Zhao Qingjie (Alibaba Cloud Function Computing)、Lin Xueqing (Alibaba Cloud Function Computing)、Du Lingling (Gao De)、Wang Bicheng (Gao De)
序文
2023 年の春節、感染症の流行から 3 年が経ち、ようやく春の夜明けを迎えました。中国人の旅行に対する熱意は前例のないほど高く、両親に会いに実家に帰り、ずっと考えていた旅行がついに実現します。オートナビの推計によると、2023年の春節期間中のピーク交通量は、2022年の同時期や2022年11月と比べてかなりの割合で増加するという。ただし、つい最近まで、疫病の影響により、システムのトラフィックは依然として比較的低いレベルで実行されていました。
春節旅行の準備を短期間で迅速に完了し、春節期間中のピーク交通下でシステムのスムーズな動作を確保し、公共旅行に必要なナビゲーションやその他の情報サービスへのアクセスをスムーズにする方法、技術者にとって緊急の課題となっています。トラフィックが大幅に変化した場合に、コストを削減し効率を高めながら、システムのスムーズな運用を確保するにはどうすればよいでしょうか?
ここ数年、AutoNavi はサーバーレス アプリケーションを強力かつ継続的に推進してきました。綿密な調査と選択の結果、最終的に、Alibaba Cloud Function Computing (Aliyun FC) がそのアプリケーションのサーバーレス コンピューティング プラットフォームとして選択されました。この 1 年間で、大きな進歩が見られました。
AutoNavi のサーバーレスに関する先見性は、春節旅行中の不確実性と強力な回復に、より機敏かつ経済的な方法で対処するのに役立ちます。トラフィックの変化によってもたらされるリソースの変更を心配する必要はなく、事前に大量のコンピューティング リソースを準備する必要もありません。ピークトラフィックに応じて、リソースが十分であるかどうかを心配する必要はなくなり、経済コストが大幅に低下し、研究開発と運用保守の効率が大幅に向上しました。
前回のサーバーレスの結果に基づいて、AutoNavi の関連事業は春節旅行の準備を迅速に完了し、春節保証は正常に完了しました。
典型的なケースを見てみましょう。昨年、FC が AutoNavi の RTA 広告システムのアーキテクチャのアップグレードをどのように支援したかを見てみましょう。
ビジネスの背景
RTAとは
RTAは、メディアと広告主双方のデータやモデル能力を活用し、リアルタイムの広告最適化を実現するリアルタイム広告プログラムインターフェース技術であり、戦略指向の配信機能でもあります。
広告媒体はAutoNaviのRTAインターフェースを通じて広告掲載の可否を問い合わせ、RTAサービスはAutoNavi独自の群集情報を問い合わせることで掲載結果を返します。これにより、メディアはより正確に広告を掲載できるようになります。
元のシステムのアーキテクチャと問題点
元々のシステムサーバが占有量が多く、依存リンクも長く、容量を拡張するたびに依存サービスもそれに合わせて拡張する必要があり、リソースを多く占有してしまう。
テクノロジーの選択
クラウドヒット機能
クラウド ヒット関数の本質は、要素がコレクション内にあるかどうかを取得する問題に起因すると考えられます。
この種の問題は、業界ではブルーム フィルターによって解決されることがよくあります。ブルーム フィルターの本質は、一連のハッシュ アルゴリズムとビットマップの組み合わせです。利点は、クエリ効率が高く、フットプリントが小さいことです。Redisの拡張版ではbf（ブルームフィルター）機能が提供されています。読み取りは golang で行われ、書き込みは Java で記述されるため、言語間で引き起こされるライブラリの不一致や、ブルーム フィルターの実装の違いによって引き起こされる可能性のあるヒットの不一致を回避するために、BF の Redis 拡張バージョン (ブルーム フィルター) を使用できます。 ) 関数を使用する場合は、Redis サーバーに bf 関数を実装して、さまざまな言語での呼び出しのデータの一貫性を確保します。
Redisを利用してクラウドヒット機能を実現することで、アルゴリズムゲートウェイを削除でき、データセンター側の多くのリソースも節約できます。
データの同期
現在、CircleRen プラットフォームには、オンライン、リアルタイム、オフライン 1 回、オフライン サイクルの 4 種類のデータ更新があります。
現在のサークル戦略はオフラインの集客をベースにしています。将来的にはオンラインかつリアルタイムの活用も考えられますが、一般的にRTA広告で描かれる群衆は大きく、リアルタイムでの群衆変化の割合は低く、またメディアにはキャッシュがあるため、リアルタイム性の要件は高くなります。リアルタイムのオンライン群衆とオフラインを使用する群衆の効果に大きな違いはないため、現時点では、サークルの主な手段としてオフラインの群衆のみを使用することをお勧めします。リアルタイム パフォーマンスに対する高い要件がある場合は、時間ディメンションでオフライン サイクルを更新することを検討できます (基本的に、リアルタイム パフォーマンスは UDF 更新頻度とトリガー方法に依存します)。Redis をオフラインで定期的に更新する方法を総合的に検討します。
サーバーレス
なぜサーバーレスなのか
サーバーレスでは、アプリケーションとプラットフォームのインターフェイスを再分割することで、企業が独自のビジネス ロジックに集中できるようになり、誰もが安定性、安全性、弾力性に優れたスケーラブルな分散アプリケーションを迅速に開発できるようになります。
サーバーレスを実現する方法
新しいテクノロジーの選択では、エンジン サービスは Redis にアクセスする必要があります。これは、高頻度のストレージ アクセスを伴うシステムをどのようにサーバーレス化するかという問題です。
一般に、サーバーレスは FaaS+BaaS であると考えられています。FaaS: Function as a Service、サービスとしての機能、一般にさまざまなバックエンド マイクロサービス。BaaS: Backend as a Service とは、ストレージ サービスなど、FaaS には適さないバックエンド サービスを指します。
サーバーレス システム アーキテクチャでは、クラウド ストレージに高い要求が課せられており、スケーラビリティ、レイテンシ、IOPS の点で、クラウド ストレージはアプリケーションと同等またはそれに近い自動拡張および縮小機能を実現できる必要があります。
Alibaba Cloud は、Redis Enterprise Edition サービスを提供しており、クラスター アーキテクチャ バージョンは複数のインスタンス仕様を提供し、最大総帯域幅 2G、QPS 6,000 万をサポートします。さまざまなパフォーマンスと容量の要件を満たすために、インスタンスのアーキテクチャと仕様を調整することをサポートします。無誘導伸縮を実現します。サーバーレス エンジン サービスのストレージ要件を満たすことができます。
FaaS は現在、サーバーレス バックエンド マイクロサービスで最も一般的なテクノロジーの選択です。Alibaba Cloud Function Compute は、Forrester によって認定された世界をリードするファンクション コンピューティング製品であり、パブリック クラウドおよびグループ内でサーバーレス アプリケーションに関する豊富な経験を蓄積しているため、適切な選択肢となります。
高いパフォーマンス要件
RTA 広告配信システムは、外部メディアの関連サービスを提供するシステムとして、大規模なトラフィックと高遅延要件の特徴があり、高いパフォーマンスが要求される典型的なシナリオです。このようなシナリオでは、クライアントによって設定されたタイムアウト期間は通常非常に短く、タイムアウトが経過すると、インターフェイス呼び出しは失敗します。サーバーレス アーキテクチャを採用した後、要求されたトラフィックはまず FC システムに入り、次に処理のために関数インスタンスに転送されます。このシナリオでは、FC のマルチテナントおよび大規模なトラフィック要件の場合、リクエスト処理に費やされるシステム時間の平均値 (関数自体の実行時間を除く) と P99 値は非常に低いレベルに維持されます。リクエスト成功率の SLA 要件を確保します。
着陸計画
システム構造
新しいアーキテクチャでは、中間ステーションがクラウドを生成した後、Redis の BF.INSERT およびその他のコマンドを呼び出して bf を生成します。エンジン側はデバイスIDを取得後、RedisのBF.EXISTSコマンドを通じて該当する群衆にあるかどうかを判断します。
特徴：
- ゲートウェイを削除してリンク長を短くします
- キャッシュを設定し、オフライン システムとオンライン システムを分離し、パフォーマンスを向上させます
- データ圧縮によるメモリ使用量の削減
- システムはサーバーレスで、リアルタイムの弾力性と自由な運用保守を実現し、アプリケーションの反復を高速化します。
リクエストのスケジュール設定
AutoNavi RTA 広告配信システムには、典型的な高パフォーマンス シナリオである大規模なトラフィックと高い遅延要件の特性があると前述しました。FCは代表的なマルチテナントシステムであり、クラスタ内にはオートナビRTAの広告機能だけでなく、その他多くの業務機能が存在します。FC のリクエスト スケジューリングには非常に高い要件が課されます。
- 単機能 QPS には上限がなく、多くのロングテール機能はリソースを消費しません
- サービスのスケジューリングは高可用性を確保する必要があり、単一点障害がサービスに影響を与えることはありません
- リクエスト処理に必要なシステム時間は、平均値で2ms未満、P99値で10ms未満に制御する必要があります。
FCがどのようにそれを行ったかを見てみましょう。
リアルタイムの弾力性を実現するために、関数リクエストが Function Compute のフロントエンド マシンに到着すると、フロントエンドはスケジューリング ノード (パーティションワーカー) にリクエストを処理して転送するインスタンスを要求します。スケジューリング ノードはリクエストを受信した後、利用可能なインスタンスがある場合は負荷分散戦略に従ってインスタンスを取得し、フロントエンド マシンに返します。そうでない場合は、リアルタイムでインスタンスを作成してフロントエンド マシンに返します。フロントエンドマシン。インスタンスの作成時間は数百ミリ秒に達する場合があります。
- 高可用性と水平スケーラビリティを確保するために、スケジューリング ノードはパーティション アーキテクチャを採用しています。
- 同じユーザー/機能からのリクエストは連続したシャードにマッピングされます
- 単一の関数リクエストは複数のシャードにまたがり、水平方向に拡張できます。
- スケジューリング ノード (Partitionworker) は、ハートビートを通じて断片化とノードのステータスを断片化マネージャー (Partitionmaster) に報告します。
- パーティションマスターはシャードの移動/分割/結合により負荷分散を実行します
- 100 万の機能をスケジュール、単一機能の最大ピーク値は 200,000 TPS、スケジューリング遅延は 1 ミリ秒未満
- ノードに障害が発生した場合、リクエストは他のパーティションワーカーにルーティングされ、可用性には影響しません。
リクエストは、特定の関数インスタンスに転送される前に、フロントエンド マシンとスケジューリング ノードによって処理される必要があることがわかります。したがって、リクエスト処理のシステム消費時間には、フロントエンドコンピュータの処理時間、スケジューリングノードの処理時間、フロントエンドコンピュータとスケジューリングノード間の通信時間、およびフロントエンドコンピュータとスケジューリングノード間の通信時間が含まれます。ディスパッチング システムは、リクエスト処理に必要なシステム時間の平均値が 2 ミリ秒未満、P99 値が 10 ミリ秒未満に制御されるように、ターゲットを絞った最適化を数多く行っています。非常に大きな交通量。
リソースの配送
サーバーレス シナリオでは、企業はリソース管理を気にする必要がなくなり、プラットフォームがリソース管理とスケジューリングを担当します。ビジネス トラフィックが増加すると、プラットフォームはビジネスに必要なコンピューティング リソースを迅速かつ確実に提供できる必要があり、トラフィックが減少すると、プラットフォームはアイドル状態のリソースを自動的に解放する必要があります。
Gaode RTA 広告機能を含む機能のリソースの厳格な配信を確保するために、FC はリソース管理の実装の最適化を続けています。
新しいサーバーレスベース: Shenlong ベアメタル + 安全なコンテナ
当初、FC は Function Compute インスタンスを Docker コンテナーの形式で提供していました。Docker はコンテナエスケープやストレージなどのセキュリティ上の問題があるため、セキュリティを確保するためにホストは 1 つのテナントの機能のみをデプロイします。FC にはロングテール関数が多数あるため、関数インスタンスの仕様は多くの場合、わずか 128M/0.1 コアなど比較的小さく、リソース使用率の向上には限界があります。
この問題を解決するために、FC と関連チームが協力してリソース ベースを X-Dragon Bare Metal + Secure Containers に完全にアップグレードし、X-Dragon Bare Metal ソフトウェアとハードウェアの統合によってもたらされる仮想化効率の向上を活用して、多くの利点を実現しました。テナントが高密度に混在するため、リソースの使用率が大幅に向上します。
独立したリソースの管理と制御
K8s クラスタの Pod 出力効率は、サーバーレスの毎分数万インスタンスの作成要件を満たすことが難しいため、FC は関連チームと協力して、Pod 内のコンピューティング リソースをさらに細分化し、高いパフォーマンスを実現します。密度の高い展開と高頻度の作成機能。
ミリ秒レベルのリソース配信速度
K8 のリソース配信速度要件が分レベルを超えるのと比較して、サーバーレス シナリオではリソース配信速度を秒レベルまたはミリ秒レベルまで高める必要があります。K8s インフラストラクチャの時間のかかる起動と、極めて高い柔軟性を求めるファンクション コンピューティングの強力な魅力との間の矛盾を解決するために、FC はポッド リソース プーリング、イメージ アクセラレーション、イメージ プレヒート、コンピューティング インスタンスのリサイクル、およびその他のテクノロジを実装して、極めて高速なリソースを確保しました。配達速度。
高可用性
高可用性を実現するために、FC リソースは各リージョン内の 1 つの K8s クラスターだけでなく、複数の K8s クラスターに分散されており、いずれかの K8s クラスターに問題が発生した場合は、自動的に通常のクラスターに切り替わります。各クラスターには、排他的リソース プール、混合リソース プール、プリエンプティブル リソース プールなど、複数のタイプのリソース プールがあります。FCではビジネスの特性に合わせて統一的なスケジューリングを行うことで、さらなるコスト削減を実現します。
配信SLA
リソース配信の総量に関しては、FC は現在 1 つの機能で数万のインスタンスを配信するケースがありますが、FC はリソース プールを動的に補充する機能があるため、理論的には FC の 1 つの機能で配信できるインスタンスの数は減少します。配信できるインスタンスは数万をはるかに超えています。リソース配信速度の点では、FC は 100 ミリ秒のインスタンス作成速度を達成できます。バーストの場合、FC は次の 2 つの側面からリソース配信速度を制御します。
- バーストインスタンス数: すぐに作成できるインスタンスの数 (デフォルトは 300)。
- インスタンスの増加率: 突然増加するインスタンスの数 (デフォルトは 1 分あたり 300) を超えた後、1 分あたりに増加できるインスタンスの数。
上記のパラメータは調整可能です。
次の図は、コール数が急速に増加するシナリオにおける FC のフロー制御動作を示しています。
マルチルーム展開
このシステムは 3 ユニット展開を採用しており、近くの外部メディアにアクセスできるようにし、ネットワーク遅延を軽減します。
ビジネス効果
システム アーキテクチャがアップグレードされた後、数千のコア マシン リソースが節約され、サーバーレスが実現され、通話リンクが短縮され、システムはより柔軟で堅牢になり、保守が容易になり、良好な業績を達成しました。
展望
過去 2022 年に、AutoNavi はサーバーレスの分野で大きな進歩を遂げました。ただし、これは終わりではなく、単なる始まりにすぎません。フォローアップ FC は AutoNavi と協力して包括的なサーバーレス アプリケーションを推進し、AutoNavi が次の分野で役立つことを期待しています。さまざまなシナリオでサーバーレスを使用し、サーバーレスによってもたらされる技術的な利点を十分に理解してください。
さらに多くのコンテンツについては、サーバーレス WeChat パブリック アカウント (ID:serverlessdevs) に注目してください。このアカウントには、サーバーレス テクノロジの最も完全なコンテンツがまとめられ、サーバーレス アクティビティ、ライブ ブロードキャスト、およびユーザーのベスト プラクティスが定期的に開催されます。