SAP HANAサイジング完全ガイド：必要メモリの計算とSAP Quick Sizerの使い方

SAP HANAのサイジングでは、業務データの量だけでなく、インメモリ処理に必要な領域、サービスのオーバーヘッド、バックアップや一時処理の余裕、将来のデータ増加をまとめて評価します。導入時の構成を決めるだけでなく、稼働後に実測値と計画値を比較することも重要です。

01SAP HANAサイジングの基本

SAP HANAオンプレミスは、データを主にメインメモリ上で処理します。そのため、必要メモリはデータベースの論理サイズと同じではありません。圧縮後のカラムストアサイズ、行ストア、システムサービス、SQL実行時の一時領域、バックアップや運用作業に必要な余裕を考慮します。

初期計画では、次の情報を整理します。

• 対象となるSAP S/4HANAやSAP ERPのリリースと利用機能
• 移行または新規導入するテーブルのレコード数とデータ増加率
• 日次・月次の処理量、同時実行ユーザー数、ピーク時間帯
• バッチ処理、集計、データロード、バックアップの実行時間
• 高可用性、バックアップ、障害復旧に関する運用要件
• システムの稼働期間と将来のデータ保持方針

サイジング結果は、CPU、メモリ、ディスク、ネットワークの組み合わせとして確認します。メモリだけを大きくしても、CPU処理能力やストレージのI/O性能が不足すると、期待した応答時間を得られません。

02SAP Quick Sizerで必要リソースを見積もる

SAPの標準的な見積もりでは、SAP Quick Sizerを使用します。対象製品、業務領域、ユーザー数、ドキュメント数、処理量などの入力値を整理し、必要なハードウェアリソースの目安を作成します。

SAP Quick Sizerを使うときは、入力値の根拠を記録します。たとえば、ユーザー数だけを現在の人数で入力すると、将来の増員やピーク時の同時利用を評価できません。年間の伝票数、明細数、データ保持年数、月末処理の集中度など、業務側で確認できる数値を利用します。

見積もり結果は最終構成そのものではなく、検証を始めるための基準です。次の段階で、既存システムの実測値、対象テーブルのデータ量、PoCや負荷試験の結果を組み合わせます。詳細な導入手順や前提条件は、SAP HANAインストールガイドとあわせて確認できます。

03メモリ容量を計算する要素

SAP HANAに必要なメモリは、主に次の要素で構成されます。

1. データ領域：カラムストアと行ストアのデータを保持する領域
2. システム領域：各サービス、メタデータ、内部管理処理が使用する領域
3. 作業領域：SQL実行、ソート、ハッシュ結合、集計、データロードなどの一時領域
4. 運用上の余裕：再編成、デルタマージ、バックアップ、増加分に対応する余裕
5. 高可用性の考慮：障害時や再起動時にも運用を継続できる構成上の余裕

カラムストアでは、データ型、NULLの割合、値の分布、圧縮方式によって実際のメモリ使用量が変わります。レコード件数だけから正確な容量を導くことはできないため、代表的なデータを使った測定や、稼働中の類似テーブルの実績を参照します。

ストレージ容量もメモリとは別に見積もります。データボリューム、ログボリューム、バックアップ保存先を分けて考え、バックアップ世代、ログバックアップの頻度、保持期間、障害時の一時領域を含めます。ハードウェア要件の確認には、SAP HANAハードウェア要件も参照してください。

04稼働中のメモリ使用量を確認する

既存のSAP HANAシステムでは、サイジング値と実測値を比較します。ホスト全体のメモリ状況は、SAP HANA database explorerやSAP HANA cockpitから確認できます。SQLで確認する場合、ホストリソースの情報は SYS.M_HOST_RESOURCE_UTILIZATION にあります。

SELECT HOST,
       USED_PHYSICAL_MEMORY,
       FREE_PHYSICAL_MEMORY,
       ALLOCATION_LIMIT,
       INSTANCE_TOTAL_MEMORY_USED_SIZE,
       INSTANCE_TOTAL_MEMORY_ALLOCATED_SIZE
FROM SYS.M_HOST_RESOURCE_UTILIZATION;

サービス単位の使用状況は SYS.M_SERVICE_MEMORY で確認し、使用メモリには TOTAL_MEMORY_USED_SIZE を使用します。ホスト全体の物理メモリ、SAP HANAが割り当て可能な上限、サービスが使用するメモリを分けて見ることで、OSや他プロセスによる消費とデータベース内部の消費を区別できます。

カラムストアのテーブル別使用量は M_CS_TABLES で確認できます。MEMORY_SIZE_IN_TOTAL と RECORD_COUNT を組み合わせると、テーブルのメモリ使用量とレコード件数を比較できます。

SELECT TABLE_NAME,
       MEMORY_SIZE_IN_TOTAL,
       RECORD_COUNT
FROM M_CS_TABLES
ORDER BY MEMORY_SIZE_IN_TOTAL DESC;

メモリ監視の考え方や日常運用の確認項目は、SAP HANAメモリ使用量の確認方法で補足しています。単一時点の値ではなく、通常日、月末、年末、データロード後など複数の期間を比較してください。

05将来拡張をサイジングに含める

導入直後のデータ量だけで構成を決めると、業務拡大やデータ保持期間の延長によって早期に上限へ到達する可能性があります。少なくとも次の増加要因を計画に含めます。

• 年間の伝票・明細・ログデータの増加
• 利用ユーザー、バッチ、インターフェースの増加
• 履歴データの保持期間延長
• 新しい業務機能や追加会社コードの導入
• 月末・決算期に集中する処理量の増加

増加率は一律の数値で置かず、業務部門から得た計画値と過去実績を分けて記録します。計画値が不確かな場合は、複数のシナリオを作り、標準、成長、最大負荷の各ケースでメモリとストレージを比較します。

06サイジング結果を検証する

サイジング後は、設計レビュー、代表データによる測定、負荷試験、運用手順の確認を順に行います。負荷試験では平均応答時間だけでなく、ピーク時の同時実行数、SQLの待機、メモリ消費、ログ生成量、バックアップ時間を記録します。

検証では、次の判定基準を事前に決めておくと、構成変更の判断が容易になります。

• 通常時とピーク時の応答時間が業務要件を満たす
• メモリの使用量と割り当て上限に十分な余裕がある
• データロード、デルタマージ、バックアップが予定時間内に完了する
• データ量の増加を監視できる
• 障害復旧とバックアップリストアを実行できる

運用開始後は、SAP HANA cockpitの監視機能とSAP HANA database explorerを利用して、計画値との差を定期的に確認します。サイジングは一度作成して終了する資料ではなく、実測値を反映して更新する運用設計の一部です。

07まとめ

SAP HANAサイジングでは、SAP Quick Sizerによる初期見積もりに、データ量、圧縮後のメモリ、サービス領域、ピーク処理、バックアップ、将来増加の評価を重ねます。導入前には代表データと負荷試験で検証し、稼働後には SYS.M_HOST_RESOURCE_UTILIZATION、SYS.M_SERVICE_MEMORY、M_CS_TABLES の情報を使って実測値を継続的に確認します。

構成を検討する際は、ハードウェア要件、導入手順、監視方法を別々に扱わず、ひとつの運用計画として整理してください。これにより、初期容量の不足だけでなく、ピーク処理や将来のデータ増加による性能問題も早期に発見できます。