たくさん同時に送信されてくるデータを、AWSを使ってまとめてkintoneに登録してみる話 (前編)

公開日：2025-01-27

注意

本記事は情報提供を目的としており、本記事の内容は無保証、サポートの対象外です。
サポート窓口、問合せ窓口にご質問をいただいても対応いたしかねますのでご了承ください。

システム開発グループ テクニカルマネージャーの浅利です。

今日は、AWS と kintone を使った、技術的な話をしたいと思います。
具体的には、大量の同時登録がある場合に、Amazon SQS を使って kintone にまとめて登録する方法についてです。

目次

対象:

kintone と AWS の知識が多少ある方🙇‍♂️

今回のお題: フォーム上で入力して、kintoneに登録する Webアプリ

例えばお問い合わせフォームのような、フォーム上で入力して登録ボタンを押すと kintone アプリに１レコード追加されるWeb画面、というのを使ったことがあるかもしれません。
Web画面側は kintone アカウント不要でお手軽に登録でき、レコードも kintone アプリに入ってくるため、非常に便利です。

しかし、１日に数件とか数十件とかなら問題ないんですが、ピーク時１分間に数百件のような大規模な同時アクセス・同時登録がある、という場合はどうでしょう？

通常の設計では、大量の同時登録が発生すると、以下のような問題が出てきます。

1. 同時アクセス数の制限

kintone のAPIには、同時アクセス数が1つのドメインにつき100まで、という制限があります。同時アクセス数が上限を超えるとエラーになるため、正常にデータを登録できなくなる可能性があります。
その結果、フォーム画面にエラーが表示されてしまったり、利用者が登録しようとしたデータが kintone に登録されてない、といったことが発生してしまいます。

2. 1日に実行できるAPIリクエスト数の制限

kintone のAPIには同時アクセス数の制限だけでなく、1日に実行できるAPIリクエスト数の制限があります。通常、1日1万リクエストまでです。(ワイドコースの場合は1アプリごとに1日10万リクエストまで)

もし同時アクセス数の制限にひっかからなくても、1日合計でこのリクエスト数(=レコード登録数)を超えてしまうかもしれません。

3. システム負荷 等

上記の制限に引っかからなかった場合でも、アクセス集中によって kintone へ負荷がかかります。すると、kintone アプリの動作が重くなったりといったことが発生するかもしれません。

解決策: いったんSQSに入れて、kintoneへはまとめて登録

そこで解決策としては、kintone へ1件ずつ登録するのをやめて、複数件まとめて登録するようにします。kintone API には複数レコード登録APIが用意されていますので、それを使うことで最大100件まとめて登録することができます。

まとめて登録するためには、大量のリクエストが来てもすぐに kintone へ登録するのではなく、一時的にどこかにためておいてある程度たまったらまとめて処理するようにします。
今回は、Amazon SQS（Simple Queue Service）にキューイングし、複数件まとめてキューから取り出して、kintone にも複数レコード登録をする形にしました。

構成

  1. フォーム送信時に呼ばれる AWS Lambda
    Webフォームから送信時に、API Gateway または関数URLにて この Lambda が実行されるようにします。この Lambda は、送られてきたフォームの内容を SQS に登録します。
  2. フォームの内容を一時的に格納する Amazon SQS
    フォームの内容を一時的にキューイングするキューを用意します。
    キューの種類は「標準キュー」とします。(後述⇒注意点1)
  3. SQS をトリガーにして、kintoneに登録する AWS Lambda
    SQS にメッセージが入ったのをトリガーにして、この Lambda が実行されるようにします。
    そのトリガー設定にてバッチサイズを大きくします。例えば100にすると、最大100件までキュー内のメッセージがまとめて処理されるようになります。
    これにより、SQS のメッセージ複数件をまとめて、kintone複数レコード登録APIを使って登録するようにします。
  4. 重複メッセージ除去のための DynamoDB テーブル (後述⇒注意点2)

主な構成は上の通りで、いくつか注意点があります。

(注意点1) Amazon SQS の 標準キュー と FIFOキュー について

SQS には「標準キュー」「FIFOキュー」という二種類があります。

今回、トリガーのバッチサイズを大きくしたいのですが、FIFOキューだと最大バッチサイズは 10 という制限があるため、標準キューにしました。(標準キューの最大バッチサイズは 10,000 です )
kintone の複数レコード登録API の最大レコード数は100件なので、バッチサイズを 100 にすればいいでしょう。( もし バルクリクエスト を使用する場合はその 100件 × 20回分 の 2,000件なので、バッチサイズを 2,000以下にすればよいと思います )

(注意点2) 重複メッセージの除去について

SQS を「標準キュー」にしたことで、1つのメッセージで1回 以上、AWS Lambda がトリガー実行されます。
この「1回以上」というのが曲者で、場合によっては 同じメッセージ(= 1回のフォーム送信) で複数回 Lambda が起動されることがあります。

つまり、何も対策をしていないと、1回のフォーム送信で複数個 kintone レコードが登録されてしまうことがある、ということです。

その重複の除去のため、今回は SQS メッセージのIDを DynamoDB のテーブルへ条件付き書き込みし、すでにテーブル上に存在している場合はスキップする、といった制御を入れました。

(注意点3) その他の構成について

この構成が必ずしも正解というわけではなく、場合によっては「バルクリクエストを使ってまとめて 2,000件登録する」「3番の Lambda は SQS トリガー起動ではなく定期実行にする」等、いくつかバリエーションも考えられます。

必要とされる仕様に応じて、工夫してみてください。

まとめ

この Webフォーム → Lambda → SQS → Lambda → kintone 構成を実際に構築してみましたが、手元での実験では、1分間に1,000件登録し、数分後 kintone にも無事反映されました。

今回はWebフォームからの kintone アプリへ登録する話でしたが、他のことにも応用できると思います。もしたくさん登録が必要な場合は、「まとめて登録できないか？」を考えてみてください。

また、今回載せたのは構成だけですが、次回は実際の設定等も書きたいと思います。

kintone AWARD 投票システム

実はこの仕組みを応用したものが、サイボウズ株式会社様 事例紹介 の kintone AWARD グランプリの投票システムとなっています。

ぜひそちらの記事もご覧ください。

アールスリーが業務改善・システム開発を支援する「キミノマホロ for kintone」

アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。

今回書かせていただいた内容も、そのシステム開発のノウハウをもとにしています。

また キミノマホロ for kintone では、以下のようなワークショップを無料で開催していますので、ぜひ詳細をご覧ください。

投稿者プロフィール

アバター画像
淺利(あさり)
Webとか.NETとかスマホとかマイコンとかシーケンサーとか、いろいろやってるエンジニアです

関連投稿:

kintone から AWS AppSync [Preview] へのアクセスを試す kintone認定アプリデザインスペシャリスト合格体験記 ～失敗から学んだ攻略のコツ～ Deploitの機能を確認しよう　基本編