読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェアにおけるアンチフラジャイルとレジリエンス

気になったキーワード「アンチフラジャイル」について調べてみた。また類似の概念「レジリエンス」との違いについての現時点の理解とそれについて思ったこと。
fragile

アンチフラジャイル

自分がこのキーワードを知ったのはInfoQの記事なのだけれども、Qiitaにも整理された記事があったので、あわせて読んだ現時点での理解は以下の通りである。

いやぁ、文章としてはある程度理解できるような気がするけれども、具体的なイメージがまったく沸かないぞ・・・

アンチフラジャイルを目指すために必要なこと

個人的な印象で書くのだけれども、「アンチフラジャイル」なシステムを目指すのであれば次のような事を意識していく必要があるのだと理解している。

  • まず大前提として「レジリエンス」なソフトウェアであり、突発的な問題が発生したとしても最低限の安全性は担保できるようにする必要がある。簡単にサービスが停止してしまうような脆弱な(フラジャイルな)ソフトウェアが一足飛びに抗脆弱性(アンチフラジャイル)を得ることは難しいだろう。
  • 次の段階として、発生するさまざまな問題に対してスピーディに改善、改良を繰り返すことが出来るようにする必要がある。これは近年話題のDevOpsといったキーワードで語られている事柄と関連していて、継続的に改良・改善を繰り返していくための仕組みづくりが必要なのだろう。ただ、これが実現した状態がアンチフラジャイルな状態か、というとまだ足りない印象がある。
  • では何をするのか。さらに強制的・高速・大量の失敗を注入することによって改善改良を繰り返すことによって、アンチフラジャイルな状態に移行していくのではないか、というのが現時点の理解。

こういった考え方は、アンチフラジャイルとセットで語られることの多いNetFlixのカオスエンジニアリングの事例などをが参考になるようだ。

任意のサーバのシャットダウンやプロダクション環境のデータセンター全体のシャットダウンをシミュレーションしてきた経験に基づいて、NetflixがChaos Engineeringの原則を提案している。 NetflixはChaos Engineeringを「プロダクション環境の過酷な状況に耐えられるというシステムの能力に自信を持つため、分散システムで実験するという規律」だと定義している。コントロールされた実験でシステムの振る舞いを観察することにより、プロダクションシステムの弱点が望ましくないやり方で現れる前に見つける必要があると、Netflixは述べている。

またタレブは、ティンカリング (ブリコラージュ) あるいは試行錯誤の結果、イノベーションという良いブラックスワンが起こると指摘しています。もちろん、その際には数多くの失敗をしますが、その失敗のコストは小規模かつ予測可能な範囲に収めます。これを Taleb は「凸状のいじくり回し (convex tinkering)」と呼びます。予測可能な損失の範囲で試行錯誤しながら、ポジティブなほうに凸になるところをいじくりながら探すわけです。それは運にまかせるということではなく、一回の失敗ごとに学びや追加の情報が発生して、徐々に「どこに行くか」が分かる試行錯誤です。

話に聞くところによると、 マイクロサービスアーキテクチャに言及があるようで、これは未読なので早く読んでみたい。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

あとこちらは邦訳版は出ないのかなぁ・・・

Antifragile: Things That Gain from Disorder (Incerto)

Antifragile: Things That Gain from Disorder (Incerto)