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

Slide 1

Slide 1 text

CloudNative Days Tokyo2023 CloudNative環境におけトラブルシューティングガイド Merpay/Mercoin SRE @tjun Junichiro Takagi https://speakerdeck.com/tjun/20231212-cndt

Slide 2

Slide 2 text

今日の内容 CloudNativeな環境でSREとしてサービスを5年以上運用してきた経験をもとに、自分がどのうにさまざまなトラブルを解決してきたかを紹介します。話したいこと CloudNativeな環境におけアラートや障害などのシステムトラブルに対して、どのうに調査・対応を行っていか話さないこと障害対応のコミュニケーションやインシデント管理など、組織的な取組みセキュリティ系のトラブル対応 ※ Kubernetesを知っていことを前提とした話を含みますが、雰囲気は分かかと思います

Slide 3

Slide 3 text

自己紹介 Junichiro Takagi @tjun Merpay/Mercoin SRE Tech Lead 2018 MerpayにSREとして入社 2019 Merpayリリース 2023 Mercoinリリース金融系サービスのSREを5年くいやっています。

Slide 4

Slide 4 text

(参考)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

Slide 5

Slide 5 text

トラブルシューティングシステムを運用していと、想定していなかった問題が突然発生しますトラブルシューティングとは、システムやネットワークなどの運用中に発生した問題を特定し、原因を解析して解決すプロセスや活動のこと

Slide 6

Slide 6 text

● アプリなどのクライアントかのリクエストを受け ● クラウド上でシステムを構築 ○ LoadBalancerやGateway的なものがい ○ 後に複数のコンテナベースのアプリケーション ○ さにその後にDatabaseがあ今日の話で想定す CloudNativeなアーキテクチャ LB service A service B service C Database Database

Slide 7

Slide 7 text

CloudNativeな環境におけ運用の特徴オートスケーリングやオートヒーリングなどクラウドが提供す機能を使うことで、あ程度の負荷やインスタンスの障害などには対応でき ● Kubernetesの場合 ○ Horizontal Pod Autoscalerを設定すことで自動的にPodを増やすことができ ○ liveness/readinessProbeを設定すことで、Podを作直した readyになまでトラフィックを流さないことができマネージドなデータベースやミドルウェアを利用すことで、インフラの運用も比較的簡単にな ● 冗長構成なども取やすい CloudNativeな環境でもトラブルは必ず起きます…！😭

Slide 8

Slide 8 text

今日の流 ● CloudNative環境で発生すシステムトラブルの紹介 ● トラブルに対応すために必要な準備 ● 実際のトラブル対応方法 ● トラブルシューティング事例 ● 次のトラブルを防ぐための改善

Slide 9

Slide 9 text

CloudNative環境におけトラブル

Slide 10

Slide 10 text

CloudNativeな環境のトラブル CloudNativeなシステムにおいても、もちんさまざまなトラブルがあます。CloudNative環境でも防げないトラブルとして思いつくものをいくつか紹介します。 ● クラウド自体の障害 ● オートスケーリングでも救えないケース ● オートヒーリングでも救えないケース

Slide 11

Slide 11 text

クラウドサービスの多くは可用性に関す 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

Slide 12

Slide 12 text

Statusページに載うな規模の大きな障害もあば、VMインスタンスやネットワークなどにおけ限定的な影響の問題が起きこともあます https://health.aws.amazon.com/health/status CloudNative環境のトラブルクラウドの障害

Slide 13

Slide 13 text

急なリクエスト増などの高負荷にはオートスケーリングで対応したいが、期待どお対応できないこともあます ● 設定したMax値やクラウドリソースの上限（Quota）に当たってしまう ● オートスケールが間に合わない ● 依存す外部システムのキャパシティの限界 ● 期待通オートスケールできない CloudNative環境のトラブルオートスケーリングで救えないケース

Slide 14

Slide 14 text

設定したオートスケールの限界（Max）値に達すオートスケーリングの設定をすとき、MinとMaxの値を設定します。想定以上の負荷で、Maxまでスケールしても足ない場合は対応できません。コンテナ側はスケールできても、データベースは増やせない場合などもあます。クラウドリソースの上限（Quota）に達すクラウドではAPI呼び出し回数やインスタンス数に対して、Quotaと呼ば上限が設定さてお、こを上回リクエストをしてもエラーとなます。（申請すばQuotaを増やせものもあ） CloudNative環境のトラブルオートスケーリングで救えないケース

Slide 15

Slide 15 text

オートスケーリングが間に合わない KubernetesのDeployment, NodePoolとデータベースに対してオートスケールの設定をしていても、KubernetesやデータベースのNodeが増えて利用可能になまでには数分程度時間がかかます PodがスケールしたくてもNodeが増えのを待つ必要があった、Podが増えてもデータベースがボトルネックになった、システム全体のスケーリングには時間がかかます通常時のN倍といった、スパイクのうに増えリクエストに即座に対応すのは (reactiveな)オートスケールには難しい CloudNative環境のトラブルオートスケーリングで救えないケース

Slide 16

Slide 16 text

期待どおオートスケールできないまずはCPU使用率をもとにオートスケール設定すことが多いと思います CPU使用率が上が前にメモリ使用率が増えてOut of memoryにななど、オートスケールのしきい値に達す前に別の問題が起きてしまうとオートスケールできないことがあます CloudNative環境のトラブルオートスケーリングで救えないケース spec: scaleTargetRef: kind: Deployment minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 50 Horizontal Pod Autoscalerの設定例

Slide 17

Slide 17 text

オートヒーリングとは監視に基づいて問題を検知し、自動的にシステムを自動で修復す機能。 KubernetesではLiveness/Readiness Probeを設定すことで、問題があ Podを再起動したトラフィックを送ないことができ。何かの理由で再起動しても同じ問題が起き場合、オートヒーリングで救えません ● メモリ不足やDBセッションのリークなど、なんども再現す問題があ ● 依存していシステムに問題があ CloudNative環境のトラブルオートヒーリングで救えないケース

Slide 18

Slide 18 text

CloudNative環境におけトラブルへの準備

Slide 19

Slide 19 text

準備0: 自分が運用していシステムの構成を理解すシステムが複雑になっていくと、システムの全体を理解すのが難しくなっていく ● メルペイも100以上のマイクロサービスがあ、すべて把握してい人はいない全体のアーキテクチャ + 自分が担当していサービスまでの経路 + 自分が担当すサービスの周はあ程度把握していないと、トラブルシューティングは難しい

Slide 20

Slide 20 text

準備0: 自分が運用していシステムの構成を理解す ● クライアントかどのうにリクエストが来て、どのうなシステムを経由してレスポンスを返すのか ● どの機能やどのクラウドサービスに依存していのか LB service A service B service C Database Database

Slide 21

Slide 21 text

準備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

Slide 22

Slide 22 text

準備1: 自分たちのシステムの正常な状態を定義す SLOの例 ● 99.9%の可用性 ● 99%のリクエストは1秒以内に応答す SLOを設定す ● 目標を決めて、障害として対応すラインを決め ● 高すぎ目標を設定すと、アラートが増えて運用の負担が増え ● クラウドのSLAを超え SLOを設定しても達成できない

Slide 23

Slide 23 text

準備2: トラブルを観測できうにす目標として決めたSLOを、達成できていのかどうか確認でき →目標を満たせてないときに、アラートとして通知す SLOを作構成要素となシステムの各種メトリクスも取得し、あきかな異常の場合は検知してアラートできうにす https://www.datadoghq.com/blog/slo-monitoring-tracking/

Slide 24

Slide 24 text

準備3: トラブルを調査できうにすトラブルが観測できたときに、そこか深掘して調査すためには、さまざまなデータが必要メトリクス、ログ、トレーシングを使って、問題の深掘ができ状態を準備す参考: What is Observability | New Relic https://newrelic.com/blog/best-practices/what-is-observability

Slide 25

Slide 25 text

準備3: トラブルを調査できうにす Observability（可観測性） Log アクセスログやアプリケーションのログを見ことで時系列な分析ができ。エラーメッセージやスタックトレースを通じて、どこでどのうな問題が起きたか把握でき Metrics システムの状態や負荷の変動を数値的に確認でき。トラブルが起きた際の異常な値を知ことができた、変化のトレンドを把握すこともでき Trace 一連のリクエストやトランザクションがシステムの異な部分を通過す過程で、各サービスやコンポーネントがどだけの時間を要していたかを特定し、パフォーマンスのボトルネック発見に利用でき

Slide 26

Slide 26 text

会場アンケート: Observabilityツールの利用についてどのうにObservabilityの環境を構築していますか？ 1. CloudWatch(AWS), Cloud Monitoring(GCP)などクラウドプロバイダーが提供すツールを利用 2. Datadog, Dynatrace, New Relicなど専用のサービスを利用 3. Prometheusなどを使って自分たちで構築

Slide 27

Slide 27 text

会場アンケート: アラート対応と緊急度についてみなさんどのうにアラート通知を受け取って対応していますか？ 1. PagerDutyなどのツールを使ってコールして、夜間休日でも即時対応 2. Slack, Email等の通知を使って、気づいた対応 3. 定期的にDashboardを見て確認す

Slide 28

Slide 28 text

CloudNative環境におけトラブルへの対応

Slide 29

Slide 29 text

トラブルシューティングの流問題の検知問題の把握原因の特定暫定対応復旧確認問題を発生してか、なべく早く検知し、原因を特定して対応すことで、サービスへの影響を減すことができ。問題発生復旧

Slide 30

Slide 30 text

トラブルシューティング1: 問題を把握すまずは客観的な目線で、何が起きていかを把握すいつか、どこで、何が起きていか ● いつか発生したのか ● どこで ○ どのマイクロサービス ○ 外側か見ていったときに、どこか発生していのか ● どのうな問題が起きていのか ○ エラーが増えてい ○ レイテンシが上昇 ○ Unavailable Podが増えてい

Slide 31

Slide 31 text

トラブルシューティング1: 問題を把握す問題把握す際のポイントメトリクスを見て、実際に起きてい問題以外にも変化がないか確認す ● リクエストは増えていか ● オートスケールは発動していか正常な部分と異常な部分を切分け ● リクエストが届く経路や依存すコンポーネントは正常か確認す原因の断定を焦ない ● エラーが増えていとこは実は根本原因ではなく、他の箇所の問題の影響を受けた結果、ということはくあ

Slide 32

Slide 32 text

トラブルシューティング2: 問題の原因を調査すいいなアプローチで調査す ● 仮説を立て →裏付けデータがないか確認す　の繰返し ● マクロ（メトリクス）とミクロ（ログやトレース）を行き来す ○ メトリクスに変化が起きた時刻のログを見 ○ 気になログを見つけた、このエラーはいつか発生していたのか確認す ● 思いついたこと/気になったことは他の人にも共有す ○ xxで問題が起きてい可能性はないかな？ ○ このエラーログは関係あますか？

Slide 33

Slide 33 text

トラブルシューティング2: 問題の原因を調査すエラー増加の原因調査アプリケーションログをとにかく見て、気になエラーメッセージがないか調べ ● エラーメッセージで検索してみ（Google, Slack, GitHub） ● いつか発生していたか調べ ● エラーの発生場所やタイミングに偏はないか確認す Datadogでのpodごとのエラー数確認例

Slide 34

Slide 34 text

トラブルシューティング2: 問題の原因を調査すレイテンシ増加やタイムアウトエラー ● トレースを見て、時間がかかってい箇所が特定できないか調べ ● 同じ時間帯の各種メトリクスを確認す ○ CPU/Memory、DBレイテンシに問題はなかったか ● ネットワークの外側（クライアント側）か順に追っていく ○ アクセスログを見てどこまでリクエストが届いていたのか確認す ○ どこがタイムアウトエラーを返していのか ○ どこでエラーが何件観測さていのか

Slide 35

Slide 35 text

トラブルシューティング2: 問題の原因を調査す切口を変えて調査す ● 発生時刻近くにあった関連すイベントはないか調査す ○ リクエストの急増 ○ サービスのデプロイ ○ 定期バッチ処理の起動 ○ Kubernetes Eventのログ ● 問題に共通すことはないか ○ 周期性（実は前日も同じうな時間に起きていた） ○ 実は同じシステム依存を持つサービスで問題が起きてい ○ 同じversionのライブラリを使ってい

Slide 36

Slide 36 text

トラブルシューティング2: 問題の原因を調査す問題の切分けのために変化を加えてみ ● サービスの１つ前のversionをリリースしてみ ● ライブラリを最新版にして、リリースしてみ ● デバッグログを追加してデプロイしてみ ● KubernetesのPodやNodeを再起動してみ ● リソースの値を増やしてみ ○ CPU/Memoryを増やす ○ Pod数やDatabaseのNode数を増やす ● 裏で動いていバッチ処理を止めてみ変更してみて直ばいいし、直なくても原因の候補が１つ潰せ

Slide 37

Slide 37 text

トラブルシューティング2: 問題の原因を調査す原因調査の難しいポイント ● エラーログとして、直接の原因となエラーも、問題の影響を受けたことにエラーが多く出ため、本来知たいエラーが埋もてしまう ○ Request timeout error、Connection errorなど ● クラウド内部のことは分かないので、クラウドインフラで問題が発生したかどうか自分たちでは確認できない ○ サポートチケットを切ことで確認できこともあ

Slide 38

Slide 38 text

トラブルシューティング2:問題の原因を調査すクラウドへのサポートチケットの起票クラウドプロバイダーが提供すサービスに問題があと考えとき、サポートチケットを作調査を依頼すことができます。（契約次第）サポートチケットを作ときのポイント: 問題を具体的に記述す ● 発生していサービス（インスタンス名、リージョン、テーブル名など） ● いつか問題が始まったか、きっかけとなイベントはあか ○ 例: x月x日のxx:xx(JST)か。その前にxxをver x.xxにアップデートした ● どのうな問題が起きていか ○ 確認できログやメトリクスがあば添付す ● 深刻度、ビジネスへのインパクト ● 自分たちで調査した内容

Slide 39

Slide 39 text

トラブルシューティング3: 問題の修正案を考え問題の原因があ程度特定できた、修正対応 ● アプリケーションコードを修正してデプロイ ● 不足していリソースを追加して手動でスケールアウトす ● 問題が起きていコンポーネントの退避や再起動修正がすぐできない/どうしても負荷に耐えないと判断した場合の対応 ● Rate Limitなどを設定してリクエスト数を制限す ● メンテナンスモードに入てリクエストを止め → リクエスト再開時に、負荷をさばくための十分なリソースがあことを確認す

Slide 40

Slide 40 text

トラブルシューティング4: 問題の復旧を確認す暫定対応が終わった、復旧を確認す ● 影響を受けていたメトリクスがもとに戻ったこと ● 増えていたエラーが止まったこと ● サービスが想定通利用可能なこと再発可能性について確認・共有す ● 再起動して収まったが、根本的な原因が分かないので再発すかもしません、もし発生した再起動お願いします

Slide 41

Slide 41 text

事例紹介 ※ 紹介す事例は、自分が所属すメルペイ/メルコインだけでなく、副業で経験した話や他社のSREか　　聞いた話も含みます

Slide 42

Slide 42 text

発生したトラブル ● いくつかのマイクロサービスでエラーが増加 ● そぞのマイクロサービスには直接の依存関係はない調査 ● エラー率があがったPodを確認すと偏が見た（一部のPodのみにエラーが出てその他のPodは正常） ● Podが動いてい Nodeを確認すと、エラー率が上昇していた他のサービスのPodも存在していた復旧対応 ● Nodeを退避してPodを別のNodeへ移すことで問題は解消事例紹介1 Kubernetes Nodeの不調 Podごとのエラー数

Slide 43

Slide 43 text

発生したトラブルあイベントにって想定を超えリクエストが来た複数のマイクロサービスでエラーの増加などの問題が発生調査 Kubernetesリソースの状態やエラー内容を確認したとこ、 Pod数がオートスケールの上限に貼付いていサービス、 Database側のスケールが間に合ってないサービスなどがあった対応リソースが不足してい部分のオートスケールのMin/Max値を上げことでエラーが解消し、リクエストをさばけうになった事例紹介2 想定を超えリクエスト数の増加

Slide 44

Slide 44 text

発生したトラブル社内ツールが利用できなくなという問い合わせがあった。 Kubernetes deploymentのrollout restartすと解消したが、数日後に再発した調査 DBのsession poolを使い切っていてセッションが作成できないというエラーが出ていた。Podごとのセッション数を確認したとこ、一つのPodでセッションをmaxまで使い切っていた復旧対応セッションのリークの原因をすぐに特定すことができなかった。 DBへリクエストを投げ処理を定期実行して、失敗した livenessProbeがエラーとな対応を入て、自動的に再起動すうにした事例紹介3 Databaseセッションのリーク Podごとの使用DBセッション数

Slide 45

Slide 45 text

発生したトラブル多くのサービスにおいて、レイテンシの99パーセンタイルのレイテンシが継続的に悪化調査各サービスにおいてデータベースへの読み書きの99パーセンタイルレイテンシが増加していことが確認できた。その原因についてさに調査を行ったが原因がすぐに分かなかったので、サポートチケットを起票して調査を依頼復旧対応クラウド側の、マイクロサービスが動くシステムとデータベース間のネットワークで問題があ一時的にレイテンシへの影響が出ていたことが分かった。クラウドプロバイダ側の対応に解消した。事例紹介4 クラウドのインフラネットワークにおけ障害

Slide 46

Slide 46 text

次のトラブルを防ぐために

Slide 47

Slide 47 text

失敗か学んで、同じ失敗を繰返さないことが大事改善策として根本原因を修正すだけでなく、以下のうなポイントも検討できます 1. 原因となった箇所の修正 2. 原因の修正が難しい場合、影響を緩和す対応 3. 類似の問題が別の箇所で発生すことがないか確認 4. 問題に早く気づくための監視の改善 5. 同じ問題が発生した場合に、早く復旧すための改善次のトラブルを防ぐための改善

Slide 48

Slide 48 text

次のトラブルを防ぐポストモーテムの実施同じトラブルを繰返さないために、チームで振返を行い原因や対策を検討します ● インシデントの内容を確認 ○ タイムラインとサービスへの影響範囲 ● インシデントの原因と対策 ○ 原因 ○ 暫定対応 ○ 再発防止策重要: 人を避難せず建設的な議論を行う参考: メルペイにおけインシデントマネジメントとナレッジシェア https://engineering.mercari.com/blog/entry/20221220-5040a56d02/

Slide 49

Slide 49 text

次のトラブルを防ぐ Playbookの作成アラートが来たどのうな対応をすのか、ドキュメントで管理すことで次回以降の対応を早くす Title (アラート内容) ● アラートがな理由 ● 深刻度と影響範囲（サービスにどのうな影響が出か） ● コンタクト先 (SlackのMention先、PagerDutyのチーム等） ● 対応方法 ○ 調査方法 ○ 暫定対応 ○ 復旧確認方法参考: メルペイのシステム運用とPlaybookの共通管理への挑戦 https://engineering.mercari.com/blog/entry/merpay-operation-and-playbook-challenge/

Slide 50

Slide 50 text

トラブルシューティングの流（再掲）問題の検知問題の把握原因の特定暫定対応復旧確認問題を発生してか、なべく早く検知し、原因を特定して対応すことで、サービスへの影響を減すことができ

Slide 51

Slide 51 text

トラブルシューティングにおけ今後のチャレンジ課題: あ程度の経験があ人がい方が問題の解決が早い ● システムのアーキテクチャについての理解 ● 類似の問題を過去に経験していこと ● Observabilityツールの理解 AIアシスタントを活用してトラブルシューティングの知見を蓄積し、誰でもトラブルシューティングができ仕組みが、今後数年で登場すかも ● Amazon Qなどの製品に期待

Slide 52

Slide 52 text

まとめ CloudNativeな環境でシステムを構築すことで、あ程度運用を自動化すことが可能です。しかし、そでも必ずトラブルは発生します。適切な準備をして、トラブルを調査・切分け・修正できうにしましう。今日紹介した方法が、何か役に立てば幸いです。