FIXER Tech Blog - Cloud

AWS CDKとGitHubを使ったIaC＝インフラ構成管理の基本

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「[IaC] AWS CDKとGitHub を使ったインフラ構成管理」を再編集したものです。

　本記事はFIXER Advent Calendar 2024（FIXER Advent Calendar 2024 ～ Tech編 ～）12月2日の記事です。

　こんにちは！ヘルスケアイノベーション領域の山村です。

　最近は、ある保険制度基盤のクラウドリフト案件に従事する傍ら、Webシステムのインフラ基盤の設計・開発をお手伝いしていました。

　そのWebシステムの案件で、AWS CDKとGitHubを使ってインフラ構成管理に挑戦しましたので、今回はその経験について共有したいと思います。

はじめに

　インフラエンジニアにとって、インフラの構成管理は環境間の不整合を防ぎ、システムの安定稼働を実現するために非常に重要な業務です。

　以前、私は「インフラ環境変更履歴表」という管理表に「いつ・どの環境に・どのようなインフラ構成の変更を加えたか」を手作業で記載し、インフラ構成管理を行っていました。

　しかし、この方法を続けるうちに、手動でのインフラ構成管理には様々な課題があることに気づきました。

　そこで、これらの課題を解決するために、AWS CDKとGitHubを使ったインフラ構成管理を導入しました。

※今回はAWS CDKを使用しましたが、TerraformなどのIaC（Infrastructure as Code）ツールでも同様のことが可能です。

手動管理の課題点

　インフラを手動で管理する場合、以下のような課題が生じます。

a. ドキュメンテーションの不足
　手動操作では、細かな設定変更が記録に残らないことが多く、問題発生時のトラブルシューティングが困難になります。
例 : いつ、誰が、どのような設定を変更したのか不明瞭になり、原因究明に時間がかかる。

b. ヒューマンエラーのリスク増大
　設定ミスや手順の漏れにより、システムの不安定化やセキュリティホールを生む可能性があります。
例 : 手動でファイアウォールのルールを設定する際に、意図せず全てのトラフィックを許可してしまう。

c. 再現性の低さ
　手動操作では、同じ環境を再度構築することが難しい場合があります。作業者によって手順が異なったり、設定の抜け漏れが生じる可能性があります。
例 : 開発環境と本番環境で設定が微妙に異なり、デプロイ後に不具合が発生する。

d. スケーラビリティの限界
　大量のリソースを短時間で展開・管理することは、手動では非現実的です。迅速な対応が求められる中で手作業はボトルネックとなります。

AWS CDKとGitHubを使ったインフラ構成管理

　上記の課題を解決するために、AWS CDKとGitHubを利用した以下のワークフローを採用しました。

開発ワークフロー

1. featureブランチの作成
　開発者はdevelopブランチからfeatureブランチを作成します。このブランチでは機能の追加や変更、バグ修正などを行います。

2. プルリクエストの作成（developブランチへ）
　featureブランチでの作業完了後、開発者はfeatureブランチをリポジトリにプッシュし、developブランチへのプルリクエストを作成します。

3. プルリクエストのレビュー（developブランチ）
　レビュー担当者がコードの品質チェックや潜在的な問題の早期発見を目的としてレビューを行います。

4. プルリクエストのマージ（developブランチへ）
　承認されたプルリクエストをdevelopブランチにマージします。

5. 開発環境のインフラ構成変更確認
　cdk diffコマンドを実行し、想定された変更のみが開発環境へデプロイされることと、デプロイによる影響範囲を確認します。デプロイによる影響を考慮したデプロイ計画を作成します（例えば、デプロイによってダウンタイムが発生する場合、開発環境を利用しているユーザーに事前周知が必要）。

6. 開発環境へのデプロイ
　cdk deployコマンドを実行し、最新のインフラ構成を開発環境にデプロイします。

7. 開発環境でのテスト
　開発環境でテストを行い、新しいコードの統合に伴って発生し得る問題を特定・修正します。

8. プルリクエストの作成（masterブランチへ）
　開発環境でのテストが成功した後、開発者はdevelopブランチからmasterブランチへのプルリクエストを作成します。

9. プルリクエストのレビュー（masterブランチ）
　システム全体の安定性とリリースの妥当性を確認するためのレビューを行います。

10. プルリクエストのマージ（masterブランチへ）
　承認されたプルリクエストをmasterブランチにマージします。

11. 本番環境のインフラ構成変更確認
　cdk diffコマンドを実行し、想定された変更のみが本番環境へデプロイされることと、デプロイによる影響範囲を確認します。デプロイによる影響を考慮したデプロイ計画を作成します。

12. 本番環境へのデプロイ
　cdk deployコマンドを実行し、最新のインフラ構成を本番環境へデプロイします。

手動管理の課題点をどう解決したか

　上記のワークフローを採用することで、手動管理の課題点を以下のように解決できました。

a. ドキュメンテーションの不足
　→　GitHubを利用することで、「インフラ環境変更履歴表」がなくとも「いつ・どの環境に・どのようなインフラ構成の変更を加えたか」を追跡できるようになりました。変更履歴表への記載漏れに解消され、履歴管理が容易になりました。

b. ヒューマンエラーのリスク増大
　→　リソースの作成や設定値の変更はIaC（CDK）が行うため、ヒューマンエラーのリスクが大幅に減少しました（ただし、プルリクエストのレビューを正確に行うことが前提です）。

c. 再現性の低さ
　→　コードに記述された通りの環境が自動的に構築されるため、何度構築しても同じ環境が作成されます。また、本番環境は常に開発環境でテストされた環境であるため、環境差異による不具合を防止できます。

d. スケーラビリティの限界
　→　IaC（CDK）がインフラストラクチャを自動的に構築・設定するため、大量のリソースを短時間で展開・管理できます。

最後に

　今回紹介したワークフローは一例に過ぎません。皆さんが従事しているプロジェクトの要件に合わせて、柔軟にワークフローを調整し、IaCとGitHubを活用してみてください。

　私自身、AWS CDKとGitHubを活用することで、インフラ構成管理の効率化と品質向上を実感しています。ぜひ皆さんもこの機会に挑戦してみてください！

山村 悠馬／FIXER
はじめまして、山村です。
入社以来、インフラ一筋です。

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER