クラウドネイティブに殺されなかった運用担当者がSREに転身…

Google は 10 年前に SRE という職種を創設しました。 SRE は Site Reliability Engineering の略称で、site は Website を指し、Web サイトの信頼性エンジニアリングと訳すことができます。数年前、Google のシニア SRE である Chris Jones 氏らが「Google SRE: Google が本番システムを実行する方法」を共同執筆し、Google の実稼働環境と SRE 方法論全体を初めて外部に公開しました。では、SRE システムをゼロから構築するにはどうすればよいでしょうか?以下のコンテンツでは、主にサイト信頼性エンジニアリング (SRE) と、システムの拡張時にシステムを監視し、高速で信頼性の高い状態を維持する方法について説明します。

図 1: SRE アーキテクチャのマインドマップの作成

クラウド時代において、顧客体験はすべての真剣なビジネスにとって新たな合言葉であり、ミッションステートメントです。顧客エクスペリエンス、可用性、アクセシビリティはエッジで決定され、サイトは常に [24 時間 365 日] 利用可能である必要があります。ユーザーにとって重要なのは信頼性です。使用されていないアプリケーションは、ユーザーにとってもビジネスにとっても価値がありません。

今日、あらゆる企業が技術革新を推進するために懸命に取り組んでいます。企業のビジネス戦略はクラウド機能を中心に構築されます。これは彼らにとって大きな運用上の課題です。サイトのパフォーマンスと顧客エクスペリエンスが低下すると、現金、収益、競争力の損失につながり、従来の運用では対応できない観測可能性（リアルタイムの監視とアラートを含む）の大きな問題につながります。

サイト信頼性エンジニアリング (SRE) が存在するのはなぜですか?アジャイル運動により、機能横断型チーム間のコラボレーションの重要性が促進され、DevOps が誕生しました。

DevOps とは、組織固有の問題や課題を深く掘り下げることです。スピード、効率、品質も重要です。本質的には、組織の望ましい結果を達成するための文化、運動、一連の価値観、原則、方法、実践です。

この速度は、ある程度の不安定性も生み出します。開発者の動きがかつてないほど速くなっており、運用チームにとって課題が生じています。 IT 運用チームはこの速度に対応できず、ボトルネックと深刻なバックログが発生し、生産が不安定になり、結果としてシステムの信頼性が低下しました。そのため、Google は SRE の要件として、「運用上の問題にエンジニアリングの専門知識を適用できる開発者のグループ」を提唱しています。

SRE は標準化された DevOps アプローチです。これは、デリバリーサイクルとインシデント管理ライフサイクルを短縮してサービスを運用し、作業負荷を軽減して開発者とオペレーターをサポートするという原則に重点を置いた、システム管理タスクの考え方です。 SRE チームの日常的なタスクには以下が含まれます。

• 可用性
• 遅れ
• パフォーマンス
• 効率
• 変更管理
• 監視と警告
• 緊急対応
• インシデント対応
• 準備
• キャパシティプランニング

では、サイト信頼性エンジニアリング (SRE) とは何でしょうか?

SRE チームの役割は、運用中の「ミッション クリティカルなシステム」でアプリケーションを実行し、サイトを稼働し続けるために必要なことすべてを行うことです。通常、運用と保守の作業を行うソフトウェア エンジニアとして定義されます。 SRE チームは、システムのサービス レベル指標 (SLI)、目標 (SLO)、契約 (SLA)、およびエラー バジェットを維持および確立し、それらが満たされていることを確認する責任を負います。

運用作業（システムが期待どおりに動作することの確認）と管理するシステムの改善に一定の時間を費やすことが期待されます。 SRE は、プロセスを自動化し、「面倒な作業」の作業負荷を軽減するソフトウェアの作成に重点を置いています。この「面倒な作業」とは、システムによってまだ自動化されておらず、手動で処理する必要がある作業のことです。

SRE の戦略的目標は次のとおりです。

• 導入が簡単になります
• 稼働時間の向上または維持
• アプリケーションパフォーマンスの視覚化機能を構築する
• SLI、SLO、エラーバジェットの設定
• 計算されたリスクを取ってスピードを上げる
• 手作業を排除
• 障害コストを削減し、新機能のサイクルタイムを短縮する

SLI と SLO

サービス レベル目標 (SLO) は、SRE チームと製品所有者または事業部門 (LOB) の間の合意にすぎません。指標は、チームが管理するシステムの性質によって大きく異なります。サービス レベル インジケーター (SLI) は、システムに対して定義される定量的なメトリックであり、「測定対象」とも呼ばれます。

これらのメトリックは管理対象のシステムによって異なります。一般的な Web アプリケーションの場合、これらのメトリックは可用性、リクエストの待ち時間、エラー率などになります。ただし、たとえば、Hyperledger Fabric ブロックチェーン アプリケーションでは、ネットワークのスループットを測定するために、エンドースメントと 1 秒あたりの元帳コミット レートを使用する場合があります。

SRE チームは最終的に複数のシステムを管理することになります。さまざまなアプリケーションにわたって標準的なサービス レベル メトリックのセットを定義すると、チームはスタック全体の監視、ログ記録、自動化を標準化できるようになります。

SLO は、システムが「どの程度」パフォーマンスを発揮すべきかを示す目標値または範囲です。これらは、以前に定義された SLI の予想される動作値です。たとえば、ブロックチェーン ネットワークでは、エンドツーエンドのレイテンシを 5 秒未満にして、50 ～ 100 件のトランザクション送信レートのトランザクション スループットを維持する必要があります。もちろん、SLI と SLO を過剰に設計する傾向もあります。最初はシンプルにしておくことが重要です。時間の経過とともにシステムに対する理解が深まるにつれて、より厳しい目標を設定できるようになります。

3. SLAの主なビジネス価値

サービス レベル契約 (SLA) は、顧客が提供されたサービスに満足せず、関連する契約どおりにサービスが提供されない場合に適用されます。それはシステムの信頼性である可能性があります。 SLA は、製品とそのエンドユーザー間の契約です。サービスの信頼性に関してお客様と締結する契約です。簡単に言えば、「SLA = SLO + 結果」です。 SRE チームは SLA の定義プロセスには関与しないかもしれませんが、SLO が満たされていることを確認する責任があります。

SLA には通常、一定期間にわたるサービスの稼働時間の計算が含まれます。

図2は9を使用したSREを示しています

99.9% は 3 つの 9 秒の稼働率で、1 日あたり 1.44 秒のダウンタイムが許容されます。上記の表に示すように、週、月、年間のダウンタイムはそれぞれ 10.1 分、43.8 分、8.78 時間です。

たとえば、SLA では通信回線の稼働率を 99.9% 保証する場合があります。したがって、サービスが停止できる時間は 0.1% のみであり、それ以上になると SLA 違反とみなされ、罰金が科せられます。

4. SREチームの作業負荷を軽減し、作業負荷を制御する

SRE チーム内で実行する必要がある、手作業による面倒な作業は常に存在します。ソフトウェア開発者であろうと建築家であろうと、日々の仕事では、好きではないタスクを完了する必要があります。これらの手作業が多く、退屈で反復的なタスクは、エラーにつながる可能性もあります。 SRE チームも同様のタスクを実行する必要があります。これは、SRE が開発スキルを活用し、可能な限り手動プロセスを排除できる例です。 SRE が管理するシステムの改善に最大 50% の時間を費やすようにするのが良い方法です。

5. エラーバジェット

エラー バジェットは、SRE チームがサービスの信頼性のバランスをとるために使用するツールであり、次のように計算されます。

可用性 = (良好なイベント数 / 合計イベント数) * 100
エラー バジェット = (100 - 可用性) = 失敗したリクエスト / (成功したリクエスト + 失敗したリクエスト)

エラー バジェットは 100 からサービスの SLO を引いた値です。 SLO が 99.99% のサービスでは、エラー バジェットは 0.01% になります。

エラー バジェットは、各サービスがペナルティ条項を含む独自のサービス レベル契約によって拘束される SLO のもう 1 つの例です。他の SLO を満たすためにどれだけの余裕があるかを測定します。

たとえば、トランザクションの 99.99% が 5 秒以内に会計のためにコミットされる必要があるというサービス レベル インジケーターがある場合、5 秒以上かかるトランザクションは 0.01% のみになります。メジャーリリース後、動作が遅くなり始め、突然エラー バジェットがすべて使い果たされていることに気付く場合があります。

変更が停止の最も重要な原因であり、リリースが変更の主な発生源であることを忘れないでください。エラー バジェットを継続的に超過している場合は、SLO とプロセスの一部を再検討する必要があります。

1 回のリリースで導入する変更が多すぎませんか?シンプルさを保ち、リリースをより小さな要件の変更に分割します。

SLO は厳しすぎますか? SLO を交渉して緩和する必要があるかもしれません。

リリースプロセスで問題を引き起こしている手動の手順はありますか?自動化とテストを導入してみてください。

システム アーキテクチャはフォールト トレラントですか?ハードウェア障害、ネットワーク パケット損失、またはアップストリームまたはダウンストリーム アプリケーションで予期しない動作が発生する可能性があります。システム アーキテクチャはこれらの障害に耐えられる必要があります。

開発チームは技術的負債に対処していますか?新しい機能を急いでリリースすると、技術的負債が見落とされがちです。

監視とアラートは主要な指標を捕捉していますか?キューのサイズの増大、ネットワークの速度低下、過度のリード変更などはすべて、ダウンストリーム イベントにつながる可能性があります。

ログを定期的に監視し、クリーンな状態に保っていますか?ログには、すぐには問題を引き起こさない警告が含まれている場合があります。ただし、他のインフラストラクチャの問題と組み合わせると、これらのアラートが重大なインシデントにつながる可能性があります。

6. 分散システムを監視するための 4 つの黄金指標

SRE の 4 つの黄金律は、成功する監視およびアラート システムを構築するための基本原則とベスト プラクティスです。これらは、大規模な本番アプリケーションのサービス レベル目標 (SLO) の重要な部分です。彼らの目標は、システムの潜在的な問題を特定し、解決することです。

運用チームが問題を迅速に把握し、ほぼリアルタイムですべてのサービスの遅延、トラフィック、エラー、飽和度を追跡する必要があるときはいつでも、インフラストラクチャの問題をプロアクティブに解決します。

各メトリックについて簡単に説明し、次に 4 つの主要なメトリックを使用してシステムを監視する方法を見てみましょう。

遅れ

レイテンシは、情報の送信者と受信者の間の遅延時間であり、ミリ秒 (ms) 単位で測定されます。原因は多くの場合、パケット損失、ネットワーク輻輳、および「パケット遅延変動」と呼ばれるネットワークジッターです。レイテンシは顧客エクスペリエンスに直接影響を及ぼし、成功したリクエストの遅延や失敗したリクエストの遅延につながります。

流れ

トラフィックは、システムのワークロードによって発生する圧力です。これは、1 秒あたりのクエリ数 (QPS) または 1 秒あたりのトランザクション数 (TPS) で測定されます。企業はこれを量で測定します。つまり、主要業績評価指標 (KPI) は、特定の時間にサイトに訪れる人の数です。これはビジネス価値に直接関係します。

間違い

エラーは、システム全体で発生するエラーに基づいて測定されます。サービスエラー率の重要な指標と考えられています。エラーには 2 つのカテゴリがあります。失敗した HTTP 要求のような明示的なエラー (たとえば、500 エラー コード)。暗黙的なエラーは、応答は成功しますが、内容が間違っていたり、応答時間が長かったりします。

飽和

飽和度は、サービスがどの程度過負荷になっているかを定義します。リソースとサービスの全体的な容量に重点を置いて、システムの使用率を測定します。これは通常、CPU 使用率、メモリ使用量、ディスク容量、1 秒あたりの操作数などのリソースに適用されます。ダッシュボードと監視アラートは、これらのリソースを監視し、飽和状態になる前に積極的に容量を調整するのに役立つ理想的なツールです。

利用

一般的に受け入れられている「4つの黄金の指標」の一部ではありませんが、言及する価値はあります。使用率は、リソースまたはシステムがどの程度混雑しているかを示します。 0～100% の範囲のパーセンテージで表されます。

図3 ゴールデンシグナル

これらの指標は重要であり、監視する必要があることに私たちは皆同意しています。では、どうやって始めればいいのでしょうか?簡単にするために、CPU、ディスク、ネットワーク、RAM などの非常に基本的な従来のリソースを考慮して、非常に基本的なマトリックスを作成しましょう。

ゴールデン メトリックの利点は、アラート、トラブルシューティング、チューニング、容量計画が可能になることです。

• 問題が発生したときにアラートが通知されます。
• トラブルシューティングは、問題の発見と解決、および根本原因の分析に役立ちます。
• チューニングと容量計画は、監視システムから収集された適切なメトリック、ログ、トレースを使用して、時間の経過とともに問題を改善するのに役立ちます。

図4 ゴールデンシグナルネットワークと遅延

図5: ゴールデンシグナルの誤差と飽和

七。リスク分析

リスク分析は次のように定義されます: SLO 違反につながる可能性のある項目のリスト。

• TDD: 検出時間
• TTR: 解決までの時間
• 頻度/年: 年間のエラー頻度
• ユーザー: 影響を受けるユーザー
• 不良/年: エラー予算に相当する年間の異常分数

SRE は、エラー バジェットを使用して許容可能なリスク レベルとリスクを管理し、SLI および SLO と連動していつ変更を行うべきかについて情報に基づいた決定を下すことで、制御された方法でリスクを受け入れます。必要に応じて、SRE チームがリリース サイクルを制御できます。

リスク = TTD * TTR * (頻度 / 年) * (ユーザーの %)

 TTD = 0の場合、

リスク = TTR * (頻度 / 年) * (ユーザーの %) 

図6 リスク分析と測定

8. 監視と警告

監視はシステムの動作状況を観察するのに最適な方法であり、アラートはシステムがクラッシュしたとき、またはクラッシュしそうになったときにトリガーされるイベントです。したがって、SRE チームが信頼性が高く有意義な監視システムを構築することが不可欠です。優れた監視システムを構築するために使用できるツールは多数あります。 Prometheus は、イベントの監視とアラートのためのオープンソース アプリケーションです。 HTTP プル モデルを使用して構築された時系列データベースにリアルタイム メトリックを記録します。たとえば、Prometheus は、Hyperledger Fabric ブロックチェーン ノードからメトリックを抽出するように構成できます。

図7 監視とアラーム

Grafana を構成して、Prometheus をクエリするための視覚化とダッシュボードを構築できます。

図8. サービスを監視するための「4つのゴールデンシグナル」を使用したGrafanaダッシュボードの例

9. 事後分析を促進する

組織内で SRE の役割を構築する場合、重要でありながら忘れられがちな側面が事後検証です。 「死後検査は無罪だ」これは、組織が犯した間違いから学ぶ機会として定義できます。障害が解決されたら、できるだけ早く事後分析とレビューを実行する必要があります。複雑なエンタープライズ IT 環境では、コンポーネントとアプリケーションは最終的に障害を起こします。これらの障害は、デプロイメント エラー、最近のリリースで導入されたソフトウェア バグ、または単なるハードウェア障害が原因である可能性があります。

インシデントの根本原因と短期および長期の修正を文書化し、開発チームと SRE チーム全体に広めることは、企業全体での知識移転にとって重要です。障害の発見は、他のシステムの予防修復に使用できるほか、将来同様のインシデントが発生した場合の参照ポイントとしても役立ちます。事後検証が適切に行われた場合は、それを記録し、後で参照できるように社内の知識ベースを構築するために使用する必要があります。

10. 信頼できるサービスを得るにはどうすればいいですか?

SRE チームの役割は、必要なアクションを実行してアプリケーションを運用し、システムを適切に稼働させることです。 SRE が各段階で日常業務を実行するために使用する戦略とツールをいくつか紹介します。

フェーズ1: 開発

• パイプライン
• ロードとスケール

フェーズ2: パイロット

• 監視
• オンコール + 非難のない事後検証
• 統合された検索可能なログ
• プロダクトオーナーと定期的にSLI/SLOを確認する
• インフラストラクチャをコードとして

フェーズ3: 生産

• カナリアデプロイメント + 自動ロールバック
• 負荷とスケールの実装
• アプリケーション パフォーマンス モニタリング (APM)
• カオスエンジニアリング

11. 結論

では、信頼性の高い動作とはどういう意味でしょうか?このブログ投稿では、成功する SRE チームを構築するために必要な基本的な概念とテクニックについて説明します。改善されたメトリック、ログ、トレース、ダッシュボードを通じて可観測性に焦点を当て、インシデントを積極的に特定して修復する方法と、SLO、SLI、SLA について説明します。エラー バジェットやリスク分析などの基本的なツールを使用して、信頼性への投資とアプリケーション機能やその他のビジネス上の優先事項への投資のバランスをとるために必要な意思決定を導く方法を学びます。最後に、この記事では、分散システムを監視するための 4 つの重要な指標について詳しく説明します。