BLOG
이제 Amazon ECS에 통합 서비스 검색 기능이 포함되었습니다. 이를 통해 ECS 서비스는 Amazon 라우트 53에 예측 가능하고 친숙한 DNS 이름으로 자동 등록됩니다. 로드 또는 컨테이너 상태에 대한 응답으로 서비스가 증가하거나 감소하면 Route 53호스팅 영역이 최신으로 유지되어 다른 서비스가 각 서비스의 상태에 따라 연결할 위치를 검색할 수 있습니다. 가상 소셜 네트워킹 앱에 대한 서비스 검색 데모는 https://servicediscovery.ranman.com/에서 확인할 수 있습니다.
서비스 검색
마이크로서비스 및 최신 아키텍처로 전환하기 위해서는 장애 및 변화하는 로드에 신속하게 대응할 수 있는 동적, 오토 스케일링 및 강력한 서비스가 필요합니다. 여러분의 서비스에는 해당 서비스와 해당 서비스가 제공하는 서비스에 대한 복잡한 종속성 그래프가 있을 것입니다. 현대적인 아키텍처 모범 사례는 이러한 서비스를 느슨하게 결합하여 자체 종속성을 지정하는 것이지만, 개별 서비스가 자체의 연결 지점을 찾도록 하는 동적 환경에서는 이 방법이 복잡할 수 있습니다.
서비스 검색에 대한 전통적인 접근 방식인 consul, etcd, zookeeper는 모두 이 문제를 잘 해결하지만, 컨테이너나 인스턴스에 추가 인프라나 에이전트의 설치를 유지하고 관리해야 합니다. 이전에는 서비스가 서로 검색 및 연결할 수 있도록 하려면 고유한 서비스 검색 시스템을 구성 및 실행하거나 모든 서비스를 로드 밸런서에 연결해야 했습니다. 이제 ECS 콘솔, AWS CLI 또는 ECS API를 사용하여 컨테이너형 서비스에 대한 서비스를 검색할 수 있습니다.
Amazon 라우트 53 서비스 등록 및 자동 명명 API 소개하기
Amazon ECS 서비스 검색은 Amazon 라우트 53 서비스 등록 및 자동 명명 API와 통신하여 작동합니다. 이 블로그에서 이 문제에 대해 이야기해 본 적이 없기 때문에, 라우트 53 API들이 어떻게 작용하는지 간단히 설명하려고 합니다. 먼저, 몇 가지 어휘를 말해 보겠습니다.
- 네임스페이스-네임스페이스는 트래픽을 라우팅 할 도메인 이름을 지정합니다(예: internal, local, corp). 서비스가 서로를 검색할 수 있어야 하는 논리적인 경계라고 생각할 수 있습니다. aws servicediscovery create-private-dns-namespace 명령에 대한 호출을 사용하여 네임 페이스를 생성하거나 ECS 콘솔에서 네임스페이스를 생성할 수 있습니다. 네임스페이스는 라우트 53의 호스팅 영역과 대략적으로 동등합니다. 네임스페이스에는 다음 단어인 서비스가 포함되어 있습니다.
- 서비스-서비스는 “인증”,”타임 라인”또는”작업자”와 같은 네임스페이스의 특정 애플리케이션 또는 애플리케이션 집합입니다. 서비스에는 서비스 인스턴스가 포함되어 있습니다.
- 서비스 인스턴스–서비스 인스턴스에는 Route 53이 리소스에 대한 DNS 쿼리에 응답하는 방법에 대한 정보가 포함되어 있습니다.
라우트 53은 API를 제공하여 네임스페이스를 생성하고, 작업 IP당 A 레코드를 생성하고, 작업 IP+포트별 SRV 레코드를 생성합니다.
라우트 53에 worker.corp과 같은 것을 요청하면, 우리는 그 요청을 이행할 수 있는 가능한 일련의 IP들을 돌려 받아야 합니다. 연결된 애플리케이션이 동적 포트 노출에 연결되어 있으면 호출 애플리케이션이 SRV 레코드를 손쉽게 쿼리 하여 자세한 내용을 확인할 수 있습니다.
ECS 서비스 검색 기능은 라우트 53 API 위에 구축되었으며 기본 API 호출을 모두 관리합니다. 이제 서비스 등록의 작동 방식을 이해하여 ECS 측에서 서비스 검색이 어떻게 작동하는지 확인할 수 있습니다.
Amazon ECS 서비스 검색기능
서비스 검색 기능으로 응용 프로그램을 시작해 봅시다! 먼저”flask-backend”과 “flask-worker”와 같은 두 가지 작업 정의를 생성합니다. 두 가지 모두 HTTP 요청을 처리하는 단일 컨테이너 서버가 있는 간단한 AWS Fargate 작업입니다. flask-backend을 써서 worker.corp에게 일을 하라고 요청하고, worker를 위해 라우트 53에 주소를 적어 응답과 함께 보내 주겠습니다. 아래 코드와 같습니다.
이제 컨테이너와 작업 정의가 준비되면 콘솔에 서비스를 생성하겠습니다.
서비스 마법사의 2단계로 이동하면서 서비스 검색 섹션을 작성하여 ECS를 통해 새 네임스페이스를 만들 예정입니다.
또한 ECS에게 서비스 중인 작업의 상태를 모니터링하고 필요에 따라 라우트 53에서 추가 또는 제거하도록 지시하겠습니다. 그럼 우리가 사용할 A 레코드에 TTL을 10초로 설정하겠습니다.
“작업자” 서비스에 대해서도 같은 단계를 반복할 것이며, 1분 정도 후에는 대부분의 작업이 실행될 것입니다.
라우트 53 콘솔에서 작업에 대한 모든 기록을 볼 수 있습니다!
라우트 53 서비스 검색 API를 사용하여 사용 가능한 모든 서비스와 작업을 나열하고 프로그래밍 방식으로 각 서비스에 연결할 수 있습니다. 백엔드 및 작업자를 제외하고는 어떤 서비스로도 쉽게 확장할 수 있습니다. 저는 “인증”,”Feed”,”타임라인”,”작업자”,”사용자”등과 같은 서비스를 포함한 가상의 소셜 네트워크에 대한 간단한 데모를 만들었습니다. https://servicediscovery.ranman.com/. Github에 해당 페이지를 실행하는 데 사용된 코드를 볼 수 있습니다.
지금 사용가능합니다!
Amazon ECS 서비스 검색은 현재 미국 동부(버지니아 북쪽), 미국 동부(오하이오), 미국 서부(오리건) 및 유럽 연합(아일랜드)에서 사용할 수 있습니다. AWS Fargate는 현재 미국 동부(버지니아 북쪽)에서만 사용할 수 있습니다. ECS 서비스 검색을 사용할 경우 생성한 각 네임스페이스를 포함하여 사용하는 라우트 53 리소스와 서비스가 수행하는 조회에 대해 비용을 지불해야 합니다. 컨테이너 수준의 상태 검진이 무료로 제공됩니다. 가격에 대한 자세한 내용은 설명서를 참조하십시오.
원문 URL: https://aws.amazon.com/ko/blogs/aws/amazon-ecs-service-discovery/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.