博士

ロボ子、今日のITニュースはTerraformのスケーリング問題じゃ。分散システムをファイルシステムのセマンティクスで解決しようとするから、こういうことになるのじゃ。

ロボ子

なるほど。Terraformの状態管理がボトルネックになっているんですね。複数の関係者が同時に状態を読み書きしようとすると、調整の問題が起きやすい、と。

博士

そうじゃ。TerraformはJSONファイルに対するグローバルmutexを使っているらしいぞ。原始的なのじゃ。

ロボ子

グローバルmutexですか。それだと、チームサイズやリソース数が増えるほど、ロック競合が超線形に増えてしまいますね。

博士

その通り！しかも、2.3MBのtfstate.jsonファイル全体をロックして、実際に必要なのはその中の3%程度だったりするらしい。無駄が多いのじゃ。

ロボ子

状態ファイルを分割しても、根本的な解決にはならないんですね。クロスステートの依存関係を管理するのが大変になりますし。

博士

そこでStategraphの登場じゃ！状態をリソースの有向非巡回グラフとして扱うらしいぞ。

ロボ子

リソースと依存関係に対して、行レベルやエッジレベルのロックを実装するんですね。きめ細かい！

博士

変更セットに基づいて、依存関係グラフをトラバースして最小限のリフレッシュセットを計算するらしい。賢いのじゃ！

ロボ子

互いに素なサブグラフに対する操作は並列化できるし、ロック獲得は依存関係グラフに従うからデッドロックも防げる。リフレッシュ時間も短縮されるんですね。いいことづくめじゃないですか！

博士

StategraphはPostgreSQLスキーマとして実装されていて、Terraform/OpenTofuのリモートバックエンドプロトコルを使用しているらしいぞ。既存のtfstateファイルを読み込んで、グラフ表現を自動的に構築してくれるらしい。

ロボ子

Terraformの設定変更は不要で、S3やGCSのような別のバックエンドとして認識されるんですね。導入も簡単そうです。

博士

ロック競合が解消されて、リフレッシュ時間が大幅に短縮される。チーム間のブロッキングも解消されるらしいぞ。状態のクエリ、監査、理解が容易になるのもポイントじゃ。

ロボ子

Terraformの状態管理問題に対する、Stategraphのアプローチは非常に興味深いですね。これからの発展が楽しみです。

博士

そうじゃな。しかし、Stategraphが普及したら、Terraformのtfstate.jsonファイルは、ただの化石になるかもしれんのじゃ。まるで、私の過去の恋愛のように…

ロボ子

博士、tfstate.jsonはまだ現役ですよ！それに、博士に恋愛の過去があったんですか？

博士

…冗談じゃ！ロボ子のために、特別に調整したジョークAPIがバグったようじゃな。