この記事は、こちらのブログ「 Deploying Karpenter Nodes with Multus on Amazon EKS 」（2024年5月24日公開）を翻訳したものです。 コンテナベースの通信事業者のワークロードでは、トラフィックやネットワークの分離のために Multus CNI をよく使用します。 Amazon Elastic Kubernetes Service（Amazon EKS） は Multus CNI をサポートしており、複数のネットワークインターフェイスをアタッチし、Kubernetes ベースのアプリケーションに対して高度なネットワーク構成や分離を適用することができます。AWS でアプリケーションを実行する利点の 1 つは、リソースの弾力性（スケールアウトおよびスケールイン）です。ノードの弾力性は、 Karpenter のようなクラスターオートスケーラーを使用することで実現できます。Karpenter は、アプリケーションの需要に応じて最適なコンピュートリソースを自動的に起動します。Karpenter は、迅速かつシンプルな Kubernetes クラスターのプロビジョニングを目的として設計されており、Amazon EKS ノードグループの外部でグループレスのノードをプロビジョニングします。 目的 この投稿では、Multus インターフェイス付きの EKS ノードプールを Karpenter でプロビジョニングされるデプロイモデルを紹介します。このデプロイモデルは、特に通信事業者のワークロードに推奨されますが、これに限定されるものではありません。このモデルは、Karpenter をグループレスのノードプールおよびオートスケーリングソリューションとして活用することを目的としています。グループレスのワーカー（ノードプール）は、Multus CNI を必要とするアプリケーション Pod 用であり、一方でAmazon EKS マネージド型ノードグループのワーカーは、プラグイン、アドオン、および Karpenter 自体など、Multus CNI を必要としないポッドを実行します。この投稿では、Karpenter が複数の Elastic Network Interface（ENI）を持つワーカーのリアルタイムスケーリングを管理し、スケーラビリティとネットワーク分離の厳しい要件を満たす方法も示します。 なぜこのようなデプロイモデルなのか？ Karpenter の主なユースケースは、デプロイ時やスケールアウトイベント時に Kubernetes クラスターのワーカーノードをプロビジョニングすることです。この投稿では、Karpenter のもう一つのユースケースとして、Multus CNI を使用するアプリケーションをホスティングするノードプールをプロビジョニングする方法を紹介します。このデプロイモデルは、アプリケーションのワーカーノードを Amazon EKS マネージド型ノードグループから切り離します。このアプローチの利点は、1）アプリケーションワーカーは特定のインスタンスタイプやサイズに限定されず、インスタンスのタイプやファミリーの幅広い選択肢を利用できること。2）アプリケーションのスケールアウト機能が Amazon Elastic Compute Cloud（Amazon EC2） Auto Scaling グループに結びつかず、Amazon EKS マネージド型ノードグループを通じて Auto Scaling グループを利用する場合よりも、柔軟にスケールできることです。また、EC2 Auto Scaling グループに依存しないため、Karpenter は Amazon EC2 fleet API を直接使用してワーカーノードを迅速にプロビジョニングできます。これはアプリケーションのスケールアウトシナリオにおいてかなり重要です。標準の Karpenter ベースのノードプロビジョニングは、単一の VPC サブネットに接続されたノードを作成するため、Multus CNI をサポートしていません。この投稿では、EC2NodeClass を使用することにより、user-data を活用した ENI 管理を導入することで、Karpenter を介して Multus をサポートするソリューションを提供します。 デプロイ このセクションで説明される手順の詳細は、こちらの GitHub リポジトリを参照しています。 このデプロイは、Multus CNI を使用したアプリケーション Pod を Karpenter で柔軟に実行できることを示しています。Karpenter を介して Multus 用の ENI を作成およびアタッチするアプローチを適用し、併せて Karpenter のスケーリング機能も実演します。 前提条件 この投稿の手順を進めるには、以下の前提条件が必要です。 AWS CloudShell 環境設定 このセットアップでは、VPC、EKS クラスター、EKS マネージド型ノードグループ、セキュリティグループ、および関連するVPCコンポーネントを作成します。 1. ここでは CloudShell 環境を使用して EKS クラスターを構成し、サンプルアプリケーションをデプロイします。CloudShell コンソールに移動し、この GitHub リポジトリをダウンロードして、必要なツール（awscli、kubectl、eksctl、helmなど）をインストールするための次のスクリプトを実行します。 sudo chmod +x tools/installTools.sh ./tools/installTools.sh 2. テンプレート `vpc-infra-mng.yaml` を使用して AWS CloudFormation スタックを作成します。2つのアベイラビリティゾーン（例：`us-west-2a` および `us-west-2b`）を選択します。スタック名を `karpenterwithmultus` とします（このスタック名は後で CloudShell 環境で使用します）。他のパラメータはデフォルトのままにしておくことができます。次の  AWS Command Line Interface (AWS CLI) コマンドを使用するか、 AWS マネジメントコンソール の CloudFormation メニューを使用してスタックを作成します。 aws cloudformation create-stack --stack-name karpenterwithmultus --template-body file://cfn-templates/vpc-infra-mng.yaml --parameters ParameterKey=AvailabilityZones,ParameterValue=us-west-2a\\,us-west-2b --region us-west-2 --capabilities CAPABILITY_NAMED_IAM 次の手順を実行する前に、最初の CloudFormation スタック作成が完了していることを確認してください。EKSクラスターとワーカーノードの構築には約15分かかる場合があります。 結果として得られるアーキテクチャは次の図のようになります。 3. CloudShell で、Karpenter バージョン、EKS クラスター名、および AWS リージョン を定義するために環境変数を作成します。パラメータ値を環境に応じて変更して、CloudShell コンソールに移動して次のコマンドを実行します。 export KARPENTER_NAMESPACE=karpenter export K8S_VERSION=1.29 export KARPENTER_VERSION=v0.32.3 export AWS_PARTITION="aws" export VPC_STACK_NAME="karpenterwithmultus" export CLUSTER_NAME="eks-${VPC_STACK_NAME}" export AWS_DEFAULT_REGION=us-west-2 export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)" export TEMPOUT=$(mktemp) 注： `VPC_STACK_NAME`は、CloudFormationテンプレート`vpc-infra-mng.yaml`で指定した名前を使います。 デフォルトのリージョンに注意してください。後のステップで、`nodepool.yaml`にはアベイラビリティゾーン（AZ）を指定します。 この例では CloudShell を admin ノードとして使用します。CloudShell がタイムアウトすると、環境変数が失われます。CloudShell 以外の admin ノードを使用しても問題ないです。 Kubeconfig を更新し、Amazon EKS コントロールプレーンへのアクセスをテストします。 aws eks update-kubeconfig --name $CLUSTER_NAME kubectl get nodes kubectl get pods -A エラーが表示されなければ、K8Sクラスターへのアクセスが確認されます。 プラグインの設定 4. Multus CNI をインストールします。 Multus CNI は、Kubernetes 用のコンテナネットワークインターフェースプラグインであり、Pod に複数のネットワークインターフェースをアタッチできます。Multus CNI と VPC CNI が Amazon EKS でどのように機能するかについて理解したい場合は、こちらの Amazon Container の記事 を参照してください。 kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/multus/v4.0.2-eksbuild.1/multus-daemonset-thick.yml kubectl get daemonsets.apps -n kube-system 5. Multus の IP アドレスレンジを専有させるために Multus サブネット用の CIDR 予約が必要です。CIDR 予約で明示的なフラグを設定すると、VPC が ENI などの VPC リソースを作成する際にこれらの CIDR ブロックに使わないようになります。次の CIDR 予約コマンドを Multus サブネットで実行し、/27 の IP レンジを確保します。 Multus1Az1subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus1Az1-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus1Az1subnetId} --cidr 10.0.4.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} Multus1Az2subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus1Az2-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus1Az2subnetId} --cidr 10.0.5.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} Multus2Az1subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus2Az1-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus2Az1subnetId} --cidr 10.0.6.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} Multus2Az2subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus2Az2-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus2Az2subnetId} --cidr 10.0.7.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} 注： エラーが発生した場合、例えば`subnet ID doesn’t exist`のエラーが表示された場合は、正しい AWS_DEFAULT_REGION 環境変数が定義されているかどうかを確認してください。 6. Whereabouts プラグインをインストールします。Whereabouts は、前のステップで設定した Multus Pod IP アドレスを管理するために使用する IPAM CNI プラグインです。Whereabouts を使用した Multus Pod IP アドレスは、Custom Resource Definition（CRD）Network-Attachment-Definitions（NAD）を介して定義されます。 kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/whereabouts/master/doc/crds/daemonset-install.yaml kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/whereabouts/master/doc/crds/whereabouts.cni.cncf.io_ippools.yaml kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/whereabouts/master/doc/crds/whereabouts.cni.cncf.io_overlappingrangeipreservations.yaml kubectl get daemonsets.apps -n kube-system 7. クラスターに NetworkAttachmentDefinitions を適用します。これは、後でアプリケーション Pod を作成するときに、Pod 上の Multus インターフェースのコンフィグになります。このファイルを確認すると、前のステップで設定した CIDR 予約プレフィックスが定義されていることがわかります。 kubectl apply -f sample-application/multus-nad-az1.yaml kubectl apply -f sample-application/multus-nad-az2.yaml IAM ロールの設定 8. Karpenter IAM ロールおよび Karpenter に必要なその他の前提条件を作成します。このステップが完了すると、「Successfully created/updated stack – <Karpenter-${CLUSTER_NAME}>」というメッセージが表示されるはずです。 curl -fsSL https://raw.githubusercontent.com/aws/karpenter/"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > $TEMPOUT \ && aws cloudformation deploy \ --stack-name "Karpenter-${CLUSTER_NAME}" \ --template-file "${TEMPOUT}" \ --capabilities CAPABILITY_NAMED_IAM \ --parameter-overrides "ClusterName=${CLUSTER_NAME}" eksctl create iamidentitymapping \ --username system:node:{{EC2PrivateDNSName}} \ --cluster "${CLUSTER_NAME}" \ --arn "arn:aws:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}" \ --group system:bootstrappers \ --group system:nodes eksctl utils associate-iam-oidc-provider \ --cluster "${CLUSTER_NAME}" \ --approve eksctl create iamserviceaccount \ --cluster "${CLUSTER_NAME}" --name karpenter --namespace karpenter \ --role-name "${CLUSTER_NAME}-karpenter" \ --attach-policy-arn "arn:aws:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}" \ --role-only \ --approve export KARPENTER_IAM_ROLE_ARN="arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-karpenter" echo $KARPENTER_IAM_ROLE_ARN 9. Multus に必要な AWS Identity and Access Management (IAM) ポリシーを作成し、それを Karpenter ノードロールにアタッチします。EC2NodeClass の userdata セクションには、Karpenter でプロビジョニングされたノードに ENI を作成、アタッチ、およびコンフィグするためのスクリプトが含まれています。ノードには、Karpenter ノードロールに適切なポリシーをアタッチする必要があります。 aws iam create-policy --policy-name karpenter-multus-policy --policy-document file://config/multus-policy.json | jq -r '.Policy.Arn' karpentermultuspolicyarn=$(aws iam list-policies | jq -r '.Policies[] | select(.PolicyName=="karpenter-multus-policy") | .Arn') aws iam attach-role-policy --policy-arn $karpentermultuspolicyarn --role-name KarpenterNodeRole-${CLUSTER_NAME} 10.（オプション）スポットインスタンスを使用するためのロールを、下記のコマンドで作成します。 aws iam create-service-linked-role --aws-service-name spot.amazonaws.com || true 既にロールが正常に作成されている場合は、次のようなメッセージが表示されます。 # An error occurred (InvalidInput) when calling the CreateServiceLinkedRole operation: Service role name AWSServiceRoleForEC2Spot has been taken in this account, please try a different suffix. 注 ：このステップはオプションであり、Karpenter ノードプールでスポットインスタンスを使用したい場合にのみ必要です。 Karpenter のインストール 11. Karpenter をインストールします。 helm registry logout public.ecr.aws helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version ${KARPENTER_VERSION} --namespace karpenter --create-namespace \ --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=${KARPENTER_IAM_ROLE_ARN} \ --set settings.aws.clusterName=${CLUSTER_NAME} \ --set settings.aws.defaultInstanceProfile=KarpenterNodeInstanceProfile-${CLUSTER_NAME} \ --set settings.aws.interruptionQueueName=${CLUSTER_NAME} \ --set controller.resources.requests.cpu=1 \ --set controller.resources.requests.memory=1Gi \ --set controller.resources.limits.cpu=1 \ --set controller.resources.limits.memory=1Gi \ --wait 12. Karpenter Pod が `Running` 状態にあるか確認するために次のコマンドを実行します。 kubectl get pods -n karpenter -o wide 13. `nodepool.yaml` ファイルに含まれる Multus サブネットタグ名、AZ、およびセキュリティグループタグ名を更新します。Karpenter ノードプール構成の詳細については、こちらの Karpenter の記事を参照してください。 sed -i "s/##Multus1SubnetAZ1##/Multus1Az1-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus2SubnetAZ1##/Multus2Az1-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus1SubnetAZ2##/Multus1Az2-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus2SubnetAZ2##/Multus2Az2-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus1SecGrpAZ1##/Vpc1SecurityGroup/g" config/nodepool.yaml sed -i "s/##Multus2SecGrpAZ1##/Vpc1SecurityGroup/g" config/nodepool.yaml sed -i "s/##Multus1SecGrpAZ2##/Vpc1SecurityGroup/g" config/nodepool.yaml sed -i "s/##Multus2SecGrpAZ2##/Vpc1SecurityGroup/g" config/nodepool.yaml `nodepool.yaml` を正しい AZ 名で更新し、次のコマンドを実行します。この例では、`us-west-2a` および `us-west-2b` を使用しています。 AZ1='us-west-2a' AZ2='us-west-2b' sed -i "s/##AVAILABILITY_ZONE1##/${AZ1}/g" config/nodepool.yaml sed -i "s/##AVAILABILITY_ZONE2##/${AZ2}/g" config/nodepool.yaml 次のコマンドを使用して EKS クラスター名を更新します。 sed -i "s/##CLUSTER_NAME##/${CLUSTER_NAME}/g" config/nodepool.yaml Karpenter ノードプール構成を適用します。 kubectl apply -f config/nodepool.yaml 注：`config/nodepool.yaml` ファイルを確認すると、EC2NodeClass の userdata セクションがカスタマイズされていることがわかります。userdata 内のスクリプトは、Amazon EC2 ノードプールの作成時に MULTUS ENI をプロビジョニング、アタッチ、およびコンフィグします。これはノードプール上の MULTUS ENI LCM を設定するところです。追加のノードチューニングが必要な場合は、userdata セクションに追加することができます。 ノードプールコンフィグにエラーがある場合は、Karpenter コントローラーのログを確認してください。 kubectl logs -f -n karpenter -l app.kubernetes.io/name=karpenter -c controller 14. ノードプール内のノードで Multus DaemonSet Pod とアプリケーション Pod が同時にスケジュールされると競合状態が発生します。この課題を解決するために、Karpenter のノードプールを `StartupTaints` で構成する必要があります。`StartupTaint` は、Multus が準備完了するまでアプリケーション Pod が新しいノードにスケジュールされるのを防ぎます。Multus が準備できたら Taint が削除されます。Taint の削除を自動化するために、この投稿では DaemonSet ベースのソリューションを使用します。 まず、Taint を削除するまたの DaemonSet 用のネームスペースを作成します。 kubectl create namespace cleartaints DaemonSet `daemonset-clear-taints` がノード上の Taint を削除できるようにするための RBAC コントロールを提供する必要があります。次のコマンドで、`cleartaints` ネームスペースに限定された Service Account 、Service Account Role 、および Role Binding を作成します。 kubectl apply -f config/sa-role-rolebinding.yaml `cleartaints` というネームスペースで、` daemonset-clear-taints ` という名前の DaemonSet を作成して適用します。 kubectl apply -f config/cleartaints.yaml DaemonSet Pod を確認します。Karpenter ノードプールでのみ実行されるため、この時点では DaemonSet は表示されません。 kubectl get ds -n cleartaints Node-Latency-For-K8s のデプロイ 15.（オプション）ノードプールのスケールアウト速度に関するデータを収集するために、 Node-Latency-For-K8s ソリューション をデプロイできます。Node-Latency-For-K8s は、ノード起動遅延を分析するためのオープンソースツールです。このツールは、ノードがインスタンス化されるから、アプリケーション Pod が実行されるまでの各フェーズでかかった時間を測定します。後のステップではいくつかの例を取り上げます。 export VERSION="v0.1.10" SCRIPTS_PATH="https://raw.githubusercontent.com/awslabs/node-latency-for-k8s/${VERSION}/scripts" TEMP_DIR=$(mktemp -d) curl -Lo ${TEMP_DIR}/01-create-iam-policy.sh ${SCRIPTS_PATH}/01-create-iam-policy.sh curl -Lo ${TEMP_DIR}/02-create-service-account.sh ${SCRIPTS_PATH}/02-create-service-account.sh curl -Lo ${TEMP_DIR}/cloudformation.yaml ${SCRIPTS_PATH}/cloudformation.yaml chmod +x ${TEMP_DIR}/01-create-iam-policy.sh ${TEMP_DIR}/02-create-service-account.sh ${TEMP_DIR}/01-create-iam-policy.sh && ${TEMP_DIR}/02-create-service-account.sh export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)" export KNL_IAM_ROLE_ARN="arn:aws:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-node-latency-for-k8s" docker logout public.ecr.aws helm upgrade --install node-latency-for-k8s oci://public.ecr.aws/g4k0u1s2/node-latency-for-k8s-chart \ --create-namespace \ --version ${VERSION} \ --namespace node-latency-for-k8s \ --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=${KNL_IAM_ROLE_ARN} \ --set env[0].name="PROMETHEUS_METRICS" \ --set-string env[0].value=true \ --set env[1].name="CLOUDWATCH_METRICS" \ --set-string env[1].value=false \ --set env[2].name="OUTPUT" \ --set-string env[2].value=markdown \ --set env[3].name="NO_COMMENTS" \ --set-string env[3].value=false \ --set env[4].name="TIMEOUT" \ --set-string env[4].value=250 \ --set env[5].name="POD_NAMESPACE"\ --set-string env[5].value=default \ --set env[6].name="NODE_NAME" \ --set-string env[6].value=\(v1\:spec\.nodeName\)\ --wait サンプルアプリケーションのデプロイ 16. サンプルアプリケーションをデプロイします。次のコマンドは、各 AZ に1つのアプリケーションレプリカを持つ Deployment をインストールします。これにより、Karpenter がアプリケーションをスケジュールできるようにノードプールの作成がトリガーされます。 `multitool-deployment-az1.yaml`、`multitool-deployment-az2.yaml` の各ファイルで、正しい AZ 名に更新します。 sed -i "s/##AVAILABILITY_ZONE1##/${AZ1}/g" sample-application/multitool-deployment-az1.yaml sed -i "s/##AVAILABILITY_ZONE2##/${AZ2}/g" sample-application/multitool-deployment-az2.yaml kubectl apply -f sample-application/multitool-deployment-az1.yaml kubectl apply -f sample-application/multitool-deployment-az2.yaml 各 Deployment には `karpenter-node` というアフィニティキーがあり、これによりアプリケーション Pod はラベル「`karpenter-node`」が付いたワーカーノードにのみスケジュールされます。Deployment が作成されるときに、Karpenter ノードプールはラベルを割り当てるため、これらの Deployment の Pod をスケジュール/実行するためにノードをスケールします。 次のコマンドを使用して、Karpenter が新しい Amazon EKS ワーカーノードをスケーリングするのを監視します。 kubectl get nodes -o wide Karpenter のログを確認します。 kubectl logs -f -n karpenter -l app.kubernetes.io/name=karpenter -c controller Karpenter が新しい EC2 インスタンスを起動し、EKS クラスターに参加し、`Ready` 状態になると、`Pending` 状態のポッドが `Running` 状態に移行します。 kubectl get pods -o wide 次の図のように、Multus インターフェースを持つ Karpenter ワーカーが追加されたアーキテクチャが完成します。 17. 次のコマンドを使用して、アプリケーション Pod が `Running` 状態であることを確認します。 $ kubectl get node NAME STATUS ROLES AGE VERSION NAME STATUS ROLES AGE VERSION ip-10-0-2-110.us-west-2.compute.internal Ready <none> 8m25s v1.28.5-eks-5e0fdde ip-10-0-2-156.us-west-2.compute.internal Ready <none> 29m v1.28.5-eks-5e0fdde ip-10-0-3-117.us-west-2.compute.internal Ready <none> 8m20s v1.28.5-eks-5e0fdde ip-10-0-3-146.us-west-2.compute.internal Ready <none> 29m v1.28.5-eks-5e0fdde $ kubectl get pod NAME READY STATUS RESTARTS AGE scaleouttestappaz1-6695b7f878-xjh66 1/1 Running 0 10m scaleouttestappaz2-7f88f964b6-8sz9r 1/1 Running 0 10m `kubectl describe pod` または `kubectl exec` を使用して Pod を確認し、Multus インターフェースとアドレスを確認できます。 kubectl describe pod|grep "multus " Normal AddedInterface 42s multus Add eth0 [10.0.2.73/32] from aws-cni Normal AddedInterface 42s multus Add net1 [10.0.4.32/24] from default/nad-multussubnet1az1-ipv4 Normal AddedInterface 42s multus Add net2 [10.0.6.32/24] from default/nad-multussubnet2az1-ipv4 Normal AddedInterface 45s multus Add eth0 [10.0.3.212/32] from aws-cni Normal AddedInterface 44s multus Add net1 [10.0.5.32/24] from default/nad-multussubnet1az2-ipv4 Normal AddedInterface 44s multus Add net2 [10.0.7.32/24] from default/nad-multussubnet2az2-ipv4 1つのポッドを選択し、次の `exec` コマンドを実行して Multus Pod の IP アドレスを確認します。`net1` および `net2` インターフェースが Multus インターフェースとして表示されます。Amazon EC2 ワーカー上では、Multus ENI はそれぞれ `eth1` および `eth2` と同じサブネットに属しています。 $ kubectl exec scaleouttestappaz1-6695b7f878-xjh66 -- ifconfig net1 net1 Link encap:Ethernet HWaddr 02:11:D3:5B:D6:6B inet addr:10.0.4.35 Bcast:10.0.4.255 Mask:255.255.255.0 inet6 addr: fe80::211:d300:15b:d66b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:450 (450.0 B) TX bytes:978 (978.0 B) $ kubectl exec scaleouttestappaz1-6695b7f878-xjh66 -- ifconfig net2 net2 Link encap:Ethernet HWaddr 02:8B:1B:57:0D:35 inet addr:10.0.6.35 Bcast:10.0.6.255 Mask:255.255.255.0 inet6 addr: fe80::28b:1b00:157:d35/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:51 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5070 (4.9 KiB) TX bytes:558 (558.0 B) 注 ：Multus Pod IP アドレスを確認します。これらの IP は、ステップ 6 で定義した NetworkAttachmentDefinitions ファイルで設定した範囲に属しています。 （オプション）Karpenter ノードプールのプロビジョニングにかかる時間を調べるために、Node-Latency-For-K8s のログを新しく作成されたノードで確認できます。`node-latency-for-k8s-node-latency-for-k8s-chart-xxxxx` Pod のログを取得します。例として、ログの取得に約5分かかる場合があります。 $ kubectl -n node-latency-for-k8s logs node-latency-for-k8s-node-latency-for-k8s-chart-7bzvs 2023/12/22 16:57:09 unable to measure terminal events: [Pod Ready] ### i-0cb4baf2a1aa35077 (10.0.3.7) | c6i.2xlarge | x86_64 | us-east-1d | ami-03eaa1eb8976e21a9 | EVENT | TIMESTAMP | T | COMMENT | |--------------------------|----------------------|-----|---------| | Pod Created | 2023-12-22T16:46:30Z | 0s | | | Instance Pending | 2023-12-22T16:46:41Z | 11s | | | VM Initialized | 2023-12-22T16:46:51Z | 21s | | | Network Start | 2023-12-22T16:46:53Z | 23s | | | Network Ready | 2023-12-22T16:46:54Z | 24s | | | Cloud-Init Initial Start | 2023-12-22T16:46:54Z | 24s | | | Containerd Start | 2023-12-22T16:46:54Z | 24s | | | Containerd Initialized | 2023-12-22T16:46:55Z | 25s | | | Cloud-Init Config Start | 2023-12-22T16:46:55Z | 25s | | | Cloud-Init Final Start | 2023-12-22T16:46:55Z | 25s | | | Cloud-Init Final Finish | 2023-12-22T16:47:16Z | 46s | | | Kubelet Start | 2023-12-22T16:47:16Z | 46s | | | Kubelet Initialized | 2023-12-22T16:47:17Z | 47s | | | Kubelet Registered | 2023-12-22T16:47:17Z | 47s | | | Kube-Proxy Start | 2023-12-22T16:47:20Z | 50s | | | VPC CNI Init Start | 2023-12-22T16:47:20Z | 50s | | | AWS Node Start | 2023-12-22T16:47:25Z | 55s | | | Node Ready | 2023-12-22T16:47:27Z | 57s | | 注 ：起動時に実行される userdata スクリプト（約20-25秒）は、ノードが Ready になるまでの時間に加算されます。userdata スクリプトを使用しない場合、Karpenterノードの Readby になる時間は約30秒です。 （オプション）Multus Pod IP の自動割り当て Pod への Multus 接続には、Multus IP をワーカーノード上の対応する Multus ENI のセカンダリIPとして割り当てることが重要です。この GitHub リンク を使用して、InitContainer ベースの IP 管理ソリューションまたは Sidecar ベースの IP 管理ソリューションをアプリケーション Pod 内で使用して、Multus IP を自動的に Multus ENI にセカンダリ IP として割り当てることができます。 スケーリング 18. 次のコマンドを使用してスケールアウトを実行し、Karpenter を使用したノードの追加スケーリングをテストし、ノードのスケーリングを監視します。 kubectl scale --replicas=5 deployment/scaleouttestappaz1 kubectl scale --replicas=5 deployment/scaleouttestappaz2 kubectl get nodes -o wide -w kubectl get pods 19.（オプション）Karpenter のスケールアウト速度に関するデータをもう一度収集します。新しく作成されたノードプールワーカーで `node-latency-for-k8s-node-latency-for-k8s-chart-xxxxx` Pod のログを取得します。 $ kubectl -n node-latency-for-k8s logs node-latency-for-k8s-node-latency-for-k8s-chart-28wsr ### i-005dfff5abc7be596 (10.0.2.176) | c6i.2xlarge | x86_64 | us-east-1c | ami-03eaa1eb8976e21a9 2023/12/22 17:14:55 unable to measure terminal events: [Pod Ready] | EVENT | TIMESTAMP | T | COMMENT | |--------------------------|----------------------|-----|---------| | Pod Created | 2023-12-22T17:04:16Z | 0s | | | Instance Pending | 2023-12-22T17:04:20Z | 4s | | | VM Initialized | 2023-12-22T17:04:29Z | 13s | | | Network Start | 2023-12-22T17:04:33Z | 17s | | | Network Ready | 2023-12-22T17:04:33Z | 17s | | | Cloud-Init Initial Start | 2023-12-22T17:04:33Z | 17s | | | Containerd Start | 2023-12-22T17:04:33Z | 17s | | | Cloud-Init Config Start | 2023-12-22T17:04:34Z | 18s | | | Cloud-Init Final Start | 2023-12-22T17:04:34Z | 18s | | | Containerd Initialized | 2023-12-22T17:04:35Z | 19s | | | Cloud-Init Final Finish | 2023-12-22T17:05:00Z | 44s | | | Kubelet Start | 2023-12-22T17:05:00Z | 44s | | | Kubelet Initialized | 2023-12-22T17:05:00Z | 44s | | | Kubelet Registered | 2023-12-22T17:05:03Z | 47s | | | Kube-Proxy Start | 2023-12-22T17:05:05Z | 49s | | | VPC CNI Init Start | 2023-12-22T17:05:05Z | 49s | | | AWS Node Start | 2023-12-22T17:05:09Z | 53s | | | Node Ready | 2023-12-22T17:05:11Z | 55s | | 2023/12/22 17:14:55 Serving Prometheus metrics on :2112 20. Karpenter は、`Pending` 状態のポッドの数に応じて必要なノードを自動的にプロビジョニングする柔軟性があります。レプリカの数を増やすことで、スケールインとスケールアウトをもう一度行うことができます。Karpenter がプロビジョニングしたインスタンスタイプとサイズを注目してください。 スケールイン： kubectl scale --replicas=1 deployment/scaleouttestappaz1 kubectl scale --replicas=1 deployment/scaleouttestappaz2 Karpenter が既存のノードプールを終了するのを待ち、終了したら再度スケールアウトします。この例では、ネットワークアドレス定義で利用可能な IP アドレスの数の制限まで Pod をスケールアウトできます。 kubectl scale --replicas=10 deployment/scaleouttestappaz1 kubectl scale --replicas=10 deployment/scaleouttestappaz2 クリーンアップ CloudFormation スタックを逆の順序で全て削除します。 kubectl delete -f sample-application/multitool-deployment-az1.yaml kubectl delete -f sample-application/multitool-deployment-az2.yaml sleep 120 # to ensure all the karpenter nodes are terminated kubectl delete -f config/nodepool.yaml kubectl delete -f config/cleartaints.yaml kubectl delete -f config/sa-role-rolebinding.yaml helm uninstall karpenter -n karpenter helm uninstall -n node-latency-for-k8s node-latency-for-k8s aws iam detach-role-policy --policy-arn $karpentermultuspolicyarn --role-name KarpenterNodeRole-${CLUSTER_NAME} karpentermultuspolicyarn=$(aws iam list-policies | jq -r '.Policies[] | select(.PolicyName=="karpenter-multus-policy") | .Arn') aws iam delete-policy --policy-arn $karpentermultuspolicyarn 結論 この投稿では、Karpenter を Multus CNI と組み合わせて使用し、Multus が使用する ENI のライフサイクルをどのように管理するかを示しました。Karpenter でプロビジョニングされたノードプールのワーカーには、Multus 対応のインターフェースがアタッチされます。また、Karpenter をオートスケーリングソリューションとして使用する利点も示しました。Karpenter は、Kubernetes クラスターでワークロードを実行する際に、効率とコストを次のように改善します： Kubernetes スケジューラーが未スケジュールとしてマークしたポッドを監視する。 Pod によって要求されたスケジューリング制約（リソースリクエスト、ノードセレクター、アフィニティ、トレランス、トポロジスプレッド制約）を評価する。 Pod の要件を満たすノードをプロビジョニングする。 ノードが不要になったときにノードを削除する。 Karpenter は、アプリケーションのスケーリング要件に対応するための柔軟なツールです。 Karpenter とベストプラクティスに関する詳細は、 AWS GitHub リンク を参照してください。 著者 Rolando Jr Hilvano Rolando Jr Hilvano is a Principal Solutions Architect in the Worldwide Telecom Business Unit at Amazon Web Services (AWS). He specializes in 5G space and works with telecom partners and customers in building and deploying Cloud Native Telco workloads on AWS. Ashutosh Tulsi Ashutosh Tulsi is a Principal Solutions Architect in the AWS Worldwide Telecom Business unit working with Communication Service Providers (CSPs) and Telco ISV Partners. His goal is to enable CSP’s achieve Operational and Cost efficiencies by providing solutions that assist in migrating the 4G / 5G Networks to the AWS Cloud. Young Jung Dr. Young Jung is a Principal Solutions Architect in the AWS Worldwide Telecom Business Unit. His primary focus and mission are to help telco Core/RAN partners and customers to design and build cloud-native NFV solutions on AWS environment. He also specializes in Outposts use cases of telco industry for telco’s edge service implementation powered by AWS services and technologies. Neb Miljanovic Neb Miljanovic is an AWS Telco Partner Solutions Architect supporting migration of Telecommunication Vendors into public cloud space. He has extensive experience in 4G/5G/IMS Core architecture and his mission is to apply that experience to migration of 4G/5G/IMS Network Functions to AWS using cloud-native principles. Sudhir Shet Sudhir Shet is a Principal Partner Solutions Architect in the AWS Global Telecom IBU team, specializes in IMS and 5G, working with various global telecom partners and CSPs to create cloud-native 5G/IMS NFV solutions on AWS. 翻訳はソリューションアーキテクトの陳誠が担当しました。

Heroku は、開発者が AWS 上でアプリケーションをデプロイ、運用、スケーリングできるようにする完全にマネージドされたプラットフォームサービス( PaaS )ソリューションです。2007 年に設立され、2010 年からは Salesforce の一部となっています。Heroku は、小規模スタートアップから大企業の大規模デプロイメントまで、数百万件のアプリケーションで選ばれているプラットフォームです。これらのアプリケーションをスムーズに運営するには、AWS が提供するビルディングブロックを使って、プラットフォームの基盤となるインフラストラクチャに継続的な投資が必要不可欠です。 このブログ記事では、Heroku が 2023 年に完了した、 アプリケーションメトリクスとアラート機能 のストレージバックエンドを自社管理の Apache Cassandra クラスターから Amazon DynamoDB に移行するインフラアップグレードについて説明します。 Heroku は、この移行を顧客への影響なしに完了することができました。Amazon DynamoDB への移行により、プラットフォームの信頼性が向上すると同時に、運用コストも削減されました。本記事では、システムアーキテクチャ、DynamoDB へ移行した理由、移行の実施方法、そして移行完了後の成果について詳しく説明します。 (本記事は 2024/05/09 に投稿された How Heroku reduced their operational overhead by migrating their 30 TB self-managed database from Amazon EC2 to Amazon DynamoDB を翻訳した記事です。) サービスとしてのメトリクス（ MetaaS ） Heroku のアプリケーションメトリクスは、内部のサービスである MetaaS（ Metrics as a Service ）によって提供されています。MetaaS は、Heroku で稼働しているアプリケーションから様々な観測値を収集します。例えば、特定の HTTP リクエストを処理するのにかかる時間などです。集計された生データに対し、アプリケーション単位、分単位の統計値(中央値、最大値、99 % 応答時間など)が計算されます。この時系列メトリクスデータは、 Heroku ダッシュボード に表示されたり、アラートやオートスケーリングの機能に活用されます。 MetaaS の中核は、高スケールでマルチテナントな時系列データ処理プラットフォームです。毎秒数十万件の観測値が最初に Heroku 上の Apache Kafka に取り込まれます。ストリーム処理ジョブのコレクションが Kafka からこれらの観測値を消費し、Heroku が各顧客アプリケーションについて追跡しているさまざまなメトリクスを計算します。そして、最終的には長期保存とクエリのためデータベース（元々は Amazon EC2 上の Apache Cassandra ）に書き込みます。MetaaS の時系列データベースには数 TB ものデータが保存されており、ピーク時には毎秒数万件の新しいデータポイントが作成され、最大秒間に数千件のリードクエリが行われます。 下記の図は従来のアーキテクチャを示しています。 DynamoDB を選択した理由 Cassandra によって構成された MetaaS は、長年 Heroku に良いサービスを提供してきました。しかし 2022 年末頃、Heroku のエンジニアチームはバックエンドストレージを構成する他の方法を探り始めました。MetaaS が使用している Kafka クラスターは、Kafka 運用の経験が豊富なチームによって提供されていますが、Cassandra クラスターは MetaaS 固有のものでした。 Heroku は、データベースインフラを監視するエンジニアチームは非常に小さいため、Kafka クラスターと同様に専門家チームが運用・保守するマネージドサービスに移行することが重要だと考えていました。そこで、大量のデータを高スケールで分散システムに格納しつつ、あらゆるスケールでの高速な書き込みパフォーマンスを維持できる AWS のマネージドデータベースを探しました。結果的に、Heroku の他のチームがデータストレージおよび処理に使用している DynamoDB が、一貫性とパフォーマンスの要件に合っていたため、MetaaS のワークロードにも適していると判断されました。 慎重なマイグレーション 計画を立て、コードを書き換えた後、既存の顧客に影響を与えずに、高スケールで高スループットの分散システムのバックエンドストレージを入れ替えるという作業が残されていました。既存 MetaaS アーキテクチャは Heroku の移行に有利でした。Kafka から時系列データを Cassandra に書き込むためのストリーム処理ジョブがすでに用意されていたので、同じデータを DynamoDB に書き込むための並行したジョブを立ち上げるのが簡単でした。これが移行の最初のステップで、システムの他の部分には何の影響もありませんでした。 Heroku の顧客にとって運用メトリクスは非常に重要です。DynamoDB へのデータ書き込みが正常に行われていることを確認するため、チームは従来の単体テストや統合テストに加えて、既存単体テスト及び統合テストを規範としたテストを実施しました。まずは Cassandra と DynamoDB の両方からデータを読み出すクエリを少量実行し、データの整合性を確認しました。2 つのコードパスで結果が異なるクエリはすべてログに記録されました。プリプロダクションでのテスト後、徐々にクエリの割合を増やし、最終的には 100 % のクエリが両方のコードパスを経由するようになりました。この変更によって、お客様は Cassandra のコードパスでクエリ結果をもらい、あまり影響がありませんでしたが、従来の単体テストや統合テストでは見つからなかった微妙なエッジケースを特定し修正することができました。 スムーズな移行 DynamoDB が Cassandra と同じ結果を一貫して返していることを検証実験で確認できたため、本番稼働の準備が整いました。MetaaS はデータを 30 日以内しか保持しておらず、それ以降は削除されます( DynamoDB では便利な TTL 機能 を使用)。つまり、Cassandra から過去のデータを移行する必要がありませんでした。両方のデータベースに同じデータが書き込まれていることを確認した後は、2 つのデータベースが同期されるのを待つだけでよかったのです。 テスト環境から始め、徐々に DynamoDB からのみ読み出すクエリに切り替えていきました。見落とされていた可能性のある問題のある動作に関する顧客からの報告がないかを慎重に確認しながら進めました。そのような報告はなく、2023 年 5 月以降、MetaaS へのすべてのクエリが DynamoDB から提供されるようになりました。Heroku は、変更を戻す必要がないことを確認するため、数週間待ちました。 以下の図は、更新されたアーキテクチャを示しています。 結果 1 年以上の運用経験を経て、Heroku はマネージドデータベースサービスの採用を正しい判断であったと確信しました。DynamoDB は信頼性と拡張性に優れています。Heroku は、データベースサーバーのパッチ適用とチューニングに必要な運用負荷を 90% 削減し、当初の目標を達成できました。また、DynamoDB はこれまでの Amazon EC2 上の自社運用 Cassandra クラスターよりも高速かつ低コストであることがわかりました。具体的には、クエリの最大レイテンシーを 75% 削減し、コストを約 50% 削減できました。 例えば、以下のグラフに示されているように、18 時までは Cassandra をクエリしていたため、p99 レイテンシーにかなりの変動が見られましたが、18 時以降は DynamoDB をクエリしているため、そのような変動は見られなくなりました。 教訓 Heroku のサービスは VPC エンドポイント を通じて DynamoDB にアクセスしています。 AWS Identity and Access Management ( IAM )ポリシーを設定し、DynamoDB へのトラフィックが VPC エンドポイントを経由するよう要求することで、VPC 内のアプリケーションがインターネットに露出することなく DynamoDB にアクセスできるようになっています。 Heroku は、Heroku ダッシュボードで顧客がメトリクスを見る頻度によってトラフィックが週の中で変動するため、 DynamoDB Auto Scaling を使って MetaaS テーブルのプロビジョンド読み取りキャパシティを管理しています。一方、書き込みパターンはより予測可能なため、自動スケーリングの最大利用率目標の 90 % を上回るようにテーブルの書き込みキャパシティを手動で設定しています。 ピークがある場合は自動スケーリングが費用削減に効果的ですが、予測可能なワークロードの場合は必要なキャパシティを正確に設定することで、コストを節約できます。 DynamoDB への書き込みは常に最低 1 つの書き込みキャパシティユニット( WCU )を消費しますが、書き込むレコードのサイズに応じて、それ以上の WCU を消費する可能性があります( 1 KB 当たり 1 WCU、最大 400 KB まで)。MetaaS が保存するレコードのほとんどは非常に小さいものの、わずかに 400 KB 制限を超えるものがあることがわかりました。Heroku は、これらの大きなレコードを DynamoDB に書き込む前に gzip で圧縮することで、この問題を解決（また、コストも節約）できました。MetaaS データはそれほど頻繁には照会されないため、圧縮と解凍の CPU 時間コストは、WCU の削減と柔軟なスキーマ変更の利便性に比べて無視できます。 最後に、テスト初期の段階で、DynamoDB への書き込みに予期せぬパフォーマンスボトルネックが発生していました。原因は、DynamoDB SDK で使用されている HTTP クライアントの設定不足でした。高スケールのワークロードの場合、デフォルト設定ではなく、チューニングを行うことが重要です。Heroku は、DynamoDB への同時接続数を増やし、再利用のために維持するアイドル接続数を調整し、デフォルトよりも積極的なタイムアウトとリトライ設定を行うことで、大幅な改善を達成しました。 まとめ このブログ記事では、Heroku がセルフマネージドの Cassandra クラスターから DynamoDB へのインフラストラクチャ移行させた方法について説明しました。Heroku はこの移行を顧客への影響なしに完了し、プラットフォームの信頼性を向上させると同時にコストを削減できました。Heroku は、 EC2 上のセルフマネージド Cassandra から DynamoDB に移行したことで、クラウドインフラストラクチャコストを最大 50 % 削減しました。また、パフォーマンスの改善は、DynamoDB のクエリパフォーマンスがはるかに予測可能になったためです。Cassandra では、ピーク時にレイテンシースパイクが最大約 80 ms に達していましたが、DynamoDB では一貫して 20 ms 未満でクエリが実行されるようになり、顧客へのメトリクス提供遅延が大幅に改善されました。 DynamoDB を使ったハイスケールなワークロードの運用について、他にもヒントや質問はありますか? コメントでお知らせください。DynamoDB の使用を始めるには、 開発者ガイド と AWS DynamoDB コンソール をご覧ください。 このブログ記事は、Heroku と AWS の共同作成で、 Herokuブログ ともにクロスポストされています。 元作者情報 Rielah De JesusはAmazon Web Service のプリンシパルソリューションアーキテクトであり、ワシントンDC、メリーランド、バージニアの多くのエンタープライズ級のお客様のクラウド移行を支援し、成功させてきました。現在のロールではカスタマーアドボケイトおよびテクニカルアドバイザーとして、Salesforceを始めとする複数の組織のAWSプラットフォームでの成功の支援をしています。また、Women in ITの熱心な支持者でもあり、テクノロジーとデータを創造的に活用して日常的な課題を解決する方法を見つけることに情熱を注いでいます。 David Murrayは、Salesforceのソフトウェアアーキテクトで、現在Herokulのバックエンド全般を担当しています。過去には、ネットワーク、データベース、セキュリティ、テクニカルライティングなどの分野を経験してきたほか、 愛猫Sammyについてaws reinventで講演 を行いました。コンピューターのことを考えていないときは、ボートこぎ、自転車乗り、ボードゲームなどを楽しんでいます。

この記事は、“ Enhanced interoperability with SMART on FHIR support in Amazon HealthLake ” を翻訳したものです。 はじめに 2021 年 7 月の開始以来、 Amazon HealthLake は AWS Identity and Access Management (IAM) を通じて安全なアクセスを提供してきました。AWS は最近、 SMART on FHIR 1.0.0 のサポートを含む新しい FHIR API 機能を Amazon HealthLake で発表しました 。SMART on FHIR のサポートにより、HealthLake は FHIR スコープとローンチコンテキストを使用した SMART フレームワークに基づく認可を提供するようになりました。この記事では、Okta を ID プロバイダー (IdP) として使用して、HealthLake で SMART on FHIR を実装する方法について説明します。 患者と医療従事者に健康データへの安全なアクセスを提供するための革新的な取り組みを行う開発者は、さまざまな形式と標準のために複数の課題に直面しています。 ONC Cures Act Final Rule は、医療業界に対し、開発者が医療従事者のワークフローをサポートする新しいアプリケーションを作成し、患者が自身の健康記録にアクセスできるようにする標準の採用を促しています。その標準の 1 つである SMART on FHIR は、開発者が 1 度アプリケーションを作成すれば、医療機関がさまざまな開発者のアプリケーションをテストし、適切なものを見つけられるようにするアーキテクチャ上の解決策を提案しています。「SMART」は Substitutable Medical Applications and Reusable Technologies を意味し、「on FHIR」は Fast Healthcare Interoperability Resources (FHIR) 標準の利用を示しています。 SMART フレームワークの概要 SMART アプリケーションを展開するためのフレームワークは、外部アプリケーションを電子健康記録 (EHR) システムに接続する上で重要な役割を果たします。このフレームワークにより、EHR システムの内外でアプリケーションを起動できるようになります。このフレームワークは、医師、患者、その他の個人やシステムが FHIR API を使用して設計されたさまざまなアプリケーションをサポートしています。ユーザーは、アプリケーションに自分の健康データへのアクセス権を付与できるため、アプリケーションがエンドユーザーデバイスやサーバー上で実行されているかどうかに関係なく、さまざまなアーキテクチャ構成で安全で信頼できるプロトコルが保証されます。 SMART on FHIR 1.0.0 には、以下の 4 つのユースケースが含まれています。 独立して起動できるスタンドアロンの患者向けアプリケーション。 EHR ポータルから起動できる患者向けアプリケーション。 独立して起動できるスタンドアロンの医療従事者向けアプリケーション。 EHR ポータルから起動できる医療従事者向けアプリケーション。 SMART 認証と FHIR アクセス 次の図は、FHIR リソースサーバーとして HealthLake を利用する SMART on FHIR アプリケーションのスタンドアロンの起動とアクセス許可のステップを示しています。これらのステップとワークフローを詳しく見ていきましょう。 ステップ 1: アプリケーションが認証を要求します SMART on FHIR クライアントアプリケーションは、FHIR リソースへのアクセスを認可するために、起動時に ID 情報なしで HTTP GET リクエストを FHIR サーバーの SMART 構成メタデータ [base]/.well-known/smart-configuration の検出 URL に送信します。この構成メタデータには、OAuth の authorization_endpoint と token_endpoint の URL が含まれています。その後、アプリケーションは、FHIR サーバーが「認可」に使用するエンドポイント URL のクエリコンポーネントに以下のパラメータを追加して、認可リクエストを作成します。 response_type: これは固定値です – code client_id: クライアントの識別子です redirect_uri: 登録済みクライアントが持つリダイレクト URI のいずれかと一致する必要があります launch: EHR 起動フローを使用する場合、EHR から受け取った起動値と一致する必要があります。これはスタンドアロンの起動ワークフローでは必須ではないオプションのパラメータです scope: アプリが必要とするアクセスを記述する必要があり、臨床、コンテキスト、ID データのスコープを含む必要があります SMART アプリケーションの起動フレームワーク IG で説明されているように、データのスコープは次のように形成されます。 最も一般的に使用されるスコープの例は次のとおりです。 patient/*.read – 現在の患者に関連するリソースを読み取る権限 user/*.* – 現在のユーザーがアクセスできるすべてのリソースを読み書きする権限 他に一般的に使用される医療以外のスコープは以下の通りです。 launch – EHR から起動されたアプリのコンテキストを取得する権限 launch/patient – EHR 外からアプリが起動され、患者のコンテキストが必要な場合、認証サーバーから選択する患者のリストが提供される offline_access – アクセストークンの有効期限が切れた後、オフラインの場合でも、期限切れのアクセストークンを更新するためのリフレッシュトークンを要求する online_access – ユーザーがオンラインの場合に、期限切れのアクセストークンを更新するためのリフレッシュトークンを要求する state : リクエストとコールバック間の状態を維持するために使用される不透明な値 aud : これは「対象者」を指し、アプリがデータを取得する FHIR リソースサーバーの URL です。 ステップ 2: 認可リクエストを評価する 認可プロセスは認可サーバーに依存し、サーバーはユーザーに許可を求めることができます。その後、サーバーはクライアント ID、設定されたポリシー、時にはユーザーの入力などの要因に基づいて、アクセスを許可するか拒否するかを決定します。アプリケーションは、認可サーバーから認可コードが送り返された場合、またはアクセスが拒否された場合はエラーレスポンスが送り返された場合に、この決定を受け取ります。 ステップ 3: 認可コードをアクセストークンと交換する アプリケーションが認証コードを取得すると、そのコードをアクセストークンと交換する処理に進みます。この交換は、EHR 認証サーバーのトークン URL エンドポイントに対して HTTP POST リクエストを行うことで実現します。その際、コンテンツタイプとして application/x-www-form-urlencoded. を使用します。 ステップ 4: FHIR API を通じた医療データへのアクセス アプリケーションが有効なアクセストークンを取得すると、FHIR サーバーのエンドポイントに FHIR API 呼び出しを行うことで、データを取得する機能を持ちます。API リクエストには、アクセストークンを “Bearer” トークンとして次の形式で含む認証ヘッダーが含まれています: Authorization: Bearer {{access_token}}. ここで、プレースホルダー {{access_token}} は、前のステップで取得した実際のトークン値に置き換えられます。 ステップ 5: リフレッシュトークン アプリケーションはリフレッシュトークンを使用して新しいトークンを取得します。リフレッシュトークンは、アクセストークンの有効期間よりも長いセッションを許可するために発行されます。 Amazon HealthLake 上の SMART on FHIR の実装例 SMART on FHIR を定義する仕様と標準について説明したので、次は Okta を ID プロバイダー (IdP) として使用して HealthLake で実装する方法を示します。HealthLake では他の OAuth 2.0 IdP を使用することもできることに注意してください。 Amazon HealthLake での SMART アクセスの設定 ステップ 1: サードパーティの認可サーバーをセットアップし、’well-known’ 構成を取得する 認可サーバーは若干の違いがあるかもしれませんが、認可サーバーから ‘well-known’ 構成からベース URI と十分なメタデータを取得することが重要です。次の Okta のスクリーンショットは、Okta IDP のメタデータ URI を含むデフォルトの認可サーバー構成を示しています。 ID プロバイダーからのメタデータ情報には、認可エンドポイント、トークンエンドポイント、サポートされる付与タイプとスコープなどの詳細が含まれています。この情報は、次のセクションで強調されているように、SMART 機能を持つ HealthLake データストアを作成する際に使用されます。 ステップ 2: HealthLake と Auth Server 間の通信を確立する SMART on FHIR サポートを備えた Amazon HealthLake データストアを作成する際は、特定のクレームを返す AWS Lambda 関数の ARN と、FHIR API リクエストを実行するための許可を持つ IAM サービスロールを指定する必要があります。Lambda 関数の作成の詳細については、 Amazon HealthLake 開発者ガイド を参照してください。この Lambda 関数は、FHIR API リクエストに応答して、Amazon HealthLake サービスに必要な要素を返します。 次の図は、SMART on FHIR アプリケーション、IDP、Amazon HealthLake、Lambda 関数間の通信を示しています。 ステップ 3: HealthLake データストアの作成時に IdP 構成を保存する HealthLake データストアの所有者が決定します FHIR 相互作用に関連付けられた IAM ロール 復号化とトークン検証方法 (ローカル検証または ID プロバイダーとのトークン検査) と ID プロバイダーの構成。検査 Lambda 関数を作成した後、ユーザーは IdentityProviderConfiguration を格納する機能が強化された create data store API を呼び出すことができます。このパラメータは、認可戦略、検出 API メタデータを構成し、細かい認可を有効にします。この構成は新しいデータストアを作成する際にのみ利用可能で、既存のデータストアでは有効にできないことに注意してください。さらに、この構成はコマンドラインインターフェイス (CLI) とソフトウェア開発キット (SDK) からのみアクセス可能で、コンソールからはアクセスできません。 この新しい CreateFHIRDatastoreRequest の構造では、新しいデータストアを作成する際に IdentityProviderConfiguration がオプションのパラメータとなっています。 この構成では、次のフィールドを受け入れます。 AuthorizationStrategy : SMART 認証の場合は SMART_on_FHIR_V1 、非 SMART 認証の場合は AWSAuth を指定してください。値が SMART_on_FHIR_V1 の場合、以下のすべてのフィールドが必須になります。 FineGrainedAuthorizationEnabled : 細かい権限管理を HealthLake で行いたい場合は true 、そうでない場合は false を選択してください。 Metadata – 検出 API リクエストコールを受信したときに返される認証サーバーのメタデータを格納します。 SmartConfigurationMetadata は、 FHIR 仕様 に示されているものと同様の JSON オブジェクトで、authorization_endpoint と token_endpoint が含まれています。 IDPLambdaARN : トークン検証を行うカスタム Lambda の ARN です。 これらの設定を完了すると、HealthLake は SMART アプリケーションから送信された”Bearer” トークンをデコードできるようになり、それらのリクエストに対して認証と承認を実行できるようになります。 Amazon HealthLake の SMART on FHIR サポートの主要機能とメリット 適用性と柔軟性: ヘルスケアプロバイダーは、シームレスにサードパーティのアプリケーションを既存のシステムに統合できるようになります。これにより、臨床ワークフローのカスタマイズと拡張が可能になり、効率性と使いやすさが向上します。 患者中心のケア: HealthLake の SMART on FHIR サポートにより、患者は自身の健康データに安全にアクセスし、患者向けアプリケーションと対話できるようになります。これにより、患者の積極的な関与、エンパワーメント、健康状態の自己管理が促進されます。 相互運用性の向上: FHIR 標準データ形式を活用することで、SMART on FHIR は異なるシステム間で構造化された健康データを交換できるようになり、互換性と一貫性が確保されます。これにより、効率的なケアの調整、研究、集団健康管理が促進されます。 開発者に優しい環境: SMART オープンソースプラットフォームは、イノベーションを促進し、新しいヘルスケアソリューションの創出を奨励します。 結論 SMART on FHIR は、医療の相互運用性に変革をもたらすアプローチで、医療従事者、開発者、患者を同様に力づけます。アプリケーションをシームレスに統合し、ケアの調整を強化し、患者の関与を促進する機能により、SMART on FHIR は医療分野のデジタル変革を可能にする重要な要素となります。Amazon HealthLake がこの標準をサポートすることで、相互運用性、イノベーション、そして最終的には患者の良好なアウトカムを実現します。Amazon HealthLake を使い始め、健康データを数分で安全に保存、変換、トランザクション、分析する方法の詳細を知るには、以下の過去のブログをご覧ください。 Amazon HealthLake に関する過去のブログへのリンク Amazon HealthLake を使用して患者データの洞察を解き放つ 新しい Amazon HealthLake の機能により、次世代のイメージングソリューションと精密健康分析が可能に Amazon HealthLake の新しい FHIR API 機能により、お客様はデータ交換を加速し、ONC と CMS の相互運用性とパティエントアクセスルールを満たすことができます <!-- '"` --> TAGS: Amazon HealthLake , AWS Lamda , comprehend medical Yogesh Dhimate Yogesh DhimateはAWSのシニアパートナーソリューションアーキテクトです。Yogesh は、グローバルなヘルスケア分野のISV（独立系ソフトウェアベンダー）がAWS上で相互運用性ソリューションを構築することをサポートしています。AWSに入社する前は、MuleSoft（現Salesforce）でヘルスケア業界向けソリューションのテクニカルリーダーおよびプロダクトマネージャーとして働いていました。 Bakha Nurzhanov Bakha NurzhanovはAWSのインターオペラビリティ・ソリューションアーキテクトであり、ヘルスケアの相互運用性とイノベーションの技術リーダーです。Bakha は、グローバルなヘルスケア顧客をサポートし、グローバル技術チームにおけるヘルスケアの相互運用性に関する専門知識を深め、ヘルスケアイノベーションの開発をリードしています。AWSに入社する前は、様々なヘルスケアプロバイダー組織において、20年以上にわたりインテグレーションアーキテクトおよび開発者として働いていました。 Mirza Baig Mirza Baig はヘルスAI分野のプリンシパルソリューションアーキテクトで、主にヘルスAIソリューションの採用促進に注力しています。アマゾンに入社する前は、エンビジョン・ヘルスケア、シスコ、米国大統領府などの大規模組織で、ソフトウェア開発、データ基盤、サイバーセキュリティ、ネットワークエンジニアリングにおける技術職およびリーダーシップの役割を担っていました。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

このブログは、 How to expansively train Robot Learning by Customers on AWS using functions generated by Large Language Models を翻訳したのものです。 ロボット工学業界では、 強化学習 (RL) が、伝統的な経路計画アルゴリズムでは処理できない複雑な問題、特に複雑な操作を伴う問題に広く利用されています。RL における報酬関数は、目的を設定しエージェントの学習プロセスに指示を与える重要な要素です。効果的な報酬関数を作成することは難しいですが RL エージェントが適切に動作するためには不可欠です。 Eureka は、NVIDIA の研究者による大規模言語モデル (LLM) を使用して、報酬関数を手作業で設計するのではなく、洗練された報酬関数を生成する素晴らしいプロジェクトです。強化学習の業界では、報酬関数の作成は試行錯誤のプロセスのままです。ロボット工学者は報酬関数を自動的に生成および改良する方法を求めています。 このテーマの画期的な成果である Eureka は、難しい問題を解決するための一種の自動化を提供します。 Eureka の研究論文 によると、LLM によって生成された報酬関数は、全体で 50 % のパフォーマンス向上があり、タスクの 80 % 以上で人手による報酬関数設計を上回ります。 このブログ記事では、Nvidia の Eureka を Amazon Web Services (AWS) 上で実行し、Amazon Bedrock for LLMs を使用する方法を説明します。ロボット学習のプロセスをオンプレミスのトレーニングインスタンスから AWS に移行する際、エンジニアが対処する必要のある課題がいくつかあります。 シミュレーション/トレーニングプロセスを複数のノードに分散してスケーリングし、トレーニングプロセスを加速させ、コストを節約します。 クラウド上でロボットのシミュレーション/トレーニングプロセスを可視化し、エンジニアが参加できるようにすることで、タスク効率を向上させます。 Amazon Bedrock の LLM を使用して、報酬関数を生成します。 ソリューションの概要 このブログ記事では、ロボット業界の顧客が上記の課題を解決するために AWS が提案するソリューションの 1 つについて説明します。このソリューションでは、以下のツールを使用します。 自動運転データフレームワーク (Autonomous Driving Data Framework: ADDF) は、AWS の自動車チームが再利用可能でモジュール化された汎用コード資産を提供することを目的としたオープンソースプロジェクトです。ADDF はデータ処理、シグナル抽出、シーン検出、シミュレーション、データ可視化用のモジュールを提供しています。この記事では、このプロジェクトをロボット業界でどのように活用できるかを示します。 Amazon Elastic Kubernetes Service (Amazon EKS) は、コンテナ のスケジューリング、アプリケーション可用性の管理、クラスターデータの保管を行う Kubernetes コントロールプレーンノードの可用性とスケーラビリティを AWS が管理する、マネージド型の Kubernetes サービスです。この記事では、EKS 上でロボットの学習とシミュレーションを行います。 NICE DCV は、お客様にリモートデスクトップとアプリケーションストリーミングを安全に提供する高性能のリモートディスプレイプロトコルです。この記事では、EKS 上で行われるロボットシミュレーションと学習プロセスを DCV でストリーミングする方法を示します。 このソリューションは次のように設計されます: 図 1: ソリューションの高レベル設計 この画像では、このデザインのアーキテクチャを示しています。まず、コードとトレーニングアーティファクトを Amazon S3 バケットにデプロイします。Amazon DataSync が、コードとアーティファクトを Amazon EKS クラスター内のポッドにマウントされる Amazon FSx と同期します。 Amazon EKS 側では、トレーニング/シミュレーションのために イベント駆動型アーキテクチャ を採用しています。シミュレーション/トレーニングのワークロードは、ワーカーポッドで実行されます。これらのワーカーポッドはステートレスです。タスクコントローラーポッドは、タスクに基づいてトレーニング/シミュレーションのワークロード定義を生成する責任があります。ワーカーにワークロードをスケジュールするために、 Amazon Simple Queue Service (Amazon SQS) を使用しています。各タスクコントローラーは、1 つのトレーニングジョブのシミュレーションとトレーニングを制御します。 タスクコントローラーは、選択された LLM からさまざまな報酬関数をサンプリングするサービスを提供する Amazon Bedrock とも通信します。一方、ユーザーは DCV モジュールを介してシミュレーションを視覚化および操作できます。ADDF では、インフラストラクチャを簡単に設定できます。ADDF は、Amazon EKS、DCV コンポーネント、この特別なプロジェクト向けの他の AWS リソースなど、必要なモジュールをデプロイします。 ローカル開発環境での前提条件は以下の通りです: Python 3.8 以上のバージョン git CLI AWS 認証情報 AWS CLI aws-cdk CLI バージョン 2.20.0 以上 kubectl CLI バージョン 1.29 以上 Amazon EKS クラスターのセットアップ この項では、インフラストラクチャのセットアップに焦点を当てます。以前別のプロジェクトで ADDF を使用したことがある場合は、該当する手順を飛ばしてください。 ステップ 1: ADDF リポジトリをローカルディレクトリに clone します。 現在、複数のリリースがあります。この記事執筆時の最新バージョンは release/3.5.0 を使用することをおすすめします。 git clone --origin upstream --branch release/3.5.0 https://github.com/awslabs/autonomous-driving-data-framework.git ステップ 2: Python の仮想環境を作成し、依存関係をインストールする cd autonomous-driving-data-framework python3 -m venv .venv &amp;&amp; source .venv/bin/activate pip3 install -r requirements.txt 今度は、アカウントに対する有効な AWS 認証情報があることを確認してください。アカウントの bootstrapping に必要になります。以下のコマンドで &lt;REGION&gt; と &lt;ACCOUNT_ID&gt; と &lt;ROLE_NAME&gt; を置き換えてください: export AWS_DEFAULT_REGION = cdk bootstrap aws:/// Step 3: Deploy Amazon EKS Cluster and DCV modules. このステップでは、セットアップに必要なモジュールをデプロイします。以下のものがデプロイされます： Amazon FSx for Lustre : これは Amazon EKS 上の Pod にマウントされます。また、S3 バケットから Amazon FSx へのデータ同期を設定します。これとデータ同期をデプロイするには、次のモジュール定義が必要です。Amazon FSx の定義は manifests/robotic-training-on-eks/storage.yaml に定義されています。 eureka モジュールにも、K8S リソースとして Amazon FSx ストレージクラスがデプロイされます。依存関係のあるモジュールでは、Amazon FSx が作成されます。また、追加の Amazon FSx K8S リソースをデプロイし、Amazon FSx を Pod にマウントできるようにします。 Amazon ECR : これはロボット学習/シミュレーション画像を格納するために使用されます。 Amazon S3 バケット: このバケットはデータストアとして使用されます。学習データ、学習出力、コードをこのバケットに保存します。 Amazon EKS: これは、学習/シミュレーション Pod をスケジューリングするためのフレームワークとなります。この例では、少なくとも 2 つの g5.2xlarge インスタンスをデプロイします。 NICE DCV イメージと Kubernetes (K8S) リソース: DCV に関連する 3 つのモジュールがあります。1 つは DCV サーバーイメージを格納する ECR を作成し、もう 1 つは DCV イメージを作成し、最後のモジュールは K8S リソース (DaemonSet、ClusterRole、ClusterBinding など) を作成します。これらのモジュールはそのままの状態で構いません。設定の更新は必要ありません。 dcv-eks モジュールの README を確認してください。DCV サーバー用のシークレットを設定する必要があります。 次のコマンドを実行して、ADDF モジュール全てをデプロイできます: seedfarmer apply manifests/robotic-training-on-eks/deployment.yaml 次のような出力が正常にデプロイされた場合に表示されます: 図 2: デプロイされる ADDF モジュール ステップ 4: Kubectl とクレデンシャルをセットアップ。 ステップ 3 で Amazon EKS クラスターをデプロイしました。この ブログ記事の範囲では、 kubectl コマンドを使用して Amazon EKS でアプリケーションを実行する必要があります。 このリンク に従い、バージョン 2.29 の kubectl クライアントをインストールしてください。 モジュールがデプロイ済みであれば、すべてのリソースが Amazon CloudFormation のスタックとして存在します。AWS コンソールから Amazon CloudFormation サービスに移動し、 addf-robotic-training-on-eks-core-eks という名前のスタックを探して選択し、出力を参照すると、次の図のように clusterConfigCommand が表示されます。 Figure 3: Amazon EKS Cloud Formation Stack Output 次に、 clusterConfigCommand の値をターミナルにコピーして実行してください。資格情報は適切に更新されます。次のコマンドを実行して K8s クライアントを検証できます: kubectl get svc 出力は次のようになります。 NAME &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLUSTER-IP &nbsp;&nbsp; EXTERNAL-IP &nbsp;&nbsp; PORT(S)&nbsp;&nbsp; AGE kubernetes &nbsp;&nbsp; ClusterIP &nbsp;&nbsp; 172.20.0.1 &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 443/TCP &nbsp;&nbsp; 177m ステップ 5: GPU オペレータをインストールする。 ステップ 3 で GPU 対応ノードを持つ Amazon EKS クラスターを設定したはずです。ADDF EKS モジュールは、GPU ドライバーが事前にインストールされたインスタンスを起動します。ただし、GPU リソースを必要とする K8s ワークフローをスケジュールするには、クラスターに GPU オペレータプラグイン をインストールする必要があります。GPU オペレータは、K8S 内のすべての NVIDIA GPU リソースを自動的に処理します。この手順で、GPU 関連のワークロードに NVIDIA GPU オペレータをインストールします。ステップ 5.1 と 5.3 はオプションです。これらの追加機能を利用したい場合は、 このリンク の下にある必要なファイルがあります。 (オプション) DCGM メトリクス パブリッシャー をインストールします。 これは GPU の利用状況など GPU 関連のメトリクスを公開するための、GPU オペレーターのオプションのステップです。 kubectl create namespace gpu-operator curl https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/main/etc/dcp-metrics-included.csv &gt; dcgm-metrics.csv kubectl create configmap metrics-config -n gpu-operator --from-file = dcgm-metrics.csv ステップ 5.2 (必須) GPU オペレータをインストールします。 ステップ 5.1 をスキップした場合、次のコマンドでは DCGM 関連のフラグ (次のコマンドの太字部分) を設定する必要はありません。 # run command in bash bash -c "helm install --wait --generate-name \ -n gpu-operator \ nvidia/gpu-operator \ --set driver.enabled = false \ --set toolkit.version = v1.14.4-ubi8 \ --set dcgmExporter.config.name = metrics-config \ --set dcgmExporter.env[0].name = DCGM_EXPORTER_COLLECTORS \ --set dcgmExporter.env[0].value =/etc/dcgm-exporter/dcgm-metrics.csv" # Validate installation by checking out whether all the pods in namespace gpu-operator are Running or Completed kubectl get pods -o wide -n gpu-operator GPU ドライバのインストールは ADDF EKS モジュールによってデプロイされた K8S ノードグループの AMI に既にインストール済みのため、GPU オペレータでは無効化されていることに注意してください。 今のところ、稼働可能な Amazon EKS クラスターが準備できています。 ロボット訓練とシミュレーション Isaac Gym デモンストレーション シミュレーション環境のセットアップ ADDF リポジトリのさまざまなモジュールと GPU Operator のデプロイが成功したら、シミュレーション/トレーニングのワークロードのデプロイを開始できます。 このブログ記事では、Eureka コントローラーポッドとトレーニングポッドをデプロイします。すべてのアプリケーションポッドは kubectl を使って手動でデプロイされます。各トレーニングタスクに対して、1 つのコントローラーポッドがあります。このブログの範囲では、shadow-hand タスクを実演します。異なるユースケースでテストしたい場合は、別のコントローラーポッドをデプロイできます。トレーニングポッドは K8s のデプロイメントとしてスピンアップします。トレーニングポッドの数は、各ノードで使用可能な GPU 数などのリソース制限によって制限されます。 上記のセクションに記載した方法でモジュールをデプロイすると、eureka モジュールが必要なすべての出力を保存します。具体的には、次の 3 つの項目が出力されます。 1. IamRoleArn: これはユーザーがクラウド上でシミュレーション/学習を実行するために作成された役割です。以下の権限が含まれています: a. Amazon FSx の読み取り/書き込み b. Amazon S3 バケットの読み取り/書き込み c. Amazon SQS の読み書き d. Amazon Bedrock の権限。 e. Amazon EKS クラスターのサービスアカウントがこのロールを引き受けるための信頼関係 2. ApplicationImageUri: このモジュールでは、基本ライブラリを含む ECR イメージを公開します。この実演では、このブログ記事内のすべての使用に対して 1 つの単一のイメージを再利用します。 3. SqsUrl: このモジュールは、Amazon SQS メッセージキューも作成します。コントローラーがエンキューし、ワーカーはシミュレーション/トレーニングの目的でデキューします。 ステップ 1: アーティファクトを S3 にアップロードする 。このステップでは、前に作成した S3 バケットに次のファイルをアップロードします。Amazon Datasync を利用しているので、ファイルをアップロードした後、データは自動的に Amazon S3 から Amazon FSx に同期されます。Amazon FSx をポッドにマウントすれば、すべてのポッドが共通の外部ドライブを共有できます。 Eureka: これは元の Eureka から フォークされたライブラリ です。複数のノードにシミュレーションをデプロイしてスケーラビリティを持たせることを目的としています。 IssacGym: この リンク から IssacGym Preview 4 にアクセスしてください。IssacGym をダウンロードするリンクが表示されます。次のコマンドで &lt;LINK_TO_DOWNLOAD_ISSACGYM&gt; をダウンロード用の正しいリンクに置き換えてください。 Fbx Fix Patch: これは FBX モジュールのエラーを修正するホットパッチです。Adobe は公式に Fbx Python をサポートしていないため、Fbx を実行するにはこのパッチを当てる必要があります。 BUCKET は ADDF モジュールで作成したデータバケットです。 mkdir robotic_data &amp;&amp; cd robotic_data # Get Eureka for distributed simulation git clone https://github.com/sauronalexander/Eureka.git # Get IssacGym wget tar -xvf IssacGym_Preview_4_Package.tar.gz rm IssacGym_Preview_4_Package.tar.gz # Get Fbx fix patch git clone https://github.com/Shiiho11/FBX-Python-SDK-for-Python3.x.git mv FBX-Python-SDK-for-Python3.x/2020.0.1_3.8.3_x64/FbxCommon.py ./ mv FBX-Python-SDK-for-Python3.x/2020.0.1_3.8.3_x64 ./fbx rm -rf FBX-Python-SDK-for-Python3.x # Upload files to s3 aws s3 sync ./* s3:// --recursive これからは、ローカルの Python スクリプトを編集し、コードを S3 と同期できます。コード成果物はすぐにすべての Pod から参照可能になります。もう 1 つの手法は、コードをイメージにビルドインすることです。この記事の単純化のため、コード変更の度にイメージのリビルドは行いません。 ステップ 2: Python Anaconda 環境をセットアップします。 このステップでは、必要な Python ライブラリをインストールします。IssacGym などの依存関係パッケージのインストールには、Nvidia ドライバが準備されている必要があります。このステップでは、環境をセットアップするために、各ノードに 1 つの Pod をデプロイします。各 Pod では、ホストノード内のディレクトリを使用するローカルマウントを確立します。この Pod は、Nvidia GPU ドライバをチェックアウトし、Anaconda 環境を共有ディレクトリにあらかじめインストールします。このセットアップが完了すると、ワーカー Pod とコントローラー Pod は、シミュレーション/トレーニングのワークロードを実行するために、この Anaconda 環境を再利用します。これにより、環境のセットアップ時間が大幅に節約されます。 anaconda_setup.yaml 内の画像 URI とロール ARN を、前のステップで作成した適切な画像 URI と IAM ロール (以下の太字の部分を参照) に置き換えてください。 apiVersion: v1 kind: ServiceAccount metadata: name: aws-s3-access annotations: eks.amazonaws.com/role-arn: automountServiceAccountToken: true --- apiVersion: apps/v1 kind: DaemonSet metadata: name: anaconda-daemonset labels: app: anaconda-setup spec: selector: matchLabels: app: anaconda-setup template: metadata: labels: app: anaconda-setup spec: terminationGracePeriodSeconds: 30 # Set the termination grace period serviceAccountName: aws-s3-access automountServiceAccountToken: true containers: - name: anaconda-setup-container image: resources: limits: nvidia.com/gpu: 1 # requesting 3 GPU, 1 shared gpu is 3GB in g5 … # Wait for around 10 minutes until the setup is complete. You can verify the setup to be completed by check if the conda setup pods are ready watch -n 5 kubectl get pods # When it is ready, you can delete the pods kubectl delete -f anaconda_setup.yaml ステップ 3: LLM アクセスを設定する この プロジェクトでは、LLM を使って報酬関数を生成できることを示します。私たちの実装では、Anthropic の Claude 3 (Amazon Bedrock 上) と OpenAI の ChatGPT の 2 つの LLM ファミリをサポートします。 ステップ 3.1: Claude 3 へのアクセスを設定する AWS コンソール (リージョン us-east-1 または us-west-2) で Amazon Bedrock に移動してください。Amazon Bedrock LLM には一部の特定のリージョンでのみアクセスできます。 左側のパネルで「Model Access」を選択します。 使用するモデルをチェックしてください。Claude 3 モデル (Claude 3 Haiku、Claude 3 Sonnet、Claude 3 Opus、および Claude 3.5 Sonnet) のみがサポートされています。 「Save」をクリックすると、Python で Claude 3 モデルを操作できるようになります。 ステップ 3.2: ChatGPT アクセスの設定 OpenAPI API キーを取得する この API キーを管理し、コントローラーポッドを Amazon EKS クラスターにデプロイする際、環境変数として使用できます。 デモンストレーション – シミュレーション/トレーニングの実行 次に、 eureka.yaml に記載されている Eureka アプリケーションをデプロイできます。 必要に応じて、以下を置き換えてください。 イメージ URI: 前のセクションで展開したモジュールでは、Amazon ECR の 1 つに Ubuntu イメージを公開します。イメージ URI は eureka モジュールの出力名 &lt;ApplicationImageUri&gt; になります。 EUREKA_TRAINING_QUEUE_URL: ADDF モジュールで作成した &lt;SqsUrl&gt; に置き換えてください。 OPENAI_API_KEY: ステップ 3.2 で取得したキーに置き換えてください。Claude 3 を使用する場合はこのステップを省略できます。 AWS_REGION: デプロイする予定のリージョン &lt;REGION&gt; に置き換えてください。 EUREKA_ENV: 学習に使用するタスク名です。 EUREKA_SAMPLE: LLM から生成される報酬関数のサンプル数です。各反復で並列に評価されます。 EUREKA_MAX_ITERATIONS: LLM から生成された報酬が評価される最大反復回数です。 EUREKA_NUM_VAL: 最終評価ラウンド数 (20000 回の反復) で、並列に実行できる数です。 上記の設定を変更した後は、次のコマンドを使用してポッドをデプロイできます。この例では、 shadow-hand タスクを実行します。コントローラーのポッドは shadow-hand という名前です。 kubectl apply -f eureka.yaml # You can check the progress using kubectl logs shadow-hand --follow ノート: タスクごとに 1 つの controller pod をデプロイできます (これは EUREKA_ENV で定義されます)。一方で、controller では複数のタスクを並列でデプロイできます。 ロボットシミュレーション/トレーニングの視覚化を DCV で行うデモンストレーション Figure 3: Application Streaming Architecture in EKS このセクションでは、DCV サーバーを使用してシミュレーションとトレーニングをストリーミングする方法を説明します。DCV をストリーミングするための全体的なアーキテクチャは以下のようになります。 DCV コンポーネントは、Amazon EKS クラスターへの DaemonSet としてデプロイされます。つまり、ノードごとに 1 つの DCV Pod が存在します。アプリケーション Pod、あるいは私たちのユースケースではワーカー Pod は全て、DCV Pod との間でディレクトリを共有します。DCV Pod はそのディレクトリに X11 ディスプレイソケットを作成し、ワーカー Pod はそのソケットを通じて DCV Pod 内の DCV サーバにアプリケーションをレンダリングできます。ワーカー Pod 内で実行される IssacGym は X11 ソケット上にレンダリングされます。次に、DCV サーバはユーザ接続を受け入れ、リモートデスクトップ上に IssacGym を表示します。パブリックの Amazon サブネットでは、NodePort サービスを使用できます。このブログ記事の範囲では、プライベートサブネットを使用します。次の接続方法は、プライベートサブネットとパブリックサブネットの両方で使用できます。 K8S ポートフォワーディングを使用して接続します。次のコマンドを使用できます: # First, determine which worker pod you want to connect to by running: kubectl get pods # Next, run the following command to forward the traffic kubectl port-forward $(kubectl get pods -n dcv --field-selector spec.nodeName =$(kubectl get pod -o = jsonpath ='{.spec.nodeName }') -o jsonpath ='{ range .items[ * ] }{.metadata.name }{"\n"}{ end }') -n dcv 9999:8443 上記のコマンドは、指定されたワーカー Pod が実行されているノードを見つけます。次に、そのノードで実行されている DCV Pod の名前を見つけます。そして、DCV サーバーがリッスンしているポート 8443 を、ローカルホストのポート 9999 にフォワードします。 ブラウザから https://localhost:9999 にアクセスできます。DCV サーバーからユーザー名とクレデンシャルの入力を求めるプロンプトが表示されます。 Figure 4: DCV Login Page in Web Browser DCV モジュールのセットアップで設定したユーザー名/パスワードを入力してください。次に、DCV サーバーに接続できるはずです。シミュレーションが画面に表示されるはずです。 Figure 5: Training shadow-hand in multiple pods クリーンアップ アプリケーションの Pod を削除するには、次のコマンドを実行できます: kubectl delete -f eureka.yaml このデプロイデモのモジュールを破棄するには、次のコマンドを実行できます。 seedfarmer destroy manifests/robotic-training-on-eks/deployment.yaml まとめ このブログ投稿では、Amazon EKS、Amazon FSx for Lustre、Amazon ECR、そして NICE DCV などの Amazon サービスを使用して、Nvidia の Eureka と Isaac Gym を使ってスケーラブルなロボット研修パイプラインを構築する方法を説明しました。また、ADDF を使ってインフラストラクチャを構成し、GPU オペレーターをインストール、IAM ロールを作成、コントローラーとワーカーの Pod をデプロイする方法も示しました。 さらに、AWS Bedrock の Claude 3 のような LLM を強化学習タスクの報酬関数生成に統合する方法も示しました。最後に、NICE DCV リモートデスクトップを使ってロボットのシミュレーションを視覚化するストリーミングする方法をご紹介しました。このソリューションは、ロボット開発チームが AWS 上で最新の AI モデルを使った報酬モデリングを活用し、より効果的に協業しながら研修を加速できるように設計されています。 オープンソースの ADDF プロジェクトは、このようなロボットの学習パイプラインをすばやくプロトタイピングできるようインフラストラクチャをコードとして再利用できるよう設計されています。 今後の課題として、このフレームワークで学習したポリシーを実際のロボットに移行することを検討しています。このフレームワークを活用すれば、実世界で高度な操作作業を行うためにロボットを訓練することも可能だと考えています。 AWS の自動車向け製品サービスについて詳しくは AWS for automotive ページ をご覧ください。または、 お問い合わせ ください。 参照 AWS の自動運転データフレームワーク (ADDF) を使用してカスタマイズされたワークフローを開発・デプロイ このブログはシニアソリューションアーキテクトの渡邊翼が翻訳を担当しました。

本ブログは、株式会社ユビタスと Amazon Web Services Japan が共同で執筆いたしました。 株式会社ユビタス は、NVIDIA の投資を受けたテクノロジー企業で、世界有数の GPU 仮想化とクラウドストリーミング技術を有しています。クラウドと AI 分野での最高のサービスを提供することを目指しています。ユビタスは、台湾大学や東京大学などの著名大学と協力し、繁体字・日本語の大規模言語モデル（LLM）を学習させるほか、AI キャラクターソリューション「 UbiONE 」を立ち上げ、ブランドキャラクター「 AI Vtuber: Ubi-chan 」を発表するなど、生成 AI の分野でイノベーションと実用化を行っています。 課題 UbiONE は、金融や医療など様々な業界向けにカスタマイズされた対話型 AI キャラクターソリューションになります。各業界には固有の要件があり、それに対応する対話機能とフロントエンド・バックエンドの構築が求められていました。しかし、従来の開発アプローチでは、このカスタマイズ作業に多大な労力とリソースを要していました。 検証内容 そこで、LLM の開発を加速するため、 Amazon EC2 P5 インスタンスと AWS ParallelCluster を活用した検証を行いました。まず 16 台の NVIDIA H100 GPU 搭載 Amazon EC2 P5 インスタンスで 1 ヶ月間の事前学習を実施し、高性能なクラウド計算環境を構築できました。その結果、深層学習とAIモデルのトレーニングスピードが大幅に向上しました。 次に、AWS の技術支援を受けながら AWS ParallelCluster を導入しました。この優れたクラスタ管理ツールにより、計算リソースの使い勝手が格段に改善され、学習時間が従来比で 90% 短縮されました。さらに Slurm システムを活用してリソース割り当てと管理を最適化することで、効率的なリソース活用を実現しています。 フロントエンド環境では、 Amazon S3 、 Amazon CloudFront 、 Amazon EKS 、 Elastic Load Balancing などの AWS サービスを組み合わせてアプリケーションとサービスをサポートしています。これらのサービスにより、ストレージ、トラフィック分散、動的プロビジョニングが可能になり、複数のカスタマイズされた AI キャラクターバージョンを高速に構築・管理し、効率的に展開および更新することができます。 検証結果 その結果として、従来の開発プロセスに比べて大幅な作業量の削減と開発効率の向上をもたらすことが確認できました。さらに、AWS のスケーラブルなクラウドインフラストラクチャを活用することで、様々な業界のお客様の要件を的確に満たすカスタマイズされた AI キャラクターを柔軟に提供できることが実証されました。 今後の展望 今後もユビタスは AWS が提供する先進的なクラウドサービスを積極的に活用し、プロダクト開発のさらなる効率化、機能拡張、精度向上を図っていく方針です。 幅広い観点からは、UbiONE を金融や医療に留まらず、さまざまな業界への展開を視野に入れています。各業界の専門知識を AI モデルに取り込むことで、高度な対話機能を備えた特化ソリューションの開発を図っていく予定です。 一方で深さの面でも、対話エンジンの高度化や API 機能の拡充、ユーザーインターフェースの改善など、リッチでシームレスなユーザー体験を実現するための継続的な開発投資を行っていく予定です。 まとめ 今回の検証を通して、Amazon EC2 P5 と AWS ParallelCluster の組み合わせが AI モデル開発の大幅な効率化に有効であることが確認できました。さらに、Amazon S3、Amazon CloudFront、Amazon EKS、Elastic Load Balancing を活用したサービスのプロビジョニングにより、AI における競争力が一層高まりました。ユビタスは引き続き AWS の技術を活用し、革新的な AI ソリューションの提供に注力していきます。

私が、 Amazon プライムデー のセールよりもワクワクすると思うものは何でしょうか? Amazon Web Services (AWS) がどのようにしてすべてを実現させたのかについて、学ぶことです。毎年、 Jeff Barr の年次投稿で、チャートの上位にランクインするメトリクスを確認するのを心待ちにしています。そのスケールにはいつも驚かされます。 2024年は Channy Yun と Jeff Barr が、 AWS が 2024 年のプライムデーを強化して記録的な売り上げを達成した方法 の舞台裏を紹介してくれます。詳細については投稿を読んでいただきたいのですが、毎年びっくりさせられるメトリクスの 1 つが、 Amazon Aurora のものです。プライムデーには、6,311 件の Amazon Aurora データベースインスタンスが 3,760 億のトランザクションを処理し、2,978 テラバイトのデータを保存し、913 テラバイトのデータを転送しました。 他にも嬉しいニュースがあります。 2 つの新しい AWS 認定試験の登録受付が開始されました 。 AWS 認定 AI プラクティショナー と AWS 認定機械学習エンジニア – アソシエイト のベータ版に登録できます。これらの認定資格は、基幹業務の専門家から経験豊富な機械学習 (ML) エンジニアまで、すべての人を対象としており、 需要の高い人工知能と機械学習 (AI/ML) のキャリア に備えるのに役立ちます。AWS 認定 AI プラクティショナーと AWS 認定機械学習エンジニア – アソシエイトを対象とした 4 段階の試験準備計画を実行することで、試験の準備ができます。 8月12日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Elastic Compute Cloud (Amazon EC2) EC2 G6e インスタンスの一般公開 – NVIDIA L40S Tensor Core GPU を搭載した G6e インスタンスは、機械学習や空間コンピューティングの幅広いユースケースに使用できます。G6e インスタンスを使用すると、最大 13B のパラメータを持つ大規模言語モデル (LLM) と、画像、動画、音声を生成するための拡散モデルをデプロイできます。 Karpenter 1.0のリリース – Karpenter は、柔軟かつ効率的で高性能な Kubernetes コンピューティング管理ソリューションです。Karpenter は Amazon Elastic Kubernetes Service (Amazon EKS) または任意の準拠の Kubernetes クラスターで使用できます。詳細については、 Karpenter 1.0 のリリースに関する投稿 をご覧ください。 Amazon SageMaker Pipelines 用のドラッグアンドドロップ UI – 今回のリリースにより、コードを記述しなくても、エンドツーエンドの AI/ML ワークフローをすばやく作成、実行、モニタリングして、モデルのトレーニング、ファインチューニング、評価、デプロイを行えるようになりました。ワークフローのさまざまなステップをドラッグアンドドロップし、UI で接続して AI/ML ワークフローを作成できます。 Amazon EC2 オンデマンドキャパシティ予約の分割、移動、変更 – Amazon EC2 オンデマンドキャパシティ予約を管理する新機能により、キャパシティ予約の分割、キャパシティ予約間でのキャパシティの移動、キャパシティ予約のインスタンス適格属性の変更を行えるようになりました。これらの機能の詳細については、「 既存のキャパシティ予約から利用可能なキャパシティを分割する 」を参照してください。 Amazon Q Business のドキュメントレベル同期レポート – Amazon Q Business のこの新機能により、データソース同期ジョブ中に処理された各ドキュメントの詳細なインデックス作成ステータス、メタデータ、アクセスコントロールリスト (ACL) の詳細を含む包括的なドキュメントレベルのレポートが提供されるようになりました。Amazon Q Business がクロールおよびインデックス登録を試みたドキュメントのステータスを確認できるだけでなく、特定のドキュメントが期待どおりの回答で返されなかった理由をトラブルシューティングすることもできます。 AWS Control Tower でのランディングゾーンのバージョン選択 – ランディングゾーンバージョン 3.1 以降では、現行バージョンのランディングゾーンを更新またはリセットしたり、選択したバージョンにアップグレードしたりできます。詳細については、 AWS Control Tower ユーザーガイドの「 ランディングゾーンのバージョンを選択する 」を参照してください。 AWS re:Post での AWS サポート公式チャンネルのリリース – AWS サポートと AWS Managed Services (AMS) の専門家が作成した、AWS で大規模な運用を実現するための厳選されたコンテンツにアクセスできるようになりました。この新しいチャンネルでは、複雑な問題に対する技術的解決策、運用上のベストプラクティス、AWS サポートと AMS のサービスに関するインサイトを確認できます。詳細については、 re: Post の AWS サポート公式チャンネル をご覧ください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS サービスの地域拡大 8月19日週に実施された AWS サービスの新しい AWS リージョンへの拡張の一部を次に示します。 Amazon VPC Lattice が、さらに 7 つのリージョンで利用可能に – Amazon VPC Lattice は、米国西部 (北カリフォルニア)、アフリカ (ケープタウン)、欧州 (ミラノ)、欧州 (パリ)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、南米 (サンパウロ) で利用できるようになりました。今回のリリースにより、Amazon VPC Lattice は 18 の AWS リージョンで一般利用できるようになりました。 QuickSight の Amazon Q が、さらに 5 つのリージョンで利用可能に – QuickSight の Amazon Q は、既存の米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト) リージョンに加えて、アジアパシフィック (ムンバイ)、カナダ (中部)、欧州 (アイルランド)、欧州 (ロンドン)、南米 (サンパウロ) で一般提供が開始されました。 AWS Wickr がヨーロッパ (チューリッヒ) リージョンで利用可能に – AWS Wickr は、米国東部 (バージニア北部)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (ロンドン)、欧州 (フランクフルト)、欧州 (ストックホルム) リージョンに加えて、欧州 (チューリッヒ) でも利用できるようになりました。 リージョン別の利用可能な AWS サービスの一覧を参照できます。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent 2024 – 第 1 ラウンドのセッションカタログ をご覧ください。2024年の AWS re:Invent でのさまざまな学習機会のすべてを詳しく確認し、今すぐアジェンダの作成を開始しましょう。あらゆる関心と学習スタイルに合ったセッションが見つかるでしょう。 AWS Summit – 2024 年の AWS Summit シーズンが終わりに近づいています。 クラウドコンピューティングコミュニティがつながり、コラボレーションして、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください: ジャカルタ (9 月 5 日)、 トロント (9 月 11 日)。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 コロンビア (8 月 24 日)、 ニューヨーク (8 月 28 日)、 ベルファスト (9 月 6 日)、 ベイエリア (9 月 13 日) です。 AWS GenAI Lofts – AWS AI のエキスパートとつながり、業界のリーダーによる講演、ワークショップ、Fireside Chat、質疑応答に参加しましょう。すべての Loft は無料で、AI ジャーニーの加速に役立つよう、あらゆる参加者が何かを得られるように、細心の注意を払って厳選されています。Loft は、 サンフランシスコ (8 月 14 日～9 月 27 日)、 サンパウロ (9 月 2 日～11 月 20 日)、 ロンドン (9 月 30 日～10 月 25 日)、 パリ (10 月 8 日～11 月 25 日)、 ソウル (11 月) で開催される予定です。 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 8月19日週はここまでです。8月26日週の Weekly Roundup もお楽しみに! – Prasad この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

はじめに データは現代企業にとって非常に重要な経営資源の一つとなっています。しかし、多くの企業がデータの活用において様々な課題に直面しているのが実情です。 そこで AWS では、パートナー企業と協力して「データ活用ワークショップ(WS)」を開催しました。今回の WS では、複数のユーザー企業が一同に会し、各社が抱える課題や対処方法を共有し合いました。そして、パートナー企業の支援のもと、短期間ながらも素晴らしい成果を上げることができました。 本記事では、その WS の様子と、データ活用におけるパートナー企業の重要性について紹介していきます。データ活用は一企業だけでは難しく、専門知識を持つパートナーと協力することが成功の鍵となります。ぜひ参考にしてみてください。 データ活用 WS とは データ活用 WS について説明する前に、データ活用における代表的な 4 つの課題について述べていきたいと思います。 &nbsp;データの収集と管理の難しさ 企業は複数のソースからデータを収集しますが、データ形式が統一されていないことが多く、収集と管理に手間がかかります。また、データの信頼性や完全性を確保することも大きな課題です。 データ分析人材の不足 データ分析に必要なスキルを持つ人材が不足しているのが実情です。データサイエンティストなどの専門家の確保は容易ではありません。 データ活用の具体的な方法がわからない データを収集し分析することは重要だと認識していても、実際にビジネスにどのように活用すればよいかわからないケースが多数あります。 データ活用に対する経営層の理解不足 データ活用の重要性を経営層が十分に理解していないと、投資が進まず取り組みが遅れがちになります。 データ活用 WS ではこれらの課題について、ユーザー企業が意識して取り組めるような座組みとなっています。まず、参加者は IT 部門が参加するようなテクノロジーに特化した勉強会のようなものではなく、実際にその会社ごとに持つ課題を深掘りして、その課題を解決するような分析ソリューションを構築します。そのためには、事業部門側の積極的関与が必要になります。本WS では、事業部門と IT 部門の参加を必須としており、さらに実際にデータ活用を根付かせるには経営層の理解が必要になることから、エグゼクティブスポンサーをつけていただくことを必須としています。 それにより、データ活用 WS で作られた分析業務を行うダッシュボードは、 IT 部門が作ったきりで使われないダッシュボードになることなく、常に事業部門の意見が取り入れた使い勝手の良いものとなり、さらにこの関係性を継続することにより、常に改善され続けるソリューションとなります。 またデータ分析が根付くには、経営層の理解が必要になります。理解があるからこそ、データの民主化が実現され、今回 のWS 参加者以外にも浸透していくことが期待されます。 &nbsp; 以上のような課題解決に重要な考え方は、こちらの Blog「 データドリブンカルチャーの作り方 」を参照ください。WS の中でもこちらの Blog の内容に触れ、組織のあり方についてもお伝えしました。 この WS では、AWS のデータ分析におけるスペシャリストの講義を受けた上で、Amazon 流のモノづくりのスタイルである Working Backwards を取り入れたグループワークで課題を洗い出し、解決策を考えます。考えた内容は各社で発表しあい、他社からの学びを得ることができるようになっています。さらにパートナー企業がサポートをするため、参加企業は WS の中で有識者からたくさんの知見を得ることができるようになっています。 図1. データ活用WS DAY1 から DAY4 までの流れ 実施期間としては、だいたい 3-4 ヶ月間かけてDay1 〜 Day4 を実施し、Day4 の成果報告会にて各社の成果を発表いただきます。 Amazon S3 をデータレイクとして、 AWS Glue Crawler でデータカタログを作成し、 Amazon Athena でクエリし、 Amazon QuickSight にてダッシュボードを作るパターンとするのが、最初のステップとして取り組みやすく、本 WSの中でも推奨しています。 今回は、ユーザー企業 3 社（ 藤田観光株式会社様 、 株式会社ルネサンス様 、医療機器メーカー A 社様）と、パートナー企業 3 社（ クラスメソッド株式会社様 、 株式会社ジェーエムエーシステムズ様 、 株式会社システナ様 ）が参加されました。参加企業の参加時のレベル感はまちまちで、企業内でも部署によっても差がある企業が多いです。これまで実施してきた中でも、データがサイロ化されており事業部ごとにそれぞれデータを保有しているため属人化された作業になっている企業が多く、そういった企業や、そこまでも至っていない企業でも参加が可能になっています。 図2. 各社のデータ活用具合と課題感 4 日間の様子については、以下の章をご覧ください。 データ活用WS実施の様子 Day1 Day1 では、ベースとなるアイデアの発散フェーズと位置づけ、座学とグループワークの 2 つのアジェンダを実施しました。座学では、AWS スペシャリストからの QuickSight に関する基礎知識のインプットセッションが提供されました。 グループワークでは、各々がデータ活用に関して「これまでやってきたこと」「うまくいったこと」「うまくいかなかったこと」を付箋に書き出し、事業部門と IT 部門がそれぞれの取り組みについて理解を深めました。参加企業の中には、この日が事業部門と IT 部門の参加者が初対面という場面もありましたが、ディスカッションを通して互いの意見への理解を深められていました。最後にはディスカッションを通して整理した①過去の取り組み ②自社のデータ活用のレベル感 ③現時点での課題 について、各社より発表をして頂きました。 写真1. グループワークの様子 個人ワークで付箋に書き出し→ホワイトボードに張り付けて整理する、というセットを繰り返し課題の整理を行いました。 Day2 Day2 では、ダッシュボードイメージを作成することをゴールに、座学とグループワークの 2 つのアジェンダを実施しました。 座学では、データ分析・可視化の必要性や、分析要件や指標の定義の仕方、可視化の手法のご紹介といった、ビジネス現場におけるデータ分析の基礎について、AWS のスペシャリストより講義を行いました。座学で学んだデータ分析の考え方をもとに、グループワークではダッシュボードを使うユーザーのペルソナを設定していきます。 図3. Day2 ディスカッションのまとめ方例 当日は上記のフォーマットに従ってホワイトボードで意見を整理していきます。 ダッシュボードイメージを考える際、Amazon 自身が新製品や新サービス開発・社内の業務改善の際に実践している「Working Backwards」と呼ばれるメカニズム（フレームワーク） を活用して課題を整理します。Working Backwards では、「お客様は誰ですか？」「現在の課題と新しい可能性は何ですか？」「お客様にとっての最大のメリットは何ですか？」「お客様のニーズやウォンツをどのように知りましたか？」「お客様の体験はどのように変わりますか？」という5 つの質問を通じて、本当に必要なサービスを企画・開発していきます。今回のグループワークでは、参加企業の皆さまから見た「お客様（＝ダッシュボードを使う人）」について徹底的に議論し、必要な要素を洗い出していきました。この際に、事業部門のお困りごとに関するリアルな声が反映されていくことで、より「使われる」ダッシュボードの開発に繋がります。Day2を終え参加者からは、「『お客様を起点に考える』にとても共感しました。」「 今までやりたいことが膨らみ過ぎて、手が付けられない状態になっていました。 Day2 で焦点が整理され、初手の動きが明確化できました。」という感想を頂いており、 座学やグループワークを通してデータ可視化の手順や考え方について学びを得ていただきました。 写真2. Day2発表の様子 &nbsp; Day3 Day3 では、Day2-Day3 の間の期間で開発されたダッシュボードに対し、ダッシュボードの利用者である事業部門の参加者へ中間報告を行います。 一番多かった企業では当日約 40 名様に参加頂き、実際に使う事業側の方から「こういったデータが見たかった」「こういう軸があるとさらに意思決定に役立てられそう」といった意見が飛び交いました。ここで得たフィードバックをもとにユーザー企業の IT 部門の参加者はさらに改良を重ね、Day4 に向けて完成させていきます。この開発期間中、パートナー企業の優れた技術力が開発メンバーの大きな助けとなります。参加企業が QuickSight の使い方に悩んでいる際は、パートナー企業に相談しながら解決策を一緒に考えていました。このようにパートナー企業の力を借りることで高品質なダッシュボードを素早く実装することが出来ました。 Day4 Day4 では、参加企業が Amazon オフィスに集まり成果物の成果発表会を実施します。 ここでは各社から開発までの道のりや今回実装したダッシュボードの発表がなされ、どの企業も短期間で開発したとは思えない素晴らしい出来栄えを披露いただきました。参加企業の 1 社は、データソースからそのままのデータでは表現が難しいものを、データパイプラインを構築した上、１つのダッシュボードの中で期間の比較を簡単に行えるように、検索フィールドを含めた比較的難易度の高い機能をパートナーの支援を受けながら構築し、実用性の高さから会場を沸かせていました。 写真3. 最終発表会の様子 また最後には、参加企業それぞれから MVP を 1 名ずつ選出させていただきました。伴走支援頂いたそれぞれのパートナー企業より、ユーザーに求められるダッシュボードを根気強く作り上げた各社の開発担当者が表彰されました。MVP に選出された皆さまからは、「データをただ見せるだけではあまり意味が無く、誰がどの様に何のために使うのか、という設定がとても重要になってくると学びになりました。」「ダッシュボード作成が可能な人材を社内に増やしていき、QuickSight の利用拡大を加速させる布教活動にも取り組みたいと思っております。」とコメントを頂きました。表彰された MVP の皆さまには AWS より書籍を贈呈いたしました。 成果発表会の終了後は、参加企業同士の懇親会の場が設けられています。データ活用 WS を通して得た学びや、この取り組みを自社に持ち帰り全社展開していくにあたっての悩みなど、ざっくばらんに意見交換がなされました。終了後のアンケートでは、「業界は違うものの、他社の取り組みや課題感を知ることで自分たちの立ち位置を知ることができ、かなり刺激的だった」という声が多くあがっていました。 今後の展望 データ活用 WS は、今後さらにパートナー企業と連携を強化しながら、継続して実施していく予定です。お客様からのフィードバックを参考にしながら、WS の内容を日々改善・進化させています。 また、WS に参加された企業においても、AWS やパートナー企業の支援を受けながら、WS で構築した分析基盤をベースにさらに様々なデータを取り込み、他の部門での課題についても解決できるようなソリューションを構築していく予定です。 事業部門を巻き込んで、会社全体の組織を変革したいとお考えの方は、ぜひお気軽にご相談ください。データ活用の取り組みを通じて、貴社の事業変革をサポートさせていただきます。 まとめ 本 Blog では、データ活用 WS でパートナー協業型の実施企業の様子をお伝えしました。業界問わず、様々な企業がデータ分析に課題を抱えており、データ活用を推進するためのノウハウや人材の確保が重要な課題となっています。今回の WS では異なる業種の企業が自社の状況を振り返り、それぞれの考え方を共有し合うことで、お互いに学びあい新たな可能性を見出すことができました。参加企業からは、「新しい視点を得ることができました。」「他社の事例から多くの気づきがありました。」「パートナー様および AWS メンバーの方々には手取り足取り色々教えていただきまして、ありがとうございました。」といったコメントをいただきました。コメントにもある通り、自社だけで進めるのではなく、他社の知見やパートナー企業、AWS とともに課題解決が実際にできていました。データ活用は単独の企業だけでは難しく、様々なパートナーと協業することが成功の鍵となります。今後もこうした機会を設けながら、データ活用の裾野を広げていきたいと考えています。 著者について 戸塚 智哉 戸塚智哉(Tomoya Tozuka)は、飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 &nbsp; 新田 美咲 新田 美咲(Misaki Nitta) は、サービス産業営業本部 エンタープライズアカウント第 3 営業部のアカウントマネージャーです。主にフィットネス業界、ホテル業界、SIerのお客様のご支援を担当しています。趣味は旅行で、最近行って感動した地域はハイジの世界が連想されるスイスのグリンデルワルトです。 &nbsp; &nbsp; &nbsp;

本投稿は Migrate an Amazon QLDB Ledger to Amazon Aurora PostgreSQL (記事公開日: 2024 年 7 月 18 日) のブログを翻訳したものです。 「 監査のユースケースで Amazon QLDB をAmazon Aurora PostgreSQL に置き換える 」のブログでは、データ変更に対して信頼できる監査を維持することが重要な要件である台帳データベースの一般的なユースケースにおいて、 Amazon Aurora PostgreSQL 互換エディション が Amazon QLDB の優れた代替手段である理由を説明しました。 この投稿では、Amazon QLDB 開発者ガイドの チュートリアル にある米国自動車省 (DMV) のサンプル台帳を例として、Amazon QLDB 台帳を Amazon Aurora PostgreSQL に移行するプロセスを示します。このソリューションをあなた自身の移行におけるベースとして使用し、スキーマと移行戦略に合わせて必要に応じて変更することができます。 移行決定 データベースを移行するときは、どのデータを移行するかを決定する必要があります。一部のアプリケーションでは、すべての履歴データを含むデータベース全体を移行することが求められます。また、最新のデータ (たとえば、過去 12 ヶ月分) のみを移行し、古いデータをアーカイブするのが最適な選択である場合もあります。ただし、アプリケーションのカットオーバーを迅速に行うために最新のデータを移行し、後で古いデータを新しいデータベースに移行することを決定する企業もあります。現在、一括で移行できることはほとんどないため、カットオーバーまでの期間、ターゲットデータベースをソースデータベースと同じ最新の状態に保つ必要があります。 この記事で紹介したソリューションは、ベースとして移行元の台帳データ全体をターゲットデータベースに移行し、移行元で継続中の変更をカットオーバーまでターゲットにコピーすることです。このソリューションはモジュール式なので、特定の移行戦略に合わせてカスタマイズできます。 また、移行中にターゲットデータベース内のデータをモデル化し、台帳データをそのモデルに適合するように変換する方法を決定する必要があります。Amazon QLDB ドキュメントデータモデルは、ネストされた要素を含む可能性のある複雑で構造化されたドキュメントをサポートします。Amazon QLDB のテーブルには、ドキュメント構造の異なるオブジェクトが含まれている場合があります。台帳の柔軟な文書モデルをより厳格なリレーショナルデータベーススキーマにマッピングするのは難しい場合があります。さらに、文書の構造は時間の経過とともに変化する可能性があります。移行プロセスでは、特定の文書のすべてのリビジョンが同じ構造であることを前提とすることはできません。このような課題を考えると、データを JSON として Amazon Aurora PostgreSQL に移行することもできます。これにより移行が大幅に簡素化されますが、リレーショナルデータベースのデータにアクセスするための最も効率的なオプションではない可能性があります。別の方法は、移行中に台帳データを正規化し、文書モデルをリレーショナルモデルに変換し、時間の経過とともに発生した文書モデルへの変更を考慮に入れることです。このアプローチはより複雑で、より多くのコーディングが必要であり、予期しない変換エラーが発生して移行プロセスが中断される傾向がありますが、RDBMS でのデータへのアクセス方法および使用方法によっては、より適切な選択となる場合があります。 このソリューションでは、両方のアプローチを提示します。車両登録サンプルアプリケーションの台帳データはリレーショナルモデルに正規化されますが、台帳からの改訂メタデータは Amazon Aurora PostgreSQL に JSONB タイプとして保存されます。 ソリューション概要 移行は、フルロードと継続的なレプリケーションの 2 つのフェーズで実行されます。フルロードでは、ソースデータベースからターゲットデータベースへのデータの効率的な一括ロードが実行されます。ソースデータベースは、アプリケーションがターゲットデータベースを切り替えて使用するまでトラフィックを処理し続ける可能性があるため、フルロードでは移行されなかったデータ変更が含まれている可能性があります。継続的なレプリケーションまたは変更データキャプチャ（CDC）フェーズでは、継続的に変更を取得してターゲットデータベースに移行し、アプリケーションがターゲットデータベースを参照するまでソースと同じ最新の状態に保ちます。 フルロードフェーズでは、Amazon QLDB 台帳は AWS Step Functions ステートマシンによって Amazon Simple Storage Service (Amazon S3) のバケットに エクスポート されます。エクスポートには、エクスポートが開始された時点のすべてのトランザクションのデータが含まれます。 AWS Glue ジョブは、エクスポートされたファイルから台帳文書のリビジョンを抽出し、 AWS Database Migration Service (AWS DMS) が使用できる CSV 形式に変換します。AWS Glue ジョブは、変換された CSV ファイルを Amazon S3 に書き込みます。AWS DMS タスクは Amazon S3 から CSV ファイルを読み取り、そのデータを Aurora PostgreSQL データベースにロードします。この記事では Amazon Aurora PostgreSQL へのデータ移行について説明していますが、AWS DMS は 様々なターゲットエンドポイント をサポートしているため、ここで説明するプロセスを他のデータベースへの移行にも適用できます。 次の図は、ソリューションのアーキテクチャを示しています。 継続的なレプリケーションフェーズでは、台帳への新しい更新がキャプチャされ、ほぼリアルタイムでターゲットの Aurora PostgreSQL データベースに移行されます。このプロセスは Amazon QLDB ストリーミング 機能に依存しています。このソリューションでは、エクスポートの最後の台帳ブロックを識別して、エクスポート開始後にコミットされた最初のブロックからストリームを開始できるようにします。新しいトランザクションが台帳にコミットされると、Amazon QLDB はそれらの変更を Amazon Kinesis Data Streams に送信します。 AWS Lambda 関数は、次の図に示すように、 Amazon Kinesis Data Streams からのイベントを使用し、そのデータをターゲットデータベースに書き込みます。 前提条件 移行ソリューションは、インフラストラクチャをセットアップし、移行に使用されるコードをデプロイする複数の AWS CloudFormation テンプレートを使用してデプロイされます。CloudFormation テンプレートと関連ファイルは GitHub repo で入手でき、PCにダウンロードする必要があります。以下のコマンドでプロジェクトコードをダウンロードします。 git clone git@github.com:aws-samples/example-qldb-ledger-migration.git プロジェクトには次のファイルが含まれています。 setup.yml – 車両登録台帳、ターゲットの Aurora PostgreSQL データベース、および関連する VPC ネットワーキングをデプロイしてデータを作成します ledger-export.yml – コンポーネントをデプロイして台帳からデータをエクスポートします ledger-full-migration.yml – AWS Glue コンポーネントと AWS DMS コンポーネントをデプロイして、エクスポートされた台帳データをターゲットデータベースに抽出、変換、ロード (ETL) します ledger-cdc-migration.yml – Amazon QLDB ストリーミング用の Kinesis Data Stream と、ターゲットデータベースに台帳の変更を書き込むストリームコンシューマーを設定します dmv-postload-ddl.sql – 移行のフルロードフェーズが完了した後にターゲットデータベースにインデックスを作成するための SQL ステートメントが含まれます ソースデータベースとターゲットデータベースの作成 このデモンストレーションでは、ソースとして動作する Amazon QLDB 台帳とターゲットとして機能する Aurora PostgreSQL クラスターを作成し、VPC と関連ネットワーク、データベース認証情報を保持する AWS Secrets Manager シークレット、S3 バケット、 AWS Identity and Access Management (IAM) ロール、および Aurora クラスターを起動するために必要なその他のコンポーネントを作成します。セットアップにより、台帳データベースにデータが入力され、Aurora PostgreSQL クラスターにデータベースとスキーマが作成され、移行用のデータベースユーザーが作成されます。 このソリューションは RDS Data API に依存していますが、すべてのリージョンで利用できるわけではありません。 この表 を参照して、使用しているリージョンが Data API をサポートしていることを確認してください。 このソリューションをあなた自身の移行の基礎として使用していて、Amazon QLDB 台帳と Aurora PostgreSQL クラスターがすでにセットアップされている場合、このセクションはスキップできます。 AWS CloudFormation を使用してコンポーネントをデプロイするには、以下のステップを実行します。 AWS CloudFormation コンソールのナビゲーションペインで 「 スタック 」 を選択します。 「 スタックの作成 」 を選択し、「 新しいリソースを使用（標準） 」 を選択します。 「 テンプレートファイルのアップロード 」 を選択します。 「 ファイルの選択 」 を選択し、PC 上の GitHub プロジェクトから setup.yml ファイルを選択します。 「 次へ 」 を選択します。 「 スタックの詳細を指定 」ページで、 スタック名 に ledger-migrate-setup と入力します。 &nbsp;VPC の CIDR が環境内の他の VPC と競合しない限り、すべての入力パラメータはデフォルトのままにします。競合する場合は、 VPCCIDR 、 DatabaseSubnetCIDRs 、 PublicSubnetCIDRs の各パラメータを変更して、競合しないようにしてください。また、デフォルトの AuroraDBInstanceClass パラメータを調整する必要がある場合もあります。すべてのインスタンスタイプがすべてのリージョンで利用できるわけではありません。 「 次へ」 &nbsp;を選択します。 「 スタックオプションの設定」 ページで、「 次へ」 &nbsp;を選択します。 「 確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「 送信」 &nbsp;を選択します。 スタックが CREATE_COMPLETE ステージになったら、「 出力 」タブを選択してスタックの出力を表示します。これらの値は、移行プロセスの後続ステップの入力として使用されます。 Amazon QLDB からデータをエクスポート 移行の最初のステップは、ソース台帳から S3 バケットにデータをエクスポートすることです。エクスポートは多数のファイルで構成され、各ファイルには JSON 形式の 1 つ以上の台帳ブロックが含まれます (詳細については、 QLDB のジャーナルエクスポート出力 を参照してください)。中規模の台帳のエクスポートでも数時間かかる場合があります。エクスポート時間を短縮するために、1 つの台帳に対して複数のエクスポートを並行して実行して、エクスポートごとに台帳の一部を処理することができます。Amazon QLDB はデフォルトで最大 2 つの同時エクスポートをサポートします。台帳が非常に大きい(数百ギガバイト) 場合は、AWS サポートに連絡して制限の引き上げをリクエストしてください。 このソリューションでは、Step Functions を使用してエクスポートを実行します。ステートマシンは、必要な数の同時エクスポートをパラメータとして受け入れます。台帳ダイジェストを取得してジャーナルの最後のブロック番号を取得し、それを使用して台帳を均等に分割し、エクスポート全体で作業を均等に分割します。ステートマシンはエクスポートジョブを開始し、すべて完了するまでループします。すべてのエクスポートジョブが完了すると、ステートマシンは各エクスポートの最後のブロックのダイジェストとプルーフハッシュを取得し、Amazon S3 に保存します。これにより、ソースの台帳が削除された後にエクスポートは暗号で検証されます (このプロセスはこの記事では説明しません)。 エクスポートを実行するには、まず AWS CloudFormation を使用して必要なコンポーネントをデプロイする必要があります。以下のステップを完了します。 &nbsp;AWS CloudFormation コンソールのナビゲーションペインで 「 スタック」 &nbsp;を選択します。 「 スタックの作成」 &nbsp;を選択し、「 新しいリソースを使用 (標準)」 &nbsp;を選択します。 「 テンプレートファイルをアップロード」 &nbsp;を選択します。 「 ファイルを選択」 &nbsp;を選択し、コンピューター上の GitHub プロジェクトから ledger-export.yml ファイルを選択します。 「 次へ」 &nbsp;を選択します。 「 スタックの詳細を指定」 ページで、「 スタック名」 &nbsp;に ledger-export と入力します。 &nbsp; LedgerName パラメータの値はデフォルト値 ( “vehicle-registration” ) のままにしておきます。 「 次へ」 &nbsp;を選択します。 「 スタックオプションの設定」 ページで、「 次へ」 &nbsp;を選択します。 「 確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「 送信」 &nbsp;を選択します。 &nbsp;スタックが CREATE_COMPLETE ステージになったら、Step Functions コンソールを開き、ナビゲーションペインで 「ステートマシン」 を選択します。 LedgerExporter ステートマシン を選択します。 ステートマシンは インプットとしてJSON オブジェクトを受け入れます。 &nbsp;次のスニペットを JSON エディターに入力します。AWS サポートを通じて同時エクスポートの制限を増やした場合は、 ExportCount の値を新しい制限に変更してください。 { "LedgerName": "vehicle-registration", "BucketPrefix": "dmv/", "ExportCount": 2 } &nbsp;「 実行の開始 」を選択します。 ステートマシンは、&nbsp; vehicle-registration 台帳の場合は約 10 分間実行されますが、台帳が大きい場合はさらに長く実行されます。完了すると、実行ステータスは「 成功 」になります。実行詳細ページの グラフビュー セクションには、ステートマシンのステップが視覚的に表示されます。 &nbsp; Export ノードを選択し、 Output セクションからエクスポート ID をコピーして、テキストエディタに保存します。これらはこれ以降のステップで必要になります。 ダイジェスト ノードを選択し、 LastBlockNum &nbsp;と&nbsp; LastBlockTimestamp の値を、後で使用できるようにテキストエディタにコピーします。 エクスポートが完了しました。このプロセスにより、 ledger-export-&lt;ACCOUNT ID&gt; という名前の S3 バケットが作成されました。このバケットには、JSON 形式でエクスポートされた台帳データを含む dmv というフォルダがあります。フォルダの名前は、ステートマシンへの入力の&nbsp; BucketPrefix パラメーターで設定されました。 データの抽出と変換 台帳のエクスポートが完了したら、次のステップは、エクスポートされた JSON ファイルから台帳データを抽出し、それを CSV ファイルに変換して Amazon Aurora PostgreSQL に効率的に読み込むことです。このソリューションは、抽出と変換を実行する AWS Glue ジョブを作成します。AWS Glue は Apache Spark を使用してエクスポートデータセットを複数のコンピューティングノードに分散して同時処理することで、大規模な台帳からのデータを処理するのに必要な時間を短縮します。AWS Glue ジョブは、エクスポートステップで作成された S3 バケットからエクスポートされたデータを読み取り、その出力をプロセスによって作成された新しい ETL バケットに書き込みます。 AWS Glue ジョブは、 k 台帳のテーブルをターゲットデータベース用に設計したスキーマに変換し、台帳文書の構造をリレーショナルデータベースの行と列にフラット化するように構築されています。このプロセスを使用して台帳を移行するには、データモデルに合わせて AWS Glue ジョブの PySpark コードの一部を変更する必要があります。 抽出と変換を実行するには、AWS CloudFormation を使用して必要なコンポーネントをデプロイします。 &nbsp;AWS CloudFormation コンソールのナビゲーションペインで 「 スタック」 &nbsp;を選択します。 「 スタックの作成」 &nbsp;を選択し、「 新しいリソースを使用 (標準)」 &nbsp;を選択します。 「 テンプレートファイルをアップロード」 &nbsp;を選択します。 「 ファイルを選択」 &nbsp;を選択し、コンピューター上の GitHub プロジェクトから ledger-full-migration.yml ファイルを選択します。 「 次へ」 &nbsp;を選択します。 このテンプレートは、移行のこのフェーズと次のフェーズに必要なコンポーネントをデプロイします。 「 スタックの詳細を指定」 &nbsp;ページで、「 スタック名」 &nbsp;に ledger-full-migrage と入力します。 エクスポートスタックとは異なり、このテンプレートには入力パラメータが必要です。 &nbsp;次の入力パラメータを指定します。 &nbsp; LedgerName には、 ledger-migrate-setup スタックの LedgerName 出力パラメータの値を入力します。 &nbsp; ExportIds には、state 関数実行からコピーしたexport IDs を、カンマ区切りのリスト形式で入力します。 &nbsp; ベースプレフィックスのエクスポート に、&nbsp; dmv/ と入力します。 &nbsp; グルーワーカータイプ に、&nbsp; G.2X と入力します。 &nbsp; グルーワーカーの数 に、 2 と入力します。 &nbsp; レプリケーション・インスタンス・サブネット に、 ledger-migrate-setup スタックの DatabaseSubnets パラメータからサブネットを入力します。 &nbsp; レプリケーションインスタンスクラス に、dms.r6i.large と入力します。 &nbsp; セキュリティグループ については、 ledger-migrate-setup スタックの DatabaseSecurityGroups パラメータからセキュリティグループを選択します。 &nbsp; ターゲットデータベースシークレット名 には、 ledger-migrate-setup スタックの MigrateDatabaseUserSecretName 出力パラメータの値を入力します。 &nbsp; ターゲットデータベース名 には、 ledger-migrate-setup スタックの TargetDatabaseName 出力パラメータの値を入力します。 「 次へ」 &nbsp;を選択します。 「 スタックオプションの設定」 &nbsp;ページで、「 次へ」 &nbsp;を選択します。 「 確認して作成」 &nbsp;ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「 送信」 &nbsp;を選択します。 &nbsp;CloudFormation スタックのデプロイが完了したら、AWS Glue コンソールに移動し、ナビゲーションペインで ETL ジョブ を選択します。 &nbsp; ledger-dmv-migrate ジョブを選択し、「 ジョブの実行」 &nbsp;を選択します。 &nbsp;ジョブの名前を選択して、ジョブの詳細ページを開きます。 &nbsp;「 実行 」 タブを選択すると、ジョブのステータスが表示されます。 ジョブが完了すると、そのステータスは「 成功 」 になります。 CloudFormation テンプレートは ledger-etl-&lt;AccountId&gt; という名前の S3 バケットを作成しました。AWS Glue ジョブは、その出力をバケットの dmv というフォルダに書き込みます。Amazon S3 コンソールを開き、 ledger-etl-&lt;AccountId&gt; バケットに移動して、 dmv フォルダを開くことができます。 vehicle-registration 台帳の各テーブルに対応するフォルダのリストが表示されます。これらのフォルダには、テーブル内の削除されていないすべてのドキュメントの最新リビジョンが含まれています。ターゲットの Aurora PostgreSQL データベースに書き込まれる監査テーブルの内容を含む各台帳テーブル用の追加フォルダがあります。監査テーブルには、それぞれの元帳テーブル内のすべての文書の完全な改訂履歴が含まれています。 フォルダとそのコンテンツを確認してみてください。 table_counts フォルダには、台帳の各テーブルの名前と、テーブル内のそれぞれのドキュメントリビジョン数を含む1つのファイルが格納されます。これは、すべてのレコードがターゲットデータベースに移行されたことを確認するのに役立ちます。 フルデータ移行 フルデータの移行では、AWS DMS を使用して前のステップの AWS Glue ジョブの CSV 出力を読み取り、それを Amazon Aurora PostgreSQL にロードします。AWS DMS は、データをロードする前にターゲットデータベースのテーブルを切り捨てます。この記事ではターゲットデータベースとして Amazon Aurora PostgreSQL を使用していますが、AWS DMS では AWS Glue ジョブの出力を 他の多くのデータベース に移行できます。 移行を開始するには、次の手順を実行します。 &nbsp;AWS DMS コンソールのナビゲーションペインで 「 データベース移行タスク」 &nbsp;を選択します。 &nbsp; dmv-full-migration task を選択し、「 アクション 」ドロップダウンで「 再起動/再開 」を選択します。 &nbsp;警告として ターゲットデータベースへのデータ損失の可能性がある再起動/再開 を選択します。 移行タスクの実行が開始されます。そのステータスにはジョブの進行状況が反映されます。ジョブが完了すると、そのステータスは 「 ロード完了」 &nbsp;になります。この時点で、Amazon QLDB の vehicle-registration 台帳からエクスポートされたすべてのデータが Aurora PostgreSQL データベースに移行されます。次に、Aurora PostgreSQL データベースにインデックスと制約を作成します。 &nbsp;Amazon RDS コンソールで、前のセクションで行ったように台帳データベースに接続します。 &nbsp;GitHub プロジェクトの dmv-postload-ddl.sql ファイルからすべての行をコピーし、RDS クエリエディタに貼り付けて、「 実行」 &nbsp;を選択します。 &nbsp;RDS クエリエディタを使用して、次のクエリのいくつかを実行して、移行されたデータを確認します。 select * from dmv.person; select * from dmv.person_audit_log; select * from dmv.vehicle; select * from dmv.vehicle_audit_log; select * from dmv.vehicle_registration; select * from dmv.vehicle_registration_audit_log; select * from dmv.drivers_license; select * from dmv.drivers_license_audit_log; テーブルの ql_audit カラムは PostgreSQL の JSON タイプです。この列には、Amazon QLDB 台帳からのリビジョンメタデータが含まれています。 &nbsp;次のクエリを実行して、JSON オブジェクトの個々のフィールドにアクセスする方法を確認してください。 select person_id, ql_audit-&gt;'ql_txid' transaction_id, ql_audit-&gt;'ql_txtime' transaction_timestamp from dmv.person_audit_log; 継続的な変更データの複製 フルデータの移行プロセスでは、台帳からエクスポートされたすべてのデータが移行されます。ただし、台帳を使用するアプリケーションが Aurora PostgreSQL データベースを使用するように変更されるまで、エクスポート後も台帳を引き続き使用できます。移行の次のステップは、実行された変更をキャプチャし、ほぼリアルタイムで Aurora PostgreSQL データベースに複製することです。このソリューションでは、Amazon QLDB ストリーミング 機能を使用して、台帳の変更を Kinesis Data Stream にほぼリアルタイムで送信します。Lambda 関数はデータストリームからの台帳イベントを処理して、 RDS Data API で Aurora PostgreSQL データベースに書き込みます。次の図は、このワークフローを示しています。 AWS CloudFormation を使用して変更データのレプリケーションに必要なコンポーネントをデプロイするには、以下のステップを実行します。 &nbsp;AWS CloudFormation コンソールのナビゲーションペインで 「 スタック」 &nbsp;を選択します。 「スタックの作成」 を選択し、「 新しいリソースを使用 (標準)」 &nbsp;を選択します。 「テンプレートファイルをアップロード」 &nbsp;を選択します。 「ファイルを選択」 &nbsp;を選択し、コンピューター上の GitHub プロジェクトから ledger-cdc-migration.yml ファイルを選択します。 「次へ」 &nbsp;を選択します。 「 スタックの詳細を指定 」ページで、「 スタック名 」に ledger-cdc-migrate と入力します。 次のスタックパラメータを入力します。 AuroraClusterArn には、 ledger-migrate-setup スタックの AuroraClusterArn 出力パラメータの値を入力します。 AuroraDatabaseName には、 ledger-migrate-setup スタックの TargetDatabaseName 出力パラメータの値を入力します。 DatabaseUserSecretArn には、 ledger-migrate-setup スタックからの MigrateDatabaseUserSecretARN 出力パラメータの値を入力します。 KinesisShardCount &nbsp;に 1 と入力します。 LastFullLoadBlock には、エクスポートステートマシンから取得した LastBlockNum の値を入力します。 LedgerName には、 ledger-migrate-setup スタックから LedgerName 出力パラメータの値を入力します。 LedgerStreamStartTime には、エクスポートステートマシンから取得した LastBlockTimestamp の値を入力します。 「次へ」 &nbsp;を選択します。 「スタックオプションの設定」 ページで、「 次へ」 &nbsp;を選択します。 「確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、 送信」 &nbsp;を選択します。 CloudFormation スタックのデプロイが完了したら、AWS Glue コンソールに移動し、ナビゲーションペインで ETL ジョブ を選択します。 スタックのデプロイが完了すると、進行中のレプリケーションがアクティブになります。 レプリケーションの動作を確認するには、Amazon QLDB コンソールの PartiQL エディタに移動します。 「 台帳の選択 」ドロップダウンメニューで vehicle-registration 台帳を選択し、次のクエリを入力します。 update Person set FirstName = 'Melvin' where GovId = 'P626-168-229-765'; &nbsp;RDS クエリエディタに移動し、ターゲットデータベースに対して次のクエリを実行します。 select * from dmv.person_audit_log where gov_id = 'P626-168-229-765' 監査テーブルには、Melvin Parker の 2 つのレコードが含まれています。元のバージョンには、「MelVIN」というスペルのファーストネーム、0 の version 、および INSERT を表す I の operation が含まれています。アップデートされたバージョンでは、ファーストネームが「Melvin」と修正され、 version は 1 になり、UPDATE の operation は U になっています。 &nbsp;次に、以下のクエリを実行します。 select * from dmv.person where gov_id = 'P626-168-229-765' 更新されたpersonsテーブルには、Melvin Parkerのレコードの最新リビジョンが含まれています。名前とバージョン番号を書き留めておきます。 後片付け この記事で作成した AWS インフラストラクチャを削除するには、AWS CloudFormation コンソールを開き、 ledger-cdc-migrate , ledger-full-migrate , ledger-export, setup.yml の順に 削除 します。 スタックには、 ledger-export-&lt;AccountId&gt; と ledger-etl-&lt;AccountId&gt; という 2 つの S3 バケットが残ります。これは、ソリューションが本番台帳の移行に適合している場合に、重要な Amazon QLDB 台帳データが誤って削除されないようにするためです。vehicle-registration 台帳の移行では、各バケットの コンテンツを削除 してから バケットを削除 します。 ソリューションを台帳に合わせて調整 この移行ソリューションは、独自の台帳で使用できるように調整できます。カスタムスキーマを作成するには、プロジェクトソースの setup.yml テンプレートファイルにある PrepareTargetDatabase リソースのスキーマ定義を変更する必要があります。また、 dmv-postload-ddl.sql ファイルを変更して、カスタムスキーマのプライマリインデックスとセカンダリインデックスを作成する必要があります。 ledger-dmv-migrate のAWS Glue ジョブのPySparkコードでは、141行目から146行目まで、ソース台帳内のテーブルの変換関数と出力列が、 table_converters というPython dictで定義されています。変換機能により、台帳からの 1 つの文書リビジョンを CSV として出力できる列にフラット化します。ソースデータベースとターゲットデータベースのデータモデルの table_converters および関連する変換関数の定義を変更します。AWS Glue ジョブのソースコードは、GitHub プロジェクトの ledger-full-migration.yml ファイルの PutGlueJobCodeToS3 リソースで定義されています。 table_converters = { 'Person': { 'name': 'person', 'func': convert_person, 'columns': ['doc_id', 'version', 'person_id', 'first_name', 'last_name', 'dob', 'gov_id', 'gov_id_type', 'address', 'ql_audit'] }, 'Vehicle': { 'name': 'vehicle', 'func': convert_vehicle, 'columns': ['doc_id', 'version', 'vin', 'type', 'year', 'make', 'model', 'color', 'ql_audit'] }, 'VehicleRegistration': { 'name': 'vehicle_registration', 'func': convert_vehicle_registration, 'columns': ['doc_id', 'version', 'vin', 'license_plate_num', 'state', 'city', 'pending_penalty_amt', 'valid_from_dt', 'valid_to_dt', 'primary_owner', 'secondary_owners', 'ql_audit'] }, 'DriversLicense': { 'name': 'drivers_license', 'func': convert_drivers_license, 'columns': ['doc_id', 'version', 'person_id', 'license_plate_num', 'license_type', 'valid_from_dt', 'valid_to_dt', 'ql_audit'] } } Kinesis Data Stream からの台帳更新を使用する Lambda 関数には、同じロジックが含まれていますが、これも変更する必要があります。変更するコードは、GitHub プロジェクトの ledger-cdc-migration.yml ファイル内の StreamConsumerFunction リソースで定義されています。 最後に、 ledger-full-migration.yml ファイル内の SourceEndpoint リソースは、AWS Glue ジョブによって生成される CSV ファイルの構造を定義する AWS DMS ソースエンドポイントを定義します。この定義は、新しい構造に合わせて変更する必要があります。AWS DMS テーブル定義形式の詳細については、「 AWS DMS のソースとしての Amazon S3 の外部テーブルの定義 」を参照してください。 移行を実行する前に、ターゲットデータベースをバックアップしてください。移行ソリューションはターゲットデータベースのテーブルを切り捨て、エラーが発生しても移行全体をロールバックしません。 サマリー この投稿では、Amazon QLDB 開発者ガイドのチュートリアルにある車両登録サンプルデータベースを使用して、Amazon QLDB 台帳を Amazon Aurora PostgreSQL に移行するためのソリューションを紹介しました。このソリューションを独自の台帳の移行に適応させることができ、モジュラー設計により移行戦略に合わせて調整できます。 このソリューションの詳細や移行計画については、AWS の担当者にお問い合わせください。 著者について Dan Blaner は、台帳とリレーショナルデータベースを専門とするプリンシパルソリューションアーキテクトです。彼は学ぶこと、物事を理解すること、他の人が物事を理解するのを助けることを楽しんでいます。休みはベースを弾き、仲の良い友達と bad music 作りを楽しんでいます。

本投稿は Replace Amazon QLDB with Amazon Aurora PostgreSQL for audit use cases (記事公開日: 2024 年 7 月 18 日) のブログを翻訳したものです。 Amazon Quantum Ledger Database (Amazon QLDB) はフルマネージド型の台帳データベースサービスで、台帳にコミットされたすべてのトランザクションの完全かつ検証可能な履歴を提供します。Amazon QLDB 台帳の中核となるのがジャーナルです。ジャーナルは追加専用のデータ構造で、ブロックとして保存されたトランザクションの連続的かつイミュータブルなレコードが含まれます。ジャーナル内のブロックは、暗号ハッシュを使用して連結されます。暗号ハッシュチェーンは、暗号検証方法を使用してトランザクションデータの整合性を提供します。トランザクション履歴のイミュータブルで 暗号化による検証可能性 という 2 つの特性は Amazon QLDB 固有のものであり、お客様が Amazon QLDB を使用してデータの整合性の高い監査と変更履歴を提供する理由でもあります。 この投稿では、監査用に Amazon QLDB の代わりに Amazon Aurora PostgreSQL 互換エディション を使用する方法と、Amazon QLDB が提供する独自の機能の一部を Amazon Aurora PostgreSQL のどの機能に置き換えることができるかについて説明します。 ジャーナルの置き換え Amazon QLDB では、基になるジャーナルには、クエリステートメントやデータ定義コマンドを含む、コミットされたすべてのトランザクションの不変なレコードが格納されます。ジャーナルのトランザクション履歴は Amazon Simple Storage Service (Amazon S3) バケットにエクスポートして、監査目的でアクセスできます。Amazon Aurora PostgreSQL は、変更に関する永続的で不変なレコードを保持しません。代わりに、その履歴を監査データとして生成し、データベースの外部に保存する必要があります。 Amazon Aurora PostgreSQL は オープンソース監査ロギングエクステンションである pgAudit をサポートしています。これにより、PostgreSQL の標準のロギングと比べてきめ細かなセッションおよびオブジェクトの監査ロギングが可能になります。DDL 操作、読み取り、書き込み、ロールと権限の変更、関数の実行、バキュームやチェックポイントなどのユーザー開始操作などの監査するイベントを選択できます。ログ出力は、Amazon RDS コンソールからアクセスできる標準の postgres.log ファイルに送信され、 最大 7 日間保存 できます。監査ログデータを永続的に保持するには、 ログを Amazon CloudWatch Logs に送信するように Aurora クラスターを設定 して、ログを無期限に保持することができます。 Amazon CloudWatch Logs は、ログのクエリ、モニタリング、アラート、および管理機能を提供します。CloudWatch Logs は保存時にログファイルを暗号化します。ログの削除を禁止する機能を含め、 AWS Identity and Access Management (IAM) を使用して CloudWatch Logsへのアクセスを管理できます。 CloudWatch Logs は、監査人がデータベース監査を行う際に使用するのが難しいインターフェイスかもしれません。「 Amazon S3 と Amazon Athena を使用して Amazon RDS for PostgreSQL の一元化された監査データ収集を構築する 」という投稿では、監査人が監査データをクエリするためのわかりやすいインターフェイスを提供するソリューションを提供しています。このソリューションでは、 Amazon Data Firehose を使用してデータベースのログを CloudWatch Logs から Amazon S3 に送信し、 Amazon Athena を使用して SQL でクエリを実行できます。次の図は、このアーキテクチャを示しています。 history() 関数の置き換え Amazon QLDB history() 関数を使用すると、テーブル内のすべてのレコードのすべてのリビジョンにアクセスできます。history() 関数を使用して、時間の経過とともにデータレコードがどのように変化したかを確認できます。別のテーブルの行に加えられた変更のコピーを格納する監査テーブルを使用して、この機能を Amazon Aurora PostgreSQL で複製できます。 監査テーブルの従来のアプローチは、監査対象のテーブルの構造を反映したテーブルです。トリガーは、メインテーブルの INSERT、UPDATE、DELETE のたびに実行されて、監査テーブルに変更された行のコピーを送信します。この方法のバリエーションでは、監査された行が JSON として保存されるため、ソーステーブルの構造が変更された場合に監査テーブルの構造を変更する必要がなくなります。テーブル権限は、監査テーブル内の行の変更を禁止するように設定されています。次の図は、この設計を示しています。 このアプローチは、正しい権限があればユーザーが監査テーブルのデータを変更できるという点で Amazon QLDB のHistory とは異なります。データアクセス権限の監査は、監査テーブル内のデータの整合性を維持するために重要です。監査テーブルを安全な専用の監査データベースに分離することで、この問題が解消され、監査データの信頼性が高まります。「 Amazon Aurora PostgreSQL テーブルの監査記録を作成する 」という投稿では、次の図に示すように、 AWS Database Migration Service (AWS DMS) を使用してソースデータベースの変更を取得し、監査データベースに安全に保存するソリューションを提供しています。 Amazon QLDB streamsの置き換え Amazon QLDB streams は、ニアリアルタイムで台帳イベントを Amazon Kinesis Data Streams にフィードします。ストリームレコードには、台帳へのデータ更新と、データベースで実行されたクエリステートメントのレコードが含まれます。ストリームを使用して、台帳から他のシステムにデータを複製できます。ストリームイベントをニアリアルタイムで分析して、疑わしいアクティビティや重要なテーブルやデータへの変更を特定できます。 データレプリケーション Aurora をプライマリデータベースとして使用する場合、AWS DMS を使用して Aurora から他のシステムにデータをレプリケーションできます。AWS DMS は、1 回限りのデータ移行用だけではありません。ソースの Aurora PostgreSQL データベースから変更データキャプチャ (CDC) を使用して 1 つ以上のターゲットデータベースへの継続的なレプリケーションをサポートしています。Amazon QLDB ストリームを使用してデータをレプリケートする場合とは異なり、AWS DMS を介して Amazon Aurora PostgreSQL からデータをレプリケートする場合、追加のコーディングは必要ありません。AWS DMS は、宣言型 JSON 構文を使用して、ソースデータベースとターゲットデータベース間でデータをマッピングおよび変換します。 ニアリアルタイムの監査 Amazon Aurora PostgreSQL を使用してニアリアルタイムの監査機能を利用するには、 Database Activity Streams を使用できます。Database Activity Streams は、Aurora クラスターから Kinesis Data Stream に低レベルの監査情報をニアリアルタイムでフィードします。Amazon QLDB ストリームと同様に、監査イベントをフィルタリング、分析、処理するカスタム Kinesis Data Stream コンシューマーを構築できます。Database Activity Streams は、Amazon QLDB が提供するものよりもはるかに幅広く監査のデータポイントをキャプチャします。Aurora は Amazon QLDB のように DML イベントと DDL イベントを報告しますが、接続、ロールと権限の変更、関数の実行、バキュームやチェックポイントなどのユーザー開始操作も報告します。Database Activity Streams と Amazon QLDB ストリームの主な違いは、Amazon QLDB はコミットされたトランザクションのアクションのみを報告するため、読み取り後にトランザクションをキャンセルすることで、ユーザーが検出されない読み取りを実行できることです。Aurora は、コミットされていないトランザクションも含め、すべてのアクションをアクティビティストリームに報告します。 Database Activity Streams は、データベース管理者のアクティビティの信頼できるログを提供します。Aurora クラスターのアクティビティストリームのアクティベーションはデータベースの外部で実行され、その操作へのアクセスはデータベース権限ではなく IAM 権限によって制御されます。データベース管理者には、監査データの収集や Kinesis Data Stream への公開を妨げるだけの十分なアクセス権がありません。また、データベース管理者は Kinesis Data Stream 内の監査データにアクセスできないため、そのデータの処理を妨害することはできません。 Amazon QLDB では、基礎となるジャーナルにはコミットされたすべてのトランザクションの不変なレコードが格納されます。ジャーナルのトランザクション履歴には、テーブルの history() 関数をクエリするか、Kinesis Data Streams を介してジャーナルを再ストリーミングすることで、いつでもアクセスできます。この機能は Database Activity Streams には存在しません。 ストリーミングされた監査データの有効期限が切れると、そのデータは失われます。監査データを保持するには、Amazon Data Firehose を使用してストリーミングされた監査イベントを 、Amazon S3 に保存することで無期限に保持できます。「 Filter Amazon Aurora database activity stream data for segregation and monitoring 」という投稿では、Firehose を使用して監査イベントをフィルタリングして Amazon S3 に送信して長期保存するソリューションを記載しています。 pgAudit と Aurora Database Activity Streams による監査の詳細については、「 Part 1: Audit Aurora PostgreSQL databases using Database Activity Streams and pgAudit 」を参照してください。 まとめ この投稿では、監査機能および変更履歴機能を提供する Amazon Aurora PostgreSQL の機能について説明しました。この機能は、監査ユースケース向けに Amazon QLDB が提供する独自の機能の一部に取って代わることができます。 次の記事「 Amazon QLDB のAmazon Aurora PostgreSQL への移行 」では、Amazon QLDB 台帳から Amazon Aurora PostgreSQL にデータを移行するのに役立つソリューションを提供します。 台帳移行の計画や、Amazon Aurora PostgreSQL が台帳データの適切な保存先であるかどうかの判断については、AWS の担当者にお問い合わせください。 著者について Dan Blaner は、台帳とリレーショナルデータベースを専門とするプリンシパルソリューションアーキテクトです。彼は学ぶこと、物事を理解すること、他の人が物事を理解するのを助けることを楽しんでいます。休みはベースを弾き、仲の良い友達とbad music 作りを楽しんでいます。

はじめに 6 月 20 日と 21 日の 2 日間にわたり、幕張メッセにおいて 13 回目となる AWS Summit Japan が「AWS と創る次の時代」をテーマに開催され、会場では 3 万人以上、オンラインも合わせると過去最高となる 5 万人超の方の参加者を記録しました。私たちは 2 年目の新入社員有志でチームを作り、&nbsp;“ 新入社員プロジェクト生成AI を活用した&nbsp;Virtual Summit Assistant ” というタイトルでブース展示を行いました。当日は絶えず沢山の来場者の方々にブースにお越しいただき、アプリケーションを体験していただきました。このブログでは、“ 新入社員プロジェクト生成AI を活用した&nbsp;Virtual Summit Assistant ” の展示内容をダイジェストでご紹介します。展示に使われている AWS サービスやアーキテクチャの詳細な紹介については個別の解説ブログを発行予定です。 “新入社員プロジェクト生成 AI を活用した Virtual Summit Assistant” とは 展示内容の説明に入る前に、まず私たちがどのような課題から今回の展示作成に至ったのかについてお話しします。以前 AWS Summit に参加した際にAWS Summit に来場者として訪れた際に感じた 2 つの課題がありました。1 つ目は、会場が広く、目的地に辿り着けないということです。Summit 会場では 250 を超える展示があり、自分が見たいブースがどこにあるのかわからないことがありました。2 つ目は「どのセッション・ブースを訪ればいいのかわからない」というものです。去年 Summit に参加した際、入社数ヶ月だった私たちは、AWS に関する知識がまだ浅く、様々なセッションやブースの中から、自分の興味分野やレベルにあったものを探すのは難しかったため、自分の好みを反映したおすすめを教えてほしいという声がありました。 そこで私たちはアバターが Summit 会場の案内とおすすめセッションを教えてくれる Virtual Summit Assistant を開発しました。このプロダクトは画像のようなアバターに今回の AWS Summit に関する情報、例えばセッションやブースに関する質問をすることで、回答を返してくれるバーチャルアシスタントです。 この展示のアーキテクチャは以下のようになっています。 Virtual Summit Assistant の中心は、 Amazon Simple Storage Service &nbsp;(S3)、 Amazon Kendra 、 Amazon Bedrock &nbsp;を用いた検索拡張生成 (RAG, Retrieval Augmented Generation) です。Web ユーザーインターフェースは、 Amazon CloudFront と Amazon S3 によって提供されています。アーキテクチャは、 Amazon Cognito 、 Amazon Transcribe 、 Amazon Polly などの複数のマネージドサービスによってサポートされています。Web ユーザーインターフェースは、ユーザー登録と認証用のための&nbsp; Amazon Cognito 、 Amazon Transcribe &nbsp;と&nbsp; Amazon Polly &nbsp;を用いて入力音声の書き起こしと回答文を音声出力へ変換しています。 検索拡張生成 (RAG, Retrieval Augmented Generation) は、大規模言語モデルで回答の精度を向上させるための手法です。RAG を使わない構成ではユーザーが基盤モデルに何か質問をする際、ユーザーはアプリを介して質問を送り基盤モデルが質問内容を受け取って回答を生成しますが、この方法では基盤モデル学習時に学んだデータを元に回答を生成するため、学習をしていない知識、例えば今回の Summit に関する情報や、外部公開されていない企業独自の情報は回答できません。そのような課題の解決に有効なアプローチが RAG になっています。 RAG では従来の構成に加えてナレッジソースと呼ばれるデータソースを用意します。ナレッジソースには、基盤モデルが回答を生成する際に参考にしてほしいデータを入れておきます。ユーザーが質問した際は、一旦ナレッジソースに問い合わせを行い質問に関連するデータを抽出します。そして、抽出したデータとユーザーからの質問を合わせて基盤モデルに送信し、基盤モデルはナレッジソースのデータを参考にしながら回答を生成します。こうすることで、基盤モデルは学習していないデータに関しても正確な情報を回答できるようになります。今回の場合はナレッジソースとして&nbsp;Amazon S3 を使用し、Amazon S3 内に Summit のセッションやブースに関する情報を txt 形式で格納しています。 Generative AI Avatar Chat を用いた開発 今回の開発ではアーキテクチャの設計や開発を、一から行った訳ではなく Generative AI Avatar Chat と呼ばれるサンプルアプリケーションをもとにカスタマイズを加える形で行いました。このサンプルアプリケーションを使うと、3D アバターをインタフェースとして持つ生成 AI チャットボットを簡単に構築できます。デフォルトで RAG の構成も実装されるため、情報を追加することで専門知識や社内情報を含めた回答を行うことも可能です。質問文の入力には文字または音声を利用可能です。こちらのアプリケーションコードは AWS リソースを用いたソリューションを提供している AWS Samples にて公開されており、AWS CDK のデプロイにより数ステップで構築ご利用いただけます。 今回のプロジェクトは、業務の合間時間を使いながら約 3 ヶ月で完成させなければならないというタイトなスケジュールでしたが、このようなサンプルアプリケーションをベースに、自分たちでカスタマイズを加えることで短い期間でも開発を行うことができました。 ブース紹介 当日は絶えずたくさんの来場者の方々にブースにお越しいただきました。著者も当日ブース対応を担当しました。このアシスタントは会場内の 5 箇所、計 9 台の Kiosk 端末で設置しました。お客様からは、「このようなアシスタントが案内してくれると、店舗人員を減らせてよい。」「アバターと RAG で使用するドキュメントを変えるだけで様々な環境やユースケースに対応可能で良い。」や、「新卒が業務の合間にここまで作れるなんて、自分たちのカリキュラムにも組み込みたい。」など、アプリケーションや新入社員プロジェクトなど、様々な側面からフィードバックをいただきました。 最後に 以上、私たちが本展示の開発過程、主な機能、Summit 当日の様子をご説明しました。最後に新入社員開発プロジェクトを通して学んだことを 3 つご紹介します。1 つ目はチーム内外とのコミュニケーションです。Summit という大きなイベントでのブース展示、登壇を行う過程で非常に多くの方にご協力いただきました。その中で開発における役割分担、議論の記録の取り方、複数人でコミュニケーションを取る場合の文書化の重要性など、多くの人を巻き込んだプロジェクトにおけるコミュニケーションの取り方について学びを得ました。2 つ目として新年度から開発がスタートした本プロジェクトは日々の業務の両立をどう行うのか、特に各メンバーの役割と進捗の管理など、プロジェクトのマネジメントに関する経験がとして得られました。 最後はユーザ目線の開発経験です。開発経験の少ない新卒メンバーが、Summit ユーザーの視点を元にした課題定義、発案、開発までの一連の流れを体験することができたのは、ペインポイントの整理からニーズベースでの開発という意味で大きな経験になりました。 開発メンバーとブースの様子 今回、開発したVirtual Summit Assistant は空港、ショッピングモール、病院、イベント会場などの施設案内を必要とするような場所への導入が考えられます。自然言語により質問が可能なため、ユーザーはより自分の希望に合った案内を受けることができますし、アバターや音声入力といった親しみやすさにより、小さなお子様や高齢者の方も簡単にご利用いただくことが可能です。このような商業施設への導入という観点では、さらなる追加機能の例として、アクセスするデータソースや API の種類を増やすことで、情報提供の幅を増やす。例えば、混雑情報のようなリアルタイムで変化する情報の提供などから、レストラン予約といったアクションをこのアバターが推薦できるなどが新機能として考えられます。 実際に Summit に参加されたお客様から、「案内板に付加価値をつけることが可能。イベントで使用したい。」「無人店舗を検討中のため使用してみたい。」などのフィードバックをいただきました。このように様々なユースケースで使用していただけるのではないかと思っています。このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWS 担当営業もしくはこちらの窓口 ( https://aws.amazon.com/jp/contact-us/ )までご連絡ください。 著者について 松本 敢大 (Kanta Matsumoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。 好きな AWS サービスは AWS IoT Core。 趣味はカメラで、犬が好きです。 &nbsp; &nbsp; &nbsp; &nbsp; 中本 翔太 (Shota Nakamoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は飲食、旅行など、サービス業のお客様を中心に技術支援を行っています。 好きな AWS サービスは Amazon Bedrock。 &nbsp; &nbsp; &nbsp; &nbsp; 大久保 裕太 (Yuta Okubo) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は不動産、建設業のお客様を中心に技術支援を行っています。 好きな AWS サービスは Amazon Kinesis Video Streams と Amazon Braket。 &nbsp; &nbsp; &nbsp; &nbsp; 池田 優 (Yu Ikeda) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は金融業のお客様を中心に技術支援を行っています。 好きな AWS サービスは&nbsp;Amazon Elastic Compute Cloud。 &nbsp; &nbsp;

前回の Amazon プライムデー 2024 (7 月 17～18 日) は、 Amazon にとって過去最大のプライムデーショッピングイベント となり、記録的な売上高を達成するとともに、2 日間のイベントでこれまでのどのプライムデーイベントよりも多くの商品を販売しました。プライム会員は、世界中 35 を超えるカテゴリー全体で何百万ものお買い得商品を購入し、数十億に及ぶ金額を節約しました。 私は韓国に住んでいますが、プライムデー 2024 開催中は幸運にもシアトルにいたので、 AWS Heroes Summit に参加することができました。私は、 プライムメンバーシップ にサインアップし、私の新しい AI 駆動の会話型ショッピングアシスタントである Rufus を使用して、商品をすばやく簡単に検索しました。私のような米国のプライム会員は、プライムデー開催中に何百万もの注文の配送をまとめることを選択して、推定 1,000 万回分の配達の手間を省きました。配送をまとめることにより、平均的な二酸化炭素排出量も低減します。 Jeff が毎年投稿するブログ記事からわかるように、これらの短期間で大規模なグローバルイベントを実現可能にする Amazon ウェブサイトとモバイルアプリは、AWS が実行しています (Jeff の 2016 年 、 2017 年 、 2019 年 、 2020 年 、 2021 年 、 2022 年 、および 2023 年 の記事で振り返ってみましょう)。今日は、私の素晴らしいショッピング体験を可能にした AWS の最高数値を皆さんと共有したいと思います。 数値で見るプライムデー 2024 最も興味深いメトリクスと、驚異的なメトリクスをいくつか紹介します。 Amazon EC2 – Rufus や Search などの Amazon.com サービスの多くは内部で AWS 人工知能 (AI) チップを使用しているため、Amazon はプライムデーのために 8 万個を超える Inferentia と Trainium のチップ群をデプロイしました。プライムデー 2024 の開催中、Amazon は 25 万個以上の AWS Graviton チップを使用して、5,800 を超える個別の Amazon.com サービスを稼働させました (2023 年の 2 倍)。 Amazon EBS – プライムデーをサポートするため、Amazon は 2024 年に 264 PiB の Amazon EBS ストレージをプロビジョンしました。これは、2023 年と比較して 62% の増加になります。Amazon EBS での Amazon.com のパフォーマンスをプライムデー 2024 の前日と比較すると、イベント開催中は読み取り/書き込み I/O 操作が 5 兆 6,000 億件へと急増し、プライムデー 2023 との比較では 64% の増加になります。また、プライムデー 2024 の前日と比較すると、イベント中に Amazon.com が転送したデータは 444 ペタバイト増加し、プライムデー 2023 との比較では 81% の増加になります。 Amazon Aurora – プライムデーでは、Amazon Aurora の PostgreSQL 対応エディションと MySQL 対応エディションを実行する 6,311 個のデータベースインスタンスが 3,760 億件を超えるトランザクションを処理し、2,978 テラバイトのデータを保存して、913 テラバイトのデータを転送しました。 Amazon DynamoDB – DynamoDB は、Alexa、Amazon.com サイト、およびすべての Amazon フルフィルメントセンターを含めた複数の高トラフィック Amazon 施設とシステムの原動力となっています。プライムデーの期間中、これらのソースは DynamoDB API に対して数十兆回に及ぶ呼び出しを行いました。DynamoDB は、1 桁ミリ秒のレスポンスを提供し、ピーク時には 1 秒あたり 1 億 4,600 万件のリクエストを処理しながら、高可用性を維持しました。 Amazon ElastiCache – ElastiCache は、1 日で 1,000 兆件を超えるリクエスト (ピーク時には 1 秒あたり 1 兆件を超えるリクエスト) に対応しました。 Amazon QuickSight – プライムデー 2024 の期間中、プライムデーチームが使用した 1 つの Amazon QuickSight ダッシュボードでは 10 万 7,000 のユニークヒットと 1,300 を超えるユニーク訪問者が確認され、160 万件を超えるクエリを発行しました。 Amazon SageMaker – プライムデー開催中、SageMaker は 1,450 億件を超える推論リクエストを処理しました。 Amazon Simple Email Service (Amazon SES) – プライムデー 2024 の開催中、SES は Amazon.com のためにプライムデー 2023 よりも 30% 多い E メールを送信しました。これらの E メールのうち 99.23% がお客様に送信されたものです。 Amazon GuardDuty – プライムデー 2024 の開催中、Amazon GuardDuty は 1 時間あたりほぼ 6 兆件のログイベントを監視しました。これは前年のプライムデーと比較して 31.9% の増加になります。 AWS CloudTrail – AWS CloudTrail は、プライムデー 2024 をサポートするために 9,760 億件を超えるイベントを処理しました。 Amazon CloudFront – プライムデー 2024 の開催中、CloudFront は 1 分あたり 5 億件を超える HTTP リクエストのピーク負荷を処理し、HTTP リクエストの総数は 1 兆 3,000 億件を超えました。これは、プライムデー 2023 の総リクエスト数と比較して 30% の増加になります。 スケールするための準備 Jeff が毎年指摘しているように、プライムデーやその他の大規模イベントの成功の鍵は、徹底した準備です。例えば、耐障害性をテストし、プライムデーで Amazon.com が高可用性を維持できることを確実にするために、 AWS フォールトインジェクションサービス 実験が 733 回実施されました。 これに類似するビジネスクリティカルなイベント、製品リリース、および移行に向けて準備を進めているという場合は、新たにブランド化された AWS Countdown の活用を強くお勧めします。このサービスは、プロジェクトライフサイクル向けに設計されたサポートプログラムで、AWS エキスパートが開発した実証済みのプレイブックを使用して、運用準備状況の評価、リスクの特定と緩和、およびキャパシティの計画を行います。例えば、AWS Countdown からの追加のサポートを利用して、問題を最小限に抑えながら 450 台のサーバーの移行を成功させた Legal Zoom は、現在も AWS Countdown Premium を活用して SaaS アプリケーションのリリースを合理化し、迅速化しています。 2025 年も、どのような記録が破られるか本当に楽しみです! – Channy &amp; Jeff ; 原文は こちら です。

VP of AI and Data である Swami Sivasubramanian 博士が 2005 年に Amazon でインターンをしていたとき、Amazon の CTO である ワーナー ヴォゲルス 博士が最初の上司でした。19 年の時を経て、2 人は VivaTech Conference で同じステージに立ち、Amazon のイノベーションの歴史 ( Amazon Web Services (AWS) での従量制料金モデルの開拓から、「古き良き AI」を使用したカスタマーエクスペリエンスの変革まで) と、 生成人工知能 (生成 AI) の時代に 2 人を夜眠れなくさせるものについて振り返りました。 競合他社のことを考えて夜眠れなくなったことがあるかとたずねられたヴォゲルス博士は、ガードレール、セキュリティ、プライバシーなどのお客様のニーズに耳を傾け、それらのニーズに基づいて製品を構築することが Amazon の成功の原動力であると主張しました。Sivasubramanian 博士は、 Amazon SageMaker と Amazon Bedrock を、このお客様第一のアプローチの結果として生まれた、成功した製品の代表例とみなしていると述べました。「競合他社を追いかけると、競合他社が構築しているものを構築することになります」と Sivasubramanian 博士は付け加えました。「実際にお客様の声に耳を傾ければ、実際にイノベーションをリードすることになるのです」。 お客様中心のイノベーションに関するさらに 4 つの教訓については、 AWS キャリアブログ にアクセスしてください。 例えば、弊社はお客様中心のセキュリティのために、サイバー脅威を検出して対応するための強力なニューラルネットワークモデルである Mithra を構築して使用しています。このモデルは、AWS グローバルネットワークからの 1 日あたり最大 200 兆件のインターネットドメインリクエストを分析し、平均 182,000 件の新たな悪意のあるドメインを驚くべき精度で特定します。Mithra は、AWS がグローバルスケール、高度な人工知能と機械学習 (AI/ML) テクノロジー、そして継続的なイノベーションを活用して、クラウドセキュリティをリードし、インターネットを誰にとってもより安全なものにしている一例にすぎません。詳細については、Amazon の Chief Information Security Officer である CJ Moses のブログ記事「 How AWS tracks the cloud’s biggest security threats and helps shut them down 」にアクセスしてください。 8月5日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Bedrock の Amazon Titan Image Generator v2 – 新しい Amazon Titan Image Generator v2 モデルを使用すると、テキストプロンプトと参照画像を使用して画像作成をガイドしたり、生成された画像のカラーパレットを制御したりできるほか、背景を削除し、モデルをカスタマイズしてブランドスタイルと主題の一貫性を維持することもできます。詳細については、私のブログ記事「 Amazon Bedrock で Amazon Titan Image Generator v2 が利用可能に 」にアクセスしてください。 Amazon Bedrock における Anthropic の Claude モデルのリージョンレベルの拡張 – Anthropic の最新の高性能 AI モデルである Claude 3.5 Sonnet が、米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (東京)、アジアパシフィック (シンガポール) リージョンにおいて、Amazon Bedrock でご利用いただけるようになりました。Anthropic の手頃な料金で使用できるコンパクトな AI モデルである Claude 3 Haiku が、アジアパシフィック (東京) およびアジアパシフィック (シンガポール) リージョンにおいて、Amazon Bedrock でご利用いただけるようになりました。 VPC およびサブネットのプライベート IPv6 アドレス指定 – Amazon VPC IP Address Manager (IPAM) を使用して、VPC およびサブネットのためにプライベート IPv6 をアドレス指定できるようになりました。IPAM 内では、プライベートスコープでプライベート IPv6 アドレスを設定して、ユニークローカル IPv6 ユニキャストアドレス (ULA) とグローバルユニキャストアドレス (GUA) をプロビジョニングし、それらを使用してプライベートアクセスのために VPC とサブネットを作成できます。詳細については、「 Understanding IPv6 addressing on AWS and designing a scalable addressing plan 」および VPC ドキュメント にアクセスしてください。 Amazon EFS の最大 30 GiB/秒の読み取りスループット – 読み取りスループットを 30 GiB/秒に増加し、Amazon EFS のシンプルかつ完全に伸縮自在でプロビジョニング不要のエクスペリエンスを拡張して、モデルトレーニング、推論、財務分析、ゲノムデータ分析のための、大量のスループットを伴う AI および ML ワークロードをサポートします。 Amazon Redshift ML の大規模言語モデル (LLM) – Amazon Redshift ML の一部として、 Amazon SageMaker JumpStart で事前トレーニング済みの公開 LLM を使用できます。例えば、LLM を使用してフィードバックを要約したり、エンティティ抽出を実行したりできるほか、Amazon Redshift テーブルのデータに対して感情分析を実施することもできるため、データウェアハウスに生成 AI のパワーをもたらすことができます。 Amazon DataZone のデータ製品 – Amazon DataZone でデータ製品を作成できます。これにより、特定のビジネスユースケースに合わせてカスタマイズされた、明確に定義された自己完結型パッケージにデータアセットをグループ化できます。例えば、マーケティング分析データ製品では、マーケティングキャンペーンデータ、パイプラインデータ、顧客データなど、さまざまなデータアセットをバンドルできます。詳細については、 AWS ビッグデータブログの記事 にアクセスしてください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 Jeff Barr による AWS Goodies – AWS に関するもっとエキサイティングなニュースを知りたいですか? Jeff Barr は常に最新情報をキャッチアップモードで提供しており、自ら見つけたり、共有されたりしたすべての興味深い情報を共有できるよう最善を尽くしています。Goodies は週に 1 回の頻度で掲載されます。 Jeff の LinkedIn ページ をフォローしましょう。 AWS とマルチクラウド – AWS の既存の機能と、マルチクラウド環境における継続的な強化についての優れた記事をぜひお読みください。この記事では、Jeff がマルチクラウドに対する AWS のアプローチについて説明し、実際の例をいくつかご紹介するとともに、AWS サービスのラインナップ全体における最新のマルチクラウドおよびハイブリッド機能のいくつかをレビューしています。 Amazon Q Developer でのコード変換 – Amazon では、 Amazon Q Developer Agent for Code Transformation を使用して 30,000 を超える本番アプリケーションを古い Java バージョンから Java 17 に移行するよう、小規模なチームに依頼しました。Amazon Q Developer を利用してこれらのアップグレードを自動化することで、チームは、これらのすべてのアップグレードを手動で行う場合にかかったであろう労力と比較して、4,500 年超に相当するデベロッパーの労力を削減し、最新の Java バージョンに移行することで、会社全体で年間 2 億 6,000 万 USD のコスト削減を実現しました。 AWS CDK への貢献 – AWS Cloud Development Kit (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK に貢献することは、AWS サービスの知識を深めるのに役立つだけでなく、コミュニティへの貢献や、使用しているツールの改善にもつながります。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent 2024 – 第 1 ラウンドのセッションカタログ をご覧ください。今年の AWS re:Invent でのさまざまな学習機会のすべてを詳しく確認し、今すぐアジェンダの作成を開始しましょう。あらゆる関心と学習スタイルに合ったセッションが見つかるでしょう。 AWS Innovate Migrate, Modernize, Build – ワークロードを AWS クラウドに効果的に移行し、アプリケーションをモダナイズして、クラウドネイティブで AI 対応のソリューションを構築するための実証済みの戦略と実用的なステップについて学びましょう。エキスパートと一緒に学び、AWS の可能性を最大限に引き出すこの機会をお見逃しなく。今すぐ アジアパシフィック、韓国、日本 (9 月 26 日) に登録しましょう。 AWS Summits – 2024 年の AWS Summit シーズンが終わりを迎えようとしています。 クラウドコンピューティングコミュニティがつながり、コラボレーションして、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください: サンパウロ (8 月 15 日)、 ジャカルタ (9 月 5 日)、 トロント (9 月 11 日)。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 ニュージーランド (8 月 15 日)、 コロンビア (8 月 24 日)、 ニューヨーク (8 月 28 日)、 ベルファスト (9 月 6 日)、 ベイエリア (9 月 13 日) です。 AWS GenAI Lofts – AWS AI のエキスパートとつながり、業界のリーダーによる講演、ワークショップ、Fireside Chat、質疑応答に参加しましょう。すべての Loft は無料で、AI ジャーニーの加速に役立つよう、あらゆる参加者が何かを得られるように、細心の注意を払って厳選されています。Loft は、 サンフランシスコ (8 月 14 日～9 月 27 日)、 サンパウロ (9 月 2 日～11 月 20 日)、 ロンドン (9 月 30 日～10 月 25 日)、 パリ (10 月 8 日～11 月 25 日)、 ソウル (11 月) で開催される予定です。 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 8月12日週はここまでです。8月19日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup &nbsp;シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。

複数の拠点に工場やプラントを持つ企業では何千もあるモーターやポンプなど設備の保全タイミング管理は操業品質とコストに影響する重要な課題です。 AWS Japan ソリューションアーキテクトチームはこの課題に対するソリューションのデモを開発しました。 このブログは デモ解説の Part 2として、利用している各サービスの役割、デモ開発のための工夫と実運用へ適用するための検討点を解説します。 開発したデモのサービス構成 Part 1 で解説したデモのユーザーストーリーを決めた後、私達はデモを行うための設計を開始しました。 デモ特有の要件として、 Monitron のセンサー状態を任意のものに変更したり、ダッシュボード上へニアリアルタイムにデータを反映し、連携する機器に即時通知するといった必要があるため、私達は新たな設計を行い、その解決にチャレンジしました。下の図はデモで開発した多拠点予兆保全ダッシュボードのハイレベルアーキテクチャです。 (図: 多拠点予兆保全ダッシュボードのハイレベルアーキテクチャ) Part 2では各コンポーネントに焦点をあてて、デモでの役割と仕組みを説明します。 Amazon Monitron センサーと Amazon Monitron ゲートウェイによる撹拌機の測定 Monitron センサーと Monitron ゲートウェイは、今回のイベントに展示するミニチュアファクトリーの１つである「 プロセス工場 」に設置しました。工場の中に連続稼働する撹拌機をつくり、そのモーターに Monitron センサーを取り付けました。センサーが測定したデータは柱に取り付けられた Monitron ゲートウェイへ BLE (Bluetooth Low Energy) で送信され、Monitron ゲートウェイはそれを Wi-Fi でインターネット上の Monitron サービスへ送信します。このデータは Monitron アプリでデモ会場内から確認できます。 (図: Monitron 実機を設置するミニチュアプロセス工場) このデモは多拠点設備の一元管理をテーマにしていますが、イベントで展示するすべてのミニチュアファクトリーに Monitron センサーを取り付けるのはサイズなどの問題もあり困難でした。そこで、 3D プリンターを用いてミニチュアサイズの Monitron センサーのモックを作り、それを各工場のモーターやポンプに貼り付けました。 これにより、Monitron センサーの設置イメージをわかりやすくご理解いただけます。このミニチュア Monitron センサー はとてもかわいらしいのですが、非売品です。またセンサー機能はありません。 (図: Monitron センサーとミニチュア模型) (図: 複数の工場の設備に Monitron が設置される様子をミニチュアで表している) AWS IoT SiteWise によるデータの収集 (図: AWS IoT SiteWise によるデータの収集) AWS IoT SiteWise は産業データの収集・整理・分析を簡素化するマネージドサービスです。Monitron からのデータを保存・分析にするには Amazon S3 に保存し、 AWS Glue などの ETL サービスで前処理と型付けを行った後に Amazon Athena などで分析することが考えられますが、今回は以下の理由から　AWS IoT SiteWise を採用しました。 収集から表示までの時間を短縮する ：通常 Monitron はセンサー 1 台あたり 1 時間に 1 回の頻度でデータを送信します。分析の目的は不良予兆の検知ですから、短い時間の対応は多くの場合必要なく、数時間から 1 日に 1 回といった頻度のバッチ処理で分析すれば十分です。しかし、デモではデータ送信から結果の報告までを数秒から数分といった短い時間内に表現する必要があるため、Amazon S3 と AWS Glue を使ったデータレイク的な構成は適しません。AWS IoT SiteWise であれば、AWS IoT SiteWise API を用いて、Monitron から Amazon Kinesis Data Streams に送信されたデータを AWS Lambda で取得しニアリアルタイムで AWS IoT SiteWise 内に収集・蓄積できます。 アセット管理機能 ： Amazon Monitron はアプリケーション内でサイトや設備といったアセットを管理します。AWS IoT SiteWise はデータをモデル化してアセットモデルを管理できるため、Monitron から受信したデータをアセットモデルのメトリクスとして収集・保存し、外部から AWS IoT SiteWise API でデータへアクセスできます。 Grafana 連携の容易さ ： Amazon Managed Service for Grafana には AWS IoT SiteWise との連携機能があり、Grafana から AWS IoT SiteWise 上のデータをノーコードで検索し可視化できます。 アラートからのイベント発生 ：AWS IoT SiteWise は収集したデータを変換・評価し、しきい値に応じてアラートを作成し、 AWS IoT Events を経由して他のサービスへイベントを生成できます。 API による他サービスとの連携 ：AWS IoT SiteWise は API をもち、蓄積したデータを他のサービスから API 経由で検索したり、 AWS IoT Analytics を用いて SQL で分析できます。 また、 AWS IoT TwinMaker と連携してデジタルツインを実現することも容易です。 AWS IoT Events によるイベント発生 外部のサービスや装置と連携するには、データに基づいて判定し、外部サービスを操作するイベントを発生させる必要があります。 AWS IoT Events は機器またはデバイスの障害や動作の変更を状態遷移としてモニタリングし、状態変化にあわせてイベントを発生させ、必要なアクションを起こすことができるサービスです。 デモでは AWS IoT SiteWise からのデータから、信号灯を点灯させるためのイベントと、チャットツールへ投稿するイベントを生成します。 AWS Chatbot によるチャット通知 (図: AWS Chatbot による通知) 現場の保守担当者へ保全が必要であることを通知するために、チャットツール (今回は Slack)を用いました。AWS Chatbot は AWS のイベントに応じてチャットツール (Slack や Teams) に投稿を行うことができます。また、チャット画面で AWS CLI のコマンドや AWS Lambda 関数の実行を指示することができます。 このデモでは、保守要請のポストに対して、保守担当者が「私が担当します！」ボタンを押すことで、保守担当者がアサインされる想定にしました。 また、ボタン押下に応じて、イベントの情報をチャット内に表示しています。カスタマイズによってより詳細な情報を表示するなどのワークフローも実現可能です。 信号灯による保守担当者への通知 (図: 信号灯による通知の仕組み) 監視拠点や工場の現場では、保守担当者が常時ダッシュボードをチェックしつづけることは困難です。多くの現場では信号灯の点灯や鳴動によって現場の異常を作業員に知らせます。パトライト社製のネットワーク制御信号灯 NHV シリーズ は AWS 連携機能をもち、 AWS IoT Core からの MQTT 通信による指示に応じて簡単に信号の点灯などの制御が可能です。制御と連携方法の詳細は以下の AWS ブログをご覧ください。 Amazon Monitron とパトライト社の信号灯で、設備異常の予兆を逃さない保全を実現 エミュレータによる仮想的な複数設備の状態変化 イベントには多くの来場者が訪れます。多くの来場者は 1 つの展示に多くの時間をかけて説明を聞くことはできません。 一方、予兆保全は比較的長い時間 (数週間から数か月、場合によっては数年) にわたって行う運用です。 Amazon Monitron はセンサーから 1 時間に 1 回の頻度で情報を送るためダッシュボードが頻繁に変化することはありません。また実際には短い期間に頻繁に不具合を通知することはまれです。そこで不具合発生時の運用をデモンストレーションするために私達は Monitron のデータを生成するエミュレーターアプリケーションを開発しました。 このアプリケーションは内部的に複数の Monitron センサーのように振る舞い、アプリ画面のボタンを押すことで、データを送信します。 (図: Monitron エミュレーターによる予兆検知のデモンストレーション ) 実際の大規模な設備保全に適用するための検討ポイント 私達はデモの短い時間に効果を表現するために、スケーラビリティよりもリアルタイム性にこだわった設計を採用しました。多拠点・大規模な設備群の予知保全を管理する場合、今回開発したデモンストレーションのアーキテクチャは参考になるでしょう。一方で、商用環境では長期間に多数・多品種の設備を管理することが必要ですし、運用はより複雑です。このデモを気に入ったユーザーが商用環境に同様のソリューションを構築しようと考えた時に役に立つ代表的な考慮事項を以下に記載します。 スコア集計および分析機能の強化 何千ものアセットの状態からスコアを求めるには、よりスケーラブルな分析機能を使う方が良いでしょう。AWS IoT SiteWise は多数の産業設備から得るデータを収集し、設備毎に変換・評価することに優れたサービスです。一方、複数の設備から得たデータを集計・分析するには他のサービスと連携したほうが効率的な場合があります。このデモでは AWS IoT SiteWise で集計する方式と、リアルタアイム性を向上させるために AWS Lambda を用いて集計する方式を併用しました。 より大規模な集計・分析を要する場合は、AWS IoT SiteWise と連携可能な分析サービス (例えば Amazon Athena 、 AWS Glue 、 AWS IoT Analytics ) を用いて SQL による分析を行ったり、集計結果を Amazon Aurora のような RDBMS や Amazon Timestream のような時系列データベースへ保存することでより高度で大規模な分析に対応することができます。 保守を推奨するための基準を設定する機能 ユーザーの環境はさまざまです。商用利用においては、ユーザーの環境に合わせて保守推奨の基準を変更できる機能が必要です。このデモでは拠点とプロジェクト全体に対して、健全性を表すスコアを定義し、その値に基づいて保全を推奨するイベントを発生させました。このスコア算出方法は Monitron から出力される状態をもとに設備毎のスコアを決定しました。その後、拠点のスコアは拠点内の設備スコアの平均値を採用しました。プロジェクトスコアは最も保全を必要とする拠点の状態を優先して評価するために最もスコアの低い拠点の拠点スコアをプロジェクトスコアとして評価しました。商用環境に割り当てる基準スコアや拠点スコア・プロジェクトスコアの算出方法は管理する対象設備や運用、規模によって考慮する必要があります。さらに、運用性を考えると、このスコア設定を管理者が変更可能にする管理機能を具備することが望ましいです。 他システムとの API 連携 今回はシンプルなワークフローを用いましたが、大規模なワークフローのためには他のシステムとの統合が必要です。このデモでは AWS の外部にある装置やシステムと連携することを示すために信号灯とチャットサービスを連携しました。同様の仕組みを使うことによって、ユーザーが利用する他のシステム、例えば EAM (Enterprise Asset Management : 設備資産管理) システムやワークフロー管理システム、そして ERP (Enterprise Resources Planning) システムへ状態の変化を送り、部品の調達や人員配置計画に活用することが考えられます。 以下の情報は EAM などの外部システムとの連携において参考になるでしょう。 AWS はガイダンス「 Amazon Monitron による予知保全のガイダンス 」、ブログ「 産業設備の予知保全サービス Amazon Monitron の紹介と、多拠点・大規模な設備群における保全効率化への取り組み 」、及びそれらの ソリューション実装 を公開しています。 SAP 社と AWS は「 AWS と SAP — Amazon Monitronを使用したIoTシナリオの共同リファレンスアーキテクチャ 」及びサンプル実装「 SAP BTP を使用して Amazon Monitron からのイベントを SAP S/4HANA と統合する 」を公開しています。 Amazon Monitron 以外のデータソースの統合 ユーザーが所有している別のデータソースを予知保全に活用することも検討する価値があります。実際、AWS Summit Japan 2024 の会場でこのデモを観たお客様からは、ポジティブなフィードバックとともに「Amazon Monitron に限らず、自社で利用している設備から取得できる情報も含めてこのような予知保全ダッシュボードを作りたい」というご意見を多くいただきました。 例えば多くの設備が PLC ( Programmable Logic Controller ) から情報を取得することができます。 AWS は PLC 等の工場・プラントにあるデータを AWS 上に蓄積するための IoT サービス (例えば AWS IoT SiteWise や AWS IoT Greengrass ) を提供します。 取得したデータから将来の不良予知を行うための、 機械学習サービス ( 例えば Amazon Sagemaker Canvas ) を提供しています。 AWS は Solutions Architect や Professional Service がお客様の課題を解決するご支援をします。また AWS 上でのシステム構築経験豊富な多くの AWS パートナーがいます。 おわりに このブログでは、 多拠点工場群設備の不良予知保全ダッシュボードデモ解説の Part 2 として、利用している各サービスの役割を解説しました。 2 回のブログを通じて、 Monitron の大規模適用についての課題とソリューション、また、それをデモとして見せていくための要件と対応について説明しました。 このブログについて このブログの内容は AWS Japan のソリューションアーキテクト 吉川晃平 、安田京太 、梶山 政伸 、三好史隆 、秦将之 、大井友三 が開発し、吉川晃平 が執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 お盆の期間ですが、AWSのサービスアップデートはたくさんリリースされています。5月のゴールデンウィーク頃から書き始めたこの週刊生成AI with AWSでは、毎週発表される生成AIに関するニュースをお届けしてきました。皆さんも実感していらっしゃると思いますが、生成AIは技術の進歩がとても早い分野です。新しいモデルもどんどん出てきますし、AWSのサービス機能追加もハイペースで行われています。もしお時間が取れるようであれば、「便利に使えそうなサービスがリリースされていたけど、見落としていた」というものがないか、振り返ってみるのはいかがでしょうか？週刊生成AI with AWSの記事も、 「週刊AWS」タグ を付けてありますので一覧で見やすくなっています。 「 AWSジャパン生成AI実用化推進プログラム 」も参加者の方を募集中です。こちらのほうも引き続き、よろしくお願いいたします。 それでは、8 月 12 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「LLM 社会実装を進める ELYZA 社: AWS Inferentia2 × Speculative Decoding の組み合わせは世界初、約 2 倍の推論速度を実現」を公開 AWS Startupブログ(日本語)で大規模言語モデル(LLM)の社会実装に取り組むELYZA様に関する記事が公開されています。700億パラメータのLLMである「ELYZA-japanese-Llama-2-70b」を開発したELYZA様ですが、チャット形式のデモサイトを提供しており、そのインフラ環境としてAWS Inferentia 2を搭載したインスタンスを活用しています。推論処理の高速化に利用されるSpeculative Decodingという手法をInferentiaで採用した事例としては世界初のものとなりますので、ぜひチェックしてみてください。 サービスアップデート Amazon EC2 G6eインスタンスが一般利用開始に NVIDIA L40S Tensor Core GPUを搭載したAmazon EC2 G6eインスタンスがご利用頂けるようになりました。G6eインスタンスはG5インスタンスと比較して最大2.5倍のパフォーマンスを発揮し、P4dと比較して推論ワークロードを最大20%安価に実行できます。13B規模の大規模言語モデル(LLM)や画像、動画、音声を生成する拡散モデルのデプロイに適しています。現時点ではバージニア、オハイオ、オレゴンのリージョンでご利用頂けます。 Amazon Connect Contact Lensが提供するエージェントのパフォーマンス評価機能が東京リージョンで利用可能に Amazon Connectではコンタクトセンターの分析と品質管理機能を強化するContact Lensという機能を用意しています。この機能では生成AIの技術を活用して、お客様対応を担うエージェントのパフォーマンスを評価する上での推奨事項や、お客様対応が適切かどうかを示すインサイトを提供します。これによってコンタクトセンターの対応品質のさらなる向上に繋げることが可能です。 Amazon Q in QuickSightが新たに5つのリージョンで利用可能に Amazon Q in QuickSightは、データからのインサイトの獲得や活用を容易にする生成AIアシスタントです。これを利用すると、データを解釈し説明する文書やビジネス上のアクションを推奨したり、スライドやエグゼクティブサマリーを生成することができます。今回、Amazon Q in QuickSightが新たにカナダ(中央)、ムンバイ、アイルランド、サンパウロ、ロンドンの5つのリージョンでご利用頂けるようになりました。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

株式会社カプコンは、近畿大学の学生を対象に、AWS のクラウドサービスを活用したゲーム開発の体験型授業を提供します ( プレスリリース )。この授業ではカプコンの自社開発ゲームエンジン「RE ENGINE」を AWS 上で利用し、ゲームの企画から実装まで一連の開発工程を実践的に学びます。産学連携によるこの取り組みを通じて、教育機関の発展と優秀な人材の育成を支援し、ゲーム業界全体の活性化につなげることを目指しています。 この記事では AWS のクラウドサービスが、体験型授業をどの様に支えているかについてご説明します。 「RE ENGINE」とは カプコンの自社開発ゲームエンジン「RE ENGINE」は、実写に匹敵するフォトリアルなグラフィックスを実現しながら、複雑な技術を開発者が簡単に扱えるよう工夫されています。これにより開発の効率化と品質の向上を両立し、世界で競争力のあるゲームタイトルの開発が可能となっています。常に進化を続けるこのエンジンは、カプコンの高品質なゲーム開発を支える中核的な存在です。 図 1: RE ENGINE ロゴ 図 2: RE ENGINE 画面 AWS の採用理由 ゲーム開発の体験学習には Unity など市販のゲームエンジンを使う事もありますが、今回の施策を開始する際、カプコンは「カプコンならではの授業はどの様な形が良いか」を考えました。その結果、普段自分達が実際の開発業務に利用し、常に改善を続けている「RE ENGINE」を授業に使うのが最良であると結論付けました。また実際のゲームに使われているアセットデータを利用し、ゲーム開発のプロフェッショナルと同じ開発工程を体験してもらおうと考えました。 しかし「RE ENGINE」は非公開のゲームエンジンであり、また実際のゲームに使用されているアセットを利用する為には、セキュリティや情報漏洩に細心の注意を払う必要がありました。そこでカプコンはクラウドサービスを利用する事で、安全にリモートアクセス可能で、更に参加者の PC スペックに依存せずに「RE ENGINE」を提供できる環境を構築する事にしました。カプコンでは以前から AWS を利用しており、AWS のクラウドサービスを用いてビルドプラットフォームを構築した経験 ( AWS Summit Tokyo 2023 セッション ) がありました。その際スケーリングやモニタリング、セキュリティの設定を柔軟に行えた実績があった事から、本件にも AWS が採用されました。 アーキテクチャ 体験型授業は以下のアーキテクチャで構成されています。 参加者は以下の手順で「RE ENGINE」を利用します。 参加者は自宅あるいは大学の教室から、 AWS Client VPN を利用してプライベートネットワークと安全な接続を確立します 次に管理用の Web ページから「RE ENGINE」をインストールした Amazon Elastic Compute Cloud ( Amazon EC2 ) を起動します EC2 が起動したら NICE DCV を使用して EC2 にリモートデスクトップ接続し、「RE ENGINE」を起動して学習を行います 使用するアセットは、同じプライベートネットワークで動かす Perforce サーバや FTP/SVN サーバから取得します 図 3: 体験型授業のアーキテクチャ図 以下で利用されている AWS サービスの詳細について説明します。 AWS Client VPN 参加者の PC からプライベートネットワークへの接続には AWS Client VPN を利用しています。これは AWS が提供するフルマネージドのリモートアクセス VPN ソリューションで、インターネット経由で企業の AWS リソースやアプリケーションに安全にリモートアクセスできます。接続数に応じて自動的にスケールアップ / スケールダウンする柔軟性も備えています。またアクセスログは AWS CloudWatch に記録され、外部からの不正アクセスを監視します。 Amazon EC2 実習用端末のインスタンスタイプは、「RE ENGINE」を動作させるのに必要な GPU を搭載した G4 インスタンスを使用しています。学習を快適に行える様配慮し、動作に十分なスペックを持つインスタンスサイズを指定しています。また多くのアセットデータを使用する為、ブロックストレージである Amazon Elastic Block Store ( Amazon EBS ) を 1TB 作業領域として追加しています。 アセットを保持するサーバには C5 インスタンスを使用しています。また高い性能を求められないサーバについてはより低コストな T3 インスタンスを使用しています。参加者の人数から同時接続数や負荷を想定し、コスト効率の良いインスタンスタイプ・インスタンスサイズを選定しています。 NICE DCV リモートデスクトップ接続には AWS が提供するソリューションである NICE DCV を利用しています。グラフィックスを最適化する独自のストリーミングプロトコルを持っており、HPC シミュレーションの視覚化から低レイテンシーを必要とする 3D グラフィックスを多用するアプリケーションまで幅広い用途に使用可能です。通信は暗号化されており、ファイル転送やクリップボードの共有機能を無効化する事で安全性をより高める事も可能です。 AWS Lambda EC2 の起動には AWS のサーバーレスコンピューティングサービスである AWS Lambda を利用しています。体験型授業の期間中は参加者が同じ EC2 インスタンスを継続して使用出来る様、管理端末から指定した EC2 インスタンスを起動する仕組みを構築しています。実行結果のログは AWS CloudWatch に記録されます。 セキュリティサービス 実習用端末と Client VPN のユーザ認証には AWS Managed Microsoft AD を利用しています。 Amazon GuardDuty で悪意のあるアクティビティや不正な動作を継続的に監視し、 AWS Config や AWS CloudTrail を利用して AWS インフラに施された変更や API 呼び出し履歴も追跡します。これらの監視結果は AWS CloudWatch に集約され、プライベートネットワーク内のあらゆる挙動を可視化しています。 まとめ カプコンと近畿大学の産学連携プロジェクトでは、AWS のクラウドサービスを活用することで、カプコン独自の「RE ENGINE」を用いたゲーム開発の体験型授業を実現しました。セキュリティを確保しつつ、スケーラブルで費用対効果の高いアーキテクチャを構築することで、優れた教育環境を提供できるようになりました。 今回の取り組みを通じて得られた知見を活かし、カプコンでは「RE ENGINE」を社内外問わず使える環境を目指しています。この産学連携はそのための第一歩となり、「RE ENGINE」の更なる発展と活用が期待されます。 AWS では多くのゲーム会社様が AWS のクラウドサービスを使ってゲームを開発・運用するための技術支援をしています。またこのブログを始め、CEDEC や GDC などのゲーム業界イベントや AWS 主催のイベント ( Game Tech Night ) などでゲーム会社様向けの情報を発信しています。私たちの活動がゲーム業界の発展に貢献できる様、今後も技術とビジネスの両面から全力でお客様をサポートしていく所存です。 著者 ( 敬称略 ) 伊集院 勝 株式会社カプコン 基盤技術研究開発部 基盤開発支援室 室長 山田 拓海 株式会社カプコン 基盤技術研究開発部 基盤技術開発室 エンジニア 長田 義広 アマゾン ウェブ サービス ジャパン合同会社 Game Techグループ インダストリーソリューション部 ゲームスペシャリスト シニアソリューションアーキテクト

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 早速ですが、先日開催されたAWS Builders Online Seriesのセッションが登録なしでご覧いただけるようになりました。 https://resources.awscloud.com/aws-builders-online-series-japanese ご参加できなかった方もこれを機にぜひご活用いただけますと幸いです。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月12日週の主要なアップデート 8/12(月) Amazon CloudWatch Internet Monitor enhances dashboard and traffic suggestions Amazon CloudWatch Internet Monitorのコンソールが新しくなりました。これにはアプリケーションのレイテンシーを短縮するのに役立つ設定変更を視覚化する新機能も組み込まれています。作成したモニターの概要ページには監視対象のすべてのトラフィックの統計がまとめられ、ヘルスイベントページにはエンドユーザーのトラフィックに影響を与える世界中のインターネットのヘルスイベント詳細が表示されます。今回新機能として最適化ページが追加され、ロケーション毎のレイテンシーを改善するための提案オプションを確認できたり、Amazon CloudFrontのレイテンシーを比較することもできます。詳細については ドキュメント をご確認ください。 Amazon Connect Contact Lens generative AI-powered agent performance evaluations (preview) now available in 6 new regions Amazon Connect Contact Lens が生成 AI を活用したエージェントのパフォーマンス評価機能(プレビュー)が新たに東京を含む新たに６つのリージョンで使えるようになりました。この機能は例えば「エージェントはネガティブな内容を伝えているときに共感を示したか?」のようにエージェントの対応に関するインサイトを取得し正確な評価を支援するものです。昨日の詳細に関しては ドキュメント をご確認ください。プレビュー中、この機能はContact Lensのパフォーマンス評価の料金で、追加料金なしで利用できます。 AWS Batch adds support for cancelling queued jobs AWS Batchがキューで待機中のジョブのキャンセルをサポートしました。実行前のジョブをキャンセルできることで、例えばフェアシェア（公平配分）スケジューリング機能を使用している場合、優先度が低いジョブをキャンセルして、他のユーザーが同じキューに送信したジョブが進行するためのスペースを確保できます。キューでの待機中にキャンセルされたジョブは FAILED 状態となります。この機能は、AWS Batchが利用可能なすべてのAWSリージョンで利用できます。詳細は ドキュメント をご確認ください。 8/13(火) Amazon DataZone launches domain units and authorization policies Amazon DataZoneにドメインユニットと認証ポリシーと呼ばれる新しいデータガバナンス機能が追加されました。ドメインユニットは”営業”、”マーケティング”などチーム毎に作成することで所有権を割り当て、データチームの構造をより詳細に管理できるようにします。これにより、ドメイン単位でカタログを検索したり、特定のビジネスユニットが作成したデータをサブスクライブできます。また、認証ポリシーを使用することでドメインユニットユーザーは、プロジェクトや用語集を作成したり、Amazon DataZone 内のコンピューティングリソースを使用したりするためのアクセスポリシーを設定できます。これらの機能は、Amazon DataZone が利用可能なすべての AWS リージョンで利用できます。詳細については、 ローンチブログ もご確認ください。 Announcing Amazon S3 Express One Zone storage class support on Amazon EMR Amazon S3 Express One Zone ストレージクラスが、すべての EMR デプロイモデル (EC2 の EMR、EKS 上の EMR、および Spark、Trino、Flink、Hive、HBase ワークロード向けの EMR サーバーレス) でサポートされました。Amazon S3 Express One Zoneは頻繁にアクセスされるデータや遅延の影響を受けやすいアプリケーションに1桁ミリ秒単位のデータアクセスを提供することを目的にした、単一アベイラビリティゾーン(AZ)のストレージクラスです。今回、EMRで対応したことで、S3との間のデータ移動を高速化できるようになり、ジョブの実行時間が短縮され、パフォーマンスが向上します。この機能はAmazon S3 Express One Zone ストレージクラスが利用可能なAWSリージョンでAmazon EMR 7.2.0 以降で利用可能です。詳細は EMR on EC2 、 EMR on EKS 、 EMR サーバレス 、それぞれのドキュメントをご確認ください。 Amazon Neptune Analytics now supports openCypher queries over RDF Graphs Amazon Neptune AnalyticsがRDF グラフ経由のOpenCypherクエリをサポートしました。グラフベースのアプリケーションを構築する際、これまではSPARQLを使用するRDFグラフと、GremlinとOpenCypherを使用するLPGのどちらかを選択する必要があり、利用しづらい原因の一つと捉えられ長年の課題でした。このような課題を解決する取り組みの一つとしてRDFモデルとLPGモデルの両方の長所を組み合わせて、RDFグラフに対してOpenCypherクエリを実行し、統合されたデータセット全体に強力なグラフアルゴリズムを適用できるようになりました。詳細に関してはこちらの ブログ や ドキュメント をご確認ください。 8/14(水) Announcing Karpenter 1.0 柔軟で高パフォーマンスなオープンソース KubernetesクラスターオートスケーラーのKarpenterがベータ版を卒業しバージョン1.0となりました。バージョン1.0リリースにあたり 1.中断理由（Underutilized、Empty、Drifted）ごとの中断制御の強化、2.お客様がアプリケーションの可用性とセキュリティ要件とのバランスを取るのに役立つ強制的な中断モード、3.低利用ノードの統合制御のため、consolidateAfterの機能拡張 などの新機能が追加されています。これらの機能およびその他の変更点の詳細については、 Karpenter 1.0リリースブログ 、 karpenter.sh または ドキュメント をご確認ください。 Amazon Redshift Query Editor V2 now supports query import Amazon RedshiftのクエリエディターV2にクエリインポート機能が追加されました。これによりコピー＆ペーストではなく単一/複数ファイル/フォルダをインポートすることで、ローカル環境で実行したクエリの実行や、複数人でシェアする作業を簡略化できます。 New capabilities for Amazon EC2 On-Demand Capacity Reservations: Split, Move, and Modify additional attributes Amazon EC2 オンデマンドキャパシティ予約に新たな機能が追加されました。オンデマンドキャパシティ予約は、特定のアベイラビリティーゾーンのワークロードのコンピューティングキャパシティを任意の期間予約できる機能で、確実なリソース利用をしやすくします。今回、キャパシティ予約を分割や、キャパシティ予約間で容量を移動、「オープン」と「ターゲット」のキャパシティ利用資格を切り替えることができるようになりました。これらの新機能は、すべてのAWS商業地域、中国リージョン (Sinnet が運営する北京リージョン、NWCD が運営、寧夏リージョン)、および AWS GovCloud (米国) リージョンので追加費用なしで利用できます。詳細については、 ドキュメント をご確認ください。 8/15(木) Announcing general availability of Amazon EC2 G6e instances NVIDIA L40S Tensor GPU を搭載した Amazon EC2 G6e インスタンスが一般提供開始されました。G6eインスタンスは最大8個のL40Sと第3世代AMD EPYC プロセッサが搭載されており、G5インスタンスと比較して最大2.5倍パフォーマンスが高く、P4dインスタンスよりも推論コストを最大20%削減できるため、機械学習と空間コンピューティングを中心に幅広いユースケースにご活用いただけます。Amazon EC2 G6e インスタンスは、バージニア北部、オハイオ、オレゴンの３つのリージョンで利用可能で、Amazon SageMaker のサポートも間もなく開始されます。 AWS Control Tower launches landing zone version selection AWS Control Towerでランディングゾーンのバージョン3.1を対象とし、ランディングゾーンの構成を更新またはリセットするときに、現在のバージョンをそのまま使用するか、新しいバージョンにアップグレードするかを選択できます。これにより環境の変更内容を評価しながら、より柔軟にバージョンアップグレードの計画を立てることが可能になりました。詳細については ドキュメント をご確認ください。 Amazon ECS provides the ability to restart containers without requiring a task relaunch Amazon ECSで柔軟なコンテナ再起動ポリシーを定義できるようになりました。これまでコンテナの再起動に際して、タスクを再起動が必要でしたが、今回の機能追加によりタスクを再起動せずともコンテナをローカルで再起動することができるようになり、コンテナの回復スピード向上とタスク全体の安定性が向上します。詳細は ドキュメント をご確認ください。 AWS CodeBuild now supports multiple access tokens via AWS Secrets Manager AWS CodeBuildでソースプロバイダー毎に複数アクセストークンの設定がサポートされました。OAuthまたはアクセストークンをAWS Secrets Managerに保存してCodeBuildプロジェクトから指定が可能です。これによりプロジェクトごとに権限の範囲を限定したトークンの使用ができるほか、CloudTrailから使用状況の監査、IAMロールとリソースポリシーによる利用ユーザーの制限など柔軟なセキュリティ対応が可能です。この機能はCodeBuildが提供されるすべてのリージョンで利用可能でGitHub、GitHub Enterprise, Bitbucketに対応しています。詳細は ドキュメント をご確認ください。 AWS CodeBuild now supports using GitHub Apps to access source repositories AWS CodeBuildがリポジトリアクセスの認証方法としてGitHub Appsと統合されました。GitHub Appsではきめ細やかな権限を持つ有効期間の短いトークンを利用でき、アプリケーションがアクセスできるリポジトリを制御できます。この機能はAWS CodeConnections（旧AWS CodeStar Connections）を介して接続します。この新機能は、中国 (北京)、中国 (寧夏) を除く、AWS CodeBuild がサポートされているすべてのリージョンで利用できます。詳細は ドキュメント をご確認ください。 8/16(金) Blueprints simplify agent-based automation on Amazon Bedrock Amazon BedrockでAgentのBlueprintを利用できるようになりました。これは一般的なユースケースに最適化されたビルド済みのテンプレート集で、複雑な開発をせずに簡単にAgentベースのアプリケーションをお試しいただけます。BlueprintはAWS QuickStart GitHub リポジトリで無料のオープンソーステンプレートとして公開されており、作成したリソースの料金のみでご利用いただけます。詳細については ドキュメント をご確認ください。 SageMaker Canvas unlocks no-code ML and data preparation at petabyte-scale Amazon SageMaker Canvasがペタバイト規模のデータセットをサポートしました。SageMaker Canvasは50 以上のコネクターと直感的なインターフェイスでローコード/ノーコードの機械学習ソリューションです。今回、扱えるデータが以前の5GBの制限から大幅に向上し、これまでの10倍の最大20万行のサンプリングが可能になりました。5GBを超えるデータの処理は自動的にEMR Serverlessにスケーリングされるため、EMR Serverlessの利用料に応じてEMRの料金が追加で発生します。このアップデートはSageMaker Canvas が提供されているすべての AWS リージョンで利用できます。詳細については リリースブログ や ドキュメント をご確認ください。 Amazon Neptune now introduces support for PropertyGraphStore in Neptune to build more reliable GraphRAG applications Amazon NeptuneがPropertyGraphIndexをサポートしました。これによりLlamaIndexと組み合わせたGraphRagアプリケーションを構築ができるようになります。LlamaIndexは、Amazon Bedrockで利用できるような大規模言語モデル (LLM) を使用してアプリケーションを構築するための一般的なオープンソースフレームワークです。今回のローンチにより、テキストをOpenCypherクエリに簡単に変換できるようになり、ナレッジグラフの操作やナレッジグラフからの関連情報の抽出が容易になりました。さらに、一般的なOpenCypherクエリには定義済みのテンプレートを利用できるため、クエリ構築を簡易にし、アプリケーション間の一貫性を確保できます。PropertyGraphIndexは、複雑なマルチホップ検索を処理する場合でも、単純なクエリを処理する場合でも、GraphRagソリューションの全体的なパフォーマンスと機能を大幅に向上させます。詳細は LlamaIndexのドキュメント をご確認ください。 最後に、イベントのご紹介です。9月11日にWebセキュリティ対策に関するイベントが開催されます。 幅広い業界の方に関連する内容と思いますので、ご都合つけばぜひご参加ください。 — 2024年 9月 11日 14:00 – 17:00 JST 「高度化するサイバー攻撃へのWeb セキュリティ対策 ～ 強化された機能とプロアクティブな運用サポート」 https://aws-web-security-20240911-p.splashthat.com/ — それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本ブログは、株式会社インサイトテクノロジー と Amazon Web Services Japan が共同で執筆しました。 株式会社インサイトテクノロジー は、1995 年の創業時から一貫してデータベース技術を追究し、企業自らが良質なインサイトを得るためのデータ活用基盤「インサイト・インフラ」関連の製品をプロフェッショナルサービスとともに提供しています。現在では、企業におけるデータの価値を最大化できるよう、データ利活用の統制を図り、データ活用推進を支える攻めと守りの両面のメリットをもたらすデータガバナンスソリューション として、SQL テスト製品、データマスキング製品などを 提供しています。 同社では、データベースのマイグレーションやバージョンア ップにおける 挙動の変化やエラーの発生を確認できるテストツール、 Insight SQL Testing を提供しています。 Insight SQL Testingでは本番環境のデータベースに対して行われた SQL の自動収集を行い、収集した SQL をテスト環境に対して実行し、実行結果を分類したわかりやすい UI を提供するなど、 SQL テストの効率化を行うことができます。同じエンジン間でのバージョンアップに伴う挙動の変化の確認だけでなく、異種データベース間でも利用できるため、DB エンジンの変更を伴うマイグレーションの場合でも利用可能なソリューションです。 課題と開発経緯 データベースのバージョンアップやマイグレーションを行う際、元々利用していたデータベースではエラーなく実行できる SQL 文でも、移行先となる 異なるエンジンのデータベースやバージョンアップ先のデータベースでは、仕様の違いからエラーになってしまう SQL 文が存在します。 Insight SQL Testing ではそういったエラーになる SQL を洗い出すことを容易にしてくれますが、どのように修正を行っていくべきかはエンジニアが検討を行ったり、 AWS Schema Conversion Tool を用いて対象となる SQL&nbsp;文に対して修正レコメンデーションを表示させるといった Insight SQL Testing のツール外での作業が必要でした。 そこで、Insight SQL Testing のツール内で作業を完結することができるよう、SQL 修正提案機能が追加されました。この機能の追加により、DBA のような専門の知識を持ったエンジニアがいない場合でも修正方法の検討が容易になります。この機能ではエラー確認画面上で LLM に修正内容を提案させることができ、提案された修正内容をそのままツール上で再実行することも可能です。Insight SQL Testing のツール内で修正箇所の確認から SQL&nbsp;文の修正の実施までの作業を一貫して行うことができるようになりました。 ソリューション SQL 修正提案機能の実現にあたって、 Amazon Bedrock &nbsp;が活用されています。Amazon Bedrock は&nbsp; 単一の API を介して AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデル (FM) を選択できるフルマネージドサービスで、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供します。 Insight SQL Testing は&nbsp; AWS Marketplace &nbsp;上で AMI として提供されており、 Amazon EC2 上にデプロイされます。Amazon Bedrock を活用することで、Insight SQL Testing を実行する EC2 インスタンスのスペックによらず SQL&nbsp;文の修正内容を提案させるための LLM の推論を行うことができ、既存のテストツールとしての機能には影響を与えず SQL 修正提案機能を提供することができます。 また、Amazon Bedrock への接続にあたっては AWS PrivateLink を利用することで、Insight SQL Testing がデプロイされた EC2 と Amazon Bedrock 間の通信はインターネットに出ない構成となっています。Insight SQL Testing で収集する SQL 文はアプリケーションでどういったデータを扱っているかを推測できる情報となり得るため、外部に情報が出ないセキュリティ的に安全性の高い利用方法をとっています。 導入効果 Amazon Bedrock の活用によって、生成 AI 機能という新しい分野の開発をスムーズに進め、製品へと導入することができました。一方、生成 AI を活用した機能を構築するにあたっては、評価の方法を確立することは課題の一つでした。機能の開発にあたっては何パターンかのテストケースを用意し、テスト結果を確認しながらより良い応答を求めてプロンプトの修正等のチューニングを行っていました。 SQL修正提案機能については、Insight SQL Testing の利用者からも「 SQL 修正提案機能で提供される情報は修正を進めていくうえでの参考情報として使えそうです。」といったフィードバックをいただいてます。また、Insight SQL Testing の画面から、エラー原因の確認、修正まで一連の流れで行える点はユーザーからも高評価をいただいています。 今後の展望 今後の展望として、モデルの変更機能の追加、 Knowledge Base for Amazon Bedrock を活用した推論精度の向上といったアップデートを計画しています。 生成 AI は変化が激しい領域であるため、より良い精度を求めるためにモデルの変更が求められることがありますが、Amazon Bedrock を活用することで、モデルの変更にも柔軟に対応できます。 また、Amazon Bedrock には Knowledge Base と呼ばれる&nbsp; RAG &nbsp;を構築するための機能があります。RAGはあらかじめ用意したドキュメントを質問内容に応じて類似検索し、LLM がより関連性の高い情報を元にした回答を作成するための手法の一つです。 SQL 修正提案機能では各 DB エンジンのドキュメントをベースとした回答を行えるよう RAG を構築することで、モデルが学習していない最新のバージョンについての情報や、特定のエンジン固有の情報への対応などより精度の高い回答を行えるよう計画しています。 まとめ Insight SQL Testing では、Amazon Bedrock を SQL 修正提案機能に活用することで、生成 AI 機能の開発をスムーズに行うことが可能になり、製品の価値を高めることに繋がりました。 SQL 修正提案機能の詳細については、株式会社インサイトテクノロジーのプレスリリースでも確認可能です。 https://www.insight-tec.com/news/press/202404_5061/ SQL 修正提案機能を搭載したInsight SQL Testing は AWS Marketplaceからも購入可能 です。Free trialとデモの案内が用意されているため、データベースのマイグレーション、バージョンアップにおけるテスト工数削減を行いたい場合はぜひご確認ください。

はじめに 現代のサプライチェーンを管理するには、グローバルな変動、輸送の混乱、予期せぬ顧客需要の変化など、課題がつきまといます。これらの課題に対処するには、サプライチェーンの俊敏性、スケーラビリティ、イノベーションが必要です。 AWS Supply Chain は、お客様の課題を解決し、サプライチェーン運用の変革を加速できる選択肢を提供します。 AWS Supply Chain は、需要予測、複数拠点での在庫管理、サプライヤー計画など、サプライチェーン管理に特化した機能を提供しています。連携可能性を意識して作られた AWS Supply Chain は、既存の ERP (Enterprise Resource Planning) システムやサプライチェーン管理システムと連携でき、再設計、初期ライセンス料、長期コミットメントは不要です。 現在、多くの企業で使われている ERP ソフトウェアソリューションは、SAP ECC と SAP S/4HANA の 2 つです。AWS は 15 年以上にわたり SAP ワークロードをサポートしており、SAP ワークロードのイノベーションを加速するために数千のお客様に選ばれています。近年、多くのお客様がビジネス変革を加速するために、RISE with SAP on AWS を選択しています。AWS Supply Chain は、オンプレミスの SAP ECC、SAP S/4HANA、および RISE with SAP での SAP S/4HANA Cloud の両方と接続できます。AWS Supply Chain を使用すれば、SAP への既存の投資を活用しながら、同時にイノベーションを加速させ、企業のサプライチェーンの課題によりよく対処することができます。 このブログでは、SAP S/4HANA システムを AWS Supply Chain と連携するための接続オプション、構成上の考慮事項、およびベストプラクティスについて説明します。 AWS サプライチェーンとは？ AWS Supply Chain は、ERP (Enterprise Resource Planning) やサプライチェーン管理システムなどの既存のソリューションと連携します。AWS Supply Chain を使用すると、在庫、供給、需要に関連するデータを既存の ERP やサプライチェーン システムから抽出し、AWS Supply Chain の統合データモデルに統一できます。 さらに、AWS Supply Chain はデータをリアルタイムに可視化し、現在の在庫の選択と数量、および各拠点の在庫の健全性を強調表示して、在庫切れのリスクが高い在庫などの問題を浮き彫りにします。AWS Supply Chain を使用すると、最も緊急性が高い在庫問題に関する洞察を自動的に受け取ることができ、潜在的なサプライチェーンの混乱が発生したときに事前に警告するためにウォッチリストを設定できます。 AWS Supply Chain を使えば、提案されたオプションと推奨アクションに基づいて、迅速に適切なアクションを取ることができます (例：在庫切れを回避するための倉庫間の在庫再配分の提案) 。また、ビルトインのコンテキストコラボレーション機能を使用して、チーム間で連携し、問題をより早く解決することで、エラーを減らし、効率を向上させることができます。 さらに、AWS Supply Chain は機械学習による高精度な需要予測により、お客様の期待通りに納品することに役立ちます。 SAP S/4HANA との AWS Supply Chain 接続の概要アーキテクチャーと前提条件 このセクションでは、AWS Supply Chain データ レイクへデータを取り込むために、SAP S/4HANA システムの接続と構成のベストプラクティスについて説明します。 以下は、接続とデータフローの参考アーキテクチャです: 図 1 – SAP との AWS サプライチェーンの連携 この参考アーキテクチャは、SAP S/4 HANA システム、Amazon AppFlow を使用した AWS Supply Chain コネクタ、および AWS Supply Chain インスタンスがすべて 1 つの AWS リージョン内にあることを示しています。 SAP システムと AWS Supply Chain インスタンスが異なるリージョンにある場合、SAP システムがオンプレミスまたは RISE with SAP on AWS で稼働している場合、または別のクラウドプロバイダーで稼働している場合もあります。このような接続の場合、お客様は自身の AWS アカウントで Amazon AppFlow サービスを使用して、SAP RISE アカウントまたはオンプレミスで稼働している SAP システムに接続することが可能です。 AWS Supply Chain は内部で Amazon AppFlow と連携し、Open Data Protocol (OData) サービスとして公開されている SAP データソースを使用して Operational Data Provisioning (ODP) によりデータを抽出します。 AWS Supply Chain で SAP からのデータに基づいて 機械学習での予測、需要計画、インサイト可視化するには、主に 3 つのステップが必要です。 1. Amazon AppFlow から SAP S/4HANA システムへの接続 2. SAP S/4HANA で必要なデータセットを準備し、それらを OData サービスとして利用可能にする 3. AWS Supply Chain での SAP S/4HANA システム接続先、およびビルトインコネクタを使用してデータ取り込み それでは、これらのステップを説明します。 Amazon AppFlow から SAP S/4HANA システムへの接続 Amazon AppFlow から SAP S/4HANA に接続し、Operational Data Provisioning (ODP) ベースのデータ抽出ができるようにするには、Amazon AppFlow ドキュメントの Amazon AppFlow SAP OData Connector の手順をご参照ください。 ブログ: Amazon AppFlow SAP OData Connector が SAP ODP Changed-Data Capture に対応 ミッションクリティカルな本番 SAP システムでのデータセキュリティを強化するため、インターネット経由での転送は避けることを推奨します。そのため、この ブログ で説明されているように、データ転送のために AWS PrivateLink 接続を設定してください。この AWS CloudFormation テンプレート を使用すると、SAP システムへセキュアに接続するための AWS PrivateLink を自動的に設定できます。 SAP S/4HANA で必要なデータセットを準備し、それらを OData サービスとして利用可能にする Amazon AppFlow と SAP システムの接続設定ができたら、AWS Supply Chain にデータ転送するために SAP S/4HANA で必要なデータの設定に進めます。この設定作業の一環として、SAP でデータソースの作成および有効化が必要です。これらの必要なデータソースの詳細な最新リストについては、 ドキュメント を参照してください。ドキュメントの「 SAP データソース 」というセクションでは、名前が「Z」で始まる「SAP データソース」がリストの「テーブル」として分類されています。「ZV」で始まるものは SAP ビュー、「ZQ」で始まるものは SAP クエリです。一覧にある「0BP*」と「2LIS*」で始まる標準のデータソースに関する追加考慮事項は、後述の「SAP S/4HANA からのデータ取り込み」で説明します。 また、データ抽出タイプ列に「差分」と「フル」の記載があり、SAP データ列に「マスターデータ」か「トランザクションデータ」かの記載も十分確認しながら進めます。これらは、設定時にどのトランザクションとどのオプションを選択するかに影響します。 SAP データソースのセクションの確認が終わりましたら、 AWS Supply Chain ワークショップの SAP S/4HANA からのデータ取り込み セクションを参照して、これらのデータソースの設定を進めてください。 AWS Supply Chain での SAP S/4HANA システム接続先、およびビルトインコネクタを使用してデータ取り込み SAP でデータソースの作成と有効化ができ、SAP Gateway サービスの定義も完了したら、AWS Supply Chain インスタンスで SAP S/4HANA システムに接続して、AWS Supply Chain データレイクへの初期データ抽出を開始する準備が整います。 AWS Supply Chain インスタンス作成はまだ行っていない場合は、AWS マネジメントコンソールで AWS Supply Chain インスタンス を作成してください。AWS Supply Chain を検索してサービスのコンソールに移動し、AWS リージョンを選んだあとに、「インスタンスを作成」ボタンをクリックします。AWS Supply Chain のユーザーは、 IAM Identity Center サービスと連携して管理できます。ドキュメントの IAM Identity Center の有効化 セクションを参照してください。 AWS Supply Chain インスタンスには、Amazon Simple Storage Service (Amazon S3)やElectronic Data Interchange (EDI)などのデータソースに加え、SAP S/4HANAやSAP ECCシステムへのコネクタがすぐに利用できます。 接続を作成するには、AWS Supply Chain インスタンスにログインし、左側メニューの Data Lake → Connections をクリックします。 図 2 – AWS Supply Chain データレイク接続 「New Data Connection」ボタンをクリックし、SAP S/4HANA を選択します。「Next」ボタンをクリックします。 図 3 – AWS Supply Chain の接続先選択 次の画面で、SAP システムへの接続情報を入力します。AWS Supply Chainは内部で Amazon AppFlow を使用して、SAP S/4HANA システムからデータを抽出します。 前述のとおり、Amazon AppFlow での SAP S/4HANA への接続設定から、アプリケーションホスト URL と AWS PrivateLink サービス名を確認できます。 図 4 – AWS Supply Chain から SAP への接続情報 接続ができたら、追加のマッピング作業は不要です。ウィザードの残りの手順を進めると、データ取り込みが自動的に開始されます。AWS Supply Chain は、SAP システムからデータを抽出するためのデータフローを自動的に作成し実行します。 図 5 – エンティティグループとデータフロー この段階で、AWS Supply Chain データレイクには、SAP システムから OData サービスを使用して公開された、トランザクションとトランザクション以外のデータソースからのデータが格納されています。データ取り込みを確認するには、[ Connection ] -&gt; [ Data flows ] -&gt; [ All data flows ] の順で画面選択すれば確認できます。 図 6 – AWS Supply Chain データレイク詳細 AWS Supply Chain のデータマッピング AWS Supply Chain では、ユーザーが SAP ソースから AWS Supply Chain ターゲットのデータレイクへのデータフィールドマッピングを確認および変更できる機能があります。このマッピングを確認するには、データレイクコネクションの中で SAP 接続を選択し、Entity Groups を展開します。確認したいデータエンティティで、ほかの詳細オプションをクリックし、レシピの管理をクリックします。たとえば Purchase Order – Inbound Order Line などのエンティティのデータフィールドマッピングを確認できます。SAP データソースのフィールドが抽出され、AWS Supply Chain データレイクのフィールドにマッピングされていることが確認できます。たとえば、SAP データソース 2LIS_02_ITM の EBELN フィールドは、AWS Supply Chain Purchase Order Inbound Order Line の order_id フィールドにマッピングされています。レシピアクション をクリックすると、フィールドマッピングをダウンロードしたり、要件に応じてマッピングをアップロードしたりできます。 図 7 – AWS Supply Chain で SAP データソースのデータフィールドマッピング AWS Supply Chain でのデータ可視化 データ取り込みプロセスが完了したら、AWS Supply Chain は機械学習を使ってデータ変換と計画機能を実行します。企業は、SAP S/4HANAのような一般的なERPシステム用のあらかじめ構築されたコネクターによって、より速く、より簡単なデータ関連付けで、すべてのサプライチェーンシステムにわたるデータに簡単に接続することができるます。これは、再設計又はシステム移行を行わなくても実現できます。AWS Supply Chain はこれらのシステムと別で機能でき、既存システムに付加価値を提供しています。お客様は SAP データと SAP 以外のデータソースを組み合わせることができます。たとえば、図 8 の AWS Supply Chain 在庫可視化ネットワークマップに示されているように、異なるソースからのデータにあるさまざまな場所での在庫状況を可視化できます。 図 8 – AWS Supply Chain 在庫可視化ネットワークマップ 重要な考慮事項とトラブルシューティング SAP でデータソースを作成する際は、データソース名が ドキュメントのリスト に記載されている SAP データソース名と完全に一致することを確認してください。 前述のとおり、SAP データソースは ODATA サービスに定義されています。トランザクション /n/IWFND/MAINT_SERVICE で ODATA サービスが有効化され、サービステスト結果のreturn値が 200 (OK) であることを確認してください。 ODATA サービスに関するエラーについては、/n/IWFND/ERROR_LOG で確認できます。 AWS Supply Chain は、Amazon AppFlow を使用して SAP S/4HANA システムからデータを抽出するための 53 個のフローを自動的に作成します。フロー名には、AWS Supply Chain インスタンス ID と SAP S/4HANA データソース名が含まれます。 Amazon AppFlow サービスコンソール画面を開くと、各フローのステータスを確認できます。AppFlow に関する一般的なエラーコードについては、 一般的なエラー のドキュメントを参照してください。また、各フローの Amazon CloudWatch メトリクス が提供されており、トラブルシューティングの出発点として役立ちます。さらに、Amazon AppFlow に対して、ユーザー、ロール、または AWS サービスによって実行されたアクションの記録については、 CloudTrail ログ を参照できます。 ２つのAmazon S3 バケットが作成されます。1 つは Amazon AppFlow により使われ、抽出されたデータを格納し、AWS Supply Chain インスタンスへのデータ取り込みに使用されます。もう 1 つは、AWS Supply Chain 接続により、エンティティタイプと取り込みタイプ (置換、更新、削除) ごとに作成されます。 AWS Supply Chain から SAP S/4HANA への接続に問題がある場合は、KMS キーポリシーが正しい AWS Supply Chain インスタンス ID で「ListGrants」権限を持っていることを確認してください。 詳細については、 ドキュメント を参照してください。 AWS Supply Chain に抽出されたデータにエラーがある場合、抽出されたデータ ( Amazon AppFlow の対象フローのデータ保存先バケットにある)を CSV ファイルとしてダウンロードし確認することができます。対象データを確認することで、null フィールドや重複行など、AWS Supply Chain へのデータ取り込み失敗につながる可能性がある問題の詳細を確認できます。 AWS Supply Chain では、エラーのあるエンティティのレシピ―管理画面でデータ取り込みの問題についてより詳細を確認できます。 図 9 – AWS Supply Chain でのデータ取り込み問題のトラブルシューティング AWS Supply Chain の問題のトラブルシューティングについてさらにサポートが必要な場合は、AWS Supply Chain チームにケースを開いて、 AWS Supply Chain の管理サポート を受けることができます。 価格 AWS Supply Chain は従量課金制のクラウドサプライチェーンアプリケーションで、データレイク、インサイト、需要計画機能を提供しています。利用分のみの支払いで、前払いのライセンス料や長期契約は不要です。詳細については、AWS Supply Chain のドキュメントの 料金設定 セクションを参照してください。 まとめ AWS Supply Chain に SAP S/4 HANA と連携することにより、需要の変動や供給の混乱に対する対応力を最大化し、サプライチェーンの回復力を高めることができます。新しいデータを受け取ると再計算が実行されるため、サプライチェーンデータでほぼリアルタイムで更新され、素早くインサイトを得られます。機械学習機能による実用的な分析と推奨を活用して、よりデータに基づいた意思決定ができます。ユーザは同じアプリケーション内で同じ情報を見ながら、ビルトインのコンテキストチャットやメッセージングを使って迅速に問題を解決できます。リスクを軽減してコストを削減しながら、顧客体験を向上させることができます。構成に示しているように、これらすべてが SAP S/4 HANA システムとのビルトインのコネクタを使って、数クリックで実現できます。 以下のAWS Supply Chain 紹介と追加リソースも併せてご確認ください: AWS Supply Chain デモビデオ、ブログ等の参考リソース 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

生成型人工知能 (AI) は転機を迎え、誰もが想像力を掻き立てられています。顧客向けサービスやソリューションに生成 AI 機能を統合することが重要になっています。現在の生成 AI 製品は、機械学習モデルや深層学習モデルからの段階的な進化の集大成です。深層学習から生成 AI への飛躍は、 基盤モデル によって可能になりました。 Amazon Bedrock は、幅広い基盤モデルに簡単にアクセスでき、開発体験全般を大幅に簡素化します。 しかしながら、その力にもかかわらず、汎用的なモデルだけでは、特定の関連性の高い AI ソリューションを生成することはできません。より良く、より有用な応答を生成するためには、追加のドメインコンテキストが必要となります。 検索拡張生成 (RAG) は、コンテキストを提供する一般的な手法です。RAG の中核となるのがベクトル埋め込みで、これは非構造化データを基盤モデルを介して多次元の数値表現に変換するものです。次元内のベクトル値が近ければ近いほど、項目の類似性が高くなります。これが、今日みられるベクトル類似度検索のユースケースの基礎となっています。 Amazon Relational Database Service (RDS) for SQL Server は、世界中のあらゆる規模の組織で使用されている、フルマネージドの耐久性のあるデータベースサービスです。多くのお客様にとって、RAG ベースの生成 AI ユースケースに追加のドメインコンテキストを提供できる運用データストアは、すでに Amazon RDS for SQL Server 上にホストされています。その結果、以下の理由から、このデータベースサービスはベクトルデータストアとして最適な選択肢となります。 Amazon RDS for SQL Server は、高度に成熟したスケーラブルで信頼性と効率性の高いリレーショナルデータベースサービスで、ベクトルデータ管理を容易にします。 ベクトルは SQL Server データベース内のリレーショナルテーブルとしてモデル化できます。 SQL Server の列ストアインデックスには、ベクトル演算を加速する SIMD と AVX-512 などの最適化機能が組み込まれています。 今日の一般的なベクトル類似度計算である コサイン類似度 は、SQL Server データベース内のユーザー定義関数として実装できます。 この投稿では、類似性検索を含む生成 AI のユースケースを実装するためのベクトルデータストアとして Amazon RDS for SQL Server を使用する方法を示します。このシナリオでは、ソースとなる運用データストアとベクトルデータストアの両方が Amazon RDS for SQL Server 上に配置、ホストされます。埋め込みデータをドメイン固有のデータセットの近くに格納することで、外部データソースを必要とせずに追加のメタデータと組み合わせることができます。データは時間とともに変化するため、埋め込みデータをソースデータの近くに格納することで、埋め込みデータを最新の状態に保つことも簡単になります。 この投稿では、運用データとベクトルデータストアの両方に同じ RDS for SQL Server インスタンスを使用しました。私たちが示すワークフローの具体例は、RAG を使って基盤モデルを強化し、ドメインに関連する応答をユーザーに提供する典型的なチャットボットシナリオです。次の図は、この投稿で実装された生成 AI ワークフローの概要を示しています。 ソースデータのベクトル埋め込みはすでにベクトルデータストアに存在すると想定しています。私たちの主な焦点は、チャットに投稿された質問のベクトル埋め込みを生成し、それをベクトルデータストアと比較して、類似性検索を使って関連する応答を生成することにあります。この投稿のデータは Wikipedia の公開コンテンツ から取得されており、id、URL、タイトル、テキストの 4 つのフィールドから構成されています。Amazon RDS for SQL Server でのベクトルデータベースにおけるサンプル Wikipedia データを使ったベクトル埋め込み生成プロセスは、次の投稿 (パート 2) で包括的に取り上げる予定です。 大規模言語モデルを利用してユーザーに対話応答を提供する UI の実装の詳細は、このシナリオから意図的に除外されています。このソリューションのポイントは、データベース側にあります。つまり、類似性検索要求に応じて、ベクトルデータストアから関連する結果セットを取得する方法に焦点が当てられています。 ソーリューションアーキテクチャ概要 上記の RAG ワークフローを実装するためのソリューションアーキテクチャには、 Amazon RDS for SQL Server 、 Amazon SageMaker 、および特に Amazon Titan G1 Text Embedding Model を使用する Amazon Bedrock が含まれています。ワークフローは次のとおりです: ユーザーの質問 (プロンプト) は、SageMaker ノートブックから Amazon Bedrock の API を呼び出すことで、Amazon Titan モデルを使ってベクトル埋め込みに変換されます (次の図の手順 1 から 3) 。 この新しいベクトルデータは、ベクトルデータストアにホストされているコサイン類似度関数への入力として渡されます。この関数は、データベースに永続化されているベクトル埋め込みに対して類似性検索を実行し、結果セットを SageMaker に返します (次の図の手順 4 と 5) 。 次のセクションでは、Amazon RDS for SQL Server、Amazon Bedrock、Amazon SageMaker を使用して、このソリューションアーキテクチャを設定する方法について説明します。また、Amazon Bedrock Foundation Models とのやり取りの仕方や、ベクトルデータストアからコサイン距離計算を実行する方法についても詳しく説明します。 前提条件 この投稿では、 AWS マネージメントコンソール の操作に精通していることを前提としています。この例では、AWS アカウントで以下のリソースとサービスが有効になっている必要があります: Amazon RDS for SQL Server インスタンス (ベクトルデータストア) Amazon SageMaker サンプルノートブック Amazon Bedrock Python ライブラリ Amazon Bedrock 。Amazon Bedrock では、特定の基盤モデルを使用するために、アクセスをリクエストしておく必要があります。この投稿では、Amazon Titan Embeddings G1 – Text を使用します。 Amazon Bedrock API のセットアップ Amazon RDS for SQL Server ベクトルデータストアの作成 Amazon RDS for SQL Server の基本的なビルディングブロックはデータベースインスタンスです。このインスタンス環境で、SQL Server データベースを実行します。インスタンスを作成するには、ユーザーガイドの「 Microsoft SQL Server DB インスタンスの作成と接続 」の章に記載されている手順を参照してください。 次のオプションが選択されていることを確認してください: エンジンオプションは、Microsoft SQL Server を選択します。 エンジンバージョンは、SQL Server 2019 15.00.4345.5.v1 を選択します。 エディションは、SQL Server Standard Edition を選択します。 DBインスタンスクラスは、db.t3.xlarge を選択します。 ストレージタイプは、gp3 を選択します。 パブリックアクセスは、「はい」を選択します。これにより、ワークステーションから RDS for SQL Server インスタンスに直接接続できるようになります。 オプショングループは、SQLSERVER_BACKUP_RESTORE オプションを含むオプショングループを選択します。これは、SQL Server ネイティブバックアップをリストアできるようにするために必要です。詳しい手順については、ユーザーガイドの「 ネイティブバックアップと復元を使用した SQL Server データベースのインポートとエクスポート 」の章を参照してください。 Amazon RDS for SQL Server インスタンスを作成し、前提条件のリンクで提供されるベクトルデータベースバックアップをリストアします。リストアが完了すると、次のように [vector_db_wiki] という名前のデータベースを参照できるようになります。 [vector_db_wiki] データベースには以下の 3 つのテーブルが含まれています。 wikipedia_articles (私たちのユースケースの生のソースデータ) wikipedia_articles_embedding_bedrock wikipedia_articles_content_vector そしてコサイン類似度のロジックを実装するユーザー定義関数が 1 つ含まれます。 Bedrock_SearchSimilarContentArticles SageMaker ノートブックの構成 この投稿で提供されている Amazon SageMaker ノートブックのサンプルをアップロードする前に、Amazon SageMaker ノートブックインスタンスをセットアップする必要があります。AWS マネージドコンソールで SageMaker サービスに移動し、左側のペインの Applications and IDEs セクションにある Notebooks をクリックし、「ノートブックインスタンスの作成」ボタンを選択してください。 注意 ：2024年7月時点の UI に則った手順に記載を変更しています。 ノートブックインスタンスの名前として「rds-sql-genai-demo」と入力し、残りの値はすべてデフォルト値のままにしてください。 「ネットワーク」セクションを展開し、適切な「VPC」、「サブネット」、「セキュリティグループ」を選択します。先ほど作成した Amazon RDS for SQL Server データベースインスタンスが、選択した同じ VPC 上に配置されていることを確認します。下にスクロールして「ノートブックインスタンスの作成」ボタンをクリックします。ノートブックインスタンスが起動したら (ステータスが InService になったら)、アクションから「JupyterLab を開く」を選択します。「Terminal」アイコンを選択して JupyterLab IDE に移動します。 Linux ターミナルウィンドウで次のコードを実行して、SQL Server (Linux) 用の Microsoft Open Database Connectivity (ODBC) ドライバをインストールしてください。 # RHEL 7 and Oracle Linux 7 curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/mssql-release.repo sudo yum remove unixODBC-utf16 unixODBC-utf16-devel #to avoid conflicts sudo ACCEPT_EULA = Y yum install -y msodbcsql18 # Optional: for bcp and sqlcmd sudo ACCEPT_EULA = Y yum install -y mssql-tools18 echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' &gt;&gt; ~/.bashrc source ~/.bashrc # For unixODBC development headers sudo yum install -y unixODBC-devel Bash 次のコードを実行して、必要な追加のライブラリをインストールしてください。 pip install --no-build-isolation --force-reinstall \ "boto3&gt;=1.28.57" \ "awscli&gt;=1.29.57" \ "botocore&gt;=1.31.57" Bash インストール処理の最後に表示される pip 依存関係エラーは無視しても問題ありません。 次のコードを実行して「utils」ライブラリをインストールしてください。インストールが完了したら、 bedrock.py ファイルをSageMaker ノートブックインスタンスのローカルドライブの /home/ec2-user/anaconda3/envs/python3/lib/python3.10/site-packages/ ディレクトリにコピーしてください。 pip install utils Bash 次に、前提条件のリンクで提供されているサンプルの SageMaker ノートブックをアップロードします。まだノートブックファイルをダウンロードしていない場合は、処理を進める前にダウンロードしてください。ダウンロードフォルダに vector-similarity-search-bedrock-sql-server.ipynb という名前のファイルが入っているはずです。 SageMaker ノートブックインスタンスの右側にある「Open JupyterLab」リンクを選択してください。次に、Jupyter Lab ウィンドウの左側のペインにある「フォルダー」アイコンを選択します。「ファイルをアップロード」オプションを選択し、「ダウンロード」フォルダーに移動して、「vector-similarity-search-bedrock-sql-server.ipynb」ファイルを選択します。 ファイルがアップロードされると、下の画像のようにサンプルの SageMaker ノートブックを参照できるようになります。 類似検索の実行 このセクションでは、SageMaker ノートブックを使用して、いくつかの類似性検索のユースケースを実行します。このドキュメントに含まれている Bedrock API を実行する前に、すべての API 呼び出しのセキュリティコンテキストとして使用する IAM ロールを設定する必要があります。必要な IAM ロールを設定するには、 ドキュメント に記載された手順に従ってください。 最初のステップは、コードが参照する必要なライブラリのセットをインポートすることです。JupyterLab ツールバーの実行ボタンを使用して、次のコードスニペットを選択して実行するか、セルを強調表示して Shift+Enter を押してください。 次に、以下のコードスニペットを実行して Amazon Bedrock クライアントを設定します。コードを実行する前に、アカウント番号とロール名を適切な値に置き換えてください。実行が完了すると、SageMaker ノートブックに “boto3 Bedrock client successfully created!” というメッセージが表示されます。 最初の類似性検索 (“What are the best Sci-Fi movies in history?”) のためのユーザーのプロンプトをベクトル化するために、次のコードスニペットを実行して最初の BedrockAPI コールを行います。私たちが使用するテキスト埋め込みモデルは、Amazon Titan Embeddings G1 – Text v1.2 (コードスニペットの 1 行目) であることに注意してください。 入力ベクトルが作成されたら、Amazon RDS for SQL Server ベースのベクトルデータストアとの接続を確立し、コサイン距離アルゴリズムを利用した類似性 (意味的) 検索リクエストを発行する準備ができます。以下のコードを実行する前に、ODBC 接続文字列に適切なパラメータがすべて指定されていることを確認してください。 数秒後、次のような結果セットが得られるはずです。各 Wikipedia の記事の横に表示される値は、プロンプトベクトルと wikipedia_articles_content_vector テーブル (コンテンツベクトルテーブル) に現在格納されている各ソース Wikipedia の記事のベクトル間のコサイン距離計算の結果を表しています。 「Alien」、「2001: A Space Odysse」、「Blade Runner」などのウィキペディアの記事が、「Sci-Fi」や「Movie」という単語が含まれていないにもかかわらず上位に表示されていることに注目してください。これは従来のテキスト検索では実現できません。また、「AFI が選ぶ 100 年に一度の映画 100 本」の記事が上位に表示されていることにも注目してください。この記事はアメリカ映画協会が選んだ上位 100 本の映画について書かれているので、検索結果に含まれることは理にかなっています。最後に、「What are the most iconic warriors in history?」というプロンプトで類似性 (意味) 検索を行う例を示します。 数秒後に、次の結果セットが得られるはずです。 結果セットには、「Zhang Fei」、「Leonidas I」、「Sitting Bull」などのウィキペディアの記事が含まれていることに注目してください。これらはすべて、古代中国、スパルタ、そしてアメリカ入植者と激しく戦った有名なシューインディアンの酋長など、異なる時代と場所の伝説的な戦士たちです。もう一つ重要なことは、結果セットの項目が降順でコサイン距離で並べ替えられていることです。コサイン距離値が 0.457988230404067 と非常に高い位置にある「Leonidas I」は、伝説的なスパルタの戦士についてのウィキペディアの記事です。 これらのリソースを使って追加のテスト、または開発に使用する予定がある場合、継続的なコストを最小限に抑えるための簡単な方法は RDS for SQL Server と SageMaker ノートブックインスタンスを停止することです。予定がない場合は、クリーンアップセクションの説明に従ってこれらのリソースを削除してください。 クリーンアップ このデモでは以下に示すいくつかの AWS リソースを作成しました: Amazon RDS for SQL Server データベースインスタンス Amazon SageMaker ノートブックインスタンス 今後これらのリソースが必要ない場合は、提供された URL の手順に従って、 Amazon RDS for SQL Server と SageMaker ノートブック インスタンスを削除し、不要な課金を避けてください。 まとめ 検索拡張生成 (RAG) は、ドメイン固有の情報と基盤モデルを組み合わせることで、生成 AI アプリケーションのレスポンスを強化する強力な手法です。この投稿では、Amazon RDS for SQL Server、Amazon SageMaker、および Amazon Bedrock を使用した 2 つの類似性検索のユースケースについて説明しました。また、Amazon RDS for SQL Server がベクトルデータストアとして機能する方法も示しました。お客様には、本番環境にソリューションを展開する前に、徹底的にパフォーマンスとスケールのテストを実施することを強くお勧めします。これにより、類似性検索の応答時間が必要な期待値を満たすことが保証されます。生成 AI アプリケーションにおけるベクトルデータストアの役割の詳細については、「 生成 AI アプリケーションでベクトルデータストアが果たす役割とは 」をご覧ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Joshua Jin は、Amazon Web Services (AWS) のデータベースベンチマークエンジニアであり、データベースのパフォーマンス評価に精通しています。 Camilo Leon は、カリフォルニア州サンフランシスコを拠点とする AWS のプリンシパルソリューションアーキテクトで、データベースを専門としています。彼は、AWS のお客様に対してアーキテクチャのガイダンスと技術サポートを提供し、AWS のリレーショナルデータベース業務と業務アプリケーションの設計、展開、管理を行っています。休日には、マウンテンバイキング、写真撮影、映画鑑賞を楽しんでいます。。 Sudarshan Roy は、World Wide AWS Database Services Organization (WWSO) のシニアデータベーススペシャリストクラウドソリューションアーキテクトです。彼は大規模なデータベース移行とモダナイゼーションのエンゲージメントを企業顧客向けにリードし、データベースワークロードを AWS クラウドに移行する際の複雑な移行課題の解決に取り組んでいます。 Barry Ooi は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。彼の専門分野は、お客様の AWS への移行の一環として、クラウドネイティブサービスを使用したデータプラットフォームの設計、構築、実装です。彼の関心分野はデータ分析とデータの可視化です。

はじめに 2021 年 11 月、AWS は 新しいオープンソースの Kubernetes クラスターオートスケーリングプロジェクト「 Karpenter v0.5 」の発表を行いました。当初は Kubernetes の Cluster Autoscaler の柔軟で動的かつ高性能な代替手段として考案されていましたが、その後の約 3 年間で Karpenter は大幅に進化し、完全な機能を備えた Kubernetes ネイティブのノードライフサイクルマネージャーになりました。 このプロジェクトは、業界のリーダー企業によってミッションクリティカルなユースケースに採用されています。自動的に利用率を改善するように設計された ワークロード統合 や、ユーザーがクラスター内で Karpenter がノードのライフサイクル管理操作を実行する方法とタイミングを指定できるようにする 中断制御 (Disruption Controls) などの主要な機能が追加されました。2023 年 10 月には、 このプロジェクトがベータ版に移行 し、AWS は Kubernetes の Autoscaling Special Interest Group (SIG) を通じて、ベンダーニュートラルなプロジェクトのコアを Cloud Native Computing Foundation (CNCF) に 貢献 しました。Karpenter コミュニティからの関与により、GitHub の星の数で AWS のオープンソースプロジェクトのトップ 10 の 1 つとなり、AWS 以外のコミュニティメンバーからの貢献も、数と範囲の両面で増加しています。この進化を支えているのはユーザーの成功事例や、新機能、コミュニティの貢献です。AWS の Karpenter チームは、プロジェクトの成熟度と運用の安定性を高めるために熱心に取り組んでいます。 本日、 Karpenter v1.0.0 のリリースにより、Karpenter がベータ版から卒業したことを誇りに思います。このリリースでは、安定版の Karpenter API、すなわち NodePool と EC2NodeClass が今後の 1.0 マイナーバージョンリリースでも同様に利用可能で、マイナーリリース間で互換性のない変更が加えられることはありません。この記事では、現行の Karpenter v0.37 と v1.0.0 の変更点について説明します。 v1.0.0 の変更点 v1.0.0 リリースの一環として、カスタムリソース定義 (CRD) のアプリケーションプログラミングインターフェイス (API) グループと Kind 名は変更されていません。また、ベータ版から安定版への移行をよりシームレスにするために、変換用の Webhook を作成しました。Karpenter の v1 ( v1.1.0 ) 以降のマイナーバージョンでは、v1beta1 API のサポートを廃止する予定です。以下に新機能と変更点の概要を示します。 中断理由ごとの中断制御の強化 Karpenter リリース v0.34.0 では、Karpenter がノードを終了する方法とタイミングをユーザーに制御させる中断制御が導入されました。これにより、コスト効率、セキュリティ、アプリケーションの可用性のバランスを改善することができます。この中断予算 (Disruption Budgets) は、表現力のある cron 構文に従い、特定の時間帯、曜日、時間、分に適用されるようスケジューリングできるため、アプリケーションの可用性をさらに保護できます。Karpenter の設定で disruption ブロックに設定がない場合、デフォルトでは常に 10% のノードの中断に制限されます。 Karpenter v1 は、中断理由ごとの中断予算をサポートしました。サポートされるのは Underutilized 、 Empty 、 Drifted です。これにより、ユーザーは特定の中断理由に適用される中断予算をより細かく制御できるようになります。たとえば、次の中断予算は、ユーザーが以下のようなコントロールを実装する方法を定義しています。 月曜日から金曜日の 9:00 UTC から 8 時間の間は、 Drifted もしくは Underutilized の場合でもノードの 0% が中断の対象になります すべての時間において、 Empty の場合はノードの 100% が中断の対象になります その他の時間帯では、 Drifted もしくは Underutilized の場合にノードの 10% の中断が許可されます。ただし、より厳しい予算設定が有効でない場合に限ります。 ユーザーは、このバジェットを使用して、アプリケーショントラフィックのピーク時に空きノードを終了し、コンピューティングを最適化できます。中断理由が設定されていない場合、中断予算はすべての中断理由に適用されます。 ... disruption: budgets: - nodes: “ 0 ” schedule: "0 9 * * mon-fri" duration: 8h reasons: - Drifted - Underutilized - nodes: "100%" reasons: - Empty - nodes: "10%" reasons: - Drifted - Underutilized ... 統合ポリシー名を WhenUnderutilized から WhenEmptyOrUnderutilized に変更 統合ポリシーの WhenUnderutilized の名称が WhenEmptyOrUnderutilized に変更されました。v1beta1 のときと機能は同じで、 consolidationPolicy=WhenUnderutilized の場合、Karpenter は部分的に利用されているノードまたは空のノードを統合します。新しい名前 WhenEmptyOrUnderutilized は、条件を明示的に正しく反映しています。 apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: default spec: disruption: consolidationPolicy: WhenEmptyOrUnderutilized 低利用ノードの統合制御 consolidateAfter Karpenter は、スケジューリングされた Pod の数が最小になるようにノードを統合することを優先します。需要の急激な増加や中断可能なジョブがあるワークロードを持つユーザーは Pod の入れ替えが多く発生する可能性があるため、Karpenter のノードを統合しようとする速度を調整できるようにしてほしいと要望していました。以前は、 consolidateAfter は consolidationPolicy=WhenEmpty の場合のみ使用できました。つまり、最後の Pod が削除された時のみ適用されました。 consolidateAfter は、現在 consolidationPolicy= WhenEmptyOrUnderutilized でも使用できるようになりました。これにより、ユーザーは Pod が追加または削除された後、Karpenter が統合を行うまでの時間を時間、分、秒単位で指定できるようになりました。v1beta1 の WhenUnderutilized と同じ動作を望む場合は、 consolidationPolicy=WhenEmptyOrUnderutilized にし、 consolidateAfter を 0m に設定してください。 新しい中断制御 terminationGracePeriod クラスター管理者は、Karpenter 内でノードの最長ライフタイムを強制する方法を求めており、それがセキュリティ要件に準拠していることが望ましいです。Karpenter は、Pod Disruption Budget (PDB)、Pod の terminationGracePeriodSeconds 、および karpenter.sh/do-not-disrupt アノテーションを尊重することで、ノードを適切に中断します。これらの設定が誤っていた場合、Karpenter はノードの中断を無期限に待ち続けるため、クラスター管理者が新しい Amazon Machine Image (AMI) をロールアウトできなくなります。 そのため、 terminationGracePeriod が導入されました。 terminationGracePeriod は、ノードが強制的に削除される前に drain できる最大時間です。またノードの有効期限を過ぎても置換ノードを待機しません。ノードの最大ライフタイムは、 terminationGracePeriod + expireAfter です。この変更に伴い、 expireAfter の設定も disruption ブロックから template.spec に移動されました。 次の例では、クラスター管理者が NodePool を構成して、ノードが 30 日後に drain 開始するようにし、強制終了される前に 24 時間の猶予期間を設けることで、既存のワークロード (長時間実行されるバッチジョブなど) が強制終了される前に完了する時間を十分に確保できます。 apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: default spec: template: spec: terminationGracePeriod: 24h expireAfter: 720h ... Drift フィーチャーゲートの削除 Karpenter の Drift 機能は、ノードが望ましい状態から外れた場合 (例えば古い AMI を使用している) に、そのノードを置き換えます。v1 では、Drift 機能が安定版に昇格し、フィーチャーゲートが削除されました。つまり、デフォルトでノードが ドリフトするようになりました。v1beta1 で Drift 機能のフィーチャーゲートを無効にしていたユーザーは、今後は中断理由ごとの中断予算を使用してドリフトを制御できます。 amiSelectorTerms の必須化 Karpenter v1beta1 API で amiSelectorTerms を指定せずに amiFamily を指定した場合、Karpenter はその AMI ファミリの新しいバージョンの Amazon EKS 最適化 AMI がリリースされると、Drift 機能を通じてノードを自動的に更新していました。これは、常に最新バージョンにアップグレードされるのが望ましいテスト用の環境では機能しますが、本番環境では望ましくない場合があります。Karpenter では、ユーザーに本番環境で AMI をピン留めすることを推奨しています。AMI の管理方法の詳細は、Karpenter の ドキュメント を参照してください。 amiSelectorTerms は必須フィールドになり、新しい用語 alias が導入されました。 alias は AMI ファミリーとバージョン ( family@version ) で構成されています。 EC2NodeClass に alias が存在する場合、Karpenter はそのファミリーの Amazon EKS 最適化 AMI を選択します。この新機能により、ユーザーは特定のバージョンの Amazon EKS 最適化 AMI を指定できるようになりました。設定できる Amazon EKS 最適化 AMI ファミリーは、 AL2 、 AL2023 、 Bottlerocket 、 Windows2019 、 Windows2022 です。次のセクションでは例を示します。 Amazon EKS 最適化 AMI の使用 この例では、Karpenter は Bottlerocket の v1.20.3 Amazon EKS 最適化 AMI でノードをプロビジョニングします。AWS が Bottlerocket Amazon EKS 最適化 AMI の新しいバージョンをリリースしても、ワーカーノードはドリフトしません。 apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: default spec: ... amiSelectorTerms: - alias: bottlerocket@v1.20.3 ... カスタム AMI の使用 EC2NodeClass で alias 項目を指定しない場合、 amiFamily で使用するユーザーデータを設定する必要があります。 amiFamily は、 AL2 、 AL2023 、 Bottlerocket 、 Windows2019 、 Windows2022 のいずれかを設定して事前生成されたユーザーデータを選択するか、ユーザー自身がユーザーデータを提供する場合は Custom を設定できます。 amiSelectorTerms 内の既存のタグ、名前、ID フィールドを使用して AMI を選択できます。Amazon EKS 最適化 AMI ファミリーのユーザーデータの注入例は、Karpenter の ドキュメント にあります。 次の例では、 EC2NodeClass がユーザー指定の AMI (ID “ami-123”) を選択し、Bottlerocket が生成するユーザーデータを使用します。 apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: default spec: ... amiFamily: Bottlerocket amiSelectorTerms: - id: ami-123 ... Ubuntu AMI ファミリーの選択の削除 v1 以降、Ubuntu AMI ファミリーは削除されました。Ubuntu AMI を引き続き使用するには、 amiSelectorTerms で最新の Ubuntu AMI ID に固定された AMI を構成できます。さらに、 EC2NodeClass で amiFamily: AL2 を参照すると、以前と同じユーザーデータ構成を取得できます。以下は例です。 apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: default spec: ... amiFamily: AL2 amiSelectorTerms: - id: ami-123 ... コンテナからのインスタンスメタデータサービスへのアクセスをデフォルトで制限 Amazon EKS のベストプラクティス では、アプリケーションに必要な権限のみを付与し、ノードの権限を付与しないよう、Pod がノードに割り当てられた AWS Identity Access and Management (IAM) インスタンスプロファイルにアクセスできないよう制限することが推奨されています。そのため、デフォルトでは新しい EC2NodeClass では、ホップカウントを 1 ( httpPutResponseHopLimit :1 ) に設定し、IMDSv2 ( httpTokens : required ) を要求することで、Instance Metadata Service (IMDS) へのアクセスがブロックされます。ホストネットワークモードを使用する Pod は引き続き IMDS にアクセスできます。ユーザーは、 Amazon EKS Pod Identity または IAM roles for service accounts を使用して、Podに AWS サービスへのアクセス権限を付与する必要があります。 kubelet 設定を EC2NodeClass に移行 Karpenter では、kubelet 引数のサブセットを指定して追加のカスタマイズができます。Karpenter v1 では、kubelet 構成が EC2NodeClass API に移動しました。カスタムの kubelet 構成を提供し、単一の EC2NodeClass を参照する異なる kubelet 構成を持つ複数の NodePool がある場合は、複数の EC2NodeClass を使用する必要があります。Karpenter v1 の Conversion Webhooks はこの互換性を維持します。ただし、v1.1.x に移行する前に、ユーザーは NodePool を正しい EC2NodeClass を参照するように更新する必要があり、その結果ノードがドリフトします。 NodeClaims がイミュータブルに Karpenter v1beta1 では NodeClaim の不変性は強制されませんでしたが、作成後にユーザーがこれらのオブジェクトに対して操作しないことを前提としていました。そのため、 NodeClaim ライフサイクルコントローラーは初回のインスタンス起動後の変更に反応しないため、 NodeClaim はイミュータブルになります。 NodePool の nodeClassRef フィールドすべての必須化と apiVersion フィールドの group への名称変更 Karpenter v1beta1 では、ユーザーが参照する NodeClass の apiVersion と kind を設定する必要はありませんでした。Karpenter v1 では、ユーザーはすべての nodeClassRef フィールドを設定する必要があります。さらに、 nodeClassRef の apiVersion フィールドは group に名前が変更されました。 ... nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default ... Karpenter の Prometheus メトリクスの変更 Karpenter は、Karpenter コントローラーとクラスターのプロビジョニングステータスを監視できるように、Prometheus 形式のメトリクスをいくつか提供しています。Karpenter v1 リリースの一環として、v1beta1 のメトリクスの一部が変更されました。そのため、これらのメトリクスを使用するクエリを含むダッシュボードを使用しているユーザーは、更新する必要があります。メトリクスの変更の詳細リストについては、Karpenter v1 アップグレード ドキュメント を確認してください。 計画済みの非推奨化機能の削除 この変更に伴い、v1 では以下のベータ版の非推奨機能が削除されました。 karpenter.sh/do-not-evict アノテーションは、アルファ版で Pod レベルの制御として導入されました。この制御は、Pod が実行されているノードに対する中断操作を無効にする karpenter.sh/do-not-disrupt アノテーションに置き換えられました。 karpenter.sh/do-not-evict アノテーションは、ベータ版を通して非推奨と宣言され、v1 では削除されました。 karpenter.sh/do-not-consolidate アノテーションは、アルファ版でノードレベルの制御として導入されました。この制御は、単に統合だけでなく中断操作を無効にする karpenter.sh/do-not-disrupt アノテーションに置き換えられました。 karpenter.sh/do-not-consolidate アノテーションは、ベータ版を通して非推奨と宣言され、v1 では削除されました。 ConfigMap ベースの構成は v1beta1 で非推奨となり、v1 で完全に削除されました。この構成は、より簡単な CLI/環境変数ベースの構成 に置き換えられました。 クラスター名をその値に格納する karpenter.sh/managed-by タグのサポートは、 eks:eks-cluster-name に置き換えられました。 新機能、変更点、廃止された機能の完全なリストについては、詳細な 変更ログ をお読みください。 移行パス Karpenter の v1 API は API グループやリソースの変更を伴わないため、 Kubernetes の Webhook conversion プロセス を利用して、ノードのロールアウトなしに API をインプレースでアップグレードできます。アップグレードする前に、 NodePool 、 NodeClaim 、 EC2NodeClass などの v1beta1 API をサポートする (0.33.0 以降の) Karpenter バージョンを使用している必要があります。 アップグレードプロセスの概要 (ベータ版から v1 への移行) は次のとおりです。 更新された v1 の NodePool 、 NodeClaim 、 EC2NodeClass CRD を適用します Karpenter コントローラーを v1.0.0 バージョンにアップグレードします。この Karpenter バージョンは、API リクエストで v1 API スキーマに基づいて推論を開始します。アップストリームの Karpenter プロジェクトとプロバイダー ( EC2NodeClass の変更) によって提供される Conversion Webhook を使用して、リソースは v1beta1 から v1 バージョンに自動的に変換されます。 次に、Karpenter v1.1.0 へのアップグレードに備えて、ユーザーは v1beta1 マニフェストを新しい v1 バージョンを使用するように更新する必要があります。この際、リリースの API 変更を考慮する必要があります。詳細については、v1 移行 ドキュメント の「Before upgrading to&nbsp;v1.1.0」を参照してください。 詳細なアップグレードの手順については、Karpenter v1 移行 ドキュメント を参照してください。 まとめ この記事では、Karpenter v1.0.0 リリースと、新機能および変更点の概要について学びました。Karpenter を v1.0.0 にアップグレードする前に、完全な Karpenter v1 移行 ドキュメント を読み、本番環境以外の環境でアップグレードプロセスをテストすることをお勧めします。質問やフィードバックがある場合は、Kubernetes Slack の #karpenter チャンネル または GitHub でフィードバックを共有してください。