さらに今日のクラウドサービスの大半はインターネット経由でアクセスするが、インターネットはベストエフォート型のサービスであり、保証は何ら提供できない。ネットワーク接続の品質を保証できない状況でクラウドSLAの交渉を正当化するのは難しい。また自社におけるQoE測定ポイントとクラウドの間にネットワークというサービスコンポーネントが存在しているとなると、クラウドサービスプロバイダーがSLAを順守できなかったことを証明するのも難しい。さらにこの問題はクラウドへの管理接続の他、管理レベルのQoEに関するSLAの策定にも影響を及ぼす。

　これまでにSLAを作成したり監視したりした経験のある人であれば、2番目に多く報告されている問題については詳しいだろう。その問題とは、「クラウドSLAには順守状況を評価するために必要となるQoEの妥当な測定方法が明記されておらず、また明記することもできない」というものだ。この問題は、「クラウドオペレータは具体的にどのような基準で何を保証するのか？」という一見シンプルな疑問からスタートする。例えば、レスポンスタイム1つを取っても、企業がどのような方法を用いて、どこで測定するかは実に多様だ。測定方法と測定ポイントの両方について双方の合意が成立しない限り、現実的なSLAの施行は不可能だ。

　クラウドSLAの3つ目の問題は、「ユーザーが供給するソフトウェアコンポーネントやユーザーが作成するアプリケーション接続がアプリケーションのQoEに影響を及ぼす可能性がある」というものだ。SaaS（Software as a Service）を「最も高いレイヤー」のクラウドサービスと捉え、IaaS（Infrastructure as a Service）を「最も低いレイヤー」のクラウドサービスと捉えるのなら、低いレイヤーのサービスにはユーザーが登録するコンポーネントがより多く含まれ、ユーザーが登録したコンポーネントが外部接続を発生させてパフォーマンスに予期せぬ影響を及ぼすリスクも高まることになる。クラウドサービスプロバイダーはそうしたことがアプリケーションの全体的なQoEにどのような影響をもたらすかまでは保証できないし、予測もできない。

　4つ目によく報告されているSLAの問題は、「クラウドパラメータの設定がアプリケーションQoEに大きな影響を及ぼし得る」というものだ。つまり、SLAは明確なパラメータ設定を想定した上で策定しなければならないということだ。基準から大きく外れているわけではなくても、何か普通とは違う状況が起きれば、QoEやSLAの問題につながらないとも限らないからだ。

妥協点を見つける

　ここで本当に問題なのは、有用なSLAの策定を難しくさせる要因は多数あるが、だからといってSLAの必要性が軽減されるわけではないという点だ。では、可能な範囲で最善なSLAを締結するためにはどうすべきなのだろう？

　簡単に言えば、その答えは上記の問題を回避することだ。基本は「クラウドサービスプロバイダーが実際に保証できること」を理解することだ。クラウドは仮想リソースを実際のアプリケーションに割り当てることで機能する。割り当てが予想した通りにいけば、リソースも予想通りのパフォーマンスを発揮する。であれば、リソースに対するパラメータや、ネットワークを経由したリソースへのアクセスに対するパラメータの設定で変数を抑える必要があるだろう。

　最も包括的なSLAを実現できるのは、ネットワークプロバイダーを兼ねるクラウドサービスプロバイダーとの間で交わすSLAだろう（関連記事：BizCITY、回線の品質とグローバル対応で信頼のプライベートクラウドを実現）。SLAの点からすると、最も好ましい関係を結べる相手はネットワーク事業者のクラウド部門ということになる。

　2番目に良い選択肢は、クラウドサービスプロバイダーの側で保証準備が整っているネットワーク事業者からクラウド接続を入手することだ。いずれにせよ、通信保証を明確にするためにはインターネットやインターネットVPNではなく、プロビジョニングされたVPNを使用する必要があるだろう。

　リソースの割り当てに関しては、「何が仮想リソースなのか」を明確にすることがまず肝要だ。

　SaaSの場合、ユーザーはコンポーネントを一切供給しないため、全ての要素が仮想リソースとなる。従って、クラウドサービスプロバイダーが完全に取り仕切り、ネットワーク以外の全てのアプリケーションコンポーネントに対するSLAを書くことが期待される。

　PaaS（Platform as a Service）やIaaSなど、低いレイヤーのサービスでは、プロバイダーは自分たちが何を提供するかを保証できる。ユーザー側に求められるのはベンダーパフォーマンスの測定方法の決定だ。IaaSの場合、アプリケーションがサーバに割り当てられる速度は最も変わりやすい要素となり、エラー発生時に新規サーバに取り換えられる速度が可用性を決定することになる。

　SLAに関しては、PaaSが最も厄介だ。PaaSの場合、具体的なハードウェア構成が約束されるわけではなく、幾つかの物理ホストとソフトウェアで構成されるプラットフォームの提供が約束されるだけだからだ。レスポンスタイムの変化にどの程度の幅があるかを把握するためには、クラウド内にpingポイントを設けてネットワーク遅延を測定し、エンド・ツー・エンドのアプリケーション遅延からその分を差し引いて、クラウドアプリケーション処理のパフォーマンスを判断できるようにする必要がある。そして、何を決めるにせよ、プロバイダーが条件に同意し、契約にそれを明記しておくことが必須となる。

　クラウドSLAは恐らく買い手を満足させるものにはならないだろう。だがそれは現代の多くのSLAにあてはまることだ。慎重に取り組めば、少なくともリスクレベルを制御できるクラウドSLAを策定し、会社の目標達成につながるクラウドサービスを提供してもらうことは可能なはずだ。