InfoQ ホームページ Resilience に関するすべてのコンテンツ
-
可観測性を使って迅速なリリースを実現する
迅速なフィードバックを得るためには、高い頻度で、準備が整えば即座にリリースし、自動化システムを使って変更をライブにテストすることが必要だ。正常に動作していること、警告が発生していないことの検証には、監視機能が使用できる。迅速なリリース(shipping fast)は結果的にテスト回数を削減し、問題に対するレジデンスを向上することになる。
-
障害モードとレジリエントなシステムの構築 - 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)"を創出し維持することは、レジリエンスのある行動だ。サプライズに人々がどのように対処するかについて学ぶことは、レジリエンスの源を見つけるための道である。
-
構成可能なレジリエンスポリシを備えたFailsafe 2.0がリリース
障害処理を目的とした依存度ゼロのJavaライブラリであるFailsafeが、バージョン2.0をリリースした。レジリエンスポリシ構造に加えて、独自のポリシサービスプロバイダが可能なプラグインアーキテクチャをサポートする。
-
Spring Cloud、プラガブルなサーキットブレーカインタフェースを発表
Spring Cloudのインキュベーターは、プラガブルなサーキットブレーカーインターフェースを提供するSpring Cloud Circuit Breakerと呼ばれる新しいプロジェクトを導入した。これはシステムが早期にエラーを発生し、連鎖的な失敗とシステムの過負荷を防ぐのに役立つ。
-
カオスエンジニアリングと可観測性 - Russ Miles氏に聞く
O'Reillyの新しいレポート "Chaos Engineering Observability: Bringing Chaos Experiments into System Observability"では，筆者のRuss Miles氏が，可観測性とカオスエンジニアリングは"密接に関連している"と考える理由が論じられている。エンジニアがカオス試験を実施する場合には，���験の対象とする下位システムに関して多くの問いかけをする必要が生じるはずだ，と氏は主張する。
-
レジリエントなサーバレスシステムの設計と構築 - QCon Londonでの John Chapin氏の講演より
QCon London 2019で行ったプレゼンテーションで，John Chapinは，サーブレステクノロジの基本と，レジリエントなサーバレスシステムの設計と構築を行う方法について解説した。さらに氏は，世界規模で分散された高可用性アプリケーションを構築し，AWS上の複数リージョンで運用する，というデモも披露した。
-
Russ Miles氏の講演より - 無視されるアーキテクトとカオスエンジニアリング
先日アムステルダムで開催されたEvent-Driven Microservices Conferenceで、Russ Miles氏は、アーキテクトにとって最大の課題は無視されることだ、と主張した。イベント駆動マイクロサービスのような優れたアイデアを持っていても、確かに素晴らしい、だが現状のニーズには複雑過ぎる、という反応をされることが多過ぎるのだ。
-
レジリエントなアーキテクチャを実現する方法
スケールするシステムを管理するには限界ぎりぎりまでシステムを追い込んでも、回復できるようにする必要がある。そして、障害を受け止めることも必要だ。Adrian Hornsby氏はふたつのブログ記事で、自身の10年以上にわたる大規模システム運用の経験と発見したパターンを共有している。
-
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)フレームワークを使用したコールスタックを通じて渡されるクッキー内のデータを介して、 障害トリガを注入することができる。障害シナリオにはエラー、遅延、タイムアウトなどがある。