信頼性向上のための Typetalk の障害対策の取り組み

Slide 1

Slide 1 text

信頼性向上のための Typetalkの障害対策の取り組み株式会社ヌーラボ　二橋宣友 1

Slide 2

Slide 2 text

自己紹介二橋宣友 (ふたはしひさとも) @futahashi ● 株式会社ヌーラボ SRE テックリード ○ ビジネスチャットツール Typetalk の SRE 業務 ○ 他のプロダクトや会社全体の SRE 業務 ○ AWS 全般の支援＆リードなど ● ホライズンテクノロジー株式会社技術顧問 ○ 技術コンサルティング & 社員技術向上支援など ● 称号 / 資格 / 出版 ○ 2022 & 2023 APN AWS Top Engineers (Software) ○ 2023 Japan AWS All Certifications Engineers ○ Mackerel Ambassador 🐟 2

Slide 3

Slide 3 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 3 取り組みを支えるツール /サービスも紹介

Slide 4

Slide 4 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 4 取り組みを支えるツール /サービスも紹介

Slide 5

Slide 5 text

● 障害を収束させるために行う一連の作業 ○ 検知 / 連絡 / 動員 / 調査 / 解決 / 記録など ● 障害の種類 ○ システムダウン / 異常動作 / 応答速度の低下 / 不正アクセス / サイバー攻撃など ● 障害対応の難しいところ ○ いつ起きるか / いつ終わるか分からない ○ 解決方法が定まっていない ○ システムや技術の深い知識 / 広い知識が必要 ○ 関係者間の連携が必要 ○ 頻繁に発生すると疲弊する ○ 一方でたまにしか発生しないと対応方法に慣れない ○ 高いプレッシャーの中で素早い判断が求められる ○ 障害はいつか必ず発生するので避けて通れない 5 はじめに - 障害対応とは？ 🤯🤯

Slide 6

Slide 6 text

6 ● アーキテクチャの強化 ○ 障害に強いアーキテクチャで障害を予防する ● 監視の整備 ○ 監視で障害や予兆を検知して早期解決 / 回避する ● 運用フローの定義 ○ 予め障害発生時の運用フローを整備しておく ● 運用体制の整備 ○ 障害がいつ発生しても動員できる体制を整える ● チームワークの強化 ○ 障害対応のチームワークを強化する ● スキルの強化 ○ 障害対応の調査 / 復旧スキルを高めるはじめに - 障害対策はどうする？

Slide 7

Slide 7 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 7 取り組みを支えるツール /サービスも紹介

Slide 8

Slide 8 text

8 Typetalkの障害対応の運用 - イメージ ①サービス監視 / オンコールによる検知 ②チャット / 通話 / 文書による意思疎通と記録 (Google Chatは予備) ③障害対応Wiki / 障害対応フロー ⑥ポストモーテムの記録 / 共有 ✉ ⑤ユーザへの連絡 ④障害の調査 / 対応

Slide 9

Slide 9 text

● 監視は信頼性を高める重大な要素 ○ 障害の防止 / 早期対応 ● Mackerelでサービスの状況を監視 / 共有 ○ 内部監視 / 外形監視 / APIの監視 ○ ダッシュボードで主要メトリックと関連リンクの集約 ○ リリースイベントの記録と共有 ○ サービスのメトリック / アラートの状態をチーム間で共有 ● PagerDutyをオンコールで利用 ○ 夜間や休日でもアラートに気づける ○ 長時間アラートが放置された場合の電話通知 / エスカレーション 9 Typetalkの障害対応の運用 - サービス監視 / オンコール

Slide 10

Slide 10 text

● 複数のチームで連携して収束を目指す ● チャットで関係者と連携 ○ 障害対応の情報共有 / 依頼 ● 主対応チームは通話で密な役割分担 / 連携 ○ 指揮者 / 実作業者 / 書記 / 連絡係 / 顧客対応 ● 文書でリアルタイムに情報を記録 / 整理 ○ 後から参加した人がキャッチアップできる ● 文書のテンプレートを用意し作業効率化と漏れの防止 ○ 障害対応のチェックリスト ○ 障害対応の役割分担 ○ 障害に関する情報 (概要 / 影響範囲 / 発生原因 / タイムライン) 10 Typetalkの障害対応の運用 - コミュニケーション

Slide 11

Slide 11 text

● 障害対応時に必要な情報を集約 ○ ステークホルダー ○ 連絡手段 / 連絡先 ○ 障害対応のPlaybook ○ 緊急時の対応方法 ● 障害対応のフローチャート ○ チーム毎の行動と順序を定義 11 Typetalkの障害対応の運用 - 障害対応Wiki / フロー

Slide 12

Slide 12 text

● ポストモーテムとは？ ○ 発生した障害についてまとめた文章 ○ 障害から学び今後の改善に繋げる ● 障害記録に加えてフォローアップアクションを記入 ○ 根本原因 / 再発防止策 ○ 教訓 ■ うまくいったこと / いかなかったこと / 幸運だったこと ● Backlogの課題で全サービスのポストモーテムを管理 ○ すべての障害状況を管理 / 可視化 ○ カスタムフィールドで専用の入力項目を用意 ○ 検索で過去の障害をキーワード / 日時 / サービス単位などで抽出して振り返り 12 Typetalkの障害対応の運用 - ポストモーテム

Slide 13

Slide 13 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 13 取り組みを支えるツール /サービスも紹介

Slide 14

Slide 14 text

● 障害訓練と題して以下を定期開催 ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● 目的 ○ 障害に強い組織 / システムを作り信頼性を向上する Typetalkの信頼性向上の取り組み - 概要 14

Slide 15

Slide 15 text

● 障害対応の実施 / 改善の機会の減少 ○ サービスの安定化や障害対応の定型化 ● 事業の成長 ○ 利用者の拡大 / 上場による責任の増加 ● 組織の拡大 ○ チームの細分化 / SREの発足 ○ 新規SREメンバーの参入 ■ 障害対応スキルを効率良く習得できる仕組みを与えたい ● AWS Well-Architected Tool (WA Tool) / Foundational Technical Review (FTR) の実施 ○ プラクティスに基づく信頼性向上の気づき 15 Typetalkの信頼性向上の取り組み - きっかけ

Slide 16

Slide 16 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 16 取り組みを支えるツール /サービスも紹介

Slide 17

Slide 17 text

● 概要 ○ 障害が発生した想定で障害対応のコミュニケーションを模擬的に演習 ○ SRE / 開発者 / カスタマーサポートチームが参加 ● 目的 ○ 障害対応フローの理解 ○ 障害対応のコミュニケーションの質の向上 ● 背景 ○ 障害対応フロー / コミュニケーションの改善機会が少なかった 17 ①障害対応フロー演習

Slide 18

Slide 18 text

①障害対応フロー演習 - イメージ 18 ①障害対応Wiki / 障害対応フローの読み合わせ ②演習設定の提示 / 演習実施メンバーの選出 ③模擬演習による障害対応 ④意見交換とWiki / 障害対応フローの見直し ✏

Slide 19

Slide 19 text

● 障害対応の心理的な障壁の低下 ○ 改めて障害対応のフローを認識できた ○ 基本的なコミュニケーションのイメージが身に付いた ○ 特に新入社員 / 障害対応の機会が少なかった人 / 忘れてた人に有効 ● チームを越えた活発な意見交換 ○ 演習を通じて本当の障害も想起されて意見が湧き出た ○ 障害対応方法を改善する目的で議論する機会を設けられていなかった ○ 本当の障害時には話せなかった部分も話し合えた ● ドキュメントの改善 ○ ドキュメントの乖離発見 / 改良 ● メンバーの信頼関係とサービスの信頼性を向上 19 ①障害対応フロー演習 - 模擬演習の所感

Slide 20

Slide 20 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 20 取り組みを支えるツール /サービスも紹介

Slide 21

Slide 21 text

● 概要 ○ 本番環境と同じ構成の検証環境に負荷を実施 ○ 負荷の内容はできるだけ本番環境に近いものを再現 ● 目的 ○ 性能問題を事前に発見するため ● 背景 ○ 構成変更の際にパフォーマンス影響を事前に把握しづらかった ■ 性能問題は、ローカル環境や開発環境で発見しづらい ■ 性能問題は、大きな損失に繋がりかねない 21 ②性能試験

Slide 22

Slide 22 text

22 ②性能試験 - イメージ …  …  …  ①負荷開始  ②ECS Fargate起動   ③トラフィック流入  ④実行結果保存  ⑤完了通知  今ならDistributed Load Testing on AWS を使った環境構築を推奨 https://github.com/aws-solutions/distribu ted-load-testing-on-aws ⑥結果確認 

Slide 23

Slide 23 text

● 有名なツール ○ Gatling (Scala) ← Typetalkはこれ ○ Apache Jmeter (Java) ○ Locust (Python) ○ vegeta (Go) ● 選定理由 ○ 性能試験ツールとして有名で実績がある ○ Typetalkやヌーラボのエンジニアが Scalaに慣れている 23 ②性能試験 - ツール

Slide 24

Slide 24 text

● 直感的で柔軟なプログラミング ○ HTTPメソッドの指定 ○ Form / Headerの指定 ○ 変数の利用 ○ レスポンスコードのチェック ○ レスポンス結果の変数格納 ● Feederを使ったテストデータ作成 ○ csvによるデータINPUT ○ ランダム抽出や順番選択など可能 24 ②性能試験 - Gatlingの特徴 val upload_attachment = exec( http("POST: /api/v1/topics/:topicId/attachments") .post("/api/v1/topics/" + "${topic_id}" + "/attachments") .formUpload("file", "${attachment_file}") .header("Authorization", "Bearer ${access_token}") .check(jsonPath("$.fileKey").saveAs("fileKey")) .check(status.is(200)) ) id,client_id,client_secret 1,taro,***** 2,jiro,***** 3,saburo,*** シナリオの例  Feederのテストデータの例  

Slide 25

Slide 25 text

● 性能試験の結果をHTMLで出力 ○ リクエスト別の統計情報 ○ レスポンスタイムの分布 ○ レスポンスコード判定結果 (OK/NG) ● スコープダウン / フォーカス機能 ○ リクエスト別に詳細絞り込み ○ 気になる時間軸をマウス選択で拡大 25 ②性能試験 - Gatlingの実行結果の例

Slide 26

Slide 26 text

● パフォーマンスに影響するリリース前 ● 構成変更時 ● 性能チューニング時 ● ボトルネックの調査 ● リソース調整時 26 ②性能試験 - 実施タイミング

Slide 27

Slide 27 text

● AWS Graviton 2移行 ● Amazon Corretto移行 ● JDKのバージョン更新 ● DBメジャーバージョンアップ ● パフォーマンスに影響する機能リリース ● 結婚そして出産 27 ②性能試験 - 性能試験のおかげでできたこと

Slide 28

Slide 28 text

● 簡単に性能試験が実現できる時代 (OSS、コンテナ、クラウド) ○ 性能試験実装に必要なコストも抑えやすい ● よりリアルな環境に近づけて事象の再現を目指すのが大事 ○ 本番同等の構成 / リクエストの量 / リクエスト内容 ● 性能試験で性能面で安心できるプロダクトを実現 28 ②性能試験 - 所感

Slide 29

Slide 29 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 29 取り組みを支えるツール /サービスも紹介

Slide 30

Slide 30 text

● 概要 ○ 検証環境で障害を意図的に発生 ○ 発生した障害によるサービス / 自動復旧 / 監視の挙動を確認 ○ 障害の調査 / 復旧オペレーションの実施 ● 目的 ○ 障害時のシステムの挙動確認や調査復旧スキルの向上 ● 背景 ○ 新規SREメンバーが障害対応を効果的に学べる環境を提供したかった 30 ③Game Day

Slide 31

Slide 31 text

③Game Day - イメージ 31 AWS FIS ①検証環境に負荷実行 ②障害をランダムに注入 ③障害要因の特定 / 影響判断 / システム復旧 ④答え合わせ / 振り返りチャットでFISの実験をランダムで実行本番環境の負荷を再現

Slide 32

Slide 32 text

AWS Fault Injection Simulator (FIS)の概要 ● 概要 ○ 障害を注入するフルマネージドサービス ○ カオスエンジニアリングや Game Dayに最適 ● 前提条件 ○ FIS用のIAMロールを作成 ○ (オプションでSSMエージェントを導入) ● 機能 ○ 実験テンプレートの作成 ○ 実験の管理 (実行 / 停止 / モニタリング) ○ シナリオライブラリの利用 (AWSが提供するシナリオ ) ○ スポットインスタンスの中断や RDSのフェイルオーバーの実行なども可能 32

Slide 33

Slide 33 text

FISの概要 - FISの実験テンプレートの作成 ● 設定項目 ○ 説明と名前 ○ ロール ○ ターゲット ○ アクション ○ (ログ) ○ (停止条件) 33 公式にIAMロール/ポリシーの例有り https://docs.aws.amazon.com/ja_jp/fis/latest/userguide /security_iam_id-based-policy-examples.html

Slide 34

Slide 34 text

FISの概要 - 実験テンプレートの作成 ● 設定項目 ○ 説明と名前 ○ ロール ○ ターゲット ○ アクション ○ (ログ) ○ (停止条件) 34 EC2 / ECS / RDS など色々サポート数や割合でも選択可能 IDやタグで選択可能

Slide 35

Slide 35 text

FISの概要 - 実験テンプレートの作成 ● 設定項目 ○ 説明と名前 ○ ロール ○ ターゲット ○ アクション ○ (ログ) ○ (停止条件) 35 複数アクション可能用意された様々なアクション

Slide 36

Slide 36 text

FISの概要 - 実験テンプレートの作成 ● 設定項目 ○ 説明と名前 ○ ロール ○ ターゲット ○ アクション ○ (ログ) ○ (停止条件) 36 細かい実行ログまで閲覧可能 (ランダムで選ばれたターゲットIDなど) ガードレールとして設定可能

Slide 37

Slide 37 text

FISの概要 - 実験の管理 37 手動停止も可能実験の日時 / 状態 /アクション / ターゲット / タイムライン等が確認可能

Slide 38

Slide 38 text

③Game Day - 実験内容の紹介 ● 実験の構成 ○ 1つの実験に付き1アクションのシンプルなシナリオ ● ターゲット ○ 検証環境でタグで絞り込んでランダムに抽出 ● アクション ○ EC2の停止 / 再起動 ○ RDSのFailover / 再起動 ○ 特定のProcessをKill (アプリ、ミドル、その他のエージェント ) ○ CPU / Memory / Network のストレス ○ EC2のルートボリュームの枯渇 38

Slide 39

Slide 39 text

● FISで障害注入の仕組みを簡単に実装 ● 障害対応の経験値の向上 ○ 障害対応の知識 / 技術共有 ○ 障害対応への慣れ ● システムの動作確認 ○ 監視項目 / しきい値 / アラートの動作確認 ○ システムの耐久力 / 回復力の確認 ③Game Day - 所感 39

Slide 40

Slide 40 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 40 取り組みを支えるツール /サービスも紹介

Slide 41

Slide 41 text

● 概要 ○ 過去の特定のバージョンのアプリへロールバックするオペレーションを実施 ● 目的 ○ ロールバックが必要な事態に円滑にロールバックを実行できるようにする ● 背景 ○ 機械的に検知できない異常時に人の判断でロールバックを実行する機会がたまにある (主には社内環境) 41 ④ロールバック演習

Slide 42

Slide 42 text

42 ④ロールバック演習 - イメージ ①ロールバックのWikiの読み合わせ ②ロールバックオペレーションの実施 ③ロールバック結果の確認 ④ロールバックのWikiの見直し ✏

Slide 43

Slide 43 text

● CodeDeployとは？ ○ アプリケーションのデプロイを自動化するサービス ○ デプロイの管理 / 可視化 / ロールバック ● デプロイのターゲット ○ EC2 / ECS / Lambda / オンプレミス ● デプロイの種類 ○ In-Place Deployment / Blue/Green Deployment ● 便利な機能 ○ デプロイ履歴の管理 ○ デプロイ進捗状況の可視化 ○ CloudWatch Alarmと連携した自動ロールバック 43 CodeDeployの概要

Slide 44

Slide 44 text

①デプロイ前 44 CodeDeployの概要 - Blue/Green Deployment ③新環境へ切り替え ⑤手動 / 自動ロールバック ④障害の検知 ②新環境の配備 / 切り替え前動作確認

Slide 45

Slide 45 text

CodeDeployの概要 - デプロイ履歴管理画面 45 デプロイ履歴が確認可能デプロイの詳細の表示 / 停止 / 再試行などのアクションが可能

Slide 46

Slide 46 text

CodeDeployの概要 - デプロイ詳細画面 46 デプロイの進捗状況を可視化停止 / ロールバック等の操作

Slide 47

Slide 47 text

CodeDeployの概要 - デプロイ詳細画面 47 サーバ単位でのより詳細なデプロイ進捗状況

Slide 48

Slide 48 text

CodeDeployの概要 - デプロイ詳細画面 48 デプロイ失敗の際のエラー内容関連するログ

Slide 49

Slide 49 text

④ロールバック演習 - 所感 ● リリース起因での問題は頻度として発生しやすい ● 簡単で安全な素速いロールバックの仕組みが大事 ● 機械的な判断による自動ロールバックで復旧時間を短縮 ● Blue/Green Deploymentを活かして信頼性を向上 ○ 切り替え前の事前動作確認 ○ 高速なロールバック 49

Slide 50

Slide 50 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 50 取り組みを支えるツール /サービスも紹介

Slide 51

Slide 51 text

● 概要 ○ 障害でデータが壊れたと仮定して、バックアップから復旧操作を実施 ○ 対象はデータベース (Aurora RDS)と検索システム(Solr on EC2) ● 目的 ○ 大規模災害を想定したデータの復旧操作の確認と見直し ○ RTO の確認と見直し ● 背景 ○ 過去に1度データが壊れたことがあり、復旧操作や時間見積もりに苦労 51 ⑤DR演習

Slide 52

Slide 52 text

⑤DR演習 - イメージ 52 ①DR対応のWikiの読み合わせ ②対象の復旧オペレーション ④RTOの見直し ③DR対応のWikiの見直し ✏

Slide 53

Slide 53 text

⑤DR演習 - 振り返り ● DRは滅多に発生しないが発生した時の影響が大きい ● RTOは様々な要因で変化 ○ データ量の増加 ○ インフラ構成の見直し ○ RTOに影響するAWSの新機能の利用 ● 定期的な実施による見直しが必要 ○ DR対応のWikiの見直し ○ RTOの見直し 53

Slide 54

Slide 54 text

目次 ● はじめに ● Typetalkの障害対応の運用 ● Typetalkの信頼性向上の取り組み ○ ①障害対応フロー演習 ○ ②性能試験 ○ ③Game Day ○ ④ロールバック演習 ○ ⑤DR演習 ● まとめ 54 取り組みを支えるツール /サービスも紹介

Slide 55

Slide 55 text

● 障害対策は事前準備が大事 ● 障害対策はアーキテクチャ強化以外にも様々な対策が有効 ● 障害対応は障害演習を通じて鍛えること可能 ● 限りなく本番環境に近い演習が効果的 ● 定期的に改善を積み重ねていくことが大事 ● ツールやサービスを活用による効率的な障害対策 ● 今後もお客様が安心してご利用できるサービス提供に努めてまいります！まとめ 55

Slide 56

Slide 56 text

END 56