Serverless App Engine:はじめに

Serverless App Engine (SAE) を初めて使用する場合は、動画を視聴して SAE と基本操作を確認してください。

前提条件

初回のデプロイメントの前に、次の項目を準備してください：

• ネットワークリソース — VPC と、その vSwitch を計画してください。vSwitch を作成する際は、Limits and quotas の説明に従って IP アドレス数を計画してください。

• 名前空間 — テスト、ステージング、本番環境を分離する名前空間を計画してください。

• アプリケーションソース — コードパッケージまたはコンテナイメージを準備してください。対応しているソースについては、Deployment sources をご参照ください。

• コンソールのエントリ — SAEコンソール で最初のアプリケーションを作成してください。

  詳細については、「Prerequisites」をご参照ください。

制限とクォータ

計画時には、次の制限を考慮してください。各制限は、アプリケーションを作成できるか、スケールできるか、または監視できるかに影響します。

• システムディスク — SAE は 20 GB のシステムディスクストレージを提供します。外部ストレージの読み取りまたは書き込みを行うには、Apsara File Storage NAS または Object Storage Service (OSS) を使用してください。詳細については、「Storage」をご参照ください。

• リアルタイムログ — リアルタイムログ機能では、ログデータを 500 行表示します。より多くのログデータを表示するには、ファイルログ収集を使用してください。詳細については、「Logs」をご参照ください。

• EIP 数 — 各インスタンスを EIP にバインドする場合は、EIP の数が「インスタンス数 + 1」以上であることを確認してください。EIP が不足していると、インスタンスの作成に失敗し、インスタンスはトラフィックを処理できません。

• vSwitch の IP アドレス — IP アドレスが不足すると作成や弾性スケーリングに失敗するため、vSwitch ごとに 100 個以上の IP アドレスを計画してください。

• ポートマッピング — サービスは 1 つのアプリケーションに対して 1 つのポートを公開します。イングレスは 1 つのポートで複数のアプリケーションを公開します。

デプロイメントソース

SAE は コードパッケージのデプロイ および イメージのデプロイ をサポートしています。

起動コマンドとパラメーター

起動コマンドは、デプロイメントソースごとに定義方法が異なります。

• イメージデプロイメント — Dockerfile に起動コマンドとそのパラメーターを直接定義します。また、アプリケーションの作成時に起動コマンドを上書きすることもできます。

• コードパッケージデプロイメント — アプリケーションの起動コマンドのパラメーターを設定します。Java アプリケーションの場合、デフォルトのコマンド形式は java [-Options] -jar jarfile [arg...] です。この形式では、[-Options] と [arg...] のパラメーターをカスタマイズできます。

環境変数

アプリケーションのコマンドを実行する前に、システムで必要な環境変数を設定しておく必要があります。環境変数はキーと値のペアとして保存されます。環境変数はアプリケーションごとに独立しており、他のアプリケーションには影響しません。詳細については、「Configure environment variables」をご参照ください。

Hosts バインディング

Hosts バインディングを使用すると、SAE アプリケーションは IP アドレスの代わりにドメイン名を使用して外部サービスにアクセスできます。

データベースのホワイトリスト

Elastic Compute Service (ECS) インスタンスに直接アプリケーションをデプロイする場合と比較して、SAE はコンテナでアプリケーションを実行するため、アプリケーションをデプロイするたびに IP アドレスが変更される可能性があります。 アプリケーションがバインドされている vSwitch の CIDR ブロックは変更されないため、vSwitch の CIDR ブロックをデータベースのホワイトリストに追加します。 詳細については、「アプリケーションから Alibaba Cloud データベースにアクセスする」をご参照ください。

CI/CD とデプロイメントプラグイン

SAE は、コンソールおよび API デプロイに加えて、Alibaba Cloud DevOps や Jenkins などの多くの CI/CD ツールと連携しているため、コードコミット後にデプロイが自動的に開始されます。 Java を使用する場合、SAE は、Maven、IntelliJ IDEA、Eclipse 用のプラグインなど、一連のデプロイプラグインも提供します。 詳細については、「アプリケーションホスティングの概要」をご参照ください。

SAE リソースをコードとして管理するには、Terraform を使用します。 詳細については、「terraform-provider-alicloud」および「Terraform の概要」をご参照ください。

ローカル開発や、すでにクラウド上で稼働しているサービスとの共同デバッグについては、「Microservices development」をご参照ください。

リリースとロールバック

SAE は、一括リリース、段階的リリース、およびカナリアリリースをサポートしています。リリースによって問題が発生した場合、アプリケーションを以前のバージョンにロールバックできます。詳細については、「アプリケーションのアップグレードとロールバック」をご参照ください。

権限設定

SAE は、名前空間、アプリケーション、および読み取り/書き込みレベルでのきめ細かいアクセス制御をサポートしており、権限アシスタントが設定プロセスを簡素化します。詳細については、「SAE 権限アシスタント」をご参照ください。

ネットワークの概念

次の図は、これらの Alibaba Cloud ネットワークリソースが相互にどのように関連しているかを示しています。

• VPC — Alibaba Cloud 上に作成するカスタムのプライベートネットワークです。VPC は論理的に互いに完全に分離されています。

  説明

  デフォルトでは、プライベートネットワークはインターネットにアクセスできません。

• vSwitch — VPC の基本的なネットワークデバイスで、物理データセンターに対応します。VPC 内にクラウドリソースを作成する際は、そのリソースが接続する vSwitch を指定する必要があります。

• EIP — ECS インスタンスや SAE インスタンスなどの 1 つのリソースにのみバインドできる Elastic IP アドレスです。バインドされたリソースは、インターネットとの間でトラフィックを送受信できます。

• NAT ゲートウェイ — VPC 内のリソースが SNAT を介してインターネットにアクセスできるようにします。EIP との主な違いは、インターネット NAT ゲートウェイが VPC 内のすべてのリソースを対象とするのに対し、EIP は VPC 内の 1 つのリソースのみを対象とする点です。

トラフィック方向別のアクセス方法

SAE にアプリケーションをデプロイすると、以下のネットワークアクセス要件が発生する場合があります。次の図にその概念を示します。

アクセス方法の比較

サービスレジストリと設定センター

SAE アプリケーションは、サービスレジストリを介して相互に登録および検出します。要件に基づいて実装を選択してください。

• MSE Nacos (推奨) — MSE の Nacos サービスレジストリを使用するもので、マイクロサービスレジストリと設定センターの両方として機能します。

• 組み込み Nacos サービスレジストリ — SAE に組み込まれている Nacos サービスレジストリです。 これを使用するアプリケーションでは、SAE が基本的なサービスリストのクエリ機能を提供します。

• 組み込みの設定管理 — SAE に組み込まれている 分散型設定管理 (ACM) 機能で、設定センターとして機能します。

  他のサービスレジストリのサポートを含む、登録とディスカバリーの詳細については、「Nacos およびその他のサービスレジストリに基づくサービス登録とディスカバリー」をご参照ください。

マイクロサービス開発

サービスガバナンス

マイクロサービスの関連機能

• グレースフルスタートとシャットダウン (マイクロサービスのグレースフルシャットダウンを含む)：「グレースフルスタートとシャットダウン」をご参照ください。

• スロットリングと縮退：「スロットリングと縮退」をご参照ください。

• アプリケーションモニタリング、トレース、およびアラート：「モニタリングとアラート」をご参照ください。

PHP ランタイムのサポート

Serverless App Engine (SAE) は、PHP アプリケーション向けに以下のデプロイ方法をサポートしています。

• イメージ： あらゆる PHP アプリケーションアーキテクチャ。

• PHP ZIP パッケージ： PHP-FPM と Nginx アーキテクチャを使用するあらゆるオンラインアプリケーション。

  SAE は、デフォルトで PHP ランタイム環境を提供します。

PHP リモートデバッグ

SAE には、リモートデバッグを有効にできる Xdebug プラグインが組み込まれています。デバッグ中にインスタンスとローカルマシン間でファイルを移動するには、「ファイルのアップロードとダウンロード」をご参照ください。

ファイルログ

SAE は SLS ログ収集と統合されており、SAE コンソールで有効にするだけで使用できます。収集マシンのリストを手動で管理する必要がある ECS インスタンスへのアプリケーションの直接デプロイと比較して、SAE は、収集ディレクトリまたは収集ファイルを設定した後、各デプロイメントおよびスケールアウト時に SLS ログ収集に自動的に接続します。その後、SLS コンソールでキーワードによるログ検索が可能になります。詳細については、「SLS へのログ収集の設定」をご参照ください。

収集を設定するには、ログ設定ページで次の操作を実行します。

1. SLS ログサービスを有効にするをオンにします。

2. 新しい SLS リソースを作成または既存の SLS リソースを使用を選択します。

3. 収集設定テーブルで、ログタイプ (コンテナ標準出力など) を選択し、ログソース (stdout.log など) を設定します。

4. 追加をクリックして、収集ルールを追加します。

   ログソースはワイルドカードをサポートしています。たとえば、/tmp/log/*.log は、/tmp/log ディレクトリとそのサブディレクトリ内の .log で終わるすべてのファイルを収集します。

環境変数を使用して Logtail 起動パラメータを設定することもできます。詳細については、「Logtail 収集パフォーマンスの向上」をご参照ください。

代わりにログを Kafka にインポートする場合は、ビジネスシナリオに基づいて、Kafka データを Elasticsearch などの別の永続ストアに配信できます。これにより、ログの一元管理と分析が容易になります。詳細については、「Kafka へのログ収集の設定」をご参照ください。

リアルタイムログ

SAE は標準出力ログを自動的に収集し、最新の 500 エントリを保持し、SAE コンソールで表示できるようにします。詳細については、「リアルタイムログの表示」をご参照ください。

リアルタイムログページで、Pod 名ドロップダウンリストからインスタンスを選択し、リアルタイムログの更新頻度を設定します (デフォルトは 15 秒です)。

最新の 500 エントリを超える標準出力ログを保持するには、ログをファイルにリダイレクトします。

1. 起動コマンド設定のargs フィールドに >> /tmp/stdout.log 2>&1 と入力して、標準出力と標準エラーを /tmp/stdout.log ファイルにリダイレクトします。

2. ファイルログで説明されているように、/tmp/stdout.log のファイル収集を設定します。Webshell を使用してファイルをオンラインで表示することもできます。Webshell は、インスタンスが正常に実行されている場合にのみ使用できます。

NAS

SAE は Apsara File Storage NAS をサポートしており、アプリケーション インスタンスのデータの永続性とインスタンス間のデータ配信の課題を解決します。NAS ストレージは、ECS インスタンスまたは SAE にマウントした後にのみアクセス可能です。詳細については、「NAS ストレージの設定」をご参照ください。

OSS

OSS は、バケットを視覚的に管理するための便利なツールとコンソールを提供します。OSS は、設定ファイルやフロントエンドの静的ファイルのマウントなど、読み取り集中型シナリオに適しています。SAE コンソールでアプリケーションをデプロイする際に OSS ストレージを設定すると、OSS コンソールでデータにアクセスできます。詳細については、「OSS ストレージの設定」をご参照ください。

ファイルのアップロードとダウンロード

SAE インスタンスからローカルマシンにファイルをダウンロードするには、Webshell を使用してインスタンスにログインし、組み込みのファイルアップロードおよびダウンロード機能を使用してください。詳細については、「Webshell を使用したファイルのアップロードとダウンロード」をご参照ください。

NAS や OSS ストレージの利用に加えて、ossutil ツールで OSS のファイルを操作することもできます。NAS と OSS は、コード開発とデバッグも簡素化します。定期チェックを通じて、または OSS にログをアップロードすることで、SAE アプリケーションを診断できます。Alibaba Cloud OSS を使用したログのアップロードとダウンロードの方法については、「定期チェックによるアプリケーションの診断」をご参照ください。

手動スケーリング

手動スケーリングは、手動 O&M のシナリオに適しています。 SAE のスケーリングはコンテナイメージに基づいているため、ECS インスタンスに直接デプロイされたアプリケーションのスケーリングよりも高速です。 詳細については、「手動スケーリング」をご参照ください。

スケジュールされたスケーリング

スケジュールされたスケーリングは、予測可能なトラフィックのシナリオに適しています。たとえば、飲食業や教育業界では、毎日明確な朝と夕方のビジネスピークがあるため、異なる時間帯に異なる数のインスタンスを設定することで、サーバーリソースを実際のビジネストラフィックに合わせることができます。詳細については、「自動スケーリングポリシーの設定」をご参照ください。

メトリクスベースのスケーリング

メトリクスベースのスケーリングは、比較的予測が困難なトラフィックのシナリオに適しています。現在、CPU、メモリ、TCP 接続、QPS、レスポンスタイム (RT) などのメトリクスをサポートしています。詳細については、「自動スケーリングポリシーの設定」をご参照ください。

ハイブリッドスケーリング

ハイブリッドスケーリングは、バーストトラフィックの処理とスケジュールされたスケーリングの両方が必要なシナリオに適しています。たとえば、インターネット、教育、飲食業界などで、既知の時間帯に対してインスタンス数をきめ細かく調整する場合に使用します。

たとえば、平日に伸縮性インスタンスの最大数を max、最小数を min に設定します。週末に min 個のインスタンスを維持する必要がない場合は、週末用に別のインスタンス数を設定して min を削減します。詳細については、「自動スケーリングポリシーの設定」をご参照ください。

スケジュールされた起動と停止

定時起動/停止機能は、名前空間ごとにアプリケーションをスケジュールに従って一括で起動および停止する機能です。たとえば、開発環境またはテスト環境のすべてのアプリケーションをスケジュールに従って起動および停止できます。開発環境またはテスト環境が毎日 08:00 から 20:00 までのみ必要で、それ以外の時間はアイドル状態である場合、SAE で定時起動/停止を設定することでコストを削減できます。詳細については、「定時起動/停止ルールを作成する」をご参照ください。

インフラストラクチャモニタリング

インフラストラクチャモニタリングは、CPU、負荷、メモリ、ディスク、ネットワーク、TCP 接続を対象としています。詳細については、「インフラストラクチャモニタリング」をご参照ください。インフラストラクチャモニタリングは現在、Alibaba Cloud CloudMonitor によって提供されているため、CloudMonitor コンソールにログインして、カスタムモニタリングダッシュボードを設定することもできます。

アプリケーションモニタリング

マイクロサービスアーキテクチャでは、監視システムがないと問題の検出と診断が困難になります。SAE は Application Real-Time Monitoring Service (ARMS) を統合して、アプリケーションダッシュボード、JVM モニタリング、スローコールモニタリング、トレース分析、アラートを提供し、企業がマイクロサービスアーキテクチャを採用する際のハードルを下げます。詳細については、「アプリケーションモニタリング」をご参照ください。

アプリケーションに統合される ARMS のエディションと適用料金は、アプリケーションのエディションによって異なります。

SAE の Standard Edition アプリケーションは、ARMS Basic Edition のモニタリングを統合しており、アプリケーションモニタリングを有効にすると無料で使用できます。Standard Edition は、ARMS Premium Edition のモニタリングを有効にするためのエントリポイントも提供します。Standard Edition アプリケーションで ARMS Premium Edition を有効にすると、追加料金が発生し、データを ARMS コンソールで表示する必要があります。詳細については、「Standard Edition のアプリケーションモニタリング」をご参照ください。

アラート設定

SAE では、前述のすべてのモニタリング項目に対してアラートを設定できます。詳細については、「アラート管理」をご参照ください。

マルチ vSwitch デプロイメント

データセンターレベルの障害に対応するには、本番向けの SAE アプリケーションに複数の vSwitch を設定します。vSwitch を作成する際は、IP アドレス数を十分に (100 個以上) 計画してください。IP アドレスが不足すると、作成失敗または弾性スケーリング失敗が発生します。詳細については、「Switch vSwitches」をご参照ください。

複数の vSwitch を使用すると、SAE は複数のゾーンにまたがってリソースを自動的にスケールします。そのため、リソースの分散状況を追跡する必要がなく、リソースプール全体の可用性を維持できます。たとえば、単一障害点またはゾーン障害が発生した場合、SAE は障害が発生したインスタンスと同数のインスタンスを正常なノードまたは別のゾーンに移行します。

複数の vSwitch は、次のいずれかの方法で設定します。

• 作成時 — 異なるゾーンにある 2 つ以上の vSwitch を選択して、マルチゾーンのディザスタリカバリを実現します。

• 作成後 — [Application Information] ページで [Multi-vSwitch Deployment] リンクをクリックし、vSwitch を追加します。

グレースフルな起動とシャットダウン

SAE にアプリケーションをデプロイする場合、通常は最初にスケールアウトし、その後スケールインします。トラフィックのグレースフルな起動とシャットダウンには、次の 2 つの主要な課題があります。

• 新たにスケールアウトしたインスタンスがトラフィックを処理できる状態になっているか。

• 古いインスタンスをどのようにグレースフルに破棄するか。

  SAE は Kubernetes を基盤としており、アプリケーションインスタンス向けの liveness プローブと、アプリケーションサービス向けの readiness プローブという 2 つのヘルスチェックを提供します。これら 2 つの課題に対応するため、SAE は readiness プローブをサポートしています。readiness プローブは、インスタンスが準備完了かどうかを定期的にチェックし、SAE はインスタンスの準備が完了した後にのみ、新しいインスタンスにトラフィックをルーティングします。チェックに失敗した場合、SAE はそのインスタンスにトラフィックをルーティングしません。古いインスタンスを破棄する前に、まずトラフィックから切り離されます。また、インスタンスを破棄する前のシャットダウンスクリプトと待機時間を設定できます。詳細については、「Configure health checks」をご参照ください。

liveness プローブは、インスタンスが起動したかどうかも定期的にチェックします。チェックに失敗した場合、SAE はコンテナを自動的に再起動します。この機能は、例外シナリオにおける自動運用保守をサポートしますが、障害時のコンテキストが失われ、原因調査が困難になる可能性があります。シナリオに応じて、liveness プローブを設定するかどうかを判断してください。

readiness プローブと liveness プローブに加えて、マイクロサービスのシナリオでは、サービスレジストリのキャッシュ問題を解決するためにマイクロサービスのグレースフルシャットダウンが必要です。コンシューマークライアントはデータをキャッシュするため、マイクロサービスプロバイダーのオフライン通知をタイムリーに受信できません。その結果、通常はプロバイダーインスタンスの登録をサービスレジストリから解除し、コンシューマーのキャッシュが更新されるまで待機する必要があります。この問題を解決するため、SAE は Microservices Engine (MSE) のグレースフルシャットダウン機能と連携し、このプロセスを製品機能として提供します。

本番環境では、自動スケーリングやロールバック、またはアップグレードなどの機能によって、短時間のサービス停止や多数のビジネスモニタリングエラーが発生する場合があります。これらの課題に対応するため、SAE はマイクロサービス向けのグレースフルな起動をサポートしています。コンシューマーは、プロバイダーがサービスレジストリに登録されるとすぐにマイクロサービスプロバイダーを呼び出せます。ただし、その時点では、データベース接続プールの初期化など、プロバイダー側で追加の初期化が必要な場合があります。トラフィックが多いマイクロサービスアプリケーションでは、グレースフルな起動を有効にしてください。詳細については、「Configure graceful start and shutdown」をご参照ください。

スロットリングと縮退

アプリケーションがマイクロサービスアーキテクチャとモノリシックアーキテクチャのどちらを採用していても、フラッシュセールなどのバーストトラフィックに直面すると、突然クラッシュする可能性があります。また、マイクロサービスアプリケーションではカスケード障害が発生する場合もあります。こうした高トラフィックのシナリオに対応するため、SAE は Microservices Engine (MSE) のトラフィック保護機能と連携しています。これにより、Java アプリケーションのスロットリングと縮退のルールを容易に設定および管理でき、アプリケーションの可用性を保護します。詳細については、「Traffic protection」をご参照ください。