KubeCon + CloudNativeCon Europe 2019参加レポート：CERNによるKubernetesを使ったヒッグス粒子のシミュレーションと、Spotifyの障害復旧話

こんにちは！

SREチームでコンテナやパブリッククラウドを使ったインフラの構築や運用などを行っている@_inductor_です。スペインのご飯が美味しすぎて日本に帰るのがつらい気持ちになっています。

本記事は、5月20日から23日にかけて行われているKubeCon + CloudNativeCon Europe 2019（以下KubeConまたはKubeCon EUと表記します）の参加レポートです。

昨年12月にシアトルにて開催されたKubeCon NAの様子についてはこちらの記事をご覧ください。

今回のKubeCon EUはスペインのバルセロナで行われ、およそ8000人が参加しています。昨年のコペンハーゲンでは4000人超程度だったので、その倍の参加者数です！
また、前回のKubeCon NAでは参加者が8000人（+2000人程度のキャンセル待ち）だったため、規模感としてもアメリカに引けを取らない程度の規模であることが伺えます。

このペースで増えていった場合、14年後には日本の全員が、20年後には地球上のすべての人類がKubeCon参加者になる見込みです。

KubeConではキーノート、セッション含め数多くの内容について話されますが、今回は僕が個人的に興味のあった2つのキーノートについてまとめてご紹介します。

Reperforming a Nobel Prize Discovery on Kubernetes - Ricardo Rocha, Computing Engineer & Lukas Heinrich, Physicist, CERN

1つめに紹介するキーノートは、CERNのエンジニアによる「ヒッグス粒子の発見をKubernetes上で再現する話」です。

CERNについて

CERNはスイスにある世界最大の素粒子物理学の研究所で、宇宙の起源や形などを探ると言った理由でさまざまな基礎研究を行っている研究機関です。

ITの文脈においては、CERNはWebの起源でもあります。
CERNの研究者であるティム・バーナーズ・リーが論文を公開するために考案したのがWWW（HTTP）で、CERNの中で普及しましたが「これは世の中にも広めるべきだ」ということで公開されるようになりました。

今年の春にWebは30年の誕生日を迎え、それに合わせた記念イベントも開かれました。

研究の話に戻ると、CERNは実験機関としても世界最大規模の施設を持っています。
CERNにある加速器は全周20km以上にも及び、光速に近いスピードの粒子を衝突させてその結果を解析しています。

加速器はテラバイト級のネットワークに接続されており、データセンターにつながっています。ストレージに蓄積されるデータは400TB/日にものぼります。
世界中のいたるところにある研究機関にもネットワークが繋がっていて70PB/年のデータをやり取りしています。

研究とKubernetesのかかわり

今日ここで話すのはこうした研究を動かすためにKubernetesをどのように使っているかです。
取り上げるのは「ヒッグス粒子」で、2013年のノーベル物理学賞を受賞した研究です。ヒッグス粒子の存在が証明されることによってビッグバンの起源などに関わる様々なことが説明できるようになるのですが、またたく間に崩壊して4つの粒子になってしまうため物理的に観測することはとても難しく、再現性のあるシミュレーションが重要になってきます。

シミュレーションにはJupyter Notebookを使い、グラフの可視化まで行います。このシミュレーションには70TBのデータセットを使い、20000を超えるKubernetesクラスタで処理します。

CERNでは従来よりOpenStackベースのインフラストラクチャを用いており、この研究に関してもCeph + OpenStack Magnum + Redisの構成で行われていました。

2018年にGoogleがCERN openlabの活動にジョインしたことをきっかけに、GKE（Kubernetes）を使って研究を行ってみることになりました。

Google Cloud Platform（GCP）上での技術スタックとしては、Google Cloud Storage（GCS）+ Google Kubernetes Engine（GKE）+ Memorystoreとなっており、基本的なスタックは変えないままマネージドに移行しています。

デモを行った結果実験でGCSからPullするデータの瞬間転送速度は最大1.6Tbpsくらいで、かなりの規模のデータ転送が行われていることがわかります。

CERNで使っているデータセットはオープンデータポリシーに基づいているため「理想的には」どこであろうと誰であろうと実験を行うことができますが、現実的にはこの量のデータを処理するにはかなりのパワーが必要です。

そんな中で研究に使われるインフラの技術を入れ替えることにはどのような意味があるのでしょうか。

コンピューターを使った計算を行う場合、

• OS（バージョンやディストリビューション、アーキテクチャ）
• （言語などの）インタプリタのバージョン

といった差異が大きな違いを招いてしまうことがあります。

こうした問題を解決するにあたって、コンテナが大きな役割を果たしてくれました。

まとめ

• コンテナは再現性を「空間と時間（物理学における宇宙の定義）」に与えてくれる
• 世界中のどんなデータセンターでも、いつ実行しても同じように動かすことができる
• オープンサイエンスにおける大きなゲームチェンジャーになる

How Spotify Accidentally Deleted All its Kube Clusters with No User Impact - David Xia, Spotify

2つめに紹介するキーノートは、Spotifyのエンジニアによる「何回か誤ってクラスタを削除してしまったがユーザーへの影響なしに復旧できた話」です。

Spotifyのサービス及びインフラ構成について

Spotifyは1億を超える有料会員、2億を超えるMAUを抱える世界最大級の音楽ストリーミングサービスです。

SpotifyではGoogle Cloud Platform（GCP）でインフラを組んでおり、その中でもいくつかのサブシステムをGoogle Kubernetes Engine（GKE）で部分的に動かしています。

削除の経緯（Story Time）

前提として、SpotifyのGKEではUS、Europe、Asiaの3つのクラスタがあり、それぞれが同じ構成でリージョナルな冗長構成になっています。

ある日、オペミスでUSのクラスタを削除してしまいました。

また、別の機会には同僚が誤ってAsiaのクラスタを削除してしまい、復旧しようとしたものの、さらに間違えてUSのクラスタも追加で削除してしまいました。

これらオペミスが発生した背景としては、ブラウザ上で作業をしていたときに、テスト用のクラスタとプロダクション用のクラスタを横に並べていたことが原因でした。

幸いなことに、本事象に起因したユーザーへの影響はありませんでした。

とはいうものの、このような事象を食い止めるにはどうしたら良いのでしょうか。現実的には、「食い止める」ことはできないため、何らかの仕組みを設けて「防ぐ」必要があります。

削除から学んだこと

クラスタの復旧には時間がかかること（3.25時間）

時間がかかった理由には以下の3つがありました

• 原因1: クラスタ作成スクリプトのバグがあった
• 原因2: ドキュメントの様々な不備があった
• 原因3: クラスタの作成処理はresumableではなく、All or Nothing（失敗したらまた1からやり直し）だった

削除事件から一ヶ月後

この失敗を踏まえて、Terraformを使ってインフラの構成をコード化することで削除するのを防ぐことにしました。

ところが、また事件が起きます。

前提として、全クラスタに対する共通設定やKubernetesのリソースを管理するためのGitリポジトリがあり、それを使って構成管理をします。また、このリポジトリにはクラスタの運用者と利用者の両方がコミットします。

Terraformの十分な知識がないまま運用していたので、tfstate（構成の詳細を管理するステートファイル）をGitリポジトリに含めていました。tfstateには各環境ごとにすべてのリソースのメタデータが入っていて、手動で触るのは非常に危険なので、S3などに保存してGitには含めないのが一般的です。

チームのエンジニアがAsiaリージョンにクラスタを新しく作成するためのPRを作成しました。このとき、CIでreviewビルドが走り、リモートのステートが 誤って更新されてしまいました。 このステートファイルがMasterに取り込まれると、本番のリソースにも影響が発生します。しかし、この時点ではレビュー用のCIが走っただけで、Masterにはマージされていませんでした。

次に、クラスタ利用者が、既存のRoleBindingに3つの新しいユーザーを追加するPRを作成しました。この変更は一見なんの問題も無さそうです。しかし、不幸なことに、問題はこの変更ではありませんでした。問題は、このユーザー追加がAsiaリージョンのクラスタに定義されていなかったことです。

このPRを先にマージした結果、不整合が発生してAsiaのクラスタが動かなくなりました。

この問題を修正するために、マージしていなかったAsiaのクラスタ定義のPRもマージしたところ、今度はサービスロールの権限不足でAsiaクラスタの作成時にエラーが発生しました。今までは手でクラスタを作成していたため問題がなかったのですが、サービスロールの設定を変えたことによって、Terraformから見たときに新しくロールを作り直すための権限が必要になりました。

これらの不整合の結果、今度はUSのクラスタにまで影響が波及しました。 3つのプロダクションクラスタのうち2つのクラスタがこの地球上から消え去ってしまいました。

開発者への影響

この事象におけるユーザーへの影響も前回と同じくありませんでした。しかし、開発者には以下のような影響がありました。

1. 開発チームが非KubernetesなVMを追加で構築する必要があった
2. マスタIPがハードコードされていたのでアップデートする必要があった
3. kubectlに使うクレデンシャルを更新する必要があった

障害の振り返り（やっておいてよかったこと）

障害が実際に起きたのは事実ですが、上述の通りユーザーへの影響はありませんでした。これは不幸中の幸いとも言えますが、以下のような内容が実践できていたことが重要でした。

• 障害を前提に設計していたこと
• 大規模かつで複雑なインフラを段階的に移行したこと
• 学びの文化を持っていたこと

どのように障害を意識してインフラを設計したか

1. あらゆるサービスのK8sへの移行を「段階的に」した
2. Kubernetes上で動かすアプリケーションの登録方法の工夫
3. 非K8sな環境へのフェイルオーバー

大規模かつで複雑なインフラを段階的に移行したこと

障害発生時点で、SpotifyにおけるKubernetesの利用状況は実験段階（β）に過ぎませんでした。

そのため、開発チームには各サービスをいきなり全てKubernetesに移行することは推奨せず、部分的に取り入れるようにさせていました。

他にも、Kubernetesのインテグレーション、可用性、複数クラスタの管理について継続的に取り組んでいました。

Kubernetes上で動かすアプリケーションの登録方法の工夫

Kubernetes上で動かすアプリケーションの中で「あえて」Kubernetes wayに反した使い方をしている部分があります。 例えば、アプリケーション上でKubenernetesのService IPは使わず、Serviceのエンドポイントを定期的にポーリングしてサービスディスカバリの設定を更新しています。

非K8sな環境へのフェイルオーバー

サービスディスカバリのシステムが再起動したことで、KubernetesのPodたちがサービスディスカバリの一覧から削除され、結果として既存のVM上で動いているサービスにアクセスが切り替わりました。

学びから得たベストプラクティス

クラスタバックアップ

闇雲にバックアップするだけではなく、日常的にバックアップから復旧できることを証明しておくことが非常に重要です。

インフラのコード化

特に以下の部分について言及されていました。

1. ワークフローの標準化
   1. 新しいツールは段階的に入れる
   2. LinterとValidatorを入れる
   3. dry-runの結果を表示する（GitのPRコメントとか）
   4. featrueブランチは常に最新の状態に揃える
   5. Branch Protectionの導入（CIのステータス、レビューのApprove）
2. 障害の試験
   1. 障害は起こるものだと考える
   2. 試験するときはちゃんとスケジュールする
   3. 運用者、利用者にアナウンスする
   4. 複数の障害シナリオを用意する
   5. 発生した問題は即座に記録、修正する
3. Practice makes perfect
   1. 前は3時間以上かかったリストアが今は1時間で完了するようになった

学びの文化

失敗は失敗で終わらせるのではなくきちんと学びにすること。

失敗した人を責めないこと。

最後にもう一度、よかったことのまとめ

• 障害を前提に設計していたこと
• 大規模かつで複雑なインフラを段階的に移行したこと
• 学びの文化

Spotifyのインフラが目指す次のステップ

1. 各サービスのオーナーたちに、アプリケーション全体がKubernetesで動かせるようになったことを伝える（βフェーズを脱した）
2. 複数クラスタに跨った設定の管理とワークロードの分散する
3. リージョン内で複数クラスタにサービスをデプロイすることで冗長性を確保する

まとめ

KubeCon EUには初めて参加したのですが、USよりも規模が小さいという予想をいい意味で裏切られました。

セッションの幅が広く、面白そうなものが固まっていたためどれに行けばよいかわからなくなってしまうこともありました。

全体的にはいままでのKubeConのスタイルと同じくコミュニティや事例・スポンサーの色を強く残しながらも、Spotifyのようなスタートアップの失敗事例をはじめCERNや大学などのアカデミックな事例にまで幅が広まっており、ますます盛り上がりを見せているように感じます。

セッションの動画を見たり記事を見ることで得られる情報も非常に勉強になりますが、やはり現地で空気感を味わいながら「参加」することも非常に重要なのだなと思えるようないいセッションを見ることができました。

冒頭でも触れましたが、スペインはご飯も美味しく人や気候も穏やかで非常に良かったです。

11月にSan Diegoで開催されるKubeCon NAも楽しみにしつつ、以上でレポートとさせていただきます。

ありがとうございました。