パフォーマンスとスケーラビリティはトレードオフなのか

この記事の概要

現在システムデザインの学習として system-design-primer を読んでいます。その中で Performance vs scalability という項目があるのですが、なぜ vs となっているのか理解し切れる部分が少なく、自分なりに深掘りをしてみました！
この記事では、システムデザインにおいてパフォーマンスとスケーラビリティがどのように関係し、どんな場面でトレードオフが生じやすいのか、また両立できるケースは何かを自分なりに調査しまとめます！

パフォーマンスとは

システムにおけるパフォーマンスとは、システムが一定時間内にどれだけうまくタスクや処理を実行できるかを指します。パフォーマンスには処理速度、応答速度、スループットなどの要因が関係していて、高パフォーマンスシステムは大量のデータを素早く処理することができたり、ユーザーのリクエストに対して高速に応答することができます。

スケーラビリティとは

システムにおけるスケーラビリティとは、リクエスト数やデータ量の増加に合わせて適切に対応できる能力を指します。理想的にはパフォーマンスを維持しながら成長に追従することですが、実際にはアーキテクチャや運用の工夫が求められます。スケーラブルなシステムはサーバーやデータベースを追加することで増加する負荷を分散することができます。

パフォーマンス vs スケーラビリティ

パフォーマンスとスケーラビリティは常にトレードオフの関係にあるのでしょうか。一見するとどちらも担保したい指標ですが、同じ施策が同時に両方を満たすとは限りません。実際のシステム設計では両立できる場面もあれば、トレードオフが顕在化する場面もあります。

以下は Performance vs Scalability in System Design という記事でまとめられていた比較表です。

Aspect	Performance	Scalability
Definition	Focuses on optimizing speed and responsiveness	Focuses on handling increasing workload or users
Goal	Achieve maximum efficiency for current tasks	Accommodate growing demands without slowdown
Concerns	Speed, latency, throughput, resource utilization	Capacity, availability, distribution of workload
Key Techniques	Code optimization, caching, load balancing	Horizontal scaling, stateless architecture, microservices
Scaling Approach	Vertical scaling (scaling up)	Horizontal scaling (scaling out)
Impact of Growth	May degrade with increased workload	Maintains performance with increased workload
Resource Allocation	May require hardware upgrades for improvement	Adds more instances or nodes for improvement
Maintenance Complexity	Generally lower complexity	May involve higher complexity due to distributed nature
Example	A high-performance gaming server	A scalable social media platform

上記の、特に Maintenance Complexity の項目がトレードオフになりやすいと考えています。
例えば、サービス開始当初はリクエスト数が少なく、単一サーバーでのパフォーマンスを気にかけていればそれほど問題がありません。しかしユーザーが増加し秒間リクエスト数が急増すると、単一サーバーのスケールアップだけでは対応しきれず、バックエンドサーバーを複数台用意してロードバランサーで負荷分散するスケールアウト戦略が必要になります。ロードバランサーの導入は遅延をわずかに増やす一方で、総スループットと可用性を大幅に向上させる施策です。セッション管理やデータ同期をどこまで厳密に行うかによってはパフォーマンスに悪影響が出ることもあるため、設計方針を明確にしておく必要があります。

また、サービスのアーキテクチャとしてマイクロサービスを選択した場合、個々のサービスのスケーラビリティは他のサービスに依存することなく確保しやすい反面、サービス間通信が増えるためネットワークI/Oやリトライ処理がパフォーマンスのボトルネックになる可能性があります。API を同期的に多段呼び出ししてレイテンシが積み上がる、分散トレーシングがないとボトルネックが追えない、といった点は典型的なトレードオフです。

一方で、キャッシュ導入や非同期処理、クエリ最適化、読み取り専用レプリカの追加など、パフォーマンスとスケーラビリティを同時に底上げできる施策も多く存在します。例えば、リクエストのヒット率が高いキャッシュを手前に追加すればレスポンス時間を短縮しつつ、同じインフラ構成でもスループットを確保できます。このような対策はアーキテクチャの複雑性をあまり増やさずに済むため、トレードオフを生む施策に踏み込む前に検討する価値があります。

このように、スケーラビリティを確保する過程で複雑性が増し、その結果パフォーマンスに影響が出るリスクがトレードオフとして現れやすい一方、適切な設計・計測・運用によって両立させる余地も十分に存在すると考えます。（例えがわかりやすかった記事）

参考にさせていただいた記事にもまとめられていますが、システムの非機能要件やリクエストの増加見込み、現状のボトルネックなどを見極め、パフォーマンスとスケーラビリティをどの順序で高めるか、あるいは両軸で進められないかを検討する必要がありそうです。

感想

システムデザインの基礎的な知識としてパフォーマンスとスケーラビリティのトレードオフの関係性について調べてみました！初めはどちらも担保できるものと考えていましたが、改善したい指標に応じてトレードオフが出てくるケースと両立できるケースがあることに気づけてよかったです！
今回はトレードオフという点に絞って調査しましたが、パフォーマンスとスケーラビリティを確保すること自体もチャレンジングだと思うので、しっかり学びたいと思います！

参考

GeeksforGeeks, Performance vs Scalability in System Design
Parul Chaddha, Scalability v/s Performance
system-design-primer