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構成、ワークフロー構成によって異なります。
Designer では、新しいワークフローに対して既定で AMP が有効になりました。Serverの新規インストールまたは既存Serverにおける新規ワーカーの場合、既定ではAMPと従来のEngineの両方の実行が許可されます。ワークフロー設定によって、どちらのエンジンを使用するかが決まります。
注記
Serverバージョン2022.1にアップグレードする際には、エンジン選択設定とリソース割り当てを検証することをお勧めします。新しい "Allow Server to manage workflows running simultaneously" (Serverによるワークフローの同時実行の管理を許可する) 機能と、既定でAMPが有効になる変更により、ご利用の環境で設定が変わる可能性があります。
既存のServerがあり、現在のシステム設定を維持したい場合は、アップグレードする前に次の手順をお読みください。
1.[Controller] > [General] > [Enable AMP Engine]
アップグレードする前に、現在の設定をメモしておきます。
アップグレード後、選択を目的の値に戻します。
2.[Worker > [General > [Allow Server to manage workflows running simultaneously](Serverによるワークフローの同時実行の管理を許可する)
アップグレードする前に、[workflows allowed to run simultaneously](同時に実行できるワークフロー数)に設定されている数をメモしておきます。
アップグレード後、[Allow Server to manage workflows running simultaneously]の選択を解除します。
[workflows allowed to run simultaneously](同時に実行できるワークフロー)にメモした数を入力します。
3.[Engine] > [General] > [Engine]
アップグレードする前に、現在の設定をメモしておきます。
アップグレード後、選択を目的の値に戻します。
4.[Engine] > [General] > [Run engine at a lower priority](低い優先度でEngineを実行)
アップグレードする前に、現在の設定をメモしておきます。
アップグレード後、選択を目的の値に戻します。
新しいオプション [Serverによるワークフローの同時実行の管理を許可する] と [Alow Server to manage Engine resources](エンジンリソースのServerによる管理を許可する)を使用することをお勧めします。各エンジンインスタンスが [システム設定] で定義されたメモリと論理CPUの制約内で動作するようにロジックが追加されました。これらの値をServerで管理するのではなく手動で設定する場合には、過剰割り当てを行わないように注意する必要があります。
計算
[Serverによるワークフローの同時実行の管理を許可する] と [エンジンリソースのServerによる管理を許可する] のオプションを有効にすると、Serverは同時に実行されるジョブの数、サービスの起動時にジョブごとに割り当てるCPUスレッド(コア)数とメモリ量を計算します。これらの計算は、使用可能な論理CPUコアの合計数とホストマシン上のシステムメモリリソースの合計に基づいて行われます。また、ベンチマーク結果に基づいて、使用可能なハードウェアに対してAMPパフォーマンスを最適化するように設計されています。これらの計算式は次のとおりです。
計算式
同時ジョブ
同時ジョブ数= floor(物理プロセッサ数/2)
メモリの上限
メモリ上限= IF (ノードでMongoDBが有効、(((合計物理RAM/2) -4096) /同時ジョブ数)、(合計物理RAM / (同時ジョブ数+2)))
MongoDBが組み込まれた、ワーカーとコントローラーのどちらとしても動作するServerマシンの場合、メモリ上限(MB)は以下の式に基づいて自動的に計算されます。
(((合計物理RAM/2) - 4096) /同時ジョブ数)
スタンドアロンワーカーの場合、以下の式に基づいてより多くのメモリが割り当てられてワークフローが実行されます。
(合計物理RAM / (同時ジョブ数+2))
計算式の結果が2 GB未満の場合は、エンジンを実行できるようにメモリ上限を2 GB以上に設定します。
処理スレッド
既定の処理スレッド数 = [LogicalCores]b
値を手動設定する際の推奨事項
これらの値を手動で設定する場合は、最適なパフォーマンスを得るために、次のガイドラインに従うことを推奨します。
ワークフロー実行用のメモリ: AMPを使用して最適なパフォーマンスを得るための推奨値は、物理コアあたり8 GBです。
ワークフロー実行用のCPU数: 1つの同時実行ワークフローに対し2個の物理コア。
ノードあたりの物理コア数: 最適なパフォーマンスを得るためには、ノードあたり8個の物理コアと追加ノードへの水平スケーリングを推奨します。通常、これはノードごとに4つのワークフローを同時実行できることを意味します。
並列に動作する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であると想定します。
リソースを計算するための式は、あらかじめこれらの推奨事項を考慮に入れています。詳細については、Engineを参照してください。
最新のServerのシステム要件については、Serverシステム要件 のヘルプページを参照してください。推奨される要件は、最小ハードウェア要件と計算負荷の高いワークロードに推奨されるハードウェアの2つのカテゴリに分けられます。
最小ハードウェア要件
Serverの最小ハードウェア要件は、Alteryx Serverの安定したインストールを実行するために必要な最小限のハードウェアとして定義されています。最小要件を満たしていないと、いずれかのエンジンが稼働しているノードでパフォーマンスが低下し、サービスがランダムにシャットダウンされる危険性があります。
以下の最小ハードウェア要件は、必要な同時実行ワークフロー数に対して推奨されるものです。
望ましい同時ワークフロー数 | 最小システム要件 | |
|---|---|---|
メモリ(GB RAM) | 物理コア | |
2 | 32 | 4 |
3 | 48 | 6 |
4 | 64 | 8 |
5 | 80 | 10 |
6 | 96 | 12 |
7 | 112 | 14 |
8 | 128 | 16 |
計算負荷の高いワークロードに推奨されるハードウェア
計算負荷の高いワークロードのためのサーバーハードウェアの推奨事項が、要求の厳しいワークフローをServerができるだけ効率的に実行できる理想的な仕様として定義されています。これは、システムがビジー状態になったときに処理の滞りを減らすために不可欠です。
計算負荷の高いワークロードには、以下のハードウェア仕様が推奨されます。
望ましい同時ワークフロー数 | 計算負荷の高いワークロードでの推奨事項 | ||
|---|---|---|---|
メモリ(GB RAM) | 物理コア | 論理コア* | |
2 | 64 | 8 | 16 |
3 | 96 | 12 | 24 |
4 | 128 | 16 | 32 |
5 | 160 | 20 | 40 |
6 | 192 | 24 | 48 |
7 | 224 | 28 | 56 |
8 | 256 | 32 | 64 |
*論理コアは、vCPUまたは物理コア内の論理コアです。論理コアとして標準的に参照しているのは、オンプレミスの物理サーバーとクラウド内の仮想サーバーの両方で一貫して比較するためです。Intelハイパースレッディング、AMD SMT、vCPUと物理コアの比率2:1。
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が既定で有効になります。
[Worker] > [General] > [Allow Server to manage workflows running simultaneously](Serverによるワークフローの同時実行の管理を許可する)は、既定ですべてのワーカーが[True]に設定されています。この設定がTrueになっていると、同時に実行できるワークフローの数を設定できません。
[Workflows allowed to run simultaneously](同時に実行できるワークフロー数)は、サービス起動時に、このノードの全CPUとメモリに基づいて自動的に計算されます。
[Engine] > [General] > [Engine]の値を変更したことがある場合、変更した値に関係なく、アップグレード後もその値が維持されます。この設定を変更したことがなく、常に既定の従来のEngineのオプションを使用していた場合、新たな既定として[Both Engines](両方のエンジン)に設定されます。
[Engine] > [General] > [Allow Server to manage engine resources](エンジンリソースのServerによる管理を許可する)は新しい設定で、既定で[False]に設定されています。
[Engine] > [General] > [Memory Limit]の既定値を計算するフォーミュラが変更されました。
[Engine] > [General] > [Default number of processing threads](既定の処理スレッド数)の既定値の計算式が変更されました。
[Engine] > [General] > [Run engine at a lower priority] (低い優先度でEngineを実行): この値を変更したことがある場合、変更した値に関係なく、アップグレード後もその値が維持されます。常に既定値の[False]を使用していた場合、アップグレード後は新しい既定値の[True]に設定されます。
新規 Server インストール向けのシステム設定:
[Controller] > [General] > [Enable AMP Engine](AMP Engineを有効にする)チェックボックスは既定で[True]に設定されています。
[Worker] > [General] > [Allow Server to manage workflows running simultaneously](Serverによるワークフローの同時実行の管理を許可する)は、既定ですべてのワーカーが[True]に設定されています。
[Workflows allowed to run simultaneously]は、サービス起動時に、このノードの全CPUとメモリに基づいて自動的に計算されます。
[Engine] > [General] > [Engine]ドロップダウンは、既定で[Both Engines](両方のEngine)に設定されています。
[Engine] > [General] > [Allow Server to manage engine resources]は、既定で[False]に設定されています。
[Engine] > [General] > [Memory Limi]の既定値の計算式が変更されました。
[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] が既定です。
専門のメモリ上限の設定はありません。[システム設定]の[Engine] > [General] > [Memory Limit]フィールドがエンジンに適用されます。これは、Designer と Server の両方に適用され、基本的にエンジンが稼働しているすべての場所に適用されます。
Designer では 1 回に実行できるワークフローが 1 つだけであるため、それぞれの実行で制限が異なり、それだけ制限が緩くなります。
システムでは、自動的にAMPが有効になり、関連するすべての設定が既定で設定されます。オフにする場合のみ、変更が必要です。DesignerとServerにはどのような変更が加えられましたか?の回答を参照してください。
安定したサーバー環境を維持できるよう、最小ハードウェア要件が満たされるようにします。
心配はありません。これまでとまったく同じように動作します。
ワークフローが 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負荷が高く、ワークフローあたりのスレッド数が少ない場合には、その傾向が強くなります。
サービス品質(QOS)はこれまでと同じように動作します。
適切なリソースがあれば、AMPと従来のEngineのワークフローはどちらも予測可能なはずです(過去の従来のEngineでのパフォーマンス結果のみを参考にするのではなく、新しいベースラインを使用すれば予測可能)。予測不可能になるのは、ワーカーのハードウェアリソースが十分に割り当てられていない場合だけです(従来のEngineとAMPがリソース競合するため)。
AMP を有効にしてワークフローを Server に保存した後、AMP を無効にしたワークフローのコピーを保存することができます。そうすれば、各ワークフローを何回か実行し、どちらのパフォーマンスが優れているかを確認することができます。AMP ワークフローは、他の AMP ワークフローと同時に実行されたとき、より高速に実行される傾向があります。
サービス品質 (QOS) に関する懸念
[Engine Configuration Memory Limit](Engine設定のメモリ上限)は、従来のものかAMPかを問わず、両方のエンジンに適用されます。違いは、各エンジンがそのメモリ上限を処理する方法です。
従来のエンジンは、メモリの割り当て量全てを事前に割り当てます。
AMP はメモリ上限の範囲内で必要な分を割り当てます。
それは、リソースをより効率的に使えることです。従来のエンジンはマルチスレッドですが、高度にマルチスレッド化されているわけではありません。AMP は、ジョブを順次実行したときの方がはるかに力を発揮します。メリットは総スループットで、従来のEngineを使用したときよりもAMPの方が高くなります。
Server はハードウェアを分析し、エンジンごとに適切なリソースを割り当てることが可能になりました。これは OS にあるようなリソースマネージャのレベルではありませんが、この新機能で Server にリソースを管理する機能を実装しました。
管理者が設定しているのであれば、ハードウェアの合計リソース数に基づいて、同時に実行できるジョブの数が自動で割り当てられます。ワーカー設定の詳細については、ワーカー のヘルプページを参照してください。
そうはなりません。リソースはエンジンジョブごとに割り当てられます。各ジョブがそのジョブ専用のリソースを保有するため、ジョブ間でリソースの競合が発生することはありません。