InfoQ ホームページ chaos-engineering に関するすべてのコンテンツ
-
障害モードとレジリエントなシステムの構築 - Adrian Cockcroft氏のQCon SFでの講演より
Adrian Cockcroft氏は先頃、障害発生時においても正常に運用できるレジリエントなシステムの構築方法について、自身の考えを公開した。氏は先日のQCon San Franciscoでも、継続的レジリエンスの考え方を備えたシステム構築において望まれる、クラウドのレジリエンスパターンについての私見を述べている。
-
どうやってうまくいっているのか？Netfixが教える、インシデントからの学び方 - QCon New YorkでのRyan Kitchens氏の講演より
QCon New Yorkで、Ryan Kitchens氏が、"How Did Things Go Right? Learning More from Incidents"と題して講演した。主なポイントは次のとおりだ。リカバリは予防に優る； インシデントは"最悪の状況"が起きた時に発生するのであるから、根本原因(root cause)というものは存在しない; ユーザの幸福が何より重要である; システムがうまくいっている理由を知ることには大きな価値がある。
-
Solo.ioがサービスメッシュハブとカオスエンジニアリングツールを発表
クラウドネイティブソフトウェア企業のSolo.ioは、業界初となるサービスメッシュハブをローンチした。このハブは、ハイブリッドおよびマルチクラウド環境へのサービスメッシュテクノロジの導入を支援するリソースとして、Istio、Linkerd、Envoy、AWS App Mesh、HashiCorp Consulといったツールを提供する。
-
Chaos Community Day v4.0要約 - レジリエンス、可観測性、ゲームデー
今年初め、第４回の"Chaos Community Day"が、ニューヨーク市のWork-Benchで開催された。当日の重要ポイントは次のようなものだ — カオスエンジニアリングのトピックは他の分野に大きく依存しており、ソフトウェアエンジニアはそこから学ぶこともできる。システムを理解し、コミュニケーションし、関連するメンタルモデルを交換することは、レジリエンス確立のために不可欠である。
-
LitmusフレームワークによるKubernetesのカオスエンジニアリング
Litmusは、ステートフルなアプリケーションを実行するKubernetes環境のための、オープンソースのカオスエンジニアリングフレームワークだ。MayaDataの開発したこのフレームワークは、テストスイートの実行、ログのキャプチャ、レポートの生成、カオステストの実行を可能にする。
-
レジリエンスの源を強化する - QCon LondonにおけるJohn Allspaw氏の講演より
QCon Londonで、John Allspaw氏が、"Amplifying Sources of Resilience: What Research Says"と題したプレゼンテーションを行った。要点は次のようなものだ — レジリエンスはシステムが持つ(has)ものではなく、システムが行う(do)ものである。組織内で"適応能力(adaptive capacity)"を創出し維持することは、レジリエンスのある行動だ。サプライズに人々がどのように対処するかについて学ぶことは、レジリエンスの源を見つけるための道である。
-
カオスエンジニアリングと可観測性 - Russ Miles氏に聞く
O'Reillyの新しいレポート "Chaos Engineering Observability: Bringing Chaos Experiments into System Observability"では，筆者のRuss Miles氏が，可観測性とカオスエンジニアリングは"密接に関連している"と考える理由が論じられている。エンジニアがカオス試験を実施する場合には，試験の対象とする下位システムに関して多くの問いかけをする必要が生じるはずだ，と氏は主張する。
-
Russ Miles氏の講演より - 無視されるアーキテクトとカオスエンジニアリング
先日アムステルダムで開催されたEvent-Driven Microservices Conferenceで、Russ Miles氏は、アーキテクトにとって最大の課題は無視されることだ、と主張した。イベント駆動マイクロサービスのような優れたアイデアを持っていても、確かに素晴らしい、だが現状のニーズには複雑過ぎる、という反応をされることが多過ぎるのだ。
-
Netflixから“しなやかさ"を学ぶ - カオスエンジニアリングを論じたQCon NYでのHaley Tucker氏の講演より
QCon New YorkでHaley Tucker氏は、“UNBREAKABLE: Learning to Bend but Not Break at Netflix”と題して講演し、Netflixでのさまざまな役割を担当して学んだカオスエンジニアリングの経験について論じた。おもな内容は次のとおりだ - 障害分離のための機能シャーディング(functional sharding)の使用、RPC呼び出しの継続的なチューニング、小さなイテレーションでのカオス試験の実施、”カオスの原則”の適用。
-
LinkedInのカオスエンジニアリング - "LinkedOut"障害注入テストフレームワーク
LinkedIn Engineeringチームが先日、自らの“LinkedOut”障害注入テストフレームワークについて説明した。サービスのレジリエンスに関する仮説を構築し、LinkedInのA/BテストフレームワークであるLiXや、Invocation Context(CI)フレームワークを使用したコールスタックを通じて渡されるクッキー内のデータを介して、 障害トリガを注入することができる。障害シナリオにはエラー、遅延、タイムアウトなどがある。
-
カオスエンジニアリングによるAPIの回復力の向上
Gremlinチームは、組織のAPIが回復力があることを検証する方法として、シンプルなカオス実験を説明した。「game days」（ITシステムや人々のための消防訓練）を実行するように、カオス工学と技術の原則を使うことで、この新興領域で商用およびオープンソースのツールを適切に使えるようになるという価値を提供することができる。
-
レジリエンスなシステムはなぜ必要なのか - QCon LondonでTammy Butow氏がカオスエンジニアリングを論じる
Tammy Butow氏はQCon Londonで講演し、よりレジリエントなシステムが求められている理由と、それがカオスエンジニアリングのプラクティスによっていかに実現されるかを説明した。講演ではカオスエンジニアリングのための３つの主要な前提条件 -- 重要度の高い“SEV”インシデントの管理、監視、及び影響度の測定 -- が提示され、ガイドラインとツール、プラクティスが紹介された。
-
BloombergがKubernetes用のオープンソースのカオステストツール“PowerfulSeal”をリリース
先日のKubeCon North Americaカンファレンスで、Bloombergがオープンソースの“PowerfulSeal”ツールを新たに公開した。対象となるポッドと基盤のノードインフラストラクチャを停止させることで、Kubernetesクラスタ内でのカオステストを可能にするツールだ。
-
Twillioにおけるカオスエンジニアリング
Twilioチームがカオスエンジニアリングへの進出について説明している。Gremlinを使って自社製のキューシステムの一部に障害を注入し、自動回復のテストを行なう。
-
Expediaにおけるサイトのレジリエンス向上への取り組みとカオステストの導入 - QCon SFでの講演より
QCon SFにおいて、Sahar Samiei、Willie Wheeler両氏が“Expedia's Journey Toward Site Resiliency”と題したプレゼンテーションを行い、Expediaでのレジリエンステストに関するプラクティスのコミュニティ構築について論じた。結果は概ね望ましいものだった – 運用システムでは5月15日以降、NetflixのChaos Monkeyが毎日実行されるようになり、４つのTier 1サービスパイプラインにレジリエンステストが追加された。