1

척박한 공대의 현실에서 로그를 사랑한다니 참으로 안타까움을 금할 수 없는 제목이였다. 한편, 물질문명의 시대에 로그까지 사랑한다니 참으로 사이버 포뮬러 돋는 이야기 아닌가 싶어서 아스카 건담타는 생각을 해 보았다.

여자(사람) 친구의 불편을 처리/통합/분석을 통한 솔루션을 제공하지는 못하지만 그래도 /var/log에 위치한 로그는 어떻게 해볼 수 있지 않을까 싶어서 읽은건 아니고, 하사품이라 감사하게 읽었다.

2

이 책은 가격에 비해서 내용이 알차다. 한빛미디어에서 가격을 잘못 책정한 것 같다. 이 정도 품질이면 충분히 만원받아도 된다. 그렇다고 만원으로 인상합시다라고 건의하는건 아니지만 저렴한 가격에 비해서 내용이 좋다. 8000원 정도니까 꼭 한번 읽어보시라. 스타벅스 프라프치노 벤티사이즈에 자바칩 추가한 가격보다 저렴하다.

3

필자분이 링크드인에서 근무하셨고, 요즘 빅데이터 비슷한거 관련된 자료에 빠지지 않고 등장하는 kafka(컴파일러가 벅그가 될 것같은건 기분탓)를 만드신 분인듯 싶다.

그래서 내용이 ‘알차다’. 출퇴근하면서 존 레식의 원-포인트 레슨을 보고 있는데(존 레식이 jQuery에 주석을 달아둔 사이트) 이 책도 그에 못지 않다.

그러니까 결론은 사서 꼭 읽어보시라.(난 하사품…)

가볍게 읽을 수 있을 것 같지 않은건 아닌데, 가볍지도 않을 뿐더러 최신 기술도 이런 최신 기술이 있나 싶다.

보잘 것 없는 humble 로그를 가지고 데이터 인프라 구축에 어떻게 활용하는지, 외국에서는 어떤 최신 기술을 어떻게 써서 문제를 해결했는지 동향 파악 정도로 가볍게 읽어 내려가도 좋을 듯싶습니다.

로그는 “시간”을 축적한다. 그러므로 스트림 처리의 기준은 “시간”이 되어야 한다. 배치가 아니라 실시간이 되어야 한다. 뭐 이런 뜻인듯…

파일은 바이트의 배열이고 테이블은 레코드의 배열이며, 로그는 레코드가 시간순으로 정렬된 파일이나 레코드 중 하나다.

물리적 시간과 별도의 시간 개념이 Ordered 란 말인가?

레코드의 배열 순서가 곧 시간이라는 말이 처음엔 어색할 수 있겠지만, 특정한 물리적인 시간 관념과는 완전히 별개의 속성을 갖게 된다. 바로 이러한 속성이 분산 시스템에서 아주 중요한 핵심이 된다.

덧붙이기만 한다. 지우는건 고려하지 않겠다는 단호박같은 의지, “로그는 지우는게 아니란다”라는 마음의 울림이 느껴진다. 그래서 다들 HDFS가 필요하고, 그런김에 MR돌리고 막.. 그러다가 울고 그러는가 보다…

이 책에서 이야기할 로그는 […] 시간순으로 덧붙이기만 가능한(append-only) 레코드 시퀀스(record sequence)다.

특히 MR… 지옥같은 비가역적 결과…

분산 시스템에서 로그 중심적(log-centric)인 접근 방법은 기계 복제 원리(machine replication principle) 라는 단순한 이론에서 비롯되었다. 2개의 똑같은 확정적(deterministic) 프로세스가 똑같은 상태에서 시작하여 똑같은 입력을 똑같은 순서대로 받는다면, 똑같은 결과를 산출하고 똑같은 상태로 종료될 것이다.

그렇다. 이쁜건 이쁜거다. “프로그래머는 프로그램적이다.”… 우주세기 개드립같은 느낌적인 에반게리온이다.

이 원리에 더는 심오하고 복잡한 건 없다. 한 마디로, “확정적인 처리는 확정적이다deterministic processing is deterministic”는 것이다. 그렇긴하지만 이 한 마디가 분산 시스템을 설계하는 기본 토대가 되었다.

핵심이 너무 많다고 생각하지 않는가?

혹자는 “그렇게 간단한 걸 뭐하러 얘기하고 있는 거지?”라고 의문을 품을지 모르겠다. 덧붙이기만 가능한 레코드 시퀀스가 데이터 시스템과 무슨 상관이란 말인가? 정답은, “로그는 언제 무슨 일이 일어났는지 기록하는, 특정한 목적을 가지고 있다”는 것이다. 바로 이것이 여러 면에서 분산 데이터 시스템의 핵심이된다.

원래 로그는 롤백을 위한 것이였나? 그깟 텍스트 파일이?! 두둥…

데이터 구조와 인덱스를 동기화 시킬 용도로 사용; 로그는 데이터베이스에서 장애가 발생하면 데이터 구조와 인덱스를 동기화 시킬 용도로 사용했었다. 이를 좀 더 작은 단위로 세분화하고 오랫동안 보존할 목적으로, 데이터 구조에 어떤 변경을 하기 직전 변경될 레코드의 이력을 남겨두기 위해 데이터베이스에서 로그를 활용하기 시작했다. 로그는 발생한 일을 기록한 레코드고, 각 테이블이나 인덱스는 이러한 이력을 유용한 방향으로 투영시킨 결과물이다. 로그는 계속 보존되는 데이터이므로 시스템 장애가 발생할 때 다른 영속적인(persistent) 데이터 구조를 복구하는, 가장 확실한 소스가 된다.

메탈기어 솔리드 생각나면 이상한거다.

ACID 속성 (원자성atomicity , 일관성consistency , 고립성isolation , 지속성durability )을 구현하기 위한 용도에서 데이터베이스 간 데이터를 복제하는 도구로 사용 범위가 확대되었다.

로그가 실시간 데이터를 처리하기 위한 이상적인 컨테이너라 말인데 뭔가?!

[…]하지만 로그가 다양한 유형의 메시징이나 데이터 흐름, 실시간 데이터 처리를 가능케 한 이상적인 추상체다.

굉장히 민주적인것 같지만, 남의 나라 이야기가 아닌 우리들의 세계인가?

프라이머리-백업 모델에서는 마스터로 선정된 노드가 모든 읽기/쓰기를 담당한다. 쓰기 처리는 로그에 남게 되고, 슬레이브는 이를 구독해서 마스터가 실행한 결과를 자신에게도 적용한다. 마스터 노드에 문제가 생기면 자동으로 슬레이브 중 하나가 새로운 마스터로 등극한다. 반면, 상태 기계 복제 모델에서는 모든 노드가 피어 peer 다. 로그에 뭔가 쓰이면 모든 노드가 쓰인 순서대로 각자 자기 자신을 업데이트한다.

당연한데 ‘모든’이 붙으니 갑자기 당연하지 않게 보인다.

데이터 통합이란 조직의 서비스와 시스템에 필요한 모든 데이터를 사용할 수있게 하는 것이다.

수집이 중요하다. 뭐 이런 뜻이다.

여러분은 요즘 숨 가쁘게 회자하고 있는 빅 데이터(big data)의 그늘에 가려 데이터 통합에 대해서는 정작 많이 들어보지 못했을 것이다. 그렇지만 데이터를 가용한 상태로 만드는 이 지루해 보이는 작업이야말로 회사에서 가장 역점을 두어야 할, 핵심 목표 중 하나라고 생각한다.

이래서 인문학, 인문학 하나 본데, 도민준 생각나네…

효율적으로 데이터를 사용한다는 건 매슬로우 Maslow 의 욕구단계설(hierarchy of needs)을 따르는 것과 같다. [그림 2-1]에서 피라미드의 밑부분은 모든 관련 데이터를 붙잡아서 적절한 처리 환경 (최신 실시간 쿼리 시스템이든, 단순 텍스트 파일이든, 파이썬Python 스크립트든 간에) 에 입력하는 행위를 가리킨다. 데이터는 일정한 방법으로 가공되어 쉽게 읽고 처리할 수 있어야 한다. 일관된 방향으로 데이터를 포착한 다음에는, 인프라에서 여러 가지 방법 (맵리듀스MapReduce , 실시간 쿼리 시스템 등) 으로 데이터를 처리한다.

히터라니.. 나의 소중한 VM을…

여러분이 기억해야 할 것은, 신뢰성 있는, 완전한 데이터 흐름이 전제되지 않는 한, 하둡 클러스터는 아주 비싸기만 하고 조립은 까다로운, 공간만 많이 차지하는 골칫덩이 히터나 다름없다는 사실이다. 일단 데이터와 처리, 두 가지가 가능해야 그 다음 단계 (훌륭한 데이터 모델과 일관적이고 이해가 쉬운 의미 부여 등) 로 진행할 수 있다. 궁극적으로는 더욱 정교한 처리 (향상된 시각화 visualization , 리포팅 reporting , 알고리즘적 처리와 예측)를 할 수 있는 경지에 이르게 된다.

{신뢰성 있는, 완전한 데이터 흐름} 회사의 1차 목표인가?

데이터의 완전성, 신뢰성이 모자란 상태에서 곧바로 심도 있는 고찰과 고급 데이터 모델링 기법 등으로 옮아가려고 한다. 완전히 방향이 반대로 틀어진 것이다. 결국, 관건은 조직의 데이터 시스템 전반에 걸쳐 어떻게 신뢰성 있는 데이터 흐름을 구축할 것인가 하는 점이다.

링크드인 개발자분도 하둡의 역습에 당했나보다.

자체 키-값 저장소를 탑재한 2008년 즈음 본격적으로 이 일에 참여하게 되었다.나의 다음 임무는 하둡을 설정하여 작동시키고 여기에 추천 프로세스를 태워보는 일이었는데, 경험이 부족하다 보니 자연스레 몇 주 동안은 데이터 입/출력에, 나머지 시간은 제법 그럴싸한 예측 알고리즘을 구현하는데 시간을 다 써버렸다. 지루한시간이 이어졌다.

“다른 개발사도 마찬가지다. 우리만 그런게 아니다.” 후훗..

이렇게 만든 파이프라인은 하나하나가 제법 쉽지 않은 기술적 난제였다. 여러 대의기계에서 돌릴 수 있도록 조정을 해야 했고, 모니터링, 테스팅, 유지 보수는 필수였다. 이 지루하기 짝이 없는 데이터 복사 작업이 전체 개발 프로젝트에서 차지하는 비중은 상당했다. 설상가상으로, 어느 파이프라인 하나라도 문제가 생기면 (당시는 그리 드문 일도 아니었다) 하둡 시스템은 사실상 무용지물이었다. 최고의 알고리즘이라도 잘못된 데이터가 입력되면 쓰레기 데이터가 나올 테니 말이다

뭔가 집착과 근성이 느껴진다. 건프라를 구매하기 위한 비상금과 건프라를 쌓아두는 곳은 가능한 분리해야 한다.

데이터 소비 시스템을 데이터 소스와 가능한 한 분리해야 했다. 소비 시스템을 모두 단일한 데이터 저장소에 통합시켜 전체 소스 데이터를 바라볼 수 있게 한다면 가장 이상적일 것이다.

카프카가 좋다는 말이다.

데이터베이스와 분산 시스템 내부 구현에 널리 활용됐던 로그 개념을 이용하여 메시징 시스템에서 우리가 경험했던 것들을 바탕으로 카프카 Kafka를 개발하는 데 전념했다. 우선 활동 데이터activity data를 대상으로 중앙 파이프라인 역할을 하면서, 결국 하둡에서 데이터를 배포하거나 데이터를 모니터링하는 등 다양한 용도로 쓸 수 있는 어떤 장치가 필요했다.

가역적이라니 그럼 체(R)만 가능한건가? … 수학드립… 생각나서

데이터 흐름에는 사람과 관련된 부분도 있다. 누구나 데이터에 접근할 수 있다는 관점에서 중요한 고려 사항이다. 데이터를 로그에 내보내기 전, 데이터를 만드는 쪽에서 정제 과정을 마치는 것이 가장 좋다. 이렇게 해야 데이터가 있던 저장소 시스템이나 데이터를 만들어낸 특정 코드로부터 걷어내야 할 부분을 걷어내고 정규화된canonical 형태의 데이터를 보장할 수 있다. 자세한 로직은 데이터를 만들어낸 부서에서 가장 잘 알고 있을 테니 응당 그들에게 맡기는 것이 가장 좋다. 이 단계에서 적용되는 로직은 어떤 것이라도 손실이 없고 loseless 가역적 reversible 이어야 한다.

실시간 환경에서 값이 부가되는value-added 변환은 원천 로그 피드raw 처리post-processing 하는 sessionization log feed를 후 처식으로 이루어져야 한다. 이를테면 이벤트 데이터를 세션화한다든지, 다른 일반 파생 필드를 추가할 수도 있을 것이다. 원래 로그는 그대로 남아있는 상태에서 이렇게 실시간으로 처리하면, 증강된 augmented 데이터가 포함된 파생 로그가 만들어진다.

그림을 보고 싶다면 책을 사자!

링크드인에서 우리는 로그 중심적인 방식으로 이벤트 데이터 처리 시스템을 구축했다. 카프카를 써서 중앙의 다중 구독자 multisubscriber 이벤트 로그([그림 2-8]) 로 삼았고, 특정 유형의 액션에 대한 고유 속성을 담고 있는 수백 가지 이벤트 타입을 정의했다. 페이지 뷰, 광고 임프레션, 검색부터 서비스 호출, 애플리케이션 예외에 이르기까지 모든 것을 망라한 것이다.

파이프라인을 통한 통합이란 말인데 바벨탑같은 언어가 있지… 피해보자 자바, 다시보자 스칼라, 언제나 반가운 메이븐, 넌 누구냐? SBT 이런 느낌적인 느낌

이벤트 구동 방식으로 접근하면 문제는 간단해진다. 채용 정보 표시 페이지는 단지 채용 정보를 문제없이 보여주고 관련 속성 (일자리, 뷰어 등) 및 기타 유용한 정보를 기록하는 데 전념하면 된다. 다른 유관 시스템들 (추천 시스템, 보안 시스템, 채용 정보 게시자 분석 시스템, 데이터 웨어하우스) 은 피드를 구독해서 각자의 역할에 충실하면 된다. 채용 정보 표시 페이지의 코드는 이 시스템들의 존재를 신경 쓸 필요가 없고, 새로운 데이터 소비 시스템을 추가할 때에도 전혀 변경되지 않는다.

흠…. 다른일 찾아보란 말인가?

실제 사용할 만한 정도로 빠르고, 비용이 적게 들고, 확장성이 좋은 로그를 구축할 수 없다면 로그를 만병통치약쯤으로 생각하는 건 우아한 환상에 지나지 않는다.

우리는 카프카에 몇 가지 트릭을 사용하여 이 정도 규모의 서비스를 지탱했다.

• 로그 파티셔닝 읽기/쓰기를 한꺼번에 처리함으로써 스루풋 throughput최적화
• 불필요한 ‘데이터 복사’ 제거
• 로그를 파티셔닝하여 각 파티션이 다른 파티션과 독립적으로 작동하게 한다. 이런 식으로 쓰기 스루풋을 수평적으로 확장할 수 있다.

스트림을 처리하려면 로그로 처리해란 말인데, 로그가 앞에서 그런 느낌이니까 실시간적인 느낌적인 느낌?!

“로그”는 다른 말로 “스트림 stream”이고 스트림 처리”stream processing”의 핵심이다. // 현대 웹에서는 배치 데이터 수집이 전혀 필요 없다. 웹사이트에서 만들어지는 데이터는 활동 데이터나 데이터베이스 변경 중 하나고, 이들은 모두 연속적으로 발생한다는 특징이 있다. 사실, 어떤 비즈니스라도 그 근간은 거의 언제나 실시간으로 발생하는 이벤트, 즉 연속적인 프로세스다. 데이터를 배치 수집한다는 건 다시 말해 수작업으로 처리하는 단계가 남아있거나 디지털화가 덜 되었다는 소리다.

오호! 뭔가 굉장히 공부하란 뜻인것 같아서 믿지 않기로 하겠어!

자, 이제 스트림 처리에서 가장 많이 헷갈리는 부분을 명확히 해보자. 어떤 종류의처리 작업은 스트림 처리로는 불가하며 반드시 배치로 실행해야 한다고 주장하는 사람들이 있다. 내가 들은 바로는, 전체 데이터를 바라봐야 하는 통계치 (백분율, 최댓값, 평균값 등) 를 계산하는 경우가 그렇다고 한다. 하지만 이는 문제의 본질을 잘못 파악한 것이다. 연산 과정만 놓고 보면 틀린 말은 아니다. 예컨대 최댓값은 특정 윈도의 전 데이터 중 가장 큰 레코드를 골라내야 하므로 블로킹 연산이 맞다. 그런데 이런 연산도 스트림 처리 시스템에서 전혀 문제없다. 실제로 스트림 처리에 관한 초기 연구 논문들을 보면 첫 부분에 등장하는 내용이 윈도 내부에서 블로킹 연산을 할 수 있도록 윈도윙 windowing 의 정확한 의미를 부여하는 것이다.

역시 ‘시간’ 개념이 중요한거다. 시간 개념이 포함된 데이터는 스트림 처리가 가능하다. 역도 성립한다.

이런 관점에서 내가 생각하는, 더욱 일반적인 스트림 처리의 개념을 정리하겠다. 스트림 처리는 우선 블로킹/논블로킹 연산 여부와 무관하고, 단지 처리할 기반 데이터에 시간 개념이 포함된 처리로서, 처리할 데이터의 정적인 스냅샷은 필요하지 않다. 즉, 스트림 처리 시스템에서는 데이터의 “끝”에 도달할 때까지 마냥 기다리지 않고, 사용자가 임의로 설정한 빈도에 맞춰 결과를 산출한다. 이런 점에서 스트림 처리는 배치 처리를 일반화시킨 것이고, 실시간 데이터가 대부분인 환경에서 매우 중요한 일반화다.

복잡한 프레임워크는 필요하지 않다. 단지 안 복잡한 프로그램을 겁나게 많은 파이프라인으로 연결하는거다… 환장할 노릇

스트림 프로세서에 복잡한 프레임워크 따위는 필요하지 않다. 로그를 읽고 쓰는 프로세스는 어떤 것이라도 스트림 프로세서가 될 수 있다. 준-실시간 near-realtime 처리 코드를 관리, 확장하는 데 도움을 주기 위해 인프라를 덧붙이거나 지원할 수 있는데, 이것이 스트림 처리 프레임워크가 하는 일이다.

조대협님의 책을 읽어보면 무슨 말인지 이해된다. 자 가자 서점으로?!

작동 원리는 이렇다. 불변성 immutable 레코드 시퀀스를 포착하여 배치-및-스트림batch-and-stream 처리 시스템에 병렬로 입력한다. 변환 로직은 배치 시스템과 스트림 처리 시스템에서 각각 한 번씩, 총 두 차례 수행된다. 그런 다음 양쪽에서 쿼리로 결과를 병합한 뒤 전체 결과물을 생성한다.

람다 아키텍처 쓴 형님 책이 조만간 출시된다는 소문을 들은지 언제던가?

람다 아키텍처의 사상은 원래의 입력 데이터를 훼손되지 않은 채로 갖고 있어야 한다는 것이다. 정말 중요한 사항이라고 본다. 어떤 데이터가 들어오고 나갔는지를 알 수 있다면 복잡한 데이터 흐름을 처리하는 데 매우 큰 도움이 되기 때문이다.

실시간 처리를 가능케 하는 마법

“재처리”란 입력 데이터로 결과를 다시 생성하는 것을 말한다. 이렇게 해야 할 때가 분명히 있는데도 대부분 사람들은 신경을 안 쓴다. 코드는 항상 바뀌게 마련이다. 입력 스트림에서 결과 데이터를 만들어내는 코드가 수정되면 결과 데이터를 다시 산출하여 코드 수정에 따른 영향도를 분석해야 한다.

코드가 문제… 다 문제란 말이쟈나?

람다 아키텍처의 단점은 복잡한 분산 시스템 두 곳에서 같은 결과를 산출하기 위한 코드를 관리한다는 게 겉보기만큼 상당히 골치 아프다는 사실이다. 해결 가능한 문제는 아닌듯 싶다.

참고하겠음

그럼, 스트림 처리 작업에서 곧바로 재처리할 수 있을까? 내가 즐겨 쓰는 방법은 정말 단순하다. 1) 재처리하려는 데이터의 전체 로그를 갖고 있고 다중 구독 서비스가 가능한 카프카 부류의 시스템을 사용한다. 예를 들어, 30일 치 데이터를 재처리한다면 카프카에서 보유 기간을 30일로 설정한다. 2) 재처리할 때, 스트림 처리 작업 인스턴스를 하나 더 기동시켜 보유한 데이터의 처음부터 처리를 시작하되 결과 데이터는 새 결과 테이블에 적재한다. 3) 두 번째 처리 작업이 따라붙으면 새 테이블에서 읽어오도록 애플리케이션을 스위칭한다. 4) 구 버전의 작업을 중지하고 구 결과 테이블을 삭제한다

아니… 그만하자. 이 정도면 충분해

물론 여기서 더 최적화시킬 수도 있다. 많은 경우 2개의 결과 테이블을 병합할 수있다. 하지만 내 생각에는 얼마 안 되는 기간이라면 두 테이블을 모두 가진 편이 몇가지 이점이 있다. 그래야 구 테이블로 애플리케이션을 되돌리는 버튼 하나를 클릭하면 즉석에서 구 버전의 로직으로 돌아가게 할 수 있다. 예를 들어 광고 타기팅 기준 같은 특별히 중요한 경우에는 혹시라도 버그를 고친 코드나 새 버전의 코드가 오히려 뜻하지 않게 상황을 악화시키는 일이 없도록 자동화된 A/B 테스팅 21 , 또는 밴디트 알고리즘 bandit algorithm 22 으로 가동 중단 cutover 을 미연에 방지할 수 있다.

굿..!! 통합환경!!

그러나 정말 좋은 점은 효율이 아니라, 사람들이 하나의 처리 프레임워크에서 시스템 개발, 테스트, 디버그, 운영 작업을 할 수 있다는 사실이다. 따라서 단순함이 요구되는 상황이라면, 람다 아키텍처의 대안으로 내가 제안한 접근 방식을 고려해보기 바란다.

스키마 만들때 고려!

프로그램이 특정 시간 동안에는 비교적 한정된 주소 공간에만 접근하는 성질을 말한다. ‘시간적 지역성(Temporallocality)’은 어떤 항목이 참조되면 곧 그 항목이 다시 참조될 가능성이 높은 것을 말하고, ‘공간적 지역성(Spatial locality)’은 어떤 항목이 참조되면 그 근처에 있는 다른 항목들이 참조될 가능성이 높은 것을 의미한다.

카프카 좋다(2)

카프카는 가진 데이터가 순수 이벤트 데이터인지, 키별 업데이트 데이터인지에 따라 정리하는 방법이 두 가지로 나뉜다. 여기서 이벤트 데이터란 페이지 뷰, 클릭 등 의 비관계 사건들 unrelated occurrences , 또는 애플리케이션 로그에 나오는 다른 항목들을 의미한다. 키별 업데이트는 어떤 키에 의해 식별 가능한 엔티티의 상태 변화를 구체적으로 기록한 이벤트를 말하며, 데이터베이스의 변경 로그가 대표적인 예다.

역시 세입자 신세란…

소프트웨어 아키텍처에서 멀티테넌시(multitenancy)란, 서버에서 단일 인스턴스로 다수의 테넌트(tenant,세입자)를 서비스하는 것을 일컫는다.

나의 우분투가 그러하다.

종류가 다른 시스템들이 자꾸 늘어나는 건 그만큼 분산 데이터 시스템을 구축하기가 쉽지 않다는 걸 대변한다. 단일한 쿼리 타입이나 유스 케이스만 놓고 보면 각 시스템의 범위는 구축 가능한 작업 세트로 좁힐 수 있지만, 전체 시스템들을 한꺼번에 실행하면 복잡도가 가중된다.

응? 안된다니…. 시무룩…

관계형 데이터베이스 같지만, 수많은 소규모 시스템들을 큰 규모의 시스템 하나로 대신할 수 있으므로 조직에서 사용하는 방법은 사뭇 달라질 것이다. 이런 시나리오 대로라면 새로운 시스템에서 내부적으로 해결된 문제 이외에 별다른 실제 데이터 통합 문제는 없다. 하지만 이런 시스템을 만들기란 실상 너무 어려워서 가능한 일처럼 보이지 않는다.

이게 다 뭔말인가 싶지만 근래 1주일 동안 다 써본 기술이다. 놀랍게도…

엔지니어인 내 생각에 가장 있음 직한 가능성은 마지막 세 번째가 아닐까 싶다. 신형 데이터 시스템은 흥미롭게도 대부분 오픈소스다. 오픈소스는 새로울 가능성이 있다. 서비스 뭉치와 애플리케이션 연계 시스템 API, 이 두 갈래로 데이터 인프라를나누는 것이다. 자바 진영에서는 이미 어느 정도 비슷한 맥락으로 흘러가고 있다.

• 주키퍼Zookeeper는 대부분의 시스템 조정 역할을 맡는다.(헬릭스Helix나 큐레이터Curator같은 고수준 추상체의 지원이 어느 정도 필요하긴 하다)
• 메소스Mesos와 얀YARN은 가상화virtualization 를 처리하고 자원을 관리한다.
• 루씬Lucene, 락스DB등의 임베디드 라이브러리는 인덱싱한다.
• 네티Netty, 제티Jetty 및 피네이글Finagle과 레스트.리rest.li같은 고수준 래퍼 wrapper는 원격 통신을 담당한다.
• 아브로 Avro, 프로토콜 버퍼Protocol Buffers, 스리프트Thrift, 그 밖의 수만 가지 라이브러리로 직렬화를 처리한다.
• 카프카와 북기퍼BookKeeper는 백로그를 제공한다.

참 많은 것을 할 수 있지만, 연애는 힘들 것 같다.

로그를 통해 할 수 있는 것들을 정리해보자.

• 동시에 노드를 순서대로 업데이트함으로써 데이터 일관성 (결과적이든, 실시간이든) 유지 노드 간 데이터 복제 수행
• 작성한 데이터가 절대로 소실되는 일은 없다는 보장이 있을 때만 인정할 수 있는 작성자에게 “커밋” 개념을 제공
• 시스템으로부터 외부 데이터 구독 피드 제공
• 데이터가 소실된 장애 사본을 복구하거나 새로운 사본을 기동
• 노드 간 데이터 재조정rebalancing

중요한건 다음기회에?!

이 항목들은 상당 부분 분산 데이터 시스템이 하는 일이기도 하다. 나머지 대부분은 최종 클라이언트와 맞닿은 쿼리 API와 인덱싱 전략인데, 시스템마다 천차만별인 바로 그 부분이다. 예를 들어, 풀 텍스트 검색 쿼리는 전 파티션을 질의해야 하지만, PK를 사용하면 이 키의 데이터에 해당하는 단일 노드에 대해서만 질의하면 된다.