Wantedly 開発チームブログ
こんにちは、川崎です。Wantedlyに参加して4年が経ちました。
今回は、Wantedlyのサービスの現状について、システム的な観点から紹介したいと思います。
利用ユーザ数は月間90万人、利用企業数は15000社を超えました。自分が始めた頃は、月間1万人、利用企業数150社ほどだったので、4年間でおよそ100倍に成長した計算になります。
サービスとしては、「働くすべての人のインフラへ」というスローガンで大きく2つの挑戦をしています。1つは創業当初から取り組んできた「会社と人の出会い」を生み出すマッチング事業を、さらに大勢の人に使ってもらえるようにすること。わかりやすく言えば、採用・広報媒体としてのサービスです。
そしてもう1つは、WantedlyのビジネスSNSとしての側面で価値を提供し、会社の枠を越えた「人と人のつながり」を加速させていくこと。
どのような思想で取り組んでいるのか、その背景は先日WIREDに掲載された記事によくまとまっています。
ちなみに、数カ月前にリニューアルした www.wantedly.com のトップページのデザインは、それを色濃く反映させた内容となっています。
ビジネスチャットSyncは2015年5月から開発を始めました。平均すると6人ほどのメンバー、期間は半年ほどで、ウェブ・デスクトップ・iPhone・Androidのアプリを開発しました。
開発開始時点では、Wantedlyは所謂モノリシックなアーキテクチャ、単体のRailsアプリとして開発されていました。ここでは本体アプリと呼ぶことにします。この構成は、チャットを開発していくにあたって、いくつかの課題がありました。
リアルタイムなチャットにとって、システムが高速であることと安定していることは「機能」であると言っても過言ではありません。数年間開発を続けて肥大化しているため、本体アプリの平均のレスポンスタイムは 200ms を超えていて(当時)、チャットのバックエンドとしては遅すぎると考えました。また、多い時で1日に10回以上デプロイをされているのですが、全体に影響する障害がどうしても稀に発生してしまいます。
また、開発効率も大きな問題でした。新規プロダクトということで、少しでも早く動作するプロトタイプを作り、それをマーケットにだして価値を検証していくことが求められます。30人近い開発者が変更していおり、当時、CIサーバでのテスト時間は40分を超えていて、スピーディーに開発を続けるにはつらい状況でした。また、モジュール間の相互影響や全開発者への影響を考えると、気軽にライブラリやフレームワークを新しく導入することが出来ませんでした。
以上を踏まえて、SyncのAPIサーバは、本体アプリと切り離して新しいアプリサーバとして開発することにしました。
新サービスとはいえ、ベースとなるユーザーやソーシャルグラフのデータは共通なので、既存のWantedlyアカウントで利用できるようにする必要があります。そこで、将来のさらなる複数サービス展開も視野に入れて、ユーザ認証とOAuth 2の認可を担当するRailsサーバを作成しました。具体的には、doorkeeper gemを利用しています。
メインとなるチャット用のAPIサーバもRailsで書かれています。Railsのパフォーマンス上の懸念はありましたが、リアルタイム通信のためのwebsocketを直接自分たちで用意せずMBaaSのFirebaseを使うことにしたこと、シンプルなRailsアプリにすることで許容範囲のパフォーマンスがだせそうなこと、慣れている技術を使うことによる生産性の高さを考慮して、Railsで開発を進めました。将来的にスケールさせていくためには、リアルタイムメッセージング・並行処理に実績のある別の言語を検討していくことになります。このJSON APIサーバの実装には、garage gemが活躍しました。
下の図では省略されていますが、チャットグループの参加者の画像を1枚の画像にまとめる(LINEやFacebookメッセンジャーと同じ)画像合成サーバや、ウェブフロントエンドを配信するNodeサーバが、その他に存在します。
このような構成にすることで、Syncは少人数かつ高速な体制での開発を実現し、また将来のシステム進化に備えることができました。
続きます。次回はOpen APIと会社フィードについて書きます。
Wantedlyでは「働くすべての人」に価値を提供するために、新規プロダクトに取り組むサービス開発エンジニアを積極募集しています。少しでも興味のある方は話を聞きに来て下さい。お待ちしています!