Page tree
Skip to end of metadata
Go to start of metadata
  • 분산 시스템을 다루는 것은 한 컴퓨터에서 실행되는 소프트웨어를 작성하는 일과는 근본적으로 다르다.
  • 핵심적인 차이는 뭔가 잘못될 수 있는 새롭고 흥미진진한 방법이 많다.

결함과 부분 장애

  • 분산 시스템에서는 시스템의 어떤 부분은 잘 동작하지만 다른 부분은 예측할 수 없는 방식으로 고장난다. (부분장애)
  • 이 부분 장애 가능성과 비결정성이 분산 시스템을 다루기 어렵게 한다.
  • 클라우드 컴퓨팅과 슈퍼 컴퓨터가 부분 장애를 다루는 방법
    • 슈퍼 컴퓨터는 부분 장애를 전체 장애로 확대한다.
    • 시스템의 어느 부분이 죽으면 그냥 전체를 죽인다.
    • 분산 시스템은 이와 다르게 부분 장애 가능성을 받아들이고 소프트웨어에 내결함성 메커니즘을 넣어야 한다.
    • 몇 개의 작은 노드만으로 구성된 작은 시스템이라도 부분 장애를 고려하는 것은 중요하다.
      • 처음에는 잘 동작하겠지만, 결국은 문제를 일으킬 것이다.
    • 결함 처리는 소프트웨어 설계의 일부여야 하며, 개발자는 결함이 발생할 때 소프트웨어가 어떻게 동작할지 반드시 알고 있어야 한다.
    • 분산 시스템에서 의심, 비관주의, 편집증은 값어치가 있다.

신뢰성 없는 네트워크

  • 네트워크는 다른 노드로 요청을 보내서 응답을 받지 못했을 때 그 이유를 아는 것이 불가능하다.
    • 이를 다루기 위해 가장 흔하게 사용하는 방법이 타임아웃이다.
  • 현실의 네트워크
    • 네트워크 장비를 아무리 이중화 구성하고 노드를 더 추가해도 장애 감소에 큰 도움을 주지 못한다.
    • 결국 최고의 장애 원인인 인적 오류를 막을 수 없기 때문이다.
    • 상상을 초월한 장애 원인들
      • 상어가 해저 케이블을 물어 뜯거나 (책내용)
      • 음주운전자가 공조시설을 들이 받거나 (책내용)
      • 데이터센터 내 카트를 움직이다가 바닥형 소방 장치를 건드려서 터진다거나 (경험담)
    • 네트워크 결함의 오류 처리가 정의되고 테스트되지 않는다면 상상을 초월하는 나쁜 일이 벌어질 수 있다.
      • 데이터를 다 지워버린다거나
      • 영구적으로 처리할 수 없는 데이터 손실이 발생하거나
    • 고의로 네트워크 장애를 발생시키고 시스템의 반응을 테스트하는 것은 충분히 일리가 있다.
  • 타임아웃과 기약 없는 지연
    • 시스템이 이미 높은 부하에 허덕이는 중이라면 성급하게 노드가 죽었다고 하면 더 문제가 악화될 수 있다.
    • 실제로는 살아 있는데 과부하 때문에 응답이 느리기만 한 상태일 수 있다.
      • 극단적인 경우 모든 노드가 서로 죽었다고 선언해서 시스템 전체가 중지될 수 있다.
  • 네트워크 혼잡과 큐 대기
    • 컴퓨터 네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많다.
  • 위와 같이 복잡한 상황 때문에 고정된 타임아웃을 설정하는 건 좋은 방법이 아니다.
    • 변동성을 측정하고 관찰된 응답 시간 분포에 따라 타임아웃을 자동으로 설정하도록 jitter를 설정하는 쪽이 가장 좋다.
  • 대개의 네트워크 문제는 지연 때문에 발생한다.
  • 원인을 제거하는 게 가장 좋기 때문에 네트워크 지연을 완전히 없애기 위한 시도가 몇번 있었다.
    • 하지만 근본적으로 TCP는 이런 동작을 제공할 수 없다.
    • 전화회선은 가능하겠지만, TCP 프로토콜은 전화와는 근본적으로 다르다.

신뢰성 없는 시계

  • 메시지를 받은 시간은 항상 보낸 시간보다 나중이지만 네트워크 지연 변동성 대문에 얼마나 나중인지는 알 수 없다.
  • 이를 해결하기 위해 가장 널리 쓰이는 해결방안은 NTP를 쓰는 방안이다.
  • 단조 시계와 일 기준 시계
    • 현대 컴퓨터는 최소 이 두가지 시계는 반드시 갖고 있다.
    • 일 기준 시계는 직관적으로 시계에 기대하는 역할을 한다.
      • 특정 달력에 따라 현재 날짜와 시간을 반환한다.
    • 단조 시계는 타임아웃이나 서비스 응답시간 같은 지속 시간을 재는 데 적합하다.
      • 한 시점에서 단조 시계의 값을 확인하고 어떤 일을 한 후 나중에 다시 시계를 확인할 수 있다.
      • 두 값의 차이로 시간이 얼마나 흘렀는지 알 수 있지만, 이 절대값이 의미 있는 건 아니다.
  • 시계 동기화와 정확도
    • 단조 시계는 동기화가 필요 없지만 일 기준 시계는 NTP 서버나 다른 외부 시간 출처에 맞춰 설정돼야 유용하다.
    • 시계가 정확한 시간을 알려주게 하는 방법은 기대만큼 신뢰성이 있거나 정확하지 않다.
    • 컴퓨터 시계는 드리프트(더 빠르거나 더 느리거나) 현상이 생기기 때문에 아주 정확하지는 않다.
      • 드리프트는 장비의 온도에 따라 발생한다.
    • NTP 클라이언트는 여러 서버에 질의를 보내고 다른 것과 큰 차이가 나는 값을 무시하므로 생각보다 상당히 견고하다.
  • 대부분의 시계는 잘 동작하지만 시계가 잘못된 경우에도 반드시 대비해야 한다.
  • 이벤트 순서화용 타임스탬프
    • 가장 나중의 타임스탬프 값을 최종값으로 인정하는 충돌 해소 전략을 최종 쓰기 전략이라 한다.
    • 문제는 애플리케이션에 어떤 오류도 없었지만 임의의 양의 데이터가 조용히 유실되는 문제가 발생할 수 있다.
    • "최근"의 정의는 로컬 일 기준 시계에 의존하며 그 시계는 틀릴 수 있다는 것을 반드시 알아야 한다.
  • 일 기준 시계는 마이크로초 해상도로 읽을 수 있지만, 실제로 그 정도의 정확성을 제공한다는 의미가 아니다.
  • 전역 스냅용 동기화된  시계
    • 분산 환경에서 가장 흔한 스냅숏 격리 구현은 단조 증가하는 트랜잭션 ID를 사용하는 방안이다.
    • 이 용도로 시계 동기화를 쓰는 방안이 활발히 연구되고 있지만 실제로 주류 데이터베이스에 구현된 사례는 없다.
  • 시계를 통해 분산 시스템에서 리더 노드를 결정하면 위험할 수 있다.
    • 분산 시스템에서 스레드는 오랫동안 멈출 수 있다.
    • 시계 측정도 마찬가지다.
    • 후에 다룰 합의 알고리즘을 사용해야 한다.

요약

  • 분산 시스템에서는 흔히 우리가 신뢰할만하다 생각한 것 중 진짜 신뢰할 수 있는 게 많지 않다.
  • 신뢰한다 믿는 것들이 망가질 때를 대비하고 설계해야 한다.
  • No labels