BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース CloudBeesがHudson-as-a-Serviceを紹介

CloudBeesがHudson-as-a-Serviceを紹介

原文(投稿日:2010/09/07)へのリンク

CloudBeesは同社初のPaaSであるHaas(Husdon-as-a-Service)を紹介した。このサービスはクラウド環境に継続的統合とテストを導入する。クラウド内の柔軟なリソースを"必要に応じて"利用することで、プロジェクト構築に必要な作業量をより効率的に割り当てることができ、その結果、構築にかかる時間を削減できる。CloudBeesのHaaSは既存のGITやSVNのリポジトリと連携できる。また、プライベートで安全なSVNやGITやMavenのリポジトリも提供する。

HaaSの土台はCloudBeesのPaaSのインフラだ。彼ら自身が言うように、

私たちはクラウドは新しいプラットフォームだと考えます。時間とともにアプリケーションはクラウドへ移行するでしょうし、それとともにハードウエアやITのコストが下がるでしょう。しかし、この流れは一斉に起こるので、真のクラウドネイティブなインフラが欠かせません。

上記を考慮に入れて、彼らはPaaSが持つべきいくつかの性質を目標に設定した。

  • IaaSにとらわれない - 独自の透過的な方法を使って複数のベンダをサポートする。
  • オープン - オープンで標準的でフリー/オープンソースの技術やデータフォーマットを利用する。
  • 少ない抵抗 - アプリケーション開発を簡単にすること、開発に伴うすべてのオーバヘッドを削減することに注力する。これにはスケールの定期的な調整(スケールダウン、スケールアップ、スケールアウト)を含む。
  • 現実のアプリケーション - "現実の"アプリケーションのクラウドへの配置を邪魔する制限や限界を取り除く。

彼らの初期のHaaSは上記の性質を巧みに利用する。また、新しいサービスや機能を導入しながら、これらの性質もより強化する計画だ。

InfoQはCloudBeesのCEOであり創設者であるSacha Labourey氏に話を聞いた。氏はいくつかの追加の質問にも答えてくれた。

継続的統合という技術で会社を導くという方法を採用することはかなり大胆ですね。どうしてこの方法を採用したのですか。

CloudBeesの目的は開発から運用、メンテナンス、ステージング環境から品質保証まで、アプリケーションのライフサイクル全体を網羅するクラウドプラットフォームを提供することです。したがって、継続的統合という視点から事業を始めるのは道理にかないます。継続的統合はほとんどの開発チームが直面する困難(例えば、継続的統合作業に割り当てる容量がない)を本当に解決してくれるからであり、他方、現在の実行環境には何の影響も与えません。通常、現在の実行環境はより戦略的で長い時間が必要な意思決定が行われる領域です。

それゆえ、私たちはまず開発者に制約がほとんどない、アプリケーションの仕組みにとらわれないSaaSを提供することで、ITが抱える典型的な痛みを解消するつもりです。そして、私たちのPaaSをそこに構築します。私たちのがPaaSが準備できたら、顧客はCloudBees RUN@cloudを使って自分のアプリケーションを簡単にテストできるようになるでしょう。その結果、アプリケーションはすでにそこで構築されテストされたことになるので、私たちはそのアプリケーションがCloudBeesと互換性があるのかどうか自動的に判定することができます。

また、CloudBeesのHaaSは私たちのPaaSのサブシステム(プロビジョニングエンジンのような)を利用しています。それゆえ、私たちのSaaSは私たちのPaaSの最初の顧客になります。

サポートしようと思っている配置技術(例えば、NoSQL、リレーショナルデータベース、ウェブサーバなど)を教えてください。

JavaプラットフォームとJavaのリソースを分離して考えましょう。Javaのプラットフォームの上質なEE環境から提供される典型的なサービスはすべて提供するつもりです。しかし、特定の"ウェブサーバ"の仮想マシン、"アプリケーションサーバ"の仮想マシンを提供する考えはありません。私たちが提供するのはこれらのサービスを統合した、完全に仮想化されたJavaプラットフォームです。しかがって、利用者が特定のタイプのノードがどのくらい必要か定義する必要はありません。抵抗が極力すくないプラットフォームを目指します。それによって、利用者はITの典型的な課題をすべて操ることができるでしょう。拡張性(クラスタリング)、高可用性、透過的なアップグレードなどです。その結果、利用者は自分のアプリケーションのことに集中できます。その他のことは私たちが担当します。

マルチテナントのインフラ上でデータを守るためにどんな準備がありますか。

私たちの当初の実装はほとんどがプロセス分離(そしてユーザとプロセスの分離を保証する、OSの良く知られた手法)に基づきます。しかし現在、リソースを効率的に利用できるインプロセスのマルチテナントアーキテクチャも評価中です。この評価はこれからも繰り返し行う予定です。今はまだこの点がデータ保護にとってどの程度重要なのか評価している段階ですが、私たちの設計の中核部分であることは確かです。データのために私たちは最良の方法を求め続けますし、保存されるすべてのテナント固有のデータを暗号化したいと思っています。

定期的なスケールDUOについて詳しく教えてください。

私たちが"スケールDUO"(スケールの -Down, -Up, -Out)と呼ぶものは私たちのプラットフォームの能力であり、より細かいレベルでリソースを動的に確保することでその時点での負荷をさばくことができます。喩えで言えば、電力会社から提供される電力にとても似ています。装置をコンセントに接続したら過不足なく必要なだけ電力が得られ、利用した分だけ支払えば済みます。この喩えを使うと、現在のITの場合、何週間も前にプロバイダに対してどの装置でどのくらい電力が必要か教え、10,000単位で事前に購入しておく必要があるでしょう。よりアジャイルで重いITプロセスに依存しない開発環境を実現したいのなら、この喩えよりももっと優れた方法を実践しなければなりません。

サービスベースのHudsonから完全なクラウドベースの開発インフラへの企業の移行についてはどのようにお考えですか。この移行が利用する仮想マシンを簡単に提供するための大きな一歩であることは明らかです。

この移行が単一のステップが行われる必要はありません。企業はまず、最大の問題点から順々に除去する方法を探すでしょう。クラウドはこれらの問題を解決する最良の方法を提供するはずです。そして、開発プロセスの主要な部分がクラウドに移行したら、すべての開発を結ぶために企業が残りの部分をクラウドへ移行する移行するのは時間の問題でしょう。しかし、この移行は強制的に一回で行えません。何回かに分けて行われるはずです。何度も資産を壁の両側に分けながら行います。このためCloudBeesの提供する環境は完全に統合されている一方で、その各部分は独立して動作し、サードパーティのシステム(オンプレミスであれクラウドであれ)とも繋がります。

自動テストについてはどのようにサポートしたいとお考えですか。オンデマンドのSelenium Gridは、あなたのビジョンの中で描かれた運用の移行の実現にぴったりだと思いますし、このサービスに欠けている部分でもあると思うのですが。

そのとおりです。私たちが現在提供するサービスは、これから次々に提供する予定の新しいサービスのための素晴らしい基盤です。私たちには既にサービスの次のあるべき姿について具体的なアイディアがあります。そして、これから追加される新しいサービスのひとつひとつについて、自分たちで開発を行うのか外部と提携するのかを決めるつもりです。

CloudBeesを使うことであなた自身の開発プロセスがどのように改善されたか教えてください。

開発プロセスの全体がオンライン化しました。スクラッチから始めたので、まずGitHubを使い、CIが準備できたら使い始めました。あと少しで完全にクラウド化されたCloudBeesのステージング環境(HaaS、PaaSのプロビジョニング、請求と支払いなど)を見せれるところまで来ています。この環境はまっさらなAmazonのアカウントの中で、HaaSを利用してコードリポジトリから直接コードを取得して構築しました。私たちの企業は明らかにITが少ないです。自前でサーバを持っていません。エンジニアリングもビジネスも完全にSaaS(salesforce.com、Loopfuse、Zendesk、PagerDutyなど)に依存しています。

CloudBeesのHaasの提供についての詳しい情報と、彼らのリリース予定のPaaSの特徴についてはwww.cloudbees.comで確認できる。

この記事に星をつける

おすすめ度
スタイル

BT