SaaS運用での大障害の思い出と対策の共有(大噴火編)【WESEEK Tech Conf #6】
- 2. 会社概要 株式会社WESEEK 所在地 ● 本社：〒169-0051東京都新宿区西早稲田2-20-15高田馬場アクセス10F ● サテライトオフィス：〒874-0838大分県別府市荘園9-1 ルーデンス荘園305 代表者 ● 武井 雄紀 2
- 3. 現在の主な事業 1. 通信大手企業の業務フロー自動化プロジェクト 2. ソーシャルゲームの受託開発 3. 自社発オープンソースプロダクト「GROWI」「GROWI.cloud」の開発 3
- 4. GROWIとは 4 快適な情報共有を、全ての人へ ● OSSとして公開している情報共有ツール(ナレッジベース) ● エンジニアに馴染みのあるMarkdown形式で記述可能 ● 柔軟な階層構造での情報管理が可能
- 5. GROWI.cloudとは 情報共有をもっと身近に、もっと手軽に ● OSSであるGROWIを専門的知識がなくても簡単に運用・管理できる、 法人・個人向けの商用サービス ● エンタープライズプランの導入事例 ○ インターネットマルチフィード株式会社様 ○ 株式会社エイチーム様 ○ 株式会社HIKKY(VR法人HIKKY)様 5
- 7. 質問の受付方法について ● Zoomのチャット機能で、発表中も随時質問を受け付けます ○ メッセージの送信先設定は「全員」で！ ● 発表終了後にも10分程度、質疑応答の時間を設けています 7
- 9. 本日の発表 9
- 10. 自己紹介 10 ● 株式会社WESEEK システムエンジニア 佐藤 龍 ● 前職(7.5年)ではサポートセンターのテクニカルエンジニアをしてました ● 現職(3年目)では大手IXの業務自動化システムの機能開発やGROWI.cloudの インフラ構築・運用に携わってます ● Qiitaでは@tatsurou313としてアウトプットしてます
- 11. 発表内容と見どころ 11
- 12. 発表内容と見どころ(1/3) 12 『SaaS運用での大障害の思い出と対策の共有』 ● 先ほどご紹介したGROWI.cloudの運用話です ● 思い出すのもツラいところがありますが、過去に発生した障害の中でも比較 的大きいものを紹介します ○ 当時感じたツラさを聞いてください (^^; ○ 中噴火編よりも高い障害レベルです
- 13. 発表内容と見どころ(2/3) 『SaaS運用での大障害の思い出と対策の共有』 ● 原因と対策は技術・運営の観点で紹介します ○ システム可用性の向上に対するヒントにできる(かも) ○ 同じプロダクトを使っていれば事前に対策できる(かも) ○ 似た構成を使っていれば対策を参考にできる(かも) ○ 障害時の運営方針決定の参考にできる(かも) ● 参考情報のURLはまとめてGitHubに公開しています ○ https://git.io/weseek_techcnf6 ○ 気になった情報は発表中・発表後に参照してください 13
- 14. 発表内容と見どころ(3/3) 『SaaS運用での大障害の思い出と対策の共有』 ● 障害ごとに章が分かれています ● 章は３つに分かれています 「コンテキスト」→「事例紹介」→「まとめと恒久対策」 ● 原因は何か？を考えて頂くのも楽しいかもしれません 14
- 16. GROWI.cloudとはどんなサービス？ ● GROWI.cloudとは ○ OSSのGROWIを専門的知識がなくても簡単に運用・管理できる、法人・個人向けの商 用サービス ○ 要するにGROWI appをディプロイするサービス ● GROWIとGROWI.cloudの違い ○ GROWIはWiki ○ GROWI.cloudはGROWIをCRUDする ○ ユーザーがGROWIを作成するときと、 Wikiを編集するときのWEBサーバは別のもの 16 GROWI App WEBサーバ GROWI.cloud WEBサーバ GROWI.cloud GROWIを作成 する Wikiを編集する CRUD 利用者
- 17. GROWI.cloudはどんな構成？ 17 *0-1 Brigade | Event-driven scripting for Kubernetes. *1-1 を使って、マニフェストをデプロイする 利用者 GROWI ノード 【フロントエンド】 GROWI 作成 (/構成変更/削除) オーダー オーダー helm upgrade helm upgrade 【バックエンド】 【オーダー処理】 【クラスタ】 ... GROWI App GROWI App
- 18. 運用の目標は？ ● GROWI appの稼働率SLO 99.9% * ● まだまだ至らないところですが、一日 換算で許容できる停止時間は 86.44秒 18 * SLO 99.9% は、旧スタンダードプラン以上、5/13リリースの新法人 プランではベーシックプラン以上での提供です GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できな い機能がある バックアップできない 機能は提供できるが縮退状態 高 ↑ 障 害 緊 急 度 ↓ 低
- 20. クラスタは正常な状態のアプリを維持してくれる 20 ● kubernetesはアプリを診断し、異常な場合は再起動する*1-1 ○ livenessProbeにアプリが正常な場合にSuccessとなる処理を定義する ○ livenessProbeがFailureとなるとコンテナをKILLする ○ コンテナはrestartPolicyに従い起動する ● つまり、アプリの正常・異常状態を定義することが重要 *1-1 Liveness Probe、Readiness ProbeおよびStartup Probeを使用する
- 21. GROWI appが提供している機能 21 ● GROWIが提供する機能 ○ Wiki ○ 全文検索 ○ 同時多人数編集 ○ ユーザー認証 ○ メール送付、Slack通知、・・・ ● どの機能が使える状態が正常状態であるとするか？ ● どの機能が使えない状態が異常状態であるとするか？
- 22. GROWI appの機能で回復しないもの(1/2) 22 機能 ドライバ 常時接続 再接続可否 Wiki MongoDBとの接続 (mongoose) YES NO*1-2 (実装依存) 全文検索 Elasticsearchとの接続 (elasticsearch.js) YES NO*1-3 (実装依存) 同時多人数編集（HackMD） MariaDBとの接続 (Sequelize) YES NO*1-4 (実装依存) ユーザー認証（各種認証ミドルウ ェア・認証機構を利用） - NO - メール送付、Slack通知、・・・ 各種ツール NO - *1-2 specifications/server-monitoring.rst at master · mongodb/specifications *1-3 npm i elasticsearch *1-4 https://github.com/hackmdio/codimd/blob/e00eaa82a98423b9eeb904b9c9fc8fc939f9f6e6/lib/models/index.js#L20-L24
- 23. GROWI appの機能で回復しないもの(2/2) 23 機能 ドライバ 常時接続 再接続可否 Wiki MongoDBとの接続 (mongoose) YES NO*1-2 (実装依存) 全文検索 Elasticsearchとの接続 (elasticsearch.js) YES NO*1-3 (実装依存) 同時多人数編集（HackMD） MariaDBとの接続 (Sequelize) YES NO*1-4 (実装依存) ユーザー認証（各種認証ミドルウ ェア・認証機構を利用） - NO - メール送付、Slack通知、・・・ 各種ツール NO - *1-2 specifications/server-monitoring.rst at master · mongodb/specifications *1-3 npm i elasticsearch *1-4 https://github.com/hackmdio/codimd/blob/e00eaa82a98423b9eeb904b9c9fc8fc939f9f6e6/lib/models/index.js#L20-L24
- 24. GROWI appのヘルスチェックを行う(1/2) ● GROWI appのヘルスチェックする対象となる機能は、常時ミドルウェアと 接続していて再接続しない機能 → 『wiki』『全文検索』『同時多人数編集』の3つ ● これらの機能は1度でも使えなくなると回復しない ● いつの間にか使えなくなりユーザーに不便を感じさせてしまう可能性がある 24
- 25. GROWI appのヘルスチェックを行う(2/2) ● 『wiki』『全文検索』 ○ GROWIのヘルスチェックAPIへアクセスする ○ クエリを送信することでミドルウェアとの接続性が確認できる*1-5 ● 『同時多人数編集機能』 ○ HackMDのヘルスチェックAPIへアクセスする ○ DBとの接続性が確認できる*1-6 → ヘルスチェックURLをkubernetesのlivenessProbeに設定する ○ ミドルウェアと接続できなくなった場合は自動でGROWI appが再起動される *1-5 https://github.com/weseek/growi/blob/301f2283bae6f1adc195403ef0a2024b8c3bf78c/src/server/routes/apiv3/healthcheck.js#L80 *1-6 https://artifacthub.io/packages/helm/codimd/codimd?modal=template&template=deployment.yaml 25
- 26. GROWI appが常に正常な状態を維持するようになった ● いつの間にか『Wiki』が使えなくなった場合→自動復旧 ● いつの間にか『全文検索』が使えなくなった場合→自動復旧 ● いつの間にか『同時編集機能』が使えなくなった場合→自動復旧 26
- 27. 大障害1.GROWI app再起動の多発 ● 何が起こったのか？ ○ 1つのGROWI appにおいて再起動が繰り返され、同様 の状態が多数のGROWI appで起こった ● 何が出来なくなるか？何が困るのか？ ○ 複数のユーザーのGROWI appが一切使えない ■ ユーザーの怒る顔が浮かびます... ○ 当然、早々にSLOが維持できなくなってしまう状況とな った 27 GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できない機能がある バックアップできない 機能は提供できるが縮退状態
- 28. まずは状況確認(1/2) ● GROWI appのPodはlivenessProbeが失敗していた ○ livenessProbeが失敗したためPodが再起動されていた ● 特定のノードだけではなく複数のノードで発生 ○ PodのHTTPサーバーが応答していないことは考えづらい → となると、livenessProbeで確認しているミドルウェアにて問題が起こって いる可能性が疑われる 28
- 29. まずは状況確認(2/2) ● ミドルウェアの状態 ○ DBのクラスタステータス・負荷は問題なし ○ Elasticsearchのクラスタステータスは問題なかったが負荷が高騰していた → 接続自体は出来ていたが負荷により応答時間が平常時よりも長く、 livenessProbeのtimeout時間(defaultは1秒)を超えてしまっていた 29
- 30. 検討・暫定対応したこと(1/2) � Elasticsearchの負荷が高騰した理由は不明であり、改善の見込みが立たなか った � ヘルスチェックの間隔を長くする？*1-7→大きな改善はせず � Elasticsearchのリソースを増強する？→大きな改善はせず ● GROWI appが再起動する状況に比べて、全文検索機能が使えないかもしれ ない状態にする方がSLOの観点からも、ユーザーとしても良い → 生かすべきか殺すべきかで、生かすべきという判断 *1-7 Configure Liveness, Readiness and Startup Probes 30
- 32. 大障害1のまとめと恒久対策 ● 事象 ○ GROWI app再起動の多発 ● 原因 ○ Elasticsearchの負荷高騰によりレスポンスが低下した ● 影響 ○ 多数のGROWI appに対してヘルスチェックが失敗し、再起動を繰り返した ● 暫定復旧方法 ○ 一時的にヘルスチェック時のミドルウェア接続性を確認しないようにした ● 恒久対策 ○ GROWIの改修を開発チームへ依頼し、Elasticsearchとの接続が失敗した場合は再接続 できるようにし、ヘルスチェックAPIではミドルウェア毎に接続確認できるようにした *4-6 *4-7 ○ GROWI appのヘルスチェックAPIを新しい仕様に併せて更新した 32 *1-8 https://github.com/weseek/growi/releases/tag/v3.7.7 *1-9 https://github.com/weseek/growi/releases/tag/v4.2.3
- 34. kubernetesのワーカーノード 34 ● ワーカーノード上でアプリケーションが 稼働する ○ 稼働する単位をPodと呼ぶ ● マスターノードはワーカーノードとPod を管理し、クラウドプロバイダー固有の 機能と連携する マスターノード(群) (コントロールプレーン) ワーカーノード(群) Cloud Provider (ex. GKE)
- 35. ワーカーノードを管理するkube-apiserver ● kube-apiserver ○ クラスタ内の全コンポーネ ントのステータスを把握し、 コンポーネント間の連携を 促す ● kubelet ○ マスターノードからの指示 に従い、Node内でPodを 稼働させる 35 マスターノード kube-apiserver kubelet
- 38. コントールプレーンという頭が胴体を管理する 38 ● コントロールプレーンは、 ○ ワーカーノードで稼働するPodを把握 ○ 稼働していないPodは適宜稼働先のワーカ ーノードを探し、稼働できるようにスケジ ューリングする といった管理を行う ● これにより、いつワーカーノードが停止 しても別のワーカーノードでPodが稼働 することができる マスターノード(群) (コントロールプレーン) ワーカーノード(群) Cloud Provider (ex. GKE)
- 41. 大障害2.GROWI appが停止して影響数も増加 ● 何が起こったのか？ ○ GROWI appが停止して影響数も増加 ● 何が出来なくなるか？何が困るのか？ ○ 複数のユーザーのGROWI appが一切使えない ■ ユーザーの怒る顔が浮かびます... ○ 時間経過と共に使えなくなるGROWI appが増え、SLO を維持することが出来ない 41 GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できない機能がある バックアップできない 機能は提供できるが縮退状態
- 42. まずは状況確認(1/2) ● プリエンプティブルノードが再起動した後にGROWI appが再起動していな い ○ しかしプリエンプティブルノードの在庫枯渇ではない ○ (ただし恒久対策として緊急退避はできる用意をしてある) 42
- 43. まずは状況確認(2/2) ● 、、、と思ったが、クラスタのあらゆる状況が確認できない ● マスターノードが停止していた ○ 自動アップグレードの失敗&リトライが繰り返されていた*2-1 ○ kube-apiserverが停止しているとkubernetesクラスタの状態が取得できない ■ kubectlなどのkubernetes APIを必要とする処理は実行不可 ■ ワーカーノードが停止してもkube-apiserver, kube-schedulerがなく回復しな い ○ まるで、頭がなく胴体だけで動いているデュラハンが死を告げに来たようでした・・・ ● 幸いにもPrometheusが動作していたため観測だけは出来た *2-1 gcloud container operations list | Cloud SDK のドキュメント 43
- 44. 検討・暫定対応したこと ● クラウドプロバイダのサポートへ対応を依頼するしかない ● 事象は1日の中で数時間に及び、連日発生したため再発する可能性は高かった ● 暫定対応として、デュラハンとなったとしても胴体だけで少しでも長く生き 続けるという選択を取った ○ ノンプリエンプティブルノードを購入し、プリエンプティブルノードから移動させた ○ Prometheusが停止しないようノンプリエンプティブルノードを占有する構成へ変更し た 44
- 45. 大障害2のまとめと恒久対策 ● 事象 ○ マスターノードが長時間・連日停止した ● 原因 ○ 不明（マネージドサービスのため） ● 影響 ○ その間に停止したプリエンプティブルノードで稼働していた多くのGROWI appが停止 した ● 暫定復旧方法 ○ クラウドプロバイダのサポートに依頼した ○ ノンプリエンプティブルノードを購入してGROWI app/Prometheusを延命させた ● 恒久対策 ○ マスターノードが冗長化されたkubernetesクラスタ*2-2を構築して切り替えた *2-2 Regional clusters | Kubernetes Engine Documentation 45
- 46. 障害を振り返って思うこと ● 技術的な対策をとり、常に稼働率が高まるように努めることが重要 ○ 備えていても障害は起こるもの ○ 一度起こってしまったことが再発しないよう対策を行う ○ メンテナンス作業でも極力作業影響がない方法を模索する ● 稼働率を観測し続ける ○ 何が稼働率を高めるのか、低めるのかを理解する ● ユーザーの満足度も忘れない ○ 稼働率は重要だが絶対的な正しさではない ○ 稼働率に影響がなくともユーザーが不便に感じないような対応が望ましい 46
- 47. 質疑応答 47
- 48. お知らせ① 次回のWESEEK Tech Conf 48
- 49. お知らせ② GROWIについて GROWIのOSS開発に参加しませんか？ GROWI は、WESEEKが開発を行いMITライセンスで公開している オープンソースソフトウェアです。 開発を手伝っていただけるエンジニアの方を募集しております。 詳しくはGROWI公式サイトのJOIN USをご覧ください。 https://growi.org/ja/#joinus 49
Editor's Notes
- #16: 目安経過時間: 10m 障害について紹介する前に運用対象である GROWI.cloud について紹介します。
- #17: GROWI appというものを説明する
- #20: 目安経過時間: 15m
- #23: 機能によってはミドルウェアと接続が必要なものがあります。 ミドルウェアに接続するときに使うドライバが常時接続(初期化タイミングが1回だけも含む)しているか、機能を使うタイミングで都度接続をするかといった違いがあります。 都度接続するドライバについては、何かエラーが起こってもユーザーがリトライすれば再び機能を使うことが出来るようになります。 しかし、常時接続するドライバについては、何かエラーが起こった時に再接続できない場合はその機能が使えなくなってしまいます。 つまり、「ミドルウェアと常時接続」していて「ミドルウェアに再接続できない」機能が使えなくなった場合はアプリが異常であると定義し、それ以外の場合を正常であると定義するとよさそうです。
- #24: 表中では「**Wiki**」「**全文検索**」「**同時多人数編集**」の 3 つが当てはまります。
- #25: 目安経過時間: 20m
- #28: 目安経過時間: 25m
- #30: GROWI app の Pod の状況を確認すると livenessProbe が失敗しており、そのために Pod が再起動されていることが分かりました。 また、特定のノードで稼働する Pod だけではなく複数のノードでも同様であったため、Pod 側の問題である HTTP サーバが応答しないことは考えづらい状況でした。 となると、livenessProbe で確認しているミドルウェアで問題が起こっている可能性が疑われます。 そこで、ミドルウェアの状態を確認しましたが、DB のクラスタステータス・負荷は問題ありませんでしたが、Elasticsearch がクラスタステータスは問題ないものの負荷が高騰していることが分かりました。 つまり、GROWI app からミドルウェアへ接続は出来ていたものの負荷により応答時間が平常時よりも長く、livebessProbe の timeout 時間(defaultは1秒)を超えてしまっている状況ということが分かりました。
- #31: Elasticsearch の負荷が高騰した理由は不明であり、ヘルスチェックの間隔を長くしても、Elasticsearch のリソースを増強を試みるも大きな改善は見込めず、復旧の目途は立ちませんでした。 そこで、GROWI app が再起動する状況と、全文検索機能が使えなくなっているかもしれない状況にするかのいずれかを選択することになり、SLO の観点からもユーザーとしても良いだろうということで、全文検索が使えなくなった場合に GROWI app は生かすべきという判断を行いました。
- #33: 目安経過時間: 30m
- #38: 目安経過時間: 35m
- #42: 目安経過時間: 40m
- #47: 目安経過時間: 45m