소프트웨어 아키텍처 101 - CHAPTER 18 최적의 아키텍처 스타일 선정

18.1 아키텍처 ‘유행’은 계속 변한다

• 과거를 돌아보다

새로운 아키텍처 설계는 과거 아키텍처 스타일에서 발견된 결함이 반영된 경우가 많습니다.

• 생태계의 변화

끊임없는 변화는 소프트웨어 개발 생태계의 바람직한 특성입니다.

• 새로운 기능

새로운 기능이 출현하면 아키텍처는 단순히 어떤 도구를 다른 도구로 대체하는 정도가 아닌 완전히 새로운 패러다임으로 전환될 수 있습니다.

• 가속

생태계는 끊임없이 변할 뿐만 아니라 그 변화의 속도도 계속 빨라지고 있습니다. 새로운 도구는 새로운 엔지니어링 프랙티스를 창출하고 이는 다시 새로운 설계와 기능으로 이어집니다.

• 도메인 변경

비즈니스가 계속 진화하고 타 회사와 합병되면서 개발자가 소프트웨어를 개발하는 도메인 역시 도통 가만히 있는 법이 없습니다.

• 기술 변화

기술이 진화할수록 조직은 그 변화의 흐름의 일부라도 (특히 그것이 분명하고 중요한 이익을 가져올 때) 따라잡으려고 합니다.

• 외부 팩터

소프트웨어 개발과 연관된 많은 주변 요인들이 조직의 변화를 가져오는 경우도 있습니다.

현재 유행하는 아키텍처 관점에서 조직이 어떤 위치에 있든 아키텍트는 업계 동향을 잘 파악해서 유행을 따르고 예외를 두어야 하는 경우를 현명하게 잘 결정해야 합니다.

18.2 결정 기준

• 도메인

아키텍트는 도메인에서 여러 가지 양상, 특히 어느 부분이 운영 아키텍처 특성에 영향을 미치는지 파악해야 합니다. 아키텍트가 꼭 해당 분야의 전문가일 필요는 없지만, 자신이 설계하는 도메인에서 중요한 파트에 대해서 최소한의 지식을 갖고 있어야 합니다.

• 구조에 영향을 미치는 아키텍처 특성

아키텍트는 도메인과 다른 외부 요소를 지원하는 데 필요한 아키텍처 특성을 정확하게 밝혀내야 합니다.

• 데이터 아키텍처

아키텍트와 DBA는 서로 머리를 맞대고 데이터베이스, 스키마 등 데이터에 관한 문제를 의논해야 합니다. 신규 시스템이 이전에 그리고(또는) 현재 사용 중인 데이터 아키텍처와 상호작용할 경우, 아키텍트는 반드시 데이터 설계가 아키텍처 설계에 미치는 영향도를 미리 파악해야 합니다.

• 조직 문제

갖가지 외부 팩터들도 설계에 영향을 줍니다.

• 프로세스, 팀, 운영 문제에 관한 지식

소프트웨어 개발 프로세스, 운영팀과의 소통(또는 그런 소통의 결핍), QA 프로세스 등 프로젝트와 관련된 다양한 팩터들도 아키텍처 설계에 영향을 끼칩니다.

• 도메인/아키텍처 동형성

아키텍처의 토폴로지와 잘 맞는 문제 영역이 있습니다. 예를 들어, 마이크로 커널 아키텍처 스타일은 아키텍처적으로 플러그인 형태의 커스터마이징이 가능하므로 맞춤성이 필요한 시스템과 완벽하게 잘 어울립니다.

반대로, 문제 영역과 아키텍처 스타일이 불협화음이 나는 경우도 있습니다. 예를 들어 규모가 큰 모놀리식 구조로는 확장성이 우수한 시스템을 설계하기가 어렵습니다.

• 모놀리스냐 분산이냐

아키텍트는 아키텍처 퀀텀 개념을 이용하여 단일 아키텍처 특성만으로도 설계에 부족함이 없는지, 아니면 시스템 파트별로 상이한 아키텍처 특성이 필요한지 판단해야 합니다. 전자의 경우 (다른 팩터들 때문에 결국 분산 아키텍처로 굳어질 수 있지만) 모놀리스가 적합하다는 뜻이고, 후자의 경우 분산 아키텍처가 정답에 가깝습니다.

• 데이터를 어디에 둘 것인가?

일반적으로 모놀리식 아키텍처는 하나 또는 소수의 관계형 데이터베이스를 전제로 하지만, 분산 아키텍처에서는 아키텍트가 어느 서비스가 어떤 데이터를 저장할 지 결정해야 합니다. 즉, 워크플로를 구축하기 전에 아키텍처의 데이터 흐름에 대해 충분히 숙고해야 합니다.

• 서비스 간 통신은 동기, 비동기 중 어떤 스타일로 할 것인가?

데이터를 어떻게 분할할지 정한 다음에는 서비스 간 통신 방식을 동기로 할지, 비동기로 할지 결정해야 합니다. 동기 통신은 대부분 더 간편하긴 하지만 확장성, 안정성, 그 밖의 다른 아키텍처 특성에 부정적인 영향을 미칠 수 있습니다. 비동기 통신은 성능, 확장성 측면에서 우월하나, 데이터 동기화, 데이락(deadlock, 교착상태), 경합 조건, 디버깅 등 골칫거리가 많습니다.

이키텍트는 가급적 설계, 구현, 디버깅 문제가 비교적 적은 동기 통신을 기본으로 하되, 필요한 경우에 비동기 통신을 함께 사용하는 것이 좋습니다.

18.3 모놀리스 사례 연구: 실리콘 샌드위치

우리는 실리콘 샌드위치 카타의 아키텍처 특성을 조사한 후 이 시스템은 단일 퀀텀으로 구현해도 충분하다고 결정했습니다.

우리는 실리콘 샌드위치를 도메인 분할된 컴포넌트와 기술 분할된 컴포넌트, 이렇게 두 가지 상이한 컴포넌트로 설계했습니다. 두 가지 설계를 비교해보면서 각각의 트레이드 오프를 살펴보겠습니다.

18.3.1 모듈러 모놀리스

모듈러 모놀리스는 단일 퀀텀으로 배포된 단일 데이터베이스 기반의 도메인 중심 시스템입니다.

앞서 아키텍트가 식별한 각 도메인이 이 그림에서 컴포넌트로 표시되어 있습니다. 시간과 리소스가 넉넉하다면 아키텍트는 도메인 컴포넌트 단위로 테이블과 기타 데이터베이스 자산을 분리하고 나중에 요구사항이 발생하면 분산 아키텍처로 쉽게 마이그레이션될 수 있도록 설계해야 합니다.

18.3.2 마이크로커널

실리콘 샌드위치에서 식별된 아키텍처 특성 중 하나가 맞춤성이었습니다. 아키텍트는 도메인/아키텍처 동형성을 검토 후 마이크로커널 형태로 구현할 수도 있습니다.

코어 시스템은 도메인 컴포넌트와 단일 관계형 데이터베이스로 구성됩니다. 이전 설계와 마찬가지로, 도메인과 데이터를 신중하게 동기화하면 향후 분산 아키텍처로 코어를 마이그레이션할 수 있습니다.

프런트엔드를 위한 백엔드(BFF, Backend for Frontends) 패턴을 응용해서 API 레이어를 마이크로커널 어댑터로 사용하는 독특한 설계 방법도 있습니다. 일반적인 정보는 백엔드가 제공하고 BFF 어댑터는 이 정보를 프런트엔드 장치에 적합한 포맷으로 바꾸는 것입니다.

18.4 분산 아키텍처 사례 연구: GGG

GGG는 어느 정도 야심 찬 수준의 규모, 탄력성, 성능, 그 밖의 까다로운 운영 아키텍처 특성이 요구사항에 명시되어 있습니다. 아키텍트는 아키텍처 내부의 세부적인 수준까지 고도의 커스터마이징이 가능한 패턴을 선택해야 합니다.

요약

18.1 아키텍처 ‘유행’은 계속 변한다

• 과거를 돌아보다
  • 새로운 아키텍처 설계는 과거 스타일의 결함을 반영하여 발전합니다.
• 생태계의 변화
  • 소프트웨어 개발 생태계는 끊임없이 변화하며, 이는 긍정적인 특성입니다.
• 새로운 기능
  • 새로운 기능의 출현은 도구 교체를 넘어 완전히 새로운 패러다임으로의 전환을 이끌 수 있습니다.
• 가속
  • 변화의 속도가 계속 빨라지고 있으며, 새로운 도구와 프랙티스가 새로운 설계와 기능으로 이어집니다.
• 도메인 변경
  • 비즈니스의 진화와 합병으로 소프트웨어 개발 도메인도 지속적으로 변화합니다.
• 기술 변화
  • 기술의 발전에 따라 조직은 중요한 이익을 얻기 위해 변화의 흐름을 따라잡으려 합니다.
• 외부 팩터
  • 소프트웨어 개발과 연관된 주변 요인들이 조직의 변화를 유도할 수 있습니다.
• 아키텍트의 역할
  • 아키텍트는 업계 동향을 파악하여 유행을 따를지 말지를 현명하게 결정해야 합니다.

18.2 결정 기준

• 도메인
  • 아키텍트는 도메인의 다양한 양상과 운영 아키텍처 특성에 영향을 미치는 부분을 이해해야 합니다.
• 구조에 영향을 미치는 아키텍처 특성
  • 필요한 아키텍처 특성을 정확히 식별하여 도메인과 외부 요소를 지원해야 합니다.
• 데이터 아키텍처
  • 아키텍트와 DBA는 데이터베이스와 스키마 등 데이터 관련 문제를 협의해야 합니다.
  • 이전 또는 현재의 데이터 아키텍처와 상호작용 시, 데이터 설계가 아키텍처에 미치는 영향을 파악해야 합니다.
• 조직 문제
  • 외부 팩터들이 설계에 영향을 줄 수 있습니다.
• 프로세스, 팀, 운영 문제에 관한 지식
  • 개발 프로세스, 운영팀과의 소통, QA 프로세스 등 다양한 요소가 아키텍처 설계에 영향을 미칩니다.
• 도메인/아키텍처 동형성
  • 아키텍처의 토폴로지와 잘 맞는 문제 영역이 있습니다.
    • 예: 마이크로커널은 맞춤성이 필요한 시스템과 잘 어울립니다.
  • 반대로 부적합한 경우도 있습니다.
    • 예: 큰 모놀리식 구조로는 확장성 높은 시스템 설계가 어렵습니다.
• 모놀리스냐 분산이냐
  • 단일 아키텍처 특성으로 충분한지, 파트별 상이한 특성이 필요한지 판단해야 합니다.
    • 단일 특성이면 모놀리스가 적합합니다.
    • 다양한 특성이면 분산 아키텍처가 적합합니다.
• 데이터를 어디에 둘 것인가?
  • 모놀리스는 일반적으로 하나의 관계형 데이터베이스를 사용합니다.
  • 분산 아키텍처에서는 서비스별 데이터 저장 위치를 결정해야 합니다.
  • 워크플로우 구축 전에 데이터 흐름을 충분히 고려해야 합니다.
• 서비스 간 통신 방식 선택
  • 동기 통신
    • 간편하지만 확장성, 안정성 등에 부정적 영향을 줄 수 있습니다.
  • 비동기 통신
    • 성능과 확장성에서 우수하지만 동기화, 데드락, 디버깅 등의 문제가 있습니다.
  • 권장 사항
    • 기본적으로 동기 통신을 사용하고, 필요시 비동기 통신을 함께 사용하세요.

18.3 모놀리스 사례 연구: 실리콘 샌드위치

• 아키텍처 특성 분석 결과
  • 단일 퀀텀으로 구현해도 충분하다고 결정했습니다.
• 설계 비교
  • 도메인 분할된 컴포넌트와 기술 분할된 컴포넌트로 설계하여 각각의 트레이드오프를 분석했습니다.

18.3.1 모듈러 모놀리스

• 특징
  • 단일 퀀텀으로 배포되는 도메인 중심의 시스템입니다.
  • 각 도메인이 컴포넌트로 표현됩니다.
• 장점
  • 도메인 컴포넌트 단위로 데이터베이스 자산을 분리하면 향후 분산 아키텍처로 쉽게 마이그레이션할 수 있습니다.

18.3.2 마이크로커널

• 특징
  • 맞춤성이 중요한 아키텍처 특성이므로 마이크로커널 형태로 구현합니다.
  • 코어 시스템은 도메인 컴포넌트와 단일 관계형 데이터베이스로 구성됩니다.
• 응용 패턴
  • BFF(Backend for Frontends) 패턴을 어댑터로 사용하여 프런트엔드에 맞는 포맷으로 정보를 제공합니다.

18.4 분산 아키텍처 사례 연구: GGG

• 요구사항
  • 규모, 탄력성, 성능 등 까다로운 운영 아키텍처 특성이 요구됩니다.
• 설계 전략
  • 아키텍처 내부의 세부 수준까지 고도의 커스터마이징이 가능한 패턴을 선택해야 합니다.
• 구현 고려사항
  • 각 서비스의 독립성 확보와 아키텍처 특성 간의 균형을 맞춰야 합니다.