コンテンツ
出典：pressureUA / iStockphoto
取り除く：
最新のシステムは、ダウンタイムを回避するために混乱を処理できなければなりません。そのため、システムを徹底的にテストし、復元力を確保することがこれまで以上に重要になっています。
それらを回避するための最大限の努力にもかかわらず、ITインシデントは仕事の避けられない部分です。そして、ビジネスに影響を与えるダウンタイムを先取りしようとすることは、より巧妙になりつつあります。今日のシステムは緊密に結合され、ますます複雑になっています。可動部品が増えると、物事がうまくいかなくなる可能性が高まります。
これが、ますます多くの組織がサービスの可用性を高め、障害に対する回復力を高めるためにマイクロサービスに目を向けている理由の1つです。しかし、これらはモノリシックアプリケーションを破壊するための大きな前提ですが、回復力を念頭に置いて明示的に設計されていない限り、障害のリスクを潜在的に悪化させる可能性もあります。
失敗の準備
分散システムには本質的に混oticとした性質があるため、サービスは障害を予測するだけでなく、障害が発生した場合に自動的に回復するように開発する必要があります。つまり、定期的に障害を引き起こして、エンドユーザーへのサービスを中断することなくシステムが混乱を処理できるようにします。これを実現するには、テスト環境で本番のようなトラフィックをシミュレートする機能が必要です。
もちろん、変更が実稼働環境に反映される前に、復元力をテストすることをお勧めします。これを行わないと、サービスが平均負荷とピーク負荷の両方をサポートできることを確認できません。実際、最も安全な方法は、スケールアップせずに製品が最大2倍のピーク量を処理できるようにすることです。
復元力テストに関しては、適切なツールは、リクエストの処理方法についてあまり気にするべきではなく、最終的に正しい影響を与えるだけです。特定の条件下では、入力サービスはシステムの他の部分へのリクエストのハンドオフに失敗する可能性がありますが、失敗を報告できないことに注意してください。エンドツーエンドの検証が実際に行われていることを確認することにより、監視のレーダーの下で飛行する問題を危険にさらさないでください。 （詳細については、「技術の失敗：それらと共存できますか？」を参照してください）
次のステップ
負荷がかかった状態でのサービスの動作を理解したら、障害イベントの導入を開始します。すべてのソフトウェアテストと同様に、さまざまなインフラストラクチャテクノロジーに影響を与える複雑なイベントを調整できるように、シナリオを簡単かつ迅速に再現できる自動化ツールを用意することが最善です。また、サービスの修正や変更を検証する機能を超えて、これにより、任意の環境およびスケジュールでランダムな障害シナリオを実行できます。
意味のある障害イベントは、主にサービスのレイアウトに依存します。関連する特定の質問をすることで、それらを策定できます。たとえば、データベースが一定の期間到達不能になった場合、フロントエンドを使用しているユーザーにとってどのような影響がありますか？それらのユーザーは引き続きWeb UIを操作できますか？引き続き情報の更新を発行できますか？データベースが再び到達可能になったときに、それらの更新は正しく処理されますか？
複数のマイクロサービスを実行している場合、個々のサービスがクラッシュした場合にグローバルな停止があるかどうかを尋ねることができます。または、サービス間の通信をバッファリングするキューイングメカニズムがある場合、コンシューマサービスが動作を停止するとどうなりますか？ユーザーは引き続きアプリケーションで作業できますか？平均的な負荷が与えられた場合、キューがオーバーフローしてsを失い始めるまでにどれくらいの時間がかかりますか？
バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド
誰もソフトウェアの品質を気にしない場合、プログラミングスキルを向上させることはできません。
インフラストラクチャに関するいくつかの重要な質問を定義したら、それらの障害をシミュレートするさまざまな方法のリストを開始できます。特定のサービスまたはデータベースサーバーを停止するだけで十分な場合があります。サービスのメインスレッドをブロックして、デッドロックをシミュレートし、そのコンテナーがまだ応答し、実行されている場合があります。特定のサービス間のトラフィックをブロックするために、ネットワークにルールを導入することを決定する場合があります。 Linux環境では、「tc」などのツールを使用して、高遅延、ドロップ、破損、または重複したパケットなどのネットワーク状況をエミュレートできます。 （テストにユーザーを関与させることが重要になる場合があります。エンドユーザーがUATの前にテストに参加する必要がある4つの理由について詳しくお読みください。）
ドリルによる学習と改善
障害シナリオを作成する上で最も価値のある側面の1つは、システムが障害を起こす可能性のあるすべての方法を公開できることです。これにより、自己修復ロジックへの道が切り開かれます。チームは、サービスを手動で回復する手順を実行します。SLA内でこれを実行できることを確認するための素晴らしいドリルです。この回復プロセスの自動化に取り組むことはできますが、それまでの間は、サービスを軌道に戻すプロセスをチームが経験したことを簡単に知ることができます。障害シナリオをランダムかつ定期的にし、実行の詳細を完全に公開しないことにより、SLAの重要な部分であるドリルに発見と診断を含めることもできます。
カオスエンジニアリングは、その中核として、システムの複雑さを与えられたものとし、新しい奇抜な条件をシミュレートしてテストし、システムがどのように応答するかを観察します。これは、データエンジニアリングチームがシステムを再設計および再構成して、より高い復元力を実現するために必要なものです。新しい有用なことを学ぶ機会はたくさんあります。たとえば、ダウンストリームサービスが変更されてもサービスが更新されない場合や、監視が完全に欠落している場合があります。製品の弾力性と堅牢性を高めるエキサイティングな方法がたくさんあります！