kintone気をつけようシリーズ 集中アクセス編②

お前誰？

トヨクモ株式会社の前CTOとしてフォームブリッジやkViewerなどkintone連携サービスの開発をしてきました。2014年の制度発足時からのkintoneエバンジェリストで、（自称）kintoneやkintone連携サービスのセキュリティ、パフォーマンス、カスタマイズなど高度な技術領域に詳しいマンです(^^)
今はトヨクモクラウドコネクト株式会社の取締役をしております。

これなに？

「kintone気をつけようシリーズ」では、セキュリティやパフォーマンスなどのkintoneやkintone周辺サービスを使う上での気をつけた方がいい点を発信していきたいと思っています。
今回は集中アクセスが想定されるシステムを正しく設計・設定しないと上限に到達し不具合が発生したり、最悪障害を起こしてしまうケースをピックアップしていきます。

kintoneのREST API同時接続上限

kintoneのREST APIは非常に便利な機能で、kintone周辺サービスが数多く提供されているのもREST APIのおかげです。ただもちろんシステム上限があり、ドメイン当たり同時接続数上限100という制限があります。
REST APIは私には関係ないわ〜と思っている方！連携サービスを使う場合も同様に注意が必要です！！フォームブリッジやkViewerなどkintoneに連携するサービスもREST APIを利用したサービスになります。kintoneを利用する以上、ドメイン当たり同時接続数上限100は必ず意識して構築しましょう。特に意識する部分としては、接続時間が長くなりやすい添付ファイルの扱いや処理時間を長くしてしまうようなアプリ設計ですね。

またシステム上限による不具合の場合、検証段階では不具合を発見できず、本番運用で不具合が発生することで初めて気づく点も怖いですね…

上限を超えた場合は HTTP ステータスコード 429 が返されるため、REST APIを利用した開発をする場合はエラーハンドリングをしておきましょう！
エラーハンドリングができるかは、kintone周辺サービスを導入する場合のサービス選定項目の１つですね。

他にもkintoneにはアプリにも10,000件のAPIリクエスト数／日の制限もあります。

まとめ

kintoneのREST APIは非常に便利な機能ですが、上限があるのでパフォーマンスを意識した設計が重要です！！動かないと怒られるのは構築した人ですし、集中アクセスがある規模で障害起こしたら影響範囲も大きいですよね。。。（もし不安な場合はkintoneのパフォーマンスに詳しい人にレビューしてもらうと良いです）