[AWS트러블슈팅] NLB의 Target Group이 unhealthy인데 원하는 통신이 된다?

안녕하세요 해당 블로그를통해 AWS를 사용하면서 자주 겪는 트러블슈팅을 연재해보고자 합니다.

AWS는 가상의 서비스이기 때문에 많은 부분이 Black Box 영역으로 알 수 없거나, 사전검증(Prototype Of Concept)이 필요합니다.
따라서 알 수 없는 영역이나 사용자가 충분히 이해하지 못하고 있는 부분에서 장애 또는 이슈가 발생할 수 있습니다.

그 간지러운 부분을 조금이나마 긁어드리고 싶은 마음으로 시작해보도록 하겠습니다.

NLB의 Target Group이 unhealthy인데 원하는 통신이 된다

그 첫번째가 AWS NLB(Network LoadBalancer)입니다. NLB는 Target Group으로 트래픽을 전달하도록 되어있습니다.

기존에 ALB/NLB가 없던 시절 CLB(Classic LoadBalancer)는 Target Group개념이 없었고 직접 EC2 Insntace를 할당하였었죠.
어쨌든, NLB던 CLB던 뒤에 붙어있는 서버와 제대로 통신을 하고 있는지 확인을 하는 기능을 갖고 있습니다. 바로 Health check 입니다.

Health check를 어떻게 해야하는지는 다음 블로그에 연재해보도록 하고 오늘은 CLB와 NLB가 Health check 방식에 차이점을 이야기 해보도록 하겠습니다.

CLB같은 경우는 Health check가 완료가 되지 않으면 뒤로 더이상 트래픽 자체를 보내지 않습니다.
하지만 NLB는 Health check와 상관없이 Target Group으로 트래픽을 전달 합니다.

그렇게 EC2에 할당되어있는 AWS Security Group정책에 의해서 트래픽이 최종 프로세스로 전달이 될지 안될지 결정이 됩니다.
한단계 더 들어가보면 OS에도 selinux firewalld 같은 방화벽에 의해 트래픽이 제어가 될 수 있다는점 꼭 인지하셔야합니다.

다시 본론으로 돌아와서 NLB의 Health check얘기를 해보겠습니다. 아래 그림과 같이 Target Group에 붙어있는 EC2에 Nginx를 80포트로 구동하고, health check를 8080으로 해보겠습니다.
해당 테스트는 security group을 포함한 모든 방화벽은 any open이라고 가정하겠습니다.

그러면 당연히 EC2에는 8080으로 동작하는 서비스가 없기 때문에 health check가 안돼겠죠 Target Group의 Instance 상태가 unhealthy로 보여집니다. 그런데, 이상태에서 a.test.com으로 통신 테스트를 해보면 통신이 가능한 것을 확인할 수 있습니다.

앞서 말씀드린 Health check와 상관없이 Target Group 으로 통신이 가능하도록 설계가 되어있기 때문입니다.

결론

NLB의 Health check를 통해서 원하는 서비스가 잘 구동이 되어있는지 판단하는것은 것은 위험할 수 있습니다. NLB의 Health check와는 무관하게 Target Group으로 트래픽을 전달하기 때문에 사용자가 원하는 판단을 하지 못할 수도 있기 때문입니다.
따라서 NLB를 통해 서비스의 구동 유무를 판단하기 보다는 OS레벨에서 직접 프로세스가 살아있는지를 판단해야 합니다.