Archive for the ‘ソフトウェア’ Category.

ゲーム業界はオワコン

そろそろゲーム業界から卒業すべき時がきたでしょうか?

私が携わっていたのは、AppStoreセールスランキングで上位の有名アプリでしたので、負荷は半端ないものでした。
ところが今携わっている案件で納品されてきたプログラムは質が低すぎて、これで実績のあるゲーム会社が作ったの?と目を疑うレベルです。
モバゲーアプリの開発実績もある会社なので、このレベルの低さは理解できなかったのですが、どうやらモバゲーは想像以上にオワコンらしいです。

私がモバゲーアプリを開発したのは、モバゲーAPIがサードパーティに提供された時の初期参入アプリです。
API公開時に参入した数社だけが当時の地獄を経験したのでしょうかね?
分間50万アクセスとか当たり前のようにくるのが、ソーシャルゲームという戦場だったんですがねぇ?
どうも話を聞いていると、今はモバゲーもゴミみたいな作り方で、まったく問題なく動くようです。
memcached使いました!ドヤァみたいな程度で動くみたいです。
なので、質の低いサーバーサイドエンジニアが量産されてしまっているのはあるんだと思います。

スマホアプリもセールスランキングトップのアプリ以外は全然負荷も高くないみたいです。
どの程度の順位までが負荷が高いのかは分かりませんが、少なくとも100位以内に入ってないようなのはゴミみたいなプログラムで動くみたいです。
ゴミで良いのなら、ゲーム業界なんていても良い事ありませんよねぇ。

トランザクションを理解する

さて、昨日書いた補足説明をしたいと思います。

まずレイドボスの場合は、倒したかどうか?という判断が必要になります。
読んでいる数値が保証されていなければどうなるか?
通常は討伐報酬が発生しますが、報酬の2重付与が発生してしまいます。
悲しい事に、ここまで書かないと何が悪いの?と理解できない人間が多いのがゲーム業界のサーバーエンジニアです。

ですから、プランナーがサーバーエンジニアをただのweb屋レベルのペチパーと勘違いするのも仕方ないと思います。
本当は数が少ないだけで、最も知識が必要で高いレベルが要求されるのがサーバーエンジニアです。
アプリ側は人間が余っていますが、マトモなサーバーエンジニア・インフラエンジニアは数が少ないのでどこの会社も人材を求めている所でしょう。

で、次に減らしてから増やすという話も説明しないと理解できない人が大勢いるでしょう。
そもそもA処理が終わってB処理が終わらない。
このシチュエーションが起こるケースは
1.トランザクションを利用していない。
2.B処理が別の保存先(例えばキャッシュ)
という事が考えられます。

もう1つ考えられる最もアホな発想についてまずは潰しておきます。
3.トランザクション中にコミットして片方が切り捨てられるという発想です。
はい、WALとか知らないんだったら勉強しましょうね。
insert文やupdate文を実行した時にそのデータはどこにいくとお考えですか?
メモリ上を更新するだけです。
そしてコミット処理を受け付けた時にmysqlが何をしているか知っていますか?
REDO(トランザクション)ログをシーケンシャルに書き出してメモリ上のデータが仮で無くなるだけです。
(設定されていればbinlogも)
binlogがredoログだと思っている人が多いですが、binlogはbinlogです。
多分レプリケーションの関係で後から付けた仕組みなんじゃないですか?>binlog
ib_logfile0とib_logfile1というのがmysqlのトランザクションログです。
チェックポイントに到達するとログファイルを切り替えて、実際にディスクに書き込むのでそれまではオンメモリなんですよ。
ですのでmysqlのリカバリのメカニズムは、ディスクに書き込まれていないデータはトランザクションログから復旧を試みます。
コミットに途中で?失敗する=トランザクションログの書き込みに途中で失敗する=mysqlサーバーのディスク逝ってるレベル。
2行目のクエリ書き込みタイミングでディスク逝く確率はゼロじゃないけど、このパターンの障害はファイルも救い出せないレベルじゃねーの?って事。
仕組みを知らずにケース3を想像してた人は、せいぜい意地になって超低確率のレアケースを想定してなさいってこった。

次にケース1
トランザクションを利用していない。>アホか、氏ね。

次にケース2
片方だけ更新しちゃう>アホか、氏ね
キャッシュだったとしても、ロールバック出来る形で実装していないのは設計が間違ってるだけ
キャッシュだったとしたら、キャッシュを消せば次回はDBから読み込んでキャッシュ化する作りになってなかったらアホ
ロールバックするの仕組みを実装するのが面倒だったら、DBへのコミット失敗したらキャッシュ消せ
つまり減らして増やすじゃなくて、DBコミット→キャッシュコミットという順番なら正しい
キャッシュコミットに失敗する=キャッシュサーバーがフェイルオーバーするから、DBから読み直して動くので全く問題なし
問題があるなら設計に問題がある、消えて困るデータをキャッシュするな

唯一筋が通りそうなのは、キャッシュじゃなくて
ケース4.垂直分割とかDBが分かれているケース
XA-TRANSACTION使えアホと言いたい所だが、Transactionマネージャーを自作するのが面倒くさいので自力Commitループしてるパターン。
このパターンだったら片方だけコミットされるというのはあり得るから、最終的にはエラーログからデータは戻すんだけど
それまでの間の問題にならないように減らす→増やすの順番でコミットせーよ!ってのは有りかもしれませんね。

ペチパー酷過ぎ

ソシャゲーというかスマホアプリ
今のクラサバ型ネイティブアプリを支えているのは、サーバーエンジニアの一部のマトモな人間だとひしひしと感じる出来事があった。
これは久しぶりにソシャゲ系の記事も書いてみようかと思うに足る衝撃である。

基本的にゲーム系で育った人間はトランザクションを理解していない人間が多いみたいである。
同じプログラムが並行で動いたら、これじゃデータおかしくなりますよね?っていうのが理解出来ていない。
これは、ソシャゲの勉強会?の資料で減らして→増やすとか意味不明な事を書いて撒き散らしてる人達も同じなんだろうと思われる。
トランザクションを使ってないか?使い方を間違えてるから、このような意味不明な事を言うのだろう。
ゲーム業界の低レベルな人間だと、一見なるほどと思ってしまうような内容ですしね。

ここら辺は業務系で育った人間の方が優秀である。
数字が狂ったら業務に支障が出て始末書物の世界なので、並行動作への教育は十分にされている。
ゲーム系のスライド等を見ても一部のマトモな人間はちゃんとread lockについて言及していますし、こういった人間が支えているんですね。
気持ちは分かるんですけど、ゲーム業界の低レベルな人間がよくやってしまうのは
更新処理の部分だけでしかbeginTransactionとcommitを考えれない。
今読んでいるデータの値が動作中に保証されている必要があるのか?まで考えが及ばない人が多いようです。

簡単に例を上げるとレイドボスのHP
現在HPを読んでHPからダメージ減算という処理があったとします。
ほぼ同時に処理が動作した時に、現在HPが同じ値を読む事があるという当たり前の事を考えられないんですよねぇ。
Aさん:ボスHP:1000、攻撃100、残りHP900
Bさん:ボスHP:1000、攻撃200、残りHP800
現在読んだデータを信用できない作り方にするのであれば、
update文では、boss_hp = boss_hp – 100
のような更新をする事でカバー出来る事があります。
レイドボスの場合は読んだデータを信用するパターンじゃないと困るケースでしょうけど。

iWormが流行っているらしい

土曜日にbashの脆弱性について、macが一番セキュリティがやばい状態と書いた途端にコレですかw
ネットには腐れマカーのmac信者の痛々しい記事が数多くあるのでmacはウイルスソフトが要らないという都市伝説は信用してはいけません。
OS側に実装されているのは、WindowsのSecurity EssentialsやDeffenderと同じです。
それを信用しないのならばmacでも同様に専用のウイルスソフトが必要なのを認めているのと同じです。
appleの誘導もありセキュリティ意識が低いユーザー民度のmacは、今後も愉快犯のターゲットになっていくのは仕方がないんじゃないでしょうか?

bashの脆弱性がmacの危険性を露呈した?

今回のbashの脆弱性は、インパクトが大きいように扱われていますが実際は大した事はありません。
大変だったのはcgiを扱っているレン鯖屋さんくらいでしょう。
それくらいcgiなんて物は過去のテクノロジーで利用されていません。
(念のために書くとcgiだけが影響あると言っている訳ではありません)

さて一時期マスゴミがMicrosoft様をこきおろせば記事がウケるという時代がありましたよね。
Linuxは世界中の人がうんたら、Microsoftは一社だけで対応するから遅いだのw
例えばCentOS6なんてメインコミッタがやる気なくしただけでCentOS6のリリースがどれだけ遅れたかご存じでしょうか?
どこの誰かも知れない人間>有償サポートMicrosoftという扱いをしていた当時のマスゴミは本当にアホですね。

で、今回のbashの脆弱性で一番対応が遅れる上に一般人に影響がある?のは実はmacなんじゃないか?
私みたいにデスクトップ用途でLinuxを利用している人間は少数な上に、こういう人は知識があります。
(XPサポート終了により私のLubuntu設定ページへのアクセスは結構ありますし、素人さんも結構流れてる感はあります。)
しかしmacは、ミーハー気質のど素人が大勢利用している訳で、愉快犯がこの脆弱性を狙うならmacでしょう。

9/29にアップデートが公開されましたが、macユーザーはアップデートに対する危機意識は如何な物なのだろうか?
10/24 22:13現在、久しぶりにmac book airを起動させてみましたが、アップデートに関して何も表示されないんですが、大丈夫なんだろうか?
app store起動するとアップデートがあって、その中にセキュリティアップデートが含まれてるけど、これがbashのやつなのかよく分からんw

SQLインジェクション対策で祭りがあったらしい

今更ながら2013年末に何やら盛り上がってたらしいのを知りましたw

「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」
でググると関連するものが出てくるが、全く何を揉めてるのか分からなくて楽しかったです。

http://togetter.com/li/601462
異論を唱えてる誰かがいるらしくて、それがこの2人じゃないという構図なのでまったくもって意味不明なまとめです。
エスケープの知識はあって然るべきという当たり前の事を2人とも言ってるのに論点が噛み合ってないようで、これだけ読むと意味不明でした。

http://togetter.com/li/600908
次にこういうまとめにたどり着きました。
先程のまとめの題名だと、「プリペアードクエリが基本だけど」というタイトルだったので、そういう発言をしたのかと思っていましたが、このまとめではエスケープを使えと主張した事になってます。
一体大元の着火発言はどれだったんだ?と意味不明です。
多分全体の流れを分かってる人達は分かるんでしょうが、後から部外者が読むと話が噛み合ってないだけにしか見えませんから面白いですねw

http://archive.today/TGn8P
最後に辿り着いたのがこちらになります。
どうやらIPAの文書をディスったのが根底にあって、SQLインジェクションの話は全体から見ると枝葉の話題に過ぎないぽいですね。
なので2つ目のリンクの人みたいに感情的になって問答しているんだろうという結論に辿り着きました。

結論、まとめ(割愛具合)が悪いと後から部外者が見ると双方ともアホに見えるから可哀想。

モンストがパズドラを抜いたけど、パズドラ超えは初じゃないってばよ!

ブログ再構築時に該当記事は削除しましたが、以前に書いた通りパズドラ超えは既に達成されています!
以前から言っていたように、瞬間最大風速だとパズドラ超えは不可能ではないのです。
そして今回はLINE系ではなくモンストが達成したというだけの話ですね。

「モンスト」初のApp Store売り上げランキング1位に 王者パズドラを逆転
うーん、ITmediaにこんな普段からセールスランキングチェックをしていない人間が書いたような記事を書かれると困りますねぇ。

>アプリマーケティング分析のApp Annieによると、パズドラはこれまで約1年半にわたって1位を独占しており
これは、デイリーランキングの話でApp Annieのデイリーランキングは0時時点のランキングが利用されます。
私を含めて仕事柄ランキングを良く見ている人達には常識だと思うんですけどねぇ。
そして昨年パズドラ超えを果たした、LINEポコパンとLINEは、かなり衝撃的でした!
この記事を書いた人が既にパズドラ超えを達成されているのを知らなくて、モンストを取り上げたようにパズドラ超えというのは驚異的ですからね。
当時は2chでもそこそこ騒いでいましたし、今でもググるとブログに書かれている人がhitしたりしますね。

2013年8月1日14:00-16:00 LINEポコパンがパズドラ超えを達成!
20130801pokopang

2013年8月2日9:00-16:00 LINEがパズドラ超えを達成!
20130802line

同時間のパズドラのランキングをチェックして下さいね!
2位になってますから!
先ほど書いた通りデイリーは0時時点の順位しか分かりませんので、本当にパズドラ超えがあったかどうかは時間で見ないといけないんですよね。
今回は23時時点でも1位ですので、0時時点のデイリーランキングでもパズドラ超えを達成できそうですが、それは結果論です。
記事を書かれた時点ではLINEの達成したパズドラ超え時間を抜いてすらいなかったので、執筆者が単純に知らなかっただけなのは明白です。
まぁ時間単位ではっついてないと分からない部分はありますが、ポコパンと違ってLINEは始業時間から日中と毎日ランキングチェックしてる人なら気づいてましたからね。
私も最近は毎日のアウアリーランキングまでチェックしなくなってるので、2013/8以降に他のアプリが瞬間最大風速で抜いていたアプリがあっても知りません。
なのでこの記事を書いた人が悪いとは思いませんが、やはりちゃんと毎日ランキングを調べていないのがバレバレな人間が書いてるのは良くないとは思いますね。

phpフレームワークとの付き合い方

フレームワークを使うならメモリ消費について諦めなければいけない点かもしれません。

よくあるフレームワークで考えると、indexというメインコントローラがアクションクラスのインスタンスを作成します。
このメモリが解放されるタイミングは、どこになるでしょうか?
恐ろしい事に(ほぼ)全ての処理が終わってindexコントローラーからインスタンスが解放されるタイミングです。

なので、アクションクラスではprotectedやpublicのメンバ変数(プロパティ)はなるべく使用しない方が良いです。
インスタンスが解放される=メインコントローラーの最後までメモリ解放されません。

アクションメソッドの中でマスターデータなどを取得した場合もunsetしない限りはスコープから外れるまで解放されません。
スコープから外れる=アクション終了=(ほぼ)全ての処理が終わっている

オブジェクトを多用するのは、zend_class_entryに設計図が登録されるので、クラス数だけメモリを消費します。
クラスを一杯作成するのはメモリ消費には繋がります。
ですがstaticメソッドを持ったクラスを作るのは別に問題だとは思いません。
これはfunctionを作ってもfunctionが登録されるのと同じだからです。

どうせ数msで終わるのだから、頑張ってメモリ解放しなくても良いというアプローチこそ
lightweight languageに相応しい気がしますので、あまり神経質にならなくて良い気がします。
アクションクラスのメンバ変数に大きなマスターデータを持たせるとかは、やめた方が良いかもしれませんけども。

久しぶりに連日技術的なネタを投稿して充実していましたが、明日ソードアートオンラインのゲームが出るので若干更新ペースが落ちるかもしれませんw

php extensionのススメ3(メモリ消費)

同時アクセス数が多いという事はweb(ap)サーバーのメモリ消費に注意しなくてはいけません。
webサーバーレイヤーではnginxが有利だと言われる部分はアプリレイヤーでも考慮する必要があります。

phalconフレームワークとCakePHPで単純にHelloWorld的なプログラムを実行してみます。
テンプレートでmemory_get_usage()をechoするだけのプログラムです。

phalconフレームワークは400Kくらいです。
phalcon

cakephpは10倍の4Mくらいです。
cakephp

DB接続すらせずに、Actionも空っぽでテンプレートでecho memory_get_usage()しているだけのプログラムで10倍のメモリ消費となります。
phalconフレームワークは早いだけではなくメモリ消費という最重要項目に関しても優秀です。
これは、先日説明したphpのzvalを思い出して下さい。
c言語のネイティブレイヤーでスタック変数を定義するのと、phpレイヤーで変数を定義するのとではメモリ消費が違います。
同じ処理をするにしても、ネイティブ側で例えばint型(私のPCは32bitなので4バイト)で良い値があるとします。
phpレイヤーでしか定義出来ない場合は、まず$aというポインタ変数として(私のPCは32ビットなので)4バイト
ポインタの参照先の実態として、zval構造体+共用体のメモリを消費します。
ネイティブで済ませる部分が多ければ多いほど、zvalの呪縛から解放されメモリ消費を抑える事も出来ると言うことです。

Actionやテンンプレートが空っぽでこれなのですから、CakePHPをそのまま使ってしまうと1アクセス当たり平均10MBは覚悟しておいた方が良いかもしれません。
対象サーバーでの同時アクセス数を100に設定したと仮定すると軽く見て1GBは覚悟しておくべき数値かと思われます。
1000アクセスだとすると10GBですね。
ゲーム開発の場合はマスターデータをKVSから全件取得したりもしますので、多めに考えておいた方が良さげです。
あくまでアプリレイヤーのメモリ消費ですので、webサーバーは別途メモリを消費します。
そしてAPCにキャッシュさせたデータもメモリを消費します。
APCのコンパイルキャッシュもメモリを消費しますので、プログラムの本数分消費します。

その他サーバー監視プロセスやログ収集プロセスなど最低限動いているプロセスもメモリを消費します。
これから考えてもApacheとnginxの項でも書いた、C10Kという単位は普通に馬鹿かと言いたくなる単位なのは、ご理解いただけるかと思いますw

プロジェクトスケルトンの作成

プロジェクトの設定とかは全くしていませんが、とりあえず動きました。
これでチュートリアルに進めます。
phalcon