[iitp] 마이크로 서비스 아키텍처(MSA)에 대한 이해와 컨테이너 기술의 활용 방안

 

[ 마이크로 서비스 설계 : 본문 중 캡처 ]

 

 

 

*** 출처: [iitp] 마이크로 서비스 아키텍처(MSA)에 대한 이해와 컨테이너 기술의 활용 방안

*** 문서:

file2645276227345330267-188702.pdf

 

 

 

 

I. 서론

 

 

■ 최근 기업별 MSA 도입 동향

 

 

○ 아마존

 

- ‘Amazon Go’와 같은 줄 서지 않고 제품을 구매할 수 있는 식료품점 등을 통해 디지털 전환(Digital Transformation)을 가속화하고 있는데, 신속하게 개별 서비스를 혁신하고 새로운 기술 기반의 서비스를 개발 및 통합하기 위해 마이크로 서비스 아키텍처를 적용하였다.

 

 

○ 넷플릭스

 

- 1억 1,800만 명의 가입자에게 1일 1억 이상의 비디오 스트리밍을 제공하고 있는데, 높은 재생 품질을 다운타임 없이 서비스하는 것을 목표로 마이크로 서비스 아키텍처를 적용하였다.

 

- 마이크로 서비스에 적합한 조직 구성, 클라우드 기반 서비스 생명주기 관리 등을 고려하였으며, 이를 위해 Service Discovery, Circuit Breaker, API Gateway 등의 기술을 도입하였다.

 

- Netflix OSS를 선보이며, 기술의 확장 및 외부 커뮤니티와의 지속적 커뮤니케이션을 진행하고 있다.

 

 

○ 쿠팡

 

- 부분 장애가 서비스 전체 장애로 이루어지고, 서비스가 부분적으로 scale-out하기 힘든 구조로 되어 있고, 조직이 성장할수록 배포 대기시간이 비약적으로 증가하는 단점을 개선하기 위해 MSA로 전환하였으며

 

- 이를 통해 작은 서비스 단위로 개발/테스트/배포를 할 수 있어 비즈니스 성장을 가속화할 수 있었고, 서비스의 확장성과 안정성을 적은 비용으로 빠르게 확보할 수 있었다.

 

 

 

II. MSA 구축에 대한 이해와 설계/구축/고려사항

 

 

1. 마이크로 서비스 아키텍처의 개념

 

- 마이크로 서비스 아키텍처는 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성요소 간의 관계를 정의한 아키텍처이다.

 

- 하나의 애플리케이션을 구성함에 있어 분할된 다수의 서버 또는 컨테이너를 통해 애플리케이션 기능뿐만 아니라 데이터까지 분리하여 격리된 독립된 환경으로 구성되는 점이 특징이다.

 

 

 

 

[ 이미지출처: redhat '마이크로서비스란?' ]

 

 

 

2. MSA 전환 시 사전준비 및 설계

 

 

■ 마이크로 서비스 아키텍처 설계의 사전준비

 

 

○ 마이크로 서비스 아키텍처 전환의 자가점검

 

- 적절하게 구조화된 모노리틱 애플리케이션을 구축하였는가?

- 마이크로 서비스로 충족해야 하는 요구사항을 결정하였는가?

- 마이크로 서비스를 활용할 수 있도록 팀을 재정비하였는가?

- DevOps 및 CI/CD에 대한 모범 사례를 도입하였는가?

- 애플리케이션 내에서 비즈니스 범위를 식별하였는가?

- 마이크로 서비스 오케스트레이션 및 관리도구와 프로세스를 구현하였는가?

 

 

○ 규모 확장성(scalability)에 대한 고려

 

 

 

 

[ Scale Cube 모델을 통한 서비스의 분할 ]

 

 

- 규모의 확장성을 결정하기 위해 scale cube 모델(위 그림)을 많이 사용

 

- X축 - Horizontal duplication: 동일한 이미지를 다수 복사해서 많은 업무를 처리

 

- Y축 - Functional decomposition: 기능을 분해해서 여러 머신에서 돌아가게 설계하여 많은 업무를 처리

 

- Z축 - Data Partitioning: 데이터베이스를 여러 서버로 분할. 하나의 큰 데이터베이스에서 데이터를 찾는 것보다 작은 데이터베이스에서 찾는 것이 효율적. DB 샤딩(Sharding) 자가 점검을 완료하고, 기존 시스템에서 어느 부분을 분할할지 결정하면 모노리틱 시스템을 마이크로 서비스 아키텍처로 전환하기 위한 사전준비 단계가 완료되고, 기존 서비스를 마이크로 서비스로 분할하는 단계를 수행하게 되는 것임

 

 

○ 마이크로 서비스 설계

 

 

[ 마이크로 서비스 설계 ]

 

 

 

 

■ 마이크로 서비스 아키텍처 설계

 

 

○ 마이크로 서비스 아키텍처 구성

 

- 환경설정: 시스템에서 참조해야 하는 환경변수 등을 별도의 저장소에서 관리하여 애플리케이션이 배포된 환경에 구애 받지 않고, 해당 환경에 적절한 환경정보들을 참조할 수 있는 기능을 제공하는 서비스

 

- 서비스 등록 및 감지: 마이크로 서비스가 시스템 등록되는 것을 자동으로 감지하여 서비스 게이트웨이가 자동으로 인지할 수 있게 지원하는 기능

 

- 서비스 게이트웨이: 요청을 받아서 해당 요청에 필요한 서비스로 연결해주는 역할을 수행. 클라이언트 관점에서는 서버에 접속하기 위한 관문이고, 서버 측면에서는 클라이언트 요청의 부하 분산과 대응하는 적절한 마이크로 서비스를 찾아주는 역할을 수행하는 것임

 

 

 

 

[ Euraka의 등록, 탐색, 연결 구조 ]

 

 

 

 

- 서킷 브레이커: 특정 서비스가 정상적으로 동작하지 않을 경우 다른 기능으로 대체 수행시켜 장애를 회피하는 기능. 최종 사용자 측면에서는 장애 상황을 인지할 수 없음

 

 

 

 

[ Circuit Breaker 패턴 구성 ]

 

 

 

 

- 큐잉 시스템: 마이크로 서비스간 데이터 전달이 필요하고 느슨한 결합을 위해서 MQ 사용. 업무 메시지 전달은 물론 로그 데이터도 메시지 시스템에 흘려 보내 처리할 수 있음. 서비스에 직접적인 부하를 주지 않고 필요한 서비스만 구독해서 사용하면 되는 것이 강점

- 폴리그랏 프로그래밍과 폴리그랏 퍼시스턴스: 서비스별로 목적과 특성에 맞는 언어와 기술을 사용. 회원관리는 RDB, 문서형태의 콘텐츠는 key-value DB를 이용. 각 서비스의 특성은 최대한 보장하고, 이에 맞는 기술 형태로 구성

 

 

 

○ API 설계

 

- 마이크로 서비스들은 각각 독립성을 가지고 동작하므로 각각 독립된 버전을 가지며, 서비스를 체계적으로 관리하기 위해서는 마이크로 서비스 API를 정의하고 생성하는 서비스 생성자와 서비스 를 사용하는 소비자 간에 잘 정의된 마이크로 서비스 API 체계가 필요하다.

 

- API 설계의 특징

 

 

 

 

 

 

 

○ 테스트 체계

 

- API 명세를 토대로 수행할 수 있어야 하며, 서버/클라이언트의 규격이 정상적인지를 판단하기 위해 시스템적으로 자동화 및 모니터링이 필수이다.

 

 

 

○ 지속적 통합 및 배포체계 설계

 

- 소스코드는 저장소에서 별도의 브랜치 형태로 관리하며, 파이프라인 전략과 자동화되고 시각화할 수 있는 체계가 필요하다.

 

- 지속적 통합 및 배포 프로세스

 

 

 

 

 

 

 

○ 모니터링 체계 설계

 

- 서비스 모니터링: 각 개별 서비스들의 상태정보가 모니터링되어야 함. 클라이언트의 요청을 실시간으로 모니터링하여 시각화하고, 개별 서비스의 응답지연이 발생할 때에는 즉시 해당 접근 경로를 차단시키고 다른 경로로 우회하도록 만드는 서킷 브레이크 기능과 상태 정보 등을 확인할 수 있도록 구성

- 데브옵스 모니터링: 마이크로 서비스 환경에서는 서비스의 개발과 배포 주기가 짧아지고 모니터링해야 할 대상도 많아지므로 운영측면에서 장점

 

 

 

■ 마이크로 서비스 아키텍처의 구현과 배포 - 애플리케이션 배포 관점에서의 고려사항

 

- 분할된 서비스가 많지 않다면 VM에 WAS Instance를 교차로 배치하여 효율성과 가용성을 확보하는 방법도 가능하지만

 

- 수백 개 이상의 마이크로 서비스를 운영할 때는 VM보다는 도커와 같은 컨테이너 기술을 고려하는 것이 서비스 관리, 고가용성 측면에서 유리한 면을 가지고 있다.

 

- 도커 이미지, 도커 레지스트리, 도커 네트워크 등의 에코시스템을 통해 마이크로 서비스의 생성과 배포, 실행이 가능하다.

 

 

 

■ 사례

 

- 도서주문 서비스의 MSA 구성 사례(도서주문 서비스 사례)

 

 

 

 

 

 

 

III. Immutable Infrastructure, Docker

 

 

- 마이크로 서비스 아키텍처에서는 응집도를 높이기 위해서 기능 설계, 구현, 배포 측면에서의 응집도를 위한 기능 간의 독립성을 확보할 수 있는 가상화 기술이 필요하다.

 

 

1. 하드웨어 가상화 기술

 

- 가상화(Virtualization) 기술은 가상 머신 기반과 리눅스 컨테이너 기반의 가상화 기술로 나누어질 수 있다.

 

- 가상 머신 기반의 가상화 방식(hosted / bare-metal) 모두 게스트 운영체제(OS)의 설치가 필요하다. 이 부분이 리눅스 컨테이너 기반 가상화 기술과 큰 차이를 보여준다.

 

- 가상머신과 컨테이너 비교

 

 

 

 

 

 

- 도커는 도커 클라이언

 

- 도커는 도커 클라이언트, 도커 이미지, 도커 데몬, 도커 레지스트리, 도커 네트워크와 오케스트레이션 및 모니터링이 가능한 에코 시스템으로 구성된다.

 

 

 

 

[ 도커 아키텍처 ]

 

 

 

- 도커 클라이언트: 도커 컨테이너를 관리하고 실행하기 위해 데몬과 상호 작용하는 Binary 파일로 CLI 기반이나 Remote API를 통해 관리한다.

 

- 도커 이미지: 유니온 파일 시스템 형식으로 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 파일로 만든 것으로서 상태 값을 가지지 않고 변하지 않는다. 이미지는 베이스 이미지(Base image)와 도커 이미지로 구분될 수 있다. 베이스 이미지는 리눅스 배포판의 커널을 제외한 영역을 이미지로 만들어 부팅할 때 최소한의 부하로 실행될 수 있고, 도커 이미지는 베이스 이미지 위에 필요한 라이브러리나 실행 파일 등을 추가하거나 불필요한 파일들을 삭제하여 만든 이미지이다. 운영체제로 본다면 이미지는 일종의 실행 파일과 유사하다.

 

- 도커 컨테이너: 이미지를 독립된 공간에 할당하여 실행한 런타임 객체로서, 운영체제의 라이브러리와 애플리케이션을 묶어 하나의 객체로 실행한다. 운영체제 측면에서는 프로세스와 유사하다.

- 도커 데몬: 호스트에 설치되어 클라이언트와 상호 작용하여 도커 컨테이너를 관리하는 프로세스이다.

- 도커 레지스트리: 도커 이미지를 관리할 수 있게 제공된 저장공간이다. 이 공간을 통해서 도커 이미지를 공유하고 실행 환경을 구축할 수 있다. 개발자가 도커 이미지를 도커 레지스트리에 업로드하면 이를 필요로 하는 시스템 담당자는 다운로드를 하여 필요한 환경을 구성할 수 있다. 만든 이미지를 많은 사람들과 공유할 수 있도록 깃허브와 비슷한 방식의 도커 허브(Docker hub)를 사용한 이미지 버전관리 및 이미지 공유가 가능하다.

- 도커 네트워크: 네트워크 터널링을 통해 다른 호스트 간의 컨테이너 간 데이터 전송을 위해 네트워크 오버레이 기술을 활용한 가상의 네트워크 환경이다. 외부 물리 네트워크에서 들어오는 연결은 물리 NIC에 연결되고 도커 내부 네트워크의 브리지 역할을 하는 도커 0에 연결된다.

도커 0는 도커 내부 컨테이너들의 virtual NIC와 연결되어 접속이 가능하다. NAPT 기능은 하나의 IP로 가상의 여러 IP 및 포트와 변환하는 기능으로, 이를 이용하여 특정 IP에 특정 포트 서비스 요청을 하면 사설 IP에 포트까지 다른 컨테이너에 연결이 가능하다.

- 오케스트레이션: 도커 컴포즈, 스웜, 쿠버네티스를 통해 멀티 컨테이너를 조직화하고 연결하는 기능으로 MSA 애플리케이션의 가용성과 로드밸런싱 기능을 구현한다.

 

 

 

3. 도커 기반의 마이크로 서비스 배포

 

- 도커는 이미지를 그대로 컨테이너로 유연하게 실행이 가능하고 컨테이너라는 표준성을 확보한 상태에서 배포가 진행되므로 동일하게 다양한 환경에서 배포가 가능하다.

 

- 도커 서비스 배포 과정

 

 

 

 

 

 

- 변경된 도커 이미지의 배포 시 서비스를 내리고 올려야 하기 때문에 서비스 중단의 단점이 발생한다.

 

- nginx와 haproxy를 이용한 로드밸런싱 기반의 카나리 배포와 블루그린 배포 유형을 통해 서비스의 잦은 변경과 배포에 유연하게 대응할 수 있도록, 자동화된 배포 전략을 잘 활용한 안정적인 서비스 운영이 필요하다.

 

 

 

IV. 결론

 

 

- MSA의 도입 및 구현은 시스템의 아키텍처 및 프로세스가 조직의 문화에 영향을 미치고, 도커와 같은 인프라가 뒷받침되어야 구현이 가능하기 때문에 MSA의 도입을 위해서는 조직문화, 인프라 등 다양한 방면에서 검토가 필요하다.

 

① MSA 인프라로 활용되는 도커의 경우, 사용 목적에 따라 데이터 저장 방식을 선택해야 한다.

 

② MSA 모델에 대한 디자인 수행 시 현업 종사자와 개발팀간 Context 공유를 위해 DDD(Domain Driven Design)를 적용해야 한다.

 

③ 개발과 운영 조직을 하나로 묶어 빠른 의사소통이 가능한 데브옵스(DevOps)를 적용해야 한다.

 

 

■ 마이크로 서비스는 서비스 크기가 작아지고 중앙에서 통합 및 조정하는 기능이 없어 서비스 연계시 복잡도가 증가하며, 마이크로 서비스 간 통신이 빈번해져 네트워크 자원을 많이 소모하며, 동일한 프로세스를 마이크로 서비스별로 구현하게 될 경우 중복된 노력을 할 가능성이 존재한다.

따라서 복잡도에 따른 관리의 노력을 줄이기 위한 자동화 도구를 최대한 활용하고, 서비스 간 중복을 최소화하여 자원소모를 줄이고, 서비스 간 경계를 잘 정의하기 위한 도메인 주도 설계 인력의 확보가 필요하다. 또한, 시장 환경의 변화에 따라 기업이 민첩하게 대응할 수 있도록 상호 조직적인 구조인지, 방해요소가 존재하는지를 검토하여 시장 환경에 유연하게 대응할 필요가 있다.