【レポート】インシデントを起点に考える、システム運用のユースケースご紹介(AWS-04) #AWSSummit

AWS Summit Tokyo 2023

#AWS

杉金晋

2023.04.21

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

みなさんこんにちは、杉金です。

今回は 2023 年 4 月 20 - 21 日にわたって開催された AWS Summit Tokyo 2023 のセッションレポートです。

セッション視聴

AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です）

登録済みの場合、以下から直接遷移できます。

https://jpsummit.awsevents.com/public/session/view/553

セッション概要

インシデント対応、AWSリソース状況の把握、トラブルシューティング・・・。システム運用の仕事はつきません。そんなお仕事をAWSのサービスで楽にしましょう。このセッションでは、インシデント発生という激動の一日を追いながら、その対応やトラブルシューティングといった非日常の運用、またその備えのための日常運用を、マルチアカウント・マルチリージョンといった複雑な環境下において、AWS Systems Manager などの AWS のサービスを使って楽にする方法をご紹介します。

スピーカー

アマゾンウェブサービスジャパン合同会社
エンタープライズ技術本部小売・消費財ソリューション部
マネージャーシニアソリューションアーキテクト
石橋香代子氏

レポート

目的

インシデントを起点にAWSサービスで実現できるおすすめの運用のユースケースを紹介

今日お話すること

バナナスタンドアプリでインシデントが発生、トラブルシューティングを行う。そこから、日常運用で取り組んででいただきたいことについて説明

ケース1：インシデントの対応

夜中４時寝ているところにインシデント発生
- よくあるオンコールの課題
  - 24/365運用体制のオンコール
  - 人的作業ゆえの対応遅延
    - 自動コールの仕組みが必要
  1. 担当者に電話で連絡
  2. 担当者への連絡と同時に関係者にEメールとSMSで通知
  3. 連絡がつかない場合、次の担当者へ
  4. 連絡がつかない場合、次の担当者へ、並行してSUPERVISORにも通知
- AWSサービスで自動でオンコールができる
担当者に連絡がついて対応開始
- 初動対応で手間取ることはないか？
- 初手が決まっているのなら自動修復がよい
  - 登録されている自動処理が自動でキック（自動再起動）
- 担当者は起こされず安眠、情報共有はチャットツールに通知
- 人手を介さず自動修復するのがよい
  - 自動修復で対応できないものもある。そんなときは手順書を見つけて対応する
  - どの手順を使えばいいか、どこにあるのか手間取る
    - AWSで対応手順を用意（Runbook）
    - インシデントに対応するRunbookの表示でインシデントにも焦らず対応できる
いままで説明してきたものの核となるサービスは、AWS Systems Manager Incident Manager

Incident Managerについて

インシデント解決までの手順を短縮させる
対応プランの用意
連絡手段
- Eメール、SMS、電話
エンゲージメント先
- エスカレーションフローの定義
- 担当者のローテーションも設定可能（最近のアップデート）
  - 最初の週は担当者A、次の週は担当者Bに連絡
- Runbookの実行
  - インシデント発生時に自動化ワークフローであるRunbookを呼び出し可能
  - インシデント対応用のテンプレートがある
    - 影響判断、診断、緩和、リカバリーのステップがある
    - これをもとに独自の手順を作っていく
- インシデントの更新や通知はChatChannelを使用する
  - 作業記録をチャットツールに投げられる
  - 複数担当者によるコラボもできようになる
- その後に改善項目や根本原因の振り返り
マルチアカウントやマルチリージョンは対応してる？
- 対応している。レプリケーションセットで代替リージョンで対応可能
- マルチアカウントも集約を使って実現
初期投資不要、従量課金
Incident Managerによって以下を簡単にできる
- 自動コール
- 自動修復
- Runbookの表示
- インシデント情報を集約

ケース2：トラブルシューティング

先ほどのRunbookテンプレートを例にやっていく
- 影響確認、診断、緩和、リカバリー
まずは影響確認。インパクトの検出が必要
- オーバーラッピングする様々な領域にわたるインパクトを一元的に見ることが重要
  - そのためにAmazon CloudWatch dashboardsからはじめてみる（オブザーバビリティ）
    - 自身の役割ごとに見やすいダッシュボードを作るとよい
- エンドユーザーの体験により近く（計測して影響判断に役立てる）
  - CloudWatch Synthetics（外形監視）
  - CloudWatch RUM（Real User Monitoring）リアルなユーザー体験を吸い上げ
  - CloudWatch Internet Monitorインターネットからアクセスしたときの可用性とパフォーマンスを可視化
つぎは診断（ログの調査と直前の操作や構成変更の確認）
- こんな苦労はないか？色んな所からログをダウンロードしてgrep
- こんなときはCloudWatch logs Insight
  - その前にCloudWatch logsの説明（サーバーやアプリのログを収集）
- CloudWatch logs insightの話に戻る
  - 1時間あたりの例外発生件数の一覧を見るクエリ例（件数やグラフ化できる）
  - マルチアカウントで複数のログを横断的に分析できる
- 担当者はBanana-Appで出ているErrorを見ている。並行して直前の操作や構成変更の確認
  - AWSの操作履歴といえばAWS CloudTrail。その分析の仕方を知っているか？
  - Amazon Athenaでクエリで見られるが難易度が人によって高いかも
  - そんな人のためにCloudtrail Lakeがよい
    - コンソール上でクエリを投げでイベント分析ができる。最近のアップデートでAWS以外のソースもCloudTrail Lakeに集められるようになった
    - AWS Configとも統合されているので何をしたか分かる
    - マルチアカウント、マルチリージョンに対応している
つづいて緩和
- 定形処理（EC2の再起動）→IAMの特権アクセス申請→非定型処理
- 定型処理は、汎用的な処理ながら毎回手順書を見ながら手作業でやっている
  - そんなときはAWS Systems Manager Automation
    - Automationは、さまざまなサービスから呼び出せる
    - Runbookを実行できる基盤を提供
    - 事前定義されたRunbookもあるのでそれを使うのもおすすめ
    - Runbookに必要なパラメーター（インスタンスIDなど）を指定して実行
    - マルチアカウント、マルチリージョンで実行できる
    - 200以上ある中からオススメのランブック紹介
      - AWSSupport-TroubleshootSSH（SSH接続できないとき）
      - AWSSupport-ResetAccess（EC2キーペアの紛失、パスワード忘れ）
      - AWSSupport-UpgradeWindowsAWSDrivers（ドライバーのアップグレードしてくれる）
      - AWS-UpdateLinuxAmi, AWS-UpdateWindowsAmi
      - AWSEC2-CloneInstanceAndUpgradeWindows（WIndowsのインプレースアップデート）
- EC2再起動では復旧しない場合、特権での作業が必要。個人に特権を与えてない場合、上長宛にIAM特権の利用を申請する対応が必要
  - AWS Systems Manager Change Managerでこの仕組みを実現
  - 運用上の変更をリクエスト、承認、実装および報告するためもの
    - まず該当のRunbookを動かすテンプレートを用意
    - テンプレートを選択して承認リクエストを上長に送る、上長が承認して特権が利用可能になる
    - 承認は自動承認もできる
    - 変更管理するためのダッシュボードもある（変更リクエストの状況など）
- 特権を与えられた担当者はEC2にアクセスしたい。SSH接続は、SSHキー管理・SSHポート穴あけの管理が大変
  - 脱SSH
  - AWS Systems Manager Session Manager
    - ノードへのセキュアな特権アクセス
      - マネージメントコンソールから対象サーバーを選択してセッション開始で接続できる
      - SSH鍵管理から開放される
    - 発見的統制がしやすいメリットがある。接続履歴やコマンドを取得できる。
      - 接続履歴：CloudTrail
      - sudoコマンドの履歴：CloudWatch logsに連携して検知
処置完了（リカバリ）
- メトリクスを見たところ回復していることを確認。よかったね。
分析
- 事後分析のテンプレートが用意されている（Incident Manager）
- 設問が用意されている。
  - 検知時間を半分にするには？なぜなぜ分析５回など

ケース3：日常運用で取り組んででいただきたいこと

AWS Well-Architected フレームワーク：今日はこの中の運用優秀性の準備を紹介

まずは可視化（EC2は何台あるか、AWSのサポートケースの状況）
- AWS Systems Manager Explorer
  - カスタマイズ可能な運用ダッシュボード
  - 複数サービスからマルチアカウント、マルチリージョンで情報が集約される
- 各サーバーごとの状況
  - Systems Manager Inventoryで収集
    - 各サーバのメタデータを収集
    - マルチアカウントマルチリージョンも対応
ベースラインの構築：AWS全体
- セキュリティベストプラクティスに従っているか：AWS Security Hub
  - 自動コンプライアンスチェック
  - マルチアカウント・マルチリージョンで結果を集約できる
- 各サーバー
  - パッチは適用しているか、手動適用していると見逃していないか→自動化する
    - Systems Manager Patch Manager
    - パッチ自動適用のハードルが高ければ、まずはスキャンから
定形作業の自動化の整備：Runbook
- 定形作業や修復アクションとしても使用できる
- テンプレートがあるのでそれをもとにカスタムして作るのがよい

まとめ
- まずは可視化：Systems Manager Explorer, Systems Manager Inventory
- ベースライン構築：AWS Security Hub, Systems Manager Patch Manager
- 定形作業の自動化の整備：Runbook

総まとめ

担当者が連絡受けたインシデントを起点に
- インシデント対応、トラブルシューティング
- 日常運用で取り入れていただきたいこと
- AWSのサービスを紹介

所感

AWS Systems Managerは豊富な機能を持っているため、使いこなせてない感があったのと、障害対応について何かヒントを得たいと思い、このセッションを受けてみました。実際のトラブルシュートを例にした説明で、どの場面でAWSサービスを使うべきかがよく分かりました。あまり使ったことのないサービスもいくつかあったので、このセッション受講を機会に利用してみようという気になりました。単なるサービス紹介だけでなく、可視化や自動化、楽にするためのテンプレート集など運用効率を高めるためのエッセンスも含まれていて、すぐにでも取り入れたいものばかりでした。また、これらの機能をマルチアカウントで使ってみるというのも近いうちに試したいです。