助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 33164
問題を開く
ある会社は、ALB配下のAuto Scalingグループに所属するEC2インスタンスでECサイトを運営している。ECサイトは時間帯によってアクセス数に変動があり、1日に何回かインスタンスのスケーリングが発生している。会社は、クライアントとのセッションを安定して維持するためにセッション管理を最適化し、セッション情報を永続的に保存したい。
どのようなソリューションが適切か。（2つ選択）
どのようなソリューションが適切か。（2つ選択）
正解
Amazon DynamoDBにセッション情報を保存する
Amazon ElastiCacheのRedisをマルチAZに設定して、セッション情報を保存する
解説
設問のようにインスタンスのスケーリングが発生するシステムでは、クライアントとのセッションを維持しているサーバーがスケールインした時に、セッション情報が破棄されてしまいます。セッションを安定して維持するためには、セッション情報をデータベースに保存してインスタンス間で共有するのが効果的です。セッション情報の保存には、NoSQLデータベースで高パフォーマンスな読み取り・書き込みが可能であるAmazon DynamoDBとAmazon ElastiCacheが適しています。
下記の図はDynamoDBを利用した例です。
DynamoDBに保存するデータは3つのAZに自動的に保存されるので耐久性に優れており、セッション情報を永続的に保存できます。また、ElastiCacheのRedis型もマルチAZに対応しておりデータの永続保持が可能です。
したがって正解は
・Amazon DynamoDBにセッション情報を保存する
・Amazon ElastiCacheのRedisをマルチAZに設定して、セッション情報を保存する
です。
その他の選択肢については、以下のとおりです。
・Amazon ElastiCacheのMemcachedをマルチAZに設定して、セッション情報を保存する
ElastiCacheのMemcached型はセッション情報の一時保管には適していますが、マルチAZや永続保持の機能はないので障害や再起動などが発生した場合はデータが残りません。
セッション情報を永続的に保存したいという要件に合わないので、誤りです。
・AWS Systems Manager Session Managerを使用してセッション情報を管理する
Systems Manager Session Managerは、EC2インスタンスへブラウザ（マネジメントコンソール）やAWS CLIからセキュアにログインできる機能です。
クライアントとサーバー間のセッション情報を管理する機能はないので、誤りです。
・AWS WAFのWeb ACLを使用してセッション情報を管理する
AWS WAFは、脆弱性を突く攻撃からWebアプリケーションを保護するサービスです。Web ACLというアクセスコントロールリストで、IPアドレス、HTTPヘッダー、HTTP本文、URI文字列などに対してフィルタリングの条件を設定します。
クライアントとサーバー間のセッション情報を管理する機能はないので、誤りです。
下記の図はDynamoDBを利用した例です。
DynamoDBに保存するデータは3つのAZに自動的に保存されるので耐久性に優れており、セッション情報を永続的に保存できます。また、ElastiCacheのRedis型もマルチAZに対応しておりデータの永続保持が可能です。
したがって正解は
・Amazon DynamoDBにセッション情報を保存する
・Amazon ElastiCacheのRedisをマルチAZに設定して、セッション情報を保存する
です。
その他の選択肢については、以下のとおりです。
・Amazon ElastiCacheのMemcachedをマルチAZに設定して、セッション情報を保存する
ElastiCacheのMemcached型はセッション情報の一時保管には適していますが、マルチAZや永続保持の機能はないので障害や再起動などが発生した場合はデータが残りません。
セッション情報を永続的に保存したいという要件に合わないので、誤りです。
・AWS Systems Manager Session Managerを使用してセッション情報を管理する
Systems Manager Session Managerは、EC2インスタンスへブラウザ（マネジメントコンソール）やAWS CLIからセキュアにログインできる機能です。
クライアントとサーバー間のセッション情報を管理する機能はないので、誤りです。
・AWS WAFのWeb ACLを使用してセッション情報を管理する
AWS WAFは、脆弱性を突く攻撃からWebアプリケーションを保護するサービスです。Web ACLというアクセスコントロールリストで、IPアドレス、HTTPヘッダー、HTTP本文、URI文字列などに対してフィルタリングの条件を設定します。
クライアントとサーバー間のセッション情報を管理する機能はないので、誤りです。
参考
【Amazon ElastiCache】
Amazon ElastiCacheは、AWSが提供するデータベースサービスの一つです。
ElastiCacheはフルマネージド型のインメモリデータベースサービスです。
インメモリデータベースとはデータストレージにメモリを使用するデータベースのことです。SSDのようなディスクストレージよりも高速・安定したアクセスが可能で、主にパフォーマンスを重視するアプリケーションに利用されています。RDSやRedshiftなど他のデータベースサービスと連携し、クエリの結果をElastiCacheにキャッシュさせることで全体的なパフォーマンスを向上させる、というような使い方ができます。
また、ElastiCacheはフルマネージド型のサービスですので、データベースの拡張や障害の検出・復旧、バックアップなどはAWSによって管理されています。
【ElastiCacheのデータベースエンジン】
ElastiCacheにはKVS（Key-Value Store:Key-Value型のデータストア）型のデータベースエンジンが2つ用意されており、データベースを構築する際に選択することができます。
※Key-Value型 ... 保存するデータ（Value）とそれを特定するためのキー（Key）がペアになった構成のデータセットのこと
MemcachedおよびRedisの特徴は以下の通りです。
Memcachedにはデータの永続保持やバックアップ機能はありませんので、障害や再起動などが発生した場合はデータは残りません。保持しておかなければならないデータはストレージや他のデータベースサービスへ保存しておき、アプリケーションの高速化を目的としてキャッシュとして利用する、といったケースに向いています。
RedisはMemcachedよりも高機能なデータベースエンジンです。スナップショット（Amazon S3への保存）機能によるバックアップ・リストアが可能で、データを永続的に保持しておくことができます。
また、耐障害性の機能として「自動フェイルオーバー」「マルチAZ」があります。
自動フェイルオーバー機能により、プライマリノードに障害が発生した場合は自動的にレプリカノードがプライマリノードへ昇格します。またマルチAZではAZ（Availability Zone）を跨いだレプリケーションが可能なため、プライマリノードが存在するAZに障害が発生した場合でも、別のAZのレプリカノードを昇格させることにより運用を継続することができます。
※ElastiCacheにおいて各ノードは「キャッシュノード」と呼ばれます。キャッシュノードのうち、プライマリノードは更新・参照などを行えるノード、レプリカノードは参照のみを行えるノード（リードレプリカ）です。
さらに、RedisにはMemcachedにはない機密性があります。保管しているデータの暗号化やSSL/TLSによる通信の暗号化、クライアントをパスワードで認証するRedis認証を行うことができます。これらを利用するには、ElastiCacheのデータベース作成時に「Redis」を選択し、暗号化を有効にする必要があります。
【キャッシュ戦略】
高速アクセスを実現するElastiCacheは、アプリケーションのパフォーマンス向上に主に使用されます。データをどのように保存するかというキャッシュ戦略は、データの整合性や可用性を保ちながら、パフォーマンスを最大化するために重要です。
以下に、代表的なキャッシュ戦略の2つを紹介します。
■ライト（書き込み）スルー戦略
データベースへのデータ書き込みや更新が行われるたびに、同時にキャッシュにも書き込みます。この戦略では、キャッシュのデータが常に最新の状態を保たれるため、データの整合性が維持されます。しかし、書き込み性能が若干低下する可能性があるのと、アクセスされないデータがキャッシュに蓄積されるというデメリットもあります。
■遅延読み込み戦略
データベースへの書き込みを優先し、必要な時にのみキャッシュにデータを書き込みます。アプリケーションがデータを要求した際には、まずキャッシュを確認します。キャッシュにデータが存在する場合、そのデータをアプリケーションに返します。データが存在しない場合には、データベースからデータを取得し、そのデータをアプリケーションに提供した後でキャッシュに書き込みます。この方法では要求されたデータのみがキャッシュされるため、リソースの無駄遣いを減らすことができますが、キャッシュとデータベース間で一時的なデータの不一致が生じる可能性があります。また、キャッシュミス（キャッシュからデータを取得できなかった）した場合には、データ取得に時間がかかることがあります。
【TTL（Time To Live）】
TTL（Time To Live）とは、データがキャッシュやその他のストレージシステムに保持される時間の長さを指します。これはキャッシュ管理における非常に重要な要素であり、リソースの効率的な使用とデータの整合性維持に広く利用されています。具体的には、データに保存期間が設定され、その期間が経過すると自動的にキャッシュからデータが削除されます。このメカニズムにより、使用されない古いデータや不要なデータを効率的に整理でき、リソースの確保につながります。
Amazon ElastiCacheは、AWSが提供するデータベースサービスの一つです。
ElastiCacheはフルマネージド型のインメモリデータベースサービスです。
インメモリデータベースとはデータストレージにメモリを使用するデータベースのことです。SSDのようなディスクストレージよりも高速・安定したアクセスが可能で、主にパフォーマンスを重視するアプリケーションに利用されています。RDSやRedshiftなど他のデータベースサービスと連携し、クエリの結果をElastiCacheにキャッシュさせることで全体的なパフォーマンスを向上させる、というような使い方ができます。
また、ElastiCacheはフルマネージド型のサービスですので、データベースの拡張や障害の検出・復旧、バックアップなどはAWSによって管理されています。
【ElastiCacheのデータベースエンジン】
ElastiCacheにはKVS（Key-Value Store:Key-Value型のデータストア）型のデータベースエンジンが2つ用意されており、データベースを構築する際に選択することができます。
※Key-Value型 ... 保存するデータ（Value）とそれを特定するためのキー（Key）がペアになった構成のデータセットのこと
MemcachedおよびRedisの特徴は以下の通りです。
Memcachedにはデータの永続保持やバックアップ機能はありませんので、障害や再起動などが発生した場合はデータは残りません。保持しておかなければならないデータはストレージや他のデータベースサービスへ保存しておき、アプリケーションの高速化を目的としてキャッシュとして利用する、といったケースに向いています。
RedisはMemcachedよりも高機能なデータベースエンジンです。スナップショット（Amazon S3への保存）機能によるバックアップ・リストアが可能で、データを永続的に保持しておくことができます。
また、耐障害性の機能として「自動フェイルオーバー」「マルチAZ」があります。
自動フェイルオーバー機能により、プライマリノードに障害が発生した場合は自動的にレプリカノードがプライマリノードへ昇格します。またマルチAZではAZ（Availability Zone）を跨いだレプリケーションが可能なため、プライマリノードが存在するAZに障害が発生した場合でも、別のAZのレプリカノードを昇格させることにより運用を継続することができます。
※ElastiCacheにおいて各ノードは「キャッシュノード」と呼ばれます。キャッシュノードのうち、プライマリノードは更新・参照などを行えるノード、レプリカノードは参照のみを行えるノード（リードレプリカ）です。
さらに、RedisにはMemcachedにはない機密性があります。保管しているデータの暗号化やSSL/TLSによる通信の暗号化、クライアントをパスワードで認証するRedis認証を行うことができます。これらを利用するには、ElastiCacheのデータベース作成時に「Redis」を選択し、暗号化を有効にする必要があります。
【キャッシュ戦略】
高速アクセスを実現するElastiCacheは、アプリケーションのパフォーマンス向上に主に使用されます。データをどのように保存するかというキャッシュ戦略は、データの整合性や可用性を保ちながら、パフォーマンスを最大化するために重要です。
以下に、代表的なキャッシュ戦略の2つを紹介します。
■ライト（書き込み）スルー戦略
データベースへのデータ書き込みや更新が行われるたびに、同時にキャッシュにも書き込みます。この戦略では、キャッシュのデータが常に最新の状態を保たれるため、データの整合性が維持されます。しかし、書き込み性能が若干低下する可能性があるのと、アクセスされないデータがキャッシュに蓄積されるというデメリットもあります。
■遅延読み込み戦略
データベースへの書き込みを優先し、必要な時にのみキャッシュにデータを書き込みます。アプリケーションがデータを要求した際には、まずキャッシュを確認します。キャッシュにデータが存在する場合、そのデータをアプリケーションに返します。データが存在しない場合には、データベースからデータを取得し、そのデータをアプリケーションに提供した後でキャッシュに書き込みます。この方法では要求されたデータのみがキャッシュされるため、リソースの無駄遣いを減らすことができますが、キャッシュとデータベース間で一時的なデータの不一致が生じる可能性があります。また、キャッシュミス（キャッシュからデータを取得できなかった）した場合には、データ取得に時間がかかることがあります。
【TTL（Time To Live）】
TTL（Time To Live）とは、データがキャッシュやその他のストレージシステムに保持される時間の長さを指します。これはキャッシュ管理における非常に重要な要素であり、リソースの効率的な使用とデータの整合性維持に広く利用されています。具体的には、データに保存期間が設定され、その期間が経過すると自動的にキャッシュからデータが削除されます。このメカニズムにより、使用されない古いデータや不要なデータを効率的に整理でき、リソースの確保につながります。
脱字報告
投稿日 2023/09/03
誤った選択肢ですが、「AWS Systems Manager Sesson Manager」となっていて、iが抜けておりました。
スタッフからの返信
この投稿に対して返信しませんか？
s staff_satomi
2023/09/04 09:53
STakayuki様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。