 AWS에서 테스트 1473;1064; 서비스에 SSL 1064;1613;서 ,152;/140;고 1089;업1473;1064;데 AWS 1088;체 1064;1613;서 0156;급 후 /196;드0184;런서/196; 연결Ȣ16;/140;고 합니다.
443 포트에 메1064; 서비스가 1105;혀1080;고 80 포트lj16; 보안상 0120;사용 상태1077;니다.
Route 53에lj16; 통상1201;1004;/196; Ȣ16;Ǐ19;1060; 80포트 1217;속시 4431004;/196; 연결Ȣ16;도/197; 세ᔚ1;.104;Ǻ12;1080;구요.
1064;1613;서 0156;급과 도메1064; 연결까1648;lj16; 1096; .104;었고 1068;단1008; A/112;코드에 1064;스턴스 IP를 ,152;Ǻ12;서 0148;/196; 연결Ȣ16;,172; 해.164; 상태1077;니다.
계속 /196;드0184;런서에서 사용Ȣ16;lj16; target group라lj16; ǥ12;ǥ16;에서 ኔ1;7176;네요...
여기서 health check에서 계속 오류가 뜨lj16;데, 보고 1080;lj16; /112;6140;런스에서lj16; health check 프/196;토콜1012; TCP/196; 0148;ǂ12; 1204;달Ȣ16;면 문1228; 없1012;,144;라고 1201;혀1080;습니다...
근데 dashboard에서lj16; TCP UDP를 설1221;Ȣ16;lj16; ǥ12;ǥ16;1060; 보1060;1648; 않lj16;데, 1060;ᅆ1;우 Ǻ12;떻,172; 해야 오류 해결 가능할1648; 1312;Ǻ16; 1452;시면 감사Ȣ16;,192;습니다
그리고 일단, 사용중이신 로드밸런서의 종류가 무엇인지 말씀해 주세요. ALB인지 NLB인지 혹은 CLB인지..
알고 계시겠지만 ALB (Application Load Balancer)는 HTTP, HTTPS(레이어7) 프로토콜을 지원하는 로드밸런서이고 NLB(Network Load Balancer)는 TCP/UDP등(레이어4)를 지원하는 로드밸런서입니다. 따라서 타겟그룹도 거기에 맞춰 생성을 해줘야 하는 것도 알고 계시리라 생각합니다.
한편, 타겟그룹 생성시 프로토콜을 HTTP나 HTTPS로 잡으면 Health Check도 기본적으로 HTTP나 HTTPS중에서만 지정하게 되어 있죠.. 타겟그룹 자체의 프로토콜을 TCP로 잡으면 Health Check에서도 TCP를 선택할 수 있게 됩니다.
또 Health Check에 TCP를 지정할 수 있는 건 CLB인데 이건 특별한 이유가 없다면 굳이 쓸 일이 없다고 봅니다. AWS에서도 ELB(ALB 또는 NLB..)를 권장하고 있구요.
암튼, 실제 서비스되고 있는 포트와 헬스체크 포트가 일치하는지 다시 확인해 보시고..
아, 그리고 기본적으로 시큐리티 그룹부터 확인해 보시는 게 우선이겠네요. ㅎㅎㅎㅎ 저도 시큐리티 그룹때문에 여러 번 골탕먹었습니다. ㅎㅎㅎㅎ
80포트는 일반 HTTP 접속시 HTTPS로 포워딩되게 잡아둔 포트입니다. ALB로 설정해주는게 제일 간편하다고 해서 그렇게 했었구요.
참고해서 마저 작업해 보겠습니다! 감사합니다:)
지금 찾아보니 시큐리티그룹(SG)은 한글 표기로는 보안그룹이라고 하는군요. 암튼, 이 ALB에도 보안그룹이 할당되어 있을테고, 타겟 EC2 인스턴스들도 공통 보안그룹이 할당되어 있을텐데, ALB가 EC2의 상태를 확인하기 위해선 당연히 이를 위한 룰이 적절히 설정되어 있어야 하죠. 즉, ALB 보안그룹의 아웃바운드 -> 타켓 EC2 보안그룹의 인바운드 룰이 매칭이 되어야 하죠. 그런데 처음엔 이걸 깜빡하고서 왜 health check가 실패하지?? 한 경우가 개인적으로 종종... ㅠㅜ 있었거든요.
마침 찾아보니 이와 관련해서 딱 적당한 문서가 있네요.
https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-update-security-groups.html