Datadogは、第3世代のログストレージシステムHusky専用のデータインジェストアーキテクチャを開発した。このイベント駆動型アーキテクチャ(EDA) により正確なセマンティクスを実現、マルチテナントプラットフォームのトラフィックのバーストに対応し、妥当なインジェストレイテンシーと許容できる運用コストで対応できる。
Datadogは2022年のHuskyリリース以降、2つのデータストレージアーキテクチャを運用してきたが、従来のアーキテクチャでは対応が難しいデータストレージやクエリ要件があることが分かった。
Huskyのアーキテクチャでは、データ取り込み、データ圧縮、データ読み込みのワークロードを分離し、それぞれを独立してスケールさせることが可能である。3つのワークロードはすべて、FoundationDBで構築された共有メタデータストアと、AWS S3を使用するブロブストレージサービスを活用している。データ取り込みワークロードは、Apache Kafkaを使用して、イベントをストレージプラットフォームに配信し、データライターに内部でルーティングする。
/filters:no_upscale()/news/2023/06/datadog-husky-data-ingestion/en/resources/1datadog-husky-architecture-1686691944650.jpeg)
出典： https://www.datadoghq.com/blog/engineering/introducing-husky/
DatadogのシニアソフトウェアエンジニアであるDaniel Intskirveli氏は、効率的なデータインジェストソリューションのための自社の課題を説明している。
Huskyで少数レコードを検索するクエリの実行はできるが、そのようなクエリを大量かつ低遅延で実行するように設計されていない。この設計により、 データがHuskyに正確に一度だけインジェストされ、重複したイベントが存在しないことを保証する方法の確立がHuskyの課題となる。
重複したイベントは、アラートモニターの評価で偽陽性や偽陰性を引き起こす可能性があり、顧客の請求に関わる使用状況報告にも影響を与えるため、Datadogにとって正確なインジェストのセマンティクスは極めて重要である。
これを、受信したイベントストリームを各テナントの複数のシャードに分割する内部ルーティングメカニズムで実現する。 テナントシャードからのイベントは、インメモリイベント重複排除を担当する下流のライトワーカー（またはライター）によって、ストレージエンジンに取り込まれる。このアプローチでは、シャード内のテナントデータの局所性により、重複排除が容易になり、より良いパフォーマンスが得られる。テナントデータはストレージレベルで分離されているため（別々のファイルに保存）、ルーティングメカニズムにより、シャードに含まれるテナントの数が制限され、ストレージコストが削減される。
/filters:no_upscale()/news/2023/06/datadog-husky-data-ingestion/en/resources/1datadog-husky-ingestion-1686691944650.jpeg)
出典： https://www.datadoghq.com/blog/engineering/husky-deep-dive/
ライトワーカー（またはライター）は、割り当てられたシャードからイベントを消費し、これらのイベントを永続化し、クエリ可能にする。これまでの経験から、チームは自動スケーリングと負荷分散を可能にするために、ライターのステートレス設計を選択した。イベントの重複排除をサポートするために、ステートレス・ライターは、以前に処理したイベントIDを永続的なデータストアに保存する必要がある。イベントIDはFoundationDBの別々のテーブルに挿入され、イベントメタデータとともに単一トランザクションでコミットされるため、原子性と一貫性が確保される。さらに、イベントIDは、LRU（最近使用された最小の）キャッシュを使用して、ライターによってメモリにキャッシュされる。
これによりスケールアップや再展開、インフラストラクチャの問題による再起動などの場合に、シャードが別のワーカーに再割り当てされるに発生する競合検出とその解決が可能となる。楽観的同時実行制御を使用し、イベントIDテーブルへの更新はバージョン管理され、順序外の更新は拒否される。ワーカーが競合を検出すると、FoundationDBテーブルからevent-IDキャッシュをリフレッシュし、Kafkaトピック内のオフセットをリセットする。