サーバーレスとプロビジョニングのトレードオフ

AWS の多くのデータサービスには、容量を自分で決めて確保する「 (プロビジョンド)」の形と、容量を意識せず使った分だけ払う「」の形があります。さらに、AWS が運用を引き受けると、の上に自分でソフトウェアを入れて運用するアンマネージドの形もあります。

DEA では、負荷の予測しやすさ、コスト、運用負荷、細かい設定の自由度から、どちらの形を選ぶかを説明できることが問われます。

Point

Provision = 用意する、供給する の意味です。プロビジョンドは「前もって容量を用意しておく」形です。
Serverless は「サーバーがない」のではなく、「サーバーの用意と管理を利用者がしなくてよい」形です。
Managed = 管理された の意味で、マネージドサービスは AWS がパッチ適用、障害時の置き換え、バックアップなどを引き受けるサービスです。
和訳
- Provision: 用意、供給
- Weblio英和辞書「provision」

概要

選び方の軸は、「負荷が予測できるか」と「どこまで自分で制御したいか」です。

観点		プロビジョンド
容量の決め方	自動で増減します	自分でノード数やサイズを決めます
課金	使った処理量や時間に応じて払います。使わない時間は (基本的に) 払いません	確保した容量に対して、使っていなくても払います
向く負荷	断続的、変動が大きい、予測できない	一定で高い、予測できる
運用負荷	低い	サイズの見直しやスケーリングの設定が必要です
細かい制御	選べる設定が少ない	インスタンスの種類や設定を細かく選べます
起動の速さ	最初の実行で起動の待ちが出ることがあります	常に起動しているため待ちがありません

主要技術

①サービスごとの比較 ⚠️ 頻出

サービス	プロビジョンドの形	の形	選び方
	プロビジョンドクラスター (RA3 のノード数を指定)。予約ノードで割引を受けられます	Redshift Serverless。 (Redshift Processing Unit) の使用時間で課金され、クエリがないときは処理の課金がありません	24 時間ずっと高い負荷ならプロビジョンド+予約、日中だけや不定期の分析ならサーバーレス
	EMR on (インスタンスの種類、スポット、ブートストラップ、への接続を細かく制御)	EMR Serverless (アプリケーションを作り、ジョブを投げるだけ。事前に初期化した容量で起動の待ちを減らせます)	クラスターの細かい設定や独自のソフトが必要なら EC2、運用を減らしたいならサーバーレス
	プロビジョンド (ブローカーの数とサイズ、ストレージを指定)	MSK Serverless (容量の管理が不要)	の設定を細かく調整したい、非常に大きな負荷ならプロビジョンド、変動する負荷で運用を減らしたいならサーバーレス
	プロビジョンドモード (数を指定)	モード (シャードを自動で管理)	流量が予測できるならプロビジョンド、予測できない・新しいワークロードならオンデマンド
	プロビジョンドキャパシティ (読み書きの容量を指定、自動スケーリング可)	オンデマンドキャパシティ (リクエストごとの課金)	安定した負荷ならプロビジョンド、急な増減や予測不能ならオンデマンド
での分析	Redshift のプロビジョンドクラスター、のプロビジョンドキャパシティ	Athena (スキャン量の課金)、Redshift Serverless	たまのアドホックなクエリなら Athena、頻繁で重い集計なら Redshift
	EMR on EC2	(ワーカーの使用時間の課金)、EMR Serverless	運用を減らしたいなら Glue / EMR Serverless

⚠️ 頻出: 「月末だけ、または不定期に分析し、それ以外は使わない」「運用負荷を最小に」はサーバーレス (Redshift Serverless、Athena、EMR Serverless)、「24 時間一定の高い負荷で、コストを最小に」はプロビジョンドと予約 (またはスポット) の組み合わせです。

②マネージドサービスとアンマネージドサービス

同じソフトウェアでも、AWS ので使うか、に自分で入れて使うかを選べます。

観点	マネージドサービス (例: 、、、、)	アンマネージド (EC2 の上で、、Hadoop などを自前運用)
構築とパッチ適用	AWS が行います	自分で行います
障害時の置き換え、可用性	AWS がマルチの構成や置き換えを用意します	自分で設計し、監視して対応します
バックアップと監視	組み込みの機能を使えます	自分で仕組みを作ります
設定の自由度	AWS が許す範囲に限られます	やソフトウェアのすべてを自由に変えられます
責任の範囲	利用者はデータ、アクセス権、設定に集中します ()	OS より上のほぼすべてが利用者の責任です
との統合	IAM で認証・認可できるものが多いです	ソフトウェア独自の認証を自分で管理します

試験の問題文に「運用のオーバーヘッドを最小に」「パッチ適用の手間をなくしたい」とあれば、マネージドサービス (さらに) を選びます。「特定のバージョンや独自のプラグインが必須で、マネージドサービスでは対応できない」場合に限り、EC2 での自前運用を考えます。

③コストの比べ方

状況	有利な形	理由
1日に数回の短いジョブ		使わない時間の課金がありません。
常に高い使用率	プロビジョンド + 予約 /	単価が下がり、使用率が高いほど得になります。
中断してよいバッチ処理	on の (タスクノード)	大きな割引を受けられます。
負荷の予測ができない新しいサービス	サーバーレス /	容量の見積もりの失敗 (過剰・不足) を避けられます。
スキャン量が大きく、頻繁なクエリ	(またはプロビジョンドの容量)	スキャン量の課金が積み重なると割高になります。

サーバーレスは「使った分だけ」ですが、常に高い負荷で使い続けると、確保した容量より高くなることがあります。逆に、プロビジョンドは使用率が低いと、確保した容量の大部分が無駄になります。

Redshift Serverless のまま常に一定量のを使い続けている場合は、サーバーレス予約 (1 年または 3 年の期間で RPU の量を約束する割引) を購入できます。予約した RPU が先に使われ、超えた分はオンデマンドの料金になります。割引の幅は、プロビジョンドクラスターの 3 年の予約ノードの方が大きくなります。

④性能と制御の違い

観点	で気をつける点	プロビジョンドで気をつける点
起動の待ち	初回の起動 (コールドスタート) で数秒から数分の待ちが出ることがあります。 Serverless の事前初期化した容量などで減らせます	常に起動しているため待ちはありません
上限	サービスごとの上限 (数、最大容量) の範囲で自動で増減します	自分で決めた容量が上限です。足りなければ手動や自動スケーリングで増やします
細かな調整	インスタンスの種類などを選べないことが多いです	インスタンスの種類、ストレージ、設定を細かく調整できます

試験対策

①判断マトリクス

問題文のキーワード	選ぶ形	理由
不定期・断続的な分析、使わない時間は払いたくない	Serverless /	使った分だけの課金です。
24 時間一定の高い負荷、コスト最小	Redshift のプロビジョンドクラスター + 予約ノード	高い使用率で単価が下がります。
のジョブを、クラスター管理なしで	Serverless /	クラスターの用意と停止が不要です。
EMR で独自のソフトやの設定が必要	EMR on	ブートストラップやインスタンスの種類を制御できます。
ストリームの流量が予測できない	のモード / Serverless	容量を自動で管理します。
パッチ適用や障害対応の運用をなくしたい		AWS が運用を引き受けます。
マネージドサービスにない独自の設定が必須	EC2 での自前運用	自由度は高いが運用負荷も高くなります。

②よくある誤答

なら常に安いと考えること。常に高い負荷では、プロビジョンドと予約の方が安くなることがあります。
「運用負荷を最小に」という条件での自前運用を選ぶこと。やサーバーレスを選びます。
サーバーレスでは性能を制御できないと考えること。 Serverless の基本容量、 Serverless の事前初期化など、調整の手段はあります。