🤗

新人エンジニアがインフラのコード化（IaC）に３ヶ月取り組んで見えた知見をまとめてみた

2020/10/09に公開

AWS

はじめに

約３ヶ月間、それなりにボリュームのある新規開発で AWS周りをガッツリやらせてもらいました。

AWS や新規開発について学ぶことが多かったので何回かに分けてまとめてみたいと思います。
これから AWS をガッツリ使っていこうと思っている方の参考になれば幸いです。

今回はその第１回、 IaC (Infrastructure as Code)編です🎉

AWSで使った技術など

CloudFormation
Lambda
DynamoDB
API Gateway
CloudWatch
CloudFront
X-Ray
SNS
S3

などなんかたくさん。
今回 IaC にはCloudFormationを使ったのですが、Terraform など他のツールでも参考になると思います。

ある程度の規模になりそうなら SAM はやめておこう

AWS でインフラをコード化するにはいろいろ選択肢がありますが、AWS SAM というものも使えます。
今回使用したのは厳密に言えばこちらの SAM です。

【参考】

簡単に言うと、Lambdaを中心としたサーバーレスアプリケーションを構築する人向けに、CloudFormationをより簡単に使えるようにラップしたもの、でしょうか。

何が問題なのか？

CloudFormationをラップしたものなので、CloudFormationで書けるものは基本的には書けるはずです。
では、何が問題なのでしょうか？

それは、 CloudFormation なら使える機能の１部が使えない（あるいは使いづらい） からです。

最初はスピード感を重視して SAM で開発を始めたのですが後々、

Stack の管理外にあるリソースを CloudFormation の管理下におきたい
リソースを記載したファイルが煩雑になってきたのでリファクタリングしたい

という時に苦労しました。もしかしたら何か別の方法があったかもしれませんが、必須では無かったのでとりあえず諦めました。

サクッとサーバーレスアプリを立ち上げたい時には素晴らしいのですが、ある程度の規模になることが見込まれるのであれば最初から純粋な CloudFormation で良くない？というのが印象です。

あまりメリットを享受できなかった気がする。。。

リソースの命名規則は最初にチームでしっかり決めていく

インフラをコード化する時には論理名（下のサンプルで言うと HelloBucket ）と、そのリソースの名前（バケット名とか）があると思います。

Resources:
  HelloBucket:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: PublicRead

これらの命名規則をしっかり決めておかないと、後で 何が何だかどこで使っているリソースなんだか分からなくなります。

私の失敗談を共有しておくと、それなりに分かりやすい名前を付けて進めていたつもりなんですが、「環境名の prefix」を付けていなかったんですね。

そして開発が進み、必要になりました。はい。環境名の prefix が。

うわあああああああああああああ、めんどくせええええええええ！！！！！！！

本当に後から名前を変える単純作業は苦痛ですし、工数としてもちょっと無駄です。
せっかく効率化のために IaC ツールを使っているのですから、この辺はスマートにやりたいところ。
是非皆さんには私のような間違いは犯して欲しくないなと思っております😵

命名規則に関しては以下のクラスメソッドさんの記事が非常に参考になります。

ワークフローはしっかりチームで決めよう

もちろんインフラをコード化したらチームメンバーにレビューをお願いすると思います。

しかしまだ経験が少ないなら尚更のこと、 AWS は実際にデプロイしてみないと分からないことが多々あります。
もしかしたら、合っていたと思っていた設定値が間違っていてデプロイに失敗するかもしれません。

それにレビューする側もプロパティがツラツラ書いているだけのものを見るより、動いてから見せてもらった方が良いと思います。
なので開発用の環境が用意できるのであればそこで試してからレビュー依頼を出す、とか工夫をした方が良いです。

工夫というか、チームで決めるようにできると良いですね！！
他にもワークフローに関してはこんなことを事前に決めておくと良いかもしれません

手でデプロイするの？ CI/CD ツールを使ってデプロイするの？
環境は何を用意してそれぞれがどんな役割なの？
コードレビューの着眼点

IaC ツールは Terraform を使おう

以上です、何も言うことはありません😢

手動を排除しよう

最初は良いんです、最初は。
しかし開発は進み、当初は予期していなかったリソースは増えていくものです。

その時、 チームのワークフローはそれに対応できるものでしょうか？

確かにコマンド一発でインフラを構築できる威力は凄いですしシンプルですが、それでも環境が増えたりすると手順ミスは当然起こりえます。
AWS ですし、下手にミスると大事なデータを消してしまったりもします。精神衛生上も良くないです（幸い問題にはなりませんでしたが、私も開発中何度かヒヤッとしました）。

めんどくさい気持ちは分かるんです。最初はコマンドラインから普通にデプロイした方が楽ですからね。

しかしこういうのは最初に CI/CD パイプラインを構築するなどして 仕組みに頼る べきです。
間違っても「自分は間違えない」などと過信してはいけません。どんなに優秀な人でも所詮人間です、普通に間違えます。間違えるのは決して悪いことではありません。それに対して策を講じないのが悪いことです。

気合で頑張るとかはやめて、仕組みに頼りましょう。

【例】
GitHubにpush → CDで検証環境にデプロイ → 動作確認 → レビュー依頼 → 修正対応 → masterにマージ → 本番環境にデプロイ

ほんの一例ですが、手元からデプロイするよりずっと安全です。

おわりに

まだまだあるのですが、長くなるのでこの辺で切ります。
引き続き、もっと安定して強力なワークフローを考えられるように頑張ります🙂

どなたかの役に立てば幸いです、ありがとうございました。