TIL

08장 분산 시스템의 골칫거리

결함과 부분 장애

• 부분 장애(partial failure)
  • 분산 시스템에선 어떤 부분은 잘 동작하지만 다른 부분은 예측할 수 없이 고장날 수도 있다.
  • 부분 장애는 비결정적이다.
  • 네트워크와 관련되어 어떨 때는 동작하지만 어떨 때는 실패한다.

클라우드 컴퓨팅과 슈퍼컴퓨팅

• 대규모 컴퓨팅 시스템 구축 방법 종류
  • 고성능 컴퓨팅 분야 - 슈퍼컴퓨터 등으로 계산 비용이 매우 높은 과학 계산 작업에 사용된다.
  • 클라우드 컴퓨팅 - 데이터센터, IP 네트워크로 연결된 상용 컴퓨터 등과 관련돼 있다.
  • 고성능 컴퓨팅과 클라우드 컴퓨팅의 중간 지점인 전통적인 기업형 데이터 센터
• 이 책에선 인터넷 서비스를 구현하는 시스템을 집중적으로 다루며 다음과 같은 특징이 있다.
  • 언제라도 사용자에게 지연이 낮은 서비스를 제공해야 한다.
  • 부분 장애 가능성을 받아들이고 소프트웨어에 내결함성 메커니즘이 필요하다.
  • 지리적으로 분산된 배포를 하기에 통신 대부분이 인터넷을 거친다.
• 분산 시스템에선 의심, 비관주의, 편집증을 가지는 것이 좋다.
  • 발생 가능성이 낮은 결함이더라도 광범위하게 고려하고 테스트할 필요가 있다.

신뢰성 없는 네트워크

• 전통적 인터넷 서비스를 위한 분산 시스템은 비공유 시스템이다.
  • 즉 네트워크로 연결된 다수의 장비
  • 상대적으로 저렴하고 지리적으로 분산되어 높은 신뢰성 확보가 가능
• 인터넷과 데이터센터 내부 네트워크 대부분은 비동기 패킷 네트워크이기에 여러 가지가 잘못될 수 있다.
  • 요청이 손실 됐을 수도 있다.
  • 요청이 큐에서 대기하다 나중에 전송될 수 있다.
  • 원격 노드에 장애가 생겼을 수 있다.
  • 원격 노드가 일시적으로 응답하기를 멈췄지만 나중에 다시 응답할 수 있다.
  • 원격 노드가 요청을 처리했지만 응답이 네트워크에서 손실됐을 수 있다.
  • 원격 노드가 요청을 처리했지만 응답이 지연되다 나중에 전송될 수 있다.

현실의 네트워크 결함

• 100% 신뢰성 있는 네트워크를 만드는 방법은 아직 없는 듯 하다.
  • EC2 같은 공개 클라우드 서비스는 일시적 네트워크 결함이 자주 발생한다.
  • 비공개 데이터센터는 더 안정적일 순 있지만 네트워크 토폴로지 재구성을 유발하고 패킷이 1분 이상 지연될 수도 있다.
  • 상어가 해저 케이블을 물어뜯어 손상시키기도 한다.
• 네트워크 결함이 드물더라도 일어날 수 있기에 소프트웨어는 이를 처리할 수 있어야 한다.
  • 네트워크 결함을 견디도록 처리하기 보다 사용자에게 오류를 보여주는 것도 타당한 방법이다.
  • 소프트웨어가 네트워크 문제에 반응하여 복구될 수 있도록 보장하는 것이 중요하다.

결함 감지

• 많은 시스템은 결함 있는 노드를 자동으로 감지할 수 있어야 한다.
• 하지만 네트워크의 불확실성 때문에 노드가 동작 중인지 구별이 어렵다.

타임아웃과 기약 없는 지연

• 타임아웃은 결함을 감지하는 수단이지만 얼마나 기다려야 하는지 간단하지 않다.
  • 타임아웃이 길면 노드가 죽었다고 판단하기까지 대기 시간이 길어진다.
  • 타임아웃이 짧으면 노드가 일시적으로 느려졌을 뿐일 때도 죽었다고 선언할 위험이 높아진다.
• 시스템이 이미 높은 부하에 있다면 성급한 노드 결함 선언은 문제를 악화시킬 수 있다.
  • 연쇄적인 장애 유발

네트워크 혼잡과 큐 대기

• 컴퓨터 네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많다.
  • 여러 노드가 같은 목적지로 패킷을 보내려 하면 네트워크 스위치는 패킷을 큐에 넣고 한 번에 하나씩 목적지 네트워크 링크로 넘겨야 한다. (네트워크 혼잡)
  • 패킷이 목적지에 도착해도 모든 CPU 코어가 바쁜 상태라면 준비가 될 때까지 OS가 큐에 넣어 둔다.
  • TCP는 흐름 제어를 수행하면서 자신의 송신률을 제한하기에 데이터는 네트워크에 들어가기 전에도 부가적인 큐 대기를 할 수도 있다.
  • TCP는 타임아웃 안에 확인 응답을 받지 않으면 패킷 손실로 간주하고 손실 패킷을 자동으로 재전송하는데 이로 인한 지연도 존재한다.
• 큐 대기 지연은 시스템의 최대 용량까지 광범위하게 일어난다.
• 좋은 방법은 고정된 타임아웃을 설정하는 대신 지속적으로 응답 시간과 변동성을 측정해 타임아웃을 동적으로 조절하는 것이다.
  • 아카(Akka)와 카산드라 그리고 TCP 재전송 타임아웃도 비슷한 방법을 사용한다.

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

• 동기식 네트워크
  • 요청과 응답이 직렬적으로 이루어져 한 작업이 완료될 때까지 다음 작업이 진행되지 않는다.
  • 데이터가 여러 라우터를 거치더라도 큐 대기 문제를 거치지 않는다.
  • 큐 대기가 없기에 네트워크 종단 지연의 최대치가 고정돼 있다.
  • ex) 전화 통화 - 전화 회선은 다른 누구도 사용할 수 없는 고정된 대역폭을 사용하며 초당 비트 개수가 상당히 고정돼 있다.
• 비동기 네트워크
  • 요청과 응답이 병렬적으로 이루어지며 요청을 보낸 후 응답을 기다리지 않고 다른 작업을 수행한다.
  • TCP 연결의 경우 네트워크 대역폭을 기회주의적으로 사용해 가변 크기의 데이터 블록을 짧은 시간 안에 전송하려 한다.
  • ex) 웹 페이지 요청, 이메일 전송 등 - 순간적으로 몰리는 트래픽에 최적화됨
• 회선(동기식 네트워크)을 통해 파일 등을 전송하는 작업은 대역폭 할당을 추정해야 하기에 어렵다.
  • 추정치가 너무 낮으면 네트워크 용량을 쓰지 않고 남겨 둔 상태로 전송이 불필요하게 느려진다.
  • 추정치가 너무 높으면 회선은 구성될 수 없다.
    • 회선 교환은 대역폭 할당을 보장할 수 없다면 회선 생성을 허용하지 않기 때문
  • 반대로 TCP는 네트워크 용량에 맞춰 데이터 전송률을 동적으로 조절한다.
• 이러한 이유로 현대 웹 서비스들은 비동기 네트워크를 사용할 수밖에 없고, 네트워크 변동성으로 인한 기약 없는 지연이 발생할 것이라고 가정해야 한다.

신뢰성 없는 시계

• 분산 시스템에서 시계와 시간은 중요하다.
  • 통신이 즉각적이지 않기 때문
  • 네트워크 상의 개별 장비는 자신의 시계를 갖고 있기에 오차가 발생

단조 시계 대 일 기준 시계

• 현대 컴퓨터는 최소 두 가지 종류의 시계를 갖고 있다.
• 일 기준 시계(time-of-day clock)
  • 직관적으로 시계에 기대하는 일을 하는 시계로 현재 날짜와 시간을 반환한다.
  • ex) 리눅스와 자바는 에포크(epoch) 이래로 흐른 초(또는 ms)를 반환한다.
  • 일 기준 시계는 보통 NTP로 동기화되는데 여러 장비 간 타임스탬프들은 이상적으로 동일한 의미를 지닌다는 뜻이다.
  • 일 기준 시계는 로컬 시계가 NTP 서버보다 너무 앞선다던지 문제가 존재한다.
• 단조 시계(monotonic clock)
  • 타임아웃이나 서비스 응답 지속 시간을 재는 데 적합한 시계
  • ex) 리눅스의 clock_gettime과 자바의 System.nanoTime()
  • 한 시점의서의 시계 값과 다른 시점에서의 값의 차이로 시간이 얼마나 흘렀는지 알 수 있다.
  • 하지만 두 대의 다른 장비에서 나온 단조 시계 값을 비교하는 것은 의미가 없는데 이는 동일한 것을 의미하지 않기 때문
    • 심지어 CPU마다 독립된 타이머가 있을 수도 있다.
  • 분산 시스템에서 시간 경과를 재는 데 단조 시계를 사용하는 것은 일반적으로 괜찮다. (측정이 다소 부정확해도 민감하지 않음)

시계 동기화와 정확도

• 단조 시계는 동기화 필요가 없지만 일 기준 시계는 NTP 서버 등에 맞춰 설정되어야 유용하다.
• GPS 수신기, 정밀 시간 포로토콜과 세심한 배포 및 모니터링을 통해 높은 정확도를 가지는 시계를 만들 수 있긴 하다.
• 하지만 상당한 노력과 전문 기술이 필요하고 동기화가 잘못되는 수많은 시나리오가 있다.
  • NTP 데몬 설정이 잘못되는 경우
  • 방화벽이 NTP 트래픽을 차단하는 경우

동기화된 시계에 의존하기

• 시계는 사용하기 쉬워 보이지만 많은 함정이 존재하기에 견고한 소프트웨어는 잘못된 시계에 대비할 필요가 있다.
  • 동기화된 시계를 사용한다면 모든 장비의 시계 차이를 모니터링해야 한다.
• 이벤트 순서화용 타임스탬프
  • 분산 시스템에서 발생하는 이벤트들에는 이벤트 발행 시간인 타임스탬프를 기록한다.
  • 같은 값에 접근하는 이벤트들에 대해 최종 쓰기 승리(last write wins)를 적용하려 해도 어떤 쓰기가 가장 “최근” 값인지는 로컬 일 기준 시계에 의존하게 된다.
    • 정확한 NTP 동기화를 필요로 하는데 어려운 일이다.
  • 논리적 시계(logical clock)는 증가하는 카운터를 기반으로 하며 이벤트 순서화의 안전한 대안으로 사용된다.
    • 일 기준 시간이나 경과 초 수를 측정하지 않고 이벤트의 상대적인 순서만 측정
• 시계 읽기의 신뢰 구간
  • NPT 서버와의 동기화에 오차가 있기 때문에 장비의 일 기준 시계가 마이크로초/나노초 해상도로 시간을 읽을 수 있어도 실제로 정확한 것은 아니다.
  • ex) 어떤 장비의 현재 시간이 10.3초와 10.5초 사이일 확률이 95%임을 알아도 그보다 더 정확히는 알 수 없다.
  • 대부분의 시스템은 이러한 불확실성을 노출하지 않는다.
  • 예외적으로 스패너(Spanner)의 구글 트루타임(TrueTime) API는 로컬 시계의 신뢰 구간을 명시적으로 보고한다.
    • 현재 시간을 요청사면 가능한 타임스탬프 범위인 신뢰구간[earliest, latest]을 받는다.
• 전역 스냅숏용 동기화된 시계
  • 데이터베이스의 스냅숏 격리에선 트랜잭션은 단조 증가하는 트랜잭션 ID가 필요하다.
  • 하지만 분산 환경에선 트랜잭션 ID에 대한 코디네이션이 필요하고 각 노드에서 발생한 트랜잭션들 중 뭐가 더 높은 ID를 가지는지 판단할 수 있어야 한다.
  • 동기화된 일 기준 시계의 타임스탬프를 트랜잭션 ID로 쓰기에는 앞서 설명한 불확실성이 걸린다.
  • 스패너의 트루타임을 통해 트랜잭션 ID를 부여할 수 있는데 두 신뢰 구간이 겹치지 않는다면 선후관계를 파악할 수 있고 겹친다면 순서를 확신할 수 없다.
    • 트랜잭션 타임스탬프가 인과성을 보장하기 위해 스패너는 읽기 쓰기 트랜잭션을 커밋하기 전 의도적으로 신뢰 구간 길이만큼 기다린다.

프로세스 중단

• 파티션마다 리더가 하나씩 있는 데이터베이스에서 어떤 리더가 여전리 리더인지, 쓰기를 받을 수 있는 상태인지 어떻게 알 수 있을까?
• 한 가지 방법으로 리더가 다른 노드들로부터 임차권(lease)을 얻는 것이다.
  • 특정 시점에 오직 하나의 리더만 임차권을 얻는다. (타임아웃이 있는 잠금과 비슷)
  • 임차권이 만료될 때까지 자신이 리더임을 알 수 있다.
  • 노드가 계속 리더로 남아 있으려면 주기적으로 임차권을 갱신해야 한다.
  • 노드에 장애가 나면 임차권 갱신이 되지 않아 만료 시 다른 노드가 리더를 넘겨받을 수 있다.

while (true) {
  request = getIncomingRequest()
  
  // 항상 임차권이 적어도 10초는 남아 있게 보장
  if (lease.expiryTimeMillis - System.currentTimeMillis() < 10000) {
    lease = lease.renew()
  }
  
  if (lease.isValid()) {
    process(request)
  }
}

• 하지만 임차권 만료 로직에서 여러 오류가 발생할 수 있다.
  • 임차권 만료시간에 관련된 로직에서 동기화된 시계에 의존하기에 동기화가 깨지면 버그가 발생할 수 있다.
  • 단조 시계만 사용하도록 변경하더라도 시간을 확인하는 시점과 요청이 처리되는 시점 사이 매우 짧은 시간이 흐른다.
  • 프로그램 실행 중 예상치 못한 중단이 발생할 수도 있다.
• 프로그램 중단이 발생하면 실행 중인 스레드를 어떤 시점에 선점하고 얼마 후 재개할 수 있다.
  • 선점된 스레드는 중단과 재개에 대해 알지 못하기에 타이밍에 대한 어떤 가정도 할 수 없다.
  • 멈춰 있는 동안 외부 시계는 계속 움직인다.
• 응답 시간 보장
  • 명시된 시간 안에 응답하지 못하면 심각한 손상이 발생하는 시스템에선 응답 시간에 대한 데드라인이 명시된다.
  • 데드라인을 만족시키지 못하면 전체 시스템 장애를 유발할 수 있는데 이를 엄격한 실시간 시스템(hard real-time)이라 한다.
  • 시스템에서 실시간 보장을 제공하려면 실시간 운영체제(real-time operating system, RTOS)가 필요하다.
    • 많은 양의 부가 작업이 필요
    • 사용 가능한 프로그래밍 언어, 라이브러리, 도구의 범위를 엄격히 제한
  • 실시간과 고성능은 동일하지 않기에 대부분의 서버측 데이터 처리 시스템은 비실시간 환경에서 운영되어야 하며 시계 불안정과 중단으로부터 고통받는다.
• 가비지 컬렉션 영향을 제한하기
  • 런타임에 애플리케이션에게 노드가 곧 GC 중단이 필요하다는 경고가 가능하다면 그 노드로 새 요청 보내기를 멈추고 GC 실행을 기다릴 수 있다.
  • 그럼 요청 처리 중 GC로 인한 중단으로 인해 시계가 꼬이는 일을 방지할 수 있을 것이다.
  • 실제로 지연에 민감한 금융 거래 시스템 중엔 이 방법을 쓰는 것도 있다.

지식, 진실, 그리고 거짓말

• 분산 시스템은 공유 메모리가 없고 지연이 큰 네트워크 때문에 아래 문제에 시달린다.
  • 부분 장애
  • 신뢰성 없는 시계
  • 프로세스 중단
• 원격 노드가 응답하지 않으면 그 노드의 상태를 알 방법은 없다.
  • 네트워크 문제 or 노드 자체의 문제
• 그래도 다행인 것은 분산 시스템에서 동작하는 시스템 모델에 관해 가정을 명시하고, 가정을 만족시키는 방식으로 시스템을 설계할 수 있다.
  • 시스템 모델이 매우 적은 보장만 제공하더라도 신뢰성 있는 동작의 달성이 가능

진실은 다수결로 결정된다

• 분산 시스템에선 노드의 과반수 이상을 정족수로 삼는 게 가장 흔하다.
  • 개별 노드에 장애가 나더라도 시스템은 여전히 안전하다고 판단
  • 시스템에는 오직 하나의 과반수만 존재할 수 있어 서로 충돌되는 결정을 하는 두 과반수는 동시에 있을 수 없다.
• 리더와 잠금
  • 시스템이 오직 하나의 뭔가를 필요로할 때가 있다.
    • 오직 한 노드만 데이터베이스 파티션의 리더여야 함
    • 특정 자원이나 객체에 오직 한 트랜잭션만 짐금을 획득 가능
  • 분산 시스템에서 이를 구현하기 위해선 잠금이 필요하다.
  • 어떤 노드가 자신이 선택된 것처럼 행동하더라도 다른 노드 과반수가 이에 동의하지 않을 수 있다.
    • ex) 임차권 로직에서 서로 다른 노드가 자신이 임차권을 가진 것으로 판단하는 경우
• 펜싱 토큰 : 잠금이 승인될 때마다 증가하는 숫자
  • 잠금 서버가 잠금이나 임차권을 승인할 때마다 펜싱 토큰도 반환한다고 가정
    • 클라이언트 1이 33번 토큰으로 임차권을 획득 후 장애가 발생해 임차권이 만료
    • 클라이언트 2가 34번 토큰으로 임차권을 얻어 토큰을 포함하여 쓰기 요청
    • 클라이언트 1이 되살아나 33번 토큰으로 쓰기 요청
    • 저장소 서버는 더 큰 토큰 번호(34)를 가진 쓰기를 이미 처리했기에 33번 토큰 요청을 거부
  • 잠금 서비스로 주키퍼를 사용하면 트랜잭션 ID나 노드 버전을 펜싱 토큰으로 사용 가능 (단조 증가 보장)

비잔틴 결함

• 펜싱 토큰의 사용은 노드들이 신뢰성은 없지만 정직하다고 가정한다.
  • 부주의에 의한 오류(임차권이 만료됐다는 것을 모름)는 차단 가능하다.
  • 하지만 노드가 고의로 가짜 펜싱 토큰을 사용하면 시스템은 고장난다.
• 비잔틴 결함(Byzantine fault)
  • 본산 시스템의 문제는 노드가 ‘거짓말’을 할지도 모른다는 것인데 이를 비잔틴 결함이라 한다.
  • 비잔틴 장군 문제(Byzantine Generals Problem) - 신뢰할 수 없는 환경에서 합의에 도달하는 문제
  • 오작동 및 악의적인 공격에도 올바르게 동작한다면 비잔틴 내결함성을 지닌다고 말한다.
• 하지만 이 책에서 살피는 시스템은 보통 비잔틴 결함이 없다고 가정할 수 있다.
  • 데이터센터 내 모든 노드를 조직의 개발자가 관리 및 제어
• 웹 애플리케이션은 최종 사용자가 제어하는 클라이언트의 행동이 악의적일 수 있다고 가정해야 한다.
  • ex) SQL injection, css 등
• 노드들은 일반적으로 정직하지만 약간의 ‘거짓말’을 대비하는 매커니즘의 추가는 도움이 된다.
  • 네트워크 패킷이 버그로보터 오염되는 경우 애플리케이션 수준 프로토콜에서 체크섬을 쓰면 충분하다.
  • 공개적으로 접근 가능한 애플리케이션은 사용자 입력을 신중히 받아야 한다.

시스템 모델과 현실

• 분산 시스템 문제 해결을 위해 많은 알고리즘이 설계되고 있다.
  • 알고리즘은 하드웨어나 소프트웨어 설정에 너무 의존하지 않고 예상되는 결함을 정형화해야 한다.
• 시스템 모델 (system model) - 알고리즘이 가정하는 것을 기술한 추상화
• 타이밍 가정에 대한 시스템 모델
  • 동기식 모델
    • 네트워크 지연, 프로세스 중단, 시계 오차에 모두 제한이 있다고 가정하는 모델
    • 기약 없는 지연과 중단이 발생할 수 있다.
  • 부분 동기식 모델
    • 시스템이 대부분 시간에는 동기식으로 동작하지만 때때로 지연, 중단, 시계 드리프트 한계치를 초과
  • 비동기식 모델
    • 알고리즘이 타이밍에 대한 어떤 가정도 할 수 없다.
    • 알고리즘을 비동기식으로 설계할 수 있지만 매우 제한적
• 노드 장애에 대한 시스템 모델
  • crash-stop
    • 죽으면 중단하는 모델로 노드에 장애가 나는 방식이 하나뿐이다.
    • 노드가 응답을 멈추면 결코 되돌아오지 않는다.
  • crash-recovery
    • 노드가 어느 순간 죽을 수도 있지만 시간이 흐르고 다시 응답할 것이라 가정
    • 메모리는 휘발되지만 비휘발성 디스크 저장소에는 데이터가 남아있다고 가정
  • 비잔틴 결함
    • 노드는 다른 노드를 속이거나 전적으로 모든 일이든 할 수 있다.
• 알고리즘이 정확하다는 게 어떤 의미인지 정의하기 위해 알고리즘의 속성(property)을 기술할 수 있다.
  • 유일성 - 펜싱 토큰 요청이 같은 값을 반환하지 않음
  • 단조 일련 번호 - 요청 x가 토큰 tx를, 요청 y가 토큰 ty를 반환했고 y가 시작하기 전에 x가 완료됐다면 tx < ty를 만족한다.
  • 가용성 - 펜싱 토큰을 요청하고 죽지 않은 노드는 결국에 응답을 받는다.
• 안정성과 활동성
  • 안정성(safety)은 비공식적으로 나쁜 일은 일어나지 않는다라고 정의한다.
    • 유일성과 단조 일련번호는 안전성 속성
    • 안전성 속성이 위반되면 그 시점을 가리킬 수 있다. (유일성이 위반되어 중복된 펜싱 토큰을 반환한 연산을 식별 가능)
    • 안정성이 위반된 후에는 그 위반을 취소할 수 없다.
  • 활동성(liveness)은 좋은 일은 결국 일어난다라고 정의
    • 가용성과 최종적 일관성은 활동성 속성
    • 활동성 속성이 위반되면 그 시점을 정의하지 못할 수 있다. (노드가 요청을 보냈지만 아직 응답을 못했을 수도 있다.)
    • 항상 미래에 그 속성을 만족시킬 수 있다는 희망이 있다.
  • 안전성과 활동성 속성을 구별하면 어려운 시스템 모델을 다루는 데 도움이 된다.