・学習率：重みの更新幅。大きすぎると発散、小さすぎると収束が遅い。機械学習における「学習率」は学習の安定性にどう影響するかを意味する。学習率を適切に下げることで損失の振動を抑え、学習を安定させることができる。

• 学習率が高い場合の問題点
  モデルの学習が大きく進みすぎるため、損失（モデルの誤り度合い）が安定せず、下がったかと思うとまた上がるという「振動」が発生します。これは、損失が最も小さくなる最適解の地点を通り過ぎてしまうことが原因。
• 学習率を下げることの効果
  学習率を下げると、モデルはパラメータをより慎重に少しずつ調整するようになります。これにより、損失の振動が抑えられ、安定して最小値に向かって学習が進みます。その結果、モデルの性能も向上する。

・バッチサイズ：一度に学習するデータの数。
・エポック数：データセットを何回繰り返して学習するか。

• パラメーター：モデルが学習によって自動的に決定する値（例：重みやバイアス）
• ハイパーパラメータ：学習前に人が設定する調整項目（例：学習率やエポック数）

学習が十分に進み、それ以上やると逆に性能が落ちそうになる一番良いタイミングで、賢くトレーニングをストップさせる手法。トレーニングを進めながら、モデルの性能を別途用意した「検証データセット」で常に監視します。そして、検証データセットに対する性能が向上しなくなった、あるいは悪化し始めた時点で、トレーニングを自動的に終了させる。

[メリット]

• 過学習の防止: モデルの性能が最大化された最適なタイミングで学習を止められる。
• 時間とコストの節約: 無駄なトレーニングを続けることを防ぎ、計算時間を短縮できる。

モデルのトレーニング中に、各層のニューロン（ノード）を一定の確率でランダムに無効化（一時的に無視）しながら学習を進める手法。この処理により、モデルが特定のニューロンや特徴の組み合わせに過度に依存することを防ぐ。
ネットワークは、より頑健で冗長性の高い表現を学習するようになり、未知のデータに対する予測性能である「汎化性能」が向上する。過学習を防ぐための効果的な「正則化」の手法として広く利用されている。

application/json , application/x-recordio-protobuf , text/csv

Autopilot

機械学習の専門知識がなくても、データセットから機械学習モデルの構築、トレーニング、デプロイのプロセスを自動化する機能（AutoML）。データの分析・前処理から、モデルの選択、ハイパーパラメータの最適化、デプロイまでを自動で実行。

[実行する主なタスク]

• データ分析と前処理
• モデルの選択
• ハイパーパラメータの最適化
• モデルのトレーニングと評価
• モデルのデプロイ

Batch Transform

大量のデータに対して一括で推論（予測）を行うための機能。リアルタイムではなく、事前に用意したデータをまとめて処理するのに向いている。

[特徴]

Canvas

プログラミング（コーディング）なしで、クリック操作だけで機械学習の予測モデルを構築できるツール。顧客がサービスを解約する可能性（カスタマーチャーン）の予測在庫の計画や価格の最適化テキストや画像の分類文書からの情報抽出など。

Clarify

機械学習モデルの入力データおよび推論結果に潜むバイアスや精度低下の原因となるデータ内の傾向を評価・特定。これにより、ユーザー層毎の予測パフォーマンスのばらつきや不公平な結果の原因を分析し、改善するための具体的な洞察を得ることができる。

Data Wrangler

機械学習（ML）で使うためのデータの準備から異常検出、特徴量エンジニアリングまでの一連のデータ準備プロセスを効率化し、迅速かつ正確に実行できるようになる。また結果の可視化を単一のツールで効率的に実行。特に、データの不均衡や特徴量間の相互依存性といった問題に、「組み込みの異常検出機能」や「可視化機能」を用いて迅速に対応。

Debugger

機械学習モデルのトレーニング中に発生する問題を自動で検知し、モデルの内部状態を可視化できるツール。必要に応じて、カスタムルールを定義してより細かい検証も可能。精度が上がらない原因調査やモデルの挙動をリアルタイムで監視したいときに有効

[対応フレームワーク]
TensorFlow , PyTorch , MXNet , XGBoost など

Experiments

複数のハイパーパラメータやアルゴリズムを試す反復的なML開発プロセスに対して、MLモデルのトレーニングや評価における実験の記録・整理・比較を支援する。

[主な機能]

Future Store

機械学習モデルのための特徴量を一元管理するためのフルマネージドサービス。特徴量（Feature）とは、MLモデルに入力する意味のあるデータのこと。Feature Storeはそれらを保存・共有・管理するための専用リポジトリ。

Ground Truth

ラベル付きデータセットを作成できる機械学習とともに、Amazon Mechanical Turk、任意のベンダー会社、または社内のプライベートワークフォースのいずれかのワーカーを使用できる。Ground Truth のラベル付きデータセット出力を使用して、独自のモデルをトレーニングできる。Amazon SageMaker AI モデルのトレーニングデータセットとして出力を使用することもできる。

ヒューマンインザループ(HITL)のラベリングタスクを支援するために設計されている。

JumpStart

様々な問題に対応できる、学習済みのオープンソースモデル。ユーザーはこれを基盤として、機械学習をすぐに始めることができる。デプロイ、微調整、評価までを一貫して行えるハブのような機能。これにより、ローコード・ノーコードの手法を容易に採用できる。

●事前トレーニング済のモデル

機械学習を容易に始めるための、幅広い問題に対応する「事前トレーニング済みのオープンソースモデル」を提供する。更新された「Studio エクスペリエンス」のJumpStartランディングページを通じて、一般的なモデルハブからこれらのモデルをデプロイ、微調整、評価することができる。

・提供されるモデルは、デプロイ前にトレーニングや調整（チューニング）が可能。
・一般的なユースケースのインフラをセットアップするための「ソリューションテンプレート」も提供される。
・SageMaker MLを使用した機械学習用の「実行可能なサンプルノートブック」も含まれる。

Market Place

機械学習モデルやアルゴリズムを簡単に導入・利用できるAWSのプラットフォーム。

Model Registry

作成した様々なバージョンの機械学習モデルを、一元的なリポジトリ（保管場所）で整理・追跡・管理するためのサービス。モデルの登録、バージョンの管理、承認やデプロイといったMLモデルのライフサイクル全体を管理する中心的なハブ。AWS内外を問わずモデルの運用が非常に効率的になる。

Model Monitor

機械学習モデルの予測精度やバイアス、入力データの品質が時間とともに劣化する「ドリフト」を検出するアラートを設定できる。モデルの再トレーニング、アップストリームシステムの監査、品質問題の修正などのアクションを実行できる。コーディングが不要な Model Monitor のビルド済みモニタリング機能を使用可能。

ML Lineage Tracking

データ準備からモデルデプロイまで、MLワークフローの各ステップの情報を詳細に記録・追跡（トラッキング）する機能。モデルが「いつ、どのデータで、どのように作られたか」という系統（リネージ）を追跡できるため、監査やコンプライアンス確認に必要な「ガバナンス機能」を提供する。

Pipelines

データ準備、トレーニング、評価、モデルデプロイといった一連のMLワークフロー全体をエンドツーエンドで自動化するためのサービス。機械学習のワークフローを有向非巡回グラフ（DAG）として可視化・管理する機能。これにより、データサイエンティストはワークフロー全体を細かく制御できる。15TBを超えるような大規模データセットも効率的に処理できる。

Serverless Inference

サーバー管理不要でAWSがMLモデルのインフラ管理やスケーリングを自動で行う便利なサービス。「プロビジョニングされた同時実行」を設定すれば、アクセスが集中する時間を予測して事前準備を行い、遅延なく安定したパフォーマンスをコスト効率よく提供できる。あらかじめ指定した数の推論環境を「ウォームアップ」（事前準備・待機）させておくことで、コールドスタートを解消し、予測されるトラフィックに対して高いパフォーマンスとスケーラビリティを確保する。

※断続的な推論リクエストには向いている。常に高い負荷がかかるため起動の遅延が生じやすい。

Inference Recommender

機械学習モデルの推論に最適なインスタンスタイプや構成を自動で提案する機能。

Studio Classic

2023年11月以降、従来の SageMaker Studio は「Studio Classic」と呼ばれ、新しい SageMaker Studio はより高速で統合されたUIを提供している。

●SageMaker Studio（新しいStudio）

AWSが提供する最新の機械学習統合開発環境。VS CodeベースのIDEやJupyterLab、RStudioを選べる柔軟なUIを備え、数秒で起動可能。Amazon Q Developer によるAI支援やGit連携、S3・RedshiftなどのAWSサービスとの統合もスムーズで、MLOpsやチーム開発に最適。

●SageMaker Studio Classic（従来型Studio）

JupyterLabベースのIDEで、データ準備からモデル構築・トレーニング・デプロイまでを一貫して行える。起動に時間がかかることがあり、Git連携やAWSサービスとの統合は手動設定が中心。個人開発や研究用途に向いている。

※AWSが提供する機械学習向けの統合開発環境（IDE）

インポートすると、コピー元のモデルと全く同じ、トレーニング済みの複製モデル（Comprehendのカスタムモデル）が新しいアカウントに作成（コピー）される。

AWSが提供する自然言語処理（NLP）サービスで、医療分野向けに特化したツール。

[主な機能]

• 非構造化医療テキストの解析
  医師のメモ、退院サマリー、検査結果などから、病名・薬剤・治療法・PHI（保護医療情報）などの医療関連エンティティを自動抽出します。
• 信頼スコアの提供
  抽出された情報には、モデルがどれだけ自信を持っているかを示す「信頼スコア」が付与されます。
• オントロジーとのリンク
  抽出したエンティティを標準化された医療用語体系（オントロジー）に結びつけることで、より高度な分析が可能です。
• 同期・非同期処理に対応
  単一文書の即時解析（同期）と、S3に保存された複数文書のバッチ解析（非同期）の両方に対応しています。

Kendraは「データソースコネクタ」という機能を使って、様々なデータソースに接続し、検索対象のインデックス（索引）を作成する。接続先として、Amazon S3の他に、Microsoft SharePointやGoogle Driveなどが挙げられている。

このコネクタは、データソースを定期的にスキャンし、ドキュメントの変更や追加を自動でインデックスに反映させるため、常に最新の状態で検索ができる。

[S3 との連携]
「Amazon S3 コネクタ」を使うことで、S3バケットに保存されているテキストファイルなどを直接インデックス化し、高精度なセマンティック検索を簡単に実現できる。S3などの多様なデータソースに接続するだけで、AIによる高精度な意味検索を簡単に構築できるサービス。インデックスを自動で最新に保ってくれるため、RAGのような高度なアプリケーションにも適している。

[主な特徴]

[構成要素]

[主な特徴]

[機能構成]

●ContentBlockerRule

Amazon Q Businessのガードレール機能の一部であり、ユーザーが制限されたトピックや禁止されたフレーズに触れた際の応答方法を制御するためのルール。制限されたトピックについて質問されたことをエンドユーザーに通知し、次にとるべき手順を提案するカスタムメッセージを設定することができる。

●グルーバルコントロール

アプリケーション全体の全ての対話に適用される。

[そのほかルール参照]

AWS Trainiumチップを搭載し、大規模言語モデル(LLM)などの高性能な深層学習（DL）トレーニングのために設計されている。他のEC2インスタンスと比較して、トレーニングにかかるコストを最大50%削減できるとされている。Trnシリーズは、機械学習トレーニングに特化しており、エネルギー効率が「非常に高い」と評価されている。

共通鍵を公開鍵で暗号化し、復号は秘密鍵。実際の通信は共通鍵暗号で暗号化/復号を行う。
安全性とパフォーマンスの両立を実現。

独自のキーマテリアルをインポートするには、最初にキーマテリアルなしで KMS キーを作成。そして、独自のキーマテリアルをインポート。キーマテリアルなしで KMS キーを作成するには、AWS KMS コンソールまたは CreateKey オペレーションを使用する。キーマテリアルなしでキーを作成するには、オリジンとして EXTERNAL を指定。

• キーマテリアル
  CMKのメタデータを除く暗号・復号に利用する部分。

[マスターキーの種類]

●KMSキー（CMK３種類）

データの暗号化、復号、再暗号化を行い、外部が使用するデータキーを作成する。キーストアに厳重に格納される。KMS キーには、キー ID、キー仕様、キー使用法、作成日、説明、およびキーステータスなどのメタデータが含まれる。

[データーキー]

●CDK(Customer Data Key)

対象のデーターを暗号化するための鍵（データキー）。
※公式の資料ではCDKという言葉はほとんど使われていない
[使われている関連記事]

●KMS Generate Data Key

アプリケーションでデータをローカルで暗号化することができる。一意の対象データキーを生成する。データキーのプレーンテキストコピーと、指定したCMKで暗号化されたコピーを返す。プレーンテキストキーを使用して、KMSの外部でデータを暗号化し、暗号化されたデータと主に暗号化されたデータキーを保存できる。

●マルチリージョンキー

複数のリージョンで同じように KMS Key を相互使用ができる。関連するマルチリージョンキーセットごとに、同じキーマテリアルおよびキーIDがあるため、1つのAWSリージョンでデータを暗号化し、再暗号化やAWS KMS へのクロスリージョン呼び出しを行うことなく異なるAWS リージョンで復号できる。
・キーは個別に管理、独立して使用、連携させて使用することもできる。

[自動キーローテーション]
KMSで生成した各キーマテリアル（ベース）を年次(1年)で更新する。エイリアス、Key ID、Key ARNは新キーに引き継がれる。

・古いキーマテリアルがすべて永続的に保存する。削除されない限り、KMS キーで暗号化されたすべてのデータを復号できる。
・サポートするのは、AWS KMS が作成するキーマテリアルを持つ対称暗号化 KMS キーのみ。（インポートしたCMKは対応不可）
・KMS キーのキーマテリアルに関するローテーションの追跡は、Amazon CloudWatch とAWS CloudTrail で実行できる。

[CloudTrailとの統合]
・KMSで内ユーザーやロール、またはAWSのサービスによってじっこうされたアクションを記録。
・KMSコンソールからのコールやKMS APIへのコード呼び出しを含むKMSのすべてのAPI呼び出しをイベントとしてキャプチャし、証跡を作成。
（リクエスト作成元のIPアドレス、リクエストの実行者・実行日など、）

・すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立つ

共通鍵と公開鍵。占有タイプ(Amazonの管理者もアクセスできない)のハードウェアで暗号化キーを保管(不正防止機能を装備したハードウェアデバイス内でキーを操作)

・物理デバイス制御とキーへのアクセスを持たないアプリケーションで秘密鍵を強力に保護できる。そのため、キーがAWS環境の外に移動されない。

CloudHSM クラスターの HSM に対するHTTPS同様の計算の一部をオフロードできる。ウェブサーバーの計算負荷が軽減され、サーバーのプライベートキーを HSM に保存するとセキュリティが強化される。このプロセスは、SSL アクセラレーションとも呼ぶ。

・ウェブサーバーとそのクライアント (ウェブブラウザ) では、SSL または TLS を使用できる。

※一般的に HTTPS として知られており、パブリック/プライベートのキーペアと SSL/TLS パブリックキー証明書を使用して、各クライアントとのHTTPS セッションを確立するため、このプロセスは、ウェブサーバーにとって多くの計算を伴う。

パスワード、ユーザーネーム、APIトークン、データベース認証、パスワードなどの一連の認証情報、OAuth トークン、または、暗号化された形式。
[参考サイト]

[アクセス]
・きめ細かい IAM とリソースベースのポリシーを使用して、シークレットへのアクセスを管理する。
・各シークレット情報は各サーバーからAPIを叩くことでシークレット情報を取得でき、認証やサーバセットアップに利用できる
・シークレットはデフォルトで KMS によって暗号化されるが、この暗号化キーの管理はAWSが行う。

[シークレットのローテーション]
(Rotation Schedule リソース)
暗号化された安全なストレージを提供され、シークレット、データベースまたはサービスの認証情報が更新する。定期的なキーローテーションスケジュールを設定できる。
※長期のシークレットを短期のシークレットに置き換えることが可能となり、侵害されるリスクを大幅に減少させることができる。

以下の2つの方式がある。

• マネージドローテーション
  ・ほとんどのマネージドシークレットで利用される。
  ・サービス側がローテーションを設定・管理するため、Lambda関数は不要。
• Lambda関数によるローテーション
  ・その他のタイプのシークレットで使用される。
  ・ユーザーが用意したLambda関数を使って、シークレットと関連サービス（データベースなど）の認証情報を更新する。

Secrets ManagerにはCloudFormationテンプレートの一部として作成できるリソースタイプが複数ある。

• クライアント側
  クライアント側でデータを暗号化し、暗号化したデータをS3にアップロードする。
  この場合、暗号化プロセス、暗号化キー、関連ツールはユーザ管理。
  
• サーバー側
  送信先で暗号化を実施する方法。暗号化キーによって管理方法が変わる。
  オブジェクトをデータセンター内のディスクに保存する前にオブジェクトレベルで暗号化。アクセスするときに復号するようにS3にリクエストする。

「AWS S3でサーバー側暗号化をしたい」というニーズに応えつつ、セキュリティ運用の方針に合わせて選べるようになっている。「AWSにキー管理を任せて利便性やセキュリティレベルを高めたい企業」はSSE-KMS。
「AWSにキーを預けたくない」「極限まで自分で管理したい」というセキュリティポリシーが厳格な組織やプロジェクトではSSE-C。一番簡単に使える暗号化方式で、「保存時に暗号化されればOK」という基本的なセキュリティ要件にはSSE-S3。クライアント側暗号化はAWS外で処理を完結したい場合に有効。

たとえば、

• 金融や医療分野などで「クラウドでも鍵は一切預けない」といった方針があるならSSE-C。
• 監査対応やIAM連携を重視する企業であればSSE-KMS。

以下設計により、認証とIP制御の柔軟な組み合わせで、Kibanaのセキュリティを強化することが可能。

[認証と保護の方法]

多数のIPをホワイトリストに登録するのは非効率なため、プロキシのIPアドレスからのみアクセス許可する方法が提案されている。KibanaはJavaScriptアプリのため、アクセス元IPは「ユーザーのIP」となり、IPベースの制御が難しくなる。

最近の使用率メトリクスの履歴データと、レコメンデーションの予測使用率を示す。最適なコストパフォーマンスのトレードオフとなるレコメンデーションを評価できる。実行中のリソースを移動またはサイズ変更するタイミングを決定し、パフォーマンスとキャパシティーの要件を満たすのに役立つ。

一連のデータレコードを持つ「シャード」のセット。各シャードのデータレコードには、Kinesis Data Streams によってシーケンス番号（順序）があるため、メッセージが失われず、重複されず、到着と同じ順序で伝送することが可能。サーバー側での暗号化をサポートする。特定の場所に転送することはできない。
（処理速度を向上させるものではない、スループット（処理量）を増加させるもの）

・デフォルトのデータ保持期間は24時間。この期間は、最大で8760時間（365日）まで延長できる。保持期間を延長すると、追加料金が発生する。

⇒データバッファリングや一括処理には不向き

●プロデューサー（データ送信側）

データレコードを Kinesis Data Streamsに送信する。たとえば、Kinesis data stream にログデータを送信するウェブサーバーはプロデューサー。コンシューマーは、ストリームのデータレコードを処理する。

●コンシューマー（データ処理側）

Kinesis Data Streams からレコードを取得して処理する。これらのコンシューマーは Kinesis Data Streams Application と呼ばれる。S3、Redshift、Splunk などのサービスに直接ストリームレコードを送信する場合は、 Kinesis Data Firehose 配信ストリームを使用できる。
[拡張ファンアウト]
コンシューマーは、シャードあたり 1 秒間に最大 2 MB のデータのスループットで、ストリームからレコードを受け取ることができる。これにより、コンシューマーはスループット性能を向上させることができる。

●Kinesis Client Library(KCL)

Kinesis Data Streamからレコードを取得して、レコードプロセッサ と呼ばれるレコードを処理するためのハンドラをアプリケーション。EC2などの上で常駐させる。アプリケーションの開発者はこの レコードプロセッサ に処理を実装するだけで良く、レコードの取得、どのレコードまで処理したかの状態、Kinesisストリームのシャード増減を自動的に管理してくれる。

●Kinesis Producer Library（KPL）

Kinesis Data Streamsが提供するライブラリ。データストリームへの書き込みプロセスを簡素化する。 バッチ処理、集約、自動再試行などの機能を提供し、データ取り込みの効率性と信頼性を向上させる。

Kinsis系のサービスではストリーミング処理を失敗した場合に、プロデューサーが断続的に再起動され複数回送信されてしまう場合がある。重複させないために主キーをレコード内に埋め込み、それぞれのレコードをユニークにする(同じものの存在を1つしか許さない状態)必要。下記2点についてはアプリケーション側で設計時に複数回送信されることを想定される。

• プロデューサーの再試行
• コンシューマーの再試行

★以下を処理実行する
１：サーバーのプロビジョニング
２：Apache Kafka クラスターの設定
３：障害時のサーバーの交換
４：サーバーのパッチとアップグレードのオーケストレート
５：高可用性のためのクラスターの構築
６：データの永続的な保存とセキュリティの確保
７：モニタリングとアラームの設定
８：負荷変動をサポートするためのスケーリングの実行

データを処理するために使用できる一式の組み込み変換を用意。これらの変換はETLスクリプトから呼び出すことができる。データは変換から変換へとDynamicFrameと呼ばれるデータ構造で渡される。

[公式参考サイト]

AWS Glue専用のデータ構造。SparkのDataFrameと似ていますが、1つのカラム（列）に複数の異なるデータ型を混在させられるという高い柔軟性が最大の特徴。

[主な機能と特徴]

生データの複雑なETL処理を簡単にするために設計されています。複数のデータ型候補を「Choice型」として保持し、後の処理で型を決定できます。SparkのDataFrameと相互に変換可能。一般的に、データの読み書きはDynamicFrameで行い、途中の複雑なデータ変換はDataFrameに変換して行うことが多い。

[構造]
DynamicFrameがデータ全体（テーブル）を表し、その中の1行のデータをDynamicRecordと呼ぶ。

[Lake Formation のタグベースアクセス制御 (LF-TBAC)]

• LF-TBAC は、属性（タグ）に基づいて許可を定義する仕組み。
• LF タグは Data Catalog リソース、Lake Formation プリンシパル、テーブル列などに付与可能。
• プリンシパルのタグがリソースタグと一致したときに操作を許可する。
• 急成長する環境やポリシー管理が複雑な状況で有効。
• IAM の属性ベースアクセス制御 (ABAC) と連動し、細粒度アクセスを提供。

[メリット]

・名前付きリソース方式よりも柔軟で効率的。
・リソースが多数あってもスケーラブルに管理可能。

メッセージを管理する入れ物のようなもの（256KB限度）デフォルトは4日間保存する。キューは手動で削除することが可能。

キューの中に格納される情報。

●メッセージグループ ID

【メッセージのタグ付け】
メッセージが特定のメッセージグループに属することを指定するタグ。 同じメッセージグループに属するメッセージは、そのメッセージグループに関連して厳密な順序で 1つずつ処理される。

●可視性タイムアウト

【重複受信防止】
メッセージの受信中に他クライアントが受信しないように防止する(30秒～12時間まで延長可能)。メッセージは受信しただけでは消えず、クライアント側から削除指示を受けた時のみ削除される。

• ChangeMessageVisibility
  新しいタイムアウト値を指定すると、メッセージの可視性を短縮または拡張できる。
• VisibilityTimeout
  メッセージが1回受信された後、他のクライアントから同じメッセージを受信不可にするための時間。
  (デフォルトは30秒. 値は0〜43,200(12時間) の間で設定可能)
• ReceiveMessage
  リクエストによってメッセージを取得。

●SQS Java 拡張クライアントライブラリ

【メッセージの保存管理】
メッセージを常に S3 に保存するか、メッセージのサイズが 256 KB を超える場合のみ保存するかを指定する。

・S3 バケットに保存されている単一のメッセージオブジェクトを参照するメッセージを送信する
・S3 バケットからメッセージオブジェクトを取得 / 削除する

複数のキューを呼び出して分散してメッセージを処理する。ただし、1つのキューにすべてのメッセージが入っているわけではない。
キューの中の先頭のデータが渡されるため、中の特定のメッセージを指定できない。
[参考]

[参考公式サイト]

[AWS SQSで利用可能なCloudWatchメトリクス]

機械学習を使って類似レコードを検出する機能。特に、完全一致しないデータ（名前のスペル違いや住所の表記揺れなど）でも、同一人物や同一商品などを見つけたいときに活躍。時系列データを日付プレフィックスでパーティション化することでクエリ効率を大幅に向上させることができる。

[特徴]
・主キーや完全一致がなくても類似レコードを検出可能
・ラベル付きデータを使って機械学習モデルをトレーニング
・match_id列を付与して、同一グループのレコードを識別
・重複排除やインクリメンタルマッチングにも対応

●Apache Spark

EMRクラスターを使用した機械学習、ストリーム処理、またはグラフ分析に役立つ分散処理フレームワークおよびプログラミングモデル。 Apache Hadoopと同様に、ビックデータのワークロードを処理するために一般的に使用されているオープンソースの分散処理システム。

※イメージ比較
・Redshiftは標準的な Apache Sparkの3倍以上の速さで、ペタバイト規模の分析を実行できる。

●Hadoop

巨大なデータを処理するため、アプリケーションの実行をハードウェアのクラスター上で行うオープンソースのソフトウェアフレームワーク（プラットフォーム）。

• HDFS（Hadoop Distributed File System）
  コモディティハードウェア上で実行するように設計された分散ファイルシステム。
  
  ・耐障害性を備えており、低コストのハードウェアに導入できるように設計されている。
  ・アプリケーションデータへの高スループットを提供する。
  ・Apache Hadoop のファイルシステムデータへのストリーミングアクセスを可能にする。

●Kerberos ベースの認証

EMRクラスターのセキュリティ強化に使用。はじめにIDとパスワードで認証に成功すると、証明のための「チケット」が発行される仕組み。

●マスターノード

クラスターを制御し、分散アプリケーションのマスターコンポーネントを実行。クラスターにサブミットされたジョブステータスを追跡して、 インスタンスグループの健全性を監視。マスターノードは一つしかなく、インスタンスグループまたはインスタンスフリートは1つの EC2で構成される。
※マスターノードが終了するとクラスターも終了するため、マスターノードは突然終了しても問題が発生しないクラスターを実行している場合にのみ、スポットインスタンスとして起動するようにするとよい。

●コアノード

マスターノードによって管理される。データノードデーモンを実行して、Hadoop Distributed File System(HDFS)の一部を使用して データを格納する。さらにタスクトラッカーデーモンを実行し、インストールされているアプリケーションを要求する。 データ上で、その他の並列計算タスクを実行。マスターノードのように、クラスターあたり最低一つのコアノードが必要。
※コアインスタンスを終了すると、データ損失のリスクがある

●タスクノード

タスクノードはオプション。Hadoop MapReduceタスクやSpark実行プログラムなど、データに対して平行計算タスクを実行するための能力を追加するために使用。データノードデーモン上で実行されることも、HDFSでデータを保存することはない。コアノードと同様に既存のユニフォームインスタンスグループにEC2インスタンスを追加することでクラスターにタスクノードを追加、あるいはタスクインスタンスフリートのターゲット容量を変更することができる。オンデマンドインスタンスなど、異なるインスタンスタイプおよび価格設定オプションを組み合わせることができる。

[対象環境]Amazon ECS、Amazon EKS（EC2 プロビジョニングされたクラスタのみ）、EC2 上の Kubernetes
[収集メトリクス]
・Pod レベルのメモリ使用率（pod_memory_utilization）
・ノードレベルのメモリ使用率（node_memory_utilization）
・サービスレベルのエラー率や CPU 使用率（Service インサイト）

[活用方法と注意点]
・AWS CloudWatch ダッシュボードで Pod／ノード／サービス単位のメトリクスを可視化できる
・サービスインサイトを有効にするには、対象となる Kubernetes サービスにタグ付けが必要
・タグがないとサービスレベルのメトリクス収集が行われない

セッション管理しているサーバーに障害が発生した場合、セッション情報が消える。⇒再度処理しなおす必要がある。➡各サーバーにセッション情報を置かずに、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]

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

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

S3 に格納されるオブジェクトのコンテナ。すべてのオブジェクトはバケット内に格納される。 バケットへのアップロードは書き込みアクセス許可が必要。

• AWSユーザーの正規ID
  他のAWSアカウントにアクセスを許可するために必要

[s3 Sync コマンド]
S3バケット間でデータを同期するために使用される。
※EFSやFSx for Windows File Server を転送先としてサポートしていない

S3 に格納される基本エンティティ(ファイルデータ)。オブジェクト(ID)データとメタデータで構成される。キー (名前) とバージョン ID によってバケット内で一意に識別される。オブジェクト所有者はオブジェクトのアクセスコントロールリスト（ACL）を更新することによって、バケット所有者にオブジェクトのフルコントロールを付与できる。

・ファイルが保存されるグループに対して、それぞれにセキュリティーポリシーを適用する

[オブジェクトの取得方法]

• 1 回で取得
  Amazon S3 に格納されているオブジェクトを 1 回の GET オペレーションで取得。
  
• オブジェクトを複数回に分けて取得
  GET リクエストの Range HTTP ヘッダーを使用すると、 S3 に格納されているオブジェクトの特定のバイト範囲を取得できる。アプリケーションの準備ができた時点でいつでも残り部分の取得を再開でき、この再開可能なダウンロードは、オブジェクトデータの一部だけが必要な場合に便利。また、ネットワーク接続の状態が悪く、障害に対処する必要がある場合にも役立つ。

[オブジェクトのアップロード方法]

AWS SDK、REST API、または AWS CLI を使用して、
・1 回のオペレーションでオブジェクトをアップロード。
※1回のPUTオペレーションで、最大 5 GB の単一のオブジェクトをアップロード可能

マルチパートアップロード API を使用すると、最大 5 TB のサイズの単一の大容量オブジェクトをアップロード可能。

・Amazon S3 コンソールを使用して 1 つのオブジェクトをアップロード。
※Amazon S3 コンソールでは、最大 160 GB のオブジェクトをアップロード可能

・オブジェクト格納成功時、【HTTPステータスコード２００】を返す。

バケット内のオブジェクト固有の識別子。バケット内のすべてのオブジェクトは、厳密に 1 個のキーを持つ。

※バケットポリシーでは、プリンシパルとして対象のアカウントIDが使用するIAMロールを指定してアクセス許可を付与することができる。

●ACL

バケットとオブジェクトへのアクセスを管理できる。各バケットとオブジェクトには、サブリソースとして ACL がアタッチされている。これにより、アクセスが許可される AWS アカウントまたはグループとアクセスの種類を定義。リソースに対するリクエストを受信時、S3 は該当する ACL を調べて必要なアクセス許可がリクエスタにあることを確認する。

[（バケットの）アクセス許可を付与する]

AWSユーザーの正規ID を設定することで対応可能。

[種類]

• Bucket ACL
  手軽に基本的なアクセス権（バケット及び個々のオブジェクトへのアクセス権の設定）許可のみであり拒否はなし。
• Object ACL
  オブジェクト単位で制御したいときに向いている。
  [指定バケット > アクセス権限 > アクセスコントロールリスト],[指定オブジェクト > アクセス権限]

●バケットポリシー

【S3への高度なアクセス制御を実施する】
S3オブジェクトへのアクセス許可。バケット単位でIAMユーザやグループのアクセス権、他のAWS アカウントを指定することが可能。BucketPolicyの方が強いが、設定されていない場合は、ACLによって制御される。

・サーバー側の暗号化を必要としないオブジェクトのアップロードを拒否できる
・バケットにアクセス権を付けただけではアクセスできないため、オブジェクトへのアクセス許可も必要。

[エレメント]

• プリンシパル(Principal)
  Principalエレメントは、リソースへのアクセスを許可または拒否するユーザー、アカウント、サービス、または他のエンティティを指定。
  [参考公式サイト]

●ユーザー（IAM）ポリシー

別のAWSアカウントに自分が所有するS3バケットへのアクセス利用を許可したい時、バケットポリシー及びユーザーポリシーの 両方の許可設定が必要（特定のIAMユーザー、IAMロールだけ操作できるようにしたいとき）。レプリケーションを実施するためには、両方のS3バケットにおいてバージョン管理を有効化。

●被付与者

AWS アカウント または事前定義済みのいずれかの Amazon S3 グループ。
E メールアドレスまたは正規ユーザー ID を使用。AWS アカウント にアクセス許可を付与。ただし、付与のリクエストでメールアドレスを指定すると、Amazon S3 はそのアカウントの正規ユーザー ID を確認して ACL に追加する。その結果、ACL には AWS アカウント の E メールアドレスではなく、常に AWS アカウント の正規ユーザー ID が含まれる。

※IA はinfrequent access (低頻度アクセス) の略

★トピック「暗号化」にて記載

★Content-MD5 ヘッダーの役割と使用方法 / オブジェクトの整合性検証

[Content-MD5 ヘッダーの目的]

• Content-MD5 は、アップロード時のデータ整合性を検証するためのチェックサム。
• オペレーション（PUT、POST、COPYなど）で送信されたデータが、Amazon S3 に正しく保存されたかを確認する。
• エラーが発生した場合、Amazon S3 はリクエストを拒否し、整合性が保証されない。

[オブジェクトの整合性検証方法]

• オブジェクトの ETag（通常は MD5 ダイジェスト）を使って、アップロード後に整合性を確認できる。
• マルチパートアップロードでは、ETag は複数パートの組み合わせで生成されるため、ETag ≠ Content-MD5 になる。
• オブジェクトをダウンロード後、ローカルで MD5 を計算し、ETag と比較することで整合性を確認可能。

[注意点]

• Content-MD5 を使用する場合、Base64 エンコードされた MD5 ダイジェストをヘッダーに含める必要がある。
• ETag が MD5 であるとは限らず、暗号化やマルチパートアップロードでは異なる形式になる。