API Gateway for Web3: APISIX 如何赋能 Hyperchain

概要

世界をリードする企業向けコンソーシアムブロックチェーン基盤インフラストラクチャおよびソリューション提供者であるHyperchain Technologiesは、革新的なインフラストラクチャを構築し、社会のデジタル化を推進することを使命としています。急速な成長の中で、HyperchainはHyperchainブロックチェーンプラットフォームを構築する際に以下のような多くの問題に直面しました：

標準化されたトラフィック管理がなく、システム崩壊のリスクがある
セキュリティ制御と認証管理が不完全
権限制御が不便
パブリックネットワークIPアドレスのコストが高い
ブロックチェーンノードが不安定：単一ノードが攻撃を受けやすい
複数のプロトコルの統一管理が欠如

HyperchainはKongやNGINXを試しましたが、残念ながらHyperchainのビジネスシナリオを満たすことができませんでした。しかし、Apache APISIXを採用した後、上記の問題はすべて解決され、Hyperchainブロックチェーンプラットフォームに無限の活力を与えました。

Hyperchainブロックチェーンプラットフォームについて

Hyperchainブロックチェーンプラットフォームは、ブロックチェーンフレームワークをクラウドコンピューティングプラットフォームに組み込み、クラウドサービスのインフラストラクチャの展開と管理の利点を活用することを指します。これは、開発者に便利で高性能なブロックチェーンエコシステムと関連サポートサービスを提供し、web3でのビジネス拡張と運用をサポートするオープンなブロックチェーンプラットフォームです。

Hyperchainブロックチェーンプラットフォームは、ブロックチェーンネットワークを迅速かつ柔軟に構築できます。このプラットフォームを使用することで、企業はブロックチェーン業務を一元的に管理できます。例えば、プラットフォームを通じて統合開発環境で契約を締結し、その後作成したブロックチェーンネットワークに契約をデプロイできます。上位サービスモジュールはブロックチェーン関連の契約を呼び出してビジネスプロセスを継続できます。

チェーン内には多くのノードがあり、数十から数千に及ぶため、プラットフォームのサポートなしではチェーンの運用を監視および維持することが困難です。Hyperchainブロックチェーンプラットフォームを使用することで、ユーザーはコストを節約するだけでなく、ブロックチェーンをより便利に管理し、システム全体のセキュリティを強化できます。

Hyperchainを例に、なぜブロックチェーン企業が多くのAPIゲートウェイの中からApache APISIXを選択すべきかを説明します。以下では、APISIXのHyperchainブロックチェーンプラットフォームとブロックチェーンノードでの応用を分析します。

HyperchainブロックチェーンプラットフォームでのAPISIXの応用

以下は、HyperchainブロックチェーンプラットフォームでのAPISIXの応用インタラクションダイアグラムです。バックエンドサービスは、そのビジネス特性に応じてetcdにサービス情報を登録し、その後ルート登録モジュールを通じてAPISIXにサービスを登録します。

APISIXはシステム内の内部マイクロサービスの統一エントリとして機能します。外部リクエストはまずAPISIXに送信され、認証を通過した後、APIを介してアクセス層にアクセスし、その後RPC（リモートプロシージャコール）を介してコアサービスにアクセスします。

Hyperchain応用インタラクションダイアグラム

ルート転送

時には、APIを同じドメイン名の下に公開することが期待されます。この場合、同じサービスのAPIパスにいくつかのプレフィックスを追加できます。例えば、/baas-coreや/baas-otherなどです。クライアントがこれらのAPIをリクエストする場合、APIゲートウェイは追加されたプレフィックスを取り除き、リクエストをバックエンドサービスに転送する必要があります。APISIXのproxy-rewriteプラグインは、このようなケースを便利に処理するのに役立ちます。

例えば：訪問時：http://apisix:8080/baas-{service}/api/v1/… リクエストはhttp://{service}/api/v1/…に転送されます正規表現を記述することで：^/baas-core/(.*)$,/$1

proxy-rewriteプラグイン編集

トラフィック制限管理

ユーザーはHyperchainだけでなく、IBMデータファブリック、Baidu XuperChainなど、ニーズに応じてコンソーシアムブロックチェーンを選択できます。したがって、Hyperchainはシステム内のすべてのコンソーシアムブロックチェーンのライフサイクル管理を行う必要があります。

コンソーシアムチェーンを作成する際、Hyperchainはブロックチェーンプラットフォームにハードコードを記述し、プラガブルドライブコンポーネントをブロックチェーンプラットフォームにアップロードして呼び出し、コンソーシアムチェーンを作成します。一部のプライベートデプロイメントケースでは、プラガブルドライブコンポーネントが迅速にサポートできます。

ドライブコンポーネントへの呼び出しは制限が必要なプロセスであり、特に数が多い場合に重要です。したがって、APISIXのlimit-reqプラグインは、プラットフォームのトラフィック入出力を制限し、安定性を確保するのに役立ちます。

limit-reqプラグインでは、レートとバーストに関するカスタマイズ設定が可能です。

limit-reqプラグインモデル

セキュリティ制御と権限管理

APISIXと連携するため、Hyperchainはプライベートデプロイメント環境向けのプラグインを開発しました。パーティAはしばしば独自の認証サービスやサービスアカウントシステムを使用することを好みます。フロントエンドトラフィックがウェブサイトにアクセスする際、まずAccess-authプラグインを通過し、認証を通過した場合にのみバックエンドBFF（Backend for Frontend）にアクセスできます。

認証プロセスダイアグラム

Restful標準仕様の3つの主要要素（認証情報、Restfulパス、およびGET、POST、PUT、DELETE、PATCHなどのHTTP動詞）に基づいて、アカウント-ロール-権限認証が行われます。認証が通過した場合、ユーザー情報がヘッダーに返されます。認証が失敗した場合、403が返されます。

API認証パス

ホットリローディング

APISIXは、内部で開発されたプラグインのホットリローディングを提供します。これにより、開発中に時間を節約し、プラグインランナー全体を再起動することなくコードの一部を変更できます。この方法で、開発者はバックエンドでインターフェースを調整し、即座に反映させることができ、オンラインリリースに便利でフレンドリーです。

なぜKongではないのか？

Hyperchainは以前Kongを使用していましたが、最終的にApache APISIXに置き換えました。主な理由は以下の通りです：

高いデプロイメントとメンテナンスコスト

KongクラスターはPostgresqlデータベースと連携する必要があり、高可用性のために特定のデータベース管理者が必要です。Postgresqlデータベースのクラスター展開は比較的難しく、後続の運用とメンテナンスのコストを増加させます。
システムの複雑さと故障率の増加

HyperchainブロックチェーンプラットフォームはMySQLデータベースを使用しており、Kongを採用するとシステム内に2つのリレーショナルデータベースが存在することになり、システムがより複雑になります。また、2つのデータベース間の互換性を向上させる際に故障率が増加します。

ブロックチェーンノードでのAPISIXの応用

Hyperchainブロックチェーンダイアグラム

パブリックネットワークIPアドレスのコスト削減

ユーザーはHyperchainブロックチェーンプラットフォームを通じてブロックチェーンを購入します。その後、上位ビジネスと開発者クライアントはノードに接続できます。サービスは1つ以上のノードに接続し、ユーザーは1つ以上のノードにアクセスする可能性があり、これにより問題が発生します：ほとんどすべてのノードが訪問され、単一ノードの訪問負荷が高くなります。

一部のプライベートデプロイメント環境では比較的簡単に処理できます。しかし、インターネットユーザーを対象としたシステムでは、多くのノードとパブリックネットワークIPが必要です。4メガバイトのトラフィックを持つ各パブリックネットワークIPの価格は、月額約200元に達する可能性があります。Hyperchainプラットフォームには数千のノードがあり、高いパブリックIPコストがかかります。

APISIXはすべての訪問リクエストを管理し、対応するブロックチェーンノードにトラフィックを分散します。これにより、Hyperchainは高いコストを節約しました。

APISIXを使用したHyperchainのモード

便利な権限制御

Hyperchainブロックチェーンプラットフォームにはさまざまなブロックチェーンがあり、各チェーンには複雑なRBAC権限制御があります。したがって、クライアント側にTLS証明書など、さまざまな種類の証明書を追加する必要があり、ユーザーを困惑させます。

現在、APISIXのkey-authプラグインを使用してこの問題を効率的に解決できます。認証されたユーザーは、権限設定を気にすることなく直接ブロックチェーンにアクセスできます。APISIXは基盤となるチェーンを統一します。

クラスタリングによるノードの安定性向上

前述のように、ノードは頻繁に訪問されます。銀行ユーザーの多くは高並列性があり、TPS（1秒あたりのトランザクション数）は40,000-50,000回に達する可能性があります。

ブロックチェーンの単一ノードは脆弱であることが判明しています。各トランザクションは訪問されたノードに影響を与えます。

HyperchainはKubernetes上にApache APISIXをデプロイし、Horizontal Pod Autoscalerを使用しています。APISIXは動的な拡張性が優れたetcdを使用しているため、単一ポイントのトラフィック影響の問題を効果的に解決できます。

複数のプロトコルのサポート

Hyperchainブロックチェーンプラットフォーム上の異種チェーンのプロトコルは多様です。例えば、HTTPプロトコル、Websocketプロトコル、gRPCプロトコル、TCPプロトコル、UDPプロトコルなどです。

APISIXは複数のプロトコルをサポートし、異なるブロックチェーンの基盤層に柔軟に適応し、開発コストを削減します。

なぜNGINXではないのか？

HyperchainはNGINXを使用して問題を解決できるように思えます。しかし、試用後、HyperchainはNGINXを放棄しました。その理由は以下の通りです：

動的拡張に不向き

Hyperchainはブロックチェーンプラットフォームで頻繁にノードを追加および削除する必要があり、再起動後にのみ有効になります。これは開発者にとって不便です。さらに、開発者はNGINXのconfファイルに複雑なルールコードを記述する必要があります。
クラスタリングが困難

NGINXはクラスタリングをサポートしておらず、ユーザーにとって比較的複雑でフレンドリーではありません。
TCPおよびUDPの直接サポートがない

NGINXは7層プロトコルのみをプロキシでき、4層プロトコルを直接サポートできません。さらに、モジュールはデフォルトでコンパイルされておらず、追加の処理が必要です。
ダッシュボードがない

NGINXには視覚化されたインターフェースがなく、多くのノードを管理するのが開発者とオペレーターにとって困難です。

まとめ

上記の内容から、Apache APISIXがブロックチェーン領域で応用できる動的APIゲートウェイであることがわかります。さらに、Apache APISIXはロードバランシング、動的アップストリーム、カナリアリリース、サーキットブレーカー、認証、可観測性などの豊富なトラフィック管理機能を提供します。

APISIXがより多くのブロックチェーン企業を次の開発段階に進めることを願っています。 Apache APISIXについてもっと学びたい方は、https://api7.ai/contact でお問い合わせください。