先週のInfoQ Liveで、BBCのプリンシパルシステムエンジニアであるBlanca Garcia-Gil氏が、Evolving Analytics in the Data Platform (データプラットフォームの進化する分析)というタイトルのセッションを行った。このセッション中、Garcia-Gil氏は、チームが失敗に備える方法と設計方法に焦点を当てた。
BBCは、BBCが提供するものを最大限に活用できるように、読者をよりよく理解するためのデータプラットフォームを維持している。彼らはAWSでプラットフォームを運用しており、分析パイプラインはチームによって構築された最大規模のデータパイプラインだ。1日に数十億のメッセージを処理し、関連するデータレイクはペタバイト規模だ。
チームがパイプラインを設計する際に、「既知の未知」と「未知の未知」の2種類の障害モードを計画した。既知の未知は、チームが発生する可能性があると予測できる障害だ。メトリック、ロギング、および監視ダッシュボードは、このタイプの障害を処理するために使用される主要なツールだ。一方、未知の未知は、制御も予測もできない障害だ。Garcia-Gil氏は、これらの障害のそれぞれを予測して計画することは非効率的であるため、発生した問題を調査するためのツールが必要であると述べている。このツールは、最終的には、Garcia-Gil氏のチームにさまざまな方法で利益をもたらした。たとえば、それを意識する必要のない人々から詳細を抽象化し、インシデントを解決する時間を大幅に短縮する。
次の図は、パイプラインアーキテクチャを示している。これは、一部で、障害に対する設計の結果だ。
出典: https://twitter.com/blanquish
主要な取り込みパイプラインコンポーネントは、図の一番上の行に示されている。サードパーティの分析プロバイダがファイルをS3にアップロードし、そこでアップロードをキャプチャするイベントが生成され、キューに入れられる。小さなJavaアプリケーション (Job Submitter) がイベントを取得し、最小限の検証を実行して、Apache Livyを使用してApache Sparkで実行されている map-reduce クラスタに処理ジョブを送信する。処理結果は、内部の中間S3バケットに保存される。最後に、Apache Airflowワークフローはアグリゲーションを生成してAmazon Redshiftビッグデータウェアハウスにロードし、データ自体をS3ベースのデータレイクにロードする。
Garcia-Gil氏のチームは、いくつかの「既知の未知」を処理するために上記のパイプラインを設計した。たとえば、パイプラインを明確に定義された境界を持つ複数のサービス (中間のS3ストア、キューなど) に分割することで、チームは「ビッグバン」タイプの障害を回避できた。代わりに、マイクロサービスは内部の障害を分離し、互いに独立して動作できる。その結果、1つのマイクロサービスで障害が発生しても、他の隣接するサービスには影響しない。もう1つの例は、障害が検出されて修正された場合にデータをすばやく再生できる Resubmitter (再送信) ユーティリティだ。
「未知の未知」を処理するために使用された主なツールは、系統ストアだ。系統ストアはPostgreSQLで実装されている。データ処理チェーン内のイベントを追跡する。これを行うことで、チームは問題を調査するのに十分なデータがない問題に対処するのに役立つ。Garcia-Gil氏は、時間の経過とともに表面化したそのような未知の1つを詳しく説明している。
サードパーティのサプライヤからデータを受け取っています。そのデータには合意された周期とフォーマットがありましたが、それでも多くの遅延データが見つかり、欠落しているデータを追跡し、ダウンストリームのビジネスユーザに物事が期待どおりに実行されていないことを通知できます。この場合、イベントと欠落しているデータを追跡する系統ストアがあり、一歩前進できました。不足しているファイルがないか定期的に系統ストアにクエリを実行するサーバレス関数を作成しました。不足しているファイルがある場合、それはすぐに私たちにアラートし、サプライヤとのチケットを作成します。
InfoQ Liveは、ソフトウェアの専門家とのセッションとオプションの懇談会を特徴とする一連のオンラインイベントだ。InfoQは、今後数か月以内にGarcia-Gil氏のセッションビデオを公開する。