Bug Shooting Challenge #2 参加記
はじめに
タイトルにもありますが, この記事はBug Shooting Challenge#2の参加記になります。
この記事の目的は, 時系列に沿ってざっくりとBug Shooting Challenge#2を振り返ることです。
この記事の概要は次のとおりです。
もくじ
Bug Shooting Challengeとは
Bug Shooting Challenge（以下BSCとします）とは, 2人1組となって、ゲームサーバのログから不具合の原因を特定し、ソースコードの修正までを行なうChallengeのことです。
詳しくは, 次のリンクをご参照ください。
- 学生対象 不具合調査体験ワークショップのご紹介 - mixi developers - Medium
- mixi GROUP presents「Bug Shooting Challenge」 - NAVER まとめ
きっかけ
きっかけは, mixiさんからのメールでした。mixiさんの+Challenge系は面白いという噂を耳にしていたため, 申し込みました。
申し込んだ後に事前課題が与えられたので, 事前課題を解いて提出し, とおりますようにとお祈りをしていました。
結果は当選だったので, 喜んだのをよく覚えています。
イベント前日までにしたこと
Slackで要求された, DockerおよびDocker Composeのインストールを行いました。
Dockerは使用したことがあったのですが, Docker Composeはあまり使用したことがなかったので, 次の記事を読んでおきました。
当日したこと
会場に到着するまで
起床Challengeに成功して家を出ました。
渋谷駅に到着したものの, 渋谷駅付近で迷いました。 高低差が多く, 道も多いため方向音痴の私としては大変でした。
会場に到着してから
会場には, AからJまでのグループがあったと思います。その中で, 私はHグループに分類されました。
イベントは, 次の流れで行われるようでした。
- スタッフの方々による技術解説
- 昼食
- 本番前のチュートリアル
- 本番
- 夕食と交流会
スタッフの方々による技術解説
田村さん
CREについてご説明いただきました。
CREとは, Customer Reliability Engineeringの略で, CS（Customer）とエンジニアを繋ぐ架け橋になる存在とのこと。
さらに, 本イベント中は私たち参加者がCREとなり, 不具合調査および問題解決に当たって欲しいとのことでした。
佐藤さん
次の技術についてご説明いただきました。
Ruby/Rails
Rubyに関しては, 20分ではじめるRubyや公式リファレンスを見てほしいとのことでした。
ちょっとした動作を確認するためにRubyを使いたい場合は, インタラクティブシェルを使うと便利らしいです。
$ docker run -it -rm ruby:2.5 irb- pryもオススメ
Git/GitHub
Gitとは, 分散型バージョン管理システムのこと。 GitHubとは, Git向けのリポジトリホスティングサービスのこと。
Git-Challengeもやっているので, 参加してほしいとのことでした。
Docker/Docker Compose
Dockerコンテナを活用することで, 環境を容易に用意できます。最近は, 異なるアーキテクチャのコンテナも起動できるとのこと。
佐野さん
SQL
はい。
Hadoop（Apache Hive）
オープンソースの分散ファイルシステムおよび分散処理基盤で, SQL Likeのクエリを投げられるとのこと（HiveQL）。
AWS EMR（Elastic MapReduce）でS3上のデータに対して, EC2インスタンスのクラスタで分散処理を実行できるとのこと。
メリットは, 膨れ上がったデータを高速に処理できたり, 低コストでスケールアウトできたりするとのこと。
昼食
釜飯をいただきました。昼食は, スタッフの佐藤さんと大谷さん, 隣のGグループの方々とご一緒しました。
本番前のチュートリアル & 本番
問題は非公開とのことなので, 割愛します。
スタッフの方々からの講評
バグレポートには実際のログを載せよう
色々なバグレポートがありましたが, 大抵が要点は抑えられていたとのことでした。しかし, バグレポートにバグの根拠となるログ自体を載せているグループは少なかったようでした。
バグレポートは書いた人のためにあるのではなく, 読む人のためにあるものです。読む人がログを見ることができるとは限らないので,実際のログも載せるとよいとのことでした。
チートは許さないという確固たる意志を持とう
CREである以上, チートは絶対に許さないという強い意思をもつべきとのことでした。
夕食 & 交流会
食事が豪華でした。数人とお話しましたが, やはり知らない分野の話を聞くのは面白かったです。まだ知らない世界があると思うとわくわくしてきますね。
また, 競プロ・CTF勢の多さが印象的でした。普段はこれらの分野の話ができないので, かなり楽しめました。
まとめ
今回のBSCを通して得られた知見を5つまとめてみました。
キャッシュとは程々の付き合いをしよう
キャッシュは, 使わなくて済む場合は使わない方がよい。しかし, 使うと便利なことも事実です。そのため, 使えるときは整合性に気をつけながら, 程よく使うとよいとのことでした。
リクエストを信用してはならない
HTTPリクエストには, 不正なものが含まれることもあります。そのため, リクエストログは客観的に見るべきだそうです。それに加えて, 不正なリクエストが来ることを考慮してコードを書く癖をつけるとよいとのことです。
意味的にひとかたまりの処理を意識したコーディングをしよう
コーディングをする際に, 処理をグルーピングするとよいとのことです。たとえば, データベースとのやりとりをするときはトランザクションをひとかたまりの処理として意識できます。そうすることで, 一貫したコードを書くことが可能になるそうです。
また, エラーが出た時の挙動を理解しておくとよいとのことです。
その場しのぎの対応策は良くない
バグを発見したとしても, 対策方法は複数あることも珍しくないです。そこで, その場しのぎの対応策を選ぶのではなく, ユーザのためのアプリケーションであることを第一に考えた対応策を選定するべきだそうです。
また, 単に簡単な対応策のみをとると他のバグを誘発する恐れもあるため, 根本的な問題を解決するような対応策をとるべきであるとのことでした。
バグレポートのフォーマット
以下のように, What, Why, Howを具体的に書くと良いそうです。
- What（バグの説明）
- Why（原因/根拠）
- ここには実際のログを入れるとよい
- How（対応）
展望
BSCでのバグ対応は, 実際のアプリケーション開発においても意識面での実践ができそうです。
また, バグレポートの書き方はテストや仕様書, コメントを書く時にも転用できると考えます。基本的に他人が見る前提で, そのように書いた理由があれば具体的に書くとよいかもしれません。
スタッフの皆さんへ
BSCという機会を設けていただき, 本当にありがとうございました。イベント中は, 質問・要望に対して1つ1つ真摯に対応していただいたので, 本当に感謝しています。
ありがとうございました。お疲れ様でした。
おわりに
こういったイベントは, やはりよいですね。何より,自分の知らない知識や経験を得る機会になりますし, 参加者の研究内容や興味のある分野を聞く機会にもなります。こういった機会は日常生活ではあまり無いので貴重な時間でした。
また, 他の+Challengeも参加したいですね。そのためには, さらに知識と経験を積まねばならないな, という気持ちです。
ここまでが, BSCの参加記でした。 興味のある方は, 次回のBSCに参加してみては如何でしょうか(開催するのかは分かりかねますが)？
