Site Reliability Engineering #2
2章 SREの観点から覽たGoogleのプロダクション環境
2.1 ハードウェア
Googleが設計した独自のデーターセンタ群から構成される
- マシン
- 一つのハードウェアまたは1つのVM
- サーバ
- サービスを実装しているソフトウェア
マシンは抽象化を施すことで、Googleのクラスタオペレーティングシステムである「Borg」がプログラムの実行に必要なリソースの割当を受け持つ。
データセンター内のマシン間の通信を支えるためにJupiterと呼ばれる高速な仮想スイッチをGoogleは開発した。 JupiterはClosネットワーク装置であり、サーバ間で1．3Pbsの帯域幅をサポートする。 データーセンタ群はSDNにより地球規模のバックボーンネットワークで相互接続されている。
2.2 ハードウェアを「組織化」するシステムソフトウェア
Googleはスケーラビリティが高いソフトウェアによりハードウェアの障害によりユーザが影響を受けないようにしている
BorgはApache Mesosに似た分散クラスタオペレーティングシステムでジョブをクラスタのレベルで管理する - ジョブは同一タスクが1つ以上含まれることがある
Borgは障害ドメインを考慮して、タスクをマシンに配置する
- #注釈 Borgはkubernetesの祖先にあたるシステム
タスクはHDPSに相当するストレージが利用でき、多くのレイヤーから構成される
- 最も下のレイヤーは物理のHDD or SSD
- 次にColossusでファイルシステムとレプリケーション、暗号化を提供する。GFSの後継
- Colossus上にはNoSQLのBigtableとSQLに似たSpannerが稼働する
- 他にもBlobstoreなどのDBが利用できる
ネットワークは世界中に分散配置されたシステムから、サービスのレイテンシを最小化する最も近いデータセンターにユーザを振り分ける。 ユーザの振り分けはGSLBで行われ、3つのレベルでロードバランスをする。
2.3 他のシステムソフトウェア
これらに加えて非同期の合意形成に利用するPaxosプロトコルを持つChubbyというストレージがある。
モニタリングとアラートのためにBorgmanというインスタンスがサーバのメトリクスをスクレイプしている。
2.4 Googleのソフトウェアインフラストラクチャ
極度にマルチスレッド化、かつRPCを使った通信に揃えたソフトウェアアーキテクチャとすることで、分散化を容易にしている。
また、protocol buffersによりXMLと比較してサイズが最大1/10、最大100倍高速化している。
2.5 Googleの開発環境
Googleは単一の共有リポジトリを使って作業することで、次のメリットを得ている
- プロジェクト外のコンポーネントに対して変更提案の”Changelist”をコンポーネントの所有者に贈り、メインラインに投入してもらうことができる
- ”Changelist”が投入されるたびに依存関係を持つコンポーネントのテストが実行され、所有者が異常に素早く気がつける
2.6 シェークスピア：サンプルのサービス
具体例としてシェークスピアの全作品から単語を検索できるサービスの提供を考えてみる。
ユーザからのリクエストは次のデータフローに沿って処理される
ユーザのリクエスト受付からユーザへのレスポンス開始まで数百ミリ秒の時間で実現している。
