AWS CDK (TypeScript) を 継続的にメンテ可能にするために 取り入れているノウハウ集 id:nabeop / @nabeop 2022/12/09 Qiita Night 1

自己紹介 ● id:nabeop (なべおぴー) ● 株式会社 はてな ● システムプラット フォームチーム SRE 2

お品書き ● AWS CDK のコードを継続的にメンテ可能に するために ○ IaC で感じていた課題感 ○ 取り入れている知見 ○ 得られた恩恵 3

4 IaC における課題感

5 IaC のコードの陳腐化 ● IaC のコードはライフサイクルとライブラリ 更新頻度に大きな開きがある ○ インフラ部分は数ヶ月単位で変化しないこともある ○ 毎週のように使っているライブラリは更新される ● 気がついたらコードは更新されず、ライブラ リの更新からも取り残され、メンテ不能な状 態に...

6 IaC コードの運用にアプリ ケーション開発の知見を輸 入する

狙い ● ライフサイクルが短いアプリケーション開発でもライブラ リの更新への追従という問題はある ● インフラの変更をしない間にライブラリの更新に取り残さ れないようにしたい ● AWS CDK を TypeScript アプリケーションと捉えてみる ○ アプリケーション開発の知見を取り入れることでライブラリの追従コ ストを抑制できるはず 7

renovate による自動更新 8 ● https://github.com/hatena/renovate-co nfig をベースにしている ○ はてなで使用しているRenovateの設定プリセットを 公開しました - Hatena Developer Blog ○ レビュー者をチームメンバーからランダムにアサイン するようにしている ○ 更新が激しい割に影響が確実にないものはチームメン バーと相談しつつ automerge に変更

9 snapshot テストによる差分確認 ● ライブラリの更新を頻繁に取り込むにあたり、取り込まれ る更新内容が環境に影響を与えないことを確認したい ● AWS CDK を CFn テンプレートエンジンと捉える ○ ライブラリの更新が生成される CFn テンプレートに影響しないこと を確かめたい ○ snapshot テストで生成される CFn テンプレートの差分を確認したい ○ ノイズとなる差分は snapshot serializer で無視できるようにしてい る ● snapshot テストは実世界と極力合わせておく必要がある

reusable workflow による CI の横展開 ● Github Actions の workflow に落とし込んでいる ○ だいたい同じ内容の workflow が誕生する ● コピペしたくないので reusable workflow を導入し て CI の内容を一元管理するようにした ○ プロジェクト間の微妙な差異は package.json で吸収できるよ うに責任分界点を設定した ■ reusable workflow では実行する内容に責任を持つ ■ 実行時のオプションなどはプロジェクト側の package.json が責任を持 つ 10

11 得られた恩恵 AWS-CDK v2 への追従

12 AWS CDK v2 化で必要だったこと ● v2 bootstrap への対応 ○ (当時) 最新の AWS CDK v1 で対応していたので問題 なし ● feature flag や v2 に合わせたコードの修正 ○ snapshot テストの結果と見比べながら修正

実際はどうだったか? 13 ● 主業務の片手間としてコードの書き換えができた ○ 普段から意識の片隅にあった状態なので勘所があった ○ 最小限の手間だけですんだ ■ コードは常に最新の状態を保っていたので AWS CDK の開発プロ ジェクト側が準備したマイングレーションのレールにすんなり乗 れた ■ AWS CDK のコードをシンプルな状態に保っていたという側面は ある

14 まとめ

15 IaC コードを継続的にメンテ可能な状態にする ● ライブラリの更新は継続できる仕組みを入れ る ○ アプリケーション開発のノウハウを輸入 ● 負荷が少ない形で意識の片隅においておける 環境を作る

Dev トークやっています 16 https://jobs.qiita.com/dev_talks?employer=37