サーバーレスでアプリケーション開発を最適化
アプリケーション開発を最適化するチャンス
仮想マシン（VM）、コンテナ、パブリッククラウドといった革新によって、アプリケーション開発はさまざまな点で改善されてきましたが、それでもなお、設定、メンテナンス、最適化に関するいくつかの決定は技術そのものでなく開発者にかかっています。
開発者に他の責任が課されれば、その分、製品や社内アプリケーションの開発にかけられる時間が減ります。残念ながら、普及率の高い技術の多くは、パフォーマンス最適化、アプリのスケ ーリング、セキュリティパッチの適用、負荷分散などのタスクを開発者に課しています。それらのタスクには、最適とはいえない選択や間違いのリスクがあり、予算を食ったり、脆弱性とダウンタイムの原因になる可能性があります。
こうした効率の悪さは深刻な結果を招いています。恐ろしいことに、開発者がコーディング以外のタスクに費やす時間を組織のコストに換算すると、年間850億ドル以上にも上ります。
そこで、アプリケーション開発から複雑さを取り除くことで開発環境が改善され、組織にとっても大幅なコスト削減になります。
業界がサーバーレスに移行する
サーバーレス 技術はこうした問題の解決のため、特に開発者の負担を軽減することによるアプリ開発過程の改善を旨に設計されました。しかし、同じサーバーレスでもプラットフォームによって異なります。サーバーレスプラットフォームの初期のイテレーションでは、構築の基盤となった技術（コンテナ、地域、パブリッククラウド）に関連する設定、スケーラビリティ、パフォーマンスの問題の多くが残っていました。
ですから、今日私 たちが知っている「サーバーレス」は、古いモデルを下敷きに漏れのある抽象化をしたケースが多いのです。
高度なサーバーレスプラットフォームはそうした問題を克服し、重要なアーキテクチャーの改善をいくつか実現しました。これらの改善によって時間のかかる決定が開発プロセスから排除され、チームは素晴らしい製品やアプリの開発にもっと時間を割くことができるようになります。
従来の開発メソッドに基づく構築
サーバーレスが登場する前はVMとコンテナでした。VMは、別のコンピューターのOS内に存在するソフトウェアベースのコンピューターで、コンテナは、アプリケーションの実行に必要なすべての要素を内包するソフトウェアの標準単位です。
これらの技術はいずれも、開発者がハードウェアの管理よりアプリケーションに集中できるようにします。ただ、VMやコンテナも開発者が管理や設定を担っているのは同じで、そのために開発プロセス全般が遅くなります。
VMやコンテナでは、開発者とそのパートナーであるIT・セキュリティチームが、程度の違いはあるものの次のことをする必要があります。
セキュリティパッチと、ID・アクセス管理（IAM）におけるアクセス許可を管理する
負荷分散とネットワーキングの設定をする
可用性と冗長性を確保する
Kubernetesのようなコンテナオーケストレーションシステムは、スケールや冗長性の管理などコンテナに関連する設定要件の多くを緩和してくれます。しかし、デベロッパーオペレーション（DevOps）チームは、対顧客の問題より社内の開発問題を解決することに注力しており、効果的な管理をするにはKubernetesの専門知識が必要になります。Kubernetesときちんと訓練されたチームが無ければ、コンテナの限界は依然残ります。
VMとコンテナは全体像の一部に過ぎません。これらの技術は共に、パブリッククラウドで使うことができますが、それによる制約も生まれます。
パブリッククラウドは開発のさまざまな側面をシンプルにするのには役立ちますが、地域選択、セキュリティ管理、ネットワーキングソリューションの設計、可用性確保などの何層もの設定を顧客組織がしなければならないことに変わりはありません。また、パブリッククラウドでは、データベース、メッセージキュー、ストレージなど複数のサービスを手動で組み合わせなければなりません。それらのサービスを手動で設定して接続するには時間がかかり、そのためにデプロイメント全体の所要時間が長くなります。
第1世代のサーバーレス開発は非効率
サーバーレスの開発は、VM、コンテナ、パブリッククラウドに関連する問題を克服するためにデザインされました。しかし、初期サーバーレスのメソッドの成功は限定的でした。
第1世代サーバーレス開発の主な問題は、以下などでした。
遅延とスケーラビリティ：初期のサーバーレスプラットフォームの多くはパブリッククラウドで稼働しており、オーバーヘッドコストを削減するために中央に集約したデータセンターに依存していました。このモデルでは、顧客がリソースの物理的ロケーションをデプロイメント地域として選択しなければなりません。データを中央に集約すると、コードがエンドユーザーから遠く離れた場所で実行されるため遅延が発生します。さらに、複数地域にわたるスケーリングやデプロイメントは可能ですが、設定が複雑です。
コールドスタートとCPUスロットリング：コンテナを基にしたサーバーレスプラットフォームは、コールドスタートと中央処理装置（CPU）のスロットリングが問題でした。コールドスタートは、サーバーレス関数を初めて実行する際に生じる読み込みの遅れで、コンテナが温まるまでに数秒かかることがあるために起こります。一方、CPUスロットリングは、プラットフォームが所定のサーバーレスインスタンス数に達すると起こり、リクエストを遅らせます。
開発環境の悪さ：開発者は多くの場合、オーケストレーションテンプレートのセットアップ、アプリケーションのサイズ計測、メモリ階層の決定など、時間のかかるタスクを管理しなければなりません。これらのタスクには高くつく間違いが起きる可能性があり、開発者がコーディングにかける時間が削られるため、組織にとっては長期的にコスト高となります。
限定的な可観測性：サーバーレス開発プラットフォームの多くは、可観測性が不十分なため監視が困難です。可観測性とは、分散型システムで何が起こっているかをパフォーマンスメトリクスやイベントログなどによって組織が理解できる程度をいいます。可観測性が不十分だと、組織はサーバーレスアプリケーション内の問題を効率的に診断して是正することができません。
ステートレスという性質上、アプリケーションの機能が限定的：第1世代のサーバーレスプラットフォームは、事実上ステートレスです。このステートレスという性質は、スケーラビリティという点ではプラスですが、インタラクティブチャット、ビデオゲーム、共同編集ツールなど複数クライアント間の強い一貫性やライブ調整が必要なアプリケーションの構築を難しくする可能性があります。
コスト：クラウドサーバーレスプラットフォームの多くでは、APIゲートウェイの料金やコンテナ温存の料金など、隠れがちな追加コストがかかります。その結果、第1世代のプラットフォームを使ったアプリケーション構築（特に大規模の場合）は高価になる可能性があります。
サーバーレス移行の目的は最初からアプリ開発プロセスの簡便化でしたが、中央集約型のパブリッククラウドで稼働するサーバーレスプラットフォームは、その目的を十分に達することができませんでした。
サーバーレス再考：進化を振り返る
次世代のサーバーレス開発プラットフォームは、前世代の欠点の多くを克服して進化してきました。コンテナやパブリッククラウドのようなレガシーインフラに依存しないそれらのソリューションは、いくつかの点で改善されており、開発者の時間を取り戻しています。
それらの改善点とは：
ネットワークエッジで稼働：最先端のサーバーレスプラットフォームは、「エッジ」（つまり、多数のデータセンターからなる分散型ネットワーク）で稼働します。大規模なネットワークになるほど、パフォーマンスやスケーラビリティの問題解消効果が顕著です。それは、エッジネットワークでは、コンピューティングがエンドユーザーの最寄りの接続拠点で行われるからです。分散型のアプローチは遅延が低減します。パブリッククラウドの中央集約型地域とは根本的に異なるのです。つまり、数百のデータセンターを擁するネットワークにコードをデプロイすれば、20のデータセンターを持つネットワークにデプロイするよりも優れたパフォーマンスが提供できるということです。最先端のエッジプラットフォームは、複雑なワークロードを構築できるようCPUランタイムが長くなっています。
コンテナでなくアイソレートを使用：このアプローチで、コンテナベースのアーキテクチャに関わる問題を解消します。コールドスタートとCPUスロットリングという、緩和コストが高くつく問題です。アイソレート（分離）はコンテナと違って温存の必要がなく、コールドスタートの問題は起こりません。また、アイソレートはメモリ消費量が少ないため、オーバーヘッドが削減でき、CPUスロットリングの問題も緩和できます。
事前決定事項が少ない：比較的新しいエッジサーバーレスプラットフォームの中には、パフォーマンスとセキュリティのアプリケーションを自動で最適化するものがあります。グローバルエッジネットワークを使うソリューションも、ネットワーク上のすべてのデータセンターにコードをデプロイするため、開発者がワークロードをホストする地域を選ぶ必要がありません。こういった面倒なタスクが省かれて、開発環境が改善されます。
詳細分析と詳細ログ：前世代のサーバーレスプラットフォームは分析やデバッグ、ログの機能は大してなかったのに対し、先端のサーバーレスプラットフォームは可観測性が高まっています。詳細な分析やログは、開発チームがトラブルシューティングに必要な情報を収集しやすくします。さらに、一部のプラットフォームは洗練度の高い監視ツールを統合しています。複雑度の高いアプリケーションの開発で必要になるかもしれません。
統合されたコーディネーションとストレージ：この機能により、サーバーレスでステートフルなアーキテクチャを構築することが可能になります。ステートフルなアーキテクチャは、一貫性のあるデータストレージを必要とします。一時的データを使うステートレスアプリケーションと違う点です。ステートフルなアーキテクチャなしには、インタラクティブでリアルタイム性のアプリケーションを作ることはできません。
優れたコスト効率：アイソレートベースの軽量エッジサーバーレスプラットフォームは、コンテナベースの従来型と比べて低コストです。アイソレートアーキテクチャは、優れたスケーラビリティと柔軟性というクラウドのメリットはすべて提供しつつ、隠れた料金やコストの急増はありません。
これらの改善により、次世代のサーバーレスプラットフォームはアプリケーション開発のプロセス全体を最適化します。面倒なタスクを排 除し、開発者が開発に集中できるようにし、組織にはコスト削減効果をもたらします。
Workersでアプリケーション開発を最適化
適正なサーバーレスプラットフォームは、スケーラビリティの制約を取り除き、開発者の負担を和らげ、アプリケーション開発のプロセス全般の効率を改善します。Cloudflare Workers は、開発者を多くの事前決定事項から解放するためにスマートインフラを用いたエッジベースのサーバーレスプラットフォームです。Cloudflareのインフラのおかげで、Workersで構築したアプリケーションは常に最適化されており、セキュリティ、パフォーマンス、信頼性を確保します。
Workersは120か国以上、330都市以上に広がるCloudflareのグローバルネットワーク上で稼働しているため、スケーラビリティの問題は全くありません。コードは全地域に自動的にデプロイされます。追加のコストや設定は一切必要ありません。開発チームは Workers Unboundを使って、長いCPUランタイムを必要とする高度なアプリケーションをエッジで構築できます。Workersプラットフォームはコンテナでなくアイソレートで稼働するため、コールドスタートやCPUスロットリングは起こりません。Workersには可観測性がビルトインされており、 New Relic やSentryなどの高度な監視ツールを統合しているほか、Workers Command Line Interface（CLI）を通してデバッグやログのツールも利用可能です。 Durable Objects を使えば、Workersプラットフォームに低遅延のコーディネーションと一貫性のあるストレージが加わり、ステートフルなサーバーレスアプリケーションを実現できます。同時に、Workersは隠れた料金がなく、業界有数の手頃な価格設定により、お客様にとっても費用節約になります。
開発チームはWorkersを使うことによって、メンテナンスや設定ではなく製品開発に集中できますので、開発環境が改善され、長期的には会社にも財務的メリットがあります。
この記事は、技術関連の意思決定者に影響を及ぼす最新のトレンドとトピックについてお伝えするシリーズの一環です。
記事の要点
この記事を読めば、以下が理解できます。
非効率な開発アーキテクチャの問題点は？
開発メソッドが進化してサーバーレスに至った経緯は？
サーバーレスの初期イテレーションは、どうしてアプリケーション開発の簡便化に失敗したか？
次世代サーバーレスの主な違い
関連リソース
このトピックを深く掘りさげてみましょう。
Workersなどのサーバーレスプラットフォームの詳細については、「The Forrester New Wave: Function-as-a-Service Platforms」レポートでお読みいただけます。