初めまして。インフラチームの和田 明久と申します。

2018年12月4日に開催された、日本で初開催となる Amazon Game Developers Day(主催:アマゾン ウェブ サービス ジャパン株式会社)にて「モバイルゲームにおけるカオスエンジニアリング実践に向けて」と題して、弊社におけるカオスエンジニアリングの取り組みについてご紹介させていただきました。会場にご足労いただいたみなさま、誠にありがとうございました。セッション内容を少し振り返ってみます。

弊社の運用タイトルは会社設立以降、増加の一途を辿り、定常的な安定稼働が求められています。モバイルゲームはユーザ様の1アクションがユーザエクスペリエンス(UX)に直結するため、高い稼働率と低遅延が要求されます。ひとたび障害が発生するとUX低下はもとより、機会損失・ユーザ離れ・ゲームへの信頼性低下を招きます。近年、ITインフラ環境が障害等の不安定になっても、耐障害性の高いシステム構築を志向するカオスエンジニアリングという技法が登場しています。そこで、弊社においてもより信頼のおけるゲームシステムを目指すべく、開発フェーズとインフラチーム内において実践したカオスエクスペリメントの一部をご紹介させて頂きました。

こちらが講演資料となります。是非一度お目を通していただけると幸いです。

※ スライド中の「Chaos Loop」「Chaos Sheet」などは社内独自の表現です。

スライドでは説明しきれなかった箇所を補足させていただきます。

例示

カオスエンジニアリングの考え方を我々の現実社会に存在する事例で捉え直しています。例えばインフルエンザの予防接種、災害時において1人でも多くの生命を救うための防災訓練など、被害の拡大を最小化するような事前準備があります。このような考え方をITインフラに取り入れたものがカオスエンジニアリングであり、ITインフラの障害訓練のようなものです。

ChaosConf2018

2018年9月末にSanFransiscoで開催されたChaosConf2018(主催:Gremlin Inc.)へ参加してまいりました。基本から最先端事例を学べるセッションで、広告・メディア・流通といった業種のSREやインフラエンジニアが登壇しておりました。一般的な事例だとサービスのプロダクション環境における一部のコンポーネント（インスタンス）を停止させても自律的に回復するシステムかどうか実験していることが多いですが、”デプロイフローで擬似的にコンポーネントを停止させても正常にロールバックされるか”、”アプリケーションコード中にユーザ単位で障害注入(Fault Injection)しても動作に支障がないか”、といった仮説に基づいたアプローチをしている組織もありました。カオスエンジニアリングの応用範囲は広く、弊社でもアプローチできる対象はいくらでもあることを実感し、帰国後早々に新たな実験対象を考え、手をつけられる箇所から導入しています。内容はこちらから全セッションが確認できますので、興味がある方はご参照ください。

事例 RDS Failover 中に出てくるカーネルパラメーター

Multi-AZ(Availability Zone)構成のRDSでFailoverが発生すると新しいAZに切り替わりIPアドレスも新しくなります。こういった自体に備えるためDNS名でアクセスしていますが、Mysqlクエリ実行中にFailoverが実施されると、Webサーバからの接続は応答待ちとなりプロセスを維持します。こちらが大量発生した場合に新規のリクエストを受け付けなくなることを回避するべく、TCP接続のタイムアウトと再送間隔を短縮するようにカーネルパラメーター（tcp_retries2）を最小推奨値8に修正しました。これによりデフォルト比でタイムアウト時間が1/9となり不要なコネクション解放に繋がりました。

最後に

今回の登壇内容がモバイルゲームに限らずITインフラを支える部門にいらっしゃる方にとって一助となれば幸いです。今後もカオスエンジニアリングを利用して高品質なシステム設計や構築を進めてまいります。皆様のお役に立てそうな事例ができましたら、またご紹介させていただきます。

Cygamesではカオスエンジニアリングに関連する取り組みにご興味のある方、もしくは実践経験のある方を募集しております。国内での事例が少ないため手探りでのアプローチになることも想定されますが、自ら道を切り開いてやりとげるような心持ちの方と高品質なシステムを構築していければと思います。詳細はこちらをご覧ください。