Yapc::Asia_2012

大きくなったシステムの疎結合化への取り組み

[email protected]

YAPC::Asia 2012

○ 星野将(id:masartz)

○ 株式会社ミクシィ

○ 技術部たんぽぽGたんぽぽT

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

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

Self Introduction

2

○ mixiサービスの歴史と現状

○ 疎結合化のアーキテクチャ

○ ライブラリ管理

○ ガイドラインとテスト

○ まとめ


Agenda

3


4

mixiサービスの歴史と現状

○ サービス開始(2004年)から表も裏もperlであることは変わっていない

○ あるときオープンソース化したことで、そこのライブラリは変更した

○ 特徴

○ ライブラリ・モジュール群が複雑に絡まりあっている ● 影響範囲が広いor読めない

● 開発効率が落ちる or 予期せぬ障害が発生する

○ レガシーな記述や歴代のコーディングスタイルが混在している ● メンテナンスコストも高い

● ack しまくり


mixi’s History

5

○ しかし、、、それを一口に悪と言うだけでは良くない

○ 長く続いているサービスでは仕方ないこと

○ たくさんの開発者がいるサービスでは避けられないこと

○ 皆様にも共感いただける内容になっているのではないかと思います


mixi’s History

6


7

疎結合のアーキテクチャ

○ Service Procedure

○ Web+DB vol.62 に掲載

○ モジュール間を仲介するための疑似的なRPC

○ 直接useすることで生じる依存関係を解決する

○ ×：Mixi::Diary -> Mixi::User::get_profile

○ ○：Mixi::Diary => Mixi::ServiceProcedure::call(‘user.profile.get’) => Mixi::User::Adapter::Profile -> Mixi::User::get_profile

○ 横断的なインターフェースの一覧がYAMLで管理される

--- methods: getEntryBody : Mixi::Voive::Adapter::Entry inertComment : Mixi::Voice::Adapter::Comment

○ 内部実装の変更をProcedureで吸収or確認することができる


Architecture of loose coupling

8

○ 各レベルのAPI一覧

○ InternalAPI ( 別の名前空間向け）

○ CoreInternalAPI ( 内部切り出しのサービス向け） ←今回の話はコレ

○ InternalGraphAPI ( 公式アプリなど向け）

○ GraphAPI ( SAPなど向け）


Architecture of loose coupling

9

○ mixiのサービスは1つのリポジトリによって運用されている

○ メリット

○ 既存資産

○ 開発ノウハウ

○ デメリット

○ リポジトリの肥大化

○ 影響範囲の拡大

○ 新しいトライへの障壁

○ このデメリットの部分に対する一つの解として、必要な情報のみをAPIとして提供するための機構がCoreInternal


CoreInternal API

10

○ ミニマムなサービスを手軽に構築することを目的とする wwwサーバー、DBサーバー、memcacheなどのリソースも専用化する

○ APIサーバーはhttp通信

○ 現時点では生のPlackサーバー

○ リクエスト/レスポンス ○ JSONRPC


CoreInternal API

11

○ 導入実績

○ 社内用ベータサービスなどで実験導入中

○ 既存システムに混じっていた小規模サービスの切り出し（途中）

○ 課題

○ リソースの専用化と資源配分

○ 負荷面のパフォーマンス計測

○ 既存資産が活用できない

○ 使いどころ

○ 新規サービスをミニマムで構築する場合

○ 言語や環境の縛りを超える場合


CoreInternal API

12

○ ここまでで半分ちょっと


Once the break

13


14

ライブラリ管理

○ Inspect Package

○ http://alpha.mixi.co.jp/2011/10767/

○ 名前空間ごとの技術的負債のスコアを算出する

○ 結合度、複雑度etc

○ 導入された以降、いくつかの改善対応が行われる

○ Service Procedureを用いたリファクタリングetc

○ 究極的なゴールは結合度・複雑度がゼロになること

○ その始点として現在の数値がいくつなのかを「見える化」するツール


Library Maintenance

15

○ 対応が進むと、経過差分が見たくなる ○ 社内wikiではいくつかのチームがコマンド実行->結果貼り付けをルーチン化 ○ そういう作業を自動化するのがたんぽぽの業務

○ 過去に遡った履歴の取得 ○ 取り組んだチーム管轄以外も含めて全ての名前空間分を収集

○ 時間軸：過程も含めた「見える化」を行える

○ モジュール間の横軸：全社的な状況把握と対応の優先度づけを行える


Library Maintenance

16


17

ガイドラインとテスト

○ コードレビュー業務とコーディングガイドライン

○ http://alpha.mixi.co.jp/2012/10870/

○ コードレビューによって、一定の安定度・統一性が保たれてきた

○ しかし最近は、中央集権的だったコードレビューの一部

（特定名前空間のみ対象）を各チーム内に権限移譲

○ 組織：小さな組織で小さなサイクルを回すため

○ コード：疎結合化により、コード修正の影響範囲の局所化が進んでいるため

○ 通常レビュー、チーム内レビュー問わず同様の品質を保つ必要がある

○ →ガイドラインを整理する／ガイドラインに沿ったレビューをする

○ ー→ガイドラインを厳守するためのテストを書いて自動化する＝品質担保をできる限り自動化する


Guideline and Test

18

○ 自動化できるガイドライン項目を洗い出す

○ 内容に沿ったテスト内容を書く

○ 現状では正規表現系が主

○ リポジトリの主要ディレクトリ配下全てを再帰的に対象とする

○ 既存のモジュールでテストが落ちるものをブラックリスト化する

○ 上記内容を設定ファイルっぽくしたファイルを作っていく

<モジュール> <設定ファイル>


Guideline and Test

19

○ 設定ファイルっぽいテスト項目ファイル群をまとめてテスト実行

○ テスト項目（の一部）

○ @EXPORTの使用

○ requireの使用

○ 非推奨モジュールの使用

○ ループ用途でのmap,grep使用

○ etc…

○ 中には140個程度のpmがブラックリストに列挙されたものもある

○ 大事なのは、既存に引っ張られずに、悪さに歯止めをかけること

○ 新しいものをダメにしない

○ ダメなものを洗い出して、直していく

○ 「いつか良くなるだろう」は甘え


Guideline and Test

20


21

まとめ

○ システムが長く運用される上で、肥大化・複雑化することは仕方ない

○ 「リーダブルコード」の『ネストを浅くする』の項

○ 例えば1日1回if文を追加する

○ 例えば1日1回モジュールをuseする

○ →普段何気なく行っていることの結果起きること


Conclusion

22

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

○ 道筋となる土台を作る

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

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

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

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

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

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


Conclusion

23

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


Thanks

24


25

Yapc::Asia_2012

Technology

Transcript of Yapc::Asia_2012