RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

トップ > SRE > SRE とは？ 【まとめ】

SRE とは？ 【まとめ】

SRE

初めに

初めまして、sakekobaです。

普段インフラのお仕事をさせて頂いておりますが、ここ数年の間に「SRE」という言葉を聞くようになったように感じます。
SREについて知りたいけど難しいな…。と思っていたので、SREについて、出来るだけ分かりやすくまとめる事にチャレンジしました。

  • 「SRE」とは分かりやすく言うと何なのか？
  • SREの取り組みは、具体的に何をすればいいのか？
  • どういう人がSREに向いているのか？

という点について、まとめてみました。

目次

「SRE」とは？

「SRE」をざっくり言うと「新しいサービス運用の考え方、そしてその役割」です。
SREとは「サイト・リライアビリティ・エンジニアリング」の頭文字をとった言葉で、日本語では「サイト信頼性エンジニアリング」となります。

サイト（サービス）の信頼性をエンジニアリングする（意訳ですが、しっかり作りこむ）ことを目的として、システムエンジニアリングの知見からのアプローチで、システム管理、運用をより良くします。
SREの中で謳われている「信頼性（が高い）」とは、ユーザが期待通りにサービスを使える（障害等で使えないことが無い（少ない））状態のことです。

勿論、SREが広まる前もシステムの運用者は高い信頼性維持を目指していますが、システム運用に求められるスキルは、「サーバ・NW・ミドルウェア等の幅広い知識を以て安定運用に寄与すること」であるため、運用者自身が手でコマンドを打つ等で運用作業を行うことが多い状態でした。
そのため、例えば下記のような問題がありました。

  • 手作業が多いと、それだけヒューマンエラーで障害のリスクがある
  • サービスの規模が大きくなると作業が増大し、人手や時間といったコストをかける必要があり、不具合改修、サービス向上にコストを振り分けられない
  • サービスの「開発者」と「運用者」が完全に分かれていることで、「ユーザの為により良い改善をどんどんリリースしたい」開発と、「安定稼働の為には、システムのリリース作業は最小限にしたい」と考える運用の間に大きな壁がありリリースのスピードが遅くなる

などなど… これらの問題を解消する役割が、SREです。
例えば下記があります。

  • SREチームが「信頼性」を定義し、皆で同じ方向を向く
  • 手作業が多いシステム管理・運用の分野に、SREが自動化を取り入れる
  • その他、エラー許容の定義や障害発生時の事後検証等、信頼性向上のための活動を行う

SREという言葉を提唱したのはGoogle社ですが、そのGoogle社が、下記の資料を公開しています。 sre.google

また、このSREについての資料の日本語版がオライリー社より出版されています。 www.oreilly.co.jp

SREは会社・サービスの課題によって様々なアプローチで信頼性の向上に取り組みます。 このブログでは、先に上げたSREの役割の例

  • 信頼性の定義
  • 省力化する
  • 信頼性向上のための活動

を少し掘り下げて記載したいと思います。

「SRE」の「信頼性」を定義する

SREのエンジニアチームには、「信頼性」を定義して関わる人を同じ方向に向ける役割があります。

そもそも「信頼性が高いサービス」とは何でしょうか。
24時間常に動作していて、応答が即座に返ってきて…と、思いつくものはあるかと思いますが、具体的にするとどうでしょう。
例えば・・・

「ECサイトで決済だけされて購入（在庫の確保）が遅い時があった」ら買えない場合もあり、怖くて使えないかもしれませんが、「暇つぶしの無料動画サイトで読み込みが遅い時があった」としても、怖くて使えない！とまでは思わないかもしれません。
また、同じECサイトだとしても、「お気に入りリスト」のような付属機能の更新が一時的に使えなかったとしても、購入機能ほど困らないかもしれません。

このように、ものによって全く違う期待に応える必要があるため、SREでは具体的に数字に落とし込むことで、関わる人が同じ方向を向けるようにします。
SREではこの信頼性の定義を、SLI 、SLA、SLOを用いて行います。

SLI

サービス・レベル・インジケーターと読みます。
サービスレベルを測るため、定量的な指標を定義します。
たとえば、「早くサイトが表示される」という目標だけでは、「1秒で表示されるのは遅い？早い？」のように人によってバラバラな捉え方をしてしまいます。
その為「理想的なリクエストの応答時間は0.5秒」のように指標となる定量的な項目を定義し、後述のSLOを測るために使います。

SLA

サービス・レベル・アグリーメントと読みます。
この言葉自体はSREに特化したものではない為、SREに関わらず、この用語を耳にされたことがあるかもしれません。
サービスを使用するユーザと「合意した（対外的に約束した）」サービスの品質のことです。
この「合意」はお金を払って契約しているサービスで、契約書に明記されている場合もあり、「契約違反では？」と言えてしまうようなものです。
絶対に守るべきラインとなるため、次に挙げる「SLO」より緩く設定されていることが一般的です。

SLO

サービス・レベル・オブジェクティブと読みます。
内部的に設定したサービスレベルの目標値です。
関わる人の認識を合わせるためでもあるので、高すぎても、低すぎても問題があります。
高すぎると、常に目標達成のため原因追及をする羽目になります。
低すぎると、普段は良くても「（内々にはSLOの範囲だけど）いつもより悪いとユーザからクレームが来た」等の時に対応に困る羽目になります。

SLOの考え方については、Googleのブログに具体的に書かれた記事があります。
cloud.google.com

省力化する

冒頭で上げた問題の例に、手作業に伴う問題がありました。

  • 手作業が多いと、それだけヒューマンエラーで障害のリスクがある
  • サービスの規模が大きくなると作業が増大し、人手や時間といったコストをかける必要があり、不具合改修、サービス向上にコストを振り分けられない

このような人が手で運用作業をすることに伴い発生する課題について、SREは、自動化を推進することで解消を図ります。 省力化はSREが担う役割の中でも重要なものの一つで、
GoogleのSREチームでは「SREが運用作業に充てて良い時間は業務の50％まで」とし、残りは運用作業の自動化や、サービスの開発などに振り分けるよう徹底しているほどだそうです。

この自動化できるのにしていない繰り返しの手作業は「トイル」と呼ばれています。
SREはこのトイルを見つけ出し、ソフトウェアエンジニアリングの知見で解消をすることで、ヒューマンエラーの低減、サービス向上のような作業への人的リソースの振り分けを行えるようにアプローチします。

SREのトイルの考え方、見つけ方についてより知りたい場合は、下記の記事が参考になると思います。
cloud.google.com

「運用を自動化しよう」というのは「SRE」だけでなく「DevOps」という言葉で聞いたことがある方も多いかと思います。
SREとDevOpsは相反するような考え方ではありません。
SREとDevOpsは、それぞれが独立した考え方ではなく、SREはより具体化し、自動化以外の要素も持ったものと言えるかと思います。

先に紹介したSREを提唱したGoogleの資料でも、下記のように記載されています。

DevOpsは、さまざまな組織、管理構造、および人員に対するいくつかのコアSRE原則の一般化と見なすことができます。（※日本語訳、本文は英語）
Google - Site Reliability Engineering

信頼性向上のための活動を行う

信頼性の定義や自動化だけでなく、SREはその会社・サービスが持つ運用課題を様々な方法で解決に向かわせます。
例えば、冒頭で挙げた

  • サービスの「開発者」と「運用者」が完全に分かれていることで、「ユーザの為により良い改善をどんどんリリースしたい」開発と、「安定稼働の為には、システムのリリース作業は最小限にしたい」と考える運用の間に大きな壁がありリリースのスピードが遅くなる

という問題点については、SREでは「エラーバジェット」という考え方を用いてアプローチします。

エラーバジェット

SREのアプローチとして、開発と運用のバランスを取るための方法です。

エラー等を許容する値を決めておき、エラーが許容量までであれば新機能の開発やリリースを優先してもよく、閾値を下回る場合は新規のリリースをとめて安定した運用を優先しなくてはならない、というルールを決めた運用方法です。
前述したSLOで、サービスレベルの目標値を決めておき、そのレベルまでのサービス品質の低下を許容するという考え方です。
この値を決め、ルールを設定することで開発と運用で同じ指標を共有出来、バランスを取ることが出来るようになります。

他にも、運用には障害対応がつきものです。
SREではこの障害を「ポストモーテム」という振り返り用の記録として残し、事後検証・共有し今後に活かそうという取り組みを行うこともあります。

ポストモーテム

障害・インシデントが発生した際、その内容、原因、対応などを文章化し、そこから再発防止や、ベストプラクティスを学びます。
SREが行うポストモーテムが、一般的な障害報告等と違うところは「決して非難しない」という点です。
非難を排除することで、問題が隠されてしまうことを防いだり、本質的な改善の議論にフォーカスすることが出来ます。

信頼性向上のため、多岐にわたる役割が内包されているSREですが、会社、サービスごとに取り巻く状況や解決するべき課題に差があります。
なのでSREチームが置かれていたとしても、どの会社も同じことをしているとは限りません。
一律に「この作業をする」と言い切れないところに、SREという言葉を理解する難しさがあると感じます。

ラクスのSRE課について

弊社ラクスにも、SRE課があります。
一例として、簡単にではありますが、弊社の取り組みを紹介させていただきます。

ラクスの取り組み

ラクスのSRE課では、現在各プロダクトの運用の自動化やモニタリング基盤の刷新などを進めています。
とは言え、まだ出来上がったばかりのチームで小さく始めたところです。

事例ですと、Kubernetesを利用した環境構築や運用のデプロイパイプラインの構築、モニタリングツールの導入支援といった業務を推進しています。
将来的にはこれらのノウハウを各プロダクトへ展開していきたいと考えています。

どういう人がSREエンジニアに向いているのか？

最後に、SREエンジニアになりたい場合、どのようなスキルや経験を積んでいるとより良いか、ラクスのSRE課に求める人物像を聞いてみました。

目的を正しく把握して行動に移せる　というのが一番重要なことだと思います。
SREとしてのプラクティスを実践するための技術的なスキルも重要ですが、
業務的にDevとOps双方と協業する立場ですので、目的がブレないようにしつつ、
関係者を巻き込んで改善していく行動力が特に重要だと考えています。
※スキルは一緒に学んでいけばよい、と考えています

ご興味ありましたら、以下内容をご確認ください！
career-recruit.rakus.co.jp

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.