N° 01 — 목록
'distributed-systems' (12)
-
Software Architecture/Distributed SystemsDistributed Systems - 06. 복제 패턴
복제 패턴 — 데이터 복사본의 일관성과 가용성2017년 한 서비스가 읽기 부하를 분산시키려고 PostgreSQL에 읽기 복제본을 3개 추가했다. 마스터 DB의 쓰기는 비동기로 복제본에 복제됐다. 며칠 뒤 사용자 불만이 접수됐다 — "방금 게시글 썼는데 피드에 안 떠요". 조사해보니, 사용자의 쓰기는 마스터에 갔지만, 같은 사용자의 직후 읽기는 복제본에 갔고, 복제 지연(보통 수백 ms, 부하 시 수 초)이 발생했다. 사용자는 자기가 방금 쓴 글이 안 보이는 현상을 겪은 것이다. read-your-writes 위반의 전형적 사례. 복제는 데이터 가용성과 읽기 성능을 높이지만, 복제 지연이라는 새로운 일관성 문제를 만든다. 이 글은 복제의 세 가지 형태와 그 trade-off를 다룬다.비유로 감 잡기 — 사..
-
Software Architecture/Distributed SystemsDistributed Systems - 05. 파티셔닝과 샤딩
파티셔닝과 샤딩 — 데이터가 한 노드에 안 들 때2019년 한 SaaS 회사의 주문 테이블이 2TB를 넘겼다. 단일 PostgreSQL 인스턴스에 적재했더니 디스크 I/O가 병목이 돼 쿼리가 10배 느려졌다. 가장 비싼 인스턴스로 올려도 한계가 드러났다 — RAM에 인덱스가 다 안 들어가서 디스크 읽기가 폭증했다. "더 비싼 서버"라는 해결책이 다했던 시점이다. 다음 단계는 — 데이터를 여러 노드로 나누는 것, 즉 파티셔닝(partitioning) 또는 샤딩(sharding)이다. 둘은 같은 개념의 다른 이름이다 (샤딩은 주로 데이터베이스 맥락에서, 파티셔닝은 더 일반적으로 쓰인다). 이 글은 데이터를 어떻게 나눌까, 나누면서 생기는 새로운 문제를 어떻게 다룰까를 다룬다.비유로 감 잡기 — 도서관 책을 ..
-
Software Architecture/Distributed SystemsDistributed Systems - 04. 합의 알고리즘
합의 알고리즘 — 여러 노드가 하나의 값을 정하는 법2019년 한 Elasticsearch 클러스터에서 split-brain(뇌 분리)이 발생했다. 두 데이터센터 사이 네트워크가 30초간 끊겼다. 양쪽 데이터센터의 노드가 각자 자기를 "마스터"로 선언했다. 두 마스터는 같은 데이터에 서로 다른 쓰기를 적용했다. 네트워크가 복구됐을 때 두 마스터의 상태가 충돌했고, 시스템은 어느 쪽이 진짠지 결정하지 못해 일부 데이터를 잃었다.이 사태의 원인은 — "누가 진짜 마스터인가"를 노드들이 동의하지 못한 것이다. 합의(consensus)가 없었다. 분산 시스템에선 이런 "동의"가 필요한 상황이 자주 온다 — 누가 리더인가, 다음 연산은 무엇인가, 클러스터에 새 노드를 추가할까. 이 글은 여러 노드가 하나의 값에 ..
-
Software Architecture/Distributed SystemsDistributed Systems - 03. 일관성 모델
일관성 모델 — 강한 일관성과 최종 일관성 사이의 스펙트럼2018년 한 SaaS 회사에서 사용자가 프로필을 수정한 직후 "저장됐다"는 메시지를 받았다. 새로고침하니 예전 프로필이 떴다. 사용자는 "저장이 안 됐나?"라고 생각해 다시 저장했다. 같은 데이터가 두 번 쓰였고, 결제 주소까지 두 번 변경돼 뒷배송 처리에 며칠이 걸렸다.원인은 — 쓰기 요청이 마스터 DB에 갔고, 읽기 요청이 읽기 복제본(비동기 복제)에 갔다. 복제 지연으로 복제본엔 아직 새 데이터가 안 반영됐기 때문이다. 시스템은 "저장됐다"고 했지만, 사용자가 보는 화면은 그게 아니었다.이 사태를 "강한 일관성 vs 최종 일관성"이라는 이분법으로 설명하면 핵심이 빠진다. 강도의 스펙트럼이 있고, 그 사이에 여러 모델이 있다. 이 글은 그 스..
-
Software Architecture/Distributed SystemsDistributed Systems - 02. CAP PACELC
일관성 모델 — 강과 최종 그 사이의 스펙트럼2018년 한 SaaS 회사에서 사용자가 프로필을 수정한 직후 "저장됐다"는 메시지를 받고, 새로고침하니 예전 프로필이 떴다. 사용자는 "저장이 안 됐나?"라고 생각하고 다시 저장했다. 같은 데이터가 두 번 쓰였다. 결제 주소까지 두 번 변경돼, 뒷배송 처리에 며칠이 걸렸다. 원인은 — 쓰기 요청이 마스터 DB에 갔고, 읽기 요청이 읽기 복제본(비동기 복제)에 갔는데, 복제 지연으로 복제본엔 아직 새 데이터가 안 반영됐기 때문이었다. 이런 현상을 "강한 일관성 vs 최종 일관성"이라는 이분법으로 설명하면 핵심이 빠진다. 강도의 스펙트럼이 있고, 그 사이에 여러 모델이 있다. 이 글은 그 스펙트럼을 정리한다.비유로 감 잡기 — 뉴스 전파의 여러 형태어떤 사건이 ..
-
Software Architecture/Distributed SystemsDistributed Systems - 01. 분산의 8가지 오해
분산의 8가지 오해 — 로컬 호출과 원격 호출은 같지 않다2017년 한 팀이 주문 서비스를 마이크로서비스로 쪼갰다. 모놀리스 시절 한 메서드 안에 있던 inventory.reserve(order)와 payment.charge(order)가 HTTP 호출로 바뀌었다. 코드는 똑같아 보였다 — 메서드 호출을 클라이언트 호출로 바꿨을 뿐. 3주 뒤 프로덕션에서 장애가 터졌다. 결제 서비스가 30초간 응답하지 않았고, 주문 서비스의 스레드 풀이 고갈됐다. 모놀리스 시절엔 결제가 느려지면 사용자가 잠깐 기다리는 걸로 끝났다. 마이크로서비스에선 회사 전체가 30분간 주문을 못 받았다. 로컬 호출을 원격 호출로 치환하는 게 얼마나 다른 결과를 낳는지, 그 팀은 비용으로 배웠다.이 글이 다루는 질문: 로컬 호출과 원격..