ScalableなWeb Application設計
Scalableなアプリケーションを作るためにどういうことをやっているのか知っていることを抽象的にひたすらあげる
具体的なやり方は具体的なソフトと構成とともに調べる必要あり
MECEではない
一般的なボトルネックとその対応
ネットワーク帯域
対応
一度の通信量を減らす(データサイズを小さくする)
チャンクに分割
そもそも不要なデータがあったらデータ量を減らす
オーバーヘッドの少ないプロトコルを採用する
通信を分散する
リクエストを減らす
細かいリクエストが複数あったら、リクエストをまとめられるかも?
bulk処理をイメージ
computingの処理速度(CPU/GPU)
対応
処理を分散する
動的にリソースをコントロールする
CDNで処理
クライアントで処理する
ブラウザにcomputingを任せる
スペックの低いスマホで全然動かなかったりする
探索にかかる時間
DBのSelectが遅い/検索でのserchが遅い
対応
データの持ち方を検討してDBの特性を考慮
やりたいタスクに特化したDBを採用する
分析なら分析用DBにデータを置くとか
検索は検索用サーバーに置くとか
探索範囲を絞る
computing powerで解決
ディスクIOが遅い
とにかくdisk I/Oは遅いのでアクセスさせないのがキモ
対応
その他対応
探索範囲を絞る
表示までが遅い
対応
非同期にリソース取得できるところは非同期にする
storage容量
比較的簡単に大きくできるので問題になりづらい?
とはいえ余計なものはいらない
共通の手法としてスケールアップがある
エンジニアリングとしては最も簡単な手法
金で解決
スケールアップ以外は基本的に面倒
stateがあると問題は一気に面倒になる。そしてstateはたいていある。
キャッシュはstateを持つ
expireはいつかの問題(「データが更新されない!」)
アクセス権限(間違って誰でもアクセスできるようになっているとやばい)
scale outでも
DBのshardingのように状態をもつと、どこにどの情報があるのかを意識する必要が出てくる
stateがないwebサーバーは増やせばいいだけだけど
分散は面倒
排他制御
ロック何が起きている問題
でも分散しないといけないのが普通
scale up
CPU clock/coreが高いのを重視
scale out
最適化
コード
OS/middlewareのconfig
portがなくなると新しい通信ができない
Linuxのportは65535
DBサーバの同時接続数がAPIサーバの最大数の上限
DBに接続できないAPIサーバーがあっても意味ない
都度T CPセッションはるからport枯渇しやすい
このスライドではカラムでの分割のことを言っていなくて
機能ごとにDBを分けるという表現をしてる
アプリケーションでDBアクセスを分ける