ID:15422さん

自社マンガサービスと同じようなOEMサービスを作成しました。 開発経験： ・AWSでインフラ構築 ・EC2はAutoScaling ・サーバーサイドはPHP（Yii2） ・アプリとWebサービスの作成 詳細： 自社サービスのマンガアプリのOEMを作成しました。 当時はEC2を2台RDS（マルチAZ）１台インフラ構成でした。 EC2にはnginxが入っているAMIを使用し、PHPをインストールし、index.phpをYii2のメインに設定しました。 ・マンガのリストを表示するためのAPI ・巻のリストを表示するためのAPI ・巻をダウンロードするためのAPI ・CloudSearchを使ってヒットしたマンガを返却するAPI などをYii2で作成しました。 上記APIを使って、 Swiftを使ってiOSアプリの作成、 Javaを使ってAndroidアプリの作成をしました。 運用後しばらくして、Web版を作成することになりました。 Yii2で違うディレクトリにweb用のものを作成し、使用するModelやContorollerを分け、 専用の処理ができるようにしました。 このタイミングの自社サービスのWeb版では画像を４９分割にバラバラにしたものを並べ替える暗号化方法でしたが、 OEM版のWebサービスではバイナリでバラバラにし、暗号化をかけたものを描画時に復号化する処理でセキュリティの強化をはかりました。 Web版のサービスはAPIサーバーとは分けて、 EC2なども１から構築しました。 Autoscalingを採用して、常時２台で６０％以上のCPU使用率で増減するようにしました。

他のプロジェクトで培った能力すべてを駆使して、 初めてサーバーをAWSのAMIのAmazon Linux2AMIから作成。 nginx,PHPやgitなどをインストールしてサーバーを作成。 これが今の所一番楽しかった！ このプロジェクトは現在稼働中…

開発経験 ・OpenGL ・C++ ・iOS ・Android ・ゲーム開発 ・２D描画 ・３D描画 詳細： 初めて業務レベルでゲームアプリに携わりました。 始めは、UI実装などからプロジェクトのソースコードを把握していきました。 数ヶ月経ったあたりから、一人でこのゲームのアップデートを担当することになりました。 ３Dの釣りゲームだったのですが、描画が大変重く、その原因を取り除くことに苦労しました。 OpenGLをC++で記述されたコードを追って、重い処理を探しました。 原因は3Dポリゴンの頂点計算を全てfor文が回されていたことによるループ回数の肥大化でした。 配列から３つずつ取得してループ回数を必要な箇所で３分の１にしたことによって、 処理速度は向上しました。 同時期に犬の飼育ゲーム作成にも携わっておりました。

開発経験 ・DS ・パーティくん ・OpenGL ・C++ ・ゲーム開発 ・２D描画 ・３D描画 詳細： NITOROという開発機材を使って、ニンテンドーDS専用のゲームエンジンで ゲームを作成しました。 私が担当した箇所は、 パーティくんというエフェクトライブラリを使って、 パーティクルやエフェクトの実装をしました。 ３DSと同時リリースということもあり、 DSの描画の限界に挑戦したゲームとなっていまして、 メモリ不足などが多々発生しました。 ある程度はオブジェクト自体を軽くしたことで緩和できたのですが、 DSではエフェクト表示中は描画するオブジェクトをかなり削減するなどの見た目に違和感が出ないレベルの調整に大変苦労しました。 また、UI部分の実装も対応しました。 こちらは、パレットと言われる独自の色数やオブジェクト管理領域があり、 読み込める色数とオブジェクト数が決まっていたため、 こちらも表示されるオブジェクト数の管理に苦労しました。

開発経験 ・iOS ・Android ・PHP ・Ubuntu ・AWS ・MySQL ・Yii ・Yii2 詳細： 現在も携わっているプロジェクトとなります。 プロジェクト初期から関わっており、 最初はPHPでのAPI実装から携わりました。 AWS RDSのMySQLサーバーにDBを作成し、 RDSとEC2を接続してyiiでActiveRecordでデータを取得し、 APIを作成しました。 これまでC++をメインにやってきたので、 型が無いということに一番戸惑っていました。 APIを作成できるようになったら、 iOSの開発を引き継ぎました。 こちらは特に苦労なく実装を進めることができました。 漫画を読めるアプリを作成した後、 複数の漫画が読めるアプリを作成しました。 その後Androidのアプリ制作も引き継ぎました。 Androidでの開発も初めての業務レベルでの実装ではないので、 特に苦労することはなく実装できました。 前職（釣りゲームプロジェクト等）では、NDKでのC++がメインだったのですが、 SDKのJavaとの連携も記載していたので、Javaだけの実装も苦労なくできました。 苦労した点はサーバーの負荷対策です。 定期的にPush通知でユーザーが一気に集まるタイミングができてしまって、 APIでクエリ詰まりが起きてしまっていました。 ひとまずはRDSのIOPSのオプションを付与しました。 そこからは負荷対策を実装していくことになりました。 まずはPush通知の分散対策を実行しました。 秒間のアクセスを減らすことができたら良かったので、 数秒ずつずらすようにしました。 また、TOPページへのアクセスが高負荷となっていたので、 APIの簡素化をして不要なデータは返却しないようにし、データを圧縮しました。 サーバーが安定してしばらくすると、インフラ周りの作業を引き継ぎました。 この時点で、iOSの作業とAndroidの作業は別の方に引き継いでおります。 AWSのコンソールからインフラの管理の学習をしていき、 EC2やRDSの状況把握をCloudWatchなどで、確認できるようになりました。 ここからはコストの削減に努めます。 まずはRDSのIOPSのオプションを2,000つけていて、 RDSコストが大きくなっていたので、 そのオプションを消しました。 APIの負荷からのクエリ詰まりのためにつけていたオプションですが、 APIを新しいものにして、アプリ側にページャーを実装することによって、 Push通知をバラけさせたタイミングよりも負荷は大きく下っています。 そのためIOPSのオプションを消してもRDSは安定しました。 また、RDSの負荷とサービスのプロモーションのロードマップから、 向こう1年は急激に負荷が増えることが無いと判断したため、 リザーブドインスタンスの購入をしました。 この時点で大きくコストカットできておりますが、 APIのページャー実装なども伴って、 EC2への負荷もかなり下っていたので、 AMIを取得し、インスタンスタイプを下げました。 それまでの半分の性能のサーバーにしました。 3台稼働させていたサーバーも常時稼働を2台にし、 4台まで自動スケールするようにしました。 今までは別サーバーからのAWSコマンド実行による、 EC2のCronでのスケールだったのですが、 AWSのAutoscalingを使用しての自動スケールにしました。 また常時稼働の2台はリザーブドインスタンスとして、 前年度より半分のコストとなりました。 APIの負荷をさらに下げた部分の実装ですが、 yiiフレームワークだったAPIをYii2フレームワークへ変更しました。 これにともなってActiveRecordの生成はセッション内ならキャッシュされるようになったので、 外部結合などで別テーブルデータを持ってきても大きな負荷にならないようになりました。

開発経験 ・iOS ・Android ・PHP ・Ubuntu ・AWS ・MySQL ・Yii ・Yii2 詳細： このプロジェクトは漫画アプリ制作の後半部分とほぼ同時期に対応しております。 インフラ作業を引き継いだタイミングで それまであったWeb版の漫画サービスを引き継ぎました。 Webサービスの実装は初めてでしたが、 PHP自体はそれまでの経験で培ってきましたので、 大きな苦労はなく実装できました。 インフラを引き継ぐ前にも、 一部だけ実装を手伝うことがありました。 その時の実装内容はImageMagickを使って、 画像をアップロードするタイミングで、 ４２分割にバラバラにしてアップロードしていました。 しばらくはその漫画データのままサービスを続けていっておりましたが、 この漫画データは、Chromeのデベロッパーツールなどから 読み込んでいるリソースを取得すると、 漫画ページを４２分割した後バラバラに配置させた画像が取得できていました。 元の状態に戻すにはパズルのように合わせると元に戻せてしまいます。 PHPでImageMagickを使用してバラバラにしていたのですが、その際ビットマップ形式にして バラバラにした後jpegに戻していたので、 元のファイル容量よりもサイズが大きくなってしまっていました。 約１．５倍ほど大きくなっていたので、そこも小さくして転送量を減らすように考えました。 新しいやり方としてえらんだ実装が、 画像をバイナリで読み込んで一定バイト数ごとの配列にし、 その配列の順番を入れ替えることによって、 画像データではないバイナリを作成する方法でした。 これだとImageMagickを使うこともない上に、 配列を入れ替えるだけなので、 アップロード時の処理速度も向上させるだけでなく、 転送量も削減できたので、 ユーザーが使用している時の読み込んでいるメモリ量も減らすことにつながりました。 肝心のデータを取得すると、画像データでは無いものが取得できるので、 セキュリティとしても大きく向上しました。

開発経験 ・iOS ・Android ・PHP ・Ubuntu ・AWS ・MySQL ・Yii ・DynamoDB ・API Gateway 詳細： このプロジェクトは複数のゲームを一つのアプリの中に実装するゲームアプリを作成するものでした。 当初はiOSとAndroidを別々で作成する予定でした。 インフラ周りの作成は当初は別の方の作業でした。 iOSでの実装から始めることとなりました、 前職（魚や犬のプロジェクト）のようにOpenGLで実装することも考えましたが、 もっと楽に実装しようとしたため、 SpriteKitでの実装でやろうと決めました。 初めてのエンジンでしたが、基本がOpenGLと同じだったので楽に実装できました。 ゲーム選択画面などはUIViewで実装することになっていたので、 そこからSpriteKitを起動するなどでメモリ不足などの対応に苦労しましたが、 DSのプロジェクトに比べると管理する内容が少なかったので、 画像を小さくしたり、不要な初期化処理は省いたりでなんとかなりました。 １年なる少し前にUnityで作成して、Androidも同時にリリースし直すことになりました。 Unityは前職で勉強していたのと、独学もありましたので、 ゲーム部分などは簡単に実装し直せましたが、 UI部分の実装は苦労しました。 ゲームのUIと違って、ゲーム選択画面やリザルト画面などは UIViewのようなデザインが必要だったので、 画面サイズごとの実装に苦労しました。 UnityのCanvasを使っての実装になったのですが、 微妙にUIViewと違った描画になったりするので、 そこの調整は大変時間を要しました。

開発経験 ・OpenGL ・C++ ・iOS ・Android ・ゲーム開発 ・２D描画 ・３D描画 ・３Dアニメーション（FBXの再生） 釣りゲーム作成と同時期に犬の飼育ゲーム作成も携わっておりました。 こちらも最初はUIなどの２D部分から携わり、最終的には一人で仕様追加などのアップデート対応を行っておりました。 fbxでのモーション再生を初めて経験したのですが、自社ライブラリが一部バグっていて再生時の頂点移動処理などを修正しました。 基本的に釣りプロジェクトと平行して、 ２週間ぐらいで仕様を追加して、 アップデートをiOSとAndroidで対応していました。