1.What is EDA?

 EDA(Event-driven architecture)라는 용어에 대한 정의는 약간씩 다르지만, 공통적으로 거론되는 키워드들을 중심으로 정리하면 다음과 같이 말할 수 있다.

 분산된 시스템 간에 이벤트를 생성, 발행하고 발행된 이벤트를 필요로하는 수신자에게 전송, 필요에 따라 처리하는 시스템 아키텍쳐

 따라서 EDA를 이해하려면 이벤트 대한 정의, 시스템 구성, 각 구성 요소에 대한 이해가 필요하다.

- 이벤트란 무엇인가?

 EDA에서의 이벤트란 시스템의 내,외부에서 발생한 '주목할 만한 상태의 변화(a significant change in state)'를 뜻한다. 자동차라는 컴포넌트를 예로 들면

1. 초기 상태가 '판매중(for sale)' 인 자동차가

2. 고객의 구매로 인하여

3. '판매됨(sold)' 상태로 바뀌게 되며

 자동차의 상태 변화를 감지한  판매 시스템은 이 이벤트를 발행하고 이벤트 중개자에 의해 재무, 마케팅 등 판매 이벤트를 필요로 하는 시스템으로 자동 전송된다. 이렇게 전송된 이벤트는 각 시스템의 요구에 따라 적절한 처리 과정을 수행하게 된다.

 - EDA의 구성 요소

 EDA는 크게 3개의 구성 요소로 나누어 볼 수 있다.

•  Event generator : 시스템 내,외부의 상태 변화를 감지하여 표준화된 형식의 이벤트를 생성

•  Event channel : 이벤트를 필요로 하는 시스템까지 발송

•  Event processing engine : 수신한 이벤트를 식별, 적절한 처리를 함. 때에 따라 이벤트 처리의 결과로 또 다른 이벤트를 발생시킬 수 있음.

 앞의 예에서 판매 시스템은  Event generator, 중개자는 Event channel, 재무, 마케팅 시스템은 Event processing engine에 해당한다.

- Event processing styles

  수신한 이벤트를 처리하는 방법에는 세가지 종류가 있다.

•  Simple event processing

 각각의 이벤트가 직접적으로 수행해야할 action과 매핑되어 처리 됨. 실시간으로 작업의 흐름을 처리할 때 사용되며, 이벤트 처리 시간과 비용의 손실이 적다.

•  Event Stream Processing

 이벤트를 중요도에 따라  필터링하여 걸러진 이벤트만을 수신자에게 전송. 실시간으로 정보의 흐름을 처리할 때 사용되며, 기업에 적용될 경우 신속한 의사 결정을 가능케한다.(BAM)

•  Complex event processing

 일상적인 이벤트의 패턴을 감지하여 더 복잡한 이벤트의 발생을 추론하는 것. 예를 들어 '주식의 등락'이라는 일상적인 이벤트의 패턴을 감지하여 '투자 적기'라는 상위의 이벤트를 추론해 낼 수 있다.

2.EDA & SOA

  얼핏 보면 두 아키텍쳐 간에 큰 차이가 없어 보이지만 둘 사이에는 근본적 차이가 존재한다.

• SOA : 동기화된 요청/응답 방식

• EDA : 비동기화된 배포/구독 방식

  더 자세히 설명하자면 SOA의 경우 1.필요한 서비스를 찾고, 2서비스 제공자에게 서비스를 요청하고, 3 요청에 대한 응답을 받는 단계를 순차적으로 처리한다. 즉 서비스 요청자와 제공자가 사전에 '표준화 된 호출 규약'을 합의해야하며, 하나의 서비스가 다른 서비스의 상태에 의존성을 가지게 된다.

 반면 EDA는 불특정 다수에게 이벤트를 발송하기만 하면 되며, 이벤트의 처리에 대한 내용은 발송자가 전혀 관여하지 않는다. 즉 발송자와 수신자가 서로에 대한 규약 없이 독립적으로 수행된다. 따라서 EDA는 보다 향상된 유연성(loosely coupled)을 제공 한다.

 Outsourcing, M&A, 잦은 구조 조정 등으로 인해 기업의 구조가 자주 바뀌는 상황에서 IT 시스템을 구축하고자 한다면 EDA가 더 나은 선택일 수 있다. 그러나 EDA는 SOA의 대체제가 아니라 보충물의 역할을 한다는 견해가 지배적이다.

• 은행 업무 처럼 트랜잭션 처리가 필수적인 경우

• 수직적인 기업 구조에서 명령/통제가 필요한 경우

• 순차적인 처리가 보장되야 하는 경우

 이런 경우 SOA의 사용이 적합하다. 반면 process chain 상에서의 수평적 관계에는 EDA의 사용이 적합하다.

이 글은 스프링노트에서 작성되었습니다.

1.데이터 중복 제거란?

 데이터 중복 제거란 서로 다른 데이터(파일)들 간에 중복되는 부분을 검출해내고, 중복된 부분을 제거함으로써 스토리지 활용의 효율성을 높이는 것을 말하며, 크게 보아 데이터 압축의 일종이라고 볼 수 있다. 좀 더 쉬운 이해를 위해 간단한 예를 들어보면, 우리가 매일 사용하는 메일의 첨부 파일을 생각해 볼 수 있다. 가령, 특정 부서의 관리자가 새로 도입된 시스템의 설치 메뉴얼을 100명의 임직원에게 보냈다고 생각해 보자. 만약 데이터 중복 제거를 사용하지 않는다면 똑같은 내용의 파일임에도 불구하고 100개의 파일이 스토리지에 저장되어야 한다. 그러나 만약 데이터 중복 제거를 사용한다면 100개의 파일을 저장하는 대신, 단 1개의 파일을 저장한 후, 그 1개의 파일을 가리키는 포인터 100개를 유지함으로써, 스토리지 사용량을 비약적으로 줄일 수 있다.

 용량 대비 스토리지의 가격이 급속히 하락하면서 데이터의 크기에 대한 제약은 점점 사라지고 있으며, 우리가 다뤄야할 데이터의 양은 점점 더 폭증하고 있다. 특히 이렇게 급증하는 데이터를 백업하기 위해서는 더욱더 방대한 스토리지 및 그것을 뒷받침 하기 위한 시스템이 필요하게 되었다. 그러나 기업이 사용할 수 있는 비용은 언제나 제한되어 있으며, 최소한의 비용으로 방대한 데이터를 유지 및 관리하기 위해서, 데이터 중복 제거는 선택이 아닌 필수가 되어가고 있다.

2.데이터 중복 제거의 이점

• 데이터 중복 제거의 가장 큰 이점은 역시 비용 절감이다. 일차적으로 스토리지 사용량을 줄여서, 고가의 스토리지 시스템을 확장하는 비용을 절감할 수 있다. 저장되는 데이터의 종류에 따라 최대 90%의 절감율을 보이며, 통상적으로 40% 이상의 스토리지 용량 절감 효과를 갖는다고 한다. 또한 네트워크 사용량 감소로 인한 회선 비용 절감 효과도 누릴 수  있다. 뒤에서 설명할 소스(source) 중복 제거 방식을 사용할 경우 파일 전송이나 백업시의 네트워크 트래픽을 획기적으로 줄일 수 있다.(그 외에도 상면 비용, 전력, 냉각 등 다양한 측면에서 TCO(총 소유 비용) 절감에 도움을 준다.)
• 데이터 백업 비용의 절감과 효율성 향상 역시 큰 이점이다. 특히 백업의 경우 각각 다른 버젼의 백업 데이터 대부분이 실제로는 중복되는 부분을 매우 많이 포함하므로 중복 제거의 효과를 톡톡히 볼 수 있다. 이러한 스토리지 용량 절감 효과로 인해 용량 대비 비용이 줄어들어 기존에 주로 백업 매체로 사용되어오던 자기 테이프를 디스크로 대체할 수 있다. 테이프는 보관이 어려우며, 순차적인 액세스만 가능하기 때문에 복구시 오랜 시간을 필요로 한다. 반면 랜덤 액세스가 가능한 디스크를 사용하면 필요한 데이터에 직접 접근할 수 있어 복구시 효율성을 높일 수 있다. 또한 앞에서 언급했듯이 소스(source) 중복 제거 방식을 사용할 경우 백업 및 복구시의 네트워크 트래픽이 줄어들고, 이는 백업에 소요되는 시간의 단축으로 이어진다. 즉 백업의 수행 주기를 더 작게 유지하여, 한 단계 높은 서비스 수준(SLA)을 보장하는데 도움이 된다.
• 서버 가상화가 일반화된 요즈음, 데이터 중복 제거는 또 다른 의미를 갖는다. 바로 가상화 이미지 백업에 활용될 수 있는 것이다. 가상화 이미지는 일반적으로 그 크기가 매우 크며, 실행중인 시스템에 대한 모든 정보를 담고있기 때문에 반드시 백업이 필요하다. 가상화를 사용하는 기업의 데이터 센터는 물론이고, 가상화된 자원을 서비스로 제공하는 IaaS 제공자에게 고객이 사용하는 이미지의 백업 및 복구는 필수 사항이다. 결국 방대한 용량을 갖고 중복 부분이 큰 이미지 백업에 중복 제거는 그야말로 안성맞춤이라 하겠다. (실제로 많은 중복 제거 솔루션들이 가상화 관리 솔루션에 통합된 이미지 백업 기능을 제공하고 있다.)

3.데이터 중복 제거의 분류

 데이터 중복 제거는 몇가지 기준에 따라 분류될 수 있다. 각각의 장단점을 살펴보자.

3.1.중복 제거의 수준에 따른 분류

•  먼저, 파일 수준의 중복 제거는 말 그대로 파일 전체가 중복되는 경우에만 중복 제거를 수행하는 방식으로 SIS(Single Instance Storage)라고도 불린다. 중복되는 파일이 많은 경우 손쉽게 구현될 수 있다는 장점이 있으나 효율성 면에서는 바람직하지 못하다. 예를 들어, 두 파일이 딱 1비트만 달라도 서로 다른 파일로 인식되기 때문이다.
•  반면 한 파일을 블록(혹은 청크, 세그먼트) 단위로 나누거나 비트 단위의 중복 제거를 수행하는 방식이 있다. 중복되는 블록은 오직 1번 저장되고, 그 블록을 가리키는 포인터를 저장함으로써 추후에 파일을 재조합할 수 있다. 당연히 효율성 면에서는 파일 수준의 중복 제거보다 훨씬 뛰어나다. 블록 수준의 중복 제거는 다시 두가지로 나뉠 수 있다. 블록의 크기가 고정되어있는 고정 길이 방식과 블록의 크기가 가변적인 가변 길이 방식이 그것이다. 일반적으로 블록의 길이를 최적화 할 수 있고, 중복된 블록의 파일 내 오프셋 변경이 가능한 가변 길이 방식이 더 효율적이다.

3.2.중복 제거가 일어나는 장소에 따른 분류

•  먼저, 애플리케이션(예를 들면 백업 프로그램)이 위치하는 데이터 소스에서 중복 제거가 이루어지는 소스(source) 중복 제거 방식이 있다. 별도의 데이터 중복 제거 모듈을 소스 디바이스에 설치한 후, 중복된 부분에 대해서는 그 포인터 만을 타깃 스토리지에 전송하는 방식이다. 위에서 언급했듯이 실제 데이터를 전송하지 않고 그 포인터만을 전송하기 때문에 네트워크 트래픽이 크게 줄어드는 장점이 있다. 그러나 중복 제거 작업이 많은 CPU 작업을 요구하기 때문에 본래 애플리케이션의 수행에 오버헤드로 작용할 수 있다.
•  반면 소스 디바이스에서 보내진 원본 데이터를 타깃 스토리지 측에서 중복 제거하는 방식을 타깃(target) 중복 제거 방식이라고 한다. 소스 디바이스에 별도의 오버헤드가 없고, 중복 제거 기능을 갖추지 않은 기존의 애플리케이션을 그대로 사용할 수 있다는 장점이 있으나 전송되는 데이터의 크기가 클 경우 대량의 네트웍 트래픽이 발생하며 백업 및 복구 소요 시간이 커질 수 있다.
•  위의 두 방식의 절충점이 바로, 소스와 타깃 사이에 전용 어플라이언스를 두는 것이다. 위에서 설명한 두 방식의 장점을 고루 가지고 있지만 전용 어플라이언스의 비용 및 확장성이 문제가 될 수 있다. 소스 디바이스의 갯수가 늘어나면 전용 어플라이언스 갯수 역시 늘어나야 하며, 잘못하면 어플라이언스가 병목 구간으로 작용할 수 있다.

3.3.중복 제거가 일어나는 시점에 따른 분류

•  모든 데이터를 임시 디스크에 저장한 후, 추후 시점에 데이터 중복 제거를 진행하는 방식을 사후 처리 중복 제거 방식(post-process deduplication)이라한다. 이 방식은 별도의 임시 스토리지가 필요하며, 저장된 임시 데이터가 많을 경우 작업 완료 시간이 지연될 수 있다. 그러나 데이터를 수신하는 시점에는 별도의 오버헤드가 존재하지 않아 빠른 송수신이 가능한 장점이 있다.
• 데이터를 수신 받은 후 바로 중복 제거 작업을 진행하는 방식이 인라인 중복 제거(in-line deduplication) 방식이다. 별도의 임시 스토리지가 필요치 않으나, 데이터 송수신시 오버헤드가 존재한다.

3.4.중복 제거의 방식에 따른 분류

•  가장 많이 사용되는 방식은 해시 함수(hash function)를 사용하는 것이다. 특정 파일이나 블록, 혹은 비트 스트림에 대하여 해시 값을 계산하고 해시 값이 같은 두 세그먼트를 중복된 데이터로 간주하는 것이다. 또한 각 해시 값에 대한 인덱스를 유지하여 빠른 저장 및 조회가 가능토록 한다. 그러나 이론상 아무리 강력한 해시(strong hash)를 사용하더라도 해시 충돌(hash collision)의 가능성은 존재한다(그 가능성은 매우 적을지라도). 즉 해시 값이 같은 두 세그먼트가 실제로는 다른 데이터일 수 있다는 것이다. 따라서 경우에 따라서는 해시 충돌을 처리하기 위한 메커니즘이 필요하다.
•  또 다른 방법으로는 형상 관리 툴에서 주로 사용되는 델타 기반 중복 제거(텔타 인코딩)가 있다. 이 방식은 기본 복제본을 기준으로 향후 변동된 내용에 대해서만 기록하는 방식이다. 해시 방식이 CPU 자원을 주로 사용하는 반면 델타 기반 방식은 이전 복제본과의 비교를 위해 디스크 입출력이 많다. 

4.향후 발전 방향

 현재까지 데이터 중복 제거의 활용 영역은 백업을 비롯한 2차 스토리지에 국한되어 있었다. 그러나 최근 데이터 중복 제거를 1차 스토리지에 활용코자하는 노력이 계속되고 있다. 이를 위해서는 중복 제거에 의한 오버헤드를 최소화하여 작동중인 시스템의 동작에 주는 악영향을 줄여야 한다. 또한 각종 SW 솔루션의 수정이나 별도의 통합 작업 없이 데이터 중복 제거 기능을사용할 수 있도록 표준화된 인터페이스를 제공해야 한다.

이 글은 스프링노트에서 작성되었습니다.