クラウドネイティブアプリケーションに適した...

ホワイトペーパー

Jared Ruckle、Matt Stine、Ford Donald、Guillermo Tantachuco

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

pivotal.io

ホワイトペーパー 2

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

クラウドネイティブアプリケーションのためのセキュアなハイブリッドバンキング・リファレンスアーキテクチャ

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

クラウドネイティブジャーニーの設計図 ................................. 3

セキュリティについて ......................................................................... 4

内容 ............................................................................................................... 5

PivotalCloudFoundry：プラットフォームとサービス ... 5

インフラストラクチャサービス仮想ネットワーク .................. 6

ElasticRunTime 仮想ネットワーク ................................................. 6

アプリケーションサービス仮想ネットワーク ........................... 7

その他のトピック ................................................................................. 8

プラットフォームのコンプライアンスとセキュリティ対応 ................................................................................... 8

SpringCloudServices .........................................................................10

概要 ..........................................................................................................10

ConfigServerforPivotalCloudFoundry ....................................10

ServiceRegistryforPivotalCloudFoundry ...............................11

CircuitBreakerDashboardforPivotalCloudFoundry ...........11

リファレンスアーキテクチャ：論理インフラストラクチャ .............................................13

論理インフラストラクチャ：VMwarevSphereと NSXを使ったオンプレミス環境 .....13

コンピューティング ...........................................................................14

ストレージ .............................................................................................14

ネットワーキング ...............................................................................14

ネットワーク設計 ...............................................................................14

その他のガイド：VMvSphere によるオンプレミス..............15

リファレンスアーキテクチャ：パブリッククラウドの論理インフラストラクチャ ...........15

マルチクラウド：最適なクラウドプロバイダを容易に使用可能 .....................15

ハイブリッド環境における考慮事項 .........................................16

データレプリケーション ..................................................................16

サイト選定のルーティング .............................................................17

Active/Active か、Active/Passive か？ .......................................18

デプロイメントのオーケストレーション ..................................18

リファレンスアーキテクチャ： Pivotal Cloud Foundry で稼働するアプリケーションとマイクロサービス ..............19

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

複数サイト間での高可用性に関する考慮事項 .....................20

サービスレジストリによるピアレプリケーション ...........21

Ribbon によるクライアントサイドでのロードバランシング ...21

リファレンスアーキテクチャ：顧客向け銀行アプリケーションのサンプル ......23

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

PCF プラットフォームサービス ....................................................25

次のステップ ...........................................................................................25

付録 A：なぜクラウドネイティブなのか？クラウドネイティブが重要な理由 .........................26

ソフトウェアは世界をどのように飲み込んでいくのか？ ...26

目標：品質向上とビジネス拡大のためのサイクルの短縮 ...26

継続的デリバリのパイプライン ....................................................27

付録 B：夜眠れない理由：銀行エディション ....................28

付録 C： Pivotal の顧客は、クラウドネイティブに移行するために何をしているか？第一歩はプラットフォーム。 .......................................30

目次

pivotal.io




はじめに銀行での IT 運用は気の弱い人には向きません。この業務には、創造性、俊敏性、実用主義、そして根気のすべてを兼ね備えている必要があります。何より、次のような時代の変化を切り抜けられなくてはなりません。

• 消費者の期待の高まり。市場は、バンキングアプリも消費者のお気に入りモバイルアプリのように動作することを望むようになりました。便利なものにするには、軽快で応答性が高く魅力的なユーザー体験の実現が求められます。

• フィンテックによる競争の拡大。競合会社はウォールストリートだけとは限りません。シリコンバレーの天才集団も金融業界に狙いを定めています。

• 規制要求とコンプライアンス。業界の規制では、変革の方法と投資先についての情報提供が義務付けられています。

• セキュリティ。これからの 10 年は、スピードとセキュリティを兼ね備えた銀行が最大の成功者となるでしょう。どちらか片方では不可能です。

このように劇的に変化する中で収益をあげて市場シェアを得るにはどうしたらよいのでしょうか？答えは、クラウドネイティブな企業になることです。PivotalCloudFoundry（PCF）は、これを実現するためのもっとも有効なツールです。（このトピックに関する詳細は、付録をご覧ください。）

クラウドネイティブジャーニーの設計図Pivotal のエンジニアと設計者は、この数年間、上位 7銀行と協力し、PCF のデプロイと最新アプリケーションの開発を最適に行うことのできる「ベストプラクティス」を磨きあげてきました。この知見によって、顧客はリスクを低減し、高品質なソフトウェアのより迅速なデリバリが可能になります。

得られた知識は、リファレンスアーキテクチャとしてまとめられました。本書でその概要をご紹介します。このアーキテクチャの設計図により、銀行は、高い安全性と拡張性を実現しながらソフトウェアを継続的にデリバリーすることが可能になります。4つのアーキテクチャとよくある質問を見てみましょう。

• Pivotal Cloud Foundry とは？ PivotalCloudFoundry は、ソフトウェアの迅速なデプロイとよりセキュアな運用の実現をどのように助けてくれるのですか？必要なデータサービスを提供できるようにプラットフォームを拡張するにはどうしたらよいのですか？これらの疑問に対し Spring フレームワークはどのように応えてくれるのでしょうか？内容を参照

• データセンターに PCF をどのようにデプロイしたらよいのですか？パブリッククラウドはどうなるのですか？アプリケーションをマルチサイトで運用するにはどうしたらよいのですか？リファレンスアーキテクチャ：論理インフラストラクチャを参照

• Pivotal Cloud Foundry では、マイクロサービスとイベントドリブンアーキテクチャをどのように運用するのですか？リファレンスアーキテクチャ：PivotalCloudFoundry で稼働するアプリケーションとマイクロサービスを参照

• Pivotal Cloud Foundry と Spring Cloud Services では、実際の銀行アプリはどのように見えるのですか？リファレンスアーキテクチャ：顧客の銀行アプリのサンプルを参照

https://pivotal.io/industries/financial-services

pivotal.io




セキュリティについてはじめにで述べたように、セキュリティ態勢の改善は常に優先事項です。そのために一般的に行われる投資の 1つが、ネットワークの仮想化です（VMwareNSX など）。

ネットワークの仮想化だけでもセキュリティは向上します。例えば、企業全体にネットワークポリシーを強制することが非常に容易になります。それでは、この技術と PivotalCloudFoundry を組み合わせたらどうなるでしょうか？

結果は、組織にとってまさに鬼に金棒となります。

アプリケーションのインタラクションに「ゼロトラストモデル」を使用する、リアルタイムで負荷の分離を検証する、システム全体に最小権限の原則を強制する―これらすべてをプラットフォーム内で実行します。したがって、エンジニアはこれらのタスクを意識する必要がなくなります。

「迅速かつセキュア」という夢が現実のものとなるのです。

pivotal.io




内容

Pivotal Cloud Foundry：プラットフォームとサービスPivotalCloudFoundry（PCF）は、アプリケーションのデプロイと運用のためのクラウドネイティブなプラットフォームです。PCF は、オンプレミス、そして多くのパブリッククラウド・プロバイダ上で稼働できます。これにより、企業はハイブリッドなマルチクラウド・プラットフォームを手にすることができます。

PCF は、ポピュラーな言語で記述したアプリケーションを起動し、素早く反復できる、統一的な方法です。このプラットフォームは、あなたに代わり、多くの実装を詳細にわたって管理します。PCF を活用すれば、アプリケーションをどのようにデプロイ、スケール、公開するかを考慮する必要がなくなり、コードの開発によってビジネス価値を加えることに専念できます。開発者はアプリケーション開発をスピードアップし、市場投入までの時間を短縮することが可能になります。

図 1は、重要な PCF コンポーネントを示しています。このアーキテクチャは、組み合わせるネットワークとの整合性に応じて要素を調整します。

• インフラストラクチャサービス仮想ネットワーク。基盤となるインフラストラクチャを制御するために PCFOpsManager が使用します

• Elastic Runtime 仮想ネットワーク。PCF の ElasticRuntime、コンテナオーケストレータなどの関連サービスが使用します

• アプリケーションサービス仮想ネットワーク。MySQL、RabbitMQ、SpringCloud®ServicesforPivotalCloudFoundry のような PCF マネージドサービスが使用します

NATゲートウェイによるセキュアなネットワーク接続

ロードバランサ

MySQL Brain

Configデータ

Windows セルLinux セル

Spring Cloud Services

Redis

Pivotal CloudCache

サードパーティのサービス

プラットフォームAPI

ログ& モニタリング

ログ検索

Diego

メッセージ

TCPルーター

ErrandネイティブIaaS機能により

暗号化されたBlob Storage

HTTPルーター Gorouter

ログ集約

機密情報& キー管理

インフラストラクチャサービス仮想ネットワーク

Elastic RunTime仮想ネットワーク

VMware OpenStack Amazon Azure GCP

アプリケーションサービス仮想ネットワーク

アイデンティティ＆アクセス管理

PCF OpsManager

デプロイメントサービス

サービスのプロビジョニングとデプロビジョニング

HTTP/sによるセキュアな

インタラクション

RabbitMQ

サードパーティのサービス

インターナルサービス

図 1 – Pivotal Cloud Foundry の主要コンポーネントの概要

pivotal.io




それでは、図 1の各項目を見てみましょう。

インフラストラクチャサービス仮想ネットワーク

• 機密情報および証明書管理–CredHubがCloudFoundryに追加される予定です。この機能は、証明書の生成、保存、ライフサイクル管理、アクセスを一元化し、セキュリティを確保します。CredHub により、証明書の漏洩や、データ侵害における犯罪のリスクを低減することが可能になります。

• アイデンティティ管理とアクセス管理–シングルサインオン方法に使用されるプロトコルは、LightweightDirectoryAccessProtocol（LDAP）です。LDAP は、ツール（Microsoft の ActiveDirectory など）とサードパーティのシステムを接続します。PivotalCloudFoundry は、UAAサービスによって LDAP と SSOをサポートします。

• PCF Ops Manager–OperationsManager（「OpsManager」）は、PCF のデプロイと管理に使用されるWebアプリケーションです。OpsManager は、BOSHDirector と通信し、ElasticRuntime コンポーネントや他のサービスをデプロイします。” )

• デプロイメントサービス–PCF のデプロイは、ユーザーの提供する構成詳細に基づいて実施され、BOSHDirectorによって高度に自動化されています。

• NAT ゲートウェイによるセキュアなネットワーク接続–NAT（ネットワーク・アドレス変換）ゲートウェイにより、プライベートサブネットのサービスを他の PCF コンポーネントに接続することができます。また、NAT ゲートウェイは、インフラストラクチャサービス VLAN外のコンポーネントが、これらのサービスとの接続を行わないようにします。PCF のファイアウォールの構成に関する詳細を読む。

Elastic RunTime 仮想ネットワーク

• ロードバランサ–本番 PCF 環境では、可用性の高いロードバランサを使用します。ロードバランサは、トラフィックを PCFRouterIP にルーティングし、ワイルドカードDNS のロケーションで SSL の終了に対応します。また、受信したリクエストに、適切な x-forwarded-for および x-forwarded-protoHTTP ヘッダーを追加します。WebSocket は必要に応じサポートされます。

• TCP ルーター–TCP ルーターは、非 HTTPTCP プロトコルでリクエストに対応するアプリケーションと連携します。TCP ルーティングは、使用しているアプリケーションの可能な限り近くで TLS を終了します。このシナリオでは、パケットは、アプリケーションレベルに到達するまでは復号化されません。この構成は、特定の規制への準拠に役立ちます。

• HTTP ルーター–HTTP ルーターは、PCF デプロイメント内外のHTTP トラフィックを管理します。

• Gorouter–Gorouter は、PCF へのトラフィックを適切なコンポーネントにルーティングします。例えば、IT 運用担当者がプラットフォーム API に対応する際に Gorouter が使用されます。また、アプリケーションユーザーがDiego セルで稼働しているアプリにアクセスする際にも使用されます。

• プラットフォーム API–プラットフォーム API（または CloudController）は、システムにアクセスするクライアントのために、RESTAPI エンドポイントを提供します。また、組織、スペース、サービス、ユーザーロールなどのテーブルを含むデータベースを維持します。

• ロギングとモニタリング–PCFMetrics は、PCF で稼働しているアプリケーションからのログ、メトリックデータ、イベントデータを保存します。このモジュールは、これらのデータを視覚的にレンダリング表示します。この処理によって、IT 運用担当者と開発者は、アプリケーションの健全性とパフォーマンスをより良く把握できるようになります。

https://github.com/pivotal-cf/credhub

http://docs.pivotal.io/pivotalcf/1-10/concepts/architecture/uaa.html

http://docs.pivotal.io/pivotalcf/1-10/customizing/index.html

http://docs.pivotal.io/pivotalcf/1-10/customizing/vsphere-config.html

http://docs.pivotal.io/pivotalcf/1-10/customizing/config_firewall.html

http://docs.pivotal.io/pivotalcf/1-10/customizing/custom-load-balancer.html

http://docs.pivotal.io/pivotalcf/1-10/adminguide/enabling-tcp-routing.html

http://docs.pivotal.io/pivotalcf/1-10/concepts/http-routing.html

http://docs.pivotal.io/pivotalcf/1-10/concepts/architecture/router.html

http://docs.pivotal.io/pivotalcf/1-10/concepts/architecture/cloud-controller.html

http://docs.pivotal.io/pcf-metrics/1-3/index.html

pivotal.io




• ログ検索–IT 運用担当者は、PCFLogSearch を使用して様々なシステムコンポーネントを分析できます。この機能は、ElasticStack をカスタマイズして実装したものです。PCFLogSearch は、他のタイルからのデータを受信、解析、標準化します。IT 運用担当者は、PCFLogSearch の Kibana コンポーネントを使用して、システムデータを検索して視覚化することができます。

• Diego –Diego は、PivotalCloudFoundry のコンテナオーケストレータです。

ϐ Brain –DiegoBrain は、各 Diego セルに一度限りのタスクや長時間稼働プロセス（long-runningprocess：LRP）を配分します。これらのプロセスは動的に管理され、フォールトトレランスと長期的一貫性を向上させます。

ϐ Linux セル–各 Linux ベースアプリケーション VMには Linux セルがあり、ローカルアプリケーションの動作をスタートさせたりストップさせたりします。セルは、VM内のコンテナを管理し、アプリのステータスや他のデータを LogAggregator にレポートします。

ϐ Windows セル–Windows セルは Linux セルと機能は同様ですが、Windows および .NET コンポーネントに必要なタスクとプロセスに対するものです。

ϐ Config データ –このデータベースには、Diego クラスタの状態がリアルタイムで保持されます。保存されるデータは、希望するすべての LRP、動作している LRP インスタンス、インフライトタスクに関するメタデータなどです。また、Diego への一貫性のあるキーバリュー・データストアも含まれます。

• メッセージング–PCF のメッセージングはNATS を介して実行されます。軽量のパブリッシュ /サブスクライブおよび分散キューイングメッセージシステムです。

• Errand –これらのインスタンスは、一度限りの errand の実行専用です（例：タイルの追加と削除）。

• ログアグリゲータ–ログアグリゲータ（または「Loggregator」）は、ログとメトリックの集計とストリーミングを行います。ログアグリゲータは、すべてのユーザーアプリケーションとElasticRuntimeコンポーネントからデータを収集して処理します。

• ネイティブ IaaS 機能により暗号化された BLOB ストレージ–PCF では、BLOB ストレージを使用して、ビルドパック、Droplet、パッケージ、リソースをホストします。これは、オブジェクトストレージサービスまたは内部ファイルシステムになります。REST での暗号化は、ベースとなるストレージサービスのビルトイン機能によって実行されます。

アプリケーションサービス仮想ネットワーク

• Spring Cloud Services–SpringCloudServicesforPivotalCloudFoundry（PCF）は、SpringCloudNetflix やSpringCloudConfig などの SpringCloud プロジェクトのサーバーサイド・コンポーネントをパッケージ化して、PCF マーケットプレイスでサービスとして使用可能です。

• MySQL –MySQLforPCF は、単一ノードまたは 3ノードのリレーショナルデータベース・クラスタをデプロイして維持します。クラスタは、迅速なフェイルオーバーのために SQL プロキシでMariaDB を実行します。開発者は、各自のMySQL対応データベースをオンデマンドでプロビジョニングすることができます。その他の機能には、自動バックアップ、ゼロダウンタイム・アップグレード、構成可能なサーバープランなどがあります。

• Redis –RedisforPCF は、高性能アプリケーション向けのインメモリキーバリュー・データストアです。このサービスは、インメモリキャッシング、リアルタイムデータ構造計算、パブリッシュ /サブスクライブ、およびキューイングを実行します。Redis インスタンスは、共有リソースでも専用リソースでも利用可能です。

https://docs.pivotal.io/logsearch/index.html

https://www.elastic.co/products

http://docs.pivotal.io/pivotalcf/1-10/concepts/diego/diego-architecture.html


http://docs.pivotal.io/pivotalcf/1-10/concepts/diego/diego-architecture.html#brain-components


http://docs.pivotal.io/pivotalcf/1-9/windows/index.html

http://docs.pivotal.io/pivotalcf/1-10/concepts/diego/diego-architecture.html#database-vms

https://docs.pivotal.io/pivotalcf/1-10/concepts/architecture/messaging-nats.html

https://docs.pivotal.io/tiledev/tile-errands.html

https://docs.pivotal.io/pivotalcf/1-10/loggregator/architecture.html

http://docs.pivotal.io/pivotalcf/1-10/concepts/high-availability.html#blobstore

https://docs.pivotal.io/spring-cloud-services/1-3/

http://docs.pivotal.io/p-mysql/1-9/index.html

http://docs.pivotal.io/redis/1-7/index.html

pivotal.io




• Pivotal Cloud Cache–PivotalCloudCache（PCC）は、大規模カスタムアプリケーションのためのインメモリ分散データグリッドです。PCC は、多数のノードにわたって拡散したデータに対するインメモリ・アクセスを提供します。また、PCC は、「シェアードナッシング」アーキテクチャを特徴とします。この製品は、ApacheGeodeオープンソースプロジェクトの商用実装版です。

• RabbitMQ –RabbitMQforPCF は、効率的でスケーラブルなキューイングシステムで、メッセージトラフィックを容易に処理します。RabbitMQforPCF はプロトコルベースで、他のソフトウェアコンポーネントへの接続もシンプルです。

• サードパーティサービス–多様なソフトウェアパッケージを PivotalCloudFoundry と統合できます。最も一般的なものは、アプリケーションパフォーマンス管理（APM）、API ゲートウェイ、NoSQL データベースなどです。利用可能なソフトウェアの全一覧は、PivotalNetwork をご覧ください。

• 内部サービス–顧客は、サービスブローカのインターフェースを使用して、自社の内部サービスに接続することができます。

その他のトピック

• Apps Manager –AppsManagerはWebベースのツールで、PivotalCloudFoundry内のロールと権限を管理します。

• Buildpacks –Buildpacks は、アプリケーションにフレームワークおよびランタイムサポートを提供し、ユーザーの提供するアーティファクトを検証して依存関係を決定します。また、バインドされたサービスとの通信に必要な構成も管理します。アプリケーションをプッシュすると、PCF は必要なビルドパックを検出します。次に、アプリケーションがステージングされるビルドパックビットがインストールされます。

• Service Brokers –アプリケーションは、データベースからのサービスか、またはサードパーティ SaaS プロバイダからのサービスかによって異なります。servicebroker は、この接続を調整します。ServiceBroker がサービスインスタンスを提供すると、アプリケーションがそのインスタンスと通信できるようになります。インタラクションは、HTTP/s 経由により安全性が保たれます。

プラットフォームのコンプライアンスとセキュリティ対応セキュリティの問題では「急がない方がリスクが減る」が一般的な考え方ですが、Pivotal と当社のお客様は、実際は逆こそが真実であると考えています。システムの変更が速いほど、侵入がより困難になる-これが、クラウドネイティブ・セキュリティの核となる考え方であり、PCF では、「デフォルトでセキュア」が重要とされます。このような機能は、一般的なコンプライアンスやセキュリティ要件への対応に際して銀行をサポートします。

• 認証 –ユーザーアカウントおよび認証サービス（UAA）は、PCF 用のアイデンティティ管理サービスです。これはOAuth2 プロバイダで、PCF ユーザーに代わってクライアントアプリケーションが動作する際に使用するトークンを発行します。UAAは、ログインサーバーと連携し、PCF 認証情報によってユーザーを認証します。この認証情報（またはその他）を使用して、シングルサインオン（SSO）を実行します。UAAには、ユーザーアカウント、およびOAuth2 クライアント登録などのその他の機能を管理するためのエンドポイントがあります。

• BOSH –BOSH は、PivotalCloudFoundry と関連サービスをデプロイします。ライフサイクル全体にわたり、クラウドソフトウェアの管理を統合します。BOSHは、数百の VMに対してソフトウェアをプロビジョニングしデプロイすることが可能です。また、モニタリング、障害回復、およびゼロダウンタイムから最小ダウンタイムでのソフトウェアのアップデートも実行します。BOSHは、多くの「不変インフラストラクチャ」コンセプトをサポートしています。これにより、クラウドネイティブ・セキュリティの次の 2つの重要な要素が実行可能になります。

https://content.pivotal.io/blog/supercharging-your-scale-cube-caching-microservices-on-pivotal-cloud-foundry

http://docs.pivotal.io/rabbitmq-cf/index.html

https://network.pivotal.io/

http://docs.pivotal.io/pivotalcf/1-10/console/index.html

https://docs.pivotal.io/pivotalcf/1-10/buildpacks/index.html

http://docs.pivotal.io/pivotalcf/1-10/services/overview.html

http://docs.pivotal.io/pivotalcf/1-10/concepts/architecture/uaa.html

https://docs.pivotal.io/p-identity/1-9/

https://bosh.cloudfoundry.org/docs/about.html

pivotal.io




ϐ 修復 –脆弱性があるソフトウェアを、アップデートが利用可能になると直ちに修復します。

ϐ 更新 –既知の良好な状態にサーバーやアプリケーションを更新します。これは頻繁に行われます。マルウェアは、脆弱性のあるソフトウェアや、静的で更新されないシステムを脅かします。環境を頻繁に更新し、マルウェアが侵入しやすい状況を終わらせてください。BOSH を使用すれば、最小限の手作業でダウンタイムなく、環境を１日に数回デプロイすることが可能になります。

• 広範囲にわたるエレメントの CVE、パッチ、アップデート–Pivotal では、定期的に PCF コンポーネント、基盤のOS、ミドルウェア、サードパーティの依存関係にパッチを適用します。Pivotal のセキュリティチームは、「high（高）」または「critical（重大）」の CVE を特定すると、48 時間以内に修正します。これらのアップデートは、OpsManager と他のツールを使用して適用することができます。多くの場合、ダウンタイムはありません。詳細は、https://pivotal.io/security を参照してください。

• REST でのデータの暗号化–この要件は、デプロイしたストレージのネイティブな暗号化機能によって行われます。AWSへのデプロイについては、OpsManagerDirector が暗号化を有効にできます。

• 移行中のデータの暗号化（IPsec Add-on）–IPsecAdd-onforPCFは、PCFデプロイメントにおける移行中の IPデータを暗号化します。このモジュールは、悪意のあるアクターがファイアウォールを侵害した場合に内部システムを保護します。

• Isolation Segments–IsolationSegments は、アプリケーションセットを特定のホスト VMセットに指定します。これにより、アプリケーションとそのデータを他のワークロードから隔離します。この構成には、規制およびコンプライアンスルールが必要となる場合があります。

• ロールベースのアクセス制御–PCF は、Org（組織）、Space（スペース）、Role（ロール）、Permission（権限）によって、エンタープライズアクセス制御をサポートします。この機能は、開発者と IT 運用担当者が適正なアクセスレベルを持つように連携して動作します。AppsManager はWebベースのツールで、ロールと権限の管理に役立ちます。

ϐ Org（組織） –組織は開発アカウントで、個人またはチームが使用します。コラボレータは、ユーザーアカウントを使用して組織にアクセスします。コラボレータは、組織のリソース割当プラン、アプリケーション、サービスの可用性、カスタムドメインを共有します。

ϐ ユーザーアカウント–ユーザーアカウントは、PCF インストレーションにおける個人を表します。ユーザーは組織内の異なるスペースで異なるロールを持ちます。

ϐ Space（スペース）–すべてのアプリケーションとサービスは、スペースの一部です。各組織には少なくとも1つのスペースがあり、スペースにはアプリケーション開発、デプロイメント、保守のための共有ロケーションがあります。各スペースのロールは特定のスペースにのみ適用されます。

ϐ Role（ロール）および Permission（権限）–ユーザーは 1つまたは複数のロールを持つことができます。これらのロールは、組織および組織内の特定のスペースにおけるユーザーの権限を定義します。

• SSL/TLS –SSL/TLS 証明書は、ElasticRuntimeデプロイメントへのHTTPトラフィックをセキュアなものにします。非HTTP トラフィックをセキュアにするには、ロードバランサまたはアプリケーションで、ルーティングを使用して TLS を終了します。

•「ゼロトラストモデル」–CloudFoundry のコンテナ間ネットワーキングによって、管理者は、ゼロトラストモデルを実装できます。ここでは、管理者はアプリ間インタラクションのためのネットワークポリシーを構築して強制することができます。これにより、ホワイトリスト・トラフィックが不要になり、プライベートアプリケーション内のパブリックルートを使用する必要がなくなります。このシナリオでは、すべてのネットワークが信頼できないものとされ、「信頼する」環境と「信頼しない」環境という旧来の IT 慣行から決別します。このようなセキュリティのプロビジョニングは、プラットフォーム内で構成されます。

https://pivotal.io/security

http://docs.pivotal.io/pivotalcf/1-10/customizing/cloudform-om-ebs-config.html

http://docs.pivotal.io/addon-ipsec/index.html

https://content.pivotal.io/blog/tutorial-using-isolation-segments-in-pcf-for-hub-and-spoke-isolation

http://docs.pivotal.io/pivotalcf/1-10/adminguide/securing-traffic.html

http://docs.pivotal.io/pivotalcf/1-10/adminguide/enabling-tcp-routing.html

pivotal.io




Spring Cloud Services

概要SpringCloudServices(SCS)forPCF には、SpringCloud プロジェクトのコンポーネント（SpringCloudNetflix、SpringCloudConfigなど）が含まれます。SCSは、PCFマーケットプレイスからサービスとして利用できます。SCSにより、ユーザーはこれらのコンポーネントを管理・保守する必要がなくなり、Pivotal が代わって管理・保守します。

SCS を使用して、コンフィグサーバー ,サービスレジストリまたはサーキットブレーカーダッシュボードサービスインスタンスをオンデマンドで作成します。ここから、これをバインドして使用することができます。そして、自身のマイクロサービスによる付加価値の向上に注力することが可能になります。

Config Server for Pivotal Cloud FoundryConfigServerforPCF は、外部アプリケーションの構成サービスです。すべての環境にわたるアプリケーションの外部プロパティを集中管理する機能を提供します。

ConfigServer は、アプリケーションがデプロイメントパイプライン（開発、テスト、本番）内を通過するにしたがって、その構成を管理します。開発者は、このプロセス中、実行するために必要なすべてをアプリケーションが持っていることを確認できます。ConfigServer は、ラベル付けされている環境固有の構成をサポートします。ユーザーは、Git などの多くのツールで構成内容を管理できます。また、今後、Vault（および Git と Vault の混在）もサポートする予定です。

図 2 – Config Server for Pivotal Cloud Foundry。

http://docs.pivotal.io/spring-cloud-services/1-3/index.html

http://cloud.spring.io/

https://cloud.spring.io/spring-cloud-netflix/

https://cloud.spring.io/spring-cloud-config/

https://cloud.spring.io/spring-cloud-config/

http://docs.pivotal.io/spring-cloud-services/1-3/config-server/

pivotal.io




Service Registry for Pivotal Cloud FoundryServiceRegistryforPCF は、NetflixEureka を基盤とするサービスディスカバリ・パターンを実装しています。これは、マイクロサービスベースのアーキテクチャの主要信条のひとつです。

各クライアントまたはサービスの手動での構成は困難で、多くの場合、本番での脆弱性の要因となります。その代わりに、サービスレジストリを使用して、登録されたサービスを動的に探して呼び出します。

図 3 – Service Registry for Pivotal Cloud Foundry。

最初は、サービスレジストリによるクライアントの登録です。クライアントは、ホストやポートなどのクライアント自身に関するメタデータも提供します。登録後、レジストリには、各サービスインスタンスからの定期的なハートビート・メッセージが送信されます。ハートビート・メッセージが継続的に送信されない場合、サービスレジストリはそのインスタンスをレジストリから削除します。

Circuit Breaker Dashboard for Pivotal Cloud FoundryHystrix ライブラリ（SpringCloudNetflix の一部）は、サーキットブレーカー・パターンを実装しています。CircuitBreakerDashboardforPCF は、アプリ内のサーキットブレーカーのメトリクスを可視化します。クラウドネイティブ・アーキテクチャは、多くの場合、多層の分散サービスから構成されています。

エンドユーザーは、これらのサービスに複数の呼び出しを含めることができます。低いレベルのサービスに障害が発生した場合、この障害はエンドユーザーまでカスケードし、他の依存関係のあるサービスに広がる可能性があります。また、障害のあるサービスへアクセスが集中することで、修復を困難にすることがあります。Hystrix サーキットブレーカーは、障害がカスケードしないように予防してくれます。また、障害の発生したサービスが正常に復旧するまで、フォールバック動作をします。

http://docs.pivotal.io/spring-cloud-services/1-3/service-registry/

http://docs.pivotal.io/spring-cloud-services/1-3/service-registry/resources.html

https://github.com/Netflix/Hystrix

https://cloud.spring.io/spring-cloud-netflix/

http://docs.pivotal.io/spring-cloud-services/1-3/circuit-breaker/

http://docs.pivotal.io/spring-cloud-services/1-3/circuit-breaker/

pivotal.io




図 4 – Circuit Breaker for Pivotal Cloud Foundry。

サーキットブレーカーは、サービスに適用されると、サービスの呼び出しに障害がないかを監視します。障害が特定のしきい値に達すると、サーキットを「Open」にします。サーキットブレーカーは、呼び出しを特定のフォールバック機能に自動的にリダイレクトします。これにより、障害のあるサービスに復旧までの時間が与えられます。サーキットブレーカー・ダッシュボードは、一連のクラウドネイティブ・サービスにあるすべてのサーキットブレーカーの動作を可視化します。

pivotal.io




リファレンスアーキテクチャ：論理インフラストラクチャこのアーキテクチャは、Pivotal 製品の基礎となるデプロイの模擬となります。

論理インフラストラクチャ：VMware vSphere と NSX を使ったオンプレミス環境

このアーキテクチャは、オンプレミスでホストされているセキュアな PCF 基盤で、約 1,500 個のアプリケーションインスタンス（AI）をホストできるインストレーションを示しています。図 5には、一般的な管理サービス、MySQL、RabbitMQ、SpringCloudServices が含まれています。

この図には、3つのクラスタが表示されています。各クラスタにはリソースプールがあり、PCF は OpsManager を介してこれらのプールにデプロイされます。1つのクラスタにつき1つのプールとなります。コアとなるネットワークは、以下のサブネットのあるNSXEdge を介して作成されます。

• インフラストラクチャ（PivotalCloudFoundryOpsManager および BOSH用）

• ERT（PivotalCloudFoundry の ElasticRuntime 用）

• サービスタイル（MySQL、RabbitMQ、SpringCloudServices などの PCF マネージドサービス用）

• ダイナミック・サービスタイル（BOSHDirector によってすべてが管理されているネットワーク）

インターネット

クラスタ 01 クラスタ 02

ストレージ層：VMFS/NFSボリューム

クラスタ 03

タイルタイルタイル

動的サービス

動的サービス

動的サービス

タイルタイルタイル

動的サービス

動的サービス

動的サービス

ファイアウォールロードバランサ

NAT / SNAT

ルートされたバックボーン

ファイアウォールロードバランサ

NAT / SNAT

A本番データストア

B本番データストア

PCF “A本番”

PCF “B本番”

図 5 – NSX を備えた VMware vSphere 上の Pivotal Cloud Foundry に対する論理リファレンスアーキテクチャ。クラスタを 3 つとしたもの。

pivotal.io




このモデルは、1つまたは複数の PCF インストレーションをデプロイする際の代表例です。vSphere レベルでのキャパシティの増加や強固なインストレーションセキュリティをサポートします。

ここでは、2つの PCF インストレーションが同一の vSphere 容量を共有しています。リソースプール（点線の長方形）がインストレーションを分割しています。この「sharedyetsegmented（共有しながら分割する）」アプローチは、多数の PCF インストレーションに合わせて拡張可能です。管理者は、必要に応じて特定のインストレーションに優先順位を割り当てることができます。これは、プールレベルで適用されている「shares（シェア）」を使用して行います。例えば、重要なインストレーションには「highshares（高いシェア）」、重要ではないものには「lowshares（低いシェア）」とします。

コンピューティング各クラスタには、少なくとも 3個の ESXi ホストがあります（デプロイメント全体では最小 9個のホスト）。すべてのインストレーションが、集約的に同じ9個のホストから展開されます。垂直に拡張するには、プールとPCFインストレーションを追加します。水平にスケールするには、既存のクラスタにホストを追加します（3個のセット、1個のクラスタにつき 1個）。すべてのインストレーションが、追加処理能力へのアクセスを得られます。

VMwareのベストプラクティスは、vSphereHAの使用で、3個以上のクラスタにホストをデプロイすることです。リソースプールの有効化と自動 vMotion の許可には、vSphereDRS が必要です。

ストレージ一般的なアプローチの２つに 1つは、システムがホストにストレージを付与しています。• データストアがすべてのホストに与えられ、一度に1つのサブネットが1つのインストレーションに提供されます。

• データストアはホストクラスタに一意的に付与され、各インストレーションは複数のデータストアを使用して各クラスタに VMを保存します。

推奨されるデータストアのサイズは、データストア 1つにつき 8TB、PCF インストレーション 1つにつき 2つのデータストアです。この数値より少し大きな容量を使用することも可能です。追加されているタイルの数が少ない小さなインストレーションでは、この数値より小さくすることもできます（PCF1 つにつき 4TBx2 が適当です）。

vSphere データストアがストレージ DRS（sDRS）を使用する vSphere ストレージクラスタの一部である場合、このsDRS機能は、PCFの使用するデータストアでは無効にする必要があります。無効にしないと、管理されている独立型ディスクの名前変更の際に、StoragevMotion アクティビティによって BOSHに不具合が生じる可能性があります。

推奨されるストレージタイプは、ブロックベース（ファイバーチャネルまたは iSCSI）およびファイルベース（NFS）などで、6GFC や 10GigE などの高速キャリアが理想的です。PCF が使用する「persistent（永続的）」ストレージタイプには、冗長ストレージが強く推奨されます。「ephemeral（一時的）」ストレージタイプには、DASD または JBODを使用することもできます。

ネットワーキング図 5のモデルは、VMwareNSXSDN（ソフトウェア・デファインド・ネットワーキング）を示しています。このオプションでは、vSphere上のPCFインストレーションに独自のメリットがあります。NSXの使用は必須ではありませんが、強く推奨されます。NSX によって、PivotalCustomer0repo に記載されているように、多くのパワフルな要素が追加されます。

ネットワーク設計各 PCF インストレーションは、図 5のように、NSXEdge からのネットワークを 3つ以上使用します。これらは、特定のジョブに応じて調整されます。

• インフラストラクチャ–このネットワーク上で動作している IaaS レイヤと通信しているリソース。CIDR レンジは大きくありません。これは、「内向き」なネットワークで、OpsManager、BOSH、その他のユーティリティVM（ジャンプボックス VM）が接続されます。

https://github.com/c0-ops/landingpage/blob/master/vsphere/refarch-main.md

pivotal.io




• デプロイメント–「アプリワイヤ」と呼ばれるこのネットワークは、アプリケーションおよび関連コンポーネントのデプロイで特に ERT タイルによって使用されます。CIDR レンジは大きくなっています。

• CF タイル–PCF デプロイメントは、多くの場合、複数のサービスネットワークを有しています。各サービスネットワークは、CIDR レンジが大きく、OpsManager を介して BOSH によってホストおよび管理されている他のインストレーションとともに使用されます。シンプルなアプローチは、このネットワークを ERT 以外のすべてのPCF タイルに使用することです。さらに複雑なアプローチでは、複数の「Services-#」ネットワークをデプロイします。各タイルには 1つです（または各タイルタイプに 1つ）。

• 動的サービス–BOSHDirector に付与されている単一ネットワークで、デプロイメントの動的アドレス空間が必要なサービスタイルと使用されます。これは、vSphere タイルでチェックボックスに「Services（サービス）」とマークされる唯一のネットワークです。

これらすべてのネットワークは、「inside（インサイド）」または「tenant-side（テナントサイド）」のネットワークとして認識されます。これらは、ルーティングできない RFC ネットワークスペースを使用して、プロビジョニングの繰り返しを可能にしています。NSXEdge は、SNAT と DNAT を使用して、テナントサイドとサービスプロバイダサイドのネットワーク間を変換します。

その他のガイド：VM vSphere によるオンプレミスこのリファレンスアーキテクチャに関する詳細なガイドは、PivotalCustomer0Githubrepo を参照してください。この Repo では、非NSX 環境でのコンフィグレーション情報も提供されています。

リファレンスアーキテクチャ：パブリッククラウドの論理インフラストラクチャPivotalCloudFoundry はマルチクラウド・プラットフォームで、複数の IaaS ターゲットにわたるポータビリティを提供します。一般的なパブリッククラウドのリファレンスアーキテクチャは、以下のリンクからご利用いただけます。

• PivotalCloudFoundry&AmazonWebServices

• PivotalCloudFoundry&MicrosoftAzure

• PivotalCloudFoundry&GoogleCloudPlatform

マルチクラウド：最適なクラウドプロバイダを容易に使用可能多くの銀行がマルチクラウド戦略を実行したいと考えています。このアプローチは、オンプレミス・インフラストラクチャの使用と選択したパブリッククラウドを組み合わせます。多くの顧客にとって理想的な状況とは、複数アプリケーションが他のスタックと同じように容易に 1つのスタック上で動作できることです。

これは、PivotalCloudFoundry の基本的なコンセプトです。この製品は、大きな再作業をせずにインフラストラクチャターゲット間でアプリケーションを移動するという、アプリケーションのポータビリティの実現を目指しています。

企業にとっては PCF が抽象化層であると考えることができます。購入担当者は価格、性能、場所、先進機能を元にしてインフラストラクチャを選択できます。どこでも自由に PCF をデプロイし、図 6で示されているように、各 IaaS ターゲットの独自の属性をフル活用してください。

https://github.com/c0-ops/landingpage/blob/master/vsphere/refarch-main.md

https://github.com/c0-ops/landingpage/blob/master/aws/refarch-main.md

https://github.com/c0-ops/landingpage/blob/master/azure/refarch-main.md

https://github.com/c0-ops/landingpage/blob/master/gcp/refarch-main.md

pivotal.io




Example Application

Services

DynamoDB

Event Hubs

Machine Learning

AWS Service Broker

GCP Service Broker

Azure Service Broker

Single Sign-On for PCF

Pivotal Cloud Foundry Metrics

Pivotal Cloud Foundry Log Search

Spring Cloud Services for PCF

Pivotal Cloud Foundry Elastic Runtime

Pivotal Cloud Foundry Operations Manager

クラ

ウド

プロ

バイ

ダイ

ンタ

ーフ

ェー

ス

Application A

Application B

Application C

Application D

図 6 - Pivotal Cloud Foundry は、複数のクラウドプロバイダ間のポータビリティをサポート。また、特定のプロバイダにデプロイされたアプリケーションは、そのプロバイダ独自のサービスを使用することも可能です。

ハイブリッド環境における考慮事項銀行において、もっとも一般的なハイブリッド環境の考慮事項は何でしょうか？それは、オンプレミス・データセンターの拡張として、パブリッククラウドを使用することです。アプリは、オンプレミスでマルチテナントの、弾力性のあるインフラストラクチャで動作します。管理者は、パブリッククラウドでファイアウォールのルールを構成します。これによりアクセスが制限され、特定の IP レンジ（コーポレートネットワークのもの）のみがアプリにアクセスできます。

以下は、このシナリオにおける４つの考慮事項です。

1 データレプリケーション

ハイブリッドアーキテクチャを設計する際に最も考慮すべき点はデータです。何より、ほとんどの規制やコンプライアンス基準は、データの取り扱いに対して適用されます。

従来のシナリオは、プライマリサイトとセカンダリサイトに注意を向けています。システムはプライマリ・データセンターからセカンダリロケーションに定期的にデータベースのログを送信します。

しかし、Pivotal のほとんどのお客様は、もっと違うもの、もっと強力なもの、つまり、双方向のデータレプリケーションを求めています。この場合、システムは、サイト間でほぼリアルタイムでデータのレプリケーションを行います。両方のサイトがトラフィックに対応し、リクエストを処理します。このアプローチにより、アプリケーションの信頼性と回復力が向上します。

PivotalCloudFoundry のお客様は、これをインメモリ・データグリッドの PivotalCloudCache（PCC) で実現しています。変更が発生すると、PCC はレプリケーションキューにイベントを作成して、他のサイトに送信します。イベントは、ユーザーの指定した間隔（「5秒毎」など）でレプリケートしたり、定義された数の後（「1000 イベント毎」など）でレプリケートしたりすることができます。PCC は、送信前にイベントを圧縮および暗号化します。他のサイトで受信されると、そのデータは解凍および復号されます。

クラスタは、読み取り /書き込みのオペレーションのいずれも実行できます。PCC は、重複排除と競合解消を行います。

pivotal.io




これは、複数のロケーション間の 100%のデータ冗長性を確保する重要な機能です。

サイト1

データレプリケーション

サイト2

マイクロサービス

データストアデータストア

マイクロサービス

図 7 – Pivotal Cloud Foundry と Pivotal Cloud Cache による 2 つのサイト間のデータレプリケーション。

2 サイト選定のルーティング

パブリッククラウドと自身のデータセンターでアプリケーションを実行している場合、トラフィックをどのようにルーティングしますか？ PivotalCloudFoundry のお客様は、次の 2つのオプションから選択しています。

• 毎回自社のデータセンターを経由：このシナリオでは、トラフィックはユーザーの既存のグローバル・トラフィックマネージャを通過します。管理者は、カスタムルールに基づいてルーティングポリシーを作成します。これらのポリシーは、オンプレミスとパブリッククラウドといずれかの適切なサイトにリクエストを送ります。次に、管理者は、データセンターからパブリッククラウドへのトラフィックのみを許可するファイアウォールのルールを構築します。これらのルールは、企業のパブリッククラウドインスタンスへの他のすべてのトラフィックをブロックします。このハイブリッド設定には、データセンターとパブリッククラウド・サイト間に高速の専用接続が必要です。データは通常、オンプレミスサイトから送られてくるということにご注意ください。他のアプリケーション要素は、高い弾力性を得られます。

• パブリッククラウド・ノードと自社データセンター間のトラフィックを平衡：このオプションでは、DNS ルーティングまたはサードパーティのグローバル・ロードバランシングサービスを使用します。PivotalCloudFoundry は、このシナリオに容易に対応します。2つの PCF 基盤をデプロイしてそれぞれを構成し、希望するポリシーと連携させます。

pivotal.io




3 Active/Active か、Active/Passive か？

これらの用語は、聞き手によって意味が異なります。このホワイトペーパーでは、Active/Active 構成をリアルタイムの高可用性（HA）と定義します。Active/Passive は、継続性または可用性にある程度の遅れが許容される構成です。

Active/Active 構成の実現における主要な障害の 1つは、データセンター間の待ち時間です。分散トランザクションでは待ち時間が発生しますが、可能な限り回避する必要があります。データにローカルでアクセスし、単一のDCでリクエストを解決します。データ分割によっても待ち時間を低減することができます。ただし、この場合は、他の問題もあります（継続性や、競合解消で誰を信用するかなど）。

アプリケーションレベルでのHAパターンに関する詳細は、複数のサイト間での高可用性に関する考慮事項を参照してください。

Active/Passive 構成は比較的容易です。パッシブなサイトは、データレプリケーションセクションで述べたように、X秒または Yイベント毎にアップデートされます。アクティブなサイトがダウンした場合は、パッシブロケーションにトラフィックを再ルーティングするだけです。

4 デプロイメントのオーケストレーション

継続的デプロイは、デジタル時代における 3つの重要なコンセプトの 1つです。異なるターゲット間に非同期アプリをデプロイする際は、CI/CD ツールおよびプロセスを検証する必要があります。Concourse や Spinnaker のようなシステムは、このユースケースには特に適しています。

データベース・スキーマの変更を記録することは、非常に重要な考慮事項です。スキーマのバージョンが整合していないと、レプリケーションエラーやイベントのミスマッチが発生します。データベースのバージョンを同時にアップしたり、ロールバックすることができるようになります。

http://www.slideshare.net/Pivotal/the-five-stages-of-cloud-native

http://concourse.ci/

http://www.spinnaker.io/

pivotal.io




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

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

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

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

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

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

pivotal.io




リファレンスアーキテクチャのコンポーネント• 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 のようなシステムは、受信したメッセージを即時に削除します。

複数サイト間での高可用性に関する考慮事項ハイブリッドの考慮事項では、高可用性の要素をいくつか確認します。メッセージングミドルウェアとイベント駆動型アーキテクチャの使用は、アプリケーションレベルで高可用性（HA）に対応します。

分散アーキテクチャは、アプリケーションサービス間の非同期メッセージ駆動型通信の上に成り立ちます。これは、クラスタ間のトラフィックに膨大な帯域幅を必要とする従来の同期システムとは対照的です。

図 8のイベントストアは、複数のサイトにイベントを送信するよう構成することが可能です。では、さまざまな場所にあるサービスを探して使用するにはどうしたらよいのか、確認してみましょう。

pivotal.io




サービスレジストリによるピアレプリケーション図 9に示されている、金融サービス組織における実世界の最新ユースケースを考えてみましょう。この銀行は、複数の org（組織）と space（スペース）にわたって多数のサービスがデプロイされています（セキュリティセクションで確認した権限モデルの一部）。これらのサービスを使用するには、銀行全体を探す必要があります。管理者は、どのPCF 組織やスペースかにかかわらず、アプリケーションでこれらのサービスを使用したいと考えています。サービスレジストリのピアレプリケーションによって、アプリケーションはスペースの認証モデル内で管理でき、サービスには、組織間のアクセスを制御しながらアクセスすることができるようになります。

西部PCF 西部PCF

サービスレジストリ

サービスレジストリ

ピアレプリケーション

図 9 – サービス登録に対する複数サイトのピアレプリケーション。

サービスレジストリのピアレプリケーションは、複数の PCF インストレーション間で機能します。また、単一のPCF インストレーション内の複数組織間でも機能します。上の図は、2 つのサイト間における単純なサービスレジストリのピアレプリケーションを表しています。西部 PCFデータセンターを見ると、ローカルのサービスレジストリは、青色のサービス Aと Cを登録しています。これらのサービスは、東部データセンターでも参照することが可能です。逆に、西部 PCF のサービスも同様です。東部 PCFのサービスレジストリは、薄緑色のサービスをローカルで登録し、西部 PCF で参照できるようにします。

ピアレプリケーションを有効にすることで、開発チームと運用チームは以下のようなメリットを得られます。

• 部分的な障害発生時のマイクロサービスの可用性向上

• ネットワークの境界をまたぐロードバランシング

• 異なる PCF インストレーションまたは組織間のサービスの確実な検出

このシナリオに関する詳細（サンプルコードを含みます）は、Pivotal ブログでご覧いただけます。

Ribbon によるクライアントサイドでのロードバランシング複数サイトでのデプロイの場合、図 8の Edge Gatewayは、クライアントサイドのロードバランサによって強化できます。これにより、開発者は、HTTP クライアントと TCP クライアントの動作を制御することができます。Pivotal のお客様は、これを実現するために、Spring の NetflixRibbon プロジェクトを使用しています。

Ribbonは、集中型ロードバランサへの負荷を低減します。また、クライアントサイドのロードバランシングを使用して、マイクロサービス・リクエストの送信先に関して最適な決定をします。Ribbon はサービスレジストリと統合し、各クライアントがランドスケープを正確に把握できるようにします。

https://content.pivotal.io/blog/new-in-spring-cloud-services-1-2-multi-site-service-discovery

https://spring.io/guides/gs/client-side-load-balancing/

pivotal.io




ここで、複数サイトから構成される PCF 環境に Ribbon をデプロイする方法を見てみましょう（図 10）。

ロードバランサ

API(エッジ)サービス(インスタンス1, ゾーンA)

Ribbonクライアント(サービスX)

Ribbonクライアント(サービスY)

Ribbonクライアント(サービスX)

Ribbonクライアント(サービスY)

サービスY)(インスタンス2)

[ゾーンB]

サービスY)(インスタンス1)

[ゾーンA]

サービスX)(インスタンス3)

[ゾーンC]


[ゾーンB]


[ゾーンA]

API(エッジ)サービス(インスタンス2, ゾーンB)

サービスレジストリクライアント

サービスレジストリクライアント

図 10 - マルチサイト PCF 環境での Ribbon のデプロイメントトポロジー。

ロードバランサは、パブリックトラフィックに対応します。内部の中間層のリクエストは、Ribbon フレームワークを介して処理されます。サービスレジストリは、アプリケーションのサービスを登録します。ベストプラクティスは、各ターゲットサービスに Ribbon のクライアントを作成して構成することです。Ribbon のクライアントには、優れた構成オプションが用意されています（接続タイムアウト、再試行、再試行アルゴリズムの選択など）。

pivotal.io




リファレンスアーキテクチャ：顧客向け銀行アプリケーションのサンプル

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

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

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

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

データソース 1.入口

2.検証

3.濃縮

5.イベントストア

6.エラー

イベントストア

7.監査

8.問合せ可能

データ

9.検索可能

インデクス

UIビジネス

運用担当者運用担当者

10a. 15.UI運用管理

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

10c.回復ポジション

スケジューラ

データ取得検索

11.発行

LDMトランスフォーマ

分散プラットフォーム

4.ルールベースの

濃縮

到着したストリーム

検証されたストリーム

変換されたストリーム

集合ストリーム

派生したストリーム

変換されたストリーム

トランスフォーマ

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

凡例

リクエスタサービスアクティベータ

サービス

サービスサービス

サービス

JMSキュー

Kafkaチャネル

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

ビジネス固有サービス

共有サービスRESTエンドポイント

図 11 – Spring Cloud Stream を基盤とするデータ取得のためのリファレンスアーキテクチャ。

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

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

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

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

pivotal.io




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pivotal.io




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

PCF プラットフォームサービス一方で、PCF は根底となるインフラストラクチャとランタイムの依存関係を管理します。プラットフォームは、以下の重要な要素にも対応します。

• Config Server –ConfigServer は、サンプルアプリの外部構成プロパティを管理します。

• Service Registry –ServiceRegistry は、サンプルアプリのマイクロサービスでサービスディスカバリを実行します。これは、サンプルアプリに登録されたサービスを動的に検出して呼び出します。

• Circuit Breaker Dashboard –サンプルアプリには、分散しているサービスの複数のレイヤがあります。Hystrixライブラリ（SpringCloudNetflix の一部）は、サーキットブレーカーパターンを実装しています。また、障害の発生したサービスが正常に戻るまで、フォールバック動作をします。CircuitBreakerDashboardは、アプリ内のサーキットブレーカーのメトリクスを可視化します。

• App Autoscaler –AppAutoscaler は、このサンプルアプリに合わせてキャパシティを自動的に調節します。調節は、カスタムのトリガとしきい値にしたがって行われます。このサービスは、CPUの使用、HTTP レイテンシー、HTTP スループットに基づきインスタンスを追加または削減します。

次のステップこれまで、PivotalCloudFoundryの最適なデプロイ方法とSpringCloudServicesの適用方法を説明してきました。では、次のステップに進みましょう。

pivotal.io にアクセスし、PivotalWebServices の無料体験版をお試しください。また、PivotalCloudFoundry の無料ローカルエディションもダウンロードいただけます。このエディションには、PCFDev と呼ばれる SpringCloudServicesも含まれています。マイクロサービスのデリバリ改善に Pivotal をぜひお役立てください！

さらに支援が必要ですか？ Pivotal では、お客様のような企業に、アーキテクチャに関するアドバイスやコンサルティングをご提供します。

Pivotal は、組織がアプリケーションのリプラットフォームを評価・実行するお手伝いをしています。また、お客様に代わって、作成されたアプリケーションオンプラットフォームの運用も行います。Pivotal のソフトウェア、サービス、経験は、さまざまな業界のあらゆる規模の企業（大企業からスタートアップ企業まで）から高い信頼を得ています。当社は、クラウドを導入する前から導入後に至るカスタマージャーニーを先導します。

• Pivotal と共に対象とするアプリケーションを特定し、ビジネスに必要な労力とメリットのトレードオフを可能にするリプラットフォームを実現しましょう。

• PivotalLabs のアプローチをぜひご活用ください。当社のアプローチは、アジャイル開発手法を採用しており、これまでは価値を生み出すまでに数か月にわたるポートフォリオ分析を必要とするのに対して、わずか 10 週間のスプリントで繰り返し、結果をもたらします。

• 12FactorsApp の中で、クラウドでアプリケーションを実行できるようになる前に最低限対処すべき要素を迅速に見つけ出します。

• Pivotal と連携して、モノリシックアプローチ内で抽出可能な範囲を特定します。そして、クラウドネイティブデザインをフルに活用する必要のあるアプリケーションをリプラットフォームするにあたり、段階的に移行することでビジネスへの価値をつなげて維持します。

• PivotalCloudFoundry でアプリケーションをデプロイし管理してください。PivotalCloudFoundry は、価値実現までの時間を短縮する当社のクラウドネイティブ・プラットフォームです。

今すぐお問い合わせください。すぐ始めましょう！

http://docs.pivotal.io/pivotalcf/1-10/appsman-services/autoscaler/using-autoscaler.html

https://pivotal.io/

http://pivotal.io/contact

pivotal.io




付録 A：なぜクラウドネイティブなのか？クラウドネイティブが重要な理由

クラウドネイティブ・ジャーニーにようこそ

付録 Aは、MichaelCoté が投稿した Pivotal ブログからの引用です。

ソフトウェアは世界をどのように飲み込んでいくのか？Pivotal のお客様の多くは、クラウドネイティブ企業になろうとしています。これは、いかに多数の企業が変革を行い、カスタムソフトウェアを使用してビジネスを行っているかを目撃する機会を当社に与えてくれました。

このような企業のそれぞれが、ソフトウェアが定義するビジネスとなる必要性、つまり、ビジネスの方法を破壊するような俊敏性、クラウド、データ、デバイスの使用を求める「シリコンバレー」からのプレッシャーに立ち向かっているのです。このプレッシャーについての詳細は他でも取り上げているため、私は、このような企業がどのように変化し、何を実行しているかについて、主要な情報を集め始めました。このコンセプトは、しばしば「旅 ( ジャーニー )」と呼ばれます。「ジャーニー」という言葉は、「大変な努力と時間がかかる。一夜にして成功はしない」ということを婉曲的に意味しています。同様に、自分の家を建てることや子供を育てることも「ジャーニー」です。簡単な答えなどありません。「うまくいかない」ことも多々あります。しかし、継続的に学習し改善するプロセスを設定することによって問題解決につながり、その結果、カスタムメイドの家ができあがり、子供はしっかりとした大人に成長するのです。

それでは、この記事では最初に、子供が刑務所に入らないようにするために、PivotalCloudFoundry のお客様が何を実行しているかをご説明しましょう。第 1に、目標を大まかに話し合います。企業がクラウドネイティブになりたいと考える理由です。第 2に、Pivotal がよく遭遇する 3つの組織タイプと、これらの組織がクラウドネイティブ戦略をどのように策定しているかをご紹介しましょう。このシリーズの今後の記事では、技術的および構造的な問題と、どのようにこれらの問題に対処するか、そしてクラウドネイティブジャーニーのその他の側面を見ていきます。この概要が、「ジャーニー」はなぜ重要なのか、どのようなものか、そしてクラウドネイティブ企業になるためのジャーニーをどのように計画していくかについて、理解の助けとなれば幸いです。

目標：品質向上とビジネス拡大のためのサイクルの短縮Pivotal のお客様は、PivotalCloudFoundry を使用して、組織内の IT 活用方法を改善したいと考えています。ビジネスと顧客体験を実施し改善するには、お客様は、独自のソフトウェアの作成と管理に優れていなくてはなりません。このために、新しいアイデアの発案から本番環境での稼働にいたる開発まで、ソフトウェアのライフサイクルの質を向上させようとしています。Allstate の AndyZitney 氏が述べたように、彼らの目標は、新しいソフトウェアのアイデアを月曜日に思いつき、金曜日には本番環境で稼働させることです。

https://blog.pivotal.io/pivotal-cloud-foundry/features/welcome-to-your-cloud-native-journey-part-1

https://blog.pivotal.io/pivotal-cloud-foundry/p-o-v/the-three-horsemen-of-the-digital-apocalypse-considered

https://hbr.org/2010/07/how-will-you-measure-your-life

https://blog.pivotal.io/pivotal-cloud-foundry/features/mapping-the-cloud-native-journey

pivotal.io




簡単に言えば、私がよく使用する図に示すように、ソフトウェアのデリバリサイクルをスピードアップすることを目標としています。

継続的デリバリのパイプライン

コードバージョン管理

フィードバックループ

ビルドテスト/検証リポジトリへのパッケージ

インフラプラットフォーム本番の課題

(モニタリング、スケーリング等)

目標は、安全で信頼のおける方法で、できるだけ迅速にパイプライン上にコードを流してゆくことです。よい目標は毎週ですが、小さなバッチを習得し、必要なプロセスと技術を活用できれば、毎日のデプロイを目指すこともできるでしょう。

これが、あなたの組織の短中期的目標として掲げるべきゴールです。つまり、新しい機能を本番環境で稼働させるまでにかかるサイクルタイム全体を短縮することです。長期的目標は、ソフトウェアのデリバリプロセスの品質を向上

させるだけでなく、ビジネスの質も向上させることです。

https://blog.pivotal.io/pivotal-cloud-foundry/p-o-v/continuous-delivery-among-the-donkeys

pivotal.io




付録 B：夜眠れない理由：銀行エディションクラウドネイティブのパターンとプラクティスは、高品質なソフトウェアのリリースの迅速化に役立ちます。これは、あなたの企業が市場で優位に立つためにも有用です。このような方法を銀行にどのように適用したら良いのでしょうか？優れたソフトウェアは、どのような機会、課題、脅威への対応をサポートしてくれるのでしょうか？

Pivital のこれまで経験から、4つの主要領域を特定しました。

業界のトレンドクラウドネイティブのメリット

消費者の期待の高まり。消費者は、財務情報に常にアクセスしたいと考えています。多様なデバイスで、財務状況をリアルタイムに配信してほしいのです。また、セルフサービスによるオンラインバンキングも望んでいます。これは、銀行、特に、スタックの至るところで旧来の技術に頼っている銀行にとっては大きな課題です。投資銀行は、このような課題の多くに直面しています。

クラウドネイティブ・アプリケーションでは、最優先事項は API ファーストの設計です。開発者は、多くのデバイスにわたるユーザーに機能を提供します。優れた API は、サクサク動くユーザー体験も実現します。

フィンテックによる競争の拡大。ソフトウェアが、金融サービス業界を飲み込んでいます。スタートアップ企業は、彼らのソフトウェアの強みを生かして、市場シェアを獲得しつつあります。スタートアップ企業は、顧客からのフィードバックに基づき、迅速に改善できます。このようなスタートアップ企業は、既存の企業に比較して、多くの強みがあります。その一部は、優れた企業文化とリーンなプロセスがあること、そして技術的負債がないことです。Pivotal は、過去 5年の間、多くの業界でこのような破壊パターンが繰り広げられるのを目にしてきました。そして現在、金融サービスでも同じことが起こっています。

ソフトウェア定義型のビジネスになるためには、次の 3点が重要です。第 1に、マイクロサービス・アーキテクチャです。これは、スピーディーな反復と、システムの個別コンポーネントへの小さな変更を促します。次に、継続的デリバリーにより、開発者は本番稼働まで摩擦なく進めることができます。これは、経時的に大きなメリットをもたらす小さな変更の頻繁なデプロイメントにつながります。最後に、DevOps 文化は、従来型の開発者/IT運用担当者ロールと目的を回避します。その代わりに、顧客の価値を実現することが目標とされます。

規制要件とコンプライアンス。IT システム、プロセス、アプリケーションは、業界の規制やコンプライアンス基準の変化に対応しなくてはなりません。これには、多大な時間、注意、予算が必要です。

クラウドネイティブなアプローチは、自動化と、設計時の「セキュリティファースト」アプローチを重視します。これらの 2点は、コンプライアンスには極めて重要です。高度に自動化されたシステムでは、アクティブにログが記録されます。何がいつ変更され、誰がアップデートをトリガしたのかを容易に確認することができます。さらに自動化されたシステムでは、迅速にパッチをあて、頻繁に新しくアップデートすることができます。一般的に、自動化されたシステムでは、毎日人が関与する必要性が大幅に軽減されるため、セキュリティも高くなります。

「セキュリティファースト」とは、エンジニアが最初から機能にセキュリティをデザインすることを意味します。これらは、後で追加されるのではありません。

セキュリティ。脅威のランドスケープは、常に進化および変化しています。銀行は、マルウェア、持続的標的型攻撃（APT）、認証情報の漏洩をするスペクターと戦わなくてはなりません。

企業のセキュリティサークル内における従来の知識によると、「ゆっくり実行しリスクを減らす」ことがアドバイスされます。しかし、クラウドネイティブな世界では、「迅速に行動してリスクを減らす」ことが重要です。なぜでしょうか？頻繁に変更されるシステムは、マルウェアや他の脅威に対する脆弱性がはるかに小さくなります。変化のない環境では、悪意のあるアクターが活発になり、企業に大きな損害をもたらします。

自動化を使用して、最新のパッチをシステムに適用してください。不変インフラストラクチャの概念を取り入れ、スタックを「最後の既知の良好な状態」に頻繁にリデプロイしてください。そして、認証情報を頻繁にローテート（変更）させ、漏れた認証情報の有効期限がすぐに切れて価値の無いものとなるようにしましょう。

pivotal.io




クラウドネイティブなプラクティスによって、より迅速に新しい市場機会から収益を得ることが可能になります。コンプライアンスは、高度に自動化されたアプリケーションのデリバリと運用によって、より容易に実現できます。そして、不変インフラストラクチャのような概念によって、セキュリティ態勢を改善することも可能です。

あなたの組織と業界のライバルは、このような変革が不可欠であると認識しています。すなわち、最新の Forresterレポートは、次の 2 つの主要な発見を報告しています。

1. 金融サービス企業は、変革の必要性を最重要課題としました。大多数の金融サービス企業は、生き残るためには変革が必須であることを受け入れています。変革の取り組みを行っていると説明する企業が、かつてないほど増加しています。

2. 行動の遅い企業は、競争に生き残ることが困難になるでしょう。漠然とした変革プランしかもたない、またはまったくプランのない金融サービス企業は、デジタル化へのジャーニーを加速させる必要があります。プランのない低速なアプローチでは生き残りが極めて難しくなります。

このため、企業はクラウドネイティブ・エンタープライズになりたいと考えているのです。

1 Forrester Research, “The Path To Digital Transformation In High Speed Financial Services” , December 27, 2016

https://www.forrester.com/report/The+Path+To+Digital+Transformation+In+High+Speed+Financial+Services/-/E-RES133987

https://www.forrester.com/report/The+Path+To+Digital+Transformation+In+High+Speed+Financial+Services/-/E-RES133987

pivotal.io




付録 C： Pivotal の顧客は、クラウドネイティブに移行するために何をしているか？第一歩はプラットフォーム。

多くの企業が、チームが継続的にソフトウェアをデリバリできるように、セルフサービス・プラットフォームを採用しています。なぜでしょうか？

プラットフォームは、アプリケーションをデプロイし実行するうえで、継続的で予測可能かつ安全な方法です。プラットフォームは、統合セルフサービスモデルで重要な機能を開発者に提供します。

言い換えれば、プラットフォームは、非常に複雑な IT 機能群の雑多な詳細を隠し、チームが必要なすべての機能をシンプルかつ高い信頼性で提示します。各機能には、消費者が迅速でシンプルな方法でアクセスできます。

プラットフォームは、これらの機能を完全に自動化された直ちに使える状態で提供します。すべてのアプリケーションチームは、プラットフォームを各自で容易に使用できます。

プラットフォームは、規模の経済と同様です。1つのプラットフォームで実行するアプリが多ければ多いほど、組織にとって効率が高くなり、価値も上昇するのです。

組織が適切なクラウドネイティブ・プラットフォームで「allin（すべてを含む）」を選択すれば、全員に勝利がもたらされます。開発者、IT 運用担当者、財務チームすべてが、大きな収益を実現できるのです。

Pivotal のクラウドネイティブなプラットフォームが、世界中で最も高く評価されるブランドの数々においてソフトウェアイノベーションを促します。世界中のコミュニティにおける何百万もの開発者により、Pivotal の技術は毎日何十億ものユーザーに触れています。10 年以上にわたってシリコンバレー有数の企業でソフトウェア開発の文化を形成してきた Pivotal は現在、世界のソフトウェア開発の在り方を変える技術的な潮流を先導しています。

Pivotal、Pivotal Cloud Foundry、Pivotal Cloud Cache、および Cloud Foundry は、米国および / またはそのほかの国々におけるPivotal Software, Inc. の商標または登録商標です。本文書で使用されているその他のすべての商標は、各所有者の所有物です。

クラウドネイティブ アプリケーションに適した...

Documents

クラウドネイティブアプリケーションに適した...