Kong Community Japan Meetup #4【イベントレポート】

■Kongとは？

Kongは、世界で最も採用されている高速でスケーラブルなマルチクラウド対応APIマネジメントプラットフォームです。Amazon Web Services、Microsoft Azure、Google Cloud Platformなどあらゆるクラウドサービス上で動作するだけでなく、オンプレミス環境でも広く利用されており、更にそれらを組み合わせたハイブリッドクラウドアーキテクチャの構築も容易にします。

グローバルでは、業界リーダー800社以上の導入実績があり、日本においても既に、 Yahoo! JAPAN 等を運営する LINEヤフー株式会社や株式会社NTTデータ、株式会社インターネットイニシアティブをはじめとする日本を代表する企業が Kong を活用しており、デジタル庁からも推奨APIゲートウェイに認定されています。

Kongは標準でプロキシ、ルーティング、ロードバランシングや、ヘルスチェック、認証認可、流量制限とリクエスト/レスポンス編集など、様々な機能を提供しており、外部へのAPI公開を行う際に役立つのはもちろんのこと、Kubernetesにもネイティブに対応しており、マイクロサービスオーケストレーションの中核的なレイヤーとして利用することも可能です。

Kongは高いパフォーマンスと1,000以上のプラグインによる拡張機構を備えているだけではありません。エンタープライズ版は、拡張されたセキュリティ機能、24/7サポート、および高度なプロキシ機能を含む29以上のエンタープライズ版専用プラグインを提供します。関連プロジェクト全体でGitHubスター数5万以上と、開発者からの圧倒的な支持を受けており、世界で最も人気のあるAPIマネジメントプラットフォームです。 基本的なAPI管理機能を利用される場合、GitHub上でオープンソースプロジェクトとして開発されているOSS版もご活用ください。

Kongに関するFindy Toolsの紹介・レビューはこちら https://findy-tools.io/products/kong/334

セッション「マイクロサービスでのAPI Gatewayの必要性と役割」

本イベントでは Kong Inc. のVP of ProductであるReza Shafii氏より、Kongエコシステムのロードマップやその先に見据える将来のビジョンについて講演したのち、田中直登さんによるセッションが行われました。API Gateway「Kong」の利活用やKubernetesでのKong稼働などをお話しいただいています。

■田中 直登さんプロフィール
東京工業大学大学院卒業後、2020年4月にソフトバンク株式会社に入社。モバイル事業領域において、主に内製開発や開発方針の策定・技術スタックの検証に従事。所属部署での開発においてKongを活用しており、Kong Community、 Japanのメンバーとしても活動中。

マイクロサービスでのAPI Gatewayの必要性と役割

田中：ソフトバンク株式会社の田中と申します。普段の主な業務としては、Kongの検証・構築、JavaScriptフレームワークでのフロントエンド開発を行っています。

またモバイル事業のアーキテクチャを担当する部署に所属しているので、社内での実績がない技術スタックの検証や発信を行っています。今日は「ソフトバンクでのシステム開発におけるKongの活用」というテーマで、モバイル事業で採用しているAPI Gateway「Kong」の活用方法についてお話をさせてください。

はじめに私の所属部署には、コンシューマ事業と法人ビジネス事業、大きく2つの事業があります。コンシューマ事業では、オンラインショップや実店舗での申し込みシステム、アプリなどの顧客向けのフロントシステムを開発しています。法人ビジネス事業では、パートナーに対しての商材提供、loTなどの非通信系サービスのシステム開発を行っています。

今回は、そのなかでもコンシューマ事業での活用について紹介します。コンシューマ事業のフロントシステムは、店頭システムやオンラインショップ、アプリなどの各チャネルに応じてさまざまな開発が行われています。



田中：それぞれのシステムが年月を重ね「肥大化」 「複雑化」した結果、「保守コストの増加」や「機能の重複開発」といった問題が発生していました。このような背景から、従来の一元型のモノリシックシステムで開発された各機能をAPIに切り出し、共通化していく。いわゆるマイクロサービスアーキテクチャへと移行する取り組みを進めています。

一方で、マイクロサービス化を進めるうえで、大きく以下3つの課題が生じると考えています。



田中：1つ目は、元々一つのモノリス型であったシステムを分けたことによって、各マイクロサービスを個別に呼び出すことが非効率であること。
2つ目は、複数の通信プロトコルを意識する必要があること。
3つ目は、各マイクロサービスにおいて、業務とは関係のない認証/認可、流量制御などの機能をそれぞれで実装する必要があることです。

こうした課題の解決策として「API Gateway」があります。API Gatewayを用いることで、「UIはマイクロサービスを意識することが不要になる」というメリットがあります。

我々の組織では、一つの大きなAPI Gatewayを用いる訳ではなく、各システムで独立したAPI Gatewayを設けています。理由としては、各システムの改修が柔軟に対応可能になり、システム固有の処理を効率的に実行できるようになるためです。

API Gatewayに求められることとベース機能としてのKong利活用

田中：API Gatewayに求められることとして、マイクロサービスパターン（Chris Richardson著）によれば「リクエストのルーティング」 「APIの合成」 「プロトコルの変換」 「エッジ機能の提供」の4つの大きな役割があると述べられています。

ソフトバンクでは、オープンソースのKongをベースにAPI Gatewayを構築し、リクエストのルーティング、プロトコルの変換、エッジ機能の実装を行っています。また必要に応じてNode.jsなどの適切な言語を通じ、APIの合成を行っています。



田中：Kongは、認証や流量制御、キャッシュなどの必要な機能をプラグインで追加できるオープンソースのAPI Gatewayです。プラグインは自作可能かつ拡張も可能です。

Yamlファイルで簡単にルーティングの設定とプラグインを追加するだけで、必要なエッジ機能の有効化が可能になります。

しかし、流量制御、認証・認可、IN・OUTマッピング、レスポンスキャッシュ、リトライ制御、トレーシング、フォーマット変更、バージョン管理などの必要なエッジ機能のうち、JWTの検証についてはデフォルトのプラグインでは対応が難しいところがありました。

プロトコルの変換においても、SOAP通信のレガシーシステムと通信する要件があった一方で、RESTから変換する方法はありませんでした。



田中：そうした観点から、業務上に必要かつKongの機能にないものは、OSSのプラグインを機能拡張したり、カスタムプラグインの作成を行い機能を追加することで対応しました。

具体的には、JWTプラグインをベースに検証済み項目をプラグイン共有変数に格納する機能拡張や、RESTからSOAPのプロトコル変換するためにカスタムプラグインを新しく作成しました。

カスタムプラグイン作成においては、基本的に言語はLuaで開発しています。作成ファイルとしては、ライフサイクルの各フェーズで実行する処理を記載するための「handler.lua」と、ユーザーが動作を変更するための変数を定義する「schema.lua」の2つをつくれば機能拡張が可能になります。

KubernetesでのKong稼働

田中：最後に「KubernetesでのKong稼働」についてお話しします。

API Gatewayの考慮点として、UIからの全てのリクエストがAPI Gatewayを通過するので、パフォーマンスとスケーラビリティが重要となります。これを担保するために高いI/OパフォーマンスをもつKongをKubernetesで稼働させる方法があります。

KongをKubernetesで稼働するには大きく2つの選択肢があります。



田中：1つ目は、「Kong Ingress Controller」のingressリソースとしてkongを使用することです。メリットとしては、HelmやKustomizeで環境ごとの設定管理も容易になります。一方で、デメリットとしてはカスタムプラグインをConfigmapとして作成する必要があり、ライブラリを使う場合は困難になります。

2つ目は、DBレスモードのKongのpodをKubernetesで動かす方法です。メリットとしては、Kongのdockerイメージを自由に拡張できることです。デメリットとしては、設定ファイルを用いるので、環境ごとの設定管理が困難になることです。



田中：我々の場合は、カスタムプラグイン利用のため、2つ目のKong DBless ContainerをKubernetesの環境で稼働させる方法をとっています。

構成管理については、コンテナとして使用する場合の「環境ごとの構成管理が困難である」という課題に対して、環境変数を設定ファイルに埋め込むことで環境ごとの設定を可能にしています。



まとめとしては、はじめに「マイクロサービスでのAPI Gatewayの必要性と役割」についてお話しさせていただきました。マイクロサービスで生じる課題の解決策としてAPI Gatewayの導入やそのベース機能としてオープンソースのKongを採用したことを紹介しました。

2つ目に、「API Gatewayのベース機能としてのKong利活用」についてもお話ししました。API Gatewayの役割である「エッジ機能」 「プロトコル変換」において業務上必要だが足りない部分をカスタムプラグインで機能拡張する取り組みを紹介しました。

最後に、「KubernetesでのKong稼働」について、API Gatewayの懸念点であるスケーラビリティに関して、Kongコンテナ＋Kubernetesを利用していることを紹介しました。

セッション「decKを使ったKongのCDパイプライン実装について」

続いて、サイオステクノロジー株式会社のアーキテクト マネージャー、槌野 雅敏さんによるセッションが行われました。「decKを使ったKongのCDパイプライン実装について」と題して、KongのAPIOps運用を支援するツール「decK」の利活用についてお話しいただいています。

■槌野 雅敏さんプロフィール
IT業界四半世紀、ここ10年はAPI関連の技術に特化し様々なAPI基盤プロジェクトのコンサルティング等支援に従事。ビジネスと技術のバランスを両立する最適なアーキテクチャはどんなものかを考えている時間が仕事の中での楽しみ。



槌野：サイオステクノロジー株式会社の槌野と申します。API基盤の導入支援コンサルティングを中心に、基盤アーキテクチャの設計やKongをはじめとする各種ミドルウェアの技術サポートを行っています。

2017年に当社はKongとパートナー提携を結び、現在OSS版とエンタープライズ版を合わせて20社ほどの導入支援を行っています。

それでは本日は「decKを使ったCDパイプラインの実装」をテーマにお話しさせていただきます。

decKとは

槌野：まずはじめに、decKとはKong社が作成している宣言的構成（Declarative Configuration)を支援するためのツールです。APIライフサイクルの自動化を支援する目的で開発されており、Kongの設定情報をYamlファイル形式(以下state file)で扱うことができます。



state fileを用いると、KongのDBと同期・逆同期ができます。またAdmin APIを並列実行できることで、個別にスクリプト実行するよりも高速処理が可能になります。

decKはコマンドライン型のアプリケーションで、テキストベースでCI/CDパイプラインへの組み込み、運用が簡単に行えます。さらに独立したアプリケーションなので、API Gatewayの環境に非依存で、柔軟性の高い運用も可能です。

OSS版だけでなく、エンタープライズ版にも対応しているので幅広い運用が可能です。ただしエンタープライズ版の固有オブジェクトに関しては、一部非対応のものがありますので、今後の課題でもあります。

管理対象オブジェクトについては、ServiceやRoutes、Consumer、PluginsのようなKongの基本的なオブジェクトに関してdecKを使用しての管理が可能です。

decKの「4つのユースケース」

ここからはdecKの4つのユースケースについてお話しさせてください。



1つ目は、「Kongのバックアップ＆リストア」です。弊社の運用実績でも最も多い事例です。「Kongのエンティティ構成のサブセットまたは全体をバックアップ・リストアしたい」というニーズに応えています。

2つ目は、CaC(Configuration as Code)またはGitOpsのような形で、運用を自動化するための仕組みとして使いたいという声に対応するために、「CIパイプラインでKongの構成をプッシュ」すること。

これを拡張するイメージで3つ目は、APIOpsでコンフィグの生成、設定の変換、Kongの状態管理などのAPIライフサイクルを自動化すること。

4つ目は、「Kong構成の分散管理」を行えるようにすることです。複数のチームで、1つのKongを使用する際に、それぞれのチームが独立性を持って構成を管理することが可能になります。

APIOpsのライフサイクル

槌野：APIOpsの実践イメージについてもご紹介します。
まず、API開発者がInsomniaというツールでOpen API Specの作成・編集を行い、Githubにスペックをプッシュします。その後、Jenkinsがプッシュトリガーで検知し、スペックをGithubからプルし、decKのコマンドを用いてstate-fileを生成します。そして、decK syncというコマンドを使うことによってKongに同期を取ります。こちらが、一連のライフサイクルの流れになります。

decKの進化はこれからも加速する

槌野：まとめとしては、decKは「KongのAPIOps運用を支援する」ツールです。

Open API SpecからKongの設定ファイルを生成することもできます。プラグインやコンシューマーの設定など、スペックに依存しない情報は分離して構成管理することができます。
この辺りの機能は私が触りはじめた頃にはありませんでしたが、2023年後半頃から機能が大幅に追加され、エンタープライズ版の運用においても実用性の高いツールに進化しています。

とはいえ自動化におけるトラブルを防ぐためには、どのようなサービスやルートにプラグインを適用するかなど、設計に関して十分に検討する必要があります。しかし、そのハードルさえ乗り越えることができれば、CI/CD運用の自動化は十分に実現可能です。

以前と比べ、APIOps Readyを非常に考慮した仕様に進化していますので、ぜひdecKを一度試していただけるとうれしく思います。

---

Kongに関するFindy Toolsの紹介・レビューはこちら
https://findy-tools.io/products/kong/334