ncdc-API20200623

2020/06/23 弊社主催のウェブセミナー資料です。
-------------------------------
【概要】
近年、API（Application Programming Interface）の活用が注目を集めています。
この背景には、さまざまな技術の発展とWebAPIを無償公開するサービスの増加により、APIが容易に導入できて、多くのメリットが得られるものとして進化し続けてきたことが挙げられます。

「API利用＝開発の効率化・開発コストの削減」というイメージされる方が多いと思いますが、具体的にはどの分野で使われてどう効果を上げているのか、API活用の最新事例を知る機会は多くないかもしれません。
そこで、このセミナーでは、マネージャー層向けに他社の事例などを踏まえたAPI活用のヒントをお伝えします。

また、最近は、マイクロサービスアーキテクチャの台頭により、旧来のモノリシックなシステムをWeb APIを活用したマイクロサービスにリプレイスするケースも増えています。
この応用で、レガシーシステムからの脱却を図る際に一からシステムを作り直すことなく、API連携によって段階的な改善を図るという手法もあります。

そのため、API は先進的なIT企業だけでなく、社内にレガシーシステムを抱えてDXが思うように進められない大手企業からも注目されています。

こうしたマイクロサービスアーキテクチャや、レガシーシステムとAPI連携するシステムを設計する際に注意すべきポイントと、実装に必要な知識・スキルについても、セミナー内で解説します。

Transcript

1. マネージャー層向け API活用セミナー 最新の事例とDXへの応用手法を知る 2020/06/23 NCDC株式会社 十川 亮平
2. 取締役/CTO 十川亮平 プレゼンター紹介 NCDCでは、モバイル、API、IoT、機械学習など を使った新規サービスの企画立案や、プロジェ クト推進の支援を担当。 Webサービス／モバイルアプリのバックエンド プラットフォームである「AppPot」のプロダク トマネージャーとして、マーケティング活動や APIの開発を行っている。
3. NCDCのサービス l CX/UXと先端テクノロジーによってデジタルイノベーションを推進します 3 NCDC CX/UX デザイン 先端 テクノロジー 自社 サービス • 新規サービス企画 • CX/UXデザインコンサルティング • IoT/AI • クラウドインテグレーション • モバイル・Web先端技術 • モバイルプラットフォーム [AppPot]の製造・販売 • IoTプラットフォーム • [AppPot IoT]の製造・販売
4. NCDCのサービスの特徴 l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで システムを構築します 4 ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション ITアーキテクチャのデザイン リファレンス実装 DX推進のための組織デザイン
5. 今日お伝えしたいこと l Why API l API周辺のテクノロジー l APIの設計、考慮すべきこと l APIを活用した事例 l NCDCのアーキテクチャ・コンサルティングサービス l バックエンドサービスAppPot 5
6. Why API ・APIのメリット ・マイクロサービス ・ SPA
7. APIとは l APIとは外部からアプリケーションの機能を呼び出すためのインターフェイス l OSがプログラムに提供するAPI、モジュール（部品）を呼び出すためのAPIな ど様々ありますが、本セッションでは 「主にWebサービスを用いて外部から機能を利用するAPI」 についてお話させていただきます。 顧客向け フロントエンド 管理向け フロントエンド 社内の 他システム 他社の 他システム API データベース 7
8. APIとは l APIに含まれるものは主に次の通りです 8 顧客向け フロントエンド 管理向け フロントエンド 社内の 他システム 他社の 他システム API データベース データモデル エンドポイント （呼び出し先） 呼び出し方
9. APIがあると何が嬉しいの？ l APIで公開された機能は、さまざまな場所から利用できる 9 ②APIを境界に 関心を分離できる データやロジックを担 当するAPIはそのままで、 画面側だけを独立して 変更、配信できる。 ①再利用性 いろいろのなクラ イアントから呼び 出すことができる ③自動化 APIがあると プログラムを 使って自動化でき る RPAで人手の作業を 自動化していますが、 本来はAPIが提供さ れていればシステム 同士が連携できる
10. API活用例① マイクロサービス 10 モノリシック （一枚岩）な システム マイ クロ サー ビス 様々な機能を１つのシステ ムで実現。 各機能やデータは密に連携 しているため、システム改 修時に影響範囲が大きく、 変更に時間がかかる マイ クロ サー ビス マイ クロ サー ビス 機能の塊で、システムを分割。 各マイクロサービスは独立性を 保ち、他サービスと連携しなが ら全体の機能を提供するという 考え方 Ex)ECサイトで商品、買い物かご、 決済、顧客管理を別のサービス として構築。 マイクロサービスとは
11. マイクロサービスと技術レイヤー 11 商品 買い物 かご 決済 会計 フロントエンド バックエンド （API） データベース 技術 レイヤー どのような単位で マイクロサービスに分けるか
12. システムの特性に合わせて、採用する技術を組み合わせることが容易になってきている 12 商品 買い物 かご 外部の 決済 サービ ス 既存の 会計 システ ム フロントエンド バックエンド （API） データベース 技術 レイヤー どのような単位で マイクロサービスに分けるか MySQL NoSQL DB Node.js Java 顧客向けフロントエンド
13. システムの特性に合わせて、採用する技術を組み合わせることが容易になってきている 13 商品 買い物 かご 外部の 決済 サービ ス 既存の 会計 システ ム フロントエンド バックエンド （API） データベース 技術 レイヤー どのような単位で マイクロサービスに分けるか MySQL NoSQL DB Node.js Java API連携 API連携 顧客向けフロントエンド API連携 API連携 なぜこのようなことができるかというと、APIを介した連携だから。 APIというインターフェイスが変わらなけれは、 連携先の言語、実行基盤、実態がどこにあるのかが変わっても影響を受けない
14. API活用例② 企業間/社内間システム連携 14 設計 製造 施工管理 運用 A工程 施工 B工程 施工 設計事務所 工場 元請けゼネコン 建物運用 施工会社A 施工会社B 独自 システム 独自 システム 独自 システム Excel Excel 独自 システム 独自 システム 紙 紙 Excel 例えば建設業の例では
15. API活用例② 企業間/社内間システム連携 15 設計 製造 施工管理 運用 A工程 施工 B工程 施工 設計事務所 工場 元請けゼネコン 建物運用 施工会社A 施工会社B 独自 システム 独自 システム 独自 システム Excel 独自 システム 独自 システム API API データ 連携 API RPA APIを利用することでシステム間のデータのやりとりが、 自動化でき、リアルタイム性、正確さが向上します。 ※すべてをAPI化する必要はありません。 リアルタイム性が必要ない部分はデータ 連携を使用したり、システム化の費用対 効果がでない部分はRPAを組み合わせる なども考えられます。
16. APIの活用例③ UXが重視されており、顧客向けのUIを高速に改善したい 16 顧客向け フロントエンド API データベース データモデル、機能は 比較的あまり変わらない UX/UIはどんどん 改善していく APIを境界にフロントエンド（画面）とバックエンド（機能・データ）が 分離され、それぞれが独立して改善、リリースできる
17. とはいえ、APIの管理について気をつける点がいくつかあります 17 顧客向け フロントエンド 管理向け フロントエンド 社内の 他システム 悪意のある クライアント API データベース APIの セキュリティ APIの 仕様の公開 どういう 設計が良いの？ どんな技術で 作るのか？
18. API周辺のテクノロジー ・SOAPからRESTへ ・開発言語のサポート ・コンテナ ・サーバレス ・APIドキュメント
19. 一昔前からのAPI周辺技術の進化 l 一昔前はWeb APIと言えばSOAPというプロトコルでした l WSDL（XML）でインターフェイスを定義 l WS-*などの複雑な仕様 l サポートする言語、ミドルウェアが限定的 l 現在はRESTが一般的 l シンプルな仕様 l HTTPの仕様に合わせており、さまざまな言語で扱いやすい l URL l HTTPメソッド l 応答コード、など 19
20. 様々な開発言語で簡単にAPI化することができます l Java + JAX-RS アノテーションでURLのパスや HTTPメソッドを指定することでWeb サービスを定義できる。 特別なClassの継承や、XMLを書く必要は ない。 20 import javax.ws.rs.GET; import javax.ws.rs.Produces; import javax.ws.rs.Path; @Path("/helloworld") public class HelloWorldResource { @GET @Produces("text/plain") public String getClichedMessage() { // Return some cliched textual content return "Hello World"; } } l Node.js + Express JavaScriptで簡単にWebサービスを書け る const express = require('express') const app = express() app.get('/helloworld ', (req, res) => res.send('Hello World!')) app.listen(3000, () => console.log('Example app listening on port 3000!')) API化が楽というだけで、 APIそのものの開発が楽だとは言ってないです
21. APIの実行基盤としてのコンテナ / サーバレス l APIはサーバーサイドで実行されるため、何らかの環境が必要 l 代表的なものとして、以下があげられますが 本日はコンテナ、サーバレスについてお話します 21 コンテナ オンプレ サーバー IaaS サーバレス サーバー上にOSをセットアップ アプリケーション・サーバー、 Webサーバーなどのミドルウェアを構築 開発したアプリケーションをデプロイ IaaSの場合は、AWS EC2などを利用し、 ハードウェアを意識する必要はない。 主にDockerを使用 して、物理サー バー上に仮想化さ れた環境（コンテ ナ）の中でアプリ ケーションを運用。 物理サーバー上で 多くのコンテナを 動作させることが できるため、１つ のコンテナを小さ く、シンプルにす ることができる クラウドベンダー が提供している仕 組みをなどを利用 して、 開発者はサーバー を意識することな く、開発、運用す ることができる。 実行した分だけの 従量課金が多い
22. コンテナとは l Dockerの仮想化技術がベースとなっている l Kubernetes、AWS ECSなどはDockerコンテナを運用するためのもの （オートスケール、フェイルオーバー、負荷分散など） l 徹底的に自動化ができるようになっている。 22 図は下記より引用 https://www.docker.com/resources/what-container
23. コンテナとは l Dockerの仮想化技術がベースとなっている l Kubernetes、AWS ECSなどはDockerコンテナを運用するためのもの （オートスケール、フェイルオーバー、負荷分散など） l 徹底的に自動化ができるようになっている。 23 図は下記より引用 https://www.docker.com/resources/what-container コンテナの１つとしてAPIが配置される。 負荷に応じてインスタンスを増やした り、障害時に別の環境にフェイルオー バーできる Dockerが動作する別のホストへ コンテナを持っていくことができる 可搬性 本番環境→検証環境 １号機→２号機
24. コンテナとは l コンテナ環境を構築する際に、１つのコンテナ上に沢山の アプリケーションを動かすのではなく、 １つだけにするのがシンプル l 例えばJavaでは、これまではTomcat、JBossなどのアプリケーションサーバー 上で複数のWebサービスを動かしていましたが、 コンテナ時代はSpring Bootのような１コンテナ=１アプリケーションで動かす ための実行基盤が主流 24 図は下記より引用 https://www.docker.com/resources/what-container Java VM Guest OS Application Spring Boot
25. サーバレスとはサーバーが無い？ l 実際には物理的なサーバー上にアプリケーションを配置しますが、 開発者がサーバーや、実行基盤のようなミドルウェアを意識する 必要がありません l 暗黙的にはこのような処理が行われています l 処理の実行回数により課金が行われる 25 アプリケーション サーバー ①処理要求 ビルド済み アプリケーション ②サーバー上に 読み込み ③処理の実行 ④アプリケーションの破棄
26. サーバレスとはサーバーが無い？ l 実際には物理的なサーバー上にアプリケーションを配置しますが、 開発者がサーバーや、実行基盤のようなミドルウェアを意識する 必要がありません l 暗黙的にはこのような処理が行われています l 処理の実行回数により課金が行われる 26 アプリケーション サーバー ①処理要求 ビルド済み アプリケーション ②サーバー上に 読み込み ③処理の実行 ④アプリケーションの破棄 サーバーなどのハード障害はあり得る。 しかし、次の処理要求は別の正常な サーバーで処理される。 サーバーの復旧や、フェイルオーバー などの仕組みを自分たちで考える必要 がない 多少のオーバーヘッドがあります。 サーバーへの読み込み、アプリケー ションの破棄はクラウド側で最適化 される （できるだけ再利用してくれる）
27. サーバレスとコンテナの使い分け マネージドサービス サーバレス コンテナ IaaS 機能 • 提供されたもの を使う • 自前で開発 • 処理が15分以内 • コネクションプール が使えず、DBは RDBMSと相性悪い • 自前で開発 • 自前で開発 アプリフレー ムワーク例 • 使用しない • Serverless Framework • Spring Boot • Spring Boot、 Spring Framework インフラ • クラウドベン ダーに任せる • クラウドベンダーに 任せる • リクエスト数に応じ て使った分だけ課金 • ハードウェア、仮想 化環境はクラウドベ ンダーに任せる • 用意したインスタン スに合わせて課金 • ハードウェアは提供され る。 • OS以上を自前で構築 • 用意したインスタンスに 合わせて課金 運用 • クラウドベン ダー • 基本、クラウドベン ダーに任せる • 機能のリリースなど は自前 • コンテナ管理はクラ ウドベンダー • コンテナイメージ、 アプリは自前 • インフラ管理より下のレ イヤーはクラウドベン ダー • OS、アプリは自前 サービス 例 • AWS Cognito 認証サービス • AWS Lambda • ECS（AWS独自） • EKS（Kubernetes） • EC2 27 • 開発しなくて良い／運用コストが下がる • 制約は大きい やりたいことと提供されるものがあっている場 合には、非常に効果を発揮する。 要件とフィットしていれば、使ったほうが良い • 自由度が高い • 開発、運用の費用は相対的に 大きい
28. 制約はありますが、許容できるならサーバレスがおすすめ l 安い！ l APIが呼び出された量での課金 のため、特に新規事業、新規 サービスのような、ローンチ 時に大量アクセスが無い様な APIの場合、すごく安い l 運用が楽 l サーバーの管理が不要 l 障害時の再起動、フェイル オーバーすら不要 28 https://aws.amazon.com/jp/lambda/pricing/
29. 事例）サーバレスとマネージドサービスをフル活用したアーキテクチャ 29 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知
30. 事例）サーバレスとマネージドサービスをフル活用したアーキテクチャ 30 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知 AWS Lambda サーバレスな処理実装 Cognito マネージドな 認証サービス DynamoDB スケールアウト可能な データベース アプリケーションは S3とCloudFrontで配信
31. もしAPIを広く使ってもらいたいならAPIの使い方の公開はとても重要 31 https://api.slack.com/apis https://docs.apppot.jp/ 閉じられた範囲でのAPIの利用であれば、ExcelやWordで記載されたAPI仕様書で問題ないかも知れませんが、 幅広く使用してもらいたいAPIの場合は、APIの使い方の公開が重要です。 顧客によっては、APIがあることが選定理由になるかも知れません。
32. APIで考慮すべきこと ・APIの設計 ・セキュリティ ・APIマネジメント ・バージョニング
33. APIの開発に必要なスキルセット l APIの開発を行うためにはどんなスキルセットを持った エンジニアが必要でしょうか？ l ただし、以下のような内容をキャッチアップする必要があります l ベストプラクティスはAPIを使う側も理解 している（べき？）ので、基本的なルー ルは説明しなくても分かってもらえる。 l 各種ライブラリがサポートしているので、 作る側、使う側とも楽。 Web APIのベストプラクティスの理解 l DDDやオブジェクト指向などの 設計手法を使って、システムの機能や データをモデリングし、 どのような単位でAPIを作っていくか 設計する APIの粒度や機能の集約の考え方の理解 基本的には、Java、Node.js、Pythonなどでサーバーサイドの プログラミングが書けるエンジニアであれば大丈夫です！ むしろ、これまでのサーバーサイドエンジニアはWebアプリケーションの 画面も開発していたことを考えれば、APIになることでよりバックエンドに集中できる 33
34. APIの設計 34 商品 テーブル 在庫 テーブル 入庫などの操作（メソッド）が 実際にAPIを呼び出す単位。 どのようにAPIを設計すべきか 商品 - 商品マスタ取得API Webアプリ 在庫 - 入庫API - 出庫API - 在庫確認API モバイル アプリ 他システム APIの利用側の要件だけに 従って作ると似て非なる APIが大量にできることに・・・
35. APIの設計 35 商品 テーブル 在庫 テーブル 入庫などの操作（メソッド）が 実際にAPIを呼び出す単位 どのようにAPIを設計していくか。 商品 - 商品マスタ取得API Webアプリ 在庫 - 入庫API - 出庫API - 在庫確認API モバイル アプリ 他システム APIの利用側の要件だけに 従って作ると似て非なる APIが大量にできることに・・・ 在庫、商品などのオブジェクトのデータモデルと、 そのオブジェクトが持つ操作（メソッド）や、データの項目を定義 図の例では、このサービスでの在庫というデータの項目を共通的に定義し、 在庫に対する操作（入庫、出庫、確認など）を洗い出し、それをクライアントに提供するという考え方
36. じゃあどうやってオブジェクトを見つけて定義するのか？ l ドメイン駆動設計（DDD）やオブジェクト指向の手法を使って サービス、システムをモデリングするなどが考えられます 36 エリック・エヴァンスのドメイン駆動設計 モデリングの例
37. APIのベストプラクティスって何？ l RESTful （RESTの原則の則っている）であること l 使用するリソース（機能やデータなど）をURIで識別できること l ステートレスであること l 別のリソースへの参照はリンクで表現する l HTTPのメソッド 例えば、営業部の社員一覧を取得する場合は次のようなURLを GETメソッドで呼び出します https://hostname/company/sales/employees 同じく、営業部の社員番号1440の社員の情報を取得したければ https://hostname/company/sales/employees/1440 RESTfulを理解しているエンジニアが見れば、APIの仕様を見ると 機能ややりとりできる情報が想像できます 37
38. APIのセキュリティ l APIの呼び出し元が正しいことを確認 l 次ページ l APIのスロットリング l スロットリングとは、特定の利用者が大量にAPIを呼び出していたり、悪 意のあるユーザーの攻撃に対して流量制御をかけます l 不正なアクセスの検知 l リクエストの傾向や、通信内容を見て不正アクセスを検知 l WAF（Web Application Firewall）の導入を検討 https://aws.amazon.com/jp/waf/ l 暗号化 l HTTPSを使用した通信経路の暗号化 l APIのネットワーク的なアクセス経路 l 公開レベルに応じて、ネットワーク的に保護 38
39. APIの呼び出し元が正しいことを確認 l APIは機能やデータを公開するため、それを誰に どこまで使わせるのかは慎重に検討する必要があります l APIの呼び出し元の確認には次のようなものがあります l IPアドレス l 特定のIPアドレスのクライアントから利用できる l 通信経路が安全でない場合、IPアドレスのなりすましがあり得る l APIキー l パスフレーズを知っているクライアントから利用できる l 認証済みトークン l ユーザーの認証を行った時に発行されるトークンを検証 l クライアント証明書 l クライアントに証明書を発行 39
40. APIの運用 l 今日は時間の制約がありますのでキーワードだけ l 処理をトレースできる仕組みの検討 l 複数のレイヤーをまたがって処理を行いますので、 どこでエラーが発生したのか、その影響範囲の確認、 どこで時間で時間がかかっているのか を特定するためにリクエストごとに ユニークなIDを発行してフロントエンド、API、 バックエンドの処理ロジックでログに出すような仕組 み l APIのバージョン管理 l APIはいろいろなところから利用される可能性があり ます l 将来的にインターフェイスが変更になった場合に、 多数のクライアントが困らないようにバージョン ごとに並行稼動してクライアントがバージョンを 指定して呼び出し分けることができるような仕組み 40 顧客向け フロントエンド 管理向け フロントエンド API データベース
41. NCDCのAPIに関するサービス・プロダクト
42. NCDCのアーキテクチャ・コンサルティングサービス l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで システムを構築します 42 ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション ITアーキテクチャのデザイン リファレンス実装 DX推進のための組織デザイン
43. NCDCのアーキテクチャ・コンサルティングサービス l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで システムを構築します 43 ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション ITアーキテクチャのデザイン リファレンス実装 DX推進のための組織デザイン システム全体のアーキテク チャの策定 使用する技術、サービスの 選定 アプリケーション開発者が 該当技術に慣れていない場 合、リファレンス実装を行 い技術移管
44. バックエンドサービスAppPot 企業のスマートデバイス活用を支援する モバイルアプリの開発／運用プラットフォームです 44 特徴③ 特徴② 既存の社内システムとの 連携が容易 サーバー開発不要 企業で必要な機能を 実装済み 特徴① ίετ࡟ݮ º ։ൃظؒ୹ॖ
45. AppPotの主要機能 45 Ϣʔβʔ؅ཧ •ログイン／ログアウト •Active Directory／LDAP／Google Appsとの認証 連携 σʔλ؅ཧ •端末とサーバー間のデータの同期 •トランザクション制御によるデータの信頼性 の確保 •オフライン状態での利用と、オンライン時の 再送 ΞϓϦͷ࢖༻ঢ়گͷϞχλϦϯά •使用されている機能やエラー情報の収集、参 照 ϓογϡϝοηʔδɺFϝʔϧ •管理画面やAPI経由でアプリからのPush メッセージの送信 •API経由でeメールの送信 ηΩϡϦςΟ •端末内のデータの暗号化 •SQL Injectionなどのセキュリティ対応済み ଞγεςϜͱͷ࿈ܞ •他システムとのWebサービス、ファイル、 データベースとの連携 •別オプションでERPパッケージ製品との連 携コネクター 各機能を簡単に使⽤するためのWeb APIと、 iOS / Android / JavaScriptのSDKが提供されています
46. AppPotの事例 46 l モバイルアプリ：Monaca上でAngularJSを使ったハイブリッドアプリ l サーバー側処理はAppPotのみで、スクラッチ開発はなし。 l 使っている機能：データ永続化 / Google OAuth認証 / モニタリング / ファイルAPI / 他システム連携アダプタ