Kongってみなさんご存知ですか。 ここ数年 Serverless アーキテクチャで AWSの API Gatewayの存在が際立ってますが、 いわゆる API Gateway の役割を担うのが Kong です。

API Gateway

API Gateway はその名の通り、API の Gateway の役割を担います。 詳しくはこちらのサイトに記載されています。 今までの レコチョクのバックエンドでは、共通機能だけでなくビジネスロジックも1つのシステムが兼ねており、システムが肥大化しています。 共通機能の部分（認証だったりサーキットブレーカーだったり）については誰が実装しようが機能は同じになるはず、、、なのでわざわざ実装するのはコストが掛かりますよね。 そこで、今後は機能を分解し、共通機能部分を API Gateway(Kong)で実装することとなりました。

いまある API Gateway の一例

• AWS API Gateway
  • フルマネージドなので運用に耐えられるか微妙
  • IPを固定できない + Publicで受けられるようにする必要がある
    • NAT Gatewayで回避できるがコストが少々高い
• Netflix zuul
  • ドキュメントがほとんどない、、、 (getting start できなかった)
• TYK
  • 機能とドキュメントは十分にある
  • 日本での情報がまったくない
• Kong
  • 管理用の RESTfullAPI が用意されている
  • プラグインが豊富(ただし独自開発しようとするとLua言語)
  • 日本の企業でも導入されているらしい
• KrakenD
  • 一番特徴的な API Gateway
  • 複数の バックエンドサービスに対して同時呼び出ししレスポンスを結合して返す
  • コンテンツタイプも複数サポートしていて一番欲しい機能
  • ヘッダーはプロキシしてくれない
  • 分散トレーシングできないので致命的

Kong を選んだ理由

今回 Kong を選んだ理由としては、GitHub の状況から海外でも比較的利用されて機能も十分満たしており、 プラグインが豊富だったからです。 また、ドキュメントも綺麗にまとまっていたのでとっつきやすいというのもありました。 個人的にはKrakenDの機能がとても魅力的でしたが、まだ発展途中でヘッダーをプロキシできないバグもあったりと信頼性にかけたので今回は見送りました。

最後に

自分たちで開発するべきところ（ビジネスロジック）に注力していけたらと思います。

関連記事 : https://www.slideshare.net/charlier-shoe/api-gateway