Skip to main content

AWSでのApp Builder

このガイドでは、AWSでApp Builderを設定し、データ分析とインサイトを自動化する方法について説明します。以下の手順に従うことで、セットアップを効率的に設定および最適化できます。

必要条件

アカウントのセットアップ

ステップ1: IAMの設定

ステップ1a: App BuilderのIAMポリシーを作成

注記

AAC_AppBuilder_SA_Policyは、ポリシー名の例です。ポリシーには任意の名前を指定できますが、その名前は「AAC_AppBuilder」で始まる必要があります。

カスタムIAMポリシーを作成する必要があります。名前を「AAC_AppBuilder_SA_Policy」とし、以下のポリシードキュメントを添付します。ビジュアルエディターではなくJSONタブを使用することをお勧めします。実行するには、Alteryx Oneに一部*権限が必要です。ポリシーの作成時に、セキュリティ警告が何件か発生する場合があります。

ステップ1b: IAMポリシーのタグ付け
ステップ1aで作成したカスタムIAMポリシーにタグを付けます。
タグ名
値
AACResource
aac_sa_custom_policy
ステップ1c: IAMポリシーの付与
プライベートデータ用のAWSアカウントとVPCのセットアップページで作成したaac_automation_saサービスアカウントに、AAC_AppBuilder_SA_Policy IAMポリシーを添付します。
ステップ2: サブネットの設定
注記
Designer Cloud は、Machine Learning、Auto Insights、およびApp Builderとサブネットの設定を共有します。これらのアプリケーションを複数展開している場合、サブネットの設定は一度のみ必要になります。
プライベートデータ処理環境のDesigner Cloudには、最大3つのサブネットグループが必要です。各グループには3つのサブネットが含まれており、それぞれが別のアベイラビリティゾーンにあります。
  • eks_controlグループ(必須): EKSコントロールプレーンは、このサブネットを使用して入力されたジョブ実行要求を受け入れます。
  • eks_nodeグループ(必須): EKSクラスターは、このサブネットを使用してAlteryxソフトウェアのジョブ(接続、変換、処理、公開など)を実行します。
  • publicグループ(必須): このグループでサービスは実行されませんが、eks_nodeグループがクラスター外への通信にこのサブネットを使用します。
  • privateグループ(必須): このグループは、プライベートデータ処理専用にサービスを実行します。
ステップ2a: VPCでサブネットを作成する
aac-vpc VPCでサブネットを設定します。
サブネットを作成し、以下の例に示すようにタグ付けします。CIDRとサブネットの値は、ネットワークアーキテクチャに合わせて調整できます。
大規模なアドレス空間は、完全にスケールアウトされたクラスターに対応するように設計されています。必要に応じてアドレス空間を小さくすることもできますが、処理負荷が高くなったときにスケーリングに問題が発生する可能性があります。
重要
表に記載されているように、タグ名とタグ値を使用してサブネットにタグを付ける必要があります。
CIDR
サブネット名
サブネット
AZ
タグ名
タグ値
注記
10.64.0.0/18
eks_node
10.64.0.0/21
AZa
AACSubnet
eks_node
eks_node
10.64.8.0/21
AZb
AACSubnet
eks_node
eks_node
10.64.16.0/21
AZc
AACSubnet
eks_node
10.64.24.0/21
予備
10.64.32.0/19
予備(後でブルー/グリーンのアップグレード用に設定可能)
10.10.0.0/21
eks_control
10.10.0.0/27
AZa
AACSubnet
eks_control
eks_control
10.10.0.32/27
AZb
AACSubnet
eks_control
eks_control
10.10.0.64/27
AZc
AACSubnet
eks_control
10.10.0.96/27
予備
パブリック
10.10.0.128/27
AZa
AACSubnet
パブリック
パブリック
10.10.0.160/27
AZb
AACSubnet
パブリック
パブリック
10.10.0.192/27
AZc
AACSubnet
パブリック
10.10.0.224/27
予備
プライベート
10.10.1.0/25
AZa
AACSubnet
プライベート
プライベート
10.10.1.128/25
AZb
AACSubnet
プライベート
プライベート
10.10.2.0/25
AZc
AACSubnet
プライベート
10.10.1.128/25
予備
ステップ2b: サブネットのルートテーブル
サブネット用のルートテーブルを作成します。サブネットのルートテーブルエントリは以下のとおりです。
注記
<gateway id>は、お使いのネットワークアーキテクチャに応じて、各AZに作成されるゾーナルNATゲートウェイまたはトランジットゲートウェイのいずれかになります。NATゲートウェイの場合は、パブリックサブネットのAZごとにNATゲートウェイを作成します。
サブネット名
ルートの宛先
ターゲット
コメント
eks_node
/18 CIDRブロック
/21 CIDRブロック
<s3 prefix id>
0.0.0.0/0
ローカル
ローカル
<vpce endpoint id>
<gateway id>
3つのAZサブネットルーティングテーブルすべてに同じルートを設定します。
eks_control
/18 CIDRブロック
/21 CIDRブロック
<s3 prefix id>
0.0.0.0/0
ローカル
ローカル
<vpce endpoint id>
<gateway id>
3つのAZサブネットルーティングテーブルすべてに同じルートを設定します。
パブリック
/18 CIDRブロック
/21 CIDRブロック
0.0.0.0/0
ローカル
ローカル
<gateway id>
3つのAZサブネットルーティングテーブルすべてに同じルートを設定します。
プライベート
/18 CIDRブロック
/21 CIDRブロック
<s3 prefix id>
0.0.0.0/0
ローカル
ローカル
<vpce endpoint id>
<gateway id>
3つのAZサブネットルーティングテーブルすべてに同じルートを設定します。
0.0.0.0/0はパブリックネットワークに送信される必要があります。
ステップ3: KMSキーポリシーを更新する
プライベートデータ処理が正常に作成されると、credential-service-roleという名前のカスタムロールがアカウントに確立され、Kubernetes資格情報サービスアカウントが、キー保管庫のプライベートデータ資格情報にアクセスできるようになります。さらに、プライベートデータ用のAWSアカウントとVPCのセットアップ(ステップ5: 安全に保管するための対称キーを作成する)で作成したKMSキーのポリシーを更新して、必要な権限を付けてカスタムロールcredential-service-roleを付与します。
  1. [キー管理サービス]に移動し、プライベートデータ用のAWSアカウントとVPCのセットアップ(ステップ5: 安全に保管するための対称キーを作成する)で作成したキーを選択します。
  2. [キーポリシー]を選択し、[編集]を選択します。
  3. 既定の権限を削除し、以下に示す権限で更新します。
    {
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account id>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account id>:role/credential-service-role"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}   
    注記
    <accountId > - プライベートデータ処理環境の処理がプロビジョニングされているAWSアカウント番号。
  4. [変更を保存] を選択します。
プライベートデータ処理
注意
プライベートデータ処理を設定した後に、Alteryx Oneをプロビジョニングされたパブリッククラウドリソースを変更または削除すると、不整合が生じる可能性があります。これらの不整合により、ジョブの実行中またはプライベートデータ処理設定のプロビジョニング解除時にエラーが発生する可能性があります。
ステップ1: App Builderのデプロイをトリガーする
App Builderのプロビジョニングは、Alteryx Oneの管理者コンソールからトリガーできます。このページを表示するには、ワークスペース内のワークスペース管理者権限が必要です。
  1. Alteryx Oneのランディングページで、ユーザーのイニシャルが入った右上の丸いアイコンを選択します。メニューから[管理者コンソール]を選択します。
  2. 左側のナビゲーションメニューから[プライベートデータ処理]を選択します。
  3. Auto Insightsチェックボックスを選択した後、[保存]を選択します。
[更新]を選択すると、AWSアカウント内のクラスターとリソースのデプロイがトリガーされます。これにより、一連の検証チェックが実行され、AWSアカウントの設定が正しいことが確認されます。
最初の検証チェックが完了すると、プロビジョニングが開始されます。画面上のメッセージボックスは、ステータスの変更に合わせて定期的に更新されます。
注記
プロビジョニングプロセスの完了には、約35-40分かかります。
プロビジョニングが完了すると、作成したリソース(EC2インスタンスやノードグループなど)をAWSコンソールから表示できます。これらは絶対に自分で変更しないでください。手動で変更すると、プライベートデータ処理の機能に問題が発生する可能性があります。
このセクションの内容: