こんにちは、noダーマです。
7月8日夜、Cygamesがサービス提供している『グランブルーファンタジー』や『ウマ娘 プリティーダービー』、『プリンセスコネクト!Re:Dive』、『アイドルマスター シンデレラガールズ スターライトステージ』などのゲームでアクセス障害が発生しました。
明けた早朝4時頃から各公式SNSで順次復旧のアナウンスが出され、原因はデータセンターの設備障害によるものだったようです。
時間が時間なだけに障害対応をされていた方は深夜作業をしていたことになりますが、実はこの業界において障害で深夜対応をするといったことは珍しくありません。
サービスが停止している時間が長ければ長いほど損失が大きくなるため、致命的な障害の場合は昼夜問わず最優先で対応する必要があるのです。
かくいう筆者もこれまでに何度も深夜の障害対応を経験してきました。
今回はあまり表に出ることのない障害対応の裏側、発生から復旧まで現場で行われていることを解説していきます。
各企業のルールによって作業内容やフローが記載内容と異なる場合もありますが、その点は予めご了承ください。
目次
障害発生から初動対応
異常検知サービスや死活監視、あるいはユーザーからの問い合わせなどで障害を検知すると、まずはサービスの現状確認を行います。
状況が把握できたら次は責任者へ連絡し現状報告と次の指示を仰ぎます。
といっても次にやるべきことが復旧作業なのは明白なので、報告と並行して復旧作業を開始していることもよくありますね。
それからユーザーへ障害発生連絡と、必要ならサービスのメンテナンスを行い、並行して復旧作業と原因調査を実施します。
ちなみに復旧・調査作業は必ずしもオフィスまたは自宅からできるとは限りません。
特に冒頭でご紹介したCygamesのような場合は、作業はほぼ間違いなくデータセンターまで行く必要があるでしょう。
交通機関が動いていない深夜の場合はどうするの？って思う方もいるかもしれません。
その時は自分の車を使ったり、あるいはタクシーを呼んででも行く必要があります。。。
あとから経費精算できるとはいえ、お財布にも結構なダメージが入りますね
復旧作業と原因調査
システム障害の発生原因は多岐に渡るため、ここではよくある例をいくつかご紹介しましょう。
アクセス集中による高負荷
ソーシャルゲームのサービス開始直後や、イベント開始直後などに特に発生しやすい例ですね。
「運営側は対策をしていないのか」という声をよく目にしますが、当然ながら運営側も事前に負荷対策は行っています。
対策しているならなぜ？と思うでしょうが、高負荷によるシステム障害が起きてしまう理由はだいたい下記の通りでしょう。
・想定していた以上のアクセスがあった
・サーバースペックが不十分
復旧作業では「サーバーの再起動」や「冗長化による負荷分散」、AWSなどのクラウドサービスではサーバースペックの引き上げなどを行っています。
ユーザー目線からすると「最初から負荷に耐えうる状態にしておけよ」って思うかもしれませんが、当然それ相応の費用が発生するわけで、運営会社の台所事情も関わってくるので一概に責められない部分でもあります。
プログラムのバグ
これもサービス開始直後や、新機能のリリース直後に発生しやすい例でしょう。
特に「課金したのに反映されない」「データがおかしくなる」など、ユーザーにとって致命的な悪影響を及ぼす場合は即座に緊急メンテナンスを行うことがあります。
これはシンプルにリリース前のテスト不足が原因です。
純粋に開発者の技術不足の場合もあれば、無茶な開発スケジュール、急な仕様変更など様々な理由で、満足にテストを行えなかったケースもよく聞きます。
人が作業する以上、バグを生まないということは不可能ですが、それを限りなく減らすために行うことがテストです。
開発というのは実装完了したら終わりではなく、むしろテストこそが本番と言えるでしょう。
いいものを作りたいなら納期を遅らせてでもテストを十二分に行うべき、というのが筆者の持論です。
機器故障
初期不良や経年劣化、またはその他の要因で発生する機器故障によるシステム障害です。
特に後者の場合は、サービスの稼働日数が増えれば増えるほど発生リスクも増加するため、いつかは発生しうる問題とも言えます。
清掃業者が掃除機をコンセントに刺した結果、回線がショートしサーバーが壊れたなんて特異なケースも存在するため、故障はいつなにが原因で起こるか予想できないのが難しいところです。
復旧方法はシンプルに故障した機器の交換なのですが、故障した機器や規模によって復旧までの時間や難易度が大きく変わります。
ただし、最近の機器には故障しても最低限の機能で動作する仕組み(フェールソフト)が組み込まれていることもあるため、サービス稼働は維持できるといった場合もあります。
報告書作成と改善措置
無事システムの復旧作業も完了し、ほっと一息…はまだできません。
この後にもさらに重要な仕事が残っております。それが報告書作成です。
ここで面倒なのは、提出する先の責任者が技術的な話をちゃんと理解できるとは限りません。
むしろ割合的には理解できる人の方が少ないでしょう。
すなわち詳しくない人でも理解できるように記述する必要があるということです。
ということで専門用語などは極力使わない方がベターです。
技術者同士であればたったの一言で通じるところをあえて言葉を変えて、時には補足説明などを加えるなどの工夫が必要になります。
またシステム障害の場合は、改善措置や再発防止策の策定と実施も必要です。
改善措置や再発防止策を施したあとしばらく様子を見て、同様のシステム障害が再発しないことが確認できたら晴れて一連の対応は完了となります。
あとがき
かなりさらっと記載しましたが、実際の障害対応の現場はとても戦々恐々としております。
ユーザーや責任者・上司からの「早く復旧させろ」という圧で、体力よりも精神的に疲弊するんですよね。
もちろんシステム障害が発生しないようにするのも技術者の仕事ですし、そういった姿勢で仕事をするのが大切ですが、それでも完全に0にすることはできません。
システム障害が発生したらその裏で、人知れず頑張っている技術者がいるということも頭の片隅に留めておいていただけたら幸いです。
それではまた次回お会いしましょう。
