MSA에 대한 대략적인 내용

모놀리식 지옥의 실상

모놀리식 아키텍처의 근본적인 한계는 성공한 어플리케이션 부터 생긴다.

더 큰 서비스, 더 많은 기능, 더 많은 개발자들은 애자일식 개발/배포도 불가능한 상황이 온다.

서비스는 너무 복잡해져서 어떤 개발자도 전체를 ‘완전히’ 이해하는 게 불가능해진다.

단일 코드베이스는 소통/조정에 오버헤드를 유발하고, 코드를 커밋한 후 반영되기까지 매우 긴 지연이 발생한다.

당연히 이런 큰 코드들은 IDE의 실행 속도도 늦추고 개발 속도를 계속 떨어드린다.

확장은 어렵고, 신뢰성이 떨어지며 ( 에러 발생 시 전체 서비스가 다운된다 ) 새로운 기술을 적용하기도 어렵다.

 

마이크로서비스 아키텍처

모놀리식의 단점을 느끼고 있다면 서비스가 성공적이었다는 것을 의미해도 될 거 같다.

만약 서비스가 비대해져서 더 이상 개발하기 어려운 시점이라면 해결책은 MSA 말고는 없다.

MSA란 뭘까.

MSA는 각각의 서비스가 모듈성을 가지고, 또 각각의 DB를 가지도록 구현된 아키텍처를 의미한다.

이 책에서는 MSA를 확장 큐브라는 3차원 확장 모델로 설명한다.

정육면체 큐브에 X축, Y축, Z축 3가지의 축이 있고, 이 축 어느 방향으로든지 큐브가 확장할 수 있다고 해보자.

X축 확장: 다중 인스턴스에 고루 요청 분산

쉽게 생각하면 AWS의 ELB(Elastic Load Balancer)로, 부하를 견디기 힘들면 그만큼 서버를 더 여는 것이다.

Z축 확장: 요청 속성 별 라우팅

X축 확장처럼 서버의 수를 늘리는 것은 같지만 인스턴스 별로 주어진 데이터 하위 집합만 처리하는 게 차이점이다.

위에서 ELB였던 요소는 이제 라우터라는 요소로 바뀐다.

이 요소는 클라이언트의 요청으로부터 헤더든 메시지든 정해진 포맷을 읽고 요청을 각 서버로 분산시킨다.

이 때 분산의 조건에 데이터 하위 집합 이라는 건데, 쉽게 말하면 userId에 따라서 요청을 라우팅하는 것이다.

Y축 확장: 기능에 따라 어플리케이션을 서비스로 분해

X/Z축 확장은 부하를 분산시킬 수는 있지만 어플리케이션의 복잡도를 낮추는 데에는 도움이 되지 않는다.

따라서 Y축 확장, 즉 기능을 분해할 필요가 있고, 이는 모놀리식 어플리케이션을 여러 서비스로 쪼개는 것이다.

그리고 만약 이 세 가지를 모두 사용한다고 하면, 쪼개진 기능(서비스)에서 다시 X/Z 확장을 할 수 있겠다.

 

디자인 패턴

소프트웨어 개발 커뮤니티에 속한 사람들은 자신의 감정을 극복한 상태에서 기술을 논할 방법을 강구해야 합니다. 그것이 바로 패턴 포맷 (pattern format)으로 기술(technology)을 객관적으로 기술(describe)하는 것입니다. 기술을 패턴 포맷으로 나타내면 자연히 그 단점도 드러나게 됩니다. - 51p

패턴은 맥락을 고려하게 만드는 것 외에도, 매우 중요하지만 자주 간과되는 솔루션의 측면도 함께 기술하도록 강제한다는 점에서 효용성이 큽니다. 상용 패턴의 구조는 대략 다음 세 부분으로 구성됩니다.

• 강제조항(forces) : 문제 해결을 위해 반드시 처리해야 할 이슈
• 결과맥락(resulting context) : 패턴 적용 결과 : 해결된, 해결되지 않은, 추가로 발생한 강제조항들에 대하여
• 연관패턴(related pattern) : 다섯 가지 관계 유형

연관 패턴

한 패턴과 다른 패턴의 관계를 기술하는 영역으로 5가지가 있다.

• 선행자 : 이 패턴을 필요하게 만든 패턴으로, 가령 마이크로서비스는 모놀리식을 제외한 모든 패턴의 선행자.
• 후행자 : 이 패턴으로 야기된 이슈를 해결하는 패턴. 가령 마이크로 패턴 적용 시 디스커버리 패턴이 필요.
• 대안 : 이 패턴의 대체제가 될 수 있는 패턴으로 모놀리식의 대체제는 마이크로서비스 패턴
• 일반화 : 문제를 해결하는 일반적인 솔루션에 해당하는 패턴
• 세분화 : 특정 패턴의 구체적인 형태

마이크로서비스 패턴 언어

마이크로서비스 아키텍처 패턴 언어는 전체 어플리케이션을 마이크로서비스로 구성할 때 유용한 패턴 모음집이다.

패턴 언어는 여러 그룹의 패턴으로 구성된다.

 

위 그림은 마이크로서비스 패턴 언어로, 좌측은 모놀리식과 아키텍처가 서로의 대안임을 의미하고.

우측의 그림은 마이크로서비스 패턴을 채택할 때 따라와야 하는 후행자 패턴들을 의미한다.

후행자 패턴은 크게 세 개의 패턴 그룹으로 구성된다.

인프라 패턴, 어플리케이션 인프라, 어플리케이션 패턴이다. ( 패턴은 해결하려는 문제의 종류별로 묶을 수 있다. )

이는 또 다시 여러 가지 패턴으로 구분된다.

 

• 분해 패턴 : 비즈니스 능력에 따라, 또는 DDD 하위 도메인에 따라 서비스 구성하는 방법 두 가지가 존재
• 통신 패턴 : 분산 시스템 내에서 어떻게 통신을 할 것인가?
• 데이터 일관성 패턴 : 서비스마다 DB가 분리되어 있을 때 어떻게 트랜잭션을 관리할 것인가?
• 데이터 쿼리 패턴 : 서비스마다 DB가 분리되어 있을 대 어떻게 데이터를 조인할 것인가?
• 서비스 배포 패턴 : 수십, 수백 개로 분산된 시스템을 어떻게 배포할 것인가?
• 관측성 패턴 : 어플리케이션의 동작을 이해하고 요청 실패, 긴 지연 시간 등을 어떻게 진단하고 조치하는가?
• 서비스 테스트 자동화 패턴 : 취약한 e2e 테스트를 대신할 패턴이 있는가?
• 횡단 관심사 처리 패턴 : DB 자격증명과 같은 전체 서비스에 구현되어야 할 관심사를 어떻게 다뤄야 하는가?
• 보안 패턴 : 사용자 정보를 인증하는 방법 ( ex. JWT )

 

---

 

여기까지는 개략적인 내용이었는데, 앞으로 MSA를 구축하는 데에 있어 필요한 각 패턴들을 공부해볼 예정이다.

현재 읽고 있는 책은 [마이크로서비스 패턴] 이라는 제목의 책이다.