Recommandé
Contenu connexe
Tendances
Tendances (17)
Similaire à 30days album / MySQL Casual Talk #3
Similaire à 30days album / MySQL Casual Talk #3 (20)
Dernier
Dernier (9)
30days album / MySQL Casual Talk #3
- 1. こんな僕でも 一億枚さばけた 30days albumインフラ成長の歴史 2012.4.19 MySQL Casual Talk #3 Ryo Kuroda @lamanotrama
- 2. 自己紹介 ● 株式会社 paperboy&co. ● インフラエンジニア
- 4. サービス紹介 ● http://30d.jp ● 2008年4月 ～ ● 写真共有・保存サービス ○ 期間限定(30日)オンラインアルバム ○ 合言葉で共有(閲覧、投稿) ● 2009年12月 ～ ● 容量無制限オンラインフォトストレージ
- 5. 登録枚数 ● 最近累計登録枚数が1億枚を超えました ● 2012.4.19現在 108,491,796枚 ● 容量 202TByte
- 6. 何が「こんな僕でも」なのか 前職 ● ホスティング会社サバ管 ● 台数はそこそこ ● 2000台位かな ● 皆さん等しくそれなりに使えればOKな世界
- 7. なにそれ? ● パフォーマンスチューニング? ● HA? ● スケーラビリティ? (＊別のスキルは必要です)
- 10. 本題開始
- 11. まず当時の構成
- 15. 1. days アプリケーション用 ● 写真、アルバムの論理データ ● 誰々さんの、どのアルバムの… ● 保存期限 ● カメラの種類 ● Exif
- 16. 2. storage_api storage_api用 ● 全てのMogileFSオブジェクトへのAPI層 ○ アプリケーション、JOBワーカとMogileFSへの橋渡し ○ HTTP GET/PUTで画像の出し入れ ● ファイルのメタデータを管理 ○ content-type, content-length ● サービス種別を管理 ○ 30days、logpi、puboo
- 17. 3. mogilefs MogileFS用 ● オブジェクトの物理的な場所 ○ device ○ host ● オブジェクトの複製、再配置の為のジョブキュー
- 19. 全て画像絡み 扱う枚数が増えればDBの負荷も上がる ● 管理枚数 ● 閲覧数 ● アップロードペース
- 20. より詳しくは アーキテクチャの詳細は過去のスライドをご覧下さ い。 ● 関西オープン2008 http://www.slideshare.net/mizzy/2008-30days-album- presentation ● YAPC::Asia Tokyo 2010 http://www.slideshare.net/kyanny/inside-30days- albumlaterstory-5452817 今日あまり触れないDB周り以外の苦労話も入って ます。
- 23. 2010年 春 夏 兆候
- 25. storage006.30d.jp storage003.30d.jp storage002.30d.jp 今まで1ホスト1 role (puppetのマニフェスト上) だったのを storage001.30d.jp ストレージ (Mogilefs) ……
- 28. days dbにindexを追加 ● Maatkitマジ便利(って刺身さんがいってた) ○ mk-query-profiler ○ mk-query-digest ○ 刺身さんのYAPC資料 ● アルバム、ライブラリの表示レスポンスはある程 度改善 ● アップロードや画像変換の処理遅延は引き続き 悪化 この辺でアップロードペース(容量増加ペース)がグ
- 29. ストレージ容量グラフ
- 30. ● 週末には 500GB/日 ○ 2009年段階では多くて200GB ● 枚数にして 10万枚/日 ● 容量追加が間に合わない ● 空間効率が悪い ● ベンダー製はコストが…
- 31. 自作サーバー登場
- 32. MP100 ● 高集積 ○ 2U ○ 2TB * 7 ● 低コスト ○ ひみつ ● H/W好きで詳しい人がいた ○ マサキパワー100(kg)
- 34. ● 写真をアップロードしても表示までに時間がか かる ● 画像を回転しても返事がない ● まとめてダウンロード用のアーカイブファイル作 成がいつまで経っても終わらない
- 35. ● よくよくDB観察するとstorage_apiがテーブル ロックしまくってる ● 実はMyISAMだった ○ 実はあまり気にしたこともなかった これによって ● jobワーカがサーバ性能通りの働きを発揮出来 ない ● 参照クエリもレスポンスが悪化し閲覧にも影響
- 37. 2010年 秋 メンテナンス大会
- 39. ● 新サーバにはSSDを採用 ● 当然storage_apiはinnodb化 ● ついでにdays、mogilefsはinnodb file per table化
- 42. slaveの構成 諸事情により新サーバ用のslaveサーバを用意出 来なかったので、days DB用slaveサーバに相乗 り。 mysqld_multiは使わなかった ● なんだかんだで別々の方が扱いやすい ● わりとすぐに分離する予定だった ● puppetで構成管理するので都合が良かった
- 43. mysqld.second initスクリプト、my.cnfを調整して2つのmysqldを起 動。 別のmy.cnfと、それを使うラッパースクリプトを作 成して運用。 ● /etc/my.cnf.second ● /var/lib/mysql.second ● /etc/init.d/mysqld.second ● /usr/local/bin/mysql.second ● /usr/local/bin/mysqldump.second
- 49. この後、 ● days DBに更にindex追加 ● appサーバ群もリプレースにより強化 ● 内部ネットワークのギガ化 等も行い、過去最高の状態。 すごく早いよ!
- 51. 2度目の安定期 少しずつ手を入れながら平和な日々が続く。 ● 相乗りだったslaveも新サーバを追加して、別々 に ● railsの動作環境を Lighttpd+FastCGI から Apache+Passenger に変更 ○ パフォーマンスアップ、省リソース的にはあんまり効果無 し。安定はした。 ● jobサーバ群をリプレースして強化
- 55. 昨年同時期の数倍 ● 週末の増量ペースが 1TB～2TB/日 ● 枚数にして～28万枚 ● 例の如くそのほとんどが夜間に集中 ● 9月のシルバーウィークの影響もあるとは言え、 これは正直想定外だった appサーバ、days DBがどちらもH/W性能の限界 (storage周りのDBは去年のSSD化で超余裕)。 ピーク時にアプリケーションサーバがまったく捌き きれず、断続的にダウンする有様。
- 57. さてどうする ● apache、passengerのチューニングでごまかし ごまかし ● staticファイルのサーブをnginxに変更 ● days DBにindexを足すが、目立った効果はな し ● サーバを発注したが、納品は数週間後 数週間はもたんよね。
- 58. YAPC::Asia フォトスポンサー 2週間後に開催されるYAPC::Asia 2011 のオフィ シャルフォトスポンサーにご指名して頂いていた。 このままだと絶対にDisられる。というか申し 訳ない。 とりあえず見れないのはやばい。見るだけでもなん とかしなくては。
- 61. 孫slaveが必要だった理由 ● masterが限界なので子slaveを増やしたくない ● 子slaveなインスタンスがいくつか兼任してたの で出来るだけ落としたくない ○ ldapサーバ ○ puppetサーバ ○ セッションストレージ(kyototycoon) ● だが、DBのスケールアップ(ダウン)は柔軟に行 いたい。
- 62. 子slaveはxtrabackupで作成(1) 1. EC2インスタンスに別ディスク(EBS)をmountし とく mount -t ext3 /dev/sdf /tmp/mysql 2. DC側のslaveからxtrabackupで直接データ転 送 innobackupex --user root --password=xxxx --slave-info --stream=tar4ibd --defaults-file=/etc/my.cnf /tmp/mysql | gzip -c |
- 63. 子slaveはxtrabackupで作成(2) 1. EC2側のslaveで差分ログ当てる innobackupex --apply-log --ibbackup=xtrabckup_51 /tmp/mysql 2. データ差し替え mv /var/lib/mysql{,.bak}; mkdir /var/lib/mysql umount /tmp/mysql; mount /dev/sdf/ /var/lib/mysql chown -R mysql. /var/lib/mysql 3. mysqld 立ちあげてxtrabackup_slave_info の 内容で change master 実行
- 64. master > 子slave間はSSL(1) 1. CA証明書、証明書、秘密鍵を作成 2. master側で設置、設定 [mysqld] ssl-ca = /var/lib/mysql/ca-cert.pem ssl-cert = /var/lib/mysq/server-cert.pem ssl-key = /var/lib/mysql/server-key.pm
- 65. master > 子slave間はSSL(2) 1. slave側にも同様に証明書を設置 2. ssl有効化 CHANGE MASTER TO MASTER_SSL = 1 MASTER_SSL_CA = '/var/lib/mysql/server-cert.pem'; 3. 実際にやりとりを確認 tcpdump -nxX -s 1000 port 3306
- 66. 孫slaveはEBSスナップショットで(1) slaveのdata_dirは別disk(EBS)なので、スナップ ショットから簡単につくれた。 1. slaveで ○ stop slave io_thread ○ mysqld stop ○ my.cnf に log_slave_update 追記 2. EBSスナップショット作成 3. スナップショットからEBSを複製 4. slave で ○ mysqld start
- 67. 孫slaveはEBSスナップショットで(2) 孫slaveで 1. 複製したEBSをmount 2. mysqld start 3. stop slave; reset slave 4. change master 5. slave start 楽だ。
- 68. セッションストレージ MemcachedからKyoto Tycoonに変更 ● dual master ● memagentを使ってactive、backup構成に ○ DCのクライアント(rails、perlbal)は ■ DC上のをactive、 ■ EC2上のをbackupとして指定 ○ EC2のクライアントはその逆 ● データは暗号化
- 69. DCとEC2のセッション共有(with memagent) app001 app002 app201 DC AWS ここ Perlbal Perlbal Rails mem agent KT Rails Rails KT mem agent mem agent
- 71. 危機を乗り越えた ● とりあえず閲覧に関しては安定 ● アプロードもDC側で専念出来るのでマシに ● 知る限りではDisりもなし
- 73. 平和がもどった システム安定後、ゆっくりと ● mysql5.1から5.5にバーションアップ ● ファイルフォーマットをbarracudaに変更 ● フロントのプロキシをperlbalからnginxに変更 ○ perlbalが無くなったわけではなくnginxからperlbalとrails に振り分ける形 ○ perlbalは画像に対する認証も行なっているので簡単に は置き換えできない 等を行って更に安定し、めでたく一億枚を超えまし た。 めでたしめでたし。
- 76. まとめ ● 実は成長してないのかもしれない ● 忙しくてもパフォーマンス監視だけは忘れずに ● SSDマジ強い ● (特に)足場であるDBは早めの増強を
- 77. 質問あるかな
- 78. ご静聴有難うござ いました。