$30 off During Our Annual Pro Sale. View Details »

認知負荷って何_を知った上で再考する_CloudFormationからCDKへの移行

kato
September 13, 2023
2.2k

 認知負荷って何_を知った上で再考する_CloudFormationからCDKへの移行

kato

September 13, 2023
Tweet

More Decks by kato

Transcript

  1. 名前 : 加藤 裕士 (yushi kato) 居住地:札幌市中央区 好きなサービス : CloudFormationが大好き!

    好きな事 : スペースエイジインテリア収集 最近の興味 : CDKは勉強中の白帯です。 音楽鑑賞(Black Music, 和物, アンビエント etc..) 自己紹介
  2. CloudFormation       (JSON/YAML) AWSサービスのリソースをコードで表現し作 成するサービス。 01. 02. Terraform (HCL) マルチクラウド等での利用も可能で、CFnを 介さずAPIを利用した高速デプロイを実現。

    AWSにおけるIaC 03. CDK (Typescript,JavaScript、 Python,Java,C#,Go etc..) 汎用プログラミング言語で記述可能。CFnに相当 するL1の他,高度に抽象化されたL2,L3が存在。 Serverless Framework,SAM,Pulumi etc.. 他
  3. 抽象化(L2/L3) - 本番利用では結局抽象ではなく具体で完璧に把握している必要があるのでは。  - 暗黙的な設定を意識しつつの作業は脳への負荷が高かったりしないかな。  - addoverride(上書き)等に感じる セット注文後にポテトをチキンに変えて、ピクルスを抜いて、 バンズをライスに変えるような違和感 (最初から単品で注文すれば...)

    言語選択   - 複数の言語から選択可能である事でコードの再利用性に悪影響はないのか。     - 汎用プログラミング言語で作成したものを結局YAMLで確認するの?    その他 - 物理(論理)命名はダメ(非推奨)なの?   - コンソールや合成して出てきたYAML結果が見づらくてストレス。 - forなど使える事によるメリットは本当に大きい? - 本音でいえばCFnに慣れていてツラミまでは感じてないんだけど.. 当時(初めて一週間時点の)私が感じた色々
  4. 私が考察するCDKとの対比においてのCFnのツラミ(一例) ①CFnがツラい=YAML構文の習得がツラいという事ではなさそう。 - そもそも熟知していない情報が大量に視界に入るのが認知的に辛い。(マネコンでも辛い) - 所謂「よしな(=設定すべてを完了させる能力が未成熟でも、安心して利用出来る助け)」を求めている。 →AWSの全てに詳しくないユーザーも、IaCのメリットを享受したい。気にしている部分以外は任せたい。 →CDKにはあってCFnにはない部分では?という事と考える。 ②ロールバックが発生して初めて判明する設定ミスやタイポ。 →

    小さいミスに対して都度ロールバックが発生する時間的なロスが辛すぎる。 → CDKならリンターがエディタ上でエラーを指摘して大半を削ってくれる。 ③リージョンをまたぐデプロイの際、値を引き渡す事が難しい。 (人間が記憶してParameterに値を渡すか自身でパラメータストア等へ保存させ、引き出す工夫が必要) ④マネコンから或いは、CLIからCFnの実行を行う際の画面遷移や入力が毎回面倒くさい。(1アクションがいい) ⑤S3のバケットの物理名重複等、残存リソースとの衝突があると、これまた再デプロイが失敗。 (これに関してはDeletionPolicy:RetainExceptOnCreateの登場で一部解消。)
  5. 最近体感しているCDKの良さ(先ほどのツラミに対する対処) ①TSの静的型付け+linterのおかげでエディタ上でエラーがわかり修正出来る。 - 失敗が確定しているデプロイが減少→エラー発生とロールバックの減少。 - ドキュメントの往復回数の減少。 ②抽象化の恩恵 - 初手で視界に入る情報量の抑制。 -

    気付けていなかった「AWSが提唱するあるべき姿」(セキュリティ設定等)とお友達になれる。 (気付いて→信頼し→任せるという意識フローが存在する。(コンストラクトとユーザー間の信頼関係の醸成)) ③ChangeSetを利用した差分変更が容易。 - 初回デプロイ以降は前回デプロイ内容に対する変更で済む為、時間短縮になる。 - cdk diffで「前回との違い」を自分以外にアウトソーシング出来る。 ④物理命名が非推奨である事(良し悪しの「良し」) - 既存リソースとの物理名の衝突を回避。 ⑤並列で一気にデプロイしたり、リージョンを跨いで値を引き渡してくれたり、バケットのオブジェクトを消す Lambdaを作ってくれたりCFnにない便利がいっぱい。
  6. CFn→CDKに移行するにあたって「意識改善」出来た点。(と私個人が今一番聞きたい事) ①マネコンから物理名を見て「なんのリソースだったか」を判別し易いメリットは一旦忘れてみた。(そのうち慣れる) ②CDKで記述しているものは、慣れ親しんだCfnテンプレートを作成する為の「更に前段」である事を再認識する。 ③Cfnでは手の届かなかった「便利さ」や、「速さ(作業効率の助け)」がいっぱいある。 ④これまでのテンプレで蓄積してきたものはL1のProps(第三引数)にコピペして使える為、完全に無駄にはならない。 (が、実際にL1の完成形を起点にL2以上に昇華していく事は少なさそう) ⑤結局Forを使って作成するのもアリかもと思ってきた。(VPCEndPoint等々) ⑥cdk synthの可読性が低く感じていた事については各Metadataを含めないよう設定する事でかなり解消。 ターミナル上では⌘+F「Type:

    AWS::」をする事で区切れ目を判別する工夫をする等した。 ⑦CFnから始めるかCDKから始めるか迷っている人は、L1=書き方の違うCFnなので、CDKから始めるのが良いと思う。 (cdk synthで合成された結果はJSON、YAMLである為、これを理解する努力=CFnへの理解と考えて遜色なさそう。) CFnのドキュメントは最高の教科書だと思っているが、CDKのリファレンスはまだまだ仲良くなりきれていない。 今日の座談会ではCDKリファレンスで補完されない部分(CDK作業時のCFnドキュメントの登場ポイント)も聞きたい。 「CFnで当たり前になっているここはアンラーニングして臨んだ方がいい」という所があればそれも聞きたい。