BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース CohesiveFTのElastic Server On-Demand - 容易なサーバープロビジョニング

CohesiveFTのElastic Server On-Demand - 容易なサーバープロビジョニング

ブックマーク

複雑さは本当に人々にとって深刻化している問題である。私たちは日々「すべてに対してMore(より多く)」に襲われている - より多くのソフトウェア選択、より多くのバージョン、より多くのシステム、より多くのビジネス変化、というように。そしてまもなく - より多くの仮想化 - より多くのVM(仮想マシン)もそれに加わるだろう。2010年に、あなたの企業・組織にはいくつのVMがあるだろうか? VMはどのように製造およびプロビジョニングされ、これが現在と同じ方法で行われるのだろうか? InfoQは、CohesiveFTの創始者であるAlexis Richardson氏と、同社の製品である「Elastic Server On-Demand」について話をした。これは、仮想化されたアプリケーションスタックの使用を単純化することを目的とした製品である。

InfoQ: InfoQの読者のために、Elastic Server On-Demandの概要について説明してください。

CohesiveFT: Elastic Serverはセルフサービスと自動化によって仮想マシン管理の問題に対処します。Elastic Server On-Demandサービスは、仮想サーバー(source)やクラウド形式(source)向けに、すぐに実行可能な注文に応じたアプリケーションスタック(source)を提供します。このサービスは、複数の手動による手順とスクリプトを、迅速かつ使いやすい(source)単一の自動化されたプロセスに置き換えることで、アセンブリと配備のライフサイクルから複雑さと不確実性を排除します。当社は、高速かつ質の高い方法で、サーバーを作成および共有するための場所、または推奨されるパターンからサーバーを複製するための場所をご提供します。

InfoQ. Elastic Serverはどのように使用するのですか?

CohesiveFT: 仮に、Ruby on Rails用に記述されたアプリケーションがあって、ラップトップでテストビルドを実行するが稼動中のデータセンター - たとえばAmazon EC2に移動したいとします。問題ありません。Elastic Serverサイト(サイト・英語)で、それぞれ異なる技術コミュニティ(source)や製品パターン(source)に応じているポータルの集合(source)をご覧になれます。Ruby on Rails portal(source)を選択し、ベーススタックであなたが望むコンポーネントをカスタマイズしてください。たとえば、Rails 2.0.2、Mongrel 1.1.4、PostgreSQLライブラリ、RubyGemsなどです。そして、「ビルド」を押してください。それだけです - 数分でRailsサーバーを(source)上で動作させることができます。

選択をテンプレート(source)として保存できるため、同じ構成を再利用し、それを独自のハードウェア上で他の形式、現時点ではVMware(サイト・英語)、Parallels(サイト・英語)、またはXen(サイト・英語)で実行できます。これが、サーバーを「Elastic(弾性がある)」と呼んでいる理由です。あなたはサーバーレシピを1つしか持たないのですが、それを複数のビジネスケースや技術プラットフォームで再利用できる柔軟性を保持します。このあらゆる側面が1つの場所で、一貫した方法で管理されます。また、すべてのサーバーに、ネットワーク設定、セキュリティ、監査、ライフサイクルなどの保守機能を編成するためのWebコンソールとAPI(source)があります。

InfoQ. 仮想化されたサーバー環境の管理に内在する複雑さをどのように単純化しますか?

CohesiveFT: この例は重要なことを2、3示しています。第一に、Elastic Server On-Demandサービスは、他の誰かに引き受けてもらいたいであろう、増え続ける厄介で手間のかかる活動の制御および管理の単一ポイントを提供します。これらは、常に予測どおりに動作する1つのより単純なプロセスに置き換えられ、まさにお望みどおりの仮想サーバーを実現し、命令に応じて、瞬時に別の方法でサーバーをプロビジョニングするようになります。第二に、Elastic Server On-Demandは非常に柔軟なシステムです。つまり、ビジネスニーズに対応し、1回限りのことや特定分野の状況に限定されません。誰もが知っているとおり、自動化によってより優れた品質管理が実現しますが、柔軟性やユーザー選択が犠牲となることがあります。Elastic Serverは、あなたの選択肢を奪うことはありませんし、どんな仮想化やOSプラットフォームにもあなたを束縛することはありません。

Cohesive FT Community Portals基本的に、Elastic Server On-Demandは開発と運用の両方において重要となるコンテンツのカタログを作成、編成、および共有する(source)方法を示します。このコンテンツとは何でしょうか? ソフトウェア、コンポーネント、スタックです。それは、ファイルシステムとメタデータであり、どのサーバーも所定のユースケースで必要なとおりに実行できる言わば「魔法のファイル」です。Elastic Serverポータルを、ソフトウェアスタックのコンテンツマネジメントシステム(CMS)として考えることができます。どんなCMSでもそうですが、独自のコンテンツを作成して(source)、それを独自のポータルに編成すること(source)を可能にします。Shindig(サイト・英語)、SOAスタック(サイト・英語)、RabbitMQメッセージングスタック(サイト・英語)、Google App Engineツール(source),、LAMPスタック(サイト・英語)など、新しいポータルが絶えず作成されており、人々はコミュニティ(source)で独自のサーバーを構築および共有しています。

InfoQ. 製品はどのようにライセンスされていますか? 

CohesiveFT: 当社は加入契約に基づいてライセンスを提供します - Elastic Server On-Demandは主としてSaaSビジネスモデルです。中核となる「構築、保存、共有」機能を備えた無料のCommunityエディションを用意しています。プライベートワークスペースを許可してライフサイクルサポートとVM管理を提供する商用のPersonalエディションとTeamsエディションがあります。これらのライセンスは従量制のプロビジョニングに基づいています - したがって、あなたは自分の使用分に対してのみ代価を払うだけであり、いつも必要な容量を得ることができます。Enterpriseチームやクラウド全体における非常に大規模なプロビジョニングのために、当社はrunbookベースのアプローチを用意しています - ここでもやはり柔軟性を顧客に提供しています。

Community(コミュニティ)は私たちにとって非常に重要です。Communityとは、誰でも無料で当社のプラットフォームにアクセスできることを意味するのですが、共有することをお勧めします。あなたは、スタック「レシピ」を取得し、それらをキャプチャし、自動で仮想サーバーとしてそれらを複製し、サーバーをコミュニティと共有できます。また、独自のコンポーネントをロードできます(source)。商用エディションは、連携して仕事する人々をサポートします。機能には、ポータルオーサリングツール、セキュリティ、マルチユーザーアクセス制御、サーバーイメージの寿命の追跡が含まれます。それは開発、テスト、および運用チームのための情報を管理する1つの場所を持つということです。

また、オープンソースのソフトウェア(source)も用意しています。それについては、ここ(source)で説明しています。

InfoQ: 独自のスタックの定義と管理によってどのように顧客をサポートするか具体的に話していただけますか?

Elastic Server On-Demand System ConfigurationCohesiveFT 顧客は、新しいスタックを作成し、要求に応じてそれらの固有のコピーを作成し、それらを追跡する能力と、パッチなどの、経時的な変化を管理する能力が必要であると、私たちに言いました。そのため、人々が仮想化技術またはクラウドのどちらを使用しても、彼らは当社の「elasticな(弾性がある)」カスタマイズを利用してビジネス変化を管理およびサポートするでしょう。

しかし、私たちは「スタック」とは何であるのかも問います。皆、「スタック」や「LAMPスタック」(source)や「SASHスタック」(サイト・英語)について、まるでそれぞれが固有のエンティティを選出するかのように話します。スタックは設計パターンとオペレーティングシステムのビルドの組み合わせである、と私たちは思います。ソフトウェアのユースケースが存在するのと同じ数だけスタックも存在します。どんなビジネスにも独自のユースケースのセットがあり、それぞれカスタムアプリケーションスタックを必要とする場合があります。もちろん、任意の2つのスタックが「そっくりに見える」かもしれません - たとえば、Linux上でSpring、Hibernate、およびMySQLを使用する2つのスタックは全く似ている傾向があります。しかし、各スタックはビジネス使用に特定のものです。これを考慮すると、顧客が独自のコンポーネントをロードして独自のスタックを定義すること(source)で独自のユースケースを定義する能力というのが不可欠です。

スタックをキャプチャするというのは、そうしないとコンポーネントが変化した場合に見失ってしまう恐れのある情報を管理できるということを意味しています。初めはプロジェクト予算でスタックの定義に思考力と労力を投資して問題を解決できるかもしれませんが、後で忙しすぎて、適切に知識とコードを共有することによってこの仕事を強化できない可能性があります。こうした重要な情報の損失は、保守コストやロックインコストを時間の経過とともに上昇させ、新しい目的でコードを編集または再利用する能力を下降させる恐れがあります。そのために、Elastic Serverで知識を得ることで、その問題を解決します。

InfoQ: どのようにサーバー「レシピ」を配備するのですか?

CohesiveFT Server ManagementCohesiveFT: Elastic Serverでは、そのダウンロードの準備が行われる前に、各スタックに、IDと資格メタデータ(source)、アプリケーション、OS、ミドルウェア構成ファイル、そして、ネットワークアドレス、ファイアウォール、ログ記録などの設定用の管理ツール(source)が自動注入されます。手短に言えば、各サーバーは使用のために強化されます。

Elastic Server On-Demandサービスは、サーバーをダウンロード可能にしたり、それをステージングエリアに配備可能にしたりします - 場合によってはディスク共有やマウントされたSANキャッシュ、ことによるとVMwareやOpsware、または自動化されたテストプロセスの引継ぎのため、などです。または、ユーザーはそれをクラウドに自動配備して稼動を開始するようにサービスに伝えることができます。可能な限りこれは自動化されており、数分しかかかりません。実際に試して自分の目で確かめてください!(source)サーバーが稼働したら、そのインスタンス化を変更することも可能です。たとえば、XMLファイルでポートを変更することなどが可能です。これは次の3つの方法で実行できます。web adminツールを使用する方法、プログラムでweb APIを使用する方法、またはrootとしてSSHを使用する方法です。

InfoQ: 変更を管理する方法、または配備されたインスタンスを再プロビジョニングする方法はありますか?

CohesiveFT: 高度な変更管理のサポートは今後のエディションで導入されるでしょう。すべては、どのサーバーにも関連するすべての変更を追跡するために適した固有の識別子を含むマニフェストがあるという考えに基づいています。また、アドミニストレーション機能は、パッチの前提条件であるID認識です。

これはどのように機能するのでしょうか? 論理的に、当社のビルドシステムは巨大な非巡回依存(規則)グラフです。コンポーネントへの変更(ビルド入力)は、依存グラフに波及してサーバーに影響します(ビルド出力)。明らかに当社はこれを自動化し、将来的にはそれをユーザーへの警告に使用して、サーバーにパッチを適用できるようにするでしょう。 

再プロビジョニングは現在のところ単純ではありますが、今日の実ケースには十分なものです。多くの会社が高度なプロビジョニング、編成、ワークフロー、および管理システムを保持しており、当社はそれらとの統合を期待しています。明らかにこれは、データがスタックサーバーと密接に結合される場合におけるデータ移行にも適用されます。.

InfoQ: Elastic Server On-Demandはアーキテクチャの観点からどのような課題の解決に役立ちますか?

CohesiveFT: Elastic Server On-Demandは、コンスタントなシステム変更の存在下で、オンタイムに質の高い結果を実現するものです。仮想化とクラウドはアーキテクチャだけではなく(source)すべてを変えると私たちは考えます! それらは、私たちが現在把握しているよりもはるかに多くのライフ側面に影響を与えるでしょう。 

そうは言っても、言及すべきアーキテクチャ上のポイントがいくつかあります。1つ目は、クラウドに配備すること、または、今 - 今日 - 即座に仮想データセンターから値を取得することです。これらは問題です。私たちは、2者間および複数の仮想化形式における、労力を必要としない移植性を可能にします。それもまた問題です。 

2つ目に、技術的または製品アーキテクチャの観点から、Elastic Serverのビルドシステムの背後には、非常に幅広いクラスの資産に対する依存性管理に対処するための、深い技術が存在します。これは、現在あといくつのスタック、オペレーティングシステム、および仮想化技術が存在するのかを考えるときに重要です。

最後になりましたが、「アーキテクトは人でもある」ということを言う必要があります。彼らは、開発チームに十分な影響をもたらすことができるようにと、アーキテクトかつ技術専門家として名声を得ることができるように、ワークライフをより容易にするという願望を共有しています。Elastic Serverは、新しいスタック構成を試すにしても、エンタープライズデータセンターをプロビジョニングするにしても、より迅速に物事を成し遂げます。スタックに関する情報のやりとりと管理を集中化することによって、この製品はオーバーヘッドを排除します。Elastic Serverポータルを使用することで、応答時間の短縮や、変更品質の改善、スタックの品質管理コストの削減、分散したチーム間などでのプロジェクトリーダーと開発者とのより良いコミュニケーションにつながります。

原文はこちらです:     http://www.infoq.com/news/2008/04/elasticserver

この記事に星をつける

おすすめ度
スタイル

BT