AWSは先頃、App Runnerの一般提供開始(General Availability)を発表した。App Runnerは、コンテナベースのアプリケーションを開発しデプロイするためのサービスを、より高度に抽象化したものだ -- ロードバランシングやオンデマンドのスケーリング、アプリケーション状態の監視といった分散システム開発における課題を、プラットフォームがすべて処理してくれる。コンテナやインフラストラクチャに関する経験のないユーザには、AWSの運用やセキュリティ、コンフィギュレーションに関するベストプラクティスも同時に提供する。
ユーザはインフラストラクチャやサーバ、あるいはスケーリングを気にすることなく、アプリケーションに集中することができる。
App Runnerの思想とその設計について、AWSでコンピューティングサービスを担当するVPのDeepak Singh氏に話を聞いた。
InfoQ: App Runnerを開発したおもな動機は何でしたか？
Deepak Singh: AWSのコンテナオーケストレーションサービスであるAmazon ECSとAmazon EKSは、それらが提供するコントロールやパワフルなサービスが広く認められて、数十万のユーザに採用して頂いています。そのような中、特にAmazon ECSを使用するユーザの間で、当社の提供するコンテナ用サーバレスエンジンであるAWS Fargateを、コンテナの実行ベースとして選択する例が増えています。AWS Fatgateは、インスタンス用のクラスタ管理を不要にする、強固なアイソレーションを提供する、ホストインフラストラクチャのパッチを不要にする、といった方法で、ユーザのアプリケーション運用を容易なものにしてくれます。しかしながら、一部のユーザからは、さらなる要望が寄せられています。ロードバランサやVMや暗号化に関する認証管理といったことに煩わされずに、ただ単にWebアプリを実行したい、というのです。ビジネスの構築に集中したい、ビジネスの成長に伴うプラットフォームやアーキテクチャの再構築に頭を悩ませたくない、というのが彼らの希望です。AWS App Runnerはこのようなニーズから生まれました — インフラストラクチャやコンテナの専門知識を必要とせず、スケーラブルなWebアプリを開発し、デプロイし、実行する手段をユーザに提供する、完全マネージドなサービスです。AWS App Runnerを使えば、コンテナの専門知識やインフラストラクチャの運用経験を持っていなくても、スケーラブルなWebアプリを数分間でデプロイすることができます。
InfoQ: 単純な、あるいは標準的なユースケースに対しては、Cloud Foundryのように定型的なサービスを提供するプラットフォームが適している、という見解がありますが、App Runnerはこうしたユースケースを越えるものなのでしょうか、そうであるとすれば、どのように越えるのですか？
Singh: AWS App Rnnerは、開発者中心のエクスペリエンスを備えています。アプリの運用は極めて簡単ですが、AWSのセキュリティや運用に関するベストプラクティスというメリットも兼ね備えているのです。スケーリングや暗号化、コンテナのアイソレーションなど、多くの要素が組み込まれています。App Runnerで得られるのは簡便性だけではありません — ビジネスの成長に伴うプラットフォーム再構築を不要にするような、スケーリング機能も合わせて実現します。トラフィック要件に合わせたスケールアップだけではありません。プロビジョンされたコンテナインスタンスの設定数まで、自動的にスケールダウンすることも可能です。コールドスタートの必要性を削減し、定常的な低レイテンシを保証します。これは当社が多くのユーザから求められている、重要な要件なのです。
InfoQ: App Runnerのおもなユーザはどのような人たちなのでしょう？SMBでしょうか、あるいは大企業ですか？
Singh: AWS App Runnerは、可能な限り小さなインフラストラクチャで素早く行動したいユーザ向けに開発されました。サーバレスコンテナ運用モデルを提供するAmazon ECS/AWS Fargateについて振り返ってみると、当初はSMBが採用していたものの、インフラストラクチャが完全マネージドであるという理由から、その後Vanguardなどの大企業にも有意義な手段として採用が広がっていった、という経緯がありました。AWS Fargateを採用したことによってVanguardは、マイクロサービスの運用投入速度を3か月から24時間へと向上するとともに、単位コストを50パーセント削減したのです。同じような簡易運用モデルはスタックの他の部分でも求められていますから、App Runnerも同じような採用パターンになるのではないか、と予想しています。
InfoQ: Node.js 12やPython 3以外の言語サポートについてはどうでしょう？より多くの言語を統合する上では、どのような問題がありますか？
Singh: Node.js 12とPython 3は現在、自身のコードリポジトリからスタートしたいユーザを対象に、AWS App Runnerビルドプロセスのすべてにおいてサポートされています。ただしAWS App Runner自体は、コンテナにパッケージして実行するという意味からは、無制限に近い言語やフレームワークをサポートしているのです。当社の他のコンテナサービスと同様、ロードマップはGitHubで公開しています。サポートする開発言語の追加については、ユーザの要求をベースに優先度を決めたいと思っています。
InfoQ: App Runnerの実装や技術的詳細について、もう少し詳しく説明してください。
Singh: AWS App RunnerはAmazon ECS/AWS Fargate上に構築されています。このサービスで重要なのは、難しい処理(heavy lifting)を抽象化している点です。AWS App Runnerがすべてを完全に管理してくれるので、ユーザは単に自身のコードをプラグインすればよいのです。設定や最適化、スタック全体の運用は、エンドツーエンドで私たちが処理します。App Runnerを使うユーザには、FirecrackerなどのテクノロジによるVMのアイソレーション(デフォルト)、完全自動化されたオートスケーリング、さらにはblue-green形式のデプロイによる安全なデプロイメント(デフォルト)やトラフィックに反応するアプリケーションのスケーリングなど、AWSコンテナ実行の持つメリットが自動的に提供されます。サービスやコンポーネントを自分たちで設定したい、あるいはその必要があるユーザに対しては、AWSの用意する広く深いコンテナポートフォリオが、いつでもそのニーズに応えます — AWS App Runnerは、インフラストラクチャに関する判断や管理作業を削減して、自らのアプリにより時間を費やしたいユーザのためのものなのです。
InfoQ: 最後になりますが、App Runner全般と開発ツールに関する計画やロードマップについて教えてください。
Singh: AWS App RunnerのロードマップはGitHub上で公開されています(編集記: インタビュー時点ではGitHubリポジトリ上で確認できる情報はなかった)。フィードバックや機能の要望も同時に募集しています。App Runnerのユーザが強い関心を持っている領域としては、プライベートVPCのサポート追加、ビルドパックのサポート、利用可能なリージョンの拡大、AWS X-RayやAWS Secret Managerサポートの追加、といったものがあるようです。AWS Copilotを使った、AWS Runner用のアウト・オブ・ボックスサポートも用意しています。AWS Copilotを使えば、Amazon ECS/AWS FargateとAWS App Runnerにまたがるデプロイも簡単に行うことができます。Webアプリケーションにデータ層(Amazon DynamoDB、Amazon S3など)を追加するための、合理的なストレージユニットワークフローもサポートしています。
AWS App Runnerの導入について紹介した資料には、アプリケーションの開発とデプロイの手順が概説されている。