コミュニティセントラル
登録

Fandomで広がる世界は無限大です。記事を編集したり、他のユーザーとライブチャットを楽しんだり、バッジを集めたり、コンテンツの整理に身を投じたり、あるいは大好きなトピックについてただ何時間も読みふけることもできます。 しかもそれを、デザインも内容も異なる36万ものコミュニティにわたってできるのですから、どれだけバラエティ豊かなのかは想像できると思います。

バラエティ豊かなコミュニティは、Fandomの大きな魅力のひとつでもあります。 その一方で、コミュニティの数が増えれば増えるほど、エンジニアやプロダクトマネージャーにとってコード化が複雑になるということも事実です。 そしてFandomでは、持てる技術の総力を上げ、年月をかけて巨大なコードベースを構築してきました。

数年前、Fandomでも熟練のエンジニアが数名集まり、このコードベースを分解して解析したいと申し出ました。 Fandomを支えているコーディングやその他の機能をもっと効率的に管理できる方法を模索したい、と彼らは言ったのです。 それができれば、今後のソフトウェア開発もさらに速く、円滑に行うことができることもわかっていました。 そしてこれまでベールに包まれたこのプロジェクトですが、ついにこれまでの大きな成果を発表できることになったのです!

今回発表するソリューションは、その名もサービス指向アーキテクチャ(通称SOA)。長年のWiki編集者(編集し始めて10周年になります!)、およびコンピュータープログラマーとして、この度はFandomのソフトウェア開発チームの舞台裏で行われているプロジェクトの概要を説明できる運びとなり、大変うれしく思います!

用語[]

Fandomが取り組んできた技術的な変更点を理解しやすくするために、いくつか大きなコンセプトを表す用語について説明しましょう。

MediaWiki: 2006年に設立以来、Fandomの基幹として存在する主要エンジンです。 MediaWikiはWikiの作成において重要な要素であり、編集のしやすさ、ユーザー作成コンテンツのプレゼンテーション、単純なユーザーグループ構成、または履歴の追跡や編集など、様々な機能を支えています。

現在のFandomはMediaWikiのバージョン1.19で運営していますが、今後大規模な更新を行う可能性は低いでしょう。 理由は、MediaWikiはあくまでも基板としての役割を持つソフトウェアだからです。 その上に構成されるMediaWikiのコーディングや設計などがシステムのコントロールを左右してます。 たとえば、編集した内容を保存する機能がページの削除を担うコードでもあるのですが、 これはほとんど、PHPとJavaScriptを通じて行われています。

技術的な観点で言うと、サービスとは、ひとつの共通タスクを実施する機能を表す小さなソフトウェアと定義されます。 どんな言語でもコード化することが可能です。 つまりサービス指向アーキテクチャとは、すべてを同時に実行するひとつの大きなソフトウェアではなく、ウェブサイト上のタスクを個別サービスを通じてひとつずつ細かく実施できるシステム設計を表すのです。

問題と課題[]

City (Civ3)

サービス指向アーキテクチャとはそれぞれ特殊な職業トレーニングを受けた市民のようなものです。(CiVシリーズの市民のようなものです!…あまり分かりやすくないですかね?)

これまでのMediaWikiモデルからSOAモデルに移る利点を理解するために、MediaWikiをひとつの大きな街だと想像してみてください。 街の住民は新しい建設から地域の取り締まり、商業施設の運営などのすべてにいたるまで、街の経済と安全を全員が支えなければいけません。 日常的な業務はそれぞれ問題なくこなせますが、突然そこで火災が起きた場合、消防士ではなく店主や警察官、あるいは建設現場の作業員が消防活動を行うのは、少しおかしな話になってしまいます。

今度はSOAモデルの場合、この街がどう機能するかについて同じ例を続けて見てみましょう。 SOAモデルの街では上記と違い、住民は建設なら建設だけ、警察なら警察だけ、あるいは店主なら店主だけ、といった個別の責任を持ちます。 つまり、やるべき仕事はひとつに絞られる、ということになります。 火災が発生したら、専任の消防士が現場に駆けつけます。 みなさまも同じだと思いますが、もし自分の家で火災が起きたら、パン屋さんではなく、消防士が来てくれたほうがずっと安心します。 まぁ、小麦粉を大量にふりかけて火を消すという発想もおもしろいかもしれませんが、それはさておき。

このような例で説明すると、なぜFandomがSOAモデルに変更したいか、その理由がわかりやすくなったと思います。

MediaWikiと比較してSOAの主な利点は次の通りです:

  • よりシンプルな構造 ソフトウェアエンジニアにとって、ソフトウェアの規模が小さく、コードも一箇所にまとまった構造のほうが問題の理解もしやすく、より速く修正と改善を行うことができます。
  • 効率性 SOAモデルではJavaやPythonなどのソフトウェア言語を扱うことができるため、PHPが不得意だったタスクのパフォーマンス向上が期待できます。
  • 適応性 MediaWikiはその巨大な規模が原因で、更新がどうしても遅くなってしまいます。 ですがインターネットを取り巻く環境の変化は早い速度で常に変化します。 上記の問題のため、モバイルアプリの開発など必須機能において、MediaWikiが遅れをとってしまっている現状があります。

何が変わったのか[]

驚かれるかもしれませんが、SOAモデルへのFandomの切り替えはすでに昨年から部分的に行っていました。 ただし、SOAモデルになるからといってFandomが豪華な見た目になるというわけではありません。 SOAは単純にFandomにおけるMediaWikiの働きを部分的に抽出し、効果と効率性の向上を目的にコードを再構築してから、コードをまた有効にするという作業になります。 コードを書き直す際に新たな機能を追加することはできても、見た目としての違いは特に気づかれないはずです。

良い例がFandomのアカウントログインシステムです。 信じられないかもしれませんが、この仕組みは昨年、かなりの変更を行った経緯があります! MediaWikiのユーザー認証は過去、Fandomほど大きなユーザーデータベースを効率的に扱えない場合があり、Facebookコネクトなどのアドオンを簡単に行えない状況が発生していました。 そのため昨年、FandomではHeliosと呼ばれる仕組みを作り、より速く、安全にユーザー登録とログインできるプロセスを可能にしました。 HeliosはMediaWikiとは別で存在するシステムであり、単純なAPIを通じてMediaWikiとデータのやり取りを行います。

また、ユーザーグループの権利設定や個人設定だけを扱うサービスも確立しました。 このような開発はほとんどすべて、モバイルアプリおよびモバイルウェブの中で行われています。 事実、今ではFandomユーザーはHeliosを使って簡単にモバイルウェブやモバイルアプリ上からFandomにログインすることができるのですが、既存のMedaiWikiの認証システムをモバイルツールとつなげるよりかは遥かに容易に実現できたのです。

今回の取り組みは、Fandomをさらに効率的なシステムに進化させるためのほんの始まりにしかすぎません。 最高の機能をより多く設計し、コード化を続けていく中で、Fandomの将来を見据えた成長を支えていくことをお約束します。 Fandomでのサービス指向アーキテクチャの開発についてご質問などありましたら、お気軽にコメント欄にてお寄せください!

スタッフブログが更新された際の通知の受信をご希望の方は、 こちらをクリックしてブログをフォローすると、通知を受信していただけます。