[AWS] ECS: Private Server 구성하기

#AWS

MSA 전용 내부서버를 구성하다보면 서버와 서버 엔드포인트를 private, 그러니까 내부 접속 전용으로 만들어야 할 때가 있다. AWS에서는 VPC 내부에서만 접근 가능한 식으로 제약을 걸고 싶을 것이다.

그럴 때는 여러가지 불편한 처리가 추가된다. 설정할 것도 많고 비용이 발생할 요소도 훨씬 늘어난다.
private 기반으로 리소스를 구성하면 비용 뻥튀기는 피할 수 없는 숙명인 것 같다.

ECR 관련 네트워킹 구성

의외의 복병이 ECR 관련 설정이다.
ECS Service가 로드되려면 어디에선가 Docker 이미지를 가져와서 띄워야 하는데, 여기에서도 자잘하게 신경써야할 부분이 존재한다.

이런식으로 pull이 실패할 수 있기 때문이다.

ECR을 사용하지 않을때

Docker hub나 Github docker 저장소 같은 다른 곳에서 이미지를 가져올때는 명백하게 외부 인터넷을 사용하게 된다.

이렇게 도커허브 이미지를 가져다쓴다 치면

NAT 게이트웨이 설정만 잘 되어있어도 문제없이 이미지를 가져울 수 있다.
물론 NAT 통신비용은 추가로 발생한다.

잘 동작했다.

요청도 잘 된다.

ECR을 사용할때

언뜻 보면 ECR을 사용하지 않을때보다 간편하고 설정이 쉬울 것 같지만, 그렇지만은 않다.

일단 테스트를 위해 nginx 이미지를 ecr private repo에 올렸다.

그걸로 작업정의를 교체했다.

그리고 그냥 실행해보면

이런 에러가 뜰 수 있다.
같은 aws 서비스임에도 ecr 서버로 접속할 수 있는 통로가 뚫려있지 않다고 오류가 나는 것이다...

여기서 가장 간단하게 해결할 수 있는 방법은 NAT 게이트웨이를 사용하는 것이다. 하지만 NAT 게이트웨이는 통신비용이 꽤 비싼 편이라, 배포가 좀 자주 일어난다면 비용 축적이 심해질 수도 있다.

권장되는 방법은 그냥 VPC 엔드포인트를 뚫어서 같은 VPC 내에서 통신이 가능하도록 명시적으로 네트워크 구성을 해주는 것이다. 이게 열려있으면 NAT보다 이걸 우선으로 통신한다. 내부통신이기 때문이다.

ecr 엔드포인트 2개, s3 게이트웨이 1개, logs 엔드포인트 1개가 필요하다.
이런걸 내가 왜 수동으로 하나씩 해줘야 하는건지 모르겠지만, 아무튼 AWS는 그렇다.
모든 유저들이 모든 VPC에 모든 엔드포인트를 열어둘 것이라고 생각하고 설계를 했나보다.
저거 하나마다 다 고정비가 나간다.

ecr은 당연히 ecr api로 레포지토리 정보를 확인할때 쓴다.

근데 또 도커 인터페이스는 그것대로 따로 요금을 뜯는다. 정신이 나간건가?

s3 게이트웨이도 필요하다.
도대체 왜인지는 모르겠지만, 내부적으로 도커 이미지를 s3에 다운받은 다음에 그걸 쓰는 구조라고 한다.

또 로그도 필요하다. 정신나갈거같다.

적당히 이렇게 4개 뚫어놓고 배포를 시도하면, 그때는 잘 받아서 올라갈 것이다.

로드밸런서 구성

당연히 로드밸런서도 ECS Service와 동일한 private 서브넷으로 깔아준다.

적당히 옵션 주고 만들었다. 거의 기본값이다.

근데 여기서 이상한 점이 좀 있다.

원본 IP로 조회하면 잘 동작하는데

로드밸런서로 꽂으면

무한히 대기하면서 블락된다.
분명히 내가 지금 curl을 날리고 있는 EC2 머신은 ECS, 로드밸런서와 동일한 서브넷을 공유하고 있다. 그럼에도 뭔가 내부통신이 수월하게 이뤄지지 않고 있는 것이다.

이게 왜 그런가 하면, 로드밸런서 DNS도 DNS인지라 요청을 할때 dns lookup을 한다.
Application 로드밸런서가 고유의 IP를 가지고 있지 않고 private IP 라우팅도 안되는 반쪽짜리 로드밸런서라서 이런 문제가 발생하는 것이다.
그래서 이 문제를 해결하려면 Network Loadbalancer를 Application Loadbalancer 앞에 붙여줘야 한다.
당연히 돈이 더 나간다.