Sansan 事業部プロダクト開発部インフラ担当の岩下です。 こちらは Sansan Advent Calander 2018 の4日目の記事です。
先日参加させてもらったre:Invent、超たのしかったっす。
その中で面白かったCoinbase社、及びDataDog社によるSREの取り組みについてのセッションをご紹介したいと思います。
拙い翻訳で心苦しい限りですが、何かしらの気付きになれば幸いです。
本人より許可いただいています。 Thank you so much.
@niallohiggins @phrawzty hello. your SRE session at re:Invent was so great.
— ~/ (@rriifftt) 2018年12月3日
I'd like to introduce it in Japanese, is it OK?
SREとは何か
新しいものだから定義は変化し続ける。
その中で多くの誤解があるようだ。
これはSRE？
終わりのない火事場？なりやまないオンコール？トイルへの対応？
これらはSREの仕事ではない。
これらは症状であり、この病気に苦しんでいるのなら治癒する必要がある。
それを治癒するのがSREの仕事である。
Devopsとは？
SREは、すべてではないにしても、devopsのオペレーション、及び文化上の要素を満たすことができる
SRE本にもあるように、SREはdevopsの実装の一つであると言われている。
もし既にdevopsをやっているなら、SREはすぐにフィットするだろう。
Key SRE insight #1
計測し、人、組織、システムを改善する
SREはシステムだけを見るのではなく、インシデント発生時のプロセス、あるいはそれから何を学ぶか、組織のプロセスを改善できるか等の側面からアプローチする必要がある。
そのために常に、全てを計測しなければならない。
Key SRE insight #2
受動的ではなく自発的に。トイルを見つけ出し、それを排除する
自宅に火事が起こったら燃え尽きるまで見ているなんてことはせず、消防士を呼ぶだろう。
あるいは、実際に火事が起こるのは嫌なので発生を検知するために火災報知器を設置するなどの積極的な行動をするだろう。
これは問題が大きくなる前に排除するにあたって有効な手段だ。
受動的ではなく自発的に。これはとてもとても重要だ。
トイルとは？
トイルとはスケールしない手動のオペレーションであり、組織とともにどこまでも成長することがある。
成長するトイルを見逃していては組織の成長は阻害されるだろう。
SREはこの問題に対処する必要がある。
Key SRE insight #3
組織的なフィードバック
例えばデータベースのパフォーマンスがよくない状況においてはデプロイを止めた方がいい時がある。
これは適切なフィードバックがあるからできることであり、システムの信頼性を維持するには必要かつ重要なことだから、コミュニケーションには重点を置くべきである。
トップダウン、ボトムアップの双方で意識されるべきことだ。
Set Early Expectations
SREは新しい概念なので、新しい用語が多くある。
即時的な結果を求めず、ある程度の時間をかけながら始めるのがいいだろう。
でも何から始めればいいか？
Coinbase社では以下の戦略を取ることにした。
Service Level Indicators
何をどう改善すればよいか？何もなければよくわからない。
計測し、現状を理解し、サービスレベルの指標を設定することにした。
作業を進めるときなどには優先度を設定するが、それはどのように設定されるのか、客観的な指標を持つべきである。
その指標にはFour Golden Signalsというフレームが非常に役立つ。
我々はこれらをSLIのコアメトリクスとして採用することにした。
コアメトリクス
データは大量にあるかもしれないが、そのどれもが有用とは限らない。
ビジネスをゴールに向かわせるために本当に大切なメトリクスは何か、それを見極める必要がある。
Four Golden Signals
Four Golden Signalsとは以下のメトリクスである。
- Latency
- Traffic
- Errors
- Saturation
これらはどんなサービスにも適用できる普遍的な指標であると言える。
また、これは後述するが、人、チーム、組織に置いても適用することができる。
Latency
レイテンシーとはクライアントがWebサーバーからレスポンスを受け取るのにどれくらい時間がかかるのかを示すものであり、顧客の経験に直接的な影響がある。
なぜ遅いのか、それはあなたが計測する方法に依存するので難しい問題である。
ロードバランサーで計測するか、クライアント側でラウンドトリップを計測するか、あるいはサーバー側で計測するか、様々なオプションがあるだろう。
実用的な値を計測するにも複雑になりうる。まぁ、これら3つ全てが取れるならかなりいいよね。
Traffic
トラフィックとは作業量、または試行回数を意味する。
トラフィックはビジネスの価値、規模に大きく関係するが、大量のトラフィックに見舞われた時にシステムのどこかで落ちてしまうことがあるだろう。
なので、しきい値を設定する必要がある。
Errors
成功したリクエストと失敗したリクエストの比率をターゲットとして設定するのは簡単だし、効果的だろう。
例えば昨日はサイバーマンデーで、新たな導線を敷き、大量の消費行動が行われたとして、エラーレートが50%であれば使い物にならなず、0.1%であればそれは良い数字であると言えるだろう。
複雑なシステムではエラーが発生するのは当然起こりうることであるから、ゴールはエラーを排除することではなく、エラーをどこまで許容するかを明確にすることである。
また、このエラーレートを低く維持することをビジネス上の重要な目標とすることが望ましい。
Saturation
TrafficとSaturationは何が違うのか？
Trafficは試行の総量であるのに対し、Saturationは使用可能な総量である。
たとえばWebサーバーのメモリ使用量、DBのディスクスペースといったものだ。
これはソフトウェアそのものではないことから、いつでもどこでも起こりうることなので、指標としてこれまた重要なものであると言える。
ただし、Saturationが発生することはトリッキーな事態であるとも言える。
Humans and the Four Golden Signals
Four Golden Signalsは人やチーム、組織にも適用することができる。
Latencyは、人々がブロッカーを待っている時間に例えることができる。
依存関係のあるタスクを待つなどといった状況のことだ。
Trafficはそれより劇的で、スタックしているチケットの数として見ることができる。
Errorについては、人間は誰しも多かれ少なかれミスをする。
何らかの仕組みが必要となることがあるだろう。
Saturationを人という観点から見たときには燃え尽き症候群のようなものがイメージしやすいのではないだろうか。
燃え尽き症候群は大企業にとって大きな課題である。
Start, Then iterate
you can't finish something that you don't start
これらの課題に対するためには、まずはどこからか始めなければならない。
始めるにあたっては完璧である必要はないし、完璧であることはできない。
シンプルに！
繰り返し、フィードバックを与え、得ることが重要だ。ここに魔法はない。
Spreadsheets are simple, right?
さて、システム、ならびに組織にSLIを適用するにはどうすればいいだろうか。
適切なツールを使うことはやはり効果的だろう。
スプレッドシートはいいぞ(突然の金言)
見やすいし、シンプルだし、シェアしやすく、アクセス性もよい。
簡単にコラボレーションできるしオススメ。
サービスごとのFour Golden Signalをカラムに追加することから初めてはどうだろう。
追加サービスがあるのなら行を追加すればいいし、簡単だ。
SLIs: Defining "done"
システムやサービスにSLIを規定し、スプレッドシートを作成し、運用を開始したとする。
そしてFour Golden Signalsの内のいずれかがSLIに抵触したために作業をしたとして、完了したことを我々はどうやって知ればいいだろうか？
そのためには完了した状態を定義しておくとよいだろう。
まず第一に監視システムや、JIRAのチケットに完了したことを報告する。
次にどのようにして完了させたかを説明するためのドキュメンテーションを行う。
これは常に明確なドキュメントでなくてもよい。
なぜならどのようにこの指標を使用しているか、なぜ重要であるのか、誰が気にするべきなのかは必ずしも明白とは言えないからだ。
(結構ゆるめだなーという印象)
ダッシュボードはあなたの友達だが、注意すべきだ。
ダッシュボードには多くの情報があるはずだが、常に十分な情報があるわけではないので、翻弄されないようにした方がよい。
すでにSLI抵触に関するイテレーションが適切に回っている？それなら問題ない。
start somewhere, this is good place to start.
付け加えておくと、大きな障害を避けるためには予測をすることもとても重要だ。
Specification Documentation
SLIの抵触はCriticalな事態だ。
だからこそ、なぜその指標が重要なのかをドキュメントにしておくとよいだろう。
例えば、元々はELBでレイテンシーを計測していたが、やはりモバイルアプリのクライアント側で計測することが最適であるとして、メトリクスを変更したとしよう。
このような時にドキュメントが重要になってくる。
なぜこの指標が重要であるのか、また、それについての将来のロードマップがどのようなものであるのかを話すことができるからである。
SLIの文化を構築するには仕様文書を作成することに非常に大きな価値がある。
やみくもにドキュメント化するのではなく、組織の求めるものは何かを念頭に置き、重要なメトリクスをドキュメント化するとよいだろう。
First SLIs, then promises
あなたは顧客のために何を約束しますか？
また、他のチームが約束していることはあなたに依存しますか？
途方もないことかもしれないが、それについて考える必要があるだろう。
でも恐れることはない。良いPM、良いSREはビジネスの価値を知り、問題解決の能力があり、あなたの問いかけに回答してくれるだろう。
その下地を作るためにも計測し、改善し続けるしかない。
なぜこのようなことをしなければならないのか。
数千のメトリクス、重なる工数、難解な問題は山積みだ。
でも答えは一つ、それは約束を守るためだ。
突然の書籍紹介
Thinking in Promises.
http://shop.oreilly.com/product/0636920036289.do
(とてもいい本らしい)
Concerning Promises
promiseには2つのコンポーネントがあり、この場合は人間と機械である。
promiseは人間から機械へ、人間から人間へ、機械から機械へと設定することができる。
それらは常に対等の責任を負う必要はないが、それらの組み合わせの意味を考えることが重要である。
この組み合わせは機能を横断したチーム同士が協力しあっている状態であることが望ましく、より単純な帰結をもたらすだろう。
それは例えばAPIであったり、メッセージキューであったりするかもしれない。
Promises Example
promiseは平易に、明確に明文化すると効果的だ。
それを満たすか、満たさないかがひと目でわかるように。
promiseはSLIに組み込まれることもある。
(SRE本で言うところのSLOがpromiseであるようだ)
例として以下のようなものである。
- response within 50ms
- error rate will be > 1%
- on call 15min
Promise Enumration
各チームはpromiseを列挙したら公式化し、維持しなければならない。
また、その機能が果たすべきpromiseを理解していなければならない。
When Promises are Broken...
promiseが破られることは回避できない。
だからこそ、その時に何をすべきか規定しておかなければならない。
インシデントが発生したらどうする？
インシデント発生時のフィードバック方法は規定されている？
継続的なフィードバックは非常に重要である。
Post-Mortems
- blameless post-mortem
- blameless post-mortemがいいネーミングだとは思わないが。。
- https://techbeacon.com/blameless-postmortems-dont-work-heres-what-does
- data driven post-mortem
ポストモーテムには色々とあるが、重要なことは正しい計測、結果の分析、対処である。
そのためには計測した結果を正しく理解し、活用できなければならない。
これができなければポストモーテムはうまく回らないだろう。
Interpreting Incidents
ステークホルダーも交えて共通言語を決定しておくとスムーズに事が運ぶ。
英語なのかフランス語なのか、公式言語は決めておいた方がよい。そのための訓練も重要だ。様々な言語が飛び交う現場は混乱を招くだろう。
また、言うまでもなく発生したインシデントは広く共有すべき。
Measuring Incident Response
インシデントを定量的、定性的に計測するとよいだろう。
定量的にはインシデントを検知した時間、着手開始時間、リカバリーするまでの時間など。
定性的にはコミュニケーションは適切だったかなど。
これらの継続的なフィードバックは改善に向けて非常に重要である。
所感
計測と継続的フィードバックが重要であるということは各所でよく言われていることと思いますが、実際にやっている企業の事例を聞くとやはりとても刺激的ですね。
スプレッドシートから始めるという一見原始的と思える手法ですが、実践的でとても参考になりました。
元記事はこちら
