Russ Miles氏の講演より - 無視されるアーキテクトとカオスエンジニアリング

先日アムステルダムで開催されたEvent-Driven Microservices Conferenceで、Russ Miles氏は、アーキテクトにとって最大の課題は無視されることだ、と主張した。イベント駆動マイクロサービスのような優れたアイデアを持っていても、確かに素晴らしい、だが現状のニーズには複雑過ぎる、という反応をされることが多過ぎる。スケーリングや冗長性やフォールトトレランスの面から、非同期イベント駆動システムを検討すべきだと主張すると、決まってこのような反応がある、と氏は言う。企業にとっては概ね妥当な主張のはずだが、無視される場合がほとんどなのだ。

Miles氏の最大の目標は、信頼できるシステムの構築にある。氏の考える信頼性とは、顧客が望むものの尺度であり、フューチャーリッチで常に稼働しているシステムのことだ。これはまた、特に複雑なシステムに対して、共存が容易ではない２つの相反する力が存在するということでもある。すなわち、継続的なイノベーションと変革であり、常に稼働するシステムである。

Miles氏によると、アーキテクトにとって最も困難なのは、レジリエントなシステムを構築していることを誰もが理解できるようにすることである。特に氏が強調するのは、これがテクノロジだけの問題ではないという点だ。人々と彼らのプラクティス、それを取り囲むプロセスまでを含むものがシステムなのだ。これをすべて考慮した時、氏は、システムが運用できるというのは小さな奇跡だ、と考えている。

Miles氏はレジリエンスの定義として、John Allspaw氏の言葉を引用している。冗長性やレプリケーション、分散などを多く備えたシステムを構築すれば、堅牢なシステムは実現できるだろう。しかし、Allspaw氏の言うレジリエンスでは、それに人々が加わっている。同じように、カオスエンジニアリングは単なるツールではない – 人々がシステムをどう考え、どのようにアプローチするかという問題なのだ。

Miles氏の考えるカオスエンジニアリングとは、発生する前に障害を発見するテクニックであると同時に、その考え方でもある。

• システムダウンを無駄にしてはいけない。障害が起きた時は、そこから学ぶのだ。
• 死に瀕した場合の態度を決めておくこと。システムダウンから学ぶことは可能だが、事前に弱点を調べておく方がより望ましい。
• 協力的であること – 他人のシステムに実験を仕掛けてはならない。何を学びたいのかを皆が事前に知り、それに同意する必要がある。
• ひとつの実験から小規模に始めること。システムが無事ならば、次にはスコープを増やすことが選択肢になる。
• 自分の頭を使って、まずは手作業で始めること。ツールを使った自動化に着手するのはその次だ。

Miles氏にとって、カオスエンジニアリングで唯一かつ最も大切なことは、自身がシステムを担当するチームの一員でなければならない、ということである。システムを棄損して、誰かが修復してくれるのを待つような立場であってはならない。自分が行なったことに影響を受けるひとりとして、他の人たちと協力して修正に当たる必要がある。Miles氏はこれまで、仕事としてシステムを棄損する人たちのグループを持つ企業を見てきたが、氏の経験から言えば、この方法は機能しない。

Miles氏は内心、カオスエンジニアリングは単純なものだと考えている。学ぶべきプラクティスは２つだ、認定プログラムは必要ない、と氏は強調する。

• Game Days – すべてのチームが集まり、全員が合意可能な運用条件の変更を行なって、その対処方法を確認する。多くのチームの時間を要するため、Game Daysは費用が高くなる可能性がある、と氏は指摘する。
• 自動カオス実験 – 実験を自動化することで、弱点の継続的な探索と調査を行なうことが可能になる。

自分の会社にカオスエンジニアリングの作業を始める体制が整ったならば、Miles氏の最初のアドバイスは、カオスという言葉は一切使用するな、というものだ。何かを壊すということは口に出さず、発生したインシデントや、そこから何を学び、改善できたのか、を話題にするのだ。あなたは今や、システムを段階的に、よりレジリエントにするための学習ループの中にいるのだ、と氏は指摘する。

自身の主張を要約するものとして、Miles氏は、“カオスクラブ”の中から従うべきいくつかのルールを指摘した。

1. カオスについて話さないこと。概念として以前よりもメインストリームになったとはいえ、この言葉には依然として人々を驚かせる可能性がある。周りの信頼をもっと得てから、その言葉を使うようにしよう。
2. 壊さずに学ぶこと。やろうとしているのは、ユーザより先に弱点を見つけ出して対処することであり、社会システムと技術システムの全体を改善することなのだ。
3. カオスは驚きであってはならない。
4. システムが棄損すると分かっている時は、実験をしないこと。新たな弱点を見つけようとする前に、すでに分かっている弱点の修正にトライしよう。

イベント駆動マイクロサービスをベースとするシステムを開発する場合、最も難しいことのひとつは、運用段階でのよい市民になる方法を開発者に理解させることだ。その中には、システムが健全であると宣言するために適切なエンドポイントの状況を知っておくことと、状態がOKかどうかを伝えるための正しいタッチポイントを用意することも含まれる。優れたログはその重要な一面である。これを改善する方法としては、例えばGame Daysで、システムの挙動をログを通じて知らなければならないような場合に、開発者が自身のログを読むことなどがある。

カオスエンジニアリングを行う場合、イベントソースシステムのひとつの利点として、それが実現している可観測性がある。Miles氏にとっての可観測性とは、運用中のシステムを変更しなくてもデバッグが可能であるということだ。何らかの形でカオス試験を行なっているのであれば、最初にやりたいと思うのは、問題点を把握するためにシステムをデバッグすることだろう。イベントソースシステムには記録システムがあるので、何がいつ起きたのかを正確に知ることができる。

Miles氏は結論として、自身のキャリアの中で初めて、ベストプラクティスがあると述べている。我々が今日構築している、複雑で、おそらくはカオスなシステムにおいて、カオスエンジニアリングは氏が“やってみるべきだ”と言えるテクニックだ。まずは少し、手操作で、Game Dayなど可能な日に試してみよう。システムの信頼性やレジリエンスが心配ならば、まさにあなたのためのツールだ、と氏は確信している。