AWS CDKによるマルチAZ3層アーキテクチャ構築

kitaya

皆様こんにちは。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上でも環境構築をしてみました。
下記ご確認ください。

AWS CDKの環境構築(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.監視システムの構築

Last modified: 2024-08-16

Author