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

요약

• 신뢰성 없는 네트워크 중, 동기와 비동기 네트워크에 대한 내용을 이해함.
  • 동기 → 제한 있는 지연 / 고정 대역폭
  • 비동기 → 제한 없는 지연 / 전송률 동적 조절 가능
• 신뢰성 없는 시계에 대한 내용을 이해함.
  • 일 기준 시계
    • 벽 시계
  • 단조 시계
    • 시간으 흐름을 잼
  • 시계 동기화와 정확성에 대한 내용
    • 신뢰가 낮음
  • 동기화된 시계에 의존
    • 이벤트 순서화용 타임스탬프
    • 시계 읽기 신뢰구간
  • 프로세스 중단에 따른 응답 시간처리가 필요
    • 응답 시간 보장
    • 가비지 컬렉션 영향 제어

메모

동기 네트워크 대 비동기 네트워크

• 동기 네트워크
  • ex) 전화 네트워크에서 통화 시, 회선(circuit)이 만들어짐.
    • 회선은 통화가 끝날 때까지 유지됨.
  • 데이터가 여러 라우터를 거치더라도 큐 대기 문제를 겪지 않음.
  • 큐 대기가 없기에 네트워크 종단 지연 시간의 최대치가 고정되어 있음.
    • 제한 있는 지연(bounded dely)라고 함.

그냥 네트워크 지연을 예측 가능하게 만들 수는 없을까?

• 전화 네트워크 회선과 달리 TCP 연결은 매우 다름.
  • 회선은 만들어져있는 동안, 다른 누구도 사용할 수 없는 고정된 양의 예약된 대역폭임.
    • 만약 데이터센터 네트워크와 인터넷이 회선 교환이라면 왕복 시간의 최대치를 보장할 수 있음.
  • TCP 연결의 패킷은 가용한 네트워크 대역폭을 상황에 맞게 사용한다.
    • 이더넷과 IP는 큐 대기 영향을 받는 패킷 교환 프로토콜 이므로 네트워크에 기약 없는 지연이 있음.
• 데이터센터 네트워크와 인터넷이 패킷 교환을 하는 이유는 순간적으로 몰리는 트래픽(bursty traffic)에 최적화됐기 때문임.
  • 회선을 통해 파일 전송을 한다면, 대역폭 할당을 추정해야 하는데, 추정치가 너무 높으면 회선이 구성될 수 없다. (대역폭 할당이 보장되지 않으면 회선 생성을 허용하지 않기 때문)
    • 따라서 순간적으로 몰리는 데이터 전송에서 네트워크 용량을 낭비하고 전송이 불필요하게 느려짐.
  • 반대로 TCP는 가용한 네트워크 용량에 맞춰 데이터 전송률을 동적으로 조절함.

신뢰성 없는 시계

분산 시스템에서 통신이 즉각적이지 않으므로 시간 다루기가 까다로움.

• 네트워크에 있는 개별 장비는 자신의 시계를 갖고 있음.
  • 이 하드웨어 장치는 완벽하지 않아서 각 장비마다 시간 개념이 느리거나 빠를 수 있음.
  • 이러한 차이를 어느정도 동기화 할 수 있는데, 네트워크 시간 프로토콜(Network Time Protocol, NTP)로 서버 그룹에 보고한 시간에 따라 컴퓨터 시계를 조정할 수 있게 함.

단조 시계 대 일 기준 시계

일 기준 시계

• 직관적으로 시계에 기대하는 일을 함.
• 어떤 달력에 따라 현재 날짜와 시간을 반환함. (벽시계 시간이라고도 함.)
• 일 기준 시계는 보통 NTP 로 동기화 됨.
• 일 기준 시간은 이상한 점이 많음.
  • 로컬 시계가 NTP 서버보다 너무 앞서면 강제로 리셋되어 과거 시점으로 거꾸로 뛰는 것 처럼 보일 수 있음.

단조 시계

• 타임아웃이나 서비스 응답 시간 같은, 지속 시간을 재는 데 적합함.
• 단조 시계라는 이름은 항상 앞으로 흐른 다는 사실을 의미함.
• 단조 시계는 두 시점에 대한 값의 차이로 시간이 얼마나 흘렀는지 알 수 있음.
  • 시계의 절대적인 값은 의미가 없음.
• NTP는 컴퓨터의 로컬 시계까 NTP 서버보다 빠르거나 느리다는 걸 발견하면, 단조 시계가 진행하는 진도수를 조정할 수 있음. (시계를 돌린다(slewing)라고 함.)

시계 동기화와 정확도

• 시계가 정확한 시간을 알려주게 하는 방법이 기대만큼 신뢰성이 있거나 정확하지 않음.
  • 드리프트 현상 발생 (더 빠르거나 느리게 실행됨)
    • 이는 장비의 온도에 따라 바뀜)
  • 노드와 NTP 서버사이 방화벽 문제로 지연이 발생함.
  • NTP 서버 설정이 잘못되어 있어 상당히 큰 차이의 시간을 보고하기도 함.
  • 윤초 처리가 제대로 고려되지 않을 수 있음.
  • 제어할 수 없는 장치에서 소프트웨어 실행 시, 그 장치의 하드웨어 시계를 믿을 수 없음.

동기화된 시계에 의존하기

• 시계는 대부분의 시간에 잘 동작하지만, 견고한 소프트웨어는 잘못된 시계에 대비할 필요가 있음.
• 장비의 수정 시계에 결함이 생겨서, 드리프트가 생기거나 등등 여러 문제로 실제 시간과 멀어져 가지만 잘 동작되는 것처럼 보일 수 있음.
  • 극적인 고장보다 조용하고 미묘한 데이터 손실이 발생할 가능성이 큼.
    • 따라서, 동기화된 시계가 필요한 소프트웨어를 사용한다면, 모든 장비 사이에 시계 차이를 모니터링 해야 함.
      • 다른 노드와 시계가 너무 차이가 많이 나면 죽은 노드로 선언하고 클러스터에서 제거돼야 함.

이벤트 순서화용 타임스탬프

• 타임 스탬프로 이벤트 순서를 올바르게 정할 수 없음.
  • p291 예시 참고
  • 가장 “최근” 값을 유지하고 다른 것들을 버림으로써 충돌을 해소할 수 있지만, “최근”의 정의는 로컬 일 기준 시계에 의존하기에 그 시계가 틀릴 수 있다는 걸 인지해야 함.
    • 올바른 순서화를 위해서는 시계 출처가 측정하려고 하는 대상(= 네트워크 지연)보다 훨씬 더 정확해야 함.
      • 논리적 시계
        • 이벤트 순서화의 안전한 대안
        • 일 기준 시간이나 경과한 초 수를 측정하지 않고, 이벤트의 상대적인 순서만 측정함.
      • 물리적 시계
        • 단조 시계와 실제 경과 시간의 측정.

시계 읽기는 신뢰 구간이 있다.

• 로컬 네트워크에 있는 NTP 서버와 동기화 하더라도 부정확한 수정 시계로 인해 드리프트는 쉽게 몇 밀리초가 될 수 있음.
  • 시계 읽기를 어떤 시점으로 생각하는 건 타당하지 않음.
  • 오히려 어떤 신뢰 구간에 속하는 시간의 범위로 읽는게 나음.
• 스패너의 구글 트루타임 API는 현 시간에서 가장 이른 것과 가장 늦은것을 가리키는 구간(신뢰 구간) 반환함.
  • 실제 현재 시간은 그 구간 안의 어딘가에 있다는 것을 의미함.

전역 스냅숏용 동기화된 시계

• 스냅숏 격리로 인한 트랜잭션을 사용하며, 동기화된 시계를 만들려면, 전역 단조 증가 트랜잭션 ID를 생성해야 함.
  • 분산 시스템에서는 데이터베이스가 여러 데이터센터에 분산돼 있기에 전역 단조 증가 트랜잭션 ID를 생성하기 어려움.
    • 동기화된 타임스탬프로 트랜잭션 ID 를 생성하게 할 수 있음.
      • ex) 스패터는 데이터센터에 걸친 스냅숏 격리를 구현함.
      • 트루타입 API 를 통해 두 시간에 대한 신뢰 구간을 구한다.
        • 신뢰 구간이 겹치지 않으면 이벤트 순서는 보장됨.
        • 신뢰 구간이 겹칠 경우에는 어떤 순서로 실행됐는지 확신할 수 없음.

프로세스 중단

• 분산 시스템에서 시계를 위험하게 사용하는 다른 예임.
• ex) 파티션마다 리더가 하나씩 있는 데이터베이스에서, 리더만 쓰기를 받아들이도록 허용함.
  • 안전하게 쓰기를 받아들이려면 리더가 다른 노드들로부터 임차권(lease)을 얻는다.
  • 노드가 계속 리더로 남아 있으려면 임차권이 만료되기 전에 주기적으로 갱신해야 함.
  • 노드에 장애가 나면 임차권 갱신을 멈추고 임차권이 만료될 때까지 다른 노드가 리더 역할을 넘겨받을 수 있음.
• 만약, 프로그램이 실행 중 예상치 못한 중단이 있으면, 해당 스레드가 오래 멈추게 되고, 요청을 처리하는 시점에 임차권이 만료돼서 다른 노드가 이미 리더역할을 넘겨 받았을 가능성이 높음.
  • 이 경우 실행 중인 스레드를 어떤 시점에 선점하고, 시간이 흐른 후 재개할 수 있음.
• 분산 시스템의 노드는 어느 시점에 실행이 상당한 시간 동안 멈출 수 있다고 가정해야 함.

응답 시간 보장

• 앞선 스레드, 프로세스의 중단의 원인을 제거할 수 있음.
  • 시스템에서 실시간을 보장하려면
    • 프로세스가 명시된 간격의 CPU 시간을 할당받을 수 있게 보장되도록 스케줄링 해주는 실시간 운영체제 (RTOS)가 필요함.

가지비 컬렉션의 영향을 제한하기

• 노드가 가비지 컬렉션하는 동안 클라이언트로부터 요청을 다른 노드들이 처리하게 한다.