마이크로서비스 배포의 진화

https://developers.redhat.com/blog/2017/01/20/microservices-deployments-evolution/

안녕하세요, 오늘은 빌긴 이브리암님의 3년 전 글인 "마이크로서비스 배포의 진화"라는 내용을 번역해 보았습니다.

즐겁게 읽어 주셨으면 좋겠습니다. 매끄럽지 않은 내용이 있다면 피드백 주셔도 감사드리겠습니다!

 

https://twitter.com/bibryam

저자 Bilgin Ibryam님이 한국 독자들을 만나보고 싶어 합니다, Bilgin의 트위터 공간을 통해 만나보세요!

 

앞으로 더 지속될 마이크로서비스 트렌드

 

몇 년 전까지만 하더라도, 대다수의 소프트웨어 시스템은 모놀리틱한 구조로 되어 있었고, 배포 주기 또한 느렸습니다.

최근 몇 년간, 확장성과 탄력성, 장애와 변화의 속도에 최적화되어 있는 마이크로서비스로 이전하려는 뚜렷한 움직임이 있었습니다.

이런 트렌드는 클라우드와 컨테이너의 채택에 의해서 더욱더 강화되어 왔고, DevOps와 같은 업무 관행의 도입을 가능케 했습니다.

 

IT 업계에서의 트렌드

 

이러한 변화를 통해 배포할 서비스의 수가 폭등했고, 개발할 서비스의 수 역시 더 늘리는 결과를 초래했습니다.

이는 곧 마이크로서비스 이전의 도구와 기술로는 버티지 못할 것이 분명했습니다.

그리고 배포하는 서비스의 폭증으로 인해서 새로운 서비스들이 생겨났습니다.

이번 글을 통해서, 우리는 쿠버네티스와 같은 클라우드 네이티브 플랫폼이 어떻게 사람의 간섭을 최소화하여

더 큰 스케일의 마이크로서비스의 배포를 가능하게 하는지에 대해서 다룰 예정입니다.

 

클라우드 네이티브 배포 전략

 

셀프-서비스 환경

Local, Dev, Test, Int, Perf, Stage, Prod ... 는 개발 환경이지만, 도대체 개발 환경이란 게 무엇일까요?

보통 개발 환경을 대표하는 VM(virtual machine, 가상 머신)의 그룹이거나 단일의 VM을 말합니다.

 

예를 들면 , 

 

Local(로컬 환경)의 경우, 개발자의 노트북을 예로 들 수 있는데 사용자는 무언가를 실험해도 되고 부셔도 되는

완전한 형태의 자유를 갖습니다. 하지만 아직 "내 컴퓨터에서는 돌아가는데?" 신드롬을 피하기 위해서는

다른 환경과 비슷하게 구축해야 합니다.

 

Dev(개발 환경)는 모든 개발자로부터 비롯된 변화가 하나의 애플리케이션으로 통합된 최초의 환경입니다.

이는 서비스의 스냅샷 버전(사진 찍어서 기록하는 듯 서비스 관리)을 운영하고, 외부 종속성을 모방해왔으며,

대체로 꾸준한 변화의 틀을 깼습니다.

 

서비스가 배포되고 나면, Test(테스트 환경)와 같은 더욱 안정적인 환경으로 옮겨졌습니다.

이 환경은 좀 더 강력하고(아마도 하나의 vm보다는 더 강력), 외부 종속성을 모방하기보다 

더 많은 외부 서비스를 가질 수 있고, 그리고 이 서비스에 접근할 수 있는 테스터를 가질 수 있습니다.

 

개발 환경은 Int/Stage/Perf  같은 production 환경과 친숙해지는 반면에 더욱 크고, 더 많은 VM과 더 많은 외부 종속성 역시도 가능해졌습니다. 어떤 점에서는 우리는 아마도 격리가 가능한 리소스 공간을 갖고 Production 환경에서 테스트할 필요가 있을 수

있습니다.

 

이 모델을 통한 주된 어려움은 바로 개발 환경의 컨셉이 가상 머신들과 물리 공간에 매핑되어 이를 통한 변경이 느리다는 것입니다.

현존하는 개발 환경에 쉽게 리소스 프로파일을 변경할 수 없고, 새로운 개발 환경으로 바꿀 수 없고,  개발자 개인마다 즉각적인 새로운 환경을 제공할 수도 없습니다.

 

쿠버네티스에 의해 관리되는 개발 환경

 

쿠버네티스 네이티브 환경에서, 개발 환경은 독립되고, 리소스 컬렉션이라는 이름으로 관리되어 집니다.

예를 들어 8개의 VM 풀이 주어졌다고 가정한다면, 다양한 팀의 요구에 맞춰서 리소스 풀을 각기 다른 환경 인스턴스로 청크(작은 저장 공간, 파티션)로 묶어서 사용할 수 있습니다. 그리고 그러한 청크들은 VM에 매핑되지 않습니다.

즉, VM에 대한 요청이 있으면 하나의 명령만으로도 며칠 또는 몇 주 동안 대기하지 않고도 즉각적으로 환경을 만들고, 편집하고, 파괴할 수 있다는 뜻입니다. 이를 통해 팀은 변화하는 요구에 맞춰서 팀 자체적으로도 쉽고 빠른 환경 프로파일을 변경할 수 있습니다.

 

동적으로 배치된 애플리케이션

 

우리는 관리 환경을 위한 셀프서비스 플랫폼이 얼마만큼 새로운 개발자, 서비스, 프로젝트와 심지어 일시적으로 즉각적인 필요에 따라 커스텀한 배포 전략으로의 유입을 쉽게 도와주었는지 확인했습니다. 환경이 준비된 이후 작업은 개발 환경에서 마이크로서비스를 배치하기 위한 전략을 고르는 것입니다.

 

제가 좋아하는 마이크로서비스의 관련 서적은 샘 뉴먼의 "마이크로서비스 아키텍처 구축"이라는 책입니다.

이 책에서 샘은 마이크로서비스를 가능한 모든 각도에서 접근하는데, 이 중의 하나는 배포입니다.

배포 관련 챕터에서 저자는 호스트에 서비스를 매핑시키기 위한 몇 가지 전략을 제시하고 이의 장단점에 대해서 다룹니다.

 

서비스 / 호스트 간 매핑 전략

 

저는 또한 저의 저서인 "카멜 디자인 패턴"에서 이러한 접근이 얼마나 고통스러운 방법인지에 관해서도 기술한 바 있습니다.

기본적으로, 이러한 접근은 결국 모든 종류의 서비스와 호스트 종속성을 고려하여 서비스를 패키징하고 사용 가능한 호스트에 그룹화하는 방법을 선택하는 것으로 귀결됩니다.

 

다행히도, 산업이 정말 빠르게 변하고 있고, 컨테이너가 마이크로서비스의 패키징 기준으로 자리매김하고 있습니다.

당신의 서비스가 넷플릭스이고 10만 개가 넘는 아마존 EC2 인스턴스가 아니라면, 빠르게 각각의 서비스의 EC2 이미지를 구울 빠른 방법을 찾을 필요는 없습니다. 그리고 그냥 컨테이너를 사용하면 됩니다. 

넷플릭스조차도 AWS로 이전하고 나서 컨테이너를 실험하고, 오픈소스 스케줄링 소프트웨어를 개발하기까지 합니다.

그러니 더 이상 서비스당 VM도, 더 이상의 호스트에 매핑시킬 전략도 필요 없습니다.

 

대신에, 가능한 호스트 리소스와 서비스 요구사항과 종속성에 기반하여 당신의 클라우드 네이티브 플랫폼은 정책에 의해서 예측 가능한 방법에서 모든 서비스의 호스트를 찾을 것입니다.  이를 위해서는 각 서비스에 대한 이해와 스토리지, CPU, 메모리 등등의 내용에 대한 요구사항을 기술해 놓을 필요가 있습니다. 하지만, 이후에 얻을 수 있는 이점은 상당히 큽니다.

 

미리 각 서비스를 수동으로 조정하고 호스트를 할당하는 것이 아니라, 쿠버네티스 스케줄러는 서비스의 코레오그래피

(시스템의 각 구성 요소에 비즈니스 트랜잭션의 워크플로우, 출처 : 마이크로소프트 기술 페이지)를 수행하고

요청 시에 동적으로 호스트를 배치하여 이를 수행합니다.

 

보시다시피 VM/HOST의 개념은 여러 호스트로 확장할 때나 서비스가 동적으로 배치되면서 사라지게 됩니다.

우리는 우리의 개발 환경에 새겨지는 실제 호스트가 어디에 위치하는지 그리고 마이크로서비스가 어디에 배치되는지 이런 것들을 알고 싶지도 않고, 신경 쓰는 사람도 없습니다. (예측 가능한 퍼포먼스가 치명적인 경우이거나 공유 호스트 자원과 그 플랫폼이 회피해야 하는 경우를 제외하면 말이죠)

 

명시적 서비스 배포

 

우리는 최소한의 노력으로 셀프서비스 방식의 개발 환경을 프로비저닝 할 수 있고, 또한 환경에 서비스를 배치할 수도

있습니다. 하지만, 여러 인스턴스를 가진 서비스가 있다면, 어떻게 새로운 인스턴스를 배포할 수 있을까요?

제일 먼저 인스턴스를 중지하고, 업그레이드하고, 잘못되면 롤백하는 식으로 해야 할까요?

클라우드 네이티브 플랫폼(특히 쿠버네티스)은 이것에 대한 계획이 다 있습니다.

쿠버네티스의 배포 전략 개념은 서비스 업그레이드에 대한 방법을 기술합니다.

 

롤링 배포와 고정 배포

 

롤링 업데이트 배포 전략은 서비스 전체를 동시에 중단하는 대신, 한 파드를 한 번에 업데이트하여 제로 다운 타임을 보증합니다.

반면에 고정(혹은 재생성이라고 합니다.) 전략은 모든 서비스 인스턴스를 중단시키고, 순차적으로 새로운 버전을 구동시킵니다.

 

두 가지 사례배치는 모두 명시적으로 기배포된 애플리케이션에 대해서 이면에서 지속해서 업데이트를 할 것입니다.

 

추가적인 이점들

 

서비스의 전체 라이프 사이클을 관리하는 플랫폼을 보유한다면, 추가적인 배포에 관련한 이점들도 얻을 수 있습니다.

 

블루- 그린 배포와 카나리 배포

 

블루-그린 배포는 새로운 배포에 있을 수 있는 어떠한 문제점에 대해서도 재빠른 롤백을 취할수 있는 방법입니다.

 

카나리 배포는 모든 사용자에게 배포하기 전, 사용자의 작은 서브 셋만 변경함으로써 에 프로덕션 환경에서 새로운 소프트웨어를 도입하는 위험성을 줄이는 기술입니다.

 

이 두 가지 사례 모두 쿠버네티스를 사용하면, 인간 간섭을 최소로 줄이고 쉽게 적용할 수 있습니다.

 

 

셀프 힐링

 

클라우드 네이티브 플랫폼은 장애를 추적할 뿐 아니라, 대응하고 치료합니다.

쿠버네티스는 애플리케이션을 대상으로 주기적으로 헬스 체크를 시행하여 어떤 이상을 감지했을 때, 서비스를 재시작하고 더 나아가 필요하다면, 다른 더 건강한 호스트로 서비스를 옮깁니다.

 

오토 스케일링

 

셀프 힐링에 이어, 플랫폼은 서비스에 대한 오토 스케일링이 가능하고, 심지어 인프라에 대한 오토 스케일링 또한 가능합니다.

그것은 아주 강력한 특성으로 플랫폼에 일부 안티프레질 특성을 가져다줍니다.

 

DevOps와 안티프레질

 

쿠버네티스가 제공하는 모든 이점을 살펴보면, 저는 이러한 이점들이 기초 요소들과 추상화를 제공하고

규모의 마이크로서비스를 관리하는데 최적화되었다고도 할 수 있으리라 생각합니다.

이런 툴을 사용하면 팀과 회사는 DevOps와 같은 업무 관행을 실무에 적용하기 쉬워질 것이고, 안티 프레질에 대한 업무 프로세스를 개선하기 쉬워질 것입니다.

 

마치며

 

세상에 공짜는 없다

우리는 마이크로서비스 배포에 관련한 클라우드 네이티브 플랫폼의 많은 이점들을 살펴보았지만, 

의도적으로 이 글에서는 마이크로서비스에 관련한 어떠한 단점에 대해서도 언급하지 않았습니다.

예상하셨겠지만, 쿠버네티스에 대한 급격한 러닝 커브가 존재합니다.

또한 이런 애플리케이션들을 개발할 때의 패턴, 원칙, 프로세스와 업무 관행에 있어서 변화가 필요합니다.

그것이 기본적인 클라우드 네이티브 애플리케이션을 향한 움직임입니다.

 

변화는 피할 수 없다

 

너무 격하게 들릴지 모르겠지만 만약 마이크로서비스를 하고 계신다면, 그것도 규모의 마이크로서비스라면, 클라우드 네이티브 플랫폼(쿠버네티스와 같은)을 사용하는 것은 필수입니다.

 

변화할 필요는 없습니다. 생존은 의무가 아닙니다. - 윌리엄 에드워드 데밍(미국의 품질경영 권위자, 엔지니어, 교수)

 

만약 마이크로서비스 이전의 툴, 기술, 마이크로서비스를 개발하기 위한 이전의 업무 관행들을 사용하고 계신다면

이로 인해서 타격을 입을 것이고, 마이크로서비스가 동작하지 않을 수도 있습니다.

 

 

저자 소개

저자 빌긴 이브리암은 아파치 카멜의 커미터, 레드햇의 통합 아키텍트, 소프트웨어 장인이자 블로거입니다.

그는 오픈소스의 광신자, 분산 시스템과 메시징, 애플리케이션 통합에 열정적입니다.

Camel Design Patterns & Instant Apache Camel Message Routing books의 저자입니다.

 

 

PS, 롤링 업데이트, 카나리 배포, 블루 그린 등 배포 전략에 자세한 내용은 아래의 포스팅을 참고하세요!

덧붙여서 윌리엄 에드워드 데밍 같은 경우는 미국의 품질경영 권위자이면서 패전 후 일본의 경제를 선진국의 반열로 올리신 장본인이자 피터 드러커급의 경영인이라고 합니다.

 

그럼 다음 글을 통해 뵙겠습니다!

오늘도 좋은 하루 보내세요~

 

https://jflip.tistory.com/14?category=851729

[퀵랩] 고급 - 쿠버네티스 솔루션 01/08