Perlがメインじゃない現場でもPerlを使う(AdTech現場編)
masartz@VOYAGE GROUPYAPC::Asia 2015 08/22
自己紹介• masartz
• http://search.cpan.org/~masartz/
• https://github.com/masartz
• VOYAGE GROUP adingo -> fluct
先ほどのセッションに続き確認ですが、 こちらでお間違いではないですか?
結論• 言語が変わっても求められる事は変わらない
• 言語に関わらずできること/しなければならないことはある
• 無駄な部分はなるべくなくしていこう
• そのために自分の持っている技術を使い、またその技術の幅を広げよう
前提
• What’s SSP?
• What’s fluct?
• How Architecture Works?
What’s SSP
メディア(媒体) SSP
Adnetwork
or
DSP
広告主
What’s fluct
本日のお品書き1. Perlの現場でやってた事を
PHPの現場でもやった話
2. PHPの現場で書いたものをPerlにバックポートした話
3. Rubyの現場で暫定対応をPerlでやった話
4. まとめ
Perlの現場でやってた事をPHPの現場でもやった話
共通している課題
• 「こうしたい」、「こうなったら良い」に対して現状がそれを阻む制約を抱えている
• 何らかの線引きをしないと、制約は加速していく
「現状○○なんだけど、いずれxxしたい」 という時のアプローチ
http://techlog.voyagegroup.com/entry/2015/05/01/150606
何をしたか?どうなったか?• 媒体社様向けの管理画面用リポジトリにおいて、PSR-2に沿う事をコードレビュー時に目視確認と手動修正によって行っていた
• 既存ファイルを全て修正して、php-cs-fixerが使える状況を作った
• 開発時に機械的にPSR-2に沿えるようになった
Perlの現場では?• 古いライブラリで、社内のガイドラインに沿ってないファイルがたくさんあった
• Test::CodingStyle( https://github.com/mixi-inc/p5-Test-
CodingStyle )という仕組みを作り、既存ファイルをblacklistに入れて分別するようにした
• 新規分は必ずガイドラインに沿えるようになった
• http://www.slideshare.net/masartz/yapc2013-26481517/21
PHP環境 Perl環境
課題 コードレビュー時に毎回発生する確認&修正コスト
増え続けるライブラリのメンテナンスコスト
現状 PSR-2に則っていないファイル群(550)
社内ガイドラインに沿ってないファイル群(10,000)
対応 既存全てのファイルにphp-cs-fixerを適用した
Testツールを作って、既存ファイルはblacklist扱いにした
結果 make php-cs-fixer test running
この話のまとめ• 対象リポジトリ配下全てがPSR-2に沿った
• 対応リリース過程で障害に繋がったケースはなし
• 大切な事は、明瞭な規約に沿う事にコードを統一できたことではない
• 人がやるべきではない作業を機械にやらせるようにした
PHPの現場で書いたものをPerlにバックポートした話
共通していること• 開発者がcrontabをうっかり書きミスること 例)19時00分にだけ動いてほしい場合 誤: * 19 * * * php hoge.php 正 : 0 19 * * * php hoge.php
• cron.txt っぽいファイルで設定を管理している
• crontabの解析用のライブラリが既にあることによって少ない工数で、テストが書ける
・http://masartz.hatenablog.jp/entry/2015/08/04/203331 ・http://www.slideshare.net/masartz/lt-open-45508527
何をしたか?どうなったか?• crontabの設定をうっかりミスってしまい、障害が起きてしまった
• 書きミスがちょっとだけ防げるdoctest (or Test::Base)っぽいテストを書いた
• テストが落ちることで、うっかりミスに気づけるようになり、簡単な再発防止策となった
* 19 * * * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00
これだと、テスト落ちる
0 19 * * * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00
これだと、テスト通る
Perl版は?
• Test::Parse::Crontab::Simple
• http://search.cpan.org/~masartz/Test-Parse-Crontab-Simple-0.01/
10 19 * * * perl hoge.pl ###sample 2014-12-31 19:20:00
これだと、テスト落ちる
*/10 19 * * * perl hoge.pl ###sample 2014-12-31 19:20:00
これだと、テスト通る
PHP環境 Perl環境
課題 開発者がcrontabをうっかり書きミスる
現状 Cron Expressionがある Parse::Crontabがある
対応 Cron Expressionを用いたテストファイル Test::Parse::Crontab::Simple
結果 うっかりミスに少しだけ気づきやすくなった
何故Perlに移植したか?
• PSGI,Plack,plenv,Carton etc…
• 近年のPerlの成長は他言語からの流入が大きい
• 他言語で得た知見をPerlに還元するため
ここで半分ちょっと越えたくらい
Rubyの現場で暫定対応を Perlでやった話
Which situation?
メディア(媒体) SSP
Adnetwork
or
DSP
広告主
Adnetworkからfluctへの入稿
何をしたか?どうなったか?• 入稿するJavascriptタグを多重登録してしまうオペレーションミスがしばしば起こっていた
• 重複検知のための要件定義をPerlで行い、定常運用版をRubyで書いた
• 重複が発生した場合、アラートメールが届き、 重複を解消できるようになった
Which situation?
既存分の修正
既存分抽出及び定常バッチ用
スクリプト作成&修正(Ruby)
要件定義&既存分の精査
オペレーションG エンジニア
警告発生時の 修正フロー開始
定常バッチ化リリース
要件が曖昧で、見積もりにくい
クリティカルパス
メンテナンス
この案件のキモ• 要件定義をできるだけ早めて、早く次のフェーズに進むこと
• 一旦現状をクリーンにしてから、異常があった場合のみメールが発砲されるようにすること
• 現状を鑑みて、冗長体制かつ、少ないメンテナンスコストで運用できるようにすること
既存分の修正
既存分抽出及び定常バッチ用
スクリプト作成&修正(Ruby)
要件定義&既存分の精査
オペレーションG エンジニア
警告発生時の 修正フロー開始
定常バッチ化リリース
既存分の修正
既存分抽出スクリプト作成&修正
(Perl)
要件定義&既存分の精査
オペレーションG エンジニア
定常バッチ化開発(Ruby)
警告発生時の 修正フロー開始
定常バッチ化リリース
この話のまとめ• 現状、通知メールが来ると「おっ?」って 思える運用フローになっている
• リリース後稼働しているRuby版は冗長なメンテナンス体制が取れている
• 案件の性質を理解し、より良い手段を取ることが大事であるということ
全体のまとめ• 言語が変わっても求められる事は変わらない
• 言語に関わらずできること/しなければならないことはある
• 無駄な部分はなるべくなくしていこう
• そのために自分の持っている技術を使い、またその技術の幅を広げよう
告知タイム
http://voyagegroup.com/crew/recruit/
Thanks YAPC::Asia!