クラウドのdirty bitはAPI呼び出しログではなくリソース指向の変更フィードである
CPUはメモリの全走査をしない。ページテーブルのdirty bitが「変わったページ」だけを教え、キャッシュ一貫性プロトコル(MESI系)は無効化通知を受けたキャッシュ行だけを再取得する。「全部読む」を「変わったと通知されたものだけ読む」に変える構造である。
クラウドにもdirty bitに相当する仕組みはある。これを購読すればworldは「planのたびに全GETで作るスナップショット」ではなく「変更イベントで維持される実体化ビュー」になり、refreshは「前回チェックポイント以降のイベント再生 + dirtyなリソースだけのGET」に縮む。API呼び出し数はリソース総数ではなく変更数に比例する。
ただし供給源の選定が肝心である。「CloudTrailを購読する」という素朴な形には壁が二つある。
- 同定の壁: CloudTrailはAPI呼び出しのログであり、イベント中のリソースの表現(リクエストパラメータ、ARN、名前)がサービスごとに不揃いで、イベントをIaC側のリソース(state上のアドレス)へ一意に対応づけるのが難しい
- 量の壁: CloudTrailは読み取りを含む全API呼び出しを記録するため、ログが膨大になる
したがってdirty bitの供給源は、API呼び出しログではなくリソース指向の変更フィードにすべきである。AWS Configのconfiguration item、またはEventBridgeで書き込み系・対象リソース型に絞ったルールを一次チャネルに置く。Configは「リソース型 + リソースID」をキーに構成変更だけを配信するので、量の壁は構造的に小さく、同定の壁もリソースの語彙に最初から揃っている。
さらにawsccプロバイダはCloud Control APIの上にあり、すべてのリソースが「リソース型(AWS::EC2::VPC)+ primary identifier」という一様な同定子を持つ。stateが保持する識別子とConfigイベントの語彙がほぼ一致するため、CloudTrailで問題になった対応づけが構造的に易しくなる可能性がある。それでも残る不一致(識別子の表記揺れ、複合識別子)に対しては、購読対象をstateに存在するリソース型・識別子の集合へ事前に絞り込み、対応づけられないイベントは「不明な変更 → 反エントロピー同期の対象」へ落とす、という保守的な設計で吸収する。
イベント配信は遅延も欠落もあるので、それだけに頼ると静かにずれる。Dynamo系の反エントロピー — 低頻度のバックグラウンド全同期で補正する — を併用する。Merkle木的なダイジェスト比較で「どの部分木がずれたか」だけを特定して同期する発想も借りられる。
根拠の確度
CloudTrailの二つの壁(同定・量)は、Terraformとの組み合わせで筆者が実際に試みた確認済みの問題である。一方、AWS Config / Cloud Control APIの挙動と配信遅延に関する記述はAIの学習データ由来で、一次ソースとの突き合わせをしていない。awsccの一様な同定子が対応づけを易しくするという見立ても未検証。