[Kong Meetup #2] ソフトバンクでのAPI Gatewayを用いた開発におけるKongの利活用

Connpassで開催した「Kong Community Japan Meetup 第2回」の事例紹介セクションにて発表した資料になります

Transcript

1. 【Kong MeetUp #2】 ソフトバンクでのAPI Gatewayを用いた システム開発におけるKongの利活用
2. 2 自己紹介＋本資料の目的 • 田中 直登　 ◦ 東京都東村山市出身 ◦ 2020.4 ソフトバンク株式会社 入社（社会人3年目） • これまでの主な業務 ◦ Kongの検証・構築 ◦ JSフレームワークでのフロントエンド開発 ◦ Jenkins/Concourseなどパイプライン構築 • 本資料の目的 所属部署でのシステム開発において、API GatewayとしてKong OSS版をカスタムプ ラグイン等で機能拡張し活用しており 皆様のKong利用の参考になればと思い、その内容をご紹介いたします たまにKong関連のQiitaも 書いています
3. 3 1 マイクロサービスでの API Gatewayの必要性と役割 UIにマイクロサービスを意識させないために API Gateway導入 2 API Gatewayのベース機能としての Kong利活用 カスタムプラグインでの機能拡張を含めたベース機能の実装 3 KubernetesでのKong稼働 スケーラビリティを考慮し、 Kongコンテナ+Kubernetesで稼働 Agenda
4. 4 1 マイクロサービスでの API Gatewayの必要性と役割 UIにマイクロサービスを意識させないために API Gateway導入 2 API Gatewayのベース機能としての Kong利活用 カスタムプラグインでの機能拡張を含めたベース機能の実装 3 KubernetesでのKong稼働 スケーラビリティを考慮し、 Kongコンテナ+Kubernetesで稼働 Agenda
5. 5 モノリス型システムの問題が顕著化 店頭システム ソフトバンクのフロントシステムはチャネルに応じて様々なシステムがある 年月を重ね肥大化・複雑化した結果、保守コスト増加や機能の重複開発が発生 Webシステム アプリ 画面 Business Logic 肥 大 化 ・ 複 雑 化 機能の重複開発 ・・・ その他
6. 6 モノリスからマイクロサービスへ モノリスシステムをAPIに切り出し、共通化を段階的に進める APIの組み合わせでフロントシステムを構成していく マイクロ サービス API ユーザ インターフェース マイクロ サービス ・・・ API API モノリシックシステム 機能同士が密結合し 単一で巨大なシステム マイクロサービスアーキテクチャ 複数の小さなサービスが 連携して動くシステム API API API モノリシックシステム ユーザ インターフェース マイクロ サービス API API API データ データ データ ビジネスロジック データアクセス
7. 7 生じる課題 マイクロ サービス API システムA システムB システムC マイクロ サービス マイクロ サービス ・・・ API API API API API マイクロ サービス API API API API API API フロントアプリは各サービスの 通信プロトコルを意識す る必要がある マイクロサービスに分解することで以下のような課題が生じる フロントアプリから各マイクロサービスを 個別に呼び出 すのは非効率 各サービスでは業務とは関係のない認証 /認可や流量 制御等の機能をそれぞれで実装する必要 がある 上記課題の解決策としてAPI Gateway導入
8. 8 API Gatewayパターンの採用 API Gatewayを用いることでフロントアプリはマイクロサービスを意識する必要が なくなる フロント マイクロ サービス 群 Monolithic System APIs APIs APIs システムA システムB APIGateway UI APIGateway APIs UI 以下の観点から、クライアントごとに独立したAPI Gatewayを設ける • 改修に柔軟に対応できるようにするため • 共通化したBL機能を用いたシステム個別の処 理を行えるようにするため
9. 9 API Gatewayに求められること リクエストルーティング リクエストを適切なAPIにルーティングする API合成 複数のAPIのレスポンスを合成する プロトコル変換 様々なプロトコルのAPIをRESTful APIで提供する エッジ機能 認証/認可・流量制御・キャッシュ・フォーマット変換などの横断 的機能 マイクロサービスパターン（Chris Richardson著）よりAPI Gatewayには以下 の内容が求められる
10. 10 API Gatewayの実装 OSSのAPI GatewayであるKongをベースに、カスタムプラグイン等 を活用しAPI Gatewayを構成する APIs APIGateway UI APIs 必要に応じて適切な言語 /FWで実装 Kong OSSで実装 プロトコル変換 カスタムプラグイン作成（ REST↔SOAPのみ） リクエストルーティング Kong機能を用いる エッジ機能 kong提供プラグイン+カスタムプラグイン作成 API合成 共通機能に分解した各 BLを要件に応じて合成 フロント マイクロ サービス 群
11. 11 1 マイクロサービスでの API Gatewayの必要性と役割 UIにマイクロサービスを意識させないために API Gateway導入 2 API Gatewayのベース機能としての Kong利活用 カスタムプラグインでの機能拡張を含めたベース機能の実装 3 KubernetesでのKong稼働 スケーラビリティを考慮し、 Kongコンテナ+Kubernetesで稼働 Agenda
12. 12 Kongとは？(おさらい) 世界で最も使用されているOSSのAPI Gateway 認証や流量制御・キャッシュ等の必要な機能をプラグインで追加できる プラグインは自作可能で拡張もできる https://github.com/Kong/kong
13. 13 ルーティング設定 ルーティング設定 リクエストルーティング エッジ機能 （例）Yamlファイル利用の場合 必要なエッジ機能をプラグインとして追加 簡単にルーティング設定＋必要なエッジ機能の有効化可能
14. 14 エッジ機能の追加 エッジ機能 エッジ機能 kong OSS Enterprise 詳細 流量制御 ◦ ◦ Rate Limitingプラグインで可能 認証/認可(JWT検証) △ △ Jwtプラグインで検証は可能 検証した項目をボディにマッピングはできない IN/OUTマッピング △ ◦ request transformer advanced/response transformer advanced で柔軟にin/outマッピング可能 レスポンスキャッシュ ◦ ◦ Proxy Cacheプラグインで可能 リトライ制御 ◦ ◦ kong設定のretriesで設定可能 トレーシング ◦ ◦ Correlation IDプラグインで可能 フォーマット変換 × ◦ jqプラグインで可能 バージョン管理 ◦ ◦ kong設定でpathを分けることで可能 必要なエッジ機能のうち一部はKong機能では足りない部分あり
15. 15 プロトコル変換 プロトコル変換 SOAP通信のレガシーシステムと通信する要件があるが、RESTから変換する方法 はない エッジ機能 kong OSS Enterprise 詳細 REST ↔ gRPC ◦ ◦ gRPC-gatewayプラグインで可能（現状は要件なし） REST ↔ SOAP × × REST-SOAPの変換はEnterpriseも含めなし GraphQL ↔ REST × ◦ DeGraphQLプラグインで可能（現状は要件なし）
16. 16 カスタムプラグインでの機能追加 エッジ機能 機能 OSS/ Enterprise 詳細 エッジ 機能 認証/認可 (JWT検証) △ Jwtプラグインをベースに検証済み項目をプラグイン共有変数に 格納するよう機能拡張 プロトコル 変換 REST ↔ SOAP × カスタムプラグインを新規作成 業務上必要かつKong機能にないものは、OSSプラグイン機能拡張/カスタムプラ グイン作成を行うことで機能を追加できる プロトコル変換
17. 17 カスタムプラグイン作成 開発言語 言語はLuaで開発（Go/JS/Pythonでも作成可能） ゲームやプラグイン開発で使用される高速のスクリプト言語 作成ファイル 最低以下の2ファイルを作成すればOK • handler.lua ライフサイクル（request, response, logなど）の各フェーズで実行する処理を記載 • schema.lua ユーザーが動作を変更するための変数を定義する プラグイン有効化 コンテナの指定フォルダに配置すれば完了
18. 18 （例）correlation-idプラグイン schema.luaの作成 schema.lua ymlファイルでの設定 schema.luaでは設定ファイルで受け取るパラメータの型やデフォルト値などを 定義する
19. 19 handler.luaの作成 handler.luaではライフサイクル（request, response, logなど）の各フェーズ で実行する処理を記載 （例）correlation-idプラグイン handler.lua（抜粋） 実行するフェーズを指定する よく用いられるのは以下 その他はKong Docs参照 access kongがプロキシする前 ↓ header_filter レスポンスヘッダー受取時 ↓ body_filter レスポンスボディ受取時 ↓ log kongのレスポンス終了時
20. 20 handler.luaの作成 （例）correlation-idプラグイン handler.lua（抜粋） confで指定したパラメータを利用可能 ヘッダやボディの取得およびセット可能 リクエストの各フェーズでの変数を共有可能 • kong.ctx.plugin: 同プラグイン • kong.ctx.shared: プラグイン間共有
21. 21 プラグインの有効化 環境変数 設定値 詳細 KONG_PLUGINS bundled,<plugin-name>,... カンマ区切りでカスタムプラグインの名前を記 載する KONG_UNTRUSTED_LUA on カスタムLuaコードを使えるようにする設定 Luaライブラリ等を使用する場合はonにする 環境変数設定 プラグインフォルダにコピー handler.lua・schema.luaをプラグイン名のフォルダに入れ、 /usr/local/share/lua/5.1/kong/plugins/にコピーする （例）/usr/local/share/lua/5.1/kong/plugins/ 
 L custom-correlation-id 
 L handler.lua
 L schema.lua

22. 22 1 マイクロサービスでの API Gatewayの必要性と役割 UIにマイクロサービスを意識させないために API Gateway導入 2 API Gatewayのベース機能としての Kong利活用 カスタムプラグインでの機能拡張を含めたベース機能の実装 3 KubernetesでのKong稼働 スケーラビリティを考慮し、 Kongコンテナ+Kubernetesで稼働 Agenda
23. 23 API Gatewayの考慮点 フロントシステムからの全てのリクエストがAPI Gateway を通過するので、パフォーマンス・スケーラビリティが重 要となる 他のAPI Gatewayに比べても高いI/Oパフォーマンスを持つ KongをKubernetesで稼働させ、スケーラビリティを担保 する パフォーマンス/スケーラビリティ ✖ https://konghq.com/
24. 24 Kong+Kubernetesの選択肢 ①Kong Ingress Controller kubernetesのingressリソースとしてkongを使用する カスタムプラグイン利用のため②を選択 メリット： HelmやKustomizeで環境ごとの設定管理も容易 デメリット： カスタムプラグインをConfigmapとして作成する必要があり、ライブラリを使う場合は困難 メリット： Kongのdockerイメージを自由に拡張できる デメリット： 設定ファイルを用いるので環境ごとの設定管理が困難 ②Kong DBless Container on k8s DBレスモードのKongのpodをkubernetesで動かす
25. 25 Kubernetesでの構成管理 コンテナとして使用する場合の「環境ごとの構成管理」の課題に対し ベースのdockerイメージにデプロイ時に定義した環境変数を設定ファイルに埋 め込んで環境ごとの設定を構成 DBlessモード使用 設定ファイル内で 変数化しておき イメージ作成 コンテナ起動時に 環境変数定義＆ envsubstで環境変数 埋め込み
26. 26 まとめ 1. マイクロサービスでのAPI Gatewayの必要性と役割 マイクロサービス化で生じる課題の解決策としてAPI Gateway導入 そのベース機能としてオープンソースのKongを採用 2. API Gatewayのベース機能としてのKong利活用 API Gatewayの役割である「エッジ機能」「プロトコル変換」において、業務上必 要だが足りない部分をカスタムプラグインで機能拡張 3. KubernetesでのKong稼働 API Gatewayの懸念点であるスケーラビリティに対して、kongコンテナ+ Kubernetesを利用
27. End Of Document 27