AWS関連

LayerXインボイスから学ぶTerraform 運用|JAWS-UG コンテナ支部 #20

はじめに

今回は「JAWS-UGコンテナ支部 #20」 の参加レポートになります。

有益セッションの中から今回は、LayerX 高江さん(@shnjtk のセッション 『実践DevOps チーム全体でインフラを管理する』 をピックアップさせていただきます。

過去に、AWS Summit Online 2021 で登壇されていた高江さんのセッションについても取り上げさせていただいたのですが、今回も相変わらず学びが多くて最高でした。ついつい(自分のために)整理したくなったのでレポートしていきます。

高江さんのセッション(LayerXの運用)は、いつも得るものが多いのよねマジで。
今回も何度もリピート視聴してしまった笑。

当日の動画はこちら↓

まとめ

詳細は後述していきますが、
まとめスライドに沿って各項目についてポイントを羅列してみます。

1.一貫性のあるルールを設ける

  • tf ファイルの命名規則を定め、ファイル名から管理対象リソースを確認できる
  • 再利用性を意識したリソース定義により、コピペ時の負担軽減&考慮漏れへの対策になる
2.タグを活用する

  • service_id タグで対象サービスの情報(プロジェクトコード的なもの)を明記する
  • managed_by タグで管理リポジトリを明記する
  • default_tags を利用して、Terraform 管理下のリソースを明確にする
3.CI/CD で処理を自動化する

  • tfstate ファイルはリモートバックエンド(S3)で管理する
  • 上記S3 バケットはバージョン管理することで万が一に備える(安心感を与える
  • GitHub Actions 等を利用したパイプラインを構築して Plan / Apply は自動化する
  • プルリクにPlan 結果を反映させることで共有&レビューできる体制づくり
4.Terraform コードをリファクタリングする

  • 思わぬ差分を出さないように(ポリシーのインライン化等)、日々リファクタリングを行う
5.必要に応じてTerraform 以外のツールも利用する

  • インフラはTerraform で管理することをベースとする
  • 複雑なLambda 関数(複数パッケージを要する等)を取り扱う場合には、AWS CDK を利用する
  • AWS CDK の管理対象はLambda 関数のみとし、周辺リソース(IAM / SSM 等)はTerraform で管理する

全体を通して、いかに『スピードを落とさずに効率的にサービスを開発するか』 という観点で運用が整えられているという印象を受けました。

この運用ルールについても日々ブラッシュアップされているとのことで、やはりLayerX イケているなと再認識しましたね、ハイ。(語彙力)

今回の学び [まとめの深堀り]

上で羅列したポイントに関して、より細かい部分の内容を以下にまとめてみます。

1.一貫性のあるルールを設ける

・「tf ファイルの命名規則」はスライドに例として記載してある通りです。
操作対象のファイルが一目でわかると言うのはとても効率的ですよね。

・「再利用性を意識したソース定義」は、”なるべくコピペしやすいように” あるいは”設定周りで守ってほしい部分がカバーされるように” といった部分をターゲットとしており、スピードだけでなく品質についても仕組みでカバーしにいく姿勢がとても素晴らしいと感じました。

加えて、これらの施策が「アプリ開発メンバーがインフラに変更を加える」ことを前提として設けられている点になんというか、、(技術レベルも意識も高くて)いいチームなんだろうな〜と感じずにはいれませんでした。

どの立場からモノを言っているのでしょうか?私は。。(スミマセン笑)

2.タグを活用する

タグに関しては、若干地味ではありますが運用を考えるにあたりかなり学びが多かった部分です。

・「service_id タグ」 として、サービス固有のプロジェクトコードを付与します。
このタグの使い方については、よくある運用の部類に入るのかなといった印象です。

・「managed_by タグ」 として、管理リポジトリの情報を付与します。
このタグがあることで何が嬉しいかというと、リソースに対して手を入れようとする場合にどのIaC リポジトリで管理されているかがすぐに分かるという点です。

これは便利だ◎
ちなみに、このタグ元々は別の用途で利用していたらしく、運用のなかで最適化されていった結果いまの用途になったんだとか。

・最後に「default_tags」について。
デフォルトタグを利用することで、Terraform で作成するリソースに対するタグ付けの抜け漏れがなくなります。
抜け漏れなくタグ付けができることで、手動で作成したリソースを簡単に見分けることができます。
”手動で作成したリソースは試しに作成したもの” という共通認識(運用)を持つことで、後から不要リソースとして削除する際のハードルがぐっと下がるがよいですね。

各リソースに対してそれぞれタグ付けの記述を追加していたのはいい思い出…(もっと早くdefault_tags と出会いたかったす涙)

3.CI/CD で処理を自動化する

インフラのCI/CD については、恥ずかしながら構築した経験がなかったのでこの部分も学びが多かったです。

・「tfstate ファイルのリモートバックエンド管理」 については多くの環境で取り入れられていることでしょう。複数人で作業を進める場合には特に、リモートバックエンドで管理するようにした方がよいですね。(1人でもほぼ必須と考えていいかもですね)
細かい部分でいうと、リモートバックエンドに利用する”S3 バケットのバージョン管理を有効化” についても切り戻しに備えて必要ですね。

・「GitHub Actions を利用したパイプライン構築」 については、自動化による作業コスト削減や情報共有やコードレビューの観点からもメリットが大きいと改めて感じました。(そして早く自分でも構築してみなきゃ、、と思いました。)

やったことないって前も言ってたよね自分?うだうだ言ってないでさっさとやってみようよ、インフラCI/CD。(to 自分)

4.Terraform コードをリファクタリングする

・これまた細かい話ですが、実際「思わぬ変更」は発生するものなので、思わぬ変更が発生しないような記述にリファクタリングします。

今回共有いただいた例でいくと、
S3 からGetObject するためのポリシードキュメントを定義している状態でS3 バケットのタグを変更した場合には、
ポリシードキュメントにも差分が出てくる(差分が出るような Plan 結果が出力される)というものです。

回避策としては、
ポリシー定義の記載方法を変更して、インラインでポリシーを記載するというリファクタリングを行っている、というものでした。

説明の中でもありましたが、「思わぬ変更(差分)」が発生すると”手が止まってしまう” ことに繋がるので、地道ではありますがこの手のリファクタリングも開発スピードを落とさないために必要な運用だなと理解できました。

確かに”apply してからのお楽しみ” 的なメッセージが出てきたら手止まるよな〜

5.必要に応じてTerraform 以外のツールも利用する

・「Terraform 以外のツール利用」について。
基本的にはTerraform でインフラを管理する、という大前提はありつつも、複数パッケージが必要となるようなLambda 関数の場合には、(Lambda 関数のみを対象として)AWS CDK を利用するとのことでした。

Lambda 関数はアプリ担当が変更を加えることが多いことから、対象となるLambda 関数についてはIAM 等の関連リソースとは別で管理する方が、手が止まってしまうリスクを避けられるという説明も納得できました。

ガチガチにルールを決めるのではなく、本来の目的に向かって柔軟に対応する姿勢がとても素敵ですね〜(またエラそうにm)

おわりに

冒頭でもお伝えしましたが、今回のセッションも相変わらず学びが多く、勉強になりました。

タグ利用の部分は早速取り入れさせていただき、インフラCI/CD についても練習的に構築してみようと思いました(思いました、ではなくヤル!。笑)

と言いつつ、今いる会社はTerraform やIaC にあまり積極的ではないので、、細々とやっていこうと思います〜笑

(最後にスパー余談ですが、LayerX のスピード感を垣間見ることのできたツイートを発見したので共有いたします。やばい)

(当日のスライド資料はこちら↓)

以上です。最後まで読んでいただきありがとうございました。