Re:モノリスなRailsアプリ『ツクリンク』で技術的に面白くなるところ（またの名を課題）

ごきげんよう。あっきー（@kuronekopunk）です。
去年書いた課題から状況も変わったのでアップデート含め書きます。

🤖対象読者

• Railsエンジニア

  • 特にRailsでモノリスなWebアプリを開発している方

• ツクリンクに興味のあるエンジニア

🏃‍♂️忙しい方向けまとめ

• プロダクトの信頼性を上げるよ！

  • AWSへのインフラ移行

  • SREチーム発足

• Flutterでアプリ作るよ！

• フロントエンド/バックエンドの分離をしたい！

• 死ぬほど新しいことやっていきます！

🔭プロダクトの安定稼働

今後、更にユーザー数も増え、機能自体も増えていきます。その中で安定性を上げていく取り組みが今以上に大事になってきます。

Heroku→AWSへのインフラ移行

現状、インフラはHeroku上にアプリケーションサーバー、PostgreSQL、Elasticsearch、Redisを載せ、一部AWSでS3, SES, SQS, CloudFrontなどを利用しています。
2022年末にUSにあったHerokuアプリをエンタープライズの東京リージョンに移行しました。これによりレスポンスの高速化、プライベートネットワーク内で管理できるようになりセキュリティ対策にもなりました。
ですが、Herokuで運用する中で2つ大きな課題があり、これを解消するためにAWSへのインフラ移行を進行しています。

１．ブルーグリーン・デプロイメントができない
HerokuではPrebootしてデプロイすることが、デプロイ時は瞬断が起こる程度ではありますが、デプロイしたアプリケーションに不具合があった場合の切り戻しを操作することができません。今後の安定稼働のためデプロイ周りを自分たちで管理できる必要があります。

２．設定がブラックボックスで変更不可能な部分がある
Heroku側でフルマネージドされている関係上、PostgreSQL、Elasticsearch、Redisで設定できることや管理に制限があります。今後DBのチューニングなど細かな設定が必要になる際に対応できなくなる可能性があります。

SLO, SLI定義・監視体制の強化と対応

現状、Datadogでのメトリクス監視を行っています。一般的な指標やアラート設定をしていますが、まだ自社サービスに沿った形にはできていません。またSLO,SLIといった指標も検討中です。SREチームを作り、SLO,SLI定義から監視体制の強化と対応の実施を行っていきます。

スロークエリ対策

サービスリリースから約10年が経ちました。それに伴い、データ量も増え、スロークエリも出やすくなりました。監視やクエリ改善、DBのチューニングなどの改善を任意メンバーによる委員会的に進めています。

QAの品質向上、E2Eテストの再設計・拡充

現在Rspec, CapybaraでE2Eテストを実施してます。テストカバレッジは高い水準を保っているものの、全体的な設計や実装方針などは昔作ったままの状態のため最高品質とは言いづらい状況です。Datadog内のE2Eテストツールの検討や実装方針を再定義するなど、こちらも任意メンバーによる委員会的に改善を進めています。

📱モバイルアプリ、フロントエンド

Flutterを利用したモバイルアプリリニューアル

既存アプリはほぼWebviewで構成されており、ユーザーの利便性を高めていくために、ネイティブアプリへのリニューアルを計画しています。クロスプラットフォームで変更容易性が高く、技術的な挑戦の観点からFlutterを選ぶことにしました。

フロントエンド/バックエンドの分離

モバイルアプリ強化によってフロントバックエンドの分離がしやすくなります。最初はモバイルアプリを優先としますが、順次SPA化を進めUXの向上とシステム上の責任範囲の分離ができたら良いと考えています。

💎バックエンド（Rails）

Railsアプリの切り分けやアーキテクチャ設計

アプリのリニューアルに紐づくアプリケーションサーバー側の認証やAPI設計なども課題となってきます。
このあたりは特に知見のある方に協力いただきたいポイントです。
組織やサービスのスケールに対応できるよう、モジュラモノリスやマイクロサービスなどアーキテクチャ面での検討を行っていき、安定した価値提供ができるようプロダクトを進化させていく必要があると考えています。

[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

メール・プッシュ通知配信の基盤改善

割と古めな実装が生きている箇所です。ユーザー数に伴って送信件数も増えているため速度面の改善が必要になります。根本的なアーキテクチャの考え直しからリプレイスを視野に入れて改善を検討しています。

爆速での新機能開発

サービス拡大のため作るべき機能が山ほどあります。価値あるプロダクトを爆速で届けていくにはエンジニアが言われたものを作るのではなく要件定義から積極的に関わり提案し、価値あるものをよりコストを下げて作っていくことが重要です。そのためにはモノづくりする実装力だけではなく、プロダクトづくり全般の総合力を上げていく必要があります。現メンバーの総合力を上げるのはもちろんですがそういった指向性のあるメンバーを積極的に採用して組織力を上げていきます。

組織的な技術力強化

元々PHPをやっていた僕がRailsを覚えながら書き換え→開発をしてきた背景もあり、古いコードは設計面でも怪しい箇所もあります。実運用に影響の出そうな設計も存在するため、データ構造などを含めてのリファクタリングも積極的に行いたいと感じています。そのためにチームの技術力強化やテックリードの採用などにも力を入れていきます。

おわりに

前回の記事を振り返ってみると改善できている所/できていない所だけでなく新しい課題やチャレンジが進んでいたり、サービスの成長を感じています。
更にここからサービス・組織共に急成長していくため今ここで書いた課題が1ヶ月後には全く違う課題になっているかもしれません。そういったことも含め大きな課題を一緒に全力でぶっ壊してくれる人が必要です。
少しでも興味があればTwitter（@kuronekopunk）のDMでもリプライやYOUTRUSTでも良いのでお声がけいただけると嬉しいです。カジュアル面談というのも少し堅く感じてしまうのでただただ雑談できればと思います。
同じような課題を持っていて更に具体的に話してみたい方もぜひ雑談しましょう。