Implementation and case analysis of serverless architecture

インターネットソフトウェアアーキテクチャの進化

まず、インターネットソフトウェアアーキテクチャの進化を簡単に振り返りましょう。シングルマシンデプロイ：シングルマシンデプロイでは、すべてのビジネスとデータベースが 1 台のホストにデプロイされます。

このアーキテクチャの利点は、開発、デプロイ、運用保守が非常にシンプルなことです。欠点は、過度なトラフィックやマシン障害が発生すると、システム全体が麻痺し、ビジネスデータを失って甚大なビジネス損失を招く恐れがあることです。

クラスターデプロイ

前述のアーキテクチャの課題に対して、一般的な解決策は水平スケーリングによるクラスターデプロイを採用することです。SLB トラフィックゲートウェイのルーティングを導入し、負荷分散を実現します。

クラスターデプロイは本質的にシングルアーキテクチャです。プロジェクト開発時に開発者は追加の注意が必要です。たとえば、Cookie を使用した認証では、セッションをローカルに保存できず、Redis を導入して別途保存する必要があります。クラスターデプロイは、トラフィックの急増やマシン障害の問題を、迅速な水平スケーリングによって解決できます。

マイクロサービス分割

ビジネスの発展とチーム規模の拡大に伴い、シングルアーキテクチャの密結合アプローチはますます多くの問題をもたらし、アーキテクチャの柔軟性とスケーラビリティがビジネス発展を阻害する大きな課題となります。そこで、マイクロサービスアーキテクチャが誕生しました。

シングルアーキテクチャと比較して、マイクロサービスアーキテクチャははるかに複雑であり、API ゲートウェイ、サービス登録、サービスディスカバリ、RPC 通信など、多くの新しい技術が派生しています。

サーバーレスアーキテクチャ

シングルアーキテクチャからマイクロサービスアーキテクチャへ、单机デプロイからクラスターデプロイへ、インターネットソフトウェアアーキテクチャはますます複雑になっており、企業は基盤技術のアップグレードと維持に多くの労力とコストを投資する必要があります。次の図はサーバーレスアーキテクチャを示しています。シングルアーキテクチャとの違いは、対応するコンポーネントがサーバーレスクラウドプロダクトに置き換えられている点です。

技術進化の本質は、ビジネスにより良くサービスを提供することです。従来の開発方法では、企業が基盤技術の詳細を磨くことにより多くの労力を費やしてしまいます。サーバーレスアーキテクチャは、開発者がビジネス実装に注力し、より大きなビジネス価値を生み出せるようにするためのものです。

サーバーレスアーキテクチャの利点は明らかです。

● 基盤インフラに注力せず、ビジネス価値の創造に集中

● 自動スケーリングで、トラフィックの急増にも余裕を持って対応

● リソース使用量に基づく課金で、リソースのアイドルと無駄を回避
サーバーレスアーキテクチャの検討
まず、FaaS の実行プロセスを見てみましょう。青色の部分はユーザーが手動で管理する部分で、コードデリバリーのみが必要です。その他の起動、実行、保守タスクは FaaS プラットフォーム上で実行されます。

ただし、このアーキテクチャでは以下の問題が発生する可能性があります。

● コードの断片化により、統一管理とデプロイができない

● ローカル環境とオンライン環境に乖離があり、依存関係の互換性問題に対処できない

● ローカルデバッグとオンラインデバッグが困難

● FaaS メーカーはコードパッケージに制限を設けており、大規模なコードパッケージをデプロイできない

● 統一基準の欠如により、ベンダーロックインの問題が発生

Serverless Devs はこれらの問題に対処します。Serverless Devs は開発者がサーバーレスアプリケーションをより良く開発・管理できるようにします。以下の特徴があります。

● ベンダーロックインなし。Serverless Devs は開発者のアプリケーションを各ベンダーにデプロイ

● オープンソースで、コードロジックにブラックボックスなし

● 機能のプラグイン化。Serverless Devs はコンポーネント形式で提供され、開発者はニーズに基づいて独自のツールスイートを迅速に開発可能

● プロジェクトのフルライフサイクル管理機能。Serverless Devs は、プロジェクトの初期化、作成、開発、デバッグ、デプロイなどのフルライフサイクル管理を行うためのツールです。サーバーレスアプリケーション開発の簡素化を実現します。サーバーレスアーキテクチャが開発者のアプリケーション開発を支援するなら、Serverless Devs はサーバーレス開発者がより良くサーバーレスアプリケーションを開発できるように支援します。

サーバーレスアーキテクチャの実践

Serverless Devs 公式サイトでの実践は、前述の紹介からわかるように、Serverless Devs 開発者ツール自体はサービスを提供せず、サービスの実装はコンポーネントによって提供されます。一方で、コンポーネント自体は異なる GitHub リポジトリに分散しています。

Serverless Devs 公式サイトには以下の要件があります。

● 異なるリポジトリにある GitHub 来源のドキュメントを 1 つのインターフェースに表示

● コンポーネント開発者はコンポーネントドキュメントに注力し、リアルタイムで自動的に公式サイトに同期

● コンポーネントの変更が発生すると、公式サイトが自動的にデプロイ・ビルド。全体のスキームは以下の通りです。

開発者が GitHub でドキュメントを更新し、Webhook で設定された Http Serverless 関数をトリガーします。ここで注意が必要です。コンポーネントのドキュメント数が可変であり、GitHub のネットワークが不安定なため、すべての処理を Http 関数で実行するとタイムアウトが発生しやすくなります。したがって、すべての処理ロジックは非同期呼び出しに配置され、処理結果は実行後にメールなどで配信されます。

Alibaba Cloud Function Compute コンソールの実践
Alibaba Cloud Function Compute（FC）コンソールは、ユーザーが Function Compute プロダクトを使用する際の最初のステップであり、コンソールのユーザーエクスペリエンスが極めて重要です。

以下のアーキテクチャ課題があります。

● バックエンドは集中デプロイモードを採用しており、海外でのユーザーアクセス遅延が非常に高い

● ユーザーがモニタリング、ロギング、グレーリリースなどの機能を手動で構築する必要があり、運用保守コストが高い

● 研究開発効率が低く、開発プロセスでフロントエンドとバックエンドの間の調整とコミュニケーションが必要で、コラボレーションコストが高い

全体のソリューションは以下の通りです。

左側は Alibaba Cloud の共通ゲートウェイで、認証とセキュリティロジックを統一して担当し、BFF（Back for Front）レイヤーを引き出します。この部分の特徴は以下の通りです。

● 全体の BFF は Alibaba Cloud Function Compute（FC）上にデプロイされ、開発者は手動で運用保守する必要がない

● BFF レイヤーはフロントエンドエンジニアが担当し、ビジネスを深く理解し、優れたユーザーエクスペリエンスを提供

● バックエンドエンジニアは基盤の安定性とアトミック機能の提供に注力し、SDK を通じて BFF にデリバリー

サーバーレスで実装された BFF は、ビジネスに大きな柔軟性をもたらすだけでなく、フロントエンドエンジニアのチームにとっても質的な変化をもたらします。以前の技術視点から、よりビジネス価値とユーザーエクスペリエンスの向上に注力するようになりました。

CD 構築の実践

従来のセルフビルド CD クラスターソリューションでは、Jenkins または Tekton フレームワークを使用してビジネスロジックをオーケストレーションし、リソースレベルでは K8s デプロイによりオートスケーリングを実現します。シンプルなクラウドベースの CD 構築ソリューションを実装する場合、上記のアーキテクチャは若干複雑です。CI/CD ビジネスシナリオには以下の特徴があります。
● イベントによって実行がトリガーされる
● トラフィックを事前に予測できない
● 長時間のバックグラウンド実行が必要で、レイテンシに鈍感
● ネットワーク遅延などの問題により、失敗時のリトライメカニズムを設計する必要がある

これらの特徴はサーバーレスに完全に適合しています。実装スキームでは、非同期関数を使用してビルドの全プロセスを非同期関数に誘導し、処理を行います。全体のオーケストレーションロジックは Serverless Devs を通じて実行され、安定したパフォーマンスを持つ CD ビルドクラスターを完璧に実現します。Alibaba Cloud Function Compute アプリケーションセンターの基盤 CD 機能は、上記の原則に基づいて完全に実践されており、ご自身で体験いただけます。

非同期関数

非同期関数には多くの実践シナリオがあります。ここで簡単に紹介します。

まとめると、非同期関数には 4 つの特徴があります。

1. 長時間の実行が可能で、2 時間から 1 日までの範囲

2. 自動終了を設定でき、時間を自由に調整可能で、リソースを節約

3. トリガー結果をさまざまなイベントキューに配信可能

4. 障害発生時に自動的にリトライする 3 つの機会