SAPシステムの起動停止自動化をAWS Systems Managerで実現

最近のブログでは、ビルドとオペレーションの両方におけるDevOps for SAPの利点について説明し、AWS Chatbotを使ってStop/Startを開始する方法を探りました。今日は、Linuxオペレーティングシステムにインストールされた分散SAP HANAランドスケープを開始・停止するAWS Systems Managerベースのソリューションをオープンソースで提供することで、SAP運用のためのAWSネイティブサービスの利用を迅速に行うことができるようにします。

このソリューションは、AWS CloudFormationテンプレートを使用して5分以内に導入することができます。このソリューションは、アプリケーションを意識したSAPワークロードとEC2インスタンスの停止と開始を容易にし、成功または失敗を電子メールアドレスに通知します。前提条件は、インスタンスがAWS Systems Managerでマネージドインスタンスとして設定されていることと、Readmeに記載されているタグ付けが行われていることです。

このソリューションが開発された理由に触れていきましょう。

利用事例

全世界で5000を超えるお客様が、既存のSAPワークロードをそのまま移行したり、AWSへの移行の一環としてSuite on HANAやSAP S/4HANAの導入を検討したりして、SAP on AWSのご利用を始めています。

これらのクラウドベースのSAPデプロイメントの総所有コストを評価する中で、多くのお客様は、AWSが提供する柔軟な商用モデルを検討し、Savings Plans、Amazon EC2 Reserved Instance、および24時間365日必要ではないシステムのためのAmazon EC2 On-Demand Pricingを使用した稼働時間の短縮を組み合わせて、コストを削減する機会を特定しました。

多くのお客様にとって、開発、テスト、トレーニング、サンドボックスインスタンスなどの非本番SAPシステムは、常時使用されるものではありません。これらのシステムの一部または全部は、稼働時間の要件が低かったり、プロジェクトサイクルの中での役割が短かったりする場合があり、そのような場合には、オンデマンド価格がよりコスト効率の高いオプションとなることがあります。

例えば、r5.16xlargeのEC2インスタンスは、us-west-1で週に67時間以下しか稼働していませんが、オンデマンド価格を利用すると、最も費用対効果の高い価格設定モデルよりも安くなります。下の図でコストの比較をご覧ください。また、AWS Pricing Calculatorを使って、インスタンスタイプとリージョンについて同様の比較を行ってください。

稼働時間をコントロールすることはコスト削減につながりますが、夜間や週末など使用されていないときにEC2インスタンスを停止するという運用上の課題があります。また、分散された環境では、アプリケーションを意識した停止/起動プロセスが必要になります。例えば、SAPアプリケーションサーバのインスタンスは、対応するデータベースインスタンスが稼働するまで起動できません。また、シャットダウン時に、最初にデータベースアプリケーションをクリーンに停止せずにデータベースホストを停止すると、データベースが破損するリスクが高まります。

お客様がこの課題にどのように取り組むかについては、しばしば進化が見られます。プロジェクト段階では、クラウドの設定や運用モデルに慣れるまでは、SAP Basis管理者が個々のシステムにログオンして複数の起動・停止コマンドを実行するという伝統的なアプローチを取ることも珍しくありません。これは長時間の手動プロセスであることに加え、エラーが発生しやすく、適切な管理が行われていない場合にはリスクが生じます。

次によく見られるのは、cronでスケジュールされたスクリプトやタグベースのシャットダウン/スタートアップスケジュールを組み合わせて使用する方法です。この方法では、手動のステップを減らすことができますが、インスタンス間の依存関係を調整するという課題があり、システムが使用されているときだけにシステムの稼働時間を最小限に抑えることができません。また、手動での設定作業、スケジュールの変更、視認性などの問題もあります。

最後に、SAPランドスケープの管理に既製のソリューションを採用しているお客様がいます。このアプローチは、その製品が幅広い運用機能を提供し、SAPやAWSの機能と統合されている場合には意味があります。評価の際には、ライセンス、ホスティング、導入、サポートに関するコストが考慮されていることを確認する必要があります。

これらのソリューションの限界を理解した上で、私たちは別のソリューションにたどり着きました。私たちが開発したAWSクラウド・ネイティブ・ソリューションは、2つの部分に分けられます。

SAP向けAWS Systems Manager自動化ドキュメント（ランブック）
すべてのインスタンス操作（インスタンス起動を含む）を中央制御機構に移す、SAPを意識したクラウドネイティブなシステム起動/停止方法。
実行および通知フレームワーク
技術チームへの依存度を除去または軽減しつつ、必要なコントロールと可視性を確保するためのオプション。

結果として得られたソリューションは、AWSに移行してからもDevOps for SAPの旅を続けている、多角的なグローバルアグリビジネス協同組合であるCHS Inc.などのお客様に利用されています。CHS社は、この自動化を活用して、業務時間外に非本番系SAPシステムを人手を介さずにシャットダウンしました。CHS社は、業務時間外に非本番系システムをシャットダウンすることで、すぐに大幅なコスト削減を実現しました。

ソリューション

先ほど説明した2つの要素について、もう少し詳しく見てみましょう。

SAP向け AWS Systems Manager自動化ドキュメント

AWS Systems Managerは統一されたユーザーインターフェースを提供しており、複数のAWSサービスの運用データを閲覧したり、AWSリソース全体の運用タスクを自動化することができます。システム管理の経験があるオペレータであれば、事前に定義された自動化プレイブック、簡単なbashスクリプトを書けるRunCommandモジュール、そして時折発生するディシジョンステップを組み合わせて、簡単に設定できるはずです。

各ステップは、単一のアクションまたはステップを実行するように設計されており、要素の構築、連鎖、再利用を可能にするだけでなく、可視性と制御性を向上させます(これは後にフレームワークの重要な要素となります）。

RunCommandとbashスクリプトを選択したのは、SAP管理者の馴染みのある「コマンドライン」での使用に沿ったものだからです。また、必要な設定と入力を最小限にするために、ホスト上のクエリを使用して実行中のものを特定し、コマンドを発行するために必要なパラメータを導き出しました。また、実行内容を関連付け、インスタンスを識別するために、SSM Automation ドキュメントのパラメータ、出力、およびインスタンスタグを使用しました。

ドキュメントをデプロイした後は、マークアップテキストの説明を確認して、手順をより詳細に理解することができます。

例として、start アクションが選択された場合に実行されるステップを以下に示します。

名前	アクション	説明
START_QUERY_AWS_DBInstanceId	aws:executeAwsApi	EC2 Describe Instanceを実行して、特定のSIDのDBサーバーを特定するためのタグ値を照会する。
START_AWS_DBInstanceId	aws:changeInstanceState	インスタンスのdesired stateを “running “に変更する
START_DB_HANA	aws:runCommand	sapcontrol startを呼び出し、システムが動作しているかどうかを検証する短いバッチスクリプト。

次のコードスニペットは、sapcontrolコマンドの実行に使用されるbashスクリプトの例を示しています。Note 1763593 – Starting and stopping SAP system instances – startsap/stopsap are deprecated (SAP SユーザIDが必要です) を参照してください。

#!/bin/bash
SAPProfile=`grep -o 'pf=[^[:space:]]*' /usr/sap/sapservices | grep _HDB`
SID=`echo ${SAPProfile} | awk -F "/" '{print $4}'`
SYSTEMNO=`echo ${SAPProfile} | awk -F "/" '{print $7}' | awk -F "_" '{print $2}' | sed 's@^[^0-9]*\([0-9]\+\).*@\1@'`

echo "Running /usr/sap/hostctrl/exe/sapcontrol -nr ${SYSTEMNO} -function GetSystemInstanceList"

/usr/sap/hostctrl/exe/sapcontrol -nr ${SYSTEMNO} -function GetSystemInstanceList
if [ $? -eq 0 ]
then
    echo "There is a system here, I am going to use start"
    /usr/sap/hostctrl/exe/sapcontrol -nr ${SYSTEMNO} -function StartWait 600 2
else
    echo "There is no service running for instance number ${SYSTEMNO} "
    exit 1
fi

/usr/sap/hostctrl/exe/sapcontrol -nr ${SYSTEMNO} -function GetProcessList
if [ $? -eq 3 ]
then
    echo "`date +%F\ %T`: The HANA Database Started Successfully"
else
    echo "The return code was $? "
    exit 1
fi

ランブックの実行と通知フレームワーク

追加機能として、システムの重要度に合わせて適切なセキュリティ管理とガバナンスを用いて、Systems Manager Runbookをどのように起動するかを検討します。

外部ソースからのアクセスを許可する場合は、IAMのベストプラクティスに従い、最小の権限を持つロールを使用してドキュメントを実行するようにしてください。

まずは手動で自動化を実行し、ドキュメントに慣れることから始めます。次のステップとして、EventBridgeイベントルールのターゲットとしてランブックを構成するAmazon Eventbridgeパターンなどのトリガーを使用したスケジューリングのオプションを検討します。オプションや詳細については、Systems Managerのドキュメントを参照してください。

スケジュールが固定されていない場合、これらのメカニズムはオンデマンドやアドホックな使用のために拡張することができます。電子メールやAWS Chatbotなどの他のサービスと統合することで、ランブックを実行し、ステータスに関する通知を受け取ることが可能です。より複雑なフレームワークを設計して、外部の承認プロセスやインスタントメッセージングサービスと連携させることも可能です。

提供されているCloudFormationテンプレートでは、Amazon EventbridgeとAmazon SNSを使ったシンプルなソリューションを採用しています。Amazon Eventbridgeはルールを使ってランブックのステータスの変化を識別し、完了または失敗したときに、AWSコンソールのランブック実行詳細へのリンクを含むメールを送信します。

導入手順

このソリューションをデプロイするためのCloudFormationドキュメントは、GitHub (/aws-samples/aws-ssm-automation-for-start-stop-sap)で公開されています。環境の設定方法や作成されるサービスについては、READMEをご覧ください。

今後の展開

このドキュメントをそのまま使って頂くのも良いですが、SAPの運用環境で使用するためのオプションは無限にあります。

このドキュメントは、以下のように簡単に変更を行うことができます。

異なるデータベースタイプを扱う
WindowsワークロードのためのPowerShellコマンドの使用
クラスタ化された高可用セントラルサービスやデータベースのセットアップのための追加手順を盛り込む
バックアップの完了を確認するなど、起動とシャットダウンの手順に事前または事後のステップを追加する

同様のスタイルのドキュメントとフレームワークを以下のように使用できます。

データベースとファイルシステムのバックアップの調整
ログ機能を使った日常的なチェックとハウスキーピング
パフォーマンステストのためのインスタンスのサイズ変更やストレージ特性の変更

実際に操作してみると、AWSのAPIコールとOSのコマンドのほとんどの組み合わせが可能であることがわかります。また、AWS Lambdaに依存する手順を組み込むことも可能です。また、ネイティブサービスを使った運用活動の自動化について支援が必要な場合は、AWS Professional Services Global SAP Specialty Practiceの利用をご検討ください。

翻訳はPartner SA 松本が担当しました。原文はこちらです。

Amazon Web Services ブログ