はじめに
CastingONEでバックエンドエンジニアをやっている清水です。
CastingONEではCSVファイルを用いたスタッフの一括登録機能があり、
先日登録機能に変更を加え上限2000件から10万件にすることができたので、その内容について紹介させていただきます。
プロジェクトの背景
CastingONEのシステムを利用されているお客様の規模が大きくなり、その結果として一括登録できる件数の上限引き上げの要望が増えてきました。
今回はこの要望に応えるために、一括登録の最大処理件数を2000件から10万件まで拡張しました。
これにより、より大規模なデータの一括登録が可能になり、お客様のニーズにより柔軟に対応できるようになりました。
今回は技術的になぜこの変更が必要になったのか、どのように実現したのかをご説明します。
技術的に変更が必要になった理由
以前のアーキテクチャでは、フロントエンドでCSVファイルをパースし中身のデータを全部ボディとして送ってもらいサーバー側で登録処理を行っていました。
しかし、Cloud Runにはリクエスト・レスポンスサイズが最大32MiBまでという制限があり、一度に2000件程度の処理しか行えませんでした。
どのように登録数の上限を拡張したのか
上記の問題に対してアーキテクチャの構成をCloud Run ＋ Eventarc + Pub/Subに変えることでCSVファイルでの一括登録機能の上限を10万件まで引き上げることができました。
具体的な処理の流れについては旧アーキテクチャと比較しながら説明していきます。
旧アーキテクチャの処理フロー
以下の内容が旧アーキテクチャの登録時のデータフローと図になります。
旧アーキテクチャはかなりシンプルでフロントエンドからアップロードされたCSVファイルを登録するエンドポイントが存在するだけです。
新アーキテクチャの処理フロー
以下の内容が新アーキテクチャの登録時のデータフローと図になります。
データフロー
-
CSVファイルをGCSにアップロードするために、署名付きURLの取得を行うAPIを呼び出し署名付きURLを発行します。
-
取得した署名付きURLを利用して、CSVファイルをGCSにアップロードします。
-
CSVファイルがGCSにアップロードされると、Eventarcはアップロードのイベントを検知し、Pub/Subにメッセージを送信するAPIを呼び出します。
- Pub/Subメッセージが送信されると、Pub/SubがDBに登録するAPIが呼び出し、DBへの取り込み処理が行われます。
新アーキテクチャの選定理由
今回のアーキテクチャを選定した理由2つあります。
1つ目が、GCS + Eventarc + Pubsubの構成がGCP側で推奨している構成だったためです。
CastingONEでは他のところでGCSを利用しているので、GCPを用いた構成にすることは決めていました。
GCPを前提とした上で、イベント駆動な構成をするのに参考にしたのがGCPのドキュメントで推奨している構成でした。
参考にしたドキュメントが以下の内容です。
2つ目が、タイムアウト時間の取り扱いが容易になるためです。
1つのエンドポイント内で2000件から10万件への処理数の拡張が困難だった理由の一つに、全てのデータを処理しきる前にCloud Runのタイムアウトエラーが発生してしまう問題がありました。
これに対する解決策として、データの登録処理を複数回に分けて1エンドポイントあたりの処理時間を短縮するようにしました。
具体的には、最初にサーバー側でCSVレコードを500件ずつに分割した上で、Pub/Subにメッセージを送信し、500件単位で登録処理が行われるにしています。
これによって大量のCSVレコードをタイムアウトエラーが発生することなく処理し切ることができるようになりました。
おわりに
弊社ではいっしょに働いてくれるエンジニアを募集中です。社員でもフリーランスでも、フルタイムでも短時間の副業でも大歓迎なので、気軽にご連絡ください！
Discussion