# 12章 非抽象的な大規模システム設計の紹介
その責任がプロダクションの運用からプロダクトエンジニアリングにまで渡るSREは、ビジネスケースの要求と運用コストの足並みを揃えるユニークな立場にある。
プロダクトエンジニアリングチームは、自分たちが設計するシステムのメンテナンスコストを認識していないことがある。

Googleでは信頼性こそが最も重要な機能である。
NALSD(=Non Abstract Large System Design)と呼ばれるスタイル。
## 12.1　NALSDとは何か？
問題の定期から始めて、要件の収集し、成功の見込みがあるソリューションに達するまで設計を洗練させる、Googleで実践されているアプローチ。

## 12.2　なぜ「非抽象的」なのか？
- どんなシステムでも、最終的には本物のネットワーク、データセンター、コンピュータの上で動作することになる
- このため、分散システムの設計者は、設計プロセスの複数の段階で机上の設計を具体的なリソースの概算量に変換する能力について継続的に訓練する必要がある
- これを精密にできない場合、実際の稼働に対応できないシステムを作り出してしまう
- 逆に、この作業を事前に行なっておけば、物理的な制約を予測できず最終段階でシステムの設計変更を行う必要に迫られる事態を減らすことができる
- この作業はマシンの台数などの数値を得るため
- これらの作業の繰り返しで大切なのはしっかり理由づけした仮定を置くことである。繰り返しの中で設計を理解することが大切

## 12.3　AdWordsの例
- AdWords: テキスト広告をGoogle検索に表示するシステム。
- CTR: 広告がクリックされた回数と広告が表示された回数の比
以下の例ではCTRを正確に計測しレポートできるシステムの設計を目指す。

### 12.3.1　設計プロセス
大まかにNALSDには2つのフェーズがある。それぞれのフェーズではいくつかの質問について考える。
1. 基本の設計フェーズ
原理的にうまく動く設計を目指す
1. 実現可能か?
2. もっと上手いやり方はないか?

2. 基本設計のスケールアップ
例えば劇的に要求を増やしたりする
1. 現実的か?
2. 弾力性があるか?
3. もっと上手いやり方はないか?

フェーズと質問はおおよそこの順序で進めるが、実際は質問とフェーズの間を行き来する。
この2つのフェーズの後イテレーションを開始する。
フェーズをうまく通過できた設計であっても後から苦労する場合もある。その際はやり直してコンポーネントを置き換えたり修正したりする。

### 12.3.2　初期の要件
広告と検索語について以下がわかっていること
- この検索語がこの広告を表示させるきっかけになった頻度
- 広告を見た人が広告をクリックした回数
以下のSLOを満たすこと
- ダッシュボードのクエリの99.9%が1秒以下で終わる。
- 表示されるCTRのデータは99.9%の場合で5分以内のものである。

### 12.3.3　1台のマシン
出発点として、シンプルにアプリケーション全体を1台のコンピューター上で動作させることを考える。
1台のマシンでRDBを使い、以下のようなテーブルを作り2つのテーブルをquery_idでジョインし、search_termでグループ化すれば、それぞれの検索に対してCTRをレポートできる。

クエリログ
time: クエリが行われた時刻
query_id: クエリのユニークな識別子（クエリID）
search_term: クエリの内容
ad_id: 検索に対して表示されたすべてのAdWords 広告のID。

クリックログ
time: クリックが行われた時刻
query_id
ad_id

#### 12.3.3.1 計算
これらのログすべてを解析するのに必要なリソースの量を計算する。

各クエリログのエントリを値のサイズにメタデータのサイズを加えて多めに見積もると2KBとなる。これをもとに、1日のログ量を計算すると86.4TB。RDBのインデックスによるオーバーヘッドを考慮すると、約100TBとなる。
この100TBという数字でストレージについて考えると、標準的なHDDでは要求を満たせないことがわかる。HDDより高性能なソリューションとしてRAMについて考えた場合、標準的なマシンで1563台が必要となる計算となる。

#### 12.3.3.2 評価
もしこの設計を1台のマシンに収められるとしても、障害が起きたらどうなるかを考えるとCPU、メモリ、ストレージ、電源…と大量の単一障害点が見つかる。これでは確実にSLOをサポートできないことがわかる。
計算上からも耐障害性の観点からも1台のマシンでの設計は現実的ではないが、この設計について考えるステップは無駄ではない。
このステップにより、この設計を複数マシンを使うものに発展させる必要があることがわかる。

### 12.3.4　分散システム
#### 12.3.4.1 MapReduce
MapReduceを使えば、大きなデータセットを大量のマシンで処理して結果を生成できる

##### 評価
間違いなく水平にスケールできる。しかし、ログの受信後5分以内に結合されたログを利用できるようにするというSLOは満たせない。

#### 12.3.4.2 LogJoiner

##### 計算

#### 12.3.4.3 シャードされたLogJoiner
##### 評価
#### 12.3.4.4 複数のデータセンター
##### 計算
##### 評価

## 12.4　まとめ

NALSDの実戦により、イテレーションごとに一からやり直すことなく設計の改善を進められる。
NALSDの鍵となる4つの質問により、それぞれのイテレーションを改善できる。
- 実現可能か?
- もっと上手いやり方はないか?
- 妥当な範囲でできる限りシンプルになっているか?
- 実行可能か?
- 弾力性があるか?
- 稀にではあるが不可避的に生じる障害を乗り切ることができるか?
NALSDは実戦により学習できるスキルである。
抽象的な要求から具体的なリソースを推定する能力は、長く現役でいられるシステムの構築に欠かせない。