マルチ クラウドは現実性のない夢なのでしょうか。いえ、そんなことはありません。
私たちが使用している計算能力、ネットワーク、ストレージ リソースの効率や価格性能比は年々向上していますが、それでもスタートアップはもちろん、規模の大きい企業にとってもインフラストラクチャはかなりの出費です。
しかも、インフラストラクチャには大きなリスクがあります、一つひとつの判断が、構築されるサービスの将来のスケーラビリティ、サービス レベル、柔軟性を大きく左右します。システム アーキテクトにとって、最も大きな懸案は “future-proofing”（将来の保証）だと言っても過言ではないでしょう。
インフラストラクチャを提供する側も、損得抜きでかかわっているわけではありません。どのベンダーにも、契約、価格、技術からの締め付けを通じて顧客をロックインしようという強いインセンティブがあります。
インフラストラクチャをすでに有している企業を中心に、多くの場面でクラウド インフラストラクチャに関心が集まるのは、提供される価値よりもロックインによるコストのほうが高くなってしまった既存のベンダーとの関係を断ち切りたいという強い思いからです。何らかの形でロックインの力が働き始めると、インフラストラクチャの提供企業は顧客に得をさせなくても使用料を上げていけることがわかっているのです。
では、インフラストラクチャを消費する側である皆さんは、最小限のコストで最大限の価値をプロバイダーから引き出すために、周囲からの圧力をどのようにさばいていけばよいのでしょうか。
最初の第一歩はロックインのメカニズムに積極的に抵抗することです。ほとんどのコンシューマー企業は今までの経験から、長期契約が危険なこと、そして先払い契約は意思決定を歪めることをよく知っています。
それでも、技術的なロックインを防ぐのは至難の業です。プロバイダーの多くは、差別化できる価値のあるサービスをプロプライエタリな API で包み込み、アプリケーションがいずれ自分たちの型にはまって抜け出せなくなるようにします。
こういった “sticky services”（厄介なサービス）や “loss leaders”（客寄せ商品）は、コンシューマー企業にとって、手っ取り早く価値を手に入れ、ロックインのリスクを受け入れる気にさせるものなのです。
これは、技術的負債のよくある形です。特に新しいベンダーが同じ分野でより強力で差別化されたツールをリリースしたり、OSS コミュニティからより優れたソリューションが生まれたりしたときに強く感じることです。
かつて、個々のプロバイダーのプロプライエタリな API の上に抽象化レイヤを構築し、1 つのツールで複数のクラウドを仲介することで、この技術的負債からコンシューマー企業を救おうとした会社がいくつかありました。しかし、この方法は脆く、ぐちゃぐちゃになりがちで、複数のクラウドの最大公約数的な形で妥協しがちです。また、顧客のロックインを維持するため、クラウド プロバイダーが戦略的に切り崩してくることもよくあります。
オープン アーキテクチャ
もっとも、テクノロジーはそんなものばかりではありません。不要なロックインのリスクを受け入れたり、最大公約数的なサービスに我慢したりしなくても、スケーラビリティが高く、高パフォーマンスでコスト効率の高いシステムを効率的に構築することは可能です。必要に応じてオープンな API で移行できることが前もってわかっていれば、プロプライエタリなインフラストラクチャ製品を使うことさえできます。
もちろん、「移行は複雑で高度な作業ではない」などと言うつもりはありません。複雑で高度な作業です。しかし、必要とされる時間と労力は日に日に大きく短縮、縮小されていきます。ユーザーはレバレッジを手にします。自由が広がれば広がるほど、プロパイダーをコモディティという本来の姿で扱えるようになっていきます。
私たち Google は、プロプライエタリな開発の価値を理解しています。私たちは、スケーラビリティ、パフォーマンス、セキュリティ、柔軟性が高くなるように意識してチューニングされたクラウド スタックを作ってきました。そして、宣伝、アプリケーション、クラウド ビジネスを通じて、この投資から本物の価値を引き出しています。しかし、Google Cloud Platform（GCP）とより広範な技術コミュニティの他プロバイダーやメンバーは、力を与えられたユーザーが、本当に強力なことができることを知っています。
私たちは、プロプライエタリで閉じた API に走らずに、パフォーマンスおよび安定性の高さとコストの低さから差別化されるサービスをお届けするよう努力してきました。もちろん、そうしたサービスの場合は、ユーザーは GCP を使うのを止めたくなったときに止めることができます。しかし、ユーザーにとってはそれこそが、GCP を使うリスクを軽減化するパワーになると、私たちは思うのです。
一部の優れた人々は、このアプローチを “GIFEE”（Google Infrastructure For Everyone Else）と呼び始めました。しかし、Kubernetes のケースに代表されるように、圧倒的な数の参加者と個人、そしてあらゆる規模の企業からの関連 OSS プロジェクトに対するソースコードのコントリビューションを考えると、“Everyone's Infrastructure, For Every Cloud”（すべての人々の、すべてのクラウドのためのインフラストラクチャ）と呼んだほうがおそらく正確でしょう。しかし、これでは頭文字を並べたときに、大変なことになってしまいます。
いくつか顕著な例を挙げておきましょう。
アプリケーションを実行するコンテナの管理システムとしては、Google が開発を支援した OSS の Kubernetes があります。Google Container Engine（GKE）または他プロバイダー、あるいはその両方で管理、ホスティングされています。
Kubernetes は、コンテナが決してロックインされないようにします。






ウェブ アプリケーションを実行する PaaS 環境としては、OSS アプリケーション管理フレームワークの AppScale があります。Google App Engine または他プロバイダー、あるいはその両方で管理、ホスティングされています。重要なのは、アプリケーションで必要な NoSQL トランザクション ストアもここに含まれることです。ストレージ レイヤとして Cassandra を使用するストアは、Google App Engine Datastore API をアプリケーションに提供する AppScale でも、App Engine ネイティブのものでもかまいません。
AppScale は、アプリケーションが決してロックインされないようにします。

NoSQL のキーバリュー ストアとしては、Bigtable ホワイトペーパーから生まれた Apache HBase があります。Cloud Bigtable または他プロバイダー、あるいはその両方で管理、ホスティングされています。
HBase は、NoSQL が決してロックインされないようにします。
OLAP システムのエンジンとしては、Google の Dremel システムからヒントを得た OSS OLAP エンジン、Druid と Drill があります。これらは BigQuery と非常によく似ており、あらゆるインフラストラクチャのもとで実行できます。
Druid と Drill は、OLAP システムが決してロックインされないようにします。



高度な RDBMS の構築には、Google が開発を支援した OSS MySQL ツールキットの Vitess が使用できます。Google Container Engine または他プロバイダーが Kubernetes を介して、あるいはその両方でホスティングされています。Google Cloud SQL を使用し、GCP 上でフルマネージドの MySQL を実行することも可能です。
Vitess は、RDBMS が決してロックインされないようにします。
データ オーケストレーションの実行には、Google が開発を支援した OSS ETL エンジン、Apache Beam が使用できます。Google Cloud Dataflow または他プロバイダー、あるいはその両方で管理、ホスティングされています。
Beam は、データ ETL が決してロックインされないようにします。

機械学習サービスの構築には、Google が開発を支援した OSS 機械学習ツール、TensorFlow が使用できます。Google Cloud Machine Learning または他プロバイダー、あるいはその両方で管理、ホスティングされています。
TensorFlow は、機械学習が決してロックインされないようにします。

オブジェクト ストレージの構築には、OSS を介して S3 API を提供する Minio.io が使用できます。同じく S3 API をエミュレートする Google Cloud Storage または他プロバイダー、もしくはその両方で管理、ホスティングされています。
Minio は、オブジェクト ストアが決してロックインされないようにします。

継続的デプロイ ツールとしては、Netflix と OSS のチームが発足させたプロジェクト Spinnaker が使用できます。GKE または他プロバイダー、あるいはその両方でホスティングされています。
Spinnaker は、継続的デプロイ ツールが決してロックインされないようにします。

まだプロプライエタリだが、たぶん大丈夫

CDN、DNS、ロード バランシング

これらのサービスに対するインターフェースはコードではなくネットワーク構成なので、今までのところ、これらはプロバイダー全体を通じてプロプライエタリなまま残っています。
NGINX と Varnish は素晴らしい OSS のロード バランサ / フロントエンド キャッシュを作りましたが、切り替えに伴う摩擦やリスクが低いことから、パブリック クラウドで DNS やロード バランシング サービスを避けようとする本格的ニーズはありません。本当に動的なことをしたい場合や自動化のためのコードを書く場合は、コードに対するオープンなインターフェースを確保するために Netflix の Denominator を使うことになるでしょう。

ファイル システム

ファイル システムは、クラウド プロバイダーが大規模なマネージド サービスとして提供するのがまだ難しい分野です。GlusterFS、Avere、ZFS などは、環境と関係なく専用の POSIX レイヤを提供するため本当に役に立ちます。もし Kubernetes の内部に構築するのであれば、CoreOS の Torus プロジェクトを参照するとよいでしょう。

ソフトウェアだけではない、本命はデータ

ロックインのリスクはさまざまな形をまとってやってきます。なかでも強力なのは、データの重さというか、慣性です。
すべてのソフトウェアがインフラストラクチャ間で簡単に移動できるようになっていても、それらのシステムはスループットが制限されたインターネットで接続されており、仮にペタバイトものデータが書き込まれたとしたら、それを移動するのは苦痛になるでしょう。ソフトウェアを 1 分で移動できても、データの移動に 1 か月かかるようなら意味はないのではないでしょうか。
GCP ネイティブのものや、拡大しつつあるパートナー エコシステムのものも含めて、そうしたデータの移動に有用なツールはたくさんあります。
  • データがオブジェクト ストアに格納されている場合は、Google Cloud Storage Transfer Service を使用できます。これは、Amazon から Google へのデータの移動に使用できる、簡単で身近な自動化ツールです。
  • データがテープやディスクに格納されている場合は、Offline Media Import / Export サービスを検討してみるとよいでしょう。Google クラウドとの間で大規模なデータを定期的に転送しなければならない場合は、キャリアや公開ピアリング ポイントを活用して確実に Google に接続できる Google Cloud Interconnect を検討してみてください。
  • クラウドにすばやく移動させたい VM イメージがある場合は、CloudEndure を使ってイメージを転送し、Google Compute Engine で実行できる形に変換することをお勧めします。
  • レプリケートが必要なデータベースがある場合は、Attunity CloudBeam を試してみてください。バルク データをマイグレートしたいのであれば、CERN の FDT を試してみましょう。
  • データをインポートするなら、おそらく Embulk が使えます。
まとめ
ロックインの罠に陥ることなく、システムの成長を支援するオープンな API とテクノロジーを選択したい。そんなときに本稿の内容がお役に立てば幸いです。
とはいえ、移行の自由を有していることを本当に証明できるのは実際の移行だということを覚えておいてください。実際に試してみましょう。多くのお客様が、私たち Google との交渉の場で、複数プロバイダー間でアプリケーションを間違いなく実行できたときに発見した、自分たちの中の新しい力について語ってくれています。
今回取り上げたツールとプロバイダーとを結ぶ強力なプライベート ネットワークを組み合わせれば、アプリケーションはプロバイダー固有の細かい差異を最小限に抑え、その垣根を越えていくでしょう。
本稿で説明したことに関する実装の方法、この種の考え方で使われるスタックの他の部分、あるいはどうやって始めたらよいかなどについてご質問があれば、こちらから Google Cloud Platform にどんどん送ってください。喜んでお手伝いさせていただきます。
- Posted by Miles Ward, Global Head of Solutions
ラベル: , , , ,

ラベル: , ,