Site cover image

Site icon imageけけずん積読消化記録

This is my Tsundoku records.
2024-06-22
書籍

🪡WIP: “SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本” を読んだ

はじめに

最近から所属しているチームのSRE担当として任命されたが、そもそもSREのことを全くわかっていない。SRE入門として下記の書籍が良いとお勧めされたので、早速Amazonでkindle版を購入してみた。500円と激安。

https://amzn.to/4bffmZb

なぜSREという考え方が生まれたのか

🗒️ 書かれてること

SREという考え方が生まれた理由や、それを実践して何が解決できるのかについて記載されている。

💡学び

  • SRE（Site Reliability Engineering）とは
    • Google社が提唱、実践しているシステム管理とサービス運用の方法論
    • パッチ当てや移行作業などを、ソフトウェアによる自動化を依頼した時点でSREが始まっている
    • 人的ミスによるシステム障害を最小化し、常にサービスが利用できる状態にすること（ = サービスの品質を向上すること）に注力すること
      • サービスを利用する側、サービスを提供する側のどちらにも配慮がされている
  • SREの起源
    • GoogleのBenjamin Treynor Slossさんが最初に立ち上げた
    • 「信頼性こそがあらゆるプロダクトの基本的な機能」
    • Googleのサービスでは多くの人に「信頼性」を提供するためにSREが必要だった
  • DevOpsとは
    • 開発担当者と運用担当者が連携して協力する開発手法
      • Dev = 設計、開発、テスト、リリースを担当
      • Ops = 運用、保守、障害対応を担当
    • 開発、運用などロール間の情報サイロを解消することが目的
  • Googleの10x（テンエックス）という考え方
    • 物事を現状より10%よくするよりも10倍欲するほうが簡単、という考え方
      • 馬車の速度を10%上げたい場合、どうすれば馬をより早く走らせることができるか、と考える
      • 10倍上げたい場合、馬だとどう考えても厳しいので別のアプローチ（車など）を考えるようになる

💬 感想

用語についての説明がされているはずだが、SREとDevOpsの関係についてもいまいちピンときていない。参考までに、下記はChatGPTに「SREとDevOpsの違いをバカでも分かるように簡潔に教えてください」と聞いてみた結果。

DevOpsは、開発者と運用担当者が協力してソフトウェアを速くて安全にリリースすることが目的で、チームで連携して働き自動化や効率化を目指す。SREは、システムが壊れにくくすることが目的で、ソフトウェアエンジニアが運用作業を行い自動化やモニタリングを使ってシステムの信頼性を高める。
要するに、DevOpsはチームで早く動き、SREはシステムが壊れないようにする専門家がいる感じです。

SREを理解するための用語解説

🗒️ 書かれてること

SREの理解を深めるために必要な用語についての説明が記載されている。

💡学び

  • 可用性（Availability）
    • システムが継続して稼働できる度合いや能力のこと
      • サービスが利用できない時間として、可用性99.9%は年間で8時間46分以内、99.99%の場合は年間で52分34秒以内となる
    • サービスの性質、設備投資、運用人員にかかるお金を考慮して適切に可用性を設定することが重要
  • 信頼性（Reliability）
    • ユーザが、サービスを使い続けたいと思えるかの尺度
    • サーバサイドだけでなく、ユーザの環境（デバイス、帯域、OS，サーバまでの距離）を再現して計測した値も考慮して信頼性を定義する必要がある
  • SLI（Service Level Indicators）
    • サービスレベル指標
    • ユーザが、サービスを使いやすい（もしくは使いづらい）、有益なサービスと思う指標のこと
      • 例： Playボタンを押した際に0.5秒以内で再生されること
    • SLI=良いイベント数/イベント総数∗100SLI = 良いイベント数 / イベント総数 * 100
    • 1つのサービスには2〜6個のSLIが標準的で、シンプルにするように推奨されている
  • SLO（Service Level Objectives）
    • サービスレベル目標
    • SLIで設定した値以内で完了したサービス提供回数が、どのくらいの割合で提供できればいいかという目標値
    • SLOで重要な3つの値
      • SLI
      • 期間 = SLIを計測する期間
      • 目標 = 特的の期間に期待するSLI達成の割合
  • SLA（Service Level Agreement）
    • サービス水準合意、またはサービス品質保証
    • SLOが未達の場合に、ユーザに対しての補償などを約束する法的な契約のこと
    • サービスの採用・不採用、プロバイダ選定などに有効となる指標
      • 例： クラウドサービスプロバイダの場合、補償として利用料のn%を返金する
  • SLI、SLO、SLAの順番
    • SLI → SLO → SLA という順番が一般的
    • SLAが高すぎると運用が大変で、低すぎるとユーザが離れるなど機会損失になる可能性もある
  • CUJ（Critical User Journey）
    • SLIを決める際に必要で、ユーザがサービスを利用して目的を達成するために実行する特定の手順のこと
  • パーセンタイル
    • 小さい数字から順に並べて、ある数値が小さい方から見て何%の位置にあるか表すもの
    • SLOを設定する際は平均値よりもパーセンタイルを使う
  • エラーバジェット
    • Devは機能追加・拡張により競合他社との差別化をしたいが、Opsはサービスの安定稼働を最優先にしたい → DevとOpsは相反する関係
    • DevとOpsを共通のルールで納得させるために考え出されたのがエラーバジェット

💬 感想

書籍