目次


マイクロサービス・ベースのアーキテクチャーを Bluemix 内に実装する: 第 1 回 CF アプリを使用したビルドとデプロイ

アプリを複数のサービスに分割し、明確に定義された API を利用してサービス間の通信を行う

Comments

マイクロサービス・アーキテクチャーを使用すると、レジリエンシーとスケーラビリティーに優れたクラウド・アプリケーションを作成できるようになります。アプリケーションは複数のサービスに分割され、それらのサービス間では必要に応じて、明確に定義された API を利用して、通信が行われます。

このチュートリアル・シリーズでは、Cloud Foundry (CF) アプリと IBM Containers を使用して、マイクロサービス・ベースのアプリケーションを IBM Bluemix プラットフォーム内で実装する方法を紹介します。第 1 回でフォーカスするのは、CF アプリを使用して実装する方法です。

このシリーズのサンプル・アプリは、マイクロサービス・アーキテクチャー・パターンを使用して作成される、眼鏡のフレームを販売する単純な e-コマース・ストアです。サンプル・アプリはデモ用なので、本番品質のコードに相当するわけではありませんが、マイクロサービスについて探るための単純なコード・ベースを例示します。

サンプル・アプリを実行するコードを入手する

サンプル・アプリは、次の 2 つのマイクロサービスで構成されています。

  • cat: 製品カタログを管理します。
  • cart: ブラウザー・セッションごとの固有のショッピング・カートを管理します。

ショッピング用の Web ユーザー・インターフェースは、クライアント・ユーザー・インターフェースで管理します。現在のところ、配送、在庫管理、アカウント管理に対応するためのマイクロサービスはありません。これらのサービスを将来的に開発する場合、どのサービスもサンプル・アプリの実装手法に影響することなく開発できるはずです。

今回のチュートリアルでは、CF アプリを使用してマイクロサービス・ベースのショッピング・アプリを作成します。このシリーズの今後のチュートリアルでは、同じアプリを Bluemix の IBM Containers を使用して作成する方法を紹介します。

このチュートリアルに必要なソフトウェア

それぞれのマイクロサービスは Python で実装されており、Flask マイクロフレームワークを使用しています。Python と Flask を選んだ理由は、この 2 つには必要なビルドパックとイメージが備わっているためです。サーバーと UI のコードを git リポジトリーから取得して変更を加える場合は、Python と Node.js を使用すると便利です。

マイクロサービスの概要

アプリケーションのアーキテクチャーは、ユーザーの要求を満たすように進化しており、今ではクラウド・コンピューティングを利用するようになっています。ユーザーはタブレット、スマートフォン、ブラウザーのどれを使ってもアプリケーションを利用できることを求めています。そのような要求に応えるアプリケーションのユーザー・インターフェースは、タッチ操作にもキーボード/マウスでの操作にも対応しなければなりません。アプリケーションのアップデートは、従来のパッケージ・ソフトウェアの更新より頻繁にリリースされるため、デスクトップ・ブラウザー用の単純なモノリシックの Web アプリケーションを開発するのでは、もはや十分ではありません。

クラウド・ベースのアプリケーションには、分散型ソフトウェア・デザイン・パターンと、「System of Systems (複数システムで構成されるシステム)」の概念が適用されるようになっています。アプリケーションまたはサービスを一連の独立した構成部分 (「マイクロサービス)」として実装することを、「マイクロサービス・アーキテクチャー・パターン」と呼んでいます。それぞれのマイクロサービスは、スコープが制限されており、クライアントから使用できるように公開されている、明確に定義された API を必要に応じて利用してスケーリングできるように作られています。

開発者がマイクロサービス・アーキテクチャー・パターンを利用するメリットには、以下のものがあります。

  • アプリケーション・コンポーネント (マイクロサービス) のバージョンを管理して、それぞれのマイクロサービスを個別にデプロイすることができます。
  • 小規模なアジャイル・チームごとに異なる別個のマイクロサービスに取り組むことができます。
  • 継続的リリースという、DevOps の文化を適用して、アップグレードやマイクロサービスの A/B テストを進めることができます。
  • マイクロサービス・アーキテクチャーは本質的に API セントリックであり、疎結合ながらも凝集性が高いため、開発者は相互作用するコンポーネント間の契約の確立に重点的に取り組むことができます。

API ゲートウェイ: マイクロサービスの共通パターン

API ゲートウェイ・パターンは、マイクロサービス・アーキテクチャーの根本的な問題に対処するパターンです。その問題とは、マイクロサービス・ベースのアプリケーションで、クライアントはどのように個々のサービスにアクセスするかというものです。

例として、Amazon のような e-コマース・ストアにユーザー・エクスペリエンスを提供するモバイル・アプリを考えてみてください。このような e-コマース・ストアがマイクロサービスを使用して実装されているとします。この場合、モバイル・アプリが 1 つの製品ページを表示するには、以下のマイクロサービスのすべてと、やりとりしなければなりません。

  • 製品カタログ
  • 在庫
  • カスタマー・レビュー
  • ユーザー・アカウント
  • ショッピング・カート

各マイクロサービスが API エンドポイントを公開しているので、モバイル・アプリには、製品画面をレンダリングするだけでも複数のエンドポイントが必要になります。

この場合、マイクロサービスのリファクタリングが必要になったとしたら、どうなるでしょう?モバイル・クライアントは各マイクロサービスと直接やりとりするので、マイクロサービスの API を変更するたびに、モバイル・クライアントを更新しなければなりません。その結果、モバイル・クライアントを使用するすべてのデバイスに更新をプッシュする複雑さが増してきます。

このような複雑さに対処するのが、API ゲートウェイ・パターンです。このパターンでは、モバイル・クライアントに各マイクロサービスと直接やりとりさせるのではなく、API ゲートウェイを作成します。API ゲートウェイは、フロント・コントローラーという形で機能し、アプリケーションへの単一の論理エントリー・ポイントになります。

開発者とアーキテクトにとって、API ゲートウェイ・パターンは以下のメリットをもたらします。

  • クライアントに公開する論理 API を、各種マイクロサービスの物理実装とは切り離します。
  • すべてのクライアントに共通の単一エントリー・ポイントを提供します。クライアントは、API ゲートウェイのロケーションだけを知ればよく、実装されている個々のマイクロサービスのロケーションを知る必要はありません。
  • アーキテクトは、API を使用するクライアントのタイプに応じて、ロール固有の API を提供することができます。例えば、API ゲートウェイを使用して、すべてのクライアントがリソースを読み取れるようにする一方、認証用の適切な資格情報を持つクライアントだけに書き込み操作を制限することができます。
  • リクエストの調整を最適化して、リクエストの数を削減します。API ゲートウェイがコントローラーとして機能して、クライアントからリクエストされた情報を集約します。このような集約は、モバイル・クライアントにとって重要です。その理由は、インターネットを経由した各ラウンドトリップ・リクエストは、時間とバッテリー・パワーの点でコストがかかるためです。リクエストの調整は、クライアントが 1 つのリクエストを行うだけで済むことも意味します。

これらのメリットはほとんどの場合、別のサービスを実装してデプロイしなければならない複雑さを補って余りあるものとなります。すべての API がゲートウェイを介してルーティングされることから、このゲートウェイが通信のボトルネックになる可能性もありますが、API ゲートウェイのメリットは、そのような潜在的問題もしのぐほどの価値があります。

このサンプル・アプリでは、UI を API ゲートウェイとして使用し、UI に Web アプリケーションをレンダリングする役割と、アプリケーションのフロント・コントローラー (API ゲートウェイ) としての役割の両方を兼任させます。

この小さなサンプル・アプリには、これで問題ありませんが、実際の本番アプリケーションでは、この方法を使用しないでください。一般には、指定されたアプリケーションに対して複数のクライアントを開発します。例えば CLI クライアント、Web クライアント、モバイル・クライアントを開発する必要があります。API ゲートウェイを (単一の) ユーザー・インターフェースと結合すると、追加のクライアントを簡単に実装できなくなります。

マイクロサービスに CF アプリを使用する

このチュートリアルでは、cat マイクロサービスと cart マイクロサービスを Cloud Foundry アプリケーションとして実装します。UI クライアントも同じく Cloud Foundry アプリケーションとして実装します。マイクロサービス・ベースのアプリケーションに例外なく伴う根本的な問題は、サービス登録とサービス・ディスカバリーに対処する方法です。ここでは、Cloud Foundry マニフェスト・ファイルを使用して各マイクロサービスとそれぞれに関連付ける API エンドポイントを宣言します。

この方法には、実装が単純になり、別個のサービス・レジストリーを実装する必要がなくなるというメリットがあります。また、アプリケーションのソース・コードをパッケージ化とは切り離すこともできます。CF アプリのマイクロサービスと同じ cat ソース・コードを、IBM Container ベースのマイクロサービス環境にデプロイすることができ、コンテキストは環境変数を使用して渡されるため、サービス・レジストリーにアクセスする必要はありません。

一方、この方法の欠点は、完全に静的であることです。つまり、マイクロサービス・エンドポイントのいずれかが変更された場合、完全にデプロイし直さなければなりません。

それでは、このショッピング・アプリを Bluemix に実装してみましょう。IBM Bluemix のようなクラウド・プラットフォームは、不可欠となる高可用性と、水平スケーリング機能および垂直スケーリング機能を提供します。

ステップ 1. アプリケーションの構造を作成する

  1. アプリケーションのルート・ディレクトリー (shop) を作成します。
  2. マイクロサービスごとのサブディレクトリー (cat と cart) と UI (ui) のサブディレクトリーを作成します。 マイクロサービスごとのサブディレクトリー と UI のサブディレクトリーが作成されていることを示す画面のスクリーンショット
    マイクロサービスごとのサブディレクトリー と UI のサブディレクトリーが作成されていることを示す画面のスクリーンショット
  3. Bluemix にアクセスして、cat、cart、ui 用のアプリケーションを作成します。 cat、cart、ui 用のアプリケーションが作成されていることを示す Bluemix の画面のスクリーンショット
    cat、cart、ui 用のアプリケーションが作成されていることを示す Bluemix の画面のスクリーンショット

ステップ 2. マニフェスト・ファイルを作成する

単一のマニフェスト・ファイルによって、(cf push コマンドを使用して) すべてのマイクロサービスがデプロイされます。マニフェスト・ファイルは API エンドポイントを環境変数として各マイクロサービスに渡します。

マイクロサービスのデプロイメントを制御する CF manifest.yml ファイルを使用することで、必要に応じて追加の環境変数を渡すことができます。

リスト 1. Hello Node.js
---
disk_quota: 1024M
domain: mybluemix.net
instances: 1
memory: 128M
env:
  MONGODB_URI: mongodb://<user>:<pass>@ds061112.mongolab.com:61112/IbmCloud_381vomtk_ppokkvq4
  CART_ENTRYPOINT: http://davet-cart.mybluemix.net
  CAT_ENTRYPOINT: http://davet-cat.mybluemix.net
applications:
- name: davet-cat
  path: ./cat/src/
- name: davet-cart
  path: ./cart/src
- name: davet-shop
  path: ./ui/src

上記のマニフェスト・ファイルは、davet-cat、davet-cart、davet-shop という 3 つのアプリケーションを宣言します。ユーザー・インターフェースは davet-shop アプリケーションです。このマニフェストでは、cat および cart のエントリー・ポイント URL が、それぞれ環境変数 CAT_ENTRYPOINTCART_ENTRYPOINT で宣言されています。

製品情報を保管するために使用するのは、MongoDB データベースです。MongoLab サーバーを CF アプリに接続することもできますが、ここでは簡単のため、Mongo 接続ストリングを環境変数として渡します。

ステップ 3. デプロイメント・ファイルを追加する

中心となるマニフェスト・ファイルとは別に、各マイクロサービスのソース・コード・ディレクトリーには以下のファイルが含まれています。

  • Procfile: CF アプリを起動する際に実行するコマンドを指定するファイル
  • requirements.txt: Python ライブラリー要件を記述するファイル
  • runtime.txt: 使用する Python ランタイムのバージョンを指定する CF ステートメントが含まれるファイル

このサンプルの Cloud Foundry アプリケーションは、それぞれ Flask フレームワークを使用して Python で作成されています。requirements.txt ファイルに、許容される Flask のバージョンと必要なコンポーネントが指定されています。

Flask == 0.10.0
pymongo >= 3.0

(pymongo は、このサンプルで使用する Python 用の MongoDB データベース・ドライバーです。)

ステップ 4. マイクロサービスを実装する

cat、cart、ui アプリケーションのそれぞれを単純な Flask アプリケーションとして実装する方法については、このチュートリアルで取り上げません。詳細については、ソース・コードを参照してください。

マニフェスト・ファイルは、各マイクロサービスのエンドポイントを宣言します。マニフェストで宣言されているすべての CF アプリに、Bluemix は環境に関する情報を渡すので、この機能を利用してアプリケーションを起動します。例えば、以下のコード・スニペットによって、UI アプリケーションは cart マイクロサービスを見つけます。

CART_ENTRYPOINT = os.environ['CART_ENTRYPOINT'] if 'CART_ENTRYPOINT' in os.environ else ''

API ゲートウェイの一部の手法では、「すべての」トラフィックが API ゲートウェイにルーティングされます。これには、マイクロサービス間の通信も含まれます。この場合、API ゲートウェイは外部的にも内部的にもアプリケーションのリバース・プロキシーとして機能します。

この例では、直接アクセスできる API エンドポイントをすべてのマイクロサービスに対して公開するという方法を採っています。この方法には、マイクロサービス間のネットワーク・トラフィックが削減されるというメリットがあります。

まとめ

マイクロサービス・ベースのアプリケーションを作成するには、サービスの登録とディスカバリーに CF アプリのマニフェスト・ファイルを使用するのが簡単な手法ですが、その欠点は、サービス登録が比較的、静的な性質を持つようになることです。新しいマニフェスト・ファイルで cf push を実行するという方法は、負荷の重いクラウド・アプリケーションには拡張できない可能性があります。さらに、マニフェスト・ファイルによる登録手法を使用する場合、Red-Black デプロイや他の DevOps ベスト・プラクティスをサポートすることができません。

これらの問題を修正するには、IBM Containers を使用することができます。この場合、サービスの登録とディスカバリーが少し複雑になるという代償はありますが、最小限のダウンタイムでサービスの自動スケーリングと動的変更をサポートすることが可能になります。

このシリーズの次回のチュートリアルでは、IBM Containers を使用してマイクロサービス・アーキテクチャーを実装する方法を具体的に説明します。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1024832
ArticleTitle=マイクロサービス・ベースのアーキテクチャーを Bluemix 内に実装する: 第 1 回 CF アプリを使用したビルドとデプロイ
publish-date=01072016