Airbnbでのフォールトトレラントなメトリクスストレージシステムの構築
Airbnbは、1秒あたり5,000万サンプル、2.5ペタバイトの時系列データを処理するために、社内ストレージシステムを開発しました。この移行は、進化する製品とインフラストラクチャ全体にわたる広範なコード計測によって生成される膨大な量のデータが原因で必要となりました。主なエンジニアリング上の課題は、この大規模なデータセットを高性能に永続化し、提供することでした。この規模を管理するために、Airbnbはマルチテナントアーキテクチャを採用し、安定したグループ化と属性付与のために、テナントをサービスまたはプロセスごとに分離しました。シャッフルシャーディングを実装してテナントのワークロードを分離し、テナントがノードのサブセットに対してのみ書き込みとクエリを行うようにすることで、フォールトトレランスを向上させました。運用上の複雑さ、特にテナントのオンボーディングと構成管理は、オンボーディングを自動化し、構成の更新を簡素化する統合されたコントロールプレーンによって対処されました。システムの主要な要件には、1秒あたり5,000万を超えるサンプルを処理すること、多数のダッシュボードとアラートをサポートすること、および低いクエリ実行時間を維持することが含まれていました。シャドウクラスターを使用した初期検証では、信頼性の問題、コンパクションの遅延、特に大きなデータペイロードでの遅いクエリパフォーマンスが明らかになりました。これらの課題への対処は、単一のクラスターの信頼性を確保することから始まり、ベンチマーク、ガードレール、およびクエリパスの分離を通じて、書き込み、読み取り、およびコンパクションの安定化に焦点を当てました。システムは、3つのゾーンにデプロイされたゾーン対応のステートフルコンポーネントを使用して、フォールトトレラントになりました。効果的なフリート管理とシステム保護のために、レプリカごとの制限とテナントレベルの制御が実装されました。その後、障害の範囲を縮小し、柔軟性を高めるために、マルチクラスターアーキテクチャが採用されました。ただし、このマルチクラスターアプローチは、メトリクスの検出、クエリ、および運用上のオーバーヘッドに複雑さをもたらしました。これらは、テナントとクラスターのマッピングのためのツールと、Kubernetesオペレーターを使用した自動化されたデプロイ戦略によって軽減されました。カスタム拡張機能を備えたPromxyの導入により、クロスクラスターのクエリとアラートが容易になりました。この道のりからの重要な教訓には、クロスクラスタークエリの大きなコストと、自動化と標準化されたデプロイメントを通じて実現されるデプロイメントの一貫性の重要性が含まれます。哲学は、クラスターを重要な、ユニークな「ペット」ではなく、使い捨てのリソースである「家畜」として扱うように進化し、スケーリングとメンテナンスが容易になりました。最終的に、このプラットフォームの構築には、アーキテクチャの革新、運用上の厳格さ、および期待値を管理する文化的な変化の組み合わせが必要でした。