S
Smarter Business

モダナイゼーション10の罠|6.可用性・信頼性の罠

post_thumb

濱口 悟

濱口 悟
日本アイ・ビー・エム株式会社
IBMコンサルティング事業本部
Application Engineering Services
 

「可用性・信頼性の罠」とは?

基幹システムでは「3つの安」の観点で既存システムの可用性や信頼性の実現が求められます。既存システムをオンプレミス環境からクラウド環境へモダナイゼーションする際には、稼働環境のサービス品質保証(Service Level Agreement:以下、SLA)の考慮が重要となります。

オンプレミス環境では、信頼性を向上させるために「故障率が低い部品を使う」ことが可能でしたが、クラウド環境では、ユーザは「故障率の大小」という観点で部品を選択することができません。これでは「故障率が低いこと」を前提にできたオンプレミス環境の既存基幹システムと同等の高可用性を実現することは困難です。

これを「可用性・信頼性の罠」と呼び、可用性・信頼性が担保できない設計はモダナイゼーションの足枷となります。
そのため、部品が停止したり、誤操作・誤動作による障害が発生したりすることを前提としたフェイルセーフの設計思想に重点をおき、冗長化などの方策により、障害発生後にいち早く復旧することを目指す必要があります。

フェイルセーフの設計思想イメージ図

実際に起こっている問題

ここでは「クラウド・サービスのとあるコンポーネントがダウンして、正常系に引き継がれる間5分停止した。」というケースで考えてみます。

オンプレミスのシステムの場合、5分間の停止は異常事態であり、あまり発生しない事象であると言えるかもしれません。しかしクラウド・サービスでは、この程度の停止は発生確率が比較的高いものと考えておくべきです。

停止する理由は局所的なシステム障害だけではなく、突発的なメンテナンスや、構成変更の人為的ミスなどさまざまです。一度構築したらめったに構成変更しないオンプレミスのシステムと異なり、クラウド・システムは必要に応じて随時構成を変えられることが長所ですが、同時に構成変更にともなうミスも発生しやすくなります。

また、クラウド・ベンダー側でも、SLAの免責事項として、数分程度の停止や、OSの再ロード時間などの復旧に必要な時間を稼働時間の計算から除外しているケースもあります。

「可用性・信頼性の罠」の乗り越え方

故障・停止しやすいクラウド・システムを用いてどのように「可用性・信頼性の罠」を乗り越えればよいのでしょうか。そのためには「コンポーネントは停止するもの」という前提に立ち、それぞれが停止しても、サービスには影響が出ないフェイルセーフ設計を全体に適用する必要があります。

具体的には「冗長化」と「信頼性向上」を図ることになります。

「冗長化」を実現するための方策は下記となります。

  • クラウド・サービスが提供している冗長化方策を適用する

    ストレージやデータベース、ネットワーク経路の多重化など、多くのクラウド・サービスでは標準的に提供しているものを使う方法です。ただ、構成方法によってはサポートされない構成も取れてしまうので、正しく構成できているか確認が必要です。

  • 単一障害点を減らす

    例えばアプリケーション・サーバをマルチ・インスタンス構成にすることにより、単一インスタンス障害時にも、正常なインスタンスでサービスをそのまま継続することが可能です。これにより、システム全体のサービスレベルが、クラウド・サービスのSLAを超える設計にすることも可能になります。

「信頼性向上」についても、いくつか方策があります。

  • 障害からの自動復旧を行うためのプロセスを用意し、稼働テストを行う

    オンプレミスのシステムでは、システム障害はめったに発生しないイベントなので、復旧手順については手動対応とする場合もありました。しかしクラウド・システムでは、システム障害は頻繁に発生するため、対応する復旧を自動化させることが有用です。

  • システムをなるべく多くのインスタンスに分散する

    インスタンスが多くなると、相対的に障害の影響を受けるトランザクションが少なくなり、システム障害の影響を軽減できます。

  • ワークロード使用率をモニタリングし、需要の変動にともなうリソースの追加と削除を自動化する

    システム停止の要因の1つである「リソースひっ迫」をこれにより回避することができます。また、必要がなくなった時に自動削除することでコスト最適化を図ることができます。

  • インフラの変更作業を自動化する(IaC:Infrastructure as Code)

    インフラの変更作業を事前にスクリプト化して実行するだけにしたり、クラウド・ベンダーから提供されているテンプレートを活用して変更作業のコードを作成したりすることで、人為的なミスによるシステム障害を減らすことができ、結果的に信頼性向上につながります。また、インフラ環境がコード化されることにより、コード自体への自動テストやレビューが可能になり、変更作業の成功確率、ひいてはシステムの信頼性が向上します。

まとめ

IBMでは、マイグレーションの豊富な経験を保有していますので、今回ご紹介した問題以外にも注意すべきポイントをおさえてプロジェクトを推進することが可能です。ぜひご相談いただければと思います。

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