助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30278
問題を開く
データを保存する先のAWSサービスについて検討している。以下の条件において最適なサービスはどれか。
・過去に保存したデータへのアクセス頻度は1ヶ月に1回程度
・データの取り出しは1桁ミリ秒で完了すること
・データは永続的に保存可能
・データ量の上限は不明
・コスト的な制約はない

正解

Amazon DynamoDB

解説

以下はAWSが提供する主なデータベースサービスです。


DynamoDBはNoSQLのデータベースサービスで、Key-Value型という「保存するデータ(Value)」とそれを特定するための「キー(Key)」がペアになっている形式のデータを扱います。シンプルな構造であるためデータアクセスのパフォーマンスは非常に高く、ピーク時には秒間2000万件のリクエストに対応します。更にストレージの容量制限もありませんので拡張性にも優れています。
また、DynamoDBでは、テーブルに対する書き込み・読み込みの量と利用料金が関係しており、書き込み・読み込みは「キャパシティユニット」という単位で管理されています。これは1秒間にどれだけ読み込み・書き込みを行うかを予約する設定で、容量が大きいほど料金がかかりますが、高いパフォーマンスを発揮することができます。


設問のケースでは、データを永続的に保持することやその上限も不明であることから、ストレージの容量制限がないDynamoDBが適しています。
また、アクセス頻度の低いデータであっても取り出しが1桁ミリ秒(千分の一秒)という高パフォーマンスを求められていますが、コスト面の制約がない、という条件からRCUを大きくすることで対応が可能です。

以上より正解は
・Amazon DynamoDB
です。

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

・Amazon ElastiCache for Memcached
ElastiCacheは非常に高速なアクセスが可能なインメモリデータベースで、主にキャッシュなど一時的なデータ保存に利用されます。使用できるメモリ容量は、契約したノードタイプによって上限が決められています。また、ElastiCache for Memcachedにはデータの永続保持やバックアップ機能はありません。
本設問の条件「データを永続的に保存可能」には適していないため誤りです。

・Amazon RDS
・Amazon Aurora
いずれもRDB型のデータベースで、AuroraはRDSで利用可能なデータベースエンジンの一つです。
いずれもストレージには容量制限があり、またパフォーマンス観点ではRDBよりもデータ構造がシンプルなNoSQLの方が優れていますので、本設問のケースには適しません。

参考

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


「NoSQL」は多くの場合、SQLを使用する「リレーショナルデータベース(RDB)」に属さないデータベース、といった意味で使われます。
本項では、DynamoDBが扱うデータ構造、DynamoDBの特徴である高可用性、キャパシティ、データ参照時の一貫性、自動スケール、更新ログの保存機能であるStreams、Time To Live(TTL)機能について解説します。

●データ構造
・Key-Value型
DynamoDBでは、Key-Value型という「保存するデータ(Value)」とそれを特定するための「キー(Key)」がペアになっている形式のデータを扱います。

例えば「ユーザーが保有しているアイテム」を管理するには以下のように表せます。

新たにアイテムが追加された場合や追加されたアイテムを初めて保有する際にも、既存のデータ構造に変更を加えることなく新しい項目を追加することができます。

Key-Value型で構成された項目の塊をテーブルと呼びます。ある表AとBのデータを結合して結果を得たり分析するような利用方法よりも、上例のように単一のデータを格納・取得するというシンプルな利用に向いています。シンプルな構造であるためパフォーマンスは非常に高く、ピーク時には秒間2000万件のリクエストに対応します。更にストレージの容量制限もありませんので拡張性にも優れています。

・ドキュメント型
DynamoDBでは、ドキュメント型という、階層的なデータ構造をもった形式のデータを扱います。


構造的にはKey-Value型を背景に持ちますが、ドキュメント型ではデータをJSON形式で表現することができます。JSONは、階層的なデータ構造を簡単に表現することができるデータフォーマット(形式)です。DynamoDBにJSON形式のデータを格納することで、階層的なデータの効率的な管理が実現できます。

さらに、DynamoDBは「スキーマレス」と言われることが多いデータベースで、属性の追加や変更が非常に柔軟に行えます。スキーマとはデータベースの構造のことです。新たなデータ項目を追加する場合、通常はスキーマの変更と既存の格納済みデータへのスキーマ変更に対応する修正を行う必要がありますが、DynamoDBのようなデータベースではプライマリキー(データを一意に識別するために使われる項目)以外の属性については、スキーマの変更作業自体が不要になります。

また、DynamoDBでは、テーブル内のデータに高速にアクセスできるように様々なインデックス(書籍の索引のようにデータを一意に特定する仕組み)を作成することができます。インデックスを効果的に作成することでスループットを向上させることができ、コストダウンの効果も期待できます(スループットとコストの関係については、下部「●キャパシティ」も参照してください)。

●高可用性
・3つのAZにデータを分散して保存
DynamoDBでは、単一障害点(SPOF: Single Point Of Failure:ある箇所が故障すると、システム全体が機能不全になる箇所)を持たず、高い可用性を誇ります。
また、データは3つのAZに自動的に保存されますので、耐障害性にも優れています。


各AZのデータはパーティションという単位で分散して保存されます。パーティション分割によって一か所にデータを集中させないようにすることで、プロビジョニング(予約)されたスループットを保てるようにしています。なお、パーティション分割はAWSによって自動的に行われるので、ユーザーが通常意識することはありません。

・バックアップ
DynamoDBには2つのバックアップ方法があります。
「オンデマンドバックアップ」は、ユーザーが任意のタイミングで作成するバックアップのことです。マネジメントコンソールまたはAPIを利用して、テーブルの完全なバックアップを作成します。
自動的にバックアップを行いたい場合は「ポイントインタイムリカバリ(PITR)」を有効にします。オンデマンドバックアップとは違い、差分バックアップが定期的に自動で取得されます。リカバリ時は、35日前まで遡ることができます。

●キャパシティ
DynamoDBでは、テーブルに対する書き込み・読み込みの量と利用料金が関係しています。
・オンデマンドモード ... 書き込み・読み込みのリクエスト単位で利用料金がかかる
・プロビジョニングモード ... 1秒間に行う書き込み・読み込みの量で利用料金が異なる

プロビジョニングモードの書き込み・読み込みは、「キャパシティユニット」という単位で管理されています。これは1秒間にどれだけ読み込み・書き込みを行うかを予約する設定で、容量が大きいほど料金がかかります。

キャパシティユニットは、テーブル作成時にはWCU、RCUともに 5 に設定されています。キャパシティユニットの変更はいつでも行うことができます。
また、データアクセスの負荷に応じてキャパシティユニットを自動的にスケール(増減)することもできます。常に高いパフォーマンスを維持しておく必要がないため、コストを抑えたい場合に有用です。

大規模に利用する場合は「リザーブドキャパシティ」を用いることもできます。
リザーブドキャパシティはWCU、RCUともに100ユニット単位で1年または3年の期間で予約購入するサービスです。通常のプロビジョニングモードよりも割安に利用できます。


・キャパシティユニットとパーティション
パーティション(「●高可用性」を参照)の数やサイズは、キャパシティユニットの値をもとにAWSが算出します。パーティション分割はプロビジョニングされたスループットを保つための仕組みですから、キャパシティユニットの値を大きくする(=1秒間の処理件数を増やす)と、パーティションの数も多くなります。

●データ参照時の一貫性
アプリケーションが書き込みを行った場合、3つのAZのテーブルのうち2つのテーブルに書き込みができた時点で完了とみなされます。残りの1つには後からレプリケートされます。このレプリケートされるまでの間は、書き込みが行われた後の結果と書き込みが行われる前の結果が混在することになります。このとき、レプリケートが完了していないテーブルに対して読み込みが発生すると、古いデータを読み出してしまう可能性があります。
DynamoDBでは以下の2つの読み込みモードをサポートしています。
○結果整合性のある読み込み(デフォルト)
 一時的には読み込んだデータが最新ではないタイミングが発生する可能性はあるが、最終的には読み出すデータは最新のものとなる(書き込みから少し時間をおくことで回避できる)。
○強力な整合性のある読み込み
 必ず最新のデータを取り出すことができる。ただし読み込み時のコストが2倍になる、レイテンシが高くなる可能性がある、などの条件がつく。

●自動スケール
データ容量が増えた場合でも、DynamoDBは自動的にスケールアウト(拡張)されます。データベース用ノードの追加やディスクを増やすといった作業がないため、ダウンタイム(サービスを停止する時間)がなくサービスを提供し続けることができます。

●更新ログ保存機能(DynamoDB Streams)
DynamoDB Streams(ストリーム)とは、テーブルに対して行われた直近の24時間の変更(追加や更新、削除)をログに保存する機能です。ストリームを参照することによって、いつ誰がどのようにテーブルを更新したかがわかります。
ログには、アプリケーションがリアルタイムにアクセスできるため、変更内容に応じて処理を組み込むことができます。例えば、ログを監視し問題のある処理があった場合はアラートを上げさせたり、プロフィール画像を更新(追加)したらフレンドに通知させるというような運用が可能です。

なお、DynamoDB Streamsは非同期で動作するため、ストリームを有効にしても元のテーブルのパフォーマンスには影響を与えません。



●Time To Live(TTL)機能
Time To Live(TTL)機能は、特定の時点で自動的にデータ項目を削除する機能です。項目にTTL属性(UNIX時間形式のタイムスタンプ)を設定することで、その時刻が来たときにDynamoDBが自動的に項目を削除します。このプロセスは完全に自動化されており、追加の管理やコストが発生しません。これにより、データのライフサイクル管理が簡素化され、不要なデータによるストレージコストの増加を防ぎます。

【DynamoDB Accelerator(DAX)】
DynamoDB Accelerator(DAX)は、DynamoDBのインメモリのキャッシュクラスタです。
DAXを利用することにより、ミリ秒(千分の一秒)だったレスポンスをマイクロ秒(百万分の一秒)レベルのパフォーマンスにまで向上させることができます。

またキャッシュであるDAXからデータを取得することができればDynamoDBへアクセスする回数も削減されるため、RCUを抑えることもできます。

【グローバルテーブル】
DynamoDBのグローバルテーブルは、DynamoDBテーブルを複数のリージョンにまたがって運用できるサービスです。複数のリージョンにDynamoDBテーブルが自動的にレプリケートされ、ユーザーは地理的に近いリージョンのDynamoDBテーブルへ高速な読み込みと書き込みが可能になります。データのレプリケーションは通常1秒以内に完了し、リージョン間のデータ冗長化によって高可用性が確保されます。
下記のように、グローバルテーブルのレプリケート先のリージョンはユーザーが指定します。


【S3へのエクスポート】
DynamoDBでは、既存のテーブルデータを任意のS3バケットに直接エクスポートする機能が提供されています。ユーザはこの機能のために独自のアプリケーションを用意したり、追加のコードを記述したりする必要はありません。また、この機能を使用したデータのエクスポートでは、対象のテーブルに設定されたRCUを消費せず、テーブルの可用性やパフォーマンスにも影響を及ぼさないという点が大きなメリットです。



なお、この機能は、内部的にDynamoDBの継続的バックアップの機能(ポイントインタイムリカバリの前提となる機能)を使用しているため、対象のテーブルのポイントインタイムリカバリを有効にしておく必要があります。

上に戻る

誤りとされている選択肢について

公開日 2022/12/12

解説にて「本設問の条件「データを永続的に保存可能」には適していないため誤りです。」とありElastiCacheが誤りとなっています。

データベースエンジンでMemcachedを使用している場合はその通りだと思うですが、Redisを使う場合は永続的にデータを保存できる→この選択肢も誤りではない。ではないでしょうか。

※「30296」など、ElastiCacheの問題の参考部に「RedisはMemcachedよりも高機能なデータベースエンジンです。(省略) データを永続的に保持しておくことができます。」と書かれています。

2022/12/12 15:02

Amazon ElastiCacheが不正解なのは、「データを永続的に保存可能」なことではなく「データ量の上限は不明」なところかなと思いました。
ElastiCacheはノードタイプによって保存容量(メモリ)が違うので。
https://aws.amazon.com/jp/elasticache/pricing/
どちらにせよ解説には合っていないですが……。


コメント

n nanasi2424

2022/12/13 01:56

birdpixy様 ElastiCacheの容量について理解が浅かったので、ご指摘いただいて納得しました! そもそも私、「データ量の上限は不明」の一文を見落としていた様です笑

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

2022/12/13 01:57

修正ありがとうございました。
反映も確認いたしました。


コメント

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

スタッフからの返信

s staff_satomi

2022/12/12 15:57

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

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