CIAN이 테라바이트 규모의 로그를 길들인 방법

안녕하세요 여러분, 제 이름은 Alexander입니다. 저는 CIAN에서 엔지니어로 일하고 있으며 시스템 관리 및 인프라 프로세스 자동화에 참여하고 있습니다. 이전 기사 중 하나에 대한 댓글에서 우리는 하루에 4TB의 로그를 어디서 얻을 수 있는지, 그리고 그 로그로 무엇을 하는지 알려 달라는 요청을 받았습니다. 네, 저희는 로그가 많고 이를 처리하기 위한 별도의 인프라 클러스터가 생성되어 있어 문제를 빠르게 해결할 수 있습니다. 이 기사에서는 계속해서 증가하는 데이터 흐름을 처리하기 위해 XNUMX년 동안 이를 어떻게 조정했는지에 대해 설명하겠습니다.

우리는 어디서 시작했나요?

지난 몇 년 동안 cian.ru의 로드는 매우 빠르게 증가했으며 2018년 11.2분기에는 리소스 트래픽이 월간 고유 사용자 수 40만 명에 달했습니다. 당시 중요한 순간에는 최대 XNUMX%에 달하는 로그가 손실되었기 때문에 신속하게 사건에 대처하지 못하고 문제를 해결하는 데 많은 시간과 노력을 쏟았습니다. 또한 문제의 원인을 찾지 못하는 경우가 많아 시간이 지나면 다시 발생하는 경우가 많습니다. 그곳은 지옥이었고 이에 대해 뭔가 조치를 취해야 했습니다.

당시 우리는 로그를 저장하기 위해 표준 인덱스 설정을 갖춘 ElasticSearch 버전 10가 포함된 5.5.2개의 데이터 노드로 구성된 클러스터를 사용했습니다. 인기 있고 저렴한 솔루션으로 XNUMX년여 전에 도입되었습니다. 당시에는 로그 흐름이 그다지 크지 않았기 때문에 비표준 구성을 생각해 낼 필요가 없었습니다. 

수신 로그 처리는 100개의 ElasticSearch 코디네이터의 서로 다른 포트에서 Logstash에 의해 제공되었습니다. 크기에 관계없이 하나의 인덱스는 XNUMX개의 샤드로 구성되었습니다. 시간별 및 일별 순환이 구성되었으며 그 결과 매시간 약 XNUMX개의 새로운 샤드가 클러스터에 나타났습니다. 로그가 많지는 않았지만 클러스터는 잘 대처했고 설정에 신경쓰는 사람도 없었습니다. 

급속한 성장의 과제

두 프로세스가 서로 겹치면서 생성된 로그의 양이 매우 빠르게 증가했습니다. 한편, 서비스 사용자 수가 증가했습니다. 반면에 우리는 마이크로서비스 아키텍처로 적극적으로 전환하기 시작하여 C#과 Python의 기존 모놀리스를 정리했습니다. 모놀리스의 일부를 대체한 수십 개의 새로운 마이크로서비스는 인프라 클러스터에 대해 훨씬 더 많은 로그를 생성했습니다. 

클러스터를 실질적으로 관리할 수 없게 된 지점까지 우리를 이끈 것은 확장이었습니다. 로그가 초당 20만 개의 메시지 속도로 도착하기 시작했을 때 쓸데없는 잦은 순환으로 인해 샤드 수가 6천 개로 늘어났고 노드당 샤드가 600개가 넘었습니다. 

이로 인해 RAM 할당에 문제가 발생했고, 노드가 충돌하면 모든 샤드가 동시에 이동하기 시작하여 트래픽이 증가하고 다른 노드에 로드가 발생하여 클러스터에 데이터를 쓰는 것이 거의 불가능해졌습니다. 그리고 이 기간 동안 우리는 로그 없이 남겨졌습니다. 그리고 서버에 문제가 생기면 기본적으로 클러스터의 1/10이 손실됩니다. 다수의 작은 인덱스로 인해 복잡성이 추가되었습니다.

로그가 없으면 우리는 사건의 원인을 이해하지 못했고 조만간 같은 갈퀴를 다시 밟을 수 있었습니다. 우리 팀의 이데올로기에서는 이것은 용납할 수 없었습니다. 왜냐하면 우리의 모든 작업 메커니즘은 정반대의 작업을 수행하도록 설계되었기 때문입니다. 절대 반복하지 마십시오. 같은 문제. 이를 위해서는 근무 엔지니어 팀이 메트릭뿐만 아니라 로그의 경고도 모니터링했기 때문에 전체 로그 볼륨과 거의 실시간 전달이 필요했습니다. 문제의 규모를 이해하자면 당시 하루 총 로그 용량은 약 2TB였습니다. 

우리는 불가항력 발생 시 로그 손실을 완전히 제거하고 ELK 클러스터로 전달되는 시간을 최대 15분으로 줄이는 목표를 설정했습니다(나중에 이 수치를 내부 KPI로 사용함).

새로운 회전 메커니즘 및 hot-warm 노드

ElasticSearch 버전을 5.5.2에서 6.4.3으로 업데이트하여 클러스터 변환을 시작했습니다. 다시 한 번 버전 5 클러스터가 종료되었으며 이를 끄고 완전히 업데이트하기로 결정했습니다. 아직 로그가 없습니다. 그래서 우리는 단 몇 시간 만에 이러한 전환을 완료했습니다.

이 단계에서 가장 큰 규모의 변화는 코디네이터를 중간 버퍼로 사용하여 2개 노드에 Apache Kafka를 구현한 것입니다. 메시지 브로커는 ElasticSearch 문제로 인해 로그가 손실되는 것을 방지했습니다. 동시에 우리는 클러스터에 24개의 노드를 추가하고 데이터 센터의 서로 다른 랙에 XNUMX개의 "핫" 노드가 있는 hot-warm 아키텍처로 전환했습니다. 어떤 상황에서도 손실되어서는 안 되는 마스크(nginx 및 애플리케이션 오류 로그)를 사용하여 로그를 리디렉션했습니다. 디버그, 경고 등의 사소한 로그가 나머지 노드로 전송되었으며, XNUMX시간 후에는 "핫" 노드의 "중요" 로그가 전송되었습니다.

작은 인덱스의 수를 늘리지 않기 위해 시간 회전에서 롤오버 메커니즘으로 전환했습니다. 인덱스 크기에 따른 회전은 매우 신뢰할 수 없다는 정보가 포럼에 많이 있었기 때문에 우리는 인덱스의 문서 수에 따른 회전을 사용하기로 결정했습니다. 우리는 각 인덱스를 분석하고 이후 회전이 작동해야 하는 문서 수를 기록했습니다. 따라서 우리는 50GB 이하의 최적의 샤드 크기에 도달했습니다. 

클러스터 최적화

그러나 우리는 문제를 완전히 제거하지 못했습니다. 불행하게도 작은 인덱스는 여전히 나타났습니다. 지정된 볼륨에 도달하지 못했고, 회전되지 않았으며, 날짜별 회전을 제거했기 때문에 600일보다 오래된 인덱스의 전역 정리에 의해 삭제되었습니다. 이로 인해 클러스터의 인덱스가 완전히 사라져서 데이터 손실이 발생했고, 존재하지 않는 인덱스에 쓰려는 시도로 인해 관리에 사용했던 큐레이터의 논리가 깨졌습니다. 쓰기용 별칭이 인덱스로 변환되어 롤오버 논리가 깨져 일부 인덱스가 최대 XNUMXGB까지 통제할 수 없이 증가했습니다. 

예를 들어 순환 구성의 경우:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

롤오버 별칭이 없으면 오류가 발생했습니다.

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

우리는 다음 반복을 위해 이 문제에 대한 솔루션을 남겨두고 또 다른 문제를 다루었습니다. 즉, 들어오는 로그를 처리하는(불필요한 정보 제거 및 강화) Logstash의 풀 로직으로 전환했습니다. 우리는 이를 docker-compose를 통해 실행하는 docker에 배치했고, 로그 스트림의 운영 모니터링을 위해 Prometheus에 측정항목을 보내는 Logstash-exporter도 여기에 배치했습니다. 이러한 방식으로 우리는 각 로그 유형을 처리하는 Logstash 인스턴스 수를 원활하게 변경할 수 있는 기회를 얻었습니다.

클러스터를 개선하는 동안 cian.ru의 트래픽은 월별 고유 사용자 수 12,8만 명으로 증가했습니다. 결과적으로 우리의 변환이 생산 변화보다 약간 뒤처진 것으로 밝혀졌으며 "웜" 노드가 로드에 대처할 수 없고 전체 로그 전달 속도가 느려진다는 사실에 직면했습니다. “핫” 데이터를 실패 없이 수신했지만, 인덱스를 균등하게 분배하기 위해 나머지 전달에 개입하고 수동 롤오버를 수행해야 했습니다. 

동시에 클러스터의 로그스태시 인스턴스 설정을 확장하고 변경하는 것은 로컬 docker-compose이고 모든 작업이 수동으로 수행되었다는 사실로 인해 복잡했습니다(새 끝을 추가하려면 모든 작업을 수동으로 수행해야 했습니다). 모든 곳에서 docker-compose up -d를 수행합니다).

로그 재배포

올해 30월에도 우리는 여전히 모놀리스를 절단하고 있었고 클러스터의 로드는 증가했으며 로그 흐름은 초당 XNUMX만 메시지에 가까워졌습니다. 

우리는 하드웨어 업데이트로 다음 반복을 시작했습니다. 우리는 코디네이터를 5명에서 3명으로 전환하고 데이터 노드를 교체하여 비용과 저장 공간 측면에서 승리했습니다. 노드의 경우 두 가지 구성을 사용합니다. 

• "핫" 노드의 경우: E3-1270 v6 / 960Gb SSD / 32Gb x 3 x 2(Hot3의 경우 1개, Hot3의 경우 2개).
• "웜" 노드의 경우: E3-1230 v6 / 4Tb SSD / 32Gb x 4.

이번 반복에서 우리는 일선 nginx 로그와 동일한 공간을 차지하는 마이크로서비스의 액세스 로그가 포함된 인덱스를 20개의 "핫" 노드로 구성된 두 번째 그룹으로 이동했습니다. 이제 데이터를 "핫" 노드에 XNUMX시간 동안 저장한 다음 이를 "웜" 노드의 나머지 로그로 전송합니다. 

회전을 재구성하여 작은 인덱스가 사라지는 문제를 해결했습니다. 이제 인덱스는 데이터가 거의 없더라도 어떤 경우에도 23시간마다 순환됩니다. 이로 인해 샤드 수가 약간 증가했지만(약 800개) 클러스터 성능 측면에서는 허용할 수 있습니다. 

결과적으로 클러스터에는 6개의 "핫" 노드와 4개의 "웜" 노드만 있었습니다. 이로 인해 오랜 시간 동안 요청이 약간 지연되지만 향후 노드 수를 늘리면 이 문제가 해결됩니다.

이 반복에서는 반자동 스케일링 부족 문제도 해결되었습니다. 이를 위해 우리는 프로덕션 환경에 이미 배포한 것과 유사한 인프라 Nomad 클러스터를 배포했습니다. 현재로서는 Logstash의 양이 부하에 따라 자동으로 변경되지는 않지만 이에 대해 설명하겠습니다.

앞으로의 계획

구현된 구성은 완벽하게 확장되며 이제 13,3TB의 데이터를 저장합니다. 모든 로그는 4일 동안 저장되며 이는 경보의 긴급 분석에 필요합니다. 일부 로그를 지표로 변환하여 Graphite에 추가합니다. 엔지니어의 작업을 더 쉽게 만들기 위해 인프라 클러스터에 대한 메트릭과 일반적인 문제의 반자동 복구를 위한 스크립트가 있습니다. 내년 예정인 데이터 노드 수를 늘린 뒤 데이터 저장 기간을 4일에서 7일로 전환할 예정이다. 우리는 항상 가능한 한 빨리 사건을 조사하려고 노력하고 장기 조사를 위한 원격 측정 데이터가 있으므로 운영 작업에는 이것으로 충분합니다. 

2019년 15,3월 cian.ru의 트래픽은 이미 월별 고유 사용자 수 XNUMX만 명으로 증가했습니다. 이는 로그 전달을 위한 아키텍처 솔루션에 대한 심각한 테스트가 되었습니다. 

이제 우리는 ElasticSearch를 버전 7로 업데이트할 준비를 하고 있습니다. 그러나 이를 위해서는 버전 5.5에서 이동하고 버전 6에서 더 이상 사용되지 않는 것으로 선언되었기 때문에 ElasticSearch의 많은 인덱스 매핑을 업데이트해야 합니다(단순히 버전에는 존재하지 않습니다). 7). 즉, 업데이트 프로세스 중에 일종의 불가항력이 발생하여 문제가 해결되는 동안 로그가 남지 않게 됩니다. 버전 7 중에서 우리는 향상된 인터페이스와 새로운 필터를 갖춘 Kibana를 가장 기대하고 있습니다. 

우리는 주요 목표를 달성했습니다. 로그 손실을 멈추고 인프라 클러스터의 가동 중지 시간을 주당 2~3회 충돌에서 월 XNUMX시간의 유지 관리 작업으로 줄였습니다. 이 모든 생산 작업은 거의 눈에 띄지 않습니다. 그러나 이제 우리는 서비스에 무슨 일이 일어나고 있는지 정확하게 판단할 수 있으므로 자동 모드에서 신속하게 이를 수행할 수 있으며 로그가 손실될 것을 걱정할 필요가 없습니다. 일반적으로 우리는 만족하고 행복하며 나중에 이야기할 새로운 공격을 준비하고 있습니다.

출처 : habr.com