요약: XNUMX년 전 저는 새로운 서버 모니터링 도구에 대한 아이디어를 가지고 Google을 떠났습니다. 일반적으로 분리된 기능을 하나의 서비스로 결합하려는 아이디어였습니다. 수집 로그 분석, 지표 수집, 경고 그리고 대시보드. 원칙 중 하나는 서비스가 진정으로 이루어져야 한다는 것입니다. 빠른, 쉽고 대화형이며 즐거운 경험을 DevOps에 제공합니다. 이를 위해서는 예산 범위 내에서 수 기가바이트 규모의 데이터 세트를 몇 분의 XNUMX초 만에 처리해야 합니다. 기존 로그 관리 도구는 느리고 투박한 경우가 많았기 때문에 사용자에게 새로운 경험을 제공할 수 있는 도구를 현명하게 설계해야 한다는 좋은 과제에 직면했습니다.

이 기사에서는 Scalyr에서 구식 방법, 무차별 접근 방식을 적용하고 불필요한 레이어를 제거하고 복잡한 데이터 구조를 피하여 이 문제를 해결한 방법을 설명합니다. 이러한 교훈을 자신의 엔지니어링 문제에 적용할 수 있습니다.

올드 스쿨 파워

로그 분석은 일반적으로 검색으로 시작됩니다. 즉, 특정 패턴과 일치하는 모든 메시지를 찾습니다. Scalyr에서 이는 여러 서버의 수십 또는 수백 기가바이트의 로그입니다. 일반적으로 현대적인 접근 방식에는 검색에 최적화된 복잡한 데이터 구조를 구성하는 것이 포함됩니다. 나는 확실히 이것을 Google에서 보았습니다. 그들은 이런 종류의 일에 꽤 능숙합니다. 그러나 우리는 로그를 선형으로 스캔하는 훨씬 더 조잡한 접근 방식을 선택했습니다. 그리고 그것은 효과가 있었습니다. 우리는 경쟁사보다 훨씬 더 빠른 검색 가능한 인터페이스를 제공합니다(마지막 애니메이션 참조).

핵심 통찰력은 현대 프로세서가 간단하고 간단한 작업에서 실제로 매우 빠르다는 것입니다. 이는 I/O 속도와 네트워크 작업에 의존하는 복잡한 다층 시스템에서는 놓치기 쉽고 이러한 시스템은 오늘날 매우 일반적입니다. 그래서 우리는 층과 과도한 잔해를 최소화하는 디자인을 개발했습니다. 여러 프로세서와 서버를 병렬로 사용하면 검색 속도가 초당 1TB에 이릅니다.

이 기사의 주요 내용:

• 무차별 검색은 실제 대규모 문제를 해결하기 위한 실행 가능한 접근 방식입니다.
• 무차별 대입은 작업이 필요 없는 솔루션이 아닌 설계 기술입니다. 다른 기술과 마찬가지로 일부 문제에는 다른 기술보다 더 적합하며 잘못 구현되거나 잘 구현될 수 있습니다.
• 무차별 대입은 특히 목표 달성에 좋습니다. 안정된 생산력.
• 무차별 공격을 효과적으로 사용하려면 코드를 최적화하고 적시에 충분한 리소스를 적용해야 합니다. 서버에 사용자 이외의 로드가 많고 사용자 작업이 우선 순위로 유지되는 경우에 적합합니다.
• 성능은 내부 루프 알고리즘뿐만 아니라 전체 시스템의 설계에 따라 달라집니다.

(이 문서에서는 메모리의 데이터 검색에 대해 설명합니다. 대부분의 경우 사용자가 로그 검색을 수행하면 Scalyr 서버는 이미 이를 캐시했습니다. 다음 문서에서는 캐시되지 않은 로그 검색에 대해 설명합니다. 동일한 원칙이 적용됩니다: 효율적인 코드, 무차별 대입 큰 계산 자원을 가지고 있음).

무차별 대입 방식

전통적으로 대규모 데이터 세트는 키워드 인덱스를 사용하여 검색됩니다. 서버 로그에 적용하면 이는 로그에서 모든 고유 단어를 검색하는 것을 의미합니다. 각 단어에 대해 모든 포함 목록을 작성해야 합니다. 이렇게 하면 'error', 'firefox' 또는 'transaction_16851951'과 같이 이 단어가 포함된 모든 메시지를 쉽게 찾을 수 있습니다. 색인을 살펴보세요.

저는 Google에서 이 접근 방식을 사용했는데 잘 작동했습니다. 그러나 Scalyr에서는 로그를 바이트 단위로 검색합니다.

왜? 추상적인 알고리즘 관점에서 보면 키워드 인덱스는 무차별 검색보다 훨씬 더 효율적입니다. 그러나 우리는 알고리즘을 판매하는 것이 아니라 성능을 판매합니다. 그리고 성능은 알고리즘뿐만 아니라 시스템 엔지니어링에 관한 것이기도 합니다. 우리는 데이터의 양, 검색 유형, 사용 가능한 하드웨어 및 소프트웨어 컨텍스트 등 모든 것을 고려해야 합니다. 우리는 특정 문제에 대해 'grep'과 같은 것이 인덱스보다 더 적합하다고 결정했습니다.

인덱스는 훌륭하지만 한계가 있습니다. 한 단어는 쉽게 찾을 수 있습니다. 하지만 'googlebot', '404' 등 여러 단어로 구성된 메시지를 검색하는 것은 훨씬 더 어렵습니다. '잡히지 않은 예외'와 같은 문구를 검색하려면 해당 단어가 포함된 모든 메시지뿐만 아니라 해당 단어의 특정 위치도 기록하는 더 성가신 색인이 필요합니다.

진짜 어려움은 단어를 찾지 않을 때 발생합니다. 봇에서 발생하는 트래픽의 양을 확인하고 싶다고 가정해 보겠습니다. 첫 번째 생각은 로그에서 '봇'이라는 단어를 검색하는 것입니다. Googlebot, Bingbot 등 다양한 봇을 찾는 방법은 다음과 같습니다. 하지만 여기서 '봇'은 단어가 아니라 단어의 일부입니다. 색인에서 'bot'을 검색하면 'Googlebot'이라는 단어가 포함된 게시물을 찾을 수 없습니다. 색인의 모든 단어를 확인한 다음 색인에서 찾은 키워드를 검색하면 검색 속도가 크게 느려집니다. 결과적으로 일부 로그 프로그램은 부분 단어 검색을 허용하지 않거나 (기껏해야) 성능이 낮은 특수 구문을 허용합니다. 우리는 이것을 피하고 싶습니다.

또 다른 문제는 구두점입니다. 다음의 모든 요청을 찾으시겠습니까? 50.168.29.7? 다음을 포함하는 디버깅 로그는 어떻습니까? [error]? 아래 첨자는 일반적으로 구두점을 건너뜁니다.

마지막으로 엔지니어는 강력한 도구를 좋아하며 때로는 정규식을 통해서만 문제를 해결할 수 있습니다. 키워드 인덱스는 이에 적합하지 않습니다.

게다가 지수는 복잡한. 각 메시지는 여러 키워드 목록에 추가되어야 합니다. 이러한 목록은 항상 쉽게 검색할 수 있는 형식으로 보관되어야 합니다. 구문, 단어 조각 또는 정규 표현식이 포함된 쿼리는 다중 목록 작업으로 변환되어야 하며, 결과를 스캔하고 결합하여 결과 세트를 생성해야 합니다. 대규모 다중 테넌트 서비스의 맥락에서 이러한 복잡성으로 인해 알고리즘을 분석할 때 눈에 띄지 않는 성능 문제가 발생합니다.

키워드 인덱스도 많은 공간을 차지하며, 로그 관리 시스템에서 스토리지는 주요 비용이다.

반면에 각 검색은 많은 컴퓨팅 성능을 소비할 수 있습니다. 우리 사용자는 고유한 검색어에 대한 고속 검색을 높이 평가하지만 이러한 검색어는 상대적으로 드물게 발생합니다. 예를 들어 대시보드와 같은 일반적인 검색 쿼리의 경우 특별한 기술을 사용합니다(다음 문서에서 이에 대해 설명합니다). 다른 요청은 한 번에 두 개 이상을 처리할 필요가 없을 만큼 자주 발생하지 않습니다. 하지만 이것이 우리 서버가 바쁘지 않다는 의미는 아닙니다. 서버는 새 메시지 수신, 분석 및 압축, 경고 평가, 이전 데이터 압축 등의 작업으로 바쁘습니다. 따라서 우리는 쿼리를 실행하는 데 사용할 수 있는 프로세서를 상당히 많이 공급하고 있습니다.

무차별적인 문제가 있는 경우(그리고 많은 강제력) 무차별 대입이 작동합니다.

무차별 대입은 내부 루프가 작은 간단한 문제에 가장 적합합니다. 매우 빠른 속도로 실행되도록 내부 루프를 최적화할 수 있는 경우가 많습니다. 코드가 복잡하면 최적화하기가 훨씬 더 어렵습니다.

우리의 검색 코드에는 원래 상당히 큰 내부 루프가 있었습니다. 우리는 페이지에 메시지를 4K로 저장합니다. 각 페이지에는 일부 메시지(UTF-8 형식)와 각 메시지에 대한 메타데이터가 포함되어 있습니다. 메타데이터는 값의 길이, 내부 메시지 ID 및 기타 필드를 인코딩하는 구조입니다. 검색 주기는 다음과 같습니다.

이는 실제 코드를 단순화한 버전입니다. 그러나 여기에서도 여러 개체 배치, 데이터 복사본 및 함수 호출이 표시됩니다. JVM은 함수 호출을 최적화하고 임시 개체를 할당하는 데 매우 능숙하므로 이 코드는 우리가 기대했던 것보다 더 잘 작동했습니다. 테스트하는 동안 고객은 이를 매우 성공적으로 사용했습니다. 그러나 결국 우리는 그것을 다음 단계로 발전시켰습니다.

(로그를 직접 작업하는 대신 4K 페이지, 텍스트 및 메타데이터가 포함된 이 형식으로 메시지를 저장하는 이유가 무엇인지 물을 수 있습니다. 여러 가지 이유가 있는데, 이는 내부적으로 Scalyr 엔진이 데이터베이스라기보다는 분산 데이터베이스에 더 가깝다는 사실로 요약됩니다. 텍스트 검색은 로그 파싱 후 여백에 DBMS 스타일 필터와 결합되는 경우가 많습니다. 수천 개의 로그를 동시에 검색할 수 있지만 단순 텍스트 파일은 트랜잭션, 복제, 분산 데이터 관리에 적합하지 않습니다.

처음에는 이러한 코드가 무차별 대입 최적화에 적합하지 않은 것처럼 보였습니다. "실제 작업" String.indexOf() CPU 프로필을 지배하지도 않았습니다. 즉, 이 방법을 최적화하는 것만으로는 큰 효과를 얻을 수 없습니다.

각 페이지의 시작 부분에 메타데이터를 저장하고 UTF-8로 된 모든 메시지의 텍스트는 반대쪽 끝에 압축됩니다. 이를 활용하여 전체 페이지를 한 번에 검색하도록 루프를 다시 작성했습니다.

이 버전은 뷰에서 직접 작동합니다. raw byte[] 전체 4K 페이지에서 모든 메시지를 한 번에 검색합니다.

이는 무차별 대입 방식으로 최적화하는 것이 훨씬 쉽습니다. 내부 검색 루프는 각 게시물에서 별도로 호출되는 것이 아니라 전체 4K 페이지에 대해 동시에 호출됩니다. 데이터 복사나 개체 할당이 없습니다. 더 복잡한 메타데이터 작업은 결과가 긍정적인 경우에만 호출되며 모든 메시지에 대해 호출되는 것은 아닙니다. 이러한 방식으로 우리는 엄청난 양의 오버헤드를 제거했으며 나머지 로드는 추가 최적화에 매우 적합한 작은 내부 검색 루프에 집중되었습니다.

실제 검색 알고리즘은 다음을 기반으로 합니다. Leonid Volnitsky의 좋은 아이디어. 이는 각 단계에서 대략 검색 문자열 길이를 건너뛰는 Boyer-Moore 알고리즘과 유사합니다. 주요 차이점은 잘못된 일치를 최소화하기 위해 한 번에 XNUMX바이트를 확인한다는 것입니다.

우리의 구현에서는 각 검색에 대해 64K 조회 테이블을 생성해야 하지만 이는 우리가 검색하는 기가바이트급 데이터에 비하면 아무것도 아닙니다. 내부 루프는 단일 코어에서 초당 수 기가바이트를 처리합니다. 실제로 안정적인 성능은 각 코어에서 초당 약 1,25GB이며 개선의 여지가 있습니다. 내부 루프 외부의 오버헤드를 일부 제거하는 것이 가능하며, Java 대신 C에서 내부 루프를 실험해 볼 계획입니다.

우리는 무력을 사용한다

우리는 로그 검색이 "대략" 구현될 수 있다고 논의했지만, 우리는 얼마나 많은 "능력"을 가지고 있습니까? 꽤 많이.

1월: 올바르게 사용하면 최신 프로세서의 단일 코어는 그 자체로 매우 강력합니다.

8코어: 우리는 현재 각각 1.4코어(2.4스레드)를 갖춘 Amazon hi8xlarge 및 i16xlarge SSD 서버에서 실행되고 있습니다. 위에서 언급했듯이 이러한 코어는 일반적으로 백그라운드 작업으로 바쁩니다. 사용자가 검색을 수행하면 백그라운드 작업이 일시 중단되어 8개 코어가 모두 검색용으로 확보됩니다. 검색은 일반적으로 XNUMX초 안에 완료되고 그 후 백그라운드 작업이 다시 시작됩니다(조절 프로그램은 검색 쿼리의 공격이 중요한 백그라운드 작업을 방해하지 않도록 보장합니다).

16코어: 신뢰성을 위해 서버를 마스터/슬레이브 그룹으로 구성합니다. 각 마스터는 자신의 명령에 따라 하나의 SSD와 하나의 EBS 서버를 갖습니다. 메인 서버가 충돌하면 SSD 서버가 즉시 그 자리를 대신합니다. 거의 항상 마스터와 슬레이브는 잘 작동하므로 각 데이터 블록은 두 개의 서로 다른 서버에서 검색 가능합니다(EBS 슬레이브 서버는 프로세서가 약하므로 고려하지 않습니다). 우리는 이들 사이에 작업을 나누어서 총 16개의 코어를 사용할 수 있게 되었습니다.

많은 코어: 가까운 미래에 우리는 모든 중요 요청을 처리하는 데 서버가 모두 참여하는 방식으로 서버 전체에 데이터를 배포할 것입니다. 모든 코어가 작동합니다. [메모: 우리는 계획을 구현하고 검색 속도를 1TB/s로 높였습니다. 기사 마지막에 있는 참고 사항을 참조하세요.].

단순함이 신뢰성을 보장합니다

무차별 방식의 또 다른 장점은 상당히 일관된 성능입니다. 일반적으로 검색은 문제 및 데이터 세트의 세부 사항에 그다지 민감하지 않습니다(그래서 "대략"이라고 부르는 것 같습니다).

키워드 색인은 때로는 믿을 수 없을 정도로 빠른 결과를 생성하지만 다른 경우에는 그렇지 않습니다. 'customer_50'라는 용어가 정확히 5987235982번 나타나는 XNUMXGB의 로그가 있다고 가정해 보겠습니다. 이 용어에 대한 검색은 색인에서 직접 세 위치를 계산하며 즉시 완료됩니다. 그러나 복잡한 와일드카드 검색은 수천 개의 키워드를 검색하고 시간이 오래 걸릴 수 있습니다.

반면, 무차별 대입 검색은 모든 쿼리에 대해 거의 동일한 속도로 수행됩니다. 긴 단어를 검색하는 것이 더 좋지만 단일 문자를 검색하는 것조차 상당히 빠릅니다.

무차별 대입 방법의 단순성은 성능이 이론적 최대치에 가깝다는 것을 의미합니다. 예상치 못한 디스크 과부하, 잠금 경합, 포인터 추적 및 기타 수천 가지 실패 이유에 대한 옵션이 더 적습니다. 지난 주 가장 바쁜 서버에서 Scalyr 사용자가 요청한 내용을 살펴보았습니다. 요청은 14건이었습니다. 그 중 정확히 000개가 99초 이상 걸렸습니다. 111밀리초 이내에 XNUMX% 완료(로그 분석 도구를 사용해 본 적이 없다면 저를 믿으세요: 빠르다).

서비스 이용의 편의성을 위해서는 안정적이고 신뢰할 수 있는 성능이 중요합니다. 주기적으로 지연이 발생하면 사용자는 신뢰할 수 없다고 인식하고 사용을 꺼리게 됩니다.

로그 검색 실행 중

다음은 Scalyr 검색이 실제로 수행되는 모습을 보여주는 짧은 애니메이션입니다. 우리는 모든 공개 Github 저장소의 모든 이벤트를 가져오는 데모 계정을 가지고 있습니다. 이 데모에서는 약 600MB의 원시 로그에 해당하는 일주일 분량의 데이터를 검사합니다.

영상은 특별한 준비 없이 제 데스크탑(서버에서 약 5000km 떨어진 곳)에서 실시간으로 녹화되었습니다. 여러분이 보게 될 성능은 주로 다음 사항에 기인합니다. 웹 클라이언트 최적화, 빠르고 안정적인 백엔드도 제공합니다. '로드 중' 표시 없이 일시 정지가 있을 때마다 제가 누르려는 내용을 읽을 수 있도록 일시 정지하는 것입니다.

결론적으로

대용량 데이터를 처리할 때는 좋은 알고리즘을 선택하는 것이 중요하지만, '좋다'고 '멋지다'는 뜻은 아니다. 코드가 실제로 어떻게 작동할지 생각해 보세요. 알고리즘의 이론적 분석에서는 현실 세계에서 매우 중요할 수 있는 몇 가지 요소를 제외합니다. 알고리즘이 단순할수록 최적화하기가 더 쉽고 엣지 상황에서 더 안정적입니다.

또한 코드가 실행될 컨텍스트에 대해서도 생각해 보세요. 우리의 경우 백그라운드 작업을 관리하려면 충분히 강력한 서버가 필요합니다. 사용자는 상대적으로 검색을 자주 시작하지 않으므로 각 검색을 완료하는 데 필요한 짧은 기간 동안 전체 서버 그룹을 빌릴 수 있습니다.

무차별 방식을 사용하여 일련의 로그에 대해 빠르고 안정적이며 유연한 검색을 구현했습니다. 이러한 아이디어가 귀하의 프로젝트에 유용하길 바랍니다.

편집하다: 지난 몇 년간의 성능 향상을 반영하기 위해 제목과 텍스트가 "초당 20GB로 검색"에서 "초당 1TB로 검색"으로 변경되었습니다. 이러한 속도 증가는 주로 증가된 고객 기반에 서비스를 제공하기 위해 오늘 설치하고 있는 EC2 서버의 유형과 수의 변경으로 인한 것입니다. 운영 효율성을 또 한 번 획기적으로 높일 수 있는 변화가 곧 있을 예정이며, 우리는 이를 빨리 공유하고 싶습니다.

출처 : habr.com