Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie SaaS運用での大障害の思い出と対策の共有(中噴火編)【WESEEK Tech Conf #4】
Ähnlich wie SaaS運用での大障害の思い出と対策の共有(中噴火編)【WESEEK Tech Conf #4】 (20)
Mehr von WESEEKWESEEK
Mehr von WESEEKWESEEK (11)
SaaS運用での大障害の思い出と対策の共有(中噴火編)【WESEEK Tech Conf #4】
- 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. 12 『SaaS運用での大障害の思い出と対策の共有』 ● 先ほどご紹介したGROWI.cloudの運用話です ● 思い出すのもツラいところがありますが、過去に発生した障害の中でも比較 的大きいものを紹介します ○ 当時感じたツラさを聞いてください (^^; 発表内容と見どころ(1/3)
- 13. 『SaaS運用での大障害の思い出と対策の共有』 ● 原因と対策は技術・運営の観点で紹介します ○ システム可用性の向上に対するヒントにできる(かも) ○ 同じプロダクトを使っていれば事前に対策できる(かも) ○ 似た構成を使っていれば対策を参考にできる(かも) ○ 障害時の運営方針決定の参考にできる(かも) ● 参考情報のURLはまとめてGitHubに公開しています ○ https://git.io/weseek_techcnf4 ○ 気になった情報は発表中・発表後に参照してください 13 発表内容と見どころ(2/3)
- 14. 発表内容と見どころ(3/3) 『SaaS運用での大障害の思い出と対策の共有』 ● 障害ごとに章が分かれています ● 章は３つに分かれています 「コンテキスト」→「事例紹介」→「まとめと恒久対策」 ● 原因は何か？を考えて頂くのも楽しいかもしれません 14
- 16. SaaS(オープンβ*)運用開始前の準備 16 ● サービスを理解する ● システムを理解する ● 監視の仕組みを理解する ● 運用ツールを理解する ● アラート対応手順を理解する ● 運用の目標を理解する * 2019/8/21～2020/9/3
- 17. どんなサービス？ ● GROWI.cloudとは ○ OSSのGROWIを専門的知識がなくても簡単に運用・管理できる、法人・個人向けの商 用サービス ○ 要するにGROWI appをディプロイするサービス ● GROWIとGROWI.cloudの違い ○ GROWIはWiki ○ GROWI.cloudはGROWIをCRUDする ○ ユーザーがGROWIを作成するときと、 Wikiを編集するときのWEBサーバは別のもの 17 GROWI App WEBサーバ GROWI.cloud WEBサーバ GROWI.cloud GROWIを作成 する Wikiを編集する CRUD 利用者
- 18. どんな構成？ 18 *1-1 Brigade | Event-driven scripting for Kubernetes. *1-1 を使って、マニフェストをデプロイする 利用者 GROWI ノード 【フロントエンド】 GROWI 作成 (/構成変更/削除) オーダー オーダー helm upgrade helm upgrade 【バックエンド】 【オーダー処理】 【クラスタ】 ... GROWI App GROWI App
- 19. どうやって監視している？ 19 19 GROWI app Prometheus server ミドルウェア Alertmanager Slack Grafana *1-2 Prometheus Overview SOME exporter notify push alerts PromQL pull metrics ...
- 20. ステータス確認方法は？ ● GrafanaのDashboardでステータスが確認できる ○ システム全体のステータス ■ 稼働率、異常状態のGROWI app、他... ○ GROWI app単体のステータス ■ プラン、リソース使用率、他... ○ 他... 20 システム全体用ダッシュボード GROWI app単体用ダッシュボード パネル
- 21. アラート対応手順は？ ● アラート対応手順が用意されている ● アラートが発生したら、発生したアラートに対応する手順を実施する ○ 例えば、GROWI appのURLへアクセス不可となった場合にアラートが発生 21
- 22. 運用の目標は？ ● GROWI appの稼働率SLO 99.9% * ● まだまだ至らないところですが、一日 換算で許容できる停止時間は 86.44秒 22 * SLO 99.9% は、旧スタンダードプラン以上、5/13リリースの新法人 プランではベーシックプラン以上での提供です GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できな い機能がある バックアップできない 機能は提供できるが縮退状態 高 ↑ 障 害 緊 急 度 ↓ 低
- 23. 運用準備は整った ● サービスを理解する→OK ● システムを理解する→OK ● 監視の仕組みを理解する→OK ● 運用ツールを理解する→OK ● アラート対応手順を理解する→OK ● 運用の目標を理解する→OK 23
- 24. 大障害1.監視システムの全停止 ● 何が起きたのか？ ○ Prometheus serverが停止した ● 何が出来なくなるか？何が困るのか？ ○ GROWI.cloudを使っているユーザーには何も影響ない ■ 障害緊急度の表にあてはめても一番低 ○ しかし、システムの稼働状況の把握や、サービスの稼働率の 計測、アラート通知が一切できない ■ GROWI.cloudは稼働している？→ 不明 ■ ユーザーはGROWI appを使える？→ 不明 ■ ミドルウェアは稼働している？→ 不明 ○ つまり、SLOを達成できているか分からなくなってしまい、 サービス運営存続に支障が出てしまう 24 GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できない機能がある バックアップできない 機能は提供できるが縮退状態
- 25. Prometheus server Alertmanager Slack Grafana SOME exporter notify push alerts PromQL pull metrics まずは状況確認(1/2) 25 25 GROWI app ミドルウェア ...
- 26. ● Podを見るとPrometheus serverがCrashLoopBackOffとなっていた*1-3 ○ 通常は停止してもk8s clusterのkubeletにより自動再起動される*1-4 ● ログを見るとPrometheus起動時に実行されるhead chunkチェックで不整 合を検知していた*1-5 → 不整合を起こしたhead chunkファイルを削除すればよいと判明 *1-3 トラブルシューティング | Kubernetes Engine ドキュメント *1-4 Liveness Probe、Readiness ProbeおよびStartup Probeを使用する *1-5 opening storage failed: found unsequential head chunk files 23 and 25 · Issue #7412 · prometheus/prometheus 26 まずは状況確認(2/2)
- 27. どうやって不要なhead chunkを消そう？(1/2) ● PrometheusのPodは数秒で停止するためkubectl execではshellを起動でき ない 1. マニフェストのcommandを`sleep infinity`等へ書き換える？ ○ Podのcommandは書き換え不可*1-6 2. マニフェストのrestart policyをNeverへ書き換える？ ○ StatefulSetのrestart policyはAlways以外不可*1-7 3. 同じPVをmountするPodを立ち上げる？ ○ PVがRWOであったため、別Nodeで立ち上がったPodからはアクセス不可*1-8 *1-6 Kubernetes API Reference Docs *1-7 restartPolicy: Unsupported value: "Never": supported values: "Always" *1-8 永続ボリューム 27
- 28. どうやって不要なhead chunkを消そう？(2/2) 4. Prometheusが稼働していたノードへsshログインする？ ○ PodがPVをマウントしているということはのノードがPVをマウントしているということ*1-9 ○ ノードへsshできればPV内のファイルを削除できるはず！ *1-9 詳解KubernetesにおけるPersistentVolume 28
- 29. Prometheusが稼働していたノードへsshログインす る 1. GKEのノードへsshする*1-10 2. PVのmount先を特定する 3. ファイルを消す 29 $ kubectl get pvc storage-volume-admin-prometheus-server-0 Bound pvc-bf8d8e4c-7561-11e9-bef2-42010a920054 XXXGi RWO XXXXX XXXd $ mount | grep bf8d /dev/sdb on /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/gke-growi-cloud-prod-c-pvc-bf8d8e4c-7561-11e9-bef2-42010a920054 type ext4 (rw,relatime,data=ordered) : # cd /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/gke-growi-cloud-prod-c-pvc-bf8d8e4c-7561-11e9-bef2-42010a920054/chunks_head # ls 000618 000619 000621 000622 # rm -f 000621 000622 # ls 000618 000619 *1-10 Using SSH to connect to a cluster node | Anthos clusters on VMware
- 30. 大障害1のまとめと恒久対策 ● 事象 ○ Prometheus serverが停止した ● 原因 ○ Prometheusのhead chunkに不整合が起こり起動しなくなった ● 影響 ○ システムの稼働状況の把握や、サービスの稼働率の計測、アラート通知が一切できず、サービス運営存続に支障 が出てしまう ● 暫定復旧方法 ○ ノードへsshして不整合を起こしたhead chunkを削除した ● 恒久対策 ○ 監視システムが停止したことを監視する ○ Prometheusはv2.19.1以降を使用する ■ head chunkの不整合が起こらないようになった 30
- 32. GROWI.cloudにおけるリソース管理 32 ● 求められる頻度や重要度に応じてリソースの自動スケール・手動スケールを 使い分ける ● ユーザーがサービスを利用したいと思った時に使えるようにする ○ 頻度は人気に応じて上昇・重要 ○ →自動化する！ ● システム維持に必要なリソースを増やす ○ 頻度は低い・重要だが自動化難易度も高い ○ →リソース監視＆メンテナンス作業で対応する
- 33. GROWI app数の増加 kubernetesノード 必要数の増加 狭義の 影響なし 影響なし インストール済chart数の増加 影響なし 33 利用者の増加に伴い増えるリソース 影響度大 * Kubernetes icons * 利用者の増加に伴いGROWI.cloudへのアクセス/GROWI appへのアクセス回数も増加するが、同時間帯アクセスがなければ影響は少ないため割愛
- 34. ノード数を自動で増やす仕組み 34 ● ノードやクラスタのオートスケーラーはCluster Autoscalerと呼ばれる*2-1 ○ GKEはCluster Autoscalerに対応している ● ノードプール（ノードの集まりを指す概念）にてオートスケールを指定でき る*2-1 ○ 増減量はmin/max(per zone)が指定可能 ○ Podをscheduleする際に、request resource分の空きがあるノードが枯渇した場合、 新しいノードが追加される *2-1 Cluster Autoscaler *2-2 クラスタ オートスケーラー | Kubernetes Engine ドキュメント | Google Cloud ノードプール (ex. min:2, max:5) node node new node p o d p o d オートスケール schedule
- 35. ノードのオートスケールができるようになった ● ユーザー増加に伴い必要となるリソースを整理し、影響度が高いノード数の 増加を自動化した ● ノードプールはシステム内の用途に応じて分類し、最も数が必要になる GROWI app実行用のノードは十分な数を設定した → GROWI appが作成されると自動でノードのオートスケールができるように なった 35 ノードプール (～用) ノードプール (～用) ノードプール (～用) ノードプール (GROWI app用) オートスケール
- 36. 大障害2.長時間GROWI appが停止し影響数も増加 ● 何が起こったのか？ ○ 同じノードに載っているGROWI appが一斉に停止し、 起動せず長時間に及んだ ○ 他のノードでも徐々に同じ状況になった ○ いずれのノードもプリエンプティブルノードであった ● 何が出来なくなるか？何が困るのか？ ○ 複数のユーザーのGROWI appが一切使えない ■ ユーザーの怒る顔が浮かびます... ○ プリエンプティブルノードは24h以内に再起動するため、 放置するとSLOを維持できなくなることが明白である 36 GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できない機能がある バックアップできない 機能は提供できるが縮退状態
- 37. まずは状況確認 ● 事象はプリエンプティブルノード(プール)で発生している ● 気がかりなのは、新しく追加したGROWI appが影響を受けているのではな く、既にあるGROWI appが影響を受けていること ○ オートスケールに問題があれば新しく追加したGROWI appが起動しなくなる → ノードプールのノード数maxに到達してはいない ○ オートスケールによるノード削減はありうるが、適切にrequest resourceを設定してい るため、その線も考えにくい 37
- 38. 原因はプリエンプティブルノードの在庫枯渇 ● 原因はプリエンプティブルノードの在庫枯渇であった ○ ノードはGKEが用意してくれるもの ○ 在庫はGKE側で増やしてもらわないといけない ● プリエンプティブルノード再起動時にノード削除と追加が起こっていた ● ノード追加しようとするも在庫がなく、ノードが再起動時に削除のみされて しまっていた 38 プリエンプティブル ノードプール node node new node p o d p o d オートスケール
- 39. 検討・暫定対応したこと ● プリエンプティブルノードの在庫枯渇が解消される目途は不明 ● 数日/数か月かかるとしたらGROWI.cloudユーザーには目もあてら れない ● 暫定対応としてノンプリエンプティブルノードを購入し、プリエン プティブルノードから移動させた ○ 「そもそも本番サービスでプリエンプティブルノード使うなよ」という声も あるかもしれません ○ 下位プランの運用コストを如何に下げるかというチャレンジであり、詳細は 前々回の弊社今間の発表ログ*2-3をご覧ください ● 在庫枯渇が終わり次第元の状態へ戻した 39 *2-3 コスト8割減！k8s本番サービス環境の運用ノウハウ【WESEEK Tech Conf #2】 - connpass
- 40. 大障害2まとめと恒久対策 ● 事象 ○ 長時間GROWI appが停止し影響数も増加 ● 原因 ○ プリエンプティブルノードの在庫が枯渇した ● 影響 ○ 多くのGROWI appにて、稼働するノードがなくなり長時間停止した ● 暫定復旧方法 ○ ノンプリエンプティブルノードを購入してGROWI appを稼働させた ● 恒久対策 ○ 緊急時にノードを退避するためのnodeAffinityを設定した （在庫の枯渇は避けようがないため、再発時の対応を迅速にする対策） 40
- 42. 42 GROWI.cloudというSaaS(1/3) を使って、マニフェストをデプロイする 利用者 GROWI ノード GROWI 作成 (/構成変更/削除) GROWI App GROWI App
- 43. GROWI.cloudというSaaS(2/3) 43 ● (広義の)GROWI.cloudは役割に応じて4つに分解できる ○ フロントエンド ■ ログイン画面、組織の作成・変更操作、GROWI appの作成・変更操作 ○ バックエンド ■ ログイン機能、組織/GROWI appデータ保存、オーダー実行 ○ オーダー処理（brigade, helm含む） ■ オーダーを解釈し、対応するhelmコマンドを生成・実行する ○ クラスタ（kubernetes cluster） ■ GROWI appの稼働、GROWI.cloudシステムプロセス稼働 ● GROWI appの作成・変更操作等をオーダーとして扱い、オーダーを処理する結果としてクラ スタ内のGROWI appをCRUDしている
- 44. GROWI.cloudというSaaS(3/3) 44 を使って、マニフェストをデプロイする 利用者 GROWI ノード 【フロントエンド】 GROWI 作成 (/構成変更/削除) オーダー オーダー helm upgrade helm upgrade 【バックエンド】 【オーダー処理】 【クラスタ】 ... GROWI App GROWI App
- 45. オーダー処理によりユーザー操作を自動でクラスタへ反映できる ● ユーザーが行う操作を自動化できた ○ GROWI appを新しく作成する→自動 ○ 不要となったGROWI appを削除する→自動 ○ GROWI appのバージョンを変更する→自動 ○ 独自ドメインを設定する→自動 ○ 証明書を設定する→自動 45
- 46. 大障害3.GROWI appの新規作成及び更新操作の失敗が多発 ● 何が起こったのか？ ○ GROWI appの新規作成及び更新操作の失敗が多発 ● 何が出来なくなるか？何が困るのか？ ○ ユーザーは作成済みのGROWI appは利用できる ○ GROWI.cloudの操作画面からGROWI appの新規作成 及び更新ができない ○ つまり、SLOは維持ができるが、新規ユーザーを獲得 する機会損失につながり、既存ユーザーは不便な思い をしてしまう 46 GROWI appが停止した Keycloakが停止した HackMDが停止した Elasticsearchが停止した = GROWI appでの全文検索不可 GROWI.cloudサイトが停止した GROWI.cloudにログインできない GROWI.cloudでGROWI appの更新ができない GROWI.cloud上でバグなどにより利用できない機能がある バックアップできない 機能は提供できるが縮退状態
- 47. まずは状況確認(1/2) 47 を使って、マニフェストをデプロイする 利用者 GROWI ノード 【フロントエンド】 GROWI 作成 (/構成変更/削除) オーダー オーダー helm upgrade helm upgrade 【バックエンド】 【オーダー処理】 【クラスタ】 ... GROWI App GROWI App
- 48. まずは状況確認(2/2) ● GROWI.cloudを操作した後、brigadeに対してオーダーが渡っている ○ つまりフロントエンド・バックエンド・クラスタは白 ○ 残るオーダー処理に問題がありそう ● オーダー処理の中でJobをBuildする処理が失敗していた 48 オーダー helm upgrade
- 50. 原因はnpmjsサイトの障害(2/2) ● npmjsサイトの障害により一切のnpmのパッケージダウンロードができなく なった*3-1 ● オーダー処理の中でJobをBuildする処理にて、npmのパッケージを都度ダウ ンロードする必要があり、それが失敗していた → オーダー処理が行えなくなった結果、GROWIの新規作成及び更新ができなく なった *3-1 https://status.npmjs.org/incidents/cksjqc1w11v5 50
- 51. 検討・暫定対応したこと ● npmjsサイトの障害復旧目途は不明 ○ ただし、対応状況の変化が早く、長くても1週間はかからないであろう状況 ● npmのパッケージダウンロードが出来ないと対応手段がない ● GROWI.cloudのNewsとTwitter通知にてアナウンスを行った 51
- 52. 大障害3まとめと恒久対策 ● 事象 ○ GROWI appの新規作成及び更新操作の失敗が多発 ● 原因 ○ npmjsサイトの障害により一切のnpmのパッケージダウンロードができなくなった ● 影響 ○ GROWI Appの新規作成及び更新ができない ● 暫定復旧方法 ○ なし (障害アナウンスのみ) ● 恒久対策 ○ 必要なnpmパッケージをSCM repositoryに含め、都度ダウンロードを不要にした （また、repositoryに含めるにあたり依存するnpmパッケージ数を減らしもしました） 52
- 53. 障害を振り返って思うこと ● 備えていても障害は起こるもの ○ 基本的ですが、一度起こってしまったことが再発しないよう対策を行う ○ 再発の可能性があれば緊急回避手段を用意する ● ユーザーの満足度も忘れない ○ 稼働率は重要だが絶対的な正しさではない ○ 稼働率に影響がなくともユーザーが不便に感じないような対応が望ましい 53
- 55. 質疑応答 55
- 56. お知らせ 次回のWESEEK Tech Conf 56
- 57. お知らせ② GROWIについて GROWIのOSS開発に参加しませんか？ GROWI は、WESEEKが開発を行いMITライセンスで公開している オープンソースソフトウェアです。 開発を手伝っていただけるエンジニアの方を募集しております。 詳しくはGROWI公式サイトのJOIN USをご覧ください。 https://growi.org/ja/#joinus 57