Dev.Chan64's Blog

홈으로 가기
Open Slide

메시지 기반 아키텍처와 운영 중심 설계

1. 문제 상황과 선택의 갈림길

End-to-End 기반의 서비스 구조에서는 장치, 앱, 인증 시스템, 데이터 플랫폼 등이 유기적으로 연결되어야 합니다.
그러나 연결성이 높아질수록 장애 복원력과 유지보수성은 저하되며, 기능 변경에 대한 민감도는 급격히 증가합니다.

초기 시스템은 REST 기반의 API 호출 방식으로 구성되어 있었으나, 다음과 같은 문제가 지속적으로 발생하였습니다:

이러한 구조적 한계를 극복하기 위해, 기존 구조를 유지보수하기보다는 메시지 중심의 비동기 아키텍처로 전환하는 것이 장기적으로 더 적합하다고 판단하였습니다.

2. 메시지 기반 설계 선택의 배경

메시지 기반 구조는 각 서비스가 직접 호출되는 것이 아니라, 메시지를 통해 간접적으로 연결되고 독립적으로 동작하는 구조를 의미합니다.

본 구조를 선택한 이유는 다음과 같습니다:

특히 메시지 중심 구조는 APM, Grafana 등의 시각화 도구와 통합이 쉬워, 실시간 모니터링과 문제 대응 속도 개선에 큰 도움이 되었습니다.

3. 설계 전략과 팀 내 수용 과정

이 설계는 개인적인 운영 경험과 과거의 기술적 배경을 기반으로 도출되었습니다.
특히 로봇 운영체제(ROS: Robot Operating System) 환경에서 메시지 기반 아키텍처에 익숙했던 경험이 큰 도움이 되었습니다.
ROS는 기본적으로 Publisher-Subscriber 방식의 메시지 통신 구조를 중심으로 구성되며, 이는 다양한 구성 요소 간의 분산된 상호작용과 복원력을 강조하는 구조적 특성을 갖고 있습니다.

이러한 기술적 기반은 단순한 구현 경험을 넘어, 실제 필드에서 운영과 개발을 동시에 고려한 DevOps적 시각을 형성하는 데 중요한 자양분이 되었습니다.
본 프로젝트에서도 이러한 사고를 바탕으로 설계 초기부터 운영 가능성과 문제 대응 효율성을 핵심 지표로 설정하였습니다.

처음부터 조직 내에서 즉각적인 공감을 얻기는 어려웠습니다.
특히 메시지 기반 구조가 익숙하지 않은 개발자나 운영자는 이를 구조적으로 받아들이기 어려워하거나, 기존 REST 기반 아키텍처에 비해 복잡하다고 느낄 수 있었습니다.

이에 따라 설계의 핵심 이점을 다음과 같은 실질적인 운영 시나리오에 근거하여 설명하였습니다:

이러한 이점을 바탕으로 기존 REST 중심 구조와 비교한 구체적 사례를 제시하고, 메시지 기반 아키텍처의 실효성과 장점을 반복적으로 설명하며 팀 내 공감대를 형성해 나갔습니다.

본 설계는 단순한 메시지 전달 경로의 정리를 넘어,
운영 관점에서의 복원력 확보, 설계 관점에서의 유연한 확장성,
그리고 비즈니스 흐름 중심의 구조화를 통합적으로 구현하고자 한 시도였습니다.

4. 네임스페이스 기반 계층 구조와 설계 철학

본 구조에는 data_service에 해당하는 영역이 정의되지 않았습니다.
이는 당시 해당 계층의 역할과 책임이 명확하지 않았기 때문에, 설계 상 의도적으로 비워두고 추후 data_platform으로의 통합 가능성을 고려한 전략적 선택이었습니다.

이러한 네임스페이스 기반 분리는 단순한 디렉토리 구분을 넘어서, 기능을 태깅하거나 그룹화하는 방식으로도 활용될 수 있습니다.
기능 계층 구조를 추적하고 시스템의 흐름을 명확히 이해하는 데에 실질적인 도움이 되었습니다.
그러나 이 구조 자체보다 더 중요한 것은, 이 네임스페이스가 팀 내 공통 언어로 작동할 수 있도록 정의되고 합의되었는가 입니다.
언어적 정렬의 일관성과 명확한 의미 부여는, 시스템 구성 요소 간의 관계를 직관적으로 해석하게 됩니다.
개발자와 운영자 간 커뮤니케이션의 효율성을 실질적으로 높이는 핵심 요소입니다.

5. 아키텍처 도식

아래 도식은 전체 시스템의 계층 구성과 메시지 흐름을 시각적으로 표현한 것입니다.
사용자 요청 및 외부 이벤트가 어떻게 유입되고 처리되는지를 구조적 관점에서 설명합니다.

graph TB
    %% --- 상위 서비스 구조 ---
    subgraph SRV [Service]
        DEV[Device]
        DEV1[Device] --> AGENT[Agent]
        APP[App] --> ALB 
    end    
    
    subgraph 3RD [External Service]
        3RD_DEV[Ext. Device] --> 3RD_CLOUD[Ext. Cloud] --> BRIDGE[C2C Bridge]
    end

    %% --- 메인 서비스 플랫폼 ---
    subgraph SP [Service Platform]
        AUTH[Auth] --> API[API Gateway]
        X509[X.509] --> MSG[Message Broker]
        BRIDGE --> MSG
        API --> MSG
        MSG --> RULE[Rule Engine] --> DT[Device Tween] --> MSG

        subgraph OC [Container]
            MSA[Worker A]
            MSA1[Worker B]
            MSA2[Worker C]
        end

        API --> MSA
        RULE --> MSA1
        RULE --> MSA2 --> MSG
    end

    %% --- 데이터 플랫폼 ---
    subgraph DP [Data Platform]
        DATA_API[Data API] --> MODEL[Data Model]
        DATA_BRIDGE[Data Bridge] --> MODEL
        ETL[ETL Service] --> MODEL
        MODEL --> DATA[Storage]
    end

    %% --- Cross-domain 연결 ---
    MSA --> DATA_API
    API --> DATA_API
    RULE --> DATA_BRIDGE
    DATA_BRIDGE --> ETL
    DEV[Device] --> X509
    AGENT --> X509
    ALB --> AUTH

6. 설계 주요 구성 요소

참고: 초기에는 Kafka의 도입을 고려하였으나, 인프라 관리 효율성과 인력 비용을 고려하여 AWS Kinesis 기반의 관리형 서비스를 선택하였습니다.

메시지 처리 흐름

도메인 기반 계층 분리

데이터 흐름과 후처리 구조

7. 운영 성과와 효과

이러한 전략은 실제 운영 환경에서 높은 안정성과 유연성을 제공하였으며, 장애 상황에서도 빠르게 문제를 진단하고 서비스 확산을 방지할 수 있는 기반이 되었습니다.

8. 설계 인사이트와 철학

9. 핵심 메시지

“좋은 메시지 설계는 결국 좋은 운영 설계입니다.”

“시스템은 연결로 복잡해지고, 메시지로 단순해집니다.”

홈으로 가기
태그: 프로젝트 DevOps 플랫폼화