Serverless Framework を使用したマルチクラウド ソリューション

Azure Functions

この記事では、Serverless Framework を使用して Azure およびアマゾン ウェブ サービス (AWS) の両クラウド プラットフォームにまたがる高可用性サーバーレス ソリューションをデプロイするために、Microsoft Commercial Software Engineering (CSE) チームがグローバルな小売業者と提携した方法について説明します。

アーキテクチャ

マルチクラウド サーバーレス アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  • ユーザー アプリには、クラウドにログインできる任意のソースのものを使用できます。 この実装では、ユーザーは、Azure と AWS のクラウド間で要求を 50 対 50 の割合で負荷分散するゲートウェイ アプリにログインします。
  • すべての応答も、API マネージャー ゲートウェイ経由でルーティングされた後、要求元アプリに送信されます。

コンポーネント

Serverless Framework

このソリューションでは、Serverless, Inc から入手できる Serverless Framework が使用されています。無料版の Serverless Framework には、CLI、追加のプラグイン、および制限付きの監視サービスが含まれています。 Pro エディションでは、強化された監視やアラートなど、クラウドにまたがる運用機能が提供されます。 このフレームワークでは、Node.js と Python 言語、および AWS と Azure クラウド ホストの両方がサポートされています。

Serverless Framework で Azure を使用するには、次のものが必要です。

  • Node.js (マイクロサービスをパッケージ化するため)
  • Azure Functions (他のクラウド プラットフォームと同等の機能を提供するため)
  • Serverless Framework (マルチクラウドのデプロイと監視をサポートするため)
  • サーバーレス マルチクラウド ライブラリ (開発者向けに正規化されたランタイム API を提供するため)
  • Azure Functions サーバーレス プラグイン (マルチクラウドのデプロイをサポートするため)。 このプラグインは、最初は比較対象の AWS Lambda プラグインと同等のものではなく、このプロジェクト用に拡張されました。

次の図は処理パイプラインを示しています。 ミドルウェア レイヤーは、ハンドラーに到達する前に必要なすべての中間機能を表しています。

マルチクラウド処理パイプラインを示す図。

クラウドに依存しない API

各プラットフォーム上のサーバーレスの実装では、個々の関数がマイクロサービスとしてサポートされます。機能 VM ノードごとに 1 つのマイクロサービスがあり、必要に応じて処理が実行されます。 それぞれの AWS Lambda 関数には、対応する Azure Functions 関数があります。 "サーバーレス マルチクラウド ライブラリ" は、どちらかのクラウドからの類似のマイクロサービスを、クラウドに依存しない "正規化された REST API" に構築します。クライアント アプリでは、これをどちらのプラットフォームともインターフェイスとして使用できます。 抽象化された API レイヤーでは、各プラットフォームの対応するマイクロサービスを処理するためのコードが提供されるため、トランザクションに変換は必要ありません。 ユーザー アプリでクラウドに依存しないインターフェイスを使用すると、どのクラウド プラットフォームにアクセスしているかを気にすることなく、クラウドと対話できます。

次の図にこの概念を示します。

クラウドに依存しない API を示す図。

GitOps を使用した CI/CD

Serverless Framework の主要なジョブは、アプリをクラウドにデプロイする際の、インフラストラクチャに関するすべての懸念事項を抽象化することです。 マニフェスト ベースの方法を使用することにより、Serverless Framework ではデプロイに関するすべての問題に対処でき、必要に応じてデプロイを自動化し、GitOps をサポートすることができます。

この最初のプロジェクトでは手動デプロイを使用しましたが、クラウド内またはクラウド間でマニフェスト駆動型のサーバーレス ビルド、テスト、およびデプロイを実装することは現実的です。 このプロセスでは、GitOps 開発者ワークフローを使用できます。すなわち、Git からのビルド、テストと評価用の品質ゲートの使用、および両方のクラウド プロバイダーへのサーバーレス ソリューションのプッシュです。 プロジェクトの開始時から Serverless Framework を使用してすべてのデプロイを実行することは、作業を進める最も効率的な方法です。

API マネージャー

API マネージャーとしては、既存のアプリケーションまたはカスタム アプリケーションを使用できます。 この実装の Apigee™ API マネージャーは、2 つのクラウド プラットフォームに対する 50 対 50 の割合のトランザクションの負荷分散を提供するルーターとしてのみ使用されており、その機能の一部しか使用されていませんでした。

API マネージャーには、次の機能が備わっている必要があります。

  • 必要に応じて、クラウド プラットフォームの内部または外部にデプロイされる
  • 両方のクラウド プラットフォーム間でメッセージをルーティングする
  • トラフィック要求をログに記録し、非同期メッセージ トラフィックを調整する
  • ユーザー アプリケーションとの間で共通の REST API を使用して要求と応答をリレーする
  • 両方のクラウド サーバーレス フレームワーク デプロイの正常性を監視して、要求を受信する機能を検証する
  • 各クラウド プラットフォームに対して自動的に正常性と可用性のチェックを実行し、ルーティングと高可用性をサポートする

代替

  • クラウド プラットフォーム (この場合は AWS Lambda と Azure Functions) のサーバーレス実装によってサポートされている限り、Python などの他の言語を使用してソリューションを実装することができます。 このプロジェクトでは、マイクロサービスをパッケージ化するために Node.js が使用されました。お客様が Node.js を使い慣れており、AWS と Azure の両方のプラットフォームでサポートされているためです。

  • ソリューションでは、Azure と AWS だけでなく、Serverless Framework がサポートされている任意のクラウド プラットフォームを使用できます。 現時点では、Serverless Framework によって、8 つの異なるクラウド プロバイダーとの互換性が報告されています。 唯一の注意点は、マルチクラウド アーキテクチャまたはそれと同等のものをサポートする要素が、ターゲット クラウド プラットフォームで使用できることを確認することです。

  • この最初の実装の API マネージャーは、2 つのクラウド プラットフォームに対する 50 対 50 の割合のトランザクションの負荷分散を提供するルーターとしてのみ使用されました。 API マネージャーには、特定のシナリオ用に他のビジネス ロジックを組み込むことができます。

シナリオの詳細

"サーバーレス コンピューティング" では、クラウド プロバイダーによって、コードを実行するためのマイクロサービス リソースが動的に割り当てられ、使用されたリソースに対してのみ料金が請求されます。 サーバーレス コンピューティングによって、インフラストラクチャの実装、コードの展開、計画やメンテナンスなどの運用面からアプリ コードが抽象化されます。

他のサービスと同様に、各クラウド プロバイダーは独自のサーバーレス実装を備えており、運用に対する大きな影響やコストなしで、顧客が異なるプロバイダーを使用することは困難です。 潜在的な顧客は、自分の交渉の立場や機敏性を弱めるものとしてこの状況を見なす可能性があります。 ベンダー ロックインは、エンタープライズ クラウド導入に対する最大の障害の 1 つです。

オープンソースの Serverless Framework は、クラウド プロバイダーにまたがるサーバーレス コンピューティング ソリューションを開発およびデプロイするための、ユニバーサル クラウド インターフェイスです。 サーバーレス関数のオープン ソース化および共通 API によって、プロバイダー、顧客、およびパートナーは、最善のサービスを実現するためのクロスクラウド ソリューションを構築できます。 Serverless Framework によって、ベンダー ロックインとクラウド間のプロバイダーの冗長性に関する問題に対処することにより、クラウド導入に対する障壁が軽減されます。 お客様は、コスト、機敏性、その他の考慮事項に基づいてソリューションを最適化できます。

CSE と Azure 製品チームは、共同で Serverless CLI を作成し直し、Premium Functions、API Management、KeyVault などの Azure Functions の新機能がサポートされるようになりました。 Serverless CLI では、Azure と AWS の両方に対して GitOps デプロイを実行するための標準インターフェイスが提供されるようになりました。 また、このチームによって "サーバーレス マルチクラウド ライブラリ" も開発されました。これには、AWS と Azure の両方にサーバーレス アプリをデプロイするための "正規化されたランタイム API" が用意されています。

この設計では、複数のクラウド プラットフォーム間で、"アクティブ/パッシブ" フェールオーバーではなく "アクティブ/アクティブ" フェールオーバーを使用して高可用性が提供されます。 1 つのクラウド プロバイダーのサービスが異常な状態や利用不可の状態になった場合、このソリューションでは、要求を別のクラウド プラットフォームに再ルーティングできます。

このプロジェクトは、次の技術的な目標を達成しています。

  • 業界間共通のソリューションを作成する。
  • マルチクラウド サーバーレス ライブラリを使用して、デプロイされた場所に関係なくマイクロサービス間のインターフェイスとなるクラウドに依存しない API をサポートする。
  • サポートされているすべてのクラウド プラットフォーム上で、開発、テスト、およびデプロイのための GitOps CI/CD プロセス ワークフローをサポートする。
  • 認証されたクラウド ゲートウェイ経由で API ベースのアクセスを使用し、ゲートウェイをルーターとして使用してクラウド プラットフォーム間の負荷を分散する。

Serverless Framework を使用すると、次のような利点を得られる可能性があります。

  • ベンダー ロックインの防止または削減
  • マルチクラウド サーバーレス ライブラリを使用することによる、開発中の 40-60% 以上のコード削減
  • さまざまなクラウド プロバイダーのサービスを組み合わせた最善のソリューションの開発
  • プラットフォームとインフラストラクチャの複雑さとメンテナンス要件をほとんど排除する
  • より簡単なデータ共有、パフォーマンスとコストの比較、および特別なオファリングを活用する機能
  • アクティブ/アクティブの高可用性

考えられるユース ケース

  • サーバーレス マルチクラウド ライブラリのクラウドに依存しない API を使用して、複数のプラットフォーム用のクライアント側アプリケーションを作成する。
  • サーバーレス フレームワークの機能的なマイクロサービスのコレクションを、複数のクラウド プラットフォームにデプロイする。
  • クラウドに依存しないアプリを、クラウド プラットフォーム間で、どのプラットフォームがホストしているかを気にすることなく使用する。

考慮事項

  • この記事では、セキュリティ ソリューションについては説明していません。ただし、最初のデプロイにはそれらが含まれていました。 セキュリティ ソリューションにはさまざまなものがあり、一部はプラットフォームに依存します。このフレームワークでは、妥当なすべてのソリューションに対応する必要があります。 ユーザー認証は、想定される最低限のセキュリティです。

  • AWS と Azure のサーバーレス機能のオファリングの違いを明確に区別することは困難なため、初期の作業では、各クラウド プラットフォームで使用可能な関数のマッピングと、必要な変換要件の特定に焦点を当てる必要があります。 この情報から、プラットフォームに依存しない API を開発することができます。

  • オープンソース ソリューションを使用する場合、あらゆるオープンソース ソフトウェアに伴う長期間の保守とサポートの困難により、リスクが生じる可能性があります。

  • 無料の Serverless Framework では、監視機能は主に管理ダッシュボードに制限されます。 監視機能は、有料のエンタープライズ オファリングで利用できます。 現時点では、Azure Functions サーバーレス プラグインには監視のためのプロビジョニングが含まれていないため、これらの機能を実装するには変更が必要になります。

  • このソリューションでは、メトリックを使用してクラウド プラットフォーム間のパフォーマンスとコストを比較することができ、それによってお客様がクラウド プラットフォーム間の使用をシームレスに最適化できます。

このシナリオのデプロイ

従来の "ブルーグリーン デプロイ" では、アプリを開発し、2 つの独立したまったく同じ環境 (ブルーとグリーン) にデプロイすることで、可用性を高め、リスクを軽減します。 一般的に、ブルー環境がライブ トラフィックを通常処理する運用環境であり、グリーン環境は必要に応じたフェールオーバー デプロイです。 通常、CI/CD パイプラインでは、同じクラウド プラットフォーム内にブルーとグリーンの両方の環境が自動的にデプロイされます。 この構成は、"アクティブ/パッシブ" 構成と見なされます。

マルチクラウド ソリューションでは、ブルーグリーン デプロイは両方のクラウド プラットフォームに実装されています。 サーバーレスの場合は、クラウド プラットフォームごとに、マイクロサービスの 2 つの重複するセットがデプロイされます。1 つは運用環境用、もう 1 つはフェールオーバー環境用です。 各クラウド プラットフォーム内のこのアクティブ/パッシブ設定により、このプラットフォームがダウンするリスクが軽減され、可用性が高まり、マルチクラウドの "アクティブ/アクティブ" の高可用性が実現されます。

アクティブ/アクティブのブルーグリーン デプロイを示す図。

ブルーグリーン デプロイの 2 つ目の利点は、各クラウド プラットフォームでのフェールオーバー デプロイを、マイクロサービスの更新用のテスト環境として使用してから、それらを運用環境デプロイにリリースできることです。

次の手順