Skip to content

Instantly share code, notes, and snippets.

@tanan

tanan/simplicity.md

Last active October 30, 2018 10:34
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tanan/8393cf6ef67e022f2108f32876d1be9c to your computer and use it in GitHub Desktop.
Save tanan/8393cf6ef67e022f2108f32876d1be9c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
simplicity.md

Regaining Simplicity

  • 大抵のシンプル化はシステムから要素を取り除くことで実現できる

    • すでに利用しなくなったリモートシステムからデータフェッチする処理を削除するだけの場合もあれば、再設計が必要になることもある
    • 例えば、２つのシステムが同じリモートデータにアクセスする必要がある場合、２回フェッチする必要があるが、よりシンプルなシステムは１度だけデータをフェッチして結果をフォワードできるかもしれない

  • シンプル化は効率化である

    • コンピュータ・ネットワークリソースをセーブする代わりに、エンジニアリングの時間や認知（理解）にかかる負荷を節約する => つまり、未来のリリースにとって有効

  • コードを追加することと、取り除くことは同等に祝福される

    • Googleのイントラでは大量のコードを削除したエンジニアのために「Zombie Code Slayer」バッチが飾られている

  • シンプル化も機能の一つである

    • シンプル化の優先度をあげ、SREの時間を確保する必要がある
    • SREチームやdeveloperがシンプル化のプロジェクトを自分のキャリアにとって有益であるとみなさない場合、このプロジェクトは実行されない。
    • 例えば、10%はシンプル化のプロジェクトに割り当てる等をした方が良い

  • システム規模が大きくなり、複雑になるに連れて、新しいチームをシステムの小さな部分に集中させて、SREチームを分割させる場合がある

    • これが必要な場合もあるが、新しいチームの範囲を狭めることで、より大きな単純化プロジェクトを推進する意欲や能力が低下する可能性がある
    • スタック全体の実用的知識を保持している小さなローテーショングループのSREを設計することを検討する。
    • システムを図式化することにより、システムを理解してその動作を予測する能力を妨げる深刻な設計上の問題を特定するのに役立ちます。

Amplification

  • エラーやタイムアウトが呼ばれたり、いくつかのレベルでリトライされる時、RPCの合計数が何倍にもなる原因になる

Cyclic dependencies

  • コンポーネントがそれ自体に依存しているとシステムの完全性が失われる可能性があり、システムのコールドスタートが不可能になる。

Case Study 3: Simplification of the Display Ads Spiderweb

Background

  • Googleのディスプレイ広告事業には買収に起因するもの（DoubleClick, AdMob,Invite Media等）があり、これらをGoogleのインフラで動作するようにしなければならなかった。例えば、DoubleClick for Publishersを使用するウェブサイトで、AdSenseで選択された広告を表示出来るようにしたい。同様に、DoubleClick Bid Managerで実行されるリアルタイムオークションにアクセスしたい。
  • 上記の独立して開発された製品は理由を説明しずらい相互接続されたバックエンドのシステムを形成した。トラフィックが各コンポーネントを通過した際に何が起きたか確認することが難しく、キャパシティを正確に測れない。
  • ある時点で、私たちはクエリーフロー内の無限ループを削除したことを確かめるテストを追加しました。

What we decided to do

  • 以下のような統一基準を策定
    • 大きなデータをコピーする単一の方法を確立
    • 外部データ検索を実行する単一の方法を確立
    • monitoring, provisioning, configurationのための共通テンプレートを提供

この取り組み前は、別々のプログラムが各製品のフロントエンドとオークション機能を提供していた。 図7-1に示すように、広告リクエストが2つのターゲティングシステムにヒットした場合、2番目のシステム用にリクエストを書き換えました。 これは追加のコードと処理が必要であり、また望ましくないループが発生する可能性もあった。

  • シンプル化のために、全てのユースケースを満たす共通プログラムと保護フラグを追加
  • 時間の経過とともにフラグを削除し、機能をより少ないバックエンドサーバに統合
  • サーバが統一されると、オークションサーバは両方のターゲティングサーバと直接やりとりでき、ルックアップの際にも統一されたオークションサーバで１回のみ必要となる

Lessons learned

  • すでに稼働しているシステム同士を、段階的に統合していくべき
  • 単一のプログラムで非常に似通った機能が存在するのは設計上の問題を表す「コードの臭い」を表している
  • 単一のリクエストで冗長検索をしてしまうのは「システムの臭い」を表している
  • 明確な統一基準を作成すると複雑さを解消するためのblueprintを提供でき、管理者が恩恵を得ることが出来る

Case Study 4: Running Hundreds of Microservices on a Shared Platform

Background

  • Googleのシステムの多くは、専用のSREチーム、開発フロー、CI/CD、監視等のスタックを持っている。
  • これはメンテナンス、開発コスト、独立したSREエンゲージメントの面で大きなオーバーヘッドとなる
  • チーム移動時の教育コストも高い

What we decided to do

  • サービスを構築するスタックをマイクロサービスプラットフォームに統合
  • このプラットフォームがベストプラクティスに準拠しているため、信頼性、デバッグを容易にした
  • レガシーサービスは新しいプラットフォームに移行するか、段階的に廃止する必要がある

Design

  • マイクロサービスを取り入れ、モノリスは徐々に移行。
  • 共通基盤上で、UI,API,CLI等を提供した

Outcomes

  • 開発チームが数百のサービスを深いSREの知見なしで運用できた。
  • また、共通プラットフォームはSREとdeveloperの関係も変えた。階層型SREエンゲージメントはGoogleで一般的になりつつある
  • 階層型SREエンゲージメントは軽いコンサルからデザインレビュー、深いエンゲージメント（オンコール通話の共有）などSRE関連のものも含む

Lessons learned

  • 共通基盤への移行は長期の投資 それぞれのステップが、インクリメンタルだが、究極的にはそれらのステップがオーバーヘッド軽減やスケールにつながる インクリメンタルな生産性の向上を目指す（最後にドカンとリファクタリングはやめる）

Case Study 5: pDNS No Longer Depends on Itself

Background

  • GoogleのプロダクションでサービスのIPアドレスを検索する場合は、Svelteというルックアップサービスをよく使用する
  • 以前は、Svelteのアドレスを見つけるために、pDNS（Production DNS）を利用していた。
  • pDNSはロードバランサー経由でアクセスし、実際のpDNSサーバに到達する。Svelteを利用するために...

Problem statement

  • pDNSはそれ自体にいきすぎた依存性があった。pDNSサービスは複製されていたので、Lookupは通常issueにはなっておらず、依存関係のループは、Googleプロダクションのどこかでいつでも利用できた。
  • しかしコールドスタートは不可能。
  • “We were like cave dwellers who could only light fires by running with a torch lit from the last campfire.”

What we decided to do

すべてのGoogleプロダクションマシンのローカルストレージに、近くにあるSvelteサーバーの現在のIPアドレスリストを維持した この変更により、他のほとんどのGoogleサービスのpDNSへの暗黙的な依存性も排除された 同様の問題を回避するため、pDNSとの通信が許可されているサービスをホワイトリスト化しゆっくりとその設定を減らしました。 その結果、シンプル化に成功し、信頼性が増した。

Lessons learned

  • サービスの依存関係に注意
  • 偶発的な追加を防ぐために、明示的なホワイトリストを使用する
  • 循環依存性を考慮する

Conclusion

  • シンプル化はSREの自然な目標。
  • 分散システムのシンプルさを図るのは難しいが、合理的なプロキシがあり、いくつかピックして改良する価値がある
  • SREは、システムのエンドツーエンドでの理解のために、複雑さの原因を特定、防止、修正する優れたポジションにある （ソフトウェア設計、システムアーキテクチャ、構成、展開プロセスの場所にかかわらず）
  • SREは、早期に設計討議に参加する必要があり、プロダクションを均質化するための標準を積極的に開発することもできる。かつ、継続的に注意とコミットメントが必要だが、価値のあること
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment