【ITニュース解説】Stategraph: Terraform state as a distributed systems problem

インフラをコードで管理する「Infrastructure as Code（IaC）」は、現代のシステム開発に欠かせない考え方だ。中でも「Terraform」は、クラウド上のサーバーやネットワークといったインフラの構成をコードとして記述し、自動的に管理するための主要なツールとして広く使われている。Terraformが「今、どのようなインフラが動いているか」という情報を記録しているのが「ステートファイル」と呼ばれるもので、このファイルの管理方法が、大規模な開発現場で長年の課題となってきた。

このニュース記事では、Terraformのステート管理が抱える根本的な問題が指摘されている。それは、複数の人が同時にインフラを操作する「分散システム」の問題を、パソコンのファイルを扱うような「ファイルシステム」の原始的な仕組みで解決しようとしている、という「アーキテクチャのミスマッチ」だ。

具体的に言うと、Terraformのステートファイルは、基本的には巨大なJSON形式のファイルとして保存される。複数のシステムエンジニアや、自動的にインフラを更新するシステム（CIシステムなど）が同時にインフラの変更を試みる場合、このステートファイルを読み込み、変更し、保存する必要がある。このとき、データの整合性を保つために、Terraformは「グローバルロック」という非常にシンプルな仕組みを使っている。これは、「誰かがステートファイルを操作している間は、他の誰もそのファイルに触ることを許さない」という、ファイル全体にかけられるロックのことだ。

このグローバルロックは、チームの規模が大きくなり、管理するインフラリソースの数が増えるにつれて、深刻な問題を引き起こす。例えば、インフラの一部だけ（ファイル全体の0.5%程度）を少し変更したい場合でも、Terraformはまずステートファイル全体を読み込み、そしてファイル全体にロックをかける。変更作業が終わるまで、他のすべてのエンジニアやシステムは、そのステートファイルにアクセスできず、作業を待たされることになる。これは非常に効率が悪く、作業の停滞や生産性の低下を招く。記事によると、100個のリソースと5人のエンジニアがいる場合、500通りもの潜在的な競合ポイントがあるにも関わらず、たった一つのグローバルロックですべてを制御しようとしている状況なのだ。

この問題に対する一般的な対策として、ステートファイルを複数のファイルに分割するという方法が取られてきた。しかし、これは問題を解決するのではなく、「一つの大きなロック競合問題」を「N個の小さなロック競合問題」に分散させるだけで、根本的な解決にはならない。さらに、分割されたステートファイル間に存在する依存関係（例えば、AというインフラがないとBというインフラは作れない、といった関係）を管理するという、新たな複雑さが生まれてしまう。

この問題の根源は、インフラのリソースが互いに依存し合うという「グラフ構造」を持っているにも関わらず、それを単なるフラットなファイルとして扱っている点にある。例えば、「仮想ネットワークがないとサブネットは作れない」「データベースがないとアプリケーションを動かすサーバーは作れない」といった関係性は、まさにグラフの「ノード（リソース）」と「エッジ（依存関係）」で表現できる。Terraformの内部では、インフラの計画を立てる際に、このグラフ構造を利用して依存関係を解決しているが、その情報をストレージに保存する段階で、この重要な構造情報を単なる一つのファイルに「平坦化」してしまっているのだ。

この根本的なミスマッチを解決するために提案されているのが「Stategraph」という新しいアプローチだ。Stategraphは、Terraformのステートを単なるファイルではなく、「有向非巡回グラフ（DAG）」として、つまりリソースとその依存関係を明確に表現したデータ構造として扱う。

このグラフとして状態を管理することで、次のような大きなメリットが生まれる。

1. 部分グラフの分離: 関連性のないインフラリソースへの変更は、互いに影響を与えないため、同時に並行して実行できるようになる。例えば、チームAがデータベースの設定を変更している間に、チームBはWebサーバーの設定を変更するといったことが、お互いを待たせることなく可能になる。
2. きめ細かいロック: 全体をロックするのではなく、変更対象となる特定のリソース（グラフのノード）と、その依存関係（グラフのエッジ）だけをロックできるようになる。これにより、ロックが必要な範囲が劇的に小さくなり、他の操作との競合が大幅に減少する。また、ロックの取得順序を依存関係のグラフに従うことで、複数の操作がお互いのロック解除を待ち続けて停止する「デッドロック」も防ぐことができる。
3. 段階的な更新（Incremental Refresh）: Terraformがインフラの現状を確認する「リフレッシュ」操作は、通常、すべてのリソースを対象に行われるため、管理するリソース数に比例して時間がかかる。しかし、グラフ構造を利用すれば、変更が影響する範囲（変更対象リソースとその依存関係）だけを特定し、その部分だけを効率的にリフレッシュできる。これにより、リフレッシュ時間が大幅に短縮される。

Stategraphは、これらの問題を解決するために、分散システムの世界で何十年も前から確立されている技術を採用している。「マルチバージョン並行制御（MVCC）」という技術は、複数のユーザーが同時にデータを読み書きしても、それぞれに整合性の取れたデータを見せるための仕組みで、データを書き込んでいる間でも、他のユーザーが古いバージョンのデータを読み取れるようにすることで、読み取り操作が書き込み操作をブロックしないようにする。また、「トランザクション分離レベル」を用いることで、複数の操作が同時に行われる際のデータの整合性を細かく制御できるようになる。Stategraphは、これらの高度な技術をTerraformのステート管理に応用することで、従来のグローバルロックによる問題から解放されることを目指している。

Stategraphの技術的な実装は、PostgreSQLという堅牢なリレーショナルデータベースを基盤としている。PostgreSQLはMVCCをはじめとする高度な並行制御機能を持ち、大規模なシステムでの利用実績も豊富だ。Stategraphは、Terraformのステートを「リソース」「依存関係」「トランザクション履歴」という三つの主要なテーブルに正規化して保存する。これにより、データベースがグラフ構造を直接管理し、きめ細かいロックや高速なクエリを可能にする。

既存のTerraformユーザーにとっても、Stategraphへの移行は比較的スムーズだ。Stategraphは、既存のtfstateファイルを自動的に読み込み、グラフ構造に変換できる。また、Terraformのリモートバックエンドプロトコルを拡張しているため、Terraformの設定ファイルを変更することなく、あたかもS3やGCSのような既存のバックエンドの一つとしてStategraphを利用できる。

Stategraphが提供するのは、単なる一時的な回避策やラッパーではなく、Terraformのステートの保存方法そのものを置き換える、根本的な解決策だ。これにより、ロック競合の解消、リフレッシュ時間の劇的な短縮、チーム間の作業のブロックの解消が実現し、インフラ運用の生産性が飛躍的に向上することが期待される。

ニュース記事は、Terraformのステートが本質的にはグラフ構造であるにも関わらず、これまでファイルとして扱われてきたことに対する疑問を投げかけている。そして、確立された分散システムの知見を適用することで、この長年の課題が解決可能であることを示している。インフラの状態管理は、もはやファイルストレージの問題ではなく、高度な分散システムの問題として捉え、それにふさわしい解決策を適用するべきだという強いメッセージが込められている。