クラウドアプリケーションは、ユーザに高可用性とアクセシビリティを約束するが、それを実現するには、ディザスタリカバリ計画が不可欠である。InfluxDBを支援するチームが、KubeConEU22で、本番環境を削除した日.のディザスタリカバリ戦略を試す戦いから学んだ教訓を共有した。
高可用性、冗長性、ビジネスの継続性はすべて、最近のソフトウェア開発で働くすべての人に馴染みのある言葉である。デジタルトランスフォーメーションの加速は、ほとんどのビジネスが24時間年中無休のスケジュールに移行したことを意味する。私たちが構築した製品は破壊されることはないと信じる傾向がある場合でも、InfluxDBの製品担当副社長のRick Spencer氏の言葉は知っているであろう。
実稼働レベルの災害は遅かれ早かれ発生します。準備ができていることを確認してください。
これは、彼らが把握している通りの真実である。
InfluxDBでは、時系列（タイムスタンプ付きデータ）アプリケーションを構築するためのプラットフォームが提供される。つまり、多くのソフトウェアアプリケーションに対して、データバックボーンが提供される。プレゼンテーションでは、InfluxDBの製品担当副社長のRick Spencer氏と、プラットフォームエンジニアのWojciech Kocjan氏が、その日にあった一連の出来事とそこから学んだ教訓を発表した。
背景
同社は、Kubernetesベースの部分的にステートフルなアプリケーションを実行している。このアプリケーションは、永続化のために基盤となるボリュームとオブジェクトストアを保持するように設定されたPVC（Persistent Volume Claims）のストレージエンジンを備えている。ほとんどのマイクロサービスはステートレスか、マネージドデータベースを使用する。GitOpsの方法に従って、すべてがgitリポジトリに保存され、コードリポジトリと構成リポジトリが分離される。ArgoCDを使うと、InfluxDBクラウドのすべてのインスタンスをデプロイできる。
手遅れだった
すべてのArgoCDアプリケーションがすべて、1つの大規模な設定ファイルに含まれていたため、名前の衝突を特定するのが困難であった。これは、デプロイのターゲットになると、クラスタを削除して再インストールすることを意味する。誤った名前は、central-eu-clusterをターゲットとしていた。
10:22-10:37 UTC: 問題のあるPR（プル・リクエスト）のマージの後、クラスタが削除された。それによって、APIの障害と顧客へのエスカレーションを報告するように監視システムがトリガーされた。これに応じて、サポートチームはインシデント対応プロセスを開始した。
10:42-10:56 UTC: PRを元に戻すと通常の操作を復元できることを示す通常の手順を実施するときに、チームはもっと複雑であることに気付いた。サービスがステートフルで、再デプロイによって新しいボリュームが生成されるためである。復旧計画プロセスが開始され、ステータスページが問題を適切に反映するように更新された。
再構築
11:17 - 15:26 UTC: すぐにデプロイを停止できる「赤いボタン」が押されると、デプロイリストが作成され、ダブルチェックされた。既存のボリュームに依存するすべてのサービスは、状態保持をターゲットとして慎重にデプロイされた。最初は手動で行われ、プロセスが信頼できるようになると、自動化された。ステートレスサービスはCD（Continuous Delivery）によってデプロイされた。並行して、その途中でデータの整合性が検証された。可能な場合には、サービスは再デプロイではなくバックアップから復元された。
サービスが復旧するとトラフィックが急増することを予想して、流入ポイントは積極的にスケールアップされた。
サービスの復旧
15:26 - 16:04 UTC: 書き込みサービスが有効化され、テストされ、機能が検証された。クラスタの過負荷を回避するために、タスクを有効にして失敗させた。タスクが完了すると、クエリサービスが再び有効化された。
その余波で
16:04 UTC 以降: 顧客には、通常の操作モードに戻ること、そしてタスクの失敗と可能な限り復元できるよう支援することが通知された。
RCAは作成され、公開された。
現代の世界では、拡大し続けるデジタルインフラストラクチャはデータによって支えられている。この時代の新しい燃料である。そのため、その重要性はどのビジネスにとっても明らかである。InfluxDBはデータストレージであるため、顧客にとっての継続的な運用の重要性は推測することしかできない。この出来事を振り返ると、同社はそのメカニズムが十分ではないと結論付けた。ダウンタイムはあったが、データは失われなかった。このインシデントの後、チームはこういった種類の変更が早期に検出されるようにするための措置を講じた。基本的なテストツールを使ってYAMLファイルをレンダリングし、重複するリソースを検出する。また、障害の影響を最小限に抑えるために、ファイル構造が変更され、各ファイルに1つのオブジェクトのみが含まれるようになった。また、ArgoCDは、別の名前空間からオブジェクトを変更できないように再構成された。
先回りして策を打つだけでなく、当企業は、停止が万が一発生する場合に備えて、さらに徹底的に準備した。これにより、利用者が影響を受けるインシデントの処理プロセスが改善された。発見されたケースのRunbookが作成され、実行された。
遅かれ早かれ、本番環境の停止を引き起こす何かが起こると想定できる。しかし、その影響を可能な限り最小限に抑え、各インシデントによってチームが強化されるように可能な限り準備するのはあなた次第である。