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

2024年5月23日開催『Mackerel Drink Up 出張版＠福岡 (共催：株式会社ヌーラボ)』での発表資料です。

〈概要〉Typetalkが信頼性向上のために実施している取り組みとして、障害演習 / Game Day / 負荷試験などを紹介します。

ヌーラボSRE 二橋
ヌーラボのSREテックリード兼ホライズンテクノロジーの技術顧問。AWSが大好きで、Typetalkを中心にヌーラボの様々なインフラを支えている。子供が2人産まれて、充実した楽しい日々を送っている。

Transcript

1. 信頼性向上のための Typetalkの障害対策の取り組み 株式会社ヌーラボ　二橋 宣友 1
2. 自己紹介 二橋 宣友 (ふたはし ひさとも) @futahashi • 株式会社ヌーラボ SRE テックリード ◦ ビジネスチャットツール Typetalk の SRE 業務 ◦ 他のプロダクトや会社全体の SRE 業務 ◦ AWS 全般の支援＆リード など • ホライズンテクノロジー株式会社 技術顧問 ◦ 技術コンサルティング & 社員技術向上支援 など • 称号 / 資格 / 出版 ◦ 2022 & 2023 APN AWS Top Engineers (Software) ◦ 2023 Japan AWS All Certifications Engineers ◦ Mackerel Ambassador 🐟 2
3. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 3 取り組みを支えるツール /サービスも紹介
4. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 4 取り組みを支えるツール /サービスも紹介
5. • 障害を収束させるために行う一連の作業 ◦ 検知 / 連絡 / 動員 / 調査 / 解決 / 記録 など • 障害の種類 ◦ システムダウン / 異常動作 / 応答速度の低下 / 不正アクセス / サイバー攻撃 など • 障害対応の難しいところ ◦ いつ起きるか / いつ終わるか分からない ◦ 解決方法が定まっていない ◦ システムや技術の深い知識 / 広い知識が必要 ◦ 関係者間の連携が必要 ◦ 頻繁に発生すると疲弊する ◦ 一方でたまにしか発生しないと対応方法に慣れない ◦ 高いプレッシャーの中で素早い判断が求められる ◦ 障害はいつか必ず発生するので避けて通れない 5 はじめに - 障害対応とは？ 🤯🤯
6. 6 • アーキテクチャの強化 ◦ 障害に強いアーキテクチャで障害を予防する • 監視の整備 ◦ 監視で障害や予兆を検知して早期解決 / 回避する • 運用フローの定義 ◦ 予め障害発生時の運用フローを整備しておく • 運用体制の整備 ◦ 障害がいつ発生しても動員できる体制を整える • チームワークの強化 ◦ 障害対応のチームワークを強化する • スキルの強化 ◦ 障害対応の調査 / 復旧スキルを高める はじめに - 障害対策はどうする？
7. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 7 取り組みを支えるツール /サービスも紹介
8. 8 Typetalkの障害対応の運用 - イメージ ①サービス監視 / オン コールによる検知 ②チャット / 通話 / 文書 による意思疎通と記録 (Google Chatは予備) ③障害対応Wiki / 障害対応フロー ⑥ポストモーテムの 記録 / 共有 ✉ ⑤ユーザへの連絡 ④障害の 調査 / 対応
9. • 監視は信頼性を高める重大な要素 ◦ 障害の防止 / 早期対応 • Mackerelでサービスの状況を監視 / 共有 ◦ 内部監視 / 外形監視 / APIの監視 ◦ ダッシュボードで主要メトリックと関連リンクの集約 ◦ リリースイベントの記録と共有 ◦ サービスのメトリック / アラートの状態をチーム間で共有 • PagerDutyをオンコールで利用 ◦ 夜間や休日でもアラートに気づける ◦ 長時間アラートが放置された場合の電話通知 / エスカレーション 9 Typetalkの障害対応の運用 - サービス監視 / オンコール
10. • 複数のチームで連携して収束を目指す • チャットで関係者と連携 ◦ 障害対応の情報共有 / 依頼 • 主対応チームは通話で密な役割分担 / 連携 ◦ 指揮者 / 実作業者 / 書記 / 連絡係 / 顧客対応 • 文書でリアルタイムに情報を記録 / 整理 ◦ 後から参加した人がキャッチアップできる • 文書のテンプレートを用意し作業効率化と漏れの防止 ◦ 障害対応のチェックリスト ◦ 障害対応の役割分担 ◦ 障害に関する情報 (概要 / 影響範囲 / 発生原因 / タイムライン) 10 Typetalkの障害対応の運用 - コミュニケーション
11. • 障害対応時に必要な情報を集約 ◦ ステークホルダー ◦ 連絡手段 / 連絡先 ◦ 障害対応のPlaybook ◦ 緊急時の対応方法 • 障害対応のフローチャート ◦ チーム毎の行動と順序を定義 11 Typetalkの障害対応の運用 - 障害対応Wiki / フロー
12. • ポストモーテムとは？ ◦ 発生した障害についてまとめた文章 ◦ 障害から学び今後の改善に繋げる • 障害記録に加えてフォローアップアクションを記入 ◦ 根本原因 / 再発防止策 ◦ 教訓 ▪ うまくいったこと / いかなかったこと / 幸運だったこと • Backlogの課題で全サービスのポストモーテムを管理 ◦ すべての障害状況を管理 / 可視化 ◦ カスタムフィールドで専用の入力項目を用意 ◦ 検索で過去の障害をキーワード / 日時 / サービス単位などで抽出して振り返り 12 Typetalkの障害対応の運用 - ポストモーテム
13. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 13 取り組みを支えるツール /サービスも紹介
14. • 障害訓練と題して以下を定期開催 ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • 目的 ◦ 障害に強い組織 / システムを作り信頼性を向上する Typetalkの信頼性向上の取り組み - 概要 14
15. • 障害対応の実施 / 改善の機会の減少 ◦ サービスの安定化や障害対応の定型化 • 事業の成長 ◦ 利用者の拡大 / 上場による責任の増加 • 組織の拡大 ◦ チームの細分化 / SREの発足 ◦ 新規SREメンバーの参入 ▪ 障害対応スキルを効率良く習得できる仕組みを与えたい • AWS Well-Architected Tool (WA Tool) / Foundational Technical Review (FTR) の実施 ◦ プラクティスに基づく信頼性向上の気づき 15 Typetalkの信頼性向上の取り組み - きっかけ
16. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 16 取り組みを支えるツール /サービスも紹介
17. • 概要 ◦ 障害が発生した想定で障害対応のコミュニケーションを模擬的に演習 ◦ SRE / 開発者 / カスタマーサポートチームが参加 • 目的 ◦ 障害対応フローの理解 ◦ 障害対応のコミュニケーションの質の向上 • 背景 ◦ 障害対応フロー / コミュニケーションの改善機会が少なかった 17 ①障害対応フロー演習
18. ①障害対応フロー演習 - イメージ 18 ①障害対応Wiki / 障害対応フローの読み合わせ ②演習設定の提示 / 演習実施メンバーの選出 ③模擬演習による障害対応 ④意見交換とWiki / 障害対応フローの見直し ✏
19. • 障害対応の心理的な障壁の低下 ◦ 改めて障害対応のフローを認識できた ◦ 基本的なコミュニケーションのイメージが身に付いた ◦ 特に新入社員 / 障害対応の機会が少なかった人 / 忘れてた人に有効 • チームを越えた活発な意見交換 ◦ 演習を通じて本当の障害も想起されて意見が湧き出た ◦ 障害対応方法を改善する目的で議論する機会を設けられていなかった ◦ 本当の障害時には話せなかった部分も話し合えた • ドキュメントの改善 ◦ ドキュメントの乖離発見 / 改良 • メンバーの信頼関係とサービスの信頼性を向上 19 ①障害対応フロー演習 - 模擬演習の所感
20. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 20 取り組みを支えるツール /サービスも紹介
21. • 概要 ◦ 本番環境と同じ構成の検証環境に負荷を実施 ◦ 負荷の内容はできるだけ本番環境に近いものを再現 • 目的 ◦ 性能問題を事前に発見するため • 背景 ◦ 構成変更の際にパフォーマンス影響を事前に把握しづらかった ▪ 性能問題は、ローカル環境や開発環境で発見しづらい ▪ 性能問題は、大きな損失に繋がりかねない 21 ②性能試験
22. 22 ②性能試験 - イメージ …
 …
 …
 ①負荷開始
 ②ECS Fargate起動 
 ③トラフィック流入
 ④実行結果保存
 ⑤完了通知
 今ならDistributed Load Testing on AWS を使った環境構築を推奨 https://github.com/aws-solutions/distribu ted-load-testing-on-aws ⑥結果確認

23. • 有名なツール ◦ Gatling (Scala) ← Typetalkはこれ ◦ Apache Jmeter (Java) ◦ Locust (Python) ◦ vegeta (Go) • 選定理由 ◦ 性能試験ツールとして有名で実績がある ◦ Typetalkやヌーラボのエンジニアが Scalaに慣れている 23 ②性能試験 - ツール
24. • 直感的で柔軟なプログラミング ◦ 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のテストデータの例 

25. • 性能試験の結果をHTMLで出力 ◦ リクエスト別の統計情報 ◦ レスポンスタイムの分布 ◦ レスポンスコード判定結果 (OK/NG) • スコープダウン / フォーカス機能 ◦ リクエスト別に詳細絞り込み ◦ 気になる時間軸をマウス選択で拡大 25 ②性能試験 - Gatlingの実行結果の例
26. • パフォーマンスに影響するリリース前 • 構成変更時 • 性能チューニング時 • ボトルネックの調査 • リソース調整時 26 ②性能試験 - 実施タイミング
27. • AWS Graviton 2移行 • Amazon Corretto移行 • JDKのバージョン更新 • DBメジャーバージョンアップ • パフォーマンスに影響する機能リリース • 結婚そして出産 27 ②性能試験 - 性能試験のおかげでできたこと
28. • 簡単に性能試験が実現できる時代 (OSS、コンテナ、クラウド) ◦ 性能試験実装に必要なコストも抑えやすい • よりリアルな環境に近づけて事象の再現を目指すのが大事 ◦ 本番同等の構成 / リクエストの量 / リクエスト内容 • 性能試験で性能面で安心できるプロダクトを実現 28 ②性能試験 - 所感
29. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 29 取り組みを支えるツール /サービスも紹介
30. • 概要 ◦ 検証環境で障害を意図的に発生 ◦ 発生した障害によるサービス / 自動復旧 / 監視の挙動を確認 ◦ 障害の調査 / 復旧オペレーションの実施 • 目的 ◦ 障害時のシステムの挙動確認や調査復旧スキルの向上 • 背景 ◦ 新規SREメンバーが障害対応を効果的に学べる環境を提供したかった 30 ③Game Day
31. ③Game Day - イメージ 31 AWS FIS ①検証環境に負荷実行 ②障害をランダムに注入 ③障害要因の特定 / 影響判断 / システム復旧 ④答え合わせ / 振り返り チャットでFISの実験をラ ンダムで実行 本番環境の負荷を再現
32. AWS Fault Injection Simulator (FIS)の概要 • 概要 ◦ 障害を注入するフルマネージドサービス ◦ カオスエンジニアリングや Game Dayに最適 • 前提条件 ◦ FIS用のIAMロールを作成 ◦ (オプションでSSMエージェントを導入) • 機能 ◦ 実験テンプレートの作成 ◦ 実験の管理 (実行 / 停止 / モニタリング) ◦ シナリオライブラリの利用 (AWSが提供するシナリオ ) ◦ スポットインスタンスの中断や RDSのフェイルオーバーの実行なども可能 32
33. FISの概要 - FISの実験テンプレートの作成 • 設定項目 ◦ 説明と名前 ◦ ロール ◦ ターゲット ◦ アクション ◦ (ログ) ◦ (停止条件) 33 公式にIAMロール/ポリシーの例有り https://docs.aws.amazon.com/ja_jp/fis/latest/userguide /security_iam_id-based-policy-examples.html
34. FISの概要 - 実験テンプレートの作成 • 設定項目 ◦ 説明と名前 ◦ ロール ◦ ターゲット ◦ アクション ◦ (ログ) ◦ (停止条件) 34 EC2 / ECS / RDS など色々サポート 数や割合でも選択可能 IDやタグで選択可能
35. FISの概要 - 実験テンプレートの作成 • 設定項目 ◦ 説明と名前 ◦ ロール ◦ ターゲット ◦ アクション ◦ (ログ) ◦ (停止条件) 35 複数アクション可能 用意された 様々なアクション
36. FISの概要 - 実験テンプレートの作成 • 設定項目 ◦ 説明と名前 ◦ ロール ◦ ターゲット ◦ アクション ◦ (ログ) ◦ (停止条件) 36 細かい実行ログまで閲覧可能 (ランダムで選ばれたターゲットIDなど) ガードレールとして設定可能
37. FISの概要 - 実験の管理 37 手動停止も可能 実験の日時 / 状態 /アクション / ターゲット / タイ ムライン等が確認可能
38. ③Game Day - 実験内容の紹介 • 実験の構成 ◦ 1つの実験に付き1アクションのシンプルなシナリオ • ターゲット ◦ 検証環境でタグで絞り込んでランダムに抽出 • アクション ◦ EC2の停止 / 再起動 ◦ RDSのFailover / 再起動 ◦ 特定のProcessをKill (アプリ、ミドル、その他のエージェント ) ◦ CPU / Memory / Network のストレス ◦ EC2のルートボリュームの枯渇 38
39. • FISで障害注入の仕組みを簡単に実装 • 障害対応の経験値の向上 ◦ 障害対応の知識 / 技術共有 ◦ 障害対応への慣れ • システムの動作確認 ◦ 監視項目 / しきい値 / アラートの動作確認 ◦ システムの耐久力 / 回復力の確認 ③Game Day - 所感 39
40. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 40 取り組みを支えるツール /サービスも紹介
41. • 概要 ◦ 過去の特定のバージョンのアプリへロールバックするオペレーションを実施 • 目的 ◦ ロールバックが必要な事態に円滑にロールバックを実行できるようにする • 背景 ◦ 機械的に検知できない異常時に人の判断でロールバックを実行する機会がたまにある (主には社 内環境) 41 ④ロールバック演習
42. 42 ④ロールバック演習 - イメージ ①ロールバックのWikiの読み合わせ ②ロールバックオペレーションの実施 ③ロールバック結果の確認 ④ロールバックのWikiの見直し ✏
43. • CodeDeployとは？ ◦ アプリケーションのデプロイを自動化するサービス ◦ デプロイの管理 / 可視化 / ロールバック • デプロイのターゲット ◦ EC2 / ECS / Lambda / オンプレミス • デプロイの種類 ◦ In-Place Deployment / Blue/Green Deployment • 便利な機能 ◦ デプロイ履歴の管理 ◦ デプロイ進捗状況の可視化 ◦ CloudWatch Alarmと連携した自動ロールバック 43 CodeDeployの概要
44. ①デプロイ前 44 CodeDeployの概要 - Blue/Green Deployment ③新環境へ切り替え ⑤手動 / 自動 ロールバック ④障害の検知 ②新環境の配備 / 切り替え前動作確認
45. CodeDeployの概要 - デプロイ履歴管理画面 45 デプロイ履歴が確認可能 デプロイの詳細の表示 / 停止 / 再試行な どのアクションが可能
46. CodeDeployの概要 - デプロイ詳細画面 46 デプロイの進捗状況を可視化 停止 / ロールバック等の操作
47. CodeDeployの概要 - デプロイ詳細画面 47 サーバ単位でのより詳細な デプロイ進捗状況
48. CodeDeployの概要 - デプロイ詳細画面 48 デプロイ失敗の際の エラー内容 関連するログ
49. ④ロールバック演習 - 所感 • リリース起因での問題は頻度として発生しやすい • 簡単で安全な素速いロールバックの仕組みが大事 • 機械的な判断による自動ロールバックで復旧時間を短縮 • Blue/Green Deploymentを活かして信頼性を向上 ◦ 切り替え前の事前動作確認 ◦ 高速なロールバック 49
50. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 50 取り組みを支えるツール /サービスも紹介
51. • 概要 ◦ 障害でデータが壊れたと仮定して、バックアップから復旧操作を実施 ◦ 対象はデータベース (Aurora RDS)と検索システム(Solr on EC2) • 目的 ◦ 大規模災害を想定したデータの復旧操作の確認と見直し ◦ RTO の確認と見直し • 背景 ◦ 過去に1度データが壊れたことがあり、復旧操作や時間見積もりに苦労 51 ⑤DR演習
52. ⑤DR演習 - イメージ 52 ①DR対応のWikiの読み合わ せ ②対象の復旧オペレーション ④RTOの見直し ③DR対応のWikiの見直し ✏
53. ⑤DR演習 - 振り返り • DRは滅多に発生しないが発生した時の影響が大きい • RTOは様々な要因で変化 ◦ データ量の増加 ◦ インフラ構成の見直し ◦ RTOに影響するAWSの新機能の利用 • 定期的な実施による見直しが必要 ◦ DR対応のWikiの見直し ◦ RTOの見直し 53
54. 目次 • はじめに • Typetalkの障害対応の運用 • Typetalkの信頼性向上の取り組み ◦ ①障害対応フロー演習 ◦ ②性能試験 ◦ ③Game Day ◦ ④ロールバック演習 ◦ ⑤DR演習 • まとめ 54 取り組みを支えるツール /サービスも紹介
55. • 障害対策は事前準備が大事 • 障害対策はアーキテクチャ強化以外にも様々な対策が有効 • 障害対応は障害演習を通じて鍛えること可能 • 限りなく本番環境に近い演習が効果的 • 定期的に改善を積み重ねていくことが大事 • ツールやサービスを活用による効率的な障害対策 • 今後もお客様が安心してご利用できるサービス提供に努めてまいります！ まとめ 55
56. END 56