有利というわけではないが、Amazonで仕様を把握しているので回答は得られやすい。Linuxを利用しました。感想ここもEC2を使う上で悩むポイントでした。AMI」で検索すると、AMIをOSイメージから作成する情報が多くひっかかり、逆に公開されているこのAMIを使うと良いといった情報があまり無かったので、実はOSイメージからAMIを作成してそれをラウンチするのが一般的なのかと思っていました。個人的にはrightscaleのAMIを利用していて、それで困ったことは無いのですが、やはり同じような使い方をしている人が多いということで安心しました。本稼働で利用しているという意見も聞けたので今後は利用してみようと思います。Deviceの選択です。storeとEBSの2種類が選択でき、それぞれ特徴があります。Deviceでもデータ領域にEBSをマウントする方法は、前者になります。会場からの回答ほとんどの人がEBS。storeだったものをEBSへ移行している。DeviceにEBSが利用選択出来なかったからでは。それで困ったという意見はありませんでした。Rootとして利用したいと思っていました。速度的に不利という情報もあったので、実際のところどうなのかと思っていたのですが、とくに支障は感じないということだったので良かったです。Deviceに選んで良さそうですね。Snapshot質問EBSの特徴でもあるスナップショットですが、簡単にボリューム全体のバックアップが取れるという優れものです。日々のバックアップとして利用しているのですが、実際のところ困ったこととかありませんか?例えばスナップショットでバックアップを取っていたが、いざリストアしようとしたらデータが不完全で困った、など。困ったという意見はナシ。スナップショットはS3に保存される。S3の耐久性はイレブンナイン(99.999999999%)なので、まず大丈夫。自前でバックアップストレージ用意するよりはるかに安全ですね。ファイルシステムの整合性は担保されていないので、これは自分でフォローする。書き込みロックする、DBはダンプする、など。書き込みが頻繁で無いなら、世代数を多めに取るという考えもあり。感想EBSのスナップショットは簡単にバックアップが取れるのでかなり便利なのですが、あまりに簡単過ぎて、根拠はないのですが若干不安があったりもしました。いった心配は不要でしたので、安心して利用できますね。やってみて逆質問という形式でやってみたのですが、多く方々から様々な意見を頂いて、とても勉強になりました。聞きたい内容はあるので、また次回以降でやってみたいと思います。Shinbara雑感こんなにAWSについて聞いたり話したりしたのは初めてでした:D他の方の発表ももちろんですし、懇親会でも(ここでは書けない)色々なお話を聞くことができて楽しかったです。「生の声」が聞けるのは勉強会の醍醐味ですね。進化が速いAWSだけに最新情報を共有できるこういった場は貴重です。懇親会でJAWSの方々から「コアメンバーになる?」と声をかけて頂いたので、コアメンバーとしてお手伝いさせて頂くことになりました。具体的に何をやるのかはまだ分かっていませんが、コミュニティ活動に関わって行ければと思います。日本国内のパブリッククラウドをざくっと集めてみました。クラウドがすっかり盛り上がってきました。Engine、Azureの海外勢ですが、日本国内でもパブリッククラウドが立ち上がってきています。2010/07現在で、どういったパブリッククラウドが国内にあるかをざっと並べてみました。「クラウド」を謳っているサービスは多数あるのですが、ここでは以下に限定しました。月額課金サーバ構成変更のリードタイムが?まだ少ない。EC2のように自由にリソースを変更できるクラウドを想像すると国内はまだまだ少ないですね。リストアップする前はもっとあると思っていたので、上手く見つけられていないのかもしれません。(教えて下さい!)個人だとユニットホスティングしか選択肢が無いのが何とも厳しいですね。EC2が国内に拠点を持つという話も出ているので、国内でも良いパブリッククラウドサービスが増えると良いですね。4分37秒とあるイベントで使うWebシステムでEC2を使ってたところ、Amazonからメール送信制限に関する通知が来たという話です。このイベントでは、短時間で多くのリクエストを捌かないといけないので、あらかじめWebサーバを何台か立てて準備していました。想定を超える負荷に備えて、増設用AMIも作成して、すぐに増設できる体制にしていました。増設のリハーサルもやりました。イベントが始まります。アクセスがボチボチ来始めました。リソースにはまだまだ余裕があるので順調に捌いてくれています。無難な立ち上がりだなと、ひと安心したところにメールが一通。+0000......うん?メールの送信制限?何これ?たしかにメール送信は行っていますが、1hで数十通程度です。一気に送るというよりバラバラと送信しています。この程度で制限がくるとは思わなかったのですが、イベント中に送信を止められるとシャレにならないので、すぐにメールに記載されたフォームからメール送信制限解除申請を送りました。Services本文の内容でググってみると同じようなメールが来た人は何人か見つかったのですが、解決したという内容は見あたりませんでした。blockされて、仕方なく外部のメールサーバに別ポートで接続してメールを送信している人もいました。その時点では送信はできていたので、イベントが終わるまではとにかく持ってくれという心境でした。何とか回避策を制限解除申請をしたものの、ぼーと待っていても仕方が無いので取れる策をということであれこれやってみました。送られてきたメールにはインスタンスIDとIPが記載されていたので、別インスタンスとIPなら回避できるかもと思い、作成しておいたAMIから新しいインスタンスを起動しました。IPで別IPを発行しました。これはもともと高負荷時にスケールアウトすることを想定していたのですんなりと準備できました。ここでふと、もしかするとアカウントを停止させられるかも、という考えが頭をよぎりました。なると何台増設していても意味がありません。実際にそうなるかは分かりませんが、とにかく止められないので、新たなアカウントを発行することにしました。登録をこなして、スケールアウト用AMIの共有設定を行い、なんとかLB+Web+DBの構成を構築しました。DNSのTTLは短めにしておいたので、もしアカウントを停止された時はDNSを書き換えて別アカウントの構成にアクセスを向けます。この間もサービスとしては問題無く稼働していました。AmazonからメールがあれこれやっているとAmazonからメールが来ました。内容は「申請を受け付けた」「2営業日以内に回答するよ」といったもの。2営業日以内って!とか思いつつ、とにかく回避策をひたすら準備。サーバログ(主にmaillog)と睨めっこしながらイベントが無事終わるのを待ちます。inboundもoutboundも変なエラーは無く順調に稼働しています。自分でもサイトにアクセスして試してみますが問題ありません。乗り切った!結局、blockされることなく無事にイベントは乗り切ることができました。Amazonからメールが無難にイベントが終わって、ひと息ついていた頃に再びAmazonからメールが来ました。内容は「制限を解除した」とのこと。本文には申請したインスタンス、IPに対する制限を解除しただけなく、アカウントに紐付く全てのインスタンス、IPに対する制限を解除した、と書かれていました。対応は2営業日以内と書かれていたのですが、申請から数時間で対応してもらえたのは驚きでした。IPで割り振ったIPだけは残しておくことにします。EC2からメールを送る際は念のため申請をイベント中に来たAmazonからのNotificationには本当に焦りました。それほど多くのメールを送ったわけではなく、どういった基準でこの通知が来るかは分かりません。イベント前のテストでは問題無かったので、閾値は低いものの一定時間中に一定数を外部に送信すると通知される仕組みなのかもしれません。ここぞの時にblockされるとシャレにならないので、EC2から数多くのメール配信を行うなら、あらかじめ制限解除申請をするなり、別環境を用意するなり準備をしておいた方が良いでしょうね。