Yapc::Asia 2013

大きくなったシステムを元に新たな環境を作る取り組み
masartz@mixi.inc
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

○ 去年のおさらい
○ 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

Yapc::Asia 2013

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (14)

Destaque

Destaque (7)

Semelhante a Yapc::Asia 2013

Semelhante a Yapc::Asia 2013 (20)

Último

Último (9)

Yapc::Asia 2013