Devops days 2018 Effective feedback from OPS case study in Rakuten email service
•
2 likes•869 views
私達楽天のEmailサービスチームは開発と運用を同じメンバーで行っています。 DevOpsにおいて開発からリリースまでのプロセスは開発者から高い関心が寄せられており知見も十分に集まっている印象です。 一方サービス運用に対して有効なプラクティスやツールの活用事例を耳にする機会はあまり多くなく私にとってはは試行錯誤が多い領域でした。 どのようにすれば、リリース後にサービスを安定稼働させ稼働実績から有益ななフィードバックを得ることができるでしょうか？ 本セッションでは私達のチームが過去〜現在において直面している課題とその解決へ向けた取り組みやプラクティスを紹介します。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Devops days 2018 Effective feedback from OPS case study in Rakuten email service
Similar to Devops days 2018 Effective feedback from OPS case study in Rakuten email service (20)
Recently uploaded
Recently uploaded (9)
Devops days 2018 Effective feedback from OPS case study in Rakuten email service
- 1. Effective feedback from OPS case study in Rakuten email service April.25.2018 Kenji Kitaura Communications group. Rakuten, Inc.
- 2. 2 Speaker profile 北浦 顕志 (@kkitauta) 所属：Communications group (Email delivery platform) 職種：Application engineer 役割：Product backlog management, Service operation, Software development 技術：Email(SMTP), Java, Kotlin, Ruby 趣味：Cycling, Swimming, Game
- 3. 3 Key messages 以下のことを楽天のメールサービスの取り組みを通してお伝えします。 § サービスの成⻑にはOPSからのフィードバックが⼤切 § SLOを元に監視、アラート、障害対応からフィードバックを得る取り組み Implement Monitor Backlog
- 8. 8 楽天のEmailサービス 主要なサービスは以下の４つです。 § 社内向け § Delivery : Email送信 § Marketing ：コンテンツ編集、宛先の抽出、パーソナライズ § Customer Insight ：実績確認、顧客⾏動分析 § お客様向け § Subscription ：メルマガ購読登録・解除
- 9. 9 楽天のEmailサービス 開発⾔語、Middleware § アプリケーション：Java(Spring Boot) § ツール, 管理画⾯：Ruby, PHP § Middleware： MySQL, Hadoop, Redis, Rabbitmq, fluentd, etc…
- 10. 10 楽天のEmailサービス 運⽤環境 § アプリケーションはDockerコンテナとしてビルドしKubernetesにデプロイ § MiddlewareはIaaS(プライベート)にデプロイ IaaS Kubernetes Middleware Containerized Application 他部署が運⽤ ⾃部署が運⽤ VM VM
- 12. 12 DEVOPSにおけるOPSの役割 ⼀般的にOPSの役割は「サービスを安定稼働さる」ことですが、DEVOPSにおい てはさらに以下の２つも重要だと考えます。 § サービスの信頼性の⽬標をコントロールする § ⽬標と実績のギャップをタイムリーにフィードバックする SLOを基礎として監視, アラート, 障害対応を洗練し、フィードバッ クの情報源として活⽤する⽅法を考えていきたいと思います。
- 14. 14 SLOとは § SLI : Service Level Indicator 指標 § 例：リクエストの成功率 § SLO : Service Level Objective ⽬標 § 例：⽉の全リクエストの成功率は 99.95%以上 § SLA : Service Level Agreement 合意 § 例: SLOが満たされなかった場合、利⽤料の 10%を返⾦します。ただし開⽰する SLOを内部のSLOよりも低くすることでSLAに安全マージンを持たせることが⼀般的 です。※1 ※1 : https://landing.google.com/sre/book/chapters/service-level-objectives.html
- 15. 15 SLOが無いことで⽣じる問題 § 利⽤側 § 機能性だけを評価してプロトタイプを重要なシステムに組み込んだ。 § 週に数件のエラーレスポンスが原因で品質が悪いと⾔われた。 § 提供側 § 「その状況がトラブルかどうか」で意⾒が⾷い違い対応が遅れた。 § 機能追加と品質向上のどちらを優先するかで意⾒が合わない。
- 16. 16 SLOを決める動機 § 信頼性に対する期待のコントロールができる § 過度に⾼い期待や利⽤者のサービスレベルと合わない使われ⽅ を避ける § エンジニアチームが⽬指すべき品質⽬標を明確にできる § 品質⽬標に適したアーキテクチャを選定できる
- 17. 17 SLOを決める動機 § 監視、アラート、障害対応の⽅針を決定できる § SLIを確認することで障害判定ができる § SLOに準じた値でアラートできる
- 18. 18 SLOドキュメントの⽬次 SLOの構成要素 項⽬ 説明 Service time サービスの提供時間 例：24時間 365⽇ Availability criteria Availabilityの計算⽅法 例外事項 Trouble escalation policy トラブルの定義 連絡⽅法 連絡までの⽬標時間 Maintenance announcement policy 予定・緊急メンテンスに対する告知期限と 告知⽅法 Support time 問い合わせ窓⼝とその稼働時間
- 19. 19 Availabilityの定義 問題のあるAvailabilityの計算⽅法の例： 成功レスポンス数 ÷ 総リクエスト数 • 計測期間はどのくらいか？ • レスポンス速度はどれくらいならOKか？ • 成功か失敗の判断基準は何か？
- 20. 20 Availabilityの定義 メール配信基盤の例 （HTTPで受理したリクエストをバックエンドの別サービスで順次処理します。） Google cloud storageの例: https://cloud.google.com/storage/sla Azure Cosmos DBの例: https://azure.microsoft.com/ja-jp/support/legal/sla/cosmos-db 99.95% availability over a month. Availability is calculated every 3 minutes period. - HTTP endpoint available criteria - 99.9 % success(HTTP status 200) for valid request . - 95% response return within xx msec. - Email delivery available criteria - No email delivery failure - Email delivery have to be finished with in xx minutes after request accepted.
- 22. 22 Monitoring
- 24. 24 Monitoring Targets 私達は監視対象の漏れを数多く経験してきました。 実際にあった問題 § APIやバッチの処理速度を監視していなかったので遅延に気が付かない § リクエストの量を確認していなかったので気がついたときには負荷試験の限界 値を超えるリクエストを処理していた。 § ログ転送プロセスがダウンしていて監視サーバーがログを拾えていなかった。
- 25. 25 Monitoring Targets 監視対象の例 § アプリケーション § リクエスト成功/失敗数 § 応答速度 § サーバー § CPU/メモリ/ディスク使⽤率 § 起動時間 § ミドルウェア(MySQLやRedisなど) § 応答速度 § レコード数
- 26. 26 Monitoring Method 症状と原因に分ける。 § 症状（ブラックボックス） ：外部から観測できる振る舞い § レスポンス速度 § エラーのレスポンス数 § ビジネスのKPI（メールの通数） § 原因（ホワイトボックス）：アプリケーション内部の情報 § データベースへの接続速度 § CPU,メモリ、ディスク使⽤率 § アプリケーションのエラーログ
- 27. 27 Monitoring Method ブラックボックスとホワイトボックスの特徴 § 症状（ブラックボックス） § SLIの監視に向いている § 実際にサービスで起こっている問題を指摘できる § 将来起こりそうな問題については指摘できない § 原因（ホワイトボックス） § 実際に起こっている問題の原因を特定できる § 将来起こりそうな問題を予測できる § 実際にサービスにどのような影響がでているかは指摘できない
- 28. 28 Monitoring Tools 監視に利⽤できるツール・サービスで私達が利⽤しているものをご紹介します。 種類 ツール ⽬的 ブラックボックス Splunk • エラー数/率 • レスポンス速度 • ビジネスメトリックス ホワイトボックス Splunk • エラーログ（アプリ/ミドルウェア） Datadog • サーバーリソースメトリックス • Docker コンテナのメトリックス Newrelic • JVM • APM
- 31. 31 Feedback from Monitoring § 週次のミーティングでメトリックスの確認 § 個⼈に依存せず継続して実施するためにチームのプラクティスとする § 重要な指標に異変があった場合は原因を調査して対策する
- 32. 32 Feedback from Monitoring 課題 § Middlewareの時系列監視⽅法が統⼀されていない § Prometheus + Grafana等で統⼀していきたい § ⼀つの不具合でアラートが複数届く § 例えばAPI性能劣化の事象を伝えるアラートとアプリのエラーログのアラー ト
- 33. 33 Alert
- 34. 34 Alert：実際にあった問題 当時の運⽤⽅法 • アラートは会社⽀給の携帯電話にメールで全員に着信 • アラートを処理する⼈は⽇替わりで変更 • 対応漏れ防⽌のためにプライマリとセカンダリを配置
- 35. 35 § 運⽤チームへの負担が⾼い § 緊急のアラートと翌⽇対応可能なアラートが混る § ⾒逃しプレッシャーから担当者にストレスがかかる § 担当でない⽇も担当の⽇と同じようにメールが来る § エスカレーションは⾃分で電話 § 当番割が⼿動 Alert：実際にあった問題
- 36. 36 § 対応漏れによるトラブル § 対応しなくても放置される § 対応済/未対応の区別ができない § どのように対応したのか確認できない Alert：実際にあった問題
- 37. 37 全てのアラートをPagerDutyからトリガーすることで改善に取り組みました。 Alert：改善への取り組み 問題 対策 運⽤チームへの負荷 が⾼い • プライマリにのみに電話で通知 • 応答しない場合は⾃動的に次の⼈に電話 • 全員にリアルタイムでSlackで共有 • 翌⽇対応でよいものはSlackのみ • 当番は⾃動割当 対応漏れ • 応答するまで何度もシステムが電話 • 応答しても放置していると再び電話 • 対応状況は「未、中、完」で可視化 • 対応状況と対応⽅法はSlackに反映
- 42. 42 Feedback from Alert 対応⽅法と対策の検討 初⾒のアラートがあった場合は週１回のMTGで暫定対応と恒久対策を検討 § 暫定対応 § 対応必要：対応マニュアル作成し、レビュー § 対応不要：ツールの無視リストにパターンを追加 § 恒久対応 § プログラム改修を含む根本的な対応チケットを作成
- 43. 43 Feedback from Alert § アラート数をKPIとして確認 § 特定のサービスのアラートが増加傾向にある場合はアラートを減らす対策を検討
- 44. 44 Trouble
- 45. 45 Trouble 実際にあった問題 § トラブル判定 § アラートが鳴っているけどトラブルかどうか分からない § 基準が明⽂化されていいないので都度マネージャー判断 § トラブル対応 § 障害の告知に含めるべき情報が分からないので告知が遅くなる § いつまでに誰が何をするのか分からない § 複数の⼈が同じ調査をしているかもしれない § 重要な役割が抜けているかもしれない
- 46. 46 Trouble 改善への取り組み 問題 対策 判定 トラブルの判定基準の明確化 § SLIを監視、可視化 § SLOにトラブルの判定基準を定義 対応 エスカレーションポリシーと対応フローの策定 § 迅速な報告のためのテンプレートを作成 § 報告先のメーリングリストを⾃動で⼊⼒ § 役割（管理・報告・調査・復旧）を定義 § 役割に必要な作業と⼿順を定義
- 47. 47 Trouble 役割と役割ごとのタスクを定義 • 管理（全体のまとめ） • 報告 • 調査 • 復旧 障害処理フローの⼀部抜粋
- 48. 48 Feedback from trouble(Postmortem) トラブルは将来のトラブルの発⽣を避けるための情報を得ることができる チャンスです。 § ⽬的 § トラブルの影響と根本原因を理解すること § 再発防⽌と予防施策が確実に実施されること § ルール § 関わった⼈を決して⾮難、糾弾しないこと
- 49. 49 Feedback from trouble(Postmortem) 問題のある振り返り § 関わった⼈が怒られる § 問題を正直にレポートすることが苦痛になる § 同僚が怒られる可能性がある場合ば事実を伝えにくい § 関わった⼈のやる気や能⼒に原因を求める § 責任感から⾃らの能⼒やマインドを⾮難してしまうことがある § バグを書いた⼈を⾮難するとリスクがある箇所を避けるようになる
- 50. 50 Feedback from trouble(Postmortem) 振り返りの質を⾼く維持するためには以下の項⽬について確認しています。 1. Trouble Summary 2. Service Impact 3. Time Line 4. Root Causes 5. Trigger 6. Resolution 7. Detection 8. Action item : Temporary, Permanent measurement 9. Lesson Learned : What went well, What went wrong, Where we got lucky
- 51. 51 Feedback from trouble(Postmortem) Lesson Learnedからアクションアイテムを⾒つける § What went well うまくいった対応が属⼈的なものかどうか確認します。他の⼈が対応 した場合でも同じようにうまくいくように施策をAction Itemに追加し ます。 § What went wrong うまくいかなかった原因を議論して再発防⽌策をAction Itemに追加し ます。 § What we got lucky 実際には表⾯化しなかった問題でも将来顕在化するかもしれません。 将来にわって防⽌する⽅法を議論して発⽣防⽌策をAction Itemに追加 します。
- 52. 52 Feedback from trouble(Postmortem) Lesson Learnedの例 § What went well § 影響範囲を正確にレポートできた。 § What went wrong § 監視が機能しておらずトラブルの報告（第⼀報）に時間がかかった。 § What we got lucky § リカバリツールの実⾏時に対象を間違いそうになったが直前で気がついた。
- 53. 53 付録：Feedback from daily operation 例 § SLIを測定するために指標を集計する機能を実装して欲しい § リリース後のエラー率を抑えるためにリリース時に段階的にユーザーのトラ フィックを増やして欲 § リクエスト数のピークが⾮機能要件の限界値に近づいている § 今週はエラー率が⾼い § ⼿動でのロールバックでは時間がかかりすぎる。⼀定のエラー率を超えた場合 は⾃動でロールバックする仕組みが必要 § 最近増加しているアラートが発⽣しないようにして欲しい § マニュアルでリカバリしなくて済むようにリトライ機能を実装してほしい
- 54. 54 まとめ
- 55. 55 まとめ § OPSからのフィードバックのサイクルを駆動させるためにはSLOに基づいた監 視、アラート、障害対応が重要です。 § 客観的事実や課題が集まれば⾏動可能なIssue（バックログ）として管理するこ とができます。 § 機能追加の開発を優先するか安定性の向上の開発を優先するかはSLOの達成度 を振り返ることで決断に⾃信を持つことができます。
- 56. 56 さいごに Technical Solutions Engineer https://talent.rakuten.careers/jobs/software-engineer-digital-marketing-messaging-platform-6542 https://talent.rakuten.careers/jobs/technical-solutions-engineer-digital-marketing-messaging-platform-6554 Software Engineer エンジニア募集