ao-log

インフラ系ITエンジニアのメモ帳です。

「【AWS勉強会】CM re:Growth Developers.IO Meetup 01」参加レポート

参加してきました。告知されていたページはこちら。
http://connpass.com/event/4123/

クラスメソッド株式会社様の主催で、10名の方がそれぞれ持ち時間20分での発表でした。いずれの発表も濃い内容で、また数々の名言もありました。会場に来ている方も、先進的な技術者の方が多い印象で、発表者と会場が一体になった楽しい勉強会でした。

少し脱線しますが、社員の方が書かれたブログの記事数が、そろそろ 2,000 を超えそうだということで勢いがすごいです。
http://dev.classmethod.jp/

以下、10 個の発表について、個人的に印象に残った点をまとめていきます。

Redshift x EMR x Tableau Desktopで実現するCloudTrailログ解析

CloudTrail のログを整形し、最終的に Tableau Desktop で可視化するという発表。
たしか、この発表でだったと思うのですが、RedShift を使用後に落とし忘れて、しばらく稼働したままになっていて案の定そこそこの額の請求となってしまったという話がありました。使い終えたものは忘れずに落とそうといういい教訓でした。

Re:Invent報告

Re:Invent に行ってきた報告で、クラスメソッド様は発表者の方を含め 4 名の方が行ったそうです。ツアーというのがあるそうで、ツアーに沿っていくことで様々な負担が軽減されそうでした。

EMR with the MapRは何がうれしいの(仮)

MapR は Hadoopディストリビューションの一つで、Java ではなく C++ で実装されています。M3、M5、M7 があって、M3 が無償利用できるそうです。AWS にのっている M3 は若干追加費用が発生するらしいです。
[MapR: MapR エディション]
http://www.mapr.com/jp/products/mapr-m7-edition
[Amazon Web Services]
http://aws.amazon.com/jp/elasticmapreduce/mapr/

MapR の特徴は高速なことなので、EMR と比較して高速に処理できるのであれば、MapR の使用費用が若干高くなってもトータルでは安くなるのではとの仮説を立て、実証した内容でした。BigData Benchmark というものがあるそうで、このテストケースを使ってベンチマークしたそうです。
[BigData Benchmark]
https://amplab.cs.berkeley.edu/benchmark/

結果は、試したテストケースではMapR を使うと少なくとも 3 倍くらい早くなり、同程度の計算が半分程度のインスタンスでできるようになり安くなると実証できたと結論付けられていました。

ソフトウェアの取捨選択でコストがここまで変わるのは劇的で、参考になりました。

運用担当者からみた、AWS へシステム移行する際に気にしてほしい5つのこと

私も日々システム運用している立場なので、すごく共感できる内容でした。AWS を使うことで技術者にとって様々なことが簡単に実現できても、いざ運用する際は様々なステークホルダがいて、人が運用することをしっかり考えないといけないと考えさせられました。

発表内容を完全に覚えていないので私なりにアレンジした内容となってしまいますが、技術者の脳内にあるユースケースとは違って、各ステークホルダは色々なシステムの使い方をしたり要望を発生させるので、データの流れをヒアリングして聞き出したり、ログから実態を調べて、要望とのずれがないことを確認すること。また、監視の際は Web サーバ一台でも ELB を使うことでとれるデータが増えること、CloudWatch のログは 2 週間までしか残らないので Zabbix などの統合監視ツールでもとるようにしたほうがよいこと。保守員用にシステムに入る経路を用意しておくこと。などの考え方を教えてくださりました。

また、5 つめの気を付けてほしいこととして、自分が現場担当者として関われなくなった時のこと(例えば年齢が上がりマネジメント側の人間になった場合)のことも考える必要があるとのことでした。マニュアル等が残っていないと後に残った人が苦労するので、それを残す。また、何故そのような実装もしくはやり方にしているのか、思考の記録を残すことも大事で、周りの人のこと、後輩世代のこともしっかり考えないといけないと再認識させられました。

「『なれる!SE」2 巻での梢さんの明言も紹介され、これも非常に共感できました。

CloudWatchで出来ること

CloudWatch でとれるデータについて、踏み込んだ内容の発表でした。様々な情報を取得できますが、直感的な理解とは異なる情報が出力されるケースがいくつかあるようです。どのような値が出力されるのかきちんと調べて理解しておかないと、思い違いをしている可能性があるので、注意が必要だなと感じました。

Storage Gateway仮想テープライブラリによるバックアップ戦略

発表内容が変わって、壮絶なプロジェクトをどう達成したかについての発表でした。6リージョンで計180台(各リージョンで30台ずつ)のインスタンスを稼働させる。話が出たときの納期は 1 週間で、前半 3 日で実現方法の検討や社内の人材リソース調整、後半 3 日で構築というすさまじい内容でした。構築は、CloudFormation と Capistrano で行ったとのこと。

いかんせん時間がないので、ベストプラクティス的な方法というよりは力技を多用。また、CloudFormation は途中でこけるとロールバックするので、すべての構築を一気にするのではなく、3 段階程度に小分けして実行し、リスクを減らしたりなどの工夫をされていました。AMI のリージョン間コピーは前はできなかったそうなのですが、最近できるようになったそうで、これがあったので大助かりだったそうです。
[【AWS発表】EC2のAMIをリージョン間でコピー可能に]
http://aws.typepad.com/aws_japan/2013/03/ec2-ami-copy-between-regions.html

AWS SDK for .NETを利用したExcelによるAWS環境定義書自動生成

色んな意味ですごい内容でした(褒め言葉です)。会場からの反響も大きかったです。
Excel のボタンをクリックすると、AWS の様々な構成情報を拾ってきて、Excel シートに落とし、またその逆もできるという内容でした。背景として、大企業様との取引でドキュメント化のご要望もいただくことがあるようです。

CloudFormationとSerfで作る全自動インフラ

Serf を使用したデモをしてくださり、動きのイメージがわきました。デモは VPC で 2 つの NAT インスタンスを用意し、プライベートサブネットで gw となっている NAT インスタンスを落とした時の自動復旧について。gw となっている NAT インスタンスをリブートしたとき、reboot を イベントとして Serf で検出し、自動的にもう片方の NAT インスタンスに gw を切り替えて、プライベートサブネットからの通信が復旧するのを実演してくれました。今日(12/11)の CDP Advent Calendar で記事になるようです。

Infrastructure as Code からFull Reproducible Infrastructureへ

コマンドひとつでインフラを構築でき、別のアカウントでも同じようなインフラを構築できる。このようなことを実現できるソフトを書いているようです。

なお、発表者の方から「Infrastructure as Code」は知っていますか? 「Immutable Infrastructure」は知っていますか? との質問が会場の参加者に向けてありましたが、半数以上の方が挙手していて、参加者の先進的ユーザ率はやはり高かったようです。発表中「SSH したら負けだと思っている」との名言があり、これも賛同する方が多かったです。

Amazon DynamoDBによるセッション永続化とフェイルオーバー

発表内容が変わって、6 個めのプレゼンテーションで発表された壮絶なプロジェクトについて。こちらは、後半 3 日間での構築の話よりは、前半 3 日間のクライアントから依頼をもらって構想を練る段階がメインでした。

印象的なのは、マルチリージョンでの構築をした点です。さすがの AWS といえどもインフラを無限に利用できるわけではなく、ある一定量以上を使用したい場合は、上限緩和の申請が必要とのことです。
[お問い合わせ: サービス上限緩和の申請]
http://aws.amazon.com/jp/contact-us/

要件の実現を構想するにつれ、1 つのリージョンでは実現できないと分かってきたとのことですが、最終的に北米の 6 つのリージョンで解決しています。1 リージョン内での様々な制約も、マルチリージョンで解決するとのことで、リージョンでのある種のスケールは、AWS ならではだと思いました。もっと、リージョンが増えれば、ますます大規模なことができるとのことで、さらなるリージョンの追加を望んでいるとのことです(思わず笑ってしまいましたが、リージョンの増設を今までどんどん実現してきたのが AWS のすごいところです)。re:Invent でも今までマルチ AZ だったのが、マルチリージョン推しに変わってきていて、クラウドの世界のスケールの大きさを生々しく感じる事例でした。