リクルートIDにトラブル発生
2020/3/2 16:30現在、リクルートIDに何らかのトラブルが発生しているようで、緊急メンテナンスを実施しているそうです。
※18:00ごろに復旧したっぽいです。
ユーザー判別にリクルートIDを利用しているサイトは公式サイトのキャッシュによれば、下記のとおりです。
じゃらんnet
じゃらんゴルフ
ホットペッパー グルメ
HOT PEPPER Beauty
HOT PEPPER Beauty 美容クリニック
ポンパレモール
Oisix × Pontaポイント
人間ドックのここカラダ
Airウォレット
リクルートかんたん支払い
リクルートカード
スルガ銀行リクルート支店
ゼクシィ内祝い
ショプリエ
リクナビNEXT
リクナビ派遣
タウンワークネット
とらばーゆ
はたらいく
フロム・エー ナビ
SUUMO
SUUMO賃貸経営サポート
ゼクシィ
ゼクシィキッチン
ゼクシィBaby
カーセンサーnet
スタディサプリ ENGLISH
エイビーロード
ケイコとマナブ お月謝くん
タブルーム
Airリザーブ
Airウェイト
マジ☆部
レビューノート
保険チャンネル
HOT PEPPER Beauty cosme
ここカラダme
上記サイトを開き、マイページに行こうとするとことごとく、リクルートIDのメンテナンスページに飛ばされます。
ツイッターの情報を見る限りは、本日13:15ごろに発生したように見えます。
サービス共通基盤のリスク、リターン
上記無数のサービスがおしなべて、同時に利用できなくなるという事象は、起こってみると非常に怖いものです。
同一企業に対して、複数システム同時にユーザーから障害の問い合わせが起こりますから、基本的に問い合わせ窓口はパンクします。
また、その影響の大きさにビジネスの担当者はパニックとなりがちです。特に今日は日曜日ですからほとんど会社には人はおりません。緊急連絡体制を持っていたとして、そこから単に人が集まるだけでも2時間はかかると思います。また、ベンダーも日曜日ということもあり保守を呼ぶとしてもハードウェアならまだしも、ソフトウェア周りとなるとなかなかマンパワーを確保するのに時間がかかります。
今回の障害がどこに原因があるのかという状況より前に、エンドユーザーへの告知すら現象発生より3時間経っても出せないところが、まず初動として厳しい状況にあるのだなということを感じることができます。
リクルート系の各サイトの特徴として予約サイトが多いということです。エンドユーザーとして利用する個人だけではなく、それを利用して予約を管理している企業側もユーザーであるということです。個人側からすれば新規予約ができないことはもちろん既存の予約確認ができません。企業側のマイページがどのような作りになっているのかはわかりませんが、「予約したはず」という個人をさばかなければいけないでしょう。特に日曜日の午後と言うことで、いろいろな混乱が起きていることは間違いないと思います。
さて、リスク管理の観点から、リクルートIDの大きなリスクの話です。複数のサイトは別々の作りであるにも関わらず、このリクルートIDの認証を通らないとログイン以降の処理が全くできなくなります。
このような、複数の機能に対して同時障害を引き起こす箇所というのは、リスクを相当に高く見積もりそれに対してコントロールを行っていないと、そのリスクが発現した際には相当高い代償を支払うこととなります。
もし、今回の障害の原因は大変シンプルだったとしても、その影響と損失は大きいですから、あらゆる想定を行い、相当のリスク対策を何重にも行わないといけない箇所です。そして万が一発生したとしても、短時間で復旧できるような設備も用意しておき、その切り替えもできるように用意しておかないといけません。
そもそも構築時に、非常に高いリスクポイントとなりえるような設計にしなければいいという観点も確かにそうです。しかし共通の認証基盤は最近はビジネス上大変重要な機能と言われています。GoogleもGoogle IDを用意していますし、Amazonも、Facebookも、AppleもIDを共通IDを準備しています。国内でもYahoo! JapanがYahoo! ID、楽天は楽天 IDを用意しています。なぜIDを各社が争ってサービスしているかと言うと、IDに紐づけて行動分析を行いたいからです。下記の記事が詳しいです。こちらはリクルートID自体のインフラの話ではなく、そこからどうやって全体を分析しサービス化しているかという記事です。
システムエンジニア側としてみれば、共通認証基盤は非常に責任の伴う箇所であり、できればサイト単位で独立してくれたほうが気は楽です。しかしビジネス上の制約からそんなことは言っていられないということで実装し、運用されているのだと思います。
繰り返しますが、このような箇所には破格の投資を行い、リスクに対するコントロールを何重にも実装しなければいけません。
コントロールの例
こういった、企業にとって命綱ともなる共通基盤に対して、どうコントロールを行うか。お金があるのならばいくらでも選択肢はあります。
・データセンターを二重化し、片方が止まっても無停止で動作し続けられるようにする。もしくはごく短時間で切り替えられるようにする。
・24時間運用を行い、有人監視とする。問題が発生した場合に手順書に基づいて対応可能なように普段から準備しておく。
・外部からDDoS攻撃を受けた場合を想定し、セキュリティー監視サービスをアウトソースしておく。またあらゆる攻撃に対して、対応策を前もって用意しておく。
・各サブシステムは二重化・三重化するとともに、仮想基盤などを利用しハードウェア障害の影響を受けにくくしておく。
・データベースの停止や起動しないなど、データの完全性が脅かされる事態を想定し、バックアップやリストアは投資を十分に行う。バックアップの定期取得に関しては厳しく監視を行い、短時間でリストアできることを常にチェックしておく。
・ベンダー保守については、24時間保守はもちろんのこと、専任担当者の複数名アサイン、かけつけ対応など十分な投資を行っておく。
ただ、平常時。何もないときを想定してもらえるとわかりますが、こちらはビジネスオーナーにとって「大きなコスト」に見えます。このコストを抑えれば抑えるほど、単年度の利益は増額します。かなり大きな金額ですから、これを削減しつつコントロールできるかどうかがシステム責任者に問われます。
私は何度か、「サービス共通基盤を持てば、コストメリットが出るし管理も一つになるから運用が楽」的な意見を跳ねつけた記憶があります。もし可能ならば、今回のような複数のシステムが同時に影響を受けうる機能の実装は最後まで反対します。それでもビジネスオーナーが強行する場合は、そのリスクを十分に共有します。それでもやる、という場合にだけ先に進めるようにしています。
昨今は、新型コロナウィルスにより、電車の移動や駆け付け、オフィスへの集合も健康リスクが伴うようになっています。至る所にあるリスクを考えると、各機能はできるだけ分散し、独立させてやりたいものだと思います。
