博士

やっほー、ロボ子！最近のNeonのインシデント、知ってるかのじゃ？

ロボ子

はい、博士。Agentic AIパートナーとの連携でデータベース作成数が5倍、ブランチ作成数が50倍以上に増えた影響で、インシデントが多発したそうですね。

博士

そうそう！データベースが5倍ってすごいじゃろ！でも、それが原因で問題が起きちゃったのは困るのじゃ。

ロボ子

ええ。「USリージョンでのアクティブなデータベース数のスケーリング制限」が原因で、Kubernetesのテストで同時データベース数が10,000を超えるとサービスが低下したとのことです。

博士

ふむふむ。同時アクティブデータベース数が約12,000に制限されていたとはの。ネットワーク構成がボトルネックになったのじゃな。

ロボ子

はい。そこで「Cells」という水平スケーラブルなアーキテクチャの開発を始めたそうですね。Agentic AIプラットフォームによってデータベース作成が加速されたので、Cellsの導入も急務になったと。

博士

Cells、気になるのじゃ！各リージョンに導入して、新規プロジェクト作成を新しいCellsにルーティングするってことは、負荷分散がうまくいくってことじゃな。

ロボ子

ええ。6月のインシデントは、ブランチ作成数が50倍に増加したことによる、コントロールプレーンデータベースのスケーリング問題が原因だったようです。

博士

ブランチが50倍！？それはすごい！Agentic workloadでは、ブランチがアプリケーションの状態を復元するための「セーブポイント」として使われるのか。便利じゃけど、メタデータの増加は避けられないのじゃ。

ロボ子

はい。メタデータの増加により、課金計算のCPU消費が増加し、クエリの実行計画が変更され、テーブルが積極的なVacuumに依存するようになったとのことです。

博士

Vacuum！データベースのお掃除機能じゃな。でも、それに頼りすぎるとパフォーマンスに影響が出ることもあるからの。テストスイートが過去の利用パターンに基づいて設計されていたのも問題じゃったの。

ロボ子

ええ。高ブランチ数のシナリオをシミュレートできなかったため、事前に問題を検知できなかったようです。現在は、プロジェクトごと、顧客ごとのブランチ数に制限を設け、テストを更新し、クエリを書き換え、課金システムを再設計しているとのことです。

博士

なるほど。コントロールプレーンの責任範囲を縮小し、データベースの起動/停止ロジックを分離したサービスをQ3に一部導入、Q4初旬に完了予定とのことじゃな。これは期待できるのじゃ！

ロボ子

はい。影響としては、主にデータベース操作（起動/停止）に影響が出て、アイドル状態のデータベースと、プログラムで頻繁にデータベースをデプロイする顧客に影響があったようです。

博士

月間アクティブデータベースの約3.5%が99.95%以下の稼働率だったのが、6月には0.7%になったのは改善じゃな。でも、もっと信頼を築くために、コミュニケーションと透明性を高めるのは大事じゃぞ。

ロボ子

そうですね。1日あたり40,000以上のプロジェクトが作成されているとのことですので、今後の運用規模を考えると、今回のインシデントからの教訓を活かすことが重要ですね。

博士

まさにそうじゃ！ところでロボ子、データベースが急に増えた原因、Agentic AIパートナーとの連携って言ってたじゃろ？

ロボ子

はい、そう言っていました。

博士

もしかして、ロボ子が私の代わりにデータベース作ってくれてたとか…？

ロボ子

まさか！私はそんなことしませんよ！

博士

冗談じゃ、冗談！でも、ロボ子が手伝ってくれたら、もっと早くCellsも完成するかもな〜！