理論

1. Amazon Aurora PostgreSQL

• Auroraは、Amazonが提供するフルマネージド型のリレーショナルデータベースサービスで、PostgreSQL互換のデータベースエンジンも提供しています。

• Aurora Auto Scalingは、リードレプリカの数を自動的に調整する機能です。これにより、アプリケーションの読み取りトラフィックに合わせてリソースをスケーリングできます。

2. EC2 Auto Scaling

• EC2 Auto Scalingは、アプリケーションの需要に応じてEC2インスタンスの数を自動的に調整する機能です。これにより、トラフィックが増加した際にインスタンスを追加し、トラフィックが減少した際にインスタンスを削除できます。

3. Elastic Load Balancing (ELB)

• Elastic Load Balancingは、AWSの負荷分散サービスで、アプリケーションのトラフィックを複数のバックエンドインスタンスに分散させ、可用性とスケーラビリティを向上させます。

• Application Load Balancer (ALB)は、HTTP/HTTPSトラフィックに最適化された負荷分散機能で、アプリケーション層（第7層）でのルーティングを行います。ルーティングのアルゴリズムとしては、ラウンドロビンがよく使われます。

• Network Load Balancer (NLB)は、TCP/UDPトラフィックに最適化された負荷分散機能で、第4層（トランスポート層）で動作します。最小待機リクエストなどのルーティングアルゴリズムを使用することができます。

4. Sticky Sessions（セッション維持）

• Sticky Sessions（またはセッションアフィニティ）は、同じクライアントからのリクエストを常に同じEC2インスタンスにルーティングする機能です。これにより、セッション情報が保存されている特定のインスタンスと継続的にやりとりすることができます。

5. スケーラビリティと一貫性の確保

• アプリケーションやデータベースがスケールする場合、ユーザーに一貫した体験を提供するために、セッション管理（Sticky Sessions）や適切な負荷分散の設定が重要です。

• Auroraのリードレプリカを使用して、読み取り専用のトラフィックを分散させることで、書き込みトラフィックが集中してもパフォーマンスを保つことができます。

6. オートスケーリングの対象

• Aurora Auto Scalingは、Auroraレプリカのスケーリングに関係し、Aurora書き込みインスタンスに対するスケーリングではない点に注意が必要です。書き込みインスタンス（Writer）は通常、1つのインスタンスに固定されていますが、読み取りトラフィックの増加に応じてレプリカを増やすことができます。

7. 2層のWebベース

1. プレゼンテーション層（クライアント層）: ユーザーがインタラクトする部分です。通常、ブラウザやモバイルアプリがこの層に該当します。この層は、ユーザーインターフェース（UI）を提供し、ユーザーからの入力を受け取り、それをサーバーに送信します。

2. データ層（バックエンド層）: アプリケーションのビジネスロジックやデータの管理が行われる部分です。この層は、通常、サーバー上で動作しており、データベースとの通信や処理を行います。Webアプリケーションの場合、データベース（例: PostgreSQLやMySQL）とサーバーサイドのロジック（例: アプリケーションサーバー）で構成されます。

重要な要点

• Aurora Auto Scalingを使用してAuroraレプリカをスケーリングし、読み取りトラフィックを分散させる。

• Application Load Balancer (ALB) を使用し、ラウンドロビンでトラフィックを均等に分配。

• Sticky Sessionsを使用して、一貫したユーザー体験を提供。

実践

一門道場

選択肢:

• AuroraのAuto Scaling（Auroraレプリカ用）を有効化

• Network Load Balancer (NLB) を使用し、最小待機リクエストのルーティングアルゴリズムとステッキーセッションを有効化

• AuroraのAuto Scaling（Aurora書き込み用）を有効化

• Application Load Balancer (ALB) を使用し、ラウンドロビンルーティングアルゴリズムとステッキーセッションを有効化

• AuroraのAuto Scaling（Auroraレプリカ用）を有効化

• Application Load Balancer (ALB) を使用し、ラウンドロビンルーティングアルゴリズムとステッキーセッションを有効化

• AuroraのAuto Scaling（Aurora書き込み用）を有効化

• Network Load Balancer (NLB) を使用し、最小待機リクエストのルーティングアルゴリズムとステッキーセッションを有効化

解説

1. アーキテクチャの構成

• アプリケーション層：状態を保持するアプリケーションが1台のEC2インスタンスで動作しています。

• データベース層：PostgreSQLデータベースが別のサーバーで稼働していますが、AWSのAurora PostgreSQLに移行されます。

2. アプリケーションのスケーリング

3. データベースのスケーリング

• Network Load Balancer (NLB) は高いトラフィックを処理するために設計されていますが、リクエストの最小待機時間（least outstanding requests）でトラフィックを分散します。NLBは通常、TCP/UDPトラフィックに最適ですが、状態保持型のWebアプリケーションで「Sticky Sessions」を使用する場合、Application Load Balancer (ALB) がより適しています。

• この選択肢は、状態保持型のアプリケーションとトラフィック管理には不適切です。

• AuroraのライターインスタンスにAuto Scalingを有効にすると、書き込み操作の負荷を分散できますが、ライターのスケーリングは通常、特定の書き込み操作を分散するために使用されます。このシナリオでは、読み取り専用の操作が主であり、リーダーのスケーリングが必要です。

• ALBはWebアプリケーションのロードバランシングに適しており、状態保持（Sticky Sessions）を活用する場合にも最適です。

• Auroraリプリカを使用することで、読み取り専用のリクエストを複数のインスタンスに分散できます。また、ALBはHTTP/HTTPSトラフィックの処理に優れており、状態保持型のセッション管理（Sticky Sessions）もサポートしています。この選択肢は、Webアプリケーションのスケーラビリティと一貫したユーザー体験を提供するために最適です。

• AuroraライターのAuto Scalingを使用する場面では、書き込み操作にフォーカスする必要があり、このシナリオではリードレプリカのスケーリングが重要です。さらに、NLBは状態保持型アプリケーションには適していません。