飲食店のインフラサービス “ダイニー” のトラブル対応のすべて

SRE Lounge #17

July 2nd, 2024

Transcript

1. 飲⾷店のインフラサービス “ダイニー” のトラブル対応のすべて dinii, inc. Hiroaki KARASAWA (karszawa) SRE Lounge #17 2024年07⽉02⽇
2. 2 自己紹介 | 唐澤弘明 | @karszawa 株式会社 dinii (2020~) | VP of Technology Google Cloud Champion Innovator 娘が産まれました
3. 飲⾷店の All in One SaaS “ダイニー”
4. 4 宣伝
5. 5 SRE Lounge #17 参加者および ANDPAD 社員の皆様
6. 6 秋葉原での ディナーやランチ にお困りではないで すか？
7. ダイニーの大規模インシデントの歴史 7 2021/08/15 一部の顧客の巨大なデータ出力で全体がデグレード → 60分のサービス停止 2022/08/11 待機トランザクションが増え続け DB がパンク → 90分のサービス停止 2022/08/19 コネクションプール管理ライブラリのバグで DB 接続が不可に → 90分のサービス停止 2023/11/29 マネージドのデータベースのスケーリングが不可に → 45分のサービス停止 失敗を経るごとに原因が高度化 失敗のたびに学習し、組織として成長しているから 店舗数・機能の増大
8. 8 秋葉原での ディナーやランチ にお困りではないで すか？ （株）アンドパッド
9. 9 秋葉原での ディナーやランチ にお困りではないで すか？ ウルビアマン 秋葉原
10. 10 秋葉原での ディナーやランチ にお困りではないで すか？ 大衆イタリアンかね子
11. 11 秋葉原での ディナーやランチ にお困りではないで すか？ 北海道シントク町 塚田農場
12. 12 秋葉原での ディナーやランチ にお困りではないで すか？ 1.ウルビアマン 2.北海道シントク町 塚田農場 3.金子屋 4.大衆飯店 かね子 秋葉原店 5.大衆イタリアンかね子 秋葉原店 6.炉端バル さま田 7.はなこま 秋葉原店 8.四十八漁場 秋葉原昭和通り口店 9.焼肉韓菜 福寿 秋葉原店 10.宮崎県日南市 塚田農場 秋葉原中央通り店 11.牛たん焼きと伊達ごはんだてなり屋 秋葉原UDX店 12.秋葉原メンゲキ酒場 13.串カツ田中 秋葉原昭和通り店 14.ビーフキッチンスタンド　秋葉原店末広町
13. 13 ぜひ ご利用ください
14. 飲食のインフラが 落ちるとどうなるか？ 14
15. 飲食のインフラが落ちるとどうなるか？ 15 ※ 分かりやすさのために直近の有名な事例として紹介させていただいています。 ※ 有名ではないのでニュースにはなってませんが、ダイニーもゴリゴリ落ちてますし、お客様に迷惑をおかけしてます。 ① 注文ができない ② 注文を確認できない ③ 調理ができない ④ 会計ができない 短時間 & 先会計でもこうなる。 ダイニーがターゲットとする 居酒屋 = 予約 & 長時間 & 後会計 では…
16. ダイニーのインシデント対応（2024年版） 16 インシデント時の被害を最小化するための仕組み • 外部システムとのサーキットブレイカー • スタンドアロン機能 • 大規模障害トリガー インシデント対応を迅速化するための仕組み • インシデント報告フォーマットの整理 • オンコール • メトリクスダッシュボード インシデントを予防・検知するための仕組み • ベータリリース • 大規模障害訓練 • ユーザーサポート体制の構築 • 仕様質問フローの整理 • リリース確認会 • 利用バージョンの監視 振り返りにより再発を防ぐための仕組み • ポストモーテム • パフォーマンスレビュー 本日はこれらを全体的に説明します！
17. 大規模障害訓練 17
18. なぜ大規模障害訓練を行うのか？ 18 大規模障害に対する心構え 󰢃「起こらないでくれ！」 🤔「起こるよ、知らんけど」 🫶「？？？」
19. 大規模障害に対する心構え 19 否定しようのない事実 • 年に1回は必ず大規模な障害が発生している（経験） • 日夜さまざまなサービスで障害が発生している（歴史） 我々のサービスだけが永続的に機能を提供できる保証とは？ → サービスは必ず落ちるという確信を持って事に向き合う。 なぜ大規模障害訓練を行うのか？ A. 必ず起こることだから。必ず起こることに備えない理由を見つける方が難しい。
20. 大規模障害訓練の内容 20 計画 → 実施 → 振り返り • エンジニア、ユーザーサポート、営業の代表が集まりシナリオを設計する • シナリオ = どこのどのコンポーネントがどう壊れてどう治るのか ◦ 案内方法が不安な機能をターゲットにしてみたり • 当日はエンジニア、ユーザーサポート、営業の 全メンバー を集める ◦ 全メンバーを集めるのは大変だが、緊急時はどのみち全メンバーが対応する • 役割決定 ◦ インシデントオーナー ◦ 対外発信責任者 ◦ 顧客対応責任者 ◦ 飲食店役（飲食店の従業員やオーナーになりきって温度感の高い電話をかける）
21. 大規模障害訓練の内容 21 計画 → 実施 → 振り返り 障害シナリオ例） 1. エラーが Slack に大量投稿される 2. 店舗からの問い合わせが多数発生する 3. エンジニアが修正を実施する 4. 徐々に処理できる確率が上がっていく 5. 問題なくすべての処理を実行できる 6. 店舗に顛末を報告する 店舗役として電話をかけるメンバーの様子
22. 大規模障害訓練の実施 22 計画 → 実施 → 振り返り 項目ごとにオーナーを決めて粛々と改善していく フィードバックの例 • 顧客への連絡が遅い • ワークフローがわかりにくい • 誰がどこで連携しているのか分かりにくい → 前提を疑いすべてを洗い出す。
23. 大規模障害訓練よさそう！→ どうやれば上手くいく？ 23 1. 全員集める a. 実際に大規模な障害が発生したら何もしない社員はいない b. 障害は必ず起こる & 障害が発生したら全員が当事者になるということを教育する 2. 振り返りのクロージングに責任を持つ a. 全員を集めるからには最大限の効果を得たい b. 振り返りのアクションを放置するのはもったいなさすぎる 3. 何回でも繰り返す a. 新しい社員がどんどん増えてインシデントの記憶が薄れていく b. インシデントの辛さを知る社員の本気度を見て 新入社員が成長していく ダイニーには #remember_20220811 という Slack チャンネルがある
24. スタンドアロン機能 24
25. スタンドアロン、の前に SLA について 25 ダイニーでは一部のエンタープライズ顧客に対して SLA を設定している SLA = Uptime 99.95% = Monthly Downtime 21.6 mins 店舗でのネットワーク障害も含めると、それ以上のレベルを求めても意味がないので、数値は妥当 どのみち「顧客のサービス提供 = 料理の提供」はダウンタイム 21分で設計する必要があるから Q. 顧客自身（飲食店のオーナー）がダウンタイム 21分をどうやって乗り切るかの設計ができるか？ A. いいえ
26. SLA を定める 26 ≠ 「責任範囲を限定する」🤔 = 「ダウンタイムの体験設計を行う」💪
27. スタンドアロン機能 27 店内の様々な機器をローカルネットワーク内で動かしてしまう ビジネスサイド向け説明資料
28. スタンドアロンの実現まで 28 ダイニーは Node.js や React Native を活用した複数のプロダクトがインターネットを通じて連携するサービス それをローカルネットワークだけで動かすのは並大抵の努力では実現不可能 これだけの投資を行ってきたからこそ、強固な参入障壁になっている ※ ダイニー固有の事情はほとんど無い = 飲食でサービスを提供するなら必ず乗り越えなければならないハードル
29. つまり… 29 安定性への投資（エンジニアリング）が 事業の強度を高めている！ 楽しい！
30. ユーザーサポートとの連携 30
31. “ダイニー” のサポート体制 31 仕様確認は始めに PdM がフィルタリング → 問題があればエンジニアにエスカレーション （あまりに膨大かつインサイトの塊なので） ユーザーにとってはサポート体制まで含めて “ダイニー” というサービス システムが悪いとかサポート体制が悪いとかは顧客には何の関係もない 「システムに寄せる」「サポート体制に寄せる」「両方で冗長構成を作る」 これを全体最適として選択できる視座を持つ。
32. サポート体制のポイント 32 1. 知らなくて当たり前という前提を持つ a. 飲食店営業のすべてを担う巨大なプロダクト b. 知らない仕様がたくさんあってキャッチアップに年単位の時間がかかる 2. カジュアルに質問できる場所を用意する a. Slack の #dev-help チャンネルで仕様に関して気軽に質問できる b. システム化されているので記録として残り続ける c. → 検索で過去の回答を見つけられる & AI 化に期待 3. アップデートを共有する a. 週次のリリースでリリースノートを詳細に書く b. 仕様に関して Notion AI で質問できる
33. 33 Point 1. エンジニアしか理解できない 言葉で書かない Point 2. 画像をたくさん！
34. インシデントレポート 34
35. インシデントレポートと仕様確認の違い 35 仕様確認はなるべくハードルを下げて気軽に行ってもらいたい vs インシデントレポートは調査のために詳細な報告が欲しい → まずは仕様確認として上げてもらい、不具合であればインシデントレポートとして再起票してもらう フォーマット • 発生日時 • 対象プロダクト • 期待する挙動 • 実際の挙動 • 業務影響度 • 影響範囲 • 顧客がどれぐらい困っているか こちらを参考に設計しました 最重要なのは？
36. 「顧客がどれぐらい困っているか」 36 究極、顧客が困っていなければ何の問題もない。 逆説的に言えば インシデント対応の目的 = 顧客の目の前の業務を回復すること 原因分析や発生事由は後回しにしてでも、顧客の業務を回復させる。 例）不正なデータにより注文が出来なくなっている → 不正が生じた理由が分からなくてもデータを修正する ※ 複数人の監視で行う、変更前のスナップショットを取っておく、等のプラクティスは当たり前に実践する
37. オンコール 37
38. オンコールの体制 38 24時間ごとのローテーションでほぼ全エンジニアが対応する システムアラートは Spike.sh から電話がかかってくる ユーザーサポートにて対処不要で緊急を要する対応も電話がかかってくる
39. オンコールの心構え 39 顧客の目の前の業務を回復すること
40. システムメトリクスダッシュボード 40 アラートが鳴ったときにとりあえず見に行く場所 確認の優先順位 1. ユーザーが体験するもの （エラーレート、レイテンシ） 2. 経験則的にインシデントに直結するもの （データベースの CPU 使用率） 3. 調査に役立つ情報 （その他の CPU 使用率、メモリ使用率、ログ） １と２だけをアラート化する CPU 使用率が上がっていたところで スケーリングしてリクエストを捌けていれば何の問題もない
41. オンコールメンバーが実施する被害を食い止めるための工夫 41 経験則的に外部サービスの動作不良がダイニー側に影響を及ぼすことが多い 例）LINE のメッセージ配信のレイテンシが伸びる → チェックインのトランザクションが伸びる → 卓情報のロックが伸びる → 注文が止まる ※ この例は設計自体が間違っているが、誤った設計になりやすいのも事実 サービスの挙動を環境変数だけで切り替えられるようにしておき、 Google Cloud のコンソールから Docker image をそのままで再デプロイする こういった再デプロイの判断・実施をオンコールが行う
42. Q. そんな対応を即座に実施できるか？ 42 挙動を変える実装にしておく = その事象が起こり得ることは認知できている = その事象を検知できるアラートを作成する = すべてのアラートに Runbook を設定する A. できる！
43. 43 すべてこの本に書いてあります
44. ポストモーテム 44
45. ポストモーテム 45 毎週、その週の報告をまとめて振り返りを行っている。 振り返りのポイント • その問題を発生させないためには、どのプロセスで何をしていれば良かったか （人ではなくプロセスに注目する） • その問題をより早く収束させるためには、いつ何をすれば良かったか • 「顧客の業務を回復させること 」を第一優先に動けていたか • 顧客対応者と連携が取れていたか（温度間に差異が無かったか）
46. インシデントスコア 46 各報告を「業務への影響度」ｘ「影響店舗数」でスコアリングし定点観測 業務への影響度 • 店内業務に影響（利便性に軽度の問題） 1 pts • 店内業務の遂行に支障（代替可能） 3 pts • 店内業務の遂行が困難（代替不可能） 5 pts 影響範囲 • 過半数 ~ 全店舗 3 pts • 100 ~ 過半数 2 pts • 1 ~ 数店舗 1 pts 例） • 店内業務に影響（利便性に軽度の問題） 1 pts • 過半数の店舗に影響があった場合 3 pts • インシデントスコア = 1 x 3 = 3 pts
47. インシデントスコア 47 各報告を「業務への影響度」ｘ「影響店舗数」でスコアリングし、件数と合計値を定点観測 とりあえず決めて走り出す。一定やったら基本は変えない。基準が変わらないので変化が見えてくる。 経営会議でインシデントスコアをレポーティング → システムの安定性が顧客目線でメトリクス化される 推測するな、計測せよ。
48. パフォーマンスレビュー 48
49. パフォーマンスレビュー？ 49 システムメトリクスの健全性を週次で確認 基本的にエンジニア全員で確認する 週次 x エンジニア全員という事例はあまり無さそう 前提、ダイニーのエンジニアはクライアントもバックエンドも インフラもすべて触るのでここらへんも知ってる必要があ る。
50. 飲食サービスならではの強い規則性 50 人間の習慣に根ざしたサービスなので予期できない理由で利用が変わらない 分間注文回数のグラフ → 前日、一週間前と比べているがほぼ一致している = 定常的なレビューにも意味がある
51. まとめ 51
52. SRE (Incident Management) というロールで採用してます！ 52 飲食のインフラとしてインシデントレスポンスのクオリティが事業としての強度に直結する = 事業戦略としてここに投資していきたい ※ インシデントの対応自体はメンバー全員でやること & メンバー全員が正しい意識で実施できることに意味がある