52. 실전 운영에서 마주하는 분산 시스템의 대가(Cost): 지연 시간과 파티션 허용 오차

🚀 들어가며: 분산 시스템이라는 양날의 검

안녕하세요. Hans 입니다.

현대 백엔드 아키텍처에서 분산 시스템(Distributed Systems)은 거부할 수 없는 대세로 자리 잡았습니다. 단일 고성능 머신(Scale-up)에 의존하는 대신, 여러 대의 독립적인 컴퓨팅 리소스(노드)에 작업 부하를 분산(Scale-out)시키는 구조는 대규모 트래픽을 처리하는 조직에게 필수적입니다.

우리가 많은 비용과 노력을 들여 분산 시스템을 구축하는 이유는 명확합니다.

1. 확장성(Scalability): 필요에 따라 노드를 추가해 증가하는 트래픽을 선형적으로 처리할 수 있습니다.
2. 내결함성(Fault Tolerance): 특정 서버나 지역의 노드가 다운되더라도 시스템 전체가 멈추지 않고 사용자 요청을 계속 처리해 다운타임을 최소화합니다.

하지만 현업에서 분산 시스템을 도입하고 막 운영하기 시작한 개발자라면 곧 거대한 벽에 부딪히게 됩니다. 시니어 엔지니어들이 이를 분산 시스템의 "어두운 면(The Dark Side)"이라 부르는 이유가 있습니다.

단일 머신 환경에서는 당연하게 여겼던 즉각적인 데이터 일관성, 신뢰할 수 있는 로컬 호출이 무너집니다. 우리는 예측할 수 없는 네트워크 지연을 다뤄야 하고, 동시다발적인 충돌 쓰기 작업을 제어해야 하며, 부분적인 오류 속에서도 시스템을 정상 유지해야 하는 복잡한 숙제를 안게 됩니다.

그 중심에 늘 존재하는 두 가지 핵심 고려사항이 바로 지연 시간(Latency)과 파티션 허용 오차(Partition Tolerance)입니다.

⚖️ 1. 아키텍처의 숙명: CAP 정리의 세 가지 축

분산 시스템의 구조적 한계를 명확히 규정하는 것이 바로 CAP 정리입니다. 시스템의 기능적·비기능적 요구사항을 설계할 때 아래의 세 가지 속성을 동시에 모두 만족하는 분산 시스템은 존재할 수 없습니다.

• 일관성 (Consistency): 모든 읽기(Read) 요청은 어떤 노드로 접근하든 항상 가장 최근에 업데이트된 동일한 데이터를 반환받아야 합니다.
• 가용성 (Availability): 모든 요청은 실패(에러) 없이 정상적인 응답을 받아야 합니다. (다만 최신 데이터라는 보장은 없을 수 있습니다.)
• 파티션 허용 오차 (Partition Tolerance): 노드 간의 통신이 단절되거나 메시지가 유실되는 네트워크 파티션 장애가 발생하더라도 시스템이 중단 없이 계속 작동해야 합니다.

실제 현실 세계의 물리 네트워크는 유실과 지연이 불가피하므로, 분산 시스템은 반드시 파티션 허용 오차(P)를 확보해야 합니다. 따라서 실질적인 선택은 CP(일관성 중심)와 AP(가용성 중심) 사이의 밸런스 게임이 됩니다. 네트워크가 찢어졌을 때 데이터를 엄격하게 맞출 것인가(CP), 아니면 조금 오래된 데이터라도 일단 빠르게 응답을 줄 것인가(AP)를 비즈니스 도메인에 맞춰 조율해야 합니다.

⏳ 2. 지연 시간(Latency)의 실체와 RTT

단일 머신 안에서의 프로세스 간 통신(IPC)이나 메모리 접근은 마이크로초($\mu s$) 단위로 끝나지만, 네트워크를 타는 순간 밀리초($ms$) 단위의 지연 시간이 발생합니다. 분산 시스템에서 총 지연 시간은 단순히 서버 내부의 연산 시간만이 아니라, 왕복 시간인 RTT(Round Trip Time)를 기준으로 계산해야 합니다.

• User Request (네트워크 상행): $400ms$ 소요
• Server Response (네트워크 하행): $500ms$ 소요
• Total Latency (RTT): $400ms + 500ms = 900ms$

단 하나의 요청-응답 쌍만으로도 네트워크 환경에 따라 수백 밀리초가 누적될 수 있습니다. 만약 마이크로서비스 아키텍처(MSA) 환경에서 하나의 비즈니스 로직을 처리하기 위해 내부 노드들끼리 동기식 원격 호출을 무분별하게 남발하고 있다면, 이 RTT가 그대로 누적되어 최악의 사용자 경험(UX)으로 이어지게 됩니다.

🗂️ 3. 복제 아키텍처의 선택: 리더 기반 vs 리더 없는 구조

데이터의 유실을 막고 가용성을 높이기 위해 여러 노드에 복제본을 두는 방식 또한 지연 시간과 데이터 정합성에 막대한 영향을 미칩니다.

① 리더 기반 복제 (Leader-based Replication)

하나의 특정 노드가 리더(Leader/Primary)가 되어 모든 쓰기(Write) 요청을 독점 처리하고, 나머지 팔로워(Follower/Secondary) 노드들로 데이터를 복제하는 방식입니다.

• 특징: 쓰기 순서가 리더에 의해 제어되므로 데이터 충돌 관리가 비교적 단순합니다.
• 운영 포인트 (Critical Reads): 클라이언트가 쓰기 작업을 수행한 직후 팔로워 노드에서 데이터를 읽을 때, 복제 지연(Lag)으로 인해 옛날 데이터를 보게 되는 현상이 생길 수 있습니다. 이를 막으려면 본인이 쓴 중요한 데이터는 리더 노드에서 직접 읽도록 강제하는 Critical Reads 경로를 정교하게 설계해야 합니다.

리더 기반 복제(Leader-based Replication)

② 리더 없는 복제 (Leaderless Replication)

리더의 개념 없이 클라이언트가 여러 개의 레플리카 노드에 쓰기 요청을 동시에 전송하고, 설정된 기준 개수 이상의 노드로부터 응답(ACK)을 받으면 성공으로 간주하는 방식입니다.

• 특징: 특정 단일 노드의 장애에 영향을 받지 않으므로 가용성이 극대화되지만, 여러 노드에 동시다발적으로 데이터가 쓰이면서 발생하는 쓰기 충돌(Conflict) 해결 로직을 애플리케이션 레벨에서 직접 감당해야 하는 부담이 생깁니다.

리더 없는 복제(Leaderless Replication)

🛠️ 4. 동기화의 트레이드오프: 지속성(Durability) vs 지연 시간(Latency)

복제를 처리할 때 비동기식 복제(Async Replication)를 선택하면, 리더 노드는 자신의 로컬에 데이터를 쓰고 나서 팔로워로 복제 요청을 보낸 뒤 팔로워의 응답을 기다리지 않고 즉시 클라이언트에게 성공을 반환합니다.

• 장점 (낮은 지연 시간): 팔로워 노드로 가는 네트워크 지연($5ms$ 또는 $8ms$)을 기다릴 필요가 없어 클라이언트가 체감하는 응답 속도가 매우 빠릅니다.
• 단점 (데이터 유실 위험): 팔로워가 최신 데이터를 반영하기 전까지 시스템은 최종 일관성(Eventual Consistency) 상태에 머물게 되며, 만약 리더 노드가 복제본을 팔로워에게 넘겨주기 전에 갑작스럽게 다운되면 해당 데이터는 영구 유실될 위험이 있습니다.

반대로 데이터의 철저한 지속성(Durability)을 보장하고 싶다면 어떻게 해야 할까요?

리더는 쓰기 요청을 받은 후 팔로워에게 데이터를 복제하고, 팔로워가 업데이트에 성공했다는 신호(Success ACK)를 보내올 때까지 기다려야(Waiting for Follower Update) 합니다. 이 동기식 대기는 데이터 안정성을 극대화하지만, 네트워크 상태에 따라 전체 시스템의 지연 시간을 크게 증가시키는 대가를 치르게 만듭니다.

💡 5. 초보 분산 시스템 운영자를 위한 실전 가이드

분산 시스템의 어두운 면에 휩쓸리지 않고, 안정적으로 아키텍처를 안착시키기 위해 우리가 실천해야 할 지침입니다.

1. 네트워크는 언제나 실패할 수 있음을 인정하라 (Design for Failure)
2. 네트워크 파티션은 피할 수 없는 현실입니다. 타임아웃(Timeout) 값을 무조건 촘촘하게 설정하고, 실패 시 재시도(Retry) 전략을 세우되 시스템에 부하를 연쇄적으로 주지 않도록 지수 백오프(Exponential Backoff)와 지터(Jitter)를 반드시 조합해야 합니다.
3. 비즈니스 요구사항에 맞춰 완급을 조절하라
4. 결제나 잔액 관리처럼 단 1원의 오차도 허용할 수 없는 도메인은 지연 시간을 감수하더라도 엄격한 일관성(CP)과 동기식 지속성을 확보해야 합니다. 반면, SNS의 '좋아요' 수나 추천 피드는 수초 간 데이터가 맞지 않아도 서비스에 지장이 없으므로 비동기 복제 기반의 가용성(AP)과 최종 일관성을 적극적으로 채택해야 합니다.
5. 핵심 지표의 모니터링 및 시각화
6. 노드 간 RTT, 복제 지연 시간(Replication Lag), 그리고 상위 99%의 사용자가 겪는 꼬리 지연 시간(p99 Latency)을 관측 가능한 대시보드로 구축하세요. 분산 시스템의 숨은 버그나 병목은 평균값이 아닌 꼬리 지연 시간에서 발견됩니다.

🏁 맺으며

분산 시스템이 주는 화려한 '확장성'과 '내결함성'의 무대 뒤편에는, 개발자가 온전히 통제하고 타협해야 할 '지연 시간'과 '네트워크 파티션'이라는 그림자가 존재합니다. 이 어두운 면을 피하기보다, 내가 다루는 도메인의 비즈니스 성격에 맞게 트레이드오프를 명확히 설계하는 것만이 진정한 분산 시스템 엔지니어로 성장하는 길입니다.

지금 여러분이 운영 중인 서비스의 복제 방식과 타임아웃 전략은 어떻게 설계되어 있는지 다시 한번 점검해 보는 계기가 되기를 바랍니다.

 

Thanks

Hans