도커와 마이크로 서비스 아키텍처 개요 (Docker & MSA)

개요

2019년에 인턴 생활을 했을 때, MSA(Micro Service Architecture)라는 키워드가 동기들 사이에서 자주 등장했었고 실제로 면접에서도 자주 등장했었던 내용이었습니다.

그리고 지금 현재 2021년에는 웬만한 플랫폼 서비스에서 Docker가 사용되고 있고, 많은 기업들이 기존의 레거시 서비스를 모놀리식 아키텍처(Monolithic Architecture)에서 마이크로 서비스 아키텍처로 전환하고 있기 때문에 도커와 마이크로 서비스에 대해서는 알아두는 것이 좋을 것 같습니다.

 

모놀리식 아키텍처

• 구시대적 서비스 방법
• 서비스가 하나의 애플리케이션으로 실행되는 구조 즉, 하나의 거대한 아키텍처
• 다양한 기능을 동작하는 서비스를 서버에서 실행

 

모놀리식 아키텍처 장점

• 하나의 애플리케이션이기 때문에 비교적 간단히 배포할 수 있음

 

모놀리식 아키텍처 단점

• 반면, 로드밸런싱을 할 때 불필요한 서비스까지 모두 이중화해야 함
• 또한, 각 기능이 사용하는 라이브러리 버전이 상이할 경우 관리하기 어려움 (라이브러리 종속성이 문제)
• 마이너한 수정 사항이 있더라도 전체 빌드 및 배포를 해야 하므로 비효율적 (서비스가 커지면 커질수록 딜레이 시간 기하급수적으로 증가)

 

* 로드밸런싱(Load Balancing): 가용성 및 응답 시간 최적화를 위해 둘 혹은 셋 이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 작업

 

마이크로 서비스 아키텍처

• 앞서 언급한 모놀리식 아키텍처와 반대되는 개념
• 애플리케이션의 기능들을 분리하여 개발하고 관리 진행

 

마이크로 서비스 장점

• 모놀리식 아키텍처의 단점들을 보완
• 서비스 단위로 개발이 진행 가능함 (라이브러리 종속성에서 해방)
• 개별 서비스 단위로 개발, 패키징, 빌드, 테스트 및 배포가 가능하므로 효율적
• 로드밸런싱을 할 때, 자주 사용되는 서비스만 이중화 가능하여 자원 절약이 가능함

 

마이크로 서비스 단점

• 시스템이 분산되어 있기 때문에 아래와 같은 사항을 고려해야 하므로 관리 복잡
  
  • 트랜잭션 보장
  • 테스트
  • 배포

 

https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/

 

MSA의 단점을 해결하기 위해 등장한 개념

• MSA의 단점인 관리 복잡성을 해결하기 위해 컨테이너, 도커 그리고 쿠버네티스 등장
• 컨테이너: 환경을 격리시키는 역할
• 도커: 컨테이너들을 편리하게 사용 가능하도록 각각의 컨테이너를 관리해주는 역할
• 쿠버네티스: 다양한 도커들을 관리해주는 역할

 

https://www.edureka.co/blog/kubernetes-tutorial/

 

* 고래 위에 있는 박스들이 컨테이너

 

컨테이너

• 가상 머신을 사용해 각 마이크로 서비스를 격리하는 기술 (isolate)
• 가상 머신처럼 하드웨어를 전부 구현하지 않아도 되기 때문에 실행 속도가 비교적 빠름
• 프로세스 문제가 발생할 경우 컨테이너 전체를 조정해야 하기 때문에 컨테이너 당 하나의 프로세스를 실행하도록 하는 것이 효율적

 

컨테이너를 격리하는 기술

• 컨테이너의 핵심은 각 프로세스마다 격리 환경을 제공하는 것이므로, 격리하는 기술이 중요
• 리눅스 네임스페이스와 리눅스 컨트롤 그룹을 통해 격리 환경을 제공
• 리눅스 네임스페이스(Linux namespace): 각 프로세스가 파일 시스템 마운트, 네트워크, 유저(uid), 호스트 네임(uts) 등에 대해 시스템에 독립된 뷰를 제공하는 역할
• 리눅스 컨트롤 그룹(Linux Control Group): 애플리케이션이 자신의 자원을 사용할 수 있도록 프로세스가 소비할 수 있는 리소스 양을 제한 (CPU, 메모리, I/O, 네트워크 대역폭, device 노드, etc.)

 

* 리눅스 커널은 내부에서 공유하기 때문에 또 다른 커널 혹은 운영체제 설치할 필요 없음

 

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

 

* Traditional Deployment: 온프레미스 환경

* Virtualized Deployment: 온프레미스 환경에서 발전을 했지만 하드웨어를 가상화했기 때문에 무거운 것이 단점

* Container Deployment: 불필요한 운영체제와 Hypervisor 생략 가능 (효율적으로 가상화 환경 운영 가능)

 

도커

• 컨테이너 기술을 지원하는 다양한 프로젝트 중 하나이지만 사실상 컨테이너 기술의 표준
• 리눅스, 윈도우, MacOS 등 다양한 운영체제에서 사용 가능하지만 윈도우의 경우 Hypervisor가 필요하기 때문에 비교적 성능이 떨어짐 
• 애플리케이션에 국한되지 않고 의존성 및 파일 시스템까지 패키징하여 빌드, 배포, 실행 프로세스가 단순화
• 컨테이너 기술의 핵심인 리눅스 네임스페이스와 컨트롤 그룹과 같은 커널 기능을 사용하여 가상화

 

https://vmarena.com/docker-architecture-and-components/

 

중요 용어

• 컨테이너: 이미지를 격리하여 독립된 공간에서 실행한 가상 환경
• 이미지: 필요한 프로그램, 라이브러리, 그리고 소스를 설치한 뒤 생성한 하나의 파일
• 클라우드 서비스 모델 중 PaaS, SaaS가 이미지가 존재하는 형태이며 도커와 같이 사용 가능

 

* 도커 레지스트리에는 사용자가 사용할 수 있도록 데이터베이스를 통해 이미지를 제공

* 도커 레지스트리 확인 링크: hub.docker.com

 

도커 아키텍처

 

https://medium.com/tiffanyfay/docker-1-11-et-plus-engine-is-now-built-on-runc-and-containerd-a6d06d7e80ef

 

* Docker engine: 이미지, 네트워크, 디스크 등을 관리하는 역할

* containerd: runC와 같은 OCI 구현체를 이용해 컨테이너를 관리해주는 daemon

* 두 프로그램이 각각 돌아가기 때문에 도커 엔진을 재시작해도 각 이미지에 영향 X

 

도커의 한계

• 도커가 컨테이너들이 증가함에 따라 관리의 필요성이 느껴져 등장한 개념이지만 도커 또한 서비스가 커질수록 양이 증가하기 때문에 관리하기 어려운 상황이 발생할 수 있음 
• 따라서, 보조를 위해 오케스트레이션 툴이 필요한데 이때 등장한 개념이 쿠버네티스

 

쿠버네티스

• 도커의 한계를 극복하기 위해 등장한 오케스트레이션 툴
• 구글이 컨테이너 운영을 위해 출시한 오픈소스 라이브러리
• 많은 시스템을 통합했고 컨테이너를 다루기 위한 다양한 API 제공

 

출처

인프런 데브옵스(DevOps)를 위한 쿠버네티스 마스터

 

각 이미지마다 출처 링크를 남겼는데 해당 링크도 참고하시면 좋을 것 같습니다.