スケーラビリティとは？スケーラビリティの意味

スケーラブルなシステムとは、ワークロードやユーザーの要求の急激な変化に対応できるシステムを指します。スケーラビリティとは、そのシステムがリソースの追加や削除を通じていかに変更に対応し、需要に応えられるかを示す指標で、アーキテクチャとは、システム全体を構成するネットワーク、アプリケーション、プロセスやサービスを構築するためのハードウェア、ソフトウェア、テクノロジーやベストプラクティスを意味します。

こうしたアーキテクチャ、サービスや製品、ブランドを定義するあらゆるものを含めたシステムは、以下の場合にスケーラブルであるとみなすことができます。

• リソースを追加し、スケールアップすることで、顧客の需要やワークロードの増加にシームレスに対応できる。
• 需要やワークロードが減少した際にはリソースを簡単かつシームレスに削除できる。

これを実現するためには、変化し続ける需要に合わせてキャパシティを調整でき、アクセス性に優れ、すべての顧客が必要なタイミングでどこからでも利用できるるシステムを構築する必要があります。

例えば、デザイン性とスケーラビリティに優れたウェブサイトは、同時にアクセスするユーザー数が1人であっても数千人であっても同様に機能し、さらに多くのユーザーがログインしても、機能の低下は感じられないはずです。

この記事では、スケーラビリティとは何か、システムやサービスにおけるスケーラビリティの意味とパターンを定義し、一般的な内容を見ていきます。

スケーラビリティのパターンとは？

LEGO® ブロックで遊んだことがある方も多いと思いますが、説明書を読まずに適当に組み立てて最終的に壊れてしまったこともあるのではないでしょうか。ただ、緻密なイラストで分かりやすい説明書どおりに組み立てれば、わざとブロックを引っ張って壊さない限り壊れないしっかりとした構造が完成するはずです。説明書に記載されている組み立て方法は、ビルダーの多くがよく遭遇する構造上の問題を解決するようテストされ、実証されたものなのです。

コンピューター開発におけるアーキテクチャのパターンも、この LEGO® の説明書に記載されている組み立てテクニックによく似ており、コンピューターシステム開発における一般的な問題解決方法として実証されている一連の開発・プログラミング技術と呼べるものです。どのパターンも優れた設計構造を持ち、特性が定義され、過去に問題解決のために活用されています。

ただ、状況によって適切なスケーラビリティパターンは異なり、適切なパターンを選択し、自社のシステムに特有の課題に合わせてカスタマイズする必要があります。実証済みのスケーラビリティパターンを適切に取り入れることで、作業の手間が減り、時間の節約になります。

一般的なスケーラビリティパターンの例は？

スケーラブルなアーキテクチャパターンにはいくつかありますが、この記事では、アーキテクチャのスケーリングの課題を解決するために使われる最も一般的なパターンを紹介します。

AKF スケールキューブ

X、Y、Z 軸に沿った3つのスケーリングアプローチを定義する3次元モデルです。

X 軸スケーリング

X 軸スケーリングとは、同じコンポーネントの複数のインスタンスによるスケーリングを指し、ロードバランサーの背後にサービス、アプリケーションやデータセットをクローンまたは複製して行います。この場合、あるアプリケーションの N クローンの実行中には各インスタンスは負荷の 1/N を処理することになります。

X 軸スケーリングパターンは実装しやすく、トランザクションのスケーラビリティを高める効果がありますが、データセット全体が複数のサーバーに複製され、データキャッシュが指数関数的に増加するため、維持費が高くなります。

Y 軸スケーリング

Y 軸スケーリングとは、異種のコンポーネントを動詞や名詞の境界に沿って複数のマクロサービスやミクロサービスに分割またはセグメンテーションすることを指します。例えば、動詞ベースのセグメントとしては「決済」などのサービスを、名詞ベースのセグメントとしては「ショッピングカート」を定義することができます。

サービスをそれぞれ個別に拡張できるため、現在必要なサービスにのみリソースを傾斜配分することができます。高い可用性を確保するため、各サービスが独自の非共有データセットを持つ必要があります。

データセットを非共有とすることで障害の分離が可能となり、システム全体をスキャンすることなく、問題をスピーディに診断・修正しやすくなります。ただ、Y 軸スケーリングの設定には時間がかかり、実装が難しいという欠点があります。

Z 軸スケーリング

Y 軸スケーリングでは異種コンポーネントを分割しますが、Z 軸スケーリングではシステム内の同種コンポーネントを分割します。この場合、各サーバーが同一のコードのコピーを実行しますが、実行対象はそのデータのサブセット (またはシャード) のみに限定されます。

こうした Z 軸での分割は、顧客を地域別やタイプ別に分ける場合によく使われます。例えば、定額制のニュースサイトで、有料会員は24時間365日すべてのサイトのコンテンツに無制限にアクセスできるのに対し、無料会員は同じデータにアクセスできるものの全文を読める記事数が月に3、4本までに制限されているといった場合が挙げられます。

この設定では、データのセグメントが小さくなり、必要なストレージリソースも少なくなるため、運用コストを削減できますが、設計と実装に時間がかかり、システムの間接費を減らすためには多数の自動化が必要となります。

水平・垂直方向のスケーラビリティパターン

上方 (垂直方向) や横方向 (水平方向) にスケールを拡大することもできます。

垂直方向のスケーリング

垂直方向のスケーリングとは、サーバーなどのコンポーネントの能力を高めてパフォーマンスを向上させることを指し。垂直スケールとも呼ばれます。例えば、アクセス数が増えるとサーバーのパフォーマンスは低下しますが、RAM やストレージドライブを増設すればサーバーのパフォーマンスが向上し、増加したトラフィックを処理しやすくなります。

垂直方向のスケーリングは、導入が容易で、リソースの追加購入が不要なためコストを抑えられ、メンテナンスも簡単です。ただ、これが単一障害点として重大なダウンタイムの原因となるリスクもあります。

創業間もない企業であれば、コストを抑えるために垂直方向のスケーリングを導入する可能性も多々ありますが、いずれは RAM やストレージの限界に達し、需要に対応するためにリソースの追加が不可避となります。

水平方向のスケーリング

水平方向のスケーリングとは、同種のリソースをシステムへ追加投入してパフォーマンスを向上させることを指します。例えば、サーバー1台の容量を増やしてパフォーマンスを向上させる代わりに、システムにサーバーを追加する方法などがあります。サーバーの可用性に応じてワークロードを異なるサーバーに分散させるには、ロードバランサーが役立ちます。こうすることでシステムの全体的なパフォーマンスを向上させることができます。

コンピューティングリソースが増えれば、フォールトトレランスが向上し、ダウンタイムのリスクが減ります。ただ、サーバーやロードバランサーの追加にはコストがかかります。トラフィックの増加に対応するためには、オンプレミスのリソースとクラウドのリソースを組み合わせて使用することを検討する必要があります。

負荷分散

ロードバランサーは、ユーザーリクエストやワークロードをバックエンドサーバー群に効率的に分散させ、一つのリソースに負荷が集中しないよう、さまざまなリソース間で負荷のバランスを取ります。こうすることで、IT 部門がサービスの可用性とスケーラビリティを確保しやすくなります。

ロードバランサーのタスクには以下のようなものがあります。

• システムで利用可能なリソースを発見する。
• リソースの健全性を確認し、リソースの可用性に加え、そのリソースが適切にワークロードを処理するために動作しているかを判断する。利用可能なサーバーがダウンした場合、ロードバランサーはそのサーバーへのパスをシャットダウンし、ユーザーに遅延やダウンタイムを感じさせずに別のサーバーに切り替えます。
• 複数の正常なバックエンドサーバー間で負荷のバランスを取るため、使用すべきアルゴリズムを決定する。

一般的なロードバランスの方式 (アルゴリズム) には以下のようなものがあります。

• 最小接続数 : アクティブな接続数が最も少ないサーバーにトラフィックがルーティングされます。
• 最小応答時間 : ロードバランサーがヘルスモニタリングのリクエストに対するサーバーの応答時間を計測し、応答時間が最も短い健全なサーバーにトラフィックを送ります。ロードバランサーの中には、このアルゴリズムに加えてアクティブな接続数を考慮するものもあります。
• ラウンドロビン : 現在のワークロードやアクティブな接続数に関係なく、最初に利用可能なサーバーにトラフィックが送られます。そのサーバーがリクエストを受信して処理すると、ロードバランサーはそのサーバーをキューの一番下に移動させます。この方式のリスクとしては、プロセッサー負荷の高いリクエストを受信したサーバーが再びキューの先頭に到達した時点で以前のリクエストを処理中であるリスクが挙げられます。
• ハッシュ : 受信パケットのデータのハッシュによりリクエストを受信するサーバーが決まります。このデータには、IP アドレス、ポート番号やドメイン名などの情報が含まれます。

キャッシング - コンテンツ配信ネットワーク (CDN)

CDN とは、静的なウェブプロパティへのアクセスと配信を最適化し、高速化するために使用されるサーバーのグローバルネットワークです。静的なプロパティとは、Javascript、CSS、画像やその他のメディアファイルなど、頻繁に変更されないものを指します。

場合によっては、ウェブサイトの 80% が静的コンテンツで構成されていることもあります。例えば、ストリーミングサービスで配信されている動画はあまり頻繁に変更されませんが、動画の中には非常に人気が高くなり、毎日何百万件ものアクセスを集めるものもあります。こうした静的コンテンツを CDN にオフロードすることで、元のサーバーの負荷を軽減し、グローバルにコンテンツを強化するだけでなく、データを顧客の近くに移動させてアクセスをスムーズにし、高い可用性を実現することができます。

マイクロサービス

マイクロサービスとは基本的に、連携して一緒に動作できる異種の小さなアプリケーションの集まりを指します。個々のマイクロサービスにはそれぞれの目的と担当範囲があり、複数の異なるチームが他のマイクロサービスから独立して個別に開発することができます。マイクロサービスが機能する上で相互に依存する必要はありませんが、相互に通信できる仕組みが必要となります。

マイクロサービスでは、現在必要な要素のみを拡張すればよいためスケールアップがしやすく、開発チーム間での調整を行わずとも独立して展開することができます。マイクロサービスは、ウェブアプリケーション、迅速な開発と展開、世界各地に分散したチーム構成に適しています。

マイクロサービスを使用することで、トランザクションや大規模なデータセットを効率的にスケーリングでき、障害の分離を容易に行えるため、システムの高可用性が維持しやすくなります。また、大きな機能を小さなサービスに分割することができるため、コードベースの複雑さも軽減できます。

シャーディング

シャーディングとは基本的に、大規模なデータベースを、管理しやすくスケーラブルなコンポーネントに小さく分割することを指します。データベースが大きくなると、対応してリクエストやトランザクションも増え、データベースへのクエリに対する応答時間が長くなります。また、大規模なデータベースの維持には非常にコストがかかります。

「シャード」とは、個々のデータベースパーティションを指します。こうしたシャードを複数の分散型データベースサーバー上に分散して配置することで、ワークロードを分散することができます。

データベースの規模が大きくなりすぎると、以下の理由からシャーディングを使いたくなるかもしれません。

• 小規模なデータベースの方が管理しやすい。
• 小規模なデータベースは高速で、個々のシャードの能力が単一の大規模なデータベースよりも優れている可能性もある。
• 新たなデータシャードを作成して複数のサーバーに分散させることができ、小規模なデータベースの拡張も容易である。
• シャーディングではホストに巨大かつ高価なサーバーが不要なため、コストを削減できる。

スケーラブルなアーキテクチャパターンをシステムに実装することで、入力負荷が増加してもシステムのパフォーマンスを維持できるようになります。