Quay.io의 사후 부검이 불가능함

메모. 번역: XNUMX월 초, Red Hat은 지난 달 서비스 사용자들이 겪었던 접근성 문제를 해결하는 방법에 대해 공개적으로 밝혔습니다. Quay.io (회사가 CoreOS 구매와 함께 받은 컨테이너 이미지 레지스트리를 기반으로 합니다.) 이 서비스에 대한 귀하의 관심에 관계없이 회사의 SRE 엔지니어가 사고 원인을 진단하고 제거하기 위해 취한 경로는 유익합니다.

19월 XNUMX일 이른 아침(동부 일광 절약 시간, EDT)에 quay.io 서비스가 중단되었습니다. 이 사고는 quay.io 소비자와 quay.io를 소프트웨어 구축 및 배포용 플랫폼으로 사용하는 오픈 소스 프로젝트 모두에 영향을 미쳤습니다. Red Hat은 두 사람의 신뢰를 중요하게 생각합니다.

SRE 엔지니어 팀이 즉시 참여하여 가능한 한 빨리 Quay 서비스를 안정화하려고 노력했습니다. 그러나 이 작업을 수행하는 동안 클라이언트는 새 이미지를 푸시하는 기능을 상실했으며 가끔 기존 이미지를 가져올 수 있는 경우도 있었습니다. 알 수 없는 이유로 서비스를 전체 용량으로 확장한 후 quay.io 데이터베이스가 차단되었습니다.

«무엇이 바뀌 었습니까?“-이런 경우에 일반적으로 묻는 첫 번째 질문입니다. 문제가 발생하기 직전에 OpenShift Dedicated 클러스터(quay.io 실행)가 버전 4.3.19로 업데이트되기 시작했다는 사실을 확인했습니다. quay.io는 Red Hat OpenShift Dedicated(OSD)에서 실행되므로 정기적인 업데이트가 일상적이었고 문제가 발생하지 않았습니다. 또한 지난 XNUMX개월 동안 서비스 중단 없이 Quay 클러스터를 여러 번 업그레이드했습니다.

우리가 서비스를 복원하려고 시도하는 동안 다른 엔지니어들은 이전 버전의 소프트웨어로 새로운 OSD 클러스터를 준비하기 시작했습니다. 그래서 무슨 일이 발생하면 여기에 모든 것을 배포할 수 있었습니다.

근본 원인 분석

실패의 주요 증상은 수만 개의 데이터베이스 연결이 급증하여 MySQL 인스턴스가 효과적으로 작동하지 않게 되는 것이었습니다. 이로 인해 문제를 진단하기가 어려워졌습니다. SRE 팀이 문제를 평가하는 데 도움이 되도록 클라이언트의 최대 연결 수에 제한을 설정했습니다. 우리는 데이터베이스에 대한 비정상적인 트래픽을 발견하지 못했습니다. 실제로 대부분의 요청을 읽었고 소수만 쓰기만 했습니다.

우리는 또한 이러한 사태를 일으킬 수 있는 데이터베이스 트래픽의 패턴을 식별하려고 노력했습니다. 그러나 로그에서는 어떤 패턴도 찾을 수 없습니다. OSD 4.3.18이 포함된 새 클러스터가 준비되기를 기다리는 동안 우리는 계속해서 quay.io 포드를 시작하려고 시도했습니다. 클러스터가 전체 용량에 도달할 때마다 데이터베이스가 정지되었습니다. 이는 모든 quay.io 포드 외에도 RDS 인스턴스를 다시 시작해야 함을 의미합니다.

저녁까지 우리는 읽기 전용 모드에서 서비스를 안정화하고 데이터베이스의 부하를 줄이기 위해 필수적이지 않은 기능(예: 네임스페이스 가비지 수집)을 최대한 비활성화했습니다. 동결이 중지되었습니다. 하지만 그 이유는 발견되지 않았습니다. 새로운 OSD 클러스터가 준비되었으며 서비스를 마이그레이션하고 트래픽을 연결하며 계속 모니터링했습니다.

Quay.io는 새로운 OSD 클러스터에서 안정적으로 작동했기 때문에 데이터베이스 로그로 돌아가 보았지만 막힘을 설명하는 상관 관계를 찾을 수 없었습니다. OpenShift 엔지니어는 Red Hat OpenShift 4.3.19의 변경 사항이 Quay에 문제를 일으킬 수 있는지 파악하기 위해 우리와 협력했습니다. 그러나 아무것도 발견되지 않았고, 실험실 조건에서 문제를 재현하는 것은 불가능했습니다..

두 번째 실패

28월 XNUMX일 정오(EDT) 직전에 quay.io는 동일한 증상으로 다시 충돌했습니다. 데이터베이스가 차단되었습니다. 그리고 다시 우리는 조사에 모든 노력을 기울였습니다. 우선 서비스 복원이 필요했다. 하지만 이번에는 RDS를 재부팅하고 quay.io 포드를 다시 시작해도 아무 일도 발생하지 않았습니다.: 또 다른 연결의 눈사태가 기지를 압도했습니다. 그런데 왜?

Quay는 Python으로 작성되었으며 각 포드는 단일 모놀리식 컨테이너로 작동합니다. 컨테이너 런타임은 많은 병렬 작업을 동시에 실행합니다. 우리는 도서관을 이용해요 gevent 아래의 gunicorn 웹 요청을 처리합니다. 요청이 Quay에 들어오면(자체 API 또는 Docker API를 통해) gevent 작업자가 할당됩니다. 일반적으로 이 작업자는 데이터베이스에 접속해야 합니다. 첫 번째 실패 후, 우리는 gevent 작업자가 기본 설정을 사용하여 데이터베이스에 연결하고 있음을 발견했습니다.

상당한 수의 Quay Pod와 초당 수천 개의 요청이 들어오는 경우 이론적으로 많은 수의 데이터베이스 연결이 MySQL 인스턴스를 압도할 수 있습니다. 모니터링 덕분에 퀘이는 초당 평균 5천 건의 요청을 처리하는 것으로 알려졌다. 데이터베이스에 대한 연결 수는 거의 동일했습니다. 5개의 연결이 우리 RDS 인스턴스의 기능 범위 내에 있었습니다(수만 개라고 말할 수는 없음). 어떤 이유로 연결 수가 예상치 못하게 급증했습니다.그러나 들어오는 요청과의 상관 관계는 발견되지 않았습니다.

이번에는 문제의 원인을 찾아 제거하고 재부팅에만 국한되지 않기로 결정했습니다. Quay 코드베이스로 각 작업자의 데이터베이스 연결 수를 제한하도록 변경되었습니다. gevent. 이 숫자는 구성의 매개변수가 되었습니다. 새 컨테이너 이미지를 구축하지 않고도 즉시 변경할 수 있게 되었습니다. 현실적으로 처리할 수 있는 연결 수를 알아보기 위해 스테이징 환경에서 여러 가지 테스트를 실행하고 다양한 값을 설정하여 이것이 부하 테스트 시나리오에 어떤 영향을 미치는지 확인했습니다. 그 결과, 다음과 같은 사실이 밝혀졌습니다. Quay는 연결 수가 502개를 초과하면 10 오류를 발생시키기 시작합니다.

우리는 이 새 버전을 즉시 프로덕션에 배포하고 데이터베이스 연결 일정을 모니터링하기 시작했습니다. 기존에는 약 20분 만에 기지가 폐쇄됐다. 문제 없이 30분을 보낸 후 우리는 희망을 갖게 되었고, 한 시간 후에는 자신감을 갖게 되었습니다. 우리는 사이트의 트래픽을 복원하고 사후 분석을 시작했습니다.

차단으로 이어지는 문제를 우회하는 데 성공했으며, 우리는 그 진짜 이유를 찾지 못했습니다. 이전에 Quay에서 문제 없이 작동했던 버전 4.3.19에서도 동일한 현상이 발생하여 OpenShift 4.3.18의 변경 사항과 관련이 없는 것으로 확인되었습니다.

클러스터에는 분명히 다른 것이 숨어있었습니다.

상세한 연구

Quay.io는 기본 설정을 사용하여 XNUMX년 동안 아무런 문제 없이 데이터베이스에 연결했습니다. 무엇이 바뀌었나요? quay.io의 트래픽이 꾸준히 증가하고 있다는 것은 분명합니다. 우리의 경우, 마치 일부 임계값에 도달한 것처럼 보였고, 이는 눈사태처럼 많은 연결을 유발하는 역할을 했습니다. 우리는 두 번째 실패 이후에도 데이터베이스 로그를 계속 연구했지만 어떤 패턴이나 명확한 관계도 찾지 못했습니다.

그 동안 SRE 팀은 Quay의 요청 관찰 가능성과 전반적인 서비스 상태를 개선하기 위해 노력해 왔습니다. 새로운 지표와 대시보드가 ​​배포되었습니다., 고객이 가장 수요가 많은 부두 부분을 보여줍니다.

Quay.io는 9월 XNUMX일까지 잘 작동했습니다. 오늘 아침(EDT)에도 데이터베이스 연결 수가 크게 증가한 것을 확인했습니다. 이번에는 다운타임이 없었습니다, 새 매개변수는 그 수를 제한하고 MySQL 처리량을 초과하는 것을 허용하지 않았기 때문입니다. 그러나 약 XNUMX분 동안 많은 사용자가 quay.io의 성능 저하를 지적했습니다. 추가된 모니터링 도구를 사용하여 가능한 모든 데이터를 신속하게 수집했습니다. 갑자기 패턴이 나타났습니다.

연결이 급증하기 직전에 App Registry API에 많은 요청이 이루어졌습니다.. 앱 레지스트리는 quay.io의 잘 알려지지 않은 기능입니다. 풍부한 메타데이터가 포함된 Helm 차트 및 컨테이너와 같은 항목을 저장할 수 있습니다. 대부분의 quay.io 사용자는 이 기능을 사용하지 않지만 Red Hat OpenShift는 이 기능을 적극적으로 사용합니다. OpenShift의 일부인 OperatorHub는 모든 연산자를 앱 레지스트리에 저장합니다. 이러한 운영자는 OpenShift 워크로드 에코시스템 및 파트너 중심 운영 모델(2일 차 운영)의 기반을 형성합니다.

각 OpenShift 4 클러스터는 내장된 OperatorHub의 연산자를 사용하여 설치에 사용할 수 있는 연산자 카탈로그를 게시하고 이미 설치된 연산자에 대한 업데이트를 제공합니다. OpenShift 4의 인기가 높아짐에 따라 전 세계적으로 OpenShift XNUMX의 클러스터 수도 증가했습니다. 이러한 각 클러스터는 quay.io 내부의 앱 레지스트리를 백엔드로 사용하여 내장 OperatorHub를 실행하기 위해 운영자 콘텐츠를 다운로드합니다. 문제의 원인을 검색하는 과정에서 OpenShift의 인기가 점차 높아짐에 따라 거의 사용되지 않는 quay.io 기능 중 하나에 대한 부하도 증가한다는 사실을 놓쳤습니다..

App Registry 요청 트래픽을 일부 분석하고 레지스트리 코드를 살펴보았습니다. 즉시 데이터베이스에 대한 쿼리가 최적으로 형성되지 않는 단점이 드러났습니다. 부하가 낮을 때는 문제가 되지 않았으나, 부하가 증가하면 문제의 원인이 되었습니다. App Registry에는 로드 증가에 제대로 응답하지 않는 문제가 있는 두 개의 엔드포인트가 있는 것으로 밝혀졌습니다. 첫 번째는 저장소의 모든 패키지 목록을 제공했고 두 번째는 패키지에 대한 모든 Blob을 반환했습니다.

원인 제거

다음 주 동안 우리는 앱 레지스트리 자체와 환경의 코드를 최적화하는 데 시간을 보냈습니다. 확실히 비효율적인 SQL 쿼리가 재작업되었으며 불필요한 명령 호출이 제거되었습니다. tar (BLOB이 검색될 때마다 실행됨) 가능한 경우 캐싱이 추가되었습니다. 그런 다음 광범위한 성능 테스트를 수행하고 변경 전후의 앱 레지스트리 속도를 비교했습니다.

이전에는 최대 XNUMX분이 걸렸던 API 요청이 이제 밀리초 안에 완료됩니다.. 다음 주에 우리는 변경 사항을 프로덕션에 배포했으며 그 이후로 quay.io는 안정적으로 작동하고 있습니다. 이 기간 동안 App Registry 엔드포인트에서 트래픽이 몇 차례 급격히 급증했지만 개선을 통해 데이터베이스 중단을 방지했습니다.

우리는 무엇을 배웠습니까?

모든 서비스는 가동 중지 시간을 방지하려고 노력하는 것이 분명합니다. 우리의 경우 최근 중단이 quay.io를 개선하는 데 도움이 되었다고 믿습니다. 우리는 공유하고 싶은 몇 가지 주요 교훈을 배웠습니다.

1. 귀하의 서비스를 사용하는 사람과 방법에 대한 데이터는 결코 불필요하지 않습니다. Quay는 "그냥 작동"했기 때문에 트래픽을 최적화하고 로드를 관리하는 데 시간을 소비할 필요가 없었습니다. 이 모든 것이 서비스가 무한정 확장될 수 있다는 잘못된 보안 감각을 만들어냈습니다.
2. 서비스가 다운되면, 다시 시작하고 실행하는 것이 최우선 과제입니다.. Quay는 첫 번째 중단 동안 데이터베이스 잠김으로 인해 계속 어려움을 겪었기 때문에 표준 절차는 의도한 효과를 얻지 못했고 이를 사용하여 서비스를 복원할 수 없었습니다. 이로 인해 기능 복원에 모든 노력을 집중하기보다 근본 원인을 찾기 위해 데이터를 분석하고 수집하는 데 시간을 소비해야 하는 상황이 발생했습니다.
3. 각 서비스 기능의 영향 평가. 클라이언트는 App Registry를 거의 사용하지 않았기 때문에 우리 팀의 우선 순위는 아니었습니다. 일부 제품 기능이 거의 사용되지 않으면 버그가 거의 나타나지 않으며 개발자는 코드 모니터링을 중단합니다. 갑자기 그 기능이 큰 사건의 중심에 놓이게 될 때까지는 이것이 그래야 한다는 오해에 빠지기 쉽습니다.

다음은 뭐지?

서비스의 안정성을 보장하기 위한 작업은 결코 멈추지 않으며 지속적으로 개선되고 있습니다. quay.io의 트래픽 양이 계속 증가함에 따라 우리는 고객의 신뢰에 부응하기 위해 최선을 다해야 할 책임이 있음을 인식하고 있습니다. 따라서 현재 다음과 같은 작업을 진행하고 있습니다.

1. 기본 RDS 인스턴스에 문제가 발생할 경우 서비스가 적절한 트래픽을 처리할 수 있도록 읽기 전용 데이터베이스 복제본을 배포합니다.
2. RDS 인스턴스 업데이트. 현재 버전 자체는 문제가 없습니다. 오히려 우리는 (실패하는 동안 따라온) 잘못된 흔적을 제거하고 싶을 뿐입니다. 소프트웨어를 최신 상태로 유지하면 향후 정전이 발생할 경우 발생하는 또 다른 요인을 제거할 수 있습니다.
3. 전체 클러스터에 대한 추가 캐싱. 우리는 캐싱이 데이터베이스의 부하를 줄일 수 있는 영역을 계속해서 찾고 있습니다.
4. 누가 quay.io에 연결하고 있는지, 그 이유를 확인하기 위해 WAF(웹 애플리케이션 방화벽)를 추가합니다.
5. 다음 릴리스부터 Red Hat OpenShift 클러스터는 App Registry를 포기하고 quay.io에서 사용 가능한 컨테이너 이미지를 기반으로 하는 Operator Catalog를 사용할 예정입니다.
6. App Registry의 장기적인 대체는 OCI(Open Container Initiative) 아티팩트 사양에 대한 지원일 수 있습니다. 현재 기본 Quay 기능으로 구현되어 있으며 사양 자체가 완성되면 사용자가 사용할 수 있습니다.

위의 모든 사항은 소규모 "스타트업 스타일" 팀에서 성숙한 SRE 기반 플랫폼으로 전환함에 따라 quay.io에 대한 Red Hat의 지속적인 투자의 일부입니다. 우리는 많은 고객들이 일상 업무(Red Hat 포함!)에서 quay.io에 의존하고 있다는 것을 알고 있으며, 최근의 중단 상황과 지속적인 개선 노력에 대해 최대한 투명하게 공개하려고 노력하고 있습니다.

번역가의 추신

블로그에서도 읽어보세요.

• «CoreOS 컨테이너 이미지용 Red Hat 오픈 소스 레지스트리 코드 - Quay";
• «SRE 일상생활의 실용적인 이야기. 2 부";
• «Kubernetes의 Pod 우선순위가 Grafana Labs의 가동 중지 시간을 초래한 방법".

출처 : habr.com