目次


クラウド・アプリケーションのレシピ

3 ステップの階層型レシピ

Comments

この数年にわたり、ソフトウェア開発、アーキテクチャー、運用の各パターンの価値が広範囲にわたって検討されてきました。その例としては、The Open Group の TOGAF における「Architecture pattern」、Kyle Brown 氏のランタイム・パターンにおける「Patterns at all levels」などがあります。

この記事では、「レシピ」と呼ばれる新しいタイプのパターンについて説明します。レシピを利用することで、クラウドに移行または実装するアプリケーション候補を評価できます。候補となるアプリケーションは、クラウド内に限定して実行される場合もあれば、ハイブリッド・モデル内で実行されて、一部のコンポーネントが別のクラウド・プラットフォームや従来の環境内で実行される場合もあります。

アプリケーションを分析して IaaS または PaaS クラウド・プラットフォームにデプロイする最適な方法を判断するための時間と労力は、レシピによって節約できます。これから説明する基本的な構成要素を使用して各アプリケーションを評価することで、必要なコンポーネント、そしてアプリケーションをクラウドのシステムおよびサービスと対応させる最適な方法を定義することができます。さらに、レシピ固有エコシステムのサービスと汎用エコシステムのサービスという 2 つのサービス層を追加して、基本的なパターンを拡張することもできます。

レシピ

「レシピ」と呼ばれるコア・パターンは、一連のランタイムおよびサービスからどのようにアプリケーションやコンポーネントを組み立てるかについての洞察を提供するものです。レシピは、(特定のサービスを特定の組み合わせで利用することを示す) ボイラープレートではなく、一連の手順書として一般的なサービス・タイプを組み合わせる方法を示します。レシピと比べると、ボイラープレートはいわば冷凍ピザやインスタント・ラーメンのようなものです。

この記事で説明する一般的な 3 つのタイプのレシピには、それぞれに特定のサブタイプがあります。異なるタイプのレシピと、それぞれのタイプのレシピをサポートするサービス・タイプについて学ぶには、まず始めに、クラウド内で構築できるタイプのシステムに関する 3 つの概念を理解しておくことが重要です。なぜ重要であるかは、最初のレシピを定義する際にわかるでしょう。クラウド内で構築できるシステムには、以下のタイプがあります。

  • システム・オブ・レコード - システム・オブ・レコードとは、実際のオブジェクトやイベントに関する情報を記録するシステムのことです。アプリケーション内で、人、イベント、モノに関する複合データを永続ストアに保管するとしたら、それはおそらくシステム・オブ・レコードを構築していることになります。
  • システム・オブ・エンゲージメント - システム・オブ・エンゲージメントとは、他のシステムとやりとりするのではなく、主に人とやりとりするシステムのことです。アプリケーションが既存のデータにアクセスするように設計されている場合、または既存のデータに単純な変更を加えられるように設計されているだけの場合でも、それはおそらくシステム・オブ・エンゲージメントを構築していることになります。
  • システム・オブ・インサイト - システムのタイプのうち、システム・オブ・インサイトは最も理解するのが難しいでしょう。過去に関する質問に答えるためのシステム、または何らかの形で将来を予測しようとするシステムがある場合、それはシステム・オブ・インサイトを構築していることになるはずです。

以上の違いが重要となるわけは、これら 3 つのシステム・タイプのそれぞれに対応する、固有のランタイムとサービスの組み合わせがあるためです。別の言葉で言い換えると、タイプごとに固有のランタイムとサービスの組み合わせが、最初のステップでのレシピとなります。ただし、組み合わせは違っていても、すべてのレシピには中核となる材料一式があります。例えば、システム・オブ・レコードには通常、このシステムに固有の機能要件と非機能要件を満たすデータベースが必要です。バリエーションを加えられるのは、目の前にある特定の問題を解決するのにふさわしい追加の材料です。料理のレシピで言えば「好みの味付けをする」部分に相当します。

実際のところ、システム・オブ・レコードのレシピは最も単純なレシピです。developerWorks 上で説明されているものや、IBM Bluemix Garage を通じて私たちが構築したものなど、システム・オブ・レコードの数十の例を見て行った末、システム・オブ・レコードには以下のレシピがあることが判明しました。

システム・オブ・レコード = ランタイム + データ・ソース + (任意) ゲートウェイ

図 1. データ・ソースの例
データ・ソースの例の概要図
データ・ソースの例の概要図

レシピの内容

ランタイムは、IBM Bluemix 内で中心的役割を果たすコンポーネントです。それは Cloud Foundry インスタント・ランタイム (Liberty Buildpack など) または Docker Container を意味することもあれば、アプリケーション・コードをホストできる VM を意味することもあります。

データ・ソースは、次に重要なコンポーネントです。Bluemix 内では、SQL の選択肢 (DB2 as a Service、PostgreSQL by Compose サービスなど) からでも、NoSQL の選択肢 (IBM Cloudant、Redis by Compose など) からでも、任意のデータ・ソースを選ぶことができます。

ゲートウェイは、少々理解するのが難しいコンポーネントかもしれません。一部の (すべてではありません) システム・オブ・レコードは複数のタイプのデータ・ソースを必要としますが、それらのデータ・ソースの中には企業のファイアウォールによって保護されているものもあります。その場合、それらのデータ・ソースにアクセスするために、ゲートウェイに API Management などのサービスやセキュア・ゲートウェイを組み込むという方法を使うことができます。それと同様に、システム・オブ・レコードではフロントエンド・ゲートウェイを使用することもできます。ランタイムが非同期サービスとして構成されている場合には、他のシステムとの通信を可能にするために、メッセージ・ハブや IBM MQLight サービスなどのゲートウェイが必要になります。

システム・オブ・インサイトがシステム・オブ・レコードと共通している点は、データ・ソースです。データ・ソースが唯一の共通点であることも珍しくありません。システム・オブ・インサイトのレシピは以下のとおりです。

システム・オブ・インサイト = データ・ソース + (任意) 視覚化 + (任意) アナリティクス・ツール + (任意) データ移動

ここで新しく導入されている 2 つのタイプのサービスは、詳しく調べる価値があります。まず、アナリティクス・ツールは、特化されたデータ分析の実施を可能にするサービスです。このようなアナリティクス・ツールの例には、IBM BigInsights for Apache Hadoop、Apache Spark、さらには IBM DashDB もあります。視覚化は、ユーザーに分析結果を表示するために利用するサービスです。このタイプのサービスを利用することで、分析結果をテキスト形式で表示できます (例えば、Embeddable Reports サービスによるレポート)。あるいは、IOT Real-Time Insights のようなビジュアル・ツールを使用して結果を表示することもできます。システム・オブ・インサイトの最後のコンポーネントであるデータ移動は、さまざまなデータ・ソースの内外にデータを移動する場合に必要になります。そのようなデータ移動ツールとしては、IBM DataWorks があります。

システム・オブ・エンゲージメントでは、ランタイムを必ず使用し、多くの場合はゲートウェイも使用しますが、データ・ソースは必要になることもあれば、必要にならないこともあります。システム・オブ・エンゲージメントでローカルにデータをキャッシングするとしたら、キャッシュとしての役割を果たすデータ・ソースが必要になりますが、システム・オブ・エンゲージメントに永続的にデータを保管することは避けてください。それは、システム・オブ・レコードがやるべきことです。したがって、システム・オブ・エンゲージメントのレシピを単純にすると、以下のようなレシピになります。

システム・オブ・エンゲージメント = ランタイム + [キャッシュとしてのデータ・ソース] + [ゲートウェイ]

上記の例では、ほぼあらゆるものが選択項目になっているように見えます。もちろん、それではあまり役に立ちませんが、真の差別化は次の層で行います。この追加の層で、レシピ固有エコシステムのサービスを使用する、より具体的なレシピを考えることになります。

図 2. 論理上のレシピのタイプ
論理上のレシピのタイプの概要図
論理上のレシピのタイプの概要図

レシピ固有エコシステム

次の層は、「レシピ固有エコシステム」に属するサービスからなります。レシピ固有エコシステムには、1 つ以上の特定のレシピによって使用されるシステムやサービスがあります。テスト環境または本番環境内でアプリケーションを完全に機能させるためには、ベース・レシピによって使用されるシステムやサービスに加え、これらのシステムやサービスが必要となります。

多くの場合、必要となるコア・サービスとレシピ固有エコシステムからのサービスを決定できるよう、レシピには特定のサブタイプが用意されています。

システム・オブ・インタラクションは、Web システム・オブ・インタラクションとモバイル・システム・オブ・インタラクションという 2 つのサブタイプに分かれます。

  • Web システム・オブ・インタラクションでは、レシピ固有エコシステムのセッション・キャッシングシングル・サインオンなどのサービスを利用することになりそうです。
  • モバイル・システム・オブ・インタラクションでは、プッシュ通知モバイル品質保証およびモバイル・セキュリティーなどのレシピ固有のサービスを利用することが考えられます。

また、モノのインターネットのシステム・オブ・レコードが IoT ゲートウェイを介してメッセージを送受信する例もよく見掛けます。その場合は通常、システム・オブ・レコードによってデータ・ストアに保管される情報をユーザーが操作できるようにするために、システム・オブ・エンゲージメントが結合されます。

システム・オブ・インサイトについては、履歴システム・オブ・インサイトとリアルタイム・システム・オブ・インサイトに分類できます。

  • 履歴システム・オブ・インサイトでは、DashDB 内で利用できるテーブル・ピボッティングのような手法を使用します。
  • リアルタイム・システム・オブ・インサイトでは、ストリーミング・アナリティクスなどの手法や Apache Spark を利用できます。

この層に含まれるシステムやサービスは、2 つのグループに分けることができます。これらのグループ分けは、以下のようにシステムまたはサービスの目的に基づいています。

  • 運用の成功を実現するためのグループ: このグループには、モニタリング、ロード・バランシング、キャッシングなどのサービスが含まれます。例えば、Web システム・オブ・インタラクション (SOI) のレシピのためにクラウド・サービスを選択する際は、セッション・キャッシング、ロード・バランシング、または自動スケーリングなどのサービスが必要になるでしょう。
  • アプリケーションを操作するためのグループ: このグループには、機能要件としての操作をサポートすることを目的としたシステムおよびサービスが含まれます。アプリケーションの操作には、複数のプロトコル (SOAP、REST、JDBC など) を使用できます。これらのシステムやサービスは、環境 (開発、QA、本番) によって使用できるかどうかが異なり、場合によっては、公開された API や仮想サービスがこのグループに相当することもあります。

汎用エコシステム

最後に取り上げるサービスのタイプは、ソフトウェアの開発、デリバリー、リリース・ライフサイクルをサポートする、汎用エコシステムのサービスです。ハイブリッド環境、従来型の環境、あるいはメインフレーム環境にアプリケーションをデプロイする組織には、このエコシステムが、アプリケーション・デリバリー・ライフサイクルのさまざまな環境で使用できるシステムとサービスを提供します。例えば、Web アプリケーションを Bluemix のパブリック・クラウドにデプロイする場合、アプリケーションのパフォーマンスをテストするには BlazeMeter または LoadImpact を選択できます。Bluemix パブリック・クラウドにデプロイするクラウド・ネイティブのアプリケーションを開発しているとしたら、DevOps Services Delivery Pipeline を利用して、アプリケーションをさまざまなステージにビルドおよびデプロイできます。それとは対照的に、従来のオンプレミスと 1 つ以上のクラウド (IaaS、PaaS) プラットフォームにデプロイする、ハイブリッド・ワークフローを使用するアプリケーションを開発している場合は、UrbanCode Deploy を利用することで、クラウド・プラットフォーム内でのアプリケーションのデプロイメントとフルスタックのプロビジョニングに対応できます。

利用可能な機能について

この手法を使用する際は、使用するアプリケーションとパターンを特定するために、アプリケーションがクラウドに対応できるかどうかを判断する必要があります。その評価の際に従うのに適切なフレームワークは、このリンク先の記事で説明している「クラウド・アプリケーションにとって最も重要な 9 つのルール」(developerWorks、2014年4月) です。

また、利用するクラウド・プロバイダーまたは従来のプラットフォームの機能についても理解する必要があります。特に、提供されているサービスのうち、利用しようと考えているものについて十分に理解してください。多くのプロバイダーは、提供するサービスを紹介する Web サイトを用意しています。このリンク先の IBM のクラウド・サービスはその一例です。

ハイブリッド・モデルを採用し、複数のプラットフォームにわたってアプリケーションを運用することを目的としている場合は、プラットフォームを統合するために利用できる機能を把握してください。その好例は、API とハイブリッド・クラウドの統合です

クラウド・プロバイダーが提供するシステムまたはサービスを、他のプロバイダーが提供しているものや、オンプレミスでホストされているものと比較して評価してください。例えば、このリンク先のブログ「UrbanCode with Bluemix for Hybrid Cloud Deployment」では、ハイブリッド・プラットフォームと従来型プラットフォームのデリバリー・パイプラインに共通する機能について詳しく説明しています。

レシピを作り上げる

最善の方法は、アプリケーションごとに特定のレシピを適用してから、繰り返し利用できるエコシステムを調べて、アプリケーションを共通パターンに分類することです。以下のプロセスを繰り返し実行し、必要に応じて新しい要件やサービスだけを導入してください。

  • ステップ 1: レシピを組み立てます。ランタイムとサービスを試して、コアとなるレシピに適しているランタイムやサービスを判断します。
  • ステップ 2: レシピに固有の機能を実装するため、またはレシピに含まれるコア・コンポーネントの NFR を満たすために、レシピ固有エコシステムのサービスが必要になるかどうかを判断します。必要な場合は、レシピ固有エコシステムのサービスを追加します。
  • ステップ 3: 保全性、パフォーマンス、信頼性、セキュリティーの各分野でソリューションの NFR を満たすために、アプリケーションに汎用エコシステムのサービスが必要となるかどうかを判断します。必要な場合は、DevOps Services やセキュリティー・サービスなどの 1 つ以上の汎用エコシステムのサービスを追加します。

以下の図に、Bluemix のサンプル・レシピを示します。コア・レシピは Java ランタイム、Cloudant DB、Secure Gateway、そして追加のオンプレミス・データ・ソースと接続するための CUPS からなります。また、レシピ固有エコシステムと汎用エコシステムも DevOps オープン・ツール・チェーン、自動スケーリング・アナリティクス、メッセージ・ハブという形で含まれています。

図 3. Bluemix のサンプル・レシピ
トラフィックのフローを含む Bluemix のサンプル・レシピの概要図
トラフィックのフローを含む Bluemix のサンプル・レシピの概要図

まとめ

この記事では、IaaS または PaaS クラウド・プラットフォームへのアプリケーション移行を計画する際に利用できるアーキテクチャー・パターンについて説明しました。この 3 つのステップからなる階層型手法は、ランタイム・トポロジーとアプリケーションに必要なクラウド・サービスを明らかにする、コア・パターンとエコシステム・パターンを定義する手段となります。この手法を使用すれば、移行計画にかかる時間と労力を節約できるだけでなく、同様のレシピ・パターンを持つ複数のアプリケーションを移行する際の複雑さが軽減されます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Cloud computing
ArticleID=1039673
ArticleTitle=クラウド・アプリケーションのレシピ
publish-date=11172016