Amazon Web Services 한국 블로그

AWS App Runner – 손쉽게 코드를 높은 확장성의 안전한 웹 애플리케이션 배포하기

컨테이너는 웹 애플리케이션을 패키징하는 기본 방법이 되었습니다. 저는 컨테이너가 제공하는 속도, 생산성 및 일관성을 선호하지만 컨테이너 개발 워크 플로우에는 컨테이너 이미지를 처음 배포할 때 오래 걸리는 루틴이 하나의 단점입니다.

여러분은 로드 밸런서 설정, 도메인 구성, TLS 설정, CI/CD 파이프라인 생성 및 컨테이너 서비스에 배포와 같은 이 루틴을 인식할 수도 있습니다.

수년에 걸쳐 워크플로를 조정해 왔으며 이제는 사용하는 상용구 AWS Cloud Development Kit 프로젝트가 있지만 이 단계에 도달하는 데는 오랜 시간이 걸렸습니다. 이 상용구 프로젝트는 대규모 애플리케이션에 매우 유용하지만 단일 컨테이너 이미지를 배포하고 확장만 하려는 경우 많은 작업이 필요합니다.

AWS에는 컨테이너화된 애플리케이션을 세부적으로 제어할 수 있는 다양한 서비스가 있지만, 많은 고객이 AWS에서 컨테이너 환경의 구성 및 운영을 처리할 수 있는지 물었습니다. 그들은 단지 기존 코드 또는 컨테이너 리포지토리를 가리키고 인프라 서비스를 구성 및 관리할 필요가 없이 클라우드에서 애플리케이션을 실행하고 확장하고자 합니다.

고객이 더 간단한 것을 만들도록 요청했기에 당사의 엔지니어는 고객이 좋아할 새로운 서비스를 만들기 위해 열심히 노력했습니다.

AWS App Runner소개
AWS App Runner를 사용하면 컨테이너나 인프라를 배포하고 관리하는 경험이 없는 팀에서 조차도 작성된 언어에 관계없이 웹 앱과 API를 클라우드에 쉽게 배포할 수 있습니다. 이 서비스에는 AWS 운영 및 보안 모범 사례가 내장되어 있으며, 즉시 자동 확장 또는 축소되므로 완전 시작을 걱정할 필요가 없습니다.

소스에서 배포
App Runner는 소스 코드 또는 컨테이너 레지스트리에 연결하여 앱을 배포할 수 있습니다. 먼저 소스 코드에 연결할 때 어떻게 작동하는지 보여 드리겠습니다. GitHub 리포지토리에 Python 웹 애플리케이션이 있습니다. App Runner를 이 프로젝트에 연결하여 코드를 컴파일하고 AWS에 배포하는 방법을 확인할 수 있도록 하겠습니다.

App Runner 콘솔에서 App Runner 서비스 만들기를 선택합니다.

App Runner 콘솔의 스크린샷

리포지토리 유형의 경우 소스 코드 리포지토리를 선택한 다음 지침에 따라 서비스를 GitHub 계정에 연결합니다. 리포지토리의 경우 배포하려는 애플리케이션이 포함된 리포지토리를 선택합니다. 브랜치메인을 선택합니다.

콘솔의 소스 및 배포 섹션 스크린샷

배포 트리거자동을 선택합니다. 즉, App Runner에서 내 소스 코드에 대한 변경 사항을 발견하면 업데이트된 버전을 자동으로 빌드하고 내 App Runner 서비스에 배포합니다.

콘솔의 배포 설정 섹션의 스크린샷

이제 빌드를 구성할 수 있습니다. 런타임으로는 Python 3을 선택합니다. 이 서비스는 현재 Python과 Node.js의 두 가지 언어를 지원합니다. 다른 언어가 필요한 경우 컨테이너 레지스트리 워크플로를 사용해야 합니다(이는 나중에 설명할 것입니다). 또한 다음과 같이 빌드 명령, 시작 명령포트 필드를 완료합니다.

콘솔의 빌드 구성 섹션의 스크린 샷

이제 내 서비스에 이름을 지정하고 컨테이너에 사용할 CPU 및 메모리 크기를 선택합니다. 여기에서의 선택은 지불하는 가격에 영향을 미칠 것입니다. 내 애플리케이션에는 CPU 또는 메모리가 거의 필요하지 않으므로 비용을 낮추기 위해 vCPU 1개와 2GB를 선택합니다. 내 애플리케이션을 구성하기 위해 여기에 환경 변수를 제공할 수도 있습니다.

콘솔의 서비스 구성 섹션 스크린 샷

콘솔을 사용하면 서비스에 대한 여러 가지 설정을 사용자 정의할 수 있습니다.

자동 크기 조정 동작을 구성할 수 있습니다. 기본적으로 내 서비스에는 컨테이너 이미지의 인스턴스가 하나 있지만 서비스가 80개 이상의 동시 요청을 수신하면 여러 인스턴스로 확장됩니다. 선택적으로 원가 관리를 위한 최대 수를 지정할 수 있습니다.

상태 확인을 확장하고 App Runner가 상태 확인 요청을 보내는 경로를 설정할 수 있습니다. 경로를 설정하지 않으면 App Runner는 상태를 확인하기 위해 TCP 연결을 시도합니다. 기본적으로 App Runner가 5회 연속 상태 확인 실패를 받으면 인스턴스를 비정상으로 간주하고 대체합니다.

보안을 확장하고 인스턴스에서 사용할 IAM 역할을 선택할 수 있습니다. 그러면 컨테이너에 다른 AWS 서비스와 통신할 수 있는 권한이 부여됩니다. App Runner는 내 애플리케이션 소스 이미지 또는 소스 번들의 저장된 모든 복사본을 암호화합니다. 고객 관리 키(CMK)를 제공하면 App Runner가 키를 사용하여 소스를 암호화합니다. 제공하지 않으면 App Runner는 AWS 관리 키를 대신 사용합니다.

콘솔의 스크린샷

마지막으로 서비스 구성을 검토한 다음 만들기 및 배포를 선택합니다.

콘솔의 검토 및 만들기 섹션의 스크린샷

몇 분 후 애플리케이션이 배포되고 서비스에서 배포된 웹 애플리케이션을 가리키는 URL을 제공했습니다. App Runner는 https의 구성을 보장하여 브라우저 보안 경고를 받지 않고 애플리케이션을 테스트하기 위해 팀의 누군가와 이를 공유할 수 있습니다. 컨테이너 이미지에서 HTTPS 보안 트래픽 처리를 구현할 필요가 없습니다. App Runner에서 모든 것을 구성합니다.

이제 사용자 지정 도메인을 설정하려고합니다. 이 서비스를 사용하면 콘솔을 떠나지 않고도 구성할 수 있습니다. 서비스를 열고 사용자 지정 도메인 탭을 선택한 다음 도메인 추가를 선택합니다.

콘솔의 사용자 지정 도메인 섹션의 스크린샷

도메인 이름에서 앱에 사용할 도메인을 입력한 다음 저장을 선택합니다.

사용자 지정 도메인을 추가하는 사용자의 스크린샷

도메인의 소유권을 증명하면 내 사용자 지정 URL에서 앱을 사용할 수 있습니다. 다음으로, App Runner가 컨테이너 이미지와 작동하는 방법을 보여드리겠습니다.

컨테이너 이미지에서 배포
.NET 웹 애플리케이션을 만들어 컨테이너 이미지로 만든 다음 이 컨테이너 이미지를 Amazon ECR Public(당사의 공개 컨테이너 레지스트리)에 푸시했습니다.

첫 번째 데모에서와 마찬가지로 서비스 만들기를 선택합니다. 소스 및 배포에서 저장소 유형으로 컨테이너 레지스트리를 선택합니다. 공급자로는 Amazon ECR Public을 선택합니다. 컨테이너 이미지 URI에 이미지의 URI를 입력합니다.

이제 배포 설정은 배포를 수동으로 트리거하는 옵션만 제공합니다. 이는 Amazon ECR Public을 선택했기 때문입니다. 컨테이너가 변경될 때마다 배포하려면 공급자Amazon ECR을 선택해야 합니다.

콘솔의 소스 및 배포 섹션 스크린샷

이 시점부터 지침은 “소스에서 배포” 섹션의 지침과 동일합니다. 배포 후 서비스는 URL을 제공하고 애플리케이션은 인터넷에서 라이브입니다.

실행 중인 앱의 스크린샷

알아야 할 사항
App Runner는 컨테이너 인스턴스에서 임시 저장소로 파일 시스템을 구현합니다. 파일은 임시 파일입니다. 예를 들어 App Runner 서비스를 일시 중지하고 다시 시작할 때 지속되지 않습니다. 보다 일반적으로 파일은 애플리케이션의 상태를 저장하지 않는 특성의 일환으로 단일 요청 처리 이상으로 유지되도록 보장되지 않습니다. 그러나 저장된 파일은 수명 기간 동안 App Runner 서비스의 저장소 할당의 일부를 차지합니다. 임시 저장소 파일은 요청 간의 유지가 보장되지는 않지만 때때로 지속될 수 있습니다. 사용자는 기회적으로 이를 활용할 수 있습니다. 예를 들어 요청을 처리할 때 향후 요청에 필요할 경우 응용 프로그램에서 다운로드하는 파일을 캐시할 수 있습니다. 이렇게하면 향후 요청 처리 속도가 빨라질 수 있지만 속도 향상을 보장 할 수는 없습니다. 코드에서는 이전 요청에서 다운로드된 파일이 여전히 존재한다고 가정해서는 안됩니다. 보장된 캐싱을 위해서는 Amazon ElastiCache와 같이 처리량이 높고 지연 시간이 짧은 인메모리 데이터 스토어를 사용하십시오.

파트너의 작동 방식
지금까지 App Runner와 통합하기 위해 MongoDB, Datadog 및 HashiCorp와 같은 파트너와 협력해 왔습니다. 다음은 그들이 진행하고 있는 작업을 간략히 설명합니다.

MongoDB — “App Runner와 MongoDB Atlas를 통합하여 개발자들이 App Runner 애플리케이션을 위한 글로벌 클라우드 네이티브 데이터베이스 서비스의 확장성과 성능을 활용할 수 있게 되어 기쁩니다.”

Datadog — “이제 고객은 AWS App Runner를 사용하여 컨테이너 이미지 또는 소스 코드 리포지토리에서 웹 애플리케이션을 더욱 쉽게 배포하고 확장할 수 있습니다. 새로운 통합을 통해 고객은 App Runner 메트릭, 로그 및 이벤트를 모니터링하여 문제를 더 빠르게 해결하고 앱에 가장 적합한 리소스와 확장 설정을 결정할 수 있습니다.”

HashiCorp — “HashiCorp Terraform과 AWS App Runner를 통합하면 개발자가 구성 및 관리할 인프라가 줄어들고 프로덕션 클라우드 애플리케이션을 더 빠르고 쉽게 배포할 수 있습니다.”

또한 App Runner 고객이 이미 알고 신뢰하는 도구와 서비스를 사용할 수 있도록 해주는 Pulumi, Logz.io, Trek10, Sysdig의 흥미로운 통합도 있습니다.

가용성 및 요금
AWS App Runner는 현재 미국 동부 (버지니아 북부), 미국 서부 (오레곤), 미국 동부 (오하이오), 아시아 태평양 (도쿄), 유럽 (아일랜드)에서 사용할 수 있습니다. AWS 관리 콘솔 및 AWS Copilot CLI와 App Runner를 사용할 수 있습니다.

App Runner를 사용하면 애플리케이션에서 사용하는 컴퓨팅 및 메모리 리소스에 대한 비용을 지불하게 됩니다. App Runner는 애플리케이션의 처리 요구 사항에 맞게 활성 컨테이너의 수를 자동으로 늘리고 축소합니다. 비용이 예산을 초과하지 않도록 애플리케이션에서 사용하는 컨테이너 수에 최대 제한을 설정할 수 있습니다.

App Runner가 실행 중일 때만 요금이 청구되며 애플리케이션을 쉽게 일시 중지하고 신속하게 다시 시작할 수 있습니다. 이 기능은 애플리케이션을 사용하지 않을 때 애플리케이션을 끌 수 있으므로 비용을 관리하는 데 도움이 되고 개발 및 테스트 상황에서 특히 유용합니다. 자세한 내용은 App Runner 요금 페이지를 참조하십시오.

지금 AWS App Runner를 사용하여 웹 애플리케이션을 대규모로 빠르고 안전하게 실행할 수 있습니다.

– Martin