N° 01 — 목록
'software-architecture' (49)
-
Software Architecture/Architectural StylesArchitectural Styles - 09. 이벤트 소싱
이벤트 소싱 — 상태를 이벤트의 누적으로 저장하기은행 통장을 펼쳐보자. 잔액은 단 하나의 숫자로 표시되지만, 그 숫자가 어떻게 됐는지를 보여주는 건 '거래 내역'이다. 7월 1일 입금 100만 원, 7월 5일 출금 30만 원, 7월 10일 입금 50만 원. 이 내역들을 순서대로 적용하면 잔액 120만 원이 나온다. 잔액은 '계산된 결과'고, 거래 내역이 '진짜 데이터'다. 은행이 잔액만 저장하고 내역을 버리면, "왜 120만 원이지?"라는 질문에 답할 수 없다. 이벤트 소싱(event sourcing)은 이 은행 통장 모델을 소프트웨어에 적용한 것이다 — 현재 상태를 덮어쓰지 않고, 상태 변경을 이벤트로 append-only 저장한다. 현재 상태는 이벤트를 재생해 계산한다.이 글이 다루는 질문: 상태를 ..
-
Software Architecture/Architectural StylesArchitectural Styles - 08. CQRS
CQRS — 명령과 질의를 가르는 선택한 전자상거래 시스템의 접근 패턴을 보자. 주문 생성(쓰기)은 하루 10만 건, 주문 조회(읽기)는 하루 1억 건이다. 1000 대 1의 비율이다. 그런데도 같은 Order 모델, 같은 OrderRepository, 같은 DB를 쓴다. 읽기 최적화(인덱스, 캐싱, 복제본)를 하려 해도 쓰기 모델에 영향을 줘서 함부로 못 건드린다. 쓰기 트랜잭션의 무결성을 지키려면 읽기 성능을 희생해야 하고, 읽기 성능을 올리려면 쓰기 무결성이 흔들린다. 이 교착에서 빠져나오는 한 방법이 CQRS(Command Query Responsibility Segregation)다. 명령(쓰기)과 질의(읽기)를 아예 다른 모델로 가르는 것.이 글이 다루는 질문: 같은 모델로 읽고 쓰는 게 항상..
-
Software Architecture/Architectural StylesArchitectural Styles - 07. 이벤트 기반 아키텍처
이벤트 기반 아키텍처 — 비동기가 만드는 새로운 일관성결제 서비스가 3초 걸린다고 하자. 모놀리스에서 동기 호출로 묶여 있으면, 주문은 결제가 끝날 때까지 3초 대기한다. 요청이 몰리면 스레드 풀이 고갈되고 전체 장애로 번진다. 이 장면을 이벤트 기반으로 바꾸면 — 주문은 접수만 하고 'OrderPlaced' 이벤트를 발행한다. 결제 서비스는 그 이벤트를 받아 자기 속도로 처리한다. 주문은 결제가 3초 걸리든 30초 걸리든 영향받지 않는다. 이게 이벤트 기반 아키텍처(event-driven architecture)의 약속이다.이 글이 다루는 질문: 비동기 이벤트가 푸는 문제는 무엇이고, 그 대가로 요구하는 것은 무엇인가. 푸는 문제는 '결합과 장애 전파'고, 대가는 '강한 일관성과 디버깅 단순함'이다.비..
-
Software Architecture/Architectural StylesArchitectural Styles - 06. 마이크로서비스의 함정
마이크로서비스의 함정 — 쪼갰지만 묶여 있는 구조2017년, 한 대형 이커머스 회사가 2년에 걸쳐 모놀리스를 40개의 마이크로서비스로 쪼갰다. 발표 자료엔 멋진 서비스 맵이 그려졌다. 그런데 1년 뒤, 그 팀은 한 가지 이상한 현상을 보고했다 — 한 서비스를 배포하면 자주 다른 서비스가 깨졌다. 서비스가 '독립적'이지 않았다. 조사해보니 서비스 30개가 동기 HTTP 호출 체인으로 엮여 있었고, 한 서비스의 응답 스키마를 바꾸면 호출하는 서비스들이 연쇄적으로 깨졌다. 외견상 40개 서비스, 실제로는 30개가 결합된 하나의 시스템 — 분산 모놀리스(distributed monolith)였다.이 글이 다루는 질문: 마이크로서비스로 '분해'했는데 왜 '결합'이 남을까. 그리고 그 결합을 어떻게 풀거나 피할 수..
-
Software Architecture/Architectural StylesArchitectural Styles - 05. 마이크로서비스
마이크로서비스 — 분해와 독립성의 약속2014년 3월, James Lewis와 Martin Fowler는 martinfowler.com에 "Microservices"라는 글을 올렸다. 당시 이미 여러 기업(Netflix, Amazon)이 이런 식의 아키텍처로 시스템을 운영하고 있었지만, '마이크로서비스'라는 이름과 특성을 처음 정리한 것은 이 글이었다. 그 후 10년 동안 마이크로서비스는 업계를 휩쓸었다 — 그리고 많은 곳에서 실패했다. Sam Newman이 2판(2021)에서 가장 강조하는 메시지는 1판(2015)과 미묘하게 다르다 — 분해보다 '독립성'과 '비용'을 더 직시한다. 이 글이 다루는 질문: 마이크로서비스를 정의하는 것은 '작음'인가, '독립성'인가. 답부터 말하면 — '작음'은 부수물이고..
-
Software Architecture/Architectural StylesArchitectural Styles - 04. 클린 아키텍처
클린 아키텍처 — 의존성 규칙을 동심원으로 그리기2012년, Robert C. Martin은 자신의 블로그에 'Clean Architecture'라는 글을 올렸다. 거기 그린 그림은 동심원이었다 — 가운데 Entities, 그 바깥으로 Use Cases, Interface Adapters, Frameworks & Drivers가 겹겹이 둘러싼 모양. 이 그림은 5년 뒤 같은 이름의 책(, 2017)이 되고, 동시대에 Jeffrey Palermo가 제안한 'Onion Architecture'(2008)와 거의 같은 구조로 통합됐다. 동심원 그림은 인터넷에 널리 퍼졌지만, 정작 핵심은 그림이 아니다. 동심원은 발상을 시각화한 부수물이고, 본질은 '의존성 규칙(dependency rule)'이라는 한 문장에 ..