Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

ホットキャッシュを使用してユースケースに応じてデータを最適化する

はじめに

ユーザーの要求はますます高くなり、結果が出るまで辛抱強く待てなくなっています。低速なアプリケーションは、ユーザーによる導入を大きく左右し、ビジネスニーズに影響を及ぼす可能性があります。開発のベストプラクティスの欠落のほかにも、アプリケーションのパフォーマンスの良し悪しに影響する可能性のある要素があります。

  • 大量のデータが保存されている外部システムのレコードとの依存関係。

  • 複雑な計算やデータマッシュアップが必要な情報。

これらの要因を克服するため、設計時に複数のアーキテクチャパターンを検討することができます。この記事では、パフォーマンス上の問題を回避できる可能性があるキャッシュアーキテクチャパターンについて説明します。

Wikipediaには、「キャッシュとは、将来のリクエストにすばやく対応できるようにするためにデータが保存されるハードウェアコンポーネントまたはソフトウェアコンポーネントのことで、キャッシュ内に保存されるデータには以前の計算結果や他の場所に保存されたデータのコピーなどがあります」とあります。

この記事では、キャッシュとは、外部で管理されているデータ(外部レコードマスター)の(OutSystemsデータベース内の)ローカルレプリカを保持することを意味します。この記事では、サーバーのインメモリキャッシュについては詳しく説明しません。これはOutSystemsプラットフォームのビルトイン機能(Cache in Minutesプロパティ)で、これもパフォーマンス上の問題の軽減にも役立つ場合があります。

複数データレイヤーパターン

このパターンでは複数のキャッシュレイヤーを定義し、それぞれに目的とデータセットを指定します。異なるキャッシュレイヤーを使用することで、要件に基づいて各レイヤーを細かく調整し、データを大量に処理するときのパフォーマンスを向上することができます。

通常、以下のシナリオでこのパターンを使用します。

  • 外部レコードマスターとの連携。

  • ホットビジネスプロセスの事前データ収集。

  • ダッシュボードのデータマッシュアップ。

  • モバイルにおける最適化されたデータモデルのサポート。

  • モバイルにおけるオフラインサポート。

以下は、可能なキャッシュレベル(およびそれぞれの視覚的表現)です。

クライアント側のキャッシュ クライアント側のキャッシュ ユーザーの固有データのローカルキャッシュ。 通常、モバイルアプリケーションでローカルストレージとして設定されます。
ホットキャッシュ ホットキャッシュ 事前収集データまたは計算データのキャッシュ。 主にアクティブなプロセスや要件です。
コールドキャッシュ コールドキャッシュ すべての関係を含む正規化されたデータモデル。 検索を容易にするためにエンティティ間の関係が維持されます。
ステージングキャッシュ ステージングキャッシュ 外部システムから収集されたステージングデータのキャッシュ。コールドデータへと処理されます。
レコードマスター レコードマスター 外部データマスター。

複数のレイヤーがありますが、必ずしもすべてのデータレイヤーを含める必要はありません。ユースケースに基づいてアーキテクチャを設計してください。ほとんどのアプリケーションは正規化されたデータベース(コールドデータレイヤー)のみを中心に構築され、外部レコードマスターのローカルレプリカを実装します。これにより、データアクセスの高速化と外部システムの呼び出し回数の抑制を実現します。詳細については、連携に基づいてコアサービスを抽出する方法をご覧ください。モバイルアプリケーションでは、クライアント側のキャッシュを利用してパフォーマンスを向上させ、サーバー呼び出し回数を減らすことが特に重要です。

この記事では、ホットキャッシュ/データパターンを使用するべき状況と、アプリケーション全体に対するメリットについて主に説明します。

ホットキャッシュ/データパターン

一部のユースケース(ダッシュボードや条件付き変数データなど)では、アプリケーションのビジネス要件を満たすために、様々なソースから情報を集約する必要がある場合や、大量の元データに対して大量の計算を実行する必要がある場合があります。

このユースケースに必要なデータを必要に応じてソースシステムで直接収集することが可能です。ただし、適切なデータの取得に時間がかかり、エンドユーザーエクスペリエンスに影響を及ぼすため、通常は適切な選択肢ではありません。

この場合、ホットキャッシュパターンで大きなメリットが得られます。複数のエンティティに対して直接クエリやデータ結合を行う代わりに、エンドユーザーが情報を表示するときに、ユースケースに応じて最適化されるように設計された新しいエンティティを含むキャッシュレイヤーが作成されます。この新しいエンティティには定期的にデータが反映され、事前計算されたデータが保存されます。このキャッシュレイヤーは、アクティブなデータのみが保存されることから、「ホットキャッシュ」と呼ばれます。

簡単なWebストアを例として示します。このWebストア(WebShop)では、顧客、顧客タイプ、製品カテゴリに基づいて製品の価格設定を区別します。また、数百万点の製品と数百万人の顧客を抱える大規模な店舗であるとします。4 Layer Canvasに従い、次のようなアーキテクチャ図が考えられます。

WebShopのアーキテクチャ例

WebShop: 顧客別の正しい価格でオンラインカタログを表示するには、手間のかかる計算とデータマッシュアップが必要です。

Product_CS: 製品および製品カテゴリ、基本価格および製品説明。

Pricing_CS: 価格設定ルール。顧客別、顧客タイプ別、製品カテゴリ別の最終製品価格に影響を及ぼします。

Customer_CS: 顧客情報。個人データ、顧客メンバーシップレベル(基本、シルバー、ゴールド)など。

単純化するため、OutSystemsデータベースにのみデータを保存することにします。各コアサービス(CS)モジュール内の青色のデータベースアイコンがこれを示しています。なお、このレイヤーはコールドデータコンセプトにマッピングされます。

この例では、情報をリアルタイムで取得および計算した場合にユーザーエクスペリエンスに影響を及ぼす要件がいくつかあります。

  • 顧客別カタログ - 顧客ごとに独自の製品価格カタログがあります。1か月間有効な顧客メンバーシップレベルに基づく割引があります。

  • 週間特別価格 - 前週の参照回数が上位10位以内の製品に割引が適用されます。

  • メンバーシップの更新 - 販売金額に基づき、顧客メンバーシップレベルが更新されます。たとえば、顧客の販売金額が1,000ドルに達するとシルバーレベルに昇格し、より大きな割引を受けることができます。

ホットキャッシュの実装方法

アーキテクチャ

ホットキャッシュパターンの実装で最初に行う手順は、要件の分析と、最適化されたデータを保持するホットキャッシュデータモデルの設計です。

たとえば、WebShopで、すべての顧客別カタログを保存する新しいエンティティが必要です。キャンペーン価格はキャンペーンのリリース時に事前計算されます。データがホットである間(1か月のキャンペーン中)は、このエンティティに保持されます。

ホットキャッシュの実装をサポートするための新しいモジュールが2つあります。

ホットキャッシュアーキテクチャ

Catalog_BL - ホットキャッシュエンティティが定義されるビジネスロジック(BL)モジュール。個別の顧客カタログ、週間価格、価格履歴が保存されます。

Promotion_Eng - このエンジンがホットキャッシュエンティティへの入力を行います。トリガープロセスと関連するビジネスロジックを実装します。

トリガー

ホットキャッシュの入力方法と入力タイミングの定義は難しい場合があります。「万能」のパターンは存在しません。どのビジネスケースも唯一無二であるため、キャッシュ作成のトリガーをビジネス要件と連携させる必要があります。WebShopの要件に基づいたいくつかのオプションを以下に示します。

  • 顧客別カタログ - プロモーションの開始前にすべての製品の顧客価格を事前計算します。これを実現するには、BPTプロセスの開始をトリガーして新しいオンラインカタログを作成する顧客別の月次タイマーを設定します。

  • 週間特別価格 - 週末タイマー。毎週日曜日に実行するようにスケジュールを設定します。前週のすべての顧客による参照回数が上位10位以内の製品を収集し、グローバルな割引価格を適用します。

  • メンバーシップの更新 - 新規販売の後にトリガーされ、現在の販売量を評価するBPTプロセス。メンバーシップレベルが更新される場合は、顧客オンラインカタログの更新をトリガーします。

同期

次に対処する必要がある問題は、ホットキャッシュを常に最新状態に保つことです。ホットデータを最新状態に保つことは信頼性の鍵になります。

ただし、すべてのユースケースでホットキャッシュの再計算が必要になるわけではありません。コールドデータが変更されたときにどのユースケースを更新する必要があるかを、ユースケースごとに評価することが重要です。また、この更新はきびきびと行うことが重要であり、コールドキャッシュの変更の影響を受けるレコードのみを更新する必要があります。

ここで、WebShopの例に戻ります。

  • 顧客別カタログ - このメインカタログは月1回構築されるため、基本価格の変更は月初にのみ反映されます。月1回のカタログの再作成以外の同期は不要です。週間価格やメンバーシップレベルの更新によって顧客カタログが更新される場合がありますが、これらの場合については以下で説明します。 最適化のため、最近Xか月以内にWebポータルを閲覧したユーザーのカタログのみを作成するようにすることもできます。

  • 週間特別価格 - 週間価格は日曜日にのみ更新され、コールドキャッシュに対する変更の影響を受けません。10個の週間製品を顧客カタログに反映する必要があるため、すべての顧客カタログで10個の新価格(これら10個の価格のみ)を更新する第2のプロセスをこのプロセスでトリガーする必要があります。また、カタログは月次であるため、各顧客カタログで前月の価格をそれぞれ元の金額にリセットする必要があります。

  • メンバーシップの更新 - 顧客の割引はメンバーシップレベルの影響を受けるため、顧客のレベルが変わるたびに、その顧客のカタログの再作成をトリガーする必要があります。

パージ

ホットキャッシュの応答を高速に保つため、関連するアクティブなデータのみが含まれるようにする必要があります。同期では関連するフィールドのみを考慮するようにするほか、使用されなくなった情報を消去するためのパージメカニズムを適所に配置する必要があります。パージ戦略は各エンティティの性質に基づいて設計し、ビジネスユースケースと連携させる必要があります。

説明した例では、以下のような方法が考えられます。

  • 顧客別カタログ - 現在のカタログの期限切れまたはメンバーシップの更新など別のイベントの発生によって、カタログの新しいバージョンが作成されたときにパージします。

  • 週間特別価格 - 毎週、10個の旧特別価格をパージします。

  • メンバーシップの更新 - メンバーシップレベルはホットキャッシュの一部ではないため、アクションは不要です。顧客カタログを再作成するトリガーであるプロセスでは、古いカタログのパージを考慮します。

  • 非アクティブなユーザー - ユーザーが非アクティブになった場合、関連するカタログをホットキャッシュからパージし、月次の計算が行われないようにする必要があります。

パージ操作の実行には時間がかかり、ホットキャッシュシステムの全体的な使用に影響を及ぼす可能性がある点に留意することが重要です。そのため、WebShopアプリケーションの負荷が少ない特定の時間にこのタイプの操作をスケジュール設定することが推奨されます。

結論

大量のデータを処理する場合や重い情報の処理を行う場合にキャッシュメカニズムを使用すると、アプリケーションのパフォーマンスに重大な影響を及ぼす可能性があります。

ホットキャッシュパターンは、ビジネスニーズと強い関連性があります。このメカニズムを設計する際は、以下のガイドラインに留意します。

  • ビジネス要件に注目し、必要なデータを確認し、簡素化されたより効率的なエンティティに保存するためにどのタイプの事前計算と同期が必要なのかを確認します。

    • ホットキャッシュエンティティにはアクティブなデータのみを保存します。
  • アプリケーションに影響を及ぼさないように、エンジンや同期メカニズムのトリガーを設計します。ビジネス要件に配慮し、長時間の処理は時間外にスケジュール設定し、同期するデータの量を常に考慮します。

    • 効率的に変更されたレコードのみを更新します。タイムスタンプを利用して、差分同期をサポートします。
  • マスターデータが変更される可能性があること、ホットキャッシュをレコードシステムから更新する必要がある可能性があることを忘れないようにします。そのため、これらの場合のトリガーを適切に計画する必要があります。

  • 使用されなくなった古いキャッシュデータを消去します。使用されなくなった古いデータによるパフォーマンス上のメリットはまったくなく、ホットキャッシュメカニズムの効率性に深刻な悪影響を及ぼす可能性があります。