図解で学ぶシステム設計 〜スケーラビリティー編〜
初めに
こんにちは、最近、AIの進化が止まらないですね。毎日のように新しいプロダクトが登場しており、凄まじい勢いです。特に2022年11月30日にリリースされたChatGPTは、わずか5日で100万人のユーザーを獲得し、個人的にはユーザーの増加率よりシステムの心配をしていました。
このように、急激にユーザーが増えてもシステムが正常に動くようにするために大事な考え方が「スケーラビリティ」です。今回は、このスケーラビリティについて、ざっくり整理してみたので、ぜひ参考にしてみてください。
スケーラビリティとは
まず初めにスケーラビリティの定義について明らかにしておきましょう。ソフトバンクグループによると以下のように定義されています。
スケーラビリティ(Scalability)とは、システム、機器、またはソフトウェアの拡張性や拡張可能性を指します。 どれだけ柔軟に規模や利用負荷の増大に対応できるかの能力や度合いを示し、電気通信やソフトウェア工学の分野でも広く用いられています。システムやネットワーク、またはアルゴリズムが持つべき望ましい特性として扱われます。
つまりソフトウェア自体の拡張性を表しており、増加するユーザー（リクエスト）にどれだけ耐えうるのかを測定するために利用できます。例えば、多くのユーザーを抱えるNetflixやUberなどの企業では、スケーラビリティを考慮した技術選定、実装が適切に行われています。
スケーリング方法
スケーリング方法には大きく２種類の方法があります。それは、水平スケールと垂直スケールです。
それでは早速、それぞれの特徴とメリットデメリットについて見ていきましょう。
水平スケール (Horizontal Scaling)
水平スケールは、システムの処理能力や容量を向上させるために、複数のサーバーやノードを追加する手法です。つまり、サーバーの個数を増やす手法になります。これ結果、負荷分散が可能となり、システム全体の可用性やパフォーマンスが向上します。特にクラウド環境や分散システムにおいて効果的であり、トラフィックの増加やデータ量の拡大に柔軟に対応できます。水平スケールの場合は各サーバーに対してリクエストを分散させる必要がありますが、ロードバランサーを設定することでこの問題を解決することができます。
水平スケールでは、ロードバランサーの設定など構成の変更が必要ですが、後述する垂直スケールに比べて比較的低コストでサービスを拡張することができます。また、最大の強みは可用性にあり、たとえ1つのサーバーがダウンしても、他のサーバーがリクエストを処理するため、単一障害点を排除して継続的なサービス運営を実現できます。
図1: 水平スケールの概念図
| メリット | デメリット |
|---|---|
| 高い可用性を実現できる | 複雑な構成管理が必要 |
| システムの拡張性が高い | ネットワーク遅延や通信オーバーヘッドの増加 |
| 負荷分散が容易 | データの一貫性維持が難しい場合がある |
| 障害発生時の影響を限定できる | 初期コストが高くなることがある |
| リソースの追加が比較的容易 | スケーリングに伴うソフトウェアの対応が必要な場合がある |
垂直スケール (Vertical scaling)
垂直スケールは、既存のサーバーやノードに対して、CPU、メモリ、ストレージなどのリソースを追加・強化する手法です。つまり、数は増加させず既存のサーバーの能力を向上させる方法です。アプリケーションのアーキテクチャを大幅に変更することなく性能向上を図る場合に有効であり、特に既存のインフラストラクチャを最大限に活用したい場合に適しています。
垂直スケールは単にサーバーのスペックを変更するだけという手軽さが特徴ですが、サーバーが1台のみになるため、単一障害点やDDoS攻撃などのセキュリティリスクを抱えることになります。
図2: 垂直スケールの概念図
| メリット | デメリット |
|---|---|
| シンプルな構成で導入が容易 | 拡張性に限界がある |
| アプリケーションの再設計が不要な場合が多い | ハードウェアの制約に依存する |
| 初期コストが比較的低い | ダウンタイムが発生する可能性がある |
| リソースの追加が即時反映されやすい | 障害時に全体のサービスが停止するリスク |
| 管理が容易で、運用の複雑さが低い | 単一障害点（Single Point of Failure）となるリスク |
水平スケールと垂直スケールの比較
| 特徴 | 水平スケール | 垂直スケール |
|---|---|---|
| 拡張方法 | サーバーやノードを追加する | サーバーのリソース（CPU、メモリ等）を増強する |
| 可用性 | 高い可用性を実現可能 | 可用性向上には限界がある |
| 拡張性 | 非常に高い | ハードウェアの制約により限界がある |
| コスト | 初期コストは高いが、長期的には効率的 | 初期コストは低いが、拡張に限界がある |
| 管理の複雑さ | 高く、負荷分散やデータ同期が必要 | 低く、シンプルな管理が可能 |
| 障害耐性 | 高い（複数ノードにより冗長性を確保） | 低い（単一ノードがボトルネックとなる） |
まとめ
水平スケールと垂直スケールには、それぞれ違ったメリットとデメリットがあり、システムの規模や使い方に応じて、どちらを選ぶかが大事になってきます。水平スケールは拡張性が高く、システムの可用性もアップしますが、その分管理が多少複雑で、初期コストがかかるのがネックです。一方、垂直スケールはシンプルに管理できて、導入コストも低めですが、拡張性や可用性に限界があるのが弱点です。
多くの場合は、これらのスケーリング方法をうまく組み合わせて、システムのパフォーマンスと安定性を最大化するのがベストです。特にシステム規模が小さいときは、AWS LambdaやAzure Functionsみたいなサーバーレスアプリケーションを使うと、インフラの面倒な部分をクラウドに任せられるのでおすすめです（裏側を作成しているエンジニアに感謝です）。システムの要件に合わせて、賢くサービスを選んで、スムーズに運用できるようにしましょう！ワイルドだろ〜。
参考資料
Discussion