サーバーレス アプリ: アーキテクチャ、パターン、および Azure の実装

サーバーレス アプリの e-book のカバーを示すスクリーン ショット。

エディション v3.0-Azure Functions v3 に更新

次の場所でダウンロードできます: https://aka.ms/serverlessbookpdf

発行者

Microsoft 開発部門、.NET および Visual Studio 製品チーム

A division of Microsoft Corporation

One Microsoft Way

Redmond, Washington 98052-6399

Copyright © 2018-2020 by Microsoft Corporation

All rights reserved. 本書のいかなる部分も、書面による発行者の許可なしに、いかなる形式または方法によっても、複製または伝送することを禁じます。

本書は "現状有姿" で提供され、著者の見解と意見を表しています。 URL および他の参照されているインターネットの Web サイトをはじめ、本書に記載されている見解、意見、および情報は、通知なく変更されることがあります。

ここに記載したいくつかの例は、説明のためだけに提供された架空のものです。 実在のものとの関連性または関係性は一切ありません。

https://www.microsoft.com の "商標" Web ページに記載されている Microsoft および商標は、Microsoft グループの商標です。

Mac および macOS は Apple Inc. の商標です。

その他のすべてのマークおよびロゴは、該当する各社が所有しています。

作成者:

Jeremy Likness 、上級 .NET データ プログラム マネージャー、Microsoft Corp.

共同作成者:

Cecil Phillip 、上級クラウド アドボケイト、Microsoft Corp.

編集者:

Bill Wagner 、シニア コンテンツ開発者、Microsoft Corp.

Maira Wenzel 、シニア コンテンツ開発者、Microsoft Corp.

参加者とレビュー担当者:

Steve Smith 、所有者、Ardalis Services。

はじめに

サーバーレスとは、クラウド プラットフォームが純粋なクラウド ネイティブ コードの方向に進化したものです。 開発者は、サーバーレスにより、インフラストラクチャを心配することなく、ビジネス ロジックに近づくことができます。 "サーバーがない" というよりはむしろ "サーバーが少ない" パターンです。 サーバーレス コードは、イベント ドリブンです。 コードは、従来の HTTP Web 要求からタイマーまたはファイルのアップロード結果など、すべてのものからトリガーできます。 サーバーレスの背後にあるインフラストラクチャを瞬時にスケーリングして、需要に柔軟に対応することにより、真に "使用したものを支払う" マイクロビリングが提供されます。 サーバーレスでは、新しい考え方やアプローチでアプリケーションを構築する必要があり、すべての問題へのソリューションとしては適していません。 開発者は以下の決定をする必要があります。

  • サーバーレスの長所と短所とは何か?
  • 独自のアプリケーションでなぜサーバーレスを検討する必要があるのか?
  • サーバーレス コードをどのようにビルド、テスト、展開するのか?
  • 既存のアプリケーションでサーバーレスにコードを移行するのにどの場所が適切であるか、およびこの移行を実現する最善の方法は何か?

このガイドについて

このガイドでは、サーバーレスを使用するアプリケーションをクラウド ネイティブで開発することに焦点を当てています。 このブックでは、サーバーレス アプリの開発の利点と、可能性のある欠点を明らかにし、サーバーレス アーキテクチャについて概説します。 サーバーレスの多くの使用例は、さまざまなサーバーレスの設計パターンを使用して示しています。

このガイドでは、Azure のサーバーレス プラットフォームの構成要素について説明しますが、特に Azure Functions を使用したサーバーレス実装について説明しています。 トリガー、バインド方法、および Durable Functions を使用した状態に依存するサーバーレス アプリの実装方法について説明します。 最後に、プロジェクトにとってサーバーレスが正しいアプローチであるかどうかを判断するために、ビジネス例およびケース スタディで状況や視点を示しています。

クラウド プラットフォームの進化

サーバーレスとは、クラウド プラットフォームがいくつか繰り返されたものの累積です。 この進化は、データ センターの物理メタルから始まって、Infrastructure as a Service (IaaS) および Platform as a Service (PaaS) へ進化しました。

オンプレミスからサーバーレスへの進化

クラウド以前は、開発および運用の間には、認識可能な境界がありました。 アプリケーションを展開するということは、次のようなさまざまな問題に回答するようなものでした。

  • どのようなハードウェアをインストールする必要があるか?
  • コンピューターへの物理アクセスのセキュリティはどのように確保するか?
  • データ センターには無停電電源装置 (UPS) は必要か?
  • ストレージのバックアップはどこに送信するか?
  • 冗長電源は必要か?

このような問題はこれ以外にもあり、莫大なオーバーヘッドがありました。 多くの状況では、IT 部門は途方もない無駄への対応を強いられていました。 この無駄とは、ディザスター リカバリー用のバックアップ マシンとしてのサーバーと、スケールアウトを可能にするスタンバイ サーバーを過度に配置していたことでした。幸いにも、仮想マシン (VM) を使用した仮想化テクノロジの導入 (Hyper-V など) で、Infrastructure as a Service (IaaS) が台頭しました。 運用側は、仮想化されたインフラストラクチャで、サーバーの標準セットを基幹として構成することが可能になり、ユニークなサーバー群を "オン デマンド" でプロビジョニングできる柔軟な環境が出来上がりました。 さらに重要なことには、クラウドを使用して仮想マシンを "サービスとして" 提供するステージが仮想化により設定されました。 企業は、冗長充電や物理マシンなどを心配する必要がなくなりました。 その代わりに仮想環境に集中できるようになりました。

運用ではまださまざまなタスクをこなす必要があるため、IaaS にはまだ大量のオーバーヘッドが必要です。 たとえば、次のようなタスクです。

  • サーバーへの修正プログラムの適用とバックアップ。
  • パッケージのインストール。
  • オペレーティング システムの最新の状態の維持。
  • アプリケーションの監視。

次の進化の Platform as a Service (PaaS) により、オーバーヘッドが減りました。 PaaS でクラウドのプロバイダーは、オペレーティング システム、セキュリティ更新プログラムに対応するのみでなく、特定のプラットフォームをサポートするのに必要なパッケージさえにも対応します。 VM を構築して .NET を構成して、Internet Information Services (IIS) サーバーを立ち上げる代わりに、開発者は "Web アプリケーション" や "API エンドポイント" などの "プラットフォーム ターゲット" を選択し、コードを直接展開すればよいだけになります。 これにより、インフラストラクチャの問題は以下に減りました。

  • どのようなサイズのサービスが必要か?
  • サービスはどのようにスケール アウトされるのか (サーバーやノードが追加されるのか)?
  • サービスはどのようにスケール アップされるのか (サーバーやノードをホストする容量が増えるのか)?

イベント ドリブンのコードに焦点を当てることにより、サーバーレスはさらにサーバーを抽象化しました。 プラットフォームの代わりに、開発者は 1 つのことを実行するマイクロサービスに集中することができます。 サーバーレス コードを構築するときに重要な 2 つの問題は次のとおりです。

  • コードは何によってトリガーされるか?
  • コードでは何が実行されるか?

サーバーレスでは、インフラストラクチャは抽象化されます。 開発者がホストをまったく心配する必要がない場合もあります。 IIS、Kestrel、Apache またはその他の Web サービスのインスタンスが Web 要求を処理する場合もしない場合も、開発者は HTTP トリガーに焦点を当てます。 トリガーは、要求に対して標準のクロスプラットフォームのペイロードを提供します。 このペイロードは、開発手順を単純化するのみでなく、テストを行いやすくし、場合によってはプラットフォーム間でコードを簡単に移植できるようにします。

サーバーレスのもう 1 つの特徴に、マイクロビリングがあります。 Web アプリケーションでは、一般的に Web API エンドポイントがホストされます。 従来のベア メタルでは、IaaS および PaaS の実装でさえも、API をホストするためのリソースに継続的に支払いが行われてきました。 つまり、アクセスがないときでもエンドポイントをホストする費用を支払わなければなりません。 たいてい他よりも頻繁に呼び出される API が 1 つあるため、よく使用されるエンドポイントをサポートするためにシステム全体がスケールされます。 サーバーレスでは、各エンドポイントを個別にスケーリングして、その費用のみを支払えばよいので、API が呼び出されていないときはコストは発生しません。 多くの場合、移行により、エンドポイントをサポートする継続的なコストが劇的に減ります。

このガイドに含まれないもの

このガイドでは、特にアーキテクチャでのアプローチおよび設計パターンについて説明しており、Azure Functions、Logic Apps またはその他のサーバーレス プラットフォームについては詳しくは説明していません。 このガイドでは、たとえば、Logic Apps が使用された高度なワークフローや、クロス オリジン リソース共有 (CORS) の構成などの Azure Functions の機能、カスタム ドメインの適用または SSL 証明書のアップロードについては説明していません。 これらについては、オンラインの Azure Functions のドキュメントで説明しています。

その他の技術情報

対象読者

このガイドは、オンプレミスまたはクラウドでサーバーレス コンポーネントを使用する可能性のある、.NET でのエンタープライズ アプリケーションを開発する、開発者やソリューション アーキテクト向けに記述されています。 これは、次のことに関心のある、開発者、アーキテクト、技術意思決定者に役立ちます。

  • サーバーレスでの開発の長所と短所の理解
  • サーバーレス アーキテクチャに着手する方法の学習
  • サーバーレス アプリの実装例

このガイドの使用方法

このガイドの最初の部分では、いくつかの異なるアーキテクチャでのアプローチを比較しながら、なぜサーバーレスが選択肢として選択可能か検証します。 ソフトウェア開発のすべての局面は、アーキテクチャの決定の影響を受けるので、ライフサイクルの技術面および開発面の両方を検証しています。 次に、このガイドでは、ユース ケースと設計パターンを検証しています。これには、Azure Functions を使用した参照用の実装も含まれています。 各セクションには、特定の領域についてさらに学習するための参照資料が含まれています。 このガイドは、チュートリアル用のリソースおよびサーバーレス実装の実践の探査で締めくくられています。

フィードバックの送信

このガイドおよび関連サンプルは、継続的に更新されるので、お客様のフィードバックを歓迎しています。 このガイドを改善する方法についてコメントがある場合、GitHub の問題の任意のページの下部にビルドされているフィードバック セクションをご利用ください。