こんにちは。ラスベガスには行ってないけど、深夜のキーノートを連日見て寝不足気味の照井@さっぽろです。

Lambdaやデータ分析方面の革新的で魅力的なサービス群で遊びたい気持ちを抑えつつ、今すぐ業務に役立ちそうな新サービスのSystems Managerの検証を始めたので、ファーストインプレッションをまとめておきたいと思います。

Amazon EC2 Systems Managerとは

Systems Managerは、エージェントをインストールすることでOS内部のインベントリを収集し、それを参考にOSのパッチ適用やパッケージインストール/アップデート等を自動化して一元管理できるようにするサービスです。今まであったSSM(Simple Systems Manager)の進化版のようなサービスです。

前提知識など

SSMの時から存在したRun Commandについては今回は割愛しており、なんとなく知っていないと分からない部分が出て来ると思うので、Run Commandについて先に知っておきたい方はこちらをご参照ください。

また、本文中に出てくる英語の Document はRun CommandやAutomation(後述)のタスク内容を定義するJSON形式のDocumentを指します。仕様書やマニュアルのようなドキュメントとは異なりますので、ご注意ください。

触ってみる

さて、早速触ってみようと思ったものの「あれ・・・？無い・・・？」と少し戸惑いました。でも、よく考えたらSSMもEC2のメニューに含まれていたので、そちらを探して発見。

左メニューの一番下ですね。SSMが無くなってSystems Managerと統合されています。

下準備

SSMの時からそうでしたが、Systems ManagerもエージェントがSystems Managerのエンドポイントと通信をして動くため、アウトバウンド通信可能な状態にしておくことと、Systems ManagerのAPIをコールするIAM Role権限の付与が必要です。詳しくは以下をご参照ください。
Systems Manager Prerequisites - Amazon Elastic Compute Cloud

EC2を起動してエージェントをインストール

こちらに書かれているUserDataを入れて起動してインストールします。SSMからサービス名的にはSが一個無くなっていますが、エージェントの名前は ssm-agent で今のところ同じです。
※ドキュメント赤字のリージョン名の部分は置き換えが必要なので注意してください

管理画面を確認してみる

Managed Instances というメニューからSystems Manager管理下にあるインスタンスを確認できます。

インベントリ収集の有効化

同画面上部の Setup Inventory からインベントリ収集の設定を行います。
収集対象のインスタンスをInstance IDまたはTagを指定して決定し、収集スケジュール（最小30分毎）、収集対象のインベントリ種別、S3に吐き出させるかどうかを選んで有効化します。Tagを指定できるのは良いですね。

収集対象のインベントリ種別

収集対象のインベントリ種別と、ドキュメントに詳しい記述が見つからなかったので見た感じのざっくり説明です。

Applications
パッケージインストーラ(rpmやdeb,msi等)によってインストールされているアプリケーションやミドルウェアとその提供者やバージョン情報
Aws Components
aws-amitoolsやssm-agent等のAWSの管理機能向けアプリケーションとその提供者やバージョン情報
Network Config
ネットワークインターフェイス毎のネットワーク情報(IPv4,v6アドレスやSubnet Mask,Gateway,DHCP Server,DNS Server)
Windows Updates
Windows Updateの情報（今回はLinuxで試したので詳細不明）
Custom Inventory
ssm:PutInventory APIにてユーザが投入した情報

ChefのインベントリのようにOS情報やログインユーザ、ハードウェアの情報等は収集しない模様。今後増えるのかもしれませんが、欲しければCustomで入れろってことですかね。

ちなみにインベントリはこういった感じで見れます。

State Managerを見てみる

インベントリ収集の設定を行うと、State Managerでタスクの状態が確認できます。他にも、Run CommandのDocument(タスク内容)をインベントリ収集と同様に対象やスケジュールを指定して追加することができ、それぞれのタスクの状態が確認できるようになるようです。

その他の機能

Automation

Automationは、既存のインスタンスに対して実行するRun Commandとは異なり、専用の一時的に動作するインスタンスを起動して外部リソース等の操作を自動化するための機能のようです。使用するためにはDocumentの定義が必要ですが、Run Commandとは違いデフォルトで用意されているタスクのDocumentが存在しないので、また後日試したいと思います。

Activation

Activationは、オンプレミスのインスタンス（サーバ）に対するRun Command実行のために台数のLimitや有効期限を設けた一時的なIAM Roleを付与するための機能のようです。今のところあまり使う機会は無さそうです。

Maintenance Window

Maintenance Windowはドキュメントによると、システムに影響を及ぼす可能性があるタスクを実行するための機能とのことですが、開始時間と期間を指定するものの、その何が起きるかはドキュメントからは読み取れず。雰囲気的にはRDS等の同機能から察するに自動実行タスクが動作可能な期間を限定する機能なのかなという感じがしています。また後でもう少しドキュメントを読み込んだり実際に動かして調べたいと思います。

Parameter Store

Parameter StoreはRun CommandやAutomationのDocumentに埋め込める共通の変数を定義する機能です。

まとめと感想

運用の自動化に必要な様々な要素が詰まった、使いこなせば相当便利なサービスだと思います。

ただ、構成要素が多く、EC2の管理画面に合わせたGUIではかなり操作性や視認性に難があるように感じました。OpsWorksのような専用の管理画面がほしい所です。

また、DocumentやState Manager、Automation、Maintenance Windowの定義あたりは使いこなしていくとGUIによる管理は厳しくなりそうです。何かしらのコード化するツールが必要になってくるかもしれないなと感じました。

あとはせっかくインベントリを集めているのだから、それで実行対象のフィルタリングができると良さそうですね。インベントリをフィルタリングして取得するAPIは用意されているので、自分で作り込むこともできなくは無さそうですが。

今後も検証を重ねて、運用の自動化や効率化を支えるサービスとして活用できると良いなと思います。とりあえず今回は以上です。