＊この記事は chillSAP 夏の自由研究2021 の記事として執筆しています。

はじめに

冒頭の自由研究の題材として、SAP Landscape Management Cloudを取上げてみたいと思います。

テクノロジーがクラウドにシフトし、必要な時に必要なだけ利用できるサービスが増えています。SaaS型で提供されるSAP Landscape Management Cloud（以下、LaMa Cloud）もその一つです。その名の通り、SAPのシステムランドスケープを管理するソフトウェアで、BTPとしては珍しいBasisの領域をカバーしています。2021年1月にリリースされた比較的新しいサービスのため、Free Trialを使って自由に研究（検証）してみたいと思います。イメージが付くようTechnicalな検証画面を含めているため、多少長めの記事になることご容赦下さい。

最後のまとめに記載していますが、Basis担当以外の方が扱えるシステムランドスケープ管理ツールとしても使えると思いますので、ご参考になれば幸いです。

SAP Landscape Managementの歴史

まずは簡単にLaMa Cloudの生い立ちを振返ります。その前身は2013年に登場したLandscape Virtualization Management（LVM）に遡ります。システムコピーやシステムリフレッシュの自動化機能を搭載して話題を集めました。2017年に名称をSAP Landscape Management（LaMa）に変更し、IaaS（AWS・Azure）上のSAPシステム管理機能が追加されました。2019年にはIaaSコストの管理機能を組込む予定とのプレビュー発表があり、2021年1月にようやく製品としてリリースされました。この製品がLaMa Cloudですが、従来のLaMaとは別製品となっている点がポイントです。
下図がLaMaとLaMa Cloudの違いです。SAPシステムの起動停止など両者共通で実行できる機能もありますが、前者は環境構築や運用の自動化に、後者はIaaSのコスト管理に焦点を当てており、できることがかなり異なりますので注意が必要です。

上図の説明から、LaMaでできた環境構築はLaMa Cloudでは行えないことが分かります。更なる詳細は製品ページに情報が掲載されていますのでここでは割愛します。

また、本記事では後者のLaMa Cloudにフォーカスしますが、前者のLaMaは以前のSAP Inside Track 2017/2019で取上げさせて頂きました。纏めた資料を公開頂いていますので、ご興味のある方は参照頂ければと思います。

SAP LaMa Cloudの機能

さて、LaMa Cloudの中身に入っていきます。前述のとおり、IaaSコスト管理を主要なコンセプトとしています。LaMa Cloudのポータルにログインし、そこから現状のIaaSコストのモニタリングや、IaaS含むSAPシステムの起動/停止、スケールイン/アウト（＝サーバー台数減少/増加）などのオペレーションを行います。オペレーションについては即時手動実行も、スケジュールによる自動実行も可能です。現時点で対応しているIaaSはAWSとAzureのみですが、近い将来GCPもカバーするそうです。

LaMa Cloud画面の見た目は下図のとおりです。トップページ（DashBoard）の前面にIaaSコスト情報が押し出されているのが分かります。

LaMa Cloudでできることを簡単に纏めると、以下の4点です。

①SAPシステムの起動/停止（手動/自動）

IaaS含むSAPシステム全体を停止し、クラウド運用コストを下げる。

（例：使わない土日はシステムを停止する。）

②サーバーのスケールイン/アウト（手動/自動）

指定したサーバーを増減させ、クラウド運用コストを効率化する。

（例：夜間処理の時だけAPサーバー全台をフル稼働させ、他時間帯は1台を残し停止する。）

③IaaSコスト削減額のシミュレーション

現状のコストと、上記①②を適用した場合のコストを比較し、コスト削減額を算出する。

（例：1か月、3か月、1年などのスパンでコスト削減効果をシミュレーションする。）

④IaaSコスト推移の分析

様々な観点からクラウド運用コストを分析する。

（例：開発/検証/本番環境ごとのコスト分析や、AWS/Azure環境ごとのコスト分析等。）

なお、Free Trialでは④の分析機能は提供されていないため、今回は①～③に絞り検証してみたいと思います。

SAP LaMa Cloudの機能検証

---

事前準備：SAPシステムのグルーピング

検証を行う前の事前準備として、Free Trialで用意されている10個のSAPシステムを分かりやすくグルーピングしておきます。Configurationタブで確認すると、最初は下図のように全て「Unassigned」になっています。

左メニューにあるGroup Managementから適当なグループ名を作成し、そこに各システムを割り当てていきます。今回は下記のとおりグルーピングしてみました。

本記事では、作成したDEVグループに割当てたD01システムだけを使っていきます。D01システムをプルダウン表示すると、DB×1台、AP×3台、CS×1台の計5台で構成されていることが分かります。

Landscapeタブを確認すると、作成したグループごとのシステム数とコストが確認できます。DEVグループにあるD01システムは、2.1K USD/月がIaaSコストとして発生していることがわかります。

以上で準備は完了です。

後続の検証では、前述した3つの機能に着目し検証していきます。

① SAPシステムの起動/停止
② サーバーのスケールイン/アウト
③ IaaSコスト削減額のシミュレーション

---

検証①：SAPシステムの起動/停止

この検証では、SAPシステムとIaaS(AWS)サーバーの停止を手動で行ってみます。

Landscapeタブから先ほど作成したDEVをクリックすると下図の画面が表示されます。D01システムの現在のステータスは「Running」です。右端にあるメニューから「Stop」を選択します。

停止の進行ステータスが表示されるので、数分待ちます。

現在のステータスが「Not Running」に変わり、D01システムが停止しました。LaMa CloudはSAPの停止と同時にIaaS環境のサーバー停止も同時に行ってくれます。

起動も簡単です。同様に右端のメニューから「Start」を選択し、数分後に起動してきました。

非常に単純ですが、以上が手動での起動停止の検証でした。一般的に1つのSAPシステムは複数のAPサーバーやDBサーバー等で構成されているため停止順序があり、IaaS環境のサーバー停止も個別に行う必要があります。LaMa Cloudはワンクリックでこれらを全て制御してくれるのでとても重宝しそうです。

なお、システム停止には3つのオプションがあり、紛らわしいので補足しておきます。

停止オプション 内容 Stop 即時強制停止。手動で起動、または次回の起動スケジュールが到来したら起動する。 Stop Gracefully 接続要求を処理したのちに停止。手動で起動、または次回の起動スケジュールが到来したら起動する。 Snooze Systems 接続要求を処理したのちに停止。設定された起動スケジュールが到来しても無視して停止を継続。手動でメニューからWake Up Systemsを選択したら起動する。

---

検証②：サーバーのスケールイン/アウト

この検証では、IaaS(AWS)サーバーをスケールインすることに主眼を置いていきます。

場面設定として、平日の利用頻度が少ない21:00～6:00の間、D01システムの３台のAPサーバーのうち２台を減少(スケールイン)させることとします。さらに、利用しない週末の土日はD01システム全体を完全停止させる（検証①の自動停止版）設定も加えてみます。スケールインとシステム停止という、2つの要素を含んだシナリオで進めたいと思います。

a) Patternの作成

まずはPatternを作成します。Patternとは、実行するアクションとスケジュールを設定する枠です。枠を作成し、それを必要なSAPシステムに割当てることでアクションを自動実行してくれます。

Patternsタブを開くと、予めサンプルのPatternが存在するので、それをコピーして新しいPatternの枠を作成します（もちろんゼロから新規作成も可能です）。今回はこの枠の中で、スケールインとシステム停止という2つのスケジュール設定を行っていきます。

作成するPatternの名称を入力します。ここでは「Scaled In Test」としました。

スクロールダウンすると、スケジュール設定箇所が出てきます。ここで、実行するアクションとスケジュールを設定していきます。日付をまたぐスケジュールは0：00を起点に2つに分ける必要があるようです。平日の21:00～6:00のスケールイン設定は、「Scaled In」を選択し、21:00～0:00（下図Time Slot1）と、0:00～6:00(下図Time Slot3)に分けて設定しました。システム停止設定については停止日時を定義するのではなく、起動日時で表現が必要になるようです。「Running」(下図Time Slot2)を選択し、月～金を選択して土日は除外することで、土日のシステム停止を実現します。

これで平日21:00～6:00のスケールインと、土日のシステム停止のスケジュール設定が完了しました。右側のPattern Schemeで、何曜日の何時にどのアクションが実行されるかを視覚的にも確認できます。

Patternsタブを見ると作成した「Scaled In Test」のPatternが存在しています。これでPatternの作成は完了です。

b) Patternの割当て

次に、作成した「Scaled In Test」のPatternを、D01システムに割当てていきます。LandscapeタブからD01システムの右端にあるメニューで、「Apply Pattern」を選択します。

どのパターンを割当てるか聞かれるので、先ほど作成した「Scaled In Test」を選択します。スケールイン対象のサーバーを選択するため、そのまま横にある「Select Instances」を選択します。

（冒頭で設定したシナリオに基づき）3台中2台のAPサーバーをスケールイン対象として選択します。これでPatternの割当ては完了です。

---

検証③：IaaSコスト削減額のシミュレーション

そのまま右側のSummary画面を見てみます。「Scaled In Test」のPatternを適用する前後でのIaaS環境コスト比較が表示されており、この時点でIaaSコスト削減額のシミュレーションが行われまています。ここでは593 USD/月が節約できることがわかります。

---

検証結果の確認

Patternを適用したのちしばらく放っておき、土曜日にD01システムの状態を確認してみました。D01システムのステータスは「Not Running」、スケールイン状態は「Yes」となっていました。ApplyしたPatternがスケジュールに基づき有効に機能したことが確認できました。

同様に月曜日にD01システムを確認したところ、システムも起動し、スケールアウト（＝APサーバー3台への戻し）も実行されていました。

余談ですが、LaMa Cloudにはスケジュール実行履歴を確認する画面がありません。実行履歴を確認したい場合は、現在のステータスをクリックして確認します。

この時点でDashBoardタブに戻ってみると、現在のDEVグループに存在するD01システムのIaaSコストが反映されていました。当初の2.1K USD/月 → 1.4K USD/月に削減され、当然ではありますがTCO削減効果は出ていそうです。

---

SAP LaMa Cloudの考察

ここまでサンプルで用意されたSAPシステムを使い、下記3つの機能を簡単に検証してきました。

① SAPシステムの起動/停止
② サーバーのスケールイン/アウト
③ IaaSコスト削減額のシミュレーション

優れていると感じた点

・提供機能がコンパクトなのでスムーズに内容を理解できた点。

・UIがシンプルなのでマニュアルを読まずとも直感的に操作できた点。

AWSとAzure（将来的にGCP）をサポートするため、マルチクラウドのIaaSコストをこのLaMa Cloudを起点として統合的にモニタすることもできそうです。

多少もどかしいと感じた点

・SAPシステム内のどのサーバーが起動 or 停止しているのか細かな確認まではできない点。

・IaaSコスト表示はUSD or EURのみで日本円への通貨換算が個別に必要になる点。

Road Map Explorer上では今後も継続的に機能追加・改善が予定されているので、引続き長い目でウォッチしていたいと思います。

今回はFree TrialなのでSAPシステムをすぐに使える状態でしたが、実際の現場ではLaMa CloudとSAPシステムの接続作業やLaMa Cloudのオペレーション権限設定など、事前のセットアップ作業が必要になってきます。Administration Guideを参照しながらのセットアップ作業となりますが、そこまで複雑ではなさそうです。

気になる価格ですが、記事をリリースした時点でのサブスクリプション価格は￥37,461/月でした。接続するSAPシステムが多ければ多いほど安くなる価格体系になっています。

おわりに

2021年1月にリリースされたSAP LaMa Cloudを自由に研究してみました。実はこのLaMa Cloud、2019年にプレビュー発表があった当初は、Cloud Operation Optimizerという名称になる予定でした。最終的にLaMaになぞらえLaMa Cloudとなったことで、システムランドスケープ管理と言えばLaMaシリーズ、というシンプルな認識が持てるようになった気がします。今回の研究の成果から分かった確かなことは、SAPシステムランドスケープ管理の一部はオープンになり、Basis担当以外のどなたでもシステム管理に携われる状況になってきているということです。新たなテクノロジーの発展による恩恵ですが、このような変化を敏感に感じ取り、現場ビジネスへの取込み可否を素早く検討できるようでありたいと感じた夏でした。

長文を最後までお読み頂きありがとうございました。