【レポート】DevOps の採用と「運用自動化」の始め方 (Embrace DevOps and Learn How to Automate Operations) #reinvent #DEV306

2017.12.02

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

はじめに

本記事は AWS re:Invent 2017 のセッション「DEV306 - Embrace DevOps and Learn How to Automate Operations」のレポートです。

このセッションは開会前から公開されていたものですが、実際のところは先日発表された AWS Systems Manager の解説でした。

Ancestry 社の事例紹介では、SSM をプロビジョニングツールとして使って如何に問題を解決したかをユーモアたっぷりに(運用エンジニアの悲哀を込めて)説明してくれました。

スピーカー

  • Narayanan Lakshmanan - Software Development Manager, Amazon
  • Amjad Hussain - Senior Manager
  • Tyler Jones - Cloud Infrastructure Engineering Team Lead, Ancestry

概要

Managing large-scale production environments can be complex – things will go wrong and learning to operate and manage these environments is critical. From routine tasks such as building AMIs to managing the lifecycle of your instances, investing in automation and tooling can help you detect problems earlier, minimize downtime, and reduce manual work. In this session, you will learn how to use Amazon EC2 Systems Manager to troubleshoot common issues, detect and remediate configuration drift, and automate common actions. You will learn how to author common actions and about community driven features of Systems Manager. You can use the same tools across Linux and Windows, in AWS and in hybrid environments. You will also hear from a Systems Manager customer on how they are using Systems Manager to better manage and operate their infrastructure.

Our customer, Ancestry, will talk about how they are using EC2 Systems Manager to manage their environment in an agile manner.

セッション動画

レポート

このセッションの内容

  • AWS Systems Manager 概説
  • 主要顧客のユースケース
  • Ancestry 社の事例紹介 - EC2 SSM

AWS Systems Manager

  • 運用の可視化とコントロール
  • グループ
    • アプリケーションまたは環境を反映させたグルーピング
  • 可視化
    • AWSサービスの運用データを集約
    • パッチの追随、監査データ 他
  • アクション
    • 発生した事象に対処するための自動的なアクション
    • グループ単位
    • リソース間で安全なオペレーション

System Manager capability

  • リソースグループ
  • 組み込みInsight、インベントリ、コンプライアンス、CloudWatchダッシュボード
  • Run Command、ステートマネージャ、メンテナンスウィンドウの定義、パッチマネージャ、自動化、パラメータストア、ドキュメンテーション

オペレーターの人生

  • 新サービスを構築
  • 自分のアプリケーションを構築
  • 時間が経つにつれてサーバの設定(環境)が変化していくことを憂う
  • 手作業だが繰り返しやっている仕事に気付く
  • 業務時間外に通知を受けてトラブルシュートを開始する

こうしたい

  • 全ての自分のインスタンスが適切に設定されていることに確証を得たい
  • 簡単にコンプライアンス違反のインスタンスを探し出したい
  • 全ての監査・バージョン管理を共用可能な方法で集約したい
  • よくやる(common)タスクは自動化したい
  • 簡単にトラブルシュートしたい

Step 1: インフラの設定

  • 一貫性のあるインフラ設定(configration)
  • よくあるシナリオ :
    • とある AutoScalingGroup 内の全てのインスタンスに同じ設定をする
    • 起動時に「ドメイン」へ所属(join)させる
    • インスタンスの健康状態をモニタする
  • Systems Manager が提供してくれるもの
    • 設定をコードとして整える(Authoring)
    • 自動的にインスタンスの設定が起動時に行われる
    • 発生した差分を補正しコンプライアンスレポートを作成

自分の意図を整える

  • ドキュメント化は設定または手順を表現する上で使いやすい方法
  • ドキュメントを編集し、履歴を見て、共有する
  • パラメータの適正さはヒューマンエラーによって減っていく
  • YAML サポートはオーサリングとコメント付与をやりやすくする
  • Amazon (AWS) は予め定義されたドキュメントを公開している

ドキュメントを YAML でオーサリングする

  • ドキュメントからドキュメントを呼び出す(ネスト)
  • プライベートの GitHub レポジトリから Ansible Playbook をダウンロードする
  • Ansible Playbook を実行

インスタンスの設定(Configuring)

  • State Manager はインスタンスの構成変更を可能にする
  • 起動時にインスタンスを構成する
  • 設定の差異からインスタンスを守るための設定の再適用
  • コンプライアンスレポート

Instance Health Monitoring(New!)

  • まもなく公開予定!(動画 12:50頃)
  • クロスプラットフォームのログ・メトリクスのモニタリング
    • CloudWatchとSystems Manager 向け
  • 高解像のメトリクスと集約をサポート
  • メトリクス
    • CPU
    • メモリ
    • ディスク
    • その他(カスタム)
  • 簡単セットアップ
  • オープンソース

Step 2: コモンタスクの自動化

  • よくあるシナリオ
    • ロードバランサ配下のインスタンスの安全なメンテナンス
    • インスタンス起動の前の承認
  • Systems Manager が提供してくれるもの
    • 全ての拡張可能なオペレーションタスク自動化
    • ワークフローは承認を得るまで一次停止・待機できる

オートメーションサービスを使えば

  • 手作業かつ繰り返し実行される手順を自動化手順にコンバートする標準的なフレームワーク
  • 定義済みタスクと新規のカスタム
  • 実行継続前に手作業での承認作業を追加可能
  • Lambda と Run Command

Step 3: トラブルシュートと検証

  • トラブルシューティングは複雑だ
  • よくあるシナリオ
    • ログ収集と検証作業の実行
    • 安全な方法での運用案件の調整
  • Systems Manager が提供してくれるもの
    • インスタンスをまたいだ作業の単純かつ安全な方法
    • 作業内容(アクション)はカスタマイズ可能
    • ヒューマンエラーを減らすためのパラメータ式のアクション

安全なツールとしての Run Command の使用

  • クロスプラットフォーム
  • タグベースの権限付与を含んだアクセスコントロールの代替
  • インバウンドポートを開けたり RDP や SSH を管理する必要は無い
  • 率(Rate)とエラーの閾値
  • CloudWatch Eventsサポート

デモ!

(省略)

Ancestry 社の事例(SSM)

  • オンプレからAWSに移行完了
  • プロビジョニングの方法に悩んだが SSM に落ち着いた
    • 組み込まれたフィードバックと進捗レポート
    • などなど
  • なぜ SSM を?
    • AutoScaling Group 内の全ての Windows VM の起動
    • Linux VM は必要であれば起動時にドメインへ所属させる
    • AMI のパッチ最新化と再構築を月次で実施
    • パッチレベルの監査
    • 起動中のインスタンスへのパッチ適用
    • 任意のコマンドをインスタンス上で実行

SSM にしたことの効果

  • サーバプロビジョニングにかかる時間
    • データセンタ(DC)時代には 2〜3 日かかっていた
    • AWS だと 30〜45分
  • 確実な自動実行
    • DC では 60%
    • AWS では 95%(残りはヒューマンエラー・スクリプトエラー)
  • 簡単なパッチ監査
  • さらなる柔軟性

デモ!

(省略)

将来のプラン

  • Windows Update の 100%自動化
  • パラメータストアの暗号化
  • 構成管理のための State Manager

要約(recap)

  • Systems Manager (SSM) は自動化されたエンタープライズ IT オペレーションの安全でセキュアなプラットフォーム
  • SSM は AWS サービスを統合する - IAM, CloudTrail, CloudWatch Events, AWS Config
  • 全ての AWS リージョンで使用可能
  • SSM Agwnt はWindowsサーバとAmazon Lunux の AMI でデフォルトで使用可能
  • SSM は SOC と HIPAA 認定済み

最後に

特に事前に告知されてなかったのですが、蓋を開けてみれば新サービス(AWS Systems Manager)の説明で驚きました。また、未発表の Instance Health Monitoring の発表のあって盛りだくさんです。

AWS Systems Manager は当初、単に既存のサービスを集約しただけと思えたのですが、よく説明を聞いてみると非常に使いでのあるサービスに思えてきました。今後研究していきたいと思います。