AMP Engine のベストプラクティス
このドキュメントは、新しい AMP Engine に関連する質問に答えることを目的としています。ドキュメントの読者として、既存の管理者と新規ユーザーの両方を想定しています。
AMP Engineの詳細については、 Alteryx AMP Engine と エンジン のヘルプページを参照してください。
Serverのシステム要件の詳細については、 システム要件 のヘルプページを参照してください。
一般的なトピック
ほとんどのユースケースでは、十分なシステムリソースが提供されると、AMP Engineは従来のEngineよりもパフォーマンスと効率が大幅に向上します。システムリソースの要件と推奨事項の詳細については、 AMPを使用してシステムリソースを管理する方法 と AMP Engineのシステム要件は何ですか? を参照してください。
AMPは、大量のデータをより高速で処理するように設計されており、通常は、従来のEngineに比べてマシンリソースをより効率的に使用して、ワークフローをより迅速に実行します。
従来の Engine のアーキテクチャでは、主にシングルスレッド処理が可能で、データはレコードごとに連続して処理されていました。一方、新しい AMP コンセプトでは、大規模なマルチスレッド処理を可能にします。AMPは、実行時間を改善するために複数レコードをまとめて処理し、ツールを並列に実行できます。また、AMPは、出力レコードの順序に影響を与える可能性のあるレコードのグループ化とソートの際に、よりパフォーマンスの高いアルゴリズムを使用します。
「 AMPでワークフローを強化 」の記事では、AMP Engineを使用することによるパフォーマンス上の利点について説明しています。
最もよく使用されるツール類は AMP で最適なパフォーマンスを発揮します。
通常はデータサイズが大きくなるほど、AMP のメリットが増えます。
パフォーマンスは、データサイズ、基盤となるハードウェア、データセンターとネットワークインフラストラクチャ、Alteryx Server構成、ワークフロー構成によって異なります。
ベンチマーク結果
注記
ベンチマークには、次の測定方法を使用しました。
ワークフロースループット= (workflows / runtime)。runtimeは、ワークフローの実行にかかった合計時間です。
エンジンスループット= (workflows / engine_runtime)。engine_runtimeは、エンジンがワークフローを実行するのにかかった時間です。
Workflows =ワークフローの数
ワークフローが1つしかない場合、エンジンのスループットとワークフロースループットの間に大きな時間差はありません。1つのワーカーのキューに2つのワークフローがある場合、最初のワークフローのランタイムが2番目のワークフローのランタイムに影響します。
一般的なデータ準備タスクのベンチマーク結果
CPUの負荷が高い一般的な予測タスクまたは機械学習タスクのベンチマーク結果
詳細については、このドキュメント下部にある ドキュメンテーションリンク を参照してください。
Designer では、新しいワークフローに対して既定で AMP が有効になりました。Serverの新規インストールまたは既存Serverにおける新規ワーカーの場合、既定ではAMPと従来のEngineの両方の実行が許可されます。ワークフロー設定によって、どちらのエンジンを使用するかが決まります。
1. Controller > General > Enable AMP Engine
1. アップグレードする前に、現在の設定をメモしておきます。
2. アップグレード後、選択を目的の値に戻します。
2. Worker > General > Allow Server to manage workflows running simultaneously
1. アップグレードする前に、[Workflows allowed to run simultaneously] (同時に実行できるワークフロー数) に設定されている数をメモしておきます。
2. アップグレード後、[ Allow Server to manage workflows running simultaneously ] (Server によるワークフローの同時実行の管理を許可する)の選択を解除します。
3. [Workflows allowed to run simultaneously] (同時に実行できるワークフロー数) でメモした番号を入力します。
3. Engine > General > Engine
1. アップグレードする前に、現在の設定をメモしておきます。
2. アップグレード後、選択を目的の値に戻します。
4. Engine > General > Run engine at a lower priority
1. アップグレードする前に、現在の設定をメモしておきます。
2. アップグレード後、選択を目的の値に戻します。
新しいオプション [ 同時に実行されるワークフローのServerによる管理を許可する ] と [ エンジンリソースのServerによる管理を許可する ] を使用することをお勧めします。各エンジンインスタンスが [ システム設定 ] で定義されたメモリと論理CPUの制約内で動作するようにロジックが追加されました。これらの値をServerで管理するのではなく手動で設定する場合には、過剰割り当てを行わないように注意する必要があります。
計算
[ 同時に実行されるワークフローのServerによる管理を許可する ] と [ エンジンリソースのServerによる管理を許可する ] のオプションを有効にすると、Serverは同時に実行されるジョブの数、サービスの起動時にジョブごとに割り当てるCPUスレッド(コア)数とメモリ量を計算します。これらの計算は、使用可能な論理CPUコアの合計数とホストマシン上のシステムメモリリソースの合計に基づいて行われます。また、ベンチマーク結果に基づいて、使用可能なハードウェアに対してAMPパフォーマンスを最適化するように設計されています。これらの計算式は次のとおりです。
注記
同時ジョブ
同時ジョブ数= min(floor(論理プロセッサ/ 8), (floor(合計メモリ/ 8000) - 2))
メモリの上限
メモリ上限= floor(合計メモリ/ (同時ジョブ数 + 2))
処理スレッド
スレッド数= floor(論理プロセッサの合計数/同時ジョブ数)
値を手動設定する際の推奨事項
これらの値を手動で設定する場合は、最適なパフォーマンスを得るために、次のガイドラインに従うことを推奨します。
ワークフロー実行用のメモリ: AMPを使用して最適なパフォーマンスを得るための最小推奨値は、ワークフローあたり8GBです。
ワークフロー実行用のCPU数: 1つの同時実行ワークフローに対し6～8個の論理CPUコア。
並列に動作するAMP Engineの最大数: これは完全にハードウェアに依存します。理論的には、128個の論理コアと160GBのRAMを持つワーカーがあれば、16個のAMPジョブまたはAMPジョブと従来のEngineのジョブの組み合わせを同時に実行できます。ただし、この条件ではディスクI/Oとネットワーク帯域幅がボトルネックになる可能性が高くなります。従来のEngineとAMPはどちらも、データのサイズとデータの入力元および出力先に応じて、ディスクI/Oとネットワーク帯域幅によるパフォーマンスの制限を受けます。
E1も同時実行中に実行されるAMP Engineの最大数: ServerはAMP Engineジョブと従来のEngineのジョブを区別しません。ServerはワークフローをEngineに送信するだけで、EngineがAMPと従来のEngineのどちらで実行するべきかを判断します。そして、AMP Engineが有効な場合、ServerはすべてのジョブがAMPであると想定します。
Server上で実行されているDesignerからのワークフローを手動で実行する場合は、悪影響を回避するために、オペレーティングシステム用にジョブ1つ分のメモリと、さらにジョブもう1つ分のメモリを確保することをお勧めします。リソースを計算するための式は、あらかじめこれらの推奨事項を考慮に入れています。
最新のServerのシステム要件については、 Serverシステム要件 のヘルプページを参照してください。推奨される要件は、 最小ハードウェア要件 と 最適なパフォーマンスのための推奨ハードウェア の 2 つのカテゴリに分かれています。
最小ハードウェア要件
Serverの最小ハードウェア要件は、Alteryx Serverの安定したインストールを実行するために必要な最小限のハードウェアとして定義されています。最小要件を満たしていないと、いずれかのエンジンが稼働しているノードでパフォーマンスが低下し、サービスがランダムにシャットダウンされる危険性があります。
以下の最小ハードウェア要件は、必要な同時実行ワークフロー数に対して推奨されるものです。
注記
緑色で強調表示されている行が、推奨される最小構成です。1同時実行ワークフローの情報を示している行で、既存の設定に1ジョブを追加するためにリソースをどれだけ増やす必要があるかを確認することができます。
最適なパフォーマンスを得るための推奨ハードウェア
Serverの最適なパフォーマンスのためのハードウェアの推奨事項は、AMP Engineを使用するときにServerが可能な限り効率的にワークフローを処理でき、ハードウェアが最も威力を発揮する設定として定義されています。これは、ビジー状態のシステムでの輻輳を解消し、AMP Engineのパフォーマンスとスループットの能力を最適化するのに役立ちます。
最適なパフォーマンスを得るために、次のハードウェア設定を推奨します。
注記
*論理コアは、vCPUまたは物理コア内の論理コアです。標準的に論理コアとして参照しているのは、オンプレミスの物理サーバーとクラウド内の仮想サーバーの両方で一貫して比較するためです。
2022.1 より前のバージョンでは、Server 上で AMP が利用できましたが、既定では無効になっていました。
リリース2022.1以降、新規Serverのインストールでは、コントローラーとワーカーはAMPと従来のEngine両方の実行を許可するように既定で設定されています。既存のServerの場合には、既存のコントローラーとワーカーの設定は変更されませんが、新規ワーカーではすべて、既定でAMPと既存のEngine両方の実行が有効になります。これを回避したい場合は、現在の設定を保持する方法に関するメモを参照してください。
コントローラーとワーカー両方のノードで AMP Engine を有効にする設定は、Alteryx のシステム設定にあります。各エンジンのハードウェア割り当てを管理するための設定が追加されています。また、 [Allow Server to Manage Engine Resources] の設定を推奨します。
既存の Server インストール向けのシステム設定:
Controller > General > Enable AMP Engine の値を変更したことがある場合は、変更した値に関係なく、アップグレード後もその値が維持されます。この設定を変更しておらず、常に既定状態の未選択のままにしている場合は、このチェックボックスがオンになり、AMPが既定で有効になります。
[ ワーカー ] > [ 全般 ] > [ 同時に実行されるワークフローのServerによる管理を許可する ] は、すべてのワーカーで既定値の [ True ] に設定されます。この設定がTrueに設定されていると、同時に実行できるワーカーの数を設定できません。
[Workers allowed to run simultaneously] (同時実行を許可するワーカー数) は、サービス起動時に、Server 環境の CPU とメモリの空き容量に基づいて自動的に計算されます。
Engine > General > Engine の値を変更したことがある場合は、変更した値に関係なく、アップグレード後もその値が維持されます。この設定を変更したことがなく、常に既定の従来のEngineのオプションを使用していた場合、新たな既定値として [両方のエンジン] に設定されます。
Engine > General > Allow Server to manage engine resources は新しい設定で、既定で False に設定されています。
Engine > General > Memory Limit の既定値を計算する式が変更されました。
Engine > General > Default number of processing threads の既定値を計算する式が変更されました。
Engine > General > Run engine at a lower priority : の値を変更したことがある場合は、変更した値に関係なく、アップグレード後もその値が維持されます。常に既定値である [False] を使用していた場合、アップグレード後は新しい既定値である [True] に設定されます。
新規 Server インストール向けのシステム設定:
Controller > General > Enable AMP Engine チェックボックスは既定で True に設定されています。
Worker > General > Allow Server to manage workflows running simultaneously は、すべてのワーカーで既定値の True に設定されています。
[Workers allowed to run simultaneously] (同時実行を許可するワーカー数) は、サービス起動時に、Server 環境の CPU とメモリの空き容量に基づいて自動的に計算されます。
Engine > General > Engine ドロップダウンは、既定で Both Engines (両方のEngine)に設定されます。
Engine > General > Allow Server to manage engine resources は既定で False [に設定されています。.
Engine > General > Memory Limit の既定値を計算する式が変更されました。
Engine > General > Default number of processing threads の既定値を計算する式が変更されました。
Engine > General > Run engine at a lower priority 既定で True に設定されています。
ユーザーが設定を元に戻す (Server で AMP をオフにする) ことはできますか?
管理者が AMP を使用したくない場合、手動でオフにする必要があります。[システム設定] のコントローラー [一般設定] セクションにある [エンジン] の設定については、下図を参照してください。
管理者が一部のワーカーノードで AMP をオフにしたい場合、[システム設定] の [Engine 設定] セクションで設定できます。[エンジン] のドロップダウン設定を下図に示します。下図では、 [Both Engines] に設定されていますが、 [Original Engine] のみを選択して変更することができます。新しい Server の環境では、 [Both Engines] が既定です。
専門のメモリ上限の設定はありません。 System設定 において、 Engine > General > Memory Limit フィールドがエンジンに適用されます。これは、Designer と Server の両方に適用され、基本的にエンジンが稼働しているすべての場所に適用されます。
Designer では 1 回に実行できるワークフローが 1 つだけであるため、それぞれの実行で制限が異なり、それだけ制限が緩くなります。
システムでは、自動的にAMPが有効になり、関連するすべての設定が既定で設定されます。オフにする場合のみ、変更が必要です。「 DesignerとServerにはどのような変更が加えられましたか? 」の回答を参照してください。
最適なパフォーマンスと安定性を得るために、 最小ハードウェア要件のガイドライン に従っていることを確認してください。
Server で AMP を有効にすることで、既存のワークフローに不具合が発生しませんか?
心配はありません。これまでとまったく同じように動作します。
ServerでAMPと従来のEngineの両方の実行を許可すると、既存のワークフローの実行方法が変わりますか?
ワークフローが Designer に保存されている場合、ランタイム設定オプションで [AMP Engine を使用する] を選択するか否かを選択できます。Designer で保存されたオプションは、Server で実行されたときにも適用されます。Server の設定がワークフローのエンジンオプションよりも優先されることはありません。したがって、ServerでAMPと従来のEngineの両方の実行を許可しても、従来のEngineとして保存されたワークフローがAMP Engineで実行されることはありません。AMPをエンジンオプションとしてワークフローが保存され、ServerでAMPが有効になっていない場合は、ワークフローは従来のEngineで実行されることはなく、失敗します。
従来のEngineとして保存されたワークフローをAMPとして実行する場合は、Designerで [ AMP Engineを使用する ] の設定を選択してワークフローを再保存する必要があります。
AMP でワークフローを実行すると、いくつかの処理が並行して行われるため、結果の出力行の順序が変わることがあります。このことを念頭に置いて、プロセスが出力順序に依存しているかどうかを確認してください。依存している場合、従来のEngineの順序に従うようにワークフローを調整します。
各ワークフローの実行時間が変わることが予想されます。
一般に、適切な数の処理コアを使用した場合、AMP ワークフロージョブは大幅に高速化されます。
場合によっては、AMPジョブは従来のEngineのジョブよりも時間がかかることがあります。特にワークフローのCPU負荷が高く、ワークフローあたりのスレッド数が少ない場合には、その傾向が強くなります。
一般に、ワークフローはより高速に終了しますが、競合する AMP ワークフローにリソースを奪われるため、AMP 以外のワークフローの実行に若干時間がかかる場合があります。ただし、 サービス品質 (QOS) の動作に変更はなく、ワークフローはよっては高速に実行されるものもあり得ます。QOS はこれまでと同じように動作します。
AMP が有効になっている場合も、顧客はこれが可能ですか?
タイミングに少し時間がかかるいくつかの例外を除いて、完了までの時間は一貫して改善されるはずです。
AMP を有効にすると、一定の実行時間を保証できなくなる場合、そのような保証が求められているユーザーには、AMP を無効にすることを推奨しますか?
適切なリソースがあれば、AMPと従来のEngineのワークフローはどちらも予測可能なはずです(過去の従来のEngineでのパフォーマンス結果のみを参考にするのではなく、新しいベースラインを使用すれば予測可能)。予測不可能になるのは、ワーカーのハードウェアリソースが十分に割り当てられていない場合だけです(従来のEngineとAMPがリソース競合するため)。
AMP を有効にしてワークフローを Server に保存した後、AMP を無効にしたワークフローのコピーを保存することができます。そうすれば、各ワークフローを何回か実行し、どちらのパフォーマンスが優れているかを確認することができます。AMP ワークフローは、他の AMP ワークフローと同時に実行されたとき、より高速に実行される傾向があります。
サービス品質 (QOS) に関する懸念
Engine Configuration Memory Limit (Engine設定のメモリ上限)は、従来のものかAMPかを問わず、両方のエンジンに適用されます。違いは、各エンジンがそのメモリ上限を処理する方法です。
従来のエンジンは、メモリの割り当て量全てを事前に割り当てます。
AMP はメモリ上限の範囲内で必要な分を割り当てます。
それは、リソースをより効率的に使えることです。従来のエンジンはマルチスレッドですが、高度にマルチスレッド化されているわけではありません。AMP は、ジョブを順次実行したときの方がはるかに力を発揮します。メリットは総スループットで、従来のEngineを使用したときよりもAMPの方が高くなります。
Server はハードウェアを分析し、エンジンごとに適切なリソースを割り当てることが可能になりました。これは OS にあるようなリソースマネージャのレベルではありませんが、この新機能で Server にリソースを管理する機能を実装しました。
管理者が設定しているのであれば、利用可能なハードウェアリソースに基づいて、同時に実行できるジョブの数が自動で割り当てられます。ワーカー設定の詳細については、 ワーカー のヘルプページを参照してください。
そうはなりません。リソースはエンジンジョブごとに割り当てられます。各ジョブがそのジョブ専用のリソースを保有するため、ジョブ間でリソースの競合が発生することはありません。