サーバーレス
2016年6月20日
サーバーレスアーキテクチャは、アプリケーション開発が通常のサーバープロセスを使用しない、インターネットベースのシステムです。代わりに、サードパーティサービス、クライアントサイドロジック、およびサービスホスト型リモートプロシージャコール(FaaS)の組み合わせのみに依存します。

サーバーレスアプリケーションは、従来サーバーによって処理されていたタスクを達成するために、サードパーティサービスを広範囲に利用することがよくあります。これらのサービスは、Amazon AWSやAzureのような相互運用可能なサービスの豊富なエコシステムである場合もあれば、ParseやFirebaseのようなターンキー機能を一式提供しようとする単一のサービスである場合もあります。これらのサービスによって提供される抽象化は、(メッセージキュー、データベース、エッジキャッシュなどの)インフラストラクチャ関連である場合もあれば、(フェデレーションID、ロールと機能の管理、検索などの)より高度なレベルである場合もあります。
汎用サーバーベースのWebアプリケーションの主な責務の1つは、リクエスト-レスポンスサイクルを制御することです。サーバー側のコントローラーは入力を処理し、適切なアプリケーション動作を呼び出し、通常はテンプレートエンジンを使用して動的なレスポンスを構築します。アプリケーションの動作がサードパーティサービスから織り合わされているサーバーレスアプリケーションでは、クライアントサイドの制御フローと動的コンテンツ生成がサーバーサイドのコントローラーに取って代わります。リッチなJavaScriptアプリケーション、モバイルアプリケーション(そしてますます、TVや組み込みIoTアプリケーション)は、API呼び出しを行い、クライアントサイドのUIフレームワークを使用して動的コンテンツを生成することにより、さまざまなサービス間のインタラクションを調整します。
サーバーベースのWebアプリケーションの最も実質的な部分は、コントローラーとインフラストラクチャの間で行われる作業、つまりビジネスロジックです。長寿命のサーバーは、このロジックを実装するコードをホストし、アプリケーションが稼働している限り必要な処理を実行します。サーバーレスアプリケーションでは、カスタムコードコンポーネントのライフサイクルがはるかに短く、単一のHTTPリクエスト/レスポンスサイクルのタイムラインに近くなります。コードはリクエストが到着するとアクティブになり、リクエストを処理し、アクティビティが終了するとすぐに休止状態になります。このコードは、Amazon Lambda、Azure Functions、またはGoogle Cloud Functionsなどのマネージド環境に存在することが多く、コードのライフサイクル管理とスケーリングを処理します。(このスタイルのソフトウェア編成は、「Function as a Service」- FaaSと呼ばれることもあります。)リクエストごとの短いライフサイクルは、リクエストごとの価格モデルにも適しており、一部のチームにとっては大幅なコスト削減につながります。[1]
新しいスタイル、新しいトレードオフ
すべての設計はトレードオフに関するものです。このスタイルで構築されたアプリケーションにはいくつかの明確な利点があり、もちろんいくつかの問題もあります。
最も一般的に主張される利点はコストです。トラフィックパターンがバースト状であるシステムでは、バーストに対応するために、ほとんどの時間冷えている頑丈なサーバーを実行するコストは、無駄であり高価です。クラウドベースのインフラストラクチャサービスの需要ベースの価格モデルは、このタイプのトラフィックを処理する必要があるチームに大幅なコスト削減を提供できます。さらに、従来のサーバーベースのアプリケーションでは、アプリケーションと関連するすべてのインフラストラクチャコンポーネントのスケーラビリティは開発チームの責任です。これは、URLを介して利用可能なAPIの単純な抽象化の背後で透過的にスケールするサービスを使用するよりも難しいことがよくあります。したがって、チームはサーバーレスアプリケーションがより簡単にスケールできることに気づくことがよくあります。
一方、いくつかの新しいコストもあります。単一のアプリケーションを分割して、サービスのファブリックから織り合わされたものにするという概念的なオーバーヘッドは大きく、使用するサービスの数と種類が増えるにつれて増加します。アプリケーションに外部サービスで実装および実行されている重要な部分がある場合、ローカル開発と単体テストも難しくなります。チームは、これをある程度相殺するために、ブロードスタックテストとセマンティックモニタリングをよく使用します。
最後に、サーバーレスシステムは運用および保守が容易であるという認識された利点があります。サードパーティサービスは、セキュリティ、可用性、スケーリング、およびパフォーマンスに多大なリソースを費やしています。これらのことは専門的なスキルを必要とすることが多く、小規模な開発チームの専門分野ではない可能性があります。しかし、これはチームが運用について忘れてもよいという意味ではありません。サービス停止、ダウンタイム、廃止、および速度低下によって引き起こされる問題に対処し、これらが自身のアプリケーションにカスケード的な影響を与えるのを防ぐことは、依然として開発チームの責任です。
さらに読む
Mike Robertsは、サーバーレスアーキテクチャに関するより詳細な記事を執筆しており、これには例、トレードオフに関する詳細、および同様のスタイルとの対比が含まれます。
Patrick Deboisは、serverlessconf 2016での彼の講演で、サーバーレスアーキテクチャの運用の現実について詳しく述べています。
謝辞
この投稿のイラスト、編集アドバイス、ガイダンスで協力してくれたMartin Fowlerに感謝します。また、Mike Roberts、Paul Hammant、Ken McCormackのインプット、およびサーバーレスアプリケーションの構築経験について議論する時間を提供してくれたChris Turner、Ian Carvell、Patrick Debois、Jay Sandhausにも感謝します。Jean-Noël Rouvignacは、いくつかのタイプミスを指摘してくれました。