CloudNative環境におけるトラブルシューティングガイド / CloudNative Days Tokyo 2023

2023/12/12のCloudNative Days Tokyo2023の「CloudNative環境におけるトラブルシューティングガイド」の登壇資料です。

https://event.cloudnativedays.jp/cndt2023/talks/2001

1. CloudNative Days Tokyo2023 CloudNative環境におけ トラブルシューティングガイド Merpay/Mercoin SRE @tjun Junichiro Takagi https://speakerdeck.com/tjun/20231212-cndt
2. 今日の内容 CloudNativeな環境でSREとしてサービスを5年以上運用してきた経験をもとに、 自分がどの うにさまざまなトラブルを解決してきたかを紹介します。 話したいこと CloudNativeな環境におけ アラートや障害などのシステムトラブルに対して、 どの うに調査・対応を行ってい か 話さないこと 障害対応のコミュニケーションやインシデント管理など、組織的な取 組み セキュリティ系のトラブル対応 ※ Kubernetesを知ってい ことを前提とした話を含みますが、雰囲気は分か かと思います
3. 自己紹介 Junichiro Takagi @tjun Merpay/Mercoin SRE Tech Lead 2018 MerpayにSREとして入社 2019 Merpayリリース 2023 Mercoinリリース 金融系サービスのSREを5年く いやっています。
4. (参考)Merpay/Mercoinの技術スタック マイクロサービスアーキテクチャ Google Cloud Platform • Kubernetes (GKE) • Cloud Spanner CDN/WAF • Fastly Observability • Datadog API Gateway Authority API Service X API Service Y Google Cloud Load Balancer Service A Service B Google Kubernetes Engine Service C Web Service Z Cloud Spanner Project A Cloud Spanner Cloud Pub/Sub Project B Project GKE Project C Cloud Spanner Cloud Storage
5. トラブルシューティング システムを運用してい と、想定して いなかった問題が突然発生します トラブルシューティングとは、システムや ネットワークなどの運用中に発生した問題を 特定し、原因を解析して解決す プロセスや 活動のこと
6. • アプリなどのクライアントか のリクエストを受け • クラウド上でシステムを構築 ◦ LoadBalancerやGateway的なものがい ◦ 後 に複数のコンテナベースのアプリケーション ◦ さ にその後 にDatabaseがあ 今日の話で想定す CloudNativeなアーキテクチャ LB service A service B service C Database Database
7. CloudNativeな環境におけ 運用の特徴 オートスケーリングやオートヒーリングなどクラウドが提供す 機能を使うことで、あ 程度の負荷やインスタンスの障害などには対応でき • Kubernetesの場合 ◦ Horizontal Pod Autoscalerを設定す ことで自動的にPodを増やすことができ ◦ liveness/readinessProbeを設定す ことで、Podを作 直した readyにな までトラ フィックを流さないことができ マネージドなデータベースやミドルウェアを利用す ことで、インフラの運用も比較的 簡単にな • 冗長構成なども取 やすい CloudNativeな環境でもトラブルは必ず起きます…！😭
8. 今日の流 • CloudNative環境で発生す システムトラブルの紹介 • トラブルに対応す ために必要な準備 • 実際のトラブル対応方法 • トラブルシューティング事例 • 次のトラブルを防ぐための改善
9. CloudNative環境におけ トラブル
10. CloudNativeな環境のトラブル CloudNativeなシステムにおいても、もち んさまざまなトラブルが あ ます。CloudNative環境でも防げないトラブルとして思いつくものを いくつか紹介します。 • クラウド自体の障害 • オートスケーリングでも救えないケース • オートヒーリングでも救えないケース
11. クラウドサービスの多くは可用性に関す SLAを設定しています。 そのため、あ 程度利用できない時間を許容して利用す ことにな ます。 SLA per week per month 99.9% 10.1 minutes 43.2 minutes 99.95% 5.04 minutes 21.6 minutes 99.99% 60.5 seconds 4.32 minutes 99.999% 6.05 seconds 25.9 seconds CloudNative環境のトラブル クラウドの障害 参考: https://sre.google/sre-book/availability-table/ Allowed unavailability window
12. Statusページに載 うな規模の大きな障害もあ ば、VMインスタンスや ネットワークなどにおけ 限定的な影響の問題が起き こともあ ます https://health.aws.amazon.com/health/status CloudNative環境のトラブル クラウドの障害
13. 急なリクエスト増などの高負荷にはオートスケーリングで対応したいが、 期待どお 対応できないこともあ ます • 設定したMax値やクラウドリソースの上限（Quota）に当たってしまう • オートスケールが間に合わない • 依存す 外部システムのキャパシティの限界 • 期待通 オートスケールできない CloudNative環境のトラブル オートスケーリングで救えないケース
14. 設定したオートスケールの限界（Max）値に達す オートスケーリングの設定をす とき、MinとMaxの値を設定します。 想定以上の負荷で、Maxまでスケールしても足 ない場合は対応できません。 コンテナ側はスケールできても、データベースは増やせない場合などもあ ます。 クラウドリソースの上限（Quota）に達す クラウドではAPI呼び出し回数やインスタンス数に対して、Quotaと呼ば 上限 が設定さ てお 、こ を上回 リクエストをしてもエラーとな ます。 （申請す ばQuotaを増やせ ものもあ ） CloudNative環境のトラブル オートスケーリングで救えないケース
15. オートスケーリングが間に合わない KubernetesのDeployment, NodePoolとデータベースに対してオートスケールの 設定をしていても、KubernetesやデータベースのNodeが増えて利用可能にな まで には数分程度時間がかか ます PodがスケールしたくてもNodeが増え のを待つ必要があった 、Podが増えてもデー タベースがボトルネックになった 、システム全体のスケーリングには時間がかか ます 通常時のN倍といった、スパイクの うに増え リクエストに即座に対応す のは (reactiveな)オートスケールには難しい CloudNative環境のトラブル オートスケーリングで救えないケース
16. 期待どお オートスケールできない まずはCPU使用率をもとにオートスケール設定す ことが多いと思います CPU使用率が上が 前にメモリ使用率が増えてOut of memoryにな など、 オートスケールのしきい値に達す 前に別の問題が起きてしまうとオートスケール できないことがあ ます CloudNative環境のトラブル オートスケーリングで救えないケース spec: scaleTargetRef: kind: Deployment minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 50 Horizontal Pod Autoscalerの設定例
17. オートヒーリングとは 監視に基づいて問題を検知し、自動的にシステムを自動で修復す 機能。 KubernetesではLiveness/Readiness Probeを設定す ことで、問 題があ Podを再起動した トラフィックを送 ないことができ 。 何かの理由で再起動しても同じ問題が起き 場合、オートヒーリングで 救えません • メモリ不足やDBセッションのリークなど、なんども再現す 問題があ • 依存してい システムに問題があ CloudNative環境のトラブル オートヒーリングで救えないケース
18. CloudNative環境におけ トラブルへの準備
19. 準備0: 自分が運用してい システムの構成を理解す システムが複雑になっていくと、システムの全体を理解す のが難しくなっていく • メルペイも100以上のマイクロサービスがあ 、すべて把握してい 人はいない 全体のアーキテクチャ + 自分が担当してい サービスまでの経路 + 自分が担当 す サービスの周 はあ 程度把握していないと、トラブルシューティングは難しい
20. 準備0: 自分が運用してい システムの構成を理解す • クライアントか どの うにリクエストが来て、どの うなシステムを 経由してレスポンスを返すのか • どの機能やどのクラウドサービスに依存してい のか LB service A service B service C Database Database
21. 準備1: 自分たちのシステムの正常な状態を定義す 自分たちが目標とす サービスの信頼性を数値で決め SLO= Service Level Objective お客様の 体験 信頼性 (&コスト) SLO SLO未達で 体験が悪い状態 目標以上の信頼性を実現するには 高いコストと時間がかかる 参考: Shrinking the impact of production incidents using SRE principles—CRE Life Lessons https://cloud.google.com/blog/products/devops-sre/shrinking-the-impact-of-production-incidents-using-sre-principles-cre-life-lessons
22. 準備1: 自分たちのシステムの正常な状態を定義す SLOの例 • 99.9%の可用性 • 99%のリクエストは1秒以内に応答す SLOを設定す • 目標を決めて、障害として対応す ラインを決め • 高すぎ 目標を設定す と、アラートが増えて運用の負担が増え • クラウドのSLAを超え SLOを設定しても達成できない
23. 準備2: トラブルを観測でき うにす 目標として決めたSLOを、達成できてい のかどうか確認でき →目標を満たせてないときに、アラートとして通知す SLOを作 構成要素とな システムの各種メトリクスも取得し、あき かな 異常の場合は検知してアラートでき うにす https://www.datadoghq.com/blog/slo-monitoring-tracking/
24. 準備3: トラブルを調査でき うにす トラブルが観測できたときに、そこか 深掘 し て調査す ためには、さまざまなデータが必要 メトリクス、ログ、トレーシングを使って、問題の深 掘 ができ 状態を準備す 参考: What is Observability | New Relic https://newrelic.com/blog/best-practices/what-is-observability
25. 準備3: トラブルを調査でき うにす Observability（可観測性） Log アクセスログやアプリケーションのログを見 ことで時系列な分析がで き 。エラーメッセージやスタックトレースを通じて、どこでどの うな 問題が起きたか把握でき Metrics システムの状態や負荷の変動を数値的に確認でき 。 トラブルが起きた際の異常な値を知 ことができた 、変化のトレンド を把握す こともでき Trace 一連のリクエストやトランザクションがシステムの異な 部分を通過す 過程で、各サービスやコンポーネントがど だけの時間を要していた かを特定し、パフォーマンスのボトルネック発見に利用でき
26. 会場アンケート: Observabilityツールの利用について どの うにObservabilityの環境を構築していますか？ 1. CloudWatch(AWS), Cloud Monitoring(GCP)などクラウド プロバイダーが提供す ツールを利用 2. Datadog, Dynatrace, New Relicなど専用のサービスを利用 3. Prometheusなどを使って自分たちで構築
27. 会場アンケート: アラート対応と緊急度について みなさんどの うにアラート通知を受け取って対応していますか？ 1. PagerDutyなどのツールを使ってコールして、夜間休日でも即時対応 2. Slack, Email等の通知を使って、気づいた 対応 3. 定期的にDashboardを見て確認す
28. CloudNative環境におけ トラブルへの対応
29. トラブルシューティングの流 問題の検知 問題の把握 原因の特定 暫定対応 復旧確認 問題を発生してか 、な べく早く検知し、原因を特定して対応す ことで、 サービスへの影響を減 すことができ 。 問題発生 復旧
30. トラブルシューティング1: 問題を把握す まずは客観的な目線で、何が起きてい かを把握す いつか 、どこで、何が起きてい か • いつか 発生したのか • どこで ◦ どのマイクロサービス ◦ 外側か 見ていったときに、どこか 発生してい のか • どの うな問題が起きてい のか ◦ エラーが増えてい ◦ レイテンシが上昇 ◦ Unavailable Podが増えてい
31. トラブルシューティング1: 問題を把握す 問題把握す 際のポイント メトリクスを見て、実際に起きてい 問題以外にも変化がないか確認す • リクエストは増えてい か • オートスケールは発動してい か 正常な部分と異常な部分を切 分け • リクエストが届く経路や依存す コンポーネントは正常か確認す 原因の断定を焦 ない • エラーが増えてい とこ は実は根本原因ではなく、他の箇所の問題の影響を 受けた結果、ということは くあ
32. トラブルシューティング2: 問題の原因を調査す い い なアプローチで調査す • 仮説を立て →裏付け データがないか確認す 　の繰 返し • マクロ（メトリクス）とミクロ（ログやトレース）を行き来す ◦ メトリクスに変化が起きた時刻のログを見 ◦ 気にな ログを見つけた 、このエラーはいつか 発生していたのか確認す • 思いついたこと/気になったことは他の人にも共有す ◦ xxで問題が起きてい 可能性はないかな？ ◦ このエラーログは関係あ ますか？
33. トラブルシューティング2: 問題の原因を調査す エラー増加の原因調査 アプリケーションログをとにかく見て、気にな エラーメッセージがないか調べ • エラーメッセージで検索してみ （Google, Slack, GitHub） • いつか 発生していたか調べ • エラーの発生場所やタイミングに偏 はないか確認す Datadogでのpodごとのエラー数確認例
34. トラブルシューティング2: 問題の原因を調査す レイテンシ増加やタイムアウトエラー • トレースを見て、時間がかかってい 箇所が特定できないか調べ • 同じ時間帯の各種メトリクスを確認す ◦ CPU/Memory、DBレイテンシに問題はなかったか • ネットワークの外側（クライアント側）か 順に追っていく ◦ アクセスログを見てどこまでリクエストが届いていたのか確認す ◦ どこがタイムアウトエラーを返してい のか ◦ どこでエラーが何件観測さ てい のか
35. トラブルシューティング2: 問題の原因を調査す 切 口を変えて調査す • 発生時刻近くにあった関連す イベントはないか調査す ◦ リクエストの急増 ◦ サービスのデプロイ ◦ 定期バッチ処理の起動 ◦ Kubernetes Eventのログ • 問題に共通す ことはないか ◦ 周期性（実は前日も同じ うな時間に起きていた） ◦ 実は同じシステム依存を持つサービスで問題が起きてい ◦ 同じversionのライブラリを使ってい
36. トラブルシューティング2: 問題の原因を調査す 問題の切 分けのために変化を加えてみ • サービスの１つ前のversionをリリースしてみ • ライブラリを最新版にして、リリースしてみ • デバッグログを追加してデプロイしてみ • KubernetesのPodやNodeを再起動してみ • リソースの値を増やしてみ ◦ CPU/Memoryを増やす ◦ Pod数やDatabaseのNode数を増やす • 裏で動いてい バッチ処理を止めてみ 変更してみて直 ばいいし、直 なくても原因の候補が１つ潰せ
37. トラブルシューティング2: 問題の原因を調査す 原因調査の難しいポイント • エラーログとして、直接の原因とな エラー も、問題の影響を 受けたことに エラーが多く出 ため、本来知 たいエラーが埋も てしまう ◦ Request timeout error、Connection errorなど • クラウド内部のことは分か ないので、クラウドインフラで問題が 発生したかどうか自分たちでは確認できない ◦ サポートチケットを切 ことで確認でき こともあ
38. トラブルシューティング2:問題の原因を調査す クラウドへのサポートチケットの起票 クラウドプロバイダーが提供す サービスに問題があ と考え とき、 サポートチケットを作 調査を依頼す ことができます。（契約次第） サポートチケットを作 ときのポイント: 問題を具体的に記述す • 発生してい サービス（インスタンス名、リージョン、テーブル名など） • いつか 問題が始まったか、きっかけとな イベントはあ か ◦ 例: x月x日のxx:xx(JST)か 。その前にxxをver x.xxにアップデートした • どの うな問題が起きてい か ◦ 確認でき ログやメトリクスがあ ば添付す • 深刻度、ビジネスへのインパクト • 自分たちで調査した内容
39. トラブルシューティング3: 問題の修正案を考え 問題の原因があ 程度特定できた 、修正対応 • アプリケーションコードを修正してデプロイ • 不足してい リソースを追加して手動でスケールアウトす • 問題が起きてい コンポーネントの退避や再起動 修正がすぐできない/どうしても負荷に耐え ないと判断した場合の対応 • Rate Limitなどを設定してリクエスト数を制限す • メンテナンスモードに入 てリクエストを止め → リクエスト再開時に、負荷をさばくための十分なリソースがあ ことを確認す
40. トラブルシューティング4: 問題の復旧を確認す 暫定対応が終わった 、復旧を確認す • 影響を受けていたメトリクスがもとに戻ったこと • 増えていたエラーが止まったこと • サービスが想定通 利用可能なこと 再発可能性について確認・共有す • 再起動して収まったが、根本的な原因が分か ないので再発す かも し ません、もし発生した 再起動お願いします
41. 事例紹介 ※ 紹介す 事例は、自分が所属す メルペイ/メルコインだけでなく、副業で経験した話や他社のSREか 　　聞いた話も含みます
42. 発生したトラブル • いくつかのマイクロサービスでエラーが増加 • そ ぞ のマイクロサービスには直接の依存関係はない 調査 • エラー率があがったPodを確認す と偏 が見 た （一部のPodのみにエラーが出てその他のPodは正常） • Podが動いてい Nodeを確認す と、エラー率が上昇 していた他のサービスのPodも存在していた 復旧対応 • Nodeを退避してPodを別のNodeへ移すことで問題は解消 事例紹介1 Kubernetes Nodeの不調 Podごとのエラー数
43. 発生したトラブル あ イベントに って想定を超え リクエストが来た 複数のマイクロサービスでエラーの増加などの問題が発生 調査 Kubernetesリソースの状態やエラー内容を確認したとこ 、 Pod数がオートスケールの上限に貼 付いてい サービス、 Database側のスケールが間に合ってないサービスなどがあった 対応 リソースが不足してい 部分のオートスケールのMin/Max値を上 げ ことでエラーが解消し、リクエストをさばけ うになった 事例紹介2 想定を超え リクエスト数の増加
44. 発生したトラブル 社内ツールが利用できなくな という問い合わせがあった。 Kubernetes deploymentのrollout restartす と解消した が、数日後に再発した 調査 DBのsession poolを使い切っていてセッションが作成できないと いうエラーが出ていた。Podごとのセッション数を確認したとこ 、 一つのPodでセッションをmaxまで使い切っていた 復旧対応 セッションのリークの原因をすぐに特定す ことができなかった。 DBへリクエストを投げ 処理を定期実行して、失敗した livenessProbeがエラーとな 対応を入 て、自動的に再起動 す うにした 事例紹介3 Databaseセッションのリーク Podごとの使用DBセッション数
45. 発生したトラブル 多くのサービスにおいて、レイテンシの99パーセンタイルのレイテンシが継続的に悪化 調査 各サービスにおいてデータベースへの読み書きの99パーセンタイルレイテンシが増加してい ことが確認できた。その原因についてさ に調査を行ったが原因がすぐに分か なかったので、 サポートチケットを起票して調査を依頼 復旧対応 クラウド側の、マイクロサービスが動くシステムとデータベース間のネットワークで問題があ 一時的にレイテンシへの影響が出ていたことが分かった。 クラウドプロバイダ側の対応に 解消した。 事例紹介4 クラウドのインフラネットワークにおけ 障害
46. 次のトラブルを防ぐために
47. 失敗か 学んで、同じ失敗を繰 返さないことが大事 改善策として根本原因を修正す だけでなく、以下の うな ポイントも検討できます 1. 原因となった箇所の修正 2. 原因の修正が難しい場合、影響を緩和す 対応 3. 類似の問題が別の箇所で発生す ことがないか確認 4. 問題に早く気づくための監視の改善 5. 同じ問題が発生した場合に、早く復旧す ための改善 次のトラブルを防ぐための改善
48. 次のトラブルを防ぐ ポストモーテムの実施 同じトラブルを繰 返さないために、チームで振 返 を行い原因や対策を 検討します • インシデントの内容を確認 ◦ タイムラインとサービスへの影響範囲 • インシデントの原因と対策 ◦ 原因 ◦ 暫定対応 ◦ 再発防止策 重要: 人を避難せず建設的な議論を行う 参考: メルペイにおけ インシデントマネジメントとナレッジシェア https://engineering.mercari.com/blog/entry/20221220-5040a56d02/
49. 次のトラブルを防ぐ Playbookの作成 アラートが来た どの うな対応をす のか、ドキュメントで管理す ことで 次回以降の対応を早くす Title (アラート内容) • アラートがな 理由 • 深刻度と影響範囲（サービスにどの うな影響が出 か） • コンタクト先 (SlackのMention先、PagerDutyのチーム等） • 対応方法 ◦ 調査方法 ◦ 暫定対応 ◦ 復旧確認方法 参考: メルペイのシステム運用とPlaybookの共通管理への挑戦 https://engineering.mercari.com/blog/entry/merpay-operation-and-playbook-challenge/
50. トラブルシューティングの流 （再掲） 問題の検知 問題の把握 原因の特定 暫定対応 復旧確認 問題を発生してか 、な べく早く検知し、原因を特定して対応す ことで、 サービスへの影響を減 すことができ
51. トラブルシューティングにおけ 今後のチャレンジ 課題: あ 程度の経験があ 人がい 方が問題の解決が早い • システムのアーキテクチャについての理解 • 類似の問題を過去に経験してい こと • Observabilityツールの理解 AIアシスタントを活用してトラブルシューティングの知見を蓄積し、誰でも トラブルシューティングができ 仕組みが、今後数年で登場す かも • Amazon Qなどの製品に期待
52. まとめ CloudNativeな環境でシステムを構築す ことで、あ 程度運用を 自動化す ことが可能です。しかし、そ でも必ずトラブルは発生します。 適切な準備をして、トラブルを調査・切 分け・修正でき うにしまし う。 今日紹介した方法が、何か役に立てば幸いです。