SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？（1/2 ページ）
この記事は新野淳一氏のブログ「Publickey」に掲載された「SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？」（2019年7月8日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。
2019年5月20日から3日間にわたりスペイン バルセロナで開催されたKubeCon＋CloudNativeCon Europe 2019の基調講演では、SpotifyがミスによってKubernetesのクラスタを消去してしまった経験を振り返るという非常に興味深いセッション「Keynote: How Spotify Accidentally Deleted All its Kube Clusters with No User Impact - David Xia」（基調講演：SpotifyはいかにしてKubernetesクラスタの全削除というミスにもかかわらず顧客への影響を引き起こさなかったのか？）が行われました。
障害が起こることをあらかじめ計画としてインフラの構築にどう反映させるのか、そして堅牢なシステムはどのような企業文化から生まれるのか、といった点を学べるセッションになっています。
本記事ではその内容をダイジェストで紹介しましょう。
SpotifyはGoogle Kubernetes Engineを採用
Spotifyのインフラエンジニア、David Xia氏。
Spotifyは音楽をストリーミングサービスとして提供しており、10億人以上のユーザーがサブスクリプションしている。1000人以上のデベロッパーが1万以上の仮想マシンを基盤に開発している。
インフラはGoogle Cloud Platformを利用しており、Kubernetesの基盤としてGoogle Kubernetes Engine（GKE）を利用。
米国、欧州、アジアの3つのリージョンにそれぞれKubernetesの本番クラスタを構築。各クラスタは1時間ごとにバックアップが実行される。
誤ってKubernetesの米国クラスタを削除
2018年、私はGKEの機能をテストするため、本番クラスタと同じ機能を持つテストクラスタを作成して操作していた。
このとき、Webブラウザのタブを複数開いており、あるタブはKubernetesの本番クラスタ、別のタブはKubernetesのテスト用クラスタを操作するためのものだった。
テストが終わったあと、テストクラスタを削除するつもりで、操作するタブを間違って本番クラスタのタブでクラスタの削除を行ってしまう。
GKEはとても操作が簡単で、簡単にKubernetesクラスが作れる。同様に、簡単にKubernetesを削除できる。そして削除をはじめたらその処理を止める方法はない。
失われたクラスタを再作成するには手作業が必要で、しかも手順がちゃんとマニュアル化されておらず、スクリプトにもバグがあったことなどが影響して、3時間15分かかった。
再びKubernetesのクラスタを削除、今度は2つも削除
約1カ月後、われわれはクラスタ作成をコード化することでこうした問題が再び起こることを防ごうと、Terraformを導入した。
これによってクラスタの作成をコード化し、バージョン管理や変更時のレビューなどが可能になる。
しかしこれが原因で、こんどは1つならず2つのクラスタを失うことになるのだ。次にその話をしよう。
Terraformはクラスタの状態をファイルに保存する仕組みを備えているが、使い始めのころはまだそうした挙動に詳しくなかった。
あるエンジニアがクラスタ定義の動作を確認するためレビュービルドを行ったところ、知らないうちにクラスタの状態を示すファイルが書き換わってしまい、これを本番用のコードにマージしてしまった。
それを本番クラスタに適用したところ、本番クラスタからアジアリージョンが失われてしまった。
アジアクラスタを再構築するべく、Terraformのスクリプトをローカルで動作確認したのちに本番環境で実行した。しかしローカル環境では気付かなかった、本番環境でのパーミッション不足があり、その結果、動作不良によりわれわれは米国リージョンのKubernetesクラスまで失うこととなった。
3つある本番用Kuberntesクラスタのうち、2つまでの同時に失ってしまったのだ。
ユーザーから障害が影響したというレポートはまったくなかった
この障害によってエンジニアチームは、非Kubernetesベースの仮想マシンを多数立ち上げることとなり、それにあわせてインフラチームは古いIPアドレスベースで記述されていた部分を全てアップデートするといった作業に追われた。
しかし幸いにも、この障害によってユーザーになにか影響があったという報告はまったくなかった。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
こんなメディアも見られています
ITmedia NEWSに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
SpecialPR
本日の新着記事
アクセスランキング
-
1
なぜ酒蔵の許諾なしに？ 「VTuberコラボ日本酒」騒動、主催者が経緯説明 仲介者による調整で「準備進んでいると認識」
-
2
かっぱ寿司「配布前のコラボグッズ、フリマで買わないで」 プリキュアコラボ発表日に注意喚起
-
3
「食事量は1日1200kcal以下、でも肥満」な人を14日間追跡調査 痩せない理由は……米コロンビア大などの研究
-
4
本物そっくり“AI生成レシート“が経費精算の脅威に マネフォ「自力で見破るのは難しい」 企業はどう備える？
-
5
「菜の花がおかしい」――イラストレーター制作うたうマラソン大会ポスターに指摘相次ぐ 事務局がAI使用明かす【訂正あり】
-
6
「ペンギンを返して」→「3匹全部採用して」 批判殺到のSuica新キャラ、ファンアートが空気を変えた？ SNSの声
-
7
藤井風のリサイタル、公式サイトがインターネット老人会すぎると話題 公民館のチラシみたいだけど東京ドーム開催
-
8
「iPhone Duo」純正ケース話題、「面白いけど高い」……1万4800円と2万4800円
-
9
「ランジェリーパープルじゃない」「買おうと思ってたのに」 iPhone 18 Pro／Pro Maxの色に落胆の声
-
10
松本デジタル相、24.6万件漏えい可能性について説明 「既知の脆弱性を対応前に悪用」
ITmedia NEWS SNS
@itmedia_newsをフォロー
インフォメーション
注目情報をチェック
ITmediaNEWSをフォロー
あなたにおすすめの記事PR