BoomAppGamesのゲーム攻略Wikiシステムの紹介

技術開発部の武藤です。

弊社の運営しているサービスの一つに,BoomAppGamesというゲーム情報ポータルサイトがあります。
その一環として,ゲーム攻略Wikiを昨年より多数運営しています。上記URLのページ上部にある「攻略中のゲームWiki」にリンクが貼られているものです。

- FGO攻略Wiki - Boom App Games
- ドールズオーダー(ドルオダ)攻略Wiki - Boom App Games
- デジモンリアライズ(デジライズ)攻略Wiki - Boom App Games

以前から度々twitter等で話題になる,集合知によらない,新しいタイプのゲーム攻略Wikiサービスですね。

弊社では旧来より,ゲームやそれ以外でも自由に誰でもwikiを作成し運営できるサービス「Seesaa Wiki」も運営していますので,よければこちらもご利用ください。

今回はこのゲーム攻略wikiの技術てきなことについて軽く書きます。


*

インフラは全てAWS上に構築しました。
draw.ioにて雑な絵を描いたので以下に示します。
Copy of boomappwiki.png
サーバーアプリケーションはEC2上のdockerコンテナで動いています。EC2内にnginxが立っており,各アプリケーションにつながっています。アプリケーションはPerlで書かれており,PSGI/Plack,Starletを使用しています。

メインとなるwikiのページ用のアプリケーションとは別で,ユーザーのアカウントをまわりのページやAPIを担当するコンテナが分けられています。
それぞれ負荷の大きさが異なることが予想されているので,将来的に分離し,EC2からECSにし,スケーリングしやすくすることを前提とした設計です。

DBはMongoDBを使っています。AWS公式でマネージドサービスが無いので,EC2上で作っています。
mongoはReplica setを組んでおくと突然死しても自動で切り替わってくれるので便利ですね。
なお何度か実験したのですが,primary交代の際にアプリケーションを見ていると10秒ちょっとダウンタイムが発生することがわかりました。ミッションクリティカルなモノには採用できませんね。

KVSはmemcachedを使っています。本当にキャッシュにしか使わず,シンプルな場合は,メモリ効率の良いmemcacheのほうがふさわしいかな,と。
ElastiCacheを使うと,本当にマネージドは楽で良いなあというお気持ちになりました。

画像はS3に保管されます。
高解像度の画像が保管されるのですが,貼り付けられている箇所によって適切なサイズに圧縮されるように,API Gateway+Lambdaを用いてリサイズする仕組みを作りました。サイズをURLパラメータに入れており,パラメータの内容別にCloudFrontでキャッシュ(Behaviorの「Query String Forwarding and Caching」をホワイトリスト制に)しているため,次回以降の閲覧では高速に配信しています。

wikiのトップページや記事ページもCloudFrontでキャッシュしているのですが,記事更新の度に該当URLのキャッシュをinvalidationし,最新の内容が出るようにしました。また,記事下のコメント欄等は別途APIで取得するようにしこれも最新のものが出るようにしています。

このサービスを作っているときに,ちょうどdev.toや日経電子版とかがバズっていて,よし高速化やっていくぞという気持ちが発生して,そこそこ速く見れるようになりました。
Cache-Controlも適切に設定し,gulpでJSとCSSを一つに圧縮したりもしました。
CDNでのキャッシュを効かせにくいページでもそこそこ速くレスポンス返せるように,アプリケーション内でmemcachedでのキャッシュを多用しDBへのアクセスを大幅に減らす等のチューニングも行いました。

GoogleのPageSpeed Insightsにかけてみると,以下のようなスコアになりました(2018/07/27現在)。
Screenshot from 2018-07-27 12-26-03.png
速度は早いらしいですが,まだまだ最適化が足りないようです。
他社の競合サービスさんに追いつけ追い越せの気持ちで,頑張っていこうと思います。


*


弊社ではAWSでのインフラ構築やWebフロントエンド&サーバーサイドプログラミングに興味のあるエンジニアを募集しています!
募集中の職種ページを是非ご覧ください。

この記事へのコメント