今週末の金曜日、3月15日に「JAWS DAYS 2013」のパネルディスカッションのパネラーとして呼ばれておりましてー。 風呂グラマーのmasuidriveさんとTreasure Dataの太田さんとお話をするらしく多少ビビってる僕です。
実はこのAmazon Web Serviceユーザーにおける祭典「JAWS DAYS」のイベントに呼ばれた前日。 ちょうどボケてを某さくらVPSからEC2含むAWSへせっせと移行していましてー。 ま、つまりは「AWSでこれからバリバリ運用始めるぜ！」ってタイミングでのお呼ばれでしたw
イベント自体はおもろい事話せればいいなーとは思いつつ、AWSへ移行して、もしくはAWSへの準備の段階で得たTipsを箇条書きでまとめてみます。ちなみに、その移行以前からS3とCloudFrontに限っては画像ストレージ、配信というユースケースで利用していました。その関係あってか、Amazonの営業と技術の方と数回の打ち合わせをしてからのー「ほぼ全リソースをAWSへ移行」となりました。使っているAWSサービスは以下となります。
- S3
- CloudFront
- EC2
- RDS
- ELB
- CloudWatch
- Route53
- SES
では以下にパラパラとTips的なことを公開できる範囲で書いていきます。
- Sorry Pageは出せないけどLoad BalancerはELBに任せよう（追記: Sorry PageはRoute53と組み合わせると出来そうだってことが分かったばかりでやってない）
- Webサイト、Web APIなどサービスドメインごとにELBは分けた方がいい、耐障害性が上がる
- EC2それぞれにnginx＋Starman/Starlet（Perlのアプリケーションサーバ）という構成はアリ
- ELBがL4スイッチ、nginxがL7スイッチという感覚
- 転送量について、S3とCloudFrontの中間キャッシュという技があるが、当然CloudFrontとクライアント間における解決策ではない
- むしろクライアント側でキャッシュすべき
- CloudFrontには10TB/月の転送量を約束するReserved Capacityという割引制度がある
- Reserved Instanceに限らず、AWSには割引の制度が色々あるので使用料が大きい場合は相談した方がいいかも
- AMIはサーバミドルウェア、アプリ、レポジトリが入った状態で固めるのがオススメ
- Chefとか使えばそんなことないかも、だけど、俺は今の所AMIで管理している（デメリットもある）
- AutoScalingは無し、手動でやろう。そういうユーザも多い
- それぞれの操作はWebコンソールから。あえてコマンドを覚える必要はないと思う
- ec2ssh はホスト名コピペとかしなくていいからオススメ
- RDSではmysqlテーブルにslow query log相当の物が入ってる
- CloudWatchは2週間しかデータを保持しないから、他にも監視システムを入れるのをオススメされた
- 元々使ってるCloudForecast/GrowthForecastとか通知システムとかをそのまま利用
- AMIはインスタンスサイズが違ってもOK、リージョンまたぐとダメ
- EC2はMedium使うよりSmallインスタンスをたくさん使った方がCPUリソースを使えるケースがある
- 性能表に書いてある「ECU」ってのは非常に性能の低いCPUと見なせる
- なのでm1.largeではなく、ハイCPUインスタンスのc1.mediumをメインで利用している
- EC2からメール送信すると諸々問題あるのでSES経由で配信。APIを叩くのではなくSMTPサーバとして利用
- サポートに入ると全体の1割増し、電話24時間サポートが付く、困ったときに入ればよいかと
- Reserved Instanceは購入の瞬間にクレジットカード会社に請求が発生、通常に買い物をするのと同じ
- なんだかんだ言って、当初考えていた料金の1.5倍くらいに請求額がいってしまったので怖いw
- クレジットカードの限度額等の確認、なるべく法人で専用のカードが良い、クラウド破産に注意
AWSを使っての全体的な感想としては、すんなりとインフラが揃ったって感じで、後はアプリのつくりとか運用のテクニック、つまり自分の腕次第だなーってものです。大昔といっても3年くらい前にEC2は触ってたのですが、エラい色んなサービスが出ててビックリしましたねー。AWSコンソールでほぼなんでも出来ちゃうのも便利です。
ってことで箇条書きでAWSにおける僕なりのTipsや伺った話をまとめてみました。興味のある方は3月15日（金）の「JAWS DAYS 2013」にお越し下され！