Skip to content

フルマネージド環境でスケーラブルな Web API を構築する

概要

このアーキテクチャで達成できる要件

  • シンプルな Web アプリケーションをデプロイしたい
  • アプリケーションの実行環境の運用コストを軽減して、アプリケーションの開発に集中したい

構成図

構成説明

  • Amazon Aurora MySQL DBクラスタを作成するためのVPCおよびサブネットを作成します。
    • サブネットは二つ作成します。
    • 各サブネットは、それぞれ異なるアベイラビリティゾーンに作成されます。
  • DBクラスタにインターネットからアクセスできるように、インターネットゲートウェイを作成します。
  • DBクラスタに設定するためのセキュリティグループを作成します。以下のインバウンドルールおよびアウトバウンドルールを設定します。
    • インバウンドルール
      • すべてのIPアドレスからのMySQLトラフィックを許可します。
    • アウトバウンドルール
      • すべてのトラフィックを許可します。
  • DBクラスタに設定するためのサブネットグループを作成します。
    • サブネットグループには、二つのサブネット両方が追加されます。
  • Amazon Aurora MySQL DBクラスタを作成します。
    • DBインスタンスは二つ作成されます。一つはライターインスタンス、もう一つはリーダーインスタンス(Auroraレプリカ)になります。
    • インターネットからアクセスできるように、DBインスタンスはパブリックアクセス可能にします。
  • AWS App Runnerにデプロイするアプリケーションのコンテナイメージを保存するためのAmazon ECRリポジトリを作成します。
  • ECRリポジトリにプッシュされたイメージを用いて、アプリケーションを実行するApp Runnerサービスを作成します。
  • App Runnerサービスにカスタムドメインをリンクするために、Amazon Route 53のALIASレコードおよびCNAMEレコードを作成します。
    • なお、Route 53のホストゾーンは作成されないため、作成済みのホストゾーンを使用してください。
  • アプリケーションにアクセス可能なソースIPアドレスを制限できるようにするために、AWS WAFのWeb ACLを作成します。
  • Web ACLトラフィックのログを記録するためのAmazon CloudWatch Logsロググループを作成します。
  • アプリケーションが利用するMySQLのデータベースおよびユーザを作成します。
  • 各種IAMロールを作成します。具体的には以下のロールが作成されます。
    • DBインスタンスに設定するためのAmazon RDS拡張モニタリング用のロール
    • App RunnerサービスのECRアクセスロール用のロール
    • App Runnerサービスのインスタンスロール用のロール
  • 各種Amazon Secrets Manager シークレットを作成します。具体的には以下のシークレットが作成されます。
    • DBクラスタのマスターパスワード
    • アプリケーションがAurora MySQL DBクラスタにアクセスする際に使用する、MySQLのユーザ用パスワード

処理フロー

  1. アプリケーションのFQDNに対するHTTPSリクエストを、App Runnerサービスが処理する。ここで、AWS WAFのWeb ACLのルールに準拠しないリクエストは拒否され、準拠するリクエストのみが受理される。

  2. アプリケーションが実行される。ここで、アプリケーションは必要に応じてMySQLデータベースやシークレットにアクセスする。

  3. アプリケーションが処理を終えて、クライアントに処理結果を返す。

他の方式との比較

  • アプリケーション層を実現するサービスとして、App Runnerの他にAWS Fargateを使用する選択肢も考えられます。

  • App Runnerを用いた方式は、以下の場合に適しています。

    • Webアプリケーションの実行環境の運用コストを軽減して、アプリケーションの開発に集中したい。
  • AWS Fargateを用いた方式は、以下の場合に適しています。

    • サーバレスのメリットを活かしつつ、負荷分散やスケーリング等の設定をより細かく制御したい。

AssemblyLine 構成

このアーキテクチャでは、以下の AssemblyLine が生成されます。

  • AWS Shared Infrastructure
    • バックエンドアプリケーションをデプロイするための基盤となるクラウドリソースをデプロイする。
  • AWS API Backend Application
    • 基盤となるリソース上にバックエンドアプリケーションをデプロイする。

AWS Shared Infrastructure

この AssemblyLine は、以下の Pipeline から構成されます。

  • deploy
    • 基盤となるクラウドリソースをデプロイする。

AWS API Backend Application

この AssemblyLine は、以下の Pipeline から構成されます。

  • refer
    • AWS Shared Infrastructure AssemblyLine によってデプロイされたリソースの情報を取得し、リソースデプロイに活用する。
  • build
    • デプロイするアプリケーションのコンテナイメージをビルドする。
  • deploy
    • バックエンドアプリケーション用のクラウドリソースをデプロイする。

追加可能な Option

アプリケーションの公開範囲を制限したい

機能説明

アプリケーションにアクセスできるソース IP アドレスを制限します。アクセスを許可したい IP アドレスをパラメータで指定することで、指定した IP アドレスが AWS WAF の Web ACL に設定され、それ以外の IP アドレスからのアクセスが拒否されます。この Option を使用しない場合は、インターネットのすべての IP アドレスからのアクセスが許可されます。

利用場面

  • アプリケーションにアクセスできるクライアントを制限してセキュリティを向上したい。

Architecture Decision Records

Amazon RDS の DB エンジンには Aurora MySQL を使用する

Context

  • Amazon RDS で MySQL を使用する場合、DB エンジンとして通常の MySQL または Aurora MySQL を選択できます。

Decision

  • Aurora MySQL を使用します。
    • Aurora MySQL は MySQL の完全な互換性を備えており、スループットが MySQL の 最大 5 倍であるなど性能面で優れているため。

Aurora Serverless v2 を使用する

Context

  • DB インスタンスクラスは、DB インスタンスの計算容量・メモリ容量を決定します。
  • 特定の DB インスタンスクラスを選んで容量を手動で管理する方法と、オンデマンドの自動スケーリング設定である Aurora Serverless を使用する方法があります。

Decision

  • Aurora Serverless v2 を使用します。
    • 特定の DB インスタンスクラスを指定する方法の場合、DB インスタンスの計算容量・メモリ容量を手動で管理することになりますが、Aurora Serverless を使用することで手動管理に伴う運用コストを軽減できるため。

ライターインスタンスの他に Aurora レプリカを作成する

Context

  • Aurora MySQL は、プライマリであるライターインスタンスがあれば動作できます。
  • ライターインスタンスに加えて、スタンバイである Aurora レプリカ(リーダーインスタンス)も作成できます。

Decision

  • Aurora レプリカを作成します。
    • Aurora レプリカを作成しておくことで、高可用性を実現できるため。

DB インスタンスのマイナーバージョン自動アップグレードを無効化する

Context

  • DB インスタンスのマイナーバージョン自動アップグレードを有効化することで、新しいマイナーバージョンがリリースされた際に自動的にアップグレードされるようになります。

Decision

  • マイナーバージョン自動アップグレードを無効化します。
    • 自動アップグレードを有効化していると、Qmonus Value Stream で管理されている DB インスタンスのバージョンと、実際に DB インスタンスに適用されているバージョンに差分が生じる可能性があるため。
    • エンジンバージョンを指定するパラメータが用意されているので、バージョンをアップグレードしたい場合は当該パラメータを変更した上で AssemblyLine を再実行してください。

非機能要件

可用性

冗長化構成

  • App RunnerはAWSグローバルインフラストラクチャを使用しており、アベイラビリティーゾーン間で自動的にフェイルオーバーするように設計されています。

  • Aurora MySQL DBクラスタでは、二つのアベイラビリティゾーンに対してインスタンスが一つずつデプロイされ、一つはライターインスタンス、もう一つはリーダーインスタンスになります。

    • ライターインスタンスは自動的にリーダーインスタンスにレプリケートされます。
    • ライターインスタンスが使用できなくなった場合は、リーダーインスタンスが自動的に昇格し、ライターインスタンスとして動作します。

リージョン構成

  • 以下のリソースは全て同じリージョンに作成されます。このリージョンはパラメータで変更可能です。

    • VPC
    • インターネットゲートウェイ
    • Aurora MySQL DBクラスタ
    • ECRリポジトリ
    • App Runnerサービス
    • CloudWatch Logsロググループ
    • Secrets Managerシークレット
  • 以下のリソースはグローバルサービスのリソースです。

    • Route 53レコード
    • IAMロール
    • Web ACL

運用・保守性

バックアップ

  • バックアップ方式
    • Aurora MySQL DBクラスタでは、自動バックアップが毎日 1 回実行されます。自動バックアップの保持期間は1〜35日間で、この保持期間はパラメータで変更可能です。
    • Aurora MySQL DBクラスタでは、任意のタイミングで手動でスナップショットを作成できます。

保守

  • Aurora MySQL DB インスタンスのエンジンバージョンのアップグレード
    • DBインスタンスのマイナーバージョン自動アップグレードは無効化されます。

セキュリティ

アクセス制限

  • アクセス制限方法
    • (【アプリケーションの公開範囲を制限したい】Option を追加した場合)パラメータで指定することで、アプリケーションにアクセスできるソース IP アドレスをWeb ACLによって制限できます。

ログ

  • ログポリシー
    • Web ACLトラフィックのログを保存します。
  • ログ保存先
    • CloudWatch Logsロググループにエクスポートされます。
  • ログ保存期間
    • ログが保持される期間はパラメータで変更可能です。デフォルトでは365日間保持されます。

データの暗号化

  • Aurora MySQL DBインスタンスは、AWSマネージドキーによって暗号化されます。
  • Secrets Managerに保存されるシークレットは、AWSマネージドキーによって暗号化されます。

Web からの攻撃対策

  • (【アプリケーションの公開範囲を制限したい】Option を追加した場合)Web ACLのルールに準拠しないリクエストは拒否され、準拠するリクエストのみが受理されます。

Last updated: