はじめに
KCS部DSREチームのromです。
KCS部は、KADOKAWAグループ向けプライベートクラウド(KADOKAWA Cloud Service、以下KCS)を提供しており、主な利用者は株式会社ドワンゴがサービスを提供している「ニコニコ」です。 私の所属しているDSREチームでは、MySQLやRedis、Elasticsearch/KibanaといったDatastore関連のミドルウェアをマネージドサービスとして、KADOKAWAのグループ会社に提供しています。
今回は、MySQLのマネージドサービスであるRDB基盤で行なった障害対応演習について紹介します。
RDB基盤とは
RDB基盤とは、KCSがKADOKAWAグループ向けに提供しているMySQLのマネージドサービスです。 構成は以下の通りです。
- バージョン：MySQL 5.7系
- MySQL数（概算）：600
DSREチームによって全て構築・運用されています。 詳細は、がんばらないDBaaSの作り方 を参照ください。
メンバーが増えても障害対応は自然にスケールするわけではない
最近喜ばしいことに、DSREチームに中途の方と新卒の方の合計4人チームに加わっていただけました。
メンバーが増えてチームの戦力が増えたのですが、メンバーが増えたからといって運用が自然にスケールするわけではありませんでした。 いくつかの運用については、既存の手順書が古く現在とは異なっていたり、そもそも手順書のない運用がありました。 これらの運用について、新たなメンバーにも行っていただけるように手順書の整備や自動化を行い、属人性を排除していきました。 手順書の整備や自動化によってほとんどの運用については新たなメンバーにも行っていただけるようになりましたが、一方で、これだけでは運用をスケールできないものがありました。 それは、障害対応でした。
障害対応するには、対象のシステムに対する深い理解だけではなく、想定外の事象に対する問題解決力、調査力、判断力、チームワーク力など、様々な力が必要です。 これらの力は、書籍や手順書、日々の開発や運用だけで養うのは難しいもので、実践によって養われる側面が大きいものです。 また、障害対応の手順書があったとしても、対応をしたことのない人がいきなりやってうまくいくのはなかなか難しく、そもそも手順書自体にバグや不足のあることはよくあることです。 そのため、新メンバーに対していきなり障害対応をお願いするのは、難しいと考えました。 特に、新卒の方は、インフラの障害についての経験が豊富ではありません。 そこで、これらの力を養うために、障害対応演習を行いました。
以降では、まず、RDB基盤の障害対応演習のために行なった運用の整備について紹介します。次に、RDB基盤で行なった障害対応演習について紹介します。
意味のないアラートはなくし、意味のあるアラートだけにする
障害対応演習を行う前に、監視周りを整理しました。
RDB基盤では、想定される障害を検知できるようにモニターを定義していますが、次のような問題を抱える既存のモニターがいくつか存在していました。
- サービス影響がないのにモニターのアラートが鳴る
- モニターのアラートが鳴っても対応手段が不明である
- モニターがどのような意味でなぜ設定されているのか曖昧である
これらのモニターについて、以下の基準で必要/不要も含めて見直しをしていきました。
- SLOへの影響度
- 基盤利用者への価値
- 基盤運用への影響度
- 他のモニターによる検知可否
- 実績の有無
さらに、各モニターのアラートレベルを見直し、以下のように再定義して、適切なアラートレベルの設定をしました。
- レベル1: 次の営業日の日礼で確認して対応者をアサインして解決する。
- Slackのメンションなしで投稿。
- レベル2: 営業時間内ならばすぐに対応する。営業時間外ならば、次の営業日の日礼で確認して対応者をアサインして解決する。
- Slackの@hereメンションをつけて投稿。
- レベル3: 緊急かつ継続性があるので、電話のなった人がすぐに対応する。
- Slackの@channelメンション+電話による通知。
上記の見直しを行なっても、多くの基盤利用者にとっては意味があるが一部の基盤利用者には意味がない、というモニターはどうしても出てしまいました。 例えば、MySQLのレプリケーション遅延モニターについて一部の基盤利用サービスでは、バッチ処理などであらかじめ決まった期間の遅延が発生するがそれは問題でなかったり、RDB基盤で設定している閾値のレベルの遅延は問題にならない、といった場合です。 これらのようなモニターについては、個別に基盤利用者と話し合い、特定の時間だけモニターをミュートしたりアラートの閾値などのモニター自体の内容を見直すことで、意味のあるアラートだけにしていきました。
結果としていくつかのモニターについて、アラートレベルの変更をしたり、モニター自体を削除/変更/追加できました。
また、モニターそれぞれに対して、その対応手順を明らかにし、手順書を作成しました。 手順書は、アラートのSlack通知にリンクを貼り、対応者がすぐに参照できるようにしました。
これらの整備により、意味のあるモニターだけにでき、アラートが鳴っても対応者が何をすれば良いかが明確になりました。
障害対応演習
演習の種類
大きく分けて、2種類の演習をしました。
- 想定内の障害（対応手順書がある障害）に対する演習
- 想定外の障害（対応手順書は存在しない障害）に対する演習
想定内の障害（対応手順書がある障害）に対する演習
想定されている障害で、対応手順書があるものです。 手順書に従って適切に対応することの訓練になります。障害対応に慣れていないメンバー向けの訓練です。 今回は新メンバーの増加がやることのきっかけになったので、これをメインとしました。
実施した演習内容は、ディスクフルが起きた場合や再起動からインスタンスが復帰しない場合です。 これまでにRDB基盤で実際に起こったことがある障害で、これらを再現してアラートを鳴らし対応しました。
想定外の障害（対応手順書は存在しない障害）に対する演習
こちらは、対応手順が存在しないものです。 障害対応に慣れている人がもっとスキルを伸ばすための演習で、既存メンバー向けです。 想定外の障害を再現するのは想定外であるのだからできないので、 演習では、対応者に発生する障害の内容は秘密にして対応をしてもらうといった内容にしました。
実施した演習内容は、ヒューマンエラーにより設定値が不正となりMySQLがエラーとなってしまう場合や外部依存サービス（今回は監視SaaSのDatadog）がダウンした場合です。
演習の流れ
合計5回実施しました。
初回は障害対応の手順書の読み合わせを行いました。 初回以降は次の流れで実施しました。
- オンライン会議に集まる。
- KPT会の実施（KPT会については後述する）。
- 今回の障害対応演習の内容について説明する。
- 参加メンバーでペアを作る。
- 各ペア内でロール割り当てを行う。 ロールは、対応者（基盤運用者）、基盤利用者、基盤依存サービス、障害仕掛人。 ひとりが対応者（基盤運用者）になり、もうひとりが他のロールを兼務する。 各ロールがやることについては、後述する。
- オンライン会議の部屋をペアごとに分けて、演習を実施する。 Google Meetのブレークアウトセッション機能を使用する。
- ペアのロールを入れ替えて、もう一度演習を実施する。
- KPTの内容を記述する（KPTについては後述する）。
時間は1時間30分で、最初の30分でKPT会、後半の1時間で演習としました。
演習手順書を作成する
演習は一度行っただけでは、今後新たにメンバーが変わったり増加した場合に、対応できなくなります。 演習の手順書を作成することで、今後も繰り返し実施することを可能にしました。
実際に障害を発生させる
RDB基盤にはサービス影響がないSandbox環境というのがあるので、そこで障害を発生させるようにしました。 実際に障害を発生させるので、本番の障害時と同様のアラートがなり、現実に近い形で演習ができました。
ロールプレイする
チームのメンバーだけで演習できるようにロールを定義しました。 ロールは、対応者（基盤運用者）、基盤利用者、基盤依存サービス、障害仕掛人です。
対応者（基盤運用者）は、障害対応する人です。実際の障害時にはRDB基盤の運用者が担うものです。 基盤利用者は、RDB基盤を利用していただいている人です。 基盤依存サービスは、RDB基盤が利用している監視サービスや仮想化基盤などのRDB基盤外の基盤運用者です。 障害仕掛け人は、演習のための障害を実際に発生させる人です。
短い間隔でKPTする
毎回の演習の後にKPT会を実施しました。
KPT会とは、Keep（継続すること）、Problem（問題であったこと）をあげて、チーム皆で一緒にそれらに対してTry（今後取り組みこと）を考える会です。 これを毎回の演習で行い、改善していくように回していきました。
今回の演習を通して、数多くのKeep（継続すること）、Problem（問題であったこと）を明らかにし、それらについてTry（どのような手を打つか）を具体的なタスクとして切り出していくことができました。まだ、ここで挙げられたタスクを全て完了できていませんが、徐々に改善していっています。今回の障害対応演習はチームにとって初めての取り組みであったため、短い間隔でKPT会を実施して改善していけたのはよかったと考えています。
様々なKeepが上がりましたがその中でも意外だったのが、今回の障害対応演習がチームビルディングになったということでした。 今回の演習は新メンバーが多く、新メンバーで共同の作業をするという体験になったのがよかったようです。障害対応演習がチームビルディングになるというのは、想定していなかった効果で思いがけない発見でした。
最後に
RDB基盤における障害対応演習について紹介しました。
今回の障害対応演習により、チームのメンバーに安心して障害対応をお願いできるようになり、新メンバーには実際に対応を既にしていただいています。 また、この障害対応演習をきっかけに行った監視周りの整備によって、監視が健全な状態にできました。 最近、意味のないアラートによって休日に連絡が来ていたのが、なくなりました。大変嬉しいです。 今後は、新たにメンバーが増えた時や定期的な間隔で継続的に障害対応演習を実施していきたいと考えています。
一方で、課題はあります。 今回はRDB基盤のあるひとつのDBクラスタでの障害についての障害対応演習を行いました。 しかし、基盤全体にわたる大規模な障害や外部依存サービスと連携して対応する必要のある障害については演習できておらず、これらが課題だと認識しています。
障害対応演習を行うこと自体は、工数さえかければ難しくないことだと思います。 障害対応演習を行うのにネックになるのは、障害対応自体が緊急時のことであり、日々の開発タスクや運用タスクとは関連が少なく、チームの関心度が低いことだと思います。障害対応演習にそこまで工数をかけたくない、という判断がされやすいものであると思います。 障害が起きた際は、障害対応演習をやろうという声はあがることがよくあると思いますが、なかなか工数をかけて実行はされにくいものです。 今回、新メンバーの増加という背景のもと、障害対応をスケールさせるために障害対応演習に対して工数をかけて実施させていただきました。 そして、実際に新メンバーに障害対応をしていただくという結果を出すことができ、 障害対応演習はチームの人のシステムの信頼性の確保のために効果があるシステムだということを示すことができ、嬉しく思います。 このように、RDB基盤では人のシステムの信頼性を向上させるために、今回行った障害対応演習のように運用改善を引き続き行っていきたいと思います。
最後に、一緒に働ける仲間も募集しています。 興味のある方は採用サイトをご確認の上ご応募お待ちしています。
