すべてのシステム アーキテクチャには独自の歴史的背景があり、私は通常、需要主導とテクノロジー サポートという 2 つの側面から分析します。

WPAIの立ち上げ以前は、ビジネスの急速な発展を支援し、AIアプリケーションの迅速な実装を実現するために、グループ内の各事業部門はそれぞれ独自の戦力で推論関連機能を自主開発するしかありませんでした。しかし、プラットフォームベースの管理・監視機能が不足していたため、研究開発および運用保守の効率が低いという問題が必然的に発生していました。さらに、アルゴリズムとエンジニアリングの境界が明確でなかったため、アルゴリズムエンジニアはエンジニアリングの問題に深く入り込み、限られたエネルギーをモデルの最適化に集中させることができず、モデルの反復効率も不十分でした。そのため、グループはAIプラットフォームの機能を切実に必要としていました。

技術サポートの観点から見ると、Kubernetes クラスターの内部ネットワークと外部ネットワークは相互接続されていないため、クラスターエッジにゲートウェイを設置して推論プロセス全体を接続する必要があります。当時、グループが独自に開発した Java ベースの RPC フレームワークである SCF は、成熟したサービスガバナンス機能（タイムアウト、レート制限、監視、アラームなど）、強力な水平スケーリング機能、そして複数のバージョンの反復とグループの複数の事業部門による本番環境でのテストを経て得られた高可用性保証を備えていました。さらに、ビジネスユーザーにとって学習コストと使用コストは基本的にゼロでした。そのため、ビジネスユーザーの迅速なアクセスニーズを満たすために、バージョン 1.0 の推論アーキテクチャを構築するためのゲートウェイとして SCF を選択しました。

図3 SCFアーキテクチャ全体

3.2 推論アーキテクチャ 1.0 の設計と実装

推論アーキテクチャ 1.0 の SCF ゲートウェイは、従来型の API ゲートウェイ実装です。以下では、現在広く普及しているデータプレーンとコントロールプレーンの概念を用いて説明します。

コントロール プレーンは主に 3 つのモジュールで構成されます。

1. K8Sクラスターに接続し、K8S List/Watchメカニズムを介してサービスの登録と検出を実装します。また、エンドポイントに基づいて、モデル指向のきめ細かなgRPC接続プールを構築します。

2. AI管理プラットフォームに接続し、WConfig（58の自社開発構成センター）を使用して、タイムアウト時間やレート制限しきい値などのモデル実行時パラメータのリアルタイム同期を実現します。

3. WOS（58が自社開発したオブジェクトストレージサービス）をベースに、プロトコル変換JARプラグインセンターを構築しました。SCFゲートウェイはgRPCリクエストを透過的に転送できないため、ゲートウェイ内部で各SCFリクエストをgRPCリクエストに変換してからバックエンドのモデルサービスに転送する必要があります。返されるデータも同様です。これを実現するために、プラットフォームは標準のプロトコル変換インターフェースを提供しています。アルゴリズム開発者は、モデルが稼働する前に、プラットフォームのインターフェースに基づいてモデル固有のリクエストと返されるデータの変換ロジックを実装し、JARファイルにパッケージ化して、プラットフォーム管理インターフェースからプラグインセンターにアップロードする必要があります。

データ プレーンでは、認証、第 2 レベルのレート制限、プロトコル変換 JAR パッケージのホット ローディング (モデルが最初の推論要求を受け取ったときにカスタム クラス ローダーを介して JAR パッケージをロードする)、要求/応答プロトコル変換、加重負荷分散、トラフィック転送、ログ記録と例外処理などのサービス ガバナンス関連の機能を中心に要求処理パイプラインが構築されています。

図4. 推論アーキテクチャ1.0の実装

3.3 推論アーキテクチャ1.0の欠点

推論アーキテクチャ1.0の導入により、グループ内のオンライン推論プラットフォーム機能の不足が効果的に解消され、アルゴリズムエンジニアとエンジニアリングエンジニアの責任が分離され、アルゴリズム反復とエンジニアリング開発の効率が向上しました。しかし、ユーザー数の増加とビジネスステークホルダーからのモデル反復への需要の高まりに伴い、1.0アーキテクチャには徐々にいくつかの欠点が露呈してきました。

ビジネス アクセスの観点から: プロトコル解析 JAR パッケージの作成とアップロードにより、アクセス プロセスが若干複雑になり、アルゴリズム担当者のモデル デバッグ コストが増加し、アクセス方法が制限され、HTTP アクセスがサポートされません。

サービスパフォーマンスの観点から見ると、SCFプロトコルとgRPCプロトコル間の変換によって推論時間が長くなるという問題があります。一方、SCFネットワーク通信層はNettyをベースとしており、Nettyは各SocketChannelにデータ読み取り用のバッファ（ByteBuffer）を割り当てます。バッファサイズはサービスパフォーマンスに直接影響します（割り当てサイズが大きすぎるとGC負荷が増大し、小さすぎるとリサイズが発生し、メモリコピー操作が発生します）。Netty実装では、この問題を解決するために「予測可能な」バッファ割り当てメカニズムが提供されています（コア実装についてはio.netty.channel.AdaptiveRecvByteBufAllocatorクラスを参照してください）。しかし、このメカニズムは大規模なリクエストにはあまり適していません。例えば、画像強調推論のシナリオでは、入力画像サイズが1MBを超えると、バッファは16MBに拡張されます。そのため、SCFクライアント接続数は、サーバーのJVM旧世代メモリ使用量を直接決定します。アクセス規模が大きくなると、GCの問題によって推論パフォーマンスが変動します。

開発と運用の観点から：ゲートウェイの実装はサードパーティ製ライブラリと密接に連携しています。新機能の統合やサードパーティ製ライブラリのアップグレードには、ゲートウェイ全体のアップグレードが必要となり、コストがかかります（Log4j についてはここで言及する必要があります）。

1.0推論アーキテクチャの従来のゲートウェイ実装で明らかになった問題に対処するため、私たちは推論アーキテクチャをアップグレードし、クラウドネイティブゲートウェイであるIstioを採用することにしました。Istioの定義は広範であり、Istioを素早く理解する最良の方法は、まずその開発のタイムラインから始めることです。

2012年から2013年にかけてモバイルインターネットが登場し始め、企業はサービスの反復効率に対する要求を高めました。アプリケーションアーキテクチャはモノリシックからマイクロサービスへと移行し始め、サービスの規模も当初より拡大し始めました。

Docker は 2013 年にオープンソース化され、アプリケーションのカプセル化、分離、移植性に関連する問題を解決する、より軽量な仮想化ソリューションを提供します。

2014年、GoogleはKubernetesのオープンソース化を発表し、コンテナオーケストレーションとライフサイクル管理の標準ソリューションを提供しました。クラスタは急速に大規模かつ分散型のアーキテクチャへと進化し、サービス数と複雑なトポロジの急増につながりました。

2016年、BuoyantのCEOであるWilliam Morgan氏は、サービスメッシュを初めて定義しました。サービスメッシュとは、サービス間通信を処理するために使用されるインフラストラクチャ層です。クラウドネイティブアプリケーションは複雑なサービストポロジを持ち、サービスメッシュはリクエストがこれらのトポロジを確実に通過することを保証します。実際のアプリケーションでは、サービスメッシュは通常、アプリケーションと並行してデプロイされながらもアプリケーションに対して透過的な一連の軽量ネットワークプロキシで構成されます。第一世代のサービスメッシュ製品であるLinkerdは、同年にリリースされました。

Envoyプロキシは2016年にオープンソース化され、Lyftのエッジプロキシとして本番環境で検証されています。プログラマブルプロキシ時代のマイルストーンとなる製品として、定義されたxDS（x Discovery Service）プロトコルはクラウドネイティブなシナリオにおいて大きな成果を上げています。

2017年、Google、IBM、Lyftは共同でIstioのオープンソース化を発表し、データプレーンとコントロールプレーンの構成、そしてサイドカーパターンを定義しました。これは第二世代のサービスメッシュ製品として高く評価され、サービスメッシュのコンセプトは広く受け入れられました。

2018 年、Cloud Native Computing Foundation (CNCF) は、コンテナ、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API など、クラウド ネイティブの代表的なテクノロジを再定義しました。

図5 Istioの誕生のタイムライン

要約すると、IstioはKubernetesと緊密に統合され、クラウドネイティブなシナリオに適しており、サービスメッシュアーキテクチャをベースとした、サービスガバナンスのためのオープンプラットフォームです。トラフィック管理、セキュリティ、可観測性という3つのコア機能を提供します。

Istioはサービスメッシュ機能で有名になりましたが、単なるサービスメッシュ製品ではありません。Linkerdと比較すると、IstioはKubernetes Ingress（プログラマブルプロキシEnvoyベース）がクラスター内のNorth-Southトラフィックを処理するためのデフォルトソリューションを提供します。さらに、Kongなどの他のIngressプロバイダーと比較して、Istioには以下の利点があります。

素晴らしい遺伝子ですね。EnvoyはLyftのエッジプロキシとして本番環境で検証され、その後CNCFの3番目のプロジェクトとして卒業しました。CNCFはService Meshをクラウドネイティブ定義の第2版に正式に含めました。また、Istioも最近CNCFのインキュベーションプロジェクトになりました。コントロールプレーンとデータプレーンの分離アーキテクチャとxDS動的構成同期ソリューションを組み合わせたものです。

包括的な機能。C++で実装された完全非同期イベントメカニズムによる堅牢なプロキシパフォーマンス、リクエストルーティング、ロードバランシング、タイムアウト、レート制限、サーキットブレーキングなどの豊富なトラフィック管理機能（いずれもすぐに使用可能）、詳細な監視メトリクスと完全なアクセスログによる強力な可観測性サポート、そしてフィルター、Lua、WASMに基づく機能拡張を可能にする柔軟な拡張性などが含まれます。

勢いは衰えていません。2020年のCNCF China Cloud Native Surveyによると、昨年4位だったEnvoyは、この1年間で利用率が飛躍的に増加し、シェアは15%から29%へと拡大し、F5とHAProxyを抜いて2位に躍り出ました。Istio/Envoyは、Google、Microsoft、Alibaba、Tencentといった国内外の有力企業に広く導入されており、サービスメッシュ/データプレーンプロキシのデファクトスタンダードとなっています。

上記のすべてを考慮して、最終的に、クラウド ネイティブ ゲートウェイ Istio に基づいてバージョン 2.0 推論アーキテクチャを構築することを選択しました。

4.2 推論アーキテクチャ2.0の実装

推論アーキテクチャ 2.0 の実装は図 6 に示されており、モデル サービス層、ゲートウェイ層、およびビジネス アプリケーション層に分けることができます。

図6. 推論アーキテクチャ2.0

モデルサービス層は、1.0推論アーキテクチャと比べて変更されていません。Istioのサイドカーソリューションは、以下の理由により有効化しませんでした。

1. オンライン推論は、東西トラフィックを必要としない典型的なエンドツーエンドのシナリオです。

2. Istio の Sidecar ソリューションは、リクエスト転送を実装するために iptables に基づいており、これによりパフォーマンスが低下し、推論パフォーマンスに影響します。

3. サイドカー コンテナの数が多いと、クラスター リソースに大きな負担がかかり、運用と保守管理の複雑さも増します。

アーキテクチャ設計において、複雑さは諸悪の根源です。IstioのSidecarソリューションはすぐに使える状態で提供されていますが、必要に応じて活用する必要があります。

ゲートウェイ層はIstioのネイティブアーキテクチャです。Istioは、コントロールプレーンのIssueとデータプレーンのIngress Gatewayを、独立してデプロイされる2つのプロセスに分離することで、リソースの分離と相互干渉を防ぎます。コントロールプレーンのIssueは、3つの主要モジュールで構成されています。Citadelは、組み込みのIDおよび認証情報管理を通じて堅牢なサービス間およびエンドユーザー認証を提供し、メッシュにおける認可とゼロトラストセキュリティを実現します。Galleyは、Istioの構成検証、抽出、処理、配信コンポーネントです。Pilotは、データプレーンプロキシのサービス検出、トラフィック管理、および耐障害性を提供​​します。データプレーンのIngress Gatewayは、EnvoyとPilot-agentで構成されています。Envoyはトラフィックプロキシ機能を実行し、Pilot-agentはEnvoyの静的構成ファイルの生成とEnvoyのライフサイクル管理を担当します。Pilot-agentはEnvoyの「サイドカー」として機能します。一般的に、ゲートウェイ層のコントロールプレーンは、クラスタ内のノードの動作状態の変化を下位レベルで検知し、標準インターフェースを介してアプリケーション層からゲートウェイの動作設定の変更を受け取り、すべての情報を統合し、xDSプロトコルを介してデータプレーンにリアルタイムでプッシュします。データプレーンは、この情報を使用して、負荷分散、レート制限、サーキットブレーキング戦略の実装など、ユーザートラフィックの管理方法を決定します。両層はそれぞれ独自の機能を実行することで、真の高凝集性と低結合性を実現します。

ビジネスアプリケーション層は、データプレーンとコントロールプレーンにさらに分けられます。データプレーンでは、ユーザーアクセスとその後のトラフィック管理を容易にするために、部分粒度でのマルチテナント分離を実装し、ドメイン名 + 58DNS + CLB の組み合わせによりゲートウェイの負荷分散と高可用性を実現しました。コントロールプレーンでは、K8S + Istio リソースに対するビジネスオペレーションの統一されたエントリポイントとして K8S マネージャーサービスをカプセル化し、クエリと変更の動作を標準化しました。K8S マネージャーサービスは、Web ページ上のモデル推論タイムアウト設定の変更など、さまざまなビジネスシナリオ呼び出しに上位接続します。

4.3 推論アーキテクチャのアップグレードによるアプリケーション効果

このアーキテクチャのアップグレードにより、推論プラットフォームのパフォーマンス、安定性、使いやすさが全面的に向上しました。 推論時間は1.0アーキテクチャと比較して50%以上短縮され、 デプロイメントレベルでのデータプレーンとコントロールプレーン間のリソース分離によりサービスの安定性が向上しました。また、 Istio が提供する豊富なトラフィック管理機能により、 その後の開発および保守作業が大幅に簡素化されました。    

5.1 Istio トラフィック ガバナンスの基礎 - 宣言型 API

宣言型APIは、Kubernetesが提供するCRDの拡張です。Istioでは、PilotモジュールがList/Watchメカニズムを用いてすべてのCRDリソースの変更を監視し、最新の構成をデータプレーンブローカーに同期します。Istioは内部的に数百のCRDを定義しており、ここでは最もよく使用される4つのCRDについて簡単に紹介します。

ゲートウェイ: 公開されたポートやプロトコルなど、レイヤー L4 ～ L6 における抽象ゲートウェイの負荷分散属性。

VirtualService: L7トラフィックルーティングルールを設定します。トラフィックポート、ヘッダーフィールド、URIなどに一致条件を設定し、トラフィックを適切な宛先にルーティングできます。また、ルーティングルールを使用して、ヘッダーの追加や削除、URLの書き換え、リクエストの再試行ポリシーの設定など、トラフィックに対して特定の操作を実行することもできます。

DestinationRule: ターゲット サービスまたはそのサブセットと、負荷分散戦略、サーキット ブレーカー設定など、通話がターゲット サービスまたはそのサブセットに転送される場合のトラフィック戦略を定義します。

EnvoyFilter: サービス メトリックの統計やレート制限などの Envoy リクエスト処理ロジックをカスタマイズできる Istio プラグイン メカニズム。

図7の例では、3つのCRD（Gateway、VirtualService、DestinationRule）が名前またはラベルによって関連付けられています。これは、ヘッダーにtaskd=666を含む*search.wpai.58dns.org:8866を要求するすべてのトラフィックが、Kubernetesのservice-666というサービスに含まれるワークロードにラウンドロビンでルーティングされることを意味します。

図7 宣言型APIアーキテクチャ

5.2 ゲートウェイマルチテナント実装 - ゲートウェイ分割

Istioでは、複数のゲートウェイをデプロイできます。1つのゲートウェイを共有することも、テナントおよび名前空間ごとに個別にデプロイすることもできます。ゲートウェイ障害の影響範囲を縮小し、推論品質とゲートウェイリソースの利用率の両方を確保するため、ビジネスラインの特性とトラフィック特性を総合的に考慮し、ゲートウェイクラスターと名前空間を1:1および1:Nの関係で分割しました。図7はゲートウェイ分割の簡略化された例です。テスト用名前空間と検索用名前空間はそれぞれ専用のゲートウェイクラスターを持ち、残りの名前空間は別のゲートウェイクラスターを共有しています。

図8. ゲートウェイ分割図

5.3 適応型レート制限の実装

Istioは、ゲートウェイ側でデフォルトでグローバルレート制限とローカルレート制限の2つのレート制限スキームを提供します。グローバルレート制限では外部レート制限サービスへのアクセスが必要であり、高同時実行テストケースではパフォーマンスが不十分であったため、ローカルレート制限スキームを選択しました。ローカルレート制限は、Envoyが内部的に提供するトークンバケットアルゴリズムに基づいて実装され、設定インターフェースはEnvoyFilterを通じて外部に提供されます。レート制限設定の最小粒度はルートであり、これはKubernetesのサービスの概念に対応しており、私たちの推論シナリオではタスクです。ただし、エラスティックスケーリングメカニズムでは、タスクレプリカの数はトラフィックとタスク自身の負荷に応じて変化します。タスクが処理できる合計QPSは、レプリカの数と単一のレプリカのQPSを乗算することで計算されます。したがって、正確なレート制限を実現するために、次の2つのステップを含む適応型レート制限機能を実装しました。

1. プラットフォームの観測可能なシステム（主にタスクのレプリカの数を参照）に基づいて、タスク プロファイルの変更を監視します。

2. レプリカ変更イベントのジッタが除去された後、タスクの合計 QPS に変換され、その後、K8S マネージャー サービスを要求して、EnvoyFilter 内のタスクのレート制限構成が変更されます。

図9 適応型電流制限方式

5.4 ロスレス展開の実装 - モデルのウォームアップ

オンライン推論シナリオでは、新しいノードは最初の推論リクエストを受信した時点でのみ、モデルファイルをメモリ/GPUメモリにロードします。このプロセスは時間がかかり、トラフィックが多い場合は、リクエストのブロック、レスポンスのタイムアウト、さらにはリソース枯渇につながり、最終的にはシステムクラッシュにつながる可能性があります。シームレスなノードデプロイメントを実現するために、タスクノードサービスがリリースされる前にトラフィックを事前加熱することで、モデルのロードプロセスを事前にトリガーできるモデル事前加熱機能を提供しています。

図10 モデル予熱実施スキーム

まず、 モデルによってウォームアップ時間の要件が異なることを考慮し、 Kubernetesが提供するStartupプローブとReadinessプローブを導入しました。Readinessプローブは、コンテナサービスのデプロイ（プローブ成功）とデコミッション（プローブ失敗）のタイミングを決定し、Startupプローブはコンテナサービスが正常に起動したかどうかを検知します。Readinessプローブは、Startupプローブがサービスを正常に検出した後にのみ起動します。2 つのプローブは同じ設定可能な属性を持ちます。ここでは主に「initialDelaySeconds」属性を利用します。Startupプローブでは、コンテナが起動してからどのくらいの時間が経過したらプローブがサービスの検出を開始するかを示します。Readinessプローブでは、Startupプローブがサービスを正常に検出してからどのくらいの時間が経過したらプローブがサービスの検出を開始するかを示します。したがって、Readinessプローブの「initialDelaySeconds」属性をウォームアップ時間に設定することで、サービスの起動とデプロイの間隔を正確に制御できます。企業は、十分なウォームアップを確保するために、必要に応じてウォームアップ時間を設定することができます。

さらに、モデルごとに入出力フォーマットの要件が異なります。これに対処するため、オンラインモデルと推論リクエストを整理し、モデル設定ファイル群を抽象化しました。戦略パターンに基づき、これらの設定ファイルを用いたモデル固有のウォームアップクライアントを作成しました。アルゴリズムエンジニアは、必要な設定ファイルをアップロードし、サービス開始後にサービス内でウォームアップリクエストを送信するだけで、モデルのロードロジックを事前にトリガーできます。

図11 モデルの予熱構成

メトリックは、さまざまな次元にわたって一定期間にわたって記録された定量的な情報であり、システムの特定の状態と傾向を観察するために使用されます。

ログは、プログラム実行中の対象イベントのタイムスタンプ付きの構造化または非構造化レコードです。

トレース: リクエストのライフサイクル全体を通じて、リクエストの開始から終了までの呼び出しチェーンの記録 (主にマイクロサービス シナリオで使用されます)。

図12 可観測性アーキテクチャ

可観測性はIstioのコア機能の一つであり、豊富な内部エコシステムサポートを提供しています。しかし、ゲートウェイにとって最も重要なサービスメトリクス（レイテンシ、トラフィック、異常など）はIstioによる生成を必要とするため、Istioのメトリクス生成・収集ソリューションは使用しませんでした。その代わりに、図13に示すように、Istioのアクセスログに基づいて独自の可観測性構築ソリューションを構築しました。

図13 2.0アーキテクチャにおける観測可能な構築スキーム

ゲートウェイの構造化（JSON）アクセスログと推論サービスの非構造化ログはディスクから収集され、対応するKafkaに送信されます。その後、ELKコンポーネントを使用して転送、保存、可視化が実現されます。図14は、ゲートウェイアクセスログの可視化例を示しています。

監視メトリクスには、サービス（トラフィック）監視メトリクスとリソース監視メトリクスがあります。サービス監視メトリクスは、Kafkaのゲートウェイ構造化ログをデータソースとして、ストリーミングコンピューティングエンジンFlinkで計算され、豊富なディメンション（基本メトリクス+二次処理メトリクス）、多様なレベル（部門レベル、タスクレベル、レプリカレベルなど）、柔軟なスパン（分レベル、秒レベル）を持つサービス監視メトリクスを取得し、ElasticsearchとKafkaに同時にシンクします。リソース監視メトリクスはcAdvisorによって収集・計算され、Prometheusが転送と保存を担当します。リアルタイムタスクプロファイルを構築するために、Prometheus-Kafka-Adapterを使用して、すべてのリソース監視メトリクスをKafkaにリアルタイムで同期します。

監視メトリックは Grafana ダッシュボードを通じてクエリされ、視覚化され、監視アラート、サービス ガバナンス、および柔軟なスケーリングのためのデータ サポートを提供します。

図14. ゲートウェイアクセスログの可視化

図15. 推論サービスの監視メトリクスの表示

参考文献:

[1] パターン：サービスメッシュ（https://philcalcado.com/2017/08/03/pattern_service_mesh.html）

[2] Istio公式ドキュメント（https://istio.io/latest/docs）

[3] Istio OSSを超えて - Istioサービスメッシュの現状と将来（https://jimmysong.io/blog/beyond-istio-oss）

[4] サービスメッシュの比較：Istio vs Linkerd（https://dzone.com/articles/service-mesh-comparison-istio-vs-linkerd）

[5] 2020年CNCF中国云原生调查（https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020）

[6] Hango-云原生网关实践，为何选择Envoy（https://hango-io.github.io/Hango-why-envoy）

[7] 云原生网关的可观测性体系实（https://mp.weixin.qq.com/s/Hb7vZWhO4ul4L4of6IDCrw）

著者について:

魏竹斌，58同城TEG AI Lab AI平台部后端资深工程师。2020年7月加入58同城，目前主要负责深度学习推理平台和vSearch向量检索平台相关建设工作。