スタディサプリ Product Team Blog

株式会社リクルートが開発するスタディサプリのプロダクトチームのブログです

SREの仕事とは?

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

SREとは?

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

  • Site Reliability Engineering
  • Site Reliabitlty Engineer

上はエンジニアリングを下はそれを仕事にする人を表していますが、およそ同じような内容ですので文脈から意味は捉えることができると思います。

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

SREの起こり、SREとは?

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

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

www.youtube.com

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

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

SREの普及

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

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

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

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

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

SLOとSLI

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

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

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

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

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

Margaret Hamilton - restoration

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)の開発責任者です。

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

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

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

http://blogs.discovermagazine.com/vintagespace/2018/01/05/apollo-11s-1202-alarm-explained/#.XMEBypMzbOQblogs.discovermagazine.com

最後の砦

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

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

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