API Academy:マイクロサービス化へのファーストステップ

API Academy
マイクロサービス化へのファーストステップ
日本CA株式会社
加田友広

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”で検索サイトで検
索いただくとダウンロードページにたどり着けます。

5
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

6
• 大規模なシステムをスピーディーかつ安全に開発できるシステムアーキテクチャへ
• Small in size (アプリケーションのサイズが小さい)
• Messaging enabled (Web APIで通信が行える)
• Bounded by contexts(コンテキスト境界:ドメインドリブンデザインの考え方)
• Autonomously developed (自主的に開発される)
• Independently deployable (独立してデプロイできる)
• Decentralized (集中管理はしない)
• Built and released with automated processes (ビルドとリリースは自動化されている)
維持可能な状態で(部分的に)リプレース可能となるシステムとはどんな特徴があるのか？

7
https://www.nginx.com/blog/introduction-to-microservices/
モノリシックアーキテクチャ
マイクロサービスアーキテクチャ
DevOps

既存の仕組みをAPI化するには？

9
Web APIインタフェース準備の課題
• マイクロサービスとまではいかないまでもWeb API化の必要があり直近で対応しないといけない。
 フィンテック
 外部連携
 モバイルアプリケーション対応
など

10
Web APIインタフェース準備の課題
• レガシーな連携インタフェースしか用意されておらず簡単にWeb API化することが難しい。
• アプリケーション/システムとして作成されているためWeb APIインタフェースとしてサービスを切り出すことが難しい。
アプリケーション
CORBAなどの
レガシーなプロトコル
インタフェース
RDBMS
どの部分を切り出
せばよいか？稼働
しているので手を
加えられない。
レガシーなプロトコ
ルをどのようにAPI
化すればよいか？
API Client
ブラウザのみを想定したWebアプリケーション
システム
API Client
Web API
Web API

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のインタフェースを用意しただけなので既存ビジネスロジックのエンハンスなどはこれまで
と同じく依存関係の問題から即座に行うことは難しいかもしれない。

12
• CA API Gatewayで受け付けたメッセージリクエストをバックエンドのリソースへルーティング(フォワード)する機能
を提供します。
• CA API Gatewayで受け取ったプロトコルメッセージとは別のプロトコルのメッセージを送信することも可能です。
Web API化の準備
SOA/API GWのバックエンド転送機能(プロトコル変換機能)
HTTP HTTPS
FTP FTPS
SSH MQ
JMS
メッセージルーティング
JDBC
SNMP
Trap
SMTP
Syslog
SOAP REST
LDAP
バックエンドリソース
Web API Request
CA API
Gateway

13
Web API化の準備
SOA/API GWのバックエンド転送機能(プロトコル変換機能)
ポイント
• サポートされるプロトコルを確認する
 各社SOA GW/API GW製品ではバックエンド転送へのプロトコル変換機能があるがサポートされる種類がある程度
決まっているため、自社内で利用できるかどうか？を確認する必要があります。
• 旧来からある ESBやEAIなどのミドルウェア
 SOA/API GWよりバックエンド転送のプロトコル変換機能が充実しているケースが多い
 ネックとしては高価なライセンス価格(すべての機能を利用しないので割高になってしまう)、SI工数が通常大きく
なってしまう。そうであればWeb API化をスクラッチで行った方が安くなるケースも。

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に整
形して返す。

マイクロサービス化のファーストステップ
〜Data CentricからCapability Centricの考え方へ〜

16
• もしマイクロサービスの開発手法、スタイルを導入するならシステム・アプリケーションの開発は
Data CentricからCapability Centricの考え方でまず行ってみては？
• Data Centricとは？
 アプリケーションをデータ中心に設計・開発していくやり方。
• Capability Centricとは？
 データではなく”機能”を提供することを目的とした設計・開発の進め方。
マイクロサービス化のファーストステップ
データベーステーブルの設計アプリケーションの設計
データベーステーブルの設計アプリ/UIの設計提供する各機能の設計
アプリケーションを構成する各サービスではど
んな機能が必要か？
アプリケーションとして必要なデータベース
テーブルは？

17
• Data Centricの考え方の場合、アプリケーションの間でデータの共有が発生してしまう。
• 依存関係が発生してしまい”部分的”にリプレースしづらい環境となってしまう。
Data CentricからCapability Centric
Data Centricの問題点
Exchange Rate
Currency ID USD_RATE
1 110.10
App A
App B
別々のアプリAとBがそれぞれExchange
Rateの情報を使う処理を行う。
Example
• Aはデータベースの種類をNOSQLなどに変えたいがBシステ
ムは嫌だといってできない。
• データベースのバージョンアップに伴いアプリ側の接続ドラ
イバも更新する必要があるが、Bアプリは管理者が不在で簡
単に修正できず、結局、データベースのバージョンアップが
できない。
データ共有の問題
共有データベース

18
Capability Centricの考え方
• 必要な“機能”を提供することにするとデータの共有の問題を解決しコンポーネントのリプレースが可能
となりやすい。
Exchange Rate
Currency ID USD_RATE
1 110.10
App A
App B
Exchange
Rate
サービス
Example
Web API
Request
• Exchange Rateサービスとして以前と変わらないサービス
を提供できればバックエンドのストレージは例えばNOSQL
に変えても問題ない。
JSON or XML
Web API
Request
JSON or XML
• Exchange Rateサービスとして以前と変わらないサービス
を提供できればデータベースのバージョンアップや接続ドラ
イバを変更しても問題ない。
リプレースできる
リプレースできる

19
Microserviceでのデータの持ち方

20
Microserviceでのデータの持ち方：疑問点
別のサービスが既存データ
ベース上のデータにアクセス
したい場合はどうする？
Service
疑問点

21
Microserviceでのデータの持ち方：データのコピー？
Replica
DB
Service
データのコピーの仕組みを考える
必要があったり、データのリアル
タイム性が損なわれる。
既存のサービス経由では必要な
データが返らない。

22
Microserviceでのデータの持ち方：データアクセス層の疎結合化(Web API化)
Data Access Layer (Data API)
Web API Web API Web API
Service
Web API

23
Microserviceでのデータの持ち方：データアクセス層の疎結合化(Web API化)
MS
• データアクセス層をWeb API化しておくと新しくサービスを追加する際に柔軟に対応できるのでは？
既存サービス想定していたものよりデータ、
ロジックが必要になった。機能
が足りないので新しくサービス
を作成しないと。。
MS
既存サービス
Data API
MS
Client
新サービス
Web API
Web 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

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

CA Live API Creatorを利用したWeb API化

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

28
データベースの整合性を保つためのロジック実行機能
Reactive Logic
API
Client
Web API
Request
 テーブルに対して”ルール”を指定するとWeb APIを利用してテーブルに追加(POST)、修正(PUT)、削除(DELETE)が
行われたときに反応(React)して指定のルールを実行することが可能です。
CA Live API Creator
Reactive
Logic
Execute
テーブルA
にレコー
ド追加
テーブル
A用HTTP POST データコミット
テーブルA
Database
Response
Rule

29
Reactive Logic : 表計算ソフトのスプレッドシートのような動作
 表計算ソフトのスプレッドシートのようにカラムのテーブルの値が変更されれば指定されたルールにより自動で
計算される仕組みを提供します。
“50”から”75”へ修正すると自動でAmount
Totalも変更される。

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”

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を実行するというルール

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)

33
ユースケース1
レガシーシステムのWeb API化支援
Application
Logic
既存システム・アプリケーション
データベース
新しいアプリケーション
既存システム・アプリケーションのデータベースの
情報にアクセスしたいが、システムとしてデータ
ベースが取り込まれているためアクセスできるイン
タフェースがない。あったとしてもレガシーなイン
タフェース(CORBA, FTP etc)のみのケース。
新しいアプリケーション
CA Live API Creator
HTTP
CRUD Type
Web API Endpoint
データベース
JDBC
新規のアプリケーションが既存のデータベースへHTTPを利用したWeb APIアクセスでき
るようになる。

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で十分。
レガシーシステム

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

API Academy:マイクロサービス化へのファーストステップ

API Academy:マイクロサービス化へのファーストステップ

More Related Content

Similar to API Academy:マイクロサービス化へのファーストステップ (20)

More from CA Technologies (20)

API Academy:マイクロサービス化へのファーストステップ