[MSA 시작 #1] MSA 개념 아주 쉽게 이해하기

MSA (Micro Service Architecture) 가 이쪽 업계에서는 아주 뜨겁다. JD를 봐도 MSA 경험자 찾는 회사들이 엄청나게 많아진걸 보면 대세가 되어가고 있는듯 하다. 조금 공부를 해보니 그렇게 될 수밖에 없는듯 하다. 

 

MSA는 기존의 하나의 application 형태(Monolithic Architecture)가 아닌 application을 서비스별로 나누어 독립적으로 개발하는 아키텍처를 말한다. 각 서비스들은 API 호출을 하는 형식으로 통신을 한다. 아주 간단한 정의이다. 

---

MSA의 목적 (장점)

그럼 왜 멀쩡히 잘 돌아가는 서비스를 골치 아프게 나눌까? 여러가지 이유가 있다. 

 

• 빠르고 간단한 배포
• 시스템의 선택적 확장
• Polyglot 아키텍처 지원

제목의 간단히 라는 컨셉에 맞게 MSA를 사용하는 이유도 아주 간단히 정리해봤다. IT쪽 일을 하며 커다란 서비스를 직접 배포하고 운영해본 사람은 이런 것들이 필요한걸 뼈저리게 경험했을것이다.

 

빠르고 간단한 배포

Monolithic 구조에서 일단 운영중인 큰 시스템 배포를 한번 하는건 큰 일이다. 새로 반영한 내용이 다른것들에 대해 영향력이 없는지 정말 꼼꼼히 봐야 한다. 만약 새로 배포한 내용에 오류가 있다면 전체 시스템 장애로 이어질 수도 있기 때문이다. 테스트를 꼼꼼히 하고(테스트도 큰 일이다.) 모두가 지켜보는 가운데 숨죽이고 배포를 한다.. 그것도 업무가 모두 끝나고 이용자가 적은 시간에.. 이 소리는 당연히 야근/특근을 해야 한다는 것이다. 이에 반해 MSA는 서비스별로 자신이 맡은 영역에 대해서만 빌드 및 배포를 진행하므로 위험부담은 현저히 줄어들고 독자적으로 이런것을 수행할 수 있기에 업무 효율은 획기적으로 증대된다. 

 

시스템의 선택적 확장

마케팅팀에서 엄청나게 일을 잘해서 갑자기 시스템 폭주가 예상이 된다면? 며칠 전부터 이 큰 덩치의 어플리케이션을 올릴 서버들을 물색하고 이것을 돌리기 위한 설정을 한다. 커다란 놈이라 설정하기가 만만치가 않다. 하지만 서비스를 나눠서 부하가 몰릴 서비스에 대해서만 확장을 한다면.. 이런 작업이 훨씬 수월할 것이다. 해보면 안다. 

 

Polyglot 아키텍처 지원

용어가 낯설고 어렵다. 쉽게 이해시켜줄만한 단어는 '꼴리는대로 만든다' 정도 될것같다. 언어의 선택이 아주 저속하다. 덩치가 큰 어플리케이션은 보이지 않는 창살이 어플리케이션 주위로 둘러져 있다. 즉 이 안의 세계에 누구도 쉽게 들어오는 것을 허락치 않는다. 선택된 것들만 허용한다. 최신 기술로 나온 효용성이 높은 언어라던지 Framework, 이미 사용하고 있는 library의 최신 버전의 적용도 쉽지가 않다. 나는 이런거 저런거 적용해서 더 잘해보고 싶은데 그렇게 하기 힘들다. 한마디로 이 덩치 큰 어플리케이션을 오래 다루다 보면 고인물이 되어버린다. 하지만 MSA 구조로 가게 되어 작은 서비스별로 내가 만들고 싶은대로 만들수 있다. (현실적으로 쉽지는 않아보인다.. SI에서 이렇게 여러 API 서비스들을 맘대로 만들어 놨다가는.. 어휴.. 이 아키텍처는 온전히 DevOps가 잘 정착되어 그 서비스를 그 팀에서 잘 처리할 수 있는 환경에서 가능할 것이다.)

 

---

MSA 단점 

위의 글들만을 봤을때는 MSA를 찬양만 해도 부족하다. 하지만 많은 기업들이 바로바로 이런 훌륭한 아키텍처로 전환을 하지 않고 있는데는 많은 이유가 있다. 

 

• 기술 복잡도가 높음
• 느린 속도 
• 관리 포인트 증가 

기술 복잡도가 높음

아마도 이게 전환이 빠르게 이루어지지 않는 가장 큰 이유가 아닐까 싶다. 어렵다. 기존에 돌고 있던 큰 덩어리를 서비스별로 다 쪼개서(DB까지도..) 나누는 일 자체가 엄청나게 어려운 일이다. 시스템을 완전히 분석을 해야 하는 일이기에 이 기간만 엄청나게 오래 걸린다. 거기에 Monolithic 에서는 고민할 필요가 적었던 어플리케이션간 인증, 설정, 트랜잭션, 로깅, 모니터링 등등의 항목들도 많은 고민을 해야 한다. 또한 새로운? 기술들의 향연이 펼쳐진다. Spring Cloud, Netflix OSS, 분산 트랜잭션, ELK, Docker에 Kubernates, Kafka 등등.. MSA를 하면 이 모든 신문물?을 접할수 있다. 

테스트를 할때도 다른 서비스와 얽혀 있다면 시나리오 짜는것도 어렵다. 디버깅도 여러 서비스로 나뉘어져 있어서 오류 찾는것도 Monolithic 에 비해 어렵다. 아무튼 어렵다. 

 

느린 속도 

워낙 하드웨어, 네트워크가 발달한 시대에 살고 있어서 크게 와닿지 않을수도 있지만 그래도 하나의 어플리케이션에서 자기 자신의 메소드를 호출하는 것보다 분명히 다른 어플리케이션을 호출을 하는것이 느린것은 당연하다. 

 

관리 포인트 증가

서비스가 여러개로 쪼개지면 당연히 관리 포인트가 증가가 될수밖에 없다. 거기다가 그 각각의 서비스를 취합해서 모니터링도 해야 하고 로그도 쌓아야 하고 인증에 대한 관리를 해주는 녀석도 필요하고 설정을 관리하는 녀석도 필요하다. 분명 편리한점도 있지만 이렇듯 복잡해지고 불편해지는 점들도 존재하게 된다. 

 

 

이렇듯 MSA는 분명하게 장단점이 있다. 상황에 맞게 구분을 해서 적용을 해야 한다. 

다음장부터는 MSA하기 아주 좋게 잘 나온 OSS들을 이용해서 간단한 MSA 환경을 만들어 보도록 하겠다. 

 

끝!