Web Application & Software Architecture 101 ~③スケーラビリティとは？~

educativeのWeb Application & Software Architecture 101という講座を受けたのでその内容についてまとめです．これは現在のWebアプリケーションがどのような設計で成り立っているかを概念レベル（コードレベルではない）で説明されてい講座です．なのでWebアプリケーションの設計について学びはじめの方やWebアプリケーションの設計の全体像を知りたいという方にぴったりの講座です．第3回目の今回はスケーラビリティについてです．昨今のWebアプリケーションはアクセス数がかなり増えているのでスケーラビリティを考えることは重要だと言えます．今回は改めてそのスケーラビリティとは何か？なぜ重要なのか？どうやってスケーラビリティを高めるのかの指針について紹介します．

スケーラビリティ（Scalability）とは？

スケーラビリティとは，処理が増えてもアプリケーションが遅延せずにその処理をできる能力のことです．たとえばある一人がWebアプリケーションにリクエストを行ったときレスポンスまでに0.5秒かかるとします．これが100万人になろうと0.5秒でレスポンスを返せるアプリケーションはスケーラビリティが高いこ言えます．スケーラビリティが低いアプリケーションだと10秒かかるようになってしまいます．つまり10秒の遅延が発生します．そしてなぜこのスケーラビリティが重要かと言いますと，もし遅延が発生してしまったらユーザーは他のWebページやサービスに飛んでいってしまって自分たちのサービスを使ってくれないからです！

遅延（Latency）

この遅延には2種類存在します．1つ目がネットワーク遅延で，2つ目がアプリケーション遅延です．

f:id:harada-777:20200815181207p:plain:w400

ネットワーク遅延はブラウザなどのリクエストがサーバー（アプリケーション）に届くまでと，レスポンスがサーバーからブラウザまで届く時間の合計です．ネットワーク遅延を削減するにはCDN（Content Delivery Network）と呼ばれる分散化されたキャッシュサーバーのようなものを用意するといったアプローチが取られたりします．これをユーザーの近く（地理的に）に置くことでネットワーク遅延を削減したり，本体のサーバーの負荷を減らしたりします．アプリケーション遅延はアプリケーションがレスポンスを返す為の処理をする時間です．こちらを削減する方法がいくつかあり，次節以降で解説します．

スケーラビリティを高めるアプローチ

ここからはアプリケーション遅延を改善し，スケーラビリティを高める方法について解説します．アプローチとしては主に2つあります．

Vertical Scaling

Vertical Scalingはアプリケーションを起動するサーバー（PC）のCPUやRAMを高めることでスケーラビリティを高める方法です． Vertical Scalingはアプリケーションコードを触わずにスケーラビリティが高められるのでまずはこの方法を試すのが良いとされています．しかしその1台のサーバーの能力を高めるだけでは効果は限定的にはなってしまいます．そこで登場するのがHorizontal Scalingです．

Horizontal Scaling

Horizontal Scalingはアプリケーションを起動するサーバーの数を増やしてスケーラビリティを高める方法です．1台では無理な場合は2台，3台と複数のサーバーでアプリケーションを起動してそれらでリクエストを捌くようにします．またcloud computingサービスを使うと動的にサーバーの数を増やしたり減らしたりしてくれるので金銭の節約にもなります．（Requestが増えたときのみサーバーの数を増やしてくれる）この方法ではロードバランサーを設置したり，サーバー間でデータの共有をどうするのか？などの問題が発生するのでVertical Scalingよりは複雑になってしまいます．

スケーラビリティへのアプローチとして本講座で述べられているのは社内からのアクセスや限定されたアクセスしか想定されないアプリケーションはVertical Scalingでの対応をし1サーバーでアプリケーションを立てるので十分であるとされていました．逆に一般公開される予定のものはHorizontal Scalingができるようなアーキテクチャ（例えば本講座で少し後に出てくるマイクロサービスアーキテクチャ）で設計しておくことが推奨されていました．

ボトルネック

ここでは本講座で述べらていたボトルネックになり得る主な箇所について述べさせて頂きます． - データベース - 1つのデータベースだけを使用しているとデータベースがボトルネックとなってしまいます．読み取り用のデータベース，書き込みのデータベースなど正しく分割することで高速化を期待できます． - アプリケーションアーキテクチャ - 非同期で実行した方が良い部分を非同期で実装できていない部分があるとここがボトルネックになることがあります． - キャッシュを不使用 - 正しくキャッシュを使うとデータベースへのアクセスや対象のアプリケーションから外部のアプリケーションに接続する必要がなくなってパフォーマンスを改善することができます． - データベースの選出方法 - トランザクションや強い整合性が必要ないのにRDB (Relational Datebase)を使っていませんか？NoSQLを使用すればHorizontal Scalingが可能なのでよりパフォーマンスが求められる場合はこちらを使うことが推奨されています．（DBについては本講座の後半にて解説）

実際の開発ではパフォーマンスが遅いと感じたときに以上の場所を中心に，実際の時間を測定しボトルネックを探していくのが良いと感じます．パフォーマンスを考慮したコードやアーキテクチャは複雑になりがちなので必要なときに，目標の数値が達成できるようするのが良いと思います．

感想

今回は主にスケーリングについてまとめました．これを読むことでどういう部分がボトルネックになりやすいのかということについて整理ができました．また実際の現場でどう計測するのかなどより具体的な部分についてより勉強してみたいと感じました．