AWSのIaC案件に配属されることになったので、基礎知識を知っておきたい
IaCを身につけておくと良いことあるの？
本記事ではAWSインフラ運用経験者でIaC未経験の方が知っておくべき知識を纏めています。
- IaCとは？
- IaCのメリデメ
- AWSのIaC案件に入るための基礎知識
- IaCを扱えるAWSエンジニアの価値
インフラエンジニアになるために最低限必要な知識やスキル関しては下記にまとめています。
AWS IaC案件における基礎知識
IaCとは？
直訳はインフラストラクチャのコード管理(Infrastructure as Code)です。
プログラミングでインフラ構築を自動化する手法のことです。
インフラ案件は既にクラウド必須となりつつありますが、
クラウド案件であればIaC(infrastructure as code)を組み込むことが(徐々にですが)
多くなってきていると感じています。
デジタル化が急速に進む昨今、ITシステムにはより素早く、より効率的に
構築・管理・運用することが求められているからです。
IaCのメリデメ
IaCのメリット
IaC導入のメリット（＝目的）は主に下記の２つになると思います。
- 業務効率化
- 品質向上
ひとつずつ具体例を交えてみていきます。
-
- 業務効率化
構築自動化することが業務効率化に繋がるのは想像しやすいと思います。
例えば下記の時に効率化を実感できます。・同様な作業のコピー
毎年あるイベントのために同様のインフラ構成で構築する案件がありました。繰り返し作業を見越してIaC化を試み、
初回構築時の工数は3割増しくらいになりましたが、
次回作業時は10～20%くらい（8割減）の工数で
構築完了できました。・設定変更時の作業手順書が不要
本番環境の変更作業には１コマンド単位で手順を求められたりします。手順書作成は多く工数を取られますが、IaCであればコードをレビュー頂いていれば、
どのような作業でもコード実行のみという手順になり、個別の手順作成が不要、もしくは簡易になります。・障害復旧作業の簡略化（RTO短縮）
インフラの要件定義時にRTO（障害復旧時間）を検討します。
システム全損したら設計書を基に一から再構築しますという流れでの検討でした。
IaCを利用すると、コード再実行するだけで良くなります。 -
リリース頻度の向上
変化の激しい時代ということもあり
「リリース頻度増に備えて自動化しておいてほしい」
とお客様指示でIaC導入が行われることもありました。簡単な変更であっても、リリース作業はエンジニアにとって大きな負担になります。
完璧な作業手順書を作る労力が大きいからです。IaC化により、個別の作業手順書が不要になることでリリース準備工数が削減され
結果としてリリース頻度が向上します。 - 品質向上
構築自動化すると品質が格段に向上します。
これは説明するよりも実際にやってみると分かるのですが、
例えばEC2を手動作成する場合と自動（コード）作成する場合で
比較するとイメージがわくかもしれません。●EC2自動構築コード例
Terraform Registry
registry.terraform.io
・設計書が信用できるものになる
実際、設計書と実機設定が乖離していない現場はないです。
IaCの場合は手動変更を許可していなければコードと実機設定が乖離することはないので、
コードを設計書代わりにできるように見やすく書くか、
コードから設計書を自動作成する仕組みを作れば
設計書が100%信用できるものになります。・変更履歴管理（git利用によるバージョン管理）
gitを利用することでインフラの変更履歴を管理できるようになります。
いつどんな変更をしたかが把握できると、障害がどの変更による影響なのかがわかり、
品質向上に繋がります。
- 業務効率化
IaCのデメリット
IaC導入のデメリットは主に下記の２つになると思います。
-
- IaCスキルが必要
- （1か所の変更などの）簡単な設定変更でもある程度の時間がかかる
- IaCスキルが必要
ここがIaC導入の一番ネックになる部分です。
逆に言うとスキルを身につけた後はデメリットはほとんどないということです。
IaCスキルが重たいかというとそこまで重たくはなく、
AWSスキルが身についていればつまずくことは少ないです。
（AWSスキルがないと大変かもしれません。。） - （1か所の変更などの）簡単な設定変更でもある程度の時間がかかる
軽い設定変更でも
コード変更→gitマージ→環境反映
の一連の流れを行う必要があります。
心理的に手動でやりたくなってしまいますが、
リリースの自動化まで実現できればこのデメリットは解消します。
実質的にはデメリットはないと考えてよいと思っています。
AWSのIaC案件に入るための基礎知識
ここからはIaCに必要な知識（下記の6点）についてみていきます。
主に開発関連の知識です。
- Gitの理解
- 機密情報管理
- 代表的なIaCツールの把握
- 開発環境整備
- コーディング規約
- 手動設定の禁止
インフラエンジニアはプログラムが苦手な方が多い印象です。
（多分ですが、、）プログラミングが自分の専門領域でなないと思っているからだと思います。
※私自身も「JAVAは詳しくないので・・・」が口癖になっています。
ただIaC案件で求められる開発スキルはそれほど多くありません。
AWSの基本的な理解には半年程度のAWS経験が必要ですが、
IaCは１～2週間程度で運用を回せる程度になれると思います。
Gitの理解
IaC案件ではGitの利用がほぼ必須になります。
開発と縁が薄いインフラエンジニアにとって、Gitはハマりポイントなので、
少しでも理解しておきましょう。
Gitの資料はミクシィの新卒向け資料が無料公開されています。
おすすめです。
実際に利用するサービスはGitHubやAWS CodeCommitになると思います。
機密情報管理
プログラムはGitで管理しますが、AWS認証情報やパスワード情報などの機密情報はGitで管理するべきではありません。（認証情報を記載したファイルはgitignoreに登録してGit管理対象外にします。）
GitHubでもプライベートリポジトリとしてしまえば管理しても問題ない気もするのですが、簡単に公開できてしまうことからリスクはあるものと捉えるべきかなと思います。
2021年に起きたSMBCのソースコード流出は大きな話題になり、記憶に新しいですね。
ここでも機密情報が含まれていなかったから「顧客情報の流出には影響がない」「単独では悪影響を与えるものでない」と説明ができています。
ではどこで機密情報を管理するのかですが、AWSには機密情報を管理するためのサービスが存在します。
AWS Systems Manager Parameter Store
AWS Systems ManagerというサービスのParameter Storeという機能で機密情報の管理ができます。
Parameter Storeはパラメータを管理する機能ですが、機密情報の管理にも利用できます。
プログラム内にパスワードをべた書きするのではなく、パラメータストアを参照するという形にすることで、Gitに機密情報が含まれないようにします。
AWS Secrets Manager
AWS Secrets Managerはその名の通り、機密情報を管理するためのサービスです。
私は利用したことが無いのですが、資格情報を自動的に更新、ローテーションすることができるのは便利だと感じます。
代表的なIaCツールの把握
代表的なIaCツールを紹介します。こんなものがあるんだ程度で把握しておきましょう。
AWS層のコード化とOS・ミドル層のコード化は
扱うツールが異なるため、分けて紹介します。
AWS層のコード化ツール
AWS層のコード化ツールは以下の３つがあります。
AWS構築に利用可能なIaCツール
| ツール | 評価 | 概要 | テストツール | 備考 |
| Terraform | ◎ | HCLという専用言語でコードを記載する。AWS以外（GCPやAzure）でも利用可能。 | Terratest | ステートファイルの（※）考慮に気を遣う ※構築したリソースの状態が記録されるTerraformファイル |
| CDK | ◎ | Terraformより後発のAWS純正ツール。PythonやJAVAなどの一般的なプログラムでコードが書ける。 | 各プログラムのテストライブラリ（JAVAならJUnitなど） | CloudFormationをラッピングしたもの（裏でCloudFormationコードを出力している） |
| CloudFormation | 〇 | AWSが提供するIaCサービス。jsonかyamlで記載ができるので、敷居は低め。 | cfn-nag、CloudFormation Guard | json、yamlはプログラムに比べると可読性が低い（For文やIF文が使えない） |
TerraformかCDKの2択だと思っています。Terraformの方が主流でCDKはこれから伸びるかもといった印象です。（どちらのツールも素晴らしいです）
個人的にはプログラムで書けるCDKの方がPythonなどのプログラミングスキルを得られるという観点では良いかなと思っています。
CloudFormationでIaC運用している現場では裏で勝手にCDK活用していました。
CloudFormationはコーディング環境の用意が必須ではないので、簡単に始められます。IaC範囲が小さく、更新頻度も少なめであれば選択肢として考えても良いと思います。
AWS層のテストツールは有効活用したことないのですが、参考までに載せました。（要調査です。。）
OS・ミドル層のコード化ツール
OS・ミドル層のコード化ツールは以下の２つがあります。
OS・ミドルウェア構築に利用可能なIaCツール
| ツール | 評価 | 概要 | テストツール | 備考 |
| Ansible | ◎ | 導入の敷居が低い（エージェントレス） YAMLで記載するため、複雑な処理は苦手 | ServerSpec | 2015年にRed Hatに買収された |
| Chef | △ | 管理対象全てにエージェントが必要になるため、導入の敷居は高く、運用も煩雑化しがち。 RubyやChef独自言語の知識が必要になる。 | ServerSpec | Ansible登場前は主流だったが、Ansibleにシェアを奪われた |
OS・ミドル層のIaCツールはAnsible一択で良いのではないかと思っています。
下記の記事によるとChefがAnsibleに勝っている指標は無いようです。
Ansibleを買収したRed Hatのコメントでも「構成自動化ツールにはChefやPuppetもある。どちらも素晴らしい技術だが、私はAnsibleが新世代の技術だと考えている。」と記載があります。
IaCツールのバージョン管理について
どのIaCツール（CloudFormationはツールレス）にも言えることですが、ツールのバージョン固定は必須になると考えています。
IaCツールのバージョンアップ影響が読めないからです。
複数人で開発する場合、全員のツールバージョンを一致させておく必要があるので、自動アップデートされないよう注意します。
開発環境整備
シェルスクリプト作成はサクラエディタでも問題なかったですが、
IaCでプログラム開発を行うのであれば、開発専用のエディタを利用することで、
開発効率がかなり違ってきます。
利用するエディタは現場でルールが決められている場合も多いですが、
私のお勧めするエディタはVSCodeです。
おすすめ設定も参考までに貼っておきます。
慣れてきたら徐々に使い倒していく感じでも良いかと思います。
ドットインストールのVisual Studio Code入門も分かりやすかったです。（無料枠で見れます。）
コーディング規約
コーディング規約は変数名やコメントのルールが記載されているものです。
リファクタリングの著者Martin Fowlerが
「コンパイラがわかるコードは誰にでも書ける。すぐれたプログラマは人間にとってわかりやすいコードを書く」
と言っていたそうです。
■コーディング規約の目的
- ソフトウェアメンテナンスにおける、可読性・保守性・拡張性の向上
- 問題を起こしやすい実装を未然に回避することによる、品質・生産性の向上
- 標準規約を通して得られる一般的な実装知識やノウハウ（＝学習効果）
コーディング規約は開発案件であれば必ずあると思っていますが、
IaC案件始めたばかりの現場ではないこともあるかもしれません。
もし無ければ作ってもらうか自分で作りましょう。
コーディングルールは言語ごとに定められているものもありましたので、
参考までに見ておいても良いかもしれません。
・Python（pep8）
・JAVA（Future Enterprise Coding Standards）
・SQL
・コメントルール（参考）
手動設定の禁止
IaC化した案件では手動設定が禁止になります。
（今のところ、全ての案件でそうなっています。）
手動設定を許可してしまうと冒頭に記載したIaCのメリットの大半が成り立たなくなるからです。
ただ試験時のセキュリティグループのルール変更（1行）などは手動で行いたくなる気持ちは分かります。
（後で元に戻せば良いやと思って、、戻し忘れます。。）
コードと実機の設定がずれてしまうことをドリフトと言いますが、
IaCツールにはドリフト検知する機能が備わっていることが多いです。
IaC案件ではルール準拠と検知の仕組みを用いて、
ドリフトしないよう運用していくことが必須になると思います。
IaCを扱えるAWSエンジニアの価値
IaCを扱えるAWSエンジニアは希少です。
上記を見るとAWS経験があれば高単価であることが分かります。
マイクロサービス、IaC、DevOps、コンテナなどのトレンド技術が
できるとさらに単価が上がることも分かります。
高単価を目指すなら少しずつでも新しい技術を追うと効率が良いのですが、
IaCスキルもその一つです。
まとめ
IaC案件に必要な知識を列挙する形で紹介してきました。
個人的にIaCの最大のメリットは楽しいことなんじゃないかなと思っています。
新しいことを覚えることは大変ですが、楽しみながらスキルアップしてもらえたらと思います。
案件の自動化範囲によっては他にも紹介したい知識はありますが、
長くなってしまったので、別記事で紹介できたらと思います。
参考
Infrastructure as Code 談議 2022
TerraformかCloudFormationか？失敗例コミでIaCを語る！GUIからの卒業 #AKIBAAWS ONLINE #03
[DevAx::connect番外編] CDK実践勉強会の資料およびQ&A公開
I-2 : 「それ、どこに出しても恥ずかしくないTerraformコードになってるか？」
コメント