- 최적의 아키텍처 스타일은 상황에 따라 다르다!
- 아키텍처 특성, 도메인 고려사항, 전략적 목표 + 그외 상황을 고려하여 선택
- 아키텍트는 과거를 반영한 현재의 사고로 미래의 시스템을 내다본다.
- 과거의 스타일에서 발생한 결함을 보완한 경우가 많다.
- 생태계의 변화(쿠버네티스), 새로운 기능의 출현, 흐름의 가속화, 도메인 변경, 기술의 진화, 외부 팩터(라이센스 등)이 영향을 미친다.
- 도메인 설계 구조의 원인이 될 만한 모든 요소를 종합적으로 고려해야 한다.
- 도메인: 최소한 중요한 파트에 대해서는 지식을 가지고 있어야 함
- 아키텍처 특성: 도메인과 외부 다른 요소를 지원하는데 필요한 아키텍처 특성을 정확하게 밝혀내야 함
- 데이터 아키텍처: 데이터 설계와 영향도를 고려해야 함
- 조직 문제
- 운영 문제: 프로세스, 팀, 운영 문제에 대한 지식이 필요함
- 도메인~아키텍처의 동형성: 문제 영역과 아키텍처 스타일이 잘 맞아야 함(예를 들어, 규모가 큰 모놀리식은 확장성을 고려한 설계가 어려움)
- 모놀리식? 분산?: 단일 아키텍처 특성만으로 설계가능한지, 시스템 파트별로 상이한 아키텍처 특정이 필요한지 판단해야 함
- 데이터를 어디에?: 워크플로를 구축하기 전에 전체 아키텍처의 데이터 흐름에 대해 충분히 숙고해야 함. 어떤 서비스가 어떤 데이터를 저장할 것인가.
- 서비스간 통신(동기? 비동기?):
- 동기: 간편하지만 확장성, 안정성 등에 부정적 영향 가능성
- 비동기: 성능, 확장성 측면에서 우월하지만, 데이터 동기화, 데드락, 경합조건, 디버깅 등이 어려움
- tip: 동기 통신을 기본으로 하고 필요시 비동기를 사용
- 시간과 리소스가 넉넉하다면 도메인 컴포넌트 단위로 테이블과 기타 데이터베이스 자산을 분리하고 나중에 요구사항 발생시, 분산 아키텍처로 쉽게 마이그레이션 될 수 있도록 설계하자
- 개별적으로 커스터마이징 할 수 있도록 오버라이드 엔드포인트를 설계해야 함
-
각 플러그인은 커플링 되지 않아 각자 자신의 데이터를 유지
-
BFF(Backends For Frontends) 패턴을 응용하여 API를 마이크로커널 어댑터로 사용하는 방식도 존재
- BFF 패턴은 API 게이트웨이와 같은 진입점을 하나로 두지 않고 프론트엔드의 유형에 따라 각각 두는 패턴
- 출처: https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern
-
모듈러 모놀리스, 마이크로커널 모두 엄청난 성능이나 탄력성을 요하지 않고, 오래걸리지 않으므로 통신은 동기 방식으로 충분
- GGG(Going, Going, Gone) 가타란?
- 가타
- 참고: 5장 104pg
- 도메인에 관한 설명을 보고 아키텍처 특성을 도출하는 연습
- 올바른 자세와 기술을 중시하는 개인 훈련 체계
- 설명, 유저, 요구사항 + 부가 콘텍스트 를 설정하여 설계 연습을 하는 것
- GGG
- 참고: 7장 135pg
- “없나요? 없습니까? 네, 팔렸습니다!” 로 경매인이 주로 많이 쓰는 말
- 책에서 의미하는 것은 온라인 경매 회사의 아키텍처 가타를 의미함
- 특정 아키텍처 용어인 줄 알았으나 아니었다.
- 가타
- GGG는 어느 정도의 큰 규모, 탄력성, 성능, 그 밖의 까다로운 운영 아키텍처 특성이 요구사항에 명시
- 아키텍트는 아키텍처 내부의 세부적인 수준까지 고도의 커스터마이징이 가능한 패턴을 선택해야 함
- 대부분의 특성을 충족하는 아키텍처 -> 저수준의 이벤트 기반 또는 마이크로서비스
- 순수한 이벤트 기반 아키텍처는 대부분 운영 아키텍처 특성에 따라 나누지 않고, 통신스타일(오케스트레이션, 코레오그래피)에 따라 구분됨
- 오케스트레이션: 중앙에서 관리하는 시스템이 존재
- 코레오그래피: 이벤트를 발행하면 필요한 시스템이 그 이벤트를 수신하여 반응
- 동기 통신 스타일과 비동기 통신 스타일을 주의 깊게 식별하였음
- 비동기 통신을 선택한 것은 서비스마다 상이한 운영 아키텍처 특성을 고려한 결과
- 결과적으로 여러개의 퀀텀으로 마무리
- 설계의 정답은 없다
- 적어도 트레이드오프가 가장 나쁜 것 중에서 제일 나은 설계
- 마이크로서비스를 도입하고 이벤트와 메시지를 영리하게 이용하면 최대한 활용하면서 향후 개발과 확장이 용이한 기반을 다질 수 있다