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. なぜ「Infrastructure as Code」が必要なのか
    NRIネットコム株式会社 上野 史瑛
    2021年1月24日

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. 4
    はじめに

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. 21
    IaCが解決する課題

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  27. 26
    課題の解決 ②人のミスを減らす
    構築
    Template
    開発環境
    本番環境
    Stack
    Stack

    ◼ 同じテンプレートをベースとするため、環境間の差分やミスが発生しにくい
    ◼ VPCなど各種リソースは各環境同じになるように設計するのもポイント

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  32. 31
    CloudFormationの始め方

    View Slide

  33. 32
    IaCは難しいのか
    CloudFormationは難しいのか?
    ⇒人による

    View Slide

  34. 33
    IaCは難しいのか
    CloudFormationは難しいのか?
    ⇒人による
    AWS環境を(理解して)手動管理していた人に
    CloudFormationは難しいのか?
    ⇒難しくない(はず)

    View Slide

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

    View Slide

  36. 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」
    ◼ テンプレートとして、設定値を書き起こす

    View Slide

  37. 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」
    ◼ テンプレートとして、設定値を書き起こす
    ◼ コメントも残せる
    ⇒どちらも書く内容は大きく変わらない、設定内容の理解が大事

    View Slide

  38. 37
    CloudFormationのポイント

    View Slide

  39. 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

    View Slide

  40. 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

    View Slide

  41. 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
    (手動承認)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. 45
    まとめ

    View Slide

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

    View Slide

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

    View Slide