第3回ペパボテックカンファレンスに参加してきたメモ #pbtech

10年動き続けているブログサービスのエンドツーエンドを書いた記録

ペパボ技術部
http://www..shu-cream.com

電車で携帯忘れたときの知見と共有
プロダクトオーナーシップに関する社内勉強会をはじめました

なぜテストを書くに至ったか

NyAh
- プレイベーとクラウド基盤へ移設する
- JUGEM移設のPO的なポジション
JUGEMU
- 10周年
- PHP/MySQL/Ruby/Perl
- 15個のリポジトリ
- サーバのロールは18ロール
- porral
- JGセット（ユーザ毎のブログでWEBとDBの組み合わせ。39セット）
- バッチ
- 外部、内部連携用API
- 顧客管理、etc
JGセットの移設
- 数が多い
- ユーザ影響が大きい
- カスタマーサポートも巻き込む必要が

エンドツーエンドでテストやってしまおう

新規構築のリリース前にしようするチェックリスト
手動、目視の350
Trnip(Ruby/自然言語)
Capybara(バックエンド)
poltergeist(PhantomJS)
どうやってテストを書いたのか
キューカンバーをイメージすると良い
自然言語でテストで書く事に意味があると感じている
識別可能な名前をユーザ目線でつけれる、共通のワード
複数の処理にまとめて日本語で名前をつけれる
実例とテクニック
- ステージング、リリース前の本番環境に実行する
- DBに直接接続しない
- debug用のステップを作る(よくおちる時の切り分け)
- ステップを再利用できるようにする
- 無料ユーザで１日の投稿上限数が決まっている場合
- DBを直接触れないのでリセットできない
- 普段は実行せずタグで制御
- データのリセットは削除操作を繰り替えす
- evaluate_scriptでjavascript経由でデータを受け取れる

取り組みのまとめ

よかった点
- アプリケーションの動作をよく理解できる
- stepをうまく作れるとシナリオをどんどん足せるので気持ちいい
つらかった点
- javascriptを多用した記事エディタの難しさ
- phantomJS or capybara-webkit
全部テストいける？
- どうしようもない部分は手で実行する必要があるとわかった
- flashができない
日本語で書けるというので外側がキレイになる

MogileFSをバックエンドとしたPrivate S3の作り方

インフラ編

private Cloud(openstack)に移行中

主に画像、容量が大きい、各サービスが個別にもっている
- 例えば30days alubum 2008年リリース / 750TB / 22億
- 横断的なオブジェクトストレージが必要
計画メンテを除いたサービス断はなし
大規模運用で安定運用するのは甘くない。swiftは見送った
MogileFSは既存で使っていた
S3はコスト面で見送った。従量だけで月数百万
Baytと名付けた

ストレージサーバとフロントエンド

nginx + ngx_mruby
インターネット、インターナルからリクエストを受ける
apiにproxy
apiだけでは出来ないあれこれ

api

rails, unicorn
その前に既存システムの安定稼働(負荷が増える/パターンも変わる)を
メトリクスの充実化、可視化(munin/kibana/big query)
storageサーバの高集積化（47でバイス, 170TB, dev/starまである）
DB(MySQL)サーバのリプレース
- 2台から3台
- 5.1->5.5
- MHA #### mogilefsdクラスタの強化
- スペックアップと台数強化

mogilefsdがスケールしない

マスタープロセスとワーカを増やすpreforkモデル
子がすくないうちは大丈夫
増やすと全体的に不全状態に
renice -20 -p 親（プロセスの優先度を最大に）
- 改善！
- ただし、副作用が
- 子が-20になる・・・
- cronで親子のnice値の面倒をみることで解決
DBが刺さる問題
- 5.5以降デッドロックが
- 負荷がじりじり上がる
- MHAマネージャからの
- 元々使われてなかったindexが使われるようになった
- drop

既存の画像配信の品質向上

30%ほど高速化（資料参照）

gateway

実URLへのreproxy処理
x-reproxyヘッダに実態のURLを２つ入れて返す
Gatewayが実態のあるURLに取りに行く
apiへproxy / ヘッダみて再プロキシ(re-proxy)
APIが返したヘッダとクライアントに返すようにしないといけない
APIに届かなかった場合のエラードキュメント(bodyだけでなくstatus codeも)
ngnx + mruby
- server: bayt
- リクエストUUIDの発行
- HMAC認証をskipさせるヘッダを付与
- ngx_mrubyのオーバーヘッドはほぼ無い
- 太らない。活発な開発。劇的改善。

既存データのインポート方法

S3互換なのでクライアントの実装はそのまま使える
ETag(md5値)保存用のカラム追加
path(object key)カラムのサイズを255->512へ
約9億レコードのテーブルへのALTERで最長25時間

今後の予定

全サービス移行
マルチロケーション
動的画像リサイズ機能

API編

オブジェクト->ストレージのデータ
MIMEだったりmysqlのデータ
GET/PUT/POST/DELETE

API設計

新しくAPIを設計する？
- 設計するのいやだな・・・（時間に耐えうる設計の重さ）
- サーバサイド＋クライアントの実装。多種多様な言語
S3互換APIにしよう
- aws-sdk等OSSクライアントを利用可能
- HMAC認証等、再実装が煩雑なものが揃っている
API実装もいろいろ
- とはいえ、mogilefsをバックエンドとして流用できるものはさすがに
S3互換の制約
- S3 APIができる事だけ提供
- API自体の拡張は難しそう。SDKをいじるのはきつい
S3はREST APIのドキュメントが公開されている
さくらのオブジェクトストレージのリファレンスを先に読むとS3互換でよい

MogileFSクライアント、MySQLクライアント

HTTPのハンドリング
XMLのパース、HMAC認証
perl-catalyst APIの稼働実績がある
ペパボでperlの継続的開発ができるか
MogileFSクライアント
- perlが本家、rubyはunicornの作者製
- ラウンドロビン機能、高速に動く工夫の観点でrubyで

S3をリファレンス実装とするとバグレポートのやり取りが楽

HMAC認証はrubyに落とす
HTTPルーティングも作る。501 Not Imprementでちゃんと返すように。
metaテーブルを扱うのは１テーブルのみ
オブジェクトのCRUD
- CRUDを1コントローラ、1トランザクションとして作る
- S3仕様のレブポンスボディ(XML)

S3にディレクトリは無い。common prefixesです

list objectはLIKE検索とNOT LIKEと ">"で
rails-apiでダイエット
APIチューニング。XMLの生成がちと遅い
builder, nokogiri, oxで比較
oxが早い
GETはmogilefsのオーバーヘッドが乗るので遅い(100ms)程度

H2OとPHPの話

H2O
- HTTPを早速サポートしている
- デフォルトで高速 − まだ情報が少ない

高速でメモする余裕がなかった資料参照(?)

歴史あるwebサービスに携わって２年半の間に起きた事やった事

カラミーショップのエンジニア − 10年続くサービス − 対部分はPHP、railsでAPI、AngularJS

入社当時（2年半前）

Trac使ってた − レビューなし − SVN＋git-svn
deployはwebistrano
素のSQL
テストは特になし

GitHub Enterpriseを使うようになった

− 全社的に導入
− SVN＋git-svnからの脱却
− レビューするようになった
− 順番にレビュー当番。共通認識。
− PSRを意識するようになった

PHP-CS-Fixer
githubで?w=つけるとレビュー便利だよ
- javascriptの else if -> elseif

テストの導入

− E2Eテストが作られた
− RSpec + capybara
- ユニットテスト
- PHPUnit

composerが導入さられた

− ライブラリを探してバージョン管理
− deploy時にcomposerインストールする

ローカル環境が構築された

vagrant + puppet
今まではMaglica上でそれぞれ作ってた

Wheneverでcronの変更を自動化

crontabを管理してくれるGem
コードにcrontabの設定を落とし込む。もちろんレビューも。

MySQLバージョンアップ

4.0->5.1->5.6
Eloquent ORM(Larvelについてくる)
もう昔の素のSQLには戻れない

画像サーバをFTPからBaytへ

− BaytとはS3互換のストレージサーバ

尋常じゃない速度でドッグフードを食べる方法

sqaleというサービスの話
ruby on railsのアプリケーションを利用するためのプラットフォーム − ドッグフーディングとは − 自社の製品を自分たちで使ってより良くしていいくこと

− 良い所・便利なところが見えてくる
− 新機能が出たらすぐに自分の小さなアプリをデプロイ

ネットが切れたので途中・・・

今夜、インターネットの片隅で。〜ウェブサービス開発ちょっといい話〜

カラミーショップ − ショッピングカートを全部作り直す − エンジニアが４人 − いい話一覧を話す

ショッピングカート

− 住所入力が2個あるとかも意味がある
− デジタルコンテンツだったらいらないのに
− その人に最適な情報入力を出せばいいじゃん
− 指針が大事。作る
− 哲学フロー開発

やぷしぃおもしろきかく！網羅パーソン総選挙

− 銅鑼で投票
− conoha(VPS)
- PHP/MySQL/KVSなし
− Nginx -> H2O

PHPでできないことは実装をあきらめる（速度重視と実装コスパ） − 1200万投票 − PHP安定してるじゃん − DBが太ってストレージが溢れる − 自動化してAPI叩きまくる人

OS X アプリケーション開発普及活動

− Cocoa Programing
- 経験は1年、teitenをリリース
− WWDC2014に参加
− NextSTEP

資料参照の方が良さそう

仮想通貨自動トレード記 Part1 〜国内Bitcoin取引所で裁定取引したら儲かるの？〜

− JUGEMの開発している人
− もっと世の中に仮想通貨のすばらしさを広めたい
− Hubotとslack
− ２つの国内取引上の板の差を判断し約定させる
- bugで損した
− 改修してみた。またBugが。
− promise/async
- hubotの開発はcloud9
- slackは絵文字でわかりやすくしよう