[#Cloud #クラウド ] OpenStackの隠れた一面 = エコシステム•ロックイン

Open Stack Summitを数週間後に控えた状況の中、Open Stackのオープンソースに関する懸念がいくつかのレポートを通して表面化し始めている。

Gartner Research: Lydia Leong氏

ベンダーロックインの懸念を解消するためのオープンソフトウェアとしてのOpen Stackでありながらも、新たに、"エコシステム•ロックイン"と呼ばれる問題がOpen Stackの問題として登場している、と言う点を指摘している。合わせて、この問題を避けるために、3rd partyによるクラウド管理ツールやAPIライブラリの採用が必要である、と提言している。

同氏が書いたレポート、

"Don't let OpenStack hype distort your selection of a cloud management platform in 2012″ 

によると、元々、「オープンであり、広く採用する事が自由にできる標準」、という事で定義されているオープンソフトウェアとしてのOpen Stackは、実はかなり現実と離れている、と指摘している。

「Open Stackは複数のIT企業によって制定され、他に見られるような個人的な寄与によるオープンソフトウェアとは性格を異にしている。Open Stackの団体を構成している企業で、例えばRackspace社は、Amazon Web Service (AWS)を明確な競合相手である、と見ており、一社だけではAWSの独占的な市場成長を止める事が出来ない、と判断しているが故にOpen Stackという団体の運営を行っている、と言える。」

"OpenStack is dominated by commercial interests, as it is a business strategy for the vendors involved, not the effort of a community of altruistic individual contributors. Some of the participants, notably Rackspace and other service providers are afraid of the growing dominance of AWS in the cloud IaaS market and do not believe that they have the ability to muster, on their own, the engineering resources necessary to successfully compete with [Amazon Web Services] at scale, nor do they want to pay an ongoing license fee for a commercial [cloud management platform]  like VMware's vCloud stack."

こう述べた上で、この要件がある故、今後のクラウドデータセンタをデザインする上で、Open Stackをコアにしたアーキテクチャを目指してはいけない、と述べている。

一方、先行的に新技術を導入したり、まだ若いソースコードの品質を向上するためにエンジニアリソースを投入したい、という会社にとっては非常に適している技術である、と言及している。

このレポートはこのリンクにて無償で読む事が出来る。

もう一つ、Open Stackに対する懸念材料として、組織が業界の大手ベンダーによって構成されている、と言う点である。参加企業は、Rackspace, NASAからスタートして、IBM, HP, Cisco, Dell, SUSEそして最近ではVMWareが名を連ねている。

各社の共通の目的としてOpen StackをAWSに対抗できる技術として育てていこう、という意識がある点では良いが、それと同時に参加企業各社は明らかにIT業界の中で競合し合う企業である、という事実も認識する必要がある。

Open Stackの狙いとして、クラウドアーキテクチャの中Linuxの様な存在にしたい、という意見が多く登場しているが、果たして本当にこの競合状況の中でLinuxの様な統一規格が実現できるのか、それともUnixの様に各社各様、それぞれ異なる仕様をもったAPIになってしまうのか、という懸念が大きく残る。

最近のOpen Stack Foundationの動きは、Rackspaceが従来持っていたスターティングメンバーである権力状態から脱出し、影響力を少なくする方向に動いている事が顕著である。

新組織は、リーダーをSUSEのAlan Clark氏、Cisco VP/CTOであるLew Tucker氏を登用し、Rackspaceの幹部が退いている事が明らかになっている。また、"Network Connectivity as a Service"といった新機能を盛り込んでいる、Folsomというリリースも、Rackspaceの影響がかなり少なくなっている、という事が話題になっている。

個人的な所感としては、90年代前半に起きた、Unix標準化に向けてIT業界が大きく動いていた時代を思い出させる状況である。

当時は、Sun MicrosystemsがSolarisで絶対的な市場を確保する中、X/Openという業界団体が登場し、広く採用できるオープンなUnixのカーネルAPIを制定する動きに続いて、Open Software Foundation (OSF)と呼ばれるHP, DECを中心としたさらに大きな業界団体が産まれた時代である。結果として、OSFの存在価値が一定の評価を受ける中、実際には参画企業各社がそれぞれ独自の仕様を盛り込んだOSF準拠のUnix OSを開発する結果となり、メンバー間のUnixアプリケーションの互換性は十分に確保できなかったのが現実。細部まで仕様を標準化できない要因として、各社が製造するハードウェアに依存するAPIであるが故に、そもそも共通化できるカーネルのAPIの範疇が狭すぎたのでは、という意見も多く登場した時代である。

クラウドAPIも、下部レイヤーに存在するVMハイパーバイザ、ネットワーク仕様、CPU/ストレージ等のインタフェース等が少なからずも意識した仕様になるはずであり、各社Open Stack仕様を100%共通化しようと思っても無理な相談なのでは、と思うところである。

Apple iOSの様な下から上まで全部一社で統一した仕様がよいか、と言ったらそれはそれで問題がある事はわかるが。

Ippei Suzuki

e:  admin@ippeisuzuki.com

クラウド2.0、を考える

昨日は昔の会社時代の大先輩とロスのダウンタウンで食事をしました。クラウドコンピューティング関係のビジネスに取組むきっかけを4年前に頂いた方で、考えても見れば、その時から大変お世話になっています。
色々と情報交換をさせて頂く事を通して考えさせられる事がいくつかありました。

まず、クラウドの定義自体が日米で少しズレが起きている、という事。特にエンタプライズ系の市場ではクラウド＝アマゾン＝よそ者、という解釈が意外と広がっている、という点。クラウドと距離を置こう、という人口がまだ多い事が要因なのでしょうか。

もう一つは、オープンソフトウェアとクラウドとの関係がまだまだ理解されていない、という事。クラウド基盤を作るところまでは或る程度ベンダーはもう固まっているけど、その上のミドルウェアの市場（ID管理、セキュリティ、DR、DB、課金、等）はまだ混沌とした乱立市場。ここの整理をするのにオープンソフ

トウェアの市場が大きく台頭して来ているという現実を見るにあたり、オープンソフトに対する新しい取り組みが重要になって来てます。まだそれが見えている方が非常に少ない。

そして最後に、クラウド業界が大きく2分化している、という事。いわゆるエンタメ系のWeb2.0市場と、後を追って参入しているエンタプライズ系の市場では、客層、利用方法、主要ベンダー、全てに置いて２極化している、という事を体で知る、という事です。

先輩の言葉を借りると、クラウド2.0の時代、という事です。スピードの早いこの時代、これを理解する事によって、無駄な時間を浪費しない、効率のいい事業戦略が切望されており、それをサポートすべき自分の役割を改めて確信する、大変有意義な夜でした。

Amazon Web ServiceのCTO, Werner Vogel氏が見る、5年後のクラウド業界

GigaOmが主催するイベントにおいて、AWSが予測するクラウドコンピューティングの業界について、4つの予測を説明している。

折しも、5年前のこのイベントに同氏が初めて登壇し、EC2とS3について説明した経緯があり、その時点から現在に至るまで相当の進歩を遂げている中、今後それがどの様に発展するのか、興味深く読める記事である。

Vogel氏自身も5年前は今日のクラウドがこれだけビジネスに大きな影響を与える事になる、とは予測していなかったようだ。

ビデオの配信はここ：http://livestre.am/3YHSy

2017年には次の様な事が起きるだろう、と説明している。

1）AWSの価格はさらに下がる

今まで、AWSは価格を20回下げている実績がある。確かな事は、今後もこの傾向は続く、という事であり、市場に受け入れられるサービスの重要な要件として捕えている。

2）若いビジネスは今後もクラウドで成長する

Socialcam社、Pinterest社、Instagram社等はクラウドをベースにIT基盤を作り、急成長を遂げた会社の代表である。このような会社はどんどん増えていく、と予測する。これらの会社は、従来のハードベースのIT環境をもってあれだけの急成長を実現することが出来ただろうか？　まずあり得ない、と言えるだろう。そしてその傾向はますます強くなるものと考える。

3）企業のCIOは若いスタッフにチャンスを与える

ITソリューションの事になると、大企業のCIOはこういったクラウドをフルに活用した若い企業の手法に対して耳を傾ける様になるものと考える。5年前（現在）、CIOは大企業のセオリーにのみ頼っていたが、次第に大きな変化が起きるだろう、と見ている。

4）古いハードウェアベンダーは存続の機器に直面する

HPに代表される従来のハードウェア製造メーカは存続する為に大きな変革を遂げる必要がある。大きな鍵は「クラウドのマインドセット」を持つ事である。クラウドのマインドセット、とは、単に客に対してベンダーの姿勢を持つのではなく、パートナーとしての姿勢を持つ事から始まる、としている。そしてその最も大きな目的な客のITコストを下げる事にある。

AWSの姿勢は、顧客に対して110％の注目をする事、と主張している。競合のはげしいクラウド業界の中、他のベンダーと機能サポートの篠木愛をするのでは無く、顧客の求めている物をより早く提供する事が重要なビジネス要件である、と主張している。

[#Cloud #クラウド ] クラウド上でのHigh Availabilityを実現するための4つのステップ。いずれもクラウド運用のベストプラクティスとしては重要な要件だと思います。

Four Steps to Achieving High Availability in the Cloud by Brian Adler

クラウド上で可用性の高いアプリケーション環境を構築するのは一見、難しい作業の様に思えますが、重要なポイントは、クラウド上のコンポーネント全てに障害が起きうる、という事を認識しそれに対応した障害対策や自動化の対策を講じる、という意外と地味な作業を行う事です。

6月11～14日に予定している、RightScale User Conferenceにおいては、このHA (High Availability)とDR (Disaster Recovery)が重要なテーマとして様々なセッションが予定されています。多くの企業がこの課題に対して取組んでいる、という実情を反映している事からこのテーマを採用しているわけですが、RightScaleが取組んでいる "HA in the Cloud" に向けた4つのステップについて、下記の通り簡単に説明したいと思います。

1. Build for server failure 

サーバの障害は必ず起きるという前提でシステム構築をする

クラウド上のインスタンスは、データセンタにあるサーバと同様のレベルのサポートが必要です。特にサーバの障害に対する対応策の設計は大事です。サーバ障害への対処の第１ステップは任意のサーバ／サービスのリブートに影響を受けない様な環境で動かす事です。下記の点への着目が必要です。

• 自動スケーリングを設定し、様々なトラフィックの増減のパターンに対して対応出来る様な設計にする。
• データベースのミラー、マスター／スレーブ環境等を設定し、データの保全性を確保しダウンタイムを最小限に留める。
• ダイナミックDNSや、固定IPを利用し、アプリケーションが利用するインフラのコンポーネントが常に同期している事を保証する。

2. Build for zone failure

クラウドゾーンも必ず障害が起きる、という前提でシステムを構築する

サーバ単位で障害が発生するばかりではない。停電、ネットワーク障害、落雷による電力系統の障害、等さまざまである。こういった複数のサーバ群を対象とした障害に対する対処もアプリケーションとしては必要になってくる。AWSのAvailability Zoneの様に、こういた地域単位の障害に対する保全性、耐久性を確保したサーバ群の単位をゾーン（Zone）と呼び、複数のゾーンにまたがった次の様なアプリケーションの実装が必要になってきます。

• 少なくとも2つのゾーンに対してアプリケーションが稼働するサーバ群を配置する。
• ゾーン間でのデータの同期を行う。通常の範囲でのデータ同期は定額で行う方法がある。

3. Build for cloud failure

クラウド自体もも必ず障害が起きる、という前提でシステムを構築する

稀なケースで、一つの地域（リージョン）に配置される複数のゾーンが同時に障害を起こすケースもあります。2011年、4月に起きた、AWSのサービス障害がその一例です。ここでいう「リージョン」とは、個別のAPIをもつ独立したシステムリソースの事を指し、RightScaleが定義するクラウドの単位でもあります。

可用性（Availability）を限りなく100％に近くする為には、このリージョン（クラウド）単位での障害にも対応出来るためのプロセスを考慮する必要があります。しかし、クラウド間でシステムを構築する際にはいくつかの難しい課題に直面します。API、システム構成等、インタフェースの違い等がまず問題になり、これに対しては、アプリケーションとしては特定のクラウドAPIにとらわれない、汎用的なインターフェースを採用するコンセプトに基づいて構築される必要があります。

RightScaleの提供するクラウド管理システムはこういったクラウド間の違いを吸収し、開発者、システム運用管理者に対して、障害対応力に極めて強い、標準コンポーネントによって構成されるアプリケーション設計戦略を構築するのに大きな効果を発揮します。特定のベンダーが提供する複数のリージョン間にに搭載されるアプリケーションの実装ではなく、ベンダーにも限定されない複数のインフラ提供者にまたがった、次の様なアプリケーションの運用が非常に容易になります。

• データのバックアップを複数のリージョンやIaaSプロバイダ間で行う。プロバイダ間のデータの転送はインターネット上で行われるので、特にデータセキュリティの保全が重要になります。
• 障害時の補完用のインスタンスを別リージョン／クラウドに配置することにより、ゾーンやクラウド上の障害に対するキャパシティ設計を行う。
• いっぺんに大規模なクラウド間システムを構築するのでは無く、段階をもってシステムの障害対応戦略を拡張していく（複数ゾーン対応から複数クラウド対応へ）

4. Automate and test everything

全ての管理工数を自動化し、テストを行ってから実装する

システムの構成を順次サーバ障害、ゾーン障害、クラウド障害へ対応出来る様構築していくにつれ、障害に対する対策手順を自動化していく事が次のステップになります。クラウド管理ステムは、上記の様な複数サーバ、ゾーン、クラウドの単位それぞれに対して、障害対策手順を設計し、運用／管理出来る様な機能を提供します。障害時は大抵時間との戦いになるケースが多く、手順を自動化する事は非常に重要、且つ有効なソリューションになる事は自明で、次の様な対策が勧められる。

• 全てのステージに於けるデータのバックアップを自動化し、障害発生時にはデータの保全性を確保する様に設計します。
• 常に、システムを監視し、有事の際にアラートが発生する様にシステムをセットアップし、問題が発生した時にどこでどのような問題が起きたのかを迅速に検知出来る様な仕組みを構築する。クラウドプロバイダーからの連絡を待つ方法では、情報伝達が遅い上、精度に欠けるケースが多いのが現状です。（4月のAWS障害時はその問題がよく話題に上がっている）
• 障害対策プランは、実際にテストをする事によって初めて有効である、と判断出来る。クラウド上でのテストは従来のOn Premise上でのシステムと比較して非常に安くテストを行う事が可能になっている。特に過負荷テスト、障害のシミュレーション等は、RightScaleのコンソールを通して構造的な方法をもって行うことが出来ます。

クラウドのインフラは、DR(Disaster Recovery)やHA(High Availability)のシステム設計を非常に安く、そして確実に導入する事を可能にしている、という点は改めて評価する必要があります。最近、頻繁に発生しているクラウドサービスの障害のニュースが飛び交う中、クラウド上でMission Criticalな業務アプリケーションを何の問題も無く運用を継続し続ける会社も多いのも事実です。こういった会社はあまりニュースに登場していないだけだ、という現状を認識すべきであるが、多くの事が学べると考えます。

RightScaleの提唱するクラウドベストプラクティスと参照アーキテクチャについての上はこのリンクのWhite Paper on HA and DR Scenariosを是非ご参考にして下さい。

Brian Adler @ RightScale, Inc.

[#Cloud #クラウド ] マルチクラウド管理について: 大きく2つの領域に分離

[#Cloud #クラウド ] クラウドコンピューティングは一体どれだけ浸透しているのか？

[#Cloud #クラウド ] 1社のクラウドサービスで閉じたクラウド戦略であってはいけない理由

There's no need to be a one-cloud company

1社のクラウドサービスで閉じたクラウド戦略であってはいけない

By Mark Thiele, Switch Apr. 10, 2012, 9:00pm PT

昔からの言い伝えで、「全てを卵を一つのバスケットに入れてはいけない」という諺があります。イースターの祝日に良く行われる、イースタエッグの祝い事が毎年4月上旬に北米ではよく行われるが、きれいに色付けした卵を広場の所々に隠して、子供達が競ってそれをバスケットに入れて集める遊びである。この諺は、一つのバスケットに卵を全部入れてしまうと、万が一転んだ時に全部がいっぺんに割れてしまうので気をつけなさい、という意味である。

企業に於けるクラウド戦略を策定する際にも同じ様な論理が働く。

一社のクラウドサービス事業社に企業のIT資産を全て移行してしまうと、大きな失敗に繋がる可能性が高くなる、という事である。

ここで重要な事は、クラウドサービス事業社の立場としては、上記と全く異なる立場でお客さんに自社のサービスをプロモートする、という事を理解する必要がある。

実際、Joyent, Amazon, Rackspace, VMWare, HP, CloudSigma, 等のクラウドサービス事業社は、自社のSLAの強み、DRソリューション、セキュリティ対策、等自社のサービスが如何に堅強で安心してIT資産を預けられるかを具体的ににプロモートしている。企業間の競争というのはすばらしいもので、業界全体の質的な向上には非常に良い方向である、と言える。

問題は、リスク回避、という観点においては、どのクラウドサービス事業社も所詮、自社のデータセンタ内で閉じたソリューションしか提供していない、という事である。複数データセンタ間での多重化、バックアップ、プライベートクラウド連携によるハイブリッド化、等テーマは色々とあるが、クラウド事業社自体が重要障害を起こしたら全てが壊れてしまう、というリスクは依然残る。

最終的には、ユーザ自身が、クラウドサービス事業社に依存しないリスク回避の為の施策を考えて、実行に移す必要がある、という事を改めて認識する必要がある、というのが今後の最重要課題である、という事を主張したい、

実は、「一つのバスケットに全ての卵を入れる」、という行為自体は、えも言われぬ安心感を産む、という事も事実である。

何せ、問い合わせ窓口は一つだけだし、ベストプラクティス、当面に於いても専門家から統合的なコンサルを受ける事が出来るわけである。

このブログの筆者である、Mark Thiele氏は、Switchと呼ばれる、ラスベガスに拠点を置くjoyent

というデータセンターの運用を経営している会社のEVPである。

同氏は、FluidITというIT運用コンセプトを提唱しており、よりAgileで、より効率の良いITエコシステムを作る必要性を主張している。この中で、マルチクラウドを統合的に運用管理することによるリスク回避、地理的なカバレッジの拡大、アプリケーションの多様性、新規技術の早期導入、等の価値の大きさを特に重要している。

この記事でも同様のアプローチをしている。

幾つか、非常に興味深いポイントを述べる。

1）クラウド、特に複数のクラウドの運用はリスク回避を企業の責任として持つ際には不可避の選択になる。

2）マルチクラウドを効果的に運用、管理するコンポーネントの導入はその為に非常に重要な要件となる。

3）企業に於けるIT運用のガバナンスは、マルチクラウド管理のコンポーネントが持つべきである。各々のクラウドサービス事業社に企業のガバナンスするモデルは今後もどんなにクラウド事業社が成長してもあまり期待してはいけない。

もちろん、マルチクラウドを管理するインフラを導入せず、全て企業が各クラウドの運用管理を直接行う、という選択もある。マルチクラウド管理のコンセプトはまだ新しく、本当に信頼出来る技術ベンダーは誰なのか、選択するのもそう簡単ではない、という考え方もある。全て独自管理する手法を採用すると、それに伴う管理コスト、工数はそれ相当に大きくなる、という事は容易に想像出来る。場合によっては、クラウドを最初から採用しない方が安く済むのではないか、という考え方も出てくる。クラウドに投資出来ないで躊躇している企業や、SIはこの辺で大きく悩んでいるケースは良く聞く。

Thiele氏の例えを借りると、交通渋滞の中でフェラーリを運転している様なものである、と述べている。企業内のIT管理者は能力は高いが、その能力をマニュアルでマルチクラウドを取りまとめる事に注力してしまったら、実にもったいない、と言う事である。

まず、ユーザとして理解しなければいけないのは、マルチクラウド環境を構築する事によるメリットである。一般的には次の様な点が上げられる。

A)  負荷分散

B)  IaaSコストの最適化

C)  レイテンシー（Latency)の最適化

D)  クラウド業界での障害に対するDR

E)  クラウド間の資産の移動をビジネスプラクティスとして汎用化する

マルチクラウド運用は、さらにクラウド採用の最大の懸念要因である、セキュリティとプライバシーを解決する為のソリューションとして考慮する価値がある。各々のクラウドの運用状況を細かくモニターし、障害やそれ以外の要因でデータの保全性に影響する様な問題は早い段階で検知し、しかるべきデータの移動、複製、ロールバック、等の処置を自動化することが出来る機能は既に存在する。

これに限らず、クラウド上のアプリケーション業務の性能の確保、ロードバランス、自動プロビジョニング、等も同様の運用管理機能である。これらをIT管理者が常に複数のクラウド上を監視し、マニュアルの操作をするのではなく、マルチクラウド管理レイヤーがルールベースの自動化作業に置き換える事によって、IT管理業務をクラウドに移行しても、SLAを十分に確保することが出来る、という事が見える様になってくる、と期待する。またそうなると、クラウド、それもマルチクラウド運用も出るの採用に踏み切る為の判断材料を定量的に見積もることが出来る様になる、という事が期待される。