설계 고려 사항

AWS Elastic Beanstalk를 사용하여 배포되는 애플리케이션은 AWS 클라우드 리소스에서 실행되므로 애플리케이션을 설계할 때 확장성, 보안, 영구 스토리지, 내결함성, 콘텐츠 전송, 소프트웨어 업데이트 및 패칭, 연결성을 고려해야 합니다. 이 주제에서는 각 항목에 대해 별도로 다룹니다. 아키텍처, 보안, 경제성 등의 주제를 다룬 포괄적인 기술 AWS 백서 목록은 AWS 클라우드 컴퓨팅 백서를 참조하세요.

확장성

클라우드 환경과 달리 물리적 하드웨어 환경에서 작동하는 경우 두 가지 방법 중 하나로 확장성에 액세스할 수 있습니다. 수직 배율 조정을 통해 스케일 업하거나 수평 배율을 통해 스케일 아웃할 수 있습니다. 스케일 업 방식을 사용하려면 강력한 하드웨어에 투자해야 하며, 이는 비즈니스의 증가하는 요구를 지원할 수 있습니다. 스케일 아웃 방식을 사용하려면 분산된 투자 모델을 따라야 합니다. 따라서 하드웨어 및 애플리케이션 인수를 더 많이 타겟팅할 수 있고, 데이터 세트가 페더레이션되고, 설계가 서비스 지향적일 수 있습니다. 스케일 업 접근 방법의 경우 상당한 비용이 들 수 있으며, 여전히 수요가 용량을 초과할 우려가 있습니다. 이와 관련하여 일반적으로 스케일 아웃 접근 방식이 더 효과적입니다. 그러나 이를 사용할 때는 정기적으로 수요를 예측하고 해당 수요를 충족하기 위해 인프라를 대량으로 배포할 수 있어야 합니다. 따라서, 이 접근 방법을 택할 경우 종종 미사용 용량이 발생할 수 있으므로 세심한 모니터링이 필요합니다.

클라우드로 마이그레이션하면 클라우드의 탄력성을 활용하여 인프라와 수요를 잘 맞출 수 있습니다. 탄력성은 리소스 확보 및 릴리스를 간소화하는 데 도움이 됩니다. 수요의 변동에 따라 인프라를 빠르게 스케일 인 및 스케일 아웃할 수 있습니다. 이 기능을 사용하려면 환경에 있는 리소스의 지표를 기준으로 확장하거나 축소하도록 Auto Scaling 설정을 구성합니다. 예를 들어 서버 사용률 또는 네트워크 I/O와 같은 지표를 설정할 수 있습니다. 컴퓨터 용량에 대해 Auto Scaling을 사용하여 사용량이 증가할 때마다 자동으로 추가되고 사용량이 떨어질 때마다 제거되도록 할 수 있습니다. 시스템 지표(예: CPU, 메모리, 디스크 I/O 및 네트워크 I/O)를 Amazon CloudWatch에 게시할 수 있습니다. 그런 다음 CloudWatch를 사용하여 Auto Scaling 작업을 트리거하거나 이러한 지표를 기반으로 알림을 전송하도록 경보를 구성할 수 있습니다. Auto Scaling 구성 방법에 대한 설명은 Elastic Beanstalk 환경에 대한 Auto Scaling 그룹 단원을 참조하세요.

또한 모든 Elastic Beanstalk 애플리케이션은 필요에 따라 확장할 수 있고 느슨하게 결합된 내결함성 구성 요소를 사용하며, 가급적 상태 비저장으로 설계하는 것이 좋습니다. AWS의 확장 가능한 애플리케이션 아키텍처 설계에 대한 자세한 내용은 AWS Well-Architected 프레임워크를 참조하세요.

보안

AWS의 보안은 공동 책임입니다. Amazon Web Services는 환경의 물리적 리소스를 보호하고 고객이 클라우드에서 애플리케이션을 안전하게 실행할 수 있도록 합니다. 고객은 Elastic Beanstalk 환경 안팎에서 오는 데이터의 보안과 애플리케이션의 보안을 책임집니다.

애플리케이션과 클라이언트 사이에 흐르는 정보를 보호하기 위해 SSL을 구성합니다. SSL을 구성하기 위해서는 AWS Certificate Manager(ACM)의 무료 인증서가 필요합니다. 이미 외부 인증 기관(CA)의 인증서를 갖고 있다면, ACM을 사용하여 해당 인증서를 가져올 수 있습니다. 또는 AWS CLI을 사용하여 가져올 수 있습니다.

ACM을 AWS 리전에서 사용할 수 없는 경우, VeriSign이나 Entrust 같은 외부 CA를 통해 인증서를 구매할 수 있습니다. 그 다음, AWS Command Line Interface(AWS CLI)를 사용하여 AWS Identity and Access Management(IAM)에 서드 파티 또는 자체 서명된 인증서와 프라이빗 키를 업로드할 수 있습니다. 이 인증서의 퍼블릭 키가 귀하의 서버에 대한 인증을 브라우저에 요청합니다. 또한 이는 데이터를 양방향으로 암호화하는 공유 세션 키를 만드는 기반 역할을 하기도 합니다. SSL 인증서를 생성 및 업로드하고 이를 환경에 할당하는 방법은 Elastic Beanstalk 환경에 사용할 HTTPS 구성 단원을 참조하세요.

환경에 대해 SSL 인증서를 구성하면 클라이언트와 환경의 Elastic Load Balancing 로드 밸런서 간에 데이터가 암호화됩니다. 기본적으로 암호화는 로드 밸런서에서 종료되고, 로드 밸런서와 Amazon EC2 인스턴스 간의 트래픽은 암호화되지 않습니다.

영구 스토리지

Elastic Beanstalk 애플리케이션은 영구 로컬 스토리지가 없는 Amazon EC2 인스턴스에서 실행됩니다. Amazon EC2 인스턴스가 종료되면 로컬 파일 시스템은 저장되지 않습니다. 새 Amazon EC2 인스턴스는 기본 파일 시스템으로 시작합니다. 영구 데이터 원본에 데이터를 저장하도록 애플리케이션을 구성하는 것이 좋습니다. AWS는 애플리케이션에 사용할 수 있는 다양한 영구 스토리지 서비스를 제공합니다. 다음 표에는 해당 항목이 나열됩니다.

스토리지 서비스	서비스 설명서	Elastic Beanstalk 통합
Amazon S3	Amazon Simple Storage Service 설명서	Amazon S3에서 Elastic Beanstalk 사용
Amazon Elastic File System	Amazon Elastic File System 설명서	Amazon Elastic File System에서 Elastic Beanstalk 사용
Amazon Elastic Block Store	Amazon Elastic Block Store 기능 설명서: Elastic Block Store
Amazon DynamoDB	Amazon DynamoDB 설명서	Amazon DynamoDB에서 Elastic Beanstalk 사용
Amazon Relational Database Service(RDS)	Amazon Relational Database Service 설명서	Amazon RDS와 함께 Elastic Beanstalk 사용

참고

Elastic Beanstalk는 웹앱 사용자를 생성하여 EC2 인스턴스에서 애플리케이션 디렉터리의 소유자로 설정할 수 있습니다. 또는 2022년 2월 3일 이후에 출시되는 Amazon Linux 2 플랫폼 버전의 경우, Elastic Beanstalk는 웹앱 사용자에게 새로운 환경에 대한 uid(사용자 ID) 및 gid(그룹 ID) 값 900을 할당합니다. 플랫폼 버전 업데이트 이후 기존 환경에서도 동일하게 작동합니다. 이 접근 방식을 통해 웹앱 사용자는 영구 파일 시스템 스토리지에 대한 일관된 액세스 허가를 유지할 수 있습니다.

드물게 발생하는 다른 사용자나 프로세스가 이미 900을 사용하고 있는 경우, 운영 체제는 웹앱 사용자 uid 및 gid의 기본값을 다른 값으로 지정합니다. EC2 인스턴스의 리눅스 명령 id webapp을 실행하여웹앱 사용자에 할당된 uid 및 gid 값을 확인합니다.

내결함성

경험상 클라우드의 아키텍처를 설계할 때 비관주의자가 되어야 합니다. 제공되는 탄력성을 활용하십시오. 항상 장애 시 자동 복구할 수 있도록 설계, 구현 및 배포합니다. Amazon EC2 인스턴스 및 Amazon RDS에 여러 가용 영역을 사용합니다. 가용 영역은 개념적으로 논리적 데이터 센터와 같습니다. Amazon CloudWatch를 사용하여 Elastic Beanstalk 애플리케이션의 상태를 보다 쉽게 파악하고 하드웨어 장애나 성능 저하 시 적절한 조치를 취합니다. 비정상 Amazon EC2 인스턴스를 새 인스턴스로 바꾸도록 Auto Scaling 설정을 구성하여 Amazon EC2 인스턴스를 일정한 크기로 유지합니다. Amazon RDS를 사용하는 경우 Amazon RDS가 자동 백업을 수행할 수 있도록 백업의 보존 기간을 설정합니다.

콘텐츠 전송

사용자가 웹 사이트에 연결하면 요청이 여러 개별 네트워크를 통해 라우팅될 수 있습니다. 따라서 사용자는 긴 지연 시간으로 인해 성능 저하를 경험할 수 있습니다. Amazon CloudFront는 전 세계 엣지 로케이션의 네트워크 전체에 걸쳐 이미지, 비디오와 같은 웹 콘텐츠를 배포하여 지연 시간 문제를 개선할 수 있습니다. 사용자의 요청이 가장 가까운 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능이 뛰어납니다. CloudFront는 최종 원본 파일을 영구적으로 저장하는 Amazon S3에서 원활하게 작동합니다. CloudFront에 대한 자세한 내용은 Amazon CloudFront 개발자 가이드를 참조하세요.

소프트웨어 업데이트 및 패치 적용

AWS Elastic Beanstalk는 플랫폼 업데이트를 정기적으로 릴리스하여 수정, 소프트웨어 업데이트 및 새 기능을 제공합니다. Elastic Beanstalk는 플랫폼 업데이트를 처리할 수 있는 몇 가지 옵션을 제공합니다. 관리형 플랫폼 업데이트는 애플리케이션을 계속 서비스하면서 예약된 유지 관리 기간 동안 환경을 최신 플랫폼 버전으로 자동 업그레이드합니다. 2019년 11월 25일 이후 Elastic Beanstalk 콘솔을 사용하여 생성한 환경에서는 가능할 때마다 관리형 업데이트가 기본적으로 활성화됩니다. Elastic Beanstalk 콘솔 또는 EB CLI를 사용하여 수동으로 업데이트를 시작할 수도 있습니다.

연결

배포를 완료하려면 Elastic Beanstalk를 환경의 인스턴스에 연결할 수 있어야 합니다. Amazon VPC 내부에 Elastic Beanstalk 애플리케이션을 배포하는 경우, 연결성을 지원하는 데 필요한 구성은 생성하는 Amazon VPC 환경의 유형에 따라 다릅니다.

• 단일 인스턴스 환경의 경우 추가 구성이 필요하지 않습니다. 이러한 환경에서 Elastic Beanstalk가 각 Amazon EC2 인스턴스에 퍼블릭 탄력적 IP 주소를 할당하여 인스턴스가 인터넷과 직접 통신할 수 있기 때문입니다.

• 퍼블릭 서브넷과 프라이빗 서브넷이 모두 있는 Amazon VPC의 로드 밸런싱 수행 및 확장 가능 환경의 경우 다음을 수행해야 합니다.

  • 인터넷에서 Amazon EC2 인스턴스로 인바운드 트래픽을 라우팅할 수 있도록 퍼블릭 서브넷에 로드 밸런서를 만듭니다.

  • 프라이빗 서브넷의 Amazon EC2 인스턴스에서 인터넷으로 아웃바운드 트래픽을 라우팅할 수 있도록 네트워크 주소 변환(NAT) 디바이스를 만듭니다.

  • 프라이빗 서브넷 내부에 Amazon EC2 인스턴스의 인바운드 및 아웃바운드 라우팅 규칙을 만듭니다.

  • NAT 인스턴스를 사용하는 경우, 인터넷 통신을 사용하도록 NAT 인스턴스와 Amazon EC2 인스턴스의 보안 그룹을 구성합니다.

• 퍼블릭 서브넷이 한 개 있는 Amazon VPC의 로드 밸런싱 수행 및 확장 가능 환경의 경우 추가 구성이 필요하지 않습니다. 이는 이러한 환경에서 Amazon EC2 인스턴스가 퍼블릭 IP 주소로 구성되어 인스턴스가 인터넷과 통신할 수 있도록 하기 때문입니다.

Amazon VPC와 함께 Elastic Beanstalk 사용에 대한 자세한 내용은 Amazon VPC에서 Elastic Beanstalk 사용 단원을 참조하십시오.