リファクタ耐性はidentityを歴史的に繋ぐ機構が要る
コード構造を変えたとき(rename / move / refactor)に既存リソースが破壊されないかどうかは、identityの生成規則そのものではなく、旧identityと新identityを歴史的に繋ぐ機構があるかどうかで決まる。identityの生成規則は「同じコードなら同じ識別子」を保証するだけで、コードが変わったときの連続性は別建ての機構が担う。
| ツール | リファクタ耐性の機構 |
|---|---|
| Terraform | movedブロック(1.1+)でリネーム/移動を吸収 |
| CDK | overrideLogicalId()で論理IDを明示制御。cdk refactor (新機能?) |
| Pulumi | aliasesで旧URNを保持して移動を吸収 |
| Carina | moved block実装済み(removed blockも対応)。リネーム自動検知はcarina#2194で起票済み |
Terraformのmovedブロックはこう書く。
moved {
from = aws_s3_bucket.old
to = aws_s3_bucket.new
}CDKのoverrideLogicalId('FixedId')は、escape hatchesの一つとして位置づけられている(node.defaultChildでL1を取得し、addPropertyOverride / addOverride / addDeletionOverrideと並ぶ)。construct pathからMD5ハッシュを生成する仕組みは、Construct構造を変えると論理IDが変わることを意味するので、この明示制御が必要になる。
CarinaのanonymousリソースがSimHashによるcontent-basedな識別子を使うのは、この問題への別方向の答えである。Hamming distance対応で、小さい引数変更時もstate内のリソースを追跡できる。identityを固定するのではなく、identityの近さで同一性を判定する設計になっている。
CDK / Pulumiは動的選択を言語側で遮断しない代わりに、identity安定性の責任をユーザに委ねる。AWS CDK公式のBest practicesは「Make decisions at synthesis time」としてホスト言語ループでのConstruct生成を推奨しつつ、「statefulリソースのlogical IDを変更すると置き換えが発生する」「単体テストでlogical IDの固定性を検証すべき」と注意喚起する。Pulumi公式も同様に、名前やparentの階層変更でURNが変わると別リソース扱い(削除→新規作成)になると警告する。これは「規約に委ねる」象限の典型挙動である。
根拠の確度
CDKのcdk refactorの存在と機能範囲、Pulumiのaliasesの使い方詳細は未確認。