N° 01 — 목록
'Software Architecture/Distributed Systems' (12)
-
Software Architecture/Distributed SystemsDistributed Systems - 12. 회복탄력성
회복탄력성 패턴 — 장애가 전파되는 것을 막는 법2015년 한 시스템에서 한 하위 서비스가 30초간 응답 지연을 일으켰다. 호출하던 상위 서비스가 스레드 풀을 모두 점유당해 응답 불능에 빠졌다. 그 상위 서비스를 호출하던 더 상위 서비스도 같은 운명을 겪었다. 4단계 위의 서비스까지 멈췄다 — 한 서비스의 지연이 연쇄적으로 전파돼 전체 장애가 됐다. 01편(분산의 8가지 오해)에서 본 "네트워크는 신뢰할 수 없다"를 코드로 방어하지 않은 결과. 이 장애를 막는 패턴들이 회복탄력성(resilience)이다. timeout, retry, circuit breaker, bulkhead, load shedding — 이 패턴들이 분산 시스템의 장애를 국소화하고 전파를 차단한다.비유로 감 잡기 — 배의 격벽과 퓨..
-
Software Architecture/Distributed SystemsDistributed Systems - 11. 서비스 디스커버리·게이트웨이
서비스 디스커버리와 API 게이트웨이 — 클라이언트가 어디로 보낼까2016년 한 회사가 30개의 마이크로서비스를 운영했다. 각 서비스의 URL이 설정 파일에 적혀 있었다. 어느 날 인프라팀이 로드 밸런서를 교체하면서 모든 서비스의 IP가 바뀌었다. 설정 파일을 모두 수정하고 재배포하는 데 하루가 걸렸다. 그 사이 프로덕션은 중단됐다. 서비스가 어디 있는지 알아내는 것조차 복잡한 작업이 된 것이다. 또 다른 문제 — 30개 서비스마다 각자 인증, 속도 제한, 로깅을 구현했는데, 코드가 중복되고 정책이 어긋났다. 이 두 문제를 다루는 패턴이 서비스 디스커버리와 API 게이트웨이다. 이 글은 두 패턴과 그 현대적 변형인 서비스 메시까지 다룬다.비유로 감 잡기 — 호텔 프론트 데스크큰 호텔에 왔다고 상상하자. ..
-
Software Architecture/Distributed SystemsDistributed Systems - 10. 일관적 해싱
일관적 해싱 — 노드 추가/제거 시 최소 이동2014년 한 시스템이 4개 노드로 운영되다가 트래픽이 늘어 5개로 확장했다. 해시 파티셔닝(05편)을 썼기 때문에, 노드가 4→5로 바뀌자 전체 데이터의 80%가 다른 노드로 이동해야 했다. 클러스터가 몇 시간 동안 비정상적으로 동작했고, 확장은 실패로 끝났다. 노드 하나를 추가했을 뿐인데 데이터 대부분이 움직이는 현상 — 이건 해시 분할의 근본적 한계다. 이 한계를 해결하는 기법이 일관적 해싱(consistent hashing)이다. 1997년 David Karger 등이 발표한 이 기법은 — 노드가 추가·제거될 때 데이터 이동을 최소화한다. 오늘날 Dynamo, Cassandra, Memcached, CDN이 쓰는 핵심 기법이다.비유로 감 잡기 — 원형 ..
-
Software Architecture/Distributed SystemsDistributed Systems - 09. 시간·순서·클럭
시간, 순서, 클럭 — 분산 시스템에서 "먼저"를 정하는 법2018년 한 분산 데이터베이스에서 두 사용자가 거의 동시에 같은 계좌에서 출금했다. 한 요청은 서울 노드에, 다른 요청은 부산 노드에 도착했다. 두 노드는 각자 자기 요청을 먼저 처리했다고 기록했다. 왜냐 — 두 노드의 시계가 7ms 차이가 났기 때문이다. 서울 노드의 시계가 10:00:00.007이었고, 부산 노드의 시계가 10:00:00.000이었을 때, 두 요청의 실제 도착 시간이 정확히 같았다면 — 두 노드는 서로 다른 "먼저"를 기록한다.어느 쪽이 "진짜 먼저"인가. 이 질문에 답하지 못해 시스템은 임의로 한쪽을 골랐다가 사용자 불만을 받았다. 모놀리스였다면 — 단일 시계가 "이 쪽이 1ms 빨랐다"라고 결정했을 것이다. 분산에선 시계..
-
Software Architecture/Distributed SystemsDistributed Systems - 08. 멱등성·정확히 한 번
멱등성과 정확히 한 번 — "exactly-once" 함정 파헤치기2020년 한 결제 시스템에서 같은 결제가 두 번 처리된 사고가 터졌다. 사용자는 한 번 결제했는데, 계좌에서 두 번 빠져나갔다. 조사해보니 — 네트워크 지연으로 결제 서비스가 응답을 못 받은 클라이언트가 재시도했고, 결제 서비스는 같은 요청을 두 번 처리했다. "이런 건 왜 생기나. exactly-once 보장하면 되지 않나?"라는 질문이 자연스럽다. 이 질문에 대한 답이 이 글의 핵심이다. 결론부터 말하면 — end-to-end exactly-once는 매우 어렵고, 대부분 at-least-once + 멱등성으로 달성한다. "exactly-once"를 마케팅 문구처럼 쓰는 시스템은 사실 이 조합을 숨기는 것이다.비유로 감 잡기 — 우편..
-
Software Architecture/Distributed SystemsDistributed Systems - 07. 분산 트랜잭션
분산 트랜잭션 — 분산 환경에서 원자성을 어떻게 보장할까2016년 한 항공 예약 시스템에서 사용자의 예약과 결제가 분리된 서비스로 옮겨갔다. 사용자가 예약을 하면 — 예약 서비스가 좌석을 잠그고, 결제 서비스에 결제를 요청했다.어느 날 결제 서비스가 응답하다가 죽었다. 예약 서비스는 좌석을 잠갔지만, 결제가 됐는지 안 됐는지 몰랐다. 사용자는 돈은 안 빠졌는데 좌석이 잠겨 있다고 불만을 넣었다. 다른 사용자는 그 좌석을 예약하려다 실패했다. 한 트랜잭션으로 묶이지 않은 두 서비스의 변경이 — 중간 상태에 멈춘 것이다.모놀리스였다면 — 예약과 결제가 한 DB 트랜잭션에 묶여 있었다. 둘 다 성공하거나 둘 다 실패했다. 분산에선 그게 안 된다. 두 서비스가 각자 DB를 가지니 한 트랜잭션으로 묶을 수 없다...