こんにちは、ウォンテッドリー株式会社でインフラエンジニアをやっている @fohte です。

筆者はウォンテッドリーに join して 1 年が経過しようとしており、ようやくウォンテッドリーが採用しているアーキテクチャについて全貌が掴めてきました。そこで改めてウォンテッドリーの技術スタックを考え直してみると、ウォンテッドリーのバックエンド領域において利用している言語はなぜ採用されているのかが気になりました。今回はそれを読み解くべく、過去から現在までに利用されている言語の比率から、その背景と歴史を追っていきます。

ウォンテッドリーで採用している言語とアーキテクチャの歴史

まずはじめに、ウォンテッドリーでは下図の技術およびアーキテクチャを選定しています。

(参考: 技術とアーキテクチャ - Wantedly Engineering Handbook)

本記事では、この図での "The System" の多くを担うバックエンド領域について深掘りします。

ウォンテッドリーのサーバーは全て Docker コンテナの中で動作し、Kubernetes 上で動いています。これらはマイクロサービスの単位で独立してテスト・デプロイされます。そのため、マイクロサービスの実装には任意のプログラミング言語を選択できます。また現在のウォンテッドリーでは、サーバーの実装に使われる主要な言語として Ruby, Go, Python が採用されています。

利用言語推移を見る

技術とアーキテクチャの歴史を追うために、"The System" を構成するマイクロサービスに用いられている言語の利用率の推移を見てみます。下図では、ウォンテッドリーが開発しているすべてのリポジトリにおける、バックエンド領域で利用している言語 (Go, Ruby, Python) の比率を一年ごと算出しています。

(余談ですが、この利用率推移の算出方法は Gist に書いています。)

初期 (〜2016 年)

ウォンテッドリーではもともと、単一の Ruby on Rails で開発されたモノリシックなアプリケーションで構成されていたため、Ruby がウォンテッドリーの最初期から利用されている言語となっています。図のように、2016 年まではバックエンド領域において Ruby の利用率が 100 % でした。

マイクロサービスアーキテクチャの導入 (2016 年)

大きな転換期として、2016 年にマイクロサービスアーキテクチャが導入されました。

そこで、マイクロサービスを開発する言語として Go も採用されるようになりました。Go は開発のリードタイムよりも安定性やスケーラビリティが求められる場面や、責務が明確なマイクロサービスの実装に利用されています。具体的な例としては、ウォンテッドリーで利用される画像の配信・アップロードするマイクロサービスは Go で実装されています。以下の記事でも、「なぜ Go なのか」「Go で成功・失敗したサーバーはなにか」などについて詳しく紹介しています。

なお、マイクロサービスの開発言語は常に Go とは限らず、例えば Ruby on Rails を採用している箇所もあります。例えば、ウォンテッドリーのユーザーを管理するための Ruby on Rails で開発されたマイクロサービスがあります。ウォンテッドリーの最初期は、Ruby on Rails で開発されたモノリシックなアプリケーションでしたが、現在ではそれらの一部がマイクロサービスとして分割され、継続して Ruby on Rails が採用されています。

また、この 2016 年には、新規事業として Wantedly People が開発されていました。Wantedly People には名刺の読み取り機能があり、それは機械学習モデルによって実装されています。機械学習には Python が適しているため、言語としては Python が用いられています。これはマイクロサービスアーキテクチャを採用した理由のひとつでもあります。

余談となりますが、現在の機械学習領域 (具体的には推薦領域) において、以下のスライドでも紹介している通りマイクロサービスアーキテクチャがうまく噛み合った事例もあります。

現在 (2024 年)

マイクロサービスアーキテクチャの導入から 8 年が経った現在のウォンテッドリーでも、引き続きマイクロサービスアーキテクチャが採用されています。また、言語の利用比率としては Go や Python の利用が増えていることが分かります。

Go は、前述のように画像の配信・アップロードするマイクロサービスが構築されています。またバックエンド領域とは離れますが、Kubernetes 自体が Go で実装されていることから、内製 kubectl wrapper である kube や、custom controller (例えば kubefork) の実装においても利用されています。

Ruby は依然としてウォンテッドリーの中核を支える主要な言語となっています。Wantedly Visit のバックエンド領域においてはほとんどが Ruby on Rails で実装されています。今でも多くの箇所で利用されています。サービスに必要な機能を高速で実装するために Ruby が用いられており、主要な箇所では Rails のサーバーに実装することが多くあります。

ただし以前までと全く同じということはなく、Ruby を使ったアーキテクチャも年々変容しています。今では Ruby on Rails を純粋に利用するだけに留まらず、マイクロサービス間の通信を担うために gRPC サーバーの実装が増えています。
(参考: 実践: gRPC in Ruby - Wantedly Engineering Handbook)

Python は機械学習を用いた推薦システムの台頭などにより利用比率が増えています。また、バックエンド領域とは少し外れますが、最近では Next.js の台頭により JavaScript (TypeScript) で実装されたマイクロサービスが生まれるなど、細かい単位での年々変容は起きています。

将来 (2024 年〜)

ウォンテッドリーにおいては、この利用言語の推移やアーキテクチャは大きくは変わらないと考えています。3言語という観点では、一部のマイクロサービスで新たに別の言語を利用する可能性はあります。マイクロサービスとして境界が切られていることもあり、多くのマイクロサービスにおいて実装言語を一新するような大きな変更はしばらく行われないと推測しています。

最後に

「利用している言語」という切り口からアーキテクチャや言語の技術選定の変化について紹介しました。この記事を通じて、ウォンテッドリーのバックエンド領域における技術選定が、読者の皆さまの参考になれば幸いです。