こんにちは、DCP事業部エンジニアの榎本です。普段の業務ではMedPeer Channelの開発を担当しています。
メドピアはKaigi on Rails 2021にRubyスポンサーとして参加し、そのスポンサーLT枠にて 『medpeer.jp 開発を加速させるエンジニアリング施策』という発表をしてきました。
今日はその内容を補足するとともに改めて本テックブログでも紹介したいと思います。
medpeer.jp の rails stats
medpeer.jp （医師専用コミュニティサイト「MedPeer」のことです）自体は2007年にローンチしたサービスで、サービスの歴史としては10年以上（もうすぐ15年！）続くサービスです*1。
サービスイン当時の開発言語はPHPでしたが、2016年に medpeer.jp のRails化が開始されました。Rails化をスタートさせてから既に5年が経過しており、Railsのコードベースも巨大になりつつあります。
2021年10月時点の medpeer.jp の rails stats 取得してみました。その結果が下記です。
$ rails stats +----------------------+--------+--------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+--------+--------+---------+---------+-----+-------+ | Controllers | 29336 | 22890 | 547 | 3078 | 5 | 5 | | Helpers | 861 | 676 | 0 | 114 | 0 | 3 | | Jobs | 1412 | 1164 | 49 | 166 | 3 | 5 | | Models | 64144 | 43039 | 1218 | 4945 | 4 | 6 | | Mailers | 599 | 483 | 26 | 59 | 2 | 6 | | JavaScripts | 665 | 292 | 0 | 51 | 0 | 3 | | JavaScript | 22963 | 15936 | 0 | 1234 | 0 | 10 | ...（以下略）...
そんな巨大な medpeer.jp 開発を支えるエンジニアリング的な工夫をいくつか紹介したいと思います。
- medpeer.jp の rails stats
- コンテナベースの開発環境
- フィーチャートグル
- Railsアプリケーション設計
- CI/CD
- Rails Upgrade 戦略
- 技術負債・今後の課題
- Kaigi on Rails に参加してみて
コンテナベースの開発環境
もはや常識となったdockerコンテナ開発ですが、弊社も例に漏れずdockerコンテナをベースとして開発しています。
ローカル開発環境
ローカル開発環境は dip を利用しています。
dip とは Docker Compose をラップしたコマンドラインツールです。これを利用することで複雑な docker compose コマンドを大幅にショートカットできます。例えばmedpeer.jp 開発の場合、 Rails Server の起動は dip rails s とすれば立ち上がるように設定しています。
dip に関しては下記の翻訳記事が詳しいのであわせてご参照ください。
QA環境
medpeer.jp 開発チームではQA環境という環境を用意しています。QA環境は何かというとブランチ単位のプレビュー環境のことです。
GitHub Pull Request 上で /deploy-qa とコメントをすると GitHub Actions でデプロイジョブが走り、当該ブランチがQA環境へデプロイされる仕組みになっています。
ステージング環境・プロダクション環境
ステージング環境、プロダクション環境ともにECSを使ってインフラを構築しています。また、メインとなるRails AppのサーバーはAWS Fargate を使って構築しています。
ちなみに medpeer.jp だけでなくメドピア会社全体としてECSを採用しており、弊社のSRE・侘美がECS勉強会を開催したときの資料は下記になります。
フィーチャートグル
flipper というgemを使いフィーチャートグルを実現しています。
今まで巨大な長命のフィーチャーブランチを頑張ってメンテし、リリースタイミングでドカンと危険なビッグバンリリースを発動させていたのですが、このフィーチャートグルの仕組みが導入されたことにより、ビッグバンリリースを回避することができるようになりました。
追記: フィーチャートグルに関しては下記の記事でまとめております。あわせてご覧ください。
Railsアプリケーション設計
巨大なRailsアプリケーションコードをメンテナブルにする工夫は各社いろいろアプローチあると思いますが、弊社は PORO (Plain Old Ruby Objects) のアプローチを使うことが多いです。
POROに関しては弊社の技術顧問である willnet さんが下記記事で紹介しておりますので、よければご覧ください。
また、フォームオブジェクトのアプローチについても下記記事で解説しておりますのであわせてどうぞ。
CI/CD
medpeer.jp の CI/CDですが、CIサービスとして CircleCI + GitHub Action を利用しており、CDは主に GitHub Action を利用しています。
中でも GitHub Actions + GitHub Deployment の仕組みが便利で、GitHub ネイティブのデプロイ通知が見れたり、Activeなデプロイメントステータスが GitHub UI 上でさっと確認できるのが便利です。
これに関して詳しくは、弊社SRE・正徳が発表した資料がありますので、下記資料をご覧ください。
Rails Upgrade 戦略
スムーズなRails Upgradeのために、複数RailsバージョンでCIを実行しています。つまり、現行バージョンに加えて次のRailsバージョンでCI上を動かすことで、次のバージョンでも正しく動くことをCIで担保しています。
これに関しても正徳が発表した資料がありますので、詳しくは下記資料をご覧ください。
技術負債・今後の課題
medpeer.jp は長年運用しているサービスですので、もちろん技術負債もあります。具体的には下記のようなものです。
- まだRails 6.0（年内には Rails 6.1 にアップグレード予定）
- 残存するPHPコードベース
- PHPから移植した古いRailsコード
- マイクロサービスっぽいアーキテクチャの残滓
現状はこれらの技術負債に対して、きれいにできるところからきれいにしていき徐々に減らしていっているという段階です。
Kaigi on Rails に参加してみて
前年度の Kaigi on Rails にも私は参加していましたが、間違いなく去年よりカンファレンス特有の"ワイワイ感"が演出できていたように感じます。
そのワイワイ感を演出するのに一役買っていたのは reBakoであったと思います。雑談テーブルで開発者同士がいろいろ話していたり、登壇者が登壇後QAテーブルでいろいろ質問に受け答えをしていたりして盛り上がっていました。
一方で企業ブース出展側でいうと、一見さんが入りやすいような雰囲気作りをするのに課題を感じました。リアルのブース出展だとフラッと立ち寄ってくれる方がいらっしゃったり、こちらからノベルティを渡しに行ったりとある程度インタラクションが発生する機会がありますが、オンラインだとなかなかブースの中までは呼び込むのにハードルを感じました。このあたりは再度 reBako 出展する機会があればいろいろ工夫したいところです。
最後になりますが、とても素敵な"Kaigi"を開催してくださった Kaigi on Rails 2021スタッフの皆様、ありがとうございます！
メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！
■募集ポジションはこちら
https://medpeer.co.jp/recruit/entry/
■開発環境はこちら
