サイト信頼性ワークブック：実用的なアプリケーション

こんにちは住民！サイト信頼性エンジニアリングの本は、白熱した議論を引き起こしました。今日の搾取とは何ですか、そしてなぜ信頼性の問題がそれほど根本的なのですか？現在、このベストセラーの本の背後にあるGoogleエンジニアは、理論から実践への移行を提案しています。サイト信頼性ワークブックは、SREの原則と実践がプロダクションでどのように具体化されるかを示しています。Googleの専門知識は、Google CloudPlatformのユーザーケースによって補完されます。 Evernote、The Home Depot、New York Times、およびその他の企業の代表者は、彼らの戦闘経験を説明し、採用したプラクティスと採用していないプラクティスを説明します。この本は、会社の規模に関係なく、SREを自分の実践の現実に適応させるのに役立ちます。次のことを学びます。

• 完全に制御していないクラウドおよび環境でのサービスの信頼性を確保します。
• SLOに焦点を当て、サービスを作成、起動、監視するさまざまな方法を適用します。
• 管理チームをSREエンジニアに変換します。
• SREを最初から開始し、既存のシステムに基づいて開始する方法を実装します。Betsy Beyer、Neil Richard Murphy、David Renzin、Kent Kawahara、Stephen Thorneはすべて、Googleシステムの信頼性の確保に関与しています。

監視システム管理

監視システムは、使用する他のサービスと同じくらい重要です。したがって、監視は十分な注意を払って処理する必要があります。



構成をコードとして扱う



システム構成をコードとして扱い、バージョン制御システムに保存することは一般的な方法であり、変更履歴の保存、特定の変更のタスク管理システムへのリンク、単純化されたロールバック、エラーの静的コード分析などの機能があります。強制コード検査手順。



また、監視構成をコードとして扱うことを強くお勧めします（構成の詳細については、第14章を参照してください）。 WebインターフェイスまたはCRUDスタイルのAPIのみを提供するシステムではなく、目標と機能の整形式の説明を使用してカスタマイズをサポートする監視システム（http://bit.ly/1G4WdV1）。この構成アプローチは、構成ファイルのみを読み取る多くのオープンソースバイナリの標準です。 grafanalib（http://bit.ly/2so5Wrx）などの一部のサードパーティソリューションは、UIを使用して従来からカスタマイズ可能なコンポーネントに対してこのアプローチをサポートしています。



一貫性を促進する



監視を使用する複数のプロジェクトチームを持つ大企業は、微妙なバランスを取る必要があります。一方で、集中型のアプローチにより一貫性が確保されますが、他方では、個々のチームが構成の動作を完全に制御したい場合があります。



正しい決定は、組織のタイプによって異なります。時間の経過とともに、Googleのアプローチは、一元化されたサービスとして機能する単一のプラットフォームにすべてのベストプラクティスをまとめる方向に進化してきました。これは私たちにとって良い決断であり、これにはいくつかの理由があります。統合されたインフラストラクチャにより、エンジニアはあるチームから別のチームにすばやく簡単に移動でき、デバッグ中の共同作業が容易になります。さらに、各チームのダッシュボードが開いてアクセスできる一元化されたダッシュボードサービスがあります。他のチームから提供された情報をよく理解していれば、自分の問題と他のチームの問題の両方をすばやく修正できます。



可能な限り、基本的な監視範囲をできるだけ単純にしてください。すべてのサービスが一貫したベースラインのセットをエクスポートする場合、組織全体でそれらのメトリックを自動的に収集し、一貫したダッシュボードのセットを提供できます。このアプローチは、自動的に起動する新しいコンポーネントの基本的な監視があることを意味します。このようにして、社内の多くのチーム（エンジニアリングチームでさえも）が監視データを使用できるようになります。



弱い結びつきを好む



ビジネス要件は変化し、生産システムは1年で異なって見えるでしょう。制御するサービスと同様に、監視システムは、さまざまな一般的な問題を通過しながら、時間の経過とともに開発および進化する必要があります。



制御システムのコンポーネント間の結合はそれほど強くないことをお勧めします。各コンポーネントを構成し、監視データを転送するには、信頼できるインターフェイスが必要です。さまざまなコンポーネントが、監視データの収集、保存、アラート、および視覚化を担当する必要があります。安定したインターフェースにより、特定のコンポーネントを最も適切な代替品に簡単に置き換えることができます。



オープンソースの世界では、機能を個別のコンポーネントに分解することが一般的になりつつあります。10年前、Zabbix（https://www.zabbix.com/）などの監視システムは、すべての機能を1つのコンポーネントに統合していました。最新の設計では通常、ルールの収集と実行を分離し（Prometheusサーバー（https://prometheus.io/）などのソリューションを使用）、長期的な時系列を保存し（InfluxDB、www.influxdata.com）、アラートを集約します（ Alertmanager、bit.ly / 2soB22b）およびダッシュボードの作成（Grafana、grafana.com）。



この記事の執筆時点では、ソフトウェアに必要なツールを装備し、メトリックを提供できるようにする、少なくとも2つの一般的なオープンスタンダードがあります。

• statsd — , Etsy, ;
• Prometheus — , . Prometheus OpenMetrics (https://openmetrics.io/).

複数のデータソースを使用する個別のダッシュボードシステムは、サービスの集中化された統合ビューを提供します。 Googleは最近、この利点を実際に体験しました。従来の監視システム（Borgmon1）は、アラートルールと同じ構成でダッシュボードをバンドルしていました。新しいシステム（Monarch、youtu.be / LlvJdK1xsl4）に切り替えるときに、ダッシュボードを別のサービス（Viceroy、bit.ly / 2sqRwad）に移動することにしました。 ViceroyはBorgmonまたはMonarchコンポーネントではなかったため、Monarchの機能要件は少なくなりました。ユーザーはViceroyを使用して、両方の監視システムからのデータに基づいてグラフを表示できるため、BorgmonからMonarchに徐々に移行することができました。



意味のあるメトリック



第5章では、サービス品質（SLI）メトリックを使用して、予算に対する脅威を追跡および報告する方法を示します。 SLIメトリックは、サービス品質（SLO）ターゲットに基づいてアラートがトリガーされたときにチェックする最初のメトリックです。これらの指標は、サービスのダッシュボード、理想的にはフロントページに表示されます。



SLO違反の根本原因を調査する場合、SLOパネルから十分な情報が得られない可能性があります。これらのパネルは違反があることを示していますが、違反に至った理由を知ることはほとんどありません。ダッシュボードには他にどのようなデータを表示する必要がありますか？



指標を実装する際には、次のガイドラインが役立つと考えています。これらの指標は、本番環境の問題を調査し、サービスに関する幅広い情報を提供できる有意義な監視を提供する必要があります。



意図的な変更

SLO関連のアラートを診断する場合、ユーザーに影響を与える問題を通知するアラートメトリックから、それらの問題の根本原因を警告するメトリックに移行できる必要があります。このような理由は、サービスに対する最近の意図的な変更である可能性があります。生産の変更を通知する監視を追加します。変更が加えられたことを検出するには、次のことをお勧めします。

• バイナリファイルのバージョンを監視する。
• , ;
• , .

これらのコンポーネントのいずれかがバージョン管理されていない場合は、コンポーネントが最後に組み立てまたはパッケージ化された日時を追跡する必要があります。



新たなサービスの問題を展開と関連付けようとする場合、事後にCI / CDログをめくるよりも、アラートで参照されているチャートまたはパネルを確認する方がはるかに簡単です。



依存関係



サービスが変更されていない場合でも、その依存関係は変更される可能性があります。したがって、直接の依存関係からの応答も追跡する必要があります。



依存関係ごとに、要求と応答のサイズをバイト単位、応答時間、および応答コードでエクスポートすることをお勧めします。チャートのメトリックを選択するときは、これら4つのゴールデンシグナルを念頭に置いてください（セクションを参照）「4つの黄金の信号」、サイト信頼性エンジニアリングの第6章）。

メトリックで追加のラベルを使用して、応答コード、RPC（リモートプロシージャコール）メソッド名、および呼び出されるサービスの名前でそれらを区切ることができます。



理想的には、各RPCクライアントライブラリにそのようなラベルをエクスポートするように依頼する代わりに、この目的のために下位レベルのRPCクライアントライブラリを一度ツールすることができます。これにより、一貫性が高まり、新しい依存関係を簡単に監視できます。



非常に限定されたAPIを提供する依存関係があり、すべての機能はGet、Query、またはまったく情報がないという単一のRPCメソッドを介して利用でき、実際のコマンドはそのメソッドへの引数として指定されます。クライアントライブラリのツールへのシングルポイントアプローチは、このタイプの依存関係では機能しません。待ち時間に多くの変動があり、この「泥だらけ」の一部を示している場合と示していない場合があるエラーの特定の割合が表示されます。 APIは完全に機能しなくなりました。この依存関係が重要な場合は、次の方法で適切な監視を実装できます。

• この依存関係のために特別に設計された個々のメトリックをエクスポートします。ここで、リクエストは有効なシグナルを取得するために解凍されます。
• 依存関係の所有者に、依存関係を書き直して、個々のRPCサービスとメソッド間の機能の分離をサポートする拡張APIをエクスポートするように依頼します。

ワークロードのレベル



サービスが機能するすべてのリソースの使用を制御および追跡することが望ましいです。一部のリソースには、超えることのできない厳しい制限があります。たとえば、RAMのサイズ、アプリケーションに割り当てられたハードディスク、CPUクォータなどです。開いているファイル記述子、スレッドプール内のアクティブなスレッド、キュータイムアウト、書き込まれるログの量などの他のリソースには、明確なハードキャップがない場合がありますが、それでも管理する必要があります。



使用しているプログラミング言語に応じて、いくつかの追加リソースを追跡する必要があります。

• Javaでは、ヒープとメタスペースのサイズ（http://bit.ly/2J9g3Ha）、および使用されるガベージコレクションのタイプに応じたより具体的なメトリック。
• 囲碁では、ゴルーチンの数。

プログラミング言語自体は、これらのリソースを追跡するためのさまざまなサポートを提供します。



第5章で説明されているように、重要なイベントを警告するだけでなく、特定のリソースが重大な枯渇に近づいたときにトリガーされるアラートを設定することもできます。これは、たとえば、次の状況で役立ちます。

• リソースに厳しい制限がある場合。
• 使用量のしきい値を超えたときにパフォーマンスが低下した場合。

監視は、サービスが適切に管理しているリソースも含め、すべてのリソースにとって不可欠です。これらのメトリックは、リソースと機能を計画するときに不可欠です。



発行されたトラフィックのステータス



ダッシュボードにメトリックまたはメトリックラベルを追加して、発行されたトラフィックをステータスコードで分類できるようにすることをお勧めします（SLIの目的でサービスによって使用されるメトリックにこの情報が含まれていない場合）。ここにいくつかのガイドラインがあります。

• 誤ったクライアントの動作の可能性があるためにアラートを発行する理由ではないものも含め、HTTPトラフィックのすべての応答コードを追跡します。
• ユーザーに時間制限または割り当て制限を適用する場合は、割り当てが不足しているために拒否された要求の数を追跡します。

このデータのプロットは、生産の変更中にエラー率が著しく変化する時期を判断するのに役立ちます。



ターゲットメトリックの実装



各メトリックはその目的を果たす必要があります。生成が簡単であるという理由だけで、複数のメトリックをエクスポートしようとしないでください。代わりに、それらがどのように使用されるかを考えてください。メトリクスアーキテクチャ（またはその欠如）には影響があります。理想的には、アラートに使用されるメトリック値は、システムで問題が発生した場合にのみ突然変化しますが、通常の操作中は変更されません。一方、これらの要件はデバッグメトリックに課せられていません-アラートがトリガーされたときに何が起こるかについてのアイデアを提供する必要があります。優れたデバッグメトリックは、システムの潜在的に問題のある部分を示します。事後分析を作成するときは、問題をより迅速に診断できる追加のメトリックを検討してください。

アラートロジックのテスト

理想的な世界では、監視およびアラートコードは、開発コードと同じテスト標準に従う必要があります。現在、そのような概念を実装できるようにする広く受け入れられているシステムはありません。最初の兆候の1つは、Prometheusに新しく追加されたルールユニットテスト機能です。



Googleでは、合成時系列の作成を可能にするドメイン固有の言語を使用して、監視およびアラートシステムをテストしています。次に、導出された時系列の値を確認するか、特定のアラートが発生して必要なラベルが付いているかどうかを明確にします。



アラートの監視と発行は多くの場合、複数のステップからなるプロセスであるため、ユニットテストの複数のファミリが必要です。



この領域はまだ開発が進んでいませんが、ある時点で監視テストを実装する場合は、図1に示すように3層のアプローチをお勧めします。4.1。

1. バイナリファイル。エクスポートされたメトリック変数が特定の条件下で期待どおりに値を変更することを確認してください。
2. 監視インフラストラクチャ。ルールが守られ、特定の条件が予想されるアラートであることを確認してください。
3. アラートマネージャー。生成されたアラートが、ラベル値に基づいて事前定義された宛先にルーティングされることを確認します。

合成ツールを使用して監視システムをテストできない場合、またはステップをまったくテストできない場合は、要求やエラーなどの既知のメトリックをエクスポートする実稼働システムを作成することを検討してください。このシステムを使用して、時系列とアラートを確認できます。アラートルールは、設定後数か月または数年は起動しない可能性があります。メトリックが特定のしきい値を超えた場合でも、アラートが意味のあるものであり、目的のエンジニアに配信されることを確認する必要があります。



章のまとめ



SRエンジニアは生産システムの信頼性に責任を負わなければならないため、これらの専門家はしばしば監視システムとその機能を深く理解し、それと密接に相互作用する必要があります。このデータがないと、SREは、どこを調べれば、システムの異常な動作を特定する方法や、緊急時に必要な情報を見つける方法を知らない可能性があります。



私たちの観点から有用な監視システムの機能を指摘し、選択を正当化することにより、監視システムがどのようにニーズを満たしているかを評価するのに役立つことを願っています。さらに、使用できる追加機能のいくつかを調べて、加えたいと思われる変更を確認するのに役立ちます。監視戦略でメトリックとログのソースを組み合わせると便利な場合があります。メトリックとログの適切な組み合わせは、コンテキストに大きく依存します。



特定の目的に役立つメトリックを必ず収集してください。これらは、帯域幅のスケジューリング、デバッグ、または発生した問題の報告などの目標です。



監視しているときは、視覚的で便利なはずです。これを行うには、その設定をテストすることをお勧めします。優れた監視システムは利益をもたらします。特定の要件を最適にカバーするために使用するソリューションを事前に徹底的に計画し、監視システムを継続的に繰り返し改善することは、成果を上げるための投資です。



この本についての詳細は、上で見つけることができます»出版社のウェブサイト

»目次

»抜粋



については居住者クーポンで25％割引- Googleの



書籍の紙のバージョンの支払いの際に、電子書籍を電子メールで送信されます。