DeNA QA Night #2 開催レポート(パネルディスカッションパート)

こんにちは。品質管理部QC2Gの柏倉直樹です。Eコマース、ライブ配信サービス、インキュベーションプロジェクトなどのQAリーダーを勤めつつ、DeNA品質管理部の知名度アップとQA業界への貢献を目指し、DeNA QA Nightと言うイベントのプロジェクトオーナーを担っています。今回はそのDeNA QA Nightの第2回目開催レポートをお届けします。

はじめに

DeNA QA Nightとは、ソフトウェアテスト・品質に関しての技術や事例を共有・議論する事を目的とした定期開催イベントです。ソフトウェアテスト・品質に関して広く議論する機会を提供することでテスト・品質コミュニティへの貢献を目指し企画・開催しております。

今回はその第2回目の開催レポートです。 第1回目の開催レポートもありますので、ご興味のある方はご覧ください。
第1回 DeNA QA Nightレポート(前半)
第1回 DeNA QA Nightレポート(後半)

第2回 DeNA QA Nightは2部構成となっています。

【前半】
DeNA品質管理部QC1Gの山本幸寛よりゲームQAにおける品質改善の取り組みについて発表しました。 上流工程でレビューを実施すると下流工程でみんなハッピーになるよ、と言う話ですが、上流でレビューを実施するまでに持っていくのがなかなか大変だったりしますよね。インクリメンタルなレビューであれば、比較的導入がしやすく、効果も出るよ、と言った内容ですので、興味のある方は是非こちらのブログもご覧ください。

【後半】
本ブログはこの後半をターゲットに書いています。
後半では、社外から2名の講師をお呼びしてパネルディスカッションを開催しました。

■テーマ
QAの過去から現在・現在から未来

■パネラー(社外講師)
奈良 隆正 氏
 NARAコンサルティング代表
 『ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点』著者

西 康晴 氏
 電気通信大学
 ソフトウェアテスト技術振興協会 理事長
 JSTQB 運営委員長

また、モデレーターとしてDeNA品質管理部QC2Gの河野哲也が登壇しました。

■パネルディスカッションの流れ
・イントロダクションで本日のテーマについて会場と認識を合わせる(5min)
・オープニングスピーチでまずは西氏のご意見について伺う(20min)
・会場を交えてパネルディスカッション(50min)

イントロダクション

イントロダクションではモデレーターの河野より、本日のテーマ、パネル企画の意図を会場と共有しました。ここではその概要について簡単に触れておきます。

開発手法の変化やビジネスモデルの変化、そして品質保証に求められることの変化にともない、かつて有効とされてきた仕組みや仕掛けが通用しなくなってきているのではないか。しかし、その全てが現在でも通用しないわけではなく、現在でも引き続き有効なものとそうでないものがありそう。

そこで、
・基礎知識として覚えておく必要があるもの
・今でも使い物になるもの
・忘れても良さそうなもの
と言う観点から過去の技術、仕掛け、仕組みについてパネルディスカッション形式で意見を交換したい。さらにそこから、未来の技術的展望を交えながら考え方・技術・プラクティスを整理していきたい。

過去と現在のコンテキストの違いを表にまとめるとこんな感じ。(イントロダクション資料から抜粋)
qa_night_2_pic01new.png

イントロダクション資料全編はこちら

Qa night#2 intro from Tetsuya Kouno

イントロダクションではこのような感じの大枠を会場と共有しました。
いよいよオープニングスピーチに入っていきます。

オープニングスピーチ

オープニングスピーチでは、パネルディスカッションに先立ち西さんご自身のお考えについてお話しいただきました。

洞窟の奥には隆盛を誇った古代都市の遺跡がある...と言うなんとも聴衆の興味をそそりそうな一言からスピーチが始まりました。さすが喋り慣れてる人は違いますね。と言う個人的な感想を述べてみたところでオープニングスピーチの概要はこちらです。

まずは時代を次の3つに分け、それぞれの時代の特徴と、どんな開発・QAだったかを紹介。

【かなり昔('70年代〜'80年代)】
 ■特徴
  内製や関係の強い企業に発注していた(汎用機)
  あまり複雑でなく、規模はそこそこだった
 ■どんな開発・QAか
  中身をちゃんと理解して納得して作っていた
  全体としてどんな品質で何が問題なのかが分かっていた

【ちょっと昔('90年代〜'00年代)】
 ■特徴
  多重下請構造に基づいたプロジェクト制だった(エンプラ・組込み)
  かなり複雑でかなり大規模だった
 ■どんな開発・QAか
  よく分からないけど指示に従って業務をこなす意識で作っていた
  全体としてどんな品質で何が問題なのかが分かっていなかった

【現在から未来('10年代以降)】
 ■特徴
  内製化が進んできている(クラウド)
  かなり複雑で徐々に大規模になっていく(が経験はない)
 ■どんな開発・QAか
  中身をちゃんと理解して納得して作れている?
  全体としてどんな品質で何が問題なのかが分かっている?

このように、時代とともに特徴や開発・QAの内容も変化している。コンテキストが変化しているので、かつて成功していたQAのやり方をそのまま現代でも適用すると概ね失敗する。リソースにかかる値段も昔と現代とではまるで違うし、オープンソースやクラウドが当たり前になり、全て自社開発で中身を把握できていた時代は過ぎ去った。

これからのQAは、昔からの良い考え方をさらに変化させながら現代に合わせて進化させることが必要。
例えば
・優れた組織イニシアティブの創出や醸成
・品質保証戦略のデザインと着実な積み重ね
・みんなが嬉しくなる品質マネジメントシステムの構築
などが進化のカギである。

逆に、よく陥りがちなワナとしては、
・おかしな組織イニシアティブの創出や醸成
・役に立たない品質保証戦略のコピペとやりっぱなし
・誰も嬉しくならない品質マネジメントシステムの構築
などが挙げられる。

詳細は西さんの資料に書いてあるので、興味がある方はぜひご参照ください!

DeNA QA night #2 presentation from Yasuharu Nishi

さて、オープニングスピーチでの西さんのお話を踏まえ、いよいよ奈良さんにご登場いただき、会場全体を巻き込んでディスカッションしていきます。

パネルディスカッション

パネルディスカッションでは今でも使い物になりそうなもの、基礎知識として必要なもの、忘れても良さそうなもの、の3種類に事前に分類していただきました。 qa_night_2_pic02new.png

この表をもとに、奈良さん、西さん、河野がそれぞれどのような意図で分類したのかを議論していきました。議論のエッセンスをテーマごとに紹介していきますね。なお、時間の関係で全てのテーマについてディスカッションできなかったため、議論できたテーマのみ紹介します。

【品質管理手法】
・考え方は知っておいた方が良いが、実際に使用する機会は少ない
・コンサルがよく品質管理手法を提案するが、騙されないためにも知っておくべき

【品質管理図】
・テストがどこまで進んでいるかを答えられるようにするためのツール
・テスト期間が3日間など短い場合はあまり有効ではなさそう
・スプリントの性質によるが、ある程度のテスト期間がある場合はリリースごとでの利用価値はありそう
・テストがいつ終わりそうか、を答えられる状況にあるのならどんなツールを使ったって構わない

【V&V(Verification:検証とValidation:妥当性確認)】
・検証と妥当性確認はどちらか一方ではダメ。全体を考えることがとても大切
・レビューを実施する上でもV&Vの考え方を理解していないとうまくレビューできない
・自動化すべきところと人間が考えるべきところをきちんと整理するためにも有効

【探針・信頼度成長モデル】
・テストがいつ終わるのか予想するための手法として活用していた
・組織やプロダクトなど各種特性によって曲線は使い分ける必要がある
・テスト期間が3ヶ月とか長期間にわたる場合は有効
・現在では全く使い物にならないと言う意見もあり
・ただしコンサルに騙されないためには知っておくべき

【規模(LOC・FP)ベースの品質マネジメント】
・オープンソースを活用する現在の開発において、自分が書いたソースの行数だけを見て何が測定できるのか疑問
・しかし、ソフトウェアの目方を測るためにはなんらかの指針が必要
・LOCよりも現在の開発手法にあった測定指標があるのではないか、と言う意見もある
・ソフトウェアの目方に関係なく、「自分たちはきちんとテストできてるよね」とみんなで納得できる方法を模索する方が大切では?

【メトリクス(GQM)、品質特性】
・何も考えずに、上司が取れと言ったからメトリクスを取っているような場合は意味がない
・なんでもかんでもむやみにメトリクスを取れば良いと言うものではない
・根拠を示すためにデータを取ることは大切であり、データをもとに議論するべき
・メトリクスを検討するにあたってGQMは役に立つが、やってみると結構難しい

【ソフトウェア工学】
・上手にソフトウェアを開発するための知見を集めたのがソフトウェア工学
・ソフトウェアに関わって飯を食っている人は知っておくべき
・例えばソフトウェアを開発して飯を食っている人はコードだけ書ければお金がもらえるか?否、見積もりしたり管理したり様々なことをやっている
・自動車工学を知らない人が作った自動車に乗りたいか?航空工学を知らない人が作った飛行機に乗りたいか?ソフトウェア工学も一緒

【会場からの質問1】
■Question
「基準に従え!人力でなんとかしろ!誰の責任だ!マニュアル化しろ!文書!文書!文書!ハンコー!」と言った類の管理が横行しモチベーションの低下や仕事の矮小化、視野狭窄が起こっている現場で働いているのですが、どうすればこの現状を打破できますか?
■Answer
・スキルを身につけて会社を辞めれば良いと思う
・会社に残ったまま状況を変えるのは相当な難問。もしその道を選ぶとしたら、小さなプロジェクトでこっそり結果を出して、少しずつ隣のプロジェクトにも波及させていくようなやり方が良い
・今日のような勉強会に仲間数人で参加するのも手。むしろ一人で参加してもあまり意味がない。複数人で参加して課題を共有すれば、会社に持ち帰りやすい。一人で持ち帰ろうとしても、勉強会で感じた課題感を仲間と共有するのは難しい。

【会場からの質問2】
■Question
次の時代のQAが身につけるべきスキルとはなんですか?
■Answer
・テスト技術の話に閉じず、サービスの品質とは?を考える必要がある
・自分が携わっているサービスは社会の課題を本当に解決できているか?ユーザーに価値を提供できているか?まで考える範囲を広げる必要がある
・身につけるべきものの範囲が広がって来ている
・自分の組織でだけ通用する技術を磨いてもダメ
・積極的に社外の勉強会に参加したり、自らが発表して周囲からフィードバックをもらう事も有効

以上、ここまでがパネルディスカッションのエッセンス紹介です。

まとめ

さて、いかがでしたでしょうか。冒頭でお伝えしたテーマについて振り返りましょう。テーマは、
・基礎知識として覚えておく必要があるもの
・今でも使い物になるもの
・忘れても良さそうなもの
と言う観点から過去の技術、仕掛け、仕組みについてパネルディスカッション形式で意見を交換したい。さらにそこから、未来の技術的展望を交えながら考え方・技術・プラクティスを整理していきたい。と言うものでした。

ディスカッションから見えてきた答えとしては、完全に忘れても良いと言えるものは無く、どれも知識として有しておく必要がありそう、と言う事ですね。また、V&Vやソフトウェア工学と言った分野はこれからも間違いなく必要なものと言えそうです。それから、未来において必要なスキルとしては、テスト技術に閉じずに自らが携わるサービスが世の中の課題を解決しているか、また、ユーザーに価値を提供できているか、と言ったところまで視野を広げて仕事ができるかがポイントになりそうですね。

ここまでレポートを書いてきましたが、本記事をお読みいただいた読者の皆様に少しでも刺激を与えることが出来たなら幸いです。そして、この記事を読んで「次回DeNA QA Nightに行ってみたい!」と思っていただけたらなお幸甚です。

最後に

DeNA QA Nightは半年に1回のペースで継続開催を予定しています。次回は8月末くらいを予定しています。案内はconnpassから発信しますので、ぜひグループ登録をお願いします。
connpassグループの登録はこちらから

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA QA Night #2 開催レポート(第一部)

はじめに

こんにちは、品質管理部の山本です。 ゲーム関連のQAを担当しております。

先日(2019/3/6)、DeNAが主催しております ソフトウェアテスト、品質関連のイベント「DeNA QA Night#2」にて、 DeNAのゲームQAで行った取り組みに関しての発表を行いましたので その内容についてご紹介できればと思います。

発表の背景

幅広いプレイヤー層にゲームを楽しんでもらうため、多い時で月に7~8本のイベント施策をリリースしている運用タイトルがありました。

1か月内に多くのイベント施策がリリースされるため、 開発の一人一人がリリースサイクルの短いイベント施策を並行で開発する事となり、 深刻なリソース不足に陥っていました。

開発側とゲームQA側双方がこの現状に問題意識を持ってはいたのですが リソース不足解消の目途はたたず、 またリソース不足の影響で開発成果物(仕様書やデータ)に対してセルフレビューを実施できず、検証時に検出される不具合が増加してしまう不幸な状況が続いていました。

そこで、不具合が増加している状況を解決するために、開発側で実施できなかったレビューをゲームQA側が開発に入り込んで実施しようと考えました。

開発成果物の欠陥を上流工程である開発期間にレビューし検出する事で、 下流工程である検証時の不具合数を減らしていけると考えたのですが 一つ一つのイベント施策のリリースサイクルが短く開発期間も短いため、 レビュー実施方法について工夫する必要があるだろうと考えました。

このような背景をもった運用タイトルに対して行った取り組みが、 今回発表させて頂いた内容となります。

今回の発表内容

DeNA QA Night#2 Game QA part from Yukihiro Yamamoto

上記が発表当日のスライドとなりますが、 インクリメンタルなレビューといたしまして、開発メンバーのすぐ近くに移動して、 直接開発成果物の作成状況を随時確認し、レビューが行えそうな物があれば、 どんどんレビューを実施していくという形を取りました。 (ご協力頂いている開発メンバーには本当に感謝です...!)

リリースサイクルが短く複数のイベント施策を並行で開発している為、 開発成果物が完成してからレビューを実施していると、レビューする期間が足りず、開発側もレビューに対する修正を実施する期間が十分に取れない状態となってしまいます。

また、影響範囲の大きい箇所から随時レビューを実施し問題点を早期指摘する事で、影響範囲内の別箇所に同様の問題が混入しないように対応を促すことが出来、少ない指摘で開発側、ゲームQA側双方が効率よく作業を進められると判断しました。

下流工程になればなるほど仕様変更が発生した際のリスクは大きくなると思いますが、 こちらもインクリメンタルレビューを実施して早期指摘する事により、仕様変更が入ってしまった場合の、開発側、ゲームQA側の負担も軽減出来ると考えました。

そしてインクリメンタルレビューを実施した結果、 検証時の不具合数削減やそれに伴うQAコストの削減について、一定の効果も確認できましたので、詳細が気になった方に関しては上記スライドをご覧頂けますと嬉しいです!

発表のポイント

この発表のポイントとしては下記となります。

・インクリメンタルレビューであれば、完成してからまとめてレビューを行うより、開発側QA側共に心理的ハードルが低く実施しやすい

・開発側のリソースが不足している状況でレビュー工程を追加する事は、一見酷に見えるのですが、インクリメンタルレビューであれば負荷が少なく導入が可能

・最終的に検証時に検出される不具合数が減少したので、下流工程に入ってからの満足度が、開発側もQA側も高い

これからについて

まだまだ発展途上で改善点もある状況ではありますが、 なるべく開発側とゲームQA側がwin-winの関係になれるように、 レビュー対応で不具合数を減らしてQAコストを削減するだけでなく、 開発メンバーへのレビュー対応満足度アンケートを実施したりしながら、 周りの意見を吸い上げて改善しながら進めています。

現在は運用タイトルの1タイトルのみの対応となっておりますが、 インクリメンタルレビューを、他タイトルや新規リリースタイトルにも実施できるように 更に改善していければと思っています。

おわりに

DeNA QA Night#2も前回に引き続き、皆様のお陰で大盛況だったかと思います! 私個人としましても、この発表に至るまでに周りの皆様に支えて頂き助けて頂き、 どうにか本番を迎えられたという状況だったので、 この場を借りて改めて感謝をお伝えしたいです。 本当に皆様ありがとうございました!

引き続きゲームの検証を行う上で有効だと判断出来るものには 積極的に取り組んで行きたいと考えておりますので、 また皆様と意見交流を行えると幸いです!

ありがとうございました!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA TechCon 2019 ベストトークセッションをご紹介します

2019.02.06_133.jpg

こんにちは!技術広報の玉田です。2019年2月6日に開催し、社内外から約1500名の方にご参加いただいた DeNA TechCon 2019 について、社内社外で実施したアンケートの満足度が高かったセッション Top5 をご紹介します。

社外アンケート 満足度 Top5 セッション

約400名の社外の皆様にアンケートにご回答いただき、参加したセッションの満足度を「満足、やや満足、どちらでもない、やや不満、満足」の5段階で評価いただきました。ご協力いただいた皆様どうもありがとうございました!! 評価いただいた中から満足度Top2(満足、やや満足)の割合が高かったセッション Top5 をご紹介します。

1位. AI によるアニメ生成の挑戦

  • 満足度Top2:98%
  • 登壇者:濱田 晃一、李 天琦
AIによるアニメ生成の挑戦 from Koichi Hamada

2位. 『モビリティ・インテリジェンス』の社会実装

  • 満足度Top2:94.3%
  • 登壇者:織田 拓磨、益子 遼介
『モビリティ・インテリジェンス』の社会実装 [DeNA TechCon 2019] from DeNA

3位. 10年目の『エブリスタ』を支える技術

  • 満足度Top2:91.7%
  • 登壇者:松尾 卓朗、井田 祐太
10年目の『エブリスタ』を支える技術 from DeNA

4位. 「マンガボックス」の価値を革新するエンジニアのチャレンジ

  • 満足度Top2:89.4%
  • 登壇者:神武 里奈

5位. スマホゲームのチート手法とその対策

  • 満足度Top2:88.6%
  • 登壇者:舟久保 貴彦
スマホゲームのチート手法とその対策 [DeNA TechCon 2019] from DeNA

DeNA社内アンケート ベストトークセッション5つ

実はDeNA社内メンバーにもアンケートに協力してもらい、「あなたが思うベストトークはどのセッションでしたか?」と聞き、回答してもらいました。その結果ベストトークとして推薦された推薦率が高かったセッション5つをご紹介します。

1位. AI によるアニメ生成の挑戦

スライドは上記となりますが、こちらでは「AI によるアニメ中割生成結果」についてもご紹介します。

 

2位. ゲーム開発者からMaaS開発者へ

  • 登壇者:惠良 和隆


3位. 「マンガボックス」の価値を革新するエンジニアのチャレンジ

  • 登壇者:神武 里奈

3位. スマホゲームのチート手法とその対策

  • 登壇者:舟久保 貴彦


5位. 車載カメラの画像を使用した3次元点群復元と物体認識技術における深層学習の活用

  • 登壇者:葛岡 宏祐


5位. DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜

  • 登壇者:金子 俊一

おわりに

いかがでしたでしょうか。DeNA TechCon 2019 ではこの他にも様々なセッションを実施し、それらのセッションについても皆様に評価いただきました。ご来場の皆様、アンケートにご回答いただいた皆様、ご協力どうもありがとうございました。

その他のスライドや動画についても今後ご紹介していきますので、以下公式 Twitter アカウントをぜひフォローいただければと思います。それでは引き続きどうぞよろしくお願いします!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DroidKaigi 2019 に参加しました!!

DroidKaigi 2019 お疲れ様でした!技術広報の玉田です。DroidKaigi 2019 では DeNA から7名のエンジニアの発表が採択され、それぞれ登壇を行いましたのでご報告します。

採択された7名6セッション

DroidKaigi2019.png

マルチモジュールなプロジェクトでテストはどう変わる?

初日の2/7の10:20から、Hall A にて DeNA SWET チームの田熊が登壇しました。詳しくはこちらのブログ記事でもコメントしていますのでぜひご覧ください。

Espresso のテストを Android の最新トレンドに対応させよう

2/7 の 12:50 から Room2 にて DeNA SWET チームの外山が登壇しました。詳しくはこちらのブログ記事でもコメントしていますのでぜひご覧ください。

外部デバイスと密に連携する Android アプリに最適なアーキテクチャとは?

2/8 の 10:30 から Room6 にて 次世代タクシー配車サービス「MOV」のエンジニアである三輪と本戸が登壇しました。

Wi-Fi RTT による屋内測位アプリを作ろう

2/8 の 11:20 から Room6 にて 次世代タクシー配車サービス「MOV」のエンジニアである @napplecomputerが登壇しました。

WiFi Direct + VpnService で SIM 無し Android を Web 世界に社会復帰させる話

次世代タクシー配車サービス「MOV」のエンジニアである空中が登壇予定でしたが、インフルエンザで当日は登壇できなかったため、 Android Reject Conference 2019/2 で登壇しました。

WiFi Direct + VpnServiceでsim無しAndroidをweb世界に社会復帰させる話 from Kiyotaka Soranaka

UI テスト (Espresso) の高速化をさらにすすめる

2/8 の 16:50 から Room3 にて DeNA SWET チームの平田が登壇しました。詳しくはこちらのブログ記事でもコメントしていますのでぜひご覧ください。

UIテスト(Espresso)の高速化をさらにすすめる from Toshiyuki Hirata

ブース展示も行いました

DroidKaigi 2019 のブース展示にて、 次世代タクシーアプリ「MOV」の車載機器、クラウドアーキテクチャ図の展示などを行いました。

その他、WebCamカバーのプレゼント企画、ライブ配信アプリ「Pococha」のチョコやステッカーなども展示しました。

おわりに

登壇いただいたみなさま、当日含め準備いただいた運営のみなさま、参加者のみなさまのお陰でとても濃い2日間を過ごすことができました!どうもありがとうございました!!

DeNA では引き続き CI/CD Test NightAndroid Test Night など Android アプリ開発者のコミュニティ活動をサポートさせていただきますので、今後共どうぞよろしくお願いいたします。 ベイスターズのビール2.jpg

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA TechCon 2019を開催いたしました

こんにちは。システム本部品質管理部SWETグループの加瀬です。

techcon_2019_1.jpg

2019年2月6日にDeNA TechCon 2019を開催いたしました。今年で早くも4回目の開催となりますが、今年もたくさんの方にお越しいただき、大盛況のうちに幕を閉じることができました。 ご来場の皆様、登壇された皆様、運営の携わったスタッフの皆様、ありがとうございました!

早速ですが、今年のTechConの様子を紹介したいと思います。

オープニング

オープニングはDeNAのエンジニアリングの統括を務める小林より、今回のテーマである「SHIFT UP」についてや、後の発表で詳しく語られるオートモーティブやクラウド移行の話の紹介がありました。 最後に時間の都合上紹介しきれない技術はたくさんあるものの、吟味したAI・ゲーム開発・エンタメ・ヘルスケア・オートモーティブ・開発基盤、この6つを主とした発表があることを紹介して今年のTechConが開幕となりました。

techcon_2019_2.jpg

会場

今年もステージを4つに分け、それぞれのステージでDeNAの様々な事業における技術的なチャレンジについての発表が行われました。 発表後には登壇者に質問できる場が設けられ、参加者とディスカッションしている様子が見られました。

techcon_2019_3_2.jpg techcon_2019_4.jpg techcon_2019_5_2.jpg techcon_2019_6.jpg

今年は開催前にgihyo.jp様よりTechConの見どころを紹介(前篇 後編)して頂いたり、Twitterにてそれぞれの発表の紹介をしてきました。
登壇で使用した資料や動画も、準備ができ次第公開する予定です。興味があったものの当日聞くことができなかった発表については、公開をお待ち頂ければと思います。

それでは、来年もまたDeNA TechConでお会いしましょう!

techcon_2019_7.jpg

当日のツイートの様子

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA TechFes 2019を開催します

denatechfes_cover.gif 明日2019年2月6日(水)は、DeNAの技術を活用した取り組みや新たなチャレンジについて紹介する技術カンファレンス「DeNA TechCon(テックコン) 2019」開催日です。

今年度は、「参加したかったけど参加できなかった方」や「参加したけど、詳細をもっと聞きたい方」などの方向けに、DeNA TechCon 2019 の After Party として DeNA TechFes 2019 を開催します!

DeNAの事業やサービスにフォーカスしたTechイベントやエンジニアのキャリアにフォーカスした採用イベントを小規模で週代わりに開催予定です。

皆さんと近い距離でお話しできることを楽しみにしております。

イベント詳細

※アップデートがあり次第更新いたします!
※各イベントで参加登録が必須となりますので、イベントページをご確認の上ご登録ください。

2/13(水)マンガボックスTech Night

DeNAが提供する週刊マンガ雑誌アプリ「マンガボックス」を対象とした、サーバーサイドエンジニア向けのキャリア採用イベントを少人数制で開催いたします。 2018年12月で5周年を迎えた、マンガボックス。さらなる進化を目指し言語の移行など大規模なリニューアルを予定しており、即戦力となるサーバーサイドエンジニアの募集を始めました。 本イベントではこれまでお話ししてこなかった、開発現場のリアルや今後サービス拡充に向けてテクノロジー観点で考えていることなど、プロダクトオーナーと担当エンジニアがお話しさせていただきます!

2/20(水)Meet the DeNA #Engineer career night

DeNAのエンジニアが経験してきたキャリアパスをエンジニアの方向けに赤裸々にお伝えするためのMeetupです。実際の働き方やキャリアの広がりの可能性を知りたい方は是非ともご参加ください。当日はDeNAでのキャリア形成、エンジニアカルチャーや制度、ものづくり組織の取り組みをメインにお話させていただきます。システム本部本部長の小林(nekokak)や、DeNA内外でキャリアチェンジを行なってきた多様なキャリア経験のあるエンジニアの登壇を予定しております。

3/6(水)オートモーティブ×ヘルスケア TechNight 〜テクノロジーのちからで社会課題を解決する〜

オートモーティブ・ヘルスケア事業に関わるエンジニアがTechConで伝えきれなかった開発の裏側に加え、働き方やキャリアについてパネルディスカッションを交えながら赤裸々にお話します。 新しい技術領域やキャリア形成にチャレンジしている部署なので、既存のDeNAのイメージにはない新しい気づきを感じてもらえればと思います! ※DeNA Engineers' Blogにて詳細発表予定。

3/15(金)DeNA GAME tech talk 〜モバイルゲームを支える基盤の技術チャレンジ〜

ソーシャルゲームにおいてネイティブゲームが主流になっている昨今、それを支えるバックエンドシステムに求められる要件の高さや技術的難易度は高くなっています。DeNAのゲームを支えるバックエンドシステムにフォーカスしたセッションを行います。mobage時代からネイティブシフトを経験したDeNAだからこそ語れるこれまでのゲーム開発と現在のネイティブゲーム開発の違いや、今後のバックエンドシステムに求められる要件を元に現在DeNAがチャレンジしている内容についてお伝えさせていただきます。

日程調整中:PocoDevMeetup

ライブ配信アプリ「Pococha」のエンジニアが開発にまつわる勉強会を開催します。ライブ配信サービスの領域は、今が旬で、皆で寄ってたかって領域を盛り上げていくタイミングだと思っています。ライブ配信アプリ・機能を作りたい方、エンタメサービス開発に携わっている方、Pocochaのことを知りたい方、サービスの新規立ち上げからグロースの苦労やノウハウ、開発の裏側を大公開しますので、是非、ご参加ください!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

MOV タクシー配車アプリ RubyからGolangへ刷新 マイクロサービス化

RubyからGolangへの移行を進める過程で、システムアーキテクチャがマイクロサービス化していくという稀有な体験をしたので記事を書きました。

次世代タクシー配車アプリMOV(モブ)及び、タクシー車両内の乗務員向けアプリに係る WebAPI 50前後をRailsからGolang net/http に刷新しました。その過程でマイクロサービス化が進んだ事例を紹介します。MOV サーバエンジニア池田 周平です。サービスを継続しつつシステム刷新するために、なぜその判断を行ったかについてお伝えできれば幸いです。

MOV(旧タクベル)ご存知でしょうか?神奈川、東京でサービス提供中のタップ操作でタクシー配車ができる配車アプリです。 スクリーンショット 2018-12-28 11.03.58.png

実証実験を繰り返しサービスリリースしました。 立ち上げ初期段階から居たメンバーに話を聞くとRailsで高速にプロトタイピングを繰り返していたそうです。 リリース直前にGAE FEサーバのスケールとスピンアップ速度の観点でGAE SE Golangへ刷新を決め、新設WebAPIはGolangで実装しましたが大部分はRailsのままリリース当日を迎えました。

スクリーンショット 2019-01-08 19.19.41.png

APIバージョンをv1, v2, v3と上げ、アプリの強制バージョンアップでRubyからGolangに切り替える作戦を立てるも、後方互換性を維持し古いアプリでも配車可能であり続けるという運用方針があり、コード2重メンテ問題を回避するため断念しました。開発チームではGolang刷新を完遂したいとたまに話題にしつつも、日々の機能追加や運用に工数を割いていました。

GAE 1%カナリアリリース

リリース直後特有の繁忙期が過ぎたある日、マネージャからGolang移行チーム設立と担当を任されました。移行チームが出来て任されると自分ごとになりムクムクとやる気が出てくる点ワタシ自身が驚きました。

まず最初に考えたことは安全に移行するための仕組みです。

車両軌跡データやユーザアプリと乗務員アプリ間で配車ステート更新を行うため一部のデータ構造や通信シーケンスが複雑です。開発環境でバグ取りきれず本番環境で不具合に繋がる可能性がどうしてもありました。電車やタクシー内で考えた結論はカナリアリリースの仕組みを作り WebAPIごとに最初の24時間はRuby99%, Golang1%でトラフィックを分割して監視、その後割合を増やしていくという作戦でした。

GAEはservice versionごとの段階的なトラフィック切り替えをサポートしていますが、ルーティングを制御するdispatch.yamlの更新はゼロイチ切り替えのためproxyサーバを用意して切り替えることにしました。

GAE標準のトラフィック切り替え機能

スクリーンショット 2018-12-28 13.20.36.png

Golang移行対象WebAPIの1%カナリアリリース

Proxyのversion1と2の差は、刷新対象のWebAPIについてトラフィック流し先がRuby版かGolang版であるかの違いです。 スクリーンショット 2018-12-28 13.47.20.png

このようなアーキテクチャ設計にした狙いは、ゼロイチでルーティングを切り替えるGAE disptach.yamlの仕組みから最小工数でカナリアリリースできるように変更できる点、RubyとGolangサービスで共通formatのログを出力できる点です。1手で2つのメリットあるため採用しました。Cloud Functionsを利用するといった他の選択肢もありました。複数ある選択肢から早期に絞りこめたのはGoogleテックコンサルの皆様に定期的に相談できる恵まれた環境にあった点が大きかったです。サポートとても感謝しています。

Proxyサーバを実装する

GAE dispatch.yamlを代替するサービスを便宜上proxyサーバと呼んでいます。実態はHTTPサーバでHTTP CONNECT methodはログ出力するため利用していません。次のようなざっくり目標と設計で開発しました。

  • Proxyは通信の土管に徹するサービス
  • 処理のオーバーヘッドは50ms以下が目標
  • APIサービスへのHTTP通信はNon-blocking I/Oで必ず行う
  • JSONパースは処理時間が掛かるため行わない
  • BigQueryへログ出力を行う

Golangで素直に書いていけば実現する仕様です。本体は200行くらいでどのサービスに通信を振り分けるかはrouterをそのまま利用して実装します。仮想コードの方が伝わるので載せておきます。


func init() {
    router := router.New()
    setAction(router, "/", iamproxy)
    setAction(router, "/v1/drivers/*path", rubyService)
    setAction(router, "/v1/users/*path", golangService)
    http.Handle("/", router)
}

func main() {}

先ほど本番サーバをStackdriver traceで計測したらproxyの処理時間は15msでした。サービス間の通信はurlfetchを利用していて、GAEだとGCPの同一データセンター内にdeployされる特性があるためレイテンシは低めです。詳細は公式の Google App Engine 上でのマイクロサービス アーキテクチャ に記載があります。

routerはwild card routingといった標準的な機能が利用できるものを採用しました。特に高速化のために内部で Radix tree を生成し、サーバ起動時にURL routingの名前空間が重複しているとエラー吐いてどこが重複したか教えてくれるようならライブラリを利用するとよいです。複数のAPIを段階的に移行する際の助けになりました。

Proxy導入でログ出力を強化する

複雑な構造を持つJSONをRubyからGolangに移行したとき、RubyとGolangの細かな仕様差、たとえばゼロ値で苦しめられます。 元の構造では気軽nullを扱っておりJSON objectの各プロパティの型がnullableになっていました。ArrayやStringが空のとき [] or "" or null がAPIごとにバラバラだったため、正しく移植しきれず何箇所かで失敗することが予想できました。

現行WebAPIがどういった構造のJSONを送受信しているか蓄積し知るためProxyサーバで HTTP Request/Response/Headerを全てStackdriverにログ出力して、Stackdriver exportでBigQueryにsyncしました。この設定はボタンポチポチで設定できる割に効果が大きく移行をサポートする強力なツールになりました。(開発者用のログはオートモーティブ事業部内での厳しい個人情報取扱規程・個人情報保護指針があり、位置情報や選択内容及びアカウント情報は全てサーバ内部のメモリ上で削除し個人を特定出来ない形でログ送信しています)

億単位の通信ログからBigQueryで目当てのログを検索できたときは、1歩時代が進んだ感あって気に入っています。またStackdriverはStackdriverMonitoringで簡単に監視設定を作り込みSlackやPagerDutyと連携できるため頻度高く利用しています。

機能追加とGolang移行のバランス

サービスへの機能追加とシステム刷新のバランスは難しい問題です。開発の手を止めることが出来ればよいのですが、システム刷新を理由にリリース直後のアプリで機能追加速度を落としたくはありませんでした。50前後あったWebAPI次の5つに分類し段階ごとにリリースしました。特にHTTP GETなWebAPIはステートレスでテスト容易だったため早期に移行を行いました。5段に分けてリリースした理由は、1段目は単純なAPIを移行し実行可能性を調査するため、2段目移行は移行対象が大きすぎて全体把握と品質担保が難しいといった問題を回避するために、QAを行いやすい単位で分割していきました。

  • アカウントAPI
  • 配車API(method:GET)
  • 配車正常系API
  • 配車準正常系・異常系API
  • その他(お知らせ等)

移行中のGoとRubyどちらに実装すればいいといったコンフリクトが複数発生するなと予期していました。実際はごく少数しか発生せずスムースに移行完了でき、きっと私が気づかない所で開発チームメンバーが配慮・調整してくださっていたんだと思います。

振り返るとシステム刷新する上で開発チーム全体への影響を最小にするポイントはいかに早く刷新コードをmasterブランチへマージするかという点です。Proxyサーバでトラフィックを切り替えない限り蓋ができる構造だったため、完成次第masterブランチに投入して本番リリースを行いました。蓋を開けるタイミングはQA完了後です。早い段階で刷新したコードが他の開発者の目に触れる場所に設置できた点はとても良かったです。

マイクロサービス化と開発組織

現在アプリから見えるサーバは次のような構成になっていて9名の開発者で開発しています。(これ以外にもFleet Management System, タクシー事業者向け管理サービス, CS対応向け管理サービスとその開発チームありますが図からは省略しています)定めたというより自然とこのような形に落ち着きました。言語化すると次の基準です。現在のスナップショットでしかないため人員が増えるとルールは変化していきそうです。ポイントはサーバ間認証のサービスを増やしていっている点で部品としてふるまうためマイクロサービス化の副作用少なくメリットを享受できると考えています。

  • API Service本体は全員が開発
  • 各マイクロサービスは2名前後で開発
  • user/driverのaccess tokenを認証認可するサービスはAPIに集約する
  • MOV以外でも利用需要がありそうな機能はサーバ間認証でマイクロサービス化

スクリーンショット 2018-12-29 15.13.53.png

GEOはgeographyの略で一緒に開発していたエンジニアがすごい勢いで空間参照系について詳しくなり、いつの間にか作り終わっていた機能です。代表的な機能はユーザや車両がどの営業区域にいるか経度緯度情報からの地域判定です。PostGIS DBのCPUで判定計算している点が特徴です。

E2Eテストを書く

proxyを対象にE2Eテストを書きました。テストケースは本番の配車履歴から頻出パターンを抽出しました。検査項目はHTTP ResponseのJSON SchemaチェックとRDBのレコード状態の確認です。RSpecの生産性の高さと、使い捨て前提の割り切りでサクサク書け手動で再現するには2時間くらい掛かる分量になりました。捨てるにはもったいない出来だったのでbotに組み込みQA環境を自動試験しています。

スクリーンショット 2018-12-29 16.43.36.png

まとめ

振り返るとRubyからGolangへの移行を進める過程で、システムアーキテクチャがマイクロサービス化していくという稀有な体験ができしました。短期間で大きなトラブルなく安全に移行完了できたのはカナリアリリース、ログ基盤、E2Eテストと足回りを強化したあと移行を行った点にあると思います。

このアーキテクチャは現在のスナップショットであって、今後開発リストにあまたある新規開発を行っていく上で変化していくでしょう。チーム内では配車サービスを独立といった話をしています。

お話変わってDeNAでは年に1度TechConを開催しています。今回移行作業を強力にサポートしてくださった惠良 和隆さんの発表もあります。ぜひ。 https://techcon.dena.com/2019/

最後まで読んで頂きましてありがとうございます。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

QA Night #1 開催レポート(第二部)

はじめに

品質管理部の河野です。 開催レポートが遅くなってしまってしまったのですが、「おわりに」で遅くなった言い訳を書かせて頂きます。
すでに第一部の松尾谷さんの講演はこちらでレポートさせて頂きました。
こちらの第二部では、DeNAパートの中でも事例のところにフォーカスを当ててレポートいたします。 今回、DeNA QA の事例として、テストプロセス標準化の取り組みを発表させて頂きました。以降、発表の背景と概要をレポートいたします。

発表の背景

ちょうど1年前の12月くらいから部門横断の改善活動を開始したのですが、そのとき真っ先に着手したのがテストプロセスの標準化でした。各チームでバラバラだったテストの進め方をまずは全体的に共通化しようと言うのが本発表の取り組みです。
その後、標準テストプロセスが概ね出来上がった段階でその導入を進めつつ、TPI NEXTを使ったテストプロセスのアセスメントや標準テスト観点の整備などの取り組みを進めてきました。また、テストプロセスが標準化されたことで、今後はテスト活動のメトリクスの収集を行っていく予定です。
ということで、まずはテストプロセスを標準化していくことで、その後の活動がスムーズに進んだように思います。 それでは、当日の発表概要に移ります。その前に、当日のスライドはこちらになります。

DeNA QA Night #1 DeNA part from Tetsuya Kouno

発表の概要

当日の発表では、上記のような背景を初段に説明して、その後は、具体的にどのようにテストプロセスを標準化していったのかという事例を紹介しました。
テストプロセスの標準化というと難易度が高そうに見えますが、我々が取ったアプローチは以下になります。
1.各チームのテストプロセスの見える化する
2.上記テストプロセスの共通化する(積の共通とする)
3.成果物や処理の名称を決める
それで、当日は1.の見える化を「カレーライスを作る」演習を交えて、皆さんで少しワークをしてもらいました。思いの外、盛り上がってよかったです。
その後は、2.と3.を具体例を交えながら解説していき、最後の方で標準化のメリットなどを示しました。

後日談1:プロセスに関しての松尾谷さんの発表について

松尾谷さんの発表で、品質関連のアプローチとして「プロセスや技法」は負け犬の遠吠え、
のような解説がありました。 それに関して、後日というよりは発表後の話になるんですが、
松尾谷さんから以下のような意図のコメントを頂きました。

私が言ったのは河野さんの発表のようなプロセスではなくて
スタッフ部門や管理部門が押し付ける規範的なプロセスを指しているので
逆にこのようなプロセスを標準化するのは良いことだ

ということで、今回の取り組みはそれほどずれていなかったようで安心しました。
今回、気をつけたのは、ボトムアップのアプローチで進めたのでやはりそれが良かったと思いました。

後日談2:PFDってそんなに簡単なだっけ?

本イベントに参加した私の知り合いに、とあるイベントであったのですが、こんなことを言われました。

PFDでプロセスを書くのを簡単に発表してたけど、
そもそも目の前の業務をPFDに書くことは結構難易度高いんじゃない

はい、おっしゃる通りで、よく見かけるのはフローチャートになっていたり、
成果物と処理がごっちゃになったりして、PFDで表現するのは結構難しです。
それで、私は以下のような工夫をしております。

  • 最終成果物から戻るようにプロセスを書いていく
     最終成果物からその前の処理、その処理の入力成果物といった感じで考えるほうが
     経験的に知的ハードルが低くなるように感じます
  • 最初はメタに捉えて、作業の粒度を荒くする
     細かく考えるとキリがないです。まずはメタに捉えて、細かくしていきましょう。
     細かくしていくところは参考資料を見てみてください。
  • ホワイトボード / 紙と鉛筆で書く
     いきなりpptで清書すると挫折します。挫折というより、時間切れになると思います。
     なので、まずはラフにスケッチしましょう。
     スケッチできなければ、よくわかっていないことなので、次の工夫です。
  • 一人で考えすぎずに、他の人を巻き込む
     実態がわからなくて、PFDで表現できないところが出てきます。
     なので、そういうところは知っている人に聞くのが早いです。
  • 成果物と処理の名前付けに気をつける
     これは重要です。周りのメンバが共感できるような実態にあった名前をつけましょう。
     それと、成果物と処理にふさわしい名前、特に処理は動作を表す名前をつけましょう。

おわりに

今回の第一回、DeNA QA Night は参加者・講演者の皆さんのおかげで成功だったと思います。ただ、これは終わりではなくて始まりです。
次回もやります。日程は3月6日(水)で決まっております。次回も業界の一線級の識者にお声がけしてます。是非、期待して下さい。
ということで、次回日程が決まってから開催レポートを書きたいと思っておりましてこんな遅い開催レポートとなってしまいました。という、言い訳でした。
皆様、良いお年を!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ここでしか見られない DeNA TechCon 2019 のセッション4つ

og.png

DeNA の様々な技術的なチャレンジをみて参加者のみなさんに「面白かったー」と思ってもらいたい DeNA TechCon。こちら次回開催は 2019年2月6日(水) で、登壇情報もほぼ全て出揃いました!(ゲストセッション、LTセッションなどはまた後日お知らせします!)

DeNA グループ全社で取り組んでいる様々な取り組みの中から厳選した21セッションをお届けするので、本当に全部おすすめ。そんな21セッションの中から、社外では発表する機会が少なかったり、DeNA TechCon だからこそ話せるような、他の技術系イベントでは見ることが難しいと思われるセッションを各トラックから1つずつご紹介します。

「AI 技術の事業への応用」トラック

パネルディスカッション:データサイエンスの競技者、Kagglerたちが活躍する職場とは

2018年8月末、DeNAのKagglerである小野寺和樹と加納龍一を含むチームが、過去最大のKaggleコンペである"Home Credit Default Risk"にて、7198チーム(参加者数8572名)中2位に入賞しました。

彼らを含め、DeNA では データサイエンス競技「Kaggle」のトッププレイヤーが集まっています。この Kaggler たちは一見すると事業貢献からは遠い競技者だと見えてしまいますが、 彼らと連携するメンバーの協力もあり、Kaggler たちは事業でも大活躍しています!

Kaggler とはどういった人たちでどのように事業でも成果をだしているのか、「Kaggler たち自身の立場」、「彼らと連携するメンバーの立場」の両面から話を聞ける機会は少ないと思います。そのためおすすめのセッションです!

参考記事

「クラウド活用」トラック

DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜(仮)

現在約 3,000 台のオンプレミスのサーバーを運用している DeNA は、3年かけてオンプレミスで運用する全てのシステム基盤を全面的にクラウドに移行することを決定しました。
その決定にいたるまでの裏側の話は、現在オンプレミスだがクラウドに移行しようか悩んでいる人や、現在クラウドを使っているが低コストと安定運用を両立したい人にとって、とても参考になる話だと思われます。
多くの人に興味を持ってもらえるだろうこの登壇内容について、この意思決定を推進した 金子 俊一が自ら登壇してお話ししますので、是非見てもらいたいです!

参考記事

オンプレミスに強みをもつDeNAはなぜクラウド化を決めたのか?その舞台裏と今後の展望

「サービス開発」トラック

ヘルスケアサービス開発の裏側 〜品質と開発効率の両立〜

ヘルスケアは一般的なサービスに比べるとセキュリティに求められる水準が高く、どうしても開発スピードと両立させることが難しいそうです。そんなヘルスケアのサービスでセキュアな状態を維持しつつも開発スピードが高いままで - オンプレからクラウドに移行する - マイクロサービス化するという点 の2つを推進しており、様々なサービスにとって参考になる情報が盛りだくさんで、非常に見応えある内容だと思われます。当日はサーバサイドの池松、クライアントサイドの四方がそれぞれ話すので、アプリケーション開発、サービス開発に携わるエンジニアにはぜひ見ていただきたいです。

「ものづくりを支える技術」トラック

スマホゲームのチート手法とその対策

スマホゲームではさまざまなチート方法があるそうなのですが、その方法について「チート手法」と「その対策」を紹介してくれる場はあまり無いそうです。
チート方法はセキュリティエンジニアだけが知っていたら良いものではなく、アプリ開発やサービス開発するエンジニアも知っておくべき知識ですよね。セキュリティエンジニアとして知識を深めたい人、アプリ開発エンジニアだけど知識としてチート方法と対策を知っておきたい人にはぜひ見ていただきたいです。

終わりに

本当にすべてのセッションがおすすめなのですが、今回はその中でも 社外では発表する機会が少なかったり、DeNA TechCon だからこそ話せるような、他の技術系イベントでは見ることが難しいと思われるセッション 4つをご紹介しました。

また、実はまだ公開していないゲストセッションや、LTに関しては 公式 Twitter アカウントの DeNAxTech で今後ご紹介していきますので、まだフォローしていない方はぜひご登録下さい。

icon_tw@2.png
また肝心の DeNA TechCon 2019 について、まだ参加登録していない人は以下の Peatix から参加登録のほどよろしくお願いいたします!!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

LLVMを用いたチート対策ツールを作っている話

この記事はDeNA Advent Calendar 2018の24記事目です。

こんにちは、セキュリティ部セキュリティ技術グループ ツール開発チームの小竹 泰一(aka tkmru)です。 脆弱性診断業務の傍ら、ツール開発チームでは、パッチ管理ツールやチート対策、脆弱性診断のためのツール開発を行っています。 この記事では開発中のLLVMを用いたチート対策ツールの紹介をしたいと思います。

はじめに

本題に入るまえに、チートをされるとどのような問題があるのか、チートの方法やチート対策技術にはどのようなものがあるのかということを軽く説明しようと思います。

チートによるリスク

スマートフォンのゲームアプリのチートでよくあるものとしては、 「スタミナが減らないようにするもの」や、 「ステータスを不正に上昇させバトルで勝利するもの」、 「不正に課金アイテムを取得するもの」などがあります。

もし、このようなチートが横行してしまうと、適切に利用しているユーザの快適なプレイが阻害されてしまうかもしれません。 また、不正に課金を回避したり、ステータスをアップさせているユーザの存在は他のユーザの納得感を得られないでしょう。 チーターの存在はゲームバランスにも影響し、ゲームからユーザーが離れる一因となります。 ゲームアプリの脆弱性診断では、ゲームに対して実際に攻撃を行うことで、このようなチートからゲームを守ることができるかを確認しています。

チート対策技術とは

上で述べたように、チート対策はゲームの魅力を守るために重要です。 とくに、近年のゲームアプリはUX向上の為クライアント側の計算により多くのゲームロジック(スコア・ダメージの計算、勝敗判定など)を寄せています。 そのため、リバースエンジニアリングを伴う攻撃への耐性を上げることが重要なチート対策となっています。

ゲームアプリに限った話ではなく一般的に言えることですが、リバースエンジニアリングの手法は、アプリケーションを実際に動作させメモリや通信内容を解析する動的解析と、 ディスアセンブラやデコンパイラにかけた結果を解析する静的解析の2つに分類されます。 ARMアセンブリのコードを読む必要のある静的解析は動的解析に比べ、難易度が高いですが、 用いられている暗号方式などの詳細な解析結果を得るには行う必要があります。

ゲームアプリのチート対策では、この2つに対して対策する必要があります。 ここではひとつひとつを詳細に説明することはしませんが、チート対策技術には以下のようなものがあります。

  • 通信の暗号化
  • Root化端末、JailBreak端末の検知
  • VMの検知
  • デバッガ検知
  • メモリ上のデータの暗号化
  • パッキング
  • コード改ざんの検知
  • 難読化
  • ... etc

紹介するLLVMを用いたチート対策ツールでは、コードの処理の流れを追いにくくする難読化と、 パッチを当てられたことを検知するコード改ざん検知を担っています。 コードの改ざんを検知した後にやることとしては、アプリを強制的に終了させることや、ログをサーバーに送信することが考えられます。

LLVMとコンパイラ

LLVMは、コンパイラ開発のためのオープンソースの基盤ソフトウェアです。 主な特徴として、コンパイルに必要な機能がモジュール化され,各機能を統合するドライバで構成されており、拡張性、移植性に優れていることが挙げられます。

コンパイラの設計手法の一つにフロントエンド、optimizer、バックエンドの3つの構成要素に分割して設計するThree-Phase Designがあります。 LLVMを用いてThree-Phase Designを採用してコンパイラを設計すると、 内部構造は以下の画像(The Architecture of Open Source Applications: LLVMより引用)のようになります。

LLVMCompiler1.png

フロントエンドがプログラムのソースコードをLLVM IRという中間表現に変換し、 LLVM optimizerがLLVM IRのコードに対して最適化をかけます。 そして最後にLLVMバックエンドがLLVM IRのコードからターゲットのアーキテクチャのアセンブリコードを生成し、 実行可能ファイルを生成する流れになっています。

コンパイラ開発にLLVMを利用すると、中間表現をLLVM IRに統一することができ、 異なるアーキテクチャ向け、異なる言語向けのコンパイルであっても最適化部分を共通化できます。 しかも、その最適化機構はPassとしてLLVMが提供してくれています。 また、バックエンドを置き換えるだけで異なるアーキテクチャに対応できたり、フロントエンドを置き換えるだけで異なるプログラミング言語に対応できたりもします。 このようにLLVMを利用することで、1からコンパイラを作成するより効率よくコンパイラを作成することができます。

LLVM IR

LLVM IRについてもう少しくわしく見ていきましょう。 LLVM内部で用いられる中間表現であるLLVM IRは、 アセンブリ言語に似た表現で、表現力や拡張性、軽量であることを追求して作られています。 基本的な命令による操作の組み合わせで、 様々な高級言語に対応した簡潔な表現が可能になっています。 また、LLVM IRのレジスタは数に制限が無く、値の代入が一箇所でしか行えないSSA(Static Single Assignment)形式になっており、 これを用いて柔軟に変数を表現することができます。 LLVM IRには様々な種類の型が存在し、レジスタに型が対応しており、 細分化された型は高度な最適化を可能にします。 例えば、32bit整数型を表すi32型や、 128bit浮動小数点数型を表すfp128型などがあります。 これらの基本となる型と組み合わせて、構造体、配列、ベクトルといった 派生型を構成することができます。

実際にLLVM IRのコードを見てみましょう。 以下のような西暦を出力するだけのコードをLLVM IRに変換します。もうそろそろ2019年ですね。

#include <stdio.h>

int main(){
  int year = 2018;
  printf("%d", year+1);
  return 0;
}

clangに-S-emit-llvmの2つのオプションを指定するとLLVM IRコードが出力されます。

$ clang new-year.c -S -emit-llvm
$ cat new-year.ll
; ModuleID = 'new-year.c'
source_filename = "new-year.c"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.13.0"

@.str = private unnamed_addr constant [3 x i8] c"%d\00", align 1

; Function Attrs: noinline nounwind optnone ssp uwtable
define i32 @main() #0 {
  %1 = alloca i32, align 4
  %2 = alloca i32, align 4
  store i32 0, i32* %1, align 4
  store i32 2018, i32* %2, align 4
  %3 = load i32, i32* %2, align 4
  %4 = add nsw i32 %3, 1
  %5 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i32 0, i32 0), i32 %4)
  ret i32 0
}

declare i32 @printf(i8*, ...) #1

attributes #0 = { noinline nounwind optnone ssp uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.module.flags = !{!0, !1}
!llvm.ident = !{!2}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 7, !"PIC Level", i32 2}
!2 = !{!"Apple LLVM version 9.1.0 (clang-902.0.39.2)"}

レジスタが%数値で表されているのが特徴的ですね。 アセンブリとは違い、アドレスの概念がないので操作しやすそうなのが分かると思います。

Three-Phase Designについて説明をした際、異なるアーキテクチャに対して最適化部分を共通化できると述べましたが、それ以外にも LLVM IRを用いることで対象のソースや機械語に手を加えることなく、最適化を行うことができるというメリットがあります。

LLVMをなぜ使うのか

LLVM IRを最適化に使うと便利だということを述べましたが、これは難読化やコード改ざん検知機能を実装するのにも同じことが言え、 LLVM IRを用いることで対象のソースや機械語に手を加えることなく、出力されるバイナリに難読化やコード改ざん検知機能を施すことができます。 また、現在スマートフォンで用いられているCPUはARMが主流ですが、異なるアーキテクチャのCPUを用いたスマートフォンが出てきたときの対応も容易になります。 LLVMを使って難読化に行うこと自体は、新しい手法ではなく、OSSの実装としてobfuscator-llvm/obfuscatorが知られています。

Unityで作られたゲームアプリのコードはIL2CPPを利用してC++のコードに変換することができます。 開発中のチート対策ツールでは、 この出力されたC++のコードをLLVM IRに変換し、 難読化やコード改ざん検知をいれ、 最終的にバイナリにするという方式をとっています。

難読化例

プロトタイプのチート対策ツールを使用するとCFG(Control Flow Graph)を以下のように変化させることができます。 CFGはIDA Proを使って生成しました。 これによって処理の流れが追いにくくなります。

難読化前のCFG

before_cfg.png

難読化後のCFG

after_cfg.png

今のところ、まだIDAのGraph viewでCFGを表示することができますが、最終的にはAnti-Disassemblyを施してCFGを表示できないようにする予定です。

おわりに

開発中のチート対策ツールの技術的な背景を紹介しました。 マルウェアがアンチデバッグに使っている手法などを検証しながら、 低レイヤーでの開発ができる、 このツールの開発はとてもおもしろいと思っていて、 商用ツールに負けないようなツールにしていきたいと思っています。 チート対策やLLVMを使ったツール開発の面白さが少しでも伝われば幸いです。

宣伝

DeNA TechCon 2019 を2019年2月6日(水)に開催します! ぜひご登録下さい! セキュリティに関する話もあります!! techcon2019.png

また、弊社についての技術情報は @DeNAxTech より配信しています。ぜひフォローをお願いします!!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る