1.はじめに
みなさん、運用業務の自動化は進んでいますか？
クラウドが一般的になってきてから運用の自動化がすごい勢いで進んできていますね。
先日私も運用自動化するために色々と試行錯誤をしているところ、「AWS Systems Manager(以下SSMと呼ぶ)」に出会いました。
AWSを使っている方へおすすめしたいので、今回はSSMについて書いていきます。
2.SSMとは？
SSMとは、オンプレ環境にも適応可能なインフラ管理ツールです。
AWS公式ドキュメントでは、SSMを以下のように紹介しています。
"AWS Systems Manager は、Amazon EC2 インスタンス、オンプレミスサーバーと仮想マシンや他の AWS リソースを大規模に設定および管理する機能のコレクションです。Systems Manager には、AWS リソース間で運用データを簡単に一元化し、タスクを自動化できる統一されたインターフェイスが含まれています。Systems Manager はインフラストラクチャで運用上の問題を検出して解決するための時間を短縮します。Systems Manager は、インフラストラクチャのパフォーマンスと設定についての詳細を提供し、リソースとアプリケーションの管理を簡素化することで大規模なインフラストラクチャの運用と管理を簡単にします。"
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/what-is-systems-manager.html
つまり、「運用タスクの自動化用サービス」ということです！さらに、料金も安い。
オンプレ環境と非AWSパッケージの管理、SSM Automationの使用に料金がかかります。
システム規模にもよりますが、スモールスタートで導入していく場合、大体無料枠内で収まります。
https://aws.amazon.com/jp/systems-manager/pricing/
使用するためにエージェントを入れたりなんなりありますが、使用条件は以下の公式ドキュメントをご参照ください。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-setting-up.html
3.SSMの使用例
じゃあSSMってどんなことに使うのがいいの？という視点で使用例を書いてみます。
▪️バックアップの取得(AMIの取得)
私がSSMに最も注目した理由はこれです。
lambdaで実行するのと何が違うの？って思う方もいるかもしれません。
一般的にAMIの取得は、インスタンスを停止させて行うことが推奨されています。
この推奨の通りにlambdaを使用すると
"インスタンスの停止→AMIの取得開始"
までは容易にできますが、
"AMI取得完了→インスタンスの起動"
の実行をするために諸々と考えなければならなくなります。
しかし、SSMなら
"インスタンスの停止→AMIの取得開始→AMI取得完了→インスタンスの起動"
が簡単に自動化できます。
図3.1.バックアップ自動化イメージ
▪️パッチ適用の自動化
意外と時間を取られるパッチの適用作業ですが、SSMでは、Patch Managerというものや、Windows Update をAutomationで実行できる"AWS-InstallWindowsUpdates"というものが用意されていたりします。"自動化してね"と言わんばかりのサービスです。
私の場合は、管理系サーバに対して、先ほどのバックアップ取得と"AWS-InstallWindowsUpdates"を掛け合わせて、以下フローの自動実行を実現しています。
"インスタンス停止→バックアップを取得→インスタンス起動→Windows Update→インスタンス停止→バックアップを取得→インスタンス起動"
図3.2.バックアップ自動化＋Windows Update自動化イメージ
設定方法については、以下をご参照ください。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-setting-up.html
4.まとめ
使用例を交えながらSSMについての紹介をしました。
サービスを一番支えているのが運用であり、最も時間を割くのも運用だと思います。
その運用を少しでも自動化させることによって、運用担当者の負荷を下げ、創造的なタスクができるようになっていけばいいなと勝手に目論んでいます。
運用自動化の波に乗るためにも、是非SSM使ってみてください（まとめ方がSSMの回し者みたいw）。