HANA Cloud: アーキテクチャと用途

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 11, 2026 · 22 min read

本記事の位置づけ#

参考資料#

1) データと分析のランドスケープ#

L2-C ドメインは、SAP BTP 内でデータを保存、移動、モデル化、可視化するサービスをカバーしています。各コンポーネントは異なる役割を果たし、互いに補完するように設計されています。出典: SAP HANA Cloud の機能。

これらは代替品ではありません。HANA Cloudは永続化層および計算層であり、他のものはそれに依存し、その隣に位置し、またはそこからデータを消費します。

2) S/4HANA への接続方法#

どのようなデプロイメントモデル（パブリッククラウドエディション、プライベートクラウドエディション、またはオンプレミス）であっても、SAP S/4HANAは、BTPでホストされるサービスが消費するトランザクションデータを生成します。この統合の中心には、SAP HANA Cloudが位置しています。

┌─────────────────────────────────────────────────────────────────┐
│                        SAP BTP Subaccount                        │
│                                                                   │
│  ┌────────────┐    BTP Service     ┌──────────────────────────┐  │
│  │  CAP App   │◄──── Binding ─────►│   SAP HANA Cloud         │  │
│  │ (Node/Java)│   (VCAP_SERVICES)  │   - Relational Store     │  │
│  └─────┬──────┘                    │   - Document Store       │  │
│        │                           │   - Graph Engine         │  │
│        │ OData / REST              │   - Vector Engine        │  │
│        ▼                           │   - Spatial Engine       │  │
│  ┌─────────────┐                   └───────────┬──────────────┘  │
│  │  SAP BTP    │                               │                  │
│  │  Cockpit /  │                    HDI        │  Data Lake IQ    │
│  │  HANA Cloud │◄──── Admin ───────►Containers │  (petabyte-scale │
│  │  Central    │                               │   analytics)     │
│  └─────────────┘                   ┌───────────▼──────────────┐  │
│                                    │   SAP Data Lake Files     │  │
│                                    │   (Azure/AWS/GCP object   │  │
│                                    │    storage, SAP-managed)  │  │
│                                    └──────────────────────────┘  │
└─────────────┬───────────────────────────────────────────────────┘
              │
     Replication / Virtualization
              │
┌─────────────▼───────────────────────────────────────────────────┐
│  SAP S/4HANA (on-premise / PCE / Public Cloud)                   │
│  SAP ECC / non-SAP sources                                       │
└─────────────────────────────────────────────────────────────────┘

SAPおよび非SAPのソースシステムからHANA Cloudへのデータフローは、レプリケーション（SLT、SDI）および仮想化サービス（ SAP HANA Cloud スタートガイド）を通じて行われます。SAP Cloud Application Programming Model（CAP）で構築されたアプリケーションは、BTPサービスバインディング（VCAP_SERVICES）を介して実行時にデータベース認証情報を自動的に取得するため、手動による認証情報管理が不要になります。HDIコンテナは、同一のHANA Cloudインスタンス内でテナント単位のスキーマ分離を提供します。

重要ポイント: HANA Cloudは孤立したデータベースではありません。これは、BTPアプリケーションおよび分析エコシステム全体のデータ永続化ハブであり、そのプロビジョニングの決定（リージョン、サイズ、マルチテナンシーモデル）は、すべての下流サービスに影響を及ぼします。

3) 成熟度マップ#

4) 要件チェックリスト#

テナントおよび契約の前提条件#

データ統合とソースシステムの準備#

アプリケーションとHDIコンテナのガバナンス#

セキュリティとコンプライアンス#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. このソリューションは、どのような測定可能な非効率性やパフォーマンスのボトルネックを解決しますか？

数値で課題を定義する：クエリレイテンシ（現状 vs. 目標）、レポート遅延（バッチウィンドウ vs. リアルタイム要件）、またはデータサイロの数。回答が「データプラットフォームをモダナイズしたい」というだけで具体的な指標がない場合、プロジェクトのスコープは進行可能な状態ではありません。HANA Cloudのインメモリアーキテクチャは、OLTPとOLAPシステムを分離する必要性を排除しますが、このメリットは両方のワークロードが定量化された場合にのみ実現されます。#

Q2. 現在データはどこに存在し、データの保存場所に関する決定権は誰が持っていますか？

HANA Cloudのリージョン選択は、初期プロビジョニング後は実質的に元に戻せません。別のリージョンに移行するには、設定変更ではなく、完全なデータコピーが必要です（ SAP HANA Cloud スタートガイド）。サブアカウントとインスタンスを作成する前に、法務およびコンプライアンス部門からのデータ保存に関する承認を取得しておく必要があります。EUのデータ保存要件については、該当するリージョンオプションを確認し、クラウドインフラプロバイダー（Azure、SAP Cloud Infrastructure、AWS、またはGoogle Cloud）が該当基準を満たしていることを検証してください。

Q3. 予算権限を持つ社内スポンサーと、確定した稼働開始日はありますか？

HANA Cloudのクレジットベースの料金体系では、インスタンスが稼働した瞬間から継続的にコストが発生します（ SAPチュートリアル — HANA Cloud vs. オンプレミス）。コスト承認を得ずにプロビジョニングを開始したプロジェクトは、開発途中で強制的な規模縮小やインスタンス削除に直面し、環境の状態を失い、再セットアップのコストが発生します。本番環境または本番に近いサブアカウントでインスタンスをプロビジョニングする前に、必ず予算責任者の承認を得てください。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害 1: インスタンスの早期プロビジョニングによるリージョンロックイン

データレジデンシーの承認前にサブアカウントとHANA Cloudインスタンスがプロビジョニングされると、高コストな移行かコンプライアンス違反かの選択を迫られます。プロビジョニング後に別のリージョンへ移行するには、全データのコピーが必要です。インスタンス作成前にリージョン確認を正式なゲートとして設定してください。

障害 2: HANA Cloud をオンプレミス HANA のドロップイン代替として扱うこと

HANA CloudはオンプレミスのHANAと共通のSQLコードベースを共有していますが（ SAPチュートリアル）、運用モデルは根本的に異なります。OSレベルのアクセス、手動バックアップ設定、カスタムカーネルパラメータのチューニングは利用できません。これらの機能がクラウド版にも存在すると想定したプロジェクトは、設計変更に多大なコストがかかる段階になって初めてその制限に気づくことになります。

障害 3: ガバナンスのないHDIコンテナの乱立

マルチチームプロジェクトでは、命名規則や所有権モデルがない場合、HDIコンテナが増殖します。各コンテナは専用のスキーマ所有者を持つDTC/RTCペアです。無秩序な増殖により、どこに何がデプロイされているかの追跡が不可能になり、アップグレードの順序付けが複雑化します。プロジェクト開始時にHDIコンテナのガバナンスモデルを確立してください。

障害 4: 非機能要件からコネクションプールサイジングが省略されている

CAP for Java はデフォルトで最大10接続のHikariCPプールを使用します。本番環境で数百の同時セッションが発生すると、接続枯渇と連鎖的なタイムアウトを引き起こします。プールサイジング（サービスごと、想定される同時負荷ごと）は要件チェックリストに含め、本番カットオーバー前の負荷テストで検証する必要があります（ コネクションプールサイジングの洞察）。

障害 5: プロビジョニング後までデータガバナンスと分類が遅延する

データの機密レベルが統合パイプラインの構築前に定義されていない場合、プロジェクトの途中で特定のデータセットを選択したリージョンに配置できない、または顧客管理の暗号化キーが必要であることが判明します。そのたびにアーキテクチャの再作業が必要になります。データ分類はビジネス上の責任です — 設計を開始する前に、責任者を割り当ててください。

障害6: 混合OLTP/OLAP向けに設計されていないワークロード分離

ワークロードクラスの定義がない場合、長時間実行される分析クエリが利用可能なすべてのスレッドを消費し、トランザクション処理を停滞させる可能性があります。ワークロードクラスを設定せずに混合ワークロードを展開するプロジェクトでは、本番環境で予測不能なレイテンシの急上昇が発生します。ワークロードクラスの設計は要件フェーズに含めるべきです。

障害 7: 開発インスタンスでコストが発生している間に予算承認が延期される

HANA Cloud クレジットはインスタンスの起動時間から発生します。停止/起動の自動化を行わずに開発環境を稼働させ続けると、計画外のコストが発生します。非本番インスタンスの停止/起動ポリシーを確認し、プロビジョニング前に継続稼働コストが明示的に承認されていることを確認してください。

FAQ#

Q: SAP HANA Cloud は、S/4HANA オンプレミス拡張プロジェクトで使用できますか、それともクラウドデプロイメントにのみ適用されますか？

HANA Cloudは、導入モデル（パブリッククラウドエディション、プライベートクラウドエディション、オンプレミス）に関わらず、S/4HANA拡張シナリオに適しています。BTP上でCAPを使用して構築された拡張機能は、Cloud ConnectorとSAP HANAスマートデータ統合を介して、オンプレミスのS/4HANAシステムからデータをフェデレーションまたはレプリケーションできます。重要な前提条件は、BTPサブアカウントとオンプレミス環境間のネットワーク接続であり、プロジェクト設計を確定する前にセキュリティチームの承認が必要です。

Q: HANA CloudのライセンスはオンプレミスのHANAとどのように異なり、CFOに何を伝えるべきですか？

オンプレミスのHANAは、従来型の初期ライセンス購入と年間保守契約を採用し、顧客がすべてのインフラを所有します。一方、HANA Cloudはクレジットベースの従量課金モデルを採用しており、初期ライセンス購入は不要ですが、実行中のインスタンスサイズに応じて継続的にクレジットが消費されます。財務部門にとっての実務的なポイントは、多額の初期設備投資は不要である一方、運用コストは永続的に発生し、インスタンスサイズと稼働時間に連動する点です。業務時間外に非本番インスタンスを停止することでコストを削減でき、適切なサイジングがオンプレミス以上に重要となります。

Q: プロジェクトからHANA Cloudをスコープ外とし、別の永続化オプションを使用すべきなのはどのような場合ですか？

ワークロードが純粋なオブジェクトストレージ（非構造化ファイルのみ、SQLクエリなし）である場合、予算が継続的なクレジット消費をサポートできない場合、またはユースケースがターゲットクラウドプロバイダーの標準データベースで完全にカバーできる場合は、HANA Cloudの導入を見送ってください。HANA Cloudの価値は、トランザクション、分析、マルチモデルデータを単一システムで組み合わせるワークロードにおいて最も高まります。プロジェクトがトランザクション要件がなくペタバイト規模の純粋な分析である場合は、SAP HANA Cloud Data Lake単体で十分かつより費用対効果が高いかどうかを評価してください。

Q: ソリューション提案やブループリントにおいて、HANA Cloudの要件を適切に文書化するにはどうすればよいですか？

要件書には以下を明記する必要があります：(1) ワークロードタイプ（OLTP、OLAP、または混合）、(2) 稼働開始時および12か月後の予想データ量、(3) 同時実行プロファイル（ピーク時の同時ユーザー数とクエリタイプ）、(4) データ保存場所と暗号化要件、(5) 必要なHA/DRレベル（バックアップのみかシステムレプリケーションか）、(6) マルチテナンシーモデル（シングルテナントか、スキーマ分離を伴うネイティブマルチテナントか）。これら6つのパラメータは、技術的な適合性とコストの両方を決定するサイジング、リージョン、および構成の判断に直接対応します。

Q: SAP HANA Cloud は SAP S/4HANA Cloud と同じですか？

いいえ。SAP HANA CloudはSAP BTP内のデータベースおよびデータプラットフォームサービスです。SAP S/4HANA CloudはERPアプリケーション（SAP ECCの後継）であり、SAP HANAデータベース上で動作します。両者は関連しています — S/4HANA Cloudは内部でHANAを使用しています — しかし、ライセンス、管理、統合ポイントが異なる別製品です。BTPの文脈では、「HANA Cloud」はERPではなく、スタンドアロンのデータベースサービスを指します。

Q: HANA Cloudではどのような管理ツールが利用可能ですか？また、別途トレーニングは必要ですか？

HANA Cloudは、SAP HANA Cloud Central（Analytics CloudやData Lakeと共有されるインスタンスレベルの管理）、SAP HANA Cockpit（データベースレベルの監視と管理）、SAP HANA Database Explorer（SQLクエリの実行とカタログの検査）の3層のツールを使用します。CockpitとDatabase Explorerの機能は、徐々にHANA Cloud Centralに統合されています（ 管理ツール）。オンプレミスのHANA Cockpitに精通した管理者であれば、クラウド版の同等ツールも認識できるでしょう。主な学習曲線は、BTPレベルのアクセス管理（ロールコレクション、サブアカウント構造）です。

概要#

SAP HANA Cloudは、SAP BTPのデータ＆アナリティクス領域における永続化とコンピューティングの基盤です。そのインメモリカラムストアエンジン、マルチモデル対応（リレーショナル、グラフ、空間、JSON、ベクトル）、ネイティブマルチテナンシー、およびSAP管理のHA/DRにより、幅広いワークロードに対応可能な本番環境対応製品となっています。オンプレミスのHANAからHANA Cloudへの移行は、主に運用面での変化です。SAPがインフラ、バックアップ、パッチ適用を管理する一方、顧客の責任範囲はサイジング、データガバナンス、HDIコンテナライフサイクル、コネクションプール管理へと移行します。最も一般的なプロジェクトの失敗は要件定義段階で発生します。これは、リージョン、データレジデンシー、ワークロードクラスの決定が先送りにされた場合です。HANA Cloudのプロビジョニングに関する決定は、設定の詳細ではなく、アーキテクチャ上のコミットメントとして扱ってください。

次に読むべきもの#