カオナビの「サービスブリッジ」のインフラアーキテクチャ図

『カオナビ』は、社員の個性・才能を発掘し戦略人事を加速させるタレントマネジメントシステムで、企業規模や業種問わず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/