![[アップデート] AWS PCS ジョブ完了時のメタデータログを S3 や CloudWatch Logs などに保存できるようになりました"](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-242d6adbbf7d12f8c05dfdd896582262/2aac9bbff0d5d56bc0a4ab752ced5d22/hpc_eyecatch.png)
[アップデート] AWS PCS ジョブ完了時のメタデータログを S3 や CloudWatch Logs などに保存できるようになりました"
AWS PCS でジョブ完了ログを複数の保存先に送信可能に
AWS Parallel Computing Service(PCS)にジョブ完了時のメタデータログを 3 つの AWS サービスへ送信できる機能が追加されました。Slurm のジョブに対して、実行履歴保存やモニタリングが既存の AWS サービスと連携できるようになりました。
なにが嬉しいのか
HPC 環境では、ジョブの実行状況やリソース使用量の把握したくなることがよくあります。従来は Slurm の標準機能である Slurm アカウンティングを利用してジョブの実行履歴を MySQL などのデータベースに保存していました。
今回のアップデートにより、Slurm アカウンティングを利用せず簡単にジョブの実行ログを 3 種類の AWS サービスへ保存できるようになりました。保存可能なメタデータは以下の情報を含んでいます。
- リソース情報: ジョブを実行したクラスターとインスタンスの詳細
- ジョブメタデータ: ジョブ ID、ユーザー、実行時間、終了コード
- リソース使用量: CPU、メモリ、ノード数などの使用量
必要充分そうな感じがしますね。
対応している保存先
現在、以下の 3 つの保存先が利用可能です。
- CloudWatch Logs: リアルタイム監視やアラート設定に最適
- Amazon S3: 実行履歴の長期保存やコスト効率的なアーカイブに適している
- Amazon Data Firehose: 他の分析サービスとの連携に活用できる
今回追加されたのは画面下部の Log deliveries - Job Completion Logs です。マネジメントコンソールからは最大 3 つの保存先を同時に設定可能です。
CloudWatch Logs への保存設定をやってみた
今回は AWS CLI を使用して CloudWatch Logs にジョブ完了ログを送信する設定を検証しました。ちなみにマネージメントコンソールから設定をしたところ上手く動作しませんでした。アップデート当日に試していたこともあり、よくあることです。現時点では AWS CLI で設定をオススメします。
設定手順は以下を参考にしました。
Job completion logs in AWS PCS - AWS PCS
前提条件について
前提条件で IAM プリンシパルへ pcs:AllowVendedLogDeliveryForResource
アクションの許可が必要とあります。PCS クラスターに IAM ポリシーが追加で必要かと当初思ったのですが違いました。今回の設定をする人(IAM ユーザーや、IAM ロール)が権限を持っていれば問題ありませんでした。
1. ログ配信先の作成
ジョブ完了ログを送信する配信先を定義します。
put-delivery-destination
コマンドでは、ログの送信先となる AWS サービスのリソース ARN を指定して配信先を作成します。
aws logs put-delivery-destination --region ap-northeast-1 \
--name pcs-logs-to-cwlogs \
--delivery-destination-configuration \
destinationResourceArn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws-pcs/joblog
{
"deliveryDestination": {
"name": "pcs-logs-to-cwlogs",
"arn": "arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:pcs-logs-to-cwlogs",
"deliveryDestinationType": "CWL",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws-pcs/joblog"
}
}
}
2. ログ配信ソースの設定
ログを生成するソースとして PCS クラスターを登録します。
put-delivery-source
コマンドでは、ログの送信元となる PCS クラスターの ARN とログタイプ(PCS_JOBCOMP_LOGS
)を指定して配信ソースを作成します。指定したクラスターからジョブ完了ログの配信対象となります。
aws logs put-delivery-source --region ap-northeast-1 \
--name pcs-logs-to-cwlogs-sorce \
--resource-arn arn:aws:pcs:ap-northeast-1:123456789012:cluster/pcs_oq276tkdyl \
--log-type PCS_JOBCOMP_LOGS
{
"deliverySource": {
"name": "pcs-logs-to-cwlogs-sorce",
"arn": "arn:aws:logs:ap-northeast-1:123456789012:delivery-source:pcs-logs-to-cwlogs-sorce",
"resourceArns": [
"arn:aws:pcs:ap-northeast-1:123456789012:cluster/pcs_oq276tkdyl"
],
"service": "pcs",
"logType": "PCS_JOBCOMP_LOGS"
}
}
3. 配信ソースと配信先の接続
手順 1 で作成した配信先と手順 2 で設定した配信ソースを関連付けます。
create-delivery
コマンドでは、配信ソース名と配信先 ARN を指定して両者を関連付けます。注意点として、配信ソースは名前で指定し、配信先は ARN で指定する必要があります。
この設定により、PCS クラスターで実行されるジョブの完了ログが自動的に指定した配信先へ送信されるようになります。
aws logs create-delivery --region ap-northeast-1 \
--delivery-source-name pcs-logs-to-cwlogs-sorce \
--delivery-destination-arn arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:pcs-logs-to-cwlogs
{
"delivery": {
"id": "b3WK0zjti0W8GBYA",
"arn": "arn:aws:logs:ap-northeast-1:123456789012:delivery:b3WK0zjti0W8GBYA",
"deliverySourceName": "pcs-logs-to-cwlogs-sorce",
"deliveryDestinationArn": "arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:pcs-logs-to-cwlogs",
"deliveryDestinationType": "CWL",
"recordFields": [
"resource_id",
"resource_type",
"event_timestamp",
"scheduler_type",
"scheduler_major_version",
"fields"
]
}
}
設定状況の確認
設定完了後、以下のコマンドで各種設定を確認できます。
# 配信設定の一覧確認
aws logs describe-deliveries --region ap-northeast-1
# ログ配信ソースの確認
aws logs describe-delivery-sources --region ap-northeast-1
# ログ配信先の確認
aws logs describe-delivery-destinations --region ap-northeast-1
マネジメントコンソールでの確認
AWS CLI で設定後、マネジメントコンソールから設定状況を確認できます。しかし、表示されている CloudWatch Logs のロググループ名が、今回指定したものではなく、PCS の規定ロググループの設定が表示されます。現時点では規定のロググループ以外の設定がマネジメントコンソールから対応していないと思われます。
動作確認
設定完了後、ジョブを実行してログが記録されることを確認しました。簡単なテストスクリプトを Slurm で実行し、CloudWatch Logs への出力を検証しました。
# テスト用のジョブスクリプトを作成
echo '#!/bin/bash
echo "Hello from PCS job"
echo "Job completed"' > test.sh
# Slurm でジョブを投入
sbatch -p compute-queue test.sh
CloudWatch Logs のログ出力例
ジョブが完了後に確認するとログが記録されていました。
CloudWatch Logs に出力されるログは以下の構造になります。
このログには以下の情報が含まれていました。
- リソース情報: ジョブを実行したクラスターとインスタンスの詳細
- ジョブメタデータ: ジョブ ID、ユーザー、実行時間、終了コード
- リソース使用量: CPU、メモリ、ノード数などの使用量
{
"resource_id": "pcs_oq276tkdyl",
"resource_type": "PCS_CLUSTER",
"event_timestamp": 1750585988,
"scheduler_type": "slurm",
"scheduler_major_version": "24.11",
"fields": {
"job_id": 2,
"user": "ec2-user",
"user_id": 1000,
"group": "ec2-user",
"group_id": 1000,
"name": "test.sh",
"job_state": "COMPLETED",
"partition": "compute-queue",
"time_limit": "UNLIMITED",
"start_time": "2025-06-22T09:53:07",
"end_time": "2025-06-22T09:53:08",
"node_list": "compute-1",
"node_cnt": 1,
"proc_cnt": 1,
"work_dir": "/shared",
"reservation_name": "",
"tres": {
"cpu": 1,
"mem": {
"val": 7782,
"unit": "M"
},
"node": 1,
"billing": 1
},
"account": "",
"qos": "",
"wc_key": "",
"cluster": "unknown",
"submit_time": "2025-06-22T09:53:07",
"eligible_time": "2025-06-22T09:53:07",
"derived_exit_code_status": 0,
"derived_exit_code_signal": 0,
"exit_code_status": 0,
"exit_code_signal": 0,
"node_details": [
{
"name": "compute-1",
"instance_id": "i-0edda7f38b2e86cd7",
"instance_type": "m7i.large"
}
]
}
}
まとめ
AWS PCS のジョブ完了メタデータログ機能により、HPC 環境での運用が便利になりました。CloudWatch Logs、Amazon S3、Amazon Data Firehose の 3 つの保存先から選択でき、用途に応じた使い分けてください。
Amazon S3
- 用途: ジョブ実行履歴の長期保存
- メリット: 低コストでの大容量保存、データアーカイブに最適
- 想定ケース: 月次・年次のジョブ実行レポート作成、監査対応
CloudWatch Logs
- 用途: リアルタイム監視と即座のアラート
- メリット: CloudWatch アラームとの連携、ログの検索・フィルタリング
- 想定ケース: ジョブ失敗時の即座の通知、特定ユーザーやジョブタイプの監視
Amazon Data Firehose
- 用途: データ分析基盤への統合
- メリット: Redshift、OpenSearch へ転送
- 想定ケース: ジョブ実行パターンの分析、パフォーマンス最適化
おわりに
今回の AWS PCS のジョブ完了ログ機能により、従来の Slurm アカウンティングと比較してランニングコストを大幅に削減できる可能性があります。PCS の Slurm アカウンティングの場合は、DB の運用はマネージドサービスのため運用負担はかからないですが、費用はそれなりにしますからね。
今後は AWS ParallelCluster にも同様の AWS サービス統合機能の追加を期待したいところです。