クラウドのスケーラビリティ：スケールアップとスケールアウトの両立

IT管理者は、その役割の中で拡張性の課題に頻繁に直面します。アプリケーションの成長率、データ・ストレージ容量要件、帯域幅の需要を予測することは簡単な作業ではありません。ワークロードが容量の限界に近づくと、アーキテクチャーをスケールアップしたりスケールアウトしたりするにあたって、効率を確保しながら高い性能を維持するにはどうすればよいかという問題が生じます。

スケールアップまたはスケールアウトを通じてクラウドの力を迅速に活用し、予期せぬ急速な成長や需要の季節変動に対応できることは、パブリッククラウド・サービスの大きな利点となっています。しかし、効果的な管理がなければ、不利益になる可能性もあります。追加のインフラストラクチャーに数分でアクセスできることの魅力は間違いありません。しかし、効果的に行うには、需要を満たすためにどのような拡張性が必要か、特定のユースケース、経費を綿密に監視する方法について決定を下す必要があります。

インフラストラクチャーの拡張性は、変化するアプリケーションの需要に必要に応じてリソースを静的に追加または削除することにより、アプリケーションの変化するニーズに対応します。ほとんどの場合、これはスケールアップ（垂直スケーリング）および/またはスケールアウト（水平スケーリング）によって処理されます。クラウドの拡張性については、その仕組みや、新興のKubernetesやクラウドネイティブ・アプリケーションのアーキテクチャなど、さまざまな領域を対象とする研究やアーキテクチャ開発が数多く行われてきました。この記事では、まず、スケールアップとスケールアウトを比較することに焦点を当てます。

スケールアップは、しばしば垂直スケーリングと呼ばれ、既存のシステムにリソースを追加して、望ましい状態の性能に到達することによって行われます。例えば、データベースやWebサーバーは、サービスレベルアグリーメント（SLA）を満たすために、特定のレベルで次に進むためにリソースを必要とします。さらに多くの CPU、メモリ、ストレージ、またはネットワークをシステムに追加することで、性能を必要なレベルに維持できます。

クラウドでこれが行われると、アプリケーションはより強力なインスタンスまたは仮想マシンに移動され、ダウンタイムを最小限に抑えるために別のホストに移行され、以前は使用していたサーバーが廃止されることがよくあります。もちろん、このプロセスは顧客に対して透明である必要があります。

スケールアップは、スレッドや接続を増やしたり、データベース・アプリケーションの場合はキャッシュ・サイズを増やしたりすることによって、ソフトウェアで行うこともできます。こうしたスケールアップ・オペレーションは、何十年もの間、データセンターのオンプレミスで行われてきました。しかし、特定のシステムを拡張するために追加のリソースを調達するのにかかる時間は、オンプレミスでは数週間から数か月かかる場合がありました。一方でクラウドでの拡張は数分で完了するため、料金体系に影響を与える可能性があります。

スケールアウトは通常、分散アーキテクチャーに関連付けられています。スケールアウトには、次の 2 つの基本的な形式があります。

• 事前にパッケージ化されたインフラストラクチャーまたはノード（つまり、ハイパーコンバージド）のブロックに追加のインフラストラクチャー容量を追加する
• 顧客情報を取得しながら、アプリケーションやサービスから独立した分散サービスを使用し、性能の問題に対処し、クラウド・コンピューティングを最適化する

どちらのアプローチも、コストを削減するために、個々のコンポーネント（コンピューティング、メモリ、ネットワーク、ストレージ）の垂直スケーリング（スケールアップ）とともに、現代のクラウド・サービス・プロバイダー（CSP）で使用されています。水平スケーリング（スケール・アウト）により、サービス・プロバイダーは「成長に応じた投資」インフラストラクチャーやサービスの提供が容易になり、料金戦略に影響を及ぼします。

ハイパーコンバージド・インフラストラクチャーは、プライベートクラウドやティア2のサービス・プロバイダーでの使用としてますます人気が高まっています。このアプローチは、他の形式の分散アーキテクチャーほど疎結合ではありませんが、従来のアーキテクチャーに慣れているIT管理者が水平スケーリングに移行し、それに伴うコスト上のメリットを実現するのに役立ちます。

疎結合分散アーキテクチャーは、アーキテクチャーの各部分を独立して拡張できるため、ボトルネックを効果的に排除できます。つまり、ソフトウェア製品のグループを独立した部分として作成し、デプロイしても、全体として連携して完全なワークフローを管理できることを意味します。各アプリケーションは、独立して機能・動作できる抽象化されたサービスの集合で構成されています。これにより、製品レベルだけでなくサービス・レベルでも水平スケーリングが可能になります。さらにきめ細かなスケーリング機能は、SLA または顧客タイプ (ブロンズ、シルバー、ゴールドなど) 別、あるいは特定のAPIに対する需要レベルが異なる場合は API タイプ別でも定義できます。これにより、特定のインフラストラクチャー内でのスケーリングの効率的な使用が促進されます。

サービス・プロバイダーは、性能と効率に重点を置きながらも、進化する顧客ニーズに応えるためにインフラストラクチャーを継続的に調整してきました。注目すべき例はAWSのオートスケーリングです。これは、リソースの使用量を実際の要件に合わせて調整し、ユーザーがアクティブに消費した分だけ料金が請求されるようにします。複雑な請求を明らかにするのは困難な場合がありますが、このアプローチはコスト削減につながる大きな可能性を秘めています。

ここで、IBM Turbonomicが介入してクラウド課金を簡素化し、支出に関する洞察を提供し、ストラテジーに関する十分な情報に基づいた意思決定を促進して、さらなる節約を実現します。Turbonomicは、環境と移行計画の両方のコストモデルを提供することで、オンプレミスとオフプレミスのインフラストラクチャーにまたがるIT管理の予算配分を合理化し、最適なワークロードのパフォーマンスと効率を保証し、パフォーマンスの問題を軽減します。

今日のクラウド・サービス・プロバイダーにとって、疎結合分散アーキテクチャーはクラウドでのスケーリングに不可欠であり、クラウド・オートメーションと組み合わせることで、お客様のビジネス・ニーズに最適な垂直方向または水平スケーリングの多くのオプションが得られます。Turbonomicは、特定のストレージ・システム要件に合わせて、クラウドへの移行において最適なオプションを選択するのに役立ちます。