SAP HANAの超高速処理を活かし、独自のビジネスロジックを実行するための「コード最適化」


SAPジャパンの松舘です。SAP HANAのテクノロジー解説の第3回目は、「コード最適化」という概念についてお話させていただこうと思います。現在SAP ERPのデータベースとしてお使いのRDBMSを、SAP HANAに移行する際、SAP HANAの恩恵を得ていだくために必須の移行手順となります。それでは最後まで、よろしくお願いします。

SAP ERP三層構造の役割とSAP HANAにおける「コードプッシュダウン」

すでにご存知のとおり、SAP ERPのデータベースとしては、現状、Oracle、IBM DB2、Microsoft SQL Server、SAP Sybase Adaptive Server Enterpriseなどを利用することができます。このデータベース部分をSAP HANAに移行する際、どのような点に留意する必要があるかについて、一緒に見ていきたいと思います。

最初にこちらの図をご覧ください。以前の名称であるSAP R/3の「3」が、三層構造を意味するということは、第1回のブログで触れましたが、図にはその3つのレイヤーである「User Interface Layer」「Application Layer」「Database Layer」と、それぞれの役割が記載されています。

Picture3

左側から見ていきましょう。「Classic Database」は、既存データベースを使用している場合の構成になります。User Interface Layerでは、SAP GUIと呼ばれるSAPのフロントエンドツールが機能します。次のApplication Layerは、ABAP言語によるアプリケーションサーバーのレイヤーで、ERPのビジネスロジックが動いています。Database Layerでは、データの管理、ハンドリングが行われています。

SAP R/3が設計された当時、データベースの役割は、データが消えないよう確実に管理し、ハンドリングを行うという点に特化されていました。当時のデータベースのパフォーマンスを考慮すると、ERPで実行する複雑なロジックの処理は、ABAPのApplication Layerで実行する形がベストだったからです。図中で「Calculation」と記載した青いボックス部分です。

一方、右側が「SAP HANA Database」の場合の構成になります。ご覧いただいて分かるように、「Calculation」処理がDatabase Layerに移っています。SAP HANAではマルチコアで超高速な処理を実現できるため、以前のようにビジネスロジックの実行をApplication Layerで行うよりも、Database Layerで実施する方がトータルのパフォーマンスを向上することができるからです。このように、ビジネスロジック実行機能をDatabase Layerに移すことを“コードプッシュダウン”と呼びます。「下のレイヤーに押し下げる」という意味です。

ビジネスロジック実行機能をDatabase Layerに移行した場合のメリットについて、別の視点から見ると「転送データ量を減らせる」という点をあげることができます。以前の構成では、計算に必要となるデータをすべてDatabase LayerからApplication Layerに転送してから処理する必要があり、データの転送量がネックとなりました。SAP HANAでは、「SQLScript」と呼ばれるSAP HANA専用に拡張されたSQL言語を使って、Database Layer内で、いわゆる“ストアドプロシージャ”の形態により計算処理を実装しています。これにより、データ転送量を劇的に減らし、パフォーマンスを向上することができるのです。これを“Code-2-Data”と呼びます。

カスタムABAPコードの最適化

THE CITY CODE, SERBIAN PAVILION, NATALIJA  WORLD EXPO 2010, SHANGHAI, CHINA.SAP ERPのデータベースをSAP HANAへ移行する場合の考慮点として、“アドオン”機能の扱いも重要となります。特に日本のお客様の場合、独自のロジックをアドオンとして追加しているケースが少なくありません。このようなアドオンについて、移行時にどのような対応が必要かを説明します。

アドオンをSAP HANA最適化する場合には、標準トランザクションがどのように最適化されているかを確認すると非常に参考になります。SAP ERP標準のトランザクションコードではいずれかの「最適化」が施されています。標準の場合には、SAP HANA Viewに対してプロキシの役割を果たすExternal Viewへアクセスしたり、NetWeaver 7.4から利用可能になったABAP命令のCALL DATABASE PROCEDUREを利用してSAP HANAに定義したストアドプロシージャをコールするようトランザクションが最適化されています。最適化の結果、特に集計や集約を行うトランザクションにおいて、顕著な高速化の恩恵を享受できるようになります。なお、ABAPコードのSAP HANA最適化を行う場合には、トランザクションコードSE11やSE80を利用するのではなく、Eclipseベースの SAP HANA StudioにABAPアドオンを追加して開発を行います。これにより、SAPGUIとSAP HANA Studioを切り替える必要はなく、単一の開発ツールで作業が行えるため作業効率も向上します。

アドオンについては、SAP ERPのバージョンアップなどの際にも、新しいプラットフォーム上で正しく動作するか確認が必要になります。データベースをSAP HANAに移行する場合、このようアドオンに関しては、「ABAPコードガイドラインにしたがって開発したロジックは、基本的には移行後もそのまま稼動するが、最適化するとより速くなる」という扱いになっています。SAPでは、カスタムのABAPコードをSAP HANA移行後も使用できるようにするために、3つのレベルを持つガイドラインを提示しています。

カスタムABAPコードの最適化における3つのレベルを以下に示します。

Picture2

Level 2では、前述した青いボックス「Calculation」での処理の扱いが変わります。以前のデータベース使用の際には、Calculationにおいて、カスタムABAPコードで記述していた処理が実行されていましたが、SAP HANAの場合には、SAP標準のViewへアクセスもしくは、ユーザー独自のCalculation Viewを作成して、そこにビジネスロジックを埋め込み、データベース側で実行する形をとります。これによって、格段にパフォーマンスを向上することができます。

また、ABAPで記述したロジックの場合、データベースからデータを取得して処理する形をとりますが、SAP HANAの場合には、データベース側のストアドプロシージャを呼び出し、結果をクライアントツール上で表示する機能に置き換えることができます。これらの最適化によって、SAP HANAが持つ超高速処理を最大限に活かしながら、独自のビジネスロジックを実行することができるようになります。

実際の改善例を考えてみましょう。カスタムレポートのために、バッチ処理を実行してカスタムテーブルに集計結果を持っているケースが多いと思います。そのカスタムテーブルをSAP HANA View化してレポートで参照すれば、もはや、その生成用バッチ処理は不要であり、データ容量も削減され、エンドユーザはレポートを瞬時に確認できます。何倍の高速化になるでしょうか。処理そのものがもはや必要ないのですから、驚くべき効果があることがわかります。

まとめ

  • SAP Business Suite powered by SAP HANAは、コードプッシュダウンによりビジネスロジックをSAP HANAデータベースで実行することによって高速化されている
  • コードプッシュダウンを行うにはSAP HANA Viewやストアドプロシージャを構築するSAP HANAコード最適化を行う必要がある
  • コードプッシュダウンの結果、特に集計や集約を行うトランザクションにおいて、顕著な高速化の恩恵を享受できる

最終回となる今回は、SAP HANAへの移行におけるコード最適化についてご説明しましたが、いかがだったでしょうか? 3回のブログを使った駆け足の説明になりましたが、SAP HANAの魅力やその背景について、ご理解を深めていただければ幸いです。

それでは、また次の機会に皆様とお会いできることを期待しながら、今回の私のブログを終わらせていただこうと思います。ありがとうございました!

ご質問はチャットWebからも受け付けております。お気軽にお問い合わせください。

●お問い合わせ先
チャットで質問する
Web問い合わせフォーム
電話: 0120-554-881(受付時間:平日 9:00~18:00)