Amazon SAA-C03: アナリティクス、データレイク、ML、特殊なワークロード — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

データレイク基盤: Lake FormationとGlueデータカタログ

AWS分析の中心となるのはAWS Glueデータカタログです。これはHiveメタストア互換のメタストアであり、Athena、Redshift Spectrum、EMR、そしてGlue ETLのすべてがこれを利用します。すべてのテーブル定義、パーティション、列の型、SerDe設定はここに保存され、すべての下流エンジンがそこから読み取ります。もし2つの取り込みパス（例えば、Glueクローラーと手動のCREATE EXTERNAL TABLEステートメント）が同じS3プレフィックスのスキーマについて見解が異なると、クエリはサイレントに誤った結果を返すか、失敗します。正しいパターンは、テーブルごとに単一の権威を指定することです。つまり、クローラーがスキーマを所有するか、ETLジョブがglueContext.write_dynamic_frame.from_catalog経由で書き込むかのどちらかであり、マージ戦略なしに両方を行うことは決してありません。バッチETL、FirehoseのParquet変換、そして手動のDDLがすべて同じテーブルに書き込む場合、カタログのドリフトは、気づかぬうちに問題を引き起こす大きな要因となります。テーブルごとに1つのオーナーを強制し、ストリーミングプロデューサーにはGlue Schema Registryを使用し、ETLジョブが所有するテーブルに対してはクローラーをUPDATE_IN_DATABASEではなくLOGモードで実行して、キュレートされたスキーマを上書きすることなくドリフトを表面化させるようにしてください。

AWS Lake FormationはData Catalogの上位に位置し、粗粒度のIAM/S3バケットポリシーモデルを、データベーススタイルの権限レイヤーに置き換えます。プレフィックスに対してs3:GetObjectを許可する代わりに、GRANT SELECT ON customers.orders TO role/AnalystRoleのように許可します。すると、AthenaやRedshift Spectrumが基盤となるオブジェクトにアクセスする際に、Lake Formationが透過的に短期的な認証情報を発行します。その真価は、きめ細かな認可にあります。列レベルのフィルタリング、データフィルターによる行レベルのセキュリティ、そして数千のテーブルにまたがってスケールするタグベースのアクセスコントロール（LF-Tags）です。個人情報（PII）をcustomersテーブルに持つ小売プラットフォームは、アナリストにcustomer_id, region, signup_dateへのアクセスを許可しつつ、emailとssnをブロックすることができます。これはクエリ時に強制され、ビューを乱立させる必要がありません。

ガバナンスの効いたレイクの標準的なセットアップ：

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Lake Formationのブループリントは、クローラー、ジョブ、トリガーを組み合わせてJDBCソースやS3からキュレートされたレイクにデータを取り込むための、事前構築されたワークフローテンプレートです。これにより、手作業で接続する必要があった数十のGlueリソースが、ウィザード形式のフローに削減されます。

よくある間違いは、QuickSightだけで列レベルの制限を強制しようとすることです。QuickSightにはデータセットに紐付いた行レベルおよび列レベルのセキュリティがありますが、それはQuickSight上での表示のみを保護するにすぎません。AthenaやS3に直接アクセスできるユーザーは、それをバイパスしてしまいます。列レベルの制御はデータレイヤー（Lake Formationの許可、またはETL中に物理的に列を分離する）で強制する必要があり、QuickSightはそのIAMロールを通じてそのセキュリティ設定を継承します。

Athena: S3に対するサーバーレスSQL

Athenaは、Amazon S3から直接読み取るサーバーレスの従量課金制Presto/Trinoエンジンです。プロビジョニングするクラスターはなく、クエリ実行前にETLステップは不要で、アイドル時にはコストがかかりません。スキャンされたバイト数に対してのみ支払いが発生します（通常$5/TB）。このため、AthenaはS3に既にあるファイル（JSONアプリケーションログ、CSVエクスポート、Parquetファクトテーブルなど）のアドホック分析における標準的な選択肢となります。Athenaはスキーマとパーティションレイアウトを必要とし、それらはGlueデータカタログに保存されます。

Athenaはスキャンしたテラバイト数ごとに課金されるため、ストレージフォーマットはコストとレイテンシーに非常に大きな影響を与えます。そのための2つの主要な手段は、フォーマットとパーティショニングです。

• カラムナフォーマット（Parquet, ORC）により、Athenaは列や行グループをプルーニング（読み飛ばし）できます。Parquetに対するSELECT sum(amount) FROM orders WHERE region='us-east-1'のようなクエリは、参照される2つの列のみを読み取ります。CSVの場合、すべての行のすべてのバイトを読み取ります。
• 選択性の高い列（例：dt=2024-03-11/）でパーティショニングを行うと、フルテーブルスキャンがターゲットを絞った読み取りに変わります。数テラバイトに及ぶログ（CloudFront, ALB, VPC Flow Logs）では、これは$0.15のクエリと$30のクエリほどの違いになります。

生のJSONやCSVを、パーティション化されSnappy圧縮されたParquetに変換することは、ほぼ常に最初に取り組むべきコスト削減策です。LIMITプッシュダウンと組み合わせることで、AthenaはインフラゼロでS3上のほとんどの分析ニーズに対応できます。

パーティション化されたParquetとして保存された「readings」テーブルのコスト効率の良いパターン：

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

クローラーをスキップするのはよくある間違いです。カタログエントリがないと、手動でCREATE EXTERNAL TABLE DDLを書く（スキーマの進化に伴い脆弱になります）か、すべてのファイルをスキャンするスキーマオンリードのハック的な手法を使うことになります。さらに悪いことに、MSCK REPAIR TABLEやパーティションプロジェクションがないと、Athenaはクエリごとにプレフィックス全体をスキャンしてしまいます。Glueクローラーはスケジュールに基づいて新しいパーティションを検出し、カタログをアトミックに更新します。

暗号化されたS3データに対するAthena。 AthenaはSSE-S3、SSE-KMS、CSE-KMSをサポートしますが、それは呼び出し元が適切なKMS権限を持ち、ワークグループまたはクライアントが使用中の暗号化モードに合わせて設定されている場合に限られます。CSE-KMSの場合、ファイルはアップロード前にクライアントサイドで暗号化されます。クエリを実行するIAMプリンシパルは、CMKに対するkms:Decryptとkms:GenerateDataKey権限を必要とし、キーポリシーもそれを許可する必要があります。よくある失敗モードは、CSE-KMSで暗号化されたParquetをロードし、AthenaのロールにS3の読み取り権限しか与えず、その後、内容の不明なAccessDeniedやHIVE_CANNOT_OPEN_SPLITエラーが発生するケースです。この場合、オブジェクトは読み取り可能ですが、暗号文を復号できません。もう一つのよくある間違いは、テーブルを誤った暗号化モードで登録することです（オブジェクトがCSE-KMSで書き込まれたのに、テーブルプロパティでSSE-KMSを指定するなど）。この場合、AthenaはGetObject中にサーバーサイドでの復号を試み、ペイロードは生の暗号文として返され、Parquetのマジックナンバーチェックに失敗します。

Athenaのフェデレーテッドクエリを使用すると、データを移動させることなく、S3データと運用ストア（DynamoDB, RDS）を結合できます。Athenaは読み取り指向のアドホック分析用に確保し、キュレートされたゾーンの定期的な整形にはGlueジョブを使用します。

Glue クローラ、ETL ジョブ、ジョブブックマーク

Glue クローラは S3 パスをスキャンし、スキーマ（year=2024/month=01/ のようなディレクトリ構造からのパーティションキーを含む）を推論し、カタログ内のテーブルを登録または更新します。「S3にファイルを置くだけでクエリ可能にしたい」という要求に対するローコードな解決策です。ランディングバケットに対してクローラを1時間ごとにスケジュールすれば、Athena は新しいパーティションを即座に認識します。

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Glue ETL ジョブ（Spark、Python shell、または Ray）は、変換処理を担います。Glue はサーバーレスであり、1分間の最低料金で DPU 時間単位で課金され、ランタイムはワーカーを自動的にスケールします。主なパターンは、CSV/JSON を入力とし、パーティション化された Parquet を出力するものです。

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

運用上、極めて重要な機能がジョブブックマークです。Glue は、どのファイルやパーティションをすでに処理したかという状態を永続化するため、後続の実行では新しいデータのみを読み取ります。ブックマークを有効にし忘れると、実行のたびにデータセット全体が再処理され、コストと実行時間が線形に増加し、しばしば重複した出力が生成されます。ブックマークはジョブごとに有効化され、それをサポートするソースオプションと組み合わせる必要があります（Glue DynamicFrame リーダー経由の S3 ソースはサポートしますが、任意の Spark 読み取りはサポートしません）。ブックマークには、すべてのソースに transformation_ctx 引数が必要であり、また job.init(...) と job.commit() で処理を囲む必要があります。

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

ロジックのない純粋なフォーマット変換の場合、最も手間のかからない選択肢は、多くの場合、生のデータに対する Glue クローラと、ビジュアルエディタで作成した Glue ジョブ（または DataBrew レシピ）の組み合わせです。Spark コードは不要です。カスタムの EMR クラスタや Lambda コンバータは、Glue のサーバーレスモデルが排除する運用オーバーヘッドを追加します。

S3 データをキュレーションし、Redshift Serverless にロードする典型的な日次ジョブ：

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Glue セキュリティ設定とマルチテナント ETL

Glue クローラとジョブには、Athena と同様の暗号化に関する認識が必要です。Glue のセキュリティ設定は名前付きのバンドルであり、S3 ターゲット、CloudWatch ログ、ジョブブックマークがどのように暗号化されるか（特定の CMK を使用した CSE-KMS を含む）を指定します。セキュリティ設定にアタッチされたジョブは、ジョブの IAM ロールが参照されるキーに対する KMS 権限を持っている限り、CSE-KMS 入力を透過的に復号し、同じ方法で出力を暗号化します。

マルチテナント ETL、つまり SaaS プラットフォームが各顧客のデータをその顧客自身の CMK で処理するような場合、正しいパターンは、顧客ごとに1つのセキュリティ設定を用意する（またはジョブパラメータで CMK を選択する）ことに加え、その CMK にスコープを限定した IAM ロールを使用することです。すべての顧客を単一の共有キーを持つ単一のジョブで処理することは、CSE-KMS が提供するはずの分離保証を無意味にします。

関連する規律として、本番の分析テーブルを、探索的な Glue ジョブやノートブックの直接のターゲットにすべきではありません。スナップショットを S3 の「analytics」プレフィックスにエクスポートし、Athena や Spark はそのコピーを指すようにします。本番テーブルで実験的な変換を実行すると、パーティションレベルの書き換え、ブックマークの破損、ロック競合のリスクがあり、また、運用データと分析派生データの間の監査境界が曖昧になります。

AWS Glue DataBrew

DataBrew は、Spark を書けない、あるいは書くべきではないユーザー向けの、Glue のローコード版です。250 以上の組み込み変換（欠損値補完、PII マスキング、外れ値のビニング、日付解析など）を備えたスプレッドシート形式の UI を提供します。その差別化要因は、共有レシピ（バージョン管理された JSON アーティファクトであり、公開してプロジェクト間で再適用可能）と、データリネージの可視化（ソースデータセットからレシピやジョブを経て出力先まで、カラムを追跡）です。変換ロジックをアナリストが担当する場合は DataBrew を、エンジニアが担当し、パイプラインにカスタムコード、ストリーミング、または複雑な結合が必要な場合は Glue Studio/スクリプトを選択します。

Amazon EMR: 分散バッチとランタイムロール

Amazon EMR は、Spark、Hadoop、Hive、Presto、HBase、Flink を実行するマネージドクラスタプラットフォームです。その得意分野は、ペタバイト規模の S3 データセットを読み取り、それを別の記録システム（多くは Redshift）と結合してエンリッチメントを行う、大規模で並列化可能なバッチまたはインタラクティブなワークロードです。EMR は、一時的なクラスタ（起動、実行、終了）または長時間実行されるクラスタを実行でき、インスタンスフリートを介してオンデマンド、スポット、リザーブドインスタンスを混在させることができます。

典型的なパターン：Spark ジョブが S3 から Parquet を読み取り、UNLOAD-to-S3 を介して Redshift からディメンションテーブルを取得し、エグゼキュータ間でそれらを結合し、エンリッチされた出力を S3 に書き戻します。

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

ここで EMR が優れているのは、Spark が数十のノードにまたがって結合を分散させ、S3 経由でステージングすることでシングルスレッドの JDBC ボトルネックを回避できるためです。S3 データのクエリが必要になるたびに反射的に EMR を選択してしまうのが罠です。数十から数百ギガバイトのデータに対するアドホックな SQL のために、Spark クラスタをプロビジョニングしてチューニングするのは、純粋な運用オーバーヘッド（クラスタのサイジング、YARN の設定、オートスケーリング、ログローテーション、パッチ適用）です。EMR がその価値を発揮するのは、ボリューム、カスタムコード、または実行エンジンの柔軟性によってその利用が正当化される場合に限られます。

EMR ランタイムロール。 歴史的に、クラスタ上のすべてのステップは EC2 インスタンスプロファイル（基盤となるノードにアタッチされた1つのロール）を継承していました。つまり、クラスタを共有するすべてのチームは、いずれかのチームが必要とするすべての権限の和集合を持っていました。ランタイムロールはこれを解決します。ユーザーがステップをサブミットする際に --execution-role-arn を渡し、EMR はそのステップの実行期間中、そのロールを引き受けます。チーム A は s3://team-a/* に、チーム B は s3://team-b/* に制限できます。インスタンスプロファイルは、クラスタのアーティファクトを取得するだけの薄いブートストラップロールになります。

ランタイムロールは、IMDS アクセスをブロックするメカニズムでもあります。有効化されている場合（YARN 上の Spark/Hive を使用する EMR 6.7+）、プラットフォームがこれらの呼び出しをインターセプトするため、ユーザーコードはインスタンスメタデータサービス（IMDSv2 を含む）に到達できません。これにより、ジョブが http://169.254.169.254/latest/api/token を呼び出して強力な EC2 インスタンスプロファイルを引き受けることができたであろう権限昇格の経路が閉ざされます。

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

セキュリティ設定が、ランタイムロールの強制と IMDS のブロックを可能にするものです。それがない場合、EMR ワークロードが「自動的に最小権限のロールを使用する」と想定するのは間違いです。デフォルトでは、インスタンスプロファイルを共有し、IMDS はユーザーコードから到達可能です。

Amazon RedshiftとRedshift ML

Redshiftは、サブ秒単位のダッシュボード表示、数十億行にわたる複雑な結合、同時実行BIユーザー下での一貫したレイテンシーを必要とする、持続的な分析ワークロード向けの列指向MPPデータウェアハウスです。RA3ノードは、コンピューティングをマネージドストレージから分離します。Redshift Serverlessは、設定されたベースキャパシティに対してRPU秒単位で課金され、負荷に応じてスケールし、アイドル時には一時停止するため、従来のクラスターサイジングの問題が解消されます。

Redshiftは、2つのエンリッチメントモードで分析パイプラインに参加します。

• ソースとして: Spark on EMRがUNLOAD-to-S3を介してディメンションをプルするか、GlueがRedshift Data APIを介して読み取ります。
• ターゲットとして: FirehoseまたはGlueジョブが、エンリッチされたデータをCOPYで取り込みます。

Redshift Spectrumはこれを拡張し、Redshift SQLがGlueデータカタログ（Athenaが使用するのと同じカタログ）を通じてS3を直接クエリできるようにします。これがレイクハウスパターンを機能させるものです。すでにRedshiftクラスターがあり、データを移動させることなく、ウェアハウス内のファクトとS3のコールドな履歴データを結合したい場合に理想的です。

バッチロードはS3からのCOPYを使用し、コンピュートノード間で並列化されます。並列処理のためには、ファイルは（スライスカウントの倍数となる）ほぼ均等なチャンクに分割する必要があります。

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

ストリーミングインジェストは通常、Firehose（バッファリングされたCOPY）を介して行われ、ゼロオペレーションでの配信を実現します。

Redshift MLにより、SQLユーザーはCREATE MODELを介してモデルを作成、トレーニング、呼び出しできます。

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

内部的には、RedshiftはトレーニングセットをS3にエクスポートし、SageMaker Autopilot（またはXGBoostなどの指定されたアルゴリズム）を呼び出し、コンパイルされたモデルをインポートしてデータベース内推論を行います。アナリストがすでにSQLを使いこなしている場合には強力ですが、完全なMLプラットフォームの代替にはなりません。S3へのデータ移動とSageMakerのトレーニングコンピューティングは別途課金されます。大規模なトレーニングセットは、多額のデータ転送料金とAutopilotの実行時間料金を発生させる可能性があります。また、特徴量ストア、実験追跡、A/Bデプロイメントのための組み込みワークフローはありません。Redshift MLは、汎用的なトレーニングではなく、Redshiftデータに対する推論を民主化するものとして捉えるべきです。

AthenaとRedshiftの選択

ストリーミングインジェスト: Kinesis Data Streams, Firehose, and MSK

3つのAWSストリーミングサービスは、重複する問題を解決しますが、保証内容が大きく異なります。

Kinesis Data Streamsはシャード（またはオンデマンドモード）を使用します。同じパーティションキーを持つレコードは同じシャードに入り、順序通りに消費されます。コンシューマーは、従来のGetRecordsまたは拡張ファンアウト（コンシューマーごとに専用の2 MB/s）を使用します。イベントソースとしてアタッチされたLambda関数は、シャードごとのバッチで呼び出され、順序が維持されます。ダウンストリームのロジックが自明でなく、複数の独立したコンシューマーが履歴をリプレイする必要がある場合、またはクリックストリームの量が膨大な場合に正しい選択です。例えば、1日あたり30TBを生成するサイトは、KDSを介してFirehoseに流れ込み、Athena/Spectrum分析のためにS3に格納されます。

Kinesis Data Firehoseは、投入するだけでよいマネージド配信サービスです。サイズまたは時間（例：5MB / 300秒）でバッファリングし、オプションで変換用のLambdaを呼び出し、オプションでGlueテーブルのスキーマを使用してJSONをParquet/ORCに変換し、S3、Redshift（S3 + COPY経由）、OpenSearch、またはSplunkに書き込みます。FirehoseでParquet変換を有効にすることは、ダウンストリームのGlueジョブなしで、ストリーミングデータをクエリに最適化された形式で配置するための低労力な方法です。

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehoseにはエンドツーエンドの順序保証がなく、複数のリプレイ可能なコンシューマーをサポートできず、その送信先は固定のシンクです。「各レコードを順序通りに処理する」または「複数の独立したコンシューマー」という要件がある場合にFirehoseを選択することは、どちらの点でも誤りです。同様に、Firehose単体で複雑な変換を実行できると期待するのは罠です。その唯一の変換フックは、バッファリングされたバッチごとに呼び出されるLambdaです。外部エンリッチメント、複数レコードの集約、または条件付きルーティングを含むものは、そのLambda内に実装するか、上流のManaged Service for Apache Flinkに移行する必要があります。

Amazon MSKは、マネージドなApache Kafkaです。すでにKafkaのプロデューサー/コンシューマーがいる場合、Kafka固有の機能（圧縮トピック、トランザクション、Kafka Streams、Connect）が必要な場合、またはシャードベースのKinesisが快適に提供できる以上のスループットが必要な場合に選択します。

SQSやEventBridgeを分析の取り込みパスとして使用するのは間違いです。SQSはストリームごとの順序性がなく、リプレイもできません。EventBridgeはイベントルーティングに最適化されており、持続的な数MB/sの取り込みには向いていません。

リアルタイム検索: KDS + Firehose + OpenSearch + QuickSight

オンプレミスのElasticsearch+Logstashスタックの標準的な代替構成は次のとおりです。

Firehoseはストリームレコードをバッファリングし、OpenSearchドメインに直接配信します。再試行、S3へのバックアップ、オプションのLambdaによる変換も処理します。OpenSearch Dashboardsはドメインに組み込まれており無料で利用でき、リアルタイムストリームを監視するオペレーターに適しています。QuickSightは、ビジネス向けの分析でこれを補完します。Athena、Redshift、RDS、OpenSearchに直接クエリを実行し、そのSPICEインメモリ列指向エンジンが処理済みデータセットをキャッシュすることで、1秒未満のダッシュボードパフォーマンスを実現します。

一般的な使い分けは、オペレーター向けにはOpenSearch Dashboards、集約・キュレートされたAthena/Glueデータレイクのデータセットを利用するエグゼクティブ向けにはQuickSight、となります。どちらのサービスにも、IAMの読み取りアクセス権と、該当する場合は基盤となるストレージを保護しているCMKに対するKMSのDecrypt権限を付与する必要があります。さもないと、可視化レイヤーは空のパネルを表示し、クエリログには権限エラーが埋もれてしまいます。

QuickSightのアクセス制御

QuickSightでは、まずデータセット（論理的なクエリに計算フィールドと行レベルセキュリティを加えたもの）を構築し、そのデータセットを基に分析を作成し、そしてダッシュボード（読み取り専用の共有可能なビュー）を公開します。アクセス制御は階層化されており、適切なレイヤーで適用する必要があります。よくある間違いは、ダッシュボードレベルで広範なアクセスを許可してしまうことです。つまり、基盤となるデータは一部のユーザーしか見るべきでないのに、組織全体のグループに共有してしまうケースです。

QuickSightにおける最小権限の原則は、次のことを意味します。

• データセットを、それを必要とするユーザー/グループにのみ共有する。
• ユーザー名やグループで行をフィルタリングする権限データセットを介して、行レベルセキュリティを適用する。
• 機密フィールドを非表示にするために、列レベルセキュリティを適用する。
• ダッシュボードを、特定のユーザー、グループ、または（埋め込み分析の場合は）名前空間と共有する。

ダッシュボードを公開したりアカウント全体で共有したりすると、データセットレベルの制御の意図が迂回されてしまいます。なぜなら、ダッシュボードの閲覧者は、基盤となるソースの権限に関係なく、可視化されたデータへの読み取りアクセスを継承するからです。QuickSightの列レベルセキュリティはQuickSightのUI上でのみ保護するものであり、AthenaやS3に直接アクセスできるユーザーはそれをバイパスできてしまうことを覚えておいてください。したがって、機密性の高い制御はQuickSight単体ではなく、Lake FormationやETLで行うべきです。

QuickSightのロール（管理者、作成者、閲覧者）は、ユーザーが何をできるかを制御するものであり、何を見れるかを制御する共有権限とは異なります。閲覧者（Reader）は作成者（Author）ライセンスよりもセッションあたりのコストが低いため、閲覧者ユーザーはデフォルトで閲覧者にすべきであり、アクセス権は個別の割り当てではなくグループメンバーシップを通じて付与すべきです。

Amazon Neptuneによるグラフワークロード

Neptuneは、プロパティグラフモデル（Gremlin, openCypher）とRDF（SPARQL）をサポートするマネージド型グラフデータベースです。社会的関係、不正利用のリング、ナレッジグラフ、レコメンデーションエンジンなど、リレーショナルデータベースでは再帰的な結合のコストが非常に高くなるような、高度に接続されたデータ向けに特化して構築されています。ユーザー、フォロー、いいね、投稿といった要素を持つソーシャルプラットフォームは、自然に頂点とエッジにマッピングでき、Neptuneは「Xに『いいね！』した友達の友達」のようなマルチホップトラバーサル（複数ホップの探索）にミリ秒単位で応答します。

Neptune Streamsは、グラフへのすべての変更（ミューテーション）を時系列で順序付けたログとして公開します。このストリームをポーリングするLambdaやアプリケーションは、専用の変更データキャプチャ（CDC）パイプラインを構築することなく、レコメンデーションの再計算、検索インデックスの更新、不正アラートのトリガーといった変更への対応が可能です。これをAuroraやDynamoDBで再現するには、アプリケーションレベルでのグラフ探索に加えて、別途CDCの仕組みを実装する必要があります。問題の要件に「関係性の分析」と「変更の監視」の両方が含まれる場合、NeptuneとNeptune Streamsの組み合わせが最も直接的な解決策となります。

SageMaker: エンドツーエンドのカスタムML

SageMakerは、Studioノートブック、マネージドトレーニングジョブ（スポットインスタンス対応）、Model Registry、リアルタイムおよびサーバーレスエンドポイント、バッチ変換、そしてMLOpsのためのPipelinesといった、完全なライフサイクルを提供します。典型的なフローでは、トレーニングデータをS3にアップロードし、組み込みアルゴリズムまたはカスタムコンテナを指定してトレーニングジョブを開始します。するとSageMakerがエフェメラルなインスタンスをプロビジョニングし、CloudWatchにログをストリーミングし、モデルアーティファクトをS3に書き戻します。デプロイは単一のAPIコールで実行できます。

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Kubernetes、GPUドライバー、モデルサーバーを管理する必要はありません。「モデルをトレーニングして公開する」という要件を持つチームにとって、ECS/EC2で推論環境を自前で構築するのと比較して、SageMakerはほとんどの場合、最もオーバーヘッドの少ない答えとなります。

SageMaker Savings Plansは、対象コンポーネント（Studio、トレーニング、処理、リアルタイム推論）全体で1時間あたりのドル建ての利用額を1年または3年間コミットすることで、オンデマンド料金から最大64%の割引を受けられるプランです。このプランはインスタンスファミリー、サイズ、リージョン、コンポーネントをまたいで柔軟に適用されますが、Ground Truth、ストレージ、データ転送は対象外です。ベースラインとなるMLの使用量が予測可能な場合にSavings Plansを利用し、バースト的なトレーニングはスポットインスタンスで行うことで、さらに節約効果を高めることができます。

マネージドAIサービス 対 カスタムML

Amazon Rekognition（画像/動画：オブジェクトとシーンの検出、顔分析、モデレーション）、Textract（OCRに加え、フォームとテーブルの抽出）、そしてComprehend（NLP：エンティティ認識、感情分析、PII検出、カスタム分類）は、シンプルなAPIの背後で事前トレーニング済みモデルを公開しています。ComprehendのDetectEntitiesは、COMMERCIAL_ITEMカテゴリを含む型付きエンティティを返します。これは、レシピのテキストから材料名を抽出し、DynamoDBのルックアップに渡すのに最適です。トレーニングデータもホスティングも不要で、リクエストごとの課金で利用できます。

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

よくある失敗パターンは、過剰設計（オーバーエンジニアリング）です。つまり、マネージドサービスが要件をわずかな運用コストで満たせるにもかかわらず、SageMakerのトレーニングジョブを立ち上げ、Ground Truthでデータにラベル付けし、エンドポイントをホスティングしてしまうことです。カスタムMLが正当化されるのは、ドメイン固有のデータに対する精度が大幅に高い場合、必要なエンティティタイプがマネージドサービスのスキーマと一致しない場合（それでもComprehendのカスタム分類/カスタムエンティティ認識は、素のSageMakerより安価です）、またはレイテンシーやデータレジデンシーの制約によりプライベートモデルが必要な場合に限られます。

HPCのストレージとネットワーキング：FSx for LustreとEFA

密結合HPCワークロード（CFD、分子動力学、地震波イメージング、大規模トレーニングなど）には、2つの譲れない要件があります。それは、極めて低いレイテンシーのノード間通信と、高スループットの共有ストレージです。

Elastic Fabric Adapter (EFA)は、特定のEC2ファミリー（hpc7a、hpc6id、c6in、p4d/p5など）で利用可能なネットワークインターフェイスです。OSバイパスのLibfabricを使用してカーネルのTCP/IPスタックをバイパスし、MPIやNCCLが数百ノードにわたってマイクロ秒レベルのレイテンシーを達成できるようにします。EFAは、インスタンスが同一のアベイラビリティーゾーンに存在すること、そして最大の帯域幅を得るためにはクラスタープレイスメントグループ内に配置されることが必要です。

FSx for Lustreは、数百GB/sのスループットとミリ秒未満のレイテンシーを提供するマネージド並列ファイルシステムです。S3とネイティブに統合されており、FSxファイルシステムをバケットにリンクすると、オブジェクトがPOSIXファイルとして表示されます。また、Lustreに書き込まれた結果をS3にエクスポートして戻すこともできます。永続的なSSDデプロイメントは長期間使用するスクラッチ領域に適しており、一時的なジョブデータにはより安価なScratch2が適しています。

誤ったパターンは、HPCにEFSを使用することです。EFSはNFSベースであり、多数の小規模クライアントによる汎用的なファイルI/O向けにチューニングされています。500ノードのMPIジョブが必要とする集約スループットやメタデータIOPSを維持できず、そのマルチAZ設計はレイテンシーを増加させます。EFAの代わりに標準のENAを使用すると、MPIのレイテンシーがTCPレベルに制限され、allreduceを多用するランタイムが数倍に増加します。正しい組み合わせは、クラスタープレイスメントグループ内に配置され、FSx for LustreをマウントしたEFA有効化インスタンスであり、ファイルシステムにリンクされた耐久性のあるコールドストレージとしてS3を使用します。

← データベースとキャッシング · すべてのドメイン · アプリケーション統合、メッセージング、ストリーミング →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →