システム改善・育成のための障害対応訓練

Transcript

1. システム改善・育成のための障害対応訓練 September 22, 2023 Matsumoto Hiroki Marketing Cloud Platform Department Rakuten Group, Inc.
2. 2 Profile 松本宏紀 ( Matsumoto Hiroki ) • Reliability Engineering Team • Software Engineer • Joined Rakuten in 2020 • Published • OSS: Passenger Go Exporter • Presentation: デプロイメント⼿法を選択する ~ Flagger/Argo Rollouts ~ • GKE + Java + Cassandra → Ruby + Go + Kubernetes ( Private Cloud / AKS ) • Twitter : @hirokimatsumo13
3. 3 経験値を引き継ぐ
4. 4 Table of Contents 1. Assets 2. Training 3. Examples
5. 5 Assets RunBook 障害発⽣時の取り扱い説明書。リカバリ⼿順などをアラートに対してリンク、またはアラート⾃体に埋め込 まれる。 Incident Report Template 障害発⽣時の報告⽤テンプレート。ユーザー視点で、どこにどのような影響が発⽣したのかを展開するため の形式。 Training 過去の障害発⽣や、システムの構成要素から障害を実際に発⽣させ、リカバリーまでを実際に経験し、シス テム上の問題や⼈の成⻑ポイントを確認する。
6. 6 Training Trainee ☑ 基本的な事は⾃⼰学習で⾜りる ☑ 新卒1-3年⽬ ☑ 役割: Developer + Operator Trainer ☑ 運⽤経験3年以上 ☑ 対象プロダクト有識者 Manager ☑ レポート先 Training Environment ☑ トレーニング専⽤環境 Conductor ☑ 運⽤経験3年以上 ☑ 対象プロダクト有識者 擬似障害発⽣ 検知・影響範囲確認・原因特定・復旧 協⼒ 報告
7. 7 Example 1: 応答遅延 Load Balancer Istio App Nginx Proxy Pattern A Nginx request_time : 10 upstream_response_time : 10 App elpased_time : 10 Pattern B Nginx request_time : 10 upstream_response_time : 10 App elpased_time : 0.1 Pattern C Nginx request_time : 10 upstream_response_time : 0.1 App elpased_time : 0.1 https://nginx.org/en/docs/http/ngx_http_log_module.html https://nginx.org/en/docs/http/ngx_http_upstream_module.html Pattern A~Cはそれぞれどこで問題が発⽣してる︖
8. 8 Example 1: 応答遅延 Nginx: request_time request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client. 引⽤元︓https://nginx.org/en/docs/http/ngx_http_log_module.html
9. 9 Example 1: 応答遅延 Load Balancer Istio App Nginx Proxy 障害発⽣⽅法 専⽤PGにてクライアントからパケ ット送信箇所に遅延を⼊れて再現 単純に⾼負荷にする ( CPU/Packet送受信 ) Istio fault-injectionの利⽤ 単純に⾼負荷にする ( CPU/Packet送受信 )
10. 10 Example 1: 応答遅延 それぞれ計測される時間がどこからどこまでかを正確に把握する これを理解していないと、システムの問題であるかどうかも正確に把握できない状況に陥る可能性がある。 SLI (Service Level Indicator)として、どの部分がより適切であるかを理解する APMなどでアプリケーション側だけの応答速度を計測するだけでは不⼗分である事を理解する。
11. 11 Example 2: PromQLの正確性 sum(rate(istio_requests_total{reporter="destination", response_code=~"5.*"}[5m])) / sum(rate(istio_requests_total{reporter="destination"}[5m])) * 100 > 5 実際のシステムに反映する場合、どのような点に考慮すべきか︖
12. 12 Example 2: PromQLの正確性 rate/irateの違い Range全体 / 最後2点での計算の差異。 https://prometheus.io/docs/prometheus/latest/querying/functions/ counter resetへの考慮 https://github.com/prometheus/prometheus/issues/1673 そもそもcounterは0から始まるとは限らない。 定期的にリセットされる。 ※バージョンによって期間、動きの差異有り
13. 13 Example 2: PromQLの正確性 reporter=destination or source destination側はretry分も含まれてしまう場合がある。また逆にmetricsが取れていない場合もある のでsource側での計測結果を主に利⽤している。 https://istio.io/latest/docs/reference/config/metrics/ response_flag response_flagを⾒て、istio側でどのような問題が発⽣してそのエラーを返したのか確認。 https://istio.io/latest/docs/reference/config/metrics/ https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#config-access- log-format-response-flags Istio App Nginx Proxy destination source
14. 14 理論と実践 ⾒て学び、経験を得て⾃分のものにしていく。 「わからないけど、そうなってる」ではなく、なぜそうなってるかを理解していく。 ただ基本的にはそういった要素がなくなるように、システムを改善できると良い。