Amazon ECS Service Connect를 활용하여 손쉽게 마이크로서비스 운영하기

마이크로서비스 아키텍처는 최근 소프트웨어 개발의 가장 인기있는 방식으로, 애플리케이션을 작고 독립된 서비스로 나누어 분산 구성하여 운영할 수 있습니다. 이를 통해 고객은 기존의 모놀리스 애플리케이션을 목적과 역할에 따라 세분화하여 새로운 독립적인 애플리케이션으로 분리할 수 있습니다. 이렇게 분산된 애플리케이션은 자체적인 역할을 수행하며, 필요한 경우 독립적인 단위로 빠르게 스케일 인/아웃하여 더욱 확장성을 높일 수 있습니다. 또한 애플리케이션 장애 발생 시 각 서비스를 격리하여 문제를 해결할 수 있는 장점도 있습니다.

하지만 서비스 규모가 커지면서 각 서비스의 엔드포인트를 찾고, 안정적인 통신을 유지하는 것이 어려워집니다. 이러한 문제를 해결하기 위해 Amazon ECS를 사용하는 고객들은 클러스터 내 서비스 간 통신을 위한 다양한 방법을 활용할 수 있습니다.

Amazon ECS 의 서비스간 통신 방법

첫 번째 방법은 Amazon ECS Service Discovery를 활용하는 것입니다. 이 기능은 DNS를 사용하여 작업에 요청을 보낼 수 있도록 자동으로 엔드포인트를 생성합니다. AWS Cloud Map과 Amazon Route 53을 통해 필요한 항목이 자동으로 등록되며, 클라이언트는 DNS 주소로 요청을 보내면 해당하는 백엔드 작업(Task)로 요청이 전달됩니다. 하지만 DNS 자체는 라운드 로빈 방식의 간단한 검색만 제공하고, 트래픽에 대한 원격 측정을 자동으로 제공하지 않습니다. 또한 DNS 캐시(TTL) 설정으로 인해 갑작스러운 서비스 장애 발생 시 문제가 발생할 수 있습니다.

두 번째 방법은 Amazon Elastic Load Balancer(ELB)를 사용하는 방법입니다. 이 방법은 고객들이 가장 많이 활용하는 방법으로 하나의 서비스를 ELB의 대상 그룹으로 지정해서 트래픽을 전달합니다. 클라이언트는 ELB의 엔드포인트로 요청을 보내면 리스너 규칙에 의해서 쉽게 대상 그룹으로 쉽게 접근이 가능하고, 개발자나 운영자는 ELB에서 제공하는 트래픽 지표의 확인이 가능합니다. 하지만 ELB의 풍부한 기능들 활용할 수 있는 반면, 새로운 리소스 비용 및 복잡도가 증가하는 단점이 있습니다.

세 번째 방법은 AWS App Mesh를 활용하는 방법입니다. 이는 Service Mesh 개념을 기반으로 Envoy 프록시를 사이드카 형태로 생성하여 하나의 네트워크 층을 이루면서 작업(Task) 간 트래픽을 프록시하고 상호 연결을 담당합니다. Envoy 프록시는 트래픽을 세밀하게 제어할 수 있고 암호화나 인증 기능을 제공합니다. 하지만 사용법이 복잡하고 처음부터 사용하기 어렵기 때문에 충분한 학습 시간과 테스트를 필요로 합니다.

Amazon ECS Service Connect 소개

위에서 소개한 세가지 방법 외에도 여러분은 2022년 12월 새롭게 출시한 Amazon ECS의 Service Connect 기능을 활용할 수 있습니다. Service Connect는 클러스터 내부의 분산된 서비스 간의 연결을 손쉽게 구축하고 운영할 수 있는 새로운 기능입니다.

고객은 애플리케이션 코드를 직접 변경하지 않으면서 서비스 간 통신을 위한 회복 탄력성(resilience)있는 네트워크 계층을 추가하여 트래픽의 헬스 체크와 요청 실패 시 자동 재시도와 같은 기능을 쉽게 적용할 수 있을뿐 아니라, 트래픽의 텔레메트리 데이터에 대한 인사이트도 Amazon CloudWatch와 ECS 콘솔을 통해 얻을 수 있습니다. 관련된 내용은 “Amazon ECS Service Connect – 컨테이너 기반 마이크로서비스내 간편한 통신 기능 출시” 내용을 참고하시길 바랍니다.

본 게시물에서는 간단한 마이크로서비스 아키텍처 예제를 Amazon ECS에 배포해보고, Service Connect를 활성화하면 클러스터 인스턴스의 컨테이너 구성이 어떻게 변화하는지 조금 더 깊게 살펴보겠습니다. 그리고 Service Connect를 사용하는 경우 고객이 신경써야 하는 주의사항에 대해서도 함께 살펴보겠습니다.

Amazon ECS Service Connect 사용 방법

예제 소개 및 서비스 배포하기

먼저 Amazon ECS의 Service Connect 기능을 살펴보기 전에 간단한 마이크로서비스 아키텍처 기반의 애플리케이션을 구성해보겠습니다. 해당 아키텍처는 Amazon ECS 서비스의 인기있는 워크샵인 Cats and Dogs을 기반으로 수정하여 구성했습니다.

아래 그림 1은 해당 코드를 사용해 배포한 아키텍처를 나타냅니다. ECS 클러스터 안에는 web 프론트엔드 서비스와 cats-api, dogs-api 백엔드 서비스가 있습니다. 프론트엔드 서비스는 브라우저를 위한 웹 페이지를 제공하고, 고객은 웹 페이지의 버튼을 클릭하면 각각 cats-api, dog-api 서비스에 고양이와 강아지 사진을 fetch() 자바스크립트 함수를 이용해 프론트엔드 서비스의 특정 경로의 API를 호출합니다.

그림 1. 예제 Amazon ECS 아키텍처

프론트엔드 서비스의 특정 경로가 호출되면 실제로는 프론트엔드 서비스 내부의 nginx에 구성된 location proxy_pass 리버스 프록시 설정을 통해 ECS 클러스터 내부의 백엔드 서비스로 요청을 전달합니다. 이때 proxy_pass에 설정하는 URL 값은 클러스터 내부 통신을 위한 백엔드 서비스의 엔드포인트 주소를 넣어야 합니다. 일단 Service Connect 기능을 적용하기 이전에는 업스트림 오류를 방지하기 위해서 로컬호스트 주소(localhost:3000)로 임시로 설정했습니다.

server {
    listen       80;
    server_name  localhost;

    ... 생략 ...

    location /cats-api/image {
        proxy_pass http://localhost:3000/api/images; # Service Connect DNS 주소로 변경
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
    }

    location /dogs-api/image {
        proxy_pass http://localhost:3000/api/images; # Service Connect DNS 주소로 변경
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
    }

    ... 생략 ...
}

예제 1. 프론트엔드 서비스의 nginx default.conf 설정

마찬가지로 web, cats-api, dogs-api 서비스도 README.md 파일을 참고하여 Amazon ECS에 배포합니다. 그림 2는 모든 서비스가 정상적으로 배포된 프론트엔드 화면 모습을 보여 줍니다.

그림 2. 예제 아키텍처를 배포한 후 서비스에 접속한 모습

Service Connect 설정하기

서비스에 Service Connect 기능을 활성화하기 전에 클라이언트(Client side only) 모드와 클라이언트-서버(Client and server) 모드에 대해서 잠시 살펴보겠습니다. 먼저 클라이언트 옵션은 서비스 자신은 특정 네임스페이스에 해당하는 다른 서비스에 연결 요청만 하는 경우 사용합니다.

예를 들어, 프론트엔드, 리버스 프록시 또는 애플리케이션이 Elastic Load Balancing(ELB)등의 다른 방법을 통해 외부 트래픽을 수신하는 경우 등이 있습니다. 예제 아키텍처의 경우 web 서비스는 ELB를 통해서 외부에서 요청을 받고, 백엔드 서비스에 요청을 전달하는 역할을 수행하기 때문에 클라이언트 모드 옵션을 선택합니다. 반대로 cats-api와 dogs-api 서비스의 경우 web 서비스와 동일한 네임스페이스 안에서 요청을 주고 받을 수 있기 때문에 이 경우는 클라이언트-서버 모드를 선택하면 됩니다.

	클라이언트 서비스 모드 (Client service)	클라이언트-서버 서비스 모드 (Client-Server service)
서비스 타입	– 프론트엔드 – 리버스 프록시 or 로드밸런서 애플리케이션	– 백엔드 – 미들웨어 or 네트워크 요청을 받는 마이크로서비스
작업 정의 (Task Definition)	– 없음	– 컨테이너 포트 매핑을 위한 포트 이름 – (optional) 애플리케이션 프로토콜(예: HTTP)을 제공하여 서버 애플리케이션에 대한 프로토콜별 지표 수신 가능(예: `HTTP 5xx`).
서비스 정의 (Service Definition)	– 네임스페이스 설정	– DNS 이름, 포트 번호, 네임스페이스 설정

여기서 주의할 점은 서비스를 새롭게 배포하거나 기존 서비스에 Service Connect를 처음 적용하는 경우, 반드시 배포 순서에 유의해야 한다는 것입니다. 만약 기존 서비스에 적용하는 경우 클라이언트-서버 모드 옵션을 적용하는 서비스부터 Service Connect를 적용해야 합니다. Service Connect를 적용하면 서비스가 새롭게 배포되면서 Service Connect 엔드포인트(DNS 주소 혹은 clientAlias 값)가 네임스페이스에 등록이 됩니다. 이어서 클라이언트 모드의 서비스를 배포하면 네임스페이스에 등록된 클라이언트-서버 모드 서비스의 엔드포인트를 찾아 연결을 할 수 있습니다. 즉, 처음에 순서를 잘 고려해서 배포한다면 이후 배포는 원하는 시기에 각 서비스를 별도로 배포할 수 있습니다. (단, 새롭게 엔드포인트가 추가되거나 수정되는 경우에는 배포 순서를 다시 고려해야 합니다.)

자세한 설명은 아래 Amazon ECS 사용 시 고려사항에 대한 내용과 문서를 함께 참고하길 바랍니다.

그렇다면 백엔드 서비스에 해당하는 dogs-api 서비스의 Service Connect 기능을 활성화 해보겠습니다. Amazon ECS 콘솔 메뉴에서 서비스의 Configuration 메뉴로 들어갑니다. 아래 그림 3에서 표시된 [Configure] 버튼을 누르면 Service Connect을 설정할 수 있는 팝업 메뉴가 나옵니다. 여기서 클라이언트-서버 모드를 선택하고 네임스페이스를 현재 클러스터로 선택합니다. 이어서 서비스 내부의 컨테이너의 포트로 매핑하기 위한 alias 설정과 DNS 설정을 진행합니다. 추가로 Service Connect의 로그를 수집하고자 한다면 Advanced 메뉴에서 [Use log collection] 체크박스를 활성화합니다.

그림 3. ECS 서비스 Configuration 메뉴 화면의 Service Connect 설정 버튼

Service Connect 설정 화면에서는 그림 4처럼 포트 별칭, 검색 이름, 엔드포인트, 포트를 설정할 수 있습니다.

포트 별칭(Port alias) : 작업 정의 portMappings 이름 값이 자동으로 설정됩니다.
검색 이름(Discovery) : 작업 정의에서 지정된 포트에 대해 생성할 수 있는 선택적 중간 이름입니다. 이 이름은 AWS Cloud Map 서비스를 생성하는 데 사용됩니다. AWS Cloud Map 서비스 이름은 네임스페이스 내에서 고유해야 합니다.
엔드포인트(DNS) : 원하는 DNS를 설정합니다. 지정하지 않으면 기본적으로 작업 정의 portMappings 이름이 사용됩니다.
포트(Port) : 특정 애플리케이션 컨테이너의 포트를 설정합니다.

그림 4. Service Connect 팝업 메뉴 설정하기 (클라이언트-서버 모드)

여기서 설정한 DNS 주소와 포트는 Service Connect 네임스페이스 안에서 해당 애플리케이션의 엔드포인트(dogs-api.service-connect.me:3000)가 되고, 위에서 임시로 설정했던 web 서비스 default.conf 파일의 proxy_pass 설정 값을 이 엔드포인트 주소로 수정해야 합니다. 이어서 dogs-api 서비스와 마찬가지로 cats-api 서비스도 Service Connect 기능을 클라이언트-서버 모드로 활성화합니다. 마지막으로 web 서비스는 아래 그림 5와 같이 클라이언트 모드로 활성화 합니다. 클라이언트 모드는 내부 통신에 대한 요청만 수행하기 때문에 네임스페이스만 설정할뿐 요청을 받기 위해서 자신의 엔드포인트 정보를 등록할 필요는 없습니다.

그림 5. Service Connect 팝업 메뉴 설정하기 (클라이언트 모드)

위의 구성이 끝나면 각 서비스는 자동으로 새로운 네트워크 구성을 위해 롤링 업데이트를 진행합니다.

Service Connect 기능 살펴보기

이어서 서비스에 Service Connect 기능을 설정하면 어떤 기능이 추가되거나 변화하는지 콘솔 환경을 통해서 살펴보겠습니다.

Traffic health

먼저 Amazon ECS 클러스터의 서비스 메뉴에서 간단한 그림 7과 같은 트래픽 지표를 확인할 수 있는 대시보드가 생성됩니다. 클라이언트 모드 서비스의 경우는 Outgoing(Egress) traffic health를 볼 수 있고, 클라이언트-서버 모드 서비스의 경우에는 Inbound(Ingress) traffic health을 추가로 확인 가능합니다. 해당 지표는 여러분의 CloudWatch 대시보드에 바로 추가할 수 있습니다.

그림 6. Service Connect 설정 후 서비스 메뉴에 추가된 Traffic health 대시보드

여러분은 Traffic health를 통해 제공되는 다양한 지표 정보를 활용하여 트래픽에 대한 가시성을 높일 수 있습니다. 해당 지표들은 CloudWatch Metrics의 AWS/ECS 네임스페이스에서 확인이 가능합니다. 이를 통해 사용자는 필요에 따라 사용자 정의 지표와 수학식을 만들어 활용할 수 있습니다. 특히, 애플리케이션 오토 스케일링 기능을 사용하여 Amazon ECS 서비스를 더욱 효율적으로 관리할 수 있습니다. 이 기능은 애플리케이션의 요청량 등에 따라 자동으로 리소스를 확장하거나 축소할 수 있도록 도와줍니다. 자세한 내용은 “애플리케이션 오토 스케일링의 사용자 정의 지표 기반으로 Amazon ECS 오토 스케일링 하기“를 참고하세요.

예를 들어, 애플리케이션의 탄력성을 향상시킬 수 있도록 ELB의 API 요청 개수로 애플리케이션 오토 스케일링을 했었다고 가정한다면, 이제는 Service Connect 트래픽 지표 중 하나인 RequestCount 지표를 활용할 수 있습니다. 실제 적용해보겠습니다. 아래 예제 2와 같이 AWS CLI를 통해서 애플리케이션 오토 스케일링의 대상을 정의합니다. 현재 cats-api 서비스의 작업(Task) 개수는 1개지만 오토 스케일링 이벤트가 발생하면 2개까지 확장할 것입니다.

CLUSTER_NAME=MyCluster
SERVICE_NAME=cats-api

aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
--min-capacity 1 \
--max-capacity 2

예제 2. 애플리케이션 오토 스케일링 확장 대상 등록(AWS CLI)

이어서 대상 추적 확장 정책을 예제 3처럼 JSON 형식으로 정의합니다. 정책 내용을 살펴보면 RequestCount 지표의 평균값을 활용하고 해당 값이 20을 초과하면 오토 스케일링 동작하도록 구성되어 있습니다. 그리고 예제 4를 참고하여 위에서 설정한 애플리케이션 오토 스케일링 확장 대상에 해당 정책을 연결합니다.

{
   "TargetValue":20.0,
   "ScaleOutCooldown":60,
   "ScaleInCooldown":60,
   "CustomizedMetricSpecification":{
      "Metrics":[
         {
            "Id":"m1",
            "Label":"request_count_average_1m",
            "ReturnData":true,
            "MetricStat":{
               "Metric":{
                  "Namespace":"AWS/ECS",
                  "MetricName":"RequestCount",
                  "Dimensions":[
                     {
                        "Name":"DiscoveryName",
                        "Value":"cats-api"
                     }
                  ]
               },
               "Stat":"Average"
            }
         }
      ]
   }
}

예제 3. 대상 추적 확장 정책 설정 파일

CLUSTER_NAME=MyCluster
SERVICE_NAME=cats-api
POLICY_NAME=request-count-average-cats-api

aws application-autoscaling put-scaling-policy \
--policy-name $POLICY_NAME \
--service-namespace ecs \
--resource-id service/$CLUSTER_NAME/$SERVICE_NAME \
--scalable-dimension ecs:service:DesiredCount \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration file://policy.json

예제 4. 애플리케이션 오토 스케일링 정책 추가(AWS CLI)

애플리케이션 오토 스케일링 설정이 끝난 후 CloudWatch에서 cats-api 서비스의 트래픽 지표, 애플리케이션 오토 스케일링 알람을 쉽게 추가할 수 있습니다. 만약 대상 추적 확장 정책에 따라서 오토 스케일링이 동작하면 Amazon ECS는 서비스에 해당하는 작업(Task)을 DesiredCount 값에 맞게 추가로 배포합니다.

그림 7. Service Connect 트래픽 지표와 Alram 정보를 혼합한 CloudWatch 대시보드

그림 8. 애플리케이션 오토 스케일링 이벤트가 발생해서 작업(Task)가 확장되는 모습

Namespaces

네임스페이스 메뉴를 함께 살펴보겠습니다. 네임스페이스는 동일한 구성을 공유하는 서비스들의 논리적 그룹입니다. 클러스터가 생성되면 자동으로 AWS Cloud Map 네임스페이스가 생성됩니다. AWS Cloud Map의 네임스페이스는 Amazon ECS 메뉴(Namespaces)에서 확인이 가능합니다.

Service Connect는 동일한 네임스페이스 내 등록된 서비스 간의 연결만 수행하기 때문에 반드시 내부 통신을 수행하는 서비스는 하나의 네임스페이스에 등록해야 합니다. 네임스페이스 화면 안에는 위에서 Service Connect 기능을 서비스 목록이 나타나고, 클라이언트-서버 모드의 경우는 해당 서비스를 검색할 수 있는 Discovery name도 확인이 가능합니다.

그림 9. Amazon ECS의 Namespaces 메뉴 화면

해당 메뉴에서 MyCluster를 클릭하여 AWS Cloud Map으로 이동하면 MyCluster 네임스페이스가 생성되어 있는 것을 확인할 수 있습니다. 한 가지 차이점은 AWS Cloud Map에는 실제 서비스 레지스트리 역할을 수행하기 때문에 클라이언트-서버 모드의 서비스(cats-api, dogs-api)만 등록이 되어있다는 사실입니다.

그림 10. Amazon ECS의 Namespaces 메뉴 화면

Dive Deep into Amazon ECS Service Connect

지금까지 간단한 마이크로서비스 예제를 배포하고 Service Connect 기능을 활성화하여 추가로 생성된 트래픽 지표를 활용해 애플리케이션 오토 스케일링을 적용해봤습니다. 그렇다면 실제 Service Connect 기능의 동작 흐름과 추가로 생성되는 컨테이너에 대해서 살펴보겠습니다.

Service Connect 동작 흐름

Service Connect를 설정하면 서비스 업데이트 시 아래와 같은 흐름으로 배포가 이루어집니다.

콘솔에서 Service Connect 설정을 업데이트하면, Amazon ECS Agent를 통해 Service Connect Agent 컨테이너 설정이 주입됩니다.
Amazon ECS Agent는 Service Connect Agent를 생성하고, 애플리케이션 컨테이너를 배포하기 위한 명령을 내립니다.
ECS 노드 인스턴스에는 먼저 Service Connect Agent가 생성되며, 추가로 필요한 컨테이너(e.g., pause 컨테이너) 등이 배포됩니다. 그리고 Service Connect 관련 환경 설정이 완료되면 애플리케이션 컨테이너가 생성됩니다.
이때 Amazon ECS는 AWS Cloud Map의 네임스페이스에서 미리 등록된 서비스들의 디스커버리 정보를 가져옵니다.
가져온 최신 서비스 디스커버리 정보는 내부 통신을 위해 Service Connect Agent에 설정됩니다.
cats-api가 정상적으로 배포되면, cats-api의 Service Connect 관련 정보도 AWS Cloud Map에 업데이트됩니다.

그림 11. Amazon ECS Service Connect 동작 흐름

결론적으로 Service Connect를 사용하는 사용자는 서비스 작업(Task)의 DNS를 AWS Cloud Map을 통해 관리하고, 이를 Envoy 프록시를 포함한 Service Connect Agent가 업데이트하면서 내부 통신을 위한 서비스 디스커버리 구성이 자동으로 이루어진다고 이해할 수 있습니다. 다만, 사용자들이 이 기능을 사용하기 위해 동작 원리나 흐름에 대해 정확히 이해할 필요는 없습니다.

Service Connect 를 위한 추가 컨테이너

Amazon ECS는 Service Connect 기능을 위해서 필요한 컨테이너를 자동으로 배포합니다. 그 이유는 Service Connect의 서비스가 Envoy 프록시 기반의 Service Connect 에이전트를 통해 네임스페이스의 다른 서비스와 통신하기 때문입니다. 이렇게 자동으로 추가되는 컨테이너들은 ECS 컨트롤 플레인이 작업(Task)이 생성될 때 자동으로 해당 컨테이너 정의를 주입하고 배포하게 됩니다.

작업의 네트워크 모드에 따라 생성되는 컨테이너가 달라지기 때문에 추가 컨테이너의 동작 방식도 다를 수 있습니다. 예를 들어, bridge 네트워크 모드에서는 작업(Task)마다 사이드카 형태의 ecs-service-connect-agent와 내부 통신을 위해 도커 네트워크 네임스페이스 설정을 사전에 셋팅하기 위한 pause 컨테이너가 생성됩니다. 이번 게시글에서는 pause 컨테이너가 필요한 이유와 역할, 생성 흐름에 대한 자세한 설명은 생략합니다. 여러분이 알아야 하는 것은 추가적인 컨테이너 리소스가 반드시 필요하다는 것입니다.

그림 12. Amazon ECS 컨테이너 인스턴스의 도커 컨테이너 리스트

Amazon ECS Service Connect 사용 시 고려사항

이어서 Service Connect 기능을 사용할 때 꼭 알아야 하는 두 가지 고려사항을 살펴보겠습니다.

첫 번째로 Amazon ECS 서비스가 Service Connect 구성으로 생성되거나 업데이트되면, 위에서 살펴본 것 처럼 새로운 작업이 시작될 때마다 추가적인 컨테이너가 자동으로 생성됩니다. 이러한 컨테이너는 사용자가 직접 구성할 수 없지만 작업 정의에서 정의한 리소스 제한에 영향을 받습니다. 따라서 작업 메모리 제한을 직접 설정해야 합니다. 이 경우 추가 컨테이너를 위한 CPU 및 메모리 리소스를 고려해야 하며, 최소한 0.25 vCPU 및 64MiB 메모리 추가를 권장합니다. 이 때 AWS Fargate를 사용하는 경우 설정할 수 있는 최소 메모리 양은 512MiB 인 점을 고려해야 합니다. 또 많은 수의 서비스나 작업을 사용하는 경우 충분한 CPU 리소스를 할당해야 합니다. 대규모 트래픽이 예상되는 경우 작업 정의에서 0.5 vCPU 이상으로 리소스를 할당해야 합니다.

두 번째 Amazon ECS Service Connect를 사용하는 경우, 클라이언트-서버 모드 서비스의 애플리케이션을 먼저 배포해야 합니다. Service Connect가 활성화된 상태에서 실행된 작업은 이미 네임스페이스에 존재하는 엔드포인트를 확인할 수 있지만, 작업 시작 후 네임스페이스에 추가된 새 엔드포인트는 작업 구성에 추가되지 않습니다. 따라서 클라이언트 모드 서비스의 작업이 먼저 배포된 경우, 백엔드 서비스의 작업 엔드포인트는 탐색되지 않습니다. 따라서 클라이언트-서버 모드의 백엔드 서비스를 먼저 배포하고, 기존 프론트엔드 서비스와의 동작을 충분히 검증한 후 클라이언트 모드의 프론트엔드 서비스를 배포해야 합니다. 한 번의 배포가 끝난 이후에는 여러분이 원하는 주기로 각 서비스를 배포할 수 있습니다.

이 밖의 고려사항은 문서를 통해 자세한 내용을 확인할 수 있습니다.

결론

이제까지 Amazon ECS Service Connect 기능을 간단한 마이크로서비스 아키텍처 예제와 함께 살펴봤습니다. Amazon ECS은 내부 통신을 위한 다양한 방법이 있지만, Service Connect를 사용하면 다른 AWS 서비스의 추가 리소스 없이 애플리케이션 코드 수정 없이 클러스터 네임스페이스 범위 내에서 내부 통신을 쉽게 구축할 수 있습니다. Service Connect는 awsvpc 및 bridge 네트워크 모드를 모두 지원하며, 각각의 경우 Amazon ECS가 자동으로 필요한 컨테이너를 추가로 생성합니다. 이는 여러분이 내부 동작 방식을 자세히 알 필요 없이 간단한 설정만으로 쉽게 사용할 수 있다는 장점이 있습니다. 그러나 Service Connect를 적용할 때는 몇 가지 주의사항이 있습니다. 이에는 Service Connect 기능을 위한 추가 컨테이너를 위한 충분한 리소스 할당, 네임스페이스 엔드포인트 적용을 위한 배포 순서의 유의 등이 포함됩니다. 이러한 주의사항을 충분히 고려한다면 여러분은 Amazon ECS 클러스터 내에서 마이크로서비스 간의 내부 통신을 손쉽게 구축할 수 있습니다.

AWS 기술 블로그