モダナイゼーション10の罠｜10.運用保守性の罠

「運用保守性の罠」とは？

クラウドネイティブなシステムへのモダナイゼーションが完了し、無事に本番稼働を果たしたものの、システム状態が把握できない、障害時に原因究明に時間がかかる、問題解析・根本原因究明に必要な情報が得られない例が増えてきました。再発防止に向けた対策立案に必要な情報の迅速な入手が困難などの状態に陥ることを、「運用保守性の罠」と呼びます。

モダナイゼーションでは、移行前システムと同等、またはより効率化された本番運用保守作業が求められます。しかしながら、上記の罠に陥ってしまうと、元のシステムで求められていた水準のSLA（サービスのレベルに関する合意）の達成ができなくなる恐れが発生します。よって、モダナイゼーションを行うにあたり、この「運用保守性の罠」への対応策を立てておく必要があります。

実際に起こっている問題

クラウドネイティブなシステムは、マイクロサービスが疎結合された多数の小さなサービスで構成されます。一方、従来型のモノリシック・アーキテクチャーのアプローチは、密結合の大規模なアプリケーションを構成します。マイクロサービスに移行した結果、多くのサービスが独立してデプロイされることになります。しかしその結果、モニターや問題解決に使用されるロギング・データが膨大な量となり、サービス間での不整合が生じる可能性があります。この点が、原因調査を難しくさせる要因のひとつとして挙げられます。

また、クラウドネイティブなシステムでは、外部サービスも多く活用されますが、その結果、複数システムに跨るオブザーバビリティー（可観測性）やトレーサビリティー（追跡可能性）について、モノリシックなレガシー・システムのように確保することが難しいという点も挙げられます。例えば複数のサービスプロバイダーによるAPIを活用することにより、開発生産性の向上が見込める一方で、ひとつのサービスで何らかの障害が発生した場合、その影響がシステムの様々な箇所に及び、影響の特定や回復までの時間の長期化を及ぼすこととなります。

図１ 障害波及イメージ

さらに、サービスのSLAの違いにも注意する必要があります。例えばメインフレームであれば、稼働率は99.9999%と言われていますが、一般的な外部クラウドサービスのSLAは、おおむね99.9%から99.99%と定義されています。複数サービスを活用する場合、サービスごとにSLAが設定されているため、システム全体のSLAはさらに低くなるという点を認識しておく必要があります。

「運用保守性の罠」の乗り越え方

クラウドサービスで可用性を上げる手段として、例えばゾーン・リリースに対するマルチ・アベイラビリティー・ゾーン（マルチAZ）を活用する方法が考えられます。マルチAZは、２つ以上のAZを活用してシステムを構築します。マルチAZ構成は、複数のAZをまたいだシステムの冗長化を実現することができます。一方で、マルチAZはネットワーク構成が複雑となり、レイテンシー（通信遅延時間）が増えるという影響もあります。こうした可用性とパフォーマンスのトレードオフは考慮すべきです。

クラウドの特性を考慮すると、「システム障害は発生する」ということを前提に、モダナイゼーションを考える必要があります。障害発生の影響を最小限に食い止める方法として、サーキット・ブレイカーの設置が挙げられます。サーキット・ブレイカーとは、障害が発生しているサービスへの呼び出しを遮断させる仕組みです。サーキット・ブレイカーを設置することによって、１つのサービス障害が次々と他のサービスに連鎖することを避け、障害を局所化することができます。

図2 サーキット・ブレイカー

一方で、ネットワークの遅延などによって発生する一時的な障害に対しては、リトライを組み込むことによって、復旧を図ることが可能です。これによって、多くの一時的な障害から解放されますが、長期にわたる障害が発生している状況では何度リトライをしてもシステム負荷を増大させることになります。試行回数の上限を設定することで、リトライの回数を定めるとともに、サーキット・ブレイカーの発動条件とすることができます。

短期間でのリトライは、受け取る側のシステムに負荷が掛かります。これに対しては、エクスポネンシャル・バックオフという考え方を適用することで、回復と負荷のバランスを取ることが可能です。エクスポネンシャル・バックオフとは、x秒ごとにリトライというような固定間隔ではなく、１回目は１秒、２回目は２秒、３回目は4秒、というように、待ち時間を指数関数的に増やしながらリトライするアプローチです。これによって、一時的な障害から早く復旧するとともに、長時間のリトライ時にも負荷軽減を図ることができます。

また、上記のようなシステム的な予防策に加えて、早期に障害対策を行うためには、ハイブリッドクラウドやマルチクラウドにおけるそれぞれの役割分担や、マネージド・サービスにおいてもアプリケーションとインフラの役割分担など、システムの責任分担やSLAを明文化し、責任分担の「グレーゾーン」をあらかじめ潰しておくことも、運用としては欠かせません。

まとめ

クラウド・サービスを活用したシステムにおいては、「システム障害は発生する」ことを前提においた予防策を打つことが重要です。サーキット・ブレイカーやリトライを組み込むことで、障害の局所化や復旧の自動化が図れます。また、異なるサービスごとの責任分担を明確化しておく運用上の工夫も、障害からの早期復旧に役立ちます。

本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。当記事以外の解説もぜひご覧ください。