Chapter 6. 키-값 저장소 설계

[minkukjo]

느낀 점

• CAP 정리... 직방에서 면접볼 때 물어봤었는데 제대로 대답을 못했다.. (이런걸 물어볼 줄이야;)
• 주로 NoSQL 저장소와 같이 분산 시스템을 설계 할 때 등장하는 개념이다.
• 데이터 일관성, 가용성, 파티션 감내라는 세가지 요구 사항을 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리다.
• 뭐 하나 취하려면 뭔가 하나를 포기해야한다는.. 고런 원칙이다.
• 벡터 시계 기법을 이용해서 버저닝을 하고 충돌을 감지하는 처리가 신기방기했고 AWS의 다이나모 DB가 이 기법을 사용한다는 것도 무척 신기했다. (심지어 매우 많은 버전의 순서쌍 개수가 생겨도 충돌 해소 과정에서 효율성이 낮아지는 문제가 없었다는 것도... 역시 갓마존)
• 분산 환경에서 노드간의 가용성을 높이는 알고리즘으로는 주키퍼에서 사용하는 Raft 알고리즘이라는 것도 있음.
• 실제 카산드라나 다이나모 DB의 사례를 들며 예시를 들어준 점이 좋았다!

[LOG-INFO]

끄적끄적

• CAP 이론
  • Consistency: 어떤 노드로 접속하던 언제나 같은 데이터 조회
  • Availability: 일부 노드에 장애가 발생하더라도 항상 응답
  • Partition Tolerance: 두 노드 사이에 네트워크 장애가 발생해도 시스템 계속 동작
  • CA, AP, CP
  • 하지만 네트워크 장애(P)는 피할 수 없는 문제로 여겨져 항상 Partition Tolerance를 지원하도록 설계되어야 함
    • 그래서 CA는 실제로 존재하지 않음
• 여러 키워드들이 나와서 견문을 넓히기 좋았음!
  • 데이터 다중화 어떻게 하는지 - Consistent Hash에서 시계방향으로 돌며 만나는 가상 노드 세 개 (중복 없이)
  • 데이터 일관성 어떻게 지키는지 - Quorum Consensus
  • 강한 일관성 보장: R + W > N
  • 강한 일관성이 보장되지 않음: R + W <= N
  • 빠른 읽기 연산 최적회: R=1, W=N (강한 일관성이 보장됨)
  • 빠른 쓰기 연산 최적화: R=N, W=1 (강한 일관성이 보장됨)
  • 일관성 모델
    • 강한 일관성
    • 약한 일관성
    • 최종 일관성
      • ex) DynamoDB, Casandra
    • 일관성 관련 문제 클라이언트가 풀어야 함
      • Versioning
      • Vector Clock
      • 버전X가 버전Y의 이전 버전인지 아닌지 쉽게 판단
      • 단점
        • 클라이언트 구현 복잡해짐
        • [서버: 버전] 순서쌍 개수가 굉장히 빨리 늘어남
        • 길이에 Threshold를 설정하고, 넘어가면 삭제
  • 장애 감지
  • 모든 노드 사이에 멀티 캐스팅을 통해 n개 이상의 서버가 서버A를 장애라고 표시하면 서버A에 장애 -> 효율 떨어짐
  • Gossip Protocol: 멤버십목록 (Server ID - HeartBeat Counter)
  • 일시적 장애 처리
  • Strict Quorum - 읽기/쓰기 연산 금지
  • Sloppy Quorum - 건강한 쓰기 서버 W개, 읽기 서버 R개 선정하여 대신 실행. 장애 서버 무시. 이후 복구되면 일괄 반영
  • 영구적 장애 처리
  • 이건 뭔 말인지 모르겠다.... 다시 읽어봐야지..
• 데이터 센터 장애 처리
  • 데이터 센터 다중화
  • AWS/GCP/Azure 등을 다중화한 사례 들어본 적 있음. 배민이었나...?
  • 좀 다른 얘긴데 배민은 PG사를 다중화함
    • 카드 결제 누르면 KCP NHN 토스페이먼츠가 임의 확류로 나온다고 함

      아 번역....

      박동카운터 <- heartbeat counter 쓰기 경로 <- Write Through 읽기 경로 <- Read Through