인프런 커뮤니티 질문&답변

안녕하세요~

섹션 10. 두번째 강의 (Redis service 생성하고 Service Discovery 적용하기) 보셨을까요? 여기서 문의하신 내용을 다루고 있습니다! 여기서 노드 서비스가 레디스 서비스와 VPC안에서 안전하게 통신하기 위해 Service Discovery개념이 적용됩니다. 물론 Redis가 일반적인 백엔드 서비스가 아니긴 합니다만 Service Discovery 원리는 같아요. Redis 대신에 다른 (마이크로) 서비스를 두시면 됩니다! Redis를 사용한 이유는 여러가지가 있는데요. 그 중 하나가 서비스를 직접 만들지 않고(서비스 개발하는데 불필요한 강의 시간을 쓰기 싫었어요!) 바로 service discovery와 같은 ECS 기능들을 시험해보기 위함이에요.

서브 도메인, 메인 도메인 그리고 관련해서 로드벨런서 문의도 남겨주셨는데요. 음 일단 아쉽게도 구체적으로 해당 사례를 강의에서 다루지는 않았어요. 하지만 이 강의에서 배운 내용을 응용해서 충분히 할 수 있는 내용이긴 합니다! 차후에 응용사례로 보강해보도록 할게요!

일단 질문을 남겨주셨으니 간략하게 설명을 드리겠습니다.

ECS Service 단위로 load balancer를 부착할 수 있자나요. 각각 독립적인 load balancer를 생성해줄 수도 있고 하나의 로드벨런서를 공유할 수도 있어요. 특별한 경우가 아니라면 비용절감을 위해 로드밸런서를 하나로 통합하는 편이라고 생각합니다. load balancer는 내부적으로 잘 scale up/down되도록 설계되어 있는 견고한 서비스거든요. 물론 그래도 separation of concern, 견고하더라도 혹시 모를 장애 발생을 대비해서 분리할 수도 있어요.

일반적으로는 두개의 서비스가 load balancer로 외부에 노출됩니다. MSA gateway 서비스 혹은 모놀리스 백엔드 서비스가 일단 대부분 있을거고요. 추가적으로 SSR용 프론트 서버(Next.js, Remix)를 두는 경우가 있어요. 그러면 백엔드는 보통 api subdomain을 이용하게 되고 프론트 서버거 메인 도메인을 쓰게 됩니다!

서비스별 load balancer를 부착하실거라면 강의에서와 동일하게 진행하면 되기 때문에 딱히 어려움이 없을 것으로 보입니다.

하나의 로드벨런서를 사용하는 경우:

Route53에서 기존에는 메인도메인을 위해 A 레코드만 추가해줬었는데여.

subdomain을 위해 CNAME 레코드를 하나 더 추가해줘야 합니다.
api.yourdomain.com -> load balancer

그러면 지금 main, sub 도메인 모두 같은 로드벨런서로 요청을 전달해주게 됩니다.

이제 main, sub 모든 요청이 하나의 로드벨런서로 들어오게 되죠. 그러면 로드벨런서에서 백엔드 그리고 프론트 서버로 올바르게 요청을 전달해주면 됩니다. 여기서 저희가 배운 Listener Rule 그리고 Target Group이 필요합니다. backend-target-group, frontend-target-group이런식으로 각 서비스별로 우선 target group을 만들어줍니다. 그 다음에 Listener Rule을 생성해주는데요. 강의에서는 포트를 확인했었죠. 여기에서는 각각 동일한 rule(둘다 https가 적용되어야할테니) + "Host" header에 규칙을 추가하면 됩니다! "Host"가 abi.yourdomain.com이면 backend-target-group으로 전달해주고 "Host"가 yourdomain.com이면 frontend-target-group으로 전달해주면 됩니다!