Yellowfin実装計画時の重要なステップとして、キャパシティ要件の見積もりがあります。これは、提供目標とサービスレベル契約を満たすために必要な、初期のコンピューティングリソースを概算します。キャパシティの見積もりは、非公式、または構造化されたアプローチに基づき達成することができ、ユーザーが行う主要な活動を含めて考慮する必要があります。
見積もるべき主要なシステム要件は、以下の通りです。
キャパシティの見積もりは、システムインフラが、成長するユーザーのニーズに対応し続けるために、継続して実行していかなくてはいけません。ユーザー要件の管理、データソースからのデータ取得、分析機能の追加、レポート結果の書式設定や配信、レポートインタラクションの実行など、これらのすべてにコンピューティングリソースが使用されます。ユーザー数、レポート数、データ量や、Yellowfinサーバに制御される分析レポート量の増加は、同様レベルのパフォーマンスとレポートスループットを維持するために必要とされるコンピューティングリソースの量を増加させます。キャパシティの見積もりをすることで、Yellowfinの実装に必要なコンピューティングリソースの量を合理的に把握することができます。
キャパシティ計画の最も重要な要因は、以下の通りです。
3つの主要なシステム要件に対する影響をまとめると、以下のようになります。
| キャパシティ見積の要因 | プロセッサ | メモリ | ディスク容量 |
| ユーザー数 | |||
| 合計ユーザー |  | ||
| アクティブユーザー | | ||
| 同時接続ユーザー | | | |
| データ準備 | |||
| トランスフォーメーションのデザイン | | | |
| トランスフォーメーションの実行 | | | |
| レポートのデザイン | |||
| レポートサイズ | | | |
| 分析的複雑さ | | | |
| レポートレイアウト | | | |
| レポートインタラクション | |||
| レポートの閲覧と作成 | | | |
| レポートのバッチ処理と配信 | | | |
| レポート履歴 | | ||
| 実装と管理 | |||
| メタデータ | | | |
| キャッシュ | | | |
| 監視 | | | |
| ストーリー | |||
| ストーリーのデザイン | | | |
| ストーリーのインタラクション | | | |
| シグナル | |||
| シグナルの実行 | | | |
| シグナルのインタラクション | | | |
アプリケーションの合計ユーザー数は、最も簡単に見積もることのできる要因です。ユーザー情報や、監査証跡、ユニークレポートインスタンス情報はYellowfinのリポジトリに保存されているため、ユーザー数の増加はハードディスク要件を増加させます。ユーザーのアプリケーション使用方法に応じて、CPUやメモリ要件にも影響を与える場合があります。
任意の時点で、典型的なレポートアプリケーションを使用している同時接続ユーザーは、全体の10-20%程度です。Yellowfinのアプリケーションサーバは、システムリソースの共有プールからアクティブユーザーごとにメモリとアドレス空間を割り当てます。同時接続ユーザーセッション数が増加するに従い、アプリケーションサーバに消費されるメモリリソースも増加します。
通常、Yellowfinにログインしているユーザーの30-50%程度が、同時にタスクを実行します。そのため、Yellowfinのアクティブユーザー率は、名前付きユーザー全体の3-10%程度です。アクティブユーザーは、コンピューターサーバのプロセッサやメモリリソースに直接的に影響を与えます。
経験則として、アプリケーションサーバ上の25同時接続ユーザにつき、最低8 GBメモリと3 GHz（8スレッド）プロセッサを使用できます。
例えば、Yellowfinインスタンスに名前付きユーザーが500登録されている場合、任意の時点でログインをしているアクティブユーザーは50程度です（ピーク時の使用量は大幅に増加）。これには最低でも、16 GBメモリを搭載した、16スレッドサーバが必要です。もちろんこれはガイドラインに過ぎず、データベースのサイズや複雑さ、実行されているレポート、オンライン対バックグランド負荷の特性などを含み、リソースの消費は様々な要因に応じて異なります。
各インストールで状況は異なります。本番環境の負荷を想定したパフォーマンステストの実施を強く推奨します。これにより、ソフトウェアがパフォーマンス要件を満たし、Yellowfinコンテンツを合理的な時間で読み込めることを確認することができます。
導入されるレポート数は、キャパシティ要件の決定に重要な要因ですが、レポート数のみでは正確な見積もりをすることはできません。レポートのサイズ、分析的複雑さ、レポートのレイアウトも合わせて考慮する必要があります。
最近実行されたレポートは、メモリリソースを使用してキャッシュに保存されます。使用されるメモリ量は、使用されるデータ量とデータ型に応じて異なり、これは比較的正確に見積もることができます。また、レポート履歴も、ハードディスク容量を使用して保存されます（例：結果セットのXMLのコピーは、レポートが更新される度に、Yellowfinのリポジトリに保存されます）
Yellowfinは、セクションやクロス集計データの生成、計算や小計、ドリル、並べかえ、ピボットの追加、フィルタープロンプトの管理によりレポートに分析機能を追加します。大規模な分析処理を必要とするレポートには、より多くの処理能力とメモリが要求されますが、正確な量を定量するのは困難です。
Yelowfinは、クロス集計グリッドやグラフ、HTML、PDF、CSVなど、様々な方法でレポートに書式を設定します。レポート結果への書式の適用は、処理能力とメモリの両方を使用します。より多くの書式や制御、レポート項目をレポートに含めることで、より多くの処理能力やメモリリソースが消費されます。
電子メールを介したレポートの受信から、複雑なレポート作成機能まで、Yellowfinとのインタラクションレベルはユーザーに応じて異なります。これらのインタラクションによる効果は、以下のようにカテゴリー分けすることができます。
Yellowfinは、非常にリッチなレポーティングや分析、中央集約管理された監視環境を提供します。プラットフォームには、システムへのアクセスや、レポートの検索、実行、印刷などの基礎的な機能から、ドリルや並べかえ、ピボットや計算の追加、エクスポートなどの強力な分析機能まで、幅広い機能があります。洗練されたレポート開発機能もまた、このプラットフォームで利用することができます。
レポートインタラクションの量と種類は、ウェブサーバやアプリケーションサーバ、Yellowfinリポジトリ/データベースサーバ、データソース、ウェブブラウザなど、ウェブインフラのすべての層で、処理能力とメモリの両方を消費します。すべての層に対して、キャパシティを見積もる必要があります。
多くの組織では、頻繁に使用されるレポートや、スケジュール設定されたレポートをバッチで処理しています。理想的には、これらの処理はオフピーク時や、システム使用率の低い時に実行されることが望ましいです。レポートのバッチ処理のためのシステムリソースを管理する重要な制約は、実行され、配信されるレポートの量と、処理が発生するバッチウィンドウのサイズです。短いバッチウィンドウと大量のレポートは、割り当てられた時間内でレポートの処理と配信を完了するために、アプリケーションサーバにより多くの処理能力とメモリリソースを要求します。
レポートの結果セットは、複数のユーザーで使用するために、Yellowfinのリポジトリに保存することができます。これにより、複数バージョンのレポートを比較することができます。これはデータソースの負荷も軽減しますが、Yellowfinのインストールのハードディスク要件を増加させます。
管理者によりクリーンアッププロセスと、削除規定を定義することで、必要とされるリソースの総量を削減することができます。
Yellowfinは、実装を成功に導くために、様々な監視機能や、パフォーマンス強化機能とともに、豊富はアプリケーションメタデータを提供します。機能的な充実と、継続的なパフォーマンス監視の強化は、キャパシティの見積もりで考慮すべきシステムリソースを占有します。
Yellowfinリポジトリのサイズは、アプリケーションサーバのメモリ消費に影響を与えます。起動時にアプリケーションサーバは、メタデータ構成情報をメモリに読み込みます。
Yellowfinは、スループットを向上し、クエリーパフォーマンスを最適化し、エンドユーザーへのレスポンス時間を削減するために、包括的なキャッシュ機能を提供します。サーバのキャッシュはメモリ内に保存されます。
Yellowfinは、Yellowfinリポジトリ/データベースサーバに統計とユーザーアクティビティを記録します。使用率やパフォーマンス統計の保存は、無視できる程度の処理能力やメモリリソースしか消費しませんが、レコードの保存には追加のディスク容量が要求されます。
また、Yellowfinによりログファイルが作成されます。キャパシティの見積もりは、パフォーマンス監視と使用率統計のロギングを考慮しなくてはいけません。これらの監視リソースは、将来的なキャパシティ見積もりや、アクティビティのチューニングを改善するために使用されるべきであることに注意することが重要です。
Yellowfin シグナルが実行する自動解析は、いくつかの要因に応じて、複雑にもシンプルにもなり得ます。システムに影響を与えるシグナル解析の要因は、以下の通りです。
解析される各データセットのサイズに応じて、シグナル解析は、タイムスライス全体を一度に解析するために必要なメモリを要求します。これは、各スライスにより返されるロウ（行）数が、使用されるメモリ量に影響することを意味します。選択されたディメンション（次元）フィールド内の一意のディメンション（次元）値の数と、解析日付範囲のサイズの組み合わせが、各解析サブタスクの最大メモリ使用量に最も大きく影響します。シグナルは、高度に並列化されるように最適化されており、これは、複数のクラスタノードとCPUを利用して、問題を小さな塊に分割し、個別に解析できることを意味します。そのため、通常はCPUスピード/パワーがシグナルのボトルネックになる前に、データベースやネットワーク、メモリ制約が発生しますが、これは非常にパワーの低い環境、もしくは、非常に大量のシグナルタスクやサブタスクを同時に解析している環境で制約になります。
シグナルの実行に関する最後の懸念点は、ディスクの空き容量です。シグナルやその設定に関する非常に大量のメタデータが保存されるほか、複数のシグナルユーザーやジョブによりシステム上に大量の通知が生成される可能性があるため、シグナルはリポジトリデータベースのサイズに大きく影響を与えます。データセットのキャッシュもこれに影響を与えますが、これは構成可能なオプション設定です。
データセットサイズや、関連および相関するグラフなど、いくつかの要因に応じて、シグナルとのインタラクションが、システム全体に比較的負担をかけることがあります。シグナルを開くたびに、いくつかのグラフとともに複数のレポートを実行するという意味で、本質的にはシグナルは、自動生成されるダッシュボードと言えます。これはつまり、複数のユーザーが同時にシグナルを閲覧する場合、メモリやCPU使用率が急増することを意味します。
シグナルデータセットのキャッシュは、多少これをサポートしますが、グラフ生成や、メモリへのデータセットの読み込みは依然として必要です。そして、キャッシュはほとんどの場合、遅いソースがある時に、読み込み時間の短縮をサポートするだけです。より多くのデータセットを同時に読み込む必要があるため、この段階はシグナル解析の実行自体よりも、多くの場合、高い負荷が発生します。
各シグナルとともに表示される自動インサイトの解析は、最初のユーザーがシグナルを開いた時に一度だけ実行されるものです。その後は、キャッシュされ、レンダリングされたバージョンが読み込まれ、レポートは実行はされません。これは、開かれることがないかもしれないシグナルのために、多くの余分な自動インサイトレポートが実行され、保存されるのを防ぐためです。しかしこれは、通常の自動インサイトの解析が持つのと同様の懸念により、システムにも影響を与えます。
|