N° 01 — 목록
'Software Architecture' (50)
-
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에 구현된 이후로, 데이터 처리 시스템의 자연스러운 형태가 됐다.이 글이 다루는 질문..
-
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)과 미묘하게 다르다 — 분해보다 '독립성'과 '비용'을 더 직시한다. 이 글이 다루는 질문: 마이크로서비스를 정의하는 것은 '작음'인가, '독립성'인가. 답부터 말하면 — '작음'은 부수물이고..