読書メモ：データ指向アプリケーションデザイン(2)

1.3 スケーラビリティ

スケーラビリティはシステムの性能問題の要因としてありふれている。トラフィック量が増加したら、とか、扱うデータ量が増加したら、とか。

言い換えると「ワークロードの増加に対応できる能力」がスケーラビリティ。

ワークロードの増加に対応するための選択肢を議論するには、客観的に表現できるようにしなければならない。

🟡🟡(リソースなど調整できる何か)を2倍にしたら🟨🟨(トラフィック量など観測できる何か)が2倍になる、みたいな。

システムのアーキテクチャによって適切な表現は異なる。

Web サーバーなら毎秒のリクエスト数、データベースなら読み書きの比率(なんでだ？)、キャッシュならヒット率、などなど。

Twitter を題材に、多数のユーザーをフォローしている人のタイムライン取得と、多数のユーザーにフォローされているユーザーの投稿における性能上の課題とその対応を解説されている。

2種類の計測方法がある。

「パフォーマンス」の例

バッチ処理ならスループット(1秒あたりに処理できるレコード数)
オンラインシステムならレスポンスタイム(クライアントがリクエストを送信してからレスポンスを受信するまでの時間)
- レイテンシ(の中でも片道レイテンシ)とラウンドトリップタイムのほうが適切な気がする

レスポンスタイムを判断するときは統計的な分布を評価しなければならない、とか、パーセンタイルという考え方の説明とか。

一般論として、ある一定の負荷に対応できるアーキテクチャは、その10倍の負荷には対応できない。だからアーキテクチャから考え直さないといけない。

そして万能なアーキテクチャは存在しないので、要求を分析してどのようなワークロードがどれくらい発生するのか推定する必要がある。

ソフトウェアのコストは、初期の開発コストと運用中のメンテナンスコストの総和になる。

次のような設計原則に注意すれば実現できる、かもしれない。

劣悪な（あるいは完成度の低い）ソフトウェアの制約は、しばしば優れた運用によって回避できるが、運用が
悪ければ優れたソフトウェアも信頼性を保って動作することはできない

Windows Live のエンジニアが発表した論文のざっくりとした説明も紹介されてる。

何かしら対処しなければ時間とともに複雑化するのは当然。その複雑さによりいろいろな問題が引き起こされる。

「単純さ」を目指すのだけど、それは「機能を減らす」のではなく「偶発的に発生する複雑さを取り除く」ということ。

「偶発的に発生する複雑さ」というのは、結局実装の都合で生じた何かややこしい問題のこと。

それを解決する手段が抽象化。

しかし、分散システムの利用するさまざま優れたアルゴリズムには、いい感じの抽象が発見されていないものもある。

アジリティが必要だということが書かれてたけど具体的な話はなかった。