로드밸런서의 health check
우리가 수기로 배포를 진행할때도 배포가 완료되면 배포된 ec2의 ip 주소로 들어가
hello World! 와 같은 문구가 잘 보이는지 확인합니다.
(이런 느낌이랄까)
helloWorld가 안뜨고 무한정 로딩되거나 503 과 같은 에러가 보이면 우리는 배포가 실패했다는 것을 알 수 있습니다.
그렇다면 CI/CD를 사용할때는 aws가 어떻게 배포가 잘 됐는지 알 수 있을까요?
방법은 loadbalancer의 tagetgroup(대상그룹)의 health check 기능을 통해 확인합니다. 물론, 이 healthcheck는 단순히 배포 성공여부를 위해서만 존재하지 않습니다.
ec2 서버가 살아있는지, 현재 ec2 접속이 잘되고 있는지 체크 해주고 개발자에게 알림을 보내는 등등의 다양한 역할을 합니다.
아래의 AWS의 문서를 통해 확인해보면 로드밸런서에 등록된 포트에서 tcp 연결이 되고 있는지 확인하고, 등록된 주소로 http 요청을 보내 200 상태 코드가 돌아오는지 확인합니다.
https://aws.amazon.com/ko/builders-library/implementing-health-checks/
로드밸런서 -> 등록된 대상그룹(target-group) 으로 접속하면 아래와 같이 aws에서 주기적으로 진행하는 healthcheck를 통해 상태를 확인할 수 있습니다.
Custom health-check가 필요한 케이스 및 생성 방법
로드밸런서를 생성할때 target-group을 함께 생성해야합니다.
이때 아래와 같이 protocol 버전을 고르고 health check 방식을 지정할 수 있습니다.
여기서, 그냥 나는 루트로 접속하여(ex, http://{ip주소}/) healthcheck를 진행하고 싶다면 다음으로 넘어가도 괜찮지만 만약 루트 주소가 로딩하는 시간이 길다거나 가져오는 데이터가 많다면 어떨까요?
저의 경우, 루트 페이지가 DB에 접속해 서로 다른 테이블에서 가져와야 하는 데이터가 10개가 넘게 사이트 였습니다.
굳이 로드밸런서가 healthcheck를 할때 이렇게 많은 데이터가 필요한 페이지로 상태를 검사해야할까요? DB가 RDS라면 한번 조회할때 드는 비용도 있는데, 상태 검사를 실행할때마다 돈을 내야한다면 비용적인 측면에서도 좋지 못합니다.
가장 좋은 방법은 health check를 진행하는 라우트(페이지)를 하나 생성하고 healthCheck 설정을 그 주소로 변경하는 것입니다.
저의 경우는 주소를 ('/health) 로 설정하고 그 페이지에서 "Select * from {tableName} where id = 1" 을 수행하도록 하였습니다. db 테이블에서 꼭 조회하는 쿼리가 수행되는 페이지를 만들 필요는 없지만, 저는 db와도 잘 연결이 되는지까지 확인이 되야 성공적으로 배포되었다는 것을 확인할 수 있기 때문에 위와 같이 진행하였습니다.
그런 다음에 대상그룹에서 healthCheck path를 아래와 같이 변경하면 됩니다.
