地道に進めるIaC導入のアプローチ

はじめに

これは SRE Advent Calendar 2023 6日目の記事です。お邪魔します。

どこかの会社でWebサービスのSREをしています。
当社では主にAWSを利用していますが、ほぼすべてのリソースが手作業で作成変更されていました。
この状況にいくつか課題を感じており、今年はIaC化を進めた年でした。
当社の状況に照らしてIaC推進のアプローチについて書きます。

課題

  • 手作業でリソース作成変更がなされていた
    • ステージングでは動いたが、本番環境での作業漏れによって本番リリース失敗といった問題が発生していた
  • インフラ変更のレビューがムズかった
    • 作成、変更されたリソースについてレビュアーがマネジメントコンソールやaws cli等で直接確認する必要がある
  • 本番、ステージング、開発環境が1つのAWSアカウントに存在している
    • IAMロールなどのセキュリティや命名を細かく注意深く設定する必要がある。ちゃんと設定しないと本番/ステージングどの環境で使われているか分かりづらい
  • ゴミリソースもある
    • 上記のようにAWSアカウントが1つのため、気軽に消しにくい

IaC推進のアプローチ

IaC化を進めるにあたって以下のアプローチがあると思います。

  • 既存リソースをimportする
  • 既存リソースをIaCでリプレイスする
  • 新規リソースをIaCではじめる
  • (社内にIaCを布教する)

既存リソースをimportする

主にやったのが既存リソースをCloudFormationスタックにimportするというものです。 former2 にとてもお世話になりました。

  • former2でimportしたいリソースのテンプレートを得る
  • 生成されたテンプレートを一部手直しする
    • 論理IDを機械的なものから意味のある単語に変更
    • 本番/ステージングで同じ役割のリソースのテンプレートをマージする
  • スタックにimportしてドリフトチェックし、ドリフト無しを確認
  • テンプレートを改善
    • 本番/ステージングの無意味な差分の解消
    • RefやImportValueを使って適切にスタック間の依存関係を記述する
    • ゴミの掃除

former2を使った既存リソースのimportについては https://speakerdeck.com/kefi550/fei-iacnaawshuan-jing-wocloudformationdeiachua-suru でも軽く紹介しているので、興味のある方はご覧ください。

ステートフルな、再作成しにくい系のリソースは特にこのimportアプローチでIaC化しました。
一度既存の状況をそのままにimportしてその後に改善していくというのは、めんどいステップを増やすことにはなりますが、IaC導入初期では特にドラスティックに変更してしまうよりもレビューしてもらいやすかったり、比較的安全にすすめられるメリットがあると感じています。

既存リソースをIaCでリプレイスする

再作成しにくいものでなければIaCで作り直して旧リソースは削除するというのがラクな気がします。

  • lambdaなどステートレスなリソース
  • 社内向けシステム

あたりは再作成しやすいためリプレイスアプローチでやりました。
lambdaは大量にあるため、ランタイムバージョンアップのタイミングで対象のものだけIaC化作業をしています。
IaC化できることはもちろん、コードを準備する過程でコンポーネントの理解につながるというメリットもある気がしてます。

新規リソースをIaCではじめる

既存リソースをIaC化するのは上記の通りめんどい作業です。
IaCのメリットを享受し続けるためにも、新たに何か作る際はIaCではじめることが大事だと思います。
是非新規系はIaCではじめましょう。

今年当社ではいくつか新しいマイクロサービスを主にECSに構築する機会がありましたが、CloudFormation + ecspressoでデプロイするようにしました。
これは別記事とかで書けたらと思っています。

(社内にIaCを布教する)

  • 入社した当時はコード管理されたインフラはほぼなく、インフラのキャッチアップがムズかった
  • IaCは今後入ってくるメンバーのためにも役立つはず

上記をモチベーションにとりあえずテンプレートを書いてみて布教することにしました。
It's easier to ask forgiveness than it is to get permission の精神で、「IaCやりませんか？」としっかり伺いをたてることなく、「CloudFormationテンプレート書いたのでよかったら見てください！」としました。

このとき

  • 気軽にレビューしてもらいながらCloudFormationに慣れてもらえればいいなと思い、本番ワークロードではなく開発環境で使われてるコンポーネントからIaC化した
  • cdk等の選択肢もあったが、最初から抽象的な記述よりもある程度網羅的な記述のほうがレビューしやすいかなという理由でCloudFormationにした

これが良い立ち回りかは諸説あると思いますが、結果的にはメンバーにも受け入れられ、その後もIaCを進めることになったため良かったなと思ってます。

今後の展望

ここまで、とりあえず様々なAWSリソースをコード化をしたという段階です。
今後の展望として以下がありそうです。

  • 自動ドリフトチェック
  • デプロイパイプラインに載せる
    • 今やってないのは単に"オートメーション恐怖症"な気がする
  • ゴミ掃除
    • IaC化することでこれまであったゴミが可視化された。今後も掃除したい
  • AWSマルチアカウント化
    • セキュリティやコスト管理の観点からアカウントを分けたほうがよさそうですが、IaCによってアカウント分けもラクになるのではと思っている

おわりに

IaCのメリットについては様々な場所で語られていると思いますが、当社では特に作業ミスの防止やレビューがしやすくなるというメリットにつながったと感じています。
当社ではIaC元年のような状況だったこともありドラスティックに進めずに少しずつ地道にIaC化しました。似たような状況の方がいれば、参考になれば幸いです。