SaaS運用での大障害の思い出と対策の共有(大噴火編)【WESEEK Tech Conf #6】

SaaS運用での
大障害の思い出と対策の共有
WESEEK Tech Conference #6
大噴火編

会社概要
株式会社WESEEK
所在地
● 本社：〒169-0051東京都新宿区西早稲田2-20-15高田馬場アクセス10F
● サテライトオフィス：〒874-0838大分県別府市荘園9-1 ルーデンス荘園305
代表者
● 武井雄紀
2

現在の主な事業
1. 通信大手企業の業務フロー自動化プロジェクト
2. ソーシャルゲームの受託開発
3. 自社発オープンソースプロダクト「GROWI」「GROWI.cloud」の開発
3

GROWIとは
4
快適な情報共有を、全ての人へ
● OSSとして公開している情報共有ツール(ナレッジベース)
● エンジニアに馴染みのあるMarkdown形式で記述可能
● 柔軟な階層構造での情報管理が可能

GROWI.cloudとは
情報共有をもっと身近に、もっと手軽に
● OSSであるGROWIを専門的知識がなくても簡単に運用・管理できる、
法人・個人向けの商用サービス
● エンタープライズプランの導入事例
○ インターネットマルチフィード株式会社様
○ 株式会社エイチーム様
○ 株式会社HIKKY(VR法人HIKKY)様
5

高い技術力を持つ
エンジニアの知見を社外にも還元する
イベントを通じて
新たな発見に繋がる！
イベントを通じてWESEEKを
知っていただく
私たちが開発するサービスのことも
知っていただければ
6
WESEEK Tech Conferenceを開催する目的

質問の受付方法について
● Zoomのチャット機能で、発表中も随時質問を受け付けます
○ メッセージの送信先設定は「全員」で！
● 発表終了後にも10分程度、質疑応答の時間を設けています
7

ハッシュタグ
【 #WESEEK_tech 】
8

自己紹介
10
● 株式会社WESEEK
システムエンジニア
佐藤龍
● 前職(7.5年)ではサポートセンターのテクニカルエンジニアをしてました
● 現職(3年目)では大手IXの業務自動化システムの機能開発やGROWI.cloudの
インフラ構築・運用に携わってます
● Qiitaでは@tatsurou313としてアウトプットしてます

発表内容と見どころ
11

発表内容と見どころ(1/3)
12
『SaaS運用での大障害の思い出と対策の共有』
● 先ほどご紹介したGROWI.cloudの運用話です
● 思い出すのもツラいところがありますが、過去に発生した障害の中でも比較
的大きいものを紹介します
○ 当時感じたツラさを聞いてください (^^;
○ 中噴火編よりも高い障害レベルです

● 原因と対策は技術・運営の観点で紹介します
○ システム可用性の向上に対するヒントにできる(かも)
○ 同じプロダクトを使っていれば事前に対策できる(かも)
○ 似た構成を使っていれば対策を参考にできる(かも)
○ 障害時の運営方針決定の参考にできる(かも)
● 参考情報のURLはまとめてGitHubに公開しています
○ https://git.io/weseek_techcnf6
○ 気になった情報は発表中・発表後に参照してください
13

● 障害ごとに章が分かれています
● 章は３つに分かれています
「コンテキスト」→「事例紹介」→「まとめと恒久対策」
● 原因は何か？を考えて頂くのも楽しいかもしれません
14

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
利用者

GROWI.cloudはどんな構成？
17
*0-1 Brigade | Event-driven scripting for Kubernetes.
*1-1
を使って、マニフェストをデプロイする
利用者
GROWI ノード
【フロントエンド】
GROWI 作成 (/構成変更/削除)
オーダー
オーダー
helm
upgrade
helm
upgrade
【バックエンド】
【オーダー処理】
【クラスタ】
...
GROWI App
GROWI App

運用の目標は？
● 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上でバグなどにより利用できな
い機能がある
バックアップできない
機能は提供できるが縮退状態
高
↑
障
害
緊
急
度
↓
低

1章.生かすべきか殺す
べきか、それが問題だ
19
障害Lv

クラスタは正常な状態のアプリを維持してくれる
20
● kubernetesはアプリを診断し、異常な場合は再起動する*1-1
○ livenessProbeにアプリが正常な場合にSuccessとなる処理を定義する
○ livenessProbeがFailureとなるとコンテナをKILLする
○ コンテナはrestartPolicyに従い起動する
● つまり、アプリの正常・異常状態を定義することが重要
*1-1 Liveness Probe、Readiness ProbeおよびStartup Probeを使用する

GROWI appが提供している機能
21
● GROWIが提供する機能
○ Wiki
○ 全文検索
○ 同時多人数編集
○ ユーザー認証
○ メール送付、Slack通知、・・・
● どの機能が使える状態が正常状態であるとするか？
● どの機能が使えない状態が異常状態であるとするか？

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

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

GROWI appのヘルスチェックを行う(1/2)
● GROWI appのヘルスチェックする対象となる機能は、常時ミドルウェアと
接続していて再接続しない機能
→ 『wiki』『全文検索』『同時多人数編集』の3つ
● これらの機能は1度でも使えなくなると回復しない
● いつの間にか使えなくなりユーザーに不便を感じさせてしまう可能性がある
24

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

GROWI appが常に正常な状態を維持するようになった
● いつの間にか『Wiki』が使えなくなった場合→自動復旧
● いつの間にか『全文検索』が使えなくなった場合→自動復旧
● いつの間にか『同時編集機能』が使えなくなった場合→自動復旧
26

大障害1.GROWI app再起動の多発
● 何が起こったのか？
○ 1つのGROWI appにおいて再起動が繰り返され、同様
の状態が多数のGROWI appで起こった
● 何が出来なくなるか？何が困るのか？
○ 複数のユーザーのGROWI appが一切使えない
■ ユーザーの怒る顔が浮かびます...
○ 当然、早々にSLOが維持できなくなってしまう状況とな
った
27
GROWI.cloud上でバグなどにより利用できない機能がある

まずは状況確認(1/2)
● GROWI appのPodはlivenessProbeが失敗していた
○ livenessProbeが失敗したためPodが再起動されていた
● 特定のノードだけではなく複数のノードで発生
○ PodのHTTPサーバーが応答していないことは考えづらい
→ となると、livenessProbeで確認しているミドルウェアにて問題が起こって
いる可能性が疑われる
28

● ミドルウェアの状態
○ DBのクラスタステータス・負荷は問題なし
○ Elasticsearchのクラスタステータスは問題なかったが負荷が高騰していた
→ 接続自体は出来ていたが負荷により応答時間が平常時よりも長く、
livenessProbeのtimeout時間(defaultは1秒)を超えてしまっていた
29

検討・暫定対応したこと(1/2)
� Elasticsearchの負荷が高騰した理由は不明であり、改善の見込みが立たなか
った
� ヘルスチェックの間隔を長くする？*1-7→大きな改善はせず
� Elasticsearchのリソースを増強する？→大きな改善はせず
● GROWI appが再起動する状況に比べて、全文検索機能が使えないかもしれ
ない状態にする方がSLOの観点からも、ユーザーとしても良い
→ 生かすべきか殺すべきかで、生かすべきという判断
*1-7 Configure Liveness, Readiness and Startup Probes
30

検討・暫定対応したこと(2/2)
● 暫定対応として、ヘルスチェックAPIのミドルウェア接続性を確認するクエ
リを外して事象を収束させた
31

大障害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

2章.デュラハンと化し
たクラスタ
33
障害Lv

kubernetesのワーカーノード
34
● ワーカーノード上でアプリケーションが
稼働する
○ 稼働する単位をPodと呼ぶ
● マスターノードはワーカーノードとPod
を管理し、クラウドプロバイダー固有の
機能と連携する
マスターノード(群)
(コントロールプレーン)
ワーカーノード(群)
Cloud
Provider
(ex. GKE)

ワーカーノードを管理するkube-apiserver
● kube-apiserver
○ クラスタ内の全コンポーネ
ントのステータスを把握し、
コンポーネント間の連携を
促す
● kubelet
○ マスターノードからの指示
に従い、Node内でPodを
稼働させる
35
マスターノード
kube-apiserver
kubelet

Podが稼働するノードをスケジュールするkube-scheduler(1/2)
36
kube-apiserver
kubelet
kube-scheduler
● kube-scheduler
○ Podが稼働するノードを割
り当てる

Podが稼働するノードをスケジュールするkube-scheduler(2/2)
37
kube-apiserver
kube-scheduler
● kube-scheduler
○ Podが稼働するノードを割
り当てる
kubelet

コントールプレーンという頭が胴体を管理する
38
● コントロールプレーンは、
○ ワーカーノードで稼働するPodを把握
○ 稼働していないPodは適宜稼働先のワーカ
ーノードを探し、稼働できるようにスケジ
ューリングする
といった管理を行う
● これにより、いつワーカーノードが停止
しても別のワーカーノードでPodが稼働
することができる
Cloud
Provider
(ex. GKE)

GKEはマスターノードを管理してくれる
39
● GKEはマスターノードを管理してくれる
ので、GKE利用者はワーカーノードを管
理すればよい
Cloud
Provider
(ex. GKE)

ワーカーノードが停止しても自動でアプリが回復する
● ワーカーノードが停止してもアプリは別のワーカーノードで稼働する
● コントロールプレーンはGKEが管理運用してくれる
40

大障害2.GROWI appが停止して影響数も増加
● 何が起こったのか？
○ GROWI appが停止して影響数も増加
● 何が出来なくなるか？何が困るのか？
○ 複数のユーザーのGROWI appが一切使えない
■ ユーザーの怒る顔が浮かびます...
○ 時間経過と共に使えなくなるGROWI appが増え、SLO
を維持することが出来ない
41
GROWI.cloud上でバグなどにより利用できない機能がある

● プリエンプティブルノードが再起動した後にGROWI appが再起動していな
い
○ しかしプリエンプティブルノードの在庫枯渇ではない
○ (ただし恒久対策として緊急退避はできる用意をしてある)
42

● 、、、と思ったが、クラスタのあらゆる状況が確認できない
● マスターノードが停止していた
○ 自動アップグレードの失敗&リトライが繰り返されていた*2-1
○ kube-apiserverが停止しているとkubernetesクラスタの状態が取得できない
■ kubectlなどのkubernetes APIを必要とする処理は実行不可
■ ワーカーノードが停止してもkube-apiserver, kube-schedulerがなく回復しな
い
○ まるで、頭がなく胴体だけで動いているデュラハンが死を告げに来たようでした・・・
● 幸いにもPrometheusが動作していたため観測だけは出来た
*2-1 gcloud container operations list | Cloud SDK のドキュメント
43

検討・暫定対応したこと
● クラウドプロバイダのサポートへ対応を依頼するしかない
● 事象は1日の中で数時間に及び、連日発生したため再発する可能性は高かった
● 暫定対応として、デュラハンとなったとしても胴体だけで少しでも長く生き
続けるという選択を取った
○ ノンプリエンプティブルノードを購入し、プリエンプティブルノードから移動させた
○ Prometheusが停止しないようノンプリエンプティブルノードを占有する構成へ変更し
た
44

大障害2のまとめと恒久対策
● 事象
○ マスターノードが長時間・連日停止した
● 原因
○ 不明（マネージドサービスのため）
● 影響
○ その間に停止したプリエンプティブルノードで稼働していた多くのGROWI appが停止
した
● 暫定復旧方法
○ クラウドプロバイダのサポートに依頼した
○ ノンプリエンプティブルノードを購入してGROWI app/Prometheusを延命させた
● 恒久対策
○ マスターノードが冗長化されたkubernetesクラスタ*2-2を構築して切り替えた
*2-2 Regional clusters | Kubernetes Engine Documentation
45

障害を振り返って思うこと
● 技術的な対策をとり、常に稼働率が高まるように努めることが重要
○ 備えていても障害は起こるもの
○ 一度起こってしまったことが再発しないよう対策を行う
○ メンテナンス作業でも極力作業影響がない方法を模索する
● 稼働率を観測し続ける
○ 何が稼働率を高めるのか、低めるのかを理解する
● ユーザーの満足度も忘れない
○ 稼働率は重要だが絶対的な正しさではない
○ 稼働率に影響がなくともユーザーが不便に感じないような対応が望ましい
46

お知らせ① 次回のWESEEK Tech Conf
48

お知らせ② GROWIについて
GROWIのOSS開発に参加しませんか？
GROWI は、WESEEKが開発を行いMITライセンスで公開している
オープンソースソフトウェアです。
開発を手伝っていただけるエンジニアの方を募集しております。
詳しくはGROWI公式サイトのJOIN USをご覧ください。
https://growi.org/ja/#joinus
49

お知らせ③ GROWI.cloudについて
GROWI.cloudについてもっと知りたい！
サービスの詳細につきましては、GROWI.cloud公式サイトをご確認ください。
https://growi.cloud/
また、GROWI.cloudに関するお問い合わせは、GROWI.cloud公式サイトの
CONTACTからお願いいたします。
https://growicloud.atlassian.net/servicedesk/customer/portal/1
50

お知らせ④ 採用について
一緒に働く仲間を募集中！
東京の高田馬場オフィス、大分の別府サテライトオフィスにてエンジニアを募集
しております。
中途採用だけではなく、インターンシップも積極的に受け入れています！
詳しい募集要項は、弊社HPの採用ページからご確認ください。
https://weseek.co.jp/recruit.html
51

イベントへのご参加ありがとうございました。
アンケートへのご協力をお願いいたします。
WESEEK Tech Conference #6

SaaS運用での大障害の思い出と対策の共有(大噴火編)【WESEEK Tech Conf #6】

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to SaaS運用での大障害の思い出と対策の共有(大噴火編)【WESEEK Tech Conf #6】

Similar to SaaS運用での大障害の思い出と対策の共有(大噴火編)【WESEEK Tech Conf #6】 (20)

More from WESEEKWESEEK

More from WESEEKWESEEK (12)

SaaS運用での大障害の思い出と対策の共有(大噴火編)【WESEEK Tech Conf #6】

Editor's Notes