分析リーダーたちが Alteryx をスケールアウトして、より大きなプロジェクト、より大きなデータセットに取り組み、セルフサービスのデータ分析がより多くの意思決定者の手に渡ることから、Alteryx Server の人気がますます高まっています。小規模小売店やニッチデータプロバイダから、サウスウエスト航空、Chic-fil-A、ウェスタンユニオンなどの大企業まで、さまざまな組織がアナリストの生産性および意思決定の向上のためにAlteryx Serverにアップグレードしました。
LOBアナリストの方は分析プラクティスをエンタープライズ対応にする必要があることをご存知でしょう。その後、Alteryx Server を検討し始め、次のステップについて考え始めたかもしれません。現時点で、Alteryx Server を展開するためのベストプラクティス、スケーリング、ガバナンスに関する多くのご質問をいただいております。そこで私は最近、Alteryx Server のエキスパートのリーダー達、Alteryx Server シニアプロダクトマネージャーの Kory Cunningham、そして Alteryx Server 開発リーダーの Gary Schwartz と Steve Ahlgren を迎えて、よくある質問(FAQ)に回答してもらいました。チームからのフィードバックをご紹介します。
最後までお読みいただき、有難うございました。
Josh Howard, Sr. プロダクトマーケティングマネジャー
人々の関心が高い Alteryx Server の主な機能は何ですか？
KORY CUNNINGHAM - いくつかありますが、最も魅力的な機能の1つは、サーバーハードウェアを活用することができるため、分析を大規模に展開して同時ユーザーをサポートできることです。店舗の分析をする小規模な従業員5名のブティックから、何百人ものユーザーを抱える多国籍企業で展開された Alteryx Server を見てきました。2つ目はスケジューリング関連の機能です。スケジューラを使用すると、ワークフローと分析プロセスの実行、また、よりタイムリーなレポート作成を将来実行するようにスケジュールし、日単位、週単位、月単位のレポートを自動管理します。3つ目はギャラリーです。ギャラリーは、Alteryx のワークフローをギャラリーに公開して他の同僚やビジネスユーザーと共有できる Web インタフェースです。Alteryx をデスクトップにインストールしなくても、同じ分析処理を実行できます。たとえば、フィールドにいる誰かに Web ブラウザにログオンして Gallery にアクセスしてもらうと、Alteryx Designer なしでレポートを実行することができます。ギャラリープラットフォーム内では、ワークフローのコラボレーションとバージョン管理も可能です。変更が行われたときに、それらの変更をユーザーごとに共有、変更、および追跡することができます。これは Alteryx Server プラットフォーム全ての機能のほんの一部です。
Alteryx Server でサポートされている展開構成について教えてください。仮想環境での展開は可能でしょうか？
GARY SCHWARTZ – 展開構成に関しては、マイクロソフトのスタック上にあるので、すべて Windows です。Windows Server 2008 R2 以降をサポートしており、TechSpecs ページで推奨される技術仕様をご確認いただけます。 展開に関しては、サーバーをベアメタルで実行することをお勧めしますが、仮想環境でもサーバーを実行できます。実際、私たちは Amazon の仮想環境でギャラリーを実行しています。一部の仮想環境でテストを行っていますが、それらの環境ではサーバを技術的に認証していません。Alteryx Server は物理環境および仮想環境の両方でうまく機能します。考慮すべきことは、物理的ボックスのリソースの競合です。多くの人が共有している物理ボックス上で実行する場合、リソースの競合が発生する可能性があります。また、CPUとvCPU を考慮する必要もあります。例えば、Amazon では、4、8、または16個の CPU がある場合でも、実際にそれらが参照するのは vCPUです。これは実際の CPU の半分であり、私たちのスペックは物理 CPUに基づいています。そのため、このことを覚えておく必要があります。
どのような種類の認証が提供されていますか？SSO は利用可能ですか？
KORY CUNNINGHAM - ギャラリーに関しては、2つの主要な認証をサポートしています。1つはビルトイン認証です。これは、ユーザーまたは管理者が作成した自分のアカウントを使用して、ユーザーがサインインできるEメールとパスワードです。しかし、NTLM と Kerberos のネイティブサポートを含む、Windows 認証もサポートしています。これにより、ギャラリーユーザーは、自分のマシンへのログオンに使用するのと同じ資格情報を使用してログオンし、認証およびユーザー管理に既存のアクティブディレクトリを利用してギャラリーにアクセスできます。また、10.5 では、ユーザーとしてワークフローを実行する機能も導入されました。ユーザーは、グローバルサーバー管理者アカウントを使用するのではなく、自分の認証情報を使用してワークフローを実行し、許可されたデータにのみアクセスできます。
1つの展開で処理可能なユーザー数やアプリの数はいくつですか？
STEVE AHLGREN – 簡単に言えば、上限を設定して無制限の数のユーザーを処理できるということです。また、Alteryx Server には何百ものユーザーを持つクライアントがあります。ただし、ユーザー数よりも、処理できるアプリの数と種類を検討することの方が重要です。Server の良いところは、Server が直線的に拡張されることです。負荷が増加しても処理できるため、より多くのリソースを投入することができます。利用可能なハードウェアまたは仮想ハードウェアがある場合は、予想される負荷に応じて、その容量までインスタンスを満たすことができます。同時ユーザー数は、内部またはクラウドインフラストラクチャによって提供されるフロントエンドサービスによって制限されます。ロードバランサーをお持ちの場合は、フロントエンドとバックエンドの両方の負荷を処理するようにスケールできます。
Alteryx Server はどのようにスケールできますか？
STEVE AHLGREN – スケーラビリティには主に3つのポイントがあります。可能性の高い順にご紹介します。
- サーバーインスタンスへのワークフロー処理機能の追加。これらを Queue Workers または Render Workers と呼びます。これらはそれぞれ Alteryx ワークフローを処理し、マップタイルをレンダリングする物理または仮想ハードウェアのインスタンスです。Queue WorkersはAlteryx Designer 製品下で動作するのと同じ Alteryx エンジンを実行します。これらをスケーリングするには、主に2つの方法があります。1つは水平方向にスケールアウトすることです。これは、サーバーインスタンスに物理的または仮想的なワーカーを追加することを意味します。2つ目の方法は、垂直方向にスケールアップすることです。これは、既存の物理ノードにより多くのワーカー容量を追加するか、既存の物理ノードにより多くのハードウェアを追加することです。パフォーマンスの向上には、ほとんどの場合、水平方向にスケールアウトし、既存のサーバーインスタンスに物理的なハードウェアと物理的なワーカーを追加することによって達成されることを重視しています。
- 2つ目のスケール方法は、バックエンドデータベースをスケーリングすることです。この例ではMongoDB を使用します。 MongoDB には、冗長性とパフォーマンスのためのスケーラビリティオプションがいくつかあります。そのうちの1つがレプリカセットによるものです。レプリカセットは、データのコピーが常に少なくとも1つ存在するように、同時に複数のノードにデータを書き込むことによって、Mongo がデータの信頼性と冗長性を実現する方法です。ノードが落ちた場合は新しいノードが代わりになり、サーバーは稼働し続けることができます。シャーディングによってデータベースをスケールすることもできます。シャーディングは性能がより高く、小さいディスクサイズの使用を可能にします。これは、Amazon タイプのインフラストラクチャで仮想ハードウェアを使用している場合に重要です。
- 3つ目は、ギャラリーを使用するスケーリング方法です。ギャラリーはクライアントまたは Web ブラウザからのユーザー要求を処理するフロントエンドサービスです。これは、スケーリング時に使われる可能性が最も低い方法です。ボトルネックになりにくいからです。実行しているユーザーやアプリケーションの種類にもよりますが、ロードバランサを使用してスケールすることは可能です。私たちはこれら3つのスケーリング方法全てを実際に Alteryx Public ギャラリーのインスタンスに展開して使用しました。
どのような種類のハードウェアまたはネットワーク仕様が必要ですか？
KORY CUNNINGHAM – 技術に関する全てのドキュメントはこちらからご覧いただけます。http://downloads.alteryx.com/ しかし一般的なインストールでは、2.5GHz以上の16GB以上の RAM とソリッドステートドライブ（SSD）を搭載したクアッドコアのシングル CPU マシンを推奨します。実際に SSD はデータの読み書き速度にかなり大きな違いをもたらします。もう1つ考慮すべきことは、データセットの場所に関連するネットワークトポロジです。例えば、もしサードパーティデータを購入する場合、（例： エクスペリアン（Experian))Server ソフトウェアと同じマシンとネットワーク上の場所の両方にインストールできます。しかし、Serverにインストールするのはパフォーマンスのための最善の選択肢であり、またそれを実行エンジンまたは計算スペースにできるだけ近づけることです。しかし、データをネットワーク上に保存することを許可しているので、データをリモートに保存することができます。データにアクセスして更新するために複数のマシンをリモートで接続するには便利ですが、大きな負荷がかかり、パフォーマンスが低下する可能性があります。マルチノード展開で発生させる必要があるネットワークホップまたはリンクに関しては、それらを最小限に抑えるようにします。そのため、レイテンシーを回避するために、マシンをできるだけ近づけて配置するようにしてください。
GARY SCHWARTZ – ギャラリーが実行されているネットワークとサーバーに関して考えるべきもう1つのことは、ユーザーがアクセスして正しいサーバーを選ぶことができる適切なドメイン名を設定することです。DNS が正しくない例を数々見てきましたが、彼らはなぜギャラリーにアクセスできないのかを理解できませんでした。さらにギャラリーでは、SSL または TLS を使用することをお勧めします。つまり、ロードバランサーの背後で作業している場合を除き、ギャラリーをホストしているサーバーに証明書をインストールする必要があります。ITが集約している可能性があるため、ITチームと協力してSSL 証明書をインストールします。最後に、ギャラリーが実行されているドメインには、他のユーザーが作業する他のドメインと適切なレベルの信頼ポリシーを設定して、アクティブディレクトリがそれに基づいてアクセス許可を決定できるようにする必要があります。
サードパーティの Web サーバーまたはデータベースの要件はありますか？
KORY CUNNINGHAM – Server は、アーキテクチャまたはインストール自体に必要なすべてのコンポーネント（Web サーバーやデータベースなど）をパッケージ化しています。そのため、Server のインストールで全てをインストールして設定することができます。シングルノードマシンの場合、追加の依存関係はありません。ただし、スケールアウトすると、マルチノード環境でサードパーティの要件がいくつか発生する可能性があります。例えば、ギャラリーをスケールアウトする場合は、すべての Web トラフィックを処理するためのロードバランサーを設定する必要があります。Alteryx では Amazon の Elastic Load Balancer を使用していますが、F5 Networks などのIT部門が使用するものも使用できます。上記のようにデータベースをスケールアウトする場合は、MongoDBの埋め込みバージョンをパッケージ化します。しかし、高可用性、冗長性、および信頼性のために Mongo のレプリカセットの利用を開始する場合は、独自の Mongo データベースノードを管理する必要があります。設定の際には、Mongo のスペック、インストール、そしてベストプラクティスを見ることをお勧めします。それ以外に、サードパーティの要件はありません。
GARY SCHWARTZ – Web サーバーについても多くの質問が寄せられています。Web サーバーとデータベースをアーキテクチャーにパッケージ化する一方で、ギャラリーは自己ホスト型 Web サービスです。Tomcat やApache のようなものを使用しているのではなく、その場所からの Web 要求を、待機するベースアドレス設定に登録する自己ホスト型 Webサービスです。
高可用性とデータバックアップを管理する方法は？
GARY SCHWARTZ – 高可用性とはアーキテクチャの冗長性のことであり、アーキテクチャは水平方向にスケールするように設計されているため、プラットフォームはそれをサポートしています。ギャラリー側からは、ロードバランサーの背後に複数の Gallery ノードを配置するようにスケールできます。一方のノードに障害が発生した場合、もう一方のノードを復旧して稼働させるまでの間、トラフィックが発生します。次に、Steveがワーカーノードをスケールアウトすることで、ワークフローのスループットをさらに向上させることについて述べたところに戻ると、ワーカーノードが多ければ多いほど、ワークフローを実行するための可用性が高くなります。そのため、システムの使用状況の監視が必要になります。ワーカーノードが継続的に全容量で稼働している場合は、キャパシティを増やすためにワーカーノードを追加する必要があります。もちろんデータをバックアップすることをお勧めします。そのための最初のステップは、組み込みの Mongo データベースをスケールアウトして、別々のノードに複数の Mongo レプリカセットを立ち上げることです。これにより、即時のバックアップと冗長性が得られます。Mongo の推奨バックアップに従うことをお勧めします。これにはいくつかの戦略があります。 定期的な増分バックアップを使用しているので、フルバックアップを常時実行する必要はなく、途中で増分スナップショットを含む基本バックアップを使用できます。そうして時々フルバックアップをします。
KORY CUNNINGHAM – 組み込み MongoDB インスタンスの基本的なバックアップ機能では、バックアップおよび復元機能を利用できます。しかし、冗長性の高い高可用性ソリューションをお求めの場合は、MongoDBデプロイメントのユーザー管理のマルチノード展開方法をとることをお勧めします。
STEVE AHLGREN – AWS を使用している場合は、地域別配信も設定します。Amazon は停止することもあります。私たちのパブリックギャラリーでさえ、機能停止となることがあります。地域別配信を持つことでほぼ100％のアップタイムを持つことが保証されます。バックアップに関しては、EC2 で実行している場合は EBSスナップショットの設定は簡単です。週単位または日単位にて、これらの EBS スナップショットとフルバックアップを設定できます。
サーバーデプロイメントをどのように監視していますか？
STEVE AHLGREN – デプロイメントを監視する方法はいくつかあります。サーバー内のすべてのコンポーネントには独自のロギングインフラストラクチャーがあります。フロントエンドギャラリーは自身のログを書き、バックエンドも syslog レベルを使った自身の構造を持ち、そして Mongo データベースも自身のログ構造を持っています。 そのため、サーバーアーキテクチャのすべての層に豊富なログ記録があります。全員がこれらのログを収集してAlteryxを使用することをお勧めします。Alteryx は Alteryx を使って私たち自身のログを収集しています。私たちはまた、Logstash や Loggly のようなサードパーティ製のツールにインポートできる Amazon S3 からもログを抽出しますが、おそらくこれに必要なロギングツールは Alteryx があれば事足りることでしょう。その他の監視機能に関しては、Amazon CloudWatch などのサービスを使用して CPU やメモリなどのシステム状態を監視することをお勧めします。これにより、問題やトラブルを早期に表示させることができます。また、MongoDB Cloud Manager を使用したバックエンドデータベースモニタリングもお勧めします。遅いクエリや広範囲のページングによるデータへのアクセスなどを監視するためのもので、どちらも問題を表示してくれます。この他に私たちが使用しているサードパーティ監視ツールは New Relicです。これは、多層サーバーアーキテクチャのフロントエンドノードを監視するために使用します。重要なギャラリープロセス、重い CPU 負荷、ネットワークトラフィックなどのマシンの健全性を監視するために、Amazon CloudWatch と組み合わせて New Relic を使用しています。しかし、私たちはサーバー上の Alteryx 内で実行される、サーバー使用状況報告および監視アプリのパッケージ化もしています。これは、現在のユーザー数、実行キューで待機している平均ジョブ数、ジョブの実行にかかる時間等、サーバーの管理に役立つ基本的な監視をするために、サーバー上の Alteryx 内で実行されます。
どのようなユーザー許可とデータアクセス制御が必要ですか？
KORY CUNNINGHAM - ギャラリー内では、ユーザーを管理し、それらのユーザーにロールによって様々なデータアクセスの規定を行うことができます。ワークフローを実行できるギャラリーにのみアクセスできる基本レベルのビューである基本ビューアー（Viewer）から、コンテンツを提供したり、ワークフローをアップロードしたり、ギャラリーでアプリケーションを作成して他のユーザーと共有したりするアルティザン（Artisan)と呼ばれるユーザーまで、そして最後に、私たちがキュレーターロール (Curator role) と呼ぶもの、つまりギャラリーを管理する管理および管理ロールがあります。コンテンツを作成しているアーティサンのワークフローは私たちが「スタジオ」と呼ぶものに保存されます。スタジオは基本的に制限されたプロジェクトフォルダで、複数のアナリストが共有や共同作業、そして彼らのみが見ることができるワークフローを公開できます。そこから、それらのワークフローを他のスタジオまたは他のユーザーと共有することができ、さらにデータアクセス管理を制御する方法を提供します。 Alteryx Server では、データベースレベルで設定したルールと許可レベルを尊重します。そのため、すべてのワークフローが実行される、グローバル権限を設定する機能が使用できるようになっています。10.5 リリースでは、ワークフローが実行される個々のレベルで権限を設定できるようになり、柔軟性がさらに向上しました。引き続き、機能を拡大していきますので今後のリリースにご期待ください！（編集者注：詳細は Kory のビデオセルフサービスのデータ分析によるデータガバナンスの尊重をご覧ください。）
今回はここまでです。どうもありがとうございました！
Alteryx Server について、質問に答えてくれた Kory、Gary、そして Steve に感謝します。この他にご質問がある場合は、コミュニティに質問、またはこちらのレポートをダウンロードしてください。「Alteryx Server：エンタープライズ向けのセルフサービスデータ分析のスケーリング（Scaling Self-Service Data Analytics for the Enterprise...」。
Josh Howard
