こんにちは、「ドンピシャ印刷」開発チームです。 郵便番号から住所を変換する無料ツールを支える12万件のデータ活用について、連載形式でお伝えしてきました。 今回は、この膨大なデータをエラーなく確実にシステムへ登録するために採用した、GCP（Google Cloud Platform）の構成についてご紹介します。 大規模なデータを扱う際、避けて通れないのが「実行時間」の制約です。
Cloud Functionsにおける「時間」の制約
私たちがシステムの一部として利用しているCloud Functions（第2世代）は、メンテナンスが不要な便利な実行環境ですが、処理時間には一定の制限があります。 HTTPリクエストをトリガーにする場合、タイムアウトの上限は最大60分です。一見長く感じますが、12万件の住所データを前回の記事で触れた「500件ずつの制限」 を守りながらデータベースに書き込んでいくと、この制限時間内にすべてを終わらせるのは、確実性の面でリスクが伴います。
処理を小分けにする「分散処理」という選択
当初、一括でのデータ登録も検討しましたが、12万件ものレコードを一度に流し込もうとすると、ネットワークの一時的な不安定さなどで処理が中断された際、どこまで完了したかの把握が難しくなります。 そこで、処理の確実性を高めるために以下の構成を採用しました。
- タスクの分割: まず、12万件のデータを数千件ずつの小さな単位に分割します。
- Cloud Tasks（待ち行列）の活用: 分割したタスクをCloud Tasksという「順番待ち」を管理するシステムに預けます。
- 非同期での実行: Cloud Tasksが適切な間隔で処理を呼び出し、データベース（Firestore）への書き込みを少しずつ実行します。
データベースを守る「流量制限」
Cloud Tasks を使うことで、データベース（Firestore）への負荷を一定に保つ「流量制限（レート制限）」が可能になりました。 一度に大量の書き込みをぶつけるのではなく、システムが最も安定して処理できるペースで淡々とデータを流し込む。この控えめながら着実なアプローチが、データの整合性を守り、最終的にユーザーの皆様が利用する際の「爆速検索」へと繋がっています。
最後に
「検索ボタンを押すと一瞬で住所が出る」という日常的な機能。その裏側では、こうした基本的な分散処理の設計を丁寧に行うことで、データの整合性とサービスの安定性を維持しています。 ドンピシャ印刷では、こうした目に見えにくいインフラの設計についても、ユーザーの皆様が安心して事務作業を続けられるよう、標準的なベストプラクティスに基づいた運用を心がけています。 12万件の最新データを搭載した住所検索ツールを、日々の業務にぜひご活用ください。
