- SAP Managed Tags:
本ブログでは、SAP HANA Cloud (以下、HANA Cloud)環境でDBアプリケーションをデプロイする方法について解説いたします。
対象者は「SAP HANA Cloudの基本的な操作を理解している方」になります。
※ SAP HANA Cloudに関しての基本的な操作やDBアプリケーションの作成方法については下記のブログを参考にしていただけたらと思います。
・はじめてのSAP HANA Cloud (Part 1 - Part 5)
・Free Trialではじめる、SAP HANA Cloud
※ 今回の環境はFree TrialのSAP HANA Cloud環境を利用しています。
※ SAP HANA Cloud の Free Trial 環境を 2020年7月12日以前に登録/有効化された方はこちらをご確認ください。
ここで言う、DBアプリケーションとは、HANAのテーブル作成するための定義ファイルやHANA Viewの定義ファイルの事を指します。具体的には前述の「はじめての…」シリーズの Part 4 と Part 5 で作成したテーブル作成の定義ファイルやHANA Viewの定義ファイルになります。
従来、DBでオブジェクト作成する方法と言えば、****.sql ファイル (一般的にSQLファイルと呼ばれる) を作成して、ファイル中に「CREATE TABLE」文や「CREATE VIEW」文などのSQL文を記述し、DBのターミナル画面、もしくは開発ツールからそのSQLファイルを呼び出して実行する方法が一般的かと思います。
SAP HANA Cloud (SAP HANAを含む)では、それらの定義ファイルを利用して、開発環境/テスト環境/商用環境に容易にデプロイすることが可能です。
「はじめてのSAP HANA Cloud」シリーズで出てきていたキーワード「HDI」ですが、「SAP HANA Deployment Infrastructure 」の略になります。
HDI は「HANAにDBオブジェクトやDBアプリケーションをデプロイするための便利な仕組み」です。
本来のHDIの目的やHDIの良さを理解するためには、マイクロサービス、Cloud Foundry、Multi-Target Application などのテクノロジーや考え方を理解する必要があるのですが、そこから入ると、ほとんどのDBエンジニアが挫折する可能性があります。
なので、(私の経験から) HDIについては、「まずは操作を理解しながら、仕組みについても少しずつ理解する」形でお伝えしたいと思います。
DBエンジニア、もしくは、SAP HANAエンジニアの方は、とりあえず、「HANA View やSDI (Smart Data Integration) のフローグラフ (ETLツールでデータ加工の流れを作成するもの) などの、HANA のステキな機能を活用する際にはHDIは必要な仕組み」と憶えておいてください。
このHDIの仕組みを利用してDBアプリケーションをデプロイすると、「HDIサービスインスタンス」がそのファイルの内容を解釈して、HANAインスタンス内に「HDIコンテナー」と呼ばれる領域 を作成し、その領域に対してオブジェクト作成してくれます (正確にはもっと複雑な仕組みで実行されるのですが簡略化して説明しています)。
この「HDIコンテナー」は論理的な領域で、誤解を恐れずに例えると「フレームワーク」のようなものです。
具体的には、HDIコンテナー内にはDBオブジェクト以外にも複数のDBユーザーが作成されたり、管理情報を格納するためのテーブル群やプロシージャなどが作成されます。
ただし、利用者/開発者としては、まずはDBオブジェクトだけを意識していれば大丈夫です。
このHDIコンテナーは1つのHANAインスタンス内に複数保持することも可能で、HDIコンテナーは通常のDBスキーマ(テーブル等を保持する論理的なグループ)と同様にDB内での独立性を維持/提供しています。
繰り返しになりますが、このHDIは従来のDBの設計/開発/運用に慣れている方にとっては、なかなか取っつきにくい思想と設定方法があるため、当初は戸惑いもあるかと思います。
焦らず、一つずつ慣れていきましょう。そのうち、便利なことを発見できて、スルメのような味わいとなっていきます。
操作を始める前に「はじめてのSAP HANA Cloud」 のPart 3 で出てきたヤムルファイル(mta.yaml)を確認して、ボンヤリと名前と役割を記憶しておきましょう。
いよいよ、デプロイです。操作は下記の流れになります。
1. MTAR ファイルの作成 (Build)
2. MTAR ファイルのデプロイ
まず、大事なポイントは「プロジェクトを選択する」ことです。
例では「order-entry」プロジェクトを選択し、右クリックで「Build」 > 「Build」します。
すると、「MTARファイル」が作成されます。「Multi-Target Application Archive ファイル」のことで、プロジェクト内のDBアプリケーションの定義ファイルだけでなく、デプロイするための設定情報なども含まれます。前出のヤムルファイルも含まれます。
次にこの「MTAR ファイル」をデプロイします。
作成されたMTARファイルを選択し、右クリックで「Deploy」 > 「Deploy to SAP Cloud Platform」を選択します。
すると、デプロイ先の情報が聞かれるので、SAP HANA Cloud のインスタンスが配置されているスペースであることを確認して「Deploy」ボタンをクリックします。
※ デプロイ先について忘れてしまった方はWeb IDEの設定(こちら、もしくはこちら) を見て思い出しましょう。
デプロイが完了したら、Database Explorer でオブジェクトの確認を行います。
Database ExplorerでDBの接続先を追加します。
接続先のDatabase Typeは「HDI Container 」を選択し、ヤムルファイルに記載のあるHDIコンテナー名である、「order-entry-hdidb」を選択します。
DBオブジェクトを選択すると、無事、テーブルやHANA Viewが作成され、そのスキーマが「ORDER_ENTRY_HDI」であることが確認できると思います。
無事、DBアプリケーションもデプロイされたので、少しDB内部に作成されたDBユーザーや「HDIサービスインスタンス」についても確認していきましょう。
DB管理者用ツールのSAP HANA Cockpitで「Security and User Management」のメニューで、「User Management」を選択します。
DBユーザーの検索画面で「ORDER_ENTRY_HDI」をキーワードに検索すると、「ORDER_ENTRY_HDI」から始まる幾つかのDBユーザーが検索されます。これがHDIコンテナー内の内部的なDBユーザーになります。これらの内部的に作成されるDBユーザーは総称して「テクニカルユーザー」と呼ばれます。
次に「HDIサービスインスタンス」の確認を行います。
SAP Cloud Platform の管理者用ツールのSAP Cloud Platform Cockpit で「dev」スペースを選択し、右メニューの「Service Instances」を選択すると幾つかのサービスが表示されます。
ここでヤムルファイルに記載のあるHDIサービスインタンス名と同じ名前の「order-entry-hdidb」サービスを確認後、クリックします。
すると、host名やport番号などのDB接続情報が記載されていることが確認できます。このhost名はSAP HANA Cockpitのトップページに表示されているhost名と同じであることが確認できます。
今回の例では、1つのスペース内に1つのHANAインスタンスしかないため、自動的にDBが選択されましたが、同一スペース内に複数のHANAインスタンスが存在する場合は、デプロイ先のDBをヤムルファイルに指定する必要があります。
下記の図の通り、「database_id : 'XXXXXXXXXXXXX'」のようにdatabase id を指定します。このdatabase_idはSAP HANA Cockpitのトップページから確認します。
Host名の先頭部分がdatabase_idになります。
「はじめてのHANA Cloud」シリーズのPart 3,4,5にてDBアプリケーションを作成し、Buildしていたかと思います。
その操作と今回の操作での違いを最後に解説します。
開発フェーズにて、DBオブジェクトを1つずつ定義し、オブジェクト作成が成功するかどうか、また、その結果が正しいかどうかを確認しながら開発を進めると思います。
その作業は各オブジェクトのファイルを選択して、Buildする方式でした。
この方法でBuildすると、裏では自動的にHDIコンテナーが作成されたり(最初のBuild時に)、そのHDIコンテナー内にDBオブジェクトが作成されます。
ただし、この時のHDIコンテナー名は例で言うと「order-entry-order-entry-hdidb-XXXXXXXXXXXXXX」のように、プロジェクト名と(ヤムルファイル内で指定した) HDIコンテナー名を組み合わせて、さらに任意の文字列が付加されたような長い(意味不明な) HDIコンテナー名で作成されます。
HDIサービスインスタンスの名前も同様です。
また、DBに作成されるスキーマも「ORDER_ENTRY_HDI_1」のように、(ヤムルファイルで指定した) DBスキーマ名に番号が付与された命名規則で自動作成されます。
これらはローカルの開発環境 (自分だけの開発環境) で試す分には良いのですが、テスト環境や本番環境にDBアプリケーションをデプロイする場合には、今回、ご紹介したように「プロジェクトをBuildしてMTARファイルを作成し、それをデプロイする」方法を取ることを推奨しています。
そして、ローカルの開発環境は、DBの領域もアプリケーションの実行環境もリソースを取るので、開発がひと段落したら、そのDBの領域と関連アプリケーションは削除しましょう。
具体的には下記の手順となります。
SAP Cloud Platform Cockpitにて、「dev」スペースに移動します。
まずはスペース内の「HDIコンテナーにオブジェクト作成してくれるアプリケーション」を削除します。
左メニューの「Applications」を選択し、「hdispacedeploy….」で始まるアプリケーションを削除します。
続いて、下記の手順で「HDIサービスインタンス」を削除します。
このサービスを削除すると自動的にDB内のHDIコンテナーも削除されます。すなわち、テクニカルユーザーもDBスキーマもDBスキーマ内のオブジェクトも内部的な管理情報を格納したテーブルもプロシージャも全てキレイに削除してくれます(気を付けましょう)。
勘の良い方はお気付きかと思いますが、「はじめてのSAP HANA Cloud : Part 3」、もしくは「Free Trialではじめる、SAP HANA Cloud : Vol.2」でアクセスするDBを追加する際、「Database Explorer上で表示するDB名をシンプルにするために"Name to Show in Display"では分かり易い名前を付ける」作業を行いましたが、この仕組みを理解した方は、今後は難しい名前のままの方が、むしろ、運用としては分かり易いかと思います。
いかがでしたでしょうか ?
少し難しい内容でしたが、実際に試してみると、DBアプリケーションが簡単に複数の環境にデプロイできることがお分かりいただけたと思います。
他にもファイル間の依存性チェックなど、この「Buildしてデプロイする」方法には色々とメリットがあるのですが、今回はたくさん憶えることがあったのでここまでとさせていただきます。
ありがとうございました !!
対象者は「SAP HANA Cloudの基本的な操作を理解している方」になります。
※ SAP HANA Cloudに関しての基本的な操作やDBアプリケーションの作成方法については下記のブログを参考にしていただけたらと思います。
・はじめてのSAP HANA Cloud (Part 1 - Part 5)
・Free Trialではじめる、SAP HANA Cloud
※ 今回の環境はFree TrialのSAP HANA Cloud環境を利用しています。
※ SAP HANA Cloud の Free Trial 環境を 2020年7月12日以前に登録/有効化された方はこちらをご確認ください。
DBアプリケーションのデプロイ
ここで言う、DBアプリケーションとは、HANAのテーブル作成するための定義ファイルやHANA Viewの定義ファイルの事を指します。具体的には前述の「はじめての…」シリーズの Part 4 と Part 5 で作成したテーブル作成の定義ファイルやHANA Viewの定義ファイルになります。
従来、DBでオブジェクト作成する方法と言えば、****.sql ファイル (一般的にSQLファイルと呼ばれる) を作成して、ファイル中に「CREATE TABLE」文や「CREATE VIEW」文などのSQL文を記述し、DBのターミナル画面、もしくは開発ツールからそのSQLファイルを呼び出して実行する方法が一般的かと思います。
SAP HANA Cloud (SAP HANAを含む)では、それらの定義ファイルを利用して、開発環境/テスト環境/商用環境に容易にデプロイすることが可能です。
HDIについて理解する
「はじめてのSAP HANA Cloud」シリーズで出てきていたキーワード「HDI」ですが、「SAP HANA Deployment Infrastructure 」の略になります。
HDI は「HANAにDBオブジェクトやDBアプリケーションをデプロイするための便利な仕組み」です。
本来のHDIの目的やHDIの良さを理解するためには、マイクロサービス、Cloud Foundry、Multi-Target Application などのテクノロジーや考え方を理解する必要があるのですが、そこから入ると、ほとんどのDBエンジニアが挫折する可能性があります。
なので、(私の経験から) HDIについては、「まずは操作を理解しながら、仕組みについても少しずつ理解する」形でお伝えしたいと思います。
DBエンジニア、もしくは、SAP HANAエンジニアの方は、とりあえず、「HANA View やSDI (Smart Data Integration) のフローグラフ (ETLツールでデータ加工の流れを作成するもの) などの、HANA のステキな機能を活用する際にはHDIは必要な仕組み」と憶えておいてください。
このHDIの仕組みを利用してDBアプリケーションをデプロイすると、「HDIサービスインスタンス」がそのファイルの内容を解釈して、HANAインスタンス内に「HDIコンテナー」と呼ばれる領域 を作成し、その領域に対してオブジェクト作成してくれます (正確にはもっと複雑な仕組みで実行されるのですが簡略化して説明しています)。
この「HDIコンテナー」は論理的な領域で、誤解を恐れずに例えると「フレームワーク」のようなものです。
具体的には、HDIコンテナー内にはDBオブジェクト以外にも複数のDBユーザーが作成されたり、管理情報を格納するためのテーブル群やプロシージャなどが作成されます。
ただし、利用者/開発者としては、まずはDBオブジェクトだけを意識していれば大丈夫です。
このHDIコンテナーは1つのHANAインスタンス内に複数保持することも可能で、HDIコンテナーは通常のDBスキーマ(テーブル等を保持する論理的なグループ)と同様にDB内での独立性を維持/提供しています。
繰り返しになりますが、このHDIは従来のDBの設計/開発/運用に慣れている方にとっては、なかなか取っつきにくい思想と設定方法があるため、当初は戸惑いもあるかと思います。
焦らず、一つずつ慣れていきましょう。そのうち、便利なことを発見できて、スルメのような味わいとなっていきます。
Web IDEの環境を確認する
操作を始める前に「はじめてのSAP HANA Cloud」 のPart 3 で出てきたヤムルファイル(mta.yaml)を確認して、ボンヤリと名前と役割を記憶しておきましょう。
いよいよ、デプロイです。操作は下記の流れになります。
1. MTAR ファイルの作成 (Build)
2. MTAR ファイルのデプロイ
まず、大事なポイントは「プロジェクトを選択する」ことです。
例では「order-entry」プロジェクトを選択し、右クリックで「Build」 > 「Build」します。
すると、「MTARファイル」が作成されます。「Multi-Target Application Archive ファイル」のことで、プロジェクト内のDBアプリケーションの定義ファイルだけでなく、デプロイするための設定情報なども含まれます。前出のヤムルファイルも含まれます。
次にこの「MTAR ファイル」をデプロイします。
作成されたMTARファイルを選択し、右クリックで「Deploy」 > 「Deploy to SAP Cloud Platform」を選択します。
すると、デプロイ先の情報が聞かれるので、SAP HANA Cloud のインスタンスが配置されているスペースであることを確認して「Deploy」ボタンをクリックします。
※ デプロイ先について忘れてしまった方はWeb IDEの設定(こちら、もしくはこちら) を見て思い出しましょう。
デプロイが完了したら、Database Explorer でオブジェクトの確認を行います。
Database ExplorerでDBの接続先を追加します。
接続先のDatabase Typeは「HDI Container 」を選択し、ヤムルファイルに記載のあるHDIコンテナー名である、「order-entry-hdidb」を選択します。
DBオブジェクトを選択すると、無事、テーブルやHANA Viewが作成され、そのスキーマが「ORDER_ENTRY_HDI」であることが確認できると思います。
HDIの仕組みについて少しだけ理解を深める
無事、DBアプリケーションもデプロイされたので、少しDB内部に作成されたDBユーザーや「HDIサービスインスタンス」についても確認していきましょう。
DB管理者用ツールのSAP HANA Cockpitで「Security and User Management」のメニューで、「User Management」を選択します。
DBユーザーの検索画面で「ORDER_ENTRY_HDI」をキーワードに検索すると、「ORDER_ENTRY_HDI」から始まる幾つかのDBユーザーが検索されます。これがHDIコンテナー内の内部的なDBユーザーになります。これらの内部的に作成されるDBユーザーは総称して「テクニカルユーザー」と呼ばれます。
次に「HDIサービスインスタンス」の確認を行います。
SAP Cloud Platform の管理者用ツールのSAP Cloud Platform Cockpit で「dev」スペースを選択し、右メニューの「Service Instances」を選択すると幾つかのサービスが表示されます。
ここでヤムルファイルに記載のあるHDIサービスインタンス名と同じ名前の「order-entry-hdidb」サービスを確認後、クリックします。
すると、host名やport番号などのDB接続情報が記載されていることが確認できます。このhost名はSAP HANA Cockpitのトップページに表示されているhost名と同じであることが確認できます。
複数のHANAインスタンスが存在する場合のデプロイ方法
今回の例では、1つのスペース内に1つのHANAインスタンスしかないため、自動的にDBが選択されましたが、同一スペース内に複数のHANAインスタンスが存在する場合は、デプロイ先のDBをヤムルファイルに指定する必要があります。
下記の図の通り、「database_id : 'XXXXXXXXXXXXX'」のようにdatabase id を指定します。このdatabase_idはSAP HANA Cockpitのトップページから確認します。
Host名の先頭部分がdatabase_idになります。
DBアプリケーションをBuildした気がするけど… ?
「はじめてのHANA Cloud」シリーズのPart 3,4,5にてDBアプリケーションを作成し、Buildしていたかと思います。
その操作と今回の操作での違いを最後に解説します。
開発フェーズにて、DBオブジェクトを1つずつ定義し、オブジェクト作成が成功するかどうか、また、その結果が正しいかどうかを確認しながら開発を進めると思います。
その作業は各オブジェクトのファイルを選択して、Buildする方式でした。
この方法でBuildすると、裏では自動的にHDIコンテナーが作成されたり(最初のBuild時に)、そのHDIコンテナー内にDBオブジェクトが作成されます。
ただし、この時のHDIコンテナー名は例で言うと「order-entry-order-entry-hdidb-XXXXXXXXXXXXXX」のように、プロジェクト名と(ヤムルファイル内で指定した) HDIコンテナー名を組み合わせて、さらに任意の文字列が付加されたような長い(意味不明な) HDIコンテナー名で作成されます。
HDIサービスインスタンスの名前も同様です。
また、DBに作成されるスキーマも「ORDER_ENTRY_HDI_1」のように、(ヤムルファイルで指定した) DBスキーマ名に番号が付与された命名規則で自動作成されます。
これらはローカルの開発環境 (自分だけの開発環境) で試す分には良いのですが、テスト環境や本番環境にDBアプリケーションをデプロイする場合には、今回、ご紹介したように「プロジェクトをBuildしてMTARファイルを作成し、それをデプロイする」方法を取ることを推奨しています。
そして、ローカルの開発環境は、DBの領域もアプリケーションの実行環境もリソースを取るので、開発がひと段落したら、そのDBの領域と関連アプリケーションは削除しましょう。
具体的には下記の手順となります。
SAP Cloud Platform Cockpitにて、「dev」スペースに移動します。
まずはスペース内の「HDIコンテナーにオブジェクト作成してくれるアプリケーション」を削除します。
左メニューの「Applications」を選択し、「hdispacedeploy….」で始まるアプリケーションを削除します。
続いて、下記の手順で「HDIサービスインタンス」を削除します。
このサービスを削除すると自動的にDB内のHDIコンテナーも削除されます。すなわち、テクニカルユーザーもDBスキーマもDBスキーマ内のオブジェクトも内部的な管理情報を格納したテーブルもプロシージャも全てキレイに削除してくれます(気を付けましょう)。
勘の良い方はお気付きかと思いますが、「はじめてのSAP HANA Cloud : Part 3」、もしくは「Free Trialではじめる、SAP HANA Cloud : Vol.2」でアクセスするDBを追加する際、「Database Explorer上で表示するDB名をシンプルにするために"Name to Show in Display"では分かり易い名前を付ける」作業を行いましたが、この仕組みを理解した方は、今後は難しい名前のままの方が、むしろ、運用としては分かり易いかと思います。
いかがでしたでしょうか ?
少し難しい内容でしたが、実際に試してみると、DBアプリケーションが簡単に複数の環境にデプロイできることがお分かりいただけたと思います。
他にもファイル間の依存性チェックなど、この「Buildしてデプロイする」方法には色々とメリットがあるのですが、今回はたくさん憶えることがあったのでここまでとさせていただきます。
ありがとうございました !!
