サービスティアを設定して、マイクロサービスの障害を防ぐ

サービスの重要度とその扱いについて解説した記事 “How Service Tiers Can Help to Avoid Microservices Disasters” の抄訳です。

多くの方は、このような管理を明示的にしていないとかもしれません。しかしおそらく、意識はされていることだろうと思います。もしかすると、サービスの重要度は、中長期的に変化していくかもしれません。

みなさんの事業では、どうでしょうか？

この記事は Lee Atchison が The New Stack に投稿した記事をアップデートしたものです。

アプリケーション全体をダウンさせるのは簡単です。たった一つのサービスに障害が発生するだけで、アプリケーションを構成するサービス全体がトランプタワーのように崩壊してしまいます。重要ではないサービスから些細なエラーが1件発生しただけで、アプリケーション全体に悲惨な結果をもたらすことがあります。

もちろん、依存するサービスの障害を防ぐ方法はたくさんあります。しかし、非クリティカルなサービスにさらなる回復力を備えようとすると、複雑さとコストが増し、「よく考えたら必要なかった」なんていうこともあります。

例として、下の図のようなサービスがあるとします。サービスAの実行にとってサービスDはそれほど重要ではないサービスだとしたら、どうするのが良いでしょうか？サービスDが障害を起こしたからといって、サービスAを停止させる理由はありません。重要度の高いサービスAがそれなしでも生き残れるのに、なぜサービスDは高い回復力を持たなければならないのでしょうか？

サービスの依存関係リンクが重要な場合とそうでない場合をどうやって見分けるのでしょうか？「サービスティア（Service Tier）」は、これを管理するための一つの方法です。

サービスティアとは？

サービス層とは、サービスに関連付けられたラベルのことで、サービスがビジネスの運営にとってどれだけ重要であるかを示すものです。サービスティアによって、ミッションクリティカルなサービスと、便利で役立つが本質的ではないサービスを区別することができます。

依存するサービスのサービスティアのレベルを比較することで、どのサービスの依存性が最も重要で、どれがそれほど重要でないかを判断することができます。

サービスにサービスティアを設定する

システム内のすべてのサービスには、規模の大小にかかわらず、サービスティアを割り当てる必要があります。以下のセクションでは、私が使用しているスケールの例を概説します。これをそのまま使用することも、特定のビジネスニーズに合わせて調整することもできます。

ティア1

ティア1のサービスは、システムの中で最も重要なサービスです。そのサービスに障害が発生した場合、顧客や会社の収益に重大な影響を与える場合、そのサービスはティア1とみなされます。

以下、ティア1サービスの一例をご紹介します。

• ログインサービス: ユーザーがシステムにログインできるようにするサービス
• クレジットカード処理: 顧客の支払いを処理するサービス
• 認可サービス: 特定のユーザーがアクセスできる機能を教えてくれるサービス
• 注文受付サービス: 顧客にウェブサイト上で製品を購入させるサービス

ティア1サービスの障害は、事業にとって深刻な懸念事項になります。

ティア2

ティア2のサービスはビジネスにとって重要なサービスですが、ティア1サービスよりも重要度が低くなります。ティア2サービスに障害が発生した場合、顕著かつ明確に顧客体験の低下を引き起こす可能性がありますが、顧客がシステムとの対話を完全に妨げてしまうわけではありません。

ティア2サービスは、バックエンドのビジネスプロセスに重要な影響を与えるサービスですが、顧客には直接気づかれないかもしれません。

以下に、ティア2サービスの例を示します。

• 検索サービス: ウェブサイト上で検索機能を提供するサービス
• 在庫割り当てサービス: 注文を受けて、倉庫にある在庫を顧客に出荷するためのサービス

ティア2サービスの障害は、顧客にマイナスの影響を与えますが、システムの完全な障害ではありません。

ティア3

ティア3サービスとは、顧客への影響が軽微で、気づかれない、または気づかれにくい、またはビジネスやシステムへの影響が限定的なものを指します。

以下に、ティア3サービスの例を示します。

• ユーザーアイコンサービス: ウェブサイトのページにユーザーのアイコンやアバターを表示するサービス
• おすすめサービス: 顧客が現在見ているものに基づいて、顧客が興味を持ちそうな関連商品を表示するサービス
• 今日のメッセージサービス: ウェブページのトップにお客様へのアラートやメッセージを表示するサービス。

利用者は、ティアサービスが障害を起こしていることに気づかない場合もあります。

ティア4

ティア4サービスとは、障害が発生しても顧客体験に大きな影響を与えず、顧客のビジネスや財務に大きな影響を与えないサービスです。

以下に、ティア4サービスの例を示します。

• 売上報告書作成サービス: 毎週の売上報告書を生成するサービスです。売上報告書は重要ですが、短期的な障害が発生しても大きな影響はありません。
• マーケティングメール送信サービス: 顧客に定期的に送られるメールを生成するサービスです。このサービスが一定期間ダウンした場合、メールの生成が遅れる可能性がありますが、多くの場合、それがあなたやあなたの顧客に大きな影響を与えることはありません。

サービスティアの扱い方

サービスティアは、2つの側面からインパクトを与えます。問題への応答性と、サービス間の依存性です。

応答性

サービスのティアレベルは、サービスの問題がどれくらいの速さで対処されるべきか、そうでないかを決定します。もちろん、障害の深刻度が高ければ高いほど、より速く対処する必要がありますが、一方で、一般的には、サービスティアの数字が低いほど重要度が高く、より迅速に対処する必要があります。低～中程度の深刻度のティア1の問題は、深刻度の高いティア4の問題よりも重要性が高く、影響力がある可能性が高くなります。

依存性

重要度の高い（サービスティアの数字が低い）サービスに与えられる応答性の違いを考えると、これはサービス間の依存関係マップと、サービスの依存関係についての仮定に影響します。

ティア4のサービスからティア1のサービスにリクエストしている場合、ティア4のサービスはティア1サービスが常に応答すると仮定してもおそらく安全です。もしも何らかの理由で応答しない場合には、ティア4のサービスを単純に失敗させても、一般的には許容できるでしょう。つまり、アプリケーションのティア1のサービスがダウンした場合、そのサービスの問題を解決するために直ちに多大な努力が行われます。一方で、ティア4サービスがダウンしていても、結果的には重要ではありません。ユーザーがログインできない（ティア1サービスの障害）ためにWebアプリケーションがダウンしているというケースを考えてみてください。その日のマーケティングメールが少し遅れるかもしれない（ティア4サービスの障害）と比較すると、どうでしょうか？

もちろん、逆もまた然りです。ティア1のサービスがティア4のサービスに依存している場合、そのティア1のサービスはティア4サービスがダウンする可能性がある場合に備えて、緊急事態対策やフェイルオーバーからのリカバリプランを策定しておく必要があります。つまり、優先順位の低いティア4のサービスが機能していないという理由だけで、ティア1のサービスが故障することは避けたいものです。例えば、すべてのページの隅に顧客のアバターを表示できないからといって、Web アプリケーション全体がダウンして障害が発生することは避けなければなりません。アバターを表示する部分以外は素早く回復して、正常に動作するようにしたいはずです。

例

下の図を見てください。この図では、各サービスにサービスティアを割り当てています。上記のルールを考えると、サービスAは優先度の高いサービス（ティア1）であり、サービスD（ティア3）は比較的優先度が低くなっています。サービスAとサービスDの間には、回復性（レジリエンス）が必要となることに注意しましょう。すなわち、サービスDの優先度が低いため、サービスAはサービスDの障害から自分自身を保護する必要があります。

次に、サービスBを見てみましょう。サービスBもサービスDに依存していますが、上記のルールによるとこの場合、サービスBにはサービスDとの間の特別な回復性は必要ありません。すなわち、サービスDが利用できない時間帯にサービスBが障害に見舞われたとしても、許容範囲されるということになります。サービスDの方が、この例では重要だということです。

このように、サービスを慎重に分析して適切なティア割り当てを行うことで、サービス間の依存性のために開発、テスト、および回復性強化のための労力をどこに集中させるか判断することができます。最も重要で最も壊れやすいインターフェイスに投資を優先し、重要度の低いインターフェイスに過剰な投資を避けましょう。

サービスティアにラベルを付けよう

サービスティアは、システム内の各サービスの重要性に関する情報を提供する「ラベル」を付けるだけです。このラベルを使用して、問題のエスカレーション・ポリシーや対応手順、優先順位を決定することができます。

しかも、このラベルを使用して、あるサービスが依存するサービスへの呼び出しに失敗した場合に、必要なバックオフとリカバリーの量と種類を決定することもできます。ティアが上位のサービスを呼び出すか、下位のサービスを呼び出すかによって、何をするか、どのように対応するが変わってくるのです。