メモ
以前取得したAWSの資格「クラウドプラクティショナー」に続き「ソリューションアーキテクトアソシエイト(SAA-C03)」取得を目指して勉強中！
いつも何か勉強するときは基本的に書きながら覚えるのでここでアウトプットします。
有益な情報かどうかは不明(笑)
スポンサーリンク
AWSのデータベースサービス
システムの構成要素としてデータベースはなくてはならない存在。
1998年以降、データベースにも複数のアーキテクチャやデータモデルが登場しており、システムの特徴に応じて最適なDBを選択することが重要なポイントとなってきている。
AWSではデータベースサービスとして8つのサービスを提供している。
ソリューションアーキテクトとしてそれぞれのサービスの特徴を理解し、最適なサービスを選択する力を身につける。
データベースの2大アーキテクチャ
AWSが提供するデータベースサービスは以下の9つ。
・RDS
・Redshift
・DynamoDB
・ElastiCache
・Neptune
・QLDB
・DocumentDB
・Keyspaces
・Timestream
アーキテクチャの分類方法は様々だが、ここではRDBとNoSQLと呼ばれる2つのアーキテクチャに分類して概要を説明。
RDB(Relational Database)
関係データベースと呼ばれる。
データを表(テーブル)形式で表現し、各表の関係を定義・関連付けすることでデータを管理するDB。
RDBの各種操作にはSQLを使用する。
人間にとっても理解しやすく親しみやすいデータ管理方法。
DBの主要なアーキテクチャとして多くのシステムで利用されている。
AWSのデータベースサービスのうちRDSとRedshiftがRDBのサービス。
RDBの主なソフトウェアとしては、Oracle、Microsoft SQL、SQL Server、MySQL、Postgre SQLなどが挙げられる。
NoSQL(Not Only SQL)
RDBのデータ操作で使用するSQLを使わないデータベースアーキテクチャの総称として、NoSQLという言葉が登場した。
NoSQLの中にも様々なデータモデルが存在する。
RDBと比較した時のNoSQLの特徴としては、「柔軟でスキーマレスなデータモデル」「水平スケーラビリティ」「分散アーキテクチャ」「高速な処理」が挙げられる。
RDBが抱えるパフォーマンスとデータモデルの問題に対処することを目的に作られた新しいアーキテクチャ。
AWSのデータベースサービスのうちDynamoDB、ElastiCache、Neptune、DocumentDB、KeyspacesがNoSQLのサービス。
NoSQLのソフトウェアとしては以下のものが挙げられる。
・Redis、Memcached(Key-Value ストア)
・Cassandra、HBase(カラム志向データベース)
・MongoDB、CouchDB(ドキュメント志向データベース)
・Neo4j、Titan(グラフ志向データベース)
RDBとNoSQLの得意・不得意を理解する
これまでのシステムはDBといえばシステムの中にRDBが1つあり、保持しておくデータは全てその中に格納するという構成が大半を占めていた。
新たに登場したNoSQLは、RDBを完全に置き換えるというものではない。
1つのシステムの中でどちらか一方だけを使うのではなく、アプリケーションのユースケースに応じて複数のDBを使い分けるという考え方を持つようにする。
★AWSでは9つのデータベースサービスが提供されている。そのうちRDSとRedshiftはRDB型で、DynamoDB、ElastiCache、Neptune、DocumentDB、KeyspaceはNoSQL型。ユースケースに応じて適切に使い分けることが重要
RDS
RDSは、AWSが提供するマネージドRDBサービス。
MySQL、MariaDB、PostgreSQL、Oracle、Microsoft SQL Serverなどのオンプレミスでも使い慣れたデータベースエンジンから好きなものを選択できる。
さらに、2014年には、Amazon Auroraという、AWSが独自に開発した、クラウドのメリットを最大限に活かした新しいアーキテクチャのRDSも提供されている。
バックアップやハードウェアメンテナンスなどの運用作業、障害時の復旧作業はAWSが提供するマネージドサービスを利用することで、複雑になりがちなDBの運用を、シンプルかつ低コストに実現できる。
運用の効率化はRDSを使う大きなメリットの1つ。
RDSでは複数のDBエンジンを利用できるが、それぞれで提供されている機能のうち、RDSでは使用できない機能もある。
RDSを利用する場合は機能制限をよく確かめる。
アプリケーションの仕様上RDSでは使えない機能が必要な場合は、EC2インスタンスにDBエンジンをインストールして使うなどの検討が必要になる。
DBインスタンスはEC2と同じく、複数のインスタンスタイプから適正なスペックのものを選択できるが、DBエンジンによっては選択できるインスタンスタイプが限定されることもあるため、注意する。
★RDSはマネージドRDBサービスで、最大のメリットは運用の効率化。オンプレミスでも使い慣れたDBエンジンから好きなものを選択できる。AWS独自のAuroraも選択可能
RDSで使えるストレージタイプ
RDSのデータ保存用ストレージには、EBSを利用する。
EBSの中でもRDSで利用可能なストレージタイプは「汎用SSD」「プロビジョンドIOPS SSD」「マグネティック」の3つ。
マグネティックは過去に作成したDBインスタンスの下位互換性維持のために利用可能となっているが、新しいDBインスタンスを作成する時には基本的にSSDを選択する。
プロビジョンドIOPSは高いIOPSが求められる場合や、データ容量と比較してI/Oが高い場合に利用を検討する。
ストレージの容量は64TBまで拡張が可能。
拡張はオンライン状態で実施可能だが、拡張中は若干のパフォーマンス劣化が見られるため、利用頻度が比較的少ない時間帯に実施する。
RDSの特徴
RDSを使うことのメリットに運用の効率化・省力化が挙げられる。
それらを実現するために、RDSには便利なマネージドサービスが数多く提供されている。
マルチAZ構成
マルチAZ構成とは、1つのリージョン内の2つのAZにDBインスタンスをそれぞれ配置し、障害発生時やメンテナンス時のダウンタイムを短くすることで高可用性を実現するサービス。
DBインスタンス作成時にマルチAZ構成を選択するだけで、後は全てAWSが自動でDBの冗長化に必要な環境を作成してくれる。
本番環境でRDSを利用するときはマルチAZ構成を推奨する。
マルチAZは非常に有用なマネージドサービスだが、利用時に意識しておくべき点が2つある。
・書き込み速度が遅くなる：2つのAZ間でデータを同期するため、シングルAZ構成よりも書き込みやコミットにかかる時間が長くなる。本番環境でマルチAZ構成を利用する場合は、性能テスト実施時にマルチAZ構成にした状態でテストをする。AWSのコストを抑えるために開発環境はシングル構成にして、その環境を使って性能テストを実施したために本番のマルチAZ構成だと想定した性能が出なかった、ということもある
・フェイルオーバーには60~120秒かかる：フェイルオーバーが発生した場合、RDSへの接続用FQDNのDNSレコードが、スタンバイ側のIPアドレスに書き換えられる。異常を検知してDNSレコードの情報が書き換えられ、新しい接続先IPの情報が取得できるようになるまではDBに接続することができない。アプリケーション側でDB接続先IPのキャッシュを持っている場合は、RDSフェイルオーバー後にアプリケーションからRDSに接続できるようになるまで、120秒以上の時間がかかることもある
リードレプリカ
リードレプリカとは、通常のRDSとは別に、参照用のDBインスタンスを作成することができるサービス。
2020年現在では、全てのDBエンジンでリードレプリカが利用できるようになっている。
一方で、OracleとSQL Serverについては、利用方法や利用できるライセンス種別に制約がある。
リードレプリカを作成することで、マスターDBの負荷を抑えたり、読み込みが多いアプリケーションにおいてDBリソースのスケールアウトを用意に実現することが可能。
例えば、マスターDBのメンテナンス時でも参照系サービスだけは停止したくないという場合に、アプリケーションの接続先をリードレプリカに変更した状態でマスターDBのメンテナンスを実施する。
マスターとリードレプリカのデータ同期は、非同期レプリケーション方式である点は覚えておく必要がある。
そのため、リードレプリカを参照するタイミングによっては、マスター側で更新された情報が必ずしも反映されていない可能性がある。
しかし、リードレプリカを作成しても、マルチAZ構成のスタンバイ側へのデータ同期のようにマスターDBのパフォーマンスに影響を与えることはほとんどない。
★マスターとリードレプリカのデータ同期は非同期レプリケーション方式なので、タイミングによっては、マスターの更新がリードレプリカに反映されていないことがある
バックアップ/リストア
自動バックアップ：バックアップウィンドウと保持期間を指定することで、1日に1回バックアップ(DBスナップショット)を取得してくれるサービス。バックアップの保持期間は最大35日。バックアップからDBを復元する場合は、取得したスナップショットを選択して新規RDSを作成する。稼働中のRDSにバックアップのデータを戻すことはできない。削除するDBインスタンスを再度利用する可能性がある場合は、削除時に最終スナップショットを取得するオプションを利用する
手動スナップショット：任意のタイミングでRDSのバックアップ(DBスナップショット)を取得できるサービス。必要に応じてバックアップを取得できるが、手動スナップショットは1リージョンあたり100個までという取得数の制限がある。RDS単位ではなくリージョン単位の制限であることに注意。また、シングルAZ構成でスナップショットを取得する場合、短時間のI/O中断時間があることも要注意。この仕様は自動バックアップでも同じ。マルチAZの場合はスタンバイ側のDBインスタンスからスナップショットを取得するため、マスターのDBインスタンスには影響を与えない。この点からも、本番環境でRDSを使うときはマルチAZ構成を推奨する
データのリストア：RDSにデータをリストアする場合は、自動バックアップおよび手動で取得したスナップショットから新規のRDSを作成する。スナップショット一覧から戻したいスナップショットを選択するだけで、非常に簡単にデータをリストアできる
ポイントインタイムリカバリー：直近5分前から最大35分前までの任意のタイミングの状態のRDSを新規に作成することができるサービス。戻すことができる最大日数は自動バックアップの取得期間に準ずる。そのため、ポイントインタイムリカバリーを使用したい場合は、自動バックアップを有効にする必要がある
セキュリティ
DBには個人情報などの重要な情報や機微な情報を格納することもあるため、セキュリティには特に注意を払う必要がある。
代表的な2つのセキュリティサービス。
ネットワークセキュリティ：RDSはVPCに対応しているため、インターネットに接続できないAWSのVPCネットワーク内で利用可能なサービス。DBインスタンス作成時にインターネットからの接続を許可するオプションもあるが、デフォルトではOFFになっている。また、EC2と同様、セキュリティグループによる通信要件の制限が可能。EC2や他のAWSサービスからRDSまでの通信も各DBエンジンが提供するSSLを使った暗号化に対応している
データ暗号化：RDSの暗号化オプションを有効にすることで、データが保存されるストレージ(リードレプリカ用も含む)やスナップショットだけではなく、ログなどのRDSに関連する全てのデータが暗号化された状態で保持される。このオプションは途中から有効にすることができない。すでにあるデータに対して暗号化を実施したい場合は、スナップショットを取得してスナップショットの暗号化コピーを作成する。そして、暗号化されたスナップショットからDBのインスタンスを作成することで既存のデータの暗号化がなされる。
Amazon Aurora
Amazon Auroraは、AWSが独自に開発した、クラウドのメリットを最大限に活かしたアーキテクチャを採用した新しいDBエンジン。
2014年のサービスイン当初はMySQLとの互換性を持つエディションのみだったが、2017年10月にPostgreSQLとの互換性を持つ新しいエディションの提供が始まっている。
ここでは、他のRDSとAuroraの違いについて説明。
Auroraの構成要素
Auroraでは、DBインスタンスを作成すると同時にDBクラスタが作成される。
DBクラスタは、1つ以上のDBインスタンスと各DBインスタンスから参照するデータストレージ(クラスタボリューム)で構成される。
Auroraのボリュームストレージは、SSDをベースとしたクラスタボリューム。
クラスタボリュームは、単一リージョン内の3つのAZにそれぞれ2つ(計6つ)のデータコピーで構成され、各ストレージ間のデータは自動的に同期される。
また、クラスタボリューム作成時に容量を指定する必要がなく、Aurora内に保存されるデータ量に応じて最大64TBまで自動的に拡縮する。
Auroraレプリカ
Auroraは他のRDSと異なりマルチAZ構成オプションはない。
しかし、Auroraクラスタ内に参照専用のレプリカインスタンスを作成することができる。
他のRDSリードレプリカとの違いは、Auroraのプライマリインスタンスに障害が発生した場合にレプリカインスタンスがプライマリインスタンスに昇格することでフェイルオーバーを実現する点。
エンドポイント
通常、RDSを作成すると接続用エンドポイント(FQDN)が1つ作成され、そのFQDNを使ってDBに接続する。
Auroraでは、次の3つのエンドポイントが作成される。
・クラスタエンドポイント：Auroraクラスタのうち、プライマリインスタンスに接続するためのエンドポイント。クラスタエンドポイント経由で接続した場合、DBへの全ての操作(参照・作成・更新・削除・定義変更)を受け付けることができる
・読み取りエンドポイント：Auroraクラスタのうち、レプリカインスタンスに接続するためのエンドポイント。読み取りエンドポイント経由で接続した場合、DBに対しては参照のみを受け付けることができる。Auroraクラスタ内に複数のレプリカインスタンスがある場合は、読み取りエンドポイントに接続することで自動的に負荷分散が行われる
・インスタンスエンドポイント：Auroraを構成する各DBインスタンスに接続するためのエンドポイント。接続したDBインスタンスがプライマリインスタンスである場合は全ての操作が可能。レプリカインスタンスである場合は参照のみ可能となる。特定のDBインスタンスに接続したいという要件の場合に使用する
スポンサーリンク
Redshift
Amazon Redshiftは、AWSが提供するデータウェアハウス向けのDBサービス。
大量のデータから意思決定に役立つ情報を見つけ出すために必要な環境を素早く安価に準備できる。
これまで一般的に提供されてきたデータウェアハウスの導入コストと比較して10分の1〜100分の1程度で始めることができるため、データウェアハウスを活用したビッグデータ解析の導入障壁を一気に下げたサービス。
RedshiftはPostgreSQLとの互換性があるため、pgsqlコマンドで接続できる他、様々なBIツールがRedshiftとの接続をサポートしている。
★Redshiftはデータウェアハウス向けのDBサービスで、大量のデータから意思決定に役立つ情報を見つけ出すために必要な環境を素早く安価に構成できる
Redshiftの構成
Redshiftについては、複数ノードによる分散並列実行が大きな特徴として挙げられる。
1つのRedshiftを構成する複数のノードのまとまりをRedshiftクラスタと呼ぶ。
クラスタは1つのリーダーノードと複数のコンピュートノードから構成される。
複数のコンピュートノードをまたがずに処理が完結できる分散構成をいかに作れるかが、Redshiftを使いこなすポイントになる。
リーダーノード：SQLクライアントやBIツールからの実行クエリを受け付けて、クエリの解析や実行プランの作成を行う。コンピュートノードの数に応じて最適な分散処理が実行できるようにする、いわば司令塔のような役割。また、各コンピュートノードからの処理結果を受けて、レスポンスを返す役割も担う。リーダーノードは各クラスタに1台のみ存在する
コンピュートノード：リーダーノードからの実行クエリを処理するノード。各コンピュートノードはストレージとセットになっている。コンピュートノードを追加することでCPUやメモリ、ストレージといったリソースを増やすことができ、Redshiftクラスタとしてのパフォーマンスが向上する
ノードスライス：Redshiftが分散並列処理をする最小の単位。コンピュートノードの中でさらにリソースを分割してスライスという単位を構成する。ノード内のスライス数はコンピュートノードのインスタンスタイプによって異なる
★複数のコンピュートノードをまたがずに処理が完結できる分散構成をいかに作れるかが、Redshiftを使いこなすポイント
Redshiftの特徴
列志向型(カラムナ)データベース
データウェアハウスでは、大量のデータに対して集計処理を実行することがメインとなる。
データウェアハウスの最大のボトルネック要因はデータI/O。
そのため、必要なデータに効率的にアクセスできる仕組みはパフォーマンスの観点から非常に重要。
列志向型(カラムナ)データベースは、集計処理に使われるデータをまとめて(列単位で)管理し、ストレージからのデータ取得を効率化する。
結果として、大容量のデータに対して集計処理を実行する場合に優れたパフォーマンスを発揮する。
多くのエンコード方式への対応
データI/Oのボトルネックを発生させないための方法として、取得するデータ量を削減するアプローチもある。
Redshiftは9種類の圧縮エンコード方式に対応している。
また、列ごとに圧縮エンコード方式が指定可能なため、データの性質に合った方式を選択することで効率的なデータ圧縮を実現する。
各テーブルの列内に存在するデータは似たようなデータであることが多いため、列志向型データベースと組み合わせることでディスクI/Oをさらに軽減することが期待できる。
ゾーンマップ
Redshiftではブロック単位でデータが格納される。
1ブロックの容量は1MB。
ゾーンマップとは、そのブロック内に格納されているデータの最小値と最大値をメモリに保存する仕組みのこと。
この仕組みを活用することで、データ検索条件に該当する値の有無を効率的に判断でき、データが存在しない場合はそのブロックを読み飛ばして処理を高速化する。
柔軟な拡張性
Redshiftの柔軟な拡張性を実現している仕組みはMPPとシェアードナッシングの2つ。
これら2つの仕組みを利用してRedshiftクラスタを構成することで大量データの効率的な集計処理を実現している。
・MPP：1回の集計処理を複数のノードに分散して実行する仕組み。この仕組みがあることで、ノードの追加(スケールアウト)するだけで分散並行処理のパフォーマンスを向上させることができる
・シェアードナッシング：各ノードがディスクを共有せず、ノードとディスクセットで拡張する仕組み。複数のノードが同一のディスクを共有することによるI/O性能の劣化を回避するために採用されている
ワークロードの管理機能
Redshiftでは、多種多様なデータ解析要求を効率的に処理するための管理(WLM)機能が用意されている。Redshiftのパラメータグループにあるwlm_json_configurationパラメータでクエリの実行に関する定義が可能。
・クエリキューの定義：実行するクエリの種類に応じて専用のキューを作成する。例えば、長時間実行を要する単発のクエリ(1)と、実行時間は短いけれども定期的に実行するクエリ(2)がある場合、(1)の処理が(2)の実行に影響を与えないようにキューを分けるなどの使い方をサポートする
Redshift Spectrum
Redshift Spectrumは、S3に置かれたデータを外部テーブルとして定義できるようにし、Redshift内にデータを取り込むことなくクエリの実行を可能にする拡張サービス。
かつてRedshiftを使う上では以下のような課題があったが、それらを解決するソリューションとして登場した。
・S3からRedshiftへのデータロード(COPY)に時間がかかる
・データの増加に伴いRedshiftクラスタのストレージ容量を拡張する必要があるが、CPUやメモリも追加されてしまいコスト高になる
Redshift内のデータとS3上のデータを組み合わせたSQLの実行も可能なため、アクセス頻度の低いデータをS3に置いてディスク容量を節約する、複数のRedshiftクラスタからS3上のデータを共有するなどが可能になった。
DynamoDB
DynamoDBは、AWSが提供するマネージドNoSQLDBサービス。
テーブルやインデックスを作成する際に、読み取り・書き込みに必要なスループットを指定してリソースを確保することで、安定した性能を担保する仕組みになっている。
データを保存するディスク容量も必要に応じて拡縮することができる。
また、2018年11月より、トランザクション機能にも対応している。
このように、スループットは拡張性に優れたKey-Value型のDB。
以下のようなシステムのアプリケーション用のDBとして利用するとメリットを発揮する。
・高い信頼性と拡張性を必要とするシステム
・スループットが増減するようなピーク幅があるシステム
・大量のデータを蓄積して高速な検索が可能なシステム
・広告やゲームなどのユーザー行動履歴を管理するシステム
・Webアプリケーションの永続的セッションDB
★DynamoDBはマネージドNoSQLDBで、拡張性に優れたKey-Value型のDBを提供する
DynamoDBの特徴
高可用性設計
DynamoDBは単一障害点(SPOF)を持たない構成となっているため、サービス面での障害対応やメンテナンス時の運用を考える必要がほとんどない。
また、DynamoDB内のデータは自動的に3つのAZに保存される仕組みになっているため、非常に可用性が高いサービスだといえる。
スループットキャパシティ
DynamoDBを利用する場合、テーブルやインデックスを作成する際に読み取りと書き込みに必要なスループットを指定する。
このスループットキャパシティはいつでもダウンタイムなく変更できる。
スループットキャパシティは読み取りと書き込みそれぞれ個別に、キャパシティユニットを単位として指定する。
・Read Capacity Unit(RCU)：読み取りのスループットキャパシティを指定する指標。1RCUは、最大4KBの項目に対して、1秒あたり1回の強力な整合性のある読み取り性能、あるいは1秒あたり2回の結果的に整合性のある読み取り性能を担保することを表す
・Write Capacity Unit(WCU)：書き込みのスループットキャパシティを指定する指標。1WCUは、最大1KBの項目に対して、1秒あたり1回の書き込み性能を担保することを表す
スループットキャパシティの変更は、増加させるのに制限はない。
ただし、減少については1日9回までという制限があるため注意。
スループットキャパシティの自動スケーリング：負荷の状況に応じてスループットキャパシティを自動的に増減することができる。1日のうちでスループットに変化がある場合に指定することで、常時高スループットなキャパシティを確保しておく必要がなくなるため、コストメリットがある。EC2のAuto Scalingと同様、急激なスループットの上昇に即座に対応できるわけではないため、事前にスパイクが発生することがわかっている場合は手動でキャパシティを拡張して対処する必要がある
データパーティショニング
DynamoDBは、データをパーティションという単位で分散保存する。
1つのパーティションに対して保存できる容量やスループットキャパシティが決まっているため、データの増加や指定したスループットのサイズによって最適化された状態を保つようにパーティションを拡張する。
この制御はDynamoDB内部で自動的に行われるため、利用者が意識することはない。
プライマリキーとインデックス
DynamoDBはKey-Value型のDBであるため、格納されるデータ項目はキーとなる属性とその他の情報によって構成される。
プライマリキーはデータ項目を一意に特定するための属性で、「パーティションキー」単独のものと、「パーティションキー＋ソートキー」の組み合わせで構成されるもの(複合キーテーブル)の2種類がある。
パーティションキーだけでは一意に特定することができない場合に、ソートキーと組み合わせてプライマリキーを構成する。
また、プライマリキーはインデックスとしても利用され、データ検索の高速化に役立つ。
しかし、プライマリキーだけでは高速な検索要件を満たすことができない場合もある。
その場合にはセカンダリインデックスを作成することで高速な検索を可能にする。
セカンダリインデックスには「ローカルセカンダリインデックス(LSI)」と「グローバルセカンダリインデックス(GSL)」の2種類がある。
ローカルセカンダリインデックス(LSI)：プライマリキーはテーブルで指定したパーティションキーと同じで、別の属性をソートキーとして作成するインデックスのことを指す。元テーブルと同じパーティション内で検索が完結することから「ローカル」という名前が付けられている。LSIは複合キーテーブルにのみ作成できる
グローバルセカンダリインデックス(GSI)：プライマリキーとは異なる属性を使って作成するインデックスのことを指す。GSIはテーブルとは別のキャパシティユニットでスループットを指定する
セカンダリインデックスは便利だが、Key-Value型のDBの使い方の本質ではない。
作成した分だけデータ容量を確保する必要があったり、別のキャパシティユニットが必要であったりとコストの追加も必要になる。
複数のセカンダリインデックスを作成する必要がある場合は、RDBへの変更など構成見直しも含めて検討する必要がある。
期限切れデータの自動メンテナンス(Time to Live、TTL)
DynamoDB内の各項目には有効期間を設定でき、有効期間を過ぎたデータは自動的に削除される。
データは即時削除されるわけではなく、有効期間が切れてから最大48時間以内に削除される。
自動メンテナンスによるデータ削除操作はスループットキャパシティユニットを消費しないため、この機能を有効活用することで過去データのメンテナンスを効率的に実施できる。
DynamoDB Streams
DynamoDBに対して行われた直近24時間の追加・更新・削除の変更履歴を保持する機能。
DynamoDBを使ったアプリケーションの利用履歴を把握できることはもちろんのこと、データが変更されたタイミングを検知できるため、変更内容に応じた処理をリアルタイムで実行するなどの仕組みを構築できる。
強い一貫性を持った参照(Consistent Read)
DynamoDBは結果整合性のデータモデルを採用したDB。
しかしこのオプションを有効にすると、参照のリクエストがあった時点よりも前に書き込まれているデータが全て反映された状態のデータを元に参照結果を返すようになる。
このオプションを利用するとRCUは2倍消費される点には注意が必要。
セカンダリインデックスと同様、Key-Value型DBの本来の仕様ではないため、このオプションを使うのか、それともRDBに構成を変更する方が良いのかを検討する必要がある。
DynamoDB Accelerator(DAX)
DynamoDBの前段にキャッシュクラスタを構成する拡張サービス。
DynamoDBは元々ミリ秒単位での読み取りレスポンスを実現するが、DAXを利用すると毎秒数百万もの読み取り処理でもマイクロ秒単位での応答を実現する。
性能が格段に向上するのはもちろんのこと、DynamoDBに対して直接読み取り操作を実施する回数が減少するため、RCUの確保を抑え、コスト削減にも大きく貢献する。
スポンサーリンク
ElastiCache
ElastiCacheは、AWSが提供するインメモリ型DBサービス。
高頻度で参照するデータや検索に時間がかかるデータセットをメモリ上に保持することでシステムのパフォーマンス向上に寄与する。
ElastiCacheはMemcachedとRedisの2種類のエンジンをサポートしている。
用途に応じて最適なエンジンを選択する。
Memcached：KVS(Key-Valueストア)型インメモリデータベースのデファクトスタンダードとして広く利用されているエンジン。非常にシンプルなデータ構造で、データ処理パフォーマンスの向上に特化したキャッシュシステム。データの永続性機能はないため、メンテナンスや障害による再起動が行われた場合、全てのデータが消去される。以下の場合はMemcachedを選択する
・シンプルなキャッシュシステムを利用したい
・万が一データが消えたとしてもシステムの動作に大きな影響を与えない(なくても動く)
・必要なキャッシュリソースの増減が頻繁で、スケールアウト/スケールインをする必要がある
Redis：KVS型インメモリデータベースであることはMemcachedと同じだが、Memcachedよりも多くのデータ型が扱え、キャッシュ用途だけではなくメッセージブローカーやキューを構成する要素としても利用されている。また、ノード間のレプリケーション機能やデータ永続性機能といった可用性面も考慮された機能が実装されている。以下の用途の場合はRedisを選択する
・文字数。リスト、セット、ストアドセット、ハッシュ、ビットマップなど、多様なデータ型を使いたい
・キーストアに永続性を持たせたい
・障害発生時に自動的にフェイルオーバーしたり、バックアップ/リストアなどの可用性が欲しい
★ElastiCacheはインメモリ型DBサービスで、高頻度で参照するデータや検索に時間がかかるデータセットをメモリ上に保持することで、システムのパフォーマンス向上に寄与する
Memcached版ElastiCacheの特徴
クラスタ構成
Memcachedクラスタは、最大20のElastiCacheインスタンスで構成される。
クラスタ内に保存されるデータは各インスタンスに分散される。
クラスタを複数インスタンスで作成するときは、可用性を考慮して複数のAZにElastiCacheインスタンスを作成するようにする。
クラスタを作成すると2種類のアクセス用エンドポイントが作成される。
・ノードエンドポイント：クラスタ内の各ノードにアクセスするためのエンドポイント。特定のノードにのみ必ずアクセスしたいときに利用する
・設定エンドポイント：クラスタ全体に割り当てられるエンドポイント。クラスタ内のノードの増減を管理し、クラスタの構成情報を自動的に更新する。アプリケーションからElastiCacheサービスに接続するときは、このエンドポイントを使用する
スケーリング
Memcachedクラスタでは「スケールアウト」「スケールイン」「スケールアップ」「スケールダウン」の4つのスケーリングから必要に応じてリソースを調整できる。
スケールアウトとスケールイン時の注意点：Memcachedクラスタのデータはクラスタ内の各ノードで分散して保存される。そのため、ノード数を増減させた場合、正しいノードにデータが再マッピングされるまでの間、キャッシュミスが一時的に増加することがある
スケールアップとスケールダウン時の注意点：Memcachedクラスタをスケールアップ/スケールダウンするときは、新規のクラスタを作成する必要がある。Memcachedにはデータ永続性がないため、クラスタを再作成した場合、それまで保持していたデータはすべて削除される
Redis版ElastiCacheの特徴
クラスタ構成
Redis版では、クラスタモードの有効/無効に応じて冗長化の構成が変わる。
どちらの場合もマルチAZ構成を作成することができるため、マスターインスタンスが障害状態になった時にはスタンバイインスタンスがマスターインスタンスに昇格する。
このように冗長化構成が可能な点がMemcached版ElastiCacheとの大きな違い。
クラスタモード無効：クラスタモードが無効の場合、キャッシュデータは全て1つのElastiCacheインスタンスに保存される。また、同じデータを持つリードレプリカを最大5つまで作成できる。1つのマスターインスタンスとリードレプリカのまとまりをシャードと呼ぶ。
クラスタモード有効：クラスタモードが有効の場合、最大500のシャードにデータを分割して保存することが可能。リードレプリカは1つのシャードに対して最大5つまで作成できる。データを分散することでRead/Writeの負荷分散構成を作成することが可能
Redis版ElastiCacheのアクセス用エンドポイントは次の通り。
ノードエンドポイント：クラスタ内の各ノードに個別にアクセスするためのエンドポイント。特定のノードにのみ必ずアクセスしたい場合に使用する。クラスタモードが有効/無効どちらの場合でも使える
プライマリエンドポイント：書き込み処理用のElastiCacheインスタンスへアクセスするためのエンドポイント。クラスタモードが無効の場合に使用する
設定エンドポイント：クラスタモードが有効の場合は、この設定エンドポイントを使ってElastiCacheクラスタに対する全ての操作を行うことが可能
スケーリング
Redis版ElastiCacheのクラスタモードは、当初は構築後の「リードレプリカの追加/削除」「シャードの追加/削除」「エンジンバージョン」の変更ができないといった制約があった。
最近では、このあたりの制約は解消されている。
一方で、スケーリング中には処理の大部分がオフラインとなるため、スケーリングは以前、計画を立てて行う必要がある。
CPU使用率
Redisはシングルスレッドのため、1コアで動作する。
例えば、4コアのインスタンスタイプを使用していても、1コアしか使われないため、CPU使用率は25%が最大値。
この点には注意する。
Redis6でマルチスレッドに対応しているため、やがてRedis版ElastiCacheでも改善される可能性はある。
データ暗号化
Redis3.2.6および4.0.10以降では、RedisクライアントとElastiCache間の通信とElastiCache内に保存するデータの暗号化をサポートしている。
データ暗号化はRedis版のElastiCacheのみ対応しており、Memcached版にはデータ暗号化の機能はない。
その他のデータベース
実際に利用頻度が多いのは、RDS、Redshift、DynamoDB、ElastiCacheだが、それ以外のDBサービスについても概要だけ押さえる。
Amazon Neptune
AmazonNeptuneは、フルマネージドのグラフデータベースサービス。
グラフデータベースは、「ノード」「エッジ」「プロパティ」の3つの要素によって構成されていて、ノード間の「関係性」を表す。
データ構造はネットワーク型になり、 FacebookやTwitterのソーシャルグラフのような繋がりの関係を表現するのに適している。
それ以外にも、経路検索や購入履歴からのレコメンデーションなどにも利用される。
Amazon DocumentDB
Amazon DocumentDBは、フルマネージドなMongoDB互換のドキュメントデータベースのサービス。
互換データベースのため内部的な構造はAWSが独自に再構築したものと推測されているが、インターフェイス面でMongoDBと互換性があり、サーバー上で独自に構築したMongoDBをDocumentDBに移行することもできる。
Amazon Keyspaces
Amazon Keyspacesは、フルマネージドなApache Cassandra互換のデータベースサービス。
サービスとしての特徴はDocumentDB同様に、AWSがマネージドな互換DBを出していることにある。
DBの特徴としては、Cassandraは列志向データと行志向データの両方の特徴を兼ね備えているため、検索性も高く任意のデータをまとめて取ってくるといったことも得意としている。
Amazon Timestream
Amazon Timestreamは、フルマネージドな時系列DBサービス。
時系列DBサービスとは、時系列データを扱うことに特化したDBサービス。
時系列データとは、サーバーのメモリやCPUなどの利用状況の推移や、あるいは気温の移り変わりなど、時間的に変化した情報を持つデータのことをいう。
これらのデータをRDBの千倍の速度で、かつ低コストに処理・分析できるように設計されている。
IoTやサーバーモニタリング用途に最適。
Amazon QLDB
Amazon Quantum Ledger Database(QLDB)は、フルマネージドな台帳DBと呼ばれている。
台帳DBとは、変更履歴などを全て残し、かつその履歴を検証可能な状態にするもの。
企業の経済活動や財務活動を履歴として記録する必要がある場合に適したサービス。
同様の用途として、Hyperledger FabricやEthereumなどのブロックチェーンフレームワークが活用されることがあるが、そのインフラを管理するのは手間がかかる。
QLDBを活用することにより、同様の機能を得ることができる。
まとめ
データベース
・AWSでは9つのDBサービスが提供されている。そのうち、RDSとRedshiftはRDB(関係データベース型)で、DynamoDB、ElastiCache、Neptune、DocumentDB、KeyspacesはNoSQL型。ユースケースに応じて適切に使い分けることが重要
・RDSはマネージドRDBサービスで、最大のメリットは運用の効率化。オンプレミスでも使い慣れたDBエンジンから使い慣れた好きなものを選択できる。AWS独自のAuroraも選択可能
・Redshiftはデータウェアハウス向けのDBサービスで、大量のデータから意思決定に役立つ情報を見つけ出すために必要な環境を素早く安価に構成できる
・DynamoDBはマネージドNoSQLDBサービスで、拡張性に優れたKey-Value型のDBを提供する
・ElastiCacheはインメモリ型DBサービスで、高頻度で参照するデータや検索に時間がかかるデータセットをメモリ上に保持することでシステムのパフォーマンス向上に寄与する
