Smiqleの技術選定について

はじめに

こんにちは、Smiqleの代表CEO兼CTOの鈴木です。今回は、テックブログの最初の記事として、Smiqleの開発初期における技術選定についてお話したいと思います。サービスの性質や開発方針に応じて、どのような技術を選び、どういった点に注意してきたのかを具体的に紹介していきます。

プロダクト概要

Smiqleでは、toC向け、toB向けのどちらのサービスも提供しています。

toC向けプロダクト

主にメディアの性質が強く、SEO対策や検索機能のユーザー体験向上に注力しています。具体的には、不動産情報の検索ポータルとしての機能を備え、ユーザーが効率的に物件を探せることを目指しています。

toB向けプロダクト

不動産事業者向けのバーティカルSaaS型Webアプリケーションで、業務効率化をサポートするためのツールを提供しています。CRM機能や物件管理、レポーティング機能など、多岐にわたる業務フローをカバーしています。

技術選定の方針

• 共通技術スタックの採用
  • 異なる性質を持つtoCとtoBのプロダクトを、できるだけ共通の技術スタックでカバーすることで、開発・保守の負荷を軽減し、効率的な開発体制を実現したいと考えました。
• 3年間は大規模な作り直しをしないこと
  • 開発リソースを最大限に活用するため、技術選定は安定性と将来性のバランスを重視し、最低でも3年は大幅な見直しを行わずに済む技術を選びました。
• エンジニア採用のボトルネックを避ける
  • レガシーになりつつある技術や尖りすぎた技術を避け、できるだけ幅広いエンジニアに参加してもらえる技術を選びました。

フロントエンドの選定選定

複数人で開発するにあたってTypeScriptで書くことを前提にフレームワークを選定しました。

フレームワーク選定

フロントエンドのフレームワーク選定では、Nuxt、Next.js、Reactの3つを検討しました。結果として、NextJSを採用することにしました。

採用理由

• ISR（Incremental Static Regeneration）を使ってみたかったから

  • ISRは動的なデータ更新と静的なサイト生成のメリットを両立できる技術ですが、いまいち使い所が難しくもあります。ただし、以前から不動産ポータルサイト（例: SUUMOのようなサイト）には使えるんじゃないかと考えていて、Vercel以外にもFirebase Hosting でも利用できるようになったこともあり試してみることにしました。

• ライブラリとミドルウェアの充実度

  • NextJSは、ルーティング速度、ミドルウェア、API管理などの機能が豊富で、フレームワーク自身の開発速度も早く、開発者体験に優れている点が大きな魅力でした。

• 懸念点

  • 開発元であるVercelでしか使えない機能が出ることもあるので、そういう点では注意が必要だと思っています。

CSSフレームワーク

CSSフレームワークは、Chakra UI, MUI, UIkit, TailWind css を検討し、開発スピード、デザインの柔軟性、大規模サービスへの豊富な実績から、最終的にTailwind CSSを採用しました。

選定理由

• 開発スピードの向上

  • コンポーネントベースで設計できるため、デザイン修正やスタイル変更が容易で、迅速なUI開発ができるし、何と言ってもCSSファイルを触らなくて良い。

• 他の候補の課題点

  • Chakura UIは流行っていたものの、Datepickerなど基本的なUIコンポーネントが不十分で候補から外しました。またMUIはReact Hook Formとの相性が悪く、一番軽量で好んで使っていたUIKitは、大規模アプリになると痒いところに手が届かないため採用を見送りました。

最終的には、デザイナーが参画してくれて世界観の構築からやってもらうタイミングで、デザインは一新すると思うので、今はTailwind CSSで爆速開発で進めることにしました。

バックエンド技術の選定

言語選定

ここは Go を使うことが、ほぼ決まっていました。採用理由としては、コンパイル言語でメモリーの安全性が高く処理速度も早い。記述の可読性も高く、チーム開発に向いていると思います。それ以外のRustなどの言語と比べても、運用実績が多く、さまざまなサービスでライブラリが提供されている可能性が高いことが挙げられます。また国内において、メルカリやDeNAなど優秀なエンジニアが多いメガベンチャーで使われているので、そのあたりを採用するのに親和性が高いことは非常に重要です。
以上の理由で、ほぼ検討することなく Go を採用しました。

Goフレームワーク選定

ここでは新しいフレームワークが色々あるんじゃないかと期待していた部分でもありましたが、結局はGin, Echo, net/http(生）の３つの候補を検討することとなり、最終的にはEchoを採用しました。

採用理由

• 速度も早くAPIに向いている
  • net/httpと比較しても、速度はそれほど変わらずルーティングの記述もシンプルでAPIを作るための最低限が揃っている。
• シンプルな状態から必要なものを加えていける
  • 構成は非常にシンプルだが、運用の実績も多いためwebsocketやJWTなどのミドルウェアも簡単に導入できる

インフラ選定

AWSとGoogle Cloud Platformを検討し、最終的には GCP(Google Cloud Platform) を採用しました。

採用基準

• RDBの性能

  • 以前のCloud SQLだったら、バージョンアップも遅く、速度も早くなかったので、完全にAWS Auroraを選んでいたと思いますが、Cloud SQL Enterprise が出てきて潮目が変わったと思います。やはりRDBの性能が高いことはアプリケーションの品質に直結するので非常に重要であり、そういう意味で、速度面でも機能面でもCloud SQL Enterpriseは優れていると思います。AlloyDBもありますが、僕がMySQL派なので。

• NoSQLの使い易さ

  • Firestoreのsubcollection使いやすくないですか？RDBの得意じゃない部分を良い感じに表現してくれるので、DynamoDBよりFirestoreの方が使いやすいと思っています。

• Serverlessの比較

  • FargateとCloud Runを比較すると、圧倒的にCloud Runの方が使いやすく感じています。デプロイも設定も簡単。App Runnerは試したことありませんが、新しいサービスで機能が豊富なイメージではあります。ただ、あまりGoで使ってる人を見たことがありません。

料金面とか色々みて、メインはGCPにしますが、部分的にはAWSも使うと思います。

認証設計

ユーザ側の認証

ネイティブアプリも作るので、Google Identify Platformを利用します。１アカウントに複数のGoogleアカウントを紐づけるという要件を検討したときにAuth0も検討しまいsたが、そもとも要件自体がヤバすぎるため辞めました。

API側の認可

最初はAPI Gatewayを使ってエンドポイントごとに認証設定をyamlで作ることを検討していましたが、最近は Cloud Run の手前に Load Balancerを置く構成が推奨されているみたいなので、おとなしくサーバ側に Identity Platformへの認証を入れました。
また、これなら社内ツールを作る際に、Identity-Aware Proxyという便利な機能があり、Google WorkspaceのGoogleグループごとに認可できたりするので、とても便利です。

こちらの記事を参考にさせてもらいました。
https://zenn.dev/google_cloud_jp/articles/idp-patterns

おわりに

最後まで読んでいただきありがとうございます。
上記の技術は現段階での選択であり、今後優れた実績のある技術が出てくれば積極的に取り入れていく予定です。他にもミドルウェアや、CI/CD周り、ロギングなど機会があれば記事にします。

Smiqleでは、一緒に新しい不動産業界のインフラになるプラットフォームを作る仲間を募集しています。副業の業務委託から参加できるので気軽にカジュアル面談させてください。
是非一緒に、最高のプロダクト作りを手伝ってください。よろしくお願いします。