SAP製品がS/4HANAへとシフトするなか、S/4HANAならではのシステム要件に応える”SAP on Azure”の強みと展望とは？
日本マイクロソフト株式会社グローバル ブラックベルト セールス部のテクノロジーソリューションズプロフェショナルである家田恵氏、Azure Enterprise技術部のクラウドソリューションアーキテクトである井上和英氏に、さらに詳しく伺います。
性能面での課題を鑑みても、現在Azure上で動かないSAPシステムは存在しない
― パブリッククラウド上でSAPを運用する場合、性能面での課題や、それに対する試みなどはありますか。
クラウドソリューションアーキテクト
井上和英氏
井上氏：
現在、SAPのシステムで、Azure上で動かないシステムはほぼないと思います。性能面に関しては、SAPのベンチマークを取るという仕組みがあるので、ベンチマークを取れれば標準のトランザクションでの性能は担保されます。新しい認定取得のために、より高い性能を実現するためのベンチマークを、マイクロソフトのSAP部隊がSAP社と共同で実施しています。HANAの観点では、仮想化で不足する部分が絶対に出てくるので、それをLarge Instanceで補って、大規模なHANAのシステムでも高いパフォーマンスを実現しています。
― 例えば業務システムでは、夜間に大量にバッチを走らせて、朝までに処理を絶対に終わらせなければならないような場合もありますが、バッチ処理に関して、オンプレミスと比較してクラウドの場合のネックや課題はありますか。
井上氏：
ディスクの性能でしょうか。オンプレミスの場合、ストレージは高価なものを買えばI/O性能、スループットは上げることができますが、パブリッククラウドでは限界がありますね。ただ、その場合もチューニングで解決できる課題がほとんどですので、ほぼ問題はないと考えています。
家田氏：
実際にこれをクリアするための検証を実施しているお客様もいらっしゃいます。ディスクに対して、これだけのIOPSを保証しますというのをサービスとして提供しており、それを確認していただいているお客様もいらっしゃいます。ストレージはたくさんお使いいただいていますが（笑）。
Azureの可用性を支えるハードウェアと高可用性機能とは
―ここからは、ビジネス継続や可用性の観点から、Azureの可用性について伺いたいと思います。まずハードウェア的な観点から、現在のクラウドは十分な可用性が確保できていると言えるのでしょうか。クラウドは当初コンシューマー系やウェブ系、ネットビジネスなどを想定しており、ハードウェアは壊れても仕方がない、壊れたらまとめて後で交換すればいいという考えのベンダーもあったと思います。Azureはこの点に関して、何が違うのでしょうか。
井上氏：
オンプレミスでエンタープライズアプリケーションを動かしていたハードウェアと同じレベルの完全な堅牢性を備えたものではありませんが、Azureの場合も、マシンをたくさん並べて、壊れたら取り換えるという基本思想は同じです。
ただし、マイクロソフトでは、ディスクに限らず、すべてのサービスを多重化していますので、ほとんどのお客様はそれに気づかないという点が異なります。例えばディスクは多重構造になっているので、そのうちの一つが壊れても、自動で交換して新しいディスクにまたデータが書き込まれるようになります。壊れたものがあっても、お客様はサービスの利用を継続し、気づかないうちに復旧しています。かつてのクラウドもどきとオンプレミスの中間といった位置づけでしょうか。
― 次にもう少し上のレイヤーに目を向けると、Azureには更新ドメイン、障害ドメイン、可用性セットといった機能がありますが、これによってシステムの継続利用が可能になりますか。
家田氏：
物理的には、機械は壊れるものであり、メンテナンスは必要であるという前提に立った時に、それでも継続して使っていただくために提供できる仕組みには何があるか、ということで、障害ドメイン、更新ドメインなどがある、とお考えいただければと思います。
― それ以外にも、障害発生時には他の物理サーバーが自動的に起動するといったような、高可用性を実現するための機能はありますか。
井上氏：
AzureにはService-Healingという機能があり、一つのサーバーがダウンしたら自動的にリカバーします。またAzureの可用性セットではバックアップ用のインスタンスが同一のデータセンター内の、近い場所にある別のラックに配置されるため、リカバリーが速いという点が強みです。DRの観点からは、バックアップは距離的に遠い場所にあることが重要ですが、HAの観点では近くて迅速な復旧ということも判断基準になると考えています。
クラウドは共有ディスクを持てない仕組みなので、必ず同期する必要があるということを考えると、遠くに配置すると性能にインパクトを与えてしまいますので。
マイクロソフトのSLA
― SLAについてうかがいます。ベンダーによって考え方が異なる場合もありますが、御社のSLAは何に対するSLAなのでしょうか。
井上氏：
まずマイクロソフトのSLAで特徴的なのは、すべての一般公開されているサービスに対してSLAを提供していることです。SAP関連ではIaaSになりますが、これについては可用性セットを組んでいただくことが前提の上で、99.95%のSLAを提供しています。また、前提条件はありますが、シングルインスタンスでも99.9％のSLAを提供することが可能です。これはアップタイム、OSではなく1インスタンスが稼働している時間に対するSLAで、可用性セットで2台構成にした場合に、そのうち1台を99.95％月次で稼働させるということをお約束しています。
― SLA が99.95%はいえ、クラウド側の機能だけでは、システム全体の可用性の確保といった場合には足りない部分もあると思います。例えばHANAの場合、HANA自体にHANA System Replicationのようなレプリケーション機能もありますが、稼働系が落ちた場合にそれを自動で切り替える機能はありません。
テクノロジーソリューションズプロフェショナル
家田恵氏
家田氏：
はい、HANAの障害を自動で検知して自動での切り替えを行うには、HAクラスターソフトを使用する必要があります。可用性セットにしても、Large Instanceの可用性ペアにしても、マイクロソフトで提供しているのはインスタンスとしてのアップタイムだけですので、その上で動いているデータベースやSAPのアプリケーションの稼働はお約束できません。しかしお客様が本当に求めていることは、仮想マシンが動いているかどうかではなく、その上のシステムをユーザーが使えているかどうかなので、障害発生時にアプリケーションを切り替えてくれる仕組みを入れる必要はあると思います。
― データベースは言わずもがなですが、SAPの中でSPOF（Single Point of Failure：単一障害点）となるコンポーネントが他にもいくつかあると思います。例えばASCS(ABAP SAP Central Services)と呼ばれるインスタンスがありますが、一言でいうとどのようなものなのでしょうか。またこのASCSが落ちてしまったらどうなるのでしょうか。
家田氏：
SAPのアプリケーションサーバー間の負荷分散を内部的にコントロールしています。そして、SAPはアプリケーション上でも更新管理をする仕組みがあるので、その更新のロックを管理しています。このASCSが落ちてしまったら、業務を継続することができません。
― 業務継続のためには、このようなコンポーネントの冗長化やHAクラスター化も必要だということですね。SAPのようなハイエンドのERPを利用するお客様の場合、高い可用性が求められるのは当然と考えていいでしょうか。
井上氏：
そうですね、マイクロソフトのお客様は非常に規模の大きい企業様が多いので、業務継続性を重要視されています。また、SAPのSPOFをなくすことにも注力されており、HAソリューションの導入をご検討されているケースがほとんどです。
S/4 HANA化でLinux環境に移行した場合のHAクラスタリングとサイオスのSANLess Clusters
― 国内外でAzure環境での実績のあるサイオスのSANLess Clustersソリューションに対し、御社が今後期待されることや可能性にはどのようなものがあるでしょうか。
井上氏：
マイクロソフトとサイオスのつながりは深く、検証した後のホワイトペーパーや、リファレンスアーキテクチャにはサイオスのソリューションが出ています。Azureに関しては、サイオスが一番のHAソリューションになっています。ですから、今後もスピード感を維持していただきたいという期待はすごくありますね。ただ、日本ではより認知度が高いクラスター製品の存在や、それらのサポートが良いというイメージがあったりするので、サイオスのソリューションの認知度を上げていく活動を一緒にしていけたらと思っています。
家田氏：
従来はWindowsのクラスター機能と組み合わせて使うソリューションをご提案いただいていたと思いますが、HANAの場合はLinuxを使用しています。そこで今までWindowsを使っていたお客様はLinuxへの移行ということで、ハードルが高くなると思います。Linux環境のHAクラスタリングはサイオスさんの得意とするところですので、そういった移行のお客様向けに、より一層、この構成を組むハードルを下げていただきたいですね。
また、最近の傾向として、Red Hatを選ぶお客様が増えているので、サイオスさんのソリューションに対する需要自体も高まってきていると思います。
― 今年の3月にプレスリリースで発表した、SIOS Protection Suite Linux v9 EEという製品は、SAP認定を受けたLinux上でのHA化の製品です。今後のS/4HANA化に向けては、弊社の製品はお役に立てるのではと考えています。
SAPユーザーのDR（Disaster Recovery）の検討
―最後にDRについてうかがいます。弊社でも、DataKeeperという製品を使用してDRのシナリオを作成する場合もあります。SAPユーザーはDRを検討するケースも多いのでしょうか。
井上氏：
ほぼ100%のお客様がDRを検討されます。マイクロソフトの強みとしては、Azureは東西リージョン（ペアリージョン）を組むことが可能です。ペアリージョンを組む際の規定では、なるべく480キロ以上離すという条件があります。このような遠距離でのDRのペアリングソリューションがあればいいですね。
― Azure Site Recovery (ASR)などはSAP on Azureでも提案されていますか。
家田氏：
ASRは、セットで提案しています。ただし、データベースのレプリケーションの場合は、ご提案しません。ASRはVMレベルのレプリケーションであり、データベースの整合性を担保しないためです。また、本当にDRを発動した際の切り替えがASRだけでできるのかどうかという点は、検討の余地があると思います。特に、ASCSのような領域のDR対策を高いレベルで要求する場合には、ASRのレプリケーションで足りるのかということです。
― ASCSのようなインスタンスならば、レプリケーション的発想ではなく、東西でクラスタリング組むという発想はいかがでしょう？
井上氏：
それにはASRには不向きなので、サイオスのLifeKeeper/DataKeeperなどの製品が確実に必要になります。
―クラスターを一つのペアと考え、東にあるペアをどのように西に複製するかといった部分で、SIOS製品とASRの組み合わせも現在検証中です。適材適所で、弊社の製品とマイクロソフトの製品を組み合わせて、お客様に求められるソリューションを構築していければと考えています。
井上氏：
それは楽しみですね。サイオスさんはAzure上のHAソリューション、DRソリューションのトップランナーだと思うので、ぜひこのまま走り続けてください。
関連記事
- エンタープライズDBMS環境としてのAzureの優位性（前編）
- Azure上に構成したSANLess Clusters構成の運用 – Azure Site Recovery編
- Azure上に構成したSANLess Clusters構成の運用 – Azure Backup編
関連サイト
井上和英氏 日本マイクロソフト株式会社
日本マイクロソフト株式会社
日本マイクロソフト株式会社について Azureについて |
