Serverless debugging big killer device-cloud joint debugging

背景

現在最も注目されているテクノロジーといえば、サーバーレスという概念は避けられません。新しいアプリケーションアーキテクチャとして、サーバーレスはインフラ保守の手間から私たちを解放してくれます。コードパッケージやイメージをアップロードするだけで、弾力的で高可用性、運用保守不要かつ低コストのサービスを利用できます。

魅力的に聞こえるサーバーレスの実際の実装と開発プロセスには、いくつかの課題が存在します。たとえば、サーバーレスを使用する際に、以下のような問題に直面することがあるでしょう。

・Custom Runtime やコンテナを使用する関数で、SpringBoot、Python Flask、ThinkPHP などさまざまな言語フレームワークのアプリケーションをワンクリックで移行したい場合。インスタンスの起動プロセス中に、クラウド環境内の他のサービス（データベースやレジストリなど）にアクセスする必要があります。アプリケーションの起動に失敗した場合、どのように原因を特定すればよいでしょうか。

・マイクロサービスアーキテクチャを採用したアプリケーションで、複数のサービスが関連している場合。ローカルでのコード開発が完了した後、エンドツーエンドのテストを迅速に実行できるでしょうか。

・イベント駆動型アプリケーションで、イベントソーストリガーを通じて関数を呼び出し、複数のリンクと長いリンクがある場合、リンク全体をローカルで迅速にテストできるでしょうか。

・その他……

業界調査レポートでも、デバッグがサーバーレス実装の最大の障壁であることが示されています。現在、業界で既存のサーバーレスアプリケーションのデバッグ手法は、主にクラウド実行環境をシミュレートしたローカルデバッグと、リモート環境で実行されるアプリケーションのログ確認に依存しています。ローカルデバッグでは実際のクラウド環境を再現できないため、上記の問題を解決できません。そこで、サーバーレスアプリケーションのデバッグ問題を解決するために、業界初となるエンドツーエンドのクラウドエンド共同デバッグ機能を導入しました。

クラウドエンド共同デバッグ

Serverless Devs のクラウドエンド共同デバッグ機能の核心的な考え方は、ローカル開発環境がネットワークの制約を突破し、クラウド環境と連携できるようにすることです。開発者はローカルからエンドツーエンドのクラウドデバッグを通じてインスタンスを起動し、クラウド環境とシームレスに接続して、迅速にテストと問題のデバッグを行えます。クラウドエンド共同デバッグは開発者に以下をもたらします。

1. コードを変更するとリアルタイムで結果を確認でき、最短のフィードバックループでデバッグが可能です。たとえば、開発中のサービスが他のサービスに依存している場合、ローカルでのコード開発完了後すぐにエンドツーエンドテストを開始して、呼び出し元のサービスに変更の影響がないかを確認できます。従来の方法では、リモート環境にコードを展開してからテストを開始する必要があり、長い時間がかかっていました。

2. 豊富なローカル開発・デバッグツールを最大限に活用でき、最高の効率を実現します。たとえば、リモート環境で失敗したテストケースの調査は、これまでログに頼るしかありませんでした。ローカル環境のインスタンスに本番トラフィックを転送し、使い慣れた IDE でブレークポイントデバッグを行えたら、非常に効率的ではないでしょうか。

下図に示すように、エンドツーエンドのクラウドエンド共同デバッグは、ローカル開発マシンとクラウドアプリケーションの VPC 環境の間にセキュアトンネル接続を確立します。クラウドアプリケーションへのアクセス流量は自動的にローカル開発マシンに転送されます。同時に、ローカルインスタンスからの外部アクセス流量もクラウドアプリケーションの VPC 環境に自動転送されます。たとえば、ローカルインスタンスからクラウド上の RDS データベースインスタンスにアクセスする場合、従来の方法ではローカルでデバッグや開発を行う際に、RDS インスタンスのパブリックネットワークアクセスを公開するか、VPN サービスを購入する必要がありました。クラウドエンド共同デバッグでは、設定を一切変更することなく、イントラネット経由で RDS インスタンスに直接アクセスできます。

エンドツーエンドのクラウドエンド共同デバッグを有効にする

ユーザーは s.yaml が配置されているディレクトリで s proxied setup コマンドを実行するだけです。このコマンドは以下の処理を行います。

1. s.yaml の VPC 設定などの情報に基づいて補助サービス/関数を作成し、補助関数のインスタンスを 1 つ予約します。この補助関数の目的は、ローカルインスタンスへのすべての送受信トラフィックが通過するプロキシサービスとして機能することです。

2. ローカル環境でプロキシコンテナインスタンスを起動し、チャネルサービスを通じて 1 のクラウド側ネットワークプロキシコンテナインスタンスと双方向 TCP トンネルを確立します。

3. ローカル関数コンテナインスタンスを起動します。たとえば、Custom Runtime から SpringBoot アプリケーションを直接実行している場合、SpringBoot のローカル関数コンテナインスタンスを起動し、2 のプロキシコンテナインスタンスとネットワークを共有します。SpringBoot アプリケーションは既にイントラネット経由でオンライン VPC リソースにアクセスできます。

ローカル関数コンテナインスタンスが正常に起動したら、デバッグを開始できます。s proxied invoke または curl でカスタムドメインを使用して補助サービス/関数を呼び出します。トラフィックはプロキシサービスを通じてローカル関数コンテナインスタンスにルーティングされ、ローカル IDE でインスタンス内のアプリケーションに対してブレークポイントデバッグを行えます。

クラウドエンド共同デバッグを閉じる

デバッグ中は補助関数にインスタンスが 1 つ予約されるため、デバッグ完了後はリソースを手動でクリーンアップして不要なコストを回避する必要があります。

1. クラウドエンド共同デバッグを有効にしたターミナルで、CTRL+C を押して直接中断します。

2. または、別のターミナルで同じディレクトリから s proxied cleanup を実行します。

上記 1 または 2 のいずれかの方法を使用します。不安な場合は、s proxied cleanup を複数回実行してもかまいません。

クリーンアップを忘れた場合でも、ローカル開発マシンがシャットダウンまたは切断されると、チャネルセッションは自動的に閉じられ、予約されたリソースも自動的にクリーンアップされます。

実践シナリオの例

Alibaba Cloud Function Compute を例に挙げます。小王はビジネス駆動型の企業の開発者です。ビジネス反復の効率を向上させるため、同社は技術アーキテクチャをクラウドコンピューティングに移行し、インフラストラクチャの管理と運用保守を削減しました。アーキテクチャはおおよそ以下の通りです。

小王は最も頻繁に反復される外部フロントエンド・バックエンド分離プロジェクトをワンクリックで Function Compute のカスタムランタイムに移行します。この際、SpringBoot プロジェクトはさまざまな VPC イントラネットアドレスを使用して、ダウンストリームサービス（レジストリや他のマイクロサービスインターフェースなど）にアクセスできる必要があります。このような場面で、Serverless Devs が提供するエンドツーエンドのクラウドエンド共同デバッグが役立ちます。s.yaml（関数に定義された VPC 設定を含む s.yaml）が配置されているディレクトリで以下を実行するだけです。

$ s proxied setup

このコマンドはクラウド VPC 環境とのセキュアなネットワークチャネルを確立し、アプリケーションインスタンスをローカルで起動します。起動したローカルインスタンスはクラウド VPC 環境内のリソースにシームレスにアクセスでき、イントラネットアドレスを使用してレジストリ、RDS、Kafka などにアクセスできます。つまり、アプリケーション設定を一切変更することなく、ローカル環境とクラウド環境の両方のリソースとやり取りできます。

同時に、この SpringBoot バックエンドプロジェクトで FC 上のカスタムドメインにアクセスすると、トラフィックはローカルアプリケーションインスタンスにルーティングされます。たとえば、FC に展開されたフロントエンドプロジェクトの関数名が frontend で、対応するカスタムドメインが frontend.abc.com だとします。フロントエンドが依存するバックエンドサービスの関数名が backend で、対応するカスタムドメインが backend.abc.com だとします。このとき、ブラウザで frontend.abc.com を開いてバックエンドリクエストを伴う操作を行うと、トラフィックはオンラインからローカルの SpringBoot インスタンスに自動的にルーティングされます。同時に、SpringBoot のログがターミナルにリアルタイムで表示され、ブレークポイントを使用してオンラインからのトラフィックをデバッグすることもできます。

SpringBoot バックエンドプロジェクトのインスタンスがローカルで起動に失敗したと仮定します。考えられる原因としては、Function Compute の VPC 設定が正しくないことや、対応するダウンストリームサービスのホワイトリスト制限などがあります。このような場合、クラウド環境のインスタンスと同じ起動プロセスをローカルで再現でき、インスタンス起動問題のトラブルシューティングに非常に役立ちます。下図に示す通りです。

ローカルインスタンスの起動プロセス情報から、Nacos にアクセスできない理由を明確に特定できます。関数が Nacos の配置されている VPC 情報を正しく設定しているかどうか、または Nacos にホワイトリスト制限があるかどうかを確認する必要があります。

まとめ

最後に、ローカルデバッグとクラウドエンド共同デバッグの違いを表で簡潔にまとめます。

サーバーレスは次の 10 年間のクラウドコンピューティングのデフォルトのコンピューティングパラダイムです。現在、デバッグはサーバーレス最大の課題の一つです。他のプロバイダーがローカルデバッグのみを提供できるのに対し、Alibaba Cloud Function Compute は革新的にクラウドエンド共同デバッグを提案し、ツールを通じて優れた開発者体験を実現することで、サーバーレスアプリケーション開発者の開発効率と満足度を大幅に向上させています。人生は短い。Serverless を使おう。