概要
日本標準時の2022年10月02日午前05時頃、Minetestサーバーのネットワークの設定切り替えを行った。設定変更に伴い割り当てられるIPアドレスが変わり、05時09分から05時44までの35分間サービスに繋がらない状況となり、最小で3人、最大で全ユーザーが影響を受けた。
影響範囲
05時09分の障害発生から05時44分の完全な復旧までの35分間サービスダウンした。障害発生時のログインユーザー数は3であった。そのため影響を受けた人数は最小で3人、最大で全ユーザーであった。
発生した事象
以下に発生した事象を時系列で記述する。
時刻 | 内容 | 備考 |
---|---|---|
2022-10-02 04:30(頃) | ネットワークの切り替え作業の事前検証を開始する。 | |
2022-10-02 05:00(頃) | ネットワークの切り替え作業の事前検証を終了する。 | |
2022-10-02 05:05(頃) | ネットワークの切り替え作業を開始する。 | |
2022-10-02 05:09 | IPアドレスが変わり、全ユーザーはゲームから強制切断される。 | これを障害発生開始とする。 |
2022-10-02 05:09(頃) | ログから障害が発生していることを認識する。 | |
2022-10-02 05:09(頃) | 新しいIPアドレスをDNSで引けるように設定を変更する。 | |
2022-10-02 05:09 | 作業担当者の端末からログインできることを確認する。 | |
2022-10-02 05:12 | 障害と復旧の報告をメールで送信する。 | |
2022-10-02 05:17 | サポートのためのメールを送信する。 | |
2022-10-02 05:30 | サポートのためのメールを送信する。 | |
2022-10-02 05:32 | ユーザーから接続できない旨の問い合せメールが届く。 | |
2022-10-02 05:32(頃) | 対面サポートのためのGoogle Meetを準備する。 | |
2022-10-02 05:34 | Google Meetのアナウンスのメールを送信する。 | |
2022-10-02 05:39 | 最初のユーザーのログインをログから視認する。 | |
2022-10-02 05:42 | ユーザーの状況をゲーム内チャットで確認する。 | 1台だけログインできていないことが判明する。 |
2022-10-02 05:43 | 新しいIPアドレスを伝え、直接入力するように案内する。 | |
2022-10-02 05:44 | ログイン不能であった1台からのログインをログから視認する。 | これを障害復旧完了とする。 |
本来の作業の目的
Minetestサーバーをコストダウンするため、GCEで使用しているネットワークの層(ティア)を変更することが、今回の作業の目的であった。MinetestサーバーにはNI(ネットワークインターフェース)が1つある。そのNIはプレミアム層を利用しており、更に静的IPアドレス割り当て(予約)を行っていた。プレミアム層の下り通信の料金はスタンダード層と比較すると割高となる。そこで使用する層をスタンダードに変更することにした。
事前検証
2022年10月02日午前04時30分頃から事前検証を開始した。検証用のインスタンスを作成し、プレミアム層からスタンダード層への切り替えの手順をGCEの管理用Webコンソールから実施した。正常に切り替えが行われることを確認したが、インスタンスの起動のみを確認し、IPアドレスの状態やサーバーとの疎通を確認しなかった。
障害発生時の状況
事前検証の作業後、作業担当者は本番サーバーのネットワークの切り替え作業として同様の手順を管理用Webコンソールから実施した。この時3名のユーザーがMinetestのプレイ中であった。設定を変更しネットワークが切り替わったことでIPアドレスも変更になった。そのためログインしていたユーザーは、ゲームサーバーと疎通できなくなり、05時09分にタイムアウト状態としてゲームから強制的に切断された。
障害対応時の状況
05時09分、ネットワークの切り替えた後に作業担当者は新しいIPアドレスを用いてログインしログを確認し、事象の発生を認識した。同時に新しいIPアドレスをDNSに設定していないことに気が付いた。この時はまだDNSの設定をしておらず、FQDNで正しいIPアドレスを引けない状態であった。
05時09分頃(同時刻)、直ちにDNSの設定変更を行った。そして05時09分(同時刻)に作業担当者の端末からゲームへのログインができることを確認した。
05時12分、障害と復旧の報告をメールで送信した。しばらくログを確認していたが、誰もログインしてこないため、更にアナウンスメールを2通送信した。
05時32分、ユーザーから接続できない旨の問い合せメールが届いた。そこでGoogle Meetを準備し、05時34分にGoogle MeetのURLを記載し対面でのサポートのためのアナウンスを送信した。ただしGoogle Meetにはユーザーは誰もログインせず、その後対面でのサポートをすることはなかった。
05時39分、最初のユーザーのログインをログから確認した。作業担当者はゲーム内にログインし、05時42分にユーザーの状況をゲーム内チャットで確認した。そこで1台だけログインできない端末があると報告を受けた。
05時43分、変更後のIPアドレスを伝え直接入力してアクセスするように案内した。
05時44分、ログインできていなかったユーザーのログインをログから確認し、障害は復旧した。
原因
今回のサービスダウンは、ネットワークの切り替え手順の不備によって接続断が発生した。また間接的な原因として、切り替え手順の確認不足、事前検証時の確認不足がなかったこと、メンテナンス実施タイミングを検討しなかったことが挙げられる。
本来はどうするべきだったか
無停止で実施するか停止ありで実施するかによって異なる方法を取ることができる。
サービス停止してメンテナンスを実施する
常時利用されているわけではないため、メンテナンスのためサービス停止できる。そのためあまり利用されていない深夜帯や平日日中にメンテナンスを実施するべきであった。メンテナンス日時を決め、アナウンスを行う必要があった。その場合のメンテナンス手順としては今回の手順と同じでよい。
NIを2つ作成し常に通信を受信できる状態でメンテナンスを実施する
もし停止ができないような状況であれば、NIを2つ作成し必ず外部からの疎通を受けとれる構成に変更してから、NIの切り替えを実施するべきであった。つまり次の順序で構成を変更する。
- 新しい層のNIを追加する。
- DNSの設定を切り替える。
- 古いNIを削除する。
この場合、瞬断の可能性はあるが即座に接続を再開できる。
事前検証での確認を手厚くする
事前検証での疎通確認時に、Minetestサーバーへのログインまでを確認するべきであった。
どのような施策があれば防げたか、もしくは被害を抑えられたか
作業手順や仕組みを工夫することで、問題の発生を防いだり、もしくは被害を抑えられたかという観点で考えてみる。
メンテナンスアナウンスを行えば突然切断された時の混乱を小さくできたかもしれない
今回のメンテナンスは、事前にメンテナンスに関するアナウンスを行わなかった。その結果、ユーザーは突然接続を失い、よくわからない状況のまま最初の問い合わせをするまでに20分以上かかった。事前にメンテナンス時刻と、問題があった時の問い合わせ先などの情報を整理しておけば混乱を抑えられたかもしれない。また即時、問い合せ可能なチャット環境を整備していなかった。
メンテナンス手順のレビューを行えば手順の問題に気が付くことができたかもしれない
メンテナンス手順に問題があったのだが、事前のレビューにより問題を指摘できればこの事象は発生しなかった。
対応
環境の復旧に必要な対応は全て完了した。そのため追加で必要な対応はない。
再発防止策
以下を実施する。
- メンテナンスアナウンスは必ず実施する。
- メンテナンス手順は必ず文書化する。
- メンテナンス手順はレビューを受ける。