はじめに
最近ローンチされたApp Runnerをご存知でしょうか。
App Runnerはコンテナイメージをデプロイ・実行する最も簡単なサービスです。
どのくらい簡単かというと、何も環境を作らなくて良いと言っても過言ではないくらいフルマネージドなのです。
例えばCI/CD環境 + ECSを構築しようとすると以下のような構成図になると思います。
これでもかなり抽象化しており、図では省略していますが、HTTPS通信のためのSSL証明書やタスクを実行するためのタスク実行ロール、Codeシリーズで使うための各種ロールの作成管理などが必要になります。
このようなコンテナ実行環境をイチから構築することは少々の手間がかかりますね。
これがApp Runnerを利用すると以下のようになります。
RDSとElastiCacheは例として載せている共通部分なので一旦スルーしてください。
まるっとCodePipelineとECSの部分がApp Runnerに置き換わったことが分かりますでしょうか？
App Runner単体の機能でCI/CDの実現やロードバランサーの生成、SSL証明書の発行からコンテナ管理など全てを実現できます。
管理者に求められることはアプリケーションイメージの設計のみです。
手軽なコンテナ実行環境が扱えるのでとても期待できますね！
App Runnerにはデメリットも多い
「そんなにApp Runnerが便利ならコンテナサービスは全てApp Runnerでいいじゃん。」
なんて思う方もいるかもしれませんが、まだまだApp Runnerはコンテナ界の銀の弾丸にはなり得ません。
App Runnerにはデメリットも非常に多いです。
例えば上記の画像は先ほどの構成図ですが、RDSが公開サブネットで実行されていることにお気づきでしょうか？
さらにElastiCacheが構成図から消えていますね。
これはApp RunnerがVPCをサポートしていないため、RDSを公開状態にしなければアクセスできないからです。
さらにElastiCacheはパブリックアスセスをサポートしていないので、App Runnerを利用する場合には対象から外れます。
※ 2022年2月9日のアップデートからVPCアクセスがサポートされました。
詳しくはこちら
その他も含めてデメリットを以下にまとめます。
＜デメリット＞
・VPCが使えないのでセキュリティグループによるアクセス制御ができない
・VPCが使えないのでRDSへのアクセスは全てインターネット経由になる
-> VPCアクセスサポートにより解決しました
・IPレンジの指定ができないため、App Runnerからのアクセスを制御することができない
-> VPCコネクタのセキュリティグループを指定することでアクセス制御が可能になりました
・ApplicationLoadBalancerのリスナールールなどリッチな機能が使えない
・App Runner自身のビルド機能の自由度の低さ
・コンテナに割り当てるvCPUやメモリに制限がある(2vCPU/4GBメモリまで)
・ロードバランサーの機能の貧弱さ
・アクセス制御の不便さ
おそらくまだまだ挙げたらキリがないです。
もちろんメリットも非常に多い
先にデメリットを書いてしまいましたが、やはりマネージドにコンテナを実行できることは魅力的です。
さらにホストとなるサーバ管理をAWS側に担保させられるので、管理者が気にすべき責任はアプリケーションのみです。
また、元々グローバルサービスであるDynamoDBやS3などVPCと関係がないサービスを紐付くコンテナであれば特に恩恵を受けられそうですね。
何気にECRへのイメージプッシュをトリガーにできることは使い勝手が良くて、GitHubへのプッシュイベントをトリガーにCodePipelineを実行して、CodeBuild上でイメージを構築するようにすれば自由度の高いリッチな環境でビルドを行うことができます。
おわりに
せっかくの新機能なので「App Runnerでコンテナを実行してみた」的な記事を書こうと思ったのですが、コンテナ実行までの工数が非常に少なくあっさりと構築できてしまいました。
あまりにも簡単に実行できたものですから記事にするのをやめてしまったくらいです。
現状では制約が多くて使いにくい点が目立ちますが、将来的にVPC内のリソースへアクセスできるような機能が追加されていくとECSやEKSに代わるコンテナ実行の選択肢として本格的に名前が上がるようになるのではないでしょうか。
今後もロードマップ的にはアップデートの予告があるようなので、今後の進化を見守っていきたいですね。
コメントを残す