MSA 와 헥사고날 아키텍처

개요

아키텍처나 객체지향 프로그래밍을 공부하면서 가장 핵심적으로 느꼈던 말들이 있다.

 

"소프트웨어(기술)는 누군가의 필요로 인해서 시작된다."

"소프트웨어(기술)는 사용자에게 새로운 가치를 제공해야 한다."

"소프트웨어(기술)는 시간이 지남에 따라 변화하는 요구사항에 맞춰 적응해야 한다. "

 

모든 기술이나 산업, 아이템은 대중의 니즈에 의해서 개발되고, 만들어지고 그 기술은 이용자에게 새로운 가치를 제공하므로써 존재 가치를 증명한다. 그리고 시간이 지나면서 이용자가 원하는 방향성과 모습이 달라질 땐 그 변화에 맞춰 기술도 변화해야 살아남을 수 있고, 시장에서 지속 가능해지고, 타 기술과 견주어도 경쟁력이 생긴다.

 

변화에 적응하는 소프트웨어의 특징은 3가지 특성은 필요로 한다.

유연성, 확장성, 유지보수성

변화에 유연하게 대처할 줄 알아야하고, 높은 요구사항에 맞춰 확장할 수 있어야하고, 유지 보수가 잘 되어야 적은 리소스로도 빠르게 변화할 수 있다.

이렇게 유연성, 확장성, 유지보수성이 뛰어나려면 바로 핵심 가치가 있는데, 결합도가 낮아야한다는 것이다.

 

결합도가 높다는 건, 객체나 모듈, 계층 등이 서로 의존성이 높다는 것이고, 의존성이 높으면 변경점에 있어서, 변경사항을 전파해야하는 부분들이 많아진다는 것이다. 이렇게 특정한 변경점에 있어, 많은 부분을 수정해야하는 것은 유지 보수성이 낮다는 것이고, 객체 또는 모듈간이 강하게 유착되어 있기에 유연성도 낮고, 확장하기에도 어렵다.

 

그래서 내가 생각하기에 객체지향 프로그래밍의 핵심은 바로 결합도를 낮춘다는 점에 있고, 결합도를 낮추기위해 많은 기술들이 나왔다고 생각한다.

많은 책에서도 느슨한 결합과 높은 응집도를 많이 얘기한다. 연관성이 높은 또는 같은 책임이 있는 요소들은 하나로 합쳐 응집도를 높이고, 다른 책임과 역할이 있는 객체들과는 의존도를 낮춰 느슨하게 결합해야 한다.

 

모놀리식 아키텍처 - Monolithic Architecture 

MSA 가 나오기 전엔 많은 IT 업계에선 모놀리식으로 시스템 아키텍처를 구축했다. 모놀리식 아키텍처란 MSA 가 나타나기 전까진 지칭하는 용어 조차 존재하지 않았다. 왜냐하면 따로 구분지어서 부를 필요가 없기 때문이다. 모두 같은 방식으로 개발 했기 때문이다.

 

모놀리식 아키텍처란 기본적으로 모든 종류의 서비스가 하나의 어플리케이션으로 구성되어 있는 아키텍처를 의미한다.

이런 시스템은 다음과 같은 특징을 갖는다.

1. 하나의 주요 프로세스로 구성
2. 모든 서비스가 하나의 DB endPoint를 사용
3. 단 한줄의 코드 수정이 되더라도, 모든 어플리케이션의 재배포가 필요
4. 싱글 혹은 멀티 모듈로 구성할 순 있지만 CI 의 단위가 달라질 뿐, CD의 범위는 여전히 전체

모놀리스 아키텍처가 과거의 일반적이었던 이유는 첫 번째로 개발이 쉽다는 점이다. 개발하고 빌드하고 나온 결과물을 서버에서 실행만 시키면 됐기 때문이다. 두 번째로는 고려할 사항이 적다는 점이다. 세 번째로는 과거엔 IDC 에 배포하여 서비스를 제공하는 게 일반적이었고, 비싼 서버 리소스를 최적화 해서 사용이 가능했기 때문이다.

 

모놀리식 아키텍처의 장점으로는 개발과 배포가 쉽고 간다하는 점이고, 어디서 패키징해도 상관없고, 어떻게든 배포만 하면 된다는 점, 공통 모듈 등을 활용하기 매우 쉽다는 점, 쉽다는 특징 덕분에 빠르게 서비스를 개발할 수 있다는 점 등이 있다.

단점으로는, 수평 확장이 너무 어렵다. (단일 DB에 대한 의존성이 너무 크다.) 하나의 어플리케이션 환경이 보편화되어 시스템이 매우 커진다면 커뮤니케이션 코스트가 매우 높아진다. 복잡성이 증가하여 수정에 대한 부담감이 증가한다. 대규모 어플리케이션 환경에서는 단순한 수정 사항일지라도, 배포까지 시간이 오래 걸릴 수 있다. 장애 시, 전체 어플리케이션에 영향을 크게 받게 된다.

이러한 단점은 의존성이 높은, 즉 결합도가 높기에 발생하는 문제이다.

이용자의 요구사항에 맞춰, 빠르게 확장해야하고, 유연한 대처를 해야하고, 적은 수정으로 빠르게 배포해야 하는데 이 점이 힘들었다는 뜻이다.

 

MSA - Micro Service Architecture

AWS 시작으로 클라우드 컴퓨팅 서비스를 제공하기 시작했고, 도커와 쿠버네티스처럼 가상컨테이너, 오케스트레이션 기술들이 등장 하면서 MSA 로 변환할 수 있는 환경이 제공됐다.

모놀리식 관경에서는 비교적 필요성이 크지 않았던 것들 예를 들어, CI/CD 파이프 라인, 자동화, API GateWay 기술들이 시간이 지나면서 기술의 발전으로 허들이 낮아지게 됐고, MSA 로의 전환을 가능하게 해주었다.

 

MSA 란 Micro Service Architecture 말한다. MSA 를 정확히 지칭하는 개념은 없지만, 핵심요소들은 있다. 개발단위를 서비스로 인지하고 서비스와 서비스를 서로 분리/분해하여 독립적으로 개발, 배포한다. 이렇게 함으로써 서비스 간 결합도를 낮추게 된다. 서비스 간은 규격화된 프로토콜(인터페이스)를 사용하여 통신하고 내부 구현 사항을 모두 추상화한다.

각각의 서비스는 독립된 각각의 데이터베이스를 갖는다.

 

서비스를 한 데 뭉쳐 하나의 어플리케이션으로 작동했던 모놀리식 어플리케이션에 비해 서비스를 분리/분해하여 각각의 어플리케이션으로 배포하는 것이 MSA 의 핵심이다. 

이렇게 하면 요구사항에 맞게 빠르게 수정하거나 특정 서비스를 추가하여 빠른 배포가 가능해진다. 이것은 높은 Business Capabilities 를 갖게 된다.

Business Capability 란 조직이 비즈니스에 대해 얼마나 빠르고 유연하게 변화에 대응할 수 있는지에 대한 능력으로, 비즈니스 요구사항에 대한 빠른 대처 능력으로 말할 수 있다. 사용자가 특정 서비스에서 어떤 부분이 아쉬워 어떤 부분을 추가하길 원할 때 그 요구사항을 빠르게 받아드리고 서비스를 수정 및 보완할 수 있는 능력을 말한다. 빠른 대처 능력은 동종 업계에서 경쟁력을 갖출 수 있게 한다.

 

무거운 어플리케이션일 땐 배포하는 데에 많은 시간과 리소스를 투자해야했지만, 서비스가 분리되어 어플리케이션이 가벼워짐에 따라 잦은 배포가 가능해지고, 이는 요구사항을 빠르게 반영할 수 있다는 걸 말한다. 그리고 서비스가 분리 됐으므로 특정 서비스에 트래픽이 몰리거나,  문제가 있을 때 특정 서비스 부분만 수평적 확장을 하여, 불필요한 리소스 낭비를 줄일 수 있게 됐다. 이는 높은 확장성을 말한다. 마지막으로 서비스가 한 군데에 뭉쳐져 있지 않고, 분리 됐기 때문에 변경 사항 전파 범위가 줄어들어 유지 보수가 훨씬 수월해진다.

 

MSA 가 만능처럼 보이지만, 비례해서 주의해야하는 사항도 많다. 첫 번째로 서비스가 분리 되어 있기 때문에 필연적으로 분산시스템 아키텍처를 갖게 된다. 모놀리식에선 함수 호출로 쉽게 얻은 데이터를 이젠 네트워크 통신을 해야한다.(dump 파이프, 메시지 큐, 여러 프로토콜 수용 등등) 네트워크 통신은 항상 안정성과 신뢰성을 보장하는 것이 아니기 때문에 이에대한 보완책이 준비 되어 있어야 한다.(모니터링, 감지, 자동복구 등등)

또한 서비스가 각각의 데이터 베이스를 갖기 때문에 데이터의 정합성에 문제가 생긴다. 또 모놀리식에선 @Transactional 어노테이션으로 해결되던 문제들이 MSA 에선 보상 트랜잭션 같은 다른 과정을 반드시 필요로 한다.

이처럼 MSA 에서 개발은 매우 어렵고, 고려할 사항도 많으면서, 많은 지식을 요구한다.

 

하지만 MSA로 인한 고통과 힘듦 보다 MSA 로 인한 이점이 더 크기에 많은 IT 서비스 회사에서 MSA 로 전환을 시도하고 있다.

 

헥사고날 아키텍처 - Hexagonal Architecture

MSA 시스템 아키텍처에서 핵심은 서비스를 분리/분해 하여 결합도를 느슨하게 하고, 유연성과 확장성으로 Business Capability 를 높이고, 잦은 배포 등이 특징이라고 말했다.

 

유연성과 확장성, 낮은 결합도의 MSA 특성은 각 Micro Service 안에서도 필요하게 된다. 그래서 확장성이 뛰어나고 유지보수가 쉬운 소프트웨어 아키텍처를 요구하게 된다. 이때 많이 쓰이는 소프트웨어 아키텍처로 Hexagonal Architecture (헥사고날 아키텍처)가 있다.

 

기존에 널리 쓰이는 아키텍처로는 Layered Architecture가 있는데, 여러개의 계층으로 나누어 각 계층에서 하는 일을 한정시켜 계층별로 담당 업무에 맞게 개발하는 것이다. 각 계층 내에서는 코드 수정과 유지보수 등이 비교적 쉽고, 계층 간 접근이 자유롭다.

 

 

Hexagonal Architecture (헥사고날 아키텍처)
각 계층에서 하던 일들을 "내부와 외부" 라는 개념으로 나누어 각각에 맞는 별도의 인터페이스를 정의한다.
"내부"의 로직은 오직 "외부" 인터페이스를 통해서만 접근이 가능하다. 외부의 인터페이스를 포트,  포트를 사용하는 구현체를 어댑터라고 불러 포트 & 어댑터 아키텍처라고 부르기도 한다. 즉, 외부 서비스와의 상호 작용(어댑터) 는 비즈니스 로직과의 작업을 정의한 인터페이스(포트) 랑만 서로 통신한다.
그리고 모든 비즈니스 로직은, 오직 외부에서 내부 방향으로만 호출이 가능하고, 경계 간 이동이 제한된다.

• 인바운드 어댑터 → 인바운드 포트 → 비즈니스 로직
• 비즈니스 로직 → 아웃바운드 포트 → 아웃바운드 어댑터

아래 그림은 외부 클라이언트 서버에서 HTTP 요청을 받아 DB에 CRUD 하는 과정을 헥사고날 아키텍처의 흐름으로 도식화한 다이어그램이다.

큰 네모의 구현체들은 작은 네모의 인터페이스인 포트를 이용하여 통신할 수 있고, 포트를 구현한 구현체들은 인터페이스에 정의된 내용을 구현한다. 

 

물론 기능별로 각각의 어댑터와 포트로 분리하였기에 클래스 파일도 많아지고, 코드의 양이 많아질 수 있다고 생각이 들 수 있지만,  이런 헥사고날 아키텍처는 어댑터를 통해 외부 서비스의 의존성을 분리하여 언제든 쉽게 교체하여 유연한 확장성 있는 대처가 가능하다.

또, 포트를 통해서 내부 비즈니스 로직과 인터페이스를 분리하여 내부 로직의 구현은 인터페이스와 무관하게 개발 가능하도록 한다. 그리고 이러한  높은 유연성과 확장성은 MSA 의 목적성과 부합하게 된다.