400種類以上のAPI連携を開発・サポートしているデータパイプラインツール CData Sync の中身

© 2021 CData Software Japan, LLC | www.cdata.com/jp
1. About CData Software
400種類以上のAPI連携を開発・サポートしている
データパイプラインツール CData Sync の中身
2021/11/21：JJUG CCC 2021 Fall
CData Software Japan Lead Engineer / Kazuya Sugimoto

View Slide

CData Software Japan の API holic 担当
年100種類以上のAPIを見たり触ったりしています。
Twitter：@sugimomoto
Facebook：sugimomoto
Blog：http://kageura.hatenadiary.jp/
About Speaker
Horizontal SaaS 647種類のAPI提供状況を調査：そこから見えてきた国
産 SaaS APIの今
https://www.cdatablog.jp/entry/horizontalsaasapi

View Slide

CData SyncTM
✓ クラウド/SaaS データをノンコーディングでDB に反復
同期できるパワフルなツール
✓ クラウドデータをRDB にコピーして、帳票や分析で
データを活用
✓ クラウドデータのバックアップに
✓ 主要データソースでは、差分更新機能をサポートし、
効率的な同期ジョブを実行

View Slide

And more…
Salesforce
Facebook
Gmail Twitter Stripe
Google
Adwords
Dynamics
365
JSON
Google
Analytics
Jira
GitHub
Twilio
kintone
Office 365
Quick Books
Zoho
HubSpot Sugar CRM
SharePoint
Eloqua
Marketo
NetSuite
Dynamics
CRM
YouTube
Analytics
Google
Spreadsheets
SendGrid
SAP
Active
Driectory
Google
Contacts
XML
CData Sync Data Sources
現在「400種類」以上のサービスに対応

View Slide

本日のお話

View Slide

Horizontal SaaS API公開状況調査

View Slide

「45.6%：290サービス」がAPIを公開している
海外では90％
API公開を行っていた

View Slide

調査の中で最も注目するべき点は「API仕様の多様性」
RESTが多いが
詳しく見てみると多種多様
国産SaaSはそもそも
API仕様すらわからない

View Slide

認証方法のサポートも多岐に渡る

View Slide

不安定かつ多様な「API」と共存している

View Slide

一つの企業が利用している平均SaaSの数が「80」
企業で使うSaaS の数が急増：連携ニーズも増加
http://pages.bettercloud.com/rs/719-KZY-706/images/2020_StateofSaaSOpsReport.pdf

View Slide

アプリ側のAPI連携ニーズも拡大
HubSpotアプリマーケットプレイスへの公式連携ア
プリ登録数が500件突破
freeeアプリストアの掲載アプリ数が
100を突破連携アプリケーション掲
載数はリリースから約2年で4倍に
https://prtimes.jp/main/html/rd/p/000000622.000006428.html
https://www.hubspot.jp/company-news/hubspot-grows-platform-ecosystem-to-500-apps-20200728

View Slide

不安定かつ多様なAPIと
連携しなければいけないのが実情
もし、この不安定さが直接的に
ビジネスロジックに影響したら？
APIへの追従・機能追加がアプリの
スケールを阻害する可能性がある

View Slide

不安定かつ多様なAPIの連携に対して
どのようにプロダクトとして対応・スケールさせているのか？
製品としての取り組み、「アーキテクチャ」を軸に解説

View Slide

大量のAPIサポートしつつ、スケールする
アーキテクチャとは？

View Slide

「インターフェース」が超重要

View Slide

なぜなら
API追従の衝撃をビジネスロジック側に影響させない
アーキテクチャ
各チームが独立して、それぞれ機能追加
アップデート・ビルド・テスト・リリースが行える体制
がスケールするための要だから

View Slide

スケールを阻害する要因は「密結合」
密結合とは、細分化された個々のコンポーネント同士が密接に結びついている状態のことで
ある。
密結合状態のシステムでは、緊密で高速な動作が可能となっているが、一方のコンポーネン
トが異常をきたすと、他方のコンポーネントがその影響を受けてしまう。そのため密結合のシ
ステムでは、保守や部品の交換などに際して密接な連携を顧慮する必要がある。密結合は
マルチプロセッサシステムのようなハードウェア的なものから、アプリケーションソフトのようなソフト
ウェア的なものまで、幅広く見られる状態である。
https://japan.zdnet.com/glossary/exp/%E5%AF%86%E7%B5%90%E5%90%88/?s=4
APIへの追従に他のモジュールが影響を受けやすいと
メンテナンスコストの増加→スケールを阻害

View Slide

CData Sync はプラグインレイヤーで
APIとの疎結合なアーキテクチャを実現している
データソースとなる
多種多様なAPI
データパイプラインの
メインロジック
ビジネスロジックレイヤー
APIとロジックをつなぐ
インターフェース
プラグインレイヤー

View Slide

プラグインA
担当
プラグインB
担当
プラグインC
担当
Sync
チーム
ビジネスロジックチームと各プラグインチームが
独立して開発・ビルド・テスト・リリース
Sync Logic
Module
Plugin A
Module
Plugin B
Module
Plugin C
Module
Sync Main Module
※実際にはもうちょっと細分化してます。

View Slide

CData が活用している「インターフェース」とは？
マイクロサービス的な？
REST？ SOAP？
gRPC？
デザインパターン？

View Slide

JDBC
JDBCとは、Javaプログラムからデータベースにアクセスするための標
準インターフェース（API）の一つ。データベースの違いによらず同じ
手順で接続し、データを読み書きすることができる。
https://e-words.jp/w/JDBC.html

View Slide

API仕様のガラパゴスな世界と
常に変わり続ける仕様への追従

View Slide

API連携のスケールを意識し・拡張性を踏まえながら
サービスに機能を組み込もうとすると、2つの壁に衝突
多種多様なAPI仕様の壁
変わり続けるAPI仕様の壁

View Slide

でも、ほとんど「REST API」だから、
そんなに難しくなくない？

View Slide

「REST」はプロトコルでは無い

View Slide

改めて REST ってなんだっけ？
REST = Representational State Transfer
＞Representational State Transfer (REST) は、ウェブのような分散ハイ
パーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつである。
引用元：Wikipedia REST（https://ja.wikipedia.org/wiki/REST）

View Slide

Web API を REST たらしめる“原則“（≠規約）
• Stateless：ステートレスなクライアント/サーバプロトコル
• Uniform Interface：すべての情報（リソース）に適用できるHTTPメソッドの定義
• Addressability：リソースを一意に識別する「汎用的な構文（URL）」の定義
• Connectability：アプリケーションの情報と状態遷移の両方を扱うことができる「ハイ
パーメディア（リソースリンク）の使用」
上記の原則に従っているアーキテクチャを REST ful と言ったりするが
あくまで “原則“ であり ”規約” ではない！

View Slide

例えば「Salesforce」の「REST API」
実体はSOQLというSalesforce内部での
独自規格のSQLを発行するAPI
https://developer.salesforce.com/docs/atlas.ja-jp.api_rest.meta/api_rest/resources_query.htm

View Slide

認証方法のサポートも多岐に渡る

View Slide

同じ OAuth 2.0 でも
例えば Refresh Token の扱いが違ったり
POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=XXXX
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&refresh_token=OAAABXXXX...
&grant_type=refresh_token
&client_secret=sampleCredentia1s
{
"access_token": "XXXXX...",
"token_type": "Bearer",
"expires_in": 3599,
"scope":
"https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
"refresh_token": "XXXX...",
"id_token": "XXXXX.XXX...",
}
POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope":
"https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-
oauth2-auth-code-flow#refresh-the-access-token
https://developers.google.com/identity/protocols/oauth2/web-
server#offline
Azure AD OAuth 2.0 Google Cloud Platform OAuth 2.0

View Slide

API アップデートへの追従も大変

View Slide

Salesforce の API Version は「53」

View Slide

Amazon Marketplace API アップデートで
API仕様が大幅変更・古いAPI終了告知が半年前*
https://sellercentral.amazon.co.jp/forums/t/topic/73349
※現在は2022年7月に延期

View Slide

認証方法・クエリパラメータデザイン
レスポンスフォーマット含め全面刷新
POST /Orders/2013-09-
01/?AWSAccessKeyId=AKIAIKW5JHOTOOWSF43A&Action=List
Orders&LastUpdatedAfter=1969-12-
31T15%3A00%3A00Z&MWSAuthToken=amzn.mws.XXX&Marke
tplaceId.Id.1=A1VC38T7YXB528&SellerId=A1WD8M4EQL9XVH&
Signature=XXXXX&SignatureMethod=HmacSHA256&Signatur
eVersion=2&Timestamp=2020-10-
02T00%3A27%3A20Z&Version=2013-09-01 HTTP/1.1
Host: mws.amazonservices.jp
Accept: application/xml
Content-Type: application/xml
xmlns="https://mws.amazonservices.com/Orders/2013-09-01">

2018-08-
17T14:59:59Z
StandardOrder
2018-08-
15T09:59:55.270Z
GET /orders/v0/orders?MarketplaceIds=A1VC38T7YXB528&
CreatedAfter=2021-08-09 HTTP/1.1
Host: sellingpartnerapi-fe.amazon.com
Accept: application/json
Authorization:******
x-amz-access-token: XXXXX
x-amz-date: 20210809T073105Z
x-amz-security-token: XXXXX
{
"payload": {
"Orders": [
{
"NumberOfItemsUnshipped": 0,
"BuyerInfo": {},
"IsReplacementOrder": "false",
"IsSoldByAB": false,
"AmazonOrderId": "503-9993250-1405404",
"LatestShipDate": "2018-08-17T14:59:59Z",
"EarliestShipDate": "2018-08-15T15:00:00Z
MWS API Selling Partner API

View Slide

Yahoo Shopping API の軽減税率対応等
注文データや商品マスタなど
ほとんどのAPIリソースの項目が追加・更新
https://developer.yahoo.co.jp/webapi/shopping/tax.html

View Slide

ここまで多種多様なAPIを相手にしているからこそ
API処理を担うレイヤーは実装が重くなりやすい
Logic
API API API API

View Slide

だからこそ
疎結合の「アーキテクチャ」
それを実現し、かつAPIの変更・追従を隠蔽する
「インターフェース」
が超重要

View Slide

CData Sync における疎結合アーキテクチャの
実現アプローチ

View Slide

プラグインアーキテクチャで疎結合に構成
JDBCインターフェースでAPI追従の衝撃を緩和
データソースとなる
多種多様なAPI
データパイプラインの
メインロジック
ビジネスロジックレイヤー
APIとロジックをつなぐ
JDBCインターフェース
プラグインレイヤー

View Slide

プラグインは独立したJDBCライブラリ形式
外部から差し込み、追加サービスとしてラインナップ
ユーザーが必要なサービスの連携モ
ジュールを個別にダウンロード

View Slide

追加されたモジュールの一覧は
以下のように配置されている

View Slide

なぜ「JDBC」を採用？

View Slide

そもそもインターフェースのデザインって難しくない？

View Slide

例えば、Interfaceクラスに
どのようなメソッドを定義するのか？
interface SampleInterface {
void Create(Parameter param);
void Update(String id, Parameter param);
void Delete(String id);
Record GetRecord(String id);
List GetRecords(Query query);
}
返り値・引数のデザインは
どうする？
変更した場合、API全部の実装に手を
入れ直さないといけないの？
どこまで機能をサポートする？

View Slide

例えば、REST API でどのメソッドに
どのようにデータ・ビジネスモデルを当てはめるのか？
GET POST
PUT DELETE

View Slide

データを取得したいのにPOST
・例：Bodyで検索条件を指定するから、
POSTメソッドでGETする
・基本的にすべてのエンドポイントがPOST仕
様だったり（統一されているならいいが）

View Slide

リソース指向と関数指向がまざってる
・リソース指向、関数指向がまざっている
例えばURLが
https://XXX.com/getXXX
https://XXX.com/findXXX
https://XXX.com/users
・詳細検索するときだけ、FindやSearchといったURL

View Slide

良い疎結合の実現には
堅牢なインターフェースデザインの採用がポイント
でも、プロダクトの成長・スケールを見据えて、インター
フェースのデザインを固めることは結構難しくない？
柔軟にしすぎると各レイヤーの実装・メンテコストがかさむ
固めすぎると追加機能対応に適応し難い

View Slide

JDBC
JDBCとは、Javaプログラムからデータベースにアクセスするための標
準インターフェース（API）の一つ。データベースの違いによらず同じ
手順で接続し、データを読み書きすることができる。
https://e-words.jp/w/JDBC.html

View Slide

JDBCを採用している理由
• RESTのようなゆるい規格ではない。スタンダードかつ認識の齟齬が発生し
ない、手続きがきまっている規格である。
• クライアント側は汎用的な JDBC API の仕様のみを意識して実装できる。
使い慣れたクエリ言語、接続定義が利用できる。
• 「APIの振る舞いを読み取るためのAPIの存在」つまり「Metadata」を定義
でき、扱うことができる。
• 独立した利用・動作確認が安易かつ横断的なテスタビリティを確保しやすい。
• CData Sync というRDBライクなデータを扱う製品に向いている。

View Slide

クライアントはAPIの複雑性・不安定性を意識しない
APIとのやり取りをJDBCに一任
し、データセットを受け取る
ビジネスロジックレイヤーは
JDBCを通じて
SQLをリクエストするだけ
JDBCレイヤーが
APIリクエスト・レス
ポンスの解析を担う
SELECT [Id],[Name]
FROM [Customers]
GET /customers?
$select=id,name
Authorization: Basic XXXX
{
[“id”:1,”name”:”Hello”],
[“id”:2,”name”:”World”]
}
Id Name
1 Hello
2 World

View Slide

?
Web
API
HTTP
JSON
カラムは？型は？
桁数は？
何個リソースがあるの？
どんなリソースがあるの？
フィルターやページングはどうすれ
ばいいの？
どんなHTTPリクエストを
すればいいの？
GET? POST? 認証方式は？
Metadataが無いとクライアントはどうやって
APIの多様さを解釈すればいいかわからない
Service

View Slide

Metadataがあることでクライアントは
APIの仕様の違いを意識せずAPIを扱うことができる
テーブル定義としてリソースをリス
トアップ。ユーザーが動的にアクセ
スしたいリソースを選択できる
プロパティ、型、桁数がMetadata
から読み取れるため、マッピングや
バリデーションが行いやすい
認証に必要なアプローチ、プロパ
ティ、必須条件を提供しAPI個別の
認証方式の違いを抽象化

View Slide

JDBCのエコシステムを活用することで
インターフェース単独で動作確認・テスト・検証が安易
https://www.dbvis.com/
JDBC用ツールを活用して
ビジネスロジックを通さずに
独立して動作確認・テスト・検証が可能
いちいちモックなどを作らなくていい

View Slide

CData Sync 本体・プラグインは個別にデイリービルド
独立してオフライン・オンラインテストも実施
Sync Logic
Module
Plugin A
Module
Plugin B
Module
Plugin C
Module
Sync Main Module
プラグインでのテストの大まかな区分け
・単体テスト：クラス・メソッド単位のテスト
・結合テスト：API Request Builder の振る舞いのテスト
・インターフェーステスト：JDBC API（SQL）を通じて生成されるAPIリクエストのテスト
・オンラインテスト：実際にAPIを実行して正常性確認を行うテスト

View Slide

内部のインターフェーステストの一例
JDBCとAPIリクエスト検証ファイルの組み合わせ
@Test
public void SampleTest() throws Exception {
Class.forName("cdata.jdbc.kintone.KintoneDriver");
String testFile = "requestCheckFile.txt";
Connection conn = DriverManager.getConnection(
"jdbc:kintone:User=myuseraccount;Password=mypassword;Url=http:
//subdomain.domain.com;" + testFile
);
Statement stat = conn.createStatement();
boolean ret = stat.execute(
"SELECT RecordId,Revision FROM [顧客管理（営業支援パック）] "
);
int row = 0;
if (ret) {
ResultSet rs = pstmt.getResultSet();
while (rs.next()) {
if (row == 0) {
assertEquals("3", resultSet.getString("RecordId"));
assertEquals("10", resultSet.getString("Revision"));
}
}
row++;
}
assertEquals(10, row);
}
RequestLines=3,11 | ValidateRequest=JSON | ResponseLines=16,16 |
NextData=18 | ValidateUrl=https://XXXX.kintone.com/k/v1/apps.json |
RequestHeaders=3,11
Host: XXXX.kintone.com
Authorization: Basic XXXXXXXXX==
Accept-Encoding: gzip, deflate
User-Agent: CData Data Provider Engine - www.cdata.com - Accepts: gzip
Content-Type: application/json
Content-Length: 13
X-Cybozu-Authorization: XXXXXXXXXX==
X-HTTP-Method-Override: GET
{"limit":100}
{"apps":[{"appId":"3","code":"","name":“TimeCard","description":"勤
務時間を記録するアプリです。","createdAt":"2016-10-
26T10:12:04.000Z","creator":{"code":"Administrator","name":"Administrato
r"},"modifiedAt":"2017-01-29T10:50:44.000Z","modifier":{"code
…
リクエストのダミーファイルを作成し
ビジネスロジックを通じて生成される想定のSQL
とAPIリクエストの整合性をチェック
レスポンスの結果もResultSetとして検証

View Slide

とはいえ、それでもやっぱり難しい
インターフェースと外部APIの辻褄合わせ

View Slide

APIの複雑性・不安定性をどこまで隠蔽するべきか？
どのように隠蔽するべきか？
Web API
Service

View Slide

データ型はどうしようか毎回悩む
・そもそもAPI仕様書に型情報が載っていないものが多い
・通貨フィールドが数値型ではなく、円マーク付きで返って
くるので文字列になってしまうものも
例：var x = “¥1,000,000”;
・データとしては数値的に扱いたいニーズがあるので、プラ
グインサイドで通貨マークの調整処理が必要

View Slide

エラーハンドリングは
どこまでインターフェース側でカバーするべきか
・Error Code 404 のはずなのに 200 でエラーが返ってくる
ことがあった。成功なのに失敗？
・API Limit Error は待機するべきかリトライするべきか
・ページネーションの最後がエラーになるがクライアントにとって
はエラーにしないほうがいいものがあったり

View Slide

余談

View Slide

実はリリース当初は密結合だった CData Sync
・基本的な製品思想は同じだがAPI側プラグイ
ンとロジックサイドが密結合
・ユーザーは使いたいAPIの数だけソフトウェアを
インストールする必要があった
・ビジネスロジックサイドに修正が入ると、全デー
タソース分のビルドを作り直し
・各開発チームの担当レイヤーが入り乱れ

View Slide

まとめ

View Slide

不安定かつ多様な「API」と共存している

View Slide

不安定かつ多様なAPIと連携しなければいけない
では、どのようにプロダクト・サービスとして
サポート・スケールするのか？
API追従の衝撃をビジネス
ロジック側に影響させな
いアーキテクチャ
疎結合の「アーキテクチャ」
それを実現し、かつAPIの変更・追従を隠蔽する
「インターフェース」が鍵
その一つのアプローチとして「JDBC」が活用できる
各チームが独立して機能
追加・アップデート・ビ
ルド・テスト・リリース
が行える体制

View Slide

最後に

View Slide

CData Software Japan では
業務拡大につき新しいメンバーを絶賛募集中！
https://www.wantedly.com/companies/cdata2/projects
・テクニカルサポートエンジニア
・製品開発エンジニア
・インサイドセールス
・ローカライゼーション etc

View Slide

400種類以上のAPI連携を開発・サポートしているデータパイプラインツール CData Sync の中身

400種類以上のAPI連携を開発・サポートしているデータパイプラインツール CData Sync の中身

CData Software Japan

More Decks by CData Software Japan

Other Decks in Technology

Featured

Transcript