「JAWS-UG福岡もくもく会::EC2 Linux編」に参加した
JAWS-UG福岡もくもく会::EC2 Linux編
http://www.zusaar.com/event/878003
今回は EC2 に関する このスライド を教材に進める感じだった。
EC2 について
AWS を使う人は、数ある AWS のサービスの中から、まず最初に EC2 を使うことが多いのではないかと思う。
私も EC2 から使い始めた。
１年近く扱ってきて、だいぶん慣れたような気になっていたが...、
今回勉強会に参加して、まだまだぜんぜん知らないことだらけだなと思った。
今後も仲良く付き合いを続けたいので、自分が知らなかったことを中心に、めもめも。
ざっくりとしたメモ
Amazon VPC（Amazon Virtual Private Cloud）について
従来の EC2 の扱いに慣れているので、なかなか調べる気になれていない...。
気になるので、時間をみつけて勉強したいと思う。
Amazon VPC に関する、現時点の最新スライドは これっぽい？
Chaos Monkey（ケイオス モンキー）について
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
http://www.publickey1.jp/blog/12/chaos_monkeynetflix.html
少し昔に話題になっていた、意図的にサーバー障害を引き起こし、SPOF をあぶり出す目的で使うツール。
高い可用性を目指す Web サービスを運用するならば、こういったものがあることも覚えておきたい。
EC2 の Termination Protection（ターミネーション・プロテクション）について
存在を知らなかった。
EC2 は instance を永久に破壊する「Terminate」というコマンドがあるのだが、
Web Console 上から、簡単に選択できてしまうため、誤作動が怖い。
（私は誤作動させたことはないけれど、ありえないこともない。Stop コマンドのすぐ上にあるし...）
この誤作動を防止するために、「Terminate」にロックをかける仕組みが「Termination Protection」。
重要なインスタンスに対しては、こういう防衛策も必要？
詳しいやり方 ↓
インスタンスのTerminate | cloudpack のブログ
http://blog.cloudpack.jp/2011/07/study-instance-terminate.html
オススメの AMI ってあるの？
Amazon Linux AMI が一応、一番オススメらしい。
Amazon Linux AMI は Amazon がメンテナンス・チューニングしている AWS 向けの Linux OS 。
AWS の特性をよく理解している人間が、メンテナンスしている Linux OS なので
一般的には信頼性が高い。というふうに言われているらしい。
確かに、意外とめったに落ちないらしい。
NFS (Network File System) とは
NFS とは AWS と直接の関係はない。
NFS という技術は、複数の異なるサーバーから、単一のストレージを共有して利用するための仕組みである。
Amazon EBS（Elastic Block Store） の説明をみんなで聞いている時に、話が出た。
Amazon EBS は２つの EC2 instance から１つの EBS を参照するような使い方が出来ない。
２つの EC2 instance から１つのストレージを参照したい場合は、
NFS の導入を検討するか、Amazon S3 で代用できないか考える。
NFS → GlusterFS がオススメ？ （すっごい高コストらしい。）
「汚れたIPアドレス」
こういう概念があるのを知らなかった。
Elastic IP で割り振られる IP アドレスは、基本的には みんなで使いまわしている。
古い利用者が使っていた IP で、たまにスパムの標的になっている IP があったりするらしい。
こういう IP にあたってしまった場合は、IP を再取得したり
地道にスパム対策を行うなど注意が必要になる。
メールサーバーに IP を割り当てるときは、予め注意しておく必要があるらしい。
AWS 障害の検知は、何が一番はやい？
１．Twitter が早い
２．http://status.aws.amazon.com/ をチェックする
３．AWS の障害情報をつぶやく bot があるらしい → @awswatch （これ？）
ELB を冗長化出来る？
ELB が SPOF にならないよう、ELB を２台使って、インスタンスに対してクロスに使うことができるという話が出たような...
ちょっとこの件関しては、理解が及んでいないので、後々調べたいとは思う。
少し Google で調べてみたけど、そんな情報が見つけられない。
そもそも ELB 自体が冗長化されているはずなので、
ELB に障害が発生した時、１台でも２台でも耐障害性に違いは無さそうな気も...
疑問。
この件とは別で、ELB について詳しい資料あった。
ELBについてとことん理解する | TecTec Cloud
http://ttcloud.net/aws/ec2/elb/20110731/1567
【追記：2013/07/17】訳：ELB：評価方法のベストプラクティス
http://understeer.hatenablog.com/entry/2012/02/29/175334
Tsunami UDP について
データのアップロードを高速に処理するための手段として、話題に出た。
信頼性は犠牲にするが、TCP/IP より相当早い（？）
Tsunami-UDP で vmdk の高速転送してみた
http://snickerjp.blogspot.jp/2013/04/tsunami-udp-vmdk.html
稼働中の EC2 instance のメタデータ取得
169.254.169.254 という怪しいアドレスは、EC2 instance 上からアクセスすることができる不思議な世界らしく、
ここにアクセスすることでインスタンスのメタデータが取れるらしい。
ふむふむ。
EC2 の User Data
EC2 インスタンスの起動時によく目にするが、何のためにあるのかわからなかった「User Data」。
ここにシェルスクリプトを記述することができて、それを instance 起動時に実行させることができるらしい。
すごく便利そう！！！
EC2: User Dataを使ってインスタンス起動時の処理を自動化する
http://understeer.hatenablog.com/entry/2012/07/19/123050
今流行の Chef や Puppet との連携。
または instance に対して共通して実行させたいシェルスクリプトを S3 などにアップロードしておいて、
User Date に そのスクリプトの wget と run を仕込んでおいて、自動でセットアップ。
とか夢のある話が出てました。
最後に Tips
AWS の料金体系、じつは json で取れます（非公式）
http://blog.popowa.com/2013/06/ec2json.html
な、なるほど... （笑
大変勉強になりました m(_ _;)m
ありがとうございます！
