2
アジェンダ
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
• マイクロサービスとは?
• 既存の仕組みをAPI化するには?
• マイクロサービス化のファーストステップ〜Data CentricからCapability Centricへの考え方へ〜
• CA Live API Creatorを利用したWeb API化
4
Microserviceとは?
• マイクロサービスとは限られた範囲の機能を持った独立したコンポーネントとして展開できそれぞれのマイクロサービスはメッセージベースの通信で相互に接続できることができる。
• マイクロサービスアーキテクチャとはマイクロサービスの特徴を有し高度に自動化された進化型のソフトウェア・システムの開発手法・スタイル。
Web API
NetflixやAmazonなどに代表される先進的なIT企業が要求されるビジネススピードに対応するために考え出したシステム・アプリケーションの開発のやり方。
こういったやり方には一定の共通した設計思想がある=Microservice
何らかの決まったプロトコル、製品を採用すること≠Microservice
目的:大規模なシステムをスピーディーかつ安全に作っていく キーワード“ca microservices book”で検索サイトで検索いただくとダウンロードページにたどり着けます。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
5
Microserviceとは?Microserviceという考えの始まり
• システムが大きくなりすぎたため境界がわからなくなってしまった。
なぜ大規模なシステムをスピーディーかつ安全に作っていくことができないのか?
It had been clear that many of the problems people were facing in the wild were related to building systems that were too big. - James Lewis
Problem became “how can we build systems that are replaceable over being maintainable?” We used the term micro apps, I seem to remember.
• 維持可能な状態で(部分的に)リプレース可能となるシステムはどのように作ればよいか?
- James Lewis
先進的なIT企業が実践で考え出したシステムの開発手法・スタイル = Microservice
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
6
Microserviceとは?
• 大規模なシステムをスピーディーかつ安全に開発できるシステムアーキテクチャへ
• Small in size (アプリケーションのサイズが小さい)• Messaging enabled (Web APIで通信が行える)• Bounded by contexts(コンテキスト境界:ドメインドリブンデザインの考え方)• Autonomously developed (自主的に開発される)• Independently deployable (独立してデプロイできる)• Decentralized (集中管理はしない)• Built and released with automated processes (ビルドとリリースは自動化されている)
維持可能な状態で(部分的に)リプレース可能となるシステムとはどんな特徴があるのか?
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
7
Microserviceとは?
https://www.nginx.com/blog/introduction-to-microservices/
モノリシックアーキテクチャ
マイクロサービスアーキテクチャ
DevOps
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
9
Web APIインタフェース準備の課題
• マイクロサービスとまではいかないまでもWeb API化の必要があり直近で対応しないといけない。
フィンテック
外部連携
モバイルアプリケーション対応
など
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
10
Web APIインタフェース準備の課題
• レガシーな連携インタフェースしか用意されておらず簡単にWeb API化することが難しい。
• アプリケーション/システムとして作成されているためWeb APIインタフェースとしてサービスを切り出すことが難しい。
アプリケーションCORBAなどの
レガシーなプロトコルインタフェース
RDBMS
どの部分を切り出
せばよいか?稼働
しているので手を
加えられない。
レガシーなプロトコ
ルをどのようにAPI
化すればよいか?
API Clientブラウザのみを想定したWebアプリケーション
システム
API Client
Web API
Web API
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
11
Web APIの準備既存のバックエンドの接続にWeb APIのインタフェースをカスタムで作成
• 既存のシステムにあまり手を加えたくない場合は既存機能自体を一時的にWeb APIとして”包んでしまう”, ”リファクタリング”する必要がある。
• 一時的なWeb API化後にシステム全体のWeb API化に着手する。
既存function(ビジネスロジック)
Applicationなど
• DB Access(JDBC/ODBC etc)• CORBA/MQ etc
Web APIでないレガシーな接続
既存function(ビジネスロジック) Applicationなど
Web API
Web APIで受け付けられるインタフェースを用意する。
注意)単純にWeb APIのインタフェースを用意しただけなので既存ビジネスロジックのエンハンスなどはこれまでと同じく依存関係の問題から即座に行うことは難しいかもしれない。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
12
• CA API Gatewayで受け付けたメッセージリクエストをバックエンドのリソースへルーティング(フォワード)する機能を提供します。
• CA API Gatewayで受け取ったプロトコルメッセージとは別のプロトコルのメッセージを送信することも可能です。
Web API化の準備SOA/API GWのバックエンド転送機能(プロトコル変換機能)
HTTP HTTPS
FTP FTPS
SSH MQ
JMS
メッセージルーティング
JDBC
SNMPTrap
SMTP
Syslog
SOAP REST
LDAPバックエンドリソース
Web API Request
CA API Gateway
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
13
Web API化の準備SOA/API GWのバックエンド転送機能(プロトコル変換機能)ポイント
• サポートされるプロトコルを確認する
各社SOA GW/API GW製品ではバックエンド転送へのプロトコル変換機能があるがサポートされる種類がある程度決まっているため、自社内で利用できるかどうか?を確認する必要があります。
• 旧来からある ESBやEAIなどのミドルウェア
SOA/API GWよりバックエンド転送のプロトコル変換機能が充実しているケースが多い
ネックとしては高価なライセンス価格(すべての機能を利用しないので割高になってしまう)、SI工数が通常大きくなってしまう。そうであればWeb API化をスクラッチで行った方が安くなるケースも。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
14
Web API化の準備Web Scraping
• HTMLコンテンツを提供するサイトから必要なデータを抽出する手法のこと。
• 必要なデータを抽出してJSONやXMLフォーマットなどに整形してレスポンスを返したりAPIリクエストを受け取ってバックエンドのWebサーバへブラウザと同じ振る舞いとなるようにHTTP/POSTでデータを送信する実装を行いWeb API化します。
• ただしバックエンドのHTMLの構成などが頻繁に変化する場合などはデータ抽出方法を再検討する必要があるため注意が必要です。
Web API Request
CA API Gateway
Web
HTTP Request(ログイン)
ログイン成功
HTTP Request
Session Info
Session Info
レスポンス
JSON/XML
JSON/XML
Webリクエストと同じになるようにリクエストを整形する。
レスポンスのHTMLから正規表現などを利用して目的のデータを抽出する。
抽出データをXMLやJSONに整形して返す。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
16
• もしマイクロサービスの開発手法、スタイルを導入するならシステム・アプリケーションの開発はData CentricからCapability Centricの考え方でまず行ってみては?
• Data Centricとは?
アプリケーションをデータ中心に設計・開発していくやり方。
• Capability Centricとは?
データではなく”機能”を提供することを目的とした設計・開発の進め方。
マイクロサービス化のファーストステップ
データベーステーブルの設計 アプリケーションの設計
データベーステーブルの設計 アプリ/UIの設計提供する各機能の設計
アプリケーションを構成する各サービスではどんな機能が必要か?
アプリケーションとして必要なデータベーステーブルは?
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
17
• Data Centricの考え方の場合、アプリケーションの間でデータの共有が発生してしまう。
• 依存関係が発生してしまい”部分的”にリプレースしづらい環境となってしまう。
Data CentricからCapability CentricData Centricの問題点
Exchange Rate
Currency ID USD_RATE
1 110.10
App A
App B
別々のアプリAとBがそれぞれExchange Rateの情報を使う処理を行う。
Example
• Aはデータベースの種類をNOSQLなどに変えたいがBシステムは嫌だといってできない。
• データベースのバージョンアップに伴いアプリ側の接続ドライバも更新する必要があるが、Bアプリは管理者が不在で簡単に修正できず、結局、データベースのバージョンアップができない。
データ共有の問題
共有データベース
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
18
Data CentricからCapability CentricCapability Centricの考え方
• 必要な“機能”を提供することにするとデータの共有の問題を解決しコンポーネントのリプレースが可能となりやすい。
Exchange Rate
Currency ID USD_RATE
1 110.10App A
App B
ExchangeRate
サービス
Example
Web API Request
• Exchange Rateサービスとして以前と変わらないサービスを提供できればバックエンドのストレージは例えばNOSQLに変えても問題ない。
JSON or XML
Web API Request
JSON or XML
• Exchange Rateサービスとして以前と変わらないサービスを提供できればデータベースのバージョンアップや接続ドライバを変更しても問題ない。
リプレースできる
リプレースできる
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
19
Data CentricからCapability CentricMicroserviceでのデータの持ち方
https://www.nginx.com/blog/introduction-to-microservices/
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
20
Data CentricからCapability CentricMicroserviceでのデータの持ち方:疑問点
https://www.nginx.com/blog/introduction-to-microservices/
別のサービスが既存データベース上のデータにアクセス
したい場合はどうする?
Service
疑問点
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
21
Data CentricからCapability CentricMicroserviceでのデータの持ち方:データのコピー?
https://www.nginx.com/blog/introduction-to-microservices/
Replica
DB
Service
データのコピーの仕組みを考える必要があったり、データのリアルタイム性が損なわれる。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
既存のサービス経由では必要なデータが返らない。
22
Data CentricからCapability CentricMicroserviceでのデータの持ち方:データアクセス層の疎結合化(Web API化)
Data Access Layer (Data API)
Web API Web API Web API
ServiceWeb API
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
23
Data CentricからCapability CentricMicroserviceでのデータの持ち方:データアクセス層の疎結合化(Web API化)
MS
• データアクセス層をWeb API化しておくと新しくサービスを追加する際に柔軟に対応できるのでは?
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
既存サービス 想定していたものよりデータ、
ロジックが必要になった。機能
が足りないので新しくサービス
を作成しないと。。
MS
既存サービス
Data API
MS
Client新サービス
Web APIWeb API
既にデータへのアクセスがWeb
APIとしてインタフェースが用意
されているためロジックを付与
したAPIを開発するだけでよいね。
Web API
API Clientはデータの参照だけで
よいのでそのままAPIでアクセス
させてもよいね。たくさんAPIを
作成しなくてよいね。
MS
MS
Microservice
24
Monolith App
MonolithからMicroserviceへの移行
UI
Logic
Data
Message based communication
Message based communication
UIとLogicの切り離し
MS MS MS
MS MS
LogicとDataの切り離し
UI
Data
LogicをMicroserviceに分割
Microservice
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
25
各レイヤーのWeb API化
Backend(Database)
Business
Layer
API
Application
Third vender
Application
Mobile
Application
Channel
Layer
API
Customer
Service
User
Management
User
Authentication
Inventory
Management
・・
Desktop
App API
Mobile
App API
Third vender
App API
Web API
Web API
Web API
Web API
Web API
Web API
Data
Layer
API
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
27
データベースのデータを即座にWeb API化
CA Live API Creator
• データベースへの接続情報をCA Live API Creatorへ設定してデータベースをスキャンすることで各Table, View, ProcedureのWeb APIのエンドポイント(レコードの参照・追加・更新・削除が可能)をそれぞれ自動で作成します。
• 作成したWeb APIのエンドポイントに対して自動でSwaggerドキュメント(UI&JSON)を作成します。
Swagger UI
(API Document)
Swagger JSON
(JSON API Document)
Web API Endpoint
GET/POST/PUT/DELETE自動生成
データベーステーブル構造のスキャン
App Developer(API User)
API Request
APIの仕様確認
ツールへの取り込み
API Developer
Web API化したいデータベースの接続アカウントを指定してスキャンする。
Table View Procedure
テーブル1
テーブル2
テーブル3
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
28
データベースの整合性を保つためのロジック実行機能Reactive Logic
APIClient
Web API Request
テーブルに対して”ルール”を指定するとWeb APIを利用してテーブルに追加(POST)、修正(PUT)、削除(DELETE)が行われたときに反応(React)して指定のルールを実行することが可能です。
CA Live API Creator
ReactiveLogic
Execute
テーブルAにレコード追加
テーブルA用HTTP POST データコミット
テーブルA
Database
Response
Rule
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
29
データベースの整合性を保つためのロジック実行機能Reactive Logic : 表計算ソフトのスプレッドシートのような動作
表計算ソフトのスプレッドシートのようにカラムのテーブルの値が変更されれば指定されたルールにより自動で計算される仕組みを提供します。
“50”から”75”へ修正すると自動でAmount Totalも変更される。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
30
データベースの整合性を保つためのロジック実行機能Reactive Logic : Parent Copy, FORMULAの例
テーブルA
カラム1 カラム2 カラム3 カラム4 カラム5
1 100 3 テーブルBの値をコピーする
カラム3の値×カラム4の値の計算結果
テーブルB
カラム1 カラム2
100 1000
テーブルAにレコードをReactive LogicのParent Copy, Formulaを利用して追加するケース
テーブルAにエントリ:カラム1=“1”, カラム2=“100”, カラム3=“3”を挿入するが、カラム4とカラム5はReactive Logicで自動挿入
カラム4はテーブルBのカラム2をコピー(Parent Copy)しカラム5はテーブルAのカラム3とカラム4を掛け合わせた結果(Formula)を挿入する。
親として参照(外部キー)
参照元
参照先
Parent Copy FORMULA
“1000” “3×1000=3000”
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
31
データベースの整合性を保つためのロジック実行機能Reactive Logic : Validationの例
テーブルA
カラム1 カラム2 カラム3
1 Test 100
テーブルB
カラム1 カラム2 カラム3
1 Test True
テーブルAに”Validation”のロジックルールを設定するケース
テーブルAにあるレコードを修正(カラム1=“1”, カラム2=“Test”, カラム3=“100”に変更)
テーブルAに”Validation”のロジックルールが設定され”Validation”にはテーブルBのカラム3がTrueであればレコードの修正を許可するというルールが設定されているため、テーブルBのカラム3の値によってレコード修正のコミットを許可するかどうかの判別がされる。
データ更新をコミットする前にValidationのルールが動作するValidation
Validationルール• 指定した処理ロジック(JavaScriptで記述)がBoolean値
で”true”を返せればCommitを実行するというルール
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
32
CA Live API Creatorで実現できる環境
• バックエンドデータへアクセスするWeb APIを利用して複数のアプリケーションがデータベースやプロトコル固有の接続ではないWeb APIで必要なデータへのアクセスを可能とする。
RDBMS A
RDBMS B
CA Live API Creator
Web API SQL/JDBC
SQL/JDBC
データ(データベース)へのアクセスを提供するAPIは”Data API”と呼ばれる。特定の接続プロトコルに依存しない。
Web API
Web API
Data
Data
Data
API Client(Application)
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
33
ユースケース1レガシーシステムのWeb API化支援
ApplicationLogic
既存システム・アプリケーション
データベース
新しいアプリケーション
既存システム・アプリケーションのデータベースの情報にアクセスしたいが、システムとしてデータベースが取り込まれているためアクセスできるインタフェースがない。あったとしてもレガシーなインタフェース(CORBA, FTP etc)のみのケース。
新しいアプリケーション
CA Live API Creator
HTTP
CRUD TypeWeb API Endpoint
データベース
JDBC
新規のアプリケーションが既存のデータベースへHTTPを利用したWeb APIアクセスできるようになる。
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
34
ユースケース1レガシーシステムのWeb API化支援
• データベーステーブルに既にViewやProcedureが設定されている場合、ViewやProcedureの実行結果をWeb APIで返すことができるため、必要なデータを加工された状態でWeb APIでアクセスすることができるようになります。
• SQLを直接実行した結果をWeb APIとして返すことができます。アプリケーションから決まったSQLが既に指定されている場合はそのままテーブルのクエリー結果をWeb APIで返すことができます。
API Client
CA Live API Creatorデータベース
JDBC
Select * from table;
View or Procedure
既存のデータをデータベーステーブルから直接Web APIで取得するだけの要件も多い
(何らかのロジックを実行した結果を返さなくてよいケース)
テーブルにあるカラムの素の情
報をWeb APIで取得したいです。
ViewとProcedureの結果が
JSONで返ってくるAPIで十分。
レガシーシステム
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
35
ユースケース2アプリケーションのマイクロサービス化
Backend(Database)
Data Layer API
Business
Layer
API
Application
Third vender
Application
Mobile
Application
Channel
Layer
API
Customer
Service
User
Management
User
Authentication
Inventory
Management
・・
Desktop
App API
Mobile
App API
Third vender
App API
Web API
Web API
Web API
Web API
Web API
Web API
CA Live API Creator
• Web APIの各APIレイヤーとCA Live API Creatorの利用
Capability
データベースリソースは共有化しつつも疎結合化しやすいようにWeb API化する
CA API GW
Copyright © 2017 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.