ココナラにおける SLO 設定の実践ガイド ~ ユーザー満足度の向上に向けた SRE のプラクティス適用

まずは監視基盤について、ご説明します。

Amazon EC2 上で構築している Grafana / Prometheus で SLO を測定しており、可視化やアラート発砲も実現しています。
おもに SRE チームが日々モニタリングしたりしており、毀損している部分を Amazon CloudWatch / Amazon Athena を用いた深堀りを行います。

それに加えて、SLO とパフォーマンス改善にコミットする委員会を立ち上げ、アプリケーション開発者と協業してユーザー体験を高めるためにはどうしていくべきか ? を議論しています。

また、アラートがオオカミ少年状態になりがちでしたので「ユーザーに影響がある、かつ、対応が必要なもの」に絞り込みの実施などの運用改善を行うことで、アラート対応の高速化・効率化を実現しようと試みています。

別の切り口として、SIEM on Amazon OpenSearch Service を用いたセキュリティログ分析をセキュリティエンジニア中心に実施しており、攻撃の予兆の検知と対応の高速化を実現しています。

詳細は冒頭でご紹介した記事に記載がありますので、ぜひそちらも合わせてご参照いただけますと幸いです。

先ほどの「ココナラで設定している SLO」に照らし合わせますと、以下のとおりの運用をしています。

• 「リクエストが単位時間あたりに 2xx 系で返却された割合が 99.96% を下回った場合」にアラートを通知するような仕組みを構築しています。
• パス単位に計測しており、サブドメイン単位に集約してモニタリングを行っています。

• 「直近の各デバイスのユーザー行動回数が、過去 1 年間の同曜日、同時間帯の回数に比べて統計的に明らかに少ない場合」にアラートを通知するような仕組みを構築しています。
• 時間帯は直近 30 分、直近 1 時間・2 時間・4 時間・8 時間、直近 1 日・7 日といった括りで比較を行っています。
  

後者を取り組んだきっかけですが、リクエスト成功率だけでは見えない問題を検知するために異常検知を導入することで、直近の数値との比較を行うようにしました。


 

前述の運用の中でアラート通知や委員会でのモニタリング・議論を行っていますが、それ以外の定点確認としてチームの朝会を活用しています。朝会の中でダッシュボードや Slack の通知を確認し、傾向分析 ~ 次のアクション創出までを行っています。

実際は SLO 以外のメトリクスもモニタリングしているので、モニタリング対象の 1 つという位置づけですが、アラートやモニタリングの仕組みで検知できないような変化を複視で見ることで、プロアクティブな改善に向けたアクションを創出しています。

現在のモニタリング手法では、深堀りするのに時間を要したり、エラーをピンポイントかつ一気通貫で見ることができない状況のため、AWS X-Ray を導入することで業務効率化と調査迅速化を実現しようと改善を進めています。

クラウドサービスを使う上で考えなくてはならないのが、

• 責任共有モデルを正しく理解したうえで、サービス運用を行う必要がある
• クラウドサービスといっても 100% の稼働率ではないので、「何かトラブルが起きる」という前提で、システムを構築する

という点です。

クラウドサービスの特性を理解し、うまく利活用することで、サービス側が対応すべきところの責務が明確化したうえで、より SLO 達成に向けた運用に注力できる状況を作れることが望ましいです。

注意点としては「何でもかんでも計測すれば良いわけではない」です。たとえば「ユーザー体験を損なう」というのはクリティカルユーザージャーニーで言うとどの部分にあたるか ? を明確化し、それらに対する SLO を設定します。

アラート疲れを起こさず、ユーザー体験を確実に改善するために選択と集中を行うことが大切です。