SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？（2/2 ページ）

[新野淳一，ITmedia]

計画的に障害に備えよ

　なぜこういったことが可能だったのか？ われわれは計画的に障害に備えており、またKubernetesのような複雑なインフラへの移行は徐々に行っており、しかも社内には積極的に学ぶカルチャーが存在していたためだ。

　具体的には、Spotifyにおいて当時Kubernetesの利用はまだβ段階であったため、各チームには全面的なKubernetesへの移行ではなく、部分的な移行を推奨していた。

　さらにサービスディスカバリ機構はKubernetesのものではなく社内のものを使ってPodのIPアドレスを指していたため、Kubernetesクラスタが失われたときにはそのIPアドレスを削除してサービスディスカバリを再起動することにより、すぐに非Kubernetesのインスタンスへのフェイルオーバーが可能となった。

まとめ

　大事なことは、障害に備えてクラスタをちゃんとバックアップしておくこと。リストアのテストをしていないバックアップは、バックアップの意味を成していない。

　そしてインフラのコード化を進めること。ただし新しいツールの導入は徐々に行うこと。

　さまざまな状況を想定した複数のディザスターリカバリーテストを行うこと。

　社内には、失敗したときに人を責めるのではなく、そこから学ぶという文化を創ること。私がクラスタを削除したときでさえ、Spotifyのチームは私をサポートしてくれた。

　そしてようやく先週から、われわれもサービス全体をKubernetesへ移行する準備ができて、その作業を進め始めたところだ。