データアクセスのパフォーマンス
モバイルアプリを設計する際には、パフォーマンスについての考慮が必要です。モバイルアプリの設計上、1 回の操作で扱うデータが数十件以上になる場合は、このページの内容も考慮して機能やデータ構造を設計してください。
Kii Cloud のように外部のサービスやライブラリーを使用する場合、API の実行にかかる時間の感覚をつかんでおくことは非常に重要です。
このページでは、1 人のユーザーが 1 回で大量のデータをやりとりするような状況の対処方法を扱います。なお、ユーザー数の増加に伴うスケーラビリティは Kii Cloud で確保されているため、ボトルネックになる実装がない限り、ユーザー数に対する特別な考慮は不要です。
API の実行時間
Kii Cloud を使ったモバイルアプリを設計する際には、ローカルストレージと同じ感覚で Kii Cloud にアクセスできない点を把握しておくことが重要です。
以下に、シンプルな JSON データを様々なストレージに書き込む際の処理時間の目安を示します。
| 書き込み方法 | 処理時間の目安 |
|---|---|
| ローカル PC のへファイル出力 | ～数ミリ秒 |
| ネットワーク PC へのファイル出力 | 数十ミリ秒 |
| Kii Cloud の API 実行（4G 回線経由） | 百数十ミリ秒～ |
Kii Cloud への API 1 回あたりの実行時間は、ローカル PC 上のストレージに比べて 100 倍以上かかる傾向があります。クラウドサービスとしての処理に加え、スマートフォンなどのデバイスからインターネット経由でサーバーに到達するまでのネットワークのレイテンシもボトルネックになっています。
数回の API の実行であれば 1 秒以内に終わりますが、100 回繰り返して実行すると 10～30 秒程度が実行時間の期待値になります。
多くの KiiObject を扱う場合、API の特性を理解した上でデータや機能を設計する必要があります。以下に Kii Cloud でのデータの書き込みと読み込みに対する一般的な特性を示します。
データの書き込み
データの追加や更新では、KiiObject を 1 回の API コールごとに 1 件ずつ書き込む必要があるため、件数が多いとパフォーマンスの低下を招きます。まとめて KiiObject を書き込む機能は用意されていません。API コール数は KiiObject の件数と同じになります。
データの読み込み（ID 指定）
ID や URI を指定してデータを取得する場合は KiiObject を 1 回の API コールごとに 1 件ずつ取得する必要があるため、件数が多いとパフォーマンスの低下を招きます。API コール数は KiiObject の件数と同じになります。
データの読み込み（クエリー）
クエリーを使ってデータを取得する場合、1 回の API で最大 200 件の KiiObject を取得できるため、データ取得そのものの観点ではパフォーマンスの問題は起きにくい傾向があります。
ただし、複雑なクエリーはパフォーマンス低下の原因となるため、クエリーの設計には注意が必要です（詳細は下記の より詳しく学びたい方へ を参照してください）。
上記 の 3 つの条件で Kii Cloud にアクセスした際の処理時間の実測値を以下に示します。2 つのキーと値のペアを持つシンプルな KiiObject を 3000 件用意して、4G 回線上の Android 端末からアクセスしています。
| 書き込み | 読み込み （ID 指定） |
読み込み （クエリー） |
|---|---|---|
| 約 8 分 3000 API コール |
約 6 分 3000 API コール |
約 3.2 秒 16 API コール |
表の値は運用環境での性能を保証するものではなく、計測結果の参考値です。処理時間は、デバイスからサーバーまでのネットワーク距離、回線速度、転送データの量、サーバーでの処理内容や負荷状況など、様々な要素に応じて変動します。
なお、複数クライアントからの負荷テストのように、サーバーに負荷がかかるような性能測定を行う場合は、事前にご相談ください。
Kii Balance の仕様では、ユーザーインターフェイスの操作で 1 件ずつデータを書き込み、データ一覧画面の作成時にクエリーを使ってそれらをまとめて読み込みます。上記の傾向から見て、このような仕様であればデータ件数が増えてもパフォーマンスに対する問題は起きにくいといえます。
大量のデータを扱うための工夫
モバイルアプリの仕様上、大量のデータの利用が避けられない場合は、様々な工夫を行う必要があります。
ここでは、以下の 2 つの方法を説明します。
データのネストによる件数の削減
大量のデータを扱いたい場合、データをネストした状態で KiiObject に格納する方法があります。
たとえば、以下のように Kii Balance の収支データを JSON の配列表現によって KiiObject にまとめると、KiiObject の件数が減るため API の実行回数が少なくてすみます。
1 つの KiiObject のキーと値のペアには、JSON 形式の文字列表現で 65534 文字までのデータを保存できます（_id や _created などの Kii Cloud が内部で使用するフィールドも含みます）。モバイルアプリで決めた入力領域の最大長などから 1 つの KiiObject にネストできるデータ件数を決めることができます。
JSON オブジェクトの配列にアクセスする方法は、リファレンスガイドのサンプルコード（Andorid の 書き込み と 読み込み、iOS の 書き込み と 読み込み）を参照してください。
なお、KiiObject は JSON の 1 階層目だけが検索対象となるため、データのネストを行うと検索ができません。このような場合、検索専用のキーを 1 階層目に作成した上で、そのキーを持つデータだけを内部に格納するなどして検索性を維持することができます。
KiiObject のネストを行うと、パフォーマンスが改善する一方でプログラムの保守性やデータの柔軟性が低下します。データの利用方法やデータ量の見積もりから、パフォーマンスのチューニングが必要な箇所でのみ採用することを検討してください。
パフォーマンスの改善例
初めの表と同様、3000 件のデータに対するネストの効果を実測によって確認したものを以下に示します。ネストを使う場合は、3000 件のデータを 1000 件ずつ 3 つの KiiObject に集約しています。
| データの編成方法 | 書き込み | 読み込み （ID 指定） |
読み込み （クエリー） |
|---|---|---|---|
| ネストなし | 約 8 分 3000 API コール |
約 6 分 3000 API コール |
約 3.2 秒 16 API コール |
| ネストあり | 約 1.2 秒 3 API コール |
約 0.6 秒 3 API コール |
約 0.4 秒 1 API コール |
初めの表と同様、表の値は運用環境での性能を保証するものではなく、計測結果の参考値です。
書き込み処理と ID 指定での読み込み処理では、KiiObject を 1 件ずつ処理する必要があるため、処理時間、API コール数ともにネストを行った方が数百倍以上よい結果が出ています。クエリーによる読み込みは、1 回の API コールで最大 200 件の KiiObject を取得できるため、差は比較的小さくなります。
負荷の分散
サーバーに負荷が集中すると様々な問題が起きるため、負荷の集中を避けるように工夫する必要があります。
大量のデータの読み込みや書き込みが避けられない場合や、特定のイベントを契機にアクセスが集中する場合、サーバーの負荷に対する考慮も必要です。特に、プッシュ通知やメディアを通したマーケティング上の告知、新機能のリリースなど、アクティブユーザーが同時に Kii Cloud にアクセスするような状況では API コールの集中に注意してください。
たとえば、1 回の処理で 100 API コールを実行する仕様であっても、1 万クライアントが同時に動くと 100 万 API コールが短時間で実行されます。
Kii Cloud では、アプリケーション単位で、一定時間内に異常な負荷が集中するとエラーを返す仕組みがあります。この制限値には余裕があるため、通常の運用負荷の変動では問題なく動作する設計ですが、アクティブユーザーの一斉リクエストではエラーになる可能性があります。
負荷の集中が予想される場合、バックグラウンド処理によって少しずつ読み書きを行ったり、乱数（デバイス間で同一の値を返さないもの）で開始時刻を決めて処理を分散したりするなどの工夫を検討してください。
次は...
データの一貫性についての設計手法を説明します。
データの一貫性の保持 に移動してください。