Pulisher : Enterprise Managed Service Group イ・ヒェイン
Description：AWS App Runnerを通じてコスト最適化する方法について紹介したセッション

はじめに

AWSインフラストラクチャのコスト最適化のために普段使っていたサービスはCost ExplorerやSavings Plan、Compute Optimizerなどでしたが、AWS App Runnerという少し馴染みのないサービスを通じてどのような方法でコストを最適化できるかを知るためにセッションを申し込みました。

セッションの概要紹介

このセッションでは、AWS App Runnerのフルマネージド機能により、運用コストを削減し、アプリケーションの俊敏性を向上させる方法を紹介します。 また、自動スケーリング、継続的なデプロイメント、マネージドランタイムバージョンについて説明し、コードからデプロイ、インフラストラクチャを管理し、インフラストラクチャのオーバーヘッドを削減する方法の例を紹介します。

セッションは上記のような順序で行われました。

まず、AWS App Runnerが提供する核心機能について説明し、敏捷性を確保して高性能アプリケーションとコスト最適化を達成できる方法と、お客様の成功事例を見る順番です。

クラウドインフラストラクチャーは非常に柔軟性があり、それを構成するために様々なサービスを使用することができます。
クラウドでコンテナ化されたアプリケーションを実行することを例に挙げてみましょう。
アプリケーションをビルドしてコンテナにデプロイし、それをコンピュータにデプロイします。
この時、ビルドとデプロイメントパイプラインを構築して管理する必要があり、アプリケーションコンテナが最新のソフトウェアパッケージを使用しているかどうか、オーケストレーションを通じてコンテナも管理する必要があります。
その後、アプリケーションにトラフィックを提供するためにロードバランサーを配置し、トラフィック量に応じてコスト最適化方式で効率的に拡張または縮小することができます。ただし、これらはすべてアプリケーションに必要な最低限のものです。

この他にも、アプリケーションのユースケースや組織のセキュリティ要件に応じて、ガバナンスを作成・管理する必要がある場合があります。
しかし、多くの顧客や開発者は、これらのことを気にせず、アプリケーション構築だけに集中したい場合が多いです。

最適化された管理のために、このような高度に抽象化されたフルマネージドサービスにより、次のことが可能になります。
インスタンスやすべてのコンピューティングリソースを管理する必要がなく、トラフィックの要件に応じて自動的に拡張および縮小されるため、非常に弾力性があります。また、AWS VPC NetworkingやACMなどにも統合されています。
つまり、基本的にAWSリソースを管理する必要がないことを意味します。

AWS App Runnerのアイデアは、最初からすべてを構築する必要がなく、すべてのコア機能を一つの製品に構築することです。
このケースは、EC2とFargateをベースにカスタマイズされたプラットフォームを構築するための図です。

デプロイメントは一般的にコードに基づいて行われます。そのコードでコンテナを構築し、そのコンテナをコンテナレジストリにプッシュし、アプリケーションをデプロイし、潜在的にスイート全体にロールアウトする必要があります。
場合によっては、トラフィックを新しいバージョンのアプリケーションに移動する必要があります。 この図は、エンドツーエンドのフローと、それがどのように行われるかを示しています。

デプロイを行う場合、アプリケーションがないようなデフォルトのコードである場合もあれば、カスタムDockerファイルを入れる場合もあります。
そこから独自のカスタムイメージを指定して再生することができ、どちらの方法でも動作します。ここでのApp Runnerの利点は、コードに自動デプロイし、App Runnerだけでプッシュできることです。

また、App Runnerには実際にビルドとリリースのパイプラインが内部に組み込まれており、ダウンタイムが全くなく、ロールバックが組み込まれているのもメリットです。

例えば、同時リクエスト80個、最小サイズ1つのインスタンス、最大サイズ2つのインスタンスをしきい値として設定した場合を想定してみましょう。
47時間が経過するにつれて、1つのコンテナでスタートし、トラフィックが増加したり、減少したりする可能性があります。トラフィックが増加すると、そのApp Runnerが実行され、コンテナ数を事前に拡張し始め、別のアプリケーションインスタンスを起動してサービスを提供します。

トラフィックが減少すると、規模も減少し、ある時点に達すると、システムアプリプリンタがアプリケーションを一時停止し、CPU料金の請求を停止します。CPU料金とメモリ料金は別々に請求され、メモリ料金ははるかに少ないです。

App Runnerは基本的にプロキシによって駆動されます。
これは、App Runnerサービスの一部として内部的に展開されるロードバランサーです。
そのため、過去に使用されていた別のアプリケーションロードバランサーやネットワークロードバランサー、またはAPIゲートウェイを実行する必要があった過去の展開形態とは異なり、トラフィックを水平に分散するために、App Runnerはこれをサービス内に構築します。
そして、プロキシロードバランサーはアプリケーションコンテナインスタンスと一緒に接続されており、プロキシは処理中のリクエストの数を追跡しており、オーバーフローキューがあります。

前述の内容を要約してApp Runnerのメリットをまとめた一覧表です。

セッションを終えて

アプリケーション管理サービスとしてElastic Beanstalkのようなサービスもありますが、App Runnerはコンテナ化されたアプリケーションを管理することに特化されたサービスのような気がしました。
また、Beanstalkと違ってリソースが使用中でない状態ではコストが差し引かれないので、コスト的な面でも有利です。
また、様々なAWSサービスとも統合される点が興味深く、規模が大きくない環境に適用するとメリットが多いような気がしました。