開催概要: https://websystemarchitecture.hatenablog.jp/entry/2019/02/26/100725

自分の発表

とくに手持ちの実装や実装構想といったものがなかったため、最近よく考えていたカオスエンジニアリングについての整理を試みた。Netflix による “Chaos Engineering” ペーパーでは、すでにカオスエンジニアリングと同じようなことを Google や Amazon といった企業はすでにやっていることを知っていてそれをカオスエンジニアリングと名付けたと書いてある。その起源は明らかに「レジリエンス」のキーワードに関係していて、レジリエンスエンジニアリングという体系化された学問があることを知った。

レジリエンスエンジニアリングを調べてみると、最近の Web サービスにおける信頼性の考え方、SRE のエッセンスの一部が Safety-II で説明できることが分かった。カオスエンジニアリングはレジリエンスエンジニアリングから来ているかもしれない、というのが直感的に思ったことではあったが、その間には SRE の存在があることは、カオスエンジニアリングの概念が流行する前には SRE の概念の流行があったことを踏まえて自分の中で腑に落ちた。

カオスエンジニアリングに関連する文章でしばしば目にしていた「アンチフラジャイル」が気になったので反脆弱性という本を読んでみた。自分にはまったくなかった考え方が文章で鮮やかに説明されているのを見て感動を覚えるのは久しぶりのことだった。何もしなくても Web システムが平然と動き続けるというのは自分の理想の世界で、そのイメージはポストアポカリプス的な作品で登場する、人類の存在がなくなっても動作し続けるロボットのようなものである。そのように動き続けるためには、レジリエント性だけでは難しいと思っていたなかで、生物には生来備わっているとされる「反脆い」という性質はキーになり得るのではないかと思った。一方で、人類が創造するシステムは、自然の模倣によって進化してきているとある程度言うことができると思っており、自然の限界が人類の限界になってしまうのではないかという漠然とした喪失感も若干感じるようになった。

発表後の議論では、ありがたい意見をいくつかいただいた。概念の説明だけではそもそも議論にならないのではないかという危機感があったものの、そんなことは全くなく、参加者の知識の幅広さ・フィールドの広さを感じた。まず安全工学で語られるフェールセーフやフォールトトレラントという性質はレジリエンスエンジニアリングで語られる Safety-II と本質的な違いがあるかどうかについて。これは自分でも疑問に思っていたことで回答はできなかった。ただ様々な分野から、安全についてまとめられた「セーフウェア」という文献が参考になりそうなことを学んだ。次に反脆いシステムのためには多様性が必要であることについて、リスク分析では多様性を分散として計測することを教えていただいた。そもそもレジリエンスという言葉は様々な学問で登場するようだ。次に多様性によって事故を回避しても「強く」なっているとは言えないのではないか、という指摘。自分は個と組織の視点で分けて考える必要があり、多様性によって弱い種が息絶えることは逆に言えば強い種が生き残ったことになる、と説明した。議論の中で、Web システムだけでなくそれをつくる組織まで広げて考えると、障害を乗り越えていける体制をもつ「反脆い」組織は存在できる、という説明がされた。この説明は最初に自分が考えていたことだった。しかしそれでは結局「機械」だけでは自律できていないことになり、自分の理想とは異なるため別の説明をしたかった。「反脆さ」はまだまだ知ったばかりの概念で、もっと自分で噛み砕いていかないといけない。

他人の発表

月並みだがどの発表も興味深かった。とくに印象的だった2つの発表について書く。

@hirolovesbeer さんのログの分散処理の構想は、最近自分が考えたことに近かった、ので印象的だった。文脈は少し違うのだけど、short-term なログをすばやく見れる方法を考えていた中でのアイディアの1つだった。具体的にはコンテナインスタンスにいる Fluentd のファイルバッファを使い、クライアントがコンテナがいるホストを特定してそのファイルバッファを読みにいくという方法。「ホストを特定して」はディスカバリの問題がある。最近はサービスメッシュの概念が浸透してきて (昔にも似たような構想はいくつかあったというのは知らなかった) ログに対してもそれを使うという説明だった。サービスメッシュはサービスディスカバリの問題、サービス間通信のオブザバビリティの問題、通信設定が分散する問題を全部ひとまとめに解決している、という認識だったために、サービスメッシュと一言で言ってしまうと違和感があったが、サービスディスカバリの上に立つサービスメッシュをもっと色々な場所で活用していくといった発想は今後必要になる気がした。

次に @nari_ex さんの発表。Linux 上でコールドデータとホットデータをいい感じに取り扱う実装の構想。Linux の FUSE や LKM の機能、また SPDK など自分にとっては知らないことがたくさんあって、それを組み合わせるという実装で、オンプレでもクラウドでも使える OSS として実装したいという背景目的も含めて面白いと思った。クラウド時代になってストレージの自由度が低下している、という説明は考えたことがなかったが確かにとも思った。これは自分がストレージをまったくやってこなかったせいかもしれない。自分は仕事の都合上わりと AWS 脳であるために、S3, S3 Standard IA, Glacier を使うと一瞬でできそうだとも思ってしまったが、背景と目的の説明はかなり納得した。

おわりに

参加者を見直してみると研究所の方や大学の研究者ばかりで、客観的に見てかなりレベルの高いことになっている。実際にも議論の質は高いと思う。一企業のソフトウェアエンジニアがこういう場に参加できるのはエキサイティングである一方で、アウトプットへのプレッシャーは高い。学生枠 (?) で第一回に参加していなかったら、そのプレッシャーからその後も参加することはなかったかもしれない。雑に誘ってくれた @yuuki1 さんにはとにかく感謝している。モチベーションになることは間違いないので、プレッシャーをいい方向に働かせていきたい。