Post on 07-Jan-2017
transcript
提督業も忙しい!サーバーサイド
JAZUG 6 周年総会
2016-09-03 Kurosawa1
目標と目次
• 目標
Azure 界隈のつながりを増やしたい。
Azure 使ってる人が身の回りに少なすぎてつらい。 (AWS ? GCP ?知らない子ですね )マサカリが飛んでこない。
• 目次
お前誰?
提督表も忙しい!とは
Azure 利用箇所
障害
宣伝
2
About me
黒澤
・ガジェクラ(スマホ、ノート PC )
・スマホアプリ( Xamarin )
・ Web アプリ、ツール
・ Twitter ( @kurosawa0626)
・ Blog (ぅゎょぅι゛ょっょぃ)
フリーランス業
・サーバーサイドエンジニア( PHP 、 HTML5 、 CSS3 、 JS )
・主にソシャゲの開発、運営、ツール作成
提督業
・大湊警備府左遷組(司令部レベル 119 、甲勲章 3 つ)
・嫁艦夕張(レベル 154 、運 69 )
・提督業も忙しい!サーバー担当
3
提督業も忙しい!
提督業も忙しい! (KanColleViewer) は、 DMM.com が配信しているブ
ラウザゲーム「艦隊これくしょん ~艦これ~」をより遊びやすくするた
めのツールです。
IE コンポーネント (WPF の WebBrowser コントロール ) 上で艦これ
を表示し、 Nekoxy (HTTP プロキシ ) で通信内容をキャプチャしていま
す。
艦これの動作は、 Internet Explorer 上で動作しているものと同じです。
当然ですが、通信内容の変更や、 DMM/ 艦これのサーバーに対する情報
の送信等 ( マクロ・チート行為 ) は一切行っていません。
引用元: grabacr.nétGitHub : Grabacr07/KanColleViewer
4
Azure 利用箇所
• 限定海域出撃制限札の表示
出撃出来る海域を制限して難易度を上げるためだけの理不尽なフラグがある。
そのフラグが艦娘に付いているかどうかを一覧で見るための機能。
• MapHP プラグイン
イベント海域をクリアするためにボスを何回も殴ってゲージを削る必要がある。
そのゲージを削り切るのに最低何回の出撃が必要か表示するプラグイン。
• データ送信プラグイン (develop)提督業も忙しい!が受け取ったデータをサーバーに投げるだけのプラグインを作成。
サーバー側で投げられたデータを元にマスクパラメータとなった制空値を解析する。
( 本来これがメインで開発が始まったが、サーバーがあるついでに上記 2 つが出来た。 )
5
現在の構成
6
現在の構成
7
限定海域出撃制限札の表示
こんなやつ
8
限定海域出撃制限札の表示
• Swf 分解して札の画像取得
色指定のためだけに使う
• イベント先行者から札の情報を調べる
RTA(Real Time Attack) 勢がニコ生で配信してたり、それを元に Wiki に情報が乗ってたりする。
• 管理ページから温かみのある手入力
Web Apps で入力したデータは Blob Storage へ保存される。
• 提督業も忙しい!から Blob Storage にアクセスして JSON データを取得
9
MapHP プラグイン
KanColleViewer で、攻略中マップの HP と最低必要撃破回数を一覧表示するプラグインです。
• イベント海域では、マップ HP とゲージ破壊に最低限必要なボス撃破回数を表示します
• 通常海域では、必要なボス撃破回数と現時点での残り撃破回数を表示します
• 「艦これ戦術データリンク」からデータ取得を行っています
GitHub : veigr/EventMapHpViewer
10
MapHP プラグイン
• イベント先行者からボス情報を調べる
難易度別 (丙乙甲 ) に削り編成と最終編成がある。
難易度によって (特に序盤の乙 ) は情報が出回ってなくてイベント中盤にならないと揃わなかったりする。
• 管理ページから手入力
Web Apps で入力したデータは Blob Storage へ保存される。
少し前までは半手動 ( 解析で足りない部分を手入力 ) だったが、
艦これ運営がイレギュラーなボス実装を繰り返すため現在は完全手入力。
• MapHP プラグインから Web Apps にアクセスして JSON データを取得。
実際にやってることはリクエス URL を見て Blob Storage の指定ファイルにリダイレクト。 (後述 )
11
データ送信プラグイン (develop)
艦これサーバーから送られた JSON データをデータ解析用のサーバーに送信するだけのプラグインを作成。
プラグイン自体の開発は完了しているがサーバー側の実装が終わっていない。
• 解析の実装
実装が間に合ってません。
全面的に自分がわるいです。
• 負荷対策
MapHP プラグインで 1 回障害起こしたので…
データ送信プラグインを一般公開すると同じことが起きる。
• Storage の容量問題
お金に直結する話
12
障害
MapHP プラグインで初めてサーバーから情報を取得する機能を付けた際に、プラグイン側の実装に問題があっ
て DDoS のようなアクセスになり、サーバー側も実装が手抜き過ぎて最終的に死んだ。 (詳しくはブログ参照)
13
負荷対策
MapHP プラグインの時は最終的に出来上がってるデータにリダイレクトすることで解決したがデータ送信プラ
グインはそうも行かないので悩み中。
参考計測値 ( イベント期間中の 8月 12日~31日に提督業も忙しい!を利用しているユーザーに限る )
• 自分 1 人がサーバーに送った件数
約 10,000件 ( 削除済みデータ除く )
• MapHP プラグインからのピーク時アクセス
約 1,000件 / 分
• MapHP プラグインからの総アクセス回数
約 6,200,000 回
14
容量問題
• 解析に必要なデータの中で比較的データが大きく頻繁に送信されるのが母港アクセス時で約 100KB
• 現状比較的アクティブな開発 3 人がイベント期間中に送信して増えたデータは約 600MB
• 前述の通り提督業も忙しい!のアクティブユーザーは約 42,000 人いる
• プラグインを公開した場合に最大で約 14,000倍の 8.4TB のデータ増加
プラグインなので全員が導入することはとてもじゃないが考えられないので実際はもっと少ない。
開発 3 人の平均よりアクティブ層が増えるか減るかは不明なのでそこは予測しにくい。
仮に 10% のユーザーが導入したとしても 840GB 増えることになる。
• データが増えると請求額も増える
やってない対策がまだあるので実際はもっと増加量は減るはずだが、延命にすぎないのでどうにかしたい。
15
そもそもなんで Azure ?
• AWS と CGP は少し触ってみたけどインフラ寄りで分かりにくかった。
やりたいことはコーディングであってインフラではない。
• Azure はやりたいことがある程度簡単に出来た。
サイト構築、 Git サービスからのデプロイ、オートスケール、グラフィカルな利用状況の表示、 etcデプロイメントスロットの存在は後から知ったけど最高!
• オートスケールの際、インスタンス別にストレージを気にしなくて良い。
端的に言って最高!
• MSCC で貰った BizSpark に Azure 利用権 15,500円 /月が付いてた。
試算したら十分だったし実際に毎月 7000~8000円で今は済んでいる。
16
利用額
• App Service \5,940東日本リージョン、 S1 Standard719時間
• ブロック Blob Storage \244東日本リージョン、 Basic 、ローカル冗長
30.7GB 、 4,158万トランザクション
• Standard Schedule \1,426東日本リージョン、 1ユニット
• データ転送 \359受信 2.03GB 、送信 25.5GB
合計 \7,969
Visual Studio Enterprise with MSDN サブスクライバー (BizSpark)4月 26日~5月 25日のデータ(春イベント 5月 3日~6月 1日)
17
問題点
• MySQL がない MySQL単体のサービスがない
VM に MySQL を用意出来るが別途料金が高くかかる上に、 IaaS なため作業コストが高くつく。
サードパティ (ClearDB) もあるが性能はお世辞にも高くないし色々問題を確認している。
MySQL in WebApps はローカルからしかアクセス出来ない。
( 少しずつ進んでる感じはあるので期待 )
• Microsoft が命名下手すぎのせいでググリビリティ、 Bing リビリティが低すぎる
Web Apps もあれだけど、以前の Web Sites はもっとやばかった
SQL Database とかもっとヒット率やばい
• 新ポータルの UX がつらい
• Azure SDK for PHP がつらい
• Azure App Service の正確な料金が料金表から分からない
18
第 26 回 devcussion9月 25日 13~20時株式会社アニメイトラボ
devcussion-slack.azurewebsites.net
黒澤 雪猫devcussion
devcussion.connpass.com