Tech

표준 서비스 환경 자동 구축을 위한 서버 템플릿 도구 도입 사례

2022. 01. 05

안녕하세요, 화해팀에서 데브옵스 엔지니어로 일하고 있는 곽요한입니다. packer

지난 10월 화해 개발팀에서는 전체 엔지니어들이 모이는 제1회 테크 밋업 행사가 있었습니다. 매주 플랫폼 단위로 밋업 행사들이 진행되고 있지만 전체 개발팀이 모두 모인 Meetup Day는 처음 열린 것 같습니다. CTO이신 재광님의 ‘화해에서 개발팀이 추구하는 애자일의 가치와 이를 실현하는 방법’ 세션을 시작으로 각 플랫폼별로 뽐내고 싶은 주제를 가지고 자유롭게 선정해서 발표하고 이야기 나누는 시간을 가졌습니다.

데브옵스 플랫폼은 서비스 도메인별로 표준화되고 자동화된 서비스 환경을 제공하기 위해 동료들과 많은 고민을 나누며 개발해오고 있습니다. 기존 관리방식의 문제점을 효율적으로 개선하고자 서버 템플릿 도구를 도입했던 내용을 주제로 발표를 했고, 이때 발표했던 내용을 조금 다듬어 이번 콘텐츠를 작성해보았습니다.

표준 서비스 환경의 목적

화해의 서비스 기술 환경은 OS 기반에 각종 애플리케이션 환경을 구성하여 코드를 배포하는 방식으로 구성되어 있습니다.

packer_화해팀

이러한 환경은 새로운 인프라를 추가할 때 동일하게 구성해야 하는 상황이 빈번하게 발생했기 때문에 자동화가 필요했습니다. 그리고 눈송이 서버(Snowflakes Server)가 되지 않도록 구성하는 모든 과정을 코드로 작성하거나 문서화하여 사전에 인스턴스 이미지로 만들고, 언제든 같은 형태의 인스턴스가 생성될 수 있도록 관리해 나가는 방법이 필요합니다.

Snowflakes Server와 Phoenix Server

서버를 구성하고 나면 시간이 지날수록 초기 설정 이후에 변경과 패치 사항이 생겨서 버전별 정보를 관리하기 위해서는 많은 노력이 필요합니다. 하지만 각 개발자가 이를 신경 쓰면서 운영한다는 것은 지속 가능하지 않은 운영 방식인 것 같습니다. 만약 이렇게 이력관리가 되지 않은 상태에서 담당자가 변경되기라도 한다면 더 이상 과거 이력을 추적할 수 없게 되고 눈송이처럼 녹아버려서 다시는 동일한 형태의 서버로 구성할 수 없게 되는데 이를 눈송이 서버(Snowflakes Server)라고 부릅니다. 이와 반대 개념으로 매번 동일한 구성으로 재생성(Re-born)이 가능한 서버를 피닉스 서버(Phoenix Server)라고 부르고 변하지 않는 인프라(Immutable Infrastructure)를 구성하는데 중요한 요소가 됩니다.

packer_화해팀

기존 방식의 한계점

이처럼 지속적으로 관리가 가능한 인프라를 유지하기 위해 표준 서비스 환경이 필요합니다. 기존에는 표준 서비스 환경을 제공하기 위해 서버 구성에 필요한 내용을 문서와 애드혹 스크립트로 작성해서 관리하고 있었습니다.

packer_화해팀

구성 내용 문서화 / 애드혹 스크립트

작성된 문서와 애드혹 스크립트를 이용해서 다음 과정을 통해 인스턴스 이미지를 생성합니다.

packer_화해팀

개발자의 로컬 PC에서 CLI 이용해 표준 AMI 생성을 위한 인스턴스를 생성한다.
인스턴스 생성이 완료되면 SSH로 접근 후 초기 설정 스크립트를 실행해서 패키지 설치와 애플리케이션 환경, 미들웨어 등을 설치하고 구성한다.
다시 개발자의 로컬 PC에서 CLI를 이용해 초기 설정이 완료된 인스턴스를 Base AMI로 생성한다.

한계점

이러한 방식을 통해 서버의 변경이력을 문서로 관리할 수 있고, CLI와 애드혹 스크립트를 이용해서 인스턴스와 이미지를 생성하기 때문에 직접 인스턴스를 생성하는 것보다 일관성을 유지할 수 있었습니다. 하지만 몇 가지 개선 포인트도 발견했습니다.

먼저, 초기 설정 스크립트 내용이 변경되는 경우 스크립트와 문서를 모두 수정해야 하고 코드로 된 스크립트를 컨플루언스 문서로 관리하기 용이하지 않았습니다. 그리고 사람이 직접 문서를 수정하다 보니 휴먼에러가 발생할 수 있고 많은 양의 정보를 컨플루언스 문서로 관리하고 있어 버전 관리의 어려움이 존재했습니다. 마지막으로 새로운 환경이 추가되어 인스턴스 이미지를 생성해야 할 때마다 개발자가 직접 작업을 해주어야 하는 번거로움도 있었습니다.

이러한 한계점을 개선하기 위해서 데브옵스 플랫폼 동료들과 여러 고민을 통해 서버 템플릿 도구를 도입하기로 결정했습니다.

서버 템플릿 도구 도입을 위한 벤치마킹

서버 템플릿 도구는 OS 설정, 소프트웨어 설치, 커스터마이징 작업 등의 사전 구성이 적용된 스냅샷 형태의 이미지를 생성해주는 도구입니다. 화해 서비스의 인프라는 AWS를 사용하고 있기 때문에 시너지를 낼 수 있는 AWS EC2 Image Builder와 가장 인지도가 높은 도구인 HashiCorp의 Packer 중 적합한 도구를 선택하기 위한 벤치마킹을 진행했습니다.

Packer

Terraform, Vault 등의 오픈 소스를 개발한 HashiCorp에서 만든 도구로 하나의 Source를 이용해서 여러 플랫폼 기반의 인스턴스와 컨테이너 이미지를 만들 수 있는 도구입니다.

인터페이스는 CLI로 제공되고 Provider의 API를 호출해서 실행하는 방식이기 때문에 별도로 실행 환경을 고려할 필요가 없습니다. 또한 이미지 생성 과정에 대한 모든 정보를 코드로 관리하기 때문에 다양한 플랫폼에서 같은 형태의 이미지를 만들어 사용할 수 있습니다.

packer_화해팀

출처 Integration Program | Packer by HashiCorp

구성요소

Data Source – Template에서 사용하는 데이터로, 사전에 직접 정의한 소스나 외부 소스에서 데이터를 가져와 사용할 수 있습니다. 대표적으로 AWS Public Image가 있습니다.
Build & Builder – Builder는 이미지를 생성할 수 있는 다양한 플랫폼입니다. AWS, GCP 등이 있고 Build는 Builder를 통해서 이미지를 생성하는 단일 작업입니다.
Artifacts – 빌드 과정을 통해서 생성된 결과물을 의미합니다. post-processor를 정의해서 아티팩트를 이용해 다시 새로운 아티팩트를 생성할 수도 있습니다.
Provisioner – 이미지를 빌드하기 위한 시스템을 생성해서 적용이 필요한 특정 패키지를 설치하거나 스크립트를 수행할 수 있고 이러한 방식으로 테스트를 진행할 수도 있습니다. 프로비저너를 수행하는 대표적인 도구는 쉘 스크립트와 Ansible, Chef 등이 있습니다.
Templates – Packer를 이용해서 하나 이상의 빌드를 정의하는 구성 파일입니다. JSON(이전 세대)와 HCL2으로 나뉘고 HCL2는 1.5부터 베타 버전이, 1.7 버전부터 정식 지원이 되기 시작했습니다. HCL2를 JSON으로도 표기하는 방식이 있지만 이는 이전 세대 JSON과는 다른 표기법입니다.
Post Processor – 빌드 과정이 모두 끝난 뒤에 로컬에서 특정 스크립트를 실행하거나 아티팩트 업로드, 재패키징 등의 작업에 사용할 수 있습니다.

AWS EC2 Image Builder

19년도에 출시된 서비스로 AMI를 관리하고 구축하는 도구입니다. AWS 또는 온프레미스에서 사용할 수 있고 VM이나 컨테이너 이미지를 구축한 뒤 테스트 및 배포하는 과정을 통해 이미지를 안전하고 최신 상태로 유지하기 위한 자동화된 파이프라인을 제공합니다.

AWS EC2 Image Builder는 AWS 웹 콘솔 내에 GUI로 제공되고 있어 직관적이고 이미지를 최신 상태로 유지하기 위한 자동화된 빌드 파이프라인을 생성해서 원하는 이미지를 쉽고 빠르게 제공 및 관리할 수 있습니다. 또한 AWS CLI와 CloudFormation과 같은 AWS의 IaC 서비스와 통합이 용이합니다. 이미지를 생성하거나 저장 및 공유할 때 사용하는 기본 AWS 리소스 비용 외에는 무료로 제공됩니다.

packer_화해팀

출처 https://aws.amazon.com/ko/image-builder/

구성요소

Image pipeline – 가장 최상위 단위 구성요소로서 파이프라인으로 관리하고자 하는 이미지를 레시피로 작성하고 빌드 주기 및 시간과 빌드할 때의 인프라 환경, 생성된 이미지가 배포될 리전 등을 설정해서 사용자가 원하는 형태의 파이프라인으로 구성할 수 있습니다.
Recipe – 사용자가 원하는 이미지를 빌드하기 위한 Spec과 구성요소 등을 정의하는 문서입니다. 인스턴스와 컨테이너 이미지를 생성할 수 있습니다.
Base image – 레시피를 사용해서 이미지를 빌드할 때 기반이 되는 이미지입니다.
Components – 이미지를 빌드하고 테스트하는 과정에서 수행되는 작업의 단위입니다. CloudWatch, CodeDeploy 에이전트 설치 등 AWS에서 제공하는 관리형 컴포넌트를 선택할 수 있고 파일을 옮기거나 사용자가 직접 구성하고자 하는 내용을 작성해서 추가로 선택할 수 있습니다.
Infrastructure – 이미지를 빌드하기 위한 EC2의 인프라 환경을 설정합니다. 컴포넌트를 실행할 EC2의 타입과 IAM, VPC 등을 설정해서 적절한 환경을 통해 빌드가 수행될 수 있도록 구성합니다.
Distribution – 파이프라인의 마지막 단계로서, 결과물로 생성된 이미지의 리전과 공유 여부를 결정하고 필요시 시작 템플릿을 연결할 수 있습니다.

Packer와 EC2 Image Builder 구성요소 비교

packer_화해팀

특징 비교표

	Packer	EC2 Image Builder
OS 지원	지원 가능 OS에 대한 제한이 없고 SSH와 WinRM을 사용하기 때문에 별도의 에이전트를 설치하지 않는다.	AWS SSM 에이전트가 설치된 AMI에서만 사용이 가능하다.
재사용성	AWS의 AMI 뿐만 아니라 GCP 등 멀티 플랫폼에서 동일한 형태의 이미지를 생성할 수 있다.	AWS로 제한된다.
로깅	콘솔에 작업되는 모든 로그가 출력되고 debug 플래그를 사용하여 단계적으로 실행할 수 있다.	Cloudwatch Logs를 통해서 파이프라인 프로세스의 모든 로그가 기록된다.
레퍼런스 자료	기술 성숙도와 인지도가 높아 참고자료가 많다.	공식 문서 외엔 거의 참고할 자료가 없고 공식 문서의 자료도 많지 않다.
테스트/검증	이미지를 사용자가 원하는 구성으로 빌드한 뒤에 테스트와 검증을 위한 별도의 빌드 및 프로비저너를 작성하고, 이를 자동화할 수 있는 다른 기술 스택을 이용해서 파이프라인을 구성해야 한다.	빌드 단계에서 테스트를 통합할 수 있고, 관리형 컴포넌트를 이용해서 별도로 작성하지 않아도 손쉽게 구성할 수 있다.

Packer를 선택한 이유

벤치마킹을 진행하면서 처음에는 GUI 방식의 인터페이스와 파이프라인 구성, 기본으로 제공하는 여러 컴포넌트들까지 사용이 가능한 Image Builder에 상당한 매력을 느꼈습니다. 하지만 기술을 도입했을 때 학습에 필요한 공식문서와 레퍼런스 자료가 상대적으로 많이 부족했던 점이 장기적으로 기술을 내재화시키는데 걸림돌이 될 수 있어 보였습니다.

또한 로그정보를 확인할 때 CloudWatch Logs를 거쳐야만 파악이 가능했지만 반대로 Packer에서는 작업 단위의 상세한 내용을 Console output log를 통해 바로 확인할 수 있었습니다.

마지막으로 현재까지는 화해 서비스의 인프라를 AWS 중심으로 사용하고 있지만 일부 데이터 분석을 위한 인프라는 GCP를 사용하고 있고 향후에 서비스 인프라도 GCP를 사용할 가능성이 있기 때문에 특정 클라우드 플랫폼에 종속되지 않는 Packer를 최종 선택하게 되었습니다.

Packer 도입 후 진행 중인 부분과 향후 방향

레이어드 이미지 구성

Packer를 도입한 뒤 애드혹 스크립트를 관리하고 변경사항을 이미지로 생성해내는 과거의 절차가 매우 간소화되었습니다. 이렇게 여러 서버를 이미지로 관리하다 보면 동일하게 적용되어야 하는 영역이 생기고 어떤 경우에는 환경이나 도메인 특성에는 해당되지 않는 불필요한 영역이 생기는 경우가 있습니다. 케이스마다 새로운 종류의 이미지를 생성하면 관리해야 할 이미지가 늘어나게 되고 이중 변경사항이 생겼을 때 서버 이미지 생성을 위한 작업이 반복적으로 필요하게 됩니다.

이러한 반복 작업을 줄이기 위해서 변경이 필요한 기술들을 레이어로 묶어서 관리하는 것이 좋습니다. 예를 들어 OS만 구성된 기본 이미지 위해 모든 인스턴스에 반드시 필요한 보안설정과 패키지를 설치한 Golden Image Layer를 구성하고 이를 Common Image로 생성합니다. 이렇게 생성된 Common Image를 기반으로 모니터링 툴을 구성한 이미지나 애플리케이션 환경을 구성할 수 있습니다. 이처럼 기본 이미지에 레이어를 쌓아가면서 적절하게 이미지를 구분하고 체계적으로 관리하기 위한 작업을 진행하고 있습니다.

packer_화해팀

자동화된 파이프라인

만약 레이어드 된 이미지에 변경사항이 반영되어 새로운 버전이 릴리즈 되면 어떻게 될까요? 예를 들어 Common Image가 새로운 버전으로 릴리즈 되면 이를 기반으로 만들어진 이미지에도 새로운 Common Image가 적용되어야 합니다. 이 작업을 개발자가 수동으로 개입하지 않더라도 최종 이미지 레이어까지 자동으로 반영되어 배포될 수 있도록 자동화된 파이프라인 환경 구성을 계획하고 있습니다.

IaC의 확장

과거에 생성되어 운영되던 서버들은 히스토리를 쉽게 파악하기 어렵다 보니 지속적으로 변경관리를 하면서 운영하는데 어려움이 있었습니다. 이러한 문제점을 해결하고자 데브옵스 플랫폼에서는 표준 서비스 환경을 구성했고 앞으로 더욱 늘어나는 인프라를 효율적으로 관리해나가기 위해 Packer와 Terraform, Ansible 등의 IaC 기반의 여러 기술들을 도입해오고 있습니다. 이제 막 도입이 시작된 기술들도 많지만 앞으로 더 많은 영역의 인프라를 자동화하고 코드로 관리하면서 지속성을 가진 인프라 생태계를 만들어갈 계획입니다.

이 콘텐츠가 마음에 드셨다면 데브옵스 플랫폼의 또 다른 콘텐츠도 확인해보세요!

✅ gunicorn 설정의 A to Z

packer