188. Docker 소개
컨테이너 섹션에 오신 걸 환영합니다
이번 섹션에서는 도커 ECS 및 EKS를 배워볼 거예요
도커란 무엇일까요?
도커는 앱 배포를 위한 소프트웨어 개발 플랫폼입니다. 컨테이너 기술이죠.
컨테이너에 앱이 패키징되는데 컨테이너는 표준화되어있어서 아무 운영체제에나 실행할 수 있어요.
다시 말해 앱이 컨테이너에 패키징되면 어느 운영체제에서든 같은 방식으로 실행되죠.
- 아무 머신이나 상관 없이
- 호환성 문제가 없습니다.
- 행위 특성도 예측 가능해서 작업을 덜어주고
- 유지 및 배포가 쉽고
- 언어, 운영체제, 기술에 상관 없이 실행이 가능하죠
도커의 사용 사례에는 마이크로서비스 아키텍처가 있어요. 이 키워드를 꼭 기억해두세요. 또 온프레미스에서 클라우드로 앱을 리프트-앤-시프트하기도 하고 컨테이너를 실행하는 어떤 경우에도 사용할 수 있어요.
도커는 운영체제에서 어떻게 작동할까요
우선 서버가 있겠죠. EC2 인스턴스를 예로 들었는데 어떤 유형의 서버든 똑같습니다. 도커 에이전트를 실행하면 도커 컨테이너를 시작할 수 있어요.
첫 번째 도커 컨테이너는 Java 애플리케이션을 포함하고 두 번째 도커 컨테이너에는 Node.js 애플리케이션 있다고 가정합시다. 다수의 도커 컨테이너가 동시에 실행될 수 있어서 Java 애플리케이션을 가진 여러 도커 컨테이너가 있을 수 있죠. Node.js 애플리케이션을 가진 도커 컨테이너도 여러 개 있을 수 있어요. 도커 내에서 MySQL 등의 데이터베이스도 실행 가능하니 아주 다용도로 활용됩니다. 서버 관점에서는 모두 도커 컨테이너로 보여요.
그럼 도커 이미지는 어디에 저장할까요? 바로 도커 리포지토리입니다.
여러 옵션이 있어요
- 첫 번째 옵션인 Docker Hub은 아주 유명한 퍼블릭 리포지토리로
- 많은 기술에 맞는 기본 이미지를 찾을 수 있습니다. Ubuntu나 MySQL과 같은 OS용 기본 이미지도 마찬가지죠.
프라이빗 리포지토리인 Amazon ECR 즉 Amazon Elastic Container Registry도 있어요
- 비공개 이미지를 실행할 수 있지만
- Amazon ECR Public Gallery라 불리는 퍼블릭 리포지토리 옵션도 있어요.
도커와 가상 머신의 차이점은 무엇일까요
도커 역시 가상화 기술의 일종이긴 하지만 순전히 가상화 기술은 아니에요.
리소스가 호스트와 공유되어 한 서버에서 다수의 컨테이너를 공유할 수 있습니다.
가상 머신의 아키텍처를 살펴보면 인프라와 호스트 운영체제가 있으며 그 위에 하이퍼바이저가 있고 앱과 Guest 운영 체제가 있어요. EC2의 원리죠. 다시 말해 EC2 머신은 하이퍼바이저에 실행되는 가상 머신과도 같아요. 그래서 Amazon이 EC2 인스턴스를 다양한 소비자에게 제공할 수 있으며 가상 머신의 EC2 인스턴스는 각자 분리되어 있습니다. 리소스를 공유하지 않죠.
반면 도커 컨테이너의 경우 인프라와 EC2 인스턴스 같은 호스트 OS가 있고 도커 Daemon 위에 많은 컨테이너가 있습니다. 도커 Daemon에서 가볍게 실행되는 컨테이너라 공존할 수 있는 거죠.
네트워킹이나 데이터 등을 공유할 수도 있어요. 소위 말해 가상 머신보다 덜 안전하지만 하나의 서버에 많은 컨테이너를 실행할 수 있기 때문에 도커 컨테이너를 많이 사용합니다.
도커를 시작하려면 우선 Dockerfile을 작성해야 해요. 도커 컨테이너를 구성하는 파일이죠. 베이스 도커 이미지에 몇 가지 파일을 추가해서 구축하면 도커 이미지가 됩니다. 도커 이미지는 푸시(push)를 해서 도커 리포지토리에 저장할 수 있어요. 퍼블릭 리포지토리인 Docker Hub에 푸시하거나 Amazon 버전의 도커 리포지토리인 Amazon ECR에 푸시합니다. 나중에 도커 리포지토리에서 이미지를 가져와서 실행하게 되는데 도커 이미지를 실행하면 도커 컨테이너가 되고 도커를 구축할 때 사용했던 코드를 실행할 겁니다. 이게 도커의 모든 과정이에요
AWS에서 도커 컨테이너를 어떻게 관리하는지 궁금하시죠
첫 번째는 Amazon ECS 즉 Elastic Container Service입니다. 도커 관리를 위한 Amazon의 전용 플랫폼이죠. 곧이어 자세히 살펴볼 예정이에요.
Amazon EKS 즉 Elastic Kubernetes Service는 Kubernetes의 관리형 버전으로 오픈 소스 프로젝트입니다. 차후에 간단히 살펴볼게요
AWS Fargate는 Amazon의 서버리스 컨테이너 플랫폼으로 ECS와 EKS 둘 다 함께 작동할 수 있습니다. 섹션 중에 Fargate에 대해 더 자세히 배워 보죠.
Amazon ECR은 전에 보여드렸듯이 컨테이너 이미지를 저장하는 데 사용합니다. 이렇게 도커가 무엇이며 AWS에서 어떻게 사용하는지 알아봤어요. 이제 Amazon ECS부터 차례로 배워봅시다.
189. Amazon ECS
자, Amazon ECS를 배워봅시다. 다양한 관점에서 전반적으로 볼 겁니다. 처음으로 볼 내용은 EC2 시작 유형(Launch Type)입니다.
ECS는 Elastic Container Service의 약어로 AWS에서 컨테이너를 실행하면 ECS 클러스터에 이른바 ECS 태스크를 실행하는 거죠.
ECS 클러스터에는 들어있는 게 있는데 EC2 시작 유형을 사용하면 EC2 인스턴스가 들어있겠죠. EC2 시작 유형으로 EC2 클러스터를 사용할 때는 인프라를 직접 프로비저닝하고 유지해야 해요.
즉 Amazon ECS 및 ECS 클러스터가 여러 EC2 인스턴스로 구성되겠죠.
이때 ECS 인스턴스는 특별하게 각각 ECS 에이전트(Agent)를 실행해야 합니다. 그럼 ECS 에이전트가 각각의 EC2 인스턴스를 Amazon ECS 서비스와 지정된 ECS 클러스터에 등록해요.
이후에 ECS 태스크를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈출 겁니다. 즉 새 도커 컨테이너가 생기면 도식에서 볼 수 있듯 시간에 따라 EC2 인스턴스에 지정될 거예요. ECS 태스크를 시작하거나 멈추면 자동으로 위치가 지정되죠. 바로 이게 EC2 시작 유형입니다. 도커 컨테이너는 미리 프로비저닝한 Amazon EC2 인스턴스에 위치해요.
두 번째 시작 유형은 Fargate 시작 유형이예요. 마찬가지로 AWS에 도커 컨테이너를 실행하는데 이번에는 인프라를 프로비저닝하지 않아 관리할 EC2 인스턴스가 없습니다. 서버리스죠.
서버를 관리하지 않아 서버리스라 부르는데 서버가 없는 건 아니죠.
Fargate 유형은 ECS 클러스터가 있을 때 ECS 태스크를 정의하는 태스크 정의만 생성하면 필요한 CPU나 RAM에 따라 ECS 태스크를 AWS가 대신 실행합니다.
즉 새 도커 컨테이너를 실행하면 어디서 실행되는지 알리지 않고 그냥 실행됩니다. 작업을 위해 백엔드에 EC2 인스턴스가 생성될 필요도 없어요. 아주 신기하죠.
확장하려면 간단하게 태스크 수만 늘리면 돼요. EC2 인스턴스를 관리할 필요가 없습니다. 시험에서는 서버리스인 Fargate를 사용하라는 게 자주 나오는데요. EC2 시작 유형보다 관리가 쉽기 때문입니다. Amazon ECS의 두 가지 시작 유형을 알아봤으니 ECS 태스크의 IAM 역할로 넘어갑시다.
EC2 시작 유형의 예시로 EC2 인스턴스가 도커에 ECS 에이전트를 실행한다고 합시다.
EC2 시작 유형을 사용한다면 EC2 인스턴스 프로파일을 생성하겠죠.
- ECS 에이전트만이 EC2 인스턴스 프로파일을 사용하며
- 그 EC2 인스턴스 프로파일을 이용해 API 호출을 할 겁니다
- 그럼 인스턴스가 저장된 ECS 서비스가 CloudWatch 로그에 API 호출을 해서 컨테이너 로그를 보내고
- ECR로부터 도커 이미지를 가져오죠.
- Secrets Manager나 SSM Parameter Store에서 민감 데이터를 참고하기도 합니다
ECS 태스크는 ECS 태스크 역할을 가집니다. 이는 EC2와 Fargate 시작 유형에 모두 해당되며
- 두 개의 태스크가 있다면 각자에 특정 역할을 만들 수 있어요. 도식에 모자처럼 태스크 A는 EC2 태스크 A 역할을 맡고 태스크 B는 EC2 태스크 B 역할을 맡는 거죠.
- 역할을 다르게 하는 이유는 무엇일까요. 역할이 각자 다른 ECS 서비스에 연결할 수 있게 하기 때문입니다. 예를 들어 EC2 태스크 A 역할은 태스크 A가 Amazon S3에 API 호출을 실행할 수 있도록 한다면 태스크 B 역할은 DynamoDB에 API 호출을 실행할 수 있도록 하죠.
- ECS 서비스의 태스크 정의에서 태스크의 역할을 정의해요. 이러한 EC2 인스턴스 프로파일 역할과 ECS 태스크 역할의 차이점을 기억하세요.
다음은 로드 밸런서 통합입니다
EC2 시작 유형을 예로 들었지만 Fargate 시작 유형도 마찬가지예요. 여기 여러 ECS 태스크들이 실행되며 ECS 클러스터 안에 있습니다. HTTP나 HTTPS 엔드 포인트로 태스크를 활용하기 위해 애플리케이션 로드 밸런서(ALB)를 앞에서 실행하면 모든 사용자가 ALB 및 백엔드의 ECS 태스크에 직접 연결되죠
ALB는 이 경우를 포함해, 대부분의 사용 사례를 지원하는 좋은 옵션이죠.
한편 네트워크 로드 밸런서(NBL)는 처리량이 매우 많거나 높은 성능이 요구될 때만 권장합니다. 추후 강의에서 배우겠지만 AWS Private Link와 사용할 때도 권장되는 옵션이죠.
구세대 Elastic Load Balancer(ELB)는 사용할 수는 있지만 권장하지는 않아요. 고급 기능이 없을 뿐더러 ELB는 Fargate에 연결할 수 없기 때문입니다. 반면 애플리케이션 로드 밸런서(ALB)는 Fargate와도 사용할 수 있죠.
그럼 Amazon ECS의 데이터 지속성을 알아볼까요. 데이터 볼륨이 필요하며 여러 종류가 있는데 그 중 하나가 EFS에서 자주 사용됩니다.
ECS 클러스터에 EC2 인스턴스와 Fargate 시작 유형 둘 다 구현했다고 가정합시다.
EC2 태스크에 파일 시스템을 마운트해서 데이터를 공유하려고 해요. 그러면 Amazon EFS 파일 시스템을 사용하는 게 좋겠죠.
네트워크 파일 시스템이라 EC2와 Fargate 시작 유형 모두 호환이 되며 EC2 태스크에 파일 시스템을 직접 마운트할 수 있거든요. 어느 AZ에 실행되는 태스크든 Amazon EFS에 연결되어 있다면 데이터를 공유할 수 있고 원한다면 파일 시스템을 통해 다른 태스크와 연결할 수 있기 때문이죠.
따라서 Fargate로 서버리스 방식으로 ECS 태스크를 실행하고 파일 시스템 지속성을 위해서는 Amazon EFS를 사용하는 게 가장 좋아요. EFS 역시 서버리스이기 때문에 서버를 관리할 필요 없고 미리 비용을 지불하죠. 미리 프로비저닝하기만 하면 바로 사용할 수 있습니다.
사용 사례로는 EFS와 ECS를 함께 사용해서 다중 AZ가 공유하는 컨테이너의 영구 스토리지가 있어요.
하나 알아 두어야 할 게 있는데 Amazon S3는 ECS 태스크에 파일 시스템으로 마운트될 수 없어요.
190. Important: ECS UI Changes
191. ECS 클러스터 생성하기 - 실습
192. ECS 서비스 생성하기 - 실습
193. Amazon ECS - 오토 스케일링
자 ECS 서비스 오토 스케일링을 배워봅시다
지난 강의에서는 서비스에 ECS 태스크 수를 수동으로 늘렸었죠. 하지만 태스크 수를 자동으로 늘리거나 줄일 수도 있습니다.
AWS의 Auto Scaling이라는 서비스를 사용하면 세 개의 지표에 대해 확장이 가능합니다.
- ECS 서비스의 CPU 사용률을 확장할 수 있고
- 메모리 사용률 즉 ECS 서비스의 RAM이나
- ALB 관련 지표인 타겟당 요청 수를 확장할 수 있어요
세 개의 지표만 기억하시면
다양한 오토 스케일링을 설정할 수 있습니다. 특정 타겟을 추적하는 대상 추적(Target Tracking) 스케일링이나
단계(Step) 스케일링
혹은 미리 ECS 서비스 확장을 설정하는 예약(Scheduled) 스케일링 등이 있죠
EC2 시작 유형이라면 태스크 레벨에서의 ECS 서비스 확장이 EC2 인스턴스 클러스터의 확장과 다르다는 사실을 기억하세요.
따라서 EC2 오토 스케일링이 필요하지 않다면 즉 백엔드에 EC2 인스턴스가 없다면 Fargate를 사용하는 것이 서비스 오토 스케일링에 도움이 되겠죠. 전부 서버리스니까요. 저 역시 Fargate를 아주 좋아하며 시험에서도 Fargate 사용을 권장하죠.
그럼 EC2 시작 유형에서는 백엔드의 EC2 인스턴스를 어떻게 자동으로 확장할까요.
스케일링에서 여러 방법이 있는데 그 중 하나가 오토 스케일링 그룹입니다.
- CPU 사용률에 따라 ASG를 확장한다고 하면
- CPU 사용률이 급등할 때 EC2 인스턴스를 추가할 수 있겠죠.
아니면 이전 실습에서 본 것처럼 더 최신 기능인 ECS 클러스터 용량 공급자를 사용할 수 있습니다.
- 용량 공급자(Capacity Provider)는 아주 똑똑해요. 새 태스크를 실행할 용량이 부족하면 자동으로 ASG를 확장하죠.
- Capacity Provider는 오토 스케일링 그룹과 함께 사용되며
- RAM이나 CPU가 모자랄 때 EC2 인스턴스를 추가합니다. 두 번째 방법을 사용하는 게 좋아요. 오토 스케일링 그룹과 ECS 클러스터 용량 공급자 중에 EC2 시작 유형의 경우 EC2 클러스터 용량 공급자를 사용하세요.
서비스 예시를 한 번 볼까요
서비스 A에 태스크 두 개가 실행 중이고 CPU 사용량은 이 정도입니다. 이 서비스는 AWS 애플리케이션 오토 스케일링으로 자동 확장됩니다. 만약 사용자가 훨씬 많아져서 CPU 사용량이 급증하면 ECS 서비스 레벨에서 CPU 사용량을 모니터링하는 CloudWatch 지표가 CloudWatch 알람을 트리거하죠. 이어서 이 알람이 오토 스케일링을 또 트리거하면 ECS 서비스의 희망 용량이 증가하고 새 태스크가 생성되게 됩니다. 또 EC2 시작 유형에서 실행되는 서비스라면 ECS 용량 공급자가 EC2 인스턴스를 추가해 ECS 클러스터를 확장할 겁니다.
194. Amazon ECS - 솔루션 아키텍트
Amazon EC2에서 접할 수 있는 몇 가지 솔루션 아키텍처를 배워봅시다
첫 번째는 EventBridge로 작동되는 ECS 태스크입니다. Amazon ECS 클러스터가 있고 이와 함께 Fargate와 S3 버킷이 있는 예시를 봅시다. 사용자가 S3 버킷에 객체를 업로드하겠죠. 이때 S3가 Amazon EventBridge와 통합되어 이벤트를 모두 보낼 수 있어요. Amazon EventBridge에는 ECS 태스크를 실행하는 규칙을 만들 수 있습니다. 그럼 ECS 태스크가 생성되고 관련 ECS 태스크 역할이 주어지겠죠. 태스크는 객체를 받아 처리하고 Amazon DynamoDB에 결과를 보내게 됩니다. ECS 태스크 역할이 결합된 덕분이죠. 이렇게 도커 컨테이너를 이용해 S3 버킷으로부터 이미지나 객체를 처리하는 서버리스 아키텍처를 완성했어요. Amazon EventBridge와 ECS Fargate 모드 S3와 소통하는 ECS 태스크 역할 또 Amazon DynamoDB를 사용했습니다.
두 번째 아키텍처 예시는 EventBridge Schedule(일정)입니다. Fargate와 EventBridge를 사용하는 ECS 클러스터가 있다고 가정합시다. 한 시간마다 트리거되는 규칙의 일정을 만들면 Fargate에서 ECS 태스크를 실행할 겁니다. 즉 한 시간마다 Fargate 클러스터에 새 태스크가 생성되겠죠. 태스크에는 자유롭게 Amazon S3에 접근 가능한 ECS 태스크 역할 등을 생성하면 태스크, 도커 컨테이너, 프로그램이 Amazon S3의 파일에 대해 한 시간마다 배치(Batch) 처리를 하게 됩니다. 이때 아키텍처는 서버리스예요.
마지막 예시는 SQS 대기열입니다. ECS의 서비스에 두 개의 태스크가 있고 SQS 대기열에 메시지를 전송했다고 합시다. 서비스 자체적으로 SQS 대기열로부터 메시지를 가져와서(poll) 처리하겠죠. 여기에 ECS 서비스 오토 스케일링을 활성화하면 SQS 대기열에 메시지가 많아질수록 ECS 서비스에 태스크가 많아집니다 여기까지 몇 가지 ECS 아키텍처를 소개해드렸어요.
195. Amazon ECR
Amazon ECR은 Elastic Container Registry의 줄임말로 AWS에 도커 이미지를 저장하고 관리하는 데 사용됩니다
지금까지 Docker Hub 등의 온라인 저장소를 활용했는데
이미지를 Amazon ECR에도 저장할 수 있는 거죠. ECR에는 두 가지 옵션이 있어요.
- 첫 번째는 계정에 한해 이미지를 비공개로 저장하는 건데 여러 계정으로 설정할 수도 있죠
- 혹은 퍼블릭 저장소를 사용해 Amazon ECR Public Gallery에 게시하는 방법이 있습니다
ECR은 Amazon ECS와 완전히 통합되어 있고 이미지는 백그라운드에서 Amazon S3에 저장됩니다.
ECR 저장소에 여러 도커 이미지가 있는데 ECS 클러스터의 EC2 인스턴스에 이미지를 끌어오기 위해서는 EC2 인스턴스에 IAM 역할을 지정하면 됩니다. IAM 역할이 도커 이미지를 인스턴스에 끌어올 거예요.
ECR에 대한 모든 접근은 IAM이 보호하고 있죠. ECR에 권한 에러가 생긴다면 정책을 살펴보세요.
EC2 인스턴스에 이미지를 끌어온 후에는 컨테이너가 시작됩니다. ECS와 ECR이 이런 식으로 함께 작동해요.
Amazon ECR은 단순히 저장하는 리포지토리에 그치지 않고 이미지의 취약점 스캐닝, 버저닝 태그 및 수명 주기 확인을 지원합니다. 정리하자면, 도커 이미지를 저장할 때는 ECR을 기억하세요. 시험에 출제될 수 있습니다. 그럼 다음 강의에서 또 만나요 수고하셨습니다.
196. EKS 개요
이번에는 Amazon EKS를 이용하여 AWS에 컨테이너를 실행해 보겠습니다
Amazon EKS는 Amazon Elastic Kubernetes Service의 약자입니다.
AWS에 관리형 Kubernetes 클러스터를 실행할 수 있는 서비스입니다. 화면 우측 상단의 파란색 로고가 Kubernetes 로고예요.
Kubernetes는 오픈 소스 시스템으로 Docker로 컨테이너화한 애플리케이션의 자동 배포, 확장, 관리를 지원합니다.
컨테이너를 실행한다는 목적은 ECS와 비슷하지만 사용하는 API가 다릅니다. ECS는 오픈 소스가 아닌 반면 Kubernetes는 오픈 소스이고 여러 클라우드 제공자가 사용하므로 표준화를 기대할 수 있습니다.
EKS에는 두 가지 실행 모드가 있습니다. EC2 시작 모드는 EC2 인스턴스에서처럼 작업자 모드를 배포할 때 사용하고 Fargate 모드는 EKS 클러스터에 서버리스 컨테이너를 배포할 때 사용합니다.
EKS의 사용 사례는 다음과 같습니다. 회사가 온프레미스나 클라우드에서 Kubernetes나 Kubernetes API를 사용 중일 때 Kubernetes 클러스터를 관리하기 위해 Amazon EKS를 사용합니다. 시험에 나올 수 있어요
Kubernetes는 클라우드 애그노스틱으로 Azure, Google Cloud 등 모든 클라우드에서 지원됩니다. 따라서 클라우드 또는 컨테이너 간 마이그레이션을 실행하는 경우 Amazon EKS가 간단한 솔루션이 될 수 있습니다.
도표로 살펴보면 이렇습니다
VPC와 세 AZ가 있고 각 AZ는 퍼블릭 및 프라이빗 서브넷으로 나뉩니다. EKS 작업자 노드를 생성하면 EC2 인스턴스가 구성되겠죠. 각 노드는 EKS 포드를 실행합니다. ECS 태스크와 유사합니다만 이름에서 포드를 발견하면 Amazon Kubernetes와 관련된 거라고 생각하면 됩니다. EKS 포드가 실행되는 EKS 노드는 오토 스케일링 그룹으로 관리할 수 있습니다. ECS와 유사하게 EKS 서비스나 Kubernetes 서비스를 노출할 때는 프라이빗 로드 밸런서나 퍼블릭 로드 밸런서를 설정해 웹에 연결해야 합니다.
Amazon EKS의 여러 노드 유형을 정리해 보도록 하죠
먼저 관리형 노드 그룹은
- AWS로 노드, 즉 EC2 인스턴스를 생성하고 관리합니다
- 노드는 EKS 서비스로 관리되는 오토 스케일링 그룹의 일부입니다
- 온디맨드 인스턴스와 스팟 인스턴스를 지원합니다
자체 관리형 노드를 선택할 수도 있어요 사용자 지정 사항이 많고 제어 대상이 많은 경우
- 여러분이 직접 노드를 생성하고 EKS 클러스터에 등록한 다음 ASG의 일부로 관리해야 합니다.
- 사전 빌드된 AMI인 Amazon EKS 최적화 AMI를 사용하면 시간을 절약할 수 있습니다. 자체 AMI를 빌드해도 되지만 복잡할 수 있어요.
- 이 역시 온디맨드 인스턴스와 스팟 인스턴스를 지원합니다.
끝으로 노드를 원치 않는 경우에는 Amazon EKS가 지원하는 Fargate 모드를 선택하면
- 유지 관리도 필요 없고 노드를 관리하지 않아도 되며 Amazon EKS에서 컨테이너만 실행하면 됩니다.
Amazon EKS 클러스터에 데이터 볼륨을 연결하려면
EKS 클러스터에 스토리지 클래스 매니페스트를 지정해야 합니다
컨테이너 스토리지 인터페이스(CSI)라는 규격 드라이버를 활용하는데 시험에 나올 만한 키워드예요.
Amazon EBS와 Fargate 모드가 작동하는 유일한 스토리지 클래스 유형인 Amazon EFS를 지원하고 Amazon FSx for Lustre와 Amazon FSx for NetApp ONTAP을 지원합니다.
197. Amazon EKS - Hands On(실습)
198. AWS App Runner
AWS App Runner 서비스를 살펴보겠습니다
완전 관리형 서비스로 규모에 따라 웹 애플리케이션, API 배포를 돕습니다.
이 서비스로는 누구나 AWS에 배포를 할 수 있습니다.
인프라나 컨테이너, 소스 코드 등을 알 필요가 전혀 없죠.
먼저 소스 코드나 Docker 컨테이너 이미지를 가지고 원하는 구성을 설정합니다. vCPU의 수나 컨테이너 메모리의 크기 오토 스케일링 여부 상태 확인을 설정하면 됩니다. 웹 애플리케이션이나 API에 들어갈 기본 설정을 설정하는 겁니다.
다음 작업은 자동으로 이뤄집니다. App Runner 서비스가 웹 앱을 빌드하고 배포하죠. 컨테이너가 생성되고 배포됩니다. API나 웹 앱이 배포된 다음엔 URL을 통해 바로 액세스할 수 있습니다. 이처럼 배후에서 어떤 작업이 이뤄지는지 전혀 몰라도 배포할 수 있습니다. 배후에서 AWS 서비스가 사용되는 것이겠지만 사용자는 굳이 몰라도 빠른 배포를 할 수 있습니다.
App Runner에는 장점이 많습니다. 오토 스케일링이 가능하고 가용성이 높으며 로드 밸런싱 및 암호화 기능을 지원합니다.
애플리케이션, 즉 컨테이너가 VPC에 액세스할 수도 있어서
데이터베이스와 캐시 메시지 대기열 서비스에 연결할 수 있습니다.
사용 사례로는 빨리 배포해야 하는 웹 앱, API 그리고 마이크로서비스가 있습니다. 신속한 프로덕션 배포가 필요할 때도 가장 좋은 방법은 AWS App Runner 서비스를 사용하는 것이고요. 아주 간단한 서비스지만 상당히 강력합니다. 유익한 강의였길 바라며 다음 강의에서 뵙겠습니다.
