Slide 1

Slide 1 text

マネージャー層向け API活用セミナー 最新の事例とDXへの応用手法を知る 2020/06/23 NCDC株式会社 十川 亮平

Slide 2

Slide 2 text

取締役/CTO 十川亮平 プレゼンター紹介 NCDCでは、モバイル、API、IoT、機械学習など を使った新規サービスの企画立案や、プロジェ クト推進の支援を担当。 Webサービス/モバイルアプリのバックエンド プラットフォームである「AppPot」のプロダク トマネージャーとして、マーケティング活動や APIの開発を行っている。

Slide 3

Slide 3 text

NCDCのサービス l CX/UXと先端テクノロジーによってデジタルイノベーションを推進します 3 NCDC CX/UX デザイン 先端 テクノロジー 自社 サービス • 新規サービス企画 • CX/UXデザインコンサルティング • IoT/AI • クラウドインテグレーション • モバイル・Web先端技術 • モバイルプラットフォーム [AppPot]の製造・販売 • IoTプラットフォーム • [AppPot IoT]の製造・販売

Slide 4

Slide 4 text

NCDCのサービスの特徴 l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで システムを構築します 4 ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション ITアーキテクチャのデザイン リファレンス実装 DX推進のための組織デザイン

Slide 5

Slide 5 text

今日お伝えしたいこと l Why API l API周辺のテクノロジー l APIの設計、考慮すべきこと l APIを活用した事例 l NCDCのアーキテクチャ・コンサルティングサービス l バックエンドサービスAppPot 5

Slide 6

Slide 6 text

Why API ・APIのメリット ・マイクロサービス ・ SPA

Slide 7

Slide 7 text

APIとは l APIとは外部からアプリケーションの機能を呼び出すためのインターフェイス l OSがプログラムに提供するAPI、モジュール(部品)を呼び出すためのAPIな ど様々ありますが、本セッションでは 「主にWebサービスを用いて外部から機能を利用するAPI」 についてお話させていただきます。 顧客向け フロントエンド 管理向け フロントエンド 社内の 他システム 他社の 他システム API データベース 7

Slide 8

Slide 8 text

APIとは l APIに含まれるものは主に次の通りです 8 顧客向け フロントエンド 管理向け フロントエンド 社内の 他システム 他社の 他システム API データベース データモデル エンドポイント (呼び出し先) 呼び出し方

Slide 9

Slide 9 text

APIがあると何が嬉しいの? l APIで公開された機能は、さまざまな場所から利用できる 9 ②APIを境界に 関心を分離できる データやロジックを担 当するAPIはそのままで、 画面側だけを独立して 変更、配信できる。 ①再利用性 いろいろのなクラ イアントから呼び 出すことができる ③自動化 APIがあると プログラムを 使って自動化でき る RPAで人手の作業を 自動化していますが、 本来はAPIが提供さ れていればシステム 同士が連携できる

Slide 10

Slide 10 text

API活用例① マイクロサービス 10 モノリシック (一枚岩)な システム マイ クロ サー ビス 様々な機能を1つのシステ ムで実現。 各機能やデータは密に連携 しているため、システム改 修時に影響範囲が大きく、 変更に時間がかかる マイ クロ サー ビス マイ クロ サー ビス 機能の塊で、システムを分割。 各マイクロサービスは独立性を 保ち、他サービスと連携しなが ら全体の機能を提供するという 考え方 Ex)ECサイトで商品、買い物かご、 決済、顧客管理を別のサービス として構築。 マイクロサービスとは

Slide 11

Slide 11 text

マイクロサービスと技術レイヤー 11 商品 買い物 かご 決済 会計 フロントエンド バックエンド (API) データベース 技術 レイヤー どのような単位で マイクロサービスに分けるか

Slide 12

Slide 12 text

システムの特性に合わせて、採用する技術を組み合わせることが容易になってきている 12 商品 買い物 かご 外部の 決済 サービ ス 既存の 会計 システ ム フロントエンド バックエンド (API) データベース 技術 レイヤー どのような単位で マイクロサービスに分けるか MySQL NoSQL DB Node.js Java 顧客向けフロントエンド

Slide 13

Slide 13 text

システムの特性に合わせて、採用する技術を組み合わせることが容易になってきている 13 商品 買い物 かご 外部の 決済 サービ ス 既存の 会計 システ ム フロントエンド バックエンド (API) データベース 技術 レイヤー どのような単位で マイクロサービスに分けるか MySQL NoSQL DB Node.js Java API連携 API連携 顧客向けフロントエンド API連携 API連携 なぜこのようなことができるかというと、APIを介した連携だから。 APIというインターフェイスが変わらなけれは、 連携先の言語、実行基盤、実態がどこにあるのかが変わっても影響を受けない

Slide 14

Slide 14 text

API活用例② 企業間/社内間システム連携 14 設計 製造 施工管理 運用 A工程 施工 B工程 施工 設計事務所 工場 元請けゼネコン 建物運用 施工会社A 施工会社B 独自 システム 独自 システム 独自 システム Excel Excel 独自 システム 独自 システム 紙 紙 Excel 例えば建設業の例では

Slide 15

Slide 15 text

API活用例② 企業間/社内間システム連携 15 設計 製造 施工管理 運用 A工程 施工 B工程 施工 設計事務所 工場 元請けゼネコン 建物運用 施工会社A 施工会社B 独自 システム 独自 システム 独自 システム Excel 独自 システム 独自 システム API API データ 連携 API RPA APIを利用することでシステム間のデータのやりとりが、 自動化でき、リアルタイム性、正確さが向上します。 ※すべてをAPI化する必要はありません。 リアルタイム性が必要ない部分はデータ 連携を使用したり、システム化の費用対 効果がでない部分はRPAを組み合わせる なども考えられます。

Slide 16

Slide 16 text

APIの活用例③ UXが重視されており、顧客向けのUIを高速に改善したい 16 顧客向け フロントエンド API データベース データモデル、機能は 比較的あまり変わらない UX/UIはどんどん 改善していく APIを境界にフロントエンド(画面)とバックエンド(機能・データ)が 分離され、それぞれが独立して改善、リリースできる

Slide 17

Slide 17 text

とはいえ、APIの管理について気をつける点がいくつかあります 17 顧客向け フロントエンド 管理向け フロントエンド 社内の 他システム 悪意のある クライアント API データベース APIの セキュリティ APIの 仕様の公開 どういう 設計が良いの? どんな技術で 作るのか?

Slide 18

Slide 18 text

API周辺のテクノロジー ・SOAPからRESTへ ・開発言語のサポート ・コンテナ ・サーバレス ・APIドキュメント

Slide 19

Slide 19 text

一昔前からのAPI周辺技術の進化 l 一昔前はWeb APIと言えばSOAPというプロトコルでした l WSDL(XML)でインターフェイスを定義 l WS-*などの複雑な仕様 l サポートする言語、ミドルウェアが限定的 l 現在はRESTが一般的 l シンプルな仕様 l HTTPの仕様に合わせており、さまざまな言語で扱いやすい l URL l HTTPメソッド l 応答コード、など 19

Slide 20

Slide 20 text

様々な開発言語で簡単に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そのものの開発が楽だとは言ってないです

Slide 21

Slide 21 text

APIの実行基盤としてのコンテナ / サーバレス l APIはサーバーサイドで実行されるため、何らかの環境が必要 l 代表的なものとして、以下があげられますが 本日はコンテナ、サーバレスについてお話します 21 コンテナ オンプレ サーバー IaaS サーバレス サーバー上にOSをセットアップ アプリケーション・サーバー、 Webサーバーなどのミドルウェアを構築 開発したアプリケーションをデプロイ IaaSの場合は、AWS EC2などを利用し、 ハードウェアを意識する必要はない。 主にDockerを使用 して、物理サー バー上に仮想化さ れた環境(コンテ ナ)の中でアプリ ケーションを運用。 物理サーバー上で 多くのコンテナを 動作させることが できるため、1つ のコンテナを小さ く、シンプルにす ることができる クラウドベンダー が提供している仕 組みをなどを利用 して、 開発者はサーバー を意識することな く、開発、運用す ることができる。 実行した分だけの 従量課金が多い

Slide 22

Slide 22 text

コンテナとは l Dockerの仮想化技術がベースとなっている l Kubernetes、AWS ECSなどはDockerコンテナを運用するためのもの (オートスケール、フェイルオーバー、負荷分散など) l 徹底的に自動化ができるようになっている。 22 図は下記より引用 https://www.docker.com/resources/what-container

Slide 23

Slide 23 text

コンテナとは l Dockerの仮想化技術がベースとなっている l Kubernetes、AWS ECSなどはDockerコンテナを運用するためのもの (オートスケール、フェイルオーバー、負荷分散など) l 徹底的に自動化ができるようになっている。 23 図は下記より引用 https://www.docker.com/resources/what-container コンテナの1つとしてAPIが配置される。 負荷に応じてインスタンスを増やした り、障害時に別の環境にフェイルオー バーできる Dockerが動作する別のホストへ コンテナを持っていくことができる 可搬性 本番環境→検証環境 1号機→2号機

Slide 24

Slide 24 text

コンテナとは l コンテナ環境を構築する際に、1つのコンテナ上に沢山の アプリケーションを動かすのではなく、 1つだけにするのがシンプル l 例えばJavaでは、これまではTomcat、JBossなどのアプリケーションサーバー 上で複数のWebサービスを動かしていましたが、 コンテナ時代はSpring Bootのような1コンテナ=1アプリケーションで動かす ための実行基盤が主流 24 図は下記より引用 https://www.docker.com/resources/what-container Java VM Guest OS Application Spring Boot

Slide 25

Slide 25 text

サーバレスとはサーバーが無い? l 実際には物理的なサーバー上にアプリケーションを配置しますが、 開発者がサーバーや、実行基盤のようなミドルウェアを意識する 必要がありません l 暗黙的にはこのような処理が行われています l 処理の実行回数により課金が行われる 25 アプリケーション サーバー ①処理要求 ビルド済み アプリケーション ②サーバー上に 読み込み ③処理の実行 ④アプリケーションの破棄

Slide 26

Slide 26 text

サーバレスとはサーバーが無い? l 実際には物理的なサーバー上にアプリケーションを配置しますが、 開発者がサーバーや、実行基盤のようなミドルウェアを意識する 必要がありません l 暗黙的にはこのような処理が行われています l 処理の実行回数により課金が行われる 26 アプリケーション サーバー ①処理要求 ビルド済み アプリケーション ②サーバー上に 読み込み ③処理の実行 ④アプリケーションの破棄 サーバーなどのハード障害はあり得る。 しかし、次の処理要求は別の正常な サーバーで処理される。 サーバーの復旧や、フェイルオーバー などの仕組みを自分たちで考える必要 がない 多少のオーバーヘッドがあります。 サーバーへの読み込み、アプリケー ションの破棄はクラウド側で最適化 される (できるだけ再利用してくれる)

Slide 27

Slide 27 text

サーバレスとコンテナの使い分け マネージドサービス サーバレス コンテナ IaaS 機能 • 提供されたもの を使う • 自前で開発 • 処理が15分以内 • コネクションプール が使えず、DBは RDBMSと相性悪い • 自前で開発 • 自前で開発 アプリフレー ムワーク例 • 使用しない • Serverless Framework • Spring Boot • Spring Boot、 Spring Framework インフラ • クラウドベン ダーに任せる • クラウドベンダーに 任せる • リクエスト数に応じ て使った分だけ課金 • ハードウェア、仮想 化環境はクラウドベ ンダーに任せる • 用意したインスタン スに合わせて課金 • ハードウェアは提供され る。 • OS以上を自前で構築 • 用意したインスタンスに 合わせて課金 運用 • クラウドベン ダー • 基本、クラウドベン ダーに任せる • 機能のリリースなど は自前 • コンテナ管理はクラ ウドベンダー • コンテナイメージ、 アプリは自前 • インフラ管理より下のレ イヤーはクラウドベン ダー • OS、アプリは自前 サービス 例 • AWS Cognito 認証サービス • AWS Lambda • ECS(AWS独自) • EKS(Kubernetes) • EC2 27 • 開発しなくて良い/運用コストが下がる • 制約は大きい やりたいことと提供されるものがあっている場 合には、非常に効果を発揮する。 要件とフィットしていれば、使ったほうが良い • 自由度が高い • 開発、運用の費用は相対的に 大きい

Slide 28

Slide 28 text

制約はありますが、許容できるならサーバレスがおすすめ l 安い! l APIが呼び出された量での課金 のため、特に新規事業、新規 サービスのような、ローンチ 時に大量アクセスが無い様な APIの場合、すごく安い l 運用が楽 l サーバーの管理が不要 l 障害時の再起動、フェイル オーバーすら不要 28 https://aws.amazon.com/jp/lambda/pricing/

Slide 29

Slide 29 text

事例)サーバレスとマネージドサービスをフル活用したアーキテクチャ 29 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知

Slide 30

Slide 30 text

事例)サーバレスとマネージドサービスをフル活用したアーキテクチャ 30 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 自社営業 向け配信 SNS Push通知 AWS Lambda サーバレスな処理実装 Cognito マネージドな 認証サービス DynamoDB スケールアウト可能な データベース アプリケーションは S3とCloudFrontで配信

Slide 31

Slide 31 text

もしAPIを広く使ってもらいたいならAPIの使い方の公開はとても重要 31 https://api.slack.com/apis https://docs.apppot.jp/ 閉じられた範囲でのAPIの利用であれば、ExcelやWordで記載されたAPI仕様書で問題ないかも知れませんが、 幅広く使用してもらいたいAPIの場合は、APIの使い方の公開が重要です。 顧客によっては、APIがあることが選定理由になるかも知れません。

Slide 32

Slide 32 text

APIで考慮すべきこと ・APIの設計 ・セキュリティ ・APIマネジメント ・バージョニング

Slide 33

Slide 33 text

APIの開発に必要なスキルセット l APIの開発を行うためにはどんなスキルセットを持った エンジニアが必要でしょうか? l ただし、以下のような内容をキャッチアップする必要があります l ベストプラクティスはAPIを使う側も理解 している(べき?)ので、基本的なルー ルは説明しなくても分かってもらえる。 l 各種ライブラリがサポートしているので、 作る側、使う側とも楽。 Web APIのベストプラクティスの理解 l DDDやオブジェクト指向などの 設計手法を使って、システムの機能や データをモデリングし、 どのような単位でAPIを作っていくか 設計する APIの粒度や機能の集約の考え方の理解 基本的には、Java、Node.js、Pythonなどでサーバーサイドの プログラミングが書けるエンジニアであれば大丈夫です! むしろ、これまでのサーバーサイドエンジニアはWebアプリケーションの 画面も開発していたことを考えれば、APIになることでよりバックエンドに集中できる 33

Slide 34

Slide 34 text

APIの設計 34 商品 テーブル 在庫 テーブル 入庫などの操作(メソッド)が 実際にAPIを呼び出す単位。 どのようにAPIを設計すべきか 商品 - 商品マスタ取得API Webアプリ 在庫 - 入庫API - 出庫API - 在庫確認API モバイル アプリ 他システム APIの利用側の要件だけに 従って作ると似て非なる APIが大量にできることに・・・

Slide 35

Slide 35 text

APIの設計 35 商品 テーブル 在庫 テーブル 入庫などの操作(メソッド)が 実際にAPIを呼び出す単位 どのようにAPIを設計していくか。 商品 - 商品マスタ取得API Webアプリ 在庫 - 入庫API - 出庫API - 在庫確認API モバイル アプリ 他システム APIの利用側の要件だけに 従って作ると似て非なる APIが大量にできることに・・・ 在庫、商品などのオブジェクトのデータモデルと、 そのオブジェクトが持つ操作(メソッド)や、データの項目を定義 図の例では、このサービスでの在庫というデータの項目を共通的に定義し、 在庫に対する操作(入庫、出庫、確認など)を洗い出し、それをクライアントに提供するという考え方

Slide 36

Slide 36 text

じゃあどうやってオブジェクトを見つけて定義するのか? l ドメイン駆動設計(DDD)やオブジェクト指向の手法を使って サービス、システムをモデリングするなどが考えられます 36 エリック・エヴァンスのドメイン駆動設計 モデリングの例

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

APIの呼び出し元が正しいことを確認 l APIは機能やデータを公開するため、それを誰に どこまで使わせるのかは慎重に検討する必要があります l APIの呼び出し元の確認には次のようなものがあります l IPアドレス l 特定のIPアドレスのクライアントから利用できる l 通信経路が安全でない場合、IPアドレスのなりすましがあり得る l APIキー l パスフレーズを知っているクライアントから利用できる l 認証済みトークン l ユーザーの認証を行った時に発行されるトークンを検証 l クライアント証明書 l クライアントに証明書を発行 39

Slide 40

Slide 40 text

APIの運用 l 今日は時間の制約がありますのでキーワードだけ l 処理をトレースできる仕組みの検討 l 複数のレイヤーをまたがって処理を行いますので、 どこでエラーが発生したのか、その影響範囲の確認、 どこで時間で時間がかかっているのか を特定するためにリクエストごとに ユニークなIDを発行してフロントエンド、API、 バックエンドの処理ロジックでログに出すような仕組 み l APIのバージョン管理 l APIはいろいろなところから利用される可能性があり ます l 将来的にインターフェイスが変更になった場合に、 多数のクライアントが困らないようにバージョン ごとに並行稼動してクライアントがバージョンを 指定して呼び出し分けることができるような仕組み 40 顧客向け フロントエンド 管理向け フロントエンド API データベース

Slide 41

Slide 41 text

NCDCのAPIに関するサービス・プロダクト

Slide 42

Slide 42 text

NCDCのアーキテクチャ・コンサルティングサービス l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで システムを構築します 42 ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション ITアーキテクチャのデザイン リファレンス実装 DX推進のための組織デザイン

Slide 43

Slide 43 text

NCDCのアーキテクチャ・コンサルティングサービス l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで システムを構築します 43 ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション ITアーキテクチャのデザイン リファレンス実装 DX推進のための組織デザイン システム全体のアーキテク チャの策定 使用する技術、サービスの 選定 アプリケーション開発者が 該当技術に慣れていない場 合、リファレンス実装を行 い技術移管

Slide 44

Slide 44 text

バックエンドサービスAppPot 企業のスマートデバイス活用を支援する モバイルアプリの開発/運用プラットフォームです 44 特徴③ 特徴② 既存の社内システムとの 連携が容易 サーバー開発不要 企業で必要な機能を 実装済み 特徴① ίετ࡟ݮ º ։ൃظؒ୹ॖ

Slide 45

Slide 45 text

AppPotの主要機能 45 Ϣʔβʔ؅ཧ •ログイン/ログアウト •Active Directory/LDAP/Google Appsとの認証 連携 σʔλ؅ཧ •端末とサーバー間のデータの同期 •トランザクション制御によるデータの信頼性 の確保 •オフライン状態での利用と、オンライン時の 再送 ΞϓϦͷ࢖༻ঢ়گͷϞχλϦϯά •使用されている機能やエラー情報の収集、参 照 ϓογϡϝοηʔδɺFϝʔϧ •管理画面やAPI経由でアプリからのPush メッセージの送信 •API経由でeメールの送信 ηΩϡϦςΟ •端末内のデータの暗号化 •SQL Injectionなどのセキュリティ対応済み ଞγεςϜͱͷ࿈ܞ •他システムとのWebサービス、ファイル、 データベースとの連携 •別オプションでERPパッケージ製品との連 携コネクター 各機能を簡単に使⽤するためのWeb APIと、 iOS / Android / JavaScriptのSDKが提供されています

Slide 46

Slide 46 text

AppPotの事例 46 l モバイルアプリ:Monaca上でAngularJSを使ったハイブリッドアプリ l サーバー側処理はAppPotのみで、スクラッチ開発はなし。 l 使っている機能:データ永続化 / Google OAuth認証 / モニタリング / ファイルAPI / 他システム連携アダプタ

Slide 47

Slide 47 text

No content