요약
- MSA 구성 요소와 MSA 패턴의 나머지 부분을 이해함.
- 인프라 구성요소
- 플랫폼 패턴
- 애플리케이션 패턴
- 서비스 유형별 대표적인 클라우드 서비스를 이해함.
- 마이크로서비스 운영과 관리를 위한 플랫폼 패턴에 대해 이해함.
- 데브옵스 인프라 구성
- 빌드/배포 파이프라인 설계
- 마이크로서비스 생태계와 운영 관리 요소의 탄생
- 마이크로서비스 관리/운영 패턴
메모
컨테이너 오케스트레이션
- 컨테이너 기술을 선택했다면, 컨테이너를 관리하기 위한 기술 또한 필요함.
- 컨테이너가 많아지면 그에 따라
- 컨테이너의 자동 배치 및 복제
- 장애 복구
- 확장 및 축소
- 컨테이너 간 통신
- 로드 밸런싱
- 이러한 기술을 컨테이너 오케스트레이션 이라고 함.
- 최근에는 구글이 자사의 도커 컨테이너 관리 노하우를 CNCF 재단에 제공해서 공개한 쿠버네티스가 가장 인기를 끌고 있음.
- 쿠버네티스를 이용하면 손쉽게 사설 컨테이너 플랫폼 환경을 구축할 수 있기 때문.
- 컨테이너 배포의 기본 단위에 해당하는 파드, 디플로이먼트, 레플리카 셋 정보를 확인하고 설정할 수 있는 PaaS UI를 제공함.
- 쿠버네티스는 다음과 같은 주요 기능을 제공함.
그 밖의 다양한 클라우드 인프라
- AWS, Azure, GCP 와 같은 CSP 사업자 모두 기존의 물리 서버, 네트워크, 스토리지, DB를 대체할 다양한 가상 서버, 가상 네트워크 및 가상 스토리지, 가상DB를 제공함.
- 이들은 퍼블릭/프라이빗 간, 가상/물리 레거시 간에 모두 가능함.
- 따라서 클라우드 인프라 선택지는 다양함.
- 처음에 클라우드 서비스 제품군을 접하면 각 벤더가 위와 같이 매우 다양한 제품군을 제공하므로 선택하기 어려움.
- 이러한 서비스들을 클라우드 서비스 유형인 Iaas, Paas, Caas 으로 묶어서 보면 단순해짐.
서비스 유형별 대표적인 클라우드 서비스
- Iaas(Infrastructure as a Service)
- 가상 머신, 스토리지, 네트워크 같은 인프라를 필요한 만큼 적시에 제공하는 서비스임.
- 사용자는 이 인프라를 이용해 개발 환경을 구성한 후 애플리케이션을 배포함.
- 가상 서버, 가상 네트워크, 가상 스토리지로 생각하면 이해하기 쉬움.
- ex) AWS EC2, GCP Compute Engine, Azure VM
- Caas(Container as a Service)
- 컨테이너 기반 가상화를 사용해 컨테이너를 업로드, 구성, 실행, 확장, 중지할 수 있는 서비스임.
- 애플리케이션을 바로 구동할 수 있는 환경을 제공한다는 점에서 PaaS와 유사하지만 다른 환경에도 이식 가능한 컨테이너 기반 가상화를 제공한다는 점이 다름.
- PaaS(Platform as a Service)
- 복잡함 없이 애플리케이션을 곧바로 개발, 실행, 관리할 수 있는 플랫폼 환경을 서비스 형태로 제공함.
- IaaS 위에 실제로 애플리케이션이 실행될 수 있는 미들웨어나 런타임까지 탑재된 환경이라 생각하면 이해하기 쉬움.
- Azure Web App, Google Ap Engine, Cloud Foundry, Heroku, AWS Elastic Beanstalk
2.4.2 마이크로서비스 운영과 관리를 위한 플랫폼 패턴
- 마이크로서비스의 원활한 동작을 지원하는 플랫폼 환경을 살펴보자.
- 인프라 환경을 결정했다면, 그다음으로 인프라 환경 위에서 애플리케이션을 운영하고 관리하는 환경을 구성하는 방법을 생각해야 함.
- 특히 애플리케이션을 빌드하고 인프라에 배포할 수 있는 환경이 중요함.
- MSA 시스템을 구성하는 수많은 마이크로서비스를 하나하나 수동으로 빌드하고 배포한다면 비효율적이고 큰 혼란을 가져올 것임.
- 따라서 이러한 과정을 하나하나 통제하고 자동화하는 것이 중요함.
개발 지원 환경: 데브옵스 인프라 구성
- 필요한 요소는 마이크로서비스를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 개발 지원 환경인 데브옵스(DevOps) 환경임.
- 개발과 운영이 분리되지 않고, 병행할 수 있는 조직 또는 문화를 일컫는다.
- 여기서는 협의의 의미로, 개발과 운영을 병행 가능하게끔 높은 품질로 소프트웨어를 빠르게 개발하도록 지원하는 빌드, 테스트, 배포를 위한 자동화 환경을 말함.
- 이전의 수동 빌드/배포 과정은 정말 많은 시간이 소요됨.
- 또한, 마지막에 배포를 처리하는 배포 담당자는 시스템 사용률이 낮은 야간에 시스템을 장시간 멈추고 배포 작업을 진행하는 경우가 많았음.
- 당연히 이러한 환경에서 비즈니스 민첩성은 높을 수가 없다.
- 따라서 이 같은 활동을 자동화할 필요가 있음.
- 특히, 여러 개의 마이크로서비스를 배포해야 하는 환경에서는 배포가 잦을 수밖에 없기에 자동화가 절실함.
- 자동화된 빌드나 배포 작업을 보통 CI/CD 라고 함.
- CI는 지속적 통합(Continuous Integration)을 가리킴.
- 지속적 통합은 애자일 방법론 중 켄트 백이 만든 XP(eXtreme Programming)의 주요 프랙티스로 시작됐음.
- 오랜 시간이 걸리는 빌드를 매일 자동화해서 수행한다면 개발 생산성이나 소스코드 품질이 높아진다는 경험에서 출발함.
- 자동으로 통합 및 테스트하고 그 결과를 리포트로 기록하는 활동을 CI라고 함.
- 실행 환경에 내보내는 활동을 CD라고 함.
- CD는 지속적 제공(Continuous Delivery) 및 지속적 배포(Continuous Deployment)를 의미함.
- 두 가지 의미를 모두 포함함.
- 차이점을 살펴보면, 지속적 제공은 빌드된 소스코드의 실행 파일을 실행 환경에 반영하기 전 단계 까지 진행하는 방식임.
- 실행 환경에 배포하기 위해 승인 및 배포 담당자의 허가를 받아야하고, 배포도 수동으로 처리함.
- 다소 엄격한 배포 절차를 밟는다고 할 수 있음.
- 지속적 배포는 소스코드 저장소에서 빌드한 소스코드의 실행 파일을 실행 환경까지 자동으로 배포하는 방식임.
빌드/배포 파이프라인 설계
- 보통 빌드/배포되는 과정 동안 수행해야 할 태스크가 정의된 것을 빌드/배포 파이프라인이라고 함.
- 즉, 빌드/배포 파이프라인은 통합 및 배포까지 이어지는 일련의 프로세스를 하나로 연계해서 자동화하고 시각화된 절차로 구축하는 것을 말한다.
- 어떤 단계를 거치는지는 파이프라인 흐름도로 확인할 수 있음.
- 빌드, 단위 테스트, 정적 분석, 배포 과정을 거치는 것을 볼 수 있음.
- 배포 절차 전에 UI 테스트, 통합 테스트, 배포 승인 프로세스 등을 추가하여 재설계할 수도 있음.
- 그리고, 이를 구현하기 위해 어떤 도구를 활용할지 결정하고 도구 사이의 연계 방법을 정의 해야 함.
- 이러한 전 과정을
빌드/배포 파이프라인 설계라고 함.
- 최근 클라우드 같은 가상 환경이 대중화되면서 완전한 자동화가 가능해짐.
- 즉, 인프라 구성을 마치 프로그래밍하는 것처럼 처리하고 소수의 인원으로 많은 컨테이너 배포 처리를 할 수 있게 됨.
- 이를 Infrastrucutre as Code 라고 함.
- 이를 이용하면 배포 파이프라인 절차를 완벽하게 자동화할 수 있음.
- 대규모 인프라 관리를 수행할 수 있고, 코드이기 때문에 쉽게 공유 및 재사용이 가능함.
- IaC를 통해 CI/CD 에서 자동화할 요소들을 살펴보면
- 형상관리 리포지토리에서 소스코드를 가져와 빌드해서 실행 파일을 만드는 작업
- 실행 파일을 실행 환경에 배포하는 작업
- 이런 작업들을 통제하고 연결해서 전 작업이 성공하면 다음 작업이 자동으로 수행되게 하는 연계 자동화 작업
- 으로 나눌 수 있음.
- 이를 모두 코드로 정의 및 설정할 수 있고 이를 지원하기 위해 여러 오픈소스나 솔루션을 이용할 수 있음.
- 모든 과정을 자동화하는 것은 힘들기에 일부 자동화, 일부 수동으로 처리할 수도 있음.
- MSA 시스템의 경우 마이크로 서비스는 각각 별도의 리포지토리를 가지고 있고 독립적으로 수정 및 빌드하고 배포해야 함.
- 빌드/배포 파이프라인도 마이크로서비스별로 별도로 설계해야 함.
마이크로서비스 생태계와 운영 관리 요소의 탄생
- 운영 관리를 위한 요소에 대해 살펴보자.
- 마이크로서비스 생태계가 어떻게 발전했는지를 나타내는 발전 흐름을 알아보면 운영 관리 패턴의 발전 과정을 이해할 수 있음.
- 클라우드 기반에서 마이크로서비스로 전환하는 과정이 쉽지 않았음.
- 애플리케이션이 한 덩어리였을 떄 발생하지 않았던 여러 문제점이 불거짐.
- 전체 서비스를 여러 개의 서비스로 분산 구성했을 때, 한 서비스에서 발생한 장애가 다른 서비스로 전파됨.
- 여러 서비스에 분산된 로그를 관리해야 하는 불편함이 있음.
- 서비스 하나가 동작하지 않아 시스템의 일부 기능이 동작하지 않아도 그것을 알아채지 못하고 장애가 방치되는 문제가 발생함.
- 넷플릭스는 이러한 문제의 해결법으로 다양한 서비스와 도구를 개발하고 오픈소스로 공개함.
- 이것이 바로 넷플릭스 OSS임.
- 여러 마이크로서비스 간의 라우팅과 로드 밸런싱을 위한 줄(Zuul)과 리본(Ribbon), 모니터링을 위한 히스트릭스(Hystrix), 서비스 등록을 위한 유레카(Eureka) 등이 포함돼 있음.
- 이러한 넷플릭스의 공유 활동이 마이크로서비스 기술을 발전시키는 시초가 됨.
- 이를 기반으로 주요 마이크로서비스 운영 관리를 위한 문제 영역들이 활발히 논의됨.
- 이를 해결한 기술들이 공유되고 자연스럽게 개발자 간 협업 및 오픈소스에 대한 기여가 이뤄지고 이로 인해 업계가 함께 발전하게 됨.
- 이후 2013년 가장 유명한 컨테이너 기술이 도커가 세상에 등장함.
- 최근 컨테이너 오케스트레이션 기술인 구글의 쿠버네티스까지 등장함.
- 계속해서 마이크로서비스 생태계의 발전을 이끌어냄.
- 그 과정에서 주요 문제 영역들이 논의되고, 그에 대한 해결책이 제시돼 왔음을 알 수 있음.
경험으로 획득한 지혜: 마이크로서비스 관리/운영 패턴
- 마이크로서비스 구축 시 발생하는 문제는
- 주로 시스템을 여러 개의 서비스로 구성하기 때문에 발생하는 문제임.
- 넷플릭스가 이 문제를 해결하는 데 크게 기여했는데, 넷플릭스 OSS는 넷플릭스가 마이크로서비스를 개발하고 운영하면서 생긴 노하우를 다른 사람들도 쉽게 사용할 수 있도록 공유한 오픈소스임.
- 마이크로서비스 생태계에 크게 도움이 됨.
- 특히 마이크로서비스 관리와 운영을 지원하는 전형적인 마이크로서비스 애플리케이션 패턴으로 자리잡음.
- ex) API 게이트웨이, 서비스 디스커버리, 모니터링, 트레이싱 등.
- 다수의 마이크로서비스를 관리 및 운영하기 위한 플랫폼 패턴으로서 넷플릭스에서 소스를 공개하고 나서 패턴으로 정착되고 나중에 이러한 패턴을 적용한 다른 여러 도구와 오픈소스들이 생겨나는 밑거름으로 작용함.
- 넷플릭스 OSS를 더 쉽게 쓸 수 있도록 스프링 진영의 피보탈에서는 기존의 스프링 부트 프레임워크에서 잘 돌아갈 수 있도록 넷플릭스 OSS 모듈들을 스프링 프레임워크로 감싸서
스프링 클라우드(Spring Cloud)라는 명칭으로 발표함.
- 스프링 부트와 스프링 클라우드는 마이크로서비스를 개발하기 위한 가장 대중적인 기본 프레임워크로 자리매김함.
- 이를 이용하여 마이크로서비스 애플리케이션의 운영 환경을 쉽게 구축할 수 있음.
- 이어서 스프링 클라우드를 중심으로 주요 관리 및 운영 플랫폼 패턴을 살펴보자.
댓글