티스토리 뷰
소프트웨어 아키텍처 101 - YES24
막막했던 아키텍처가 쉬워지는 실무 지침서소프트웨어 아키텍트는 전 세계 연봉 10위 안에 드는 직업이지만, 지금까지 ‘개발자가 아키텍트’로 전향하는 데 실질적으로 도움이 될 만한 지침이
www.yes24.com
도메인 중심의 서비스 기반 아키텍처
아키텍처에 별 관심이 없는 사람들이라도 MSA(Micro Serivce Architecture)라는 말을 들어봤을 가능성이 높다. 우선 이 서비스 기반 아키텍처는 MSA의 기반 중 하나이다. 뿐만 아니라 아키텍처에 대해 관심 있는 사람들은 SOA (Service Oriented Architecture)도 들어봤을 것인데 이것을 기반으로 한다.
(사실 Based와 Oriented에서 큰 차이를 못 느낄 수 있지만, Based는 서비스 기반이 핵심이라고 한다면, Oriented는 모든 것이 서비스 중심으로 돌아간다는 것이 핵심이라고 이해하면 좋을 것 같다)
도메인 중심의 생각
서비스 기반에서의 '서비스'는 '도메인 중심적'이다.
흔히 DDD(Domain Driven Design)라고 표현하는데, 우리말로는 도메인 주도 설계이다.
즉, 아래 그림처럼 '기술'단위가 아닌 '도메인' 단위로 서비스를 만들고, 각각의 서비스들을 유기적으로 조합하여 애플리케이션을 만드는 방식이다.
여기서 도메인이라는 것은 분류하기 나름이다. 즉, 그 범위나 규모를 크게 분류할수도 있고, 흔히 서브(sub) 도메인이라고 부르는 형태까지 분류할 수 있는데, 이 서비스 기반 아키텍처는 큰 단위의 도메인으로 분리한다. (왜냐하면 그래야 이 초기 모델로부터 MSA가 등장할 이유가 되니까)
토폴로지 구성
토폴로지는 다양하게 구성할 수 있다.
즉, 유저 인터페이스를 하나 혹은 도메인 기반 혹은 서비스 기반에 따라 여러개로 만들 수 있고,
데이터베이스를 단 하나만 운용하거나 각 도메인/서비스마다 하나씩 논리적/물리적으로 구분하여 사용할 수도 있다.
또한, 유저 인터페이스와 서비스 사이에 API 레이어로써 프록시나 게이트웨이를 둘 수도 있다.
각각의 토폴리지 구성 방법은 당연히 트레이드오프 관계이다. 어플리케이션에 따라 적절하게 선택하는 것이 중요하다. 아키텍처에서는 절대적인 답은 없다는 것을 다시 한번 상기시키자.
트랜잭션 (Transaction)
도메인 기반 아키텍처에서는 도메인 서비스 분류에 대한 세분도가 크기 때문에, 데이터 무결성 보장을 위한 커밋/롤백이 수반되는 ACID DB 트랜잭션을 사용한다. 이는 MSA에서 BASE 분산 트랙잭션 기법을 사용하는 것과는 대조적인데, 이는 이들의 도메인 분류 방법과 그 추구하는 바가 다르기 때문에 그런 것이다.
예를 들어, 주문 처리 시스템에서 재고확인 ~ 상품 선택/최종결제 확인까지 각 서비스별 결과와 상태가 유관하고 중요한데, 만약 여기서 MSA로 처리하려고 한다면 어떻게 될까? 처리를 할 수는 있지만 이러한 일련의 처리 과정에 대해 정확한 오케스트레이션이 필요하다. (물론, 서비스 세분화를 통한 복합적인 문제 최소화 등의 MSA가 가지는 장점들이 있다)
결국 도메인마다 요구하는 바가 다르고, 어떤 방식을 취하냐에 따라 트레이드오프가 존재한다.
결국 아키텍처를 선정할 때는 이러한 부분들을 고려하여 잘 선택해야 한다는 것이다.
아키텍처 특성
| 아키텍처 특성 | 별점 |
| 분할 유형 | 도메인 |
| 퀀텀 수 | 1 or N |
| 배포성 | ★★★★ |
| 탄력성 | ★★ |
| 진화성 | ★★★ |
| 내고장성 | ★★★★ |
| 모듈성 | ★★★★ |
| 전체 비용 | ★★★★ |
| 성능 | ★★★ |
| 신뢰성 | ★★★★ |
| 확장성 | ★★★ |
| 단순성 | ★★★ |
| 시험성 | ★★★★ |
마무리
이번 아키텍처에 대해 설명하면서, 계속 트레이드오프와 적절한 선택에 대해 강조했다.
사실 어떠한 아키텍처이든지 간에 이러한 고민을 계속하는건 당연하고 마땅하다.
하지만, 유독 더 강조했던 이유는 이것이 MSA와 계속 비교될 수 있기 때문인데, 트레이드오프를 고려하지 않고 특정 기술/개념에만 빠져버리는 잘못된 길을 가지 않도록 우리 스스로에게 계속해서 질문을 던져보길 바래서였다.
여기서 이번 시리즈 가장 처음에 나왔던 이야기들을 다시 한번 상기시켜 보자.
최고(best)의 아키텍처를 고집하지 말고 나쁜 것 중에서 제일 나은(least worst) 아키텍처를 선택하세요
- 소프트웨어 아키텍처 101, p.99.
소프트웨어 아키텍처의 특성을 생각하며, 트레이드 오프를 고려하며 "성공적인 애플리케이션 서비스/유지보수"에 맞는 가장 나은(least worst) 아키텍처를 선택하는 능력을 기르는 것이 중요하다.