なぜ「Infrastructure as Code」が必要なのか NRIネットコム株式会社 上野 史瑛 2021年1月24日

1 自己紹介 名前： 上野 史瑛（うえの ふみあき） 所属： NRIネットコム株式会社 経歴： ・各種Webシステムのインフラ構築・運用 - サーバ、ネットワーク管理や構築がメイン - PCIDSS取得対応等にも参画 - オンプレとAWSの両方を経験 ・AWS最適化プロジェクトに参画 ・AWS技術検証や構成レビュー ・2020 APN Ambassadors ・2020 APN AWS Top Engineers ・2020 APN ALL AWS Certifications Engineer @fu3ak1

2 会社紹介 WEBシステムを中心にソリューションを提供しています

3 会社紹介 AWSは特に力をいれて頑張っています ・資格取得数100 ・モバイルコンピテンシー取得 AWSでご相談があればご連絡ください →「NRIネットコム 問い合わせ」で検索

4 はじめに

5 本講演の対象者 ◼ クラウド環境を管理しているインフラエンジニア ◼ インフラの手動管理を行っている方 ◼ Infrastructure as Code（IaC）を始めたい方、初心者の方

6 本講演の目的 IaCの必要性を理解し、未経験、初心者の方に IaCを始めるきっかけにしてもらう ◼ お話すること ⚫ インフラ手動管理の方法やそこにある課題 ⚫ IaCが解決する課題 ⚫ AWS CloudFormationを使用したIaCの例、始め方 ◼ お話しないこと ⚫ IaCの詳細な書き方、高度な活用方法

7 IaCを使わない手動インフラ管理

8 仮想マシン データベース、ストレージ ネットワーク インフラ（Infrastructure）とは？ クラウド環境 サーバ・OS ネットワーク 機器 データベース、 ストレージ オンプレミス 本講演でのインフラの対象 ◼ クラウド環境の構成設定、各サービス内の設定 ◼ オンプレミス環境の物理機器構成、機器内の設定 その他 機器 その他クラウドリソース

9 仮想マシン データベース、ストレージ ネットワーク インフラ（Infrastructure）とは？ クラウド環境 サーバ・OS ネットワーク 機器 データベース、 ストレージ オンプレミス 本講演でのインフラの対象 ◼ クラウド環境の構成設定、各サービス内の設定 ◼ オンプレミス環境の物理機器構成、機器内の設定 その他 機器 その他クラウドリソース IaCが活用しやすいところ ⇒クラウド標準のAPIがあり、IaCツールも多い

10 インフラの手動管理の流れ 1. 設計 - 全体構成や方針を決定する方式設計 - 各機器やサービスの詳細設定を決定する詳細（パラメータ）設計 方式設計 詳細、 パラメータ設計 （＋構築手順） 方式設計書 詳細設計書 パラメータシート

11 インフラの手動管理の流れ 1. 設計 - 全体構成や方針を決定する方式設計 - 各機器やサービスの詳細設定を決定する詳細（パラメータ）設計 2. 構築 - 機器への設定投入、クラウドサービスの作成、設定 方式設計 方式設計書 構築 詳細、 パラメータ設計 （＋構築手順） 詳細設計書 パラメータシート

12 インフラの手動管理の流れ 1. 設計 - 全体構成や方針を決定する方式設計 - 各機器やサービスの詳細設定を決定する詳細（パラメータ）設計 2. 構築 - 機器への設定投入、クラウドサービスの作成、設定 3. テスト - 設計内容の動作確認 方式設計 方式設計書 構築 詳細、 パラメータテスト インフラ総合 テスト テストケース テストケース 詳細、 パラメータ設計 （＋構築手順） 詳細設計書 パラメータシート

13 インフラの手動管理の流れ 1. 設計 - 全体構成や方針を決定する方式設計 - 各機器やサービスの詳細設定を決定する詳細（パラメータ）設計 2. 構築 - 機器への設定投入、クラウドサービスの作成、設定 3. テスト - 設計内容の動作確認 方式設計 方式設計書 構築 詳細、 パラメータテスト インフラ総合 テスト テストケース テストケース 詳細、 パラメータ設計 （＋構築手順） 詳細設計書 パラメータシート IaCが活用しやすいところ ⇒考え方や方式ではなく実際の設定部分

14 手動管理で発生する課題

15 手動管理の課題 ①構築、テストの手間がかかる 構築 開発環境 ステージング環境 本番環境 ◼ 本番、ステージング、環境と3環境あった場合は3回同じ構築作業を行う ◼ 急な環境追加にも対応しにくい

16 手動管理の課題 ①構築、テストの手間がかかる 構築 開発環境 ステージング環境 本番環境 詳細、 パラメータテスト テストケース パラメータシート⇔実環境パラメータ の突合せ確認 ◼ 想定したパラメータ（＝パラメータシート）になっているかテストを行う

17 手動管理の課題 ②人間はミスをする 構築 開発環境 本番環境 Bucket 暗号化：有効 Bucket 暗号化：無効 詳細、 パラメータテスト テストケース テストでミス発見 ◼ 手作業のため、必ずどこかに設定ミスが見つかる ◼ 設定ミスは、頑張ってテストで見つける（大変）

18 手動管理の課題 ③実環境の設定がわからない 構築 本番環境 ①障害が発生し、緊急修正対応 詳細、 パラメータ設計 （＋構築手順） 詳細設計書 パラメータシート ②設計書への反映を忘れる ③差分発生 ④誰も信じられないドキュメント 1. 構築もしくは運用中に問題が発生し、急遽実環境の設定修正を行う 2. 設定を終えて満足し、設計書の反映を忘れる 3. 実環境と設計書に差分が起きる 4. 設計書が信じられない、以後の設定変更に影響を与える

19 手動管理の課題 ④誰が、いつ変えたのかわからない（履歴管理） 方式設計 方式設計書 詳細、 パラメータ設計 （＋構築手順） 詳細設計書 パラメータシート 変更日 変更者 コミットメッセージ 2021/1/10 担当A ファイアウォール変更 2021/1/12 担当B サーバー追加 変更履歴をドキュメントにつける。 が、正しく運用されないことも多い ◼ ドキュメント管理を細かく行い、履歴管理を行う ◼ 担当者によって記載粒度も変わったり、そもそも履歴が残らない場合も多い

20 手動管理の課題 まとめ ①構築、テストの手間がかかる ②人間はミスをする ③実環境の設定がわからない ④誰が、いつ変えたのか履歴がわからない

21 IaCが解決する課題

22 前提とするIaC - AWS CloudFormation ◼ AWSが提供するIaCフレームワーク ◼ YAMLまたはJSON形式で記載 ◼ AWS純正のため、AWSのIaCとして始めやすい ◼ 本講演は以下を対象に説明 ⚫ IaC ⇒ CloudFormation ⚫ 環境 ⇒ AWS

23 課題の解決 ①構築、テストの手間を減らす 1. 構築＝テンプレートを書くこと 構築 Template

24 課題の解決 ①構築、テストの手間を減らす 1. 構築＝テンプレートを書くこと 2. テンプレートができたら各環境にデプロイするのみ （環境ごとの差分はパラメータとして渡す） ENV=dev PARAM:ENV 構築 開発環境 ステージング環境 本番環境 Template Stack Stack Stack ENV=stg ENV=prd

25 コードテスト 課題の解決 ①構築、テストの手間を減らす 構築 開発環境 ステージング環境 本番環境 Template Stack Stack Stack 詳細、 パラメータテスト テストケース パラメータ確認も可能 テストツール アプリケーション同様にコードテストが可能 ◼ コードベースとなるため、アプリケーション同様のテスト手法が可能 ◼ 文法チェック、セキュリティチェックなど ◼ パラメータチェックも可能 ENV=dev PARAM:ENV ENV=stg ENV=prd

26 課題の解決 ②人のミスを減らす 構築 Template 開発環境 本番環境 Stack Stack ＝ ◼ 同じテンプレートをベースとするため、環境間の差分やミスが発生しにくい ◼ VPCなど各種リソースは各環境同じになるように設計するのもポイント

27 課題の解決 ②人のミスを減らす 構築 Template 開発環境 本番環境 Stack Stack CodeCommit または Gitリポジトリ CodePipeline CodePipeline ◼ 人のミスをさらに減らすにはパイプラインからコマンドを実行するほうが良い ◼ 実行時に渡すパラメータや、対象環境のミスを防ぎやすい

28 課題の解決 ③実環境の設定がわかる 構築 Template 開発環境 本番環境 Stack Stack CodeCommit または Gitリポジトリ CodePipeline CodePipeline ◼ リポジトリ管理＋パイプラインリリースにしおくことで、 リポジトリ内のテンプレート＝実環境設定という状態を維持できる ◼ 設定を確認するために、実環境へのアクセスが不要 テンプレートを見れば設定がわかる

29 課題の解決 ④変更履歴がわかる 構築 Template CodeCommit または Gitリポジトリ ◼ テンプレートをGitリポジトリにすることで、強制的に履歴が残る ◼ いつ、だれが、どう変更したのか閲覧しやすい 変更日 変更者 コミットメッセージ 2021/1/10 担当A ファイアウォール変更 2021/1/12 担当B サーバー追加 Gitの機能として強制的に履歴が残る

30 課題の解決 まとめ ①構築、テストの手間がかかる ⇒1テンプレートの構築で複数環境分を構築でき、手間が減る ⇒コードテストで一部テストの自動化もできる ②人間はミスをする ⇒テンプレートベースで環境間の差分を無くす ⇒環境への展開もパイプライン＋コマンドで人が実施しない ③実環境の設定がわからない ⇒Gitリポジトリベースとし、テンプレート＝実環境設定を維持 ④誰が、いつ変えたのかわからない ⇒Gitリポジトリで強制的に履歴管理

31 CloudFormationの始め方

32 IaCは難しいのか CloudFormationは難しいのか？ ⇒人による

33 IaCは難しいのか CloudFormationは難しいのか？ ⇒人による AWS環境を（理解して）手動管理していた人に CloudFormationは難しいのか？ ⇒難しくない（はず）

34 パラメータシートとCloudFormation 項目 設定値 補足 CIDR 10.0.0.0/16 テナンシー デフォルト デフォルトor専有 DNS解決 有効 DNSホスト名 有効 Nameタグ dev-sys-vpc [環境]-[システム名]-vpc パラメータシートの例（VPC) 「パラメータシート」 ◼ エクセル等の資料で設定値を書き起こす ◼ 補足や設定根拠をコメントとして残す

35 パラメータシートとCloudFormation 項目 設定値 補足 CIDR 10.0.0.0/16 テナンシー デフォルト デフォルトor専有 DNS解決 有効 DNSホスト名 有効 Nameタグ dev-sys-vpc [環境]-[システム名]-vpc パラメータシートの例（VPC) vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: "10.0.0.0/16" InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: "dev-sys-vpc" CloudFormationの例（VPC) ① ① ② ② ③ ④ ③ ④ ⑤ ⑤ 「パラメータシート」 ◼ エクセル等の資料で設定値を書き起こす ◼ 補足や設定根拠をコメントとして残す 「CloudFormation」 ◼ テンプレートとして、設定値を書き起こす

36 パラメータシートとCloudFormation 項目 設定値 補足 CIDR 10.0.0.0/16 テナンシー デフォルト デフォルトor専有 DNS解決 有効 DNSホスト名 有効 Nameタグ dev-sys-vpc [環境]-[システム名]-vpc パラメータシートの例（VPC) vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: "10.0.0.0/16" ## デフォルトor専有 InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name ## [環境]-[システム名]-vpc Value: "dev-sys-vpc" CloudFormationの例（VPC) ① ① ② ② ③ ④ ③ ④ ⑤ ⑤ ⑥ ⑦ ⑥ ⑦ 「パラメータシート」 ◼ エクセル等の資料で設定値を書き起こす ◼ 補足や設定根拠をコメントとして残す 「CloudFormation」 ◼ テンプレートとして、設定値を書き起こす ◼ コメントも残せる ⇒どちらも書く内容は大きく変わらない、設定内容の理解が大事

37 CloudFormationのポイント

38 環境ごとに変わる値はParametersを使用 Resources: vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: "10.0.0.0/16" InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: "dev-sys-vpc" ◼ 開発、本番など環境ごとに変わる値をParametersで別出し ◼ Parametersで設定した値を、AWSリソースを定義するResourcesで取得 ◼ パラメータは各環境のデプロイ時に渡せる Parameters: Env: Description: "Environment" Type: String Default: "dev" VpcCidr: Description: "VPC CIDR" Type: String Default: "10.0.0.0/16" Resources: vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: !Ref VpcCidr InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${Env}-sys-vpc" そのまま使用するRef 値の一部として使用するSub 開発環境 本番環境 Template Stack Stack PARAM:ENV ENV=dev ENV=prd

39 テンプレートの分割 ◼ 1システム1つのテンプレートだと、大規模テンプレートになり、メンテナンスが難しい ◼ システム全体に影響を与える可能性もある ◼ そこでライフサイクル別（変更頻度）にテンプレートを分割 ◼ 参照すべきリソースがあれば、Output＋ImportValueを使用 （他にも参照方法はいくつかある） VPC Template Security group Template 参照 Outputs: vpc: Value: !Ref vpc Export: Name: vpc Resources: SecuritygroupEC2: Type: "AWS::EC2::SecurityGroup" Properties: GroupName: !Sub "${Env}-ec2-sg" GroupDescription: "for EC2" VpcId: !ImportValue vpc

40 パイプラインを使用した本番運用 ◼ 人の手作業ミスから離れるために、CloudFormation実行をパイプライン経由にする ◼ テストやデプロイ前の確認機能など、本番運用を想定した機能もある 「IaCのパイプライン例」 Source Test Deploy CodePipeline CodeCommitGithub CodeBuild Lambda AWS Cloud VPC Template Template Lint,SecurityCheck Test Stack CodeDeploy 使用 サービス 対象 リソース Pre Deploy CodeBuild Change set Approve Stack （手動承認）

41 Change Sets ◼ 環境へデプロイする前に変更内容を表示してくれる機能 ◼ CloudFormationスタックの変更は、ミスすると危険、意図しない変更もある ◼ 本番環境など影響のある環境はChange Setsの内容を確認後に反映することを推奨 Template Change set Stack 本番環境 VPC subnet 変更内容： SecurityGroup A⇒変更 IAM Role B⇒削除 IAM Role A⇒新規作成

42 CloudFormationのテストツール ◼ 「cfn-nag」 ⚫ テンプレートの内容からセキュリティ的に問題がある部分を見つけ出して警告できる ⚫ たとえばセキュリティグループの公開、IAMの*許可など ◼ 「cfn-python-lint」 ⚫ デプロイ実行時にエラーとなるような文法、パラメータミスをチェックできる ◼ 「TaskCat」 ⚫ 実際にテンプレートのデプロイを行い、実行エラーにならないかチェックできる ⚫ 実行後はすぐに削除されるため、余計なものが残らない ⚫ CloudFormationと同じくYAML形式でパラメータ、実行リージョンを指定する

43 AWS環境のパラメータチェックツール ◼ 「AWS CLI」 ⚫ AWS標準のコマンドラインツール ⚫ 処理を1つ1つ書くので、シェルで壮大なスクリプトが必要になることも ⚫ テスト目的で作られている訳ではない ◼ 「AWS SDK」 ⚫ Python、Java、PHPといった開発言語でAWS環境へアクセスできる ⚫ 慣れた言語であれば使いやすい ⚫ テスト目的で作られている訳ではない ◼ 「awspec」 ⚫ AWS上のリソース状態をテストできるツール ⚫ サーバテストツールのServerspec同様の使い方となる ⚫ テスト目的で作られている

44 パラメータチェックは必要なのか？ ◼ CloudFormation＝設定 as Codeになるため、テンプレートと実環境は同じである ◼ 実環境のパラメータを見ていくよりも、テンプレートを見ることに時間をかけて品質 UPを目指すほうが良いかもしれない Template 本番環境 Stack 構築 確認 テスト ツール ◼ テンプレートとは別のテスト形式で確認をすることで品質UPという考え方もある ◼ 重要なパラメータ（SGやIPなど）だけチェックするということもできる ◼ テスト駆動開発のような手法もできる（チェックすべきパラメータを先に書く） ◼ 目視確認は極力減らすべき Template 本番環境 Stack 構築 確認 ⇒組織にあった最適な方法を！

45 まとめ

46 まとめ ◼ 手動管理はヒューマンエラーによるミスや課題が起きる ◼ IaCはその課題の一部を解決する ◼ CloudFormationはAWSのIaC第一歩に最適 ◼ 初期構築だけではなく運用にも活かして人の手から離れていこう

47 ありがとうございました