Magnolia Tech

いつもコードのことばかり考えている人のために。

『オブザーバビリティ・エンジニアリング』で学ぶ”既知の未知”と、”未知の未知”との付き合い方

2023/2/4 書名のコピペをミスって間違っていました…直しました

すいません>各位


オブザーバビリティィィィィィイ!!!!!

なんか必殺技の名前っぽいですよね、オブザーバビリティ。

リング状のエネルギーが放出されて、回転しながら相手を切り刻むイメージです。


そんなことはサテオキ

この現代、バラバラに設計された、断片的な情報しか教えてくれないアプリケーションログと、よく分からない閾値に基づいた監視メトリクスと、設計意図の分からないダッシュボードと、運用メンバの経験と勘で運用するのは限界があるよなーというのは、全システム運用者の共通の課題認識ではないでしょうか。

そんな課題へのヒントがあればなーと思って、『オブザーバビリティ・エンジニアリング』を読みました。


第一部のハイライトは、5〜6ページにかけて並べれた質問のいくつかの質問。

例えば、以下のような質問が挙げられている。

  • あなたのソフトウェアを使う任意の特定のユーザーが、任意の時間に体験していることを理解できるか?

確かにすぐに答えられないかもしれない。どの質問も改めて聞かれると、「頑張って調べれば分かるかもしれないけど、そんな観点で調べることを考えたこともなかった」ということに気づくと思います。


本書は、システム構成や、アプリケーションコードがどんどん複雑化する中、従来のモニタリングによる「既知の未知」だけでなく、オブザーバビリティという概念を導入することによって「未知の未知」への対応力を高めていきましょう、ということが解説された、包括的なオブザーバビリティに関する解説書です。

一般的に「従来の監視」では、モニタリングツールが計測するメトリクスに対する閾値チェックか、アプリケーションやミドルウェアのログを「ERROR」などのキーワードチェックでシステムに問題が発生していないかを計測してきました。

そこから、例えばアクセスログから応答時間の変動や、一歩進んで各種データ量の増減傾向(「このタイミングでこのデータはゼロ件のはずだ」「この日程が終わる頃には、○○件以上のデータが蓄積されているはずだ」等)の計測結果を使った監視が追加されていくこともあるかもしれません。

みんな可視化のために頑張ってきた、いろんな工夫を加えてきた……ただ、この手の個別に作り込まれた個々のアプリケーション固有の振る舞いに関する計測方法は、最初から設計に組み込まれるというより、発生したインシデント等のフィードバック(いわゆる再発防止!!なぜなぜ!!)に基づいて追加されるものだったり、決して包括的なものでもないし、網羅的なものでもないことが多かったりしませんか、どうですか。

じゃあこの複雑化した、色々なサービスや、コンポーネントが絡みあうプロジェクトに対してはどうしますか、何かできることは有りますか?という疑問が湧いた時に、「オブザーバビリティ」というキーワードが出てきた……という話に本書ではなっていくのだけど、正直第I部は概念的な話とかモニタリングの問題点といった話が続き、「うーん、で、どうやってそれが実現されるの?」という、ハテナが続く状態で読み進めていたのだけど、第II部の具体的な方法論へ突入し、構造化イベントの概念、構造化イベントを繋ぎ合わせるトレースの考え方、そしてOpenTelemetryを使った標準化……と、ここに来てようやく腹落ちしたというか、ようやく”オブザーバビリティ”というものが何か見えてきた……気がする。

なお、OpenTelemetryについては、下記のサイトが非常に参考になりました。

opentelemetry.io

syu-m-5151.hatenablog.com

やっぱり何でも動く実装を見ることが大事ですね。

標準化されていることで、例えばJavaの実装の例では、以下のサイトに紹介されたようなライブラリやフレームワークはあらかじめ自動的に構造化イベントを取得する方法が用意されているとのこと。

github.com


第Ⅲ部は、組織としてオブザーバビリティ・エンジニアリングを実践していくための考え方、事例などが紹介されています。まぁ、ここは必要ですけど、その前にとりあえず動かせるものは動かして、手に馴染ませるのが大事かな、と思った。


従来のログが「点」を表現するものであり、その「点」と「点」をどうやって結びつけていくのかが解析の腕の見せどころだったのに比べて、構造化イベントは最初から「線」を表現することを目指していて、今度は「線と線から面へ」という、より先に進んだ解析ができるようになる訳で、そりゃ確かになーという気持ちと、「で、果たして既存のアプリケーションが既にたくさん積み上がっている中、どこから手をつけていくのか?」ということを考えさせれる1冊でした。

テーマがより深いアプリケーションの挙動の可視化と、振る舞いへの理解、なので、当然一定以上の複雑さを持つシステムじゃないとあまり恩恵も無いだろうし、実感も湧かないと思うので、いきなりこの本だけ読んで本質が理解できる訳ではなく、きっかけに過ぎないけど、それでも改めて自分たちの課題へ向き合うヒントとして、凄く学びの多い内容だった。

まずは、OpenTelemetryの言語別の実装を触ってみるところから始めてみます。


そういえば、”テレメトリー”という単語、その前に読んだ『はやぶさ2のプロジェクトマネジャーはなぜ「無駄」を大切にしたのか?』にも繰り返し出てきた。

blog.magnolia.tech

二日連続で”テレメトリー”という単語が出てくる本を読んでた。どんだけ監視と運用が好きなんだ。

—-

その後、考えたことを追記

『はやぶさ2のプロジェクトマネジャーはなぜ「無駄」を大切にしたのか?』は、マネジメントと、運用と、監視が語られた1冊だった

人に「こんな本を読んでいる」とか、「この本が凄く面白かった」と聞くとなるべくすぐに買って読むようにしている。

はやぶさ2」プロジェクトのプロジェクトマネージャーである津田雄一さんが、プロジェクトの立ち上がりから、地球へサンプルを持ち帰るまでの一連の出来事を、プロジェクトマネジメントの視点で書かれた1冊。

タイトルにある「無駄」というキーワードはあまり出てこなかったけど、繰り返し出てきた「想定外を想定する」は運用をする上は本当に大事なことだと自分も常日頃思っていたことなので、凄く共感できた。

また、地球からコマンドを発行しても、届いて結果が返ってくるまで何十分もかかる環境の中で、得られるフィードバックを元に次の一手を考えていく様は「メトリクスを監視すること」の大切さがよく分かる。

あとはやはりメンバに対する機会を与える姿勢と、繰り返される訓練は、先を見据えて組織を作っていくプロジェクトマネージャーにとって一番大事な視点なんじゃないかと。


本屋でこの本を見かけても買うことはなかっただろうなーと考えると、やはり人に紹介してもらった本はまずは読んでみるって姿勢はアリだなーと、改めて実感した。

「不確実性」に向き合う人たちの気持ちを考える

現代のソフトウェア開発のプラクティスは、「複雑なこと」と「不確実なこと」にどうやって対応していくか?というテーマを元に進化を続けている。

そのうち「不確実なこと」に関しては、そのリスクを可視化し、分解していって、それぞれの要素に対する打ち手の数を増やすことと、そのフィードバックに対するレスポンスの速さを支えるプロセスや、ツールの議論が盛んに行われている。

一方で、それを扱う「人」は果たしてそれに対応できているのか?という疑問がある。

上記のツイートのリプライや、引用RTにはさまざまな意見が集まっているのだけど……組織文化によってはリスクを挙げることそのものがタブーみたいなところもあったりと、リスクへの許容度というものは組織文化によるところが大きいし、個々の人の性格的な側面も大きい。また、経験や、教育、立場や裁量によっても変わってくる。

特に答えが有る話ではないけど、結局こんなことをぼんやりと考えていた、という記録のエントリでした。

『継続的デリバリーのソフトウェア工学』...ソフトウェア工学とは何か?

書名の「継続的デリバリー」はCI /CDの解説書かな?とも思わせてしまうので若干ミスリードなんだけど、「工学とは何か?」「ソフトウェア工学とは何か?」「工芸と工学は何が違うか?」ということを解説した1冊。

本書を通じて語られているのは、ソフトウェア開発においていきなり正解に一発で辿り着くことはなく、下記の5つの考え方を実践していく必要がある、という点です。

  • 反復的な作業
  • フィードバック
  • 漸進主義
  • 実験主義
  • 経験主義

前半は、それらがいかに大事な考え方であるかを一つ一つ事例を交えながら解説が続いていきます。ウォーターフォールと、アジャイルの対比のあたりは、ちょっと「悪い事例の見本としてのウォーターフォール」に偏りすぎじゃない?とは思いましたが、極端な事例を対比させることで論点を際立たせる手法だと捉えておくとよいかな、と思いました。

後半は、ソフトウェアの複雑性と戦うための指標としての

  • モジュラー性
  • 凝集度
  • 関心の分離
  • 情報隠蔽と抽象化
  • カップリング(結合度)の管理

といったキーワードへの解説が行われます。

テスト駆動開発や、ドメイン駆動設計も当然のように出てきます。


主に考え方や、概念、振る舞い、といったことと、それがどのような背景から由来するものか、というところに焦点が当てられている内容なので、具体的なツールの解説や使い方にフォーカスすることを期待しているとちょっと違うかも、と思われるかもしれません。一人で読んで考える、というより読書会などで色々な人の考え方を聞いて、良いプラクティスを理解した上で現実の課題にどうアプローチすべきか、ということを考えるきっかけにすると良いですね。


途中で出てきた「私の友だちのなかには、読めるPerlを書ける人さえいます。」というくだりは笑ってしまった...普通書けないことが前提になっていますね、これ...

Atermの「DHCP固定割当エントリ」設定時には、DHCPサーバの「割当数」の範囲内のIPアドレスを選ぶ

相関チェックくらいしてくれよー、と思ったけど、引っかかったのでメモ

au ひかりのホームゲートウェイは、NECAtermが使われている。

DHCPで、IPアドレスmacアドレスを元に固定設定する場合は、「DHCP固定割当エントリ」のページでmacアドレスIPアドレスをセットで設定する。

この時、使用できるIPアドレスの番号帯は、「IPアドレスDHCPサーバ設定」の「DHCP」の「割当数」の範囲内に収まる必要が有る。

自動設定にしておくと、64個が割当数になっているので、192.168.0.65までが利用できる範囲。

うっかり、65を超える数字、例えば100とかを設定しても無視される。

以上、メモでした。

『マスタリングLinuxシェルスクリプト 第2版』、こういう1冊手元に有るとずっと使える本はちゃんと買っておきたいですね

令和最新版のシェルスクリプトの入門書とリファレンスがセットになった1冊。手元に置いておくと安心感ありますよね。

令和最新版なので、冒頭からデバッグしたいならVisual Studio Code がオススメ、と出てきます。

コンテナ使おうと思ったらシェルスクリプトの読み書きの出番がどんどん増えていって、コンテナに一番必要なスキルはシェルスクリプトのスキルでは?と思っている今日この頃です(違います)が、そのくらいの用途に必要な要素は全部盛り込んであり、シェルスクリプトの文法と実践的な使い方に加えて、一緒に利用されることの多いgrepawksedといったコマンドの解説も併せて載っています。

とりあえず手元に置いておくと便利。

あ、あと訳註がやたらと充実していて、痒いところに手が届く補足がめちゃめちゃ多いので、翻訳書にありがちな「書いた通りには動かない、条件が変わっている」みたいなところが無いところも本書のおすすめポイントです。


ちなみに本書も最後の章は「bashスクリプトの代わりとしてのPython」という内容で締めくくられていて、もうそこはPerlじゃないんだよなーって思いました、マル。

ケーブル類の収納にはジッパーバッグがおすすめ

長年の間に増え続けたたくさんのケーブル類のストック、要らない訳ではないけど、すぐに出番もない。そしてどれがどれだか、どこに何があるのかわからなくなる。

ケーブル類の収納はジップロックとか、ジッパーバッグに入れて分類するのが良い、という記事を以前見かけたので、やってみました。

こんな感じでジャンルごとに分けてバッグに入れて、箱の中に縦で入れておくとごちゃっとした感じが無くなって、良い感じですね。

ジッパーバッグ

1〜2mくらいの、柔らかめのケーブル(USBとか、DisplayPortとか、HDMIとか、LANケーブルとか)であればA4サイズがちょうど良いようです。

硬めのディスプレイケーブルだと1本で一つのバッグ、柔らかめのUSBケーブルとかだと2〜3本入れるぐらいがまとまります。

薄型のDVDドライブや、小型のUSB充電器なども、硬めのバッグだと型崩れせずに、縦に収納できるところがオススメのポイントです。

中身が見えづらいので、透明なものも探したんですけど、硬めで良さそうなものがなかったので、メッシュで硬めのものをAmazonで探して購入しました。

ジップロックを使う案も有りましたけど、上手く綺麗に縦に収納できなさそうなので、そちらは止めました。

というわけで、ケーブル類の収納にはジッパーバッグがおすすめ、というエントリでした。