orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。



GmailやGoogle Drive障害の症状はKubernetes環境独特の動きだった

f:id:orangeitems:20190313163007j:plain

 

日本中が仕事できないと悲鳴

日本中が大騒ぎになってましたね、今日のGmailやGoogle Driveの障害

 

jp.techcrunch.com

日本時間3月13日お昼前ごろより、メールサービスGmailや、クラウドストレージGoogle DriveといったGoogleのサービスに障害が発生している模様です。主な症状はGmailの「送受信がまったくできない」といったお手上げなものから、「テキストや画像を添付したメールの送受信はできるもののその他の添付ファイルがあると送信できない」、「メールを書いている途中にエラーになる」などさまざまです。

 

15:13当たりで復旧したらしいですが。

 

f:id:orangeitems:20190313163129p:plain

G Suite Status Dashboard


  

コンテナとGoogleとKubernetes

Googleのサービスはコンテナで動いていて、そのコンテナ基盤が今やKubernetesとして脚光を浴びているのは有名な話です。

 

www.publickey1.jp

つまり私たちが利用するGoogleのすべてのサービスも、Googleの社内で使われているツールもすべて、すでにGoogleではDockerのようなコンテナ型仮想化技術の上で実行されているということのようです。
「We start over 2billion containers per week.」(私たちは毎週20億個以上のコンテナを起動している)とも書いてあり、Google内部ではすさまじい数のコンテナが実稼働していることになります。

 

20億個のコンテナと言うパワーワードで業界がざわついたのは今や昔ですが、今はもっと増えているんではないでしょうか。この記事にはKubernetesと言う言葉はないものの、絵はKubernetesそのものですね。マスターとワーカーノードそのものです。

Kubernetesの歴史をひも解くと・・

 

thinkit.co.jp

Kubernetesは、Googleの社内で利用されていたコンテナクラスタマネージャの「Borg」をアイデアの元にして作られたOSSです。2014年6月にローンチされ、2015年7月にバージョン1.0となったタイミングでLinux Foundation傘下のCloud Native Computing Foundation(CNCF)に移管されました。CNCFには著名な開発者、エンドユーザ、大手クラウドプロバイダなどのベンダーが参加しており、現在はCNCFが主体となり中立的な立場で開発が進められています。執筆時点での最新バージョンは1.9となっておりますが、1.7の時点でProduction-Readyと宣言されています。

 

ってことで2014年6月って書いてあるので、20億個宣言(2014年5月)の直後と言うことになります。すげーなGoogle、っていうのが当時だったわけですが。

 

techtarget.itmedia.co.jp

2018年8月末、Googleはクラウドベースの大規模テスト環境をオープンソースソフトウェア管理団体Cloud Native Computing Foundation(CNCF)に移管する準備を開始した。Googleはこれにより、Kubernetesのガバナンスを完全な独立状態にさせることに一歩近づいた。
 CNCFは、アップストリーム(サードパーティー製でなくコアの)Kubernetesの開発に使用するテスト環境の管理を、Googleから徐々に引き継ぐ予定だ。Googleのスタッフのみが管理していたこのテスト環境は、5000台の仮想マシン(VM)に構築された15万個ものコンテナにより、スケーラビリティのテスト用クラスタを実現する。Kubernetesプロジェクトのコントリビューターは、このインフラでテストを実行する際、これまではGoogle社員を通す必要があった。

 

ということで、もうお金出すからOSSにしてみんなで良くしていこうぜというフェーズになっています。

 

今回の障害

自動的に復旧する仕組みのあるKubernetesですから、今回は不気味な症状を経験できました。動いているけど一部動かなかったり、自然に復旧したりと「不安定」を絵に描いた挙動です。しかし全く使えなくなるわけではない。マイクロサービス化しているからこそ、不安定な部分が生まれると一部が使えなくなりそのうち自然復旧。これまでのモノリシックなサービスだと全くアクセスできなくなり真っ白になるだけでした。不安定ながらも動き続けるというのはインフラ側をやっていると不思議なものです。ただ、Kubernetesのワーカーノード大部分が被害を受けるようなネットワーク障害やストレージ障害が絡んだりすると、根本的な原因を修正しなければ、いつまでたってもマスターノードが「満足」とみなさないので一気に不安定になります。

この辺りの気持ち悪さを考えると、オンプレでKuberenetesというのは不安が大きく、パブリッククラウドがマネージドしてくれるマネージドKuberenetesに限るよなあと言う感想を強くした次第です。

同時多発的にコンテナがボコボコ再起動したり落ちたりするのを見ながら、障害対応しなければいけないのは辛いものがあります。その辺はクラウド業者に任せたい。

特にKuberenetesの障害時のベストプラクティスや運用設計はまだまだ不明確なので、今回の障害の症状はなかなか貴重な経験だったように思います。