はじめに
さくらのクラウドで、コンテナ実行環境「AppRun β版」がリリースされました。
・さくらのクラウド AppRun
https://cloud.sakura.ad.jp/lp/apprun/
アーキテクチャや仕様、FAQは、以下のマニュアルが詳しいです。
・さくらのクラウド マニュアル AppRun 技術概要
https://manual.sakura.ad.jp/cloud/apprun/glossary.html
・さくらのクラウド マニュアル AppRun サポート
https://manual.sakura.ad.jp/cloud/apprun/faq.html
トライアルでは、一部制限付きではありますが、全機能が無料で用できるとのことで、試してみました。
僕が触ったことがあるクラウドのコンテナ実行環境としては、AWS ECS on Fargateぐらいですが、それとの違いを思い浮かべつつ、触ってみた感想と、本番運用に向けて気になる点をまとめます。
※性能については、現在はリソースを制限しているとのことで、確認していません。現時点での機能仕様や、設定の操作感を確認しました。
※試したのは、2025年2月13日です。
試したこと
以下のマニュアルの「クイックスタート」をほぼそのまま、実行しました。
・さくらのクラウド マニュアル AppRun クイックスタート
https://manual.sakura.ad.jp/cloud/apprun/getting_started.html
- Node.js のHello World 的なサンプルアプリケーションの作成
- コンテナレジストリ、レジストリユーザーの作成
- Dockerコンテナイメージの作成とレジストリへのプッシュ
- アプリケーションの作成、デプロイ
という順で進め、とくに戸惑うことなくデプロイまで完了し、公開URLに対してアクセスを確認することができました。
デプロイ後の、コントロールパネルの画面はこんな感じです。
良い点、面白い点
- 簡単な設定で、アプリケーションを公開できる
- ゼロスケールする
- アプリケーションの複数バージョンへの重みづけのリクエスト振り分けが可能
1.簡単な設定で、アプリケーションを公開できる
AWS ECSと比べると、アプリケーション公開までの作業フローがとても簡単で楽チンです。
ユーザーが考慮すべき基本的な設定としては以下ぐらいです。
- リソース設定（コンテナインスタンスのCPUとメモリ）
- スケーリング設定（コンテナインスタンスの最大数）
- 環境変数
あとは AppRun が起動や自動スケーリングなどをうまいことやってくれます。
コンテナ実行制御レイヤの仕様や独特な用語を意識することなく、容易に使用開始できるのはとてもよいですね。
（その点では、AWSの App Runner に近いのでしょう。名前も似ていますね。）
スケーリングのロジックは非公開で、ユーザー側では変更できませんが、最低限、リソース使用状況とスケーリングの推移が確認できればそれでよいと思います。
APIも使用できるので、CI/CDツールと連携して、ビルド・デプロイの自動化も可能です。
2. ゼロスケールする
アクセスがない時はゼロスケールすることで、コストを最適化します。
という記載があります。
ゼロスケール＝コンテナをすべて停止する、ということですね。
AppRun の課金ルールは発表されていませんが、「コストを最適化」とまで言っているので、コンテナ起動時間ベースの課金となりそうで、アクセスの少ない時間帯のコストを抑えることができます。
一方で、コンテナがすべて停止された状態でアクセスが発生した場合は、コンテナの起動時間が必要なため、レスポンスが少し遅くなります。
僕が試したときでも、連続アクセスの場合のレスポンスは一瞬ですが、アクセス間隔を1～2分ぐらい空けると、5～10秒ぐらい待たされました。
このような、ゼロスケールからのレスポンス遅延が気になるユーザーもいるでしょう。
スケーリング設定は、現状は最大数しか指定できず、最小数は0で固定となっていますが、最小数も指定できる、もしくは、ゼロスケール無効が設定できるとよいですね。
3. アプリケーションの複数バージョンへの重み付けリクエスト振り分けが可能
「アプリケーションのバージョン1に50%、バージョン2に50%」
のような複数バージョンへの振り分け設定ができます。
Blue/Green Deployment的に緩やかに新バージョンに切り替えたい場合や、A/Bテスト等に便利でしょう。
ユーザーが設定可能な項目が少ない中で、この機能は少し意外でした。
本番稼働に向けて気になる点
AppRun を実際に本番環境で使用する場合に気になる点を考えてみました。
- DBサーバーへのセキュアな接続、不正アクセス対策が必要
- アプリケーションのログが確認できない
- モニタリングツールがない
3点あげましたが、逆にいうと、最低限これぐらいあれば十分かもしれません。
1. DBサーバーへのセキュアな接続、不正アクセス対策が必要
Webアプリケーションの場合、データ保存にRDBを使用するケースは非常に多いでしょう。
現時点で、さくらのクラウドでRDB DBサーバーを用意するには、以下の方法が考えられます。
- 「サーバ」にMySQL等のRDBソフトウェアをインストール
- RDBアプライアンス
- エンハンスドデータベース（Labプロダクト）
これらのDBサーバーへの不正アクセスを防ぎつつ、AppRunからDBサーバーに対してセキュアに接続するアクセス制限、認証の仕組みが必要となるでしょう。
現状は、AppRun はパブリックネットワーク（もしくは共用プライベートネットワーク）で動作しているように見えますが、
「DBをパブリックネットワークに公開して、ユーザー名とパスワードのみで認証」
では、さすがに不安です。
2. アプリケーションのログが確認できない
現状、アプリケーションのログを確認する方法は用意されていません。
ログがないと、アプリケーションの動作状況がわかりませんし、デバッグもできません。
これはさすがに、正式リリースまでに何らかの機能が用意されるはずです。
3. モニタリングツールがない
現状、コンテナの稼働状況を確認する方法がありません。
さくらのクラウドの「アクティビティグラフ」のような機能で、例えば以下のようなリソース使用状況を時系列で確認できるツールが必要でしょう。
- CPU使用率、メモリ使用率（ユーザーが設定したCPU、メモリやオートスケール数の妥当性を確認）
- コンテナインスタンス数（オートスケール数設定の妥当性や課金の正確さを確認）
こちらも、正式リリースまでに何らかの機能が用意されると思います。
AppRunのアーキテクチャ
AppRunのアーキテクチャについては、公式のマニュアルでは見つけられませんでしたが、ブログメディア PublicKey の記事に以下のような記載がありました。
・さくらのクラウド、コンテナをサーバレスで実行する「AppRun」製品版トライアルを開始。トライアル中は全機能が無料に – PublicKey
https://www.publickey1.jp/blog/25/apprun.html
AppRunはKubernetesを基盤に、Kubernetes上でサーバレスを実装するためのオープンソースである「Knative」（ケイネイティブ）を用いて構築されています。
KnativeはGoogle CloudのCloud Runで使われているソフトウェアであり、同社が2018年オープンソースとして公開。
「Knative」について調べてみると、RedHat「赤帽エンジニアブログ」の以下の記事がとてもわかりやすかったです。
これらを読むと、AppRunの以下のような機能は、「Knative Serving」の機能によって実現されているのだなと推測できて面白いです。
- アプリケーションの複数バージョンへの重みづけのリクエスト振り分け
- ゼロスケール（KPAでリクエスト数ベースのオートスケール？）
おわりに
最近リリースされた、さくらのクラウド AppRun β版を試してみました。
AppRun は、アプリケーションエンジニアが難しいことを考えずに容易に利用できるコンテナ実行環境といえます。
アプリケーションエンジニアさんと話すと、サーバーアプリケーションをPC上で開発する場合にDockerを使用するケースが多いようですので、それをそのまま本番環境に載せられると便利ですね。
本番環境で安心して使えるよう、正式リリースに向けて機能が追加されることを期待します。