Yapc::Asia 2013

大きくなったシステムを元に新たな環境を作る取り組み

[email protected]

YAPC::Asia 2013

○ 星野将(id:masartz)

○ 株式会社ミクシィ

○ 技術部たんぽぽG

○ No More 「刺身の上にタンポポをのせる仕事」 - 単純作業の繰り返しで開発者の時間を浪費しないために

○ https://securityinsight.jp/interview/27-whitehats/490-matsuoka_takeshi

Copyright (C) mixi, Inc. All rights reserved.

Self Introduction

2

https://securityinsight.jp/interview/27-whitehats/490-matsuoka_takeshi





○ 去年のおさらい

○ mixiにおけるPerlの使用状況

○ スマホアプリ開発のための基盤構築の取り組み

○ 外部化したCPANモジュール

○ まとめ


Agenda

3


4

去年のおさらい

○ あるべき姿に向けてどういうアプローチをとっていくか

○ 道筋となる土台を作る

● SeviceProcedureモジュール、CoreInternalAPIサーバー

○ ゴールまでの距離を計測する

● Inspect Packageツール／ビジュアライザ

○ 今以上に悪くならないよう歯止めをかける

● ガイドラインテストツール

○ 最終的にはエンジニアの手によって計画的に改善していく


Review of YAPC::Asia 2012

5


6

mixiにおけるPerlの使用状況

○ 2004年2月：mixiのサービス開始

○ 当時のPerlの最新バージョン：5.8.8

○ ～このまま7年ほど過ごす～

○ 2011年頃からOSとPerlのアップデートプロジェクトが開始

○ OSをアップデートする

● そのためのPerlをアップデートする

○ /usr/bin/perl からの脱却

● /usr/local/perl-5.14.4/bin/perl の使用

○ 今後のバージョンアップもスムーズに行えるハズ

● 実際に、5.14.1 -> 5.14.4 へのマイナーバージョンアップは実施済み

○ モジュール管理にcartonを利用

○ などなど対応した2013年9月現在は5.14.4で稼働中


mixi’s Perl version

7

バージョンアップの対応手順

○ perl 5.14 + アップデートしたCPANモジュールの環境のテストをフル実行 ○ jenkins を回しまくる

○ 落ちた所を順次潰す -> 再実行のループ

○ 網羅QAテスト ○ 単体テストの網羅率が100％ではない && 単体では見つからない部分

○ 本番環境に段階的に投入 ○ 最初は1台のサーバーにのみ投入し、影響範囲を最小化する

移行期間の開発作業

○ オプションで環境選択してApacheを立ち上げ

○ 同じくオプションつきでブランチをjenkinsでテスト実行

○ 移行後半にはtrunkのfull testを両バージョンで実施 ○ どっちかの環境で引っかかる問題が出たりする

○ HTTP::Status の RC_OK と HTTP_OK の互換性


How to version up of Perl

8

対応した問題の一部

○ CPANモジュール部分

○ Regexp::Optimizerにパッチを送る

○ Storable が正規表現リテラルをシリアライズしない

○ XML::Feedパッケージ内のレイアウト変更

● XML::Feed::RSS(0.23) => XML::Feed::Format::RSS(0.3)

○ List::MoreUtils::all の挙動変化

● perl -e “warn List::MoreUtils::all { 0 } qw()“

● 0.22 : Warning

● 0.33 : 1

○ Perlのコアな部分

○ かっことしての qw(...) の使用（例： Class::Accessor::Fast）

● ×：__PACKAGE__->mk_accessors qw/ hoge / ;

● ○：__PACKAGE__->mk_accessors( qw/ hoge / );


How to version up of Perl

9

バージョンアップしたPerl5.14の使い方

○ 基本的に増えた機能はどれも使ってOK

○ Defined-or演算子 //

○ 他だと package ブロック文法( package Foo {}) とか say とかが稀に

○ まだ積極的に色々使っている段階ではない

○ experimentalな機能は使用不可

○ push $array_ref , $value

○ ルールで縛っているだけなので、うっかり書いたのに気づけないのは課題

○ 【宣伝その1】5.14より先のPerlについては明日11:20から藤原洋記念ホールで発表がある「これからのPerlプロダクトのかたち」で！


How to use Perl 5.14

10

mixiのコアライブラリの切り出し ○ 設計レイヤにおけるcommon library層のモジュール群が対象

○ 専用の名前空間をトップレベルで設ける ○ そこの名前空間ごと別リポジトリ化する ○ 対象モジュール

○ Encoding ○ DB操作（分散環境を考慮したconnect から SQL発行まで） ○ Log出力 ○ Convert( YAML , JSON => perl-object) ○ その他いわゆるUtil的なものなど（ String , Hash …)

○ 機能単位の疎結合化をしたり、新サービスを作るとき使うために


mixi’s core library

11

○ ここまでで半分くらい

○ 小休止


Once the break

12

powered by Cheering〜がんばるあなたを応援します〜

http://apps.mixi.co.jp/apps/cheering.html


13

スマホアプリ開発のための基盤構築の取り組み

○ mixiのスマホアプリ？

○ nohana?

○ Innovation Center発だから違うよ！

○ http://nohana.jp/

○ 色んな所でアプリ作ってます

○ 多くのアプリを作るための基盤を提供する

○ ミクシィ社が提供する共通アカウント管理サービスを実現する

○ 【宣伝その2】詳しくは明日14:50から藤原洋記念ホールで発表がある「スマフォアプリ開発を支える認証認可アーキテクチャ」で！


What’s mixi’s Smartphome Application

14


System Architecture

15

○ 各機能別層と外部とのI/FとなるAPI層の2つに大別される

○ 全体としてPSGI互換

○ API層

○ 外部（SDKやApplication Backend)との通信を行う

○ 通信方式はRESTful API

● REST通信の実現はRouter::Simple

○ 細かい所だと use common::sense

○ 薄いレイヤーなので、非常にシンプル

○ 各機能別層

○ アカウント基盤、Push基盤、etc…

○ API層との通信をJSON-RPCで行う（基盤同士の通信も同様）

○ RPCの通信モジュールは既存mixiのServiceProcedureよりも簡略化したもの

○ CoC（設定よりも規約）のポリシーで設計

○ それぞれの基盤のリポジトリが別れるため、明確に規約で縛って関係性を構築した方がスムーズだった


Basis Application

16

○ スマホ基盤開発においては全面的にGithub Enterpriseを使用

○ mixi.jpの開発はgit + gitweb

○ 数十人の開発者が多くのリポジトリ管理をしている

○ github.comのプライベートリポジトリとの比較

○ メリット

● 他のチームやプロジェクトのリポジトリへの閲覧・PR

● 任意のメンテタイミング＋ネットワークセキュリティ

○ デメリット

● リポジトリへのアクセス手段が限定される

● 他社と協業する際に社内ネットワークにアクセスさせることになる

○ =>ケースバイケースで使い分けている

○ 【宣伝その3】続きは明日13:00から多目的教室3で発表がある「GitHubでつくる、たのしい開発現場」で！


Develop Environment

17


18

外部化したCPANモジュール

○ useしてるけど、実は使ってないモジュールの検知

○ 書いたけどやっぱり使わなかった or 使っていた処理が消えた

○ 特に後者は長年メンテしているモジュールだと割とある

○ 中身は正規表現で頑張っているだけ ○ 正しく厳密にやるならPPIを使えばできると思う

○ 8割カバーできればOKと思ってサクっと作ったのがきっかけ


Open Source Software of mixi(Test::UselessModule)

19

○ sample_test.t

○ Todo ○ CLI ツール

○ 例外モジュールの追加方法

○ Repository ○ https://github.com/masartz/p5-test-uselessmodule


Open Source Software of mixi(Test::UselessModule)

20

○ 例外ファイルを管理しつつ、独自のルールでテストする

○ 昨年のYAPC::Asia2012でも触れたもの

○ 社内コーディングガイドラインドキュメント -> 自動化ツール

○ ルールファイルを追加して、テスト実行すると検知可能


Open Source Software of mixi(Test::CodingStyle)

21

○ 「これ以上負債を増やさないためにどうするか」というアプローチ

○ Test::Perl::Criticとの比較

○ 独自のルールを簡単に書ける

● 正規表現、PPIなど可

○ キモはblacklistとexcept_listの管理

● すぐには直せないものがたくさんあってもルールを追加できる

○ mixiはぶっちゃけどれくらいのファイル数なのか？

○ libの配下で「find . -type f -name "[^.]*" | wc -l」

○ 12000ファイル！

○ 変更のないファイルを見ないよう後に改修

○ Test::Perl::Criticも重いので、同じ仕組みを導入してる



22

○ 汎用的なモジュールか？

○ 実際、mixi以外の基盤プロダクトで使ってもらったフィードバック

○ Perl::Criticのルールの範囲内でなんとかなる

○ 独自のルールを適用する場合、管理する前に引っかかる箇所を全部直す

○ まとめると、「そんなに必要ない」

○ これはこれで全く正しい対応

○ それができないようなプロダクトだけで使えばいい

○ mixi並の規模で、全体把握ができない or 力技の修正が効かない

○ 案件が逼迫していてメンテ・リファクタリソースがない

○ Repository

○ https://github.com/mixi-inc/p5-Test-CodingStyle



23


24

まとめ

○ 新しい環境を作って得たものをmixi本体に持ち帰れるかが課題

○ ライブラリ・アーキテクチャ・開発環境

○ 割愛したスマホ基盤のインフラ部分にもいくつものTryがありました

○ Perlのバージョンアップに戸惑っている方、がんばってやりましょう

○ きっとできるはず

○ 使っているCPANモジュールとそのバージョンに注意

○ モジュールやプロダクトのオープン化をさらに進めて行きたい

○ 今更感はすごいありますが・・

○ 文化的な部分もあって、これまで注力していなかった

○ mixi本体の課題解決は特にこの半年は注力していなかった

○ mixiと新環境、両方を運用しつつこれに向かっていかなければいけない

○ その過程で出る課題や解決方法も、アウトプットしていきたい


Conclusion

25

○ ご清聴ありがとうございました


Thanks

26


27

Technology

Yapc::Asia 2013