アプリのパフォーマンス: 基本コンセプト

アプリをより高速に実行できるようにするには、まず基本コンセプトを理解する必要があります。

アプリがデータを同期したり、入力に応答したりする際に、アプリのユーザーに待ち時間が発生しないことが理想とされます。AppSheet アプリを適切に調整すると、この理想の実現に近づくことができます。

AppSheet アプリは、モバイル デバイスまたはブラウザで実行できます。アプリで使用されるすべてのテーブルデータは、デバイスまたはブラウザのローカルコピー内に維持されます。このローカルコピーを使うことにより、アプリはインタラクティブかつレスポンシブに動作し、オフラインでも実行できます。プラットフォームは、データのこのローカルコピーとクラウド データ プロバイダ（Google ドライブ、Office365、SQL Server など）内にある実際のデータを常に同期させる必要があります。

以下の各セクションで、アプリのパフォーマンスを向上させるための考慮事項について説明します。

• レイテンシとスループット
• 同期速度を改善する
• アプリのパフォーマンスを改善する
• 一般的なデータソースのパフォーマンスに関する考慮事項

レイテンシとスループット

アプリのパフォーマンスとは、通常、アプリのエンドユーザーが認識するアプリの応答性を指します。また、レイテンシとは、待機する時間を指します。アプリの応答性は、ユーザーが認識するレイテンシに直接関係しています。Google の目標は、エンドユーザーが認識するレイテンシを最小限に抑えることです。

AppSheet アプリの仕組みがわかってくると、異なるシステムが互いに通信していることに気づくでしょう。それぞれの通信において行われているのが、システム間のデータ転送です。ここで言うレイテンシとは、システムがリクエストに最初に応答するまでにかかる時間を指します。スループットとは、1 秒あたりに転送されるデータの量を指します。例えば、Google ドライブからスプレッドシートを取得する場合、このリクエストに応答する際に最初に生じるレイテンシと、データの実際の転送にかかった時間の合計が、全体的なレイテンシになります。

同期速度を改善する

AppSheet アプリは、クラウド データ プロバイダに直接接続できません。代わりに、クラウド プロバイダとの通信を仲介する AppSheet のバックエンド サービス（下図の AppSheet サーバー）と通信します。このように階層化することにより、セキュリティだけでなくパフォーマンス上のメリットも得られます。

まず、読み取り専用アプリでの同期の場合を考えてみましょう。アプリを最初に起動する際も、アプリの [Sync on start] オプションが有効になっている場合も、同じように動作します。

• 読み取りステップ 1: モバイル デバイス上のアプリが同期を開始し、AppSheet サーバーにデータをリクエストします。次に、AppSheet サーバーがクラウド プロバイダにデータをリクエストします。
• 読み取りステップ 2: クラウド プロバイダからデータを受け取ると、AppSheet サーバーは定義されている仮想列を計算してから、データをモバイル デバイス上のアプリに返します。アプリはモバイル デバイス上にデータを保存します。

ステップ 1 において、AppSheet サーバーが同じまたは異なるクラウド プロバイダから多くのテーブルを取得する場合があることにご注意ください。ステップ 2 において、すべてのデータは同時にアプリに送信されます。送信されるデータを減らし、これらのステップにかかる時間を短縮するためのさまざまな最適化の方法については、後ほど説明します。

ここで、アプリがデータ（データのローカルコピー）に対して変更を加え、同期を呼び出している場合について考えてみましょう。アプリはまずデータの更新を順に AppSheet サーバーに送信（図中のステップ 3 と 4）し、その後に読み取り専用の同期を行います。

• 書き込みステップ 3: アプリが追加、更新、削除されたデータの行を AppSheet サーバーに送信します。写真、図形描写、署名をキャプチャした場合、これらはデータの行と同時に送信されます。
• 書き込みステップ 4: AppSheet サーバーがこの情報を受け取り、クラウド プロバイダにデータを書き戻します。自動化が定義されている場合は、これらも実行されます。これらは通常、アクションを実行する前に、更新された行をクラウド プロバイダから再度読み取ります。

アプリ作成者は、同期速度とパフォーマンスを改善できます。詳しくは、以下をご覧ください。

• 同期速度を改善する
• データベース更新時の同期速度を改善する

コミュニティの記事 Obstacles with AppSheet for business due to large data もお役立てください。

アプリのパフォーマンスを改善する

多数の同時ユーザーに対応してスケールできる高性能なアプリを設計する際には、同期のパフォーマンスを最適化すること以外にも、理解しておくべき重要なコンセプトと技術的機能があります。

• 書式ルール - アイコン、テキストなどをカスタマイズするルールを定義します。書式ルールがあると画面上でスクロールが発生するたびに膨大な計算が行われる場合があるため、インタラクティビティに直接影響を与える可能性があります。
• 仮想列 - アプリの式を使用して、自動的に列の計算を行います。仮想列は列と行ごとに計算され、式は複雑になることがあるため、アプリに多数の仮想列がある場合は一般的にパフォーマンスにとって大きな負担となります。一般的には、可能であれば仮想列の数を最小限に抑えることをおすすめします。
• 参照 - データ参照は、優れたユーザビリティを実現し、データ レプリケーションを回避できるため、多くのアプリケーションにとって有益です。ただし、各参照では仮想列と参照データの読み取りも必要になるため、過剰に使用するとパフォーマンスに悪影響が出る可能性もあります。参照を追加する前に、アプリケーションで本当に必要かどうか検討してください。
• データ パーティショニング - バックエンド データソースの種類に関係なく、アプリのデータを複数のテーブルにパーティショニング（分割）すると、全体的なパフォーマンスにプラスの効果が生まれる場合があります。

• セキュリティ フィルタ - ユーザー アクセスを制限する方法、または一般的にバックエンド データソースから取得するデータの量を制限する方法を提供します。通常は全体的なパフォーマンスにプラスの効果をもたらしますが、使用されるバックエンド テクノロジーによっては特別な考慮事項があります。
  • Google スプレッドシート - Google スプレッドシートを使用するアプリは、スプレッドシートのデータ全体を取得して、サーバーにフィルタを適用します。セキュリティ フィルタが行単位で実行されるため、大量のデータを処理する場合はパフォーマンスに悪影響が出る可能性があります。
  • Cloud SQL - セキュリティ フィルタは SQL ステートメントに変換され、データベースに送信されます。通常はパフォーマンスの向上を期待できますが、式が非常に複雑な場合、向上の幅はごくわずかになる可能性があります。AppSheet がデータベース上の変換可能なデータをすべて変換してから、サーバーでフィルタが（再）適用されるためです。
  • AppSheet データベース - AppSheet データベースに対してセキュリティ フィルタを適用することで、通常はパフォーマンスが向上します。
• オフライン データ / 画像キャッシュ - 大規模なデータセットを処理する場合は、オフライン キャッシュに影響が及ぶ可能性があることと、クライアント デバイスのストレージまたはメモリに制限があるとデバイスがクラッシュする可能性があることも考慮するとよいでしょう。

一般的なデータソースのパフォーマンスに関する考慮事項

AppSheet プラットフォームは一般的に水平方向に動的にスケールして、どのような規模のユーザーにも対応します。AppSheet が実行される Google インフラストラクチャは極めて高いレベルの同時リクエスト（数百万単位を含む）を処理できるよう設計されていますが、AppSheet がサポートできる同時ユーザーの数はアプリ内で使用されるデータソースのスケーラビリティによって厳密に規定されます。

たとえば、待合室に無数の顧客を収容できるレストランを想像してみてください。待合室（この場合は AppSheet プラットフォーム）には何人でも入ることができますが、レストランの最大収容人数、つまり一度に対応できる顧客の人数は、調理と給仕のスタッフ数、ダイニング テーブルなどのリソース量、シェフが調理できる食料の量（この場合はデータソース）によって決まります。

以下の表で、AppSheet の最も一般的なデータソースのパフォーマンスに関する考慮事項をご確認ください。

データソース	アプリのパフォーマンスに関する考慮事項
AppSheet データベース	AppSheet データベースをデータソースとして使用する AppSheet アプリの特長は以下のとおりです。 プロビジョニングが容易。スプレッドシートを作成するのと同じくらい簡単です。 Google スプレッドシートよりも大規模にスケールできる可能性がある。 毎秒 100 リクエストの高い同時実行性。 Quick sync は、AppSheet のデータベースを使用するすべてのアプリに対してデフォルトで有効になっています。 まとめ AppSheet データベースには、表のような構造でデータを編集するという使い慣れた機能のほか、クラウド データベースのパフォーマンスと規模が備わっています。
Google スプレッドシート	Google スプレッドシートをデータソースとして使用する AppSheet アプリは、特に小規模から中規模のアプリで非常に一般的かつ実用的です。Google スプレッドシートをデータソースとして使用するアプリを大規模にデプロイしているアプリの作成者は、割り当てを超過する問題が起こらないよう、AppSheet で Sheets API がどのように使用されるかにつきご注意ください。割り当ての使用量に関する注意点は以下のとおりです。 Sheets API の割り当ての計算は、分単位、プロジェクト単位、ユーザー リクエスト単位で行われます。  すべての AppSheet アプリは、AppSheet 環境全体を実行している単一の Cloud プロジェクトから API にアクセスします。 この AppSheet プロジェクトには未公開の追加された割り当てがあり、需要の増加に応じて更新されます。 個々の AppSheet アプリには独自の Cloud プロジェクトがないため、割り当ての増加をリクエストすることはできません。  ユーザーごとの割り当ては、一般的に、個々のアプリ作成者の認証情報に基づいて計算されます。デフォルトのアクセスモードでは、アプリ作成者として実行するためです。 繰り返しになりますが、割り当ての超過は小規模から中規模のスプレッドシート ベースのアプリでは通常発生しません。ピーク時に多くのユーザーによる同時アクセスが発生する大規模なデプロイを計画する際は、アプリ作成者はこれらの API 割り当てに関する考慮事項を念頭においてください。 アプリの例と想定される Sheets API 割り当て 出張の承認アプリ - 出張の承認リクエストを送信するための基本的なアプリ。 従業員が出張計画の承認リクエストをいつでも送信できるように常時稼働します。1 日を通して負荷が分散されるため、使用量が格段に増えるようなピークはありません。 アプリに必要とされるデータも比較的少なくて済みます。通常は、出張の日時、理由、交通費と宿泊費などの情報で十分です。 必要とされるデータは少なく、トラフィックはさまざまな時間に分散されるので、アプリ作成者またはアプリユーザーのどちらのアクセスモードで実行するかは重要ではありません。 結論 - 低リスクです。このアプリの場合、Sheets API で同時実行または割り当ての問題が発生する可能性は低いと思われます。 毎日のタスクアプリ - 毎朝、従業員が複数の日常業務を追跡するアプリ。 特定の時間帯に複数のユーザーが大量のデータにアクセスする大規模なアプリです。 このアプリでは API の割り当て上限で問題が発生する可能性があります（特に、特定地域で朝にあたる時間帯などに使用量が急増する場合）。 各ユーザーがアプリ使用中に複数のタスクを生成し、さらにそれらの各タスクに複数のデータ フィールドがある場合は特に、データが大量にあることにより問題がさらに複雑になる可能性があります。 このアプリの場合、使用量のピークに達する時間帯があることと、データが大量であることから、多くのユーザーがアクセスすると、API 割り当ての問題による影響が生じる可能性があります。 また、作成者のアクセスモードで実行すると、割り当て超過のリスクがさらに大きくなります。 結論 - 高リスクです。このアプリの場合、使用量のピークに達する時間帯があることと、大量のデータを処理することから、Sheets API で同時実行または割り当ての問題が発生する可能性があります。アプリがユーザー アクセスモードで実行され、データ量が制限されている場合や、アプリへのアクセスがさまざまな時間に分散される場合は、この問題を緩和できる可能性もあります。 まとめ Google スプレッドシートをデータソースとする AppSheet アプリでは、AppSheet と Google スプレッドシートのアーキテクチャを設計するときに、アプリアクセスの時間帯（使用量のピーク発生の回避）、アプリへのアクセスモード、全体的なデータ量を考慮しないと、Sheets API で同時実行または割り当ての問題が発生する可能性があります。
Cloud SQL（MySQL、PostgreSQL、SQL Server）	Cloud SQL のバックエンド データソースを使用する AppSheet アプリの場合、Sheets API のような割り当て上限の問題は発生しません。Cloud SQL では秒間クエリ数（QPS）の制限すらないためです。 Cloud SQL インスタンスがその構成対象に対するリクエストを過度に大量に受け取ると、リソースの枯渇により、データベースで処理速度の低下やタイムアウトが発生します（監査ログに表示されます）。この問題は、トラフィックの増加に合わせて SQL インスタンスを適切に構成することで改善できます。 さらに、アプリがデータベースに対して行うクエリの種類と、全体的なデータ プロファイル（テーブルの数、行の数、列の数、データベース ビューが使用されているかどうか）も、パフォーマンスとスケーラビリティに影響する可能性があります。 以下を含む Cloud SQL インスタンスの構成が、スケーラビリティを左右する主な要因となります。 vCPU 数 メモリ ストレージの種類と容量 3 種類のデータベース（MySQL、PostgreSQL、SQL Server）につき、本番環境および開発環境のデフォルトの構成は以下のとおりです。   本番環境 開発環境 可用性 高可用性 シングルゾーン vCPU 8 4 メモリ 32 GiB 16 GiB ストレージ 250 GiB 100 GiB まとめ Google Cloud SQL をデータソースとする AppSheet アプリでは、割り当ての超過による同時実行の問題は発生しません。その代わり、データベースの最大のパフォーマンスは、インスタンスをどう構成するかによって決まります。経時的に変更が必要な本番環境では、パフォーマンスと同時実行の目標に最適になるよう SQL インスタンスの構成を常に調整することをおすすめします。