애플리케이션 아키텍처 - Amazon Elastic Container Service

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

애플리케이션 아키텍처

Amazon ECS에서 애플리케이션의 아키텍처를 어떻게 설계하는지는 키 구분자로 사용하는 시작 유형을 비롯한 몇 가지 요인에 따라 달라집니다. 시작 유형에 따라 세분화되어 있는 다음 지침은 이 프로세스를 수행하는 데 도움이 될 것입니다.

사용Fargate시작 유형

실행할 응용 프로그램을 설계 할 때Amazon ECS를 사용하는AWS Fargate주요한 문제는 여러 작업 정의에 컨테이너를 구분하여 배포하는 것에 비해 여러 컨테이너를 동일 작업 정의에 배치하는 시점을 언제로 할 것인가 하는 것입니다.

다음 조건이 필요한 경우 단일 작업 정의에 컨테이너를 배포하는 것이 좋습니다.

  • 컨테이너가 공통 수명 주기를 공유하는 경우 (즉 함께 시작하고 종료됨).

  • 컨테이너는 동일한 기본 호스트에서 실행되어야 합니다. 즉 로컬호스트 포트에서 한 컨테이너가 다른 컨테이너를 참조함.

  • 컨테이너가 리소스를 공유해야합니다.

  • 컨테이너가 데이터 볼륨을 공유하는 경우

이런 경우가 아니라면 컨테이너의 규모 조정, 프로비저닝 및 디프로비저닝을 별도로 할 수 있도록 별도의 작업 정의에서 컨테이너를 정의해야 합니다.

사용EC2시작 유형

EC2 시작 유형을 사용하여 작업 정의 및 서비스를 모델링하는 방법을 고려할 때 어떤 프로세스를 함께 실행해야 하는지, 그리고 각 구성 요소의 규모를 어떻게 조정할지를 감안하는 것이 도움이 됩니다.

예를 들어 다음 구성 요소로 이루어진 애플리케이션을 생각해 봅시다.

  • 웹 페이지에 정보를 표시하는 프런트엔드 서비스

  • 프런트엔드 서비스에 API를 제공하는 백엔드 서비스

  • 데이터 스토어

개발 환경에서는 아마도 도커 호스트에서 이러한 세 컨테이너를 모두 실행할 것입니다. 운영 환경에서도 동일한 접근법을 사용하고 싶을 수 있지만, 이 접근법은 여러 단점이 있습니다.

  • 한 구성 요소를 변경하면 세 구성 요소 모두에 영향을 미칠 수 있어 변경 범위가 예상했던 것보다 커질 수 있습니다.

  • 모든 컨테이너를 비례적으로 조정해야 하므로 각 구성 요소를 조정하기 더 어렵습니다.

  • 작업 정의는 10개의 컨테이너 정의만 포함할 수 있는데, 애플리케이션 스택은 지금 또는 향후 더 많은 정의를 필요로 할 수 있습니다.

  • 작업 정의의 모든 컨테이너가 동일한 컨테이너 인스턴스에 있어야 하는데, 이로 인해 인스턴스 선택이 가장 큰 크기로 제한될 수 있습니다.

이러한 단점을 감안할 때 공통 용도로 사용되는 컨테이너를 그룹화하는 작업 정의를 만들고 다른 구성 요소를 여러 작업 정의로 분리해야 합니다. 앞의 예에서는 세 작업 정의가 각각 하나의 컨테이너를 지정합니다. 다음 예제 클러스터에는 3개의 프런트 엔드 서비스 컨테이너, 2개의 백엔드 서비스 컨테이너 및 1개의 데이터 스토어 서비스 컨테이너에 등록된 3개의 컨테이너 인스턴스가 등록되어 있습니다.


					애플리케이션 아카텍처 사례

동일한 작업 정의의 관련된 컨테이너를 그룹화할 수 있습니다(예: 반드시 함께 실행해야 하는 연결된 컨테이너). 예를 들어 로그 스트리밍 컨테이너를 프런트 엔드 서비스에 추가하고 동일한 작업 정의에 포함할 수 있습니다.

작업 정의로부터 서비스를 생성하여 원하는 작업의 가용성을 유지할 수 있습니다. 자세한 정보는 생성Amazon ECS서비스을 참조하십시오. 서비스에서 컨테이너를 Elastic Load Balancing 로드 밸런서와 연결할 수 있습니다. 자세한 정보는 서비스 로드 밸런싱을 참조하십시오. 애플리케이션 요구 사항이 변경될 경우 서비스를 업데이트하여 원하는 작업의 개수를 조정하거나 작업에 새 버전의 컨테이너를 배포할 수 있습니다. 자세한 정보는 서비스 업데이트하기을 참조하십시오.