increased API error rates (APIエラーレートの上昇)ってなんだ？ 〜クラウドやSaaSの障害表現を知ろう

ども、大瀧です。

ITシステムを利用していると、しばしば利用できない状態、いわゆるシステム障害に出くわすことがあります。 最近のITシステムは一台のサーバーにあれやこれやとソフトウェアを入れれば完結するものは少なく、複数のクラウドやSaaSサービスを組み合わせて作るのが一般的になりました。そのため、システム障害とひとことで言ってもその組み合わせのどこで障害が起きているのか見た目からはわからないため、原因の切り分けが必要になります。

ITシステムを運用するいわゆる"中の人"としては、運用しているシステムのアプリケーションの障害なのか利用するクラウドサービスの障害なのか、それぞれの状況を確認し原因の切り分けを進めます。クラウドやSaaSサービスには、サービスステータスダッシュボードといったサービスの提供状態を示すWebページを公開しているものが多くあります(正確な名称はサービスによってまちまちです)。ステータスダッシュボードのサービス提供状態の表現には独特なものがありそれが何を示すのかピンと来ないこともあるかなと思い、本ブログで解説してみたいと思います。(ここまでで長い前置き)

クラウド/SaaSの障害表現とは

クラウドやSaaSはたくさんのユーザーのWebブラウザや連携するユーザーのシステムから接続して利用する公共性、重要性が高いといえます。そのため、クラウドやSaaSは可用性や冗長性のテクニックを駆使した非常に壊れにくい設計になっています。例えば、地理的に離れた場所にある複数のデータセンターにシステムを分散配置していたりします。クラウド/SaaSが提供するサービスの全てが利用不能な全断状態のケースは極めてまれであり、実際の運用で目にすることはほとんどありません。一方で局所的な障害、例えばある顧客は正常に利用できるが、別の顧客は利用できないといったケースが起こりえます。ステータスダッシュボードでは、一部のユーザーでの障害や部分的な機能の障害を示す表現を目にするわけです。わかりやすいものとしては以下があります。

一部のお客様でXXがYYできない事象を確認しています、開発チームで原因を調査しています。

同じような障害状況ですが、少し様子の異なる表現として、以下もあります。

APIエラーレートと遅延の上昇を観測しています、(略)

ちなみに英語だと以下で始まる感じです。

we experienced increased API error rates and latencies ...

なんだかSFものの小説やゲームでロボットを操縦するシーンでダメージを受けたようなメッセージですね。それぞれ解説します。

APIは、クラウドやSaaSでサービスを提供する接続方法のひとつで、現在最も良く利用される方法です。WebブラウザやユーザーのシステムからこのAPIにアクセスしてサービスを利用します。エラーレートというのはサービス事業者が定期的に取得しているサービス自身の動作に関する指標値のうちエラーになっている割合(レート)を指します。正常稼働時のエラーレートはパーセンテージにすると0%ないしサービス提供に支障のない小さな値なので、APIエラーレートが上昇するというのは顧客からのAPIアクセスのうちエラーになっている(=利用できない)率が上がっている様子を指すわけです。これが100%になると、先ほど言っていた全断になります。障害対応中にその具体的な数字が示されることはありませんが、後日の障害レポートやサポートへの問い合わせで開示される場合があり(非開示の場合もあります)、障害の規模感を知るヒントになることがあります。

以下もより抽象的ですが似たような部分的障害を指します。

degraded　XX　handling

日本語にするとしたら以下の感じでしょうか。

XXの処理が劣化しています

システム開発の用語でデグレードとカタカナで表現することもあるので、イメージはしやすいと思います。

接続しずらい状態とは

また、しばしば見られる障害状態の記述として以下もあります。

一部のお客様でXXに接続しずらい事象を確認しています、開発チームで原因を調査しています。

前述の説明では「XXできない」とありましたが、「接続しずらい」というのはどういう状態でしょうか。先ほどと同じ部分的な障害を指すケースがある一方で、サービスが許容する接続数の上限を超える多くの接続が来ている、接続過多のケースがあります。この場合は既に接続済みだと正常に利用できる一方で、新規の接続がエラーになるような振る舞いになります。

接続過多の状態で新規接続を繰り返してしまうと状況が悪化し、復旧が遅れる原因になります。自動で再試行するような設定の場合はエラーログの肥大にもつながるので、サービスが復旧するまで止めるよう対応するのがお奨めです。

タイムゾーンに注意しよう

ステータスダッシュボードの障害情報の時刻表記は、そのサービスを提供する地域のタイムゾーンと同じとは限りません。サービスの開発・運用チームによる調査と障害情報の報告は緊急性が高く記述を誤ると大きな混乱を生むため、運用体制にとって最も適したタイムゾーンが選ばれることが多いです。あらかじめ過去の障害履歴などからステータスダッシュボードに記載される時刻のタイムゾーンを調査しておき、Googleカレンダーのセカンダリータイムゾーンなどで素早く確認できるようにしておくのがお奨めです。

ログを見てヒントを得よう

自分達のシステムに問題が発生していてクラウドやSaaSと連携する処理にエラーを見つけた場合、クラウドやSaaSの障害を疑うのはおかしいことではありません。しかし連携処理が上手くいかなくなる原因は複数あり、連携先の障害はそれらの理由のひとつであるという感覚は胸に留めておいた方が良いでしょう。例えば、連携先のクラウドやSaaSが正常でも通信するネットワークで障害が発生すると連携処理は失敗します。クラウドやSaaSの障害と決めつけるのではなく、システムのログメッセージから切り分けに役立つような情報が無いか調べるようにしましょう。接続エラーの場合もあれば、接続はできていて連携先からエラーコードやエラーメッセージが返っている場合もあるでしょう。適切な情報が返っていれば非常に有用な情報源になります、サポートへの問い合わせにも活用しましょう。

対処方法

では、上記のような障害表記を見つけた場合、どう対処すれば良いのでしょうか。まずは自身のITシステムで当該のクラウドやSaaSサービスへのアクセスが実際に成功/失敗しているかをログなどから確認しましょう。失敗する様子を確認した場合は、クラウドやSaaSサービスに問い合わせるサポートチケットを発行します。そのときの注意点として、ユーザーを識別するアカウント情報や設定を識別するIDを必ず添えるようにします。前述の通りサービスの全断はまれで一部のユーザーからの利用に支障が出ている状態なので、サービス事業者側ではどのユーザー、設定からのアクセスなのかを識別しないと状況を調査することができないためです。たとえ問い合わせWebフォームがメールアドレスとメッセージのみといった形式でも、自身のシステムに関する情報を積極的に書くようにしましょう。どんな事を書けば良いのかわからない場合は、AWSが公開しているガイドラインが参考になるでしょう。AWSに限らず、ITサービスへの問い合わせ全般に役立つ項目が多く載っています。

また、クラスメソッドではAWS総合支援サービスを行っており、テクニカルサポートで得たノウハウをブログ記事で発信しています。こちらも参考になるかもしれません。

ちなみに、↑の記事の著者の中村さんによるテクニカルサポートの中の人の思うところの記事もあります。

どんなクラウドやSaaSでもステータスダッシュボードやサポートチケットの向こう側にはそれに応対する人が必ずいて、プレッシャーに耐えながら一生懸命考えて対応しているのをイメージしていただけるといいなぁと個人的には思います。

まとめ

クラウドやSaaSが公開するサービスステータスダッシュボードでの障害を示す表現を解説し、それに関する推奨事項をご紹介しました。ITシステムを運用する皆さんの何かの役に立てば幸いです。