Practical Guide | Application Development under Serverless Architecture

サーバーレスアーキテクチャのアプリケーション開発プロセス

サーバーレスアーキテクチャに基づくアプリケーション開発プロセスは、従来のアーキテクチャに基づくものよりもシンプルになります。サーバーレスアーキテクチャでのアプリケーション開発では、ユーザーは通常、仕様に従ってコードを記述し、プロダクトを構築し、オンラインにデプロイするだけで済みます。

Figure 1 に示すように、CNCF Serverless Whitepaper v1.0 では、ファンクションのライフサイクルはコードの記述と仕様メタデータの提供から始まると指摘しています。Builder エンティティがコードと仕様を取得し、コンパイルしてアーティファクトに変換し、コントローラエンティティを持つクラスタにアーティファクトをデプロイします。コントローラエンティティは、イベントトラフィックやインスタンスの負荷に基づいて、ファンクションインスタンスの数をスケーリングする役割を担います。

Figure 2 に示すように、ファンクションの作成と更新の完全なプロセスは以下の通りです。

1) ファンクションを作成する際、ファンクション作成の一部としてメタデータを提供し、コンパイルして公開可能な状態にします。次に、ファンクションの起動と停止を行います。ファンクションのデプロイメントは、以下のユースケースをサポートできる必要があります。

• イベントストリーミング：この場合、キューに常にイベントが存在する可能性がありますが、一時停止/再開をリクエストして処理する必要がある場合があります。

• ウォームスタート：いつでも、最も少ないインスタンス数のファンクションが受信した最初のイベントを迅速に処理できます。これは、ファンクションが既にデプロイされており、イベントに対応する準備ができているためです（コールドスタートとは異なります）。コールドスタートでは、着信イベントを通じて最初の呼び出し時にファンクションがデプロイされます。

2) ユーザーはファンクションを公開できます。これにより、新しいバージョン（最新バージョンのコピー）が作成されます。公開されたバージョンには、タグやエイリアスを設定できます。

3) ユーザーは、デバッグや開発のために、イベントソースや API ゲートウェイをバイパスしてファンクションを直接実行/呼び出すことができます。必要なバージョン、同期/非同期操作、詳細ログレベルなどの呼び出しパラメータを指定できます。

4) ユーザーは、ファンクションの統計データ（呼び出し回数、平均実行時間、平均遅延、失敗数、再試行数など）を取得できます。

5) ユーザーは、ログデータを取得できます。ログデータは重要度レベル、時間範囲、コンテンツでフィルタリングできます。ログデータは各ファンクションレベルで管理されます。ファンクションの作成/削除、警告やデバッグメッセージ、オプションのファンクション Stdout または Stderr などのイベントが含まれます。呼び出しごとに 1 つのログエントリを記録するか、ログエントリを特定の呼び出しに関連付けることが推奨されます（ファンクションの実行フローをより簡単に追跡できます）。

Figure 3 に示すように、Alibaba Cloud のサーバーレス製品を例に、本番環境でのサーバーレスアプリケーション開発プロセスを説明します。

ステップ 1：FaaS プロバイダーが提供するランタイムに対応した使い慣れたプログラミング言語を選択し、プロジェクトの開発とテストを行います。

ステップ 2：コードが完成したら、FaaS プラットフォームにアップロードします。

ステップ 3：アップロード完了後、FaaS プラットフォームにアップロードされたファンクションは、API/SDK または一部のクラウドイベントソースによってトリガーされます。

ステップ 4：FaaS プラットフォームは、トリガーされた同時実行数とその他の弾力性に基づいて、対応するファンクションを実行します。

ステップ 5：最終的に、ユーザーは実際のリソース使用量に基づいて課金されます。

サーバーフルアプリケーション開発プロセスとの比較

次に、本番環境でのケースを通じて、従来のアーキテクチャでのアプリケーション開発とサーバーレスアーキテクチャでのアプリケーション開発を比較します。

Web アプリケーションを例にとります。Figure 4 に示すように、

一般的に、一部の Web アプリケーションは従来の 3 層 C/S アーキテクチャに基づいています。たとえば、一般的な E コマースアプリケーションでは、サーバーサイドで Java を、クライアントサイドで HTML/JavaScript を使用します。このアーキテクチャでは、サーバーは単なる ECS であり、多くのビジネス機能とビジネスロジックを担っています。たとえば、システム内のロジックの大部分（認証、ページナビゲーション、検索、トランザクションなど）はサーバー上で実装されています。

サーバーレスアプリケーション形式に変換すると、アーキテクチャは Figure 5 のようになります。

ステップ 1：サーバーレスアプリケーションモードでは、元のアプリケーションから認証ロジックを削除し、サードパーティの BaaS サービスに置き換えます。

ステップ 2：クライアントが直接一部のデータコンテンツにアクセスできるようにします。このデータはサードパーティによって完全にホストされています。ここでは、いくつかのセキュリティ設定を使用して、クライアントの対応するデータへのアクセスを管理します。

ステップ 3：上記の二つのポイントから、非常に重要な第三のポイントが導かれます。すなわち、従来のサーバーロジックの一部がクライアントサイドに移行したということです。たとえば、ユーザーセッションの維持、アプリケーションの UX 構造の理解、データの取得とユーザーインターフェースのレンダリングなどです。クライアントは実質的にシングルページアプリケーションへと徐々に進化してきました。

ステップ 4：重い計算タスクや大量のデータにアクセスする必要がある操作など、引き続きサーバーサイドに保持する必要があるタスクもあります。「検索」を例にとると、検索機能は常時稼働するサーバーから切り離し、FaaS で実装し、API ゲートウェイ経由でリクエストを受信してレスポンスを返すことができます（後で詳しく説明します）。このサーバーサイドファンクションは、クライアントと同じデータベースから製品データを読み取ることができます。元の検索コードを少し修正するだけで、この「検索」機能を実装できます。

ステップ 5：「購入」機能も別の FaaS ファンクションとして書き直すことができます。セキュリティ上の理由から、クライアントサイドではなくサーバーサイドで実装する必要があります。API ゲートウェイを通じて外部に公開されます。

従来の仮想マシンアーキテクチャでのアプリケーションの開発と公開は、Figure 6 に示す通りです。

コード開発後、開発者は公開前の準備を行う必要があります。これには、リソースの評価、サーバーの購入、オペレーティングシステムのインストール、サーバーソフトウェアのインストールなどが含まれますが、これらに限定されません。コードデプロイメントの完了後も、専門の人員やチームがサーバーやその他のリソースを継続的に監視し、運用保守を行う必要があります。たとえば、トラフィックが急増した際のスムーズなサーバーのスケールアウトや、トラフィックが急減した際のスムーズなサーバーのスケールインなどです。

しかし、サーバーレスアーキテクチャでは、開発モード全体が大きく変化しました。

前述の E コマースサイトと合わせて、Figure 7 を参照してください。上記のアプリケーション開発と公開のプロセスにおいて、サーバーレスアーキテクチャの開発者が実際に関心を持つのは、関数内のビジネスロジックのみです。認証ロジック、API ゲートウェイ、データベースなど、従来のサーバーサイドにあったプロダクトやサービスは、すべてクラウドプロバイダーによって提供されます。

同時に、ユーザーはサーバーレベルの保守に注意を払う必要がなく、トラフィックのピークとトラフに対応するための運用保守リソースを投入する必要もありません。アイドルリソースに対して追加料金を支払う必要もありません。サーバーレスアーキテクチャの従量課金制と弾力的なスケーリング、そしてサーバーの低運用保守/運用保守不要の機能により、ユーザーのリソースコストと人件費を削減し、全体的な R&D 効率を大幅に向上させ、プロジェクトのパフォーマンス、セキュリティ、安定性を強力に保証できます。

まとめると、サーバーレスアーキテクチャと従来のアーキテクチャのアプリケーション開発プロセスの明確な違いは、前者が開発者が自身のビジネスロジックにより集中できるようにし、NoServer の考え方を強調している点にあります。より専門的なことはより専門的な人に任せることで、ビジネスの革新と効率の向上を促進し、ビジネスの立ち上げと反復サイクルを短縮します。

課題

サーバーレスアーキテクチャは急速に発展し、多くの人々に真のクラウドコンピューティングと見なされています。2020 年の Cloud Habitat Conference でも、サーバーレスは「次の 10 年間のクラウドコンピューティングを牽引する」と改めて断言されました。しかし、サーバーレスアーキテクチャは依然として多くの課題に直面しています。

UC Berkeley の記事「Cloud Programming Simplified: A Berkeley View on Serverless Computing」（2019 年）では、サーバーレスアーキテクチャの以下の 5 つの課題がまとめられています。

1）抽象化の課題

リソース要件：サーバーレス製品では、開発者はクラウドファンクションのメモリサイズと実行時間を指定できますが、その他のリソース要件は指定できません。これにより、CPU、GPU、その他のタイプのアクセラレータなど、より詳細なリソースを制御したい場合に対応できません。

データ依存関係：現在のクラウドファンクションプラットフォームは、クラウドファンクション間のデータ依存関係を理解しておらず、これらのファンクションが交換する可能性のあるデータ量も把握していません。これにより、最適な配置が実現できず、非効率な通信パターンが生じる可能性があります。

2）システムの課題

エフェメラルストレージ：サーバーレスアプリケーションに一時的なストレージを提供する方法の一つは、最適化されたネットワークスタックを使用して分散メモリサービスを構築し、マイクロ秒レベルのレイテンシを確保することです。

永続ストレージ：他のアプリケーションと同様に、サーバーレスデータベースアプリケーションはストレージシステムのレイテンシと IOPS に制約されており、長期的なデータストレージとファイルシステムの可変状態セマンティクスを必要としています。

コーディネーションサービス：関数間の状態共有には通常 Producer-Consumer デザインパターンが使用され、Consumer は Producer の状態を即座に知る必要があります。

起動時間の最小化：起動時間は 3 つの部分で構成されます。第一に、クラウドファンクションを実行するためのリソースのスケジュールと起動の時間、第二に、ファンクションコードを実行するためのアプリケーションソフトウェア環境（オペレーティングシステムやライブラリなど）のダウンロードの時間、第三に、データ構造やライブラリの読み込みと初期化など、アプリケーション固有の起動タスクの実行時間です。リソースのスケジューリングと初期化は、分離された実行環境の作成と VPC および IAM ポリシーの設定により、大幅なレイテンシとオーバーヘッドが発生する可能性があります。

3）ネットワークの課題

クラウドファンクションは、ブロードキャスト、集約、シャッフルなどの一般的な通信プリミティブで大きなオーバーヘッドが発生する可能性があります。

4）セキュリティの課題

サーバーレスアーキテクチャはセキュリティ責任を再分配し、その多くをクラウドユーザーからクラウドプロバイダーに移行しますが、根本的に変更するわけではありません。ただし、サーバーレスアーキテクチャには、アプリケーションの分解とマルチテナントリソースの固有リスクも存在します。

5）コンピュータアーキテクチャの課題

クラウドを支配する x86 マイクロプロセッサの性能向上が遅いという問題があります。

もちろん、ここで説明したサーバーレスアーキテクチャが直面する課題は比較的抽象的です。現在の業界の実際の状況としては、これらの課題は依然として広く存在しており、多くのクラウドプロバイダーが継続的に取り組んでいる方向でもあります。サーバーレス開発者の視点から、上記の課題と開発者が最も関心を持ついくつかの問題を組み合わせると、現在のサーバーレスアーキテクチャが直面する課題は、コールドスタート問題、ベンダーロックイン、不完全なサポートリソースなどに限定されないことが導き出されます。

1 コールドスタート問題

コールドスタート問題とは、サーバーレスアーキテクチャが弾力的にスケーリングする際に、環境の準備（ワークスペースの初期化）、ファイルのダウンロード、環境の設定、コードと設定の読み込みを含む、完全なインスタンス起動プロセスがトリガーされる可能性があることを指します。その結果、本来ならミリ秒または数十ミリ秒で取得できるレスポンスが、数百ミリ秒または数秒でしか取得できなくなり、ビジネス処理速度に影響を与えます。

前述の通り、すべてのことには二面性があります。サーバーレスアーキテクチャには弾力的スケーリングのメリットがある一方で、サーバーフルアーキテクチャと比較して新たな問題が導入されました。それがコールドスタートです。サーバーレスアーキテクチャでは、開発者がコードを提出した後、プラットフォームはそれを永続化するだけで、実行環境は事前には準備されません。そのため、ファンクションが最初にトリガーされる際、環境を準備する比較的長いプロセスが発生します。このプロセスには、ネットワーク環境の確立や、必要なファイル、コード、その他のリソースの準備が含まれます。

この環境の準備からファンクションの実行までのプロセスが、ファンクションのコールドスタートと呼ばれます。サーバーレスアーキテクチャは弾力的なスケーリング機能を備えているため、サーバーレスプロバイダーはトラフィックの変動に応じてインスタンス数を増減させます。そのため、プラットフォームは新しい環境の準備、ファンクションコードのダウンロード、インスタンスの起動を頻繁に行い、新たに発生するリクエストに対応する必要があります。

Figure 7 に示すように、サーバーレスアーキテクチャの FaaS プラットフォームのファンクションがトリガーされると、FaaS プラットフォームは状況に応じてインスタンスを再利用するか、新しいインスタンスを起動します。

Figure 8 に示すように、再利用条件を満たすアイドルインスタンスが存在する場合、FaaS プラットフォームはそれを優先的に使用します。このプロセスがいわゆるホットスタートプロセスです。そうでない場合、FaaS プラットフォームは新しいインスタンスを起動してリクエストに応答します。これが対応するコールドスタートプロセスです。

サーバーレスアーキテクチャのこの自動ゼロ管理スケーリングは、すべてのワークロードを処理できる十分なコードインスタンスが揃うまで継続されます。

「新しいインスタンスの起動」には、ワークスペースの初期化、ファイルのダウンロードと環境の設定、コードと依存関係の読み込み、ファンクションインスタンスの起動といったいくつかのステップが含まれます。ミリ秒または数十ミリ秒のホットスタートと比較して、コールドスタートの追加ステップは数百ミリ秒、場合によっては数秒かかる可能性があります。本番環境で新しいインスタンスが起動する際にこの状況が発生し、ビジネスレスポンス速度に影響を与えます。コールドスタートの影響が最も懸念される点です。Figure 9 に示す通りです。

まとめると、コールドスタート問題の一般的なシナリオを分析してまとめることは難しくありません。

ファンクションの初回起動：デプロイ後のファンクションの最初の起動は、通常、既存のインスタンスが存在しないため、コールドスタートが発生しやすくなります。

リクエストの同時実行：リクエストが完了する前に新しいリクエストを受信すると、FaaS プラットフォームが新しいインスタンスを起動して新しいリクエストに応答し、コールドスタート問題が発生します。

2 回のトリガー間の間隔が長すぎる：2 回のトリガー間の間隔がインスタンスリリース時間のしきい値を超えると、ファンクションのコールドスタート問題が発生します。現在、サーバーレスアーキテクチャが直面するコールドスタートの課題は深刻ですが、致命的ではありません。各クラウドプロバイダーは、インスタンスの事前ウォーミング、インスタンス予約、リソースプーリング、単一インスタンスでの複数同時実行など、コールドスタート問題の解決策を導入しようとしています。

2 ベンダーロックイン

ベンダーロックインとは、各プロバイダーが提供するサーバーレスアーキテクチャの形式が異なっていることを指します。これには、製品形式、関数のディメンション、イベントデータ構造などが含まれます。あるプロバイダーのサーバーレスアーキテクチャを使用すると、通常、FaaS 部分と対応するサポートバックエンドインフラも同じプロバイダーのものを使用する必要があり、マルチクラウドでのデプロイやクラウド間でのプロジェクト移行などが困難になり、コストが非常に高くなります。

ご存知の通り、ファンクションはイベントによってトリガーされるため、FaaS プラットフォームとサポートインフラサービス間で合意されたデータ構造が、ファンクションの処理ロジックを決定づけることがよくあります。同じタイプのトリガーでも、各プロバイダーが合意するイベント構造が異なると、マルチクラウドデプロイやクラウド間でのプロジェクト移行に莫大なコストが発生します。

開発者が関数を開発し、異なるクラウドプロバイダーが提供するサーバーレスアーキテクチャで実装する場合、コードロジックや製品能力が異なり、ビジネスロジックや運用保守ツールも完全に異なることがあります。

そのため、プロバイダー間でのビジネス移行やマルチクラウドデプロイを行う場合、企業は高い互換性コスト、ビジネスロジックの変換コスト、複数プロダクトの学習コスト、データ移行リスクなどに直面します。

現在、すべてのクラウドプロバイダーが従う完全で統一された仕様が存在しないため、各プロバイダーのサーバーレスアーキテクチャは自社の製品やビジネスロジックと密接に結びついており、開発者にとってクラウド間のディザスタリカバリやクラウド間移行は非常に困難です。現在、クラウドプロバイダーによるサーバーレスアーキテクチャの深刻なロックイン問題は、開発者が最も不満を持ち、最も懸念している問題の一つでもあります。

もちろん、この問題に関して、CNCF などの組織やチームは、上位レベルでより標準化された科学的な方法で改善と対処を進めています。

3 不完全なサポートリソース

サポートリソースが不十分とは、サーバーレスアーキテクチャの核心的な考え方の一つが、より多くのことを、より専門的なクラウドプロバイダーに委託することであるにもかかわらず、実際には、需要の優先度や自社のビジネス品質などの問題により、クラウドプロバイダーはサーバーレスアーキテクチャで行うべき多くの作業を十分に増やすことができない場合があることを意味します。これにより、開発者はサーバーレスアーキテクチャに基づくプロジェクト開発やアプリケーション運用保守で多くの困難に直面し、不満を募らせています。

サーバーレスアーキテクチャの急速な発展の中で、各プロバイダーはサポートリソースと施設の充実に努めています。しかし、サーバーレスアーキテクチャには依然として多くのサポートリソースが不十分であり、開発者がサーバーレスアプリケーションの開発をよりスムーズに完了し、サーバーレスアプリケーションをより簡単に運用保守できない状況にあります。主に以下の点が挙げられます。

1) サポート開発ツールが複雑で多様であり、機能が不足している

一方では、市場で開発者ツールチェーンが不足しており、開発とデプロイが困難で、コストが増加しています。他方では、関連ツールチェーンの不足が、体験レベルでのサーバーレスの改善をさらに妨げています。高品質なツールチェーンの欠如は、プロバイダーロックインを懸念するサーバーレス開発者にとって、プロバイダーとのロックイン解除をさらに困難にしています。

2020 年に発表された第 1 回 Cloud Native User Survey Report では、サーバーレスアーキテクチャの使用前に、ユーザーの 49% がデプロイコストを、26% がプロバイダーのロックインを、24% が関連ツールセットの完全性を考慮していたことが明確に指摘されています。

これらのデータの背後にある事実は、開発者がツールチェーンの改善を強く求めているということです。現状では、完全に統一され、一貫性のあるサーバーレス開発ツールは存在しません。各プロバイダーには独自の開発者ツールがあり、使用形態や動作が異なります。これにより、開発前の調査、開発中のデバッグ、デプロイ後の運用保守において、深刻な課題が生じています。

さらに、大半のサーバーレス開発ツールは、開発ツールや運用保守ツールというより、リソースオーケストレーションとデプロイメントツールに近いものです。特に、デバッグではオンラインとオフライン環境の整合性が保証できません。運用保守では、ビジネスを迅速にデバッグできず、エラーをより簡単に確認できるようにすることができず、問題特定のための統一された完全なソリューションがありません。これにより、開発者のサーバーレスアーキテクチャの学習と使用のコストが高くなっています。

2) サポートドキュメントと学習リソースが不十分で、学習コストが高すぎる

現状では、サーバーレスアーキテクチャの学習リソースは比較的不足しています。テキスト、ビデオ、実験、ケースの観点や、プロバイダーが提供するチュートリアル、ベストプラクティスの観点から、包括的な学習リソースや参考ケースがありません。サーバーレスの学習リソースが少なく、開発経験のケースも少ないため、開発者は学習段階で適切な学習リソースを見つけるのが困難です。開発プロセスでは未知のエラーに頻繁に遭遇し、サーバーレスアーキテクチャに対する開発者側の意識構築を阻害しています。

もちろん、上記の側面はサーバーレスアーキテクチャのサポートリソースと施設の不十分さの一部に過ぎません。さらに、サーバーレスアーキテクチャと従来のフレームワークをどのように緊密に統合するか、従来のビジネスをどのように簡単にサーバーレスアーキテクチャに移行するか、サーバーレスアーキテクチャの監視とアラームをどのように行うか、サーバーレスアプリケーションとサーバーレスリソースをどのように管理するか、サーバーレスアーキテクチャの科学的なリリースと運用保守のベストプラクティスは何か、といった課題も、引き続き研究と探求が必要です。

現在も、サーバーレスアーキテクチャには多くの課題がありますが、誰もがより優れた体験を通じて、ユーザーがビジネスコードをより簡単に、より迅速にサーバーレスアーキテクチャにデプロイできるように支援しています。たとえば、Alibaba Cloud のサーバーレスチームが開発したオープンソースの Serverless Devs は、ベンダーロックインのないサーバーレスアプリケーションライフサイクル管理ツールです。

図に示すように、Serverless Devs は Alibaba Cloud のファンクションコンピューティングコンポーネントを例にとると、プロジェクト作成、開発、デバッグ、デプロイ、運用保守の全プロセスに参加できます。

Figure 10 Serverless Devs プロジェクトのフルライフサイクル管理のサーバーレスアプリケーション概略図

• プロジェクト作成フェーズでは、開発者ツールまたはアプリケーションセンターを通じてプロジェクトを初期作成できます。

• プロジェクト開発フェーズでは、ローカル開発やデバッグなどの機能を通じて、ローカル開発の正確性を検証できます。

• プロジェクトデバッグフェーズでは、ローカルデバッグ、リモート呼び出し、ログクエリなどの機能を通じて、プロジェクトの最終デバッグを行えます。

• プロジェクトデプロイメントフェーズでは、まず依存関係のインストールやプロジェクトビルドなどのプロセスを通じて完全なデプロイメントパッケージを構築し、その後プロジェクトをデプロイします。

• 運用保守フェーズでは、インデックスクエリを通じてプロジェクトの健全性を確認し、ログクエリを通じて問題を特定し、プロジェクト公開などの機能を通じてバージョン、エイリアス、グレースケールを公開できます。

さらに、学習リソースの面でも強力なサポートがあります。Figure 11 は Alibaba Cloud デベロッパーコミュニティが提供する多数のサーバーレス関連コースを示しています。（2021 技術アトラス）

Figure 11 Alibaba Cloud デベロッパーコミュニティが提供する多数のサーバーレス関連コース

その後、「サーバーレス実践戦略」などの一連のコースも用意されており、継続的なご注目をお待ちしています。

4 その他の課題

サーバーレスアーキテクチャは現在非常に人気があり、各プロバイダーは自社のサーバーレス製品の改善と、サーバーレスのエコシステムおよびマインド構築の推進に力を入れています。しかし、客観的に言えば、サーバーレスアーキテクチャが直面する課題は前述のものだけではありません。

1) サーバーレスアーキテクチャはセキュリティ面でより大きな課題に直面する可能性があるか

より専門的なことをより専門的な人に任せることで、サーバーレスアーキテクチャはより強力なセキュリティ保証を得られます。しかし、サーバーレスアーキテクチャの極めて高い柔軟性のため、開発者はより多くの懸念を抱いています。「もし誰かが悪意を持ってビジネスを攻撃した場合、サーバーレスアーキテクチャの極めて高い柔軟性と従量課金制により、短時間で莫大な損失が生じるのではないか。」これは従来の仮想マシンが示す「サービス提供不能」とは異なり、開発者にとってより深刻な懸念事項です。

多くのプロバイダーは、API ゲートウェイのホワイトリスト/ブラックリスト機能や、ファンクションコンピューティングなどの関連機能のインスタンスリソース上限設定を通じてこの問題に対処していますが、多くの開発者は依然として懸念を抱いています。

2) エラーの発生 - 感知とトラブルシューティングが困難

サーバーレスアーキテクチャは従来の仮想マシンアーキテクチャよりも「ブラックボックス」的な性質が強いため、サーバーレスアーキテクチャでのアプリケーション開発時に感知しにくいエラーがしばしば発生します。

たとえば、経験の浅いサーバーレスアプリケーション開発者がオブジェクトストレージトリガーを使用する際に、深刻なサイクルトリガー問題に直面する可能性があります。具体的には、「クライアントがオブジェクトストレージに画像をアップロードし、オブジェクトストレージトリガーファンクションが画像圧縮操作を実行し、結果の画像をオブジェクトストレージにライトバックします。ここのトリガー条件が適切に設定されていないと、圧縮とライトバック操作のサイクルトリガーを引き起こす可能性があります。」感知しにくいエラーのほかに、サーバーレスアーキテクチャはトラブルシューティングの難しさという課題にも直面しています。ユーザーがローカルでビジネスロジックを開発・デバッグし、コードをオンラインにデプロイした後に偶発的なエラーが発生することはよくあります。このとき、ユーザーはマシンにログインしてデバッグできず、インスタンスもトリガー後にリリースされる可能性があるため、問題の特定と原因追跡が困難になります。

まとめると、サーバーレスアーキテクチャのメリットと同様に、サーバーレスアーキテクチャが直面する課題の多くは前述の通りですが、その一部は既に解決されています。このシリーズの記事では、その解決方法も紹介していきます。サーバーレスアーキテクチャは多くの課題に直面していますが、これらの課題はより多くの組織やチームに新たな機会をもたらすでしょう。