[소프트웨어 아키텍처 101] 파트2

9장. 기초

진흙잡탕

대충 되는 대로, 아무렇게나 막 지저분하게, 덕지덕지 붙여놓은 스파게티 코드 정글
뭐 하나 뚜렷한 아키텍처 구조가 전무한 상태를 표현 
대수롭지 안헥 시작한 애플리케이션이 나중에 규모가 커져 처치 곤란한 상태 

모놀리식 대 분산 아키텍처 

아키텍처 스타일은 크게 전체 코드를 단일 단위로 배포하는 모놀리식, 여러 단위로 배포하는 분산형 두 종류가 있다
분산 아키텍처는 모놀리식에 비해 성능, 확장성, 가용성 측면에서 강력하지만, 분산 아키텍처에서는 무시할수 없는 트레이드 오프가 수반된다.
아래는 '분산 컴퓨팅의 오류' 라는 글에서 최초로 거론된 8가지 오류이고, 이는 현대 분산 아키텍처에서도 적용된다.

• 네트워크는 믿을 수 있다
  • 분산 아키텍처는 특성상 네트워크에 의존하는데, 실제로 네트워크는 믿을수 없다
  • 때문에 타임아웃, 회로 차단기 같은 장치를 마련한다
• 레이턴시는 0이다
  • 로컬에서 다른 컴포넌트를 호출하면 대개 나노 초 내지 밀리초 단위로 측정되지만, 원격으로 호출하면 최소 밀리초 단위다
  • 네트워크가 빠르다고 주장하며 이를 무시하려고 하지만, 이는 무시할수 없다
  • 평균 레이턴시, 95~99 백분위 레이턴시를 이해해야한다
  • long tail 레티언시는 분산 아키텍처의 성능을 저해하는 주범이다
• 대역폭은 무한하다
  • 모놀리식은 큰 대역폭이 필요하지 않지만, 분산 아키텍처는 대역폭을 상당히 점유한다
  • 분산 아키텍처는 서비스 또는 시스템간에 최소한의 데이터만 주고 받도록 해야 한다
• 네트워크는 안전하다
  • VPN, 신뢰할수 있는 네트워크, 방화벽에 익숙해져 네트워크가 안전하지 않다는 사실을 망각한다
  • 보안은 분산 아키텍처에서 특히 더 어려운 문제이다
• 토폴로지는 절대 안 바뀐다
  • 네트워크를 구성하는 모든 라우터, 허브, 스위치, 방화벽, 네트워크, 어플라이언스 등 전체 네트워크 토폴로지가 불변일 것이라고 가정한다
  • 아키텍트는 운영자, 네트워크 관리자와 항시 소통을 하며 무엇이 언제 변경되는지 알아야 한다. 그래야 적절히 대응할 수 있다
• 관리자는 한 사람뿐이다
  • 언제나 한 사람의 관리자와면 협의하고 소통하면 된다는 오류에 빠진다
  • 분산 아키텍처는 복잡할 수밖에 없고 상당히 많은 사람과 많은 조율 과정이 불가피하다
• 운송비는 0이다
  • rest 호출을 하는데 소요되는 진짜 비용을 0으로 생각한다
  • 분산 아키텍처는 하드웨어, 서버, 게이트웨이, 방화벽, 서브넷, 프록시 등 리소스가 더 많이 든다
  • 따라서 모놀리식보다 비용이 훨씬 더 많이 든다
• 네트워크는 균일하다
  • 모든 장비가 같은 하드웨어 업체에서 만들었다고 생각한다
  • 하지만 실제로는 많은 회사의 인프라, 하드웨어가 섞여있고, 이것들이 모두 다 잘 맞물려 동작하지는 않는다

이 외 분산 아키텍처를 설계할때 만나는 이슈 및 난제들이 있다

• 분산 로깅
  • 애플리케이션과 시스템 로그가 분산되어 데이터 누락의 근본 원인을 밝혀내기 어렵고 시간도 많이 걸린다
• 분산 트랜잭션
  • 분산 아키텍처는 최종 일관성 개념을 바탕으로 분리된 배포 단위에서 처리된 데이터를 어느 시점에 일관된 상태로 동기화 한다
  • 확장성, 성능, 가용성의 대가로 데이터 일관성과 무결성을 희생하는 트레이드오프다
  • 분산 트랜잭션 관리 방법으로는 트랜잭셔널 사가가 있다
• 계약 관리 및 버저닝
  • 계약생성, 유지보수, 버저닝도 까다로운 문제다

 

10장. 레이어드 아키텍처 스타일

레이어드 아키텍처 (n티어 아키텍처)는 가장 흔한 아키텍처 스타일중 하나다.
단순하고 재중적이며 비용도 적게 들어 사실상 표준 아키텍쳐다.

각 레이어는 특정한 역할을 수행한다
프레젠테이션 레이어는 유저 인터페이스/브라우저 통신, 비즈니스 레이어는 알맞은 비즈니스 규칙 실행 등
주어진 비즈니스 요청을 충족하는데 필요한 업무 위주로 추상화 되어 있다.
프레젠테이션 레이어는 고객 데이터를 조회하는 방법을 알 필요가 없고, 그럴 이유도 없다.

이런 관심사의 분리 개념 덕분에 아키텍처 내부 역할 및 책임 모델을 효과적으로 구성 가능하다.
특정 레이어에 소속된 컴포넌트는 역할 범위가 한정되며 그 레이어의 로직만을 처리한다.

따라서 개발자 본인의 기술 역량을 기술적인 부분에 집중시킬 수 있지만, 전체적인 민첩성은 떨어진다.

레이어 격리

각 레이어는 폐쇄 또는 개방 상태다.
폐쇄 레이어는 요청이 상위에서 하위로 이동하므로 중간에 어떤 레이어도 건너뛸 수 없고 현재 레이어를 거쳐야 다음 레이어로 갈수 있음을 의미한다.

레이어 격리는 어느 레이어에서 변경이 있어도 다른 레이어의 컴포넌트엔 영향을 끼치지 않기에 레이어간 계약은 불변임을 의미한다.
각 레이어는 독립적으로 작동되므로 다른 레이어의 내부 작동 로직은 알지 못한다

기타 고려 사항

아키텍처 싱크홀 안티패턴을 조심해야 한다.
요청이 한 레이어에서 다른 레이어로 이동할 때 각 레이어가 아무 로직도 처리하지 않고 그냥 통과시키는 안티패턴을 의미한다.
이는 불필요한 객체 초기화 및 처리를 빈번하게 유발하고 쓸데없이 메모리를 소모하며 성능에도 부정적인 영향을 끼친다.
아키텍처 싱크홀이 전무한 시스템은 없겠지만, 그 비율을 최소한으로 유지하려 노력해야 한다 (80대 20법칙)

장단점

전체 비용과 단순성은 주요 강점이다.
복잡도가 낮고, 구조가 단순하여 알기 쉬운데다 구축 및 유지보수 비용도 비교적 적게 든다.
하지만 레이어드 아키텍처가 점점 커지고 복잡해질수록 이런 장점들도 희미해진다.

배포성과 시험성, 탄력성, 확장성이 좋지 않은게 주요 단점이다.
배포의 절차가 까다롭고 리스크가 높으며 자주 배포할수 없다.

 

11장. 파이프라인 아키텍처 스타일

다수의 파이프와 필터로 구성된다.

파이프
한 소스에서 입력을 받아 다른 소스로 출력을 내는 필터간 통신 채널
성능상 이유로 보통 단방향, 점대점 방식으로 구성

필터
다른 필터와 독립적이며 일반적으로 무상태성
한가지 태스크만 수행하므로 복합 태스크는 여러 필터를 붙여 처리
필터는 다음 네가지 종류가 있다

• 프로듀서 (producer)
  • 프로세스의 시작점
  • 아웃바운드만 있어 소스라고도 한다
• 변환기 (transformer)
  • 입력을 받아 필요시 일부 또는 전체 데이터를 변환 후 아웃바운드 파이프로 전달
  • 함수형 프로그래밍의 map
• 테스터 (tester)
  • 입력을 받아 하나 이상의 기준에 대해 테스트 하고 결과에 따라 필요시 결과를 생산
  • 함수형 프로그래밍의 reduce
• 컨슈머 (consumer)
  • 파이프라인의 종착역
  • 프로세스의 최종 결과를 데이터베이스에 저장하거나 UI 에 표시

장단점

애플리케이션 로직을 필터 타입에 따라 나누는 기술 분할 아키텍처
보통 모놀리식 형태로 구현/배포

주요 장점은 모듈성과 결부된 전체 비용 및 단순성
모놀리식에 가깝기 때문에 분산 아키텍처의 복잡도가 없고, 단순해서 알기 쉬워 구축 및 유지보수 비용이 비교적 적게 든다

주요 단점은 탄력성과 확장성이다.
확장을 하려면 대부분 멀티스레딩, 내부 메시징을 비롯해 어울리지 않는 병렬 처리 프랙티스와 기법이 필요하다

 

12장. 마이크로커널 아키텍처 스타일

코어 시스템과 플러그인 컴포넌트 두 요소로 구성된 단순한 모놀리식 아키텍처
애플리케이션 로직은 독립적인 플러그인 컴포넌트와 기본 코어 시스템에 골고루 분산

코어시스템

시스템을 실행시키는 데 필요한 최소한의 기능으로 정의
커스텀 처리가 거의/전혀 필요 없는, 애플리케이션을 광통하는 정상경로라고 정의할수 있다

플러그인 컴포넌트

특수한 처리 로직, 부가 기능, 코어 시스템 개선/확장하기 위한 커스텀 코드가 구현된 스탠드얼론 컴포넌트
변동성이 큰 코드를 분리하여 유지보수성, 시험성을 높이는 것
이상적인 플러그인 컴포넌트는 상호 독립적이며 의존성이 없다

플러그인 컴포넌트는 라이브러리 형태로 제공을 하거나, 스탠드얼론 서비스로 만들어 rest 나 메시징 등 다른 방법으로도 호출할 수 있다.

레지스트리

코어 시스템은 어떤 플러그인을 사용할수 있는지, 가져오려면 어떻게 해야 하는지 알고 있어야 한다.
일반적은 방법은 플러그인 레지스트리를 경유 하는 것이다.
이 레지스트리에는 플러그인 명칭, 데이터 계약 등 플러그인 모듈에 관한 정보가 있다.

장단점

단순성과 전체 비용은 주요 강점이다.
모놀리식 배포 탓에 확장성, 내고장성은 주요 단점이다.
도메인 분할, 기술 분할이 모두 가능한 유일한 아키텍처 스타일이다.

 

13장. 서비스 기반 아키텍처 스타일

마이크로서비스 아키텍처 스타일의 일종으로, 아키텍처가 유연해서 실용적인 아키텍처 스타일중 하나이다.

토폴로지

기본 토폴로지는 각각 따로 배포된 유저 인터페이스, 원격 서비스, 모놀리스 데이터베이스로 이루어진 대규모 분산 레이어 구조이다

서비스 기반 아키텍처 기본 토폴로지 출처 : 소프트웨어 아키텍처 101

중앙 공유 데이터베이스를 사용한다는 특징이 중요하다. 따라서 서비스는 기존 모놀리식 레이어드 아키텍처와 동일한 방식으로 데이터를 사용한다.

토폴로지 변형 

서비스 기반 아키텍처는 특유의 유언성 때문에 다양한 변형이 존재한다.
위 13-1 그림기반으로, 유저 인터페이스를 여러 유저 인터페이스로 나눌수도 있고, 도메인 서비스에 맞게 나눌 수도 있다.
또 데이터베이스 역시 개별 데이터베이스로 분리(마이크로서비스와 비슷하게) 하거나 각 도메인 전용 데이터베이스로 쪼갤 수도 있다.
이런 경우엔 각 데이터베이스 도메인 데이터를 다른 도메인 서비스가 필요로 하지 않도록 설계하는 것이 중요하다.
그래야 도메인 서비스 간 상호 통신을 방지하고, 중복 데이터를 방지할 수 있다.

장단점

서비스 기반 아키텍처는 도메인 분할 아키텍처이다. 
민첩성, 시험성, 배포성, 내고장성, 가용성이 장점이다.
아키텍처 스타일을 응용해서 개별 배포되는 여러 도메인 서비스로 나눌수 있고, 도메인 범위가 한정되므로 테스트 커버리지가 향상된다.
단순성과 전체 비용 측면에서 마이크로서비스, 이벤트 기반 아키텍처, 공간 기반 아키텍처 등 비교적 비용이 많이 들고 복잡한 분산 아키텍처와 차별화 된다.
가장 구현하기 쉽고 비용면에서 효율적인 분산 아키텍처여서 가장 실용적인 아키텍처 라고 볼 수도 있다.
이보다 더 강력한 분산 아키텍처 스타일도 있지만 이는 곧 가파른 비용 상승을 동반하고 그렇게까지 강력할 필요가 없는 경우가 많다.

 

14장. 이벤트 기반 아키텍처 스타일

확장성이 뛰어난 고성능 애플리케이션 개발에 널리 쓰이는 비동기 분산 아키텍처 스타일이다.
소규모부터 크고 복잡한 애플리케이션까지 두루 사용 가능하다.
이벤트를 비동기 수신/처리 하는 이벤트 처리 컴포넌트들로 구성되며, 스탠드얼론 아키텍처로 사용하거나 다른 아키텍처에 내장할 수 있다.

토폴로지

주요 토폴로지는 중재자 토폴로지와 브로커 토폴로지가 있다.
중재자는 이벤트 처리 워크플로 제어, 브로커는 신속한 응답과 동적인 이벤트 처리 제어가 필요할때 사용한다.

브로커 토폴로지

중앙에 이벤트 중재자가 없는 토폴로지다.
메시지는 주로 메시지 브로커를 통해 브로드캐시틍 되는 식으로 흘러간다.
비교적 이벤트 처리 흐름이 단순하고 굳이 중앙에서 이벤트를 조정할 필요가 없을때 유용하다.
네 가지 기본 컴포넌트인 시작이벤트, 이벤트브로커, 이벤트프로세서, 처리 이벤트로 구성된다

브로커 토폴로지는 다른 이벤트 프로세서의 관심 여부와 무관하게 각 이벤트 프로세서가 자신이 한 일을 모두에게 알리는게 바람직 하다.
그래야 추후에 기능 추가가 필요할때 아키텍처를 쉽게 확장할 수 있다.

성능, 응답성, 확장성 측면에서 장점이 있지만
시작 이벤트와 연관된 전체 워크플로를 제어할수 없다는 단점이 있다.
따라서 어느 파트도 실제 전체 트랜잭션이 언제 끝났는지 알수 없고, 에러 처리도 어렵다. 
중재자가 없으므로 처리가 실패해도 다른 파트는 알수 없고, 별도 조치를 해주지 않으면 프로세스는 정체된다.
비즈니스 트랜잭션을 재시작하는 기능(복구성)도 지원되지 않는다

중재자 토폴로지

브로커 토폴로지의 단점을 일부 보완한다.
여러 이벤트 프로세서 간의 조정이 필요한 시작 이벤트에 대해 워크플로를 관리/제어하는 이벤트 중재자가 핵심이다.

시작 이벤트는 이벤트 큐를 거쳐 이벤트 중재자로 전달된다.
이벤트 중재자는 이벤트 처리에 관한 단계 정보를 갖고 있고, 각 이벤트 채널로 전달되는 처리 이벤트를 생성한다.
각 이벤트 프로세서는 자신의 이벤트를 받아 처리한 다음 중재자에게 작업 완료 응답을 보낸다.

브로커 토폴로지와 달리 워크플로에 대해 잘 알고 있고 통제가 가능하다.
이벤트 상태를 유지하면서 필요시 에러처리, 복구, 재시작이 가능하다.

단점도 있는데,
첫째, 복잡한 이벤트 흐름 내에서 발생하는 동적인 처리를 선언적으로 모델링 하기 매우 어렵다.
둘째, 이벤트 프로세서는 쉽게 확장할 수 있찌만, 중재자도 함꼐 확장해야 하므로 전체 이벤트 처리 흐름에 병목 지점이 생기기 쉽다.
셋째, 이벤트 처리를 중재자가 제어하므로, 이벤트 프로세서가 커플링되어 성능은 브로커 토폴로지보다 좋지 않다.

비동기 통신

이벤트 기반 아키텍처 스타일은 비동기 통신만 사용한다는 점에서 다른 아키텍처와 차별화 된다.
비동기 통신에서는 에러 처리가 가장 큰 문제인데, 응답성은 많이 개선되지만 에러 처리가 쉽지 않아 복잡도가 가중된다.

에러처리

에러 처리 문제를 해결하기 위한 방법 중 한가지로 리액티브아키텍처의 워크플로 이벤트 패턴이 있다.
시스템의 응답성에 영향을 미치지 않고 탄력적으로 에러 처리를 할수 있게 해준다.

워크플로 이벤트 패턴 출처 : 소프트웨어 아키텍처 101

워크플로 대리자를 통해 위임, 봉쇄, 수리 작업을 한다.
이벤트 컨슈머가 처리 도중 에러가 발생하면 해당 에러를 워크플로 프로세서에 위임한 뒤 다음 메시지로 넘어간다.
이런 구조 덕분에 응답성에 영향을 미치지 않는다.
워크플로 프로세서는 프로그래밍 방식으로 원데이터를 변경해서 조치한 후 원래 큐로 돌려보낸다.
이벤트 컨슈머는 이 메시지를 새로운 메시지로 간주하여 재처리를 시도한다.

 

데이터 소실 방지

이벤트 기반 아키텍처는 데이터가 소실될 만한 곳이 많다.
이벤트프로세서A가 큐에 메시지를 비동기 전송하고 이벤트 프로세서B는 이 메시지를 받아 데이터베이스에 저장하는 일반적인 시나리오를 가정하자.
이 시나리오에서 데이터 소실이 일어나는 경우는 세 가지가 있다.

1. A 에서 메시지가 큐로 전달되지 않거나 브로커가 다운된다
2. B가 큐에서 메시지를 꺼내 이벤트를 처리하기 전에 장애가 발생한다
3. 데이터 에러로 인해 B가 데이터베이스에 저장할 수 없다

1번 이슈는 동기 전송과 퍼시스턴트 메시지 큐를 이용하면 해결된다.
브로커가 메시지를 수신하면 메모리에 저장하는 동시에 물리적 데이터 저장소에도 메시지를 저장한다.
이러면 메시지 브로커가 다운되도 디스크에 저장되어 있기 때문에 복구가 가능하다.
동기 전송은 브로커가 메시지를 저장했다고 응답 할때까지 메시지 프로듀서를 기다리게 한다

2번 이슈는 클라이언트 확인응답 모드를 통해 해결 가능하다.
다른 컨슈머가 읽을수 없도록 메시지를 큐에 보관하고, B가 응답했을때 큐에서 삭제해준다.

3번 이슈는 데이터베이스 본연의 트랜잭션 커밋으로 해결한다

브로드캐스팅

이벤트 기반 아키텍처는 메시지를 누가 받는 무슨일을 하든 상관없이 이벤트를 브로드캐스트 할수 있다. 
메시지 프로듀서는 자신이 보낸 메시지를 어느 이벤트 프로세서가 수신할지, 받아서 무슨일을 할지 알수 없다.

장단점

특정 도메인이 여러 이벤트 프로세서에 분산되어 있는 기술 분할된 아키텍처이다.
성능, 확장성, 내고장성이 주요 강점이다.
특유의 비결정적, 동적인 이벤트 흐름 때문에 단순성과 시험성이 안좋은 것은 단점이다.

 

15장.  공간 기반 아키텍처 스타일

높은 확장성, 탄력성, 동시성과 관련된 문제를 해결하기 위해 설계된 아키텍처
유저 수 증가에 따른 병목 현상의 가장 일반적인 해결 방법은 확장이다.
비교적 쉽고 효과적으로 병목을 제거 할수 있지만, 부하는 웹서버 -> 애플리케이션서버 -> 데이터베이스로 이동한다.
최종적으로 데이터베이스가 동시 처리 가능한 트랜잭션 수가 최종 제약 조건이 되는 경우가 많다.
다양한 캐시 기술과 데이터베이스 확장으로 문제를 해결할순 있찌만, 엄청나게 많은 부하 상태에서 확장하는 작업은 만만하지 않다. 
극단적이고 가변적인 확장성 문제는 데이터베이스를 확장하거나, 확장성이 떨어지는 아키텍처에 맞게 캐시 기술을 적용하는 것보다 아키텍처 적으로 해결하는 것이 낫다

토폴로지

시스템에서 동기 제약조건인 중앙 데이터베이스를 없애고, 복제된 인메모리 데이터그리드를 활용한다.
애플리케이션 데이터는 메모리에 둔 상태로 모든 처리 장치들이 데이터를 복제한다.
처리 장치들은 데이터를 업데이트 할때 퍼시스턴스큐에 메시지를 보내는 식으로 데이터베이스에 데이터를 비동기 전송한다.
중앙 데이터베이스는 표준 트랜잭션 처리에 관여하지 않으므로 데이터베이스 병목 현상을 없애고, 애플리케이션은 거의 무한에 가까운 확장을 할 수 있다.

애플리케이션 코드가 구현된 처리 장치, 처리 장치를 관리/조정하는 가상 미들웨어, 업데이트된 데이터를 데이터베이스에 비동기 전송하는 데이터 펌프, 데이터 펌프에서 데이터를 받아 업데이트를 수행하는 데이터 라이터, 처리장치가 시작하자마자 데이터베이스의 데이터를 읽어 전달하는 데이터 리더 컴포넌트로 구성된다.

공간 기반 아키텍처 기본 토폴로지 출처 : 소프트웨어 아키텍처 101

동작 방식 및 구성 요소가 복잡하므로, 필요시 책을 다시 정독하자.

장단점

탄력성, 확장성, 성능이 가장 좋다. 
이 아키텍처 기반으로 시스템을 구축하면, 수백만명의 동시 유저도 처리 할수 있다.
전체적인 단순성과 시험성 측면, 많은 비용에서는 단점이 있다.
캐시 사용, 최종 일관성이라는 개념으로 인해 구조가 매우 복잡하다.
수많은 가동부에서 충돌이 발생해도 데이터가 소실되는 일이 없도록 주의를 기울여야 한다.

 

17장. 마이크로서비스 아키텍처 스타일

최근 가장 각광 받고 있는 아키텍처이다.
도메인 주도 설계 사상의 많은 영향을 받았고 특히 디커플링 스타일을 나타낸 경계 컨텐스트 개념은 결정적인 영향을 미쳤다.
주요 목표는 경계 콘텐스트의 논리적 개념을 물리적으로 모델링하는 고도의 디커플링이다.

토폴로지

마이크로서비스는 단일 목적만 가지기 때문에 다른 분산 아키텍처보다 서비스 규모가 훨씬 작다.
각 서비스는 데이터베이스등 서비스가 독립적으로 작동하는데 필요한 것들이 전부 준비되어 있다.

분산

마이크로서비스는 분산 아키텍처를 형성한다.
분산 속성 탓에 성능은 다소 부정적이다. 
서비스 경계를 넘나드는 트랜잭션을 사용하지 않도록 해야한다.
서비스 세분화를 어느정도로 잘 하는지가 성공의 관건이다.

경계 컨텍스트

각 마이크로서비스는 어느 한 도메인이나 서브 도메인을 나타낸다

세분도
종종 서비스를 너무 잘게 나누는 실수를 하곤 한다. '마이크로서비스'라는 용어를 지령처럼 받아들여 지나치게 세분화 하지 않도록 해야한다.

목적
가장 확실한 경계는 이 아키텍처의 본래 의도인 도메인 이다. 
각 마이크로서비스가 기능적으로 응집되어 있고 하나의 핵심 기능을 제공하는 것이 이상적이다

트랜잭션
여러 엔티티가 함께 개입하여 작동하는 트랜잭션은 좋은 서비스 경계 후보이다.

데이터 격리
경계 컨텍스트 개념에 따라 데이터를 격리해야 한다
시스템 내부 값들을 통합하여 단일 데이터베이스를 만드는데 익숙한데, 마이크로서비스에서는 그렇게 하면 안된다.
어떻게 하면 아키텍처 전체에 데이터를 분산시킬 수 있을지 고민해야 한다.

운영 재사용

모니터링, 로깅, 회로 차단기 등의 커플링이 유리한 아키텍처는 어떻게 처리할까?
여러 마이크로 서비스를 구축하다보면 각 서비스에 공통적인 요소가 있고 이 유사성을 활용하면 유리한 부분이 있음을 알게 된다.
이 문제를 해결하는 방법으로 사이드카 패턴이 있다.

사이드카 패턴 출처 : 소프트웨어 아키텍처 101

공통 운영 관심사를 별도의 컴포넌트로 두고, 해당 팀이나 공유 인프라 팀이 소유하도록 한다.
사이드카 컴포넌트가 운영 관심사를 처리한다.

통신

서비스간 통신 방식을 결정해야 한다.
일반적으로 '프로토콜 인지 이종간 상호 운용성' 을 활용한다.

프로토콜 인지
운영 커플링을 방지하고자 중앙 통합 허브를 갖고 있지 않기 때문에 각 서비스는 다른 서비를 호출하는 방법을 알아야 한다.
서비스는 다른 서비스를 호출할때 어떤 프로토콜을 사용하지 알아야 한다.

이종
각 서비스마다 구현 기술 스택이 다를수 있다. 

상호 운용성
여러 서비스가 서로 호출한다

장단점

현대 엔지니어링 프랙티스를 훌륭하게 지원한다.
분산 아키텍처라서 런타임에 여러 조각들이 연결되고 그로인한 결함에 시달린다.
장점은 확장성, 탄력성, 진화성, 모듈성이다.

분산 아키텍처 특성상 잦은 네트워크 호출로 인한 오버헤드가 있어 성능 문제가 불거질때가 많다.
과도한 네트워크 호출을 줄이고 성능을 개선하기 위해 데이터 캐시, 복제 등의 기술을 많이 사용한다.

 

18장. 최적의 아키텍처 스타일 선정

최적의 아키텍처는 상황에 따라 다르다

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

생태계의 변화, 새로운 기능, 변화의 속도가 빨라짐, 도메인의 변경, 기술의 변화, 외부 팩터등 수많은 변화의 요인이 존재한다.

결정 기준

도메인 설계 구조의 원인이 될 만한 모든 요소를 종합적으로 고려해야 한다

도메인
도메인에서 가장 중요한 여러 가지 양상, 특이 어느 부분이 운영 특성에 영향을 미치는지 파악

구조에 영향을 미치는 아키텍처 특성
도메인을 지원하는데 필요한 아키텍처 특성

데이터 아키텍처
데이터베이스, 스키마 등 

조직 문제

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

도메인/아키텍처 동형성

위와 같은 요소들을 종합해 고려하여 다음과 같은 결정을 내려야 한다.

모놀리스/분산, 데이터 적재 위치, 서비스간 통신 스타일