![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
適切に設計されたアプリケーションでは、アプリケーションのある機能を実行するステートは、別の機能を実行するステートへとスムーズに素早く遷移します。アプリケーションは常に利用可能であり、計画されたメンテナンスのための停止を除けばアプリケーションが中断されることはありません (あるいは、あったとしても気付かないほどの中断です)。
開発者がアプリケーションをクラウド環境にマイグレートすることを決断せざるを得ないような状況では、開発者は先を見越した対応ができていません。マイグレーションに向けての準備として、開発者はアプリケーションに何らかの変更を加えます。例えばログイン・ボックスを追加し、適切なクレデンシャルを持ったユーザーのみがアプリケーションを使えるようにします。クレデンシャルには、利用しているクラウド・サービスの種類に応じて、ユーザーがどの程度アプリケーションを制御できるかという情報が含まれています。
開発者がアプリケーションを SaaS (Software as a Service) としてマイグレートする場合、ユーザーが制御できるのは、デスクトップ機器またはモバイル機器からアプリケーションにアクセスし、課金や請求などのビジネス・タスクを処理することのみです。この図式では、SaaS アプリケーションが実行されているオペレーティング・システムやハードウェア、ネットワーク・インフラをユーザーが制御することはできません。アプリケーションのあらゆる機能に対するアップグレードやパッチを作成してビルド、デプロイ、実行、管理できるのは、開発者のみです。
開発者が PaaS (Platform as a Service) の一部としてアプリケーションをマイグレートする場合には、そのプラットフォームのビジネス・ライフサイクル全体の中で、ユーザーはアプリケーションを制御することで、スプレッドシートの操作や給与処理などを行うことができます。ユーザーは、アプリケーションに加える変更の内容 (例えば開発者から提供されたドロップダウン・リストにオプションを追加する、など) を決定することができます。ただしこの場合も、オペレーティング・システムやハードウェア、ネットワーク・インフラをユーザーが制御することはできません。
マイグレーション・プロセスを完了するとまもなく、開発者は相互運用性やパフォーマンスの問題に直面します。アップタイムはサービス・レベル・アグリーメント (SLA) に示された保証レベルよりも下がり始めます。重要なビジネス判断を行う上で必要なデータを要求するリクエストに対し、アプリケーションからのレスポンスが通常よりも遅いという大きな不満の声がユーザーから上がります。ユーザーは新しいビジネスチャンスを失ってしまいました。
開発者は大慌てで手っ取り早いソリューションを求め、反応的な対応になってしまうかもしれません。
開発者は大慌てで手っ取り早いソリューションを求め、反応的な対応になってしまいます。差し当たり、開発者はクラウドの本番アプリケーションを停止し、計画されていたメンテナンス作業であるかのように装います。そして、ユーザーのブラウザーに「サービスは現在一時的に停止しています。しばらくお待ちください。」という通知が表示されるようにし、そのアプリケーションに対する作業を社内で開始します。
まもなく開発者は、ビジネス・タスク (例えば請求用のタスクなど) のドロップダウン・リストを含めるようにコードを拡張するのが困難であることがわかります。そして、社内で実行すれば完璧な動作をするアプリケーションが、以前の開発者によって1 つの大きなユニットとして作成されており、(例えば 500 個の) モジュールで構成されているわけではないことに、遅まきながら気付きます。
開発者は必死になって、ドロップダウン・リスト用のモジュールを追加することでアプリケーションを修正し、クラウドでテストを行い、リソース・インスタンスが均等に割り当てられた上でアプリケーションを適切に実行できるかどうかを判断します。しかし、時すでに遅く、ロード・バランシングがうまく行かなかったことに気付きます。最大負荷に達してしまったリソース・インスタンスが 1 つあり、そこが障害となっています。他のリソース・インスタンスは既に最大負荷の 75 パーセントに達しており、障害となっているリソース・インスタンスからビジネス・トランザクションを引き継ぐことができませんでした。
マイグレーションを行う前、開発者は各リソース・インスタンスを最大負荷の 50 パーセントで使用するという点を確認しませんでした。その点が守られていれば、1 つのリソース・インスタンスに障害が発生した場合にも、そのインスタンスを健全なリソース・インスタンスが引き継ぐことができます。
その間、ユーザーは長引くメンテナンス作業に不満の声を上げ、アプリケーションに何か問題があるのでは、と疑い始めます。ユーザーは、SLA の規定どおりのサービスが提供されなかった補償として、割引、返金、一定期間の支払い免除などを要求します。そして、不十分なサービスの提供が継続する場合にはサービスの解約が認められるべきであると要求します。
この時点で開発者は、アプリケーションをマイグレートする前に以下の 2 つを行わなかったことを深く後悔します。
- アプリケーションをモジュールに分割すること
- リソースのしきい値用のウィンドウをアプリケーションに含め、リソース・インスタンスの使用状況を追跡できるようにすること
開発者は、最初の時点から先を見越してアプリケーションの動作を変更しなかったことで、サービス、ユーザー、評判を失ったことを深く嘆きます。もし先を見越した変更をしていたら、今とは違う結果になっていたはずです。
開発者が先を見越してアプリケーションの動作を変更すれば、ユーザーを満足させることができ、評判を落とすこともなく、新たな利用者を得ることもできます。
まず、開発者はチームを編成してアプリケーションをモジュールに分割し、各モジュールの動作の変更を行います。変更が完了したら、チームはそれらのモジュールを社内でテストし、ユーザーの立場でチェックを行い、モジュールの動作がユーザーの期待どおりであることを確認します。そのテストが終了すると、開発者はそのアプリケーションをクラウド・サービスへとマイグレートします。
チームがアプリケーションに含めるモジュールの例として、以下の 2 つが考えられます。
- ドロップダウン・リスト・コントロール
- しきい値用のサムネイル・ウィンドウ
このドロップダウン・リスト・コントロール・モジュールにより、ユーザーは相互排他的な値のリストから選択することができます。1 回のマウス・クリックにより、ユーザーは 1 つだけ選択することができます。Ctrl キーを押したままマウスを操作すると、ユーザーはリストの中から複数の値を選択することができます。標準的なドロップダウン・リストでは、ユーザーが選択できるのはリストの中にある値のみですが、コンボ・ボックスを使用すると、リストには無い値を入力することができます。
ドロップダウン・リストの一例として、ビジネス・タスクのドロップダウン・リストを挙げます。このリストでは以下のタスクを有効にできる必要があります。
- 給与処理
- スプレッドシート
- 請求処理
- 課金処理
「給与処理」を選択すると、アプリケーションはバックグラウンドで別のアプリケーションに接続され、給与処理が開始されます。「スプレッドシート」を選択すると、スプレッドシートの一覧が表示されるので、その中からスプレッドシートを選択して、そのスプレッドシートを表示、編集することも、新しいスプレッドシートを追加することもできます。
「請求処理」を選択すると、請求書の一覧が表示されるので、その中から請求書を選択して、その請求書を表示、印刷することができます。また、空白の請求書フォームを表示し、そのフォームに記入した後、E メールで受信側に送信することもできます。「課金処理」を選択した場合、アカウントを選択することで、そのアカウントに対する課金計算の結果を表示して、送信することができます。
新しいビジネス・タスクがアプリケーションに追加されたにもかかわらず、選択肢の一覧に表示されていない場合には、例えば「invoicing2」とコンボ・ボックスに入力することができます。
ここで別のドロップダウン・リストの例を挙げます。このリストには以下の 4 つのしきい値の選択肢が示されています。
- リソース
- ユーザー
- データ・リクエスト
- ダッシュボード
この中から 1 つをマウス・クリックによって選択すると、しきい値用サムネイル・ウィンドウ・モジュール (次のセクションで説明します) によってウィンドウが表示され、そのウィンドウには選択した項目に関するアプリケーションの実行状況が示されます。
例えば「リソース」を選択した場合、リソースの使用状況に関するサムネイル・ウィンドウが画面に表示されます。「ユーザー」を選択すると、ユーザー・ステータスに関するサムネイル・ウィンドウが表示されます。「リソース」と「ユーザー」を選択する場合には、CTRL を押したまま両方の項目をマウス・クリックすると、それぞれに対するサムネイル・ウィンドウが並べて表示されます。「ダッシュボード」を選択すると、「リソース」、「ユーザー」、「データ・リクエスト」の 3 つが 1 つのウィンドウに表示され、それぞれが異なるしきい値レベルを示すようになります。
このモジュールは、しきい値用のドロップダウン・リストから項目が選択されると、サムネイル・ウィンドウをポップアップ表示します。このウィンドウには、プロバイダーが SLA のしきい値ポリシーに規定したしきい値レベルに関する、アプリケーションの実行状況がリアルタイムで示されます。
このモジュールでは、アプリケーションが許容しきい値レベル以下で実行されていると判断すると、アプリケーションを計画どおりに実行して運用を継続します。許容しきい値レベルを超えているものの、まだ最大レベルにまでは達していない場合には、何らかの理由でアプリケーションの運用が中断される可能性があることを示します。中断の理由としては、タスクを完了させるにはリソースが不足している、ユーザーがサービスの利用終了後にログオフしていない、キューに残っているデータ・リクエストの数が多すぎる、などが考えられます。
中断が数ミリ秒間の場合には、通常は人間の目では認識できず、運用が継続されます。
しきい値レベルの設定が高すぎると感じられる場合には、プロバイダーに連絡し、許容可能なレベルにまで引き下げる必要があります。
次は、どうしたら先を見越した対応をし続けられるのかを説明します。
クラウド環境にマイグレートする予定のアプリケーションを適切に変更できたら、先を見越した対応をし続けられるようにするために、以下の点を確認する必要があります。
- しきい値ポリシー
- ブラウザーに固有の制約
- アプリケーションのステートフル性
- フェイルオーバー・メカニズムのタイプ
- セキュリティーの問題
しきい値ポリシーとして、「リソース」、「ユーザー」、「データ・リクエスト」という 3 つのタイプを考えます。それぞれのポリシー・タイプにおいて、アプリケーションをテストする場合のしきい値レベルは本番の場合と異なるかもしれません。負荷計画を事前に行い、システムにしきい値ポリシーを実装する準備をする必要があります。
「リソースしきい値ポリシー」を設定すると、クラウド内のアプリケーションに対するリソースの使用状況を動的にバランスさせられるようになります。しきい値レベルの設定は、追加で使用可能なリソース・インスタンスの最大数よりも低く設定する必要があります。ワークロードの需要が急増し、リソースがしきい値レベルを超えて使用される場合には、追加のリソース・インスタンスが割り当てられます。需要がしきい値レベル以下に下がると、作成されたリソース・インスタンスは解放され、他の目的に使用されます。
「ユーザーしきい値ポリシー」を設定すると、プロバイダーによるユーザー・ライセンスに規定された制限値まで、複数のユーザーが同時にアプリケーションにアクセスできるようになります。例えば、ライセンスによってユーザーを 3,000 ユーザーに制限し、同時にアクセスできるユーザーは最大 2,500 ユーザーまでとし、同時アクセスユーザー数のしきい値レベルを 2,000 ユーザーに設定する、といったことができます。同時アクセスユーザー数が、アプリケーションに設定された数以下の場合には、リソース使用量とデータ・リクエストはそれぞれのしきい値レベル以下とみなされ、アプリケーションを継続的に利用することができます。
「データ・リクエストしきい値ポリシー」を設定すると、アプリケーションに対するデータ・リクエストを即座に処理できるようになります。しきい値レベルの値は、複数ユーザーが同時に送信できるデータ・リクエストの最大数ならびに最大サイズ未満に設定します。データ・リクエストの数がしきい値レベルを超えた場合には、メッセージをポップアップ表示し、キューで処理を待機しているデータ・リクエストの数を示す必要があります。
Mozilla Firefox と Internet Explorer の両方を使用している皆さんは、Firefox の方が Internet Explorer よりもページのロードが速く、メモリーの使用量も少ないことをご存知ですか？Firefox の主な制約は、以下のような場合に異常終了したり応答が遅くなったりすることです。
- リソース使用量がリソース・インスタンスの最大許容数に達した後、追加リソースが得られない場合
- リソース使用量がしきい値レベルを超えた場合に警告するためのしきい値用サムネイル・ウィンドウがない場合
この問題に対処するためには、確実にリソース使用量をしきい値レベル以下に維持すると同時にインスタンスのリソース冗長性に関するフェイルオーバーが機能するようにします。
リソース使用量がしきい値レベルを超えていることをサムネイル・ウィンドウに表示する場合には、そのサムネイル・ウィンドウには以下の表示も行う必要があります。
- リソース使用量の超過を示す警告メッセージのポップアップ表示
- ブラウザーの終了を促すメッセージ。またはシステムに firefox.exe プロセスを自動削除させ、ブラウザーを再起動する必要があります。
皆さんはアプリケーションの機能のステートフル性がどの程度適切に実行されているかご存知でしょうか？ステートフル性というのは、クラウド内のアプリケーションがある機能を実行するステートになっている場合、そのステートに続いて別の機能を実行するステートに遷移したときに、アプリケーションがどの程度適切な動作をするかを指しています。
単純化しすぎた例かもしれませんが、クラウド内で業務用に小売商品を購入する場合、その購入に使われるクレジットカードの情報を検証するステートは、銀行口座にカード情報を送信するステートに即座に遷移する必要があります。その後、購入商品が購入者の職場宛に発送されたことを通知するステートに即座に遷移します。
アプリケーションが、あるステートから別のステートに遷移した結果、社内でアプリケーションが実行されていたときよりもクラウド内で実行されているときの方が、処理に時間がかかるようになる場合には、以下の原因が考えられます。
- アプリケーションのロジックに欠陥があり、ビジネス・トランザクションを適切に処理することができない。
- 「リソース」、「ユーザー」、「データ・リクエスト」のすべてあるいはそのいずれかの、しきい値レベルの設定が高すぎる。
- リソース・インスタンスが十分ではないため、ステートフル性を適切なタイミングで実現できない。
- 同じリソース・インスタンスに対して「ユーザー」または「データ・リクエスト」が競合している。
フェイルオーバー・メカニズムは、ハードウェア障害が発生しそうな場合やリソース不足の場合、あるいはレイテンシーが大きすぎる場合などに、確実にアプリケーションが運用を継続できるようにします。例外としては、不可抗力による事故、プロバイダーによる計画的なメンテナンス作業のための停止、光ファイバーの切断事故などがあります。
フェイルオーバー・メカニズムとしては、以下のような例を検討する必要があります。
- 負荷共有冗長構成: 複数のシステムを使用し、各システムの負荷を全負荷の 50 パーセント以下とします。ある機器に障害が発生した場合、サービスの中断やしきい値の変更をほとんど (あるいはまったく) することなく、他の機器が負荷を引き継ぎます。
- インスタンスのリソース冗長構成: 複数のリソース・インスタンスを使用し、各インスタンスの負荷を全負荷の 50 パーセント以下とします。あるリソース・インスタンスに障害が発生した場合、しきい値をほとんど (あるいはまったく) 変更することなく、他のリソース・インスタンスが負荷を引き継ぎます。
- データ・リクエスト・キュー冗長構成: 複数のデータ・リクエスト・キューを使用し、各キューの負荷を全負荷の 50 パーセント以下とします。あるキューに障害が発生した場合、切り換えによる中断がほとんど (あるいはまったく) 発生することなく、他のキューが負荷を引き継ぎます。
- 代替接続による接続再試行: ネットワーク中断の時間が 2 分を超えた場合、代替ネットワーク接続を介して別の物理サーバーまたは仮想マシンに接続し直します。
皆さんの会社の収益が 10 億 US ドルを超えている場合、プライベート・クラウドの方がパブリック・クラウドよりもコスト効率が高い可能性があります。社内用のプライベート・クラウドのビジネス特性の多くはパブリック・クラウドの場合と同じですが、セキュリティー、可用性、フェイルオーバー・メカニズムに関し、収益 100 万 US ドル未満の小規模な企業のガバナンスよりも高いガバナンスを実現することができます。
社内用のプライベート・クラウドを利用すれば、特定の管轄区域 (例えば、米国やカナダなど) 内の既知の場所にデータを保管し、そこからデータを取得することができます。機密データ、コンプライアンスやプライバシーに関わるデータ、そしてテスト・データの保管には、社内用のプライベート・クラウドが適しています。
対照的に、パブリック・クラウド内のデータはどこに保管されるのかはわからないため、容易に取得できない可能性もあります。保管場所がわからない場合、コンプライアンスやプライバシーに関わるデータ、機密データ、そしてテスト・データの保管には適していません。
セキュリティーに関する 1 つの問題として、既知の場所に保管された機密データ、コンプライアンスやプライバシーに関わるデータ、そしてテスト・データに、プロバイダーの管理者が許可なくアクセスできるかどうか、という問題があります。もう 1 つの問題として、データが保管されている地域では、プライバシーやコンプライアンスに関する規制が皆さんの知っている国々の規制とは異なるかもしれません。データの輸出管理に関する法律も国によって異なる場合があります。
許可を与える前に、管理者の責任を契約に明記する必要があります。その内容としては、データへのアクセスに関して管理者に許可されることと、許可されないこと、データの輸出に関して管理者が遵守すべき法律、ハッカーがクラウド内に指令室 (CnC) をセットアップするリスクを軽減するために管理者が実行すべきポリシー、などが挙げられます。
ハッカーは、場所が特定できないデータ保管場所とデスクトップとの間で送受信されるデータを検出するツールを持っており、PaaS プラットフォームを指令室として使用して、DDoS (分散型サービス不能) 攻撃用のボットネットを直接操作し、クラウドにマルウェア・アプリケーションをインストールします。ハッカーが悪意のあるアプリケーションを開発してデプロイする目的としては、以下のものが挙げられます。
- 悪意のあるリソース・インスタンスを割り当てる
- しきい値レベルを非現実的な高い値にセットし直す
- アプリケーションがある機能を実行するステートから、悪意のある機能を実行するステートへ遷移させる
社内で完璧に動作するアプリケーションをクラウドでも動作するように変更するには、アプリケーションをマイグレートした後に先を見越してアプリケーションの動作を変更し続けられるように、事前の計画をしておく必要があります。開発者、ユーザー、ビジネス・アナリストのチームが協力することで、クラウドでのしきい値ポリシーの設定、ブラウザーに固有の制約の克服、フェイルオーバー・メカニズムのカスタマイズ、セキュリティーの問題に関する検討などを行う必要があります。チームは、こうした点を適切に扱うことで、先を見越してアプリケーションの動作を変更し続けるのがはるかに容易になります。
学ぶために
- この記事の著者はしきい値ポリシーに関して別の記事でも解説しています。「クラウド環境内のワークロードを分散させる:
しきい値ポリシーを使ってワークロードへの要求を動的に分散させる」と「クラウド・コンピューティングとグリッド・コンピューティングの比較:
サービスのタイプ、類似点と相違点、そして検討しなければならない点」を読んでください。
- developerWorks
でクラウド開発者のためのリソースを調べてください。クラウドにデプロイするためにプロジェクトを構築しているアプリケーション開発者やサービス開発者の知識や経験を発見し、共有することができます。
- この記事に対応する developerWorks の他のリソースとして、developerWorks の SOA and web
services ゾーンと developerWorks
の Industries ゾーンがあります。
- 次のステップとして、「IBM
Smart Business Development and Test on the IBM Cloud」にアクセスする方法を学んでください。
製品や技術を入手するために
- IBM Smart Business Development
and Test on the IBM Cloud で利用可能な製品イメージを調べてみてください。
議論するために
- developerWorks
のクラウド・コンピューティング・グループに参加してください。
- developerWorks
でクラウドに関する優れたブログを読んでください。
- developerWorks コミュニティーに加わってください。developerWorks コミュニティーは専門家のネットワークであり、接続、共有、および協力のための一連のコミュニティー・ツールを豊富に提供しています。
