[강연 및 세미나] : 실전 MSA 경험 공유

실전 MSA 경험 공유

참석일 : 22.05.26

유형 : 실시간 온라인 강연

주제 : 실전 MSA 경험 공유

발표자 : 주길재 님.

📝 ← 링크 참고

---

실전 MSA 경험 공유

최근에 MSA에 대한 소식을 많이 접하게 되고, 주변에 학교 동기 중에서도 MSA를 이용해 프로젝트를 진행하거나 진행 할 예정을 가지고 있는 사람들이 늘어나면서 자연스럽게 MSA에 대한 관심이 높아지고 있었다.

 

공부하면서 기술을 익히기 제일 좋은 방법은 프로젝트를 만들어 보면서 직접 활용해 보는 것 인데 MSA에 대한 개념이 부족하기도 하고 아직은 모놀리틱 아키텍쳐를 구현하는 실력도 높지 않아서 망설이고 생각하고 있다가 운 좋게(?) OKKY 세미나에서 MSA에 대한 주제로 세미나를 열어 참석하게 되었다.

 

세미나는 MSA 개념과 장, 단점, 여러 패턴과 사례에 대해 설명을 진행했는데 솔직히 내용이 상당히 어려웠다. 특히 패턴 과정은 일부를 제외한 대부분을 이해하기 힘들었고 중간에 채팅으로도 다른 분들이 내용이 어렵다는 말을 하기도 했다.

하지만, 매우 실무 중심적인 내용 설명인 점과 여러 패턴과 내용을 한 번 눈에 익혀 두었다는 것 만으로도 얻어가는 게 많다고 생각해서 불만은 없다. 어차피 세미나의 모든 내용을 다 내가 흡수할 수는 없다. 여기서 최소한 몇 가지 키워드만 얻어가도 나중에 떠올릴 수 있다면 나는 만족한다.

 

여튼, 내용이 내 기준에서 상당히 어려웠기 때문에 사실 세미나 내용을 어느 정도 생략하면서 복습을 진행했다. 아, 복습 내용은 참고만 하자.. 내가 잘 못 알아 들은 것이 있을 수도 있기 때문에 이 글을 통해 추가 검색 키워드 정도만 얻어가면 좋을 것 같다.

 

처음에는 MSA 개념부터 설명해 주셨다. MSA에 대해 막연히 서비스를 나누어 독립적인 모듈로 장애가 발생하거나 추가, 삭제 등이 필요할 때 조립하는 형식으로 서비스를 키우고 줄이고 할 수 있는 장점을 가진 아키텍처로 알고 있었는데 사실 강연 내용 중 내가 알아 들은 부분만 해도 이것보다 훨씬 복잡하고 고려해야 할 것이 많은 구조라는 것을 알게 되었다.

 

MSA는 Monolithic architecture(모놀리식 아키텍쳐, 모놀리식이라고 부르겠다.) 모놀리식과 비교를 많이 한다. 이 부분도 간단히 정의해 주셨는데 모놀리식은 UI가 있고 비즈니스 로직과 데이터 인터페이스를 연결하는 것이고 MSA는 서비스를 도메인이나 기능 기준으로 쪼개고 데이터 베이스를 분리해서 만들어 주는 것이다. 때문에 MSA가 비즈니스에 대해 민접하게 대응할 수 있지만 끝내 복잡해 질 수 있다는 점도 생각해야 한다고 했다.

 

그렇다면 왜 MSA를 사용해야 하나? MSA는 강력한 모듈화가 되어 있다.(의존성, 독립성) 하지만 모놀리식은 전체적으로 스케일이 조정되는데 MSA는 트래픽을 많이 받는 서비스만 트래픽 조정이 일어나서 의미가 있다고 했다. 이때, 결제 모듈을 예시로 들어주셨다. 압축해서 설명하자면 결제 모듈이 들어가 있는데 이것을 다른 것으로 바꿔야 하는 상황이라 가정하면 모놀리식인 경우 전체적으로 코드 수정이 이루어져야 하는데 MSA 경우 모듈만 바꿔주는 간편함이 있다. 이처럼 모듈화가 매우 잘 되어 있기 때문에 좋은 점이 있다. 또, 빠른 출시와 점진적 프로젝트 성장을 기대할 수 있고 독립적 모듈을 개발하기 때문에 새로운 시도에도 리스크가 생길 때 모놀리식에 비해 상대적으로 작다는 것도 MSA를 선택하는 이유가 될 수 있다고 했다. 그리고 최근에 개인적으로 모놀리식으로 프로젝트를 만들고 있었는데 MSA에 장점 중 진짜 장점이다..라고 느끼는 부분이 있었는데 지속적인 배포가 가능하고 분리가 되어 있어서 하나의 서비스의 버전이 달라질 수 있다는 점이 MSA의 장점 중 크게 느껴졌다. 모놀리식은 전체적으로 버전을 맞춰야 해서 가끔 답답할 때가 있다.(이게 터져서 막으면 저게 터지고..나나 동기들 하는거 보면 가끔 있다..)

 

앞 부분에서 마지막으로는 어떻게 해야 좋은 서비스를 만들 수 있을까에 대한 해답도 제시했다. 이 또한 간단히 압축하자면 MSA는 확장성 요구에 유리하며, 복잡성이 감소하고 한 쪽에서 하나의 기능을 관리 및 분리하다 보니 하나의 서비스는 복잡하지 않은 장점이 있고 데브 옵스 접근 방식을 지원한다. 즉, 비즈니스 민첩성이 좋아야 한다.

 

이 떄쯤이면 떠올려지는 고민이 있다. 모놀리식과 MSA 중 어떤 아키텍처가 좋나? 나는 요즘 하도 MSA, MSA 사람들이 노래를 불러서 모놀리식 보다는 MSA..라는 인식이 뇌에 박히고 있는 중인 것 같은데 강사님의 말을 듣고 다시 한 번 생각해 보게 되었다. 강사님이 말씀하시길 무조건 MSA가 좋다. 이건 위험하다고 한다. 어떤 상황에서 무엇을 만드는지가 중요한데 잘 따져봐야 한다고 했다.

 

모놀리식 경우에는 한 팀이 오랜 기간 하나의 프로젝트를 진행하거나, 애플리케이션이 크지 않거나, 팀이 작거나, 팀의 수준이 평준화 되어 있을 때 유리하다고 했다. 즉, 프로젝트 목적이 쉽고 빠르게 개발 가능하고 비용 절약이 우선인 경우다.

 

MSA는 간단히 비즈니스적으로 다양한 틈새 시장으로 확대해야 할 때 유리하다고 했다. 즉, 단기 보다는 장기 이익을 우선해야 한다고 했다.

 

추가적으로 모놀리식과 MSA를 사용하는 기업에 대해서도 간단하게 설명해 주셨다.

 

모놀리식을 사용하는 기업은 페이스북과 Segment라는 곳을 예로 들었다. 모놀리식을 사용하는 이유는 데이터 유출 위험이 높은 서비스라서 안전을 우선시하기 때문에 MSA를 사용하면 잠재적 위험이 존재해서, 민감한 정보를 처리해야 하고 안정성과 신뢰성이 최우선이면서 통신 및 관리 오버헤드가 너무 크고 성능 저하 문제가 있었기 떄문에..라고 한다.

MSA는 Uber랑 ebay가 있다고 했는데 MSA를 사용하는 이유는 초기 간단한 기능만 제공하다 비즈니스가 확장되면서 트래픽이 증가하게 되고 결국 모놀리식에서 MSA로 전환해서 사용하게 되었다고 한다. MSA 전환 후 새로운 기능과 많은 변경 사항을 신속하게 처리할 수 있게 되었다고 하니 각각 장,단점을 잘 파악하고 적용하는 게 매우 중요하다고 느껴졌다.

 

결론적으로는 모놀리식과 MSA 둘 다 나쁘지 않고 상황에 맞게 선택하는 게 중요하며 요약을 하자면 모놀리식은 혁신 시도 부담이 큰 환경이며 실패 시 막대한 비용을 손해보고 결국 잦은 실험적 시도가 불가능하지만 운영 오버헤드 감소 및 쉬운 테스트, 큰 규모의 프로젝트 수행에 알맞고, MSA는 혁신 시도 부담이 적은 환경에 사용하면 좋으며 실패 시 적은 비용과 시간의 손실이 나오고 결국 많은 실험적 시도를 할 수 있는 환경이 된다는 점이다.

 

이 후에는 장,단점을 조금 더 깊게 설명해 주시고 MSA 의사 결정 트리와 패턴에 대해 설명해 주셨다.

 

패턴부터는 슬슬 내가 이해하기 어려워지는 영역이 되어서 복습 정리에 공부할 수 없었다. 간단히 강연을 들으면서 메모한 부분만 적자면 아래와 같다.(키워드만 따서 필요에 따라 따로 검색해 보는 것이 좋을 것 같다.)

 

Saga 패턴

: 사람이 인지하기 쉽고 판단하기 좋아서 Saga를 선호한다.

 

CQRS 패턴

: -

 

Shared 패턴

: 단일 데이터 베이스를 사용하는 것이다. API로 데이터를 주고 받는다.

 

API Gateway 패턴

: MSA에서 게이트웨이는 꼭 필요하다. 다른 기업한테 API를 노출하는 경우는 많이 없기 때문에 스프링 클라우드 API로 심플하게 사용한다. 실제 클라이언트와 백엔드에 있는 서비스를 분리해 주는 것이다. Rest로 만들면 각각 서비스를 하나의 서비스로 보이도록 구성하기에 유리한 패턴이다. 때문에 많이 사용하고 꼭 사용해야 한다.

 

Discovery 패턴

: -

 

Circuit breaker 패턴

: 장애가 생기면 빨리 끊어준다. 예외 처리는 직접 코드를 넣어야 한다. 만약 MSA가 되게 많고 지엽적 장애가 발생할 확률이 높고 트래픽을 보내는 게 위험할 것 같다면 Circuit breaker 패턴을 사용하는 것도 고려하면 좋다.

 

이 외 뭐라 설명해야 할 지 모르겠는데.. 트랜젝션을 추적하는 기능 중 Observability도 알려주었다. 간단하게 클라이언트가 호출을 흐름에 Trace ID를 남겨 부모,자식으로 쭉쭉 묶어 버그나 장애가 생겼을 경우 추적이 가능하게 만들어 둔 기능이다.

 

BFF(Backend For Frontend)도 알려주었다. 디바이스 종류에 따라 API와 UI의 관점은 다를 수 있는데 중간에 뭐가 없다 보니 같이 가져가는 문제가 있었다. 하지만 BFF를 통해 API를 모아 중간에 중재자로 UI에 맞는 API를 넘겨주어 여러 디바이스에서 효율적으로 동작하게 된다. 이는 강사님도 자주 사용하고 있다고 하셨다. 또, 후반에 질문에 게이트웨이 앞에 있냐, 뒤에 있냐 질문도 나왔었는데 UI서버와 같이 할 경우 API Gateway보다 앞에 둔다고 했다.

 

이 뛰에서는 Service Mesh에 대해 설명을 해주셨는데 사실 이 부분은 전혀 이해하지 못 했다. 게이트 웨이나 패턴 중 몇 개 정도는 동기들 수준이나 인강, 유튜브에서도 몇 번 듣기야 했는데 Service mesh는 처음 들었다. 간단하게 설명 하자면 Mesh는 비즈니스 로직과 아키텍쳐가 물리적으로 분리되어 있는데 서킷 브레이커 예외 처리는 물론 로직이 들어가야 한다고 한다. 또, Service Mesh는 VM환경(Ec2, 온프레미스 등)에서는 사용하지 못 하며 오직 컨테이너 환경에서만 사용할 수 있다고 한다. 잘 이해는 하지 못 했지만.. 다양한 언어를 사용한다면 고려할만하다고 하셨다. 나중에 MSA에 대해 좀 더 깊게 알아야 한다면 검색해 봐야겠다. 좋은 키워드를 얻어가는 부분이였다.

 

이후 강의 끝이 되어서 적용 사례를 설명해 주셨는데 이때 적용 사례가 강사님이 경험했던 사례를 통해 직접 사진과 프로젝트 자료 중 일부를 보여주셔서 신기했다. 아직 현업 경험이 많이 없어서 어떻게 이런 회의를 진행하나 했는데 많이 참고할 수 있는 자료를 넣어주셔서 너무 좋았다.

 

처음에는 도메인 분리하고 이때, 현업에서 일하고 있는 사람과 같이 비즈니스를 분석, 분리했다. 오직 비즈니스 관점에서 서비스를 분리한 것이다. 이것은 비즈니스를 이해하기 위해서 또, 잘 쪼개기 위해서 꼭 필요한 작업이라고 했다.

 

이렇게 분리했지만 여러 피드백이 있었고 Actor 관점과 요구사항, 기능, 데이터, 인터페이스 등의 관점에서 재분리를 다시 한 뒤에 총 18개로 서비스를 확정했으나 추후에 10개 정도로 줄었다고 하셨다. (쿠버네티스 뭐.. 이슈 등등..) 이때, 시스템 관리자 서비스는 모든 데이터베이스를 관리해야해서 MSA가 아닌 모놀리식으로 만들었다고 하신다. MSA를 사용해도 모놀리식의 장점이 더 큰 부분은 과감하게 모놀리식으로 만든 모습도 신선했다.(왜냐하면 간단하게 프로젝트 검색해서 구경하는 수준에서는 섞어서 프로젝트를 만들었다라는 것을 본 적이 없었기 때문이다.) 이렇게 서비스 구성안에 대해 여러 관점(장애, 트랜잭션, 부하 등)에서 보고 난 뒤에 API를 설계했는데 이래야 프론트 개발자와 동시에 작업이 가능하다고 했다.

 

설계한 서비스에서 대외, 대내 시스템으로 구분되는 경우는 각각 하나씩 만들어 주지 않고 인터페이스를 만들고 모든 인증(JWT 등..)을 여기서 처리하도록 했다고 한다. 나중에 참고하면 좋을 것 같아서 메모해 두었다.

 

다음은 Layered 아키텍처, 논리 아키텍처, Overall 아키텍처 등을 만들었고 이 프로젝트는 18개월 정도에 70명 인력이 투입되었다고 했던가.. 그랬던 것 같다. 이것도 마지막에 질문으로 나와서 얼핏 들었는데 글을 적다 떠올라서 넣어봤다. 생각보다 짧은 기간에 생각보다 많은 인원이 들어가는구나를 느꼈다.

 

MSA 전환 시 고려할 점에 대해서도 알려주었는데 처음 시작부터 어떻게 해야 할지 살펴봤다. 일단 업무 영역을 기반으로 서비스를 크게 구분하고 또 구분해서 점점 세분화하며 진행한다. 자료에서 다룬 부분이지만 참고로 Rest API는 다 동기로 사용할 수 있다. 즉, 순차적이라 사람이 인지하기 쉽다. 예를 들어 결제 같은 것은 순서가 있기 때문에 비동기로 하면 위험하다. 이 부분도 체크해 두면 좋을 것 같아서 따로 표시해두었다.

 

MSA를 고민하면서 데이터베이스에 대한 궁금증도 많았는데 이 또한 설명해주었다. 하나의 데이터를 공유하는 방식과 각 서비스가 각각의 데이터를 사용하는 것 중간에 미니 서비스(하이브리드 서비스)도 있다고 했는데 미니 서비스는 일부는 데이터베이스를 쉐어하고 있고 일부 서비스는 독립적인 데이터베이스를 사용한다.

 

MSA 유형 결정에 대해서는 간단히 3가지를 제시했는데 단일 페이지를 소유한 MSA, 단일 페이지를 공유하는 MSA, Front-End를 분리한 MSA 이렇게 3가지가 된다. 이 중 제일 마지막 Front-End를 분리한 MSA를 요즘에는 가장 많이 사용하고 있다고 한다.

 

팀의 중요성에 대해서도 말했다. 이때, 서비스 하나당 한 팀을 만들지 않고, 팀 내의 하나의 파트를 둘 수는 있다. 라고 했다.

 

전환 시 고려 점으로 Legacy와 관계도 생각해 봐야 한다고 했다. 레거시가 없다면 오히려 어려울 수 있다고 했다. 반대로 레거시가 존재하고 만약, 잘못 설계가 되어 있다면 미리 리팩터링을 먼저 해서 기술 부채를 미리 덜어놓거나 리소스와 시간을 더 확보해서 병행하면서 진행하는 것이 중요하다고 한다. 특히, 레거시가 존재하면 미니 서비스를 무조건 고려하는 게 좋다고 했다.

 

그리고 최신 기술을 요즘 고집하는 사람이 많아서 그런지 최신 기술에 대해 주의도 주었다. 나의 니즈를 이 기술이 과연 다 수용할 수 있나?에 대한 점을 잘 생각해 봐야한다. 단지, 트랜드가 이러더라로 결정하면 안 되는 부분이다.

 

이렇게 강연은 마무리 되었고.. 2시간이 진짜 한 40분 처럼 후딱 지나갔다. 아무래도 못 알아듣는 부분이 많다 보니 혹시 알아 들을 수 있는 부분이 나오면 놓치면 안 되니 더 집중해서 들었던 것 같다. 덕분에 얻어가는 것도 최대한 억지로 흡수할 수 있었고 뒤늦게 복습하면서 다시 상기시키고 포인트를 체크해 둘 수 있어서 좋았다.

 

지금 하고 있는 개인 프로젝트를 다 마치면 이것을 리팩터링을 해보던가 강사님이 추천하는 토이 프로젝트를 만들어 볼 예정이다. 토이 프로젝트는 기능까지 구현할 필요는 없고 흐름 정도를 구현하면 딱 괜찮을 것 같다고 하셨는데 같은 생각이다. 빈 기능의 프로젝트로 MSA를 간접 경험해보고 지금 만들고 있는 프로젝트를 리팩터링해 보는 것도 재밌을 것 같다.

 

최소한 곧 있을 취업 전에 MSA 프로젝트 한 개 쯤은 완성해 보고 가고 싶은 마음이다. 오랜만에 들은 세미나도 매우 유익한 정보를 잔뜩 얻어갈 수 있어서 좋았다. 아쉬운 점은 부족했던 내 지식이지만.. 분명 현업자 분들은 나보다 얻어가는 게 많았을 것 같다..