Exploration and Practice of Serverless Elasticity in the Cloud Native System

Serverless 時代の到来

Serverless はその名の通り「サーバーレス」のアーキテクチャであり、サーバーに関するさまざまな運用保守の複雑さを隠蔽し、開発者がビジネスロジックの設計と実装により多くのエネルギーを注げるようにします。Serverless アーキテクチャの下では、開発者は上位レイヤーのアプリケーションロジック開発に集中するだけでよく、リソース申請、環境構築、負荷分散、スケーリングといったサーバー関連の複雑な操作はプラットフォーム側で管理されます。クラウドネイティブアーキテクチャのホワイトペーパーでは、Serverless の特徴を以下のようにまとめています。

・フルマネージドのコンピューティングサービスであり、顧客はコードを記述してアプリケーションを構築するだけでよく、サーバーベースの同質的で負担の大きいインフラの開発、運用保守、セキュリティ、高可用性に注意を払う必要がありません。

・汎用性があり、クラウド上のすべての重要なタイプのアプリケーションをサポートできます。

・自動スケーリングにより、リソース使用量のために事前に容量計画を立てる必要がなくなります。

・従量課金制により、アイドルリソースに課金することなく、企業が使用コストを効果的に削減できます。

Serverless の発展の軌跡を振り返ると、2012 年に Serverless の概念が初めて提唱されてから AWS がクラウドプロダクト Lambda をリリースするまでの期間に、Serverless への注目度が爆発的に上昇し、サーバーレスへの期待と想像力が業界全体を徐々に活気づけたことがわかります。ただし、Serverless のプロダクション推進と実装のプロセスは楽観視できるものではなく、Serverless の概念と実際のプロダクションの間にはギャップがあり、ユーザーの既存の使用体験と慣行に課題を突きつけています。

Alibaba Cloud は、Serverless がクラウドネイティブの先の確かな発展方向であると確信しています。FC や SAE など複数のクラウドプロダクトを順次リリースし、異なる分野や異なるタイプのアプリケーション負荷をカバーして Serverless 技術を利用できるようにしており、Serverless 概念全体の普及と発展を継続的に推進しています。

現在の Serverless の全体的な市場構造において、Alibaba Cloud は中国で Serverless プロダクトケイパビリティの第一水準を達成し、世界をリードしています。Forrester のマジッククアドラントでは、Alibaba Cloud が Serverless の分野で AWS と同等の位置にあることが明確に示されています。同時に、Alibaba Cloud の Serverless ユーザー数は中国で 1 位を占めており、2020 年の中国クラウドネイティブユーザー調査レポートでは、Alibaba Cloud の Serverless ユーザーの割合が 66% に達しています。さらに、Serverless 技術の導入に関する調査では、ますます多くの開発者や企業ユーザーが Serverless 技術をコアビジネスに適用している、または適用する予定であることが示されています。

Serverless とスケーリングの探求

クラウドのコアケイパビリティの一つとして、スケーラビリティは容量計画と実際のクラスター負荷の間の矛盾に関わります。2 つのグラフを比較すると、事前に計画された方法でリソースを配置した場合、リソース準備量とリソース需要量の不一致により、リソースの無駄やリソース不足が生じ、コストの増大やビジネスへの悪影響につながる可能性があります。理想的なスケーラビリティとは、準備されたリソースが実際に必要なリソースとほぼ一致し、アプリケーション全体のリソース使用率が高く、コストがビジネスの増減に伴って増減する状態です。同時に、容量問題によるアプリケーション可用性への影響が生じないことも重要です。これがスケーラビリティの価値です。

スケーラビリティは実装上、拡張性とフォールトトレランスに分けられます。拡張性は、基盤リソースがメトリックの変化に基づいて適応できることを意味し、フォールトトレランスは弾性的な自己修復によりサービス内のアプリケーションやインスタンスを健全な状態に保つことを指します。これらのケイパビリティの価値は、コスト削減とアプリケーション可用性の向上にあります。一方面ではリソース使用量がアプリケーションの実際の消費に適合し、もう一方面ではピーク時のアプリケーション可用性を向上させることで、市場の継続的な発展と変化に柔軟に対応できます。

以下では、現在主流の 3 つのスケーリングモードについて説明し分析します。

1 つ目は IaaS スケーリングで、各クラウドベンダーのクラウドサーバー向けスケーリング機能を代表します。たとえば、Alibaba Cloud ESS では、Cloud Monitor のアラートルールを設定することで対応する ECS の増減操作をトリガーできます。SLB バックエンドサーバーや RDS ホワイトリストの動的な増減もサポートして可用性を確保し、ヘルスチェックによる弾性的な自己修復ケイパビリティを実現します。ESS ではスケーリンググループの概念を定義しており、これがスケーリングの基本単位です。同じアプリケーションシナリオの ECS インスタンスの集合で、SLB や RDS と関連付けられています。また、シンプルルール、プログレスルール、目標追跡ルール、予測ルールなど、複数のスケーリングルールをサポートします。ユーザーの使用プロセスは、スケーリンググループとスケーリング設定の作成、スケーリングルールの作成、スケーリング実行のモニタリングと確認です。

Kubernetes のスケーリングは、主に水平スケーリング（HPA）に焦点を当てており、Kubernetes とその対応するマネージドクラウドプロダクト（Alibaba Cloud Container Service など）が代表です。プラットフォーム運用保守向けのアプリケーション指向インフラおよびプラットフォームとして、Kubernetes は主にコンテナレベルの管理とオーケストレーションに特化した組み込みケイパビリティを提供し、スケーリングケイパビリティは基盤 Pod の動的な水平スケーリングに焦点を当てています。Kubernetes HPA は Pod のモニタリングデータを定期的にポーリングし、目標期待値と比較します。リアルタイムのアルゴリズム計算で目標レプリカ数を生成し、Workload のレプリカ数に対して増減操作を実行します。ユーザーは実際の使用で対応するメトリックソース、スケーリングルール、対応する Workload を作成・設定し、イベントを通じてスケーリングの実行状況を確認できます。

最後に、アプリケーションプロファイルスケーリングを紹介します。これは主にインターネット企業内部で使用されており、Alibaba ASI キャパシティプラットフォームが代表例です。キャパシティプラットフォームはキャパシティ予測サービスとキャパシティ変更意思決定サービスを提供し、AHPA/VPA などの基盤キャパシティ変更コンポーネントをガイドしてキャパシティスケーリングを実現し、スケーリング結果に基づいてキャパシティプロファイルを修正します。プロファイル駆動を主軸にメトリック駆動を補助としたスケーリングケイパビリティを実現します。事前スケーリングとリアルタイム修正によりスケーリングリスクを低減します。スケーリングプロセス全体で ODPS と機械学習ケイパビリティを活用して、インスタンスモニタリングなどのデータを処理し、ベンチマークプロファイル、スケーリングプロファイル、大規模セールプロファイルなどのアプリケーションプロファイルを生成します。また、キャパシティプラットフォームを使用してイメージインジェクション、変更管理、障害フューズなどの操作を完了します。ユーザーの使用プロセスは、アプリケーションの登録、履歴データや経験に基づく対応するキャパシティプロファイルの生成、メトリックのリアルタイムモニタリングによるプロファイル修正、スケーリング実行のモニタリングと確認です。

比較からわかるように、各プロダクトのスケーリング機能モードは抽象的にはほぼ同じで、トリガーソース、スケーリング判断、トリガーアクションで構成されています。トリガーソースは一般的に外部モニタリングシステムに依存してノードメトリックとアプリケーションメトリックを収集・処理します。スケーリング判断は一般的に定期的なポーリングとアルゴリズム判断に基づき、一部は履歴データの分析予測やユーザー定義のタイミング戦略に基づきます。トリガーアクションはインスタンスの水平方向のスケールアウトとスケールインで、変更記録と外部通知を提供します。これを基盤として、各プロダクトはシナリオの豊富さ、効率、安定性の競争力を強化し、可観測性ケイパビリティを通じてスケーリングシステムの透明性を向上させ、問題のトラブルシューティングとスケーリング最適化のガイドを容易にすると同時に、ユーザーエクスペリエンスと定着度を向上させています。

各プロダクトのスケーリングモデルには一定の違いもあります。IaaS スケーリングは、老舗のスケーリングケイパビリティとして長い定着期間があり、強力で豊富な機能を備えていますが、クラウドベンダー間でのケイパビリティの均質化が進んでいます。スケーリング効率はコンテナと比較して制限があり、基盤 IaaS リソースと強く結合しています。Kubernetes はオープンソースプロダクトとして、コミュニティの力でスケーリングとベストプラクティスを継続的に最適化しており、大半の開発・運用担当者のニーズに合致しています。弾性行为と API を高度に抽象化していますが、スケーラビリティは限定的でカスタム要件のサポートには不十分です。アプリケーションプロファイルスケーリングはグループ内部向けに設計されており、グループの現在のアプリケーション状況とスケーリングニーズに基づいて設計され、リソースプールの予算コスト最適化、縮小リスク、複雑性などの課題に重点を置いています。外部の中小規模顧客への展開は容易ではありません。

最終目標から見ると、パブリッククラウドとインターネット企業の方向性は異なります。

・インターネット企業は、内部アプリケーションのトラフィック特性が顕著で、アプリケーション起動への依存度が高く起動速度が遅いため、Metrics により計算されたキャパシティデータのリアルタイム修正に基づく早期スケーリングのためにキャパシティプロファイルに依存することが多く、さらにリソースプール全体の容量と水位管理、在庫財務管理、オフライン混合デプロイなどの組織的な要求があり、キャパシティプロファイルの精度を十分に高めて期待されるリソース使用率を達成することが目標です。

・パブリッククラウドベンダーは外部顧客にサービスを提供し、より汎用的で普及性の高いケイパビリティを提供し、スケーラビリティを通じて異なるユーザーの差別化されたニーズを満たします。特に Serverless シナリオでは、突発的なトラフィックへの対応能力が重視されます。キャパシティ計画なしで、メトリックモニタリングと究極のスケーラビリティにより、アプリケーションリソースのほぼオンデマンド使用とプロセス全体のサービス可用性を実現することが目標です。

Serverless スケーリングの実装

クラウドコンピューティングのベストプラクティス、クラウドネイティブ開発の方向性、将来の進化トレンドとして、Serverless のコアバリューは迅速なデリバリー、インテリジェントなスケーリング、低コストにあります。

このような時代背景の中、SAE は時代の要請に応じて登場しました。SAE はアプリケーション指向の Serverless PaaS プラットフォームで、Spring Cloud や Dubbo などの主流開発フレームワークをサポートしています。ユーザーはコード変更なしで直接 SAE にアプリケーションをデプロイでき、オンデマンドで従量課金制で利用できます。これにより、アイドルリソースのコストを削減する Serverless のメリットを最大限に活用できると同時に、フルマネージドで運用保守不要の環境を体験できます。ユーザーはコアビジネスの開発に集中するだけでよく、アプリケーションライフサイクル管理、マイクロサービス管理、ログ記録、モニタリングなどの機能は SAE が処理します。

スケーリングの競争力は主にシナリオの豊富さ、効率、安定性にあり、まずは SAE のスケーリング効率の最適化について説明します。

SAE アプリケーションのライフサイクル全体（スケジューリング、init コンテナ作成、ユーザーイメージのプル、ユーザーコンテナ作成、ユーザーコンテナとアプリケーションの起動を含む）について、データ統計と可視化分析を行った結果、時間配分を簡略化した模式図から、アプリケーションライフサイクル全体でスケジューリング、ユーザーイメージのプル、アプリケーションのコールドスタートに時間が集中していることがわかります。スケジューリングフェーズでは、主な時間消費要因は SAE が現在実行しているユーザー VPC 操作です。このステップがスケジューリングと強く結合されているため時間がかかり、ロングテールタイムアウトの発生やリトライ失敗などの状況があり、スケジューリングリンク全体の処理時間が長くなっています。

ここで生じる疑問は、スケジューリング速度を最適化できるか、スケジューリングフェーズをスキップできるかです。ユーザーイメージのプルについては、イメージのプルと展開の処理時間を含み、特に大容量イメージのデプロイで顕著です。最適化の思路は、イメージのプルでキャッシュを活用できるか、イメージの展開を最適化できるかです。アプリケーションのコールドスタートについては、SAE には多数の個別アプリケーションやマイクロサービスの Java アプリケーションがあります。Java タイプのアプリケーションは起動時の依存度が高く、設定の読み込みが遅く、初期化プロセスが長いため、コールドスタート速度が分単位に達することがよくあります。最適化の方向性は、コールドスタートプロセスを回避し、アプリケーションに変更を加えずにユーザーにできるだけ意識させないようにすることです。

まず、SAE はインプレースアップグレードケイパビリティを導入しました。当初、SAE はリリースプロセスに Kubernetes ネイティブの Deployment ローリングアップグレード戦略を使用しており、まず新しいバージョンの Pod を作成してから古いバージョンの Pod を削除する方式でした。いわゆるインプレースアップグレードとは、Pod 内の 1 つ以上のコンテナバージョンのみを更新し、Pod オブジェクト全体や他のコンテナに影響を与えないアップグレードを指します。その原理は、Kubernetes の patch ケイパビリティを通じてコンテナをインプレースでアップグレードし、Kubernetes の readyGates ケイパビリティによりアップグレードプロセス中のトラフィック無損失を実現します。

インプレースアップグレードは SAE に多くの価値をもたらします。最も重要なのは、再スケジューリングとサイドカーコンテナ（ARMS、SLS、AHAS）の再構築を回避できることで、デプロイ全体の時間が Pod のライフサイクル全体を消費するものから、ビジネスコンテナのプルと作成のみに短縮されます。同時に、スケジューリングが不要になるため、新しいイメージを事前にノードにキャッシュでき、スケーリング効率が向上します。SAE は Alibaba のオープンソース OpenKruise プロジェクトが提供する CloneSet を新しいアプリケーションワークロードとして使用し、そのインプレースアップグレードケイパビリティと組み合わせることで、全体的なスケーリング効率が 42% 向上しました。

同時に、SAE はイメージウォームアップケイパビリティを導入しています。これにはスケジューリング前のウォームアップとスケジューリング中のウォームアップの 2 種類があります。スケジューリング前のウォームアップでは、SAE が共通の基本イメージをノード間でキャッシュし、リモートからの頻繁なプルを回避します。同時に、バッチシナリオではスケジューリング中のウォームアップがサポートされています。CloneSet のインプレースアップグレードケイパビリティと組み合わせることで、アップグレード中にインスタンスのノード分布を検知できます。これにより、最初のバッチで新しいバージョンのイメージをデプロイしながら、後続バッチのインスタンスが配置されるノードのイメージプリフェッチを実行でき、スケジューリングとユーザーイメージのプルを並列化できます。この技術により、SAE のスケーリング効率は 30% 向上しました。

前述の最適化ポイントはイメージのプル部分に関するものです。イメージの展開については、従来のコンテナ操作ではイメージデータの全量をダウンロードして展開する必要がありますが、コンテナ起動時に実際に使用するのは一部の内容のみである場合が多く、コンテナ起動時間が長くなります。SAE はイメージアクセラレーション技術により、元の標準イメージフォーマットを自動でランダム読み取りに対応した高速イメージに変換し、完全ダウンロード不要でイメージデータのオンライン展開を実現し、アプリケーション配布効率を大幅に向上させます。同時に、ACR EE が提供する P2P 配布ケイパビリティを活用することで、イメージ配布時間も効果的に短縮できます。

Java アプリケーションのコールドスタートの遅さという課題に対して、SAE と Dragonwell 11 は AppCDS 起動高速化戦略を提供します。AppCDS（Application Class Data Sharing）は、この技術を使用してアプリケーション起動時のクラスリストを取得し、その中の共有クラスファイルをダンプします。アプリケーション再起動時に共有ファイルを使用して起動することで、コールドスタート時間を効果的に短縮します。SAE のデプロイシナリオにマッピングすると、アプリケーション起動後に共有 NAS に対応するキャッシュファイルが生成され、次回のリリース時にそのキャッシュファイルを使用して起動できます。全体的なコールドスタート効率は 45% 向上しました。

アプリケーションライフサイクル全体の効率最適化に加え、SAE はスケーリングの最適化も実現しています。スケーリングプロセス全体は、スケーリングメトリック取得、メトリック判断、スケーリング操作実行の 3 つの部分で構成されています。スケーリングメトリック取得については、基本モニタリングメトリックデータは秒レベルの取得に達しており、レイヤー 7 アプリケーションモニタリングメトリックについては、SAE は透過的なトラフィックインターセプト方式を採用してメトリック取得のリアルタイム性能を確保する予定です。スケーリング判断フェーズでは、スケーリングコンポーネントは複数のキューで並行 Reconcile を実行し、キューの蓄積とレイテンシをリアルタイムでモニタリングします。

SAE のスケーリングには強力なメトリックマトリックス、豊富なポリシー設定、完全な通知・アラームメカニズム、包括的な可観測性が備わっています。複数のデータソースをサポートします。ネイティブ MetricsServer、MetricsAdapter、Prometheus、クラウドプロダクト SLS、CMS、SLB、外部ゲートウェイルートなどです。複数のメトリックタイプをサポートします。CPU、MEM、QPS、RT、TCP 接続数、送受信バイト数、ディスク使用率、Java スレッド数、GC 回数のカスタムメトリックなどです。メトリックのキャプチャと前処理の後、アプリケーションの特定シナリオに適したスケーリングポリシーをカスタマイズして設定できます。高速スケールアウトと低速スケールイン、高速スケールアウトと高速スケールイン、低速スケールアウトと低速スケールイン、スケールアウトのみ、スケールインのみ、DRYRUN、アダプティブスケーリングなどがあります。

同時に、より細かいスケーリングパラメータ設定も可能です。インスタンスの上限・下限、メトリック間隔、ステップ比範囲、クールダウン時間とウォームアップ時間、メトリック収集サイクル、集約ロジック、CRON 式などです。今後はイベント駆動型ケイパビリティもサポートされる予定です。スケーリングがトリガーされると対応するスケールアウト・スケールイン操作が実行され、ストリーム切り替えを通じてトラフィックの無損失が保証されます。さらに、充実した通知・アラームケイパビリティ（DingTalk、Webhook、電話、メール、SMS）によりユーザーにリアルタイムで通知できます。スケーリングは包括的な可観測性を提供し、スケーリングの判断時間と判断内容を明確に表示し、インスタンスステータスのトレーサビリティとインスタンス SLA のモニタリングを実現します。

SAE のスケーリング機能はシナリオの豊富さにおいても競争力を備えています。以下では、SAE が現在サポートしている 4 つのシナリオに焦点を当てて説明します。

・タイミングスケーリング：アプリケーションのトラフィック負荷に周期性がある場合に設定します。時間、曜日、日付のサイクルに基づいてアプリケーションのインスタンス数を定期的にスケーリングできます。たとえば、8:00〜20:00 の昼間トラフィックの時間帯は 10 インスタンスを維持し、それ以外の時間帯はトラフィックが少ないため 2 インスタンスに縮小、または 0 にスケールインできます。リソース使用率に周期性があるアプリケーションシナリオに適しており、証券、医療、政府、教育などの業界で多く使用されています。

・メトリックスケーリング：期待されるモニタリングメトリックルールを設定でき、SAE はアプリケーションのメトリックを設定されたメトリックルール内に安定させます。デフォルトでは高速スケールアウト・低速スケールインのモードを採用して安定性を確保します。たとえば、アプリケーションの CPU メトリックの目標値を 60%、QPS を 1000、インスタンス数の範囲を 2〜50 に設定します。このアプリケーションシナリオは突発的かつ典型的な周期性トラフィックに適しており、インターネット、ゲーム、ソーシャルプラットフォームなどの業界で多く使用されています。

・ハイブリッドスケーリング：タイミングスケーリングとメトリックスケーリングを組み合わせることで、異なる時間帯、曜日、日付に対して異なるメトリックルールを設定でき、複雑なシナリオのニーズにより柔軟に対応できます。たとえば、8:00〜20:00 の時間帯は CPU メトリックの目標値を 60%、インスタンス数の範囲を 10〜50 に設定し、それ以外の時間はインスタンス数の範囲を 2〜5 に縮小します。周期的なリソース使用率と突発的かつ典型的な周期性トラフィックの両方があるアプリケーションシナリオに適しており、インターネット、教育、飲食などの業界で多く使用されています。

・アダプティブスケーリング：SAE はトラフィックサージシナリオ向けに最適化されており、トラフィックサージウィンドウを使用して現在のメトリックにトラフィックサージの問題があるかどうかを計算し、トラフィックサージの強度に応じてスケールアウトに必要なインスタンス数を計算する際に冗長性を追加します。サージモードではスケールインは許可されません。

安定性は SAE のスケーリングケイパビリティ構築プロセスにおいて非常に重要な部分です。スケーリングプロセス中にユーザーアプリケーションが期待される動作に従ってスケールアップ・スケールダウンし、プロセス全体の可用性を確保することが注目点です。SAE のスケーリングは全体的に高速スケールアウト・低速スケールインの原則に従い、マルチレベルの平滑化とアンチシェイキングにより実行の安定性を確保しています。同時に、メトリックが急増するシナリオではアダプティブケイパビリティを使用して事前にスケールアウトします。SAE は現在 4 レベルのスケーリング平滑化設定をサポートし、安定性を確保しています。

・第 1 レベルの平滑化：メトリック取得サイクル、単一メトリック取得のタイムウィンドウ、メトリック計算の集約ロジックを設定

・第 2 レベルの平滑化：メトリック値の許容範囲と間隔スケーリングを設定

・第 3 レベルの平滑化：単位時間あたりのスケーリングステップサイズ、パーセンテージ、上限・下限を設定

・第 4 レベルの平滑化：スケーリングのクールダウンウィンドウとインスタンスのウォームアップ時間を設定

Serverless スケーリングのベストプラクティス

SAE のスケーリング機能は、トラフィックピーク到達時の自動スケールアウトとピーク終了後の自動スケールインを効果的に実現します。高信頼性、運用保守不要、低コストでアプリケーションの安定運用を確保します。使用時に以下のスケーリング設定のベストプラクティスに従うことを推奨します。

・ヘルスチェックとライフサイクル管理の設定

アプリケーションのヘルスチェックを設定して、スケーリング中のアプリケーションの全体的な可用性を確保し、アプリケーションが起動・実行中で、トラフィック受信の準備ができた状態でのみトラフィックを受け取るようにすることを推奨します。また、ライフサイクル管理の Prestop を設定して、スケールイン時にアプリケーションが期待通りにグレースフルオフラインされるようにすることも推奨します。

・指数バックオフリトライメカニズムの採用

スケーリングが間に合わない、アプリケーション起動が間に合わない、またはアプリケーションがグレースフルオンライン・オフラインされていないことによるサービス呼び出し例外を回避するため、呼び出し側はサービス呼び出しに指数バックオフリトライメカニズムを採用することを推奨します。

・アプリケーション起動速度の最適化

スケーリング効率を向上させるため、以下の側面からアプリケーションの作成速度を最適化することを推奨します。

・ソフトウェアパッケージの最適化：クラスローディングやキャッシングなどの外部依存関係による過剰なアプリケーション起動時間を削減するための起動時間最適化

・イメージの最適化：イメージサイズを小さくし、インスタンス作成時のイメージプル時間を短縮します。オープンソースツールの Dive を使用してイメージレイヤー情報を分析し、イメージレイヤーに対して対象を絞った変更を加えることができます

・Java アプリケーションの起動最適化：SAE Dragonwell 11 を活用して、Java 11 ユーザーにアプリケーション起動高速化機能を提供します

・スケーリングメトリックの設定

スケーリングメトリック設定。SAE は基本モニタリングとアプリケーションモニタリングの複数のメトリック組み合わせをサポートしています。現在のアプリケーションの属性（CPU 重視 / メモリ重視 / IO 重視）に基づいて柔軟に選択できます。

基本モニタリングとアプリケーションモニタリングの対応するメトリックの履歴データ（過去 6 時間、12 時間、1 日、7 日のピーク値、P99 値、P95 値など）を確認して、メトリックの目標値を閲覧・見積もることができます。PTS などの負荷テストツールを使用して、アプリケーションが対応できる同時リクエスト数、必要な CPU とメモリの量、高負荷条件下でのアプリケーション応答モードを把握し、アプリケーションキャパシティのピークサイズを評価できます。

メトリックの目標値は、可用性とコストの間で戦略的に選択する必要があります。たとえば以下の通りです。

・可用性最適化戦略：メトリック値 40% を設定

・可用性・コストバランス戦略：メトリック値 50% を設定

・コスト最適化戦略：メトリック値 70% を設定

同時に、スケーリング設定では上流・下流の依存関係、ミドルウェア、DB などの関連依存関係を整理し、対応するスケーリングルールや流量制限・デグレード方法を設定して、スケールアウト時にリンク全体の可用性を確保する必要があります。

スケーリングルールを設定した後は、継続的にモニタリングと調整を行い、キャパシティを実際のアプリケーション負荷に近づけていきます。

・メモリメトリックの設定

メモリメトリックについては、一部のアプリケーションタイプ（Java の JVM メモリ管理、Glibc の Malloc/Free 操作など）でメモリ割り当てに動的メモリ管理を使用している場合の考慮が必要です。アプリケーションのアイドルメモリがオペレーティングシステムにタイムリーに解放されず、インスタンスが消費する物理メモリはタイムリーに削減されません。新しいインスタンスを追加しても平均メモリ消費量は減少しないため、スケーリングをトリガーできません。そのため、このタイプのアプリケーションにはメモリメトリックを使用することをお勧めしません。

・Java アプリケーションのランタイム最適化：物理メモリを解放し、メモリメトリックとビジネスの関連性を高める

Dragonwell ランタイム環境で、JVM パラメータを追加して ElasticHeap 機能を有効化し、Java ヒープメモリの動的スケーリングをサポートして、Java プロセスが実際に使用する物理メモリの使用量を節約できます。

・最小インスタンス数の設定

スケーリングの最小インスタンス数を 2 以上に設定し、複数のアベイラビリティゾーンの vSwitch を設定することを推奨します。これにより、基盤ノードの異常によりインスタンスがエビクトされたり、アベイラビリティゾーンに利用可能なインスタンスがない場合にアプリケーションが動作停止するのを防ぎ、アプリケーション全体の高可用性を確保します。

・最大インスタンス数の設定

スケーリングの最大インスタンス数を設定する際は、アベイラビリティゾーン内の IP アドレス数が十分かどうかを考慮し、新しいインスタンスを追加できない状況を防止する必要があります。コンソールの vSwitch で現在のアプリケーションの利用可能な IP アドレス数を確認できます。利用可能な IP アドレスが少ない場合は、vSwitch の交換または追加を検討してください。

・最大スケーリングへの到達

アプリケーション概要で現在スケーリング設定が有効なアプリケーションを確認でき、現在のインスタンス数がピークに達したアプリケーションをタイムリーに発見し、スケーリング最大設定が適切かどうかを再評価できます。期待される最大インスタンス数がプロダクト制限を超える場合は、ワークオーダーのフィードバックを通じて制限を引き上げることができます（現在の制限は 1 アプリケーションあたり 50 インスタンス）。

・アベイラビリティゾーンの再バランス

スケーリングによるリサイズがトリガーされた後、アベイラビリティゾーンの割り当てが不均等になる可能性があります。インスタンスリストでインスタンスが属するアベイラビリティゾーンを確認できます。アベイラビリティゾーンが不均等な場合は、アプリケーションの再起動操作により再バランスを実現できます。

・スケーリング設定の自動復元

アプリケーションデプロイなどのチェンジオーダー操作を実行する際、SAE は 2 つの操作間の競合を避けるために現在のアプリケーションのスケーリング設定を停止します。チェンジオーダー完了後にスケーリング設定を復元したい場合は、デプロイ時に「システム自動復元」をチェックできます。

・スケーリング履歴

SAE のスケーリング有効化アクション。現在、イベントを使用してスケールアウト・スケールインの時間とアクション、リアルタイムおよび履歴の判断記録、判断内容の可視化機能を確認でき、スケーリング戦略の有効性を評価し、必要に応じて調整できます。

・スケーリングイベント通知

DingTalk、Webhook、SMS、電話など複数の通知チャネルを組み合わせることで、スケーリングのトリガーステータスをタイムリーに把握できます。

最後に、SAE のスケーリング機能を活用した顧客事例を紹介します。2020 年の COVID-19 パンデミック時、あるオンライン教育顧客のビジネストラフィックが 7〜8 倍に急増し、ハードウェアコストとビジネスの安定性が大きなリスクに直面しました。従来の ECS アーキテクチャを採用した場合、顧客は非常に短期間でインフラストラクチャアーキテクチャをアップグレードする必要があり、ユーザーのコストとエネルギーに大きな課題となります。しかし、SAE を採用すれば、ユーザーは変換コストゼロで Serverless の技術的メリットを享受できます。SAE のマルチシナリオスケーリングポリシー設定、スケーリング適応、リアルタイム可観測性を組み合わせることで、ピーク時のユーザーアプリケーションのビジネス SLA を確保し、優れたスケーリング効率によりハードウェアコストを最大 35% 削減しました。

まとめると、スケーリング開発の方向性、特に Serverless シナリオでは突発的トラフィックへの対応能力がより重視されます。キャパシティ計画なしで、メトリックモニタリングと究極のスケーリングケイパビリティにより、アプリケーションリソースのほぼオンデマンド使用とプロセス全体のサービス可用性を実現することが目標です。SAE はスケーリングコンポーネントとアプリケーションのライフサイクルを継続的に最適化して秒レベルのスケーリングを実現し、スケーリング性能、シナリオの豊富さ、安定性において中核的な競争力を備えており、従来のアプリケーションを Serverless に変換する最適な選択肢です。