N° 01 — 목록
'Software Architecture' (49)
-
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분간 주문을 못 받았다. 로컬 호출을 원격 호출로 치환하는 게 얼마나 다른 결과를 낳는지, 그 팀은 비용으로 배웠다.이 글이 다루는 질문: 로컬 호출과 원격..
-
Software Architecture/Architectural StylesArchitectural Styles - 12. 아키텍처 스타일 비교
아키텍처 스타일 비교 — 같은 요구, 다른 정답한 스타트업이 주문 시스템을 설계한다고 하자. 요구사항은 명확하다 — 하루 10만 건 주문, 결제 연동, 재고 관리, 향후 확장 가능성. 이 요구사항을 놓고 열두 가지 스타일 중 어느 것을 고를까. 정답은 "그때그때 다르다"가 아니라 "주어진 품질 속성 우선순위에 따라 다르다"다. 같은 기능(주문 처리)이라도, 어느 품질 속성(확장성·단순성·독립 배포·강한 일관성)이 결정적인가에 따라 정답이 갈린다. 이 글은 지금까지 다룴 열한 가지 스타일을 같은 잣대로 비교하고, 선택의 기준을 정리한다.비유로 감 잡기 — 집의 골조 선택같은 "3가족이 사는 집"을 짓는다고 하자. 세 가지 옵션이 있다고 가정한다.단독주택 한 채 — 모두가 한 지붕 아래 산다. 공간 효율 좋..
-
Software Architecture/Architectural StylesArchitectural Styles - 11. 마이크로커널과 서버리스
마이크로커널과 서버리스 — 코어를 최소화하는 두 형태Eclipse IDE를 켜보자. 핵심은 작다 — 플랫폼 런타임, 번들 시스템, 워크벤치. 그 위에 수백 개의 플러그인이 얹혀 있다. JDT(Java 개발 도구), CDT(C/C++), PyDev(Python), Git 통합, 디버거, 마켓플레이스에서 다운받는 수천 개의 확장. 핵심 코어는 플러그인이 뭘 하는지 모른다 — 그저 정해진 확장점(extension point)으로 플러그인이 참여할 뿐이다. 이 구조의 이름이 마이크로커널(microkernel)이다. 반대 극단에 AWS Lambda 같은 서버리스(serverless) FaaS가 있다 — 함수 하나가 코어 없이 그 자체로 실행 단위. 두 스타일은 다른 것 같지만, "코어를 최소화하고 확장에 집중한다..
-
Software Architecture/Architectural StylesArchitectural Styles - 10. 파이프라인
파이프라인 아키텍처 — 단계별로 흐르는 구조터미널에서 한 번쯤 이런 명령을 쳐봤을 것이다.cat access.log | grep "404" | awk '{print $1}' | sort | uniq -c | sort -rn | head -20이 한 줄은 다섯 개의 프로그램(cat, grep, awk, sort, uniq)이 '파이프'(|)로 연결돼, 앞의 출력이 뒤의 입력으로 흘러간다. 각 프로그램은 자기 일만 하고, 다른 단계가 뭘 하는지 모른다. 이 간결한 구조가 파이프라인(pipeline) 또는 파이프-필터(pipe-filter) 아키텍처 스타일이다. Doug McIlroy가 1964년에 제안하고 1973년 Unix에 구현된 이후로, 데이터 처리 시스템의 자연스러운 형태가 됐다.이 글이 다루는 질문..