2011年5月27日金曜日

サイバーエージェントxクックパッド合同勉強会に参加しました

５月もそろそろ終わりに近づきましたが、今月は全くブログを更新してないのかorz
昨日はせっかく勉強会に参加したので、ブログに残しておこうと思います。

参加したのはサイバーエージェントさんと、クックパッドさんの合同勉強会。
最近の勉強会は気付いたらすぐに定員が埋まってしまうので、参加するのも大変（汗）
今回の勉強会も登録した時点では補欠でしたが参加枠が拡大されて出席出来ました。
とても参加したかった勉強会だったので、ほんとに良かったです。

場所はクックパッドさんのオフィスがある白金台！
シロガネーゼとやらは、どなたなのか分かりませんでしたが静かで、お洒落なとこでした。
『なんか大衆居酒屋とかねー街なんだな！』というのが第一印象です。
自分が住むには住みずらそうですが、家賃払えないので、不要な心配ですね。

クックパッドさんのオフィスはとても奇麗でした！
写真をあまり撮れてないのが非常に残念＞＜ですが、会場は以下のような感じ。
しかも懇親会でお料理が出るなんて、とてもユニークで美味しいお勉強会ですね★
最初に【プレゼンの時はプレゼンに集中！食べるときは食べる事に集中！】というありがたいお言葉を頂きました。


以下はメモと感想ですが、みなさんSlideShareとかにアップしてくれるらしいです。
私のメモは適当すぎるので参考程度に…資料がUPされたらリンクをつけときたいな。

■一人目はサイバーエージェントの坂本さん
OpensStackを検証してみたというお話です。
AWSに例えるとってところもあり分かりやすくて、ありがたかったです。

AWSとの比較
  • EC2=>Nova
  • S3=>Glance(OSイメージ登録)、Swift(ストレージ)
Nova
  • CloudControllerとComputenodeに分かれる
  • Conputenode内にInstanceが起動される
  • CloudControolerとCnputenodのプロセスのお話
  • インスタンスのネットワーク構成を3種類から選べる
管理方法
  • novaコマンド
  • ecuca2oolsコマンド
注意点
  • 1プロジェクトで作成出来る上限は10インスタンスまで※変更可能
  •  ライブマイグレーションはは共有ディスクのみサポート
  • セキュリティ設定はiptablesで実装している
気付いたこととか
  • ElasticFoxでも管理出来る
  • Ubuntuだとパッケージ化されているからインストールが簡単
  • シンプルで分かりやすい
  • AWS知っている人はとっつきやすそう
苦労話し
  • インスタンスメタデータをどこに取りに行けのか分からない
  • ドキュメントは英語
  • 開発中なのでドキュメントは微妙
まとめ
  • 発展途上だけど使える
  • 開発が盛んだから今後にも期待出来る
  • GUIは本気出してくるかわからない
  • ハイブリッドクラウドが良いよね
【個人感想】
プライベートクラウドはH/Wの面倒をみたりと運用は大変そうだけど、自由度が高いというのは良い点みたいです。
物理H/Wは一台あれば試せるらしいので、かなり興味が湧きました。
お仕事ではパブリッククラウドばかりですが、いわゆるクラウドのバックエンドがどのように動くかという興味を満たしてくれそうな気がします。
あんな事や、こんな事も、楽しそう！！

■二人目はサイバーエージェント森野さん
AmebaPicoの裏側の技術とAWSの利用についてのお話でした。
Picoはピグの海外版でFacebookアプリもあるらしいっす。

サーバー構成
  • サーバーはすべてAWSのクラウドを利用している（個人的にはこの時点で涎モノ）
    • Cloudfront(キャッシュOKなもの)
    • EC2(汎用的なサーバーやその他)
    • S3(静的データのストレージ、ログの保存)
    • Elastic Map Reduce(S3のログ解析→結果はS3に保存)
    • EBS(バックアップや揮発性があっては困るもの)
    • 開発サーバとか本番サーバとかでインスタンスタイプ変更
    • MongoDB(3台構成の6シャドーで分散)
運用してみて
  • 手軽(必要なときに必要な時だけ)
  • データセンターにいく必要がない(海外ならなおさら)
  • インフラエンジニアがいなくてもなんとかやれた
  • たまに落ちる(頻度：現在60インスタンスで2ヶ月に1インスタンスくらいの割り合い)
  • 4週間のうちに4個落ちた事もあった(告知あり)
  •  落ちると応答がなくなる(特定ポートのみの場合や全体的に落ちる場合も)
  • 落ちた場合はリブートする時もあるがリブートしてもダメな場合もある
  • MongoDBのコネクションプールが枯渇した(I/Oボトルネック)
    • ⇒I/Oパフォーマンス高いもの+シャドーを増やした
  • MongoDBのバランシングの挙動に偏りがある
  • MongoDBの設定情報が反映されない事もあった
  • MongoDBの問題の解決とノウハウの蓄積をしたい
【個人感想】
やっぱりAWSはただのレンタルサーバとして使うのは持ったいなさすぎますね。
AWS内の色々なサービスを組み合わせて面白い使い方をして最高の力を発揮しますね。
そのためにはAWSの色々な使い方を妄想したり検証したり、使う準備も必要ですね。
syslogサーバのログデータとかもs3fs使ってs3とかに保存するのって運用したらどうなんだろう。
インフラエンジニアがいらないってなってしまうと悲しいけど…(笑)
どんなエンジニアでも色々な技術を吸収する事が大事になってきていそうですね。
レイヤーとかで分けるのではなく、いろいろ広く勉強しなきゃな〜。

■三人目はクックパッド成田さん
毎日の料理を楽しくする画像配信のしくみのお話
ちなみに私はここら辺から後ろからの、とても美味しそうな匂いで集中力が…が…が…w

今まで
  • 昔は画像をアップしたらいくつかのパターンの画像サイズ(サムネイル)を用意した
  • 現状の写真の大きさで本当に良いのか？まだまだ検討の余地がある
  • よりより写真にしたい
  • iPhoneアプリとかにも、きちんと適切をしたい
  • 画像配信するアプリケーションはサムネイル画像の運用が悩み
  • 画像保存先としてNFSはやめたい⇒AWSにいくならS3つかいたい
変更後(開発したTOFU導入後)
  • 配信は一枚の画像をS3にアップして配信時にオンデマンドの画像サイズで配信
  • TOFUはApacheモジュールとなり画像変換には(本当は速い)ImageMagickを使う
  • Imlib2を使わなかった理由は画像の質が落ちるから
  • CookPadアプリの写真は順次リプレース中
  • 効率が上がり開発者のモチベーションがUP、美味しい料理の写真を届けられるように
  • akamai⇒ELB⇒tofu複数台(c1.xlarge)⇒S3
  • S3は夢のストレージではない。S3の特定のAPIだけが障害発生したりもした。
  • S3はデータが消える事はなさそうだけど、データにアクセスできなくなる事はある
Akamai or Cloudfront
  • S3専用だったけど、EC2をオリジンに指定(Custom origin)が使えるようになった
  • just-ping.com(世界中からpingをうつサービス)を使うとakamai速い
  • Akamaiはあまりキャッシュヒット率が高くないから以前はさらにVarnishを配下に使ってもみた
    • Varnishはメモリを使うからTOFUインスタンスを増やしても良さそう
最後に
  • 写真は料理を美味しくみせる為に大事な事！！！
【個人感想】
とにかく料理を美味しくみせる為にという事を大事にしたお話しで素敵でした。
どうありたいかのゴールを大事にしてその為に何をするかって大事でっすね。
写真は美味しそうだし、後ろから美味しそうな匂いもするし、早くご飯食べたい★

■最後はクックパッド菅原さん
AWS移行に向けたクックパッドの取り組み＋αのお話
と、とにかくお腹空きました！お話も勉強になる素敵な会ですよ！

AWSのサーバネットワーク構成
  • iDCだと3層構成から⇒EC2だと1層構成になるからセキュリティをしっかりと確保
  • セキュリティグループは以下を組み合わせるみたい
    • Basic(基本的なものhttpsやpingや監視ポート)
    • 各ロールのセキュリティグループ(DB用やアプリサーバ用や)
    • 基本的にはIPからは許可しない事(ローカルIPだけ許可しても他の会社がいたりするから)
    • 全てのサーバでiptablesは有効⇒人的ミスを防ぐため
    • 内部DNSはPowerDNSで使う(E2のNAMEタグから引ける)
    • resolv.confは定期的に更新するように
  • AMIはCentOS5.5をクリーンインストール(EBSベース)
  • 64bitに統一する予定
    • 現在32bitがあるのはmicroインスタンスがなかった時代の残り(お金の事が原因とかとか)
  • ベースとなるAMIから各ロールのAMIを作成する
  • システム管理ツールのChefの導入も進めてる
  • システムネットワークの生存監視(Nagios)
    • Nagiosを使ったAMIからの復旧(ヘルスチェック失敗のタイミングで)
  • サーバの性能情報(munin)
  • EIP,HeartBeatを使った冗長構成も進めている
    • HearBeatの仮想IPの代わりにEIPを使う
分散DNS
  • resolve.confは内容がキャッシュされるのでApacheの再起動が必要になったりする
  • cronで監視だとダウンタイムが分単位になってしまう
  • 各インスタンスでDNSを起動して分散DNSを実現（デモをしてくれました）
【個人感想】
AWSでの運用はもっと考える余地がありそうだと思いました。
ノウハウもまだまだ集めたいし、現状に満足してはいけませんね。
もうお腹がぐーぐーなって死にたい！

■LT
Varnishのお話しやtmpfsのお話しや、とあるクラウドwのお話しでした。
Varnish勉強会は面白そうですね。懇親会の家が建つお話も素敵でしたw
Vanishで勉強会でお家の建て方を学びたい★

■懇親会
本当に美味しくて温かい料理は素敵ですね！
写真を全然撮ってない昨日の自分バカッ！

■最後に
今回の勉強は内容も充実していて、ご飯も充実して身も心もお腹いっぱいになりました★
関係者の方々ごちそうさまでしたー！

投稿者 時刻: