아키텍처의 퀀텀

퀀텀이란 무엇인가?

퀀텀은 라틴어 ‘quantus’에서 유래했으며, ‘얼마나 많은’, ‘양의’를 의미합니다. 이외에도 사전 상에서 다음과 같은 의미를 찾을 수 있습니다.

• (물리학) 양자: 더 이상 나눌 수 없는 에너지나 물질의 최소 단위.
• (일반적으로) 최소량, 일정량.
• 갑작스럽고 중요한 도약을 의미할 때도 사용

아키텍처에서의 퀀텀

아키텍처에서는 사전적 의미의 최소량의 의미를 가지고 쓰이게 됩니다. 일반적으로 한번에 배포될 수 있는 단위를 퀀텀이라고 부르게 됩니다.

최근 마이크로서비스 아키텍처 트렌드와 시스템의 복잡성 증가로 인해 퀀텀 개념은 더욱 중요해졌습니다. 빠른 비즈니스 요구사항 변화에 유연하게 대처하기 위해 각 서비스를 독립적인 퀀텀으로 설계하고 배포하는 것이 필수가 되었습니다.

예를 들어, 대규모의 복잡한 시스템을 하나의 거대한 단위로 관리한다면 변경 및 배포가 매우 느려지고 위험해집니다. 하지만 시스템을 여러 개의 작은 퀀텀으로 나누어 관리하면, 각 퀀텀은 독립적으로 개발, 테스트, 배포될 수 있어 전체 시스템의 민첩성과 안정성을 높일 수 있습니다.

퀀텀은 복잡한 시스템을 이해하고 관리하기 위한 논리적인 분할 단위이자, 효율적인 개발 및 운영을 가능하게 하는 핵심 개념입니다. 아키텍처를 설계할 때 “어떤 단위를 묶어서 함께 배포할 것인가?“와 “각 단위는 어떤 책임과 범위를 가질 것인가?“에 대한 고민이 바로 퀀텀을 정의하는 과정입니다.

실제 예시로 이해하기

채팅 서버

채팅 서버를 구성한다고 가정해보겠습니다. 단일 서버로만 올릴 건 아니니까, 당연히 여러 서버 인스턴스가 올라가게 될 겁니다. 여러 서버 인스턴스가 올라가게 되면 메시지를 중계해줄 메시지큐나 브로커가 필요합니다. 세션 관리를 위한 분산 캐시와 사용자 관리를 위한 데이터베이스나 채팅 기록을 위한 데이터베이스도 필요할 겁니다.

채팅 서버 하나를 올리기 위해 다음 인프라가 추가로 필요합니다:

• Message Queue or Message Broker: NATS, Kafka, Pulsar 등
• Distributed Cache: Redis cluster, Valkey cluster, MongoDB, Memcached 등
• OLTP Database: Postgres, MySQL, MSSQL 등
• OLAP Database: MongoDB, Cassandra, Clickhouse 등

최적의 조합으로 채팅 서버를 구성하면:

• Go로 된 채팅 서버
• 레디스 노드
• 포스트그레
• 클릭하우스

이렇게 4개 구성요소가 채팅 서버 퀀텀을 구성합니다.

온라인 쇼핑몰

온라인 쇼핑몰에서는 다음과 같이 퀀텀을 정의해 볼 수 있습니다.

• 주문 처리 퀀텀: 주문 접수 서비스, 결제 처리 서비스, 재고 관리 서비스, 배송 정보 생성 서비스 등을 묶어 하나의 퀀텀으로 볼 수 있습니다. 이 퀀텀은 고객이 상품을 주문하고 최종적으로 배송이 시작되기까지의 핵심 비즈니스 로직을 담당하며, 각 서비스는 독립적으로 배포될 수 있지만 주문이라는 도메인 책임을 공유합니다.

• 상품 정보 퀀텀: 상품 정보 조회 서비스, 상품 리뷰 서비스, 상품 추천 서비스 등을 묶어 또 다른 퀀텀으로 볼 수 있습니다. 이 퀀텀은 고객에게 상품 정보를 제공하고 상호작용을 유도하는 역할을 하며, 주문 처리 퀀텀과는 독립적으로 변경 및 배포가 가능합니다.

게임 서비스

게임 서비스의 경우에도 다양한 퀀텀으로 분리하여 설계할 수 있습니다.

• 매치메이킹 퀀텀: 사용자 매칭 서비스, 게임 세션 생성 서비스, 게임 시작 알림 서비스 등을 포함할 수 있습니다. 이 퀀텀은 플레이어들이 함께 게임을 할 수 있도록 연결하는 역할을 담당하며, 빠른 반응성과 확장성이 요구될 수 있습니다.

• 인벤토리 퀀텀: 사용자 아이템 관리 서비스, 아이템 구매/판매 서비스, 아이템 조합 서비스 등을 포함하는 퀀텀입니다. 플레이어의 자산과 관련된 민감한 정보를 다루므로 높은 일관성과 보안이 중요하며, 다른 퀀텀과 분리하여 관리함으로써 독립적인 보안 강화 및 데이터 일관성 유지가 가능합니다.

이처럼 퀀텀은 시스템의 특정 비즈니스 기능이나 도메인 책임을 중심으로 정의될 수 있으며, 이는 아키텍처를 더 작고 관리 가능한 단위로 분할하여 개발, 배포, 운영의 효율성을 높이는 데 기여합니다.

퀀텀의 책임과 범위

퀀텀의 범위는 도메인이나 생산되는 데이터의 책임 범위와 유사합니다. 앞에서 살펴본 채팅 서비스 예시를 통해 각 구성 요소의 역할과 책임 범위를 살펴보겠습니다.

• 채팅 서버: 유저로부터 채팅을 받고 필요한 정책적 처리 및 전송 과정을 담당
• 레디스 노드: 각 유저 세션이나 chat room 등의 캐싱을 담당하고, 공통된 환경 변수, 정책에 필요한 데이터의 캐싱 등의 공유를 담당 (필요에 따라 Refresh Token같은 걸로 세션을 대체할 수도 있음)
• 포스트그레: 각 유저 데이터나 chat room 데이터 등의 레디스에서 쓰이는 데이터의 오리지널 데이터의 저장을 담당 (필요에 따라 유저 인증과 관련된 API Key나 Secret을 저장할 수도 있음)
• 클릭하우스: 역대 채팅 서버를 통해 공유된 메시지나 이벤트 등의 내용을 저장하고 제공하는 걸 담당

다른 곳에서 채팅 데이터를 가지고 검색을 만들거나, 관심사를 추출하는 등의 다양한 행위를 할 수 있지만, 데이터의 생산과 보존은 채팅 서비스 퀀텀에서 수행하는 것입니다.

적절한 퀀텀 크기 가이드라인

효과적인 퀀텀을 설계하기 위한 정량적 기준들:

• 팀 크기: 2-8명의 팀이 관리할 수 있는 범위 (2 pizza team 원칙)
• 배포 주기: 독립적으로 주 1-2회 이상 배포 가능한 단위
• 코드베이스 규모: 10만 라인 이하의 코드로 구성
• 데이터베이스 테이블: 10-15개 이하의 핵심 테이블
• API 엔드포인트: 20-30개 이하의 관련성 높은 API

퀀텀 분할 시 피해야 할 안티패턴

• 과도한 분할: 너무 작은 단위로 나누어 네트워크 오버헤드와 복잡성만 증가
• 순환 의존성: 퀀텀 간에 순환 참조가 발생하는 설계
• 공유 데이터베이스: 여러 퀀텀이 하나의 데이터베이스를 공유하는 구조
• 동기식 체인: 여러 퀀텀이 동기적으로 연결되어 장애 전파 위험이 높은 구조

퀀텀을 알아야 하는 이유

퀀텀 개념을 이해하는 것은 아키텍처를 설계하고 발전시키는 데 있어 여러 면에서 중요한 통찰을 제공합니다. 이는 단순히 용어를 아는 것을 넘어, 시스템의 독립성, 변경의 영향 범위, 그리고 장애 격리 능력 등을 판단하는 기준이 됩니다.

독립적 배포와 개발

시스템을 퀀텀 단위로 분할하면, 각 퀀텀은 독립적으로 개발, 테스트, 배포될 수 있습니다. 대규모 모놀리식 아키텍처에서는 작은 기능 변경에도 전체 시스템을 다시 빌드하고 배포해야 할 수 있어 시간 소모적이고 위험 부담이 큽니다.

하지만 퀀텀 단위로 분리된 아키텍처에서는 변경이 발생한 특정 퀀텀만 업데이트하면 되므로, 배포 속도를 높이고 롤백의 복잡성을 줄일 수 있습니다. 이는 팀의 생산성과 시스템의 민첩성을 향상시킵니다.

영향 범위 파악과 격리

시스템의 한 부분에서 발생한 변경이 다른 부분에 미치는 영향을 퀀텀 개념을 통해 명확하게 파악할 수 있습니다. 특정 퀀텀 내에서 변경이 발생했다면, 해당 변경이 다른 퀀텀에 미치는 직접적인 영향을 예측하고 관리하기 쉬워집니다.

모놀리식 시스템에서는 의존성이 복잡하게 얽혀 있어 작은 변경이 예상치 못한 큰 파급 효과를 가져오기 쉽습니다. 퀀텀은 이러한 의존성의 경계를 정의하고, 변경의 영향 범위를 국한시키는 데 도움을 줍니다.

퀀텀은 시스템의 각 부분을 논리적으로 격리하는 역할도 합니다. 외부 서비스와의 연동을 담당하는 퀀텀에서 외부 서비스의 장애가 발생하더라도, 이 장애가 다른 퀀텀으로 전파되지 않도록 격리할 수 있습니다. 이는 서킷 브레이커(Circuit Breaker)와 같은 디자인 패턴과 함께 활용될 때 시스템의 탄력성을 크게 향상시킵니다.

실전 적용 사례

채팅 서비스에 접근하기 위한 인증과 chatroom에 대한 관리를 멤버십 서비스가 담당한다고 가정해봅시다. 멤버십 서비스가 장애가 나거나, 내부 네트워크 문제로 인해 서로 다른 서비스 간의 통신이 단절되면, 채팅 서비스도 장애를 공유받게 됩니다. 이 경우엔 채팅 서비스에 대한 퀀텀에 멤버십 서비스가 포함되게 되겠죠.

하지만 채팅 서비스가 온전히 자신만의 퀀텀을 가지고, 멤버십에서 오히려 채팅 서비스에 유저 접근을 위한 토큰 발급을 요청하고, 해당 토큰을 유저에게 제공한 후 채팅 서비스에 접근하도록 한다면, 멤버십에 대한 장애가 발생해도 채팅 서비스 자체는 유저들이 원활히 이용할 수 있을 겁니다.

퀀텀 효과성 측정 방법

퀀텀이 제대로 설계되었는지 평가하는 지표들:

• 배포 빈도: 각 퀀텀의 독립적 배포 횟수
• 변경 실패율: 배포 후 롤백이 필요한 비율
• 복구 시간: 장애 발생 시 정상 상태로 복구하는 시간
• 개발 리드 타임: 기능 요구사항부터 프로덕션 배포까지의 시간
• 팀 자율성 지수: 다른 팀의 의존 없이 작업 가능한 비율

이처럼 퀀텀 개념을 통해 우리는 시스템을 더 작고 관리 가능한 단위로 분할하고, 각 단위의 책임과 의존성을 명확히 하며, 변경 및 장애에 대한 시스템의 탄력성을 높일 수 있습니다. 이는 현대의 복잡하고 빠르게 변화하는 소프트웨어 환경에서 안정적이고 확장 가능한 아키텍처를 구축하는 데 필수적인 요소입니다.

마지막으로

정말 별거 아닌 기초적인 용어이지만, 개념을 알고 모르고의 차이가 설계 레벨에서 의외로 큰 차이를 보인다는 걸 느끼고 있었습니다. 그러던 중 퀀텀이란 단어를 알게 되어 오랜만에 포스팅을 했는데, 처음 아키텍처링을 접하는 분들에게 도움이 되기를 바랍니다.