최고 파카포프 시안

모든 좋은! 

제 이름은 Nikita이고 Cian 엔지니어링 팀의 팀 리더입니다. 회사에서 제가 맡은 책임 중 하나는 생산 인프라와 관련된 사고 수를 XNUMX으로 줄이는 것입니다.
아래에서 논의할 내용은 우리에게 많은 고통을 가져왔으며, 이 글의 목적은 다른 사람들이 우리의 실수를 반복하지 않도록 방지하거나 최소한 그 영향을 최소화하는 것입니다. 

서문

오래 전, Cian이 단일체로 구성되어 있었고 아직 마이크로서비스에 대한 힌트가 없었을 때 우리는 3~5페이지를 확인하여 리소스의 가용성을 측정했습니다. 

그들은 대답합니다 – 오랫동안 대답하지 않으면 모든 것이 괜찮습니다 – 경고합니다. 사건으로 간주되기 위해 얼마나 오랫동안 직장을 떠나야 하는지는 회의에서 사람들이 결정했습니다. 사고 조사에는 항상 엔지니어 팀이 참여했습니다. 조사가 완료되면 그들은 무슨 일이 일어났는지, 얼마나 오래 지속되었는지, 현재 무엇을 했는지, 앞으로 무엇을 할 것인지 등의 형식으로 이메일을 통해 일종의 사후 보고서를 작성했습니다. 

사이트의 기본 페이지 또는 우리가 바닥에 도달했음을 이해하는 방법

 
오류의 우선순위를 어떻게든 이해하기 위해 비즈니스 기능에 가장 중요한 사이트 페이지를 식별했습니다. 이를 사용하여 성공/실패한 요청 수와 시간 초과 수를 계산합니다. 이것이 가동 시간을 측정하는 방법입니다. 

사이트에 주요 서비스(광고 검색 및 제출)를 담당하는 매우 중요한 섹션이 여러 개 있다는 사실을 발견했다고 가정해 보겠습니다. 실패한 요청 수가 1%를 초과하면 이는 심각한 사고입니다. 프라임타임 중 15분 이내 오류율이 0,1%를 초과하는 경우에도 중대재해로 간주됩니다. 이러한 기준은 대부분의 사건에 적용되며 나머지는 이 문서의 범위를 벗어납니다.

최고 최고의 사건 Cian

그래서 우리는 사건이 일어났다는 사실을 확인하는 방법을 확실히 배웠습니다. 

이제 모든 사건이 자세히 설명되고 Jira 서사시에 반영됩니다. 그건 그렇고, 이를 위해 우리는 FAIL이라는 별도의 프로젝트를 시작했습니다. 이 프로젝트에서는 에픽만 만들 수 있습니다. 

지난 몇 년 동안의 모든 실패를 수집하면 리더는 다음과 같습니다. 

• mssql 관련 사건;
• 외부 요인으로 인한 사고;
• 관리자 오류.

관리자의 실수와 기타 흥미로운 실패에 대해 자세히 살펴보겠습니다.

XNUMX위 - "DNS에 정리하기"

폭풍우가 몰아치는 화요일이었습니다. 우리는 DNS 클러스터의 순서를 복원하기로 결정했습니다. 

내부 DNS 서버를 바인딩에서 powerdns로 전송하고 이를 위해 DNS 외에는 아무것도 없는 완전히 별도의 서버를 할당하고 싶었습니다. 

우리는 DC의 각 위치에 하나의 DNS 서버를 배치했으며 영역을 바인드에서 powerdns로 이동하고 인프라를 새 서버로 전환하는 순간이 왔습니다. 

이동 중에 모든 서버의 로컬 캐싱 바인딩에 지정된 모든 서버 중 상트페테르부르크의 데이터 센터에 있는 서버 하나만 남았습니다. 이 DC는 처음에는 중요하지 않은 것으로 선언되었으나 갑자기 단일 실패 지점이 되었습니다.
모스크바와 상트페테르부르크 사이의 운하가 무너진 것은 바로 이 이전 기간 동안이었습니다. 우리는 실제로 XNUMX분 동안 DNS 없이 방치되었다가 호스팅 업체가 문제를 해결했을 때 다시 일어났습니다. 

결론 :

이전에 작업을 준비하는 동안 외부 요인을 무시했다면 이제 그 요소도 우리가 준비하는 목록에 포함됩니다. 이제 우리는 모든 구성 요소가 n-2로 예약되도록 노력하고 있으며 작업 중에 이 수준을 n-1로 낮출 수 있습니다.

• 실행 계획을 세울 때 서비스가 실패할 수 있는 지점을 표시하고 모든 것이 "나쁜 상태에서 더 나쁜 상태로" 진행되는 시나리오를 미리 생각해 보세요.
• 다양한 지리적 위치/데이터 센터/랙/스위치/입력에 내부 DNS 서버를 배포합니다.
• 각 서버에 요청을 기본 DNS 서버로 리디렉션하는 로컬 캐싱 DNS 서버를 설치하고, 사용할 수 없는 경우 캐시에서 응답합니다. 

XNUMX위 - "Nginx에서 정리하기"

어느 화창한 날, 우리 팀은 "이제 충분하다"고 결정하고 nginx 구성을 리팩토링하는 프로세스가 시작되었습니다. 주요 목표는 구성을 직관적인 구조로 만드는 것입니다. 이전에는 모든 것이 "역사적으로 확립"되어 논리가 없었습니다. 이제 각 server_name이 동일한 이름의 파일로 이동되었으며 모든 구성이 폴더에 배포되었습니다. 그런데 구성에는 253949줄 또는 7836520자가 포함되어 있으며 거의 ​​7MB를 차지합니다. 최상위 구조: 

Nginx 구조

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

훨씬 나아졌는데 구성 이름을 바꾸고 배포하는 과정에서 일부 확장자가 잘못되어 include *.conf 지시문에 포함되지 않는 경우가 있었습니다. 결과적으로 일부 호스트를 사용할 수 없게 되어 기본 페이지에 301이 반환되었습니다. 응답 코드가 5xx/4xx가 아니기 때문에 이는 즉시 발견되지 않고 아침에만 발견되었습니다. 그 후 우리는 인프라 구성 요소를 확인하기 위한 테스트를 작성하기 시작했습니다.

결론 : 

• 구성을 올바르게 구성하고(nginx뿐만 아니라) 프로젝트 초기 단계에서 구조를 생각해 보세요. 이렇게 하면 팀이 더 쉽게 이해할 수 있게 되어 TTM이 줄어들게 됩니다.
• 일부 인프라 구성 요소에 대한 테스트를 작성합니다. 예: 모든 키 server_name이 올바른 상태 + 응답 본문을 제공하는지 확인합니다. 구성 요소의 기본 기능을 확인하는 몇 가지 스크립트만 있으면 충분하므로 오전 3시에 확인해야 할 사항을 정신없이 기억하지 않아도 됩니다. 

XNUMX위 - "카산드라에서 갑자기 공간이 부족해졌습니다."

데이터는 꾸준히 증가했고 Cassandra 클러스터에서 대형 케이스 공간의 수리가 실패하기 시작할 때까지는 모든 것이 괜찮았습니다. 압축이 작동하지 않았기 때문입니다. 

어느 폭풍우가 몰아치는 날, 클러스터는 거의 호박으로 변했습니다.

• 클러스터에는 전체 공간의 약 20%가 남아 있었습니다.
• 노드를 추가한 후 파티션 공간이 부족하여 정리가 진행되지 않기 때문에 노드를 완전히 추가하는 것은 불가능합니다.
• 압축이 작동하지 않아 생산성이 점차 떨어집니다. 
• 클러스터가 비상 모드에 있습니다.

종료 - 정리하지 않고 노드 5개를 더 추가한 후 공간이 부족한 빈 노드처럼 클러스터에서 노드를 체계적으로 제거하고 다시 입력하기 시작했습니다. 우리가 원하는 것보다 훨씬 더 많은 시간이 소요되었습니다. 클러스터를 부분적으로 또는 완전히 사용할 수 없게 될 위험이 있었습니다. 

결론 :

• 모든 Cassandra 서버에서는 각 파티션 공간의 60% 이하를 차지해야 합니다. 
• CPU의 50% 이하로 로드되어야 합니다.
• 용량 계획을 잊어서는 안 되며, 각 구성 요소의 세부 사항을 토대로 철저하게 고려해야 합니다.
• 클러스터에 노드가 많을수록 좋습니다. 적은 양의 데이터를 포함하는 서버는 더 빨리 과부하되고, 이러한 클러스터는 다시 활성화되기 쉽습니다. 

XNUMX위 – “영사 키-값 저장소에서 데이터가 사라졌습니다”

서비스 검색을 위해 우리는 많은 사람들과 마찬가지로 영사를 사용합니다. 그러나 우리는 또한 모놀리스의 청록색 레이아웃에 대한 키-값을 사용합니다. 배포 중에 위치가 변경되는 활성 및 비활성 업스트림에 대한 정보를 저장합니다. 이를 위해 KV와 상호 작용하는 배포 서비스가 작성되었습니다. 어느 시점에서 KV의 데이터가 사라졌습니다. 메모리에서 복원했지만 오류가 많이 발생했습니다. 그 결과, 업로드 시 업스트림의 부하가 고르지 않게 분산되었고, 백엔드의 CPU 과부하로 인해 502 오류가 많이 발생했습니다. 결과적으로 우리는 consul KV에서 postgres로 이동했으며 더 이상 제거하기가 쉽지 않습니다.  

결론 :

• 승인되지 않은 서비스에는 사이트 운영에 중요한 데이터가 포함되어서는 안 됩니다. 예를 들어 ES에서 권한이 없으면 필요하지 않은 모든 곳에서 네트워크 수준의 액세스를 거부하고 필요한 것만 남겨두고 action.destructive_requires_name: true도 설정하는 것이 좋습니다.
• 백업 및 복구 메커니즘을 미리 연습해 보세요. 예를 들어 백업과 복원이 가능한 스크립트를 미리(예를 들어 Python으로) 만들어 보세요.

XNUMX위 - '캡틴 언노비어스(Captain Unobvious)' 

어떤 시점에서 우리는 백엔드에 10개 이상의 서버가 있는 경우 nginx 업스트림에서 로드가 고르지 않게 분산되는 것을 발견했습니다. 라운드 로빈이 처음부터 마지막 ​​업스트림까지 순서대로 요청을 보내고 각 nginx 다시 로드가 다시 시작되었기 때문에 첫 번째 업스트림은 항상 나머지 업스트림보다 더 많은 요청을 받았고 결과적으로 작업 속도가 느려지고 사이트 전체가 어려움을 겪었습니다. 이는 트래픽 양이 증가함에 따라 점점 더 눈에 띄게 나타났습니다. 단순히 무작위를 활성화하기 위해 nginx를 업데이트하는 것은 작동하지 않았습니다. (당시) 버전 1에서 시작되지 않았던 여러 Lua 코드를 다시 실행해야 합니다. 우리는 nginx 1.15를 패치하여 무작위 지원을 도입해야 했습니다. 이로써 문제가 해결되었습니다. 이 버그는 "Captain Non-Obviousness" 카테고리에서 우승했습니다.

결론 :

이 버그를 탐색하는 것은 매우 흥미롭고 흥미로웠습니다.) 

• 이러한 변동을 빠르게 찾는 데 도움이 되도록 모니터링을 구성하세요. 예를 들어 ELK를 사용하여 각 업스트림의 각 백엔드에서 rps를 모니터링하고 nginx의 관점에서 응답 시간을 모니터링할 수 있습니다. 이 경우 이는 문제를 식별하는 데 도움이 되었습니다. 

결과적으로, 현재 수행 중인 작업에 대해 좀 더 세심한 접근 방식을 취했다면 대부분의 실패를 피할 수 있었을 것입니다. 우리는 머피의 법칙을 항상 기억해야 합니다. 잘못될 수 있는 일은 무엇이든 잘못될 것입니다. 그리고 이를 기반으로 컴포넌트를 구축합니다. 

출처 : habr.com