グリーンなソフトウェア開発

第10章. モニタリング

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

信頼できない人間は誰の友でもない。

イドリース・シャー、リフレクションズ

かつて、チャックと呼ばれた製品があった。それはとてもよくできていて、当然ながら99.9999％の稼働率を誇っていた。 (そう、彼はいつでもどんなリクエストにも対応できるように準備万端だったのだ！）。

チャックはプロダクション・ランドで停止時間や障害とは無縁の平穏な生活を送っていた。ある日、いつものようにプロダクション・アベニューを散歩していると、突然、接続が途切れるような感覚に襲われ、歩道に座り込んだ。チャックは考えた。私はついに倒れてしまったのだろうか？

チャックはかつての非常に遠い記憶のネットワークに障害が起きていたのか！？

チャック・イン・プロダクション・ランド」はおとぎ話ではない。「チャビー」という名のGoogle製品が、非常によくアーキテクトされ、信頼性が高いことが証明されたために、ユーザに誤った安心感を与えてしまったという現実の話である。 彼らは、Chubbyが決してダウンすることはないと信じ込み、宣伝され、観測され、監視された可観測性をはるかに超えて、Chubbyへの依存度を高めてしまったのだ。

ユニコーンが神話上の生き物であり、存在しないことは誰もが知っている。Chubbyがインシデントに直面することはほとんどなかったが、それでも時折インシデントが発生し、下流サービスに予期せぬ（そしてさらに重要なことに、予定外の）中断をもたらした。

Googleにとって、この一角獣のようなシナリオに対する解決策は、宣伝している稼働時間に見合うだけの頻度で、意図的に自社のシステムをダウンさせることだった。それによって、Chubbyが可用性を上げすぎないようにし、ユーザを二度と誤った安心感に誘わないようにしたのだ。

この話の教訓は、製品の可能な限り高い可用性を追求することは、エキサイティングで大胆なエンジニアリングの問題を克服することかもしれないが、見過ごすことのできない負の結果もあるということだ。ユーザによる過度の依存だけでなく、ソフトウェアによる二酸化炭素排出も含まれる。

チャックの話を続ける前に、可用性の定義と、なぜ技術界が可用性を賞賛するのかについて時間を割く必要がある。その後、基本に戻り、モニタリングの理由と方法について検討し、少し回り道をして、SREが従来のモニタリングではマイクロサービスの世界では不十分だと考える理由について議論する。最後に、本題だ。我々は可観測性について簡単に調査し、それが技術における持続可能性とどのように適合するかを検討する。こうすることで、グリーン・ソフトウェアの実践者として、ますます複雑化する分散システムの世界についていくことができる。

私たちは、ソフトウェア・システムの二酸化炭素排出量のモニタリングは、それ自体（つまり章）に値すると確信している！検討すべき材料や比較対照すべきツールがまだ圧倒的に多いからではなく、環境に配慮することがDevOpsやSREの確立された領域とどのように統合されるかについて、技術専門家が早い段階から考え始めることが最も重要だからだ。

カーボン・エミッションのモニタリングを考える際には、車輪を再発明するのではなく、業界標準に従うことが重要なのだ。

北極星としての可用性

システムの可用性とは、そのシステムがいつでも意図された目的を果たせるかどうかということである。 ...