こんにちは。エンジニアの濱田（ @hamakou108 ）です。
今回は弊社サービスの可用性を担保するために開発チームで取り組んでいることについて紹介したいと思います。
はじめに
新型コロナウイルスの脅威が世界的に拡大していく中、経済への打撃は日に日に深刻さを増しています。 私達M&Aクラウドではこういった状況下でも積極的に買収・出資を検討している企業様を見える化する施策を行っています。
この施策はプロジェクト立ち上げから1週間程度というスピードでリリースすることができましたが、その裏にはサービスの信頼性や可用性を担保するための平常的な取り組みの存在があります。 機能が何らかのエラーで利用できない、サービスが重くて使えないといった問題が多発していれば、保守運用に掛かりっきりで新規開発どころではありませんよね。 M&Aクラウドの開発チームで可用性を担保するために取り組んでいることの1つが SLO の設定とその評価の自動化です。
SLO/SLI/SLA
一概にサービスの可用性とは言うものの、どのようにして可用性を評価すればよいでしょうか？ ここで役立つのが SRE (Site Reliability Engineering) の文脈で用いられる SLO 、 SLI 、 SLA という概念です。 Google Cloud の CRE チームのブログ記事によると以下のように表現できそうです。
- SLO (Service-Level Objective): システムの可用性を担保するにあたってターゲットとする目標、数値。
- SLI (Service-Level Indicator): SLO が満たされているか評価する際に用いる指標。エラー率やスループットなど。
- SLA (Service-Level Agreement): サービスの利用者に対して約束する可用性のレベル。
一般的には SLO と SLI を設定して一定期間ごとに評価することで可用性が担保されているか判定します。 サブスクリプションとして利用者にサービス提供している場合などは SLA を設定し、満たせなかった場合に罰則が発生するような契約を結ぶケースもあります。
ここで SLO は高ければ高いほど良いというわけではなく、事業目標を達成する上で理にかなっているかという点が重要となります。 サービス品質向上のためにリソースを割けば、その分だけ機能開発に費やすためのリソースを失うことになります。 機能開発と品質向上をうまくバランスさせて、事業目標を達成できるような SLO を設定することが1つの肝です。
チームにおける SLO/SLI と評価のための仕組み
M&Aクラウドの開発チームでは SLO として可用性 99.95 % を掲げており、 SLI については Web サービスという性質から HTTP レスポンスステータスを採用しています。 すなわち Server Error 5xx ステータスを返す割合が 0.05 % 未満であれば SLO が満たされていると評価するような形です。
私達はアクセスログをカスタムしたデータを ElasticSearch に格納しており、 Kibana でステータスコードごとにグルーピングしたグラフで可視化していつでも確認できるような仕組みを作成しています。
また可用性を継続的に評価するため、 Kibana のアラート機能を使って週に1度可用性を計測し、 SLO を下回っている場合は Slack 通知する仕組みも作成しています。 こちらに関しては具体的な設定方法を Qiita で公開しています。
Slack 通知の仕組みを作成して2ヶ月程ですが、今のところ SLO を下回った週はありません。 通知が来ない間は可用性について特に心配する必要はないので、他の開発に集中することができています。
終わりに
最後に内容をまとめます。
