Single State 모델 아키텍처

Source: Dev.to

문제 설명

현대 시스템 아키텍처는 종종 단순함과 일관성을 희생하면서 규모와 유연성을 우선시합니다. 마이크로서비스, 이벤트‑드리븐 패턴, 복잡한 클라우드 도구를 도입하려는 급박함 속에서 많은 시스템이 서비스 전반에 걸쳐 파편화된 상태를 갖게 됩니다. 각 서비스가 자체 데이터베이스나 캐시를 보유하게 되면서 동일한 정보에 대한 여러 진실의 출처가 생깁니다.

이러한 파편화는 일관성 문제를 초래합니다. 예를 들어, 사용자 인터페이스는 하나의 값을 보여주지만 백엔드 서비스나 로그는 다른 값을 보여줄 수 있습니다. 이는 시스템의 서로 다른 부분이 동기화되지 않았기 때문입니다. 이런 차이는 단일 컴포넌트가 “전체 상황”을 알지 못하기 때문에 문제 해결이 퍼즐 맞추기와 같이 느껴지게 합니다.

게다가 과도한 추상화와 과대광고에 기반한 설계는 상황을 더욱 악화시킬 수 있습니다. 미들웨어 층, 수많은 API, 과도하게 설계된 프레임워크는 최종 사용자에게 명확한 이점 없이 복잡성만을 추가합니다. 팀은 최신 모범 사례라는 명목으로 “무상태” 토큰 기반 인증이나 과도하게 비동기적인 통신을 도입하지만, 결국 누가 데이터를 실제로 보유하고 있는지, 시스템의 어느 부분이 권위 있는지를 알지 못하게 됩니다.

결과: 기술적으로는 정교하지만 이해하기 어렵고 동작이 예측 불가능한 시스템.

요컨대, 많은 현대 아키텍처가 명확성 및 상태에 대한 단일 책임점을 놓치고 있습니다. 상태를 관리하는 통합된 접근 방식이 없으면 시스템은 유지보수가 어려워지고, 사용자는 혼란스럽거나 일관성 없는 경험을 하게 됩니다. 따라서 단순성, 예측 가능성, 그리고 핵심 상태 데이터에 대한 단일 진실의 원천을 중심에 두는 아키텍처가 필요합니다.

단일 상태 모델 정의

Single State Model은 전체 시스템에 걸쳐 각 사용자 세션에 대해 하나의 권위 있는 상태를 설정하는 아키텍처 접근 방식입니다.

이 모델에서는 사용자의 현재 세션 및 컨텍스트를 나타내는 모든 데이터를 한 곳(단일 상태 저장소)에 유지하며, 각 서비스에서 복제하거나 파생하지 않습니다. 모든 애플리케이션과 컴포넌트는 세션‑특정 정보를 위해 동일한 진실의 원천을 사용합니다.

핵심 포인트

• 세션 상태에 대한 단일 진실의 원천은 원래 여러 서비스에 흩어져 있던 데이터를 하나로 통합합니다.
• 각 마이크로서비스나 프론트엔드가 자체적인 사용자 컨텍스트 복사본을 유지(동기화되지 않은 상황을 초래)하는 대신, 모델은 하나의 중앙 세션 상태가 최종 진실이라고 주장합니다.
• 모든 다른 계층(캐시, UI 표시, 로그)은 그 하나의 상태를 반영하는 역할만 합니다.
• 사용자 세션당 하나의 정규화된 상태 객체를 두어, 사용자가 애플리케이션의 어느 부분과 상호작용하든 일관되고 최신의 사용자 데이터 뷰를 보장합니다.

설계 원칙 및 비목표

설계 원칙

• 단일 진실의 원천: 세션‑특정 데이터는 모두 한 곳(중앙 세션 저장소)에 저장·업데이트되어 충돌하는 버전을 없앱니다.
• 상태 통합: 분산된 상태를 하나의 논리 모델로 통합합니다. 사용자 ID, 선호도, 역할 및 기타 컨텍스트가 하나의 상태 공간을 공유합니다.
• 복잡성보다 단순성: 설계는 교묘한 추상화보다 직관적이고 예측 가능한 동작을 우선합니다.
• 강한 일관성: 세션 상태 변경은 시스템 모든 부분에 즉시 반영됩니다. 모델은 최종 일관성보다 동기식·원자적 업데이트를 선호합니다.
• 투명성: 엔지니어와 운영자는 하나의 세션 레코드만 보면 사용자의 현재 상태를 파악할 수 있습니다.

비목표

• 무제한 수평 확장: 모델은 의도적으로 세션 정보를 중앙 집중화하므로, 임의의 규모 확장을 위한 완전한 상태 파티셔닝 설계를 추구하지 않습니다.
• 다중 언어·서비스별 데이터 모델: 각 서비스가 자체적인 사용자 상태 뷰를 갖는 것을 허용하지 않으며, 대신 세션 데이터 모델을 표준화합니다.
• 과대광고를 위한 최신 기술: 블록체인이나 이색적인 합의 알고리즘 같은 기술은 피합니다; 목표는 예측 가능성이지 트렌드 추종이 아닙니다.
• 기록용 데이터베이스 대체: 단일 세션 상태는 전체 기록을 위한 장기 저장소가 아닙니다(예: 주문 이력). 이는 활성 세션 상태—사용자 상호작용 중에 필요하고 일시적이며 변경 가능한 데이터를 의미합니다.

최소 논리 아키텍처

핵심 구성 요소

• Identity Provider (IdP): 인증 서비스(예: SSO)로, 자격 증명을 검증하고 ID 토큰을 발급합니다. 게이트웨이와는 달리 세션 상태를 다루지 않습니다.
• Gateway: 사용자 ID를 검증하고 저장소에서 세션 상태를 읽고/쓰기 하는 통합 진입점입니다. 트래픽 관리와 세션 중개 역할을 동시에 수행합니다.
• Session Store: 모델의 핵심—각 사용자의 세션 상태를 단일 구조화된 객체로 보관하는 중앙 저장소(예: Redis, SQL).
• Applications (Services): 비즈니스 로직을 담당하는 백엔드 서비스. 사용자 세션에 대해 무상태이며, 컨텍스트는 게이트웨이를 통해 공급받습니다.
• Client: 최종 사용자의 인터페이스(브라우저/앱). 최소한의 상태(보통 토큰 하나)만 보유합니다.

구성 요소 아키텍처 다이어그램

flowchart LR
    subgraph Client_Side [Client Side]
        user[User
(Browser/App)]
    end
    subgraph Server_Side [Server Side]
        gateway[Gateway]
        idp[Identity
Provider]
        session[Session
Store]
        subgraph Apps [Applications]
            app1[Application 1]
            app2[Application 2]
        end
    end

    user -- Login / Requests --> gateway
    gateway -- Verify Identity --> idp
    idp -- User Identity --> gateway
    gateway -- Read/Write Session --> session
    gateway -- Forward request --> app1
    gateway -- Forward request --> app2
    app1 -- (If needed) Read/Update --> session
    app2 -- (If needed) Read/Update --> session

세션 수명 주기 예시

수명 주기 시퀀스 다이어그램

sequenceDiagram
    participant User
    participant IdP as Identity Provider
    participant Gateway
    participant Session as Session Store
    participant AppA as Application A
    participant AppB as Application B

    User ->> IdP: Submit login credentials
    IdP -->> User: Return authentication token (if valid)
    User ->> Gateway: Open App A (with token)
    Gateway ->> IdP: Validate token/identity
    IdP -->> Gateway: Identity confirmed
    Gateway ->> Session: Create new session for user (store state)
    Session -->> Gateway: Session created (ID and data)
    Gateway ->> AppA: Forward request with user context
    AppA ->> Session: Update session data (e.g., user updates profile)
    Session -->> AppA: Confirm update
    AppA -->> Gateway: Send response for App A request
    Gateway -->> User: Response from App A (reflecting updated state)

    %% User accesses another application in the same session
    User ->> Gateway: Open App B (with token or session ID)
    Gateway ->> Session: Fetch current session state
    Session -->> Gateway: Return session data (including latest updates)
    Gateway ->> AppB: Forward request with user context
    AppB -->> Gateway: Send response for App B request
    Gateway -->> User: Response from App B (consistent with updated state)