Perl Hackers Hub

第8回 Perlによる大規模システム開発・設計のツボ(2)

この記事を読むのに必要な時間:およそ 3 分

mixiのアーキテクチャパターン

2011年4月現在,mixiは2004年2月のサービス開始から7年以上をかけて,最適化,バグ修正,新機能リリースなどを続けています。⁠2)では,こういった状況の中で,安定したサービスをみなさんにお届けするために取り入れているアーキテクチャ設計上の工夫や,失敗を修正していくための品質評価手法を紹介します。

システムの境界と階層化

mixiでは個々の機能について,次のようなパッケージレイアウトを採用しています。

Mixi::Voice::*

つぶやき機能に関するモジュール群

Mixi::Video::*

ビデオ機能に関するモジュール群

Mixi::Diary::*

日記機能に関するモジュール群

Mixi::Home::*

ホーム表示機能に関するモジュール群

以降では,これらのモジュールの集まりを「コンポーネント」と呼びます。これらのコンポーネントは,相互に連携や結合を持っています。

システム自体が大きくなり,コンポーネント同士の連携が複雑になるにつれて,1つの修正の影響範囲がかなりの広範囲に波及することになり,変更に対して鈍重なアーキテクチャになりがちです。

階層化

そのためmixiではコンポーネント間の連携とその手段を制限していく方針を決めました。

まず始めに,各コンポーネントに与えられた役割を4つに分類しました。以降では,コンポーネント名とは別に,この役割の名前を<<役割名>>といった形で表現します。

<<application>>

1つの機能を実現するために必要なモジュール群

<<framework>>

システム横断的に利用するユーザデータの取得手段

<<service>>

<<application>>間の連携の仲介を行うパッケージ

<<common library>>

<<application>>,<<service>>に依存しないユーティリティ

これらは図1の結合のみを許すようにしています。この階層化の定義によって,既存のコンポーネント同士の持つ結合の良し悪しを明確にでき,リファクタリングを進めるための指針がはっきりとしました。

図1 コンポーネントの連携

図1 コンポーネントの連携

以降では,<<service>>に当たる各アプリケーション間の連携手段について紹介していきます。

設定ファイルによる依存性注入

<<service>> に相当するコンポーネントは,各<<application>>の持っている機能の利用を仲介します。この際,どの機能を利用しているのかという依存性は,必ず設定ファイルに記述するようにしています。これによって「依存の形」を限定できるうえ,それ自体がドキュメントとしての役割を果たすことができます。これは,Javaなどのフレームワークで見られる「依存性の注入」Dependency Injectionというテクニックを参考にしています。

著者プロフィール

広木大地(ひろきだいち)

筑波大学大学院卒業後,2008年度に新卒として株式会社ミクシィに入社。

広告システムの開発に従事したのち,システム本部たんぽぽ開発グループに所属。現在は「刺身の上にたんぽぽを乗せる仕事」を撲滅するべく,サービスアーキテクチャの設計/開発や技術者教育などを担当している。

YAPC::Asia 2010にて,mixiのアーキテクチャについての発表を行った。

コメント

コメントの記入