SREの要点：サイト信頼性エンジニアリングに期待すべきこと

サイト信頼性エンジニアリング（SRE）とは、ソフトウェアエンジニアリングのツールと原則をIT運用に組み込む慣行です。SREは、信頼性、回復力、効率性、拡張性に優れたインフラとサービスを構築・保守し、スケーラブルなシステムの信頼性を向上させます。設計段階から回復力を備えたシステムを構築し、ソフトウェアと自動化を活用して、拡大し続けるインフラを管理します。これは、手動で管理するよりもはるかに持続可能な方法です。

サイト信頼性エンジニアは、IT運用の管理と自動化を担当する人々で、ソフトウェアエンジニアリングの専門知識により、システムの耐障害性と可用性を維持し、あらゆる問題を自動的に修復します。新しいアプリケーションの配信と導入を監督し、潜在的な停止や中断を防ぐ役割です。

Googleエンジニアリング担当バイスプレジデントのBenjamin Treynor Sloss氏は、2003年に「サイト信頼性エンジニアリング」という用語を初めて作り出し、「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼することで実現するものである」と述べました。そして、同氏はまさにこれを実行しました。¹

Googleに新入社員として参画した同氏は、急速に拡大する事業と大規模で分散したインフラを管理するためのエンジニアリングソリューションを見つけるという任務を負いました。同社のインフラの成長速度では、新しいサービスを手動で管理するために必要な数のエンジニアを雇いながら、同じペースでイノベーションを起こすことは不可能です。代わりに、Treynor氏のチームはイノベーションとシステムの信頼性のバランスを取り、継続的な学習と改善の文化を育みました。

やがて、Googleの成長を続けるSREチームは、安定性と信頼性を維持しながら、新しい機能を本番環境にプッシュすることに注力するようになりました。数年のうちに、さらに多くの企業がGoogleと同じ問題に直面し、サービスの可用性と信頼性を維持しながら大規模な分散インフラを管理することを迫られました。まもなく、サイト信頼性エンジニアリングの慣行はGoogle以外にも広がり、現代のIT運用の鍵となりました。

今日のデジタルファーストの世界では、あらゆる規模の企業が、可用性が高く、スケーラブルで、回復力のあるシステムに依存するようになっています。ウェブサイトやモバイルアプリが1度停止しただけでも、経済的損失、顧客体験の悪化、運用上の非効率性を引き起こす可能性があります。そのため、SREはどの企業においても重要な役割を果たしています。

SREを活用することで、競合他社に遅れずについていくことが容易になります。可用性の問題を数日ではなく数分で解決し、ユーザー数に関係なくページの読み込み時間を短縮できます。

大企業の場合、SREは異なるスケールで同じタスクを実行します。事前監視とインシデント管理により、信頼性を自動化し、パフォーマンスを最適化し、システム障害を防ぎます。SREは開発チームと運用チーム間の連携を促進することで、信頼性が高く効率的なシステムを構築します。

サイト信頼性エンジニアリングの核となるのは、ソフトウェア開発アプローチを使用して本番環境の運用上の問題を処理することです。その他の基本原則には、リスクの受け入れ、自動化の使用、サービスレベル目標（SLO） とサービスレベル指標（SLI）の設定が含まれます。

SREは、完璧に機能するシステムは存在しないことを認識しています。イノベーションのプロセスの一環として、障害や停止が発生することが予期されます。SREは、失敗を回避するのではなく、許容可能なリスクレベルを理解することに重点を置きます。

リスクを受け入れるとは、信頼性の向上、新しいコードのデプロイ、ユーザーへの潜在的な影響の管理の間の転換点を見つけることです。サービスの信頼性を向上させるためにかかる時間、エネルギー、またはその他のリソースは、許容できるリスクですが、それ以外は過剰です。ただ、果たしてどの程度のリスクが許容され、プロセスのどの時点でユーザーエクスペリエンスが低下し始めるのでしょうか。

このSREの基本原則は、次の4つの要素に基づいています。

1. ユーザーにとって許容可能な信頼性レベル（SLOとSLIの設定によって決定）

2. 信頼性向上のコスト（自動化とツールを含む）

3. 改善しないリスク

4. コスト対リスクの比較（エラーバジェットを通じて確認）

多くの場合、リスクを受け入れるための鍵は文化的な視点です。SREは懲罰的な文化にとらわれない組織文化の中で活動します。失敗から学び、予防策を講じることで、システムの信頼性とアプリケーションのパフォーマンスを継続的に向上させます。

エラーバジェット
エラーバジェットは、リスクを理解し管理するための明確な指標です。これは、サービスが一定時間内に経験できるダウンタイム（またはエラー数）の量です。

許容されるシステムの信頼性の低さ（エラーバジェットとも）を定義することは、革新と信頼性のバランスを取るのに役立ちます。エンジニアは、デプロイの高速化や新機能のリリースなどのリスクを冒すことが奨励されていますが、それはエラーバジェットがあるためです。このしきい値に達すると、エンジニアはシステムを安定させ、信頼性を向上させます。

SREチームは、SLOに基づいて許容されるエラー（またはダウンタイム）のレベルを決定し、エラーバジェットを計算します。言い換えれば、SLOで許容されるエラーの範囲です。

サービスレベル目標（SLO）とは、一定期間におけるパフォーマンスの目標値です。設計上、エンジニアリングチームとビジネス関係者の両方がこれらの目標を理解し、意思決定の指針となる明確な期待値を設定する必要があります。

サービスレベルインジケーター（SLI）は、サービスのパフォーマンスを測定します。通常、SLIは、サービスのレイテンシ、可用性、スループット、エラー率などのユーザーの優先順位を表します。

SLOもSLIも静的ではなく、時間とともに進化するため、定期的な見直しと改善が必要です。

最後に、自動化です。SRE は、手動の反復的なタスクを自動化に置き換えることを目指しています。労力を削減することは、システムの信頼性を向上させ、より迅速かつ効率的に革新することを意味します。

一部のSREチームは、デプロイ、インシデント対応、テストのための自動化ツールの開発に最大で半分の時間を費やしています。高度な自動化機能により、サービスの信頼性と最適なパフォーマンスを確保しながら、経時的にスケーリングコストを削減することができます。

システム監視とオブザーバビリティは、SREにとって重要であり、サービスが稼働しているか、どの程度稼働しているか、問題の所在など、真の可視性を提供します。

監視は、サイト信頼性エンジニアが問題を迅速に検出し、対処するのに役立ちます。オブザーバビリティは、システムパフォーマンスに関するリアルタイムおよび履歴の洞察を提供し、未知の問題に対処します。トレース、ログ、メトリクスは主要なオブザーバビリティシグナルです。

サイト信頼性エンジニアリングの4つのゴールデンシグナルは、レイテンシー、トラフィック、エラー、飽和度です。これらのメトリクスは、分散システムにおけるサービスの健全性とパフォーマンスであるアプリケーションの信頼性の基礎となります。

• レイテンシーとは、システムがリクエストに応答（成功またはエラー）するのにかかる時間です。高レイテンシーは、SREが早急に対応する必要があるパフォーマンスの問題を示しています。

• トラフィックはシステムの需要を測定します。システムによっては、1秒あたりのトランザクション数や1秒あたりのHTTPリクエスト数を指します。SREはトラフィックを使用して、ユーザーエクスペリエンスが低下しているかどうかを判断します。

• エラーは失敗したリクエストの割合です。エラーは、明示的に（HTTP 500など）、暗黙的に（HTTP 200でコンテンツエラーがある場合など）、またはポリシーによって（失敗までに1秒以上かかるリクエストなど）発生します。システムに応じて、SREは特定の種類のエラーを他のエラーよりも優先させ、繰り返し発生する問題に対処することができます。

• 飽和度はシステム全体の容量、またはサービスがどれほど「満杯」であるかを示します。最も制約されているリソースやシステムが処理できる残りの負荷に応じて、さまざまな方法で測定できます。

この4つのゴールデンシグナルにより、SREはキャパシティプランニング、長期的なシステムの信頼性向上、インシデントへの対応と管理、問題の根本原因の発見に集中できます。

それでも、4つのゴールデンシグナルだけでは複雑な分散システムを完全に信頼できるものにすることはできません。そこで登場するのが、すべてのパフォーマンス数値をコンテキストに沿って解釈する分散トレーシングです。

先ほども述べたように、SREに関しては、インシデントや停止は避けられません。しかし、どのようなインシデントにも対応が必要なことに変わりありません。効果的なインシデントレスポンス計画には、トリアージ手順、明確なコミュニケーションプロトコル、エスカレーションパスが含まれます。

おそらく、事後検証も同様に重要です。事後検証は建設的な慣行であり、責任転嫁の機会ではなく、学びの機会となります。SREは各インシデントを追跡し、その根本原因を発見し、開発チームと協力してコードを修正するか、（可能であれば）ツールを構築して再発を防ぐ必要があります。

インシデント管理についてさらに詳しくご覧ください。

キャパシティプランニングは、今日と明日のサービスの信頼性を確保し、過剰プロビジョニングと不足プロビジョニングの両方から保護します。

SRE チームは、過去の使用パターンを分析し、将来のリソースニーズを予測することで需要を予測します。非効率性を探し、リアルタイムの情報に基づいてリソースを最適化および再割り当てし、変化するデータに応じてこれらの計画を定期的に更新します。

サイト信頼性エンジニアは、キャパシティプランニングを使用して、システムが成長と需要の急増に対応できるようにします。

変更はしばしば停止を引き起こすもので、これは従来のITOpsでも証明されています。しかし、SREは、障害を恐れて変化を恐れるのではなく、3つのベストプラクティスを用いてこれを受け入れます。

• 漸進的で制御されたロールアウトにより、潜在的な問題の影響を最小限に抑え、早期検出が可能になります。

• 監視により、SREは問題をリアルタイムで正確に検出できるようになります。

• ロールバック計画は、問題が発生した場合に変更をロールバックするための安全で迅速な手順を保証します。

これら3つのプラクティスは、可能であればすべて自動化する必要があります。

Elastic Observabilityはテクノロジースタック全体のオブザーバビリティメトリックを収集、監視、分析するための統合ソリューションを提供します。Elastic Observability を使用すると、あらゆるソースからオブザーバビリティメトリックを収集、保存、可視化し、ElasticのSearch AI Platformで問題解決を迅速化できます。


会話型検索とエージェントAIをElastic Observabilityに組み合わせることで、独自のデータや手順書も含めたコンテキストアウェアなチャット体験を実現できます。Elastic AI Assistantは、SREによるログメッセージやエラーの解釈、コードの最適化、レポートの作成、手順書の特定と実行をサポートします。問題解決を迅速化し、コラボレーションを促進し、知識を解放することで、すべてのユーザーを支援し、信頼性を確保します。

Elasticのオブザーバビリティについての詳細をご覧ください。