カトホームの技術構成 2024冬
November 18th, 2024 15:32・All users
はじめに
カトホーム は2021年1月にリリースし、もうすぐ4周年を迎えようとしています
この4年でサービスの技術構成は大きく変わりました
そこで2024年11月現在における技術構成や、そこに至るまでの構成の変遷についてまとめておきます
2024年11月現在の構成
こちらが現在の構成の概要です
厳密には複数のバッチがあったり開発用のAPIがあったりします
開発効率>費用の安さ>運用の楽さ>安定性 のような優先度で意識して組んでいます
費用なども大事ですが個人開発なので思い立ったときにサッと作ってサッとリリースできることが継続的なアップデートに繋がると考え、開発効率に重きを置いています
Kubernetes
サーバー側の機能は Akamai で構築した Kubernetes cluster 上に載っています
Akamai の Kubernetes は GKE や EKS と比べ安く個人開発では助かります
Kubernetes を使うことによって cluster の管理が発生して運用が多少大変になりますが、Argo CD を使って GitOps を構築した cluster を持っていると気軽にデプロイしやすくなり開発効率が上がるため採用しています
過去には NodeBalancer や Istio などを用いていた時期もありましたが、Kubernetes上で管理するリソースを減らせて運用を簡単にできる Cloudflare Tunnel を現在は使っています
代わりに Kubernetes 外の管理対象が増えることになるので一長一短です
バッチ処理
開発用の内部 API を GUI から呼ぶ目的でも使えて便利です
データベース
MySQL 互換かつ費用が安いため採用しています
元々 Cloud Firestore や Cloud Functions などの Firebase で固めていましたが、後述する理由でRDBMSへの移行を進めています
既に大半の機能を移行済みです
認証
Firebase Authentication を使っています
検索
MySQL の全文検索や Elasticsearch なども考えましたが、Algolia は業務で経験があり安く簡単に全文検索を実現できそうなので採用しました
Elasticsearch の業務経験もありますが、カトホームで採用するにはオーバースペックですしメンテナンスも大変になるので避けています
メール送信
Resend を使っています
Send Grid も考えましたが個人では契約出来なかったので Resend にしました
メール送信の知識は全く持っていませんでしたが、設定項目が分かりやすくなっていて助かりました
オブジェクトストレージ
Cloudflare R2 を使っています
料金が安く、他の Cloudflare 製品も使っているので選択しました
通知送信
FCM を使っています
最初期(2021-01)の構成
最初期の構成はこのようになっていました
配信情報取得などの定期バッチは Rust で作ったバイナリを GCE において cron で回していました
バイナリのビルドや配置は手動、ログは残らないし定期バッチの死活監視も無しと安定して運営できるようにはなっていませんでした
2021-02 ~ 2024-01 の構成
企画で賞をいただき多くの人に使ってもらえるようになったため、安定した運営を実現するべく急遽作り直したのがこちらの構成です
最初期に GCE 上で回していた定期バッチを TypeScript で書き直して Cloud Functions に載せたものです
Cloud Functions に載せることでログが残るようになった上にサーバー管理から開放され、安定して運用できるようになりました
この構成で2年ほど運用したあたりで以下のような課題が見えてきました
・アプリケーションの設計と Firestore の料金計算方法の相性が悪い
・読み込み対象のレコード数に比例して発生する料金が高めで、頻繁に表示される同時接続数の推移データを読み込む際の費用が高い
・NoSQL が辛い
・複雑な検索がしにくい
・スキーマの管理が大変
また個人的な話として
・普段の業務では RDBMS を使っており SQL の方が練度が高いため開発速度を意識して揃えたい
・他の個人開発で使い始めた Kubernetes & Argo CD の開発体験が良い
これらの理由から現在の構成への移行作業を2023年頃から始め、カトホームで本番運用を始めたのが2024年の2月頃でした
同じものを自分で作り直す作業が中心で面白みに欠けたためモチベーションが安定せず、移行作業には1年ほどかかってしまいました……
しかし移行後は上述した課題が解決し開発速度も向上しました
実際2024年2月以降は1~2ヶ月に1回程度のペースで新バージョンを継続的にリリースできており、やって良かったと思っています
おまけ 2024年11月現在のCI/CDなどの構成
現在の CI/CD などの構成はこのようになっています
「などの」としているのは OpenAPI 周りの生成はローカルで手動で行っているからです
CIに載せても良さそうだと思っていますが、一人で開発する分にはローカルで実行する方が手っ取り早いので手動で行っています
server の API はコードとマニフェストでリポジトリを分けています
コードリポジトリの main ブランチに push すると GitHub Actions でコンテナイメージの作成 & push とマニフェストリポジトリの更新が行われます
以前は Kubernetes cluster 内に harbor などのコンテナレジストリを立てて使っていましたが、cluster 内で何かしらの障害が起きると harbor からイメージを pull できなくなってサービスの復帰が難しくなるため cluster 外で管理するように変更しました
Codemagic ではビルドに M2 mac を使うことが出来るため採用しています
500分/月の無料枠もあるので個人利用であれば十分です
おわりに
カトホームの現在の技術構成などをまとめました
図に起こすのは初めてだったので整理する良い機会になりました
本記事がなにかの参考になれば幸いです
