[Day 1: A-2] Microservices on "Rails"


yhirano55

登壇者: Wantedly, Inc. 竹野 創平 氏 @Altech

マイクロサービスと一言で言っても、何をどこまでやるサービスを作り、それらのサービスをまとめてどのようなアーキテクチャにするのかというところにはかなりの自由度があり、技術的・事業的な変数に依存します。

弊社では2016年に開発を始めた Wantedly People においてマイクロサービス・アーキテクチャを採用しています。ここでは Rails に加えて Go, Python など複数の技術を導入していますが、そういった中でどのように Rails が使われているかをご紹介します。またより大きなアーキテクチャとして、事業的な中核価値であるユーザープロフィールデータの既存の Rails アプリケーションから切り出してより使いやすい形で各事業から活用できるようにする変更を現在進めており、これについても少しご紹介したいと思います。

https://techplay.jp/event/639872


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(1)

Questions and feedbacks (21)

Altech
Altech commented about 1 year

現在進められているというprofile serviceの話についてです。 「writeは該当サービスの責務を持つserviceのAPI経由で行う」とのことですが、readの方はどうされてるのでしょう? そこは妥協して直接しているのでしょうか。

モノリシックアプリケーションである Wantedly Visit 以外は Wantedly Visit に対して API 経由で profile を取得しているので、Wantedly Visit 以外は read を profile service の API 経由で取得するようにできます。

ただ Wantedly Visit では profile はコードベースの広い範囲で様々な形で使われているので、少し難しい気もしています。今回、優先して解決したい問題としては、1) 書き込みの際の整合性担保、2) Wantedly Visit に多サービスの負荷が集中しない構造にする、3) 変更のフックを書くサービスが受け取れるようにする、などがあるのですが、それらに対してはそこまでやる必要がないという事情もあります。

あとモデルは各リポジトリで別々に管理されているようですが、例えばモデル部分はgem化しておいてインターフェースに変更があったらバージョンアップ+実装変更みたいなアプローチも考えられるんですがどう思いますか?

特に Rails だけを使いたいわけではないので原則は API で抽象化したいところですが、上記の Wantedly Visit と profile service の間に関しては現実的にあり得る選択肢かもしれないですね。

Like(1)

Altech
Altech commented about 1 year

各マイクロサービスが持つべきロギング等の共通機能を内部のリポジトリに切り出しているとのことでしたが、 この共通部分は Ruby, Python, Go それぞれでメンテしているのでしょうか? もしそうであるなら負担に感じたりはしないのでしょうか?

新しく service を立てるときには毎回書かなければ行けないコードではあるので、実装コストはペイすると思っています。一方で、これが広く使われた場合に各リポジトリでバージョンを上げるのは少し面倒かもしれないです(バージョンアップで互換性が破壊されるような複雑な機能は入れていないという前提です)。

Like(0)

Altech
Altech commented about 1 year

機械学習を専門とする人がつくる Python の実装は Http で Go から呼び出せるようにしているのですか? その場合、機械学習を専門とする人たちが WebAPI も実装しているのですか?

はい、Web API を tornado というシンプルなフレームワークを使って機械学習チームが実装しています。

Like(1)

Altech
Altech commented about 1 year

趣旨とずれているかもしれませんが、Railsでマイグレーションすることに関してです。 大きなテーブルにマイグレーションをかける際に、何か工夫されていることなどあるでしょうか? 例えばサービス停止しているとはいえ、1億レコードあるようなテーブルだとかなりの時間を要するかと思います。

この辺特別詳しいわけではないのですが、Postgres の場合はカラム追加はデフォルト値を設定しなければ一瞬で終わるので、デフォルト値を設定したい場合は一旦設定せずにmigration してから値を fll する script を走らせてから再度 migraiton、がよくあるプラクティスだと思っています。カラム削除は内部的に disable にされるだけなのですぐ終わると思います。

Like(0)

Altech
Altech commented about 1 year

ふりがなサービスとかutil的なサービスもあるような気がするのですが、gemじゃなくてmicroservice化されているのは理由がありますか?

こちらセッションで答えたのですが、gem にしてないのは単純に Ruby ではなく Python で実装しているためですね。

あとは、仮に gem にすると Ruby でしか利用できなくなってしまうのと、ふりがなの振り方自体も独立して精度改善の余地があるので、miscroservice にしておく意味があるかなと個人的には考えています(ライブラリだと改善したときに利用側を全てバージョンアップしなければいけないので)。

Like(1)

Altech
Altech commented about 1 year

セッションテーマとちょっとずれた質問ですが、「Dockerの薄いラッパー」って具体的にどんなものなんでしょう? シェルやMakefileでサブコマンド、みたいなのがよくあるユースケースかと思っているのですが何かツールとか作られてますか?

具体的には弊社のエンジニアが https://github.com/creasty/rid (run-in-docker) というソフトウェアを作っているのですが、ほぼネイティブのコマンドのように Docker 内でコマンドを実行できるものです。bundle exec のように prefix を付けて実行すると docker 内のコマンドとして実行されます。

$ rid rails c

あとは Docker 内でのセットアップ(image pull 後の bundle install など)はシェルスクリプトを libexec というサブディレクトリに bootstrap script を置いて rid bootstrap で全てセットアップできるようにしています。docker image 内での bootstrap なので環境依存性が低いのと、シェルスクリプトであることを意識させないところが便利な印象です。

Like(1)

Altech
Altech commented about 1 year

peopleっていうserviceは、今思うと細かいserviceに切り分けたいと考えますか?切り分けた事例があればその中で辛かった部分を教えて欲しいです

まだサービスを出して1年程度なので、切り分けた事例はまだないですね。ただ、今回紹介した複数サービス(People, Visit)の間で共有するデータに移したい箇所はいくつかあります。

Like(0)

Altech
Altech commented about 1 year

Wantedly Peopleの方はかなりサービス数多いと思うんですが 今振り返ってみてサービスの分け方は成功したと思いますか? また、運用してみてサービス数が多いことによるつらみみたいなのはありますか?

@nabuchi セッションの中で言えば良かったですが、基本的には新しく作ったサービスの分け方は成功したという感覚です。サービスが多いことに対しては、 Kubernetes を運用している SRE チームが継続的に対処しています。特に、サービス数に対して O(n) での作業量が必要になるものの割合を一定以下に抑えると言った観点があり、こちらは弊社の @koudaiii による以下のスライドなどで説明しています。 https://speakerdeck.com/koudaiii/number-jtf2017

つらみで言うと、セッションでも触れていた別の事業部の中にある中核ドメインに関する変更ですね。テーブルにカラムを1つ追加して read / update するまでに4つのリポジトリに PR を出したこともありました…。

あとはサービス横断的な不具合に対しては分散トレーシングはやはり無いと辛いので、その辺りは現在整えているところです。

Like(0)

Altech
Altech commented about 1 year

Wantedlyさんは、ネイティブアプリも途中からかなり分割していっている印象があるのですが、バックエンドのマイクロサービス化とネイティブアプリ・フロントアプリの関係についてもできればお聞きしたいです。 (当日は裏で司会をしている予定なので、リアルタイムでは聞けない可能性が高いのですが... >< )

こちらセッションの最後でお答えしました!基本的には分割はやってなくて、新しい事業に対してアプリとサーバーを新しく作っていて、そこで問題になる中核ドメインの共有問題に対してマイクロサービスによる解決を試みているという関係です。

Like(1)

yuemori
yuemori commented about 1 year

現在進められているというprofile serviceの話についてです。 「writeは該当サービスの責務を持つserviceのAPI経由で行う」とのことですが、readの方はどうされてるのでしょう? そこは妥協して直接しているのでしょうか。

あとモデルは各リポジトリで別々に管理されているようですが、例えばモデル部分はgem化しておいてインターフェースに変更があったらバージョンアップ+実装変更みたいなアプローチも考えられるんですがどう思いますか?

Like(0)

yskkin
yskkin commented about 1 year

各マイクロサービスが持つべきロギング等の共通機能を内部のリポジトリに切り出しているとのことでしたが、 この共通部分は Ruby, Python, Go それぞれでメンテしているのでしょうか? もしそうであるなら負担に感じたりはしないのでしょうか?

Like(0)

shimpei
shimpei commented about 1 year

機械学習を専門とする人がつくる Python の実装は Http で Go から呼び出せるようにしているのですか? その場合、機械学習を専門とする人たちが WebAPI も実装しているのですか?

Like(1)

naoki85
naoki85 commented about 1 year

趣旨とずれているかもしれませんが、Railsでマイグレーションすることに関してです。
大きなテーブルにマイグレーションをかける際に、何か工夫されていることなどあるでしょうか?
例えばサービス停止しているとはいえ、1億レコードあるようなテーブルだとかなりの時間を要するかと思います。

Like(0)

nobuhikosawai

ふりがなサービスとかutil的なサービスもあるような気がするのですが、gemじゃなくてmicroservice化されているのは理由がありますか?

Like(2)

yuemori
yuemori commented about 1 year

セッションテーマとちょっとずれた質問ですが、「Dockerの薄いラッパー」って具体的にどんなものなんでしょう? シェルやMakefileでサブコマンド、みたいなのがよくあるユースケースかと思っているのですが何かツールとか作られてますか?

Like(0)

KentaYoshitani

peopleっていうserviceは、今思うと細かいserviceに切り分けたいと考えますか?切り分けた事例があればその中で辛かった部分を教えて欲しいです

Like(0)

nabuchi
nabuchi commented about 1 year

Wantedly Peopleの方はかなりサービス数多いと思うんですが 今振り返ってみてサービスの分け方は成功したと思いますか? また、運用してみてサービス数が多いことによるつらみみたいなのはありますか?

Like(1)

qsona
qsona commented about 1 year

Wantedlyさんは、ネイティブアプリも途中からかなり分割していっている印象があるのですが、バックエンドのマイクロサービス化とネイティブアプリ・フロントアプリの関係についてもできればお聞きしたいです。 (当日は裏で司会をしている予定なので、リアルタイムでは聞けない可能性が高いのですが... >< )

Like(3)

yhirano55

Rails, Go, Python などを使って開発

@Altech なるほど。Wantedly Visitはモノリシックなんですね。ありがとうございます マイクロサービス・アーキテクチャだと、『事業的な中核価値であるユーザープロフィールデータを既存の Rails アプリケーションから切り出し、より使いやすい形で各事業から活用できるよう』が、どの現場でもキーになりそうな問題っぽいので期待しています。

Like(0)

Altech
Altech commented over 1 year

おっと、気づくのが送れてしまいました。。

2011年の最初にリリースされた Wantedly(現在の Wantedly Visit)は現在もモノリシックな Rails アプリケーションとして開発を続けています。一方、2016年に開発・リリースした Wantedly People は当初からマイクロサービス・アーキテクチャを採用していて、そちらの方がユーザー規模は大きいのですが、こちらは Rails, Go, Python などを使って開発をしています。このあたりの背景は少し説明に入れようと思います💡

Like(1)

yhirano55

素朴な疑問で恐縮ですが、Wantedlyはリリース当初、モノリシックなRailsアプリケーションだったのでしょうか?(どんなUIだったのだろう...?)

Like(0)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano