Zenn
株式会社Inner ResourcePublicationへの投稿
🔍

キーワードでざっくり理解するSRE

tyamap
2024/05/09に公開
SRE
observability
SLO
SLI
tech

はじめに

私は最近SREに興味を持ち始め、いろいろと調べ始めたエンジニアで、実務でSREを取り扱っているわけではありません。
今回は私のように、SREに興味があるけれど、どのようなものかよくわからない、といった方に向けての情報共有としての投稿です。
認識の誤りやわかりにくい点がありましたら、コメントでご指摘いただければ幸いです。

今回のテーマ

  • SREの基本概念・キーワードを知る
  • SREを運用することで得られるものを知る
  • SREを運用する上で必要なアクションのイメージを持つ

SREの基本概念

SRE Site Reliability Engineering （サイト可用性エンジニアリング）とは、
ソフトウェアエンジニアの思考と技術で、サービスの信頼性を担保する運用設計を考えた時に出てくるものです。

SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるものです

My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team.
Google - Site Reliability Engineering

背景

「顧客により良い価値を提供する」という目的を実現するために、開発チームと運用チームはそれぞれ異なるミッションを持っています。

  • 開発チーム：
    • 新しい機能をリリースしてユーザーにより良い価値を届ける
    • イノベーション重視
  • 運用チーム：
    • ユーザーが安定してサービスを利用できるようにシステムを安定運用する
    • 信頼性重視

イノベーションを促進しつつ信頼性を確保することは、従来的なやり方ではうまくできません。
大抵、運用チームの負担が大きくなり、疲弊していきます。
そんな中で Google のソフトウェアエンジニアが、「俺たちの考えた最強の運用設計」を考えたのがSREの始まりです。

つまり、「イノベーションと信頼性の両立を実現するための取り組み」としてSREがあると考えます。

DevOps と SRE

DevOps とは、「開発チームと運用チームが相互に協力し合いながら開発を行い、迅速・高頻度にシステムをリリースすることでビジネスの価値を高めていく」という思想、概念を指します。

SRE はそれを実現するためのアクション・プラクティス・実装のことです。

SREのキーワード

CUJ

Critical User Journey

ユーザーが 1 つの目的を達成するために行う サービスとの一連のインタラクション、その中でもサービスの重要な機能・フロー。
ユーザー体験を見える化したカスタマージャーニーの中でも、特にビジネスの観点から重要とされる部分にフォーカスしたカスタマージャーニー です。

例: 「ユーザーが購入手続きボタンをクリックし、カートが処理されて領収書が返されるレスポンスを待つ。」

サービスレベル

Service Level

特定のサービスがユーザーに対して期待される作業をどの程度行えているかに関する測定値。

例: 「ユーザーは、サービスが利用可能で高速であることを期待する。」

SLI

Service Level Indicater

定量的に測定可能な、サービスレベルに関するユーザーの満足度の指標 。
リクエストのレイテンシや、エラー率など。

例: 「直近 10 分間における成功したリクエストの数を、直近 10 分間の有効なリクエストの数で割った値を測定する。」

SLO

Service Level Objective

サービスがほとんどの時間帯で達成すると期待されるレベル。
先にSLOがあって、必要な情報をSLIとして測定します。

ビジネスの価値をベースとして、SLOを考えて定めます。ここが最も重要な部分と言えます。

例: 「14 日間で測定されたすべての有効なリクエストの 95% でサービスのレスポンスが 400 ミリ秒より早い必要がある。」

SLA

Service Level Agreement

サービス提供者とユーザーとの間で結ばれるサービスのレベルに関する合意サービス水準、サービス品質保証。
SLIで示される、マストで担保されるべき可用性です。

エラーバジェット

Error Budget

エラーバジェット = 1 - SLO

例えば、あるシステムのSLOを「年間の可用性99.9%」と定義すると、年間で 8.76時間 までの停止を許容できることになります。

この時間を開発チームと運用（SRE）チームの共通の「資産」と考えて、有効活用する考え方です。
運用の方針は下記の通りです。

  1. SLO を定義する
  2. データに基づいて判断する
  3. 予算が残っている限りは、通常の DevOps のリズムは崩さない
  4. 予算をスプリントと合わせる

例えば開発チームが開発した機能をリリースするとして、SREチームがシステムを停止してアップデートします。そのリリースのために 1時間のダウンタイムが発生した場合、その時間がエラーバジェットから消費されます。
これまではリリースにかかる予算と故障対応の予算は別のものと考えられてきましたが、どちらもひとつの指標で管理することで、イノベーションと信頼性を両立していこうという考え方です。

エラーバジェットの考え方のメリット

  • 開発と SRE の共有のインセンティブになる
    • イノベーションと信頼性の適切なバランスを見つけられる
  • 開発チームが自分でリスクを管理できる
    • エラー予算をどう使うかは開発チームが決められる
  • 非現実的な信頼性の目標は魅力的でなくなる
    • そういった目標はイノベーションの速度を遅くすることがわかる
  • システム稼働時間に対する責任を共有する
    • インフラの障害もエラーバジェットを消費する

しかしエラーバジェットの考え方を導入しても、従来通りの運用だとすぐに予算は枯渇して、攻めの開発ができなくなります。 そこでソフトウェアエンジニアリングの技術を活用することになるわけです。
詳しくは後述の「SREを支える技術」で説明します。

トイル

Toil

トイルとは、プロダクションサービスを動作させることに関連するもののうち、手作業で繰り返し行われ、自動化することが可能であり、戦略的で長期的な価値を持たず、作業量がサービスの成長に比例する傾向を持つもの

Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.
Google - Site Reliability Engineering

  • 繰り返しやる作業
  • 自動化できそうな作業
  • そんなにビジネス価値向上につながらない作業
  • システムが大きくなればなるほどボリュームが増えそうな作業

トイルを削減するために、作業の自動化を行います。大抵はソフトウェアエンジニアリングの技術で自動化は実現できます。

一方で例えば新人の育成やチームマネジメントなどは自動化できないので、カリキュラムやマニュアルといったドキュメントを整理したり、評価制度を可視化するなどして、できる限り仕組み化・システム化していくことで、削減していきます。

サイロ

Silo

サイロとは、業務プロセスや業務アプリケーション、各種システムが孤立し、情報が連携されていない状態を指します

  • 各チームが個別最適でシステムを構築・ツールを導入している
  • 必要なデータがどこにあるのか把握されていない・連携されていない
  • チームによってデータのフォーマットが異なる

サイロ状態を解消するというミッションは DevOps の思想の中核にもなっています。

SREを支える技術

SLIを計測し、SLOを定め、エラーバジェットを有効活用するために、ソフトウェアエンジニアリングの技術を活用する、というのが、SREの基本となります。
そんなSREを支える、具体的な技術について、見ていきましょう。

モニタリング

Monitoring

SLI/SLO を正しく計測するための仕組みです。
サービスを、監視システムやAPM（Apprication Performance Monitoring）ツールを用いて監視します。
さらに適切に導入して、エラーの把握・故障箇所の特定・対処時間を短くすることができれば、エラーバジェットの消費を抑えることができます。

自律化

Autonomous

自律化とは、「発生した事象を正しく理解し、対処策を判断し、実行するまでの一連の動作を自動的に行うこと」を指します。一方で、「事象の理解と対処策までを人間が行い、実行をボタン一つで処理すること」を一般に自動化と言います。

発生する事象 自律化による効率化
急激なアクセス増によるリソース枯渇 自動でスケーリングして対処できる
サーバー故障によるシステムダウン 正常なサーバーに自動的に移動し再起動
リリースしたアプリにバグがあり、切り戻しが必要 自動で故障を判断し、切り戻しを実施

コンテナ

Container

これらの実現のために、コンテナやコンテナオーケストレーションサービス（コンテナプラットフォーム） が用いられます。
コンテナ技術を採用することで、デプロイ時にサービスを止める必要がなくなる Blue/Green デプロイなどの手法も取り入れやすくなります。
また、早く・正確に開発したり、リリース作業時間の短縮のためにテストやリリースを自動化する CI/CD の技術とコンテナも親和性が高いです。

まとめ

SREに取り組むメリットと、ソフトウェアエンジニアリングの技術との親和性について理解が深まったと思います。
ソフトウェアエンジニアリングのスキルを駆使して生産性の向上と「イノベーションと信頼性の両立」に取り組みましょう！

参考

GitHubで編集を提案
株式会社Inner Resource
株式会社Inner ResourcePublication

株式会社Inner Resource のエンジニアブログです。 忙しい研究者・研究施設の業務効率化のためのクラウド購買管理ソフト「リプルア」を開発しています。

Discussion