Amazon Web Services ブログ

AWS Systems ManagerとAmazon AthenaでSAPランドスケープのインベントリを保守する

はじめに

SAPシステムの効果的な保守と運用は、意思決定をサポートするためのシステム情報へのアクセスに依存しています。例えば、SAPカーネルのバージョン、インストールされたABAPコンポーネント、または単にアクティブなSAPシステムに関する情報を調べることは、IT運用活動の一部となっています。さらに、これらの調査は、例えば、SAPカーネルとオペレーティングシステムカーネルの両方の特定のバージョンに一致するシステムをリストアップするなど、一般的なものより複雑な場合もあります。

SAP管理者は保守活動の計画に役立てるために、システムのインベントリーを保有ことは珍しいことではありません。インベントリデータを保存する典型的な場所は、テキストファイルまたはスプレッドシートです。これらのデータソースはインベントリデータへの素早いアクセスを提供しますが、更新やチームメンバーとの共有が困難な場合があります。インベントリを保持するために、より精巧な代替案は、SAPデータベースから直接データを抽出したり、SAPトランザクションをリモートで呼び出したりすることがありますが、SAPランドスケープが成長すればするほど、これらの方法を拡張して運用するのは難しくなります。Solution ManagerのようなSAP製品は、最新のインベントリデータを保持していますが、データのクエリはユーザーインターフェース(UI)またはアプリケーションプログラミングインターフェース(API)を介して行われることになります。
サードパーティの構成管理ツールはこのようなデータをキャプチャーするのに役立つかもしれませんが、AWSのお客様はよく費用対効果が高くて、スケーラブルで可用性の高いクラウドネイティブなソリューションを求めて、追加のインフラやソフトウェアを導入する必要がなく、実装やメンテナンスの労力が少なくて済むことを望んでいます。このブログでは、 Amazon EventBridgeAWS Systems Manager InventoryAmazon AthenaとSAP Host Agentを使用して、自動更新の形で、そして標準SQLでクエリ可能なSAPランドスケープのインベントリを保守する方法を紹介します。

ソリューションの概要

下記の図は、Amazon Athenaを使用して照会できるSAPランドスケープインベントリを作成するために使用されるAWSサービスとコンポーネントを示しています。

Solution architecture

SAP Host Agentのインスタンス検知とインベントリー機能を活用し、ランドスケープ内の各SAPサーバーから情報を抽出します。Amazon EventBridgeとAWS Systems Manager Run Commandは、定義されたスケジュールでSAP Host Agentを呼び出す自動化をサポートします。自動化はまた、カスタマイズされたスクリプトを呼び出して、AWS Systems ManagerにJSON形式のインベントリファイルを作成します。インベントリJSONファイルは、AWS Systems Managerエージェント(SSMエージェント)によってピックアップされ、AWS Systems Managerインベントリが作成されます。

AWS Systems Manager Resource Data Syncは、インベントリデータをAmazon Simple Storage Service (Amazon S3)バケットに送信します。最後に、AWS Systems Managerインベントリは、Amazon S3バケットに保存されたインベントリデータを準備し、Amazon Athenaより標準SQLでクエリできるようにします。

AWS Systems ManagerでSAPランドスケープのインベントリの作り方をデモするために、以下のシステムを使用しました。

  • SAP (A)SCSが稼働するEC2インスタンス
  • SAP ERS、SAP gatewayとSAP web dispatcherが稼働するEC2インスタンス
  • SAP PASが稼働するEC2インスタンス
  • Oracleデータベースが稼働するEC2インスタンス

デモ目的で、これらのEC2インスタンスのIAMインスタンスプロファイルには、AWSが管理するポリシーであるAmazonS3ReadOnlyAccessAmazonSSMManagedInstanceCoreが含まれています。これによって、EC2インスタンスがAmazon S3と対話したり、AWS Systems Managerサービスのコア機能を使用したりすることを可能にします。

このSAPランドスケープ内のすべてのシステムは、Linuxオペレーティングシステムを使用し、以下のソフトウェアパッケージがインストールおよび構成されています。

  • SAP Host Agent 7.2
  • AWS SSM Agent version 3.1
  • AWS CLI
  • jq (OSコマンドの出力をJSON形式に解析する)
  • dos2unix (DOS/MAC形式のプレーンテキストファイルをUNIX形式に変換する)

データ収集処理の範囲を制御するために、各EC2インスタンスには以下のようなタグが設定されています。

  • sap:inventory = yes
  • sap:sid = <SAP SID>

<SAP SID>はお使いのSAPシステムの対応するSIDに置き換えてください。

1つのAmazon S3バケットを使用して、以下を保存します。

  • シェルスクリプト
  • SSMインベントリ同期データ
  • Amazon Athenaのクエリ結果

ウォークスルーに移る前に、SAP EC2インスタンスがAWS Systems Managerに統合されていることを確認します。AWS Systems Managerを開き、「ノード管理」、「フリートマネージャー」に移動し、EC2インスタンスを探します。次の画像は、AWS Systems Managerのフリートマネージャーに表示されているSAPシステムです。

Systems Manager managed nodes

ウォークスルー

カスタムメトリクスを収集するためのスクリプトを作成する

SAPInventory.sh という名前のシェルスクリプトを作成して、SAP Host Agent を呼び出し、実行中の SAP インスタンスを検出し、対応するインベントリファイルを JSON 形式で生成します。

次のシェルスクリプトは、実行中の SAP インスタンスのリストを取得し、対応する JSON インベントリファイ ルを生成します。

#!/usr/bin/sh
SHA=/usr/sap/hostctrl/exe/saphostctrl
SCNTRL=/usr/sap/hostctrl/exe/sapcontrol

# Get my EC2 ID
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
EC2ID=$(curl http://169.254.169.254/latest/meta-data/instance-id -H "X-aws-ec2-metadata-token: $TOKEN")

# Inventory file: SAP Instances
SSMINVSAPINST="/var/lib/amazon/ssm/${EC2ID}/inventory/custom/SAPInstanceList.json"

# Inventory header
echo -n -e "{\"SchemaVersion\": \"1.0\",\"TypeName\": \"Custom:SAPInstanceList\",\"Content\": [" > ${SSMINVSAPINST}

# Get list of SAP instances
SAPINSTANCELIST=$(${SHA} -function ListInstances -running 2>&1)

# Iterate through list and add to inventory file
for I in $(echo ${SAPINSTANCELIST}|sed -E -e 's/\s//g' -e 's/InstInfo:/\n/g')
do
SID=$(echo ${I}|cut -d"-" -f1)
SN=$(echo ${I}|cut -d"-" -f2)
VH=$(echo ${I}|cut -d"-" -f3)
IN=$(${SCNTRL} -nr ${SN} -function GetInstanceProperties |grep INSTANCE_NAME|awk 'BEGIN { FS = "," } ; { print $NF }'|sed -E 's/\s//g')

echo -n -e "{\"SID\": \"${SID}\",\"System Number\": \"${SN}\",\"Virtual hostname\": \"${VH}\",\"Instance Name\": \"${IN}\"}," >> ${SSMINVSAPINST}
done

# Complete the JSON file
sed -i 's/,$//' ${SSMINVSAPINST}
echo -n -e "]}" >> ${SSMINVSAPINST}

類似の方法で、SAP カーネルバージョン、SAP インスタンスアクセスポイント、SAP インスタンスプロセス、SAP ABAP コンポーネントバージョンに関する情報を取得することができます。

下記はSAPInventory.sh スクリプトによって生成された JSON 形式のインベントリファイルの例です。

{
   "SchemaVersion": "1.0",
   "TypeName": "Custom:SAPInstanceList",
   "Content": [
     {
      "SID": "SC3",
      "System Number":  "02",
      "Virtual hostname":  "sc3gw",
      "Instance Name":  "G02"
     },
     {
      "SID": "SC2",
      "System Number":  "01",
      "Virtual hostname":  "sc2wd",
      "Instance Name":  "W01"
     },
     {
      "SID": "SC1",
      "System Number":  "10",
      "Virtual hostname":  "sc1ers",
      "Instance Name":  "ERS10"
     }
   ]
}

AWS Systems Manager Inventoryで使用されるJSONフォーマットの詳細については、working with custom inventory というドキュメントをご参照ください。

また、ユースケースを拡張し、分析に関連する可能性のあるオペレーティングシステムのメトリックを取得することもできます。例えば、コスト最適化の優先順位を決めるために、現在どのSAPシステムが最も未使用のファイルシステム領域を持っているかを知りたいとします。次のサンプルスクリプト(FileSystems.sh)は、関連するファイルシステムのメトリクスを取得します。SAPシステムごとに結果を集計するために、EC2タグの値も使用します。

#!/usr/bin/sh
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
EC2ID=$(curl http://169.254.169.254/latest/meta-data/instance-id -H "X-aws-ec2-metadata-token: $TOKEN")
REGION=$(curl http://169.254.169.254/latest/dynamic/instance-identity/document | jq .region -r)

# Inventory file: SAP Instances
SSMINVFS="/var/lib/amazon/ssm/${EC2ID}/inventory/custom/FileSystems.json"

# Inventory header
echo -n -e "{\"SchemaVersion\": \"1.0\",\"TypeName\": \"Custom:FileSystems\",\"Content\": " > ${SSMINVFS}

# Capturing a Tag Value (Ex: tag key = SAPSID)
SID=`aws ec2 describe-tags \
--region $REGION \
--filters "Name=resource-id,Values=$EC2ID" \
"Name=key,Values=SAPSID" \
| jq .Tags[0].Value | sed 's/"//g'`

# Capturing list of filesystems, appending SAP SID 
df | tr -s ' ' | sed "s/$/ $SID/" | jq -sR 'split("\n") | .[1:-1] | map(split(" ")) | map({"SID": .[6], "file_system": .[0], "total":.[1], "used": .[2], "available": .[3], "used_percent": .[4], "mounted": .[5]})' >> ${SSMINVFS}

# Complete the JSON file
echo -n -e "}" >> ${SSMINVFS}

これらのシェルスクリプトをAmazon S3バケットにアップロードします。この例では、スクリプトは/scripts/というプレフィックスが付いたAWS S3バケットに格納されています。

AWS Systems Managerドキュメントを作成する

EC2インスタンスでのカスタムシェルスクリプトの実行は、AWS Systems Managerのドキュメントを使用して行います。

1. AWS Systems Managerを開きます。
2. ナビゲーションバーの「共有リソース」から「ドキュメント」を選択します。
3. 「Create document」を選択し、「Command or Session」を選択します。
4. ドキュメントの名前を入力し、他のフィールドは変更しないでください。
5. 以下のJSONコンテンツを使用できますが、AWS S3バケット名は独自のものに置き換えてください。

{
  "schemaVersion": "2.2",
  "description": "Create SAP SSM Inventory files",
  "mainSteps": [
    {
      "inputs": {
        "timeoutSeconds": "300",
          "runCommand": [
          "mkdir -p /root/tmpscripts",
          "aws s3 cp s3://<bucket name>/scripts/SAPInventory.sh /root/tmpscripts/",
          "aws s3 cp s3://<bucket name>/scripts/FileSystems.sh /root/tmpscripts/",
          "sudo dos2unix /root/tmpscripts/* ",
          "sudo chmod 755 /root/tmpscripts/* ",
          "/root/tmpscripts/SAPInventory.sh",
          "/root/tmpscripts/FileSystems.sh",
          "rm -rf /root/tmpscripts "
        ]
      },
      "name": "runCommands",
      "action": "aws:runShellScript"
    }
  ]
}

下記はAWS Systems Managerのドキュメントのイメージです。

Systems Manager document content

スケジュールベースのAmazon EventBridgeルールを定義する

Amazon EventBridge RuleはAWS Systems Managerドキュメントを定期的に実行します。AWS Systems Managerドキュメントはデータ収集シェルスクリプトを順番に実行します。

1. AWSコンソールでAmazon EventBridgeを開きます。
2. 「ルール」を選択し、「ルールを作成」をクリックします。
3. ルールの名前説明を入力します。
4. セクションルールタイプで「スケジュール」を選択し、「次へ」をクリックします。

例として、次の画像を参考に、このルールのスケジュールを30分ごとに作成します。

EventBridge rule pattern

5. セクションターゲットを選択で「Systems Manager 実行コマンド」をターゲットとして選択します。
6. ドキュメントでこの前作成したAWS Systems Managerドキュメントを選択します。
7. ターゲットキーtag:sap:inventoryを入力します。
8. ターゲット値yesを入力します。
9. 最後にルールの作成をクリックします。定義されたスケジュールに従ってルールが発動されます。

例として、次の画像を参考に、このルールのターゲットを選択します。

EventBridge rule targets

インベントリデータを表示する

下記の手順でカスタムインベントリデータを見ます。

1. AWSコンソールでAWS Systems Managerを開きます。
2. セクション「ノード管理」配下の「フリートマネージャ」をクリックします。
3. マネージドノードのリストから、SAPインベントリが収集されたインスタンスを1つ選択し、クリックします。
4. タブ「インベントリ」をクリックします。
5. ドロップダウンリストインベントリタイプを開き、「Custom:SAPInstanceList」を選択します。

例として、次の画像は1つのインスタンスのカスタム・インベントリ・データを表示しています。

Systems Manager inventory exmaple

AWS Systems Managerのインベントリデータを準備する

Amazon Athenaでインベントリデータを照会する前に、データソースを準備する必要があります。これはいくつかのステップから構成されますが、下記説明のように、AWS Systems Managerはプロセスを簡素化します。

1. AWSコンソールでAWS Systems Managerを開きます。
2. セクション「ノード管理」配下の「インベントリ」をクリックします。
3. タブ「詳細ビュー」を選択します。
4. 「リソースデータの同期の作成」をクリックします。
5. 同期名、バケット名、プレフィックスを入力します。

次の画像を参考に、リソースデータの同期を作成します。

Create a resource data sync

6. 数分待ってから、AWS Systems Manager→インベントリ詳細ビューの画面に戻ります。
7. リソースデータの同期のドロップダウンリストに新しい同期が表示されます。
8. 新しい同期を選択し(今回はSAP-inventory)、「Run Advanced Queries」をクリックします。

SAP-inventory resource data sync

これでAmazon Athena画面に遷移し、データソースデータベースは対応するAWS Systems Managerインベントリが 選択されている状態になります。下記の画像は稼働中のSAPインスタンスと対応するテーブルを表示しています。(例えば、custom_sapinstancelist)。

Athena table

一つの注意点として、リソースデータの同期が作成された時点に、Amazon S3に格納されたすべてのオブジェクトはカタログ化されます。その結果、Systems Managerインベントリ以外のものも含めたより大きなテーブルセットが出る場合があります。

Amazon Athenaでインベントリをクエリする

Amazon Athenaを初めて使用する場合、クエリ結果を格納するAmazon S3バケットを指定します。

1. Amazon Athenaのメイン画面で「設定」を選択します。
2. クエリ結果を格納するAmazon S3バケット(およびプレフィックス)を指定します。

Athena query results location

SAP インベントリテーブルの 1 つ(例えば、custom_sapinstancelist)からデータをプレビューするには、以下の手順に従います。

1. テーブル名の横にある省略記号付きのメニューボタンをクリックします。
2. 「テーブルをプレビュー」を選択します。
3. これで新しいタブが追加され、対応するSQLと結果が下に表示されます。

下記画像は結果の例を表示しています。

query sapinstancelist - results

カスタムAthenaクエリを作成する

Systems ManagerインベントリがAmazon Athenaで利用できるようになったことで、より複雑なクエリを実行することが可能になりました。例えば、以下のクエリは標準のAWS Systems Managerインベントリからのデータと、カスタムSAPインベントリを組み合わせて、私たちのSAPシステムにおけるC++標準ライブラリのバージョンを取得するためのものです。

SELECT a.name, a.version, a.packageid, a.publisher, b.sid, b."instance name", a.resourceid
FROM "myxferbucket-us-west-2-database"."aws_application" a, "myxferbucket-us-west-2-database"."custom_sapinstancelist" b
WHERE a.resourceid=b.resourceid
AND a.name='libstdc++';

Custom query example

AWS Systems Managerのインベントリデータを取得する際に、ファイルシステムの統計情報も含めていれば、下記のようなクエリを実行し、Oracle、DB2、HANAのデータに使用されるファイルシステムで最も空き容量のあるSAPシステムの上位10件を取得することができます。これにより、例えばストレージコストを最適化するための潜在的な候補が明らかになるかもしれません。

SELECT sid as "SAP System", sum(cast(available as bigint))/1024/1024 as "Available Data FS Space (GB)"
FROM   custom_filesystems 
WHERE  (mounted like '/oracle/___/sapdata%') 
OR     (mounted like '/db2/___/sapdata%') 
OR     (mounted = '/hana/data')
GROUP BY sid
ORDER BY 2 desc
LIMIT 10;

Filesystem space query example

コスト

本ブログで紹介したような要件を対応するために、AWSのサービスは 費用対効果の高いソリューションを提供します。以下の表は、このブログで紹介したシナリオの一部として使用された各サービスのコスト試算です。これらの試算では、以下を想定しています。

  • 使用したAWSリージョン:us-east-1 (N.バージニア)
  • SAPランドスケープは2000台のSAPサーバ(EC2インスタンス)で構成されます。
  • 取得したメトリクスは、1日平均100回クエリされました。
  • SAPとファイルシステムの両方のカスタムメトリクスは、カスタムSystems Managerインベントリデータの一部であった。さらに、Linuxの標準的なSystems Managerインベントリデータもすべて含まれていました。
サービス 備考 試算 追加の価格情報
Amazon EventBridge 標準的なEventBridgeのイベントは無料です。 $0 Amazon CloudWatch pricing
AWS Systems Manager AWS Systems ManagerインベントリとRun Commandの使用は無料です。 $0 AWS Systems Manager pricing
Amazon S3 $0.023/GB/月(2000台のSAPサーバーのインベントリーデータのサイズは2GB程度と試算) $0.5 Amazon S3 pricing
Amazon Athena 1回のクエリでスキャンされるデータが最低10MB、スキャンされるデータ量が$5/TBとして、1日100回のクエリを想定(すべてのクエリは最低10MBより大幅に少ないデータをスキャンしています)。 $0.16 Amazon Athena pricing
Amazon Glue 我々のカタログは、100万オブジェクトの無料階層をはるかに下回っていました。クローラーを1時間ごとに実行する場合のコストは、最低10分のDPUチャージに基づき、DPU/時間当たり$0.44と試算されました(テストしたクローラーの実行時間は最低10分未満でした)。 $53.00 AWS Glue pricing
月額費用試算の合計 $53.21

クリーンアップ

ウォークスルーセクションで作成したサービスやオブジェクトの構成を削除するには、次の手順を実行することをお勧めします。

  1. AWS Systems Managerのインベントリリソースの同期を削除します。
  2. AWS Glue Crawlerを削除します。
  3. AWS Glueデータベースを削除します。
  4. Amazon EventBridge Ruleを削除します。
  5. AWS Systems Managerのドキュメントを削除します。
  6. Amazon Simple Storage Service (AWS S3)のバケットを削除します。
  7. OSからjsonインベントリファイルを削除します。
  8. AWS CLIを使用してインベントリ定義を削除します。

まとめ

このブログはAWSのサービスを活用してSAPシステムのインベントリを可視化する方法について、いくつかのアイデアを紹介しています。いくつかの設定ステップで、Amazon EventBridgeとAWS Systems Managerを連携し、SAPシステム情報のデータを自動的に収集、保存、集計することができます。その後、Amazon Athenaと標準的なSQLクエリを使用して、この情報に素早くアクセスすることができます。さらに、これは追加のインフラストラクチャをデプロイすることなく実現することができます。

このブログで提供される例は、下記のように簡単に拡張することができます。

  • PowerShellコマンドを使用して、Windowsワークロードのカスタムインベントリデータを取得します。
  • シェルスクリプトとデータベースコマンドラインツールの組み合わせを使用して、カスタムインベントリデータにデータベースメトリクスを含めます。
  • AWSタグ戦略の追加コンポーネントを使用し、カスタムのインベントリデータを強化し、より高度なクエリのシナリオを可能にします。

さらに、お客様のSAP環境、特にSAP HANAがコアコンポーネントとなっている環境では、Amazon CloudWatch Application Insightsにより観測性を高めることが可能です。SAP HANAデータベースのモニタリングを今すぐセットアップするには、Amazon CloudWatch Application Insightsのドキュメントを参照して、開始方法に関する詳細なチュートリアルをご参照ください。

これらのアイデアは、SAP on AWS環境のさまざまな側面をサポートするために活用することができます。運用サポート、監査とコンプライアンス、キャパシティプランニング、コストの最適化などは、ほんの一例です。私たちは、お客様がこれらのアイデアを基に構築されるのを楽しみにしています。ぜひAWS Consoleにログインして、このブログで取り上げたサービスの探索を始めてみてください。

SAPシステムをAWSに移行する際に、専門家によるガイダンスやプロジェクトサポートをお探しでしたら、AWS Professional Services Global SAP Specialty Practiceがお役に立てると思います。SAP on AWSのお客様(CHSやPhillips 66を含む)は、SAPの変革を加速するために、私たちのチームとのエンゲージメントに投資することが多くなってきています。私たちがどのように支援できるかについてもっと知りたい場合は、AWSプロフェッショナルサービスチームにご連絡ください。

AWSが5000を超えるSAPのお客様に選ばれた理由については、aws.amazon.com/jp/sapをご参照ください。

翻訳はSpecialist SA アッシュが担当しました。原文はこちらです。