こんにちは、インフラチームの和田です。

10月3日（木）、4日（金）に神田明神ホールで開催されたAWS DevDay Tokyo 2019にて、アマゾン ウェブサービス ジャパン株式会社の畑様とともに登壇し、「Chaos Engineering 〜入門と実例〜」と題するセッションを行いました。前半の畑様のパートではChaos Engineeringの歴史、関連するツール、最新のトレンドを紹介していただき、後半の私のパートでは社内での取り組みと今後どのようなアプローチを考えているかをシェアさせていただきました。
当日お越しいただいた皆さまや中継をご覧になっていた皆さまのChaos Engineeringに対する考え方に、何かしらのインパクトを与えられたのであれば幸いです。

資料は下記のリンク先から確認できます。
[Chaos Engineering 〜入門と実例〜]

セッション終了後に「Ask the speaker」で質問いただいた内容も踏まえて、Q＆A形式で補足いたします。

Q: そもそもChaos Engineeringを始めたきっかけは？

2017年頃より新規タイトルのリリース前に耐障害性を高める取り組みをしたことがきっかけとなります。会社設立以後、モバゲー向けのゲーム提供が主軸でしたが、ネイティブアプリの台頭でモバイルゲームのトレンドが変化しました。インフラ環境もオンプレからクラウドへと拡大、幸いなことにユーザー数も増加し、弊社のコンテンツに対する期待値も高くなりました。そういった中でシステムの稼働率が低下することになれば、ユーザーや信頼を失うことにもつながりますし、諸々のオペレーションも発生します。これに対してChaos Engineeringは、システムを意図的に不安定にすることで事前に脆弱性を探り、対策を考えることができるという点で、最適なエンジニアリング手法であると考えています。

Q: ツールはどういったものを使ったか？

AWSコンポーネントの故障・障害やネットワーク遮断などのイベントはAWS APIを用いて発生させました。また、インスタンスリソースの枯渇については、Linuxベースの標準コマンドやディストリビューションのコマンドを利用して実施しました。その他、プログラム中に直接レイテンシーを注入するも実験もしました。[Awesome Chaos Engineering]では多くのツールが列挙されていますが、Chaos Engineeringを行う必須のツールではないと考えています。

Q: 本番環境ではやらないのか？

もちろん実トラフィックが流れる本番環境で実施することが望ましいですが、現状では開発環境のみでの実績となります。開発環境で実践しても意味がないのではないか、というとそうでもないです。事例で一部ご紹介したようなインスタンス内部のプロキシが抱えていた障害の種を事前に発見し、対策できたことからも、開発環境でも十分価値のあるプラクティスができるという感触を持っています。ハードルが高いという印象をお持ちの方は、まずは開発環境から試すことをお勧めします。

終わりに

Cygamesのインフラチームでは、高速かつ安定的にゲームを提供できるように、目立たないながらもコツコツと業務に取り組んでおります。今回ご紹介した取り組みに限らず、ゲームシステムの構築・運用から、システムパフォーマンスの改善、オンコールや開発者が抱える繰り返し作業の効率化、新規のミドルウェア・サービスの導入検証、などと幅広い業務があります。
また、最近では、コンテナオーケストレーションツールとしてデファクトスタンダードになっている、Kubernetesに移行するプロジェクトも出てきており、モダンなシステムへの転換も着々と進んでいます。そんなインフラチームでは、ゲームインフラに興味のある方、またセッションでご紹介したChaos Engineeringの取り組みにご興味のある方を募集しております。詳細はこちらをご確認ください。

最後に予告となります。セッション内でChaos Conf 2019に参加した様子に触れましたが、もう少し詳しい内容をこちらのブログに掲載予定です。お楽しみに。