Rettyマイクロサービス移行の旅、開始からの現在位置

マネージャーの常松です。Rettyで働き始め2年が経ちましたが、私の入社前から進められているマイクロサービス移行が、少し前に節目と呼べる大きめの本番稼働を始めたため紹介します。

Rettyのマイクロサービス移行について
マイクロサービス移行で直面した難所
今後の方針

Rettyのマイクロサービス移行について

これまでの公開情報

隠していたつもりはないのですが、タイミングを逃したりしていて、これまで正面から「Rettyはマイクロサービス化を進めています！」とうたったものはあまりありませんでした。このTechBlogだと2018年末にVPoEの小迫が開発着手に言及した記事をはじめ、4件の記事がマイクロサービスに言及しています。

もう少しまとまった形だとエンジニアの高瀬がVueFes 2019で登壇予定だったのですが、台風で中止となってしまった経緯があります。

システム構成

他社でもマイクロサービス移行の取り組みが多数公開されていますが、Rettyのシステム構成もよく似たものとなっています。

段階的なリリースを実現するために、URLやデバイス(PC・スマートフォン)をみてアクセスを振り分けるサービスをリクエスト処理の先頭に配置。
既存サービスでVue.jsを採用していたため、フロントエンドはNuxt.js/TypeScriptを採用。Atomic Designに基づきコンポーネントを設計。
バックエンドマイクロサービスはGo言語を採用。過去のコード資産を生かせるものはKotlinも使う。個々のマイクロサービス設計はクリーンアーキテクチャを採用。
フロントエンドからバックエンドマイクロサービスへの通信はBFF(Backend For Frontend)サーバーを経由する。BFFサーバーはGo言語で実装し、GraphQLで通信する。
マイクロサービスとの通信はgRPCで行う。

新サービスは下記で構成されており、全てECS Fargateで動作しています。

Nuxt.jsのフロントエンド
BFF GraphQLサーバー
マイクロサービス×10種

マイクロサービスのうち1種が小さなサービスの寄り合い(モジュラモノリス)となっており、成長に応じてサービスを切り出せるようにエンドポイントを細かく分けています。

開発経緯

開発開始から現在まで、下記のような経緯を辿りました。

2018年9月プロジェクトを立ち上げ、開発に着手
2019年6月フロントエンド・GraphQLサーバー・PHP モノリスを呼び出すマイクロサービス変換層が用意できた。数店舗でお店ごとのページ(店舗詳細ページ)PC版を切り替え、本番稼働を開始。
2020年3月 Rettyお店会員向けに提供している機能を追加開発。数店舗で店舗詳細ページPC版を切り替え本番稼働を開始。
2020年4月〜10月緊急事態宣言によるビジネス環境の変化、Go To Eatキャンペーンの準備を優先するため開発を一時中断
2020年10月特定プラン契約店舗で店舗詳細ページスマホ版のデザイン変更を行うため、対象を絞ってマイクロサービス化を加速することを決意
2021年2月 PHP モノリスへの依存を排除。対象店舗の店舗詳細ページを順次切り替え

土台を整備し、最低限の機能に絞って表示要件を満たせる数店舗を切り替えられるようになるまで9ヶ月、見つかった不具合修正・パフォーマンス改善、初期リリースに含められなかった不足機能の拡充に6ヶ月、スマホページ移植・マイクロサービス切り出しを終えるまでに4ヶ月といったボリューム感です。

マイクロサービス移行で直面した難所

マイクロサービス移行では様々な分野の悩みに直面しました。以下大きなものをいくつか紹介します。

作る側から陳腐化していく、変化への追従

インターネットサービスは日々環境が変化し続けます。プログラミング言語・ライブラリ・システム環境も日々変わっていくため、今日のベストプラクティスが明日は変わってしまうことが少なくありません。2年半の間にこんなことがありました。

AWSの新サービスがリリースされ、便利な機能が増える。
- インフラ環境をECS EC2からECS Fargateへ変更
SEO対策の状況が変化
- Googlebotが更新されJavaScriptの解釈能力が向上(参考)。→Server Side Renderingが不要になりそうだがこれは今のところそのまま。
- 2021年5月にCoreWebVitalsが導入される。→チューニングを実施
自社ドメインに対して理解が深まり、gRPC/GraphQLのスキーマを見直したくなる。
Vue3でクラスAPIの提案がRejectされた
- クラスAPIで当初揃えていたので逐次書き換えていかないといけない。
言語バージョン・依存ライブラリが更新されず古いまま。
- Dependabotを各リポジトリに導入し、ライブラリをこまめに更新する習慣を取り入れ。

変化に追従できたもの、対応を見送っているもの、これから対処するものなど様々ありますが、マイクロサービス移行は長丁場の開発であるため、最初に描いた全体を作りきるだけでなく、適宜「今作っているものが適切か?」を見直す機会が重要だと感じます。

既存のビジネスロジックを整理する流れを作る

開発過程で、表示コンテンツを決定する既存のビジネスロジックが誰もわからないこともありました。開発だけで進めていると「ソースコードを読み解いて現状に合わせる」ことを求められてしまいがちですが、営業・企画・デザイナーを巻き込むことで根本に立ち返った議論ができた場面がいくつもありました。気がついたときに声を上げ議論する経験を増やすことで「表示ロジックを簡易化できないか」「そもそもそのコンテンツは必要か」といった話をきちんとできるようになったと思います。

エンジニアの開発キャッチアップ

マイクロサービスを構成する個々の技術要素は世に出て数年経ち、勉強するためのリソースも探すことが容易になっていますが、実際に業務で取り入れようとするとスキルを身に付けるには、つまづきポイントがいくつもあるなと感じました。私の印象ですと以下がありました。

静的型付け(Go言語、gRPC/proto、GraphQL、TypeScript)を導入し、データモデルのあり方をきちんと議論・整理してから実装する
クリーンアーキテクチャのきちんとした理解
Nuxt.jsのServer Side Renderingの理解
PHPからGo言語への移行

他にも開発に携わるメンバーが増えていく・変わっていく中で、当初目指していた理想や・思想の理解、開発成果物の引継ぎにも時間をかけることがありました。

マイクロサービス移行は「単に実装言語・サービス構成を変える」という話ではなく、「開発文化を変えていく」ことなのでしょう。ですので意識の変化に時間を要することは必要なコストなのかと思います。

タイミングをみて推し進める

一度にシステムの全てを置き換えるのでない限り、旧版(モノリス)と新版(マイクロサービス)の並行稼働期間が生じます。旧版の開発を全て止め、新版に開発リソースの全てを割りふる事例もみますが、施策開発や不具合修正を止めることは現実的には困難なケースが多いでしょう。 Rettyでも「並行稼働期間の施策開発はマイクロサービスにも反映させていく」方針でいましたが、コロナ禍でビジネス環境が大きく変わった局面では2つのシステムを同時に改修していくことは諦めざるを得ませんでした。ビジネス上仕方のないことではありますが、移行そのものが頓挫してしまうと数年後により大きな、対処できない事業問題として返ってきてしまいます。

先の経緯紹介にある「特定プラン契約店舗で店舗詳細ページスマホ版のデザイン変更を行うため、対象を絞ってマイクロサービス化を加速することを決意」が大きな転機でしたが、「マイクロサービス化を推し進める」という正攻法のアプローチ以外でも、優先順位が高い事項をうまく絡め、機をみて推し進めていくしたたかさや胆力が求められます。

今後もマイクロサービス移行は数年かかると思われ、途中何らかの要因で止まってしまうことはあるかもしれませんが、この姿勢は崩さずに取り組んでいきます。

今後の方針

マイクロサービス移行は始まった当初 ORAという名のプロジェクトでした。これはOmise Re-Architectureの頭文字からつけられたもので、"Omise"は「店舗詳細ページ」を指したものです。去年あたりから「リアーキテクチャの取り組みは店舗詳細だけがターゲットではない」ことを打ち出していくため、"retty3"とも呼ぶように決めました。PHP モノリスのretty1、アプリAPIサーバー・まとめ記事自動生成ソリューションに結実したretty2の次を担い、メジャーバージョンを上げ過去を置き換えることを意識してつけた呼び名です。

マイクロサービスはtoC向けのWebシステムから始めましたが、アプリ・toB向けのシステムも少しずつrettty3へ統合していきます。進め方は「retty3開発プロジェクト / retty3開発チームを作る」のではなく、全チームがretty3に習熟し、普段の開発をretty3に寄せていけるように少しずつ変えていきます。

次のマイクロサービス移行経過報告は2年半待たずに行いたいところですが、難易度も開発ボリュームもある開発なのでまだまだ仲間が必要です。「国内有数の大規模アクセス数があるサービスのマイクロサービス移行」面白そうだと思いませんか? 新卒も中途も興味がある方は是非お声がけください。