CH8 - 분산 시스템의 골칫거리

[won983212]

결함과 부분 장애

단일 시스템에서는 소프트웨어가 결정적으로 동작한다.

• 하드웨어가 정상적: 항상 같은 결과를 냄
• 하드웨어가 고장: 완전히 동작하지 않는다.
• 즉 동작하지 않을 수 있어도, 잘못된 결과를 주진 않음

💡 이는 다루기 힘든 잘못된 결과를 피하기 위해 의도적으로 설계된 것. '완전히'라는 키워드가 중요

네트워크로 연결된 분산 시스템은 전체가 아니라 일부만 예상치 못한 방식으로 고장날 수 있다.

• 이를 부분장애라고 하며, 부분 장애는 비결정적임
• 부분장애의 비결정성때문에 분산 시스템은 다루기 매우 까다롭다.

내 짧은 경력 동안 한 데이터 센터에서 발생한 장기간의 네트워크 분단, PDU(power distribution unit, 전원 분배 유닛)장애, 스위치 장애, 전체 랙에서 주기적으로 일어난 전원 사고, 전체 DC 백본 장애, 전체 DC 전원 장애를 겪었고, 저혈당증을 앓는 운전자가 자신의 포드 픽업 트럭을 DC의 HVAC(난방, 통풍, 공조) 시스템에 처박은 적도 있었다.
심지어 나는 운영 담당 직원도 아니였다.

- 코다 헤일(Coda Hale) -

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

구분	슈퍼컴퓨팅	클라우드 컴퓨팅
시스템	단일 노드 컴퓨터에 가깝다.	분산 시스템
하드웨어	전용 하드웨어로 구축	상용 장비로 구축
신뢰성	노드가 서로 가깝고 전용 하드웨어를 사용해 높은 신뢰성	노드가 멀리 떨어져있고 인터넷으로 통신하므로 비교적 낮은 신뢰성
사용	일기예보나 분자 동력학 등 큰 과학 계산에 주로 사용	인터넷 서비스 등...
장애복구	부분 장애를 전체 장애로 확대 - 가끔씩 계산 상태를 체크포인트로 저장한다. - 장애 발생시 모든 계산을 중단한다. - 복구가 끝나면 계산을 재시작한다.	부분 장애를 허용 - 인터넷 애플리케이션 특성상 가용성이 중요하므로 장비를 중단할 수 없음. - 소프트웨어에 내결함성 메커니즘을 넣어야 함

분산 시스템에서는 신뢰성 없는 구성요소를 모아 신뢰성 있는 시스템 구축해야한다.

• 예시로 IP가 있다. IP는 신뢰성이 낮은데, TCP에서는 IP위에서 패킷 누락/중복/순서 뒤엉킴이 발생하지 않도록 보장해준다.
• 물론 완벽하진 않아서 패킷 지연은 막을 수 없다.

신뢰성 없는 네트워크

여기서는 분산 시스템은 비공유 시스템이라고 가정한다.

• 네트워크로 연결된 다수의 장비를 의미
• 다른 장비의 RAM/Disk등에 직접 접근 불가
• 실제로 대부분의 분산 인터넷 애플리케이션 서비스는 비공유 방식으로 동작

왜 인터넷 서비스에서 비공유 시스템이 주로 사용되는가?

• 상용 장비를 사용하므로 장비값이 비교적 저렴
• 상품화된 클라우드(AWS, NCP, GCP, ...)를 사용할 수 있음
• 지리적으로 분산된 여러 IDC에 분산 배포하여 신뢰성 확보

비동기 패킷 네트워크

인터넷 서비스는 대부분 비동기로 패킷을 전송한다.

• 그래서 요청 전송후 기다릴 때 여러 결함이 발생할 수 있다.
• 응답을 받지 못해도 그 이유을 알 수 없다.
• 심지어 요청이 잘 처리되었는지 조차도 알 수 없다. (ex. 스티커가 잘 수집 되었는지)

응답을 받지 못하는건 여러 이유가 있을 수 있는데

• 케이블 선이 고장나서 요청 손실
• 원격 노드에 불남 (카카오)
• 네트워크 스위치 설정 문제로 요청이 다른 곳으로 전송
• 해저 케이블을 상어가 뜯어먹어서 지연
• 스위치 SW 업데이트 중 토폴로지 재구성
• 네트워크 장비가 과부하되어 지연 등...

이 문제를 처리하기 위해 타임아웃을 주로 사용한다. 하지만 원격 노드가 응답을 받았는지는 여전히 알 수 없다.

현실의 네트워크 결함

이처럼 네트워크 결함은 생각보다 많이 발생한다. 항상 네트워크 결함이 있다고 가정해도 될 정도.

• 소프트웨어 차원에서 네트워크 결함을 잘 처리해야한다.
• 네트워크 문제에 소프트웨어가 어떻게 반응하는지 알고 복구할 수 있도록 해야한다.
  • 카오스 몽키

결함 감지

고가용성을 보장하기 위해서 분산 시스템에서는 결함을 잘 감지해야한다.

• 로드 벨런서는 결함 있는 노드로 요청을 보내지 말아야 한다.
• 단일 리더 복제에서는 리더에 장애가 발생하면 한 팔로워를 리더로 승격시켜야 한다.

네트워크의 불확실성 때문에 결함을 완벽하게 감지하는건 어렵다. 그래서 타임아웃을 두어 일정 시간 응답을 못받으면 결함이라고 가정한다.

좀 더 빠른 처리를 위해 애플리케이션에서 명시적으로 피드백을 주는 방법도 있다.

• ex1) 어떤 노드 프로세스가 죽었다면 응답으로 죽었다고 전달한다.
• ex2) IP주소에 도달할 수 없다고 라우터가 확신하면 ICMP Destination Unreachable을 전달한다.
• 타임아웃을 끝까지 기다릴 필요가 없다는 장점이 있다.
• 하지만 이러한 피드백 조차도 네트워크 문제로 전달되지 않을 수 있으니 의존하면 안된다.

타임아웃과 기약 없는 지연

적절한 타임아웃 시간은 산출하기 어렵다.

👉 타임아웃이 길면

• 기다리는 시간이 길어진다. 요청이 많은 경우 소켓 고갈 가능성이 있다.

👉 타임아웃이 짧으면

• 실제로 살아있어도 죽었다고 판단할 확률이 높아진다.
• 같은 동작을 두 번이상 할 수도 있다. (멱등성이 보장되지 않은 경우)
  • ex) 같은 스티커가 두 번 수집될 수 있다.

네트워크 혼잡과 큐 대기

네트워크 패킷 지연이 매번 다른건 큐 대기때문인 경우가 많다.

• 동시에 같은 목적지로 많이 전송: 여러 다른 노드가 동시에 같은 목적지(ex. 스위치 포트)로 패킷을 보내려고 하면 패킷은 슬롯을 얻을 때 까지 대기
• 원격 노드 CPU가 바쁨: 패킷이 도착했는데 CPU가 바쁜 상태면 운영체제가 잠시 큐에 패킷넣어 버퍼링
• 가상 환경에서 CPU 시간 뺏김: 잠깐 다른 가상 장비가 CPU코어를 사용하면 데이터를 큐에 넣어 버퍼링
• TCP 흐름제어: 네트워크에 과부하를 가하지 않도록 자신의 송신률을 제한
  • 타임아웃이 지나면 패킷을 다시 재전송

네트워크 지연 변동성이 커서 타임아웃을 고정적으로 설정하는 것보단, 응답 시간에 따라 동적으로 타임아웃을 조절하는 것이 더 좋다. (ex. phi accrual failure detector)

동기 네트워크와 비동기 네트워크

전화 회선 (동기식)

• 전용 선을 할당받아 데이터를 주고받는다.
• 고정된 대역폭을 할당받는다.
  • 대역폭이 예상 가능하므로 큐 대기 문제가 없다.
  • 네트워크 지연 시간 최대치를 알 수 있다.

인터넷 네트워크 (비동기식)

• 하나의 선에 여러 곳에서 온 데이터들이 전달될 수 있다.
• 대역폭을 동적으로 공유한다.
  • 네트워크 지연 시간 변동성이 크다.

인터넷 네트워크를 비동기식으로 구성한 이유는 몰리는 트래픽을 효과적으로 처리하기 위해서이다.

• 전화 회선은 전용 선으로 통신하므로 트래픽이 많아져도 다른 회선을 쓸 수 없다. 전용 선만 써야하므로 리소스 낭비이다.
• 인터넷은 대역폭을 공유하므로 잠깐 더 많은 대역폭을 점유해서 쓸 수 있다. 더 효율적으로 네트워크 회선을 사용할 수 있다.
• 즉 네트워크 지연 변동성과 전송 효율 사이의 트레이드 오프인 것.
• 그래서 결국 타임아웃은 실험적으로 결정할 수 밖에 없다.

[won983212]

신뢰성 없는 시계

컴퓨터(서버) 시계는 정확하지 않다.

• 컴퓨터 수정 시계 소자는 온도에 따라 드리프트 현상이 발생할 수 있다.
• 장비별로 시간 오차가 발생할 수 있다.

💡 드리프트 현상: 시간이 더 빠르게 흐르거나 느리게 흐르는 현상

단조 시계와 일 기준 시계

용도에 따라 시계를 골라 사용할 수 있다.

구분	일 기준 시계	단조 시계
개념	현재 날짜/시각을 계산	특정 이벤트 사이의 시간 구간을 계산
사용처	- 자바의 System.currentTimeMillis()	- 자바의 System.nanoTime() - 타임아웃, 서비스 응답시간 등
시간 흐름	NTP에 의해 동기화되면서 시간이 뒤로 흐를 수도 있음	항상 앞으로 흐름
단위 해상도	낮음 (예전 윈도우 시스템에서 10밀리초 단위)	높음 (µs이하)

일 기준 시계 오차

여러 장비간 시각(일 기준 시계) 오차을 맞추기 위해 NTP를 사용한다.

• NTP 서버는 GPS, PTP 등의 방법을 사용해 정확하게 시각 측정
• Mac은 time.apple.com으로 시계 동기화

NTP의 문제점

NTP가 완벽하게 신뢰성/정확성을 보장하진 않는다. 그래서 컴퓨터 시계에 너무 의존해서는 안된다.

• 시간이 역으로 흐를 가능성이 있다.
  • 컴퓨터 시계가 NTP 서버와 너무 차이나면 컴퓨터 시계를 리셋할 수 있다.
  • 이 과정에서 시계가 거꾸로 흐르는 것처럼 보일 수 있음.
• 결국 서버에서 데이터를 가져와야하므로 네트워크 통신에 의존한다.
  • 만약 방화벽 등의 설정으로 통신이 막혀도 당장 눈치채기 어려울 수 있다.
  • 동기화 정확성이 네트워크 지연에 의존한다.
• NTP 서버 자체 문제로 몇 시간전으로 돌아갈 수도 있다.
  • 클라이언트가 윤초를 고려하지 않는 시스템이라면 시간이 엉망이 될 수 있다.
• 가상화 시스템에서 갑자기 시간이 앞으로 뛰는 현상이 발생할 수 있다.
  • CPU가 다른 앱을 실행하느라 잠시 멈출 수 있는데, 다시 실행 재개되면 시간이 뛴 것처럼 보일 수 있다.

예시: 최종 쓰기 승리(LLW) 문제

다중 리더 복제 시스템에서 LLW는 노드간 시간 차이로 인해 문제가 생길 수 있다.

💡 최종 쓰기 승리(LLW): 충돌이 발생했을 때 더 나중에 쓴 값을 쓰는 전략

1. Client A) Node 1에 x=1
2. Client B) Node 3에 x+=1

Node 2에는 x=2가 저장되어야한다.

• Client A가 먼저 x=1을 실행하고 B가 거기에 1을 더했으니

하지만 Node 3의 시계가 더 앞서도록 설정되어있다면 x=1요청이 무시된다.

이 문제를 해결하기 위해 논리적 시계를 사용하는 방법이 있다.

• 물리적 시계(일 기준/단조 시계)로 이벤트 순서를 측정하지 말고
• 이벤트 카운터 등을 사용해서 버전 관리를 하여 순서를 측정할 수 있다.

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

네트워크를 통해 이루어진 분산 시스템에서는 각 노드의 상태를 정확히 알기 어렵다.

• 노드의 장애나 네트워크 불안정성으로 인해 신뢰할 수 없는 정보가 생길 수 있음.

100% 신뢰성있는 시스템은 만들 수 없고, 몇 가지 가정을 통해 좀 더 신뢰성있는 설계를 만들 수 있을 뿐이다.

진실은 다수결로 결정

단일 노드의 의견에 의존하지 않고, 다수의 노드 의견을 종합하여 판단해야한다.

• 노드는 언제든 장애가 날 수 있기 때문
• 노드 A에 대해 노드 4개는 OK, 노드 2개는 FAIL이더라도 다수결에 의해 OK로 판단

리더와 잠금

시스템에 오직 하나의 뭔가를 만들고 유지해야할 때가 있다.

• 단일 리더 복제: 한 명의 리더만 있어야 한다.
• 파일 쓰기: 충돌을 피하기 위해 한 thread만 써야한다.

하지만 오류로 인해 하나만 존재해야한다는 가정이 깨질 수 있다.

• 단일 리더 복제: 리더 노드의 네트워크가 잠깐 끊기거나 GC등의 이유로 강등되었음에도 여전히 리더라고 생각할 수 있다.
• 파일 쓰기: lock timeout이 지났는데 GC때문에 여전히 락을 가지고 있다고 착각할 수 있다.

파일 쓰기의 예시를 좀 더 살펴보면...

1. Client 1은 쓰기 락을 획득한다.
2. 그런데 GC가 발생해서 프로그램이 잠깐 멈춘다. 그 과정에서 lock timeout이 지나 락도 회수된다.
3. Client 2가 쓰기 락을 획득한다.
4. Client 1의 GC가 끝났는데, 여전히 lock을 가지고 있다고 착각한다.
5. 결국 Client 1, 2모두 쓰기 작업을 수행해 충돌이 발생한다.

펜싱 토큰을 사용하여 이 문제를 해결할 수 있다.

• 락 획득시 펜싱 토큰(버전정보)를 같이 전달하고, 쓰기 작업시에 토큰을 전달한다.
• 저장소는 토큰을 확인해 쓸지 말지 결정한다.

비잔틴 결함

분산 시스템에서 노드가 다른 노드에게 거짓 정보를 전달할 수 있는 상황

일반적으로 노드는 거짓말을 하지 않는다고 가정하지만, 노드가 거짓말을 할 수도 있다면 시스템 설계가 훨씬 복잡해진다.

• 예를 들어 사실 펜싱 토큰을 임의로 조작해 강제로 쓰기를 수행할 수도 있다.

노드가 거짓말을 할 수도 있는 환경에서도 계속 올바르게 동작한다면 비잔틴 내결함성을 지닌다고 한다.

• 임베디드 시스템에서는 중요하다고 한다.
• 예를 들면 항공우주 산업에서 쓰이는 CPU는 방사선으로 인해 오작동할 수 있고, 장애 발생시 비용이 매우 크므로 비잔틴 내결함성을 지녀야한다.

노드 시스템을 본인 조직이 관리한다면, 즉 어느정도 신뢰할 수 있다면 비잔틴 내결함성을 꼭 지닐 필요는 없다.

• 내결함성까지 갖추기에는 너무 비용이 크기 때문에