ブログ

全国100万人の刺身マニアのみなさんこんにちは。

前回の、(続)スライド公開用のアプリケーションを作っている話の続きです。

粛々と色んな機能を追加したり寿司スライドをUpして（・∀・）ﾆﾔﾆﾔしたりして楽しんでいるのですが、何人かの知り合いから自分の環境で動かす簡単な方法を要求されたので、AWS上で簡単に動作させられるようにCloudFormationのテンプレートを作ったので晒しておきます。

Cloud Formation Template

利用上の注意としては、

• AWSの東京リージョンだけしか動きません(面倒なので)
• 動作させると新たにVPC、サブネット4つ、IAMロール、S3のバケット2つ、SQSのキュー1つ、そしてt2.largeのインスタンスを1台起動します。その分お金がかかります
• インスタンス起動時にChef Soloを使って自動で環境設定を行ないます。ChefDKを始め、それなりに大きいファイルのダウンロードがあるので、完了までに15分くらいかかります
• 構築が完了したらインスタンスタイプを小さなものに変えるのがお勧めです
• 環境を削除したいときは、CloudFormationの画面でスタックごと削除してください。ただしS3のバケットは消さないようにしてある(ファイルが無くなるとマズイ)ので手で削除してください

なお、アプリ本体のレポジトリはこちらです。

アーキテクチャ

ここから先はアーキテクチャを説明していきましょう。

以下の図はCloudFormationを使って作れる最小構成になります。1台のインスタンスにWebもDBもWorkerも同居しているので可用性も何もありません。板前さん1人で営業しているお寿司屋さんと同じです。

上記の図はスライドアップロードの際の流れですが、言葉にすると以下のようになります。

• まずユーザーがアップロードのフォームをWebサーバに要求する
• Webサーバは、POST先がAmazon S3になっているフォームを応答する。この際フォームの中には有効期限やトークン等を埋め込んでいる
• ユーザーがファイルをアップロードする
• アップロードが完了した際に、Amazon S3では指定したURLにリダイレクトしたり、ステータスコード201を返すことができる
• リダイレクトした先のアプリでSQSにパワーポイント等のファイルを変換するジョブを登録し、そこまで終わったらクライアントに応答を返す

ここまでできたら裏でパワーポイント等の変換処理が走ります。

• ここではSQSのキューに変換ジョブがあるかどうかをインスタンスの中で動かしているデーモンがポーリングし続けます
• 変換ジョブがあった場合は、ユーザーアップロード用のS3のバケットから該当ファイルをダウンロードして色々変換処理をします
• 変換が終わったらワーカー自身が変換後のファイルを保存するバケットにファイルをアップロードします。なお変換後のファイルは再作成が可能なのでS3の低冗長化オプションを使って料金を下げる工夫をしています

ここまで来たらスライドが表示できるようになります。

• アプリケーション本体はWebサーバにありますが、スライド表示に必要な変換ファイルは全てS3にあるので、そちらに直接リンクすることでWebサーバの負荷を減らします

可用性や耐久性を上げる

ここまで見てきた構成はCloudFormationで作った一番単純な構成でしたが、当然可用性や耐久性などに問題があります。

一番シンプルな対応としては以下のような構成に変更します。いわずもがなですね。

• Webサーバの中にあったDBは追い出してRDSを利用することにして、マルチAZ構成にする
• Webサーバ自体を冗長化して、手前にELBを置く
• S3やSQSは特に何も考える必要はなし

そして最後は大規模向けの構成です。万が一とてつもなくたくさんのスライドがアップされ続けたりとてつもないアクセスが来る場合は以下のように変更します。

• Auto Scalingを利用してWebサーバの台数を伸縮自在にする
• ついでに変換用のワーカーを分離してこれもAuto Scalingするようにする
• スライド表示に必要な変換後ファイルの配信にCloudFrontを使う

なお、お約束ですが、この記事は私の個人的な見解であり、所属会社とは一切関係ございません。