Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SRE study group 4th slide
Search
Korenaga Makoto
May 19, 2020
Technology
2
71
SRE study group 4th slide
Korenaga Makoto
May 19, 2020
Tweet
Share
More Decks by Korenaga Makoto
See All by Korenaga Makoto
SRE study group 3rd slide
hapoon
1
51
SRE study group 2nd slide
hapoon
1
43
SRE study group 1st slide
hapoon
1
58
Slackアプリを使ってデイリースクラムを効率化
hapoon
1
490
モノリシックからマイクロサービスへ
hapoon
0
100
Other Decks in Technology
See All in Technology
BCMathを高速化した一部始終をC言語でガチ目に解説する / BCMath performance improvement explanation
sakitakamachi
2
1.2k
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
210
OPENLOGI Company Profile
hr01
0
61k
SSH公開鍵認証による接続 / Connecting with SSH Public Key Authentication
kaityo256
PRO
2
220
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
110
銀行でDevOpsを進める理由と実践例 / 20250317 Masaki Iwama
shift_evolve
1
110
初めてのPostgreSQLメジャーバージョンアップ
kkato1
0
410
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
240
ひまプロプレゼンツ 「エンジニア格付けチェック 〜春の公開収録スペシャル〜」
kaaaichi
0
130
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
710
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
abnoumaru
0
390
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
Featured
See All Featured
The Language of Interfaces
destraynor
157
24k
The World Runs on Bad Software
bkeepers
PRO
67
11k
A designer walks into a library…
pauljervisheath
205
24k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
Practical Orchestrator
shlominoach
187
10k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
470
4 Signs Your Business is Dying
shpigford
183
22k
A Tale of Four Properties
chriscoyier
158
23k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
51
2.4k
It's Worth the Effort
3n
184
28k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
31
4.7k
Transcript
Site Reliability Engineering 4th DevOps unit study group Makoto Korenaga
アジェンダ 1. Googleにおける自動化の進化 2. リリースエンジニアリング 3. 単純さ
Googleにおける自動化の進化
自動化の価値 一貫性 何度も人によって行われるアクションはミスや品質の安定、信頼性という点で問題が ある。 例)アカウントの作成など
自動化の価値 プラットフォーム 適切に設計・実装された自動化はその後の自動化基盤(プラットフォーム)となり、間 違いを集約してくれるメリットがある
自動化の価値 高速な修復 システムでよくある障害解決を自動化することにより、MTTR(平均修復時間)を削減 することができる。
自動化の価値 時間の節約 自動化の為のコード化で初期コストはかかるが、その後は手作業での時間削減に繋 がる上に、作業がカプセル化されることにより誰でも実行できるようになる(属人化の 防止)
自動化のユースケース • ユーザーアカウントの作成 • サービス用のクラスタのターンアップおよびターンダウン • ソフトウェアやハードウェアのインストール準備や撤去 • 新しいバージョンのソフトウェアのロールアウト •
ランタイムの設定変更 • ランタイムの設定変更の特殊なケース:依存対象の設定変更
自動化の進化 • 自動化以前 データベースマスターのフェイルオーバーが手動で行われる状態 • 外部でメンテナンスされるシステム固有の自動化 SREでフェイルオーバーのスクリプトを持っている状態 • 外部でメンテナンスされる汎用の自動化 誰もが使用する汎用フェイルオーバーのスクリプトに追加されている状態
• 内部でメンテナンスされるシステム固有の自動化 データベース自身にフェイルオーバースクリプトが同梱されている状態 • システムが自動化を必要としない データベースが問題を検出し、人間の介入なしで自動フェイルオーバーできる状態
自分の仕事の自動化:何もかも自動化する • 手動でのフェイルオーバーは人間の時間をかなり消費し、最もうまくいっても99% の可用性しか得られず、ビジネス上の要求を満たせない • エラーバジェット内に収めるには1回のフェイルオーバーによる停止時間を30秒 以内にする必要があった フェイルオーバーの自動化 →フェイルオーバーに止まらずすべてを自動化する
リリースエンジニアリング
リリースエンジニアの役割 プロジェクトのリリースが確実に一貫して再現可能な方法で行われるようにする為に ツールの使用方法のベストプラクティスを定義する。 プロダクトを安全にデプロイしサービスを動作させ続ける為に、SREと協力し、変更の カナリアテスト、サービスの停止なしでの新リリースのプッシュ、問題が生じた機能の ロールバック戦略を開発する。
哲学 • セルフサービスモデル 自動化されたビルドシステムとデプロイメントツールの組み合わせでリリースを完全に自動化。 • 高速性 リリースを頻繁に行えるようにしバージョン間の変更をできるだけ少なくする • 密封ビルド ビルドツールは一貫性と再現性を持つ。別の開発者が同じコードをビルドした際に同じ結果になる。
• ポリシーと手順の強制 ◦ ソースコード変更の承認 ◦ リリースプロセス間の各手順の指定 ◦ 新しいリリースの作成とデプロイ
継続的ビルドとデプロイメント • ビルド GoogleではBlazeを使用(BazelとしてOSS化) • ブランチ • テスト 変更が投入される度にユニットテスト実行 •
パッケージ化 • Rapid 次ページで説明 • デプロイメント
Rapidアーキテクチャ • リクエストされたリビジョン番号を使い、 リリースブランチ生成 • Blazeを使ってバイナリコンパイルし、ユ ニットテストを実行(並列実行) •
システムテスト、カナリアデプロイメント の実施 • 各ステップの結果はロギングされ、リ リース後に変更に関するレポートが作成 される
設定管理 リリースエンジニアとSREが密に協力する領域の一つ • メインラインの設定使用 • バイナリと設定ファイルの同梱 • 設定ファイルをパッケージ化 • 外部ソースからの設定ファイル読み込み
頻繁に変更が必要だったり、動的な変更をする場合
まとめ リリースエンジニアリングは初期の段階から始めよう • パッケージのバージョン付けはどうするか? • 継続的ビルドやデプロイのモデルを採用するか?定期的なビルドが良いか? • リリース頻度はどれくらいか?
• 設定管理のポリシーはどうするか? • リリースに関して注目すべきメトリクスは? • リソース、期間や予算を計画されているか?
単純さ
システムの安定性とアジリティ 安定性を犠牲にしてアジリティを優先させる方が妥当なこともあります プロダクションソフトウェアの大部分は安定性とアジリティをバランス良く調整する必 要があります SREはソフトウェアの信頼性を高める為の手続き、プラクティス、ツールを作成する為 に働くと同時に開発者のアジリティに与える影響を最小限にとどめる必要もあります
退屈の美徳 ソフトウェアにおいて退屈なのは良いことで、プログラムには定められた通りに動作し 予想通りに作業目標を完遂してもらわなければなりません 必要な複雑さと想定外の複雑さを区別し、想定外の複雑さはエンジニアリングで解決 していくことが重要 • 受け持っているシステムに想定外の複雑さが生じていたら差し戻す • 関わっているシステムや運用を受け持つことになるシステムから複雑さを取り除 く努力を継続的に行う
単純さを保つ為に • 不要になったコードは削除する(無用な混乱をさせない為) ◦ BAD)コメントアウトして残す ◦ BAD)フラグで不要なコードを通らなくする • 最小限のAPI ◦
利用者に提供するメソッドや引数は必要最低限にする • モジュラー性 ◦ バイナリとバイナリ、バイナリと設定を疎結合にし単純にすることにより開発のアジリティとシス テムの安全性を同時に高めてくれる • リリースの単純さ ◦ 複数の変更をまとめてリリースより単一の変更をリリースする方が影響調査しやすい
• 時系列データからの実践的な アラート • オンコール対応 • 効果的なトラブルシューティン グ • 緊急対応
次回予告 第5回
ありがとうございました 参照: SRE サイトリライアビリティ エンジニアリング Googleの信頼性を支えるエンジニアリングチーム (オライリー・ジャパン)