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

計画的に障害に備えよ

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

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

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

まとめ

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

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

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

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

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

この記事の著者

関連記事

• 

  「君、今日からクラウド担当ね」　未経験者が1人で始めた、ファミマのAWS移行の舞台裏

• 

  「この虫の名は？」すぐ解決　20万匹の害虫画像を学習した、駆除を支える「クラウド×AI」がスゴい

• 

  ラーメン屋・幸楽苑、店長の「シフト作成」をクラウド活用で自動化へ　「バイト入れる？」と聞く手間省く

• 

  PayPay“100億円祭”の裏側で何があったのか　システム障害と苦闘したエンジニア