銀行破綻とリトマスカオスを用いた克服

おい、皆さん、このブログでは、私は銀行関連の失敗について話します、そして、どのように我々は彼らをLitmusChaosを使って克服することができますか。

銀行破綻に出くわしたことがありますか.
モバイルバンキングのアプリは、今日のために、例えば、どこからでも快適さから預金を預けることができます.同時に、あなたのバランスを確認することができます、転送資金、およびあなたが支店を訪問する必要がなくあなたのアカウントをオーバードラフトする場合に通知するための通知を設定します.これは、リアルタイムの節約です!
しかし、同時に、銀行のサーバーがダウンしているか、接続が遅い場合は、あなたのアカウントにアクセスすることができなくなりますし、トランザクションが通過したかどうかを知るのは難しいでしょう.

以下のトピックを一つずつやります。

Bank Of Anthos とLitmusカオスとの関係

バンクオブアントス

リトマス入門

注入カオスと観測結果

結論、参照、およびリンク.

Anthos銀行について

Bank of Anthos は、銀行の支払い処理ネットワークをシミュレートするサンプルのHTTPベースのWebアプリケーションです.
Googleはどのように開発者は、GCPの製品を使用して企業のアプリケーションを近代化することができますデモをするには、このアプリケーションを使用します.
アントス銀行の建築
LitmusChaosで、我々は働いていて、我々の実験をテストしましたBank Of Anthos アプリケーション.カオス実験は、実際のカオスの詳細を含んでいます.
我々は2つのシナリオ:弱いと弾力性があります.それに基づいて、我々は実験の作業負荷を実行し、原因に影響を見つけることを試みる.
このワークフローは、2つのバージョンのbank-of-anthos deployment : 弱いものは弾力的なものが成功する間、失敗すると予想されます.

リトマス入門

リトマスは、チームが制御された方法でカオステストを誘導することによってチームの弱点と潜在的停電を特定するのを可能にするオープンソースのカオス工学プラットホームです.
開発者とSresは、現代のカオス工学の実践とコミュニティのコラボレーションに基づいて、使いやすいようにリトマスでカオス工学を実行することができます.リトマスは100 %オープンソース＆CNCF主催です.
リトマス雲を作成し、管理し、カオスを監視するネイティブのアプローチを取る.
カオスは、次のKubernetesカスタムを使用して調整されます
リソース定義( crds ):

ChaosEngine:KubernetesアプリケーションまたはKubernetesノードをChaos実験にリンクするリソース.Chaosengineは、カオス実験を呼び出すカオス演算子によって見られます.

Chaos実験カオス実験の構成パラメータをグループ化するための資源Chaos実験CRSは、実験がChaosEngineによって呼び出されるとき、演算子によって作成されます.

ChaosResultカオス実験の結果を保持する資源カオス輸出者は結果を読んで、メトリックを構成されたPrometheusサーバーに輸出します.

ハブにカオス実験を行う.リトマスカオス.入出力それは、アプリケーション開発者、ベンダーが彼らのカオス実験を共有する中央ハブです.そして、彼らのユーザーが生産のアプリケーションの回復力を高めるために彼らを利用することができます.

注入カオスと観測結果

Pod-network-loss ネットワーク接続を中断するカオスを注入balancereader & transactionhistory Kubernetesポッド.
ワークフローが完了すると、アプリケーションポッドは健康であるべきです.カオスにも関わらずサービスリクエストを送ればよい.この実験はリトマスを使用してパケット損失を注入することによってアプリケーション複製へのアクセスの損失を引き起こします.
ネットワークの損失はbalancereader or transactionhistory から読むledger DB そして、弱いシナリオでのマルチレプリカとしてではなく、単一のレプリカ展開として実行します.損失のために.balancereader and transactionhistory が失敗した場合にはアクセスできない.
単一のレプリカ展開では、ユーザーがすることはできません-詳細を参照してください詳細を追加または情報を取得します.一方、2つの展開では詳細を追加することが可能です.The balancereader or transactionhistory 詳細を追加することができます提供API経由で取得します.

プローブのチェック

HTTPプローブでは、開発者は、実験/使用状況(またはその他のカスタム条件)を入力/終了条件の一部として測定するために使用するURLを指定できます.受信したステータスコードは、期待されたステータスに対してマップされます.これは.spec.experiments[].spec.probe , Chaosengineの中の経路
HTTPプローブを再度使用していますhttp://frontend.bank.svc.cluster.local:80 をプローブpoll間隔で1秒とする.
HTTPプローブを再度使用しています“http://frontend.bank.svc.cluster.local:80” プローブポーリング間隔1秒で.

- name: "check-frontend-access-url"
  type: "httpProbe"
  httpProbe/inputs:
    url: "http://frontend.bank.svc.cluster.local:80"
    insecureSkipVerify: false
    method:
      get:
        criteria: "=="
        responseCode: "200"
  mode: "Continuous"
  runProperties:
    probeTimeout: 2
    interval: 1
    retry: 2
    probePollingInterval: 1

弱いシナリオでは、podの1つのレプリカだけが存在します.カオス注入の後、それはダウンします、したがって、アクセシビリティはそこにありません、そして、結局、それはフロントエンドアクセスのために失敗します.

弾力的なシナリオでは、ポッドの2つのレプリカが存在します.カオス注入の後、1つがダウンします.したがって、1つのPODはアクセシビリティのためにまだ上にあります、そして、フロントエンドアクセスのためにまだ通過するでしょう.

プローブはアクセシビリティの変更のためのタイムアウト時間を再試行します.終了時刻がアクセシビリティなしでタイムアウトを超えた場合、失敗します.

リトマス入口

Litmusポータルは、管理、監視、およびイベントのカオスワークフローの周りコンソールとUIの経験を提供します.カオスワークフローは、アプリケーションまたはKubernetesプラットフォームにフォールトを導入する目的を達成するために一緒に実行する一連の実験から成ります.

マニフェストを適用する

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/2.0.0-Beta9/docs/2.0.0-Beta/litmus-2.0.0-Beta.yamlインストールが完了したら、カオスコントロールプレーンと定義済みのワークフローのすべての部分を探索することができます.

閉じるこの動画はお気に入りから削除されています.

オープンBank of Anthos 詳細を得るために定義済みのワークフロー.

コントロールプレーンを使用してワークフローをスケジュールするには、オプションを選択します.

YAMLを編集し、アプリケーションの配備を見ることができます

 - name: install-application
      container:
        image: litmuschaos/litmus-app-deployer:latest
        args:
          - -namespace=bank
          - -typeName=resilient
          - -operation=apply
          - -timeout=400
          - -app=bank-of-anthos
          - -scope=cluster

ここでは、弱いアプリケーションのインストールステップでは、変更することができます-typeName=weak その結果、単一のレプリカです.
注:あなたがChoosEngineの正しいDocker経路を通過したことを確認してください.
デフォルト

名前: SocketLandパス
値:/var/run/docker.靴下

ワークフローを継続してスケジュールしましょう.

ワークフローの実行が完了した後、ネットワークの損失に失敗したことがわかります.

これは、クロスチェックすることができますUIを使用して.http://<frontend-host>:portNo

我々は、我々が我々のバランスをチェックすることができない現実世界シナリオでこれを見ることができます.

では、ワークフローを再度スケジュールしましょう

我々は、アプリケーションがネットワークの損失の後でさえ通過したのを見ることができます.レプリカの高い入手可能性のため、プローブが通過しました.

はい、バランスがあるし、ログを見ることができますChaos Results それ以下.

あなたはそれの下にログとカオスの結果を見ることができます.

結論

我々は簡単に議論したBank Of Anthos resilience 定義済みワークフローBank Of Anthos アプリケーションの弾力性とそのLitmusChaosとの関係が示されている.
ワークフローはAnthos弾力性ワークフローの導入銀行で議論されました.LitmusChaosでは、我々は継続的に働いていると我々の実験アプリケーションをテストします.
異なった定義済みワークフローとKubernetesワークフローの間で、我々の第3の定義済みのワークフローはAnthos弾力性チェックの銀行です.
最後まで読んでくれてありがとう.私はあなたがLitmusChaosについての生産的な時間を学んだことを願っています.あなたはsreまたはkubernetes愛好家ですか?カオス工学はあなたを興奮させるか?
参加LitmusChainコミュニティスラックチャンネル#litmus チャンネル登録者https://slack.k8s.io/ ) スラック!

参照とリンク

Slack
LitmusChaos
Litmus ChaosHub
Github Repo Litmus
Connect with us on Slack
chaos-charts
必要な変更を確認する場合はプル要求を送信します.
これらのリソースを共有することを忘れないでください誰かを学ぶに役立つ/カオス工学についての詳細を探る必要があります.