新機能 – AWS App Runner: スケーラブルで安全なウェブアプリケーションをコードから数分で作成

現在、コンテナは、私がウェブアプリケーションをパッケージ化する際の標準的な方法となっています。コンテナが提供するスピード、生産性、一貫性は好ましいものですが、コンテナの開発ワークフローには気に入らない側面も 1 つ存在します。コンテナイメージを初めてデプロイする際に発生する時間のかかるルーチン作業です。

このルーチン作業は、ロードバランサーの設定、ドメインの設定、TLS の設定、CI/CD パイプラインの作成、コンテナサービスへのデプロイなどです。

長年にわたりワークフローを微調整してきた私は、現在、AWS Cloud Development Kit のボイラープレートプロジェクトを使用していますが、この段階に到達するには長い時間がかかりました。このボイラープレートプロジェクトは大規模なアプリケーションに最適です。とは言え、単一のコンテナイメージをデプロイしてスケーリングするだけの場合は、依然として作業量が多く感じられます。

AWS のサービスには、コンテナ化されたアプリケーションをきめ細かく制御できるものが多数ありますが、多くのお客様からは、独自のコンテナ環境の設定と操作をAWS で処理できないか、というご質問も届いています。インフラストラクチャサービスを構成および管理することなく、既存のコードまたはコンテナのリポジトリをポイントするだけで、アプリケーションをクラウド内で実行および拡張できるようにしたいというご要望があるのです。

よりシンプルなサービスに対する、お客様からのご希望に応えるため、当社では、エンジニア達が新しいサービスの開発に鋭意取り組んでいます。

AWS App Runner のご紹介
AWS App Runner を使用すると、コンテナやインフラストラクチャのデプロイと管理に関する事前の経験がないチームでも、記述されている言語に左右されることなく、ウェブアプリケーションと API をクラウドに簡単にデプロイできます。このサービスには、AWS の運用とセキュリティのベストプラクティスが組み込まれており、スケールアップまたはスケールダウンは一瞬で行われます。コールドスタートの心配もありません。

ソースからのデプロイ
App Runner では、ソースコードまたはコンテナレジストリに接続することで、アプリケーションがデプロイされます。まず、ソースコードに接続する際の動作をお見せしましょう。私の Python ウェブアプリケーションが、GitHub リポジトリに置かれています。このプロジェクトに App Runner を接続します。これにより、どのようにコードがコンパイルされ、AWS にデプロイされるのかをご覧いただけます。

App Runner コンソールで、[Create an App Runner service (App Runner サービスの作成)] をクリックします。

[Repository type (リポジトリタイプ)] で、[Source code repository (ソースコードリポジトリ)] を選択し、指示に従ってサービスを GitHub アカウントに接続します。[Repository (リポジトリ)] では、デプロイするアプリケーションが置かれているリポジトリを選択します。[Branch (ブランチ)] で、[main (メイン)] を選択します。

[Deployment trigger (デプロイトリガー)] で、[Automatic (自動)] を選択します。これにより、App Runner がソースコードの変更を検出すると、更新されたバージョンのビルドと App Runner サービスへのデプロイが自動的に実行されます

次に、ビルドを設定します。[Runtime (ランタイム)] で、[Python 3] を選択します。このサービスは現在、Python と Node.js の 2 つの言語をサポートしています。他の言語が必要な場合は、コンテナレジストリワークフローを使用する必要があります (後ほど説明します)。[Build command (ビルドコマンド)]、[Start command (スタートコマンド)]、および [Port (ポート)] フィールドも、このスクリーンショットと同じように入力します。

ここで、自分のサービスに名前を付けて、コンテナで使用したい CPU とメモリサイズを選択します。これらの選択は、請求される利用料金に影響します。このアプリケーションでは、CPU やメモリをほとんど必要としないため、コストを低く抑えるために vCPU 1 個、メモリ 2 GB を選択します。また、アプリケーションを設定するための任意の環境変数を、ここで指定することもできます。

このコンソールでは、App Runner のために、いくつか異なる設定をカスタマイズできます。

例えば、Auto Scaling の動作を設定できます。デフォルトでは、サービスが持つこのコンテナイメージのインスタンスは 1 つです。しかし、80 を超えるリクエストを同時に受信した場合には、そのインスタンスが複数に拡張されます。この拡張の最大数をオプションで指定することで、コストを管理することができます。

[Health check (ヘルスチェック)] を展開すると、App Runner がヘルスチェックのリクエストを送信するパスを設定できます。このパスを設定しない場合、App Runner は正常性を検証するために TCP 接続の確立を試みます。デフォルトでは、App Runner が 5 回連続でヘルスチェックの失敗を受信すると、対象のインスタンスは異常であるとみなされ置き換えが行われます。

[Security (セキュリティ)] を展開すると、インスタンスで使用する IAM ロールを選択できます。これにより、コンテナが他の AWS のサービスと通信するためのアクセス許可が付与されます。App Runner は、保存されている、アプリケーションのソースイメージまたはソースバンドルすべてのコピーを暗号化します。顧客管理キー (CMK) を指定しておくと、App Runnerは、ソースの暗号化にそのキーを使用します。キーを指定しない場合には、App Runner は AWS 管理のキーを代わりに使用します。

最後にサービスの設定内容を確認した上で、[Create & deploy (作成してデプロイ)] をクリックします。

数分間経つと、このサービスによるアプリケーションのデプロイが完了し、デプロイされたウェブアプリケーションを指す URL が提供されます。App Runner では https の構成が確保されるので、アプリケーションをチームの誰かと共有してテストする際にも、ブラウザがセキュリティ警告を発することはありません。HTTPS セキュアトラフィック処理のすべては、App Runner が自動的に構成してくれるので、ユーザーがコンテナイメージ内に実装する必要はありません。

では、カスタムドメインを設定していきましょう。このサービスを使用すれば、その設定のためにコンソールを離れる必要もありません。サービスを開き、[Custom domains (カスタムドメイン)] タブを表示し、[Add domain (ドメインの追加)] をクリックします。

[Domain name (ドメイン名)] にアプリケーションに使用するドメインを入力し、[Save (保存)] をクリックします。

ユーザーがドメインの所有権を証明した後、アプリケーションがカスタム URL で利用できるようになります。次のセクションで、App Runner がコンテナイメージをどのように処理するのかをお見せしていきます。

コンテナイメージからのデプロイ
今、.NET ウェブアプリケーションを作成し、コンテナイメージとしてビルドした後、そのコンテナイメージを Amazon ECR Public (パブリックなコンテナレジストリ) にプッシュしてあります。

最初のデモと同様に、[Create service (サービスの作成)] をクリックします。[Source and deployment (ソースとデプロイ) ] の [Repository type (リポジトリタイプ) ] で、[Container registry (コンテナレジストリ)] を選択します。[Provider (プロバイダー)] では、[Amazon ECR Public] を選択します。[Container image URI (コンテナイメージの URI)] に、イメージへの URI を入力します。

この時、[Deployment settings (デプロイ設定)] では、デプロイを手動でトリガーするオプションのみが選択可能になっています。これは、[Amazon ECR Public] を選択しているためです。コンテナが変更されるたびにデプロイしたい場合は、[Provider (プロバイダー)] で、[Amazon ECR] を選択する必要があります。

ここから先の手順は、「ソースからのデプロイ」セクションのものと同じです。デプロイが完了すると、サービスから URL が提供され、アプリケーションがインターネット上でアクセス可能になりまです。

留意点
App Runner は、コンテナインスタンス内に、一時ストレージとしてファイルシステムを実装します。これらのファイルは一時的な使用が目的です。例えば、App Runner サービスを一時停止して再開した場合には、それらのファイルは保持されません。より一般的に言うと、アプリケーションにはステートレスな性質があるために、1 つのリクエストの処理が終わった後に、これらのファイルを維持するということは保証されていません。ただし、保存されたファイルは、そのライフスパンの間、App Runner サービスに割り当てられたストレージの一部を占めます。一時ストレージファイルの、リクエスト間での維持は保証されていませんが、永続する場合もあり得ます。場合によると、ユーザーはこれを活用できます。例えば、リクエストを処理する際に、後に再び必要になった場合にアプリケーションにダウンロードさせるため、このファイルをキャッシュできます。これにより、将来のリクエストの処理がスピードアップすることも考えられますが、性能の向上を保証することはできません。コードの中で、以前のリクエストでダウンロードされたファイルがまだ存在すると仮定することは推奨されません。キャッシュを保証するには、Amazon ElastiCache のような、高スループットで低レイテンシーのメモリ内データストアを使用します。

活動中のパートナー
当社では MongoDB、Datadog、HashiCorp などのパートナーと協力しながら、App Runner との統合を進めてきました。彼らが取り組んできたことの概要は次のとおりです。

MongoDB –「MongoDB Atlas を App Runner と統合できることに興奮しています。これにより、デベロッパーは、当社の世界的なクラウドネイティブデータベースサービスのスケーラビリティとパフォーマンスを、App Runner アプリケーションで活用できるようになります。」

Datadog –「今後、AWS App Runner を使用するユーザーは、コンテナイメージまたはソースコードリポジトリから、ウェブアプリケーションをより簡単にデプロイおよびスケーリングできるようになります。当社が提供する新しい統合により、ユーザーは App Runner のメトリクスやログ記録、またイベントなどをモニタリングして、問題の迅速なトラブルシューティングを行い、アプリに最適なリソースとスケーリングの設定を決定できます。」

HashiCorp –「HashiCorp Terraform と AWS App Runner の統合を使用することで、デベロッパーは、実稼働向けのクラウドアプリケーションをより迅速かつ簡単にデプロイでき、必要なインフラストラクチャの設定と管理を削減できます。」

加えて、当社と Pulumi、Logz.io、Trek10、および Sysdig との統合も非常に有用で、これらにより、App Runner のユーザーは、既知であり信頼が置けるツールやサービスを利用することが可能になります。

利用可能なリージョンと料金
AWS App Runner は現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国東部 (オハイオ)、アジアパシフィック (東京)、欧州 (アイルランド) の各リージョンでご利用が可能です。App Runner は、AWS マネジメントコンソールおよび AWS Copilot CLI から使用できます。

App Runner では、アプリケーションが使用した分の、コンピューティングとメモリのリソースに対し料金が発生します。 アプリケーションの処理要件を満たすように、アクティブなコンテナの数が、App Runner により自動的にスケールアップもしくはダウンされます。利用料金が予算範囲を超えないように、アプリケーションが使用するコンテナの数に上限を設定できます。

課金は、App Runner が実行されている時間に対してのみ行われます。また、アプリケーションは簡単に一時停止したり、すぐに再開したりできます。開発およびテストの段階で、使用していないアプリケーションをオフにすることができるので、これはコストの管理に特に有用です。詳細については、App Runner の料金ページを参照してください。

大規模なウェブアプリケーションの迅速かつ安全な実行が必要なお客様は、今すぐ AWS App Runner の使用を開始してください。

– Martin