英国のオンラインバンキングの新興企業Monzoは、4か月前から存在するKubernetesのバグにより、金曜日に1時間以上のサービス停止に見舞われた。
モンゾ社のエンジニアリング責任者オリバー・ビーティー氏によると、作家レモニー・スニケットが名付けたかもしれないこの出来事は「非常に不運な一連の出来事により」生産クラスター全体をダウンさせたという。
この期間中、顧客への入金が遅れ、出金が滞りました。Monzoは基本的にインターネットベースの銀行として運営されており、スマートフォンアプリからアクセスでき、当座預金口座、予算管理ツール、支出警告などを提供しています。
月曜日、ビーティー氏はこの事件の分析を投稿し、Kubernetesと関連ソフトウェアとの非互換性が原因であると指摘した。
Beattie 氏の説明によると、Monzo のスタックは、クラスター オーケストレーションに Kubernetes、分散データベースetcd
、linkerd
クラスター ルーティングと負荷分散を管理するソフトウェアに依存しています。
障害の2週間前、Monzoのプラットフォームチームはetcd
クラスターを新しいバージョンにアップグレードし、ノード数を3ノードから9ノードに拡張しました。これにより、障害発生の布石となりました。木曜日、エンジニアリングチームはアカウント保有者向けに新機能をデプロイしましたが、問題が発生し始めたため、サービスをスケールダウンし、レプリカを一切使用せずにKubernetesサービスとして稼働させました。
金曜日の14時10分頃(英国夏時間)、決済処理に使用されるサービスに変更が加えられました。その時点で、顧客は決済に失敗するという問題が発生し始めました。2分後、変更は元に戻されましたが、問題は解決しませんでした。
14時18分までに、Monzoのエンジニアは問題の原因を突き止めましたlinkerd
。ソフトウェアは、ネットワーク上の新しいポッドの実行場所に関するKubernetesからの更新情報を受け取っておらず、リクエストをもはや有効ではないIPアドレスにルーティングしていました。
14時26分、バックエンドで稼働している数百のlinkerd
インスタンスを再起動すれば問題全体が解決するだろうと考えた彼らは、再起動を決断しました。しかし、クラスターノードで稼働しているKubeletがKubernetesから設定データを取得できなかったため、再起動はできませんでしたapiservers
。
決済代行サービスの倒産で銀行アプリスタートアップが再び窮地に
続きを読む
Kubernetesまたはにさらなる問題があると疑いetcd
、3つのapiservers
プロセスを再起動しました。15時13分にはすべてのlinkerd
ポッドが再起動していましたが、バンキングアプリのサービスはリクエストを一切受信していませんでした。この時点で、プラットフォーム全体が停止していました。
15時27分、エンジニアはからのサービス検出応答の読み取り中にlinkerd
ログに記録されたことに気付きました。エンジニアは、空の応答を解析できなかった原因は、実行中のKubernetesと のバージョンの非互換性にあると判断しました。NullPointerException
apiservers
linkerd
linkerd
サービスを復旧させるため、社内のステージング環境でテスト中の最新版に切り替えました。必要なバージョンアップグレードを実施した後、レプリカのないサービスを解析しようとする際に発生するエラーは、レプリカを削除することで回避できることが分かりました。これによりlinkerd
サービス検出が再開され、プラットフォームは回復し始めました。
ビーティー氏は、チームが「Kubernetesとクライアントにバグを発見しました。etcd
このバグにより、先週実行したようなクラスタ再構成後にリクエストがタイムアウトする可能性があります。このタイムアウトにより、サービスがデプロイされた際に、linkerd
ネットワーク上の場所に関するKubernetesからの更新情報を受け取ることができませんでした」と述べた。
インスタンスを再起動すると、と Kuberneteslinkerd
の特定のバージョン間の非互換性が明らかになったため、問題がさらに悪化したと彼は述べた。linkerd
「皆様に改めてお詫び申し上げます。今回のインシデントは、当行史上最悪の技術的インシデントの一つであり、当行の目標は、お客様に常に信頼していただける銀行を運営することです。ご期待に沿えなかったことは重々承知しており、深くお詫び申し上げます。」とビーティー氏は締めくくった。
率直な謝罪は顧客に好評だったようで、詳細な開示と説明に感謝する声が多数寄せられました。®