애플리케이션 설계

애플리케이션에 대한 작업 정의를 생성하여 애플리케이션을 설계합니다. 작업 정의에는 다음을 포함하여 응용 프로그램에 대한 정보를 정의하는 매개 변수가 포함됩니다.

• 사용할 시작 유형에 따라 작업이 호스팅되는 인프라가 결정됩니다.

  EC2 시작 유형을 사용할 때는 인스턴스 유형도 선택합니다. GPU와 같은 일부 인스턴스 유형의 경우 추가 파라미터를 설정해야 합니다. 자세한 설명은 작업 정의 사용 사례 섹션을 참조하세요.

• 컨테이너 이미지에는 애플리케이션 코드와 애플리케이션 코드를 실행하는 데 필요한 모든 종속성이 들어 있습니다.

• 작업의 컨테이너에 사용할 네트워킹 모드

  네트워킹 모드는 작업이 네트워크를 통해 통신하는 방식을 결정합니다.

  EC2 인스턴스에서 실행되는 작업의 경우 여러 옵션이 있지만 네트워크 모드를 사용하는 것이 좋습니다. awsvpc awsvpc네트워크 모드는 애플리케이션이 서로 통신하고 VPC 내의 다른 서비스와 통신하는 방식을 더 잘 제어할 수 있으므로 컨테이너 네트워킹을 단순화합니다.

  Fargate에서 실행되는 작업의 경우 awsvpc 네트워크 모드만 사용할 수 있습니다.

• 작업에 사용할 로깅 구성.

• 작업의 컨테이너와 함께 사용되는 모든 데이터 볼륨.

작업 정의 파라미터의 전체 목록은 태스크 정의 파라미터를 참조하세요.

작업 정의를 생성할 때는 다음 지침을 따르세요.

• 각 작업 정의 패밀리는 하나의 비즈니스 용도로만 사용합니다.

  여러 유형의 애플리케이션 컨테이너를 동일한 작업 정의로 그룹화하면 해당 컨테이너를 독립적으로 확장할 수 없습니다. 예를 들어 웹 사이트와 API 모두에서 동일한 속도로 스케일 아웃해야 할 가능성은 거의 없습니다. 트래픽이 증가하면 필요한 웹 컨테이너의 수가 API 컨테이너 수와 달라지게 됩니다. 이 두 컨테이너를 동일한 작업 정의에 배포하는 경우 모든 작업에서 동일한 수의 웹 컨테이너와 API 컨테이너가 실행됩니다.

• 각 애플리케이션 버전을 작업 정의 패밀리 내의 작업 정의 개정과 일치시킵니다.

  작업 정의 패밀리 내에서 각 작업 정의 개정을 특정 컨테이너 이미지 설정의 특정 시점 스냅샷으로 간주합니다. 이는 컨테이너가 특정 버전의 애플리케이션 코드를 실행하는 데 필요한 모든 항목의 스냅샷인 것과 비슷합니다.

  애플리케이션 코드 버전, 컨테이너 이미지 태그, 작업 정의 수정 버전 간에 one-to-one 매핑이 있는지 확인하세요. 일반적인 릴리스 프로세스에는 git 커밋 SHA로 태그가 지정된 컨테이너 이미지로 변환되는 git 커밋이 포함됩니다. 그러면 해당 컨테이너 이미지 태그에 고유한 Amazon ECS 작업 정의 개정이 적용됩니다. 마지막으로 Amazon ECS 서비스가 업데이트되어 새 작업 정의 개정을 배포하도록 알립니다.

• 각 작업 정의 패밀리에 대해 서로 다른 IAM 역할을 사용합니다.

  고유한 IAM 역할로 각 작업 정의를 정의합니다. 이 권장 사항은 각 비즈니스 구성 요소에 고유한 작업 정의 패밀리를 제공하라는 권장 사항과 함께 이루어져야 합니다. 이 두 가지 모범 사례를 모두 구현하면 AWS 계정 내 리소스에 대한 각 서비스의 액세스 권한을 제한할 수 있습니다. 예를 들어 인증 서비스에 비밀번호 데이터베이스에 연결할 수 있는 액세스 권한을 부여할 수 있습니다. 이와 동시에 주문 서비스만 신용 카드 결제 정보에 액세스할 수 있도록 할 수도 있습니다.