サーバーレスの実装と課題

翻訳者 |徐磊

校正：孫淑娟

このシリーズの最初の記事では、サーバーレスがクラウド コンピューティングの未来であると考える理由について説明しました。クラウド コンピューティングの進化を検討し、サーバーレス モデルに移行した現在のユースケースをいくつかリストしました。この記事では、サーバーレスを実装する方法と、実装プロセス中に遭遇する課題について詳しく説明します。最後に、議論の要約とビジョンの展望でシリーズを終了します。

チャレンジ

より純粋なサーバーレスの世界に移行すると、最新のワークロードを実行するときに発生する多くの問題が解決されますが、多くの課題も生じます。この記事では、これらの課題をクラウドの最適化、サービス設計、機能とワークフロー、セキュリティの問題という 4 つのカテゴリに分けて、個別に説明します。それぞれの大まかなカテゴリ内で、重要であり、完全に対処する必要がある具体的な問題をリストアップしました。これらは包括的ではありませんが、サーバーレス コミュニティのロードマップの基礎となると確信しています。

チャレンジ概要

クラウドコンピューティングの最適化

サーバーレスは、サービスのニーズに合わせてコンピューティング リソースを割り当てるのに適しています。サービスの需要が増加すると新しいコンピューティング リソースを割り当て、需要が減少すると関連するコンピューティング リソースを解放します。ここでのコンピューティング リソースの割り当てと解放のオーバーヘッドは、サーバーレス アプリケーションのデプロイ後に発生する最も重要な問題の 1 つになる可能性があります。

サーバーレス サービス (関数、コンテナー、またはワークフローを実行するコンテナーのグループ) では、コンピューティング リソースのスケールアップとスケールダウンにコストがかかります。このコストは、サーバーレス サービスのライフサイクルのすべての段階で発生するため、かなりの額になる可能性があります。 Kubernetes を含むほとんどのクラウド テクノロジーは、サービス リソースのプロビジョニングを考慮して設計されています。サーバーレス モードでは、実行中のインスタンスの変更によるオーバーヘッドを削減することで、より動的なユースケースを最適化することを検討する必要があります。たとえば、Kubernetes は、サービス需要が変化するたびにコストとエネルギー消費が最小限に抑えられるように、オーバーヘッドを最小限に抑えて Pod レプリカの追加を最適化する必要があります。

一方、需要の増加に応じてコンピューティング リソースを増加する過程では、サービス遅延が発生する可能性があることに注意する必要があります。追加のリソースが割り当てられるのを待っている間、サービスの待ち時間が増加します。極端なケースでは、まだリソースが割り当てられていないサービスにリクエストが到着すると、コールド スタート時間によってリクエストに大きな影響が出る可能性があります。 「Knative によるコールド スタート時間の短縮」で説明したように、最悪の場合のサービス起動時間は秒単位で測定されますが、リクエスト応答時間は通常数十ミリ秒です。複数の独立した拡張機能で構成されるサーバーレス ソリューションを作成する場合、コールド スタートの影響は非常に大きいため、考慮する必要があります。この問題をさらに改善するには、クラウド テクノロジーをさらに最適化する必要があります。

最後に、Kubernetes と Knative は、エネルギーと財務の節約に対応する潜在能力を最大限に引き出すために最適化する必要があります。ポッドの割り当てとクラスター制御は、他のワーカー ノードのサブセットに対する動的な調整 (デフラグ) をサポートするように開発する必要があります。これにより、クラスター リソースの全体的な需要が増加したときに、アイドル ノードを一時停止し、再開できるようになります。

サービスデザイン

サーバーレス アプリケーションまたはソリューションを作成する場合の主な課題の 1 つは、イベント ドリブンの考え方でアプリケーションとサービスを設計すること、つまり、アプリケーションで実行されるイベントと全体的なソリューションのさまざまな部分を理解することです。これらのイベントは、アプリケーション ドメインに関するビジネス上の理解から生じるものであり、明示的に抽出する必要があります。たとえば、休暇予約システムなどのビジネス プロセス アプリケーションには、アプリケーション全体の使用を促進する明確なイベントが存在します。顧客が休暇を計画する際、場所、フライト、ホテル、レンタカー、食事、その他のアクティビティなど、一連のオプションを順番に選択して予約する必要があります。プロセス全体は、サービスとそれらの間を流れるイベントに分解できます。企業はアプリケーションをマイクロサービスとして設計しており、この分解と設計もよく知られています。

サーバーレスのイベント駆動型アーキテクチャは、さまざまなサービスをトリガーするためにイベント (内部または外部) を追加するだけであり、リクエストを処理していない場合はイベントをゼロに減らすことができます。このアーキテクチャの利点を最大限に活用するには、サービスを駆動するイベントを外部化して、サーバーレス コンポーネント メッシュでワークフローをトリガーできるようにする必要があります。サービスは動的に拡張できるため、前述の問題が発生します。つまり、コールド スタートの潜在的な影響を考慮する必要があり、また、適切に表示され、応答性の高いユーザー インターフェイスも必要になります。

イベント駆動型アーキテクチャにも対処しなければならない独自の課題がありますが、そのほとんどは適切なイベント ブローカー、トリガー、イベント モデルを選択することで解決できます。また、アプリケーションが注意する必要がある落とし穴もいくつかあります。特に、イベント ストームや、一定期間後にイベントが減少したり機能しなくなったりする問題です。上記のすべてを、サーバーレス設計と呼びます。

機能とワークフロー

AWS が 2014 年に Lambda サービスを開始したとき、最初に導入されたモデルは純粋な関数型プログラミング モデルでした。サービスは、さまざまな言語やライブラリで定義された関数として実装されます。その後、Knative はより一般的なモデルを提案しました。Lambda 関数のようにコンテナ中心で、実行はイベント トリガーに基づいており、サービスの需要 (リクエスト) の変化に応じてリソースの規模が増減します。その後、Knative は独自の関数型プログラミング モデルである Knative function を立ち上げました。

さまざまなサーバーレス テクノロジーの共存はイノベーションに非常に役立ちますが、標準がないため、結局は互換性がなく、互換性の課題はネットワーク境界で解決されます。まず、コンテナ イメージの形式と実行は Kubernetes コミュニティによって定義されています。最も重要なことは、多くのサーバーレス プラットフォームのイベント モデルが、非常に重要な標準であるクラウド イベント標準に基づいていることです。これにより、ワークロードがクラウド間で連携、共同作業、実行できるようになります。 Kubernetes は、必要な共通の実行プラットフォームと、そのプラットフォーム上でのサーバーレスの共通定義を提供します。

最後の課題は、サーバーレス サービス間の調整フローの共通の説明を提供することです。シンプルなサーバーレス ソリューションを作成するには、トリガー、イベント ソース、さまざまなサービスからのイベント集約だけでなく、さまざまなサービス間の調整も必要です。さまざまなプロセス言語、つまりパイプライン言語には部分的なソリューションがありますが、それらは同期ポイントを持つ任意の複雑なグラフ用に設計されていません。完全なワークフロー言語が必要です。この言語は Tekton の進化形、あるいは少なくともそのスーパーセットである可能性があります。

秘密の質問

新しいテクノロジーが登場するたびに、サイバーセキュリティの新たな課題が生まれることがよくあります。サーバーレス テクノロジーの出現により、この状況は変化しました。特に、需要を満たすためにコンピューティング リソースがどこでどれだけ使用されるかを制御する制御が、ユーザー側からクラウド自動化に移行されるようになったためです。ネットワーク境界が消滅すると、関連するセキュリティ制御の多くも消滅します。さらに、サーバーレスによって低コストと簡素化された運用が実現し、多くのワークロードがより細かいセルフサービス サービスに分割されるようになります。ワークロードの断片化が進むにつれて、攻撃者にとっての攻撃対象領域も拡大します。

Knativeコミュニティが新たなサイバーセキュリティの課題にどのように対応しているか

• 導入されたサービスの更新の効率と速度を向上

Knative は、サービス変更を支援する基本機能を提供し、サービス変更プロセス中のトラフィック分割をサポートしているため、変更されたバージョンの反復中にサービスがスムーズかつリスクなく移行できます。進化する脅威や新たに発見された脆弱性のリスクを軽減するために、より頻繁な更新をサポートします。

• 恣意的なサービス構成を避ける

Knative 自動デプロイメントにより、サービスに必要なすべての Kubernetes リソースが単一のサービス リソースから取得されることが保証されます。違反者または内部担当者によるリソースの手動変更は、意図的であるかどうかに関係なく、Knative によって自動的に上書きされ、恣意的な構成変更が回避されます。

• 恣意的なインフラストラクチャ構成を避ける

Knative は Kubernetes を使用して Knative の基盤となるコンポーネントを管理しますが、サーバーレス インフラストラクチャへの手動変更はサポートしていません。

• 安全行動の監視と管理

Knative コミュニティは、デプロイされたサービスの動作とそれらのサービスに送信されるイベントを監視するための新しい手法を導入しています。 Security Guard は、脆弱なサービスをゼロデイ脆弱性や既知の脆弱性から保護するために、各サービスに合わせてカスタマイズされたランタイム セキュリティ保証です。このテクノロジーは、サービスが悪用された場合に対応するためのメカニズムも提供します。

要約する

クラウド コンピューティングは成長を続けており、世界のエネルギー消費において重要な役割を果たしており、国際エネルギー機関の推定によると、2021 年には世界のエネルギー消費の 1 ～ 1.5%、二酸化炭素排出量の 1% を占めることになります。 Kubernetes は、ワークロードのデプロイと管理の方法を標準化します。 Knative は、サーバーレスと高効率性をさらに一歩進めています。これにより、より環境に優しいクラウド コンピューティングが実現し、クラウド サービス プロバイダーとクラウド ユーザーのコストが大幅に削減されます。このサーバーレス モデルは、すべてのワークロードに適しています。効率性の向上は、個々のワークロードだけでなく、基盤となるクラウド リソースや、各ワークロードの実行によって消費されるエネルギーにも適用されます。

サーバーレスは、効率性に加えて、簡素化、自動化、バージョン管理、ネットワーク セキュリティの向上など、クラウド ユーザーにさらなるメリットをもたらします。ただし、これらにも課題があり、Kubernetes では実際の負荷に基づいてサービスを自動的にスケーリングする動的な特性をさらに最適化する必要があります。サーバーレスをより汎用的にし、より多くのユースケースのシナリオをカバーするには、まだやるべきことがたくさんあります。同様に、サーバーレス モデルを使用するには、ユーザーはワークロードとデプロイメント戦略も改善する必要があり、これには当然時間がかかります。

徐々にサーバーレス モデルに移行するにつれて、適用可能な新しいワークロードとユース ケース シナリオも考慮する必要があります。 AI、データ、機械学習のコミュニティは、オンデマンドでコンピューティング リソースを割り当てるこのモデルの価値を率先して認識しており、Kubeflow と Tekon は、データ集約型の AI パイプラインとワークロードをサーバーレス モードで設計および実行する良い例です。将来的に利用可能なその他のワークロードとユースケース シナリオには、量子コンピューターで量子アルゴリズムをオンデマンドで使用または実行できるようにする Quantum Serverless が含まれます。

サーバーレス モデルは、コストの削減とリソースの割り当ての経済性を実現します。アプリケーションはこれを目的として設計されており、プラットフォームはサーバーレス ソリューションを実行するのに効率的かつ経済的であるため、すべての関係者にとって理にかなっています。さらに、環境にも優しいという利点もあります。

謝辞

フィードバックとコメントを提供してくれた Paul Schweigert 氏と Lionel Villard 氏に感謝します。また、Kubernetes 用のサーバーレス プラットフォームの作成に貢献し、尽力してくださった Knative コミュニティ全体に感謝申し上げます。 2 年足らずの間に、コミュニティは 12 を超えるバージョンをリリースし、Kubernetes との互換性を維持しながらさまざまな側面を改善し、さまざまなイノベーションの拡張と実験を可能にしました。

翻訳者について

51CTO コミュニティの編集者であり、大手 e コマース会社の副技術ディレクターである Xu Lei 氏は、Java バックエンド開発、技術管理、アーキテクチャ最適化、分散開発などの分野に重点を置いています。

原題: ​​How do we make the future serverless?、著者: Michael Maximilien ​​、David Hadas、Angelo Danducci II、Simon Moser