【AWS】 代表的なクラウドデザインパターン紹介

はじめに

AWSの豊富なサービス群を活用することで、高可用性かつ高スケール性を実現するシステムを構築することが可能です。

しかし、クラウドサービスの特性を最大限に活かすためには、適切なデザインパターンを理解し、実践することが重要です。そこで今回は、AWSを利用して「高可用性」かつ「高スケール性」を実現するための代表的なクラウドデザインパターンを紹介します。

1. EC2インスタンスを利用した動的コンテンツの配信

動的コンテンツとは？

動的コンテンツとは、ユーザーのリクエストに応じて生成されるコンテンツのことを指します。たとえば、ユーザーのログイン状況や入力内容に基づいて異なるページを表示するようなケースです。

AWSサービスの簡単な解説

• Amazon EC2 (Elastic Compute Cloud): スケーラブルなコンピューティングリソースを提供するサービスです。必要に応じて、インスタンスの数を増減させることができます。
• Amazon ELB (Elastic Load Balancing): 複数のEC2インスタンスにトラフィックを分散させ、可用性と耐障害性を向上させます。ALBはHTTP/HTTPS、NLBはTCP/TLS/UDPプロトコルをサポートします。
• Amazon Route 53: 高可用性とスケーラビリティを備えたDNSウェブサービスです。ドメイン名をIPアドレスにマッピングし、ユーザーを最適なサーバーに誘導します。
• Auto Scaling: 指定されたポリシーに基づいて、EC2インスタンスの数を自動的に調整する機能です。これにより、変動する負荷に対応できます。

詳細については公式ドキュメントをご参照ください。

具体例

Next.jsのSSRを利用した動的コンテンツ生成は、ユーザーのリクエストごとに新しいHTMLをサーバー側で生成するため、動的コンテンツの代表的な例です。また、コンテナ化されたアプリケーションをデプロイするケースも多く、EC2の部分をECS (Amazon Elastic Container Service) に置き換えることもあります。

2. S3を利用した静的コンテンツの配信

静的コンテンツとは？

静的コンテンツとは、サーバーサイドで処理を行わずに、そのままの状態でクライアントに配信されるコンテンツのことを指します。具体的には、画像ファイル、動画ファイル、HTML、CSS、JavaScriptなどが該当します。これらのファイルはユーザーのリクエストに応じて変化することがなく、サーバーから直接提供されます。

AWSサービスの簡単な解説

• Amazon S3 (Simple Storage Service): スケーラブルで耐久性が高いオブジェクトストレージサービスです。静的ウェブサイトのホスティングや、データのバックアップ、アーカイブに利用されます。署名付きURLを利用することで、一定期間のみ有効なURLを生成し、特定のユーザーにのみアクセスを許可できます。
• Amazon CloudFront: AWSが提供するコンテンツ配信ネットワーク（CDN）サービスで、グローバルに分散したエッジロケーションを通じてコンテンツをキャッシュし、高速でユーザーに配信します。

※すでに説明したものは割愛します

具体例

静的コンテンツを利用した代表的な例として、Next.jsのSPA（シングルページアプリケーション）が挙げられます。Next.jsでは、ビルドされた静的ファイルをS3にホスティングし、CloudFrontを通じて世界中のユーザーに高速で配信するケースが一般的です。

このパターンでは、S3に格納された静的コンテンツをCloudFrontを介してキャッシュし、ユーザーに配信することで、レスポンスタイムを短縮し、コストを削減することができます。

[Topic] S3

3. 動的コンテンツと静的コンテンツの混在

動的なコンテンツと静的なコンテンツを同時に配信するためのパターンです。このパターンでは、CloudFrontのマルチオリジン機能を利用することで、コンテンツのパスに応じて適切なオリジン（ソース）からコンテンツを取得し、効率よく配信します。

動的コンテンツと静的コンテンツが混在する具体的なケース

典型的なケースとして、Eコマースサイトが挙げられます。商品ページやユーザーページは動的に生成されるコンテンツですが、画像やCSS、JavaScriptファイルなどの静的コンテンツも同じページに含まれています。この場合、動的コンテンツはEC2インスタンス上でホストされ、静的コンテンツはS3に保存されます。CloudFrontを使用することで、動的コンテンツと静的コンテンツが統合的に管理され、最適なオリジンからの配信が行われます。

※ EC2の部分をECSに置き変えることもあります

4. サーバレスアーキテクチャを利用した動的Webサービスの構築

サーバレスアーキテクチャとは？

サーバレスアーキテクチャとは、サーバの管理や運用を意識せずに、アプリケーションを構築・実行することができるクラウドのアーキテクチャスタイルです。サーバ管理の負担が軽減され、スケーラビリティやコスト効率が高まるため、スタートアップや小規模プロジェクトにも適しています。

AWSサービスの簡単な解説

• AWS Lambda: コードを実行するためのサーバーレスコンピューティングサービスです。リクエストに応じてコードが自動的にスケールし、ユーザーが直接サーバを管理する必要がありません。
• Amazon API Gateway: APIの作成・管理を行うサービスで、HTTPリクエストをLambda関数や他のAWSサービスにルーティングします。APIのセキュリティ、認証、モニタリング機能を簡単に実装できます。

この構成が具体的に使われるパターン

このサーバレス構成は、動的Webサービスを構築する際に一般的に利用されます。具体的な例としては、RESTful APIやグラフQL APIの構築、モバイルアプリのバックエンド、Webアプリケーションのバックエンドなどが挙げられます。Lambdaがリクエストに応じて動的にコンテンツを生成し、API Gatewayがそのリクエストを処理・管理します。

Webサービスの公開における注意点

サーバレスアーキテクチャでは、Lambdaが高いスケーラビリティを持つため、大量のリクエストを処理することが可能です。ただし、同時実行数やリクエストレートに上限があり、これを超える場合には、追加のチューニングやLambdaのプロビジョンドコンカレンシーを設定する必要があります。

また、Webサービスとして公開する際には、API Gatewayのレートリミットの設定や、キャッシュを有効にすることでパフォーマンスを向上させることが重要です。

バッチ処理や非同期処理にも利用

サーバレスアーキテクチャは、Webサービスだけでなく、バッチ処理や非同期処理にも非常に適しています。たとえば、S3にアップロードされたファイルを処理するためのLambda関数や、SNSトピックでトリガーされる通知システムなどが考えられます。これにより、サーバーレスアーキテクチャは多様なユースケースに柔軟に対応することができます。

Lambda URLsについて

最近のアップデートで、API Gatewayを利用せずに、直接Lambda関数を呼び出すことができるLambda URLs機能が追加されました。この機能を利用することで、API Gatewayの設定が不要となり、よりシンプルでコスト効果の高いAPI構築が可能です。ただし、API Gatewayが提供するセキュリティ機能や認証機能が必要な場合には、従来通りAPI Gatewayを使用することが推奨されます。

コスト面について

サーバレスアーキテクチャは、そのスケーラビリティに加えて、コスト効率も高いのが特徴です。Lambdaは実行時間に応じて課金され、使用していない間はコストがかかりません。API Gatewayもリクエスト数に基づいた課金モデルを採用しており、利用量に応じてコストが変動します。このため、トラフィックが少ないスタートアップやプロジェクトに特に適しています。

Topic: Lambdaについて深掘り

AWS Lambdaのスケーラビリティと制限

AWS Lambdaは高いスケーラビリティを持っており、大量のリクエストを処理することが可能です。ただし、同時実行数やリクエストレートに関する制限があります。

同時実行数（Concurrency）の定義

• 同時実行数は、同時に実行されているLambda関数の数を指します。デフォルトでは、各リージョンごとに1,000の同時実行数の制限が設定されています。
• この制限に達すると、リクエストはキューに入るか、スロットルされる可能性があります。これにより、関数が呼び出されるまでの遅延が発生することがあります。
• 必要に応じて、プロビジョンドコンカレンシー（プロビジョニングされた同時実行数）を設定することで、特定の関数に対して予測可能な負荷に対応するためのスロットを事前に確保することが可能です。

リクエストレートの制限

• リクエストレートは、Lambda関数が処理できるリクエストの頻度を指します。具体的には、各Lambda関数インスタンスは1秒あたり最大10件の同期リクエストを処理することができます。全体としては、同時実行数の10倍が最大リクエストレートとなります。（=10,000）
• 非同期リクエストの場合、理論的にはリクエスト数に制限はありませんが、実際には同時実行数に基づいて処理が行われます。
• リクエストレートの制限を超えると、リクエストはキューに入れられ、関数が利用可能になるまで処理が遅延する可能性があります。

参照：AWS Lambda クォータ

5. RDSを利用した冗長構成

AWSサービスの簡単な解説

• Amazon RDS (Relational Database Service): AWSが提供するマネージドリレーショナルデータベースサービスです。簡単にデータベースのセットアップ、運用、スケーリングが可能で、MySQL、PostgreSQL、Oracle、SQL Server、MariaDBなどの一般的なデータベースエンジンをサポートしています。

RDSの冗長とは？

冗長性とは、システムの信頼性と可用性を高めるために、同じ機能を持つ複数のリソースを用意することを指します。Amazon RDSでは、主にマルチAZ配置やリードレプリカを活用することで、冗長性を高めています。

• なぜ冗長性が必要か？
  データベースがダウンすると、アプリケーション全体が影響を受ける可能性があります。冗長性を確保することで、障害発生時にもシステムが迅速に復旧し、データの損失やサービスダウンを防ぐことができます。

[補足] 単語の説明

マルチAZ (Multi-AZ): Amazon RDSのオプションで、高可用性とデータ耐久性を確保するために使用されます。異なるアベイラビリティゾーンにプライマリーデータベースとスタンバイデータベースが配置され、障害発生時には自動でフェイルオーバーが行われます。
リードレプリカ (Read Replica): 読み出し専用のデータベースインスタンスで、主に参照クエリの負荷分散やスケーラビリティの向上に使用されます。

[Topic] DBの冗長性とThe Scale Cube

データベースの冗長性を確保することは簡単ではなく、特にスケーラビリティとパフォーマンスのバランスを取ることが課題です。この点に関して、「The Scale Cube」というモデルがあります。

• The Scale Cubeは、システムをスケーリングするための3つの次元（X軸、Y軸、Z軸）を提案しています：

X軸（ロードバランシング）は、同じデータベースインスタンスを複製し、リクエストを複数のインスタンスに分散させる方法です。しかし、これは基本的には読み取りのスケールには有効ですが、書き込みのスケールには制約があります。書き込み操作は通常一箇所に集まるため、スケールが難しい部分です。

Y軸（サービス分割）は、機能やデータを分割してそれぞれ別のデータベースに持たせる方法です。このアプローチは、データの依存関係をどう管理するかが難しく、データの整合性を保ちながらのスケーリングが複雑になります。

Z軸（シャーディング）は、データを分割して異なるシャードに分散させる方法です。これは特に大規模なデータセットで有効ですが、シャード間のデータの一貫性を保つのが難しく、スケールの際には多くの課題があります。

参照：The Scale Cube

冗長性のパターン

RDSで使用される主な冗長性パターンには以下があります：

1. マルチAZ配置
   異なるアベイラビリティゾーンにプライマリとスタンバイを配置することで、可用性を確保するパターンです。障害発生時に自動でフェイルオーバーが行われます。

2. リードレプリカ
   参照専用のレプリカを複数作成し、読み取り処理の負荷を分散するパターンです。これにより、書き込みと読み取りのトラフィックを分離できます。

構成図についての解説

上記の構成図では、次のような冗長性が確保されています：

• マスター（M）とスタンバイ（S）のデータベースインスタンス
  更新トランザクションを扱うプライマリインスタンス（M）があり、スタンバイ（S）インスタンスがフェイルオーバー用に待機しています。このセットアップにより、データベースのダウンタイムを最小限に抑えられます。

• リードレプリカ（R）
  参照系クエリを処理するためのリードレプリカが配置されています。これにより、参照系クエリがマスターインスタンスにかかる負荷を軽減し、スケーラビリティを向上させています。

他の方法や技術選定について

RDSのマルチAZ配置やリードレプリカの代替として、DynamoDBのようなNoSQLデータベースを利用することも検討できます。DynamoDBはデフォルトで高可用性とスケーラビリティを提供し、管理負荷が軽減されます。ただし、DynamoDBを選択する際は、データの構造やアクセスパターンがRDBMSよりも適しているかを検討する必要があります。

また、Amazon Auroraも選択肢です。AuroraはMySQLやPostgreSQL互換のデータベースエンジンで、RDSと同様にフルマネージドなサービスですが、以下の点でさらに優れた冗長性とパフォーマンスを提供します。

[Topic]　Amazon Aurora

• クラスター構成: Auroraでは、データはクラスターとして管理され、デフォルトでデータが6つのコピーに分散され、2つの異なるアベイラビリティゾーン（AZ）に配置されます。これにより、データの高い耐障害性と可用性が確保されます。

• マルチAZ必須（ストレージの冗長構成）: AuroraクラスターのストレージはマルチAZ構成が必須となっており、複数のAZにまたがってデータを自動的にレプリケートするため、ストレージの冗長性が非常に高いです。これにより、ストレージ層での障害が発生しても、データの可用性は保たれます。

• クラスターインスタンス（コンピューティングの冗長構成）: クラスターに接続するインスタンスについては、シングルAZ構成も選択可能です。これにより、コンピューティングリソースの冗長性を調整することができます。例えば、シングルAZで動作させてコストを抑えつつ、ストレージ層での高い冗長性を維持することが可能です。

加えて、RDSよりも自動化が進んでおり、バックアップやフェイルオーバーが迅速かつ自動的に行われます。

参照: Amazon Aurora の高可用性

デメリットや注意点、障害テスト

冗長構成は非常に効果的ですが、いくつかのデメリットや注意点があります：

• コストの増加: 冗長性を確保するためには複数のインスタンスを維持する必要があり、それに伴うコストが増加します。
• 複雑性: システムが複雑になることで、管理やモニタリングが難しくなる場合があります。
• 障害テスト: 定期的に障害シナリオをテストすることが重要です。例えば、意図的にプライマリインスタンスを停止し、フェイルオーバーが正常に行われるかを確認するテストを実施することが推奨されます。

[Topic] NewSQL

NewSQLは、従来のリレーショナルデータベース（RDBMS）のACID特性を維持しながら、NoSQLのスケーラビリティを備えた新しいタイプのデータベースです。特に、書き込みがボトルネックとなるユースケースでのスケールアウトが難しいという課題を解決するために設計されています。

主な特徴

• 水平スケーリングを実現し、書き込み処理のスケールアウトが可能。

代表的なNewSQLツール

• Google Spanner: グローバルな分散型リレーショナルデータベース。高い一貫性とスケーラビリティを提供します。
• TiDB: MySQL互換の分散型データベースで、水平スケーリングと強い一貫性を実現します。
• Vitess: YouTubeが開発したスケーラブルなMySQLクラスター管理システムで、シャーディングや自動フェイルオーバーに対応しています。

NewSQLの活用例

• 書き込み負荷が高いオンラインゲームのバックエンドやリアルタイムデータ処理などで使われてることが多そう

私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】

まとめ

クラウドアーキテクチャを設計する際には、コスト、複雑性、冗長性、スケーラビリティなどのバランスを考慮しながら、最適なアプローチを選択することが重要です。
そのためには、基本的なアーキテクチャやクラウドの特性を理解しておくことが非常に大切です。

また、デザインパターンをより深く理解するためには、以下の内容を読むことを強くお勧めします

• AWS Well-Architected Framework
  AWSが推奨するベストプラクティスに基づいて、信頼性、セキュリティ、パフォーマンス効率、コスト最適化などを考慮したアーキテクチャを設計するためのガイドです。

• AWSクラウドデザインパターン - Cloud Design Pattern

これらのリソースを参考にしながら、最適なクラウドアーキテクチャを設計してみてください。

AWSや他のクラウドサービスの詳細については、公式ドキュメントや関連リソースを参照し、常に最新の情報をチェックすることをお勧めします。

最後まで読んでくださりありがとうございました。
少しでも役に立てば幸いです。