ホワイトペーパー

Pivotal Cloud Foundry で 稼働するマイクロサービスParag Doshi、Jared Ruckle、Peter Blum、Glenio Borges、Cornelius Mendoza

pivotal.io

ホワイトペーパー 2

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

はじめに .................................................................................................. 3

マイクロサービスを選ぶ理由 ......................................... 4

市場投入までの時間短縮 .................................................................... 4

拡張性 ............................................................................................................ 4

柔軟性 ............................................................................................................ 4

PCF <3 マイクロサービス ................................................... 5

PivotalCloudFoundry とマイクロサービスエコシステム .. 6

PCF で稼働するマイクロサービス ............................ 7

アーキテクチャ：ジョブに最適なツールを使う .................. 7

拡張性：スピードと自動ルーティング ...................................... 7

高可用性（HA）の 4つの層：プラットフォームの回復力 .. 7

セキュリティ：マイクロサービスへの認証対応の提供 ... 8

JWT と OAuth2....................................................................................... 8

リファレンスアーキテクチャ：コマンドクエリの責務分離 ............................................................... 9

開発：上位エンタープライズフレームワークへの対応 ...10

Java：SpringBoot が重要 ................................................................10

SpringCloudServices .........................................................................11

SpringCloudDataFlowでのクラウドネイティブデータ ...11

.NET アプリケーション：PCF の第一級市民に ....................12

PCF は .NET と .NETCore のフル機能に対応 .............................13

PCF の VisualStudio 統合により、.NET チームの CI/CD を加速 ............................................................13

大規模なWindowsServers をPCFRuntimeforWindows で管理 ................................................13

監視 /APMツール：新時代の新しいアプローチ ................13

ロギング：一元化された場所への容易なリアルタイムストリーミング .........................................................14

分散トレーシング：マイクロサービス間のインタラクションの把握 ..................................................................14

運用 ..........................................................................................................15

CI/CD ........................................................................................................15

ブルー /グリーンデプロイメント（ゼロダウンタイムデプロイメント） ...........................................16

メトリクス .............................................................................................17

まとめ.......................................................................................................18

推薦文献 ................................................................................................18

付録 A：同業者から学ぶ： トップ企業はどのように マイクロサービスを活用しているか ....................19

Citi ..................................................................................................................19

Comcast ......................................................................................................19

Allstate .........................................................................................................19

付録 B：マイクロサービスと企業文化 ..............20

組織：マイクロサービスのための態勢を整える ................20

文化：開発者と IT 運用者が共通の目標のもとに協働.....20

チーム構造 /構成 ..................................................................................21

ロール ..........................................................................................................21

付録 C：リファレンスアーキテクチャ ...............22

PivotalCloudFoundry® で稼働するアプリケーションとマイクロサービス ....................................22

リファレンスアーキテクチャのコンポーネント ................23

顧客志向銀行のサンプルアプリケーション ..........................24

サンプルアプリケーションのコンポーネント .....................25

目次

pivotal.io

ホワイトペーパー 3

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

はじめに今日、どんなソフトウェアカンファレンスに参加しても「マイクロサービス」という言葉を必ずと言って良いほど耳にします。マイクロサービスとは、企業の開発者間で支持を増しているソフトウェアアーキテクチャのアプローチのひとつです。

では、このアプローチはなぜこれほど注目されているのでしょうか？過去 20年間に中心的なソフトウェアパターンであったモノリシックなアプリケーションを考えてみましょう。

このシステムは逆説的で、今日のビジネスプロセスには不可欠でありながら、今後の要件対応には大きな障害となっています。ビジネスではスピードと俊敏性が要求されるのに対し、このようなシステムは処理速度が遅く、扱いが困難なのです。

一方、マイクロサービスでは、開発者はこのようなモノリス（一枚岩）を分割し、一度に1つのピースにして、複数の小さなコンポーネントにリプラットフォームすることができます。このアプローチによる開発は成功をみせつつあります。

たとえば、Java 開発者は、モノリシック・アーキテクチャを打破すべく、新しいオープンソースツール、SpringCloud（NetflixOSS を基盤とする）を採用しました。そして、実際に成功しつつあります。多くの大企業が、業界イベントで自社が新たに発見した俊敏性を誇らしげに大々的に宣伝し、マイクロサービスへの移行の促進にNetflix の技術がいかに役立ったかを紹介しています。.NET開発者は、同様のメリットを得るために、Steeltoe のようなツールを使用しています。

マイクロサービスとは？

マイクロサービスとは、単一目的のサービスの継続的デリバリーを優先順位付けするために個々のチームが用いる構造的なアプローチを意味します。では、この定義のキーワードを細かく見てみましょう。

• アーキテクチャ・アプローチ:マイクロサービスは言語ではありません。また、言語に依存もしていません。

• 独立したチーム : 組織構造が強調されており、マイクロサービスの導入に成功するには、組織変更が必要です。

• 継続的デリバリーを優先 :マイクロサービスは、個々に優先順位をつけることができ、ソフトウェアのデリバリーのスピードアップに役立つことが示唆されています。

• 単一目的のサービス : 特定のマイクロサービスのスケールを定義しています。マイクロサービスは 1つのことを適切に実行するものです。マイクロサービスの論点はサイズではなくスコープにあります。より小さなサービス（コード行数に関係なく）によって、より迅速に提供できるように支援します。さらに、マイクロサービスは、ビジネスニーズやサービスに対するユーザー負荷に応じて、個別にスケールできます。

マイクロサービスモデルは、従来のモノリシックなソフトウェアとは対極にあります。モノリシックなシステムは頻繁には出荷されず、単一ユニットとしてスケールされる、密結合されたモジュールで構成されています。モノリスは一部のシナリオでは適切に機能しますが、高い俊敏性や拡張性を必要とする企業は、マイクロサービスを使用しています。

継続的デリバリーと DevOps 文化が組み合わさった場合、マイクロサービス・アーキテクチャは、競合優位性をもたらします。このホワイトペーパーでは、企業の開発チームにとって、PivotalCloudFoundry がどのようにマイクロサービスをサポートしているかを検証します。

pivotal.io

ホワイトペーパー 4

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

マイクロサービスを選択する理由マイクロサービスは、市場投入までの時間短縮、スケーラビリティ、そして柔軟性という3つのメリットをもたらします。

市場投入までの時間短縮マイクロサービスは、ソフトウェアの小さなモジュールで、それぞれ独立して構築されます。そのため、開発チームはコードを迅速に市場にデリバーすることができます。エンジニアは、機能を反復処理し、自動化された継続的デリバリーパイプラインから機能を本番環境に漸進的にデリバーします。

スケーラビリティ一般的なWeb の規模では、本番環境で数百から数千のマイクロサービスが稼働しています。各サービスは独立してスケールできるため、柔軟性が極めて高くなります。保険会社を例に挙げてみましょう。

1か月間の保険受付期間中に、加入登録のためのマイクロサービスをスケールすることができます。同様に、加入登録済み会員からの電話数が増えることが予想される別の時期（保険対象年の第 1週）には、会員問合せのためのマイクロサービをスケールすることができます。このような拡張性は、収益増大と顧客基盤の拡大に有用であるため、企業にとって非常に魅力的です。

柔軟性マイクロサービスによって、開発者はシンプルな変更を容易に行うことができます。数百万行ものコードと格闘する必要もなくなります。

各マイクロサービスは小さく、また、マイクロサービスは API を介して通信するため、開発者は、適切なツール（プログラミング言語、データストアなど）を選択してサービスを向上させることができます。

では、開発者がセキュリティ認証のマイクロサービスをアップデートするとしましょう。開発者は、ドキュメントストアで認証データをホストすることを選択できます。このオプションにより、認証の追加や削除でリレーショナルデータベース以上の柔軟性が提供されます。

別の開発者が登録サービスを実行する場合は、バッキングストアにリレーショナルデータベースを選択すること可能です。新しいオープンソースオプションは、日々登場しています。マイクロサービスでは、開発者は、適当と思われる新しい技術を自由に活用することができるのです。

各サービスは小規模でそれぞれ独立しており、契約に従います。これは、開発者チームは、他のサービスに影響を与えることなく、また全サービスの本格的な開発をせずに、どのサービスでも書き直せることを意味します。

これは、迅速な行動の求められる時代にはとてつもなく重要な価値を提供します。

pivotal.io

ホワイトペーパー 5

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

PCF とマイクロサービスとの相性マイクロサービスは、企業の IT にスピード、俊敏性、柔軟性を提供します。ただし、よく言われるように、「何事も代償が必要」です。つまり、マイクロサービスは、複雑性ももたらします。

マイクロサービス・アーキテクチャを採用すると、ビジネス機能は多数の小さなコンポーネントに分散され、1つのモノリシックなアプリケーションではなく、数十個、時にはそれ以上の数のサービスを実装することになります。

ここで、ソフトウェアライフサイクル管理（開発、テスト、ユーザー受け入れテスト（UAT）、性能テスト、本番稼働）の部分ごとで異なる環境について考えてみましょう。それを理解しなければ環境全体であっという間に数百のマイクロサービスが稼働します。

この移行は、運用チームにとってストレスとなる可能性があります。運用チームは、このようなマイクロサービスを稼働させるために、数えきれないほど多くの仮想マシン（VM）をプロビジョニングし管理しなくてはならなくなるからです。監視はより複雑になり、IT 運用担当者は、このようなサービスを記録して開発者にログを提供する必要性が生じます。

従来のプロセスでこのような複雑性を管理するのは持続不可能と言ルため、PivotalCloudFoundry（PCF）の導入をおすすめしています。

マイクロサービスを PCF で稼働させるメリットは以下のとおりです。

1. PCF には、マイクロサービスを適切に実行させるために必要なあらゆる機能が含まれています。ログ、監視、スケールが実行され、さらに、このような機能は、プラットフォームの一部として「そのまま機能」します。さらに、インフラストラクチャ管理は抽象化されます。開発者は、このような基本的な機能について心配する必要がなくなります。このホワイトペーパーでは、以下のセクションでこのような多くの属性について説明します。

2. PCF は 、マイクロサービスに親和性の高いフレームワークをサポートします。多くのチームが、Java 開発のために SpringBoot と Springframework を使用しています。SpringBoot は、依存関係管理を容易にし、すべてのWebアプリケーションにWebコンテナ（Tomcat など）を埋め込み、「そのまま実行」する自己完結型アプリケーションを作成します。その結果、SpringBoot で開発されたアプリケーションは、まったく、またはほとんど修正せずに PCF で稼働することができます。

3. PCF は、マルチテナント環境をサポートします。マルチテナント環境により、開発者はソフトウェアライフサイクルのあらゆる側面（開発、テスト、ユーザー受け入れテスト（UAT）、性能、本番稼働）に対して、均一な環境を手にします。これによって、マイクロサービスが環境全体にわたって同様に動作することが分かります。

4. PCF プラットフォームは BOSH が管理します。BOSH は、リリースエンジニアリング、デプロイ、ライフサイクル管理のための「infrastructure-as-code」ツールチェーンです。これにより、IT 運用担当者は、オンプレミスでもパブリッククラウドでも、PCF インストレーションの管理で高い柔軟性と自律性が与えられます。

5. PCF は、マイクロサービスと統合可能なプラガブルサービスのエコシステムを提供します。このマーケットプレイスには、アプリケーション監視、統合ログ、多言語のデータベースおよび言語対応などのサービスがあります。また、Pivotal には、メトリクス、シングルサインオンおよびデータサービスのためのファーストパーティサービスも用意されています。

pivotal.io

ホワイトペーパー 6

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

Pivotal Cloud Foundry とマイクロサービスエコシステム以下のセクションでは、マイクロサービスの複雑性を最小限に抑えながらメリットを享受するために、PivotalCloudFoundry と関連コンポーネントがどのように役立つかをご紹介します。下の図 1は、以下の多くのトピックをまとめたものです。このホワイトペーパーの他のセクションを読む際に、この図を思い出してください。

図 1：マイクロサービス・アーキテクチャで使用される Pivotal Cloud Foundry および一般的なアドオンコンポーネントの概要

マイクロサービス

Hystrix サーキットブレーカー

Spring Cloud Stream

Eureka

Ribbon ロードバランサ

SpringBootアプリケーション

SpringBootアプリケーション

APIゲートウェイ

CS

E

CS

E

データベース

PCF Metrics

PivotalTracker

Concourse Git

Message Brokers

ログ解析

CloudController

SCS ServiceRegistryPCF UAA

PCFRouterブラウザ

モバイル

サービスバインディング

OAuth2

デプロイ/スケール

SSO

コードのプッシュ（Canary、Red/Black)

サービスバインディング

ログとメトリクス

サービス検出

IoT

分析的知見コードデリバリー

Spring Bootアプリケーション

Spring Bootアプリケーション

Spring Bootアプリケーション

Spring Bootアプリケーション

pivotal.io

ホワイトペーパー 7

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

PCF で稼働するマイクロサービスそれでは、マイクロサービスでは何が本当に重要なのでしょうか？ PCF はどのように役立つのでしょうか？このセクションで、このような質問（および他の質問にも）へお答えします。

アーキテクチャ：各ジョブに最適なツールを使う上記で述べたように（そしてこのセクションでさらに細かく説明しますが）、マイクロサービスは、モノリシックなアプリケーションよりも多くの異なるアーキテクチャに対応します。マイクロサービスは、サービス指向アーキテクチャ（SOA）で注目を集めた SOAP を基盤とするサービスに似ています。ただし、マイクロサービスは疎結合であり、厳格な XML ベースの約束事には従いません。ほとんどのマイクロサービスは、REST または ThriftAPI によって書かれています。このようなマイクロサービスは RESTAPI（HTTP トランスポートで稼働）を使用するため、どのような言語でも書くことができます。

言語とデータストアの選択の自由が、マイクロサービス導入の理由のひとつです。PCF は、複数の言語をサポートします（Java,.NET、Ruby、Go、Python など）。プラットフォームは、Oracle、MySQL、SQLServer のようなリレーショナルデータベールもサポートします。同様に、開発者は、MongoDB や Cassandra のような NoSQL ソリューションを自由に使用することができます。エンジニアには、どのような言語ででもマイクロサービスを書ける、また、どのバッキングストアでも使用できるという自由が与えられますが、PCF に対しては同様の方法プッシュできます。標準プラットフォームで業務を行うための適切なツールを選択する権利を開発者に与えてください。これは、IT 運用担当者にとっては容易なはずです。

拡張性：スピードと自動ルーティング当然のことながら、各マイクロサービスは個別にスケールする必要があります。拡張性には、考慮すべき 2つの側面があります。すなわち、すべての依存関係および環境設定と共に、サービスをいかに素早くスケールできるか、そして、いかに速く透明性をもってサービスを検出してユーザー負荷を共有できるか、という点です。

PCF は、これら両方の要件に余裕をもって応えられます。以下はその方法です。

• 迅速なスケール。PCF にサービスがプッシュされると、プラットフォームは不変アーティファクト、「Droplet」を作成します。このDroplet には、すべてのサービス群と、ランタイムでサービスが必要とする環境固有の依存関係が含まれます。サービスを水平にスケールする場合、プラットフォームはコンテナを作成し、コンテナにDroplet を置き、コンテナを開始します。これでサービスの使用準備ができます。そして、これらすべてが瞬時に行われるのです。

• 自動ルーティング。マイクロサービスは、ビジネスニーズに合わせてスケールアップもスケールダウンもできます。マイクロサービスのインスタンスは、特定の IP やポートにバインドされないため、静的にバインドされることはありません。そのため、サービスインスタンスは、他のサービスやアプリケーションに対して検出可能にする必要があります。

PCF はこの作業をあなたに代わって行います。プラットフォームは、サービスインスタンスのライフサイクルを管理します。サービスインスタンスをスケールアップすると、PCF は新しいインスタンスを開始し、Gorouter に登録して、アプリケーションルートにバインドします。サービスインスタンスをスケールダウンする場合は、PCF は不要なインスタンスを破棄し、Gorouter の登録を解除して、アプリケーションルートからバインドを解除します。これらすべてがユーザーに対して透過的に行われます。PCF は自動ルーティングの重量挙げ級作業をすべて行ってくれるのです。

高可用性（HA）の 4 つの層：プラットフォームの回復力モノリシックなアプリケーションは、本番環境では、少数のインスタンスしかないことがあります。1つのインスタンスがクラッシュすれば、それはすぐに分かります。オンラインへの復旧は通常手動で実施します。対照的に、マイクロサービスは、本番環境では多数のサービスが稼働しています。各マイクロサービスは、複数のインスタンスにスケールアップされ、マイクロサービスがクラッシュする可能性も増大します。そのため、IT 運用者にとって、手動で監視し、不具合のあるインスタンスに対応することはもはや現実的ではありません。

pivotal.io

ホワイトペーパー 8

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

PCF は、すべてのアプリケーションのインスタンスの望ましい状況と現状を常に監視することによって、高い回復力を提供します。マイクロサービスのインスタンスがクラッシュすると、現状は望ましい状況に適合しなくなります。この相違によって、PCF 内で自己回復プロセスが開始されます。

PCF は、自動的にコンテナを作成し、そのサービスにDroplet を配置します。これによって、PCF はインスタンスレベルで高い回復力を実現します。また、PCF は、異なる可用性ゾーンにわたってインスタンスを広げることによって、すべてのインスタンスの総合的な不具合も低減します。いずれかの可用性ゾーンで障害が発生した場合、他の可用性ゾーンのインスタンスがリクエストを引き続き処理して可用性を維持します。BOSH では、回復力の別の層が提供されます。これは、VMの健全性を監視します。VMの健全性が損なわれると、BOSH は、その VMを破棄して新しいVMを作成し、前の VMで稼働していたすべてのサービスインスタンスを再デプロイします。

セキュリティ：マイクロサービスへの認証サポートの提供マイクロサービスへの単一のリクエストが、複数のマイクロサービスの呼び出しのトリガとなる場合があります。ほとんどの企業では、システム内のマイクロサービスへ認証されていない呼び出しがないように、マイクロサービスのセキュリティを確保することを選択しています。

認可されていないアクセスを制限してマイクロサービスのセキュリティを確保するための一般的なメカニズムは数多くあります。PCF 内のこのようなメカニズムのひとつ、OAuth2 による JWT を見てみましょう。

JWT と OAuth2すべてのマイクロサービスは、簡単に認証をしたり、認証の判断を行う必要があります。PCF を使用する多くのお客様が、意図的に JWTと OAuth2 を選択しています。なぜでしょうか？

JSONWebToken はプロトコルに依存しない、HTTP 認証ヘッダーに渡される JSON ベースのトークンです。これは軽量で、ペイロードのサイズに影響しません。また、言語にも依存しません。

このオプションによって、開発者は、2つの質問に答える必要があります。どのフォーマットを使用するべきか、このようなマイクロサービスは JWTトークンをどのように取得するのか、というものです。

最初の質問は、JWT仕様書に答えがあります。

「JSONWebToken（JWT）は、2者間でやりとりされるコンパクトで URL-safeなクレームの表現方法である。JWT に含まれるクレームはJavaScript Object Notation（JSON）オブジェクトとしてエンコードされ、JSON Web Signature（JWS）構造のペイロードやJSON Web Encryption（JWE）構造のプレーンテキストとして利用される。JWS や JWE と共に用いることで、クレームに対してデジタル署名やMAC（メッセージ認証コード）の付与と暗号化による完全性保護の両方を行うことが可能となる。」

リクエストに有効な JWT トークンが含まれている場合、呼び出されたマイクロサービスは、リクエストの実行に進みます。

次に、このようなマイクロサービスはJWTトークンをどのように取得するのか、という質問です。OAuth2は、JWTトークンがマイクロサービスに渡される方法を定義します。

JWTトークンは、OAuth2/OpenIdConnectServer の実装によって作成されます。PCF の UAAServer は、このようなOAuth2 プロバイダの一例です。トークンは、HTTP リクエストと共に、「Authorization（認証）」HTTP ヘッダー属性に送られます。SpringSecurity のようなフレームワークによって、SpringBoot アプリケーションは、OAuth2 サーバーの実装と連携して JWTトークンを作成および認証を容易に行うことができます。

この機能の実装のための望ましい方法は、OAuth2 サーバーを使用して、JWT トークンを作成する個別のサービスを作成することです。すべてのマイクロサービスは、他のマイクロサービスを呼び出す前にこのトークン作成サービスを呼び出すことができます。

pivotal.io

ホワイトペーパー 9

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

PCF には、ユーザー提供サービス（UPS）と呼ばれる機能があります。この機能では、JWTトークン作成のようなカスタムサービスは、UPS として構成することができます。そして、JWTトークンを必要とするあらゆるマイクロサービスをこのUPSにバインドし、JWTトークンにアクセスするようにすることが可能です。これにより、すべてのマイクロサービスに、JWTトークンの取得と認可されていないアクセスからの保護のための標準的な手段が与えられます。

リファレンスアーキテクチャ：コマンドクエリの責務分離拡張性と信頼性をどのようにしたら実現できるのでしょうか？実例を見てみましょう。

図 2は、一般的なコマンドクエリの責務分離（CQRS）アプローチを示しています。これは、2つの異なる部分にシステムを分離します。CQRS は、書き込み（実行コマンド）に使用されるコンポーネントを、クエリ実行に使用されるコンポーネントから分離します。それによって、コマンドサービスとクエリサービスがそれぞれ独立したスケーラブルなサービスになります。これらのサービスは切り離され、個別に動作することができます。このアーキテクチャは、この付録で詳細に説明します。

ServiceRegistry SSO

MySQL

Subscribe to Events

Query DB

HTTP GETHTTP POST/PUT

OAuth2Discovery

Registraton

PublishEvents

ManageConfiguration

CreateRead

ViewsEventProcessor

CommandService

Edge Gateway

Event Store

QueryService

ConfigServer

図 2：Spring Cloud Services と Pivotal Cloud Foundry を実行するイベント駆動型クラウドネイティブアプリケーション

開発：上位エンタープライズフレームワークへの対応マイクロサービスは、どのようなプログラミング言語ででも実装可能です。開発者は、マイクロサービスをより迅速に構築して統合するために役立つツールを選択する傾向にあります。PCF では、開発者は、この新しいパターンに合わせて、精通している言語を選択することができます。ここでは、プラットフォームが 2つのポピュラーなエンタープライズフレームワーク、Java と .NET をどのようにサポートしているかを見ていきます。

pivotal.io

ホワイトペーパー 10

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

Java：Spring Boot が重要Spring は、Java 開発者の間で最もポピュラーなフレームワークですが、SpringBoot は、さらに一歩進んでいます。

SpringBoot では、本番に対応可能なスタンドアロンの Spring アプリケーションを簡単に作成して、「そのまま実行」することができます。Spring プラットフォームとサードパーティ製ライブラリを独自の主張に基づいて捉えることができます。その結果、開発者は、最小限の手間でアプリケーションの作成にとりかかることができます。SpringBootは、Java 開発者に多くのメリットをもたらします。

• Spring Boot では、依存関係管理を苦労せずに行うことができます。SpringBoot は、spring-boot-starter-* の依存関係を導入します。これにより、コンパイル /ランタイム時に必要なすべてのアプリケーション用 JAR ファイルが提供されます。

• Spring Boot は、一般的に登録されている Bean（DispatcherServlet、ResourceHandlers など）を自動構成します。開発者には、合理的なデフォルト値が提供されるため、同じ設定を何度も書く必要がありません。

• Spring Boot には、Web コンテナ（Tomcat など）が他のすべての Web アプリケーションと共に組み込まれています。開発者は、これらのアプリケーションを外部Webコンテナにデプロイする必要がありません。この手順は、開発者に代わって実行されます。

• Spring Boot は、自己完結型アプリケーションを迅速に作成します。アプリケーションは、Web リクエストやRESTful リクエストをすぐに処理できるようになります。

SpringBootアプリケーションは、PCFで「そのまま実行」されます。これには、以下のようないくつかの理由があります。第 1に、このアプリケーションは自己完結型で、すべての依存関係が実行可能な JAR ファイルにパッケージ化されています。第 2に、PCF は、環境プロパティを追加して、数秒以内にコンテナでアプリケーションを開始します。最後に、Tomcat、Jetty、Undertow が組み込まれているため、デプロイメントに関する多数の問題が解決されます。

これが、Spring 利用者がマイクロサービスに PCF を選択する理由です。

アプリケーションが本稼働すると、さらにメリットが得られます。

PCF の SpringBootActuator サポートにより、開発者は、本番環境にあるアプリケーションを監視し管理することができます（図 3および図 4）。集約されたロギング、動的ログレベルでの変更、そしてプラガブルサービスにより、開発者は、最小限のコード変更で、サービスを迅速に統合してテストすることができます。

pivotal.io

ホワイトペーパー 11

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

図 3：App Manager UI にアクチュエータの health エンドポイント詳細を統合

図 4：アプリケーションを再起動せずに、パッケージまたは個々のクラスレベルで動的にログレベルを構成

Spring Cloud Services開発者がアプリケーションを SpringCloudServices にバインドする際、Eureka のような NetflixOSS コンポーネント（サービスレジストリ）、Hystrix（サーキットブレーカー）、および ConfigServer（外部管理構成用）に、追加設定なく行うことができます。これら 3つは、マイクロサービスパターンにおいてすべて最高のものです。これらの詳細については、ホワイトペーパー『StandingontheShouldersofGiants:SuperchargingYourMicroservicesWithNetflixOSSandSpringCloud（巨人の肩の上に立つ：NetflixOSS と SpringCloud によるマイクロサービスの強化）』を参照してください。

Spring Cloud Data Flow でのクラウドネイティブデータデータマイクロサービスには、PCF と SpringCloudDataFlow（SCDF）を使用します。SCDF により、データ統合とリアルタイムデータ処理パイプラインを構築することができます。

パイプラインは、図 5に示すように、SpringCloudStreamまたは SpringCloudTask マイクロサービフレームワークで構築された SpringBoot アプリケーションから構成されます。下の図は、メッセージングブローカに RabbitMQを使用しており、エンジン自体はブローカに依存せず、Kafka などの他のシステムをサポートします。

pivotal.io

ホワイトペーパー 12

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

Pivotal Cloud Foundry®

Spring CloudData Flow

SpringBootアプリケーション

コントラクト

HTTP

RabbitMQ

サンプルパイプライン

JSONフィルタ

デプロイ

変換 濃縮

カスタム

SpringBootアプリケーションコントラクト

SpringBootアプリケーションコントラクト

SpringBootアプリケーションコントラクト

図 5：Spring Cloud Data Flow による一般的なデータマイクロサービスパイプライン

これらすべてによって、SpringCloudDataFlow は、インポート /エクスポート、イベントストリーミング、予測解析といった、さまざまなデータ処理のユースケースに最適なものとなっています。SpringCloudDataFlow サーバーは SpringCloudDeployer を使用して、パイプラインを最新のランタイム（PivotalCloudFoundry など）にデプロイします。

また、SpringCloudDataFlow では、PCF でストリーミングおよびバッチデータパイプラインとして稼働しているデータマイクロサービスのさまざまなパターンおよびベストプラクティスが用意されています。PCF によって、開発者は、データマイクロサービスを分離して作成、ユニットテスト、トラブルシューティング、管理することができます。そのため、開発者は、DSL、Shell、REST-API、Dashboard、Flo を使用するデータマイクロサービスを構築することができます。ここから、開発者は、PCF で稼働している他のすべてのアプリケーションと同様に、データマイクロサービスでブルー /グリーンデプロイメントを実行することができます。

SpringCloudDataFlow マイクロサービスは SpringBoot アプリケーションとして実装されるため、PCF のすべてのメリット（メトリクス、ロギング、ヘルスチェック、リモート管理）をデータマイクロサービスレベルで得られます。

.NET アプリケーション：PCF の第一級市民にPCF は、Java チームと同じ理由で .NET 開発者にも多く使用されています。

PCF は、新しいアプリケーションを迅速に構築およびデプロイすることで、開発者が新しい体験を顧客にスピーディに提供できるように支援します。エンジニアは、コード開発に集中し、複雑な運用の大部分をプラットフォームへ委ねることができます。

PCF により、.NET 開発者は、アプリケーションやマイクロサービスを、シンプルな cf pushコマンドでプッシュすることができます。

pivotal.io

ホワイトペーパー 13

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

PCF は .NET と .NET Core のフル機能に対応.NET アプリケーションの未来の姿が明らかになりつつあります。

今日既存のほとんどの.NETWebアプリケーションは、C#で書かれ、IIS上で稼働し、WindowsServerに支えられてます。一方、Microsoft は、開発者に対し、最新のマイクロサービスを .NETCore で構築するよう奨励しています。

これは良いニュースです。PCF は .NET フレームワーク（HostedWebCore ビルドパックを活用）と .NETCore で書かれたマイクロサービスをサポートしているためです。これは、.NET チームに最大限の柔軟性と実用性を提供します。

Pivotal では、新しいマイクロサービスを .NETCore フレームワークで作成すること、そして、そのサービスには .NETCore ランタイムまたは .NETFramework のいずれかをターゲットとすることをお勧めしています。このアドバイスに従えば、Linux またはWindows 環境にデプロイすることが可能です。

いずれの場合でも、.NETアプリケーションをPCFにプッシュする時に、このホワイトペーパーで述べたプラットフォームのすべてのメリットをご体験いただけることでしょう。また、Steeltoe への対応により、.NET マイクロサービスは、SpringCloudServices と統合されます。開発者は、アプリケーションを 3つの NetflixOSS、つまり、ureka、Hystrixおよび ConfigServer にバインドすることができます。

PCF の Visual Studio 統合により、.NET チームの CI/CD を加速Microsoft と Pivotal が連携して、VisualStudioTeamServices/TeamFoundationServer および PCF 間のシームレスな統合を構築しました。既存の CI/CD パイプラインを PCF と統合するには、Microsoft の CloudFoundry プラグインをご使用ください。CI/CD パイプライン経由でのブルー /グリーンデプロイメントが、数分で開発できます。また、サーバーの追加やネットワークのサポートなしにテストすることも可能です！

大規模な Windows Servers を PCF Runtime for Windows で管理PCF は、BOSH マネージドWindowsServer もサポートしています。この機能、PCFRuntimeforWindows は、.NETマイクロサービスの回復力を高めてくれます。さらに、Windowsの管理者は、「不変インフラストラクチャ」原則に従って、サーバーフリートを稼働させる新しい方法を手に入れます。

監視 /APM ツール：新時代の新しいアプローチアプリケーション性能監視（APM）ツールは、従来型のエージェントベースのシステムです。

言語固有の監視エージェントを、Webサーバーとアプリケーションサーバーにインストールします。アプリケーションがこれらのサーバーで稼働するとき、エージェントはコードをインストルメント化し、性能データを監視サーバーに送り返します。そして、性能の問題点や使用動向の診断には、監視クライアントとWeb ベースのダッシュボードが使用されます。このコンセプトは、既知のサーバー（別名「pets」）にデプロイされている数個のモノリスアプリケーションで管理可能です。多くの場合、監視専門家チームは、これらのエージェントのインストレーションと管理を任されています。このチームはシステム管理者と連携して、エージェントを各サーバーに手動でインストールします。監視は、この専門家チームの役割となり、開発者は、アプリケーションの構成と監視からさらに解放されていきます。

これは、マイクロサービスの世界ではなぜ機能しないのでしょうか？

マイクロサービス・アーキテクチャでは、数えきれないほどのサービスインスタンスが異なる VMのコンテナ内で稼働しています。また、SpringBoot のような技術は、アプリケーション JAR ファイルと共にWebサーバーとバンドルされているため、外部Webサーバーが不要です。この環境では、エージェントの事前インストールは機能しません。

PCF は、この問題を、APMエージェントバイナリをアプリケーションのビルドパックの一部としてバンドルすることで解決しました。エージェント（またはランタイムバイナリ）は、Droplet の一部になります。アプリケーションの起動時、そして環境変数をAPMプロパティで構成する時、PCFは、エージェントプロセスを実行し、パフォーマンスデー

pivotal.io

ホワイトペーパー 14

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

タを APMサーバーに送信します。この方法によって、PCF は、エージェントバイナリのインストールを透過的に処理します。また、これにより、手動でのエージェントのインストレーションタスクと、エージェントを管理する専門家チームの必要性がなくなります。

PCF は、Dynatrace や NewRelic のような APMツールをサポートします。APMツールは、オンプレミスにインストールしたり、または SaaS モデル内で使用したりすることができます。

ロギング：一元化された場所への容易なリアルタイムストリーミング従来のロギングは、IT 運用担当者がサーバーに 1台ずつ手動でアクセスして開発者にログファイルを提供する方法に頼っています。この手間のかかるプロセスは、問題の選別とトラブルシューティングを長引かせます。マイクロサービスでは、この問題がさらに深刻化します。数多くのサービスインスタンスがコンテナで稼働し、他のマイクロサービスを呼び出しているためです。

ここにおいても、PCF はマイクロサービスの使用者に解決策を提供します。

PCF は、ログを集約して簡単にアクセスできるようにストリーム化します。開発者は、Webサーバー、プラットフォーム、アプリケーションログを 1箇所で取得できます。これにより、エンジニアは、ログとイベントを関連付けることができます。その結果、アプリケーションの問題解決が早くなります。

また、PCF では、Splunk のような外部のログ管理システム（LMS）にも対応しています。IT 運用担当者は、Firehoseのノズルを調整して、アプリケーションとプラットフォームのログを、直接 LMSに送信することができます。そして、開発者と IT 運用担当者は、それぞれ好みのツールを使用して、これらのログでフィルタリング、検索、解析を実行することができます。詳細については、メトリクスセクションを参照してください。

分散トレーシング：マイクロサービス間のインタラクションの把握本番環境でモノリシックアプリケーションが性能問題に遭遇した場合であっても、調査は簡単です。すべてのロジックは、1つのアプリケーション内に格納されているからです。

マイクロサービスに移行した場合、性能の問題は、通信ノードのいずれでも発生する可能性があります。マイクロサービスへの単一の呼び出しは、異なるマイクロサービスへの複数の呼び出しにつながり、その結果、他のマイクロサービスも呼び出すことになります。やがて、相互に接続しあった呼び出しの網に取り組むことになるでしょう。これは、問題の選別を非常に困難にします。

では、この問題をどのように解決したらよいのでしょうか？その答えは、分散トレーシングです。

分散トレーシングは、各リクエストにタグ付け（「トレース」）をして、処理中にリクエストが呼び出す各オペレーション /サービス（「スパン」）にデータを送信します。どのリクエストにも、1つまたは複数のスパンを含むトレースが作成されます。

SpringCloudSleuth は、SpringBoot アプリケーション用の分散トレーシングを提供します。SpringCloudSleuth は、抽象化層を HTrace や Zipkin（Dapper）のような分散トレーシングモデルの最上位に追加します。SpringBoot アプリケーションは、SpringCloudSleuth がプロジェクトのクラスパスで依存として追加された場合に、トレース情報を自動的に追加します。spring-cloud-sleuth-zipkin が Maven 依存として利用可能である場合、アプリケーションは、HTTP 経由で Zipkin 対応トレースを生成します。また、PCF は、これらのアプリケーションについて、loggregatorと PCFMetrics でトレース情報をストリーム化します。

PCFMetrics は、図 6に示すように、SpringCloudSleuth の独自の実装を提供します。これは、レイテンシーとパフォーマンスの問題を調査するためのUIと検索機能を特色とします。トレースIDとスパンIDは、ログの一部としてストリーム化されます。ユーザーは、さまざまなマイクロサービス間のリクエストのフローを可視化することができます。

pivotal.io

ホワイトペーパー 15

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

図 6：PCF Metrics のトレースおよびスパン情報による分散トレーシング

運用マイクロサービスの構築では、本番環境でマイクロサービスをどのようにプッシュし監視するかを考慮してください。では、3つの運用領域（CI/CD、ブルー / グリーンデプロイメント、メトリクス）で PCF がどのように役立つかを見てみましょう。

CI/CD継続的統合（CI）と継続的デリバリー（CD）のパイプラインは、マイクロサービスの前提条件です。自動化を使用して、本番環境へ付加的かつ頻繁にリリース（できれば毎日）しましょう。CI と CDは、さまざまな環境やテストサイクル全体を流れるコードのフローの可視化に役立ちます。

PCF は、以下の 2つの方法で CI/CD をサポートしています。

第 1 に、PCF はマルチテナントを利用します。Org（組織）と Space（スペース）はソフトウェア開発のライフサイクル環境に位置します。PCF は、コードがさまざまなスペースを移動するに伴い、均一な環境を提供します。これにより、コードが異なる環境内でも同様に動作するため、開発者は心配不要となります。

これは、なぜ重要なのでしょうか？漸次的なコード変更を異なる環境（開発、テスト、UAT、パフォーマンス）にプッシュすると、新しい変更は各環境の自動テストハーネスによって検証されます。コードが高次の環境に移動すると、テストの焦点は、ユニットテストから結合テスト、そして性能テストに変わります。一貫性が保証されなければ、プロセス全体が破たんしてしまいます。

第 2 に、PCF は Jenkins や Concourse のような一般的な CI/CD ツールと連携します。PCF は、これらの CI/CD パッケージから呼び出すことのできる API を提供します。開発者は、CloudFoundryAPI を呼び出して、CI/CD パイプラインを素早く記述することができます。そして、開発者は、それぞれ望む IDE と統合したり、自動構築プロセスの一部として実行させたりすることができます。

CI と CDの詳細なビューと開始方法については、もう一つのホワイトペーパーを参照してください。

ブルー / グリーンデプロイメント（ゼロダウンタイムデプロイメント）各チームは、マイクロサービス・アーキテクチャを選択して、市場投入を加速することができます。漸進的変更を本番環境にプッシュすると、ユーザーのフィードバックがすぐに提供され、それによってさらなる漸進的変更が加えられることによってユーザー体験が向上します。これはまさに好循環と言えるでしょう。

pivotal.io

ホワイトペーパー 16

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

地理的位置、顧客タイプなどの基準に基づき、新しい機能をロールアウトしたいと考える場合があります。理想は、既存の機能に影響を与えることなく変更を加えることです。ブルー /グリーンデプロイメントは、このようなシナリオに対応してくれます。

しかし、ユーザーが特定の機能を気に入らなかったらどうなるでしょうか？この場合も、ブルー /グリーンデプロイメントが役立ちます。

段階的に新バージョンにロールアウト（または前バージョンにロールバック）するためには、ユーザートラフィックを容易かつ動的に迂回させる必要があります。PCF では、これに「ルート」で対応します。

ルートは、アプリケーションと関連付けられている一意の URL です。アプリケーションは 1つまたは複数のルートを持つことができ、ルートは 1つまたは複数のアプリケーションと関連付けることができます。アプリケーションを新しいバージョンにロールアウトする場合、仮ルートを作成して小さなユーザーサブセットで検証することができます。検証に合格して完全なロールアウトを行う場合は、前バージョンと同じルートで新しいバージョンのアプリケーションをマップすることが可能です。そして、前バージョンのアプリケーションは、ルートをアンマップすることで、ゆっくりと段階的に廃止できます。図 7は、このワークフローを示しています。

r1.demo.ior1.demo.ior1.demo.io r2.demo.io

r1.demo.io

図 7： Pivotal Cloud Foundry によるブルー / グリーンデプロイメント

これらすべては、ユーザーが前バージョンのアプリケーションと通信をする間に動的に行われます。アップデートをロールバックする場合は、新バージョンのアプリケーションに誰もアクセスできないように、新バージョンからルートを簡単にアンマップ可能です。そして、前バージョンのアプリケーションにリマップすることができます。

ブルー /グリーンデプロイメントは、本番環境における新しい変更に関連するリスクを低減します。これは、多数のマイクロサービスに小さな変更を行う場合に有用です。ダウンタイムなく、顧客からフィードバックをより早く取得することができるのです。

そして、ブルー /グリーンデプロイメントは、ステートレスなマイクロサービスにはもっとも効果的であるということをぜひ覚えておいてください。マイクロサービスがバックエンドデータベースと通信している場合、物事はさらに難しくなります。

メトリクスIT 運用担当者にとって、クラウドネイティブアプリケーションの 3つすべての層、つまり、マイクロサービス、コンテナ、VMの健全性は重要です。PCF は、一箇所にプラットフォームとアプリケーションのメトリクスを提示することで、運用効率を向上します。

pivotal.io

ホワイトペーパー 17

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

PCF の Loggregator は、アプリケーションおよびプラットフォームコンポーネントからログとメトリクスを収集するロギングシステムで、単一のエンドポイント、Firehose に送ります。ノズルは、Firehose から送られるデータの読み取りと処理を専用に行うコンポーネントです。顧客は Splunk、LogSearch、DataDog などの一般的なツールにカスタムノズルを使用して、希望するシステムでメトリクスを表示・解析することが可能になります。

開発者の場合、前述の PCF メトリクスモジュールによって、アプリケーションのログとメトリクスをダッシュボードに表示することができます。このアドオンは、特定の時間枠のアプリケーションデータを対応するアプリケーションログと共に、グラフ表示してくれます。

pivotal.io

ホワイトペーパー 18

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

まとめソフトウェア定義型のビジネスになるために取り組んでいる企業は、マイクロサービスを選択しています。このパターンは、市場投入までの時間短縮、柔軟性、拡張性、そして開発者の効率を実現します。

モノリシックアプリケーション向けに作られた従来の多くのツールとプロセスは、マイクロサービスには適用できません。幸い、PivotalCloudFoundry のようなプラットフォームが、マイクロサービスに関連する複雑性の多くを解決してくれます。

成熟した分散マイクロサービス・アーキテクチャは、Spring や .NET、継続的インテグレーションおよび継続的デリバリーのツール、ログとメトリクスへの容易なアクセスへのサポートを要求します。

PivotalCloudFoundry は、このようなすべての要件以上に対応するマイクロサービスプラットフォームです。さらに、多くの企業組織は、新しいマイクロサービス・アーキテクチャを PCF 上に構築・運用しており、成功を収めています。推薦文献と付録 Aでは、PivotalCloudFoundry のマイクロサービスの、より詳細な説明と、顧客の成功事例をご覧いただけます。付録 Bは、マイクロサービスの文化的考慮事項を提示し、付録 Cは、このパターンで有用なリファレンスアーキテクチャについて説明しています。

推薦資料• ホワイトペーパー：StandingontheShouldersofGiants:SuperchargingYourMicroservicesWithNetflixOSSandSpringCloud（巨人の肩の上に立つ：NetflixOSS と SpringCloud でマイクロサービスを強化する）

• トピックページ：マイクロサービス

• DeployingMicroserviceArchitectureswithPivotalCloudFoundryAPivotalPerspective（PivotalCloudFoundry によるマイクロサービス・アーキテクチャの展開、Pivotal の視点）

• SpeedThrills:HowtoHarnessthePowerofCI/CDforYourDevelopmentTeam（スピードのスリル：開発チームのCI/CD の力を強化するには）

• ホワイトペーパー：クラウドネイティブアプリケーションに適した安全でハイブリッドな銀行業務リファレンスアーキテクチャ

• eBook：CloudNativeJava（クラウドネイティブ Java）

pivotal.io

ホワイトペーパー 19

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

付録 A：同業者から学ぶ： トップ企業はどのように マイクロサービスを活用しているか

Pivotal は、お客様との協業体制を重視しているため、現実世界や大手お客様企業のプロジェクトから得た知識や教訓を共有することが重要だと考えています。お客様に今回のケーススタディを参考にしていただければ幸いです。

CitiCiti のグローバルテクノロジー・アンド・クラウドテクノロジー担当責任者、BradMiller 氏は、マイクロサービスの構築と既存のアーキテクチャの移行を開始するために必要なスキルの開発で、[Pivotal が支援してくれました ]、と語ります。[ 詳細を見る ]

Comcast数百人の開発者によって構築された数多くのアプリケーションとサービスが、数千万のトランザクションをサポートする―このような Pivotal のソリューションのおかげで、Comcast は、アイデアの機能化を数週間ではなく数日で行い、競争的差別化を実現しています。[ 詳細を見る ]

Allstateビジネスの成長のためにテクノロジーの活用を目指す Allstate は、Pivotal と協業して、かつては想像もできなかったほどの速さと効率でサービスを革新、拡大しました。[ 詳細を見る ]

pivotal.io

ホワイトペーパー 20

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

付録 B：マイクロサービスと文化組織：マイクロサービスのための態勢を整えるモノリシック・アプリケーションアーキテクチャのソフトウェア開発ライフサイクルでは、さまざまなチームがさまざまな段階を担当します。チームは、開発、機能テスト、品質保証、性能テストなど多様です。アプリケーションは、本番環境にデプロイされると、本番運用チームの手に移ります。各チームはサイロ化され、組織は共有することよりプロセスに大きく依存しています。所有権は細分化し、各チームは、ソフトウェア開発ライフサイクルのわずか 1つの局面しか所有権を持ちません。ソフトウェア製品の開発ライフサイクルで、最初から最後まで一貫して担当する者が誰もいないのです。

マイクロサービスアークテクチャの採用を考える組織は、このモデルを変える必要があります。開発者の生産性向上と市場投入までの時間短縮による利益を得るには、プロセスのボトルネックを排除して、各チームがソフトウェア開発ライフサイクル全体を所有できるように権限を強化する必要があるのです。そのためには、文化、チーム構造、そしてチーム内のロールを変えなくてはなりません。

文化：開発と運用が共通の目標のもとに協働組織文化とは、前提、価値、信念を共有するシステムで、組織内での人々の行動に影響を与えます。そして、目標は、各部門、各チームが均一な文化を持つことです。しかし、これはめったに実現しません。

マイクロサービス・アーキテクチャを採用したいと考える組織は、このような文化においてよく見られる相違、文化的競合に取り組む必要があります。次の 2つの質問を考えてみてください。

1. 開発者は、スピードと顧客の価値実現の速さで評価されていますか？

2. 運用担当者は、安定性維持とプロセス遵守で評価されていますか？

両方ともイエスの場合は、これらの目標を 1つの共通目標として結びつける必要があります。

組織のリーダーは、変革的アプローチで、これらの 2つのチームを共通の 1つの目標のもとに協力させなくてはなりません。各チームは、責任を共有し、成功に対する共通の尺度を持つ必要があります。

開発者は、本番環境にデプロイするコード変更について、信頼性が高いこと、回帰テストが実施済みであること、フォールトトレラントであることを確認しなくてはなりません。たった 1つのコードがシステム全体をダウンさせるようなことがあってはならないのです。

運用担当者も、監視、メトリクス、ロギングのための各ツールが適切に稼働するようにしなくてはなりません。運用担当者は、問題を積極的に特定し、開発者と協力して、顧客に影響が及ぶ前に問題を解決する必要があります。開発者と運用担当者は共同でコードのデプロイのための自動パイプラインを作成し、ソフトウェア開発ライフサイクルの各段階でコードがどのように動くか、両チームが見えるようにします。これは、両チームにおける責任の共有であり、別の「DevOps」チームに責任をわたすことではありません。

pivotal.io

ホワイトペーパー 21

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

チーム構造 / 構成モノリシックなアーキテクチャでは、組織は、モノリスの異なる局面について作業する大きなチームを有し、さまざまな開発チーム、テストチーム、本番運用チームがあります。各チームは、コードだけでなく、本番稼働実現までの作業でも緊密につながっています。

チーム間の依存レベルは非常に高く、いずれもチームも、他のチームより早く改革したり行動したりすることはできません。本番環境へのデプロイメントは、すべてのチームが週末に集まって、すべてのコードを同時に本番環境にプッシュするという、一大イベントです。1つのチームのコードが壊れると、本番環境へのデプロイ全体がストップします。

このようなチーム構造は、マイクロサービス・アーキテクチャでは機能しません。独立した小さなチームが本番環境をより迅速に変更するということに重点が置かれているためです。

マイクロサービスを採用する組織は、製品機能やバインドされたコンテキストについて、それぞれのチームを再編する必要があります。各チームは、ソフトウェア全体の中の小さな 1つの機能を担当することになります。たとえば、eコマースのWeb サイトがあるとします。そこには、検索機能チーム、ショッピングカート機能チーム、チェックアウト機能チームなどがあります。

このような各機能チームは、それぞれ担当する製品機能の開発と維持全体に対して責任を持ち、他のチームとのRESTful コントラクトに従います。各チームには、開発者、ビジネスアナリスト、機能テスト担当者がいます。本番稼働サポートは、同じチーム内の開発者が順番に行います。各チームは、まるで構築したソフトウェアのように、疎結合されます。

マイクロサービスのソフトウェア開発を成功させるには、小さく独立し、機能横断的で自己充足型チームが必要とされるのです。

ロールモノリシックなアーキテクチャでは、組織の役割が明確に定義されています。開発者はコードを開発し、テスト担当者はコードをテストし、保守サポートチームは本番環境のコードをサポートします。組織がマイクロサービス・アーキテクチャに移行する場合、焦点は、独立した自己充足型チームに移ります。すべてのチームメンバーが複数の肩書を持ち、必要に応じて他のチームメンバーの役割を請け負います。同じ開発者が、開発と本番稼働サポートの役割を担当します。

モノリシックなアーキテクチャでは、インテグレータという役割が別に存在します。この役割の開発者は、さまざまなモノリシック・ソフトウェアコンポーネントを、通常はエンタープライズ・サービス・バスで統合することを役割とする、中央統合チームの一部です。マイクロサービス・アーキテクチャでは、統合は RESTful コントラクトによって行われます。マイクロサービスチームの開発者は、他のチームとの統合の責任を有します。この組織設計では、特別な統合チームは必要ないのです。

同じことが、「DevOps」チームにも言えます。このチームは、通常、開発者と運用担当者を結びつけて溝を埋めるために作られます。このチームメンバーは構成の専門家で、コードを開発環境から本番環境まで移行させることに責任を負います。繰り返しになりますが、DevOp チームは、モノリシックアプリケーションの環境構成を管理するために特別に作られた、もうひとつの中央チームです。マイクロサービスを基盤とする環境では、開発者と運用担当者は、連携して自動パイプラインを作成し、パイプラインの一部としてのさまざまな環境構成を管理します。構成は、gitによってサポートされる構成サーバーでの独立した管理が理想的です。これにより、モノリシックチーム構造で存在している専門家チームは、マイクロサービスベースのチーム構造では不要となります。

pivotal.io

ホワイトペーパー 22

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

付録 C：リファレンスアーキテクチャPivotal Cloud Foundry で稼働するアプリケーションとマイクロサービス図 8のアーキテクチャは、一般的なクラウドネイティブ属性を示しています。

• リアルタイムデータ処理のモダンなアプローチ

• 高度に分散化されたスケールアウトパターン

• コマンドクエリの責務分離（CQRS）アプローチ。これは、2つの異なる部分にシステムを分離します。CQRS は、書き込み（実行コマンド）に使用されるコンポーネントを、クエリ実行に使用されるコンポーネントから分離します。それによって、コマンドサービスとクエリサービスがそれぞれ独立したスケーラブルなサービスになります。これらのサービスは切り離され、個別に動作することができます。

• 大量のトランザクションを処理するイベントストア

ServiceRegistry SSO

MySQL

Subscribe to Events

Query DB

HTTP GETHTTP POST/PUT

OAuth2Discovery

Registraton

PublishEvents

ManageConfiguration

CreateRead

ViewsEvent

Processor

CommandService

Edge Gateway

Event Store

QueryService

ConfigServer

図 8：Spring Cloud Services と Pivotal Cloud Foundry を実行するイベント駆動型クラウドネイティブ・アプリケーション

pivotal.io

ホワイトペーパー 23

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

リファレンスアーキテクチャのコンポーネント• Spring Cloud の Zuul と共に実装される Edge Gateway は、リバースプロキシです。このゲートウェイサービスは、動的ルーティング、監視、回復力、セキュリティなどを提供します。このアーキテクチャでは、指定された動的ルーティングルールを実行し、さまざまなインバウンドクライアントを受け入れます。

• Spring Cloud Services Service Registry として実装されるサービスレジストリは、サービスを追跡します。コマンドサービスとクエリサービスは両方とも、このモジュールに登録されます。EdgeGateway はサービスレジストリを使用して、サービスの場所やリクエストのルーティング先を探します。

• Single Sign-On for PCF。シングルサインオンサービスは、アプリケーションとサービスへのアクセスをセキュアにするオールインワンソリューションです。このサービスによってユーザーは個々のコンポーネントにログインする必要がなくなるため、セキュリティと生産性が向上します。

• Spring Cloud Data Flow で書き込まれるコマンドサービスは、システムに何かを実行すること、または状態を変更することを命令します。これは、アプリケーションのビジネスロジックの一部を構成しています。

• Spring Boot アプリケーションのクエリサービスは、リレーショナルデータベースを検索し、関連する結果を戻します。コマンドサービスとは逆に、クエリサービスはシステムの状況を変更しません。このサービスは、負荷が変動しやすく、必要に応じて拡張することができます。

• Spring Cloud Services Config Server として実装される構成サーバーは、すべての環境変数を格納します。構成は、いずれのサービスにも格納されません。構成サーバーは、この情報を保存して、オンデマンドで提供します。これは、「12FactorApp」の原則に一致するクラウドネイティブのベストプラクティスです。

• Spring Cloud Data Flow に書き込まれるイベントプロセッサは、コマンドサービスと連携します。これは、アプリケーションのビジネスロジックのもう一つの部分です。

•「真実のシステム」としての MySQL for PCF。これは、クエリサービスがリクエストした結果を戻します。

• Apache Kafka を基盤とするイベントストアは、大量のイベントを処理するシステムです。このパターンは、しばしば「イベントソーシング」と呼ばれます。過去のイベントストリームの「再生」が必要となる可能性があるため、このシナリオでは最良のオプションです。対照的に、RabbitMQのようなシステムは、適切に受信したメッセージを即時に削除します。

pivotal.io

ホワイトペーパー 24

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

銀行のサンプルアプリケーションそれでは、サンプルアプリケーションを見てみましょう。このアプリケーションアーキテクチャは、Pivota ｌと銀行業界の戦略的なお客様である JP.モルガン・チェースとの緊密な協業体制と共同エンジニアリングにより生み出されました（図 9）。

このアプリケーションは、エンタープライズ・データプラットフォームです。このプラットフォームは、参照データを取得する他のすべてのサービスにとって、データソースとして機能します。

このプラットフォームにより、開発者がどのようにコード開発に専念できるのかを見てみましょう。PCF と SpringCloudServices は、進行中の管理と運用に対応します。

Spring Cloud Services

Configuration

データソース 分散プラットフォーム

1.入口

5.イベントストア

NoSQL

Store

6.エラー

イベントストア

NoSQL

Store

7.監査

NoSQL

Store

8.問合せ可能

データ

NoSQL

Store

9.検索可能

インデクス

SearchEngine

10a. 15.UI運用管理

10c.回復ポジション

10b.調停による自動復旧

スケジューラ

UIビジネス

データ取得

検索

2.検証

トランスフォーマ 3.濃縮

4.ルールベースの

濃縮

LDMトランスフォーマ

11.発行

オフプラットフォーム・サービス

AggregatedLogging

3a.同期型データ取得 (サービス・アクティベータ)

サービスサービス

アクティベータサービス

RESTエンドポイント

リクエスタ

AutoscaleKey and

Certificate StoreMessaging

運用担当者

到着したストリーム

C1, C2, C3,C4, C5, C6

C1, C2, C3,C4, C5, C6

C1, C2, C3,C4, C5, C6

Search Request(on demand)RE

STRE

ST

RESTREST

運用担当者

REST

REST

RESTREST

C1, C2, C3,C4, C5, C6

C1, C2, C3,C4, C5, C6C5 C6C6, C7

(XML)

ChannelC1

ChannelC1

検証されたストリーム

ChannelC2

ChannelC2

変換されたストリーム

ChannelC3

ChannelC3

ChannelC

7C

hannelC

7

集合ストリーム

ChannelC4

ChannelC4

派生したストリーム

ChannelC5

ChannelC5

変換されたストリーム

サービス

サービス

ChannelChannel

JMSキュー

Kafkaチャネル

メッセージングストリーム /トピック

ビジネス固有サービス

共有サービス

凡例

LDM(JSON)

ChannelC6

ChannelC6

図 9：Spring Cloud Stream を基盤とするデータ取得のためのリファレンスアーキテクチャPivotal のお客様の銀行アプリケーション本番稼働アーキテクチャ

pivotal.io

ホワイトペーパー 25

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

サンプルアプリケーションのコンポーネントこの共同設計されたアプリケーションは、以下のカスタムサービスを特徴としています。

1. 取得。これらのサービスは、上流ソースからのデータを収集します。次に、データはある形式のストア内に登録されます。そしてデータは、下流パイプラインの求める形態に変換されます。

2. 検証。データはここで、必要なスキーマや品質基準に準拠しているかどうか検証されます。

3. 濃縮。データメッセージの濃縮は、外部リソースからのデータに依存します。外部ソースには、非同期または同期インターフェースを通じてアクセスします。使用されるパターンには以下のようなものがあります。

a. 同期データ取得。多くの外部サービス（通常、本質的には同期的で互いに依存関係ではない）へのリファレンスは、サービス・アクティベータパターンによって行われます。パフォーマンスの観点から、これはスプリッタの複合、アグリゲータパターンとなります。

b. 非同期データ取得。複数のソースから必要とされているデータは、非同期 / メッセージングシステムから取得されます。このシステムは、リアクティブアプローチを採用しています。

c. ゲートウェイ。「管理境界外」にあるリソースにリクエストが行われた場合、リクエストはゲートウェイを通ります。

4. ルールベースの濃縮。複雑なビジネスルールを適用するには、カスタムのルール定義を持つルールエンジンが必要です（導出と検証）。一般的に、これは RETE ベースエンジンです。

5. イベントストア。システム内で発生するすべての重要なイベントは、後で処理できるように取得および記録されます。これらのイベントは、検出することも可能です。

6. エラーイベントストア。上記のイベントストアと同様ですが、エラーイベントストアはシステム内で発生したエラーイベントに対応します。これには、各メッセージが復旧ポイントでタグ付されている必要があります。通常、復旧ポイントは、メッセージをフローに再送信できるチャネルとなります。これには、システムを通じて再送信可能なデータペイロードが含まれます。

7. 監査。オリジナルデータメッセージに行われた変更はすべて（フロー内）記録されます。追加メタデータ（変更が起こった時間や変更の原因など）も、監査要件に応じて記録されます。

8. 問合せ可能データ。システムの「質の高い」データは、問合せ可能であるため取得もできます。

9. 検索可能インデックス。システム内のすべての「質の高い」データ（濃縮されたデータ）は、効率的な検索サービスによって検索可能です。一般的に、サービスは、NoSQL データストアによってサポートされている検索エンジンによって提供されます。

pivotal.io

ホワイトペーパー 26

© Copyright 2017 Pivotal Software, Inc. All rights Reserved.

Pivotal Cloud Foundry 上で稼働するマイクロサービス

10.復旧。復旧ポイントは、最後に認識されている問題のないコンポーネントの出力チャネルです。これには、システム内での適切な処理の記録がメッセージに適用されている必要があります。

a. 手動での復旧：一部のエラーイベントでは、復旧するために検査と手動による介入が必要です。すべての情報は、障害時点のエラー状況に基づきます。システムで最後の問題のないポイントが利用可能になります。

b. 照合による自動復旧：失敗した（しかし修復可能な）メッセージは最後に認識されているチャネルに自動的に置かれます。メッセージの実行を試みた回数の記録も、メッセージのメタデータ内に維持されます。これにより、照合プロセスはステートレスになります。

c. 復旧ポジション：これは、メッセージの再生が可能なフロー内のすべてのポイントです。

11.発行。システムによって定義されている品質のしきい値に達したデータは、下流のコンシューマに発行されます。通常、これは、データリザーバーまたは同等の配信プラットフォームです。

12.サーキットブレーカー。これにより、システム内の外部依存関係の隔離が可能になります。このような依存関係が利用不可能または壊れた場合でも、システムはフォールトトレラントで、当該依存関係の処理に際して復旧への方法を提供します。

13.Edge Gateway。これは、複数のサービスまたはデータソースの統合のためのファサードです。EdgeGatewayにより、トークンとエンタイトルメントでセキュリティ（認証と権限付与）の集中管理を行えるようになります。

14.運用管理。プラットフォームの運用を管理します。これには、監視オペレーションと、エラーやセキュリティイベントなどのイベント対応の両方が含まれます。