弾性スケーリングのための5つの条件と6つの教訓をまとめました

序文

弾力的なスケーリングは、クラウド コンピューティング時代がもたらしたコア テクノロジーのメリットです。しかし、IT の世界では、システム機能をすべてのシナリオに考えなしに適用することはできません。この記事では、エンタープライズ レベルの分散アプリケーション サービス (EDAS) を使用するお客様がシステム アーキテクチャを設計する際に、弾力性のあるシナリオで遭遇した問題を体系的に整理し、5 つの条件と 6 つの教訓にまとめて皆さんと共有します。

5つの条件

1. 手動介入なしの起動

手動介入が必要かどうかは、弾性スケーリングと手動スケーリングの本質的な違いです。従来のアプリケーションの運用と保守では、プロセスを開始するには、環境の構築、依存サービスの構成の組み合わせ、ローカル環境の構成調整など、マシン上で一連の作業を手動で準備する必要があることがよくあります。アプリケーションがクラウド上にある場合は、セキュリティ グループ ルールと依存サービスのアクセス制御を手動で調整する必要がある場合があります。ただし、自動弾力性を使用すると、これらの手動アクションは実行不可能になります。

2. プロセス自体はステートレスである

正確に言うと、ステートレス性とは主に業務システムが運用中にデータにどの程度依存しているかを指します。プロセスの実行中にデータが生成され、生成されたデータはその後のプログラムの動作に永続的な影響を及ぼします。ロジックをコーディングする際、プログラマーは、システムが新しい環境で再起動されたときに、このデータによって動作に矛盾が生じるかどうかを考慮する必要があります。推奨される方法は、ストレージとコンピューティングを完全に分離できるように、データを最終的にストレージ システムに基づいて管理することです。

3. 早く始めて、威厳を持って去る

弾力性、特にクラウド上の弾力性の特徴の 1 つは、非常に頻繁に実行されることです。特にトラフィックが急増するビジネスでは、ある程度の不確実性が存在します。起動後、システムは「コールド」状態になることがよくあります。起動後にいかに素早く「加熱」するかが、弾力効果の鍵となります。弾力性が終了すると、容量が自動的に減少することがよくあります。このプロセスも自動であるため、トラフィックを自動的に削除する機能を技術的に実現できる必要があります。ここでのトラフィックには、HTTP/RPC だけでなく、メッセージ、タスク (バックグラウンド スレッド プール) のスケジュールなども含まれます。

4. ディスクデータが失われる可能性がある

アプリケーションの起動プロセス中に、アプリケーションはディスクを使用して起動依存関係を構成する場合があります。プロセスの実行中に、ログを印刷したり、データを記録したりするためにディスクを使用することもよくあります。弾性シナリオでは、プロセスはすぐに開始および終了し、終了するとディスク上のデータも失われます。したがって、ディスク データの損失に備える必要があります。ログをどう処理すればよいのかと疑問に思う人もいるかもしれません。ログは、統合された集約、クリーニング、およびレビューのために、ログ収集コンポーネントによって収集される必要があります。この点は 12 要素アプリでも強調されています。

5. 依存サービスが完全に利用可能

大規模なビジネスシステムでは、一人で戦うだけでは済まないことも多々あります。最も一般的なアーキテクチャでは、キャッシュやデータベースなどのいくつかの中心的なサービスも使用されます。ビジネスが弾力的に拡大すると、中央に依存するサービスの可用性を見落としやすくなります。依存するサービスが利用できなくなると、システム全体に雪崩のような影響が及ぶ可能性があります。

6つの教訓

1. 指標値の設定が不合理である

弾力性は、一般的に、指標の取得、ルールの計算、スケーリングの実行という 3 つの段階に分けられます。指標は通常、PaaS プラットフォームに付属する監視システムまたはコンポーネントを通じて取得されます。一般的な基本監視指標には、CPU/Mem/Load などがあります。短期的には、一部の基本指標の値は不安定になりますが、長期間にわたって見ると、通常は「安定した」状態になります。指標を設定する際には、短期的な特性に基づいて設定することはできず、より長期間にわたる一定の水位データを参照して、合理的な値を設定する必要があります。指標が多すぎてはならず、収縮指標と膨張指標の間には明確な数値の違いがある必要があります。

2. 「遅延」を指標として使う

多くの場合、システムの可用性を判断する主な要因は、システム画面が「ぐるぐる回転している」かどうかを確認することです。これは、システムが非常に遅いことを意味します。常識的に考えれば、すぐに容量を拡大する必要があるだろう。そのため、一部のお客様はシステムの平均 RT を容量拡張の指標として直接使用していますが、システムの RT は多次元です。たとえば、ヘルスチェックは一般的に非常に高速です。このような API の頻度がわずかに高くなると、平均値は低下します。顧客によっては API レベルを指定する場合もありますが、API にはさまざまなパラメータに基づくさまざまなロジックがあり、結果として RT も異なります。つまり、遅延に基づいて柔軟な戦略を立てることは非常に危険な行為です。

3. 単一の拡張仕様を指定する

拡張仕様はリソース仕様を参照します。たとえば、クラウドのシナリオでは、同じ 4c8g 仕様に対して、メモリ タイプ、コンピューティング タイプ、ネットワーク拡張タイプなどを指定できます。ただし、クラウドは大規模なリソース プールであり、一部の仕様は売り切れている可能性があります。単一の仕様のみを指定すると、リソースが利用できなくなり、拡張は失敗します。ここで最も危険なのは、事業拡大の失敗そのものではなく、事業拡大の失敗が発生した後のトラブルシューティングのプロセスが非常に長くなることです。

4. RPCリンクのアプリケーション戦略のみを考慮する

単一のアプリケーションであれば非常に簡単なことが多いのですが、難しいのはビジネス シナリオ全体を整理することです。アイデアを整理する簡単な方法は、アプリケーションの呼び出しシナリオに従って進めることです。アプリケーション間の呼び出しシナリオの観点から、一般的には同期（RPC、Spring Cloud などのミドルウェア）、非同期（メッセージ、RocketMQ などのミドルウェア）、タスク（分散スケジューリング、SchedulerX などのミドルウェア）の 3 種類に分けられます。通常、最初のケースはすぐに解決されますが、後者の 2 つは見落とされがちです。後者の 2 つのタイプで問題が発生した場合、トラブルシューティングと診断に最も時間がかかります。

5. 対応する視覚化戦略がない

自動スケーリングは典型的なバックグラウンド タスクです。大規模クラスターのバックグラウンド タスクを管理する場合は、直感的な視覚管理のために大きな画面を使用するのが最適です。拡張失敗の状況は黙って対処することはできません。コア事業の拡大に失敗すると、直接的に事業の失敗につながる可能性があります。しかし、実際に失敗が起こると、拡大戦略が効果的であったかどうかは気にされなくなることが多いです。障害が実際に膨張によって発生した場合、この点のトラブルシューティングは困難です。

6. 事前に適切な評価を行わない

クラウド コンピューティングは、弾力性のためにほぼ無限のリソース プールを提供しますが、ユーザーが軽減されるのはリソースを準備する作業だけです。マイクロサービス システム自体は複雑であり、単一のコンポーネントの容量変更はチェーン全体に影響を及ぼします。 1 つのリスクが除去されると、システムのボトルネックが移動し、容量の変化に伴って目に見えない制約が徐々に現れる可能性があります。したがって、ほとんどの場合、弾力性戦略は力ずくの考えに基づくことはできません。チェーン全体のストレステストと検証を適切に行い、グローバルな弾性構成に適応するための練習をする必要があります。やはり、高可用性の多面的な観点から、さまざまな技術的手段を事前に理解し、複数の利用計画を立てることをお勧めします。

終わり

クラウド ネイティブのシナリオでは、弾力性機能がより充実し、弾力性に使用できるインジケーターはビジネスに合わせてカスタマイズしやすくなります。アプリケーション PaaS プラットフォーム (エンタープライズ レベルの分散アプリケーション サービス EDAS/サーバーレス アプリケーション エンジン SAE など) は、クラウド ベンダーのコンピューティング、ストレージ、ネットワークの技術基盤機能を組み合わせて、クラウドの使用コストを削減できます。ただし、これにより、ビジネス アプリケーションにいくつかの課題が生じます (ステートレス性、構成コードの分離など)。より広い視点から見ると、これがクラウドネイティブ時代のアプリケーション アーキテクチャが直面している課題です。しかし、アプリケーションがネイティブ化していくにつれて、クラウドの技術的メリットはより身近なものになるでしょう。