女性向けノベル型恋愛ゲーム　技術グループサブリーダー

女性向けノベル型恋愛ゲームで、技術グループサブリーダー。 既存運用案件／海外展開での各タイトルの開発チームのリーダーとインフラ整備を担当。 リリースしている既存案件での継続的な改善と効率的な他PF展開、及び海外（台湾、北米）への平行展開を行った。 使用言語：PHP,Javascript フレームワーク：FuelPHP,jQuery DB：MySQL,Redis, インフラ環境：IIJクラウド、AWS,IDCFデータセンター＆クラウド 1チーム構成：４〜５名（PHPエンジニア） 利用技術：Git,Jenkins,Zabbix,Monyog,NewRelic,Chef,Serf,GlasterFS,EMR(AWS),Fluentd,Elasticsearch シリーズ展開している自社タイトルIPのゲームシステムを利用し、他社IP（芸能系）のタイトルを作成した。非常に人気の高いIPかつ版元他社も含めプロモーションに力を入れていたので、初動が予測しづらかった為、インフラはAWSを選択。オートスケール環境を構築し、想定以上の負荷でも耐えられる状態でリリースを迎えた。スケールアウト時には、スポットインスタンスを利用するようにし、コストを押さえながらのスケールアウトを実現した。 サーバ構築時にはChefによるオーケストレーションを導入し、オートスケール時でもサーバ構成を維持したままのスケールアウトを可能とした。 以後、新規自社タイトルでもAWSの利用を推進、既存運用タイトルの複数を台湾、北米と展開した際にも、ユーザのレイテンシーを低く抑える為にAWSの他国リージョンを活用した。 異なる環境下で複数のタイトルを同時に運用していたが、タイトルを横断した分析が必要になったため、統合分析基盤を構築した。今まで各タイトル毎に行っていた集計処理をFluentd経由で各タイトルからログデータを収集し、EMRで集計処理を一斉に実行するように変更し、タイトル個々にに実装していた集計分析ツールを一元化した。 各タイトルで複数PF展開が進んだが、DBサーバも都度、複数台追加運用していた為、ホスティング費用の増加が問題になっていた。全てのPFのDBサーバを集約できる高パフォーマンスのサーバは当時クラウド環境にはなく、オンプレミスの高I／Oサーバへ移設を実施した。海外展開タイトルを除く全ての既存タイトルをクラウドからオンプレミスへ移設し、タイトルによっては最大１０台超のDBサーバを、それぞれ2台(Master/Slave)に集約した。 インフラ部門に専任のDBAが就任したので、DBAと連携し各タイトルで発生しているSlowQueryを集計分析し、開発チームにフィードバックする仕組みを構築した。閾値毎のSlowQuery発生数とDBAがピックアップしたQueryに対しての解決策の提案とディスカッションを行い、Query的な改修、プログラム的な改修、仕様的な改修どれを行うのかをトレードオフを考慮しながら選択し、改善サイクルを回していた。

女性向けノベル型恋愛ゲーム　開発・運用チームリーダー

シリーズ展開している女性向けノベル型恋愛ゲームの開発・運用チームのリーダー。 フューチャーフォンメインのGree,Ameba等SNS系のプラットフォームで新規開発を行い、それをスマートフォン向けiOS/Androidアプリでの横展開、というサイクルを数ヶ月スパンで実施していた。 2~3タイトルのサーバサイド開発チームのリーダーとインフラ整備を兼務で行った。 使用言語：PHP,Javascript フレームワーク：FuelPHP,jQuery DB：MySQL インフラ環境：IIJクラウド 1チーム構成：４〜５名（PHPエンジニア） 利用技術：Git,Jenkins,Zabbix,Monyog,NewRelic 運用フェーズでのイベント時の高負荷対策の為に、DB監視ツールのMonyogとSaaS型のパフォーマンス監視サービスのNewRelicを導入した。 例えば、アバター画像の生成のDiskI/Oがボトルネックだったケースでは、画像保存先を水平分割されたNASに変更するなどの対応で活用した。 それぞれのタイトルは３〜４プラットフォームに並行展開していたが、イベントの施策などはほぼ同じものを同時期に実施していたので、効率的な運用をする為に極力ソースは一元化していた。URL、DB接続先、認証ロジック、課金APIのシーケンスなどプラットフォーム毎に異なる部分だけがクラス内部で切り替えられるようフレームワークの上にラップしたクラスを用意し、そこで開発を行った。