Snowball Finance 通过 APISIX 改造其双活架构

Snowball Finance のインフラチームのシニア開発エンジニアであるWenjie Shi氏が、Apache APISIX Summit ASIA 2022 でSnowball FinanceのAPISIXを活用した実践を共有しました。本記事はその内容に基づいて、Snowball FinanceがApache APISIXを活用して内部のアクティブ-アクティブアーキテクチャの進化を実現し、より柔軟なサービス管理を実現した方法を紹介します。

課題

• 複雑なSDK認証モジュールが、アクティブ-アクティブアーキテクチャが市場サービスモジュールでのみ利用可能なため、ユーザーセンターがリージョンを跨いでアクセスされる際にシステムの複雑性とセキュリティリスクを増大させる
• OpenRestyには堅牢な監視システムがなく、拡張性を実現するためにカスタムスクリプトが必要で、開発と運用コストが高くなる
• 不完全なNGINXレジストリセンターとハートビートメカニズムの欠如により、可用性と安定性が低下し、システム障害を迅速に処理できない

目標

• ビジネスグループに対して透明性を保ちつつ、多くの変数を導入せずに変更を最小限に抑える
• インフラレベルで問題を一元的に処理し、ローカルデータセンター内で認証サービスを完了させる

成果

• ゲートウェイ層で統一された認証、サーキットブレーカー、レートリミットを実装し、システムの結合度を低減し、デュアルデータセンターシナリオでのサービス品質を向上させた
• APISIXの監視システムを活用してゲートウェイからサービス層までの統一された監視ソリューションを確立し、グローバルなトラブルシューティングに優れたサポートを提供した
• gRPCプロトコル変換とサービス管理のためのエレガントな実装アプローチを提供した

背景

2010年に設立されたSnowball Financeは、投資コミュニティとしてスタートし、現在では中国を代表するオンラインファイナンス管理プラットフォームとして、高品質なコンテンツ、リアルタイム市場サービス、取引ツール、資産管理などのサービスを投資家に提供しています。

これらのサービスの中でも、リアルタイム市場サービスは複数の上流データソースに接続し、データストリーミング、ストレージ、配信を通じて投資家に安定したデータサービスを提供しています。そのため、リアルタイム市場サービスはSnowball Financeのシステムにおいて常に主要なリソース消費源となっています。

そのため、Snowball Financeの重要な課題の一つは、市場サービスのパフォーマンス最適化を含む安定性の継続的な向上です。それでも、トラフィックのピーク時には、データの急増により一部のシステムが遅延したり、利用できなくなったりすることがあり、ユーザーエクスペリエンスに影響を与えることがあります。

この背景から、Snowball Financeは投資家に安定した高品質なサービスを提供するために、サービスアクティブ-アクティブ変換計画を立ち上げました。この計画において、Apache APISIXが実装を大幅に簡素化しました。さらに、クラウドネイティブAPIゲートウェイとして、APISIXは活発なコミュニティと豊富なエコシステムを持ち、複数のプラグインをサポートしています。これらの利点は、Snowball Financeのクラウドネイティブアーキテクチャの進化にも良い基盤を提供しています。

アクティブ-アクティブ変換の課題

単一アーキテクチャを適用していた時期には、ユーザートラフィックはサーバーロードバランシング（SLB）を経由してゲートウェイに入り、簡単な共通ロジック処理を行った後、バックエンドサービスに転送されていました。バックエンドサービスは、統合された認証モジュールを使用して、SDKを使用してSnowballユーザーセンターにユーザー認証を開始し、認証が成功すると後続の処理を続けていました。

実際のビジネスシナリオでは、いくつかの課題が徐々に浮き彫りになりました。

1. 複雑なSDK認証モジュール

アクティブ-アクティブ変換を実装する際、マイクロサービスのプロバイダーとコンシューマーを同期してデプロイおよび起動することはできません。Snowball Financeの市場サービスがクラウド上で最初に起動した際、ユーザーセンターがまだクラウド上でサポートされていなかったため、データセンターを跨いだ呼び出しが発生しました。ユーザーセンターの統計によると、そのRPC呼び出しは1日あたり数百億回に達し、ピーク時には50,000 QPSに達することがあり、これにより高いレイテンシが発生する可能性があります。

同時に、Snowball Financeの認証ロジックは複雑でした。OAuth2.0/JWTプロトコルに加えて、クライアントのバージョンやSnowball Financeの複数のアプリなど、多くの要素を考慮する必要がありました。さらに、認証モジュールがサービスに組み込まれていたため、アップグレードがより困難になっていました。

2. OpenRestyの機能制限

Snowball Financeは以前、OpenRestyをゲートウェイとして使用していましたが、OpenRestyは一部の機能において弱い部分がありました。そのため、開発者は既存の監視システムとOpenRestyを統合する際に、より多くのカスタマイズを行う必要がありました。さらに、DevOpsエンジニアは、セカンダリ開発プロセスを実装するためにカスタムスクリプトを追加する必要がありました。

3. 自社開発レジストリセンターへの依存

現在、Snowball Financeは、バックエンドサービスが起動時にレジストリセンターにリクエストしてゲートウェイに登録し、サービスが停止したときにサービスノードを削除するという方法でHTTPサービス登録を行っています。レジストリセンターは定期的にサービスノードをポーリングしてヘルスチェックを行います。しかし、オープンソースプロジェクトと比較して、自社開発サービスのメンテナンスコストは高くなっています。

APIゲートウェイ技術選定

ビジネス実践シナリオで徐々に明らかになった課題に基づいて、Snowballのインフラチームはゲートウェイ製品の研究を開始しました。

チーム内部では、ビジネスの透明性を確保しつつ、変更を最小限に抑え、多くの変数を導入しないことを望んでいます。また、インフラレベルで問題を一元的に解決し、ローカルデータセンター内で認証サービスを完了させたいと考えています。これらの点を考慮して、Snowball Financeは認証サービスをAPIゲートウェイに移行することを決定しました。

Snowball Financeは、新しいAPIゲートウェイが以下の要件を満たすことを期待しています：

• 高性能
• 強力な拡張性
• 複数のプロトコルのサポート
• ゲートウェイ認証の低コスト

以下は、OpenResty、Spring Gateway、Kong、APISIXの詳細なAPIゲートウェイ技術選定リストです。

ゲートウェイ	利点	欠点	O&Mコスト	可用性
OpenResty	高度にカスタマイズ可能で安定している	可観測性が低い	高い	高い
Spring Gateway	Java開発に優しい	パフォーマンスレベルが要件を満たさない	中程度	中程度
Kong	強力で機能が豊富	PostgreSQLのシングルポイントデータベース	低い	中程度
APISIX	クラウドネイティブで複数のプログラミング言語をサポートし、拡張性が高い	/	低い	高い

内部の要求と市場で人気のあるゲートウェイ製品を比較した結果、Snowball Financeは最終的にApache APISIXを選択し、その後のアーキテクチャに採用しました。

Apache APISIXに基づく実践

調整されたアーキテクチャ

上図に示すように、左側にはSnowball市場サービスの現在のアクティブ-アクティブアーキテクチャが表示されており、元のデータセンターのアーキテクチャに対応しており、変更はほとんどありません。右側には、クラウドへの移行後にマルチリージョンデザインに基づくアクティブ-アクティブアーキテクチャが表示されています。

Snowball Financeは、APISIXに基づいて以下の調整を行いました：

• 認証モジュールをプロキシ層に統一し、APISIXを使用して統一認証を行いました。JWTタイプの場合、APISIXのjwt-authプラグインを使用して直接ローカル認証を行うことができます。
• OAuth 2.0との互換性を確保し、APISIXを使用してSnowball Financeユーザーセンターを呼び出して処理を行いました。
• Snowball FinanceのバックエンドRPCサービスレジストリセンターと接続し、JWT認証が失敗した場合にバックエンドサービスを使用して認証を行いました。

アプリケーションシナリオ

バックエンドサービスがAPISIXに接続された後、主にゲートウェイ認証と可観測性の観点でいくつかの実践が行われました。

シナリオ1: ゲートウェイ認証

前述の通り、Snowball Financeの以前のアーキテクチャには統一された認証方法がありませんでした。一つの方法は、内部アプリケーション側がSDKを使用してユーザーセンターを呼び出して認証を行う方法で、もう一つはJWT認証を使用する方法でした。これら2つの認証方法が共存していたため、拡張性と保守性に問題が生じていました。

1. APISIXをゲートウェイとして統合した後、Snowball FinanceはAPISIXゲートウェイ層を使用して認証を一元的に管理しました。元のJWT認証方法は、公式プラグインjwt-authに置き換えられました。jwt-authプラグインの設定と使用は比較的簡単で、Dashboardでルートやアップストリームなどの関連情報を設定するだけでプラグインが有効になります。
2. Snowball Financeは、以前のOAuth 2.0関連の認証方法を処理するために、grpc-transcodeプラグインを使用して認証サービス呼び出しをプロキシしました。

Snowball Financeは、gRPCを呼び出して認証を実装するために、以下の3つのソリューションを検討しました：

• ソリューション1: Luaを使用して直接gRPCを呼び出す。このソリューションでは、ロードバランシングや動的アップストリームなどの関連実装を考慮する必要があるため、プロセスが煩雑になるため、採用されませんでした。
• ソリューション2: Luaコルーチンを使用してGolangロジックを呼び戻す。Snowball Financeは、この方法について実用的な経験が不足しているため、採用しませんでした。
• ソリューション3: Luaを使用してHTTP呼び出しを行い、gRPCインターフェースをAPISIXのgrpc-transcodeプラグインを使用して実装する。APISIXコミュニティの迅速なプラグイン最適化イテレーションのおかげで、Snowball Financeは最終的にこのオプションを選択してgRPC呼び出しを実装しました。

現在、実行中にプロトコルバッファファイルの手動同期が必要です。これは、ユーザーセンターがプロトコルバッファファイルを変更し、APISIXに保存されているバージョンと一致しない場合、認証問題が発生する可能性があるためです。

シナリオ2: 可観測性の下での多次元監視

Snowball Financeでは、ウェブサイトの立ち上げ後に多くのメトリクスを監視する必要があり、主に以下の3つの部分に焦点を当てています：

• NGINX接続ステータスとインバウンド/アウトバウンドトラフィック
• HTTPエラーステータスコード率（サービスまたはアップストリーム/ダウンストリームの問題をトラブルシューティングするために使用）
• APISIXリクエストレイテンシ（APISIXがリクエストを転送する際のロジック実行に要する時間）

例えば、一部の場合では、APISIXのレイテンシが高く見えることがあります（下図参照）。これは、レイテンシの計算ロジックに関連しています。現在、このロジックは、NGINX上の単一HTTPリクエストの時間消費から、このリクエストがアップストリームにルーティングされるまでのレイテンシを引いたものです。この2つの時間消費の差がAPISIXのレイテンシメトリクスとなります。

APISIXを使用した後、一部のプラグインを追加または変更すると、ロジックの変更が発生し、レイテンシ関連のデータに偏差が生じる可能性があります。データの正確性を確保するために、Snowball Financeはレイテンシ監視プラグインも追加しました。各データ監視の正確性を確保すると同時に、後続の問題を事前に特定し、トラブルシューティングを容易にします。

また、APISIXの可観測性機能を活用して、Accessログを収集し、フォーマット化および標準化された形でトラフィックダッシュボードに配信し、全体の傾向を多角的に把握し、潜在的な問題を特定して迅速に対処することが可能です。

シナリオ3: ZooKeeperレジストリのスケーリング

Snowball Financeでは、gRPC呼び出しはZookeeperレジストリに基づいて登録および発見されます。認証を実装するプロセスで、ローカルのJWT検証が失敗した場合、APIゲートウェイはSnowball FinanceユーザーセンターのgRPCサービスにアクセスして認証を行う必要があり、これにはAPIゲートウェイがレジストリセンターからバックエンドgRPCサービスのアドレスリストを取得する必要があります。

APISIX公式プラグインapisix-seedは、ZooKeeperを統合してサービスディスカバリを行うことができます。Snowball Financeは、自社のビジネスに特化したカスタマイズをいくつか行いました。

具体的な実装は、主にAPISIXのコンテンツノード上で行われます。Workerプロセスが起動すると、下図のようなZK-Restクラスタをポーリングし、定期的にサービスのソースデータと情報を取得し、それらをWorkerプロセスのローカルキャッシュに更新してサービスリストを更新します。

上図からもわかるように、ZK-RestクラスタはRest形式でZooKeeperデータにアクセスします。これにインスタンスを追加するだけで高可用性機能を実現でき、いくつかの複雑な操作を排除できます。しかし、この操作は、ZK-Restクラスタを定期的にポーリングする際に、サービスリストの更新に遅延が生じるという明らかな欠点ももたらします。

まとめと展望

現在、Apache APISIXはSnowball Finance内のゲートウェイ層として順調に稼働しています。具体的には：

• ゲートウェイ層で統一された認証、サーキットブレーカー、レートリミット機能を実装し、システム全体の結合度を低減し、デュアルデータセンター下でのサービス品質を向上させました。
• APISIXの監視を活用して、ゲートウェイからサービスまでの統一された監視ソリューションを確立し、グローバルなトラブルシューティングに優れたサポートを提供しました。
• gRPCプロトコルの変換とサービス管理のためのエレガントな実装アプローチを提供しました。

今後の使用において、Snowball Financeは以下のことを計画しています：

• APISIX Ingress ControllerをK8sクラスタに適用する。
• grpc-transcodeプラグインを使用してHTTP/gRPCプロトコル変換を行い、統一されたバックエンドインターフェースを実現する。
• traffic-splitプラグインを使用してトラフィックラベリングを行い、Nacosレジストリセンターに接続し、カナリアリリースやその他のサービスガバナンスを実装する。

今後の計画では、Apache APISIXを使用して既存のOpenRestyを置き換え、最終的に南北トラフィックのフルライフサイクル管理を実現する予定です。