皆様こんにちは。kitayaと申します。
今回は研修にて学習した内容について投稿させていただきます。
目的
AWS CDKを用いて下記の非機能要件に基づいてマルチAZ3層アーキテクチャを構築する。
- 高可用性
- セキュリティ
- 運用・保守性
要件
- RPO(目標復旧時点)→最長24時間前
- RTO(目標復旧時間)→最長24時間
IaCツールの比較
インフラストラクチャ・アズ・コード（IaC）のツールは様々な形式が存在します。それぞれのツールには固有のメリットとデメリットがあり、使用する状況に応じて選択されます。
今回は学習のため、AWS CDKを使用しますが各形式の比較をしました。
※下記以外にもIaCツールは多く存在します
比較
| ツール名 | シェア | 対応プラットフォーム | 使用言語 | 柔軟性 | 学習コスト | テンプレートの可読性 |
|---|---|---|---|---|---|---|
| AWS CDK | 中 | AWS | Python、TypeScript、JavaScript、Java、C#、Go | 高 | 中～高 | 高（コードベース） |
| CloudFormation | 高 | AWS | JSON、YAML | 低 | 低 | 低（冗長） |
| Terraform | 最も高い | マルチクラウド対応（AWS、Azure、GCPなど） | HCL | 中 | 中 | 中 |
| Pulumi | 低 | マルチクラウド対応（AWS、Azure、GCPなど） | JavaScript、TypeScript、Python、Go、.NET | 高 | 中～高 | 高（コードベース） |
メリット、デメリットまとめ
| ツール名 | メリット | デメリット |
|---|---|---|
| AWS CDK | ・プログラム言語でのインフラ定義が可能 ・高い抽象化と再利用性 ・AWSサービスとの強力な統合 |
・CloudFormationに依存しており、その制限やバグの影響を受ける ・プログラム言語の知識が必要で、初期の学習コストが高い ・AWS以外には対応していない |
| CloudFormation | ・JSON、YAML形式でインフラを定義できる ・自動ロールバック機能 ・AWSサービスとの強力な統合 |
・複雑なテンプレートは冗長になりがちで、可読性が低下する ・カスタマイズ性が低く、他に比べて柔軟性が低い ・AWS以外には対応していない |
| Terraform | ・宣言型のシンプルで直感的な設定が可能 ・強力なコミュニティと豊富なモジュールライブラリ ・マルチクラウド対応 |
・複雑なロジックを扱う際、HCLの制限で冗長な記述が必要になることがある ・初めて使用する際の設定が少し複雑に感じることがある |
| Pulumi | ・プログラム言語でのインフラ定義が可能 ・高い抽象化と再利用性 ・マルチクラウド対応 |
・新しいツールのためドキュメントやサポートが少ない ・プログラム言語の知識が必要で、初期の学習コストが高い |
AWS CDKの概要
AWS Cloud Development Kit (AWS CDK)は、プログラミング言語を使用してAWSリソースを定義およびプロビジョニングするためのオープンソースソフトウェア開発フレームワークです。AWS CDKを使用すると、インフラストラクチャをコードとして定義し、CloudFormationスタックとしてデプロイできます。
主な特徴
-
インフラストラクチャをコードとして定義
JavaScript、TypeScript、Python、Java、C#など、一般的なプログラミング言語でインフラストラクチャを定義できます。これにより、既存のソフトウェア開発ツールチェーンやプロセスを利用できます。 -
高レベルの抽象化
AWS CDKは、AWSサービスを簡単に使用できるようにする高レベルのコンポーネント（Constructs）を提供します。これにより、複雑なリソース設定を簡素化できます。 -
再利用可能なコンポーネント
インフラストラクチャの定義を再利用可能なコンポーネントとしてパッケージ化し、他のプロジェクトやチームと共有できます。これにより、一貫性とメンテナンス性が向上します。 -
タイプセーフティと自動補完
タイプセーフな言語を使用することで、コンパイル時にエラーを検出しやすくなり、IDEの自動補完機能を利用できます。これにより、開発速度と品質が向上します。 -
AWSサービスとの統合
AWS CDKはAWSのネイティブツールとして設計されており、AWSサービスやCloudFormationとシームレスに統合されています。これにより、最新のAWS機能を迅速に利用できます。
基本的な構成要素
-
App
CDKアプリケーションのルートで、複数のスタックを含むことができます。 -
Stack
CloudFormationスタックに対応し、AWSリソースを論理的にグループ化します。 -
Construct
AWSリソースやその他の構成要素を抽象化した基本単位です。CDKの基本的な構成ブロックであり、シンプルなリソースから複雑なアプリケーションまでさまざまな抽象化レベルがあります。
環境
以下の環境を使用しました。
- AWS Cloud9
- CDK：2.150.0
- Python：3.9.16
- Node.js：v20.15.1
cloud9での環境構築については下記の記事を参考にさせていただきましたのでご確認ください。
【AWS CDK (Python)】 AWS CDKの始め方
cloud9の新規利用終了に伴い、EC2上でも環境構築をしてみました。
下記ご確認ください。
ソースコードの解説について
次回以降の投稿ではソースコードの解説をしていきます。
スタックの分割と各投稿で分割したサービスが一致していないこともあり、モジュールのインポートなどは省いています。
構成図
構成の最終目標
【高可用性】
- マルチAZのアーキテクチャ構築(NAT・EC2・RDS)
- EC2とRDSの日次バックアップの取得
- ALBによるWebサーバーの負荷分散
- EFSを利用したEC2インスタンスの拡張
【セキュリティ】
- RDSはプライベートサブネットからのみアクセスを許可
- VPCフローログとALBのアクセスログをS3への保管
- 外部のアクセスはHTTPSにて暗号化(HTTPはHTTPSへのリダイレクト)
※内部の暗号化については今回は割愛(EC2,RDS)
【運用・保守性】
- EC2のCPU、メモリ、ディスク使用率を監視し、閾値を超えた際にSNSでメール通知
- HealthイベントをEventBridge経由でSNSでメール通知
利用するAWSサービス
| サービス名 | 利用目的 |
|---|---|
| EC2 (Elastic Compute Cloud) | Webサーバーとして使用するため |
| RDS (Relational Database Service) | DBサーバーとして使用するため |
| EFS（Elastic File System） | EC2間でファイル共有を行うため |
| S3 (Simple Storage Service) | VPCフローログ、ALBアクセスログの保管に使用するため |
| IAM (Identity and Access Management) | EC2にcloudwatch Agent、session manager用の権限を与えるため |
| ALB (Application Load Balancer) | 2つのWebサーバーの負荷分散のため |
| Route53 | 名前解決のため |
| ACM（AWS Certificate Manager） | 証明書作成/利用のため |
| CloudWatchAgent | ・CPU、メモリ、ディスク使用率の監視メトリクスを発行するため |
| CloudWatchAlarm | ・EC2のリソース使用率の監視を行うため ・閾値を超えた場合、メール通知するため |
| SNS (Simple Notification Service) | アラーム発生時のメール送信先トピックを作成するため |
| Eventbridge | AWS Healthのイベントをメール通報できるようにするため。 |
| AWS Backup | EC2の定期的なバックアップを実施するため |
| AWS Health | パフォーマンスに影響を与える可能性のある問題をAWS Eventbridgeに連携するため |
構築手順
1.はじめに
2.VPCなど基盤構築
3.データベース・インスタンス構築
4.ネットワーク構築
6.ログ収集システム構築
7.バックアップ設定
8.監視システムの構築