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

AWS re:Invent 2017

#AWS

#AWS Systems Manager（SSM）

#イベントレポート

渡辺聖剛

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 のパッチ最新化と再構築を月次で実施
- パッチレベルの監査
- 起動中のインスタンスへのパッチ適用
- 任意のコマンドをインスタンス上で実行