컨테이너화와 AWS로의 마이그레이션에 대해

기존 환경의 컨테이너화와 AWS에 이동하는 방법에 대해 기재한 글입니다

#AWS

#한국어블로그

Lee Sujae

2023.10.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요 클래스메소드의 수재입니다.
기존 온프레미스 환경에서 클라우드로 마이그레이션 하면서 기존 환경의 컨테이너화를 고려하는 경우가 있습니다.
저도 공부한 내용을 기록할 겸 정리해보겠습니다.

컨테이너화란?

정의

컨테이너화는 애플리케이션의 코드를 모든 인프라에서 실행하는 데 필요한 모든 파일 및 라이브러리와 함께 번들로 제공하는 소프트웨어 배포 프로세스입니다. 기존에는 컴퓨터에서 애플리케이션을 실행하려면 컴퓨터의 운영 체제와 일치하는 버전을 설치해야 했습니다.
예를 들어, Windows 시스템에 소프트웨어 패키지의 Windows 버전을 설치해야 했습니다. 하지만 컨테이너화를 사용하면 모든 유형의 디바이스 및 운영 체제에서 실행되는 단일 소프트웨어 패키지 또는 컨테이너를 만들 수 있습니다.
컨테이너화란 무엇인가요?(AWS)

애플리케이션을 운용하는데 필요한 종속성을 포함하여 독립적으로 패키징(이미지화) 하는 것을 "컨테이너화"라고 합니다.

장점

"배포의 부담이 줄어들고 간편해진다"가 주요 장점입니다.
더 상세하게 보자면 다음과 같습니다.

손쉬운 배포(=이동성)
실행에 필요한 종속성을 포함하여 배포하기 때문에 애플리케이션을 구동하기 위해 추가로 다른 기능을 설치할 필요가 없습니다.
따라서 필요에 따라 컨테이너 이미지만을 빌드하고 관리하면 됩니다.

확장성 및 경량화
컨테이너를 실행시키기 위해서는 적은 리소스만으로도 충분합니다. 배포가 간단하다는 장점과 합쳐져서 필요에 따라 신속하게 여러 개의 서비스를 운용하도록 확장할 수 있습니다.

내결함성
실행되는 컨테이너들은 서로 영향을 주지 않습니다¹. 따라서 다수의 컨테이너를 실행시킨 상황에서 어느 컨테이너가 멈추더라도 다른 컨테이너의 실행에는 영향이 없습니다.

민첩성
이미지화(패키징) 된 이미지를 배포하기 때문에 모든 컨테이너에 대해 어떠한 변경 사항이 있더라도 배포한 이미지만 변경한다면 기존의 다른 컨테이너에 변경을 적용할 수 있습니다.²
따라서 문제 수정이나 업데이트를 빠르게 적용할 수 있습니다.
빠르게 대응할 수 있기 때문에 테스트 후 프로덕션에 적용하는 사이클도 가속화 할 수 있습니다.

컨테이너화가 적합한 시스템

기존 환경이 다음 설명의 환경이거나 혹은 변경 할 예정이라면 컨테이너화를 고려해볼 수 있습니다.

마이크로서비스 아키텍쳐와 CI/CD

마이크로서비스(또는 마이크로 서비스 아키텍처)는 단일 애플리케이션이 다수의 느슨하게 결합되고 독립적으로 배치 가능한 더 작은 구성요소 또는 서비스로 구성되는 클라우드 네이티브 아키텍처 접근 방식입니다.
마이크로서비스란?(IBM)

애플리케이션의 각 기능을 분리하여 서로 간의 종속성이 적은(느슨한 결합을 가지는) 아키텍쳐입니다.
컨테이너화와 동일하게 각 기능마다 배포하는 것이 가능하기 때문에 수요가 많은 특정 기능을 더 많이 배포하는 등 컨테이너화에 적합합니다.

마이크로 서비스로 운용하면서 환경을 코드로 관리하는 CI/CD를 도입하는 경우도 많습니다.
이를 통해 컨테이너의 관리 및 개선을 빠르게 진행 시킬 수 있습니다.

모놀리식 아키텍쳐의 경우에는 컨테이너화하여 운용하는 것 보다 VM(가상 머신)에서 운용하는 것이 더 적합할 수도 있습니다.

릴리스 빈도가 많은 시스템

시스템의 변경이나 배포가 자주 일어나는 서비스(환경)에서 컨테이너화의 장점인 손쉬운 배포와 민첩성을 충분히 활용 할 수 있습니다.
시스템적인 변화가 거의 없는 시스템이라면 들인 시간에 비해 컨테이너화의 효율이 낮을 수도 있습니다.

클라우드 환경으로 마이그레이션하는 시스템

필요에 따라 컨테이너를 늘리고 줄일 때 필요한 만큼 리소스를 사용하기 위해서는 시스템을 클라우드화 하는 것이 가장 좋습니다.
예를 들자면 EC2에 컨테이너를 구축하여 사용하는 경우, 평상시에는 1대의 EC2에서 컨테이너를 운용하다가 보다 많은 서버 리소스가 필요해진다면 EC2를 추가하여 컨테이너를 늘릴 수 있습니다. 필요 리소스가 줄어든다면 EC2를 삭제하여 평상시의 요금만 청구되도록 할 수 있습니다.

컨테이너화 권장 사항

컨테이너화의 효율을 높이기 위해 몇 가지 권장 사항 및 주의 사항이 있습니다.

컨테이너 오케스트레이터 이용

컨테이너가 늘어날수록 당연히 관리 난이도가 올라갑니다.
이러한 컨테이너들을 관리할 수 있도록 도와주는 도구가 컨테이너 오케스트레이터(컨테이너 오케스트레이션 툴) 입니다.
이러한 도구로 Kubernates 등이 있습니다.

마이크로 서비스화 할 수 있는가?

위에서 설명했듯이 서비스를 마이크로 서비스화 할 수 있으면 컨테이너화에 가장 적합합니다.
현대적인 애플리케이션 개발에서 12가지 모범 사례인 The Twelve-Factor App에 따라 애플리케이션 구현하면 애플리케이션의 마이크로 서비스화도 구현하기 쉽습니다.
[The Twelve-Factor App는 다음과 같습니다.

코드베이스 : 버전 관리되는 하나의 코드베이스와 다양한 배포
종속성 : 명시적으로 선언되고 분리된 종속성
설정 : 환경(environment)에 저장된 설정
백엔드 서비스 : 백엔드 서비스를 연결된 리소스로 취급
빌드, 릴리즈, 실행 : 철저하게 분리된 빌드와 실행 단계
프로세스 : 애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행
포트 바인딩 : 포트 바인딩을 사용해서 서비스를 공개함
동시성(Concurrency) : 프로세스 모델을 사용한 확장
폐기 가능(Disposability) : 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화
개발/프로덕션환경 일치 : 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지
로그 :로그를 이벤트 스트림으로 취급
Admin 프로세스 : admin/maintenance 작업을 일회성 프로세스로 실행

이 중에서 특히 6. 프로세스, 9. 폐기 가능, 11. 로그에 대해 조금 더 신경을 쓰는 것이 좋습니다.

스테이트리스(stateless)한 컨테이너
컨테이너에 영구 데이터나 세션 정보가 있는 경우 컨테이너를 안전하게 종료하기가 어렵습니다.
따라서 컨테이너 내부에는 보관이 필요한 데이터나 세션 정보를 저장하지 않는게 좋습니다. 가능한 한 외부의 데이터 스토어에서 관리하여 컨테이너는 스테이트리스로 유지하는 것이 바람직합니다.

빠르게 시작하고 쉽게 폐기할 수 있는 컨테이너
애플리케이션 컨테이너는 언제든지 사용자에게 영향을 주지 않고 안전하게 종료할 수 있도록 구현되는 것이 바람직합니다.

스트림으로 처리하는 로그
컨테이너 내부에서 로그를 파일로 처리하여 외부 저장소에 저장하는 경우 컨테이너가 갑작스레 종료되면서 로그가 소실되는 경우가 있을 수 있습니다.
따라서 이벤트 등의 로그는 외부 저장소에 스트림으로 처리하는 것이 좋습니다

컨테이너 1개당 프로세스(애플리케이션) 1개

하나의 컨테이너에 대해 하나의 프로세스만 실행하는 것이 바람직합니다.

가상 머신 에서는 하나의 가상 머신에서 Web, AP, DB와 같이 여러 애플리케이션을 시작할 수 있습니다.
하지만 컨테이너에서는 하나의 컨테이너에서 여러 애플리케이션을 시작하는 것은 권장되지 않습니다. 대신 응용 프로그램별로 컨테이너를 시작합니다.

컨테이너의 안전한 작동 보증

공격자의 공격을 방지하기 위해 프로덕션 환경에서 실행되는 컨테이너 이미지는 추가 패키지를 설치하지 않으며 공격의 여지가 적은 것이 바람직합니다.
애플리케이션을 컨테이너화 할 때의 기본 컨테이너 이미지는 애플리케이션과 해당 런타임 종속성만 포함된 distoless와 같이 가볍고 안전한 이미지를 선택하는 것이 바람직합니다.

또한 컨테이너에서 작동을 보증할 수 없거나 컨테이너에서 사용할 수 없는 라이센스를 사용하는 시스템은 검토가 필요합니다. 기존 시스템을 컨테이너화하는 경우 시스템에서 사용하는 제품 및 오픈 소스 소프트웨어 라이센스가 컨테이너에서 사용하도록 지원하는지 확인해야 합니다.

컨테이너 이미지에 기밀 정보를 포함하지 않음

컨테이너 이미지에는 자격 증명과 같은 기밀 정보를 포함하지 말아주세요. 대신 자격 증명과 같은 중요한 정보는 컨테이너가 실행될 때 환경 변수를 통해 응용 프로그램에 전달하는 것이 바람직합니다.

모범 사례 에 따라 Dockerfile 작성

Dockerfile은 모범 사례 에 따라 설명하는 것이 바람직합니다.

Dockerfile이 모범 사례 따르는지 확인하는 도구도 있습니다.

AWS로의 컨테이너화

기존 온프레미스 혹은 EC2에서 운용되고 있는 서비스를 AWS로 마이그레이션하는 과정에 대해 알아보도록 하겠습니다.
대략적인 흐름 정도가 정리되어 있습니다. 각 컨테이너의 이미지 작성 방법 등 자세한 내용은 별도로 확인해주시길 바랍니다.

기존 서비스의 컨테이너화

기존의 서비스를 컨테이너화하기위해 컴포넌트를 특정할 필요가 있습니다.
온프레미스 서버나 EC2에서 서비스를 제공하는 경우에는 여러 컴포넌트가 함께 운용되고 있습니다.
위에서 설명한 컨테이너 1개당 프로세스(애플리케이션) 1개를 달성하기 위해 컴포넌트를 분리하여 각각 컨테이너화 할 필요가 있습니다.
이미지와 같이 하나의 서버에서 운용되는 여러 프로세스가 각각 컨테이너화의 대상이 됩니다.

각 컨테이너를 이미지화하여 이미지 레지스트리(컨테이너 레지스트리)에 저장합니다.
이후 필요한만큼 레지스트리에서 이미지를 읽어와 컨테이너를 작성하는 식입니다.

AWS 서비스 선정

AWS에서 컨테이너를 운용하기 위해 대표적으로 다음과 같은 서비스를 제공하고있습니다.

컨테이너 오케스트레이션 서비스
컨테이너의 디플로이, 스케줄링, 스케일링 등 사용하고 있는 컨테이너들을 관리하기 위해 사용하는 서비스입니다.
ECS와 EKS 둘 다 오케스트레이션 서비스이며 EKS는 Kubernates로 관리하는 경우 사용하는 서비스입니다.

이미지 레지스트리 서비스
컨테이너의 이미지를 저장하는 서비스입니다.
AWS에서는 ECR이라는 서비스를 제공하고 있습니다.

서버 호스팅 서비스
컨테이너를 호스팅하기 위한 서버를 제공하는 서비스(컴퓨팅 서비스) 입니다.
EC2는 사용하는 서버의 관리를 모두 사용자가 담당하는 컴퓨팅 서비스이며 Fargate는 사용자가 서버의 관리가 불필요해지는 서버리스 컴퓨팅 서비스입니다.

AWS나 컨테이너의 운용에 익숙하지 않다면 ECS, ECR, Fargate의 조합이 관리할 요소가 적어서 편하기 때문에 추천드립니다.

ECS를 사용하는 경우 다음 3가지 개념을 이해하면 구성하는 것이 어렵지 않을 것입니다.

Task(작업) 정의
- 어플리케이션을 구성하는 하나 이상의 컨테이너 그룹을 정의
Service(서비스) 정의
- 일정한 태스크를 유지하거나 상황에 따라 스케줄링하도록 정의
클러스터(Cluster)
- 태스크와 서비스을 묶은 논리적 그룹

이미지로 정리하자면 다음과 같습니다.
즉, 정리하자면

다수의 컨테이너 그룹 + 컨테이너에 관한 정의 = Task 정의
다수의 컨테이너 그룹의 수를 유지하는 설정 = Service 정의

일부 기능은 AWS 서비스로 대체

보통 서비스를 문제없이 운용하기 위해서 로깅이나 모니터링 프로그램을 사용하는 경우가 많습니다. 이러한 프로그램도 컴포넌트의 대상이 됩니다.
필요에 따라 AWS 에서 제공하고 있는 서비스를 대체하여 컨테이너를 줄일 수 있습니다.

예로들면 로깅의 경우에는 CloudWatch 를 이용하면 로그 등을 장기간 저장하고 분석하는 것도 가능합니다. 모니터링의 경우 CloudWatch Insight를 이용하면 다양한 지표를 Insight에서 확인하며 필요에 따라 알람 등을 설정하는 것도 가능합니다.

원하는 기능을 AWS에서 제공하는지 확인하기 위해서는 AWS {필요 기능}을 영어로 검색하면 대부분 확인할 수 있습니다.

마무리

이미 운용하고 있는 서비스를 컨테이너화하는 경우에는 현재 어플리케이션의 구성부터 다양한 요소에 대해 검토가 필요합니다.
운용중인 서비스가 컨테이너화에 적합하지 않더라도 가상 머신(Virtual Machine)에서 운용하는 선택지도 있습니다.
특히 컨테이너화를 진행하며 AWS 등의 클라우드화도 가능하다면 여러 방면에서 효율적인 인프라의 운용이 가능합니다.

긴 글 읽어주셔서 감사합니다.
내용 피드백 및 오탈자 피드백은 must01940 지메일로 보내주시면 감사합니다.