クラウドサービスの魅力は、何といってもそのスケーラビリティの柔軟性にあります。
まずはスモールスタートで、定期的に様子を見ながらスケールアップ、ピークを過ぎればスケールダウンして必要経費を抑えるといったスマートな運用は、これまでのASPやアウトソーシングに比べるとダイナミックで非常に有力に思えます。
しかし、いざスケーラビリティの柔軟性を活用しようと思っても、スケールアップやスケールダウンのタイミングは、どのように判断すれば良いのか、迷う方も多いのではないでしょうか。
今回は、このスケーラビリティの柔軟性に関する判断基準についてご紹介したいと思います。
クラウドをスケールアップする判断の材料と目安
クラウドサービスをスケールアップする最大の動機は、「システムが利用負荷に耐えられなくなりそうだから」です。つまり、簡単にいえば、システムのトランザクション量に対して、リソースが明らかに不足することが予想されるという状況です。パソコンでいえば、アプリケーションを立ち上げすぎてメインメモリが足りなくなり、スワップが大量に発生してパフォーマンスが急激に悪化するという、あの状態です。
これを想定してスケールアップのタイミングを図るには、今のトランザクション量を監視する必要があります。代表的なトランザクション量の指標としては、アクセス数、CPU利用率、メモリ使用量、ネットワーク帯域利用率、ストレージ残量があります。たとえば、アクセス数が右肩上がりで伸びていて、それにつれてCPU利用量やメインメモリの使用量が増えているケースです。
注意が必要なのは、これらの数値はピーク値を観察する必要があるという点です。移動平均でトレンドを見ることはありますが、平均値自体にはあまり意味がありません。
ピーク値が頻繁に、現在のリソースを超えるようであれば、スケールアップのタイミングです（少々細かくいえば、ネットワークの帯域はスケールアウトで拡張します）。
また、新規サービスを立ち上げる、といった、これまで以上にリソースを消費するのが明らかな場合も、スケールアップを検討すべきでしょう。
なお、判断はたとえば1ヵ月後に実施できるくらいのスピード感で、なるべく前倒しに判断していくのが理想です。どのくらい前倒しすべきかは、クラウドベンダがスケールアップを反映させることができる時間を目安にすれば良いでしょう。
クラウドをスケールダウンする判断の材料と目安
スケールダウンの検討は、スケールアップと逆で、元の予定数字をベースにします。
つまり、1ヵ月後、2ヵ月後…のように、先々のトランザクションを事業計画から割り出し、それに必要なリソース量を計画しておくということです。それに対してCPU利用率、メモリ使用量、帯域利用率、ストレージ残量がどうか、というふうに見ていきます。計画と照らし合わせて、明らかに計画よりもリソース使用量が少ない（それだけシステム使用量が予測値を下回っている）のであれば、スケールダウンを検討しましょう。スケールダウンをすぐに反映できるベンダでなければ、反映するのに必要な時間分は、前倒しで判断するようにすれば、スムーズに運用できます。
スケールダウンする時に注意する点
スケールダウンの判断で難しいのが、一時的に閑散としているのか、恒常的なものなのかの見極めが大切だということです。スケールダウン、スケールアップが即座に反映されるクラウドベンダならまだ気楽ですが、ある程度時間がかかる場合は、あまりスケールダウン、スケールアップを繰り返すのはリソース割当量の振れ幅が大きくなり、好ましくありません。
こうした短期的なブレに敏感になりすぎると、事業計画の方向性を見誤る可能性もあります。
スケールアップ、スケールダウンを賢く行って、スケーラビリティの柔軟性を最大限活用しよう
クラウドサービスの最大の特徴はスケーラビリティの柔軟性です。それを最大限に活用しながら、事業を最適化していきたいところです。
そのためには、日々のリソース消費量の監視が重要です。そして定期的にスケールアップ、スケールダウンの判定を行い、最小の費用で最大の効果を得られるように賢く運用しましょう。
