Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

tjun
December 11, 2023

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

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

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

tjun

December 11, 2023
Tweet

More Decks by tjun

Other Decks in Technology

Transcript

  1. 今日の内容 CloudNativeな環境でSREとしてサービスを5年以上運用してきた経験をもとに、 自分がどの うにさまざまなトラブルを解決してきたかを紹介します。 話したいこと CloudNativeな環境におけ アラートや障害などのシステムトラブルに対して、 どの うに調査・対応を行ってい か

    話さないこと 障害対応のコミュニケーションやインシデント管理など、組織的な取 組み セキュリティ系のトラブル対応 ※ Kubernetesを知ってい ことを前提とした話を含みますが、雰囲気は分か かと思います
  2. 自己紹介 Junichiro Takagi @tjun Merpay/Mercoin SRE Tech Lead 2018 MerpayにSREとして入社

    2019 Merpayリリース 2023 Mercoinリリース 金融系サービスのSREを5年く いやっています。
  3. (参考)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
  4. • アプリなどのクライアントか のリクエストを受け • クラウド上でシステムを構築 ◦ LoadBalancerやGateway的なものがい ◦ 後 に複数のコンテナベースのアプリケーション

    ◦ さ にその後 にDatabaseがあ 今日の話で想定す CloudNativeなアーキテクチャ LB service A service B service C Database Database
  5. CloudNativeな環境におけ 運用の特徴 オートスケーリングやオートヒーリングなどクラウドが提供す 機能を使うことで、あ 程度の負荷やインスタンスの障害などには対応でき • Kubernetesの場合 ◦ Horizontal Pod

    Autoscalerを設定す ことで自動的にPodを増やすことができ ◦ liveness/readinessProbeを設定す ことで、Podを作 直した readyにな までトラ フィックを流さないことができ マネージドなデータベースやミドルウェアを利用す ことで、インフラの運用も比較的 簡単にな • 冗長構成なども取 やすい CloudNativeな環境でもトラブルは必ず起きます…!😭
  6. クラウドサービスの多くは可用性に関す 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
  7. オートスケーリングが間に合わない KubernetesのDeployment, NodePoolとデータベースに対してオートスケールの 設定をしていても、KubernetesやデータベースのNodeが増えて利用可能にな まで には数分程度時間がかか ます PodがスケールしたくてもNodeが増え のを待つ必要があった 、Podが増えてもデー

    タベースがボトルネックになった 、システム全体のスケーリングには時間がかか ます 通常時のN倍といった、スパイクの うに増え リクエストに即座に対応す のは (reactiveな)オートスケールには難しい CloudNative環境のトラブル オートスケーリングで救えないケース
  8. 期待どお オートスケールできない まずはCPU使用率をもとにオートスケール設定す ことが多いと思います CPU使用率が上が 前にメモリ使用率が増えてOut of memoryにな など、 オートスケールのしきい値に達す

    前に別の問題が起きてしまうとオートスケール できないことがあ ます CloudNative環境のトラブル オートスケーリングで救えないケース spec: scaleTargetRef: kind: Deployment minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 50 Horizontal Pod Autoscalerの設定例
  9. オートヒーリングとは 監視に基づいて問題を検知し、自動的にシステムを自動で修復す 機能。 KubernetesではLiveness/Readiness Probeを設定す ことで、問 題があ Podを再起動した トラフィックを送 ないことができ

    。 何かの理由で再起動しても同じ問題が起き 場合、オートヒーリングで 救えません • メモリ不足やDBセッションのリークなど、なんども再現す 問題があ • 依存してい システムに問題があ CloudNative環境のトラブル オートヒーリングで救えないケース
  10. 準備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
  11. 準備1: 自分たちのシステムの正常な状態を定義す SLOの例 • 99.9%の可用性 • 99%のリクエストは1秒以内に応答す SLOを設定す • 目標を決めて、障害として対応す

    ラインを決め • 高すぎ 目標を設定す と、アラートが増えて運用の負担が増え • クラウドのSLAを超え SLOを設定しても達成できない
  12. 準備3: トラブルを調査でき うにす Observability(可観測性) Log アクセスログやアプリケーションのログを見 ことで時系列な分析がで き 。エラーメッセージやスタックトレースを通じて、どこでどの うな

    問題が起きたか把握でき Metrics システムの状態や負荷の変動を数値的に確認でき 。 トラブルが起きた際の異常な値を知 ことができた 、変化のトレンド を把握す こともでき Trace 一連のリクエストやトランザクションがシステムの異な 部分を通過す 過程で、各サービスやコンポーネントがど だけの時間を要していた かを特定し、パフォーマンスのボトルネック発見に利用でき
  13. トラブルシューティング1: 問題を把握す まずは客観的な目線で、何が起きてい かを把握す いつか 、どこで、何が起きてい か • いつか 発生したのか

    • どこで ◦ どのマイクロサービス ◦ 外側か 見ていったときに、どこか 発生してい のか • どの うな問題が起きてい のか ◦ エラーが増えてい ◦ レイテンシが上昇 ◦ Unavailable Podが増えてい
  14. トラブルシューティング1: 問題を把握す 問題把握す 際のポイント メトリクスを見て、実際に起きてい 問題以外にも変化がないか確認す • リクエストは増えてい か •

    オートスケールは発動してい か 正常な部分と異常な部分を切 分け • リクエストが届く経路や依存す コンポーネントは正常か確認す 原因の断定を焦 ない • エラーが増えてい とこ は実は根本原因ではなく、他の箇所の問題の影響を 受けた結果、ということは くあ
  15. トラブルシューティング2: 問題の原因を調査す い い なアプローチで調査す • 仮説を立て →裏付け データがないか確認す  の繰

    返し • マクロ(メトリクス)とミクロ(ログやトレース)を行き来す ◦ メトリクスに変化が起きた時刻のログを見 ◦ 気にな ログを見つけた 、このエラーはいつか 発生していたのか確認す • 思いついたこと/気になったことは他の人にも共有す ◦ xxで問題が起きてい 可能性はないかな? ◦ このエラーログは関係あ ますか?
  16. トラブルシューティング2: 問題の原因を調査す レイテンシ増加やタイムアウトエラー • トレースを見て、時間がかかってい 箇所が特定できないか調べ • 同じ時間帯の各種メトリクスを確認す ◦ CPU/Memory、DBレイテンシに問題はなかったか

    • ネットワークの外側(クライアント側)か 順に追っていく ◦ アクセスログを見てどこまでリクエストが届いていたのか確認す ◦ どこがタイムアウトエラーを返してい のか ◦ どこでエラーが何件観測さ てい のか
  17. トラブルシューティング2: 問題の原因を調査す 切 口を変えて調査す • 発生時刻近くにあった関連す イベントはないか調査す ◦ リクエストの急増 ◦

    サービスのデプロイ ◦ 定期バッチ処理の起動 ◦ Kubernetes Eventのログ • 問題に共通す ことはないか ◦ 周期性(実は前日も同じ うな時間に起きていた) ◦ 実は同じシステム依存を持つサービスで問題が起きてい ◦ 同じversionのライブラリを使ってい
  18. トラブルシューティング2: 問題の原因を調査す 問題の切 分けのために変化を加えてみ • サービスの1つ前のversionをリリースしてみ • ライブラリを最新版にして、リリースしてみ • デバッグログを追加してデプロイしてみ

    • KubernetesのPodやNodeを再起動してみ • リソースの値を増やしてみ ◦ CPU/Memoryを増やす ◦ Pod数やDatabaseのNode数を増やす • 裏で動いてい バッチ処理を止めてみ 変更してみて直 ばいいし、直 なくても原因の候補が1つ潰せ
  19. トラブルシューティング2: 問題の原因を調査す 原因調査の難しいポイント • エラーログとして、直接の原因とな エラー も、問題の影響を 受けたことに エラーが多く出 ため、本来知

    たいエラーが埋も てしまう ◦ Request timeout error、Connection errorなど • クラウド内部のことは分か ないので、クラウドインフラで問題が 発生したかどうか自分たちでは確認できない ◦ サポートチケットを切 ことで確認でき こともあ
  20. トラブルシューティング2:問題の原因を調査す クラウドへのサポートチケットの起票 クラウドプロバイダーが提供す サービスに問題があ と考え とき、 サポートチケットを作 調査を依頼す ことができます。(契約次第) サポートチケットを作

    ときのポイント: 問題を具体的に記述す • 発生してい サービス(インスタンス名、リージョン、テーブル名など) • いつか 問題が始まったか、きっかけとな イベントはあ か ◦ 例: x月x日のxx:xx(JST)か 。その前にxxをver x.xxにアップデートした • どの うな問題が起きてい か ◦ 確認でき ログやメトリクスがあ ば添付す • 深刻度、ビジネスへのインパクト • 自分たちで調査した内容
  21. トラブルシューティング3: 問題の修正案を考え 問題の原因があ 程度特定できた 、修正対応 • アプリケーションコードを修正してデプロイ • 不足してい リソースを追加して手動でスケールアウトす

    • 問題が起きてい コンポーネントの退避や再起動 修正がすぐできない/どうしても負荷に耐え ないと判断した場合の対応 • Rate Limitなどを設定してリクエスト数を制限す • メンテナンスモードに入 てリクエストを止め → リクエスト再開時に、負荷をさばくための十分なリソースがあ ことを確認す
  22. トラブルシューティング4: 問題の復旧を確認す 暫定対応が終わった 、復旧を確認す • 影響を受けていたメトリクスがもとに戻ったこと • 増えていたエラーが止まったこと • サービスが想定通

    利用可能なこと 再発可能性について確認・共有す • 再起動して収まったが、根本的な原因が分か ないので再発す かも し ません、もし発生した 再起動お願いします
  23. 発生したトラブル • いくつかのマイクロサービスでエラーが増加 • そ ぞ のマイクロサービスには直接の依存関係はない 調査 • エラー率があがったPodを確認す

    と偏 が見 た (一部のPodのみにエラーが出てその他のPodは正常) • Podが動いてい Nodeを確認す と、エラー率が上昇 していた他のサービスのPodも存在していた 復旧対応 • Nodeを退避してPodを別のNodeへ移すことで問題は解消 事例紹介1 Kubernetes Nodeの不調 Podごとのエラー数
  24. 発生したトラブル あ イベントに って想定を超え リクエストが来た 複数のマイクロサービスでエラーの増加などの問題が発生 調査 Kubernetesリソースの状態やエラー内容を確認したとこ 、 Pod数がオートスケールの上限に貼

    付いてい サービス、 Database側のスケールが間に合ってないサービスなどがあった 対応 リソースが不足してい 部分のオートスケールのMin/Max値を上 げ ことでエラーが解消し、リクエストをさばけ うになった 事例紹介2 想定を超え リクエスト数の増加
  25. 発生したトラブル 社内ツールが利用できなくな という問い合わせがあった。 Kubernetes deploymentのrollout restartす と解消した が、数日後に再発した 調査 DBのsession

    poolを使い切っていてセッションが作成できないと いうエラーが出ていた。Podごとのセッション数を確認したとこ 、 一つのPodでセッションをmaxまで使い切っていた 復旧対応 セッションのリークの原因をすぐに特定す ことができなかった。 DBへリクエストを投げ 処理を定期実行して、失敗した livenessProbeがエラーとな 対応を入 て、自動的に再起動 す うにした 事例紹介3 Databaseセッションのリーク Podごとの使用DBセッション数
  26. 失敗か 学んで、同じ失敗を繰 返さないことが大事 改善策として根本原因を修正す だけでなく、以下の うな ポイントも検討できます 1. 原因となった箇所の修正 2.

    原因の修正が難しい場合、影響を緩和す 対応 3. 類似の問題が別の箇所で発生す ことがないか確認 4. 問題に早く気づくための監視の改善 5. 同じ問題が発生した場合に、早く復旧す ための改善 次のトラブルを防ぐための改善
  27. 次のトラブルを防ぐ ポストモーテムの実施 同じトラブルを繰 返さないために、チームで振 返 を行い原因や対策を 検討します • インシデントの内容を確認 ◦

    タイムラインとサービスへの影響範囲 • インシデントの原因と対策 ◦ 原因 ◦ 暫定対応 ◦ 再発防止策 重要: 人を避難せず建設的な議論を行う 参考: メルペイにおけ インシデントマネジメントとナレッジシェア https://engineering.mercari.com/blog/entry/20221220-5040a56d02/
  28. 次のトラブルを防ぐ Playbookの作成 アラートが来た どの うな対応をす のか、ドキュメントで管理す ことで 次回以降の対応を早くす Title (アラート内容)

    • アラートがな 理由 • 深刻度と影響範囲(サービスにどの うな影響が出 か) • コンタクト先 (SlackのMention先、PagerDutyのチーム等) • 対応方法 ◦ 調査方法 ◦ 暫定対応 ◦ 復旧確認方法 参考: メルペイのシステム運用とPlaybookの共通管理への挑戦 https://engineering.mercari.com/blog/entry/merpay-operation-and-playbook-challenge/
  29. トラブルシューティングにおけ 今後のチャレンジ 課題: あ 程度の経験があ 人がい 方が問題の解決が早い • システムのアーキテクチャについての理解 •

    類似の問題を過去に経験してい こと • Observabilityツールの理解 AIアシスタントを活用してトラブルシューティングの知見を蓄積し、誰でも トラブルシューティングができ 仕組みが、今後数年で登場す かも • Amazon Qなどの製品に期待