[MSA 1.0] 컨테이너를 활용한 MSA 개발

 

 

# MicroServices
# MSA

 

1. MSA 란 무엇일까?

 

애플리케이션의 복잡성이 증가됨에 따라 디자인 패턴도 변화한다. 

1개의 서버에 1개의 어플리케이션이 가동되던 서버로 모든 어플리케이션이 가동되던 시대는 어땠을까?

 

과거의 레거시 어플리케이션을 모놀리스 아키텍처라 부른다.

Mono라는 단어 자체가 1개의 라는 의미를 내포하기 때문에, 이름 에서부터 예측할수 있지만 한개의 서버에서 어플리케이션이 가동된다라고 이해 하면 된다.

 

모놀리스에는 어떠한 문제점이 있는지 살펴보자. 우선 장애 측면에서 봤을때 일부분의 장애가  전체 어플리케이션의 장애로 확산된다는 가장 큰 단점이 있다.

 

그 예를 찾아보면, 2000년대 초반으로 돌아가는데..

우리가 잘 아는 AWS 역시도 과거에는 모놀리스 아키텍처에서 서비스를 가동했다.

 

물론 , AWS, Netflix가 MSA를 가장 먼저 도입한 대표적인 회사로 잘 알려져 있다. 하지만

2008년까지 AWS와 Netflix는 거대한 모놀리스 서비스 즉, 거대한 단일 아키텍처 그 자체 였다고 한다.

 

하지만 그들은 계속적인 서비스의 팽창과 개발속도에 배포속도를 맞추기 위해서 Microservices 라는 아키텍처를 선택 할수 밖에 없었다고 전해진다.

 

즉, 마이크로서비스는 돈이 남아서 하는것이 아니다. 어쩔수 없이 필연적으로 그러해야만 하는 이유가 있을때 회사들이 선택한다.

 

2. 그럼 마이크로서비스는 대체 무엇일까? 

거대한 모놀리스 아키텍처를 기능 단위로 서비스를 쪼개는 것이다.

예를 들어, 쇼핑몰에는 로그인,주문, 결제 , 배송과 같이 많은 기능들이 존재한다. 모놀리스 아키텍처에서는 이 모든 코드들이 한 서버에 존재하기 때문에, 일부분의 장애가 전체의 장애로 확산된다. 코드 한줄을 잘못 적어 넣었을 뿐인데, 로그인도 안되고, 주문도 못하고 , 결제도 실패하는 괴로운 상황이 도래 한다. 

 

이를 피하기 위해서 서버를 여러대 두고 로드벨런서를 앞단에 위치 하기도 하지만, 이러한 방법도 임시 방편이다. 어찌 되었던 간에 

3개의 서버와 로드벨런서로 구성할 경우, 33% 의 고객은 결제를 하지 못할테니까..

 

또한 로드벨런서 비용과 3개의 똑같은 서버를 구축하는 비용은 또 감당하기 어려울수도 있기 때문이다..

그래서 도입된것이 마이크로 서비스다.

 

마이크로 서비스는 모든 기능들을 전부 각기 다른 서비스에 위치하게 하는것이다.

 

✔️ 그렇게 되면, 먼저 장애 전파 측면에서 일부분의 장애가 크게 확산되지 않는다. 

 

1개의 서버 안에서 모든 기능을 유지하던 모놀리스 형태와는 다르게 

수천개의 작고 귀여운 서비스들은 유기적으로 각자의 이름을 호출하며 서로 필요한 정보를 주고 받는다. 

 

✔️ 배포의 속도에도 굉장히 유리하다.

 

 왜냐하면 로그인의 UI 를 변경해서 배포해야 하는 상황을 가정해보자. 모놀리스 아키텍처에서 그 배포는 단순히 로그인의 인터페이스만 변경하는데 전체 코드를 다시 배포해야 한다. 그 시간이 로그인 기능을 담당하는 서비스만을 배포하는 것보다 시간이 많이 걸리는건 당연한 이야기다.

 

MSA를 도입한다는 것은 굉장한 장점이 있는것은 맞지만 단점들도 분명히 존재한다. 5~6년 전부터 MSA에 대해서 많은 논의가 있어 왔고, MSA와 같은 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합해 높은 인기를 구가하고 있다. 특히 도커(Docker), 쿠버네티스(Kubernetes) 등과 같은 컨테이너 기반의 플랫폼과 조합이 잘 어우러지면서 클라우드 플랫폼과 MSA는 서로 끌어주고 밀어주면서 발전하고 있다.

 

MSA는 아마존, 넷플릭스, 이베이와 같은 글로벌 서비스 기업들이 사용할 만큼 강력한 아키텍처이다. 하지만 막상 MSA를 적용하려고 하면 다음과 같은 난관에 부딪히게 된다.

 

✔️ 개발 복잡도와 숙련도

 

분산 시스템 개발은 일반 개발보다 복잡하다. 독립적인 서비스이기 때문에 각 모듈의 인터페이스를 신중하게 처리해야 한다. 요청에 응답하지 않게 될 경우에 대한 방어 코드도 작성해야 하며 호출 대기 시간이 일정 수준을 넘기면 복잡한 상황이 발생할 수 있다. 또한 동기적인 처리방식인 REST 통신으로 인한 제약이 발생할 수 있다.

 

✔️ 트랜잭션 관리

 

MSA는 Database Per Service라는 새로운 요구사항으로 분산된 서비스마다 분리된 DB들 간의 트랜잭션 관리가 어려울 수 있다. 또한 반정규화 된 데이터의 동기 처리도 신경을 써야 한다.

 

✔️ 통합 테스트 어려움

MSA 기반의 애플리케이션을 테스트하는 것은 번거로울 수 있다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 한다.

 

✔️ 배포 복잡도

 

MSA의 배포는 복잡 할 수 있다. 각 서비스 간의 조정이 필요 할 수 있다.
MSA를 도입하다보면 기존에 없던 새로운 문제점들이 발생한다. 이런 부분들은 자동화 도구를 반드시 사용해야 한다.
CI/CD와 같은것들이 이러한 기술에 속한다.
개발조직의 CICD에 대한 업무 과중 역시 기술부채에 속한다.

 

 

결론적으로,
MSA를 도입하여 사용하는 회사들은 대부분 Netflix, AWS와 같은 전세계의 대표적인 글로벌 기업들이다.

이들에게는 1시간 정도의 서버 장애가 곧 천문학적 금액의 벌금으로 돌아온다.

반면, 규모가 작은 회사 같은 경우에는 컨테이너보다 가상머신이 어울릴수 있다.
그렇지만, 최근 들어 이러한 Cloud Native한 분위기와 트렌드로 봤을때 
이러한 기술의 발전을 학습하는것은 매우 중요하다고 생각한다.

 

 

 

 

 

---

3. Docker란 무엇인가? 

나는 docker에 대해서 아무것도 모르는 사람에게 docker을 설명하게 되면, 가상화 안의 가상화 라고 설명을 한다.

왜냐하면, 우리가 접속하는 PC 말고 실제 운영하는 서버를 생각해보자. 

 

AWS EC2 가상머신이고 해당 서버 안에서  개발한 코드를 Production 레벨로 공급한다고 생각해보자. 보통은 WEB-WAS-DB를 

서버에 설치한다. 그리고 소스 코드를 붓는다.

 

하지만 Docker를 사용하게 되면 도커 WEB 컨테이너, WAS 컨테이너, DB 컨테이너를 개별적으로 배포하면 된다. 

EC2에서 간단한 명령어로 쉽게 설치가 가능하며, 사용하는 방법도 크게 어렵지 않다.

 

 AWS에서는 docker를 이렇게 설명한다.

 

Docker는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼이라는 이야기를 많이 한다. Docker는 소프트웨어를 컨테이너라는 표준화된 유닛으로 패키징하며, 이 컨테이너에는 라이브러리, 시스템 도구, 코드, 런타임 등 소프트웨어를 실행하는 데 필요한 모든 것이 포함 되어 있기 때문입니다.

 

이게 또 무슨 이야기냐면, Docker가 컨테이너가 구동될수 있게 엔진 역할을 하기도 하지만, 

컨테이너를 만드는 일도 한다. 따라서 컨테이너 관련한 모든 일을 다 한다고 해서 플랫폼이다. 라는 표현을 쓰는것이다.

 

Docker를 사용하면 환경에 구애받지 않고 애플리케이션을 신속하게 배포 및 확장할 수 있으며 코드가 문제없이 실행될 것임을 확신할 수 있습니다. 

 

개발자와 관리자가 어떠한 규모에서든 매우 안정적이며 저렴한 방식으로 애플리케이션을 구축, 제공 및 실행할 수 있습니다.

 

👌  Docker를 사용해야 하는 이유

Docker를 사용하면 코드를 더 빨리 전달하고, 애플리케이션 운영을 표준화하고, 코드를 원활하게 이동하고, 리소스 사용률을 높여 비용을 절감 할수 있다. Docker를 사용하면 어디서나 안정적으로 실행할 수 있는 단일 객체를 확보하게 됩니다. Docker의 간단한 구문을 사용해 완벽하게 제어할 수 있습니다. 폭넓게 도입되었다는 것은 Docker를 사용할 수 있는 도구 및 상용 애플리케이션의 에코시스템이 강력하다는 의미입니다.

https://aws.amazon.com/ko/docker/ ( 참고 )

 

2. 기능 구현 - 메시징 큐(1)

메시징 큐에 대해서도 연구해볼 필요가 있다.

• MessageQue의 존재 이유를 분석하고 구현 한다.
• Kafka와 RabbitMQ를 비교 하여 사용해보고 차이점과 장점을 비교한다.

메시징 큐 관련해서도 Kafka와 RabbitMQ 두가지 실습해보고, 하나 선택해서 사용할 예정입니다. 계속적으로 포스팅되는 글들을 참고해주세요.

 

 

 

3.  기능 구현- 프론트 프레임워크(2)

MSA에서의 프론트 프레임워크의 장점에 대해 탐구한다.

또한 백엔드 프레임워크와 어떻게 유기적으로 통신을 하는가에 대한 초점을 스터디의 연구 주제로 삼는다.

 

 

 

 

 

4. 기능 구현 - Spring cloud MSA 아키텍처 (3)

 

되도록이면 Spring Cloud의 MSA 아키텍처를 사용해볼수 있도록 한다.

언어의 선택은 자율성을 갖지만 Spring Cloud의 아키텍처를 활용해 본다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

스터디 일정이 7월 30일이기 때문에, 스터디 진행전에 여러분들은 Docker 관련해서 Window 및 MacOS에 

설치해 보시고, 기본적인 개념들을 공부해서 와주셔야 합니다. 

https://themapisto.tistory.com/168?category=1042975 참고해서 설치하시면 됩니다.