티스토리 뷰

Sorry Architecture

Bakery System

Quill. 2019. 2. 16. 14:41

2019년, AWS(Amazon Web Services)가 직접 직접관리해주는 베이커리 시스템이 나왔다. AMI(Amazon Machine Image)를 쉽게 만들고 관리할수 있게 해주는 EC2 Image Builder의 등장으로 베이커리 시스템을 자체 구축할 필요성이 많이 줄어 들었다.


2013년에, 초기 버전의 베이커리 시스템(Bakery System)을 구축하였다. 당시까지만해도 EC2에 직접 접속해서 패키지를 배포하던 것이 일반적이었다. 어느 날, AWS 콘솔을 확인하던 중 EC2-AUTO라는 인스턴스를 발견했고, 협력업체 담당자인 수석연구원에게 용도가 무엇인 지 물어보았다. 그 분의 답변은 새 서버를 배포할 때 사용할 AMI를 만들려고 하는데, 이 때 t서버 설정의 일관성을 위해 깨끗한 상태의 새 EC2 인스턴스가 필요했다는 것이다. 새 버전의 서버 배포가 필요한 경우[각주:1] 셰프(Chef)를 EC2-AUTO 인스턴스에서 수행한다음, 그 인스턴스를 AMI로 만든다고 했다. 그리고 서버를 배포하는 날이 되면 오토스케일링 그룹의 AMI를 교체하여 배포를 수행한다고 했다. 셰프를 통해 서버 설정을 일관성있고 균일하게 유지하는 방법을 도입하는 것도 매우 급진적이어서 운영 업체의 반발이 엄청 심했었는데, 오히려 더 발전시켜 이미지 기반 배포를 하는 모습을 보게 되니 저절로 미소가 지어졌다.[각주:2]

 

이 후, 이렇게 AMI를 생성하고, 이미지 기반으로 빠르게 서버를 배포하는 시스템을 구현했다. 아래 그림은 초기 버전의 아키텍처를 보여준다.

Amazon Machine Image Bakery System Architecture

 

베이커리 시스템을 이용하여 이미지를 만들어서 배포를 하면, 배포시간이 짧아지고 운영 방식이 간소화 된다. 이미지를 활용하면 셰프나 앤서블을 라이브(Live) 환경에서 실행하는 것보다 빠르게 서버를 띄울 수 있다. 그리고 운영 환경에서 문제가 생겼을 경우 간단하게 최종 이미지 또는 이전 이미지를 이용하여 복구하거나 교체 하면 되기 때문에 비상시 운영자가 대응하는 절차가 쉽고 간단하다. 이미지 기반의 환경이 주는 장점에 대해서는 Immutable Infrastructure에서 보다 자세하게 다룬다.[각주:3]

 

그러나 이미지는 단점이 있다. 배포하고 실행하는 속도가 빠른 대신 1/ 상황에 맞게 동적으로 변화를 줄 수 없으며, 2/ 불투명하기 때문에 내용물이 어떤 것인지 파악하기 어렵다. 그리고 3/ 생성할 때 비교적 시간이 오래 걸린다. 이러한 문제점을 해결하면서 장점을 취하기 위해, 2016년에 베이커리 시스템을 개선했다. 이미지를 생성하기 위한 소스 코드(Source Code)로부터 이미지까지 모든 과정을 자동화했다. 설정 자동화 도구(Configuration Management)로 셰프(Chef)와 앤서블(Ansible)을 사용했고, 이미지 생성기(Machine Image Builder)로 아미네이터(Aminator)와 패커(Packer)를 사용했다. 젠킨스(Jenkins)의 지속적 전달(Continuous Integration) 기능을 통해 자동으로 빌드, 테스트, 환경 설정, 그리고 AMI 생성까지 수행하도록 만들었고 스핀에커와 젠킨스를 연결해서 배포까지 자동화하였다. 또한, 생성한 이미지에 태그(Tag)를 붙여 어떤 버전의 패키지를 담고 있는 지 쉽게 알 수 있도록 했다. AMI에 iot-cloud-20160708 같은 형식의 태그를 붙여두면 어떤 버전의 애플리케이션이 수행 중인 지 이미지 속을 들여다보지 않아도 되기 때문이었다.

Immutable Image Building Process (https://soscon.net)

 

개선된 베이커리 시스템과 이미지 기반 배포 전략은 삼성 오픈 소스 컨퍼런스 2018에 발표하였다. 위 그림은 개선된 시스템을 설명한 그림이다. 이 후 베이커리 시스템은 스핀에커(Spinnaker)에 내장된 Rosco로 대체하도록 개선했고, 도커(Docker) 이미지를 만들어서 GKE(Google Kubernetes Engine)에 배포하는 수준까지 확장하였다. 다만, 중국 클라우드 환경은 사용이 어려워서 젠킨스 기반의 베이커리를 유지 했다.  


 

  1. 당시 배포는 1개월에 한 번씩 수행했다. [본문으로]
  2. 이 배포 방법은 가수 EXO의 단독 앨범 발매로 인해 거의 모든 서비스가 멈췄을 때도, 오토스케일링을 통해 트래픽을 수용하여 유일하게 정상 동작한 서비스가 되도록 해주었다. [본문으로]
  3. https://youngookkim.tistory.com/20 [본문으로]

'Sorry Architecture' 카테고리의 다른 글

PhoenixServer  (0) 2019.02.20
Netflix Frigga  (0) 2019.02.18
Encapsulation  (0) 2019.02.16
Music Radio Architecture  (0) 2019.02.16
Purpose of Code Review  (0) 2019.02.16
공지사항