[욕망의 인프라 : 도커 & 쿠버네티스] 쿠버네티스의 등장배경(MSA)

본 스터디(이하 욕망의 인프라)는 열음(https://github.com/Juhyung990122)과 함께합니다.

컨테이너를 오케스트레이션 하는 도구. 쿠버네티스는 여러 컨테이너 런타임들을 운영하기 편하게 도와주는 도구이다. 이건 왜 등장하게 되었을까?

모놀리틱 아키텍쳐

전통적인 “모놀리틱 아키텍쳐”는 여러 서비스가 하나의 애플리케이션으로 뭉쳐있는 형태이다. 이 경우, 초기 개발 속도를 올려주지만, 장기적으론 개발, 운영, 유지보수 측면에서 다음과 같은 문제들이 있었다.

 

스케일 아웃시 불필요한 리소스 복제

위에 그림에서의 어플리케이션에서 채팅 서비스의 기능의 트래픽이 많아 스케일 아웃이 필요한 상황이 됐다고 가정해보자.

트래픽이 많아서 문제가 됐던 건 유저 서비스 뿐인데 불필요한 다른 서비스들도 복제가 되는 문제가 발생한다. 즉 리소스가 최적화되지 않았다.

 

라이브러리 충돌 문제

모놀리틱 아키텍쳐에서 만약 각각의 서비스가 같은 라이브러리를 사용해서 개발한다면, 버전은 통일시켜야 할 것이다. 만약 버전이 다르면 충돌이 일어날 것이고, 또한 프레임 웍이나 서드파티 라이브러리 등에 포함된 라이브러리도 충돌을 일으키지 않게 해야할 것이다.

위 그림의 예시에서 유저 서비스랑 게시글 서비스가 모두 A라이브러리를 사용하고 있는데, 게시글 서비스에서 A라이브러리의 1.1버전부터 추가되는 기능을 이용하기 위해 버전을 올리고 싶다고 가정해보자. 버전 호환이 잘 되면 문제가 없겠지만, 만약 버전을 올리면서 기존에 의존하던 패키지 구조나, 클래스 명이 바뀌거나 그러면 게시글 서비스 뿐만 아니라 유저 서비스도 영향을 받을 수 있다.

 

빌드/배포/테스트의 어려움

세 서비스 중 유저 서비스를 개발하는 팀이 코드를 변경해서 새로 빌드/배포/테스트를 할 경우에, 모든 서비스가 정상적으로 동작하는 지 함께 빌드/배포/테스트 과정에 포함시켜야 한다. 가장 큰 문제는 아주 작은 코드 변경에도 이러한 과정을 거쳐야 한다는 것이다. 이는 개발 속도를 저하시키는 데에 큰 원인이 되었다.

 

마이크로 서비스 아키텍쳐

위 문제를 해결하기 위해 서비스 개발 단위로 어플리케이션을 나누는 마이크로 서비스 아키텍쳐(MSA)가 나왔다.

이런 MSA 구조라면 채팅 서비스가 더 필요하면 채팅 서비스만 늘릴 수 있고, 각 서비스마다 라이브러리를 독립적으로 선택해서 사용할 수 있으며, 서비스에 코드 변경이 일어났을 때 해당 서비스에 대해서만 빌드/배포/테스트 과정을 진행하면 된다.

 

MSA는 만능일까?

MSA는 다음과 같은 단점을 지닌다.

• 복잡한 분산 트랜잭션 처리
• 많이, 자주 변경되는 동적 인프라스트럭쳐에 대한 관리

쿠버네티스는 동정 인프라스트럭쳐에 대한 관리를 보다 편리하게 할 수 있게 해주는 도구이다.

 

쿠버네티스

서비스가 커질 수록 컨테이너들도 늘어나게 되고 컨테이너 런타임이 이를 전부 감당하기 어려워질 것이다. 쿠버 네티스는 여러 컨테이너 런타임(예를 들면 도커)들을 자동으로 운영할 수 있게 도와주는 도구이다. MSA 아키텍쳐를 효율적으로 관리하는 데에 안성맞춤이라고 볼 수 있다.

 

앞으로 스터디를 진행하며 차근차근 알아볼 예정..