N° 01 — 목록
'Software Architecture/Architectural Styles' (12)
-
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)'이라는 한 문장에 ..
-
Software Architecture/Architectural StylesArchitectural Styles - 03. 헥사고날 아키텍처
헥사고날 아키텍처 — 도메인을 프레임워크로부터 격리하기2005년, Alistair Cockburn은 자신의 웹사이트에 "Ports and Adapters"라는 패턴을 올렸다. 그가 풀고자 했던 문제는 단순했다 — "같은 비즈니스 로직이 GUI, CLI, 테스트, 다른 애플리케이션에서 다시 작성되는 일"을 피하는 것. 그가 그린 그림은 도메인을 중심에 두고 여섯 개의 변이 둘러싼 육각형이었다. 이름은 헥사고날(hexagonal)이 됐고, 그 육각형의 변이 '포트(port)'가 됐다. 20년이 지난 지금, 이 패턴은 DDD 진영에서 가장 널리 쓰이는 구조적 패턴이 됐다. 그런데 이름은 자주 쓰이면서 본질은 자주 오해받는다. 헥사고날의 핵심은 '육각형 모양'이 아니라 '의존성 방향'이다.비유로 감 잡기 — 가..
-
Software Architecture/Architectural StylesArchitectural Styles - 02. 계층형 아키텍처
계층형 아키텍처 — 가장 흔한 구조가 품은 함정Spring Boot 프로젝트를 하나 열어보자. controller, service, repository 패키지가 보인다. 어쩌면 자바 웹 애플리케이션의 90%가 이 구조로 돼 있다. 이름은 계층형 아키텍처(layered architecture). 너무 흔해서 '스타일'로 의식하지 못할 정도다. 하지만 이 흔함이 숨기는 함정이 있다 — 계층을 나눴다고 해서 결합이 낮아지는 건 아니다. 계층 사이의 규칙이 결합을 낮춘다.비유로 감 잡기 — 식당의 층별 배치3층짜리 식당을 상상하자. 1층은 홀(손님 응대, 메뉴 설명). 2층은 주방(요리). 3층은 창고(재료 보관). 손님이 1층에서 주문하면 주문서가 2층으로 올라가고, 2층 주방이 3층 창고에서 재료를 꺼내 요..
-
Software Architecture/Architectural StylesArchitectural Styles - 01. 모놀리스
모놀리스가 다시 출발점이 된 이유2015년 무렵 한 스타트업이 하루 처리 건수 10만을 넘기며 모놀리스를 마이크로서비스로 쪼갰다. "모놀리스는 스케일이 안 된다"는 조언을 따른 선택이었다. 6개월 뒤 그 팀이 직면한 것은 트래픽 처리의 성공이 아니라 배포 파이프라인 8배, 분산 트랜잭션 버그, 그리고 "어느 서비스에서 로그가 끊겼는지"를 찾느라 보내는 새벽이었다. 모놀리스 시절 한 번에 끝나던 배포가 여덟 개 서비스의 버전 정합성을 맞추는 일로 바뀌었다. 그들이 진짜 필요했던 건 "모놀리스를 버리는 것"이 아니라 "모놀리스 안의 모듈 경계를 명확히 하는 것"이었다.흥미로운 건 마이크로서비스를 대중화한 책 의 저자 Sam Newman이 2판(2021)에서 오히려 "모놀리스 먼저(monolith first)..