아키텍처 종류 몇가지 정리해보기

들어가기

아키텍처 종류에 대해서 정리해보았는데 아키텍처만 정리하지 않고 아키텍처를 다루면서 같이 언급되는 대상까지 간단하게 정리했다. 개인적으로 한번 정리하고 싶었고 공유하면 괜찮을 듯해서 정리해보았다.

작성자: http://ospace.tistory.com/ (ospace114@empal.com)

모노리스(Monolith)

모노리스는 아키텍처라고는 할 수 없다. 전체 애플리케이션을 한 덩어리인 결과물이라고 할 수 있다. 즉, 배포할 때에 결과물도 하나인 경우를 말한다. 과거에 대부분의 애플리케이션이 모노리스 형식으로 많이 배포되었다. 성능 상에 이슈에는 여러 모노리스 애플리케이션을 배치해 수평확장하는 구조로 되어 있다.

모노리스라고 해서 아키텍처가 무시되지는 않는다. 내부적인 아키텍처는 다양한 형태로 구성될 수 있다. 모노리스에서 문제점으로 아무리 좋은 설계를 했어도 너무 쉽게 구조가 망가질 수 있다. 지금은 여러 정적분석 도구가 나와서 이런 부분을 어느정도 방지할 수 있다고 하지만 한계가 있다. 또한 운영 측면에서 단일 큰 바이너리이기 때문에 배포할 때에 더 많은 자원이 필요하다는데에 문제점이 있다.

초기 개발적인 측면에서는 아주 빠르게 개발을 시작할 수 있고, 리팩토링을 통해 내부구조를 개선할 수도 있다는 장점도 있다. 그러나 어느 정도도 크기가 커지기 시작하면 전체를 변경하기 어려워지기 시작한다.

계층형(Layered) 아키텍처

계층형 아키텍처는 가장 단순하고 전통적인 아키텍처이다. 이 아키텍처 특징은 수평으로 계층으로 분할되어 있다. 같은 계층 내에서 여러 영역으로 구분하기도 한다. 보통 영역 구분하는 기준이 같은 역할을 가지는 대상들을 묶어서 구분한다. 마틴 파울러의 계층형 아키텍처 패턴에 따르면 프레젠테이션, 비즈니스 로직, 데이터 엑세스 계층으로 분리한다. 물론 경우에 따라서 더 구분할 수 도 있다.

Fig 01. 계층형 아키텍처

계층형 아키텍처에 가장 강력한 제약사항은 계층은 바로 아래 계층에만 의존해야 한다. 그리고 의존하는 방향은 위에서 아래 방향이 된다. 좀 느슨한 경우 여러 계층은 뛰어 넘어서 아래 계층을 의존하기도 한다. 의존 방향이 반대인 경우는 절대 안된다. 그리고 가급적 하위 계층의 구현체에 의존하기 보다는 인터페이스에 의존하는게 좋다. 좀더 유연한 구조가 된다.

대부분의 아키텍처 이미지들을 보면 대부분 계층형 아키텍처 형태를 많이 차용하고 있다.

Fig 02. Spring Framework Architecture

CBD(Component Based Development)

CBD는 모듈화 단위로 구조화하여 재사용하는 컴포넌트로 구성하는데 있다. 콤포넌트의 핵심이 조립과 교환이 가능하다는 점이다. 이렇게 함으로서 재사용을 높일 수 있다. 컴포넌트는 시스템 구성의 일부이고 이런 컴포넌트가 모여서 전체 시스템이 완성된다.

이 컴포넌트 안에는 비즈니스 로직과 영속성 처리 코드까지 포함되어 있고 인터페이스를 통해서 접근하게 해서 내부 세부 구현을 감춘다. 이런 컴포넌트는 별도 배포 단위로 구성되는가장 작은 단위가 되기도 한다.

플러그인(plugin) 아키텍처 스타일이 엄격한 CBD라고 할 수 있다. 즉, 제한적인 CBD 형태라고 생각한다.

Fig 03. CBD 아키텍처

SOA(Service Oriented Architecture)

SOA는 전사적인 아키텍처로 전체 시스템에 대해 컴포넌트 들을 모아서 서비스 단위로 모듈화 한 것이다. 이런 서비스가 기본 구성요소로 비즈니스 기능을 제공하며 서비스들 간에 결합을 통해 기능을 제공한다. 이렇게 함으로써 각 서비스는 다른 애플리케이션에서 재사용할 수 있는 장점이 생긴다.

또한 서비스 간에는 ESB(Enterpise Service Bus)는 통신을 위한 소프트웨어를 사용해 기술에 종속되지 않고 통신을 사용할 수 있도록 한다. SOA에서 ESB는 필수는 아니지만 각 서비스 인터페이스들을 대응하는 이슈가 있기에 ESB가 거의 기본이라고 한다. 또한 영속성 저장소는 모든 서비스에서 공유해서 사용하다는 한계점이 있다.

Fig 04. SOA 아키텍처

헥사고날(Hexagonal) 아키텍처

앨리스테어 콕번의 제안한 아키텍처로 포트와 어댑터(ports and adapters) 아키텍처라고도 한다. 여기서 핵심은 중심인 고수준 비즈니스 로직 처리하는 내부 영역과 인프라와 상호 작용하는 외부영역으로 구성된다. 이렇게 함으로써 내부 핵심 부분이 외부 세부 기술에 독립된 형태로 구성할 수 있다. 즉, 두 개층으로 구분된 구조이다.

Fig 05. 헥사고날 아키텍처

외부영역에는 외부에서 요청을 받는 인바인드 어댑터(inbound adapter)와 외부와 연계되는 아웃바운드 어댑터(outbound adapter)가 있다. 내부 영역에는 비즈니스 로직을 호출위한 인바운드 포트가 있고 외부 영역 호출하는 아웃바운드 포트가 있다. 외부에 있는 인프라라고 해도 애플리케이션 영역에 포함되는 대상이 있고 포함되지 않은 영역도 있다.

Fig 06. Explicit architecture

클린 아키텍처

로버트 C. 마틴이 제안한 아키텍처로 헥사고날 아키텍처를 기반으로 더 확장된 구조를 가진다고 본다. 클린 아키텍처는 두개 층이 아닌 여러 층으로 구성된다.

가장 가운데 비즈니스 로직에 해당하는 엔티티가 있고, 그 다음으로 엔티티를 감싸는 유스케이스가 있다. 유스케이스는 특정 업무 규칙을 정의한다. 그리고 이를 감싸는 세부영역이 있다. 세부 영역에 외부 입출력 인터페이스로 저장소, 웹, 장치, UI 등이 있을 수 있다. 세부사항과 유스케이스는 의존관계 역전으로 유연하게 구성된다.

Fig 07. 클린 아키텍처

가운데 엔티티가 고수준의 핵심 영역으로 외부로부터 분리되게 한다. 의존 관계 방향을 항상 외부에서 내부로 향하게 해야한다. 즉, 저수준 영역이 고수준 영역에 의존해야 한다.

Fig 08. 클린 아키텍처 원뿔

마이크로서비스(Microservice) 아키텍처

넓은 범위에서 CBD와 SOA에 MSA(Micro Serivce Architecture)이다. MSA는 애플리케이션 아키텍처로 애플리케이션 범위내에서 아키텍처를 다룬다. 다르게 말하면, 응집된 서비스 측면에서 SOA와 비슷하지만 MSA의 자율적인 방식인 폴리글랏(polyglot)에서 차이가 발생한다. 폴리글랏은 각 팀에 맞는 개벌 언어와 저장소를 선택하는 것을 말한다. SOA에서는 서비스 분리까지 되었지만 저장소 분리는 되지 않았지만 MSA에서는 각 서비스별 독립적이다. 그리고 MSA에서는 REST API로 개발형 표준을 선택해 느슨하게 연동되도록 하였다. 그렇기에 SOA에서는 서비스간에 통신까지 고려하지만 MSA에서는 각자 협의 통해 결정하게 된다.

Fig 09. MSA 아키텍처

모노리스에 비교해 서비스 별로 애플리케이션이 동작하기 때문에 능동적이고 유연하게 서비스 확장과 변경이 가능하다. 그렇기에 운영에 부담감이 증가한다. 완벽한 폴리글랏이 될 경우 운영까지 각 서비스 별로 달라질 수 있다.

MSA의 대표적인 성공사례인 넷플릿스인 경우는 제한된 폴리글랏으로 한가지 환경으로 적용한다. 이를 넷플릭스 OSS인 오픈소스로 제공하고 스프링 클라우드(Spring Cloud)가 나왔다.

Fig 10. 넷플릭스 OSS

이후에 도커 기반의 쿠버네티스를 사용한 MSA 환경 구축까지 확장되고 있다. 이를 보면서 MSA에 다루는 많은 영역으로 운영환경을 다루고 있었다. 즉, 소프트웨어 아키텍처보다 시스템 아키텍처 관점에서 내용이다. 그리고 각 서비스별 소프트웨어 아키텍처는 팀이 결정한다.

콘웨이 법칙(conway’s law)

콘웨이 법칙은 소프트웨어 구조가 조직의 의사 통신 방식이 그대로 반영된다는 법칙이다. 예를들어, UI팀, 서버팀, DB팀이 분리되어 있다면 소프트웨어 구조가 팀에 맞게 분리된다. 만약 팀이 업무 중심으로 구성된다면 소프트웨어 구조가 기능 중심으로 분리된다는 의미이다.

Fig 11. 콘웨이 법칙

아래 재미 있는 그림이 있다. 조직 관계 외에 개인 간에 관계에 의해서도 영향을 받을 수 있다.

Fig 12. 인간관계

마무리

MSA에 많은 관심을 갖는듯 하다. MSA를 설명위해 모노리스와 많이 비교하는 경우가 많다. 개인적으로 너무 극단적인 경우를 비교하는듯 하다. 어떻게 보면 SOA에 관심있던 기업이 MSA를 관심을 가지는 경우가 많을 것이다. 즉, 모노리스로 할 경우 초기 개발이나 아주 작은 곳에서 개발할 경우가 많다. 물론 앞으로 큰그림을 위해 MSA로 할 수도 있다. 개인적으로 MSA를 공부하면서 초기에 개발 외에 너무 많은 리소스가 필요하고 너무 이른 서비스 분할로 추후 서비스 재구성이 힘들어지는 문제가 생길 것 같다. 어떻게 보면 핵심을 모듈화를 잘 하고 특정 기술에 종속되지 않도록 만든게 아닐까 생각한다. 처음 부터 결론을 내려놓고 만들면 중간에 되돌아가기 힘들어질 수 있다.

개인적인 경험에서도 이런 부분을 많이 반성하고 있다. 대부분은 어느 정도 규모가 있는 업체를 제외하고는 MSA를 적용할 경우는 거의 없다. 물론 작은 업체라고 해도 기술력이 있다면 MSA를 적용할 수 있다. 단순히 프론트 엔드 서버와 백엔드 서버 정도 구분하고 중간에 로드밸런스 정도만 해도 어느정도 규모까지 감당할 수 있다.

어떤 건축 아키텍트 책에서 건물들을 모두 지어놓고 건물 간에 길을 만들지 않았다. 어느 정도 시간이 지난후 사람들이 다닌 흔적을 따라 길을 만들었다고 한다. 물론 경험을 쌓으면 길이 어느정도 보일 수 있다. 그러나 최적의 결과는 아니다. 항상 이런 부분을 고민해야하는 역할이 아키텍트가 아닌가 생각한다.

부족한 글이지만 여러분에게 도움이 되었으면 하네요. ^^ 모두 즐거운 코딩생활 되세요. ospace.

참고

[1] 로버트 C. 마틴 저, 송준이 역, 클린 아키텍처, 인사이트, 2019

[2] 한정헌, 유해식 , 최은정 , 이주영, 도메인 주도 설계로 시작하는 마이크로 서비스 개발, 위키북스, 2021

[3] SOA란 무엇인가요?, https://aws.amazon.com/ko/what-is/service-oriented-architecture/, 2024.03.30