基礎知識

●ETL

（Extract（抽出）Transform（変換）Load（格納））
社内に点在する情報(データ)を必要な情報(データ)のみ1箇所に集約し蓄積し、経営に役立つ洞察を得るために利用する。

※これまでは情報を蓄積させるにも異なるデータソースであったため、各開発工数と専門知識が求められた

[RPAとの違い]
RPAツール：既存のアプリケーションの利用を前提とする。
ETLツール：ツールを利用してデータの収集や加工を行う。

サブセット	一部分、部分集合、下位集合などの意味を持つ英単語。ある集団全体を構成する要素の一部を取り出して構成した小集団のこと。ITの分野では、仕様や規格、データ集合、ソフトウェアの機能などについてよく用いられる用語。本来備えている要素の一部を省略・削除した簡易版、限定版、軽量版という意味で用いられることが多い。
ヒューリスティック	必ず正しい答えを導けるわけではないが、ある程度のレベルで正解に近い解答を得ることができる方法。答えの精度が保証されない代わりに、回答に至るまでの時間が少ない。
データパーティショニング	スキャンされるデータ量が最小限に抑えられ、パフォーマンスが最適かされ、S3での分析クエリのコストが削減される。データへのきめ細かいアクセスも向上。

●Fluent Bit

・Kubernetes対応：DaemonSetとして簡単にデプロイ可能。PodやNodeのログ収集に最適
・用途：ログの収集、処理、転送（ログルーターとして機能）
・軽量設計：C言語で実装されており、メモリ使用量が非常に少ない（数MB程度）
・対応フォーマット：JSON、CSV、Apache/Nginxログなど、さまざまな形式に対応
・出力先：Amazon S3、CloudWatch Logs、Elasticsearch、Kafka、Splunk、Datadog など多数

機能	説明
Input Plugins	ログの取得元（ファイル、systemd、TCP、Kubernetesなど）を指定可能
Filter Plugins	ログの加工（タグ付け、除外、JSON変換、Grepなど）
Output Plugins	転送先の指定（S3、CloudWatch、Elasticsearchなど）
パフォーマンス	高速処理と低リソース消費で、IoTやエッジ環境にも適している

Quick Sight

※CloudWatchLogsを直接データソースとして利用できない

[参考]

Open Search Service

Apache Lucene 検索ライブラリを搭載しており、KNN 検索、SQL、異常検出、機械学習コモンズ、トレース分析、フルテキスト検索など、多くの検索および分析機能をサポートしている。ドキュメントやメッセージ、ログ等の様々なデータソースに対してDashboards Query Language（DQL）を使用することでデータの分析や可視化ができるサービス。

※Cloud Frontのログの格納先にOpenSearchドメインを使用することはできない
※本サービスを停止することはできない

[Open Searchについて詳細]

[Kibanaへのアクセス制御]

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

[認証と保護の方法]

Amazon Cognito認証（Elasticsearch 5.1以降）	Kibanaにユーザー名とパスワードによるアクセス制限を設定可能。オプション機能。
IPベースのアクセスポリシー + プロキシの利用	Cognito認証を使用しない場合でも、IP制御とプロキシを使ってアクセス制御が可能。

[JavaScriptとアクセス制御の考慮点]

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

Compute Optimizer

[グラフ機能]

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

Kinesis

●ストリーミングデータ

数千ものデータソースによって継続的に生成されるデータ。

[ユースケース]
動画分析、一括からリアルタイムへの移行、動画分析アプリ、リアルタイムアプリなど

Kinesis Data Streams

仕組み

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

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

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

シャード	Kinesis Datastream内のデータレコードのシーケンス。シャードの増減によってデータの転送速度を変動できる。各シャードには、一連のデータレコードが含まれる。　[参考] 【1つのシャードあたり…】 ・取り込み：1秒あたり最大 2MB のデータ ・書込み：1秒あたり 1,000 レコード ・ストリーム：1秒あたり最大10ギガバイト [引用元公式サイト]
データレコード	Kinesis data stream に保存されたデータの単位。シーケンス番号、パーティションキー、データ BLOB (イミュータブルなバイトシーケンス) で構成される。各データレコードには、シャード内のパーティションキーごとに一意のシーケンス番号が割り当てられる。 ※BLOB 内のデータが検査、解釈、変更されることは一切ない

構成

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

データレコードを 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点についてはアプリケーション側で設計時に複数回送信されることを想定される。

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

連携サービス

Lambda	Lambda 関数を使用すると、Kinesis DataStreams のレコードを高速処理できる。Kinesis データストリームは、シャードのセット。Lambda 関数を共有スループットコンシューマー (標準イテレーター) にマップすることも、拡張ファンアウトを使用する専用スループットコンシューマーにマップすることもできる。
Application Auto Scaling	Application Auto Scalingを利用することでKinesis Data Stream に対してシャードを自動的に追加・削除する。スケーリングポリシーを定義を利用することでKinesis Data Stream に対してシャードを自動的に追加・削除するスケーリングポリシーを定義する。

Kinesis Data Firehose

※データのリアルタイム分析を直接実行する機能はない

・Lambda関数と統合されており、Lambda関数によるELT処理を連携することでデータ変換しつつ配信処理を実行できる。

●サブスクライバー

Marketplaceで提供されているソフトウェアやサービスを契約して利用しているユーザー。

機能概要

動的パーティショニング	データ内のキーを使用して、Kinesis Data Firehose でストリーミングデータを継続的にパーティショニングし、これらのキーでグループ化されたデータを対応する S3 プレフィックスに配信できる。これにより、Athena , EMR ,Redshift Spectrum などのさまざまなサービスを使用して、S3のストリーミングデータに対して高機能でコスト効率の高い分析を簡単に実行できる。
ゼロバッファリング	ほぼリアルタイムでデータを配信できるオプション。従来の Firehose は、データを一定時間（最小60秒）バッファリングしてから S3 や Redshift などに配信していたが、バッファ時間を0秒（0〜900秒 の範囲）に設定可能となり、数秒以内にデータを配信できる。 （リアルタイム性が求められるユースケースに最適） ・追加処理（変換など）がない場合、5秒以内に配信できる ・Lambda変換にもゼロバッファリング対応

Kinesis Video Streams

Kinesis Data Analytics

【分析】収集したデータを可視化・分析。
リアルタイムのストリーミングデータの分析や処理、保存を行う。

Managed Grafana

★Grafana（グラファナ）とは 分析およびインタラクティブな視覚化を可能にする、マルチプラットフォームで動作するオープンソースのWebアプリケーション

ワークスペースと呼ばれる論理的に分離された Grafana サーバーを作成する。
シングルサインオン、データアクセスコントロール、監査レポートなど、コーポレートガバナンス要件に準拠するためのセキュリティ機能が組み込まれている。

MSK

★Apache Kafka オープンソースの分散ストリーム処理プラットフォームで、リアルタイムのストリームデータを扱うためのツール

・可用性が高く、クラスターは最新の状態に保たれる。
・拡張性が高く、必要に応じて規模を換えることができる。
・Apache Kafka クラスターを複数のアベイラビリティーゾーン (AZ) に分散して提供する。
・既存アプリケーションで処理しているメッセージング機能をクラウドにすばやく簡単に移したい場合に最適。

Broker（ブローカー）	Kafkaクラスタを構成するサーバーのこと。
Topic（トピック）	メッセージを格納するための論理的な単位。データはTopicに分類される。
Producer（プロデューサ）	Kafkaにメッセージを送信するアプリケーション。
Consumer（コンシューマ）	Kafkaからメッセージを取得するアプリケーション。

[引用元]

[処理手順]

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

MSF

・複雑なストリーム処理に適している。

●RANDOM CUT FOREST

データストリーム内の異常を検出する。

分析サポートサービス

Glue

[組み込み変換]

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

Data Catalog	メタデータを格納するデータストア(=メタデータストア)。データベースやテーブルといった構造で保管する。S3 などのデータソースに保存されている構造化データ、または半構造化データの集まりをメタデータとして管理する。データカタログには、データベース、テーブル、スキーマといった構成を持ち、コネクション、クローラー、分類子といったメタデータを抽出するための機能がある。
Crawler	データソースへの接続、データスキーマの推測、データカタログでメタデータテーブル定義の作成を行うプログラム
ETL Job	ソースからデータの抽出、Apache Spark スクリプトを使用して変換、ターゲットにロードするビジネスロジック

[公式参考サイト]

Dynamic Frame

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

[主な機能と特徴]

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

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

Glue Find Matches

機械学習を使って類似レコードを検出する機能。特に、完全一致しないデータ（名前のスペル違いや住所の表記揺れなど）でも、同一人物や同一商品などを見つけたいときに活躍する。

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

Lake Formation

• アクセス制御を強化：IAM とは別の独自の権限モデルで、列・行・セルレベルまで細かく制御
• セキュリティとガバナンスの向上：企業全体でのデータ共有と制限を両立
• Lake Formation タグ を使ってデータを分類・ラベル付けし、リソースアクセスをキャンペーン単位などで制限可能。
• AWS Glue Data Catalog や Amazon Athena と連携し、統合的なメタデータ管理やアクセス制御を実現。

[主な機能と構成要素]

コンポーネント	説明
データカタログ	Glue と共有するメタデータ管理機構。S3 上のデータをテーブルとして定義
アクセス制御	LFタグ方式（タグベース）とリソース方式（個別付与）の2種類
ブループリント	データ取り込みのテンプレート。Glue のクローラーやジョブを自動生成
ワークフロー	データ取り込みや変換処理の流れを定義。Glue のトリガーと連携
プリンシパル	IAMユーザーやロールに対応。Lake Formation 独自の管理者権限も存在

LF-TBAC

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

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

[メリット]

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

ADOT

項目	内容
目的	アプリケーションのメトリクス、ログ、トレースを収集・送信するための統合ソリューション
ベース技術	CNCF（Cloud Native Computing Foundation）プロジェクトの OpenTelemetry
特徴	AWSサービスとの統合が強力（X-Ray、CloudWatch、ECS、Lambda など）
コンポーネント	OpenTelemetry Collector（AWS対応版）、SDK（Java, Python, Go など）

[メリット]
・AWSリソースのメタデータ取得：アプリケーションとインフラの関連付けが可能で、トラブルシューティングが高速化
・一度の計装で複数サービスに送信：X-RayやCloudWatchなど、複数の監視ツールに同時にデータを送れる
・サイドカーやエージェントとして柔軟にデプロイ可能：ECS FargateやEC2、Lambdaなどに対応

キューイングサービス

ストリーム処理をかけるデータはキューイングサービスを通すことが一般的である。

SQS

プロデューサ	キューにメッセージを入れる、取り出すサービス。
エンドポイント	URLを介して送受信する。

キュー

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

スタンダードキュー	順番は保証されない。一回のメッセージ配信をサポートする。 ・シーケンス情報 追加することで、順序良く受信させることができる。(スタンダードキュー可能）
先入れ先出し（FIFOキュー）	利用料金は高め。受信時にメッセージの並び替え、最低1回のメッセージ配信をサポートする。 ・S3との連携はできない ・1秒あたり最大3,000トランザクション ・1秒あたり最大300メッセージをサポートする [キューの切り替え] FIFOキューに切り替えるなどする際は、新しくキューを作成する必要がある。 ※FIFOキューは「コンテンツベース重複排除」を有効化することで、データを一意にできる

その他機能

キューイング (待ち行列)	【一時退避】一時的に送信するデータをデータ領域に保持し、滞留させず確実に相手へ届ける。疎結合が可能。
デッドレターキュー (DLQ)	【失敗処理】処理できないメッセージを別のキューに移動させる。正常に処理 (消費) できないメッセージのターゲットとする。アプリケーションやメッセージングシステムのデバッグに役立つ。
遅延キュー	【受信遅延】キューへの新しいメッセージの配信を数秒間遅延させ、そのキューに送信したすべてのメッセージは遅延期間中にコンシューマーに表示されない。キューのデフォルト (最小) 遅延は 0 秒。最大値は15分。

メッセージ

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

●メッセージグループ ID

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

●可視性タイムアウト

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

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

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

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

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

ポーリング

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

ショートポーリング	メッセージ取得時に特定のキューをランダムに選択し、そのキューからメッセージを取得する。リクエストを投げると結果は直ぐに返ってくるため、メッセージ取得時の待機時間0秒。しかし、結果が0件だった場合はリトライされるため、リクエスト回数が増え、料金が増加する。
ロングポーリング （推奨）	すべてのキューを確認し、処理可能な(待機時間を超過した)メッセージが存在する場合と接続タイムアウトになった場合のみ結果を返す。結果が0件の場合は返答しないため、SQS使用時のコストを削減できるので、ショートポーリングよりも推奨される。 ※ReceiveMessageAPI アクションが 0 より大きい場合ロングポーリングは実行中 ・KMSを使用したサーバー側の暗号化を使用したシームレスな保存データの暗号化をサポート。一元化されたキー管理が可能になる。

メトリクス

[参考公式サイト]

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

メトリクス名	説明
ApproximateNumberOfMessagesVisible	キュー内で現在可視状態にある（取得可能な）未処理メッセージの数。消費対象としてすぐに取得可能。
ApproximateNumberOfMessagesDelayed	遅延状態にあるメッセージの数。DelaySecondsが設定されており、まだ可視でないもの。
ApproximateNumberOfMessages(属性)	CloudWatchメトリクスではなく、SQSキュー属性。Visible、Delayed、NotVisibleをまとめた情報をAPIで取得可能。

MQ

・ソフトウェアをインストールして管理したりする必要はない。
・ソフトウェアのアップグレードやセキュリティの更新、障害の検出と回復などのタスクを自動的に管理する。

●メッセージブローカー

【中間システム】
異なるシステム間でメッセージやり取りの時、直接データのやり取りせず、中間システムとしてメッセージ格納領域を管理する機能。

その他関連サービス機能

IAM Access Analyzer

・ユーザーアクセスと最後にアクセスした情報に関する詳細なレポートを作成できる。

●S3 Access Analyzer

IAM Access Analyzeに基づいて現在のS3へのアクセスポリシーを監視できるサービス。
※IAM Access AnalyzeのS3用みたいなもの
バケットアクセスポリシーがS3リソースへの意図したアクセスのみを提供するように意図しないアクセスの可能性があるバケットを検出して迅速に修正できるようにする。また、S3バケットに対する外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認することができる。

S３に関する分析機能

S3 Select

[S3インベントリをフィルタリング]
S3インベントリ内のレポートをフィルタリングして、暗号化されていないオブジェクトなどを検索できる。

[データの解析には不向き]
シンプルなSQLステートメントを使用してS3オブジェクトのコンテンツをフィルタリングし、必要なデータのサブセットのみを取得できる。結果として、S3が転送するデータ量を削減でき、データ取得に要するコストを削減し、待ち時間を改善できる。

・アーカイブ容量の最大は250MB未満

※簡単なデータ検索や抽出に利用される機能であるため、本件の高度なビッグデータ分析には利用できない。

Athena

[課金について]
実行したクエリに対してのみ料金が発生する。

●CTAS (CREATE TABLE AS SELECT) コマンド

あるクエリの実行結果から新しいテーブルを作成できる。作成されたデータファイルは、指定したS3の場所に保存されます。S3上のデータをクエリしやすい形式（例: Parquet形式やパーティション化された形式）に変換・最適化し、分析パフォーマンスを向上させるための強力な機能。

[パーティション化]

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

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

S3 分析

【ストレージクラス分析】

ストレージアクセスパターンを分析し、適切なデータをいつ適切なストレージクラスに移行すべきかを判断できる。
アクセス頻度の低い STANDARD ストレージをいつ STANDARD_IA (IA: 小頻度アクセス) ストレージクラスに移行すべきかを判断できるように、データアクセスパターンを確認する。

EMR

・GoogleのフレームワークであるMapReduceをベースに実装されている。
・S3にある大量のログファイルを処理して、分析するのに最適なサービス。
・EMRの処理結果をS3をはじめとしたAWSの他のサービスと連携できる。

伸縮自在	EMRのコンピューティングとストレージは分離されているため、スケーリングができる。
信頼性	クラウド向けの調整。パフォーマンスの低いインスタンスは自動的に置き換わる。
安全性	インスタンスへのアクセスは自動制御、またKMSを使用して暗号化を行うことが可能。
低コスト	最小課金時間が1分、そして1秒毎に課金される。

仕組み

●Apache Spark

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

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

●Hadoop

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

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

●Kerberos ベースの認証

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

ノード

プライマリノード （Primary Node）	・クラスター全体の管理を担当 ・データ損失が起きるとクラスター全体に影響 ・オンデマンドインスタンスで実行し、高い可用性を確保するのが推奨
コアノード （Core Node）	・データストレージと分散処理に不可欠な役割を持つ ・データ損失が発生すると復旧困難 ・オンデマンドインスタンスを選択して安定性を担保するのが推奨
タスクノード （Task Node）	・主に計算負荷の分散処理を担当 ・データストレージには関与しない ・コスト効率を優先して スポットインスタンスを利用可能 ・中断される可能性があるが、タスクノードはその影響を最小限に抑えられる設計

●マスターノード

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

●コアノード

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

●タスクノード

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

S3 Storage Lens

[（デフォルト）ダッシュボード]
複数のAWSリージョンにわたるS3バケットの監視と、暗号化されたオブジェクトの割合の追跡に適した統合ダッシュボード。
S3コンソールを使用して直接ダッシュボードにアクセスできるため、追加のデータ集約やダッシュボードの作成が不要になる。

[クエリと集計関数の活用]
・stats コマンドを使ってログデータを集計
・特定フィールドの値でグループ化し、件数をカウント
・クエリ結果を棒グラフ・折れ線グラフなどで視覚化可能

[視覚化とパターン分析]
・ログデータの傾向や異常をグラフで把握
・stats と集計関数を組み合わせて、効率的な分析が可能

[クエリ構文の柔軟性]
・正規表現、算術演算、関数などをサポート
・複雑な条件でロググループに対して検索・抽出が可能

Cloud Watch関係

CloudWatch log insight

【Cloud Watchlogの検索】
CloudWatch Logsのログデータに対し、独自の構文を使ってクエリのようにデータを検索したり分析したりすることができる機能。ロググループ内のログデータの分析に特化しており、集計したデータをダッシュボードに表示することができる。

リアルタイムの監視やアラート設定はできない。

●ロググループ

複数のログストリームをまとめた単位。1つのロググループには複数のストリームが含まれ、アプリケーションやサービス単位でのログ管理を可能にする。

[クエリ構文]
専用のクエリ言語を用いてロググループを分析できる。

• 汎用関数：ログ項目の抽出や結合、フィルタリング
• 算術・比較演算：数値演算や大小比較による絞り込み
• 正規表現サポート：文字列パターンのマッチング
• 集計関数：集計、統計情報の生成
• ソート・制限：結果の並び替えや上位N件の取得

CloudWatch Application Insights

【アプリケーションの監視】
他のアプリケーションリソースとともに インスタンスを使用するアプリケーションをモニターリングする。

[アクション実行]
メトリクスとログを継続的にモニターリングし、異常やエラーを検出して相互に関連付ける。エラーや異常が検出されると、Application Insights は CloudWatch Events を生成する。これを使用して、通知を設定したり、アクションを実行したりできる。

[ダッシュボード]
トラブルシューティングに役立てるために、検出した問題の自動ダッシュボードを作成します。このダッシュボードには、相互に関連付けられた異常とログエラー、さらに根本原因を示唆する追加のインサイトが示されます。

CloudWatch Contributor Insights

【高頻度ボトルネック可視化】
CloudWatch Logsから取得した時系列データから上位（高頻度）の要素をリアルタイム分析を簡素できる機能。ログデータから特定の項目の頻度をランキング形式で表示し、トラフィックの傾向や主要な原因を特定するためのサービス。

パフォーマンスのボトルネックや、使用されているリソースなどを一目で確認できるダッシュボードで確認することができる。
CloudWatch Logsにエクスポートしたシステムやアプリケーションログなどからエラーが多いURLを特定したり、VPC Flow Logsで意図しないIPアドレスからのアクセスを特定したりすることができる。

CloudWatch Container Insights

ECS・EKS・EC2 上の Kubernetes クラスタで動作するコンテナ化アプリケーションやマイクロサービスのリソース使用率と稼働状況を収集・可視化する機能。

[主要ポイント]

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

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

CloudWatch メトリクスストリーム

• 目的：リアルタイムで CloudWatch メトリクスを外部サービスにストリーミングする機能。
• 用途：監視や可観測性の向上、サードパーティーサービスとの統合に活用。
• 対応先：Amazon S3、Amazon Kinesis Data Firehose、サードパーティープロバイダーなど。

[構成要素]

要素	説明
データレイク	メトリクスを Amazon S3 に保存して分析可能。Kinesis Data Firehose 経由で S3 に送信。
サードパーティープロバイダー	Datadog や New Relic などの外部サービスに直接ストリーミング可能。

Data Exchange

[サブスクリプションの検証]
データを共有する前に送り先の身元を確認でき、信頼性の確保を実現する。