クラウド・アプライアンスへのアプリケーションの統合: 18 のプラクティス

アプリケーションを適切に構成してクラウド・アプライアンスにインストールするためのベスト・プラクティス

アプリケーションを所有する人たちの間では、次第にアプリケーションをクラウド環境にホストすることを望む人が増えています。けれどもそれは、アプリケーションが複雑であったり、実行環境に深く依存していたりすると難しい場合があります。アプリケーションをクラウドにデプロイする場合の一般的なシナリオは、クラウド対応ではないソフトウェアを、既にクラウド上で実行されているソフトウェアに統合するというものです。そのためには、クラウドへデプロイするアプリケーションに対して、いくつかの機能を実装する計画を立てる必要があったり (まだそのアプリケーションに手を加えている最中である場合)、いくつかの機能を統合する必要があったりします (そのアプリケーションが既に完成した状態で存在する場合)。この記事では、アプリケーションをクラウド上で動作する製品に容易に統合できるようにするため、あるいはアプリケーションをクラウド・アプライアンスに容易に統合できるようにするため、さらにはアプリケーションをクラウド内の独立したアプライアンスとして容易にホストできるようにするための 18 種類のベスト・プラクティスを紹介します。

Sheetal Jharia, Staff Software Engineer, IBM

Sheetal Jharia は、IBM-ISL に勤務するスタッフ・ソフトウェア・エンジニア (および IBM Cloud OS 開発主任) です。現在は、IBM クラウド・ポートフォリオの重要な製品である IBM Systems Director VMControl の開発に取り組んでいます。IT で 8 年の経験を積む彼女は、インド工科大学マドラス校で電子通信システム・エンジニアリングの学士号および修士号を取得しました。



Ashish Billore (Ashish.Billore1@in.ibm.com), Development Manager, IBM

Ashish Billore は、IBM India Labs に務める IBM Cloud OS 開発マネージャーです。彼は IBM Systems Director VMControl 開発チームを管理し、クラウド・インフラストラクチャーを構築するために再利用可能なコンポーネントの開発担当として、Java、Eclipse、OSGi、Web サービスなどの技術を使用したアプリケーションの設計、開発を行っています。Eclipse オープンソース・プラットフォームのパッチに貢献し、IBM technology と QSE コンファレンスで記事を発表したこともあります。彼は電子通信エンジニアリングの学士号を取得し、大学院で情報技術を学びました。



2012年 8月 30日

この記事では、以下の目的を達成するために、クラウド対応のアプリケーションを設計してパッケージ化する際のベスト・プラクティスを紹介します。

  • アプリケーションをクラウド上で動作する製品に統合することで、他の製品がそのアプリケーションの機能を利用できるようにすること
  • アプリケーションを既にクラウドにホストされているアプライアンスに統合すること
  • アプリケーションをクラウド内で独立したアプライアンスとしてホストすること

上記のシナリオのいずれかに興味がある場合には、その目標を達成するためのベスト・プラクティスとして要約した私たちの経験を読んでください。

まずは、これらのシナリオについてもう少し詳しく説明します。

3 つのシナリオ

繰り返しますが、ここで取り上げるシナリオは、アプリケーションをクラウド上で動作する既存の製品に統合する場合、アプリケーションを包括的なアプリケーション・パッケージの一部としてクラウドにデプロイする場合、またはアプリケーションをクラウド上で動作する既存のアプライアンスに統合する場合に関連します。

クラウド上で動作する製品にアプリケーションを統合する

この場合、統合するアプリケーションの機能によって、既存のクラウド・アプリケーションの機能を強化する必要があります。目標は、この機能強化をシームレスに実現することです。

既存の製品に新しい機能を導入するとなると、その新しい機能を一から設計して開発する作業が伴うことはよくあります。その代わりの方法となるのは、使用可能な (この場合、クラウド対応ではない) 製品を利用して、その機能をクラウド上で動作する製品に統合することです。このシナリオでは、アプリケーションがクラウド上で動作する既存の製品と適切に「接続」できることを確実にしなければなりません。

既にクラウドにホストされているアプライアンスにアプリケーションを統合する

クラウド・アプライアンスは、あらかじめインストールと構成が完了しているソフトウェアおよびアプリケーションで構成されています。場合によっては、自己完結型のサーバーとしてクラウド・アプライアンスを使用することもできます。アプリケーションを追加することによって既存のクラウド・アプライアンス・パッケージの機能を強化する計画を立てる際には、追加するアプリケーションが、そのパッケージに含まれる他のアプリケーションと適切に共存動作すること、そしてアプライアンスの構成ファイルおよびリソース依存関係に適切に対応することを確実にしなければなりません。

アプリケーションを単独のクラウド・アプライアンスとしてホストする

アプリケーションを独自のクラウド・アプライアンス内に組み込んでクラウドに移すというのも、1 つの方法です。特に、アプリケーションを他のクラウド・アプリケーションと統合する必要がない場合には、この方法を適用することができます。

本題に入る前に、この記事で使用するアプライアンス、アプリケーション、仮想マシンという用語の意味を理解しておくと役立ちます。

  • 仮想アプライアンス: 1 つ以上の仮想マシンからなるビルド済みのソフトウェア・ソリューション。仮想アプライアンスはパッケージ化されて、1 つの単位として保守、更新、管理されます。開発者は、必要なものをすべて完備して最適化されたアプリケーション・スタックを開発することによって仮想アプライアンスを作成します。これらのアプリケーション・スタックは、それぞれのワークロードに応じてカスタマイズされ、最適なオペレーティング・システムが組み込まれます。アプライアンスは、従来のソフトウェアよりもセキュアで信頼性に優れたものにすることができます。また、一連のファイルをコピーして仮想アプライアンスの電源をオンにするだけで、アプリケーションが使用可能になります。
  • アプリケーション: クラウド対応のアプリケーション。ある特定の機能または一連の機能を実行します。アプリケーションは、アプライアンスに含まれるアプリケーション・スタックのコンポーネントです。
  • 仮想マシン: 仮想プラットフォームで実行するために作成された、厳格に分離されたソフトウェア・コンテナー。仮想マシンには、重要な 4 つの仮想リソースが収容されます。それは、CPU、RAM、ストレージ、およびネットワークです。

この記事で使用する「製品」という言葉は、コンテキストによって「アプリケーション」または「アプライアンス」のいずれかを意味します。

ここからは早速、以上のシナリオを現実にするためのベスト・プラクティスを見て行きましょう。


プラクティス 1: サイレント・インストールをサポートすること

処理の進行中にメッセージもウィンドウも表示しないインストールは、サイレント・インストールと呼ばれます。サイレント・インストールは、無人インストールとは違います。無人インストールとは、ユーザーによる操作を必要としないインストールのことで、サイレント (またはクワイエット) インストールとは、その進行状況をまったく示さないインストールのことです。

製品では、対話式 (あるいは GUI による) インストールと併せてサイレント・インストールもサポートし、ユーザーがこの 2 つの方法のどちらかを選択して製品をインストールできるようにしなければなりません。サイレント・インストールの場合、インストールに必要なユーザー入力は、レスポンス・ファイルに指定してください。このレスポンス・ファイルを編集する必要があるのは一度だけで、それはインストールの開始時です。インストールの開始後に、ユーザー・データが必要になったり、進行状況やウィンドウがユーザーに表示されたりするのは望ましくありません。

アプリケーションが別のアプリケーションまたはアプライアンスに統合されると、それは 1 つの製品の一部となり、インストーラーはその製品の単一のインストーラーとして作成されます。製品をサイレント・インストールできない場合、製品のインストール時にユーザーからの情報が必要になります (アプライアンス・チームは製品のインストール時に、ユーザーに情報を表示したり、情報を要求したりすることを望まないかもしれません)。これはユーザーにとっては迷惑なことです。また、ユーザーがそれらの製品の詳細を知らなければならないわけでもありません。サイレント・インストールを使用できないとしたら、統合によって得られた有効性を失ってしまいます。ユーザーにとって、それは 2 つの異なる製品をインストールしなければならないようなものだからです。


プラクティス 2: ディスク・スペースの使用量を制御すること

ディスク・スペースの使用量を制御するためには、システム・リソースが自動的に抑制されるようにする必要があります。製品の機能やプロセスがログとトレース・データを出力ファイルに書き込む場合 (そうでない場合は一体どれだけあるのでしょう!)、アプライアンス・サーバーにおいてメモリー不足の状況が発生しないように、このデータ・フローを制限するプロセスを用意してください。

プロパティー・ファイルを作成して、生成する出力ファイルのサイズと数を定義してください。これらの値は、システム管理者が編集できるようにします。その上で、これらのプロパティー・ファイルをモニターするプロセスを作成します。

出力ファイルのサイズまたは数がプロパティー・ファイルに指定されている制限を超えた場合には、以下のいずれかの措置を講じることが考えられます。

  • 古いファイルを削除して、新しいファイルで置き換える
  • システム管理者にこの状況を警告する
  • ログ・ファイルへの新しいデータの書き込みを停止する

さらに、構成可能なプログラムによって以下の処理を (オンザフライで) 行うというオプションを提供することも必要です。

  • ログを適切な場所へリダイレクトする: アプリケーション環境では、ログのモニターおよび収集を容易にするために、システム管理者がすべてのログを一箇所に集めることがあります。したがって、製品にはログを保管する場所を選択する手段を用意してください。
  • ログ・ファイルの名前を指定および変更する: ログを保管する場所に加え、ユーザーが独自の基準や自らの都合に応じて、ログ・ファイルの名前を指定できるようにする必要があります。製品が将来、大規模かつ高度なアプライアンスの一部になることを念頭に置いて、さらに柔軟性を高めるためには、ログ・ファイルの名前も変更できるようにする必要があります。
  • ログ出力ストリームのオプションを提供し、ログを他の任意のログに組み込む: この高度な機能により、ログを別のログに組み込むための柔軟性がもたらされます (該当する出力ストリームがアプライアンス環境で許可されることが前提です)。

プラクティス 3: 設定は、API または CLI で変更できるようにすること

すべての構成設定には、API またはコマンドライン・インターフェースでアクセスして操作できなければなりません。REST Web サービスは、疎結合、軽量、相互運用性といった性質を備えていることから非常に人気があり、おそらく最もよく使用されています。プロパティー・ファイルやその他のファイルを手作業で変更しなければならないプロセスがある場合には、その変更を CLI または API で行えるように、プロセスを適応させてください。

特定の設定や構成を、アプライアンスのインストール中、またはアプライアンスの全体的な機能の一環として完了しなければならない場合には、CLI または API を使用して完了できるようにする必要があります。アプリケーションの内部設計を理解しなくてもアプライアンスの設定を変更できるような設計にし、CLI だけを使用して設定を変更できるようにしてください。

また、このような構成または設定が変更された場合には、アプリケーションを再起動しなくても、その変更がオンザフライで適用されるようにすることが理想です。そうすれば、アプライアンス全体の機能が中断されることがありません。


プラクティス 4: トレース情報およびログ情報を API/CLI によって収集できるようにすること

製品での問題が報告されたときに、問題を徹底的に診断するためには、製品からログを収集することが重要です。コマンドライン・メカニズム (あるいは他の手段) を用意して、選択的かつ独立した診断操作を行えるようにしてください。つまり、診断操作がアプライアンス全体に影響しないようにするということです。これらのメカニズムには、システム管理者が直接使用できるログ/トレース情報の収集機能も含まれます。


プラクティス 5: 高可用性をサポートすることには、実に素晴らしいメリットがあります

ほとんどの IBM 製アプライアンスは、顧客の要望である高可用性をサポートするように考慮されています。アプライアンスに統合する製品が高可用性をサポートしていなければ、アプライアンス全体としての高可用性の効果が低減されてしまいます。製品の開発を開始する時点で、高可用性をサポートした設計を実施するか、あるいは将来的に高可用性をサポートした開発を行う余地を残しておくことが賢明です。


プラクティス 6: ライフサイクル機能を提供すること

アプリケーションの一部として実行しているプロセス、スレッド、あるいはデーモンには、いずれも独自のライフサイクル機能がなければなりません。起動、一時停止、停止などの一般的な状態に対応しなければならないため、CLI または API を使用して、製品自体がこれらの状態を制御するための対策が必要です。


プラクティス 7: すべての構成を再構成可能にすること

プリロードの際に前提とされる構成には、アプライアンスを作成するときにリセットできるようにする手段を持たせる必要があります。また、顧客の要求に応じて再構成できるようにすることも必要です。

皆さんの製品は、単独では特定の設定 (例えば、IP アドレス、ポート設定、またはネットワーク設定など) で動作するかもしれませんが、その製品を別の製品に統合するときには、これらのパラメーターを顧客の作業環境や製品全体の要件に応じて変更しなければならない可能性があります。このような設定は、製品の統合時、アプライアンスの作成時、あるいは顧客のデプロイメント時に再設定および変更可能にする必要があります。


プラクティス 8: アプライアンス内のアプリケーションをアクティブまたは非アクティブにできるようにすること

この機能の実装はオプションではありますが、重要です。コマンドライン、API、または GUI を使用してアプリケーションをアクティブまたは非アクティブにできるようにすることで、製品に関連するファイルをディスクに格納する一方で、製品をホストするシステムの CPU リソースやメモリー・リソースを使用しないようにすることは、アプリケーションにとって大きなメリットがあります。このようにすれば、製品を別の製品に組み込んで、必要に応じてオンにしたり、オフにしたりして使用することができます。クラウド内では、アプライアンスが当初の製品をホストし続けながらも、特定のサービスに対応する機能を非アクティブにすれば、そのサービスを停止することができます。


プラクティス 9: アプライアンスにパッチを適用できるようにすること

製品に使用可能な更新またはパッチがある場合、アプライアンスの統合環境の中でそれを適用できるようにする必要があります。製品が別の製品に統合されたからと言って、その製品のチームが機能強化の取り組みを止める必要はありません。設計フェーズで製品の更新パスを定義しておけば、引き続き機能強化に取り組むことができます。

将来、アプリケーションが他のクラウド・アプライアンスに統合される可能性もあるため、アプリケーションは統合環境内でパッチを適用できるようにする必要があります。

また、アプリケーションの更新、修正、パッチをパッケージ化して、アプライアンスの他の更新に組み込んだり、一緒にバンドルしたりできるようにすることも必要です。さらに、そのパッチ/更新プロセスは、アプリケーションを再起動することなく完了できるようにしてください。

変更内容がアプライアンスの他のコンポーネントに対応しないことが判明した場合に備え、適用した更新またはパッチの取り消しを可能にする対策を含めておくのも賢明です。


プラクティス 10: あらゆるシェルでコマンドが機能するようにすること

すべてのコマンドが特定のシェルに制限されることのないようにしてください。アプリケーションに関連付けられた CLI コマンド (少なくとも、最も重要なコマンド) が、特定のシェルでのみ機能するように制限されていてはなりません。製品を統合する対象となるアプライアンスは、それとは異なるシェルで動作している可能性もあります。その場合、シェルが異なるという理由だけで、CLI コマンドを実行できなくなってしまいます。


プラクティス 11: ライセンス・キーが入力された時点で、ライセンス・キーを必要とする機能が有効になるようにすること

ライセンス・キーを必要とする機能は、アプライアンスの共通 GUI または共通 CLI に関連付けて、ライセンス・キーが入力された時点で有効になるようにしてください。アプリケーションに組み込まれた機能のうち、ライセンス・キーを必要とする機能が 1 つでもある場合には、この機構を適切に設計し、始めからアプライアンスの共通 GUI に統合します。その際、アプリケーションのコンポーネントのライセンスが適用されると、共通 GUI でもそれを検出して、アプライアンスのユーザーに通知されるような仕組みにします。こうすることにより、顧客はどのライセンスを既に使用していて、どのライセンスを適用または購入しなければならないかを明確に認識することができます。さらに、クラウド管理者が各種のライセンスを効果的に保守する上でも役立ちます。アプリケーションには、ライセンス情報を照会して、再起動することなくライセンスを適用または更新するための API を用意してください。


プラクティス 12: 商標設定を有効にすること

これは重要な要件です。アプリケーションには、別の製品やアプライアンスに組み込まれる際に (製品名およびバージョン番号と共に) アプリケーションの商標を変更するための手段を用意してください。

アプリケーションの機能が組み込まれているアプライアンスの所有者が、アプライアンスの共通目的に密接に関連する名前でその機能を表現するように、その機能の商標を付けなおすことを望むようなケースも考えられます。

バージョン番号も、アプライアンスによって上書きできるようにする必要があります。それにはさまざまな方法があります。その 1 つは、製品名とバージョン番号を記述するファイルを一定の値を持つ変数として設定し、アプライアンスの管理者が変更できるようにすることです (当然、その管理者が適切な権限を持つことが前提となります)。


プラクティス 13: プログラムを正常に終了できる API を用意すること

API によってアプリケーションを正常かつ直接停止できるようにしてください。アプリケーションに含まれるプログラムを急遽終了する必要が生じた場合 (クリティカル・シャットダウンや、プログラムが応答していない場合など) に備え、データを破損したり、アプライアンスに悪影響を与えたりすることなく、製品内のプロセスとスレッドを正常に終了できる API が用意されていなければなりません、


プラクティス 14: データのバックアップおよびリストアを可能にすること

API を使用してデータを複数のフォーマット (フラット・ファイル、データベース・ダンプなど) でバックアップおよびリストアできるようにしてください。アプリケーションに関連するすべての重要なデータをバックアップして、必要に応じてリストアできる、(GUI を必要としない) コマンドライン機能を開発する必要があります。

このプラクティスは、アプライアンスにおいて製品の再インストールが完了した後、製品が前と同じプロセスと機能を実行できるようにするために以前のデータが必要になる場合に必ず役に立ちます。また、アプライアンスのレジリエンシーまたは高可用性を強化する上でも有益です。


プラクティス 15: 必要なものがすべて揃った自己完結型のアプリケーションにすること

アプリケーションをアプライアンスに単独で組み込んだり、削除したり、更新したりできるようにする上で、このプラクティスは重要な要件です。システム管理者がアプリケーションの組み込み、削除、更新を行う際に、アプリケーションが外部のデータや、設定、構成、環境などに対して潜在的に持つ依存関係に悪戦苦闘するようであってはなりません。


プラクティス 16: API を使用してアプリケーションにデータをインポートおよびエクスポートできるようにすること

アプリケーション内からデータを照会したり、アプリケーションから任意の場所にデータを書き込んだりするために使用できる API が用意されていると便利です。その同じ API を使って、データの照会または書き込みに対するユーザーの権限を管理することもできます。そのような API がアプリケーションに用意されていれば、アプライアンス・チームがアプリケーション内の機能を編集するプロセスが容易になるとともに、機能のモジュール性が促進されることになります。


プラクティス 17: プログラムによるユーザーの管理手段を用意すること

プログラムによってユーザーおよびロールの作成、削除、変更を行い、各種のオプションや機能を制限する手段を用意してください。アプリケーションの機能 (および、セキュアなアプライアンス機能) に対するアクセスをセキュアにするためには、プログラムで各種のユーザーおよびそのロールを制限したり、管理したりする手段が必要です。ユーザーおよびロールを作成し、それぞれの権限を管理するためのインターフェースとしては、GUI が理想的なインターフェースとなるでしょう。


プラクティス 18: 緊密な外部依存関係を必要最小限にすること

特定のバージョンやベンダーへの結合は、いずれも疎結合でなければなりません。アプリケーションで使用する外部ツールへの緊密な依存関係は排除するようにしてください。


まとめ

アプライアンスをクラウドで実行することを予定している場合、さらに、それをクラウド・アプライアンスに追加することを計画している場合にはなおのこと、そのアプライアンスがクラウドで既に実行されているかどうかに関わらず、この記事で説明した 18 の基本的なプラクティスが、クラウドに応じたアプライアンスの修正を検討する上で参考になるはずです。

次のステップは、それぞれのプラクティスをさらに深く掘り下げて、実際にそれらを実装することを検討することです。そして、その実装が効果的なクラウド・アプリケーション、つまりクラウド環境に簡単に統合できるアプリケーションの構築において持つ意味を理解してください。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmarterCloud Enterprise に用意された製品イメージを調べてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=832151
ArticleTitle=クラウド・アプライアンスへのアプリケーションの統合: 18 のプラクティス
publish-date=08302012