【Quipperブログ】SREのすすめ

こんにちは。Quipper採用担当の鈴木です。今回の記事は、SREの@moto_fによる「SREのすすめ」です！是非、ご覧ください！

皆さんは「SRE」って聞いたことあるでしょうか？近年SREという仕事が広まってきていますが、聞いたことがないという方も多くいらっしゃると思います。聞いたことがある方でも、いまいち掴みづらいと感じているかもしれません。そこでSREのメリットについてもっと多くの方に知ってもらうために、どんな時に役に立つのか、SREが提供できる本質的な価値はどんなことなのかを書こうと思います。

はじめに

SREという略語には２つの意味があります。

Site Reliabitlty Engineer
Site Reliability Engineering

上は人を下はエンジニアリングを表していますが、およそ同じような意味ですので、SREと略しても捉えることができると思います。

ぼくはQuipperでSREをしている深尾もとのぶ(@moto_f)と言います。過去には開発者、インフラエンジニア、運用という立場でも開発現場に携わってきました。そういった様々な立場から見てきた開発現場の課題の解決に、SREの考え方がヒントになるかもしれません。

SREの起こり、SREとは？

Site Reliability Engineeringは2003年にGoogleで誕生しました。Googleの設立が1998年ですから、ぼく個人の感覚としては案外SREの歴史は古いと感じます。当初はSREという概念や体系としてまとまっていたわけではなく、Google社におけるチームの名前という感じだったかもしれませんね。

Siteというワードが使われているのはもともとは ”google.com” の検索エンジンサイトを指しており、Reliabilityという単語は直訳すると"信頼性"です。簡単に言えば "google.com" をいつでも使える状態にすることがSREの仕事です。

このことはJC van Winkelが述べており、SREを理解する鍵はこのシンプルな目的にあると思います。ちなみにSiteという単語は形骸化して、今では必ずしもWebサイトだけではなく、例えばぼく達Quipperであれば、APIやアプリケーション、バックエンドのジョブなどもSite Reliabilityの対象になります。

SREの目的を端的に言えば「サービスやプロダクトをいつでも利用できるようにすること」です。まだユーザーが少なくサービスが落ちてもインバクトがないのなら、今はSREについて知る必要はないかもしれません。でも今後そうなる可能性があるのならSREがきっと役に立つはずです。

SREの普及

2014年からGoogleのSREメンバーを中心にSREconというカンファレンスが始まり、2015年に日本ではメルカリが先駆けてSREチームを作り、2016年にはSREのノウハウがまとめられた書籍がオライリーから刊行されました。SREという言葉は一般には浸透していないかもしれませんが、この頃から業界内に広まっていったと思います。

なぜこの時代に広まっていったのでしょうか？その理由の１つには、エンジニアリングの生産性の向上やテクノロジの発展により、新しい時代の新しい役割が求められたことが考えられます。

今日ではサーバを50台調達する場合でも早ければ１日でできてしまいますが、クラウドコンピューティングがなかった時代はハードウェアを運用する必要がありましたし、失敗したら簡単にやり直したり、破棄したりできなかったので、今では考えられないほど時間がかかっていました。見積りから始めて、契約、引き渡し、ミドルウェアのインストールを終えるまで順調に進んで３ヶ月、余裕を見て６ヶ月かかったこともざらにあったでしょう。ほんの５年ぐらい前までは数ヶ月かかっていたことが１日でできるようになったのです。

他にもWebアプリケーションのフレームワークやOSS、自動化や機械学習、プログラミング教育の発展など、あらゆる分野で生産性は向上し続けています。従来は開発者、インフラエンジニア、運用担当者でそれぞれが分業していたことでも、１人で広い領域をカバーできるようになりました。

一方でそれまでになかった課題も生まれました。新しいミドルウェアが登場して設計が多様化したり、事業と組織の早い成長によりソフトウェアが複雑化する中で、以前よりも何十倍、何百倍ものスピードでシステムに対する変更が求められ、行われるようになった結果、システムの障害も起こりやすくなりました。それに対する数あるプラクティスの中の１つとしてGoogleが10年以上かけて積み上げてきたSREのノウハウを活かせているのではないかと僕自身は思っています。

目的と目標

SREの大きな目的は「システムやサービスをいつでも使える状態にすること」です。ところで、それは100%を目指すべきでしょうか。
答えは「NO」です。医療や航空管制など人命が関わるようなシステムであれば、たとえコストをかけても限りなく高い信頼性を求められますが、時間とお金の限られたビジネスにおいて、システムの信頼性を高めようとし過ぎることはプロダクトや事業にとってマイナスになると言われています。

一定のラインを超えて信頼性を高めることは機会損失に繋がります。完璧なシステムを目指すよりある程度のエラーを許容しても、有限なリソースをサービスの改善や生産性の向上に費やした方がユーザーにとっての価値を最大化できる可能性があります。

そこでサービスレベル目標（SLO）を決めるという考え方がSREにあります。ただしSLOはユーザー体験に影響するので、決めるのはSREだけではなくステークホルダーが話し合って決めてください。ユーザーに対して良いサービスを提供するという観点でSLOを決めることにより、偶発的に発生するエラーやCPU使用率の上昇などに振り回されることなく、本質的な開発に集中することができるようになります。

目標がない状態ではすべてのアラートは良くないことのように感じられ、終わりのない消耗戦に陥りがちですが、SLOという目標ラインがあると例えば１週間ごとに目標達成を目指すというように、むしろポジティブに取り組むことができるようになります。SLOでは完璧を目指さない代わりに、サービスやプロダクト全体の本質的な価値の向上を追求します。

歴史上１人目のSRE、マーガレット・ハミルトン

And taking the historical view, who, then, looking back, might be the first SRE?
We like to think that Margaret Hamilton, working on the Apollo program on loan from MIT,

Googleで始まったSREですが、そんな彼らが考える歴史上の最初のSREのお話です。マーガレット・ハミルトン (Margaret Hamilton) はNASAのアポロ計画に使用されたアポロ誘導コンピューター (AGC)の開発責任者です。

なぜ彼女が史上１人目のSREだと考えられたのでしょうか？ぼくは彼女にはSREとして大切な２つの資質があると思います。１つ目はミスのない完璧なシステムやオペレーションを目指すのではなく、もし異常や人間のミスがあっても大丈夫なようにシステムを設計したこと。２つ目はAGCの設計だけでなく月面着陸および飛行士の生還というミッションにコミットしたことです。

1960年代、インターネットも携帯電話もない当時は、手書きやパンチカードを使ってプログラムを作る時代でした。数十行のコードを書くのにも多くの労力を必要とするそんな時代に、マーガレットは予期せぬエラーが起きた場合でも自動でリセットするようにAGCを設計しました。非常事態に備えた多くのコードは一度も実行されないままミッションが終わることもあります。彼女のとあるプロジェクトは"Forget it"と名付けられたほどです。

それでもそれはアポロ11の月面着陸船Eagleが最終アプローチに入った段階で1202アラームという形で作動しました。こうした彼女の功績がなければ、アポロ11は月まで届かなかったと言われています。

blogs.discovermagazine.com

最後の砦

物事の大小は違いますがちょっとした備えや支えが役に立つことは意外と日常的に起きています。マーガレット自身が当時はSREという言葉がなくてもそうしていたように、ひょっとしたらあなたもSREとは関係なくそういう行動をしていることがあるのではないでしょうか。

先日、QuipperでとあるDBの更新作業を行いました。その際、SREはいざデータが壊れてしまうという最悪のケースに備えてリカバリの準備をしました。
幸いメンテナンスは無事に終わり、時間をかけて用意したリカバリ用の手順や予備のDBが使われることはありませんでしたが、こういった「見えない支え」が役に立つ時は必ずやって来ます。

マーガレットが設計したリセットするためのコードやぼく達が用意したリカバリ用のDBが、実際に使われるような事態になることは誰にも望まれていません。それでも万が一、最悪の事態が起きてもプロジェクトや事業を継続するための最後の砦はSREです。