[AWS] ECS: Service Connect

#AWS

ECS Connect는 ECS에서 제공되는 특수한 확장 기능 중 하나다.
ECS 서비스들끼리 내부통신을 맺어줄 수 있게 해주는 편리하고 유용한 기능이다.

내부적으로는 AWS Cloud Map 기반으로 동작한다.

비용

내부 구조로 사용하는 Cloud Map 자체는 유료지만, ECS Connect 사용사례에 있어서는 거의 완전 무료다.

추가 비용이 발생할 여지는 거의 없으나, 컨테이너마다 몰래 연결을 위한 프록시를 띄우기 때문에 약간의 컴퓨팅 리소스 소모는 생길 수 있다.

이걸 언제 써야할까? 한번 예시를 들어보겠다.

흔한 ECS의 사용 패턴은 대부분 이럴 것이다.
ECS 서비스에 로드밸런서 물리고, 로드밸런서를 통해서 요청을 받도록 구성한다.

근데, 여기서 서비스 간에 통신을 하게 된다면 어떻게 해야할까?

일반적으로는 로드밸런서를 통해서, 서로가 아무 연관 없는 3자인 것처럼 쓸 수도 있을 것이다.

하지만 이런 구조는 비용/성능/보안적으로 문제가 될 수도 있다. 특히나, 통신이 빈번하게 발생하는 경우에는 불필요한 트래픽 요금이 과다청구될 수도 있다.
외부통신은 VPC 내의 내부통신보다 훨씬 비싸기 때문이다.

ECS Connect는 이렇게 직접 상호간의 통신을 맺어주는 역할을 해준다.
이러면 당연히 VPC 내부통신을 하기 때문에 비용적으로도, 성능적으로도 이득이 생긴다.

로드밸런서를 직접적으로 거치친 않지만, ALB와 Target Group Health Check 구성을 제대로 했다면, 헬스체크 기반으로 잘 살아있는 서버에 대해서만 라우팅을 알아서 잘 해준다.

한번 설정하면서 그 사용 구조를 살펴보자.

먼저, 서버 역할을 할 ECS 서비스에 들어가서 "서버"로서의 역할을 할 수 있도록 구성해줘야 한다.

서비스 탭에서 네트워크 구성 탭을 보면 이런게 있는데

"클라이언트 및 서버"로 선택하고

네임스페이스를 기반으로 잘 생성해주면 된다.
이 "네임스페이스"라는 공유 영역을 기준으로 서로간에 자유롭게 통신을 할 수 있게 되는 것이다.

열어줄 포트도 여기서 지정한다. 해당 개별 태스크들이 80 포트로 리스닝을 한다면 80 포트로 열어주면 된다.

그렇게 생성하면, 이렇게 엔드포인트가 생성된다.
저 엔트포인트는 저 네임스페이스에 속한 서비스들이 전부 자유롭게 사용할 수 있는 내부 엔드포인트가 된다.
밖에서는 접근이 불가능하다.

설정을 완료하면, ECS가 해당 설정을 반영해서 자동으로 서비스를 재시작한다.

이제 서버는 준비가 됐다.

이번에는 클라이언트 역할을 할 친구에게 가보자.
서버와 꼭 같은 클러스터에 있지 않아도 된다. 같은 VPC 안에만 있으면 된다.
다른 VPC 간에도 어떻게 할 수는 있는데, 피어링 걸고 이것저것 건드릴게 많아진다.

일단, 이제 클라이언트는 방금 만들어진 내부 엔드포인트를 통해서 접근을 하면 된다.

그리고 마찬가지로 service connect를 활성화하면 되는데

나중에 서버 역할도 할 여지가 있다면 클라이언트 겸 서버로 띄워도 된다.

이렇게 하고 찌르게 하면 끝이다.

여기에는 꽤 공들여 만든 함정이 하나 있다.

이 Connect를 활성화할때 서버 모드도 활성화한다면, 그 Agent 구성이 전체 네트워크 구성을 덮어씌워버린다는 것이다. 그래서 내부통신을 하지 않고 외부통신으로 인입될 때도 Connect Agent를 통해서 들어온다.

근데 문제는 Connect Agent 자체에도 타임아웃 설정이 있다는 것이다.
무턱대고 이걸 활성화하면 기존 API들에 대해서도 일괄적으로 15초 제한이 생기는 셈이다.

그런 상황을 원하지 않는다면 타임아웃을 넉넉하게 설정한 채로 활성화해야 한다.

이걸 왜 이따위로 만든건지 모르겠다... 타임아웃을 없는 채로 만들 수는 없는건가?