rakuten rapidapi エンタープライズ版のご紹介 - apiの開発・利...

53
高速アプリ開発の最前線と企業アプリへの展開 ~Rakuten RapidAPIを活用した新フレームワーク~ June 19, 2019 API Marketplace ビジネス部

Upload: others

Post on 30-May-2020

2 views

Category:

Documents


0 download

TRANSCRIPT

高速アプリ開発の最前線と企業アプリへの展開~Rakuten RapidAPIを活用した新フレームワーク~

June 19, 2019

API Marketplace ビジネス部

2

Agenda

はじめに01

API利用・管理を取り巻く課題02

Rakuten RapidAPI Enterprise Hub03

詳細資料06

Enterprise Hub 導入・PoC04

楽天が提供する価値05

3

APIとは?

モバイルアプリ

Webアプリ

スクラッチ開発

(各種機能をオーガナイズ)

API 活用イメージ

AI関連技術

AI 専業ベンダー/

先端研究所運営企業

セキュリティ、通信専業ベンダー

セキュリティ(MFA 等)

自社製既存機能

自社データ

他部署

外部企業 自社

RESTful API通信

RESTful API通信 RESTful API

通信

RESTful API通信

基幹系システム

01 拡張性

API ベンダー等が継続的にAPIをメンテナンス

API(Application Programming Interface)とはソフトウェア間のインターフェースです。API を通じて特定の機能を持つプログラム部品を他のソフトウェアへ組み込み可能となります。

主な利点

02 品質・先進性

03 高い保守性

04 コスト

必要な機能やデータを要件に応じて適宜利用

該当機能を専業に扱うベンダーの技術を自アプリへ取り込み

“規模の経済”によりAPIに参入するベンダが増える程コスト効率が上がる

ラッパー

4

RESTful Web API 関連市場の拡大

自社製 API の数の変遷 *1 API 専業企業への投資 *2

$480 M $495 M

$1.06 B

2X

2016 2017 2018

RESTful Web API の柔軟な接続性並びに手軽さから、多くの企業が自社の機能の共有目的で活用するようになりました。また、同技術を活用して機能単位で自社サービスやデータを販売する企業も増加の一途を辿っています。

53.6 %40 %

39.2 %

35 %

7.2 %

25 %

2017 2018

割合

実施年

> 1,000

400 - 1,000

< 400

API 導入企業の急増 参加企業の急増による API ビジネス

の隆盛

SURVEY SAYS: SECURITY AND IT PROFESSIONALS ARE CONCERNED ABOUT ENTERPRISE API GROWTHhttps://www.pingidentity.com/content/ping/en/company/blog/posts/2018/security-and-it-professionals-concerned-about-enterprise-api-growth.html

Investments in API Companies Doubled in 2018, Surpassing 1 Billion Dollarshttps://medium.com/the-era-of-apis/investments-in-api-companies-doubled-in-2018-surpassing-1-billion-dollars-2138157065dd

データ出処

*1

*2

Ping Identity 社が米国における100 社以上の IT 関連企業へ行った独自アンケート調査結果

5

自社で全ての機能を開発・実装

主機能

アカウント

管理機能

通知機能

地図機能

決済機能

主機能

API

API

API

APIの利用は開発効率化のキー

既存のAPIを活用

API

アカウント

管理機能

通知機能

地図機能

決済機能

出典:https://martinfowler.com/articles/microservices.html

The Art of UNIX Programming , Eric S.Raymond

各機能を既存のAPIで取り込むことにより開発期間、費用の大幅縮小が可能

6

7

統一キーによる API 呼び出しロジックの簡略化

SDK

リクエストパラメータセット

API 呼び出し

レスポンスのハンドル

AP

I A

コード構造イメージ(Rakuten RapidAPI 利用なし)

SDK

リクエストパラメータセット

API 呼び出し

レスポンスのハンドル

AP

I B

SDK

リクエストパラメータセット

API 呼び出し

レスポンスのハンドル

AP

I C

A 社提供

API

B 社提供

API

C 社提供

API

リクエストパラメータセット

レスポンスのハンドル

AP

I A

通API 呼び出し SDK

リクエストパラメータセット

レスポンスのハンドル

AP

I B

リクエストパラメータセット

レスポンスのハンドル

AP

I C

Rakuten

RapidAPI

A 社提供

API

B 社提供

API

C 社提供

API

共通キーの利用

共通 SDK の利用

利用する API が

多ければ多い程、

効果高

コードのスリム化

コード構造イメージ(Rakuten RapidAPI 利用あり)

Rakuten RapidAPI を介して API を利用する場合、認証は Rakuten RapidAPI 側で行います。そのため、API の呼び出しロジックの集約が可能となり、コードの保守性向上が見込めます。

8

Contents

9

Agenda

はじめに01

API利用・管理を取り巻く課題02

Rakuten RapidAPI Enterprise Hub03

詳細資料06

Enterprise Hub 導入・PoC04

楽天が提供する価値05

10

提供者

APIの提供者IT管理部門

API 利用・管理を取り巻く主な難点APIは便利ではあるものの、正しく運用されなければ高い効果は望めません。API利用者、API運用の管理者、APIの提供者のそれぞれの立場からAPIの種類に合わせて適切な環境や仕組みを講じることが肝要となります。

APIの利用者

API情報の把握

どの API の利用が許可されているかわからない

自社にどのような API があるかわからない

世の中にどのような API があるかわからない

保守性

API毎に認証方法が異なるため、利用するAPIが増える程、コードが膨れ上がり可読性に影響する

APIの数だけ認証キーやトークンが増え、管理が複雑になる

安全の担保

一定の基準をクリアした API のみ利用させたい

部署や役割に応じて利用させる API を明確化したい

管理性

API 利用開始までの流れを統一させたい

有償の API を利用する場合支払先を統一させたい

API の利用状況を全社横断的に俯瞰したい

利用の拡大

自社内、社外向け問わず、潜在利用者の目に留まるプラットフォームで運用し利用件数を増やしたいたい

保守効率

リリースまでの作業をできるだけ自動化したい

ドキュメントと実 API の整合性を確実且つ効率的に維持させたい

運用効率

API の販売管理の煩雑化を避けたい

利用者と双方向コミュニケーションがとれるプラットフォームが欲しい

API は便利ではあるものの・・・

11

Agenda

はじめに01

API利用・管理を取り巻く課題02

Rakuten RapidAPI Enterprise Hub03

詳細資料06

Enterprise Hub 導入・PoC04

楽天が提供する価値05

12

Rakuten RapidAPI Enterprise Hub

Enterprise Hub - API の総合管理プラットフォーム -Enterprise Hub は API の種類を問わず、各関係各所のメンバがそれぞれの観点でAPIをマネジメントするAPI の総合管理プラットフォームです。

IT管理部門

提供者

APIの提供者APIの利用者

3rd Party

API 群8,000+

ガバナンス

マネタイズAPI 管理

API 照会API 利用

自社・他社 APIの積極活用

効果的なAPI 運用

多種多様な APIビジネスを統合管理

自社製

API

外部公開API 群

内部向けAPI 群

弊社運営API

Marketplace

100万+

13

Rakuten RapidAPI Enterprise Hub 機能概要

APIの利用者

3rd Party

API

自社

API

目的

主な機能

IT 管理部門

APIの提供者

アプリ開発効率の向上

Discoverabilityの向上

ユーザ管理アクセス管理 運用の自動化マネタイズ

• 統合化キーアクセス

• 複数言語によるコードスニペット生成

• RapidQL• IDE 統合

• 統合化ドキュメントライブラリ

• タグ管理• コレクション管理

• Web 版クライアントツール

• Active directory連携

• チーム管理

• アクセスモニタ• ロール管理

• Operation API• OpenAPI ファイルインポート

• 警告通知

• マーケットプレイス公開

• API 利用者管理• 双方向コミュニケーションチャネル

• 請求代行

• 統合化キーアクセス

• 複数言語によるコードスニペット生成

• RapidQL• IDE 統合

• 統合化ドキュメントライブラリ

• メトリックス自動生成

• Web 版クライアントツール

N/AN/A

• Active directory連携

• チーム管理• SNS ID 連携

• 利用量のモニタ• 利用料金の支払い

14

Rakuten RapidAPI Enterprise Hub の提供オプション

提供手段 01 White Label 化して提供

Microservice 化ソリューションの一部に組み込み、各サービスのオーケストレーションに活用

自社で保有する各種機能をAPI として社内共有。更に 3rd Party API 利用できる環境を整備し、各種アプリで API を活用。

活用例

活用例の

詳細イメージ

本製品は White Label 化して貴社ブランドとしてエンドユーザーへ納品いただくことも、弊社製品として納品することも可能です。目的に応じて適切な方式をご選択いただけます。

貴社のサービスとして貴社のクライアントへご提供いただけます。

02 Rakuten 製品として提供

貴社環境にてシステム開発の場面等でご活用いただけます。

顧客管理

在庫管理

配送管理

通知サービス

Enterprise

Hub

販売管理システム(フロントエンド) Enterprise Hub

自社 API 群 3rd Party API 群

15

Rakuten RapidAPI Enterprise Hub - 機能一覧API管理

管理用APIを利用してAPIを管理 APIの追加、編集、削除 APIドキュメントの追加、編集、削除 OpenAPI仕様ファイルから自動カタログ登録 分類のためのAPIタグ付け アクセスコントロール(パブリック/セミ/プライベート)

APIキーを利用した認証管理 自社APIの分析情報を確認 価格設定しパブリックマーケットプレイスに公開して収益化 社外ユーザーに利用料金を請求。APIプロバイダは自動的に料

金を受領 特定利用者のブロック、解除 セキュリティ設定の管理(TLS, プロキシシークレットキー等)

権限管理 チーム管理 シングルサインオン Microsoft Active Directoryとの連携 サードパーティログイン: Google, Facebook, Github

ユーザーの一括作成

ユーザー管理

コミュニケーション プロバイダ‐開発者間のメッセージ基盤 コミュニケーションの履歴 カスタムメッセージのプッシュ通知 Subscriber へメッセージの一括(特定グループも可)配信機能

開発者ポータル

API検索 カテゴリやタグによるAPIのフィルタリング APIコレクションのブラウズ APIドキュメントの確認 パフォーマンスの照会 (人気度, 正常稼働率, レイテンシ)

エンドポイントのブラウザからのテスト・設定 コードスニペットを10のプログラミング言語で生成 APIキーの自動生成 豊富な開発者プロファイル(プログラミング言語やバッチ)

APIの購入 APIの評価 OAuth2トークンの取得 IDE 連携

ブランディング ホワイトラベルUI

16

Rakuten Rapid API Enterprise Hub の活用シーンの一例

アプリ開発の効率化

本製品は総合管理プラットフォームであるが故に活用シーンは限定されません。下記で例示しましたように、コスト効率の高い開発環境整備のために活用することもできれば、API ビジネスの促進やマイクロサービス化施策の一部としてもご活用いただけます。

概要

利用場面

期待効果

自社 API 利用活性化 既存アプリ機能の解放API によるマネタイズ

特定の機能開発をAPI で代替

自社開発機能

自社製API

自社開発機能

開発、R&D 費用の回避 迅速な納品 保守費用の回避

全社横断的なAPI ライブラリの提供

総合 API

ライブラリ

API ポートフォリオの最適化 API リスト可視化 利用促進 利用増加 API 開発増進

ドメスティック API エコノミーの確立

納品・保守コストの削減

マーケットプレイス上でAPI を販売

世界中に 100万人を超える登録者を抱えるマーケットプレイスでの販売

マスマーケットへの参加を通じたAPI の販売促進

Enterprise Hub

レガシーシステムの機能やデータへ自社 API と同じプラットフォーム上からアクセス

レガシーシステムの機能やデータを他の自社 API と同様に管理 利用のハードルが下がる

レガシー資産と連携したアプリ開発の促進

クライアントから請け負ったシステム構築案件

自社向けアプリの開発

クライアントが保有する自社API の利用活性化に向けた対策立案

自社固有データや技術を API経由で販売

媒体から API へ販売形態の転換

クライアントのレガシーアプリケーションのマイクロサービス化施策の一部として

貴社利用 クライアント納品 貴社利用 クライアント納品

100万+

API

ラッパー

17

Agenda

はじめに01

API利用・管理を取り巻く課題02

Rakuten RapidAPI Enterprise Hub03

詳細資料06

Enterprise Hub 導入・PoC04

楽天が提供する価値05

18

実装モデル

コスト効率性

セキュリティ、データ保護

パブリッククラウド

オンプレミス

推奨オプション

プライベートクラウドの利点

プライベートサブネットにはVPN / 専用線のみからアクセス可能 パブリックサブネットへのアクセスはオンプレ同様に制限可能

(例、特定のポートのみオープンにする等)

複数リージョンへ配備し、高可用性を確保

安全

効率性

パッチ適用、ロードバランス、オートスケーリング ハードウェアコストが不要 物理的ネットワークのデザインが不要

ロジカルネットワークのデザインのみ

実装モデルの比較

1 パブリッククラウドパブリッククラウド上にすべてのコンポーネントを実装実装ステージにおけるクライアント側の負荷は最小限

プレーン毎に異なるモデルを選択可能

Proxy Plane

オンプレミスor or

クラウド上に貴社に限定したネットワーク領域を確保実装ステージにおけるクライアント側の負荷は最小限

2 (仮想)プライベートクラウド

3 オンプレミス

Management Plane

or

クライアント側のネットワークにすべてのコンポーネントを実装ステージにおけるクライアント側の負荷は大きくなる

プライベートクラウド

パブリッククラウド

パブリッククラウド

プライベートクラウド

プライベートクラウド

19

PoC を通じた効果検証

事前検討環境

セットアップ検証対象 API

を登録ソリューション

検証効果分析

導入モデルの選定

検証対象 API の選定

検証スコープ、検証観点の設計

製品のインストール

貴社環境固有要件に合わせたカスタマイズ

アカウントのセットップ

検証設計に沿ってテスト

操作方法に関する支援

選定した API を登録

操作方法に関する支援

効果測定

報告書の作成

楽天による支援

検証フェーズ 振り返り準備フェーズ

1 week 1 - 2 weeks 1 week 2 - 3 weeks 1 - 2 weeks

本格検討に先立ち、まずは貴社資産或いは検討中のプロジェクトの資産を利用した効果検証の実施を推奨しております。検証期間中の環境セットアップや技術支援についても承れます。

標準的な Rakuten RapidAPI Enterprise Hub PoC 実施アプローチ

サンプル所用期間

20

テクニカルサポートモデル

Tier 1

貴社との総合窓口

一次受付 既知の問題で

あるかの確認 エスカレー

ション 障害追跡

日本語でお問い合わせ

Tier 3

Tier 2

有識者による技術サポート

再現テスト 各種トラブルシューティング技法を駆使して問題解決

回避策提供

開発部門との協業調査

ソースコード解析等による問題追跡

障害改修 回避策提供

既知の問題でない場合

ソースコードの解析が必要な場合

回答

回答

• 正式見解の報告• 一次回答

テクニカルサポートフロー

標準テクニカルサポートサービス

よりサービスレベルの高いプレミアムサポートサービスも有償で承れます。

お問い合わせ

• 電話• チャット平日 9:00 – 17:00

• メール24 時間、365 日受付

製品アップデート

一次回答所用時間 1 営業日以内

パッチ提供Severity Level = High と判断された障害については無償でパッチ提供

無償提供

オンサイトサポート

問題の重要度に応じて適宜判断

Rakuten RapidAPI の利用料にはテクニカルサポートサービスが含まれます。このサービスは PoC 期間中も提供されます。また、より迅速なサービス等を提供するプレミアムサポートについても要件に応じて承れます。

21

Agenda

はじめに01

API利用・管理を取り巻く課題02

Rakuten RapidAPI Enterprise Hub03

詳細資料06

Enterprise Hub 導入・PoC04

楽天が提供する価値05

22

自社における運用経験世界最大級の API 基盤

100 万人を超える巨大コミュニティ

海外ベンダーを巻き込んだ推進能力

弊社は数々の海外企業と協業を重ねて参りました。この経験は

本製品を開発する R Software との協業にも活かされています。

Rakuten RapidAPI は 100 万人を超える技術者が登録する巨大開発者コミュニティです。本プラットフォーム上で API 公開することはこの巨大コミュニティへの公開を意味します。

本日ご紹介した製品は既にユーザとして弊社が運用する製品です。実運用で露見された課題は製品へ反映させ、貴社支援時は実際に培った知見をプロジェクトへ還元させます。

Rakuten RapidAPI には8,000を超えるAPIが登録されています。この数は

今後も増え続ける見込みです。この豊富な選択肢の中から目的に

即した APIをご利用いただけます。

Contents

楽天が展開するユニークな提供価値楽天は本製品のコンセプト並びに世界最大規模の API 基盤やコミュニティに賛同し、自社の API 運用でも本製品を活用しています。ベンダーとしての知見に加えユーザとしての知見の両軸から支援いたします。

23

Case

Study

従業員

業態

拠点

楽天株式会社

17,214 人

(2018年12月時点)

インターネットサービス事業、

金融サービス事業等、70 を超える

各種事業

本社: 東京

30 以上の国と地域に事業

所を展開

ワンストップサービス

IT 管理部門の負担軽減API の積極活用

高機能な標準化ポータル

API の管理部門が関連作業により忙殺• API に関する問い合わせ対応• API 提供者と API 利用者をつなぎ合わせるための会議セットアップ並びにアテンド

組織横断的なAPI 利用多くの事業部門が API を開発し機能やデータを積極的に共有してはいたものの、多くは事業部門内での利用に留まり、事業部を超えた利用は稀

IT サイロ 関連する各種庶務各システムに類似機能が散在し、それぞれ各事業部門が独自に開発。(画像加工処理、合成処理等)

API 関連情報が全てまったポータルサイトを導入• 開発者は同サイト上で各種資産を API として自社向けに公開可能

• API 利用者は同サイト上で要件に応じて様々な観点から API を検索

• ドキュメンテーションフォーマットの標準化により API に関する学習効率を向上

• サイトに実装されたテスト機能等の活用により評価期間を短縮

API 開発の活性化

• 各部門が新規に API を積極的に開発

• API を開発する部門の増加

• 様々なシステム開発の現場で API を採用

• セルフサービス形式のポータルの導入により IT 管理部門の稼働を軽減

チャレンジ

ソリューション

結果

24

Agenda

はじめに01

API利用・管理を取り巻く課題02

Rakuten RapidAPI Enterprise Hub03

詳細資料06

Enterprise Hub 導入・PoC04

楽天が提供する価値05

25

Agenda

詳細資料06

06 – 01 アプリケーション開発に対する期待とAPIの利用

06 – 02 API利用・管理を取り巻く課題

06 – 03 Rakuten RapidAPI Enterprise Hub

06 – 04 典型的な課題・難点

26

企業アプリケーションに開発に対する期待の変遷と対応策

コスト

納期

年々より高速且つ低コストなデリバリーへと期待値が高度化

$$$

$

主な対応策

基盤調達 Cloud

プロビジョニング コンテナ

アプリコード API

開発プロセス DevOps

デリバリーに対する期待値の変遷

近年、グローバル化の進展や各種技術革新に伴い、アプリ開発におけるコストや納期に関する要求は厳しくなる一方です。これに対して API は手軽にコード量そのものを削減しつつ要件を実現する施策として注目を集めています。

27

主な API の一覧及び RESTful Web API の位置付け一言で API と言ってもその解釈は様々です。Enterprise Hub が対象とするRESTful Web API はその中でもWeb Service にカテゴライズされるもので、ステートレスや統一インターフェースを特徴としています。

Web Service APIsWeb アプリケーションサーバー上で稼働するサービスへ URI 等を通じてアクセスし、動作させる手法

GraphQL API

RESTful Web API

SOAP Web API

XML-RPC

JSON-RPC

Library-based APIsスクリプトやバイナリをインポートもしくは参照した上で、ベンダーが提供する各種ルーチンや関数を利用する手法

JavaScript API

TWAIN API

Oracle Call Interface API

Java API

Android API

Object remoting APIsローカル上の proxy オブジェクトを通じてリモート環境で稼働するオブジェクトを利用する手法

CORBA

.NET Remoting

プラットフォーム提供 APIsアプリケーションが稼働するプラットフォームが、そのプラットフォームへアクセスするためのルーチンや関数として提供する API

OS が提供する API(ファイルアクセス等)

Video acceleration

Hard disc drives

外部プロセスとの連携 同一プロセス上で連携

28

RESTful Web API活用による各種依存からの解放

Linux Native App

Windows .NET App

JVM App

Mobile App

Web Server Side(Script系)

実行形式

(C/C++/COBOL)

.NET Managed 実行形式

(C#/VB.NET/F#)

実行可能 jar ファイル

(Java/Scala)

Node.js/PHP/Python/Go

Ruby/Perl/Elixir

Android(Android Java)

iOS(Objective-C/Swift)

共有ライブラリ libXXX.so

(C/C++/COBOL)

.NET Managed.dll

(C#/VB.NET/F#)

JVM パッケージ

(Java/Scala)

それぞれの言語に合わせて準備 / ツールの利用

.jar Android(Android Java)

それぞれの言語で準備

各アプリケーションフォーマットないし言語に合わせてそれぞれ準備 1

アプリケーションフォーマットやプログラミング言語問わず共通アクセス

組織の要件に合わせて適切な言語で API の開発が可能

モジュールを1つに集約できるため、保守効率化が見込める3

2

主なポイント

共通機能を RESTful Web API として連携共通機能をルーチンとして連携

RESTful Web API は従来のライブラリと異なり、連携アプリの形式やプログラム言語非依存です。RESTful Web API として共通機能を管理することで保守や管理効率の向上が見込めます。

RESTful Web API

(C#/VB.NET/Java/Scala/Node.js/PHP/Python/Go/Ruby/Perl/Elixir 等)

29

3rd Party API 活用による各種機能の組み込み

ID管理B2Cトラベルアプリの各種機能を 3rd Party API

で組み上げた場合の例

3rd Party API を活用することで各種機能を自社でスクラッチ開発することなくアプリへ取り入れることが可能となります。利用する API は基本的に利用量に応じた従量課金となり、目的に応じた利用が可能です。

Added punchline

クレジットカード決済

MFA

フライト予約

ホテル予約

温泉旅館予約

レストラン予約

地図

Facebook for ID

Booking.com

Skyscanner

Google Maps

Jalan.net

Nexmo Verify

機能開発に伴う期間、コストの削減

専業ベンダによる高度な機能の取り込み

機能の保守は API Provider 側で行う

利用量に応じた従量課金

期待効果

30

追加機能を 3rd Party API で実装した場合のプロセスイメージ

要件

機能開発

リリース

アプリケーション結合

R&D 実装 試験設計 設計 実装 試験

要件APIを選択

リリース

アプリケーション統合

設計 実装 試験

期間、コストの圧縮!

1 2

対象機能を自社開発

2

対象機能を自社開発する場合は、追加機能と既存アプリの結合処理を実装。API を活用する場合は、API の Consume ロジックを実装。API の呼び出しロジックを共通化できれば以降のAPI 活用においては本プロセス自体の圧縮も期待できる。

1対象機能の開発をAPIで代替

Redesign

対象機能を3rd Party API で

取り込み

既存のアプリケーションに新機能を実装する際、3rd Party API にその機能を委譲することでその開発に伴う期間並びにコスト大幅に圧縮することが期待できます。

31

Agenda

Appendix06

06 – 01 アプリケーション開発に対する期待とAPIの利用

06 – 02 API利用・管理を取り巻く課題

06 – 03 Rakuten RapidAPI Enterprise Hub

06 – 04 典型的な課題・難点

32

提供者

APIの提供者IT管理部門

3rd Party API に関連した主な課題3rd Party API の活用が迅速なアプリ開発に寄与することは自明ではありますが、それには正しい API を選択することが条件となります。また、利用する API が増えれば増える程、管理が複雑化します。

APIの利用者

API情報の把握

どの API の利用が許可されているかわからない

自社にどのような API があるかわからない

世の中にどのような API があるかわからない

保守性

API毎に認証方法が異なるため、利用するAPIが増える程、コードが膨れ上がり可読性に影響する

APIの数だけ認証キーやトークンが増え、管理が複雑になる

管理性

API 利用開始までの流れを統一させたい

有償の API を利用する場合支払先を統一させたい

API の利用状況を全社横断的に俯瞰したい

API は便利ではあるものの・・・

保守効率

リリースまでの作業をできるだけ自動化したい

ドキュメントと実 API の整合性を確実且つ効率的に維持させたい

安全の担保

一定の基準をクリアした API のみ利用させたい

部署や役割に応じて利用させる API を明確化したい

利用の拡大

自社内、社外向け問わず、潜在利用者の目に留まるプラットフォームで運用し利用件数を増やしたいたい

運用効率

API の販売管理の煩雑化を避けたい

利用者と双方向コミュニケーションがとれるプラットフォームが欲しい

33

API マーケットプレイス「Rakuten RapidAPI」の活用

punchline

Rakuten RapidAPI は楽天が運営する世界最大級の API のマーケットプレイスです。API利用に関する課題を解決します。Enterprise Hubはこのマーケットプレイス上のカタログ、並びに API 公開・運用機能を利用します。

楽天が運営する世界最大級のAPI Marketplace

アプリ開発者 API Provider

Rakuten RapidAPI Enterprise Hub

8,000+

カタログ検索

Proxy

API を公開

収納代行

1,000,000+

カタログの共有 API を公開

収納代行

34

提供者

APIの提供者IT管理部門

企業特有の API 管理に関する課題API を開発してもそれらが適切に利用されなければ高い ROI は望めません。また、組織や企業を超えてデータ授受する API を無条件で解放するのも情報漏えい等のリスクが潜みます。全体を俯瞰した運用設計が肝要となります。

APIの利用者

API情報の把握

どの API の利用が許可されているかわからない

自社にどのような API があるかわからない

世の中にどのような API があるかわからない

利用の拡大

自社内、社外向け問わず、潜在利用者の目に留まるプラットフォームで運用し利用件数を増やしたいたい

API は便利ではあるものの・・・

保守性

API毎に認証方法が異なるため、利用するAPIが増える程、コードが膨れ上がり可読性に影響する

APIの数だけ認証キーやトークンが増え、管理が複雑になる

保守効率

リリースまでの作業をできるだけ自動化したい

ドキュメントと実 API の整合性を確実且つ効率的に維持させたい

運用効率

API の販売管理の煩雑化を避けたい

利用者と双方向コミュニケーションがとれるプラットフォームが欲しい

安全の担保

一定の基準をクリアした API のみ利用させたい

部署や役割に応じて利用させる API を明確化したい

管理性

API 利用開始までの流れを統一させたい

有償の API を利用する場合支払先を統一させたい

API の利用状況を全社横断的に俯瞰したい

35

各部門が個別に API 運用する場合に陥りがちな問題点

オンプレミス

機能 K

機能 L

機能 B

API ゲートウェイ

機能 M

機能 F

機能 N

部署 3

機能 G

機能 F

機能 H

API ゲートウェイ

機能 I

機能 J

機能 B

部署 2

機能 A

機能 B

機能 C

API ゲートウェイ

機能 D

機能 E

機能 F

部署 1

クラウド上の自社

AP

I

punchline

各部門がそれぞれ保有する API を管理する場合、保有 API に関する情報がその部門内に閉じてしまうことが懸念されます。これにより組織内における API 活用を障ねることになる可能性も否めません。

Swagger

ポータル

仕様書

confluence

ポータル

仕様書

MS Office

ポータル

仕様書

社内APIの分散管理がAPI 活用の足かせとなりAPI 活用が当初の期待通りに上がらない

36

組織横断的な API のワンストップサービスの導入

オンプレミス

機能 K

機能 L

機能 B

API ゲートウェイ

機能 M

機能 F

機能 N

部署 3

機能 G

機能 F

機能 H

API ゲートウェイ

機能 I

機能 J

機能 B

部署 2

機能 A

機能 B

機能 C

API ゲートウェイ

機能 D

機能 E

機能 F

部署 1

クラウド上の自社

AP

I

Enterprise Hub

企業内全 API の仕様書を掲載

共通フォーマット Swaggerからの

変換 簡単な管理

ドキュメントライブラリ

全情報の集約 APIの検索 APIのテスト APIの評価 指標値の確認 APIをフォロー

ポータル

社内 API の統合ポータルを導入し、組織が保有する API 情報を共有。同ポータル上で実際に API を呼び出し評価等を行い要件に即した API を効率的に探知。

punchline

社内で保有する API に関する情報を Enterprise Hub へ集約することで API に関する情報取得が円滑化され、API 利用促進に繋がります。同時に重複 API 開発防止も期待できます。

37

提供者

APIの提供者IT管理部門

企業特有の API 管理に関する課題API を開発してもそれらが適切に利用されなければ高い ROI は望めません。また、組織や企業を超えてデータ授受する API を無条件で解放するのも情報漏えい等のリスクが潜みます。全体を俯瞰した運用設計が肝要となります。

APIの利用者

安全の担保

一定の基準をクリアした API のみ利用させたい

部署や役割に応じて利用させる API を明確化したい

管理性

API 利用開始までの流れを統一させたい

有償の API を利用する場合支払先を統一させたい

API の利用状況を全社横断的に俯瞰したい

API は便利ではあるものの・・・

API情報の把握

どの API の利用が許可されているかわからない

自社にどのような API があるかわからない

世の中にどのような API があるかわからない

保守性

API毎に認証方法が異なるため、利用するAPIが増える程、コードが膨れ上がり可読性に影響する

APIの数だけ認証キーやトークンが増え、管理が複雑になる

利用の拡大

自社内、社外向け問わず、潜在利用者の目に留まるプラットフォームで運用し利用件数を増やしたいたい

運用効率

API の販売管理の煩雑化を避けたい

利用者と双方向コミュニケーションがとれるプラットフォームが欲しい

保守効率

リリースまでの作業をできるだけ自動化したい

ドキュメントと実 API の整合性を確実且つ効率的に維持させたい

38

ロール管理 ユーザー認証管理ソフト

フェアとの統合 タグ付け機能 ログ/分析機能

ポリシー指向ガバナンスの適用

Enterprise Hub

アクセスポリシーの定義

ロールの範囲► チームの定義► チームの役割や責任に即したロールの定義

API アクセスポリシー► 例) 管理者限定 API

► 例) チーム限定 API 等

IAM 活用による内部統制管理

► Enterprise Hub の利用者を設定► 各ユーザーを定義したチームへ配置► 定義に基づきチームへロールを付与► 定義した API アクセスポリシーに基づき参照可否をタグで構成

アクセスポリシーの徹底

► SSO を活用した効率的且つセキュアなアクセス

► ロール設定を基にしたアクセス管理並びに権限管理

► タグを基にした閲覧制限(例: 特定のチーム向け API は該当チームメンバーのみにアクセスを限定)

アクセスおよび利用の監査

アクセスログ► 異常状態な検知・分析利用状況の分析► API 利用者のプロフィール► API の稼働状況► レイテンシ► 外部公開した場合は売上状況

punchline

計画 構成

モニタ 実行

IT 管理者の視点から組織メンバーの API 利用管理を促進する各種機能が Enterprise Hub には実装されています。これらを駆使することで必要なメンバーに必要な API だけを利用させるための環境の整備が可能となります。

39

提供者

APIの提供者IT管理部門

API 運用の効率化に関する課題API のドキュメント基盤を整えても、それが API 保守ととも整合性が維持されないとプラットフォームの導入意義が覆ります。また、コストやリスクの観点から人的作業は可能な限り回避が必要です。

APIの利用者

API情報の把握

どの API の利用が許可されているかわからない

自社にどのような API があるかわからない

世の中にどのような API があるかわからない

保守性

API毎に認証方法が異なるため、利用するAPIが増える程、コードが膨れ上がり可読性に影響する

APIの数だけ認証キーやトークンが増え、管理が複雑になる

安全の担保

一定の基準をクリアした API のみ利用させたい

部署や役割に応じて利用させる API を明確化したい

管理性

API 利用開始までの流れを統一させたい

有償の API を利用する場合支払先を統一させたい

API の利用状況を全社横断的に俯瞰したい

利用の拡大

自社内、社外向け問わず、潜在利用者の目に留まるプラットフォームで運用し利用件数を増やしたいたい

保守効率

リリースまでの作業をできるだけ自動化したい

ドキュメントと実 API の整合性を確実且つ効率的に維持させたい

API は便利ではあるものの・・・

運用効率

API の販売管理の煩雑化を避けたい

利用者と双方向コミュニケーションがとれるプラットフォームが欲しい

40

管理操作オプション

管理者

管理ポータル

オペレーションチーム

Rakuten RapidAPI

Enterprise Hub

API登録 ドキュメント管理 分析情報確認

利用者管理 権限管理 ログの確認

同等の処理

管理API API登録 ドキュメント管理 分析情報確認 利用者管理 権限管理 ログの確認

Rakuten RapidAPI

Enterprise Hub

起動

ポータルの利用 APIを介したオペレーション

Redesign

オプション1 オプション2

Rakuten RapidAPI Enterprise の各種操作は Web ベースのポータルサイト上で行います。また、同等の管理操作をAPI を通じて自動化することも可能です。

41

管理 API の利用例

1 運用 API とドキュメントの整合

2 カタログ更新の自動化

開発

コーディング単体試験 機能試験

デリバリー

オペレーション

Rakuten RapidAPI Enterprise Hub

構成管理

オーケストレーション

デプロイメント

Swagger生成

カタログ更新

Swagger生成 カタログ更新

APIPGM ソース

Swaggerファイル

管理 API

Swagger 生成ツール例) express-swagger-generator

NodeJS で API を開発・運用 開発自動化ロフーにおけるデリバリープロセスに管理

API を組み込み、Enterprise Hub への登録・更新も含めて自動化

利用者

活用シナリオ

API Provider

Enterprise Hub へ登録する API エンドポイントスキーマ情報は Swagger ファイルからインポートしてカタログへ自動展開が可能です。このカタログの基となる Swagger ファイルをソースから生成し、実コードと同期をとることによりポータル上に表示される情報と実際の API の挙動を整合させることが可能となります。

Enterprise Hub への情報更新を管理ポータルで手入力するのではなく、自動処理プロセスに組み入れることで反映漏れを防止しつつ処理の高速化が期待できます。

API Provider が API を更新後、手動で変更情報を Enterprise Hub へ反映させるのではなく、管理 API 等を駆使して自動化プロセスに組み入れることで確実なドキュメント整合並びに更新の効率化が期待できます。

Redesign

42

Agenda

Appendix06

06 – 01 アプリケーション開発に対する期待とAPIの利用

06 – 02 API利用・管理を取り巻く課題

06 – 03 Rakuten RapidAPI Enterprise Hub

06 – 04 典型的な課題・難点

43

Rakuten RapidAPI Enterprise Hub 全体概要

3rd

Party

APIs

AWS

Lambda

API ゲートウェイ

クラウド

公開 APIとして運用

内部API

内部API

内部API

公開API

公開API

公開API

オンプレミス

部署 A 管理

3rd Party APIs

3rd Party API 群

8,000+

統一プロキシ

ドキュメントライブラリ

部署 A 管理 API

部署 B 管理 API

3rd Party API

3rd Party API

API

呼び出し

ツール

etc3rd Party

APIs

API ゲートウェイ

内部API

内部API

内部API

公開API

公開API

公開API

オンプレミス

部署 B 管理

IBM メインフレーム

z/OS Connect

Rakuten RapidAPI Enterprise Hub は内部向けAPI、公開API、外部企業が運営するAPI問わず横断的に管理可能な各種ポータル並びに全 API へのアクセスを統合するプロキシで構成されます。

ータ

Rakuten RapidAPI Enterprise Hub

部署Aメンバ

部署Bメンバ

他部署メンバ

IT管理部門

API の Consume

全社メンバ

管理

ツール群

44

システム関連図 – 典型パターン

API 管理 / 環境保全

API 呼び出し

Proxy planeP

rox

y S

erv

ice

1

Node2(RHEL)

kubelet

kube-proxy

Node1(RHEL)

kubelet

kube-proxy

Cac

he

DB

Redis

RHEL

Kuberneters Master

RHEL

etcd

kube-apiserver

kube-controllermanager

kube-scheduler

Management plane

Portal

Web App

Admin

Web App

Provider

Admin

Web App

Developer

Admin

Web App

Org Mgmt

Web App

3rd Party APIs

Pro

xy S

erv

ice

2

Node2(RHEL)

kubelet

kube-proxy

Node1(RHEL)

kubelet

kube-proxy

貴社 API

Dept 1

Dept 2

Authentication plane

MicrosoftADFS

MicrosoftADDS

IT 管理部門 API プロバイダ API 利用者

貴社 API の利用者

Private Network

Redis

RHEL

Proxy AgentRHEL

45

3rd Party を活用した高度且つ簡易な認証・権限管理

エンタープライズ版

認証プレーン(自社内)

MicrosoftADFSサーバ

MicrosoftADDSサーバ

ユーザー権限管理

ログ監視コントロール

1

3

2

7

8

4

5

6

1ユーザーがエンタープライズ版にアクセスし、ログインをクリック

ユーザー

SSO URLにリダイレクト

ログイン情報を入力

ADDSへログイン情報を問い合わせ

ログインを認証

暗号化されたSAMLを返答

ブラウザがポータルにSAMLを送信

アクセスを承認

2

3

4

5

6

7

8

認証管理

権限管理レイヤーに受け継がれる

9

9

ハイライト

低コスト

既知で承認済みの技術を利用

既存の認証機能を利用可 ユーザーは新たに認証情報を

作成する必要がない

高機能 サードパーティベンダーの

技術を利用

コンプライアンス

主要機能補足

46

公開した API の管理・保守イメージRakuten RapidAPI 上に公開した API の利用状況についてはプロバイダポータル上で照会可能です。また、同ポータル上で API の利用者とメールアドレス等を明かさずに双方向コミュニケーション可能です。

各種統計情報の照会 利用者とのコミュニケーション

API Consumers

API Provider

質問等を送信

サービスページ

プロバイダポータル

逆方向も可能

プロバイダポータル

公開中の API の利用状況(任意の期間中の Call 数等)

Subscribe ユーザの情報 利用者毎の請求金額 Call 毎のログ情報 公開する Discussion ボードへ投稿されたメッセージ

ポータルで照会可能な主な情報

主要機能補足

47

Rakuten RapidAPI(公開版) vs Enterprise Hub

APIの利用者

3rd Party

API

自社

API

目的

主な機能

IT 管理部門

APIの提供者

アプリ開発効率の向上

Discoverabilityの向上

ユーザ管理アクセス管理 運用の自動化マネタイズ

• 統合化キーアクセス

• 複数言語によるコードスニペット生成

• RapidQL• IDE 統合

• 統合化ドキュメントライブラリ

• タグ管理• コレクション管理

• Web 版クライアントツール

• Active directory連携

• チーム管理

• アクセスモニタ• ロール管理

• Operation API• OpenAPI ファイルインポート

• 警告通知

• マーケットプレイス公開

• API 利用者管理• 双方向コミュニケーションチャネル

• 請求代行

• 統合化キーアクセス

• 複数言語によるコードスニペット生成

• RapidQL• IDE 統合

• 統合化ドキュメントライブラリ

• メトリックス自動生成

• Web 版クライアントツール

N/AN/A

• Active directory連携

• チーム管理• SNS ID 連携

• 利用量のモニタ• 利用料金の支払い

Rakuten RapidAPI は Enterprise Hub の主要機能のうち、3rd Party API の利用と自社 API のマーケットプレイス上での運用支援機能を焦点を定め公開運用するサブセット製品です。

• 3rd API の利用• 自社 API の公開・販売関連機能に焦点を絞って一般公開したサブセット製品

48

Agenda

Appendix06

06 – 01 アプリケーション開発に対する期待とAPIの利用

06 – 02 API利用・管理を取り巻く課題

06 – 03 Rakuten RapidAPI Enterprise Hub

06 – 04 典型的な課題・難点

49

メインフレームアプリロジック・データの解放(1 / 3) IBM メインフレームを例にとり、アプリケーションの実行結果をオープン環境で利用する場合の、フローを例示します。様々なアプリを介してオープン環境で参照可能な状態へ加工する必要があり大きなタイムラグを伴います。

z/OS(IBM メインフレーム)

オンラインアプリケーション

バッチアプリケーション

DB2RDB

VSAMKSDS

IMS階層型 DB

VSAMESDS

VSAMESDS

(EBCDIC)

バッチアプリケーション

レコード順ファイル(ASCII)

CSVファイル

12

3

4 5

6

Linux

Windows 1TN3270 エミュレーターを使い、オンラインアプリケーションを実行

IBM 3270プロトコル

2

3

4

7

7

6

5

オンラインアプリケーションが結果データを生成

制御データを含まないレコード順編成ファイルへデータ変換するバッチアプリケーションを

スケジューラーによる定期起動、もしくは TSOコマンド等で随時起動

FTP ツールを利用し、ファイルを Linux 環境へ転送

ファイル中の文字コードを EBCDIC から

ASCII(日本語を含む場合は UTF8 もしくはSJIS) へ変換

レコード順ファイルをよりポータビリティの

高い CSV 形式へ変換

アプリケーション経由、もしくは直接生成された結果ファイルを参照

実行からデータの利用までに大きなタイムラグ

複雑なフロー

典型的な課題・難点

punchline

50

メインフレームアプリロジック・データの解放(2 / 3) メインフレームアプリケーションは RESTful API としてアクセスすることが可能です。API アクセス可能となれば Enterprise Hub を活用しその他 API と同様にアクセス/活用が可能となります。

z/OS(IBM メインフレーム)

CICS

バッチ

DB2(RDB)

VSAMKSDS

IMS階層型 DB

VSAMESDS

1

IMS

TMオンライン

IBM

z/OS Connect EEまたは

OpenLegacy

API Connectors

Enterprise Hub

内部 API パブリック API外部公開 API

RESTful APIとしてアクセス

A

B

A メインフレーム上のロジックを解放

企業固有の十進演算ロジック等メインフレーム

上で長年保守されてきた企業資産へ自社ア

プリ等からタイムラグなくアクセス可能とさせま

す。IBM z/OS Connect EE や

OpenLegacy API Connectors 等を

活用すれば、プログラムを書き換えることなく

メインフレーム資産へアクセス可能となります。

B 他の API と同様にアクセス・管理

RESTful API アクセスが可能となった自社の

ビジネス価値の高いレガシーロジックへのアクセ

ス情報を Enterprise Hub へ登録すること

で、利用者は Enterprise Hub へ登録された

他の API と同様にこれらへのアクセスが可能と

なります。

解決策1IBM Mainframe の場合

punchline

51

メインフレームアプリロジック・データの解放(3 / 3) メインフレーム上で稼働するアプリケーションの各種ロジックは Windows や Linux 環境へオープン化が可能です。更にオープン化したロジックは RESTful アクセスが可能なため、他の API 同様に活用可能となります。

解決策2全 Mainframe 対応

Step1: 解放ロジック選別 Step2: リコンパイル Step3: 運用A 将来的なオープン化の促進

開放したロジックについては実質オープン化

アプリケーションの棚卸しを適宜行うことによ

り、将来的なオープン化の障壁と成り得る

資産を整理可能

B CPU 課金の回避

C システム連携の活性化

IBM富士通日立日本電気

Unisys

zOS, OS/390

OSIV, MSP

VOS3

ACOS-4

OS 2200

COBOLCOBOL PL/IPL/Iアセンプリアセンプリ

• Micro Focus Enterprise Analyzer

• GTONE ChangeMiner等

ビジネスロジック関連資産の抽出

COBOLCOBOL PL/IPL/Iアセンプリアセンプリ

• Micro Focus Enterprise Developer

• Tmaxsoft OpenFrame• (富士通 NetCOBOL

等)

オープン環境向けコンパイラ

Windows, Linuxの Native Code

Enterprise Hub

RESTful APIとしてアクセス

内部 API パブリック API外部公開 API

メインフレームから開放したロジック群

Micro Focus Enterprise Server 等

元のプログラムソースがメインフレームから抽

出したものであってもRESTful API として稼

働するのはオープン環境となるため、メインフ

レームの CPU 課金に関する考慮は不要

開発・保守に関してもオープン環境で実施

手軽にロジックを利用できるようになるため、

環境制約に縛られることなく連携可能

メインフレーム側から順次ビジネスロジックや

データアクセスロジックを開放

punchline

52

サービスページ

https://www.facebook.com/RakutenRapidAPIJP/

https://twitter.com/RakutenAPI_JP

https://www.linkedin.com/company/rakuten-rapidapi-jp/

[英語]

https://english.api.rakuten.net/

SNS

[日本語]

https://api.rakuten.net/