助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30294
問題を開く
あるアプリケーションでは、データウェアハウスにおいて2種類のデータを扱っている。1つは短期的かつ頻繁に参照されるデータで、もう1つは滅多にアクセスが発生しないデータである。
これらの要件を最小のコストで満たすにはどのようにすればよいか。

正解

Amazon RedshiftとAmazon ElastiCacheを利用する。ElastiCacheへ利用頻度の高いデータのクエリ結果が保存されるようにし、以降のリクエストもElastiCacheへ行う

解説

Amazon ElastiCacheは、AWSが提供するデータベースサービスの一つです。


これらデータベースサービスのうち、データウェアハウス(DWH:複数のシステムからデータを収集・統合・蓄積し、分析に使用するデータベース)として提供されているものはRedshiftです。
※Redshiftの詳細は、分野「Redshift」を参照してください。

ElastiCacheはフルマネージド型のインメモリデータベースサービスです。
インメモリデータベースとは、データストレージにメモリを使用するデータベースのことです。SSDのようなディスクストレージよりも高速・安定したアクセスが可能で、主にパフォーマンスを重視するアプリケーションに利用されています。RDSやRedshiftなど他のデータベースサービスと連携し、クエリの結果をElastiCacheにキャッシュさせることで全体的なパフォーマンスを向上させる、というような使い方ができます。

設問では、あまりアクセスがないデータ(利用頻度の低いデータ)と、短期的に参照が頻繁に行われるデータ(利用頻度の高いデータ)の2種類があります。上述の通り、以下のように使い分けることができます:
・利用頻度の低いデータ → ストレージで扱う=Redshiftを利用する
・利用頻度の高いデータ → メモリ上(キャッシュ)で扱う=ElastiCacheを利用する
このように使い分けることによってパフォーマンスを向上させることができ、また不必要にElastiCacheを利用しないことでElastiCacheのストレージ容量を圧迫せずに済み、低コスト化にも繋がります。

以上より正解は
・Amazon RedshiftとAmazon ElastiCacheを利用する。ElastiCacheへ利用頻度の高いデータのクエリ結果が保存されるようにし、以降のリクエストもElastiCacheへ行う
です。

その他の選択肢については以下の通りです。

・Amazon RedshiftとAmazon Auroraを利用する。利用頻度の高いデータは、クエリの結果も含めてAuroraへ保存する
・Amazon RDSとAmazon Redshiftを利用する。利用頻度の高いデータはRDSへ保存し、長期的に保存しておくデータはRedshiftへ保存する
Amazon AuroraはRDSのデータベースエンジンの一つです。RDSはキャッシュとしての利用には向いていませんので誤りです。

・Amazon ElastiCacheを利用する。利用頻度に関わらずすべてのデータに高速なアクセスが可能な環境にする
すべてのデータをElastiCache上で扱っては不必要にElastiCacheのストレージ容量を使用してしまいます。本設問ではコストについても言及されているため、データの利用頻度に応じてデータベースサービスを使い分けるのがコスト面で効果的です。

参考

【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)とは、データがキャッシュやその他のストレージシステムに保持される時間の長さを指します。これはキャッシュ管理における非常に重要な要素であり、リソースの効率的な使用とデータの整合性維持に広く利用されています。具体的には、データに保存期間が設定され、その期間が経過すると自動的にキャッシュからデータが削除されます。このメカニズムにより、使用されない古いデータや不要なデータを効率的に整理でき、リソースの確保につながります。
上に戻る

表記の揺らぎ

投稿日 2022/12/12

参考のRedisの説明部で「プライマリインスタンス」「レプリカインスタンス」とありますが、直後には「プライマリノード」「レプリカノード」と書かれています。

https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html
をみると、Redisのクラスタに置いては「ノード」の表記がより正しいようなので、細かいところ恐縮ですがそちらへの統一をご検討いただけると幸いです。

2022/12/13 02:39

修正を確認いたしました。ご対応ありがとうございます。


コメント

この返信に対して
コメントを記入できます

スタッフからの返信

s staff_satomi

2022/12/12 16:38

nanasi2424様 ご指摘の点を修正いたしました。 ご報告下さり、誠にありがとうございます。

この投稿に対して返信しませんか?