Cloud ALM触ってみたら、もうこれでよくね？ってなった話

はじめまして、BeeX 山本です。
今回がBeeX Tech Blogの記念すべき初投稿となります。(👏👏👏)
内容は表題の通り「SAP Cloud ALM」についてです。
※本記事ではこれ以降、SAP Cloud ALM を Cloud ALM と略して記載します。

はじめに
SAP Cloud ALMとは
画面で見るCloud ALM：実機で触ってみた所感
関連記事
まとめ
参考リンク

はじめに

皆さんは Cloud ALM についてどれくらい知っていますか？
最近SAPがやたら推してる気がするけど、「結局これ、何ができて何が嬉しいの？」と思っている方も多いはず。

そんな皆さんのために、社内のCloud ALM環境をざっくり触ってきた私が所感をまとめます。このブログを通して皆さんのCloud ALMに対する解像度を上げる手助けができればと思っています。

SAP Cloud ALMとは

概要と位置づけ

Cloud ALM（Application Lifecycle Management）は、SAPが提供するクラウドネイティブなALM（アプリケーション運用・導入を支える仕組み）です。
ざっくり言うと、「Solution Managerっぽいことを、クラウドのSaaSで“軽く・早く”やるやつ」です。

SAP Solution Managerとの違い

上でSolution Managerっぽいことを～って書きましたが、Cloud ALMは「Solution Managerがクラウドに引っ越したやつ」ではありません。後継っぽい立ち位置ではありますが、実態は新しい基盤で作り直された別ソリューションと思うのが近いです。比較はこんな感じ。

項目	SAP Solution Manager	SAP Cloud ALM
アーキテクチャ	オンプレ（SAP NetWeaver/ABAPとJava）	SaaS（SAP BTP上で提供されるクラウドサービス）
主な対象	オンプレ／ハイブリッド中心	クラウド中心
メンテナンス	顧客責任	SAPが管理
導入スピード	設計・構築・設定がそれなりに必要で大変	使い始めは比較的スムーズ
サポート期限	2027年終了	継続的にアップデート

SAP Solution Manager 7.2 のメインストリームメンテナンスは 2027 年 12 月 31 日に終了します。

Cloud ALMが対応しているSAPシステム

対応しているシステムはこんな感じです。

SAP S/4HANA Cloud（Public Edition / Private Edition）
SAP S/4HANA（オンプレミス）
SAP BTP 系（Cloud Foundry / Kyma / ABAP環境など）
SAP SuccessFactors、SAP Ariba など主要クラウドソリューション etc....

公式に Supported Services and System Types の一覧があるので確認してみてください。

ライセンス体系

Cloud ALMには追加のライセンス費用がかかりません。Enterprise Support, cloud editionを含むSAP Cloud Serviceサブスクリプション、SAP Enterprise Support、またはProduct Support for Large Enterprisesをお持ちの場合は、カスタマ番号ごとに1つのCloud ALMテナントを無料で利用できます。

さらに、2026年1月21日より、すべてのCloud ALMテナントの基本メモリサイズとメモリ拡張が8GBから24GBに増加しました。

画面で見るCloud ALM：実機で触ってみた所感

Cloud ALMは、ざっくり「Implementation（導入）」、「Operations（運用）」、「Service（サービス）」の3領域があります。

今回はそのうち、社内環境で実際に触れた「Implementation（導入）」と「Operations（運用）」の2領域を、所感ベースでまとめていきます。

Implementation（導入）：移送管理まわり（設定～本番反映の流れをどう扱えるか）

Operations（運用）：ジョブ監視／ヘルス監視など（普段の運用でどこまで見えるか）

※S/4HANAとCloud ALM接続方法やこのブログに記載した検証内容の詳細については別のブログにまとめます。
※検証にあたってCloud ALMに接続した環境は、自前のオンプレミスのS/4HANA 2022です。
※「Service（サービス）」は、SAPの各種サービス（例：GoingLive Check など）を受ける際に、結果や指摘事項などを関係者で管理しやすくするための領域です。読んで字の如く、さくっと検証できるような内容ではないため、今回は割愛してます。

Implementation（導入）：移送管理

Implementation（導入）タブはこんな感じです。結構たくさんタイルがありますね。
今回はさくっと検証できそうな感じがした「フィーチャ」という機能を使ってみます。

フィーチャとは

公式では下記のように説明されています。
・ランドスケープ全体に機能を展開するための「乗り物」（どこまで進んだか、履歴も追える）
・様々なソフトウェア要素（移送など）をまとめて扱うオーケストレーター
・どの環境が対象か／本番反映の承認なども含めたコンテナ（ひとまとまりの単位）

とりあえずは移送を入れる箱みたいなものという認識で良いと思います。

いざ検証

やったことはこんな感じです。
①開発機で作った移送依頼をフィーチャに紐づけ
②リリース
③本番デプロイ（本稼働承認まで）

①開発機の移送をフィーチャに紐づけ

フィーチャの移送タブで開発機の移送依頼に紐づけができます。1つのフィーチャに対して、複数の移送依頼が紐づけ可能です。
この時点ではステータスが「変更可能」になっていて、まだ開発側で調整できるフェーズとなっていることが分かります。
※フィーチャ画面のヘッダが隠れてしまっていたので、この時点のステータス部分のみを抜粋して載せておきます。

②リリース実施

①の画面で「リリース」を押して数分待つとステータスが「リリース済」になりました。ブラウザ上でポチポチしたらリリースできちゃったので割と感動。でも検証時は疑っていたのでちゃんとGUIからも確認しました。（笑）
リリース済みか否かがWeb画面上で手軽に確認できるのは地味に助かるポイントかもですね。
あと、リリースすると左上のフィーチャ自体のステータスが「テスト中」に変わっていることが分かると思います。

③本番へのデプロイ（本稼働承認まで）

②の画面で右上の緑色のボタン「成功テスト確認」を押すとこちらの画面になり、左上のフィーチャのステータスが「テスト成功」へと変更されます。

さらに上の画面で右上の「本稼働承認」を押すと、フィーチャのステータスが「本稼働可能」に変化し、晴れて本番環境へのデプロイが解禁されるという流れになっています。

Implementation（導入）：所感

今回はフィーチャにしか触れていませんが、フィーチャに関してはかなり良い機能だなという印象でした。移送を軸に進捗が見えて、複数の移送が絡む変更でもフィーチャ単位で追いやすい。そのため、これまでより管理がラクになりそうです。
個人的にお気に入りなのは、ボタン操作で Release → Deploy まで進められるところです。

さらにフィーチャにはトレーサビリティ機能もありまして、添付の画面のようにフィーチャを俯瞰しつつ進捗を一元管理できたりもします。

使いこなせると、導入まわりの心強い味方になりそうですね♪

Operations（運用）：ジョブ監視／ヘルス監視

Operations（運用）タブはこんな感じです。今回は、この中のジョブおよび自動化の監視とヘルス監視を見ていきます。

ジョブおよび自動化の監視

ジョブおよび自動化の監視のタイルをクリックして、概要画面に移動するとCloud ALMに接続しているシステムごとにタイルが表示されます。
システム名が<SID>.<Client number>という表記になっているのがポイントです。 Cloud ALMでは監視したいクライアントを個別に登録していくため、このような表記になっています。

S4A.100のタイルをクリックすると、こんな感じでそのシステム（クライアント）に紐づくジョブ一覧が表示されます。一覧ではジョブ名だけじゃなく、実行ステータス、開始遅延、実行時間あたりが並んでいて、ジョブが正常に回ってるかをサクッと確認できます。
さらに、気になるジョブがあれば、行の右端（>）やジョブ名をクリックし、実行履歴やエラー内容まで追える流れです。

上で説明したジョブ詳細画面はこんな感じです。

ちなみにジョブがエラーになると、With Technical Exceptionsに一件が計上され、概要画面のタイルが赤くなります。

対象ジョブについてアラート設定がされている場合には、アラートも出ます。

ヘルス監視

「ヘルス監視」のタイルをクリックすると、S/4HANAやS/4HANA Cloudなどサービスタイプ単位でタイルが並びます。今回は S/4HANA を開いてみます。

S/4HANAの画面に遷移すると、そのサービスタイプとして登録されているシステムの一覧が表示されます。

そこから特定クライアントの画面に入ると、こんな感じでメトリクスがタイル表示されます。 ABAP系のメトリクスはもちろん、OS系（CPU／メモリ／ディスク使用量）も一通り収集されていて、とりあえずは困らなさそう感はありました。
サポートされるメトリクスの一覧は公式がまとめてくれているので確認してみてください。

これらのメトリクスは閾値の設定ができ、警告/クリティカルの2段階が存在していました。運用の温度感に合わせて柔軟に調整できそうなので、そこが良いなと思いました。

通知設定をすれば、閾値超過でメールも飛ばせます。
アラートの通知先には、SlackやTeamsなど対応しているため、プロジェクトに合わせて選択できそうですね。

Operations（運用）：所感

これまで色々画面を遷移して機能を見てきたんですが、冷静に考えるとCloud ALM側で大した設定をしてないんですよね。（笑）
一度システムをCloud ALMに接続してしまえば、あとは自動でデータが送られ、監視の土台が出来上がります。この立ち上げの速さは正直かなり強いと思いました。
標準的かつ最低限の監視をとりあえず動く状態に持っていくまでの時間は、今までより格段に短くなるんじゃないでしょうか。

Cloud ALM、恐るべし。

本記事の続編として、Cloud ALM の アラート通知の設定手順 を別記事にまとめました。
良かったらこちらも見てください！

techblog.beex-inc.com