Upgrade to Pro — share decks privately, control downloads, hide ads and more …

なぜ「Infrastructure as Code」が必要なのか

fumiakiueno
January 24, 2021

なぜ「Infrastructure as Code」が必要なのか

「July Tech Festa 2021 winter」で発表した資料です

https://techfesta.connpass.com/event/193966/

fumiakiueno

January 24, 2021
Tweet

More Decks by fumiakiueno

Other Decks in Technology

Transcript

  1. 1 自己紹介 名前: 上野 史瑛(うえの ふみあき) 所属: NRIネットコム株式会社 経歴: ・各種Webシステムのインフラ構築・運用

    - サーバ、ネットワーク管理や構築がメイン - PCIDSS取得対応等にも参画 - オンプレとAWSの両方を経験 ・AWS最適化プロジェクトに参画 ・AWS技術検証や構成レビュー ・2020 APN Ambassadors ・2020 APN AWS Top Engineers ・2020 APN ALL AWS Certifications Engineer @fu3ak1
  2. 8 仮想マシン データベース、ストレージ ネットワーク インフラ(Infrastructure)とは? クラウド環境 サーバ・OS ネットワーク 機器 データベース、

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

    ストレージ オンプレミス 本講演でのインフラの対象 ◼ クラウド環境の構成設定、各サービス内の設定 ◼ オンプレミス環境の物理機器構成、機器内の設定 その他 機器 その他クラウドリソース IaCが活用しやすいところ ⇒クラウド標準のAPIがあり、IaCツールも多い
  4. 11 インフラの手動管理の流れ 1. 設計 - 全体構成や方針を決定する方式設計 - 各機器やサービスの詳細設定を決定する詳細(パラメータ)設計 2. 構築

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

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

    - 機器への設定投入、クラウドサービスの作成、設定 3. テスト - 設計内容の動作確認 方式設計 方式設計書 構築 詳細、 パラメータテスト インフラ総合 テスト テストケース テストケース 詳細、 パラメータ設計 (+構築手順) 詳細設計書 パラメータシート IaCが活用しやすいところ ⇒考え方や方式ではなく実際の設定部分
  7. 16 手動管理の課題 ①構築、テストの手間がかかる 構築 開発環境 ステージング環境 本番環境 詳細、 パラメータテスト テストケース

    パラメータシート⇔実環境パラメータ の突合せ確認 ◼ 想定したパラメータ(=パラメータシート)になっているかテストを行う
  8. 17 手動管理の課題 ②人間はミスをする 構築 開発環境 本番環境 Bucket 暗号化:有効 Bucket 暗号化:無効

    詳細、 パラメータテスト テストケース テストでミス発見 ◼ 手作業のため、必ずどこかに設定ミスが見つかる ◼ 設定ミスは、頑張ってテストで見つける(大変)
  9. 18 手動管理の課題 ③実環境の設定がわからない 構築 本番環境 ①障害が発生し、緊急修正対応 詳細、 パラメータ設計 (+構築手順) 詳細設計書

    パラメータシート ②設計書への反映を忘れる ③差分発生 ④誰も信じられないドキュメント 1. 構築もしくは運用中に問題が発生し、急遽実環境の設定修正を行う 2. 設定を終えて満足し、設計書の反映を忘れる 3. 実環境と設計書に差分が起きる 4. 設計書が信じられない、以後の設定変更に影響を与える
  10. 19 手動管理の課題 ④誰が、いつ変えたのかわからない(履歴管理) 方式設計 方式設計書 詳細、 パラメータ設計 (+構築手順) 詳細設計書 パラメータシート

    変更日 変更者 コミットメッセージ 2021/1/10 担当A ファイアウォール変更 2021/1/12 担当B サーバー追加 変更履歴をドキュメントにつける。 が、正しく運用されないことも多い ◼ ドキュメント管理を細かく行い、履歴管理を行う ◼ 担当者によって記載粒度も変わったり、そもそも履歴が残らない場合も多い
  11. 22 前提とするIaC - AWS CloudFormation ◼ AWSが提供するIaCフレームワーク ◼ YAMLまたはJSON形式で記載 ◼

    AWS純正のため、AWSのIaCとして始めやすい ◼ 本講演は以下を対象に説明 ⚫ IaC ⇒ CloudFormation ⚫ 環境 ⇒ AWS
  12. 25 コードテスト 課題の解決 ①構築、テストの手間を減らす 構築 開発環境 ステージング環境 本番環境 Template Stack

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

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

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

    または Gitリポジトリ CodePipeline CodePipeline ◼ リポジトリ管理+パイプラインリリースにしおくことで、 リポジトリ内のテンプレート=実環境設定という状態を維持できる ◼ 設定を確認するために、実環境へのアクセスが不要 テンプレートを見れば設定がわかる
  16. 29 課題の解決 ④変更履歴がわかる 構築 Template CodeCommit または Gitリポジトリ ◼ テンプレートをGitリポジトリにすることで、強制的に履歴が残る

    ◼ いつ、だれが、どう変更したのか閲覧しやすい 変更日 変更者 コミットメッセージ 2021/1/10 担当A ファイアウォール変更 2021/1/12 担当B サーバー追加 Gitの機能として強制的に履歴が残る
  17. 34 パラメータシートとCloudFormation 項目 設定値 補足 CIDR 10.0.0.0/16 テナンシー デフォルト デフォルトor専有

    DNS解決 有効 DNSホスト名 有効 Nameタグ dev-sys-vpc [環境]-[システム名]-vpc パラメータシートの例(VPC) 「パラメータシート」 ◼ エクセル等の資料で設定値を書き起こす ◼ 補足や設定根拠をコメントとして残す
  18. 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」 ◼ テンプレートとして、設定値を書き起こす
  19. 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」 ◼ テンプレートとして、設定値を書き起こす ◼ コメントも残せる ⇒どちらも書く内容は大きく変わらない、設定内容の理解が大事
  20. 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
  21. 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
  22. 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 (手動承認)
  23. 42 CloudFormationのテストツール ◼ 「cfn-nag」 ⚫ テンプレートの内容からセキュリティ的に問題がある部分を見つけ出して警告できる ⚫ たとえばセキュリティグループの公開、IAMの*許可など ◼ 「cfn-python-lint」

    ⚫ デプロイ実行時にエラーとなるような文法、パラメータミスをチェックできる ◼ 「TaskCat」 ⚫ 実際にテンプレートのデプロイを行い、実行エラーにならないかチェックできる ⚫ 実行後はすぐに削除されるため、余計なものが残らない ⚫ CloudFormationと同じくYAML形式でパラメータ、実行リージョンを指定する
  24. 43 AWS環境のパラメータチェックツール ◼ 「AWS CLI」 ⚫ AWS標準のコマンドラインツール ⚫ 処理を1つ1つ書くので、シェルで壮大なスクリプトが必要になることも ⚫

    テスト目的で作られている訳ではない ◼ 「AWS SDK」 ⚫ Python、Java、PHPといった開発言語でAWS環境へアクセスできる ⚫ 慣れた言語であれば使いやすい ⚫ テスト目的で作られている訳ではない ◼ 「awspec」 ⚫ AWS上のリソース状態をテストできるツール ⚫ サーバテストツールのServerspec同様の使い方となる ⚫ テスト目的で作られている
  25. 44 パラメータチェックは必要なのか? ◼ CloudFormation=設定 as Codeになるため、テンプレートと実環境は同じである ◼ 実環境のパラメータを見ていくよりも、テンプレートを見ることに時間をかけて品質 UPを目指すほうが良いかもしれない Template

    本番環境 Stack 構築 確認 テスト ツール ◼ テンプレートとは別のテスト形式で確認をすることで品質UPという考え方もある ◼ 重要なパラメータ(SGやIPなど)だけチェックするということもできる ◼ テスト駆動開発のような手法もできる(チェックすべきパラメータを先に書く) ◼ 目視確認は極力減らすべき Template 本番環境 Stack 構築 確認 ⇒組織にあった最適な方法を!