エムスリーエンジニアリンググループの関根(@sekikatsu36)です。 この記事はエムスリーSREがお届けするブログリレーの14日目です。
今回、私のチームが担当しているサービスのSLI/SLOを見直すこととなり、あらためて「マイクロサービスのSLI/SLOとは」を自分なりに考える機会ができたため、その話を紹介したいと思います。 まだ実行中で結論は出ておらず、内部でも議論の余地があるものですが、何かご参考になる点があれば幸いです。
エムスリーでは数百のマイクロサービスを開発・運用していますが、今回は私の所属チームで担当している「医療ニュースの管理サービス」を取り上げます。 このサービスは、ニュース記事を表示するWebページ、ニュース記事を登録・取得するAPI、リコメンドやメルマガのための記事情報を分析・格納するバッチ、などから成り立っています。
私はこのチームのチームSREを担当しています。 チームSRE/コアSREについては、リレー初日の記事をご覧ください。
事の発端
昨年、社内の複数のサービスで障害が立て続けに発生する事態が起こりました。 それぞれの障害は独立したものだったのですが、ユーザ影響やビジネス的な損失など、そこそこ大きな影響が出てしまったため、各サービスの信頼性を高めようという動きがチーム内で発生しました。
信頼性といえばSREの出番です。 各サービスにはSLI *1 とSLO *2 が設定されていました。 しかし、信頼性の議論を始める前に、まずはこの見直しを行うことにしました。
というのも、設定されていたSLI/SLOは、HealthCheckで算出した稼働率やレイテンシなど、エンジニア目線で定義されたものだったためです。 このような指標では、SLIがSLOを下回ったとしても、優先度や費用対効果を判断できません。 例えば応答速度の99%ile値を3秒に設定していたとして、それを超えてしまってもユーザに影響が一切出ないのであれば、最優先で対応する必要はありません。 あるいは稼働率が99.8%に下がってしまったとして、その経済的影響が100万/月なのであれば、稼働率を0.1%向上させるために100万円/月以上を投入したら赤字です。
このように、現在のSLI/SLOでは、その変動とユーザ体験やビジネスへの影響が、直接関連していない状態でした。 SLI/SLOをビジネス視点で再検討することで、作業の優先順位決めやトレードオフの判断などを効果的・効率的に実施できることを狙いました。
ビジネスサイドとの対話
エンジニアだけでは、サービスの稼働状況とビジネスインパクトを判断できません。 そのため、ビジネスサイドのメンバーと会話する機会を複数回設け、ビジネスインパクトの大きいサービス要件や障害事例について、ヒアリングや議論を行いました。
「ピーク時にユーザがログイン失敗するケースがあった」 「記事のリコメンドに失敗するとCTRが落ちるので困る」 「スマホアプリでパフォーマンス問題が起きて離脱率が増えた」
ふむふむ。なるほど。
当たり前のことなのですが、議論が始まってすぐに、問題が出てきます。
私がフォーカスしていたのは単一のマイクロサービスですが、ユーザに提供される「サービス」は、それらマイクロサービスの集合体です。 ユーザへの価値も、ビジネスインパクトも、すべてその単位で語られます。 結果、それらへの担当マイクロサービスの影響が分からない、という状態になりました。
例えばリコメンドであれば、以下のいずれかでエラーが失敗したら、最終的にリコメンドには失敗してしまいます。
- 事前の記事登録(管理画面)
- 記事の分析・分類(バッチ)
- ユーザの嗜好分析と記事のマッチング(バッチ)
- リコメンド対象の記事取得(API)
APIやバッチは、仮に担当マイクロサービスが正常に結果を返していても、実は呼び出し側や後続処理でタイムアウトが起きていた可能性はあります。 逆にエラーを返していたとしても、呼び出し側でFail Safe設計がされていたら、影響はほとんどないかもしれません。
疎結合はマイクロサービスのメリットですが、それゆえマイクロサービス間でどう関連しあっているのか、全体像を把握するのは難しいです。 特に、関係する各サービスの担当が別だったりします。上記の例では、認証もリコメンドもスマホアプリも、全て別のチームの管轄です。
さて、どうしよう。
方針転換
結論として、ビジネスサイドとの対話を通して、マイクロサービス単位でSLI/SLOを考えることは一旦止めました。
ユーザやビジネスから見た「サービス」とは、マイクロサービスのことではなく、ユーザ体験や経済価値を生み出す一連のサービスです。 なので次は、この「一連のサービス」に対するSLI/SLOを考えることにしました。 そうすれば、
- ログインエラー率
- リコメンドの失敗回数
- アプリの表示速度
のような、SLIを定義できます。
しかし一方で、当然、このSLIには複数のチームがまたがって影響し合うことになります。 このように、サービスのSLI/SLOは、マイクロサービスやチームを横断して計測・可視化すべきであると考えるに至りました。
現状、具体的には、SLIに影響を与える指標(サブSLI)をマイクロサービス単位で設定し、SLI/SLOおよびサブSLIを可視化するダッシュボードをチーム間で共有するのが良いかなと思っています。 サブSLIに対応するサブSLOは設定せず、SLIがSLOを下回った際には、チームが各値を確認しあい、相互に連携しながら解決案を探っていくようなイメージです。 上記のリコメンドの例であれば、各バッチやAPIのエラー状況や実行時間をサブSLIとし、ダッシュボード化できるかどうか、検討しています。 単純なAPI呼び出しのチェインであれば、分散トレーシングなどの技術で横断的に可視化・計測できそうです。
この企画はまだ実行中で、方向性が正しいのか、今時点で私が確信を持っている訳ではありません。 マイクロサービスのメリットを活かしつつ、全体を俯瞰して見られるようにするのは難しそうですが、まずはトライしてみたいと思っています。
終わりに
マイクロサービスだと、疎結合というメリットもあり、良くも悪くも周辺サービスとの関係をあまり意識しなくなりがちかと思います(誰がそのサービスを使っているか把握しづらい)。 また、エンジニアはどうしても目の前のシステムを中心に考えてしまいます。
しかしどれだけ細かく分割したところで、最終的な目的はユーザへの価値提供です。 自分の担当サービスがそこにどう影響していて、どうあるべきなのか。マイクロサービスであっても全体像を意識するのは重要だと感じました。 無意識的に、チームや担当で境界を切ってしまっていた自分に気がつけたのも、良い収穫かなと思います。
サービスの価値とは、自分の価値とは。SREとして、今後も向き合っていきたいと考えています!
We are Hiring!
エムスリーでは、コアSRE/チームSREを広く募集中です!
サービスを新しく立ち上げたり、価値や信頼性を高めていくなど、活躍の場は無限大です! よろしければぜひ以下のリンクから応募してみて下さい!