実現可能なイノベーション: エラスティック・ソフトウェアの限界を高める

新しい概念や戦略では、使われる言葉もこれまでとは変化します。低コスト、高い柔軟性、クラウド化しやすいアーキテクチャーへの動きの中で、エラスティック性という概念がエンタープライズ IT のソリューションとして確立されています。この記事では、エラスティックなインメモリー・データ・グリッドである IBM WebSphere eXtreme Scale に見られる例を説明しながら、エラスティック性を具体的にどのように定義すればよいのか探っていきます。この記事は IBM WebSphere 開発者向け技術ジャーナルの記事です。

Robert Wisniewski, Technical Evangelist, IBM

Robert Wisniewski は、パフォーマンスとスケーラビリティーを専門とするソフトウェア・エンジニアです。彼は、EJB/JPA からオートノミック・コンピューティング、そしてベンチマーク設計に至る、あらゆる分野に焦点を当てて WebSphere Applications Server のパフォーマンスに 7 年間取り組んできました。現在、彼は技術エバンジェリストとして、顧客のシナリオでの経験と、現実世界での XTP ストラテジーの適用に再び焦点を当てています。



2012年 6月 28日

「実現可能なイノベーション」のシリーズでは、新しく登場した技術を開発者と実践者両方の観点から取り上げ、その技術の新たな情報を提供したり、その技術に関するトピックについて議論したりします。そのなかで最先端の IBM WebSphere 製品の紹介もします。

業界用語に実質的な意味を与える

このトピックに関するスキルを磨いてください

この記事は、皆さんのスキルを漸進的に磨いていくナレッジ・パスの一部となっています。「クラウド・コンピューティング: Infrastructure as a Service の紹介」を参照してください。

エンタープライズ・ソフトウェア業界に満ちあふれているものの 1 つが業界用語です。時によるとその多さに圧倒されてしまいますが、常に変わりつつあるビジネス問題を解決するためのソリューションやツールの特徴を言い表すために用いられる言葉を増やすためには、業界用語が必要になります。このような言葉を増やさない限り、新しい概念の多くは定着していきません。これまで私たちが極めて特別な意味をもたせようとしてきた 1 つの概念は、「エラスティック」という言葉を用いてエンタープライズ・ソリューションの特徴を言い表すものです。

あるソリューションに対して設定する目標について宣言する際に、「エラスティック性」の概念をついつい使ってしまいがちです。「エラスティック」という表現が使える最も単純な形としては、あるソリューションがシステムをオフラインにせずにリソースを追加または削除できさえすれば、そのソリューションはエラスティックと言えるかもしれません。しかし「エラスティック」という表現を使う基準をこれよりも高いレベルの有用なものにするために、「エラスティック」を具体的に定義するという、もっと意欲的なことを提案したいと思います。

システムまたはそのコンポーネント (私は日常的に IBM WebSphere eXtreme Scale を扱っているため、ここではソフトウェアを例に挙げます) が「エラスティック」であると言う場合、以下に挙げる具体的な 3 つの点で自由度があることを意味します。

では、これらに対し、業界用語とか中身のない概念といったレッテルを貼る前に、これらの概念に少し実質的な意味を与えさせてください。

それ相当の制限なしにスケーリングが可能である

エラスティックなシステムは、システムの可用性に大きな影響を与えることなくスケールアップやスケールダウンが可能である、という考えに大きな異論はないはずです。ただし私は、そのシステム自体は妥当なスケールアップ・シナリオに対して何ら実質的制約を課さない、という想定も必要だと考えています。つまり、インフラストラクチャー自体は、ほとんどあるいはまったくオーバーヘッドなく、システムを継続的に増強することや新しいリソースを利用することが可能となるように、設計されていなければならないということです。これには、真のリニアなスケーリングを実現できることも含まれています。

私達は、WebSphere eXtreme Scale という製品の中でのエラスティック性の概念に取り組むために、非常に大規模なグリッドが WebSphere eXtreme Scale のあらゆる側面に及ぼす影響を検討しました。それを見事に説明しているのが以下に挙げる例です。

  • 1 つ目の例では、グリッド・メンバーによって構成されるインフラストラクチャーのアーキテクチャーを小さな規模のコンポーネントに分けます。その規模は、コンポーネントの中で内部の問題を解決できる程度の大きさにします。何千台ものサーバーを 1 つのコアグループに詰め込む代わりに、カタログ・サービス (グリッドの構造を扱う管理プロセス) がメンバーを 20 のグループに分けます。そしてこれらの各グループは、IBM WebSphere Application Server に機能を提供していて実績のあるアルゴリズムである、ハートビート機能付きのメンバー表示アルゴリズムを実行します。この小さなグループの中から選ばれた「リーダー」がグループにおけるカタログ・サービスの状態を最新に保ちます。そのため、「リーダー」はグリッドの全メンバーの 1/20 のみと通信すればよいことになります。
  • もう 1 つの例では、クライアントからグリッド自体を操作します。カタログ・サービスのような単一の管理プロセスはボトルネックとならないか、という質問がよく出されます。カタログ・サービスを複製することやクラスタリングすることも可能ですが、それは単に冗長化を目的としたものです。実際には、1 つのカタログ・サービスにより、ほとんど無制限の数のクライアントの要求を処理することができます。なぜなら、これらのクライアントがカタログ・サービスを操作するのは、グリッドを立ち上げる時のみだからです。その操作の中で、カタログ・サービスはグリッドに関する情報を返します。この情報の中には、すべてのグリッド・パーティションの場所と、各グリッド・パーティションに関連付けられた鍵空間とを定義する、完全なルーティング・マップが含まれています。この操作の後、クライアントはパーティションを直接操作し、通常のトランザクション・プロセスの間にサブチャネル経由で行う操作により、このルーティング・テーブルを最新状態に保つ処理も行います。カタログ・サービスはこれらの処理から解放されると、グリッドに対してリソースの追加や削除が行われたときの、グリッドのバランスとメンバーの管理に集中します。

こうした方法により、私達は任意の大きな規模にまで効果的にグリッドをスケーリングすることができました。研究所内では、実際のパフォーマンスの差を特に感じることなく、1,500 のコンテナーで構成されるグリッドを実現しました。その後は時間が足りなくなり、それ以上スケーリングすることはできませんでしたが、このスケーリングには具体的な、それ相当の制限もありません。エラスティックなソリューションにすることを真剣に検討する際には、これは重要な要素です。

ただし、このことは、エラスティックなインフラストラクチャーをデプロイすれば、リソースが追加されたときに必ずアプリケーション全体でリニアなスケーリングが行われる、ということを意味するわけではないことを理解することが重要です。そのインフラストラクチャー内で実行されるロジックやビジネスに関して、またスケーラブルなエクストリーム・トランザクション処理の基本事項を採用するか否かに関して、考慮すべき事項は相変わらずあります。この点に関して言えば、エンタープライズ・アプリケーション自体もエラスティックな性質を持つ必要があります。しかしエラスティックなインフラストラクチャーは、そうした目標を効果的に実現するためのメカニズムとして機能する必要があります。

フォルト・トレランスを備え、自己修復が可能である

皆さんのソリューションは制限なくスケーリングできるものであるとデプロイ担当者が信頼できるようにするには、システムの規模拡大に伴って高い確率と頻度で発生しそうなイベントも許容する必要があります (例えば、保守や障害、ネットワークの障害や変更、等々によるノードの追加や消失など)。リソースが増えるのに伴い、障害が発生する可能性も高まるため、エラスティックなシステムは、こうした障害を予測可能かつ効率的な方法で克服できる必要がある一方、可能であれば、フォルト・トレランスを備えた状態に復帰できる必要があります。

WebSphere eXtreme Scale によるデータ・グリッドの例を続けると、何百、何千というコンテナー・プロセスで構成されるグリッドにまで規模が拡大するにつれ、これらのプロセスの 1 つが失われたり、保守が必要になったりする可能性が一層高まります。WebSphere eXtreme Scale や同様のインメモリー・データ・グリッド製品のコア・コンピタンスであるレプリケーション機能を利用することで、こうした事態によるイベントを許容することができます。それだけではなく、データの配置やマイグレーションの処理は WebSphere eXtreme Scale のクライアント API によって、ユーザーにはまったく処理が見えないようにブラック・ボックス化されているため、新しいレプリカは自動的に作成され、フォルト・トレランスも再び実現されます。

デプロイメントがより大規模かつ複雑なものになったときに、エラスティック性を真に有用なものにするためには、こうした概念もエラスティック性に追加する必要があります。

管理が単純である

エラスティックなインフラストラクチャーの意味を考える場合には、システムの管理と保守に関する特別な要求は些細な問題であるかもしれません。しかし、システムが大規模かつ複雑なものになったときにフォルト・トレランスの要件を考慮するのと同様に、一般的な管理タスクを実行するデプロイ担当者の能力を考慮する必要があります。

この場合に重要なことは、各ノードの構成と保守がまったく同じであるか、あるいはごくわずかの違いのみであるようにする必要がある、ということです。システムが動作するために必要な、メンバーのマシンやプロセスの全リストをデプロイ担当者が提供することを期待すべきではありません。システムの管理と保守には、一般的な構成成果物に基づく何らかのレベルの自動検出機能と自動管理機能が必要です。

WebSphere eXtreme Scale の場合、その方法は極めて単純明快です。構成情報では、特定のメンバー・プロセスの詳細に注目するのではなく、グリッド自体の構造と特性に注目します。構成する内容は、例えばデータをいくつのパーティションに分割するか、それらのパーティションをどのようにレプリケートするか、などです。この情報を基に、WebSphere eXtreme Scale は利用可能なグリッド・メンバーに構成内容をマッピングし、構成のなかで設定されているポリシーを施行します。各グリッド・メンバーが起動されると、まったく同じ構成成果物セットがそのメンバーに提供され、グリッドでのそのメンバーの場所の詳細が自動的に管理、判断されます。

この考え方が管理と保守のすべての側面に適用され、それぞれの操作は物理的なグリッドの詳細とグリッドの論理構造とを分離して行われるように設計されています。

こうした例は他にもたくさんあります。例えば、ゾーンの抽象化によってレプリカの配置を分離する機能、グリッド自体をオフラインにせずにグリッドの実際のコード・レベルをアップグレードできる機能などがあります。重要なのは、システムの規模が拡大しても管理タスクの複雑さを一定にする必要がある、あるいは少なくとも可能な限り一定に近づける必要がある、という考え方です。こうしたことから、エラスティック・ソフトウェアとエラスティック・ハードウェア (つまり仮想化とクラウド・デプロイメント) を適切に統合し、新しいレベルの自由度をエンタープライズ・ソリューションに実現する方法がわかるはずです。


業界用語を称賛する

コンピューティングの分野で最も普及している基本技術でさえ、最初は何らかの形の業界用語から出発している、と言ってもおそらく過言ではないでしょう。私たちが使用する言葉に対して、新しい概念セットや目標セットを追加する場合、私達はそれらの意味と有益な目的を何とかして定義する必要があります。このようにして、エンタープライズ・ソリューションのエラスティック性を明確に定義し、十分に検討して論理的な結論に達した時に、初めてエンタープライズ・ソリューションのエラスティック性が重要な概念になるのだということは、明らかなことだと思います。私達はこれまで、エラスティックなデータ・グリッドとしての WebSphere eXtreme Scale について語る際、具体的で役に立つ意味を関連付けるように常に努力してきました。そして今後も、真に柔軟なインフラストラクチャーの構築用に設計された他のソリューションに対し、これまでと同じように努力しながら、これらの概念を適用していくつもりです。

参考文献

学ぶために

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

議論するために

コメント

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=WebSphere, Web development
ArticleID=822575
ArticleTitle=実現可能なイノベーション: エラスティック・ソフトウェアの限界を高める
publish-date=06282012