SAP HANA Cloud elastic compute nodeとは？読み取り処理を拡張する仕組み

SAP HANA Cloudのelastic compute nodeとは、プライマリインスタンスとは別に追加できる、読み取り処理専用の計算リソースです。大量の分析クエリやレポート処理を追加ノードへ振り分けることで、トランザクション処理を担うプライマリインスタンスへの負荷を抑えられます。

重要なのは、elastic compute nodeが汎用的な書き込み拡張ノードではない点です。データの変更、ロード、更新、削除などの書き込み処理を受け付けないため、導入前に対象ワークロードを読み取り中心に整理する必要があります。

01elastic compute nodeの基本

どのようなノードか

elastic compute nodeは、SAP HANA Cloudインスタンスに関連付けて使用する追加の計算ノードです。プライマリインスタンスに保存されたデータを利用し、分析や参照を中心とするクエリを処理します。データを別の業務システムへ複製するためのデータベースではなく、同じインスタンスの処理能力を読み取り用途で広げるための仕組みです。

プライマリインスタンスは、更新系トランザクション、アプリケーション接続、データ管理などの基盤になります。一方、elastic compute nodeは参照負荷を分離する役割を持ちます。この役割分担を理解すると、単純なメモリ増設や書き込み性能の改善とは異なる機能であることが分かります。

解決しやすい課題

次のような状況では、elastic compute nodeの検討価値があります。

• 営業・在庫・財務などのレポート実行時間が業務トランザクションに影響している
• 大規模な集計クエリが同じ時間帯に集中している
• 分析用の参照処理を分離したいが、データを別の仕組みへ移したくない
• 一時的または継続的に読み取り処理の容量を増やしたい

ただし、プライマリインスタンスのメモリ不足、頻繁なデータ更新、ロック競合、非効率なSQLが原因の場合は、ノード追加だけでは十分な改善になりません。まず処理時間、同時実行数、メモリ使用量、SQLの実行計画などを確認し、ボトルネックを特定します。

02読み取り専用という制約

elastic compute nodeは読み取り専用のワークロードを処理します。SELECTを中心とする分析、ダッシュボード、参照系APIなどには適していますが、INSERT、UPDATE、DELETEのような変更処理を受け付ける用途には適していません。読み取り専用という前提を外して設計すると、接続先を追加してもアプリケーションの書き込み処理は解決しません。

また、elastic compute nodeを追加しても、すべてのクエリが自動的に期待どおり分散されるとは限りません。接続方式、ワークロードの性質、ルーティング設定、アプリケーションの利用方法を合わせて確認する必要があります。読み取り処理をどの接続から送るかを設計し、書き込み処理は引き続きプライマリインスタンスへ送ります。

次の表は、代表的な処理と適性を整理したものです。

03プライマリインスタンスとの使い分け

処理の振り分け

設計の基本は、処理を「変更する処理」と「参照する処理」に分けることです。注文登録、在庫更新、マスタ変更などはプライマリインスタンスに接続します。集計レポート、傾向分析、参照中心のダッシュボードなどは、要件に応じてelastic compute nodeへのルーティングを検討します。

この分離では、アプリケーションが利用する接続先とトランザクション境界が重要です。1つの処理の中で書き込み後の最新値を直ちに読み取る必要がある場合、読み取り先を別ノードへ切り替える設計は慎重に評価します。読み取りの整合性、反映タイミング、障害時の切り替え方を事前に決めておくと、運用時の混乱を減らせます。

スケール判断

インスタンス全体の容量や通常処理の性能が不足している場合は、まずサービス計画とインスタンス容量を確認します。読み取り負荷だけが大きく、書き込み処理には余裕がある場合に、elastic compute nodeが候補になります。SAP HANA Cloudの容量設計については、SAP HANA Cloudのスケーリング方法も参照してください。

elastic compute nodeは、書き込みスループットを増やすための手段ではありません。更新処理が遅い場合は、SQL、インデックスやデータモデル、ロック、トランザクション設計、プライマリインスタンスの容量を別々に確認します。

04導入前に確認する項目

ワークロードの分類

最初に、対象クエリを読み取り系と書き込み系に分類します。レポート名だけで判断せず、実際に発行されるSQL、実行頻度、同時実行数、処理時間、返却行数を確認します。レポートの準備処理に一時テーブルへの書き込みが含まれる場合、その処理全体をelastic compute nodeへ移せるとは限りません。

次に、負荷が常時発生するのか、月末や日中など特定の時間帯だけ発生するのかを確認します。ピーク時間だけ読み取り処理が集中するなら、容量だけでなくスケジュール、キャッシュ、集計方法、クエリの実行回数を見直すことも有効です。

容量とコスト

elastic compute nodeを追加すると、追加の計算リソースに応じた料金と運用上の管理対象が発生します。必要な期間、ノード数、サイズ、ピーク時の利用量を見積もり、継続利用と一時利用を分けて評価します。SAP HANA Cloud Centralでは、対象インスタンスの構成や関連サービスを確認しながら、現在の構成と変更後の構成を比較します。

インスタンスの状態やサービス構成を確認する手順は、SAP HANA Cloud Centralの使い方で整理しています。Centralはサブアカウントの範囲でインスタンスを管理するため、対象インスタンスを取り違えないことが重要です。

接続と権限

アプリケーションがどの接続情報を使用するか、分析ツールがどの経路から接続するかを確認します。接続先を変更するだけでなく、必要な権限、TLS設定、ネットワーク経路、接続プール、タイムアウトも点検します。

SQLの実行確認やオブジェクトの参照には、SAP HANA database explorerを利用できます。SAP HANA CloudでのSQL実行やデータベース操作については、SAP HANA database explorerの使い方を参照してください。実際の環境では、業務影響のない読み取りクエリから検証します。

05クエリルーティングの考え方

ルーティングの対象を決める

ルーティング対象は、読み取り負荷が大きく、結果の鮮度要件を満たせるクエリから選びます。レポート、集計API、分析画面などを対象にし、更新処理と同じトランザクションに属する参照は慎重に扱います。

導入時は、全トラフィックを一度に切り替えるのではなく、対象アプリケーションや利用者グループを限定して検証します。応答時間、エラー率、プライマリインスタンスの負荷、elastic compute nodeの使用状況を比較し、効果を確認します。

検証時の観測点

検証では、平均応答時間だけでなく、パーセンタイルの応答時間、同時実行数、タイムアウト、接続失敗、プライマリインスタンスの書き込み性能を確認します。分析クエリが速くなっても、接続プールの設定やルーティング条件によってアプリケーション全体の待ち時間が増える場合があります。

アラートや状態確認の設計については、SAP HANA Cloudのアラート設定も役立ちます。しきい値は環境の通常値を基準にし、追加ノードの利用率だけでなく、エンドツーエンドの業務処理時間も監視します。

06運用時のトラブルシューティング

期待したクエリが移動しない場合

まず、対象クエリが本当に読み取り専用かを確認します。内部的に一時的な書き込みや変更処理を伴う場合、elastic compute nodeの対象外になることがあります。次に、接続先、ルーティング条件、認証情報、ネットワーク経路を確認します。

そのうえで、クエリ自体の性能を調査します。テーブルスキャン、過剰な結合、不要な列の取得、過大な結果セットなどが原因なら、追加ノードに移しても処理時間が十分に改善しないことがあります。クエリを小さく分解し、必要なデータだけを取得することも検討します。

書き込み性能が改善しない場合

elastic compute nodeは書き込みを受け付けないため、書き込み性能の改善を目的に追加しても期待した結果にはなりません。更新処理の待ち時間、ロック、コミット頻度、バッチサイズ、プライマリインスタンスの容量を確認します。読み取り処理と書き込み処理が同じ時間帯に競合している場合は、処理スケジュールの調整も候補です。

07まとめ

SAP HANA Cloudのelastic compute nodeは、読み取り中心のワークロードを追加の計算リソースへ分離するための機能です。大規模な分析、レポート、ダッシュボードによる参照負荷を軽減できる一方、書き込みスループットを増やす機能ではありません。

導入時は、対象クエリの性質、接続とルーティング、データの鮮度、容量と料金、監視方法をまとめて評価します。まず小さな読み取りワークロードで検証し、効果と副作用を確認してから対象範囲を広げる進め方が安全です。