Five Conditions and Six Lessons for Elastic Scaling

はじめに

オートスケーリングは、クラウドコンピューティング時代がもたらしたコア技術の恩恵です。ただし、IT の世界において、あらゆるシナリオにそのまま適用できるシステム機能は存在しません。本記事では、Enterprise Distributed Application Service (EDAS) をオートスケーリング環境で活用する際に、システムアーキテクチャ設計で直面する問題を体系的に整理し、5 つの条件と 6 つの教訓としてまとめました。

5 つの条件

1. 手動介入なしで起動する

手動介入が必要かどうかは、オートスケーリングと手動スケーリングの本質的な違いです。従来のアプリケーション運用保守では、プロセスを起動する前にマシン上で多くの準備作業を手動で行う必要がありました。たとえば、環境構築、サービス依存の設定整理、ローカル環境設定の調整などです。クラウド環境ではさらに、セキュリティグループのルール調整やアクセス制御の変更などが必要になる場合もあります。しかし、こうした手動タスクは自動スケーリングでは実行不可能です。

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

ステートレスとは、業務システムが実行中にデータに依存しないことを指します。プロセス実行中に生成されたデータは、後続のプログラムの動作に継続的な影響を与えます。コーディング時に、このデータが新しい環境でシステムを再起動した際に動作の不整合を引き起こさないかを考慮する必要があります。推奨されるアプローチは、データをストレージシステムに永続化し、ストレージとコンピュートを真に分離することです。

3. 迅速な起動と品位ある退出

クラウド上でのスケーリングは頻繁に発生する特徴があり、特にトラフィック急増を伴うビジネスには不確実性があります。起動直後のシステムはコールドスタート状態にあり、いかに速やかにウォームアップするかがスケーリングの効果を左右する重要な要素です。スケーリング終了後には自動スケールインが行われます。このプロセスも自動であるため、技術的にトラフィックの自動切り離しを実現できる必要があります。ここでのトラフィックには、HTTP/RPC だけでなく、メッセージやバックグラウンドスレッドプールによるタスクスケジューリングも含まれます。

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

アプリケーション起動時にディスクを使って依存関係を設定したり、実行中にログを出力したりデータを記録したりすることがあります。スケーリングではプロセスの速度が重視され、ディスク上のデータは失われるため、ディスクデータの損失に備える必要があります。ログの処理方法については、ログ収集コンポーネントを通じて一元的に集約、クリーニング、参照すべきです。これは 12 factor アプリでも推奨されています。

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

大規模な業務システムは、単独で運用されるものではありません。キャッシュやデータベースなどの共通サービスは、典型的なアーキテクチャでも使用されています。スケーリング時に、これらの依存サービスの可用性を見落としがちです。依存サービスが利用できない場合、システム全体に雪崩効果が及ぶ可能性があります。

6 つの教訓

1. インジケーター値の設定が不合理

スケーリング全体は、インジケーター取得、ルール計算、スケーリング実行の 3 つのフェーズに分かれます。インジケーターは通常、モニタリングシステムや PaaS プラットフォームのコンポーネントから取得されます。一般的な基本監視インジケーターには、CPU、Mem、Load などがあります。短期的には一部の基本インジケーター値に不安定な特性が見られますが、長期的には通常、安定した状態になります。インジケーターの閾値を設定する際、短時間の特徴を根拠にしてはなりません。長期の水位データを参照することで、合理的な値を設定できます。また、インジケーターの数は絞り込み、スケールインとスケールアウトの指標には明確な数値差を設けるべきです。

2. 遅延をインジケーターとする

多くの場合、システムの可用性を判断する際、画面がぐるぐると回転しているか、つまりシステムのレスポンスが非常に遅いかを確認します。容量がまもなく足りなくなるため、すぐにスケールアウトが必要だと推測できます。そのため、システムの平均 RT をスケールアウトのインジケーターとして直接使用するケースがあります。しかし、システムの RT は多次元的です。たとえば、ヘルスチェックは一般的に非常に高速です。こうした API がより頻繁に現れると、平均値が下がります。API レベルで詳細に追跡しても、API のロジックがパラメータによって異なり、RT も異なる結果になります。結局、遅延に基づいてスケーリング戦略を立てるのは非常に危険です。

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

拡張仕様とはリソース仕様を指します。たとえば、クラウドでは同じ 4vCPU / 8 GB の仕様でも、メモリ重視型、コンピューティング重視型、ネットワーク強化型などを指定できます。しかし、クラウドは大規模なリソースプールであり、特定の仕様が在庫切れになる場合があります。単一仕様のみを指定すると、リソースが調達できずスケールアウトが失敗する事態が発生します。ここで最も危険なのはスケーリング失敗そのものではなく、障害発生後のトラブルシューティングプロセスです。

4. RPC リンクにのみスケーリング戦略を適用する

単一アプリケーションへの適用は比較的簡単ですが、ビジネスシナリオ全体を整理するのは困難です。整理する方法の一つは、アプリケーション間の呼び出しシナリオに着目することです。アプリケーション間の呼び出しは、同期呼び出し（RPC、Spring Cloud などのミドルウェア）、非同期メッセージング（RocketMQ などのミドルウェア）、タスクベースの分散スケジューリング（SchedulerX などのミドルウェア）の 3 つに分類されます。通常、同期呼び出しはすぐに把握できますが、非同期とタスクベースの 2 つを見落としがちです。これら 2 つのパターンで問題が発生すると、トラブルシューティングに最も時間がかかります。

5. 可視化戦略がない

スケーリングは典型的なバックグラウンドタスクです。大規模クラスターのバックグラウンドタスクを管理する際、直感的な大画面での可視化管理が効果的です。スケーリング障害をサイレントに処理してはなりません。コアビジネスのスケールアウト失敗は、直接的なビジネス障害を引き起こす可能性があります。しかし、実際に障害が発生した時、スケーリング戦略の有効性にまで注意が向かないことが多く、スケーリングが原因であっても、その点をトラブルシューティングするのは困難です。

6. 事前に適切な評価を行わなかった

クラウドコンピューティングはスケーリングにほぼ無限のリソースプールを提供しますが、リソース準備の手間を省くだけです。マイクロサービスシステム自体は複雑で、単一コンポーネントの容量変更がエンドツーエンドのチェーン全体に影響を及ぼします。1 つのリスクを解消しても、システムのボトルネックが別の場所に移動し、隠れた制約が容量変化とともに徐々に表面化します。したがって、スケーリング戦略のアイデアだけに頼ることはできず、エンドツーエンドの負荷テストと検証を実施し、全体に最適なスケーリング設定を調整する必要があります。事前に高可用性の複数の観点からさまざまな技術的手段を理解し、複数のプランを策定しておくことをお勧めします。

おわりに

クラウドネイティブ環境では、スケーリング機能はより充実しており、スケーリングに利用できるインジケーターもビジネス要件に合わせてカスタマイズできます。エンタープライズ向け分散アプリケーションサービス EDAS や Serverless App Engine (SAE) などの PaaS プラットフォームは、クラウドベンダーのコンピューティング、ストレージ、ネットワークの基盤技術を活用し、クラウドの利用コストを削減できます。ただし、ステートレス化や設定とコードのデカップリングなど、業務アプリケーションにはいくつかの課題が存在します。より広い視点から見れば、これはクラウドネイティブ時代におけるアプリケーションアーキテクチャそのものへの挑戦です。しかし、アプリケーションがよりネイティブになるにつれ、クラウドの技術的恩恵をより身近に実感できるようになります。