2012年5月28日月曜日

DevOps Day Tokyo 2012に参加してきた(昨日の話)ので報告と雑感。

昨日DevOps Day (sじゃない)のイベントがセルリアンタワーのGMOであったので参加してきた。

今回は正直誰が何をしゃべるのかもわからなかったので速攻で申しこみだけをしておいた。そうしたら、opscodeもenTRUSTもいるという俺得なイベントでした。積極的に質問もしたら、いろいろ出てきたのがサイコーだった。そんなわけで、いろんな話もできたし、最後に一本締めのときに前に出ることにもなったり、とても楽しい一日でした。講演者の方々、主催、スポンサー、会場のGMOの方々ありがとうございました。

全体の雰囲気は、http://togetter.com/li/310514、隣で取材してた新野さんのpublickeyに出る気がするのでそちらを参照。

以下は自分が体験したこと。

まず、opscodeのGeorge Moberlyさんから、

次のchefバージョンではDry Runがサポートされる

という言葉をもらったことはかなり心強い一言だった。他にもchefに関しては、日本でのトレーニングやCertification programの話を聞いてみたところ、前向きに考えているとのことだった。

次に、DevOps Cafeの主催のJohnとDamonにも彼らの発表に質問したり、発表がおわってから後ろで何か話をしているところにはいって話ができた。技術から金の話までおもいっきり楽しめた(enSTRATUSのビジネス配分についての話まではしなかった)。もちろんAWSで仕事してることは隠さなかったので、そこで丁度いいと思われたのか、彼らのPodCast用の取材を受けることになった。木曜か金曜あたりに私のビデオが彼らのwebから、podcastは音声だけなので私のやばい英語が世間に出ることになるはず。

今回意外だったのは、Private vs Publicのセッションでも主張したのだが、意外とみなさん教育(新人教育や、外注、パートナー育成など)の悩みがないようだ。chefに関して「日本語化しなくてもいいよ」という話がでた。私は日本語じゃないと。。という声や、サービスやツールがサステイナブルに使われるには教育がないと、という声を日々聞いているが、こういう会にきて実際に触ってる人からすると考えることではないのかもしれない。

2012年5月27日日曜日

VPCにタグつけれるんだが


$ ec2-describe-vpcs
VPC vpc-95aa06fc available 10.0.0.0/16 dopt-69ab0700 default

となっていたもの。

こいつに"hoge=vpc1000"という名前をつける


$ ec2addtag vpc-95aa06fc --tag hoge=vpc1000
TAG vpc vpc-95aa06fc hoge vpc1000

すると、


$ ec2-describe-vpcs
VPC vpc-95aa06fc available 10.0.0.0/16 dopt-69ab0700 default
TAG vpc vpc-95aa06fc hoge vpc1000

まあ、tagはつけられると。

まあ肝心なことはここを読めと。
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/Using_Tags.html

2012年5月24日木曜日

ELBの扱えるTCP portは25,80, 443 or 1024 to 65535

これもまた知られてないシリーズか。
ELBの扱えるTCP portは25,80, 443 or 1024 to 65535。
そして、違うportにアクセスしてもICMPでrefuseを通知したりはしない。

2012年5月22日火曜日

easyRoute53: Route53を前提のドメインレジストラ

easyRoute53: A GUI, User Interface to Amazon's Route53 DNS with Registrar Support

まあ中身的には大したことをしているわけではなさそうではあるが、GUIがほしい人、楽したい人はあってもいい選択肢だと思う。

easyDNS and Amazon are not partners or affiliates.

としっかり断り書きもはいっているのも好感か。

どんなことをしているのかは、スクリーンショットをみるのがいいね。

2012年5月21日月曜日

wowzaはけっこう使われている話。

AWSの英語のフォーラムをながめてたら、南米のオンプレミスでエンコしたものを日本から配信したい話っぽい。

AWS Developer Forums: When the DirectConnect will be ...

We are planning media streaming service from South America to Asia-Pacific. The streamer in AP EC2 instance will keep pulling live feed video from SA.
1) So, we have to be guaranteed on network bandwidth from SA to AP. Your DirectConnect service seems to be not available yet. when will it be?
2) without DirectConnect, It there any other AWS service that will enhance the network bandwidth usage for media streaming from region to region? TIA

wowza mediaは http://www.wowza.com/pricing/ec2-streaming に詳細がでているが、wowzaからライセンスを買って持ちこむことも、AWSからpaid amiという形でEC2の利用料金に上乗せするかたちでも使うことができる。

比較対象としてはAdobeのFMSとMS IISストリーミングなんかがあるのだが、Wowza,AdobeFMS, IISの比較表がでている。なんといってもFlash,silverlight,quicktimeと扱えるフォーマットの広さと安さ、そして配信パフォーマンスが魅力的。

もちろん東京リージョンでも使える。

Amazon VPCのネットワークにまつわる細かな話

これへの答えとしては、

各サブネットにおいて、Amazon が先頭の4 IP アドレスを確保し、最後の1 IP アドレスは、IP ネットワーキングの目的で確保されます。 http://aws.amazon.com/jp/vpc/faqs/#I8

ので、典型的には

ということになる。

他の細かな話。

(@shot6 による情報を得て修正)

    2012年5月20日日曜日

    NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較 など。

    NHNテクノロジーカンファレンスにいってきた。

    DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。

    "Mobage DBA Fight against Big Data" - NHN TE [slideshare id=12990643&w=425&h=355]
    View more presentations from riywo

    実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。

    このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。

    サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。

    RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなインスタンスに設定を変更する。詳細はFAQの#20を参照。

    「バックアップ」サーバ。マスタおちたときのレプリ昇格用。デイリーのバックアップ用。サービスからは参照されていないただのスレーブ。デイリーバックアップは人のすくない朝3時とかにmysqldump

    RDSの場合は、http://aws.amazon.com/jp/rds/faqs/#23 にあるように、デイリーの自動化バックアップと、任意のタイミングでのデータベース スナップショットを提供している。

    MHAでは、データの整合性をたもち、スプリットブレインがおこらないように、マスタ切り替え。IPのきりかえまでもやってくれる。夜中におちても切り替え時間だけの停止。計画的に使うこともできる。

    RDSであれば、可用性向上のためにさらにMulti-AZオプションが使える。http://aws.amazon.com/jp/rds/faqs/#36 にあるように、Amazon RDS は別の Availability Zone において同期する、「スタンバイ」レプリカを自動的に設定して管理します。DBインスタンスに対する更新は、複数の Availability Zone 全体において、スタンバイに対して同時にレプリケーションされます。

    フェイルオーバー時、Amazon RDS は単純に DB インスタンスの正規名レコード(CNAME)を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。DBサイズにもよりますが、3分以内で復旧します。

    ここまでいいことを書いたけど、RDSでは絶対にできないことは、お客様側のアプリで対応しないといけないこと。そしてInnodb以外を使うこと。というわけで、次の2つはさすがのDeNAの総合力といったところだろうか。

    UPDATEの最近の命題。ロックをどれだけ短かくするか。ソシャゲは綺麗なもんばかりじゃないのでデッドロックはおこる。そこでロックの順番をアプリで管理させる(理想) or バージョンをつかって楽観ロック 

    プライマリキーでのSELECTの機会は多い。そこでHandler socketの登場。SQLパーサをはぶけるので速くなる解説。