APIゲートウェイ Kongを使って開発してる話。

# 0. はじめに
 こちらは、株式会社 RetailAI X Advent Calendar 2022 の 22日目の記事になります。
 昨日の記事は、@Carol_fanさんの『[DockerでGo言語のREST APIの構築](https://qiita.com/Carol_fan/items/c0c7db918e71c5a67b75)』でした。

　まず簡単に自己紹介すると、私は、社会人5年目の元SE・バックエンドエンジニアで、最近はクラウド（GCP）を触ってインフラ構築もちょっとやってます。
 自分が今アサインしているプロジェクトで、グローバルで人気があるOSSであるAPIゲートウェイ [**Kong Gateway**](https://github.com/Kong/kong)（[+ Enterprise版](https://konghq.com/pricing)）を使って現在開発を進めているので、その話をしたいと思います。

# 1. Kong って何？ - 概要
　はじめに、[**「Kong Gateway」**](https://github.com/Kong/kong)とは、OSSのAPIゲートウェイであり、オンプレサーバ上でもクラウド環境上でも動かすことができます。[container](https://hub.docker.com/_/kong)対応もしていて、k8s上でも動きます（[helm charts](https://github.com/Kong/charts)もあります）。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/bc2cfd88-5b12-9bc2-f116-90aa1c4cfcf7.png)
　APIゲートウェイの一般的な機能として、認証、ルーティング、アクセス制限、レート制限やログ分析等が挙げられます。Kong Gatewayでは、これらの横断的な機能を、[「Plugin（プラグイン）」](https://docs.konghq.com/hub/)という形で提供されています。各機能を提供するPluginを、API経由または直接設定ファイルを更新したりすることで、Kong Gatewayに対して各機能を追加・更新することができます。いわゆる「[マイクロカーネルアーキテクチャ](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html#:~:text=The%20microkernel%20architecture%20pattern%20consists,features%20and%20custom%20processing%20logic.)」の構成を採っているようです（最近「[ソフトウェアアーキテクチャの基礎](https://www.oreilly.co.jp/books/9784873119823/)」を読んだばかりで、恰好いいワードを言いたかった）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/b78a6248-7bcc-5399-2b3b-9127949b9973.png)
　Pluginの中には、有償 = Enterprise版のものもあります（特に、[OIDC](https://docs.konghq.com/hub/kong-inc/openid-connect/)のPluginが人気らしいです）。また、Kong Gatwayの設定部分（ルーティングやPlugin）の管理やその他機能をSaaSとして提供する[「Konnect」](https://konghq.com/products/cloud-api-platform)というEnterprise版のサービスもあります。
　そのため、Pluginや有償のサービスを含めて、（無償の）OSSの「Kong Gateway」の話をする時に、「**Kong**」という総称で呼ばれている印象があります。


　以上が「Kong」に関する概要レベルでの説明でした。
（「Kong Gateway」「(Kong) Plugin」「Konnect」等の詳細に関しては、英語ですが、[公式ドキュメント](https://docs.konghq.com/)に詳しく載っているので、そちらを参照してもらうといいと思います）

# 2. Kong の使い途 - レガシー・マイグレーション
　弊社で採用したプロジェクトにおけるKongの使い途は、一言でいうと「[レガシー・マイグレーション](https://e-words.jp/w/%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%83%9E%E3%82%A4%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3.html)」です。

#### 2-1. 小売・流通システムのレガシー化
　[弊社（株式会社Retail AI X）](https://www.retail-ai.jp/)では、「[TRIAL](https://www.trial-net.co.jp/)」という流通・小売業のリアル店舗や物流を支えるシステムを開発・運用しており、それらのシステムのレガシー化が進んでしまっているのが現状です。
（以下例は、店舗運営システム）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/6f15e53b-89cb-1083-cb17-7726a024ed97.png)

#### 2-2. 「ハード」なマイグレーションは、リスクが大きい
　とはいえ、一気にクラウド化やマイクロサービス化に対応しようとすると、店舗（現時点で271店舗）を支える既存システムに大きな影響が出てしまうことは間違いないと思いました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/468e6778-6c48-f01c-ddff-458b50c567e4.png)


#### 2-3. APIゲートウェイを介した「ソフト」なマイグレーションの可能性
　そこで、APIゲートウェイを挟むことで、より「ソフト」な、段階的なマイグレーションを実現しようとすることが、今回APIゲートウェイ導入の狙いとなります。
　そのため、今はまだ過度期なので多少中途半端に感じる面もありますが、クラウド環境（GCP）とオンプレが一緒になった「ハイブリッド」な構成になっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/aca70813-8885-ef4f-c002-e18525b846aa.png)


#### 2-4. APIゲートウェイをKongで構築した理由：①コスト最適
　「じゃあ、なんで **Kong** なの？」という部分を以下から説明したいと思います。
　1つ目の理由は、「コスト最適」です。別プロジェクトでAPIゲートウェイを自前で構築したことがありましたが、思いの外開発・運用のコストがかかり、ビジネスのコアとなる後ろの接続サービスのほうへ開発にエンジニア・リソースを割けない悩みを抱えていました。一方で、クラウドが提供するAPIゲートウェイ・管理のSaaSも、当時（2022年上旬）は、自分たちのプロジェクトのサービス規模に対しては割高感がありました。
　そこで、**OSSを利用することでコストを抑えつつ、OSSの有償サポート(Plugin含め)を受けることで開発・運用の負担の軽減も一定程度考慮するという折衷案**を採ることにしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/7ae51edd-2845-ddf6-9f2e-9a05bcd33ad6.png)


#### 2-5. APIゲートウェイをKongで構築した理由：②拡張性
　そして、2つ目の理由は、「拡張性」です。上記のOSSの有償サポート(Plugin含め)を受けることと重なる話なのですが、裸のOSSの機能・仕様のままだと、どうしても自分たちの要件とギャップがある部分を出てきます。そこで、**Pluginを追加することで、Kongの機能を拡張することができます。ただし、要件や制約条件はプロジェクトによって異なるのは当然として、各OSSのAPIゲートウェイ側も強みとする機能が異なっていたので、ここはケース・バイ・ケースだと思います。** また、標準のPluginで対応できない場合は、Pluginを自前でカスタマイズして作成することができますが、結局、前者の開発・運用コストの部分に乗っかってくることになります。そのため、自分たちの要件とPluginのカバー範囲に関して、PoC等の期間の中で十分に検証する必要があると今振り返っても感じます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/a412a5ba-9021-d392-f18d-c7f0d1260be4.png)
　ちなみに、[NEC](https://jpn.nec.com/)さんの官公庁向けの調査で、「[*OSSの成熟度を評価するために開発活性度、利用者コミュニティ、情報の検索性の観点で比較分析した。どの項目においてもKong Gatewayが優れた結果となっており、APIゲートウェイのOSSの中では安定性、利便性、今後の発展など様々な面で期待できる*](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/82a1ea56-128f-4cf6-bbd5-9ef6d4b7bafc/22ab734b/20221020_policies_budget_subsidies_01.pdf)」とする報告もあるようです。

#### 2-6. Kong GatewayとKonnectを用いた実際のハイブリッドなシステム構成
　以上のような観点から、Kongを使ってAPIゲートウェイを構築することを決めたのですが、実際のシステム構成（概要レベル）が以下となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/234514/d49d9ab1-a9ba-c287-8e22-6268b31e5d74.png)
　Kong以外のコンポーネントに関しては割愛しますが、上記の構成では**Kong Gateway**（この場合、Data Plane (DP)と呼びます）に加えて、**Konnect**（Control Plane (CP)と呼びます）を使用しています。
　**Kong Gateway**自体のruntimeは弊社のクラウド上（GKE上）で動かしており、そのルーティング等の設定の更新内容が、Kongが提供しているSaaSの**Konnect**からリアルタイムで送信されて随時反映される、というハイブリッドな仕組みになっています。API経由ではなく、GUI画面から簡単に設定を変更できるので、開発環境等でアドホックに検証したい場合に便利ですし、Konnect独自のruntimeをグループで管理する機能（`dev`/`stg`/`prod`のように）があったりするので、使うことにしました（このサービスも、コスト最適のバランスの中で収まるように考慮しました）。

　以上、弊社におけるKongの使い途についての紹介でした。
　上記の内容や用いているスライドは、[**Kong Summit Japan 2022**](https://jp.konghq.com/blog/kongsummitjapan2022)での発表にて使用したものなので、本事例について詳しく知りたい方は[こちら](https://jp.konghq.com/blog/kongsummitjapan2022)から参照できると思います（投稿時点では、当日の投影資料や動画は公開準備中でした）。

# 3. おわりに
　最近、自分のプロジェクトでも利用しているGCPにおいて、API管理を提供する**Apigee**（SaaS）に、[従量課金制の新しい料金体系を導入](https://cloud.google.com/apigee/docs/api-platform/reference/pay-as-you-go)されたようです。他に、Enterprise版のKongの今後のロードマップとして、Konnect（Control Plane）だけでなく、**Kong Gateway（Data Plane）のruntimeも含めて、SaaS**として提供しようと検討していることも直近耳にはしています。
　いずれにしても、各所からAPIゲートウェイ・API管理関連の最新情報をフォローアップしつつ、自身のプロダクトの（将来を含めた）サービス規模、制約条件や予算に合った、最適なAPIゲートウェイの選定・構築方法を見直し、常にアップデートしておく必要がありそうです。

　その他、Kong GatewayやKonnectでの**実際の設定内容・方法やCI/CDの構築等、具体的な実装**の話を（~~自分の残機が足りなくて~~）紹介できなかったので、次回それを書こうかなと思います。

### 番外編 : 直近のKongでの活動について、ちょっとだけご紹介🙇
#### - 先週、[**Kong Summit Japan 2022**](https://jp.konghq.com/blog/kongsummitjapan2022)にて、Kongを使用している自分のプロジェクトについて発表しました！
　本稿でも触れたように、Konnect + Kong Gatewayを使用したユースケースとして説明しています。詳しく知りたい方は[こちら](https://jp.konghq.com/blog/kongsummitjapan2022)からいずれ参照できると思います（投稿時点では、当日の投影資料や動画は公開準備中でした）。

#### - 日本のKongコミュニティである[**Kong Community, Japan**](https://kongjp.org/)を今年発足しました！
 　一応、私もorganizerの一員として務めています。グローバルではKongの採用や各国でのコミュニティは活発なのですが、日本ではそこまで盛り上がっていない、、というのが現状です。
　しかしながら最近、公共の分野で[デジタル庁がKong Gatewayを推奨APIゲートウェイとして認定する](https://prtimes.jp/main/html/rd/p/000000006.000098201.html)等、盛り上がりを見せているので、少しでもご興味がある方は以下などから覗いてみてください。
  - [Kong Community, Japan](https://kongjp.org/)
    - [connpass](https://konghq.connpass.com/)
    - [slack](https://join.slack.com/t/kongjp/shared_invite/zt-18yyxrpvo-GHbqF0rd3z6_LeA65GmGWA)
  - [Kong Community（Global）](https://konghq.com/community)

　以上、最後まで読んでいただき、ありがとうございました！

### 明日（23日目）の記事は、@takaomagさんの『[threadと一貫性とAtomic](https://qiita.com/takaomag/items/cbf8301709024e6073fa)』です。ぜひご覧あれ！