인프런 영문 브랜드 로고
인프런 영문 브랜드 로고

인프런 커뮤니티 질문&답변

zerolike님의 프로필 이미지
zerolike

작성한 질문수

AWS로 쉽고 빠르지만 아주 견고한 서버 환경을 구축하는 방법

ECS 환경에서의 ELB 간헐적 504에러

해결된 질문

작성

·

96

·

수정됨

0

해당 강의를 보고 사내에서 개발서버 인프라구성을 변경중입니다. 해결되지 않는 이슈가 있어서 질문 드립니다.

 

AWS ECS로 배포진행하며, FARGATE가 아닌 EC2(arm64)로 현재 배포중입니다.

로드밸런서(80(443으로 redirect), 443(타겟그룹 전달)) -> 타겟그룹(IP형태의 타겟그룹) -> ECS Task

네트워크 모드는 awsvpc를 사용했으며, task는 private subnet에서 nat gateway와 정상적으로 연결됨을 확인하였습니다.

 

개발서버로 일부 기능만 내부적으로 테스트 중이라, 트래픽이 거의 없고, task의 CPU와 메모리 사용률은 30%이하를 유지중입니다.

 

대다수의 트래픽이 정상적으로 통과하지만, 특정 API 호출이 아닌 전반적으로 간헐적으로 로드밸런서에서 504 gateway timeout 이 발생합니다. (타겟그룹엔 정상적으로 healthy 상태로 등록되어 있습니다)

image.png

 

ex) 해당 기간내에 health-check 요청만 보내도, 일반적으로 잘 되지만 한번씩 헬스체크 요청조차 504 에러가 발생

 

기본적으로 잘 접속되지만 간헐적으로 발생하기에 네트워크설정쪽인 NACL이나 보안그룹의 문제는 아닐 것이라고 생각됩니다. nat gateway가 1개이긴하지만 트래픽이 매우 적어 충분할 것 같은데 혹시 가용영역별로 배치를 진행해야 하는걸까요?

혹시 이와 같은 사례를 경험하셨거나 해결방법에 대해 조언을 구하고자 합니다.

 

운영에서는 아직 ECS를 적용하지않아 EC2로 배포중인데, 해당 로드밸런서는 모니터링에서 504에러가 발생하지 않은 것으로 확인됩니다.

 

 

 

 

 

 

awsdockermsacontainerecsfargate

답변 3

0

zerolike님의 프로필 이미지
zerolike
질문자

문제가 해결되서 같은문제를 겪고 계신분들을 위해 공유드립니다.

 

간헐적으로 실패하는 이유는 ELB가 위치한 subnet의 NACL의 인바운드,아웃바운드 규칙에

32768~ 65535 로 0.0.0.0/0 으로 설정되어 있었는데

 

AWS VPC 공식문서에서 ELB와 NAT Gateway, lambda 등은 1024 ~ 65535 를 임시포트로 사용한다고 명시가 되어있어서 NACL의 인바운드,아웃바운드 규칙을 1024 ~ 65535 로 변경하였더니

간헐적으로 실패가 안되고 잘 성공하네요

https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html

 

0

Burger님의 프로필 이미지
Burger
지식공유자

안녕하세요 zerolike님

 

우선 nat gateway는 트래픽에 따라 내부적으로 자동 확장돼어 개발서버의 경우에는 웬만해선 가용영역별로 배치하실 필요는 없어보입니다.

 

해결을 도와드리기 위해 우선 인프라 구성을 좀더 여쭤보고싶습니다!

로드밸런싱 되는 태스크가 여러개인지

Api gateway 엔드포인트를 사용하고 계신지를 알면 해결에 좀 더 도움을 드릴 수 있을것 같습니다!

 

zerolike님의 프로필 이미지
zerolike
질문자

답변 감사합니다.

 

현재 개발환경 인프라 구성은 Route53에서 ex) https://dev-env.com 으로 연결시

인증서버를 담당하는 public subnet의 로드밸런서 alb로 연결되며 80포트는 443 redirect 로 인증서버로의 트래픽을 보내고 있습니다. 해당 서버는 단순 인증+api서버로의 트래픽 프록시역할을 하는 서버로 1대 구성되어 있으며 헬스체크는 api서버로 요청하고 있습니다.

 

public subnet의 로드밸런서(alb- internet-facing) 1개, 타겟그룹 1개(인증서버)

  • ECS (Fargate), 2CPU , 4GB (arm64)

private subnet의 로드밸런서(alb-internal) 1개, 타겟그룹 1개(api서버)

  • ECS (EC2) , 1.5vcpu, 3GB(t4g.medium)

api gateway는 사용하지 않고 있으며, 태스크는 각각 1개씩 띄워져있는 상태입니다.

혹시 private subnet으로의 프록시 과정에서 DB연결문제가 있을까 싶어서 순수 인증서버에 헬스체크를 체크하는 과정에서도 실패가 잦은 걸로 나옵니다.

 

ab -c 10 -t 120 https://dev-env.com/api/v1/health/server-status (api 서버로의 프록시 이후 헬스체크)

Concurrency Level:      10
Time taken for tests:   127.733 seconds
Complete requests:      5097
Failed requests:        5025
   (Connect: 0, Receive: 0, Length: 5025, Exceptions: 0)
Non-2xx responses:      72
Total transferred:      1558314 bytes
HTML transferred:       311004 bytes

 

ab -c 10 -t 120 https://dev-env.com/auth/v1/health/server-status (순수 인증서버 헬스체크)

Concurrency Level:      10
Time taken for tests:   120.181 seconds
Complete requests:      6495
Failed requests:        70
   (Connect: 0, Receive: 0, Length: 70, Exceptions: 0)
Non-2xx responses:      70
Total transferred:      1600640 bytes
HTML transferred:       22090 bytes
image.png

왼쪽의 직선의 케이스가 api서버로의 프록시로 헬스체크를 했을떄(ab -c 10 -t 120)

오른쪽의 20개 이상의 점으로 표기된것이 인증서버로의 자체 헬스체크했을떄(ab -c 10 -t 120) 입니다.

 

확실히 프록시로 하지않고 단순 헬스체크만했을때의 실패케이스가 적긴하지만, 간헐적으로 발생하는 점이 운영서버로의 ECS전환을 못하고 있습니다.

현재 구성에서 API Gateway를 사용하여서 구성도 가능한데 변경해서 시도해보면 문제가 해결될까요?

0

인프런 AI 인턴님의 프로필 이미지
인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 정영호님.

ECS 환경에서 ELB를 통해 간헐적으로 504 Gateway Timeout 오류가 발생하는 문제는 여러 가지 원인으로 발생할 수 있습니다. 504 오류는 주로 ELB가 백엔드 인스턴스와의 연결에 실패할 때 발생합니다. 발생할 수 있는 몇 가지 주요 원인을 확인하고, 해결 방법을 함께 살펴보겠습니다.

가능한 원인 및 해결 방법

  1. ECS Task의 리소스 부족:

    • ECS Task에 할당된 리소스(CPU, 메모리)가 부족할 수 있습니다. 실제 리소스 사용률은 30% 이하라고 하셨으나, 간헐적인 요청 폭주나 일시적 부하로 인한 일시적 자원 부족을 재차 확인 부탁드립니다. 혹시 최대 부하 상황에서도 충분한 리소스를 확보하고 있는지 확인하세요.

  2. 로드 밸런서의 타임아웃 설정:

    • ELB에 설정된 요청 대기 타임아웃 값이 앱의 응답 시간보다 너무 짧을 경우, 시간이 초과되어 504 오류가 발생할 수 있습니다. ELB의 Idle Timeout 값을 조정하여 문제를 해결할 수 있습니다. 기본적으로 ELB의 Idle Timeout은 60초입니다. 증가시켜 테스트해 보세요.

  3. 네트워크 연결 문제:

    • 간헐적인 네트워크 지연이나 불안정이 있을 수 있습니다. NAT 게이트웨이와의 연결 또는 VPC 내의 네트워크 설정을 다시 한번 확인해 보세요. 특히, 라우트 테이블이나 서브넷 간 연결이 문제 없는지 체크해 주세요.

  4. ECS 서비스의 헬스체크 구성:

    • ELB의 헬스체크가 백엔드 서비스의 실제 상태와 일치하도록 올바르게 구성되었는지 확인하고, 일관된 응답을 받는지 확인합니다. 헬스체크 간격 및 실패 임계값을 늘려 불일치를 줄여보세요.

  5. 로그 및 메트릭 확인:

    • AWS CloudWatch 로그 및 ELB 액세스 로그에서 문제의 타임스탬프를 찾아 추가적인 오류 메시지나 패턴을 확인할 수 있습니다. 로그 분석은 문제 진단에 큰 도움이 됩니다.

참고할 유사한 질문/답변:

앞서 말씀드린 각 단계별로 설정을 확인하는 것이 중요합니다. 문제가 반복될 수 있는 특정 조건이나 시점을 찾은 후 철저한 로그 분석을 통해 해결책을 마련할 수 있을 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

zerolike님의 프로필 이미지
zerolike

작성한 질문수

전체 Q&A
질문하기