aretan.jp

その後のDeNAのネイティブアプリ開発¶

denaがwebからnativeにしてきた
2015からnativeをやりはじめた
2016からマルチプレイや3Dアクションにチャレンジ

戦力分析
17項目で150名のゲームエンジニアのスキルを評価
Beginner Junior Middle Senior Expert
全項目が0やbeginnerが75%
メインプログラマーみたいな50ptあるのが3人

市場分析
市場のアプリを開発難度や技術要素で評価
seg1 html
seg2 htmlではない
seg3 インタラクションの強いゲーム
seg4 リアルタイムで複数のオブジェクト
seg5 30fpsで3Dのゲーム
でグラフを作成してターゲットを分析

開発要素の分析
プログラミングパラダイム(非同期とか) → とくに問題じゃなかった
マルチメディアデータ(ブラウザじゃないから自分でやる必要) → 1回ミスると大体覚えたが、プロレベルでない
リソースマネジメント(CPU メモリ) → パフォーマンスはズルズル下りがち
チート(サーバサイドはセキュアにできるが、クライアントはいじられる) → とくに問題じゃなかった

DeNAではUnity(主に3D)とLiftEngine(主に2D)をつかってる
LiftEngineを3Dにも使いはじめている
サーバーサイドはSakasho(BaaS)とIRIS(マルチプレイゲーム用サーバ)
ゲーム毎に専用のサーバを開発する事は少ない

コールバック vs ポーリング
タイミング的にコールバックが呼ばれると困るケース
コールバックが呼ばれない、もしくは2回よばれた
逆に該当処理を2回呼びたい
もはやコールバックされる必要がなくなった
タイムアウトを入れたい場合
マルチスレッドへの対応
→複雑な処理を考えると結局ポーリングに近い実装になる
→ミドルウェアでコールバックだったとしてもIFを変換しちゃった方がいい

RDBMS vs 構造体
Sakashoの扱う2つのデータ
アセット：クライアントのストレージに永久にある、グラフィックやサウンド
マスター：クライアントのメモリで扱う、都度ダウンロードされる
構造体はPKが入らないパターンも多い
マスターをRDBMSみたいに使ってしまうとデータがデカいのでスペックが問題に
メンテナンス性も低いのでトラブルも多い
時代もあるので、ランタイムの処理効率と開発効率のバランスは適切に

Webサーバ vs ゲームサーバ
クライアントにゲームロジックや各種制御をよせる戦略に慣れれないメンバ
クライアント開発に転向したエンジニアはだいじょうぶだった
クライアントがどうやってるかコードを読んで調べるのが大変
課題としてゲームサーバは難易度が高い
→ネイティブシフトをしたらサーバサイドが一番つらかった

DeNA private cloudのその後¶

サーバ運用とネットワーク運用の統合：openstack big switch seph f5
IT基盤部ネットワークGへの作業依頼をなくしたい。。。
アプリサーバネットワークをone stopで対応できる人を増やしたい
→SDN、LBaaS/FWaaSを活用する事にした
SDN: BigCloudFabric
LBaaS: F5 BIG-IP
IaaS: OpenStack
仮想環境でVMを動かしているとホストが死んだときにメンドイ
サーバーにデータを持たずにStorageから動かすと、可用性もN+1ですむ
なぜsephをつかうのか。OpenStackとインテグレーションされてる
障害テストを経て採用を決定
コンテナはrexdをためしてるがまだ導入に至っていない
ーーーここまでが振り返りーーー
全エンジニアが開発環境として利用開始ノード34台インスタンス1730台
Openstackのバージョン：Producyion kilo、Development liberty
OSはUbuntsuを利用
運用がどうなったか、ネットワーク設定はサーバエンジニアが自ら設定
ロードバランサーもOrion(内製BIG-IP用API)で自ら設定
運用改善：live-migrationができるようになった
Big Cloud Fabricの特徴はアンダーレイネットワークをサポート
コントローラとスイッチから構成、Linuxが動作している
OpenStackでネットワーク作成すると、BCFにconfigが自動で生成されるように。
構成パターンの中でP-Fabric for Openstackで選んだ
ただし、L3の連携がされないので、そこを開発した。(DeNADev/networking-bigswitch-l3-pe)
BCF pluginでsyncが頻発してしまう、sync中は他の処理が動かない
NodeのAgentは追加/削除されたportをNeutronに通知するけど、それがsyncのせいで死亡
なので、agentを全部止めて、ちょっとづつ動かしていく
BCF Pluginの不具合をBigSwitchに報告して修正してもらった (OSSだからトラブルシュートできた)
F5 Hardware Applianceを現環境でもそのまま仕様することにした
OpenStack LBaaSv2の仕様が機能不足だった
neutron lbaas-loadbalancer-create
neutron lbaas-listener-create
neutron lbaas-pool-create
サーバへのログインはLDAPで管理
Cephはオープンソースの分散ストレージ(SDS)
オブジェクトストレージとブロックストレージの両方に対応している、ブロックストレージとして利用
MON：OSDの構成や状態監視
OSD：ディスクへのデータ読み書き(レプリカ数：3で運用)
Development 214TB/421TB
Production 18TB/22TB
nova evacuateでvmを他のノードに移動する
今後Virtual Machine High Availabilityを導入したい
ハイパーコンバージド構成をしている(KVM)
ディスクは全部HDDではじめた(8TB 7200rpm SATA-HDD)
やっぱI/O性能が問題になって。。。
OSDはjournalにかいてdataに書くようになってた
ディスクへのI/Oを下げるためにSASのHDDにjournalを移動した
VMのI/Oリクエストが待たされる問題が。。。
write request受信直後の処理が遅くなってそうとわかった
OSDはwriteされるとPrimaryから2ndと3rdに書き込む
なんらかの処理がつまってworker threadが枯渇してるんじゃないか
稼働中のスレッドダンプを見てみるとworker threadのほとんどがtcmallocで埋まってた
tcmallocのスレッドキャッシュサイズを32MBから256MBに拡張したら解決された!
課題fsync問題：データ同期が発生すると後続のwriteが待たされてしまう
→一部のサーバではファイルシステムのバリアオプションを無効にして回避
課題ネットワークの輻輳：TCPセッションでの通信でパケットロスしやすい
BCFのQoS機能を仕様してCeph以外の通信を優先するようにしようかと健闘
今後はコンテナの導入やVM-HAやceph以外のSDSの導入やOpenStackのバージョンアップをしたい

スケーラブル GCP アーキテクチャ¶

Google App EngineとCloud PubSubをベースにしてスケーラビリティの高いシステムを作る
やっぱDatastoreと非同期タスクの設計が重要
今回は非同期タスクについて話します
TaskQueueで非同期にできる
Push Queue：ワーカーにジョブを登録
Pull Queue：ワーカーがジョブをとりにいく
HTTPでジョブが送られてくるのでやりやすいよね~
課題：Push型だと500task/secまでに制限、それ以上は処理がおいつかない
シャーディングで解決、キューを20個用意すれば20*500でいけるよね
Cloud PubSubで秒間100万メッセージが処理可能
なので、Task QueueからCloud PubSubに移行しようか。。。
→HTTPリクエストがカスタムできない、Datastoreのトランザクションに含めれない
Bodyに入れちゃうしかないかなー
トランザクション問題はPubSubでリトライを難度かやれば結構成功する
失敗したらTaskQueueにフォールバックさせるようにしてる
PubSubのwindow設定値をdatastoreにもって、どの程度PubSubから受けられるかを定義
PubSubのslow startな再送ロジックを上手く活用、わざと失敗させて解決

DeNAでのチート診断・脆弱性診断の取り組み¶

(2名はセキュリティ会社出身)9人でセキュリティ部を構成している
cocos2dxでチートについて学べるアプリを作った
チートをしないとクリアできないゲームを作った
まずはどのような問題があったらいけないか(リスク)から、それを対策する
攻撃側はクライアントのデータよりもサーバーのデータを書き換えたい

DeNAの取り組むテストエンジニアリング¶

Test Engineers Meetup 3/7 メルカリでやる
Selenium実践入門かいてる人
SoftWare Engineer in Test (SWET)のグループリーダー
去年も説明したので興味ありゃスライド見りゃいいじゃん
SWETのミッションステートメント
ーソフトウェアテストを起点とした
1プロダクトサービスの品質向上
2エンジニアの開発生産性向上
事業Aサポートチーム：ざっくり深さ担当
テスト基盤チーム：ざっくり広い担当
深さとは、事業状況を踏まえた品質基準を決められる事
事業リスク、技術的リスク、だけでなく、事業部の品質的なコミットメントを引き出す
検証はQAにおまかせ、にはさせない
継続的な改善活動への推進
ー検証のフィードバック
ーメトリクス
ー開発プロセスの最適化
ー自動化による改善
広さとは、ライブラリや新技術、CircleCIの導入、STFのトライアル、一歩先のテストエンジニアリング
DeNAの特徴：どんどん新領域に進出、インターネット、サービスを改善していくこと
サービスの改善をささえる、事業の段階や状況に応じてスピード品質のバランスを取る
ちょうどいいを続けていくため、一貫した様々な仕組み：可視化、フィードバック
Wモデルでの開発サイクルをしている、早い段階のフィードバックが重要
基本設計：リスク分析、品質特性への落とし込み、テストアーキ
詳細設計：テスト対象分析、テスタビリティ
実装：テストコーチ、モデル検査、CI/CD推進
結合テスト：システムテスト自動化
システムテスト：非機能テスト準備
一貫したフィードバックと計測のパイプライン
品質をつくりこむうえで、可視化されている事、フィードバックまで自動化されている事が大事
一歩先のテストエンジニアリングへ取り組んでいる
ライブラリバージョンアップ検知サービス
とくにモバイルアプリで問題がおきる場合がおおい
放置しておくと負債がすぐ大きくなるのに、都度対応するには大変すぎる
CocoaPodsやGemやXcodeをチェックしてる
→うちならバージョンアップのプルリクまで作成してくれるといいっすね! composerだけでも
→TravisでScheduleビルドでできたりしないかなー
システム統合テストは大変、得にブラウザ/実機の自動操作
メンテナンスも大変、テストデータとかが古くなったり、変更による影響
webならクローラでやれるよねー
→sitemap.xmlとかあればやれる
APIなら仕様書があればいけるとか、swaggerとか
ハッピーパスのテストケース、デフォルトパラメータ、正常系テストケース、レスポンスマッチャ
→変化をウォッチするとかでも良いかも?
AIでテスト自動化とかできないかな?
今までのE2Eはすごい泥くさい、そこをAIでやりたい。(構想段階で気持ちオンリー)
テスト結果収集基盤を作ってて、将来機械学習できるようにしてる。