Co-Edoブログ朝会になかなか出席できないです。。たるんでますね。

前回に引き続きシードスタートアップなお話です。今回はインフラ関連なんですが、個人的にAWS一択なので、AWS前提でシードスタートアップなインフラをどう作るかを書きたいと思います。

その前になぜAWS一択かというところについて。

AWSを選択する理由

1. スケールしやすい
2. マネージドサービスがバラエティに富んでいる
3. サポートが強い

1や2については言わずもがなというところで、詳しくは高山先生のschooを見ていただければと思います。

で、私が一番推したいのが3のサポートですね。イベントなども多いですし、困ったら色々教えてくれるので、シードスタートアップはエンジニアも少なく、専任の人もいないのでかなり不安になるとは思うんですが、AWSの方々はみなさん色々相談にのってくれるので安心感がありますね。

では、シードスタートアップなインフラ構成をこの前見つけたCacooのテンプレートで作ってみました。

シードスタートアップなインフラ構成

基本的には高山先生の基本構成にかなり近いんですが、schooのスタートアップ例はシリーズA以降が多く、初期のシードだともうちょっと変えたほうがいいかなと、若干私なりに少しカスタマイズしたのと、捕捉部分があるのでその辺りを説明しますね。

AZは分けない

ここは賛否両論はあるんですが、シードの状態だとAZを分けて管理する手間やELBの場合AZごとに等分にしか振り分けられないので、例えば同じサイズのEC2インスタンスがあったとしたら偶数個おかないといけないんですね。シードの場合お金を節約したいので、細かい調整が必要でEC2インスタンスを3つなど奇数個にしたいことが割とあるので、この辺り諸々踏まえるとAZが落ちるリスクを取ってもAZは分けないほうが何かと便利です。ただ、あくまでシードの場合ですからね。その後のフェーズはAZ分散も考慮したほうがいいとは思います。

※高山先生からクロスゾーンバランシングが有効になったのでAZ分けたほうがいいですよーとご指摘いただき、AZ分けるデメリットがあまりなくなったので、早い段階でAZ分けてもいいかなと思います。この辺りのデメリットへの対応スピードやサポートが身近であるところがやっぱりAWSのメリットかなとうまくオチをつけたつもりで・・

SESはそれでも便利

SESは国内キャリアメール配信に最適化されていないのがちょっと厳しいんですが、シードの場合ターゲットがアーリーアダプターなので、きっとgmail使ってるから大丈夫だよ的なノリで使うことにしています。というのもやっぱりメリットが大きいんですよね。一番はSPFやDKIMが簡単に設定出来て、もちろんRoute53をセットで使うのが前提なんですが。ボタンをポチポチ押すだけで確認込で数分(もしくは秒速！？)で設定出来ちゃいます。もう脳が退化しちゃいますよね。ちなみにメール送信はAPIやSMTPでも出来るんですが、もたつくこともあるので、個人的にはEC2のローカルにPostfixを設定して、リレーさせるようにしてますね。

CloudWatchはアラートに

サーバメトリクスを見るにはやっぱりNew Relicがいいんですが、アラート監視の部分ではちょっと弱いのでCloudWatchを使うのがいいかと思います。特にELB周りの監視はすごく重宝しますし、自分でアラートを設定したい場合もカスタムメトリクスを使ってアラートを設定出来るので便利ですね。ちなみにSNSで通知する場合通常メールで通知するようにするんですが、HTTPなどでも出来るので、中間にサーバーを挟んでHipchatに流したり、Twilioで電話で夜中起こしてもらうのもいいかもですね。

この構成で全てインスタンスサイズをsmallにした場合だいたい$200くらいでした。さくらVPSと比べると若干高いですが、最初からスケーラビリティを買えると思えば安いもんですよね。

その他色々語りたい部分もあるんですが、詳しくは高山先生のschooの授業をいっぱい見てください。

あと、AWS技術相談会など色々相談に乗ってくれるので、不明点は高山先生に聞いてもらえればと思います。