サーバレス、CaaS、PaaSをどう使い分けるか:【完訳】CNCF Serverless Whitepaper v1.0(3)(1/2 ページ)
本連載では、Cloud Native Computing Foundationのサーバレスコンピューティングホワイトペーパーを完訳し、計5回の連載として掲載している。第3回は、コンテナオーケストレーション、PaaS、サーバレスの使い分け、および併用についての解説をお届けする。
【完訳】CNCF Serverless Whitepaper v1.0 連載バックナンバー
本連載では、サーバレスコンピューティング(以下、サーバレス)を解説したCloud Native Computing Foundation(CNCF)のServerless Working Groupによるホワイトペーパー、「CNCF Serverless Whitepaper v1.0」を完訳してお届けしている。
連載第3回は、アプリケーションに「コンテナオーケストレーション(Container as a Service)」「PaaS(Platform as a Service)」「サーバレス(Functions as a Service)」のいずれを使うかを選択する際の具体的な方法、および併用の可能性について説明した部分を掲載する(翻訳・構成:三木泉)。
どのクラウドネイティブデプロイメントモデルを採用すべきか
特定のニーズに最も適したモデルを判断するには、各アプローチ(および幾つかの実装)の徹底的な評価を行う必要があります。全てに当てはまる単一の解決策はないため、このセクションでは、考慮すべき点についていくつか提案します。
機能と能力を評価する
それぞれのアプローチを試してください。機能と開発エクスペリエンスの観点から、あなたのニーズに最適なものを探してください。あなたは次のような質問に対する答えを見つけようとしています。
- 前のセクションで説明した、サーバレスの価値が生かせるワークロードに、自身のアプリケーションが適合しているように見えるか? 変更に値する他の手段と比較して、サーバレスで大きなメリットを得られるか?
- ランタイムとそれが実行される環境に対するコントロールを、自身は実際にどの程度必要としているか? マイナーなランタイムバージョンの変更が自身に影響するか? デフォルトを上書きすることはできるか?
- 自身が使う開発言語で、機能およびライブラリをフルに活用できるか? 必要に応じて追加のモジュールをインストールできるか? 自身でのパッチ適用、あるいはアップグレードの必要があるか?
- 運用面でのコントロールがどの程度必要か? コンテナあるいは実行環境のライフサイクルについて、どの程度放棄するつもりか?
- サービスのコードを変更する必要があるとすればどうか? どの程度迅速に展開できるか?
- サービスを保護するにはどうすればいいか? それを管理する必要はあるか? それともより良いサービスにこれを任せられるか?
運用面の評価と測定を実施する
PaaSやコンテナオーケストレーターにおけるリカバリ所要時間や、サーバレスプラットフォームにおけるコールドスタート所要時間などのパフォーマンス数値を収集します。 次のような、アプリケーションの他の非機能的な重要特性が、各プラットフォームでどのような影響を受けるかを調べ、定量化します。
強靭性:
- データセンター障害に対するアプリケーションの耐性を高めるには、どうすればよいか?
- 更新プログラムをデプロイする際に、サービスの継続性を確保するには、どうすればよいか?
- サービスに障害が発生したらどうなるか? プラットフォームは自動的に回復するか? エンドユーザーが意識しないで済むか?
スケーラビリティ:
- 需要の急激な変化があった場合に備えて、プラットフォームは自動スケーリングをサポートしているか?
- 自身のアプリケーションはステートレスなスケーリングを効果的に利用するように設計されているか?
- 自身のサーバレスプラットフォームは、データベースなどの他のコンポーネントに圧倒的な負荷を掛けることになるか? バックプレッシャーを管理あるいは加速できるか?
パフォーマンス:
- 1インスタンス当たり、あるいはHTTPクライアント当たり、毎秒何回の関数呼び出しが行われるか?
- ワークロードには幾つのサーバまたはインスタンスが必要か?
- 呼び出しから応答(コールドスタート時およびウォームスタート時)までの遅延時間はどの程度か?
- 単一のデプロイメント内における他の機能(訳者注:データベースなど)とマイクロサービスの間の遅延は問題になるか?
CNCF Serverless Working Groupに今後期待できる成果の1つは、特定のモデルをいつ選択するか、そして推奨されるツールセットをどのようにテストするかを決定するためのフレームワーク策定です。 詳細については、結論のセクションを参照してください。
あらゆる潜在コストを評価して検討する
これには、開発コストとランタイムリソースコストの両方が含まれます。
- 誰もがアプリケーションを一から開発できるような恵まれた環境にあるわけではない。 従って、既存のアプリケーションをクラウドネイティブモデルのいずれかに移行するコストを、慎重に検討する必要がある。 コンテナへの「リフト・アンド・シフト」は最も安価に見えるかもしれないが、長期的にはコスト効率が最も良いとは限らない。 同様に、サーバレスのオンデマンドモデルはコスト面で非常に魅力的だが、モノリシックアプリケーションを関数に分割するために必要な開発努力は膨大なものになる可能性がある
- 依存サービスとの統合にはどれくらいの費用が掛かるか? サーバレスコンピューティングは、最初は最も経済的に見えるかもしれないが、より高価なサードパーティーのサービスコストが必要になるか、または非常に迅速な自動スケールが実行されるため、使用料金が高くなる可能性がある
- プラットフォームはどの機能/サービスを無償で提供しているか? 移植性について潜在的な犠牲を払ってでも、特定ベンダーのエコシステムを活用したいか?
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- コンテナ運用環境を標準化? CNCFは何をやろうとしているか
Cloud Native Computing Foundationは、クラウドネイティブアプリケーション開発・運用環境に関する技術の「標準化」を推進しているという。臨時エグゼクティブディレクターに、具体的な活動内容を聞いた。 - CNCFのCOOに聞いた、CNCFとOCI、Docker、Kubernetes、Cloud Foundryとの関係
コンテナの世界はダイナミックに動いている。Cloud Native Computing Foundation(CNCF)はこれにどのような影響をもたらそうとしているのか。同ファウンデーションCOOのChris Aniszczyk氏に、KubernetesのCRI-OプロジェクトからCloud Foundryとの関係まであらためて聞いた。 - コンテナストレージの共通仕様にも着手、あらためて、CNCFは何をどうしようとしているのか
CNCFは、クラウドネイティブアプリケーションの世界のデファクト標準を作り上げたいのか、それともコンポーネントベースでCloud Foundryの競合勢力を構築したいのかが、分かりにくい部分がある。そこでCNCFのエグゼクティブディレクターであるダン・コーン氏と、COOであるクリス・アニズィック氏に、あらためて同組織のやろうとしていることを聞いた。 - AWSは「インフラを意識しないアプリ運用環境」を進化、コックロフト氏は「オープン」を約束
Amazon Web Services(AWS)は、2017年11月末から12月初めにかけて開催したAWS re:Invent 2017で、Amazon ECS for Kuberneteや「Fargate」、さらにサーバレスコンピューティングの「AWS Lambda」における機能強化などを発表した。こうした発表から見えてくるものは、インフラを意識しない運用環境の進化だ。