2013年3月23日土曜日

JAWS DAYS 2013 セッションメモ

2013年3月16日に行われた JAWS DAYS に参加してきました。
色々なセッションを聞いて、良いなと思った部分の羅列です。



クライドソーシングサービスを支えるクラウドコンピューティングサービス
ランサーズ株式会社 木下さん


AWS って何ですか?とサポートに問い合わせると、本社まで説明に来てくれる。
さらにその説明が詳しくて助かる(初心者には良く分からない事もある)
電話対応でも丁寧にサポートしてくれるので、何かあったらサポートに問い合わせるべき。

EC2 で CentOS 使いたい時は、提供されている AMI から作ったほうが手っ取り早い。
CentOS を初めから入れようと思ったら思わぬエラーの連続で、CloudPack の AMI を使うことにした。

画像を多く扱うサービスなので、画像や成果物は S3 へ。
サムネイル画像は EC2 にあるけど、アップされた画像や成果物は圧縮して S3 で保存している。
S3 へのアップは、PHP 版の SDK を利用。

負荷テストはスポットインスタンスで。
同じ構成をスポットインスタンスで再現して負荷テストすると、本番に影響出ないうえに安く済む。
負荷テストは短期間なので、途中でインスタンスが利用できなくなることもない。

あらかじめ予想されている負荷であれば、ELB を pre-warming しておくと便利。
ELB は負荷に応じてスケールアップするけど、5分経過しないと反応してくれない。
TV 効果など瞬間爆発的な負荷には対応出来ないので、事前にスケールアップしておくこと。
サポートに連絡すると対応してくれた。

AWS の機能はブラックボックスな所が多い。
なので、随時サポートに問い合わせるか、EC2 で実装して解析をする。
でも、AWS では通常のwebサービス稼働に使う機能が充実しているので、EC2 で独自実装するよりもサービスを使った方がお得だし簡単なので、できるだけそちらを利用する予定。



EventRegist on AWS: イベントレジストにおけるCDP
イベントレジスト株式会社 池田さん


インスタンスに付けられるタグを利用してバックアップ世代を管理している。
バックアップスクリプト中で、自分に付けられているタグからバックアップ世代を取り出して判断。
これならスクリプト修正しなくてもいいし、適宜変更可能。

静的コンテンツは外(S3)に出す。
イベント毎のヘッダー画像やサービス共通のCSSなど、読み込まれる事が多くて静的なものは全てS3へ。

トラフィックの特性が違うので、ELB は分ける。
webとDBではアクセス数も頻度も違うので、用途別に分けた方が最適化されるのでトラフィックが安定する。

AutoScaling は利用してない。
負荷の波が来たら、手動でインスタンスを起動していた。
でも今まで落ちたこと無い。

AMI はミドルウェアがインストールされた状態のもので、設定を修正反映するのは Chef に任せている。
インスタンスをコピーする際も、最初の1台を作って、そのAMIから次を作る。



無限にスケールし続ける写真共有SNSを運用するケーススタディ「snappeee」
株式会社マインドパレット 神尾さん


なるべくメンテナンスをしないような設計にした。
メンテナンスに手をかけるのは大変とわかっているから。
100% SimpleDB で動くように設計した。

サービスに合わせてプログラム・インフラを変えていく。
AWS は作り直しが簡単なので、壊せるし移動しやすい。
運用していく中で、どうしても現状に合わせて変更しなければいけない時がある。
その時はえいやと変えてしまう。恐れていては機会を逃してしまうから。

SimpleDB にも制限があるので DynamoDB に変更した。
10GB の制限があったので。

AutoScaling はスポットインスタンスで起動。
利用料金が10分の1になった。
シンガポールの c1.medium はあんまり使われていないようで、最低単価で入札できて
いる。

1,2台つぶれても仕方ない。気にせずガンガン行こうぜ。
運用している段階で、インスタンスが何らかの負荷で使えなくなることはある。
想定済みだし、1,2台潰れたぐらいでサービス止められないので、止まらないようにイ
ンスタンス数を調整している。
負荷が来るのは一瞬なので、その一瞬を逃さないようにすることが大事。

ログはDBへ。
ログをファイルに書き込むと、I/O がボトルネックになりやすい。
なので、DynamoDB につっこんで、整形したものを RDB に吐き出している。
サービス側のユーザログは最終的に1ヶ所に集めるから SimpleDB に書き込んでいる。


クラウドな働き方

福岡支部 小室さん

雲(クラウド)を雲の上から操って、人間らしく生きよう。
便利なツールをただ使うだけじゃ何も変わらない。
自分が自分でいられる時間を作り出すために活用する。

札幌支部 田名部さん

そのためにも、信頼出来る関係が大事。
信頼がなければ、協力も得られないし理解してもらえない。
部分的でもいいので、ちょっとだけ試してみる。
だめだったら止めればいいだけの話。
問題なければ、すこしずつ広げていけばいい。

北陸支部 相羽さん

仕事をしている場所、環境が、本当に必要なのかを考えてみる。
常識を疑うと、人生が変わる。
今の方法ではない、他の方法が見えてくるはず。

2013年3月14日木曜日

[error]ファイルサイズ制限を超過しました


ステージング環境で symfony の test:all を実行した時、
エラーが大量に発生して、テストが通らなかったのです。

■エラー
sh: line 1:  4611 ファイルサイズ制限を超過しました
Test returned status 153


何?何事?

Linux はファイルサイズに制限があります。
基本2GBです。
http://blog.livedoor.jp/cielo_cielo/archives/65189748.html


そんなに肥大化したファイルって何だろう…あ、ログか(;・∀・)

$ ls -lh log/frontend_*
-rw-rw-rw- 1 user user 2.0G  3月 14 11:20 log/frontend_test.log


oh... orz
ということで、ログをローテートして、無事解決!

$ php symfony log:rotate frontend test --priod=7 --history=5