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

AWS Summit Tokyo 2019のセッションレポートです。こちらでは「AWS Systems Manager 徹底活用～エンタープライズのユースケースから～」の内容をレポートします。

AWS Summit Tokyo 2019

#イベントレポート

#セキュリティ

#EC2 Systems Manager

#AWS Systems Manager（SSM）

#AWS

臼田佳祐

2019.06.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

こちらは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で運用改善をサポート
- 解決したいユースケースはお聞かせください
  - 営業やソリューションアーキテクト・パートナーに相談してください