How to quickly build low-cost and highly elastic cloud applications

01 クラウドアプリケーションのリソース選択

クラウドアプリケーションの構築では、主に安定性、コスト、柔軟性の 3 つの要素を考慮する必要があります。その中で、安定性にはインフラの安定性、アプリケーションの安定性、およびアプリケーションの可観測性が含まれます。

ユーザーは、インフラが安定し、インスタンスが安定的に稼働し、迅速な復旧が可能なクラウドプラットフォームを選択する必要があります。アプリケーションの可観測性については、クラウドプラットフォームのモニタリングデータやモニタリングアプリケーションを活用して、アプリケーションの安定性を維持できます。

コスト面では、主にインスタンス仕様、決済タイプ、リソース管理が関わります。決済タイプの選択によってアプリケーションコストが決まります。同じインスタンスでも異なる決済タイプを使用すると、コストは大きく異なります。

安定性とコストの間には相反する関係があり、サービスの安定性を向上させるためにリソースやマシンを追加すると、コストが上昇します。アプリケーションの負荷が急増した場合、安定性が低下します。オートスケーリングは、安定性とコストの矛盾を効果的に解消できます。

02 クラウド上でのアプリケーション構築の考慮事項



1. インスタンスタイプの選択

Alibaba Cloud は主に、汎用コンピューティング、ヘテロジニアスコンピューティング、ベアメタルおよび高性能コンピューティングの 3 つのインスタンスカテゴリを提供しています。ユーザーはアプリケーションの特性に応じて適切なインスタンスを選択する必要があります。

アプリケーションがメモリベースのデータベースである場合、メモリ最適化インスタンスを選択することで、リソースのミスマッチによる無駄を避けられます。ベアメタルおよびヘテロジニアスコンピューティングは、機械学習などリソース要件の高いアプリケーションに適しています。

2. 決済方法

Alibaba Cloud には、後払いと前払いの 2 種類の決済方法があります。

・後払いは、インスタンスを使用してから課金される方式です。従量課金とプリエンプティブルインスタンスの 2 種類に分かれます。その中で、プリエンプティブルインスタンスはアプリケーションのコストを効果的に削減できます。

・前払いは、実際の使用前に課金されます。

前述の図に示すように、月額サブスクリプションのインスタンスはユーザーが手動でリリースできません。従量課金およびプリエンプティブルインスタンスは、ユーザーがアクティブにリリースできます。リザーブドインスタンスは、インスタンス数量による控除方式で割引を提供します。

3. スポットインスタンス

スポットインスタンスの価格は動的に変動します。ユーザーはスポットインスタンスの価格変動に応じて入札します。

ユーザーの入札価格がスポットインスタンスの価格変動を上回っている場合、インスタンスを継続して使用できます。スポットインスタンスの価格が入札価格を上回ると、システムはインスタンスをリリースします。スポットインスタンスの料金は従量課金より安価ですが、システムによる自動回収のリスクがあり、安定性は比較的低くなります。

4. 低コストなリソース管理スキーム

アプリケーションの負荷は主に 3 つのフェーズに分けられます。

・第 1 フェーズでは、基本負荷に対応し、月額サブスクリプションとリザーブドインスタンスを使用して安定的なビジネス負荷を支えます。

・第 2 フェーズでは、日次ピーク負荷に対応し、従量課金インスタンスを使用してステートフルかつ動的なビジネス負荷をサポートし、サービスの安定性を確保しつつコストを削減します。アプリケーションのピーク負荷が発生した際、動的スケーリングによるピーク時のオートスケーリングと、従量課金インスタンスによる低ピーク時のオートスケーリングを実現できます。

・第 3 フェーズでは、負荷が突発的に増加する場面で、プリエンプティブルインスタンスを使用してステートレスかつフォールトトレラントなビジネス負荷を支えます。プリエンプティブルインスタンスにより、サービスの安定性を確保し、より低いコストで優れた効果を得られます。

03 オートスケーリングで安定的かつ低コストなクラウドソリューション

1. オートスケーリング機能の概要

前述の図に示すように、右の図はオートスケーリングの基本機能を示しています。左の図は従来のビジネスリソース運用シナリオを示しています。黒い線はビジネス負荷を表し、これは動的に変化します。緑の曲線はリソースデプロイを表します。リソースは従来の人的介入によってデプロイされ、ユーザーは長期間にわたり固定リソースを保有し続けます。

トラフィックが最初のポイントに達すると、ビジネス負荷はピーク期間まで増加し、リソース量はピーク期間のトラフィックをカバーしますが、サービス負荷に大きな変化はありません。ビジネスの低ピーク期間には、リソース削減は行われず、サービスリソースは最大トラフィックに合わせてデプロイされたままです。現在のビジネス負荷が急激に増加した場合、既存のリソースデプロイではビジネス負荷の需要を満たせず、サービスの安定性に影響を及ぼします。

従来の手動介入モードには、リソースの無駄遣い、サービスの安定性への影響、高い手動運用保守コストの 3 つの欠点があります。

オートスケーリングモードでは、黒い曲線がビジネス負荷を表し、緑の曲線がリソース量を表します。サービス負荷が急増してリソース量が増加すると、オートスケーリングによる拡張によりサービスの安定性が確保されます。ビジネス負荷が減少すると、オートスケーリングによる縮小によりサービスの安定性を保証しつつ、コストを削減できます。

従来の方法と比較して、オートスケーリングのリソースコストはより低く、明らかなリソースの無駄がありません。オートスケーリングサービスはより安定的で、トラフィックが急増するシナリオでもサービスの安定性を確保できます。さらに、システム自動化管理により人的介入が不要で、人件費を削減できます。

2. オートスケーリングの必要条件

オートスケーリングの必要条件は前述の図に示す通りです。すべてのアプリケーションがすぐにオートスケーリング機能を利用できるわけではありません。オートスケーリングには主に、モニタリング機能、デプロイと更新機能、セルフサービス機能の 3 つの側面があります。

モニタリング機能には主に、モニタリングデータ取得機能、指標集約機能、モニタリングアラーム機能の 3 つがあります。モニタリング機能では、ビジネス負荷、CPU 指標、または QPS 指標の測定を理解する必要があります。モニタリングアラーム機能は、CPU 使用率が 50% を超えた場合にイベントをトリガーし、オートスケーリングによるスケールアウト・スケールインを実行します。

指標集約機能はアプリケーションに応じて集約する必要があります。プライベートクラウドに 100 台のマシンがあり、アプリケーションがそのうち 20 台のみを使用している場合、指標集約時には 20 台のマシンのみを集約対象とします。さらに、20 台のマシンの CPU 指標を平均化して、特定の指標集約を実現することもできます。

オートスケーリング時に必要なデプロイおよび更新機能には、3 つのコア指標があります。

1 つ目は、アプリケーションソフトウェアのデプロイメディアを理解することです。たとえば、イメージを使った公開方法です。

2 つ目は、自動化されたデプロイ方法を理解することです。オートスケーリングによる拡張時に、インスタンスの拡張とアプリケーションのデプロイを同時に行う必要があります。

3 つ目は、アプリケーションの自動化アップグレードです。アプリケーションに 10 台のマシンがあり、オートスケーリングにより 2 台拡張する場合、アプリケーションデプロイ時には既存の 10 台に加えて新しい 2 台にもアプリケーションをデプロイする必要があります。したがって、ユーザーはアプリケーションのデプロイとアップグレード機能を考慮する必要があります。

セルフサービス機能の面では、オートスケーリングによる拡張後にアプリケーションインスタンスが正常にサービスを提供できるかを判断する必要があります。

インスタンスがオートスケーリングにより拡張された際に Web サービスが起動するものの、その Web サービスが対応するロードバランシングに接続されていない場合があります。この場合、ユーザーは自身のサービスを評価し、セルフサービス機能があるかどうかを確認する必要があります。外部サービスが登録に依存しているかどうか、アプリケーションインスタンスに自動登録と登録解除の機能があるかどうかも確認が必要です。

3. オートスケーリングのコアコンセプト

Alibaba Cloud Auto Scaling を通じて、スケーリンググループでマシン群を管理し、スケーリンググループのインスタンスを使用して指標収集とインスタンスデプロイを行います。

スケーリング設定には主に 2 つのポイントがあります。インスタンス仕様に関しては、インスタンス設定とインスタンス拡張時に追加のパラメータ設定が必要です。管理が必要な場合はタグ付けを行うことができます。

インスタンスミラーリングに関しては、コンテナを使用してサービスを提供する場合、アプリケーションイメージを指定できます。これにより、オートスケーリングによる拡張時にユーザーのニーズを満たし、サービスを提供できます。

スケーリングルールと通知に関しては、Auto Scaling がトリガーされた際、Alibaba Cloud はスケーリングアクティビティの成功と失敗を通知でき、ユーザーはリアルタイム通知を拒否することもできます。Auto Scaling は Cloud Monitor のシステムイベントと MNS トピックキューに接続されています。

スケーリングタスクに関しては、スケジュールタスク、アラームタスク、自動または手動トリガーの 3 種類があります。

スケジュールタスクは、ピークと低負荷の期間に明確な時間ルールがある場合に使用します。ピーク期間前に定期的にスケールアウトし、ピーク期間後に定期的にスケールインします。

アラームタスクは、CPU または QPS のモニタリング指標を通じて動的にスケールアウト・スケールインを実行します。自動または手動でスケーリングをトリガーし、動的な拡張と縮小を行います。

4. スケーリングモード

前述の図に示すように、スケーリングヘルスモードは正常でない ECS インスタンスをリリースまたは削除します。スケーリンググループは、デフォルトですべてのモードにこの機能を提供します。

スケーリング固定モードは、MinSize を指定して ECS インスタンスの固定数を保証します。ビジネス変動が小さいが高可用性が求められるシナリオに適しており、通常モニタリングモードと組み合わせて使用されます。

手動スケーリングモードでは、API を通じて ECS インスタンスを手動でスケーリングし、手動で観測したモニタリングデータまたはユーザー独自のモニタリングシステムに基づいてスケーリングルールを手動で実行します。MinSize または MaxSize を手動で調整した後、ECS インスタンスが自動的に作成またはリリースされ、インスタンス数は Min と Max の間に維持されます。

スケーリングスケジュールモードは、設定されたタイミング（例：金曜日 13:00:00）に従って ECS インスタンスを増減させます。ビジネス変動に規則性があるシナリオに適しています。

スケーリング動的モードは、モニタリング指標の負荷に基づき、設定に従って ECS インスタンスを自動的に作成またはリリースします。ビジネス変動に明らかな規則性がないシナリオに適しています。単機の CPU が 50% を超えた場合、インスタンスを追加してサービスの安定性を確保しつつ、単機の負荷を下げることができます。

5. スケーリングルール

イベントがスケーリングをトリガーした際、どのようにスケールアウトまたはスケールインを実行するのでしょうか。

前述の図に示すように、一般的なスケーリングルールは、CPU が 20% を超えた場合に 4 台のインスタンスを追加するようなルールです。ビジネス負荷のトランザクション要件を満たせない場合、マシン負荷は上昇し続け、スケーリングも継続されます。

ステップスケーリングルールは、スケーリングのトリガーしきい値を定義します。異なるしきい値は異なるスケーリングアクションをトリガーします。

ターゲット追跡スケーリングルールは、CPU を 50% に維持するよう設定します。サービス負荷が急増した場合、システムは次のポイントで 20 台以上のインスタンスを追加する必要があると計算します。ターゲット追跡スケーリングルールに基づき、20 台以上のインスタンスを一括で拡張することで、トラフィック急増シナリオに迅速に対応できます。

6. スケーリングモードのベストプラクティス

次に、異なるアプリケーションシナリオに対するスケーリングモードの選択方法を紹介します。

アプリケーションシナリオの高低ピークが比較的固定されている場合、スケジュールモードを使用して、設定に基づいて定期的に ECS インスタンスを増減させることができます。たとえば、金曜日の 13:00:00 に実行するなどです。

安定性要件が高く、トラフィックが急増するアプリケーションシナリオでは、固定モードと動的モードを使用できます。月額サブスクリプションのインスタンスを手動で追加してビジネスの基盤を確保します。ビジネス負荷が急増した際、動的スケーリングにより一部のリソースを補償してサービスの安定性を保証します。トラフィックが急増する場合でも、サービスリソースを完全に保証します。

コスト要件が高い場合、従量課金インスタンスと動的スケーリングを使用してポリシーを設定できます。CPU 使用率など、Cloud Monitor 指標の負荷に基づき、設定に従って自動的にスケーリングを実行します。

比較的安定的な負荷ピークを持つが突発的なシナリオに直面する場合、定期的なスケーリング設定によるスケールイン・スケールアウトをベースに、モニタリング指標に基づいて動的に ECS インスタンス数をさらに調整できます。

7. コスト最適化のベストプラクティス

インスタンスリソースに動的なスケーリング機能がある場合、どのようにインスタンスを拡張すべきでしょうか。前述の図に示すように、最も理想的な方法は、ベースを月額サブスクリプションのインスタンスにしてサービスの安定性を確保することです。サービスピーク時には、オンデマンド使用がスポットインスタンスより安定しています。比較的低コストで高い安定性を備えています。

8. お客様事例

グローバルテクノロジー企業である Mobvista は、デジタル時代におけるグローバルなビジネス成長の推進に取り組んでいます。企業の成長を可能にする「SaaS ツールエコシステム」の構築に注力し、企業のグローバル展開を支援しています。

広告ビジネスの規模が大きく、リソース需要も多いため、汇量科技の安定性に対する要求は高いです。リソース需要が十分なシナリオにおいて、低コストで顧客のリソース需要を満たすことが求められています。

Alibaba Cloud は、Auto Scaling、従量課金、およびスポットインスタンスの組み合わせにより、顧客のニーズに対応しています。自動補償メカニズムを通じてサービスの安定性を保証し、リソースコストを 30% から 40% 削減しています。自動補償とは、スポットインスタンスが回収された際に、Auto Scaling がその回収を検知し、従量課金インスタンスを自動的に補償してスポットインスタンスの代わりに配置することで、サービスの安定性をさらに確保する仕組みです。