涅槃を目指す in はてな

人生に迷う様を書きます

Observability とOracle Cloud について考える

Oracle Cloud 運用 Observability

この記事は、 JPOUG Advent Calendar 2021 14日目の記事です。

13日目は wmo6hashさんの記事『「働き方の新しいスタイル」への仕事場の最適化』でした。

本記事ではObservabilityというものについて考え、Oracle Cloudでどう実現したら良いのか考えてみます。

Observabilityとは何か

まずは歴史的経緯を見てみましょう。こちらのサイトがとてもよくまとまっていました。

www.humio.com

そのサイトによると

  • 1960年に電気工学の制御理論の中で「Observability」という考えが出てきた
  • 2013年にObservability at Twitterという記事でITシステムにObservabilityという言葉が使われた
  • 2017年にMetrics, tracing, and loggingの3つの柱の重要性が解かれた
  • 2019年に3つの柱を見直す動きがあり（特にログはマイクロサービスではデータ量が肥大化する）、活発な議論が今でもされている

という事がわかりました。3つの柱が重要なのは事実ですが、扱い方にフォーカスが移っているようです。

システムの内部状態を理解でき、探索できるようにし、何が起きたのかという疑問に答えられるようにすること。それがObservabilityだと結んでいます。

記事中で私が最も興味を持ったのが以下のツイートです。

Charity Majorsさんは一連のツイートの中で、イベント を中心に考えないと3つの柱は意味がないと言っています。盲目的に3つの柱を推奨するのはやめましょうと。

ログ、メトリクス、トレースはイベントから生まれるもので、ログやメトリクスをいくら集めてもイベントにはならない。ツールありきだと何種類ものツールを行ったり来たりすることになると（強めの口調で）言われています。

Charity Majorsさんはhoneycomb.ioと言う会社のCTOで、コーポレートサイトのブログは、参考になる記事が多いです。

その中でFramework for an Observability Maturity Modelという記事があるので紹介します。

www.honeycomb.io

これは組織のObiservability成熟度レベルに関する記事です。

ざっくり紹介しますけど、本文にはチェックリストもあるのでぜひ読んでみてください。

Framework for an Observability Maturity Model

  • Observabilityのゴール
    • サステナブルなシステムとエンジニアの幸福
      • 観測可能なシステムは所有と維持が容易で、エンジニアが楽になる
      • エンジニアの幸福度が上がれば離職率も下がり、新規採用コストを下げる事ができる
    • ビジネスニーズの充足と顧客の幸福
      • Observabilityはビジネスを成功させるためのもの
      • 可視性の高いシステムがあれば顧客に必要なものを理解でき、効率よく安全に提供できるようになる
    • 観測性は、コンピュータシステムだけの特性でもなければ、人間だけの特性でもない。
    • Observabilityに関する議論は、装置、ストレージ、クエリなどの技術的な部分にのみ焦点が当てられ、システムが実際にどのように使用されているかについては議論されないことが多い。
    • チームが問題解決のためにツールを使用することに違和感を感じたり、不安を感じたりすると、結果を出すことができない。ツールの品質は、機能の追加が容易かどうか、十分な粒度でデータを取り込むことができるかどうか、人間が発する質問に答えられるかどうか、などの要素によって決まる。
  • Observabilityの品質が影響をもたらすもの
    • システム障害に対して、回復性（resilience）を持たせる
      • Observabilityの質を上げると
        • チーム内にスキルが分散しているので、全員が障害に対応できる
        • 対応不要な偽アラートがなく、ストレスが少ない
        • トレーサビリティの高い監視で問題を迅速に解決できる
    • 高品質なコードをデリバリ
      • Observabilityの質を上げると
        • どこでエラーになったのか容易に確認できる
        • 豊富なテレメトリを提供することでエンジニアはユーザの目に触れる前に修復できる
    • 複雑性と技術的負債の管理
      • Observabilityの質を上げると
        • 障害や遅延の原因を素早く発見できるようになる
        • 勘や推測ではなく最適化すべきコードを特定できる
    • 流れを予測できるリリース
      • Observabilityの質を上げると
        • ビルドやデプロイの問題に早く気づける
        • 新旧のビルドIDを比較することで、コードの変化が意図したものかどうか確認できる
    • ユーザの振る舞いを知る
      • Observabilityの質を上げると
        • イベントドリブンなデータ分析と予測可能なリリースサイクルを構築できる
        • プロダクトマネージャは自分たちの変更がどれだけビジネス目標を達成したか理解し、反復して機能開発できる

Observabilityって結局なんなの？

今も議論されているので明確な定義はないのでしょうが、私個人の見解としては、『仕組みと組織が、「何が起きたのか」というシステムへの問いかけに対してどのくらい答えられるか』ですかね？

ログを集約させたけど誰もみてないとか、無視していいアラートが多いとかっていうケースは割とよくある気がしてて、目的をしっかり持ってツールを入れないとダメだと思ってます。

昔、社内研修用にObservabilityとか監視に関する以下の資料を作った事があるんですが、当時とあまり考えは変わってないのかなという気もしてます。

現在、私の職場ではDatadogを使っています。非常に高機能な製品で文句の付け所がありません。

が、我々の使い方はモニタリングツールとして使っている比率が高くて、障害発生時の調査や分析という使い方が十分出来ているとは思っていません。

だからといって無闇矢鱈とDatadogに集約させると言うよりかは、課題をしっかりと定義して解決策の1つとして使っていけたら良いのかなと思ってます。

Oracle Cloud におけるObservability

Oracle Cloud にはOracle Cloud Observability and Management Platformというものがあります。

www.oracle.com

プレスリリースや紹介記事を見てると

  • マルチクラウドの監視ができる
  • FluentdやGrafana,PagerDutyなどと連携可能
  • マイクロサービスやJava、K8sのトレースが可能

などの特徴があるようです。Javaアプリケーションであればトレース・エクスプローラ で、前述したようなイベントベースの分析が可能になるように思います。

またはResource Managerを使うことで、インフラレイヤのデリバリを高速化出来るかもしれません。

いくら便利なツールがあってもツールはあくまでも組織の加速装置だし、アラートに対して対応するかどうかは最終的には人間が判断する事です。

皆さんも何が課題で、どうやってその課題を解決するのか検討してObservabilityを育てていきましょう。

お読みいただきありがとうございました。