GitOps Part 3 — Observability

GitOpsの可観測性

第2回の続き、GitOpsの可観測性を説明します。

TL;DR

「Observability（可観測性）とはプロダクションのためのTDD（双方向の無線通信を実現するための手法のひとつ）のようなものです。プルリクエストが実装中かどうか認識する方法が分からなければプルリクエストを受け入れてはいけません。ありがとう。@mipsytipsy” — アドリーノ・バストス

もしデベロッパーがテストを好んでするようになれば、プロダクションにおいてユーザーの満足度を上げられると思います。 Observability（可観測性）がこれを可能にします。Gitはシステムのお望みの状態のために信頼できる情報源を提供してくれます。そしてObservabilityは実装中のシステムの実際のプロダクション状態のために信頼できる情報源を提供します。GitOpsの中では、私たちはその両方をアプリケーションの管理に使います。

かつては、デベロッパーが物を作り、試験者が組み立てや検査を担当していました。そしてオペレーターが動かし方や、管理やモニタリングを担当していました。それぞれの役割を１つのデリバリーサイクルを伴った１つのチームにまとめました。これは速さや軽快さを追求したためです。あらゆるビジネスにおいてはテクノロジーから生まれるサービスからお金を生み出さないといけません。競争と利益はそのビジネスが、テクノロジー・チームに対していかに早くユーザーの要求を伝えることができるかにかかっています。そして、いかに早くそれにテクノロジー・チームが対応できるかによって結果が変わってきます。このような状況の中、色々な変化を認めないアプリ開発チームにはもう生き残る道はありません。

そしてそれは、ソフトウェアエンジニアは自分のアプリを持てるようになる必要があるということを意味します。そして、それに気づき、それを操作可能なように理想的な取り組み方でアプリを作ることです。Observabilityは開発者のワークフローに対してそれを本質的なものにします。

Developers < 3 Operations?

「Observability開発はかっこいい仕事です。AirBnbは2017年の初旬にObservabilityチームを立ち上げています。それは現在新しいDevOpsです」http://bit.ly/2ig7H84” — シンディ・シリッドハラム (@copyconstruct)

Observabilityは今話題になっています。おそらくデベロッパーたちはopsについて考える1つの方法だと気づいたからです。それは、チャリティー・メジャーズ氏（the inimitable @mipsytipsy on Twitter と メジャーズ氏のブログ）とシンディー・シリッドハラム氏 （Medium上の@copyconstruct 氏はobservabilityとクラウドネイティブ間の相互作用について述べています。）の功績によるものです。

１．もしデベロッパーたちがシステムの現在の状態を外から理解できれば、システムはObservable（観察可能）になります。

２．モニタリング、トレース＆ログはベースライン観察のためのテクニックです。エラー率、リクエストのレイテンシー（待ち時間）、１秒ごとのクエリなどの測定値。（例えば、operational wellnessの症状など）

デベロッパーを医者のように考えましょう。つまり、validate health（健康かどうか検査する）するため、症状を測定するため、「全ての問題の原因を分析し、対応する」ため、共通のランゲージや、色々なテクニックを使うということです。そのようなデベロッパーたちは何か問題が起きた時の対応や修理がとても早いです。そしてビジネスにおいてもその速さが求められます。

デベロッパーたちは自然にGitをベースにしたワークフローに関心を持つようになります。前回の投稿では、Kubernetesのようなツールを使っている場合、どのようにGitOpsがインフラストラクチャーマネージメントをGit PRsに結び付けるのかについてお話しました。それではこれから、GitOpsとObservabilityを一緒にして、お互いに助け合って機能し合うか見てみましょう。デベロッパーたちはGitを信頼できる情報源としてや、ログ、トラッキングやもっと他のことのために使えるのでしょうか？その反対の場合もそうでしょうか？

Observability Is Another Source of Truth

GitOpsの中で、私たちはGitをシステムの求められる状態のための信頼できる情報源として使っています。例えば、もし失敗したら、その状態にロールバックすることが可能です。そしてObservabilityは、現在「実際に実装中の状態のシステム」のための信頼できる情報源です。私たちは、実装中のシステムを理解し、コントロールするためにobserve（観察）します。ここにそのフローを示している図があります。

Observations Are Answers To Questions About Releases

Weave Cloud開発チームはこの数年間Kubernetesスタックをずっと走らせてきました。総体的に見れば、Kubernetesが基本的にあなたに代わってインフラストラクチャー・プラミングを管理してくれるこの魔法のプラットフォームである一方、visibility（可視化）に伴うロスがあります。以下に示しています。日々に出てくる問題も含まれています。

• 私のデプロイは機能しましたか？私のシステムは今望ましい状態になっていますか？もう帰宅してもいいかな。
• 私のシステムは前のものとどう違うのですか？チェックするためにGitかシステム履歴を使ってもいいですか？
• その変化がUX全体を進歩させましたか？（システムの正確性とは反対に）
• メトリックダッシュボード（例えばRED metrics）の中に新しいサービスがない。
• この故障は最後にしたサービスのアップデートに関係しているのだろうか？もしくはもっと前にやったものが原因？

魅力的な点としては、すべての事象と「データベースとchatops gumf」が１つのuber-dashboardの中に入っていて、できるだけ多くのobservationを記録できることです。そうすると、ノイズを隠す解決策を見つけるために、だいたいいつも負荷を認知するような結果になります。それは、新しい種類のダッシュボード（例えばMatt’s team at Lyft）や新しいコンテクストベースのインシデント調査ツール（例えばCharity’s team at Honeycomb）を作るということを意味します。

補足： 2011年が過ぎてまもなく、「Observability」チームを作ったTwitterのような会社もあります。分散サービスへの移行の複雑さへの増加に対応するためです。このコリー・ワトソンの投稿 2013年 を見てみると、Twitterは単純にモニタリングすることから、サービスとシステムヘルス、そしてユーザー満足度への総合的なアプローチへ広げていきました。それらは、チームパート 1 & パート 2 &スライドからも続いています。

Diffs Check Observed vs Desired State

Weaveチームは私たちのSaaSプロダクトを走らせやすくするためにDiff toolを使います。Diff は以下の２点において利点があります。

１.現在観察中のプロダクション状態のシステムをGitの中のシステムの必要な状態へ有効にすること。例えば、最後のリリースが私の願っていた通りになったかどうか。

２.もし私たちがほとんどPrometheus とSlackを通してやっていないという時に、すぐに知らせてくれる。そして、そのリリーズ前後の差分を知らせてくれる。

Diffはあなたのベースラインの必要なGitOpsツールです。Diffは私たちの信頼できる情報源を比較します。例えば、現在観察されている状態とGitの中の必要な状態を比較します。Diffにはカスタムクリエーションやコーディングは不要です。そしてDiffは「普通に機能」します。というのも、私たちのシステムはステートメントのセットと定義されているからです。いわゆる「declarative infrastructure」のことです。できる限りそれを使うようにしましょう！

• Kubediff -例えば、希望するKubernetes状態は「４つのredisサーバーがあります」ということになることがあります。Kubediffは定期的にクラスターをチェックし、もし数が4から変更されたらアラートで知らせます。一般的にはKubediffは実装中の状態の中でyamlファイルに変わります。
• Terradiff- Terraformには「plan」モードというのがあり、それはもし自分のコンフィグが実際のものとマッチしたら、これを定期的に実行して、私たちがモニターしていて、アラートをかけているものからPrometheusへexit codeをエクスポートします。私たちの GitHub上でのTerraform k8s セットアップ.
• Ansiblediff はKubernetesのデプロイです。そのコンテナは定期的にAnsible チェックモードを実行します。そして、Ansible k8s インストールの中で何かが変化したら、Prometheusに知らせます。

補足: Kubernetesはコントローラースタイル 自動突合せループを既に構築しています。orchestratorはある条件においては“observe + sync”ということも可能です。ここでお話しているのは、Gitの中の状態と実際に適用されたKubernetesのapiサーバーとの間にドリフトが存在する可能性もあるということです。

Automation Is Convergence

それぞれの“diff”のために、コンバージェンスを強制するための“sync”ツールが存在します。その範囲に対し、Gitの中にステートメントを入れられます。そして、diffとsyncを使って、コンバージェンスを認識し、強制的にコンバージェンスをします。そして、Kubernetes orchestratorが促進させ、オペレーションを自動化できるようにするということ以上のことができるようになります。まとめるとGitOpsはきめ細やかなConfiguration Synchronizationを提供してくれます。したがって：

これについてもっと詳しく書いている内容や、プロダクションKubernetesクラスターをモニターする方法などをご覧になりたい方は、 プロビジョニング や モニタリング などの投稿をご覧ください。

Control Loops

「私はいつも『observabilityはcontrollability（可制御性）のデュアルである』という言葉が、とても意味の深い言葉だと思っている」 －ブライアン・ボレハム

https://twitter.com/bboreham/status/91672251625261

DiffとSyncはペアです。－つまり、問題をobserve（監視すること）する作業と修復作業です。もっと一般的に言うと、オペレーションにおいて、人間がobserveし、何か問題があると判明する、そして修復作業をするということです。これは全て、“controllability”（ observabilityのデュアル）の例です。

補足: Observabilityとコントロールはルドルフ・カーナップという素晴らしい人物によって発明されました。ルドルフは、そしてその大きなクラスのための厳密なObservability（可観測性）について定義づけ をしました。そして、全てのobservationがobserveされているものを変えるためにデュアル“controllability”アクションとどのように関連しているのかを見せてくれました。gps, military, network securityやエラー修正コードなどの多くの実例を見ることができます。技術においては「コントロール」は「オペレーション」と呼ばれていますし、また「マネージメント」と呼ぶこともできます。

ぜひこのコーダ・ヘイルのスーパープレゼンテーション 2011, “どこのかしこもメトリックだらけ”というプレゼンをご覧ください。この中では、私たちがどのようにシステムすればよいのか、とそれによって “OODA” style decision loopsの中の最適化を促す方法について説明してくれています。そして、ぜひこちらのmicroservicesについて（ エイドリアン・コックロフト ） も合わせてご覧ください。

Operations and the ROODA loop

GitOpsはオペレーションのリリース重視のモデルです。下のダイアグラムを見てください。デリバリーの速さはどのくらい早くチームがこのサイクルの中でステージを回れるかによって変わってきます。

OODA loop, “Observe, Orient, Decide and Act”のように下にGitOpsサイクルを書きます。でもここにはゆがみが存在しています。私は「アクト」部分をGitへのアップデートと、Gitからプッシュされたリリースに分けました。これをROODA loopと呼びます。

ここで一番難しいのはどのように「オリエント、決定、実行」するかです。ここがオペレーションの難しい部分です。どのようにしたらこれがもっと分かりやすくなるのでしょうか？これが次の大きな挑戦です。

GitOps Practicalities

私たちのWeave Cloudチームでは、マネージメントをするため、そして内因性をモニタリングするためにGitOpsを使っています。どのような「コントロール」質問が中で走るのでしょうか。

• 私たちが強制的にsyncしない方がよい時はあるのか？
• どのようにorchestratorとの対立を管理するのか？
• システムからのGitへの変更が完了できるのか？ 例えば 新しいチェックポイントを作るのは？
• もしサービスをアップデートするとしたら、自分のメトリックとダッシュボードは自動アップデートを取得することができるのか？
• マルチステージロールアウトとマルチバージョンステージング（例えばカナリア）はどうなのか？

I won’t try to answer these here. More general “what can go wrong” examples are shown below, specifically for cases where Kubernetes can’t fix everything for you by using orchestration.

ここではこの質問に答えるのは控えておきます。もっと一般的な「どのようにしたら間違うか」というような例を下に挙げました。特にKubernetesがorchestrationを使って何も修正できないというような場合などです。

一番最後のケースは、根本の原因が何なのか分からない場合や、どう修復すればいいのか分からない場合です。複雑なシステムの中では最悪なことがたくさん起こるのです。例えば、「レースコンディションが非決定性のオーバーフローを起こしていて、次々と問題が起きる」などです。ここでObservabilityはすごく役に立つ のです。それは全て、デベロッパーがよいツールを使って適切に自分たち自身のアプリコードを観察可能、発見可能にしているということです。そして、SRE book や Release It!のような素晴らしい本を読んでいるからです。

A Way Forward

私たちの目的はビジネスがデリバリーを加速しやすいようにすることです。私たちは、デベロッパーのたちがオペレーションを好きになってくれるようにObservabilityとパイプラインを統一したGit-centricを提供しています。ここに、そのアイデアを挙げておきます。まだまだ開発段階です。

Dashboards As Code

Weaveworksでは私たちはいくつかのobservabilityツールを使っています。例を挙げればPrometheus, Weave Scope, Grafanaなどです。だから私たちは自分たちのダッシュボードをコードとして保管しています。このブログでその方法を説明しています。私たちはソースコントロール、モニタリングをデプロイする機能をプラスすることなどの利益を得ています。持続的に全ての自分のスタックに伴ったソースからです。

Focused Actionable Dashboards

モニタリング、ロギング、トラッキング、トレーシングに関しての大きな問題はデータとノイズが大量になることです。コグニティブなオーバーロードはサービスコストとストレージの超過という結果の1つです。フォーカスも必要です。OODAループの中では、オリエンテーションのステップは選ばれた情報と実行可能なアラートをこの写真からどのように引き出すかということです。フォーカスを提供する1つの方法は、機能から変えることです。つまり、「すべてのことをモニターとログすること」と「自分のサービスについての重要な事実を見せてほしいし、適切な位置でそれを改善するのを助けてほしい」ということに変わることです。

Weave Cloudは異なるGitOpsライフサイクルの小さな部分を1つのサービス中心のツールに統合します。これは、私たちが自動でサービスメトリックを生成でき、それをデプロイイベントと履歴を相互に関係を持たせ、現在と過去のパフォーマンスを分析することができるという意味です。これはマネージング様にアレンジされたロールアウトやカナリアなどのためのデベロッパー中心のツールを作るにはすごくいい方法です。顧客がEnvoy, Linkerd, や Istioを使っている時などはそうですね。 総体的に見れば、これはObservabilityダッシュボードをより全体的に、連携させることを容易にします。モニタリング、ロギング、トラッキングのメインの柱を全部まとめて引っ張るためです。

補足:みんながAppOps について話をします。－「プラットフォーム定義」がインフラストラクチャーopsを持つようになる一方、アプリケーションレイヤーでどのようにアプリ開発者はオペレーションをしているのか、などについてです。ここにBridget Kromhout氏のツイート Bryan Lilesのunifying CI, CD, ログ, メトリック と Errorの扱いのイラスト.

Design For Observability, Tool For Controllability

ソフトウェアのデリバリーはソフトウェアの観察可能になるまでは「完了」と認識してはいけません。結果論ではなく、自分のアプリ開発過程のモニタリングとマネージメントを作成してください。デベロッパーはそのデザインの開始時においてアプリケーションの監視の中でbakeするべきです。プロダクションの中で、システムobservationsとプラットフォーム、パイプラインをお互いに関連づける必要があるでしょう。

ツールを選ぶ時には以下のことに気を付けてください：

１. Prometheusのようなクラウドネイティブモニタリングツールの使用は役立ちます。でも、もし参照解 と他のツール（diffなど）を組み合わせれば、もっと効果的です。

２．ログ機能は高価 — ロギングとモニタリングをミックスするときには注意をしてください。

３．多くのメトリックはRED Metricsのようなプラットフォームによって自動生成されることがあります。

4. service meshのようないくつかの新しいツールは適切な分散アプリケーションのためにシステマチックなobservability（可観測性）とコントロールを適用します。Matt Klein sets out the reasons in this fine post.

5.もしあなたが、テストとその問題を緩和するためのシステムと同時に影響し合うことができないなら、これらはどれも何の役にも立ちません。

まとめ

ObservabilityはKubernetesのための継続的なDelivery サイクルの一部だと認識されます。GitOps 1の中では、どのようにシステムの すべての所望された初期状態のための「信頼できる情報源」 としてのGit を使用するかについて、そして GitOps 2, orchestrateされた ロールバックやスナップショットなどを可能にするリリース パイプライン。 GitOpsでは実際の状態とオペレーションのためにObservabilityを信頼できる情報源として追加しました。観察された状態はGitの中の必要な状態と比べられるべきです。GitOpsダッシュボードの役割は、観察、理解のスピードアップ、システムの確認、アクションの緩和の提案を可能にすることです。このオペレーションサイクルのスピードアップはROODA loopと思われます。開発者たちは自分のシステムが観察可能だということを確かめます。そしてそれを観察し、build alerts off that. モニタリングだけでは全ての疑問は解決しない：メトリックは病気そのものではなく、症状なのです。これに似たようなものは？クラウドネイティブロンドンでのGitOps物語の完全版をご紹介します。この動画 とスライドを見てください。またサン・

ディープとジョーダンがWeave オンライン ユーザー グループの中で、見事なKubernetesのベストプラクティスについての動画解説をしてくれています。

Orangesys.ioでは、kuberneteの運用、DevOps、監視の手伝いをさせていただいています。ぜひ私たちにおまかせください。