책너두 (데이터 중심 애플리케이션 설계) 18일차 (~220p)

요약

• 파티션 재균형화에 대한 내용을 이해함.
  • 데이터베이스 변화에 따른 노드와 파티션의 재균형화 과정이 필요함.
• 재균형화 전략에 대해 이해하게 됨
  • 재균형화할 때, 해시값에 mod N 연산을 하면 안됨
    • 노드 이동이 반드시 일어나므로 재균형화 비용이 커짐
  • 파티션 개수 고정 전략
    • 데이터셋 크기가 변경되면, 파티션 개수 설정하기 어려움
  • 동적 파티셔닝 전략
    • 전체 데이터 용량에 맞게 적절히 파티션 개수가 정해짐
    • 사전 분할을 통해, 초기 파티션 집합을 설정해야 함.
  • 노드 비례 파티셔닝 전략
    • 노드당 파티션 개수 비례 전략임.
    • 개별 파티션 크기가 상당히 안정적으로 유지됨.
• 자동 재균형화와 수동 재균형화 트레이드 오프를 알게 됨.
  • 재균형화는 손이 덜가지만, 재균형화 작업이 굉장히 중요한 작업이므로 장애 발생시 문제가 될 수 있음.
  • 따라서 재균형화 과정에 사람이 개입하는게 좋을 수 있음.
• 요청 라우팅에 대한 내용을 이해함
  • 구성 요소가 어떤 파티션에(=어떤 노드) 접속 해야하는지 알아야 함
• 병렬 질의 실행에 대해 알게 됨.
  • 분석용 데이터베이스에는 대규모 병렬 처리가 필요함

메모

파티션 재균형화

• 시간이 지나면 데이터베이스에 변화가 생김
  • 질의 처리량 증가로 인한 부하 처리를 위해 CPU를 추가
  • 데이터셋 크기가 증가해서 데이터셋 저장에 사용할 디스크와 램을 추가
  • 장비에 장애가 발생해서, 다른 장비로 역할을 넘겨야함.
• 위 변화가 생기면, 데이터와 요청이 한 노드에서 다른 노드로 옮겨져야 함.
  • 클러스터에서 한 노드가 담당하던 부하를 다른 노드로 옮기는 과정을 재균형화(rebalancing)라고 함.
  • 재균형화 후, 기대되는 요구사항이 있음.
    • 재균형화 후, 부하가 클러스터 내에 있는 노드들 사이에 균등하게 분배돼야 함.
    • 재균형화 도중, 데이터베이스는 읽기 쓰기 요청을 받을 수 있어야 함.
    • 재균형화가 빨리 실행되고, 네트워크와 디스크 I/O부하를 최소화할 수 있도록 노드들 사이에 데이터가 필요 이상으로 옮겨져서는 안됨.

재균형화 전략

• 파티션을 노드에 할당하는 방법이 몇 가지 있음.

쓰면 안 되는 방법: 해시값에 모드 N 연산을 실행(4)

• 앞서 키의 해시값 기준으로 파티셔닝 시, 사용 가능한 해시값의 범위를 나누는 방식이 있었음.
  • 모드(mod)연산을 쓰지 않는 이유는 노드 개수 N이 바뀌면 키가 노드 사이에 옮겨져야 함.
    • 예시 p210 참고
    • 키가 자주 이동하면 재균형화 비용이 지나치게 커짐.
    • 데이터를 필요 이상으로 이동하지 않는 방법이 필요함.

파티션 개수 고정

• 간단한 해결책으로 파티션을 노드 대수보다 많이 만들고 각 노드에 여러 파티션을 할당하는 것임.

• 클러스터에 노드가 추가되면, 새 노드는 파티션이 다시 균일하게 분배될 때까지 기존 노드에서 파티션 몇 개를 뺏어올 수 있음.
• 파티션은 노드 사이에서 통째로 이동하기만 함.
  • 파티션 개수는 바뀌지 않고, 파티션에 할당된 키도 변경되지 않음.
  • 유일한 변화는 노드에 어떤 파티션이 할당되는가 이다.
  • 파티션 할당 변경은 네트워크를 통해 대량의 데이터를 전송해야 하므로 시간이 걸림.
    • 데이터 전송이 진행 중인 동안, 읽기나 쓰기가 실행되면 기존에 할당된 파티션을 사용함.
• 클러스터에 성능이 다른 하드웨어가 섞여 있을 수 있음.
  • 성능이 좋은 노드에 파티션을 더 할당함으로써 더 많은 부하를 담당하게 할 수 있음.
• 보통 데이터베이스가 처음 구축될 때 파티션 개수가 고정되고 이후에 변하지 않음.
  • 이론적으로 파티션을 쪼개거나 합치는게 가능하지만 파티션 개수가 고정되면 운영이 단순해짐
    • 따라서 고정 파티션을 사용하는 데이터베이스는 파티션 분할을 지원하지 않는 경우가 많음.
    • 처음 설정된 파티션 개수는 미래에 증가될 것을 수용하기에 충분히 높은 값으로 선택해야 함.
      • 개별 파티션도 관리 오버헤드가 있으므로 너무 큰 수를 선택하면 역효과가 나타남
• 전체 데이터셋의 크기 변동이 심하면 적절한 파티션 개수를 정하기 어려움.
  • 각 파티션에는 전체 데이터의 고정된 비율이 포함됨.
    • 즉, 개별 파티션의 크기는 클러스터의 전체 데이터 크기에 비례해서 증가함.
      • 파티션이 너무 크면 재균형화를 실행할 때와 노드 장애로부터 복구할 때 비용이 큼.
      • 파티션이 너무 작아도 오버헤드가 너무 커짐
        • 파티션 개수가 딱 적당할 때 성능이 가장 좋지만, 파티션 개수는 고정돼 있는 상태에서 데이터셋 크기가 변하면, 적절한 크기를 정하기 어려울 수 있음.

동적 파티셔닝

• 파티션 경계가 고정돼 있는 것은 매우 불편함
  • 파티션 경계를 잘못 지정하면 모든 데이터가 한 파티션에 저장되고, 나머지 파티션은 텅 빌 수도 있음.
• HBase나 리싱크DB처럼 키 범위 파티셔닝을 사용하는 데이터베이스에서는 파티션을 동적으로 만듦.
  • ex) 파티션 크기 설정값을 넘어서면 파티션을 두 개로 쪼개 각각에 원래 파티션의 절반 정도의 데이터가 포함되게 한다.
  • 반대로 데이터가 많이 삭제되어 파티션 크기가 임곗값 아래로 떨어지면 인접한 파티션과 합쳐질 수 있음.
• 동적 파티셔닝은 파티션 개수가 전체 데이터 용량에 맞춰 조정되는 이점이 있음.
  • 데이터양이 작으면 파티션 개수가 적어도 되므로 오버헤드가 작음
  • 데이터 양이 거대하면, 개별 파티션의 크기는 설정된 최대치로 제한됨
• 빈 데이터베이스 파티션 경계를 어디로 정해야 할지에 대한 사전 정보가 없으므로 시작할 때는 파티션이 하나임.
  • 데이터 셋이 작을 때는 모든 쓰기 요청이 하나의 노드에 실행되고, 다른 노드들은 유휴 상태에 머물게 됨.
    • 이 문제를 완화하기 위해 HBase와 몽고DB 에서는 빈 데이터베이스에 초기 파티션 집합을 설정할 수 있게 함. (= 사전 분할(pre-splitting)이라고 함.)
    • 키 범위 파티셔닝의 경우, 사전 분할을 하려면 키가 어떤 식으로 분할될지 미리 알아야 함.
• 동적 파티셔닝은 키 범위 파티셔닝 뿐만 아니라 해시 파티셔닝에도 똑같이 사용 가능함.

노드 비례 파티셔닝

• 이 방법은 카산드라와 케타마(Ketama)에서 사용되는 방법임
• 노드당 할당되는 파티션 개수를 고정함.
  • 즉, 노드 대수가 변함이 없는 동안, 개별 파티션 크기가 데이터셋 크기에 비례해서 증가함
  • 노드 대수가 늘어나면 파티션 크기는 다시 작아짐.
  • 데이터 용량이 클수록 데이터를 저장할 노드도 많이 필요하므로 이 방법을 쓰면 개별 파티션 크기도 상당히 안정적으로 유지됨.
• 새 노드가 클러스터에 추가되면 고정된 개수의 파티션을 무작위로 선택해 분할하고, 각 분할된 파티션의 절반은 그대로 두고 다른 절반은 새 노드에 할당함.
  • 파티션을 무작위로 선택해서 균등하니 않은 분할이 생길 수 있지만, 여러 파티션에 대해 평균적으로 보면 새 노드는 기존 노드들이 담당하던 부하에서 균등한 몫을 할당받게 됨.
  • 파티션 경계를 무작위로 선택하려면 해시 기반 파티셔닝을 사용해야 함.
    • 이 방법은 일관성 해싱의 원래 정의에 가장 가깝게 대응함.

운영: 자동 재균형화와 수동 재균형화

• 재균형화를 자동화 해야할까 수동화 해야할까?
• 완전 자동 재균형화는 일상적인 유지보수에 손이 덜 가므로 편리함.
  • 하지만 예측하기 어려움.
  • 요청 경로를 재설정해야 하고, 대량의 데이터를 노드 사이에 이동해야 하므로 비용이 큰 연산임
    • 즉, 주의 깊게 처리하지 않으면 네트워크나 노드에 과부하가 걸릴 수 있고 재균형화가 진행 중인 동안 실행되는 다른 요청의 성능이 저하될 수 있음.
  • 이 자동화는 자동 장애 감지와 조합되면 위험해질 수 있음.
    • ex) 노드 한대에 과부하가 걸려 일시적으로 요청 응답이 느려진건데, 노드가 죽었다고 간주하고 해당 노드를 재균형화하려고 하면, 연쇄 장애가 발생할 수 있음.
  • 위와 같은 이유로 재균형화 과정에 사람이 개입하는게 좋을 수 있음.
    • 완전 자동화 처리보다는 느리지만 운영상 예상치 못한 일을 방지하는데 도움을 줌

요청 라우팅

• 데이터셋을 여러 장비에서 실행되는 여러 노드에 파티셔닝할 수 있음.
  • 클라이언트는 어느 노드로 접속해야하는지 어떻게 알 수있는가?
  • 파티션이 재균형화되면서 노드에 할당되는 파티션이 바뀜
  • 즉, 파티션 할당 변경에 대한 내용을 알고 있어야 함.
    • 이 문제는데이터베이스에 국한되지 않고, 일반적인 문제인 서비스 찾기(service discovery)의 일종임
    • 고가용성을 지향하는 소프트웨어라면 모두 이 문제가 있음.

• 어느 노드로 접근해야 하는지에 대한 몇 가지 접근 법이 있음. 위 그림 참고

1. 클라이언트가 아무 노드에나 접속하게 함. (ex: 라운드로빈 로드밸런서)
   • 만약 해당 노드에 마침 요청을 적용할 파티션이 있다면 거기서 요청을 처리함
   • 그렇지 않으면 요청을 올바른 노드로 전달해서 응답을 받고 클라이언트에게 응답을 전달함.
2. 클라이언트의 모든 요청을 라우팅 계층으로 먼저 보낸다.
   • 라우팅 계층은 요청을 처리할 노드를 알아내고 그에 따라 해당 노드로 요청을 전달함
   • 라우팅 계층 자체에서는 아무 요청도 처리하지 않음.
   • 파티션 인지(partition-aware) 로드 밸런서로 동작할 뿐임.
3. 클라이언트가 파티셔닝 방법과 파티션이 어떤 노드에 할당됐는지를 알고 있게 함.
   • 이 경우 클라이언트는 중개자 없이 올바른 노드로 직접 접속 가능함.

• 결국 핵심 문제는 라우팅 결정을 내리는 구성요소가 노드에 할당된 파티션의 변경 사항을 어떻게 아느냐임.
  • 이 문제는 모든 곳에서 정보가 일치해야 하므로 다루기 어려움
  • 잘못 다루게 되면 잘못된 노드로 전송되어 제대로 처리되지 못함.
  • 분산 시스템에서 합의를 이루는 데 쓰이는 프로토콜이 있지만 제대로 구현하기 어려움. (9장 참고)

• 위 그림과 같이 많은 분산 데이터 시스템은 클러스터 메타데이터를 추적하기 위해 주키퍼(ZooKeeper) 같은 별도의 코디네이션 서비스를 사용함)
• 각 노드는 주키퍼에 자신을 등록하고 주키퍼는 파티션과 노드 사이의 신뢰성 있는 할당 정보를 관리함.
  • 라우팅 계층이나 파티션 인지 클라이언트 같은 다른 구성요소들은 주키퍼에 있는 정보를 구독할 수 있음.
• 파티션 소유자가 바뀌거나 노드가 추가되거나 삭제되면 주키퍼는 라우팅 계층에 이를 알려서 라우팅 정보를 최신으로 유지할 수 있게 함.
• ex) 링크드인의 에스프레소는 헬릭스를 써서 클러스터를 관리하며, 위 그림과 같은 라우팅 계층을 구현함.
  • HBase, 솔라클라우드, 카프카도 파티션 할당을 추적하는 데 주키퍼를 사용함.
  • 몽고DB도 아키텍처는 비슷하지만, 자체적인 설정 서버(config server) 구현에 의존하고, 몽고스(mongos) 데몬을 라우팅 계층으로 사용함.
  • 카산드라, 리악은 다른 방법을 사용함.
    • 가십 프로토콜(gossip protocol)을 사용하여 클러스터 상태 변화를 노드 사이에 퍼뜨림
      • 아무 노드나 요청을 받고, 요청을 받은 노드는 요청을 처리할 파티션을 갖고 있는 올바른 노드로 요청을 전달해줌.
      • 이 모델은 데이터베이스 노드에 복잡성을 더하지만, 주키퍼 같은 외부 코디네이션 서비스에 의존하지 않음.
  • 카우치베이스는 재균형화를 자동으로 실행하지 않아서 설계까 단순함.
    • 클러스터 노드로부터 변경된 라우팅 정보를 알아내는 목시(moxi)라는 라우팅 계층을 설정함.

병렬 질의 실행

• 분석용으로 자주 사용되는 대규모 병렬 처리(massively parallel processing, MPP) 관계형 데이터베이스 제품은 훨씬 더 복잡한 종류의 질의를 지원함.
  • 전형적인 데이터 웨어하우스 질의는 조인, 필터링, 그룹화, 집계 연산을 몇 개 포함함.
  • MPP 질의 최적화기는 복잡한 질의를 여러 실행 단계와 파티션으로 분해하며, 이들 중 다수는 데이터베이스 클러스터 내의 서로 다른 노드에서 병렬적으로 실행될 수 있음.
• 데이터 웨어하우스 질의 고속 병렬 실행은 전문적인 주제임
  • 분석 업무가 비즈니스적으로 중요해짐에 따라 상업적 관심을 많이 받고 있음.
  • 해당 내용에 대한 기법은 10장에서 살펴봄.