マネージドサービスを使って、キャンペーンページを切り出しました
こんにちは～
SHOWROOMエンジニアのシミズです。
TIFをはじめたくさんのイベントがあった8月も終わってしまいました。 寂しいですね。
いきなりですが、SHOWROOMのWEBアプリケーションはいわゆるモノリスな巨大な一枚岩なシステムとなってます。 配信機能、視聴機能、配信検索、イベント、アバター、トークルームなどの機能全てがほとんど１つのPerlで書かれたシステムで動いています。 5年以上の運用の中でリファクタリング(というかほぼ作り直した機能も...)などもしてきましたが、どうしても開発スピードに課題を感じるようになってきました。 特に、膨大な機能間が密結合になっており、思わぬところで影響があったりするので全体把握がとても困難です。
我々はこの5年間で生み出し続けてきた機能について、全く使われていない機能や、効果をあげていない機能などについて精査をしています。 それによって、一定の開発スピード低下は抑えられますが、スピード低下を抑えるのではなく、スピードをあげたいという思いがあります。
そこで、我々は改修頻度の高い部分について、SHOWROOMの既存システムから切り離して、軽快な開発ができる環境づくりにチャレンジしました。 このチャレンジではAWSのFargateとS3の静的ウェブサイトのホスティングを利用しています。
今回のターゲットはキャンペーンページです。
システム構成
基本的な方針として、キャンペーンページ(static-pages)はS3でホスティングします。 WEBサーバーはなく、ユーザー認証がないので全てのユーザーに同じ画面が表示されます。 キャンペーンページに関連するルームやイベントの情報についてはAPIリクエストで情報を取得してレンダリングします。 この時、従来のSHOWROOMサーバー(showroom-server)にリクエストをするようにすると、セキュリティ懸念と負荷懸念があったため、 ルームやイベントの情報を返す専用のサーバー(public-api-server)を新しく構築しました。
public-api-server
Goで書いたアプリケーションをコンテナにしてFargateで稼働させています。 コンテナを動かしたいだけで特別な要件もない時にはFargateはとても楽ができました。 また、SHOPROOMの機能ですでに利用実績があったのも選択理由です。
SHOWROOMの情報はSHOWROOMのサーバーにリクエストして取得するのですが、毎回リクエストをするとネットワークを経由するためレイテンシーが大きくなってしまいます。 これを避けるためにRedisで情報をキャッシュします。
そして、このサービスの受け口にはCDNを配置しています。 これはシステムの特性上、全てのユーザーに同じデータを返すサービスなので、キャッシュできることを前提に配置しています。 キャッシュ以外の恩恵を受けるためにTTLを0としてCDNを配置するサービスもありますが、本サービスはキャッシュをさせています。 これにより、リクエストを大きくオフロードさせることができ、必要なサーバーリソースを少なく維持しています。
S3+CDNで静的ページをホスティング
s3ホスティングはS3バケットを作って、CDNを配置するだけでいいのでとても簡単でした。 負荷の懸念からも解放され、レスポンス速度も格段に高速になりました。（静的ページを返すだけなので)
またホスティングするS3バケットは単一である必要がないため、S3バケットを分割することで編集権限の管理についてAWSの仕様を利用できるメリットもあります。
得られた恩恵
一番大きな恩恵は、本施策の目的でもありますが、 既存SHWOROOMアプリケーションから独立できたことです。
それぞれのページがそれぞれのニーズに合わせて技術選択をして自由に実装できるようになりました。 cssも軽量にすることができますし、javascriptに関してもvue.jsで実装するページやjQueryだけで実装するページもあります。
ルームの情報やイベント情報、配信中のライブ情報はpublic-api-serverを経由してshowroom-serverから取得します。 これができるようになったことで従来はSHOWROOMの情報を利用したページはshowroom-server上でレンダリングしなければいけなかったのが、showroom-serverの上になくてもできるようなりました。
キャンペーンページの開発担当者は、基本的にWEBサーバーの開発は不要でクライアントのシステム実装だけに集中でき、またそのクライアントでは開発するキャンペーンのみを扱うので、よりキャンペーンページの開発に集中できるようになります。
課題と今後の展望
複雑なキャンペーンページを実装しようとした時にいい感じのJSONを返してくれるWEBサーバーが欲しいなってなることがありました。 これをしようとした時にshowroom-serverやpublic-api-serverに実装すると、結局またそれらの仕様が膨らんでしまうし、 キャンペーンページの実装者もそれらのサーバーの仕様を把握しなければいけなくなるので課題に対して逆戻りしてしまいます。 現在はその問題についてAWS Lambdaを使えば解決できそうということで、本チャレンジを継続しております。
最後に
本投稿では最近のSHOWROOMのエンジニアってどんなことを思ってどんな仕事してるのかが少しだけでもわかればと思って投稿しました。 もちろん、これだけでなくて他にもいろいろなことにチャレンジしています。 他の投稿や下記エンジニア採用サイトも是非ご覧ください。
また少しでも興味をもっていただけましたら、お問い合わせいただくか、なにかのイベントでご一緒した時にお声かけください。
