일의 시작

사이트의 액세스 수가 일에 일에 늘어나는 가운데, 아무래도 일부의 액세스가 502 에러가 되고 있으면, Macerel 감시로 경보가 올라 왔습니다.
우선 아파치 재시작을 해 보거나 요청을 다른 서버에 놓쳐 보았지만 이벤트는 개선되지 않았습니다.

때 같게 하고, Mackerel을 보고 있으면, 이런 상태로...(당사 사이트는 2대의 Ec2로 중복 구성)



두 대 모두 떨어졌다 ...

바로 화면에서 당사 사이트를 확인해 보아도 제대로 표시할 수 있었습니다.

왜, 2대 모두 떨어지고 있는데, 화면이 표시되었는지 몰랐습니다만,
조사해 가는 동안에 알 수 있던 「과연-」를 써 둡니다.
(원래 문제를 해결하지 않으면 안 되므로, 그것도 아울러 써 둡니다.)

무슨 일이 있었는지

액세스 증가
↓
Apache 측의 프로세스 생성이 따라잡히지 않게 된다
↓
TLS 협상 오류가 발생함
↓
ALB 상태 확인 실패
↓
2대→1대→2대→1대・・・의 루프
↓
TLS 협상 오류가 추가로 발생함
↓
502 오류 반환

라는 일이 일어나고, 한 번 시작하면 액세스가 침착할 때까지 계속 건강에 해로운 상태가 발생하는 것을 알았습니다.

ALB의 절묘한 사양이 작용하고 있었다

성공적인 대상이 포함된 가용 영역이 없는 경우 로드 밸런서 노드는 모든 대상으로 요청을 라우팅합니다.

즉, 전멸하면, 어느 쪽인가에 리퀘스트를 보내지 않고, 전대에 걸친다는 것.

우리 환경에서는 두 개의 타겟 그룹(하나의 타겟 그룹에 하나의 EC2)이 있기 때문에,

1대 떨어졌을 때

Healty EC2 : 요청 할당

Unhealthy EC2 : 요청 할당하지 않음

2대 떨어질 때

Healty EC2 : 요청 할당

Unhealthy EC2 : 요청 할당

라는 상황이 되기 때문에, 통상시와 같은 거동이 된다는 것을 알았습니다.

우연히 그런 공기를 읽는 사양이었기 때문에, 미리의 리퀘스트는 제대로 돌려주고 있었는지, 라고 놀라움과 함께
사용하고 있는 AWS의 사양도 좀 더 세세한 곳까지 파악해야 한다고 반성.

해결 방법

음, 원래 TLS 협상 오류가 발생하지 않도록해야했습니다.
그 대응도 김에 써 두려고 생각합니다.

이번에 TLS 협상 오류가 발생한 근본 원인은
ALB에서 EC2의 Apache로의 연결을 충분히 늘릴 수 있도록 설정치의 재검토를 실시했습니다.

실제로 실시한 변경은 아래와 같습니다.

MaxKeepAliveRequests 늘리기

ALB <> 아파치 간의 연결을 돌리는 상한을 올린다 = connection 긴장 시간을 늘린다

MaxClients 늘리기

최대 프로세스 수의 상한을 올린다=대비 창구 늘린다

이것으로, 경과 관찰을 하고 에러가 재현하지 않게 되었으므로, 맑고 해결이 되었습니다!