[AWS] 애플리케이션 접속이 안되거나 간헐적으로 접속이 끊길 시 로드밸런서 서브넷 설정 확인하기

안녕하세요.

 

이번 시간에는 애플리케이션 성능에 영향을 주는 로드밸런서 배포 시 주의사항을 알아보겠습니다.

인터넷 경계 로드밸런서에서 잘못된 설정으로 애플리케이션이 느려지는 케이스를 소개하고자 합니다.

 

1. 개요

"애플리케이션에 접속하는 데 걸리는 시간이 20~30초 걸리고 간헐적으로 해당 증상이 계속 발생합니다."
"APM에서는 특이사항이 없어 보이는데 인프라 레벨에서 어떤 문제가 있는지 점검 부탁드립니다."
"개발 환경에서는 성능 이슈가 없는데 운영 환경에서만 해당 문제가 발생합니다."

기존 온프레미스에서 구축된 서비스를 클라우드로 마이그레이션 하던 중 애플리케이션을 올린 후 지난주 개발자분께서 애플리케이션 성능 점검 요청을 해왔습니다.

AWS에서 네트워크 및 기타 인프라는 제가 생성하였으나 현재 애플리케이션 관련 일부 서비스를 개발자분이 CDK로 관리하던 중이라서 무엇이 문제인지 확인해봐야 했습니다.

 

2. 점검 시 확인사항

모든 인프라 엔지니어의 에로사항이지만 애플리케이션 접속 시 느리다는 얘기만으론 어디서 문제가 발생했는지 원인을 찾기 어렵습니다. 그런데 개발 환경과 운영 환경의 성능 차이가 발생한다는 말은 여러 점검 사항 중 원인을 추릴 수 있습니다.

 

1. 서버 리소스 문제

Cpu, 메모리, 디스크 등 애플리케이션이 올라간 서버의 리소스가 부족할 경우 애플리케이션 성능이 느려질 수 있습니다.

 

2. 데이터베이스 쿼리 문제

데이터베이스의 Slow Query, Indexing, Connection Pool 등 애플리케이션의 성능을 저하할 수 있는 요소를 확인합니다.

 

3. 애플리케이션 코드 및 로직 문제

애플리케이션 코드가 잘못 구성되거나 성능 저하를 발생시키는 비즈니스 로직이 있는 경우 성능이 느려질 수 있습니다.

 

4. 캐싱 및 세션 문제

캐시를 사용하고 있는데 Cache Miss가 다수 발생하는 경우 성능이 느려질 수 있으니 확인이 필요합니다.

 

5. 외부 시스템 문제 (API)

외부 API와 연동되어 있어 외부 API가 요청에 대한 응답을 늦게 처리하는 경우 성능이 느려질 수 있습니다.

 

6. 글로벌 서비스의 지리적 레이턴시

각각 다른 리전을 VPN 방식으로 서비스와 DB가 통신 중일 때 캐싱하지 않는 경우 접속이 느릴 수 있습니다.

 

7. 로드밸런서 설정 문제

로드밸런서의 구성이 적절하지 않은 경우 애플리케이션에 성능 문제가 발생할 수 있습니다.

 

그 외에 더 많은 이유로 애플리케이션 성능 저하를 발생시킬 수 있습니다.

개발 환경과 운영 환경의 구성이 다를 가능성이 높은 1, 2, 3, 7번을 우선 점검을 하면 되는데 APM 상 특이 사항이 없으므로 1, 2, 7번을 확인합니다.

 

3. 해결 방법

데이터베이스 쿼리는 DBA분께 확인 요청드리고 해당 서비스가 올라간 서버의 리소스를 확인합니다. 리소스 문제가 없음을 확인한 후에는 로드밸런서 설정을 확인하였습니다.

 

가장 먼저 확인한 것은 로드밸런서가 현재 Looping 상태에 빠지진 않았는지 확인하는 것이었습니다. 로드밸런서의 리다이렉션 설정이 잘못된 경우 Looping 상태에 빠져 애플리케이션이 리소스를 과소비하게 만들 수 있어 성능 저하가 발생할 수 있습니다.

 

두 번째로 확인한 것은 DNS 설정에서 로드밸런서의 엔드포인트를 가르키는 A 레코드와 CNAME이 루프 상태에 빠졌는지 확인하는 것이었는데 문제가 없는 것을 확인했습니다.

 

마지막으로 확인한 부분에서 문제를 해결할 수 있었는데 로드밸런서의 구성 문제였습니다. CDK로 배포하면서 로드밸런서의 배포 위치가 Public과 Private을 동시에 선택된 문제였는데 체계 선택이 인터넷 경계(Internet-facing)인 경우 Public 서브넷에 로드밸런서를 위치해야 하는데 다른 하나의 서브넷이 Private 서브넷에 배포되어 문제가 발생하였습니다.

 

https://stackoverflow.com/questions/54871524/elastic-load-balancer-pointing-at-private-subnet

Elastic Load Balancer pointing at Private Subnet

해당 게시글을 보면 애플리케이션 로드밸런서를 확인할 때 해당 로드밸런서에서만 간헐적으로 연결이 종료되거나 레이턴시가 발생한다는 내용이 있습니다.

여기서 핵심은 인터넷에 연결된 애플리케이션 로드밸런서(ALB)는 퍼블릭 서브넷에만 독점적으로 프로비저닝 되어야 한다는 내용입니다.

 

로드밸런서가 프라이빗 서브넷에 배치된 경우 브라우저는 로드밸런서에 연결을 설정할 수 없게 되고 서브넷 경로가 인터넷 게이트웨이가 아닌 다른 경로가 됩니다. 따라서 로드밸런서의 응답이 잘못 라우팅 되고 연결 시간이 초과됩니다.

 

특히 로드밸런서에 퍼블릭 서브넷과 프라이빗 서브넷이 혼합된 경우 시간 초과가 간헐적으로 발생합니다. 일부 연결은 퍼블릭 서브넷 일부 연결은 프라이빗 서브넷으로 라우팅되고 있기 때문입니다.

 

다행히 AWS 로드밸런서 설정 중에서 작업 - 서브넷 편집으로 서브넷의 위치를 빠르게 바꿔 배포할 수 있기 때문에 다음과 같이 인터넷 경계에 있는 로드밸런서의 서브넷을 Public 서브넷으로 변경하면 됩니다.

 

서브넷 편집으로 서브넷 변경 후 성능 이슈가 해결되어 애플리케이션이 정상적으로 작동하는 것을 확인할 수 있었습니다.

 

이번 시간에는 로드밸런서에서 인터넷 경계 로드밸런서 설정 시 주의사항을 알아봤습니다.

 

감사합니다.