SAPの複雑性は、IBM iのパフォーマンスにどのように影響するか
IBM iサーバーとSAP社のERP（エンタープライズ リソース プランニング）ソフトウェアは、世界各地の何千もの企業を動かしている強力なコンビです。このコンビの成功は、たとえ広く認められてはいないにしても、注意を向けている人々にとっては明らかなことです。しかし、IBM i上でのSAPの円滑な運用を確保することは、特にこのセットアップの複雑性について知らない人にとっては、必ずしも、思うほど簡単ではないようです。
SAP社には、物事を行う独自のやり方があるという事実は、今に始まったことではありません。数十年前、Hasso Plattner氏率いるドイツIBM出身の5名のエンジニア グループがSAPソフトウェアの最初のリリースを開発して以来ずっと、同社はエンタープライズ ソフトウェア業界の中で独自の道を切り開いてきました。TAM、FMCからABAPやNetweaverまで、SAP社は独自のツールおよびテクノロジーを作成して顧客の環境をサポートすることで長く知られてきました。
もうひとつ、議論の余地のない事実があります。すなわち、SAP社のERPソフトウェアは、すべての業界の企業に向けて非常に多くの機能を提供しているということです。そうしたことからSAP社は、互角のライバルであるOracle社とともに、グローバルなERP市場における2大リーダー企業と目されることとなっているわけです。
しかし、そうした高いレベルの機能性には、相応のレベルの複雑性が伴います。同社のフラッグシップのERPプラットフォームには、30,000を超えるリレーショナル データベース テーブルが含まれることを考えてみてください。確かに、膨大な数ですが、これは、SAPがアプリケーション コードをデータベース本体に格納するという（この分野では比較的珍しい）事実に起因するものです。しかし、そのことが、Db2 for iのネイティブ サポートを含め、多数のRDBMに渡ってすべての種類の様々なビジネス プロセスをSAPがサポートすることを可能にしているという面もあります。
SAP社は、S/4 HANAソフトウェア製品ラインにおいて複雑性の低減を図りました。S/4 HANAでは、データベースおよびアプリケーション レベルを簡素化することや、トランザクショナルおよびアナリティカル ワークロードを1つのインメモリー列指向データベースにまとめることによってスプロールを統合することが意図されました。SAP社は数年前にHANAを発表し、次いで2015年にS/4ソフトウェアを追加しましたが、そのときに同社が自慢していたのは、いかにして比較的小型のサーバーを使用して、HANA上で業務を行えるようにしたかという点でした。
しかし、HANAのアプリケーション コンポーネントはIBM Powerプロセッサー上で稼働しますが、データベースは現在Db2 for i上でサポートされていません。そのせいで、SAPソフトウェアに投資するIBM iのショップ向けには、従来のNetweaver環境やSAP ERP Central Component（ECC）が依然として主力製品のままとなっています。
このことで、IBM iの顧客にとって構成オプションの数が削減されている側面もあります。しかし、SAP ERPソフトウェアを使用するためにPower Systemsハードウェアおよびソフトウェアをサイジングするプロセス全体がシンプルになるわけではありません。実際、パフォーマンス レベルを相応のレベルに維持するためには、検討すべき点は、かなり多くあります。
増大する複雑性
IBM Systems Lab ServicesのSAP on IBM iプラクティス リーダーであるKolby Hoelzle氏は、ミネソタ州拠点の著名なIBM i向けシステム管理ソフトウェア ベンダーが先日開催したウェビナーで、SAP on IBM iの顧客が認識しておくべきいくつかの基本的なパフォーマンス上の考慮事項について論じています。 「SAPをしばらく使用したことのある人にとって、SAPは常に、本質的に複雑なものでした」とHoelzle氏はそのウェビナーで述べています。「しかし、そうした複雑性は、ほとんどの場合、1つのアプリケーション、すなわちR/3に限られたことでした。しかし、そうした状況はこの10年の間に少し変化してきており、SAP社がERP製品に対する追加製品を導入するのにつれて、その複雑性は飛躍的に増大しています。」
※「i」は、統合（integrated）を意味するものですが、近頃では実情と懸け離れたものになっています。
コアとなるERPコンポーネント（旧称R/3、現在のECC）は、依然としてSAPの世界の中心にいます。しかし、顧客のニーズに応じて、ECCの周りには、サプライ チェーン プランニング、顧客関係管理、生産計画、在庫購買管理、人事管理、財務会計および管理会計、販売管理といった、様々な機能のためのあらゆる種類のモジュールが集まって来ます（また、セキュリティのために利用可能な技術的なモジュールと、皆さんお気に入りのプログラミング言語であるABAPも忘れてはなりません）。
一部のケースでは、SAPの顧客はこれらの様々なアプリケーションをサポートするために複数のデータベースを稼働することになっているようです。そして、表面上は管理者の業務を簡素化してくれる「一元管理される」ソフトウェア スイートの下にすべてまとめられているとはいうものの、実際のところ、これらのピースはすべて、特に非SAP製品と統合する際には、複雑性を増大させる元となってしまいます。
「SAPのセールス ポイントの1つが、他のすべてのアプリケーションを一掃してしまっても、それまで行ってきた業務をSAP上で行えるという点だとしても、実際には、他の非SAPアプリケーションとの統合は必要なのです」とHoelzle氏は述べます。「このことは、管理の必要があり、分析および最適化の必要がある非常に複雑な状況をもたらします。」
SAP社では、こうした複雑性を抑えるための対策を講じてきました。たとえば、顧客が複雑なデプロイメントを管理するのを支援するためのSolution Managerという単体製品はその一例と言えるでしょう。ただし、同製品の、複雑なインフラストラクチャーを管理および監視する機能は限定的だとHoelzle氏は述べます。「一定の指標を提供してくれたり、インフラストラクチャー監視機能の一部を担ってくれたりする点では有用です」と彼は述べます。「しかし、Solution Managerや、SAPに組み込みの管理および監視機能は、実際のところ、SAPそのものの管理を意図したものなのです。」
複雑性増大の問題は、SAPや、他のソフトウェア製品との統合に限られるものではなく、サーバー プラットフォームそのものにも影響を及ぼします。これはIBM iのショップにとって最も重大な複雑性の発生源の1つであるとHoelzle氏は述べます。
「昔は、特にIBM iについては、IBM iまたはAS/400があって、それだけでした。それはPowerハードウェア上で稼働しました。内蔵ディスクがあり、すべてがそこに収められていてすぐに使えたため、他のコンポーネントについて気に掛ける必要はありませんでした」と彼は述べます。「サーバーがあって、ネットワークに接続したら、すべてはそこで管理されました。」
今日に至るまでのいつかの時点で、あのシンプルだった日々はフッと消え去ってしまいました。「サーバーは今もありますが、今は仮想化があります。PowerVMもありますし、ストレージを仮想化しています。ということは、VIOSのようなものを導入する必要があるということになり．．．。我々は、多種多様なコンポーネントおよび多種多様なシステムからなる、これほど複雑なインフラストラクチャーを目の前にしているわけです。」
すべてをIBM iを通じて管理するのでないとすれば、表向きSAP on IBM iを「稼働している」顧客は、ある程度はAIXを知っている必要もあります。これはVIOSがUnixアプリケーションであるためです。また、SAP on IBM iが外部ストレージ アレイ上でデータベースを稼働している場合は、そのオペレーティング システムについても学ぶ必要があります。
「今日、我々が利用しているインフラストラクチャーには多くの利点があります。高度に仮想化されたインフラストラクチャーのおかげで多くの優れた機能や柔軟性がもたらされています」とHoelzle氏は述べます。「しかし、今日のインフラストラクチャーは高くつき、その料金体系は一般に非常に複雑です。統合度は単一サーバーよりも低いです。場合によっては、様々なインターフェースやオペレーティング システムについて学ぶことが必要になるかもしれません。そして、もちろん、エンドツーエンドの監視を行うには、より慎重さを要するようになります。」
ユニークな特性
Hoelzle氏は、SAP on IBM iを稼働することをユニークにさせている他のいくつかの特性についても詳しく述べています。また、そのことがこの強力なセットアップの日常管理にどのような影響を与えるかについても詳しく述べています。
SAP on IBM iのパフォーマンスの最も重要な特性の1つは、IBM i上での稼働時に、SAPによって幅広くサブシステムが使用されることです。IBM iサブシステムの使用は、「我々のSAP環境に分離層をもたらすので、SAP環境に統合する形で、かつ独立して稼働するのを可能にします。これはIBM iではかなりユニークなことです」とHoelzle氏は述べます。
IBM iの顧客は、開発と環境のテストを別々のボックスで行うのではなく、他のプラットフォームがSAP顧客にそうするよう求めるように、開発、テスト、および実働ワークロードを同じPower Systemsサーバーに統合することができます。これによりサーバー スプロールがなくなります。サーバー スプロールは長らくX86環境の悩みの種となっており、その一方で、X86環境に対するIBM iサーバーの秘密兵器でもありました。
※JDBC Configuration Managerは、JDBC接続を選択するための便利なツールです。
ほとんどのSAPジョブがIBM iサブシステム内で実行されるという事実は、監視にとっての利点であるとHoelzle氏は述べます。しかし、リモート データベース アクセス ジョブを含め、すべてのジョブがそのような形で実行されるというわけではないため、この点は監視計画を策定する際には留意する必要があります。
SAPは、非常にデータセントリックです。SAPはコンパイル済みアプリケーション コードもリレーショナル データベース テーブルに格納するとHoelzle氏は述べます。IBM i実装では、SAPは、Db2 for iのほぼ全体を格納しようとしますが、すべてではありません。たとえば、SAPは様々なライブラリーを使用して、データベースのトラッキングを行うジャーナル レシーバーを格納します。「カーネル ライブラリー」の一部は、従来のIBM iライブラリーにも格納されます。
多くのSAPランタイム ログはIFSディレクトリーに保存されますが、このことはSAP on IBM iのパフォーマンスを理解するために考慮すべき重要な事項です。「そして、スタートアップ時や他の問題など、SAPに問題が生じた場合、SAPランタイムでは、それらのログをIFSに書き込みます」とHoelzle氏は述べます。「一般に、ビジネス データはそのファイル システムに保存するべきではありませんが、時折、そうした事態が起こることは間違いないと思われます。」
SAPユーザーの監視に関しては、非常に重要な点が1つあります。それは、SAPはIBM iのユーザー プロファイルを使用しないという点です。SAPは独自のユーザー認証システムを使用し、IBM iのユーザー プロファイルを使用するのは、管理者の場合のみです。
「SAPはSQLセントリックであり、データベース セントリックです」とHoelzle氏は述べます。「すべてはデータベースが中心ですが、ロギングなどの雑用的なタスクには、そのファイル システムのような他のコンポーネントをいくつか使用します。」
ブラック ボックス
SAP on IBM i環境を適切に監視するためには、目を配らなければならない様々な場所があります。いくつか例を挙げれば、サブシステム ステータス、ジョブ ステータス、ライブラリーおよびディレクトリーの増加、一時ストレージ、およびジャーナル レシーバー ライブラリーなど様々です。
しかし、目を配るべき場所がそれほど多いために（IBM i上だけでなくSANアレイ上もその対象です）、プロセッサー、メモリー、およびディスク入出力という3つの主要なパフォーマンス指標に関して実際にどのような状況なのかユーザーが適切に把握できなくなる「ブラック ボックス」化が生じます。
「これらの制約や障害は、どこででも発生することがあります」とHoelzle氏は述べます。「制約や障害の影響を受けないコンポーネントなどありません。だからこそ、こうしたブラックボックスを取り除いておきたいのです。これらの領域はどれも、システム全体の処理を低下させる原因になり得るため、これらの領域のすべてを把握しておきたいのです。」
優れたパフォーマンス（優れたスケーラビリティおよびメモリー入出力など）は、SAPがサポートしている他のサーバーに対してIBM iプラットフォームが持つ大きな利点の1つです。システムの複雑性が増大することによってパフォーマンスの課題が覆い隠される可能性が出てきており、これはSAP-IBM iを連結して使用している顧客が直面する重大な課題となります。
「システムがどのように使用されているか、どのような制約があるのかを把握しておくことが必要であり、実際のところ、私が「バランスのとれたシステム」と呼ぶものを維持することがここでの目的です」とHoelzle氏は述べます。「効果的かつ包括的に監視を行うことは、そうした目的を実現するための鍵となります。とりわけ環境がますます複雑になってゆくのだとすれば、なおさら必要となります。」
