サーバーレスフレームワークと AWS Service Catalog を使ってより速くコードをデプロイする

Serverless Framework はオープンソースプロジェクトで、AWS Lambda や Amazon API Gateway などのサービスを使用してサーバーレスアプリケーションを迅速に構築およびデプロイしたい多くのアマゾン ウェブ サービス (AWS) のお客様に人気があります。

開発者と運用の専門家のために、サーバーレスフレームワークは、serverless deploy という 1 つの簡単なコマンドでコードをビルド、パッケージ化、デプロイします。

企業が AWS 環境を開発者やチームにまたがって拡大するにつれて、事前定義された標準化されたインフラストラクチャテンプレートに移行して、コードのデプロイプロセスをスピードアップし、設定にかかる時間を短縮しています。AWS Service Catalog は、開発者が事前定義された AWS CloudFormation テンプレートを迅速かつ安全にプロビジョニングできるようにする理想的なサービスです。

この記事では、GoDaddy と AWS がサーバーレスフレームワークを活用して共同で開発したオープンソースソリューションを紹介し、開発チームのコードデプロイプロセスを促進および簡素化します。

サーバーレスフレームワークは、AWS パートナーネットワーク (APN) の アドバンストテクノロジーパートナーである Serverless, Inc. によって管理されています。

Service Catalog を使用したコードとしてのインフラストラクチャ

AWS Service Catalog は、事前定義された不変のテンプレートのみをプロビジョニングできる AWS CloudFormation のゲートウェイです。

一見、これは、俊敏性とスピードというより広範なサーバーレスコンピューティングの目標と矛盾しているように見えるかもしれません。けれども、多くの企業は、AWS リソースを標準化された安全なテンプレートにデプロイするための多数のオプションを統合すると、俊敏性とスピードが実際に向上することに気づいています。

たとえば、多くの開発にとって、サーバーレスのオプションの数と複雑さがネックになる可能性があります。開発チームは、標準化されたアーキテクチャをデプロイに活用する方が効率的である場合、車輪を再発明することにより生産性を失う可能性があります。

したがって、AWS Service Catalog を通じて事前定義された不変のテンプレートを活用すると、組織全体の開発チームのスピードと俊敏性を向上させることができます。

動的と静的

大規模な組織は、インフラストラクチャデプロイの動的コンポーネントと静的コンポーネント、および個々のチームとエンジニアリング部門全体の効率など、多くのトレードオフがあることを認識しています。

第一に、これは動的と静的の問題ではありません。むしろ、デプロイ全体の差異を特定し、標準化されているが再利用可能なインフラストラクチャテンプレートを活用しながらオプションをキャプチャするパラメータを作成することがポイントです。

会社のエンジニアリング組織全体を見ると、デプロイは個々のチームが見ることができることよりもはるかに標準的であるというのが当社の考えです。したがって、チーム間のユースケースとデプロイの差異を把握するために十分にパラメータ化された均一なインフラストラクチャテンプレートを設計することが可能です。

動的に生成されたインフラストラクチャの速度と俊敏性を、定義済みの再利用可能なテンプレートが持つ効率性と制御と組み合わせるにはどうすればよいでしょうか? どうサーバーレスフレームワークと AWS Service Catalog を組み合わせることで、AWS Lambda と Amazon API Gateway での開発をより速く、より簡単に行うことができるかを説明します。

共同イノベーション

GoDaddy と AWS はチームを組んで、サーバーレスフレームワークの使いやすさと AWS Service Catalog のプロビジョニング速度とセキュリティを組み合わせる共同開発作業に取り組んでいます。

サーバーレスフレームワークのオープンソースプラグインエコシステムの趣旨に則り、GoDaddy と AWS はサーバーレスフレームワークが AWS Service Catalog を通じてデプロイできるようにする serverless-aws-servicecatalog プラグインを作成しました。プラグインは GitHub にあります。

サーバーレスフレームワークは、AWS CloudFormation による AWS サーバーレスインフラストラクチャの作成とプロジェクトコードのパッケージ化/デプロイの両方に対処します。ほとんどのプロジェクトは反復することで Lambda ソースコードの変更が促されますが、基礎となるインフラストラクチャのデプロイはほとんど変更されないため、後者は標準化に理想的です。

このプラグインを使用すると、現在サーバーレスフレームワークを使用している AWS のお客様は、より標準化された、スケーラブルで事前定義された Infrastructure-as-Code のプロビジョニングプロセスに簡単に移行でき、AWS のサーバーレスデプロイを実現できます。

はじめに

いくつかの簡単な手順で、サーバーレスフレームワークを AWS Service Catalog を通じて環境にデプロイできます。

通常のサーバーレスデプロイへの変更を最小限に抑えましたが、サーバーレスフレームワークをデプロイする前に、プラグインは事前定義された追加の AWS Service Catalog 製品を作成する必要があります。製品が用意されたら、開発者がデプロイするプロセスはほとんど変更されません。

図 1 – プロセスフロー。

デプロイを伴う完全なインストールは、4 つの手動のユーザーステップとそれに続く 2 つの自動化されたアクションにまとめることができます。

手動のステップ:

• AWS Admin ユーザーは、事前定義されたサーバーレス製品を使用して AWS Service Catalog セットアップを開始します。
• DevOps ユーザーはサーバーレスプロジェクトのプラグインをインストールします。
• DevOps ユーザーは、追加の AWS Service Catalog 製品パラメータを使用して、serverless.yml の AWS プロバイダーセクションを設定します (図 2 を参照)。
• DevOps ユーザーは、serverless deploy コマンドを実行します。

自動化されたアクション:

• サーバーレスフレームワークプラグインは、コードを自動的にパッケージ化し、AWS Service Catalog 製品をプロビジョニングします。
• AWS Service Catalog 製品は、AWS リソースを自動的に作成します。

図 2 – サンプル Serverless.yml。

サーバーレスフレームワークの仕組み

サーバーレスフレームワークは、サーバーレスデプロイのためにコードをビルド、コンパイル、パッケージ化してから、パッケージをクラウドにデプロイするオープンソースソフトウェアです。

たとえば、Python での AWS を使用すると、Serverless Framework はすべての依存関係を含む自己完結型の Python 環境を構築します。次に、その環境を AWS Lambda の標準化された zip ファイルにパッケージ化し、AWS CloudFormation テンプレートにデプロイするのに必要なすべての関連 AWS リソースを作成します。

最後に、コードを AWS にコピーし、CloudFormation スタックの作成または更新を開始します。これにより、サーバーレスアプリケーション向けの AWS のサービスがプロビジョニングされます。

サーバーレスフレームワークは、イベントキューを提供することでこれを実現します。その中で、標準で提供されるパッケージとテンプレートの組み合わせを追加のオープンソースプラグインと組み合わせて、機能を拡張できます。

このイベントキューにより、プラグイン開発者はフックを作成し、プロセスの各ステージ (ビルド、コンパイル、パッケージ、プロビジョニング、デプロイなど) の動作と出力を変更できます。

プラグインを追加することにより、ユーザーはフレームワークに特殊な動作を導入することで、特定の段階で処理を変更/置換/増強できます。プラグインが設定に追加されると、Serverless Framework はプラグインをアクティブ化し、プロジェクトのコードを自動的にビルドして、すぐにデプロイできる形式にパッケージ化します。たとえば、プラグインは、Python WSGI などのコーディングフレームワークを追加できるメカニズムです。

サーバーレスフレームワークが AWS にコードをデプロイする方法に特に焦点を当て、AWS プロバイダーは CloudFormation テンプレートを生成し、AWS Software Development Kit (SDK)を通じて作成スタックや更新スタックを呼び出します。サーバーレスフレームワーク向けのデフォルトの AWS プロバイダーパッケージには、最も一般的な Lambda デプロイと関連する Amazon API Gateway を生成するためのロジックとボイラープレート設定が含まれています。

サーバーレスフレームワークは AWS SDK を使用して AWS と対話し、特定のプロジェクトのディレクトリ内の .serverless フォルダの状態を維持します。最初のデプロイで AWS リソースが作成されたら、-function オプションを使用して、後続のコード変更を簡単にデプロイできます。

さらに、CloudFormation の Infrastructure-as-Code アプローチは、AWS の完全なデプロイが文書化され、コンソール内に表示されるため、管理を簡素化します。ユーザーは同じテンプレートを使用して、複数の AWS リージョンとアカウントにかけて複数回デプロイできます。さらに、選択したバージョン管理システム内の単一のプロジェクトで、コーディングとインフラストラクチャの変更を共同で管理できます。

サーバーレスフレームワーク向けの AWS Service Catalog プラグイン

前述したように、AWS Service Catalog は事前定義されたパラメータ化されたテンプレートを使用します。つまり、ユーザーがデプロイする前に、サーバーレスフレームワークパッケージをプロビジョニングするための AWS Service Catalog 製品が準備されている必要があります。このテンプレートは頻繁に更新する必要はなく、コード CI/CD パイプラインとして別のインフラストラクチャの一部になっているはずです。

AWS Service Catalog を通じて、多くのユーザーが同じテンプレートをオンデマンドで活用できます。製品が AWS Service Catalog で作成されると、開発者はサーバーレスフレームワークの設定ファイルに挿入する製品 ID が必要になります。

サーバーレスデプロイを実行すると、サーバーレスフレームワーク向けの AWS Service Catalog プラグインが、デプロイイベントキューの CloudFormation 作成部分をインターセプトします。つまり、デフォルトの AWS プロバイダーからは標準の CloudFormation テンプレートは作成されません。

代わりに、パイプラインは通常どおりコードをパッケージ化してアップロードしますが、プラグインは AWS Service Catalog 製品によって定義されたインフラストラクチャをプロビジョニングします。

GoDaddy のユースケース

GoDaddy は、顧客である一般の起業家のために、複雑なクラウドサービスを限界を超えて簡素化することに長い間取り組んできました。GoDaddy は、大規模なプロビジョニングが、急速なペースで革新し続ける取り組みの次のハードルであると見定めました。

GoDaddy は、コンテナ、Kubernetes、サーバーレス、機械学習向けに業界をリードするアーキテクチャを開発している専門家チームを擁しています。課題は、個々のチームが作成したソリューションとベストプラクティスをより広く活用し、そのテンプレートをエンジニアリング組織全体に提供することです。

この記事で説明した AWS Service Catalog ソリューションを使用すると、GoDaddy は標準化されたサーバーレステンプレートを世界中のどのリージョンにも迅速かつ安全にデプロイでき、開発者コミュニティ全体でスピードとイノベーションを後押しできます。GoDaddy は現在、AWS Service Catalog を通じてエンジニアリング組織全体に 60 以上の製品を提供しているため、開発者は AWS のサービスを新しくクリエイティブな方法で組み合わせることができます。

サーバーレスが低料金で水平スケーリングされたインフラストラクチャを入手する手段として人気が高まるにつれて、GoDaddy は、運用を簡素化し、インフラストラクチャ管理をより効率的にする方法としてサーバーレスを活用できます。各チームがインフラストラクチャデプロイアーキテクチャを理解するのに数週間費やすことなく、単にコードを記述してサーバーレスフレームワークでデプロイすることができます。

たとえば、GoDaddy は最近、serverless-aws-servicecatalog プラグインを使用してオンライン調査アプリケーション用の API を作成しました。その開発者はプラグインを使用してコードを簡単にデプロイし、すぐに製品の構築に集中することができました。

以前は、コードをデプロイする前に、各開発チームが Amazon API Gateway、AWS Identity and Access Management (IAM)、AWS Lambda、およびカスタム DNS 用の独自の AWS CloudFormation テンプレートを作成する必要がありました。

GoDaddy の開発チームは、ビジネス価値の創出に時間を注いでいます。Infrastructure-as-Code のイノベーションをキャプチャして、開発組織全体ですぐに活用できます。開発チームはこれらのテンプレートを使用して、サービスとテクノロジーの新しい組み合わせを作成できます。この組み合わせが、次の標準化されたインフラストラクチャテンプレートになります。

まとめ

多くの企業が、ソフトウェア開発組織のスピードと効率を高めようとしています。このような組織は、標準化された Infrastructure-as-Code が、インフラストラクチャの重労働から開発チームを解放するための良い方法であることをつかんできました。開発者からこの重荷を取り除くことにより、イノベーションに集中してビジネス価値を提供するのにより多くの時間を割くことができます。

サーバーレスフレームワークは、AWS Lambda パッケージとデプロイプロセスをシンプルで効果的に抽象化します。GoDaddy は、セルフサービスの標準化されたインフラストラクチャテンプレートを開発者に提供することにより、新しいプロジェクトをより少ないオーバーヘッドでより速く実行できることを発見しました。

serverless-aws-servicecatalog プラグインは、AWS Service Catalog を通じて、サーバーレスフレームワークを事前定義された AWS CloudFormation テンプレートと組み合わせます。つまり、この組み合わせにより、企業は必要とするガバナンスとセキュリティを維持する一方で、開発者はコードをより速くデプロイできます。