Fliggyのクラウド+ターミナルの実践とサーバーレスをベースとした考え方

過去 2 年間、Feizhu のフロントエンドでは積極的にサーバーレスの構築と実践が行われてきました。 2019年から2020年にかけて、当社はグループのNodeアーキテクチャグループおよびR＆Dプラットフォームと協力して基本機能とビジネスパイロットの構築を完了し、グループでサーバーレスプラクティスを実装した最初のBUとなりました。 2020年から2021年にかけて、Feizhuではサーバーレス機能の大規模な利用を推進し始めました。ショッピングガイドリンク全体からコアミドル、バックエンドまでサーバーレスであることが分かります。今年、私たちは Serverless をビジネスパイロットから生産性向上ツールへと変革しました。この記事では、主に Serverless をベースにした Feizhu の実践結果と、今後実現したいことについて共有します。

サーバーレスの使用規模

Alizhu における Serverless の規模と重要性は、2020 年から 2021 年にかけて、主に次の 3 つの点で大きく変化しました。

• まず、機能グループのサイズが 2 倍以上に拡大し、ピーク Qps が 650% 増加しました。
• 2つ目は、FaaS開発を利用する人の数が560%増加し、そのうちフロントエンド担当者の80%以上がFaaSの開発に携わっていることです。
• 3つ目は影響力です。現在、Feizhu のフロントエンドが Serverless に精通しているだけでなく、クライアント側でも多くの人が FaaS の開発に携わっています。さらに重要なのは、バックエンドと製品の同僚も、サーバーレスを使用してサービスを開発する能力があることを知っていることです。

具体的なデータは以下の通りです。

サーバーレスを導入する理由

Fliggy が Serverless の導入に熱心なのはなぜでしょうか?これは主に、フロントエンドとバックエンドのR＆Dモデルのアップグレードとフロントエンド機能の拡張を検討しているためです。以下は、Fliggy のフロントエンド アーキテクチャの開発と R&D モデルの進化の概要です。

1. Fliggyのフロントエンドアーキテクチャの開発

まとめると、Feizhu のフロントエンド アーキテクチャは、当初の純粋なフロントエンド開発から、マルチエンドの一貫性を解決するクロスエンド開発、そしてビュー サーバー ロジックを引き継ぐフロントエンド開発へと進化してきました。サーバーレスは、フロントエンドのアップグレードと変革の中核となるリンクです。

2. R&Dモデルの進化​

なぜフロントエンド担当者がサービスサイドの開発に参加する必要があるのでしょうか?フロントエンドとバックエンドのR&Dモデルの進化からは、主に次の3つの主要な段階を経てきました。​

• 第一段階はリソースの分離です。この段階では、フロントエンドは静的リソースを分離して CDN にデプロイし、バックエンド サービスと同じマシンにデプロイする際の結合問題を解決します。
• 2 番目の段階はテンプレートの分離です。前に述べたフロントエンドとバックエンドの分離は、主にテンプレートの分離を指します。不完全な解決策はレンダリングの分離です。サーバーは空のテンプレートを配置し、コンテンツは完全に CSR に依存します。徹底的な解決策は、フロントエンドがテンプレートを引き継ぐことです。テンプレートは独立してデプロイすることも、node.js に置き換えることもできます。​
• 3 番目の段階は、分離を試みることです。一方、クライアント システムとフロントエンドのオフライン システムの制限により、エンド側ではビューの動的な性質に対して非常に高い要件が課せられます。サーバー側の機能を持たないフロントエンドでは、サーバー側でのビューの動的な性質のみを実行できます。一方、データ インターフェイス プロトコルに対するエンド側アーキテクチャの特別な要件により、サーバー側でプロトコル変換を実行する必要があります。これは、サーバー側でよく Do から Vo への処理と呼ばれます。これにより、フロントエンド ビューとバックエンド ビューが結合されます。この結合部分を削除するために、フロントエンドは Node.js を BFF レイヤーとして使用し、ビュー レイヤーのロジックを引き継ぎます。サーバーレスは、フロントエンドで BFF 開発を行うための最適な選択肢を提供します。

3. なぜサーバーレスなのか?

実際、サーバーレスが登場する前は、フロントエンドでも BFF レイヤーの開発にノード アプリケーションを使用しようとしていました。 2017 年、Alizhu は Midway + React SSR アーキテクチャを使用して、Alizhu PC のメイン リンク ホームページ、検索、製品の詳細、注文の詳細をノード化しました。ただし、アプリケーション レベルの開発では、フロントエンドに次のような問題があります。​

• - 高い開発コスト: Node アプリケーション レベルの開発には、初心者のフロントエンド開発者にとって依然として一定の開発コストがかかります。以前の概算では、開始コストは少なくとも 3 人 / 日で、その後のパフォーマンス最適化やメモリ リーク検出などの一連の機能は含まれていませんでした。
• 高い運用・保守コスト: Docker、ミラーリング、マシンログの閲覧、ドメイン名の適用、マシンの交換などの運用・保守機能はフロントエンドにとって非常に複雑であり、これも推進に失敗する重要な理由です。
• マシンコストが高い: アプリケーション開発を使用する場合、フロントエンドはフロントエンドアーキテクチャ設計に過度に偏り、アプリケーションの分離とマシン使用率の低下につながります。根本的な原因は、フロントエンドがページ開発の考え方を使用してアプリケーションを開発しているため、多数の新しく構築されたアプリケーションが多数のアイドルマシンを占有していることです。

2017年から2019年は、グループのノード開発が停滞した2年間でもありました。この期間中、上記の問題が放置されていたため、Node 開発をモバイル側で展開することができませんでした。フロントエンドは主にミドルエンドとバックエンドの開発にNodeを使用しました。この時点での矛盾は、フロントエンドのR＆Dモデルの変更に対する切実な要望と、サーバーサイド開発に関与するためのコストの高さに主に現れていました。サーバーレスの波が出現するまで、私たちは夜明けを見ていました。サーバーレスがフロントエンドにどのような変化をもたらすかを見てみましょう。

Node FaaS は、ミドルウェアをランタイムのコンテキストに統合し、API を介して呼び出すことで、非常に低い起動コストと開発コストを実現します。 js を書ける人なら誰でも、0.5 人日以内に FaaS 開発を始めることができます。同時に、基盤となるサーバーレス コンテナは、統合されたマシン管理、統合されたイメージ、柔軟なスケジュール設定、従量課金制の支払いを通じて、コンテナの操作とメンテナンスを開発者から保護します。これら 2 つの組み合わせにより、これまでの Node アプリケーション開発で発生した 3 つの主要な問題を完全に解決できます。バックエンドのR＆Dモデルのアップグレードのためのパズルの最後のピースが完成し、フロントエンドではクラウド+端末の変革が始まりました。

Feizhu Cloud+Terminalのコアアプリケーションシナリオ

1. 実装シナリオの概要

Fliggy のホームページから検索、チャネル、そしてプロモーション会場まで、Serverless FaaS は Fliggy 上のショッピング ガイド チェーン全体を完全にカバーし、Fliggy のフロントエンドでよく使用される生産性ツールの 1 つになりました。さらに、中間開発およびバックエンド開発で FaaS がフル活用され、クライアントの同僚に権限が与えられました。下図の右側にあるパッケージボリュームプラットフォームは、Node FaaS を使用して Feizhu クライアントの同僚によって開発されました。

2. クラウド + 端末シナリオ - データプロトコル処理​

データ プロトコル処理は、インターフェイスのマージや Do から Vo への変換など、BFF レイヤーで最も一般的なシナリオです。 Alizhu の C エンド FaaS シナリオの 80% 以上は、データ プロトコル処理に使用されます。 FaaS を使用してプロトコル変換を実行すると、サーバーが解放され、フロントエンドのビュー層に対する制御が強化されるため、一石二鳥になります。​

最近の例としては、Fliggy のコンテンツ詳細ページがあります (下図参照)。このページには、コンテンツ ミドル プラットフォーム、評価ミドル プラットフォーム、インタラクション、アルゴリズムなど、5 つ以上のインターフェイスが含まれます。これらのインターフェースはすべて既成であり、さまざまなシステムに散在しています。フロントエンドは、最後にインターフェースを 5 回呼び出すことを望んでいません。パフォーマンスの観点から見ても、建築デザインの観点から見ても、これは不合理です。現時点では、サーバー側のインターフェースの統合が必要です。 FaaS はこれを実行するのに非常に適しています。アトミック機能を組み立てることで、サーバーの介入が不要になり、要求の配信サイクルが大幅に短縮されます。

3. クラウド + ターミナルシーン - SSR 均質レンダリング​

SSR 同型レンダリングは新しい概念ではありません。 React が初めて SSR をサポートしたとき、フロントエンドはサーバーとクライアント上で一連のコードを実行する機能を備えていました。 Alitrip は 2017 年に早くも PC 側で Midway + React SSR ページを立ち上げました。

モバイルデバイスのトラフィックは PC よりもはるかに大きく、サーバー側で Js を実行することは多くのマシンリソースを消費する操作です。 Node アプリケーションを使用して SSR を実行する場合、マシンと運用および保守のコストがページ トラフィックとともに指数関数的に増加し、ROI は高くありません。ただし、Serverless FaaS の自動ホスティングにより、フロントエンドでのマシン使用率や運用・保守コストの問題を解決できます。​

クライアントのドキュメントのプリロードと組み合わせることで、100% のクライアント プリロード直接出力レート (500 ミリ秒未満)、90% 以上のオフエンド レンダリング 2 秒準拠率、および 80% を超えるパフォーマンス向上を実現できます。

4. クラウド + ターミナルシナリオ - 統合アプリケーション​

統合型 R&D は、フロントエンド担当者の習慣に沿った開発モデルです。最も一般的なものは、ミッドエンドとバックエンドの統合と Rax + FaaS の統合です。 FaaS コードと Assets コードを 1 つのウェアハウスで開発、デバッグ、デプロイすると、開発効率が大幅に向上します。現在、Feizhu で最も一般的に使用されている方法は、ミッドエンドとバックエンドの統合開発です。

サーバーレスR&Dサポート構築

インフラストラクチャに関しては、R&D 効率の向上と実行時の安定性の確保という 2 つの部分として定義されます。

1. 研究開発の効率

開発フェーズに含まれる主な操作は、新しいプロジェクトの作成、デバッグ、およびリリースです。 Feizhu は、既存の Clam エンジニアリング システムを通じて FaaS スキャフォールディング テンプレートを統合し、def API に接続してプロジェクトの作成、反復、リリースの機能を提供します。これにより、フロントエンドの学生はページの開発と同じ経験で FaaS を開発できるようになり、開始と開発のコストが削減されます。同時に、Mtop 呼び出しとディザスタ リカバリ SDK をカプセル化し、よく使用される FaaS Utils コレクションをカプセル化して、コードの再利用性を向上させます。​

2. 実行時の安定性​

Alinode の監視機能、Sunfire のゲートウェイ監視機能、およびフルリンク ログのトラブルシューティング機能により、問題を迅速に発見して特定できます。

Tair ディザスタ リカバリと CDN ディザスタ リカバリにより、ほとんどのシナリオでは、関数またはゲートウェイに障害が発生しても、ページを正常に表示できるようになります。

未来

2020 年から 2021 年にかけて、Serverless を生産性向上ツールへと変革しました。 2021年から2022年にかけて、FliggyのR＆Dモデルの変革を全体的に完了し、FaaSをフロントエンドとバックエンドの両方の一部にします。計画はまだ詳細化されていませんが、実行すべき重要なことがいくつかあります。​

• - ミッドバックエンドおよびロングテール機能については、0 から 1 へのバウンスを試みる: 一部のミッドバックエンドおよびロングテール機能では、1 日あたりの UV が数十個しかなく、Qps レベルに到達できない可能性があることを考慮すると、1 コア マシンを予約する現在の方法はまだ少し無駄があります。マシンの最大限の使用率を達成するには、最初のリクエストに影響を与えずに 0 から 1 にバウンスすることを検討してください。
• Fliggy の物理ゲートウェイの交換: Fliggy の Java ゲートウェイは現在、投資額が少なくメンテナンス状態ですが、トラフィックが変化すると、ゲートウェイの安定性がボトルネックになります。専任の FC チームがトラフィック ゲートウェイを引き継ぐことが期待されます。 Fliggy は以前にもオンラインパイロットを完了しており、2021年から2022年にかけて引き続きプロモーションを行う予定です。
• R&D およびランタイムの問題の可観測性の強化: FC の基盤となるコンテナーから関数コード、関数の依存関係、トラフィック ゲートウェイに至るまで、デプロイメントの問題やオンラインの問題を見つけるのは困難です。通常、FC、R&D プラットフォーム、ランタイムの同僚と協力して共同で調査する必要があります。今後は、ビジネス開発者が問題を迅速に発見できるように、監視機能の強化を推進していきたいと考えています。

最後に

サーバーレスをベースにしたクラウドとターミナルの組み合わせが基本的に形になってきました。これは近年のフロントエンドにおける最大の変化の 1 つになります。今後、FaaS はフロントエンド開発に欠かせないものになるでしょう。 R&D モデルのアップグレードにそれを使用する必要があり、フロントエンドの機能拡張にもそれを使用する必要があります。 FaaS の機能により、フロントエンド開発はサービス層に深く入り込み、ビジネスにさらに近づき、ビジネスを理解し、ビジネスを支援することができます。​

著者について

Fliggy Travel のフロントエンド技術専門家である Wang Hengfei (Chengyin) は、Fliggy Serverless の紹介者および実践者であり、クラウド + ターミナルの R&D モデルを研究および推進しています。