公開日 2024/08/29更新日 2024/08/29

2ヶ月でリリースしたFindy Toolsの技術選定の裏側

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

これまで、Findy Toolsのアーキテクチャ特集記事では、テーマや分野ごとに複数の企業からアーキテクチャや技術選定の背景を伺い、まとめた記事をお届けしてきました。今回から始まる新シリーズでは、1社の技術選定についてさらに深く掘り下げ、個々の選択がどのように全体の成功に寄与しているのかをより詳細に探っていきたいと思います。初回の本記事では、まず私たち自身であるFindy Toolsが、2ヶ月という短期間でリリースに至った技術選定の裏側をご紹介します。

Findy Toolsについて

top
Findy Toolsは開発ツールに特化したレビューサイトです。ツールのレビューや他社のアーキテクチャを見て技術選定の参考にすることが出来ます。2024年1月にベータ版としてサービスをリリースしました。

ベータ版まではほとんど1人で開発され、現在は3名で開発を行っています。
立ち上げのスピードを重視して、基本は社内で実績のある技術を採用しています。ファインディではテックリードが中心となって開発基盤の整備が進められてきており、その恩恵を受けて立ち上げ初期から速いスピードでのサービス開発を実現できています。

インフラ構成

infra 会員限定コンテンツ無料登録してアーキテクチャを見る
インフラ構成に関しては基本的にAWSで、社内で実績があるサービスを利用しています。
フロントエンドは前段にCloudFrontを置き、SSR用のサーバをECS Fargateで運用しています。バックエンドサーバも同じくECS Fargateを使用しています。
フロントエンド、バックエンドともにWAFを使って攻撃やBotアクセスを制御しています。
また、すべてのインフラ構成はTerraformで管理されており、すべての変更に対してレビューが行われています。

アプリケーション

フロントエンドはNext.jsを使用しています。こちらも既存プロジェクトでの実績とSSR等の要件を加味して選定しています。また、既存プロダクトで用いているPages Routerからの移行の検証も視野に入れ、App Routerを採用しています。
App Routerに関しては、導入当初にServer ComponentとClient Componentの取り扱いやライブラリの対応に苦戦したり、後述するキャッシュの仕様に苦戦したりというのはありましたが、現状は致命的な問題はなく運用を続けています。
OG画像の生成にnext/ogを活用しており、ページに応じた動的な画像を生成しています。
フロントエンドは Nxを使ったモノレポで管理されており、コードの生成や依存関係の管理、ビルド時のキャッシュなど様々な恩恵を受けています。
特に、コード生成を活用することで新しいフィーチャーを作成するのに必要なディレクトリやファイルを自動生成出来るため、開発生産性や開発体験の向上に貢献しています。

バックエンドはGraphQLを採用しRuby on Railsを使って実装しています。
こちらもクエリの設計やLoader、エラーハンドリングなど既存のプロジェクトの知見を活かしてスムーズな開発体験を実現しています。また、ジェネレータを用いてモデル情報からクエリやミューテーションを自動生成する試みも行っています。

キャッシュ

表示速度の高速化のためにCloudFrontによるページキャッシュを導入しています。
App RouterのFull Route Cache機能の使用も検討しましたが、CloudFrontを使用した場合のキャッシュ管理が難しく今回は導入を見送っています。そのため、Next.jsのMiddlewareを使ってCache-Controlヘッダーを付与しています。
また、コンテンツを管理画面で更新したときに即時反映したいという要件もあったので、バックエンド側で更新時にCloudFrontのキャッシュをInvalidationする処理も入れています。

CI/CD

cicd 会員限定コンテンツ無料登録してアーキテクチャを見る
基本的にはテストからデプロイまでGitHub Actionsでやっています。こちらも社内の既存の仕組みがあったのでほとんどそれを流用する形で構築しています。
リリースのワークフローもほとんどが自動化されています。
リリースのワークフローを実行すると、リリースプルリクエストが作成され、ステージングデプロイが自動で行われます。リリース内容を確認しリリースプルリクエストをマージすると本番へのデプロイやリリースバージョンの発行、リリースノートの作成が行われます。

監視

o11y 会員限定コンテンツ無料登録してアーキテクチャを見る
監視は使い勝手やコスト等の理由から3つのサービスを使い分けています。
DatadogはAPM、インフラ監視、Syntheticを主に利用しています。これらの主要なメトリクスをダッシュボードに集約することで、アラート時などに問題点に気づきやすい状態を作っています。特にレスポンスタイムやステータスコードの監視はトラフィックやパフォーマンスの変化に気づきやすくなり、有効に活用できています。
また、SLOの設定も行い開発者とSREで定期的に振り返り、改善を行っています。
エラートラッキングにはSentryを使用しています。こちらはエラー調査のしやすさとコスト面から利用しています。最近はTraceなどパフォーマンス監視の機能も充実してきており期待はしていますがまだあまり活用できていません。
アプリケーションログやアクセスログはAWS Cloudwatchに転送しています。DatadogやSentryの監視があるおかげで現状ログを見る機会はそこまで多くないので、もしものために残しているというイメージです。

今後の展望

現状、まだプロダクトがリリースから1年以内ということもあり、機能開発や改善がメインタスクとなっています。しかし、少人数でやっているからこその効率化は必要だと考えており、週次で開発環境の改善点や新しい技術について共有する場を設けています。
フロントエンドのパフォーマンスやスタイルの共通化、E2Eテストなど、まだまだやっていきたいことはたくさんありますが、機能開発とのバランスを考えながら継続的に改善していきたいと思います。
ぜひ、皆様もFindy Toolsのレビューやアーキテクチャを見て開発環境の改善、開発生産性の向上のヒントを見つけてもらえればと思います！
https://findy-tools.io/

◆執筆：CTO室 Tools開発チームチームリーダー大原@kaacun