【寄稿】DXを支えるSAP基幹システムの基盤・運用はこう変わる

本記事は、JSUGが「いま知りたい！旬なITトレンド」をテーマに発行するメールマガジン「JSUG EXPRESS VOL.4」連動記事です。

第4回のテーマは「デジタルトランスフォーメーション」

本テーマは昨年のJSUG EXPRESS VOL.1でも取り上げられていましたが、その際には『リフトアンドシフト」で始めるデジタルトランスフォーメーション』と題して、「リフトアンドシフト」をSAPの観点から掘り下げて解説しておりました。
今回はその続編としてSAPシステムがクラウド上に「リフト」した後、すなわちDX具現化のために継続的な「シフト」の取り組みを支えるための次世代SAP基幹システム向け基盤のイメージを「基盤技術」と「運用」の観点から解説します。

DXって何？

デジタルトランスフォーメーション（DX）とは、「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」という概念で、2004年にスウェーデンのウメオ大学のエリック・ストルターマン教授が提唱したとされています。
かつては第3のプラットフォームと呼ばれていた「モバイル」「ソーシャル」「ビッグデータ」「クラウド」など、新しいプラットフォームを活用することで、新しい製品やサービス、ビジネスモデルを創出することで、企業の競争優位性を向上させること指すとも言われており、本記事ではこの内容で定義します。
早速、SAPを中心とした基幹システムが稼働するインフラの最新動向をみてみましょう。

DX時代を支えるSAP基幹システムの基盤技術とは

既にSAPを導入されているお客様の環境といえば、ERP, BW,Portalの御三家に加えて、ジョブ、監視、バックアップ、インターフェース、そしてSolution Managerといった周辺サーバを入れて運用されているかと存じます。また、長らくSAPを使われている場合には、当初何台もあった物理サーバを仮想マシン（以降VM）を使うことで、数台程度に集約させ今に至るといったお客様も多いのではないかと思います。
これからご説明する内容は、「この次はどうなるの？」について、技術的な背景や最新トレンドからより具体的なイメージに掴んでもらうのが目標です。

最新の基盤技術は最初にパブリッククラウド上で実装される

パブリッククラウド関連は常に進化し続け、かつサービスが広範囲に提供されていることもあり、一括でまとめて解説するのは無理があります。今回は既にSAPを中心とした基幹システムを運用されている方の視点で、あえて「計算エンジン（Compute Engine）」に注目することで、技術的な特徴をわかりやすく解説しています。

最新クラウドサービスは既存技術の組み合わせで成り立つ

下表一番左のIaaSは、皆様ご存じのVMが稼働する「IaaS」で説明は割愛しますが、その横の3つは一度は聞いたことがあるかもしれません。これらはそれぞれ別ものではなく、「コンテナ」は「VM」をその稼働基盤として利用し、「PaaS」はその「コンテナ」を稼働基盤として用いますので、これらは密に相互連携してサービスが稼働しているというのが一つ目のポイントです。

なお、FaaS（Function as a Service）は、AWS Lambdaが有名です。PaaS上で展開されたアプリのGlue（接着材）として提供されており、今後ますます発展が期待されるサービスですが、こちらでもVM、コンテナ、PaaSが利用されています。
本記事では基盤技術の観点から考察していることから、内部の仕組みを窺い知ることが必要なため、隠蔽度が高いSaaSは割愛しています。

サーバレス環境にもサーバは存在する

我々の基幹システムの分野でも「サーバレス」という言葉が注目されています。「レス」とあるので、一見サーバが存在ないように思いますが、前項で述べたとおりその基盤には「VM」即ちサーバは当然存在しています。従来との違いは、サービス利用者からは見えない（技術的に正確にいうと見えにくい）だけです。
サーバレス環境は一般的にPaaS上で展開される各種サービスを組み合わせて構築されることから、クラウド事業者でフルマネージドで運用されることとなり、利用者側はVMとかを意識しなくても使えるともいえます。しかしながらそのベースには仮想マシンやサーバがあるんだということを理解しておくのが2つ目のポイントです。

適材適所

3大パブリッククラウド事業者が競ってサービスの充実を図っていることからもわかるように、「敏捷性（Agility）」を重視した基盤が台頭する中で、当然ながらサービス毎に使い所や良し悪し（Pros and Cons）があり、このあたりの正しい理解が今後重要となってきそうだという状況を理解するのが3つ目のポイントです。
以上３つのポイント自体は凡庸な内容ですが、クラウドの世界はバスワードが多いので、誤解が多いこともあり改めてまとめてみました。
次は用途をSAP製品向け限定して、SAP社がどういう形で基盤の進化に追従しようとしているのか、その最新状況をみてみます。

SAP用途のインフラ最新動向

VMは今後も活躍

従来のSAP ERP6.0同様、SAP S/4HANAもふくめて、いわゆる大福帳DBと呼ばれていたERPのコアやその基盤のHANAは、今後もVMベースで稼働し続けることになります。
SAP社が提供するPaaSで「SAP Cloud Platform（SAP CP）」がありますが、こちらは「SAP Cloud Platform Service Description Guide」を見ることで内部の仕様を把握することができます。SAP CP内部で動くSAP HANA Serverや、「SAP HANA Service」としてサービス提供されるそのベースはVMです。それ以外のサービスについてもその多くがVMで稼働している一方で「Big Data Services」等オープンソース（OSS）で培った技術が採用されている分野ではコンテナを採用しています。このことからもわかるように最新テクノロジを活かしたサービスはオープンソース（OSS）を使うことが前提になっている今、当然SAP社も積極的にそれらを流用、組み合わせていくことになりそうな状況です。

新旧インフラが混在

SAPを中心とした基幹系システムにおいてDXを具現化していくためには、「VMをベースにした従来型のインフラ」と「PaaS、コンテナ、FaaS活用した新しいインフラ」が混在することになります。
ここまでSAPを含めたこれからの基幹システムの基盤技術とその適用動向を説明して参りました。
DXを具現化するのに求められる「敏捷性（Agility）や「新しい機能」を取り込むための施策を支えるための基盤の変化とその背景についての理解が少しでも深まれば幸いです。
続いて「運用」面での考察です。

インフラが変われば、運用も変わる

「運用」と一言でいってもその内容は広いです。今回は、従来からのSAPユーザーにとって親しみやすく、インフラが変化することのインパクトが大きい「監視」と「バックアップ」に絞って、掘り下げてみます。

監視・モニタリング運用

エンドツーエンドの監視・モニタリングの必要性

従来のSAP基幹システムで実装していた各種監視ツールによる局所性の高いモニタリング・監視に加えて、一連の処理が問題なく流れていることの監視・モニタリングが必要になります。
DXの具現化には、複数のクラウドやサービスを跨がって一連の処理を実行することになりますが、それぞれを個別に監視することはできても、対象が膨大になることで、その判断を人間がするのは事実上困難になります。その際にはEnd to End （エンドツーエンド）即ち初期入力から最終出力まで一気通貫の流れで監視・モニタリングする仕組みを予め作ることで、処理全体として「正常」 or 「異常」の判断が可能です。
具体例を挙げると、コンテナ基盤ではオートヒーリング（自動回復）機能を有しており、コンテナ内の処理が異常終了した場合には自動で再実行され、自律的に回復する機能を持ち合わせています。内部的にはコンテナ管理システムの配下のVMベースでクラスター環境が実装されており、物理サーバ障害時にはVM基盤ごとフェイルオーバーが行われていたりするのですが（＊注）、それを障害として検知し、能動的に運用担当者がアクションを起こす必要はありません。一方で、一連の処理が問題なく正常に処理されているかという視点は、個別にコンテナ上で実行されるアプリを監視しなくなった状態においては、障害発生時の判断・切り分け基準として重要な監視項目となります。
＊注：クラウドならではの設計、即ち全てのシステムは故障する前提の下でサービスが設計されているためです。（例：AWS社 Design for Failure）
ちなみに、パブリッククラウドでは、監視・モニタリング機能は標準機能として標準搭載されており、情報収集や分析のための基盤を一から作成する必要はありません。
クラウドサービス    監視方法
AWS    Amazon CloudWatch
Azure Azure Monitor 他
Google    Google Stackdriver
標準の監視サービスを使ってメトリクス（標準ではリソース利用率など）やログを取得したり、APIを通じてそのデータを取得することができます。運用ではそれを使って監視・モニタリングをすることが可能ですが、複雑な判断基準などは独自に組み込む必要があります。また、自社アプリケーションの状態は、独自のカスタムメトリクスやログを拡張定義することで各種情報を収集する仕組みをさらに追加する必要があります。

TIPS：SAP社によるエンドツーエンドの監視やモニタリングに対する取り組み

取り組みはかなり早く、SAP Solution Managerが登場して、まもなくEnd to End Monitoringの話がありましたのでかれこれ10年以上の歴史があります。今も継続していますので決して遅れているわけではなく、むしろ基幹システムの分野においては先進的ともいえる内容です。
Monitoring & alerting Infrastructure（MAI）

TIPS：本ビジョンのアプリケーションへの応用

本記事は基盤の話をしていますので、ニュアンスが異なりますが、よりビジネスよりの実装例として参考になります。
一連の処理が問題なく流れていることの監視・モニタリングに関して、効果的なアプリケーション応用例として参考になるのが、SAP社が製品として世に出したSAP GRCのSAP Fraud Managementです。膨大なトランザクションデータの中から、不正会計や横領などの不正パターンの予兆を検知するような仕組みがパッケージとして実現されています。

画像出典：SAP Blog

死活監視だけでは機能不足

従来より「URL」や「ポート」を外部監視することで、そのシステム（サーバ）が正常かどうかを簡易に判断する「死活監視」が一般的に行われていましたが、DX時代では、それだけでは機能不足です。サービスが常時起動されていることを前提にしたのが従来型の監視とすれば、今後はサービス自体がオンデマンドで起動、停止する（＝落ちていても正常と判断）ことを前提とした監視即ち、アラート発生、検知のロジックが予め組み込まれたより高度な監視を実装する必要があります。
従来の監視ツールでも、上がってきた複数のアラート元に、条件分岐やフィルタリングをすることで、ある程度実現されていたお客様もいらっしゃるかと思います。しかし、監視対象が必要に応じてスケールアウト（水平拡張）し、不要になれば対象自体がなくなるといったことが、クラウド側で自律的に行われますので、今までのやり方の延長では容易に限界がくるということをご理解ください。

各種ログの集約及びログ監視の必要性

機能をサービス単位で切り出し、その集合体がシステムとなる場合、監視業務においても全体的な整合性の確保が困難になったり、運用上の複雑性が増すのはいうまでもありません。また、複数の監視ツール（サービス）を呼び出して1つの大きい処理を実現しようとする場合に、パフォーマンスの劣化が想定されます。
一方でアプリケーション及びそれが稼働する各種基盤で吐かれるログには、API経由で取得した予め対象を絞ったメトリックスには含まれない、詳細な情報も格納されています。しかし、多数の場所に格納された詳細ログを個別に見て判断する運用には限界があります。また、エンドツーエンドな監視・モニタリングにより、障害発生時の初動対応はなんとかなったとしても、切り分け時に必要な情報が分散した結果、障害の根本原因分析に時間が取られてしまうことも潜在的なリスクとなります。
それらを運用で回避するために、膨大なログを集約することで閲覧性を高め、分析を高速かつ容易にすることで、運用負荷を低減することは効果的です。
従来のオンプレミス環境では、主にコスト削減の観点から、ログを格納する領域は極めて限定的でした。しかしパブリッククラウドでは、予め格納領域を確保することなく、極めて安価な従量課金体系で利用することができますので、大量のログを集約するためのストレージリソースの課題は、容易に解決できる時代になりました。
また、膨大なログデータを高速に検索するために有効なクラウドサービスも従量課金ベースで提供されていることから、必要なログを選択、分析するために必要となるリソース不足によるパフォーマンス懸念は払拭され、かつ必要最低限の課金で賄うことができる時代となっています。

バックアップ運用

SAPシステムは、当初大福帳DBを軸にした単一サーバ構成によるERPシステムが始まりです。その後BW,Portal,CRMといった各種ソフトウェアコンポｰネントが別立てのサーバとして取り込まれていき、今に至ります。当時から今に至る課題として、複数サーバ間でデータの整合性をソフトウェアパッケージとして完璧に維持するのは困難ということが挙げられます。（SolManやAPOのデータ整合性チェック機能とかMDMによる統合マスタ管理など、局所的に改善の取り組みがなされているのですが、その効果は限定的と言わざるを得ません。）
このような状況の中での現実解としては、複数サーバ間で同時のシステム静止点を設け、そこで全サーバのデータバックアップを取得することによるリカバリポイントを作成し、最悪でもその時点まで戻すことで全てのシステム間の整合性を担保するのが、一番シンプルで確実な方針となります。しかし、DXを具現化していくために必要となる各種サービスが膨大になり、常に変化し続けることを前提にした場合、この方針を見直す必要がありそうです。
その背景としてPaaS、SaaSの場合、基盤の運用は全てサービス提供者側で行われます。また24X365のサービス稼働が前提となり、データのバックアップも提供者側で取得されるため、バックアップ・リカバリーについては利用者側からは見えなくなります。（それでは不安というお客様は、上位のアプリケーションレベルでバックアップの概念を持ち込むことは当然あります。）
一方で、IaaS環境で動いているVMベースのシステムは、従来通りバックアップ・リストア運用は利用側で自社の運用に組み込むことになります。
以上のことから、PaaS,SaaSを含めた全システムで同時の静止点を確保することによる複数システム間の整合性担保は困難です。
逆に、IaaS側のバックアップ運用を24X365のノンストップ運用で考えることは容易ですので、その際にはシステム稼働中のオンラインバックアップ取得が前提となりますが、こちらの場合でも複数システム・サービス間で整合性を取ることは困難です。
以上のことから、今後は複数システム・サービス間の厳密な整合性確保をインフラ側だけで担保することはある程度諦めざるをえないかもしれません。本課題に対して弊社としては、アプリケーションレベルでシステム連携を密結合から疎結合に転換することを推奨しています。

最後に

長文最後までお読み頂き、ありがとうございました。
当初はわかりやすく図示しようと試みたのですが、最初に述べたとおり基盤技術で使われるキーワードはバズワードでかなり曖昧な定義のために、逆にわかりくくなり、文章のみで解説しました。
運用に関しても２つのトピックに絞りましたが、それ以外にも「自動化」や「インターフェース」などのトピックもご説明したかったのですが、さらに文章量が増えるため今回断念しました。下記リンク先にこのあたりの内容が書かれている資料をご覧いただけます。よろしければご参照下さい。
こちらからダウンロードすることができます。