【レポート】「AWS Systems Manager 徹底活用 ～エンタープライズのユースケースから～」AWS Summit Tokyo 2019 #AWSSummit

こんにちは、臼田です。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

本ブログでは『AWS Systems Manager 徹底活用 ～エンタープライズのユースケースから～』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催

セッション概要

当セッションの登壇者及び概要は以下の通りです。

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト

大村 幸敬

AWS Systems Manager は強力な可視化と自動化の機能を持ち、EC2だけでなくオンプレミスのサーバに対しても、またマルチアカウント環境も管理対象とすることができます。本セッションではエンタープライズ企業で発生する複雑な運用ユースケースを紹介し、AWS Systems Manager を使って運用を実現する具体的な方法を紹介します。本セッションに加え、Systems Manager の初級セッションも合わせて受講されることをお勧めいたします。

レポート

• まずは質問
  • 社内全サーバのJavaバージョンをグラフ化するには？
  • よくある方法
    • システム担当者へサーバ一覧を提出してもらう
    • ログインしてJavaのバージョンを確認
  • どれくらい時間がかかりますか？
  • オンプレミスでもクラウドでも同じようなことをしますか？
  • みんなそれをやりたいですか？
  • Quick Sightを利用すれば見やすいグラフを作れます
• AWSを活用した実装例
  • AWS Systems Manager(SSM)を利用して情報を取得して可視化できる
  • 常に最新の状態を保つことが可能
• このセッション
  • AWSをコントロールプレーンとして運用管理する方法
  • 適用パターンの資料を公開しているのでそれも参考に
• 想定する参加者
  • クラウド及びオンプレミスのサーバ軍を管理効率化したいシステム管理者
  • エンタープライズで運用管理方針を検討する方
• 運用管理ツールとしてのAWS
  • ビジネスアジリティとガバナンス
    • これらは二律背反で語られることが多い
    • AWSを利用すれば両方実現することが可能
    • 各種運用ツールが用意されている
  • AWSのManagement Tools
    • 有効化・プロビジョニング・オペレーションについて各種サービスが有る
  • 今回はオペレーションにフォーカス
    • 特に話すのはAWS Systems Manager
  • AWS Systems Manager
    • いろんな機能が集まっている
    • 一言で言うとサーバ群を管理する多機能なツールセット
      • グループ化
      • スケジューリング
      • などなど
    • 周辺サービスも沢山ある
• エンタープライズのサーバ管理ユースケース
  • 社内全サーバのJavaバージョン比率をグラフ化
    • ユースケースとしては可視化
    • 実現したいことは全サーバのソフトウェア構成をキーワード検索してグラフ化
    • 野良サーバも含めてもれなく最新情報を収集
    • オンプレミスとクラウド両方対象とする
    • 例
      • Javaのサポートが切れるので更改計画を立てたい
      • 脆弱性が見つかったソフトウェアの導入状況を確認
    • ソフトウェア構成情報の収集とかしか
      • SSM Inventoryからサーバの情報を集める
      • データはS3に集約できるので、複数のAWSアカウントやオンプレミスにまたがっていても大丈夫
      • まとまったらAthenaとQuickSightで可視化
    • 手順1: Systems Manager Agentの導入
      • EC2の場合にはIAM PolicyとIAM RoleをアタッチしてSSMへのアクセスを許可
      • エージェントを導入して、エージェントからSSMのエンドポイントに通信
      • オフィシャルなAMIにはエージェントは導入済み
      • 補足: オンプレミスサーバの管理
        • IAM Roleを準備
        • SSM Agentをインストール
        • 通信経路確保
        • アクティベーションコードを設定して登録
        • AWSのエンドポイントはデフォルトグローバルだが、VPC Endpointで閉域網経由でアクセスが可能
    • 手順2: インベントリの有効化
      • 1. セットアップインベントリ
        • SSM StateManagerで30分毎に情報送信を指示
        • EC2からSSM Inventoryに集まる
      • 2. リソースデータの同期
        • SSM Resource Data SyncでS3に上げる
        • Glue CrawlerでS3のデータを12時間毎クロールする
        • データカタログが更新された状態になる
    • 手順3: QuickSightのセットアップ
      • QuickSightでデータセットを定義してグラフ化
    • 参考: 不正ソフトウェア導入に対する自動アクション
      • AWS Config Rulesでソフトウェアの導入状況を記録・監視
      • 違反を検知したら通知や、サーバを止めるなどのアクションを実行できる
      • アクションはSSM Automationを利用できる
  • サーバ群でコマンドを一括実行して結果を確認する
    • ユースケースは一括オペレーション
    • 実現したいこと
      • 一個一個ログインするのは大変なので一度に行いたい
    • 一括実行の方法
      • リソースグループによってタグでサーバ群をグループ化
      • オンプレミスのサーバとまとめて扱うことも可能
      • SSM RunCommandを利用してコマンドを流し込む
        • RunShellScriptというドキュメントなどを利用する
        • sshを使ったりポートを開けたりするわけではない
        • エージェントに指示を出すだけで、上りの通信を使っている
        • 結果をCloudWatch LogsやS3に出力して活用する
    • 参考: オペレータによる規定回復オペレーション
      • 障害を検知したら運用端末上のバッチをダブルクリック
      • 端末にはAWSCLIを入れておき、それを利用してRunCommandを実行できる
      • 特定サーバ上で規定の回復コマンドを実行する
      • 既存のオペレーションと同じように実装することもできる
  • サーバログイン操作の事前許可と事後確認
    • ユースケースはガバナンス
    • 実現したいこと(事前)
      • 許可された人・サーバ・時間帯のみログイン可能
      • 事前の申請と承認が必要
    • 事後
      • 操作がされていることを確認
      • 履歴を確認
    • 構成要件
      • リモート接続用のポートを開けたくない
      • ID情報を更新したくない
    • サーバログイン操作の事前許可と事後確認
      • 申請に基づいてIAM Policy / Roleを作成
      • ログイン可能なマネージドインスタンスと時間帯を指定
      • SessionManagerでアクセス
      • ログはCloudWatch LogsやS3に貯めることができる
      • サーバへのSSH/RDS解法不要
      • OSのログインID / パスワード不使用
      • オンプレミスへのアクセスは追加料金が必要
  • SSM MaintenanceWindowによるスケジューリング
    • 決まった時間にRunCommandやAutomationを起動
    • 同時実行数制御や実行履歴の確認が可能
    • AWSリソースだけの操作ならこちらではなくCloudWatch Eventでもいい
    • インスタンス郡を決まった時間帯だけ起動するのに利用できる
      • AWS Solutions - Instance Schedulerを利用できる
  • サーバ群のメトリクスとログを一括管理
    • OSメトリクスを一括して収集・監視する
    • サーバのログを一括して集約して指定した期間保存する
    • OS内部の情報はデフォルトではCloudWatchメトリクスでは取得できなくてエージェントが必要
    • 実現方法
      • CloudWatchAgentの設定ファイルを生成し、SSM ParameterStoreへ格納
      • 設定情報のjsonを一箇所でまとめられる
      • SSM RunCommandで各サーバにCloudWatchエージェントをインストールする
      • AmazonCloudWatch-ManageAgentドキュメントを実行してパラメータを配布
      • オンプレミスへの設定配布も可能
  • セキュリティパッチの適用を徹底する
    • セキュリティパッチなどの適用状況を一括で把握し一定のルールで前者のサーバに適用する
    • SSM PatchManager機能を利用する
      • パッチがリリースされて何日経過したら適用する、のようなルールの設定が可能
      • MaintenanceWindowsとRunCommandを利用してパッチ適用
  • 所有ライセンス数と実際の利用数を管理する
    • 前者で確保しているライセンス数と利用実態の突き合わせを行う
    • ソフトウェアの利用数を確認することも可能
• 料金
  • AWS Systems Managerの利用は基本無料
  • 一部の高度な機能だけ有料
  • S3等連携しているサービスも使用料はかかる
• まとめ
  • Systems Managerで運用改善をサポート
  • 解決したいユースケースはお聞かせください
    • 営業やソリューションアーキテクト・パートナーに相談してください

感想

SSMを利用することにより幅広い運用管理のユースケースに対応できることがわかりました。

オンプレミスも含めて、運用改善をしていけるサービスであると思います。

SSMはコンポーネントが様々あって理解するのは少し大変ですが、ユースケースを想定して取り組むとやっていけると思いますので是非活用してみてはいかがでしょうか？