AWSで気になること4つを聞いてきた – 第1回 JAWS Osaka勉強会

第1回 JAWS(Japan AWS User Group) Osaka勉強会に行ってきました。

大阪では貴重なクラウド系の勉強会、しかもAWSの方が来られる、さらにちょうどAWSを使える案件が出てきたタイミング（というか提案したのですが:D）ということで、参加してきました。

おそらく他の参加される方は「はじめまして」の人ばかりですし、せっかくの機会なので LT もやってきました。

ちなみに人見知りしたり、自己紹介が苦手だったりする人は発表してしまうのが良いですよ。発表の上手下手は関係無く、発表した人は印象に残りやすいです。数分でも自分の話を参加者全員が聞いて貰えるってなかなか無いですからね。
@see 勉強会を楽しむなら発表しよう！

AWSで聞きたいあれこれ

「AWSで聞きたいあれこれ」というタイトルでLTしてきました。

せっかくAWSエバンジェリスト、さらに識者の方達が集まる場なわけですから、日頃AWSを使っていてふと気になる疑問、「自分はこうしているんだけど、他の人はどうやっているのかなー」という質問を逆に聞いてしまおうと思い、通常の発表とは逆にみなさんに質問を投げかけるという内容にしました。

本当は山ほど聞きたいことがあったのですが、とりあえずという事で基本的な 4 つについて聞いてきました。

1. Region

質問

AWSアカウントを作って、さあ AWS Management Console で EC2 インスタンスを起動してみようと思った時にまず迷うのが region の選択です。（勉強会時点は）4 つの Region（US East / US West / EU West / Asia Pacific）があるのですが、日本向け Web システムを構築するならどの Region を選びますか？

参考までに、各regionにmicroインスタンスを立てて、国内からpingを打ってみました。RTTを見るとUS WestかAsia Pacificかなーと思うのですが、日本向けWebシステムを作るとしたらどのregionを選びますか？もしくは選んでますか？

会場からの回答

• US West と Asia Pacific が半々くらい。US Eastもちらほら。EU Westはナシ。
• Asia Pacificでも経路によっては、国内からでも80msくらい出る。
  => たしかにさくらVPSからだと70msくらい出ますね。
• US Eastをあえて選ぶ理由は価格。
  => 速度を気にしなくて良い or 工夫できるなら、価格も大事な要素です。
• RTTだけが重要なわけでは無い。
• Asia Pacificを選んで困ったとこは特に無し。

感想

pingの結果を見ると、やっぱりUS Westを選ぶ人が多いように思っていたのですが、Asia Pacificの人も結構多かったです。ちょうどAsia Pacificのサーバを作っていたところだったので安心しました。

より近いregionができれば悩む必要の無くなるので、今後に期待したいですね。

2. AMI

質問

EC2インスタンスを起動するときに選ぶAMIですが、Amazon AMIやPublic AMIなどの公開されているAMIを利用しますか？それとも自分でイチからOSを入れて構築したAMIを使いますか？なお、前者の場合は起動したインスタンスをカスタムして別のAMIを生成することも含みます。

会場からの回答

• 全員公開されているAMIを利用で、OSをイチから入れるという人はいませんでした。
• 公開されているAMIを利用しつづけて困ったことは特に無い。
• やはりAmazonとしては、Amazon Linuxがおすすめ？
  => 必ずしもそうではない。利用者の自由。
• Amazon Linuxを利用すれば、AWS Premium Supportで有利？
  => 有利というわけではないが、Amazonで仕様を把握しているので回答は得られやすい。
• 会場でも何名かの人が実際にAmazon Linuxを利用しました。

感想

ここもEC2を使う上で悩むポイントでした。

Googleで「EC2 AMI」で検索すると、AMIをOSイメージから作成する情報が多くひっかかり、逆に公開されているこのAMIを使うと良いといった情報があまり無かったので、実はOSイメージからAMIを作成してそれをラウンチするのが一般的なのかと思っていました。

個人的にはrightscaleのAMIを利用していて、それで困ったことは無いのですが、やはり同じような使い方をしている人が多いということで安心しました。また、Amazon Linux を本稼働で利用しているという意見も聞けたので今後は利用してみようと思います。

3. Root Device

質問

AMIを選ぶ時にも絡むのですが、Root Deviceの選択です。instance storeとEBSの2種類が選択でき、それぞれ特徴があります。どちらを利用していますか？利用しますか？

これはあくまでRoot Deviceだけの話で、instance storeがRoot Deviceでもデータ領域にEBSをマウントする方法は、前者になります。

会場からの回答

• ほとんどの人がEBS。
• サーバ用途にもよる。
• 従来はinstance storeだったものをEBSへ移行している。
• Root Deviceをinstance storeにしているのは、以前はRoot DeviceにEBSが利用選択出来なかったからでは。
• EBSは速度的に不利という話があるが？
  => とくにそれで困ったという意見はありませんでした。

感想

EBSは数多くのメリット（インスタンス停止時にデータが消えない、スナップショット（バックアップ）が容易、AMIが簡単に作成できる、別サーバにattachできるなど）があるのでDevice Rootとして利用したいと思っていました。

速度的に不利という情報もあったので、実際のところどうなのかと思っていたのですが、とくに支障は感じないということだったので良かったです。

何か明確な理由が無いかぎりはEBSをRoot Deviceに選んで良さそうですね。

4. EBS Snapshot

質問

EBSの特徴でもあるスナップショットですが、簡単にボリューム全体のバックアップが取れるという優れものです。日々のバックアップとして利用しているのですが、実際のところ困ったこととかありませんか？

例えばスナップショットでバックアップを取っていたが、いざリストアしようとしたらデータが不完全で困った、など。

会場からの回答

• 困ったという意見はナシ。
• スナップショットはS3に保存される。S3の耐久性はイレブンナイン（99.999999999％）なので、まず大丈夫。
  => 自前でバックアップストレージ用意するよりはるかに安全ですね。。。
• ただファイルシステムの整合性は担保されていないので、これは自分でフォローする。
  => 書き込みロックする、DBはダンプする、など。
  => 書き込みが頻繁で無いなら、世代数を多めに取るという考えもあり。
• 念のため他のバックアップ方法と組み合わせている人は？
  => いませんでした。

感想

EBSのスナップショットは簡単にバックアップが取れるのでかなり便利なのですが、あまりに簡単過ぎて、根拠はないのですが若干不安があったりもしました。

そういった心配は不要でしたので、安心して利用できますね。

やってみて

逆質問という形式でやってみたのですが、多く方々から様々な意見を頂いて、とても勉強になりました。まだまだ聞きたい内容はあるので、また次回以降でやってみたいと思います。

回答頂いたみなさんありがとうございました！

雑感

こんなにAWSについて聞いたり話したりしたのは初めてでした:D

他の方の発表ももちろんですし、懇親会でも（ここでは書けない）色々なお話を聞くことができて楽しかったです。やはり「生の声」が聞けるのは勉強会の醍醐味ですね。進化が速いAWSだけに最新情報を共有できるこういった場は貴重です。

懇親会でJAWSの方々から「コアメンバーになる？」と声をかけて頂いたので、コアメンバーとしてお手伝いさせて頂くことになりました。具体的に何をやるのかはまだ分かっていませんが、コミュニティ活動に関わって行ければと思います。

会場提供頂いた富士ソフトさん、AWSのお二方、JAWSのみなさん、ありがとうございました！