데이터 중심 애플리케이션 설계 - 분산시스템의 골칫거리

분산 시스템의 골칫거리

• 잘못될 가능성이 있다면 잘못된다 ㅠㅠ

결함과 부분 장애

• 우리는 소프트 웨어를 결정적으로 설계한다.
• 하지만 네트워크로 연결된 여러 컴퓨터에서 실행되는 소프트웨어는 오류가 날 수 있다.
• 부분 장애: 어떤 부분은 잘 동작하지만 어떤 부분은 예측할 수 없는 방향으로 고장
  • 비결정적이다.

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

• 대규모 컴퓨팅 구축 방법에 관한 철학
  • 한쪽 끝에 고성능 컴퓨팅이 있다(high-performance computing, HPC)
  • 다른 극단에는 클라우드 컴퓨팅이 있다.
    • 사용ㅇ컴퓨터, 신축적, 주문식 자원할당(elastic, on-demand), 계량결제
  • 전통적인 기업형 데이터센터는 이 두 극단의 중간지점에 있다.
• 철학에 따라 결함 처리 방법도 다르다.
  • 슈퍼컴퓨터: 단일 노드처럼 처리
• 분산시스템이 동작하게 만들려면, 부분 장애 가능성을 받아들이고, 내결함성 매커니즘을 넣어야한다.
• 결함처리는 소프트웨어의 일부분이다.

신뢰성 없는 네트워크

• 분산시스템은 네트워크로 연결된 다수의 장비 (비공유 시스템)
  • 각자의 디스크나 메모리에 접근할 수 없다.
• 비동기 패킷 네트워크(asynchronous packet network)
  • 일반적으로 인터넷과 데이터센터 내부 네트워크(이더넷)
  • 보낼 수는 있지만 도착에 대해 보장하는 것이 없다.
    • 요청 손실 / 전송 지연 / 원격노드의 상태 / 네트워크 손실 등…
  • 응답을 받지 못했다면 그 이유를 아는 것은 불가능하다. (보통 아임아웃으로 해결)

현실의 네트워크 결함

• 신뢰성 있는 네트워크를 구성하는 것은 어려움.
• 송신이 잘된다고 수신까지 잘 된다고 보장할 수 없다.
• network partition, netsplit, fault : 네트워크 결함으로 다른곳과 차단
• 네트워크 결함의 가능성이 있다면 이를 소프트웨어가 처리할 수 있어야 한다.
• 반드시 견딜 필요는 없음

결함 감지

• 결함이 있는 노드를 감지하여 처리가 필요하다 (빼거나 리더를 교체하거나)
  • 요청응답은 노드보다는 어플리케이션 단에서 확인하는 것이 좋다
• 몇번의 retry와 timeout을 거쳐 최종적으로 노드가 죽었다고 선언할 수 있다.

타임아웃과 기약없는 지연

• 타임아웃 설정을 적절히 설정하는 것은 중요하다.
• 타임아웃 시간이 너무 빨라 해당 노드가 죽었다고 판단되면 해당 로드는 다른 노드로 전달되어야 한다. 시스템이 부하일 ㄸ ㅐ영향이 있을 수 있다.
• 작업의 사이즈와 요청의 최대 처리시간을 고려하여 짠다.(2d+r, ㅇd는 최대 전송시간, r은 최대요청처리시간)
  • 그러나 어떤 것도 보장되지 않는다. 기약없는 지연이 이다. 상한치가 없다.

네트워크 혼잡과 큐 대기

• 보통 컴퓨터 네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많다.
  • 송신하고 난 다음 상대 서버 처리량문제로 큐에 걸리거나
  • 우리 서버에서 TCP로 인해 전송전 제약이 있거나
    • TCP는 시간내 응답이 오지 않으면 재존송함
  • 네트워크 혼잡 등등…
• TCP 대 UDP
  • 지연시간에 민감한 경우 ⇒ UDP
  • TCP는 신뢰송, UDP는 지연 변동성을 중점으로 둔다.
    • 둘 사이에 TRADE OFF 상충관계가 있다.
  • UDP는 흐름을 제어하지 ㅇ낳고 손실된 패킷을 재전송하지않으므로 지연이 적다.
    • 지연된 데이터의 가치가 없는 상황에서 선택하면 좋다.
• 클라우드에서는 하나의 자원을 여러명이 공유하므로 자원을 많이 쓰는 누군가가 가까이 있다면 네트워크 지연 변동이 클 수 있다.
• 타임아웃 설정은 실험적으로 정하는 수밖에 없다. (테스트 많이하란 ㄸ스)
• JITTER: 고정된 타임아웃을 설정하는 대신 변동성을 측정하고 관찰된 응답시간 분포에 따라 자동 조절하는 것 (파이 증가 장애 탐지기를 사용한다.)

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

• 전화 네트워크에서 통화를 할 때에 회선 생성(circuit)
  • 대역폭이 보장된다 ⇒ 동기 네트워크
  • 큐 대기가 없으므로 네트워크 종단 지연시간의 최대치가 고정돼있다. ⇒ 제한 있는 지연(bounded delay)

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

• 전화 네트워크의 연결은 TCP 연결과 다르다.
  • 전화 회서는 대역폭이 예약되어 있지만 TCP는 가용 대역폭을 기회주의적으로 사용한다.
  • TCP는 유휴 상태에 있는 동안 어떤 대역폭도 쓰지 않는다.
• 왜 데이터센터 네트워크와 인터넷은 패킷교환을 사용할까?
  • 순간적으로 몰리는 트래픽에 최적화 되어있기 때문(bursty traffic), 단지 가능하면 빨리 완료되기를 바라 뿐이다.
  • 할당치를 추정해야하는데, 대역폭이 적절하지 않으면 비효율이 발생한다.
  • TCP는 반대로 가용 네트워크 용량에 맞춰 전송률을 동적으로 조절한다.
• 하이브리드 네트워크를 만드려는 시도도 있었다. 걍 못씀
• 지연시간과 자원사용률: 네트워크에서 변동이 큰 지연은 지연법칙이 아니라 단지 비용/이득 트레이드오프의 결과일 뿐이다.

신뢰성 없는 시계

• 분산시스템에서는 통신이 즉각적이지 않으므로 시간은 다루기 까다롭다.
• 개별 장비마다 자신의 시계를 갖고 있다.

단조 시계 대 일 기준 시계

• 일 기준 시계 : time-of-day clock , 단조시계 monotonic clock

일 기준 시계

• 일 기준 시계는 직관적으로 우리가 시대에 기대하는 일을 한다.(벽시계임)
• epoch: 1970년도 1월 1일(그래고리력) ⇒ 이 때 이후로 몇초가 지났나.
• 일기준 시계는 보통 NTP로 동기화된다. 로컬 시계가 NTP 서버보다 앞서면 강제로 리셋된다. 이 경우 윤초를 종종 무시한다는 점 등을 고려하여 기준시간 경과를 측정하는데 적합하지 않다.

단조시계

• 타임아웃이나 응답시간 같은 지속시간을 재는데 적합하다.
  • 시계의 절대적인 값은 의미가 없고 차이로 확인하는것
• NTP 는 컴퓨터의 로컬시계가 NTP 서버보다 빠르거나 느리다는 것을 발견하면 진도수를 조정한다.

>>> import time
>>> time.monotonic()
3116866.639936023
>>>

NTP (network time protocol) ; 네트웍 시각 프로토콜

"NTP"는 네트웍으로 연결되어 있는 컴퓨터들끼리 클록 시각을 동기화시키는데 사용되는 프로토콜이다.

"NTP"는 미국 델라웨어 대학의 데이빗 밀스에 의해 처음 개발되었으나, 이제는 인터넷 표준이 되었다.

"NTP"는 컴퓨터 클록 시간을 1/1000 초 이하까지 동기화시키기 위해 협정 세계시각(UTC)을 사용하게 됩니다.                                                                                                                               - www.terms.co.kr -

시계 동기화와 정확도

• 단조 시계는 동기화가 필요없지만 일기준 시계는 ntp등의 외부 출처와 동일해야 유용하다.
  • 시계의 drift, 로컬시계의 강제리셋, ntp 서버의 이상, 윤초를 고려하지 않은 설계 …

동기화된 시계에 의존하기

• 시계는 간단해 보이지만 놀랄만한 수의 함정이 있다는게 문제다.
• 동기화된 시계를 사용한다면 모든 장비사이의 시계를 모니터링 해야한다., 시차가 많이 나는 것은 죽은 것으로 처리하고 클러스터에서 제거한다.

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

• 두 클라이언트가 분산 데이터베이스에 쓰면 누가 먼저쓰게 될까? 누가 쓴게 더 최근것이 될까?
  • 각자 가지고 있는 시계가 잘 동기화 되어있어도 어떤 것이 옳은 이벤트 순서인지 알 수 없다.
• LWW: last write wins - 가장 최근 쓰기를 선택한다. 예시에서는 타임스탬프가 더 빠른 작업이 누락되는 것이다.
  • 가장 최근 값을 유지하고 다른 것을 버리는 것
• logical clock은 카운터를 기반으로 하여 이벤트 순서화의 안전한 대안이다. 이벤트ㅢ 상대적인 순서만 측정하는 것이다.
  • 반대 개념으로 physical clock이 있다.

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

• 세밀하게 읽을 수는 있지만, 그것이 정밀하다는 것은 아니다.
  • 읽기를 시점으로 생각하는 것은 타당하지 않다. 신뢰구간에 속하는 시간의 범위로 읽는게 나을 것이다.
  • 그리고 이런 불확실성을 노출하지 않는다. 알 수 없다.
• 구글 True time: 요청하면 가능한 timestamp 범위를 알려준다.

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

프로세스 중단

• Lease: 다른 노드로부터 임차권을 얻어 타임아웃이 있는 잠금을 확인한다.

 

출처

데이터 중심 애플리케이션 설계 : 네이버 도서