알면 좋은 아키텍처, MSA

글을 시작하기 전에...

Netflix 가 MSA 를 도입했다고 해서 모든 스타트업이 MSA를 채택해야하는것은 아닙니다.
그만큼 MSA 는 진입장벽이 높으며, 상황에 따라 비효율적인 선택이 될수도 있습니다.

다만, MSA 를 알고있다면, 여러분이 현업에서 Monolithic 서비스를 개발하더라도, 나중에 MSA 라는 또하나의 선택지를 고민해보실 수 있습니다.

이 글에서는 여러 블로그를 통해 MSA 를 들어는 보았고, 모놀리식으로도 충분히 서비스를 개발할 수 있지만, 그럼에도 MSA 에 대해 알고싶으신 분들을 위해, MSA 가 나온 배경부터 관련 기술까지 간략하게 소개해드리고자 합니다.

작성자의 귀차니즘으로, 글내에 사진이 존재하지 않는 점 너그러운 마음으로 양해 부탁드립니다

MSA 란

사실 MSA 가 유명해진 이유는, Netflix 의 MSA 도입 성공사례가 우리에게 드라마틱하게 다가오기 떄문이라고 생각합니다. 그렇다면, MSA 를 가장 성공적으로 도입한 기업중 하나인 Netflix 는 MSA 를 뭐라고 했을까요?

loosely coupled service oriented architecture with bounded contexts
Bounded Contexts 간의 느슨한 결합으로 이루어진 SOA(서비스 지향 아키텍처)

제가 이전에 작성한 글인 골라밥이 MSA를 채택한 이유에서 발췌해온, MSA 에 대한 Netflix 에서의 정의인데요.
쉽게 풀어보자면

• Bounded context: 관심사에 따라 비즈니스로직을 분리해놓은 것 또는 그 경계
• Loosely Coupled: 상호간의 강력한 의존관계 없이, API같은 느슨한 규약으로만 연결되어있는
• SOA: 여러 서비스의 상호작용으로 이루어진 소프트웨어에 대한 아키텍처

가 됩니다. 정리하자면 MSA는

관심사에 따라 분리된 서비스간의 API 같은 느슨한 규약으로만 연결되어 상호작용하는 아키텍처

라고 볼 수 있습니다.

그래서 왜 나왔는데?

아마 이글을 보고계신분들은 이미, Monolithic 으로 서비스를 만들어보신분들 일겁니다.
그리고, Monolithic 서비스만으로 이미 충분히 서비스를 운영가능하지만, MSA 가 최근에 부각되어서 호기심에 오신분들일텐데요.
따라서 하나의 어플리케이션에서 여러 기능을 추가하다보니, 어플리케이션이 비대해지고, 서비스가 복잡해지고, IDE 인덱싱 시간이 10분이 넘어간다는 모놀리식의 단점이 딱히 와닿으시진 않을거라 생각합니다. (제가 그랬거든요)

그런데, Naver 나 Google도 그럴까요?

우선 네이버의 메인 페이지부터 살펴봅시다. 어떤 기능들이 있을까요?
맨 위의 검색창부터, 메일, 카페, 블로그, 지식인, 쇼핑... 다양한 언론사의 뉴스를 보여주는 뉴스스텐드부터 네이버에 있는 여러 글들을 주제별로 분류해놓은 오늘 읽을만한 글까지

굉장히 많은 기능들을 제공하고있습니다. 메인페이지 단 한 페이지에서요.
그렇다면, 이 모든 기능을 한 어플리케이션에서 작성한다면 어떻게될까요?

• 우선 IDE 가 터질겁니다. 아마 모든 개발자들에게 슈퍼컴퓨터를 제공해주어야겠네요
• 이런! 카페부서에서 보낸 PR과 우리 뉴스부서에서 보낸PR간에 Conflict가 발생했네요!
  러시아 지부에있는 카페부서와 미팅을 위해서 서둘러 ZOOM을 깔아봅시다.
• 잠시만요... 서비스 도중 오류가 발생했어요! 이제 사용자는 뉴스도 못보고, 로그인도 못하고, 검색도 못하겠네요. 지금 네이버 주가 얼마나 떨어졌죠?

보셧듯, Naver 나 Google 같은 대규모서비스를 하나의 어플리케이션에서 작성하면, 수많은 문제가 발생합니다. MSA는 이를 해결하기위해, 뉴스정보는 뉴스API서버에서, 쇼핑정보는 쇼핑API 서버에서 가져올 수 있게 해줍니다.
이제 개발자분들은 맥북으로도 개발을 하실 수 있겠네요 :)

SOA는 나락, MSA는 극락?

DDD 를 배워보셧다면 BoundedContext를 들어보셧을것이며, CleanArchitecture 에 관심을 가져보셧다면 Loosely Coupled 에 대해 어느정도 유추가 가능하실겁니다.
하지만, SOA 는 뭔가 생소하지 않으신가요?
MSA가 나온 이유는 Monolithic의 단점을 극복하기 위해서라면서요.
그런 MSA이외에도 서비스를 나누는 아키텍처가 있었다면, MSA 만큼 유명하고 위대했어야 하지 않았을까요?

MSA의 다른점, 폴리글랏 퍼시스턴스

SOA 는 기본적으로, 하나의 Database 서버를 여러 서비스가 동시에 사용하는 구조인데요.
따라서, SOA 는 ESB라는 MSA 의 HTTP API 같은 endpoint 외에도 Database 라는 endpoint를 공유하고있었습니다.
DB서버 하나가 죽으면 모든 서비스가 정상적으로 실핼될 수 없고, DB 트랜젝션관리를 잘못하면 일관성이 깨질 뿐더러, 기존에 존재하는 테이블을 서비스별로 조금씩 다르게 읽어들여 사용해야했지요.
하지만, MSA 는 폴리글랏 퍼시스턴스 방식을 사용해, 하나의 서비스당 하나의 DB를 가지도록 합니다.
이제 서비스들은 자신이 필요한 정보만 가지고 있을 수 있고, 카페 DB가 부하됬다고해서 뉴스DB까지 부하되는일은 발생하지 않을겁니다.
MySQL 이 익숙한 쇼핑팀은 MySQL을, Aurora 가 익숙한 뉴스팀은 Aurora 를 사용하면 되겠네요.
이러한 기술 채택의 유연성은 DB뿐 아니라 MSA 전반에 걸쳐서 나타납니다

MSA가 성공한 이유, 클라우드 서비스

사실 SOA가 막 나왔을때는, AWS나 GoogleCloudPlatform 같은 클라우드 서비스가 많지 않았습니다.
모든 회사들은 전산실에 IDC를 가지고있고, 서버 확장을 위해서는 남는 서버장비부터 확인하거나 구매해야했죠.
이런 상황에서 서비스에따라 인스턴스를 나누어 서버장비를 점토자르듯이 잘라 배포하는건 불가능했습니다.

근데 지금은 어떤가요? 단순한 토이프로젝트를 배포할거라면 지금당장 AWS에 가서 EC2 micro 인스턴스를 만들면 됩니다. 만들고 배포하기까지 길게잡아도 1시간도 채 안걸리며, 심지어 재부팅이나 종료도, 버튼 클릭 한번이면 됩니다.

서버를 추가하고싶으시다고요? 인스턴스를 하나 더 만드세요!

이렇듯, 클라우드 서비스의 발전에 따라, 서버를 유연하게 확장/추가하여 사용할 수 있게되었고, MSA 의 등장시기가 미묘하게 맞아떨어지자, SOA 와는 달리, MSA 가 대중화 될 수 있었습니다.

MSA 장점, 3가지로 요약한다.

사실 다들 어느정도 알고 계시죠?
MSA 는 Monolithic 의 단점을 보완하기 위해 사용하는데요.
어플리케이션이 비대해지고, 서비스가 복잡해지고, 서비스를 유연하게 다룰 수 없다(부분배포, 서버 스케일링)는것이 모놀리식의 단점이었죠?
그렇다면, MSA의 장점은 이러한 문제들을 해결한다는 것에 있겠네요. 더 자세히 알아볼까요?

협업능력 100배상승

제가 MSA 를 야매로 사용해보면서 가장 크게 공감했던 장점입니다.
MSA에서는 모든 서비스들이 API 라는 느슨한 endpoing 를 통해서만 연결되기때문에,
자신이 개발하는 비즈니스 로직에만 집중할 수 있습니다.
굳이 자신이 코드를 변경한다고해서, 굳이 카페API개발하는데 뉴스API코드와의 충돌을 걱정할 필요 없이, API 만 제대로 지켰는지, 자신의 서비스 내의 코드와 충돌이 안나는지만 걱정하면됩니다.
또한, 이후 말할 기술선택의 유연성 덕분에 Node 개발자와 Spring 개발자간의 협업또한 가능하죠.

기술 선택의 유연성

여러분, 회사에서 다같이 치킨을 시켜먹는다고 해봅시다. 근데 옆의 동료분은 양념치킨을 원하고, 옆부서 Tech리더님은 갈비레오를 좋아하고 저는 후라이드를 먹고싶네요.
1가지 메뉴의 치킨만 시킬 수 있다면, 최소 2명은 어느정도 현실에 타협해야하는 상황이옵니다.
그런데 베라 파인트마냥 3가지맛을 다 시킬 수 있다면요?
누누히 말했듯 MSA는 모든 서비스가 API로만 연결되기때문에, 각 서비스에서 NodeJS 를 쓰던, Spring을 쓰던, Armeria를 쓰던 각 서비스별로 자유롭게 기술을 선택할 수 있습니다.

언어나 프레임워크만 그럴까요? 아뇨. API 이외의 모든 것들이 그래요.

빠르고 유연한 변경

Netflix 처럼 MSA 도입으로 유명한 글로벌기업, 아마존에는 1.5초라는 특별한 시간이있습니다.
바로 아마존이 서비스를 변경하고 배포하는 주기인데요...
MSA 에서는 각 서비스가 변경이 될 때, 전체 서비스의 변경 없이, 해당 서비스만 재배포하면 되기 떄문에, 변경이 미치는 영향의 범위가 획기적으로 줄어들게됩니다.

같은 이유로, 서비스중 오류가 발생하더라도, 오류가 발생하는 범위가 줄어들게되죠.

MSA, 장점만있으면 이미 썻다.

이렇게도 사랑스러운 MSA도, 단점은 있습니다.
아니, 너무나도 많습니다. 오죽하면 여러분이 다니는 회사에서 MSA내팽겨치고 모놀리식을 사용할까요.

서비스간 트랜젝션 관리의 어려움

MSA에서는 모든 기능이, 여러 서비스의 상호작용으로 이루어집니다.
네. 상호작용이요. 즉, 한 기능을 수행하려면 여러 서비스에서 각각의 비즈니스로-직을 수행해야 합니다.
보통 이러한 비즈니스 로직에는 데이터를 수정시키는 Command 가 있을텐데요. 이렇게 데이터를 수정시키는 작업에 대한 단위를 트랜젝션이라고 합니다. (DB에서 수정되면 DB트랜젝션, 서비스에서 수정되면 서비스 트랜젝션이겠죠.)
그런데, 만약 여러분이 블로그에 글을 써본다고 칩시다.

• 우선 블로그에 있는 글들은 BlogAPI 에 저장될겁니다.
• 이미지는 그대로 저장하기 비효율적이기때문에 ResourceServer 에 저장되고, URI 를 반환하겠죠.

즉, 두 서비스에서 각각의 트랜젝션이 생성되고, commit/rollback 되게 되는데요.
이때, ResourceServer 에서 트랜젝션 실행도중 오류가 난다면, 즉 이미지 저장에 실패하면 어떻게 될까요?
ResourceServer 의 트랜젝션은 rollback 되겠지만, BlogAPI 의 트랜젝션은 이미 commit 되어 지금 보시고계신 이 글처럼 이미지없는 포스트가 완성되겠지요.

이처럼 여러 서비스에 분산되어있는 트랜잭션들을 관리하기 어렵다는 단점이 있습니다.
(추후 소개할 Saga 패턴을 통해 트랜잭션을 연결하지 않는다면 말이죠.)

장애전파

자 여러분, Resource Server 가 다운되었습니다.
무슨일인고 하니 ResourceServer 서버 컴퓨터 안에 나방이 들어갔었네요
ResourceServer 가 복구될 때 까지, 블로그에 있는 포스트들을 볼 수 없어질지도 모릅니다.
이렇듯,

• 하나의 서비스에서 오류가 발생할 경우,
• 이 오류가 다른 서비스들에게 오류를 미치고,
• 다른서비스들의 오류가 또다른 서비스들에게 오류를 발생키시게 하면서,

장애가 계속 전파되는것을 장애 전파라고합니다.
(보통 Circuit Breaker 를 통해 장애를 중간에 끊어주는식으로 방지합니다)

모니터링/로깅난이도 떡상

모놀리식 서비스에서 로그를 확인하려면, 그냥 파일 하나만 보면 됬습니다. 파일 하나에, 카페API 요청내역과 포스트API 요청내역 모두 확인할 수 있었죠.
그런데 MSA 에서는 어떨까요?
각 서비스가 완전히 독립된 인스턴스를 사용하고있습니다.
카페API 는 Slf4j 2.14.1버전의 로거를 사용하지만 포스트 API 는 winston을 사용하죠.
파일 포맷이 다를 뿐만 아니라, 파일이 저장된 위치조차 다릅니다.
오후 11시부터 오후 12시까지 일어난 요청을 파악하기위해서는 두 파일을 전부 살펴봐야하죠
(앗, 근데 포스트API 는 GMT+9인데 카페API 는 GMT+10이었네요 ㅋ)

보통은 하나의 통합 로깅/모니터링 서버를 두는방식으로 해결합니다.

서비스 전체구조 파악 불가

사진 나올줄 몰랐죠?
위의 난해한 그림은 Netflix의 MSA 구조인데요..
글쎼요 저걸 이해할 수 있는 사람이 있을까요?
보셧듯이 MSA 에서는 여러 서비스들이 유기적으로 상호작용하기떄문에, 서비스의 전체구조를 파악하기 어렵습니다.

그냥 구현비용이 높아요

네.. 말 그대로 구현비용이 높습니다.
모놀리식 서버와는 달리, 서버가 여러개인데다가, 컨테이너리제이션 없이 이 많은 서버를 관리하긴 어렵죠.
서버가 여러개라는 말은 그만큼, 부가적인 비용이 많이 발생한다는 뜻이고,

위의 단점을 극복하기위해, Axon이나, MQ, SpringConfig 같은 기술들을 도입하는것도 하나의 비용이되죠.
이렇듯, 모놀리식에 비해 MSA 는 구현비용이 압도적으로 높습니다. 진짜 압도적으로요.

단점? 극복하면 되는데?

MSA 가 이렇게 단점투성이라면, Netflix나 Amazon 이 MSA 를 쓸 이유가 없겠죠.
여러 기업과 기관의 고된 노력을 통해, 전술한 단점을 해결해나갈 수 있는 기술들이 개발되었는데요
분량조절의 문제로 인해 이러한 기술에 대해서는 간단하게만 설명하도록 하겠습니다.

트랜젝션이 여러개? 하나로 합쳐!

분량조절을 위해 복잡한 ACID, ACD, 일관성문제는 PASS 하였습니다.

각 서비스에 트랜젝션이 분산되어있다면, 이를 하나로 합쳐보는건 어떨까요?
ResourceServer 가 rollback 될 때, BlogAPI도 rollback 시키는거죠.
이미 commit 된 트랜젝션을 어떻게 rollback 시키냐고요?

Saga패턴에서는 보상트랜젝션이라는 개념을 통해서, commit 된 트렌잭션을 rollback 과 유사한 작업을 수행시킬 수 있습니다.
어떤 서비스에서 트랜젝션 rollback 이 일어날 시, 이미 커밋된 이전 서비스의 트랜젝션에 대한, 보상 트랜젝션을 실행시키고, 이를 단계적으로 수행하여, 여러 서비스의 분산된 트랜젝션을 마치 하나의 트랜젝션처럼 사용할 수 있게 해주죠.

이러한 Sage 패턴은 Chreography 방식과 Orchestration 방식으로 나뉘는데요. 이부분은 해당 포스트나 여타 포스트를 통해 학습하실 수 있습니다!

Saga vs EventSourcing

EventSourcing 은 모든 변경을 Event 로서 저장하고, 현재 데이터를 알고싶을때는, 저장한 Event 를 재생하여 계산하는 방식을 의미합니다.
BlogAPI 의 변경사항을 따로 EventStoreServer에 저장하고, ResourceServer 의 변경사항을 똑같은 EventStoreServer 에 저장했다가, 오류발생시 오류에 관련되지않은 버전까지, 이벤트를 삭제시키는거죠.
모든 변경로그를 저장하면 성능문제가 발생하지 않냐고요? Git 같은 VersionControllSystem 이 이 방식을 쓰고 있다는것을 아시나요? 물론 성능문제가 안발생하는건 아닙니다..
성능문제가 걱정되신다면 EventSourcing 의 SNAPSHOT 기술을 찾아보시면 좋을거에요!

이방식, 뭔가 Saga와 대척점에 있는 것 같지 않나요?
Saga 는 Event 를 저장하진 않지만, 각 서비스에서 트랜젝션에 대한 rollback대용의 보상트랜젝션을 제공하고, EventSourcing 은 아예 모든 Event를 StoreServer에 저장해버리죠

서비스의 규모나, 필요 성능에 따라 적절한 기술을 도입하면 좋을 것 같습니다!

나머지 기술들

사실 Saga 이외에는 대부분 인터넷 서칭으로 쉽게 찾을 수 있더라구요
이외에도, 장애 전파를 막기위한 CicuitBreaker 패턴이나 Fallback, 로그를 수집하기위한 SpringCloudLoggingServer, 여러 아웃바운드 포트(gRPC, HTTP...)를 한번에 관리하고, 더욱 낮은 비용으로 MicroService 를 만들도록 도와주는 Armeria 프레임워크까지...
MSA 의 단점을 극복하기위한 기술들은 굉장히 많습니다.

분량조절실패해서 빨리 끝낼게요

이렇듯, MSA 는 장점만큼이나 단점이 많은 아키텍처입니다.
국내에서 개발문화적으로 굉장히 유명한 우아한 형제들에서도

MSA의 도입은 선택의 문제가 아니라 생존의 문제였다.

라고 할정도이죠.
하지만, 전술했듯, 쓸일이 없다고 해서 아예 배우지 않는것보단, 우선 배워놓는 편이
나중에 정말로 MSA가 필요한 순간, MSA 도입에 대해서 고민이라고 할 수 있지 않을까요?

긴 글 읽어주셔서 감사합니다! 😀