낑
AWS의 로드밸런서 서비스를 이용중이었다. 그리고 그 앞단에서 로드밸런서에 요청정보를 전달하는 Apache가 있었다.
😶: 인쟈 트래픽에 따라서 로드밸런서가 알아다가 분산하겠징
라고 생각했는데, 근 며칠동안 새벽마다 통신장애가 일어나 어느 시점부터 503 코드로 반환되었다.
귀신같이 퇴근만 하면 고장나는 서버에 뭐라도 씌인 것인 건가 싶었다. 연결된 네트워크에 안면인식기능이 탑지된 것 마냥 자정에 건물 문이 잠길 때까지 기다려도 눈앞에서 재연되지 않는 상황에 모두가 넋이 나갔다.
현지 시간대를 노린 누군가의 침입에 의한 것인가 싶어 access_log, error_log 를 다 뒤져보면 그 언저리 반갑지 않은 손님들의 소스 긁기를 위한 GET: 시도가 보이긴 하지만 그게 원인은 아니었다.
우선은 Apache의 프록시 설정을 바꿔보기로 했고, 그 김에 Nginx로 갈아탔다. 그리고 상황은 나아지지 않았다.
결론적으로 많은 시행착오와 자문을 구한 끝에 아래의 글에서 해결 소스를 얻었다.
Nginx proxy_pass 의 AWS ELB 연결 문제
어느날 nginx 의 proxy_pass 에서pending이 걸렸다. (두둥)
circlee7.medium.com
LoadBalancer의 Auto Scaling에 의해 새로운 인스턴스가 추가되면서 새로운 IP가 할당되었고, Nginx(apache 포함)는 그 새로운 IP를 알지 못하므로 전달이 도착하지 못하고 504를 반환했던 것이다.
그럼 왜 항상 눈앞에서는 해당 상황이 재연되지 않았나?
약간의 우연이 겹치긴 했다. 요근래 퇴근 전에 마무리하고자 성능을 보고자 부하테스트를 진행했었던 게 원인이었다. 당시에는
🥳🫠🫡😳: 이야 시원하다 잘 들어가는구망
라고 여겼는데 그 이후 로드밸런서가 해당 부하테스트에 대해서 일정 시간 이상의 부하 유지성을 먼저 파악한 뒤, Cool Down 기간 혹은 감시 기간에 따라 약간의 지연을 가진 뒤 스케일링 작업을 진행했다. 그게 때마침 테스트를 지켜보고 집에 들어간 새벽 시간대였던 것이고.
문제 상황을 인지하고, 파악하고, 해결책을 도입하고, 실제로 IP가 변하는 것에 대해 대응함을 확인하기까지 모두가 초조함에 시달렸지만 오늘부턴 다시 잘 잘 수 있었음 좋겠다