2개월에 걸친 격투 끝에 RDS 접속 상한선 주위의 병목을 해결하였다

MySQL의 max_이것은 connections가 아닙니다

효과 포트 고갈에 대한 이야기가 아니다

연결의 상한선을 들으면 이 매개 변수들이 가장 먼저 떠오르지만 이번 원인은 이것이 아니다.
더 잘한 것 같아서 반성하고 공유하기 위해 썼어요.

무슨 일이 있었는지 (시간순으로)

어느 날 방문자 수의 도표지만 멋지게 한계에 이르렀다.
그동안 당연히 응답이 느려졌지.

이 액세스 수는 다음 구성의 경로에 있는 ALB에 대한 액세스 수의 값입니다.

CloudFront => ALB => ECS Fargate(web) => RDS
                                      => NLB => EC2(cache) => s3

※ ECS부터 DB의 정보에 따라 NLB에 HTTP를 요청합니다.
우리는 다음과 같은 조사를 했다

성능 모니터링/USE 방법

상기 경로의 모든 자원을 확인한 후 상한선에 도달하지 않은 곳

데이터베이스의 조회 성능도 떨어지지 않았다

지원을 문의했지만 기초적인 상한선을 확인할 수 없다고 한다

분석

로그의 응답 시간과 느린 조회 로그에서 NLB와 DB의 속도가 느려지지 않음

ECS 응답 시간만 느려짐

그러나 DB와 NLB는 앞으로 느려지지 않고 자원도 충분하지만 ECS가 왜 느려지는지 모르겠다

ECS 지연 시간을 확인할 수 없음

ECS에서 어플리케이션 구성기 가져오기

그런데 DB 주변의 라이브러리가 느려진 줄 몰랐어요.

PHP 구성 프로그램에서 로컬 라이브러리의 처리를 추적할 수 없음

제어 불가능 여부

라이브러리에 포함된 다른 시스템 호출로 인해 느려졌는지 여부

RDS 측이 통신에 회신하지 않았는지 불분명

추가 조사를 위해 ECS에서 운행하는 컨테이너가 EC2에서 운행

ECS Fargate만의 문제가 아닙니다

Syn+Ack에서 tcpdump와strace, eBPF 도구를 사용하지 않고 되돌아오는 것을 발견했습니다.

그렇다면 왜 Syn+Ack은 답장이 없습니까?
max_connection 미달, 효과기 포트 상한선 미달
패킷drop도 없고 부하가 높을 때 재현되기 때문에 네트워크가 원활하지 않은 것도 아니다
somax 같은 건 확인해도 돼요.
꽉 차다
어쩔 수 없어서 RDS의 실례 유형을 줬어요.

!!!!
안 붙였어, 했어!

무슨 일이야?

결론, 실례 유형을 높여라!완성
어쨌든 이것은 될 수 있는 문제였지만 결국 AWS 지지 씨의 대답은 사실을 증명했다.
결과적으로 RDS의 Security Group 설정이 잘못되었습니다.
연결을 제어하기 위해 Security Group이 실행했습니다연결 추적.
각 연결을 추적하기 위해 AWS 측은 상태를 유지합니다.
그리고 이 연결 추적 상태는 이 상태수에 상한선이 존재한다고 한다.
그리고 모든 실례 유형의 상한선은 변화한다.
이번에 유형이 바뀌어 문제가 완화되었다.
몰라요.

기술 솔루션

이번에는 유형을 바꾸어 해결했지만 필요하지 않은 자원과 원가가 필요하기 때문에 결과적인 해결일 뿐이라고 생각합니다.
기본적인 기술 해결 방법은 몇 가지가 있는데, 여기에 두 가지를 열거한다.
우선 속도조절기 방화벽 대책이다.
연결 추적이지만 0.0.0.0/0 등 조건에서 무조건 접근하면 연결이 추적되지 않습니다.
따라서 상한선에 이르지 않는다.
가바가바라고 하지만 IAM 인증과 MySQL의 인증 기능을 이용하면 문제가 없습니다.
다음은 연못 연결 대책이다.
연결을 끊거나 끊지 않으면 추적 상태는 하나입니다.
따라서 연결 탱크를 사용하면 문제가 발생하지 않는다.
작성하지 않았지만 ECS에서 RDS로 연결할 때마다 질의를 수행합니다.
HTTP2라도 연결은 계속 당겨야 합니다.
매번 연결되는 연결이 끊기는 것이 고비용 위험이 높은 곳입니까?
또 DB를 다이나모 DB로 만들고 DB의 대수를 늘리는 등 다양한 방법이 있다.

반성하다

문서에 상한선이 명확하게 적혀 있지 않기 때문에
일부러 그런 건 아닌 것 같아요.
제가 더 빨리 해결할 수 있을 것 같아요.

조사 방면의 반성점

일찍이 같은 환경 재현 상황을 준비했으면 좋겠다

도량 확인, 접근 로그 확인, 프로필 설정 등 다양한 설정을 하면 상황 재현이라는 기본적인 일은 완전히 떨어진다.

재현할 수 있다면 파라미터를 바꾸고 실험적인 방법을 취할 수 있을 것 같다

시스템 구성에 대한 반성

연결 풀은 처음부터 고려하는 것이 가장 좋을 것 같다

공유할 수 있는 세션이라면 수영장이 있으면 귀찮지 않기 때문이다

과거에도memcached의 효과기 포트 고갈 문제 등 경험이 있기 때문에 이런 것은 디자인적으로 고려해야 한다고 생각한다

운용 방면의 반성

이번 이벤트는 검증 환경을 준비하여 부하 테스트를 진행할 때 재현

반대로 말하면 부하 테스트를 하면 문제가 표면화되지 않는다

부하 테스트 자체는 어렵지 않지만 한 번의 부하 테스트는 통신비를 무시할 수 없다(자사에 비해)

매번 할 수 있는 것이 아니라 어떻게 운용하는 부분에 편입되는지 토론하고 싶다

총결산

이번 일은 분명하게 적혀 있지만 약 2개월간의 조사 끝에 해결된 현상이다.
사용자 여러분께 오랫동안 불편을 끼치지 않은 것에 대해 죄송합니다.
AWS의 성원에 감사드립니다.
기초적으로 문제가 있느냐고 물었을 때 현상이 판명되지 않은 것을 감안하면 상당히 보기 드문 상황을 인용한 것 같다.
나는 더 잘 해결하기 위해 더욱 정교해지고 싶다.
(뭔가 없애는 건 멋있지만 테킬라주에 대응하면 잘 풀리고 왠지 기술자의 슬픈 해결인 것 같다.)