放弃Spring Cloud Gateway！金融科技APP环贝如何利用Apache APISIX

Javaへの愛と憎しみ

なぜ金融システムはJavaを好むのか

Javaはそのリリース以来、言語の優位性と巨大なエコシステムにより、多くの開発者に人気があり、好まれています。

過去15年から20年の間、多くの金融システムが主要な技術スタックとしてJavaを選択してきました。いくつかの調査の結果、Javaには以下のような利点があると結論づけました：

上記の理由から、Javaは金融ソフトウェアシステムの支持を得ています。

クラウドネイティブ時代におけるJavaの現状

技術の急速な発展に伴い、業界はまもなくモノリシックアーキテクチャを放棄し、マイクロサービスとクラウドネイティブが主流となるでしょう。しかし、近年の技術環境において、Javaは一部のビジネスシナリオでその支配的な役割を失いつつあります。

まず、Javaのパフォーマンスは弱いです。C関連の技術スタックと比較すると、なぜ私がこのように言っているのかが理解できるでしょう。

次に、Javaは仮想マシン上で動作し、仮想マシンがJavaのメモリ管理を担当します。そのため、高性能や動的な変更が必要な場合、Javaは競争力が低下します。

さらに、Javaは多くのリソースを必要とします。コストを気にせずにフレームワークを構築することは簡単です。しかし、クラウドネイティブ時代において計算がより詳細で細分化されるようになると、リソースはこれまで以上に貴重になります。また、Javaは重く、時々再起動が必要なため、実行に莫大なリソースを消費します。その結果、QPSやビジネスの継続性に対する高い要求がある場合、Javaには問題が生じます。

最後に、ポインタの問題も議論する価値があります。ポインタはC/C++に精通した開発者にとっては良いリソースです。しかし、Javaは仮想マシン上で動作するため、メモリ管理は開発者ではなくGC（ガベージコレクション）によって処理されます。そのため、高い並行性、トラフィック、パフォーマンスが厳しく要求される状況では、Javaのパフォーマンスが不十分である可能性があります。

なぜHuanBeiはAPISIXを選んだのか

Shuhe Groupは、企業や個人向けに効率的でインテリジェントなサービスを提供する金融技術プラットフォームであり、HuanBei、EnjoyPayなどの製品を持っています。HuanBeiは、複数の消費シーンに対応する分割払いサービスを提供するプラットフォームです。ライセンスを持つ金融機関と協力して、HuanBeiは個人向けローンサービスや起業資金の提供も行っています。HuanBeiはビジネスにおいて常にJava技術スタックを使用して製品を開発してきました。

Spring Cloud Gatewayは、Spring Cloudエコシステム下でマイクロサービスをより良く管理するためのゲートウェイです。Spring Cloud Gatewayは、Javaを主要な開発言語として使用する企業にとっては優れたAPIゲートウェイです。しかし、最近のAPIゲートウェイのアップグレードにおいて、HuanBeiは長年使用してきたSpring Cloud Gatewayを放棄し、Apache APISIXの使用を開始しました。

Spring Cloud GatewayとAPISIXのアーキテクチャの違い

HuanBeiはAPISIXを採用する前に、3つの異なるAPIゲートウェイシステムを使用していました。HuanBeiは、Spring Cloud Gatewayを運用および出口システムのゲートウェイとして、OpenRestyをビジネスシステムのゲートウェイとして使用していました。

HuanBeiが最初にSpring Cloud Gatewayを運用および出口システムのゲートウェイとして使用したのは、Spring Cloud Gatewayが巨大なエコシステムを持ち、分散開発システムを簡単にデプロイおよびメンテナンスできるためです。ビジネスの基盤が構築された際に、迅速にビジネスモデルを構築するために、HuanBeiはSpring Cloudが提供するすべてのサービスを使用しました。

ビジネスの発展に伴い、元のアーキテクチャではゲートウェイにメモリオーバーフローや高いCPU使用率などの安定性の問題が発生し始めました。そのため、HuanBeiはゲートウェイのパフォーマンスを向上させ、複数のゲートウェイを統一管理するために、Apache APISIXをアーキテクチャ内で唯一のゲートウェイとして使用しています。

新しいゲートウェイフレームワークでは、ゲートウェイはサービスディスカバリを介してリクエストトラフィックを直接ビジネスシステムに転送します。しかし、バックエンドアプリケーションがサービスディスカバリをサポートしていない場合や、Consulに正常なPodがない場合、システムはトラフィックを以前のイントラネットK8s Ingressにリダイレクトします。

APISIXの実践的な応用

HuanBeiは、内部に複数のゲートウェイフレームワークがあるため、Apache APISIXを直接使用することができず、実際のビジネスシナリオでAPISIXの設定を変更する必要があります。

APISIXのビルドとデプロイ

内部開発中、HuanBeiはAPISIXゲートウェイのソースコードとカスタムコードを異なるルートパスに配置し、それらが独立して協力し、反復できるようにしました。HuanBeiはゲートウェイをデプロイするためにDockerイメージを使用しました。まず、APISIXの特定のバージョンに基づいてデフォルトのイメージを作成し、その後、カスタムコードを使用して新しいイメージにラップしました。

カスタムコードのラップにはlua_package_pathを使用してコードディレクトリを指定するのではなく、同じ名前のファイルが存在する場合、ソースコードディレクトリのデフォルトイメージapisixを直接上書きしました。Dockerfileは以下の通りです：

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

APISIXのログはローカルに保存されます（Syslogや他のプラグインで収集可能）。NGINXの設定テンプレートを変更し、使用するプロファイルを確認して、ログをローカルに保存するか、Syslogを介してFLUENTDに保存するかを決定します。また、イメージをビルドする際にFLUENTD_HOST変数を置き換える必要があります：

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

NGINX設定テンプレートでは、HuanBeiはログの保存方法を変更しただけでなく、ENV環境変数とlua_shared_dicts設定をループで追加し、いくつかのNGINX最適化パラメータを修正しました。

HuanBeiは、異なるビジネスニーズに基づいてトラフィックを分離し、類似の機能を持つ複数のゲートウェイを作成します。そのため、HuanBeiは内部で「単一のソースコードだが複数のゲートウェイアプリケーション」という計画を使用しています。まず、HuanBeiは各ゲートウェイのconfig-xxx.yamlファイルをプロファイル機能を使用して設定し、その後、DevOpsプラットフォームを介してイメージをビルドする際に、アプリケーションの名前に基づいて異なるゲートウェイのDockerイメージを構築できます。

エンタープライズレベルのカスタマイズプラグイン

内部の運用システムにアクセスする際、システムは多くのバックエンドAPIを呼び出してデータを取得し、これらのAPIはAPIゲートウェイ設定のホワイトリストに含める必要があります。権限システムは、ログインユーザーの役割に基づいてページが提供するAPIの範囲が異なるため、関連するAPIリストを維持する必要があります。ページから新しいAPI呼び出しがあるたびに、開発者はゲートウェイと権限システムで2回設定を追加する必要があり、これは冗長で繰り返しの作業です。

これを実現するために、HuanBeiはゲートウェイ設定と権限システム設定の間の障壁を取り除き、権限システムのエントランスのみを保持します。ゲートウェイ設定管理システムは定期的に権限APIを取得し、それをゲートウェイのAPIホワイトリスト設定に切り替えます。この動作により、不要なユーザー設定アクションが省略され、権限システムが権限制御を行うのに役立ちます。さらに、運用ページで呼び出されるバックエンドAPIが権限システム設定に存在することを保証します。

ビジネスシナリオでは、ネイティブプラグインでは満たせないニーズが常に存在し、カスタマイズ開発が必要です。APISIXは、ネイティブプラグインを簡単にカスタマイズできる多くのツールを提供しています。以下の表は、HuanBei内でAPISIXに基づいて開発されたいくつかのカスタマイズプラグインをリストアップしています：

ゲートウェイのカナリアリリース

以前、HuanBeiはK8sコンテナとしてOpenShiftを使用していました（現在はACKクラスタにアップグレード済み）、IngressはHaproxyで構築されていました。

パブリックネットワークのK8s IngressのHaproxyが単一ドメインのトラフィックを2つの異なるNamespaceのルートパスに分割できないため、新しいゲートウェイを古いゲートウェイと同じNamespaceにデプロイすることを検討する必要があります。言い換えると、各ドメインのルートパスには複数のサービスがあり、総トラフィックの異なる割合を割り当てることで新旧ゲートウェイのトラフィックを制御できます。

実際の実装フローは以下の通りで、古いゲートウェイのNamespaceに新しいゲートウェイをデプロイするためにグループcとdを追加し、新旧ゲートウェイのトラフィック比率を制御できます。

Javaに関連するゲートウェイの要素

多くのJava開発者は、マイクロサービスアーキテクチャにおいてSpring Cloudを選択します。なぜなら、Spring CloudはJavaをシームレスにサポートし、ソースコードにクラスライブラリを埋め込むことができるからです。しかし、実際にはアップグレードが難しい状況が発生します。例えば、チームが複数のクラスライブラリを維持する必要があり、10の異なる言語と10の異なるバージョンがある場合、このチームは100の異なるクラスライブラリを維持する必要があります。

現在では、プロキシ（APIゲートウェイ）を使用してマルチバージョンやマルチ言語の問題を簡単に解決できます。では、Java技術スタックを使用し、APISIXをAPIゲートウェイとして選択する企業にとっての利点は何でしょうか？HuanBeiの実践的な経験に基づいて、2つの側面から結論を導き出しました。

企業にとって

1. 優れた機能性とパフォーマンス

HuanBeiが4コアの仮想マシンを使用し、プラグインなしでAPISIXをストレステストした場合、APISIXのQPSは80kに達します。さらに、APISIXはSpring Cloud Gatewayがコンシューマートラフィックを受信する際のパフォーマンス問題を完璧に解決し、以前のゲートウェイと比較して本番環境でのパフォーマンスが30%向上しました。

さらに、APISIXは実際のテストにおいて、認証と識別、可観測性、サービスディスカバリ、レート制限、4層および7層トラフィック転送など、すべての企業要件を満たすことができます。機能拡張に関しては、APISIXは70以上のプラグインをサポートしており、ほとんどのビジネスはそのネイティブプラグインを使用できるため、開発作業を大幅に削減できます。

2. ビジネスコストの削減

APISIXを使用する前、企業はパフォーマンス問題を解決するためにサーバーの数を増やす必要があり、ハードウェアコストが大幅に増加しました。

HuanBeiはコストを計算し、APISIXを使用した後、サーバーのコストが約60%削減されたことを発見しました。さらに、技術スタックを統一した後、ビジネスはAPISIXのネイティブアーキテクチャに基づいて迅速に異なる機能を拡張し、開発費用を削減し、製品のリリース時間を短縮できます。

開発者にとって

1. ビジネス要件を満たす

ビジネスで使用されるすべてのソフトウェアやテクノロジーは、ニーズに応えるべきです。しかし、実際のテストと研究結果から、APISIXはより優れた安定性、可観測性、拡張性を持っています。

ソフトウェアはビジネスに奉仕することを目的としています。そのため、ビジネス要件が企業のリソースを節約できる場合、その企業がどの技術スタックを使用しているかに関わらず、その企業に適したコンポーネントを使用するべきです。

2. メンテナンス費用の削減

以前使用していたOpenRestyと比較して、APISIXは学習コストが低く、メンテナンスが容易です。同時に、APISIXの豊富なプラグインは、標準機能のデプロイメントと開発を簡素化し、製品のリリース時間を短縮します。

さらに、APISIXの強力なログと動的デバッグ機能は、ビジネスにおける障害点を検出し、迅速にエラーを特定し、時間を節約するのに役立ちます。

結論：金融業界の発展のトレンド

急成長段階では、効率が唯一重要です。そのため、ディレクターは自分たちが慣れ親しんだ言語を使用してシステムを構築し、低レベルのフレームワーク選択時に異なる技術スタックを選択して、ビジネスモデルをより迅速に立ち上げることを好みます。異なるディレクターは異なる技術スタックを選択するため、将来的に多くの問題が発生します。しかし、ほとんどの活発な金融企業や金融サービス会社は、同じ技術的問題に直面します：マルチ技術スタックの問題です。この問題が発生した場合、彼らは技術スタックを1つに統合する必要があります。

企業のビジネスが正しい軌道に乗ると、システムを垂直的に分割する時が来ます。企業は情報サイロアーキテクチャをフロントエンド、ミドルエンド、バックエンドの3層アーキテクチャに変える必要があります。その後、システムが安定して動作するようになると、企業は低レベルのコンポーネントを自ら実装する時が来ます。

システムを構築する最終的な目標は共有することです。システムの繰り返し性が高いほど、メンテナンス費用が低くなります。そのため、ビジネス運営が安定すると、多くの企業は垂直分割や低レベルの基本コンポーネントの実装を開始し、メンテナンス費用をコントロールします。

企業にとって、費用は常に最も重要な原則です。急成長段階では、企業はビジネスを迅速に立ち上げ、運営する必要がありますが、この大規模な環境下では、予算内で費用が最優先事項であるべきです。その場合、効率とコストの間で選択する必要があります。そのため、予算が限られている場合、企業は最先端の技術を使用しません。同様に、技術スタッフは技術スタックを選択する際に、この新しい技術がチームにどのような影響を与えるか、現在のインフラストラクチャにどのような利益をもたらすかという次の質問を考慮しません。

技術スタッフは、この新しい技術の費用のみを考慮します。