Monzoの障害を振り返る

英国をベースとするディジタルモバイル専門銀行のMonzoが先日、当座預金の支払とプリペイドデビットカードシステムの停止という事態に見舞われた。Monzoのエンジニアリング責任者であるOliver Beattie氏は、Monzoのコミュニティフォーラムに、システム障害の事後解析結果を報告した。

Monzoでは非常に初期の段階から、世界規模のスケールを中核的な前提のひとつとして、自社インフラストラクチャの設計を行なってきた。この結果として、数百というマイクロサービスが開発されている。

これらのマイクロサービスはDockerコンテナにパッケージされ、AWSのKubernetesを使ってデプロイされる。サービスのオーケストレーションにはetcdによって実行されている。Kubernetesはこれを使って、どのサービスがどのような状態で、どこにデプロイされているのかを識別する。サービス間のルーティングとロードバランシングはlinkerdを使って行なう。

プリペイドカードと当座預金の所有者に影響を与えたシステム障害は、いくつかの要因の組み合わせによって引き起こされた。

まず第1に、Kubernetesにバグがあったため、クラスタ再構成後に要求のタイムアウトが発生した。障害発生の１週間前に行われたクラスタ再構成によってこのタイムアウトが発生し、linkerdがKubernetesからのアップデートを受信できなくなった。

次に、障害が発生した場合に即時実行される対応のひとつとして、すべてのlinkerdインスタンスが再起動された。これによって、KubernetesのバージョンとMonzoが使用しているlinkerdの間の非互換性が表面化し、特定サービスの停止からプラットフォーム全体の障害へと、状況をさらに悪化させた。Monzoのコミュニティフォーラムのスレッドには、これらイベントの完全なタイムラインが掲載されている。

このような障害には、学ぶべき重要な教訓がある。ここではバグ修正、各ライブラリのバージョン間の非互換性チェックといった問題以外に、Monzoでは、社内外での障害に関する通知に関わる手順を改善する必要性について語られた。

さらにもうひとつの教訓は、ヒューマンレラーやその他のエラーを早期検出するために、アラートやダッシュボード、アプリケーション各層のヘルスチェックといったものが重要である、ということだ。結論として、障害を阻止ないし解決するために可能なことはすべてやっておくと同時に、何が起こったのかを事後に正確に伝えて、将来的により高い安全策を立てておくことが非常に重要なのだ。