【前提知識】

• エビクション
  キャッシュが満杯の状態。キャッシュ内に必要なデータを保存し、不要なデータを追い出すこと。

• 接続文字列
  どのサーバの、どのデータベースに、どのOLEDBプロバイダーで接続するかを指定するための文字列。障害発生時に、再度更新に時間がかかる要素。AWS DLM（EBS）が有効策。

• プロキシフリート
  リソースのフリート(集団)を管理しており、DBなどの接続を仲介する（？）
  
  ・フリート
  一般的に、「集団」、「ものの集合体」を意味する。フリートを使用することによって、マルチクラスタ機能の使用と管理、複数のシステム間での一貫したポリシーの適用が可能。

• 変更データキャプチャ（Change Data Capture：CDC）
  テーブルの特定のデータソースが追加・削除・更新などの変更情報を追跡することができる。

• RDBMS（Relational DataBase Management System）
  SQLを利用して、RDBを管理するためのソフトウェアの総称 下記のソフトウェアを選択して利用できる。（各ソフトウェアを利用したDBを作成可能）
  ・MySQL(Amazon Auroraと互換性あり)⇒パフォーマンスの向上
  ・ORACLE
  ・Microsoft SQL Server , PostgerSQL
  ・MariaDB
  ・Amazon Aurora(MySQl,PostgerSQL)

【サーバーとセッション情報について】

セッション管理しているサーバーに障害が発生した場合、セッション情報が消える。⇒再度処理しなおす必要がある。➡各サーバーにセッション情報を置かずに、DBを利用して保存する。（セッション情報は消えない）

【NoSQLについて】

「柔軟でスキーマレスなデータモデル」「水平スケーラビリティ」「分散アーキテクチャ」「高速な処理」 RDSやAuroraなどのリレーショナルデータは、サーバレスアーキテクチャとの互換性が低い 小規模データを保存・処理するためにはNoSQLデータベースを利用することが最適。

●完全なスナップショット
インスタンスの停止が必要。マルチAZ配置で設置されたDBのスタンバイ側は読み込みをサポートしていない。

RDS (Relational Database Service)

シンプルかつ迅速にスケール、安定したパフォーマンス、低コストを実現可能なウェブサービス。(停止してから7日間経つと自動的に起動される)。
データを複数の表として管理し、それぞれの関係を定義することで、互いの関連性を扱えるデータベース。
リードレプリカは最大5台まで。
(課金：１秒単位　※プライマリとスタンバイ間のデータレプリケーションに課金は発生しない）

• リードレプリカ
  読み取り専用のDB。アクセス数が多くDBに読み取り負荷が起きている場合など、リードレプリカを構築することでプライマリデータベースへの負荷を分散する。マルチAZ構成との違いは、リードレプリカへのデータ更新は非同期で行われる点。

・マルチAZ構成にすると、自動的にフェイルオーバー構成になる

・頻繁にまたは同時に上書きおよび削除するデータに向いている
・複数の同時書き込み操作をサポートし、常に最新のデータが返される
・MySQLのストレージエンジンに【InnoDB】を利用⇒複雑なクエリ、結合処理が可能
・DBインスタンスのバックアップに自動バックアップとスナップショットをAmazon S3に保管する

【注意点】

・個別パッチは適用できない
・AutoScaling グループは使用できない
・OSにログインはできない(別途RDBMSの検討が必要)
・ファイルシステムへのアクセスができない（ファイルシステムとの連携がサポートされていない）
・作成した、DBインスタンスのパラメータの変更について➡[動的：インスタンスの再起動不要]、[静的：インスタンスの再起動必要]
・テーブルのパーティションは16TBが限度（ストレージは64TBまで拡張可能）

【ストレージ容量の確認方法】

Webコンソールの「RDS」→「インスタンス」→「モニタリングを表示」で「Free Storage Space(MB)」が表示される。

【Lambda関数を使って、RDSに接続設定(Lambdaを利用したサーバーレス構成必須)】

Lambda 関数用の Amazon RDS Proxy データベースを作成できる。 データベースプロキシは、データベース接続のプールを管理し、関数からのクエリを中継する。これにより、データベース接続を 使い果たすことなく、関数の同時実行レベルを高くすることができる。

【自動バックアップ】

DBインスタンス全体の保存期間を35日間に設定できる。破損からデーターベースを守ることができる。

【パラメータグループ】

データベースに割り当てるメモリなどのリソースの量などの設定方法を指定できる。
※データベース接続時の SSL / TLS 暗号化を強制できる

DB インスタンスとマルチ AZ DB クラスターをパラメータグループに関連付けて、データベースの設定を管理する。
Amazon RDS は、デフォルト設定を使用してパラメータグループを定義する。カスタマイズした設定を使用して独自のパラメータグループを定義できます。

〇ストレージタイプ

※GBあたりの容量課金を実施

・汎用(SSDタイプ)
・プロビジョンドIOPS(SSDタイプ)：汎用よりIOPSが高い
・マグネティック(HDDタイプ)：[GBあたりの容量課金を実施]＋IOリクエスト課金

〇暗号化

・SSL/TLSを使用してDBインスタンスへの接続を暗号化する
・保管時のデータリソースを暗号化する
・暗号化オプションの有効化はRDSインスタンス作成時のみ有効。

【作成後の暗号化】
スナップショットをコピー・暗号化し、新しいインスタンスとして復元することで可能。

【接続の暗号化（PostgreSQL）】

Amazon RDS for PostgreSQL ではカスタムパラメータグループを使用することで、データベース接続時のSSL/TLS暗号化を強制でき、通信内容を暗号化することができる。

【その他】

• AES-256暗号化
• AWS KMSによる鍵管理
• リードレプリカも同じ鍵管理を利用
• インスタンス作成時にのみ設定可能
• スナップショットのコピーの暗号化/リストア可能

〇オプション

• ポイントインタイムリカバリー
  直前5分前から最大35日間までの任意のタイミングの状態のRDSを新規に作成することができる。

• バックトラック機能
  指定した時間（上限は72時間）まで新しいDBクラスターを作成せずに、本番用データベースクラスターを巻き戻すことが可能。新しいDBクラスターを作成しないため、スナップショットからの復元やポイントタイムリカバリと比較すると迅速に復元できる。

• 拡張モニタリング有効化
  DBインスタンス上のさまざまなプロセスまたはスレッドがCPUをどのように使用しているかを常時モニタリングする。

• クロスリージョンリードレプリカ
  RDS のリージョン間リードレプリカを使用すると、ソース DB インスタンスとは異なるリージョンに MariaDB、MySQL、Oracle、PostgreSQL、または SQL Server のリードレプリカを作成することができる。
  ※DR対策に有効

• Amazon RDS on Vmware
  オンプレミスVMware 環境マネージド型データベースをデプロイできる。RDS同様に下記処理を自動化できる。
  ・ハードウェアのプロビジョニング
  ・データベースのセットアップ
  ・パッチ適用
  ・バックアップなど

〇その他機能

• RDS Performance Insights【DB負荷評価】
  データベースの負荷を可視化し、負荷を発生させている SQL ステートメントとその理由を簡単に調べられるようにする。
  
  ・設定もメンテナンスも不要で、現在は Auroraと RDSで利用可能。
  ・AWS API と SDK を使用すると、Performance Insights をオンプレミスやサードパーティーのモニタリングツールと簡単に統合できる。
  
  【データの保存期間】
  無料で 7 日間のパフォーマンス履歴を保存でき、多種多様な問題を簡単に突き止めて解決できる。もっと長い期間の保存が必要なときは、最大 2 年間のパフォーマンス履歴を有料で保存することもできる。

• RDSメンテナンスウィンドウ
  週次で設定し、AWSによって行われる、変更やソフトウェアのパッチなどが実行されるタイミングをコントロールできる。
  アップデートが突然行われると、提供しているサービスがダウンしたりと障害につながるようなことを防ぐ。
  なお、設定しない場合は、デフォルトのメンテナンスウィンドウを指定される。

• RDS Proxy【可用性機能】

交通整備	接続プールからアプリケーション接続をすぐに提供できない場合、これらの接続の処理順番を決めたり、スロットリングを行う。
スケーリング	レイテンシー増加時、データベースの障害や過負荷を発生させず、アプリケーションは継続して（RDSインスタンスが）スケーリングされる。
接続数管理	接続リクエスト数が指定した制限を超えると、アプリケーション接続を拒否 (負荷を削除) 。同時に、負荷に対してパフォーマンスを維持する。
接続プール再利用	アプリケーションの接続を維持しながらスタンバイインスタンスに自動的に接続することができるように設定されている。これにより、アプリケーションはデータベースへの接続を失った場合でも、再起動することなく接続を再確立できる。
フェイルオーバー	データベース接続プールを確立し、このプール内の接続を再利用することで、毎回新しいデータベース接続を開くことによるメモリと CPU のオーバーヘッドを回避できる。 （※認証情報を処理するオーバーヘッドを減らし、新しい接続ごとに安全な接続を確立できる。この作業の一部をデータベースに代わって処理できる）

Aurora
(RDSで使用できるデータベースの1つ)

MySQLとPostgreSQLと互換性がある分散型RDB。標準的なMySQL。

【性能】

データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速。

【構造】

・分散型で耐障害性（マルチAZ機能）と自己修復機能を備えている。

・DBインスタンスを作成すると、DBクラスタ（複数のDBインスタンス）が作成される（データ量：最大64TB）

・作成されたDBインスタンスは３つのAZにわけられる。1AZあたり2箇所、3AZに渡りコピー、つまり2×3=6箇所のストレージにコピーされる
（※3つのAZに6か所のデータをレプリケート）

・DBの冗長化構成(マスターデータベース/リードレプリカ)。スタンバイレプリカで読み取り処理は不可

【インスタンスについて】
・クラスターボリュームはDBエンジンのバージョンに応じて、128テビバイト(TiB)または64Tibまで自動的にスケールする

【バックアップ】

データベースインスタンスのトランザクションログを5分ごとにS3に保存している

〇エンドポイントのタイプ

[公式参考ページ]

〇種類

• Aurora Serverless（※AZ規模のDR(Disaster Recovery)向け）
  
  ・アプリケーションニーズに応じて、自動的に起動、シャットダウン、および容量を拡大または縮小することができる。アクセスがなければ勝手に停止するAWSのMySQL/PostgreSQLインフラ。処理負荷が一定ではない、予測困難なワークロードに適している。
  
  【構造】
  ・DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成して、最小と最大のキャパシティーを設定。
  
  ・データベースエンドポイントからプロキシフリートに接続される。（プロキシフリート＝インスタンス群のグループ？）このフリート内で、最小と最大のキャパシティー設定に基づいてリソースを自動的にスケールして調整する。
  
  [参考]
  
• Amazon Aurora Global Database
  （※リージョン規模のDR(Disaster Recovery)向け）
  複数のAWSリージョンにまたがる単一のAuroraデータベースを使って、グローバルに分散したアプリケーションを実行できる。データのマスターをプライマリリージョンに１つ、読み取り専用（最大5つ）をセカンダリリージョンに構成。書き込み操作は、プライマリAWSリージョンにあるプライマリDBクラスターに直接発行。
  
  データベースのパフォーマンスに影響を与えずにデータをレプリケートし、各リージョンでレイテンシーを低減してローカル読み取りを 高速化し、リージョン規模の停止からの災害復旧を実現する。

• Aurora Serverless v2
  Auto Scaling 機能を備えたリレーショナルデータベース。キャパシティは自動で調整される。
  コンピューティングとストレージの分離がある。結果として、個別に独立してスケールすることが可能。

★2025 年 3月 31 日 サポート終了 Aurora Serverless v1 (Aurora サーバーレスバージョン 1) Aurora 用のオンデマンドオートスケーリング構成。頻度が低く、断続的、または予測が困難なワークロードを処理するための、比較的シンプルかつコスト効率の高いオプションを提供。 コスト効率が良いのは、アプリケーションの使用状況に合わせて自動的に起動してコンピューティング性能をスケールし、不使用時にはシャットダウンするためである。 Aurora Serverless v1 DB クラスターでは、クラスターのコンピューティング容量を、アプリケーションのニーズに対応して増減させられる。 ※リードレプリカや複数のライターインスタンスをサポートする機能を提供しない。 このため、リードレプリカの作成や複数のライターインスタンスを持つDBクラスターの設定は実現できない。

〇機能性

• Amazon Aurora AutoScaling
  Aurora DB クラスター用にプロビジョニングされる Aurora レプリカのみ (リーダー DB インスタンス) の数を動的に調整する。
  ・Aurora MySQL と Aurora PostgreSQL の両方で使用できる。
  ・使用する Aurora DB は急激な接続やワークロードの増加を処理できる。

DynamoDB

※スナップショットなし【NoSQL型＝ビックデータ向けDB】

パーティショニング(分散処理)で、ビッグデータ処理や大量データ処理、ストリーミングデータを利用したリアルタイムデータ集計・処理などに最適。セッションデータやメタデータなどのシンプルな高速処理をするサーバレスDB。マルチAZ 3か所のAZに保存される。ストレージの容量制限がない。

【処理概要】

・テーブル設計(テーブル＞項目(アイテム)＞属性)

・プライマリキーの値を指定して、テーブルの項目に高速アクセスしデータを迅速に取得する。

・多くのアプリケーションでプライマリキー以外の属性を使って、セカンダリ（または代替）キーを 1 つ以上設定することで、データに効率的にアクセス。（ホストを増やし(ホスト1 A/ホスト2 B,C)、テーブルを自動的にスケールアップ/ダウンして容量を調整し、大量の処理が可能になる）

・データ項目に制限在り(アイテム最大サイズ：上限400KB)増え続けるデータを永続的に保持する。

【Lambdaとの連携】

DynamoDB は AWS Lambda と統合されているため、トリガー となるDynamoDB ストリーム 内のイベントによって実行される サーバレスアプリケーションを作成できる。DynamoDB ストリームを使用すると、DynamoDB テーブル内のデータ変更に対応する アプリケーションを構築できる。テーブルの項目が変更されるとすぐに、新しいレコードがテーブルのストリームに表示され、 Lambda は ストリームをポーリングし、新しいストリームレコードを検出すると、Lambda 関数を同期的に呼び出す。

【料金】

・コストはHTTPリクエスト(データI/O)の回数とリクエスト、レスポンスの量(データI/Oのサイズ)により計算される

【DB処理形式】

• スカラー型
  スカラー型は 1 つの値を表すことができます。スカラー型は、数値、文字列、バイナリ、ブール、および null 。

• ドキュメント型
  ドキュメント型は JSON ドキュメントなどの入れ子の属性を持つ複雑な構造を表すことができる

• セット型
  セット型は複数のスカラー値を表すことができます。セット型は、文字セット、数値セット、およびバイナリセット。

【書き込み形式】

• 条件付き書き込み
  複数のユーザーが同じ項目を同時更新することを防げる

• アトミックカウンター
  その他の書き込みリクエストを妨害することなく、無条件で増分される数値属性。

• バッチオペレーション
  アプリケーションからDynamoDBへのネットワークラウンドトリップの数を減らす

〇テーブルについて

テーブル上に複数のパーティション｛パーティションキー（大枠）＋ソートキー（分類など）｝。

• パーティションキー
  データをどのパーティションに配置するか決定する。各パーティションへのアクセスがなるべく均一になるようなパーティションキー設計を推奨。

• ソートキー
  ソートキーによってデータはパーティション内で並べ替えられて物理的に近くなるように配置される。QueryAPIではソートキーを指定して取り出すデータの範囲をフィルタできる。ソートキーの設定は任意。

• プライマリキー（主キー）
  「パーティションキー」または「パーティションキーとソートキーの複合キー」のこと。プライマリキーによってデータは一意に識別される。

• キーバリュー型
  リレーショナルなしにバリュー1行にデータをまとめることで高速処理になる

• 並列スキャン
  スキャンパフォーマンスの向上。

• 乱数サフィックス
  書き込みスループットを大幅に向上させることができる。

• 制限パラメーター
  消費されるプロビジョニング済みのスループットを制限できる（読み込みキャパシティーユニットの半分でテーブル全体のスキャンを行う）

• グローバルテーブル
  複数のリージョン間でのレプリケーション（同期）を自動化する。
  マルチリージョンフェイルオーバー機能が提供される。
  APIが利用するデータが常に最新の状態で 保たれるため、リージョン間でフェイルオーバーがスムーズに行われる。

〇キャパシティモード【24時間に1回行える】

キャパシティモードの指定はテーブル毎に設定可能。読み取りおよび書き込みスループットの課金方法と容量の管理方法を制御する。読み取り/書き込みキャパティーモードは、テーブルを作成するときに設定できる。

• キャパシティユニット
  パフォーマンスをどれだけ出せるかの設定であり、これが高いとコストがかかるがパフォーマンスが出せる。キャパシティユニットは2種類に分かれる。WCU(ライトキャパシティユニット)は書き込みできる量。RCU(リードキャパシティユニット)は読み取りできる量。
  
  ●キャパシティ
  利用量のこと。DynamoDBは項目の読み込み、書き込みの量。

• プロビジョニングモード（1時間辺りのキャパシティに対する課金）
  テーブルに設定すると、1秒間あたりのテーブルの読み込み及び書き込み回数に制限を設ける必要がある。DynamoDBにおけるスループットキャパシティの単位として、テーブルに書き込みキャパシティユニットと読み込みキャパシティユニットを指定する。この制限をスループットと言う。
  
  ※スループット：テーブルが1秒間に許容できるデータの書き込み及び読み込み上限回数のこと
  
  ●読み込みキャパシティユニット
  項目の読み込みについて、基本的な消費キャパシティユニットの計算は以下の通り。
  ・1秒あたり4KBの項目の結果整合性読み込みを2回行う：1キャパシティユニット消費
  ・1秒あたり4KBの項目の強力な整合性読み込みを1回行う：1キャパシティユニット消費
  ・1秒あたり4KBの項目のトランザクション読み込みを1回行う：2キャパシティユニット消費
  
  なお、4KB以下の項目の場合も4KBとして計算されます。5KBの項目の場合、8KBとしてサイズを4の倍数で切り上げて計算される。8KBの場合、消費キャパシティユニットも2倍。
  
  ●書き込みキャパシティユニット
  項目の書き込みについて、基本的な消費キャパシティユニットの計算は以下の通り。
  ・1秒あたり1KBの項目の書き込みを1回行う：1キャパシティユニット消費
  ・1秒あたり1KBの項目のトランザクション書き込みを1回行う：2キャパシティユニット消費
  
  なお、1KB以下の項目の場合も1KBとして計算される。1.1KBの項目場合は2KBとして計算される。2KBの場合、消費キャパシティユニットも2倍になる。テーブルの項目を読み込む方法には、PutItem、UpdateItem、DeleteItem、BatchWriteItemがある。例えば、5ユニットの書き込みキャパシティ/読み込みキャパシティをテーブルに設定すると、
  ・1秒に5KBまでの書き込み (1KB × 5回)
  ・1秒に20KBまでの強力な整合性読み込み (4KB × 5回)
  ・1秒に40KBまでの結果整合性読み込み (4KB × 10回)

• オンデマンドモード（リクエスト数課金）
  容量計画なしで 1 秒あたりに数千ものリクエストを処理できる柔軟な請求オプション。DynamoDBにおけるスループットキャパシティの単位として、書き込みキャパシティユニットと読み込みキャパシティユニットを指定する。急なトラフィックボリュームの増加に対してもDynamoDBがパフォーマンスを落とすことなく自動的に対応可能。(高可用性)
  
  ●読み込みリクエストユニット
  項目の読み込みについて、以下は1リクエストユニットが消費される。
  ・4KBの項目の結果生合成読み込みは2回
  ・4KBの項目の強力な生合成読み込みには1回
  
  項目の読み込みについて、以下は2リクエストユニットが消費される。
  ・4KBの項目のトランザクション読み込みは1回
  
  ●書き込みリクエストユニット
  項目の書き込みについて、以下は1リクエストユニットが消費されます。
  ・1KBの書き込み1回
  ・1KBのトランザクション書き込み1回

〇セカンダリインデックス

テーブルからの「属性のサブセット」と、「Query オペレーションをサポートする代替キー」で構成されるデータ構造（検索速度が向上） 1つのテーブルで 1つ以上のセカンダリインデックスを作成して、それらのインデックスに対して Query または Scan リクエストを実行する。これにより、アプリケーションは複数の異なるクエリパターンにアクセスしインデックスからデータを取得できる。ベーステーブルの項目を追加、変更、削除すると、そのテーブルのインデックスも更新され、この変更が反映される。

・すべてのセカンダリインデックスは、DynamoDB によって自動的にメンテナンスされる。

・ローカルセカンダリインデックスは基本テーブルのキャパシティモードが 継承され、グローバルセカンダリインデックスは、ベーステーブルとは別のキャパシティモードの指定が可能。

※テーブルの項目を読み込む方法には、GetItem、BatchGetItem、Query、Scan(DynamoDB API)がある。

• セカンダリ（代替）キー
  Primary Key以外の属性を使って、データに効率的にアクセスできるようにする。

• Scanオペレーション(全件走査のAPI)【全体スキャン】
  常にテーブルまたはセカンダリインデックス全体をスキャンし、より多くのRCUを消費する。頭からすべてのデータを取得する。全件走査であるscanを行うと、このキャパシティを食いつぶしてしまう危険性がある。対策として、属性(Attribute)で結果を絞り込むオプションがある。 

• クエリ（Query）オペレーション(scanと同じで、データを取得するAPI)
  プライマリキー、複合プライマリキー、パーティションキー、セカンダリインデックスといったDynamoDBのキーを条件にデータ取得ができる。ただし、検索条件に使用できるのがkeyのみ。Attributeを条件にデータ取得できない。
  
  ※DynamoDBはkeyに指定できる項目数が限られている。通常は1つ、複合プライマリキーを使用すれば2つ設定できる。 また、セカンダリインデックスを使用することで、さらに増やすことができる。しかし、keyに指定できる項目数には限界があるため、なんでもかんでもqueryで取得するというわけにはいかない。

・（属性の）射影
テーブルからセカンダリインデックスにコピーされる属性のセット。アプリケーションのクエリ要件をサポートするために、 他の属性を射影できる。その属性が自身のテーブル内にあるかのように、プロジェクション内の任意の属性にアクセスできる。
（※テーブルのパーティションキーとソートキーは常にインデックスに射影される）

【種類】

※結果整合性とは
常に2倍の強力な整合性のある読み込み容量を提供する。「1つの強力な整合性のある読み込み」＝「2つの結果整合性のある読み込み」

• グローバルセカンダリインデックス(GSI)【結果整合性】
  大規模にスケールされたアプリケーション向け。多数の異なる値が存在する属性間の関係を追跡する場合に特に便利。そのため、再上限に抑えて別のテーブルを作成でき、取得されるデータの量が少なくなる。
  
  ・あるテーブルをベースに、パーティションキーやソートキーの対象を組み替えて、見やすいようにテーブルを作成すること
  
  ・インデックスに関する クエリが、すべてのパーティションにまたがり、表内のすべての項目を対象とする
  
  ・専用のプロビジョニングされたキャパシティーユニットで異なるパーティションキーとソートキーを持つ別のインデックスを作成するのに役立つ。これによりテーブル内のデータへの高速アクセスを提供し要件を満たすことができる。

• ローカルセカンダリインデックス（LSI）【結果整合性】【強い整合性】
  
  ・すべてのパーティションの範囲が、同じパーティションキーを持つテーブルパーティションに限定される
  
  ・オリジナルのテーブルのパーティションキー・ソートキーだけでは不十分な場合、別のパーティションキー・ソートキーを 設定することができる。
  
  ・GSIのパーティションキーは固定したままでテーブルを作成すること。（テーブル作成時に作成する必要がある）
  
  ※一部のAPIを除き、基本的にデータの読み書きは「プライマリキー」を指定して行う
  ※データアクセスの特徴にあわせてパーティションキーとソートキーを設計すると良いでしょう
  
  [参考]

〇その他機能

【DynamoDBの機能】

• Amazon DynamoDB Read OnlyAcess権限
  AWSリソースにアクセスするための一時的な認証情報をEC2インスタンスに付与する安全な方法。

• Amazon DynamoDB 有効期限 (TTL)
  項目ごとのタイムスタンプを定義して、項目が不要になる時期を特定できる。指定されたタイムスタンプの日付と時刻の直後に、DynamoDB は書き込みスループットを消費することなく、テーブルから項目を削除する。TTL は、ワークロードのニーズに合わせて最新の 状態に保たれている項目のみを保持することで、保存されたデータボリュームを削減する手段として、追加料金なしで提供される。

• DynamoDB AutoScaling
  Application Auto Scalingサービスを使用して、実際のトラフィックパターンに応じて、プロビジョニングされたスループット容量を動的に 調整する。これは、コストを最適化するための最も効率的で費用効果の高いソリューション。 テーブルまたはグローバルセカンダリインデックスで、プロビジョニングされた読み込みおよび書き込み容量が拡張され、トラフィックの 急激な増加をスロットリングなしに処理できるようになる。ワークロードが減ると、Auto Scalingはスループットを低下させ、未使用の プロビジョニングされた容量の料金が発生しないようにする。
  

【テーブル関係】

• TrasactWriteItems
  テーブル内の複数のアイテムに対する調整されたオールオアナッシングの変更をサポートする。

• オプティミスティックロック
  データベースの書き込みは他のユーザーの書き込みによって上書きされないように保護する。

• ペシミスティックロック
  編集されている間、レコードごとロックされる。

• FGAC（Fine Grained Access Control）
  DynamoDB テーブルの所有者がテーブル内のデータに対して詳細なコントロールを行うための機能。具体的には、テーブル所有者は 誰（呼び出し元）がテーブルのどの項目や属性にアクセスでき、どのようなアクション（読み込み/書き込み）を実行できるか指定できる。IAMと組み合わせて使用され組織内のユーザーのアクセスを細かく管理することができる。セキュリティ認証情報および対応する アクセス権限の管理は、IAM で行う。

Red Shift　※シングル AZ 配置のみをサポート

クラウド内で完全に管理されたペタバイト規模のリレーショナルデータベース型DWH。
列指向ストレージ、データ圧縮 「ノード」というコンピューティングリソースで構成されている。

※様々なデータを集計、統合、分析のために保管しておく倉庫のようなもの。

・データをキャプチャできない

・基本的にAWSネットワークにおけるその他のサービスへのトラフィックを含むトラフィックをインターネット経由でルーティングする。

・スナップショットがクラスターのプライマリAWSリージョンで作成されると、セカンダリAWSリージョンにコピー。

・複雑な分析クエリの対応が可能 ・BIツールと簡単に統合できる標準SQLを使用。SQL準拠のワイヤプロトコルを使用して適切に構造化データに対するアドホッククエリもサポート。

・従来のオンプレミスソリューションの半分以下のコスト、標準的な Apache Sparkの3倍以上の速さで、ペタバイト規模の分析を実行できる。

【拡張された VPC のルーティング】

インターネットを介さず、VPCを介してS3を含むAWSサービスにアクセスすることができる。
クラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックがVPCを通るように強制する。

〇構造

複数のノードのまとまり(1つのリーダノード/複数のコンピュータノード)で構成されている。「ブロック」単位で ディスクにデータを格納。

※1ブロック＝1MBブロック内の最小値と最大値をメモリに保存不要なブロックを読み飛ばすことが可能

【ノードの種類】

• リーダノード
  SQLクライアントやBIツールからの実行クエリを受け付けてクエリ解析や実行プランを作成(司令塔)

• コンピュートノード
  リーダーノードからの実行クエリを処理する

• ノードスライス
  分散並列処理を実施する最小単位

• ゾーンマップ
  （各ブロックごとに最大・最小を持っているため高速にアクセス）

【ノード付帯機能】

• MPP(Massively Parallel Processing)
  1回の集計処理を複数のノードに分散する。ノードを追加するだけで実施できる仕組み

• シェアードナッシング
  各ノードがディスクを共有せず、ノードとディスクセットで拡張する仕組み

〇バックアップストレージ

データウェアハウスのスナップショットに関連するストレージ。

24 時間未満のRedshift Serverless リカバリーポイントについては、課金されない。
スナップショットスケジューリング機能を使用して作成される Redshift 自動スナップショットに料金は発生せず、最大 35 日間保持できる。

【料金発生について】
使用料は、バックアップ保持期間の延長やスナップショットの追加取得を行うと増加する。
24 時間を超えてリカバリーポイントを保持することを選択した場合、RMS の一部として料金が発生する。
コンソール、アプリケーションプログラミングインターフェイス (API)、コマンドラインインターフェイス (CLI) を使って行うマニュアルスナップショット。

[参考公式サイト]

〇その他機能

• 同時実行スケーリング機能
  一貫した高速のクエリパフォーマンスで数戦の同時ユーザーと同時クエリをサポートできる。
  自動的に新たなクラスターキャパシティーを追加し、読み取りと書き込み両方でクエリの増加に対応する。

• WLM(Work Load Management)
  Redshiftに投げ込まれるクエリに割り当てるRedshiftのリソースを指定する機能。クエリ処理を実施する際に、クエリ処理を 事前にWLMのキューを用意して、キューに対して割り当て、実行（優先）順序を定義することが可能。
  
  【構造】
  ・WLMの構成はパラメーターグループに含まれ、いくつかのクエリキューが処理に利用可能か、およびそれぞれのキューがどのように それらのキューにルーティングされるかを決定する。カスタマーパラメーターグループを作成してグループ内の下記設定を編集し、それをクラスターに関連付ける。
  ・それぞれのキュー内でいくつのクエリーが同時に実行可能か
  ・キュー間でのメモリ配分
  ・クエリーがどのようにキューにルーティングされるか。誰がクエリーを実行しているか、クエリーレベルは、などの基準
  ・あるキューにおけるクエリータイムアウト設定
  
  【キュー】
  キューによって分析時のサイズとメモリの割合や並列度、タイムアウトの時間を指定できる。(短くて実行速度の速いクエリが実行時間の長いクエリの後に留まらないようにできる。)

• Redshift Spectrum
  S3のエクサバイトの非構造化データに対してSQLクエリを直接実行できる。取得されるデータに基づいてクエリの計算能力を自動的に スケーリングするため、データセットのサイズに関係なく、S3に対するクエリは高速に実行される。 既存でRedshiftを利用している場合のロード対象データ容量に対するノード課金を抑える用途や、データロードにかかるリソース負荷や 金額負担を抑えたい場合の移行対象として利用できる。

Elastic Cache
【キャッシュDB】

NOSQL型。キーバリュー(ストア)型で非常にシンプルなデータ構造をした、インメモリデータストア（インメモリキャッシュ）。

・高速のインメモリシステムで処理を実行するため、ウェブアプリケーションのパフォーマンスを向上し、セッション情報の管理に最適。

・データをノードのメモリに保存するため、高速なデータの出し入れできる。しかし、データに永続性がなく、再起動すると、データ消去される。

・サーバノードのデプロイおよび実行をクラウド内で簡単に実行できるウェブサービス

• レプリケーション
  ノード間で同じデータを共有すること。 プライマリノードへの書き込みを、プライマリノードに紐づくすべてのリードレプリカへ非同期的に反映する。耐障害性の向上・読み込みの負荷分散を実現できる。

• シャーディング 【水平分割(horizontal partitioning)】
  データをシャード間で分割すること。データベース内の複数のテーブルにデータを分割するための一般的な概念。リクエスト増加などで単一のマスターDBの運用で限界がある場合、一定のルールに従いデータを複数のDBに振り分けることでアクセスを分散させ、読み書きの負荷分散・コストパフォーマンス向上を図ることができる。
  ・小さめのノードを、複数のシャードに分割することで、データ容量を増やしつつ、クラスタ全体のコストを抑えることができる

〇構造

（クラスタ＞シャード＞ノード）

• クラスタ
  シャードをまとめる論理グループ。複数のシャードを作ることで、シャーディングができる。データはシャード間で分割される。クラスタごとにキャッシュエンジン(Redis, Memcached)を設定でき、Redisエンジンのクラスタはクラスタモード無効、有効の2種類ある。
  
  ・Redis (クラスタモード有効) は、クラスタ 1 つにシャード 1〜15 個持つことができる。
  ・Redis (クラスタモード無効) は、クラスタ 1 つにシャード 1 個持つことができる。

• シャード
  ノードをまとめるグループ。データはノード間で同期され、2つ以上のノードを用いることで、レプリケーションできる 。1 シャードは、読み書きができるプライマリノード 1 個と、読み込み専用のセカンダリノード（リードレプリカ）0 〜 5 個を持つ。

• ノード
  ElastiCache の最小単位で、保存領域（RAM）を持つ。 設定したノードタイプによって CPU 性能や保存領域のサイズが異なる。キャッシュエンジンは、クラスタごとに設定できるため、クラスタ以下のノードすべては、同じキャッシュエンジンで動作する。

〇メモリエンジン（クラスタ構成）

• Redis
  多機能(バックアップなどの機能を持っている),シングルスレッドで動作, 全てのデータ操作は排他的である特徴
  
  ・ノード間のレプリケーション機能、フェイルオーバー機能、データ永続性機能、バックアップと復元の機能がある。
  
  ・複雑なデータ型を設定できる。複数のデータベースをサポートしている。
  
  ・インメモリデータセットのソートまたはランク付けが可能である。
  
  ・データをリードレプリカにレプリケートできる。
  
  【ノードの種類】
  シャード内で、1つのPriamryノードに対して、Replicaノードは５つまで追加可能。
  ●Priamryノード（読み書き）
  ●Replicaノード（読取り）
  
  【pub/sub機能を提供】
  publish/subscribe（発行/購読）モデルを実現するための機能。Redisに接続しているクライアント間で、メッセージを送信できる。WebSocketなどのリアルタイム通信に利用されることが多い。
  
  【認証処理】
  Redis認証トークンを使用すると、Redisはクライアントにコマンドの実行を許可する前にトークン（パスワード）を要求でき、 セキュリティが向上。データ転送時の暗号化、データ保管時の暗号化およびRedis Authによる認証を実施することが可能。
  
  【クラスターモード】
  クラスタモードを用いるとリードレプリカが追加できなくなる。
  クラスターモード無効：
  ・シャーディング不可能
  ・クラスタ作成後、ノードタイプ、エンジンタイプの変更可能。
  ・S3へのバックアップ、S3からの復元に対応。
  
  クラスターモード有効：
  ・シャーディング可能
  ・クラスタ作成後、構成の変更は基本的に不可能。
  ・クラスタレベルでのS3へのバックアップ、S3からの復元対応可能

• Memcached（ノードタイプの変更ができない）
  ・シンプルで高速（データ暗号化機能はなし）
  ・データベースなどのオブジェクトをキャッシュできる
  
  【メトリクスの種類】
  
  [参考]

〇キャッシュ方法

• レイジーキャッシング(遅延読み込み)
  オブジェクトがアプリケーションによって実際に要求された場合にのみキャッシュにデータを入力。
  
  ●メリット
  リクエストされたデータのみキャッシュするため、キャッシュがデータでいっぱいにならない。
  
  ●デメリット
  データが更新された場合に、キャッシュミスが起こらないとキャッシュされたデータは更新されない。データが古くなる可能性。キャッシュミスした場合、データの取得に時間がかかる。
  （※キャッシュへのリクエスト、DBへのリクエスト、キャッシュへの書き込みが行われるため）

• ライトスルーキャッシュ
  データがDBに書き込まれると常にデータを追加するか、キャッシュがリアルタイムに更新される。(※DBとCache両方書き込みされる) システムでの需要の増減に応じてノードを追加または削除するスケールアウトおよびスケールイン機能が利用できる。キーストアの永続性はない、バックアップと復元の機能がない。また、複数のデータベースを利用できない
  
  ●メリット：
  キャッシュのデータが古くならなく、常に最新のデータの状態になる。
  
  ●デメリット：
  すべてのデータをキャッシュに書き込むためアクセスされないキャッシュで圧迫される可能性。
  
  （「有効期限 (TTL) の値を追加する」を使用すると、無駄なスペースを最小限に抑えることができる）
  
  【データの欠落】
  ノード障害またはスケールアウトにより、新規ノードをスピンアップすると、データが欠落する。このデータは、DBで追加、更新されるまで失われ続ける。最小限に抑えるには、[遅延読み込み] を書き込みスルーで指定。

〇スケーリング方法

スケーリング方法は2種類ある。

• 水平スケーリング（horizontal）
  横方向にノード数を増減する方法。

• 垂直スケーリング（vertical）
  縦方向にノードの性能をグレードアップ、ダウンする方法。

	水平スケーリング	垂直スケーリング
Memcached	同じAZ内で最大40個ノードを追加する。処理能力向上。	性能を向上させるだけ。
Redis クラスター無	ひとつのシャード内でスケーリング。シャードの追加はできない。	新しいクラスターに変更後、ノードが作成されてデータがコピーされる。数秒のダウンタイムが生じる。
Redis クラスター有	シャードの追加ができるようになる。	ダウンタイムを発生させず、スケーリング可能。

〇セッション管理

[参考]

• ローカルセッションキャッシングを使用したスティッキーセッション
  セッションの有効性は、クライアント側のCookieや、リクエストをWebサーバーにルーティングするロードバランサーで設定できる 構成可能な期間パラメーターなど、さまざまな方法で判断できる。
  
  ●利点
  アプリケーションを実行している同じWebサーバーにセッションを保存しているため、費用対効果が高くネットワークの待ち時間がなくなり セッションの取得が高速である。
  
  ●欠点
  個々のノードで保存セッションを使用する場合、障害が発生時に障害が発生したノードに常駐するセッションが失われる可能性がある。さらに、Webサーバーの数が変更された場合、特定サーバーにアクティブなセッションが存在する可能性があり、トラフィックがサーバー 全体に不均等に分散される可能性がある。適切に軽減されない場合、アプリケーションのスケーラビリティを妨げる可能性がある。
  
• 分散セッション管理
  個々のWebサーバーからアクセスできるセッションに共有データストレージを提供。Webサーバー自体からHTTPセッションを抽象化できる。 RedisやMemcachedなどのインメモリキー/値ストアを活用する。（Key / Valueデータストアは非常に高速でミリ秒未満の遅延を提供する）
  
  ●利点
  HTTPセッションだけでなく、任意のデータをキャッシュするためにも利用できる。アプリケーションの全体的なパフォーマンスを向上。
  
  ●欠点
  ネットワーク遅延とコストの増加。

〇メトリクス

• Memcached のメトリクス　[参考公式サイト]
  
  ●Evictions
  新しく書き込むための領域を確保するためにキャッシュが排除した、期限切れではない項目の数。
  
  ●GetMisses
  キャッシュが受信したが、リクエストされたキーが見つからなかった get リクエストの数。

Amazon DocumentDB（MongoDB互換）

ドキュメントデータベースであり、JSONデータの保存、クエリ、インデックス作成が簡単に行える。MongoDBのワークロードをサポートする。 ミッションクリティカルなMongoDBのワークロードを大規模に運用するときに自動レプリケーション、継続的なバックアップ、および厳格な ネットワーク分離、可用性を提供するためにゼロから設計された、非リレーショナルデータベースサービス。また、数分で低レイテンシーの リードレプリカを最大15個まで追加し、読み取り容量を1秒あたり数百万件のリクエストにまで増加させることができる。 データのサイズは関係なし。マルチAZをサポートしていない。

【特徴】
・コンテンツおよびカタログ管理
・プロファイル管理
・モバイルアプリケーションとウェブアプリケーション

※スケーリング性能でいえばDynamoDBの方が高い。
※MongoDBと互換性あり。
DocumentDBの優位性は柔軟にクエリが書ける点。アクセスパターンが複数ある、もしくは読み切れない場合にはDocumentDBの方が便利。

Amazon Timestream

フルマネージド型。時系列データベースサービス。高速かつスケーラブルなサーバーレス時系列データベースサービス。1 日あたり数兆件規模のイベントを最大 1,000 倍の速度でより簡単に保存及び 分析できる。容量とパフォーマンスを自動的にスケールアップまたはスケールダウンするため、基盤インフラストラクチャの管理が不要。 数百テラバイトのデータを格納でき、最近のデータ用のメモリストアと履歴データ用の磁気ストアを使用してデータライフサイクル管理を簡素。 また、クエリを定期的かつ自動的にスケジュールし、受信データに対してリアルタイム分析が実行できる。

※時系列データ：メモリやCPUなどの利用状況の推移や気温の移り変わりなど時間的に変化する情報をデータとする

Amazon QLDB

フルマネージド型。台帳データベース(※台帳データベース：変更履歴などを残し、それらを履歴として検証可能なものとする)

Amazon Neptune

フルマネージド型。グラフデータサービス（「ノード」「エッジ」「プロパティ」要素から成り立つ）

Amazon Keyspaces

フルマネージド型。Apache Cassandra互換のデータベースサービス。

CDC(変更データキャプチャ)※継続的なレプリケーション

サポートされているターゲットデータストアへの初回（全ロード）の意向が完了した後、継続的な変更をキャプチャするタスクを作成できる。