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

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

例として、「RDS」と「DBインスタンス」の違いを記載すると以下になる。

・AWS RDSは、クラウド上でデータベースの管理を簡素化するマネージドサービス全体
・AWS DBインスタンスは、RDSの中で実際に動作する個々のデータベース環境。ユーザーが選択したエンジン（MySQL、PostgreSQLなど）で動作し、設定可能。

つまり、RDSはサービスの枠組みであり、DBインスタンスはそのサービスの中で動作する具体的なデータベース環境ということ。

●RDS Performance Insights【DB負荷評価】

データベースの負荷を可視化し、負荷を発生させている SQL ステートメントとその理由を簡単に調べられるようにする。RDSのパフォーマンス分析ツール。データベースのワークロードを分析し、ボトルネックや遅延の原因を特定。

・設定もメンテナンスも不要で、現在は Auroraと RDSで利用可能。
・AWS API と SDK を使用すると、Performance Insights をオンプレミスやサードパーティーのモニタリングツールと簡単に統合できる。

[データの保存期間]
無料で 7 日間のパフォーマンス履歴を保存でき、多種多様な問題を簡単に突き止めて解決できる。もっと長い期間の保存が必要なときは、最大 2 年間のパフォーマンス履歴を有料で保存することもできる。

●RDSメンテナンスウィンドウ

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

[オプション]

【可用性機能】
アプリケーションでデータベース接続をプールおよび共有して、アプリケーションのスケーリング能力を向上させる。「データベース接続のオーバーヘッド削減」、「コネクション管理」を主とする。RDS の前段に配置され、RDSのエンドポイントにプロキシとして接続するサービスでもある。

・アプリケーションがDBへの接続を失ったとしても、再起動することなく接続を再確立できる。

●RDSプロキシエンドポイント

アプリケーションがデータベースに接続する際に使用する、RDSプロキシというサービスの接続先。通常、アプリケーションは直接RDSデータベースに接続しますが、RDSプロキシを使うことで、その間にプロキシが入り、接続管理を効率化できる。

データベースに割り当てるメモリなどのリソースの量などの設定方法を指定できる。
※データベース接続時の 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による鍵管理
• リードレプリカも同じ鍵管理を利用
• インスタンス作成時にのみ設定可能
• スナップショットのコピーの暗号化/リストア可能

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

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

●Amazon Aurora AutoScaling

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

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

●Aurora Serverless（※AZ規模のDR(Disaster Recovery)向け）

オンデマンドで自動スケーリングするデータベース。アプリケーションの負荷に応じて自動的に起動・（アクセスがなければ）停止し、容量も調整される。必要なときに必要なだけリソースを利用できる。処理負荷が一定ではない、予測困難なワークロードに適している。

・秒単位での従量課金制が採用されており、非アクティブ時はコストが抑えられる。
・セットアップはシンプルで、エンドポイントの作成と容量範囲の指定のみで使用可能。
・標準のAurora設定との切り替えも簡単で、数クリックで移行できる。

[構造]
・DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成して、最小と最大のキャパシティーを設定。
・データベースエンドポイントからプロキシフリートに接続される。（プロキシフリート＝インスタンス群のグループ？）このフリート内で、最小と最大のキャパシティー設定に基づいてリソースを自動的にスケールして調整する。
[引用元サイト]

●Aurora Global Database

（※リージョン規模のDR(Disaster Recovery)向け）
複数のAWSリージョンにまたがる単一のAuroraデータベースを使って、グローバルに分散したアプリケーションを実行できる。データのマスターをプライマリリージョンに１つ、読み取り専用（最大5つ）をセカンダリリージョンに構成。書き込み操作は、プライマリAWSリージョンにあるプライマリDBクラスターに直接発行。

データベースのパフォーマンスに影響を与えずにデータをレプリケートし、各リージョンでレイテンシーを低減してローカル読み取りを 高速化し、リージョン規模の停止からの災害復旧を実現する。

※マルチマスター設定非対応
マルチマスター設定：複数のマスターノードが互いに連携して動作する構成
DBインスタンスごとに、読み取りオペレーションと書き込みオペレーションの両方を実行できる Auroraクラスターのアーキテクチャ。シングルマスターと比較するとｍマルチマスタークラスターは、マルチテナントアプリケーションなどのセグメント化されたワークロードに最適。

●Aurora Serverless v2

・オンデマンドで自動的にスケーリングされる Aurora データベースの構成
・アプリケーションの負荷に応じて容量を自動的に調整
・使用したリソースに対してのみ課金されるため、コスト最適化に有効
・手動のキャパシティ調整が不要になり、運用負荷が軽減
Auto Scaling 機能を備えたリレーショナルデータベース。キャパシティは自動で調整される。
コンピューティングとストレージの分離がある。結果として、個別に独立してスケールすることが可能。

エンドポイントを使用すると、ユースケースに基づいて各接続を対応するインスタンスまたはインスタンスグループにマッピングできる。

[公式参考ページ]

[引用元サイト]

●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 で行う。

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

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

[DB処理形式]

[書き込み形式]

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

【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回)

オンデマンドモード（リクエスト数課金）
事前の容量設定が不要で、使用量に応じて課金される柔軟な課金モデル。トラフィックの増減に応じて自動でスケーリングし、突発的なアクセス集中にも高可用性を維持したまま対応できます。低レイテンシーやSLA保証、セキュリティ機能も通常モードと同様に提供されており、新規・既存テーブル問わず利用可能です。また、1秒あたり数千リクエストを処理可能で、読み書きキャパシティユニットの指定が不要な点も特徴です。

• 読み込みリクエストユニット
  項目の読み込みについて、以下は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を除き、基本的にデータの読み書きは「プライマリキー」を指定して行う
※データアクセスの特徴にあわせてパーティションキーとソートキーを設計すると良いでしょう

[引用元サイト]

複数のノードのまとまり(1つのリーダノード/複数のコンピュータノード)で構成されている。「ブロック」単位で ディスクにデータを格納。
※1ブロック＝1MBブロック内の最小値と最大値をメモリに保存不要なブロックを読み飛ばすことが可能

[ノード付帯機能]

●MPP(Massively Parallel Processing)

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

●シェアードナッシング

各ノードがディスクを共有せず、ノードとディスクセットで拡張する仕組み

[ノードの種類]

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

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

[参考公式サイト]

Redshiftに投げ込まれるクエリ処理を実施する際に、事前に用意したWLMキューに割り当て、クエリ処理に実行（優先）順序を定義することが可能。

[構造]
構成はパラメーターグループに含まれる。
カスタマーパラメーターグループを作成してグループ内の下記設定を編集しクラスターに関連付ける。
・キュー間でのメモリ配分
・あるキューにおけるクエリータイムアウト設定
・それぞれのキュー内でいくつのクエリーが同時に実行可能か
・クエリーがどのようにキューにルーティングされるか
・誰がクエリーを実行しているか、クエリーレベルは、などの基準

[キュー]
以下情報を指定できる。
・分析時のサイズ、メモリの割合
・並列度、タイムアウトの時間

(短くて実行速度の速いクエリが実行時間の長いクエリの後に留まらないようにできる)

「動的データマスキングポリシー」を設定することで、データサイエンティストなどのユーザーが機密データにアクセスしようとする際に、クエリ（問い合わせ）を実行した時点で自動的にデータをマスキング（隠す）することができる。

[主なポイント]

• データの匿名化: ユーザーの権限に応じて、表示されるデータを動的に隠すことで、機密データを保護する。
• データ変更が不要: データベース内の元のデータを変更したり、移動したりする必要はありません。ポリシーを設定するだけで適用できる。
• 柔軟なアクセス制御: 特定のユーザーや役割（ロール）ごとに、異なるマスキングルールを適用できる。
• プライバシー要件への対応: SQLクエリを編集することなく、プライバシー要件の変更に迅速に対応することが可能。

要するに、最小限の作業で、データウェアハウス内の機密データを保護し、誰がどのようにデータを見られるかを柔軟に制御できる機能である。

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

●Redis

多機能(バックアップなどの機能を持っている),シングルスレッドで動作, 全てのデータ操作は排他的である特徴

・ノード間のレプリケーション機能、フェイルオーバー機能、データ永続性機能、バックアップと復元の機能がある。
・複雑なデータ型を設定できる。複数のデータベースをサポートしている。
・インメモリデータセットのソートまたはランク付けが可能である。
・データをリードレプリカにレプリケートできる。

[ノードの種類]
シャード内で、1つのPriamryノードに対して、Replicaノードは５つまで追加可能。
●Priamryノード（読み書き）
●Replicaノード（読取り）

[クラスターモード]
クラスタモードを用いるとリードレプリカが追加できなくなる。

• クラスターモード無効
  ・シャーディング不可能
  ・クラスタ作成後、ノードタイプ、エンジンタイプの変更可能。
  ・S3へのバックアップ、S3からの復元に対応。

• クラスターモード有効
  ・シャーディング可能
  ・クラスタ作成後、構成の変更は基本的に不可能。
  ・クラスタレベルでのS3へのバックアップ、S3からの復元対応可能
  
• [推奨]リーダーボード作成
  Redis はリーダーボードを実装する上で推奨されているサービス。
  通常ユーザのレーティングの計算にはネストされたクエリが必要だが、Redisではソートセットによって、ネストせず少ない計算量でレーティングなどのリーダーボードの作成に必要なクエリを実施できる。
  
  ★リーダーボード：プレイヤーは互いのパフォーマンスを比較するために用いる
  【使用例：引用サイト】

[pub/sub機能を提供]
publish/subscribe（発行/購読）モデルを実現するための機能。Redisに接続しているクライアント間で、メッセージを送信できる。WebSocketなどのリアルタイム通信に利用されることが多い。

[認証処理]
Redis認証トークンを使用すると、Redisはクライアントにコマンドの実行を許可する前にトークン（パスワード）を要求でき、 セキュリティが向上。データ転送時の暗号化、データ保管時の暗号化およびRedis Authによる認証を実施することが可能。

●Memcached（ノードタイプの変更ができない）

・シンプルで高速（データ暗号化機能はなし）
・データベースなどのオブジェクトをキャッシュできる

[メトリクスの種類]
⇒[引用元サイト]

[Redis と Memcached の比較]

●レイジーキャッシング(遅延読み込み)

オブジェクトがアプリケーションによって実際に要求された場合にのみキャッシュにデータを入力。

• メリット
  リクエストされたデータのみキャッシュするため、キャッシュがデータでいっぱいにならない。
  
• デメリット
  データが更新された場合に、キャッシュミスが起こらないとキャッシュされたデータは更新されない。データが古くなる可能性。キャッシュミスした場合、データの取得に時間がかかる。
  （※キャッシュへのリクエスト、DBへのリクエスト、キャッシュへの書き込みが行われるため）

●ライトスルーキャッシュ

データがDBに書き込まれると常にデータを追加するか、キャッシュがリアルタイムに更新される。(※DBとCache両方書き込みされる) システムでの需要の増減に応じてノードを追加または削除するスケールアウトおよびスケールイン機能が利用できる。キーストアの永続性はない、バックアップと復元の機能がない。また、複数のデータベースを利用できない

• メリット
  キャッシュのデータが古くならなく、常に最新のデータの状態になる。
  
• デメリット
  すべてのデータをキャッシュに書き込むためアクセスされないキャッシュで圧迫される可能性。
  （「有効期限 (TTL) の値を追加する」を使用すると、無駄なスペースを最小限に抑えることができる）

[データの欠落]
ノード障害またはスケールアウトにより、新規ノードをスピンアップすると、データが欠落する。このデータは、DBで追加、更新されるまで失われ続ける。最小限に抑えるには、[遅延読み込み] を書き込みスルーで指定。

Redis クラスターのスケーリングは、CPU 使用率（PrimaryEngineCPUUtilization）などのメトリクスに基づいて自動で行われる。スケーリングは、ターゲット追跡ポリシーを使用して、指定されたしきい値に合わせてノード数を増減。ｘスケーリング後も、アプリケーションは同じエンドポイント（Configuration endpoint）を使い続けられる。スケーリング方法は2種類ある。

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

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

[参考]

[ローカルセッションキャッシングを使用したスティッキーセッション]

セッションの有効性は、クライアント側のCookieや、リクエストをWebサーバーにルーティングするロードバランサーで設定できる 構成可能な期間パラメーターなど、さまざまな方法で判断できる。

• 利点
  アプリケーションを実行している同じWebサーバーにセッションを保存しているため、費用対効果が高くネットワークの待ち時間がなくなり セッションの取得が高速である。
  
• 欠点
  個々のノードで保存セッションを使用する場合、障害が発生時に障害が発生したノードに常駐するセッションが失われる可能性がある。さらに、Webサーバーの数が変更された場合、特定サーバーにアクティブなセッションが存在する可能性があり、トラフィックがサーバー 全体に不均等に分散される可能性がある。適切に軽減されない場合、アプリケーションのスケーラビリティを妨げる可能性がある。

●分散セッション管理

個々のWebサーバーからアクセスできるセッションに共有データストレージを提供。Webサーバー自体からHTTPセッションを抽象化できる。 RedisやMemcachedなどのインメモリキー/値ストアを活用する。（Key / Valueデータストアは非常に高速でミリ秒未満の遅延を提供する）

• 利点
  HTTPセッションだけでなく、任意のデータをキャッシュするためにも利用できる。アプリケーションの全体的なパフォーマンスを向上。
  
• 欠点
  ネットワーク遅延とコストの増加。

[Redis]

[Memcached]

・時系列データを長期保存するためにマグネティック層へ自動的に移行
・大容量データのコスト効率と耐久性を向上させる

・定期的にクエリを実行し、データの集計やフィルタリングを自動化
・保存済みの時系列データを分析してダッシュボードやレポートに活用可能