Ctrip の大量コールドデータ シナリオにおける JuiceFS の実践

著者: Miao Cheng は、Ctrip のクラウド ネイティブ R&D エンジニアであり、分散データベースと NoSQL に重点を置いて、Elasticsearch と JuiceFS の研究開発と運用に主に携わっています。 Ctrip のクラウド ネイティブ R&D エンジニアである Xiaofeng は、主にデータベース コンテナ化の分野に焦点を当てており、分散ストレージに強い関心を持っています。

1. 要約

Ctrip のコールドデータ規模は、バックアップデータ、画像および音声トレーニングデータ、ログデータを含めて 10PB を超えます。ストレージ ソリューションは主にローカル ディスクと GlusterFS です。実際の使用において、これらのソリューションは多くの問題点に遭遇しました。

• GlusterFS の 1 つのディレクトリに多数のファイルがある場合、ls コマンドは非常に遅くなります。
• 流行中の機械調達サイクルの制約により、実際のニーズに応じて容量を柔軟に拡大または縮小することは不可能であり、保管コストを管理することは困難です。
• ディスクの損傷やその他の障害によるマシンの交換や容量の拡張および縮小操作により、運用および保守コストが高くなります。

クラウド コンピューティング テクノロジーの発展に伴い、パブリック クラウド ベンダーはハイブリッド クラウドの顧客に、大量のコールド データ用の安価なストレージ ソリューションを提供してきました。厳密なコスト計算の結果、パブリック クラウド オブジェクト ストレージを使用すると、ストレージと運用および保守のコストを大幅に削減できることがわかりました。移行コストを削減するために、さまざまなパブリッククラウドオブジェクトストレージと高性能ファイルシステムをサポートできるバックエンドストレージを探していましたが、JuiceFS が私たちの視野に現れました。 JuiceFS には次の利点があります。

• アプリケーションに影響を与えないPOSIXインターフェース
• 強力な一貫性、ファイルの変更が即座に表示され、同じボリュームが複数のマシンにマウントされているシナリオでは、クローズからオープンまでの保証が提供されます。
• 主流のパブリック クラウド オブジェクト ストレージと、メタデータ エンジン (Redis、TiKV) などのオープン ソース ソフトウェアをサポートします。
• クラウドネイティブをサポートし、CSIモードでポッドにボリュームをマウントできます
• 活発なコミュニティ、迅速なコード更新

半年以上にわたるテストと使用を経て、データベース バックアップと ElasticSearch コールド データ ストレージを接続し、2PB を超えるデータを JuiceFS に移行し、将来的には 10PB を超えるデータにアクセスできるようになる予定です。現在、JuiceFS システムは安定しており、運用・保守コストや保管コストの削減において良好な成果を上げています。この記事では、JuiceFS の原理、使用中に発生した問題、採用した最適化ソリューションについて簡単に紹介します。

2. JuiceFS アーキテクチャと POC テスト

2.1 アーキテクチャの概要

JuiceFS はメタデータ情報と実際のデータ ブロックを個別に管理し、FUSE を通じて POSIX インターフェイスを実装し、ユーザーがローカル ファイル システムのように使用できるようにします。ユーザーが JuiceFS によってマウントされたディレクトリにファイルを書き込むと、ファイル データはオブジェクト ストレージに保存され、対応するメタデータ (ファイル名、ファイル サイズ、権限グループ、作成および変更時刻、ディレクトリ構造など) はメタデータ エンジンに保存されます。このアーキテクチャでは、ls やデータ削除などの操作はメタデータ エンジンに対する操作のみであり、オブジェクト ストレージの速度制限の影響を受けないため、パフォーマンスがより確実に保証されます。

2.2 メタデータエンジンの選択とテスト

JuiceFS メタデータ エンジンには、オープン ソースの Redis、TiKV、公式のクローズド ソース エンタープライズ バージョン メタデータ エンジンなど、さまざまなオプションがあります。 Ctrip のデータの規模の大きさと、それに続くより多くのデータへのアクセスを考慮すると、メタデータ エンジンは TB レベルのメタデータの保存をサポートし、水平方向に拡張できる必要があります。そのため、TiKV と公式エンタープライズ バージョンのメタデータ エンジンが代替手段となりました。

TiKV のパフォーマンスを検証するために、go-ycsb を使用していくつかのパフォーマンス テストを実行しました。

テスト結果:

1) 書き込みトランザクション書き込み操作、クライアントスレッド数が増えるとTPSが上昇し、ピーク値が30,000を超える

2) トランザクション読み取り操作の取得: クライアントスレッドの数が増えるとQPSが上昇し、単一ノードのピーク値は70,000に近くなります。

テスト結果から判断すると、TiKV は読み取りおよび書き込みスループットが高く、単一操作の応答時間 P99 は 10 ミリ秒未満です。コールド データ シナリオでは、そのパフォーマンスはビジネス ニーズを満たすことができます。

メタデータ エンジンの公式エンタープライズ バージョンは TiKV よりもパフォーマンスが優れていますが、コールド データ ストレージには厳しいパフォーマンス要件がないこと、およびオブジェクト ストレージの 20 ～ 200 ミリ秒のアクセス速度と比較すると、メタデータ エンジンによってシステム全体の応答速度が大幅に低下することはありません。技術的なブラック ボックスを削減するために、メタデータ エンジンとして TiKV を選択しました。

2.3 JuiceFS 全体の POC テスト

本番環境への配信前に、SLA 指標と最適な使用シナリオを明確にするために、メタデータ エンジンとして TiKV を使用した JuiceFS の全体的な POC テストを mdtest を使用して実施し、次のアーキテクチャを展開しました。

1) シングルスレッド書き込み、ファイルサイズとスループットの関係をテストする

テスト結果によると、ファイル サイズが大きくなるにつれて、スループットも増加します。 1 つのファイルが 128MB ～ 256MB 程度になると、スループットとファイル サイズの元の成長曲線は大幅に遅くなります。ファイルが小さい場合、JuiceFS クライアントとメタデータ エンジンおよびオブジェクト ストレージ間の相互作用コストが実効データ転送コストよりも高くなり、スループットが制限されることがわかります。ファイルが大きい場合、インタラクションコスト比は低下し、スループットは増加します。 JuiceFS のスループット容量を最大限に活用するには、128MB を超えるファイルを保存することをお勧めします。

2) ディレクトリの深さとJuiceFS IOPSの関係

テスト結果によると、ディレクトリの深さは JuiceFS IOPS と明らかな関係がないことがわかります。 JuiceFS コードを調査すると、深度が深くなるほどファイル パスが長くなりますが、JuiceFS がファイル/ディレクトリを作成するときに、TiKV のキーは親ディレクトリの inode + 新しいエントリの名前であることがわかります。したがって、ディレクトリの深さは TiKV 内のキーと値のペアのサイズに影響を与えず、TiKV のクエリ パフォーマンスにも影響を与えません。これはテスト結果と一致しています。

3) ディレクトリサイズとls速度の関係

テスト結果によると、ディレクトリ内のファイル数は ls にほとんど影響を与えません。

2.4 メタデータエンジンの障害テスト

理論的には、TiKV ノード内のリージョンは Raft を通じて一貫性を保証します。つまり、リーダー以外のリージョンの障害は上位層アプリケーションに影響を与えません。リーダー領域に障害が発生すると、その領域のレプリカからリーダー領域が再選出されます。選出には時間がかかり、処理のために PD ノードに報告する必要があるため、上位層アプリケーションの一部のリクエストに影響します。

PD クラスターは、TiKV クラスターを管理するために使用されます。 PD の非リーダーノードの障害は、上位層アプリケーションにはまったく影響しません。リーダー ノードに障害が発生した場合、新しい PD リーダーの再選出が必要になります。選出プロセス中は、JuiceFS クライアントの要求に応答できません。新しいリーダー ノードが確立された後、JuiceFS が接続を再確立するまでに一定の時間がかかり、この期間中は上位層アプリケーションのリクエストに影響します。

これを基に、ノード障害のシナリオをシミュレートし、実際のアプリケーションで障害後のメタデータ エンジンの回復に必要な時間をテストし、通常のシナリオと異常な状況で一定数のファイルの読み取りと書き込みの時間差を計算しました。結果は、障害の影響時間を数秒単位で制御できることを示しています。

1) TiKVの故障

2) PDの失敗

3. JuiceFS原理の分析

3.1 ファイルの書き込み

JuiceFS は書き込み要求を受信すると、まずデータをバッファに書き込み、チャンク、スライス、ブロックのルールに従ってデータ ブロックを管理し、最後にスライスをディメンションとしてオブジェクト ストレージにフラッシュします。フラッシュは基本的に、スライス内の各ブロックに対して PUT 操作を実行し、データをオブジェクト ストレージに書き込み、メタデータの変更を完了します。以下のように表示されます。

• 大きなファイルは、まず FUSE によって 128K ブロックに処理され、その後 JuiceFS 内で 4M ブロックに組み立てられます。スライスによって管理されるブロックは、スライスが 64M (チャンクのサイズ) に達するまで増加し続け、フラッシュ操作がトリガーされます。チャンク、スライス、ブロックはメモリ バッファを使用して組み立てられ、そのサイズは JuiceFS 起動パラメータ buffer-size によって制限されます。
• 小さなファイルは新しいスライスによって個別に管理され、ファイルの書き込みが完了するとオブジェクト ストレージにアップロードされます。
• クライアントがライトバック モードを設定した場合、JuiceFS はデータを直接 Object Storage に書き込むのではなく、JuiceFS が配置されているマシンのローカル ディスクに書き込み、その後非同期的に Object Storage に書き込みます。この方法はデータ損失のリスクがありますが、データの書き込み速度を向上させることができます。

3.2 ファイルの読み取り

読み取りプロセスのデータ処理方法は、書き込みプロセスのデータ処理方法と同様です。 JuiceFS プロセスは読み取り要求を受信すると、まずメタデータ エンジンにアクセスして読み取り対象のブロックを見つけ、次にオブジェクト ストレージに同時に GET 要求を発行します。ブロック データは不変であるため、読み取られた 4M ブロックはローカル キャッシュ ディレクトリに書き込まれます。読書の過程では、4M（ブロック）という形である程度の事前読書が行われます。プリフェッチパラメータを調整することで、事前読み取りウィンドウを大きく設定できます。デフォルトのプリフェッチ = 1。以下に示すように:

• 大きなファイルを順次読み取るシナリオでは、オブジェクト ストレージ内の 4M のオブジェクトが読み取られ、FUSE によって 128K のブロックに処理されてユーザーに返されます。このシナリオでは、キャッシュヒット率が非常に高くなり、事前読み取りとローカルブロックキャッシュによりスループットパフォーマンスが良好になります。
• 大きなファイルのランダム読み取りシナリオのプロセスは、順次読み取りシナリオのプロセスと同じです。このシナリオでは、事前読み取りとキャッシュ ヒットの確率は非常に低くなります。これらのロジックは読み取りパフォーマンスに影響を与える可能性があります (読み取りデータはローカル キャッシュ ディレクトリに書き込まれる必要があります)。 cache-size = 0 を設定すると、キャッシュをオフにすることができます。
• 小さなファイル（4K など）を読み込む場合は、現在のファイルのブロックが読み込まれ、FUSE を通過した後、ユーザー プログラムに応答されます。取得したデータはローカル キャッシュ ディレクトリにも書き込まれます。

4. トラブルシューティングとパフォーマンスの最適化

4.1 TiKV CPU使用率が高すぎるため、サービス拒否が発生する

現象: TiKV kv_scan リクエストの数が突然増加し、unified_read_po スレッド プールの CPU 使用率が最大限に利用される

分析:これは、クライアントが cleanTrash タスクを実行しているために発生します。 Beta 1 クライアントはこのタスクを同時に実行します。同じボリュームをマウントするクライアントが多く、ゴミ箱内のデータの量が非常に多い場合、このタスクによってメタデータ エンジンに突然の負荷がかかります。

解決：

• メタデータ エンジンの各インターフェイスへのクライアントの呼び出し量の監視を強化して、問題の原因となっているクライアントを迅速に診断できるようにします。
• バックグラウンド タスクをクライアントから分離します。クライアントはユーザー要求を実行するだけでよく、cleanTrash などのバックグラウンド タスクは別のコンポーネントに引き渡されるため、JuiceFS 管理者による制御が容易になります。
• クライアントをアップグレードします。 Beta3 では、分散ロックと no-bgjob 起動パラメータが追加されました。

4.2 TiKVデータ漏洩

現象：リージョン数とストアサイズは増加し続けますが、OSS 内のファイル数とデータ量は増加しません。

分析: tikv-ctl を介して TiKV のデータを確認すると、MVCC の変更および削除レコードがクリアされていないことが判明しました。完全な TiDB デプロイメントでは、10 分ごとにデータ GC がトリガーされます。ただし、TiKV を単独で展開する場合は、他のプログラムによってデータ GC をトリガーする必要があります。一方、TiKV のバージョン 5.0.1 にはバグがあります。データ GC は削除レコードをクリーンアップしません。関連する問題があります。

解決：

• コンポーネントを別途実装し、GC 関数を定期的に呼び出すには、https://github.com/tikv/client-go/blob/v2.0.0/examples/gcworker/gcworker.go を参照してください。
• TiKVを5.0.6にアップグレード

4.3 CSIマウントシナリオでは、PVクリーンアップ後にOSSのデータを回復することはできません。

現象: k8s の ElasticSearch のすべての Pod、PVC、PV がオフラインになってから 1 日経っても、OSS データはまだクリーンアップされていませんでした。

分析: PV がクリーンアップされると、CSI は JuiceFS rmr コマンドを実行し、すべてのボリューム データをごみ箱に移動しました。デフォルトの設定である trash-day=1 によれば、データのリサイクルは 1 日後に開始されます。環境内のすべての JuiceFS マウント Pod がオフラインになっているため、つまり、JuiceFS プロセスが CSI ボリュームをマウントしていないため、ごみ箱はクリーンアップされません。

解決策: CSI モードでは JuiceFS を使用してサブディレクトリ プロセスをシミュレートするため、CSI 管理 Pod 全体でマウントされるボリュームは同じであり、サブディレクトリへの書き込みによってデータの分離が実行されます。マウント ポッドのすべてのバックグラウンド タスクを停止し、ごみ箱データの自動クリーンアップなどのバックグラウンド タスクを完了するためにボリュームをマウントする別のマシンを見つけました。この方法により、バックグラウンド タスクによって発生するクライアント パフォーマンスのジッターも解消されました。

4.4 クライアントのメモリ使用量が高すぎる

現象: JuiceFS を使用する一部のマシンでは、メモリを過剰に占有し、20GB 以上に達します。

分析:

• cat /proc/$pid/smaps をチェックすると、占有されているメモリが Private_Dirty であることがわかりました。これは、JuiceFS プロセスによって長時間保持されており、ページ キャッシュ キャッシュが原因ではないことを意味します。
• pprof ツールを使用してヒープ使用量を分析すると、例外はダンプ メタ (バックアップ) によって発生したと推測できます。

解決策:クライアントの起動パラメータ backup-meta のデフォルト値を 0 に変更します。メタデータのバックアップは、公式の実装の考え方に従って、他のコンポーネントを通じて均一に実装されます。クライアントはメタデータのバックアップ タスクを実行しません。

4.5 最適化されたアーキテクチャ

生産現場では PB レベルのデータが扱われ、ビジネス シナリオは多岐にわたります。計画と最適化を経て、最終的に次のアーキテクチャへと進化しました。

• 小規模なビジネスの場合、ユーザーがマウントした JuiceFS クライアントがセッション、ゴミ、その他のデータを管理します。
• 大規模なビジネス (PB レベル、数百のクライアント) の場合、マウントされたクライアントはセッション、ゴミ、およびその他のデータのクリーンアップを処理しません (no-bgjob パラメータを有効にします)。管理者は、それを個別に処理し、クリーンアップを高速化する機能を提供するクライアントを提供します。
• 同じ tikv クラスター内のすべてのボリュームに対してバックアップ メタ操作を実行するためのクライアントが提供されます。
• OSS および TIKV クラスターへのアクセス フローを制限する機能を提供します。コマンドを発行することで、クライアントのフロー制限機能を変更し、専用回線の帯域幅とメタデータ ライブラリを保護し、必要に応じてサービスの低下を実現できます。
• 複数のメタデータ クラスター セットを使用して、動作に大きな違いがあるビジネスを分離します。
• TiKV の GC をトリガーするサービスを提供します。

V. 要約と展望

Elasticsearch は、JuiceFS を介してコールド データをパブリック クラウドにアップロードすることで、ある程度のストレージとコンピューティングの分離を実現し、レプリカによって発生するメモリ要件を排除し、クラスター全体のデータ ストレージ機能を向上させます。 DBA バックアップ データを GlusterFS から JuiceFS に移行した後、ls などの操作のパフォーマンスが大幅に向上しました。運用保守担当者がディスクの拡張やメンテナンスに労力を費やす必要がなくなり、運用保守コストが大幅に削減されただけでなく、ユーザーも保存期間に応じてストレージコストを迅速に制御できるようになりました。

現在、ElasticSearch と DBA バックアップからの 2PB のデータが JuiceFS に保存されています。将来的には、さらに多くのデータを JuiceFS にプッシュする予定です。もちろん、次のようなさらなる調査と最適化が必要な領域はまだたくさんあります。

• メタデータエンジンTiKVのパフォーマンスをさらに最適化し、JuiceFSの安定性を向上させて10PB以上のデータ量に対応します。
• ClickHouse コールドデータストレージに JuiceFS を使用する方法を探る
• パブリッククラウドのシナリオでHDFSをJuiceFSに置き換えて、クラウド上のストレージコストを削減します。