クックパッドさんのオフィスで開催された「サイバーエージェント×クックパッド合同勉強会」に参加してきました。 両社で検証や本番導入しているクラウドサービスな話題がメインで、とても興味深いものでした。

OpenStackを検証してみた - オープンソースの仮想化技術 open stack の検証結果の報告

サイバーエージェントの坂本佳久 (@ton_katsu) さんの発表。プライベートクラウドを構築するプロジェクトのひとつ、OpenStack を検証した結果のまとめ。

OpenStack

Nova と Swift を組み合わせたプロジェクト。 OpenStack を検証対象として選んだ理由は次のとおり。

• Eucalypusだとスケールしない (らしい)
• ubuntu がサポートする (らしい)
• 200 人体制で開発が行われている
• 参加企業として 60 社
• KVM, QEmu, Xen など広く対応している
• Pythonベースで書かれている

AWS と比較すると、下記のような対比でだいたい同じことができる。

• Amazon EC2
  • Nova
• Amazon S3
  • Glance
  • OSイメージ登録
  • Swift
  • ストレージ

システム構成の例

インスタンスの起動や管理を行う "CloudController" と、この配下に複数の "Computenode" を配置する構成をとる (最小構成では両プロセスを同じマシンに同居させることも可能)。Computenode に hypervisor などをいれ、実際にインスタンスを動作させることとなる。その他、副次的に MySQL や RabbitMQ などのプロセスも利用する。

使ってみた

実際に検証で用いた環境は下記の通り。

• OpenStack Cactus
• Controller
  • ubuntu 10.04
• Computenode
  • ubuntu 10.04 x3
• virtual
  • KVM ベースで CentOS / ubuntu

これらの管理を行うために、 Django ベースの GUI が付属している。WebSocket を利用するため、Safari などで操作する必要がある (Chrome はうまく動作しなかったとのこと)。また、VNC コンソールは Cactus のバージョンでは未実装なので、利用する場合は trunk から取得する必要がある。
その他、API も用意されているので自前で管理ツールを作成することも可能。

感想

• 良かった点
  • ubuntu ではパッケージで提供されているためインストールが簡単
  • シンプル
  • Python のためエラーが追いやすい
• 苦労した点
  • インスタンスメタデータをどこに取り行けばいいかわからなかった。。
  • ハイブリッドクラウドがいいかも

来月より検証環境で運用するとのことで、今後のレポートにも注目したいところです。

AmebaPico を支える技術 - AWS上に構築された AmebaPico で使用されている技術・開発体制について

サイバーエージェントの森野耕平 (@kohei_april20) さんの発表。AmebaPico のアーキテクチャや体制に関して。

Ameba Pico

アメーバピグの海外版として位置づけられているサービス。

• プラットフォーム
  • facebook
  • mochimedia
  • 独自 (自前)
• 利用ユーザ
  • 390万UU、60万MAU
  • 10-20代が中心、男女比 3:7
  • インドネシア、フィリピン、アメリカが中心

アーキテクチャ

すべて AWS で運用されている。

• application
  • Tomcat
• socket server
  • ノンブロッキング I/O を使い、軽量データ処理を行う
  • 独自のバイナリプロトコルで細かい大量のコマンドを処理
  • コマンドとしてのデータをバイナリとしてシリアライズ
  • イベント駆動でリアルタイム性
• static
  • CDN
  • Storage
• ZooKeeper
  • システム全体でのロック管理を行う分散ロックシステム
• memcached
• MongoDB
  • 3台構成のレプリカセットを構築
  • うち1台は EBS
  • 6シャードで分散
• ElasticMapReduce
  • ログ集計
• pigg と共用の箇所
  • ID管理サーバ
  • ポイント (サービス内通貨) 管理サーバ

AWS の利用

• S3
  • static な配信コンテンツを保持
  • ユーザ行動ログ
• CDN
  • cloudfront を利用
• ElasticMapReduce
  • S3 に保存されたログを解析
• EC2
  • 汎用的なサーバインスタンスとして利用
  • 用途に応じて種別を使い分け
  • small
  • 開発環境
  • High-CPU
  • webサーバ
• EBS
  • バックアップなど揮発性があって困る箇所にマウント

Flash の利用

クライアントサイドではまず main.swf のみをロードし、必要に応じてサブモジュールをロードする。

• shop.swf
• room.swf
• profile.swf delegate 実装でサーバ接続とモック用を切り分けることで、サーバサイドとクライアントサイド別々の開発が行えるようにしている。

運用してみて

EC2 上でサービスを運用してみての総括。

• 良かった点は「手軽さ」
  • DC 借りる必要ないことで海外展開のハードルが下がる
  • インフラメンバーがいなくても進められた (スモールスタート)
• 課題は「重い」こと
  • たまに落ちる
  • バージニアだからかもしれない？
  • バージニアで運用中のインスタンスが 60個くらい
    • 平均すると 2-3ヶ月に1つ落ちる
    • 最高で4週に4つ落ちたことがある
  • メンテナンスの告知が事前に来ることもある
  • こないこともある
  • インスタンスが落ちるとどうなるか
  • 応答がなくなる
    • 特定ポートだけの場合もある
    • 全体の場合は何も出来ない
  • リブートするしかない
  • 落ちなくても、一定時間応答なくなることもある
  • サービスとして利用する場合
  • 落ちやすいが冗長重視で組めば使える

そして、MongoDB をメインで利用してみての総括。

• 実績
  • 処理クエリは 5,000 Read/s (Max)
• 問題
  • コネクションプールが枯渇
  • MongoDB の I/O がボトルネックとなってしまう
  • シャードを 4→6 に増設することで対処
  • 合わせて I/O パフォーマンスの高いインスタンスを利用するように
  • オートバランシングの挙動
  • バランシングに偏りが生じてしまう
    • 新規シャード追加時などに特に顕著となる
  • 現在はオートバランシングを off にして手動で調整
  • レプリカセットのコンフィグ情報が未反映となるケース
  • 一見正常に動いてるので気付かなかった
    • プライマリ落ちたときにスレーブがうまく動かずに発覚
  • コンフィグの反映は全台再起動が必要

MongoDB を大規模に利用しているケースなので、とても興味深いものでした。海外展開の際に DC の場所を気にしなくても良い、というのは AWS ならではのメリットに感じました。

毎日の料理を楽しくする画像配信技術

クックパッドの成田一生 (@mirakui) さんの発表。レシピに必須の画像をリアルタイムでリサイズするための Apache モジュール "TOFU" について。

従来の画像アップロードの仕組み

• アップロードされた画像はアプリケーションサーバがリサイズ
  • サムネイルを NFS に保存
• いくつかの問題点
  • 新デザインのプロトタイプで様々な画像サイズを試すことが難しい
  • デザインに合わせて画像サイズを柔軟に変えたい
  • 試すたびに 800 万枚リサイズ
    • 昔はやってた (!)
  • デバイス展開の度にデザイン変わるためリサイズが必要
    • サービス出る速度が遅くなる
    • モチベーションが低下する

そこで新しい方法を模索

• 現在の規模
  • 投稿画像の枚数
  • 800万枚
  • 画像リクエスト
  • 7,000枚/sec
  • ストレージに NFS を利用
  • NFS が落ちると全サービスが落ちる
• EC2 への移行を検討中
  • ストレージは S3 にしたい

TOFU

URL に処理内容をマッピングし、リクエストの度に画像をリサイズする Apache モジュール (mod_tofu.so)。

/recipes/{:recipe_id}/{:size}/{:hash}

• アタック防止のために末尾に Hash キーを付加
• 画像処理も可能
  • c
  • crop (指定したサイズに収める)
  • q
  • quality
• 細かく指定すれば好きな部分だけ切り取る、もできる

画像処理には ImageMagick を利用している。

• 構成
  • C1.XLARGE x6台 で処理
  • コア数単価が安い
  • mod_tofu.so は CPU 食うけどメモリ使わない
  • 前段で akamai のキャッシュ

苦労話など

• ImageMagick と Imlib2
  • 本当は速いImageMagick: サムネイル画像生成を10倍速くする方法
• S3
  • s3::ListAllBuckets が正しい結果返さない障害発生
  • すべての画像が見えなくなった
  • データは消えないがアクセスできなくなることはある
• akamai or cloudfront
  • cloudfront は元々 S3 のデータを返すものだった
  • 現在は EC2 を origin に使えるようになった
  • でもやはり akamai は圧倒的に早い
  • akamai キャッシュヒット率は高くない
  • 90% 程度
  • 試しに ELB 下に Varnish でキャッシュサーバを構築してみたところ 60% ほどヒット
    • TOFU サーバの数を 40% ほど減らせる
  • でも Varnish は大容量のメモリが必要なためインスタンスの単価が高い
    • キャッシュサーバ入れるか、TOFU サーバを増やすか、コスト的に微妙なところ
    • 現在はキャッシュサーバは外している

画像種類もリクエストも多いのにリアルタイムに変換するのは大変そうに思ったのですが、Apache モジュールと聞いて少し納得。キャッシュもうまく組み込んでいて、かなりコストを意識した工夫がされている印象を受けました。

AWS移行に向けたクックパッドの取り組み＋α

クックパッドの菅原元気さんの発表。先日のアマゾンウェブサービスクラウドアドバンテージセミナーで発表された内容をベースに、AWS 移行に向けた全体的なお話。 プレゼン資料がとてもまとまっているので、そちらを直接見たほうが。。。

サーバ・ネットワーク構成

• 現在
  • シンプルな3層構成
  • 別々のセグメントとすることでセキュリティを担保
• 新
  • すべてが同じセグメント
  • セキュリティグループでコントロール
  • ロール同士の通信は許可
  • 人的ミス対策としてすべてのサーバで iptables 起動

AWS でのサーバ

• DNS
  • Active-Active 構成で EIP を VIP のように利用
  • 各サーバでは resolv.conf を cron で更新
• AMI
  • 基本は CentOS 5.5
  • 各イメージはバージョンをつけて管理
  • Chef 導入も進めてる
• Nagios + Munin
  • タグをもとに自動で監視項目を設定
  • 起動したインスタンスを cron でチェックして追加
• 冗長化
  • ElasticIP を利用
  • Nagios
  • LDAP
  • cron で死活監視
  • heartbeat への移行
  • EIP を VIP として利用
  • マルチキャストが使えないのでユニキャストで
• MySQL
  • EC2 上ではまだ Slave しか稼動していない

分散DNSについて

さすがに全台で resolv.conf を書き換えていくのは大変なのと、いくつかの問題点がクリア出来ない。

• 内容がキャッシュされる
• タイムアウト 1s 以下にできない
• cron で監視は分単位

そのため、分散 DNS を開発。

$ ruby gem ddns

DNS がそれぞれノードとして機能する動きは、クラウドならではの問題点をクリアするためのひとつの解決策かと思います。現状のサービスを AWS に移行する際の参考になるような、総括的な話でした。

LT もあり、その後の懇親会ではおいしい料理もあり、でとても素敵な勉強会でした。スピーカー＆スタッフの皆様、ありがとうございました！