12月15日早朝(12月14日深夜)のZohoサービスにアクセス障害の詳細について

このブログ記事は、以下の記事の続報です。
昨日(12月14日)の夜中から本日(12月15日)の早朝にかけてのZohoサービスにアクセス障害について

12月15日、1:45から5:15までの間、以下のサービスへのアクセス障害が発生していました。
  • Zoho メール
  • Zoho Books
  • Zoho Support

お詫び
まず初めに、ユーザーの皆様にご迷惑をおかけし、大変申し訳ありませんでした。Zohoサービスに信頼を寄せている皆様にとって、Zoho内の情報へのアクセスは非常に重要だということを認識しております。当社自身もZohoサービスを使って会社を運営しており、単なるサービス提供者として以上にこの障害の重要さを痛切に感じています。このような障害をできる限り予防するため、また、万一発生した場合もすぐ対応できるようにするため、原因調査を行いました。このブログ記事では障害と原因解析の経緯についてお知らせします。


障害発生の経緯
当社のソフトウェアのヘルスチェック機能により、DNSサーバーに対して名前解決の逆引きのリクエスト(IPアドレスに対応するホスト名を調べるもの)が不必要に送られていました(皮肉なことに、この機能はアクセス障害を検知するためのものでした)。

リクエストに対して、DNSの参照結果が適切に返ってこず、DNSの逆引きが失敗しました。この時、ヘルスチェックのメカニズムが不適切に作動し、アプリケーション自体が落ちていると判断し、アプリケーションを1つずつ再起動させようとする処理を走らせました。

もちろん、アプリケーションサーバーが再起動しても、問題の原因はアプリケーション自体にはないため、ヘルスチェックは依然として失敗し続け、アプリケーションを再起動し続けようとし、アクセス障害が発生しました。

ZOHOでは、単一障害点が無くなるようにすべての機器やシステムを二重化して運用するように努めていますが、今回のようなケースはカバーできておらず、当社の運用チームが気づかない単一障害点があったことになります。


原因解析の経緯
この障害は多数のアプリケーションで発生していましたが、それらのアプリケーションサーバーではリソース(物理サーバー、ファイルシステム、データベースなど)を共有しておらず、共通点は同じサブネットワークにあるということのみでした。このため、当社の調査チームは当初、サブネットワークを管理しているスイッチに原因があるのではないかと考えていました。

実際には、共有しているものがあったのですが、それはすぐには分かりませんでした。これにより、貴重な時間が失われてしまいました。最終的には、DNSの逆引きに障害があることが特定され、障害自体への対応は数分で完了しました。


今後の対応策
この12月14日の経験から、当社が得た教訓は次のとおりです。

1. 一緒に働くチームの間にも微妙な情報のギャップが生じ得ることを認識しました。今回の場合、ネットワークの運用チームとソフトウェアのフレームワークのチームで情報のギャップが生じていました。ソフトウェアがネットワーク上のコンポーネントに気づかないうちに依存する形になっていましたが、これは運用の観点からは望ましくなく、単一障害点を生み出す結果となっていました。障害が起き得る可能性は以前からあり、12月14日にそれが表面化したのです。

対応策:
ソフトウェアのどの部分についても、設定の想定を明らかにし、社内に広めるようにします。当社が使用している監視ツールにおいても、ソフトウェアが想定している設定と実際の設定とのチェックを