基礎知識
オンプレミスで頭を悩ますサイジングをクラウドで解決！
システムに必要なリソース量を決定する「サイジング」は、オンプレミスにおいて非常に頭の痛い問題のひとつです。本記事では、サイジングの概要やオンプレミスとクラウドでの考え方の違い、クラウド移行時のサイジングのポイントについて解説します。
サイジングとは
システムを構築する際に必要なリソースを見積もり、用意しておくことを「サイジング」と言います。具体的にはシステムに求められる要件から、サーバーのスペックや台数、ストレージの容量、ネットワークの帯域などを検討し、どれだけのリソースを用意するかを決定する作業です。
既存システムのリプレイスであれば、過去の運用実績から、それぞれの数値を高い精度で見積もることも可能でしょう。しかし、新システムの構築においては具体的な実績値が存在しないため、想定されるトラフィックや保存するデータ容量など、利用するアプリケーションのシステム要件をもとに予測を立てて、見積もる必要があります。
サイジングの失敗は、様々な問題を引き起こす原因となります。例えば、見積もりをしたスペックが実際の負荷に対して不足していた場合、そのシステムは運用時の負荷に耐えられないでしょう。これはパフォーマンスの劣化や、最悪の場合はシステムダウンといった重大な問題に繋がる可能性も否定できません。もしもECサイトで、セール時のアクセス急増によってシステムダウンが起こってしまったら、多大な機会損失も発生してしまうでしょう。
安定して動作するシステムを構築するためには、サイジングが非常に重要となってきます。
オンプレミスとクラウドのサイジングの違い
オンプレミスとクラウドでは、サイジングの前提条件が大きく異なります。
オンプレミスはクラウドと異なり、負荷の増大に対してオンデマンドにリソースを投入して解決することが困難となっています。その理由は「ハードウェアの調達に時間がかかる」「キッティングが必要」「メンテナンスによるシステムの停止が発生する」など様々ですが、オンプレミスにおいては、あらかじめある程度の余裕を持たせたサイジングを行うのが定石です。もちろんサイジングには一時的な負荷の増大だけでなく、将来的なアクセス数の増加や長期的な利用計画も加味しなければなりません。
こうした事情から、どうしてもオンプレミスでは余裕を持った、言い換えれば要求に対して過大なサイジングが行われる傾向があります。しかし過大なリソースをあらかじめ用意すると、システムの調達や維持にかかるコストは増加してしまいます。ピーク時の負荷や、サービスの成長に耐えられるリソースを確保しつつも、過剰投資とならない程度の適正なサイジングを行うことが重要ですが、この見積もりは非常に難しいポイントです。
それに対して、クラウドでは状況に応じてオンデマンドにリソースの追加やスペックの変更が可能（スケールアップ・スケールアウト）なため、オンプレミスほどの綿密なサイジングを必要としません。設定した値以上の負荷がかかった際に、サーバーを自動的にスケーリングをしてくれる「オートスケール」機能を利用すれば、運用の自動化すらも可能です。
スペックの調整が気軽に行えるクラウドの特徴を利用すれば、試行錯誤を繰り返してサイジングの最適化を図ることもできます。失敗時のリカバリーが困難で、損失も大きくなりがちなオンプレミスに比べ、徐々に最適値を探ることで過剰投資を避けることができるのも、クラウドの大きなメリットです。
またサイジングの調整期間中はリソース変更の自由度が高い契約で試行錯誤を行い、最適値が導けた段階で安価な長期契約を結べば、クラウドの利用料金をさらに抑えることもできるでしょう。
クラウドでのサイジングのポイント
オンプレミスからクラウドへの移行を例に、クラウドにおけるサイジングの注意点について解説します。
まずサーバーです。これは提供されているサーバータイプの中から、現在オンプレミスで利用中のサーバーと近いスペックのものを選択し、台数を決定します。クラウドベンダーでは、性能や料金が異なる複数のサーバーのタイプを用意していることが一般的ですので、システムの要件にあわせて最適なタイプを選択しましょう。FJcloud-V(旧ニフクラ)では、コストパフォーマンスに優れた「Type-c」、豊富なラインナップの「Type-e」、ハイスペックモデルである「Type-h2」を提供しています。詳細については、「機能・サービス：サーバータイプ」を確認してください。
サーバーの台数を決定する際には、障害発生時に待機サーバーへ自動的に切り替える自動フェイルオーバー（HA機能）や、クラウドベンダーが提示するSLAについても考慮することが大切です。従来、オンプレミスで可用性を向上させるためには、待機サーバーを用意して冗長構成を組むのが一般的でしたが、クラウドベンダーが提供する自動フェイルオーバー機能を利用すれば、待機サーバーの準備が不要となります。ただし、フェイルオーバーが行われる際には、短時間とはいえサービスの停止時間が発生します。そのため、冗長化をHA機能に任せられるのは、こうした停止時間を許容できるシステムに限られる点には注意が必要です。
また、単一のサーバーではSLAに提示される稼働率を達成できず、複数ゾーンを跨いだクラスター構成を組むことが条件となっているクラウドベンダーも存在します。SLAについて詳しくは、「クラウド選択時の重要な指標。サービス品質保証（SLA）とは？」も合わせて確認してください。なお、FJcloud-V(旧ニフクラ)では単一ゾーンのサーバー1台で99.99%の稼働率を保証しています。詳細については、「品質保証制度（SLA）について」をご確認ください。
ディスクについては、オンプレミスで利用中のディスクのデータ容量をもとに、容量を選択するとよいでしょう。サーバーと同様に、クラウドベンダーではRead/Write性能や、障害に備えて収納される筐体を分離するなど、性能が異なるタイプのディスクを複数用意しているのが一般的です。こうした容量以外の部分にも注目し、システムの要件にあわせて最適なディスクを選択しましょう。FJcloud-V(旧ニフクラ)で提供中のディスクについては、「増設ディスク」を確認してください。
ネットワークについては、クラウドベンダーが提供しているVLANや、さまざまな外部からクラウド環境に接続するための機能・サービスから、必要なものを選択することになります。FJcloud-V(旧ニフクラ)で提供中のネットワーク関連の機能・サービスについては、「機能・サービス：ネットワーク」を確認してください。
クラウドのサイジングでポイントとなるのは、クラウドベンダーごとにある性能差です。クラウドでは、カタログ上では同一のスペックでも、ベンダーが異なれば性能に差が発生することもよくあります。そのため単純にカタログ上の数値だけを見て判断せず、各クラウドベンダーの性能を比較したベンチマークを確認することを推奨します。FJcloud-V(旧ニフクラ)では、サーバーやディスク、ネットワークなどの「ベンチマーク結果」を公開していますので、参考にしてください。
最後になりますが、性能だけでなく、かかる料金も重要です。クラウド利用時の料金で注意するポイントについては、「想定外の料金の発生を防ぐ！クラウドの見積もりで注意するポイント」を参考にしてください。
クラウドデザインパターンのご紹介
FJcloud-V(旧ニフクラ)では、さまざまなクラウドデザインパターンをまとめた「クラウドデザインパターン」をWebで公開しています。クラウドでの典型的な課題とその解決策を解説しているので、FJcloud-V(旧ニフクラ)を利用したシステムアーキテクチャ設計を行う際はもちろんこれからFJcloud-V(旧ニフクラ)を利用検討される場合にも参考にしてください。
