SAP HANA Cloud
SAP HANA Cloud スケーリングとアップグレードの進め方
SAP HANA Cloud のスケールアップ、スケールダウン、弾性コンピュートノード、アップグレードを整理し、SAP HANA Cloud Central と SAP HANA database explorer を使った確認ポイントを解説します。
SAP HANA Cloud の処理性能を改善するときは、単純にリソースを増やすだけでなく、ワークロードの特性、利用時間帯、データ量、可用性要件を確認してから変更することが重要です。特に、書き込みを伴うトランザクション処理と、大量データを読む分析処理では、適したスケーリング方法が異なります。
本記事では、SAP HANA Cloud におけるスケールアップ、スケールダウン、弾性コンピュートノード、アップグレードの違いを整理します。インスタンスの確認や変更は SAP HANA Cloud Central で行い、データベース内部の状態確認や SQL による調査は SAP HANA database explorer で実施する、という役割分担を前提に説明します。
SAP HANA Cloudのスケーリングとは
SAP HANA Cloud のスケーリングとは、データベースインスタンスに割り当てる容量や計算リソースを、ワークロードに合わせて調整することです。判断の単位は、いわゆる製品エディションではなく、インスタンス、サービスプラン、容量です。
業務量が増えたときには、メモリや計算能力を増やすスケールアップを検討します。一方、利用量が減ったときや、環境の恒常的な余剰が判明したときには、要件を満たす範囲でスケールダウンを検討できます。変更前には、短時間のピークだけを理由にするのか、継続的な負荷増加に対応するのかを区別してください。
スケーリングの目的は、画面上のリソース使用率を下げることだけではありません。レスポンスタイム、同時実行数、バッチの完了時間、メモリ不足の兆候、ストレージの増加速度など、業務上の結果と合わせて評価する必要があります。
スケールアップを検討するタイミング
スケールアップは、現在のインスタンス容量では処理が安定しない場合に、より大きな容量や計算リソースへ変更する方法です。次のような状況が、検討のきっかけになります。
- 業務時間帯にクエリの待ち時間が継続して増加している
- 同時実行される分析処理と更新処理が互いに影響している
- バッチ処理が定められた時間内に完了しなくなった
- データ量の増加により、メモリやストレージの余裕が小さくなった
- 一時的な負荷ではなく、月次や日次の処理量そのものが増えている
ただし、性能問題のすべてが容量不足で起きるとは限りません。非効率な SQL、過剰なデータ転送、不要な列の取得、適切でないデータモデル、同時実行制御の問題などが原因であれば、容量変更だけでは十分な改善にならないことがあります。変更前に SAP HANA database explorer の SQL コンソールやモニタリング情報で、遅い処理と負荷の時間帯を切り分けます。
SAP HANA Cloud の状態やインスタンス構成を確認する入口としては、SAP HANA Cloud Centralの使い方も参照できます。インスタンスのスコープはサブアカウントを基準に確認し、対象を取り違えないようにします。
スケールダウンの判断
スケールダウンは、余剰リソースを減らしてコストと運用上の無駄を抑える選択肢です。ただし、平均値だけで判断すると、月末処理や朝一番の利用集中など、短いピークを見落とす可能性があります。
判断時には、少なくとも通常時、繁忙時、バッチ実行時の負荷を分けて確認します。次の観点を記録しておくと、変更後の比較が容易になります。
- 主要画面や API の応答時間
- 重要な SQL の実行時間と待機状況
- バッチの開始時刻、終了時刻、失敗件数
- メモリ使用量とストレージ消費量の推移
- 同時接続数と、利用が集中する時間帯
スケールダウン後は、直後の状態だけでなく、通常の業務サイクルを一周するまで観測します。特に月次締め、在庫集計、請求処理など、普段と異なる負荷を含めて評価することが大切です。問題が再現した場合にすぐ戻せるよう、変更前の容量、実施時刻、承認者、検証結果を変更記録に残します。
弾性コンピュートノードの使いどころ
弾性コンピュートノードは、読み取り負荷の分散を目的とする構成です。レポート、分析、参照系 API など、データベースに対して大量の読み取りを行う処理を切り離す場面で検討できます。
重要なのは、弾性コンピュートノードが書き込みスループットを増やすための仕組みではないという点です。更新、登録、削除、トランザクションのコミットを受け付ける書き込み先として扱うことはできません。書き込み処理の増加が課題なら、トランザクション設計、SQL、データモデル、同時実行、またはインスタンスの容量を別に評価します。
弾性コンピュートノードを検討する際は、対象処理が本当に読み取り中心か、許容できるデータ鮮度か、接続先を適切に分けられるかを確認します。単にノードを追加するのではなく、業務処理と分析処理の接続設計まで含めてテストしてください。
読み取り処理を分離する考え方や制約は、SAP HANA Cloud elastic compute nodeの概要で補足しています。対象記事の説明と実際のサービス設定を照合し、読み取り専用という前提を崩さないことが重要です。
スケーリング変更の基本手順
実際の変更は、次のような順序で進めると安全です。
- 現状を記録する：対象インスタンス、サブアカウント、サービスプラン、容量、負荷の時間帯、性能指標を記録します。
- 目的を定義する：応答時間の改善、バッチ時間の短縮、読み取り分散、またはコスト最適化のどれが目的かを明確にします。
- 原因を切り分ける：容量不足なのか、SQL やデータモデルなのか、接続や同時実行なのかを確認します。
- 変更計画を作る：実施時間、影響、検証項目、連絡先、問題時の戻し方を決めます。
- SAP HANA Cloud Centralで変更する：対象インスタンスを選び、利用可能なサービスプランや容量の範囲を確認して変更します。
- 動作を検証する：代表的な画面、API、SQL、バッチを実行し、変更前の指標と比較します。
- 一定期間観測する：変更直後だけでなく、通常の業務ピークを含めて結果を確認します。
変更の前後で、アプリケーション接続、ジョブ、監視通知が想定どおり動くかも確認します。インスタンスの開始・停止や運用時間帯を見直す場合は、SAP HANA Cloudの開始と停止も関連します。ただし、停止によるコスト抑制が業務スケーリングの代替になるとは限らないため、利用パターンに基づいて判断してください。
モニタリングと変更後の検証
スケーリングの成否は、変更操作が完了したかではなく、業務性能が改善したかで判断します。SAP HANA Cloud Central ではインスタンスの状態や構成を確認し、SAP HANA database explorer ではデータベース接続、SQL の実行状況、必要な管理情報を確認します。
監視では、単一の使用率に依存しないことが重要です。たとえばメモリ使用率が低くても、特定の SQL が長時間待機していれば利用者の体感性能は改善しません。反対に、使用率が高くても、応答時間とバッチ時間が安定している場合があります。
アラートを設計するときは、警告と重大な異常を分け、通知先と対応者を明確にします。しきい値は環境の通常値を基準に調整し、通知が多すぎて重要な異常を見逃さないようにします。具体的な通知設計は、SAP HANA Cloudのアラート設定も確認してください。
アップグレードとスケーリングの違い
スケーリングは主に容量や計算リソースをワークロードに合わせる変更です。一方、アップグレードは、データベースサービスのソフトウェアバージョンや提供される機能、修正を適用するためのライフサイクル管理です。両者は目的が異なるため、性能問題が起きたときに、すぐアップグレードだけで解決しようとしないでください。
アップグレードを計画するときは、対象インスタンス、実施時期、アプリケーション互換性、接続方式、SQL やドライバーの動作、検証環境での結果を確認します。業務停止や接続影響の有無、通知方法、失敗時の連絡手順も、サービスの案内と自社の変更管理に基づいて整理します。
また、アップグレードと容量変更を同じタイミングで行うと、問題発生時に原因を特定しにくくなります。可能なら変更を分離し、先に検証可能な範囲で一つの要因を変えます。やむを得ず同時に実施する場合は、事前の性能ベースラインと検証項目をより細かく設定します。
スケーリング計画のチェックリスト
実施前には、次の項目を確認します。
- 対象インスタンスとサブアカウントが正しい
- 変更目的と成功条件が数値または観測可能な形で定義されている
- 書き込み負荷と読み取り負荷が区別されている
- 容量不足以外の原因を確認している
- サービスプランと容量の変更範囲を確認している
- アプリケーション、ジョブ、接続設定の影響を確認している
- 実施時間、関係者、検証手順、連絡経路が決まっている
- 変更後の監視期間と、必要な場合の戻し方が決まっている
このチェックリストを変更申請や運用手順書に組み込むと、担当者が変わっても判断基準をそろえやすくなります。特に、弾性コンピュートノードを使う場合は、読み取り専用の用途であることを設計書に明記しておくと、後から書き込み処理を誤って接続するリスクを抑えられます。
まとめ
SAP HANA Cloud の性能改善では、まずワークロードを観測し、容量変更で解決できる問題かを切り分けます。継続的な負荷増加にはスケールアップ、余剰が確認できる場合にはスケールダウン、大量の読み取りを分離したい場合には弾性コンピュートノードを検討します。
アップグレードはスケーリングとは別のライフサイクル作業です。変更目的、影響、検証方法を分けて管理し、SAP HANA Cloud Central と SAP HANA database explorer を使い分けながら、業務結果を基準に判断してください。