エイプリルフールの裏側

2015年5月1日金曜日 Kouta Mikawa

皆さんこんにちは。GW楽しみですね!Mikawaです。
ギリギリ4月(書いているのは4/30)なので、今回は弊社エイプリルフール企画に関しての話です。

エイプリルフール企画の画像


4月1日はRooteという弊社ポータルサイトでエイプリルフール企画を展開していました。
3年目となるエイプリルフール企画ですが、昨年のRPG企画が大変好評だったこともあり今年の企画はRPG強化版(2?)ということになりました。
当社比2倍!のネタが詰まったこの企画、皆様お楽しみ頂けたでしょうか?

さて、ここでは私が担当した箇所の技術的側面をご紹介したいと思います。
私が担当したのはバックエンドの一部となる


の2点です。
駅すぱあとWebサービスはAWSを利用して提供しており、負荷対策もバッチリ、とはいえ業務等で利用されているお客様に万が一にも影響を与えるわけにはいかないので1日限りの専用環境を用意しました。
こちらは全く同じ構成でピークのアクセスも難なく捌き、サービスの耐久性を改めて証明してくれました。
同じ環境を別に用意したり、キャンペーンの対応で一時的に多くのキャパシティが必要となった時などは、やはりクラウドだと楽ですね。

もう1点の画像共有はプログラミング含めての作業です。
負荷には耐えてもらわないと困るけどあまりお金は掛けられないということで今回考えた構成はこちら。


画像共有のための構成

EC2は計算が必要な箇所のみに利用し、それ以外はマネージドなサービスに任せて楽をしようという構成ですね。
今回はパラメータからの画像生成のみEC2で行い、画像自体のホスティングはS3で行うという感じです。この構成ですと、EC2を使う頻度はそれほど高くないことに加え、画像を含んだツイート等で画像への参照が増加してもS3が勝手に捌いてくれるということになり、負荷を気にすることが無くなります。
また、全体の構成要素をシンプルにし、インスタンスを並べるだけでスケールするようになっていますので、画像生成自体に負荷が集中しても捌くことが可能です。
プログラミングだけでなく環境まで通しで考えて構築することで、より良い結果が出せるのはAWSの良い所ですね。

如何でしたでしょうか?外から見ると楽しいエイプリルフールですが、中のエンジニアも失敗しても良い(良いわけないんですがリスクは少ない)環境で色々なチャレンジが出来て楽しいのがエイプリルフールですよね。
因みに今回の開発作業は3月末に実施した開発合宿で行いました。
エイプリルフール企画の為の開発合宿とか良いかもしれませんね。

それではまた次回、新しいネタでお会いしましょう!

過去の記事
開発合宿をやってみた!
年忘れLT大会レポート!
JAWS-UG中央線支部のキセキ
社内同好会活動もあります!
re:Inventでささやかだけれど役に立つかもしれないこと
JAWS FESTA Tohoku 2014に参加してきました!
CloudWatchのログ蓄積とモニタリングを使ってみる(その3 完結編)
CloudWatchのログ蓄積とモニタリングを使ってみる(その2)