AWS Systems Manager の新しい Automation アクションの使い方を紹介

AWS パートナーの Onica によるゲストポストです。Eric Miller (VP of Solutions Development for Onica) が書きました。

AWSのDevOpsコンピテンシーパートナーとして、Onicaはお客様に対し、様々な自動化への挑戦をサポートしてきました。最も重要なツールの一つに AWS Systems Manager があります。AWS Systems Manager はお客様プロジェクトにおけるリソースとアプリケーションの管理をシンプルにし、かつAWSのインフラをセキュアに、信頼性高く、スケーラブルに運用することを容易にしてくれます。Systems Managerは多くのメリットをお客様に提供します。リソースのグループ化、インスタンスの自動メンテナンス、そしてオンプレミスの物理サーバや仮想サーバの管理も。こういった機能によってお客様のビジネス課題の多くを解決することができます。たとえば:

問題検知にかかる時間の短縮
問題に対する対応の自動化（解決までにかかる時間を秒単位にすることも可能）
AWSインフラストラクチャの可視性とコントロール性の改善
セキュリティとコンプライアンス対応の自動化

AWS Systems Managerが持つツールのうち、最も有用な機能の一つが AWS Systems Manager Automation です。これは AWS のマネージドサービスで、Automation Jobs を使用して、よく実行される操作やシステムメンテナンスタスクをシンプルにします。Systems Manager の自動化ドキュメント (Automation documents) で利用可能なアクションは最近まで 15 個でしたが、今回 AWS Systems Manager Automation のチームは 3 つのオフィシャル Automation アクションを公式にサポートしました。これらの新しいアクションは Systems Manager Automation の可能性を大きく広げ、Automation を使って解決できるビジネス課題の限界を、より拡張することになるでしょう。

3つの新しいアクションとは:

executeAwsApi

アナウンスされた3つの新しい機能のうち、最もパワフルな可能性を秘めています。Automation を利用するお客様は、Automation Documents に記述した executeAwsApi アクションによって、AWSエコシステムが持つほぼ全てのAPI呼び出しを行うことができます。記事の後半ではいくつかの例を示して、これがどれだけの機能を提供するのかお見せします。

waitForAwsResourceProperty

これにより、ある AWS リソースのプロパティが特定の状態になるまで、Automation documents のステップを待たせることができます。

assertAwsResourceProperty

こちらはやや細かい機能です。これは Dynamic Automation Workflow を使用する際に Automation documents の他のプロパティと組み合わせて使います。assertAwsResourceProperty はステップの onFailure や isCritical といったプロパティと組み合わせることで、成功/失敗で異なるフローを実行することができます。

新しい Automation アクションでお客様のビジネス課題を解決する

これらの新しい Automation action のメリットを説明するため、お客様の業務における事例を元に、いくつかの課題を考えてみましょう。どういった場面でどのようにこのアクションが使われるのか、いくつかのユースケースをデモすることで、新しい Automation アクションが持つパワーを知ることができるでしょう。

シナリオ1: チームをまたがったゴールデンイメージの配布を自動化する

最初の例で考えるカスタマシナリオは次のとおりです:

開発チーム: Continuous Integration/Continuous Delivery (CI/CD) パイプラインによって AWS CloudFormation テンプレートや（この場合最も重要な） Systems Manager Automation documents のデプロイメントを自動化している
セキュリティチーム: 認証済みのセキュリティベースラインを設定したAMI(Amazon Machine Images) ゴールデンイメージを作成する。このゴールデンイメージは他の組織が持つ「下流の」デプロイメントパイプラインで使われる。
運用チーム: 開発チームのデプロイメントパイプラインがアプリケーションAMIを作成する際、確実にセキュリティチームから提供されたゴールデンイメージが使われるようにする。
課題: セキュリティチームがゴールデンイメージ AMI をリリースしたとき、開発チームの CI/CD パイプラインの設定を運用チームが手動で変更し、 AMI ID をアップデートしなければならない

こういったとき、お客様は Systems Managar のパラメータストアと Automation を組み合わせ、新しい executeAwsApi アクションを使ってこの課題に対応できます。新しい Automation アクションを使った解決策は次のようになります。

ゴールデンイメージを作成するセキュリティチームの Automation にステップを追加します。追加したステップではゴールデンイメージの AMI が作成されたら、新しい AMI の ID をパラメータストアへ格納します。
開発チームの CI/CD パイプラインに Automation を追加します。この Automation documents はソースコード管理ツールに保管され、ビルドが走る際に毎回実行されます。このドキュメントでは新しい executeAwsApi アクションを使ってパラメータストアから最新のゴールデンイメージ AMI ID を取得します。この ID を下流のデプロイメントプロセスに渡します。この処理を行うための単純化したコードは以下のようになります。


description: automate instance deployment using ami-id from param store
schemaVersion: '0.3'
mainSteps:
- name: getGoldenImageId
  action: aws:executeAwsApi
  inputs:
    Service: ssm
    Api: GetParameter
    Name: GoldenImageId
  outputs:
  - Name: Value
    Selector: "$.Parameter.Value"
    Type: String

- name: launch_ec2_instance
  action: aws:executeAwsApi
  inputs:
    Service: ec2
    Api: RunInstances
    ImageId: "{{getGoldenImageId.Value}}"
    MaxCount: 1
    MinCount: 1

この例で何をやっているのか、ステップごとに説明します。

executeAwsApi アクションを使って AWS ssm:GetParameter API を呼び出しています。引数は “Name: GoldenImageId” です。
その前のステップで getGoldenImageId というパラメータの値を取得、保存し、その他のステップで参照できるようにしています。
executeAwsApi アクションを使って AWS ec2:RunInstances API を引数 “imageId: ami-abc1234″ とともに呼びだします。この引数はセキュリティチームが公開したゴールデンイメージの実際の AMI-ID で、前のステップで作成され、”{{getGoldenImageId.Value}}” という形で参照しています。（注：ここでは前のステップのアウトプットの参照方法を示すため、executeAWsApi アクションを使用しています。従来から存在する「runInstances」という Automation アクションを使用することもできます）

シナリオ2: タグとインスタンスの状態を使ってボリュームのスナップショット取得を自動化する

次のカスタマシナリオとして、オペレーションエンジニアがEC2インスタンスに取り付けられたEBSボリュームのスナップショット取得を自動化することを考えます。この例では、ほとんどのボリュームが高トランザクション処理を実行しており、データベースのテーブルやトランザクションログなどが置かれた、大量のIOが必要なボリュームであるとします。多くの場合、実行中のインスタンスボリュームのスナップショットを取得するのはそれほど問題にはなりません。しかしIOが多い場合はボリュームのIOが停止した状態でスナップショットを取得する必要があります。エンジニアが手動でスナップショットを取得する手順は次のとおりです。

スナップショット取得が必要なボリュームを持つDBインスタンスのリストを用意する
予定されたメンテナンスウィンドウで、インスタンスを手動で停止し、状態が “Stopped” になるまで待つ
手動で対象ボリュームのスナップショットを取得する

簡潔かつ短く説明するため、次の Automation の例では一つ前の step で「InstanceIDs」という StringList 型の値が生成されているものとします。ここで InstanceIDs は “db_snapshot: true” とタグ付けされたインスタンスのリストです。


---
description: wait for db instance state to be ‘Stopped’
schemaVersion: '0.3'
mainSteps:

- name: waitStep
  action: aws:waitForAwsResourceProperty
  timeoutSeconds: 300
  inputs:
    Service: ec2
    Api: DescribeInstanceStatus
    InstanceIds: "{{PreviousStep.InstanceIDs}}"
    PropertySelector: "$.Instances.InstanceState.Name"
    DesiredValues:
    - Stopped

新しい waitForAwsResourceProperty アクションを使った Automation スニペットにより、エンジニアはスナップショットの取得手順を自動化することができます。新しいワークフローはこのような流れになります。

こちらのドキュメントに記載されている手順に従い、Amazon CloudWatch イベントのスケジューリング機能を使ってメンテナンスウィンドウを設定します
スケジュールされたイベントで、自動化タスクを起動するよう設定します。ロジックは次のようになります。
- db_snapshot: true のタグが付与されたインスタンスを全て停止します
- waitForAwsResourceProperty を使って、対象のインスタンスがすべて “stopped” 状態になるまで待ちます
- aws:createImage または aws:executeAwsApi を使用して、必要なsnapshotを取得します
- 再度 waitForAwsResourceProperty を使って、全てのイメージあるいはスナップショットの状態が “complete” になるまで待ちます。
- aws:executeAwsApi を使用してインスタンスを再度起動します
- 再度 waitForAwsResourceProperty を使って、すべてのインスタンスの状態が “running”になるまで待ちます
- タイムアウト時間内にサービス提供状態に戻ってこないインスタンスがあれば、警告あるいは通知を行います。

効果を再確認しましょう。Systems Manager Automation によって、退屈で失敗しがちな手動プロセスが、高度な自動化プロセスに置き換えられました。そしてエンジニアは以前の手作業で浪費していた時間を、別のビジネス課題を解決するために振り向けることが可能になりました。

シナリオ3: エラー処理のカスタマイズ

さて、前項のカスタマユースケースへ、さらに運用を追加していきます。エンジニアはスナップショットジョブのどこかが特定の状態になったら（あるいはならなかったら）、直ちにカスタムアクションを実施して対処したいと考えています。Systems Manager Automation は CloudWatch Events と統合して利用可能で、自動化ジョブが失敗した場合に警告したり通知したりすることができます。これに加え、Automation document の中で assertAwsResourceProperty という新しいアクションを使用することで、即時かつカスタマイズされた対処を行うこともできます。

assertAwsResourceProperty は各ステップの onFailure、nextStep、isCritical と組み合わせて、Automation document の処理フローを制御するために利用するのが最も効果的です。これらのプロパティの詳細については AWS Systems Manager Automation のドキュメントに詳しく記載されていますのでお読みください。

では、エンジニアが Automation document を使って、onNotRunning という自動化ステップを実行したいと思ったとしましょう。これは前の例において、閾値時間を経過した後でもEC2インスタンスの状態が Running でない場合に実行されます。一方、インスタンスの状態が Running である場合は onRunning という自動化ステップを実行します。Automation document の例はこちらです。（再掲: InstanceIdsが前のステップで生成されていることを前提にしています）


---
description: execute steps based on resource values
schemaVersion: '0.3'
mainSteps:
- name: assertStep
  action: aws:assertAwsResourceProperty
  nextStep: onRunning
  onFailure: onNotRunning
  inputs:
    Service: ec2
    Api: DescribeInstanceStatus
    InstanceIds: "{{PreviousStep.InstanceIDs}}"
    PropertySelector: "$.Instances.InstanceState.Name"
    DesiredValues:
    - Running

- name: onRunning
  # this step will run only when assertStep above returns ‘Running’

- name: onNotRunning
  # this step will run only when assertStep above returns any value other than
  ‘Running’

カスタムアクションの実装にはいくつかの選択肢があります。

executeAwsApi アクションを各ステップの中で使用する。ほぼすべての AWS API が（パラメータ付きで）実行可能
invokeLambdaFunction アクションを使って、AWS Lambda を呼び出す。より複雑なカスタムコードが実行可能

いずれの場合でもエラー内容に関する有用な情報がトリガイベントに含まれます。これによってアクションを高度にカスタマイズしたり、異なるエラータイプによって異なる処理を行ったりすることができます。さらに、他のアクションタイプと同様に、想定と異なる状態になった場合は Automation document の全体をエラー終了させることもできます。これは単に対象ステップで isCritical の値を True にすることで実現できます。詳しくはこちらに記載しています。

次に目指すところ: CI/CD オートメーション！

AWS DevOpsコンピテンシーパートナーとして、Onicaはお客さまがAWS上の構成管理、自動化、CI/CDを実現し、成功することに情熱を注いでいます。多くのAWSサービスに共通するテーマの一つが、AWSサービスを直感的に管理するための、宣言型のドキュメントです。例えば Systems Manager Automation documents、CloudFormationの .yamlテンプレート、AWS CodeBuild の buildspec.yml、AWS CodeDeploy の appspec.yaml などがそうです。

DevOpsジャーニーの初期ステージでは、これらの宣言型ドキュメントを使ってデプロイを自動化する際に、多くの組織が足止めされてしまいます。例えば Automation documents や CloudFormation テンプレートを書くことを試みてみるものの、結局デプロイするために AWS Management Console を手動で操作したり、 CLI スクリプトを手元で手動実行したりすることを続けてしまうといったことです。

もしあなたの組織がすでに Automation documents のようなインフラストラクチャデプロイメント自動化に取り組んでいるなら、ぜひ自動化を推し進めてください。しかし、あなたのチームがデプロイメント自動化実現に足を取られてしまったら？少しのリソースを投資して、新しい Systems Managerの機能を学び、使って、デプロイメントパイプラインを作ることを検討してみてください。うまくいけばそれでよいのですが、CI/CD経験のある組織であっても、CI/CDを始めたばかりであってもチェックしていただきたいものがあります。私たちの Onica Runway を試してみてください。 Runway はフリーでオープンソースのフレームワークです。これを使うことで、AWSインフラストラクチャをデプロイする際に必要となる、多くの “つなぎ(glue)” となるスクリプトを減らすことができます。

読んでくれてありがとう。Happy Automating!

Onica は 2015年から Premier APN パートナーで、DevOpsを含む 9つの AWSコンピテンシーを保持しています。

このブログの内容と意見はサードパーティの著者によるものであり、AWSはこのポストの内容や確実性について責任を負いません。

原文はこちら (Onica demonstrates uses for new AWS Systems Manager Automation actions)。翻訳は SA 大村が担当しました。

Amazon Web Services ブログ