クラウド上にのせるアプリケーションの品質

これは2012年秋にCIOマガジンに「ビジネス成長にIT革新を生かす　【第6回】クラウド上にのせるアプリケーションの品質」というコラムで掲載した内容の転載です。

ーーーーー

クラウドでアプリケーションは何が変わるのか

クラウドの活用は、大きく2つの点でビジネスに貢献しうるとされています。1つは、基盤を自在に伸縮させてITサービスに対する過剰投資を防ぐことです。またもう1つは、ビジネス・アイデアからアプリケーションを開発し、サービスとして提供するまでのサイクルを短くすることです。

では、クラウド上に載せるアプリケーションは、これまでのアプリケーションと何がどう変わるのでしょうか。

まず、ITシステムが提供する基本的な価値（例えば、営業支援システムであれば、案件状況の可視化や可視化のための労力の削減といった価値）については、アプリケーションがどんな場所で動作しようと変わらないはずです。ただし、アプリケーションの設計によっては、クラウド活用の効果が最大限に得られない場合があります。

例えば、オンプレミスのシステム上で動作させていた既存のアプリケーションを、その設計を変えずにクラウド上に移行させるとしましょう。この場合、アプリケーションのハードウェア呼び出しやネットワーク・インフラなどが「個別に最適化された環境」での利用を想定して設計されている可能性があります。仮に、そのようなアプリケーションに対して、パブリックとプライベートの両クラウド間を自在に横断できるアーキテクチャを適合させようとすると、かえって複雑な設計になってしまい、開発の期間が従来よりも長くなってしまうおそれが強まります。そうなれば、「サービス提供サイクルを短縮化」というクラウド活用の効果がすべて帳消しになってしまうのです。

「クラウド･レディ」なアプリケーションであるための4つのポイント

上記のような問題を避けるには、クラウド上での動作を前提に開発された「クラウド･レディなアプリケーション」を開発する必要があります。

アプリケーションが「クラウド･レディ」であるためのポイントは、「パフォーマンス」「柔軟性」、「回復力」、そして「セキュリティ」の4つだといわれています。以下、これら4つのポイントについてもう少し詳しく見ていくことにしましょう。

●パフォーマンス：まず1点目の「パフォーマンス」についてですが、パフォーマンスの低いアプリケーションは、クラウド活用の効果に負の影響を及ぼすとされています。

本連載では前回、ハイブリッド・クラウドの課題について次のように言及しました。

――「ハイブリッド・クラウド構築時の大きな問題となるのが、データセンター間の距離です。オンプレミスのシステムと外部サービスのデータセンター間、または、各クラウド事業者（のデータセンター）間の距離が常に近いとは限りません。むしろ、災害対策を考慮に入れた場合、それぞれのデータセンターは離れた場所にあるほうが望ましいという考えにも至るはずです」

このような状況下で、アプリケーション（サービス）のパフォーマンスをどう確保するかは、クラウドのプラットフォームだけの問題ではありません。アプリケーションにも大量データのやり取りを考慮した設計がなされていなければならないのです。

●柔軟性：ここで言う「柔軟性」とは、すなわち、「ビジネス要求をどれだけスピーディにアプリケーションに実装し、サービスとして提供できるか」ということを意味します。そのスピードを獲得するうえでは、外部サービスの活用／連結によってビジネス要求を満たしていけるような柔軟性をアプリケーションに持たせなければなりません。そのためにも、前回の連載でも言及されていたとおり、APIやデータ形式の互換性を確保したアプリケーションを設計／開発することが重要となるわけです。また同様に、構成管理／トレーサビリティ管理といったアプリケーションの状況を可視化するマネジメントも重要な役割を担います。

●回復力：これは例えば、クラウド事業者のサービス継続が困難になるといった不足の事態が発生した場合でも、アプリケーションがプロアクティブに対処できるような特性を指します。前回の連載では、この点について次のように言及しました。

――「有事の際の復旧にかかる時間を可能な限り短くしたいのであれば、特定のクラウド基盤からデータを引き出すというアプローチではなく、常に同じデータを複数のクラウド（あるいは、データセンター）に書き込んでおくという施策が必要とされるはずなのです」　

つまり、クラウド向けにアプリケーションを開発する際には、それが上記のような基盤の上で動くものであることを念頭に置いておく必要があるということです。

●セキュリティ：クラウドの基盤は共用の環境であり、そのことはアプリケーションに新しいリスクをもたらします。例えば、セキュリティ攻撃をしかけてくるハッカーらは、クラウド上の別サービスを経由して、読者が利用する環境へのアクセスを試みるかもしれませんし、サービス間でやり取りされるデータを狙いにくるかもしれません。また、クラウド基盤そのものの脆弱性のためにセキュリティ上の問題が起きる可能性もあります。したがって、前出した「回復力」を高めるために複数のクラウドにデータを書き込むのであれば、これまでとは違ったセキュリティ・リスクを考慮に入れないと、その安全性を担保することはできないのです。

「クラウド･レディ」かどうかをテストする

クラウド向けのアプリケーションの品質を高く保つには、それが「クラウド･レディ」なアプリケーションであるかどうか――すなわち、上述した4つのポイントを満たしているかどうかをテストし、その結果をもとに評価することが必須となります。

ということで、アプリケーションが「クラウド・レディ」かどうかをテストする際の留意点について、上記4つのポイントに沿って簡単に説明しておきます。

　まず、「パフォーマンス」のテストですが、クラウド向けのアプリケーションの場合、従来型のアプリケーションとは大きく異なる厄介な点があります。それは、他のサービスとのインテグレーションを行ったうえでのパフォーマンス・テストが（そう簡単には）できないということです。すべてが自前のシステムであれば、クローン環境を作りテストを行うことが可能です。ところが、他者のサービスを利用する場合、それに対して大きな負荷を勝手にかけることは許されません。ゆえに、アプリケーション全体のパフォーマンスをシミュレートできるようなスタブ（他システムを模倣するダミー環境）を用意しなければなりません。そして、例えば、「他者のサービスと遠隔地のデータセンターとのやり取りによって応答時間が遅くなる」といったケースを想定し、そのような場合に自分たちの開発しているアプリケーションがどう振舞うかを確認する必要があります。具体的には、スタブから開発中のアプリケーションへの応答時間を意図的に遅くするといった変化をつけてパフォーマンス・テストを行わなければならないのです。

次に「柔軟性」についてですが、こちらも他者のサービスとのインテグレーションをしたうえでのテストが重要になります。

他者のサービスを利用するがゆえの「不整合」や「想定外の動き」というのは、自分たちのアプリケーションをテストするだけでは突き止められません。とはいえ、システム全体のテストを一から始めると、テスト量は膨大になります。そこで求められるのが、「回帰テストの自動化」です。回帰テストとは、一度テストを行った機能について、「別サービス（他者のサービス）を使うことで、どのような影響が出るか」という点を踏まえて再テストすることを指します。

テスト済みの機能に対して再テストを行っても欠陥が見つかる可能性は低いです。しかし、他者のサービスを利用するということは、中身の分からない機能を利用することにほかならず、それによってどこにどういった副作用が発生するかは未知数です。そのため、同じ機能に対するテストを繰り返す必要があるのです。また、相手側のサービスがバージョンアップした際にも同じ理由から回帰テストを行わなければなりません。

とはいえ、こうした反復作業を常に手作業で行うのでは、クラウドの価値である「ビジネス・スピードにマッチした素早いアプリケーション提供」が困難になります。

また、パフォーマンス・テストの場合と同じく、テスト目的で他者のサービスを勝手に使うことができないことが想定されますので、やはりスタブが必要になります。スタブは、APIやデータ形式が正しくサポートされているかの確認が行えるよう、接続対象のサービスを忠実に再現することが求められます。

　このほか、「回復力」と「セキュリティ」のテストでは、クラウドならではの障害を念頭に置きながら、どういったテストを行うかを検討しておく必要があります。

例えば、回復力について言えば、クラウドのマルチテナント・モデルが災いし、ネットワークとストレージのパフォーマンスが不安定となり、最終的にサービスがダウンしたというニュースも聞こえてきます。ですから、このような事例を常に収集するよう常に心がけ、同様の事態を想定した「回復処理のシナリオ」に沿ってテストを行うことが肝心です。

これはセキュリティについても同様です。クレジット情報の盗難などのニュースは、その原因も含め情報を収集し、同じ状況が発生した場合に問題が起きないかどうかをテストします。また、過去事例はそのリスクの度合いによって優先順位をつけておき、より重大なリスクに対しては、早いタイミングでテストを実行していく必要があるでしょう。

クラウドでも品質の基本は同じ

以上、今回は、「クラウド・レディのアプリケーション」というテーマの下で、それを実現するための4つのポイントについて説明しました。ただし実のところ、ここで掲げた4つのポイントだけで将来的にも十分かと言えば、そうとばかりは言い切れません。なぜならば、クラウドはまだ発展途上にあるからです。おそらくクラウドの世界では今後、一層シームレスに多くの環境と連携することが可能になるでしょう。また、そうしたかたちで、クラウドで実現できることが増えてくれば、クラウドにはより高い価値の提供が求められるようになるはずです。

ですからユーザー企業は、「現時点で実現できるクラウドの価値」を見極めて、クラウド活用に対する周囲の期待にこたえられるようなアプリケーションを開発していかなければなりません。とはいえ、その命題をどう遂行するかで思い悩む必要もありません。大切なのは、クラウドという言葉に振り回されることなく、「その価値を実現することが品質への要求を満たすことにつながる」という品質管理の基本に則ってテストやレビューを行うことにほかならないからです。そして、それこそが品質の高い「クラウド・レディ・アプリケーション」を実現するための最短のコースと言えるのです。