フォールトインジェクション：システムを破壊しようとしていない場合、システムは信頼できません

こんにちは、Habr！ 私の名前はパベル・リプスキーです。 私はエンジニアで、Sberbank-Technologyで働いています。 私の専門分野は、大規模な分散システムのバックエンドのフォールトトレランスとパフォーマンスをテストすることです。 簡単に言えば、私は他の人のプログラムを壊します。 この投稿では、フォールトインジェクションについて説明します。これは、人為的な障害を作成することでシステムの問題を見つけることができるテスト方法です。 この方法にどのように着手したかから始めてから、方法自体とその使用方法について説明します。









この記事にはJavaの例があります。 Javaでプログラミングしていない場合は、大丈夫です。アプローチ自体と基本原則を理解してください。 Apache Igniteはデータベースとして使用されますが、他のDBMSにも同じアプローチが適用されます。 すべての例は、私のGitHubからダウンロードできます。

なぜこれがすべて必要なのですか？

話から始めましょう。 2005年、私はランブラーで働きました。 その時までに、Ramblerユーザーの数は急速に増加し、2層アーキテクチャの「サーバー-データベース-サーバー-アプリケーション」は対処しなくなりました。 パフォーマンスの問題を解決する方法について考え、memcachedテクノロジーに注目しました。







memcachedとは何ですか？ Memcached-キーによって保存されたオブジェクトにアクセスできるランダムアクセスメモリ内のハッシュテーブル。 たとえば、ユーザープロファイルを取得する必要があります。 アプリケーションはmemcached（2）にアクセスします。 オブジェクトが含まれている場合は、すぐにユーザーに返されます。 オブジェクトがない場合、データベースにアピールが行われ（3）、オブジェクトが形成されてmemcachedに配置されます（4）。 次に、次の呼び出しで、データベースに対してリソースを消費する呼び出しを行う必要がなくなりました。RAMから既製のオブジェクトmemcachedを取得します。



memcachedにより、データベースが著しくアンロードされ、アプリケーションの動作がはるかに速くなりました。 しかし、結局のところ、喜ぶには早すぎました。 生産性の向上とともに、新しい問題が発生しました。







データを変更する必要がある場合、アプリケーションは最初にデータベースを修正し（2）、新しいオブジェクトを作成してからmemcachedに配置しようとします（3）。 つまり、古いオブジェクトを新しいオブジェクトに置き換える必要があります。 この瞬間に恐ろしいことが起こると想像してください-アプリケーションとmemcached間の接続が切断され、memcachedサーバーまたはアプリケーション自体がクラッシュします。 そのため、アプリケーションはmemcachedのデータを更新できませんでした。 その結果、ユーザーはサイトのページ（たとえば、自分のプロファイル）に移動し、古いデータを確認しますが、これが発生した理由はわかりません。



このバグは機能テストまたはパフォーマンステスト中に検出できますか？ おそらく、私たちは彼を見つけられなかったと思う。 このようなバグを検索するために、特別なタイプのテスト-障害挿入があります。



通常、フォールトインジェクションテスト中に、一般にフローティングと呼ばれるバグがあります。 負荷がかかっている場合、システムで複数のユーザーが作業している場合、異常な状況（機器の故障、電気の遮断、ネットワークの故障など）が発生した場合に表示されます。

新しいSberbank ITシステム

数年前、Sberbankは新しいITシステムの構築を開始しました。 なんで？ 中央銀行のウェブサイトからの統計は次のとおりです。







列の緑色の部分はATMでの現金引き出しの数であり、青色の部分は商品およびサービスに対して支払うオペレーションの数です。 キャッシュレス取引の数は年々増加していることがわかります。 数年後には、増大するワークロードに対処し、新しいサービスをお客様に提供し続ける必要があります。 これは、新しいSberbank ITシステムを作成する理由の1つです。 さらに、欧米のテクノロジーと数百万ドルの高価なメインフレームへの依存を減らし、オープンソーステクノロジーとローエンドサーバーに切り替えたいと考えています。



最初に、新しいSberbankアーキテクチャの中心にApache Igniteテクノロジーの基盤を構築しました。 より正確には、有料のGridgainプラグインを使用します。 このテクノロジーにはかなり豊富な機能があります。リレーショナルデータベース（SQLクエリのサポートがあります）、NoSQL、分散処理、RAM内のデータのストレージのプロパティを組み合わせています。 さらに、再起動しても、RAMにあったデータはどこにも失われません。 バージョン2.1以降、Apache Igniteは、SQLをサポートするApache Ignite Persistent Data Store分散ディスクストレージを導入しました。



このテクノロジーのいくつかの機能をリストします。

• RAMでのストレージとデータ処理
  
  
• ディスクストレージ
  
  
• SQLサポート
  
  
• 分散タスクの実行
  
  
• 水平スケーリング
  
  

この技術は比較的新しいため、特別な注意が必要です。



Sberbankの新しいITシステムは、物理的に単一のクラウドクラスターに組み込まれた比較的小さなサーバーで構成されています。 すべてのノードはピアツーピアの構造で同一であり、データを保存および処理する機能を実行します。



クラスター内は、いわゆるセルに分割されます。 1つのセルは8ノードです。 各データセンターには4つのノードがあります。





インメモリデータグリッドであるApache Igniteを使用しているため、これらはすべてサーバーに分散されたキャッシュに保存されます。 さらに、キャッシュは同じパーティションに分割されます。 サーバーでは、ファイルとして表されます。 同じキャッシュのパーティションを異なるサーバーに保存できます。 クラスター内の各パーティションには、プライマリノードとバックアップノードがあります。



メインノードはメインパーティションを格納し、それらに対する要求を処理し、バックアップパーティションが格納されているバックアップノード（バックアップノード）にデータを複製します。



Sberbankの新しいアーキテクチャを設計する際に、システムコンポーネントが故障する可能性があるという結論に達しました。 たとえば、1000台の鉄製ローエンドサーバーのクラスターがある場合、ハードウェア障害が発生することがあります。 RAMストリップ、ネットワークカード、ハードドライブなどは失敗します。 この動作は、完全に通常のシステム動作であると考えます。 このような状況は正しく処理される必要があり、お客様はそれらに気付かないようにしてください。



ただし、システムの障害に対する耐性を設計するだけでは不十分であり、これらの障害中にシステムをテストすることが不可欠です。 有名な分散システムの研究者であるCaitie McCaffreyのMicrosoft Researchが言うように、「障害が再現されるまで、緊急の障害時にシステムがどのように動作するかは決してわかりません。」

失われた更新

簡単な例を見てみましょう。送金をシミュレートする銀行業務アプリケーションです。 アプリケーションは、Apache IgniteサーバーとApache Igniteクライアントの2つの部分で構成されます。 サーバー側はデータウェアハウスです。



クライアントアプリケーションはApache Igniteサーバーに接続します。 キーがアカウントIDで値がアカウントオブジェクトであるキャッシュを作成します。 合計で、10個のそのようなオブジェクトがキャッシュに保存されます。 この場合、最初に各アカウントに$ 100を入れます（転送するものがあるように）。 したがって、すべてのアカウントの合計残高は1,000ドルになります。

CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC); try (IgniteCache<Integer, Account> cache = ignite.getOrCreateCache(cfg)) {   for (int i = 1; i <= ENTRIES_COUNT; i++)       cache.put(i, new Account(i, 100));   System.out.println("Accounts before transfers");   printAccounts(cache);   printTotalBalance(cache);   for (int i = 1; i <= 100; i++) {       int pairOfAccounts[] = getPairOfRandomAccounts();       transferMoney(cache, pairOfAccounts[0], pairOfAccounts[1]);   } } ... private static void transferMoney(IgniteCache<Integer, Account> cache, int fromAccountId, int toAccountId) {   Account fromAccount = cache.get(fromAccountId);   Account toAccount = cache.get(toAccountId);   int amount = getRandomAmount(fromAccount.balance);   if (amount < 1) {       return;   }   fromAccount.withdraw(amount);   toAccount.deposit(amount);   cache.put(fromAccountId, fromAccount);   cache.put(toAccountId, toAccount); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、これら10個のアカウント間で100回のランダムな送金を行います。 たとえば、アカウントAから別のアカウントBに50ドルが振り込まれます。 概略的に、このプロセスは次のように表すことができます。







システムが閉じられ、転送は内部でのみ行われます。 合計残高は1000ドルのままです。







アプリケーションを起動します。





合計残高の期待値-$ 1000。 それでは、アプリケーションを少し複雑にしてみましょう。マルチタスクにしましょう。 実際には、複数のクライアントアプリケーションが同じアカウントで同時に動作できます。 10個のアカウント間で同時に送金を行う2つのタスクを実行します。

 CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC); cfg.setCacheMode(CacheMode.PARTITIONED); cfg.setIndexedTypes(Integer.class, Account.class); try (IgniteCache<Integer, Account> cache = ignite.getOrCreateCache(cfg)) {  // Initializing the cache.  for (int i = 1; i <= ENTRIES_COUNT; i++)    cache.put(i, new Account(i, 100));  System.out.println("Accounts before transfers");  System.out.println();  printAccounts(cache);  printTotalBalance(cache);  IgniteRunnable run1 = new MyIgniteRunnable(cache, ignite,1);  IgniteRunnable run2 = new MyIgniteRunnable(cache, ignite,2);  List<IgniteRunnable> arr = Arrays.asList(run1, run2);  ignite.compute().run(arr); } ... private void transferMoney(int fromAccountId, int toAccountId) {  Account fromAccount = cache.get(fromAccountId);  Account toAccount = cache.get(toAccountId);  int amount = getRandomAmount(fromAccount.balance);  if (amount < 1) {      return;  }  int fromAccountBalanceBeforeTransfer = fromAccount.balance;  int toAccountBalanceBeforeTransfer = toAccount.balance;  fromAccount.withdraw(amount);  toAccount.deposit(amount);  cache.put(fromAccountId, fromAccount);  cache.put(toAccountId, toAccount); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

合計残高は1296ドルです。 顧客は喜ぶ、銀行は損失を被る。 なぜこれが起こったのですか？







ここでは、2つのタスクが同時にアカウントAの状態をどのように変更するかを確認します。しかし、2番目のタスクは最初のタスクよりも早くその変更を記録します。 その後、最初のタスクはその変更を記録し、2番目のタスクによって行われたすべての変更はすぐに消えます。 この異常は、更新の損失の問題と呼ばれます。



アプリケーションが正常に機能するためには、データベースがACIDトランザクションをサポートし、コードがこれを考慮する必要があります。



アプリケーションのACIDプロパティを見て、これが非常に重要である理由を理解しましょう。

• A-原子性、原子性。 提案されたすべての変更がデータベースに対して行われるか、何も行われません。 つまり、ステップ3と6の間に障害が発生した場合、変更はデータベースにあるべきではありません。
  
  
• C-一貫性、整合性。 トランザクションが完了した後、データベースは一貫した状態を維持する必要があります。 この例では、これはAとBの合計が常に同じであり、合計残高が1000ドルであることを意味します。
  
  
• I-分離、分離。 トランザクションが相互に影響することはありません。 一方のトランザクションが振替を行い、もう一方がステップ3からステップ6までのアカウントAとBの値を受け取った場合、彼女はシステムに必要以上のお金がないと考えます。 ここに微妙な違いがありますが、後で詳しく説明します。
  
  
• D-耐久性 トランザクションがデータベースへの変更をコミットした後、これらの変更は失敗の結果として失われるべきではありません。
  
  

したがって、transferMoneyメソッドでは、トランザクション内で送金を行います。

 private void transferMoney(int fromAccountId, int toAccountId) {  try (Transaction tx = ignite.transactions().txStart()) {      Account fromAccount = cache.get(fromAccountId);      Account toAccount = cache.get(toAccountId);      int amount = getRandomAmount(fromAccount.balance);      if (amount < 1) {          return;      }      int fromAccountBalanceBeforeTransfer = fromAccount.balance;      int toAccountBalanceBeforeTransfer = toAccount.balance;          fromAccount.withdraw(amount);      toAccount.deposit(amount);          cache.put(fromAccountId, fromAccount);      cache.put(toAccountId, toAccount);          tx.commit();  } catch (Exception e){      e.printStackTrace();  } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションを起動します。





うん トランザクションは役に立ちませんでした。 合計残高は6951ドルです！ このアプリケーションの動作の問題は何ですか？



まず、ATOMICキャッシュタイプを選択しました。 ACIDトランザクションサポートなし：

 CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.TOMIC);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、txStartメソッドには、enum型の2つの重要なパラメーターを指定できます。これは、ロックメソッド（Apache Igniteの同時実行モード）と分離レベルです。 これらのパラメータの値に応じて、トランザクションはさまざまな方法でデータを読み書きできます。 Apache Igniteでは、これらのパラメーターは次のように設定されます。

 try (Transaction tx = ignite.transactions().txStart( ,  )) { Account fromAccount = cache.get(fromAccountId); Account toAccount = cache.get(toAccountId); ...  tx.commit(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LOCK METHODパラメーターの値として、PESSIMISTIC（悲観的ロック）またはOPTIMISTIC（楽観的ロック）を使用できます。 ブロックの瞬間が異なります。 PESSIMISTICを使用する場合、最初の読み取り/書き込み時にロックが課され、トランザクションがコミットされるまで保持されます。 たとえば、悲観的ロックトランザクションがアカウントAからアカウントBへの転送を行う場合、転送を行うトランザクションがコミットされるまで、他のトランザクションはこれらのアカウントの値を読み書きできません。 他のトランザクションがアカウントAとBにアクセスしたい場合、トランザクションの完了を待たなければならないことは明らかです。これは、アプリケーションの全体的なパフォーマンスに悪影響を及ぼします。 楽観的ロックは他のトランザクションのデータへのアクセスを制限しませんが、コミットのトランザクションの準備フェーズ（準備フェーズ、Apache Igniteは2PCプロトコルを使用）で、チェックが実行されます-他のトランザクションでデータが変更されましたか？ また、変更が行われた場合、トランザクションはキャンセルされます。 パフォーマンスの観点では、OPTIMISTICはより高速に実行されますが、データを使用した競合作業がないアプリケーションにより適しています。



INSULATION LEVELパラメーターは、トランザクションの相互分離の程度を決定します。 SQL ANSI / ISO標準では4種類の分離が定義されており、各分離レベルで同じトランザクションシナリオが異なる結果をもたらす可能性があります。

• READ_UNCOMMITEDは最も低い分離レベルです。 トランザクションは、「ダーティな」コミットされていないデータを見ることができます。
  
  
• READ_COMMITTED-トランザクションが内部で機密データのみを見る場合
  
  
• REPEATABLE_READ-トランザクション内で読み取りが行われた場合、この読み取りは繰り返し可能でなければならないことを意味します。
  
  
• SERIALIZABLE-このレベルは、システムに他のユーザーがいないかのように、最大​​限のトランザクション分離を想定しています。 並列トランザクションの結果は、それらが順番に実行されたかのようになります。 しかし、高度な分離とともに、パフォーマンスが低下します。 したがって、このレベルの分離を慎重に選択する必要があります。
  
  

多くの最新のDBMS（Microsoft SQL Server、PostgreSQL、およびOracle）の場合、デフォルトの分離レベルはREAD_COMMITTEDです。 この例では、失われた更新から保護されないため、これは致命的です。 結果は、トランザクションをまったく使用しなかった場合と同じになります。







Apache Igniteトランザクションドキュメントから、ロックメソッドと分離レベルの組み合わせを使用することが適切です。

• PESSIMISTIC REPEATABLE_READ-データの最初の読み取りまたは書き込み時にロックが課され、完了するまで保持されます。
  
  
• PESSIMISTIC SERIALIZABLE -PESSIMISTIC REPEATABLE_READと同様に機能します
  
  
• OPTIMISTIC SERIALIZABLE-最初の読み取り後に取得されたデータのバージョンが記憶され、コミットの準備段階でこのバージョンが異なる場合（データが別のトランザクションによって変更された場合）、トランザクションはキャンセルされます。 このオプションを試してみましょう。
  
  

 private void transferMoney(int fromAccountId, int toAccountId) { try (Transaction tx = ignite.transactions().txStart(OPTIMISTIC, SERIALIZABLE)) { Account fromAccount = cache.get(fromAccountId); Account toAccount = cache.get(toAccountId); int amount = getRandomAmount(fromAccount.balance); if (amount < 1) { return; } int fromAccountBalanceBeforeTransfer = fromAccount.balance; int toAccountBalanceBeforeTransfer = toAccount.balance; fromAccount.withdraw(amount); toAccount.deposit(amount); cache.put(fromAccountId, fromAccount); cache.put(toAccountId, toAccount); tx.commit(); } catch (Exception e){ e.printStackTrace(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Hooray、予想通り1,000ドルを得ました。 3回目の試行。

負荷下でのテスト

ここで、テストをより現実的にします-負荷の下でテストします。 さらに、サーバーノードを追加します。 ストレステストを実施するためのツールは多数ありますが、SberbankではHP Performance Centerを使用しています。 これはかなり強力なツールであり、50以上のプロトコルをサポートし、大規模なチーム向けに設計されており、多大な費用がかかります。 JMeterでサンプルを作成しました。無料で、問題を100％解決します。 Javaでコードを書き直したくないので、JSR223サンプラーを使用します。



アプリケーションのクラスからJARアーカイブを作成し、テスト計画にロードします。 キャッシュを作成して設定するには、CreateCacheクラスを実行します。 キャッシュが初期化された後、JMeterスクリプトを実行できます。





すべてがクールで、1,000ドルを獲得しました。

クラスターノードのクラッシュ

これで、より破壊的なものになります。クラスター操作中に、2つのサーバーノードの1つをクラッシュさせます。 Gridgainパッケージに含まれているVisorユーティリティを使用して、Apache Igniteクラスターを監視し、さまざまなデータサンプルを作成できます。 [SQLビューア]タブで、SQLクエリを実行して、すべてのアカウントの全体的な残高を取得します。





なに？ 553ドル。 顧客は恐怖に陥り、銀行は評判を失います。 今回は何を間違えましたか？



Apache Igniteにはキャッシュタイプがあります。

• パーティション化-1つまたは複数のバックアップインスタンスがクラスター内に格納されます
  
  
• 複製されたキャッシュ-すべてのパーティション（キャッシュのすべての断片）は1つのサーバーに保存されます。 このようなキャッシュは、主にリファレンスブックに適しています。これはめったに変更されず、よく読まれます。
  
  
• ローカル-1つのノード上のすべて
  
  

データを頻繁に変更するため、パーティション化されたキャッシュを選択し、追加のバックアップを追加します。 つまり、データの2つのコピー（プライマリとバックアップ）があります。

 CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); cfg.setCacheMode(CacheMode.PARTITIONED); cfg.setBackups(1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションを起動します。 送金前に1000ドルを持っていることを思い出してください。 開始し、操作中にノードの1つを「消す」





Visorユーティリティでは、SQLクエリを作成して合計残高1000ドルを取得します。 すべてがうまくいきました！

信頼性の事例

2年前、新しいSberbank ITシステムのテストを開始しました。 どういうわけか私たちはエスコートエンジニアに行き、「何が壊れるのか」と尋ねました。 彼らは私たちに答えた：すべてが壊れる可能性があり、すべてをテストする！ もちろん、この答えは私たちに合わなかった。 私たちは一緒に座って、障害統計を分析し、発生する可能性が最も高いケースがノード障害であることを認識しました。



さらに、これはまったく異なる理由で発生する可能性があります。 たとえば、アプリケーションがクラッシュしたり、JVMがクラッシュしたり、OSがクラッシュしたり、ハードウェアに障害が発生したりします。







考えられるすべての障害事例を4つのグループに分けました。

1. 装備品
   
   
2. ネットワーク
   
   
3. ソフトウェア
   
   
4. その他
   
   

彼らは彼らのためにテストを考え出し、信頼性のケースと呼んだ。 一般的な信頼性のケースは、テスト前のシステムの状態の説明、障害を再現する手順、および障害中の予想される動作の説明で構成されます。

信頼性のケース：機器

このグループには、次のようなケースが含まれます。

• 停電
  
  
• ハードドライブへのアクセスが完全に失われる
  
  
• 1つのハードドライブアクセスパスの障害
  
  
• CPU、RAM、ディスク、ネットワーク負荷
  
  

クラスターには、各パーティションの4つの同一コピー（1つのプライマリパーティションと3つのバックアップパーティション）が格納されます。 ハードウェア障害のためにノードがクラスターを離れるとします。 この場合、メインパーティションは他の生き残っているノードに移動する必要があります。



他に何が起こるでしょうか？ セル内のラックの損失。







セルのすべてのノードは異なるラックにあります。 つまり ラック出力は、クラスター障害やデータ損失につながりません。 4つのコピーが3つあります。 ただし、データセンター全体が失われたとしても、大きな問題にはなりません。 4つのデータのコピーがまだ2つあります。



一部のケースは、サポートエンジニアの支援を受けてデータセンターで直接実行されます。 たとえば、ハードドライブをオフにし、サーバーまたはラックの電源をオフにします。

信頼性のケース：ネットワーク

ネットワークの断片化に関連するケースをテストするには、iptablesを使用します。 そして、NetEmユーティリティを使用してエミュレートします：

• 異なる分布関数によるネットワーク遅延
  
  
• パケット損失
  
  
• パケット再試行
  
  
• パケットの並べ替え
  
  
• パケット歪み
  
  

私たちがテストしているもう1つの興味深いネットワークケースは、スプリットブレインです。 これは、クラスターのすべてのノードが動作しているときですが、ネットワークセグメンテーションのために、それらは互いに通信できません。 この用語は医学に由来し、脳は2つの半球に分かれており、それぞれが独自のものであると考えています。 クラスタでも同じことが起こります。





データセンター間で接続が失われることがあります。 たとえば、昨年、掘削機による光ファイバーケーブルの損傷により、トチカ銀行、オトクリティー銀行、ロケットバンク銀行の銀行の顧客は数時間インターネット上で取引を行わず、端末はカードを受け入れず、ATMは機能しませんでした。 この事故について多くのことがTwitterで書かれています。



この場合、スプリットブレインの状況は正しく処理されるはずです。 グリッドはスプリットブレインを識別し、クラスターを2つの部分に分割します。 半分は読み取りモードになります。 これは、より多くの生きているノードがあるか、コーディネーターが配置されている半分です（クラスター内で最も古いノード）。

信頼性のケース：ソフトウェア

これらは、さまざまなサブシステムの障害に関連するケースです。

• DPL ORM-Hibernate ORMなどのデータアクセスモジュール
  
  
• モジュール間トランスポート-モジュール間のメッセージング（マイクロサービス）
  
  
• ロギングシステム
  
  
• アクセスシステム
  
  
• Apache Igniteクラスター
  
  
• ...
  
  

ほとんどのソフトウェアはJavaで記述されているため、Javaアプリケーションに固有のすべての問題が発生しやすくなります。 さまざまなガベージコレクター設定をテストします。 クラッシュJava仮想マシンでテストを実行します。



Apache Igniteクラスターの場合、オフヒープの特別なケースがあります-これはApache Igniteが制御するメモリ領域です。 Javaヒープよりもはるかに大きく、データとインデックスを格納するように設計されています。 ここでは、たとえば、オーバーフローをテストできます。 オフヒープをオーバーフローさせ、一部のデータがRAMに収まらない場合のクラスターの動作を確認します。 ディスクから読み取ります。

その他の場合

これらは、最初の3つのグループに含まれないケースです。 これらには、重大な事故が発生した場合、またはデータが別のクラスターに移行された場合にデータを回復できるユーティリティが含まれます。

• データのスナップショット（バックアップ）を作成するためのユーティリティ-完全および増分スナップショットのテスト。
  
  
• 特定の時点への回復は、PITR（Point in-time recovery）メカニズムです。
  
  

障害挿入のためのユーティリティ

私のレポートの例へのリンクを思い出させてください。 Apache Igniteディストリビューションは、公式サイトApache Apache Ignite Downloadsからダウンロードできます。 そして、あなたが突然このトピックに興味を持つようになった場合、Sberbankで使用しているユーティリティを共有します。



フレームワーク

• ジェプセン
  
  
• カオス猿
  
  

構成管理：

• アンシブル
  
  
• 人形
  
  

Linuxユーティリティ：

• NetEm（tc）
  
  
• ストレスng
  
  
• Iperf
  
  
• キル-9
  
  
• iptables
  
  

負荷テストツール：

• Jmeter
  
  

現代世界とSberbankの両方で、すべての変更は動的であり、今後数年間でどのテクノロジーが使用されるかを予測することは困難です。 しかし、Fault Injectionメソッドを使用することは確かです。 この方法は普遍的です。あらゆる技術のテストに適しています。実際に機能し、多くのバグをキャッチし、開発する製品を改善するのに役立ちます。