VKでClickHouseを使用する、またはKittenHouseを作成した理由

年の初めに、VKデバッグログを以前よりも効率的に保存および読み取る方法を学ぶことにしました。 デバッグログは、たとえば、ビデオ変換ログ（基本的にffmpegコマンドの出力とファイルを前処理するための手順のリスト）であり、問​​題のファイルを処理してから2〜3か月で十分な場合があります。



当時、ログを保存して処理する方法は2つありました。独自のログエンジンとrsyslogで、それらを並行して使用していました。 私たちは他のオプションを検討し始め、YandexのClickHouseが私たちに非常に適していることに気付きました-私たちはそれを実装することにしました。



この記事では、VKontakteでClickHouseをどのように使い始めたのか、私たちが踏み込んだレーキ、およびKittenHouseとLightHouseについて説明します。 両方の製品は、記事の最後にあるオープンソースのリンクに配置されています。

ログ収集タスク

システム要件：

1. 数百テラバイトのログのストレージ。
2. 数ヶ月または（まれに）年間の保管。
3. 書き込み速度が速い。
4. 読み取り速度が速い（読み取りはまれです）。
5. インデックスのサポート
6. 長い行（> 4 Kb）のサポート。
7. 操作のシンプルさ。
8. コンパクトなストレージ。
9. 数万台のサーバーから挿入する機能（UDPはプラスになるでしょう）。

可能な解決策

検討したオプションとその短所を簡単にリストしましょう。

ログエンジン

ログ用の自己記述型マイクロサービス。

-RAMに収まる最後のN行のみを提供できます。

-非常にコンパクトなストレージではありません（透過圧縮なし）。

Hadoop

-すべての形式にインデックスがあるわけではありません。

-読み取り速度が高速になる場合があります（形式によって異なります）。

-設定の複雑さ。

-数万台のサーバーから挿入する可能性はありません（Kafkaまたはアナログが必要です）。

Rsyslog +ファイル

-インデックスなし。

-読み取り速度が遅い（通常のgrep / zgrep）。

-アーキテクチャ上サポートされていない文字列> 4 Kb、UDPはさらに小さい（1.5 Kb）。

±クラウン上で対数回転することでコンパクトなストレージを実現

長期ストレージのフォールバックとしてrsyslogを使用しましたが、長い行は切り捨てられたため、理想とは言い難いです。

LSD +ファイル

-インデックスなし。

-読み取り速度が遅い（通常のgrep / zgrep）。

-数万台のサーバーからの挿入用に特に設計されていません。

±クラウン上で対数回転することにより、コンパクトなストレージが実現します。

今回のケースのrsyslogとの違いは、LSDが長い文字列をサポートしていることですが、何万台ものサーバーから挿入するには内部プロトコルを大幅に変更する必要がありますが、これは可能です。

Elasticsearch

-操作に関する問題。

-不安定な録音。

-UDPなし。

-圧縮不良。

ELKスタックは、すでにログストレージのほとんどの業界標準です。 私たちの経験では、すべてが読み取りの速度で問題ありませんが、たとえばインデックスをマージするときなど、書き込みに問題があります。



ElasticSearchは、主に全文検索および比較的頻繁な読み取り要求用に設計されています。 私たちにとって、正確な偶然の一致により、安定した記録と、データを多かれ少なかれ素早く読み取る能力がより重要です。 ElasticSearchのインデックスは全文検索用にシャープ化されており、ディスク容量は元のコンテンツのgzipと比較して非常に大きくなっています。

クリックハウス

-UDPなし。

概して、ClickHouseで私たちに合わなかった唯一のことは、UDPを介した通信の欠如でした。 実際、上記のオプションのうちrsyslogのみにありましたが、rsyslogは長い行をサポートしていませんでした。



他の基準によると、ClickHouseが私たちのところに来て、私たちはそれを使用することに決め、輸送の問題はその過程で解決されました。

KittenHouseが必要な理由

おそらくご存知のように、VKontakteはPHP / KPHPで動作し、C / C ++の「エンジン」（マイクロサービス）とGoで動作します。 PHPには、おそらく共有メモリとオープン接続を除いて、リクエスト間の「状態」の概念はありません。



ClickHouseにログを送信できるようにするサーバーが数万台あるため、各PHPワーカーからの開いた接続を維持するのは不利です（各サーバーに100人以上のワーカーがいる場合があります）。 したがって、ClickHouseとPHPの間には何らかのプロキシが必要です。 このプロキシをKittenHouseと呼びました。

KittenHouse、v1

まず、私たちのアプローチが機能するかどうかを理解するために、可能な限り単純なスキームを試すことにしました。 この問題を解決するときにカフカが思い浮かぶなら、あなたは一人ではありません。 ただし、追加の中間サーバーを使用したくありませんでした-この場合、ClickHouse自体ではなく、これらのサーバーのパフォーマンスに簡単に依存できます。 さらに、ログを収集したため、データ挿入の予測可能なわずかな遅延が必要でした。 スキームは次のとおりです。







各サーバーにはローカルプロキシ（kittenhouse）がインストールされ、各インスタンスは必要なClickHouseサーバーとのHTTP接続を厳密に1つ保持します。 MergeTreeは貼り付けには推奨されないことが多いため、貼り付けはスプールテーブルで行われます。

KittenHouse、v1の機能

KittenHouseの最初のバージョンはかなり知っていましたが、テストにはこれで十分でした：

• RPC（TLスキーム）を介した通信。
• サーバーごとに1つのTCP / IP接続を維持します。
• デフォルトでは、バッファサイズが制限されたインメモリバッファリング（残りは破棄されます）。
• ディスクに書き込む機能。この場合、配信の保証があります（少なくとも1回）。
• 挿入間隔は2秒に1回です。

最初の問題

最初の問題は、ClickHouseサーバーを数時間「返済」してから再びオンにしたときに発生しました。 以下に、サーバーが「上昇」した後のサーバーの平均負荷を示します。







その理由は非常に単純です。ClickHouseにはスレッドごとのネットワークモデルがあるため、数千のノードから同時にINSERTを実行しようとすると、CPUリソースをめぐる激しい競争があり、サーバーはほとんど応答しませんでした。 ただし、すべてのデータが最終的に挿入され、何も落ちませんでした。



この問題を解決するために、ClickHouseの前にnginxを配置しましたが、一般的には役立ちました。

さらなる開発

操作中に、主にClickHouseではなく、操作方法に関連するいくつかの問題に遭遇しました。 ここに私たちが踏み込んだ別のレーキがあります：

バッファーテーブルの「断片」が多数あると、MergeTreeで頻繁にバッファーがフラッシュされる

この例では、16個のバッファーと2秒ごとに1回のリセット間隔があり、20個のテーブルがあり、1秒あたり最大160個の挿入が行われました。 これは定期的に挿入パフォーマンスに非常に悪い影響を与えました-バックグラウンドマージが多く、ディスク使用率が80％以上に達しました。



解決策：デフォルトのバッファーリセット間隔を増やし、ピースの数を2に減らします。

Nginxは、アップストリームエンドへの接続時に502を返します

これ自体は問題ではありませんが、バッファの頻繁なフラッシュと組み合わせて、SELECTを実行しようとしたときだけでなく、テーブルに挿入しようとしたときに、502エラーというかなり高いバックグラウンドが発生しました。



解決策： fasthttpライブラリを使用してリバースプロキシを作成しました。 このライブラリは、挿入をテーブルにグループ化し、接続を非常に経済的に消費します。 また、SELECTとINSERTを区別し、挿入と読み取り用の個別の接続プールを備えています。

集中的な挿入でメモリ不足

fasthttpライブラリには長所と短所があります。 欠点の1つは、リクエストハンドラに制御を与える前に、リクエストとレスポンスがメモリに完全にバッファされることです。 このため、ClickHouseへの挿入が「時間がなかった」場合、バッファーが増大し始め、最終的にサーバー上のすべてのメモリが不足し、OOMによるリバースプロキシの強制終了につながりました。 同僚はやる気を起こさせた。







解決策： POST要求の本文のストリーミングをサポートするためにfasthttpにパッチを当てることは困難な作業であることが判明したため、要求にHTTPメソッドKITTENが含まれる場合、Hijack（）接続を使用してプロトコルへの接続をアップグレードすることにしました。 サーバーは応答でMEOWを応答する必要があるため、このプロトコルを理解している場合、スキーム全体はKITTEN / MEOWプロトコルと呼ばれます。



TCP / IPのおかげで、一度に50のランダムな接続からしか読み取ることができません。したがって、残りのクライアントは「待機」し、キューがそれぞれのクライアントに到達するまでバッファにメモリを費やしません。 これにより、メモリ消費が少なくとも20倍削減され、このような問題は発生しなくなりました。

長いクエリがある場合、ALTERテーブルは長くなる可能性があります

ClickHouseには、SELECTクエリとINSERTクエリの両方の実行に干渉しないという意味で、非ブロッキングALTERがあります。 ただし、ALTERは、ALTERの実行が完了する前にこのテーブルへのクエリが送信されるまで開始できません。



サーバー上のテーブルへの「長い」クエリの背景がある場合、このテーブルでALTERがデフォルトのタイムアウトである60秒で実行する時間がない場合があります。 しかし、これはALTERがパスしないことを意味するものではありません。SELECTクエリが終了するとすぐに実行されます。



これは、ALTERが実際にどの時点で発生したかわからないこと、およびバッファテーブルが自動的に再作成されてレイアウトが常に同じになることがないことを意味します。 これにより、挿入の問題が発生する可能性があります。











解決策：結果として、バッファーテーブルの使用を完全に放棄する予定です。 一般に、バッファテーブルにはスコープがあります。これまでのところ、バッファテーブルを使用しており、大きな問題は発生していません。 しかし、ようやく、リバースプロキシ側でバッファテーブルの機能を実装する方が、それらの欠点を我慢し続けるよりも簡単になりました。 回路例は次のようになります（破線はINSERTのACK非同期を示しています）。

データの読み取り

挿入を理解したとしましょう。 ClickHouseからこれらのログを読み取る方法 残念ながら、ClickHouseから生データを（グラフやその他のプロットなしで）読み取るための便利で使いやすいツールが見つからなかったため、独自のソリューションであるLightHouseを作成しました。 その機能はかなり控えめです。

• テーブルの内容のクイックビュー。
• フィルタリング、ソート。
• SQLクエリの編集。
• テーブル構造を表示します。
• およその行数と使用されているディスク容量を示します。

ただし、LightHouseは高速であり、必要なことを実行できます。 以下にスクリーンショットをいくつか示します。



テーブル構造を見る







コンテンツフィルタリング

結果

ClickHouseは、事実上、VKontakteに根ざした唯一のオープンソースデータベースです。 私たちはその作業の速度に満足しており、以下で説明する欠点に対応する準備ができています。

仕事の難しさ

全体として、ClickHouseは非常に安定したデータベースであり、非常に高速です。 ただし、他の製品と同様に、特に若くて、検討する必要がある機能には次のような機能があります。

• すべてのバージョンが同じように安定しているわけではありません。本番環境で新しいバージョンに直接アップグレードしないでください。いくつかのバグ修正リリースを待つことをお勧めします。
• 最適なパフォーマンスを得るには、指示に従ってRAIDなどを設定することを強くお勧めします。 これは最近highloadで報告されました 。
• レプリケーションには速度制限が組み込まれていないため、自分で制限しないとサーバーのパフォーマンスが大幅に低下する可能性があります（ただし、修正すると約束されています）。
• Linuxには、仮想メモリメカニズムの不快な機能があります。ディスクにアクティブに書き込み、データをフラッシュする時間がない場合、ある時点でサーバーが完全に「自分自身に入り」、ページキャッシュをディスクにアクティブにフラッシュし始め、ClickHouseプロセスをほぼ完全にブロックします。 これは大規模なマージで発生する場合があり、これを監視する必要があります。たとえば、定期的に自分でバッファをフラッシュしたり、同期したりします。

オープンソース

KittenHouseとLightHouseがgithubリポジトリのオープンソースで利用可能になりました：

• KittenHouse： github.com/vkcom/kittenhouse
• LightHouse： github.com/vkcom/lighthouse

よろしくお願いします！



VKontakteのバックエンドインフラストラクチャ部門の開発者、Yuri Nasretdinov