티스토리 뷰
AWS 서울 region 장애를 경험하며, 원인 파악부터 초기 대응 그리고 하루 동안 계속 생각하며 느낀 점에 대해 정리해 두려한다.
원인 파악
서비스 장애를 인지하고 원인을 찾아보았다. 가끔 EC2 인스턴스에 문제가 있어 특정 인스턴스가 내려갔다 올라오거나 하는 경우는 드물지만 있었다. 그래서 먼저 EC2 인스턴스들에 웹서버나 WAS서버 등이 떠있나 확인하였다. 확인 결과 모두 정상 동작하는 것을 확인하였고, 다시 원인을 찾기위해 브라우저에서부터 서버까지 접속하는 과정에서 어느 부분에서 장애가 발생하는지 찾아보았다. 웹서버를 통해 static page 접속은 정상으로 동작하는 것을 확인하였다. 그 후, WAS로의 reverse proxy를 확인하였는데 이 과정에 문제가 발생하고 있었다. 웹서버 로그 확인 결과, DNS 관련 error가 발생하여 WAS로 proxy하지 못하면서 502 ERROR를 내뱉고 있었다.
해결 과정
WAS 서버들 앞단에 부하 분산을 위해 ELB를 통해 로드밸런싱을 하고 있었는데, 웹서버는 이 ELB의 endpoint URL로 reverse proxy를 해주고 있었다. [AWS에서 ELB의 IP는 제공하지 않는다. 이유는 정확히 모르겠다. (확실하진 않지만, ELB에도 elastic IP를 설정할 수 있도록 한 걸 보면, IP가 가변적으로 변경되지 않을까 생각된다. CloudFront는 IP가 가변적인 것을 예전에 경험한 적이 있다.)]
저 Endpoint URL를 찾지 못하는 것 같은데, AWS에서 ELB의 Endpoint URL만 제공해주고 IP는 제공하지 않으므로 나는 ELB의 IP는 모른다. 생각해보니, DNS를 통하지 않고 웹서버에서 WAS 서버의 private IP를 Direct로 바라보도록 해줄 수 있다.
위에서 작성했듯이, CloudFront(CDN)의 IP가 가변적임을 예전에 경험 했기 때문에, ELB도 IP가 가변적일 수 있다는 가정을 전제했지만, CDN에서도 IP가 수시로 변경되진 않았고 일정 시간 유지가 되었음을 고려해봤을 때, 다른 해결 방안을 찾거나, 또는 AWS가 빠르게 장애복구 해주기를 기도하며 임시적으로 ELB의 IP를 바라보도록 해주는것은 나쁘지 않다고 생각했다. 그래서 결국, 웹서버에서 WAS서버 앞단의 ELB IP를 Direct로 바라보도록 설정을 변경하고 서비스가 정상 동작함을 확인했다.
생각
AWS 장애 사례를 찾아보니 외국에서 몇 년 전에 4시간정도 인스턴스 장애가 발생했던 적이 있었다고 한다. Cloud를 맹신하면 안된다는 걸 깨달았다. 여러 커머스, 서비스 업체들에서도 이번 AWS 장애를 경험한 것으로 보이는데, 문제점을 생각해보면 한가지 의문이 있다.
서울 리전을 사용했지만, 가용 영역(available zone)을 2개로 분산하여 안전 할 것이라 생각 한 것이다. 이 가용영역은 네트웍이나 전원 등을 별도로 사용하므로 서로 독립적이고, 안정성 등을 높일 수 있을 것으로 착각했으나 두 가용 영역에 EC2 인스턴스를 분산 시켜놨지만 이번에 모두 문제가 발생하였다.
이번 장애를 통해서, 서비스 안정성을 고려해 볼 때, 클라우드를 사용 할 경우 Multi Cloud, Multi Region 등이 필수적인가를 생각해볼 수 있는 기회가 되었다. 하지만, Multi Region 등을 고려하면, 비용 측면에서는 부담이 더 가기 때문에 중소 서비스 업체들에서는 부담이 더 갈 수도 있으므로 신중하게 고려해야겠다.