N95 마스크란?

최근 한국에서의 이슈 때문에 SNS에서 N95 마스크가 많이 언급되고 심지어 신문기사까지 나오길래 N95란 무엇인지 찾아보았다. N95, N99, N100 등의 명칭은 미국 CDC산하의 기관인 NIOSH가 FFR (filtering facepiece respirators) – 소위 마스크, 정확히는 마스크와 FFR은 구분되고 있음. – 의 필터링 능력이 무엇이고 어느 정도인지를 검사하고 인증했음을 나타내는 것.

NIOSH가 제시하는 특정 테스트 조건에서 N95, N99, N100은 각각 기름 성분이 아닌 에어로졸에 대해서 95%, 99%, 99.97%의 필터링 성능을 나타냄. 공무원 스러워 보이는 분들이 착용하고 있어서 조금 화제가 되었던 3M 1860 Surgical Mask는 Surgical N95로 분류되는데, N95 인증을 받았을 뿐만 아니라 FDA의 Surgical Mask 인증도 받은 것을 의미하고, Surgical Mask의 기준은 밀폐기준이나 입자의 크기 기준등이 NIOSH의 기준보다 약하기 때문에 (당연히도) NIOSH 입장에서는 크게 의미있게 보고 있지는 않은 듯.

대체로 가장 많이 통과를 하는 입자의 크기는 100nm 이하 (30-60nm)이고 그 외에는 대체로 100%에 가까운 필터링 성능을 보여준다고 하는 듯. 바이러스의 크기가 10nm ~ 1um이라고 하고, 실제로 바이러스가 공기중으로 이동할 때는 액체 형태의 다른 입자와 함께 이동할 것으로 추측되므로 꽤나 신뢰할만한 듯. (영화 등을 보면서 어떻게 마스크 따위로 바이러스 감염을 막을 수 있는 거지라는 의문이 많이 들었다는 점을 고백.)

NIOSH가 인증 시 테스트 규격은 NaCL 에어로졸을 사용하고 있는데, 생물학적 조직 입자를 포함하는 에어로졸의 투과율보다 NaCl 에어로졸의 투과율이 더 높기 때문에 좀 더 엄한 테스트 기준으로 사용되고 있는 듯 하다.

NIOSH의 FFR 인증에 대해서는 여러가지 입자 (가공된 나노 입자)나 여러가지 상황(작업 환경처럼 밀도 등이 변화할 수 있는 환경)에서의 성능 연구가 여러모로 이루어지고 있는 것처럼 보이므로 어느 정도 안심하고 믿을 수 있는 것 같다.

이러한 기준을 만족하기 위해서는 당연히 마스크와 얼굴 표현 사이로 입자들이 새어들어오지 않도록, 마스크가 고무 같은 부품에 의해 얼굴에 완전히 흡착되는 특징을 가지고 있으므로, 일상생활에서 사용하기에는 굉장히 힘들 것 같고, 의료진이나 빈번하게 노출되는 환경에 있는 검역 관련 직원들이나 사용하는 것이 맞겠다는 생각.

Amazon Japan에서 마스크 제품 상위권에 나오는 N95 마스크는 다음의 2가지 제품인데, 의외로 불편함에 대한 불만이 별로 안보여서 한번 시험삼아 사볼까 하는 생각도 들고 있다.

덧. 참고로 일본 일반인용 마스크 제품에서 자주 언급되는 PM2.5는 2.5um이하의 입자를 의미.

References

Kafka: a Distributed Messaging System for Log Processing

Kafka: A distributed messaging system for log processing In Proceedings of 6th International Workshop on Networking Meets Databases (NetDB), Athens, Greece (2011) by J. Kreps, N. Narkhede, J. Rao

Kafka는 기존의 메시징 시스템에서 당연하다고 가정하고 있었지만, 로그 처리 시스템에서는 필요없는 보장들을 과감하게 버리고, 성능 위주의 설계를 함으로써, 실제로 링크 속도에 육박하는 성능을 보여주고 있고, 상당히 단순한 아키텍쳐를 유지하고 있는 점이 흥미로운 점입니다. 그리고, 현실의 데이터 처리에 있어서는 버그나 장애로 인해 흔히 발생하는 재처리가 pull 기반의 소비 모델을 도입함으로써 매우 쉽게 가능해졌다는 점도 눈여겨 볼 부분입니다.

주의: 이 글은 2011에 출판된 Kafka의 페이퍼 내용을 다루고 있으며, 현재의 Kafka 버전의 내용을 다루고 있지 않습니다.

Problem

기존의 엔터프라이즈 메시징 시스템들의 한계를 다음과 같은 이유들로 설명하고 있습니다.

  • 배달 보장 (delivery guarantee)을 위한 기능들은 로그 처리를 위한 시스템 입장에서는 불필요..
  • 처리속도 (throughput)를 디자인 제약으로 고려하지 않음.
  • 분산에 대한 고려가 부족.
  • 메시지가 즉시 소비되는 것을 전제로 하기 때문에 메시지가 쌓일 경우 성능이 하락.

마찬가지로 최근에 만들어진 로그 처리 시스템들 – Scribe, Yahoo’s data highway project, Flume의 한계는 다음과 같은 이유들로 설명하고 있습니다.

  • 로그 데이터를 오프라인으로 처리하는 것을 위해 만들어진 시스템.
  • 대부분은 push 모델.

Kafka Architecture and Design Principles

Kafka의 주요 개념들과 개략적인 디자인은 다음과 같습니다.

kafka_architecture

  • 토픽 (topic): 특정한 타입의 메시지의 스트림
  • 프로듀서 (producer): 어떤 토픽에 대해 메시지를 발행 (publish)할 수 있음.
  • 프로듀서에 의해 발행된 메시지들은 브로커 (broker)라는 서버들에 저장됨. Kafka 클러스터는 일반적으로 여러 브로커들로 이루어짐.
  • 컨수머 (consumer)는 브로커로부터 1개 이상의 토픽을 구독할 수 있고, 브로커들로부터 데이터를 당김(pull)으로써 구독한 메시지들을 소비 (consume)할 수 있음.
    • point-to-point 배달 모델: 여러 컨수머가 하나의 토픽 내의 메시지를 하나씩 소비.
    • 발행/구독 (publish/subscribe) 모델: 여러 컨수머가 하나의 토픽의 각자의 복제본 메시지들을 소비.
  • 토픽은 여러 파티션들로 이루어져 있고, 각각의 브로커는 하나 이상의 파티션을 저장.

Efficiency on a Single Partition

Simple storage

  • 어떤 토픽의 각 파티션은 논리적인 로그에 해당.
  • 물리적으로 로그는 거의 동일한 크기의 세그먼트 파일들의 집합으로 구현됨.
  • 프로듀서가 어떤 파티션에 메시지를 발행할 때마다 브로커는 마지막 세그먼트 파일에 메시지를 append 한다.
  • 성능을 위해서 특정 개수의 메시지가 발행되거나 특정 시간이 흐른 후에 세그먼트 파일을 디스크로 flush한다.
    • 메시지는 flush가 된 후에 컨수머에게 노출됨.
  • 전형적인 메시징 시스템과 달리, 카프카의 메시지에는 메시지 식별자가 없고 로그 상의 논리적인 오프셋 (offset)을 주소로 사용.
    • 메시지 식별자로부터 메시지를 찾기 위한 인덱스 구조를 유지할 필요가 없어짐.
    • Kafka의 메시지 식별자 – 로그 상의 논리적인 오프셋은 자연히 증가하지만, 연속적이지는 않음.
  • 컨수머는 항상 특정한 파티션으로부터 연속적으로 메시지를 소비함.
  • 컨수머가 특정한 메시지 오프셋에 대해 ack을 한다면, 이는 그 파티션의 해당 오프셋 이전의 모든 메시지를 받았음을 의미.
  • 컨수머는 브로커에게 비동기적인 당김 (pull) 요청을 보낸다. 각 요청은 소비할 메시지의 오프셋과 최대로 가져올 메시지의 크기를 포함.
    • 브로커는 모든 세그먼트 파일의 첫번째 메시지의 오프셋들의 목록을 메모리 상에 유지.
    • 브로커는 그 목록을 세그먼트 파일을 찾고, 컨수머에게 데이터를 보낸다.
    • 컨수머가 메시지를 받은 후에는 다음 메시지의 오프셋을 계산해서 다음 요청에서 사용.

kafka_log

Efficient transfer

  • 프로듀서는 한번의 send 요청에 여러 메시지를 보낼 수 있음.
  • 컨수머 API는 한번에 하나의 메시지를 소비하는 것처럼 보이지만, 내부적으로는 각 당김 요청은 특정 사이즈 (보통 수백 KB) 내에 해당하는 여러 메시지를 가지고 옵니다.
  • 메시지들을 직접 메모리 상에 캐싱을 하지 않고 파일 시스템 페이지 캐시에 의존함.
    • 중복된 버퍼링을 피함.
    • 프로세스 내에서 메시지를 캐시하지 않기 때문에 가비지 컬렉션의 오버헤드가 매우 적어짐.
    • 프로듀서와 컨수머는 세그먼트 파일을 순차적으로 액세스하고, 보통 컨수머는 프로듀서보다 살짝 뒤쳐지기 때문에, 보통의 OS 캐싱 휴리스틱 (write through, read-ahead)이 매우 효과적으로 동작함.
  • sendfile API를 이용해서 복사와 시스템 콜 회수를 줄임.

Stateless broker

  • 대부분의 다른 메시징 시스템과 다르게, 각각의 컨수머가 얼마나 소비했는지는 브로커가 유지하지 않음.
    • 이러한 디자인은 브로커의 복잡도와 오버헤드를 줄임.
  • 문제는 이미 소비한 메시지를 언제 지울지 결정하는 것이 어려워짐.
    • Kafka는 시간 기준의 SLA를 사용해서 해결하는데, 특정 기간 (보통 1주일) 이상이 지나면 메시지는 자동적으로 삭제됨.
      • 대부분의 컨수머는 비교적 짧은 시간 단위 – 매일, 시간별, 실시간 – 내에 소비를 마치기 때문에 문제가 없음.
      • 카프카는 데이터가 크기에 따라서 성능이 저하되지 않으므로 이러한 방법이 가능.
  • 부가적인 이점으로, 컨수머는 이전의 오프셋으로 되돌아가 메시지를 다시 소비하는 것이 가능해짐.
    • 예를 들어, 컨수머의 로직에 에러가 있을 경우, 에러가 수정된 후에 문제가 된 메시지들을 다시 처리하는 것이 가능.
    • 컨수머가 크래시한다면 flush되지 않은 데이터는 잃어버리겠지만, flush하지 않은 가장 작은 오프셋부터 메시지를 다시 소비하는 것이 가능.
    • 이러한 메커니즘은 push 모델보다 pull 모델에서 훨씬 쉬움.

3.2 Distributed Coordination

  • 각각의 프로듀서는 랜덤하게 선택된 파티션이나 파티셔닝 키와 파티셔닝 함수에 의해 결정된 파티션으로 메시지를 발행할 수 있다.
  • 컨수머 그룹 (consumer group)이라는 개념
    • 토픽의 집합을 consume하는 하나 이상의 컨수머들로 구성.
    • 서로 다른 컨수머 그룹은 독립적으로 구독한 메시지들의 전체 집합을 consume하고, 컨수머 그룹 끼리는 조정?(coordination)이 불필요.
  • 어떤 토픽 내에서 하나의 파티션은 병행성의 최소 단위
    • 주어진 시점에 하나의 파티션으로부터의 모든 메시지는 각 컨수머 그룹 내에서 하나의 컨수머에 의해서만 소비됨.
    • 하나의 파티션을 여러 컨수머가 동시에 소비하도록 했다면 누가 어떤 메시지를 소비할지는 조정해야하는 오버헤드가 발생.
    • 로드를 균형 있게 맞추기 위해서는 파티션의 수는 컨수머의 수보다 더 많아지도록 유지.
  • 시스템을 단순화하기 위해 중앙의 마스터 노드를 가지지 않도록 함.
    • 조정을 위해서 Zookeeper를 사용.
    • Kafka가 ZooKeeper를 사용하는 작업들
      • 브로커와 컨수머의 추가와 제거를 탐지
      • 브로커나 컨수머가 추가/제거될 경우 각 컨수머에게 리밸런스 프로세스를 트리거.
      • 소비 관계를 유지하고, 각 파티션의 소비된 오프셋을 추적
        • 브로커나 컨수머가 시작하면 주키퍼의 브로커 또는 컨수머 레지스트리에 그 정보를 저장.
        • 브로커 레지스트리는 브로커의 호스트 이름과 포트, 토픽과 파티션의 집합을 포함.
        • 컨수머 레지스트리는 컨수머가 속한 컨수머 그룹과, 구독하고 있는 토픽들의 집합을 포함.
        • 각 컨수머 그룹은 소유권 레지스트리와 오프셋 레지스트리와 연관됨.
        • 소유권 레지스트리는 모든 구독된 파티션에 대해 하나의 ZooKeeper 경로를 가지며, 그 값은 현재 그 파티션을 소비하고 있는 컨수머의 ID.
        • 오프셋 레지스트리는 각각의 구독된 파티션에 대해 파티션 내에서 마지막으로 소비된 오프셋을 저장.
      • 브로커 레지스트리, 컨수머 레지스트리, 소유권 레지스트리에 대한 주키퍼 경로들은 ephemeral 경로.
      • 오프셋 레지스트리에 대해서는 persistent 경로.
      • 브로커가 실패하면 그 위의 모든 파티션은 자동적으로 브로커 레지스트리에서 삭제됨.
      • 컨수머의 실패는 컨수머 레지스트리에서 컨수머에 해당하는 항목과 소유권 레지스트리에서 그것이 가진 모든 파티션을 삭제.
    • 각 컨수머는 브로커와 컨수머 레지스트리에 대해 ZooKeeper Watcher를 등록하고 브로커나 컨수머 그룹에서 변화가 일어나면 통지를 받음.
    • 컨수머의 시작이나 컨수머가 브로커/컨수머 변화에 대해 통지를 받으면, 컨수머는 소비할 파티션의 부분집합을 정하기 위해 리밸런스 프로세스를 시작.
      • 브로커와 컨수머 레지스트리를 읽어서 각 구독된 토픽에 대해 사용가용한 파티션의 집합과 그 토픽을 구독하고 있는 컨수머의 집합을 계산.
      • 파티션 집합을 범위로 파티셔닝(range-partition)해서 컨수머의 수 만큼의 청크로 나누고 소유할 청크를 고름.
      • 컨수머가 고른 각 파티션에 대해 소유권 레지스트리에 그 파티션의 새로운 소유자로 스스로를 써넣음.
      • 컨수머는 각 소유한 파티션으로부터 데이터를 당겨오는 쓰레드를 시작. 오프셋 레지스트리에 저장된 오프셋으로부터 읽기 시작.
      • 컨수머는 주기적으로 오프셋 레지스트리에 마지막으로 소비한 오프셋을 업데이트.
    • 그룹 내에 여러 컨수머가 있을 때 각각은 브로커/컨수머 변경에 대해 통지를 받지만, 그 통지가 컨수머마다 살짝 다르게 올 수 있음.
      • 하나의 컨수머가 다른 컨수머에 의해 아직 소유된 파티션에 대한 소유권을 가지려고 하는 것이 가능.
      • 이 경우, 첫번째 컨수머는 단순히 모든 파티션을 릴리즈하고 조금 기다린 후 리밸런스 프로세스를 재시도한다.
      • 리밸런스 프로세스는 단 몇번의 재시도 만에 안정화됨.
    • 새로운 컨수머 그룹이 만들어졌을 때는 오프셋 레지스트리에는 오프셋이 없지만, API를 사용해서 최소 또는 최대의 오프셋부터 시작할 수 있음.

Delivery Guarantees

  • Kafka는 at-least-once 배달만을 보장함.
    • exactly-once 배달은 보통 2PC를 필요로 하고, 카프카가 대상으로 하는 애플리케이션은 필요로 하지 않음.
    • 보통의 경우, 메시지는 각 컨수머 그룹에 정확히 한번만 배달됨. 하지만, 컨수머 프로세스가 정상적으로 종료되지 않고 죽은 경우, 그 컨수머가 소유하고 있던 파티션을 새롭게 소유하게된 컨수머는 ZooKeeper에 커밋된 마지막 오프셋 후의 메시지들에 대해 중복 메시지를 소비하게 됨.
    • 애플리케이션에 있어서 메시지의 중복이 중요한 문제라면, Kafka가 컨수머에게 돌려주는 오프셋을 이용하거나 메시지 내의 어떤 유일하게 식별 가능한 키를 사용해서 자체적인 중복 방지 로직을 추가해야함.
  • Kafka는 하나의 파티션으로부터의 메시지는 컨수머로 차레대로 전달되는 것을 보장. 하지만 서로 다른 파티션으로부터 오는 메시지의 순서는 보장하지 않음.
  • 로그가 망가지는 것을 피하기 위해 각 메시지에 대해 CRC를 저장.
    • Kafka는 CC를 가진 메시지를 삭제하는 리커버리 프로세스를 실행.
    • 이 CRC는 네트워크 에러를 체크할 수도 있게 해줌.
  • 브로커가 죽으면 그것 내에 저장된 소비되지 않은 메시지는 사용불가능해짐.
    • 미래에는 여러 브로커에 메시지를 중첩해서 저장하는 자체적인 복제를  추가할 예정.

Experimental Results

Producer test

producer_performance

Kafka의 Producer 성능이 좋은 이유를 아래와 같은 이유로 설명하고 있습니다.

  • Kafka 프로듀서는 브로커로부터의 ack을 기다리지 않고 브로커가 다룰 수 있는 만큼 빠르게 메시지를 보냄.
    • 배치 크기가  50일 때는 Kafka 프로듀서는 프로듀서-브로커 사이의 1GB 링크에 포화됨. (saturated)
    • ack이 없으므로 발행된 모든 메시지가 실제로 브로커에 의해 받아진 건지 보장할 수 없음.
    • 로그 데이터에 대해서는 영속성을 처리속도와 트레이드를 하는 것이 좋음.
    • 미래에 영속성이 중요한 데이터에 대한 개선을 계획 중임.
  • 효율적인 스토리지 형식
    • 평균적으로 Kafka에서는 각 메시지는 9바이트의 오버헤드를 가짐. 반면, ActiveMQ에서는 144 바이트.
    • ActiveMQ에서의 오버헤드는 JMS가 요구하는 무거운 메시지 헤더에서 옴.
    • 여러 인덱싱 구조를 유지하기 위한 비용도 존재.
  • 배치 방식은 RPC의 오버헤드를 감추어서 (amortize) 처리속도를 크게 개선함.

 

Consumer Test

consumer_performance

Kafka가 좋은 성능을 보여주는 이유를 다음과 같이 설명하고 있습니다.

  • 효율적인 스토리지 포맷
  • ActiveMQ, RabbitMQ는 모든 메시지의 배달 상태를 유지하기 위해 꾸준히 쓰기가 발생하지만, Kafka의 브로커는 소비를 위한 디스크 쓰기가 발생하지 않음.
  • sendfile API의 사용.

Future Works

Kafka가 미래에 지원할 기능으로 우선 영속성을 위한 자체적인 복제 지원을 들고 있습니다. 비동기-동기 복제를 둘다 지원하려고 하고, 애플리케이션의 여러가지 요구에 따라 적절한 중첩 레벨을 선택할 수 있도록 하려 한다고 합니다. 다른 하나는 스트림 프로세싱입니다. 기본적인 레코드 수를 센다든지, 다른 스트림이나 다른 스토리지의 데이터와 join하는 등의 처리가 가능하게 하려고 합니다. 우리는 현재의 Kafka는 스트림 프로세싱을 지원하지 않고, Kafka와 협동하는 다른 프레임워크에 위임하는 방식으로 이루어지고 있다는 것을 알고 있습니다.

Finding a needle in Haystack: Facebook's photo storage

Finding a needle in Haystack: Facebook’s photo storage by Doug Beaver, Sanjeev Kumar, Harry C. Li , Jason Sobel , Peter Vajgel , Facebook Inc, 2010.

최근 몇개월 동안  상대적으로 크기가 작고 많은 파일들을 비교적 단순한 솔루션을 이용해서 효율적으로 저장하는 것에 대해서 관심이 있어서 읽어본 페이퍼이다. 파일들의 개수로 인한 메모리 사용량과 복제 시간 등이 골칫거리라서 커다란 파일에 저장하는 방법을 여러가지로 검토하고 있었는데, 매우 실용적이고 깔끔한 접근으로 문제를 해결하고 있고, 실제로 개발 비용도 적게 (몇개월 정도 걸렸다고 한다) 들었으므로, 2009년 경의 시스템이지만, 서비스를 다루는 엔지니어로서는 배울 점이 있다고 생각한다.  이미지 파일 자체가 불변 데이터이므로 상대적으로 쉬운 문제인 것은 맞지만, 실제로 서비스에 적용하는 것은 또 다른 문제이다. 오픈소스화 되어 있지 않은 것이 아쉬운 점이라고 할 수 있는데 – 실리콘 밸리의 큰 회사들 치고는 의외로 Facebook은 오픈소스에 그렇게 열려있지 않은 문화인 것 같다 –  구현이 비교적 단순하기 때문인지 수많은 Haystack Clone들이 있다. 혹시 좋은 구현을 찾게되면 소개할 기회가 있을지도 모르겠다.

Problem – NFS Approach

Facebook은 NAS와 NFS를 이용하는 사진 스토리지를 구축하고 있었으며 다음과 같은 문제를 인식하고 있었다.

  • 사진을 저장할 때 전통적인 POSIX 파일시스템에서 요구하는 파일 메타데이터는 필요하지 않음.
  • 사진 파일을 읽기 위해서 3번의 디스크 오퍼레이션이 필요하고 메타데이터의 액세스가 병목이 됨.
    • 디렉토리의 blockmap이 너무 커서 효과적으로 캐시되지 않음.
  • Hot한 액세스는 CDN으로 다룰 수 있지만, long tail 성격을 가진 액세스가 있으므로, 캐싱만으로 해결할 수 없음.
  • 대체 기술들도 적합하지 않음.
    • MySQL, Hadoop
    • RAM을 늘리는 것만으로는 비효율적.

Design & Implementation

Haystack은 다음과 같은 목표를 달성해서 NFS approach의 bottleneck을 줄인다.

  • 실제 데이터를 읽기 위한 디스크 오퍼레이션을 단 1번만 필요하도록 한다.
  • 메타데이터를 위한 메모리 사용량을 줄임.

기본적인 접근 방식은 여러 사진을 하나의 커다란 파일에 저장하는 방식을 사용하는 것이다.

전체적인 시스템 구성은 Haystack Store, Haystack Directory, Haystack Cache의 3개의 서브시스템으로 이루어져 있다.

  • Store
    • Persistent storage로 파일시스템 메타데이터를 관리하는 컴포넌트.
    • Logical volume은 서로 다른 장비의 Physical volume들로 구성됨.
  • Directory
    • Logical Volume으로부터 Physical volume으로의 맵핑.
    • 각 사진들이 있는 Logical volume이나 여유공간이 있는 Logical volume을 관리한다.
  • Cache
    • 내부적인 CDN과 같은 역할.

웹서버는 디렉토리를 이용해서 URL을 구성하는데, 특이한 것은 사진의 URL에 Logical volume이나 장비에 대한 힌트 등 사진을 가져오기 위한 정보가 들어가 있다는 점이다.

  • URL은 CDN host/Cache/Machine ID/Logical volume, Photo와 같은 형태인데, CDN 또는 Haystack Cache는 (Logical volume, Photo) 정보만을 이용해서 자신의 캐시로부터 사진을 찾는다.
  • CDN이나 Cache로부터 miss일 경우에는 Cache address를 URL로부터 제거하고 Store 장비에 사진을 요청한다.

Haystack Directory

Haystack Directory는 다음과 같은 4가지 기능을 가지고 있다.

  • Logical volume을 Physical volume으로 맵핑
    • 어떤 Store 장비가 소실된 상황에서는 mapping에 상응하는 엔트리를 삭제하고 온라인이 된 새로운 머신으로 대체.
  • 쓰기 액세스를 여러 로지컬 볼륨에 대해 로드 밸런싱, 읽기 액세스를 여러 피지컬 볼륨에 대해 로드밸런싱
  • 리퀘스트가 CDN으로 핸들링되어야할지 Cache로 핸들링되어야할지 결정
  • 로지컬 볼륨이 읽기전용인지 아닌지에 대한 판단. (운영적인 이유나 용량 한계)
    • 새로운 장비를 추가하면 이 장비는 쓰기가 허용되고, 쓰기가 허용된 장비만 사진의 업로드를 받는다.

Haystack Directory는 복제가 되는 데이터베이스에 정보들을 저장하고 PHP interface로 액세스되며, latency를 줄이기 위해 memcache를 사용한다고 한다.

Haystack Cache

Haystack Cache는 Photo ID를 키로 데이터를 찾을 수 있는 Distributed hash table로 구성되어 있다. 어떤 DHT를 사용하고 있는지에 대해서는 자세히 설명되어 있지 않다. 캐시되어있지 않다면, URL에 명시되어 있는 Store 장비에서 사진을 가져온다. 캐시하는 조건이 조금 특이한데 다음과 같다.

  • 사용자로부터 직접 온 리퀘스트이고 CDN이 아닐 때: CDN에서 miss된 것이 내부 캐시에서 hit될 가능성이 낮음.
  • 쓰기가 허용된 Store 장비로부터 사진을 가져왔을 때: 사진은 업로드된 뒤에 헤비하게 액세스되므로 쓰기가 허용된 장비를 과도한 읽기 액세스로부터 보호.

Haystack Store

  • 전반적인 구조
    • 각 Store 장비는 여러 개의 Physical volume을 관리하고, 각 volume은 수백만 개의 사진을 저장한다.
      • 이를테면, Physical volume은 100GB이고, /hay/haystack…<logical volume id>와 같이 저장됨.
    • Store 장비는 Logical volume의 ID와 file offset을 이용해서 사진을 액세스할 수 있다.
    • Store 장비는 각 Physical volume에 대해 file descriptor를 유지한다.
    • Physical volume은 수퍼블럭과 needle의 sequence로 이루어져 있음.
    • needle을 빠르게 가져오기 위해서 각 볼륨에 대해 In-memory data structure를 유지하고 있음.
      • (key, alternative key) -> (needle’s flags, size in bytes, volume offset)
      • alternative key는 4개의 서로 다른 크기의 사진을 나타냄.
  • 읽기 (Photo Read)
    • 읽기 요청에는 Logical volume ID, Key, Alternative key, Cookie가 있다.
    • 사진이 업로드될 때 cookie는 랜덤하게 생성되어 Directory에 저장된다. 사진의 URL을 추측해서 액세스하는 공격을 막아준다.
    • In-memory 맵핑에서 관련된 메타데이터를 찾고, 지워진 사진이 아니라면 적절한 offset을 seek해서 전체 needle을 읽어들임.
    • 읽어들인 needle로부터 cookie를 검증하고 데이터의 integrity를 체크 후 문제가 없다면 응답.
  • 쓰기 (Photo Write)
    • 쓰기 요청에는 Logical volume id, Key, Alternate key, Cookie, Data가 있다.
    • Physical volume file에 needle image를 동기적으로 append하고, In-memory 맵핑을 업데이트 함.
    • 이미 존재하는 사진의 업데이트는 동일한 key/alternate key로 업데이트된 needle을 append하는 것으로 이루어진다.
      • 새로운 needle이 다른 Logical volume에 쓰여진다면, Directory는 애플리케이션 메타데이터를 업데이트하므로 미래의 읽기 요청은 기존 버전을 읽지 않음.
      • 새로운 needle이 같은 Logical volume에 쓰여진다면, 새로운 needle을 append함.
      • 업데이트로 인해 중복된 needle이 발생할 수 있는데, 하나의 Physical volume에서 높은 offset의 needle이 최신 버전의 needle이다.
  • 지우기 (Photo Delete)
    • In-memory 맵핑과 Volume file에 삭제 플래그를 설정.
    • 삭제된 사진에 대한 읽기 요청은 먼저 In-memory 맵핑의 플래그를 체크하고, 삭제 플래그가 설정되어 있다면 에러.
  • 인덱스 파일
    • 이론적으로는 모든 Physical volume을 읽어서 In-memory 맵핑을 복구할 수 있지만, 꽤 시간이 걸리는 일이므로, 인덱스 파일은 In-memory 맵핑을 빨리 빌드하게 도와주어 Store의 재기동 시간을 줄여줌.
    • 각각의 Physical volume에 대해 인덱스 파일을 유지하는데, In-memory 데이터 구조의 체크포인트라고 생각할 수 있다.
    • 인덱스 파일의 구조는 Physical volume file과 유사하게 수퍼블럭과 인덱스 레코드들의 시퀸스인데, Physical volume file에 나타나는 needle과 동일한 순서임.
    • 사진을 추가할 때 needle은 Physical volume file에 동기적으로 쓰지만, 인덱스 레코드는 비동기적으로 쓴다.
    • 사진을 삭제할 때 Physical volume file의 needle에는 삭제 플래그를 설정하지만, 인덱스 파일은 업데이트하지 않는다.
      • 추가적인 동기적인 디스크 쓰기를 피하고, 쓰기나 삭제가 좀 더 빠르게 끝나도록 해준다.
    • 인덱스 레코드가 없는 needle (orphan)이 발생할 수 있음.
      • 재기동을 할 때 orphan에 해당하는 인덱스 레코드의 추가 작업을 수행.
      • 인덱스의 마지막 레코드는 볼륨 파일의 마지막 orphan이 아닌 needle임.
      • 재기동이 완료되면 인덱스 파일만을 사용해서 In-memory 맵핑을 초기화.
    • 삭제된 사진이지만 인덱스 레코드는 이를 반영하지 않는 경우가 발생할 수 있음.
      • 삭제된 사진을 Physical volume으로부터 가져오더라도 전체 needle을 읽으면 삭제 플래그를 검사할 수 있으므로, 그 때 In-memory 맵핑을 업데이트하고 캐시에 오브젝트가 없다고 응답.
  • 파일시스템
    • 현재는 Extent 기반의 파일시스템인 XFS를 사용.
      • 커다란 파일의 블록맵이 메인메모리에 저장되기 충분할 정도로 작다.
      • 효율적인 파일 preallocation을 제공하므로, fragmentation을 완화하고 블록맵이 커지는 것을 막아준다.
    • XFS를 사용해서 파일 시스템 메타데이터를 읽기 위한 디스크 오퍼레이션을 제거할 수 있다.
    • 예외적으로는 사진 데이터가 extent나 RAID stripe 가장자리에 걸쳐져있는 경우 1번 이상의 디스크 오퍼레이션을 필요로 한다.
      • Haystack은 1GB extent를 preallocation하고 256KB RAID stripe size를 사용하므로 실제로는 그런 경우는 드물다.

3.5. Recovery from failures

  • Detection
    • 적극적으로 문제가 있는 Store 장비를 찾기 위해서, 피치포크(pitchfork)라는 주기적으로 Store 장비의 상태를 체크하는 백그라운드 작업을 실행한다.
    • 각 Store 장비로의 접속을 원격에서 체크하고, Volume file의 가용성과 실제로 데이터를 읽는 것이 가능한지 체크한다.
    • 어떤 Store 장비가 일관되게 체크에 실패한다면  피치포크는 자동적으로 그 Store 장비에 있는 모든 Logical volume을 read-only로 표시한다.
  • Repair
    • 한달에 몇 번 정도 전체 동기화 (bulk sync)를 필요로 하는 상황이 있는데, Store 장비의 데이터를 복제본의 Volume file을 이용해 리셋해야하는 경우다.
    • 전체 동기화되는 데이터의 양은 각 Store 장비의 NIC 속도보다 order of magnitude로 크기 때문에 복구까지 몇시간이 걸릴 수 있다.
      • (나의 계산: 1Gbit하에서 10MB/s (10%)를 쓸 수 있는 상황이라면 10분 내에 복구하려면 10MB x 600sec = 6TB 정도. 1MB x 600 sec이라면 600GB.)

3.6. Optimizations

3.6.1 Compaction

  • 삭제되거나 업데이트에 의해 중복된 needle에 의해 사용되는 공간을 되찾기 위한 과정으로, 중복되거나 삭제된 엔트리를 skip하면서 needle을 새로운 파일로 복사함으로써 Volume file을 compaction한다.
  • Compaction 과정 중에 발생하는 삭제는 원래의 Volume file과 새로 빌드하는 Volume file 양쪽으로 적용된다.
  • 이 과정이 파일의 끝까지 진행되면 추가적인 수정을 블록하고 파일과 In-memory 맵핑을 atomic하게 swap한다.

3.6.2 Saving more memory

  • 플래그는 삭제 용도로만 사용하고 있기 때문에, In-memory record의 offset을 0으로 설정함으로써 삭제를 표현하고 플래그 필드는 제거.
  • 메인 메모리에는 쿠키를 저장하지 않고, 디스크로부터 니들을 읽은 후에만 쿠키를 체크한다.
  • 현재는 사진 당 10 bytes의 메모리를 사용함.
    • 하나의 이미지에 대해 4개의 사이즈를 유지하므로, 키 (8 bytes) + alternate key (4 byte) x 4 + data sizes (2 bytes) x 4 = 32 bytes
    • 해시 테이블에 의해 이미지당 2 bytes의 오버헤드.
    • 리눅스의 xfs_inode_t는 536 bytes임.

3.6.3 Batch upload

  • 디스크는 커다란 sequential write일 경우 성능이 좋으므로, 가급적이면 batch upload를 하려고 노력함.
  • 사용자의 앨범 업로드

4. Evaluations

4.1. Characterizing photo requests

  • 사용자는 매일 수백만개의 사진을 업로드함.
  • 옛날 것보다 최근에 업로드된 사진이 더 POPULAR함.

4.1.1. Features that drive photo requests

News Feed와 album이 98%의 Facebook request임.

  • 빠른 popularity 감소는 CDN/Cache가 popular content의 호스팅에 매우 효율적일 것임
  • Longtail 그래프는 무시할 수 없는 수의 리퀘스트가 캐시로 다룰 수 없음을 의미

4.1.2 Traffic Volume

  • Daily Uploaded: ~120 M
  • Haystack Photo WrittenL ~1.44 B (12배 = 4 sizes, 3 locations)
  • Photo Viewed: 80-100 B
  • Haystack Photo Read: 10 B

4.2. Haystack Directory

Hashing policy는 read-write를 잘 분산하고 있음.

4.3. Haystack Cache

80% 정도의 hit rates

4.4. Haystack Store

4.4.1 Experimental Setup

  • 2U storage blade
  • 2 hyper-threaded quad-core Intel Xeon CPUs
  • 48GB memory
  • hardware raid controller with 256-512MB NVRAM
  • 12 x 1 TB SATA drives
  • RAID-6 partition
    • 9TB of capacity
    • 적절한 redundancy와 뛰어난 읽기 성능, 낮은 스토리지 비용.
    • NVRAM write-back cache가 RAID-6의 write performance 저하를 완화
    • Store 장비에서의 캐싱은 비효율적이므로 NVRAM은 쓰기 용도로만 사용
  • Crash나 Power loss 시의 data consistency를 위해서 disk cache(?)는 disable.

4.4.2 Benchmark Performance

  • Randomio
    • random 64KB reads, direct I/O (sector aligned requests)
    • 읽기 throughput의 베이스라인 설정.
  • Haystress
    • buffer cache의 영향을 줄이기 위해 커다란 이미지 셋에 대한 랜덤 읽기를 사용.
    • Workload A randoms reads to 64KB on Store machine with 201 volumes
      • 770.6 qps, 85% of the raw throughput / 17% higher latency
  • 오버헤드의 원인
    • Haystack은 파일시스템 위에서 동작.
    • 디스크 읽기는 전체 needle을 읽기 위해 필요한 64KB보다 큼.
    • RAID-6 device stripe size에 align되지 않았을 가능성이 있으나, 적은 확률일 것임.
    • 인덱스 액세스, checksum 계산 등으로 인한 CPU 오버헤드.

4.4.3 Production workload

  • Multi-write latencies are very flat and stable
    • NVRAM allows us to write needles async and issue a single fsync to flush the volume file once the multi-write is complete
  • Read performance impacted by
    • number of photos stored on the machine
    • cached in the Cache (for read-only, buffer cache would be more effective)
    • recently written photos are usually read back immediately
  • CPU idle time varies 92-96%

Chef (2014)

우연히 한국에서 돌아오는 비행기에서 보게 된 영화입니다. 영화 자체는 편하게 볼 수 있는 보통의 영화지만, 개인적으로는 와닿는 면이 많았던 영화였습니다.

어느 날 주인공인 칼 캐스퍼가 셰프로 있는 레스토랑에 유명한 요리비평가가 찾아오기로 합니다. “예술가가 되는 건 네 시간에나 해. 여긴 내 레스토랑이야.”라는 레스토랑의 주인에 맞서보지만, 결국 새로운 요리 대신 인기 요리를 만들게 되고 그 때문인지 요리비평가가 다녀간 후에 최악의 평이 실리게 됩니다. 더 나은 요리를 만들 수 있다는 자신감 때문에 다시 한번 요리비평가에게 도전을 하지만, 요리비평가가 찾아오는 날 칼 캐스퍼는 주인과 맞서다 레스토랑을 나오게 됩니다. 실직 후 고생을 하다가 여러 사람들의 도움 끝에 푸드트럭을 통해서 성공을 하게 된다는 이야기입니다.

영화 내용 자체는 가벼운 편입니다. 전반부는 유머를 잃지않으면서도 진지한 사건들이 일어나면서 꽤나 흥미로왔는데, 후반부는 이러한 사건의 실타래가 풀리는 과정들이 흥미롭다기 보다는 그저 사건들이 흘러가는 형태인 것 같습니다.

등장인물들 하나하나의 면면을 들여다보면, 우선 레스토랑 주인은 예술적인 요리나 이를 통한 개인의 명성보다는 전통적으로 인기가 있는 요리와 이를 찾아주는 고객들을 우선시 합니다. 레스토랑 주인 입장에서 보면 자신이 모든 것을 투자하고 고용한 사람들을 자신의 의지에 따라 다루고 싶어하는 것에 크게 잘못된 것은 없습니다. 칼 캐스퍼는 지금까지 자신의 능력을 인정받아 어느 정도의 명성도 있고 주방에서의 리더 – 셰프로서의 자리를 가지고 있지만, 우연히 더욱 큰 기회를 놓치고 싶지 않고 자신의 능력을 최대한 발휘하고 이를 통해 명성을 얻고 싶어합니다. 요리비평가의 악평이 실린 후 전아내나 레스토랑의 매니저인 몰리는 고집 센 레스토랑 주인 아래에서 행복하지 않은 상태에서 계속 요리하기 보다는 푸드트럭을 시도해볼 것을 제안하지만, 칼 캐스퍼는 (아마도) 자신의 능력에 대한 신뢰와 자존심 때문에 이를 거절합니다.

푸드트럭을 시작한 후에 칼 캐스퍼는 두가지의 행복을 찾습니다. 하나는 자신이 만들고 싶은 요리를 자신의 요리를 즐겁게 먹어주는 사람들을 위해 만드는 것. 다른 하나는 항상 ‘나중’으로 미뤄놨던 아들과 약속한 여행을 하며 서로를 이해하고 교감하는 것.

영화의 결말에 이르러 칼 캐스퍼는 큰 성공을 거두게 되지만, 인생이 항상 이렇게 쉽게 풀리지는 않겠죠. 푸드트럭을 한다고해서 성공하는 것도 아니거니와, 모두가 나가서 푸드트럭을 할 수 있는 것은 아닐겁니다. 하지만, 다른 사람들의 기대와 자신의 자존심 때문에 자신의 행복을 무시하고 계속 일해서는 안된다는 결론을 이 영화를 통해 얻을 수 있었습니다.

Timestamps in Message-Passing Systems That Preserve the Partial Ordering

Fidge, C.J., Timestamps in Message-Passing Systems that Preserve the Partial Ordering, Proc. 11th Australian Comp. Sci. Conf., 1988, pp. 56-66.

Timestamping is a common method of totally ordering events in concurrent programs. However, for applications requiring access to the global state, a total ordering is inappropriate. This paper presents algorithms for timestamping events in both synchronous and asynchronous message-passing programs that allow for access to the partial ordering inherent in a parallel system. The algorithms do not change the communication graph or require a central timestamp issuing authority.

이 논문은 Vector Clock으로 알려진 개념을 소개하고 있다. Vector Clock은 [Fidge 1998]과 [Mattern 1998]에서 독립적으로 고안된 알고리즘인데, Fidge의 논문쪽이 좀 더 읽기 쉬운 편이라고 한다.

Limitation of Lamport’s logical clock

Clock Condition. For any events a, b:
if a → b then C(a) < C(b).

Lamport가 정의한 논리적 시계는 두 사건 사이의 happened-before 관계가 있다면 이를 반영하는 시계를 정의하고 있습니다. 그리고 이를 이용해 임의의 완전순서를 정의하고 있습니다. 이 완전순서는 임의의 프로세스 사이의 순서를 이용하고 있으므로 사건들을 정렬할 수 있는 방법 중의 임의적인 한 방법이고, 논리적 시계 이상의 어떤 정보가 추가되지는 않습니다.

Lamport가 정의한 논리적 시계의 문제는 이 논리적 시계를 통해서 사건들 사이의 인과성 (causality)를 알아낼 수 없다는 것입니다. 즉, C(a) < C(b)라고 해서 a  b라고 말할 수 없는 것입니다. 구체적으로 말해, C(a) < C(b)가 의미할 수 있는 것은 a와 b 사이에 happend-before 관계가 있는 것, 즉  a  b인 경우와, a와 b 사이에 happend-before 관계를 판단할 수 없고 b가 a에 대해 happened-before가 아닌 것, 즉 b ↛ a인 경우가 있습니다.

Vector Clock

Vector Clock이라는 단어를 논문에서 사용하고 있지는 않지만, 그 단어가 의미하듯이 논리적 시계의 타임스탬프를 integer가 아니라 다음과 같이 프로세스 수 만큼의 타임스탬프를 가진 배열로 대체하고 있습니다.

[c1, c2 … cn]

그리고 이 타임스탬프를 유지하기 위한 알고리즘은 아래와 같습니다. 타임스탬프가 배열이 되었다는 것 이외에 Lamport의 알고리즘과 큰 차이가 없다고도 얘기할 수 있겠지만, 주의를 기울여야 하는 부분은 메시지를 수신하는 프로세스에서는 메시지를 송신한 프로세스에 해당하는 타임스탬프 배열 항목의 값만을 증가시킨다는 것입니다.

Rule RA 1: Initially all values are zero.

Rule RA 2: The local clock value is incremented at least once before each atomic event

Rule RA 3: The current value of entire timestamp array is piggybacked on every outgoing signal

Rule RA 4: Upon receiving a signal, a process sets the value of each entry in the timestamp array to be the maximum of the two corresponding values in the local array, and in the piggybacked array received. The value corresponding to the sender, however, is a special case and is set to be one greater than the value received (to allow for transit time), but only if the local value is not already greater than that received (to allow for signal “overtaking” as described below), i.e.

q?other_array; /* receive timestamp array from process q */

if local_array[q] <= other_array[q] then
    local_array[q] := 1 + other_array[q];
for i := 1 to n do
    local_array[i] := max(local_array[i], other_array[i]);

Rule RA 5: Values in the timestamp arrays are never decremented.

이 논문에서는 설명하고 있지 않지만, 이러한 알고리즘으로 얻어지는 타임스탬프의 의미는 수신한 메시지에 근거해서 추측할 수 있는 가장 정확한 송신 측의 타임스탬프라는 것입니다. 또한, 수신한 프로세스에서 발생할 현재의 사건에 대해 happened-before 관계에 있는 송신 측의 프로세스의 가장 마지막 사건의 타임스탬프이기도 합니다.

이러한 타임스탬프 배열은 다음과 같이 비교될 수 있습니다.

각각 프로세스 p, q에서 실행된 사건 e, f를 ep, fq로 나타내고, 각 사건에 대한 타임스탬프 array를 Tep, Tfq, 그 타임스탬프 배열 중 프로세스 p에 해당하는 타임스탬프를 Tep[p], Tfq[p] 라고 할 때,

ep → fq iff Tep[p] < Tfq[p]

여기서 주목할 점은 iff 즉, 사건의 happened-before 관계와 타임스탬프의 대소 관계가 동치관계라는 것입니다. 임의의 두 사건이 주어졌을 때 인과성이 있는지 여부와 어떤 사건이 어떤 사건에 대해 인과성이 있는지를 판단할 수 있습니다.

ep ↔ fq if Tep[p] ≮ Tfq[p] and Tfq[p] ≮ Tep[p]

타임스탬프 사이의 대소 관계가 어느 방향으로도 성립하지 않는다면 두 사건은 동시적(concurrent)하다고 얘기할 수 있습니다.

Applications

그렇다면 논리적 시계를 통해서 인과성을 알아내는 것은 왜 필요한가에 대해서 이 논문이 예로 들고 있는 것 중 하나는 여러 프로세스들에 의해서 저장되는 상태의 스냅샷들에 타임스탬프를 이용해서, 전체 프로그램 상태에 대해 정상적인 상태인지 검사를 할 수 있고 이를 통해 역실행 (reverse execution), 에러의 복구, 롤백 등이 가능하다는 것입니다. 실제로 이후에 발표된 Dynamo나 Riak 등 Vector Clock을 이용하는 것으로 알려진 시스템에서는 동시적인 쓰기 등에 의해 어떤 데이터에 대해 2개 이상의 복제본이 발생했을 때 이를 해소하기 위해서 인과성을 활용하고 있는 사례를 볼 수 있습니다.

References

  • [Fidge 1998] Fidge, C.J., Timestamps in Message-Passing Systems that Preserve the Partial Ordering, Proc. 11th Australian Comp. Sci. Conf., 1988, pp. 56-66.
  • [Mattern 1998]  Mattern, F. Virtual time and global states of distributed systems. Proc. “Parallel and distributed algorithms” Conf., (Cosnard, Quinton, Raynal, Robert Eds), North-Holland, 1988, pp. 215-226.

Spotify's Engineering Culture

Spotify engineering culture (part 1) from Spotify Labs

이미 잘 알려진 서비스인 Spotify는 2008년에 창업해 2010년에 어느 정도 규모의 서비스 (1000만 사용자)에 도달, 2013년 연간 활성 사용자가 2400만명인 서비스이고, 현재 회사의 규모는 1200명 수준의 조직으로, 이제는 어느 정도 성숙해져가고 있는 엔지니어링 조직을 가지고 있는 회사라고 말할 수 있을 것 같습니다.

현재 몸을 담고 있는 회사의 문화와도 닮은 부분이 많이 있어서 공감도 되고, 두고두고 엔지니어링 문화의 지향점에 대해서 생각할 수 있는 기회가 되는 듯 해서 정리를 한번 해둡니다. 불과 10분 남짓한 비디오이므로, 엔지니어링 문화에 관심이 있다면 비디오를 반드시 한번 쯤은 시청해두면 좋을 듯 합니다.

1. Make Rules Optional

초기에는 Scrum을 사용하는 팀 문화를 가지고 있었다고 하나, 어느 순간 이러한 프랙티스들이 오히려 방해가 되었다고 합니다.

make_rules_optional

그래서, 규칙을 강제하지 않고, 프랙티스 보다는 원칙, Process Master보다는 Servant Leader를 강조하는 문화를 도입했다고 합니다.

principles_over_practices

2. Autonomous Squad

Scrum Team이었던 조직을 Squad라고 이름을 바꾸었다고 하는데요. (이름이 참 마음에 드네요!) Squad의 핵심은 자율성(autonomy)입니다. Squad는 보통 8명 이하의 작은 조직이지만, cross-functional한 조직으로 디자인, 개발, 디플로이, 유지보수, 운영에 이르기까지 end-to-end responsibility를 가지고 있다고 합니다.

autonomous_squads

Squad는 미션이나 관련된 제품에 대한 전략 등의 장기적인 미션을 가지고 있으면서도, 무엇을 어떻게 개발할 지(what to build, how to build)에 대한 단기적인 목표도 분기별로 정해진다고 합니다.

사무실은 협력을 최대한 도와줄 수 있도록 최적화되어있다고 합니다. Squad 내에서 팀원들은 서로의 모니터를 쉽게 볼 수 있도록 배치되어있으며, 계획 등을 할 수 있는 라운지가 있고, 모든 벽은 화이트보드로 되어있다고 하네요.

3. Autonomy vs. Alignment

자율성이 중요한 이유로 2가지 이유를 들고 있습니다. 하나는 동기부여(motivating)이고 다른 하나는, 결정이 내부에서 이루어지고, 의존 관계나 조율 등을 위해 다른 조직을 기다릴 필요가 없기 때문에 빠르다(fast)는 것입니다.

그렇다고 해서 회사와는 아무런 상관도 없이 흘러가는 조직이 아니라, Loosely coupled, Tightly aligned squads를 지향합니다. (Aligned autonomy!)

Autonomy와 Alignment가 서로 반대 극에 있는 개념이 아니라, 아래와 같이 다른 차원의 문제로 해석하고 있고, 오히려 Alignment로 인해 Autonomy가 가능해진다고 얘기하고 있습니다.

리더의 책임은 무엇이 해결해야할 문제이고, 왜 해결해야하는지에 대해 커뮤니케이션하는 것, Squad의 책임은 가장 좋은 해결책을 찾기 위해 서로 협력하는 것이라고 얘기하고 있습니다.

alignment_vs_autonomy

4. Cross-pollination over Standardization

pollination이란 식물의 (생식 수단으로서의) 수분을 말하는 것인데요. 어떠한 프랙티스나 도구를 전체 조직으로 표준화해버리기 보다는 하나의 조직에서 좋은 프랙티스를 도입하거나 도구를 개발하고, 이를 다른 조직에서도 채용하기 시작하고, 그것을 지원하고, 결국 de facto 표준이 되는 문화를 얘기하고 있습니다. 일관성(consistency)와 유연성(flexibility) 사이의 좋은 trade-off를 찾는다고 하네요.

cross_pollination

5. Internal Open-source Model

Spotify 내의 각각의 시스템들은 가능한한 작고 서로 decouple되도록 유지하려고 한다고 합니다. 각 시스템들은 하나 또는 몇몇 squad가 담당하고 있다고 하는데요.

만약 어떤 squad가 다른 squad가 담당하고 있는 시스템의 개선이 필요하다면 그 squad에 부탁하면 되지만, 만약 그 squad가 너무 바쁘다면 이를 기다릴 필요가 없다고 합니다. 오픈 소스 모델로 직접 수정을 하고 peer review를 받으면 되는 것 같습니다.

internal_open_source_model

6. People over *

동기부여(motivation)에 집중을 한 이후에 만족도 조사가 상승했다는 결과를 얘기하고 있습니다.

7. Community over Structure

Squard들은 위에서 얘기한대로 cross-functional 팀이지만, 역량 분야 (competency area)에 따른 Chapter라는 조직이 있는 매트릭스 조직 (matrix organization)으로, 자신의 팀장을 바꾸지 않고도 Squad를 바꿀 수가 있다고 합니다.

그리고, Squad나 Chapter와는 상관없이 서로 관심사를 공유하는 사람들은 Guild라는 가벼운 레벨의 interest group을 구성한다고 합니다.

tribe_structure

계층적인 조직 구조(structure)보다는 좀 더 커뮤너티(community)와 같은 문화를 지향하는 것을 다음과 같은 말로 요약하고 있습니다.

“If you need to know exactly who is making decisions, you are in the wrong place.”

8. Small, Frequent, Decoupled Release

릴리즈가 정말로 힘들었다라고 하는 경험을 돌아보면 많은 경우 장기간에 걸친 커다란 릴리즈였던 경우였기 때문에, 저도 작은 릴리즈를 굉장히 선호하는 편인데요. 이제는 이러한 방식이 여러 회사들에서 자리잡고 있는 것 같습니다.

small_frequant_releases

여러 squad의 결과물이 하나의 제품 화면을 구성하는 경우에도, 이를 별도로 릴리즈할 수 있도록 하고 있다고 합니다. UI 또는 시스템적으로 먼저 의존 관계를 제거화고 이를 유지할 수 있어야만 가능한 이야기라고 생각하기 때문에 굉장히 놀라운 이야기로 들리네요.

decoupled_releases

9. Self-service model

하나의 조직에서 다른 조직으로 서비스를 제공하는 방식으로 다른 조직으로 책임을 완전히 넘기는 것이 아니라, 방법을 마련해주고 실제로 실행은 그 조직에서 하는 방식입니다. 커다란 회사에서는 오히려 생존을 위해서 내부 제품을 개발하는 조직도 내부 서비스 조직으로 탈바꿈하는 경우가 있었는데, 다시 생각해볼 문제인 것 같네요. 조직이 커져가는 과정에서 어떤 형태로든 내부 서비스에 대한 concern의 분리는, 그 품질에 나쁜 영향을 준다고 생각하고 있는데, Self-service model도 그 대안 중 하나가 될 수는 있겠네요.

self_service_model

10. Release trains + Feature toggles

개발 완료되지 않은 기능들을 릴리즈에 포함하지만 이를 서비스에 나타나지 않도록 기능을 on/off할 수 있다고 합니다. 완료되지 않은 기능을 릴리즈하는 것이 조금 이상하게 생각될 수 있겠지만, 이를 통해 좀 더 일찍 통합 문제 (integration problems)를 발견할 수 있고, 적지 않은 개발 비용이 발생하는 code branch를 최소화할 수 있다고 얘기합니다.

release_train

11. Trust > Control

최근 수년간 ‘Agile at scale’이 유행하고 있었는데, 이를 위해서는 ‘Trust at scale’이 필요하다고 얘기하고 있습니다. 두려움은 단지 신뢰를 없애는 것이 아니라, 혁신도 불가능하게 만든다고 얘기하고 있습니다. (fear doesn’t just kill trust, it kills innovation.)

trust_over_control

Time, Clocks, and the Ordering of Events in a Distributed System

Leslie Lamport. 1978. Time, clocks, and the ordering of events in a distributed system.Commun. ACM 21, 7 (July 1978), 558-565.

The concept of one event happening before another in a distributed system is examined, and is shown to define a partial ordering of the events. A distributed algorithm is given for synchronizing a system of logical clocks which can be used to totally order the events. The use of the total ordering is illustrated with a method for solving synchronization problems. The algorithm is then specialized for synchronizing physical clocks, and a bound is derived on how far out of synchrony the clocks can become.

이 논문에 대해서는 Paxos Made Simple에서 이미 아래와 같은 소개를 한 적이 있습니다.

Leslie Lamport는 분산 컴퓨팅 분야에서는 너무나 유명한 분이기 때문에 따로 설명할 필요가 없을 정도입니다. 예를 들어, 1978년에 출판된 “Time, Clocks, and the Ordering of Events in a Distributed System”과 같은 페이퍼는 인용 회수로 볼 수 있는 그 영향력 뿐만 아니라 OS 수업의 읽기 과제로도 빠질 수 없는 그야말로 seminal work입니다.

1. “Happened before” 관계

가장 먼저, “Happened before” 관계라는 분산시스템 내에서 사건(event)들의 순서를 표현할 수 있는 부분순서(partial ordering)를 제안하고 있습니다.

“Happened before” relation은 분산시스템에서 구현이 어려운 물리적 시계 (physical clock)를 사용하지 않더라도 사건들의 순서를 표현할 수 있음을 보여주고 있습니다. 즉, 사건이 발생한 전역적으로 통용되는 시각을 알지 못해도 우리는 자연스럽게 사건의 순서를 정할 수 있습니다.

또한, 서로 다른 프로세스 사이에서 메시지를 주고 받을 경우에 사건 사이의 인과성(causality)이 발생하는 것을 다음과 같은 정의에 담고 있습니다.

Definition. The relation → on the set of events of a system is the smallest relation satisfying the following
three conditions:

  1. If a and b are events in the same process, and a comes before b, then a → b.
  2. If a is the sending of a message by one process and b is the receipt of the same message by another process, then a → b.
  3. If a → b and b → c then a → c.

Two distinct events a and b are concurrent if a ↛ b and b ↛ a. Assume a ↛ a for any event a. So → is an irreflexive partial ordering on the set of all events in the system.

2. Logical Clocks

논리적 시계는 하나의 프로세스 내의 각 사건들에 대해 단조 증가하는 숫자를 할당하는 것으로 볼 수 있으며, 물리적 시계가 아니라 사건이 발생한 순서에 기초해야 합니다.

Clock Condition. For any events a, b:
if a → b then C(a) < C(b).

“Happened before” 관계의 정의에 따라, 각 프로세스는 사건이 발생할 때마다 증가하는 타임스탬프를 부여하며, 프로세스 사이에 메시지를 송신할 때 타임스탬프를 함께 송신하며, 메시지를 수신하는 측에서는 수신한 타임스탬프보다 더 큰 타임스탬프를 새로운 사건에 할당합니다.

3. Ordering the Events Totally

위에서 정의된 논리적 시계만으로는 분산시스템 내의 사건들의 완전순서(total ordering)는 불가능하기 때문에, 프로세스 사이의 임의의 순서(!)를 도입해, 완전순서를 만들 수 있습니다.

In case two or more events occur at the same time, an arbitrary total ordering ≺ of processes is used. To do this, the relation ⇒ is defined as follows:

If a is an event in process Pi and b is an event in process Pj , then a ⇒ b if and only if either:
i. Ci<a> < Cj<b> or
ii. Ci<a> = Cj<b> and Pi ≺ Pj

이렇게 정의된 완전순서를 이용해 분산시스템에서의 상호배제(mutual exclusion) 문제를 해결하는 방법을 제시하고 있습니다.

간단히 얘기하면, 어떤 프로세스가 자원을 요청할 때는 자신의 타임스탬프를 함께 다른 모든(!) 프로세스들에게 전송하고, 이 자원의 요청은 요청한 프로세스 뿐만 아니라 모든 프로세스의 큐에 위에서 정의된 완전순서대로 정렬됩니다. 이 큐에서 가장 앞에 있는 자원 요청이 자원을 획득해야한다고 볼 수 있는데, 모든 프로세스들이 동일한 큐를 유지해야하기 때문에, 자원 획득을 위해서는 모든 다른 프로세스들로부터 receipt 메시지를 수신한 조건에서만 자원 획득이 가능합니다. 또한, 다른 프로세스의 자원 요청에 대한 응답과 자신의 자원 요청의 (타임스탬프의 순서는 올바르다고 하더라도) 전송 순서가 바뀌는 경우는 두 프로세스 사이의 통신은 순서대로 일어난다는 가정에 의해 발생하지 않습니다.

이 구현은 1개 이상의 프로세스의 실패나 메시지의 소실 등을 가정하고 있지 않기 때문에 현실적으로 사용할 수 있는 알고리즘은 아니지만, 분산시스템에서의 완전순서의 유용성을 보여주고 있다고 생각합니다. 그리고, Lamport가 이후에 제안한 Paxos가 바로 현실적인 환경 하에서의 완전순서를 보장하기 위한 방법을 제공하고 있는 것으로 보입니다.

4. Anomalous Behavior

위에서 제시한 상호배제 알고리즘에서 사건 사이의 인과성이 외부화됨으로써 발생할 수 있는 문제를 제시하고 있습니다. 예를 들어, 자원 요청 A를 한 후, 전화를 걸어 다른 컴퓨터에서 자원 요청 B를 한 경우, 자원 요청 A와 자원 요청 B 사이에는 실제로 인과성이 존재하지만, 논리적 시계의 체계는 이를 인지하지 못하므로, 자원 요청 B가 더 낮은 타임스탬프를 획득해 먼저 자원을 획득할 수 있다는 것입니다.

이를 해결하기 위한 방법으로 2가지 방법을 제시하고 있는데, 첫번째는 “happened-before” 관계에 필요하지만 외부화된 정보를 시스템 내로 도입하는 것입니다. 즉, 자원 요청 B를 하는 사용자에게 자원 요청 A 보다 더 이후의 타임스탬프를 발급하도록 자원요청 A의 타임스탬프를 전화를 통해 알려주는 방법 등으로 논리적 시계 체계를 유지하는 책임을 부여하는 것입니다.

다른 방법은 외부화된 사건들 사이의 관계를 포함해 모든 사건들을 정렬할 수 있는 물리적인 시계의 체계를 구성하는 것입니다. 이 시계들은 다음의 Strong Clock Condition을 만족해야 합니다.

Let S be the set of all system events and S be the set containing S along with relevant events external
to the system. Let ↪ denote the “happened before” relation for S.

For any events a, b in S: if a ↪ b then C<a> < C<b>.

5. Physical Clocks

Strong Clock Condition을 만족하기 위해서는 물리적 시계는 다음과 같은 조건을 만족해야합니다.

Let Ci(t) denote the reading of clock Ci at physical time t. Assume that Ci(t) is a continuous, differentiable
function of t except for isolated discontinuities introduced by clock resets.
PC1. There exists a constant k << 1 such that for all i: |dCi(t) / dt – 1| < k.
PC2. For all i, j : |Ci(t) – Cj(t)| < e.

PC1은 물리적 시계가 가는 속도가 물리적 시간이 흐르는 속도와 일정 오차 범위 내에 있다는 것을 의미합니다. 일반적인 수정 발진 방식의 시계의 경우, k는 약 10-6정도로 언급하고 있으며, PC1 자체는 만족되는 것으로 가정하고 있습니다.

한편, PC2는 물리적 시계들 사이의 오차가 일정 범위 내에 있다는 것을 의미합니다. PC2를 보장하기 위해서 물리적 시계의 보정을 위한 구현 방법을 제시하고 있습니다.

Let vm = t’ – t be the total delay of m which is unknown to the receiving process. Let µm be some minimum delay >= 0 known by the receiving process such that µm <= vm.

IR2′. a. If Pi sends a message m at physical time t, then m contains a timestamp Tm = Ci(t).
b. Upon receiving a message m at time t’, process Pj sets Cj(t’) equal to max(Cj(t’ – 0), Tm +
µm).

메시지에 타임스탬프를 넣어서 보내고, 이를 수신하는 측에서는 메시지를 통해 받은 타임스탬프와 최소 통신 지연 시간 이후의 시각으로 시계를 재설정하는 방식이라고 할 수 있고, 이러한 구현 요구사항을 만족한다면, PC2를 만족하는 것을 증명할 수 있다고 합니다. 이 증명에서는 일정 시간 내에 메시지가 전체 프로세스 사이로 전송되는 상황을 가정하고 있으므로, 메시지를 주고 받지 않는 조건을 염두에 두고 있는 것 같지는 않습니다.

한편, 최소 지연시간에 해당하는 µm은 일반적으로 거리와 빛의 속도로 계산할 수 있는 수준의 값으로 언급되고 있습니다. 그리고, 주어진 µm에 대해 k와 e가 얼마나 작아야 하는지에 대한 계산 방법도 설명하고 있습니다.

현실적으로는 이 논문에서 정의된 Physical Clock은 항상 가장 빠른 시계에 맞춰지게 되므로 실제 시간 (physical time)보다 더 빨라지게 되겠지만, 분산시스템의 동기화 문제를 해결하는 능력과는 무관하다고 할 수 있을 것 같습니다.

6. Closing

이 논문은 분산시스템의 문제에 대한 이해에 가장 중요한 사고 도구로 사용할 수 있는 중요한 개념들을 정의하고 있는 것 같습니다. 내용 자체를 정확하게 이해했는지의 여부를 차치하더라도, 이러한 개념이 마음에 와닿기 위해서는 몇 번은 더 읽어봐야 할 것 같습니다.

다음에는 Vector Clock에 관한 논문인 C. Fidge의 Timestamps in Message-Passing Systems That Preserve the Partial Ordering을 읽어볼 예정입니다.

Actors in Scala

 

Actors in ScalaActors in Scala by Philipp Haller and Frank Sommers

150페이지 남짓의 이 책은 Scala의 Actors 라이브러리에 대한 책이다. 이 책의 저자 중 한명인 Philipp Haller는 Scala Actors 라이브러리의 저자다.

이 책은 Scala Actors를 다루는 것에 대한 기본적인 내용과 Exception/Termination handling, Actor 실행 방법의 customization, Remote Actors를 상세하게 다루고 있다. 원래는 Actor를 사용하는 패턴도 기대하고 있었지만 MapReduce와 같은 몇가지 예시 정도 외에 좀 더 완전한 내용의 것은 찾을 수 없었다. 하지만, 기본적인 Actors 라이브러리의 기본적인 개념을 익히는데에는 좋은 책일 듯 하다.

한가지 문제라면, Scala 2.10 부터는 Actors 라이브러리가 deprecated 되었고, Akka로 대체되었다는 것이다. Scala Actors의 자세한 히스토리는 잘 모르지만, Akka는 Scala Actors와 커다란 차이는 없는 반면 더욱 일관성이 있는 느낌이 든다. Scala Actors와 Akka의 차이에 대한 사항은 Scala Actors Migration Guide를 참고하면 좋을 듯 하다.

Akka는 Java와 Scala 모두 지원하고 있기 때문에, 기존에 Java 위주의 프로젝트를 진행하고 있었지만 Scala 프로젝트도 함께 진행하기 위해 연동해야 하거나 Scala 프로젝트로 전환하는 경우의 통합 수단으로서, 기존의 language-agonostic RPC들, ZeroMQ 등의 대안으로 좋은 선택이 될 수 있지 않을까 생각해보고 있다.

소중한 것을 먼저 하라. (First things first)

최근 한달 동안 frustrating things를 지난 주에 적어 본 것이다.

1. 누군가가 찾아오거나 메신저로 물어보거나 메일을 보내온 일들을 처리해주다 보면, 일과 시간 내내 새로이 발견된 문제를 해결하는 문제를 처리하고 있거나, 아마도 다른 사람에게 갔어야 하거나 지금까지 몇번이나 반복되었던 듯 한 누군가의 질문에 답해주거나, 업무의 경과를 공유 또는 보고하는 문서나 메일을 쓰고 있다. 상사로부터 명시적으로 부여받은 소위 ‘본업’에 해당하는 일이나 중요하다고 생각하는 일은 어느새 아무도 방해하지 않는 밤이 되어서야 하게 된다. 또는 밤에도 그러지 못하는 경우도 있다.

2. 정작 ‘본업’을 할 시간이 생겨도 실제로 어떤 가치를 만들어내는 일 보다는, 그 일을 위한 일 – 이슈를 공유하거나 할 일을 정하기 위한 회의, 도구의 문제를 해결하는 일, 빌드 환경의 문제, pull request를 어떻게 할 지 정하는 문제 등을 해결하는 일 등에 들어가는 시간이 많다.

이렇게 문제를 정의한 후에는, 매일 아침 출근할 때마다 ‘오늘은 본업에만 집중할거야. 그리고 조금 여유가 생기면 내가 쓰고 싶었던 코드를 쓸거야.’라고 되새기지만, 그 전날과 완전히 동일한 하루를 보낸다. 이러한 일상의 문제들을 잘 처리하면서 자신의 ‘본업’도 잘하는 사람들도 주변에 있다고 생각하기 때문에 실은 이러한 반복적인 문제의 원인이 내 자신의 습관에 있는 것이 아닐까 이런 생각을 하면서 집으로 돌아온다. (내향적인 성격의 전형적인 결론)

이처럼 정확한 원인을 모르는 것에 대해 스트레스를 받는 것을 해결하는 방법 중 하나는 이렇게 생각을 정리해보거나, 느끼고 있는 것에 대해 다른 사람과 얘기를 하거나, 그냥 좋아하는 일을 하면서 쉬는 것이다. (그래서, 집에서 이 글을 쓰고 있다.)

그렇다. 누군가는 중요해질지도 모르는 급한 문제들을 살펴봐야 하고, 누군가는 누군가의 질문에 답해주어야 하고, 누군가는 문서를 잘 정리해야 하고, 이슈는 빠르게 공유되어야 하고, 원래 실무를 하는 과정에서는 여러가지 문제들이 발생하게 마련이다.

그런데, 좀 더 넓게 바라보면, 내가 하고 싶은 것은 다음과 같다.

– 많은 사람들에게 가치를 주는 중요한 일을 하고 싶다.
– 나의 취향과 호기심, 재미를 충족시켜주는 사람들과 일하고 대화 하고 싶다.
– 최대한의 역량을 발휘하면서 일하면서 성장하고 또 그 결과로 인정받고 싶다.
– 나의 행동을 통해 가족들이 행복할 수 있도록 해주고 싶다.
(누구나 바랄법한 목록 아닌가 싶지만, 사람들마다 미묘하게 다르다.)

잠깐씩은 ‘그래, 어쩔 수 없지~’ 하다가도 이 목록을 보다보면 진정 내가 원하는 것을 얻기 위해서는 뭔가 변화가 필요하다는 것을 알 수 있다. 그런데, 그 변화를 위한 길은 걱정이 되는 강한 용기와 의지가 필요한 매우 어려운 일인 것 같다.

예를 들어, 반복하는 단순한 운영 업무 대신 ‘이것을 반복하지 않도록 하는 일을 해보죠’라고 한다면 모든 사람의 환호성을 듣기는 어려울 것이다. 누군가가 열심히 만든 도구를 버리고 내가 쓰기 편한 도구를 쓰자고 한다면 수많은 그렇게 할 수 없는 이유들이 나열될 것이다.일부로 메신저 친구 등록을 하면서 질문을 해왔는데 만약 메일로 다시 보내달라고 한다면 저 사람 답답하게 일하네란 소리를 들을 것이다. 또는 그럴까봐 걱정을 해야할 것이다.

똑같은 문제로 힘들어 하고 분들은 어딘가에 많이 있을거라고 생각하지만, 참 쉬운 문제가 아니다. 일단 쓸데없는 오지랍이라도 줄여보려고 노력해야할 것 같다.

스티븐 코비 나쁜 놈.