LASSIC Media らしくメディア
Amazon Redshiftのコスト削減を外注で進める方法
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Amazon Redshiftのコスト高騰には、ノード種別の選択・ストレージ分離・同時実行設計という3つの固有の最適化軸があります
- RA3移行やRedshift Serverless化は技術的難度が高く、社内リソースが足りない場合は外注で進める方が工期短縮につながります
- 外注パートナー選定では「Redshift構成設計の実績」と「現状診断から移行までの一貫支援体制」の2点を確認することが大切です
目次
Redshiftコストが高騰する4つの主因
Amazon Redshiftのデータウェアハウスコスト最適化とは、ノード種別の見直し・ストレージとコンピュートの分離・同時実行設計の改善といった、Redshift固有の構成変更を通じてDWH運用費用を適正化する取り組みです。汎用的なクラウドリソースの棚卸しとは異なり、Redshift特有のアーキテクチャ理解が前提となります。
DC2ノードのコンピュート過剰割り当て
DC2（Dense Compute）ノードはコンピュートとローカルSSDストレージが一体化したノードタイプです。データ量が増えるとストレージを増やすためにノード数を増やす必要があり、コンピュート性能が過剰になりがちです。
クエリのピーク時間帯に合わせてノード数を設定すると、オフピーク時間はコンピュートが遊んでいる状態になります。この状態でもオンデマンド料金は発生し続けます。
未使用スナップショット・テーブルの放置
Redshiftのスナップショット（バックアップ）はマネージドストレージとは別に課金されます。テスト環境や旧バージョンのスナップショットを削除せずに放置すると、ストレージコストが積み上がります。
同様に、過去の分析結果テーブルや一時テーブルを削除せず残しておくと、マネージドストレージの使用量が増加します。定期的な棚卸しが行われていない環境では、不要なデータが数十GBから数TB単位で蓄積していることがあります。
同時実行スケーリングの超過課金
Redshiftの同時実行スケーリング（Concurrency Scaling）機能は、同時クエリが増加したときに追加クラスタを起動して処理を分散させます。AWSは1日あたり1時間分の無料クレジットを提供していますが、バッチ処理とインタラクティブクエリが重なる時間帯には無料クレジットを超過することがあります*1。
超過分は秒単位のオンデマンド料金が課金される仕組みです。ワークロードスケジューリングの設計が行き届いていないと、この超過課金が毎日発生し続けます。
ストレージとコンピュートの分離未実施
DC2ノードではストレージとコンピュートが一体のため、どちらか一方のリソースが不足してもノード全体を追加する必要があります。データが増えてもクエリ量は増えない場合にコンピュートが過剰になり、反対にクエリが増えてもストレージは不要なのに追加されます。
RA3ノードへの移行でこの問題は解消されますが、移行には設計・検証の工数が必要です。担当者が少ない環境では後回しにされがちです。
RA3移行とServerless化 — Redshift固有の最適化2軸
RA3ノードでコンピュートとマネージドストレージを分離する
RA3（Redshift Architecture 3rd generation）ノードは、コンピュートとストレージを独立して拡張できるアーキテクチャです。ストレージはAmazon S3ベースのマネージドストレージ（RMS）に格納され、コンピュートノード数と切り離してスケールできます*1。
AWS公式の料金ページでは、RMSは「プロビジョニングされたコンピュートノードの数とはかかわりなく、保存したデータに対してのみ支払い」と説明されています。米国東部リージョンではRMSの料金は0.024 USD/GB-月です*1。
DC2環境でストレージが増えるたびにノード追加が必要だった構成を、RA3に移行することでコンピュートの過剰割り当てを回避できます。移行の際にはクラスタのサイジング再設計と、アプリケーション側の接続エンドポイント切り替えが必要です。
Redshift Serverlessで使った分だけ課金するモデルへ
Redshift Serverless（Amazon Redshift Serverless）は、クラスタのプロビジョニングが不要なサーバーレス型のDWHサービスです。クエリが実行されているときだけRPU（Redshift Processing Unit）を消費し、アイドル状態では課金が止まります*1。
料金はRPU-時間あたり0.375 USDで、秒単位の課金（最低60秒）です。RPUは4〜1024の範囲でワークロードに応じて自動スケールします*1。利用頻度が低い環境や、開発・テスト環境ではServerlessへの移行でコスト削減が期待できます。
一方、24時間365日フル稼働のバッチDWHでは、プロビジョンド構成のリザーブドインスタンス（1年・3年契約）と比較してServerlessが割安とはいえないケースもあります。ワークロードの特性に応じて判断する必要があります。
同時実行スケーリング・ワークロード設計で削減できるコスト
1日1時間の無料クレジットを活用した同時実行スケーリング
同時実行スケーリングの無料クレジットは「1日あたり1時間」です*1。この無料枠を超えた場合のみ秒単位でオンデマンド料金が発生します。
バッチジョブ・ETL処理・BIダッシュボード更新が重なる時間帯を分散することで、同時実行スケーリングの発動頻度を下げることができます。ワークロード管理（WLM：Workload Management）のキュー設定を見直し、処理の優先順位とタイミングを整理するのが基本的なアプローチです。
sys_serverless_usageで使用量を可視化する
Redshift Serverlessでは`sys_serverless_usage`システムビューを使ってRPUの消費状況を時間帯別に確認できます。どの時間帯にどれだけのコンピュートが消費されているかを可視化することで、設定値の調整根拠が得られます。
プロビジョンド構成でも`stl_query`や`svl_query_summary`などのシステムテーブルでクエリごとの実行時間・スキャン量を確認できます。これらのデータを収集・集計してコスト配分を分析する作業は、Redshiftの内部構造への理解が必要な専門的な工程です。
Redshiftコスト最適化を外注すべき3つの判断基準
内製で対応困難な技術領域（RA3移行・Serverless設計）
RA3移行では、クラスタのサイジング計算・ノードタイプ変換手順・アプリケーション接続エンドポイントの切り替え・パフォーマンス検証という一連の工程が必要です。これらをトラブルなく進めるには、Redshiftの内部アーキテクチャとAWS CLIまたはコンソールの詳細操作に精通したエンジニアが少なくとも1名以上必要です。
Redshift Serverlessへの移行では、さらにWLMの再設計・RPU上限値の調整・コスト予測モデリングという作業が加わります。インフラ担当者が1〜2名の環境では、通常業務と並行して対応するのが難しいケースがあります。
外注で費用対効果が出やすい作業（棚卸し・クラスタ再設計）
スナップショットの一覧確認・不要テーブルの洗い出し・スケジュール設定の見直しは、外部ベンダーが手順化してスポット対応しやすい作業です。定型的な棚卸し作業を外注することで、社内担当者はビジネスロジックに集中できます。
外注で対応しにくいのは、「どのデータをどの期間保持するか」というデータライフサイクルポリシーの決定です。この部分はビジネス要件に直結するため、社内担当者が判断する必要があります。外注パートナーへは「判断の基準を渡す役割」が残ります。
外注失敗を防ぐパートナー選定の2要件
Redshiftコスト最適化の外注パートナーを選ぶ際に確認すべき点は2つあります。1つ目は「Redshiftの構成設計・移行の実績」です。汎用的なAWS運用の実績とRedshift DWH固有の移行実績は別物であり、後者の経験を持つベンダーかどうかを確認します。
2つ目は「現状診断から本番移行までの一貫支援体制」です。診断フェーズだけで終わるコンサルティング型と、設計・移行・アフターフォローまでを一貫して担うベンダーとでは、引き渡しコストが大きく異なります。移行後のパフォーマンス監視まで含めた継続支援が可能かどうかを契約前に確認します。
外注の進め方 — 現状診断から本番移行まで5ステップ
Redshiftコスト最適化を外注で進める際の標準的な流れを5つのステップに整理します。各ステップで社内が準備すべき情報と、外注パートナーが担う作業を明確にしておくと、プロジェクトがスムーズに進みます。
ステップ1：現状コストの可視化と主因特定（外注担当）
AWSコストエクスプローラーとRedshiftのシステムテーブルを使い、ノード種別・スナップショット・同時実行スケーリングの各コスト項目を分解します。社内担当者は現行クラスタ構成・利用部門・利用時間帯の情報を提供します。
ステップ2：最適化設計の策定（外注担当 + 社内レビュー）
RA3移行・Serverless化・WLM再設計のうち、コストインパクトと移行リスクのバランスを考慮して優先順位を決めます。社内は「許容できるダウンタイム」「データ保持期間の要件」を確認・提供します。
ステップ3：移行実施と動作検証（外注担当）
ノード変更・エンドポイント切り替え・WLM設定変更を本番に適用し、クエリパフォーマンスと課金額の変化を検証します。移行前後の比較レポートを作成し、社内担当者に引き渡します。
ステップ4：ワークロード最適化の調整（外注担当 + 社内確認）
移行後1〜2週間のワークロードデータをもとに、同時実行スケーリングの発動タイミング・RPU上限値・バッチスケジュールを微調整します。この段階で社内に操作方法を引き継ぐと、以降の自走が可能になります。
ステップ5：継続監視とレポーティング（外注 or 内製）
月次でコスト推移・クラスタ利用率・スナップショット容量を確認するレポートを整備します。継続的な監視を外注に委ねるか、内製化するかは運用体制と予算に応じて決めます。
| 最適化項目 | 対象構成 | 外注向き度 | 社内で必要な準備 |
|---|---|---|---|
| RA3移行（DC2→RA3） | プロビジョンド | 高（設計・移行工数が大きい） | クラスタ構成図、ダウンタイム許容時間 |
| Redshift Serverless化 | 低頻度・開発環境 | 中〜高（WLM再設計が必要） | 利用頻度・ピーク時間帯の情報 |
| 同時実行スケーリング設定 | プロビジョンド | 中（WLMの知識が必要） | バッチスケジュール一覧 |
| スナップショット・テーブル棚卸し | 全構成 | 中（手順化しやすい） | データ保持ポリシーの決定 |
| コスト可視化レポート整備 | 全構成 | 中（継続委託も可） | コスト配分タグ設定 |
まとめ：Redshiftコスト最適化外注の3つの判断軸
本稿では、Amazon Redshiftのデータウェアハウスコストが高騰する主因と、外注で効率的に進めるための手順を整理しました。要点を3つにまとめると次の通りです。
第一に、Redshiftのコスト高騰はDC2ノードの過剰割り当て・スナップショット放置・同時実行スケーリング超過・ストレージとコンピュートの未分離という4つの固有要因から生じます。汎用的な棚卸しだけでは対処しきれない領域があります。
第二に、RA3移行とRedshift Serverless化はRedshift固有の最適化手法です。RA3はコンピュートとマネージドストレージを分離することでスケール効率を高め、Serverlessはアイドル時の課金を止める仕組みです。どちらも設計・移行に専門知識が必要であり、社内リソースが不足している場合は外注が実務上の選択肢になります。
第三に、外注パートナーを選ぶ際は「Redshift構成設計・移行の実績」と「診断から本番移行・アフターフォローまでの一貫支援体制」を確認します。コンサルティング型と移行実施型では費用・工期・社内負担が異なるため、自社の体制に合った形態を選ぶことが大切です。
よくある質問
DC2ノードからRA3ノードへの移行はどのくらいの期間がかかりますか。
クラスタ規模と移行設計の準備状況によって異なりますが、小規模クラスタ（2〜4ノード程度）でも設計・検証・本番切り替えを含めると数週間から1〜2ヶ月程度の期間を見込むことが一般的です。特に、アプリケーション側の接続エンドポイント変更と移行後のパフォーマンス検証に工数がかかります。外注パートナーに依頼する際は、移行前の現状診断に要する時間もスケジュールに含めて確認することをおすすめします。
Redshift Serverlessはすべての用途でコスト削減できますか。
すべての用途で削減できるわけではありません。Serverlessはクエリが実行されていない時間帯の課金が止まるため、利用頻度が低い環境・開発環境・非定常なバッチ処理で費用削減が見込みやすいです。一方、24時間365日フル稼働のDWHではプロビジョンド構成のリザーブドインスタンスと比較してServerlessが割高になる場合があります。移行前にワークロードの利用パターンを分析し、どちらが自社環境に合っているかを判断することが大切です。
同時実行スケーリングの無料クレジットを超過しないようにするにはどうすればよいですか。
AWS公式情報によると、同時実行スケーリングの無料クレジットは1日あたり1時間です*1。超過を抑えるには、バッチETL・BIダッシュボード更新・アドホッククエリが集中する時間帯をずらすWLM（Workload Management）設計が役立ちます。クエリキューに優先順位と同時実行数の上限を設定し、ピーク時間帯への処理集中を分散させます。設定変更にはWLMの知識が必要なため、対応が難しい場合は外注パートナーへの依頼を検討してください。
Redshiftのコスト最適化外注にはどの程度の費用がかかりますか。
外注費用はスコープ（診断のみ・移行込み・継続監視込み）や対象クラスタの規模によって異なります。市場参考値として、現状診断から移行実施を含む一通りの対応で数十万円から数百万円程度の幅があるとされていますが、これは一次資料に基づく確定情報ではなく参考値です。正確な費用はベンダーへの見積もりで確認してください。なお、AWSサービスの料金（RA3ノード・Serverless RPU等）はAWS公式料金ページ（aws.amazon.com/jp/redshift/pricing/）で最新情報を確認することをおすすめします。
スナップショットの棚卸しは内製でも対応できますか。
手順自体はAWSコンソールまたはCLIで対応できるため、技術担当者がいれば内製でも進められます。ただし、どのスナップショットを削除してよいかの判断（データ保持ポリシー）は事前に社内で合意しておく必要があります。また、自動スナップショット設定（保持期間の見直し）は誤設定するとバックアップが失われるリスクがあります。不安な場合はAWSの操作手順の整備・確認を外注パートナーに依頼し、判断基準だけ社内で持つ形を取るとリスクを抑えられます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「Amazon Redshift 料金」（2024年確認）
