祝シリーズA調達！Resilireのテックスタック全貌を説明するよ | Resilire Tech Blog
サプライチェーンリスク管理クラウドサービスResilire の@teruhikyです。
つい先日、シリーズAの調達を無事に公開でき、これからさらにプロダクト開発を加速させていきます！
そんな弊社Resilireですが、一度現状のテックスタックを見ながらざっくりとどんな開発環境・体験でプロダクト開発しているのかを紹介させていただきます。
まずは全体像から！
早速、弊社のテックスタックの全体像を以下に紹介します！
組織のコミュニケーション・自動化で使っているツールから、プロダクト設計、プロダクトソフトウェア領域、インフラ、運用保守と全体感がわかるようにツールを並べています。
各領域の詳細ではもっとあったりもしますが、まずはどういう構成なのか全体像が見えるようにまとめました。
それでは、それぞれの領域について見て行きましょう。
1. 組織のコミュニケーション・自動化
全体図の”組織”という括りに並べていますが、社内のコミュニケーションと自動化にいくつかのツールを導入しています。
非同期・同期コミュニケーション
業務上の非同期（文章）コミュニケーションはSlackを、同期（会話）コミュニケーションはGatherを使用しています。
Resilire外とのコミュニケーションはZoomやMeetなども使用していますが、社内はもっぱらGatherです。
これは、もともと私がResilireにJoinした時に福岡からのリモートワークをしており（詳しくはこちらを参照）、オンラインだとお互いが見えなかったのでオフィス感が欲しくて導入させてもらいました。
結果、プロダクト開発のMTGはGatherが浸透しており、リモートワークでも出社でも同様に働けて助かっています。
組織内フローの自動化
自動化についてはGoogle Apps Script(GAS)とZapierを使用しています。
Zapierで簡単にできるものはZapierを使い、それ以外はGASを使うことで以下のような手作業を自動化しています。
- Slackで新チャネルができたことを投稿
- 毎晩その日マージされたGitHub PRのリンクと概要を一覧にまとめてSlackに投稿
- Slack Workflowから障害が報告されたらSlackでインシデント対応チャネルを作成し、また開発対応用にタスクを起票
- 開発メンバーのエンジニアテックブログをクローリングして採用サイトに反映
- Connpassで技術コミュニティが開催するテックイベントのクローリングを行い、Slackに投稿
Slackの新チャネルみたいな簡単なものもあれば、クローラーのような日々手作業で巡回するには少し面倒なものまで作っています。
Slackの新チャネルやGitHub PRの一覧はリモートワークでお互いが見えない状況でもいま何が動いているのかを気づきやすくなります。
他は社内フローで手作業になってしまうところを自動化したり、仕事に集中していても情報収集を効率的にやりたい目的で作ってあります。
特に障害時の開発対応用のタスクを記載することはこれから開発KPIとして導入する予定のFour keysの計測に利用することを考えています。
2. プロダクト設計
プロダクト設計では、Notion, Asana, Figma, Stoplightを使用しています。
NotionからAsanaへ移行中
現在、社内ではNotionのプロダクトロードマップやGitHubの開発タスク管理をAsanaへ移行中です。
詳細の選定経緯については別記事で紹介されるかもしれませんが、Asanaでは個々のタスクを複数のプロジェクトに紐付けられることが非常に便利だなと感じてます。
この機能により、1つのタスクをPdMのタスク管理やロードマップと紐づけるだけでなく、リリース一覧にも紐づけて一覧を作成できています。
デザインとフィードバックのサイクルはFigma
デザインはFigmaでまとめており、デザイン作成→フィードバック→デザイン作成のサイクルをFigma上で積み重ねていってます。
これまではNotionで要件など仕様をまとめていたのですが、Figmaの方にまとめた方がデザインと合わせて見やすいのでは？という考えから試行中だったりします😃
NotionはAsanaへの移行プロジェクトにより今後はミーティングのアジェンダ・議事録などの置き場になりそうです。
API通信の仕様管理にStoplight
開発のAPI通信の仕様はOpenAPI ver.3を使用しており、それをStoplight上で編集しています。
Stoplightで指定できないタグなどもあるので、StoplightによるGUI操作とエディターを使った修正を併用しています。
3. プロダクトソフトウェア領域
プロダクトソフトウェア領域は、全体図で”Front”、”BFF”、”Crawler”、”Backend”、”DB”、”その他”とあげた部分になります。
各領域の採用技術
FrontはViteを使ったReact + TypeScriptの環境で構築しており、ビルドした静的ファイルをkubernetes上でホスティングする構成にしています。
APIとの通信はRESTで行なっており、BFFはGoで軽量なEchoサーバーを構築しています。Crawlerはk8sのCronJobで実行されており、BackendはSQLBoilerというORMを使いながらGoでgRPCサーバーを構築してます。
BFF, Backend, Crawlerはすべてkubernetes内部で実行されており、kubernetes内部はすべてgRPCで通信しています。
DBはCloud SQL上でPostgreSQLを構築しており、そこに地理座標系を扱うためのPostGISを導入しています。
他に、認証としてはAuth0、SMSにTwilio、メール送信にSendGrid、プロダクトの一部でChatGPTを導入しています。
また、全体的に型安全での堅牢性とパフォーマンスを意識しており、FrontではTypeScriptを、BackendではDBスキーマからコードを自動生成するSQLBoilerを採用しています。
マルチプロダクト戦略に準じた設計
弊社ではマルチプロダクト戦略を掲げて、複数のプロダクトを通してサプライチェーンデータベースを構築していくことを目指しています。
そのため、複数プロダクトで相互にデータ通信しやすくするために、BFFとBackendに分割しています。
BFFはFrontのための通信スキーマを持ち、BackendはDBのスキーマを起点とした通信スキーマを持つことで、他プロダクトのBFFからでもBackendのエンドポイントの再利用性を高めています。
4. インフラ
インフラは、全体的にGoogle Cloudとkubernetesに寄せるという意思決定をしています。
先を見据えてGoogle CloudとK8sを全面採用
地理座標系を扱う上でGoogleのMap APIを使いたかったのもありGoogle Cloudを使っており、事業ポテンシャルを踏まえてプロダクトが肥大化することを考慮し、kubernetesの構築を選択しています。
最初はCloud Runでの構築も考えましたが、Cloud Runからkubernetesへの移行コストがかかりそうだったので、全体的にGoogle CloudのManagedサービスに寄せていくことでインフラ構築・保守負荷を下げる方針を採りました。
kubernetesもGKE AutopilotでFrontからBFF, Backend, CrawlerまですべてをKubernetes上にまとめることで、プロダクト全体のデプロイや運用保守を統一的に管理しています。
IaCを筆頭とした自動化
また、インフラのリソース管理は、Infrastructure as Code(IaC)としてTerraformを使っており、デプロイフローはGitHub ActionsとArgoで構築しています。
プロダクトソフトウェアはすべてGitHub ActionsでDockerイメージをビルドしており、インフラ側でArgoCDを用いてデプロイしています。
プロダクトソフトウェアとインフラのすべてのGitHub PRではCodeRabbitを導入することでAIによるレビューの補助がされています。
以前に書いた記事も取り組みの参考にご覧ください。
5. 運用保守
運用保守の面でも各種ツールの導入による環境整備が進んでいます。
E2Eテストの自動化
運用保守では、プロダクトのリリース品質担保のE2EテストとしてAutifyを導入しています。
Autifyによってリグレッションテストを行うことで、リリース対象の機能だけでなく他の主要導線への影響も確認できるように進めています。
サービス稼働状況の可視化
サービス全体の正常性は外形監視だけでなくUptime Robotを通じてステータスページも提供しており、アプリケーションの障害検知・予防でGoogle Cloud Managed Service for Prometheusを導入しています。
また、Sentryを使ってサービスレベルのバグやパフォーマンスを確認しています。
他にもGKEのメトリクスの可視化としてGrafanaを使っており、社内Adminツールを、現在ツール選定中ではありますがローコードツールで構築中です。
プロダクト構造概略
最後に、これらのテックスタックを通じて作っているプロダクト構造の概略図を紹介します。
ユーザーはGKEでホスティングされているFrontサーバーからUIを読み込み、BFFのエンドポイントにリクエストを送っています。
GKE内部では、CronJobとして定期的にクローラーが走って気象庁や電力会社といった情報ソースにアクセスしてBigQueryにデータをためています。
通知などの非同期処理はBackendサーバーからPubSubを通じてBatchサーバーで処理しています。
このようにGKEを中心に各種サービス・DBを接続することで弊社のプロダクトを提供しています。
まとめ
いかがだったでしょうか？
テックスタックの全貌ということだったので、個々の領域の詳細な構成は説明しきれず、ツールも全てを紹介はしきれませんでしたが、弊社の開発の全体感についてなんとなくは理解していただけたのではないでしょうか。
これから、現状のプロダクトを強化・運用していくのはもちろんですが、マルチプロダクト戦略としてこの構成からさらにエンハンスしていく予定です。
テックブログとしてもこの全体像を踏まえて、さらに紹介していければと思っていますのでお楽しみに！
エンジニア採用強化中
株式会社 Resilire (レジリア) では、サプライチェーンリスク管理クラウドサービスResilireの開発メンバーを募集中です。
まずは情報交換程度に気軽に話して聞いてみたいという方もウェルカムです！
Discussion