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！