ロシア企業向けのMSAzureに基づくSAPHANAの導入後の7つのレッスン

10年以上前、Microsoftは幅広いユーザーにAzureプラットフォームの提供を発表しました。この間、多くの企業がクラウドインフラストラクチャを利用して現在のIT問題を解決したいと考えていました。そのうちの何人かは、クラウドへのシステムの展開に関するアドバイスを求めて私たちに連絡しました。しかし、時が経ち、現在、ビジネスはSAPHANAのようなリソースを大量に消費するシステムをクラウドに配置する可能性を検討しています。次に、すでにいくつかの同様のプロジェクトを実装しており、MSAzureクラウドでのSAPシステムの展開をより成功させることができるこれらの観察結果を共有する準備ができています。一部の観察結果は発見にはなりませんが、クラウドプラットフォームでのいくつかのアプローチの適用可能性を示したかったのです。学んだ主な教訓を皆さんと共有したいと思います。

＃1：クラウドを使用してITアーキテクチャを一貫して最適化する

生産システムの移行の一環として、テストおよび開発プロセスでのリソース消費量が多いという問題に直面しました。最終的に、テストおよび開発環境にこれほど多くのリソースが必要な理由と、生産システムによるインフラストラクチャリソースの消費を最適化する方法について考えました。



SAPシステムを構築するための推奨されるアプローチは、SAP QuickSizer計算機を使用した必要な容量の評価に基づいています。これまで、SAPの手法は、クラウドテクノロジーの特性を考慮しない標準的なアプローチに基づいています。お客様から要件を受け取り、初期データをSAP見積もりツールに入力し、予備的なランドスケープ構成を受け取りました。従来のインフラストラクチャの場合、そこで停止して機器の購入に進むことができましたが、私たちの場合、クラウドを利用することができました。クラウドでは、リソースはいつでも増やすことができるため、Estimatorに含まれている余分なリソースの予約を放棄し、パフォーマンスの低いマシンを展開しました。これにより、コストを削減できました。また、負荷が増加すると、SAP仮想マシンのパフォーマンスを数分で常に向上させることができます。



マイクロソフトは、MシリーズVMでのみSAPサポートを提供しています。開発の初期段階でサポートレベルの点で実稼働環境と同様のテストリソースを使用することは、私たちにとって冗長であるように思われました。



同時に、EシリーズのマシンはMシリーズと同様の特性を備えていますが、コストは大幅に低くなっています。その結果、テストマシンをEシリーズに交換しました。この交換の欠点は、テスト環境でのシステムの運用に対する責任がプロバイダーからインテグレーターに移ることです。これにより、インテグレータはSAPの専門知識を持っている必要があります。

＃2：リソース消費を節約する方法

MS Azureを使用すると、1年または3年間の同時前払いでリソースを予約するときに、大幅に節約できます。



多くの場合、初期段階では、製品の開発とテストはビジネスまたは請負業者の開発者側にある多くの変数に関連付けられているため、顧客は生産的なシステムの発売日を正確に見積もることができません。



たとえば、いずれかのプロジェクトの立ち上げ時に、お客様の現在の計画に基づいて、すべての環境の同時展開を計画しました。よくあることですが、開発にはビジネスとのより長い調整が必要であり、その結果、生産開始が数か月遅れました。



この例では、プリペイドリソースを予約すると、顧客はかなりの金額の資金を失うことになります。もちろん、リソースを予約する必要がありますが、プロジェクトの後の段階で、生産システムの大部分が安定し、リソース消費の観点から開発が予測可能になったときに、これを行う方が効率的です。多くの場合、コンピューティングリソースを3年間予約すると、従量課金制の支払い方法と比較して約70％の節約が得られます。

＃3：Azureリージョンの選択方法

Azureには、さまざまなリソースホスティングリージョンがあります。リージョンを選択するための主な基準の1つは、エンドユーザーからのインフラストラクチャの遠隔性です。これは、システムの応答と、統合およびエンドユーザーの作業に影響を与えます。



2つ目は、それほど重要ではない基準は、特定の地域のサービスのリストです。



地域によっては一部のサービスをご利用いただけます。多くの場合、サービスは公式リリース前のプレビューとして提供されます。一部の地域では、新しいテクノロジーの導入が迅速であり、いずれかの新しいサービスのテストが可能です。すべての地域で、すべての仮想マシンシリーズを使用できるわけではありません。

私たちの実践では、アクセス速度の比較はしばしば西ヨーロッパ地域の利点を示しています。これは、サーバーとクライアントがロシアのヨーロッパ地域にある企業で特に顕著です。それぞれの特定のケースで、特にデータセンターと顧客が極東にある場合は、データセンター（または顧客がいる地理的地域）からの遅延をチェックして、最適なAzureリージョンを選択するのが理にかなっています。











Azure Latency Testなどのサービスを使用すると、データセンターネットワークから各Azureリージョンへのプロアクティブな遅延テストが可能になります。モスクワオフィスからテストする際に、上記のサービスを使用して待ち時間を測定した結果の例：

＃4：地上ベースの方法をクラウドインストールに適用する方法

移行のたびに、クラウドの従来のインフラストラクチャで実証された従来のソリューションをどのように使用するかを自問します。特に、ソリューションを準備する際には、技術的に正しいソリューションを開発するためにベンダーの推奨事項に依存しています。 SAP HANAプロジェクトも例外ではなく、推奨事項とベストプラクティスのプリズムを通過します。



プロジェクトの1つで、ソリューションの最初の段階を実装するときに、WindowsベースのJumpサーバーが展開されました。初期開発フェーズのコストを最適化するために、非生産的な環境のニーズに合わせて同じサーバーにNFSサーバーを展開しました。これにより、開発者の現在のニーズがカバーされ、リソースを大幅に節約できました。



時間が経つにつれて、環境とリソースの要件が増大し、NFSサーバーがすべてのタスクを処理しました。徐々に、プロジェクトの枠組みの中で、最初のVMのリソースの枯渇に近づきました。 MS AzureのVMリソースは数分で増やすことができますが、同時にサーバーの障害耐性の要件が増えたため、より大規模な再構成を検討する必要がありました。



実装には、Linuxサーバー、DRBDサービス、および可用性セット機能が使用されました。これにより、NFSクラスターのノード間のデータ複製の問題が解決され、2つのクラスターノードのいずれかに障害が発生した場合の可用性が向上しました。







ちなみに、クラスターソリューションの実装から数か月後、NetApp FilesサービスがAzureに追加されました。これにより、NetAppアレイを利用できますが、Pay-As-You-Goモデルによって料金が支払われます。

＃5：VMスケジュールを自動化する方法

クラウドインフラストラクチャを使用する場合、コスト削減を最大化するために使用できる追加のメカニズムを分析することは常に理にかなっています。



私たちの場合、システムは営業時間中にテストされます。従来のインフラストラクチャサーバーのダウンタイムは主にエネルギー料金の増加につながりますが、クラウドでは、不採算のサーバーは容量を借りるために資金を消費します。テストサーバーと開発サーバーの負荷グラフを評価したところ、圧倒的多数の開発者とテスターが平日の8時から20時までシステムを使用していることがわかりました。











非生産的なシステムのロードスケジュールが予測可能で周期的である場合、スクリプトを使用してVMのオン/オフを自動化しようとします。 Azureには、自動シャットダウン、自動化アカウント、クラウドシェルなどのツールがいくつかあります。すべてが私たちに適しているわけではありません。自動シャットダウンはVMをシャットダウンすることしかできないため、除外されました。 Cloud Shellも関与していませんでした。追加のスクリプトを準備し、スケジュールを作成し、冗長性の存在下でこれらすべてを安全な場所に保存する必要があるため、節約が最小限に抑えられました。







私たちの場合、より柔軟なメカニズムが使用されます。 Automation Accountsは、Runbookの形式で既製の実用的なソリューションを提供し、スケジュールに従って仮想マシンのオンとオフを切り替えることができます。







それぞれのリソースのグラフを作成し、Runbookをロードして、グラフとリソースの間にリンクを形成しました。







その結果、総所有コストをさらに削減しました。当初、これらのツールは実装が計画されていませんでしたが、予備運用段階ですでに実装されていました。



スケジュールの変更は数分で完了します。最初に新しいスケジュールが作成され、次に生成されたスケジュールが必要なリソースに関連付けられます。必要に応じて、多数の変更がある場合は、CloudShellを使用してこのプロセスを自動化することができます。

＃6：リソース消費の監視

従来のデータセンターの場合、残念ながら、ヘルスモニタリングとリソース消費は通常バックグラウンドにフェードインしますが、Azure内ではこれを許可することは望ましくありません。リソース消費の履歴に関する情報は、コスト最適化の可能性に直接影響します。また、リソースを早期に予約する場合は、アーキテクチャの改善の合図として使用できます。

＃7：フォースマジュール保険

多くの企業は、以前は規制当局の標的となっていた閉塞の恐れがあるため、ITシステムをクラウドリソースに配置することを警戒しています。他のリスクと同様に、これもシステムを設計するときに考慮に入れることができます。プロジェクトでは、原則として、クラウドからお客様のデータセンターへのシステムバックアップの毎週のアンロードを実装します。これにより、万が一システムを確実に復元できるようになります。これに加えて、マルチクラウドインストール戦略を使用します。これにより、アクセスが制限された場合に、リソースへのアクセスなしに放置されないようにすることができます。このシナリオでは、代替のクラウドプロバイダーがメインクラウドのDRサイトとして使用されます。これにより、大規模な障害が発生した場合にシステムを復元できます。



No. 7+個人データの処理

私たちの仕事の中で、私たちは外国のクラウドリソースを含むシステムで個人データを保存および処理する方法へのアプローチを形成しました。このアプローチの実装は、規制当局の要件を考慮して実行する必要があることに注意してください。このトピックは非常に広範囲にわたるため、コメントに対応する関心があることに気付いた場合は、次の記事で取り上げようとします。

結果

この記事では、MSAzureクラウドでSAPをホストするためのいくつかの実践的なレッスンを確認しました。明らかに、トピックは非常に広範であり、クラウドに移行するときに可能な最適化の一部にしか触れることができませんでした。



どんなニュアンスに遭遇しましたか？コメントであなたの経験を共有していただければ幸いです。