engineering minne

minne の障害訓練(ミンドリ)のご紹介

engineering minne

あけましておめでとうございます。ペパボテックブログ 2019 年一発目の記事は minne 事業部チーフテクニカルリードの @_shiro16 がお送りします。

minne では定期的に障害訓練を行なっています。そこで今回はなぜ障害訓練を実施するようになったのか?や実際に実施してみて等のご紹介をしたいと思います。

はじめに

障害訓練の名前についてミンドリと名付ける事にしました。障害訓練の内容をテックブログに書こうと思っているんですがネーミングセンスが無なので困っていると社の Slack で相談したところ @monochromegane が下記のような理由でミンドリという名前を提案してくれたので、採用させてもらいました。

経緯

minne にて sidekiq の特定の job の処理に時間がかかるようになり、一定時間の job を捌ける件数より積まれる件数が多く job の件数が増え続けこのままだと ElastiCache のメモリ容量の空きなどに影響が出るという障害が発生しました。

この障害自体は

  1. 処理に時間がかかるようになった job の特定
  2. 特定した job は service として重要度が高いのかを調べる
  3. 重要度によって対応内容を考える

といった手順で対応を進め、今回の job に関しては重要度が高くないものだったので

  1. 一旦 job を積まないようにする
  2. 積まれている job を消す
  3. job のチューニングを行い再度 job が積まれるようにする

という手順で解決しました。重要度によっては job を捌ききれるだけの server を用意する等の対応もあるかと思います。

上記の障害はあるエンジニアが対応を行なったのですが、別のエンジニアと 1on1 をした際にこの障害の時に「sidekiq についてなんとなくしか理解していないので、より詳しいであろう人に任せてしまったが自分でも対応できるようになりたい。しかし、sidekiq のコードを読んだりするだけではダメだと思っている」といった内容の相談があったので「それでは開発環境で同じような障害を僕が起こすので、その障害を解消するというのはどうですか?」という提案を行なったところ是非やりたいとなったので開催することになったというのが第一回の始まりです。

第一回が終わり感想を聞いたところ、このまま終わりではなく継続して開発するといいのでは?と考えて第二回の開催の issue を作成したところ他のエンジニアも参加したいとコメントがあり、現在は参加したいエンジニアが参加する形式になっています。

進め方

  1. 開催 1,2 週間前に開催の issue を立てる(この段階で問題は非公開)
  2. 参加したい人がコメントする
  3. 開催日までに @_shiro16 が問題を考える
  4. 前日までに問題の準備が必要なら準備をしておく
  5. 開催当日に障害が起きたことを伝えて解決に動いてもらう(この段階で issue を更新し調査条件などを追記)
  6. 障害を解消するために行なった調査や実行したコマンドは全てメモって貰う
  7. 解消できたと思ったら、原因とどうやって解消したか?を報告して貰い合っていたら完了

上記のような感じで進めています。

第一回の問題は経緯で説明した sidekiq の job が詰まったという状況を解決するというのも。特定の job に sleep(60) といったコードを仕込みその job を大量に積むことによって同じような状況を再現しました。 sidekiq について理解を深めるというのが目的の一つなので sidekiq の dashboard は使用禁止という条件を設けて対応を行なって貰いました。

実際の issue の様子は下記です。

第二回は consul dns を使用している環境で dns から host が引けなくなるという状況を解決するというものを用意しました。(内容は割愛)

6 のメモに関しては第一回では一人のみだったので issue にコメントしてもらっていましたが、二回目は参加者が複数になったことから各自 gist を用意して貰いそちらに書いて貰いました。ペパボ社内では障害の際に Slack の ch やスレを活用しているのでより実践に近い状況で行うと良いかなと思い次回以降は変更する予定です。

実施してみて

実際に参加しているエンジニアの感想は「めっちゃ勉強になったし楽しかったです」という声や「なんとなく理解していたものへの理解がより深まった」等ありました。 次回からはより実践を意識して障害が発生した場合にまずはどう動くか?(誰に連絡するか?等)も含めてやっていければと考えています。

課題を用意する側も他のエンジニアやデザイナーが使っている開発環境に影響を与えずに特定の host のみを壊すにはどうすればいいか?というのを考える必要があるので学ぶことも多くあり楽しいと感じました。 また、課題をクリアした人はその課題を用意できると思うので今後やりたいという人が出てきたときに課題をクリアした人がその課題を再現する環境を用意するなどが出来ると良いなと思っています。

この活動を行なっていたところ @_shiro16 のペパボ公式ライバルである @pyama さんがペパボ全社で行えるような仕組みを用意しだしたので社の人々は乞うご期待という感じです。 ペパボ全体では汎用的な課題を、各 service ではその service に特化した技術などを課題にして行けたら良いですね。