概要
数百万人ものユーザをサポートするシステムを段階的に作り上げていく。以下のステップでシステムの拡張を行っていく。
- 単一サーバの構成、DBの選定（初期）
- 垂直スケーリング、水平スケーリング（第二段階）
- ロードバランサの導入（第三段階）
- DBのレプリケーション（第四段階）
- キャッシュの導入（第五段階）
- CDNの活用（第六段階）
- Webサーバの水平スケーリング（第七段階）
- メッセージキューの導入（第八段階）
- ログ取得、定量化、自動化（第九段階）
- DBのスケーリング（第十段階）
学んだこと、考えたこと（各論）
単一サーバの構成、DBの選定（初期）
Webアプリケーションを構築するにあたり、シンプルにWebサーバとDBサーバの構成から検討を開始する。最初に検討すべきはリレーショナルDBを採用すべきか？非リレーショナルDBを採用すべきか？というところ。
以下のケースの場合は非リレーショナルDBを採用すべき。
- アプリケーションに超低遅延が必要な場合
- 非構造化データを扱う場合、リレーショナルデータがない場合
- データのシリアライズとデシリアライズだけが必要な場合
- 大量データの保存が必要な場合
音声や画像などデータ分析で使うようなデータを取り扱うアプリケーションの場合は非リレーショナルデータベースに格納してもよいと考えた。基本的にはリレーショナルDBを採用する。
垂直スケーリング、水平スケーリング
一台のマシンに搭載できるメモリに制約があるなど、垂直スケーリング自体に限度はある。マシンが停止した場合にアプリに影響を与えるため、水平スケーリングをする方針で検討する。
ロードバランサの導入
ユーザーからのアクセスがWebサーバでなくロードバランサに向くようになる。ロードバランサの導入自体がセキュリティの向上にも寄与する。ロードバランサがWebサーバの死活監視を行う場合、稼働していないサーバに対してはリクエストを振り分けないなどの動きをすることで可用性向上にも繋がる。
DBのレプリケーション
マスターデータベースとスレーブデータベースの構成の場合、マスターは書き込みと更新を担当し、スレーブは読み込みを担当する。
マスターが稼働しなくなった場合にスレーブを昇格させる、スレーブのデータ同期状況など本番システムで実際に導入する際には考慮事項が多そう。
キャッシュの導入
キャッシュに溜め込むべきデータであるかの判断を行う。読み取り頻度が高く、更新頻度が低いデータはキャッシュに溜め込むメリットがある。また、有効期限をどの程度に設定するか、データの一貫性を保つためにいつ同期を行うか、キャッシュサーバを単一障害点にしないこと、キャッシュの消去ポリシーの設定など考慮点は多々ある。