Skip to main content himetani's cafe

The Site Reliability Workbookの12章を読んだ

The Site Reliability Workbookの12章を読んだので、自分の理解の要約をする

この章のテーマ

  • Googleでは、プロダクションで動くシステムにおいてreliabilityを最も問題だと考えている
  • reliablityを考慮した上で行うiterativeな設計や実装をNALSD(Non-Abstract Large System Design)と呼ぶ
  • NALSDによって、ロバストでスケールするシステムをより小さなオペレーションコストで構築できる
  • NALSDの考え方や実践例を紹介している.

NALSDとは

  • High Availabilityの求められる巨大なシステムに作るときに、要件を理解、設計、評価するときにSREが持つべきスキル.
  • キャパシティプランニング、Isolation、graceful degradationなど、さまざまな観点で複合的に考える必要がある.
  • 日々変化するシステムの要件に対して、設計の鍵となる部分を正しく分析・評価できることが重要だと考えられている.
  • iterativeなプラクティス

起こり得るfailure modeに対する防御と要件を満たす、巨大なシステムを構築するには、Reliablityの観点でさまざまなことを考える必要がある. それらのSREが行うべき仕事や、その過程を体系化している.

重要なのは、“Non-Abstract"の部分だ. SREに求められるのは、論理的に正しいシステムをデザインすることではなく、実際にリアルなデータセンターでリアルなネットワークの中で動き続けるシステムをデザインすることだ. これらの要求に対して、仮説と評価を繰り返すことで、完璧ではなくとも現実世界で実現可能な巨大なシステムをデザインする.

Google AdWordsでの例

Google AddwordsでのCTRのレポートシステムの例が示されていた.

NALSDの考え方によれば、システムがどのように育つことを期待するかを考慮した上で,システムをいくつかの論理的なコンポーネントに分割する. 適切に分割できると、個々の問題をそれぞれ一つのハードウェア、または一つのソフトウェアインスタンスの問題にブレイクダウンできるため、よりスケールしやすく、よりresiliantなシステムにできる. このようなデザインプロセスをiterativeなプロセスで行う. 各プロセスでは、フェーズに応じて4つの問いを念頭に置く.

Basic Design

  1. Is it possible?
    そもそもRAM、CPU、ネットワークバンド幅は要件を満たすために十分か？
  2. Can we do better?
    例えば、O(n)時間で解ける問題をO(logn)で解けないか?

Scale up Phase

  1. Is it feasible?
    ハードウェアや金銭面などの制約下で、スケール可能か？分散システムは要件を満たすか?
  2. Is it resilient?
    コンポーネントの一部、またはデータセンターがフェイルした場合にどうなるか?

実際のステップ

要件決め

システムに求められる要件を元に、SLOを決める.

1台のマシンで動かすと?

まずはじめに、シンプルに考えるために1台のマシンで全体のアプリケーションを動かすことを考える. 具体的に、扱うデータの量は？クエリの頻度はどれくらいか？どのような傾向があるか？など仮説を立てる. それらの仮説を元に、必要なRAMやディスクなどを定量的に概算し、それらがSLOを満たすか評価する. また、概算値とは別に、もしコンポーネントがfailした場合にどうなるか？ということもSLOと照らし合わせながら評価する.

ここまで評価した上で、1台のマシンでアプリケーションを動かす場合に実現不可能だと結論づける. これらのプロセスは一見無駄なものに思えるが、この結論に至るまでに手に入れた判断材料は、要件を正しく理解するのに役立つ.

分散システムのアーキテクチャを考える

ここではMapReduceとLogJoinerというアーキテクチャが検討されていた. このステップまでに、システムに求められる要件、SLO、ハードウェアやパフォーマンスの制約が明確になっているため、それらを元に評価する. ここではLogJoinerが採用されさらにSharded LogJoinerが考えられていた. このアーキテクチャについて、データの整合性や効率、一部のコンポーネントがフェイルした場合でも、SLOを満たすことができるか、などをより具体的な数値を元に議論する. 分散合意アルゴリズムを採用する場合のlatetncyや一部のデータセンターがある地域で災害が起きた場合に備えて、デザインしたシステムをマルチデータセンターで運用した場合についても、概算値を元に仮説を立て、SLOと照らし合わせながら設計を評価する.

最後に

要件を満たし、スケールし、パフォーマンスやReliablityについても問題ないシステムをデザインできた. めでたしめでたしとなるらしい.

所感

自分が感じたことは以下の2点だ.

  1. たとえ明らかに分散システムが必要であるような規模のシステムに対しも、シンプルなシステムから考え始めることが重要
  2. 経験や暗黙知がベースとなりがちな巨大なシステムのデザイン過程を体系化して説明していてえらい（ありがたい）

最終的にどういう設計にしたかではなく、その設計に至った理由やどういう仮説を立てたかが重要であると書いてあった. 仮説や設計判断の理由を明確にするために、シンプルな設計から始め、なぜシンプルな設計ではダメなのかを説明した上でより複雑な構成を考える、というステップがとても合理的だと感じた.

また、巨大で複雑なhigh availabilityの求められるシステムは、特に暗黙知や経験によってデザインや運用されることが多いと思う.
NALSDという枠組みを用いて、考えるべきことやその設計の過程を体系化していてすごくえらいしありがたいと思った.