SREとはなにか [サイト リライアビリティ エンジニアリング]

nwiizo

2021.9.28

ITサービスのインフラ運用・改善といった観点から「SRE」という言葉を耳にすることが増えてきました。以下では、SREとは何か、DevOpsやインフラエンジニアと何が違うか、どのような場面でSREが必要になるかといった点について解説いたします。また、「SREに関するTips」や「ITサービス企業の自社SRE事例」についても、あわせてご紹介します。

SREとはなにか

SREとは、ITサービスの信頼性を高めるために、ITエンジニア(開発者)が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームを指します。

SREの発端は、グーグルが自社の検索エンジンサイトである「google.com」を安定稼働させるために、システムアドミニストレータ(運用者)ではなく、エンジニアを用いてサービス横断的なアプローチに実施したアプローチを指します。なお、サイトリライアビリティエンジニアリング(Site Reliability Engineering)の頭文字を取ってSREと呼ばれますが、この「サイト」とは、当時信頼性を向上させる対象が「google.com」のウェブサイトであったことの名残りです。

当時のグーグルは、「google.com」で検索サービスを提供すること(そして閲覧者が広告をクリックすること)がビジネスの柱でした。よって、「google.com」にダウンタイムが生じることは、訪問者の「google.com」に対する信頼性を損ね、かつ、訪問者に広告をクリックしてもらい売上を創出する機会が減ることを意味しました。つまりグーグルにとって、サイトが安定して稼働することは、「サービスに欠かせない基本機能」だったのです。

なお、SREは現在「ウェブサイト」だけでなく、分散コンピューティングシステム全般に対して用いられるアプローチとなっています。

SREはどのようなアプローチを用いるか

SREと一言でいっても、SREが具体的にどのようなアプローチを用いるのかは意外に知られていません。大まかな流れを以下で解説します。

なお、本記事では、グーグルのSREチームが執筆した「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」参照、執筆しています。

1.SREチームを組織する

はじめに取り組むべきは、ソフトウェアエンジニアを中心とするSREチームを組織することです。グーグルでは、SREチームの50~60%は「グーグルの正規のソフトウェアエンジニア」で、残りの40~50%は「正規のエンジニア『予備軍』だが、他のメンバーには持っていないスキルを持っているエンジニア」を選定しています。

2.SLIを計測しSLOを設定する

ITサービスの運用に置いて、信頼性100%と、信頼性99.99%では大きな違いがあります。信頼性100%を実現するためには、99.99%とは異なり膨大な工数を投入する必要がありますが、ほとんどのユーザーにとっては「99.999%」が「100%」になったからといって、大きなメリットがあるわけではありません。つまり、100%を目指すことは効率的ではないため、各サービスごとに適切な可用性を設定する必要があります。

はじめに、SLIですが、これは「Service Level indicator」の略で、提供されているサービスのレベルの性質を定義した計測量です。一般的には以下をSLIとして用います。

  • リクエストのレイテンシ(リクエストに対するレスポンスを返すまでにかかった時間)
  • エラー率(受信したリクエストを正常に処理できなかった比率)
  • システムスループット(単位時間あたりに処理できるリクエスト数)
  • 可用性(サービスが利用できる時間の比率)

次に、SLOですが、これは「Service Level Objective」の略で、SLIで計測されるサービスレベルの目標値、または目標値の範囲を指します。例えば、SLOを「年99.99%」と設定すると、「1年のうち52分は稼働しなくてもよい」ということになります。例えば、「1年の間にサービスが30分停止する障害」が生じたとしても、SLOの範囲であればそれは想定の範囲であり、問題ではなくなります。

同様の用語で、SLA(Service Level Agreement)がありますが、こちらはITサービスの契約において「この稼働率を下回る場合、金銭的な保証を行う」ことを示す値です。SLIは測定値、SLOは補償を伴わない目標値である点で異なります。

3.自動化・省力化するためにプログラムを書く

SREが「システムアドミニストレーター」ではない最大の特徴は、システムの拡大に伴い、保守運用工数が正比例して増大することなないように、自分たちでプログラムを書いて積極的に自動化・省力化を行う点です。このため、SREという言葉には「エンジニアリング」という言葉が含まれています。

この「プログラムを書く」という意味は、「運用工数を減らすためのプログラムを書く」という意味と、「サービス自体のプログラムを書く」の2つの意味があります。運用工数を減らすために、サービスのプログラムの修正が必要な場合、SREチームがサービスのプログラムを開発チームに代わり書くことまで含まれます。

これができる理由は、製品サービスの開発チームと、SREチームとの壁を低くし、人材が相互に行き来させるためです。つまり、チーム全体を相互にトレーニングできているのです。

4.運用を改善する

SREが行う運用改善は詳細かつ広範囲なアプローチを含みます。ここで、その中から特に重要な点のみ紹介します。

(1)モニタリングの改善

かつてはグーグルでも、障害発生時の対応として、「何らかのシステム上のしきい値を超えた場合にメールが自動で担当者に送信され、担当者は『メールを見て、なにを行うべきかを考える』」という手法を用いていました。しかしこの方法は、人間の解釈に依存する属人的な対応を行うこととなるため、グーグルではモニタリングの出力を3つに分けています。

  • アラート
    • 即座のアクションが必要な事態が発生(また今後発生する見込み)
  • チケット
    • アクションが必要だが、即時でなくてもよい(数日間の猶予がある)
  • ロギング
    • アクション不要。今後の診断目的で記録・通知されるもの。

上記はあくまでグーグルの例です。SREを導入する企業は、各サービスごとに「どのようなモニタリング出力方法が最適か」を検討し、改善を加えて行く必要があります。

(2)緊急対応時の手順書作成

グーグルでは、サービスに緊急対応が発生した場合、「即興で対応する」のではなく、「あらかじめ作成された手順書通りに対応する」場合、平均修復時間に3倍の改善が見られました。

このため、SREチームは各サービスの綿密なトラブルシューティングならび手順書・ヒントの作成が求められます。

(3)変更管理

グーグルSREチームは、およそ70%のサービス障害は、稼働中のシステム変更が原因であることを突き止めました。これを防ぐためには、以下の3点が必要とされます。

・漸進的なロールアウトの実装

・高速かつ正確な問題の検出

・問題が生じた際の安全なロールバック

「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」1.3.5. 変更管理

この3つの取組みを一体として行うことで、リリース速度とリリースの安定性の両立が可能となります。

(4)需要予測/キャパシティプランニング/プロビジョニング/効率的なリソース活用

サービスの今後の成長を予測し、それに見合ったキャパシティを確保することは、サービスの信頼性確保にとって重要です。

サービスの成長は大きく分けて「自然な成長(ユーザー数や利用頻度の漸進的な増加)」と「突発的な成長(機能追加、キャンペーンなど)」があります。予測には、自然な成長だけでなく、突発的な成長も織り込む必要があります。

そして、プロビジョニングは「必要な分だけ」「正確に」「かつ迅速に」行われる必要があります。必要分以上のプロビジョニングはコストがかかり効率性が悪化すること、また不正確かつ迅速でないプロビジョニングはシステム稼働停止リスクがあるためです。リソース活用はあくまで「利用率」をもとに効率性の観点から判断されるべきです。

(5)ポストモーテム

ポストモーテム (post mortem) とは「検死」を意味する言葉です。

サービス運用において障害や失敗が発生した際、「障害や失敗をひとまず収束されたから、それでよし」とするのでなく、障害や失敗から学びを得るための定型化されたプロセスを設けること、そして再発を防止するための対策を確実に導入すること。これがSREにおけるポストモーテムです。

なお、ポストモーテムが「担当者やチームの吊し上げの場」となってはいけません。誰かを吊し上げたところで、サービスの信頼性は向上しないどころか、「吊るし上げられることを恐れて問題を隠蔽する」ようになりかねません。

ポストモーテムで必要なのは、問題につながったアクションを特定し、その問題が正しくドキュメント化され、影響を及ぶす全ての根本原因が理解されること、そして再発を防ぐための予防策が確実に導入されることです。

なお、上記はSREが行う基本的なアプローチを抽出したものです。組織やサービスによって、適用方法も異なってくると考えられますので、あくまで参考としてご理解ください。


SRE実施企業の事例紹介

以下では、「すでにSREを実施している企業の事例」について紹介いたします。

株式会社エウレカ

エウレカは、自社が運営するマッチングサービスである「pairs」の運用品質向上のためにSREチームを設け、「エウレカのSREとして何を行うか」を定義し、日々改善の取り組みを行っています。

エウレカSREチームのミッション定義と取り組み

エウレカでSREチームが発足した当時のチームのミッションは以下の通りです。

  • 一言でいうと「会社の目指すビジネスの実現の阻害確立を上げる要因を全て排除すること」
    • 可用性99.5%
    • クリティカルなセキュリティリスクの撲滅
    • 適切なキャパシティプランニング
    • リリースエコシステムの改善と安定化
    • 事業価値最大化のための技術サポート

そして、ミッション達成のために以下の取り組みを行っています。

  • 技術的な取り組み(一例)
    • SLO/SLIの定義
    • 全サービスへのIaC (Infrastructure as Code) の適用
    • VM→コンテナへの移行
    • サブシステム・関連システムのサーバーレス化
    • クエリ修正・コード修正(サーバー負荷軽減目的)
    • トラフィックのスケーラビリティ確保
    • Datadogによる監視・モニタリング、など
  • 技術的以外の取り組み
    • ポストモーテム文化の醸成
    • 障害対応のフロー構築
    • リード・テンプレートの作成
    • 障害チケット発行からのスタッフ招集の仕組み

ミッションの再定義と新たな取り組み

エウレカのSREチームの取り組みは大きな成果を生んだ反面、「役割範囲が広すぎるため投資が広く薄くなってしまう」「SREチームに責任が集中した結果ボトルネックが発生」といった問題が発生しました。このため、エウレカSREチームは自身のミッションを以下のポイントで再定義しています。

  • 会社に提供する価値
    • SREという役割に囚われすぎないで価値を提供
  • リソース配分
    • リソースの50%を「外部依頼への対応(監査、インフラ構築など)」と「トイル(繰り返し発生する運用作業)」に割き、残り50%を「課題定義とロードマップ構築」に充てる
  • やらないこと
    • 別チームへ業務を移管し、SREチームの業務対象外とするなど

そして、SREチームとして大事な点として、「SREのエッセンスを大事にしつつ、常に変化・改善し続けること」としています。定義についても、半年や一年で見直して改善を繰り返すことが望ましいとしています。

まとめ

エウレカのSREチームの活動から得られる教訓は、3つです。

  • グーグルが定義する『SRE』に囚われすぎないこと
  • 技術的な取り組みと、技術的以外の取り組みを並行させる
  • ミッションの定義は必要だが、ミッションは定期的に見直す

貴社のSREの取り組みにお役立ていただければ幸いです。

*本項は以下のページ記載内容を引用、再構成したうえで解説を行っています。
エウレカ SREチームの2021年までの取り組みとこれから

株式会社メルカリ

メルカリは、自社が運営するフリーマーケットアプリである「メルカリ」ならび金融サービス「メルペイ」の運用品質向上のためにSREチームを設け、システムの信頼性向上に取り組んでいます。

SREチーム立ち上げから現在

メルカリのSREチームの役割は、自社サービスである「メルカリ」を少ないダウンタイムで、かつ早いレスポンスで利用できるようにすることで、サービスの信頼性を高めることが目的とされています。

2015年に発足したメルカリのSREチームは、当初以下を業務範囲としていました。

  • APIサーバ、ミドルウェアの可用性の維持・向上
  • APIサーバ、ミドルウェアのパフォーマンスの向上
  • ログ収集・分析基盤の構築、運用
  • サーバプロビジョニング・デプロイの整備
  • セキュリティの担保
  • 開発環境などの整備

しかし、2018年頃からはじまった「メルカリ」のマイクロサービスへの移行ならび、高い信頼性を求められる金融サービス「メルペイ」の運用開始により、SREチームによる横断的な信頼性向上の取り組みが難しくなっていたとされます。結果、「メルカリ」と「メルペイ」を横断した今日着き版を開発・提供するチームが発足し、これに応じてSREチームでも新しいチームを立ち上げています。

マイクロサービスSREとエンベデッドSRE

メルカリでは、従来の「SREカスタマー」チームを改め、「マイクロサービスSRE (Microservices SRE)」チームを発足させました。マイクロサービスチームは各チームに運用上のオーナーシップが委ねられているが、チーム横断で信頼性向上を行うためのチームです。

そして、SREチームメンバーは「エンベデッドSRE (Embedded SRE)」という役割を担うこととなりました。Embedded SREとは、職能横断的な「プロダクトチームの一員」として割り当てられることが特徴で、それぞれ担当するマイクロサービスを持ち、その品質改善に努めます。

プロダクトチームから高い評価

マイクロサービスSRE、エンベデッドSREというアイデアは、プロダクトチームから高く評価されました。各マイクロサービスチームからの評価の平均は5点満点の4.63という高評価です。

今後は、複数のマイクロサービスに共通する課題の発掘と解決ならびツール整備に注力を行うとのことです。

まとめ

メルカリSREチームから学ぶことができるのは、「グーグルが開発したSREという方法論を正しく行う」「その後、SREをメルカリにあわせて進化させる」という点です。これはまさに「守破離」の考えそのものといってよいと思います。

貴社のSREの取り組みのお役に立てれば幸いです。

*本項は以下のページ記載内容を引用、再構成したうえで解説を行っています。
インフラチーム改め Site Reliability Engineering (SRE) チームになりました
開発チームとともに歩むSREチームが成し遂げたいこと mercari engineering

株式会社ヌーラボ

ヌーラボは、プロジェクト管理ツール「Backlog」や、ビジュアルコラボレーションツール「Cacoo」などを開発・販売するIT企業です。以下では、ヌーラボのSREチームの取り組みについて解説します。

ヌーラボSREの歴史

かつてヌーラボはエンジニア全員がサービス開発にあたっていましたが、2015年にインフラエンジニアが入社し、SREの取り組みが開始されています。

ヌーラボのSRE組織についてですが、「開発チームに含めたほうが良いか」「プロダクトチームに含めたほうが良いか」「独立した組織としたほうが良いか」といった議論を経て、現在では「各サービスを開発する課」とは独立した形で「SRE課」が発足しています。

これは、SREは担当プロダクトを持ちながらも、各開発チームに対して横断的に連携を進めることがミッションとされたためです。

なお、SREが各プロダクトの開発チームとは独立した組織になることのデメリット(例: プロダクト開発の細かな状況が分からなくなる)を回避するため、週に一度の会議を設けてリリース予定の共有や現在起こっている問題についての議論を行うようにしています。

ヌーラボSRE課の役割と取り組み

SRE課では以下のプロセスで、信頼性向上のための活動を行っています。

  • SRE課のメンバーは改善のためのバックログを作成する。このバックログをもとに月に1度「棚卸し会議」を行い、「どの課題に優先的に取り組むか」を決定する。
  • 1ヶ月以内の改善活動についてはSREのみで取り組み、1ヶ月を超える活動の場合はSREとプロダクト開発者の両方でチームを作りプロジェクト化する。

取り組みの例としては、以下の事例が紹介され、大きな成果を発揮しています。

「Backlog」画像検索機能のリプレイス

  • プロジェクト期間: 5ヶ月間
  • チーム: SRE 1名、開発者1-2名(時期により変動)
  • 課題: スケーラビリティ、可用性、ハードウェアコスト、運用コスト、新サービス追加やマイクロサービス化の足かせとなっている
  • 対策: 既存機能のリプレイス
  • 結果: 当初の課題を全て解決。アプリケーション・サーバー上のインデックスファイルが不要となり、結果、アプリケーション・サーバーのコンテナ化・分割が可能に。

まとめ

SREが「タテ(プロダクトチーム寄り)」の役割を果たすのか、それとも「ヨコ(組織横断的)」の役割を果たすのかは、サービスの規模や数、組織の人材や文化などにより決定されるべきで「これが正解」といったものは存在しません。

貴社でSREを検討の際には、ぜひ上記内容をご参考いただき、また当社がお手伝いできる場面があればお気軽に問い合わせいただければ幸いです。

*本項は以下のページ記載内容を引用、再構成したうえで解説を行っています。
ヌーラボのSREは歴史の長いプロダクトをどのように改善しているか? #ヌーラボのアドベントカレンダー

ヤフー株式会社 (Private PaaS チーム)

ヤフーのPrivate PaaS(自社向けのPaaS環境)を構築するエンジニアは、サービス信頼性向上のためにSREを行っています。

ヤフー Private SaaSの概要と規模

ヤフーが自社のサービス構築のために準備しているPrivate PaaSは以下の環境で構築されています。

  • クラウド基盤: VMware Tanzu Application Service (TAS)
  • TASクラスタ数: 25 (本番) + 3 (開発環境) + 2 (性能試験)
  • 本番アプリケーション数: 約17,000
  • 本番稼働アプリケーションコンテナ数: 約80,000
  • 処理リクエスト数 (平均リクエスト/秒): 約350,000
  • 処理リクエストピーク数 (平均リクエスト/秒): 約600,000

アプリケーション数、コンテナ数、リクエスト数などはまさに膨大といってよく、世界でも有数なレベルのサービス規模です。なお、「TAS 25クラスタ」といってもピンと来ませんが、「1つのTASのクラスタでメモリ間さんで10TB以上のアプリケーションを稼働できる」というレベルの巨大さです。

SLO設定・SLI測定

はじめに、「ヤフーPrivate PaaSでSREを行うに際して、何を指標とするか」ですが、ヤフーでは「PaaS利用者から見える機能」に着目し、以下の2つを挙げています。

(1)アプリケーションデプロイジョブキューのエラー率
(2)アプリケーションのPaaSへのデプロイ成功率

まず、Private PaaS部門は「アプリケーション開発部門」ではありません。各アプリケーションを開発する部門、エンジニアに対して信頼できる開発実行環境を提供するのがその役割です。このため、指標は「アプリケーション」で設定されていません。

なおSLOですが、「SLO = PaaS利用者が不都合のないSLI値」として、90%~99.99%で設定されています。さらに「システム障害時の影響度」に応じて、4段階にレベル分けされています。

  • レベル0: ヤフーのサービス利用者に直ちに悪影響がでるものもの
  • レベル1: ヤフーのサービス利用者に悪影響がでる可能性がある
  • レベル2: ヤフーのサービス利用者に影響はないが、社内の開発者に直ちに悪影響がでるもの
  • レベル3: ヤフーのサービス利用者に影響はないが、社内の開発者に悪影響が出る可能性があるもの

事例内では明示されていませんが、重要度が最も高いレベル0は99.99%、最も低いレベル3は90%で設定されていると考えられます。

そして、各SLOレベルに応じて細かくSLIが設定されています。具体的には「HTTPSアクセス成功率」「コンテナ通信成功率」「アプリケーション正常動作率」などです。

SLIならびSLOの運用と改善

SLOレベルは、SLIがSLOを下回る(実際の測定値が目標値を下回る)場合の対応を定めています。ユーザーに影響が出ている(または出る可能性がある)場合は、24時間365日対応を行い、社内開発者飲みに影響が出ている(または出る可能性がある)場合は業務時間内での対応としています。

次に、SLO値の見直しについてですが、「SLOを満たしているが、社内エンジニアからエラーに関する問い合わせが来る」「障害対応を求められる」場合に、もともと設定されていたSLOが適切でない(低すぎる)と判断し、SLOの引き上げを行っています。

また、利用者が少ないのでSLIを計測していなかった値が、後に障害要因となったケースなどでは、この反省を踏まえてSLIの追加を行い、測定すべきSLIを増加させています。

さらに、設定されているSLIが適切でない場合(例: SLI計測に用いていたデプロ対象のサンプルアプリのメモリ設定値が小さすぎる)、計測基準を変更するなどして対応しています。

メリットと課題

メリットは、Private PaaSチーム全体で稼働状況を把握できるため、SLI/SLOを用いたリリース判断や障害対応判断を行えるようになったとしています。

課題としては、「SLI計測値としては正常だが、一部のPaaS利用者に重大な障害が発生するケース」を捉えきれていない点です。SLIは十分にSLOを満たすほど高く、全体としては正しく運用されているが、一部ユーザーは頻繁に障害が発生しているようなケースです。今後はこうしたケースに対する対応が課題となっています。

*本項は以下のページ記載内容を引用、再構成したうえで解説を行っています。
ヤフーのPrivate PaaSチームにおけるSREの取り組み 〜 サービス安定稼働に向けた指標計測

株式会社monotaRO (モノタロウ)

事業者向け工業用間接資材の販売会社であるモノタロウは、売上の90%以上をオンラインからの受注が占めるEC企業です。

SREチームを社内に設けて、日々「monotaro.com」の信頼性向上のための活動をおこなていますが、通常の手順では解決できないトラブルをどのように解決したかについて解説しています。

発生したトラブルとそれに対する対応

あるとき、モノタロウのWebサービス全体でレイテンシ悪化やバックエンドAPIへのタイムアウト増加が頻発しました。

レイテンシ悪化はよくある問題であるため、通常の手順で対応したところ、問題は即座に解決せず、アラートが鳴り止まない状態となりました。具体的には「ある短時間にエラーが増加している」というアラートと、「レイテンシ悪化」のアラートが両方飛んでいました。

通常の手順でははじめに、代表的な指標を掲載したダッシュボードを確認し、サイト全体の動向を把握します。その後、ダッシュボードから得た情報をもとに仮説を立て、その仮説に沿ってさらなる調査を行い対策を行います。具体的には「サーバーを特定してスケールアウトする」といったものです。今回の問題も、API処理サーバーのスケールアウトを行い、その直後はエラーが解消されたかに見えました。

しかし、翌週にも同様の問題が発生しました。ダッシュボードを見る限り、リソース利用状況は悪化しておらず、APIサーバーの処理サーバーには問題がないことが分かりました。このため、さらなる原因究明が必要となりました。

原因の確認

結論からいうと、前週に発生した問題と、翌週に発生した問題では原因が異なっていた(障害点が移動した)ために、原因究明が困難となっていました。前週に行ったスケールアウトは正しい対策でしたが、これにより後ろ側のコンポーネントに負荷が集中し、新たなボトルネックが発生していました。ただ、バックエンドのどこがボトルネックになっているかについての調査が難航しました。はじめは検索エンジンを疑い、スケールアウトを行いしたが、レイテンシの定期的な悪化は継続しました。そして、さらなる仮説検証を行うことで、最終的にはAPIサーバーとリバースプロキシ間のTCP接続およびパケットが溢れてしまったことが真の問題であることが判明しました。

対策

これに対する対策として、リバースプロキシのスケールアウトを行うことでトラブルは解消されました。そして、同様にトラブルを見過ごさないように監視項目が追加され、これらの指標がダッシュボードに追加されました。

ダッシュボードに全ての指標を掲載することは不可能です。よって、優先順位の高いものを選んで掲載します。しかし、ダッシュボードに掲載されていない指標に関連する障害が発生した場合、原因究明が困難となります。よって、ダッシュボードを適宜アップデートし、再発防止に努める必要があります。

*本項は以下のページ記載内容を引用、再構成したうえで解説を行っています。
スケールアウトの落とし穴から学ぶ、SREチームでのダッシュボードのアップデート術


SREに関するTips紹介

人類最初のSRE: マーガレット・ハミルトン

グーグルが自社の取り組みである「SRE」を解説した本である「SRE サイトリライアビリティエンジニアリング」では、人類最初のSREとしてマーガレット・ハミルソンについて記載されています。

1936年に生まれたマーガレット・ハミルトンは、ミシガン大学を卒業後に純粋数学を学んだ後に「気象学用のソフトウェア開発」のためにマサチューセッツ工科大学(MIT)で職を得ています。ここからハミルトンのソフトウェア開発が始まり、国防目的の研究所であるリンカーン研究所を経て、アメリカ航空宇宙局(NASA)の一員として人類の月面着陸プロジェクトである「アポロ計画」に携わるようになりました。

ハミルトンがなぜ「人類最初のSRE」と呼ばれるに至ったかは、「アポロ計画のミッションの失敗をソフトウェアのアプローチで回避した」ためです。

シミュレーター上で行うアポロのミッションシナリオを「予想外のキー」を押すことでクラッシュさせたハミルトンは、「宇宙飛行士が予想外の操作を行った際に備えて、エラーチェックのプログラムを追加すべき」と主張しました。しかし、「宇宙飛行士はそんな予想外の間違いをしない」と主張した上層部により、追加リクエストは却下されました。

リクエスト却下により、ハミルトンはプログラム追加を行えませんでしたが、代わりに、「宇宙飛行士が万が一、予想外の間違いをした場合のためのドキュメント」を更新しました。

ドキュメントが更新された4日後、実際に宇宙飛行士が予想外の操作を行ったことで、「航行データが消失し、宇宙飛行士が無事に帰還できない」危機に直面しました。しかし、ハミルトンがあらかじめドキュメントを更新しておいたため、宇宙飛行士はドキュメントに記載された手順で航行データを復元することができました。なお、これは現在では「フェイルセーフ」と呼ばれる、「故障や人為的なミスがあった場合でも、安全な状態に復帰する」仕組みです。

SREの価値とは、企業や組織のシステムに対して「問題が起こってから対処を考える」ではなく、「問題を予期して対策を取ることで、『問題を発生させない』『問題が発生しても、少ない被害で問題を収束させ安全な状態にする』」ことです。

ハミルトンはいち早く「起こるかもしれない問題を発見し、対策を提案」するだけでなく、「提案が却下されても、取りうる最善の策を講じる」ことでミッションと人命を救いました。SREを志すエンジニアは、こうしたハミルトンの姿勢から多くを学べるのではないでしょうか。

エラーバジェットとその考え方について

エラーバジェットとは、「サービスの可用性目標値を100%から引いた値」です。例えば、サービスの可用性目標値が99.99%であれば「100% – 99.99% = 0.01%」がエラーバジェットとなります。エラーバジェットの設定により生じる時間は、サービスの改善やさらなる信頼性向上のために利用できます。

ちなみに、エラーバジェットを設定する前提は「100%の可用性を設定することは間違っている」ということです。

例えば、「核攻撃から国民を防御する、人命に直結するシステム」であれば、多大なコストと労力を払っても100%を確保すべきです。しかし、これほどの可用性を求められるITサービスは、民間のITサービス運用ではほぼありません。よって、一般のITサービス運用に携わる組織は「100%を求められてもいないし、目指す必要もない」と理解することが出発点です。

「100%を目指すべきでない理由」は「効率性」です。

年間の可用性が「99.99%」と「100%」では、年間のダウンタイムが「52.6分 (99.99%)」か「ゼロ (100%)」かという違いがあります。年間1時間弱というわずかなダウンタイムを許容せずに100%を目指すと、「膨大なコストと労力がかかる割に、ユーザーは特にメリットを感じられない」という結果となるためです。

これに対し、年間99.99%の可用性目標を設定し、0.01%をエラーバジェットとした場合、可用性に対する考え方が大きく変わります。

エラーバジェット設定前は、「今年は99.99%の可用性だった。つまり1年のうち0.01%稼働できない時間があったので問題だ。運用チームはもっと頑張って100%を目指すべき」という考えに至ります。結果、運用チームは「コスト効率の悪い信頼性向上のアプローチ」にコストと労力を費やしてしまいます。

エラーバジェット設定後は、「今年は99.99%の可用性で目標を達成した。0.01%の時間は自由に使えるので、どう使うべきか」という発想となります。障害によるサービス停止ですら、「恐れる」ものから、「エラーバジェットの範囲内で管理するもの」となります。

平均故障時間 (MTTF) と、平均修復時間 (MTTR) について

平均故障時間 (MTTF: mean time to failure) とは、「前回の障害が復旧してから、次の障害が発生するまでの時間」を指します。「問題なく安定稼働していた時間の長さ」と言い換えてもよいでしょう。

そして、平均修復時間(MTTR: mean time to repair) とは、「新たに障害が発生してから、障害が復旧するまでの時間」です。

  • MTTFは「安定稼働している時間がどの程度の長さであったか」を示します。MTTFの数値は「長ければ長いほど安定稼働していてよい」です。
  • MTTRは「障害が発生してから復旧までに、どの程度の時間がかかったか」を示します。MTTRの数値は「短ければ短いほど障害復旧が早くてよい」です。

MTTFを長くするには、当たり前ですが「MTTRをできるだけ短くする」ことが大切です。MTTRを短くするには、大きく分けて3つの取組みが必要です。

1つめは、「障害発生時の手順をドキュメント化しておくこと」です。ドキュメント化していない場合、ドキュメント化されていた場合と比べてMTTRは3倍の長さとなります。

2つめは、「よくある障害を自動で復旧させること(その仕組みを作ること)」です。手作業での復旧と比べ、自動化された復旧ではMTTRが削減できます。

3つめは、「障害自体を発生させなくすること(発生しにくくすること)」です。障害が発生した後のポストモーテムの機会を活用し、障害が発生しないための運用の改善やアプリケーションの改善、その他の改善を行うことでMTTRを削減できます。

トイル (Toil) について

グーグルは、SREの考え方をまとめた本である「Site Reliability Engineering」にて、トイルについて、行っている作業が以下のうち1つでも当てはまれば、それはトイルと呼べる可能性は高いとしています。

  • 手作業であること
  • 繰り返させること
  • 自動化できること
  • 戦術的であること
  • 長期的な価値を持たないこと
  • サービスの成長に対して O (n) であること(正比例すること)

グーグルのSRE組織では、運用業務(トイル)を50%以下に抑えることが目標となっています。つまり、トイルが多ければ多いほど、この運用業務時間が長時間となり目標達成が難しくなるのです。そして、トイルの確認を怠ると、トイルが急速に増大して100%の時間を埋め尽くすリスクもあります。

トイルを全て無くして0%にすることは現実的ではありません。そして、SREが処理する量が少量であれば概ね問題はありません(なお、グーグルSREの運用業務割合は33%です)。

しかし、トイルが増大すると、「(SREチームメンバーの)キャリアの停滞」「士気の低下」「混乱の発生」「生産性の低下」といった問題が生じ、SRE組織での仕事に疑問を投げかける事態となりかねません。

よって、SREチームはエンジニアリングのアプローチにより常にトイルをなくしていくアプローチを継続する必要があります。

モニタリングの種類

SREにおけるモニタリングと、モニタリングに関する用語は定義づけられており、問題発生時に担当者が迷いなく必要なアクションを取られるように分類されています。

モニタリングに関する定義

  • モニタリング: システムに関するリアルタイムの定量データ収集、処理、集計、表示
  • ホワイトボックスモニタリング: システム内部で公開されているメトリクスに基づくモニタリング
  • ブラックボックスモニタリング: ユーザーが目にする挙動のテスト
  • ダッシュボード: サービスの主要メトリクスをサマリ表示するアプリケーション

3種類のモニタリング出力

  • アラート: 担当者が即座にアクションを取ることが求められる通知
  • チケット: 担当者が後ほどアクションを取ることが求められる通知(即座ではない)
  • ロギング: アクション不要の通知(ログ取得に関する通知)

リリースエンジニアリングとその哲学

SREにおけるリリースエンジニアリングとは、ソフトウェアをビルドし、リリースするプロセスの信頼性を高めるためのソフトウェアエンジニアリング手法です。定義されたポリシーや適切なツールと自動化が行われていれば、開発者やSREはソフトウェアのリリースを信頼できるで行うことができます。

グーグルでは、SREにおけるリリースエンジニアリングにおけるポイントを、以下の4点で整理しています。

  • セルフサービスモデル
    リリースエンジニアリングにより開発されたベストプラクティスやツールを用いることで、各開発チームの判断によりにリリースが行えるようになります。言い換えると、開発チームが望むタイミング、望む頻度でのリリースが可能です。
  • 高速性
    グーグルのリリースエンジニアリングにおいては、「ユーザーが利用できる機能をできる限り早くロールアウトするために、リリースを頻繁に行い、バージョン間の変更を少なくすること」が重要だという哲学が共有されています。リリースエンジニアリングは、短時間でのリリースを可能とする必要があります。
  • 密封ビルド
    「ビルドマシン上にインストールされているライブラリやその他のソフトウェアには影響されない」ようにするため、グーグルでは「密封ビルド」を用いています。別々のマシンでビルドを行っても、得られる結果が同じになるようにすべきです。
  • ポリシーと手順の強制
    リリースにおいて、意図しない変更が行われることを防ぐため、以下の処理は保護すべきとされています。
    – ソースコードの変更承認
    – リソースプロセス間に行われる各手順の指定
    – 新しいリソースの作成
    – 最初の結合ビルドの提案とチェリーピッキングの承認: チェリーピッキングとは「稼働中のソフトウェアのバグ修正などを目的として、オリジナルのビルドに変更を含めた修正版の再ビルドすること」を指します。
    – 新しいリリースのデプロイ
    – プロジェクトのビルド設定の変更

オンコール

オンコールとは、業務時間内または業務時間外に「即対応が必要な障害が発生した場合の通知、または通知を受けた後の対応(オンコール対応)」を指します。一般的には、24時間・365日の対応が求められるため、複数のチームメンバーによりシフト制でオンコールにあたっています。

本記事内の「SREにおけるモニタリングの種類」の中で、3種類のモニタリング出力について説明されていますが、ここでいう「アラート」がオンコール対応が必要な障害で、「チケット」「ロギング」はオンコール対応が必要ではありません

特に業務時間外のオンコール対応は、少人数で迅速な対応が求められます。グーグルでは、時間に対する要求が極めて厳しいシステムであれば5分、そうでなければ30分での復旧が一般的とされます。短時間で問題を解決するためには、どれほど経験豊富なエンジニアであっても、属人的に問題解決を行うのではなく、事前に準備されたドキュメントに従った対応が求められます。

なおSREでは、全労働時間に占める運用業務は50%以下にすることが規定されていますが、オンコール業務はこの運用業務時間に含まれます。オンコール業務が占める時間は最大でも25%以下とし、残った25%の時間は他の運用業務に費やすべきとされています。

トラブルシューティングの一般的な手法

トラブルシューティングに必要な2つの要素

SREかどうかに関わらず、サービス開発においてトラブルシューティングは欠かせないスキルです。「開発において多くの成功と失敗を繰り返してきた結果、適切なトラブルシューティングを実地で習得した」というエンジニアは多いですが、トラブルシューティングは学ぶことも教えることもできるものです。

トラブルシューティングを行う上で必要な2つの要素は以下のとおりです。

  • 一般的なトラブルシューティングの手法
  • 当該システムに対する深い知識

トラブルシューティングを行う上で、一般的な手法について精通しておくことはもちろん必要ですが、「問題が発生したから、トラブルシューティングの手法を1から試していく」のは効果的ではありません。当該システムが本来どのように動作しているかを理解した上で、トラブルシューティングを行うほうがはるかに効率的です。

トラブルシューティングの一般的なプロセス

上記を踏まえた上でトラブルシューティングの理論について解説します。

*画像引用元
Site Reliability Engineering – Chapter 12 – Effective Troubleshooting

上記画像はトラブルシューティングの一般的なプロセスです。

  • 問題のレポート (Problem Report): 問題の報告がトラブルシューティングの起点です
  • トリアージ (Triage): 問題の優先順位付けを行います
  • 観察 (Examine): ログなどをもとに問題を調査
  • 診断 (Diagnose): 問題がなぜ発生しているか、どうすれば解決できるかを判断
  • テスト/対処 (Test/Treat): 問題の解決を行うための手法をテストし、その後実効します
  • 回復 (Cure): 問題が解決済みとなりました

なお、テスト/対処の段階で状況が変化した場合は、再び「トリアージ」または「観察」からプロセスをやり直すことを検討します。

[意図的に障害を発生させる] 緊急対応を減らすためのSREアプローチ

プロダクトやサービスは必ず障害を引き起こすものです。壊れないものなどありません。SREの目的は「サービスの信頼性を向上させる」ことであるため、平均故障時間 (MTTF) の最大化と、平均修復時間 (MTTR) の最小化、そして平均故障間隔 (MTBF) の最大化に務めるべきです。

これらの数値を改善するためには、単に障害が起こるのを待って、それを迅速に解決し、再発防止策を施し、ドキュメント化を行うだけではありません。「意図的に障害を起こす」というアプローチもあります。

意図的に障害を発生させ、改善を行う

サービス担当者にとって最悪のケースは以下のようなものでしょう。

  • これまで安定稼働していたシステムが突然障害を起こした
  • 問題は全く未知で、どのように対処すればよいか検討がつかない
  • 長らく安定稼働していたため、チームメンバーも問題の対処に関する知見がない

サービスが安定稼働することは当然、望ましいことではありますが、安定稼働すればするほど、チームメンバーが「障害を解決する経験」「障害から学ぶ経験」「障害から改善につなげるアクションを行う経験」を積むことが困難になります。

グーグルではこうした事態を避けるために、SREが意図的にサービスに障害を発生させています。具体的には「100個の分散MySQLデータベースのうち、1個に対するアクセスを全てブロックする」というものです。

意図的に障害を発生させることで、システムの弱点を発見し、システム相互の依存関係を見つけ、その障害を観察すると同時に、信頼性を向上できるようなアプローチの適用や改善、そしてドキュメント化を行っています。

意図的な障害テストが「テスト」で済まない可能性を考慮する

上記の「100個のMySQLのうち1個のアクセスをブロック」の例ですが、これはグーグルで行った実際の例です。結果、多数のサービスが1時間弱停止するという障害を引き起こしました。問題があったとしても数分でロールバックできるはずが、大規模なロールバックがうまくいかなかったためです。

この例では、ロールバックが機能しなかった時点で、あらかじめテスト済みの別なアプローチを複数行い、並行して主要な開発者からの支援を得ました。結果、1時間弱で復旧できました。

意図的な障害を発生させるという「テスト」は、サービスの長期的な信頼性向上のために効果的なアプローチではありますが、十分に準備していなかった場合、大規模な障害を引き起こす可能性があります。ぜひ、この点は留意していただければと思います。

失敗例から学ぶインシデント管理

インシデント管理とは、「障害発生時に起こる問題を限定的なものとし、できるだけ早く通常運用に復帰させるアプローチ」を指します。以下では、インシデント管理の失敗例から学んでみましょう。

管理されていないインシデント例

  • オンコールエンジニアAは、「サービストラフィックのうち1つが、一つのデータセンターで処理できなくなった」障害通知を受けます。そして短時間で障害は拡大し、ついには過負荷からサービスが停止してしまいます。
  • ロールバックを行ったが機能しなかったため、オンコールエンジニアAは、他の同僚エンジニアBとC、ならび当該サービスを開発したエンジニアDを呼びます。B、C、Dはそろって調査に入ります。
  • 上層部はサービス停止に怒っており、技術担当重役であるEは過去の経験から「こうすればよい。早くアプローチを行え」と指示します。
  • Eの指示を断りきれず、Aは試行しますが、効果は全くありませんでした。
  • 困ったAは、別なエンジニアであるFを呼びました。Fは「こうしたアプローチが効果があるのではないか」とひらめき、独断で変更を適用しサービスを再起動しました
  • 結果、サービスは完全に停止してしまいました。

上記のようなインシデント管理の失敗例から学べることは、以下の3点です。

1.明文化された手順と役割の不在

理想的な問題解決は、オンコールエンジニアが問題解決できなかった時点で、「誰が何をどのように行うか」が明文化されたドキュメントに従い、インシデント対応を行うことです。しかし、上記ではドキュメントがないままオンコールエンジニアがバラバラに支援を要請しています。また、手順がないことから、問題解決の役割を直接的に負わない技術担当重役が口をはさむという事態も引き起こしています。

2.コミュニケーションの不在

オンコールエンジニアならび支援要請を受けたスタッフは、それぞれの所見を共有ならび、合意した上で判断することなく、バラバラに行動した結果、最終的に独断専行・システム停止を招いています。仮に明文化されたドキュメントがない場合でも、「関係するスタッフ全員が参加する会議」が設定され、共有や決定がされていれば、より効果的なアプローチが行えていたでしょう。

3.不適切なオンコールエンジニアの役割定義

オンコールエンジニアは「できるだけ独力で問題を解決する」ことよりも、「問題を短時間で解決するための環境を整える」ことのほうが重要です。独力での調査やログ確認は、結果、トラブルを深刻化させています。オンコールエンジニアの役割について、より問題解決志向で定義されていれば、対応の遅れと深刻化は避けられたかもしれません。

インシデントを管理するには

上記の失敗例を踏まえ、下では、インシデントを管理するための3つのポイントを紹介します。

1.役割分担

インシデントに関する役割を明確化し、各スタッフが自律的に動けるようにします。具体的には以下のような役割です。

  • インシデント責任者: インシデントに関する高レベルの状況を把握し、インシデントレスポンスチームを構成し、各人の責任を割り当てます。そして、他のスタッフに対して、どこにいけば(またはどのような方法で)インシデント責任者に連絡が取れるかを周知することも必要です。
  • 実行作業者: 問題調査やシステム修正など、具体的なインシデント対応を行います。実行作業者以外がインシデント対応の具体的なアクションを行うべきではありません。
  • コミュニケーション担当者: インシデントレスポンスチームのメンバーと、チーム外に関係者に適切なコミュニケーションをメールなどで取り続けます。場合によっては、インシデントに関するドキュメント管理を行う場合もあります。
  • 計画担当者: 実行チームを支援する役割です。バグの登録、夕食の発注、引き継ぎの調整などに加え、インシデント解決後にシステムを通常に戻すための記録の作成を行う場合もあります。

2.インシデントのドキュメントを最新の状況に保つ

インシデント責任者は、複数人で管理できるドキュメントツールを利用して、インシデントのドキュメントを常に更新し続ける必要があります。あらかじめインシデントドキュメントのテンプレートを作成しておき、最も重要な情報をドキュメントの先頭に持ってくるようにすべきです。

3.明確な引き継ぎ

インシデント責任者は、1日の勤務時間が終了したら、引き継ぎの責任者に状況の共有をお行い、引き継ぎの承認を得た上で、「いつ、誰にインシデント責任者権限を引き継いだ」かを、他のスタッフに宣言することが大切です。

まとめ

SREの役割はサービスの信頼性向上です。インシデント管理を適切に行うことは、平均修復時間 (MTTR) の最小化につながり、サービスの安定稼働に直結します。SREに関心がある組織にお役に立てれば幸いです。

ポストモーテムの確立

ポストモーテムの目的は、「根本原因の共有」「再発防止のためのアクション策定」です。しかし、ポストモーテムが機能するためには、組織において「正しいポストモーテム」が確立されている必要があります。

1.ポストモーテムを作成する条件をあらかじめ定義する

「ポストモーテムを作成すること自体が、批判や非難の対象となる」場合は、「できるだけ批判や非難を避けるために、『ポストモーテムを避ける』という事態」が起こりかねません。どのような状況の場合にポストモーテムが必要かについては、あらかじめ明確に定義しておき、無用な議論を避ける必要があります。

2.批判や非難を行わず、建設的であり続ける

ポストモーテムが批判や非難の場であってはいけません。何十年とポストモーテムを行っている業界に「航空業界」や「ヘルスケア業界」があります。いずれも、問題が人命に直結する業界であるため、「ミスがあっても、それを批判・非難せず、強化する機会とみなす」という文化が確立されています。ポストモーテムを作成するのであれば、人命に直結しているか否かは別に、建設的であり続ける必要があります。

3.ポストモーテムをレビューし共有する

ポストモーテムを作成するチームは、正しいステップに従って作成・共有を行うべきです。

チームはまず必要な情報を入手し、関係者からオープンにコメントを収集します。また、本件に関してフィードバックをくれる協力者に正式に依頼します。

次に、作成したポストモーテムをチーム内で、また上長からのレビューを行います。「データ収集」「インパクト分析」「根本原因」「アクションプラン」といった観点でレビューを受けた後に、ポストモーテムを広範囲に公開します。

4.ポストモーテム文化の確立

非難のないポストモーテム「文化」を確立するには、以下のような活動が効果的です。

(1)メールでの情報発信

月刊のニュースレターで、興味深いポストモーテムを共有します。

(2)ポストモーテムグループでの情報共有

社内ポータルや情報共有ツールを用いて、ポストモーテムに興味があるエンジニアが参加できる場を作り運営します。

(3)読書会

過去のポストモーテムを取り上げ、参加者で読み合わせながら「当時実際に参加したエンジニア」と「参加していないエンジニア」が対話することで、理解を深めます。

(4)不運の輪 (Wheel of Misfortune: 新人SRE向けトレーニング)

新人SREのトレーニング目的で、他のエンジニアの協力を得て、過去に作成されたポストモーテムを「リアルに再現」し、育成の場とします

信頼性を高めるためのソフトウェアテストの種類

SREの観点から実施するソフトウェアテストの目的は、信頼性を向上させることです。これは、平均修復時間 (MTTF) を最小化し、平均故障間隔 (MTBF)* を最大化するとも言い換えられ、信頼性を測定する指標となります。

*MTBF: mean time between failure, 前回に障害が発生してから新たに障害が発生するまでの期間。長ければ長いほどよい。

以下では、ソフトウェアテストについて解説します。

ソフトウェアテストの種類: 一般的なテスト

過去から用いられる一般的なソフトウェアテストは、以下のようなものです。

*画像引用元
Site Reliability Engineering – Chapter 17 – Testing for Reliability

(1)ユニットテスト
分割可能なユニット(クラスや関数など)ごとのテストです。関数や挙動が正確に実行されることを確認します。

(2)結合テスト (Integration Test)
個々のユニットテストをパスしたソフトウェアコンポーネントは、より大きなコンポーネントに組み込まれます。この大きなコンポーネント単位でのテストが結合テストです。

(3)システムテスト
システムに含まれる全てのコンポーネントをテストする最大級のテストがシステムテストです。システムテストには複数のバリエーションがあります。

[A] スモークテスト
単純ながら重要な挙動を確認するためのテストで、追加テストを省くために行われます。

[B] パフォーマンステスト
スモークテスト後に実施します。システムのパフォーマンスが許容範囲内に収まることを保証するためのテストです。

[C] 回帰テスト
システム全体の一部分を修正した後に、修正箇所が他に悪影響を及ぼしていないかを確認するテストです。回帰テストの内容を記録しておくことで、今後のシステム修正時に「過去と同じ不適切な修正」を行ってしまうことを防げます。

ソフトウェアテストの種類: プロダクションテスト

(1)設定テスト
Webサービスの設定が正しく行われることを確認するためのテストです。記録されるファイルを確認し、特定のバイナリが実際にどのように設定されているかを確認し、テスト対象の設定ファイルにどのような差異があるかを確認します。

(2)ストレステスト
システムが「どのしきい値で過負荷になるか」を確認するためのテストです。多くのシステムでは、負荷の上昇により「徐々に性能が低下する」のではなく、「しきい値を超えたとたん、一気に致命的な障害が発生する」ため、ストレステストにより限界を認識することが重要です。

(3)カナリアテスト
例えば、利用しているサーバーに新バージョンが出た場合、「一部のサーバーのみ新しいバージョンに差し替えて、問題が発生するかどうかを確認する」ためのテストです。もし問題がなければ残りのサーバーも新バージョンへ移行、問題があれば新バージョンの一部のサーバーのバージョンを戻すことで問題を収束させます。

グーグルのポストモーテムから学ぶ「Google Music楽曲欠落」

Google Music(またはGoogle Play Music)は、グーグルが以前提供していた音楽ストリーミングサービスです(現在はYouTube Musicに統合)。2012年に、グーグルのSREチームが実際に対処した問題について解説します。

「楽曲がスキップされる」という報告から「削除の暴走」を確認

「これまで再生できていた楽曲が、スキップされて再生できない」というユーザーからの報告にうけて、Google Musicのユーザーサポートチームは問題の調査にあたっていました。

そして再生できなかった楽曲のメタデータが、本来の参照先(楽曲のファイル)を参照できなくなっているという事態を確認しました。その結果、プライバシー保護のためのデータ削除パイプラインが暴走し、大量の楽曲を自動的に削除していることが判明しました。

想定外の問題を確認したエンジニアは、即座にアラームを鳴らして、サポートケースの優先度を最大限に高めて、エンジニアリングチームとSREチームに問題を報告しました。

問題を解決するために行ったステップ

バグの特定とリカバリの並行処理

「問題を根本から早急に修復することが必要」と判断したエンジニアリングチームとSREは、チームを2つに分けて対処を介しました。1つめのチームは「楽曲のリカバリ」に当たり、2つめのチームは「データ損失のバグを根本からの改修」に当たりました。

幸いなことに、障害発生の1週間前にディザスタリカバリテストの演習が行われており、新しいツールを利用する準備が整っていました。リカバリチームは、新しいツールを利用して60万にも及ぶ楽曲をマッピングし直す作業を開始しました。

削除された60万の楽曲のうち、テープバックアップに保存されていたものは43万強で、17万弱の楽曲は消失していることが判明しました。しかし、テープバックアップのリカバリプロセスにより、17万弱の楽曲をリカバリする方法を見つけました。

その間、根本原因を究明するチームは様々な仮説検証を行いましたが、原因究明には至りませんでした。

リカバリ第一波

オフサイトでバックアップされたテープ (43万強の楽曲)から、1.5ペタバイトのデータを取り出し、そのテープからデータを取り出す作業が開始されました。データ量ならび楽曲数が多量であったため、テープバックアップシステムからのリストアを要求することだけでも、SRE的なアプローチが必要となりました。

チームの驚異的な活躍の結果、43万曲の楽曲は約2日間で99.95%の楽曲のリストア操作が完了するという結果となり、残りの楽曲のテープ回収も進行中で、ほぼ処理が完了している状態となりました。実際にユーザーが楽曲にアクセスするまでには追加で5日かかっていますが、ソフトウェアの処理的には2日で復旧を完了する結果となっています。

リカバリ第二波

テープバックアップ前に削除された17万弱の楽曲については、Googleストアで購入されたものがほとんどで、ストアのオリジナルの楽曲には影響はありませんでした。よって、比較的短期間で復旧が完了しています。残ったわずかな楽曲は「ユーザーが自身でアップロードした楽曲」で、こちらについてはユーザーに再アップロードを依頼し、リカバリ処理を終えました。

根本原因の追求

最終的に、Google Musicのチームは「データ削除パイプライン」の欠陥を特定しました。当初、エラーに備えた強調機能と大きなデータのマージンが有効に動作していましたが、サービスの成長に伴いパフォーマンスの最適化が行われ、結果、データが複数自動でバックアップされる処理が競合状態を定期的に発生させ、結果、意図しない削除が行われていました。

後にデータ削除パイプラインは再設計され、競合状態が発生されないように改善が加えられました。加えて、大規模な削除バグを検出できるようにモニタリングとアラートの再設定が行われています。

グーグルのポストモーテムから学ぶ「GTapeからのリストア」

グーグルには、GTapeというテープバックアップのシステムがあります。以下は、Gmailのデータをリストアするために、GTapeを用いた例となります。

Gmailのユーザーデータ消失


2011年2月、Gmailから大量のユーザーデータが消失していることが判明し、緊急の電話会議が設定されました。Gmailには多くの保護機構、内部チェックならび冗長性があるにも関わらず、データの消失が確認されました。とはいえ、こうした事態は何度もシミュレーションされていたため、何を行うべきかは明らかにされていました。

  • リストアにかかる時間をアカウントごとに算出し通知すること
  • (初期推定値である)数時間以内に全アカウントをリストアすること
  • (推定されていた完了時間内に)99%以上のデータを回復

データ消失の原因は、Gmaiの内部的な冗長性やバックアップのサブシステムの障害であることが判明しました。この障害は内部的にリカバリできる範囲を超えていたため、大きな障害となりました。

この大規模なデータ消失事故は、結果として30時間で復旧されました。事前のシミュレーションに加え、グーグル社内の多くのチームが支援に参加したことも、短時間で障害を復旧できた原因となりました。

まとめ

サービスの信頼性を高めるために、「最悪の事態に備えておく」ことはSREとして極めて重要な姿勢です。上記のGmailのデータ消失からは、常に最悪を想定し、必要な備えを「机上の計画」としてだけでなく「実地のシミュレーション・訓練」として行っておく重要性を伝えてくれます。

新人SREの教育に関する8つの指針

新人SREを雇用した後に行うことは何でしょうか。技術的なオリエンテーションに加えて、どのような教育を行うべきかの8つの指針についてお伝えします。

SRE新人教育の8つの指針

  • 具体的で順序立てられた学習体験を設計する
  • リバースエンジニアリング、統計的な志向、基本原則に基づく作業
  • ポストモーテルを読み、障害の分析を推奨する
  • リアルな障害を人工的に発生させ、本物のモニタリングやツールを用いて修復させる
  • 障害のロールプレイングをグループで行う(不運の輪)
  • オンコールローテーションにシャドウとして参加し、自分のノートをメインのオンコール担当のノートと比較する
  • エキスパートのSREとペアを組み、オンコールトレーニング計画の目的セッションを見直す
  • 単純ではないプロジェクト作業を切り出して渡し、サービススタック中の一部を受け持つ機会を与える

新人SREを「下働き」させるのでは成長しない

新人SREは将来的には、エキスパートのSREに成長し、SRE組織をリードすることが期待されています。よって、「シニアなSREの下働きをさせ、突然本番のオンコール担当をさせる」「ポストモーテムを隠す」といった育成は望ましくありません。

*画像引用元
Site Reliability Engineering – Chapter 28 – Accelerating SREs to On-Call and Beyond
https://sre.google/sre-book/accelerating-sre-on-call/

上記の表を参考に、綿密な学習計画を立てて「新人SREメンバーの立ち上げ」を支援しましょう。

データの完全性を考えるヒント(データアクセス)

サービスを運用する上で、データの完全性を考えるにあたり重要な点は、「データが正しく保管されている」ではなく、「サービス上のデータにユーザーが利用可能であり続ける」ことです。

ユーザーは「データが正しく保管されているがアクセスできない」と、「データが破損して消失した」を明確に区別しません。使いたい時に使えなかった、そしてそのダウンタイムが長く続くことは、データ破損と消失と同様の悪いインパクトをユーザーに与えます。

また、アクセスできない期間の長さも重要です。

2011年にグーグルは、一部のユーザーがGmailにアクセスできないという障害を起こしました。この時は最長で4日間もGmailにアクセスできないユーザーが発生しました。メールを日々利用するユーザーからすると、4日間は「あまりに長い」、それどころか、24時間アクセスできなかったとしても「あまりに長い」と判断されました。

Gmailだけでなく、Google Photo、Google Drive、Cloud Storage、Cloud Datastoreなども同様です。いずれも「グーグルのサービス」であり、いずれかが障害を起こすことでグーグルのブランドイメージ全体を毀損しかねません(競合製品への乗り換えも起こります)。

サービスの開発、またはSREとして信頼性向上に努める際は、「ダウンタイムの長さがどの程度以上になると『あまりに長い』と判断されるか」を考慮した上で、適切な信頼性を担保すべきでしょう。

DevOpsとSREの違い

SREのキャリアを目指す方の多くが、DevOpsとSREの違いについて戸惑うようです。詳細は、当サイトに掲載している「SREとDevOpsの違いはなにか」をご覧いただければと思いますが、以下ではそのエッセンスだけお伝えします。

「SREはDevOpsというインターフェイスの実装である」

違いについて端的に解説すると、「DevOpsは思想であり、それを具現化させたのがSREである」といえます。まず、DevOpsについてですが、以下の5ポイントでカバーされます。

  • 組織のサイロの削減(風通しのよい組織の実現)
  • エラー発生を前提とする(100%を目指さない)
  • 段階的に変更を行う(一気にすべてを変更しない)
  • ツールと自動化を活用する(サービス成長と正比例で運用工数を増やさない)
  • 全てを計測する(モニタリングに基づく数値設定が重要)

ただ、上記はあくまで思想、概念でしかなく、具体的な方法論ではありません。これを具体的にどのように行うかを「トイルの削減・自動化」「SLI/SLOの設定による目標定量化」といった形で、誰でも用いられるように体系化させたものがSREといえます。

変更管理とその重要性

グーグルでは、サービス障害の70%は「稼働中のシステムに対して変更を行った際に発生している」ことを明らかにしました。つまり、変更管理を正しく行うことでサービス障害を未然に防ぐことができたり、万が一障害が発生しても短時間で収束できることを意味します。

では、具体的に何を実現すべきか、ですが、以下の3点とされています。

(1)漸進的なロールアウトの実装

これは、「変更を行う際に、一度にすべてのユーザーに対して変更を適用せずに、少しずつ変更適用を行い、その反応を見ながら適用範囲を拡大する」ことを意味します。万が一問題が発生しても影響範囲は限定的になり、対処も容易となります。

(2)高速かつ正確な問題の検出

これは、トラブルシューティングを適切に行うことを意味し、具体的には直感や経験に頼らずに、理性とデータに基づいた問題への対処を意味します。

(3)安全なロールバック

問題が発生した際に、一つ前のバージョンに安全にロールバックできる仕組みを構築すべきという内容です。

上記3点を正しく行うことで、問題発生範囲の最小化、理性的な問題解決、ユーザーへの影響の最小化が実現されます。

キャパシティプランニング

グーグルでは、SREの責任範囲にキャパシティプランニングを含めています。キャパシティプランニングにおいては、サービスの成長に対して必要な可用性を提供できるキャパシティと冗長性を確保することが重要です。しかし、キャパシティプランニングが正しく行われないケースが多いのもまた実情です。

以下は、適切なキャパシティプランニングを行うための基礎となります。

(1)自然な需要増加の正確な予測

現在のサービス利用状況の増加率のみでなく、サービス開発やマーケティング計画といった複数の観点から予測を作成する必要があるといえます。

(2)突発的な需要増加の発生源を予測に含める

過去に同様のサービスを提供した際の経験を活かし、突発的なニーズの高まりが起こる発生源と、どの程度の伸びが起こり得るかを予測します。

(3)ハードウェアリソースとサービスリソースのキャパシティの関連を把握するため定期的なテスト実施

リソースを正しく把握できていなければ、正しい予測を行っても無意味です。定期的にテストを行い、そのデータを予測にフィードバックします。

プロビジョニング

プロビジョニングは、「需要予測とキャパシティプランニングの結果に従い、キャパシティを確保する」ことです。つまり、プロビジョニングを実施した時点で費用が発生します。小規模のサービスであれば、プロビジョニングの費用はさほど高額ではありませんが、大規模のサービスとなれば、プロビジョニング一回で巨額の費用が動きます。

また、プロビジョニングは正確に行わなければ、確保したキャパシティが正しく利用可能となりません。サービス側に変更を行い、確保したキャパシティが正しく機能するかどうかのテストも必要です。

このため、プロビジョニングの実施は「素早く」「必要なタイミング」でのみ実施すべきとされます。

リソースの効率的な活用

ビジネスとしてサービスを成立させるためには、リソースの効率的な活用を必ず考慮する必要があります(SREの多くもこの点に関わる活動を行います)。

リソースの利用は、「需要(負荷)」「キャパシティ」「ソフトウェアの効率性」を関数で表されます。

  • 需要が増加すると、ソフトウェアの速度が低下します。
  • ソフトウェアの速度低下は、キャパシティ不足に起因します。
  • キャパシティが極端に不足すると、ソフトウェアは反応を返さなくなります。
  • キャパシティを追加すると、ソフトウェアの速度が加速され、より多い需要を満たすことができます(しかり多額に費用もかかります)。

これが一般的なリソース不足に対するキャパシティ追加ですが、SREは「ソフトウェアを改修する(コーディングする)」ことで、ソフトウェアの効率性を高めるというアプローチを行えます。これにより、従来であればキャパシティ不足が発生した状況であっても、効率性が高まったソフトウェアにより、速度が低下せずに動作させられる場合があります。

常にモニタリングを怠らず、そしてリソース不足に対してキャパシティを追加するだけでなく、SREがソフトウェア自体に手を入れることで、コストを押さえたリソースの効率的な活用が実現します。

サービスのリスク許容度(コンシューマーサービス)

SREでは、100%の可用性を目指していません。このため、「どの程度の可用性を目指すべきか」を各サービスごとに判断する必要があります。また、「障害発生時のリスクをどの程度許容できるか」についても判断が必要です。

以下では、コンシューマーサービス(個人ユーザーが利用するサービス)におけるサービスのリスク許容度について解説します。

可用性

  • どの程度の可用性を提供するかは、以下から判断できます。
  • ユーザーが期待するサービスレベルサービスが売上を生んでいるか
  • サービスは無料か、有料か
  • 競合のサービスレベルはどの程度か
  • コンシューマ向けか、企業向けか

グーグルのサービスを例に説明すると、Google Workspace (旧称 G Suite)は企業向けの有料サービスであることから、対外的には99.9%に設定すると同時に、内部的にはより高い可用性を目標としていました。その理由は、99.9%がSLAであり、これを下回ると返金が必要となるためです。

Youtubeは、個人向けの無料サービス(現在は有料プランもあり)です。2006年の買収当時はまだ急速な成長フェーズにいたこと、また当時は有料プランがなかったこともあり、安定稼働よりも機能追加を重視し、かなり低い可用性目標が設定されていました。

障害

障害をいくつかのカテゴリに分類する、以下となります。

  • 一時的なアクセス障害
  • 完全なデータ消失、データの漏えい

結論からいうと、一時的なアクセス障害はSLOのエラーバジェットの範囲内に収まっている限りは問題はないが、完全なデータ消失やデータ漏えいはサービスの信頼性を大きく損ねる事態となります。

このため、データ消失やデータ漏えいを防ぐためには、システムを全て停止させる(=一時的なアクセス障害が発生する)という判断も必要となります。

コスト

コストを考える上で重要な視点は以下の2点です。

  • 1ケタ高い可用性を実現した場合、収入はどう変化するか
  • 収入増加は、それを実現するために費やしたコストと見合うか

信頼性は高まったが。それにより収入が増える見込みがない場合は、可用性を高めることはコスト的に見合わないといえます。

エラーバジェットの活用

SREが提唱する概念で最も有名なものの1つが、エラーバジェットです。「開発チームはサービスの開発速度で評価される」「SREはサービスの信頼性で評価される」という異なる評価軸を持つチームが、エラーバジェットをどう活用すればよいか解説します。

エラーバジェットをリリースの指標とする

開発チームとSREの間で、エラーバジェットについて合意ができた場合、開発チームはエラーバジェットの範囲内でリリースを行うことになります。そして、エラーバジェットを使い切りそうになる(例: 想定外の障害が頻発する)場合は、リリースを一時的に停止し、パフォーマンス改善やシステムテストなどにリソースを投下します。なお、サービス開発側の責任でない障害(例: ネットワークやデータセンター障害)の場合でも、エラーバジェットは消費されます。

エラーバジェットを緩めることも選択肢のひとつ

ただ、上記が全てのケースでうまく機能するわけではありません。本ページでも紹介した「dely株式会社(クラシル運営元)」は、サービスの迅速な開発とリリースを重視してエラーバジェットを採用していません。

厳しい競争環境があり、可用性向上よりも迅速な機能追加が求められる場合、エラーバジェットも採用しつつ、迅速な開発とリリースを両立させたい場合は、「エラーバジェットを緩める (SLOを下げる)」ことも選択肢となります。

Google Chubbyから学ぶ意図的なSLOの引き下げ

Google Chubbyは、疎結合の分散システム向けの(ファイル)ロックサービスです。グローバルなサービス運用のために、Chubbyインスタンスを、レプリカが異なる地理的リージョンに分散配置しています。

しかし、Chubbyインスタンスが障害を発生させ、ユーザーに影響が出ていることが判明しました。障害頻度は高くありませんでしたが、それが故に「Chubbyの信頼性は高い」と判断したエンジニアが、Chubby依存のサービスを多数開発した結果、ChubbyがダウンするとChubbyに依存するサービスが立ち上がらない問題が多数生じていました。

これに対してSREチームが行った対策は、「ChubbyはSLOを満たすが、SLOを大幅に超えない(可用性を高めすぎない)」という運用を行いました。Chubbyの信頼性が高すぎなければ、Chubbyに完全に依存するサービスが開発せず、Chubby停止を考慮に入れた設計を行わざるを得ないためです。

一般的には、「Chubbyの可用性をほぼ100%に高める」というアプローチが取られそうなものですが、「Chubbyに依存しすぎて、サービス停止になる設計が悪い」ということで、あえて信頼性を下げるアプローチは、非常に興味深いものがあります。

正しいSLAの理解

SLAとは、「サービス事業者とサービス利用者間で行われる、金銭的な補償を伴うサービスレベルの合意」です。例えば、可用性SLAが99.99%の場合、実際の可用性がこれを下回る場合、サービス事業者はサービス利用者に対して違約金を支払わねばありません。

なお、SLOは「社内的な目標値で、その値を満たさなかったとしても、金銭的な支払いは発生しない」点が最大の違いです。

では、どのサービスにSLAを設定し、どののサービスにSLAを設定しないかですが、これは「グーグル検索」と「Google Workspace (旧称 G Suite)」で説明できます。

グーグル検索はSLAが設定されていません。グーグル検索は無料のサービスであり、利用者は費用支払いが不要です。その代わりに、検索連動型広告の出稿者が「広告料」という名の費用を支払っています。検索連動型広告はクリックごとの課金なので、例えば「ある時間帯に広告が表示さなかった」としても、グーグルは広告主に対して違約金を支払う根拠がないのです。

しかし、SLAがないからといって内部的な運用目標値がないわけではありません。内部的にはSLOが設けられ、その目標を満たすべくSREが行われています。

逆に、Google WorkspaceではSLAが設定されています。Google Workspaceは利用者がその利用費用を支払うサービスであり、例えば「今週まるまる1週間サービスを利用できなかった」という場合は、業務に大幅な支障をきたします。このため、グーグルは利用者または見込客に対して「Google Workspaceを安定的に運用させます」というコミットが必要となります。その、コミットの証がSLAです。

なお、Google WorkspaceのようなSLAが設定されているサービスでは、「適切なレベルのSLA設定が必要」です。ユーザーに失望されるほど低すぎてもいけませんし、すぐに違約金が発生するほど高くてもいけません。サービスを多く利用してもらい、十分な利益を生むためには、SLA設定は慎重に行う必要があります。

SLI定義の標準化

サービスごとに「SLIの定義を何にするか」をバラバラに考えていては、各サービス間でSLIを比較することが難しくなるだけでなく、測定の設定などに都度工数がかかります。よって、標準的なSLIの定義はテンプレート化しておくべきです。以下はその例です。

  • 集計のインターバル「集計期間は1分とする」
  • 集計の対象領域「クラスタ内の全てのタスク」
  • 計測の頻度「10秒ごと」
  • 対象となるリクエスト「ブラックボックモニタリングジョブからのHTTP GET」
  • データの取得方法「モニタリングシステムを通じてサーバーで計測」
  • データアクセスのレイテンシ「最後のバイトまでの時間」

上記はあくまで例ですが、自社の複数のサービスでSLIを定義する際は、できるだけ標準テンプレート化された定義を用いて、定義の設定に工数をかけすぎないように注意してください。

SLOの正しい定義

SLIの定義で重要なのは「望ましい目標から特定の指標にさかのぼる」ことです。

この逆の「特定の指標から望ましい目標を設定する」場合は、単純に測定しやすい指標が設定されることが多く、ユーザーの期待するものに近づかない可能性があるためです。

次に、SLOの明確な定義についてですが、「計測方法と、計測値が適正である条件を指定する」ことが重要となります。以下例となります。

  • Get RPCの呼び出しの99%(1分間での平均)が100ミリ秒以下で完了すること(計測の対象は全てのバックエンドサーバー)
  • スループットタイプのクライアントのSet RPC呼び出しの95%が、1秒以下で完了すること。
  • レイテンシタイプのクライアントの、1KB以下のペイロードを持つSet RPC呼び出しの99%が、10ミリ秒以下で完了すること。

上記を参考に、解釈を間違えることがない明確な定義づくりを行ってください。