ビデオを撮って、ビデオトランスコーディングシーンでの関数計算とコンテナの組み合わせの優れたパフォーマンスを見てみましょう。クリックしてビデオを見る>>
FaaSのしきい値
サーバーレスクラウドサービスは、開発者が拡張と縮小、運用と保守、容量計画、クラウド製品の統合などの多数の複雑な責任を引き受けるのに役立ち、開発者がビジネスロジックに集中し、配信速度（市場投入までの時間）を延ばし、継続できるようにします。コストを最適化します。Function-as-a-Service（FaaS）は、クラウド上で最も早く、最も広く使用されているサーバーレスコンピューティングフォームとして、数年で多くの開発者を魅了し、「サーバーレス」の最適な選択ロジックを徐々に確立してきました。ただし、従来のアプリケーションからFaaSへの移行は、開発者のエクスペリエンスにおいて依然として多くの課題に直面しています。
- 環境が均一ではない：さまざまなメーカーによって定義された成果物の形式、動作環境の互換性と豊富さは同じではなく、開発者は適応するか、再コンパイルする必要があります。
- 学習コスト：依存ライブラリのパッケージ化、圧縮コードパッケージへの組み込み、使い慣れた開発および展開方法は異なります。
- サービスの制限：たとえば、コードパッケージは100MBに制限されているため、成果物のコードの依存関係を分離する必要があり、管理とリリースの難しさが増します。
- 成果物にはバージョン管理がありません。形式は標準ではなく、ベストプラクティスは統一されていません。開発者は責任を負う必要があります。
- 生態学的な未熟さ：人気のあるオープンソースツール（CI / CDパイプラインなど）のサポートと統合の欠如。
一方、コンテナは、携帯性と配信の俊敏性において破壊的な革新を実現しました。コンテナを取り巻く生態学的な降水量は非常に豊富で成熟しており、広く受け入れられ、使用されています。アプリケーションのコンテナ化は、開発と展開の事実上の標準に急速になりつつあります。ただし、コンテナ自体は、運用と保守、拡張と縮小、アイドルコスト、およびクラウドサービス統合の問題を軽減しません。したがって、FaaSとコンテナエコロジーの統合を実現することで、開発者はより多くの技術的利益を得ることができます。
関数コンピューティングはコンテナミラーリングをサポートします
アリババクラウドファンクションコンピューティング（略してFC）は、コンテナイメージを機能成果物としてサポートするようになり、コンテナの優れた開発、展開、エコロジーを上线前、無料の運用と保守、アイドルコストゼロ、クラウドサービス統合などのファンクションコンピューティング独自の機能に統合します（上线后） 、開発者エクスペリエンスを完全にアップグレードします。
- サーバーレスのアプリケーションを簡素化：コードを変更したり、バイナリ、共有オブジェクト（* .so）、ローカルデバッグを再コンパイルしたりする必要がなく、開発とオンライン環境の一貫性を保ちます。
- より大きな機能コードの制限：解凍前のイメージは最大1 GBをサポートし（コードパッケージの解凍前の最大50 MBと比較して）、コードと依存関係の分離を回避し、配布と展開を簡素化します。
- コンテナイメージの階層キャッシュ：増分コードのアップロードとプル、開発効率の向上、コールドスタートの遅延の削減。
- ミラーの共有と再利用：ロジックを移植できるため、開発と構築の繰り返しを減らすことができます。
- ハイブリッド展開：同じアプリケーションServerfull（ECS、コンテナACK）、Serverless（FC、ASK、SAE）、異なるアプリケーションの混合展開、または同じアプリケーションの異なるサービス間の切り替え、一貫したパフォーマンス、リソースの厳格な提供、迅速な拡張、最小限の操作とメンテナンスの実現残高
- CI / CD：継続的な構築、統合テスト、コードアップロード、ストレージ、および標準バージョン管理。豊富なオープンソースのエコロジカルCI / CDツールを再利用できます。
典型的な顧客シナリオ
A.イベント駆動型のオーディオおよびビデオ処理
大きなトラフィック変動、コンピューティングリソースの弾力性に対する高い要件、ビデオアップロードイベントの監視、ワークフローやキューなどのサービスへの依存など、オーディオおよびビデオ処理の特性により、FaaSはクラウドへの自作のオーディオおよびビデオサービスの最初の選択肢となっています。ただし、このようなシナリオで最も一般的に使用されるソフトウェアであるFFmpegでは、さまざまなニーズを満たすためにカスタムコンパイルが必要になることがよくあります。コンパイルされたバイナリは、コンパイル環境の共有オブジェクト（* .so）やglibcなどのライブラリに依存し、FaaSランタイム環境と互換性がなく、実行できません。再コンパイルすると、余分な作業が発生するだけでなく、依存関係やバージョンが異なると、ビジネスの安定性に課題が生じます。以下の例に示すように、既存のDockerfileを使用して、既存のインストール方法と、ロジックおよび関連する依存関係をトランスコーディングするための完全に分離されたコンテナサンドボックス操作環境を維持します。これにより、移行コスト、安定性リスク、およびFaaSの開発と展開の学習コストが大幅に削減されます。
B.サーバーレスAI / MLモデル予測、推論サービス
AI / ML推論および予測サービスは、FaaSの無料の運用と保守、自動スケーリング、および低コストのメリットも享受できます。ただし、TensorFlowなどのコミュニティで人気のあるフレームワークは、デフォルトでコンテナイメージの形式で共有および再利用されます。オフィシャルは完全なバージョンを提供するだけでなく、オフィシャルミラーに基づくコミュニティエコロジーも非常に活発です。オフラインモデルトレーニングフェーズでは、コンテナイメージとしてECSまたはACK / ASKGPUクラスターにデプロイされます。サービングの推論/予測段階では、CPUがより費用効果の高い選択肢であることがよくあります。サービングは、バーストトラフィックに迅速に対応するだけでなく、トラフ期間中にリソースを解放するか、コストを節約するために容量をゼロに減らす必要がある需要主導型を特徴としています。これらの要件は、当然、関数コンピューティングが得意なものです。
コンテナイメージのサポートがなくなる前は、関数コンピューティングでサービスを提供するTensoflowFlowの例を展開するのは簡単ではありませんでした。TensorFlow自体のライブラリのサイズは、コードパッケージの50 MBの制限をはるかに超えています。依存関係をNASにパックすると、この問題を回避できますが、開始と移行が難しくなります。不規則な依存関係とバージョン管理も、変更に安定性のリスクをもたらします。コンテナイメージと関数コンピューティングHTTPサーバープログラミングモデルを使用して、Dockerfileの数行をFCで実行できます。TensorflowServingの例：
関数コンピューティングは、コンテナミラーリングをサポートして、AI / MLシナリオがコンテナと関数をスムーズに混合および展開し、CI / CDツール、プロセス、およびベストプラクティスを統合するのに役立ちます。運用と保守のない機能コンピューティング、高い同時実行性、100ミリ秒レベルのインスタンス拡張、および100％のリソース使用率により、サービスの品質とコストがさらに最適化されます。
C.従来のWebモノリシックHTTPアプリケーションのサーバーレス進化
従来のWebモノリシックアプリケーションの最新化には、責任の分割、運用と保守のプレッシャーの軽減（リソース計画、システムアップグレード、セキュリティパッチ、およびその他の運用と保守の負担）、およびコストの最適化という3つの主要な要求があります。単一の職務の機能を採用することはベストプラクティスですが、職務を分割するための設計とリファクタリングに時間がかかることがよくあります。機能コンピューティングのミラーリングサポート機能の助けを借りて、単一のアプリケーションをFaaSサービスに簡単に移行して、無料の運用と保守、柔軟な水平拡張、および100％のコスト効率の要件を満たすことができます。
歴史的な理由やビジネスの複雑さのために、従来のWebアプリケーションのオペレーティング環境（コンテナミラーリング）とビジネスロジックは、多くの場合、高度に結合されており、分離にはコストがかかります。サーバーレス変換の場合、オペレーティングシステムと依存ライブラリのバージョンをアップグレードし、FaaSベンダーが提供する環境で再コンパイルする必要がある場合があります。サーバーレスアーキテクチャへの移行には、時間コストと安定性のリスクがあります。コンテナミラーリングに対するファンクションコンピューティングのサポートにより、従来のコンテナ化されたWebアプリケーションは、変更なしでサーバーレスの価値をより速く享受し、バージョン管理、アップグレードメンテナンス、および容量に依存して、繰り返しの退屈な環境ではなく、ビジネスロジックの革新と反復に時間とエネルギーを集中させることができます。計画とスケーリング。
D.クラウドのオンとオフ、クラウドベンダー間のハイブリッド展開
エンタープライズクラウドの移行のペースは加速していますが、ビジネスの特性上、プライベートクラウドとパブリッククラウドのハイブリッド運用は、今後長い間標準となるでしょう。企業は、移行、耐災害性、およびリソースの厳格な提供の要件を確保するために、マルチクラウドベンダーさえ必要としています。コンテナミラーリングは、クラウドの内外で統合されたソフトウェア成果物のデフォルトの選択です。関数コンピューティングのカスタムランタイムはHTTPサーバーの標準的な対話方法を選択し、関数コードのプログラミング方法はベンダーに関連付けられていないため、クラウドベンダーロックイン（ベンダーロックイン）、クラウド上で実行できる関数、さらにはクラウド下の他の機能に関する企業の懸念が緩和されます。クラウドベンダーは、リクエストを処理するための独立したHTTPWebアプリケーションとして個別に展開することもできます。コンテナパッケージ機能は、他のクラウドサービスのコンテナサービスまたはIaaS自作サービスで実行して、マルチクラウドの耐災害性と柔軟なリソース保護を実現できます。
E.コールドスタートのベストプラクティス
FaaSコードパッケージの成果物は、ビジネスロジックを実行環境から分離し、ビジネスロジックを実行するためにロードする必要のあるデータの量を最小限に抑え、コールドスタート速度を最大限に最適化します。コンテナイメージは、動作環境とビジネスロジックの統合された配信であり、移植性とコールドスタート速度の間でトレードオフを行います。カスタム操作環境を導入すると、必然的に追加のコールドスタート遅延が増加します。このため、次のコールドスタート最適化のベストプラクティスをお勧めします。
- コンテナイメージアドレスは、関数計算と同じ領域でVPCイメージアドレスを使用することをお勧めします。たとえば
registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1、最適なイメージプル遅延と安定性を取得します。 - docker-slimなどのツールを使用して必要な依存関係とコードのみを保存し、不要なドキュメント、データ、またはその他のファイルによって引き起こされる余分な遅延を回避して、ミラーリングを最小限に抑えます。
- リソースが許可され、スレッドセーフである場合、単一インスタンスの複数の同時実行でリソースを使用すると、不要なコールドスタートを回避し、コストを削減できます。
- コンテナイメージは、コールドスタートを排除するために、予約済みインスタンスと一緒に使用されます。
F. DevOps / GitOpsのベストプラクティス
コンテナイメージのサポートにより、ビルド手順と機能の成果物が標準化され、CI / CDツールを再利用できるようになります。関数計算とAliクラウドクラウドエフェクトサービス統合DevOps、CI / CDラインを導入。次の図に示すように、新しいコードがコードリポジトリのマスターブランチ（Github / Gitlab）にプッシュされると、ビルドパイプラインタスクが開始されます。コードで指定されたDockerfileに従って、コンテナイメージがビルドされ、AlibabaCloudコンテナイメージサービスにプッシュされます。パイプラインの最後のステップでは、新しいバージョンの関数をデプロイしてリリースし、自動リリースを完了します。
次の図に示すように、クラウド効果DevOpsの完全に自動化された継続的な統合配信エクスペリエンスに加えて、Alibaba Cloud Container ImageServiceと自己構築のオープンソースCI / CDパイプラインを使用して機能リリースを自動化することもできます。関数計算の公開方法の標準化により、企業は統合ツールを使用して複数の異なるサービスを継続的に提供でき、開発および運用担当者向けの展開ツールの学習コストを削減し、展開を自動化して成功率と配信速度（市場投入までの時間）を向上させます。
カスタムランタイムとの類似点と相違点
ファンクションコンピューティングは2019年にカスタムランタイムカスタムランタイムを開始しましたが、今回リリースされたカスタムコンテナと既存のランタイムの類似点と相違点は何ですか？
- 機能コンピューティングシステムの同じプログラミングモデルと相互作用方法：同じHTTPサーバープロトコル、既存のカスタムランタイム関数は、コードを変更することなく、環境互換のカスタムコンテナ環境に直接移植できます。
- 2つのランタイムには、適用可能なシナリオとトレードオフが異なります。
- コンテナ化されていないアプリケーションの場合、カスタムランタイムを引き続き使用できます
- コールドスタート遅延の許容度が低いシナリオでは、カスタムランタイムを使用して画像のプル時間を節約することをお勧めします
- 非同期のオフラインタスクとコンテナ化されたタスク（ジョブタイプ）の場合、cutome-containerランタイムを使用することをお勧めします
- 機能コンピューティングの予約済みインスタンスと緊密に結合された展開環境およびビジネスロジックを使用するアプリケーションは、カスタムコンテナランタイムの使用を優先できます
将来の計画
コンテナが徐々にアプリケーションの配信と展開の標準的な方法になるにつれて、FaaSはコンテナエコシステムとより緊密に統合され、宣言的な展開方法などの周囲のサポートエコシステムの統合を含め、コンテナ化されたアプリケーションを低コストでサーバーレスにするのに役立ちます。 K8sは、アプリケーションの抽象化、クラウドネイティブの可観測性ソフトウェアの統合に似ています。
コンテナイメージのプルアクセラレーションに基づいて、関数コンピューティングは移植性と高速起動のパフォーマンスを考慮に入れることができます。コンテナテクノロジーとサーバーレスの本来の目的は、ユーザーがより迅速に（市場投入までの時間）を提供し、継続的にコストを最適化し、アイドル状態のリソースによって引き起こされる無駄を排除し、企業の競争力を高めることです。最終的に、クラウドネイティブの2つの主要な技術分野であるサーバーレステクノロジーとコンテナテクノロジーが近づき、開発、展開、運用、保守の違いが縮小し続けるため、開発者はビジネスロジックを変更して、さまざまなワークロードに適したものを選択することはほとんどできません。オープンで標準的な統合されたクラウドネイティブテクノロジーを使用して継続的に革新し、顧客により多くの価値を生み出す技術ソリューション。