このブログ記事は、以下の記事の続報です。
昨日(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日にそれが表面化したのです。

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


2. 障害発生後、さまざまな仮説の検証のため、貴重な時間が費やされてしまいました。それにも関わらず、根本的な原因はとてもシンプルなものでした。原因究明の時間はある程度は避けられないものだったとはいえ、それを避けるためにも予防が非常に重要だと考えています。当社では、5人の社員がシステムをさまざまな角度から検証していましたが、このようなケースが発生し得ることには気づいていませんでした。もし気づいていたら、障害解決に3時間もかからず、数分で障害は解決されていたでしょう。

対応策:
障害対応のプロセスを見直し、関連する情報に関する教育を即座に行います。また、運営チームのメンバーへのトレーニングを強化します。これにより、より広範な障害の原因解析とトラブルシューティングをできる能力を向上させます。また、原因解析用の情報をもっと詳しく提供できるように、監視ツールを改善します。


3. フェイルセーフな仕組みにおいても、予期せぬふるまいが起き、障害が発生する可能性があります。障害対応においては、障害が検知され、対応をとるという流れが基本ですが、原因の想定が間違っていて(微妙に間違っていることはよくあります)、対応策が適切ではない場合、とった対応策自体がフェイルセーフの仕組みが作動する妨げになってしまうことがあります。このため、プロセスの中に人間を介在させ、そのような場合でも適切な対応ができるようにしていますが、今回の場合、運用チームが認識していない単一障害点があり、障害が波及するのを防げませんでした。

対応策:
上記のように障害が波及しないように、人を介在させるプロセスがよりうまく動くように現在の仕組みをレビューしています。


いずれにしても、今回の障害は未然に防ぐことができるものであり、発生した後ももっと早く解決できたと考えています。重ねてお詫び申し上げます。利用しているツールやプロセスを改善し、このような障害を予防、適切な対処できるようにしていきます。

■関連情報
コメントはまだありません コメントしてください。

コメントの投稿

38.107.179.220 (38.107.179.220)