AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

3670

開発者はしばしば、 AWS Amplify Hosting にデプロイされた Next.js アプリケーションから、 Amazon Virtual Private Cloud (Amazon VPC) 内にデプロイされたリソースにアクセスする必要があります。 Amazon VPC を使用すると、お客様は隔離された仮想ネットワークでリソースを起動できます。しかし、開発者は、複雑なネットワークアクセス制御とセキュリティグループのために、Amazon VPC 内で API とデータベースを呼び出すためにフロントエンドアプリケーションを接続することが困難であると感じるかもしれません。 この投稿では、AWS Amplify Hosting 上で動作する Next.js サーバーサイドレンダリング (SSR) アプリケーションから、 Amazon Relational Database Service (Amazon RDS) や AWS Lambda などのリソースや VPC 内のリソースにアクセスするためのソリューションを実装します。 ソリューションの概要 まず、 AWS Cloud Development Kit (AWS CDK) を使って、Amazon VPC 内に Lambda 関数をビルドしてデプロイします。 次に、Pages Router を使用した Next.js API Routes を通じて Amazon VPC 内のデータにアクセスする Next.js アプリを作成し、AWS Amplify Hosting 上でホストされた React UI にアクセスします。 AWS Systems Manager Parameter Store を利用した API キーやその他の設定データのデモを行います。 その結果、エンドユーザーが Amazon VPC 内からデータを表示するためにアクセスできる Next.js アプリが作成されます。 前提条件 このチュートリアルでは以下のものが必要です。 AWS アカウント NPM でインストールされた Node.js VPC スタックでの Lambda 関数の作成 Next.js アプリケーションがアクセスできる保護された Amazon VPC リソースを説明するために、Lambda 関数が動作する Amazon VPC を作成します。 まず、AWS CDK をインストールします。前提条件の詳細は AWS CDK の開始方法 を参照してください。 $ npm install -g aws-cdk 次に、アプリ用の新しいディレクトリを作成します。 $ mkdir lambda-in-a-vpc $cd lambda-in-a-vpc 次に、以下のコマンドを実行して AWS CDK アプリケーションを作成します。 $ cdk init app —language=typescript 生成したら、 lib/lambda-in-a-vpc-stack.ts の内容を以下のコードに置き換えます。 AWS CDK Stack は、パブリック、プライベート、隔離されたサブネットを持つ Amazon VPC、セキュリティグループ、Amazon VPC の隔離されたサブネットに配置される Lambda 関数 (Node.js) を作成します。 Lambda 関数をセキュリティグループ付きのプライベートサブネットに配置することで、Amazon VPC 内で関数を分離します。 これにより、パブリックインターネットから分離された Lambda 関数のセキュアなネットワーク環境が提供されますが、プライベートサブネット内のデータベースのような Amazon VPC 内のリソースにアクセスすることができます。 // lib/lambda-in-a-vpc-stack.ts import { CfnOutput, Duration, Stack, StackProps, aws_ec2 as ec2, aws_lambda as lambda, } from "aws-cdk-lib"; import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs"; import { Construct } from "constructs"; import path = require("path"); export class LambdaInAVpcStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, "LambdaVpc", { subnetConfiguration: [ { name: "Isolated", subnetType: ec2.SubnetType.PRIVATE_ISOLATED, }, { name: "Private", subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, }, { name: "Public", subnetType: ec2.SubnetType.PUBLIC, }, ], }); // Create a security group to be used on the lambda functions const lambdaSecurityGroup = new ec2.SecurityGroup( this, "Lambda Security Group", { vpc, } ); const getDataLambda: NodejsFunction = new NodejsFunction( this, id + "-getDataLambda", { memorySize: 1024, timeout: Duration.seconds(5), runtime: lambda.Runtime.NODEJS_18_X, handler: "handler", entry: path.join(__dirname, "../lambda/getData.ts"), vpc: vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED }, securityGroups: [lambdaSecurityGroup], } ); new CfnOutput(this, "getDataLambdaArn", { value: getDataLambda.functionArn, exportName: "getDataLambdaArn", }); } } Lambda 関数 (Node.js) の内部では、Amazon RDS インスタンスような Amazon VPC 内のリソースや、Amazon S3 バケット、その他の保護されたリソース、または外部のサードパーティ API など任意のリソースからデータを取得することができます。 次に、 lambda ディレクトリを作成し、その下に getData.ts を作成します。 説明のためにデータはハードコードされていますが、この Lambda 関数は Amazon RDS やその他のデータソースから地理データを取得し、それを返す前に検証や変換を行うことができます。 // lambda/getData.ts import { APIGatewayProxyResultV2 } from "aws-lambda"; const geoData = [ { name: "United States", states: [ "Alabama", "Alaska", "Arizona", //... ], }, { name: "Canada", states: [ "Alberta", "British Columbia", "Manitoba", // ... ], }, { name: "Mexico", states: [ "Jalisco", "Mexico City", "Oaxaca", // ... ], }, ]; exports.handler = async function (): Promise<APIGatewayProxyResultV2> { try { return { statusCode: 200, headers: { "Content-Type": "application/json" }, body: JSON.stringify(geoData, null, 2), }; } catch (error) { console.error("Unable to return data:", error); return { statusCode: 500, headers: { "Content-Type": "application/json" }, body: JSON.stringify(error), }; } }; cdk deploy を実行して AWS CDK スタックをデプロイし、次のセクションで Next.js アプリケーションで使用するために返されるアウトプットをメモします。 $ cdk deploy [+] Building 92.4s (14/14) FINISHED 8.4s WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested asset-output/index.js 831b ⚡ Done in 102ms ✨ Synthesis time: 97.21s LambdaInAVpcStack: deploying... [1/1] LambdaInAVpcStack: creating CloudFormation changeset... ✅ LambdaInAVpcStack ✨ Deployment time: 33.99s Outputs: LambdaInAVpcStack.getDataLambdaArn = arn:aws:lambda:us-east-1:074128318641:function:LambdaInAVpcStack-LambdaInAVpcStackgetDataLambda1E-33sG563OFj2H Stack ARN: arn:aws:cloudformation:us-east-1:074128318641:stack/LambdaInAVpcStack/1fbc2790-2a57-11ee-9757-0ecf5ea19ac5 ✨ Total time: 131.2s LambdaInAVpcStack.getDataLambdaArn の末尾にある Lambda 関数名 (この場合は LambdaInAVpcStack-LambdaInAVpcStackgetDataLambda1E-33sG563OFj2H ) に注意してください。 Next.js Amplify アプリの作成 次に、Pages Router を使って Next.js アプリケーションを作成します。 $ npx create-next-app@latest geo-web-app ✔ Would you like to use TypeScript? … No / `_Yes_` ✔ Would you like to use ESLint? … `_No_` / Yes ✔ Would you like to use Tailwind CSS? … No / `_Yes_` ✔ Would you like to use `src/` directory? … No / `_Yes_` ✔ Would you like to use App Router? (recommended) … `_No_` / Yes ✔ Would you like to customize the default import alias (@/*)? … `_No_` / Yes` AWS Amplify JavaScript、AWS Amplify UI ライブラリをインストールします。 これらの依存関係はオプションですが、本記事では Next.js アプリケーションの UI を構築するために使用します。 $ npm i aws-amplify @aws-amplify/ui-react 以下のインポートで pages/_app.tsx を更新して、 Amplify UI のスタイルを設定します。 // Import Amplify UI styles import "@aws-amplify/ui-react/styles.css"; import type { AppProps } from "next/app"; export default function App({ Component, pageProps }: AppProps) { return <Component {...pageProps} />; } 更新を Git にコミットし、Git プロバイダにプッシュします。 Next.js アプリの Amplify へのデプロイ アプリを Git プロバイダにプッシュしたら、Amplify Hosting にデプロイする準備ができました。 まず Amplify コンソール にアクセスしてください。Amplify アプリを作成したことがない場合は、ページを一番下までスクロールし、 Amplify Hosting > Host your web app > Get started を選択します。アプリを作成したことがある場合は、 New app > Host web app を選択します。 Git リポジトリのホスティングプロバイダを選択し、 Continue を選択します。 Git プロバイダーによっては、Amplify Hosting にリポジトリへのアクセスを許可するようプロンプトが表示されます。認証に成功したら、 Recently updated repositories リストからこのアプリのリポジトリを選択し、 Next を選択します。 Build settings ページで、Amplify は自動的に正しいビルド設定を検出するので、設定を変更する必要はありません。デフォルトのまま Next を選択します。 Review ページで、 Save and deploy を選択します。 アプリが作成され、Amplify Hosting コンソールのアプリのページに移動します。Amplify Hosting は、プロジェクト用に分離されたビルドとホスティング環境をプロビジョニングし、デプロイします。このプロセスには 2 ~ 3 分かかります。以下のように、 Provision 、 Build 、または Deploy リンクを選択することで、進行状況を確認できます。 パラメータストアでシークレットを手動で作成 Next.js の API Routes では、AWS SDK が Amazon VPC 内の Lambda 関数を呼び出すために、シークレットにアクセスする必要があります。 シークレットは、設定データ管理とシークレット管理のためのセキュアで階層的なストレージを提供する Parameter Store に格納します。 Amplify Hosting コンソールで、 App Settings: General に移動し、 App ARN を取得します。 最後のスラッシュ (/) の後の値が App ID で、Parameter Store にキーを保存するときに使用されます。 VPC スタックの CDK アウトプットから取得した VPC_AWS_REGION 、 VPC_LAMBDA_FUNCTION_NAME のためのシークレットを作成する必要があります。 Next.js の API Routes と Amazon VPC の AWS Lambda の間の統合ポイントは、VPC Lambda 関数を呼び出すアクセス権を持つ IAM ユーザーまたはロールによって実現されます。 このユーザーまたはロールには、 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY 、および VPC Lambda 関数を呼び出す権限が必要です。 IAM ユーザーの作成 、 IAM ユーザーのアクセスキーの作成 、および 共有責任モデル を使用したアクセススコープのベストプラクティスを参照してください。 これらのシークレットは、AWS コンソールの Parameter Store に移動して手動で設定できます。 Amplify Hostingドキュメントの 環境変数 のページの指示に従って、パラメータ名は以下の形式に従ってください。 今回のケースでは Amplify バックエンドを持っていないので、ブランチ名は main にします。 /amplify/{your_app_id}/{your_backend_environment_name}/{your_parameter_name} 完了すると、Parameter Store で以下のように表示されます。 パラメータストアでのシークレット作成の自動化 オプションとして、以下の .env.local テンプレートと Bash スクリプト sync-ssm-params.sh を利用して、プロジェクト内の .env.local ファイルから Parameter Store に直接シークレットを保存することもできます。 このスクリプトは、ローカル開発環境に AWS CLI と jq が Amplify アプリ ID と一緒にインストールされている必要があります。 .env.local に VPC_AWS_REGION と VPC_AWS_REGION 、 VPC_LAMBDA_FUNCTION_NAME を設定し、 AWS_PROFILE に AWS CLI で設定した使用したいプロファイルを設定します。 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY は、 AWS CLI を使用してスクリプトが取得します。 # .env.local AWS_APP_ID=<Copy from Amplify Hosting Console> AWS_PROFILE=default VPC_AWS_REGION= VPC_LAMBDA_FUNCTION_NAME= #!/bin/bash # sync-ssm-params.sh # Allow list of parameters allowlist=( AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY VPC_AWS_REGION VPC_LAMBDA_FUNCTION_NAME ) # Get the name of the current branch APP_BRANCH=$(git rev-parse --abbrev-ref HEAD) # Load .env into environment export $(cat .env.local | grep -v '^#' | xargs) # Get AWS access keys from AWS CLI profile AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id --profile $AWS_PROFILE) AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key --profile $AWS_PROFILE) for key in "${allowlist[@]}"; do aws ssm put-parameter --name "/amplify/$AWS_APP_ID/$APP_BRANCH/$key" --value "${!key}" --type SecureString --overwrite done カスタムポリシーで Amplify Hosting のサービスロールの更新 Parameter Store に保存されたシークレットにアクセスする前に、アプリケーションのデプロイ時に Amplify Hosting が作成した Service Role を更新して、このアプリケーションの Parameter Store からの読み取り権限を持たせる必要があります。 Amplify Hosting コンソールに移動し、アプリケーションに移動して、 App Settings: General に移動し、 Service Role に注目してください。 AWS コンソール の IAM に移動し、Service Role を検索します。 Add permissions > Attach policy を選択して、インラインポリシー AllowAmplifySSMCalls をロールに追加します。 以下のポリシーを Amplify アプリ ID で更新し、JSON エディタに貼り付けます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAmplifySSMCalls", "Effect": "Allow", "Action": [ "ssm:GetParametersByPath", "ssm:GetParameters", "ssm:GetParameter" ], "Resource": [ "arn:aws:ssm:*:*:parameter/amplify/<AMPLIFY_APP_ID>/*" ] } ] } ポリシーが保存されると、 Permissions policies の下に他のポリシーと一緒に表示されます。 パラメータストアからシークレットをロードするための Amplify ビルドのカスタマイズ 最後に、Amplify CI のビルド設定ファイル amplify.yml を更新して、Parameter Store から Next.js がビルド処理中に参照する環境ファイル ( .env ) にシークレットをロードする必要があります。 プロジェクトに amplify.yml ファイルを追加して、 jq ユーティリティ ( $secrets の値を解析するのに必要) をインストールし、ビルド中に Parameter Store からシークレットを .env にロードするための以下のコマンドを追加します。 jq の使用はオプションであり、 環境変数をサーバー側のランタイムからアクセスできるようにするためのガイダンス に従って grep や他のユーティリティを使用しても構いません。 echo $secrets | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' >> .env 以下は、完全な amplify.yml ファイルです。 version: 1 frontend: phases: preBuild: commands: - yum -y install jq - jq --version - npm ci build: commands: - echo $secrets | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' >> .env - npm run build artifacts: baseDirectory: .next files: - "**/*" cache: paths: - node_modules/**/* ファイルを Git にコミットし、Git プロバイダーにプッシュしてデプロイを開始します。 Amazon VPC Lambda 関数のデータで Next.js アプリを更新 シークレットを Parameter Store に格納したら、Next.js アプリから Amazon VPC 内のデータにアクセスできるようになります。 AWS SDK に依存するので、次のコマンドでインストールします。 $ npm install aws-sdk page/api の下に Next.js API Routes getGeoData.ts を作成し、AWS SDK を初期化して Amazon VPC Lambda 関数を呼び出す次のコードを記述します。 // pages/api/getGeoData.ts import { Lambda } from "aws-sdk"; import { NextApiRequest, NextApiResponse } from "next"; const lambda = new Lambda({ region: process.env.VPC_AWS_REGION, accessKeyId: process.env.AWS_ACCESS_KEY_ID, secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY, }); export default async (req: NextApiRequest, res: NextApiResponse) => { lambda.invoke( { FunctionName: process.env.VPC_LAMBDA_FUNCTION_NAME!, Payload: JSON.stringify({}), }, (err, data) => { if (err) { console.log(err); res.status(500).json({ error: err }); } else { res.status(200).json({ data }); } } ); }; 次に、データにアクセスするフロントエンドのコードを記述します。 pages/index.ts を、 pages/api/getGeoData への API コールを行い、 AWS Amplify UI を使用して結果を表に表示する以下のコードに置き換えます。 // pages/index.tsx import { Heading, Table, TableBody, TableCell, TableHead, TableRow, View, } from "@aws-amplify/ui-react"; import { useEffect, useState } from "react"; type Country = { name: string; states: string[]; }; export default function Home() { const [geoData, setGeoData] = useState<Country[]>([]); useEffect(() => { fetch("/api/getGeoData") .then((res) => res.json()) .then((data) => { const payload = JSON.parse(data.data.Payload); const body = JSON.parse(payload.body); setGeoData(body); }); }, []); return ( <View padding="1rem"> <Heading level={2} marginBottom={25}> Countries and States </Heading> <br /> {geoData.length === 0 && <div>Loading...</div>} {geoData.length > 0 && ( <Table width={500}> <TableHead> <TableRow> <TableCell as="th">Country</TableCell> <TableCell as="th">States</TableCell> </TableRow> </TableHead> <TableBody> {geoData.map((country) => ( <TableRow key={country.name}> <TableCell>{country.name}</TableCell> <TableCell> {country.states.map((state) => ( <div key={state}>{state}</div> ))} </TableCell> </TableRow> ))} </TableBody> </Table> )} </View> ); } ファイルを Git にコミットし、Git プロバイダーにプッシュして最終的なデプロイを開始します。 デプロイ後、プロジェクトの URL に移動すると、Amazon VPC の Lambda 関数からデータがロードされます。 クリーンアップ AWS CDK スタックのリソースを削除するには、 lambda-in-a-vpc CDK プロジェクトのルートから cdk destroy を実行します。 Next.js Amplify アプリを削除するには、Amplify Hosting でアプリに移動し、 Actions > Delete app を選択します。 まとめ 本記事では、AWS CDK を使用して Amazon VPC 内で関数を分離するために、セキュリティグループ付きのプライベートサブネットに Lambda 関数を構築してデプロイしました。 次に Next.js アプリを作成し、Next.js の API Routes を通して Amazon VPC 内のデータにアクセスし、AWS Amplify Hosting にホストされデプロイされた React UI にアクセスしました。 パラメータストアを使用して APIキーやその他の設定データを安全に保存し、アクセスするためのベストプラクティスを紹介しました。 カスタムドメイン の設定や、 プルリクエスト用の Web プレビュー 、 機能ブランチ (feature branch) など、Amplify Hosting の機能についての詳細は、 AWS Amplify Hosting ドキュメント をご覧ください。 本記事は「 Accessing resources in a Amazon Virtual Private Cloud (Amazon VPC) from Next.js API Routes 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。
CTO として、あなたはエンジニアリングチームの技術戦略を監督し、フレームワーク、アーキテクチャ、インフラストラクチャに関する決定を導く責任があります。開発者の生産性を最大限に高めながら、堅牢でスケーラブルなアプリケーションを構築するためには、適切な技術スタックを選択することが極めて重要です。本記事では、 AWS Amplify の新しいコードファースト開発者体験 (Gen 2) でフルスタックアプリケーションを構築することが、Web 開発スタックの中核であるべき理由を説明します。 Amplify Gen 2 は、現代の Web 開発者の要件を満たすために、AWS 上でフルスタックアプリケーションを構築する開発者体験を再構築しました。TypeScript と AWS Cloud Development Kit (AWS CDK) のようなコードファーストの開発者体験ソリューションを活用することで、Amplify は AWS 上でインフラストラクチャをプロビジョニングするための設定ではなく、コードを書く能力を開発者に提供します。 TypeScript のメリット TypeScript は静的型付けされた JavaScript のスーパーセットで、プレーンな JavaScript にコンパイルされます。フロントエンドとバックエンドの Web 開発に TypeScript を使用すると、いくつかの重要な利点があります。 エラーの早期発見 : TypeScript の静的型付けは、実行時にしか現れないような、コンパイル時に発生するさまざまなエラーを検出します。これにより、より堅牢なコードとなり、実運用でのバグが少なくなります。 開発者の生産性の向上 : 型付けは、Visual Studio Code のような統合開発環境 (IDE) で、インテリセンス、オートコンプリート、インラインドキュメントを提供します。これにより、開発者の生産性が向上します。 より簡単なリファクタリング : 型システムは、互換性のない変更を即座に開発者に警告することで、大規模なリファクタリングをより安全にします。 コードの自己文書化 : 明示的な型は、バニラ JavaScript に比べてコードをより自己文書化します。そのため、新しいチームメンバーも素早く立ち上がることができます。 将来性のあるコード : TypeScript を使用すると、ロジックとフレームワークを切り離すことができるため、React Hooks のような新しいフレームワークやパラダイムへの移行が容易になります。 つまり、TypeScript を使用することで、バグが少なく保守が容易なコードを作成しながら、開発者の幸福度と生産性を向上させることができます。 AWS CDK によるコードファーストの開発者体験 インフラストラクチャを手動で管理するのは時間がかかり、エラーが発生しやすく、環境間で正確に再現するのが困難です。AWS CDK のようなコードファーストのソリューションでは、TypeScript のような実際のプログラミング言語を使用して、宣言的な方法ですべてのインフラストラクチャを定義できます。これらの機能により、アプリケーションとインフラストラクチャのニーズが進化するにつれて、AWS サービスの幅とパワーを活用した拡張性が可能になります。 AWS CDK を使用してインフラストラクチャをコードとして管理する主な利点は以下のとおりです。 ベストプラクティスの成文化 : コードとしてアーキテクチャを定義し、セキュリティ、信頼性、およびコンプライアンスのベストプラクティスを成文化します。 迅速な環境プロビジョニング : アプリケーションの開発環境、テスト環境、ステージング環境を数分で構築できます。環境の破棄と再作成もすばやく行えます。 効率的なアップデート : コードを通じて、すべての環境でスタックのアップデートを迅速に実行できます。 コストの最適化 : AWS CDK は、スポットインスタンスや自動スケーリングなどのコスト最適化サービスを簡単に活用できます。 インフラテスト : AWS CDK を使用してインフラストラクチャの単体テストと統合テストを記述し、デプロイ前のエラーを防止します。 AWS CDK は、アプリケーションコードと同様に、インフラストラクチャをバージョン管理し、CI/CD パイプラインの一部としてデプロイすることを可能にします。これは開発者の生産性とビジネスの俊敏性を大きく向上させます。 AWS Amplify とコードファースト開発者体験 AWS Amplify Gen 2 の登場は、特にフロントエンドチームのニーズに応えるフルスタックアプリケーション開発の次世代を示します。 この強力なツールキットは、開発者が堅牢でスケーラブルなアプリケーションを、スピードを維持し、複雑さを軽減しながら構築できるようにします。ここでは、AWS Amplify Gen 2 がフルスタック開発の領域でゲームチェンジャーとなる理由と方法を説明します。 開発者のスピードと効率性 AWS Amplify Gen 2 は、TypeScript ベースのコードファーストなアプローチを導入し、開発者体験を大幅に強化します。このシフトにより、フロントエンド開発者は TypeScript で直接バックエンドを定義できるようになり、開発プロセスが効率化されます。アプリのデータモデル、ビジネスロジック、認証、認可ルールを TypeScript で表現することで、開発者は基盤となる AWS サービスを手動で設定する手間をかけずにクラウドインフラストラクチャを導入できます。その結果、さまざまなサービスをつなぎ合わせる必要がなくなり、開発速度が飛躍的に向上します。 より少ないコード、より多くのパワー AWS Amplify Gen 2 で採用されているファイルベースの規約は、”設定よりも規約 (convention over configuration)” という原則を遵守しています。これは、開発者が定型的なコードを書く時間を減らし、機能構築に集中する時間を増やすことを意味します。認証用とデータ用といったように、リソースがタイプごとに別々のファイルにまとめられているため、構造が直感的で管理しやすくなっています。さらに、TypeScript を使用すると、Visual Studio Code などの IDE で厳密な型付けとインテリセンスがサポートされるため、エラーが減り、開発プロセスがさらに高速化されます。 フルスタック機能でフロントエンドチームを強化 AWS Amplify Gen 2 により、フロントエンドチームは、記録的なスピードで、より少ない摩擦で、フルスタックを構築する力を得ました。より高速なイテレーションのために最適化された開発者ごとのクラウドサンドボックス環境の提供により、個々のチームメンバーはお互いの作業を妨げることなく、独立してフルスタック機能に取り組むことができます。この並行開発機能は、新機能の市場投入までの時間を短縮する上で極めて重要です。 さらに、フルスタックの Git ベースの環境は、最新の開発ワークフローとシームレスに連携します。各エフェメラル環境は Git ブランチに直接対応しているため、新機能のテストや統合が簡単に行えます。プルリクエストや機能ブランチは、本番環境にマージする前にプレビューできます。コードファーストのアプローチを採用しているため、すべてのバックエンドリソースはコードとして定義され、ブランチ間での再現性と移植性を実現しています。この Git を中心としたアプローチによって、リポジトリが常に単一のソースであり続けることが保証され、開発環境から本番環境への機能の移行が単純化されます。 まとめ AWS Amplify Gen 2 は、フロントエンドチームが TypeScript と AWS CDK を使ってコードファーストの開発者体験でフルスタック開発に取り組む方法を根本的に変えます。開発者のスピードを重視し、過剰なコードの必要性を減らし、堅牢なフルスタック機能を提供することで、チームは他のソリューションよりも効率的かつ効果的に構築することができます。これらの機能により、開発コストを削減し、新製品や新機能の市場投入までの時間を短縮することができます。 AWS Amplify の新しいコードファーストの開発者体験 (Gen 2) を 使用して 、 AWS 上でのモダンアプリケーションの構築の詳細 をご覧ください。 本記事は「 The CTO’s Guide to building fullstack applications with AWS Amplify 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。
現在、400 を超える組織が 2040 年までに温室効果ガス排出量実質ゼロを達成することを公約した The Climate Pledge に署名しています。 明示的な気候目標を設定する背景には、顧客の需要、現在および予測される政府関係、従業員の需要、投資家の需要、競争優位性としてのサステナビリティなどがあります。 AWS の顧客からも、サステナビリティへの取り組みを推進する方法についてますます関心が高まっています。 このブログでは、 Amazon Simple Storage Service (S3) と標準 SQL を使用したデータ分析を簡単に行えるサーバーレスの対話型分析サービスである Amazon Athena を使用して、企業の既存データからスコープ 1 のカーボンフットプリントをよりよく理解し、推定する方法を解説します。 温室効果ガスプロトコル 温室効果ガスプロトコル (GHGP) は、組織の事業およびバリューチェーンからの地球温暖化への影響を測定および管理するための標準を提供しています。 GHGP が対象とする温室効果ガスは、 国連気候変動枠組条約/京都議定書 (しばしば「Kyoto Basket」と呼ばれる) で要求されている 7 つの気体です。これらの気体は、二酸化炭素 (CO2)、メタン (CH4)、一酸化二窒素 (N2O)、フロンガスと呼ばれる F ガス (ハイドロフルオロカーボンとパーフルオロカーボン)、六ふッ化硫黄 (SF6)、三ふッ化窒素 (NF3) です。 温室効果ガスは、それぞれ温室効果と大気中の寿命によって決定される地球温暖化係数 (GWP) によって特徴づけられます。二酸化炭素 (CO2) が 人為的な温室効果ガス排出量の約 76% を占めるため、温室効果ガスの地球温暖化係数は CO2 を基準に測定され、CO2 換算値 (CO2e) で表されます。GHGP は、組織の排出量を 3 つの主要なスコープに分類しています。 スコープ 1 – 直接的な温室効果ガスの排出 (例えば化石燃料の燃焼からの排出) スコープ 2 – 購入したエネルギーからの間接的な排出 (典型的には電力) スコープ 3 – サプライチェーン全体 (サプライヤーや顧客を含む) からの間接的な排出 温室効果ガスの排出量の推定方法 GHG 排出量を推定する方法には、連続排出モニタリングシステム (CEMS) 手法、支出ベース手法、消費ベース手法などがあります。 直接測定 – CEMS 手法 組織は、CEMS を用いて炭素排出量を直接測定することで、固定燃焼源からのカーボンフットプリントを推定できます。この手法を実現するためには、排出源から排出される排ガス中の物質を連続的に測定するためにガスアナライザー、ガスサンプラー、ガスコンディショニング機器 (微粒子、水蒸気、その他の汚染物質を除去する)、配管、駆動弁、プログラマブルロジックコントローラー (PLC)、その他の制御ソフトウェアやハードウェアなどの機器が必要です。このアプローチは有用な結果をもたらす可能性がありますが、CEMS は測定対象となる温室効果ガスごとに特定のセンシング機器およびハードウェアとソフトウェアのサポートが必要であり、多くの場合は中央集約型の排出源に対する環境保健安全の取り組みに適しています。CEMS の詳しい情報は こちら を参照ください。 支出ベース手法 財務会計機能は成熟しており、すでに監査を受けていることが多いため、多くの組織が財務コントロールを炭素会計の基盤として利用することを選択しています。Economic Input-Output Life Cycle Assessment (EIO LCA) 手法は、支出データと金額ベースの排出係数を組み合わせた支出ベースの方法で、推定される排出量を算出します。排出係数は、米国環境保護庁 (EPA) や他の査読付きの学術機関や政府機関によって公表されています。この方法を用いることで、事業活動に費やされた金額に排出係数を乗じることで、その活動から推定されるカーボンフットプリントを算出することができます。 たとえば、自社のトラック輸送にかかるコストを、下記のように推定される二酸化炭素換算値 (CO2e) のキログラム (KG) に換算することができます。 推定されるカーボンフットプリント = トラック輸送に費やされた金額 * 排出係数 [ 1 ] これらの計算は、総勘定元帳やその他の財務記録から非常に簡単に行うことができますが、温室効果ガスの少量発生源を報告するための初期見積もりに最も有用です。ユーザーが入力する情報は、活動に費やした金額のみなので、EIO LCA 手法は効率性の改善をモデル化するのには適していません。 これは、EIO で計算された排出量を削減する唯一の方法は支出を削減することであるためです。 したがって、企業がそのカーボンフットプリントの効率を継続的に改善していくにつれて、カーボンフットプリントを推定するためには、他の方法の方がより望ましいことが多くあります。 消費ベース手法 報告期間中に組織が調達した燃料の量は、ERP (Enterprise Resource Planning) システムや燃料代の電子コピーから容易に判断できます。燃料ベースの排出係数は、米国環境保護庁や商用ライセンスのデータベースなど、さまざまなソースから入手できます。調達した燃料の量に排出係数を乗じると、燃焼に伴う CO2e の推定排出量を導き出せます。この方法は、固定排出源 (データセンターのバックアップ発電機や工業プロセスの化石燃料炉など) のカーボンフットプリントを推定するためによく用いられます。 特定の月に、企業が固定燃焼用に一定量のガソリンを消費した場合、ガソリンの燃焼に伴うスコープ 1 CO2e フットプリントは次のように推定できます。 推定されるカーボンフットプリント = 消費された燃料の量 * 固定燃焼の排出係数 [ 2 ] 組織は、燃料や電気料金の請求書、ERP データなどの既存のデータと、関連する排出係数を使用して自社の炭素排出量を推定し、それらをデータレイクに統合することができます。Amazon Athena や Amazon QuickSight などの既存の分析ツールを使用することで、組織は推定されたカーボンフットプリントに関する洞察を得ることができます。 以下のデータアーキテクチャ図は、AWS のサービスを使用して組織の推定されるカーボンフットプリントを算出および可視化する例を示しています。 お客様は、ユースケースに基づいて、データパイプラインの各段階でサービスを選択する柔軟性を持ちます。たとえば、データ取り込みフェーズでは、既存のデータ要件に応じて、 AWS Command Line Interface (CLI) 、 AWS DataSync 、 AWS Database Migration Service などを使用してデータレイクにデータを取り込むための多くのオプションがあります。 AWS サービスを使用したスコープ 1 の固定発生源排出量の計算例 100 標準立方フィート (scf) の天然ガスをオーブンで燃焼させたとします。 米国 EPA の固定発生源の排出係数 を使用すると、燃焼に関連するカーボンフットプリントを推定できます。 この場合、排出係数は 0.05449555 Kg CO2e /scf です。 [3] 実質的に無制限の拡張性と高い耐久性を備えている Amazon S3 は、AWS でデータレイクを構築して異種データソースを 1 つのリポジトリに格納するのに理想的です。サーバーレスの対話型クエリサービスである Athena を使用すると、データを Athena にロードしたり、複雑な抽出、変換、ロード (ETL) プロセスを実行したりすることなく、標準的な SQL を使用して直接 Amazon S3 からデータを分析できます。Amazon QuickSight は、Amazon S3 や Athena を含むさまざまなデータソースのビジュアライゼーションを作成したり、カスタム SQL を使用することで柔軟にデータのサブセットを抽出できます。QuickSight ダッシュボードを活用すると、会社の推定されるカーボンフットプリントなどの洞察をすばやく得ることができ、ビジネスとサステナビリティのユーザー向けに標準化されたレポートを生成する機能も提供します。 この例では、次のアーキテクチャ図に示すように、ファイルシステムに保存されている サンプルデータ を AWS Command Line Interface(CLI) を使用して Amazon S3 にアップロードします。AWS では、 セキュリティ、アイデンティティ、コンプライアンスに関するベストプラクティス のガイダンスに従って、AWS リソースを作成し、CLI アクセスを管理することをおすすめします。 以下の AWS CLI コマンドは、サンプルデータのフォルダを S3 のターゲットの場所にアップロードする方法を示しています。 aws s3 cp /path/to/local/file s3://bucket-name/path/to/destination S3 コンソールのスナップショットは、ファイルが含まれる 2 つの新しく追加されたフォルダーを示しています。 新しいテーブルスキーマを作成するために、まず Athena クエリエディタで Hive DDL を使用してガス利用テーブル用に以下のスクリプトを実行します。このスクリプトは、データフォーマット、列の詳細、テーブルプロパティ、そして S3 のデータの場所を定義します。 CREATE EXTERNAL TABLE `gasutilization`( `fuel_id` int, `month` string, `year` int, `usage_therms` float, `usage_scf` float, `g-nr1_schedule_charge` float, `accountfee` float, `gas_ppps` float, `netcharge` float, `taxpercentage` float, `totalcharge` float) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3:///Scope 1 Sample Data/gasutilization' TBLPROPERTIES ( 'classification'='csv', 'skip.header.line.count'='1') 以下のスクリプトは、Hive DDL を使用してガス排出係数データのテーブルスキーマを生成するもう 1 つの例を示しています。 CREATE EXTERNAL TABLE `gas_emission_factor`( `fuel_id` int, `gas_name` string, `emission_factor` float) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3:///Scope 1 Sample Data/gas_emission_factor' TBLPROPERTIES ( 'classification'='csv', 'skip.header.line.count'='1') Athena でテーブルスキーマを作成した後、2020 年のガス利用量とガス公共目的プログラム付加料金 (PPPS) や税引き後の請求額などの関連請求額を示すために、ガス料金の詳細を含むガス利用テーブルに対して、以下のクエリを実行します。 SELECT * FROM "gasutilization" where year = 2020; スクリーンショットに示すように、さまざまな燃料タイプとそれに対応する CO2e 排出量の排出係数データを分析することもできます。 以下のクエリを実行し、ガス利用データと排出係数を使用することで、スコープ 1 の推定カーボンフットプリントとその他の詳細情報を取得できます。このクエリでは、ガス利用テーブルとガス排出係数テーブルを燃料 ID でジョインし、標準立方フィート (scf) で測定されたガス使用量に排出係数を乗じて、推定 CO2e インパクトを算出しました。また、顧客にとって関心のある属性である月、年、請求総額、熱量と scf で測定されたガス使用量も選択しました。 SELECT "gasutilization"."usage_scf" * "gas_emission_factor"."emission_factor" AS "estimated_CO2e_impact", "gasutilization"."month", "gasutilization"."year", "gasutilization"."totalcharge", "gasutilization"."usage_therms", "gasutilization"."usage_scf" FROM "gasutilization" JOIN "gas_emission_factor" on "gasutilization"."fuel_id"="gas_emission_factor"."fuel_id"; 最後に、Amazon QuickSight は、Amazon S3 や Athena を含むさまざまなデータソースのビジュアライゼーションを作成したり、カスタム SQL を使用することで柔軟にデータのサブセットを抽出できます。以下は、年別のガス利用量、ガス料金、推定されたカーボンフットプリントを示す QuickSight ダッシュボードの例です。 ここでは、1 つの固定燃焼源について、スコープ 1 のカーボンフットプリントを推定しました。 すべての固定および移動排出源 (異なる排出係数を使用) について同じプロセスを行い、結果を足し合わせることができれば、ネイティブ AWS サービスと自社データのみを利用して、事業全体のスコープ 1 の炭素排出量の正確な推定値を算出することができます。同様のプロセスにより、スコープ 1 の排出係数の代わりに電力系統の炭素強度を用いて、スコープ 2 の排出量の推定値が得られます。 まとめ このブログでは、組織が異なるソースに存在するデータを使用して、スコープ 1 の温室効果ガス排出量の可視性を向上するためのデータアーキテクチャを構築する方法について説明しました。 Athena、S3、QuickSight を使用することで、組織は消費ベースの方法を適用して燃料利用量を推定されたカーボンフットプリントに変換することにより、固定排出源からのカーボンフットプリントを繰り返し測定可能な方法で推定できるようになりました。 AWS で利用可能なその他のアプローチは、 Carbon Accounting on AWS 、 Sustainability Insights Framework 、 Carbon Data Lake on AWS 、および AWS Carbon Accounting ページ を参照ください。 AWS を活用して組織のカーボンフットプリントの推定する方法について関心がある場合は、AWS アカウント担当に連絡を取り、 AWS Sustainability Solutions をご確認ください。 参考文献 Amazon’s Carbon Methodology ドキュメント の 4 ページ目の例は、この概念を示しています。 トラック輸送にかかる費用: $100,000ドル EPA 排出係数: トラック輸送 1 ドルあたり 1.556 kg CO2e 推定 CO2e 排出量: トラック輸送 $100,000ドル * 1.556 kg CO2e/トラック輸送 1 ドル = 155,600 kg の CO2e ↑ 例えば、 ガソリン消費量: 1,000 US ガロン EPA 排出係数: ガソリン 1 ガロンあたり 8.81 kg の CO2e 推定 CO2e 排出量 = 1,000 USガロン * ガソリン 1 ガロンあたり 8.81 kg のCO2e = 8,810 kg の CO2e。 ガソリンの固定排出源に対するEPA排出係数 は、8.78 kg の CO2 に CH4 が 0.38 グラム、N2O が 0.08 グラムを加えたもの。 これらの排出係数を、各ガスの 100 年地球温暖化係数 (CH4:25、N2O:298) を用いて組み合わせると、合計排出係数 = 8.78 kg + 25 × 0.00038 kg + 298 × 0.00008 kg = ガソリン 1 ガロンあたり 8.81 kgの CO2e となる。 ↑ 1 scf あたりの排出係数は、CO2 が 0.05444 kg、CH4 が 0.00103 g、N2O が 0.0001 g。これを CO2e で表すには、他の 2 つのガスの排出係数にそれぞれの地球温暖化係数 (GWP) を乗じる必要がある。CH4 と N2O の 100 年 GWP はそれぞれ 25 と 298。排出係数と GWP は、 米国 EPAのウェブサイト から得られる。↑ 著者について Thomas Burns は、 SCR 、 CISSP の資格を持ち、Amazon Web Services でサステナビリティ戦略とプリンシパルソリューションアーキテクトを務めています。トーマス氏は、世界中の製造業や工業分野のお客様をサポートしています。トーマス氏は、クラウドを利用して、IT 内外の両方で企業の環境への影響を低減することに注力しています。   Aileen Zheng は、Amazon Web Services (AWS) の米国連邦政府民間科学のお客様を支援するソリューションアーキテクトです。彼女は、エンタープライズクラウドの採用と戦略について技術的なガイダンスを提供し、適切に設計されたソリューションの構築を支援するパートナーです。データアナリティクスと機械学習についても情熱があります。余暇の時間には、ピラティスをしたり、犬のムムを連れてハイキングに出かけたり、おいしい食べ物の場所を探し回ったりしています。また、多様性とテクノロジー分野の女性を支援するプロジェクトにも貢献しています。   この記事は 2023 年 8 月 2 日に Thomas Burns と Aileen Zheng によって投稿された「 Estimating Scope 1 Carbon Footprint with Amazon Athena 」をソリューションアーキテクト佐藤が翻訳したものです。 ※本稿は英語版ブログの翻訳となります。翻訳版にご不明な点がある場合は英語版ブログの内容を正としてください。
3 部構成の本ブログシリーズの 第 1 部 では、Organizations 内のある組織から別の組織にアカウントを移動する際に、ガイダンスと考慮が必要な AWS Organizations のさまざまな機能を確認しました。具体的には、Organizations のポリシー、 AWS Resource Access Manager(AWS RAM) による共有、 AWS グローバル条件コンテキストキーに焦点を当てました。 第 2 部 では、Organizations と連携する AWS サービスの委任管理者として登録されているアカウントを移動したい場合に行うべきこと、確認すべきことについて見てきました。 本ブログでは、現在の組織と移行先組織で AWS サービスに対する信頼されたアクセスが有効化されている場合に、当該組織間で AWS アカウントを移行する際に行うべきこと、確認すべきことを見ていきます。 第 1 部と同様に、 組織からメンバーアカウントを削除 し、 移行先 組織で AWS アカウントを招待 するための Organizations ユーザーガイドで提供される情報を整理していきます。 組織間でアカウントを移動するには、当該 AWS アカウントを現行の組織から削除し、AWS アカウントをスタンドアロンにしてから、移行先の組織への招待を受け入れる必要があります。 組織からアカウントを削除する前に、組織で AWS サービスに対する信頼されたアクセスが有効化されているかどうかを確認することをお勧めします。 本ブログには AWS Command Line Interface (AWS CLI) を利用したコマンド実行例を記載します。実行例を利用するには AWS CLI のインストールと設定を行う必要があります。詳細については、「 AWS CLI の最新バージョンを使用してインストールまたは更新を行う 」を参照してください。 AWS Organizations の信頼されたアクセス 互換性のある AWS サービスにおいて信頼されたアクセスを有効化すると、そのサービスは、組織内のすべての AWS アカウントでドキュメントに記載されている操作を実行できます。 AWS アカウントを削除すると、信頼されたサービスはそのアカウントで操作を実行できなくなります。 組織からアカウントを削除して別の組織に移行する前に、信頼されたサービスに関連する AWS アカウントへの影響を理解し、考慮すべきアクションを把握しておく必要があります。 現在、信頼されたアクセスをサポートしている AWS サービスのリストを本ブログに記載しています。AWS サービスの名前またはサービスのプリンシパル名で検索することができます。AWS サービスの名前または サービスのプリンシパル 名で AWS サービスを見つけることができます。サービスのプリンシパル名は、AWS CLI の list-aws-service-access-for-organization コマンドを使用して取得することが可能です。 以下の AWS CLI の例では、お客様の組織において信頼されたアクセスが有効化されている AWS サービスのリストを取得します。 PROMPT> aws organizations list-aws-service-access-for-organization 現在の組織と移行先組織において信頼されたアクセスが有効化された AWS サービスのリストを取得した後、組織間で 1 つ以上のアカウントを移動する場合に必要なアクションを計画することができます。 アカウントを別の組織に移動する際には、信頼されたアクセスが有効になっている AWS サービスと連携するためにアカウントを設定する必要があるかどうかを確認してください。ほとんどの場合、アカウントや AWS サービスを再構成する必要はありません。以下に提示する現在 Organizations の信頼されたアクセスをサポートしている AWS サービスのリストにおいてそのためのガイダンスを提供します。 トでアカウントに代わって自動的に契約を受諾することはできなくなります。削除されたアカウントは、 組織によって受諾 された AWS Artifact 組織契約にアクセスできなくなり、その対象から外れることになります。管理アカウントは AWS Artifact コンソールの「契約」メニュー内の「組織契約」で組織契約のリストを表示できます。 組織からアカウントを削除する前に、スタンドアロンアカウントや移行先組織で新しい契約を締結する必要があるかを、法務、プライバシー、コンプライアンス等の適切なチームの支援を得て判断してください。移行先組織の複数のアカウントにわたって契約が必要な場合、 AWS Artifact で信頼されたアクセスを有効 にして、必要な契約を受諾したことを確認してください。 AWS Audit Manager: auditmanager.amazonaws.com AWS Audit Manager で 信頼されたアクセス を有効にすると、組織内の複数の AWS アカウントを評価の範囲に含めることで、より幅広いソースから証拠を収集することができます。組織からアカウントを削除すると、 評価 範囲の一部としてそのアカウントから証拠を収集することができなくなります。Audit Manager は、削除に関する通知を受け取り、既存のあらゆる評価の範囲からそのアカウントを自動的に削除します。 アカウントが移行先組織に参加すると、そのアカウントは既存の Audit Manager の評価範囲に自動的には追加されません。既存の評価範囲を見直し、必要に応じてアカウントをリストに追加してください。 AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com AWS CloudFormation StackSets で 信頼されたアクセスを 有効にすると、管理者または委任管理者アカウントは、組織のスタックセットを作成および管理する権限を持っています。組織からアカウントを削除すると、 CloudFormation StackSets は、アカウントに関連する権限を持つサービスリンクロールを使用して、そのアカウントにスタックインスタンスをデプロイできなくなります。 アカウント内に StackSet の一部であるスタックがあり、そのスタックを保持したい場合、移行先組織または組織単位(OU)からアカウントを削除するときの StackSet のアカウント削除動作が「スタックを保持」と設定されていることを確認してください。AWS CLI の describe-stack-set コマンドを使用して RetainStacksOnAccountRemoval の値で削除動作を確認します。true に設定されている場合、アカウントが移行先組織または OU から削除されたときにスタックリソースが保持され、false に設定されている場合、スタックリソースは削除されます。 移行先組織の StackSet に引き続きスタックを含める予定の場合、 StackSet にスタックをインポート できます。移行先組織では、移行元組織の StackSet に使用されたものと同じテンプレートを使用して新しい StackSet を作成します。StackSet を作成するときは、アカウントが配置される OU を含めるようにします。 アカウントを移行先組織に参加させる前に、StackSet 自動デプロイメントの設定を一時的に無効にしましょう。アカウントが組織に参加した時に、インポート対象と同じ内容のスタックが自動でデプロイされてしまうことを防ぐためです。アカウントが移行先組織に参加すると、作成した StackSet にスタックをインポートできます。 インポート後、アカウント内でスタックにステータス「FAILED」の変更セットが含まれていることに気づくでしょう。これはこのインポートで期待されるステータスであり、「The submitted information didn’t contain changes. Submit different information to create a change set」という理由が添えられています。移行先組織の StackSet に参加してもスタックがすでに存在していたためデプロイされず、その後の変更も必要ないためスタックはデプロイされません。 AWS CloudTrail: cloudtrail.amazonaws.com AWS CloudTrail の 信頼されたアクセス を有効にすると、その組織内のすべての AWS アカウントのすべてのイベントを記録する 組織の証跡 を作成できます。組織からアカウントを削除すると、組織の証跡には該当アカウントのイベントが保存されなくなります。そのため、組織から離れる前に アカウントの証跡 をセットアップし、イベントのログを取得できるようにします。移行先組織で組織の証跡が有効になっている場合は、イベントは自動的に組織の証跡に含まれるようになるため、移行先組織に参加した後にアカウントでセットアップした証跡を削除することを検討してください。 AWS Compute Optimizer:compute-optimizer.amazonaws.com AWS Compute Optimizer の 信頼されたアクセス を有効にすると、組織の Compute Optimizer の推奨事項にアクセスし管理することができます。組織からアカウントを削除すると、Compute Optimizer は管理者または委任管理者アカウントから、そのアカウントの推奨事項にアクセスまたは管理できなくなります。アカウントのオプトインのステータスは、組織の一部であったときの設定が保持されます。 アカウントが移行先組織に参加すると、移行先組織の管理者または委任管理者アカウントの Compute Optimizer は、そのアカウントの推奨事項にアクセスし管理することができます。 AWS Config:config.amazonaws.com AWS Config の 信頼されたアクセス を有効にすると、Config アグリゲータ は組織内のアカウントから Config 設定データとコンプライアンスデータを収集できます。組織からアカウントを削除すると、そのアカウントが組織アグリゲータの一部である場合、アグリゲータはそのアカウントから Config 設定データとコンプライアンスデータを収集できなくなります。データは削除される前にアグリゲータアカウントに最大 24 時間保持されます。アカウントに展開された Config ルールやコンフォーマンスパックは削除されます。 AWS Config では、個別アカウントアグリゲータを作成し、1 つ以上のアカウントから Config 設定データおよびコンプライアンスデータを収集する 権限をアカウントに付与 することができます。 当該権限が付与された AWS アカウントを組織から削除しても、他のアカウントから Config 設定データおよびコンプライアンスデータを収集する権限は変更されません。 アカウントが移行先組織に参加すると、既存の Config 組織アグリゲータに含まれるように、アカウントで Config を有効にする必要があります。アカウントが既存の組織の Config ルールおよびコンフォーマンスパックと連携するためには、Config 設定レコーダ が有効になっていることを確認する必要があります。 既存の組織ルールおよびコンフォーマンスパックの展開は、レコーダが使用できない場合、アカウントが移行先組織に追加されてから 7 時間だけ再試行されます。 AWS Control Tower:controltower.amazonaws.com アカウントが AWS Control Tower に登録されている場合、組織からアカウントを削除する前に、Account Factory から 該当アカウントの管理を解除する か、Account Factory for Terraform(AFT)から アカウントを削除 してください。 アカウントがスタンドアロンで組織の一部でなくなっている間に、IAM ロール AWSControlTowerExecution の信頼関係を更新します。ロールの信頼ポリシーのプリンシパルを移行先組織の管理アカウント ID に変更する必要があります。 アカウントが移行先組織に参加し、AWS Control Tower にアカウントを登録する場合、 既存の AWS アカウントを AWS Control Tower に登録するプロセス に従ってください。 Amazon Detective:detective.amazonaws.com Amazon Detective で 信頼されたアクセス を有効にすると、組織 動作グラフ は、組織内のすべてのアカウントのアクティビティを可視化することができます。 組織から削除するアカウントが組織動作グラフのメンバーである場合、そのアカウントはグラフのメンバーとしても削除されます。これは、組織に参加する前に組織動作グラフに招待を受けた場合および組織に参加した後にグラフのメンバーになった場合、いずれの場合も対象となります。招待によってグラフに追加されたアカウントの場合は、そのアカウントがグラフのメンバーであり続けることも、グラフのアカウントメンバーシップを無効にすることも選択することができます。組織動作グラフのメンバーを確認するには、AWS CLI の list-members コマンドを使用してメンバーの一覧を取得したり、組織動作グラフの Amazon リソース名(ARN) を取得するために AWS CLI の list-graphs コマンドを使用できます。どちらのコマンドも、組織の管理アカウントまたは Detective の委任管理者アカウントの資格情報のいずれかを使用する必要があります。 アカウントがグラフのメンバーから削除されると、Detective はデータの取り込みを停止しますが、アカウントから取得した既存のデータはグラフに残ります。 招待による別の組織のグラフへのメンバーシップは、組織に参加または離脱しても影響を受けません。たとえば、アカウントが移行先組織のグラフのメンバーである場合、移行元組織を離れると、そのアカウントは移行元組織のグラフのメンバーではなくなりますが、移行先組織のグラフのメンバーのままとなります。組織からアカウントを削除する際、Detective がアカウントで有効になっている場合、Detective は有効なままで、アカウントの動作グラフの内容と設定はすべて保持されます。 組織間の移動中に組織からアカウントの可視性を保持するには、組織からアカウントを削除する前に、移行先組織のグラフに招待によってアカウントをメンバーとして追加することを検討します。アカウントが動作グラフのメンバーになると、初回の抽出の場合、データは通常 24 時間以内にグラフで利用可能になります。 移行先組織において Detective が新しい組織のアカウントを組織動作グラフのメンバーアカウントとして 自動的に有効化 にするように構成されている場合、アカウントが組織に参加するとアカウントは「By organization」グラフの有効なメンバーとなります。アカウントが招待によってグラフのメンバーだった場合、アカウントのメンバーシップは保持され、メンバーシップの種類は「By invitation」から「By organization」に変更されます。 アカウントが組織グラフのメンバーとして設定されていない場合、グラフにアカウントを招待することができ、同じ組織の一部であればアカウントは自動的に招待を受け入れます。 Amazon DevOps Guru: devops-guru.amazonaws.com Amazon DevOps Guru の 信頼されたアクセス を有効にすると、組織全体にわたってインサイトを管理することができます。アカウントが組織を離れ、そのアカウントで DevOps Guru が有効にされている場合、組織の管理アカウントまたは DevOps Guru 委任管理者は、アカウント内のすべての監視対象アプリケーションの健全性に関する全体的なビューを作成するために、アカウントからのインサイトを表示、並べ替え、フィルタリングすることができなくなります。 アカウントが移行先組織に参加し、アカウントで DevOps Guru が有効にされている場合、管理アカウントまたは DevOps Guru 委任管理者は、自動的にアカウントを組織で監視する対象に含めます。 AWS Directory Service:ds.amazonaws.com AWS Directory Service の 信頼されたアクセス を有効にすると、 AWS Managed Microsoft Active Directory(AD) ディレクトリを複数のアカウントでシームレスに共有することができます。1 つのディレクトリを同じ組織内の他の信頼済み AWS アカウントと共有したり、組織外の他の AWS アカウントとディレクトリを共有したりできます。 AWS Organizations またはハンドシェイクのいずれの 共有方法 でもディレクトリの利用者であるアカウントが組織から削除された場合、ディレクトリは引き続きそのアカウントと共有されています。 アカウントが、1 つ以上の AWS Managed Microsoft AD ディレクトリを持つ移行先組織に参加するとき、ディレクトリは自動的にアカウントと共有されません。AWS Directory Services コンソールまたは AWS CLI の share-directory コマンドのいずれかを使用して、アカウントとディレクトリを共有することができます。 AWS Firewall Manager:fms.amazonaws.com AWS Firewall Manager の 信頼されたアクセス を有効にすると、Firewall Manager 管理者 アカウントを使用して、AWS Organizations 内のすべての Firewall Manager セキュリティポリシーを管理することができます。アカウントが組織を離れると、Firewall Manager はアカウント内でサポートされている操作を実行できなくなります。 アカウントが Firewall Manager ポリシー の範囲内にあった場合、アカウントはポリシーと関連付けられなくなり、Firewall Manager 管理者アカウントにコンプライアンスステータスが表示されなくなります。 組織からアカウントを削除する前に、Firewall Manager の ポリシーの範囲 がアカウント内のリソースや保護を保持するように構成されていることの確認をお勧めします。アカウントが組織から離れると、ポリシーの範囲から離れ、管理されなくなりますが、Firewall Manager が自動的に保護を削除したり、Firewall Manager が管理するリソースを削除しないように設定することができます。 このオプションは「 Resource cleanup 」で設定を行いますが、保護を保持するためには「 Automatically remove protections from resources that leave the policy scope. 」を無効にする必要があります。このオプションは、 DNS Firewall 、 Network Firewall 、 セキュリティグループ (共通)、 WAF などのサポートするポリシータイプで Firewall Manager コンソールから確認できます。 ポリシータイプ WAF Classic、および Shield Advanced には、このオプションはありません。デフォルトでは、リソースに関連付けられている WAF の Web ACL は保持され、リソースを含まない Web ACL は削除されます。 アカウントで Shield Advanced ポリシーが有効化されている場合、そのアカウントが組織を離れると、そのアカウントは Shield Advanced 用に構成された Firewall Manager ポリシーの対象外となります。アカウントで Shield Advanced を サブスクライブ している場合、スコープ内のリソースは引き続き保護されます。組織を離れた後、アカウントは組織の一括請求の対象外となり、Shield Advanced のサブスクリプション料金の日割り料金がアカウントで引き続き発生します。移行元組織のサブスクリプション料金を引き続き支払い、アカウントが移行先組織に参加したときには新規または既存のサブスクリプション料金を支払うことになります。移行元組織を削除する予定がある場合、AWS サポートケースを作成して、移行先組織において Shield Advanced サブスクリプションを統合することができます。 Network Firewall または DNS Firewall ポリシーが設定されている場合、Firewall Manager は AWS Resource Access Manager (AWS RAM) を使用して Network Firewall および DNS Firewall ポリシーで設定されたルールグループを組織全体のアカウントと共有します。 アカウントが組織を離れると、ポリシーで設定したルールグループはそのアカウントと共有されなくなります。Network Firewall または DNS Firewall のポリシー範囲の設定における「 Resource cleanup 」オプションで「 Automatically remove protections from resources that leave the policy scope. 」が無効に設定されている場合、ポリシールールグループの ID と設定は、 AWS Network Firewall または Amazon Virtual Private Cloud (VPC) のいずれかの対応するリソースに関連付けられたままとなります。ただし、AWS RAM 共有とアカウントとの関連付けが解除されると、ルールグループを表示する権限が削除されるため、アカウントでルールグループを表示することはできなくなります。 アカウントを移行先組織に移動する前に、移動元組織で特定した各ポリシータイプごとに、移動するアカウントに適用される同等の Firewall Manager ポリシーが作成または更新されていることを確認してください。移行先組織では、WAF および WAF Classic ポリシータイプを設定して、ポリシーの範囲内のリソースに現在関連付けられている既存の Web ACL を置き換えるポリシーアクションを使用することができます。このオプションを使用して移行元組織のポリシーによって適用された Web ACL を置き換えることができます。既存の関連づけられた Web ACL を置き換えることを選択した場合、Firewall Manager は別のアクティブな Firewall Manager ポリシーによって管理されていない Web ACL をポリシーの範囲内のリソースから関連付け解除します。DNS Firewall ポリシー タイプを設定する場合、ルールグループの優先度を移行元組織のポリシーと異なるように設定します。ルールグループの優先度が一致している場合、ルールの優先度が競合するため、移行先組織ポリシーをアカウント内の Amazon VPC に適用することはできません。 移動するアカウントにおいて、移行元と移行先組織のポリシーで作成されたリソースと保護を受け入れるための AWS サービスの クォータ を確認する必要もあります。 移行元組織によってアカウントに設定されている現在のポリシー適用リソースや保護の現在の数の少なくとも 2 倍を許容するために、リージョンごとにアカウントの調整可能なクォータを一時的に増やすことを計画します。そのためにはアカウントの現在の使用状況を考慮する必要があり、それには、Network Firewall( 調整可能なクォータ )、Amazon VPC(サブネットのクォータ)、セキュリティグループ(AWS リージョンごとの VPC セキュリティグループとネットワークインターフェースごとのセキュリティグループの クォータ )、WAF(Web ACL とルールグループの クォータ )、WAF Classic(Web ACL とルールグループのクォータ)、Shield Advanced( 調整可能なクォータ )、Route 53 Resolver DNS Firewall ( 調整可能なクォータ )などの AWS サービスが含まれます。クォータの増加により、移行元組織のポリシーで作成された既存のリソースや保護、および移行先組織のポリシーで新たに作成されたリソースや保護が共存できるようになります。 移行元組織のポリシー範囲の設定で「 Resource cleanup 」オプションで「 Automatically remove protections from resources that leave the policy scope. 」を無効に設定した場合、移行元組織のポリシーにより作成されたリソースと保護は組織から離脱後も残ります。移行元組織のポリシーによって作成されたリソースが、移行先組織で適用されるポリシーで再利用されることはありません。 アカウントを移行元組織に再度参加させ、Firewall Manager 委任管理者となり、アカウントが移行元組織を離れてから Firewall Manager のポリシーが変更されていない場合、そのポリシーはアカウントが以前組織に所属していたときに作成された既存のリソースを再利用します。 移行先組織のポリシーが移行元組織によって提供されたポリシーリソース構成を複製する場合、移行元組織のポリシーによって作成されたリソースまたは関連する保護を削除することを選択できます。移行元組織のポリシーによって作成されたリソースや保護を発見するには、ポリシーの適用範囲となっているリージョンで、ポリシータイプに適用可能なリソースや保護を確認する必要があります。Firewall Manager ポリシーによって作成されたリソースは、各ポリシータイプごとに特定の命名規則を使用します。これにはプレフィックス「 FMManaged 」が含まれ、ポリシータイプに応じてポリシー名またはポリシー ID、またはその両方を含むことがあります。 ポリシー名 (PolicyName) とポリシー ID (PolicyId) などのポリシーメタデータは、移行元組織の Firewall Manager 管理者アカウントで AWS CLI の list-policies コマンドを使用してポリシーをリストアップし確認することができます。 移行元組織の Firewall Manager ポリシーによって作成されたリソースや保護を削除する前に、同等の移行先組織のポリシーがアカウントに適用されていることを確認してください。ポリシーが移行元組織のセキュリティ設定と一致し、アカウントの Firewall Manager ポリシーの 準拠ステータス が「 Compliant 」であることを確認してください。これは、ポリシー範囲に該当するアカウントのすべてのリソースにポリシーが正常に適用されていることを意味します。AWS CLI の list-compliance-status コマンドを使用して、指定したポリシーによって保護されているメンバーアカウントとその準拠ステータスの概要を取得できます。 アカウントが移行元組織の Firewall Manager 管理者の管理下から完全に解除され、移行先組織の Firewall Manager 管理者によって完全に管理されるまで最大 5 時間かかる場合があります。 ポリシーによって作成されたリソースや保護の関連付けを識別するために、サポートされているポリシータイプごとに、ポリシーによって作成されたリソースの命名規則と、アカウント内の適用可能なリソースや関連付けのリストを取得するための AWS CLI コマンドを以下にリストアップしました。 AWS Network Firewall ポリシータイプ ポリシーによって、FMManagedNetworkFirewall <policy-name><policy-id><vpc-id> の命名規則でファイアウォールが作成されます。 <policy-name> 、 <policy-id> を移行元組織の AWS Network Firewall タイプのポリシーのポリシー名とポリシー ID に置き換えます。アカウント内のファイアウォールの情報は AWS CLI の list-firewalls コマンドを使用して取得できます。 ファイアウォールポリシーは FMManagedNetworkFirewallPolicy <policy-name><policy-id><vpc-id> の命名規則でポリシーによって作成されます。移行元組織の AWS Network Firewall タイプのポリシーのポリシー名とポリシー ID で <policy-name> 、 <policy-id> を置き換えます。AWS CLI の list-firewall-policies コマンドを使用して、ファイアウォールポリシーの情報を取得できます。AWS Network Firewall ポリシータイプが適用されると、設定されている場合 Network Firewall が使用する VPC エンドポイントを含む Amazon VPC のサブネットが作成されます。サブネットは、AWSFirewallManagerManagedResource を含む命名規則で作成されます。AWS CLI の describe-firewall コマンドを使用して、Network Firewall に関連付けられた 1 つ以上のサブネットを含むファイアウォールの情報を取得することができます。 WAF ポリシータイプ WAF Web ACL は、FMManagedWebACLV2- <policy-name> の命名規則でポリシーによって作成されます。 <policy-name> を移行元組織の WAF タイプのポリシーのポリシー名に置き換えます。AWS CLI の list-web-acls コマンドを使用して、アカウント内の WAF Web ACL を取得することができます。 WAF Classic ポリシータイプ WAF Classic Web ACL は、FMManagedWebACL <policy-id> の命名規則でポリシーによって作成されます。 <policy-id> を移行元組織の WAF Classic タイプのポリシーのポリシー ID に置き換えます。AWS CLI の list-web-acls コマンドを使用して、アカウント内の WAF Classic Web ACL を取得することができます。 Security group – common ポリシータイプ セキュリティグループは、FMManagedSecurityGroup <policy-id><security-group-id><vpc-id> の命名規則でポリシーによって作成されます。 <policy-id> を移行元組織の Security group – common タイプのポリシーのポリシー ID に置き換えます。AWS CLI の describe-security-groups コマンドを使用して、アカウント内のセキュリティグループを取得することができます。セキュリティグループを削除する前に、リソースからセキュリティグループの関連付けを解除しておく必要があります。 Shield Advanced ポリシータイプ Shield Advanced の保護は、FMManagedShieldProtection <policy-id> の命名規則でポリシーによって作成されます。 <policy-id> を移行元組織の Shield Advanced タイプのポリシーのポリシー ID に置き換えます。AWS CLI の list-protections コマンドを使用して、アカウント内の保護を取得することができます。 DNS Firewall ポリシータイプ ポリシーに関連する DNS Firewall ルールグループは AWS RAM を使用して共有されており、アカウントが組織から離脱する際に削除されます。AWS CLI の list-firewall-rule-group-associations コマンドを使用して Amazon VPC との DNS Firewall ルールグループの関連付けをリストアップすることにより、移行元組織の DNS Firewall ルールグループを特定できます。DNS Firewall ルールグループの CreatorRequestId を移行元組織の DNS Firewall ポリシーのポリシー ID と照合します。その後、発見した DNS Firewall グループの関連 ID を使用し、AWS CLI の disassociate-firewall-rule-group コマンドで移行元組織のルールグループとの関連付けを解除できます。 Amazon GuardDuty:guardduty.amazonaws.com Amazon GuardDuty の 信頼されたアクセス を有効にすると、AWS Organizations を使用して組織内のすべてのアカウントの GuardDuty を管理することにより管理を簡素化することができます。GuardDuty 管理者に関連付けられたアカウントが組織を離れると、関連付けられた各リージョンの管理者から自動的に関連付けが解除されます。GuardDuty 管理者アカウントはもうそれらのアカウントを管理できませんが、各アカウントの GuardDuty のステータスは管理者によって設定されたままとなります。また、各アカウントの GuardDuty の調査結果や使用データは、GuardDuty 管理者アカウントには含まれなくなります。 アカウントが移行先組織に参加する場合、組織の GuardDuty を有効にし、GuardDuty の 自動有効化 機能を設定した各リージョンで、アカウントは自動的に GuardDuty 管理者のメンバーアカウントとして関連付けられます。アカウントで GuardDuty が有効になり、ソースの設定および S3 Protection や Kubernetes Audit Logs Monitoring のオプションが設定されます。アカウントがメンバーアカウントとして関連付けられていない場合、GuardDuty コンソールや AWS CLI の create-members コマンドを使用して、必要な各リージョンにおいて管理者アカウントから 手動でメンバーアカウントとして追加 することができます。 追加されたアカウントにおいて AWS CLI の get-administrator-account コマンドを使用し、アカウントの GuardDuty 管理者アカウントの詳細を確認したり、AWS CLI の list-detectors コマンドを使用して GuardDuty の Finding ID を見つけることができます。アカウントがリージョンにおける管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID や関連のステータスが「有効」として表示されません。 AWS Health:health.amazonaws.com AWS Health の 信頼されたアクセス を有効にすると、組織内のすべてのアカウントで AWS Health のイベントを集約できます。Health の組織ビューを設定している場合、アカウントが組織を離れると、アカウントからの新しいイベントは組織ビューに含まれなくなります。ただし既存のイベントは 90 日の制限まで照会できるように、組織ビューに残ります。アカウントが移行先組織に参加すると、アカウントからのイベントは有効な Health の組織ビューに含まれるようになります。 AWS IAM Access Analyzer:access-analyzer.amazonaws.com AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) の 信頼されたアクセス を有効にしている場合、組織全体でリソースベースのポリシーを分析し、信頼ゾーン外のプリンシパルへのアクセスを許可するポリシーを特定できます。アカウントが IAM Access Analyzer の組織における信頼ゾーンの一部である場合、組織を離れると、組織の信頼ゾーンでの調査結果は生成されなくなります。組織の移行中、信頼ゾーンとしてスタンドアロンのアカウントを使用して アナライザーを作成 することもできます。アカウントが移行先組織に参加すると、組織を信頼ゾーンとして設定したアナライザーが既に作成されている場合、アカウントは分析されるリソースのセットに含まれます。 AWS IAM Identity Center(AWS Single Sign-On の後継): sso.amazonaws.com AWS IAM Identity Center (AWS Single Sign-On の後継)の 信頼されたアクセス を有効にすると、ユーザーがシングルサインオン (SSO) で AWS アカウントやクラウドアプリケーションにアクセスする複数の AWS アカウントを選択できます。アカウントが組織を離れると、IAM Identity Center の使用可能なアカウントのリストに含まれなくなり、共通の権限セットをデプロイしたり、管理アカウントまたは委任管理者アカウントからアクセスを管理することができなくなります。IAM Identity Center は、アカウント内の IAM Identity Center のサービスリンクロールを含むアカウントのメタデータやリソースを自動的にクリーンアップします。アカウントは IAM Identity Center とは連携しなくなり、設定されたアイデンティティソース用の AWS アクセスポータルを使用してアカウントにアクセスすることはできなくなります。 アカウントが移行先組織に参加する場合、アカウントの IAM Identity Center でユーザーやグループに対して必要な権限や割り当てを設定する必要があります。 Amazon Inspector:inspector2.amazonaws.com Amazon Inspector の 信頼されたアクセス を有効にすると、組織でアカウントを管理し、組織を代表してタスクを実行することができます。このタスクには、メンバーアカウントのスキャンの有効化または無効化、組織全体で集約された検出結果データの表示、抑制ルールの作成と管理が含まれます。Inspector 管理者に関連付けられたアカウントが組織を離れると、関連付けられた各リージョンの管理者から自動的に関連付けが解除されます。Inspector の管理者アカウントは、アカウントを管理することはできなくなりますが、スキャン設定を含むアカウント内の Inspector のステータスは、管理者によって設定されたままとなります。アカウントの Inspector の検出結果は、Inspector の管理者アカウントには含まれなくなります。 アカウントが移行先組織に参加する場合、組織で Inspector を有効にしてスキャンの 自動有効化 を設定している各リージョンごとに、アカウントは自動的に Inspector のメンバーアカウントとして関連付けられます。アカウントで Inspector が有効になり、設定されていれば、EC2 のスキャンや ECR のコンテナのスキャンの有効化を含む選択されたスキャンの設定が適用されます。アカウントが関連付けられていない場合、管理者アカウントと各リージョンで Inspector のコンソールや AWS CLI の associate-member コマンドを使用して 手動でメンバーアカウントとして登録 することができます。追加されたアカウントの権限を使用して、AWS CLI の get-delegated-admin-account コマンドを使用してアカウントに関連づけられた Inspector の管理者アカウントの詳細を確認することができます。アカウントがリージョンの管理者に関連付けられていない場合、コマンドの出力は管理者のアカウント ID や「有効」という関係ステータスを表示しません。 AWS License Manager : license-manager.amazonaws.com , license-manager.member-account.amazonaws.com AWS License Manager の 信頼されたアクセス を有効にすると、組織全体でのライセンス使用とリソース検出を管理するために、 クロスアカウントのリソース検出 を有効にできます。 アカウントが組織を離れると、License Manager はアカウントのライセンス使用を管理するためのリソース検出を行うことができなくなります。License Manager のセルフマネージドライセンスをアカウントと共有している場合、License Manager によって設定された AWS Resource Access Manager(AWS RAM) の共有は、自動的にアカウントから解除されます。 セルフマネージドライセンス は、当該アカウントと共有されなくなります。必要に応じて、License Manager による AWS RAM 共有の設定を変更し、削除されたアカウントを追加してセルフマネージドライセンスの共有を継続することができますが、削除されたアカウントで License Manager の共有の招待を受け入れる必要があります。 アカウントが移行先組織に参加する場合、組織の全アカウントのライセンス使用を管理するために、License Manager のクロスアカウントのリソース検出を有効にした各 AWS リージョンで、アカウントは自動的にリソース検出の範囲に含まれます。組織でセルフマネージドライセンスを共有しており移行したアカウントと共有したい場合、アカウントを含めるために License Manager による AWS RAM 共有の設定を変更する必要があるかもしれません。アカウントは組織のメンバーとして、License Manager の AWS RAM 共有に参加する招待を自動的に受け入れます。このブログシリーズの第 1 部では、オーナーアカウントとコンシューマーアカウントの両方で、組織間の移動時の考慮事項と AWS RAM リソース共有について取り上げています。本ブログでは AWS Marketplace セクションで、License Manager を使用して組織と ライセンス許諾 を配布する方法についても取り上げています。 Amazon Macie:macie.amazonaws.com Amazon Macie の 信頼されたアクセス を有効にすると、組織内のアカウントの Macie を有効化し集中管理することができます。Macie 管理者 として関連づけられたアカウントが組織を離れると、各 AWS リージョンにおいて管理者から自動的に 関連付けが解除 されます。また、 Macie 管理者アカウント は、アカウントの管理を行ったり、特定の Macie の設定、データ、リソースにアクセスすることはできなくなります。アカウントの Macie のステータスは、管理者によって以前に設定されたまま保持されます。アカウントの Macie サマリーと所見は、Macie 管理者アカウントには含まれなくなります。 アカウントが移行先組織に参加する場合、組織の Macie を有効にし、 自動有効化 を設定した各 AWS リージョンで、Macie はアカウントで有効になり、自動的に Macie 管理者メンバーアカウントとして関連付けられます。アカウントが関連付けられていない場合、管理者アカウントで必要な各 AWS リージョンを使用し、Macie コンソールまたは AWS CLI の create-member コマンドを使用して 手動でメンバーアカウントとして追加 できます。 追加されたアカウントの権限で AWS CLI の get-administrator-account コマンドを使用し、Macie 管理者アカウントの詳細を確認できます。アカウントが AWS リージョンの管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID やステータス「Enabled」は含まれません。 AWS Marketplace : license-management.marketplace.amazonaws.com AWS Marketplace の 信頼されたアクセス を有効にすると、 Marketplace 製品サブスクリプションの 付与されたライセンス を組織のメンバーアカウント間で配布することができます。Marketplace の付与されたライセンスは、使用権、つまりエンタイトルメントを配布するために AWS License Manager を使用して組織と共有されます。 アカウントが組織を離れる際、そのアカウントが License Manager で共有された Marketplace 製品から付与されたライセンスエンタイトルメントの受領者である場合、そのエンタイトルメントはアカウントで利用できなくなります。関連する Marketplace サブスクリプションは、組織を離れたアカウントで製品を起動するために使用することはできなくなります。組織または組織単位 (OU) の一部としてアカウントにライセンスが配布された場合、そのアカウントのライセンス付与ステータスは「削除済み」 (付与者によって削除) と表示されます。個々のアカウント ID を使用して配布された場合は、ライセンス付与ステータスは「無効」(使用するためにアクティブ化されていない)と表示されます。サブスクリプションを使用して起動した製品は、Amazon Machine Image(AMI)、コンテナ、機械学習、データ製品に関連する AWS リソースを含めアカウントに残ります。 アカウントが移行先組織に参加すると、License Manager の共有エンタイトルメントが配布され、組織または OU の Marketplace 製品の使用権がアカウントに設定されます。組織の一部として、付与は自動的に受け入れられ、アカウントによって使用されるためにアクティブ化されます。 Marketplace 製品のサブスクライバーアカウントを移行先組織に移動し、License Manager を使用して組織のメンバーアカウントにエンタイトルメントを配布している場合、受領者アカウントが組織から削除されると、ライセンスは受領者アカウントに配布されなくなります。受領者アカウントでライセンスを使用できる能力を示すグラントステータスは「無効」(使用のためにアクティブ化されていない)と表示されます。サブスクライバーと同じ移行先組織にグラントの受領者アカウントを移動する場合、まず受領者アカウントで License Manager を使用してサブスクライバーアカウントからのグラントステータスを確認します。グラントステータスが「無効」であれば、ライセンスをアクティブ化することを選択できます。グラントステータスが「削除済み」であれば、グラントの受領者アカウントに付与するためにサブスクライバーアカウントで新たなグラントを作成することができます。 移行先組織に移動するアカウントが License Manager 委任管理者 アカウントである場合、そのアカウントが組織を離れる前に License Manager の委任管理者を解除する必要があります。委任管理者を解除すると、アカウント間のリソース検出とライセンス管理は削除されます。アカウントが Marketplace のサブスクライバーアカウントで、License Manager のグラントを使用して組織、OU、または個々のアカウントにエンタイトルメントを配布している場合、受領者アカウントのグラントステータスは「無効」(使用するためにアクティブ化されていない)と表示されます。アカウントが移行先組織に参加し、License Manager の委任管理者が設定されていない場合、そのアカウントを委任管理者として登録することを選択できます。アカウントを登録すると、組織全体、OU または個々のアカウントに Marketplace ライセンスのエンタイトルメントを配布するためのグラントを作成できます。アカウントを委任管理者に登録しない場合は、組織内の必要な個々のアカウントに対して 1 つ以上のグラントを作成できます。 AWS Network Manager:networkmanager.amazonaws.com AWS Network Manager の 信頼されたアクセス を有効にすると、任意の AWS アカウントに対して単一のグローバルネットワークを作成し、1 つまたは複数のアカウントから 1 つ以上の AWS Transit Gateway を登録することができます。アカウントが組織を離れると、Network Manager はそのアカウント内のネットワークリソースを一元的に管理、監視、可視化することができなくなります。Network Manager のグローバルネットワークから登録された Transit Gateway は、登録解除されます。Transit Gateway アタッチメント( VPC、VPN 接続、AWS Direct Connect Gateway など)は、グローバルネットワークに含まれなくなります。 アカウントが移行先組織に参加する場合、Network Manager のグローバルネットワークにアカウントが保持する 1 つまたは複数の Transit Gateway を含めるには、各 Transit Gateway を登録する必要があります。 AWS Security Hub:securityhub.amazonaws.com AWS Security Hub の 信頼されたアクセス を有効にすると、組織のすべてのアカウントで自動的に Security Hub を有効にし、Security Hub のチェックと検出結果の対象範囲を拡大することができます。Security Hub 管理者に関連付けられているアカウントが組織を離れると、それぞれの AWS リージョンで管理者から自動的に関連づけが解除されます。 Security Hub 管理者アカウント は組織を離れたアカウントを管理できなくなりますが、有効にされた標準やコントロールは管理者が以前に設定したままとなります。アカウントの Security Hub 検出結果やデータは、Security Hub 管理者アカウントに含まれなくなります。 アカウントが移行先組織に参加すると、その組織で Security Hub を有効にし、 自動有効化 を設定した各 AWS リージョンについて、そのアカウントは自動的に Security Hub 管理者のメンバーアカウントとして関連付けられます。Security Hub はアカウントで有効にされ、設定されている場合は選択された標準とコントロールが有効になります。メンバーアカウントとして関連付けられていない場合は、必要な各 AWS リージョンについて、管理者アカウントの Security Hub コンソールを使用して、 手動でメンバーアカウントとして追加 することができます。 参加したアカウントの認証情報で AWS CLI の get-administrator-account コマンドを使用して、アカウントの Security Hub 管理者アカウントの詳細を確認できます。 アカウントが AWS リージョンの管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID やメンバーステータス「 Enabled 」は含まれません。 Amazon S3 Storage Lens: storage-lens.s3.amazonaws.com Amazon S3 Storage Lens の 信頼されたアクセス を有効にすると、組織内のすべての AWS アカウントでストレージ、使用状況、アクティビティのメトリクスを収集および分析できます。 アカウントが組織を離れると、組織のスコープで作成した ダッシュボード はそのアカウントからのデータは更新されなくなりますが、Amazon S3 Storage Lens の 保持期間 に従って過去のデータが参照可能です。アカウントのデフォルトダッシュボードは、アカウントのデータによって引き続き更新されます。 アカウントが移行先組織に参加すると、ダッシュボードのスコープに組織内の全アカウントが含まれる場合、そのアカウントは自動的に S3 Storage Lens ダッシュボードに含まれるようになります。 AWS Service Catalog:servicecatalog.amazonaws.com AWS Service Catalog の 信頼されたアクセス を有効にすると、組織全体で ポートフォリオ の共有や 製品 のコピーを簡単に行うことができます。 移行元組織で Service Catalog 共有ポートフォリオ を利用している場合、アカウントが組織を離れてもプロビジョニングされた製品は保持されます。組織のエンティティ(組織のルート、組織単位( OU )、または組織アカウントなど)を使用して共有された Service Catalog ポートフォリオは、そのアカウントから自動的に共有解除されます。組織からアカウントを削除した後、そのアカウントでプロビジョニングされた Service Catalog 製品の管理を続ける必要がある場合、個別のアカウント用にポートフォリオ共有を作成できます。共有されたアカウントでは、ポートフォリオをインポートし、アカウント内のプリンシパルで製品に対する権限を更新する必要があります。このブログシリーズの第 2 部では、Service Catalog 共有製品を別の組織に移行する方法について説明しています。 Service Catalog AppRegistry は、AWS Resource Access Manager (AWS RAM) を使用してアプリケーションと属性グループを共有します。アカウントが組織を離れると、組織エンティティを使用して共有された Service Catalog AppRegistry リソースは、そのアカウントから共有解除されます。共有アプリケーションに追加されたアカウントの関連リソースコレクションや属性グループはすべて削除されます。このブログシリーズの第 1 部では、所有者と消費者アカウントの両方に対して、組織間で移動する際の AWS RAM リソース共有と考慮事項について説明しています。 アカウントが移行先組織に参加すると、組織ルート、組織単位、組織アカウントなどの組織エンティティを使用して共有されている Service Catalog ポートフォリオ、AppRegistry アプリケーション、属性グループリソースは自動的にアカウントに共有されます。 Service Quotas:servicequotas.amazonaws.com Service Quotas の 信頼されたアクセス を有効にすると、アカウント作成時に自動的にクォータ増加をリクエストするためのクォータリクエストテンプレートを作成することができます。アカウントが組織を離れた場合、クォータリクエストテンプレートから適用されたクォータリクエストは影響を受けません。クォータリクエストテンプレートは、組織内で新しく作成されたアカウントにのみ適用されます。 アカウントが移行先組織に参加した場合、既存のアカウントのクォータは影響を受けません。 AWS Systems Manager: ssm.amazonaws.com , opsdatasync.ssm.amazonaws.com AWS Systems Manager の 信頼されたアクセス を有効にすると、組織内のすべての AWS アカウントで Systems Manager Explorer 、 Change Manager 、 OpsCenter の機能を使用できます。 複数のアカウントからデータを収集するために、Systems Manager Explorer リソースデータ同期 を作成した場合、アカウントが組織を離れると、そのアカウントはリソースデータ同期の対象から除外され、Systems Manager Explorer ダッシュボードに同期される運用データに含まれなくなります。アカウントが移行先組織に参加すると、そのアカウントの Change Manager 変更要求は Systems Manager Explorer の既存のリソースデータ同期に含まれるようになります。 Systems Manager Change Manager を設定した場合、複数の AWS アカウントおよび AWS リージョン全体で変更を管理できます。アカウントが組織を離れると、そのアカウントに対する変更管理フレームワークを使用することはできなくなり、アプリケーションの設定やインフラストラクチャへの運用変更のリクエスト、承認、実装、報告ができなくなります。承認された後すぐに、またはスケジュールされた時間に実行されるよう設定された既存の変更リクエストは、そのアカウントを対象としなくなります。アカウントが対象の組織に参加すると、アカウント ID が指定されているか、変更リクエストで指定された組織単位(OU)の一部である場合に、Change Manager の変更リクエストはスケジュール通り、または承認されたとおりに実行されます。 組織メンバーアカウント間で OpsCenter を使用して OpsItems を操作するための Systems Manager OpsCenter を設定した場合、アカウントが組織を離れると、OpsCenter はそのアカウントの OpsItems を作成、表示、更新したり、OpsItems で指定された AWS リソースの詳細情報を表示したり、 Systems Manager Automation ランブックを開始することはできなくなります。 アカウント間で OpsItems を操作するための権限を設定し、 AWS Systems Manager ユーザーガイド にある アカウント間で OpsItems を操作するためのアクセスと権限を設定する ガイドに従った場合、アカウント間で OpsItems を操作するための権限は AWS CloudFormation スタックセットを使用して設定され、アカウント間で OpsItems を操作するためのアクセス許可をユーザーに与える OpsItemGroup リソースポリシーと IAM 実行ロールを作成します。スタックセットは組織管理アカウントで作成され、各組織メンバーアカウントにポリシー OpsItemCrossAccountResourcePolicy を持つ OpsItemCrossAccountExecutionRole が作成されます。 組織からアカウントを削除する前に、組織管理アカウントを使用して AWS CloudFormation コンソールで StackSet の自動デプロイ設定を確認し、必要に応じて「アカウント削除動作」を「スタックの削除」に設定します。これにより、組織からアカウントが削除された場合、アカウント内のスタックインスタンスが削除されます。これにより、組織管理アカウントと設定済みの Systems Manager 委任管理者アカウントで操作するために設定された OpsItemGroup リソースポリシー、および構成された Systems Manager 委任管理者アカウントが削除されます。 アカウントが対象組織に参加すると、Systems Manager ガイドに従っている場合、StackSet はアカウント ID がスコープ内であれば自動的にデプロイされ、移行先組織の管理アカウントおよび Systems Manager 委任管理者アカウントで操作するために、 OpsItemGroup リソースポリシーと IAM 実行ロールが設定されます。 Systems Manager ガイド( アカウント間で OpsItems を操作するためのアクセスと権限を設定する )を使用せずにアカウント間で OpsItems を操作する権限を設定した場合、アカウント間で OpsItems を操作する権限を更新する必要があります。これには、作成された AWS IAM ロールと OpsItemGroup リソースポリシーが含まれます。 アカウントが組織の一部でなくなった場合、IAM ロールの信頼関係を更新し、信頼されたエンティティの プリンシパル および 条件 を移行先組織の管理アカウント ID、および設定されている場合は委任管理者アカウント ID に設定します。また、AWS アカウントが OpsCenter の運用作業項目(OpsItems)を表示および操作できるようにする OpsItemGroup リソースポリシーも更新する必要があります。リソースベースの JSON ポリシー内のプリンシパル要素を変更し、移行先組織アカウント ID および設定されている場合は Systems Manager 委任管理者アカウント ID を指定します。AWS CLI の get-resource-policies コマンドを使用して OpsItemGroup リソースポリシーを表示し、 put-resource-policy コマンドを使用してリソースポリシーを作成または更新できます。両方のコマンドで、 OpsItemGroup リソースポリシーの Amazon リソースネーム(ARN) を指定します。これは、arn:aws:ssm: <region>:<account-ID> :opsitemgroup/default の形式で、<region> はポリシーを適用する OpsItemGroup リソースの AWS リージョン、<account-ID> はリソースポリシーを更新する AWS アカウント ID です。Systems Manager OpsCenter で OpsItemGroup リソースポリシーをサポートする各 AWS リージョンでリソースポリシーを更新する必要があります。 アカウントが移行先組織に参加すると、アカウント間で OpsItems を操作する権限を設定した場合、管理アカウントまたは Systems Manager 委任管理者アカウントは、アカウント内の OpsItems を操作するために IAM ロールとリソースポリシーを設定できます。 AWS Trusted Advisor:reporting.trustedadvisor.amazonaws.com AWS Trusted Advisor の 信頼されたアクセス を有効にすると、組織内のすべてのアカウントの Trusted Advisor の チェック 結果を受け取り、チェックの概要と影響を受けるリソースを確認するためのレポートをダウンロードすることができます。組織ビューを有効にしている場合、組織からアカウントを削除すると、Trusted Advisor はそのアカウントのチェックを表示または報告できなくなります。アカウントが移行先組織に参加すると、そのアカウントは有効な Trusted Advisor 組織ビューに含まれます。 AWS Well-Architected Tool:wellarchitected.amazonaws.com AWS Well-Architected Tool の 信頼されたアクセス を有効にすると、AWS Well-Architected Tool リソースを組織の他のメンバーと共有するプロセスを簡単にすることができます。 ワークロード または カスタムレンズ に対して Well-Architected Tool 組織または OU 共有を作成した場合、アカウントが組織を離れると、ワークロードまたはカスタムレンズはそのアカウントとの共有が解除されます。ワークロードまたはカスタムレンズをアカウントと共有し続ける必要がある場合は、対象の AWS アカウント ID またはアカウントの IAM ユーザーを使用して共有を作成できます。ワークロードまたはカスタムレンズを共有しているアカウントが組織を離れると、そのワークロードまたはカスタムレンズは組織または OU との共有が解除されます。組織メンバーアカウントとの共有を継続する必要がある場合は、対象の AWS アカウント ID またはアカウントの IAM ユーザーを使用して共有を作成できます。 個々の AWS アカウントや IAM ユーザーに対して作成されたワークロードまたはカスタムレンズの共有は、共有アカウントが組織を離れても削除されません。 アカウントが移行先組織に参加すると、組織または該当する OU に対して作成された既存のワークロードまたはカスタムレンズ共有に含まれるようになります。 Amazon VPC IP Address Manager(IPAM): ipam.amazonaws.com Amazon VPC IP Address Manager (IPAM) の 信頼されたアクセス を有効にすると、組織全体で IP アドレス使用状況を監視し、メンバーアカウント間で IP アドレスプールを共有することができます。組織メンバーアカウントからのデータレプリケーションを許可するオプションを使用して IPAM を作成した場合、アカウントが組織を離れると、IPAM はそのアカウント内の IP 使用量を監視できなくなります。 アカウントリソースは IPAM スコープに含まれなくなりますが、IPAM プールからの CIDR 割当はアカウントリソースに割り当てられたままであり、IPAM プールによって使用されます。組織からアカウントを削除する前に、必要に応じて、IPAM コンソールまたは AWS CLI release-ipam-pool-allocation コマンドを使用して、IPAM プールから CIDR 割り当てを削除できます。アカウントが組織に属していない場合、プールから CIDR 割り当てを削除することはできません。IPAM プールから CIDR 割り当てを削除しても、アカウントリソースに割り当てられた CIDR は削除されません。組織間の移行中は、 IP 使用状況を継続して監視するためにスタンドアロンアカウントに IPAM を作成 できます。 アカウントが移行先組織に参加すると、組織メンバーアカウントからのデータレプリケーションを許可するために作成された IPAM によって、アカウントは自動的に IP アドレス使用状況の監視対象となります。組織にアカウントを移動する前に、IPAM プールの IPAM CIDR 管理が「自動的に発見されたリソースをインポートする」に設定されていることを確認します。組織に追加するアカウントの発見されたリソースをインポートするために、自動インポートを許可することをお勧めします。リソースに対する重複しない CIDR は IPAM プールから割り当てられますが、アカウント内のリソースの CIDR は変更されません。アカウントリソースの CIDR が IPAM プールからプロビジョニングされていないか割り当てられていない場合、CIDR の IPAM コンプライアンスステータスは管理されていない状態になります。このブログシリーズの第 2 部では、IPAM の委任管理者アカウントと、これがアカウントリソースの IPAM プール割り当て CIDR にどのように影響するか議論します。 結論 本ブログでは、AWS Organizations の信頼されたアクセスをサポートする AWS サービスについて説明しました。1 つ以上の互換性のある AWS サービスが、組織で信頼されたサービスとして構成されているかどうかを識別する方法を学びました。また、組織からアカウントを削除し、別の組織に追加する場合、信頼されたアクセスを有効にした AWS サービスに関して、考慮すべき点とアクションを学びました。 このブログシリーズでは、Organizations のさまざまな機能を順を追って説明し、Organizations を使用して AWS アカウントをある組織から別の組織に移動する場合のガイダンスと考慮事項を提供します。 シリーズの 第 1 部 では、Organizations のさまざまな機能を説明し、Organizations を使用して AWS アカウントを組織から別の組織に移動する場合のガイダンスと考慮事項を提供しました。 シリーズの 第 2 部 では、AWS Organizations の委任管理者を特定し、1 つ以上の互換性のある AWS サービスの委任管理者として登録されているアカウントを移動したい場合の影響とアクションについて説明しました。 ブログ著者について : Karl Schween Karl Schween は、Amazon Web Services のプリンシパル・ソリューション・アーキテクトです。顧客のビジネス課題に対応する、拡張性、柔軟性、耐障害性の高いクラウドアーキテクチャの構築を支援しています。 Deepa Pahuja Deepa Pahujaは、Amazon Web Services のシニアソリューションアーキテクトです。クラウドネイティブサービスを利用してビジネス上の問題を解決するためのアーキテクチャを構築することを楽しんでいます。仕事以外では、Deepa は新しい場所の探索、ハイキング、ダンスを楽しんでいます。 翻訳はプロフェッショナルサービス本部の野田が担当しました。原文は こちら です。
はじめに 本日 (2024 年 2 月 21 日)、 AWS Amplify Hosting のカスタム SSL 証明書の一般提供を発表できることを嬉しく思います。この機能を使うことで AWS Certificate Manager (ACM) から独自の SSL 証明書を Amplify ドメインに設定することができます。 Amplify はお客様に代わって SSL/TLS 証明書を管理し、アプリのユーザー数が 100 人であろうと 10 万人であろうと、HTTPS で お客様のドメインに安全にトラフィックを提供します 。Amplify Hosting が生成した SSL 証明書は、ほとんどのお客様のユースケースに適していますが、一部のお客様からは、独自の証明書をドメインに関連付ける機能を要望されていました。カスタム SSL 証明書機能は、お客様の Amplify ドメインで以下のユースケースを可能にしますが、これに限定されるものではありません。 サードパーティの認証局 (CA) が発行した証明書を使用したい場合 セキュリティ強度を高めるために、証明書の TLS バージョンと公開鍵暗号化アルゴリズムを設定したい場合 www.example.com、www.example.ne など、複数の完全修飾ドメイン名 (FQDN) で証明書を共有したい場合 ウォークスルー 本記事では、IT コンプライアンスのニーズを満たすために、ACM 証明書をリクエストまたはインポートし、Amplify ドメインに関連付ける方法を説明します。 前提条件 このウォークスルーを始める前に、以下のステップを実施しておく必要があります。 Amplify Hosting に Web アプリをデプロイする。Web アプリの構築、デプロイ、ホスティングの詳細については、 AWS Amplify Hosting ユーザーガイド を参照してください。 カスタムドメインを作成する。所有権を確認するプロセスを簡素化するために、Amazon Route 53 で作成したドメインを使用することをお勧めします。 カスタムドメインを Amplify アプリに関連付ける。Amplify Hosting でカスタムドメインを設定する方法は カスタムドメインのセットアップ をご覧ください。 us-east-1 で ACM 証明書をプロビジョニングする Amplify で使用する ACM 証明書をプロビジョニングするには、2 つのオプションがあります。 ACM で新規の証明書をリクエストする サードパーティの認証局から発行された既存の証明書をインポートする 米国東部 (バージニア北部、us-east-1) リージョンで証明書をプロビジョニングする必要があります。詳細は Amazon CloudFront Developer Guide を参照してください。 新規の証明書のリクエスト ACM コンソール (us-east-1) にアクセスし、 Request a certificate を選択します。 Request a public certificate を選択し、 Next を選択します。プライベート証明書は Amplify ドメインではサポートされていません。 Fully qualified domain name の下に、ルートドメイン名 ( example.com など) とワイルドカードサブドメイン名 ( *.example.com など) の両方を入力します。 ワイルドカードサブドメイン名は、Amplifyドメインに設定したサブドメインで証明書を使用するために必要です。 Validation method 、 Key algorithm 、 Tags に必要な設定を入力し、 Request を選択します。 ACM 証明書がプロビジョニングされました。バナーの View certificate を選択すると、ドメインの所有権を確認するための次のステップが表示されます。 カスタムドメインが同じ AWS アカウントの Route 53 で作成されている場合は、 Create records in Route 53 を選択します。 Create records を選択します。これにより、カスタムドメインの Route 53 ホストゾーンに CNAME レコードが作成され、ACM はあなたがドメインを所有していることを確認することができます。 ドメインが Route 53 ではなくサードパーティのドメインレジストラで作成された場合、これらの CNAME レコードを手動で追加する必要があります。詳細については、登録しているドメインレジストラのドキュメントを参照してください。 しばらくすると、証明書が発行され、ドメインの検証に成功したことが表示されます。 既存の証明書のインポート サードパーティ CA が発行した証明書をすでにお持ちの場合は、 Import a certificate を選択します。 サードパーティ証明書には、ルートドメイン名 ( example.com など) とワイルドカードサブドメイン名 ( *.example.com  など) の両方を指定する必要があります。ワイルドカードサブドメイン名は、Amplify ドメインに設定したサブドメインで証明書が動作するために必要です。 Certificate body 、 Certificate private key 、 Certificate chain (オプション) を入力し、 Next を選択します。このステップでタグを追加することもできます。 Import を選択します。 インポートされた証明書が ACM でプロビジョニングされます。 Amplify ドメインで ACM 証明書を使用する Amplify ドメインの管理ページで、カスタムドメインを見つけ、 Manage domain を選択します。 Choose your certificate で Custom SSL certificate を選択し、ドロップダウンメニューから証明書を選択し、 Update を選択します。証明書 ID が、このウォークスルー用に ACM でプロビジョニングした証明書に対応していることを確認します。 Amplify は、ACM 証明書をドメインに関連付けるプロセスを開始し、関連付けのステータスを表示します。 クリーンアップ Amplify ドメインで Amplify が管理する証明書を使用 カスタム SSL 証明書の代わりに、Amplify が管理する証明書を使用するように切り替えることができます。Amplify ドメイン管理ページで、カスタムドメインを見つけ、ドメインの管理を選択します。 AWS Amplify Hosting のドメイン管理ページでカスタムドメイン ( olileung.people.aws.dev ) ボックスの右上に Manage domain ボタンがあります。 Choose your certificate で Amplify managed certificate を選択し、 Update を選択します。 Amplify は、ドメイン上で ACM 証明書を Amplify が管理する証明書に置き換えるプロセスを開始し、更新のステータスを表示します。 ACM 証明書の削除 ACM 証明書を削除することもできます。証明書の ACM ページで、証明書が使用されていないことを確認し、 Delete を選択します。 ポップアップで「delete」と入力し、 Delete を選択します。これで証明書は ACM から削除されます。 まとめ 本記事では、ACM 証明書をリクエストまたはインポートし、Amplify ドメインに関連付ける方法を紹介しました。これにより、ドメインと IT コンプライアンスのニーズをより詳細に管理できるようになります。 サードパーティの証明書プロバイダから証明書をインポートした場合は、有効期限が切れる前に証明書を再インポートする必要があります。詳細については、証明書の再インポートに関する ACM ユーザーガイド を参照してください。 Amplify ドメインに関連付けられた証明書は、そのサブドメインを保護します。詳細については、 サブドメインの管理に関する Amplify Hosting ユーザーガイド を参照してください。 最後に、Next.js, Nuxt, React, Angular, Vue、またはその他のフロントエンドアプリを Amplify Hosting にデプロイして、コミュニティの Discord に参加して感想を聞かせてください! 本記事は 「 Bring your own SSL certificate to AWS Amplify Hosting 」 を翻訳したものです。 著者について Oliver Leung, Software Development Engineer, Amplify Hosting Oliver Leung は AWS Amplify Hosting の Software Development Engineer (SDE) です。Oliver は、AWS の信頼性と利便性に裏打ちされたフロントエンドの Web アプリケーションを、顧客がより簡単にホストできるようにする機能を構築しています。余暇には Amazon Jazz Band でアルトサックスを演奏したり、和太鼓を演奏しています。 Matt Auerbach, Senior Product Manager, Amplify Hosting Matt Auerbach はニューヨークを拠点とする AWS Amplify チームのプロダクトマネージャーです。彼は、プロダクトとオファリングに関して開発者を教育し、支援とフィードバックのための主要な窓口として活動しています。Matt は温厚なプログラマーで、テクノロジーを使って問題を解決し、人々の生活を便利にすることを楽しんでいます。しかし、夜は…ほとんど同じことをしています。Matt の X アカウントは @mauerbac です。以前は Twitch, Optimizely, Twilio でデベロッパーリレーションを担当していました。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。
ビデオゲームの制作は、プロジェクトのさまざまな側面にわたって多様なチームが協力することを必要とする複雑なプロセスです。近年発生した世界的な出来事により、開発環境はますますハイブリッド化しています。チームメンバーは現在、仮想ワークステーションを採用するだけでなく、自宅とオフィスの両方の場所から業務を行っています。大規模で没入感のあるゲームの開発において、効率的なアセット取得とパフォーマンス最適化を確実にするために、キャッシングは不可欠です。例えば、Unreal Engine はこの目的のために派生データキャッシュ (Derived Data Cache (DDC)) と呼ばれるメカニズムを使用します。クラウドで共有 DDC を構成すると、仮想ワークステーションをより高速な応答時間とより効率的な開発プロセスで補完します。 Unreal Engine の DDC は、生成に計算コストがかかるデータのストレージメカニズムとして機能します。このデータは保持され、変更が発生しない限りは再生成の必要はありません。 DDC には、エンジンがロード時に迅速にアクセスできるテクスチャ圧縮、シェーダコンパイル、ジオメトリ変換など、処理済みの派生アセットデータを格納します。これは特に大規模なチームとプロジェクトにとって重要であり、頻繁なアセットの再コンパイルの必要性を減らし、時間と計算リソースを節約します。 DDC は単一のユーザーのローカルに置くことも、開発パイプラインの効率を向上させるためネットワーク経由でチーム全体で共有することもできます。クラウドベースの共有 DDC を設定すると、Unreal Engine プロジェクトのスケーラビリティが向上します。 AWS ストレージサービスを活用することで、どこからでもキャッシュされたデータを簡単に共有およびアクセスできます。この記事では Amazon FSx for OpenZFS での共有 DDC に焦点を当てます。 Amazon FSx for OpenZFS は、人気の高い OpenZFS ファイルシステム上に構築されたフルマネージドな共有ストレージです。これは AWS 上でトップクラスの価格 / パフォーマンスを提供する、シンプルで強力な共有 NFS ファイルストレージです。 それぞれの Amazon FSx for OpenZFS には、高速なインメモリキャッシュを備えたファイルサーバーがあります。 インメモリキャッシュに加え、Single-AZ 2 ファイルシステムは、大きな DDC を格納してより高速な応答時間を実現するために使用できる、追加の NVMe キャッシュを提供します。Amazon FSx for OpenZFS は OpenZFS ファイルシステムの ARC と L2ARC を活用して、インメモリと NVMe キャッシュからのデータアクセスを強化し、より高速なデータアクセスとパフォーマンスの向上を実現します。 Amazon FSx for OpenZFS はマルチ AZ への展開が可能ですが、代わりに Single-AZ 2 を使用して Unreal Engine の DDC のコストを最適化できます。DDC は重要ではなく簡単に再生成できるため、Single-AZ が適しています。 DDC の取得には、高いリクエストレートの時間帯とアイドル時間が長い時間帯があります。 Amazon FSx for OpenZFS にはベースライン速度を超えてバーストする機能があります。 これはネットワーク I/O およびディスク I/O 操作の両方を、 I/O クレジットのメカニズムの助けを借りて処理します。 Amazon FSx for OpenZFS のパフォーマンスの詳細は、 ユーザードキュメント で確認できます。 Amazon FSx for OpenZFS を Unreal Engine の DDC として設定する このブログでは、クライアントとして Windows Server 2019 を実行する Amazon WorkSpaces を使用し、DDC を作るのに Lyra を使用します ( Lyra は Epic Games の作ったモジュラー式のサンプルゲームプロジェクトです ) 。 ステップ 1: Amazon FSx for OpenZFS ファイルシステムの作成と構成 AWS マネジメントコンソールで Amazon FSx に移動し、「ファイルシステムを作成」をクリックします。「ファイルシステムタイプを選択」で「 Amazon FSx for OpenZFS 」を選択します。次に「スタンダード作成」を選びます。 Amazon VPC とサブネットを選択し、デプロイタイプ「 Single-AZ 2 」でファイルシステムを作成します。このタイプは NVMe をサポートしています。 Amazon FSx for OpenZFS ファイルシステムを作成するための構成は次のとおりです。 ステップ 2: ネットワークアクセスの構成 Amazon FSx for OpenZFS ファイルシステムとワークステーション間の通信を許可するには、適切なネットワーク構成が不可欠です。 AWS コンソールの「ネットワークとセキュリティ」タブで、Amazon FSx for OpenZFS ファイルシステムに関連付けられた Elastic Network Interface (ENI) を見つけます。 これは、ファイルシステムのトラフィックを処理するネットワークインターフェースです。 NFS プロトコルを介した適切な通信のため、Amazon FSx for OpenZFS で必要なポートを設定する必要があります。 ファイルシステムのアクセス制御に関する詳細は こちら をご参照ください。 WorkSpaces のセキュリティグループからのアクセスを許可するため、Amazon FSx for OpenZFS の ENI のセキュリティグループにインバウンドルールを追加します。 ステップ 3: ワークステーションへの Amazon FSx for OpenZFS のマウント Amazon FSx for OpenZFS ファイルシステムとワークスペース間の通信を容易にする為、設定した Amazon FSx for OpenZFS ファイルシステムをワークスペースにマウントします。 Amazon FSx for OpenZFS ファイルシステムをクリックし、「 アタッチ 」をクリックすると、ファイルシステムをワークステーションにマウントするための手順が表示されます。 この記事では Windows ベースの WorkSpaces を使用し、ファイルシステムを Z ドライブとしてマウントしています。 Windows クライアントへの OpenZFS ボリュームのマウントには NFS v3 プロトコルを利用します。 そのためにまず  NFS クライアントをインストール する必要があります。 ワークステーションで PowerShell を管理者として開き、NFS クライアントをインストールします。 Install-WindowsFeature -Name NFS-Client コマンドプロンプトを開き次のコマンドを実行します。ファイルシステム ID を実際のものに置き換えてください (「 Z: 」を別の使用可能なドライブレターに置き換えることもできます )。 mount \\<filesystemID>.fsx.<region>.amazonaws.com\fsx\ Z : ステップ 4: Unreal Engine エディタの DDC に Amazon FSx for OpenZFS を設定する ファイルシステムが準備できてワークステーションにマウントされたので、Unreal Engine エディタで Amazon FSx for OpenZFS を DDC として認識するように設定できます。 Unreal Engine エディタで 編集 、 エディタの環境設定 の順に移動します。 Unreal Engine エディタの設定で、「 Global Shared DDC Path 」を探します。 ここに、設定した Amazon FSx for OpenZFS のマウントパスを入力します。 ステップ 5: 構成の検証 すべてが正しく設定されていることを確認するには、DDC を再計算されたゲームデータで満たす必要があります。 ビルドのクックを開始すると、マウントされた Amazon FSx for OpenZFS のパスに DDC が入るのがわかります。 実行する必要のあるコマンドは次のとおりです。プレースホルダーをエディタとプロジェクトへの実際のパスに置き換えてください。 "<path to Editor>\UnrealEditor.exe" "<Path to project>\LyraStarterGame" -run=DerivedDataCache -fill 共有キャッシュとしてマウントされた Amazon FSx for OpenZFS に、派生データが入力されているのがわかります。 クリーンアップ プロジェクト完了後の追加コストを避けるために、クリーンアッププロセスに取り組むことが重要です。 まず、エンジンが DDC にアクセスしないように、Unreal Engine エディタの設定から Amazon FSx for OpenZFS のパスを削除してください。 次に「 net use Z: /delete 」コマンドを実行して、Amazon FSx for OpenZFS ファイルシステムのマウントを解除します (「 Z: 」を実際に使用したドライブレターに置き換えてください)。 マウントを解除したら、AWS マネジメントコンソールからファイルシステムを削除します。AWS マネジメントコンソールで FSx に移動し、Amazon FSx for OpenZFS ファイルシステムを選択します。 「ファイルシステムの削除」を選択し、すべてのデータが削除されるようにプロンプトに従ってください。 クリーンアップする際に、ネットワーク構成に加えた変更も元に戻すことが重要です。Amazon FSx for OpenZFS の ENI のセキュリティグループからインバウンドルールを削除して、ネットワーク構成を再度保護してください。 Terraform テンプレートを使用して DDC を設定したユーザーの場合は、関連インフラをデプロビジョンするために「 terraform destroy 」コマンドを実行してください。 まとめ 私たちは Unreal Engine 用の派生データキャッシュ (DDC) として、Amazon FSx for OpenZFS を設定するためのステップバイステップのガイドを提供しました。 Amazon FSx for OpenZFS は、フルマネージドでセキュアかつスケーラブルなファイルストレージを提供するため、特に共有開発環境で Unreal Engine の DDC として構成するのに最適です。 Infrastructure as Code (IaC) のアプローチを好む人の為に、セットアッププロセスを簡素化する Terraform のテンプレートを公開しています。 Terraform のテンプレートは AWS GitHub リポジトリの aws-samples/unreal-engine-ddc にあります。 このリポジトリには Amazon FSx for OpenZFS を使用した Unreal Engine の派生データキャッシュ (DDC) を設定するために必要なすべてのコードと手順が含まれています。 翻訳はソリューションアーキテクトの長田が担当しました。原文は こちら です。
チップ形状の微細化が進むにつれ、先端ノード技術を使用してチップ製造を成功させることは難しくなっています。電子設計自動化 (EDA) は、より多くのコンピュート、ストレージ、時間を消費します。設計と検証の段階で、エンジニアが反復してバグを発見する時間を増やすことは、何百万もの不具合による再設計や収益の損失を防ぐことにつながります。チップ設計プロセスをさらに複雑にしているのは、半導体市場が人材不足に陥っていることです。既存エンジニアの生産性を向上させることで、この人材不足を解消し、市場投入までの時間を改善することができます。このブログでは、柔軟なコンピュートオプションを使用して最大 40% のパフォーマンス向上を示す 2 つの環境について説明します。これらの環境は、Cadence 社と Synopsys 社のバッチツールとインタラクティブツールにまたがり、結果が出るまでの時間とジョブコストを比較しています。 選択肢が重要な理由 それぞれの EDA ツールの性能は、様々な要因の影響を受けます。CPU のクロック速度が速いものや、特定の CPU 命令セットを使っているものは、その恩恵を受けます。他のツールは、より大きな L3 キャッシュ、メモリ帯域幅、またはネットワークスループットの恩恵を受けます。AWS 上で実行することで、顧客は最適化しようとしている特定の CAD (Computer Aided Design) フローに合わせて、コンピュートインスタンスを適切なサイズに設定することができます。CAD フロー全体において、結果までの時間が 10 ~ 40% 短縮され、全プロセスが 1 時間で完了しました。これは、CAD フローを変更する労力を掛けることなく、このようなパフォーマンスの改善を得るための方法です。 影響の定量化 この最適化の影響を定量化するために、2 つの単純化したシナリオ (最適化/非最適化) を比較してみます。 ジョブは 2 つのライセンスタイプで半々に分けられます ライセンス A は CPU プロバイダー A で 15% 遅く動作します ライセンス B は CPU プロバイダー B で 15% 遅く動作します 月間 1,000,000 ジョブ、2 つのオプションのうち最速で実行した場合の平均ジョブ時間は 1 分です どちらのコンピュートタイプも 1 時間あたり 0.1 ドルです (シンプルにするため) ライセンスコストはコンピュートコストの 3 倍です (0.3ドル) 顧客がクラスタ用に 1 つの CPU プロバイダだけを選択した場合、500,000 分 * 100% * $(0.1+0.3) / 60 + 500,000 分 * 115% * $(0.1+0.3) / 60 = $7,166 を支払うことになります。 一方、同じ顧客が各ジョブを最適な CPU で実行することを選択した場合、500,000 分 * 100% * $(0.1+0.3) / 60 + 500,000 分 * 100% * $(0.1+0.3) / 60 = $6,666 を支払うことになります。 この計算では、結果を 15% 早く得ることによるビジネス上のメリット (エンジニアリングの生産性、市場投入までの時間) を無視し、直接的な節約だけが強調されています。また、よりコストの低いインスタンスもあり、それらを選択することでさらなる節約を達成できるという事実も無視されています。結果を共有する前に、どのようにベンチマークを実行したかを説明します。 方法論 AWS オレゴンリージョンの AWS インフラを使用して、このベンチマークを実行しました。各ベンチマークには以下の要素が含まれます。 Intel、AMD、ARM ベースの AWS Graviton プロセッサ の 3 つのサーバ・アーキテクチャ テスト時の 2 世代のコンピュート (現行世代と旧世代) 合計 13種類 のインスタンスタイプ (Intel 5種類、AMD 4種類、Graviton 4種類) 各インスタンスのコア数は同じで、より多くのメモリを提供するインスタンスもありました。これにより、それぞれの EDA ツールについて、各 CPU タイプのコスト/パフォーマンスを評価することができました。また、CPU の世代を比較することで、経年変化を確認することもできました。各ツールには、同じ EDA ベンダー (Cadence / Synopsys) の IP ブロックを使用しました。複数のツールで同じユースケースを実行したわけではありません。Cadence と Synopsys を比較したのではなく、ツールごとに異なるコンピュートタイプを比較したのです。同様のアプローチは Siemens 社も取っており、同社の クラウド・フライトプラン の発表で述べられているように、AWS 上でより高速に実行するための最もよく知られた方法を取り入れています。注:結果はしばしば設計に依存します。Intel が Tool X で高速だったとしても、あなたの設計では必ずしもそうではないでしょう。あなたの設計でこのテストを繰り返す必要があります。例えば、あるツールが L3 キャッシュのサイズに敏感であるにもかかわらず、テストケースが小さすぎて L3 キャッシュにストレスを与えられなかったような場合です。あなたの設計は、その違いを体験するのに十分な大きさかもしれません。言い換えれば、あなたの燃費は異なるので、自身でテストしてください。コスト分析にあたっては、3 つの仮定を置きました。 各ライセンスのコストは 2,500 ドルと仮定しました。すべてのライセンスに単一のコストがあるわけではありませんが、ランタイムが全体のコストに与える影響を示すための「プラグナンバー」が必要でした。EDA ライセンスは通常、実行に使用するコンピュートよりも数倍高いです ( Intel の場合 は 4 倍)。私たちは、コンピュートだけのコストではなく、全体的なコストを最適化しています。 私たちは生産性を示しているわけではありません。私たち自身のシリコン開発では、エンジニアのコストは新製品の開発コストの 50% にも上ります。次のコストシミュレーションには、そのようなコストは含まれていません。もしそれを含めれば、長時間ジョブの影響は 2 倍以上になるでしょう。 各ジョブには、オレゴンリージョンの Amazon Elastic Compute Cloud (Amazon EC2) の オンデマンド 価格を使用しました。オンデマンドホストは、 リザーブドインスタンス 、 Savings plans による割引を享受できません。これは「最悪のシナリオ」の計算です。 シミュレーションを使用した AWS 上の電子設計自動化のコスト予測 をお読みいただき、コスト削減を実施するための当社の支援方法をご確認ください。 このブログは 2023 年夏に実施されたテストのデータに基づいています。それ以来、Intel ベースの r7iz や Graviton 4 インスタンスなど、新しいインスタンスが発表されています。しかし、このブログでは時間の経過に伴うパフォーマンスの最適化について見ています。新しいインスタンスタイプでの再テストは、AWS 上で EDA パフォーマンスを繰り返し継続的に向上する方法の完璧な例です。 結果 : Cadence グラフ 1 は、Cadence Spectre の結果を示しています。グラフ上の各ドットは、特定のコンピュートインスタンスタイプを表しています。 X 軸はランタイム (秒) を示します Y 軸は 1 つのジョブの総コスト (実行された時間のコンピュート + EDA ライセンス) を示します 理想的なサーバーは、より低く (費用対効果が高く)、より左にあります (結果が出るまでの時間が早い) グラフ 1 – Spectre のコスト/パフォーマンス分析 (ジョブあたり)。Graviton インスタンスは x86 インスタンスより 40% 以上高速で、コストは 40% 以上低い。 グラフ 1 では、ジョブの実行時間が長いほど、ジョブ全体のコストが高くなることがわかります。データポイントが斜めに広がっているのはこのためです。 c7g / m7g (第 3 世代 Graviton プロセッサ) は、現世代の Intel インスタンス ( c6i / m6i ) や AMD ( c6a / m6a ) と比べて 40% 以上高速であることがわかります。Spectre は浮動小数点演算に依存しており、第 3 世代 Graviton プロセッサは x86 よりも高速に実行します。Graviton はクロック速度が低いにもかかわらず、浮動小数点演算ではより高速です。これは些細なことではないので、インスタンスのスペックに頼らずテストすることをお勧めします。次のツールに移る前に、これらのインスタンスファミリーを世代間で比較し、Time-to-Results が時間とともにどのように変化するかを見ることができます。 グラフ 2 – コンピュート世代間の Spectre パフォーマンス。Graviton と AMD (M-family) はどちらも以前は Intel より遅かったが、現在の世代では速くなりました。 グラフ 2 は、新しい世代におけるすべてのコンピュートファミリーのランタイムの向上を示しています。前の世代では AMD が最速でしたが、現在の世代では ARM が最速です。これは、新しい世代が出るたびに、コンピュートの選択を再評価する必要性を示しています。先に説明したように、このテストには 1 時間かかりました。このラボでは、すべてのコンピュートノードで設計を並列実行し、性能を評価しました。ライセンスの縛りがある場合は、 これらのテストを連続的に実行するか 今日は、とある 1種類の CPU タイプで、明日は別の CPU タイプでリグレッションテストを実行します 同じデータを Xcelium で比較してみます。 グラフ 3 – Xcelium のコスト/パフォーマンス分析。AMD は Intel より 11%、ARM ベースのインスタンスより 14% 高速でした。 グラフ 3 は、AMD ベースのインスタンスが同スペックの Intel よりも 11% 高速に動作し、Graviton ベースのインスタンスよりも 14% 高速に動作していることを示しています。Spectre と比較した結果の変化は、結果までの時間を短縮するためには、多様なコンピュートタイプが必要であることを浮き彫りにしています。コンピュート世代を比較すると (グラフ 4)、AMD は Intel よりも遅かったが、より速くなりました。AWS の顧客は各コンピュート世代で各フローに最適なものを柔軟にテストできます。そして、インスタンスタイプを組み合わせて使うことができます。 グラフ 4 – コンピュート世代間の Xcelium パフォーマンス。AMD (M-family) は以前は Intel より遅かったが、現在の世代では速くなりました。 結果 : Synopsys Synopsys VCS のテストでも同様のアプローチを取りましたが、今回は同じツールを 2 種類のクイックスタートキット (XBUS と Bitcoin) でテストしました。これにより、特定の設計が CPU の選択に与える影響が浮き彫りになりました。Synopsys の XBUS クイックスタートキットを使用した場合、Intel は AMD より 10%、Graviton より ~ 14% 高速でした (グラフ 5)。 グラフ 5 – VCS (XBUS) のコスト/パフォーマンス分析。Intel は AMD より 11%、Arm ベースのインスタンスより 14% 高速でした。 コンピュート世代を比較すると (グラフ 6)、現在の世代では Intel が最速であることがわかります。しかし、前の世代を比較すると、これらがどのように変化するかに注目してください。 グラフ 6 – コンピュート世代間の VCS (XBUS) 性能、Intel が両世代で最速。 Synopsys の Bitcoin クイックスタートキットを使って同じテストを繰り返すと (グラフ 7)、結果が変化するのがわかります。AMD は Intel より 25% 速く、Graviton より 20% 速いです。これは、結果がいかに設計に依存するか、そしてなぜ自分でテストする必要があるかを示しています。 グラフ 7 – VCS (Bitcoin) のコスト/パフォーマンス分析。AMD は Intel より 30% 速く、Graviton より 25% 速い。 コンピュート世代を比較すると (グラフ 8)、AMD がこの特定の設計で最も遅いものから最も速いものへと変化しており、時間の経過とともに状況が変化していることがわかります。 グラフ 8 – コンピュート世代間の VCS (Bitcoin) のパフォーマンス。 まとめ 新しい世代が出るたびに、CPU プロバイダは、EDA のコスト/パフォーマンスにおいて、互いにしのぎを削るようになるかもしれません。これにより、新たな改善の機会が生まれます。AWS の顧客は、より高速な結果を得るために、特定の EDA フロー用にコンピュートインスタンスをカスタマイズすることができます。これは、たまたま利用可能なノードでジョブが実行されるオンプレミスとは対照的です。これにより、既存のエンジニアリングチームの生産性が向上し、カバレッジが拡大し、市場投入までの時間が短縮されます。しかも、既存のフローを変更する必要がありません。このパフォーマンス最適化プロセスで EDA フローを実行してみませんか?AWS アカウントチームまたは AWS 担当者 にご連絡いただき、半導体のスペシャリストにご相談ください。お客様のテストを喜んでサポートいたします。 さらに読む EDA ライセンス時間を最大 20% 削減する方法の詳細については、 EDA on AWS ライセンスコスト最適化の経済学 をお読みください。 NXP Semiconductors のビデオでは、EDA フローを加速するためのベンチマークを紹介しています。 翻訳はソリューションアーキテクトの 吉廣 理 が担当しました。原文は こちら です。 Eran Brown Eran Brown は、シニア半導体スペシャリスト・ソリューション・アーキテクトです。半導体企業で 7 年間、HPC ストレージインフラの設計に携わり、1 平方インチのシリコンで何ができるかに驚きを隠せません。
この 1 週間も、AWS のサービスチームは引き続きお客様に代わってイノベーションを進めており、 Amazon Web Services (AWS) の世界でも、皆さんにお話ししたいたくさんのことがありました。世界各地で開催されている、あらゆる AWS コミュニティ イベントやイニシアティブについてもお伝えしたいと思います。 では、早速見ていきましょう! 2月12日週のリリース 2月12日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 AWS Control Tower が組織単位を登録するための API を導入 – これらの新しい API では、API を使用してガバナンスを組織単位 (OU) に拡張し、OU プロビジョニングワークフローを自動化することができます。API は、既に AWS Control Tower ガバナンスの対象となっている OU を、ランディングゾーンの更新後に再登録するためにも使用できます。これらの API には AWS CloudFormation サポートが含まれているため、お客様は Infrastructure as Code (IaC) を使用して OU を管理することができます。 API Gateway が TLS 1.3 のサポートを開始 – TLS 1.3 を実装した API Gateway を一元化されたコントロールポイントとして使用することにより、開発者はクライアントとゲートウェイ間のコミュニケーションをセキュア化し、API トラフィックの機密性、整合性、信頼性を維持して、TLS を使用して SSL 証明書を一元的にデプロイするための AWS Certificate Manager (ACM) との API Gateway の統合からメリットを得ることができます。 Amazon OpenSearch Service でブルー/グリーンなしでのクラスターボリュームの更新が可能に – ブルー/グリーンデプロイは、デプロイがドメインで追加のリソースを使用することによるクラスターの中断を避けるためのものですが、ブルー/グリーンはトラフィックが少ない期間に実行することが推奨されます。これからは、ブルー/グリーンデプロイを必要とすることなくボリューム関連のクラスター設定を更新できるようになるため、オンライントラフィックへのパフォーマンス影響を最小限に抑えるとともに、クラスター動作が中断される可能性も回避できます。 Amazon GuardDuty Runtime Monitoring が共有 VPC で実行されるクラスターを保護 – このリリースに伴い、GuardDuty で既に自動エージェント管理にオプトインしているお客様は、GuardDuty Runtime Monitoring の新たな 30 日トライアルを活用することができるようになります。このトライアルでは、共有 VPC セットアップにデプロイされているリソース (クラスター) の監視が自動的に開始されます。お客様には、エージェントを手動で管理して、共有 VPC 環境に仮想プライベートクラウド (VPC) エンドポイントをプロビジョニングするオプションもあります。 AWS Marketplace が OU の Private Marketplace カタログ管理のサポートを開始 – この機能は、ビジネスユニットまたは開発環境ごとに個別の製品カタログをサポートするため、組織は特定のニーズに合わせてソフトウェア調達を調整することができます。さらに、お客様は Private Marketplace 管理の委任管理者として信頼できるメンバーアカウントを指定することもできるので、マネジメントアカウント管理者の業務上の負担が軽減されます。このサポートの開始により、組織は、異なるビジネスニーズやユーザーニーズの全体に調達ガバナンスをスケールするために必要となる俊敏なコントロールを管理者に提供することによって、調達を迅速化することが可能になります。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS ニュース AWS Cloud Clubs Captains に参加しましょう – AWS Cloud Club Captains の C3 コホートへの参加申し込み受付は、2024 年 2 月 5 日から 23 日の午後 5 時 (米国東部標準時) までとなっています。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週執筆しています。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 Building with Generative AI on AWS using PartyRock, Amazon Bedrock and Amazon Q – プロンプトエンジニアリングと Amazon Bedrock API の使用におけるスキルを習得します。ナレッジベース、RAG (Retrieval Augmented Generation)、埋め込み、エージェントを通じて「ドキュメントとチャット」する方法も検証していきます。また、コーディングとデバッグを支援するために、次世代の開発者ツールである Amazon Q と Amazon CodeWhisperer も使用します。 会場 : AWS Skills Center, 1550-G Crystal Drive, Arlington, VA (米国) AI/ML security – 人工知能と機械学習 (AI/ML)、そして特に生成 AI は、多くの組織の最優先事項になってはいるものの、この新しい変革的なテクノロジーで前進したいと考えている企業でさえも、ためらいを感じています。こういった企業は、構築するものがセキュアであることを確実にする方法を必ずしも理解しているわけではありません。このウェビナーでは、その実現方法を説明します。 AWS Jam Session – Canada Edition – AWS JAM は、遊び、学んで、AWS スキルを検証するための、ゲーム化された学習プラットフォームです。午前は、セキュリティ、サーバーレス、AI/ML、分析など、さまざまな技術分野にまたがる課題を織り交ぜたものになっています。午後は、毎月異なる専門分野に焦点を当てます。課題を解決するために、最大 4 名のチームを結成できます。上位 3 チームには賞品が贈られます。 お住まいの地域が南北アメリカ、アジア太平洋、日本、または EMEA 地域であるかにかかわらず、 皆さんのタイムゾーンにぴったりな AWS Innovate Online イベント が予定されています。Innovate Online イベントは無料のオンラインイベントで、AWS に関するインスピレーションを得て、知識を深めてもらうことを目的としています。 AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。これらのイベントは、AWS の製品とサービスについて学び、インフラストラクチャとアプリケーションを構築、デプロイ、および運用するために必要なスキルを身に付けることができるように設計されています。 お近くの AWS Summit を検索 して登録するか、関心のある AWS Summit の登録受付開始時に通知を受ける設定を行ってください。 AWS コミュニティ re:Invent re:Cap  – 世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベントに参加して、AWS re:Invent からの最新の発表について学びましょう。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます 。 2月19日週のニュースは以上です。2月26日週の Weekly Roundup もお楽しみに! – Irshad この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。
AWS Cloud Development Kit (CDK) を使って既存のリレーショナルデータベース上にスケーラブルでセキュアな GraphQL インタフェースを簡単に構築できる機能を発表しました。AWS Systems Manager Parameter Store に SecureString として安全に保存されたデータベースの認証情報と共に AWS Amplify GraphQL API CDK コンストラクトを提供し、SQL ステートメントを実行する GraphQL API の構築を開始します。この新機能は、 Amazon Relational Database Service (Amazon RDS) 上の MySQL および PostgreSQL データベース、または外部でホストされている MySQL および PostgreSQL データベースで動作します。 2023 年 10 月に、DynamoDB データベースの作成と接続をサポートする Amplify GraphQL API の新しい L3 CDKコンストラクトを発表しました 。L3 CDK コンストラクトにより、お客様は AWS Lambda 関数を作成し、追加のデータソースに接続することができます。お客様は AWS Lambda を使用する柔軟性を楽しんでいるが、データベース接続、SQL 文の実行、ネットワーク設定を管理するためのカスタムコードを手作業で構築するための価値を生みづらい重労働を取り除くために、MySQL と PostgreSQL データベースに対するよりファーストクラスのサポートを求めていました。 既存の MySQL および PostgreSQL データベース用の新しい GraphQL API を 5 つのステップで作成してみましょう。 前提条件 始めるには以下が必要です。 npm 経由の CDK CLI がインストールされていること このガイドでは、Amazon RDS で デプロイされた MySQL と PostgreSQL データベースがあることを前提に説明しますが、この機能は一般にアクセス可能などのデータベースでも動作します。 Step1 – データベースの認証情報を Systems Manager に保存 データベース接続情報 (ホスト名、ユーザ名、パスワード、ポート、データベース名) を、Systems Manager に SecureString として格納します。 Systems Manager コンソールに移動し、 Parameter Store に移動して、 Create Parameter をクリックします。データベースサーバのホスト名、接続するユーザ名とパスワード、データベースポート、およびデータベース名にそれぞれ 1 つずつ、合計 5 つの異なる SecureString を作成します。 Systems Manager 構成は以下のようになります。 Step 2 – 新しい AWS CDK プロジェクトをセットアップし、Amplify GraphQL コンストラクトをインストール 新しい AWS CDK アプリケーションを作成し、ターミナルで以下の AWS CDK CLI コマンドを実行して、AWS Amplify GraphQL コンストラクトの依存関係をインストールします。 mkdir sql-api cd sql-api cdk init app --language=typescript 次にプロジェクトを開き、 npm install @aws-amplify/graphql-api-construct を実行して、GraphQL API コンストラクトを依存関係に追加します。 Step 3 – GraphQL スキーマで Query と Mutation を定義 AWS CDK アプリの lib/ フォルダ内に、公開したい API を含む新しい schema.graphql ファイルを作成します。公開したい API に合わせて、GraphQL オブジェクト型、Query、Mutation を定義します。例えば、データベーステーブルのオブジェクト型、それらのテーブルからデータを取得する Query、それらのテーブルを変更する Mutation を定義します。 type Meal { id: Int! name: String! } type Query { listMeals(contains: String!): [Meal] @sql(statement: "SELECT * FROM Meals WHERE name LIKE CONCAT('%', :contains, '%');") @auth(rules: [{ allow: public }]) } Queryリクエストから引数を参照するには、 :notation を使用できます。Amplify の GraphQL API は、デフォルトで拒否ベースで動作します。 { allow: public } ルールでは、API キーを使用している人であれば誰でもこの Queryを呼び出せるように指定しています。API キー、Amazon Cognito User Pool、OpenID Connect、AWS Identity and Access Management (IAM)、またはカスタム Lambda 関数に基づいて、これらの Query や Mutation へのアクセスを制限するために Authorization ルール を確認してください。 Step 4 – GraphQL API コンストラクトと、VPC 設定を構成 データベース内の SSM パスを参照する、AWS CDK スタック内の GraphQL API CDK コンストラクトの新しいインスタンスを作成します。このコンストラクトを sql-api-stack.ts ファイルにインポートします。 import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; AWS CDK スタックコードで、 GraphqlApi のインスタンスを作成します。データベースの認証情報への SSM パラメータパスを props として渡します。また、 .graphql スキーマファイルを指すように schema プロパティを設定します。 export class RdsStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { databaseNameSsmPath: '/rds-test/database', hostnameSsmPath: '/rds-test/host', passwordSsmPath: '/rds-test/password', portSsmPath: '/rds-test/port', usernameSsmPath: '/rds-test/username', }, }, ), authorizationModes: { // We recommend to only use API key authorization for development purposes. defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 今回は、MySQL データベースは Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon RDS 上にデプロイされているため、データベースの VPC 情報も GraphQL API に提供する必要があります。 GraphqlApi コンストラクトで、Amazon VPC、アベイラビリティゾーン、セキュリティグループ ID を指すように vpcConfiguration プロパティを構成します。 const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { ... }, // Place all VPC Configuration in here. If your database is // publicly reachable over the Internet, you can skip this config. vpcConfiguration: { // (1) Set the security group ID securityGroupIds: ['sg-08XXXXXXX'], // (2) Set the VPC ID vpcId: 'vpc-c3XXXXXX', // (3) Set the available subnet + availability zone config subnetAvailabilityZoneConfig: [{ availabilityZone: 'us-east-1b', subnetId: 'subnet-5bXXXXXXX' }] }, }), authorizationModes: { ... } }) Step 5 – GraphQL API のデプロイ 次に AWS CDK アプリをデプロイします。 cdk deploy を実行して、スキーマから接続されたデータベースで GraphQL API スタックを起動します。これで、AWS AppSync コンソールに移動し、GraphQL Query と Mutation の実行を開始できます。 ボーナス:インライン SQL ステートメントをファイル参照にリファクタリング SQL ステートメントを GraphQL API と一緒にインラインで記述することは、特に API が大きくなるにつれて管理が難しくなる可能性があります。これらの Query や Mutation を管理しやすくするには、SQL ステートメントを別の .sql ファイルで作成し、GraphQL スキーマに参照として追加します。まず、新しい lib/sql-statements フォルダーを作成し、SQL ステートメントを含む listMeals.sql ファイルを追加してみましょう。 lib/sql-statments/listMeals.sql ファイルは以下のようになります。 SELECT * FROM Meals; lib/sql-api-stack.ts ファイルで、 sql-statements/ フォルダーから読み取り、カスタム SQL ステートメントとして Amplify GraphQL API に追加します。 // ...Other imports import * as fs from 'fs'; import * as path from 'path'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition, SQLLambdaModelDataSourceStrategyFactory } from '@aws-amplify/graphql-api-construct'; export class RdsStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // Define custom SQL statements folder path const sqlStatementsPath = path.join(__dirname, 'sql-statements') // Use the Factory to define the SQL data source strategy const sqlStrategy = SQLLambdaModelDataSourceStrategyFactory.fromCustomSqlFiles( // File paths to all SQL statements fs.readdirSync(sqlStatementsPath).map(file => path.join(sqlStatementsPath, file)), // Move your connection information and VPC config into here { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { ... }, vpcConfiguration: { ... }, } ) const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), sqlStrategy ), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 次に、カスタム SQL ステートメントを参照するように GraphQL スキーマを更新します。カスタム SQL ステートメントは、ファイルのベースネーム (拡張子「.sql」を除いたファイル名) に基づいて参照できます。 type Meal { id: Int! name: String! } type Query { #- listMeals(contains: String!): [Meal] @sql(statement: "SELECT * FROM Meals WHERE name LIKE :contains") @auth(rules: [{ allow: public }]) listMeals(contains: String!): [Meal] @sql(reference: "listMeals") @auth(rules: [{ allow: public }]) } これで、API を反復処理するスピードが格段に速くなりました。例えば、GraphQL スキーマに以下の内容を追加して、食事を作成する新しい Mutation を追加してみましょう。 type Mutation { createMeal(id: Int!, name: String!): AWSJSON @sql(reference: "createMeal") @auth(rules: [{ allow: public }]) } 注:MySQL から生のレスポンスを取得する手っ取り早い方法として、AWSJSON 型を返します。これは、オプトインできる追加の型安全性を提供しません。同じリクエスト内で変更または作成されたアイテムを返す方法については、ドキュメントを参照してください。 次に、新しい lib/sql-statements/createMeal.sql ファイルを以下の内容で作成します。 INSERT INTO Meals (id, name) VALUES ( :id, :name ); これで、AWS CDK アプリを再度デプロイすることができ、新しい Mutation を持つ API が利用可能になります。 cdk deploy クリーンアップ 生成されたリソースをすべてクリーンアップします。ターミナルで以下の AWS CDK CLI コマンドを実行します。 cdk destroy まとめ このガイドでは、AWS CDK を使用して新しい GraphQL API を作成し、SQL ステートメントを実行する Query とMutation を作成し、それらを認可ルールで保護しました。Amplify GraphQL API の MySQL や PostgreSQL データベースとの統合の詳細については、 既存の MySQL や PostgreSQL データベースへの API の接続に関するドキュメント を確認してください。 本記事は「 Create a GraphQL API for any existing MySQL and PostgreSQL database 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。
この記事は “ Highlights from the AWS Healthcare and Life Sciences Executive Symposium 2023 at re:Invent ” を翻訳したものです。 re:Invent 2023 の初日11月27日にラスベガスで AWS Healthcare and Life Sciences Executive Symposium 2023 を開催しました。この半日の対面イベントには、180の組織から300人以上のリーダーが参加し、データ、分析、機械学習(ML)、生成AIを活用してイノベーションを加速するための各社の取り組みが発表されました。 今年のシンポジウムは、生成AIの可能性によってもたらされた業界の変革的な転換のため、昨年のシンポジウムとは内容が明らかに異なっていました。それは、研究開発の活性化やビジネスのオペレーションの改善、従業員の満足度向上や患者体験の向上など、様々な側面での影響をもたらしました。今年のシンポジウムの主な目的は、これらのユースケースを掘り下げるだけでなく、ビジネス上大きなインパクトをもたらすMLや生成AIアプリケーションを構築する鍵は高品質なデータへの柔軟なアクセスにあることを強調することでした。 以下は、セッションからの主なハイライトと注目すべきインサイトです。 オープニング基調講演のハイライト シンポジウムは、AWSと Merck による共同の基調講演で開始されました。基調講演で語られた重要な点は、 生成AIにとってお客様自身が保有するデータが差別化要因になる ということです。組織を本当に変革することができる強力な生成AIアプリケーションを構築することに成功する企業は、堅牢でエンドツーエンドのデータ戦略から始める企業です。 この概念を具体的に示すために、MerckのCIOであるデイブ・ウィリアムス氏がステージに登場し、クラウド上でデータを活用して自分たち自身を再発明し、AI/MLを活用して再先端の科学を支えるためにAWS上でデータ基盤を構築している方法を紹介しました。彼らのセッションで強調されていたポイントは、CEO主導のデジタル変革プログラムがあったこと、BlueSkyと呼ばれるクラウド推進プログラムがこの変革を進めるための重要な役割を果たしていたことです。さらに、彼らは、組織全体でデータがスムーズに流れるようにするためのOne Merck Data戦略を紹介し、この戦略的アプローチによって促進される影響度の高いAI/MLの利用事例を出席者に紹介しました。MerckのAWSとの連携について詳しくは こちら をご覧ください。 基調講演では、この後に続くセッションを大きく二つのパートに分けて紹介しました。 シンポジウムの第1部では、エンドツーエンドのデータ戦略の概要と、 AWSの包括的なヘルスデータポートフォリオ が組織がその堅牢なデータ基盤を構築し、MLと生成AIの可能性を最大限に解き放つ支援方法に焦点を当てました。 シンポジウムの第2部では、 AWS上でMLと生成AIのブレイクスルーを解き放つ アプローチにフォーカスしました。このパートで、すぐにでも活用できる関連するユースケースと、MLと生成AIを責任を持って活用したアプリケーションを構築するための確率されたガイドラインを探求しました。 第1部のハイライト:データと分析を活用してイノベーションをスケールさせる オープニングのAWS主導のデータセッションでは、エンドツーエンドのデータ戦略が何を含むかについて包括的な概要を出席者に提供しました。組織内のサイロを超えた横断的なデータの統合から、サードパーティやリアルワールドのデータセットへの安全でシームレスなアクセスの促進、マルチモーダルデータからの洞察を抽出するための能力の開発まで、このプレゼンテーションでは、これらの異なる要素が堅牢なデータのバックボーンとして調和して統合される必要があることが説明されました。 ※[社内データサイロを取り除く/適切なユースケースに重要なデータクラスの識別と検索性/サードパーティ・リアルワールドデートへのアクセス・シームレスな統合/外部組織とのデータ連携のためのセキュアでプライバシーを保護する環境/患者の病歴や研究データからインサイトを得るためにマルチモーダルデータを解析するケーパビリティ/データを実行可能なインサイトに変換する包括的な分析、機械学習、生成AIのケーパビリティ] セッションはまた、具体的な「how」の実践的な側面にも踏み込みました。参加者は、AWSの包括的なヘルスデータポートフォリオが組織がイノベーションのハブを作成するのにどのように役立つかについて、 AWS HealthOmics 、 AWS HealthImaging 、 AWS HealthLake 、 AWS HealthScribe など、パーパスビルドなソリューションを通して理解することができました。セッションでは、 AWS Data Exchange 、 AWS Clean Rooms 、 Amazon DataZone など、内部および外部のデータにアクセスして共同作業するための適切なソリューションについてもトップレベルの視点を提供しました。 参加者は、AWS上でエンドツーエンドのデータ戦略のさまざまな要素を積極的に構築している同業者から学ぶ機会を得て、情報をより実践的かつ適用可能にするための貴重な洞察を得ることができました。 Genomics England は、AWSを使用してマルチモーダルデータの保存、検索、ガバナンスを変革している方法について共有しました。セッションでは、 AWS上でがんのための世界最大のマルチモーダルデータプラットフォーム の構築方法について説明しました。 Bristol Myers Squibb は、AWSを活用することで 社内のデータサイロを打破し 、データを利用可能な状態にする方法について紹介しました。参加者は、彼らが構築したデータメッシュアーキテクチャに触れ、組織全体でデータへのアクセスや新薬発見を改善するために、いかに Amazon DataZone を活用する予定かを学びました。 Inovalon のセッションでは、 AWSを使用して外部データコラボレーションを推進する方法 について述べ、Inovalon ONE Platformがヘルスケア・ライフサイエンスの組織がプロプライエタリなデータセットにアクセスし、患者体験を向上させるためによりよい判断を下すための支援方法について説明しました。 プレスリリースはこちら。 Boehringer Ingelheim は、彼らのRWE Center of Excellenceを紹介しながら、リアルワールドデータ(RWD)を活用してイノベーションを加速する方法について共有しました。このセッションでは、新しい世界中のRWDを発見、評価し、エンタープライズレベルのRWDコラボレーションを促進し、リアルタイムに近いデータセットの統合を通してインサイトの創出を加速させるために、A mazon Data Exchange の利用を詳しく説明しました。 最後に、 Stanford Health Care のデータリーダーらを迎えた「MLと生成AIを活用するためのデータの解放」に関するパネルディスカッションが開催され、生成AI利用をProof of Concept段階から全社的な利用につなげるために活用したデータ基盤について議論しました。このセッションはシンポジウムの前半を見事に締めくくり、さまざまな要素が調和してデータ駆動型の組織を作り上げ、MLと生成AIの力を十分に解放する方法を示しました。 第2部のハイライト:ヘルスケア・ライフサイエンスにおけるMLと生成AI イベントの第2部は、AWS主導のセッションで始まりました。このセッションでは、ヘルスケア・ライフサイエンスの企業、組織がAWS上で簡単にMLと生成AIを始める方法に焦点を当てました。セッションでは、AWSの包括的なAI/MLのサービス群がお客様に対してビジネスに応じた適切なツールを構築、購入、カスタマイズできる柔軟性を提供しており、より簡便に、最適なコストで、そして実務上使える状態で、テクノロジーを利用する方法を、説明しました。 参加者は、 Amazon Bedrock の新機能を学びました。これにより、ビルダーはAI21 Labs、Anthropic、Cohere、Meta、Stability AIなどの主要なAI企業の最新の基盤モデルを選択して、生成AIアプリケーションを責任を持って、簡単に作成およびスケールができるようになりました。また、このセッションでは、Amazon Bedrockの簡単な概要を説明し、数クリックでAgents for Amazon Bedrockが基盤モデルを構成し、マニュアルのコードは不要でタスクを自動で分解しオーケストレートします。 実用性を高めるために、現在利用可能なさまざまな関連する生成AI利用事例のクイックデモを紹介しました。これには、公衆衛生と腫瘍学のためのRAGベースのチャットボット、製薬マーケティングコンテンツ生成、新薬探索ワークベンチ、医薬品製造のコンプライアンス監査、およびエンタープライズシステムとデータソースを使用してタスクを実行するエージェントが含まれています。 セッションでは、 NVIDIA BioNemo on AWS でサポートすることも発表されました。これにより、生成AIを使用して先進的な治療法の研究開発を加速するためのR&Dが可能になります。NVIDIA BioNemoは、新薬探索用の生成AIプラットフォームであり、現在 AWS ParallelCluster経由でAmazon SageMaker上 やNVIDIA DGX Cloud on AWS上で利用可能です。これにより、製薬企業の研究者や開発者は、自社のプロプライエタリデータを使用して基盤モデルのトレーニングを簡素化し、加速化することで、新薬探索を容易に速く進めることができます。 AWS上でMLと生成AIアプリケーションを構築する話題は、その後の一連の顧客向けライトニングトークにも続きました。 ライフサイエンス分野では、 Genentech(Roche) が、コマーシャルバリューチェーン内の3つのユースケースで生成AIをAWS上でどのように使用しているかを共有しました。それは、1/個別化された顧客エンゲージメント、2/実行可能な顧客ニーズの検知、および3/測定の自動化と収益シミュレーションです。参加者は、これらのユースケースを実現するためのAWSベースの技術スタックを垣間見るだけでなく、OneRoche Responsible AI Frameworkの仕組みも知ることができました。このフレームワークは、Genentechがエンタープライズレベルのセキュリティを備えた、責任あるソリューションの構築を支援しています。 ヘルスケア分野では、国内最大の放射線診断を行なっている Radiology Partners は、AWSのAWS HealthImagingなどの目的に特化したサービスが、彼らのAIオーケストレーションプラットフォームであるRPX AIを支えている方法を紹介しました。これにより、彼らがサービスする3600人以上の医師と3300以上の医療施設のニーズに応えるために、病院や医療システム向けのAI医療画像ツールを迅速に展開することが可能となります。 MLと生成AIの急速な拡大は革新的なブレイクスルーを確固たるものとしますが、同時に、プライバシー、セキュリティ、ガバナンス、公正性などの新たな課題が提起されています。この日の最後のセッションでは、Anthropic、Baxter、Deloitteのリーダーとの「責任ある安全な生成AIの構築」に関するファイアサイドチャットを開催しました。このセッションでは、各組織が「責任あるAI」をどのように定義し、この急速に変化する状況に対処するための独自のアプローチを概説しました。聴衆は、データセキュリティ、プライバシー、IP保護、および信頼性に関する貴重な知識を得て、AIを組織内で真の善の力として促進するために、複雑さをうまく乗り越えることができるようになりました。 私たちが17年前にAWSを立ち上げたときから、ヘルスケア・ライフサイエンスのお客様は最前線でクラウド利用を進められました。そして、このシンポジウムでMLと生成AIを使用して個別化医療や精密医療に向けて大きな一歩を踏み出す業界のリーダー企業を目の当たりにして感銘を受けました。これは、いわゆる「可能性の範囲内で最善を実現する」をまさに表している取り組みでした。 私たちの包括的なデータ、ML、生成AI提供について詳しくは、 AWS for Healthcare and Life Sciences のウェブサイトをご覧ください。 re:InventでのHCLSの他の発表やハイライトについては、 ブログ をご覧ください。 このブログはヘルスケア・ライフサイエンス事業開発 片岡が翻訳しました。
Amazon Web Services (AWS) は、AWSとして初となる AWS Education Accelerator に参加するスタートアップ企業 15 社を選出したことを発表しました。2023 年 10 月に発表された AWS Education Accelerator は、教育・学習体験を向上させ、教育成果を改善するためにイノベーションを起こす教育テクノロジー (EdTech) のスタートアップ企業を支援します。 教育が進化し続ける中、これまでの教育や学習の慣習にとらわれることなく、生徒が新しい可能性を切り開くためには データドリブンな意思決定が鍵となります。 これは、スタートアップ企業が教育の未来を変える可能性につながり、データ、アナリティクス、人工知能 (AI) を思慮深くかつ公平に活用することで、以下のような大きな教育課題の解決に役立ちます。 参加する EdTech スタートアップ企業は、幼稚園から高校までの教育機関、高等教育機関、人材育成のお客様向けの幅広いソリューションに注力しています。AWS を活用して次世代の EdTech ソリューションを開発することで、これらのスタートアップ企業は、学生のエンゲージメント、金融リテラシー、学生の健康と福祉、スキルアップ、業務の非効率性などの教育課題に対処することを目指しています。 10 週間のアクセラレータープログラムは、シアトルの Amazon 本社で 2024 年 1 月からスタートしています。参加するスタートアップ企業はそれぞれ、最大 10 万ドルの AWS コンピューティングクレジット、ハンズオン、ワークショップ、個別のカリキュラムが用意され、ビジネス指導や技術指導、Amazon のリーダーやチームからのインサイト、潜在的な投資家や顧客とのネットワーキングの機会、継続的なアドバイザリーサポートを受けることができます。プログラムの最後には、教育関係の顧客からの認知度を高めるために、 OMNIA Partners とのコラボレーションによるバーチャルでの Emerging Technology Showcase が開催されます。 本プログラムによって、最終的に EdTech の創業者達が新規顧客の開拓、パートナーネットワークの拡大、資金調達、自らの EdTech スタートアップを急速に成長させる準備が整っている状態を目指します。 プログラムに参加するスタートアップ企業の紹介 今回のプロジェクトに選出されたスタートアップ企業を発表します。採択企業は何千もの応募から、AWS のスタートアップと教育の専門家からなる委員会によって、アイデア力、技術的な準備状況、そして多岐にわたる申請および面接プロセスに基づいて選ばれました。 AWS Education Acceleratorに選ばれた15社のスタートアップは、幼稚園から高校までの教育機関、高等教育機関、人材育成機関向けの幅広いソリューションにフォーカスしています。 各スタートアップの概要と、取り組んでいる課題はこちらをご覧ください: Augmental Learning Inc County of Sussex, DE Augmental は、次世代のパーソナライズされた学習、インテリジェントなコンテンツ作成、データドリブンな分析を提供し、教育コンテンツの作成者を強力にサポートする AI を搭載した学習プラットフォームを提供しています。 Blackbullion London, UK Blackbullion は、学生に金融スキルを身につけさせる金融福祉プラットフォームとアプリケーションです。このプラットフォームは、学生向けのイギリス最大規模の支援基金、奨学金、助成金のハブを有しています。 enlightenAI San Francisco, CA EnlightenAI は、AI を搭載したパーソナライズされた教師用アシスタントを開発しています。採点やフィードバックなど、教育者の仕事をより持続可能なものにしながら、教育者の影響力を高めることを目的としています。 Hilight New Orleans, LA Hilight は、教師や学校スタッフがハイライトを投稿し、学校や地区で毎日起きている多くの小さな成功を共有することを支援します。Hilight は、よく見落とされがちな意味ある瞬間をユーザーが見つけることを助け、教育者の満足度、幸福感、教師の集団効力感 (collective teacher efficacy)、そして勤務継続率を高めます。 Infini‑D Learning Provo, UT Infini-D Learning は、学生が実世界の課題に取り組めるように、ストーリーに基づいた物語と共同での問題解決を組み合わせることで、教室での学習を変える没入型プラットフォームを開発しました。 Lessonbee Mount Vernon, NY Lessonbee は、基準に沿った健康教育の公平なアクセスを学生に提供します。また、学校における健康格差を減らし、公平性を促進するためのツールとリソースを教師に提供しています。Lessonbee の学校全体に向けたウェルネスソリューションは、教師が学生の自己効力感と幸福感を向上させるために役立つデータを提供します。 Listening San Francisco, CA Listening は学生や研究者のために設計されたモバイルアプリケーションを提供します。教科書や研究論文を音声に変換することで、外出先でのインサイトの提供やメモ機能を提供し、研究プロセスの効率化を支援します。 Oblio, Inc. Murrieta, CA Oblio は、入試担当者、教員、スタッフ、コーチによるパーソナライズしたメールの送信、コミュニケーションの効率化、多言語対応を支援するように設計された革新的なAIツールで、大学の入試プロセスを改善しています。 OneRange New York, NY OneRange は、企業による個別学習予算管理の自動化を支援しています。このプラットフォームは、コース、書籍、カンファレンスなど、あらゆる形式の学習リソースに関するデータを活用することで、各個人に適したリソースの発見とアクセスを可能にします。 Perlego London, UK Perlego は、100 万冊以上の学術書をオンラインで購読できるサービスです。出版社と提携することで、印刷、流通、小売にかかるコストを排除し、世界中の学習者により手頃で持続可能なソリューションを提供することを目的としています。 Praxis AI Sacramento, CA Praxis AI は、生成 AI を活用したデジタル教育・研究企業です。いつでも、どこでも利用できるこのソリューションは、学生と教師のやり取りをパーソナライズした指導、評価、サポートと組み合わせて提供しています。 Quizard AI, Inc. Dover, DE Quizard は、テストや小テストの勉強を支援するために設計された大学向けのアプリです。多言語で利用可能な Quizard は、世界中の学生がパーソナライズされた学習にアクセスできるようにしています。 SchoolBI San Francisco, CA SchoolBI は、データドリブンなインサイトを得るのに役立つ、使いやすさを重視したプラットフォームです。このプラットフォームは、従来の非効率性、時間的制約、ボトルネックを削減し、部門横断的に結果を簡単に報告する能力を向上させるように設計されています。 Sown To Grow Oakland, CA Sown To Grow は、簡単で魅力的なプロセスを用いた学生による振り返りと、教師からのフィードバックのプロセスを通じて、学生の社会的、感情的、学問的な幸福度を向上させるために学校を支援するプラットフォームです。Sown To Grow は元教育者のチームによって設計され、米国教育省、米国国立科学財団、Digital Promise、New Schools Venture Fundから資金提供を受けています。 The Juice Miami, FL The Juice は、楽しく魅力的なオリジナルコンテンツを使って、児童の読解力、クリティカルシンキング、情報・メディアリテラシーのスキル、公民の知識を伸ばすためにデザインされたインタラクティブな学習プラットフォームです。 データに基づいた教育における AWS クラウドの理解をさらに深める AWS がどのように EdTech イノベーションを 支援し、学習成果を向上させ、学生のデータを保護するか をご覧ください。さらに、 AWS Education Competency Partners からのサポートや、 AWS Marketplace の教育・学習ソリューション、信頼できる技術プロバイダー、教育機関に様々なクラウドベースのソリューションを提供するコンサルティングの専門家についてもご紹介します。 TAGS: AWS Public Sector , EdTech , education , education technology , higher education , K-12 , learning , startups , teaching Kim Majerus Kim Majerusは、Amazon Web Services (AWS) において、グローバル教育および米国の州政府・地方政府を統括しています。彼女の営業組織には、教育テクノロジー (EdTech) と政府テクノロジー (GovTech)、独立系ソフトウェアベンダー (ISV) 、医療・福祉サービス、司法・公安、交通、州・地方政府顧客向けの IoT にフォーカスするソリューション・バーティカル戦略リーダーが含まれます。 日本の教育機関の皆様へのご支援は こちら をご覧ください。 本ブログはソリューションアーキテクトの山下一樹が翻訳しました。原文は こちら です。
AWS SaaS Factory シニアパートナーソリューションアーキテクト Peter Yang 氏、AWS SaaS Factory プリンシパルパートナーソリューションアーキテクト Ranjith Raman 氏による投稿 Amazon Web Services (AWS) のサービスを使用してデータ取り込みアーキテクチャを設計および実装する方法はいくつかあります。 マルチテナントの Software as a Service (SaaS) 構成でデータを取り込む場合、ソリューションに組み込むべき追加の考慮事項、課題、トレードオフがあります。 SaaS の場合、テナントの詳細を取得し、取り込みプロセス全体で伝達されるようにする必要があります。これは、テナントのペルソナに基づいてデータを分離し、ワークロードとストレージを分割する方法に直接影響します。 マルチテナントデータ取り込みプロセスを実装する際に使用できる戦略は複数あります。専用 (サイロ型) メカニズムを使用するものと、共有 (プール型) 取り込みモデルを使用するものがあります。どちらも完全に有効で、両方を混在させることができますが、この投稿では、プール型モデルでのデータ取り込みの実装の細部に焦点を当て、テナントが取り込みリソースを共有する際に考慮すべきさまざまな点を取り上げます。 この投稿には、コードの実際に動作するサンプルソリューションが付属しています。このソリューションをデプロイするための手順は、 GitHub から参照できます。 マルチテナントデータ取り込みの設計上の考慮事項 ソリューションの技術アーキテクチャについて詳しく見ていく前に、マルチテナントデータ取り込みプロセスを設計する際の主な考慮事項を見ていきましょう。以下は、このようなソリューションを構築する際に SaaS プロバイダーが検討する一般的な要素のリストです: スケーリングとパフォーマンス: 大量のリクエストを処理し、シームレスに数千のテナントにスケールできる能力 セキュリティと隔離: テナントのイベントが認証されていることを保証するためのコントロールを実装し、そのコントロールを使用したデータのパーティショニングと隔離の判断 リソース管理: 突発的で予測が困難なトラフィックを処理するシームレスな容量管理 運用効率: 運用と管理のオーバーヘッドを削減 ソリューションアーキテクチャ この投稿では、データ (EC サイトや POS アプリケーションなどを想定) を収集および集計し、このデータをテナント / 顧客固有の属性で処理 (エンリッチおよび変換) してバックエンドデータストアに格納するサンプルソリューションをもとに説明を行います。 これらのアプリケーションは通常、「注文の合計」や「購入された商品のカテゴリー」などのクリックストリームデータやイベントを追跡し、データからトレンドを特定したり、重要な洞察を導き出すことを目的としています。 任意の瞬間にアクティブなユーザー数によっては、1 秒間に生成されるデータは大量になる可能性があります。 そのようなビジネスやユースケースをサポートするには、非常にスケーラブルでパフォーマンスが高く、イベントを非常に低いレイテンシーで処理できるアーキテクチャが必要です。 次の図は、ソリューションのアーキテクチャを示しています。 図 1 – ハイレベルアーキテクチャ リクエストフロー このアーキテクチャの詳細に入る前に、サンプルソリューションで採用されているハイレベルな要素を見て見ましょう。 以下が、このソリューションの一部であるいくつかのステップです: このソリューションのフローは、図 1 の左側から開始します。テナントは、 Amazon API Gateway が提供する REST API を使用して、SaaS 環境にメッセージやイベントを送信します。これは、ストリーミングイベントのエントリポイントであり、各テナントからのイベントの認証を担当します。 Amazon API Gateway は、 Amazon Cognito を使用してJSON Web Token (JWT) を検証する Lambda オーソライザー を利用します。Lambda オーソライザーは、 Amazon Kinesis Data Streams への入力として使用できるように、Amazon API Gateway のコンテキストに tenantId を追加します。 Amazon API Gateway はプロキシとして機能し、Kinesis Data Streams にテナントイベントをプッシュします。Kinesis Data Streams は、あらゆる規模でデータストリームをキャプチャ、処理、保存するのに適した、サーバレスなストリーミングデータサービスです。この例では、Kinesis Data Streams が異なるテナントからのストリーミングデータを収集するデータインジェストストリームになります。 Amazon Kinesis Data Streams はデータを Amazon Managed Service for Apache Flink  にプッシュします。このソリューションでは Amazon Kinesis Data Analytics for Apache Flink がデータの処理を行い、tenantId とtimestamp の追加に利用されます。これらの値は Amazon Data Firehose がストレージとして利用される Amazon Simple Storage Service (Amazon S3) のプレフィックスの作成に使用します。 Amazon Kinesis Data Analytics for Apache Flink はテナントイベントを Amazon Data Firehose にプッシュします。Amazon Data Firehose は、リアルタイムのストリーミングデータを直接 S3 に配信し、ストレージとさらなる処理のために使用されます。S3 には、マルチテナントデータを効率的に保存および整理するためのいくつかのメカニズムがあります。 より深い考察は、S3 を使用したマルチテナンシー実装のさまざまな戦略が議論されているこの AWS ブログ投稿 をチェックしてください。 これでハイレベルなアーキテクチャを理解したので、ソリューションの各コンポーネントについてより詳しく見ていきましょう。 リクエストの認証と認可 Amazon API Gateway は、このソリューションのフロントドアとして機能し、テナントアプリケーションからのデータストリームをスケーラブルな方法で取り込むための、セキュアなエントリーポイントを提供します。API Gateway を使用することで、テナントコンテキストを抽出し、受信リクエストを認証する Lambda オーソライザー を導入することもできます。 このテナント情報は、テナントが Amazon Cognito によって認証されたときに生成された エンコード済み JSON Web トークン (JWT) を介して渡されます。このコンテキストは、インジェストされたデータを個々のテナントに関連付けることをこのソリューションが可能にするために不可欠です。 API Gateway によって処理される各リクエストは、JWT からテナントコンテキストを抽出し、リクエストのアクセス範囲を設定する AWS Identity and Access Management (IAM) ポリシーを返す Lambda オーソライザーを呼び出します。 ポリシーとともに、リクエストのコンテキストにテナント ID ( tenantId ) も導入します。フローの後半で、このコンテキスト値の利用方法を見ていきます。以下のコード例は、コンテキストの一部として tenantId を設定する方法を示しています。 policy = AuthPolicy(principalId, awsAccountId) policy.restApiId = apiGatewayArnTmp[0] policy.region = tmp[3] policy.stage = apiGatewayArnTmp[1] policy.allowAllMethods() authResponse = policy.build() context = { 'tenantId': tenantId, } authResponse['context'] = context return authResponse Kinesis Data Streams へのデータのルーティング リクエストが正常に処理された後に、メッセージが Amazon API Gateway から Amazon Kinesis Data Streams に転送されるように設定します。これは、テナントデータのストリームを収集および処理します。以下の 図 2 は、設定手順を示しています。 ここでは、統合リクエストの統合タイプを AWS サービスに設定しています。つまり、リクエストを AWS サービス (この例では Kinesis Data Streams) に転送しているということです。 図 2 – Amazon API Gateway の統合リクエスト値 リクエストがストリームに転送される前に、API Gateway で変換を適用して、Kinesis Data Stream が期待している形式にリクエストを変換します。 Amazon API Gateway ではマッピングテンプレートを使用して、メソッドリクエストのペイロードを対応する統合リクエストにマップできます。 ソリューションでは、図 3 に示すように、テンプレートを使用して StreamName、Data、 および PartitionKey の値を設定しています。 Lambda オーソライザー によって設定された コンテキスト の一部として受信した tenantId フィールド を使用して、Kinesis Data Streams で必要な属性である PartitionKey の値を設定しています。 このテンプレートにより、ダウンストリームのサービスに渡されるすべてのリクエストが、そのリクエストを行うテナントとの関連付けがされていることを確認します。 図 3 – Amazon API Gateway マッピングテンプレート Amazon Managed Service for Apache Flink によるストリーミングデータの処理 前のセクションで説明したように、データストリームに送信するすべてのメッセージには、tenantId というパーティションキーがあります。このパーティションキーの値は、メッセージを処理するシャードに影響を与えます。 各 Kinesis ストリームには1つ以上のシャードがあり、シャード数は Kinesis が処理できるデータ量 に直接影響します。 パーティションキーによってはホットシャードを引き起こし、ストリームのパフォーマンスに影響を与える可能性があることに気を付けてください。 データストリームによってメッセージが処理されると、Amazon Managed Service for Apache Flink を使用して、データのさらなる分析を行います。このサービスを使用すると、Java のようなプログラミング言語を使用して、ストリーミングデータを処理および分析できます。 サンプルソリューションでは、データが次のサービスに転送される前に、Flink ジョブを使用してメッセージを追加のフィールドで拡張しています。 図 4 の実装で見られるように、Flink ジョブには inputStreamName があり、これはデータの送信元を示しています。今回の場合は Kinesis Data Stream です。 上述のとおり、Flink ジョブはメッセージを Amazon Data Firehose 配信ストリームにプッシュする前に、tenantId の追加属性とタイムスタンプフィールドも追加します。 図 4 – Amazon Managed Service for Apache Flink – InputStream と FirehoseOutputStream の設定 また、下記の図 5 のコードに示すように、TenantId フィールドはメッセージが Amazon S3 のどのパスに配置されるかを示すために使用され、タイムスタンプは Flink ジョブがメッセージを処理した正確な時刻を反映します。 図 5 – Flink ジョブでのtenantId の設定 Amazon Data Firehose を使用したデータ配信 サンプルソリューションでは、サービスごとのテナント分割モデルを使用してスケールを向上させるために、Amazon Data Firehose を利用してメッセージを S3 に配信しています。これは特に、SaaS システムに多数のテナントがある場合に効果的です。 Flink では、Flink ジョブから直接メッセージを S3 に配信できます。 しかし、データを Amazon Data Firehose に送信することで、このソリューションを将来的に拡張できる柔軟性が得られます。例えば、 Amazon Redshift 、 Amazon OpenSearch Service などの その他の送信先 や、その他のモニタリングソリューションをサポートできるようになります。 図 6 – Amazon Kinesis Data Firehose デリバリーストリーム 図 6 に示すように、配信ストリーム delivery-multi-tenant-firehose-stream は動的パーティショニング機能を利用しています。これにより、データ内のキーを使用して、Data Firehose のストリーミングデータをパーティション分割することができます。 図 7 – tenantId と timestamp を使用した動的パーティショニング キーは、対応するテナントの S3 プレフィックス位置に配信される前のデータのグループ化に用いられます。図 7 に示すように、動的パーティショニングを実装するために、入力メッセージの一部であったフィールド tenantId と timestamp を使用しました。S3 プレフィックスの一部として tenantId があることで、データの消費時に S3 のテナント分離戦略の一部として使用できる IAM ポリシー を作成できます。 最後に、S3 へのデータ配信のために、Amazon Data Firehose は、配信ストリームのバッファリング設定に基づいて、複数の入力レコードを連結します。 S3 へのデータ配信の頻度は、配信ストリームの S3 バッファサイズとバッファ間隔の値によって決まります。 こちらの詳細は、 AWS ドキュメント で確認できます。 結論 この投稿では、AWS のサービスを使用してマルチテナントのデータ取り込みと処理エンジンを構築する方法を探りました。 このデータパイプラインの各コンポーネントと、SaaS のマルチテナントデータ取り込みプロセスの設計アプローチに影響を与える可能性のあるいくつかの主な考慮事項を検討しました。 また、AWS サービスを使用して、マルチテナントのストリーミングデータをどのようにインジェスト、変換、ストレージできるかを確認しました。その際、データの安全な処理を保証するために、パイプラインに構築物が組み込まれていることも確認しました。 ここで紹介したサンプルアプリケーションを掘り下げていくと、AWS 上に完全な実働ソリューションを構築する上でのエンドツーエンドの全体的な体験がよりよく理解できるようになるでしょう。 これにより、SaaS データ取り込みプロセスのニーズと整合性のあるポリシーの周りを形作ることができる一方で、良い出発点を提供するはずです。 このソリューションのより詳細な概要については、環境のすべての動的な要素を理解するのに役立つ段階的なデプロイ手順が記載されている GitHub リポジトリをご覧いただければと思います。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaSの旅路にあるどの段階の組織でも支援します。新しい製品の構築、既存アプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、様々なニーズに対応できます。より多くの技術的、ビジネス的なコンテンツやベストプラクティスを知るには、 AWS SaaS Factory Insights Hub をご覧ください。 SaaS ビルダーは、エンゲージメントモデルについて問い合わせたり、AWS SaaS Factory チームと連携するために、アカウント担当者に連絡することをお勧めします。 こちらに 登録して、 AWS 上の最新の SaaS のニュース、リソース、イベントについて通知を受け取ることができます。 翻訳はソリューションアーキテクトの福本が担当しました。原文は こちら です。 なお、翻訳版では Amazon Kinesis Data Analytics と Amazon Kinesis Data Firehose の名前変更に伴い、それぞれ Amazon Managed Service for Apache Flink、Amazon Data Firehose と表記しています。 https://aws.amazon.com/jp/about-aws/whats-new/2023/08/amazon-managed-service-apache-flink/ https://aws.amazon.com/jp/about-aws/whats-new/2024/02/amazon-data-firehose-formerly-kinesis-data-firehose/
レジリエンスは、あらゆるワークロードの開発において重要な役割を果たしており、 生成 AI ワークロードも例外ではありません。生成 AI ワークロードを開発する際には、レジリエンスの観点における独自の考慮事項があります。組織の可用性と事業継続性の要件を満たすためには、レジリエンスを理解し、優先順位を付けて対応することが不可欠です。本ブログ記事では、生成 AI ワークロードを構成する各スタックとそれらの考慮事項について説明します。 生成 AI ワークロードを構成するスタック 生成 AI の魅力の多くがモデルに焦点を当てていますが、完全なソリューションには複数分野の人材、スキル、ツールが必要です。次の図は、 a16z (Andreessen Horowitz)が公開している大規模言語モデル (LLM) を利用した新しいアプリケーションスタックを AWS の視点で捉えたものです。 従来の AI や機械学習 (ML) を中心としたソリューションと比較すると、生成 AI ソリューションには以下が含まれていることが分かります。 新しいロール – モデルチューナーだけでなく、モデルの開発元やモデルインテグレーターの役割も考慮する必要があります 新しいツール – 従来の MLOps スタックは、プロンプトエンジニアリングやエージェント(他のシステムと対話するツールを呼び出す)に必要な実験の追跡やオブザーバビリティに対応していません 検索拡張生成 (RAG) 従来の AI モデルとは異なり、RAG は外部ナレッジソースを統合することで、より正確でコンテキストに関連したレスポンスを可能にします。RAG を使用する際の考慮事項は以下のとおりです。 外部ナレッジソースからのデータ取得に適切なタイムアウトを設定することは、顧客体験にとって重要です。チャットの最中に切断されることほど、ユーザー体験を損なうものはありません。 プロンプトへの入力データが、利用するモデルのトークン数制限内であることを検証してください。 プロンプトを信頼できるデータストアに保存してください。万が一プロンプトを紛失した場合やディザスタリカバリ戦略の一環として、プロンプトを保護できます。 データパイプライン RAG パターンを使用して基盤モデルにコンテキストデータを提供する場合、ソースデータを取り込み、埋め込みベクトルに変換し、ベクトルデータベースに保存できるデータパイプラインが必要です。コンテキストデータを事前に準備している場合はバッチパイプラインになります。新しいコンテキストデータを逐次取り込む場合は低レイテンシパイプラインとなります。バッチパイプラインの場合、一般的なデータパイプラインと比較して、いくつかの課題があります。 データソースには、ファイルシステム上の PDF ドキュメント、CRM ツールのような SaaS (Software as a Service) からのデータ、既存の Wiki やナレッジベースなどが考えられます。これらのソースからの取り込みは、 Amazon S3 (Amazon Simple Storage Service) 上のログデータやリレーショナルデータベースにある構造化データなどの一般的なデータソースからの取り込みとは異なり、並列処理のレベルがソースシステムによって制限される可能性があるため、スロットリングを考慮し、バックオフ手法を使用する必要があります。また、ソースシステムの一時的な障害等に備えて、エラー処理とリトライロジックを組み込む必要があります。 埋め込みモデルは、パイプライン内でローカルに実行するか外部モデルを呼び出すかに関わらず、パフォーマンスのボトルネックになる可能性があります。埋め込みモデルは主に GPU 上で実行される基盤モデルであり、そのキャパシティは有限です。モデルをローカルで実行する場合は、GPU 容量に基づいてタスクを割り当てる必要があります。モデルを外部で実行する場合は、外部モデルが飽和状態にならないようにする必要があります。いずれの場合も、達成できる並列度は、バッチパイプラインが利用できる CPU や RAM の量ではなく、埋め込みモデルによって決定されます。 低レイテンシパイプラインの場合、埋め込みベクトルの生成時間を考慮してください。アプリケーションは低レイテンシパイプラインを非同期で呼び出す必要があります。 ベクトルデータベース ベクトルデータベースには 2 つの機能があります。埋め込みベクトルの保存および、あるベクトルに対して最も近い k 個のマッチングを見つける類似検索を実行することです。また、ベクトルデータベースには大きく分けて次の 3 つのタイプがあります。 Pinecone 等のベクトルデータベース専用 SaaS 製品やサービスに組み込まれたベクトルデータベース機能( Amazon OpenSearch Service や Amazon Aurora などの AWS サービスも含まれる) 一時データに使用できるインメモリデータベース(低レイテンシが要求されるシナリオ) 本ブログ記事では、類似性検索機能の詳細については説明しません。これらは重要ですが、システムの機能的な側面であり、レジリエンスに直接影響を与えないためです。その代わり、ストレージシステムとしてのベクトルデータベースのレジリエンスの側面に焦点を当てます。 レイテンシ – 高負荷や予測不可能な負荷に対してもパフォーマンスを発揮できますか。そうでない場合、アプリケーションはレート制限やバックオフ、リトライ処理を行う必要があります。 スケーラビリティ – いくつベクトルを保持できますか。ベクトルデータベースの容量を超える場合、シャーディングや他のソリューションを検討する必要があります。 高可用性とディザスタリカバリ – ベクトルデータベースは、単一のリージョンで高可用性を実現していますか。別のリージョンにデータをレプリケートして災害復旧目的で使用できますか。埋め込みベクトルは貴重なデータであり、再生成にはコストがかかります。 アプリケーション 生成 AI ソリューションの統合において、アプリケーションには、3 つの固有の考慮事項があります。 高いレイテンシの可能性 – 基盤モデルは大きな GPU インスタンス上で実行されることが多いため、GPU 容量が確保できない可能性があります。レート制限、バックオフとリトライ、負荷制限のベストプラクティスを使用してください。高いレイテンシがアプリケーションのメインインターフェースに干渉しないように、非同期処理を利用した設計にします。 セキュリティ態勢 – エージェント、ツール、プラグイン、その他の方法を使用してモデルを他のシステムに接続している場合は、セキュリティ態勢に特に注意を払います。モデルはこれらのシステムと予想外の方法でやりとりしようとする可能性があります。たとえば、他のシステムからのプロンプトの受信を制限するなど、標準的なプラクティスである最小特権のアクセス許可に従ってください。 急速に進化するフレームワーク – LangChain のようなオープンソースフレームワークは急速に進化しています。このような成熟度の低いフレームワークから他のコンポーネントを分離するために、マイクロサービスアプローチを使用します。 キャパシティ キャパシティは、推論とトレーニングモデルのデータパイプラインという 2 つのコンテキストで考えることができます。組織が独自のパイプラインを構築する際にキャパシティが考慮事項となります。ワークロードを実行するインスタンスを選択する際、CPU とメモリが最大の要件の 2 つです。 生成 AI ワークロードをサポートできるインスタンスは、汎用インスタンスタイプよりも入手が難しい場合があります。インスタンスの柔軟性は、キャパシティとキャパシティプランニングに役立ちます。使用可能なインスタンスタイプはリージョンによって異なります。 重要なユーザージャーニーの場合、インスタンスタイプを予約または事前プロビジョニングし、必要なときに利用できるよう検討してください。このパターンにより、レジリエンスのベストプラクティスである静的に安定したアーキテクチャが実現できます。AWS Well-Architected Framework の信頼性の柱における静的安定性の詳細については、 静的安定性を使用してバイモーダル動作を防止する を参照してください。 オブザーバビリティ Amazon SageMaker や Amazon Elastic Compute Cloud (Amazon EC2) 上でモデルをホストする場合は、通常収集するリソースメトリクスである CPU や RAM の使用率に加えて GPU の使用率も注意深く監視します。基盤モデルや入力データが変更されると、GPU 使用率が予期せず変化する可能性があります。GPU メモリが不足するとシステムが不安定な状態になる可能性があります。 スタックの上位では、システム内の呼び出しの流れをトレースして、エージェントとツール間の対話をキャプチャすることも重要です。エージェントとツール間のインターフェースは API コントラクトほど正式に定義されていないため、パフォーマンスのみならず、新しいエラーシナリオを捉えるためにもこれらのトレースを監視する必要があります。モデルやエージェントのセキュリティリスクや脅威を監視するために、 Amazon GuardDuty などのツールを使用できます。 埋め込みベクトル、プロンプト、コンテキスト、出力のベースラインとこれらの間の相互作用もキャプチャする必要があります。これらが時間とともに変化する場合、ユーザーがシステムを新しい方法で使用している、コンテキストに渡す参照データが想定問答をカバーできていない、またはモデルの出力が突然変化したことを示している可能性があります。 ディザスタリカバリ 事業継続計画とディザスタリカバリ戦略を策定することは、どのワークロードにとっても必須です。生成 AI ワークロードも例外ではありません。ワークロードに適用可能な障害モードを理解することで、戦略の指針となります。 Amazon Bedrock や SageMaker などの AWS マネージドサービスを使用している場合は、そのサービスが復旧用の AWS リージョンで利用可能であることを確認してください。本ブログ記事の執筆時点では、これらの AWS サービスはリージョン間のデータレプリケーションをネイティブでサポートしていないため、ディザスタリカバリのためのデータ管理戦略を検討する必要があります。また、災害時にファインチューニングされたカスタムモデルを利用したい場合、複数のリージョンにおいてファインチューニングを行っておく必要があります。 まとめ 本ブログ記事では、生成 AI ソリューションを構築する際にレジリエンスを考慮する方法について説明しました。生成 AI アプリケーションにはいくつか興味深いニュアンスがありますが、既存のレジリエンスパターンとベストプラクティスは依然として適用できます。あとは、生成 AI アプリケーションの各スタックを評価し、関連するベストプラクティスを適用することが重要です。 生成 AI と AWS サービスでのその利用に関する詳細は、次のリソースを参照してください。 Securing generative AI: An introduction to the Generative AI Security Scoping Matrix Guardrails for Amazon Bedrock は、お客様のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードの実装に役立ちます (プレビュー版) Llama Guard is now available in Amazon SageMaker JumpStart 著者について Jennifer Moran は、ニューヨークを拠点とする AWS シニアレジリエンシーソリューションアーキテクトです。ソフトウェア開発、アジャイルリーダーシップ、DevOps など、多岐にわたる技術分野で働いた経験を持っています。顧客のレジリエンス向上とその重要性について公に発信することを楽しんでいます。 Randy DeFauw は、AWS シニアプリンシパルソリューションアーキテクトです。ミシガン大学で自動運転車両のコンピュータビジョンについて研究し、電気電子工学の修士号を取得しています。また、コロラド州立大学で MBA を取得しています。Randy はソフトウェアエンジニアリングから製品管理まで、テクノロジー分野のさまざまなポジションを歴任してきました。2013 年にビッグデータ分野に参入し、その分野を探索し続けています。機械学習分野のプロジェクトに積極的に取り組んでおり、Strata や GlueCon など、数多くのカンファレンスでプレゼンテーションを行っています。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。
多くの AWS のお客様は、アーキテクチャをモダナイズし、オープンソースデータベースに移行し始めています。 Babelfish for Aurora PostgreSQL を使用すると、SQL Server から Amazon Aurora PostgreSQL Compatible エディション へのアプリケーションの移行が容易になります。Babelfish では、Aurora PostgreSQL Compatible は一般的に使用される T-SQL 言語とセマンティクスをサポートするため、アプリケーション内のデータベース呼び出しに関連するコード変更の量を減らすことができます。 この投稿では、 AWS Database Migration Service (AWS DMS) を使用したデータ移行を含め、Microsoft SQL Server データベースを Babelfish に移行する方法を示し、移行には SQL Server Northwind サンプルデータベース を使用します。さらに、いくつかの一般的な問題とその解決方法についても検討します。 Babelfish 概要 段階的な移行プロセスを説明する前に、Babelfish のアーキテクチャを見てみましょう。Babelfish は、T-SQL コードやクライアントの接続ドライバーへの変更を最小限に抑えて SQL Server アプリケーションを Aurora PostgreSQL Compatible に移行するための移行アクセラレーターです。これにより、ライセンスを取得した独自のオンプレミスデータベースマネージメントシステム (DBMS) からクラウド内のオープンソース DBMS への移行が可能になり、モダナイゼーションへの道が開けます。 Babelfishは、PostgreSQL が SQL Server 用に作成されたアプリケーションからのクエリを理解する機能を提供します。Babelfish は SQL Server ワイヤプロトコルと SQL Server のクエリ言語である T-SQL を理解しているので、データベースドライバを切り替えたり、アプリケーションクエリをすべて書き直したりする必要はありません。次の図に示すように、SQL Server 接続ライブラリを使った TDS 接続と標準の PostgreSQL 接続を作成できます。 Babelfish の利点は次のとおりです。 既存のクエリを保持 – 言語拡張により Aurora PostgreSQL Compatible で T-SQL と連携できるようになります。 移行を加速 – 移行をより早く完了できるため、数か月から数年の作業を節約できます。 イノベーションの自由 – T-SQL コードをオープンソースの機能と並行して実行し、使い慣れたツールを使用して開発を続けることができます。 ソリューション概要 Babelfish へのマイグレーションの大まかな手順は次のとおりです。 DDL を生成し、 Babelfish Compass ツールを使用して分析を実行します。DDL は次のオプションを使用して生成できます。 SQL Server Management Studio (SSMS) を使用してデータベーススキーマをエクスポートする。 Babelfish Compass v.2023-08 以降では、分析が必要な SQL Server データベースの DDL 生成を Compass がオプションで直接実行することも可能。 Babelfish extension を使用して Aurora PostgreSQL インスタンスを作成します。 ポート 1433 に対して DDL スクリプトを実行して、Babelfish のスキーマを再作成します。 AWS DMS を使用して SQL Server から Babelfish にデータを移行し、SQL Server ではなく Babelfish TDS ポートに接続するようにクライアントアプリケーションを再設定します。 バックエンドが Babelfish である .NET アプリケーションの場合、アプリケーションコードを変更する必要はほとんどありません。 Babelfish でサポートされていない機能 については、アプリケーションコードを変更する必要があります。 以下のセクションでは、SQL Server から Babelfish for Aurora PostgreSQL に移行するためのステップバイステップの詳細を説明します。 Babelfish Compass アセスメントツール Babelfish Compass は、Windows、Mac、Linuxで動作し、Babelfish との互換性を評価するスタンドアロンツールです。このツールは DDL コードと SQL コードを調べ、サポートされている機能とサポートされていない機能をすべて一覧表示した詳細なレポートを提供します。 Babelfish Compass をインストールして実行するには、次の手順を実行してください。 Babelfish Compass の最新バージョン (.zip ファイル) を GitHub からダウンロードしてください。 ファイルを必要なフォルダに解凍します。このフォルダーには 3 つの zip ファイルがあります。 BabelfishCompass_V.2023-08.zip というファイルを解凍する必要があります。 Babelfish Compass には 64 ビット Java/JRE 8 以降が必要です。Compass レポートを実行する前にインストールする必要があります。 CMD (Windows) を開き、zip ファイルを解凍したパスに移動します。 インストールを確認するには、 -help オプションを指定して BabelfishCompass を実行します。 BabelfishCompass -help Bash Northwind データベースの Compass レポートの生成 Compass ツール機能を使用して、Compass v.2023-08 以降で DDL を生成します。このオプションは、SQL Server に多数の SQL Server インスタンスまたはデータベースが存在する場合に便利です。Compass に DDL 生成を実行させるには、次のコマンドラインオプションを指定する必要があります。その後、Compass は SQL Server に接続して DDL ファイルを生成し、生成されたファイルに対して Compass 解析を実行します。 -sqlendpoint – SQL Server のホスト名または IP アドレス。オプションでポート番号を指定することもできます (たとえば、10.123.45.67,1433 や mybigbox,1433)。 -sqllogin – SQL Server に接続するためのログイン名。DDL を生成する権限を得るには、通常、このログインが sysadmin ロールのメンバーである必要があります。 -sqlpasswd – 対応するパスワード。 -sqldblist – これはオプションです。省略するか、all を指定すると、サーバー内のすべてのユーザーデータベースに DDL が生成されます。あるいは、データベース名をコンマで区切ったリストを指定することもできます。 DDL 生成の速度は、SQL Server とのネットワーク上の距離に大きく依存します。時間がかかりすぎる場合は、 CTRL+C を使用してプロセスをキャンセルし、SSMS を使用して手動で DDL 生成を行うと、処理が速くなる場合があります。 BabelfishCompass Northwind-report5 -sqlendpoint < endpoint > -sqllogin < login > -sqlpasswd < password > -sqldblist Northwind -optimistic -reportoptions xref -rewrite Bash 上記のスクリプトは、Babelfish compass レポートを生成し、デフォルトではユーザーの Documents\\ BabelfishCompass フォルダーに保存されます。また、このスクリプトは、指定したデータベースごとに個別の DDL ファイルを生成し、以下のスクリーンショットのようにコンピュータの TEMP ディレクトリに保存します。 compass レポートを生成する他のオプションは、最初に SSMS を使用して DDL を生成し、Babelfish compass コマンドを実行してレポートを生成することです。詳細については、「 Babelfish Compass を Deep Dive する 」を参照してください。 結果の分析 移行作業全体を評価するには、最初にレポートの上部にある概要セクションを確認することです。このセクションには、オブジェクトの数と SQL コードの行数が報告されています。これにより、アプリケーションがどれほど大きく、どれだけの労力が必要かがひと目でわかります。 --- Report Setup --------------------------------------------------------------- BabelfishFeatures.cfg file : v.3.2.0, Jun-2023 Target Babelfish version : v.3.2.0 (PG 15.3) Command line arguments : Northwind-report SMOTest -sqlendpoint ****** -sqllogin **** -sqlpasswd ******** -sqldblist Northwind DDL input files : Northwind_SMO_DDL_2023-Aug-10.sql DDL input files location : C:\Users\ADMINI~1\AppData\Local\Temp\2\CompassAutoDDL-2023-Aug-10-01.36.40 User .cfg file (overrides) : C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.cfg Report name : Northwind-report This report : C:\Users\Administrator\Documents\BabelfishCompass\Northwind-report\report-Northwind-report-bbf.3.2.0-2023-Aug-10-01.37.18.html Session log : log\session-log-Northwind-report-bbf.3.2.0-2023-Aug-10-01.36.40.html ================================================================================ -------------------------------------------------------------------------------- --- Executive Summary for Babelfish v.3.2.0 ------------------------------------ -------------------------------------------------------------------------------- Total #lines of SQL/DDL: 1272 #Procedures/functions/triggers/views: 23 #Tables: 13 SQL features not supported by Babelfish : 127 Estimated complexity of not-supported features: medium:127 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- --- Applications Analyzed (1) -------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents Northwind (1272 lines SQL) -------------------------------------------------------------------------------- --- Assessment Summary --------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents #applications : 1 #input files : 1 #SQL batches : 350 #lines SQL/DDL processed : 1272 #lines SQL in objects : 208 (procedures/functions/triggers/views) total #SQL features : 1208 Supported : 750 Not Supported : 0 Review Semantics : 45 Ignored : 413 Overridden by user .cfg file (C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.Optimistic.cfg): Ignored (was: Not Supported) : 129 -------------------------------------------------------------------------------- --- Object Count --------------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents DATABASE : 1 LOGIN : 51 PROCEDURE : 7 (72 lines SQL) without issues: 7 of 7: list TABLE : 13 (144 columns) without issues: 13 of 13: list VIEW : 16 (136 lines SQL) without issues: 16 of 16: list constraint CHECK : 8 constraint FOREIGN KEY : 13 constraint PRIMARY KEY : 13 index : 26 user-defined datatype (UDD), scalar : 3 HTML 次に、「Not Supported(サポート対象外)」、「Review Manually(手動レビュー)」、「Review Semantics(セマンティクスの確認)」、「Review Performance(パフォーマンスの確認)」、「Ignored(無視)」の「SQL 機能の概要」セクションに着目します。 問題に基づいて、考えられる回避策を開発するか、移行されたアプリケーションに必要のない機能をスケールダウンして移行のスコープを狭めます。移行のスコープを狭めるには、開発者とアプリケーションオーナーの協力が必要です。コマンドで Optimistic オプションを使用すると、一部のコマンドが Not Supported ではなく Ignored の下に一覧表示されます。 Optimistic オプションなしでレポートを生成すると、以下の機能はサポート対象外としてレポートされます。最適化オプションで無視された機能は、アプリケーションを移行する目的では通常は無視できます。 Optimistic オプションを使用して Northwind スキーマの compass レポートを生成する場合、サポートされていない機能はないことに注意してください。 -------------------------------------------------------------------------------- --- SQL features 'Ignored' in Babelfish v.3.2.0 --- (total=413) ---------------- -------------------------------------------------------------------------------- Back to Table of Contents DDL (286/14) Option ALLOW_PAGE_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_PAGE_LOCKS=ON, Index, in CREATE INDEX : 26 Option ALLOW_ROW_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_ROW_LOCKS=ON, Index, in CREATE INDEX : 26 Option DROP_EXISTING=OFF, Index, in CREATE INDEX : 26 Option IGNORE_DUP_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ONLINE=OFF, Index, in CREATE INDEX : 26 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, Index, in CREATE INDEX : 26 Option PAD_INDEX=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option PAD_INDEX=OFF, Index, in CREATE INDEX : 26 Option SORT_IN_TEMPDB=OFF, Index, in CREATE INDEX : 26 Option STATISTICS_NORECOMPUTE=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option STATISTICS_NORECOMPUTE=OFF, Index, in CREATE INDEX : 26 Permissions (39/2) ALTER AUTHORIZATION ON object TO SCHEMA OWNER : 36 ALTER AUTHORIZATION ON TYPE TO SCHEMA OWNER : 3 Users (88/4) ALTER SERVER ROLE processadmin ADD MEMBER : 1 ALTER SERVER ROLE setupadmin ADD MEMBER : 1 Login option CHECK_EXPIRATION, in CREATE LOGIN : 43 Login option CHECK_POLICY, in CREATE LOGIN : 43 HTML Babelfish for Aurora PostgreSQL クラスターの生成 Babelfish クラスターの作成は Aurora PostgreSQL クラスターの作成とほぼ同じです。Babelfish for Aurora PostgreSQL は Aurora PostgreSQL バージョン 13.4 以降でサポートされているため、サポートされているバージョンを選択して Babelfish の設定セクションで「Babelfish をオンにする」にチェックします。 Babelfish クラスターを作成するときは、移行された単一の T-SQL ユーザーデータベースを使用するか、移行した複数の T-SQL ユーザーデータベースを一緒に使用するかを選択します。 single-db を指定した場合、Babelfish では 1 つの T-SQL データベースしか作成できず、T-SQL スキーマは Babelfish データベースでは通常の PostgreSQL スキーマとして作成されます。マルチデータベースモードでは、PostgreSQL からアクセスすると、ユーザーデータベースのスキーマ名は dbname_schemaname になります。T-SQL からアクセスするとスキーマ名は同じままです。詳細については、「 1 つのデータベースまたは複数のデータベースでの babelfish の使用 」を参照してください。 Babelfish クラスター内の複数の T-SQL ユーザーデータベースがサポートされるため、移行モードには multi-db を使用することをお勧めします。クラスターの作成後にこの値を変更することはできないため、最初は T-SQL ユーザーデータベースが 1 つしか必要ない場合でも柔軟性を持たせたほうがよいです。 SQL Server に近い状態にしておくために、プライマリユーザー名として sa を選択できます。 Babelfish クラスターを作成すると、リーダーとライターという 2 つのエンドポイントが提供され、異なるポートで PostgreSQL と T-SQL の両方がサポートされます。 Babelfish クラスターへの接続 次のステップは、Babelfish クラスターとの接続を確立し、SQL Server Management Studio (SSMS) を使用して新しいデータベースにスキーマを作成することです。SSMS は SQL Server に接続するための GUI ベースのクライアントツールで、オブジェクトエクスプローラーによるオブジェクトの表示とスクリプト作成は限定的にサポートされています。 Babelfish エンドポイントクラスターと認証情報を入力し、[接続] を選択します。 SSMS で DDL スクリプトを実行する Babelfish のスキーマの再作成 Babelfish でスキーマを再作成するには、以下の手順に従ってください。 次のクエリを使用して、Babelfish と Aurora PostgreSQL のバージョンを確認してください。 -- Check your version SELECT SERVERPROPERTY ( 'babelfishversion' ) AS BabelfishVersion , aurora_version ( ) AS AuroraPostgreSQLVersion , @ @VERSION AS ClassicSQLServerVersion GO SQL Babelfish のエスケープハッチを無視するように設定 – Babelfish は可能な限り、制御フローとトランザクション状態の SQL 動作を模倣します。Babelfish はエラーに遭遇すると、SQL Server のエラーコードと同様のエラーコードを返します。失敗する可能性のあるステートメントを処理するために、Babelfish ではエスケープハッチと呼ばれる特定のオプションを定義しています。エスケープハッチは、サポートされていない機能や構文に遭遇したときの Babelfish の動作を指定するオプションです。以下のステートメントを使用して、すべてのエスケープハッチが厳密な動作を無視するように設定します。 EXECUTE sp_babelfish_configure '%' , 'ignore' , 'server' ; GO SQL Northwind データベースを作成し、T-SQL カタログビューを使用して検証します。 -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL Babelfish と PostgreSQL 間のスキーママッピングを確認してください。この情報は、データロード用の DMS タスクを作成するのに役立ちます。 SELECT pg . dbname AS BabelfishDBName , be . orig_name AS SchemaName , pg . nspname AS PGSchemaNameForDMS , pg . oid , SCHEMA_ID ( be . orig_name ) AS MapsToPGOID FROM sys . pg_namespace_ext AS pg INNER JOIN sys . babelfish_namespace_ext AS be ON pg . nspname = be . nspname WHERE dbname = DB_NAME ( ) ORDER BY SchemaName ; SQL Babelfish クラスターに選択した multi-db または single-db 構成に応じて、異なる結果が表示されます。これは、PostgreSQL がこれらのオプションごとにデータベース名とスキーマ名を内部的に異なる方法でマッピングするためです。 multi-db の Babelfish クラスターの結果: single-db の Babelfish クラスターの結果: 完成したスクリプトを実行して、Babelfish でスキーマオブジェクトを作成します。 Babelfish は現在、DMS での BYTEA データ型を使用したバイナリ、VARBINARY、および IMAGE データ型の移行をサポートしています。Northwind データベーススクリプトを変更して、任意の IMAGE データ型を BYTEA に変更してください。元の Northwind データベースでは、カテゴリテーブルの Picture 列は IMAGE データ型を使用し、Employee テーブルの Photo 列は IMAGE データ型を使用します。最後のスクリプトでは、以下のように検索して置換します。 [ image ] with [ bytea ] /* [ image ] */ Bash テーブルにプライマリキーとユニークキーのみを使用してスクリプトを実行すると、データロードプロセスが高速化され、データロードプロセスが終了したら追加のインデックスと制約を作成できます。 以下のスクリプトを使用して、前のステップで作成したテーブルを検証します。 --using T-SQL view SELECT * FROM sys . tables ; SQL AWS DMS を使用した SQL Server から Babelfish へのデータ移行 AWS DMS バージョン 3.5.1 では、Babelfish マイナーバージョン 14.8 および 15.3 以降の Aurora PostgreSQL のサポートデータタイプのサポートが強化されています。SQL Server ソースエンドポイントと Aurora PostgreSQL ターゲットエンドポイントで DMS の使用を開始する方法は次のとおりです。 AWS DMS コンソールで、ワークロードに応じてインスタンスのサイズを選択して レプリケーションインスタンスを作成 します。 ソースエンドポイントとターゲットエンドポイント を作成します。 ソースエンドポイント – ソースエンドポイントは SQL Server を指している必要があります。 ターゲットエンドポイント – Aurora PostgreSQL ターゲットエンドポイント は Babelfish にデータを移行するための推奨方法です。AWS DMS コンソール、API、または CLI コマンドを使用して AWS DMS ターゲットエンドポイントを作成するときは、次の点に注意してください。 ターゲットエンジンを Amazon Aurora PostgreSQL として指定します。 データベースに babelfish_db という名前を付けます。 エンドポイント設定セクションで、 DatabaseMode を Babelfish に、 BabelfishDatabaseName をターゲットの Babelfish T-SQL データベースの名前に指定した設定を追加します。マイナーバージョン 15.3 および 14.8 より前の Aurora PostgreSQL で Babelfish を使用している場合は、これらのエンドポイント設定を使用しないでください。 レプリケーションタスクを作成 して開始し、ターゲットデータベースに指定されたテーブルのデータをロードします。AWS DMS エンドポイントとしての Babelfish の詳細については、「 AWS Database Migration Service のターゲットとしての Babelfish の使用 」を参照してください。 Northwind データベースを移行するためのタスク設定は次のとおりです。 ターゲットテーブルの準備 -「何もしない」。このモードでは、AWS DMS はターゲットデータベースを変更しません。Babelfish 3.2.0 および 2.5.0 リリースの DMS 3.5.1 の新機能を活用するには、フル LOB モードを選択する必要があります。 テーブルマッピングルール – スキーマ名が ‘dbo’、ソーステーブル名が ‘%’ のような dbo スキーマのすべてのテーブル、またはソース SQL Server データベースの特定のテーブルを含めるには、次のルールを追加します。 変換ルール – multi-db または single-db 構成に応じて必要な変換ルールは次のとおりです。 multi-db モードを使用する場合は、お使いの PostgreSQL スキーマである northwind_dbo と一致するように dbo スキーマの名前を変更してください。 どちらのモードでも、テーブルの名前を小文字に変更します。以下のスクリーンショットは変換ルールを示しています。 テーブル統計を確認して、データのロードを確認します。DMS レプリケーションタスクが正常に完了すると、テーブル統計を表示できます。 あるいは、データベースにクエリを実行してデータを検証することもできます。 SELECT TOP 10 * FROM categories ORDER BY [ CategoryID ] SQL BYTEA データ型を IMAGE に戻す – ほとんどのアプリケーションは BYTEA で正常に動作しますが、IMAGE に戻す必要がある場合は、以下のスクリプトを使用して IMAGE データ型の新しい列を追加、その列にデータをコピーしてから元の列を削除し、最後に元の列名と一致するように名前を変更します。 ALTER TABLE [ dbo ] . [ Categories ] ADD [ PictureImage ] IMAGE NULL ; UPDATE [ dbo ] . [ Categories ] SET [ PictureImage ] = [ Picture ] ; SELECT [ CategoryID ] , CASE WHEN CAST ( [ Picture ] AS Image ) = [ PictureImage ] THEN 'Match' ELSE 'No Match' END AS [ Compare ] FROM [ dbo ] . [ Categories ] ; ALTER TABLE [ dbo ] . [ Categories ] DROP COLUMN [ Picture ] ; -- Rename column EXEC sp_rename 'categories.pictureimage' , 'Picture' , 'COLUMN' ; SQL DMS からデータを読み込んだ後、IDENTITY 列をリセットします。SQL Server では、IDENTITY 列を主キーに使用したり、値の自動インクリメントが必要なその他の列を使用したりするのが一般的です。IDENTITY 列または SERIAL データ型を使用するテーブルを含むデータを移行したら、以下のスクリプトを使用して列の最大値に基づいて PostgreSQL ベースのシーケンスオブジェクトをリセットします。 -- following T-SQL query to generate statements to seed the associated sequence object. USE Northwind ; GO DECLARE @schema_prefix NVARCHAR ( 200 ) = '' IF current_setting ( 'babelfishpg_tsql.migration_mode' ) = 'multi-db' SET @schema_prefix = db_name ( ) + '_' SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name ( tables . schema_id ) + '.' + tables . name + ''', ''' + columns . name + ''') ,(select max(' + columns . name + ') from ' + schema_name ( tables . schema_id ) + '.' + tables . name + '));' FROM sys . tables tables JOIN sys . columns columns ON tables . object_id = columns . object_id WHERE columns . is_identity = 1 UNION ALL SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));' FROM information_schema . columns WHERE column_default LIKE 'nextval(%' ; SQL 次のステートメントは、前のクエリによって生成されます。Northwind データベースに対して実行してください。 -- Generated statements SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.categories' , 'categoryid' ) , ( select max ( categoryid ) from dbo . categories ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.employees' , 'employeeid' ) , ( select max ( employeeid ) from dbo . employees ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.orders' , 'orderid' ) , ( select max ( orderid ) from dbo . orders ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.products' , 'productid' ) , ( select max ( productid ) from dbo . products ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.shippers' , 'shipperid' ) , ( select max ( shipperid ) from dbo . shippers ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.suppliers' , 'supplierid' ) , ( select max ( supplierid ) from dbo . suppliers ) ) ; SQL SSMS のスクリプト生成ウィザードを使用して、次のように作成スクリプトを再生成します。 データベーステーブルだけのスクリプトを作成して、チェック制約、インデックス、トリガーなどを別のファイルに含めます。テーブルはすでに移行されているので、テーブル作成セクションをコメントアウトしてください。最終的なスクリプトには、インデックス、制約、トリガーのみを含める必要があります。Babelfish クラスター内の Northwind データベースに対してスクリプトを実行します。 ビューだけのスクリプトを作成し、Babelfish クラスターの Northwind データベースに対して実行します。 ストアドプロシージャだけのスクリプトを作成し、サポートされていない機能を修正して、Babelfish クラスターの Northwind データベースに対して実行します。 移行の問題と解決策 このセクションでは、以前の移行作業でお客様に見られた、バージョン 3.2 の Babelfish の問題点と考えられる解決策について説明します。 ストアド・プロシージャおよびストアド・ファンクションでサポートされていない機能 アプリケーションのテストをより早く開始するための方法の 1 つは、サポートされていないストアドプロシージャ本体をコメントアウトし、例外を投げたりエラーを発生させたりすることです。ストアドプロシージャのシグネチャ (名前、入力、出力) は引き続き維持されます。理論的には、パラメータ化された正規表現 (グループキャプチャ付き) を書いてこれを行うことができます。以下に例を挙げます。 これにより、サポートされていない機能のサブセットが原因で、解決に時間がかかる可能性がある一部のテスト作業を中断することなく、サポートされていない問題を切り分け、個別にリリースして修正することができます。 トラブルシューティングクエリ これは、Babelfish への移行後に最もよく発生する問題です。これらの問題の多くは、SQL Server と PostgreSQL の間で異なるインデックス戦略が原因であることが多く、PostgreSQL 側の EXPLAIN ANALYZE または SET BABELFISH_STATISTICS PROFILE を使用して診断できます。 よくある問題は、述語 (predicate) の列に式がある場合でも SQL Server はインデックス付き列を使用できるが、PostgreSQL では使用できないというものです。解決策は、PostgreSQL で述語式と一致する式インデックスを作成することです。クエリを分析したら、インデックスと JOIN 条件が適切であることを確認して、考えられる修正を適用してください。次のコードを使用してください。 SET BABELFISH_STATISTICS PROFILE {ON|OFF} を使用して、ステートメントの実行に使用されたクエリプランを表示します SET BABELFISH_SHOWPLAN_ALL {ON|OFF} を使用すると、コマンドを実行せずにステートメントの推定説明プランを表示できます。 次の例では、 BABELFISH_SHOWPLAN_ALL がアクセスパス、インデックススキャン(存在する場合)、および操作のコストの詳細を提供し、パフォーマンスチューニングに役立ちます。 SET BABELFISH_STATISTICS PROFILE ON GO SELECT * FROM test a JOIN test2 b ON a . a = b . a WHERE b . c = 'A926' SQL この例では、パフォーマンスを向上させるために、列 c の test2 にインデックスを作成します。これは実行計画に反映され、操作のコストも削減されます。 CREATE INDEX ix_test_1 ON test2 ( c ) ; SQL 詳細については、「 クエリプランのレビュー 」を参照してください。 統計情報の更新 データベースオブジェクトの統計情報は、クエリのパフォーマンスにとって重要です。データベースオプティマイザーは、これらの統計情報を使用して最適な実行プランを決定し、それをデータ取得に使用します。 この記事の執筆時点では、Babelfish では統計情報の収集と更新はサポートされていません。回避策として、PostgreSQL の機能を使用してテーブルの統計情報を取得してください。 SQL Server command – UPDATE STATISTICS PostgreSQL command – ANALYZE 詳細については、 ANALYZE を参照してください。 テーブルインデックスの再構築 インデックスはクエリのパフォーマンスにとって重要です。T-SQL では、インデックスの再作成に DBCC コマンドまたは ALTER INDEX コマンドのいずれかを使用します。 DBCC DBREINDEX ( 'northwind . dbo . employees’ ) ; ALTER INDEX ALL ON northwind . dbo . employees REBUILD ; SQL これらのコマンドは Babelfish ではサポートされていません。代わりに、PostgreSQL 接続から PostgreSQL ステートメント REINDEX TABLE を使用できます。 REINDEX TABLE dbo . employees’ ; SQL 詳細については、「 テーブルインデックスの再構築 」を参照してください。 Babelfishではサポートされていないコード機能 Babelfish 関数またはコード構文と SQL Server にはいくつかの違いがあります。次の表は、回避策の例をいくつか示しています。 SQL Feature Babelfish Workaround MERGE 文 Compass レポート書き換えオプションを使用すると、MERGE ステートメントの回避策が生成されます。 -MERGE を UPDATE に置き換え、必要に応じて挿入を追加します。 UPDATE LOCATIONS SET LocationName=S.LocationName FROM Locations T, Locations_stage S WHERE T.LocationID=S.LocationID AND ( T.LocationID =3 ) EOMONTH () などの日付関数 サポートされていない日付関数のほとんどは、DATEADD や DATEPART などを使用する Compass rewrite オプションで書き換えられます。 PIVOT clause SUM (WHEN…) 句を使用してステートメントを書き直します。 UPDATE, WITH (Common Table Expression) as target このステートメントは Babelfish ではサポートされていません。必要なすべての条件を WHERE 句に入力して、もとになるテーブルに対して UPDATE ステートメントを手動で書き換えます。 DBCC commands DBCC は、データベースメンテナンスのための SQL Server ネイティブコマンドです。Babelfish の基盤となるデータベースである PostgreSQL データベースエンジンは DBCC をサポートしていないため、Babelfish の場合は PostgreSQL コマンドを特定の目的に使用してください。 DEFAULT パラメータ値を使用したプロシージャまたは関数を呼び出し Babelfishは、プロシージャまたは関数呼び出しでの DEFAULT キーワードをサポートしていません。Compass は、DEFAULT キーワードの代わりに実際のデフォルトパラメータ値を使用して呼び出しを書き換えます。次に例を示します。 –Before rewrite dbo.stored_procedure_1( @variable1, parameter_value, DEFAULT, DEFAULT, DEFAULT) –After Babelfish Compass rewrite dbo.stored_procedure_1( @variable1, parameter_value, /*REWRITTEN*/ 'N/A' /*DEFAULT*/, /*REWRITTEN*/ NULL /*DEFAULT*/, /*REWRITTEN*/ 0 /*DEFAULT*/) まとめ この投稿では、Babelfish Compass ツールと AWS DMS の使用を含め、SQL Server アプリケーションを Babelfish for Aurora PostgreSQL に移行する手順を示しました。サポートされていない機能の詳細を知るために、Babelfish Compass レポートで注目すべきセクションについて説明しました。また、AWS DMS を使用して Babelfish クラスターにデータをロードする方法の詳細も示しました。最後に、Babelfish の移行を加速させるのに役立つ一般的な移行問題と、考えられる解決策について説明しました。 AWS Babelfish チームは、製品を継続的に改善し、定期的に新機能を追加しています。 最新の改善点 については、四半期ごとにリリースされる Babelfish for Aurora PostgreSQL のアップデートを確認してください。 Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL 」を参照してください。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Amit Arora は、AWS でデータベースと分析を専門とするソリューションアーキテクトです。金融テクノロジー、世界のエネルギー分野のお客様、AWS 認定パートナーと協力して、クラウド移行プロジェクトに関する技術支援や顧客ソリューションの設計を行い、お客様が既存のデータベースを AWS クラウドに移行して近代化できるよう支援しています。
みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 今週木曜に AWS Innovate AI/ML and Data Edition が開催されます。オンライン開催で「生成AI 」「AI/MLプラットフォーム」「ビジネスユースケース」のトラックが用意されていますので、ぜひご興味のあるセッションに参加ください。 – AWS Innovate AI/ML and Data Edition 2024 年 2 月 22 日 (木) また、3月2日の JAWS DAYS 2024 も近づいてきましたね。そろそろ残席が少なくなってきているようなので、早めの申し込みをお勧めします。 – JAWS DAYS 2024 – LEAP BEYOND それでは、先週の主なアップデートについて振り返っていきましょう。 2024年2月12日週の主要なアップデート 2/12(月) AWS Wickr now allows you to try premium features for free AWS Wickr で、StandardプランとPremiumプランの機能を最大3ヶ月間無料で試すことができる拡張フリートライアル体験(enhanced free trial experience)が利用可能になりました。Wickrはエンドツーエンドの暗号化されたメッセージングとコラボレーションを支援するサービスです。 Amazon DocumentDB (with MongoDB compatibility) now supports text search Amazon DocumentDB (MongoDB互換性) で、テキスト検索がサポートされました。フィールドにインデックスを作成しておくことで高速なテキスト検索を実現します。Amazon DocumentDB 5.0以降で利用可能であり、現時点では英語のみのサポートです。 Amazon DocumentDB (with MongoDB compatibility) now supports maintenance notifications Amazon DocumentDB にメンテナンス通知の機能が追加されました。これにより、AWS Health DashboardやEメールを通じて、スケジュールされたメンテナンスアクティビティについて通知を受け取ることができるようになります。 AWS AppSync introduces 12 new Amazon CloudWatch metrics for enhanced monitoring AWS AppSync で使用状況とパフォーマンスのより詳細な可視化を実現するために、より多くのメトリクスが提供されるようになりました。利用者のメトリクスの拡張として、リクエストとエラーのカウント、レイテンシー、キャッシュヒット/ミスの詳細なビューといった新しいオプションを含むようになりました。また、ネットワーク/CPUスループットの問題を診断する際に役立つ2つのキャッシュメトリクスも追加されました。詳細は こちらのドキュメント をご覧ください。 2/13(火) Amazon EMR on EC2 now supports retrieval of 10,000 steps completed within last 7 days Amazon EMR Step(ENRのジョブ管理の単位)のAPIであるDescribeStepとListStepで、過去7日間に完了した最大10,000ステップの取得をサポートするようになりました(以前は1,000ステップまででした)。 Amazon Redshift announces support for the INTERVAL data type and Continue Handler statements in stored procedure Amazon Redshiftで INTERVAL データ型がサポートされました。これは期間(レンジ)を表現するための型です。例えば12時間、6週間、1ヶ月などを定義できます。詳細は こちらのドキュメントをご覧ください 。 2/14(水) Amazon OpenSearch Service now lets you update cluster volume without blue/green Amazon OpenSearch Service でブルー/グリーンデプロイメント(Blue/Green deployment)を必要とせずに、クラスターのボリュームサイズ、ボリュームタイプ、IOPS、スループットを変更できるようになりました。ブルー/グリーンデプロイメントの場合、別クラスターを新しい設定で平行して起動してから移行しますが、こういった手間や時間をかけることなく変更が可能になりました。 Amazon OpenSearch Serverless now supports TLS 1.3 and perfect forward secrecy Amazon OpenSearch Serverless で TLS 1.3 が利用可能になり、合わせて perfect forward secrecy もサポートされるようになりました。これは暗号化プロトコルの仕様として、仮に秘密キーが漏洩した場合でも、以前のセッションで暗号化されたデータの安全性を守るように鍵を利用する手法であり、外部からのアタックに対してより堅牢な通信を実現します。 2/15(木) API Gateway now supports TLS 1.3 API Gatewayが TLS 1.3 をサポートしました。これによりラウンドトリップ(1-RTT)の TLS ハンドシェイクを使うことによるパフォーマンスを最適化と、前述の OpenSearch Service と同様に perfect forward secrecy をサポートする暗号のみを使うことで、セキュリティの強化を提供します。 Amazon RDS for Db2 now supports audit logging Amazon Relational Database Service (Amazon RDS) for Db2 がデータベースの監査ログをサポートするようになりました。これを有効化することで、 IBM Db2 ネイティブの監査機能が利用可能になります。監査ログは Amazon S3 に格納されます。詳細は こちらのドキュメントを参照 してください。 2/16(金) Amazon MSK now supports in-place version upgrades for Tiered Storage enabled clusters Amazon MSK がTiered Storage対応クラスターにおいて、インプレースバージョンアップグレードをサポートしました、v2.8.2.tieredを使用しているクラスターは、最新のApache Kafka 3.6.0にアップグレードできるようになりました。v3.6.0はTiered Storageの本番環境グレード(production-grade Tiere)での稼働サポートが含まれています。 Amazon Data Firehose enables selecting a time zone for bucket prefixes when delivering streams to Amazon S3 Amazon Data Firehose (※Amazon Kinesis Data Firehoseから改名されました) で、Amazon S3バケットへのストリーム配信時に、タイムゾーンを選択したバケットプレフィックスの作成が可能になりました。これまでは日本時刻でPrefixを作成する場合にはLambdaとの組み合わせ等が必要でしたら、今回の改善で設定のみで利用可能になりました。詳細は こちらのドキュメントをご覧 ください。 最後に、ちょっと気が早いですが今年のAWS Summitの開催日程が決まりましたので、ご案内します。今年は 2024 年 6 月 20 日(木)~21日(金)の2日間、幕張メッセでの開催です。以下のサイトでEメールアドレスを登録しておいていただくと、申し込み開始時に通知が届きます。 – AWS Summit Japan それでは、また来週! ソリューションアーキテクト 下佐粉 昭 (X/Twitter – @simosako )
Amazon QuickSight Community は、AWS が提供する Business Intelligence(BI) サービスの QuickSight に関する様々な情報がまとまっており、QuickSight を利用時に出てきた疑問点を質問できるコミュニティです。その QuickSight Community において、2024年2月19日より日本語で質疑応答ができるようになりました。これにより、日本の QuickSight ユーザ間でネットワークを作り、スキルの向上を図ることができるようになります。Amazon QuickSight Community では、様々な学習に役立つコンテンツや、最新の情報などを提供しており、日本語のリソースも Japanese タグにて検索し、参照できるようになっています。 このブログでは、Amazon QuickSight Community の機能について紹介し、Japanese タグの日本語リソース確認方法、Community へのサインアップ方法、日本語での質問の投稿や返答、解決や通知方法について紹介します。 QuickSight Communityとは QuickSight Community にアクセスすると、以下のようなホーム画面が表示されます。 上部メニューバーは、各種リソースにすばやくアクセスできるようにそのリンクを提供しています。(一番左にある Q&A から Japanese(日本語) を選択することにより、以下で紹介する 日本語で質問|Q&A カテゴリーに直接アクセスすることができます) その時点での注目イベントやアナウンスメントを大きく紹介し、イベントのリンクや、新機能に関する情報をすばやくアクセスできるようになっています。 カテゴリー (Categories)の一覧です。そして、このカテゴリーに 日本語で質問|Q&A が追加されました! Question & Answer (英語による質疑応答の一覧。検索も可能) Learning Center (動画やウェビナー、ワークショップなどスキル向上に必要なリソースを集約) What’s New / Blog (最新の製品アップデートやアナウンスメントとブログ) Events (週次・月次ウェビナーやオフラインイベントのサインアップ) Gallery (Arenaで作成したダッシュボードの公開ページ) 日本語で質問|Q&A (日本語による質疑応答の一覧、検索も可能) 日本語で質問|Q&A に入ると、日本語で投稿された質問の一覧が表示され、質問のタイトル(TOPIC)、返答数(REPLIES)、View数(VIEWS)、質問に対する最新アクティビティ日付(ACTIVITY)を確認できます。(質問の方法については、次の章で詳しく解説します) Learning Center に入ると、コンテンツのタイプによりさらにサブカテゴリー化されています。その中に 動画 | Japanese Videos というサブカテゴリーがあります。 その中に入ると、2023年に実施した QuickSight RoadShow in 東京のセッションを視聴することができるようになっています。 同じく、今度は Learning Center 内の Getting Started に入り、 Japaneseタグ で検索します。 日本語のコンテンツが表示されます。 How-to Video や Article も同様に Japaneseタグ にて、日本語コンテンツを参照することができます。 また、 What’s new / Blog に入り、同様に Japanese タグ で検索すると、日本語で提供されているブログを参照することができます。 今度は、 Events (イベント)にアクセスします。 同様に Japanese タグ で検索すると、現在日本語で開催予定にしているイベントの一覧を確認することができます。 日本語 Leaning Series の第一回を、3月27日12時から開催予定にしており、昨年末にリリースされた2つの新機能についてデモを交えながら紹介させていただきます。登録リンク先などの詳細情報は このトピック をクリックいただくことで、参照することができます。ぜひご登録ください。QuickSight に関わる日本語のイベントは今後この一覧にて通知する予定です。 実施した日本語Learning Seriesは録画され、 Learning Center 内の Learning Series Videos にアップロードされ、いつでも視聴することができるようになります。 QuickSight Community に参加する QuickSight Community ではログインしない場合でも、提供されているコンテンツをブラウズしたり検索することができますが、アカウントを作成いただくことで、質問をしたり、投稿への返答、コンテンツや返答にLikeをマークすることができるようになります。当 Community はパプリックコミュニティになるので、機密事項や個人情報に関わる情報については記載しないようお願いします。 Community へのサインアップ サインアップするには、以下のステップを実施します。 ホームページの右上にある Sign Up ボタンをクリックします。 既存の Amazon アカウント(米国 amazon.com のアカウント)を使用するか、EメールをIDに新しいアカウントを作成するかを選択します。EメールをIDに新しいアカウントを作成する場合は、Eメールアドレス、ユーザ名、パスワードを設定し、Create your account ボタンをクリックします。 新規にアカウントを作成した場合は、入力したEメールアドレスにアクティベンーションリンクが送られるので、それをクリックするだけで、アカウントの作成が完了します。 日本語で質問を投稿する ログインいただくことで、質問が投稿できるようになります。まず、質問を投稿する前に、検索にて同様の問い合わせが既に投稿されていないかを確認しましょう。 質問を投稿する手順は以下の通りです。 日本語で質問|Q&A に入り、 ? New Question  ボタンをクリックします。 投稿する質問内容について、タイトルを入力すると、その内容に基づき、既存の質問の中から類似した質問が右にリスト表示されます。同様の問い合わせがないようなら、投稿する前にタグを設定して下さい。タグを設定することにより、検索がしやすくなり似たような質問を見つけやすくなります。タグは最低2つ設定する必要があります。まず、ドロップダウンに表示されている author , developer , admin の中から該当するものを選択します(ビジュアル作成に関わる場合は author 、API やSDK 等に関する問い合わせの場合は developer 、ユーザやアセット、SPICE、サブスクリプションなどの管理面に関する問い合わせの場合は admin になります) その他のタグは、該当するタグを検索することにより、選択することができます。必ず、 Japanese タグを追加するようにしましょう。  タグの設定が完了したら、質問の内容について記述します。マークダウン記法をサポートする形で、テキスト入力だけでなく、ハイパーリンクやコードなどフォーマット済みテキストの入力、blockquote <引用タグ>の利用も可能で、入力すると、右にプレビュー表示がされるので入力と同時に確認することができます。 イメージのスクリーンショットもコピー&ペーストで可能です。 質問内容の入力が完了したら、その下にある + New Quetion ボタンをクリックします。 日本語の質問に応答する ログインいただくことで、既に投稿されている質問に応答することができます。遠慮せずに積極的に返答をしたり、 (like this post)マークを提供し、Community を盛り上げていきましょう! 返答は、 Reply ボタンをクリックします。 画面下に、返答入力用のフォームが提示されるので、返答内容を入力し、 Reply ボタンをクリックします。 特定の返答に対して応答するには、各返答下にある Reply アイコンをクリックすることで応答することができます。 また、気に入った返答に対しては、 (like this post)マークをクリックしましょう 日本語で投稿した質問への対応 投稿した質問に対しては、通知設定をすることができます。投稿した質問下にある (通知ベル)表示をみると、デフォルトでは Normal 設定となっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。クリックすることで、以下のような通知設定に変更することができます。 Watching :全ての返答が新規にあった場合に通知され、その返答数がリスト上に明示されます Tracking :返答数がリスト上に明示され、Normal設定と同様名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知されます Muted :何も通知はされなくなり、最新リストからも表示されなくなります また、質問を投稿し、もらった返答により解決した場合、その返答に Solution マークを付与することができ、今後同じような質問をしたいユーザに対して的確な回答を明示することができます。ぜひ、積極的に Solution マークを付与しましょう! 自分が投稿した質問に対して、的確な返答があった場合は、その返答下にある Solution マークをクリックします。 以下のように Solution マークが変わります。 さらに最初の質問内に、その返答内容が明記され、解決したことが一目で分かるようになります。 “日本語で質問|Q&A” や “Japanese”タグに通知設定する 特定のトピック(質問)だけでなく、カテゴリー自体や特定のタグに対しても通知設定をすることができます。 カテゴリー自体に通知設定をする場合は、 日本語で質問|Q&A に入り、画面右に表示される (通知ベル)アイコンをクリックします。デフォルトは Normal になっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。必要に応じて通知設定を変更します。 Watching :このカテゴリーにトピックス(質問)が新規に投稿されると通知され、そのトピックスに対する返信についても全て通知されます。また、新規の返答があった場合、その数がリスト上に明示されます。 Tracking :名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知され、新規の返答があった場合、その数がリスト上に明示されます。 Watching First Post :トピックス(質問)が新規に投稿されると通知されますが、その返答に対しては通知されません。 Muted :何も通知はされなくなり、最新リストからも表示されなくなります。 Japanese タグに対して通知設定をする場合は、以下の手順で設定できます。 右上にあるプロファイルアイコンの左にあるアイコンをクリックし、 All tags を選択します。 タグの一覧が表示されているので、対象とする Japanese を選択します。 表示された画面の右にある (通知ベル)アイコンをクリックします。デフォルトは Normal になっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。必要に応じて通知設定を変更します。 Watching :このタグにトピックス(質問)が新規に投稿されると通知され、そのトピックスに対する返信についても全て通知されます。また、新規の返答があった場合、その数がリスト上に明示されます Tracking :名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知され、新規の返答があった場合、その数がリスト上に明示されます Watching First Post :トピックス(質問)が新規に投稿されると通知されますが、その返答に対しては通知されません Muted :何も通知はされなくなり、最新リストからも表示されなくなります まとめ このブログでは、Amazon QuickSight Community について紹介し、サインアップの方法、日本語での質疑応答の方法、質問に対する解決設定方法、各種通知設定方法について紹介しました。QuickSight Community は、QuickSight を学習する上で必要な情報を集約しており、さらに日本語で利用することにより、日本での QuickSigh tユーザ間でネットワークを構築できる場となります。今後さらに日本語によるリソースを増強し、日本語 Learning Series についても定期的に開催していく予定です。ぜひ、この QuickSight Community を積極的にご活用ください。 3月:日本語Learning Series 登録ページ
AWS は、プログラミング経験がない方でも生成AIアプリ開発に参加できるハッカソン「PartyRock Hackathon」を 2 月より開始しました。 すでにAWS は 2023 年 11 月に全ての builder が生成 AI をスタートするための”プレイグランド(遊び場)”である「PartyRock」を発表し(*1)、多くのお客様に生成 AI アプリ開発の楽しさを体験していただいています。Amazon Bedrock で動く PartyRock を使うことで、プログラミングの知識の有無にかかわらず、どのようなアプリを作りたいかを文字で入力するだけで、あっという間に生成 AI アプリを構築することができます(*2)。さらにこの開発体験を通じて「プロンプトエンジニアリング」についても自然に身につけることができます。しかも利用は無料。どなたでもお気軽にお試しいただくことができます。 そして今、このPartyRock 上でアプリを開発するハッカソン「 PartyRock Hackathon 」が世界規模で開催されています。すでに 4000 名近い方が参加し、多数のアプリが日々生み出されています。ご興味のある方はぜひ、 PartyRock Hackathon 公式サイト (英語)へお立ち寄りください。 (*1) AWSブログ「Amazon PartyRock の発表」 」 (*2) AWSブログ「PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス」 参考資料) Step by Stepで学ぼう! PartyRockを利用した 生成 AI アプリの作り方
ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 ここでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめていきます。 少し発展的な内容となっておりますので、ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』 をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。 本ブログでは、共同利用方式におけるコスト・セキュリティ管理について扱っていきます。 共同利用方式になったのでコスト・セキュリティについて把握できなくなり困っている自治体の方や、共同利用方式でアプリケーションを提供するベンダーの方にお役立ていただける内容となっています。 共同利用方式の場合にコスト・セキュリティ状態をどのように管理できるか? 共同利用方式では、自治体は AWS アカウントの運用管理を個別に行わない前提となっており、 AWS アカウントのユーザーが払い出されないため、自治体職員はコストなどの情報を確認できません。 共同利用方式を SaaS と捉え、インフラのコスト・セキュリティの管理をパッケージベンダーへ一任するという考え方もあります。 一方で、従来通りインフラのコスト・セキュリティの情報を確認したい自治体の方もいらっしゃると思います。 AWS では、一部のコスト・セキュリティの情報に関しては、専用のダッシュボードを Amazon QuickSight で作成することで、AWSアカウントのユーザーを作成することなく自治体職員の方が確認できます。※ ここでは上記のニーズに対応できるよう、インフラのコスト・セキュリティの情報を Amazon QuickSight で可視化する方法について説明します。 ※ ダッシュボードの項目が多ければ多いほど実装コストも増えるため、ダッシュボードに載せる項目は情報の重要度と実装コストのバランスを取りながら考える必要があります。 コスト ここでは、以下の 2 つのケースについてコストを可視化する方法について説明します。 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 (アカウント分離方式) 1 つの AWS アカウントが複数団体のリソースを含む場合 (ネットワーク分離・アプリケーション分離方式) 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 1 つの AWS アカウントに 1 つの団体のリソースしか含まれないアカウント分離方式の場合、Cost and Usage Dashboard (CUD) , Cost and Usage Dashboards Operations Solution Dashboard (CUDOS) を利用すれば容易にコストに関する情報をダッシュボードに表示できます。 詳しい情報は 簡単に構築できる AWS コスト可視化ダッシュボードのユースケース – Cost and Usage Dashboard (CUD) と CUDOS – をご覧ください。 CUD はセットアップが簡単な分 CUDOS に比べ表示できる情報量が少なく、CUDOS は表示できる情報量が多い分セットアップに AWS CloudFormation 等の利用が必要という特徴があるため、用途に合わせてご選択ください。 以下の URL に CUDOS のダッシュボードのサンプルが公開されています。 CUDOS サンプルダッシュボード: https://cid.workshops.aws.dev/demo?dashboard=cudos 例えば、Compute のタブでは月毎の Amazon EC2 の利用料の推移を確認できます。 図 1) CUDOS の Compute ダッシュボードの例 1 つのAWSアカウントが複数団体のリソースを含む場合 ネットワーク分離・アプリケーション分離の方式を採用する場合や、共用リソースがある場合は費用按分について考える必要があります。 費用按分の戦略 費用按分の方法の考え方の一例として「リソースの Owner が明確なものはコスト配分タグで費用を按分し、タグ付け不可の場合・複数の団体で同じリソースを共用する場合は利用量・団体の人口規模等の指標で按分する」という考え方があります。 ここでは、上記の方法で費用按分を実施する方法の概要について説明します。 なお、ガバメントクラウドにおいて、自治体が利用する AWS アカウントは AWS Organizations のメンバーアカウントにあたるため、コスト配分タグコストタグを有効化できません。 そのため、管理アカウントで既に有効化されているタグを利用してコスト按分を行う必要があります。 既に有効化されているコストタグについては GCAS (Government Cloud Assistant Service) の記載をご参照ください。 タグ付け戦略 団体名のタグ タグ付け可能なリソースは団体ごとにタグ付けを行います。 タグ付け可能なリソース一覧は AWS Resource Groups とタグエディタで使用できるリソースタイプ や リソースタグの API リファレンス をご参照ください。 AWS CloudFormation・AWS CDK 等の IaC ツールを利用している場合、スタック単位でタグ付けが可能なため、簡単にタグ付けを行うことができます。 具体的には Owner=<団体名> といったタグを付けておきます。 タグ付け可能ではあるものの、複数の団体で同じリソースを共用する場合は按分方法ごとにタグを付けていきます。 按分方法ごとのタグ 複数の団体で共有するリソースは按分方法ごとにタグを付けます。 例えば、VPC FlowLog・API Gateway・ELB 等のアクセスログから各団体がどの程度システムを利用しているか計算し、費用按分する方法があります。 「API Gateway のアクセスログから団体ごとの利用料を算出するリソース」は Owner=divideByApi というタグを付けます。 他の按分の方法として、利用団体の人口で按分する方法が考えられます。例えば、更新サーバー (WSUS) などは団体規模が大きいほど更新対象のサーバー台数が多くなります。 その場合、団体規模とシステムの利用比率がおおよそ同じになることが多いため、団体の人口比で利用料を割ることを考えます。 この場合、 Owner=divideByPopulation というタグを付けます。 集計・可視化 ここではタグ付けしたリソースのコストを集計・可視化する方法について説明します。 AWS Data Exports を利用すると請求データを Amazon S3 へエクスポートできます。 Amazon Athena の データベースとテーブルの作成 の手順に従うと、Amazon S3 に配置してあるデータに対し、Athena SQL を利用した処理ができるようになります。 以下の計算を Amazon Athena で行い、新しいテーブルとして保存します。 団体名のタグ ごとにコストを集計 按分方法ごとのタグ で集計したコストをタグの値ごと合計し、按分方法に沿って計算・1 で計算した各団体のコストに加算 タグ付けできないコストはあらかじめ決めておいた按分方法で費用を按分し、2 のコストへ加算 図 2) 特定のタグがついたコストのみ集計して QuickSight で可視化した例 その後、 Amazon Athena データを使用したデータセットの作成 に従って、Amazon QuickSight から Amazon Athena のデータを参照します。 最後は Amazon QuickSight でのデータの視覚化 の手順に従い各自治体向けのダッシュボードを構築します。 Amazon QuickSight はダッシュボード単位で認可の制御ができるため、各自治体のユーザーごとに閲覧可能なダッシュボードの設定ができます。 以下の画像は上記と同様の方法で AWS Deta Exports により出力したデータから、特定のタグがついている料金のみ集計し、ダッシュボードを作成したものです。 セキュリティ ここでは、以下の 2 つのケースについてセキュリティを可視化する方法について説明します。 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 (アカウント分離方式) 1 つの AWS アカウントが複数団体のリソースを含む場合 (ネットワーク分離・アプリケーション分離方式) 例として以下のようなダッシュボードを構築できます。(例は簡素なものとなっておりますが、簡単に表やグラフを追加することができます) 図 3) Security Hub の検出結果を QuickSight で可視化した例 図 4) Trusted Advisor の検出結果を QuickSight で可視化した例 S-1. Security Hub の結果を QuickSight で可視化する方法 (1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合) 以下の手順を踏むことによって、 Security Hub の検出結果を QuickSight で可視化することができます。 1. GitHub 上にある aws-security-hub-findings-export のソリューションを利用して Security Hub の検出結果をリアルタイムに S3 にエクスポートします。 2. Security Hub のエクスポート結果の json ファイルでは、キーに Amazon Athena で処理できない記号が含まれています。詳しくは、 ドキュメント をご参照ください。このため、 AWS Glue で Glue ETL Job をセットしてスキーマを変更する必要があります。具体的には、 DynamicFrame.apply_mapping() メソッドを使用して、フィールドの名前やフィールドタイプを変更しましょう。コードの例は ドキュメント に存在するので、ご参照ください。 3. AWS Glue Data Catalog Table を作成します。クローラーを使ってテーブルを構築し、スキーマを変更した後の S3 上のファイルからデータを読み込む方法が便利です。アカウントや日付でパーティション分割されているため、[Create a single schema for each S3 path (各 S3 パスの単一のスキーマを作成する)][Update all new and existing partitions with metadata from the table (すべての新規および既存のパーティションをテーブルからのメタデータで更新します)]にチェックを入れて単一のスキーマで読み込むことを推奨します。 4. QuickSight の Athena データソースを選択し、Athena ワークグループと Glue カタログ、データベースを指定してデータを読み込みます。 5. QuickSight を利用して、必要なデータを表やグラフで表示します。 S3 のクロスアカウントレプリケーション機能を使って、 S-1. の手順 1 で S3 にエクスポートしたデータをアカウントを跨いでレプリケーションすることもできます。詳しくは ドキュメント をご覧ください。 1 つのAWSアカウントが複数団体のリソースを含む場合 Security Hub の検出結果がリソースに紐づいている場合、Secuirty Hub のエクスポートされた検出結果にはそのリソースにつけられたタグの情報も含まれているため、リソースに対して自治体ごとにタグをつけておけば、その情報を用いて QuickSight 上でフィルタリングすることができます。タグの情報は、Resources フィールドの中の Tags フィールドに含まれています。 タグ付け戦略に関しては、コストの章をご覧ください。 ガバメントクラウド上のTrusted Advisor の検出結果を QuickSight で閲覧する方法 AWS Organizations 上のアカウントの Trusted Advisor の検出結果を QuickSight 上に集約する方法として、一般的には Trusted Advisor の組織ビュー や、 Cloud Intelligence Dashboard の一つである Trusted Advisor Organizational (TAO) Dashboard があります。 しかし、ガバメントクラウド上では、AWS Organizations のマネジメントアカウントにアクセスできないため、これらの方法が使えません。 今回は、以下の条件下で AWS Organizations 配下にある特定のメンバー AWS アカウント上の QuickSight に、Trusted Advisor のデータを集約し可視化を行うことを考えます。 AWS Organizations のマネジメントアカウントにはアクセスできず、さらに、デジタル庁が適用していサービスコントロールポリシーの範囲内の権限しか使ってはいけない。 Organizations 配下にある対象ではないアカウントのデータにアクセスしない。 各メンバーアカウントにはビジネスプラン以上のサポートプランが設定されている。 なお、Trusted Advisor の検出結果はアカウント全体の状態を表すものでありリソースに紐づけられたタグの情報が含まれないため、同じアカウントに異なる自治体のリソースが含まれている場合 (ネットワーク分離方式・アカウント分離方式) もアカウント単位の情報を確認することになります。 以下の手順で、これを実現することができます。 集約元となるアカウント(QuickSight を構築するアカウントを含む)の北部バージニア (us-east-1) リージョンでこちらの yaml ファイル を用いて CloudFormation スタックを作成します。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にして、他は 「no」または未記入にします。 QuickSight を構築するアカウントの、サービスコントロールポリシーで使用が認められているリージョンでこちらの yaml ファイル を用いて CloudFormation スタックを作成します。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にして、他は 「no」または未記入にします。 Accounts-Collector-Function-<スタック名>という名前の Lambda 関数において、AWS Organizations から対象となるアカウント ID やアカウント名を取得している部分を、直接指定するように書き換えます。環境変数に記載してそれを取り込むことをお勧めします。 EventBridge が定期的に発火して、Trusted Advisor のデータを収集します。すぐに発火させたい場合は、Scheduler-For-Accounts という EventBridge ルールを無効化して有効化してみてください。 QuickSight Enterprise Editionを有効にします。 Amazon QuickSight にアクセスして、管理者ユーザーを作成し、ユーザー名とアカウント名をメモします。 集約先となるアカウントのサービスコントロールポリシーで使用が認められているリージョンで、こちらの yaml ファイル を用いて CloudFormation スタックを作成します。上二つの確認事項には「yes」と回答し、先ほどメモしたユーザー名をUser name of QuickSight userに、Trusted Advisor のデータが入っている S3 バケット名を Path to Optimization Data Collection S3 bucket に記入します。Deploy TAO Dashboard を「yes」にして、スタックを作成します。 スタックが作成されると、TAODashboardURL が出力されます。ここにアクセスし、有効な QuickSight ユーザーでログインすると、ダッシュボードを見ることができます。 まとめ 本ブログでは、共同利用のセキュリティ・コスト のダッシュボードについて取り扱っていきました。ダッシュボードの項目が多ければ多いほど実装コストも増えるため、ダッシュボードに載せる項目は情報の重要度と実装コストのバランスを取りながら考える必要があります。 共同利用方式において、自治体の方へどんな情報を提供するか・実装方法はどうしようか迷われていた方の参考になっていれば幸いです。 自治体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 押川令(Ray Oshikawa) パブリックセクターの自治体担当ソリューションアーキテクトです。 最近は自治体関連システムを担当されている企業様のサポートや、自治体業務システムのガバメントクラウドへの移行支援を中心に活動しています。   松本 侑也 (Yuya Matsumoto) パブリックセクターの自治体担当ソリューションアーキテクトです。 最近ではガバメントクラウドへの基幹システムの移行や、生成系AIの活用支援を中心に活動しています。
はじめに このブログ記事では、 CSC Generation Holdings, Inc. (CSC Generation) が、複数のブランドにわたるカスタマーサービス運営をサポートするために、Amazon Connect に移行した理由をお伝えします。CSC Generation は、 One Kings Lane や Sur La Table などの小売業者を高パフォーマンスなデジタルファーストブランドに変革させるマルチブランドの技術プラットフォームです。これらの小売業者の主な顧客は、上質な生活環境の演出に情熱を注ぐ個人、家族です。CSC Generation によるカスタマーサービス運営は、音声、チャット、Eメール、Web チケットを介して、各ブランドにさまざまなレベルのサポートを提供しています。これらのブランドはそれぞれ独自のサポートチャネルとキューを持っていますが、一部はオフィスを共有しています。 小売ブランドをデジタルファーストにするために、CSC Generation は柔軟で、エージェントの効率性と顧客のセルフサービス体験を改善するための組み込み AI 機能を備えたコンタクトセンターソリューションが必要でした。その結果、CSC Generation の開発チームは、独自の AI 駆動型 BPO 向上・生産性ソフトウェアである SnapBPO を構築しました。CSC Generation のチーフテクノロジストである Andrew Templeton との対談を通して、Amazon Connect への移行することで CSC Generation と同社の SnapBPO ソフトウェアが捉えた課題と機会について掘り下げます。 CSC Generation が直面していたカスタマーサービスの課題と、Amazon Connect への移行によってつかんだ活用機会は何でしたか ? CSC Generation の各ブランドと子会社には、インタラクティブ・ボイス・レスポンス (IVR) 構造を含む、顧客との対話を処理するための異なるワークフローがあります。Amazon Connect を使用することで、これらの構成とビジネスルールの全範囲を1つのコンタクトセンターソリューションにエンコードできることを知っていました。これは、ブランド全体で今後の作業をより効率的にする大きな機会でした。SnapBPO ソフトウェアを介して、「私の注文した商品の状況は ? 」といった電話問い合わせの自動化や、リアルタイムでの顧客情報の提供など、顧客向けの高度な新機能とエクスペリエンスを簡単に追加することもできます。 顧客にセルフサービスを提供することが CSC Generation にとって重要ということですね。セルフサービスを貴社業務にどのように組み込んでいますか? CSC Generation のそれぞれのブランドの顧客向け Web サイトでのセルフサービスに加えて、最も一般的なワークフローでは、 IVR で番号プロンプトを表示することなくすべて音声で処理を提供できるようにしています。これにより、お客様は必要な支援について自分の言葉で説明できます。 SnapBPO ソリューションに Amazon Lex を組み合わせることで、最も一般的なお客様からのご質問に完全な文章で回答しています。 結果として、「私の注文した商品の状況は ? 」といった問い合わせの平均対応時間 (AHT) が 1 分未満に短縮されています。 あなたは生成 AI の可能性を実験しています。 顧客へのセルフサービス体験を設計および提供する方法がこのテクノロジーによってどのように変化したかを共有していただけますか ? 顧客の様々な質問表現すべてを知る必要はなくなりました。 生成 AI を使用することで、Amazon Lex で発話のリストを事前に生成できるうえ、顧客からの問い合わせを読み取り理解するために、より強力だが低速に実行される NLP モデルを使用できます。 たとえば、顧客が「私の注文した商品の状況は ? それと、タオルの方は速達にしたか忘れました」という 2 つの異なる質問をした場合、SnapBPO セルフサービスボットは各問い合わせを識別し、「 9 月 3 日のご注文は明日郵送で配達されます。タオルは速達を選択されています。他に何かお手伝いできることはありますか ? 」と応答できます。 さらに、検索拡張生成 (RAG) を使用することで、製品、ビジネス方針、顧客の注文履歴や行動に関するすべての情報をインデックス化しています。 これにより、リアルタイムで顧客との会話に関連するコンテキスト情報を迅速に検索できるようになりました。 生成 AI を活用したセルフサービス体験などのテクノロジーを用いる場合、当然、顧客からの信頼性の問題が生じます。お客様からの信頼を確保するためにどのような対策を講じていますか ? Amazon Lex は私たちの文章の分類、顧客からのフレーズの書き起こしを AWS のセキュリティとプライバシー制御のもと実行しています。 このコンテキストでの生成 AI の利用は、人々の想像よりありふれたユースケースです。私たちは主に「これはどのような文章なのか」や「注文番号は発話された番号の、一つ目なのか二つ目なのか」といった、質問の解釈に関心があります。 このように AI を利用し、注文番号や顧客名などの個人を特定できる情報を置き換えることで、機密情報は共有せず、文の構造のみを共有して最高のモデルを活用しています。 エージェント体験も、CSC Generation のカスタマーサポート戦略にとって重要です。Amazon Connect への移行は、エージェントのオンボーディングと全体的なサービス提供コストにどのような影響を与えましたか ? オンボーディングの観点からは、 AWS Identity Center とのシングルサインオンにより、IT チームにとっての管理が容易になりました。アプリケーションにエージェントをユーザーとして追加するだけで、 Security Assertion Markup Language (SAML) 連携によって同期されます。コールセンターを Amazon Connect エージェントワークスペース に移行するにともない、カスタマーサービスエージェントは統一されたインターフェースだけを覚えればよくなりました。エージェントはシーズンによってさまざまなブランド間を移動することがあるため、このアプローチは労働力の管理を簡素化します。コストの観点からは、エージェント 1 人当たりの通信費は、SnapBPO AI ソフトウェアと Amazon Connect を使用したことで、以前使用していたソリューションと比較して約 80% 低くなっています。 ブランド間での統一されたエージェント体験についてのビジョンの詳細と、これが平均処理時間(AHT)にどのような影響を与えるかを共有いただけますでしょうか ? キューのタイプとワークフローを、特定のブランドのポリシーに沿ってパラメータ化することで統一しました。 Amazon Connect エージェントワークスペースを使用することで、エージェントは、顧客が何のために問い合わせてきたのか、IVR がどのように対応したのか、過去の顧客とのやり取り履歴を確認できます。 このコンテキストにより、エージェントはよりパーソナライズされた形で顧客の質問に答えることができ、エージェントによる対話支援の平均処理時間 (AHT) を短縮できます。 また、エージェントはリアルタイムで内部のナレッジベースにアクセスして顧客の質問に答えたり、 Amazon Connect Tasks を使用してエージェントワークスペースから直接メールを表示、返信したりすることができます。 当社のブランドの1つでは、エージェントワークスペース内で Amazon Connect カスタマープロファイル と ケース を利用し始めました。これにより、お客様からの問い合わせを簡単に追跡および処理できます。エージェントは、注文ステータスの確認、破損商品の報告、価格調整、注文キャンセルと返品、製品に関する一般的な問い合わせなどのサポート要求をより適切に行うために、お客様とその短期または長期にわたる問い合わせの全体像を把握できます。Amazon Connect のこれらの機能を他のブランドでも早速有効化することを楽しみにしています。 CSC Generation における大きなテーマの 1 つは、テクノロジー、エージェント体験、データを統一することのようです。CSC Generation のブランドにまたがって、カスタマーサービスデータやマージン報告を統一することの価値をどのように見ていますか ? CSC Generation の傘下にあるブランドごとのスキーマレジストリとして機能する、内部データ管理プラットフォームにデータを保存し始めました。 例えば、One Kings Lane と Sur La Table はそれぞれ注文スキーマをデータ管理プラットフォームに登録しています。 生成型AIは、同じ論理型 ( 例 : 注文明細 ) の断片化されたスキーマを標準フォーマットに統一するために使用されます。 このデータを統一することで、個々のブランドは CSC Generation の傘下にあるすべてのブランドからの情報に選択的にアクセスできるようになり、チャットボットやエージェントが他のブランドでの購入内容に基づいて顧客にオファーをカスタマイズできるようになります。 さまざまなソースからのデータを統合することで、初期の顧客とのやり取りがより明確な視点で捉えられるようになり、ブランドが顧客基盤と最も親和性のある戦略やタッチポイントを特定できるようになります。これらの洞察は、広告の効果測定、顧客嗜好の理解、 SKU の収益性に関心のあるステークホルダーにとっての包括的な分析に不可欠です。 加えて、データを統合することでコールセンターの運用が大幅に改善されました。この新しいアプローチにより、緊急の問題により効果的に対処し、顧客からの問い合わせに対応し、サービス品質を向上させることができます。最終的に、この新しいアプローチにより、コールセンターがコストセンターであるだけでなく、収益源となる可能性があることが証明されるでしょう。 これらのカスタマーサポートバックエンドの変更は、顧客ロイヤルティと追加販売にどのような影響を与えますか ? 私たちが特に取り上げたい例の 1 つは、家具ブランドの 1 つです。 このブランドでは、優先的なセールスへのアクセス、新製品の早期アクセス、キャッシュバックプランを提供する有料の顧客ロイヤルティプログラムを開始しました。 ロイヤルティプログラムへの加入が見込まれる顧客とカスタマーサービスチームが対話する際、有料プログラムへの加入を二桁台半ばの割合で実現できています。 また、そうした顧客の生涯価値は、同じグループの他の顧客の 2 倍となっています。 今後、CSC Generation とその SnapBPO ソフトウェアは Amazon Connect をどのように利用するつもりですか ? 生成 AI をより多くのユースケースに展開するための計画はどんなものですか ? 生成 AI の可能性にわくわくしています。 Amazon Connect でこのテクノロジーの利用を拡大する予定です。チャットとボイスチャネルのエージェントへのレスポンスを提案するために生成 AI を使用するだけでなく、ビジョンを広げたいと考えています。「生まれた場所は ? 」といった従来のセキュリティ質問から、「 3 日前に購入したものは ? 」といったダイナミックで取引ベースの質問への移行によって、ユーザーを認証することも目指しています。この変更により、各個人のユニークな最近の取引に関連する答えを必要とすることで、顧客体験を高め、セキュリティを強化します。構造化されていないデータを活用することが、顧客をより深く理解する鍵となります。 SnapBPO ソフトウェア、コールセンター、カスタマーサービス運用のためのソリューションをついに見つけられたことを嬉しく思います。これは、ポートフォリオ企業内のさまざまな運用ドメインにおける卓越性と標準化を追求する CSC Generation ミッションを反映するものです。 結論 CSC Generation とその AI ベースの SnapBPOソフトウェアに、Amazon Connect は頻繁なリリースと改善を通して、 AI と自動化を利用してカスタマーサービスを改善するだけでなくコストを削減し成長を促進する機会を提供しています。 セルフサービス体験を統合し、エージェントの効率化を支援するために AI などの組み込み機能を活用することで、 CSC Generation はカスタマーサービスの運用を変革し、より効率的かつ効果的なものにすることができました。 世界中のビジネスがAmazon Connectをどのように利用して、顧客とエージェントのエクスペリエンスを改善しているかをご覧ください。 CSC Generation Holdings, Inc. (CSC Generation) について CSC Generation は、小売業者を取得し、それらを高パフォーマンスのデジタルファーストの消費者中心のビジネスに変革するマルチブランド技術プラットフォーム企業です。CSC Generation は、強力なマーケティングインテリジェンス、サプライチェーンおよび流通チャネル、優れたカスタマーサポート、そして実店舗およびオンラインとカタログ販売の経験により、小売業界の他社と一線を画しています。 Andrew Templeton Andrew Templeton は、構築、フリートロジスティクス、eコマースなどのさまざまな業界における革新的な AI 駆動の自動化プロジェクトの設計と実行を専門とする、P/L 経験を持つシーズンされた技術リーダーです。顧客サービスの自動化と品質問題の検出のイニシアチブを特に率いており、TypeScript でのソースコードリファクタリングのための高度なエンジンを開発するとともに、動的にスケーリングするデータ統合プラットフォームの確立にも貢献しています。技術的知見は広範囲に及び、TypeScript、Python、Ruby や React、Vue といったクライアントサイドフレームワークに加え、Amazon Web Services の上級認定も保有しています。 Chris Phan AWS テクノロジーを専門とするテクニカルアカウントマネージャーとして、クリスはテクノロジーとフロントエンド開発への情熱で、技術的な専門知識とクライアントサポートのダイナミックなブレンドを提供しています。クラウドベースのウェブソリューションの常に進化する領域において一人一人へのガイダンスと継続的な学びを通じて、顧客がユニークな課題に対処し戦略的な成功を達成するのを支援することに専念しています。   翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。
本投稿は小田急アプリや他社サービスなどに連携する列車遅延予測機能の追加とその精度向上の取り組みについて、実際に開発と構築をされました小田急電鉄株式会社経営戦略部の落合様に寄稿いただいたものです。 はじめに 鉄道各社ではより便利に鉄道をご利用いただくため、列車の走行位置や、個々の列車の遅れの情報を各社のアプリ等を通じてリアルタイムに配信しています。弊社も2017年に小田急アプリをリリースし現在に至るまで、多くのお客さまにご利用いただいております。リリース当初は「現在の遅れ」をご案内する機能しかありませんでしたが、2022年より遅延予測機能を追加し、「現在の遅れ」に加え、「各駅の到着見込み・発車見込み時刻」をご案内しています(図1)。加えて、昨今では様々な経路検索サービスにおいても、各列車の遅れに関する情報を表示して頂けるようになるなど、鉄道のリアルタイム情報を広くご利用いただけるようになってきました。 本ブログでは、AWS サーバーレスサービスと機械学習サービスを活用した、小田急アプリにおける、列車遅延予測システムと、予測精度向上に関する取り組みについてご紹介いたします。 列車の遅延 欧州のように大規模な鉄道ネットワークで発生する遅延と比較すると、日本の鉄道で発生する遅延は小規模であることが多いものの、様々な事由により、日々大小さまざまな遅延が発生しています。このため、必要により列車を運転する順序を変更したり、運転する区間を変更したりするなど、各列車の遅延が少なくなるよう運転整理を行っているものの、2本のレールの上に、たくさんの列車が次々と走行しているため、ときに道路と同じように渋滞が発生してしまうこともあります(図2)。このため、“今時点”では定刻通り運転していても、先を走行している列車に遅れが発生していると、その影響を受けて、のちに遅れが発生するという現象もしばしば発生してしまいます。 そこで、現在の遅れをご案内することはもちろんのこと、その遅延がこの先減少していくのか、あるいは拡大してしまうかを精度高く予測しご案内をすることで、ご利用のお客さまのご不便の度合いを少しでも解消したいと考えています。 AWS Lambda とAmazon S3 で構成した列車の遅延予測の仕組み 図3に現状の小田急アプリ・列車遅延予測機能の構成図をお示しいたします。当社社内のネットワークから閉域網により Amazon VPC と接続し、AWS PrivateLink を通じて、Amazon S3 のバケットに最新の列車の走行位置と、この先の列車の運転順序に関する情報をほぼリアルタイムに連携しています。これらのデータを AWS Lambda で加工し、Amazon Aurora に格納し、小田急アプリ向けに配信しています。 遅延予測関連のシステムについては、構築当初から連携する経路検索各社様へのデータ配信も視野に入れ、小田急アプリの配信基盤と別に、当社の MaaS プラットホームである MaaS Japan 上に構築しています。 遅延予測の機能は、AWS Lambda と Amazon S3 を使用するのみの非常にシンプルな構成で、列車の在線位置から「いつ、どこに、どの列車がいたか」という情報を取得し、時系列を整えた在線履歴データを Amazon S3 に出力する関数と、在線履歴データと列車の運転順序に関する情報から、15秒に1回、この先の列車の運行をシミュレーション予測し、同じく予測結果を Amazon S3 出力する関数の2つからなります。 用いた予測アルゴリズムもシンプルです。各列車の運行を各駅への到着、発車、通過という事象ごとにノードとして表現します。続いて各ノード間に必要な最低限の時間(駅間の走行に必要な時間・駅に停車している時間・列車と列車の間隔に必要な時間)を重みとした有向アークで結び、グラフネットワークを構成します(図4)。このグラフネットワークの各ノードの重みの和が最大の値(すなわちすべての制約を満たす最短の時刻)を最長径路探索により求めることで、予測時刻とするというものです[ 参考文献 ]。 従来の課題 – さらなる精度の向上に向けて 「現在の遅れ」のみご案内していた、遅延予測機能導入以前と比較すると、よりきめ細やかなご案内ができるようになったものの、課題がありました。それは、「駅に停車している時間」が毎日同じ時刻に発車する同じ列車でも、実は日々まちまちであるという点です。 自明ながら、駅に停車している時間が(計画よりも)長ければ、その先の遅延が拡大しますし、駅に停車している時間が(計画よりも)短ければ、この先回復できる見込みが生まれます。 図5は実際のばらつきを散布図に示したものです。横軸に当社の湘南台駅到着時の遅れを、縦軸は4駅先(所要時間約10分)の藤沢駅到着時の遅れの大きさを示しており、双方の関係性をプロットしています。例えば湘南台駅に30秒の遅れで到着した列車に着目すると、藤沢駅の遅れが -15秒(すなわち少々早着)~ 120秒の間まで存在することがご覧いただけます。 各システムでご案内できる見込み時刻は1つであることから、現状では「発車見込み時刻をご確認いただいた際、乗り遅れてしまわないこと」を優先し、遅延予測をする際には若干短めの数値を採用してきました。このため、今度はご乗車しているお客さまから、「実際はもっと遅れるのに、いつも回復する見込みの案内が出ていて不便」というご意見を頂いてしまうこともありました。 そこで、2023年度、新たな仕組みを導入することとしました。 機械学習を用いた停車時分予測モデルの導入 遅延予測精度の向上を図るため、過去の運行実績を学習データとして、リアルタイムに各駅の停車時間を予測できる、相関ルールをベースとした機械学習モデルの導入を検討しました。具体的には、連続する数駅分の停車に要した時間のみの情報から、その先各駅の停車に必要な時間を確率的に予測するというモデルです。 実施に当たっては、図3に示した通り、AWS で用意されている分析機能と、機械学習実施環境の基礎的な機能を用いて、以下の手順で実施しています。 Amazon S3に蓄積した運行実績を、Amazon Athena を使って整形し、訓練用のデータセットを抽出 Amazon SageMaker に用意されている Notebook 内で、訓練用データから Apriori アルゴリズム[ 参考文献 ]を用いて相関ルールを抽出したのち、予測に有用なルール Map ( JSON ファイル)を作成 リアルタイム情報と、出来上がったルール Map を用いて、駅での停車に必要な時間を予測、結果を Amazon S3 に出力する機能を AWS Lambda にて実施 予測した停車時間を加味して運行予測シミュレーションを実施 この機械学習モデルの導入を検証したところ、予測精度の向上を実現することができる見込みが立った(図6)ため、現在は一部の列車・区間で運用しています。 今後、適用範囲を拡大するとともに、AWSの各種機能を活用し、一定期間経過後に自動的に再学習し、モデルを最新の状態で予測できるよう、MLOpsの仕組みを整備していきたいと考えています。併せて、今回は相関ルールをベースとしていますが、XGBoostやニューラルネットワークといった他の手法の適用も試み、さらなる精度の向上を図れないか検討してまいります。 まとめ 本ブログ記事では、小田急電鉄における列車の遅延予測とその精度向上の取り組みについて、AWS Lambda と Amazon S3 というシンプルな組み合わせで、容易に遅延予測の仕組みを構築できたこと、ならびに、Amazon Athena 、Amazon SageMaker といったサービスを用いることで、容易に機械学習モデルを構築し、適用できることをご紹介いたしました。このように AWS のサーバーレスと機械学習サービスを活用することで容易に機械学習を用いた機能の追加ができることは AWS クラウドを利用する大きな利点だと感じました。 デジタル技術を活用し、鉄道をより便利にご利用いただくために取り組むべき課題はまだまだたくさんありますが、 AWS のみなさまにもサポートいただきながら、一つ一つ真摯に取り組んでまいりますので、これからも弊社をご愛顧いただけますと幸いです。 著者略歴 小田急電鉄株式会社 経営戦略部 落合 康文 2002年入社、駅・車掌・運転士を経験後、2012年より輸送計画業務を担当。2019年より現職に従事。小田急アプリや鉄道に関連するデータ分析業務などを担当。2021年日本大学にて博士(工学)修得