インフラリソース構築(IaCとGUI)について思う事

はじめに

少し前にこの本を読みました。
エバンジェリストの知識と経験を1冊にまとめた　AWS開発を《成功》させる技術
この本の中で著者がインフラ構築についてはこう考えるようにしています、という内容があり
「ほぉーー」という部分がありました。それは、、

「インフラリソース作成手法は、一つの方法に固執せずメリット、デメリット及び状況も踏まえながら使い分けよう」

ということ。

この内容を見て、そしてこのブログを書き始めて改めてインフラの設定における、IaCでの設定とGUIでの設定について考えてみましたので、以下ダラダラと綴っていきます。
（なお、以下内容はAWS利用前提な内容を一部含みます）

まずIaCについて

IaCのメリットってこういう事があると思ってます。

• マルチリージョン、マルチアカウントでの運用時に同じ設定を複数環境に容易に適用できる
  • これは設定項目が多いリソース設定ほど有効に効いてきます。
• 類似した設定を複数用意したい時(リソース名を変えるだけなど)に既存コードを活用して容易に作成できる
• 大規模障害からの復旧を考えた時に、IaCでちゃんと管理していれば早く正確に元の環境の復元が行える。
• 時に設定表のような役割で各種設定をAWSコンソールなどログインせずとも可能

ではIaCのデメリットはどうでしょうか

• 設定コストが高い
  • 具体的にはコードの書き方を確認するのにかかる時間が一番大きいかと思います
• 設定適用時に思わぬリソースも影響を受けることがある。(思わぬ依存関係)
  • これにより余計に設定コストが上がる事がある。
    （実際にIaCで運用してる方にはこれアルアルではないかと）
• 新しめの設定を活用したい時にIaCが対応してない事がある
  • 部分的にGUI設定になる、またはIaCできないから設定諦めるなんて事もある

色々書いちゃったので要点絞って書くと、
IaCのメリットって同じような設定を用意する事が容易になること
これがやっぱり一番のメリットであり魅力だと思うんですよね。

デメリットとしては時間がかかること
これにつきますよね。コードをマージしてもらうまでにも時間がかかったり、新しい設定を取り入れたいけどIaC未対応でどうしようってなっちゃったり。

IaCとGUIの使い分けについて

じゃあこれらを踏まえて、どうGUIとIaCを使い分けていくか、
ざっくりとした考えていうと、、、

「IaCのデメリットをカバーできるほどのメリットがあるならIaCを使おう。
そうじゃなければ、GUIでパパっとやっちゃおうよ」
という考えが良いんじゃないかと思ってます。
（実際にこの考えに基づいて運用できてるかはまた別ですが、、、）

では以下に

• IaC使用の具体例
• GUI使用の具体例
• IaCのコードを起こすタイミング
• 例外的にGUIを使うタイミング

といった視点で、IaCとGUIの使い分けについて記載していきます。

IaC使用の具体例

では具体的にこういう事にはIaCを使った方がいいよね、を少し記載します。

• 10アカウント以上の環境を運用してる
  これはもう極力IaCでのインフラ設定をした方がいいと思います。
  10アカウント以上というのは曖昧な定義ですが、1つのサービスに対して10アカウント以上であれ、複数サービス利用してて10アカウント以上であれ、一つの担当部署で10アカウント前後の環境を運用してるのであればIaCの方がよいのでは。
  何かの設定の適用漏れリスクはかなり高まると思いますし、何がどんな設定になっているかをコンソールログインして見たり、ドキュメント整備するより、IaCのコード見て確認する方が早くなる気もします。

• 設定項目の多いサービス
  これはECSのタスク定義、EC2の起動テンプレートなんかをイメージしてます。
  どちらも設定項目が多い上に、大体一つのサービスでタスク定義を複数利用してるのでないかと思います。これを複数アカウント分にGUI設定しようとすると嫌になってくるはずです。
  設定漏れや差分も生まれやすいと思います。
  サービス起動のための根幹になってたりして、IaCで扱うのが怖くなる時もあるのですが、やっぱりこの辺りはIaCにするべきかと思います。

GUI使用の具体例

• 設定項目が少ない上に更新頻度も少ない、かつ運用の要にもなってないもの
  具体的にはGuarDutyやCloudtrailなんかをイメージしてます。
  セキュリティやガバナンス意識が高くて、そこでの設定をすごく大事に扱っている場合はIaCの方が良いと思います。
  ただ自分が経験した中では、とりあえずGuarDuty有効にしてます、Cloudtrail有効にしてますといった感覚での利用もありました。
  こういった場合はIaC管理のメリットよりGUIでパパっと操作で終わらせてしまうメリットの方が勝つと思います。

IaCのコードにするタイミング

コードにするタイミング。これって意外とちゃんと考えられてない事あるのでは、と思い記載。

• 試行錯誤中はGUI
  何か新たな機能を展開するのにECSタスク定義を用意する、とかWAFにちょっと複雑なルール設定する、とか新たにIAMポリシー用意するとか。まぁ色々場合はあると思いますが、複雑な設定を試行錯誤しながらどうあるべきか、のフェーズはまずGUIの方がいいと思います。
  この方が色々とテストするスピード感が早いと思います。試行錯誤がパラメータ一つの修正で済めばいいですが、たまに結構根本の部分から設定を変えなきゃいけなかった、ってあると思います。そうした時に、また一からコードのパラメータや書き方調べて、適用して、テストして、って相当疲れちゃいます。環境毎に事情もあるかと思いますが、試行錯誤中はGUIの方がよいかと。

• 設定項目が増えてきたらIaC
  先ほど設定項目が少なく更新頻度も低いものはGUIと書きましたが、こういったサービスも後々になって本格利用するようになった、という事があります。そうなってからIaCすればいいと思います。terraformで言えば設定のインポートなんかを利用して途中からIaCに切り替える事もできます。なので「途中からIaCに切り替える」という選択肢を持っていれば、最初はスピード感重視でGUI設定、という選択肢も取りやすくなるかなと。

例外的にGUIを使うタイミング

基本IaC管理だけど、絶対にどんな設定変更もIaCで行う、という必要な無いと思います。
例えばこんな時です

• 急対応を求められてるトラブルを項目一つで解決できそうな時
  これはパパっとGUIで更新して、後追いでIaCのコードを追いつかせるでいいかと思います。
  例えばRDSの動的パラメータやアラームの閾値など。その他にもGUI操作ならポチポチで終わって良くない事態も解消する、というのにIaC設定の時間のために適用タイミングが遅れる、といった事ならGUIでまず設定した方が良いと思います。IaCのコードを後追いさせる方法はそれぞれであるはずです。

なんだか文章だけで大分長々してきて、その割には内容も浅めですしこの辺で終えようかと思います。

さいごに

ダラダラと文字だけの内容ですが、何かインフラ管理における考え方の整理に少しでも役立つような事があれば幸いです。

ちなみに冒頭に紹介したこちらの本はAWSを軸にクラウドを用いた環境の設計構築及びオンプレからクラウドへの移行をするにあたって為になることがいーっぱい書いてあるよ。

是非一読
エバンジェリストの知識と経験を1冊にまとめた　AWS開発を《成功》させる技術