公開日 2024/06/26更新日 2024/12/09

モダンな開発環境のBtoB SaaSアーキテクチャ特集技術選定のポイントと今後の展望

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

ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております

株式会社あしたのチーム

ashitateam 会員限定コンテンツ無料登録してアーキテクチャを見る
あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス：パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。

アーキテクチャ選択の背景や意図

サービス立ち上げ初期はエンジニアの数が少ないこともあり、開発メンバーが開発と兼任でインフラの面倒を見ていました。このような事情から、できるだけコストをかけずに管理、運用できるマネージドサービスや SaaS を積極的に採用しています。
コンテナオーケストレーションには他プロダクトですでに使用実績があり、慣れているメンバーも多い AWS Fargate を採用しました。認証基盤には Auth0 を採用することで、複雑な認証周りの処理やユーザ管理を少ないコストで迅速に実装しています。監視には Datadog の各種機能を惜しみなく使い、情報を Datadog で一元管理することで、運用効率を高めています。

現在のアーキテクチャの課題と今後の改善予定

喫緊の課題としては、開発中の機能を検証するために使用できる環境数が限られており、メンバー間で環境の取り合いが発生する問題があります。
AWS Proton を使って新たに検証用の環境を構築するための仕組みを用意しているのですが、検証の都度環境を用意するには手間と時間がかかり過ぎるため、ほとんど活用されておらず、常設の環境が使いまわされています。本問題の対策として、GitHub の PR 毎に検証環境を用意する仕組みを検討しています。

【サービス公式サイト】
https://www.ashita-team.com/
https://www.ashita-team.com/cateras/

【株式会社あしたのチームのエンジニア求人】
「働く誰もが、主人公に」！誰もがわくわく働ける世界を創るバックエンドエンジニア募集【福利厚生&働きやすさ◎】等
https://findy-code.io/companies/513/jobs

弁護士ドットコム株式会社

bengo4 会員限定コンテンツ無料登録してアーキテクチャを見る
弁護士ドットコムは「プロフェッショナル・テックで、次の常識をつくる。」をミッションとして、人々と専門家をつなぐポータルサイト「弁護士ドットコム」「ビジネスロイヤーズ」「税理士ドットコム」、契約マネジメントプラットフォーム「クラウドサイン」を提供しています。
「クラウドサイン」は契約締結から契約書管理までをデジタルで完結させる契約マネジメントプラットフォームを提供するプロダクトです。導入社数は250万社を超え、地方自治体への導入シェアも約70%になるなど、非常に多くのお客様にご利用頂いております。

アーキテクチャ選択の背景や意図

クラウドサインのアーキテクチャの特徴は以下の３つになります。

シンプルなインフラ構成
3層アーキテクチャを基本としたシンプルなインフラ構成を採用しています。一方、内部構成としてはアプリケーションの肥大化を防止するために、分離可能な機能を別サービスにすることでメンテナンスや開発効率を向上させる仕組みとしています。
高可用性と迅速な開発インフラの実現
24時間365日サービスを提供しながら日々の開発をスピーディに行うため、テストやデプロイはすべてCI/CDで実施しています。また、障害発生時の顧客影響を最小限にするために CloudWatch Evidentlyを利用してカナリアリリースを行っています。
安全なデータ保管
機密情報は暗号化し別リージョンにもデータのバックアップを保存することによりデータの安全性とビジネスの信頼性を向上させています。

これらの取り組みにより、安心・安全を保ちながらも、顧客価値の提供頻度や開発者体験を向上させています。

【サービス公式サイト】
https://www.cloudsign.jp/

【弁護士ドットコム株式会社のエンジニア求人】
【バックエンドエンジニア／EM候補】クラウドサインのエンジニア組織拡大を牽引するEM候補等
https://findy-code.io/companies/58/jobs

株式会社kubell（旧Chatwork株式会社）

chatwork 会員限定コンテンツ無料登録してアーキテクチャを見る
「働くをもっと楽しく、創造的に」をミッションに掲げる株式会社kubell（旧Chatwork株式会社）は、DXを通じた中小企業の労働生産性向上に取り組んでいます。今回は、ビジネスチャット「Chatwork」のメッセージング基盤システムを支える技術についてご説明します。

アーキテクチャ図の解説

WEB: PHPで実装されたサーバサイドのシステム(現行システム)。メッセージに関する機能はFalconシステムに委譲する。データベースにAmazon Auroraを利用する
Falcon: メッセージング基盤システム
- WRITE API: メッセージ投稿・編集・削除を受け付ける書き込み用APIサーバ。リクエストが成功するとKafkaにメッセージイベントを書き込む
- READ API: メッセージの取得、レンジ取得などを受け付ける読み込みAPIサーバ
- READ MODEL UPDATER: Kafkaに書き込まれたイベントを基にHBaseにリードモデルを構築するサーバ
- SPARROW FORWARDER: リードモデル完了のイベントをPHP側に通知するサーバ

アーキテクチャ選択の背景や意図

「Chatwork」の開発は2010年に開始され、当初は内製フレームワークを用いた社内向けシステムとして運用されていました。2013年には公開サービスとしてリリースし、機能追加を続けましたが、その過程で技術負債も積み上がりました。総コード量は30万行を超え、中心的なクラスは1万行にも達しています。2014年からシステム刷新プロジェクトが始まりましたが、さまざまな課題があり2016年に中断の決断を下しました。その後、戦略を変更し、メッセージング機能に絞って新しいアーキテクチャへの移行を進めています。

プロジェクト再起動にあたっては、もっとも重要性が高いメッセージング機能を選定し、開発対象を絞り込むことでプロジェクトのリスクを最小限に抑える方針を取っています。新しいアーキテクチャに移行することで技術負債を解消し、将来的なシステムの拡張性を確保できると考えました。

新アーキテクチャの技術選定にあたっては、「高スループット・低レイテンシの実現」、「可能な限り障害に対して自己回復力を持つ」という要件を定義し、スケーラビリティと耐障害性に定評があるアプリケーションフレームワークとしてScala/Akkaを採用しています。加えて、ストレージにはHBaseとKafkaを採用し、アーキテクチャとしてはCQRS+Event Sourcingを採用しました。これによって書き込みと読み込みを分離することでスケーラビリティと耐障害性を確保しました。

現在のアーキテクチャの課題と今後の改善予定

このアーキテクチャにはいくつかの課題があります。
まず、メッセージ部分のデータベースをマイクロサービス化したことは成果ですが、主なビジネスロジックは依然としてPHP側の現行システムに残っています。現状のアーキテクチャとしては、変更頻度の高いビジネスロジックの分割統治には課題が残るためです。

また、HBaseの運用にも課題があります。HBaseは性能が高い反面、自前でクラスタを構築しているため運用コストが高く、さらにHBaseのためのLinuxディストリビューションがEOLを迎え利用できなくなるため、根本的な対策が必要になります。

今後はアプリケーション設計の改善を予定しております。現在はPHP側にあるビジネスロジックをビジネスドメインを意識しながら段階的に整理していく最中です。また、HBaseの運用コストを下げるため、マネージドデータベースへの移行を検討しています。この移行によって運用負担の軽減とシステムの信頼性向上を見込んでいます。

【サービス公式サイト】
https://go.chatwork.com/ja/

【株式会社kubell（旧Chatwork株式会社）のエンジニア求人】
【導入社数：44万社突破！】シニアフロントエンドエンジニアとして「Chatwork」の更なるグロースを目指して開発を進めるチャンス〈フレックス／ハイブリッド勤務OK〉等
https://findy-code.io/companies/545/jobs

株式会社IVRy

ivry 会員限定コンテンツ無料登録してアーキテクチャを見る
私達は、最短5分・月額2,980円から対話型音声AI SaaS「IVRy」を開発・運営しています。リリースから約3年半で、業種や都道府県を問わず、累計14,000を超えるアカウントから導入/累計着電数2,000万件を突破するなど、日々成長を続けています。

アーキテクチャ選択の背景や意図

IVRyのメイン機能はAWS上で構築されており、音声通話部分、設定画面用API、バッチ処理に分かれています。極力マネージドサービスを利用し運用コストを削減しています。
フロントはCloudFrontを利用し、コンテナプラットフォームはECS Fargate、APIのアプリケーションはRuby on Railsで実装、データベースはAurora PostgreSQLを使用した構成です。
通話の量は社会的なイベントによってスパイクすることもあります。そのため、音声通話部分は設定系のAPIとは切り離し、可用性・拡張性の観点からDynamoDBを利用し、設定内容の参照や通話ログの保存を行っています。また、Blue/Greenデプロイによる切り替えを行い、ダウンタイムと機能のロールバックに関するリスクを軽減しています。音声通話の処理内でChatGPT(Azure OpenAI Service)へのリクエストを行うこともあります。
料金計算や、通話後の書き起こしなどは非同期ジョブで処理しています。
インフラ構成はIaC(Terraform)で管理し、CI/CDは主にGitHub Actionsを利用しています。

現在のアーキテクチャの課題と今後の改善予定

通話部分のUXをより向上させるべくobservabilityの向上、ボトルネックの発見/解消に取り組んでいきたいです。関連ログ/イベントなどを集約、モニタリングし、より信頼性の高いサービスを提供していきたいと考えています。また、チームの開発リソースを、価値を生み出し素早く届けるという本質に集中できる状態を維持、向上し続けたいです。

◆執筆：AI Engineer / Engineering Manager　町田雄一郎　@machida_ivry

【サービス公式サイト】
https://ivry.jp/

【株式会社IVRyのエンジニア求人】
【シリーズC資金調達！】音声領域SaaSの開発を進めるサーバーサイドエンジニアを募集〈フルリモートOK / フレックス〉等
https://findy-code.io/companies/1610/jobs

株式会社カケハシ

kakehashi
カケハシは「日本の医療体験を、しなやかに。」をミッションとし、服薬指導のサポートも行えるクラウド型電子薬歴システム「Musubi」、薬局と患者さんをつなぐおくすり連絡帳システム「Pocket Musubi」、薬局向けの在庫管理・発注システムである「Musubi AI在庫管理」などを開発しています。
Musubi AI在庫管理は、AIによる高精度な需要予測により、これまで人的オペレーションに依存していた発注業務を半自動化し、薬局の業務効率化と医薬品の欠品・在庫リスク軽減を実現しています。

アーキテクチャ選択の背景や意図

マネージドサービスの積極採用
Musubi AI 在庫管理には、一般的な医薬品の在庫管理システムとして開発当初から必要とされていた機能が多くあり、これまでたくさんの機能追加を重ねてきました。ユーザーヒアリングやユーザーモニタリングから得られたフィードバックを基に要件を固め、素早く開発をして顧客価値の提供につなげるため、 LambdaやMWAA、Glue等のマネージドサービスを積極的に採用し、機能開発に注力できるようにしています。
独立したアルゴリズム開発
Musubi AI 在庫管理の一番の強みであるAIによる需要予測については、データサイエンティストや機械学習エンジニアがアルゴリズムを開発しています。アルゴリズムの開発はWebアプリケーション開発とは開発サイクル等が異なるため、MWAAやGlueを用いてデータ連携基盤を用意し、独立して開発が行える環境を用意しています。なお、機械学習、推論処理はStep Functionsを利用して効率的に処理を実行しています。
データレイクハウスの活用
アジャイルにおける素早い価値提供の中で、PdMやデータサイエンティスト等がデータドリブンで意思決定を行うデータ基盤は必要不可欠です。一方で、Musubi AI 在庫管理で扱う処方箋等のデータは個人情報の中でも機微情報に当たるため、取り扱いには細心の注意が必要です。そこでMusubi AI 在庫管理ではデータ基盤としてDatabricksを採用し、適切な権限制御や匿名化を行いつつ必要なデータに素早くアクセスできる基盤を整えています。

現在のアーキテクチャの課題と今後の改善予定

徐々に導入いただく薬局さまも増え、その規模も大きくなる中で、大企業特有の機能追加を随時行っている最中ではあるものの、当初想定していた機能についてはある程度揃えることができてきました。機能追加を優先する必要があった初期開発フェーズから、長期的に効率よく保守運用するフェーズに移行するにあたり、システム全体をシンプルに再構築する必要があると考えています。
また、これまでのAI在庫管理の開発で得た知見とデータを元に、より良いAIサービスへ拡充する検討も進んでおり、社内の他プロダクトとの連携などにも注力していくことになると考えています。

◆執筆：Service Development Division, SCMドメイン, ソフトウェアエンジニア　沖卓生　@takuokl

【サービス公式サイト】
https://musubi.kakehashi.life/ai-zaiko

【株式会社カケハシのエンジニア求人】
【累計資金調達額149億円】薬局のDXを推進！既存プロダクトのデータを生かし患者さまの医療体験向上に貢献する顧客データ基盤エンジニアを募集等
https://findy-code.io/companies/544/jobs

株式会社カオナビ

kaonavi 会員限定コンテンツ無料登録してアーキテクチャを見る
『カオナビ』は、社員の個性・才能を発掘し戦略人事を加速させるタレントマネジメントシステムで、企業規模や業種問わず3,600社以上（2024年3月末時点）にご利用いただいております。
今回は昨年リリースした「サービスブリッジ」という他システムとのデータ連携機能のアーキテクチャ図について説明します。「サービスブリッジ」では、直感的なUIでデータ変換ルールを定義することでシステム間のデータ構造の差異を吸収し、他システムから『カオナビ』へ、または『カオナビ』から他システムへのデータ連携を自動化できます。

アーキテクチャ選択の背景や意図

連携データの取得・加工とデータ登録の処理をそれぞれ分割して LambdaとECS/Fargateで実装し、Step Functionsをインターフェイスとして連携させるサーバレスアーキテクチャを採用しました。
このような構成となった主な理由は以下の3点です。

　データ量が小・中規模のお客様の利用を想定していた
　バッチ処理でエラーが発生した場合のリトライを細かい単位で行いたかった
　コスト観点も含めてスモールスタートで開発し、徐々に機能追加・拡張を進める方針を取った

当初は連携データの取得・加工処理もLambdaで実装していましたが、Lambdaのタイムアウト制限(15分)をオーバーすることもあったため、ECSタスクに置き換えることで解決しました。
当初の想定よりも開発スケジュールが大幅に早まり、本格的な設計開始から2〜3ヶ月でのリリースが求められましたが、開発初期のスピードが出しやすい傾向にある点でもサーバレスのメリットがありました。

現在のアーキテクチャの課題と今後の改善予定

機能追加に伴いLambdaやS3バケットなどリソースが少しずつ増加することで構成が複雑になっていく傾向にあるため、少しずつLambda→ECS/Fargateへの移行を検討しています。
例えば、ユーザがブラウザから連携データをファイルアップロードする機能があります。この機能では、API Gatewayのペイロードサイズの制限(10MB)を回避するため、S3バケットの署名付きURLをアプリケーションで発行し、ユーザがファイルをアップロードする際に利用しています。ファイルアップロードをトリガーに、S3バケットのイベント通知をLambda関数に発行し、バッチ処理の入力としています。
ALB+ECSでWeb APIを置き換えることでこの制約を解消し、インフラアーキテクチャを簡素化できることが期待されます。

◆執筆：プロダクトデベロップメント本部技術基盤部インフラグループ　水谷圭佑　@m1ztch

【サービス公式サイト】
https://www.kaonavi.jp/

【株式会社カオナビのエンジニア求人】
〈フルリモート/スーパーフレックス/副業OK〉シェアNo. 1のタレントマネジメントシステムを進化させるバックエンドエンジニア（Go）を募集等
https://findy-code.io/companies/503/jobs

株式会社LayerX

layerx 会員限定コンテンツ無料登録してアーキテクチャを見る
LayerX「すべての経済活動を、デジタル化する。」をミッションに掲げるSaaS+FinTechスタートアップです。今回は、法人支出管理サービス「バクラク」のアーキテクチャについてご説明します。

アーキテクチャ選択の背景や意図

バクラク事業部では「経費精算」「請求書受取」「ビジネスカード」など法人支出管理に関わる複数のプロダクトを提供しています。
お客様があるプロダクトを一つだけ利用するだけでなく、複数のプロダクトを利用していただくことで共通のデータを統合したシームレスでより良い体験を提供することを目指しています。これを実現するにはプロダクト間の多様な連携が不可欠です。
そこで、プロダクトを跨いで集約されたGraphQLスキーマを導入し、GraphQLサーバ (graphql-gateway) を中心とするアーキテクチャに移行しています。各プロダクトのウェブアプリはgraphql-gatewayに問い合わせることで必要な情報にアクセスします。graphql-gatewayの裏側では、Protobufで定義した責務を実装するGoのConnect (https://connectrpc.com/) サービスが多数動作しており、各プロダクトの特定ドメインのデータを取得したり、またはプロダクトによらず共通で利用できるデータをサーブしたりします。graphql-gatewayとConnectのサービスは、ビジネスドメインに集中するべくコード生成を活用したmonorepoで開発しています。

現在のアーキテクチャの課題と今後の改善予定

ドメインの内部インタフェースのConnect化とgraphql-gatewayによるプロダクトを跨いだ集約の実現はこのアーキテクチャの目標の1つですが、まだ道半ばであり絶賛進行中です。一方で従来のプロダクトごとのBackend APIを新しいmonorepoのアーキテクチャとどのように・どれくらいの期間やスコープで統合していくかなどは引き続き向き合っていく必要があります。

また、monorepoで開発するConnectのサービスは、可能な限り疎結合になるように小さい単位で論理的に分割されています。この論理的なサービスは物理的なECS FargateのServiceと一対一でマッピングするという設計を当初行いました。それから時が経ちサービス数は順調に増加し、執筆時点では50+のサービスが存在します。チーム数の増加は緩やかなこともあり、物理的なECS Serviceに論理的なサービスを集約させることでインフラやデプロイの取り回しを改善する計画を立てています。

◆執筆：バクラク事業部 Platform Engineering部 DevOpsチームテックリード　@itkq

【サービス公式サイト】
https://bakuraku.jp/

【株式会社LayerXのエンジニア求人】
【Go, TypeScript/フルリモート/地方在住可】ソフトウェアエンジニア_バックエンド等
https://findy-code.io/companies/485/jobs

株式会社マネーフォワード

moneyfoward 会員限定コンテンツ無料登録してアーキテクチャを見る
マネーフォワードは、お金に関する悩みや問題を解決する手助けとなるサービスを開発している会社です。現在は、個人向けの「マネーフォワード ME」と法人向けの「マネーフォワードクラウド」を中心に事業を展開しています。今回は「マネーフォワードクラウド」についてご説明します。

アーキテクチャ選択の背景や意図

本構成のコンセプトは開発チームの自律性です。
マネーフォワードには多くのサービスと開発チームがあります。その開発チームのサイクルを、可能な限り、他チームに依存せずに進められるようにしたいです。守らなくてはいけないポイントはポリシー等で縛りつつ、開発するサービスのコンテナやAWSリソースは、KubernetsとTerraformのマニフェストを利用し、他に依存せずに構築できるようにしています。

構築する前は、サービス毎に開発チームがあり、インフラは共通のインフラチームがまとめて見てコーディング以外の多くのことを担当していました。サービス・開発チームの数が10程度のときは、その体制、役割分担が競争力を生んでいたと思います。開発チームはアプリケーションの開発に集中でき、認知負荷が低い状態です。その他の仕事はインフラチームの学習が進み、効率性も高まっていました。しかし、プロダクトの数が増え、開発体制が大きくなると、効率性では賄えず、共通のインフラチームがボトルネックになってしまうようになり、今のように開発チームの自律性を重視したアーキテクチャにしています。

現在のアーキテクチャの課題と今後の改善予定

我々のアーキテクチャはDevOpsを前提に設計されています。
しかし、クラウドの進化や私たちのアプリケーションの増大・複雑化により、開発者が把握しておくべきことが増大の一途であり、開発者の認知負荷を大きく上げてしまっています。

DevOps自体は素晴らしいプラクティスだと思うのですが、規模と共に形を変えなくてはなりません。我々も昨今、注目を集めているプラットフォームエンジニアリングをより意識して取り組んでいく必要を感じています。私たちのプラットフォームは抽象度を高め、開発チームが必要なものを簡単かつ素早く提供し、より開発に集中できるように変わっていかなくてはいけません。
以下のような指針がキーになってくると考えています。

標準化
自動化
抽象性
持続性
総合性

このような指針と全体感を見て、どのような戦略で改善していくべきか、今まさに考えています。

◆執筆：サービス基盤本部本部長　鈴木陽介　@syou1024

【サービス公式サイト】
https://biz.moneyforward.com/

【株式会社マネーフォワードのエンジニア求人】
【CTO室_Java】サービスを横断的に支える|マネーフォワードの共通基盤アプリケーション開発を担うバックエンドエンジニア募集！等
https://findy-code.io/companies/124/jobs

Sansan株式会社

sansan 会員限定コンテンツ無料登録してアーキテクチャを見る
Sansanでは、営業DXサービス「Sansan」や名刺アプリ「Eight」、インボイス管理サービス「Bill One」、契約データベース「Contract One」を国内外で提供しています。本記事では「Bill One」についてご紹介します。

アーキテクチャ選択の背景や意図

Bill Oneではマイクロサービスアーキテクチャを採用し、業務ドメインごとにサービスを分割しています。各マイクロサービスは一つのチームがフルサイクルで開発を担当することで、コードの規模とコミュニケーションコストを抑えつつ、開発速度と保守性を高めています。
マイクロサービスの実行環境にはGoogle Cloud Runを全面的に利用しています。Cloud Runは自由度の高いコンテナ環境のフルマネージドサービスで、立ち上げ期のコストパフォーマンスと拡大期のスケーラビリティを両立しやすい特徴があります。それにより、トラフィックの変動に関係なく、さまざまなマイクロサービスを一貫した仕組みで運用できます。
マイクロサービス間でデータのやり取りが必要な場合には同期的な通信は避け、Cloud TasksやPub/Subによる非同期メッセージングを採用しています。あるサービスに障害が起きても他のサービスがその影響を受けにくくなります。

現在のアーキテクチャの課題と今後の改善予定

今後の改善予定の一つは、現在のユーザーニーズに合わせたマイクロサービスの再分割です。Bill Oneは4年前のサービスローンチ以来、ユーザー体験の向上を目指して機能の追加・拡張をし続けており、現在は20を越えるマイクロサービスを開発・運用しています。初期に開発したマイクロサービスは機能追加とともにコード規模が肥大化しているため、マイクロサービスを再分割していきます。
もう一つは、マイクロサービスアーキテクチャをより洗練化し、開発のアジリティーをさらに高めることです。これまでBill Oneは業務ドメインごとに独立したマイクロサービスを開発することでアジリティーを持たせてきました。今後は、マイクロサービス群を横断する共通機能を基盤化すること、そしてマイクロサービス間をより疎結合にするために非同期通信のメカニズムを Cloud Tasksから Cloud Pub/Subへ移行することを推進し、より高いアジリティーを目指します。

◆執筆：技術本部 Bill One Engineering Unit Core Businessグループ　柳浦豊

【サービス公式サイト】
https://bill-one.com/

【Sansan株式会社のエンジニア求人】
【リモートOK / フレックス】日本最速で成長しているプロダクト「Bill One」のテクニカルリード募集等
https://findy-code.io/companies/173/jobs

株式会社SmartHR

smarthr 会員限定コンテンツ無料登録してアーキテクチャを見る
SmartHRは、クラウド人事労務ソフト「SmartHR」を開発しています。労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会の実現を目指し、働くすべての人の生産性向上を後押ししています。

アーキテクチャ選択の背景や意図

SmartHRでは、Google Cloudのマネージドサービスを積極的に利用しています。過去、プロダクトによってインフラ構成が異なるなど、運用管理に課題がありました。利用していたDBaaS（Database as a Service）のサービス終了が予期されたことを機にアーキテクチャを見直し、インフラの運用・学習コストが低く、エンジニアがプロダクトの開発に集中できるような構成へと移行しました。
プロダクトごとにインフラは独立していますが、ほぼ同じ構成となっています。Webサーバーにはスパイクアクセスにも耐性があるCloud Runを採用しています。一方非同期処理は、処理が長時間になるものもありCloud Runは不向きなため、AppEngineを併用しています。プロダクトごとにデータを管理していますが、従業員情報などの共通データはSmartHR基本機能で保持しています。

現在のアーキテクチャの課題と今後の改善予定

SmartHRは、人事データベース機能を提供しており、最新の従業員情報の他に変更履歴を保持しています。変更履歴の実現のためBiTemporal Data Model（参考資料）を採用しており、通常よりもレコード増加量が大きくなっています。現在、従業員情報だけで数億レコードがあり、データベースのパフォーマンスやスケーラビリティに課題を抱えています。
この課題に対し、単一データベースで稼働している現在のアーキテクチャから、シャーディングやリードレプリカを導入することで課題解消できないか検討しています。また、Google Cloudが提供するAlloyDB（参考資料）の利用も検討しています。

◆執筆：技術統括本部労務プロダクト開発本部　三上拓也（みかみたくや）　@mkmn252

【サービス公式サイト】
https://smarthr.jp/

【株式会社SmartHRのエンジニア求人】
フルフレックス/フルリモートOK｜労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる！シニアウェブアプリケーションエンジニア（バックエンド）等
https://findy-code.io/companies/334/jobs