400種類のWeb APIをサポートしているデータパイプラインツールにおけるWeb APIとの共存戦略

© 2023 CData Software Japan, LLC | www.cdata.com/jp
1. About CData Software
400種類以上のWeb API をサポートしている
データパイプラインツールにおけるWeb API との共存戦略
burikaigi 2023
CData Software Japan - Kazuya Sugimoto

View Slide

CData Software Japan の Lead Engineer
これまで300種類以上のAPIを見たり触ったりしている
API中毒な人。
Twitter：@sugimomoto
Facebook：sugimomoto
Blog：https://www.cdatablog.jp/
About Speaker
Software Design 2022年8月号 Web API
特集の第1章「Web APIの目的と技術要素
利用者／提供者の利点や技術的なしくみをひも
解く」を執筆
https://gihyo.jp/magazine/SD/archive
/2022/202208

View Slide

EMPLOYEES
200+
ACTIVE CUSTOMERS
9,000+
OEM PARTNERS
100+
© 2022 CData Software Inc. | www.cdata.com
CData Software
CData Software, Inc.
• 本社：US(NC州), オフィス：日本 / 欧州 / インド / 中国
• データコネクティビティテクノロジーのリーダー
CData Software Japan, LLC
• 宮城県仙台市
• 2016/06 〜

View Slide

© 2022 CData Software Inc. | www.cdata.com
SaaSを中心とする400(API Profile含
む)を超えるデータソース
主要なデータレイク・データベース・
データウェアハウス
CData Sync
400を超えるデータソースのデータをノーコードでデータベースにレプリケーション
シンプルな設定 ETL/ELT 方式高度な差分更新柔軟なジョブ管理
ノーコード、3ステップで
データ統合基盤を構築
標準SQLによるデータ抽出時
での変換、もしくは、データ
ウェアハウスへの取り込み後
の変換どちらにも対応
CDC(ChangeDataCapture)な
どの高度な差分更新メカニズ
ムを搭載
処理負荷を軽減し、日々の
ジョブ実行時間の短縮を実現
オブジェクト（テーブルや項目）、処理方式
（洗い替えor差分など）や条件（一部のレコー
ドのみ）を指定したジョブ作成が可能
作成したジョブはスケジュール、および、Web
APIやコマンドラインで実行可能

View Slide

本日のお話

View Slide

Horizontal SaaS API公開状況調査

View Slide

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

View Slide

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

View Slide

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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

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

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

ここまで多種多様なAPIを相手にしているからこそ
API処理を担うレイヤーは実装が重くなりやすい
Logic
API API API API
だからこそ疎結合の「アーキテクチャ」
APIの変更・追従を隠蔽する「インターフェース」が重要

View Slide

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

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

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

View Slide

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

View Slide

なぜ「JDBC」を採用？

View Slide

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

View Slide

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

View Slide

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

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

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

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

まとめ

View Slide

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

View Slide

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

View Slide

CData Software Japan では業務拡大につき
新しいメンバーを北陸でも絶賛募集中！
プロダクトスペシャリスト
https://www.wantedly.com/projects/911512

View Slide

400種類のWeb APIをサポートしているデータパイプラインツールにおけるWeb APIとの共存戦略

400種類のWeb APIをサポートしているデータパイプラインツールにおけるWeb APIとの共存戦略

CData Software Japan

More Decks by CData Software Japan

Other Decks in Technology

Featured

Transcript