조용한 개발 노트

잘 설계된 시스템과 운영 가능한 시스템은 다르다분산 시스템은 설계만으로 완성되지 않는다.아무리 이론적으로 완벽해 보여도, 운영 단계에서 다음 질문에 답하지 못하면 실패한다.문제가 생겼을 때, 우리는 무엇을 보고 어떻게 판단하는가이 글에서는 지금까지 다룬 모든 개념을 운영 가능성이라는 하나의 기준으로 정리한다.운영 가능성의 출발점은 실패 수용이다운영 가능한 시스템은 실패를 막으려 하지 않는다.Partial Failure는 항상 존재한다지연과 중복은 제거할 수 없다일부 요청 실패는 정상 상태다운영의 목표는 실패를 통제 가능한 상태로 유지하는 것이다.SLO는 왜 필요한가운영 가능한 시스템은 성공과 실패를 감정이 아니라 수치로 정의한다.이를 위해 등장한 개념이 SLO(Service Level Objective)..

보이지 않으면 통제할 수 없다분산 시스템은 정상과 비정상의 경계가 흐리다.일부 요청만 실패한다특정 구간에서만 지연이 발생한다장애는 천천히 퍼진다이런 환경에서 단순한 모니터링만으로는 무엇이 일어나고 있는지 알 수 없다.그래서 분산 시스템에서는 Observability가 필수가 된다.Observability는 모니터링이 아니다모니터링은 보통 다음 질문에 답한다.CPU 사용률은 얼마인가에러율이 증가했는가서버는 살아 있는가하지만 분산 시스템에서 더 중요한 질문은 이것이다.왜 이 요청이 실패했는가Observability는 내부 상태를 추론할 수 있는 능력을 의미한다.왜 분산 시스템은 본질적으로 불투명한가분산 시스템은 다음 이유로 본질적으로 불투명하다.요청이 여러 서비스와 노드를 거친다부분 실패가 정상 동작처럼 보..

시간은 믿을 수 있다는 착각분산 시스템을 설계할 때, 우리는 무의식적으로 시간을 신뢰한다.먼저 발생한 이벤트나중에 처리된 요청이전 상태와 이후 상태하지만 분산 환경에서 시간은 공통 기준이 아니다.이 착각은 시스템을 가장 교묘하게 무너뜨린다.분산 시스템에는 하나의 시간이 없다단일 서버에서는 시간이 단순하다. 시스템 클록 하나만 믿으면 된다.하지만 분산 시스템에서는:노드마다 클록이 다르다클록은 항상 어긋난다동기화는 완벽하지 않다즉, “언제 발생했는가”라는 질문은 노드에 따라 다른 답을 가진다.Clock Skew는 예외가 아니라 상수다Clock Skew는 서버 간 시간 차이를 의미한다.NTP를 사용하더라도:네트워크 지연일시적인 동기화 실패VM 또는 컨테이너 재시작으로 인해 Skew는 항상 존재한다.따라서 시간..

트랜잭션은 경계가 명확할 때만 강력하다단일 데이터베이스에서의 트랜잭션은 매우 강력하다. 원자성, 일관성, 격리성, 지속성이라는 명확한 약속이 있다.하지만 시스템 경계를 넘는 순간, 이 약속은 급격히 약해진다.분산 트랜잭션의 문제는 구현 난이도가 아니라 전제가 깨진 환경에서 동일한 약속을 요구하는 데서 시작된다.분산 트랜잭션이 필요한 순간다음과 같은 요구가 등장할 때, 사람들은 분산 트랜잭션을 떠올린다.여러 서비스의 상태를 한 번에 변경해야 한다메시지 처리와 DB 변경을 동시에 보장해야 한다중간 실패 없이 일관된 결과를 만들고 싶다문제는 이 요구들이 앞서 살펴본 모든 실패 전제와 충돌한다는 점이다.2PC는 무엇을 약속하는가Two-Phase Commit(2PC)는 분산 트랜잭션의 가장 대표적인 프로토콜이다...

확장성의 해답처럼 보이는 선택트래픽과 데이터가 증가하면, 시스템은 결국 하나의 한계에 도달한다.이때 가장 자연스럽게 떠오르는 해법이 Sharding과 Partitioning이다.데이터를 나누면:부하가 분산되고처리량이 증가하며확장이 쉬워질 것처럼 보인다하지만 데이터를 나누는 순간, 시스템은 새로운 종류의 복잡성을 떠안는다.Sharding과 Partitioning은 무엇이 다른가두 용어는 종종 혼용되지만, 의미는 다르다.Partitioning데이터를 여러 조각으로 나눔하나의 논리적 시스템 안에서 관리ShardingPartition을 서로 다른 노드에 배치독립적인 장애 도메인 생성Partitioning이 구조적 분리라면, Sharding은 운영적 분리다.Shard Key가 모든 것을 결정한다Sharding 설..

복제는 안정성을 높이지만, 단순하지 않다Replication은 분산 시스템에서 가장 직관적인 안정성 전략이다. 데이터를 여러 노드에 복제하면, 하나가 실패해도 다른 노드가 이를 대신할 수 있다.하지만 복제는 단순한 안전장치가 아니다. 복제를 도입하는 순간, 시스템은 동기화 비용과 관찰 불일치를 함께 떠안게 된다.Replication은 무엇을 보장하는가Replication이 보장하는 것은 명확하다.단일 노드 장애로 인한 데이터 손실 위험 감소읽기 트래픽 분산 가능가용성 향상하지만 Replication이 보장하지 않는 것도 분명하다.항상 최신 데이터 제공즉각적인 동기화관찰 결과의 일관성이 간극에서 Replication Lag가 발생한다.Replication Lag란 무엇인가Replication Lag는 쓰기..

정합성은 하나의 개념이 아니다분산 시스템에서 Consistency라는 단어는 너무 자주, 너무 넓게 사용된다.그 결과 이런 혼란이 생긴다.어디까지가 강한 정합성인가Eventual Consistency는 언제 안전한가Linearizable과 Serializable은 무엇이 다른가이 글에서는 Consistency Model을 기능 설명이 아니라 시스템의 행동 규칙으로 정리한다.Consistency Model이란 무엇인가Consistency Model은 분산 시스템이 클라이언트에게 약속하는 관찰 가능성의 규칙이다.즉, 다음 질문에 대한 답이다.여러 클라이언트가 동시에 접근할 때, 무엇을 볼 수 있는가중요한 점은, Consistency Model은 내부 구현이 아니라 외부에서 관찰되는 결과를 정의한다는 것이다...

Exactly-once는 기능이 아니라 환상에 가깝다분산 시스템을 다루다 보면 자주 듣는 요구가 있다.메시지를 정확히 한 번만 처리하고 싶다표현은 단순하지만, 이 요구는 분산 시스템의 거의 모든 전제와 충돌한다.이 글에서는 Exactly-once를 “지원 여부”가 아니라 왜 시스템 전반에서는 성립하기 어려운 개념인지를 살펴본다.Exactly-once를 어떻게 오해하고 있는가Exactly-once는 흔히 다음과 같이 오해된다.메시지가 한 번만 전달된다소비자가 한 번만 실행된다중복 처리가 절대 발생하지 않는다하지만 분산 시스템에서 Exactly-once가 의미하는 바는 이와 다르다.같은 결과가 한 번만 반영된다문제는 이 결과가 여러 시스템과 상태에 걸쳐 존재한다는 점이다.왜 At-least-once가 기본값..

안정성을 높이기 위한 장치가 왜 장애를 키우는가Timeout, Retry, Backoff는 분산 시스템에서 가장 흔히 사용하는 안정성 장치다.문제는 이 세 가지가 결합되는 순간, 시스템이 장애를 완화하는 방향이 아니라 증폭하는 방향으로 동작할 수 있다는 점이다.이 글에서는 각 기법의 사용법이 아니라, 왜 이 조합이 구조적으로 위험해지는지를 살펴본다.Timeout은 실패 감지 장치가 아니다Timeout은 흔히 “요청이 실패했음을 감지하는 수단”으로 오해된다.하지만 실제로 Timeout이 의미하는 것은 이것이다.이 시간 안에는 응답을 기다리지 않겠다즉, Timeout은 실패 판별이 아니라 기다림을 포기하는 시점이다.이 차이를 이해하지 못하면, Timeout 설정은 곧잘 잘못된 선택으로 이어진다.Timeout..

CAP 이론을 아는 것과, 선택하는 것은 다르다CAP 이론은 분산 시스템을 다루는 사람이라면 누구나 한 번쯤 접한다. Consistency, Availability, Partition tolerance 중 두 가지만 선택할 수 있다는 설명은 잘 알려져 있다.하지만 실제 시스템에서 중요한 질문은 이것이 아니다.지금 이 순간, 이 요청에 대해 무엇을 포기할 것인가이 글에서는 CAP을 이론으로 설명하지 않는다. 실제 시스템이 어떤 상황에서 어떤 선택을 강요받는지를 중심으로 살펴본다.Partition은 선택이 아니라 전제다CAP을 오해하게 만드는 가장 큰 이유는 Partition을 마치 선택지처럼 받아들이기 때문이다.현실의 분산 시스템에서 Partition은 다음과 같은 형태로 항상 발생한다.네트워크 지연패킷 ..