「July Tech Festa 2021 winter」で発表した資料です
https://techfesta.connpass.com/event/193966/
なぜ「Infrastructure as Code」が必要なのかNRIネットコム株式会社 上野 史瑛2021年1月24日
View Slide
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の詳細な書き方、高度な活用方法
7IaCを使わない手動インフラ管理
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手動管理の課題 まとめ①構築、テストの手間がかかる②人間はミスをする③実環境の設定がわからない④誰が、いつ変えたのか履歴がわからない
21IaCが解決する課題
22前提とするIaC - AWS CloudFormation◼ AWSが提供するIaCフレームワーク◼ YAMLまたはJSON形式で記載◼ AWS純正のため、AWSのIaCとして始めやすい◼ 本講演は以下を対象に説明⚫ IaC ⇒ CloudFormation⚫ 環境 ⇒ AWS
23課題の解決 ①構築、テストの手間を減らす1. 構築＝テンプレートを書くこと構築Template
24課題の解決 ①構築、テストの手間を減らす1. 構築＝テンプレートを書くこと2. テンプレートができたら各環境にデプロイするのみ（環境ごとの差分はパラメータとして渡す）ENV=devPARAM:ENV構築開発環境ステージング環境本番環境TemplateStackStackStackENV=stgENV=prd
25コードテスト課題の解決 ①構築、テストの手間を減らす構築開発環境ステージング環境本番環境TemplateStackStackStack詳細、パラメータテストテストケースパラメータ確認も可能テストツールアプリケーション同様にコードテストが可能◼ コードベースとなるため、アプリケーション同様のテスト手法が可能◼ 文法チェック、セキュリティチェックなど◼ パラメータチェックも可能ENV=devPARAM:ENVENV=stgENV=prd
26課題の解決 ②人のミスを減らす構築Template開発環境本番環境StackStack＝◼ 同じテンプレートをベースとするため、環境間の差分やミスが発生しにくい◼ VPCなど各種リソースは各環境同じになるように設計するのもポイント
27課題の解決 ②人のミスを減らす構築Template開発環境本番環境StackStackCodeCommitまたはGitリポジトリCodePipelineCodePipeline◼ 人のミスをさらに減らすにはパイプラインからコマンドを実行するほうが良い◼ 実行時に渡すパラメータや、対象環境のミスを防ぎやすい
28課題の解決 ③実環境の設定がわかる構築Template開発環境本番環境StackStackCodeCommitまたはGitリポジトリCodePipelineCodePipeline◼ リポジトリ管理＋パイプラインリリースにしおくことで、リポジトリ内のテンプレート＝実環境設定という状態を維持できる◼ 設定を確認するために、実環境へのアクセスが不要テンプレートを見れば設定がわかる
29課題の解決 ④変更履歴がわかる構築TemplateCodeCommitまたはGitリポジトリ◼ テンプレートをGitリポジトリにすることで、強制的に履歴が残る◼ いつ、だれが、どう変更したのか閲覧しやすい変更日 変更者 コミットメッセージ2021/1/10 担当A ファイアウォール変更2021/1/12 担当B サーバー追加Gitの機能として強制的に履歴が残る
30課題の解決 まとめ①構築、テストの手間がかかる⇒1テンプレートの構築で複数環境分を構築でき、手間が減る⇒コードテストで一部テストの自動化もできる②人間はミスをする⇒テンプレートベースで環境間の差分を無くす⇒環境への展開もパイプライン＋コマンドで人が実施しない③実環境の設定がわからない⇒Gitリポジトリベースとし、テンプレート＝実環境設定を維持④誰が、いつ変えたのかわからない⇒Gitリポジトリで強制的に履歴管理
31CloudFormationの始め方
32IaCは難しいのかCloudFormationは難しいのか？⇒人による
33IaCは難しいのか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: defaultEnableDnsSupport: trueEnableDnsHostnames: trueTags:- Key: NameValue: "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: defaultEnableDnsSupport: trueEnableDnsHostnames: trueTags:- Key: Name## [環境]-[システム名]-vpcValue: "dev-sys-vpc"CloudFormationの例（VPC)①①②②③④ ③④⑤⑤⑥⑦⑥⑦「パラメータシート」◼ エクセル等の資料で設定値を書き起こす◼ 補足や設定根拠をコメントとして残す「CloudFormation」◼ テンプレートとして、設定値を書き起こす◼ コメントも残せる⇒どちらも書く内容は大きく変わらない、設定内容の理解が大事
37CloudFormationのポイント
38環境ごとに変わる値はParametersを使用Resources:vpc:Type: "AWS::EC2::VPC"Properties:CidrBlock: "10.0.0.0/16"InstanceTenancy: defaultEnableDnsSupport: trueEnableDnsHostnames: trueTags:- Key: NameValue: "dev-sys-vpc"◼ 開発、本番など環境ごとに変わる値をParametersで別出し◼ Parametersで設定した値を、AWSリソースを定義するResourcesで取得◼ パラメータは各環境のデプロイ時に渡せるParameters:Env:Description: "Environment"Type: StringDefault: "dev"VpcCidr:Description: "VPC CIDR"Type: StringDefault: "10.0.0.0/16"Resources:vpc:Type: "AWS::EC2::VPC"Properties:CidrBlock: !Ref VpcCidrInstanceTenancy: defaultEnableDnsSupport: trueEnableDnsHostnames: trueTags:- Key: NameValue: !Sub "${Env}-sys-vpc"そのまま使用するRef値の一部として使用するSub開発環境本番環境TemplateStackStackPARAM:ENVENV=devENV=prd
39テンプレートの分割◼ 1システム1つのテンプレートだと、大規模テンプレートになり、メンテナンスが難しい◼ システム全体に影響を与える可能性もある◼ そこでライフサイクル別（変更頻度）にテンプレートを分割◼ 参照すべきリソースがあれば、Output＋ImportValueを使用（他にも参照方法はいくつかある）VPCTemplateSecurity groupTemplate参照Outputs:vpc:Value: !Ref vpcExport:Name: vpcResources:SecuritygroupEC2:Type: "AWS::EC2::SecurityGroup"Properties:GroupName: !Sub "${Env}-ec2-sg"GroupDescription: "for EC2"VpcId: !ImportValue vpc
40パイプラインを使用した本番運用◼ 人の手作業ミスから離れるために、CloudFormation実行をパイプライン経由にする◼ テストやデプロイ前の確認機能など、本番運用を想定した機能もある「IaCのパイプライン例」Source Test DeployCodePipelineCodeCommitGithub CodeBuild LambdaAWS CloudVPCTemplate TemplateLint,SecurityCheckTest StackCodeDeploy使用サービス対象リソースPreDeployCodeBuildChange setApproveStack（手動承認）
41Change Sets◼ 環境へデプロイする前に変更内容を表示してくれる機能◼ CloudFormationスタックの変更は、ミスすると危険、意図しない変更もある◼ 本番環境など影響のある環境はChange Setsの内容を確認後に反映することを推奨Template Change set Stack本番環境VPCsubnet変更内容：SecurityGroup A⇒変更IAM Role B⇒削除IAM Role A⇒新規作成
42CloudFormationのテストツール◼ 「cfn-nag」⚫ テンプレートの内容からセキュリティ的に問題がある部分を見つけ出して警告できる⚫ たとえばセキュリティグループの公開、IAMの*許可など◼ 「cfn-python-lint」⚫ デプロイ実行時にエラーとなるような文法、パラメータミスをチェックできる◼ 「TaskCat」⚫ 実際にテンプレートのデプロイを行い、実行エラーにならないかチェックできる⚫ 実行後はすぐに削除されるため、余計なものが残らない⚫ CloudFormationと同じくYAML形式でパラメータ、実行リージョンを指定する
43AWS環境のパラメータチェックツール◼ 「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ありがとうございました
fu3ak1
globis_gdp
yuya4
ks91
ohmori_yusuke
convto
irof
okada_fuutass
hakubishin3
okuzawats
oracle4engineer
yujisoftware
sachag
rasmusluckow
aki_iinuma
62gerente
caitiem20
myddelton
garrettdimon
bkeepers
geeforr
scottboms
reverentgeek
paulrobertlloyd