クラウドアーキテクチャパターン(via DoubleCloud.org)

調べ物をしていて、Cloud Architecture Patternsなるものに辿り着きました。

次の記事が、パターンに関する概要です。

別記事で、10個のパターンが解説されています。

ブログ記事ではありますが、アレグザンダーの『パターン・ランゲージ』や、それにインスパイアされて書かれた(いわゆる)パターン本の形式が、ほぼ踏襲されています。

  • Motivation: そのパターンを適用する前提や課題
  • Solution: Motivationに対する解決策
  • Applicability: パターンがどのように適用するか
  • Consequence: パターンを活用した結果
  • Known Uses: 利用例(AWSVMwareのサービス・製品名が登場します)
  • Related Patterns: 関連する他のパターンへのクロスリファレンス

読んでみると結構面白かったので、自分用にざっくりまとめてみました。

興味のある方は、元記事をどうぞ。表中のパターン名のリンク先が、元記事です。

Pattern Category Intentのテキトー訳
VM Factory Creational ユーザ要件に基づいて仮想マシンを新規に作成する標準的な方法を提供する
VM Pool Creational 仮想マシンを素早くプロビジョンする機構を提供し、仮想マシンのプールをメンテナンスすることでそれらのライフサイクルを管理する
VM Template Creational 新しい仮想マシンをテンプレートで供給することを標準化する
Aspectual Centralization Behavioral クラウドで異なる種類のサービスを活用することによる関心事の分離
Stateless VM Behavioral 仮想マシンが恒久的な状態を持たないことを保証して、クラウドでのプロビジョニング、マイグレーション、管理を容易にする
App VM Behavioral アプリケーションを稼働させるためのPaaS環境として、パッケージしたソフトウェアスタックを提供する
Service VM Behavioral クラウドコンピューティングのために、新規のインフラとアプリケーションサービスをプロビジョンする簡便な方法を提供する
Facade VM Structural 沢山の仮想マシンで構成される大規模システムに接続するためのシングルポイントを提供し、外からは1つの大きな仮想マシンに見せる
VM Pipeline Structural モジュール化された情報を処理するために、コンフィギュレーション可能な構造を提供する
Cloud Broker Structural 複数のクラウドサービスプロバイダーに接続して管理するためのシングルポイントを提供し、複数の外部クラウドを活用する恩恵を最大化する

以下では、3つのカテゴリごとに、そのカテゴリに属するパターンの詳細と、gdgd考えたことを書いています。

# といっても、自分にはインフラ実装が思いつかないパターンもあり、疑問メモに過ぎませんが。

Creational Patterns

自分の理解を図にしてみました。


VM Factory

仮想マシンを作成する方法は、3つあります。

  1. 仮想マシンイメージにOSをインストールして作る
  2. 既存の仮想マシンのクローンを作る
  3. 仮想マシンのテンプレートから作る

これらの実装を隠蔽するのが、VM Factoryパターンです。

パブリッククラウドを使うと、VM Factoryのメカニズムは最初から与えられています。しかし、プライベートクラウドやハイブリッドクラウドを使おうとすると、複数のFactoryが必要になります。

この場合、それらを統合的に扱うGeneral Factoryを定義するとベンリです。たとえば、SLAによって複数のパブリッククラウドを使い分けたいとき、そのポリシーをGeneral Factoryに実装できます。また、個々のクラウドサービスに支払う会計情報を、General Factoryでまとめることもできます。

VM Pool

VM Poolパターンは、図の下方にあたります。楕円は、利用可能な仮想マシンVM)のプールです。

システムで必要な時にプールからVMを取り出して使い、使い終わったらプールに返します。仮想マシンの取り出し(check out)には、FIFOやFILOなどのアルゴリズムを用います。また、プールに戻す前に、初期化スクリプトを実行するなどしてVMをクリーニングします。

VM Pool Managerというロールが、VMをcheck in/outしたり、プール内のVMに索引を付けたり、利用可能なVMを探したりします。

あらかじめプールしておくことで、仮想マシンのリードタイムを短縮できるという話ですね。

VM Template

VM Templateパターンは、VM Factoryパターンの実装の1つを取り出して、パターンと呼んでいるのだと思います。

PuppetやChefのようなツールを使って、テンプレートを統合的に管理することも含まれます。もしかすると、AWSのCloudFormationも該当するかもしれません。

テンプレートというと、VMware製品では(そのまま)テンプレート、AWSではAMIですね。

自分は、テンプレートやAMIといわれると、さまざまな種類・スペックの仮想マシンが、カタログのようにフラットに並んだ様子を想像します。しかし、本文では、テンプレートの階層構造という概念も紹介されています。どのようなテンプレートを作成し、管理するかという領域は、案外深いようです。

Behavioral Patterns

(理解できないパターンがあり、図が描けないので、ネコを挟んでおきます)

Aspectual Centralization

相の一元化、と訳すのでしょうか。Intentでは、関心事の分離に焦点があたっています。Aspectual Centralizationパターンは、データサービス、メッセージング、ロギングなどの「相」を、一元化されたサービスに抽出・委譲するパターンです。

それらを外に出すことで、開発者はビジネスロジックに集中できます。また、ITスタッフの専門性を高めることもできます。たとえば、このパターンを使うと、アプリケーションを動かすスタッフは、もうデータのバックアップを心配しなくて済みます。バックアップやメンテナンスは、一元化されたデータサービスを管理するスタッフの仕事になるためです。

「このアーキテクチャパターンが広く採用されるには、IT as a Serviceのパラダイムに転換せねばならないだろう」と、本文に書かれています。多様なクラウドサービスプロバイダが、それぞれデータストアを提供しています。企業は異なるアプリケーション間でデータストアを共有することはありますが、「common serviceとして使う」ことはない、と述べられています。

このパターンの実装が、まだイメージできません。たとえば、ロギング機構を、インスタンスやデータベース、ロードバランサーなど、対象を問わず統一的に提供するサービス(?)があれば、このパターンに当てはまるのでしょうか。

Stateless VM

Stateless VMパターンの良い例として、Amazon EC2が紹介されています。EC2インスタンスをパワーオフすると、ローカルのデータが保存されずに消えます。永続化するには、S3あるいはEBSを使用します。仮想マシンは、いわば「使い捨て」です。

仮想マシンがステートレスである利点に、次のことが挙げられています。

  • 仮想マシンの移動性が高まる。組織内でも外部のクラウド間でも、コピーするだけでOK。
    • ただ、これは仮想イメージの形式に互換性がないとムリだと思いますが…
  • インスタンスが壊れたら、新しく同じものを立ち上げて付け直すだけで良い。
  • 同じインスタンスを追加で立ち上げることで、手軽にスケールできる。
  • パッチを適用したインスタンスを作れば、アップデートがラク
App VM

App VMパターンとは、PaaSのことです。システムのデプロイ先として、ちょうどよいPaaSが見つからないときに検討すべきパターンとも書かれています。つまり、自分でPaaS環境を作れという話でしょう。

自分でVM上にPaaS環境を作ると、既存のサービスプロバイダーよりも、ずっと高い移植性を実現できます。ただし、このパターンの大きな課題は、プロビジョニングと管理を効率的に行うことだそうです。

Service VM

Service VMパターンでは、インフラレベルのサービスとアプリケーションレベルのサービスに、VMを分けます。

アプリケーションを動かすには、データサービス、ファイルシステム、メッセージングなどのインフラ機構が必要です。AppVMパターンではIaaSを使ってPaaS環境を構築しますが、それだけではaspectual centralizationではありませんでした。

インフラサービス用のVMを持つのは容易ではなく、次のことが必要だそうです。

  • オープンな規格に沿ってVMを扱えること(たとえば、ストレージVMならNFSiSCSIなど)
  • 可用性が高いVMであること
  • 多くの人が選びやすいように、VMにパッチを当てたりアップデートしたりすること
  • VMを効率的に管理すること

Structural Patterns

自分の理解を図にしてみました。


Facade VM

Facade VMパターンでは、仮想マシンは、フロントに位置するFacadeと、複数のBackendに分かれます。

一つ一つの仮想マシンにPublicなIPアドレスを付けると、コストがかかります。そこで、Facadeマシンにだけ、外から見えるIPアドレスを割り当てて、BackendのマシンにはプライベートIPアドレスを付与します。

Facadeマシンは、Backendのマシン群のヘルスチェックを行います。Backendのどれかが死んだら、新しいマシンを立ち上げます。

Backendにはスペックが異なるマシンを随時追加できます。Facadeよりもフロントにあるマシンは、Backendで何が起きているかを気にせずに、シームレスにスケールできるそうです。

VM Pipeline

元記事の説明が抽象的すぎて、何のこっちゃいなと思っていたら、最後に、「情報を処理するためにパイプラインを使うのは定番だが、仮想マシンに対してこの概念を持ち込んだ例をまだ読んだことがない。もし知っていればコメントで教えて欲しい」なんて書かれていました。これはひどい

VM Pipelineパターンは、仮想マシンを数珠つなぎにして処理を行うものです。処理には、次の2種類があります。

  • 前のマシンから次のマシンにデータを受け渡すデータフロー
  • 前のマシンのタスク完了後、次のマシンのタスクが開始されるコントロールフロー

マシンといっても、1台の仮想マシンインスタンスとは限らず、クラスタの場合もあるようです。まさにバッチですね。たとえば、Asakusa on EMRが実現すれば、このパターンにあたるのかなと思いました。

Cloud Broker

Cloud Brokerパターンは、夢が広がりまくりんぐです。

  • 複数のサービスプロバイダーを統合してシームレスに利用する。
  • 個々のサービスプロバイダーの価値を最大化する。
  • 必要なら、サービスプロバイダー間をまたがってスケールする。

・・・等といった考え方のようです。

じつは最初、Cloud Facrtoryと混同していました。Cloud FactoryはIaaSレベルですが、こちらはもっと広い範囲でのマルチベンダー活用なんですね。例として、AppirioのCloudWorksというソリューションが挙げられています(同じ名称の有名なAWSコンソールがありますが、別物です)。

名前が似ていますが、POSA本のBrokerパターンとは無関係だと思います。たぶん、きっと。

こんなところです。長くなりました。