こんにちは、Baseconnectでエンジニアをしている米丸です。開発部門の組織改善や採用ロールを担当しています。この度、情報発信と業界貢献を目的にテックブログを始めることになりました。パチパチパチ！
Baseconnectでは現在、法人営業向けのクラウド型企業情報データベースサービスであるMusubuとその集客の役割を持つBaseconnect.in、協業企業向けのPartnershipAPIの３つのプロダクトを運用しています。
また、外からは見えませんが、社内向けにMusubu管理システムと企業情報登録システムといったものが存在します。一発目のテックブログということで、今日はこれらの弊社プロダクトの主要な技術スタックをご紹介したいと思います。
私自身はまだ昨年10月にBaseconnectに入社したところなので、社歴のあるエンジニアメンバーにヒアリングして導入経緯なども含めまとめた内容になります。
前提として、Baseconnectでは特定の技術にとらわれずスピードや保守性を重視し、エンジニアで議論をしながら技術選定を行ってきました。バランスを見ながら責務を切り分けられるものを対象にマイクロサービス化を進め、サービスに合わせた技術を選定してきたことで、いくつかの技術をくみあわせた技術スタックとなっています。
技術スタックや利用ツールの全体像としたは以下のようになっています（Baseconnectのエンジニアリングについてまとめた Engineering Recruite Book より抜粋したものです。興味がある方はこちらもぜひご一読ください）。
ここからいくつかピックアップしてご紹介します。
バックエンド
Ruby / Ruby on Rails
Baseconnectの各プロダクトではベースとして Ruby / Ruby on Rails の言語 / フレームワークが用いられています。創業当初、限られたリソースの中で短期間での開発を実現するため、Rubyが採用されました。
採用戦略として、京都の優秀な学生をインターンシップメンバーとして積極的に採用していて、初学者でも習得のしやすいRubyは相性の良さがありました（現在インターンシップメンバーの採用は当時より縮小しています）。その後も、エンジニアが多く採用しやすいことからメインの言語として利用しています。
ただ、Rubyしか使わないと決めているわけではなく、目的に応じて以下のサーバサイド言語も採用しています。
Go（Golang / Go言語）
コンパイラ言語のメリットを活かせる一部のシステムでGo（Golang / Go言語）を導入しています。具体的には、企業情報データベースサービスであるMusubu内で得られた企業情報は、Musubu内でメール配信やアプローチ管理を行えるだけでなく、CSVデータでダウンロードし利用することができるのですが、そのダウンロード時のデータエクスポート要求を処理するサブシステムで、Goが採用されています。
当時、メモリ使用量が大きくシステムを切り分けたかった事があり、その際にコンパイラ言語による処理速度の向上とライブラリなどが軽くなり立ち上げやすくなることを期待してGoを選択しました。また、当時Goの注目度が高かったというのも正直あったそうです笑。
Python
Pythonは、機械学習との相性を考慮し、一部のシステムで導入しています。一つは、Musubuサービスで提供しているマッチ度の算出に用いています。マッチ度は成約確率の高さを表す独自の指標で、成約先企業の特徴ベクトルのクラスタリングを行うことで算出しています。計算には scikit-learn とういう python の機械学習ライブラリを使用し、Kmeans法でのクラスタリングを行っています。
もう一つ、企業情報の名寄せシステムにも用いられています。ユーザーが登録した営業先情報とMusubuが保有する企業情報を名寄せする（同じと思われるものを突き合わせる）システムがあり、SageMakerを利用し機械学習による精度向上をはかっています。
フロントエンド
TypeScript
当初はJavascriptで開発が開始されましたが、徐々に開発規模が大きくなっていく中で安全な開発を行うために、型定義を行えるTypeScriptを導入しました。Musubuの前身であるプロダクトにおいて、ビジネスロジック部分(Model、Service、Redux) のコードから段階的に移行してきており、現在はReact Component 等、ビジネスロジック以外のコードも TypeScript で書くようになっています。
React / Redux
Musubu のフロントエンドではReactを採用しています。また、状態管理のフレームワークとして Redux を利用しています。もともと画面描画は Ruby on Rails のview上で行っていましたが、メイン機能である企業情報検索画面のおいて、動的でリッチなUIを実現し検索体験の向上をはかるために導入されました。
フロントエンドはどんどん新しい技術が出てきてキャッチアップが難しい領域ではあると思いますが、2021年に積極的なリファクタリングを行ったことで、比較的モダンなシステムを取り入れることができていると感じています。いくつかピックアップすると、xstyledやRTK Query を導入しました。
xstyledは、styled-component を拡張したもので、tailwindow のようなCSS指定を props ベースで行えるようになっています。 わかりやすい恩恵としては、テーマカラーの管理がかなり楽になりました。RTK Query は、SWR や React Query の API を Redux で再現したもので、Reduxとの相性の良さを考慮して採用しました。
フロントエンドのリファクタリングの取り組みについては他にも行ってきたことがあるので、また別の記事でご紹介できれば嬉しいなと思います。
データベース
Neo4j
Musubu ではグラフデータベースであるNeo4jをメインDBとして利用しています。グラフデータベースの特徴として、一般的なリレーショナルデータベースにはない、ネットワーク上のデータ構造をもちデータ同士の繋がりを可視化する表現力があることがあげられます。
Baseconnectでは 「世界中のデータを繋げることで、ダイレクトに必要な情報にアクセスできる世界を作る」 ことをビジョンに掲げていて、将来的に企業データだけでなく人物データや与信データといった様々な情報を繋げる構想に向けて Neo4j を採用しました。
一方で、グラフデータベースには苦手なこともあるため、以下に紹介する他のデータベースを組み合わせることで弱いところを補完するようにしています。
Elasticsearch（Elastic Cloud）
企業情報検索システムにて、検索速度を上げるためにElasticsearch（Elastic Cloud）を用いています。Elasticsearchの利用にあたっては、複雑なデータ構成の中でいかにパフォーマンスを向上させるかというところを、試行錯誤しながら取り組んできました。
特に、直近行ったデザインリニューアルでは大幅な検索システムの改善を行ったのですが、その中の技術要件として複数のデータを組み合わせた複合検索を実現する必要があり、技術探索のフェーズを設け課題をクリアしてきました。
※ Elasticsearchは正確には検索エンジンですがグラフデータベースの補完として位置づけているため、このブログ上はデータベースに分類しています。
MySQL
メール配信システムや課金システムといったMusubuのサブシステムでは、MySQL を採用しています。グラフデータベースよりもRDBの方が、表形式での集計といったところがやりやすく管理しやすいという利点があり、採用しています。
データベース全体の課題として、正規化や実行計画などパフォーマンスに影響するところや特徴であるグラフデータベースの利点を意識した設計を、一人ひとりが高いレベルでできているとは言えずまだまだ道半ばというところがあります。
インフラ
AWS
細かいサービスを含めるとキリが無くなってしまうので、（乱暴だと自覚しつつ）ひと括りにまとめてしまいますが、サービス発信環境は基本的にAWSのサービス群を用いて構成されています。GCP や Microsoft Azure ではなくAWSをメインにしているのは、特に深い理由はなくスタートアップ向けのクレジットをもらえたからだそうです笑。同じ理由で当時はGCPも使っていたようですが、管理のしやすさのためAWSに集約しました。
Kubernetes
Baseconnectでは Amazon EKS（AWSマネージドのKubernetesコントローラー）を導入しています。VagrantからDockerに置き換える過程で導入されました。導入のきっかけは、当時コンテナを使わないことにリスクを感じたメンバーからの発案によるもので、Musubuのサブシステムである課金サービスから段階的に対応していきました。
BigQuery（GCP）
BIエンジニア向けの分析用データウェアハウスとしてBigQueryを用いています。データウェアハウスにはBigQueryを使っていますが、データレイクにはS3を使っていて、GCPとAWSのいいとこ取りのような使い方をしています。データ分析ソフトウェアとしてはTableauを使っていましたが、「データの民主化」を合言葉にBIエンジニア以外も気軽にデータが見れる環境を整えるため、最近 looker に移行しました。
Terraform
主にインフラ管理の権限移譲の課題を解決することを目的に、SRE/BIチームにより導入されました。インフラの設定変更や立ち上げを行う際に本番環境などはSREメンバーに権限が偏っていたため、SREチームがボトルネックになる課題がありました。絶賛進行中ですが、Terraform導入によりインフラのコード化を行い、SREメンバーはコードをレビューし許可を出すだけで実行に移せるようにフローを変更することで、ボトルネック解消をはかっています。BIでは分析基盤の属人化を解消するためにTerraformによるコード管理が使われています。
DataDog
プロダクトの成長にともないパフォーマンス監視の優先度も上がってきました。当初のCloudWatchからZabbixに移行し、直近ではDataDogへの入れ替えを行っているところです。Zabbix では、エスカレーション基準の設定や異常検知などの機能が弱く、また他のモニタリングツールも併用しているためツールの運用負荷が高いといった課題があり、統合監視ツールであるDataDogを導入することになりました。 DataDogを使ってみたメンバーの感想では、UIが直感的でめちゃくちゃ使いやすいとのことで、開発者体験としてもよさそうでした。
Baseconnectプロダクトを構成する主要な技術スタックをご紹介しました。ミドルウェアやライブラリといったレイヤーまで含めるとご紹介できる技術スタックは他にもありますが、長くなりすぎるのでここまでとします。今後も、新しい挑戦もしつつ不用意に手を広げすぎないよう、バランスをみた技術選定をおこなっていきたいです。
もし今後の技術選定に関わっていきたい方や、もう少し詳しい話を聞いてみたいという方、ぜひカジュアルにお話ししましょう！ Baseconnectではエンジニアメンバーも絶賛募集しています！
