12 www.iitp.kr

주간기술동향 2019. 3. 13.

*

김유성 공수재* 김선진** 박준한***

케이티 과장

이랜드시스템스 과장 *

지인시스템 차장 **

비즈니스온커뮤니케이션 차장 ***

I. 서론

서비스 아키텍처 관점에서 시계를 뒤로 돌려 10년 전으로 거슬러 올라가 보면 IT업계에서 가장

많이 들렸던 이야기는 SOA(Service Oriented Architecture, 서비스 지향 아키텍처)였다. 애플리

케이션을 서비스 단위로 분할하여 미들웨어(ex. ESB 등)를 사용하여 연결하자는 의미였다. 그 당시

모노리틱 아키텍처 형태로 사용했던 대부분의 아키텍처들은 수정 및 유지보수의 문제로 IT 환경변화

에 대처하기가 어려웠던 시간이었다.

물론, SOA를 도입하여 비즈니스 대처의 유연성과 민첩성이 월등하게 높아진 것은 사실이다.

하지만 시간이 지남에 따라 연결한 미들웨어가 SPOF(Single Point of Failure)로 부각되고 사람들

이 기대했던 것만큼의 효율성이 부각되지 않아 SOA가 시들해진 것은 분명하다. 하지만 SOA가

추구했던 서비스 지향이라는 관점은 오늘날에도 유효한 개념으로서 남아 있다.

IT 기술 발전의 시대적 관점에서 현재 시대는 모바일의 시대라고 불리고 있다. 시대별 기술 변화

를 살펴보면, 안정성을 중요시하는 엔터프라이즈 시대에서, 인터넷과 SNS로 대변되는 오픈소스

시대로, 그리고 현재는 API, 클라우드, NoSQL 등 경량화되고 쉽고 빠른 개발이 가능한 여러 가지

기술들을 활용하고 있다.

이와 같은 기술들의 활용은 시대의 변화를 대변하고 있다. 예전처럼 대용량의 서버를 기반으로

무거운 시스템을 유지하는 것은 기업의 ERP(Enterprise Resource Planning)와 같은 메인 시스

템 정도이다. 급속한 기술의 변화, 고객의 Needs의 변화, 기업의 비즈니스 환경의 변화 등 빠른

트렌드 변화로 이제는 빠른 배포, 출시, 업데이트가 빈번하게 일어나고 있다. 이에 따라 기업들은

* 본 내용은 김유성 과장(☎ 02-559-0822, yousungkim1216@gmail.com)에게 문의하시기 바랍니다.

** 본 내용은 필자의 주관적인 의견이며 IITP의 공식적인 입장이 아님을 밝힙니다.

MSA에 대한 이해와 컨테이너 기술의 활용 방안

ICT신기술

정보통신기획평가원 13

서비스를 구현함에 있어 낮은 비용의 클라우드와 배포가 간단한 스크립트 언어, 그리고 운영 효율화

와 자동화 등을 고려하고 있다. 시대의 흐름에 맞춰 스크럼(Scrum)과 같은 짧은 주기의 유연한

개발 방법론과 프로젝트 중심으로 한시적으로 구성되는 CFT(Cross Functional Team)를 기업의

민첩성을 높이기 위해 사용하고 있다. 이와 같은 시대 변화의 트렌드로 인해 서비스를 제공함에

있어 MSA(Micro Service Architecture)의 도입이 활발하게 이루어지고 있다.

최근 기업별 MSA 도입에 대한 동향을 살펴보면, 아마존의 경우 ‘Amazon Go’와 같은 줄 서지

않고 제품을 구매할 수 있는 식료품점 등을 통해 디지털 전환(Digital Transformation)을 가속화하

고 있는데, 신속하게 개별 서비스를 혁신하고 새로운 기술 기반의 서비스를 개발 및 통합하기 위해

마이크로 서비스 아키텍처를 적용하였다.

Netflix는 1억 1,800만 명의 가입자에게 1일 1억 이상의 비디오 스트리밍을 제공하고 있는데,

높은 재생 품질을 다운타임 없이 서비스하는 것을 목표로 마이크로 서비스 아키텍처를 적용하였다.

마이크로 서비스에 적합한 조직 구성, 클라우드 기반 서비스 생명주기 관리 등을 고려하였으며,

이를 위해 Service Discovery, Circuit Breaker, API Gateway 등의 기술을 도입하였다. 또한,

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

국내 소셜 커머스 업체인 쿠팡은 부분 장애가 서비스 전체 장애로 이루어지고, 서비스가 부분적으

로 scale-out하기 힘든 구조로 되어 있고, 조직이 성장할수록 배포 대기시간이 비약적으로 증가하

는 단점을 개선하기 위해 MSA로 전환하였으며, 이를 통해 작은 서비스 단위로 개발/테스트/배포를

할 수 있어 비즈니스 성장을 가속화할 수 있었고, 서비스의 확장성과 안정성을 적은 비용으로 빠르게

확보할 수 있었다.

본 고에서는 이와 같은 흐름에 맞추어 MSA를 구축하기 위한 설계 및 주요기술들을 살펴보고,

MSA 구현 시 잘 어울리는 컨테이너 기술 중 하나인 도커(Docker)를 활용하는 방법을 살펴보고자

한다.

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

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

마이크로 서비스 아키텍처는 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트

웨어의 구성과 구성요소 간의 관계를 정의한 아키텍처이다. 하나의 애플리케이션을 구성함에 있어

14 www.iitp.kr

주간기술동향 2019. 3. 13.

분할된 다수의 서버 또는 컨테이너를 통해 애플리케이션 기능뿐만 아니라 데이터까지 분리하여 격리

된 독립된 환경으로 구성되는 점이 특징이다.

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

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

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

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

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

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

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

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

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

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

시스템을 MSA 형태로 구성한다는 것은 많은 장점과 단점을 동시에 가지고 가게 된다. 규모의

확장성을 결정하기 위해 scale cube 모델을 많이 사용하게 되며, 각 방향에 대한 의미는 [그림

1]과 같다

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

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

업무를 처리

Z축 - Data Partitioning: 데이터베이스를

여러 서버로 분할. 하나의 큰 데이터

베이스에서 데이터를 찾는 것보다 작

은 데이터베이스에서 찾는 것이 효율

적. DB 샤딩(Sharding) 자가 점검

을 완료하고, 기존 시스템에서 어느

부분을 분할할지 결정하면 모노리틱

시스템을 마이크로 서비스 아키텍처

로 전환하기 위한 사전준비 단계가

<자료> Scale Cube 모델을 통한 서비스의 분할, 스케일 큐브(크리스리차드슨). 2014.4, p.58

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

ICT신기술

정보통신기획평가원 15

완료되고, 기존 서비스를 마이크로 서비스로 분할하는 단계를 수행하게 되는 것임

(3) 마이크로 서비스 설계

마이크로 서비스 설계가 완료되면 분할된 서비스를 효율적으로 구축/운영하기 위한 설계를 진행

할 수 있다.

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

(1) 마이크로 서비스 아키텍처 구성

환경설정과 서비스 등록 및 감지 서비스는 마이크로 서비스의 정보들을 동적으로 관리할 수 있게

지원한다. 서비스 게이트웨이는 클라이언트 요청을 해석하여 가용성을 유지할 수 있게 부하 분산과

적절한 서비스로 연결해주는 라우팅 기능을 지원한다. 또한, 마이크로 서비스의 요청 상태와 서킷

브레이커 기능을 실시간으로 모니터링할 수 있게 지원한다.

- 환경설정: 시스템에서 참조해야 하는 환경변수 등을 별도의 저장소에서 관리하여 애플리케이션

이 배포된 환경에 구애 받지 않고, 해당 환경에 적절한 환경정보들을 참조할 수 있는 기능을

제공하는 서비스

- 서비스 등록 및 감지: 마이크로 서비스가 시스템 등록되는 것을 자동으로 감지하여 서비스

게이트웨이가 자동으로 인지할 수 있게 지원하는 기능

- 서비스 게이트웨이: 요청을 받아서 해당 요청에 필요한 서비스로 연결해주는 역할을 수행. 클라

<자료> 자바기반의 마이크로 서비스 이해와 아키텍처 구축하기, 2018.10.19. pp.15-20.

[그림 2] 마이크로 서비스 설계

16 www.iitp.kr

주간기술동향 2019. 3. 13.

이언트 관점에서는 서버에 접속하기 위한 관문이고, 서버 측면에서는 클라이언트 요청의 부하

분산과 대응하는 적절한 마이크로 서비스를 찾아주는 역할을 수행하는 것임

- 서킷 브레이커: 특정 서비스가 정상적으로 동작하지 않을 경우 다른 기능으로 대체 수행시켜

장애를 회피하는 기능. 최종 사용자 측면에서는 장애 상황을 인지할 수 없음

- 큐잉 시스템: 마이크로 서비스간 데이터 전달이 필요하고 느슨한 결합을 위해서 MQ 사용.

업무 메시지 전달은 물론 로그 데이터도 메시지 시스템에 흘려 보내 처리할 수 있음. 서비스에

직접적인 부하를 주지 않고 필요한 서비스만 구독해서 사용하면 되는 것이 강점

- 폴리그랏 프로그래밍과 폴리그랏 퍼시스턴스: 서비스별로 목적과 특성에 맞는 언어와 기술을

사용. 회원관리는 RDB, 문서형태의 콘텐츠는 key-value DB를 이용. 각 서비스의 특성은

최대한 보장하고, 이에 맞는 기술 형태로 구성

(2) API 설계

마이크로 서비스들은 각각 독립성을 가지고 동작하므로 각각 독립된 버전을 가지며, 서비스를

체계적으로 관리하기 위해서는 마이크로 서비스 API를 정의하고 생성하는 서비스 생성자와 서비스

를 사용하는 소비자 간에 잘 정의된 마이크로 서비스 API 체계가 필요하다.

<자료> Circuit Breaker 패턴 구성, MSA 서비스 개발팀 이야기, 2018. 3, p.1.

[그림 4] Circuit Breaker 패턴 구성

<자료> Euraka의 등록, 탐색, 연결 구조, 스프링클라우드 config-server 이야기, 2016. 7, p.1.

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

ICT신기술

정보통신기획평가원 17

[표 1] API 설계의 특징

(3) 테스트 체계

API 명세를 토대로 수행할 수 있어야 하며, 서버/클라이언트의 규격이 정상적인지를 판단하기

위해 시스템적으로 자동화 및 모니터링이 필수이다.

(4) 지속적 통합 및 배포체계 설계

소스코드는 저장소에서 별도의 브랜치 형태로 관리하며, 파이프라인 전략과 자동화되고 시각화

구분 세부특징 상세설명

버전관리- 하위 호환성- 독립된 버전

- 서비스명/버전/리소스 형태로 구성- ?v=2.0 포멧- Api.server.com/{서비스명}/{버전}/{리소스}

REST API- Resource- Verb- Representations

- 자원을 정의(HTTP URI)- 자원에 대한 행위를 정의(HTTP Method)- 자원에 대한 행위의 내용을 정의(HTTP Message Pay Load)

<자료> swagger UI를 통한 API테스트, [Swagger] RESTful API 문서 만들기, 2017. 4, p.1

[그림 5] swagger UI를 통한 API 테스트

<자료> 아마존 웹서비스, 지속적 통합 및 배포 프로세스, 2018. 4.

[그림 6] 지속적 통합 및 배포 프로세스

18 www.iitp.kr

주간기술동향 2019. 3. 13.

할 수 있는 체계가 필요하다.

(5) 모니터링 체계 설계

- 서비스 모니터링: 각 개별 서비스들의 상태정보가 모니터링되어야 함. 클라이언트의 요청을

실시간으로 모니터링하여 시각화하고, 개별 서비스의 응답지연이 발생할 때에는 즉시 해당 접

근 경로를 차단시키고 다른 경로로 우회하도록 만드는 서킷 브레이크 기능과 상태 정보 등을

확인할 수 있도록 구성

- 데브옵스 모니터링: 마이크로 서비스 환경에서는 서비스의 개발과 배포 주기가 짧아지고 모니

터링해야 할 대상도 많아지므로 운영측면에서 장점

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

마이크로 서비스는 독립된 서비스이고, 이를 실행하기 위한 환경은 VM과 컨테이너 기술을 고려

할 수 있다. 분할된 서비스가 많지 않다면 VM에 WAS Instance를 교차로 배치하여 효율성과

가용성을 확보하는 방법도 가능하지만, 수백 개 이상의 마이크로 서비스를 운영할 때는 VM보다는

도커와 같은 컨테이너 기술을 고려하는 것이 서비스 관리, 고가용성 측면에서 유리한 면을 가지고

있다. 도커 이미지, 도커 레지스트리, 도커 네트워크 등의 에코시스템을 통해 마이크로 서비스의

생성과 배포, 실행이 가능하다.

<자료> 히스트릭스 대시보드 사례, Hystrix - Circuit Breaker 실전, 2017. 3, p.1.

[그림 7] 서비스 모니터링을 위한 히스트릭스 대시보드 사례

ICT신기술

정보통신기획평가원 19

III. Immutable Infrastructure, Docker

기업의 비즈니스 변화에 기민하게 응답하기 위해서 마이크로 서비스로 구성된 마이크로 서비스

아키텍처는 수평적 확장이 가능한 탄력적 아키텍처(Resilience architecture)로 설계되어야 한다.

빠르고 급격한 변화에 대한 시간적, 경제적 비용을 낮추기 위해 프로그램의 효율적인 설계, 구축,

배포, 운영이 필요하다. 이에 따라 잘 구분된 기능을 모듈 별로 분할하고 추상화하여 소프트웨어의

성능을 향상시키고 유지보수를 효과적으로 하기 위한 SW 설계 및 구현 기법이 진행되어야 한다.

모듈의 독립성을 나타내는 개념으로 모듈 내부 구성원 간의 연관도인 응집도는 높아야 하고, 모듈

<자료> 자바기반의 마이크로 서비스 이해와 아키텍처 구축하기, 2018.10.19. pp.15-20.

[그림 8] 도서주문 서비스의 MSA 구성 사례(도서주문 서비스 사례)

<자료> <웹진 165호 : 공학 트렌드> 프로젝트 수행 - 재사용 편, 소프트웨어공학포털, 2016. 2. 28, p.5.

[그림 9] 모듈성을 높이기 위한 응집도와 결합도

20 www.iitp.kr

주간기술동향 2019. 3. 13.

내부가 아닌 외부의 모듈과의 연관도를 의미하는 결합도는 낮아야 한다.

응집도는 높을수록 하나의 기능만 수행하는 모듈이 되어야 하며, 결합도는 낮을수록 모듈 간 연관

은 자료 레벨의 간단한 변수의 파라미터로 교환하는 형태가 필요하고, 이를 위해 MSA에서는 API

게이트웨이와 REST 기반의 메시지 교환, 그리고 비동기 방식의 메시지 큐를 사용한다. 마이크로

서비스 아키텍처에서는 응집도를 높이기 위해서 기능 설계, 구현, 배포 측면에서의 응집도를 위한

기능 간의 독립성을 확보할 수 있는 가상화 기술이 필요하다.

1. 하드웨어 가상화 기술

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

수 있다. 가상 머신 기반의 가상화는 호스트(hosted) 방식과 베어 메탈(bare-metal) 방식을 사용

하며, 가상화 방식 모두 게스트 운영체제(OS)의 설치가 필요하다. 이 부분이 리눅스 컨테이너 기반

가상화 기술과 큰 차이를 보여준다.

컨테이너 기술은 2000년부터 ‘FreeBSD Jail’, ‘Unix FreeBSD’, ‘리눅스LXC’의 하위 시스템

분할의 아이디어로 시작되었으며, 예전부터 사용되어 온 기술이다. 리눅스 컨테이너는 하나의 호스

트 운영체제 위에 여러 개의 격리된 시스템 환경을 구성할 수 있는 운영체제 수준의 가상화 기술이

다. 리눅스 컨테이너는 컨트롤그룹(cgroup)과 네임스페이스(namespace) 기능을 사용하여 운영

환경을 고립시키고 관리한다. 컨트롤그룹은 물리적인 하드웨어의 리소스를 프로세스 그룹 단위로

제어하는 기능이다. 컨트롤그룹을 통해 사용자는 CPU 시간, 시스템 메모리, 네트워크 대역폭과

같은 자원이나 이러한 자원의 조합을 실행중인 프로세스 간에 할당하는 것이 가능하다. 이를 사용하

<자료> 이재홍, 가장 빨리 만나는 Docker, 길벗, 2014. 11, pp.15-16.

[그림 10] 가상머신과 컨테이너 비교

ICT신기술

정보통신기획평가원 21

여 시스템 관리자는 시스템 자원 할당, 우선 순위 지정, 거부, 관리, 모니터링과 같은 제어가 가능하

다. 네임스페이스는 컨테이너 별로 격리된 공간을 가질 수 있도록 지원하는 기술이다. ‘PID’, ‘NET’,

‘MNT’, ‘UID’, ‘UTS’, ‘IPC’에 해당하는 시스템 구성 요소의 네임스페이스를 제공하여 이의 공간

별 할당 및 관리가 가능하다.

게스트 운영체제 유무의 차이로 성능, 배포, 운영 측면의 영향이 달라진다. 게스트 운영체제가

설치되지 않고, 프로세스 레벨의 분리가 가능한 컨테이너를 사용하는 가상화 방식은 성능 측면에서

게스트 운영체제로 인한 성능 저하가 발생하지 않기 때문에 경량화 가상화로 분류된다. 컨테이너를

생성하는 것은 단순히 프로세스를 시작하기 때문에 일반적인 프로세스의 실행과 다름 없이 빠르게

수행이 가능하다. init을 먼저 시작하거나 각종 데몬들을 실행할 필요 없이 필요한 프로세스만 존재

하는 환경으로 만들 수 있다. 그리고 이 컨테이너 기술 기반의 도커 가상화는 게스트 운영체제 없이

배포를 하기 때문에 설치된 이미지 자체의 용량에 따른 네트워크 부하 및 배포 시간을 고려했을

때 큰 장점을 보여준다. 컨테이너 기반의 인프라를 사용하기 때문에 다양한 환경에 대한 종속성을

고민할 필요 없이 운영이 가능하다. 일반적으로 Product/QA/Dev 환경의 차이로 운영 전환 시

복잡한 문제가 발생하며 이를 해결하기 위해 같은 작업을 여러 번 실행 하더라도 같은 결과로 수렴되

는 멱등성을 갖춘 Immutable infrastructure가 필요하다. 이를 실현하는 대표적인 기술이 컨테이

너 기반의 도커 가상화이다.

2. 도커의 개념과 구성요소

도커는 리눅스 컨테이너(LXC)를 기반으로 시작해서 LXC 작업과 개선된 개발자 툴을 결합하여

컨테이너의 사용자 친화성을 높였고 이를 통해 대중이 쉽게 이용할 수 있게 만든 오픈소스 플랫폼이

다. 0.9 버전 이후부터 직접 자체적으로 만든 libcontainer 기술을 사용했다. 도커는 도커 클라이언

트, 도커 이미지, 도커 데몬, 도커 레지스트리, 도커 네트워크와 오케스트레이션 및 모니터링이 가능

한 에코 시스템으로 구성된다.

- 도커 클라이언트: 도커 컨테이너를 관리하고 실행하기 위해 데몬과 상호 작용하는 Binary 파일

로 CLI 기반이나 Remote API를 통해 관리한다.

- 도커 이미지: 유니온 파일 시스템 형식으로 필요한 프로그램과 라이브러리, 소스를 설치한 뒤

파일로 만든 것으로서 상태 값을 가지지 않고 변하지 않는다. 이미지는 베이스 이미지(Base

image)와 도커 이미지로 구분될 수 있다. 베이스 이미지는 리눅스 배포판의 커널을 제외한

영역을 이미지로 만들어 부팅할 때 최소한의 부하로 실행될 수 있고, 도커 이미지는 베이스

22 www.iitp.kr

주간기술동향 2019. 3. 13.

이미지 위에 필요한 라이브러리나 실행 파일 등을 추가하거나 불필요한 파일들을 삭제하여

만든 이미지이다. 운영체제로 본다면 이미지는 일종의 실행 파일과 유사하다.

- 도커 컨테이너: 이미지를 독립된 공간에 할당하여 실행한 런타임 객체로서, 운영체제의 라이브러

리와 애플리케이션을 묶어 하나의 객체로 실행한다. 운영체제 측면에서는 프로세스와 유사하다.

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

스이다.

- 도커 레지스트리: 도커 이미지를 관리할 수 있게 제공된 저장공간이다. 이 공간을 통해서 도커

이미지를 공유하고 실행 환경을 구축할 수 있다. 개발자가 도커 이미지를 도커 레지스트리에

업로드하면 이를 필요로 하는 시스템 담당자는 다운로드를 하여 필요한 환경을 구성할 수 있다.

만든 이미지를 많은 사람들과 공유할 수 있도록 깃허브와 비슷한 방식의 도커 허브(Docker

hub)를 사용한 이미지 버전관리 및 이미지 공유가 가능하다.

- 도커 네트워크: 네트워크 터널링을 통해 다른 호스트 간의 컨테이너 간 데이터 전송을 위해

네트워크 오버레이 기술을 활용한 가상의 네트워크 환경이다. 외부 물리 네트워크에서 들어오

는 연결은 물리 NIC에 연결되고 도커 내부 네트워크의 브리지 역할을 하는 도커 0에 연결된다.

도커 0는 도커 내부 컨테이너들의 virtual NIC와 연결되어 접속이 가능하다. NAPT 기능은

하나의 IP로 가상의 여러 IP 및 포트와 변환하는 기능으로, 이를 이용하여 특정 IP에 특정

포트 서비스 요청을 하면 사설 IP에 포트까지 다른 컨테이너에 연결이 가능하다.

- 오케스트레이션: 도커 컴포즈, 스웜, 쿠버네티스를 통해 멀티 컨테이너를 조직화하고 연결하는

기능으로 MSA 애플리케이션의 가용성과 로드밸런싱 기능을 구현한다.

<자료> Docker docs, Docker Overview part, Docker architecture, 2019, p.10.

[그림 11] 도커 아키텍처

ICT신기술

정보통신기획평가원 23

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

도커의 특징인 확장성, 표준성을 활용하여 마이크로 서비스의 유연하고 탄력적인 서비스 배포가

가능하다. 도커는 이미지를 그대로 컨테이너로 유연하게 실행이 가능하고 컨테이너라는 표준성을

확보한 상태에서 배포가 진행되므로 멱등성을 보장할 수 있도록 동일하게 다양한 환경에서 배포가

가능하다.

[표 2] 도커 서비스 배포 과정

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

다. nginx와 haproxy를 이용한 로드밸런싱 기반의 카나리 배포와 블루그린 배포 유형을 통해 서비

스의 잦은 변경과 배포에 유연하게 대응할 수 있도록, 자동화된 배포 전략을 잘 활용한 안정적인

서비스 운영이 필요하다.

Ⅳ. 결론

본 고에서는 실무적인 관점에서의 MSA 기술과 도커를 활용한 MSA에 대하여 알아 보았다.

<자료> 초보를 위한 도커 안내서 - 도커란 무엇인가?, 2017. 1, p.10.

[그림 12] 도커 서비스 배포 과정

배포 과정 설명 비고

① 이미지 생성- 이미지 기반의 컨테이너를 생성하기 때문에 원천 소스인 이미지의 생성과 저장

과정 필요(Dokerfile을 통해 실행)- docker build

② 이미지 업로드 - 생성된 이미지는 도커 레지스트리, 도커 허브에 저장 - docker push

③ 이미지 다운로드 - 업로드된 이미지를 레지스트리로부터 운영을 수행하는 호스트로 다운로드 수행 - docker pull

④ 컨테이너 실행- 내려 받은 이미지를 컨테이너로 실행- 컨테이너 조합이 많아질 경우, 도커 컴포즈(Compose)를 이용하여 컨테이너

설정 값과 의존성 확인하여 실행

- docker run

24 www.iitp.kr

주간기술동향 2019. 3. 13.

MSA는 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리할 수 있어 애플

리케이션 변경이 용이하고, 효율적인 자원 사용이 가능하다는 장점이 있다. 그러나 시스템의 아키텍

처 및 프로세스가 조직의 문화에 영향을 미치고, 도커와 같은 인프라가 뒷받침되어야 구현이 가능하

기 때문에 MSA의 도입을 위해서는 조직문화, 인프라 등 다양한 방면에서 검토가 필요하다.

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

한다. 도커의 저장 방식은 volume, bind mount, tmpfs의 3가지 방식이 존재한다. volume 방식

은 도커가 관리하는 호스트 파일 시스템의 일부에 데이터가 저장되어 Non-Docker 프로세스들이

파일 시스템의 해당 부분을 수정할 수 없게 하여 데이터를 도커 내에 존속시킨다. bind mount

방식의 경우는 데이터를 호스트 파일 시스템 어디에든 저장하는 것이 가능하다. tmpfs mount

방식은 호스트 시스템의 메모리에만 데이터가 저장되며 호스트 파일 시스템에는 저장되지 않는다.

bind mount 방식의 경우 Contatiner에서 실행 중인 프로세스들이 호스트 파일 시스템의 중요한

시스템 파일에 접근 가능하며, 디렉토리 생성, 수정, 삭제 명령을 통해 변경이 가능하므로 호스트

시스템의 Non-Docker 프로세스들에게 충돌이 발생하거나 보안에 영향을 줄 수 있어 bind mount

방식보다는 volume 기법을 권장한다.

두 번째, MSA 모델에 대한 디자인 수행 시 현업 종사자와 개발팀간 Context 공유를 위해 DDD

(Domain Driven Design)를 적용해야 한다. 구축 대상 시스템의 비즈니스 업무와 실제 비즈니스가

어떻게 돌아가는지를 파악하기 위해 UML 등의 모델을 이용한다. 현업 종사자, 개발팀, 디자인팀

간에 명확한 의사소통을 수행하며, 용어가 정의될 때마다 용어사전을 각종 산출물이나 회의시간에

활용하여 혼동이 발생하지 않도록 해야 한다.

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

야 한다. 기존의 모노리틱(monolitic) 아키텍처는 애플리케이션의 일정 부분을 고치더라도 전체를

다시 빌드하고 배포하는 변경주기를 갖고 있어 시간이 지남에 따라 모듈화하기가 어려워지는 반면

에, 마이크로 서비스 아키텍처는 복잡한 대규모 시스템을 간단하고 독립적인 단위로 결합 해제하므

로 애플리케이션에 대한 이해와 개발 및 테스트가 용이하다. 이러한 마이크로 서비스 아키텍처를

구현하기 위해 조직문화에 DevOps를 적용하면 협업, 표준화, 자동화를 통해서 개발조직과 운영조

직간 협업과 의사소통이 가능해진다.

본 고에서는 마이크로 서비스에 대한 실무적 적용 방안에 대해 검토하였고, 이를 통해 마이크로

서비스에 대한 특성을 파악하였다.

마이크로 서비스는 서비스 크기가 작아지고 중앙에서 통합 및 조정하는 기능이 없어 서비스 연계

시 복잡도가 증가하며, 마이크로 서비스 간 통신이 빈번해져 네트워크 자원을 많이 소모하며, 동일한

ICT신기술

정보통신기획평가원 25

프로세스를 마이크로 서비스별로 구현하게 될 경우 중복된 노력을 할 가능성이 존재한다.

따라서 복잡도에 따른 관리의 노력을 줄이기 위한 자동화 도구를 최대한 활용하고, 서비스 간

중복을 최소화하여 자원소모를 줄이고, 서비스 간 경계를 잘 정의하기 위한 도메인 주도 설계 인력의

확보가 필요하다. 또한, 시장 환경의 변화에 따라 기업이 민첩하게 대응할 수 있도록 상호 조직적인

구조인지, 방해요소가 존재하는지를 검토하여 시장 환경에 유연하게 대응할 필요가 있다.

[ 참고문헌 ]

[1] 자바기반의 마이크로 서비스 이해와 아키텍처 구축하기, 2018. 10. 19. pp.15-20.

[2] Apache Software Foundation, 카프카 클러스터 구조, 2017.

[3] 초보를 위한 도커 안내서 - 도커란 무엇인가?, 2017. 1.

[4] Hystrix - Circuit Breaker 실전, 히스트릭스 대시보드 사례, 2017. 3.

[5] Digital Labs Tech, [Docker 기본(5/8)] Volume을 활용한 Data 관리, 2018. 9.

[6] [커버스토리] 데브옵스와 마이크로 서비스, 컴퓨터월드., 2017. 4.

[7] Circuit Breaker 패턴 구성, MSA 서비스 개발팀 이야기, 2018. 3.

[8] API 게이트웨이를 이용한 설계, MSA 아키텍처 구현을 위한 API게이트웨이의 이해, 2015. 3.

[9] 크리스 리차드슨, Scale Cube 모델을 통한 서비스의 분할, 스케일 큐브, 2014. 4.

[10] 소프트웨어공학포털, 프로젝트 수행 - 재사용 편, <웹진 165호 : 공학 트렌드> 2016. 2. 28.

[11] 이재홍, 가장 빨리 만나는 Docker, 길벗, 2014. 11, pp.15-16.

[12] Docker docs, Docker Overview part, Docker architecture, 2019.

[13] 이충섭, 초보를 위한 도커 안내서 - 이미지 만들고 배포하기, 2017. 2.

[14] IT월드, 도커와 도커 컨테이너 이해, 2018. 9.

[15] swagger UI를 통한 API테스트, [Swagger] RESTful API 문서 만들기, 2017. 4.

[16] 아마존 웹서비스, 지속적 통합 및 배포 프로세스, 2018. 4.

[17] 가상화(Virtualization)의 내부 기술, 가상화의 이해: 가상화기술 ABC, 2008. 6.

[18] Euraka의 등록, 탐색, 연결 구조, 스프링클라우드 config-server 이야기, 2016. 7.