雑に研究テーマと、その文脈の補足あるいはこっちで考えてる論点などを雑に箇条書きで補足していく。

多分箇条書きに適してない内容を書いているので、整形したい気持ちはある。

2024/07/31

テーマ(1)

デプロイ済みの、CloudFormation ベースの別の IaC ツールで管理されている構成を CDK に移植する具体的なやりかたの提示

• 移植元プロジェクトとして、SAM あるいは Serverless Framework で構成されたサーバーレスな構成を想定する
• cdk migrate で本当に行ける？
  • 行けるというイメージはあるが実際に詳細に手を動かすレベルまでイメージできてるわけではないので、一度やってみる必要がある
• Asset を置いておく場所を引き継ぐ必要がある。そのまま使う？移行する？
• リファクタリングの方法論
  • 論理ID を維持しつつ、つまり極力 snapshot diff を出さないようにしつつ L2 Construct に移行するリファクタリングは可能か？（そして、コストかけてそれをやる意義はある？）
  • Replacement が走っても問題のないリソースなら、論理ID が変わっても良いので同一内容のリソースを L2 で作り直せるはず。その場合のデグレ防止としてどんな対策ができるか？
• 直感的には、変更要件が Replacement な対象が増えるほどリファクタリングは大変になるイメージを持っている
  • 今後作る人に対する警鐘として、あるいは IaC (CloudFormation) の活用方法として、物理名付けるな説を推奨する根拠として使えそう

テーマ(2)

Replacement が走ってしまうリソース変更を意図せずやってしまうリスクを緩和したい

• migrate することが必要なわけではなく、CDK で再定義すること自体は問題ないらしい
• 前提として、「そもそも物理名を指定しない方がいい、」という議論もある -> aws-cdk/discussions/20275
• IAM Role の RoleName とか DynamoDB Table の TableName あたりが、人間が指定しがちかつ Replacement なプロパティなのでこのへんは移行課題の題材に適していそう
• このメモ書いた時点では、「デプロイ前に replacement リソースに気づく」方法は cdk diff くらいしか浮かばない
  • --change-set オプション（デフォルトで true になっている）はこの役に立つ？
  • diff コマンド自体は replacement を検出してくれる。何によってこれを実現しているのかが把握できればもっと良いアプローチがわかりそうなのでここは研究テーマ

テーマ(3)

Office Hour で出た質問ではないけど、私個人が気になっていること。

cxapi の下などで定義されているシンボルが、ソースを読んでいるとちょいちょい unresolved になっている。このへんをもうちょいストレースフリーにしたいが、方法はある？ちゃんとビルドすれば解決する問題なのではないかと予想しているのだが、それで問題は解決する？

そもそも cdk のソースのビルド方法自体を良く知らないので、そこから調べる必要あり

テーマ(4)

これまた Office Hour で出た質問ではないけど、私個人が気になっていること。

integ-test をちゃんと使ってみたい