APISIXによるファンド管理大手の変革

概要

Invesco Great Wallについて

Invesco Great Wall Fund Management Co., Ltd. ("IGW")は、中国とアメリカの合弁によるファンドマネジメント会社で、マルチアセット投資能力と株式投資の専門知識を有しています。同社の主な事業は、定量投資、アクティブインカム、および固定収益です。IGWの運用資産は8500億米ドルを超え、6000万人以上の投資家にサービスを提供しています。

IGWは、資産管理を主な重点とし、株式、固定収益、定量戦略など、複数の資産クラスにわたる多様な投資戦略を提供しています。

課題

異なるビジネスシステム間で標準化されたゲートウェイが不足していたため、ゲートウェイに関連する多数のサービスが独立して運営され、メンテナンスコストが増加していました。
IGWの以前のゲートウェイは、負荷分散やカナリアリリースなどの機能が限られており、実装が複雑で時間がかかるため、運用上のボトルネックを引き起こす可能性がありました。
以前の設定では認証機能がなかったため、さまざまなシステムインターフェースに直接アクセスでき、ビジネスシステムに重大なセキュリティリスクをもたらしていました。

成果

APISIXを導入することで、IGWは統一されたAPIゲートウェイを構築し、冗長な開発作業と機能の品質の不一致の問題を解決しました。
DevOpsとパイプラインの統合により、ルートとサービスのデプロイの安定性が大幅に向上し、ルーティングとサービスのリリース効率が改善されました。
APISIXのホットリロード機能により、サービスの再起動が必要な場面が大幅に減少し、システムリソースへの負荷が軽減され、ダウンタイムが削減されました。

背景

まず、IGWのビジネスシステムのアーキテクチャの進化について詳しく見ていきましょう。当初、IGWはモノリシックサービスのアプローチを採用し、サービスアプリケーションを物理マシンにデプロイしていました。しかし、サービスとビジネスが成長するにつれて、運用と開発のコストが増加し始めました。これにより、仮想マシンの段階への移行が促されました。

仮想マシンの段階では、異なるビジネスシステムで使用されるゲートウェイに統一性がなく、各ビジネスが独立して運営されていたため、ゲートウェイに関連する多数のサービスが存在し、メンテナンスコストが高くなっていました。

ファンドおよび証券業界では、ネットワークゾーンに関する規制要件があります。各ネットワークゾーンは、情報セキュリティレベルに基づいて、物理的に分離されたセキュアゾーンまたは論理的なセキュアゾーンに分割する必要があり、その際にファイアウォールが使用されます。

金融技術とデジタルトランスフォーメーションにおけるクラウド戦略に沿って、IGWはクラウド移行プロジェクトを開始しました。

IGWがAPISIXを選んだ理由

金融業界は他の業界と比べてサービスの安定性を特に重視するため、安定性が最優先されます。仮想マシン環境ではゲートウェイサービスが急増し、多様なビジネス要件を満たすことが不可欠でした。そのため、ゲートウェイの拡張性が非常に重視されました。さらに、オブザーバビリティも重要な役割を果たし、ビジネスシステムのロギング、トレーシング、モニタリングに対する強いニーズがありました。最後に、ホットリロードの機能も必要でした。

IGWがAPIゲートウェイを選ぶ際のポイント

NGINXは設定の動的更新に制限があるため、設定変更時にリロードが必要です。さらに、持続的接続のシナリオでは、このプロセスがビジネスシステム内のトラフィック変動を引き起こし、ユーザーエクスペリエンスに影響を与える可能性があります。

そのため、これらの4つの焦点を考慮し、IGWの技術チームは市場で人気があり広く認知されている2つのAPIゲートウェイ、APISIXとKongを包括的に比較しました：

技術フレームワーク: APISIXとKongはどちらもOpenRestyに基づいて開発されています。設定センターに関しては、APISIXはetcdを採用し、KongはPostgreSQLを選択しています。APISIXは、etcdとAPISIXのクラウドネイティブな特性により、クラウドネイティブな分散型ゲートウェイとして際立っています。一方、Kongの設定センターの選択は、単一障害点の問題を引き起こす可能性があり、高可用性を実現するために追加のインフラストラクチャサポートが必要です。
コミュニティの活動: APISIXとKongはどちらも活発なコミュニティを持ち、リポジトリでの1日あたりのコミット数は平均20回です。
プラグイン: APISIXには80以上のプラグインがあり、各プラグインのドキュメントは1つだけです。Kongには30以上のプラグインがあり、各プラグインのドキュメントは4〜5つです。APISIXの各プラグインのコードは100行以上、Kongの場合は300行以上です。
拡張性: APISIXは多くのプログラミング言語をサポートし、WebAssemblyもサポートしています。KongはLuaのみを使用してプラグインを記述できます。
ホットリロード: これはチームが重視する点です。APISIXは、プラグインの有効化や無効化、新しいプラグイン（カスタムプラグインなど）の追加時にミリ秒レベルのホットリロードをサポートしています。また、APISIXはゲートウェイパラメータの動的変更もサポートしています。しかし、IGWが技術選定を行った時点では、Kongはこの機能をサポートしていませんでした。
オブザーバビリティ: APISIXとKongはどちらもOpenTelemetryをサポートしていますが、APISIXはElasticsearch、Prometheus、SkyWalkingにも接続できます。IGWが技術選定を行った時点では、KongはSkyWalkingをサポートしていませんでした。

上記の懸念点と比較ポイントに基づいて、IGWの技術チームは最終的にAPISIXをAPIゲートウェイとして選択しました。

IGWのユースケースとソリューション

IGWのシステムアーキテクチャの紹介

IGWのビジネスシステムは、おおまかに取引エリア、生産エリア、管理エリアの3つの部分に分かれており、それぞれ異なるAPIゲートウェイを使用していました。もともと、IGWはNGINXをウェブサーバーおよびリバースプロキシとして使用していました。同じネットワーク分類のビジネスはすべて同じNGINXを使用していました。その結果、各サービスの変更やルーティングの更新には、NGINX上で手動で更新とリロードが必要でした。

Invesco Great Wallのシステムアーキテクチャ

上記の図は、IGWのシステムアーキテクチャを示しています。ゲートウェイセキュリティクラスタ層では、Zuul、Spring Cloud Gateway、Kong、NGINXなど、複数のフレームワークを使用しています。アーキテクチャ管理は統一されておらず、管理が比較的煩雑でした。

ソリューション

これらの課題を解決するために、IGWはゲートウェイクラスタをAPISIXに変換することに重点を置きました。APISIXはKubernetesクラスタ上にデプロイされるため、YAMLを使用してAPIを宣言的に統一管理できます。さらに、APISIX Ingress ControllerはKubernetesリソースの変更を自動的に監視し、ApisixRoute、SSLなどのAPISIX設定をリアルタイムで同期します。

APISIX使用後のInvesco Great Wallのアーキテクチャ

以下は、APISIX使用後のIGWのルート同期シーケンス図です。

APISIX使用後のIGWのルート同期シーケンス図

ユースケース

APISIXを使用した後、IGWは多くのメリットを達成しました。その中でも、IGWチームがビジネスの観点から特に重視しているのは、インテリジェントなルーティング、認証、オブザーバビリティ、およびトラフィック制御です。

効率的なインテリジェントルーティング

Invesco Great Wallの効率的なインテリジェントルーティング

インテリジェントルーティングは、主にレイヤー4およびレイヤー7の負荷分散に示されています。図に示すように、APISIX Ingress Controllerを介して同期されたルーティング情報には特定のラベルが付いており、誤った削除操作を効果的に防ぎます。

環境でのテストの結果、データが削除された場合でも、KubernetesはAPISIXと迅速に自動的に同期できるため、データ損失の問題が解決されます。

さらに、APISIX上のルーティング更新はミリ秒レベルの応答性を実現し、設定同期の遅延がほとんど感知されないため、優れたユーザーエクスペリエンスを提供します。

強化された認証

統一ゲートウェイを導入する前は、各ビジネスユニットがデータインターフェースのセキュリティを確保するために、個別に認証関連のコンポーネントを開発する必要がありました。ビジネス側では、各システムが冗長な認証機能を開発する負担を負い、開発コストが高くなり、実装された機能の品質もばらついていました。そのため、セキュリティ検証のために、IGWは統一された認証とHTTPSリダイレクトプラグインを導入しました。

統一ゲートウェイを導入する前は、サービスのHTTPS証明書は高可用性（HA）エンドポイントで復号化されていましたが、これにより複雑さ、運用負荷、セキュリティリスクが増加していました。

Invesco Great Wallの強化された認証

これらの課題を認識したIGW技術チームは、ゲートウェイ内に認証機能を集中させる計画を立て、上記の問題を解決しました。このアプローチにより、ビジネスシステムの研究開発効率が大幅に向上し、開発者がコアビジネスの開発に集中できるようになりました。

APISIXに移行することで、これらの欠点を軽減できます。APISIXはHTTPS終端を処理し、SSL証明書を動的にロードし、セキュリティ関連のタスクを集中管理することで、システム全体のパフォーマンスと柔軟性を向上させます。

モニタリングを超えて

以前、IGWの元のビジネスシステムでは、オブザーバビリティのサポートが弱く、システムのトラブルシューティング、パフォーマンス最適化、信頼性、および積極的なモニタリングに悪影響を及ぼしていました。

そのため、IGW技術チームは、APISIXが提供するログモニタリングやトレーシングなどの複数のプラグインを迅速に統合し、オブザーバビリティ能力を向上させることを目指しました。

さらに、チームはApache SkyWalkingを分散トレーシングに、Prometheusをモニタリング目的に、ELKを効率的なログ収集に活用するための研究を積極的に行っていました。驚くべきことに、APISIXはこれらのプラグインをすべてサポートしており、IGW技術チームの期待と要件を完全に満たす理想的なソリューションであることが証明され、優先選択肢となりました。

IGWのサービストポロジ

上記の図は、技術チームがSkyWalkingを本番環境に統合した後のIGWのサービストポロジを示しています。この包括的な図は、ゲートウェイを介したトラフィックの方向や成功率などの重要な情報を含む、サービス間の呼び出し関係を明確かつ簡潔に視覚化しています。このトポロジ図を活用することで、IGWチームはサービスチェーン内のエラーや問題の正確な位置を迅速に特定できます。

トラフィック制御のマスタリング

APISIXは、IGWにとって多様なトラフィック制御メカニズムを促進する効果的なソリューションであることが証明されています。APISIXを採用することで、IGW技術チームはカナリアリリースと重みベースの戦略を通じてシームレスにトラフィック制御を実現しました。この堅牢な機能により、トラフィックの分散を効率的に管理し、カナリアリリースを簡単に実装し、必要に応じてトラフィックの重みを調整できます。

カナリアリリースに基づくシナリオでは、ゲートウェイはHTTPリクエストを介してダウンストリームインターフェースを呼び出し、特定のデータを取得し、返された結果に基づいてリクエストをカナリアリリース環境に送信する必要があるかどうかを判断します。

重みポリシーに基づいて、仮想マシンとコンテナのサービスが外部に並行して提供されます。例えば、トラフィックの90％が仮想マシンサービスにヒットし、10％がクラウドサービスにヒットして、クラウドサービスの安定性を検証します。現在、IGWの本番環境では、重みベースのカナリアリリースが設定されています。

APISIX使用後の成果

統一されたAPIゲートウェイの構築

APISIXを導入することで、IGW技術チームは、負荷分散、動的アップストリーム、カナリアリリース、サーキットブレーカー、認証、およびオブザーバビリティなどの豊富なトラフィック管理機能を提供するAPIゲートウェイフレームワークの標準化を達成しました。

IGWはゲートウェイ上で統一された認証機能を実装し、冗長な開発作業と機能の品質の不一致の問題を解決しました。これにより、開発者が開発に集中できるようになり、ビジネスシステムの研究開発効率が大幅に向上しました。

ルーティングとサービスのデプロイの安定性の向上

APISIX上のルーティング更新はミリ秒レベルの応答性を実現し、迅速で効率的なパフォーマンスを保証します。さらに、設定の同期はほぼ瞬時に行われ、ユーザーエクスペリエンスが向上します。

また、DevOpsとパイプラインの統合により、ルートとサービスのデプロイの安定性が大幅に向上しました。この合理化されたアプローチにより、ルーティングとサービスのリリース効率が向上し、より信頼性の高い一貫した結果が得られるようになりました。

ホットリロードによるパフォーマンスと稼働時間の向上

IGW技術チームはホットリロードの力を高く評価しています。APISIXは、プラグインの有効化や無効化、カスタムプラグインの追加、ゲートウェイパラメータの動的更新を可能にするシームレスなホットデプロイプロセスを提供します。

その結果、プラグイン設定やゲートウェイ設定の変更を、システムの再起動や中断なしに即座に適用できます。この注目すべきホットリロード機能により、APISIXプラットフォームの柔軟性と俊敏性が大幅に向上し、開発者が設定をリアルタイムで調整し、特定の要件に合わせてゲートウェイをカスタマイズできるようになります。

APISIXのホットリロード機能により、サービスの再起動の負荷が大幅に軽減されました。この機能により、サービスの更新や変更を完全な再起動なしに適用できるため、システムのパフォーマンスが向上し、ダウンタイムが削減されます。

まとめ

IGW技術チームは、APISIXの機能、信頼性、パフォーマンスをさらに強化し、将来のシームレスな運用を実現するための期待も表明しました。

Invesco Great WallでのAPISIXの成功した導入は、重要なメリットとポジティブな結果をもたらしました。APISIXにより、IGWチームは統一されたAPIゲートウェイフレームワークを実現し、運用が合理化され、コストが削減されました。この統合により、ルーティングとサービスの安定性が向上し、パフォーマンスが改善され、中断が最小限に抑えられました。

Invesco Great Wallの注目すべき結果を踏まえると、APISIXはファンドおよび証券業界を含む金融サービス業界に適した非常に効果的なAPIゲートウェイソリューションであることが証明されています。この成功事例は、金融業界におけるAPISIXの採用のメリットを強く示しており、業界の他の組織にもその導入を強く推奨します。