게이트웨이 에러 분석하기
삐용삐용
클라우드 인프라 설정쪽에서 문제가 나서, 팀 내부적으로 관련 정보 공유를 할 것 같은데 겸사겸사 블로그에도 정리해본다. 내부에서 발표하는 것보다 공유할 수 있는 자료가 극히 제한적일테지만, 어찌저찌 잘 추상화해서 표현해보려한다. 읽다가 뭔가 건너뛰고 흐름이 끊기는 내용이 느껴져도 어쩔수(?) 없다. 최대한 노력해서 써봐야겠다.
문제 상황
특정 url을 비활성화 시켰는데, 서버 접속 자체가 안되는 현상이었다.
특이한 점은 내부망에서는 접속이 잘 붙고, 별도의 도메인으로 접근하는 외부망에서는 502 배드 게이트웨이 에러가 났다. 게다가 우리는 클라우드 리소스에 일부 접근 권한만 있어서, 구성이 어떻게 되어 있는지 감도 잘 안오고 껜또로 찍어 맞춰야 했기 때문에 더 어려웠던 것 같다.
분석
이유가 뭘까 계속 고민하던 중, 한 가지 눈에 띄는 창이 들어왔다. 평소에는 보이지 않던 ‘앱이 비정상입니다’ 라는 클라우드 자체 경고 문구였다.
이 경구 문구가 왜 뜨나 살펴봤더니, 헬스 체크 url로 요청을 보내고 200~399 사이의 응답이 오지 않으면 비정상이라고 판단하고 있었다. 그리고 하필 그 url은 우리가 이번에 비활성화 시켰던 주소였다. 하지만 여전히 내부망에서는 접속이 잘 되고 있었기 때문에, 어떤 차이일지 계속 고민해봤고 어느정도 원인을 결론지었다.
왜 그랬을까?
아마 이런 구성이지 않았을까 추측중이다.
내부망에서는 내부에 구축된 프라이빗 dns와 엔드포인트를 이용해서 직접 서버로 붙었다면, 외부망에서는 어플리케이션 게이트웨이 주소로 접속을 시도했을 것이다.
직접 테스트 용도로 어플리케이션 게이트웨이 리소스를 만들어서 붙여봤는데, 헬스 체크 데이터를 이용하고 있었다. 유사한 상황을 만들고 헬스 체크 url만 일부러 이상하게 줬더니 서버가 다운되었다고 판단했고, 요청을 라우팅하지 않았다. 로드밸런서 역할도 해야하기 때문에 어떻게 보면 당연한 판단이지 않나 싶다.
선택지는
- 헬스 체크 url을 별도로 만들던지
- 기존 url을 살리던지
둘 중 하나였는데 우리는 2번을 택했다. 점점 설명이 꼬이는 구간이 왔는데 사정이 복잡하다. 보안 감사로 인한 영향 정도로밖에 기술하지 못할 것 같다.
요즘 인프라, 데브옵스 업무를 하는 빈도가 잦아지고 있다. 아직 규모가 그리 크지 않은 개발팀에서만 경험할 수 있는 소중한 기회라고 생각한다. 막말로 이거 내 돈 주고 다 구축해보려면 돈이 얼마나 나갈까. 회삿돈으로 이것저것 만들어 보고, 재밌다.
25년도 상반기가 끝나간다. 다음에는 상반기 회고를 한번 써봐야겠다. 회고를 지금까지 써본 경험이 없기 때문에, 상반기 회고이면서 그동안의 밀린 얘기들을 다 하지 않을까 싶다. 어떤 얘기들을 써야 좋으려나