Amazon Web Services 한국 블로그

Amazon ECS 서비스 검색 기능 추가

Amazon ECS에 서비스 검색 기능이 추가되었습니다. 이제 ECS 서비스가 예측 가능하고 알기 쉬운 DNS 이름으로 Amazon Route 53에 자동으로 등록됩니다. 외부 트래픽에 의한 로드 및 컨테이너 상태에 따라 서비스가 확장되거나 축소되더라도 Route 53 호스팅 영역이 최신 상태로 유지되므로 다른 서비스가 각 서비스의 상태를 기준으로 어디에 연결해야 할지를 조회할 수 있습니다. https://servicediscovery.ranman.com/에서 가상의 소셜 네트워킹 앱을 통해 서비스 검색 기능의 데모를 살펴볼 수 있습니다.

서비스 검색


마이크로서비스 및 최신 아키텍처로 전환하려면, 급격하게 변하는 트래픽과 장애 상황에도 신속하게 대응할 수 있는 동적인 자동 확장 및 강력한 성능을 갖춘 튼튼한 서비스가 필요합니다. 기존에 제공되는 서비스는 서로 복잡한 상관관계와 의존관계로 구성된 경우가 많습니다. 최신 클라우드 아키텍처에서는 이 같은 서비스를 서로 느슨하게 연결하여 자체적인 상관관계를 설정할 수 있도록 하는 것이 널리 활용되는 모범 사례입니다. 하지만, 동적 환경에서는 개별 서비스가 연결 지점을 찾아야 하기 때문에 이렇게 구현하기가 쉽지 않습니다.

Consul, Etcd 또는 ZooKeeper와 같은 기존의 서비스 검색 방식도 모두 이 문제를 잘 해결해 주지만, 인프라를 추가로 프로비저닝하고 관리하거나 컨테이너 또는 인스턴스에 에이전트를 설치해야 합니다. 이전에는 서비스가 서로를 검색하고 연결할 수 있게 하려면 자체 서비스 검색 시스템을 구성하고 실행하거나 모든 서비스를 로드 밸런서에 연결해야 했습니다. 이제는 ECS 콘솔이나 AWS CLI에서, 또는 ECS API를 사용하여 컨테이너식 서비스에 대한 서비스 검색을 활성화할 수 있습니다.

Amazon Route 53 서비스 등록 및 자동 명명 API 소개

Amazon ECS 서비스 검색 기능은 Amazon Route 53 서비스 등록 및 자동 명명 API와 통신하면서 작동합니다. 이 블로그에서 이전에 다룬 적이 없는 만큼, 이 시간에는 이 Route 53 API가 어떻게 작동하는지 간단히 설명하도록 하겠습니다. 먼저, 관련 용어를 몇 가지 설명하겠습니다.

  • 네임스페이스 – 네임스페이스는 트래픽을 라우팅할 대상 도메인 이름(예: internal, local, corp)을 지정합니다. 네임스페이스는 서로 검색 가능하게 구현되어야 하는 서비스 간의 논리적 경계라고 할 수 있습니다. 네임스페이스는 aws servicediscovery create-private-dns-namespace 명령을 호출하여 생성하거나 ECS 콘솔에서 생성할 수 있습니다. 네임스페이스는 큰 의미에서 Route 53의 호스팅 영역과 같다고 할 수 있습니다. 네임스페이스에는 다음으로 살펴볼 용어인 서비스가 포함되어 있습니다.
  • 서비스 – 서비스는 네임스페이스 안에 포함된 “auth”, “timeline” 또는 “worker”와 같은 특정 애플리케이션 또는 애플리케이션의 세트입니다. 서비스에는 서비스 인스턴스가 포함되어 있습니다.
  • 서비스 인스턴스 – 서비스 인스턴스에는 Route 53이 리소스 관련 DNS 쿼리에 어떻게 응답해야 하는지에 대한 정보가 들어 있습니다.

Route 53은 네임스페이스, 작업 IP별 A 레코드 및 작업 IP + 포트별 SRV 레코드를 생성할 수 있는 API를 제공합니다.

Route 53에서 worker.corp 같은 쿼리를 실행하면 해당 요청을 처리할 수 있는 IP의 세트가 반환됩니다. 연결하는 애플리케이션이 동적 포트를 노출하는 경우 호출하는 애플리케이션이 손쉽게 SRV 레코드를 쿼리하여 추가 정보를 얻을 수 있습니다.

ECS 서비스 검색 기능은 Route 53 API를 기반으로 하며 모든 기본 API 호출을 관리합니다. 지금까지 서비스 등록이 어떻게 이루어지는지 알아보았고, 이제 ECS에서 서비스 검색 기능이 어떻게 작동하는지를 살펴보겠습니다.

Amazon ECS 서비스 검색

서비스 검색 기능을 활용하여 애플리케이션을 시작해 보겠습니다. 먼저 “flask-backend”와 “flask-worker”라는 두 가지 작업 정의를 생성합니다. 두 가지 모두 HTTP 요청을 처리하는 단일 컨테이너를 사용한 간단한 AWS Fargate 작업입니다. flask-backend에서 worker.corp 쿼리를 실행하여 응답과 worker에 대한 주소 Route 53이 반환되도록 해보겠습니다. 코드는 다음과 같습니다.

@app.route("/")
namespace = os.getenv("namespace")
worker_host = "worker" + namespace
def backend():
    r = requests.get("http://"+worker_host)
    worker = socket.gethostbyname(worker_host)
    return "Worker Message: {]\nFrom: {}".format(r.content, worker)

컨테이너와 작업 정의가 준비되었으니, 이제 콘솔에서 서비스를 생성해 보겠습니다.

서비스 마법사의 2단계로 진행하여 서비스 검색 섹션을 작성하면 ECS가 새 네임스페이스를 생성합니다.

또한 ECS가 서비스에 포함된 작업의 상태를 모니터링하여 필요에 따라 Route 53에 추가하거나 제거하도록 지정합니다. 그런 다음 사용할 A 레코드에 대해 TTL을 10초로 설정합니다.

“worker” 서비스에 대해서도 동일한 과정을 반복합니다. 1분 정도면 작업을 모두 실행할 수 있습니다.

Route 53 콘솔에서 작업의 레코드를 모두 확인할 수 있습니다.

Route 53 서비스 검색 API를 사용하여 사용 가능한 모든 서비스 및 작업의 목록을 표시하고 프로그래밍 방식으로 각 항목에 연결할 수 있습니다. backend와 worker 이외의 서비스까지 개수 제한 없이 얼마든지 손쉽게 확장할 수 있습니다. https://servicediscovery.ranman.com/에 “auth”, “feed”, “timeline”, “worker”, “user” 등의 서비스를 사용한 간단한 가상의 소셜 네트워크 데모를 만들었습니다. 해당 페이지를 실행하는 데 사용된 코드는 github에서 확인할 수 있습니다.

정식 출시
Amazon ECS 서비스 검색 기능은 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤) 및 EU(아일랜드)에서 사용할 수 있습니다. AWS Fargate는 현재 미국 동부(버지니아 북부)에서만 사용할 수 있습니다. ECS 서비스 검색을 사용할 때에는 고객이 생성한 네임스페이스 및 서비스에서 생성하는 조회 쿼리 등 소비된 Route 53 리소스에 대한 요금을 지불합니다. 컨테이너 레벨 상태 확인 기능은 무료로 제공됩니다. 요금에 대한 자세한 내용은 설명서를 참조하십시오.

서비스 검색 기능을 사용하여 만들거나 리팩토링하는 작업물에 대해서는 코멘트나 Twitter를 통해 공유해 주십시오.

– Randall

P.S. 모든 블로그 게시물을 작성하는 데에는 수많은 AWS 동료들이 큰 도움을 주고 있습니다. 서비스 검색 기능을 만드는 데 도움을 준 모든 팀원들에게 감사를 전합니다.