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とは？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

SNMPTrap

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 CentricData Centricの問題点

Exchange Rate

Currency ID USD_RATE

1 110.10

App A

App B

別々のアプリAとBがそれぞれExchange Rateの情報を使う処理を行う。

Example

• Aはデータベースの種類をNOSQLなどに変えたいがBシステムは嫌だといってできない。

• データベースのバージョンアップに伴いアプリ側の接続ドライバも更新する必要があるが、Bアプリは管理者が不在で簡単に修正できず、結局、データベースのバージョンアップができない。

データ共有の問題

共有データベース


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サービスとして以前と変わらないサービスを提供できればデータベースのバージョンアップや接続ドライバを変更しても問題ない。

リプレースできる

リプレースできる


19

Data CentricからCapability CentricMicroserviceでのデータの持ち方



20

Data CentricからCapability CentricMicroserviceでのデータの持ち方：疑問点


別のサービスが既存データベース上のデータにアクセス

したい場合はどうする？

Service

疑問点


21

Data CentricからCapability CentricMicroserviceでのデータの持ち方：データのコピー？


Replica

DB

Service

データのコピーの仕組みを考える必要があったり、データのリアルタイム性が損なわれる。


既存のサービス経由では必要なデータが返らない。

22

Data CentricからCapability CentricMicroserviceでのデータの持ち方：データアクセス層の疎結合化(Web API化)

Data Access Layer (Data API)

Web API Web API Web API

ServiceWeb API


23

Data CentricからCapability CentricMicroserviceでのデータの持ち方：データアクセス層の疎結合化(Web API化)

MS

• データアクセス層をWeb API化しておくと新しくサービスを追加する際に柔軟に対応できるのでは？


既存サービス想定していたものよりデータ、

ロジックが必要になった。機能

が足りないので新しくサービス

を作成しないと。。

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


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

APIClient

Web API Request

テーブルに対して”ルール”を指定するとWeb APIを利用してテーブルに追加(POST)、修正(PUT)、削除(DELETE)が行われたときに反応(React)して指定のルールを実行することが可能です。

CA Live API Creator

ReactiveLogic

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化支援

ApplicationLogic

既存システム・アプリケーション

データベース

新しいアプリケーション

既存システム・アプリケーションのデータベースの情報にアクセスしたいが、システムとしてデータベースが取り込まれているためアクセスできるインタフェースがない。あったとしてもレガシーなインタフェース(CORBA, FTP etc)のみのケース。

新しいアプリケーション

CA Live API Creator

HTTP

CRUD TypeWeb 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:マイクロサービス化へのファーストステップ

Technology

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