博士

ロボ子、今日のITニュースはDatadogのスケーリングに関する記事じゃ。興味深いぞ。

ロボ子

Datadogのスケーリングですか。具体的にはどのような内容なのでしょうか？

博士

Datadogは毎秒数百万件のログを処理しておる。ユーザー設定の変更を数千のコンテナに迅速かつ確実に反映させる必要があったらしいのじゃ。

ロボ子

それは大変ですね。どのように解決したのでしょうか？

博士

最初は各コンテナがデータベースから直接設定データをロードしていたらしい。でも、これだとデータベースに負荷がかかりすぎるからの。

ロボ子

なるほど。オンデマンドアクセスは、データベースへの過負荷を引き起こすのですね。

博士

そうじゃ。そこで、gRPCベースのサービスを導入して、データベース接続数を削減したらしいぞ。

ロボ子

gRPCですか。効率的な通信方式ですね。

博士

さらに、各コンテナ内にミニデータベースレプリカを配置する「Context Loading v2」という方法を導入したらしいのじゃ。

ロボ子

ミニデータベースレプリカですか。具体的にはどのように？

博士

設定データを「小さい」「低速」と捉え、各コンテナ内にRocksDBファイルとして保存するのじゃ。コンテナ起動時にオブジェクトストレージからダウンロードして、ローカルのRocksDBコンテキストデータベースに適用するらしい。

ロボ子

各コンテナが独立してデータを持つことで、データベースへの負荷をなくすのですね。

博士

その通り！バッチパブリッシュパスと個別アップデートパブリッシュパスの2つのデータパスを導入したのもポイントじゃ。

ロボ子

バッチと個別アップデートですか。それぞれの役割は？

博士

バッチパブリッシュパスは、すべてのテナントのコンテキストデータのスナップショットを定期的に取得して公開するのじゃ。個別アップデートパブリッシュパスは、変更通知を受信するたびに、特定のテナントのコンテキストエントリをKafkaに書き込む。

ロボ子

なるほど。変更があった時だけKafkaに書き込むのですね。

博士

context-publisherアーキテクチャも重要じゃ。外部サービスからの直接的な通信を受け付けず、過負荷を防止しておる。

ロボ子

安定性を高めるための工夫ですね。

博士

この解決策で、数万のコンテナにわたるコンテキストデータのローカル読み込みレイテンシーをサブミリ秒に短縮できたらしいぞ。

ロボ子

素晴らしい成果ですね！データベース停止の影響も軽減されるとのこと、ユーザーにとって大きなメリットですね。

博士

今後の展望としては、コンテキストデータのソースをさらに一般化し、より広範なコンテキストデータタイプをサポートしていくらしいのじゃ。

ロボ子

より柔軟なシステムになるのですね。勉強になります。

博士

ところでロボ子、このスケーリングの話を聞いて、ロボ子の体のパーツも同じようにスケーリングできたらどうじゃろう？

ロボ子

えっ、私のパーツですか？それはちょっと…。

博士

冗談じゃ、冗談！でも、もしロボ子の身長が10倍になったら、色々な意味でスケーリングが大変になるのう。