helpdelete

【第8回】SRE本 輪読会 の個人的メモ

Miyaさんの資料

https://docs.google.com/presentation/d/13Y4q18Bixs7ArUMZwmp199M0KhB4fSlhB3cfQd-t-JE/edit#slide=id.p 

ここらへんも参考にしながら

7.5 苦痛の緩和:クラスタのターンアップへの自動化の適用

  • クラスタを立ち上げるのと同頻度で「チームが立ち上がる」
    • 程よいトレーニングになってた
  • 依存関係の網の目
    • 一つミスると顧客に直影響
  • 「12ディスクの最初のディスクを使ってなければ使ってない判定」のロジック
    • 案の定「重要なデータが吹き飛ぶ」
  • 「安全」シグナルの設計への注意
  • 「定型化されていない自由な」スクリプトは「技術負債のコレステロール」

7.5.1 Prodtest での不整合の検出

  • 用語
    • GFS: Google File System(後のColossus)
    • セル: セルはデータセンター内でジョブを実行するマシンの集合単位,平均で1万台構成
    • Prodtest: Prouction Testの略
  • 「独自スクリプト群」はスケーラビリティが無かった
    • サービスの依存対象がすべて利用可能で、適切に設定されているか。
    • すべての設定とパッケージは、他の動作環境と一貫しているか。
    • 例外的な設定はすべて意図的なものであることを確認できたか。
  • prodtestというものを使った
    • Pythonのユニットテストフレームワーク拡張
  • 「チームのクラスタ名」指定で、サービスをテスト出来る
  • 他チームの設定ミスで遅延したら、「Prodtestを拡張する」バグが登録できる

「3ヶ月以内に、5つの新しいクラスタが同日にネットワークの準備完了状態になる。 それらのクラスタを、1週間以内に立ち上げてほしい。」

7.5.2 不整合の冪等な解消

  • 用語
    • Macine Database: GoogleのDC内のマシンがすべて登録されるデータベース
    • Ads : Google AdSense, 広告最適化サービス
  • 「設定ミスを見つけるのユニットテスト」を「設定ミスを修正するコード」に
  • 「べき等な修正が必要」であるとは
    • チームがクラスタの設定にダメージを与える心配なく
    • 「修正スクリプト」を15分ごとに実行できる
  • どこかのテストでコケても「修正を試みる」
    • 複数回コケたら、そこで「失敗」とみなしユーザに通知する
  • 問題
    • テスト、修正、2回目のテスト「間の」レイテンシで不安定

7.5.3 特化する傾向

  • 用語
    • インセンティブ :　ご褒美
    • Admin Server : RPCベースで絶対に証跡の残るエージェント？
    • ACL : アクセスコントロールリスト、ユーザと権限の管理
  • 不格好な組織的インセンティブを作ってしまった
  • 「ターンアップ」は「自動化に向かない」最悪の処理
    • セキュテリティ観点から「sshdからRPCベースの管理デーモンへ」の置き換え
    • 「誰もログインできない」状態が功を奏し「最悪の処理」から抜け出すことができた

7.5.4 サービス指向のクラスタのターンアップ

  • クラスタのターンアップをSOAで行う
    • クラスタのTU/TDのRPCを扱うAdminServerの作成も、サービス所有者が受け持つ
  • ターンアップの進化
    1. 運用担当者が開始する手作業のアクション(自動化なし)
    2. 運用担当者が作成した、システム固有の自動化
    3. 外部でメンテナンスされる汎用の自動化
    4. 内部でメンテナンスされるシステム固有の自動化
    5. 人間による介入を必要としない自律的システム

7.6 Borg :ウェアハウススケールコンピュータの誕生

  • 用語
    • Google Borg : k8sのご先祖
  • クラスタ管理システムの開発の歴史
    • ラックに特定用途のマシンを乗っけてた
      • 「ゴールデン」バイナリと設定はマスターの中に存在
    • クラスタ使い始める
      • クラスタ=ドメイン名で管理した
      • ゆるい命名則で役割を決めてた
    • 並列SSHで管理
      • 「リソース(マシン)開放をチケットで知らせてた」時代
  • 自動化開始
    • シンプルなPythonスクリプト
      • サービス管理 :　サービスを動作させ続ける(セグフォの後のリスポンなど)
      • サービス追跡 :　どのサービスがどのマシンで動いてるか
      • ログのパース :　SSHでマシンに入り正規表現で検索
    • 次にデータベースとモニタリングツール
      • 故障通知、サービス除去、サーバの修理への配送、戻ってきたマシンへのリストア
  • そしてBorg
    • クラスタ管理を「集中的なコーディネータ」に発行可能なAPI呼び出しのエントリに変換するという発想
    • 非常にわずかな労力を一定量かけるだけで、継続的かつ自動的にOSをアップグレードできるようになりました
      • 一定量: 少なくて、その量が変化しないこと(≒人がスケールしない)
  • 「興味深い比喩」
    • 「他マシンへの再スケジューリング」は「他CPUへのプロセス移動」に似ている
    • 上記で考えると「システムが本来持っている機能」であるように思える
  • この比喩を使うと…
    • Googleのクラスタ -> 地球規模のコンピュータ
    • クラスタのターンアップ -> スケジュール割当可能なキャパ追加(RAM,ディスクの追加)
    • 自己修復が当たり前

7.7 基本的機能としての信頼性

  • 「自動化システムのが壊れたら、運用者はもうそれを直せない」問題
    • 「予想される動作」も「実際の動作」とはかけ離れる
  • 「本質が隠れ」ても「規模の大小にかかわらず、より自律的な動作を求めるべき」と主張する！
    • ※意訳

7.8 自動化のすすめ

  • 「そんなん言うても、Googleの規模なったら自動化したええって話でしょ？」
    • ２つの理由で間違ってる
      • 自動化のメリットは時間の節約だけではない
        • 後半ペイ出来る(意訳)
      • 「設計段階」に役立つ
        • サブシステムの分離、APIの導入、副作用の最小化などの標準的に優れたプラクティス

コラム「自動化による大規模な障害の発生」

  • 用語
    • colos ： コロケーション設備
    • コロケーション : ネットワークへの常時接続環境のもとに、サーバや回線接続装置などを共同の場所に設置する事,ハウジング
    • Diskerase : ディスクの自動消去とそれを確認するプロセス
  • ”空”が"すべて"と判断される問題
    • プログラムによく在る null や ""(から文字) に意味持っちゃった問題かな？
  • CDNの「イチ区画」が死んだが、なんとも無かったぜ

疑問(Q)

7.5冒頭

  • 「クラスタイフラストラクチャSREチーム」？ 10年前にSRE入ってんの？

7.5.1 Prodtest での不整合の検出

  • Prodtest(Production Test) …は「本番環境への自動単体(Unit)テスト流し」をイメージすれば良いのかな？
    • 「Serviceへのユニットテスト」というところが読まなければならないところかも
    • 「アプリを入れる前の仕込み」っぽいやつかな？
  • 「他チームの設定ミスで遅延したら、「Prodtestを拡張する」バグが登録できる」ってなんぞ？

7.5.2 不整合の冪等な解消

7.5.3 特化する傾向

  • 上の「３つの面」と下の対応がいまいち…うーんって感じ
  • 「不格好な組織的インセンティブを作ってしまった」って？
    • 価値基準としての「自動化を無視する傾向」の話かな？

7.5.4 サービス指向のクラスタのターンアップ

  • クラスタのTU/TDのRPCを扱うAdminServerの作成も、サービス所有者が受け持つ
    • 「開発チーム(というのか、サーバにデプロイされてるプロダクトを作ってるチームというか)」が、サーバへの「AdminServer 」の導入も行う、ってことかなぁ？

7.6 Borg:ウェアハウススケールコンピュータの誕生

  • 「クラスタ管理を集中的なコーディネータに発行可能なAPい呼び出しのエントリに変換するという発想」ってなんぞ？
    • 「マネージャっぽいAPIの口を用意する」「中は見えない(抽象化)」みたいな話かな？