SageMakerとアルゴリズムは“使う理由”が説明できるか

MLS後半で一気に情報量が増えるのが、
SageMaker関連サービスとアルゴリズム周りです。

名前だけ追うと破綻しますが、
「どの工程で、何を楽にするためのサービスか」
で整理すると、だいぶ頭が軽くなります。

---

Amazon SageMakerは「ML工程の分業ツール群」

SageMakerは単一サービスではなく、
前処理・学習・評価・デプロイを分業するための集合体です。

MLSでは
「この作業、人が書く？サービスに任せる？」
という視点で問われます。

---

SageMaker Data Wranglerは前処理特化

Data Wranglerは、
EDAから前処理までをGUI寄りで一気に進めるためのサービスです。

特徴としては、

・欠損値処理
・エンコーディング
・外れ値の可視化
・クイックモデルビジュアライゼーション

などが一通り揃っています。

試験で引っかかりやすいのは、
「Notebookで書くか、Data Wranglerを使うか」。

コードを書くこと自体が目的でなければ、
Data Wranglerを選ぶのが正解になるケースが多いです。

---

多重共線性と可視化の話

Data Wrangler絡みでよく出るのが多重共線性。

これは
特徴量同士が強く相関している状態
を指します。

対処法として出てくるのが、

・主成分分析（PCA）
・特異値分解（SVD）
・VIF（分散拡大係数）

ここで重要なのは、
精度を上げるためというより
「モデルを安定させる」目的だという点。

LASSOが選択肢に出る場合も、
特徴量選択が目的かどうか
を意識すると切りやすいです。

---

SageMaker Autopilotは「最短距離」

Autopilotは、
特徴量処理からモデル選択までを自動化するサービス。

MLS的には
「時間がない」「ベースラインを作りたい」
という条件がつくと、ほぼこれ一択です。

自分が間違えたのは、
「カスタマイズできない＝不適切」
と思い込んでいた点。

実際には、
最初の比較用モデルを作る
という文脈では非常に強力です。

---

SageMaker Clarifyは公平性チェック専用

Clarifyは
バイアス検出と説明可能性のためのサービス。

・DPL
・CDD
・CI

といった指標と一緒に出題されます。

ここは暗記というより、
「学習前後、どちらで使うか」
がポイント。

学習前 → データバイアス
学習後 → モデルバイアス

という整理で覚えると楽です。

---

エンドポイントは単一かマルチか

SageMakerのエンドポイントは、

・単一モデルエンドポイント
・マルチモデルエンドポイント

の2種類。

マルチモデルは
「モデル数が多い」「同時利用は少ない」
という条件で選びます。

常時高トラフィックなら、
単一モデルの方が安定します。

---

DeepARは“時系列まとめ役”

DeepARは、
多数の時系列をまとめて学習できる点が強み。

ARIMAとの違いは、

・複数系列を一気に扱える
・外部特徴量を使える

という点です。

試験では
「大量の時系列」「需要予測」
というワードが出たら、
かなりの確率でDeepARです。

---

Object DetectionとSSD

SageMaker Object Detectionでは、
SSD（Single Shot MultiBox Detector）がよく登場します。

特徴は、

・1回の推論で検出
・高速
・リアルタイム向き

ここでResNetやImageNetが絡んでくる場合、
事前学習モデルの利用
という文脈になります。

---

BlazingTextとK-Meansは“軽さ”が武器

BlazingTextは
テキスト分類や類似度計算向け。

・Word2Vec系
・高速
・大規模向き

K-Meansは
クラスタ数が事前に決まっている
という前提条件つきで有効です。

「未知クラス発見」ではなく、
「分けるだけ」のケース向き。

---

XGBoostは万能だが理由が必要

XGBoostは勾配ブースティング系。

精度が高いから選ぶ
ではなく、

・表形式データ
・非線形
・特徴量が多い

といった条件が揃っているか
を確認する必要があります。

---

協調フィルタリング系アルゴリズム

・因数分解機
・ニューラル協調フィルタリング

は、
レコメンド文脈で登場します。

ユーザー×アイテムの
疎行列
というワードが出たら、
この辺を疑います。

---

このあたりまで来ると、
MLSは完全に
「知ってるか」より
「説明できるか」の試験です。

サービス名を覚えるより、
「なぜそのサービスを選ぶのか」
を一言で言えるか。

そこが分かれるラインだと感じました。

行き詰まったら、
一度ちゃんと体系的にまとめられた教材で
全体像を見直すのもアリです。

次回は、
CloudSearchやComprehendなどの
「地味だけど落としやすいAWS AIサービス」と、
APIの使い分けを中心にまとめる予定です。

ここを雑にすると、
最後にじわっと点を落とします。

最適化と学習プロセスは、用語の理解不足が命取り

前処理とEDAを越えると、
次に牙をむいてくるのが「学習の中身」です。




勾配降下法、エポック、ミニバッチ。
単語は簡単なのに、
「この状況でどれを調整するか？」
を聞かれると一気に難しくなります。

---

確率的勾配降下法（SGD）は“雑だけど速い”

SGDは、
全データを使わず、一部のデータで勾配を更新する方法です。

メリット
・計算が速い
・大規模データに向く

デメリット
・収束が不安定
・振動しやすい

自分が間違えやすかったのは、
「SGD＝精度が悪い」という短絡的な理解。

実際は、
スピードと引き換えに安定性を捨てている
というトレードオフの話です。

---

モメンタムは「勢いを持たせる」だけの話

モメンタムはSGDの改良版としてよく出てきます。

直感的には、
「前回までの更新方向を少し残す」
という考え方。

これにより、
・局所的な揺れを抑える
・谷方向に一気に進む
ことができます。

ここで重要なのは、
「学習率を変える話ではない」
という点。

試験では、
収束が遅い
振動が激しい
といった状況説明のあとに、
モメンタムが選択肢に出てきます。

---

エポックとミニバッチサイズは必ずセットで考える

エポックは
「データ全体を何周学習するか」。

ミニバッチサイズは
「一度に何件ずつ学習するか」。

自分が混乱したのは、
この2つを独立して覚えていたことでした。

実際には、

・ミニバッチが小さい
　→ 更新回数が多い
　→ ノイズは多いが汎化しやすい

・ミニバッチが大きい
　→ 更新回数が少ない
　→ 安定するが局所解にハマる可能性

と、セットで効いてきます。

「学習が不安定」「時間がかかる」
という問題文では、
どちらを調整すべきかを考える癖が必要です。

---

ハイパーパラメータ探索は“人力卒業”の話

MLSでは、
ハイパーパラメータ探索手法がまとめて出てきます。

・グリッド検索
・ランダム検索
・ベイズ最適化
・ハイパーバンド

ここでの整理軸はシンプルです。

グリッド検索
→ 全探索。確実だが高コスト

ランダム検索
→ 重要なパラメータに当たる確率が高い

ベイズ最適化
→ 過去結果を使って賢く探索

ハイパーバンド
→ 早めにダメなモデルを切る

自分がやらかしたのは、
「一番賢そう＝ベイズ最適化」
で選び続けていたこと。

実際は、
計算コストや探索空間の大きさ
が前提条件になります。

---

ブートストラップは「評価の安定性」を見るため

ブートストラップは、
学習手法というより評価寄りの話です。

データを復元抽出して
何度も評価することで、
指標のばらつきを見る。

ここで重要なのは、
精度を上げるための手法ではない
という点。

「モデルが安定しているか？」
を確認するための方法です。

---

ARIMAは“時系列専用”と割り切る

ARIMAは
自己回帰＋移動平均の時系列モデル。

MLSでは、
「時系列ならDeepARかARIMAか」
という文脈で出てきます。

ARIMAは
・単一系列
・比較的シンプル
なケース向き。

大量の系列や
外部特徴量を使うなら
DeepARに軍配が上がります。

---

バイアス指標は“公平性の話”

ここは知識問題に近いですが、
整理しないと混乱します。

・KS（分布の差）
・DPL（ラベル比率の差）
・CI（クラス不均衡）
・CDD（条件付きの差）

ポイントは、
「何と何を比べているか」。

名前よりも
比較対象を意識した方が解きやすいです。

---

このあたりから、
MLSは「暗記」では太刀打ちできなくなります。

選択肢を読んで、
「あ、この状況はこれだ」
と反射的に結びつくかどうか。

理解が浅いと、
全部それっぽく見えて詰みます。

詰まったら、
一度ちゃんと図解されている教材で整理すると、
頭の中がかなりスッキリします。

次回は、
SageMaker系サービス（Data Wrangler / Autopilot / Clarify / DeepAR など）と
アルゴリズム領域に入る予定です。

「サービス名は知ってるけど、
どの場面で使うか説明できない」
を潰していきます。

モデルのアルゴリズム以前に、「データをどう扱うか」で点数が削られるのがMLS試験の恐ろしさです。自分が間違えたポイントを中心に、基礎体力を整理します。

---

探索的データ分析（EDA）：手法と目的を一致させる

MLSでは「次に何をすべきか？」を問われます。目的と図法をセットで脳内にインデックスします。

• クラス分布の偏り（不均衡） クロス集計、カウントプロット
• 外れ値の有無 ボックスプロット（箱ひげ図）、散布図
• 変数の相関関係 ヒートマップ（相関行列）
• テキストの傾向把握 ワードクラウド

---

「高いカーディナリティ」：One-Hotの罠

ユーザーIDや郵便番号など、ユニーク値が多すぎる変数（高カーディナリティ）にOne-Hotエンコーディングを使うと、次元が爆発して計算資源を食い尽くし、モデルが不安定になります。

• 試験対策のキーワード：
  • Feature Hashing（ハッシュトリック）： 次元を固定しつつ、高カーディナリティをさばく。
  • Target Encoding： 目的変数の平均値で置換する（ただし、リークに注意）。
  • SageMaker Data Wrangler： これらをノンコードで処理できるAWSの推奨ツール。

---

欠損値（NaN）処理：時系列と統計の使い分け

「とりあえず埋める」ではなく、データの性質を見極めるのがMLS流です。

• 時系列データ： 前の値を踏襲する Forward Fill や線形補間。
• 数値データ（外れ値あり）： 平均値よりも 中央値（Median） が安定します。
• カテゴリデータ： 「Unknown」という新しいカテゴリとして扱うのも一つの解です。

---

クラス不均衡：SMOTEのその先へ

少数クラスを合成して増やす SMOTE は強力ですが、試験では以下のセットで問われます。

1. 手法： オーバーサンプリング（SMOTE） or アンダーサンプリング。
2. 評価： Accuracy（正解率）を信じない。F1スコアやAUC を重視する。
3. 注意点： SMOTEは「訓練データ」のみに適用すること。テストデータまで合成すると正当な評価ができません。

---

インフラ：GPUと分散トレーニングの勘所

巨大なデータや複雑なモデル（RNN/CNN）を扱う際、学習時間の短縮がテーマになります。

• インスタンス選択： P系（P3/P4）やG系（G4dn/G5）のGPUインスタンスを選択。
• 分散学習：instance_count を2以上に設定。
  • データ並列： データを分割して各ノードで学習（主流）。
  • モデル並列： 巨大すぎて1つのGPUに乗らないモデルを分割。
• 注意： 学習ジョブは一時的なクラスターなので、通常のEC2のようなAuto Scaling Groupで管理するのではなく、SageMakerが「指定された台数」をプロビジョニングする形式です。

---

1日目のまとめ

「NaNだから埋める」「偏っているからSMOTE」といった条件反射ではなく、「ビジネス要件（見落とし厳禁か、誤報厳禁か）」と「データの分布」を天秤にかける視点が、合格への近道だと痛感しています。

明けましておめでとうございます。

昨日は評価指標を整理しました。今日はAWSのサービス側。SageMakerは機能が多く、名前の暗記だけでは確実に迷子になります。試験で問われやすいポイントを「解決したい課題」の軸で整理し直します。

---

機械学習の“現場トラブル”：ドリフトと変換

ドリフト（データ vs コンセプト）

ここ、試験で最も混同しやすいポイントです。

• データドリフト： 入力データの分布が変わること（例：若年層向けサービスに高齢者が増えた）。
• コンセプトドリフト： 入力と正解の関係性が変わること（例：景気変動で、以前と同じ年収でも購買行動が変わった）。
• なぜそうなるのか： モデルの精度が落ちたとき、原因が「データの変化（データ）」なのか「世の中の仕組みの変化（コンセプト）」なのかで、再学習の戦略が変わるからです。

前処理の用語整理

• 標準化（Standardization）： 平均0、分散1。外れ値がある程度含まれる場合に安定します。
• 正規化（Min-Max）： 0〜1に収める。画像処理などでよく使いますが、外れ値に非常に弱いです。
• 対数変換： データの分布が右に長く伸びている（ベキ分布）とき、中心にギュッと寄せるのに有効です。

---

主要アルゴリズムの「決め打ち」ワード

• Linear Learner： 線形回帰・分類。とりあえずのベースライン。
• XGBoost： 構造化データの王者。決定木ベース。
• BlazingText： テキスト分類 or Word2Vec（単語埋め込み）。とにかく高速。
• Seq2Seq： 翻訳や要約。入力も出力も「列」の場合。
• NTM（Neural Topic Model）： 文書群から「トピック（テーマ）」を自動抽出。

---

データ形式と投入モード：速度の壁

• RecordIO protobuf： SageMaker組み込みアルゴリズムで最も効率が良い形式。Pipeモードで使うことで、S3からストリーミングしながら学習でき、ディスク消費と時間を大幅に節約できます。
• 入力モードの三択：
  • Fileモード： 全データをダウンロード。最もシンプルだが、巨大データだと開始までが遅い。
  • Pipeモード： ストリーミング。高速だがRecordIOなどの対応形式が必要。
  • Fast Fileモード： S3をローカルのようにマウント。実装が楽で、ダウンロード待ちもない「いいとこ取り」。

---

推論エンドポイントの使い分け（超重要）

• リアルタイム： 低レイテンシ必須、常時稼働。
• サーバーレス： 負荷が断続的（たまにしか来ない）。同時実行数を予約すればコールドスタートも防げる。
• 非同期： ペイロードがデカい（最大1GB）、処理が長い（最大1時間）。完了後に通知を受け取る。
• Batch Transform： リアルタイム性は不要。数百万件のデータを夜間に一気に処理したいとき。

---

ガバナンス・運用：チームで戦うための機能

• Pipelines： MLワークフローの自動化。Step Functionsよりも「ML特有のステップ」が扱いやすい。
• Model Registry： バージョン管理と「承認フロー」。S3のフォルダ管理を卒業するためのもの。
• Lineage Tracking： 「このモデル、どのデータで学習したっけ？」という履歴を遡るための監査証跡。
• Model Cards： モデルの仕様書。リスクや制限事項を「人間向け」に残す。

---

Studio・ノーコード・自動化の棲み分け

• SageMaker Studio： データサイエンティスト向けの統合開発環境（IDE）。
• Canvas： ビジネスアナリスト向け。GUIだけで予測。
• AutoPilot： 開発者向け。「データはあるから、最適なモデルとコードを自動生成してほしい」とき。
• JumpStart： 「一から作るのは面倒、既存の有名モデル（LlamaやBERT等）をすぐ使いたい」とき。

---

監視とセキュリティ

• Model Monitor： CloudWatchでは届かない「MLの質」の監視。データの欠損やドリフトを検知します。
• Data Wrangler： GUIで前処理。PII（個人情報）のマスキングも前処理工程の一環として実行可能。
• Role Manager： ML開発に特化した権限テンプレート。最小権限の原則を簡単に実現。

---

2日目のまとめ

今日は「運用の目線」でサービスを整理しました。 試験では「データが巨大でI/Oがボトルネックなら？ → FSx for Lustre + Pipeモード」や「数十分かかる推論なら？ → 非同期推論」といった、状況に応じた「最適解」が問われます。

MLA-C01の勉強をしていて、いちばん「覚えたはずなのに落ちる」のが評価指標でした。問題文の状況に対して、指標の選び方がズレると一気に全部崩れる。今日はそこを落ち着いて整理します。

---

回帰の評価指標（MSE / MAE / RMSE / R^2 / MAPE）

回帰系は、指標の名前が似ているのがまず罠でした。

MSE（平均二乗誤差）

平均との差を二乗して平均。大きな誤差ほど強くペナルティがかかる。

• なぜそうなるのか： 二乗することで外れ値に強く反応します。外れ値を「許してはいけない重大なミス」として重く見たいときは有効ですが、単位が元の値の二乗になるため、直感的な解釈が難しいのが難点です。

RMSE（平方平均二乗誤差）

MSEの平方根。

• なぜそうなるのか： MSEの弱点（単位が二乗で解釈しにくい）を補うために平方根を取っています。これにより単位が元のデータと同じ（円、kgなど）に戻るため、「説明のしやすさ」が問われる試験問題では正解になりやすいです。

MAE（平均絶対誤差）

絶対値で平均との差を平均。

• なぜそうなるのか： 二乗がないので、極端な外れ値があっても全体が支配されにくいです。**「外れ値の影響を抑えて、一般的な精度の実態を見たい」**業務（売上や需要予測など）では、MSEよりもこちらが選ばれます。

R^2（決定係数）

「平均値だけで予測し続けるモデル」に比べて、どれだけ改善したかの割合。

• 間違えた理由： 負になり得ることを忘れていました。負の$R^2$は、「平均値で予測する（ベースライン）よりも性能が低い」という、かなり絶望的な状態を指します。

MAPE（平均絶対パーセント誤差）

誤差を「割合（%）」で見る。

• なぜそうなるのか： 単位が異なる複数の商品の予測精度を比較するのに便利ですが、実測値に0が含まれると分母が0になり計算不能（または爆発）になるという致命的な弱点があります。「売上が0の日があるデータ」という条件が出たら選んではいけません。

---

二値分類の評価指標（Recall / Precision / F1 / Accuracy / 特異度 / F-β / Balanced Accuracy / AUC）

ここは日本語訳が揺れるので、英語名と「何を見落としたくないか」のセットで覚えます。

Recall（再現率）

実際に陽性の人のうち、陽性と判定できた割合。「見落とし」を減らす指標。

• なぜそうなるのか： 分母が「実際の陽性」。医療診断のように「病気の人を陰性と誤判定（偽陰性）するのが一番怖い」ケースで最優先されます。

Precision（適合率）

陽性と判定した人のうち、本当に陽性だった割合。「空振り（誤警報）」を減らす指標。

• なぜそうなるのか： 分母が「予測の陽性」。スパムメール判定のように「普通のメールをスパムと誤判定（偽陽性）するのが一番困る」ケースで重視されます。

F1スコア / F-βスコア

RecallとPrecisionのバランス。

• F1スコア： 二つの調和平均。片方が極端に低いと全体も低くなる性質があります。
• F-βスコア： βを使ってどちらを重視するか調整します。beta > 1ならRecall重視、beta < 1ならPrecision重視です。ここ、試験で「どっちがどっち？」となりやすいポイントです。

Accuracy（正解率）と Balanced Accuracy

• Accuracy： 全体でどれだけ当たったか。データが「陽性1：陰性99」のように偏っている（不均衡）と、全部陰性と答えるだけで99%になってしまい、役に立ちません。
• Balanced Accuracy： 「Recall（陽性の正解率）」と「特異度（陰性の正解率）」の平均をとる指標。不均衡データでも公平に評価できます。

AUC（ROC曲線下面積）

閾値を0から1まで動かしたときの総合的な判別能力。

• なぜそうなるのか： 特定の閾値（0.5など）に依存せず、モデルそのものの「並び替え能力」を評価します。不均衡データに強く、ランダムだと0.5、完璧だと1.0になります。

---

学習の挙動：損失が周期的に増減する

損失（Loss）がなめらかに下がらず、ギザギザしたり周期的に上下するパターン。

学習率（Learning Rate）が大きすぎる

• 挙動： 最適な点（谷底）を飛び越えて、左右の壁を往復している状態です。
• 対策： 学習率を下げます。

バッチサイズが小さすぎる

• 挙動： 1回の更新に使うデータが少なすぎて、たまたま選んだデータの癖に反応し、学習がフラフラします（ノイズが多い）。
• 対策： バッチサイズを大きくして、更新を安定させます。

ドロップアウト（Dropout）

• 対策： 「検証損失（Validation Loss）だけが上昇していく」という絵に描いたような過学習ならドロップアウトを増やしますが、振動している場合はまず学習率を疑うのがセオリーです。

---

特徴量エンジニアリング：正規化（Min-Max）vs 標準化

• Min-Max正規化： 値を0〜1に収める。外れ値があると、他のデータが極端に狭い範囲に押し込められてしまうため、外れ値に弱いです。
• 標準化（Standardization）： 平均0、分散1にする。正規分布を仮定するアルゴリズムや、外れ値がある程度含まれる場合に適しています。
• 共通点： k-NNやニューラルネットワークなど、「距離」や「勾配」を計算するアルゴリズムでは、どちらかのスケーリングが必須です。

---

ここまでのまとめ（自分向け）

今日は評価指標を中心に整理しました。

結局、私は「指標そのもの」より「問題の状況（不均衡データ、外れ値の有無、ビジネス的なリスク）に合う指標」の選び方で落としていました。

明日は、AWSのサービス側（SageMakerの組み込みアルゴリズムと、それぞれの推奨指標）をまとめます。

日々の学習ログついでにまとめておく AWS データ系サービスたち

Data Engineer Associate の勉強を細々と続けて無事合格しました。
そこで今日は、自分が特に迷いやすかったところを、ゆるく整理してみました。

（ふとしたタイミングで見返すと、記憶の引き出しがすぐ開くのでおすすめ。）

---

---

AWS Glue と DataBrew

Glue はとにかく範囲が広くて、試験でも「Glue でできること」と「別サービスでやるべきこと」を混同しがちでした。

なぜ間違えたのか

理由ははっきりしていて、Glue の中にも

• Data Catalog
• Jobs
• Crawlers
• Studio
• DataBrew
  …など複数の機能があるからです。

特に DataBrew を「ノーコードの ETL」と捉えていると、Glue Studio（ノーコード ETL UI）との境界が曖昧になって混乱します。

なぜそうなるのか

アーキテクチャでの役割が違うためでした。

• DataBrew → データの「前処理・整形」のためのツール
• Glue ETL Jobs → 本番 ETL、ジョブ管理、スケジューリング
• Glue Studio → ETL を視覚的に組むためのエディタ

「現場のデータ整理」なら DataBrew、「本番のパイプライン」なら Glue Jobs。
これでようやく腑に落ちました。

---

Amazon Redshift / Redshift Serverless

データウェアハウスの中心でありながら、試験では Redshift のディストリビューションスタイルをよく取り違えてしまいました。

ディストリビューションスタイルの違い

• ALL
  • 小さなディメンションテーブルを全ノードにコピー
  • JOIN が高速
  • 大きいテーブルで使うと逆に遅い
• EVEN
  • 行を均等に分散
  • よく使われる標準スタイル
• KEY
  • 指定したキーで分散
  • JOIN キーを合わせると高速
• AUTO
  • Redshift が最適化してくれる
  • 助かるけど挙動はブラックボックス

なぜ間違えたのか

ALL を「小さいテーブル向け」と覚えていたものの、問題文のテーブルサイズを読み飛ばして誤答…
冷静に考えると、ALL は便利ですがコストも大きいので、使いどころは限られます。

Redshift Serverless の理解ポイント

Serverless は「スケールと料金を意識せず使える」タイプですが、
実は クラスターモードと内部構造は似ている ことを忘れがちでした。

• Data API 対応
• 暗号化やバックアップは自動
• WLM 設定が不要

Lambda やコンテナから動的にクエリするようなシナリオも非常に扱いやすいです。

---

---

Amazon Athena

Athena は使い勝手が良い反面、試験では「コスト管理」と「権限管理」を忘れがちでした。

ワークグループ

• クエリ単位の課金管理
• 制限・メトリクス・アクセス制御を分離
• 複数チームの利用で必須

これを「ただのフォルダ分け」と軽く見ていて間違えたことがあります。
ワークグループは Athena の運用に非常に重要な概念でした。

SPICE

QuickSight の話と混同しがちですが、SPICE は Athena とは別物で「QuickSight のインメモリエンジン」です。
リアルタイムなら Direct Query、パフォーマンスとコスト重視なら SPICE と判断できます。

---

Amazon Lake Formation

Lake Formation でよく迷ったのは、「Glue の権限」と「Lake Formation の権限」の境界です。

列レベル・行レベルのフィルタリング

Lake Formation は

• テーブル
• 列レベル
• 行レベル
  まで細やかにアクセスを制御できます。

なぜ間違えたのか

「Glue Data Catalog を使っているから、権限も Glue で設定する」と誤解していたためです。
実際は逆で、Lake Formation が全体のデータガバナンスを統括します。

「誰が・どの列まで見られるか」を一元管理するのは Lake Formation。
やっとこの構図が理解できました。

---

Parquet / ORC と gzip / snappy

データ形式と圧縮方式は、普段意識せず使ってしまうので試験で差がつきました。

Parquet と ORC の違い

• Parquet
  • 列指向
  • Athena / Redshift Spectrum と相性が良い
  • 汎用性が高い
• ORC
  • Hive 系に最適化
  • より高い圧縮と高速な読み取りが得意

圧縮方式

• gzip
  • 圧縮率は高い
  • 展開は遅い
  • コールドデータ向け
• snappy
  • 展開が速い
  • クエリの多いデータに向く
  • Athena や EMR でよく利用される

なぜ間違えたのか

「圧縮率＝性能」と思い込んでいたこと。
実際は、分析処理は「解凍速度」がボトルネックになることが多く、snappy が選ばれやすい理由もそこにあります。

---

---

まとめ

データエンジニアリング領域は、サービスの役割が似ているものも多く、何がどこまで担当するのかを誤解しやすいところがあります。
試験で実感したのは、「単語暗記よりも、各サービスの立ち位置を理解する方が圧倒的に強い」ということでした。

また忘れかけた頃に読み返して、記憶をあたためたいと思います。

AWS のデータ分析系サービスは、とにかく種類が多くて名前も似ています。
勉強していると「あれ、これって何のサービスだっけ？」となり、試験中にふと迷うこともありました。ここでは、直近で手こずったサービスを、復習メモも兼ねてゆっくり整理しておきます。

---

Kinesis Data Streams

Kinesis の問題で間違えやすいポイントは「スループット計算」と「保持期間」。
特に試験で迷ったのは、シャード＝並列度とスループットの単位というところ。

• 1 シャードの上限
  • 書き込み：約 1,000 レコード or 1MB/秒
  • 読み込み：2MB/秒
• ただし API のリトライとパーティションキーの偏りで実効値が変わる

ここをうっかり「Kinesis Firehose の自動スケーリング」と混同しがち。
Firehose はこっちが気にしなくても自動調整ですが、Streams は自分でシャードを増減します。
試験では「どちらがバッチ処理か？」「どちらがストリームの生レコードか？」を意識すると正誤判断しやすかったです。

---

Amazon Managed Service for Apache Flink

Flink の難しさは、とにかく「どこまでマネージドか」を間違えがちなところ。

• アプリケーションコードは自分で用意
• スケーリングは自動
• チェックポイント管理もやってくれる

つまり「Glue のようにノーコードでは動かない」。
ここを勘違いして「SQL ベースで処理するサービス」と誤解してしまい、試験で迷いました。
Flink は 複雑なストリーム処理のためのエンジン、という軸で覚えるとわかりやすいです。

---

Amazon TimeStream

IoT やメトリクスに強い時系列データベース。

間違えたポイントは、
「TTL（保持期間）とストレージ階層が自動で移動する」という仕様を忘れていたこと。

• メモリストア：高速検索
• マグネティックストア：長期保存、低コスト

DynamoDB と比較しそうになりますが、TimeStream は時系列に最適化されていて、クエリも専用の SQL 方言です。「監視データなら CloudWatch Logs でいいのでは？」と思いがちですが、分析前提の可視化なら TimeStream の方が有利。

---

Amazon Managed Service for Grafana

Grafana Cloud を AWS で簡単に動かすイメージ。

間違えたのは、Grafana と QuickSight を用途で混同しやすかった点。

• Grafana → 時系列データの可視化に強い
• QuickSight → BI ダッシュボード、ビジネス指標向け

試験では「時系列の可観測性ダッシュボードを作りたい」＝Grafana。

---

Amazon MWAA（Managed Workflows for Apache Airflow）

Airflow のマネージド版。

ミスしがちなのは、「Lambda や Glue ワークフローと混同してしまう」こと。
Airflow は DAG（依存関係付きのワークフロー）を使うので、バッチ処理の順番管理が主役。

さらに

• 実行基盤は自動管理だが
• Python ライブラリやプラグインなどは自分で管理

「全部自動でやってくれる」と思って間違えた問題もあったので反省。

---

Amazon QuickSight

間違えたポイントは SPICE と直接クエリの違い。

• SPICE：インメモリで速い、データ取り込み（キャッシュ）的
• Direct Query：毎回データソースに問い合わせる

試験では「頻繁に更新されるリアルタイム指標」＝Direct Query
「コスト最適化」「高速」＝SPICE
これで大体判断可能。

---

AWS Glue

Glue は領域が広すぎて、試験でも毎回混乱しがちなサービスです。

Data Catalog

ここを DynamoDB とか Hive メタストアと混同しがち。
中心にあるのは “メタデータ統合カタログ”。

Schema Registry

EventBridge Schema Registry と混同するミスあり。

Glue のは Kafka や Kinesis Data Streams の Avro スキーマを管理する方。

ワークフロー

Airflow と混同しやすい。
Glue のワークフローは「Glue Job や Crawler の実行順序管理」。Airflow ほど柔軟ではない。

Studio

ここを SageMaker Studio と間違えやすい。
Glue Studio は ETL の可視化と SQL ETL のためのもの。

Detect PII

Glue の識別情報検知機能。
Macie と混同しやすいが、Glue のは “カラムレベルの検知”。

---

Amazon AppFlow

SaaS から AWS にデータを安全に取り込むサービス。
Salesforce、Slack、S3 などのデータ連携。

間違えたのは、
「ETL の変換機能を期待してしまったこと」。
AppFlow は変換もできるが Glue のような本格 ETL ではない。

---

Amazon AppSync

GraphQL のマネージドサービス。

誤解しがちなのは、
「REST API の代わり」ではなく「GraphQL リゾルバで複数データソースを統合できる」ところ。
Data Engineer の観点だと、クライアントから動的に必要なデータだけ取ってくる API 層という理解で十分。

---

Amazon EMR

EMR で間違えやすいのは、ストレージ層の違いです。

HDFS データストア

• EMR クラスター内にだけ存在
• クラスター終了するとデータ消える
• 高速だが弾力性なし

EMRFS データストア

• S3 バックエンド
• 永続化できる
• ただし整合性の問題があり、EMRFS S3 Consistent View が存在

試験では
「長期保管」「スケーラブル」→ EMRFS
「高速性」→ HDFS
で判断できました。

---

Amazon Redshift / Redshift Serverless

Redshift は一問でも混乱すると連鎖で間違えるので要注意。

Data API（JDBC と比較する出題）

• Data API：SQL を HTTPS 経由で実行。クライアント不要
• JDBC/ODBC：ドライバ必須、持続的接続

「Lambda から簡単に扱いたい」＝Data API。

VACUUM

ここを忘れていて間違えました。
Redshift は列指向だが、行の削除や更新で空き領域が断片化する。
VACUUM はその再整理を行うメンテナンス。

Serverless では自動化が進んでいるので、クラシック版での出題が中心でした。

---

Amazon Athena

Athena でよく迷うのはワークグループ。

ワークグループ

• 「クエリ単位の請求管理」や「アクセス制御」を分ける仕組み
• チームごとにクエリ上限やコスト制限を設定する

試験ではガバナンス系の文脈でよく出てきます。

---

Amazon Lake Formation

湖を「安全に」運用するためのサービス。

迷ったのは
「Glue Data Catalog の権限管理との境界」。

Lake Formation は

• 列レベル
• 行レベル
• テーブル単位
  などの粒度でアクセス制御ができる。

Glue だけではできない細かさなので、用途を切り分けるのが試験のポイント。

---

Apache Parquet / ORC と圧縮方式

ここは出題頻度が高いのに、誤差レベルの違いで混乱しがち。

Parquet

• 列指向
• 多くの AWS サービスが最適化（Athena/Redshift Spectrum）
• 汎用性高い

ORC

• Hive や EMR で相性が良い
• 圧縮効率が高く、読み取り最適化

圧縮（gzip vs snappy）

• gzip：圧縮率は高いが解凍が遅い
• snappy：解凍が速く、ETL や Athena に向く

試験での判断ポイントは、
「クエリ速度重視」＝snappy
「ストレージ節約」＝gzip

---

まとめ

データ系サービスは名前も機能も似ていて、境界を理解していないと試験で混乱します。
今回の復習で気づいたのは、
「サービスを単体ではなく、周辺サービスとの組み合わせで覚える方が間違えにくい」
ということでした。

今回は、自分が模試やハンズオンの中でつまずいたポイントをまとめました。
どれも一度は混同したり、選択肢で迷ったりしたところです。
自分用の復習ノートとして読んでもらえたらうれしいです。

---

Secret Manager vs SSM Parameter Store（Secure String）

どっちを使う？
試験でよく出るのは「後者（Secure String Parameter）の方が有利なケース」。
たとえば「少数の設定値をCodeBuildやLambdaで参照するだけで、ローテーションは不要」な場合。

Secret Managerは自動ローテーションやシークレットライフサイクル管理が得意だけど、
コストも高め。逆にSecure Stringは低コストで、KMS暗号化付きの単純な設定管理に最適。

自分が間違えた理由：
「Secret＝セキュア」という印象で、何でもSecret Managerを選んでしまった。
でも、要件が“自動ローテーション不要”ならSSMの方が正解。

---

EC2がAbuse Noticeを受け取ったときの最初の対応

AWSから「あなたのインスタンスが悪意ある通信をしています」と通知されたとき。
まずすべきは 該当インスタンスのネットワーク隔離（停止 or SG遮断）。

ログ確認や原因特定はそのあと。誤って「即削除」すると、証跡が消えて原因分析できない。
AWSはまず通信を止める→証跡確保→分析→再発防止の順序を推奨。

---

悪意あるIPパケット検査のアプローチ２つ

1. Network Firewallでのステートフルインスペクション（シグネチャ検知）。
2. GuardDutyによるVPCフローログ・DNS・CloudTrailからの脅威検知。

両者の違いは「リアルタイム検査」か「分析検知」か。
Firewallは通信を“通す前”に止める、GuardDutyは“通った後”に気づく。

---

一般的なWebエクスプロイトへの保護方法

• AWS WAFでSQLiやXSSの防御。
• Shield Standard / AdvancedでDDoS対策。
• CloudFront + WAF構成でエッジ防御を組み合わせるのが王道。

Security GroupやNACLはL3/L4レベル、WAFはL7レベルと覚えると整理しやすい。

---

CLBからALBに切り替えたら古い端末がつながらない？

原因はALBがHTTP/2や最新TLSを優先しているため。
古いクライアントが古い暗号スイートしか対応していないと、
ハンドシェイクで失敗する。

なぜそうなるか：
CLBはTLS 1.0/1.1をまだサポートしていたが、
ALBはセキュリティ強化のためTLS 1.2以上が既定。

---

kms:CreateGrant の役割

KMSキーの利用権限を一時的・限定的に他サービスへ付与するための操作。
例：EBSスナップショットやRDS暗号化が、内部的にこのGrantを使う。

---

initiate-vault-lock / abort-vault-lock のユースケース

Vault LockはS3 GlacierやAWS Backup Vaultの「WORM（Write Once Read Many）」機能。

• initiate-vault-lock：ポリシー設定を開始。
• abort-vault-lock：コミット前に取り消す。

一度complete-vault-lockすると変更不可。
試験では「コンプライアンス対応（改ざん防止）」のキーワードが出たらVault Lockを選ぶ。

---

SNSデータ保護ポリシーの役割

SNSトピックに機密データを誤送信しないよう制御するための仕組み。
メッセージ本文にPII（個人情報）などを含めるのを防ぐため、
Data Protection Policyでキーワードマッチや拒否ルールを設定できる。

---

インターフェイスエンドポイントとゲートウェイエンドポイントの違い

種類	対応サービス	通信方式	コスト	覚え方
ゲートウェイ型	S3 / DynamoDB	ルートテーブルで指定	無料	“ゲート”は出入口（大通り）
インターフェイス型	ほとんどのサービス	ENI経由のPrivateLink通信	有料	“インターフェイス”＝専用線で握手

---

GuardDuty / Inspector / Detective / CloudTrail の違いと覚え方

サービス	目的	タイプ	覚え方
GuardDuty	悪意ある挙動の検知	監視・分析	「門番」＝警備員
Inspector	脆弱性スキャン	予防	「検査官」＝脆弱性チェック
Detective	事後分析・相関調査	調査	「探偵」＝事件の後に動く
CloudTrail	API操作履歴記録	証跡	「足跡」＝すべての操作を残す

なぜ混乱したか：
DetectiveとGuardDutyの違いが曖昧だった。
→ 「前に気づくか、後から調べるか」で線を引くとスッキリ。

---

IAM Access Analyzer と Service Control Policy（SCP）の違い

Access Analyzer：
組織やアカウント外に誤って共有されているリソースを検出。
“可視化”と“検出”が目的。

SCP：
Organizations全体で何をしてはいけないかを制限。
“制御”と“予防”が目的。

よくある間違い：
Access Analyzer＝SCPの一部と思っていた。
→ 実際は全く別物。前者は「気づく」、後者は「止める」。

---

まとめ

Security Specialtyの学習では、「似ているけど目的が違う」ものがたくさん出てきます。
試験では単語を丸暗記するより、「この機能はどんなタイミングで使うのか？」をイメージしておくと安定します。

自分は何度も「サービス名で反射的に選んで失敗」したので、
今は「要件 → 目的 → サービス名」の順で考えるようにしています。

RPOとは（Recovery Point Objective）

どれくらい過去に戻れるか”の目安。災害直前の最新データからどこまで古くても許せるか、という「データの許容損失時間」を表します（例：RPO=15分なら、最悪15分分のデータは失う想定）。AWSの公式ホワイトペーパーでも、RPOは“DRサイト上のデータと最新データの最大許容の差”として説明されています。

RTO（RTO: Recovery Time Objective）

どれくらい“早く戻すか”の目安。サービス停止から復旧までの最大許容ダウンタイム（例：RTO=1時間なら、1時間以内に業務を再開したい）。こちらもAWS資料で“中断から復旧までの最大許容遅延”と定義されています。

DRパターンの基本（コスト↔復旧性のトレードオフ）

Backup & Restore（バックアップ＆リストア）

いちばんシンプル。 通常時は本番のみ。障害時にバックアップから環境・データをリストアして立ち上げ直します。

• 目安：RPO中～長 / RTO中～長（時間～日）。
• 使うものの例：AWS Backup, Amazon S3/Glacier, IaC（CloudFormation, CDK）で環境再構築、テーブル系ならポイントインタイムリカバリ（RDS/DynamoDB）など。
• 向き：コスト最優先、停止許容が大きめのワークロード。

コールドスタンバイ

最小限の資源だけ“冷やして”置く。 代替リージョン/アカウントにAMI/スナップショット・テンプレートなどを用意。障害時に必要な台数を起動・スケール。

• 目安：RPO中 / RTO中（数時間想定）。
• 向き：復旧時間は欲しいが、普段の固定費は抑えたい。

パイロットライト（Pilot Light）

“火種”だけ常時稼働。 コアDBや最小構成だけは動かし続け、障害時に周辺を一気にスケールアウト。

• 目安：RPO短～中 / RTO短～中。
• 向き：DBの起動時間やデータ同期の不確実性を減らしたい。AWSのDR設計でもよく登場する現実解。 AWS ドキュメント

ウォームスタンバイ（Warm Standby）

“細め”に常時待機。 本番の縮小版をDR側で常時提供しておき、障害時にスケールアップ＆ルーティング切替。

• 目安：RPO短 / RTO短（分～短時間）。
• 向き：重要システム。コストは上がるが復旧は速い。

ホットスタンバイ（Hot Standby / マルチサイト・アクティブ/アクティブ）

“いつでも本番”。 複数サイトで同時稼働し、ヘルス次第で即時フェイルオーバー。

• 目安：RPO最短 / RTO最短（秒～分）。
• 向き：停められないワークロード。コスト・複雑性は最大。Route 53、グローバルアクセラレータ、マルチAZ/マルチリージョンDB、キューやイベントの冪等設計などがカギ。

AWS Backupの概要（手を動かす系の要点だけ）

“バックアップ運用の共通部分をまとめてお任せ”できるフルマネージドサービス。ポリシーで各リソースのバックアップ頻度・保持を集中管理できます。
主なポイント：

• バックアッププランとバックアップボールトで、スケジュール・保持・保存先を一括管理。Organizations連携でアカウント横断ポリシーも。
• 対応サービスが広い（EBS/EC2, RDS/Aurora, DynamoDB, EFS, FSx, S3 など）。＊最新の対応・地域はドキュメントで要確認。
• ライフサイクルで低コスト階層へ自動移行、クロスアカウント/クロスリージョンコピーでDR耐性を上げやすい。
• Vault Lock（WORM）で“消せない/改ざんできない”バックアップ（ランサム対策）。監査・コンプライアンス観点で強い。
• 復元テストの自動化も設計に入れると◎（“取れてる”と“戻せる”は別物）。IaCと合わせて定期リストア演習を回すのが実務の安定運用。

ちょい実務Tip：

• まずRPO/RTOの“数字”を合意 → それに合わせてDR方式を選択 → AWS Backupのポリシーで頻度・保持・コピー先をセット → 定期復元演習で検証、の順がスムーズ。
• データとアプリは別物。スナップショットだけでなく、アプリの再構築（IaC）や依存関係（IAM/シークレット/ネットワーク）まで“戻せる”計画を。