# PPSへのパスベースのルーティング

> PPSへのパスベースのルーティング - AWS上のポータブル予測サーバーへのパスベースのルーティング。

This Markdown file sits beside the HTML page at the same path (with a `.md` suffix). It summarizes the topic and lists links for tools and LLM context.

Companion generated at `2026-07-15T05:55:44.911693+00:00` (UTC).

## Primary page

- [PPSへのパスベースのルーティング](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md): Full documentation for this topic (Markdown sidecar).

## Sections on this page

- [開始する前に](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#before-you-start): In-page section heading.
- [必要なツールのインストール](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#install-necessary-tools): In-page section heading.
- [PPSコンテナの設定](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#set-up-pps-containers): In-page section heading.
- [Amazon EKSクラスターの作成](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#create-an-amazon-eks-cluster): In-page section heading.
- [NGINX Ingressコントローラーをデプロイする](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#deploy-the-nginx-ingress-controller): In-page section heading.
- [Kubernetesへのサービスの作成とデプロイ](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#create-and-deploy-services-to-kubernetes): In-page section heading.
- [パスベースのルーティング用のIngressリソースの作成とデプロイ](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#create-and-deploy-ingress-resource-for-path-based-routing): In-page section heading.
- [削除](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#clean-up): In-page section heading.
- [まとめ](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/path-based-routing-to-pps-on-aws.html.md#wrap-up): In-page section heading.

## Documentation content

DataRobot MLOpsにより、ポータブル予測サーバー（PPS）を使用して、Kubernetesクラスター（マネージドまたはセルフマネージドAIプラットフォーム）にDataRobotのモデルをデプロイできます。 PPSは、監視エージェントとDataRobotモデルを含むDockerコンテナであり、Kubernetesなどのコンテナオーケストレーションツールを使用してデプロイできます。 その後、MLOpsの [モニタリング](https://docs.datarobot.com/ja/docs/classic-ui/mlops/monitor/index.html.md) と [ガバナンス](https://docs.datarobot.com/ja/docs/classic-ui/mlops/governance/index.html.md) の機能を使用できます。

同じKubernetesクラスターに複数のPPSをデプロイする場合、すべてのPPSへのエントリーポイントを1つのIPアドレスにしたいことがよくあります。 これに対する典型的なアプローチはパスベースのルーティングで、さまざまなKubernetes Ingressコントローラーを使用して実現できます。 既存のアプローチには、 [Traefik](https://github.com/traefik/traefik) 、 [HAProxy](https://haproxy-ingress.github.io) 、 [NGINX](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) などがあります。

以下のセクションでは、Amazon EKSにデプロイされたPPSへのパスベースのルーティングに、NGINX Ingressコントローラーを使用する方法について説明します。

## 開始する前に

AWSおよび基盤となるサービスとやり取りするには、いくつかの前提条件があります。 これらのツールの一部（またはすべて）がすでにインストールおよび設定されている場合は、対応する手順をスキップできます。 詳細な手順については、 [Amazon EKSの開始方法 – eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) を参照してください。

### 必要なツールのインストール

1. AWS CLI（バージョン2）をインストールします。
2. AWS CLIの認証情報を設定します。
3. eksctlをインストールします。
4. kubectl（KubernetesクラスターのCLI）をインストールして設定します。
5. ツールが正常にインストールされたことを確認します。

### PPSコンテナの設定

この手順は、DataRobot AutoMLモデル用のPPSコンテナを作成してローカルでテストし、それらをAmazon Elastic Container Registry（ECR）にプッシュしたことを前提としています。 詳細については、 [モデルをAWS EKSにデプロイする](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/deploy-dr-models-on-aws.html.md) を参照してください。

この基本ステップは、線形回帰と画像分類のユースケースのモデルで作成された2つのPPSに基づいており、それぞれKaggleの [住宅価格データセット](https://www.kaggle.com/c/home-data-for-ml-course/data) と [Food-101データセット](https://www.kaggle.com/dansbecker/food-101) を使用しています。

最初のPPS（住宅価格）には、eXtreme Gradient Boosted Trees Regressor（Gamma Loss）モデルが含まれています。 2番目のPPS（画像二値分類 - hot dog not hot dog）には、トレーニングスケジュールモデルを使用したSqueezeNet Image Pretrained Featurizer + Keras Slim Residual Neural Network Classifierが含まれています。

後者のモデルは、DataRobot Visual Artificial Intelligence (AI)機能を使用してトレーニングされています。

## Amazon EKSクラスターの作成

[ECRに保存されたDockerイメージ](https://docs.datarobot.com/ja/docs/classic-ui/integrations/aws/deploy-dr-models-on-aws.html.md#push-the-docker-image-to-amazon-ecr) を使用して、Amazon EKSクラスターをスピンアップできます。 EKSクラスターには、次のいずれかを備えたVPCが必要です。

- 2つのパブリックサブネットと2つのプライベートサブネット
- 3つのパブリックサブネット

Amazon EKSでは、少なくとも2つのアベイラビリティーゾーンにサブネットが必要です。 パブリックサブネットとプライベートサブネットを持つVPCをお勧めします。Kubernetesがパブリックサブネットにパブリックロードバランサーを作成して、プライベートサブネット内のノードで実行されるポッドへのトラフィックを制御できるようにします。

1. （オプション）VPCに2つのパブリックサブネットと2つのプライベートサブネットを作成または選択します。 パブリックサブネットに対して「パブリックIPv4アドレスの自動割り当て」が有効になっていることを確認します。 備考対応する--vpc-private-subnetsおよび--vpc-public-subnetsパラメーターを指定しない場合、eksctlツールは必要なすべてのサブネットをバックグラウンドで作成します。
2. クラスターを作成します。 eksctlcreatecluster\--namemulti-app\--vpc-private-subnets=subnet-XXXXXXX,subnet-XXXXXXX\--vpc-public-subnets=subnet-XXXXXXX,subnet-XXXXXXX\--nodegroup-namestandard-workers\--node-typet3.medium\--nodes2\--nodes-min1\--nodes-max3\--ssh-access\--ssh-public-keymy-public-key.pub\--managed 備考--managedパラメーターを使用すると、Amazon EKSマネージド型ノードグループが有効になります。 この機能は、Amazon EKS Kubernetesクラスターのノード（EC2インスタンス）のプロビジョニングとライフサイクル管理を自動化します。 クラスター用に最適化されたノードグループをプロビジョニングできます。 EKSは、最新バージョンのKubernetesとホストOSでノードを最新の状態に保ちます。eksctlツールでは、コマンドラインフラグまたは設定ファイルを使用して、特定のサイズとインスタンスタイプファミリーを選択できます。--ssh-public-keyはオプションですが、クラスターでノードグループを作成するときに指定することを強くお勧めします。 このオプションは、マネージド型ノードグループ内のノードへのSSHアクセスを有効にします。 SSHアクセスを有効にすると、インスタンスに接続して、問題がある場合に診断情報を収集できます。 ノードグループの作成後にリモートアクセスを有効にすることはできません。クラスターのプロビジョニングには通常10～15分かかり、結果は次のようになります。
3. クラスターの準備ができたら、kubectlの設定が正しいかどうかテストします。 kubectlgetsvc

## NGINX Ingressコントローラーをデプロイする

AWS Elastic Load Balancingは、3種類のロードバランサーをサポートしています。Application Load Balancer（ALB）、Network Load Balancer（NLB）、およびClassic Load Balancer（CLB）です。 詳細については、 [Elastic Load Balancingの機能](https://aws.amazon.com/elasticloadbalancing/features/?nc=sn&loc=2) を参照してください。

NGINX IngressコントローラーはAWSでNLBを使用します。 NLBは、極めて高いパフォーマンスが必要な場合のTCP、UDP、TLSトラフィックの負荷分散に最適です。 接続レベル（ [OSIモデルのレイヤー4](https://en.wikipedia.org/wiki/OSI_model#Layer_4:_Transport_Layer) ）で動作するNLBは、トラフィックをAmazon VPC内のターゲットにルーティングし、超低レイテンシーを維持しながら毎秒数百万のリクエストを処理できます。 また、NLBは、突発的で不安定なトラフィックパターンに対処できるよう最適化されています。

NGINX Ingressコントローラーのデプロイ（このマニフェストファイルもNLBを起動）：

```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-
nginx/master/deploy/static/provider/aws/deploy.yaml 
```

## Kubernetesへのサービスの作成とデプロイ

1. Kubernetes名前空間を作成します。 kubectl create namespace aws-tlb-namespace
2. 次の内容をローカルマシン（この場合はhouse-regression-deployment.yaml）のyamlファイルに保存し、プロジェクトの値を置き換えます。以下に例を示します。 apiVersion:apps/v1kind:Deploymentmetadata:name:house-regression-deploymentnamespace:aws-tlb-namespacelabels:app:house-regression-appspec:replicas:3selector:matchLabels:app:house-regression-apptemplate:metadata:labels:app:house-regression-appspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:beta.kubernetes.io/archoperator:Invalues:-amd64containers:-name:house-regression-modelimage:<your_image_in_ECR>ports:-containerPort:80
3. 次の内容をローカルマシン（この場合はhouse-regression-service.yaml）のyamlファイルに保存し、プロジェクトの値を置き換えます。以下に例を示します。 apiVersion:v1kind:Servicemetadata:name:house-regression-servicenamespace:aws-tlb-namespacelabels:app:house-regression-appspec:selector:app:house-regression-appports:-protocol:TCPport:8080targetPort:8080type:NodePort
4. Kubernetesサービスとデプロイを作成します。 kubectl apply -f house-regression-deployment.yaml
kubectl apply -f house-regression-service.yaml
5. 次の内容をローカルマシン（この場合はhot-dog-deployment.yaml）のyamlファイルに保存し、プロジェクトの値を置き換えます。以下に例を示します。 apiVersion:apps/v1kind:Deploymentmetadata:name:hot-dog-deploymentnamespace:aws-tlb-namespacelabels:app:hot-dog-appspec:replicas:3selector:matchLabels:app:hot-dog-apptemplate:metadata:labels:app:hot-dog-appspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:beta.kubernetes.io/archoperator:Invalues:-amd64containers:-name:hot-dog-modelimage:<your_image_in_ECR>ports:-containerPort:80
6. 次の内容をローカルマシン（この場合はhot-dog-service.yaml）のyamlファイルに保存し、プロジェクトの値を置き換えます。以下に例を示します。 apiVersion:v1kind:Servicemetadata:name:hot-dog-servicenamespace:aws-tlb-namespacelabels:app:hot-dog-appspec:selector:app:hot-dog-appports:-protocol:TCPport:8080targetPort:8080type:NodePort
7. Kubernetesサービスとデプロイを作成します。 kubectl apply -f hot-dog-deployment.yaml
kubectl apply -f hot-dog-service.yaml
8. 名前空間に存在するすべてのリソースを表示します。 kubectl get all -n aws-tlb-namespace

## パスベースのルーティング用のIngressリソースの作成とデプロイ

1. 次の内容をローカルマシン（この場合はnginx-redirect-ingress.yaml）のyamlファイルに保存し、プロジェクトの値を置き換えます。以下に例を示します。 apiVersion:networking.k8s.io/v1beta1kind:Ingressmetadata:name:nginx-redirect-ingressnamespace:aws-tlb-namespaceannotations:kubernetes.io/ingress.class:nginxnginx.ingress.kubernetes.io/rewrite-target:/$2labels:app:nginx-redirect-ingressspec:rules:-http:paths:-path:/house-regression(/|$)(.*)backend:serviceName:house-regression-serviceservicePort:8080-path:/hot-dog(/|$)(.*)backend:serviceName:hot-dog-serviceservicePort:8080 備考nginx.ingress.kubernetes.io/rewrite-target注釈は、リクエストをバックエンドポッドに転送する前にURLを書き換えます。 その結果、パス/house-regression/some-house-pathと/hot-dog/some-dog-pathは、それぞれ/some-house-pathと/some-dog-pathに変換されます。
2. パスベースルーティングのIngressを作成します。 kubectl apply -f nginx-redirect-ingress.yaml
3. Ingressが正常に作成されたことを確認します。 kubectl get ingress/nginx-redirect-ingress -n aws-tlb-namespace
4. （オプション）次を使用すると、このイングレスに関する詳細な出力にアクセスできます。 kubectl describe ingress/nginx-redirect-ingress -n aws-tlb-namespace 次の2つのスコアリング要求の出力でAddressの値に注意してください。
5. house-regressionモデルをスコアリングします。 curl -X POST http://<ADDRESS>/house-regression/predictions -H "Content-Type: text/csv" --data-binary @kaggle_house_test_dataset_10.csv
6. hot-dogモデルをスコアリングします。 curl -X POST http://<ADDRESS>/hot-dog/predictions -H "Content-Type: text/csv; charset=UTF-8" --data-binary @for_pred.csv 備考for_pred.csvは、ヘッダー付きの1つの列を含むCSVファイルです。 その列のコンテンツは、Base64でエンコードされた画像です。 予測用の元の写真（ここからダウンロード済み）： 画像はホットドッグであると予測されます。 予測用の別の写真（ここからダウンロード済み）： 画像はホットドッグではないと予測されます。

## 削除

1. サンプルサービス、デプロイ、ポッド、名前空間を削除します。 kubectl delete namespace aws-tlb-namespace
kubectl delete namespace ingress-nginx
2. クラスターを削除します。 eksctl delete cluster --name multi-app

## まとめ

同じIPアドレスの背後にいくつかのKubernetesサービスをデプロイすると、必要なロードバランサーの数を最小限に抑え、アプリケーションのメンテナンスを容易にすることができます。 Kubernetes Ingressコントローラーを適用すると、それが可能になります。

このチュートリアルでは、Amazon EKSプラットフォームにデプロイされたいくつかのポータブル予測サーバー（PPS）へのパスベースのルーティングを展開する方法について説明しました。 このソリューションは、NGINX Ingressコントローラーを介して実装されています。