1. What is MSA?

1. MSA 란 무엇일까요?

서버 개발을 하다보면, 여러가지 많은 기능들을 만들어야 되는데, 이걸 하나의 프로그램에 다 쑤셔 넣어 개발하다보면 생기는 문제들이 있습니다. 일단 프로그램 안에 수많은 기능들이 들어있기 때문에 하나 망가뜨리지 않으면서 개발하는 것이 어렵습니다.

혹은 신기능을 하나 개발했다고 해도 신기능이 잘 되는지 테스트하고 컴파일하고 배포를 해야 되는데, 해당 프로그램의 규모가 클 경우 작업이 좀 오래 걸리기 때문에 개발자들이 어려움을 겪기도 합니다.

프로젝트가 크면 사용하는 프레임워크나 라이브러리 버전을 업데이트하는 순간 대참사가 일어나는게 대부분이기에, 코드 업데이트가 안 되어 고여서 썩는 문제들이 발생합니다.

더불어, 소스 코드가 너무 복잡해지다 보니 새로운 개발자를 채용해도 그 사람을 기존 코드에 적응시키는데 어려움이 있을 수도 있습니다.

이런 단점들을 극복하기 위해서, 기능들을 잘게 잘라낸 다음에 하나의 독립적인 서비스로 만들어서 운영할 수 있습니다. 이것을 바로 멋진 말로 마이크로 서비스아키텍처 라고 합니다.

참고로, 앞서 말씀드린 것처럼 한 곳에 모아놓고 개발하는 것은 모놀리식 아키텍처라고 합니다.

기존 Monolithic Architecture의 한계

• 부분 장애가 전체 서비스의 장애로 확대될 수 있음
• 전체 시스템 구조 파악이 어려움
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트 등) 파악이 힘듦
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(sacle-out) 하기 어려움 예를 들어서 쇼핑몰을 만든다고 했을 때 기능들을 만들어야 겠죠?

하나에 몰아서 개발하는 것이 아닌, 각각 독립적인 프로그램으로 만들어 놓고 필요할 때마다 동작시켜서 서버를 운영합니다. MSA는 API를 통해서만 상호작용할 수 있습니다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려집니다.

어떤 유저가 가입을 하고 싶다면 → 회원관리 서비스를 동작시키면 되고,

어떤 유저가 결제를 하고 싶다면 → 결제 서비스 동작시키면 됩니다.

자 근데 결제할 때 재고 파악을 먼저 해야 된다 그러면 재고 관리 서비스에 요청을 해서 재고를 미리 확인하면 되는 겁니다.

마이크로 서비스의 장점

1. 기능수정과 업데이트를 빠르게 진행 가능합니다.
   큰 프로젝트가 아닌, 작은 서비스 하나만 건드리면 되기 때문입니다. ( 실제로 그 프로젝트 하나하나가 정말 ‘작지’ 는 않겠지만..)
2. 같은 맥락으로, 코드 변동이 쉽습니다. 기존에 쓰던 라이브러리나 프레임워크 버전 업 하는것도 훨씬 쉽고, 간단해집니다.

서비스가 독립적이기 때문에 환경에 구애받지 않습니다.

3. 서비스 확장도 쉽다.

트래픽이 몰리는 서비스가 있으면 그 서비스만 선택해서 사이즈를 키울 수 있기 때문에 클라우드 자원을 효율적으로 쓸 수 있다는 장점도 있습니다.

정리하자면, 다음과 같습니다.

1. 배포

• 서비스별 개별 배포가 가능합니다.(배포시 전체 서비스의 중단이 없습니다.)
• 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능합니다.  

2. 확장

• 특정 서비스에 대한 확장성(scale-out)이 유리합니다.
• 클라우드 기반 서비스 사용에 적합합니다.  

3. 장애

• 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.
• 부분적으로 발생하는 장애에 대한 격리가 수월합니다.  

4. 그 외

• 새로운 기술을 적용하기 유연합니다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)
• 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

이 때문에 큰 기업들은 마이크로 서비스 아키텍처를 도입해서 개발하는 경우들이 많습니다 그리고 마이크로 서비스를 운영할 때 자주 쓰는 기술이나 툴들이 있습니다

마이크로 서비스의 구현

1. 컨테이너

도커와 같은 환경분리가 쉬운 컨테이너 같은 것 에 담아서 서비스를 배포할 수 있는 기술 같은 걸 쓰기도 하고,

1. 쿠버네티스 ( 컨테이너 오케스트레이션 ) 컨테이너가 매우 많아지면 이것을 관리하기 위해서 쿠버네티스 같은 것을 쓰기도 합니다

2. kafka 와 같은 메시지 처리 서비스 간의 메시지를 주고받을 때 빠르고 효율적으로 주고받기 위해서 카프카 같은 것도 사용 가능합니다.

3. 모니터링 서비스들을 모니터링 하기 위한 툴(프로메테우스, 그라파나, 데이터독 등 ) 들도 사용하는 경우들도 있고요

4. 배포 자동화

   그리고 서비스 배포를 자동화하고 편리하게 하기 위한 툴들도 사용하는 경우들이 많습니다.

대기업들이 마이크로 서비스를 많이 도입한다고 해서,

똑같이 마이크로 서비스 아키텍처를 도입해서 개발했다가 망했다는 후기들도 찾아보신 많습니다.

마이크로서비스 도입이 쉽지 않은 이유

복잡도가 매우 많이 증가해서 그렇습니다.

마이크로 서비스는 개발 복잡도는 낮아질 수 있지만, 전체적인 복잡도를 낮춰주는 툴이 아닙니다.

운영 복잡도라는게 매우 증가하기 때문입니다 마이크로 서비스가 100개 1000개 있으면 앞서 말했던 툴들이 거의 필수기 때문에 이거 관리하는 시간과 비용이 매우 늘어납니다.

그래서 개발자가 별로 없는 작은 회사다 그러면 개발 시간보다 관리 시간이 늘어나기 때문에 개발에 쏟을 시간이 좀 줄어들 수도 있습니다.

그리고 서비스 간의 통신하는데도 어려움이 가끔 있습니다. 통신이 너무 많거나 그러면 좀 오래 걸리고 뭔가 누락되고 그런 경우들이 가끔 발생합니다. 어떤 서비스랑 내가 통신해야 되는지 한참 찾아야 되는 경우들도 있고, 어떤 버그나 이슈가 생겼을 때의 어떤 서비스가 문제인지 범인을 찾기 좀 어려운 경우들도 있습니다.

그래서 정리하자면 그냥 대기업 조직에서 일어나는 운영상 비효율 문제들이 있습니다. 이런 것들이 그대로 개발 현장에서 일어난다고 생각하시면 됩니다. 그래서 언제나 장단점을 잘 따진 다음에 도입해보시면 좋습니다.

물론 사이즈 크다고 해서 항상 마이크로 서비스로 전환해야 하는 것도 아닙니다.

보통 이제 코드를 짜다가 너무 복잡한 코드 때문에 생산성이 좀 저하되는 시점이 있을 겁니다. 그 시점부터 천천히 도입을 시작하시면 되고, 아니면 마이크로 서비스 때문에 운영 복잡도 같은게 늘어나는게 싫다 그러면 서버리스 형태로 서비스를 배포하는 것도 하나의 방법이 될 수 있습니다.

[MSA 단점]

1. 설계의 어려움

• MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야합니다.  

2. 성능

• 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재합니다.  

3. 테스트/데이터 트랜잭션

• 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.- 통합 테스트가 어렵습니다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않습니다.  

4. 데이터 관리

• 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.
• 데이터를 관리하기 어렵습니다.