Infrastructure as Codeのはじめ方～NRIネットコム TECH AND DESIGN STUDY #93～

Infrastructure as Codeのはじめ方～NRIネットコム TECH AND DESIGN STUDY #93～ 2026年3月10日
NRIネットコム株式会社 Webインテグレーション事業部梅原航

1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 #nncstudy
転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 基本情報 ⚫ 梅原航（うめはらこう） ⚫ NRIネットコム株式会社 Webインテグレーション事業部（大阪） ⚫ AWSを使ったシステムのインフラ開発･運用に従事 ◼ 受賞歴 ⚫ 2024 Japan AWS Jr. Champion ⚫ 2025 Japan All AWS Certifications Engineer ◼ 好きなAWSサービス ◼ 本日お話すること ⚫ IaCをどのような流れで何を決めていくとよいか ⚫ IaCツールをCloudFormationとした場合の進め方 Amazon Elastic Container Service (Amazon ECS)

2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 1. Infrastructure
as Codeとは #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

as Codeとは ◼ Infrastructure as Code（IaC）とは ⚫ ソースコードを利用して、インフラストラクチャの管理を行うこと ⚫ インフラの構築や設定変更をソースコードから行う ◼ IaCを使わないときの管理方法 ⚫ 作業手順書を元にAWSコンソール上で作業を行う ◼ IaCを使うときの管理方法 ⚫ インフラの定義内容を記述したソースコードを元に、デプロイ指示を行うことで、自動で構築･設定変更される #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止しますデプロイ指示コンソール上で作業手順書 AWSリソース作業者 AWSリソース作業者ソースコード従来の管理方法 IaCの管理方法

as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

as Codeのはじめ方 ◼ いきなりIaCツールを選定するのではなく、順を追って進めていく #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します 1. 導入目的の洗い出し 2. 適用範囲の検討 3. Infrastructure as Codeツールの選定 4. Infrastructure as Codeツールの理解 5. 開発･運用ルールの策定 6. 開発 7. テスト 8. 実際の環境へデプロイ

6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.1. 導入目的の洗い出し
◼ IaCを導入することでどのような課題を解決したいかを洗い出す ⚫ 組織的な課題やプロジェクトの要件、運用上の課題などからその時の状況に合わせて目的を設定する ◼ IaCの一般的なメリット ⚫ 再現性 • 他プロジェクトへの流用や標準化、DR対策などが可能 ⚫ バージョン管理 • 誰が（who）いつ（when）何を（what）なぜ（why）変更したか追跡可能 ⚫ 属人性の排除 • ソースコードを読むだけでシステム構成の理解が可能 ⚫ 品質の向上 • 作業時のミスを無くすことができる ⚫ レビューの容易性 • ソースコードはあるべき姿が記載されているため、手順書と比較してレビューが容易 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.2. 適用範囲の検討
◼ 初めからリソース全てをIaC化できれば理想 ⚫ メンバーのスキルセットやプロジェクトの納期など、状況を見ながら最適な形で導入する ◼ 全てのリソースを0から100までコード化することが出来ない場合は、段階的に導入していく ⚫ 例: フェーズで段階的に分離開発フェーズは手動で構築→運用フェーズで徐々にコード化 ⚫ 例: リソースで段階的に導入ネットワーク･アプリケーションはコード化して、監視やCI/CDなどは後回しでコード化 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止しますネットワークサーバーアプリケーションデータベースセキュリティ監視 CI/CD どこまでIaC化していくか

8 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.3. Infrastructure
as Codeツールの選定 ◼ ツールの特性とIaC導入の目的やメンバーのスキルセット、顧客要望など状況を比較して決定する ⚫ ｢ただIaCを導入した｣にならないように、軸を持って選定理由を明確にしておく ◼ AWSリソースを構築するIaCツール ⚫ AWS CloudFormation/AWS Serverless Application Model（AWS SAM） • AWS製のIaCツール • テンプレートとしてインフラを定義し、スタックとしてデプロイされる • YAML/JSONでリソースのパラメータを定義して記述 ⚫ AWS Cloud Development Kit（AWS CDK） • OSS AWS製のIaCツール • Constructの概念が優秀 • TypeScript、JavaScript、Python、Java、C#、Goで記述 ⚫ Terraform • HashiCorp社が開発するIaCツール • AWSだけでなくGoogle CloudやCloudflareといった他プロバイダーも管理可能 • HCL (Hashicorp Configuration Language)で記述 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します AWS CDK AWS CloudFormation

as Codeツールの選定 ◼ トレンド的にはAWS CDKが採用されている印象 ◼ 特定のツールが絶対的な正解というのはないので、各々の状況に合わせて選択するべき ⚫ どんなスキルセットを持った人が開発するか ⚫ AWS以外もデプロイあるか ⚫ IaCを導入の目的は何か ◼ 全くの0からIaC化する場合はCloudFormationがおすすめ ⚫ YAML/JSONで記述可能 ⚫ AWS自体を理解しておけば学習コストはほとんどない（=開発時の負担軽減） ⚫ パラメータを書いているので、コードに馴染みがないメンバーでも理解可能 ⇒今後のスライドはCloudFormationを例とします。 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します対象はAWSだけか学習コスト再利用性可読性テストのしやすさステート管理 CloudFormation AWSのみ低い可能だが煩雑冗長になりがち難しい AWSが管理 CDK AWSのみ（インフラT目線）高い Constructで可能 Constructで簡略プログラミング言語のテストが可能 AWSが管理 Terraform 他プロバイダーも可能中程度 Moduleで可能直感的に理解可能 Terraform Testで可能 tfstateの管理が必要

as Codeツール（CloudFormation）の理解 ◼ AWS Black Belt Online Seminarやドキュメントなどで挙動や書き方を学習する ◼ 特に知ってほしいポイント ⚫ ①デプロイ時にはChangeSet（変更セット）を経由する • どのリソースに対して、どのような変更がされるかを事前確認可能 ⚫ ②データやステートを持つリソースにはリソース属性を定義する • DeletionPolicy → スタックを削除してもリソース保持 • UpdateReplacePolicy → リソース置換時に削除を行わない 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します Amazon S3 テンプレートリソーススタック削除してもリソースは保持

11 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.5. 開発･運用ルールの策定
◼ ①ファイル/スタックをどこまで分割するか ⚫ 一つのファイルに全てのリソースを記述すると可読性が低下 ⚫ どのリソースをどのファイルに記載するか（≒スタック分割をどうするか） ⚫ ライフサイクルで分割する • ネットワーク、データベース、アプリケーション、セキュリティ等々 • サービス単位で分割する ⚫ 環境単位でファイルを用意する • 1つのコードで全環境デプロイがベストプラクティスだが、環境差異でソースコードの可読性が落ちるなら環境単位でも分割 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します VPC Private subnet Public subnet Amazon Aurora Elastic Load Balancing ネットワークアプリケーションデータベース Amazon ECS

◼ ①ファイル/スタックをどこまで分割するか ◼ ②スタック間の情報連携方法 ⚫ 方法3つ • クロススタック参照（Outputs/ImportValue）で連携 • Parametersでデプロイ時に手動注入 • Parameter Store/Secrets Manager経由 ⚫ すべてがクロススタックがいいとは限らない 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します Amazon EC2 Amazon CloudWatch スタックA インスタンスIDを Output スタックB インスタンスIDを ImportValue 作業者 CloudWatch側スタックで参照しているためインスタンスID変更されるような変更やリソース削除が出来ない

◼ ①ファイル/スタックをどこまで分割するか ◼ ②スタック間の情報連携方法 ◼ ③環境差異の吸収方法 ⚫ ParametersやConditions、Mapping、AWS::NoValueなどを利用して吸収する 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します Amazon EC2（t3.micro）開発環境 Role Amazon EC2 （t3.medium）本番環境 EnvName=dev でデプロイ EnvName=prd でデプロイ

◼ ①ファイル/スタックをどこまで分割するか ◼ ②スタック間の情報連携方法 ◼ ③環境差異の吸収方法 ◼ ④デプロイ方法 ⚫ CloudFormationはデプロイの順番を決める必要がある ⚫ 方法3つ • コンソールからファイルをアップロード • コマンド • CI/CDパイプライン 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します VPC Private subnet Public subnet Amazon Aurora Elastic Load Balancing ネットワークアプリケーションデータベース Amazon ECS ①ネットワーク ②or③データベース ②or③アプリケーション

◼ ①ファイル/スタックをどこまで分割するか ◼ ②スタック間の情報連携方法 ◼ ③環境差異の吸収方法 ◼ ④デプロイ方法 ◼ ⑤AWSリソースの命名規則 ⚫ 複数開発者で揺れがないように最初に決めておく ⚫ リソース名のプレフィックスなどはParameter経由で渡す ◼ ⑥Gitブランチの運用方法 ⚫ git-flow, github-flowなどを適用して、PRレビューを効果的に行う ◼ ⑦リリース後の設定変更方法 ⚫ 手動での変更 → コードは後追いを許容するか？ ⚫ 原則コードからのみにするか？ ⚫ 緊急時のリリースは手動とするか？ 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

16 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.6. 開発
◼ いきなり0からコードを記載していくのは難しい ◼ 以下の順番で開発を行っていくと初学者でも簡単に進めることができる ⚫ まずは手動で動くものを作成する ⚫ CloudFormationのIaCジェネレーターでテンプレートを生成する ⚫ 開発ルールに従ってリファクタリングする ⚫ 実際のスタックとしてデプロイ ◼ 他アカウント･他リージョン･他システムでもデプロイ可能であることを意識して開発することが望ましい ◼ 参考 ⚫ CloudFormation ベストプラクティス ⚫ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/best-practices.html ⚫ テンプレートリファレンス ⚫ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/TemplateReference/introduction.html 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

17 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.7. テスト
◼ ｢aws cloudformation validate-template｣コマンド ⚫ テンプレートの構文のみ確認 ◼ CloudFormation変更セット作成 ⚫ 無効なプロパティ、リソース名の競合、S3バケット削除時の空制約を早期検証可能 ◼ cfn-lint ⚫ プロパティの妥当性や必須項目の漏れ、ベストプラクティスなどをローカルでも確認可能 ◼ AWS CloudFormation Guard ⚫ リソースに対するガードレールを設けることが可能 ⚫ 特定のタグをつけるといったルールの準拠確認 ⚫ 単体テストも実施可能 ◼ cfn-nag ⚫ セキュリティに特化したツール ⚫ 強い権限がないか、セキュリティグループが全開放されていないかなど解析可能 ◼ Taskcat ⚫ テスト的に環境を一時的にテスト構築してデプロイ可能か確認 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

18 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.8. 実際の環境へデプロイ
◼ 実際に各環境に対してデプロイを行う ◼ 詳細については以下参照 ⚫ ～NRIネットコム TECH AND DESIGN STUDY #92～ ⚫ ｢どこで打鍵するのがいい？ -IaCの実行基盤選定について-｣ 2. Infrastructure as Codeのはじめ方 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します Connpassページ

20 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3. まとめ
◼ Infrastructure as Codeのはじめ方 ⚫ 導入目的の洗い出し ⚫ 適用範囲の検討 ⚫ Infrastructure as Codeツールの選定 ⚫ Infrastructure as Codeツール（CloudFormation）の理解 ⚫ 開発･運用ルールの策定 ⚫ 開発 ⚫ テスト ⚫ 実際の環境へデプロイ ◼ Infrastructure as Codeはシルバーブレットではありません。 ◼ 導入したら終了ということではなく今後の運用でより真価を発揮します。 ◼ 今回お話した内容は現状に合わせる形を前提としていましたが、メンバーのスキルセット向上やチームメンバーのIaCに対する認識合わせも同じくらい重要です。その点だと0からIaC導入ではなく、手順書の一部をAWS CLIで実施して、少しずつコードに対するハードルを下げるというのも1つの手です。 ◼ 手順書作成に辟易している人はぜひIaCでコード化･デプロイ自動化を行っていきましょう。 #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します

Infrastructure as Codeのはじめ方～NRIネットコム TECH AND ...

Infrastructure as Codeのはじめ方～NRIネットコム TECH AND DESIGN STUDY #93～

umehara

More Decks by umehara

Other Decks in Technology

Featured

Transcript