7/26現在、デレマスボーダーbotではフリートレード履歴の取得が遅延する障害が発生しています。現時点では障害原因の除去は終了しており、取得できなかった分のフリートレード履歴をできる限り取得する回復動作が行われています。おそらく7/27中には回復すると見込んでいます。
この post は新機能や上記障害対応そのものについての内容ではなく、現時点におけるデレマスボーダーbotの障害発生時における挙動・ポリシーについて説明してみようと思います。
ボーダーbotのシステム構成
ボーダーbotは全部で7台のシステム＋作業用の保守端末で構成されています。
このうち観測（データ取得）に関係するサーバは、制御サーバとデータ取得サーバ、そしてデータを入れているデータベースサーバの3つです。イベントのポイントを取得するときの流れは以下のようになっています。
- 制御サーバがデータベースサーバを参照し、次に取得する必要のある情報を決定する。（例：そろそろイベントxxの総合ランキングポイントが更新される時間だ。まだ未取得なので観測しよう。と決定する）
- 取得タスクの優先度・取得期限を決定し、制御サーバ内のキューに登録。（例：取得範囲は個人1～2500位とし、200位や2000位は優先で取得しよう。と決定する）
- 制御サーバ内の別スレッドにおいて、登録されているタスクのうち優先度の高いキューから選別を行い、一番空いているデータ取得サーバに対してデータ取得を指示する。
- データ取得サーバが指示されたページを取得して解析。解析結果を制御サーバに返す。
- 制御サーバは受け取った結果をデータベースサーバに保存する。
これをずっと繰り返し、イベントポイントを取得しています。
構成図を見るとデータ取得サーバのみ3台のクラスタが存在します。これはある一定量以上の通信を「同一 IP から」 Mobage 側に行わないようにするために行っています。結果としてここだけ HA 構成になりました。すこしだけ”闇”になるのであまり深くは記載しませんが、外部へのアクセスを複数のグローバルIPから行えるよう工夫されています。
話がずれるものの大事なことなので記載しておきますが、複数台構成とはいえ、パラレルアクセスにより相手サービスに集中的な負荷を与えてしまうことがないよう、制御サーバーでキューと優先度の管理が行われています。総体としてのボーダーbotから Mobage ないし各種の外部 API へのアクセスは、一部の極僅かな例外を除いては、シリアルアクセスを保ち、かつ適切なアクセス間隔を保つよう厳格に制御されています。
この制御サーバの動作はボーダーbotの中枢であり、4年間にわたって改良を続けています。この詳細な動作を説明すると数記事に渡ってしまいますので、今回はデータ取得サーバ3台を1台の制御サーバが司っていることを伝わればよいかなと思います。
サーバごとの障害影響と縮退運転
ボーダーbotは全体としては HA 構成ではありません。データベースサーバと制御サーバは単一障害点であり、どちらかの機能が停止すると基本的にはボーダーbotの全機能が停止します。ツイートもWebも止まったときは、だいたいここがシステム障害で死んでいます。先日あった事例では、 SSD が満杯になって全機能が止まりました（文字に起こすとなんとしょうもない…）。
Webサーバとツイート画像生成サーバでの障害発生時は、それぞれWeb・ツイート出力のみが停止します。
問題はデータ取得サーバで、これだけは3台あるために特殊な動きをします。このサーバは1台が死んだ場合でも他が生存している場合は、一部の機能を制限しつつ稼働を止めないようにする「縮退運転」を制御サーバが行います。
今回の障害は、このデータ取得サーバのうち1台が、サーバ(VPS)を借りている業者(Linode)の収容器の故障により一時的に停止したことで発生していました。
こういった機材故障やアプリ障害以外にも、ボーダーbotから見た対向システム要因によるものがあります。イベント最終盤など特定の条件において、Mobage 側からの平均応答時間が連続して著しく遅延したり、Gatewayエラーなどのいわゆる「白画面」が頻発した場合です。このような状況でボーダーbotが負荷をかけ続けることは好ましくないと思われるため、過負荷と思われる状態を検知すると、制御サーバは一時的な「縮退運転」モードに入ります。
縮退運転時における優先機能
制御サーバは障害または過負荷検知により縮退運転を迫られた場合、以下の優先度で機能を活かそうとします。（上を優先して活かします）
- イベントポイント観測（100位、200位、300位、1000位、2000位、4000位など。ここでは「基準順位」と言います）
- カード情報更新（※新しいカードの追加を検知した場合）
- イベントポイント観測（基準順位以外）
- 最終イベント結果取得（プロデューサー・プロダクション情報更新）
- 道場情報更新
- フリートレード履歴取得
データ取得サーバが1台故障した時は 4. 5. 6. が行われなくなります。2台故障時や Mobage 側の過負荷検知時は 3. も停止します。
デレマスのイベントポイントは10分ごとに更新されますが、これは観測側の視点に立った場合、当該イベントポイントの取得は10分間しか許されておらず、そのタイミングを逃すともう二度と正確な値を取得することができなくなることを意味します。したがってボーダーbotは、この10分の間に重要度の高い順に必要なポイントを抜き取ることに主眼を置いて実装されています。
特に基準順位のイベントポイントは非常に重要であり、1999位のような報酬に関係しないイベントポイントは取得できなくともそれほど影響はありませんが、200位や2000位のイベントポイントを取得できなければボーダー観測情報を提供することができません。そのため、どのような場合あれ基準順位のイベントポイント観測は成功するまで何度も試み、1. が成功しない限り 2. が行われないようになっています。
それに対して最終イベントポイントやフリートレード履歴といったものは、一時的に取得できなかったとしても、期限内であれば障害の回復後に再度取得してもタイムラグ以外に問題が起こりづらい種類のものです。道場情報もそれほど最新情報が要求されるわけではありません。縮退運転せざるを得ない場合には、これら遅延が許される処理を率先して後回しにしています。
ボーダーbotはいまやたくさんの役割を持つようになりましたが、最も重要なのは基準順位の観測です。2016年に始まったときから今に至るまで、この点が変わることはありません。
もっとも、カリビアンクルーズやアイプロお仕事体験♪のように、障害が解決できないと 4. がまるごとスキップされて最終結果取得が間に合わなくなる事故が起きることもあったりします。もちろんこの場合も、ボーダーbotとしては最終結果より推移情報が全てにおいて優先するので致し方ないのですが…
たまにボーダーbotが「基準順位のポイントツイートは出ているのに、上位P 個人800位までのポイントツイートを出力しない」いう挙動をしていることがありますが、これは過負荷検知などにより 3. が止まっているときに起こります。基準順位以外の情報が欠けているので、ツイートが作成できず出力をスキップしている状態です。
さいごに
今回、フリートレード履歴の取得が遅延している理由について説明しつつ、どういう優先度でデータを取得しているか記載してみました。
いま現在は制御サーバ内に、優先度低いラベルがついたフリートレード履歴取得タスクが積み上がった状態になっています。より優先度の高い PMF51 のイベントポイントを取得しつつ、また Mobage 側への過剰な負荷を避けるため間隔を保ちつつ、緩やかにタスクが消化されています。もしフリートレード履歴をお使いの方がいまこれを見ていましたら、いましばらくお待ちください。
デレマスボーダーbotは、ミリオンボーダーbotさんやナナシスイベントボーダーbotさん、matsurihi.meさんなどを参考にして作ったものですし、特に最初期はミリオンボーダーbotさんの解説を読み込んでから作った経緯もあります。この開発ノートには、（PMFなどで）時間のある際に、誰か/なにかの参考になるよう、このボーダーbotの説明もたまに残していければと思っています。