마이크로 서비스 : 외부 아키텍처 : 인프라, 플랫폼, DevOps : 개념, 정의, 개요

인프라 영역

MSA에서 인프라 영역은 클라우드 환경을 의미합니다. 인프라로서의 서비스, 즉 IaaS, 플랫폼으로서의 서비스, 즉 Paas로 나눠집니다. 힘들게 구축했던 인프라를 세계적인 플랫폼 사업자들이 자동화된 기능으로 제공합니다. 예를 들면 시스템의 자원 구성, 할당, 관리, 모니터링 등 일련의 작업들을 몇 번 만의 버튼 클릭만으로 자동화, 시각화해서 제공하고 있습니다.

인프라 영역에서 클라우드 사업자가 제공하는 IaaS를 선택할지, 기존 베어 메탈 장비나 가상 머신인 VM을 선택할지 결정해야 합니다. 그다음 위에 플랫폼 영역에서는 마찬가지로 클라우드 사업자가 제공하는 Paas를 선택할지 또는 직접 오픈 소스로 프라이빗한 Paas를 구축할지 결정해야 합니다.

각각의 관계가 어떤 것을 선택할지라도 유연하게 결합할 수 있습니다. 각 제품들이 상호 독립적이나 호환되도록 모두 유연한 구조로 만들기 때문에 가능합니다.

 

 

서비스가 배포되는 위치

요즘의 추세는 이렇게 유연성이 소프트웨어의 필수 요소가 되고 있습니다. 플랫폼 영역에서는 가상 머신과 컨테이너를 기반으로 한 Paas 제품을 놓고 선택에 대한 고민을 합니다. 그 차이점을 살펴보면 가상화는 하이퍼바이저라는 소프트웨어를 이용해서 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술입니다.

반면에 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성합니다. 즉, 게스트OS가 있느냐 없느냐가 가장 큰 차이입니다. 가상화는 게스트 운영체제 설치와 관련 라이브러리 설치 같은 오버헤드가 발생하게 됩니다. 따라서 마이크로서비스 같은 작은 서비스를 패키지하고 배포하기에 컨테이너가 더 적절합니다.

가장 대표적인 컨테이너 기술로는 필요한 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커 컨테이너가 가장 유명하고 많이 쓰이고 있습니다.

 

 

pass

만약 컨테이너 기술을 선택했다면 이런 컨테이너를 관리하기 위한 기술 또한 필요합니다. 이런 기술을 컨테이너 오케스트레이션이라고 합니다. 구글이 도커 컨테이너 관리 기술을 오픈한 쿠버네티스 가장 인기입니다. 쉽게 쿠버네이트로 프라이빗한 Paas 환경을 구축할 수 있기 때문입니다.

 

 

DevOps

다음은 마이크로서비스를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 DevOps 환경입니다. DevOps는 개발과 운영이 분리되지 않은 개발과 동시에 운영을 할 수 있는 조직, 그 문화를 말하기도 합니다.

여기서는 그런 개발과 운영이 동시에 진행 가능하도록 빠르고 높은 품질로 소프트웨어를 개발할 수 있게 지원해 주는 빌드, 테스트, 배포, 자동화 환경을 뜻합니다.

처음에 개발자가 개발 환경에서 컴파일하고 수동으로 테스트하고 오류를 수정하고 운영 환경 전에 스테이지 환경에서 다시 수동으로 테스트하고 다시 오류를 수정합니다. 그다음에 배포 승인을 받고 배포 담당자에 의해 운영 환경에 배포하는 식으로 정말 많은 시간이 흐르게 됩니다.

또한 마지막에 배포를 처리하는 이런 빌드, 배포 담당자는 보통 밤새워 진행하는 경우가 많이 있었습니다. 당연히 이런 환경에서는 속도가 날 수가 없습니다. 그래서 이런 활동을 자동화하여야 합니다.

 

마이크로 서비스 : 외부 아키텍처 : 인프라, 플랫폼, DevOps : 개념, 정의, 개요

 

우선 하단에 배포의 타깃이 되는 인프라와 플랫폼이 있습니다. 보통 클라우드 환경에서 배포를 하게 되면 Paas가 될 수 있습니다. 개발자가 형상 관리 도구에 소스 코드를 컴파일하면 빌드, 배포 작업이 되는 것으로 표현되고 있습니다.

 

 

CI

자동화된 빌드, 배포 작업을 보통 CICD라고 합니다. CI는 Continuous Integration, 지속적 통합이라고 합니다. 

즉, 오랜 시간 걸리는 빌드를 매일 자동화하여 수행한다면 개발 생산성이나 코디의 품질이 높아집니다. 개발자들이 퇴근 시에 매일 자신이 작성한 소스 코드와 그것을 테스트한 테스트 코드를 형상 관리해 체크인 합니다. 그럼 빌드 도구에서 매일 밤 형상 관리 서버의 코드를 가져와서 통합한 다음에 자동으로 빌드하고 테스트를 수행하게 됩니다.

그리고 그 결과를 레포트 문서로 남기고 빌드 된 소스를 실행 환경에 자동으로 배포해 놓습니다. 그렇게 하면 다음날에 테스터가 실행 환경에서 테스트를 바로 수행할 수 있는 것입니다.

또는 빌드 및 단위 테스트 결과를 개발자가 확인하고 만약 문제가 있다면 바로 소스 코드를 수정할 수 있습니다. 자동으로 통합하고 테스트하고 레포트로 남기는 활동을 CI라고 하고 실행 환경에 자동으로 배포하는 것을 CD라고 합니다.

 

 

CD

CD, 즉 지속적 배포는 Continuous Delivery와 Continuous Deployment의 앞 두 글자를 의미합니다. 그 차이점을 살펴보면 지속적 딜리버리, 지속적 배포는 빌드된 소스 코드의 실행 파일을 실행 환경 반영 전까지 배포하는 방식입니다.

실행 환경 반영을 위해서는 승인 및 배포 담당자의 허가를 받아야 배포할 수 있으며 배포도 수동으로 처리합니다. 조금은 엄격한 배포 절차를 가지는 것입니다. Continuous Deployment는 소스 저장소에 빌드 된 소스 코드의 실행 파일을 실행 환경까지 자동으로 배포하는 방식입니다.

 

 

파이프 라인

파이프라인은 통합 및 배포까지 일련의 프로세스를 하나로 연계하여 자동화하고 시각화된 프로세스를 구축하는 것을 말합니다. 이러한 파이프라인도 어떠한 단계를 거칠지, 어떠한 도구로 구성할지를 설계해야 합니다.

빌드, 유닛 테스트, 정적 분석, 배포의 과정을 거치고 있습니다. 여기에 배포 전에 UI 테스트, 통합 테스트, 배포 승인 프로세스 등을 넣어서 추가 설계할 수도 있습니다. 그리고 이것을 위해 어떠한 도구들을 활용할지 결정하고 그 연계 정의를 해야 됩니다. 그런 과정이 빌드 배포 파이프라인 설계라고 합니다.