Qlik Management Console (QMC) で最適なパフォーマンスを維持するには、QMC のパフォーマンスに影響を及ぼす主な要因について理解することが重要です。このトピックの助言に従うことにより、応答時間の遅延や、QMC の不適切な使用に起因するその他の問題が生じるリスクを低減できます。
パフォーマンス向上のための提案
QMC の計画、設定、維持の際には、パフォーマンス向上のために次のオプションを検討します。その中には、若干の犠牲を払う価値があるものもあるでしょう。
- 管理者の数:QMC はセルフサービス ツールとしてではなく、限定的な数の管理者用に設計されています。管理者の数を少なくすると、パフォーマンスの向上がみられます。
- アプリの数とサイズ: ハウスキーピングをお勧めします。未使用、またはほとんど使用しないアプリがあるかどうかを確認し、可能であれば削除します。超大型のアプリは、複数の小型アプリに分割できる場合があります。
- セキュリティ ルールの設計: 適正に設計されたセキュリティ ルールにより、パフォーマンスの向上が図れます。「セキュリティ ルール」を参照してください。
- セキュリティ ルールのキャッシュについては、「セキュリティ ルールのキャッシュ」を参照してください。
- カウンター:QMC で数を表示するクエリは、パフォーマンス向上のために削除できます。
-
カスタム フィルター: カスタム フィルターを使用して、操作するデータにすばやくアクセスします。カスタム フィルターに接続されたデータは、ブラウザーにキャッシュされます。カスタムのフィルター ビューを切り替えると、データの変更のみがロードされます。これは、テーブル全体のリロードよりも高速です。「テーブル ビューでのカスタム フィルターの管理」を参照してください。
セキュリティ ルール
セキュリティ ルールにより、特定の条件を満たしている場合、ユーザーが作成、読み取り、更新、削除などのアクションを実行するためのリソースにアクセスを許可します。
セキュリティ ルールは常時提供、つまり、ユーザー アクセスを許可するために常時使用されています。セキュリティ ルールがアクティブにユーザーを除外することはありませんが、アクセス権を付与するセキュリティ ルールにユーザーが含まれていない場合、そのユーザーのアクセスは事実上拒否されます。しかし重要な点は、ユーザーがリソースにアクセスできるよう、リソースへのユーザー アクセス権を付与するルールが 1 つあるだけでは不十分だということです。多数のルールが、間接的にユーザーを排除することとは無関係です。
セキュリティ ルールがリソースへのアクセスを許可すると、ルール評価は停止します。 ルール評価の最悪のシナリオは、ユーザに権限が全くない場合で、すべてのセキュリティ ルールが評価されます。
セキュリティ ルールのキャッシュ
Qlik Sense セキュリティ ルール メカニズムには、ルール評価のパフォーマンス向上のために、2 つの異なるキャッシュ レイヤーが含まれています。
- セキュリティ ルール キャッシュ (ルール エンジン)
- セキュリティ フィルター結果キャッシュ (Qlik Sense Repository Service)
セキュリティ ルール キャッシュ
ルール エンジンは、リソースへのアクセスを評価するための解析ルールで使用されるコンポーネントです。セキュリティ キャッシュは、ルール エンジン内にあり、解析システム ルールで構成されます。キャッシュはデータベースに保存されず、Qlik Sense Repository Service を再起動すると削除されます。セキュリティ ルールに変更がない場合、キャッシュはリセットされないため、パフォーマンス向上に貢献します。セキュリティ ルールの評価は、静的コンテンツ用にはキャッシュされません。
リリース フィルター、コンテキスト、およびアクションに応じて使用するルールをエンジンがフィルターする場合は、最も頻繁にアクセスを許可するルールから順にソートされます。
セキュリティ フィルター結果キャッシュ
このキャッシュは Qlik Sense Repository Service にあります。このキャッシュを使用すると、ルール エンジンの使用を回避できます。キャッシュはデータベースに保存されず、Qlik Sense Repository Service を再起動すると削除されます。異なる方法で無効化 (削除) するキャッシュ カテゴリが 3 つあります。
• グローバル キャッシュ: セキュリティ ルール、負荷分散ルール、ライセンス ルール、またはカスタム プロパティになんらかの変更があると、キャッシュの完全無効化がトリガーされます。その結果、セッションの開始後に得られた最適化のメリットは失われます。
• ユーザー キャッシュ: ユーザー属性またはカスタム プロパティに変更があると、ユーザーベースの無効化がトリガーされます。つまり、特定のユーザーに関連付けられたキャッシュが削除されます。
• エンティティ キャッシュ: 単一のエンティティになんらかの変更 (例えば、アプリの名前または所有者) があると、エンティティベースの無効化がトリガーされます。つまり、特定のエンティティに関連付けられたキャッシュが削除されます。
関連ログ
セキュリティ フィルター結果のキャッシュ無効化に関連したログは次のとおりです。トラブルシューティングや監視のために使用できます。ログがある場所は次のとおりです。C:\ProgramData\Qlik\Sense\Log\Repository\Trace\HOST_NAME_Audit_Repository.txt
グローバル キャッシュの無効化
{reason} によるセキュリティ フィルター結果キャッシュ全体の無効化 (情報レベルでログに記録)
ユーザー キャッシュの無効化
ID があるユーザーのセキュリティ フィルター結果キャッシュを無効化:{userId} (デバッグ レベルでログに記録)
エンティティ キャッシュの無効化
エンティティ (type_id) のセキュリティ フィルター結果キャッシュを無効化: {entity.Type.Name}_{entity.Id} (デバッグ レベルでログに記録)
パフォーマンス効率に優れたセキュリティ ルールの記述ガイドライン
次のガイドラインは、セキュリティ ルールを記述する際の一般的なベスト プラクティスを示したものです。 こうした一般的なガイドラインに加えて、自身の特定の環境において、ここに記されている以外にもさらに改善できる場合があります。
特定のリソース フィルターの使用
リソースへのアクセスを評価する前に、リソース フィルターにより該当するリソースに適用されるルールを選別します。そのため、リソース フィルターはできる限り具体的にすることが重要です。フィルターが具体的であればあるほど、ルール エンジンの処理する必要があるルールを減らすことができます。
次の表に、異なる効率のリソース フィルター例を示します。
| リソース フィルター | 評価対象 | 効率 |
|---|---|---|
|
* |
すべてのリソース | 効率最小 |
| app* | 「app」で始まるすべてのリソース (例えば、app、app.object) | 上記よりも効率的 |
| app_* | アプリ リソース | 上記よりも効率的 |
| app_644d2485-d318-45b0-996e-29f5d379cac2 | ID が「644d2485-d318-45b0-996e-29f5d379cac2」のアプリ リソース | 最も効率的 |
最後の例は最も効率的ですが、再利用性も大幅に限定されます。一般的な推奨は、ルール内のリソースの種類に対するテストが不必要なレベルまでリソースの種類を指定することです。
正しいコンテキストと対象固有のアクションの使用
リソースへのアクセスを評価する前に、正しいコンテキストとアクションにより該当するリソースに適用されるルールを選別します。
[ハブ内のみ]、[QMC 内のみ]、または [ハブ内と QMC の両方] の 3 つがコンテキストの代替です。ここでも、できる限り具体的にします。最初の 2 つは、1 つのケースのみを評価するため、より効率的です。CRUD すべてへのアクセス (create, read, update, delete) を使用する代わりに、ルールが許可するアクションを指定するようにします。
複数にわたるオブジェクト参照の境界のトラバースを回避
常時とは限りませんが、多くの場合、具体的にすればするほど効率性が向上します。次の 2 つの例では、ユーザーに対し、リロード タスクへの読み取りアクセス権を付与するように設計したルールを示します。
例1：
user@property=resource.app.stream@property
結果: ユーザーは、タスクのアプリのストリームにあるカスタム プロパティに一致するカスタム プロパティを有するユーザであれば、リロード タスクを読み取ることができます。
非効率的。高価なオブジェクト参照の境界 (アプリ と ストリーム) はトラバースされます。
例2：
user.@property=resource.@property
結果: ユーザーは、タスクに直接あるカスタム プロパティに一致するカスタム プロパティを有するユーザであれば、タスクを読み取ることができます。
より効率的。境界のトラバースを回避します。
カスタム プロパティの数の最小化
場合によっては、少ないほど効率的です。カスタム プロパティの数を最小限に保つとメリットがあります。
例3：
user.@CustomProperty=resource.@CustomProp2
非推奨。リポジトリからフェッチする必要のあるカスタム プロパティが 2 つあるからです。
例4：
user.@customProperty=“ReaderOnly”
推奨。リポジトリからフェッチする必要のあるカスタム プロパティは 1 つのみだからです。
ルール構文内の実行順序は重要
ルールを記述するときは、最も高価な演算を最後にするようにします。次の例では、条件の 1 つが true であれば十分です。高価ではない演算が先にあり、true の場合は、より高価な演算の評価が不要になります。
例5：
resource.app.stream.owner.@a = “b” or user.name = “user1”
非効率的。より高価な演算が最初に評価されるからです。
例6：
user.name = “user1” or resource.app.stream.owner.@a = “b”
より効果的。より高価な演算が最後にあり、最初の演算が false の場合にのみ評価されます。
ハード コートの値を回避 – 代わりに属性を使用
resource.@property == "user1" や resource.@property == "user2" といった、ハード コートの文字列からなる複数のルールよりも、望ましいのは resource.@property == user.name といったルールです。
HasPrivilege は非効率的
HasPrivilege("アクション") は 2 番目のルールをトリガーするため、できる限り使用を避けるようにします。
例7：
App.Stream.HasPrivilege("read")
ルールの 2 番目の評価をトリガーする、ルール エンジンの新しいインスタンスを作成する機能です。
Like演算子は効率が良くありません
ルール評価のパフォーマンスに悪影響を及ぼす可能性があるため、可能であれば、(EXPRESSION) like (EXPRESSION) は避けてください。
例8：
resource.name like unit*"
Like 演算子は、文字列全体を比較する等号 (=) 演算子とは対照的に、文字列の各文字で比較します。