ISUCON8予選に参加した
はじめに
ISUCON8の予選にチーム名「GrilledMeat」で参加しました。
結果はfailのまま終了するという残念な結果でした。
その後延長期間として1週間ISUCON予選の環境を提供していただいたので当日できなかったことを試しました。
延長期間で試したことを含めて振り返ります。
実力不足を痛感させられるような素敵な問題を出してくださっただけでなく、このような振り返りの機会を用意してくださった運営の皆さま、本当にありがとうございます。
事前準備
- 使用言語をGoにするということで入門書を読む。
- プロファイラをいち早く揃えられるように Ansibleを用意した。
当日
- サーバーに入ってミドルウェア構成を見たり、ブラウザからサービスを閲覧して調査を行う。
- h2oに対する知見はなかったが、当初はh2oをうまく使いたいと思いnginxへの置き換えを考えていなかった。
- h2oのconfへalp向けにtsv形式でのログ出力を追加し、slow-queryの出力をするように設定変更。webapp動作言語もGoに切り替えてベンチマークを回す。
- ベンチマークの結果に基づいてindexを適当に追加してみるなどしてみたがスコアに変化はなかった。
- pprofも入れて再度ベンチマークを回す。getEvent、getEventsを改善するのが効果的だと判断し、そのあたりのコードを読むことに。
- getEventsのselectをまとめてアプリケーションで処理するように修正。スコアは22000くらいになる。
- 引き続きクエリをまとめたり処理の効率化を図ったが改善せずfailを繰り返すようになった。
- sheetsをハードコードしたり、いらない処理を消していった。継続的にベンチマークを回し、failしないパターンに当たり最高点である約26000を記録する。
- failを止めようにも止め方がよくわからなかったため、h2oを使って複数台構成を試みたが、failが頻発したまま終了した。
反省
- failせず安定してスコアを出し続けられるように対応する必要があった。他の細かな実装の改善よりもこちらの方が重要だったと思う。
- h2oからnginxに切り替えるべきだった。h2oをうまく利用するべきだと思っていろいろ調べていたが、その調べる時間でアプリケーションをより良くすることもできたと思う。
- 役割分担について明確にできていなかった。本番をイメージして時間を区切って過去問を解くといった準備が足りなかった。
感想戦
- 本番ではgetEventの改善やindexの修正が不十分だったため、それらを感想戦で試した。
- failが頻発する問題についてはロックなども試したがうまくいかなかった。結果としてreportのところにsleepを入れる方法でベンチマークは安定した。
- 複数台構成、Redis利用は試すことができなかったが、アプリケーションとインデックスの改善のみで最終的に以下のスコアになった。
全体振り返り
- 結果論ではあるがアプリケーションコードとDBの改善のみで一定以上のスコアになった。
- あれこれ試してみたいと思い当日の限られた時間を有効活用できなかったことが良くなかった。
- 安定的にアプリケーションを動作させるということはISUCONでスコアを稼ぐことだけでなく、普段でも重要なことなので、そのための知識や経験を得ていきたい。
- 次回は時間の使い方を意識して、自分のやることのスコープを絞ってより良い結果を出せるようにしたい。
LINE Developer Meetup in Tokyo #39 Testing & Engineering
LINE Developer Meetup in Tokyo #39 Testing & Engineeringのレポート。
イマドキのソフトウェアのテストやQAの考え方
www.slideshare.net
スライドの中身が非常に多く、以下に抜粋して説明された内容のメモをまとめる。
労働のスケールアップから知のスケールアウトへ
目的なくテストを厚くするために人的コストの投入量を増やす「労働のスケールアップ」ではなく、
プロダクトの価値の最大化のために技術を活用して効率的に品質保証を行う「知のスケールアウト」をしようという話。
知のスケールアウトを促進するような品質保証戦略を立てる
- 技術を活用するといっても流行りの手法を闇雲につぎ込めばいいという話ではない。
- バズワードに振り回された戦略は必ず失敗する。
- 大事なことは事業や開発力といった組織全体のコンテキストに合わせた品質保証戦略を立て、それに基づいたフローや自動化を導入すること。
品質保証戦略を立てる際に考えるべきパラダイム
- 品質保証とは納得のマネジメント、価値の最大化に自信を持つ行為。
- ソフトウェアという目安となる指標を算出できても測ることはできないものを無理に測ろうとしない。
- デベロッパーとQAでミッションをシェアし、違和感があれば進捗を止めて納得感を上げる活動をQAが促進する。
- その中で単純作業を自動化し、自動化によって思考に使える時間が増加した割合、納得度に対して自動化の価値を見出す。
テストにもエンジニアリングアプローチが必要
- 測定や手順による品質の保証はできない、テストは3 × 5 × 3=45種類の保証動作の重ね合わせ価値の最大化に自信を持つ行為。
- テストアーキテクチャは設計における責務の分担と配置と同様である。
- テストアーキテクチャはすでに様々なものが存在するが、組織に合ったものを考える。
テストの自動化
Fully-automated VSTeP
テストの要求分析、アーキテクチャ設計、詳細設計を自動化する。
テスト、QAにも投資が必要。
感想
単純にテストをこなすのではなく、何のために品質保証をするのかを考え組み立てていく上で、フレームワークや自動化を取り入れていくということを意識させられる話だった。 盲目的にテストを継ぎ足していくということではなく、新しいテストを追加する目的とそれで得られる価値をより深く考えていきたい。
LINE のUI自動テスト事例
www.slideshare.net
LINEのテスト自動化事情
- グループ全体
- 各開発拠点でそれぞれにQAチーム、自動テストチームを持っている。
- 拠点ごとに見ているプロジェクトが違う、テストの粒度ややり方も違う。
- LINE Fukuoka
ツール選定
- ツールとしてはオーソドックスなものを使っている。
テスト自動化で気をつけていること
- Stability
- 基本に忠実に。
- 不安定な実行環境を作らない。
- Maintainability
- UI変更に対して強く。
- テストをしやすいプロダクトを作る。
- Readability of the test result
- テスト結果を全員にとって見やすいものにする。
- 非エンジニアがログを生で見ても的確な情報は得られない。
- わかりやすい可視化をするためのレポートツールを作成。
LINE STOREでの事例
- リリースサイクルが早い。
- リグレッションテストの需要が大きい。
- 既存機能に対するテストは自動、新機能に対しては自動テストの準備が間に合わないという都合もあってManual QAも入るハイブリット。
- 大規模な更新の場合、Manual QAでのバグ発見件数が多くなる。
- 自動テストは実装したことしかテストしてくれないのでテスト選定が重要。
- 自動テストの導入は人的コストの削減には至らない。（狙っていない）
- 自動化にもコストがかかる、テストを増やしてもメンテナンスコストもかかる。
- 全てを自動化することが善ではない。
チームの指針
- E2Eのテストを全てQAチームで作るのは無理。
- Engineerと積極的に協業する。
- 全てをE2Eで解決しようとはしない。
- コストも膨大になる。
- テストを作ることが目的化するとメンテナンスできずにテストが腐っていく。
- 開発チームが仕事しやすくならなければ意味がない。
- リファクタに対する躊躇など、やりたいことを阻害する要因をカバーする。
- テストを書くことが辛いことになってしまっては意味ない。
- テストがあることで楽に開発できると思ってもらえるようにしていく。
感想
全てをただ自動化しようとするのではなく、人によるQAと自動テストの役割・価値を考えてコントロールされている良い事例だと思った。
E2Eテストや可視化ツールなど揃えておきたいものを揃えつつ、自動化やツールで全てを解決できると考えないことが品質を保ち続けるために必要な考え方だと思った。
An Agile Way As an SET at LINE
www.slideshare.net
SETとしての活動
- SET部隊の立ち上げとテスト自動化の推進がミッション
- SETに対する共通認識がない、そもそも問題の言語化ができていない。
- 遭遇した課題
- 何を為すべきかわからなかった
- テスト対象システムの詳細を知らなかった
- 幅広い関係者の支持・協力が必要だった
- 解決方法
- 何を為すべきなのかを見つけ出す
- トライアル＆エラーで高速に学習する
- 定期的に進捗と成果を見せる
何を為すべきなのかを見つけ出す
SETに対する共通認識がない、そもそも問題の言語化ができていない。
アジャイルの要素
- プロダクトディスカバリー
仕様は絶対的ではない、仕様は仮説、SETがやるべきことも仮説設定
- プロダクトディスカバリー
共通認識づくり
- 施策、目標の策定
- 継続的合意形成 ビジネスの3KPI(売上・利益・従業員満足度)に基づいて施策の優先順位づけ、効果測定を行なった。
現状把握・課題発見・言語化
- テスト対象システムの解析
- 静的コード解析によって技術的負債を見える化、共通認識を作る。
- 障害報告はヒントの山
- 障害報告から情報をかき集めてくる。
- 困っている人と直接対話して言語化する
- 課題を見える化する。
施策・目標案の策定
共通認識を作る視点はビジネスKPIに基づく。
プランは必要ないがプランニング(ゴールと施策の定期的な見直し)は必要。
トライアル＆エラーで高速に学習する
自動テストを活用したプロダクトの仕様・設計の把握。
アジャイルの要素
- Extreme Programingを活用した高速な学習の仕組み
動かしてみてわかることが多い。
- 動かしても壊れないことが理想。
定期的に進捗と成果を見せる
多くの人と協力関係を築く必要がある。
今後の課題
ビジネスに絡めたインパクトを出し続けて、より受け入れたいと思わせる。
まとめ
- 課題を見つけて言語化
- 協力者を得る
- 全てのビジネスは3KPIに基づいている
ビジネスに貢献しよう
感想
定期的に進捗と成果を見せるということが特に良い取り組みだと思った。
品質という概念やテスト自動化の推進による成果というものは、指標はあってもインパクトを測ることが難しいものである。
ビジネスの3KPIに基づいて優先度付けをし、効果測定と事業貢献を念頭に置いて取り組むということが、テストや品質保証に対して前向きな文化の醸成を推進する上で効果的な手段だと思った。
アジャイルの考え方も含めて様々なアプローチでSETの役割・働きを定義して推進しているのはすごいと思った。
全体の感想
とにかく目的を見出してテストを導入するという話が多かったと思う。
世の中には便利なツールも多く存在するが、まず導入するよりも何がプロダクトの品質面で不足しているのか、新しいツールを導入することでどういった価値を生み出せるかを自分の頭で考えて取り組むことではじめて効果が得られるのだと思った。
また品質保証チームから組織の考え方、間違った当たり前を正していくという話も多かった。
自分は開発者という立場で仕事をしているが、テストコードを書いたり品質を保つための改善をし続けることに変わりはないので、今回聞いた話も参考にしつつより明確な自分の考えを持って開発に取り組んでいきたい。
IoT勉強会に行ってきた
先日、IoT勉強会に行ってきた。
内容や感想についてまとめる。
背景
最近スマートホームに関心を持ち始めたこともあって趣味として電子工作に取り組んでいる。
取り組んでいると言っても入門書として有名なこちらの本と
それ用のパーツを買ってちまちま進めているくらいだが。。。
仕事ではサーバサイドエンジニアとして働いていて、
IoTという分野に対して実践的な知識は持ち合わせておらず、
ただプログラミング経験があるくらいである。
今回はイベント名からして自分にぴったりな雰囲気の勉強会だったので参加した。
内容
内容としては加速度センサーが自立！ モーション起動スイッチで低消費電力IoTを作ろう！に、
ブレッドボードでの回路の組み方、MOSFETのスイッチング、レジスタやSPI通信の概要
といった話を肉付けしたハンズオン形式の講座だった。
自分としては - FlashAirをマイコンとして利用する - MOSFETのスイッチング - SPI通信 の3点が初めて知る話だった。
今回作ったシステムはデバイスが動作を検知してからスクリプトを動作させるというもので、
制御をハード側に寄せているというのも面白いポイントだった。
感想
今の仕事に関係なく新しい知識を得る、原理を知るということは面白いことだし、
加えてパーツ込みで3,000円という価格だったのはとてもお得に感じた。
IoTの面白みはあれもこれもスクリプトで制御するのではなく様々なモジュールも含めて
何にどのような役割を持たせるかという設計を考えて開発できることだと思った。
これからの課題としてはまだまだどのようなモジュールがあるのかを知らないことにあって、
様々な実装パターンを学び、こういうものを作るならこのモジュールを使う、
という自分としての鉄板構成を持っておくことが必要になると思った。
(この辺はWebアプリケーション開発と変わらないかもしれない。)
引き続き普段の開発とは違った、ある種の頭の体操としての楽しみが得られるものとして触れていきたいと思う。
。。。と思って帰宅したのだが、その後Amazonからのレコメンドで以下の本を見つけた。
確かに電子工作において遭遇する言葉の一つ一つをなんとなくわかった気になって、
お手本通りに作った結果動くものができたという状態から、
まず網羅的に基礎知識を把握してから電子工作における様々な作り方を理解したいと思うので、
次はこの本を読んでみたいと思う。
MANABIYA1日目に行ってきた
3/23,24に開催されたMANABIYA(https://manabiya.tech/)の1日目に行き、
機械学習ハンズオンとインフラ系セッションに参加してきました。
普段はネイティブアプリのサーバーサイドエンジニアとして働いており、
業務で機械学習を活用したりインフラ領域に深く携わることはありませんが、
今後理解を深めていきたい分野のためせっかくの機会と思い参加しました。
Python + Keras + TensorFlowによるディープラーニング実践（入門）
AidemyのCEO石川氏によるハンズオン形式のセミナー
内容としてはAidemyの機械学習概論(https://aidemy.net/courses/2010)とディープラーニング基礎(https://aidemy.net/courses/5090)に基づいたもので、機械学習に関する解説と深層学習による手書き文字認識、画像認識についてKerasを用いてJupyter Notebook上で実際に動かすといったものでした。
解説がわかりやすくハンズオンでも実際に動かすイメージを持つことができて非常に良かったので、今後Aidemyの各コースも一通り受けてみようと思います。
本気で機械学習やる人のためのハンズオン ～教師データ作成から学習・性能評価まで～
www.slideshare.net
来栖川電算の方々によるハンズオン形式のセミナー
はじめに機械学習の概要と向き不向き、機械学習プロジェクトの進め方について解説がありました。
以下解説メモ
- 機械学習とは
- 人間の学習能力や推論能力を機械に模倣させる手法(自動プログラミングの一種)
プログラミングとの対比
- プログラミング：推論のプロセスを人間が考えて記述。実装仕様が明らか。
- 機械学習：具体的な実装仕様がわからなくても適用可能。ただし膨大なデータが必要
機械学習プロジェクトについて
機械学習プロジェクトの進め方
- 仮説検証の繰り返し
- AIエンジニアとデータ管理エンジニアが協力してルールを考案し、よりよいタスクへ再定義していく
- 精度評価においてもタスクに応じて見るべき指標が異なってくるため、タスクを確定させていきながら見るべき指標を絞っていく
ハンズオン資料 github.com
ハンズオンはAWS SageMakerを使ってJupyter Notebook上で花札の画像認識の実装を体験するというものでした。
AnnotationFactoryという来栖川電算のプロダクトを用いて作成された教師用花札画像データをSSD (Single Shot Multibox Detector) モデルで学習させる転移学習です。
AWS SageMakerについては日本リージョンではまだ利用不可であり活用事例は少なく費用面も高めなので実務想定の話ではありませんでしたが、Jupyter Notebookの含まれた機械学習を容易に試せる環境として選択したとのことでした。
マイクロサービスアーキテクチャとサーバレスからDevOpsへ
アマゾン ウェブ サービス ジャパン株式会社 プロダクトマーケティングエバンジェリストの亀田氏による講演
AWSの歴史の紹介と設計思想やインフラ技術、開発手法など幅広い解説がされていました。
以下講演メモ
AWSの由来
-
- 最初はモノリシックアーキテクチャ
- アンチパターン
- システムの大規模化によって遅延などの弊害が生じ始める
- SOA(Service Oriented Architecture)
- Two-pizza teams
- チーム内部は密結合になることもある
- この規則を超える人数のチームは作らない(コミュニケーションコストが肥大化することを防ぐ)
- DevOpsの概念
- 厳密にインターフェースを保つ
- 保つことができなければデグレが生じる
- チーム内部は密結合になることもある
- 数千のチーム × マイクロサービスアーキテクチャ × 継続的デリバリ × Infrastructure as a code = 年間5000万回のデプロイ
- Infrastructure as a codeの内部分解
- Dev側のインフラ管理コストを極小化
- DevOps
- 最初はモノリシックアーキテクチャ
AWSのサービスから見る変遷
- 初期
- Auto Scaling
- セッション情報共有Pool
- 最新アプリケーションデプロイ
- AMI再生成パターン
- 緊急時の対応などに対しては重い
- Bootstrapパターン
- OSの新規立ち上げの時間がかかる
- Loadingデプロイ
- 一台ずつ切り替えていく
- AMI再生成パターン
- コンテナ、サーバレス
- EKS,Fargate
- 初期
ソフトウェアの設計においてもインフラのリソース管理においても開発組織の形成においても、構成要素を必要最小限の粒度まで落とし込んでインターフェースを厳密に管理し疎結合にすることで効率とスケーラビリティが得られるということがよくわかった。
小さくすることはあくまで手段であり、解決したい課題が先にあってこそなので、その課題を正しく見出すことも大事だと思った。
その意味でもインフラ面について単に実装に必要なサービスを知るだけではなく、コスト面やリソースの最適な活用、あるいは継続的なデプロイのためのパイプラインをいかに整備するかということにも意識を向けて様々なプラクティスを知りたいと思った。
マイクロサービス on マルチクラウド
株式会社メルカリ SRE/プリンシパルエンジニア 長野氏による講演
メルカリのインフラの歴史やマイクロサービスとマルチクラウドの運用事例とマルチクラウドの課題についての紹介
以下講演メモ
メルカリのシステム概要
マルチクラウドの構成
インフラの歴史
IaaSを中心としたマルチクラウド
オペレーションの共通化・少人数運用の実現
シンプルな三層構成
- EC2/GCEを主に利用
internal DNS
- 全てのサーバにunboundを導入
- ローカルキャッシュによるパフォーマンス向上
- resolv.confより障害に強い
サービスの可溶性と柔軟性を確保
マイクロサービス
- サービスのレジリエンス向上
- 細かいスケーリングと障害の分離
- チーム、組織のスケーラビリティを高める
- 1000人以上のエンジニア組織を志向
- サービスの開発速度の向上
- サービスのレジリエンス向上
USリアーキテクチャ
-
- マイクロサービスを進めるため
Kubernetes
- AWS EKS, Fargateの検証
- k8s on Metalの検証
Spinnakerhttps://www.spinnaker.io/の採用
- デプロイパイプラインを定義、自動実行
マルチクラウドの課題
- 今後について
調べてみると以前からメルカリのマイクロサービス化が進められている話やマルチクラウドの話について、技術的にはchoconやSpinnakerを実用している話について発信していたみたいだが、自分にとっては初めての話で面白かった。
一つのクラウドサービス(自分はAWS)でどのようにサービスを構築するか、新しいサービスの使い道をどうするかということについ捉われがちになっていて、それでもちゃんとしたサービスを構築して開発運用できていれば問題ないのかもしれないが、よりサービスの質を高めるためにはいくつかの主要なクラウドサービスのpro/conを知った上で活用する手法を考えるべきだと感じた。
DeNA TechCon 2018に行ってきました
DeNA TechCon 2018に行ってきました。
聴講したセッションは以下の通りです。
- Keynote - エンジニアが引っ張るDeNAの"モノづくり"
- SWETの取り組むImage Based Testing
- 大規模ゲーム開発におけるBuild高速化と安定化
- DeNA TechCon2018 ゲーム体験を支えるための強化学習
- 世界へ向けたゲーム開発 ローカライズ支援ツールLION
- DeNAのネイティブアプリにおけるサーバー開発の現在と未来
- 全体的な感想
内容を改めて振り返りつつ、レポートとしてまとめていきたいと思います。
※あくまで自分がメモした内容を書き連ねているものであり、
各タイトル下のリンクにあるスライドの内容が正しいものとなります。
Keynote - エンジニアが引っ張るDeNAの"モノづくり"
概要
DeNAの歴史を振り返り、それぞれのシーンでエンジニアがどのような挑戦をしてきたかという話。
また、掲げているミッション・ビジョンに合せてエンジニアのあり方、モノづくりをどう捉えているか語られていた。
- ミッション
- Delight & Impact the World 世界に喜びと驚きを
- ビジョン
- インターネットやAIを活用し、永久ベンチャーとして世の中にデライトを届ける
DeNAの歴史を大きく分けると以下の3つ
EC, SNS
- ビッターズ、モバオクの開発
モバイルゲーム,ゲームPF
Mobageの開発
- エンジニアがサービス設計を主導
- 使いやすさに拘り抜いて開発
- 川崎氏が1人で3ヶ月で開発
- 1人のエンジニアがサービスを考え抜いて開発をしていくことが理にかなっている
- 要件定義から実装まで、1人で考えながら手を動かすことでスピードも出る
- もちろんサービスの規模が大きくなれば1人ではカバーしきれなくなるが、
最初に動くものを作る上では1人で考え抜く方が早くちゃんとしたものが作れる
Mobageの負荷分散
- トラフィック急増に伴い、1日あたり20数億PVが発生
- MHA for MySQLの技術的挑戦(MHA for MySQLとDeNAのオープンソースの話)
- サービスを止めずにメンテナンス可能に
-
- ブラウザでネイティブ並みの表現を
- グラブルでNative並みの表現を実現したWahid(GitHub - DeNADev/wahid: A CreateJS-compatible library for games)
- 5fps -> 30fps
- CreateJSとの互換性を維持
- 端末、OS、ブラウザーの差異を吸収
事業多角化
タクベルの開発
自動車事故削減に向けたCV技術を活用
- Deep LearningベースのCV技術
- CVをエッジ(車載端末)で動作させる組み込み
- 運転行動指標を算出するデータサイエンス
- 安全運転コーチングに向けた危険予知
- Deep LearningベースのCV技術
まとめ
- サービスづくりをエンジニアが引っ張る
- いいモノづくり = Delight につながる
- サービスの課題を高い技術力で解決
- サービスの拡大 = Impact につながる
感想
- 市場において先行する、あるいは他にない規模のサービスを展開する上で技術的な挑戦は不可欠。
- いかなるサービスも最初はプロトタイプ開発からであり、エンジニアが主体となりスピード感とこだわりを持って開発するべき。
- サービスの種類やフェーズによって問われる技術やエンジニアとしてのスタンスは少し異なるが、
いずれにしても技術によって課題解決を図ること、サービスを考えながら開発に取り組むことが重要なのだと思った。
SWETの取り組むImage Based Testing
概要
DeNA社内でテストの自動化やエンジニアの生産性向上のためのツールの開発・導入などを行うチームであるSWETが、 どのような技術開発を行ったかについての事例紹介。 以前からDeNA TechConなど社外発表の場において技術開発事例紹介をしてきたが、 今回はWeb ApplicationとMobile Game(Native Game)におけるImage Based Testingについての紹介。
SWETのミッション
- DeNAのサービス全般の品質向上
- エンジニアの開発生産性向上
Web Applicationにおける事例紹介
WebApplicationにおけるVisual Regression Testingの紹介
既存のVisual Regression Testingに関するサービス
- browserStack(Cross Browser Testing Tool. 1000+ Browsers, Mobile, Real IE.)
- 多様な端末、ブラウザ上でのキャプチャ取得が可能
- Applitools(Automated Visual Testing | Applitools)
- 過去画像との差分を表示してくれる管理コンソール
- browserStack(Cross Browser Testing Tool. 1000+ Browsers, Mobile, Real IE.)
Visual Regression Testingの課題
スクリーンショットクローラ
- 自律的にサイト内を巡回・テスト対象ページを見つけ出す
- モチベーション
- UIテストに詳しくなくても自動テスト管理できるようにしたい
クローラ利用の流れ
並列化
クローラ部分のシステム構成
- zalenium(GitHub - zalando/zalenium: Allows anyone to have a disposable, flexible, container based Selenium Grid infrastructure featuring video recording, live preview, basic auth & online/offline dashboards)
- WebdriverIO(WebdriverIO - WebDriver bindings for Node.js)
- クローラ側ではスクロールバーやクリックすみリンクなどの差分は検出しないように作り込みをしている
画像差分の確認
- githubの利用
- masterブランチに正解データを入れ、masterとの差分を目視で確認
まとめ
課題
- フォーム入力
- サイトごとにカスタムロジックをかく→最初の問題に逆戻り
- フォームを検出して自動で埋める技術が必要
- 同一ページ内の状態変化
- 取得したいキャプチャは1ページ1枚とは限らない
- レンダリング結果の違いを自動で検出する
- フォーム入力
- 展望
機械学習によるUIの意味認識
- 意味に基づくエレメント取得
Webページの意味解析技術
- 先行研究 Using Semantic Similarity in crawling-based web application testing
- HTMLをパターン認識して、UIエレメントの意味やページ状態を推定する
会員登録フォーム意味推定
- 精度としては大体100%近くから50%くらいまで
- 全結合三層のNN
- 深層学習ではない
- トピックごとに精度の差があり
- 生年月日はselect boxなので判別しやすい
- userIDはサービスの名前が入ってきたりもして判別しづらい、など
- ポップアップなどのパーツへの拡張
- 学習データの拡張と深層学習の適用予定
Mobile Gameにおける事例紹介
※ ゲームアプリ = Mobile Game(Native Game)
ゲームアプリのUIテスト自動化の現状
- web/ネイティブアプリはテスティングツール・ライブラリやノウハウが整備されており、UIテストの実装を行いやすい
- ゲームアプリに対してはそういったデファクトのツールやプラクティスが整っていない
ゲームアプリのUIテスト自動化の難しさ
画像処理技術を使って自動化
- Open CVのテンプレートマッチング
テンプレートマッチングとは
- 特定の画像パターン(テンプレート)が存在するかを判定
画像処理を使った自動化へのハードル
- 画像処理および画像処理ライブラリに関する知識の習得
- 画像処理に向いた言語の習得
- イメージアセットの管理
- 閾値のチューニング →これらの面倒なところを省力化するためExMachinaを開発
Exmachina
- テスト用イメージアセットの管理
- ページ単位、ページ情報という形で管理する
- 識別子(Identifier)とどのような操作が可能か(Action)を管理
- ページの判定機能
- 画像データをインプットとしてそれがどのページに該当するのかを判定
- セマンティックな情報を使ったテストが可能
- ページ判定機能を使ったテストシナリオの自動化
- テストシナリオは簡易に記述できるようにしてある
- 画像処理やAction実行といった複雑な処理はバックエンドで吸収
- テスト用イメージアセットの管理
シナリオテストの自動化からクローラへの応用
- テスト用イメージアセットの管理(Identifier, Action)から、現在どのページにいるか、どのようなアクションが行えるかを取得可能
- クローリング結果の比較
- 画面遷移の差分と、ページの画像的な差分を取れる
- 意図せぬUIの変更や、エラークラッシュの検出が容易になる
まとめ
- アプリのページ情報を管理する
- セマンティックな情報に基づいたテストを実現
- バックエンドで画像処理など複雑な処理を吸収するため、画像処理を意識せずにテストプログラムを組める
- ゲームアプリに対してもVisual Regression Testができる
課題
- ページ登録作業(テスト用イメージアセットの情報登録作業)の省力化
- 複数解像度への対応
対応
- semantic segmentation
- 画像内の各画素がそれぞれどのオブジェクトクラスに属するのかを分類するためのアプローチ
- ネイティブやウェブアプリでセマンティックな情報を取得し、それを学習データとして、ゲームアプリを解析させる
- pix2code(GitHub - tonybeltramelli/pix2code: pix2code: Generating Code from a Graphical User Interface Screenshot)
- 画像からxml/htmlに起こしてセマンティックな情報での解析に繋げる
- semantic segmentation
全体まとめ
- Web ApplicationとMobile GameそれぞれにおいてImage Based TestingによるUIテストの自動化を行った
- 今後、さらなる自動化・省力化のために機械学習を活用していく
感想
- それぞれの事例において個別のプロダクトに依存しない汎用的な形、かつ利用者にとって導入コストが低くなるように作られていて素晴らしかった
- 品質・生産性の向上を図る上で自動テストの存在はもはや欠かせないものだが、その維持コストを極小化するために機械学習の導入というアプローチが取られるのは手段としても技術的にも興味深い話だと思った
大規模ゲーム開発におけるBuild高速化と安定化
概要
大規模化するゲーム開発においてビルドの高速化、安定化には大きな価値がある。 ビルドの高速化、安定化のためのUnity、Jenkinsにおけるプラクティスの紹介と、 その他自動化、ワークフロー改善事例の紹介。
大規模複雑化するスマートフォンゲーム開発の課題
- 高品質かつ多機能
- 短いスパンでの機能、イベントの提供
- 特にアセットの容量が肥大化、ビルド時間が膨大に
- ライトからコアユーザーも遊べる複雑なゲームスキーム
- グラフィックスも2Dから3Dへより高品質へ
複数のGameイベントを週替わりでリリース →お客様を飽きさせないために様々な取り組みを並行で走らせなければならない
生じる問題
- コンテンツ・Asset大容量化→ビルド時間が膨大→毎日QAを回せない→品質が悪い→お客様に満足してゲームをPlayしてもらえない
Build高速化は非常に価値がある
- try and errorを回しやすくする
- QAを回しやすくする
Buildを高速化して課題を解決(Unity・Jenkins)
- Unityプロジェクトのリポジトリをキャッシュ
- AssetBundleの差分Build
- 分散・並列Build(プラットフォーム、開発案件ごと)
その他
- スペックが高いマシンでbuildしているか
- 対象ノードでウィルススキャンが実行されていないか
2,3についてUnity/Jenkinsの実践を交えて紹介
最大のボトルネックはUnity AssetBundle Build 差分buildで高速化しよう
- Unity AssetBundle Build高速化方法
- 一度buildしたAssetBundleファイルと同時に生成されるManifestファイルをgitで管理する
Unity側でManifestファイルをみて高速化してくれる - Assetは更新すべきファイルだけ、差分でbuildする
- フォルダの差分を検出するのは単純ではない
フォルダに含まれるアセットが別フォルダの共有アセットへ依存している - 共有アセットを含めフォルダの差分を検出したい
- 一度buildしたAssetBundleファイルと同時に生成されるManifestファイルをgitで管理する
- Unity AssetBundle Build高速化方法
EditorUtility.CollectDependencies()を使うことで共有Assetも差分検出できる
(AssetBundle 対象のフォルダついて、Asset の依存関係も含めて実ファイルのハッシュ値を計算する · GitHub)- AssetBundle対象フォルダは以下の各種Asset + Assetが依存するすべてのアセットファイル → フォルダ内のすべての実ファイルハッシュ値が計算できる
このようにあらゆる高速化を組み合わせる必要がある
Jenkinsを活用した分散・並列Build
- Jenkins Master/Slave全体構成
- Jenkins masterへの命令通知
- 各Slaveでの処理
Client Build, AssetBundle Build, Master validation, preprocess, migration, deploy, etc... - アプリのupload, githubへの自動コミット, BaaSのデプロイ
- 並列開発をしていると、キューが詰まるため、案件・ブランチごとにslave nodeを分ける
- Jenkins Master/Slave全体構成
Jenkins - Platformごとに分散Build
- Build Flow pluginのparallelブロックを使うことでノードごとに分散・並列実行できる NodeLabel Parameter Pluginを利用
- Nodeごとに同じJobは同時に一つだけ実行できるようにしたい場合はThrottle Concurrent Builds Pluginが使える
Jenkins - 同一開発ブランチで排他制御
- Masterを扱う処理は同一開発ブランチで安易に分散並列ビルドすると不整合が起こる
- 開発ブランチ単位で排他制御しつつ並列実行、高速化が必要
- Groovyでコードを書いて排他制御できる (Jenkins – 同一 branch を Groovy を使って排他制御 · GitHub)
DeNAのゲーム開発はSakashoを使いサーバレスアーキテクチャが主流に
Baasを用いると開発効率は上がるが、migrationについては別アプローチが必要
- 手動オペレーションが入ると障害が発生する
- データマイグレーションの最適化・徹底した自動化が必要
- 4つのフェーズでマイグレーションを最適化、自動化を徹底
merge → validation/build → migration → deploy
- 4つのフェーズでマイグレーションを最適化、自動化を徹底
- 手動でmergeコンフリクト解消も大変
- merge祭りjob導入
- merge作業を自動化、人為的なコンフリクト以外は自動的に解消
- ほぼコンフリクトの内容は自動で解消できる、現在のブランチを正とする
- merge祭りjob導入
- 手動でデータ更新は不整合が起こる
- データMigrationを徹底して自動化
- 先々起きるわからない問題は考えず、手動が入ることでの事故を防止するために徹底的に自動化
- 極力シンプルなJobで設計する必要がある
マイグレーションを自動化するJobインターフェース
- Configuration / Run に分離
- パラメータを設定するだけで使い回せるよう共通化
- コケたjobから容易に再実行
その際に省略可能なjobのチェックを外す - cronで時間起動する
大規模開発に適したgitワークフロー
1. エンジニア以外も全員gitを使う
2. エンジニアを介さずにpull requestをmerge出来るまでワークフローを熟考する
危険なデータがマージされない仕組みを考え抜く
すべてのAssetはimportする際にチェックして所定の場所に配置
キャラクタ、マップ、クエストはパラメータから自動生成
MasterはJenkins JOBでスプレッドシートから自動pull request
3. 事故が起きたらエンジニアが責任を持って振り返る覚悟でやる
まとめ
- 大規模化されていくゲーム開発に対して改善を積み重ねていくことが大事、絶えず改善することで安定化できる
- 様々な改善策は毎日考え続けることである日パッと思い浮かぶ
- スマートフォンゲームはまだまだ大規模化する
感想
- ゲーム全体のアーキテクチャや更新データ入稿の頻度などによって具体的なプラクティスは異なりそうだが、どのような環境においても通じる考え方を聞くことができてよかった
- 特に並列開発におけるフロー整備やJobの切り分けについては最初から完璧にできるものではないが、常に改善を続けることでやがて品質の底上げにつながるということを実感しているので、非常に参考になり面白かった
DeNA TechCon2018 ゲーム体験を支えるための強化学習
DeNA TechCon2018 ゲーム体験を支えるための強化学習
概要
逆転オセロニアにおけるAI開発の取り組みについて現状の開発事例と今後の展望についての紹介
ゲーム領域におけるAI開発の背景
- 逆転オセロニアについて
- 戦略に応じてバランスよくデッキを構築する必要がある
- ルールはシンプル、戦い方は多様で奥深い
- キャラクタースキルの微妙なバランスや流行によってゲーム環境が日々変化している
- キャラクタースキルのバランス調整をミスなく、効率的に行いたい
- 絶妙なバランスを保つ難易度が高い
- ゲーム環境はどんどん複雑になるので調整コストも爆発していく
- ミスをするとゲームの品質を落とす、ゲームバランスの毀損
- 解決したい運用課題
- 新しいスキルの評価が正確にできない
- キャラクターの性能テストにかかる工数が大きい
- チューニングを続けても見落としリスクがある
- すべてのユーザーセグメントの体感を検証するのは難しい
- 実現できたら嬉しいこと
- リリース前の新しいスキルでも検証ができること
自律的なキャラクター運用の学習 - 大量の検証によって性能を評価できること
シミュレータを使った大量の自己対戦の実現 - 壊れケースを効率的に検知できること
人間のようなリテラシーで合理的に探索する方法の実現
- リリース前の新しいスキルでも検証ができること
新環境でも柔軟に運用方法を獲得する強いAIの実現
強化学習を使ったアプローチ
強化学習とは
ある環境下で、目的とする利益を最大化するための戦略(行動系列)を獲得する機械学習の一種- 未知の環境（新しいゲーム環境）に対しても学習が可能
- 試行錯誤を繰り返しながら自律的に学習ができる
強化学習とゲームタスク
研究開発ロードマップ
4つの技術を組み合わせ環境に柔軟に対応する強いAIを作る- 教師あり学習
そもそも学習ができるのか検証(プレイヤーの対戦ログを使用)
大量の棋譜ログを活用し人間が実際に打つような打ち手を学習 - 表現学習
キャラクター運用の特徴を学習
キャラを拡張できるか検証 - 強化学習
自己対戦による自律的な学習 - 先読み機能
数手先を読むことによる推論的な学習、強化学習時の学習サポート
- 教師あり学習
AI技術の紹介
教師あり学習
- 上位プレイヤーの対戦棋譜を用いて作成
- 入力データ(特徴量)
- ステータス
- 手駒・デッキ情報
- 選択可能な行動
- 盤面情報
- 出力データ（教師信号）
- プレイヤーが選択したかいなかのバイナリ変数
- 入力データ(特徴量)
- 上位プレイヤーの対戦棋譜を用いて作成
アーキテクチャ概要
- DQNに着想を得た構造
- 盤面情報は畳み込みニューラルネットワークで処理
- DQNに着想を得た構造
実験結果
- 既存NPC(ルールベースAI)に対して高い勝率が出せている
- AIはチューニングによって既存ルールベースAIより大幅に強くなる
- 意味のある戦術を学んでいることが示唆できる
設定と工夫点
- 選択・非選択を教師信号として再利用
- 人間のようにプレイするAIを獲得したい
- 上位プレイヤーの負けた情報も有効活用
- ネットワーク・学習の詳細
- Batch Normalizationは有効、Dropoutは弱め
- 活性化情報：ELU(ReLUよりも有効だった)
- 損失関数：Cross Entropy
- 大量の棋譜があるためデータ読み込みを効率化
- 並列化、キューなどを駆使してデータ読み込みを効率化
- 選択・非選択を教師信号として再利用
表現学習
- 何ができるのか
- キャラクターを低次元のベクトルで表現できる
- キャラクター数分の次元から固定次元に削減できる
- モデルサイズ削減、学習速度向上が期待できる
- 運用方法が似たキャラクターは同じような表現になる
- キャラクターを低次元のベクトルで表現できる
- 何ができるのか
-
- 低次元ベクトルを獲得する埋め込み層を行動入力の後に導入
- マルチタスク学習としてモデルを訓練する
獲得した表現の可視化
- キャラ表現を2次元に削減しプロット
- 戦略に応じた表現が得られる
- 低次元ベクトルを活用して教師あり学習・強化学習を効率化
- キャラ表現を2次元に削減しプロット
強化学習
- 自己対戦による自律的な学習
自己対戦による成長
- 強化学習エージェントは自分自身と対戦して自律的に戦略を学ぶ
- 対戦相手も自分と同様に成長
- 過去バージョンを使用
- 実際は様々なAIエージェントを相手として用いる(教師あり学習エージェント、ルールベースAI、etc...)
- いろんな対戦相手に対応するため
- 実際は様々なAIエージェントを相手として用いる(教師あり学習エージェント、ルールベースAI、etc...)
- 強化学習エージェントは自分自身と対戦して自律的に戦略を学ぶ
実験結果
- ある特定の状況ではゼロからミドルレベルのプレイヤー並みまで成長することが確認できている
難しさと対策
オセロニアへの強化学習の適用には複数の難しさがある- 毎ターン取れる行動の種類が変わる(可変長行動)
- 可変長行動を扱うネットワーク構造の使用＋表現学習
- 豊富な計算資源を使っても実験に時間がかかる
- 教師あり学習の結果を強化学習の初期化に一部使用した効率化
- いろんな戦術の相手 + 不完全情報
- 様々な戦略を持つAIエージェントとの自己対戦
- 毎ターン取れる行動の種類が変わる(可変長行動)
先読み機能
オセロニアでの活用案
- 強化学習との組み合わせによるAIの強化
- 推論サポート
- ミスが許されない勝ち筋を見つけやすくなる
- 先読み機能だけでも教師あり学習・強化学習と同じような強さが確認できている
- 不利なデッキ同士の対戦でも高い勝率
- シミュレータの計算速度に依存した課題も存在
- 強化学習との組み合わせによるAIの強化
まとめ
Webツールを活用したチューニング
- AIの戦いを可視化するWebツールを使用してチューニングをサポート
- 統計量の可視化
- AIの人間らしさを検証
- AIの戦いを可視化するWebツールを使用してチューニングをサポート
今後に向けて
プロジェクト観点で難しい点、嬉しい点
AI活用を見越してやっておいたほうがいいこと
- 高速なシミュレータ開発
- 描画ロジックとバトルロジックを切り離しやすいような設計
- AIの学習を念頭に置いたログ設計
- プレイヤー分析のためのログ以外にもAI学習用のログ設計が必要
- 最新技術に追従する体制づくり
- 現場との密なコミュニケーション
- 課題を適切に定義する、企画提案するためのサービス理解
- どれほどの成果が出るかがわからない、期待値のすり合わせが必要
- 高速なシミュレータ開発
研究開発観点のやりがい
今後の可能性
- 今後ゲーム業界全体においてAI活用が活発化してくるのではないか
- 実用化を加速させるために会社の枠を超えた知見共有を行いたい
感想
- 様々な事例が紹介され、特に表現学習における獲得した表現の可視化の部分が良かったと思った
- ゲームの運用面から考えると人による判断が最終的に方向性を決定しているため、ゲームにおけるAI活用の取り組みとは何か奇抜な新しいゲームの仕組みを作り出すためのものではなく、人が参照できる情報とその分析の幅を広げ、多角的にゲームの状態を判断するための取り組みだと再認識させられる
(ユーザーが自らAIクライアントを育てて何かするようなゲームにおけるAI活用、みたいなものは除く) - 運用されているゲームにとってバランス調整は肝でありそれを補助するという時点ですでに成果を出していると個人的には思うが、さらなる成果を追求していった結果として運用タイトルを遊ぶユーザーの未来の行動全体を予測する仕組みができて、ゲームバランスだけでなく事業面に対しても優位な示唆が得られるものが出来上がるのではないかと思った
世界へ向けたゲーム開発 ローカライズ支援ツールLION
世界へ向けたゲーム開発 〜ローカライズ支援ツール『LION』〜
概要
モバイルゲームの海外同時配信・運用におけるローカライズ支援ツールとして開発されたLIONが実際にどのような課題を解決しているかについての紹介
モバイルアプリ運用時代のローカライズ事情
ゲーム事業部が目指している事
- 日本で評価されているゲームを世界中に発信する事
- そのために
- 各地域に合わせた適切なローカライズを行う必要がある
ゲームのローカライズとは
多言語化のフロー
- ローカライズすべき文字列のすべてに対してユニークなIDラベルをつける
- すべてのIDに対し日本語でデータ作成後、それを元に各言語へ翻訳していく
- 言語によってはどの言語からどの言語に翻訳できるかに制約があるため、2段階に分けて翻訳を進める必要がある
ex)日本語→英語→フランス語、イタリア語、etc...
- 言語によってはどの言語からどの言語に翻訳できるかに制約があるため、2段階に分けて翻訳を進める必要がある
ローカライズタイトルのスケジュール
- 企画が決まり、日本語テキストが準備できたら翻訳開始
- 翻訳完了後は、テキストバグがなくなるまで修正、反映を繰り返す
運用フェーズに入ると
- データ更新の際にテキストの追加や更新も同時に発生
- それぞれの開発で同じフローを繰り返し実施
→運用を考慮したローカライズフロー構築が重要となる
翻訳開始から完了までの作業と役割
- 翻訳のために必要な作業
- 翻訳ファイル準備
- 各種スケジュール調整
- 翻訳者への翻訳ファイル発注
- 翻訳ファイルの納品確認
ここまではコーディネーターの作業 - 翻訳作業(間違い修正含む)
翻訳者の作業
- 翻訳のために必要な作業
コーディネーターの作業詳細
- 翻訳対象の抽出
- 新規翻訳及び更新などによる変更部分に判別して翻訳依頼する
- 補足情報の追加
- 重複している文字列の排除
- 文字カウント
- スケジュール、費用検討
- 翻訳依頼ファイルを作成する
- 翻訳の進捗管理
- 翻訳対象の抽出
翻訳者の作業詳細
- 翻訳者は依頼ファイル内のテキストを翻訳
- コーディネーターが準備した補助情報が正確な翻訳の鍵となる
- 補助情報とは何か
- スクリーンショット
- 使用箇所や表示領域などの情報
- 関連テキスト
- 補助情報とは何か
これらが手作業だと何が起きるか
- 翻訳発注ファイル作成の準備効率低下
- 作業時間を要する
- ミスが発生しやすい
- 用語統一の困難が発生
- 適切な管理をしないと多大な時間を要する
- 翻訳発注ファイル作成の準備効率低下
運用タイトルにおけるローカライズの課題
- 手作業を可能な限り自動化し、効率化して困難をなくすと運用タイトルの同時ローカライズでも品質を高くできる
ローカライズ支援ツールLION
ローカライズで発生する様々な手作業
→システムに落とし効率化、標準化するLIONとは
LIONの機能
- プロジェクト設定
- 複数タイトルで同時利用
- 他のタイトルに関する情報は見れてはいけない
- ローカライズフローでは様々な役割のメンバーが作業
- 各役割に最適化したUIが必要
- 複数タイトルで同時利用
→適切なアクセスコントロール
→プロジェクトごと、アカウントごとのロール設定
- 翻訳テキストの依存関係を考慮した適切なバージョニングが必要
翻訳者ごとに表示すべき翻訳元言語が違う
文字列ID/ラベル管理
- 各テキストをユニークなID/ラベルで管理
- 言語ごとのバージョン管理
- どのバージョンのテキストをどの言語に翻訳したのか正しく追跡できるようにする
xlsxによるアップロード
- 慣れたアプリケーションを使用してデータ作成したい
- webのUIを使って一つずつ入力するのはとても面倒
- 更新内容は目視しやすくしたい
→xlsxファイル形式での一括入力をサポート →アップロード時の差分自動抽出
- 慣れたアプリケーションを使用してデータ作成したい
柔軟な文字列検索
- 様々なケースで検索が必要
- ソース言語の更新が反映されていない文字列
- 単語自体が間違っていた文字列
- データベース化によって各検索用途に対応
- 様々なケースで検索が必要
検索結果に対して一括操作
- 大量データの更新を一括で行えるように作り込み
- 内容修正
- ハッシュタグ付与
- xlsxダウンロード
- 大量データの更新を一括で行えるように作り込み
リリース制御
- 運用においてデータ更新は何度もある
- 更新タイミング
- イベント、機能追加、UI改修、etc...
- 並行して開発されているデータに同じ文字列が含まれることもある
- 更新タイミング
- リリーススケジュール設定管理
- リリース名
- 公開順を決める通し番号
- ID/言語/バージョン単位でスケジュール設定可能
- これらによりリリース時の事故を防止している
- 運用においてデータ更新は何度もある
翻訳サポート
- 翻訳対象の選定時・翻訳時に必要な情報
- 翻訳メモリ
- 翻訳済みデータとの類似率表示
- 含有文字列
- 用語集
- コメント・ファイル添付
発注フローのシステム化
- 複数の発注が同時並行で処理される
- コーディネーターの役割である発注管理の負担大
- 一つの発注に関連する情報を保持するオーダー
- ピックアップした文字列のリスト
- 文字カウント
- スケジュール
- アサイン
- LIONがオーダー管理をサポート
- 複数の発注が同時並行で処理される
バックエンドのAPI化
- 使いやすいUI→SPA化
- SPA化のためにAPIが必要
- アプリのビルド環境への組み込みにも必要
- Jenkinsなど
- 使いやすいUI→SPA化
LIONの技術コンポーネント * サーバー * Ruby on Rails + MySQL + Elasticsearch * API化
フロント
CI
- サーバ、フロントの自動テスト/ビルド
- 開発環境への自動デプロイ
LIONの運用
- 運用タイトル、開発タイトルそれぞれで使い始めるための準備中
- 運用からの組み込みと開発時からの組み込み→大きく違う
- 組み込みに当たって見えてくる課題は今後解消・最適化していく予定
今後の展開
- 便利機能
- 各操作手順をできるだけ減らすための最適化
- UI情報の保持
- 文字数/行数制限
- 通知の最適化
- タイトル側で使うためのコンポーネント
- コンバータやランタイム提供
- 自動翻訳？
- 没入感を損なわないレベルの自動翻訳が前提
- 便利機能
まとめ
感想
- ゲームタイトルの運用において煩雑な手作業の数々を一つのシステムにまとめるというのは、作業リソースの削減だけでなく障害の元となる入稿ミスやデータの不備を防ぐことにもつながるので、単純な効率化に収まらない大きなメリットがあると思う
- LIONの事例においても翻訳サポートツールとしての機能に限らず、アプリのビルド環境への組み込みやリリース制御の機能まで含まれているのは、ゲームタイトル運用での翻訳にまつわるコストやリスクを最小限に抑えるための有効な手段だと思った
- 翻訳に限らずゲームにまつわる各種データ、ファイルについて汎化された編集・入稿ツールがあるか、開発できるかというのは開発組織としての長期的な資産に関わってくるのではないかと思った
DeNAのネイティブアプリにおけるサーバー開発の現在と未来
概要
ネイティブアプリ向け内製BaasのSakashoを開発しこれまでどのような戦略でサーバーサイド開発をしてきたのか、そして今後どのように展開していくのかについての紹介
これまで
- 現在
- 内製開発6タイトルリリース
- 多数のタイトルを新規開発中
- 協業開発でも多数のタイトルを開発・運用中
どういう戦略でここまで来たのか？
- Sakasho
- 内製Baasであり汎用ゲームサーバ
- 特徴
- Sakashoサーバー+クライアントアプリで完結
- 多数のタイトルのサーバを一手に引き受ける
- 同一アプリケーション
- 一つのチーム
- タイトルチームはクライアントエンジニアだけ
- サーバー開発は一切していない
- 一般的なソーシャルゲームの機能をほぼ実装
- Sakasho
なぜそうしたか
- 選択と集中
- Webブラウザゲームでは単縦な表現力について一定の制限がある
- その中で様々なゲームシステムやサーバー技術が生まれた
- ネイティブアプリにおいてはその表現力を存分に発揮しないといけない
- 強みのある領域に集中するのではなく、強みを生むための領域に集中
- アーキテクチャの統一
- サーバーで何をやるかクライアントで何をやるかという設計
- キリがない話
- 一度間違うとかなり痛い目を見るポイント
- 最適かはわからないが間違いではないラインで全体を統一
- かなりクライアントに主導権を寄せている
- サーバーで何をやるかクライアントで何をやるかという設計
- 運用ポリシーの集中
- ゲームの外の世界だが、サービス運営には必要な要素群
- お客様対応
- 配信プラットフォームに関連する諸々
- ゲームの外の世界だが、サービス運営には必要な要素群
- サーバー技術の集約
- いわゆる大規模サービスを支える技術
- ネイティブアプリゲーム特有の傾向(やってみてわかったこと)
- Webサービスとネイティブアプリゲームとでは結構違う
- 選択と集中
結果
- サーバー開発・運用は1チームで同時並行で多数のタイトルを展開できた
- アーキテクチャはある程度統一され、同じノウハウを適用できた
- 各タイトルチームはクライアント側の開発に注力できた
- サービス運用はある程度均質化された
- サーバー負荷に関連するトラブルはかなり少なかった
→戦略が結果につながった
これから
現状を振り返り
どうすべきか
- 良い点：可能な限り残したい
- 独自のカスタマイズをしないなら開発が不要
- サーバー運用できるだけ省力化したい
- 課題点：全て解決したい
- 独自のカスタマイズや最適化を可能にしたい
- ホワイトボックス化
- 意志決定をチーム内で完結させたい
- 少数の組織が独自に意志決定できるように
- 独自のカスタマイズや最適化を可能にしたい
- 良い点：可能な限り残したい
具体的にどうすれば良いか
ネイティブアプリ開発の未来
- ブラックボックスではなくホワイトボックス
- 独自のカスタマイズをしないなら開発が不要
- 基本的な機能はライブラリとして用意
- 用意はするが、差し替え可能・改変可能
- 独自の機能を追加しやすいつくり
- 引き続き、共通基盤チームは作る
- タイトルを跨いだ最適化や再利用は行う
- 現在新規開発中のタイトル開発に合わせて取り組み中
まとめ
- 魅力的な面白いゲームを開発し、世界にDelightを届ける
- そのために
- より自由度高く、作りたいゲームが作れるように
- より開発効率よく、作りたいゲームに集中できるように
- この二つを両立できるような開発・運用体制を整えていく
感想
- 共通基盤としてネイティブアプリに必要なサーバー機能を網羅するように取り組み積み上げてきたからこそ独自カスタマイズも視野に入れて開発できるようにライブラリとして切り出すことが可能であり、これは当たり外れもあるゲーム開発においても大きく変わらないもの(サーバー機能)を共通で提供できるように固めて資産化してきたことの非常に大きなメリットだと思った
- 今後独自カスタマイズをするとしてもサーバー機能は一通り実装が揃っている状態でスタートできるのであれば、一から機能開発をするのではなくインフラ面で新しい取り組みをしたりログ収集・分析基盤開発に開発リソースを割くことができるので、より新しい挑戦がしやすいのではないかと思った
全体的な感想
- 全体を通してビジネス面での必要性に応じた各方面での自動化・効率化・集約化の話が多く、その上でどのような技術を使っているのかどういった設計にしているのかという考え方を学ぶことができた会だったと思う
- 主にネイティブゲーム開発に関わるセッションを受講したが、どれも大規模化していくネイティブゲーム開発に対して技術とその使い方で勝負しているので、今後より開発リソースに対するアウトプットのコスパが良い（良い意味で）開発ができるようになっていくのではないかと思った
