編集者注：このブログは、ビルダーが独自のソリューションを作成するためのデモンストレーションと基礎を提供するために設計されたスターター・プロジェクトの例です。本番環境で使用できるものではありません。本番環境にデプロイして使用することを計画している場合は、 本番環境での使用 を参照してください。このソリューションをさらに進めるために追加のサポートが必要な場合は、 AWS プロフェッショナルサービス または Amazon Connect パートナー にお問い合わせください。 AWS Contact Center Day にご参加ください。この無料のバーチャルイベントでは、カスタマーサービスの未来や、機械学習による顧客とエージェントの体験の最適化などについて学ぶことができます。 今すぐ登録 >> ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 企業は顧客の期待に応えるため、よりパーソナライズされた体験を提供しようと努力しています。今日、消費者は友人や家族とのコミュニケーションにさまざまなリッチなデジタルメッセージングアプリケーションから選ぶことができ、WhatsApp は世界的に最もよく利用されているアプリケーションの一つです。消費者は、利便性と柔軟性を求めて、自分の好きなデジタルチャネルでコミュニケーションできる選択肢をますます求めています。どのような規模の組織であっても、変化し続ける顧客のコミュニケーションの好みに応えるためには、デジタルコミュニケーション戦略においてこの点を考慮することが重要です。 Amazon Connect のメッセージストリーミング API を使用すると、デジタルチャネルを Amazon Connect コンタクトセンターに簡単に統合できます。追加のチャネルを統合することで、顧客が好むデジタルチャネルで、パーソナライズされたリアルタイムのサポートを提供することができます。 このブログでは WhatsApp を Amazon Connect コンタクトセンターに統合する方法をご紹介します。ここで説明する手順とアーキテクチャは他のデジタルチャネルとの統合にも応用できます。本記事の手順に従って WhatsApp をセットアップすると、エージェントはすでに Amazon Connect の音声、チャット、タスクで使用しているエージェントデスクトップから、WhatsApp チャネルの顧客メッセージを受信し、返信することができます。 ソリューション概要とアーキテクチャ このブログ記事では、 GitHub リポジトリ からサンプルプロジェクトをデプロイします。このプロジェクトには WhatsApp メッセンジャーチャネルをサポートするエンドツーエンドのインフラストラクチャが含まれています。 これらの API を使用して Amazon Connect Chat と SMS を統合する方法については、 Amazon Connect を使用した SMS 上でのパーソナライズされた顧客体験の構築 のブログをご覧ください。 図1 : ソリューション・アーキテクチャ 顧客はデジタルメッセージングチャネルから Amazon API Gateway にホストされている Webhook にメッセージを送信します。 API Gateway は AWS Lambda にメッセージを送信します。 AWS Lambda はチャットのコンタクトコンテキストを Amazon DynamoDB に書き込みます。 これがコンタクトの最初のメッセージである場合、AWS Lambda は、StartChatContact、StartContactStreaming、CreateParticipantConnection の順序で API を呼び出します。チャットがすでに存在している場合、AWS Lambda はAmazon Connect にメッセージを送信します。 Amazon Connect はエージェントまたはシステムのメッセージを Amazon SNS にストリーミングします。 Amazon SNS が AWS Lambda を呼び出します。 AWS Lambda が Amazon DynamoDB にチャットのコンタクトコンテキストを問い合わせます。 AWS Lambda は返信メッセージを送信元チャネルから API を通じて顧客に配信します。 前提条件 このチュートリアルでは、以下のリソースを理解し、アクセスできることを前提としています： 次のサービスに対して管理者権限を持つ AWS アカウント – Amazon Connect、Amazon API Gateway、AWS Lambda、Amazon DynamoDB、Amazon Simple Notification Service、AWS Secrets Manager、AWS CloudFormation Amazon Connect インスタンス Amazon Connect のコンタクトフローのセットアップ（切断フローを含む） ローカル環境での AWS CLI のセットアップ Meta (Facebook) の開発者アカウント。詳細は Meta for Developers コンソール をご覧ください。 NPM を使って開発者マシンへの Node.js のインストール。詳細は nodejs downloads をご覧ください。 デプロイのチュートリアル Meta for Developers コンソール Meta for Developers コンソール に移動します。 マイアプリ をクリックします。 アプリを作成 をクリックします（または既存アプリを選択します）。アプリに必要な機能については、 その他 を選択し、 次へ をクリックします。 アプリタイプを選択します。ここでは WhatsApp をサポートする ビジネス を選択します。 次へ をクリックします。 アプリの表示名 、 連絡先メールアドレス 、 ビジネスアカウント を紐づけるかどうかを選択し、 アプリを作成 をクリックします。 ダッシュボード に移動し、 アプリに製品を追加 セクションで WhatsApp サービスの 設定 を選択します。 Meta ビジネスアカウントを 作成 または選択し、 次へ を選択します。 アプリの設定 > ベーシック に移動し、 app secret の 表示 をクリックします。表示された値は Amazon Secrets Manager で WA_APP_SECRET というキーにシークレットを作成する際に必要となるため、保存して下さい。 WhatsApp > API設定 に移動し、 電話番号ID をメモします。このIDは後ほど AWS Secrets Manager でシークレット ( WA_PHONE_NUMBER_ID ) として必要になります。 また、 テスト番号 もメモします。ソリューションがデプロイされたら、この番号に、テスト用の電話からメッセージを送信する必要があります。これは Amazon Connect デプロイメント用のビジネス電話番号です。 また、 受信者の電話番号を選択 のドロップダウンに、テストに使用するお客様の電話番号を追加して下さい。指示に従って電話番号の追加と認証を行って下さい。注意： この電話番号で WhatsApp を登録し、クライアント端末に WhatsApp クライアントがインストールされている必要があります。検証メッセージは WhatsApp クライアントのアーカイブリストに表示され、メインのメッセージリストには表示されません。 API 経由で WhatsApp にアクセスする新規ユーザーを作成 Meta の ビジネスマネージャ を開き、あなたが作成した、またはアプリを関連づけたビジネスアカウントを選択し、ビジネス設定(歯車アイコン)をクリックします。 ユーザー の下にある システムユーザー をクリックします。 追加 をクリックし、新規システムユーザーを作成します。 システムユーザーに名前を付け、役割を 管理者 に設定し、 システムユーザーを作成 をクリックします。 アセットを割り当てる ボタンで新規ユーザーを WhatsApp アプリに関連付けます。 アセットタイプの選択 リストから アプリ を選択し、 アセットの選択 であなたが作成した WhatsApp アプリ名を選択します。部分的なアクセス許可にて アプリをテスト を有効にし、 変更を保存 をクリックして 完了 をクリックします。 新しいトークンを生成ボタン をクリックし、作成した WhatsApp アプリを選択します。 利用可能なアクセス許可 リストから whatsapp_business_messaging と whatsapp_business_management を選択し、一番下の トークンを生成 をクリックします。 アクセストークンをコピーして保存します。このアクセストークンは、次のセクションでシークレット WA_ACCESS_TOKEN として使用します。 OK をクリックする前に、トークンをコピーしたことを確認してください。 アクセストークン作成の詳細については、Meta for Developers コンソールの WhatsApp > 設定 や 固定トークンの作成方法 をご覧ください。 AWS Secrets Manager のセットアップ AWS Secret Manager のコンソール に移動し、 新しいシークレットを保存する をクリックし、 その他のシークレットのタイプ を選択します。Facebook Messengerとの統合を使用している場合、シークレットは両方のソリューションで共有できますが、シークレット内のキーは各ソリューションで個別に作成する必要があります。 下記の キー/値のペア のところに、 WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET 、 WA_VERIFY_TOKEN を追加します。 WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET には、前のステップで取得した値を指定します。WA_VERIFY_TOKEN には任意のランダム文字列 (自身で作成したもの) を指定できます。これは後のステップで、WhatsApp webhook に追加されます。 デフォルトの暗号化キー( aws/secretsmanager )を選択します。次 をクリックします。 注: 新しいキーを追加することも可能ですが、その際はCDKプロジェクトを変更し、暗号化キーへのアクセス許可を与えてください。 シークレットの名前 と 説明 を入力し、 次 をクリックします。 注: リソース権限やその他の設定を追加する場合は、CDKスタックリソースにこのシークレットへの権限が与えられていることを確認してください。 次 をクリックし、シークレットを 保存 します。 注: 必要に応じて自動ローテーションの設定を行うことができますが、このチュートリアルではデフォルト値のままとします。 AWS Secret Manager のコンソール で、作成したシークレットを検索し、 シークレット ARN をメモしてください。これは後ほど、CDKでデプロイする際に必要になります。 Amazon Connect インスタンスの詳細を取得 AWS マネジメントコンソールの Amazon Connect に移動します。 Amazon Connect インスタンスを選択し、 インスタンスARN をメモします。 Amazon Connect 管理コンソール にログインし、 コンタクトフロー の画面を開きます。WhatsAppチャネルでチャットを開始させたい コンタクトフロー を選択し、その コンタクトフローID をメモします。 AWS CDK と Bootstrap CDK 環境をインストール（CDK をインストール済みの場合はスキップ） npm -g install typescriptnpm -g install aws-cdk cdk bootstrap aws://ACCOUNT_ID/AWS_REGION プロジェクトのデプロイ 続行する前に、前のステップで以下の変数があることを確認してください。 Amazon Connect インスタンス ARN Amazon Connect コンタクトフロー ID WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET 、 WA_VERIFY_TOKEN の値を格納する、AWS Secret Manager のシークレット ARN Git を使って、GitHub からリポジトリをクローンします。 git clone git@github.com:amazon-connect/amazon-connect-message-streaming-examples.git ターミナルでディレクトリのルートに移動します。 cd amazon-connect-message-streaming-examples CDK プロジェクトと AWS Lambda 関数の依存関係をインストールします。 npm install cd src/lambda/inboundMessageHandler npm install cd ../../.. cd src/lambda/outboundMessageHandler npm install cd ../../.. cd src/lambda/digitalChannelHealthCheck npm install cd ../../.. AWS CLI プロファイルを使用して CDK プロジェクトをデプロイします。cdk スタックに必要なコンテキスト環境変数として、 amazonConnectArn 、 contactFlowId 、 waSecretArn を指定します。 cdk deploy \ --context waSecretArn=<YOUR SECRET ARN> \ --context amazonConnectArn=<YOUR AMAZON CONNECT INSTANCE ARN> \ --context contactFlowId=<YOUR CONTACT FLOW ID 注: WhatsApp、SMS、Facebook Messenger チャネルは全て同じ CDK プロジェクトの一部です。SMS または Facebook チャネルをデプロイしたい場合には、追加のコンテキストパラメータが必要です。SMS の場合は pinpointAppId と smsNumber (携帯電話番号)、Facebook の場合は fbSecretArn が必要です。詳細は SMS ブログ と Facebook ブログ をご参照ください。 CDK のデプロイが完了したら、CDK の出力から WhatsAppApiGatewayWebhook を確認します。 Meta コンソール ターミナルの CDK 出力にて、API Gateway の呼び出し URL WhatsAppApiGatewayWebhook を確認します。 Meta for Developers コンソール に戻ります。 WhatsApp > 設定  を選択し、Webhook 設定ページにアクセスします。 Webhook の下にある 編集 をクリックします。 コールバック URL には、 API ゲートウェイ呼び出し URL を指定します。 トークンを検証 には、 AWS Secrets Manager のセットアップの手順で作成したランダム文字列を指定します。 確認して保存 をクリックします。 Webhook フィールドセクションの 管理 をクリックします。 messages の行の サブスクリプション登録 をクリックします。 完了をクリックします。 おめでとうございます！Amazon Connect インスタンスにデジタルチャネルとして WhatsApp が追加されました。WhatsApp ビジネス テスト番号 を WhatsApp アカウントの連絡先に追加し、その連絡先にメッセージを送信すると、Amazon Connect インスタンスに接続されます！ クリーンアップ Whatsapp アプリを削除します。 Meta for Developers コンソール に移動し、 マイアプリ を選択し、 アプリの削除 を選択してWhatsapp アプリを削除します。 Meta 開発者アカウントを削除します。 AWS Secret Manager のコンソールに移動し、シークレットを削除します。 CDK スタックを破棄します。 cdk destroy \ --context waSecretArn=<YOUR SECRET ARN> \ --context amazonConnectArn=<YOUR AMAZON CONNECT INSTANCE ARN> \ --context contactFlowId=<YOUR CONTACT FLOW ID> まとめ 本ブログでは、 Amazon Connect Chat メッセージストリーミング API と WhatsApp を例に、Amazon Connect のデジタルチャネルを構築する方法をご紹介しました。本ブログのステップに従って WhatsApp インテグレーションを実装することで、エージェントは Amazon Connect の音声、チャット、タスクに使用しているエージェントデスクトップから、WhatsApp 上の顧客メッセージの受信と返信を開始することができます。 始めるには GitHub リポジトリ にアクセスし、プロジェクトをデプロイしてください！ 注: これは実験用に簡単にデプロイできるように設計されたサンプルプロジェクトです。IAM ポリシーは最小権限を使用していますが、デプロイされた AWS API Gateway はパブリックにアクセスできます。次の公式ドキュメント Amazon API Gatewayでのセキュリティ に従い、 AWS API Gateway のセキュリティ を確保するために適切な処置を行ってください。 著者情報 Abhishek Pandey は Amazon Web Services のシニアソリューションアーキテクトです。16 年以上のエンタープライズ IT の経験を持つ Abhishek は、さまざまな業界のビジネスイノベーションをサポートする創造的なソリューションを設計するために、顧客と深く掘り下げることに情熱を注いでいます。Abhishek は、情熱、熱意、顧客支持、好奇心、創造性の秘密のブレンドを使用して、AWS クラウドの価値を解き放つためにビルダーを鼓舞します。 — Attila は Amazon Web Services Professional Services グループの Amazon Connect コンサルタントです。コンタクトセンターの経験に加え、ソフトウェア開発とエンタープライズネットワーキングの経験があります。Attila は、顧客メリットを提供するために製品機能を強化する革新的な方法を常に模索しています。 — AWS Contact Center Day にご参加ください。この無料のバーチャルイベントでは、カスタマーサービスの未来や、機械学習 による顧客とエージェントの体験の最適化などについて学ぶことができます。 今すぐ登録 >> ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 翻訳はソリューションアーキテクトの濱上が担当しました。原文は こちら です。

はじめに AWS IoT Core は AWS IoT Core フリートプロビジョニング におけるセルフマネージドのクライアント証明書の署名方法の一般提供を開始しました。新しいセルフマネージドの証明書署名機能により、 フリートプロビジョニング 時に、外部の認証局 (CA) 、独自の公開鍵基盤 (PKI) 、もしくは AWS Private CA などの一般的な CA サービスを利用して、証明書署名要求 (CSR) に署名を行うことができます。この統合により、フリートプロビジョニングを行う際に X.509 クライアント証明書の属性をカスタマイズすることが可能となり、セキュリティが重視されるシナリオでは特に有効です。このブログでは、AWS マネジメントコンソールと AWS CLI を使用してどのようにセルフマネージドのクライアント証明書の署名を行うことができるか解説します。 フリートプロビジョニングでのセルフマネージドの証明書署名機能の利点 クライアント証明書のカスタマイズの合理化: セルフマネージドのクライアント証明書署名機能により、フリートプロビジョニングにおいて任意の CA で直接クライアント証明書の署名を行うことができます。そのため、カスタムのソリューションを設定する必要がなく、導入にかかる時間を節約し、メンテナンスコストを削減することができます。 セキュリティと柔軟性の強化: お客様のプライベート CA や他のパブリックに信頼されている CA を用いることでお客様のセキュリティ要件に柔軟に対応できるようになります。有効期間、署名アルゴリズム、発行者、エクステンションを選択することができるため、よりフレキシブルに証明書の管理を行うことができます。 ファームウェアのアップデートは不要: 新しいセルフマネージドの証明書の署名を使用するためにファームウエアのアップデートは不要です。AWS マネジメントコンソール、もしくは AWS CLI 上からセルフマネージドのクライアント証明書署名方式を有効にすると、フリートプロビジョニングの CreateCertificateFromCsr MQTT API の証明書の署名の動作が更新されます。一方、AWS 管理のクライアント証明書署名方式を使用する場合、AWS IoT Core は自身の CA にてCSR に署名を行います。 AWS IoT Core フリートプロビジョニングの概要 AWS IoT Core のフリートプロビジョニング機能を使用すると、クライアントが AWS IoT Core に初めて接続するときに、クライアント証明書と秘密鍵を生成し、安全な形で配信することできます。特筆すべき点として、AWS IoT Core によって発行されたクライアント証明書だけでなく、CA 認証局によって署名されたクライアント証明書も利用することができます。この機能により、デバイスのセットアッププロセスが効率化され、カスタマイズの選択肢が増えます。 プロビジョニングには以下の2つの方法があります: クレームによるプロビジョニング 信頼できるユーザーによるプロビジョニング クレームによるプロビジョニング 製造時に、プロビジョニングだけを行う事が可能な、権限が制限されたプロビジョニングクレーム証明書と秘密鍵をデバイスに書き込んでおき、この証明書を AWS IoT Core に登録しておきます。これにより、サービス開始時にデバイスが通常のオペレーションで使用するためのクライアント証明書と交換することができます。 信頼できるユーザによるプロビジョニング 多くの場合、信頼されたユーザーによるプロビジョニングでは、エンドユーザーや管理者のような信頼されたユーザーが、モバイルアプリを使用して、デプロイされた場所でデバイスを設定するときに、デバイスが初めて AWS IoT Core に接続します。信頼されたユーザーによるプロビジョニングは、スマートホームデバイスなどの様に、デバイスをコンパニオンアプリで設定する必要がある場合によく使用されます。 この機能を有効にするワークフロー 前提条件 ご自身のAWS アカウントにて certificate provider を作成するための権限が付与されていること Lambda 関数を作成、追加する権限が付与されていること PLambda 関数の変数を追加、更新する権限が付与されていること Tセルフマネージドのクライアント証明書の署名を有効にするためには以下のステップが必要です 証明書に署名を行う AWS Lambda 関数を作成し、関数を実行するために AWS IoT の権限を付与します。 セルフマネージドの証明書署名方法に切り替えます。それにより、アカウントレベルで AWS IoT certificate provider のリソースが作成され、certificate provider がAWS Lambda 関数の Amazon Resource Name (ARN) を使用します。 AWS IoT Core の certificate provider が作成されると以降は、そのアカウントでの証明書署名要求 (CSR) に署名を行うために呼び出させる fleet provisioning CreateCertificateFromCsr MQTT API は AWS Lambda 関数を使用するようになります。AWS IoT Core 自身のもつ CA でクライアント証明書が署名されるように戻すために、Amazon 管理の CA に切り替えることも可能で、その場合には certificate provider はアカウントから消去されます。 ソリューションの概要 AWS IoT Core フリートプロビジョニングでのセルフマネージドクライアント証明書署名のソリューションの概要を、アーキテクチャ図とともに、順を追って見ていきましょう。 以下のステップは、ユーザーがセルフマネージドクライアント証明書署名を作成し、切り替えを行った際の CreateCertificateFromCsr の動作を示します: デバイスが CreateCertificateFromCsr をリクエストする。 AWS IoT Core certificate provider が存在しないので、AWS IoT Core は自身の CA にて CSR に署名を行い、クライアント証明書を発行する。 ユーザーがクライアント証明書作成方法をセルフマネージドに切り替える。これにより、 certificate provider が作成される。 デバイスが CreateCertificateFromCsr をリクエストする。 AWS IoT Core はクライアント証明書に署名を行うために certificate provider の AWS Lambda 関数を呼び出す。 ユーザーがクライアント証明書作成方法を AWS マネージドに切り替える。これにより、certificate provider が削除され、AWS マネージドクライアント証明書署名方式に移行する。 デバイスが CreateCertificateFromCsr をリクエストする。 クライアント証明書セルフサインメソッドが存在しないので、AWS IoT Core が CSR を署名する。 Figure 1.0: AWS IoT Core フリートプロビジョニングソリューションアーキテクチャ概要図 実装の手順 プライベート CA の作成 このブログではクライアント証明書のセルフ署名方式として AWS プライベート CA を証明書の署名に使用します。プライベート CA をどのように作成するかを示す手順については プライベート CA の作成 をご参照ください。作成した CA の ARN を保存しておいてください。 AWS Lambda 関数の作成 セルフマネージドクライアント証明書作成方法に切り替える前に、CSR に署名を行うための AWS Lambda 関数を作成する必要があります。以下の関数は、プライベート CA と SHA256WITHRSA の署名アルゴリズムを使用して、入力された CSR に署名を行うため、AWS プライベート CA を呼び出します。戻されたクライアント証明書は1年間有効です。(要望に応じて有効期限を変更することも可能です。サンプルコードは365日の有効期限を設定しています。) Step 1: AWS Lambda コンソールから: 関数の作成を選択 一から作成」を選択 関数名を入力し、最新の Python のランタイムを選択、残りの項目はデフォルトのままにします。 「関数の作成」を選択 関数が作成されたら Step2 へ。 Step 2: 関数を選択して、以下のサンプルコードをエディターにコピーします。 import os import time import uuid import boto3 def lambda_handler(event, context): ca_arn = os.environ['CA_ARN'] csr = (event['certificateSigningRequest']).encode('utf-8') acmpca = boto3.client('acm-pca') cert_arn = acmpca.issue_certificate( CertificateAuthorityArn=ca_arn, Csr=csr, Validity={"Type": "DAYS", "Value": 365}, SigningAlgorithm='SHA256WITHRSA', IdempotencyToken=str(uuid.uuid4()) )['CertificateArn'] # Wait for certificate to be issued time.sleep(1) cert_pem = acmpca.get_certificate( CertificateAuthorityArn=ca_arn, CertificateArn=cert_arn )['Certificate'] return { 'certificatePem': cert_pem } このコードは作成したプライベート CA の ARN を参照するので、ARN を関数の設定に登録することが必要です。関数の設定タブに移動し、左側のメニューバーから環境変数を選択します。CA_ARN をキーとして、作成したプライベート CAの ARN の値を値として登録します。 関数を実行するために AWS IoT のパーミッションを取得する AWS Lambda 関数を作成した後、関数を実行するために AWS IoT のパーミッションを取得します。 Step 1: Lambda 関数を選択 設定のタブを開く アクセス権限を選択 リソースベースのポリシーステートメントの箇所から 「アクセス権限を追加」を選択 「 AWS のサービス」を選択 サービスのドロップダウンメニューから「AWS IoT」を選択 ステートメントIDに一意なステートメントIDを入力 「ソース ARN」に certificate provider の ARN をペースト (以下のリージョン、アカウント ID 、certificate provider の名前を置き換えてください) “arn:aws:iot:REGION:ACCOUNT_ID:certificateprovider:CERTIFICATE_PROVIDER_NAME” 作成した AWS Lambda 関数をテスト 新しく作成した AWS Lambda 関数を選択し、「テスト」のタブにてテストイベントを作成することで、作成した AWS Lambda 関数をテストすることができます。テストイベントに以下のサンプル JSON データを挿入します。 { "certificateSigningRequest": "-----BEGIN CERTIFICATE REQUEST-----\nMIICaTCCAVECAQAwJDEiMCAGA1UEAwwZQm9zdG9uQ2VydGlmaWNhdGVQcm92aWRl\ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALAlk4aEcoheqUPFOj17\ne8Qs9fhLXkNLhtmx/ePE6A0Tb6dFwWt+jwspITE96heBBQrMVCwVkI2C5tbtpx3a\n8+c5qlSZBGX7w9Tlz1Ik30rJQTeB/X7CIU068ld4b+xBNxQLJQw0eSmWCC8p+CD/\nkdxC8rGCkSia/Cd7Hp9pTdBL8nU1t+QDppv+c4dtYrRVDjPmRcwpv4dyvH5/R6aZ\nxJToKPlt3P6cpa5KEhWZvjVt7XvpbU4GMhP+ZeQL1bLFWZAJ+tAiz6qG5xr4X/2V\nWjmSQWsDnbSzWjdRtXJZZGucIR6Gif95G2E08/VJlRtBi3d3OnhdYbYBiNW4X5ck\nsqkCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQCTqiW6qZ1nLW1pNt35wFVTpvzR\nUUkAdNLugmdNZIhqi4VWi0YXfhTPszOdnTcDAaoBTvSvmqCZHfPnRnt65XsMcNQO\nY+M5f/b1n5t0kKbzdFLu+GlK2eB+J8VtQqfAKw3q5a6Q0nu+OUOhm2PepdMkRoxw\n9tUDLTHiG/8zySxUo552hNlBz0wDVb1hjrEgLDi56mQ7FJKICzpkQAq5pMcJQj6t\nozWYrxzszGDa+ZFQ7H4DY/xl4acf1rownncF7mqQgVcAjTXchJ/ETIghJAO8qU1+\nz7ASTlm8Ym8Qov9YiISzss9i2z/78tVksvL3idZ5L0W2m6pnkVuQe3wknBYw\n-----END CERTIFICATE REQUEST-----", "clientId": "221a6d10-9c7f-42f1-9153-e52e6fc869c1", "principalId": "f2a33ae79323012c5f5b4250de3952568f1d81b2aa5bad1301b23b0991ba0ef4" } データを挿入後、保存し、テストを実行します。 AWS IoT のコンソール上でセルフマネージド型のクライアント証明書署名方式を有効にする AWS IoT のコンソール上から（以下のスクリーンショットをご参照ください） 「セキュリティ」を選択 「Certificate signing」を選択 「Edit signing method」を選択 Figure 1.1: フリートプロビジョニングでのセルフマネージド証明書署名 「Self-managed」を選択 証明書プロバイダーの設定で 証明書プロバイダー名に一意の名前を入力 AWS Lambda 関数について、先ほど作成した Lambda 関数を選択 証明書プロバイダーを作成」を選択 Figure 1.2: セルフ署名による署名書の署名を有効にする 「確認」と入力し、「確認」をクリックします。 Figure 1.3: 証明書署名方法を確認 完了すると、証明書プロバイダーが「Self-managed」に変更されます。 (以下の figure 1.4 をご参照ください) Figure 1.4: クライアント証明書詳細 セルフマネージドクライアント証明書署名の AWS Lambda 関数への入力 AWS IoT Core は、デバイスが CreateCertificateFromCsr MQTT API を呼び出すと、以下の JSON オブジェクトを AWS Lambda 関数に送信します。certificateSigningRequest の値は、デバイスが CreateCertificateFromCsr リクエストにて提供したCSR（ Privacy-Enhanced Mail（PEM）形式 ）です。principalId は、CreateCertificateFromCsr リクエストの際に AWS IoT Core への接続に使用したプリンシパル（クライアント証明書）の ID となります。clientId は MQTT 接続の際に設定したクライアント ID となります。 { "certificateSigningRequest": "string", "principalId": "string", "clientId": "string" } セルフマネージドクライアント証明書署名の AWS Lambda 関数からのレスポンス AWS Lambda 関数は certificatePem の値を含むレスポンスを戻す必要があります。以下は成功した場合のレスポンスの例です。AWS IoT は戻り値 (certificatePem) をクライアント証明書を作成するために使用します。 { "certificatePem": "string" } クライアント証明書の登録が成功した場合、CreateCertificateFromCsr は CreateCertificateFromCsr のレスポンスに含まれるのと同じ certificatePem を返します。詳細は、 CreateCertificateFromCsr のレスポンスのペイロードの例をご参照ください。 重要な注意事項: AWS Lambda 関数が返すクライアント証明書は、証明書署名要求（CSR）と同じサブジェクト名と公開鍵を持つ必要があります。 AWS Lambda 関数は、5秒以内に実行を終了する必要があります。 AWS Lambda 関数は、セルフマネージドクライアント証明書署名を有効にした AWS アカウントおよびリージョンにある必要があります。 AWS IoT サービスに対して、AWS Lambda 関数を実行する権限を付与する必要があります。サービス間での混乱した代理のセキュリティ問題を回避するために（ リンク先のガイダンス に従って、混乱した代理問題を回避してください）、Lambda 関数の実行権限には sourceArn と sourceAccount を設定することを推奨します。詳細については、 サービス間での混乱した代理問題の防止 を参照してください。 AWS CLI を用いてセルフマネージド型のクライアント証明書の署名を有効にする セルフマネージドクライアント証明書の署名を利用するには、アカウントレベルで AWS IoT Core の certificate provider を作成する必要があります。create-certificate-provider CLI コマンドを使って certificate provider を作成することができます。 aws iot create-certificate-provider \ --certificateProviderName my-certificate-provider \ --lambdaFunctionArn arn:aws:lambda:&lt;your-region&gt;:&lt;your-account-id&gt;:function:my-function \ --accountDefaultForOperations CreateCertificateFromCsr このコマンドの出力例は以下のようになります: { "certificateProviderName": "my-certificate-provider", "certificateProviderArn": "arn:aws:iot: &lt;your-region&gt;:&lt;your-account-id&gt;:my-certificate-provider" } AWS IoT Core の certificate provider の作成が成功すると、以下のようにアカウント内の provider のリストを取得することができます: aws iot list-certificate-providers このコマンドの出力例は以下のようになります: { "certificateProviders": [ { "certificateProviderName": "my-certificate-provider", "certificateProviderArn": "arn:aws:iot:us-east-1:123456789012:certificateprovider:my-certificate-provider" } ] } 注意: AWS IoT Core の certificate provider を作成するとフリートプロビジョニング向けの CreateCertificateFromCsr の API の振る舞いは、全ての CreateCertificateFromCsr の呼び出しが CSR を署名するために certificate provider を起動するように変わります。これには certificate provider が作成されてから数分を要しますのでご注意ください。 まとめ AWS IoT Core のフリートプロビジョニングでのセルフマネージドクライアント証明書署名機能により、フリートプロビジョニングを使用する際の証明書署名を、特定のニーズに応じてカスタマイズすることが可能となり、カスタムのインフラストラクチャを設定する必要がなくなります。この機能により、フリートプロビジョニングを使用する際に、よりフレキシブルでかつ制御性の高い形で組織固有のセキュリティの要件を満たすことが可能となります。 著者について Syed Rehan は、ロンドンの Amazon Web Services（AWS）のシニア IoT サイバーセキュリティスペシャリストで、AWS IoT の組織で活動しています。AWS IoT、機械学習、サイバーセキュリティに関する出版物の著者として、彼はグローバルな役割に広範な専門知識をもたらし、Syed は、AWS IoT Core Identify &amp; Access Management サービスの採用を促進するために、セキュリティスペシャリスト、開発者、セキュリティの意思決定者と協力して、グローバルな顧客にサービスを提供しています。サイバーセキュリティ、IoT、クラウド技術に関する深い知識を持ち、スタートアップから大企業まで幅広い顧客を支援し、AWS環境内で安全な IoT ソリューションの構築を可能にしています。 Victor Lesau は Amazon Web Services のシニアテクニカルプロダクトマネージャーです。AWS IoT Core Identity &amp; Access Management の製品戦略、ロードマップ計画、ビジネス分析、顧客エンゲージメント、その他の製品管理分野を担当しています。 Diana Molodan は、AWS IoT Core のソフトウェア開発エンジニアです。豊富な経験を生かし、応用暗号、ID 管理、IoT、クラウドインフラストラクチャに関連する技術に注力しています。 この記事は Syed Rehan、Victor Lesau 、Diana Molodan によって投稿された AWS IoT Core now supports private certificate authorities with fleet provisioning を翻訳したものです。プロフェッショナルサービス本部 シニア IoT コンサルタントの小林が翻訳しました。 <!-- '"` -->

AWS ParallelCluster は、新薬の発見から F1 レースカーの設計、天気の予測に至るまで、さまざまな問題に対応する強力なコンピューティング機能を提供します。 ParallelCluster を利用する全てのケースにおいて、シミュレーションを実行するエンジニアや、実験結果の分析を行うサイエンティストが手動で処理を実行する必要があります。 この投稿では、オープンソースの Slurm REST API を使用して、プログラムでジョブを送信したり監視したりする方法を説明します。 これにより、API 呼び出しを介して ParallelCluster を自動化システムに統合できます。 例えば、ゲノムサンプルがシーケンサーから読み取られるたびに、個々の読み取りのアライメントを行う二次解析パイプラインが自動的に供給されたり、新しい衛星データがAmazon S3バケットに格納されると、最新の天気予報を作成するジョブがトリガーされたりすることを意味します。 本日は、AWS ParallelCluster を使用してこのような仕組みを設定する方法を説明します。 使用できるコードを含む GitHub リポジトリへのリンクを示し、curl と Python の両方を使用して API を呼び出す方法の例を示します。 アーキテクチャー この図は、Slurm REST API を使用したクラスター アーキテクチャーの例を示しています。 REST API はヘッドノード上で実行され、ジョブを Compute キューに送信します。 API の認証に使用される認証情報は、 AWS Secrets Manager に保存されます。 図示されている Compute キューは例にすぎません。クラスターは任意のインスタンス構成で構成できます。 図 1 – REST API 実行におけるアーキテクチャー図 このチュートリアルでは、 ParallelCluster UI を使用してSlurm REST API を有効化し、クラスターをセットアップします。 ParallelCluster UI をセットアップするには、 オンライン ドキュメントを参照してください 。 ParallelCluster CLI を使用したい場合は、Step 4 のYAML 構成例 を参照してください。 Step 1 – インバウンド API リクエストを許可するセキュリティ グループを作成する デフォルト構成では、クラスターは REST API へのインバウンド HTTPS リクエストを受け入れることができません。セキュリティグループを作成して、クラスター外部からのAPI呼び出しを許可します。 EC2 セキュリティグループコンソール に移動し、 [セキュリティ グループを作成] を選択します。 [セキュリティ グループ名]に、 Slurm REST API (または任意の別の名前) を入力します。 [VPC] がクラスターを構築した VPC と一致することを確認してください。 インバウンド ルールを追加し、[タイプ] で HTTPS を選択し、[ソース] をアクセスしたい CIDR 範囲のみに変更します。 例えば、VPC に関連付けられた CIDR を設定することでVPC 内へのアクセスを制限できます。 [セキュリティグループを作成] を選択します。 図 2 – セキュリティグループの設定 Step 2 – IAM 権限を追加する ParallelCluster UI チュートリアル のセクションG – Setup IAM Permissions の手順に従ってください。 Step 3 – クラスターを構成する ParallelCluster UI の Create Clusters で、Head node section &gt; Head node instance &gt; Advanced options &gt; Additional security groups の項目に Step 1 で作成した Slurm REST API セキュリティーグループを追加します。Scripts 配下にある Run script on node configured を選択し、次のスクリプトを追加します。 https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh 図 3 – ノード構成後に実行するスクリプトの追加 Head node section &gt; Security configuration and permissions &gt; IAM Policies の項目に、ポリシーを追加します。この作業は JSON Web Token (JWT) を自動的に更新するために必要となります。 arn:aws:iam::aws:policy/SecretsManagerReadWrite 図 4 – AWS SecretsManager の更新を許可する IAM ポリシーの追加 クラスターを作成します。 Step 4 – 構成を検証する Cluster Configuration YAML ファイルは次のようなテキストになります。 ParallelCluster UI の代わりに ParallelCluster CLI を使用することを選択した場合は、以下を置き換える必要があります。 AdditionalSecurityGroups : Slurm REST API への接続を許可する追加のセキュリティ グループが含まれている必要があります (Step 1 にて作成)。 OnNodeConfigured : インストール後のスクリプトを参照する必要があります: https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh Imds: ImdsSupport: v1.0 HeadNode: InstanceType: c5.xlarge Imds: Secured: true Ssh: KeyName: amzn2 LocalStorage: RootVolume: VolumeType: gp3 Networking: SubnetId: subnet-xxxxxxxxxxxxxx AdditionalSecurityGroups: - sg-slurmrestapixxxxxxxxxx Iam: AdditionalIamPolicies: - Policy: arn:aws:iam::aws:policy/SecretsManagerReadWrite CustomActions: OnNodeConfigured: Script: &gt;- https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh Scheduling: Scheduler: slurm SlurmQueues: - Name: queue-1 ComputeResources: - Name: queue-1-cr-1 Instances: - InstanceType: c5.xlarge MinCount: 0 MaxCount: 4 ComputeSettings: LocalStorage: RootVolume: VolumeType: gp3 Networking: SubnetIds: - subnet-xxxxxxxxxxxxxxxxxx Region: us-east-2 Image: Os: alinux2 Step 5 – API を呼び出す Step 1 のセキュリティグループ上で許可したネットワークのマシンにログインします。このマシンがヘッドノードと通信できることを確認してください。 ssh username@ip 次の環境変数を設定します。 export CLUSTER_NAME=[name of cluster] &nbsp;API リクエストを作成するために必要な情報を確認し、API リクエストを呼び出します。 APIリクエストの作成には、以下の情報が必要です。 ・JWT トークン : インストール後のスクリプトにより、 AWS SecretsManager に slurm_token_$CLUSTER_NAME という名前でシークレットが作成されます。 AWS コンソールまたは AWS CLI を使用して、クラスター名に基づいてシークレットを確認します。 export JWT=$(aws secretsmanager get-secret-value --secret-id slurm_token_$CLUSTER_NAME | jq -r '.SecretString') NOTE: Since the Slurm REST API script is not integrated into ParallelCluster, this secret will not be automatically deleted along with the cluster. You may want to remove it manually on cluster deletion. Bash ・ヘッドノードの Public IP : Amazon EC2 ダッシュボードまたは ParallelCluster CLI を使用してヘッドノードの Public IP を確認することができます。 export HEADNODE_IP=$(pcluster describe-cluster-instances -n $CLUSTER_NAME | jq -r '.instances[0].publicIpAddress') ・クラスター ユーザー : 利用するAMI によって異なりますが、通常は ec2-user 、 ubuntu 、または centos のいずれかになります。 export CLUSTER_USER=ec2-user curl を使用して API を呼び出します。 curl -H "X-SLURM-USER-NAME: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" https://$HEADNODE_IP/slurm/v0.0.39/ping -k 次のような応答が返されます。 { "meta": { "plugin": { "type": "openapi\/v0.0.39", "name": "REST v0.0.39" }, "Slurm": { "version": { "major": 23, "micro": 2, "minor": 2 }, "release": "23.02.2" }... APIを使用してジョブを送信します。 JSONを使用してジョブパラメーターを指定します。 クラスターユーザーに応じて、標準ディレクトリの変更が必要になる場合があります。 API にジョブを送信します。 curl -H "X-SLURM-USER-TOKEN: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" -X POST https://$IP/slurm/v0.0.39/job/submit -H "Content-Type: application/json" -d @testjob.json -k ジョブが実行中であることを確認します。 curl -H "X-SLURM-USER-NAME: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" https://$IP/slurm/v0.0.39/jobs -k Python リクエスト ライブラリを使用した API の呼び出し 次の内容を含む slurmapi.py というスクリプトを作成します。 #!/usr/bin/env python3 import argparse import boto3 import requests import json # Create argument parser parser = argparse.ArgumentParser() parser.add_argument('-n', '--cluster-name', type=str, required=True) parser.add_argument('-u', '--cluster-user', type=str, required=False) subparsers = parser.add_subparsers(dest='command', required=True) diag_parser = subparsers.add_parser('diag', help="Get diagnostics") ping_parser = subparsers.add_parser('ping', help="Ping test") submit_job_parser = subparsers.add_parser('submit-job', help="Submit a job") submit_job_parser.add_argument('-j', '--job', type=str, required=True) list_jobs_parser = subparsers.add_parser('list-jobs', help="List active jobs") describe_job_parser = subparsers.add_parser('describe-job', help="Describe a job by id") describe_job_parser.add_argument('-j', '--job-id', type=int, required=True) cancel_parser = subparsers.add_parser('cancel-job', help="Cancel a job") cancel_parser.add_argument('-j', '--job-id', type=int, required=True) args = parser.parse_args() # Get JWT token client = boto3.client('secretsmanager') boto_response = client.get_secret_value(SecretId=f'slurm_token_{args.cluster_name}') jwt_token = boto_response['SecretString'] # Get cluster headnode IP client = boto3.client('ec2') filters = [{'Name': 'tag:parallelcluster:cluster-name', 'Values': [args.cluster_name]}] boto_response = client.describe_instances(Filters=filters) headnode_ip = boto_response['Reservations'][0]['Instances'][0]['PublicIpAddress'] url = f'https://{headnode_ip}/slurm/v0.0.39' headers = {'X-SLURM-USER-TOKEN': jwt_token} if args.cluster_user: headers['X-SLURM-USER-NAME'] = args.cluster_user # Make request if args.command == 'ping': r = requests.get(f'{url}/ping', headers=headers, verify=False) elif args.command == 'diag': r = requests.get(f'{url}/diag', headers=headers, verify=False) elif args.command == 'submit-job': with open(args.job) as job_file: job_json = json.load(job_file) r = requests.post(f'{url}/job/submit', headers=headers, json=job_json, verify=False) elif args.command == 'list-jobs': r = requests.get(f'{url}/jobs', headers=headers, verify=False) elif args.command == 'describe-job': r = requests.get(f'{url}/job/{args.job_id}', headers=headers, verify=False) elif args.command == 'cancel-job': r = requests.delete(f'{url}/job/{args.job_id}', headers=headers, verify=False) print(r.text) ジョブを送信するには下記を実行してください。 ./slurmapi.py -n [cluster_name] submit-job -u [cluster_user] -j testjob.json さらに詳しい情報を入手するには下記を実行してください。 ./slurmapi.py -h 結論 Slurm REST API をセットアップすると、クラスターをプログラムで制御できるようになり、クラスターを自動化ワークフロー上で構築できるようになります。 これにより、無数のユースケースの中でも、ゲノミクスデータの自動二次分析、金融市場のリスク分析、天気予報などの新しいユースケースが可能になります。 私たちは皆さんが何を構築するかを楽しみにしています。思いついたものを X（旧Twitter） に投稿して紹介してください。 この投稿は、シニア HPC ソリューション アーキテクトである Sean Smith と、HPC SDE インターンである Ryan Kilpadi によって寄稿されました。 翻訳はソリューションアーキテクトの寺部が担当しました。原文は こちら です。 著者について Ryan Kilpadi Ryan Kilpadi は、AWS ParallelCluster を手がける HPC チームの SDE インターンとして戻ってきました。 彼は、2022 年の夏のインターンシップ プロジェクトとして、ParallelCluster での Slurm REST API の実装に取り組みました。 Sean Smith Sean Smith は、AWS の HPC および生成 AI 担当のシニア スペシャリスト ソリューション アーキテクトです。 以前は AWS Batch と CfnCluster のソフトウェア エンジニアとして働き、AWS ParallelCluster を作成したチームの最初のエンジニアになりました。

異種データベースの移行は多段階のプロセスであり、通常、評価、データベーススキーマの変換、データ移行、機能テスト、パフォーマンスチューニングなど、複数のチームにわたる多くのステップが含まれます。 IBM Db2 LUW から Amazon Aurora PostgreSQL 互換エディション または Amazon Relational Database Service (Amazon RDS) for PostgreSQL への移行は、本質的に異種DBの移行であり、従前から用いられているこういった手順が必要です。 AWS では、異種データベース移行のスキーマ変換を簡素化する AWS Schema Conversion Tool (AWS SCT)や、ダウンタイムを最小限に抑えながらデータを迅速かつ安全に AWS に移行できる AWS Database Migration Service (AWS DMS) などのツールとサービスを提供しています。 AWS SCT は、PostgreSQL に自動的に変換される Db2 コードの割合、変換に手作業が必要なコードの割合と詳細なアクション項目を示す評価レポートを生成します。 AWS SCT によるスキーマの移行は完全に自動化されたプロセスではないため、ターゲットデータベースのオブジェクトや主要なオブジェクト機能が不足している可能性は常にあります。 スキーマの検証は移行プロセスにおいて、スキーマ変換プロセスでの問題を、それ以降の段階に持ち越さないようにするための重要なマイルストーンです。 この記事では、Db2 LUW から Amazon RDS for PostgreSQL または Aurora PostgreSQL に移行されたデータベーススキーマオブジェクトを検証する方法について説明します。 いつ、どのオブジェクトを検証すべきか スキーマを Db2 LUW から正常に変換し、AWS SCT またはその他の変換ツールを使用して PostgreSQL に変換されたスキーマをデプロイ後、スキーマ検証を実行する必要があります。 次のリストは、データベース移行時に検証する必要がある Db2 LUW (ソース) と Aurora PostgreSQL (ターゲット) のデータベースオブジェクトを示しています。 スキーマ テーブル ビュー 主キー 外部キー インデックス マテリアライズドクエリテーブル ユーザー定義データ型 トリガー シーケンス プロシージャ 関数 以下のセクションでは、各オブジェクトタイプのオブジェクト数がソースデータベースとターゲットデータベースで一定であることを確認するために、各オブジェクトタイプの検証シナリオを詳細に説明します。 これらの検証シナリオでは、変換の精度は対象外です。 スキーマ スキーマは、アプリケーションまたはマイクロサービスに関連した機能を提供するデータベースオブジェクトの集まりです。 SQL クエリを使用して、ソースデータベースとターゲットデータベースのスキーマを検証できます。 DB2 LUW Query PostgreSQL Query select schemaname as schema_name from syscat . schemata where schemaname not like 'SYS%' and schemaname not IN ( 'SQLJ' , 'NULLID' ) order by schema_name ; SQL SELECT SCHEMA_NAME , SCHEMA_OWNER FROM INFORMATION_SCHEMA . SCHEMATA WHERE SCHEMA_NAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) AND SCHEMA_NAME not like 'pg_temp%' AND SCHEMA_NAME not like 'pg_toast%' order by SCHEMA_NAME ; SQL Db2 LUW example output: PostgreSQL example output: Db2 LUW スキーマを変換すると、AWS SCT はターゲットデータベースに追加のスキーマ ( aws_db2_ext と aws_db2_ext_data ) を追加します。 これらのスキーマは、変換されたスキーマを Aurora PostgreSQL データベースに書き込む際に必要な Db2 LUW データベースの SQL システム関数を実装します。 これらの追加スキーマは AWS SCT 拡張パック と呼ばれます。 Db2 LUW と PostgreSQL (‘ pg_catalog ‘、’ information_schema ‘、’ public ‘) のシステムテーブルまたはカタログテーブル (‘ SYS% ‘、’ SQLJ ‘、’ NULLID ‘) に関連するスキーマは除外されます。 また、Aurora PostgreSQL の特定の機能に関連するスキーマ ( aws_commons 、 aws_lambda ) も除外しています。 ソースデータベースとターゲットデータベースのスキーマの数が一致していることを確認する必要があります。 相違点が見つかった場合は、 AWS SCT のログ を調べて障害の原因を特定するか、手動で作成する必要があります。 テーブル AWS SCT はソース Db2 LUW テーブルを同等のターゲット (PostgreSQL) テーブルに変換します。 必要に応じて、カスタム マッピングルール を使用して特定のテーブルを移行対象に含めたり除外したりできます。 以下のスクリプトは、すべてのテーブルの数と詳細レベルの情報を返します。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as table_count from syscat . tables tab where tab . type = 'T' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL SELECT NSPNAME as schema_name , count ( RELNAME ) as table_count FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'p' , 'r' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) group by NSPNAME ORDER BY NSPNAME ; SQL Db2 LUW example output: PostgreSQL example output: IBM Db2 ではテーブルパーティションを個別のテーブルとしてリストしていないため、PostgreSQL のパーティションテーブルを除外するために C.RELISPARTITION = 'f' という条件を追加しました。 PostgreSQL には、プライマリキー、外部キー、インデックスのオブジェクト数に影響する可能性のある パーティションテーブル に関するいくつかの制限があることに注意してください。 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as table_name from syscat . tables tab where tab . type = 'T' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname ; SQL SELECT NSPNAME as schema_name , RELNAME as table_name FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'p' , 'r' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) order by NSPNAME , RELNAME ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベースの結果を検証します。 違いが見られる場合は、AWS SCT または手動ログから理由を特定し、問題を解決した後に失敗したステートメントを再実行してください。 ビュー AWS SCT によって変換されたビュー数は、ソースデータベースとターゲットデータベースで次のクエリを実行して検証できます。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as view_count from syscat . tables tab where tab . type = 'V' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL SELECT NSPNAME as schema_name , count ( RELNAME ) as view_count FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'v' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) group by NSPNAME order by NSPNAME ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as view_name from syscat . tables tab where tab . type = 'V' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname ; SQL SELECT NSPNAME as schema_name , RELNAME as view_name FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'v' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by NSPNAME , RELNAME ; SQL Db2 LUW example output: PostgreSQL example output: この SQL を使用して、ソースとターゲットの間の数と詳細を確認する必要があります。 相違点が見つかった場合は、原因を特定して相違点を修正してください。 主キー データベースオブジェクトの検証に加えて、データに一貫性があり、整合性が保たれていることを確認する必要があります。 制約 の種類が異なると、挿入時にデータを柔軟に制御して確認できるため、実行時のデータ整合性の問題を回避できます。 主キーを使用すると、列に一意の値を設定できるため、正規化処理後に情報が重複するのを防ぐことができます。 このキーは、キー値に基づく検索を改善し、テーブルスキャンを回避するのに役立ちます。 次のクエリは、ソースデータベースとターゲットデータベースの主キーの数と詳細を抽出するのに役立ちます。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( * ) as PK_Count from syscat . tables tab inner join syscat . tabconst const on const . tabschema = tab . tabschema and const . tabname = tab . tabname and const . type = 'P' inner join syscat . keycoluse key on const . tabschema = key . tabschema and const . tabname = key . tabname and const . constname = key . constname where tab . type = 'T' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL select kcu . table_schema , count ( * ) as pk_count from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'PRIMARY KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by kcu . table_schema order by kcu . table_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as table_name , const . constname , key . colname as column_name , key . colseq as position from syscat . tables tab inner join syscat . tabconst const on const . tabschema = tab . tabschema and const . tabname = tab . tabname and const . type = 'P' inner join syscat . keycoluse key on const . tabschema = key . tabschema and const . tabname = key . tabname and const . constname = key . constname where tab . type = 'T' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname , const . constname , key . colname , key . colseq ; SQL select kcu . table_schema , kcu . table_name , tco . constraint_name , kcu . column_name , kcu . ordinal_position as position from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'PRIMARY KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by kcu . table_schema , kcu . table_name , tco . constraint_name , kcu . column_name , kcu . ordinal_position ; SQL Db2 LUW example output: PostgreSQL example output: この SQL を使用して、ソースとターゲットの間のプライマリキーの数と詳細を確認する必要があります。 相違点が見つかった場合は、デプロイログから原因を特定し、違いを修正してください。 外部キー 外部キーはテーブル間の参照整合性を維持するのに役立ちます。 AWS DMS のフルロードを使用してデータ移行を実行する前に、ターゲット側でこれらのキーをオフにする必要があります。 詳細については、「 PostgreSQL データベースの AWS Database Migration Service のターゲットとしての使用 」を参照してください。 次のクエリでは、ソースデータベースとターゲットデータベースの両方にある外部キーの数と詳細レベルの情報を取得できます。 外部キーは、AWS DMS を使用してフルロードによるデータ移行を完了した後に検証します。 Db2 LUW Query PostgreSQL Query select tabschema as schema_name , count ( * ) as fk_count from syscat . references where tabschema not like 'SYS%' group by tabschema order by tabschema ; SQL select kcu . table_schema , count ( * ) as fk_count from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'FOREIGN KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by kcu . table_schema order by kcu . table_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select ref . reftabschema as schema_name , ref . reftabname as table_name , ref . constname as fk_constraint_name , ref . tabname as foreign_table_name , trim ( key . colname ) as fk_column_name from syscat . references ref left outer join syscat . keycoluse key on key . tabschema = ref . tabschema and key . tabname = ref . tabname and key . constname = ref . constname where ref . tabschema not like 'SYS%' order by ref . reftabschema , ref . reftabname , ref . constname ; SQL select rel_kcu . table_schema as schema_name , rel_kcu . table_name as table_name , kcu . constraint_name , kcu . table_name as foreign_table_name , kcu . column_name as fk_column_name from information_schema . table_constraints tco join information_schema . key_column_usage kcu on tco . constraint_schema = kcu . constraint_schema and tco . constraint_name = kcu . constraint_name join information_schema . referential_constraints rco on tco . constraint_schema = rco . constraint_schema and tco . constraint_name = rco . constraint_name join information_schema . key_column_usage rel_kcu on rco . unique_constraint_schema = rel_kcu . constraint_schema and rco . unique_constraint_name = rel_kcu . constraint_name and kcu . ordinal_position = rel_kcu . ordinal_position where tco . constraint_type = 'FOREIGN KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by rel_kcu . table_schema , rel_kcu . table_name , kcu . constraint_name ; SQL Db2 LUW example output: PostgreSQL example output: PostgreSQL バージョン 11 にはパーティションテーブルの外部キーに関する 制限 がありますが、その制限の多くはバージョン 12 以降では解消されています。 ソースデータベースとターゲットデータベース間の外部キーの数と詳細を検証する際は、これらの制限に留意する必要があります。 インデックス インデックスは、テーブルの 1 つ以上の列に基づいて作成されるデータベースオブジェクトです。 インデックスはクエリのパフォーマンスを改善し、ユニークインデックスとして定義した場合にはデータの一意性を保証します。 ユニークインデックス ユニークキーを使用すると、カラム内のデータの一意性を維持できます。 次のクエリを使用すると、ソースデータベースとターゲットデータベースの両方にあるユニークキーの数と詳細レベルの情報を取得できます。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , count ( cols . colname ) as unique_count from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'U' ) group by ind . tabschema order by schema_name ; SQL SELECT sch . nspname , count ( * ) as unique_count FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 't' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by sch . nspname order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , ind . tabname as table_name , ind . indname as CONSTRAINT_NAME , 'Unique Index' as constraint_type , cols . colname as column_name from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'U' ) order by schema_name , ind . tabname , ind . indname ; SQL SELECT sch . nspname as schema_name , tab . relname as table_name , cls . relname as constraint_name , ids . indexdef as definition FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 't' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 非ユニークインデックス インデックス はクエリのパフォーマンスを向上させる上で重要な役割を果たします。 チューニング方法はデータベースごとに異なるため、Db2 LUW データベースと PostgreSQL データベースではユースケースによってインデックスの数や種類が異なるため、インデックスの数も異なる場合があります。 PostgreSQL のパーティションテーブルの制限により、インデックス数も異なる場合があります。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , count ( cols . colname ) as index_count from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'D' ) group by ind . tabschema order by schema_name ; SQL SELECT sch . nspname , count ( * ) as index_count FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 'f' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by sch . nspname order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , ind . tabname as table_name , ind . indname as index_name , cols . colname as column_name from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'D' ) order by schema_name , ind . tabname , ind . indname , cols . colname ; SQL SELECT sch . nspname as schema_name , tab . relname as tabl_name , cls . relname as constraint_name , ids . indexdef as definition FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 'f' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベース間のインデックスの数と詳細を確認する必要があります。違いがある場合は、既知の理由によるものか、デプロイメントログに基づいて調査して修正する必要があります。 マテリアライズド・クエリー・テーブル Db2 LUW のマテリアライズドクエリテーブルは PostgreSQL の マテリアライズドビュー として移行されます。 マテリアライズドクエリテーブルが結果をテーブルのような形で保持することを除けば、通常のビューと似ています。 これにより、データがすぐに返されるので、クエリのパフォーマンスが向上します。 次のクエリを使用して、ソースとターゲットのオブジェクトを比較できます。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as mq_count from syscat . tables tab where tab . type = 'S' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL select schemaname , count ( * ) as mq_count from pg_matviews where schemaname NOT IN ( 'information_schema' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) group by schemaname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tabschema as schema_name , tabname as MQ_NAME from syscat . tables where type = 'S' and tabschema not like 'SYS%' ; SQL select schemaname , matviewname as mq_name from pg_matviews where schemaname NOT IN ( 'information_schema' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベース間のマテリアライズドクエリテーブルとマテリアライズドビューの数と詳細を確認し、違いがあればデプロイログに基づいて調査して修正する必要があります。 ユーザー定義データ型 AWS SCT はカスタムデータタイプを Db2 LUW から PostgreSQL に タイプ として移行します。次のクエリを使用して、ソースとターゲットのオブジェクトを比較できます。 Db2 LUW Query PostgreSQL Query select typeschema as schema_name , count ( * ) as udt_count from SYSCAT . DATATYPES where typeschema not like 'SYS%' group by typeschema ; SQL SELECT n . nspname , count ( * ) as udt_count FROM pg_catalog . pg_type t JOIN pg_catalog . pg_namespace n ON n . oid = t . typnamespace WHERE ( t . typrelid = 0 OR ( SELECT c . relkind = 'c' FROM pg_catalog . pg_class c WHERE c . oid = t . typrelid ) ) AND NOT EXISTS ( SELECT 1 FROM pg_catalog . pg_type el WHERE el . oid = t . typelem AND el . typarray = t . oid ) AND n . nspname NOT IN ( 'information_schema' , 'pg_toast' , 'aws_commons' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) group by n . nspname order by n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベース間のユーザー定義型の数と詳細を確認し、違いがあればデプロイログに基づいて調査して修正する必要があります。 トリガー トリガー は、データベースの監査、ビジネスルールの実装、参照整合性の実装に役立ちます。 また、適切な領域での使用状況によっては、パフォーマンスに影響を与えることもあります。 以下のクエリでは、ソースデータベースとターゲットデータベースの両方のトリガーの数と詳細がわかります。 Db2 LUW Query PostgreSQL Query select tabschema as table_schema , count ( trigname ) as trigger_count From syscat . triggers t where tabschema not like 'SYS%' group by tabschema order by tabschema ; SQL SELECT trigger_schema AS SchemaName , Count ( trigger_name ) AS TriggerCount FROM information_schema . TRIGGERS WHERE trigger_schema NOT IN ( 'aws_db2_ext' , 'aws_db2_ext_data' , 'pg_catalog' ) GROUP BY trigger_schema ORDER BY trigger_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tabschema as table_schema , trigname as trigger_name , tabname as table_name , case trigtime when 'B' then 'before' when 'A' then 'after' when 'I' then 'instead of' end as activation , rtrim ( case when eventupdate = 'Y' then 'update ' else '' end || case when eventdelete = 'Y' then 'delete ' else '' end || case when eventinsert = 'Y' then 'insert ' else '' end ) as event from syscat . triggers t where tabschema not like 'SYS%' order by table_name , trigger_name ; SQL SELECT trigger_schema AS TriggerSchemaName , trigger_name , event_object_schema AS TableSchema , event_object_table AS TableName , event_manipulation AS TriggerType FROM information_schema . TRIGGERS WHERE trigger_schema NOT IN ( 'aws_db2_ext' , 'aws_db2_ext_data' , 'pg_catalog' ) ORDER BY trigger_schema , trigger_name ; SQL Db2 LUW example output: PostgreSQL example output: Db2 LUW と PostgreSQL の間のトリガー数は、PostgreSQL でのトリガーの 実装方法 によって異なる場合があります。 ソースデータベースとターゲットデータベース間のトリガーの数と詳細を確認する必要があります。相違点がある場合は、既知の理由によるものか、デプロイメントログに基づいて調査して修正する必要があります。 シーケンス シーケンスは、指定した範囲と順序に基づいて列の整数値を作成したり増やすのに役立ちます。 ID 列とは異なり、シーケンスは特定のテーブルに関連付けられません。 アプリケーションはシーケンスオブジェクトを参照して次の値を取得します。 シーケンスとテーブルの関係はアプリケーションによって制御されます。 ユーザーアプリケーションはシーケンスオブジェクトを参照し、複数の行やテーブルにわたって値を調整できます。 以下のクエリは、ソースデータベースとターゲットデータベースにあるシーケンスの数と詳細レベルの情報を取得するのに役立ちます。 Db2 LUW Query PostgreSQL Query select SEQSCHEMA , count ( * ) as seq_count from syscat . sequences where SEQSCHEMA not like 'SYS%' and OWNERTYPE = 'U' and SEQTYPE = 'S' group by SEQSCHEMA order by SEQSCHEMA ; SQL select n . nspname as schema_namee , count ( * ) as seq_count from pg_sequence seq join pg_class seqc on seq . seqrelid = seqc . oid join pg_namespace n on seqc . relnamespace = n . oid where n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) group by n . nspname order by n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下を使用してください。 Db2 LUW Query PostgreSQL Query select SEQSCHEMA , SEQNAME , CYCLE , ORDER , CACHE from syscat . sequences where SEQSCHEMA not like 'SYS%' and OWNERTYPE = 'U' and SEQTYPE = 'S'; SQL select n . nspname as schema_namee , seqc . relname as seqname , seqcycle as cycle , seqcache as cache from pg_sequence seq join pg_class seqc on seq . seqrelid = seqc . oid join pg_namespace n on seqc . relnamespace = n . oid where n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) order by n . nspname , seqc . relname ; SQL Db2 LUW example output: PostgreSQL example output: ソースとターゲットの間のシーケンスの数と詳細を確認する必要がありますが、移行後にシーケンスを正しい値に 設定する ことも重要です。 シーケンスをソースデータベースからターゲットデータベースに移行した後は、シーケンスの minvalue から始まるため、挿入文や更新文の実行中に重複キーエラーが発生する可能性があります。 プロシージャ Db2 LUW ストアドプロシージャは、ビジネスロジックをカプセル化し、関連する DDL または DML 操作を単一の作業単位で実行します。 PostgreSQL では、 プロシージャ の制限により、ストアドプロシージャよりも 関数 を使用します。この数は、ソースデータベース内の既存の関数数に加算されます。 ソースデータベースとターゲットデータベースの両方で、次のクエリはプロシージャの数と詳細レベルの情報を提供します。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , count ( * ) as proc_count from syscat . routines where routinetype = 'P' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' group by routineschema order by routineschema ; SQL SELECT n . nspname AS SchemaName , Count ( p . proname ) AS procCount FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'p' GROUP BY n . nspname ORDER BY n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , routinename as procedure_name from syscat . routines where routinetype = 'P' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' order by schema_name , procedure_name ; SQL SELECT n . nspname AS SchemaName , p . proname AS function_name FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'p' GROUP BY n . nspname , p . proname ORDER BY n . nspname , p . proname ; SQL Db2 LUW example output: PostgreSQL example output: 関数 Db2 LUW では、関数は入力パラメータに特定のビジネスロジックまたは機能ロジックを実装し、特定の種類の定義済み出力を返します。 PostgreSQL では、ビジネスロジックとファンクショナルロジックの実装に関数が好まれるため、その数は通常 Db2 LUW よりも多くなります（訳注： PostgreSQL では、関数を使ってロジック実装されることが Db2 と比較すると多いためで、 SCT の変換機能により関数の数が増えるわけではありません）。ソースデータベースとターゲットデータベースの両方で、以下のクエリは関数の数と詳細レベルの情報を提供します。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , count ( * ) as func_count from syscat . routines where routinetype = 'F' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' group by routineschema order by routineschema ; SQL SELECT n . nspname AS SchemaName , Count ( p . proname ) AS func_Count FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'f' GROUP BY n . nspname ORDER BY n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , routinename as function_name from syscat . routines where routinetype = 'F' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' order by schema_name , function_name ; SQL SELECT n . nspname AS SchemaName , p . proname AS function_name FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'f' GROUP BY n . nspname , p . proname ORDER BY n . nspname , p . proname ; SQL Db2 LUW example output: PostgreSQL example output: 有用な PostgreSQL カタログテーブル 次の表は、いくつかの有用な Db2 LUW と、それに対応する PostgreSQL システムおよびカタログのテーブルとビューをまとめたものです。 これらのテーブルとビューには、データベース内に存在するさまざまなオブジェクトに関するメタデータが含まれており、データベースオブジェクトの検証に使用されます。 Db2 LUW PostgreSQL Use Case syscat.tables/ syscat.columns pg_tables /information_schema.tables さまざまなテーブルのプロパティ syscat.tables/ syscat.columns Pg_views/information_schema.views ビューのさまざまなプロパティ syscat.tables/ syscat.tabconst/ syscat.references/ syscat.keycoluse pg_indexes/pg_index インデックスに関する詳細情報 syscat.routines pg_proc プロシージャ、関数、トリガー関数に関する詳細情報 syscat.triggers information_schema.triggers トリガーに関する詳細情報 Syscat.sequences pg_sequence/information_schema.sequences シーケンス、ID、serialカラムに関する詳細情報 Syscat.tables pg_matviews マテリアライズドビューの詳細 syscat.datatypes pg_type カスタムデータ型に関する詳細情報 PostgreSQL ではサポートされていないオブジェクトの扱い PostgreSQL でサポートされていない Db2 LUW オブジェクトの移行は手動で実行する必要があります。 この記事で提供するクエリを使用すると、移行したオブジェクトを繰り返し検証してギャップを特定し、それに応じて修正できます。 まとめ この投稿では、Db2 LUW と Aurora PostgreSQL、または PostgreSQL データベース用の RDS のメタデータクエリによるデータベースオブジェクトの検証について説明しました。 データベースオブジェクトの検証は、移行の正確性を詳細に把握し、すべてのデータベースオブジェクトが適切に移行されたかどうかを確認するための重要なステップです。 また、データベース検証フェーズでは、ターゲットデータベースの整合性を確認し、依存するアプリケーションプロセスの事業継続性を確保します。 オブジェクトが自動変換されるか手動で変換されるかに関係なく、機能テストだけでなくユニットテストも数回繰り返す必要があります。 これにより、アプリケーションとの統合テストを行う際の多くのやり直しが省けます。 コメントや質問がある場合はお知らせください。 私たちは皆さんのフィードバックを大切にしています！ 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。 著者について Sai Parthasaradhi は AWS プロフェッショナルサービスのデータベース移行スペシャリストです。 彼はお客様と緊密に連携して、お客様が AWS でデータベースを移行し、最新化できるよう支援しています。 Rakesh Raghav は、インドの AWS プロフェッショナルサービスの主任データベースコンサルタントで、お客様がクラウドの導入と移行を成功させるお手伝いをしています。 彼は、お客様のデータベースのクラウドへの移行を加速させる革新的なソリューションの構築に情熱を注いでいます。 Veeranjaneyulu Grandhi は、AWSのデータベースコンサルタントです。 彼はお客様と協力して、スケーラブルで可用性が高く、安全なソリューションを AWS クラウドで構築しています。 彼の重点分野は、同種データベース移行と異種データベース移行です。

この投稿では、IBM Guardium でモニタリングするための Amazon Aurora PostgreSQL 互換エディション のデータベースアクティビティストリーミング (DAS) をセットアップする手順を説明します。 ここでは IBM Guardium バージョン 11.5 を使用しています。 Aurora PostgreSQL 互換エディションは、 Amazon Aurora のスピード、信頼性、管理性と、オープンソースデータベースのシンプルさと費用対効果を兼ね備えた、フルマネージドの PostgreSQL 互換、ACID 準拠のリレーショナルデータベースエンジンです。 IBM Guardium は、データベースアクティビティのモニタリングとデータ保護機能を提供する IBM セキュリティ製品です。 IBM Guardium は Aurora データベース内のアクティビティをリアルタイムで継続的に監視します。 SQL ステートメント、ログイン試行、管理アクションをキャプチャして分析します。 Guardiumはデータベースのアクティビティを即座に可視化することで、疑わしいアクティビティや不正なアクティビティを迅速に特定して対応できるようにします。 高度な分析と機械学習 (ML) 技術を採用して、潜在的なセキュリティ脅威を検出して防止します。 また、データ保護ポリシーを実施することで、 Amazon Relational Database Service (Amazon RDS) に保存されている機密データを保護するのにも役立ちます。 Amazon RDS 環境内のきめ細かなアクセス制御を確立し、特権ユーザーのアクティビティを監視できます。 IBM Guardiumは、組織がGDPR、HIPAA、PCI DSSなどを含む 幅広い規制や標準 へのコンプライアンスを維持できるよう支援します。 コンプライアンス要件を満たすのに役立つ、事前に作成されたコンプライアンス・レポートとテンプレートのほか、カスタマイズ可能なポリシーとルールも用意されています。 IBM Guardiumがサポートするプラットフォームについては、「 Guardium Data Protection 11.5のサポート対象プラットフォームと要件 」を参照してください。 ソリューション概要 以下の図は、IBM Guardium でモニタリング用に Aurora DAS を構成するための大まかな手順を示しています。 ワークフローには以下のステップが含まれます。 データベースアクティビティストリーミングを有効にする 。 「この構成ではデータベースアクティビティストリーミングを開始できません」というエラーが表示される場合は、「 データベースアクティビティストリーミングでサポートされている DB インスタンスクラス 」をチェックして、DB クラスターがサポートされているインスタンスクラスを使用しているかどうかを確認してください。 Aurora は Amazon Kinesis データストリームを自動的に作成します。 RDS データベースインスタンスの データベースアクティビティストリーミングのステータス は、Amazon RDS コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して取得できます。 IBM Guardium で Kinesis データストリームを設定します。 IBM Guardium は Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するデータコレクターで、RDS インスタンスからデータベースアクティビティをキャプチャします。 IBM Guardium で DAS を設定したら、収集するデータとその処理方法を定義する IBM Guardium ポリシー を設定する準備が整います。 IBM Guardium では、Amazon RDS からキャプチャされたデータを分析して、データベースのアクティビティについてより深い洞察を得ることができます。 IBM Guardium に組み込まれている分析機能を使用して、傾向やパターンを特定し、異常を検出し、レポートを生成できます。 これにより、データベースがどのように使用されているかをよりよく理解し、セキュリティーやコンプライアンスを強化する必要がある分野を特定できます。 また、潜在的なセキュリティ脅威やコンプライアンス違反を通知するアラートや通知を設定することもできます。 IBM Guardiumがセキュリティー上の脅威やコンプライアンス違反を検出すると、アラートや通知をトリガーできます。 問題のあるユーザーや IP アドレスをブロックしたり、セキュリティー・チームに電子メール通知を送信したりして、 これらのアラートに自動的に対応するようにIBM Guardiumを構成 できます。 これにより、潜在的なセキュリティー上の脅威に迅速に対応し、ビジネスへの影響を最小限に抑えることができます。 以下のセクションでは、データベースデータベースアクティビティストリーミングを有効にし、Amazon EC2 で IBM Guardium インスタンスを設定する手順を示します。 前提条件 この投稿は、以下の前提条件を満たしていることを前提としています。 必要なリソースを作成する権限を持つ AWS アカウント。 Amazon EC2 で動作する IBM Guardium のアクティブライセンスまたは試用版ライセンス。 AWS マーケットプレイス から セットアップ された IBM Guardium 。 IAM ロールを作成するための AWS Identity and Access Management (IAM) 権限。 Amazon RDS と Kinesis に関する基本的な知識。 Aurora PostgreSQL DB クラスター。 Aurora PostgreSQL DB クラスターを作成するには、「 Aurora PostgreSQL DB クラスターを作成して接続する 」のステップに従ってください。 データベースアクティビティストリーミングの開始 データベースアクティビティモニタリングを有効にするには、「 データベースアクティビティストリーミングの開始 」の手順に従ってください。 IAM ロールの作成 IAM ロールを使用すると、AWS のサービスにアクセスするための一時的な権限を委任できるため、認証情報が長期間使用されなくなります。 詳細については、「 IAM ロールの作成 」を参照してください。 以下のステップを完了してください。 次の IAM ポリシーを使用してロールを作成します。 a. Guardium-das-policy : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:ListStreams", "cloudwatch:PutMetricData", "cloudwatch:GetMetricStatistics" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kinesis:RegisterStreamConsumer", "kinesis:DescribeStreamConsumer", "kinesis:DescribeStreamSummary", "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:ListStreamConsumers", "kinesis:SubscribeToShard" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Scan", "dynamodb:UpdateItem", "dynamodb:DeleteItem" ], "Resource": "*" } ] } JSON b. assume-role: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "*" } ] } JSON 次の IAM 信頼ポリシーステートメントを追加してください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "AWS":"arn:aws:sts::&lt;&lt;account-id&gt;&gt;:assumed-role/&lt;&lt;iam-rolename&gt;&gt;/&lt;&lt;Guardium-instance-id&gt;&gt;" }, "Action": "sts:AssumeRole" } ] } JSON これらの権限は必要に応じてさらに制限できます。 これで、IBM Guardium EC2 インスタンスにロールをアタッチできるようになりました。 Amazon EC2 コンソールのナビゲーションペインで [インスタンス] を選択します。 Guardium インスタンスを選択します。 「アクション」メニューで「セキュリティ」を選択し、「IAM ロールの変更」を選択します。 Guardium インスタンスにアタッチするために作成した IAM ロールを選択します。 [保存] を選択します。 IBM Guardium でデータ・アクティビティ・ストリームを設定します。 Guardiumのデータ・アクティビティ・ストリームを設定するには、以下の手順を実行します。 IBM Guardium ウェブコンソールにログインします。 「 Discover 」、「 Database Discovery 」、「 Cloud DB Service Protection 」を選択します。 以下の詳細を使用して Cloud DB サービスアカウントを作成します。 [ Name ] には、Cloud DB Service Account と入力します。 [ Provider ] には [ Amazon ] を選択します。 [ Audit type ] には、[ Data Streams ] を選択します。 [ Authentication type ] には [ IAM Instance Profile ] を選択します。 [ Role ARN ] には、作成したロールの ARN を入力します。 [ Create ] を選択します。 ストリームを発見したい各リージョンの行を選択し、「 Discover 」を選択します。 オプションで、フィルターを使用して検索を絞り込むこともできます。 たとえば、「us」という文字を含むデータストリームのみを表示するには、us と入力します。 IBM Guardium はリージョンを検索し、選択したリージョンの新しいストリームをすべて Streams テーブルに追加します。 ストリームを選択し、「 Enable Monitoring 」を選択します。 [Start monitoring stream] で、次の情報を入力します。 [DB Type] では、データベースタイプを選択します (この投稿では Aurora PostgreSQL を選択します)。 [DB DNS endpoint] には、DB DNS エンドポイントを入力します。 DB DNS エンドポイントは Amazon RDS コンソールの [接続とセキュリティ] タブにあります。 Writer インスタンスのエンドポイントを選択する必要があります。 [Port] には、DB DNS エンドポイントのポート (5432 など) を入力します。 [Cluster resource ID] には、ストリームに関連付けられた RDS クラスターのクラスターリソース ID を入力します。 クラスターリソース ID は、Amazon RDS の [設定] タブに [リソース ID] というラベルが付いています。 無効または不明なクラスターリソース ID を入力すると、ストリームのステータスにエラーが報告されます。 [Consumer group Name] には、わかりやすい名前を入力します。 これにより、このデータストリームを複数のコンシューマーが共有または別々に表示できるかが決まります。 コンシューマーグループ名には任意の固有の名前を使用できます。 データストリームビューを共有するには、同じコンシューマーグループ名を使用してください。 「OK」を選択します。 データストリームを有効にして実行したら、 stream テーブルを使用してデータストリームを追跡および管理できます。 ステータスカラーの意味は次のとおりです。 緑 – 正常またはストリーミングが有効で、受信レコードを受信しています。 青 – まだ設定されていません グレー – 使用不可 黄色 – 警告。通常は ConsumerNoInboundRecords というメッセージが表示される 赤 – エラー状態 IBM Guardium のポリシー IBM Guardium で DAS を設定すると、Guardium システムが監視するデータベーストラフィックにリアルタイムで適用されるポリシー、ルール、アクションを設定できます。 ポリシーは、どのトラフィックを無視またはログに記録するか、どのアクティビティがより詳細なロギングを必要とするか、どのアクティビティがアラートをトリガーするか、またはデータベースへのアクセスをブロックするかを定義します。 ポリシーとルールの種類、およびポリシーを作成または変更する方法について詳しくは、「 ポリシー 」を参照してください。 クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。 「 Streams 」テーブルで、「 Disable Monitoring 」を選択します。 Cloud DB Service Account を削除します。 Amazon RDS コンソールで RDS インスタンスに移動し、 データベースアクティビティストリーミングを無効 にします。 RDS インスタンスを 削除 します。 Amazon EC2 コンソールで IBM Guardium EC2 インスタンスを 終了 します。 サマリー Amazon RDS を IBM Guardium と統合することで、データベースインフラストラクチャのセキュリティ、コンプライアンス、データ保護機能が全体的に強化されます。 Guardium の高度なモニタリング、脅威検出、コンプライアンスレポート機能により、Amazon RDS 環境におけるデータを自信を持って管理し、リスクを軽減できます。 この記事では、監視用に Aurora PostgreSQL と互換性のある DAS を IBM Guardium でセットアップする方法と、IBM Guardium でポリシーを定義する方法を学びました。 IBM Guardium のオファリングについて詳しくは、以下を参照してください。 IBM Security Guardium Central Manager IBM Guardium protection options IBM Guardium setup policies IBM Guardium support maintenance この投稿についてご意見がありましたら、コメント欄で送信してください。 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。 著者 Supriya Kanjilal は IBM の AWS セキュリティアーキテクトで、15 年以上の業界経験を持ち、サイバーセキュリティとクラウド移行戦略を専門としています。 現在は IBM と AWS の戦略的パートナーシップに取り組んでいます。 彼の役職は、お客様が AWS クラウドで IBM ソフトウェアソリューションを設計、計画、設計できるよう支援することです。 Rishit G. Barochia は IBM のクラウドソフトウェアアーキテクトです。 彼の経験には、テクニカルアーキテクチャ、クラウド、マイクロサービスアーキテクチャ、ハイブリッドソリューションが含まれます。 IBMとAWSの戦略的パートナーシップに取り組んでいます。 彼の役職は、お客様が AWS クラウドで IBM ソフトウェアソリューションを設計、計画、設計できるよう支援することです。 Sethil Nagaraj はアマゾンウェブサービスのパートナーソリューションアーキテクトで、バージニア州を拠点としています。 彼は顧客の問題に対して創造的なソリューションを提供することを楽しんでいる一方で、クラウドコンピューティングがいかに可能性の技術を促進しているかに魅了されています。

この記事は Create an Apache Hudi-based near-real-time transactional data lake using AWS DMS, Amazon Kinesis, AWS Glue streaming ETL, and data visualization using Amazon QuickSight の翻訳記事です。 テクノロジーの急速な発展に伴い、ますます多くのデータ量が、構造化、半構造化、非構造化など、さまざまな形式で提供されるようになっています。ほぼリアルタイムで業務データをデータ分析することは、一般的なニーズとなりつつあり、データ量の急激な増加により、スケーラビリティとパフォーマンスを向上させるために、リードレプリカをデータレイクに置き換えることが一般的になっています。実際のユースケースの多くでは、リレーショナルデータベースのソースからターゲットにリアルタイムでデータをレプリケートすることが重要です。変更データキャプチャ（CDC）は、ソースデータベースで行われた変更をキャプチャし、他のデータストアに反映するための最も一般的なデザインパターンの1つです。 最近、 AWS Glue 4.0 でのストリーミング抽出、変換、およびロード（ETL）ジョブの サポートを発表 しました。AWS Glueの新バージョンで、AWS内でのデータ統合ワークロードを高速化します。AWS Glue のストリーミング ETL ジョブは、ストリーミングソースから継続的にデータを取得し、インフライトでデータをクリーンアップおよび変換し、数秒で分析に利用できるようにします。お客様のニーズをサポートするため、AWSは幅広いサービスを提供しています。 AWS Database Migration Service （AWS DMS）のようなデータベースレプリケーションサービスは、ソースシステムから Amazon Simple Storage Service （Amazon S3）というデータレイクのストレージ層をとして広く使われているストレージサービスにデータをレプリケートすることができます。リレーショナルデータベース管理システム（RDBMS）に更新を適用するのは簡単ですが、データレイクにこのCDCプロセスを適用するのは困難です。オープンソースのデータ管理フレームワークである Apache Hudi は、インクリメンタルなデータ処理とデータパイプライン開発を簡素化するために使用され、上記の問題を解決するための良い選択肢です。 この投稿では、Amazon Relational Database Service（Amazon RDS）やその他のリレーショナルデータベースから S3 データレイクにニアリアルタイムだけではなく、データの非正規化、変換、エンリッチ可能な柔軟性を持つ CDC の適応方法を紹介します。 ソリューション概要 ソース RDS インスタンスの変更をニアリアルタイムにキャプチャするために AWS DMS を使用し、CDC レプリケーションの宛先として Amazon Kinesis Data Streams を使用します。AWS Glue ストリーミングジョブは Kinesis Data Streams から変更されたレコードを読み込んでエンリッチし、Apache Hudi フォーマットで S3 データレイクにアップサートします。これにより、 Amazon Athena でデータをクエリし、 Amazon QuickSight で可視化することは可能になります。AWS Glue は、Apache Hudi ベースのテーブルにストリーミングデータの継続的な書き込み操作をネイティブにサポートしています。 以下の図は、この投稿で使用されたアーキテクチャを示しています。 AWS CloudFormation テンプレートも提供します。 前提条件 始める前に、以下の前提条件があることを確認してください： AWSアカウント Amazon S3の基本的な理解 ダッシュボードを作成するためのQuickSightの基本的な理解 Amazon RDSデータベース、AWS DMSインスタンスとタスク、Kinesisデータストリーム、S3バケット、AWS Glueジョブ、AWS Glueデータカタログ、およびQuickSightダッシュボードを作成し、Athenaを使用してSQLクエリを実行するための権限を持つ AWS Identity and Access Management（IAM） ロール（ IAMアイデンティティ権限の追加と削除 を参照してください。） ソースデータ概要 今回は ticket_activity テーブルを使用してスポーツイベントのほぼリアルタイムのデータを分析することに興味があるデータアナリスト向けのユースケースを想定します。このテーブルの例を次のスクリーンショットに示します。 Apache Hudi connector for AWS Glue この投稿では、Hudi フレームワークをネイティブサポートしている AWS Glue 4.0 を使用します。Hudi はオープンソースのデータレイクフレームワークで、 Amazon S3 上に構築されたデータレイク におけるインクリメンタルなデータ処理を簡素化します。タイムトラベルクエリ、ACID（原子性、整合性、分離性、永続性）トランザクション、ストリーミングデータ取り込み、CDC、アップサート、および削除などの機能が利用できます。 AWS CloudFormation を用いてリソースセットアップ 迅速なセットアップのために CloudFormation テンプレート が用意しました。ご自身のニーズに合わせて見直してカスタマイズすることができます。 CloudFormation テンプレートは以下のリソースを生成します： RDS データベースインスタンス（ソース） AWS DMS レプリケーションインスタンス、ソーステーブルから Kinesis データストリームにデータをレプリケートするために使用します Kinesis データストリーム 4つの AWS Glue Python シェルジョブ： rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; – Amazon RDS 上に ticket_activity というソーステーブルを 1 つ作成します rds-ingest-data-initial-&lt;CloudFormation Stack name&gt; – Faker ライブラリでサンプルデータがランダムに自動生成され、 ticket_activity テーブルにロードされます rds-ingest-data-incremental-&lt;CloudFormation Stack name&gt; – 新しいチケットアクティビティデータを継続的にソーステーブル ticket_activity に取り込みます。このジョブは顧客のアクティビティをシミュレートします rds-upsert-data-&lt;CloudFormation Stack name&gt; – ソーステーブル ticket_activity に特定のレコードをアップサートします。このジョブは管理者の活動をシミュレートします AWS Identity and Access Management（IAM） のユーザーとポリシー Amazon VPC、パブリックサブネット、2つのプライベートサブネット、インターネットゲートウェイ、NAT ゲートウェイ、ルートテーブル プライベートサブネットは、RDS データベースインスタンスと AWS DMS レプリケーションインスタンスのため作られます NAT ゲートウェイは、AWS Glue の Python シェルジョブから Python 用 MySQL コネクタを使用するために pypi.org への到達性を確保するために使用します。また、Kinesis Data Streams と Amazon S3 API エンドポイントへのアクセスも可能ようにします これらのリソースをセットアップするには、以下の前提条件が必要です： まずは、IAM ロール dms-vpc-role 、 dms-cloudwatch-logs-role 、 dms-access-for-endpoint が必要になります。AWS DMS を使用したことがない場合は、IAM コンソールまたは AWS コマンドラインインターフェイス（AWS CLI） を使用して、これらの特別な IAM ロールを作成する必要があります。手順については、 AWS CLI および AWS DMS API で使用する IAM ロールの作成 を参照してください AWS Lake Formation コンソールの Data Catalog settings ページで、 Use only IAM access control for new databases と Use only IAM access control for new table in new databases の選択を既に解除している場合は、この2つのチェックボックスを再度選択し、設定を保存する必要があります。詳細については、 データレイクのデフォルト設定の変更 を参照してください 以下の図は、プロビジョニングされたリソースのアーキテクチャを示しています。 以下の手順で CloudFormation スタックを起動します： AWS CloudFormation コンソールにサインインします Launch Stack を選択します Next を選択します S3BucketName には、新しいS3バケットの名前を入力します VPCCIDR には、既存のネットワークと競合しない CIDR IP アドレス範囲を入力します PublicSubnetCIDR には、 VPCCIDR に指定した CIDR 内の CIDR IP アドレス範囲を入力します PrivateSubnetACIDR と PrivateSubnetBCIDR には、 VPCCIDR で指定した CIDR 内の CIDR IP アドレス範囲を入力します SubnetAzA および SubnetAzB には、使用するサブネットを選択します DatabaseUserName には、データベースユーザー名を入力します DatabaseUserPassword には、データベース・ユーザーのパスワードを入力します Next を選択します 次のページで、 Next を選択します 最後のページで詳細を確認し、 I acknowledge that AWS CloudFormation may create IAM resources with custom names をチェック入れます Create stack を選択します スタックの作成には約 20 分かかります 初期ソーステーブルの設定 AWS Glueジョブ、 rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; は、RDS データベースインスタンス上に event というソーステーブルを作成します。Amazon RDS で初期ソーステーブルをセットアップするには、以下の手順を実行します： AWS Glue のコンソールで、ナビゲーションペインの Jobs を選択します。 rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; を選択し、ジョブを開きます。 Run をクリックします Runs タブに移動し、 Run ステータスが SUCCEEDED と表示されるのを待ちます。 This job will only create the one table, ticket_activity , in the MySQL instance (DDL). See the following code: CREATE TABLE ticket_activity ( ticketactivity_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, sport_type VARCHAR(256) NOT NULL, start_date DATETIME NOT NULL, location VARCHAR(256) NOT NULL, seat_level VARCHAR(256) NOT NULL, seat_location VARCHAR(256) NOT NULL, ticket_price INT NOT NULL, customer_name VARCHAR(256) NOT NULL, email_address VARCHAR(256) NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL ) 新しいレコードの取り込み このセクションでは、新しいレコードの取り込み手順を詳しく説明する。以下の手順でジョブを実行します。 AWS DMS を使用した Kinesis Data Streams へのデータ取り込みの開始 Amazon RDS から Kinesis Data Streams へのデータ取り込みを開始するには、以下の手順を実行します： AWS DMS コンソールで、ナビゲーションペインの データベース移行タスク を選択します。 タスク rds-to-kinesis-&lt;CloudFormation Stack name&gt; を選択します。 アクション メニューで、 開始/再開 を選択する。 ステータス が Load complete および Replication ongoing と表示されるまで待ちます。 AWS DMS レプリケーションタスクは、Amazon RDS から Kinesis Data Streams へ継続的にデータを取り込みます。 Amazon S3 へのデータ取り込み 次に、Kinesis Data Streams から Amazon S3 へのデータ取り込みを開始するために、以下の手順を実行します： AWS Glue コンソールで、ナビゲーションペインの Jobs を選択します。 streaming-cdc-kinesis2hudi-&lt;CloudFormation Stack name&gt; を選択してジョブを開きます。 Run を選択します。 Runs タブで実行状況を確認し、 Running と表示されるのを待ちます。 Amazon RDS 上のソーステーブルへのデータロード Amazon RDS 上のソーステーブルへのデータ取り込みを開始するには、以下の手順を実行します： AWS Glue コンソールで、ナビゲーションペインの Jobs を選択します。 rds-ingest-data-initial-&lt;CloudFormation Stack name&gt; を選択して、ジョブを開きます。 Run を選択します。 Runs タブに移動し、 Run ステータス が SUCCEEDED と表示されるのを待ちます。 取り込んだデータの検証 ジョブの開始から約 2 分後、データは Amazon S3 に取り込まれるはずです。Athena に取り込まれたデータを検証するには、以下の手順を実行します： Athena コンソールで、初めて Athena クエリを実行する場合、以下のステップを完了します： 設定 タブで 管理 を選択します。 Athena がクエリ結果を保存するS3 パスを指定します。 保存 を選択します。 Editor タブで、テーブルに対して以下のクエリを実行し、データをチェックします： SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" limit 10; AWS CloudFormation は下記のような実行環境のアカウント ID を名前に入れ込んだデータベースを作成します database_&lt;your-account-number&gt;_hudi_cdc_demo 。 既存のレコードを更新する 既存のレコードを更新する前に、 ticket_activity テーブルからレコードの ticketactivity_id 値をメモしてください。Athena を使って以下の SQL を実行してください。この投稿では、例として ticketactivity_id = 46 を使用します： SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" limit 10; リアルタイムのユースケースをシミュレートするには、RDS データベースインスタンスのソーステーブル ticket_activity のデータを更新し、更新されたレコードが Amazon S3 にレプリケートされることを確認します。次の手順を実行します： AWS Glue のコンソールで、ナビゲーションペインの Jobs を選択します。 rds-ingest-data-incremental-&lt;CloudFormation Stack name&gt; を選択し、ジョブを開きます。 Run を選択します。 Runs タブを選択し、 Run status が SUCCEEDED と表示されるのを待ちます。 ソーステーブルのレコードをアップサートするには、以下の手順を実行します： AWS Glue のコンソールで、ナビゲーションペインの Jobs を選択します。 ジョブ rds-upsert-data-&lt;CloudFormation Stack name&gt; を選択します。 Job details タブの Advanced properties の Job parameters で、以下のパラメータを更新します： Key に –ticketactivity_id を入力します。 Value には 1 を上記で指定したチケット ID の 1 つ（この記事では 46）に置き換えてください。 Save を選択します。 Run を選択し、 Run status が SUCCEEDED と表示されるのを待ちます。 この AWS Glue Python シェルジョブは、チケットを購入する顧客のアクティビティをシミュレートします。ジョブの引数. --ticketactivity_id で渡されたチケット ID を使用して、RDS データベースインスタンスのソーステーブル ticket_activity のレコードを更新します。これは ticket_price=500 と updated_at を現在のタイムスタンプで更新します。 Amazon s3 に取り込まれたデータを検証するために、Athena から同じクエリを実行し、先ほどの ticket_activity の値をチェックし、 ticket_price と updated_at フィールドを観察します。 SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" where ticketactivity_id = 46 ; QuickSight でデータ可視化 AWS Glue ストリーミングジョブによって生成された出力ファイルを S3 バケットに入れたら、QuickSight を使って Hudi データファイルを可視化することができます。QuickSight は、クラウド用に構築されたスケーラブルでサーバーレス、組み込み可能な ML を利用したビジネスインテリジェンス（BI）サービスです。QuickSight を使えば、ML を活用した洞察を含むインタラクティブな BI ダッシュボードを簡単に作成、公開することができます。QuickSight ダッシュボードは、あらゆるデバイスからアクセスでき、アプリケーション、ポータル、ウェブサイトにシームレスに組み込むことができます。 QuickSight ダッシュボードの作成 QuickSight ダッシュボードを構築するには、以下の手順を実行します： QuickSight コンソールを開きます。 QuickSight のウェルカムページが表示されます。QuickSight にサインアップしていない場合は、サインアップ・ウィザードを完了する必要があります。詳細については、 Amazon QuickSight サブスクリプションのサインアップ を参照してください。 サインアップ後、QuickSight は “ようこそウィザード “を表示します。短いチュートリアルを表示することも、閉じることもできます。 QuickSight コンソールでユーザー名を選択し、 QuickSight を管理 を選択します。 セキュリティとアクセス権限 を選択し、 管理 を選択します。 Amazon S3 を選択し、先ほど AWS CloudFormation で作成したバケットを選択します。 Amazon Athena を選択します。 Save を選択します。 QuickSight はリージョンを意識せずご利用いただけますが、後続の操作を行う前に、AWS Glue 等で使用したリージョンに戻してください。 データセットの作成 QuickSight を起動して実行できるようになったので、データセットを作成できます。以下の手順を実行します： QuickSight コンソールのナビゲーションで データセット を選択します。 新規データセット を選択します。 Athena を選択します。 データソース名 には名前を入力します（例：hudi-blog）。 Validate を選択肢します。 検証が成功したら、 Create data source を選択します。 データベース は、 database_&lt;your-account-number&gt;_hudi_cdc_demo を選択します。 テーブル で ticket_activity を選択します。 Select を選択します。 Visualize を選択します 時間、 ticket_activity_id の順に選択すると、時間ごとの ticket_activity_id のカウントを取得できます。 後片付け 料金が発生しないようにこのソリューションを環境内でテスト目的で使用していた場合は、以下の手順で後片付けます： AWS DMS レプリケーションタスク rds-to-kinesis-&lt;CloudFormation Stack name&gt; を停止します。 RDS データベースに移動し、 変更 を選択します。 削除保護を有効にする の選択を解除し、 続行 を選択します。 AWS Glue のストリーミングジョブ streaming-cdc-kinesis2redshift-&lt;CloudFormation Stack name&gt; を停止します。 CloudFormation スタックを削除します。 QuickSight ダッシュボードで、ユーザー名を選択し、 QuickSightを管理 を選択します。 アカウント設定 を選択し、 アカウントの終了 を選択します。 アカウントの終了 を選択して確認します。 確認 を入力し、 アカウントを削除 を選択します。 まとめ この投稿では、Apache Hudi ベースのほぼリアルタイムのトランザクションデータレイクを作成するために、AWS Glue ストリーミングジョブを使用して、新しいレコードだけでなく、リレーショナルデータベースから更新されたレコードも Amazon S3 にストリーミングする方法を示しました。このアプローチによって、Amazon S3 でアップサートのユースケースを簡単に実現できます。また、QuickSight と Athena を使って Apache Hudi のテーブルを可視化する方法も紹介した。次のステップとして、大容量データセット用の Apache Hudi パフォーマンスチューニングガイド を参照してください。QuickSight でのダッシュボードのオーサリングの詳細については、 QuickSightダッシュボード作成体験ワークショップ（日本語） 、 QuickSight オーサーワークショップ（英語） をご覧ください。 翻訳はソリューションアーキテクトの Rui Lee が担当しました。原文は こちら です。

このブログは、Gergely Cserdi と Akshay Parkhi が共同執筆しました。 はじめに SAP は 2027 年までに SAP HANA 以外のデータベースに対する 一般的なサポート を終了するため、近い将来、 SAP HANA は SAP システムの新規導入における唯一の選択可能なデータベースになります。特に多数の HANA インスタンスを運用しているお客様にとって、TCO を削減するためには、一貫性のある自動化された方法でデータベースのパッチを適用することが重要です。 多くの場合、HANA ノード間では HANA System Replication (HSR) が有効になっています。これを Pacemaker クラスタと組み合わせると、お客様のデータベースは HA アーキテクチャを実現できます。このような方法でデータベースをクラスタ化すると、HANA データベースにパッチを適用する nZDT (ほぼゼロのダウンタイム) 方式のメリットを受けることができます。このブログでは、クラスタ化された HANA ノードに nZDT パッチを適用する方法について説明し、Red Hat Enterprise Linux (RHEL) ベースのシステムでプロセス全体を自動化する Ansible プレイブックのサンプルも紹介します。 パッチ適用処理中のほとんどの時間においては、データベースは少なくとも 1 つのノードで使用が可能な状態です。クラスタを使用しない場合のパッチ適用については、SAP ヘルプサイトにかなり詳しく記載されていますが、HANA ノードがクラスタ構成の場合に nZDT パッチを実行する方法に関する情報は限られています。 図 1: ペースメーカーを使用した 2 ノードの HANA クラスタ構成 前提条件: 稼働中の HANA HSR クラスタペア ( AWS Launch Wizard を使えば、数時間で、完全に自動的に SAP HANAのクラスタ構成の構築ができます。詳細に関しては、 AWS Launch Wizard&nbsp; ユーザガイド をご参照ください。) HANA パッチを適用する前に、必要な OS パッチ (ある場合) が適用されていること。詳細については、以下の情報をご確認ください。 OS に関して、BYOS の場合は“Red Hat Enterprise Linux for SAP Solutions”、またはAWS Marketplace の場合は“Red Hat Enterprise Linux for SAP with High Availability and Update Services” が必要です。サポートされている OS については、 OSS ノート 1631106 をご参照ください。また、Red Hat Enterprise Linux for SAP ソリューションサブスクリプションの ナレッジベース を参照することもできます。 root パスワードが必要で、まつ両方のノードで同じパスワードになっていることが必要です。この点に関するサポートが必要な場合は、チームの Linux 管理者に問い合わせてください。 SYSTEMDB と TENANT のために SYSTEM ユーザパスワードが必要です。この点に関しては、チームのデータベース管理者に問い合わせてください。 使用可能な Ansible インフラストラクチャーをお持ちで、HANA ノードでプレイブックを実行するように設定されていること。 必要な HANA のパッチパッケージが S3 バケットにあるか、ファイルシステムに保存されていること。 (オートメーション処理は両方からファイル取得可能) SAP HANA パッチソフトウェアは SAP Marketplace ソフトウェアダウンロードセンター からダウンロードします。(ダウンロードエリアにアクセスするには SAP Marketplace アカウントが必要) パッチファイルが Amazon S3 バケットに保存される場合、Amazon EC2 には、該当のバケットにアクセスできる IAM ロールが付与されていること。 手順 nZDT メソッドで HANA クラスタノードにパッチを適用する一般的なプロセスは以下になります。この例では、ノード 1 が現在プライマリノードで、ノード 2 がセカンダリノードであると仮定します。 * 注意 : 作業順番を守ることは重要です。 クラスタノード 2 をスタンバイモードに設定 スタンバイモードを有効にすると、指定したノードはリソースをホストできなくなります。制約が許せば、そのノードで現在アクティブなリソースがあれば、別のノードに移動されます。この場合、HANA インスタンスはセカンダリ役割であり、現在使用されているクラスタノード 1 はすでにプライマリインスタンスとなっているため、リソースはクラスタノード 1 に移動されません。 クラスタをメンテナンスモードに設定 クラスタ全体をメンテナンスモードにすると、クラスタがクラスタリソースを一切管理しなくなります。HANA のパッチ適用中に HANA サービスが断続的に停止し、そうしなけれ場クラスタが動作する可能性があるため、これは不可欠です。 ノード 2 の HANA パッチ適用 セカンダリノードで HANA にパッチを適用します。このステップは、データベースのソフトウェアバージョンを更新するための中心的な部分です。 図 2: セカンダリノードの HANA パッチ適用 パッチ適用プロセス中、セカンダリノードは一定期間使用できなくなります。ただし、プライマリノードは通常どおり稼働しており、SAP アプリケーションとユーザーにサービスを提供します。 ノード 2 をスタンバイモードから解除 このステップでは、クラスタノード 2 がクラスタで再び使用可能になり、リソースを受け入れられます。 クラスタのメンテナンスモードをオフ メンテナンスモードを無効にすると、クラスタはプライマリノードとセカンダリノードの間の HSR を自動的に再確立します。SAP はセカンダリノードをプライマリノードよりも高いパッチレベルに設定することをサポートしています。セカンダリノードはプライマリノードと同期される状態になります。 レプリケーションが再開され、正常に動作 この段階では、セカンダリノードがプライマリノードと完全に同期し、引き継ぐ準備が整うまで待つ必要があります (ステータス SOK)。 ノード 1 をスタンバイモードに設定 スタンバイモードでは、プライマリクラスタノードはリソースをホストできなくなり、プライマリ HANA の役割がノード 1 からノード 2 に引き継がれます。クラスタは現在のプライマリノードを降格させ、ノード 2 の HANA インスタンスを昇格させます。また、クラスタはオーバーレイ IP をノード 2 に移動し、ルートテーブルの更新を行います。これにより、SAP を引き継いだ後も、ユーザーは引き続き先の HANA データベースに接続できます。 図 3: テイクオーバー処理中にセカンダリノードが昇格 テイクオーバーが完了するまで待機 テイクオーバー処理には少し時間がかかります。ノード 1 にパッチを適用する前に、ノード 2 の HANA インスタンスが完全にプライマリ役割を引き継いでいることを確認する必要があります。 クラスタをメンテナンスモードに設定 クラスタがパッチ適用プロセスの妨げにならないようにするには、クラスタ全体をメンテナンスモードにする必要があります。 ノード 1 の HANA パッチ適用 この段階では、HANA DB はノード 2 でプライマリとして実行されており、SAP システムからの接続とユーザーからの接続を受け入れます。ノード 1 の HANA インスタンスにパッチを適用できるようになりました。 図 4 元のプライマリであったノード1へのパッチ適用し、現在はセカンダリノードがプライマリ役割 ノード 1 をスタンバイステータス解除 ノード 1 のパッチ適用が完了したら、スタンバイ状態から外すことで、クラスタノードとして再び有効にできます。 クラスタのメンテナンスモードをオフ クラスタがメンテナンスモードを終了すると、クラスタノード 1 で HANA インスタンスが起動していることを確認します。現在、クラスタノード 2 の HANA インスタンスにはプライマリ役割があるため、クラスタノード 1 の HANA インスタンスはセカンダリ役割として起動され、ノード 2 からノード 1 へのレプリケーションが開始されます。 図 5: パッチを適用した HANA ノード間で HSR を再確立 クラスタリソースを消去 メンテナンス作業中に、クラスタフレームワークでエラーやアラートが発生することがあります。クラスタを最初からやり直すには、これらをクリーンアップする必要があります。 まとめると、パッチ適用プロセス中は、テイクオーバー発生時に短時間停止する場合を除いて、常に少なくとも 1 つのノードでデータベースが使用可能である必要があります。注:プライマリとセカンダリは、最後に入れ替わります。これは正常であり、データベースの動作には影響しません。都合の良いときに元のトポロジーに 切り戻す ことができます。 プロセス全体を自動化する Ansible プレイブックのサンプルコードは、この 公開 github リポジトリ にあります。 Ansible プレイブックを実行するための準備 ターゲット HANA パッチ SAR ファイルを SAP Marketplace からダウンロードし、S3 バケットまたはサーバーのファイルシステムに配置します。S3 バケットまたはディレクトリに 1 つの SAR パッチファイル以外のファイルが含まれていないことを確認してください。以下は、パッチ HANA SP05 rev64 の SAR ファイルを格納している S3 バケットの例です。 図 6: HANA SAR ファイルを格納する Amazon S3 バケット リポジトリを Ansible コントローラーサーバーにコピー リポジトリをコピーする 1 つの方法は、git clone コマンドを使用することです。git コマンドに関しては参考情報のセクションをご確認ください。そのためには、まず git をインストールする必要があります。Linux への インストール方法 をご覧ください。 コピーしたリポジトリのディレクトリにアクセスし、インベントリファイルを作成し、「SAP_ &lt;SID&gt;_hana_ha」という名前のグループを作り、そのグループに 2 つの HANA ノード IP を追加します。たとえば、HANA SID が「HDB」、HANA ノード 1 の IP が 10.20.30.40、HANA ノード 2 の IP が 10.20.30.50 の場合、インベントリファイルの内容は次のようになります。 [SAP_HDB_hana_ha] 10.20.30.40 10.20.30.50 自動化ツールHANA パッチツール hdblcm を実行するには、複数の認証情報が必要になります。セキュリティ上のベストプラクティスとして、可変ファイルやその他の方法でパスワードを簡単に開示できないようにしてください。Ansible は、機密情報の暗号化に役立つ ansible-vault ツールを提供しています。HANA パッチを適用する Ansible プレイブックソリューションでは、以下の認証情報を含む「passvault.yml」というボールトファイルが必要です。 root ユーザパスワード 変数名: ROOTPWD &lt;sid&gt;adm ユーザパスワード 変数名: SIDADMPWD SYSTEM @ テナントパスワード 変数名: SYSTEMTNTPWD SYSTEM @ SYSTEMDB パスワード 変数名: SYSTEMDBPWD これらの認証情報を「passvault.yml」ファイルに追加すると、変数名や暗号化された値が格納されます。 たとえば、暗号化された root パスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。 ansible-vault encrypt_string ‘theactualpassword’ --name ‘ROOTPWD’ | tee -a passvault.yml 別の例として、SYSTEM DB の SYSTEM ユーザーの暗号化されたパスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。 ansible-vault encrypt_string ‘somepassword’ --name ‘SYSTEMDBPWD’ | tee -a passvault.yml パスワード変数を追加するときは、暗号化に同じボールトパスワードを使用してください。暗号化されたパスワードをすべて追加したら、ファイルの新しい行から始まるようにしてください。必要なパスワードをすべて追加すると、ファイルは次のようになるはずです。 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# cat passvault.yml SYSTEMDBPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 35643964393039616161626666353862653038373434613533313566353134376364643337666539 6436623736323161613031663636356162633362353831620a393365646636653837636633623164 32623365313931303939323532393265613565643965393538393737353436366330636233646330 3265663163636366340a633734306136313839366431616562666162386633353035393764313833 3137 SYSTEMTNTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 39613736376436396361383939313637623435326232656163353863383138633230326166666334 3733653737646431373261313434353065646431343037370a333963643230313565653264643831 36393332386266333438326639346539316330303331393464663539653864353834656665346264 3134306666623765640a303733383031376131613438396436393334636166386233633966396432 3232 ROOTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 30323033336466663837623064343631376634316534316165316438306635636562633164653266 3331663837303932346237643165353062656165356562300a626363373134663635313962303363 37323531633737656239356438613838343665353530313939356530616631623561623733643236 6138653361316265650a386561366330303832346235383035346363633463663035383131623732 3438 SIDADMPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 63633035656533316432353435376433393565623066643735326165313137396633323132363730 3562623132356439613533633536323563333738373931650a623964323966386634616466376631 37386564666337626630333338666264666365616263366531306162636539366461386135663263 3334373437643763380a316238373335653636323564363139376562616130396164613932633938 3361 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# ファイルの設定が完了したら、次の手順に進みます。 プレイブックを実行 ディレクトリをコピーしたリポジトリのルートに切り替え、以下のコマンドを実行します。 ansible-playbook -i &lt;inventoryfile&gt; --ask-vault-pass -e "SID=&lt;SID&gt;" -e "MEDIASRC=&lt;s3/fs&gt;" -e "MEDIALOC=&lt;locationofSARfile" ./patch_sap_hana.yml たとえば、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースが S3 バケット「s3://hanapatch/」にある場合は、次の構文を使用します。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=s3" -e "MEDIALOC=s3://hanapatch/" ./patch_sap_hana.yml 別の例として、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースがファイルシステムから、SAR ファイルが /tmp/hanapatch/ にある場合は、次の構文を使用してください。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=fs" -e "MEDIALOC=/tmp/hanapatch/" ./patch_sap_hana.yml 自動化処理は、前述で説明した順序でノードにパッチを適用します。パッチ適用処理が終了すると、ノードの役割が入れ替われることに注意してください。ノードの元のロールは後でいつでも元に切り戻すことができます。パッチが適用されたことを確認するには、Ansible ログの末尾にある各 HANA ノードの新しいパッチバージョンを確認できます。 クリーンアップ Playbook が正常に実行されると、パスワードテンプレートファイルは自動的にクリーンアップされます。 プレイブックを実行した後も、再び必要になった場合に備えて、ソフトウェアは引き続き使用できます。不要になった場合は、アーカイブするか、単純に削除することをおすすめします。 コスト 2 つの HANA ノードのコスト以外に、自動化には Amazon EC2 インスタンス上で稼働する小さな Ansible 管理ノードが必要な場合があります。 HANA のパッチファイルを保存するために S3 バケットが必要です。一般的なパッチファイルは約 3 ～ 4 GB で、これは年間わずか数ドル (0.023$/GB /月) に相当します。 他の展開 SAP HANA HSR の概念 について詳しくは、SAP 公式ヘルプドキュメントをご覧ください。 HANA HSR に関するよくある質問に対するその他の回答については、 SAP Note 1999880 — FAQ: SAP HANA システムレプリケーションをご覧ください。 RHEL 上の HANA 用 SAP ペースメーカークラスタの詳細については、公式の SAP HANA on AWS ガイド をお読みください。 AWS 無料利用枠サービスを活用して、最小限のコストで SAP on AWS で Ansible を使用する方法を学ぶのに役立ちます。Amazon Linux 2 では AWS 無料利用枠 を使用して EC2 インスタンスを作成できます。このインスタンスは Ansible 管理ノード を実行するのに使用できます。 Ansible モジュールとコーディング技術について詳しくは、ansible の 公式ドキュメント をご覧ください。 結論 この例では、クラスタ化された HANA ノードの nZDT パッチ処理がどのようなものかを説明しました。また、プロセスを自動化する例の方法として、 Ansible プレイブックも提供しました。 図 7:&nbsp; nZDT HANA のパッチ適用プロセス全体の概要ステップ AWS は HANA パッチ適用を自動化するための AWS Systems Manager ドキュメント (SSM ドキュメント) もサポートしていますが、クラスタノードはまだサポートされていないことに注意してください。 SLES ベースのシステムには、考え方は同じです。pcs コマンドをそれぞれ crm コマンドに置き換えるか、YAST モジュールを使用して処理することが可能です。 今後のアクション AWS Launch Wizard for SAP を使用して新しい HANA クラスタ構成を構築してみましょう。まず、 オンラインドキュメント をご確認ください。 無料利用枠の Amazon インスタンスに ansible をインストールし、公開リポジトリからサンプルコードのクローンを作成します。 HANA クラスタノードのロールを確認し、パッチを適用する前に HANA DB のバージョンを確認してください。 インベントリファイルと passvault.yaml ファイルを準備し、パッチ適用プレイブックを起動します。 HANA クラスタノードの役割をもう一度確認し、パッチ適用後に HANA DB のバージョンを確認します。現在、どのノードがプライマリになっているのかでしょうか？ 不要なコストを避けるため、テスト後は必ずリソースをクリーンアップしてください。 リファレンス 公式 SAP ページにある SAP HANA システムレプリケーションによる SAP HANA システムのアップデート Near Zero Downtime Upgrades のために、SAP HANA システムレプリケーションの使用 AWS Launch Wizard YAST モジュールを使用した HANA クラスタの SLES nZDT パッチ適用 Git クローンコマンドの リファレンス 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

AWS Launch Wizard for SAP API による SAP 環境構築の自動化 AWS Launch Wizard は、オンプレミスで数週間から数カ月かかる HANA ベースの SAP アプリケーションの環境構築を、わずか数時間で、安全で高性能、復元力があり、効率的に、AWS に構築するための完全に自動化されたプロセスをお客様に提供します。AWS Launch Wizard for SAP サービスは、 AWS 、SAP、および使う OS のベストプラクティスに従って、SAP アプリケーションと SAP HANA データベースのインストールと設定に必要なすべての AWS リソースをプロビジョニングします。 Nvidia 、 UNOX 、 Storengy などのお客様は、AWS Launch Wizard を利用して SAP 環境の移行を加速させています。 2020 年 4 月のサービス一般提供開始以来、AWS for SAP チームはお客様やパートナー様からのフィードバックに耳を傾け、AWS Launch Wizard サービスを継続的に改善してきました。そのフィードバックに基づいて、SAP アプリケーションソフトウェアの自動構築、構築前/構築後のスクリプトによるカスタマイズされたデプロイ、AWS サービスカタログとの統合など、いくつかの重要な改善を行いました。さらに、Launch Wizard チームは、AWS、SAP、およびオペレーティングシステムの最新機能を活用した新機能を継続的に提供しています。これにより、SAP アプリケーションのあらゆる階層で最新のイノベーションを活用することができ、お客様の投資が将来にわたって保護されます。 お客様から最も要望の多かった機能の 1 つは、AWS Launch Wizard を既存の導入ツールやスクリプトと統合できることです。お客様がアプリケーション・プログラミング・インターフェース・コール（API）を使用して、AWS管理コンソールにログインすることなく、プログラマティックでSAPシステムをデプロイできるようになったことを11月初旬に 発表 しました。 このブログでは、SAP S/4HANA システムをプログラマティックでデプロイが可能にする新しい AWS Launch Wizard API について詳しく説明します。 AWS Launch Wizard API 概要 AWS Launch Wizard API を使用すると、以下のアクションが実行可能となります。 CreateDeployment: 指定された設定でワークロードをデプロイします。 ListDeployments: 作成されたデプロイメントを一覧表示します。 GetDeployment: 特定のデプロイメントに関する詳細情報を取得します。 DeleteDeployment:特定のデプロイメントを削除します。 ListDeploymentEvents:デプロイ中に実行されているすべてのアクションを一覧表示します。 ListWorkloads: AWS Launch Wizard がサポートしている利用可能なすべてのワークロードを一覧表示します。 ListWorkloadDeploymentPatterns: 特定のワークロードのすべてのデプロイパターンを一覧表示します。 GetWorkload: 特定のワークロードに関する詳細情報を取得します。 デプロイメントの仕様 デプロイ仕様は、ニーズに応じてアプリケーションをデプロイするための情報提供に使用します。デプロイ仕様で、Amazon Virtual Private Cloud、サブネット、セキュリティグループなどのインフラストラクチャ関連の仕様や、構築予定の SAP システムの SID、SAP ソフトウェアおよびバージョンなどのアプリケーション仕様を提供します。 こちらのURL に記載されているように、サポートされているデプロイパターン毎に、異なる仕様が必要となります。AWS Launch Wizard API は、SAP HANA データベースと NetWeaver ベースのアプリケーションの以下のデプロイパターンをサポートします。 SAP HANA SAP HANA データベース、は以下のデプロイパターンがサポートされています。 SAP HANA 高可用性構成 SAP HANA マルチノード SAP HANA シングルノード SAP アプリケーション SAP S/4HANA、SAP S/4 Foundations、SAP Solution Manager、SAP BW/4HANA、NetWeaver ABAP や Java などの SAP NetWeaver ベースのアプリケーションでは、以下のデプロイパターンがサポートされています。 高可用性構成 マルチノード/分散構成 シングルノード/セントラル構成 ユースケース AWS Launch Wizard API の発表により、Launch Wizard サービスが、単なるコンソールベースのサービスから強化されます。これらの API によって、SAP アプリケーションをデプロイするために、オペレータや管理者がコンソールを操作する必要がなくなります。最初のテスト/検証作業を行えば、その後人の操作を全く介在せずにデプロイを実現できます。Launch Wizard API を活用できるユースケースをいくつかご紹介します。 SAP のデプロイをさらにスピードアップ: SAPアプリケーションを迅速にプロビジョニングするために、SID、インスタンス番号、サイジングなどのパラメータを微調整できる自動化ルーチンを構築します。 障害復旧プロセスの最適化: 災害復旧のテスト/イベント中に、ベースラインシステムのプロビジョニングに使用できるテンプレートを構築することで、Launch Wizard API を災害復旧計画の一部として活用できます。これらのテンプレートは DR プロセスに一貫性と再現性をもたらし、コンソールを使用して手動でシステムを導入する際に発生する可能なミスを削減します。 一時的または N+1 ランドスケープ設定: AWS Launch Wizard for SAP API を活用して、一時的なプロジェクト環境または永続的な N+1 環境を立ち上げながら、SAP システムのデプロイプロセスを加速できます。 例：AWS Launch Wizard for SAP API を使用した SAP S/4HANA デプロイ この例では、 AWS Command Line Interface (AWS CLI) を使用して AWS Launch Wizard for SAP API を呼出し、ABAP SAP セントラルサービス (ASCS)、プライマリアプリケーションサーバー (PAS)、SAP HANA データベースを含む SAP S/4HANA システムを、単一の EC2 インスタンスに構築します。 前提条件: AWS アカウント AWS CLI をインストールして設定 (この ドキュメント を参照)。最低限必要なバージョンは AWS CLI バージョン2 です。 AWS Launch Wizard for SAP の一般的な条件と IAM 前提条件を設定完了 (この ドキュメント を参照) SAP アプリケーションとデータベースのインストールメディアをダウンロードして準備 (この ドキュメント を参照) ステップ 1: デプロイメント仕様ファイルの準備 AWS Launch Wizard for SAP API は、JSON 形式のファイルを使用して、通常は AWS コンソールから入力されるデプロイに関する設定値を定義します。デプロイパターンに基づいて、SAP アプリケーションを構成するために必要なパラメータリストについては、 SAP デプロイ仕様 を参照してください。 { "KeyPairName": "ExampleKeyPair", "VpcId": "vpc-a1b2c3d4", "AvailabilityZone1PrivateSubnet1Id": "subnet-11111111aaaaaaaaa", "Timezone" :"PST", "EnableEbsVolumeEncryption" :"Yes", "EbsKmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:alias/aws/ebs", "CreateSecurityGroup" :"No", "DatabaseSecurityGroupId" :"sg-1234567890abcdef0", "ApplicationSecurityGroupId" :"sg-021345abcdef6789", "SidAdmUserId" :"7002", "SapSysGroupId" :"5001", "DatabaseSystemId" :"HYD", "SapSid" :"S4K", "ApplicationDataVolumeType" :"gp2", "DatabaseInstanceNumber" :"30", "InstallAwsBackintAgent" :"Yes", "BackintSpecifications": "{\"backintBucketName\":\"launchwizardsoftware\",\"backintBucketFolder\":\"HANABackintBucketFolder\",\"backintBucketRegion\":\"us-east-1\",\"backintKmsKeyArn\":\"arn:aws:kms:us-east-1:111122223333:alias/aws/s3\",\"backintAgentVersion\":\"2.0.2.732\",\"backintContinueOnFailure\":\"No\",\"backintCreateEbsVolume\":\"No\"}", "CentralSystemOperatingSystem" :"SuSE-Linux-15-SP2-For-SAP-HVM", "CentralSystemAmiId" :"ami-1234567890abcdef0", "CentralSystemInstanceType" :"r5.8xlarge", "CentralSystemHostname" :"apis4sin", "SapPassword" :"EXAMPLE-PASSWORD", "DatabaseLogVolumeType" :"io2", "SetupTransportDomainController" :"Yes", "InstallSap" :"Yes", "SapInstallationSpecifications": "{\"parameters\":{\"PRODUCT_ID\":\"saps4hana-2021\",\"HDB_SCHEMA_NAME\":\"SAPABAP1\",\"CI_INSTANCE_NR\":\"22\",\"ASCS_INSTANCE_NR\":\"20\",\"SAPINST_CD_SAPCAR\":\"s3:\/\/launchwizardsoftware\/sapmedia\/sapcar\",\"SAPINST_CD_SWPM\":\"s3:\/\/launchwizardsoftware\/sapmedia\/swpm\/20-sp10\",\"SAPINST_CD_KERNEL\":\"s3:\/\/launchwizardsoftware\/sapmedia\/kernel\/785\",\"SAPINST_CD_LOAD\":\"s3:\/\/launchwizardsoftware\/sapmedia\/exports\/s4h-2021\",\"SAPINST_CD_RDBMS\":\"s3:\/\/launchwizardsoftware\/sapmedia\/database\/hana-20-sp06-rev60\",\"SAPINST_CD_RDBMS_CLIENT\":\"s3:\/\/launchwizardsoftware\/sapmedia\/hana-client\/20-11\"}, \"onFailureBehaviour\": \"CONTINUE\"}", "SnsTopicArn" :"arn:aws:sns:us-east-1:111122223333:InstallStatus", "SaveDeploymentArtifacts" :"Yes", "DeploymentArtifactsS3Uri" :"s3://launchwizardsoftware", "DisableDeploymentRollback" :"Yes", "CentralSystemAutomaticRecovery": "Yes", "DatabaseDataVolumeType": "gp3" } ステップ 2: デプロイメント仕様の検証 デプロイを実行する前に、 create deployment アクションのオプションの dry-run フラグを使用して仕様を検証し、アクションに必要な権限があるかどうかを確認できます。 // Example command values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json デプロイに問題がない場合は、次のメッセージが表示されるはずです。 // Example JSON response { "deploymentId": "Dry run is successful" } ステップ 3: デプロイを実行開始 dry-run フラグでデプロイ仕様を検証した後、—no-dry-run フラグを使用して実際のデプロイメントを開始します。 // Example command with sample values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --no-dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json 以下に示すようにデプロイメント ID を取得し、後でこの ID をを使用してデプロイメントの進行状況を確認することができます。 // Example JSON response { "deploymentId": "72c26320-6d17-4e55-992c-b3ad8d47331d" } ステップ 4 — デプロイメントのステータスを確認 list-deployment-events アクションを使用してイベントを一覧表示し、デプロイメントのステータスを確認できます。 // Example command values aws launchwizard list-deployment-events \ --deployment-id 72c26320-6d17-4e55-992c-b3ad8d47331d \ --region us-east-1 以下のスクリーンショットは、 list-deployments-events API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deploymentEvents": [ { "name": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "description": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "status": "Completed", "statusReason": "Resource limit validation completed successfully", "timestamp": "2023-10-26T12:18:34.721000-04:00“ }, { "name": "Create resource group", "description": "Creates a resource group with all the application resources", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:32.937000-04:00" }, { "name": "Create secret", "description": "Creates a new secret", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:33.392000-04:00" }, { "name": "Creates the infrastructure for the application deployment", "description": "Creates the infrastructure for the application deployment", "status": "IN_PROGRESS", "statusReason": "", "timestamp": "2023-10-26T12:19:52.694000-04:00" } ] } デプロイメントが正常に完了すると、API コマンド list-deployments を使用してデプロイメントのステータスを取得できます。 // Example command values aws launchwizard list-deployments \ --region us-east-1 以下のスクリーンショットは、 list-deployments API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deployments": [ { "name": "S4HanaSingleTest", "id": "a572f36c-5b06-4fb5-932c-61e684ca3159", "workloadName": "SAP", "patternName": "SapNWOnHanaSingle", "workloadVersionName": "2023-10-26-00-00-00", "status": "COMPLETED", "createdAt": "2023-10-26T22:02:39.413000-05:00" } ] } トラブルシューティング AWS Launch Wizard for SAP のトラブルシューティングについては、 AWS Launch Wizard トラブルシューティングガイド を参照してください。 まとめ このブログでは、AWS Launch Wizard for SAP API を使用して、プログラムで SAP システムを AWS にデプロイする方法について学びました。この新機能を使用することにより、AWS Launch Wizard for SAP コンソールにアクセスしたり、デプロイのステップを手動で画面設定したりする必要がなくなります。詳細については、 AWS Launch Wizard の詳細ページ と ドキュメント をご覧ください。 AWS re: Invent 2023 に参加される方は、 ENT312 — Deploy and optimize SAP on AWS with DevOps で、 AWS Launch Wizard APIを使用して、SAP S/4HANA システムの高可用性構成をいかに簡単に構築、スケーリングできるかをご覧ください。このセッションで、AWS for SAP のエキスパートがプロセスのステップを説明し、AWS での SAP システムの稼働に関する質問にお答えします。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

e コマースサイトは、機敏で正確、そして何よりもユーザーフレンドリーであるべきです。しかし、e コマースサイトの検索パフォーマンスの歴史は、顧客と小売業者のどちらも満足させていない現実を物語っています。 Baymard Institute によると、「全 e コマースサイトのうち 61％ が、 ユーザーの検索語句にそぐわない検索結果を表示している」ため、顧客は新しい検索語句を入力するか、古い検索語句を完全に放棄せざるを得ないのです。 Forrester によると、 「商品の検索体験全体に対するイライラによって、 約 68％ という許容できないほどの解約や離脱を引き起こされている」といいます。 Z 世代がより速く（そしてより正確な）検索結果を求める中、e コマース企業は検索をモダナイズしなければならないという重圧を感じていますが、行動に移している企業はほとんどありません。この失敗をそのままにしてしまうと、イノベーションだけでなく、売上においても競合他社に遅れをとるという深刻なリスクを負うことになります。 このブログでは、なぜ小売業者がキーワード検索の品質のために機会損失してしまうのかと、どのようにして Amazon Web Services（ AWS ）が自然言語処理（ NLP ）を用いて、 e コマース企業の収益向上を支援できるのかを述べます。 キーワード検索の課題 すべてのオンライン顧客が買い物中に検索バーを利用するわけではないですが、50％ 近くは利用しています。 Forrester は、2022 年のロードマップレポート ” Must-Have E-Commerce Features ” にて、「小売ウェブサイトユーザーの 43% は、初めてウェブサイトにアクセスした際に、まずは検索バーで検索することから始める」ということです。このことから、検索結果に重点を置くことは、顧客との関係を維持する上でさらに重要になります。しかしながら、検索結果に重点を置くことはそれほど簡単ではありません。なぜなら、ほとんどの検索エンジンは自然言語を理解しないからです。 例えば、あなたが赤いドレスシャツを探しているとしましょう。あなたはお気に入りのウェブサイトを立ち上げ、検索バーに「男性 赤い ドレスシャツ」と入力します。そうすると、検索エンジンはあなたが書き込んだ内容を理解しようとします。しかし、キーワード検索エンジンは、キーワードをそれぞれ個別の用語としてしか理解できないため、必要な情報以外の入力は、ズレた検索結果を導いてしまう可能性があります。赤いドレスシャツの検索結果の代わりに、検索エンジンは 「ドレスシャツ 」ではなく、ドレスやシャツの検索結果を返すかもしれません。これを変えるには、検索エンジンが検索語句を一つの用語として理解する必要があります。言い換えれば、ユーザーの意図を理解する必要があるのです。 キーワード検索によくある課題として、タイプミス、同義語と方言、特徴検索、フィルター検索、コンテキスト検索、テーマ検索があります。 タイプミス： 検索したい単語を誤ってスペルミスしてしまうことです。例えば、「 sweater 」と入力すべきところを 「 sweeter 」と入力することです。 同義語と方言： 地域によって異なる意味を持つ単語を検索することです。例えば、「 sunglasses 」ではなく、「 shades 」と検索してしまい、全く異なる検索結果を得ることがあります。 例：multi-billion-dollar retailer – 「 mens sunglasses 」の代わりに 「 mens shades 」で検索した結果 特徴検索： ユーザーが特定の特徴を持つ商品を検索することです。例えば、「 strap sandal 」と検索した際に、キーワード検索エンジンが理解できるのはキーワードだけで、ユーザーの意図は理解できないので、商品説明にはサンダルとストラップが使用されていても、検索エンジンは検索語句と同一と認識できず、検索結果は 0 件と返します。 フィルター検索： ユーザーが商品の属性で検索することです。例えば、$ 30 未満のイヤリング、青色の靴下、ポリエステルの椅子張りカバーなどと検索します。 例：multi-billion-dollar retailer – 「 Earrings Under 30 」 の検索結果として関連のないアイテムが表示されてしまう コンテキスト検索： ユーザーが特定の商品ではなく、コンテキストに基づいて何かを検索することです。例えば、「すきま風対策」や「寒さ対策」と検索して、どんな商品が結果に出てくるかを確認するような場合です。コンテキスト検索は、小売業者にとって最も困難なものになります。なぜなら、コンテキスト検索では、ユーザーが存在しないキーワードを検索していることが多く、その結果、検索結果が 0 件になったり、関連した検索結果が 0 件になるからです。 テーマ検索： ユーザーがテーマ別のカテゴリーで商品を検索することです。例えば、特定の種類のラグを探している人は、単に 「ラグ」と検索するのではなく、「廊下用ラグ」と検索するかもしれません。 例：multi-billion-dollar retailer – 「 rug 」 の代わりに 「 hallway rug 」 で検索した結果 Baymard Institute は、「ユーザーの観点では、これらの日常的な表現は業界用語と同じように正しいと思っており、大規模テストの参加者のほとんどは、検索結果が悪かったときに別の類義語を試そうとは思わなかった」と述べています。「その代わりに、検索結果が悪かったり、限定的だったりするのは、そのサイトがそのような商品を選んでいるからだと参加者は単に思い込んでいました。」 機会損失を回避しましょう 顧客と小売業者にとって、検索の問題はイライラさせられるものですし、ショッピング体験の全体的な質を低下させています。しかも、小売業者は、この問題から顧客の体験と企業の財務の両面で悪影響を受けます。もし、顧客が探している商品を見つけられなければ、小売業者は多くの収益を失うことになるからです。 数字を見てみましょう。 Econsultancy の調査によると、e コマースの平均コンバージョン率は 2.77% です。しかし、顧客が検索バーを使って探していた商品を見つけると、平均コンバージョン率は 4.63% に上昇します。これは e コマースの平均コンバージョン率のほぼ 2 倍です。 Amazon.com で検索された場合、この数字はさらに上昇します。毎回 Amazon.com で検索し、探していた商品を見つけると、 コンバージョン率は 6 倍に上昇 します。つまり、かつては 2％ だったコンバージョン率が 12％ になります。このパーセンテージを収益に換算すると、e コマース企業にとって財務的に大きな改善です。 e コマース検索の改善を AWS はどのように支援できるのでしょうか？ AWS は、Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service といった人工知能と機械学習（ AI/ML ）サービスを提供しています。これらのサービスを利用することで、e コマース検索を改善することができます。 Amazon Comprehend は、機械学習を使用してテキストの意味、洞察、つながりを見つける自然言語処理サービスです。このサービスにより、あなたの検索エンジンはキーフレーズ、エンティティ、感情をインデックス化し、検索パフォーマンスを向上させることができます。Amazon Comprehend は時間をかけて学習し、ドキュメント、カスタマーサポートチケット、商品レビュー、メール、ソーシャルメディアへの投稿といったテキスト情報から貴重な洞察を発見します。Amazon Comprehend を使用することで、ユーザーは次のことができるようになります： ビジネスの分析とコールセンターの分析： 顧客アンケートから洞察を引き出し、商品を改善します。 商品レビューのインデックス化と検索： キーワードだけでなく、キーフレーズ、エンティティ、感情をインデックス化した検索エンジンを用いることで、コンテキストに焦点を当てます。 Amazon Kendra は、自然言語を理解する ML ベースのインテリジェント検索エンジンです。このインテリジェントなエンタープライズ検索サービスは、組み込みのコネクタを使用して、さまざまなコンテンツリポジトリを横断して検索することができ、機械学習の専門知識がなくても、ユーザーに高い精度の回答を提供します。 Amazon Textract は、スキャンした文書からテキスト、手書き文字、データを手作業なしで自動的かつ正確に抽出でき、すぐに使える ML サービスです。業種を問わず、データを整理し、元のコンテキストを保ち、出力結果のマニュアルレビューを省くために、Amazon Textract を利用できます。 Amazon OpenSearch Service はオープンソースの分散型検索・分析スイートで、インタラクティブなログ分析、ニアリアルタイムのアプリケーション監視、ウェブサイト検索を実行できます。OpenSearch Service を使用すると、ユーザーはアプリケーション、ウェブサイト、データレイクカタログ内で、高速かつパーソナライズされた検索により、関連するデータをすばやく見つけることができます。 結論 何十億ドルもの売上があるにもかかわらず、小売業者は検索パフォーマンスの低さによって収益を失っています。しかし、そのままにしておくのは勿体ありません。Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service といった AWS サービスを利用することで、この問題を解消することができます。これらのサービスにより、小売業者は強力で改善された検索体験を生み出すことができるため、最終的には、収益の減少ではなく、収益の増加に集中することができます。 AWS の AI/ML サービス を利用して小売業の検索パフォーマンスを改善し、収益を増加させる方法をご覧ください。 消費財業界向けの AWS の取り組みについては こちら から詳細をご覧ください。または、 AWS 担当者 にお問い合わせください。 参考リンク Building Blocks for Modern Retail Ecommerce and Media Search with AWS Amazon OpenSearch Service と Amazon Comprehend を使用したテキスト分析 Building an NLU-powered search application with Amazon SageMaker and Amazon Opensearch Service KNN feature 著者について Aditya Pendyala Aditya はニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。クラウドベースのアプリケーションのアーキテクトとして豊富な経験があります。現在、大企業と協業し、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャの構築を支援するとともに、クラウドに関するあらゆることを案内しています。Shippensburg University でコンピューターサイエンスの理学修士号を取得し、 “When you cease to learn, you cease to grow “という言葉を信条としています。 Siddharth Pasumarthy Siddharth はニューヨークを拠点とする AWS のソリューションアーキテクトです。ファッションやアパレル業界の小売企業の顧客と協業し、クラウドへの移行や最先端技術の導入を支援しています。Indian Institute of Technology で建築学の学士号、Kelley School of Business で情報システムの修士号を取得しました。最新のテクノロジーに精通するだけでなく、芸術にも情熱を注いでおり、余暇にはアクリル画の静物画を制作しています。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。

こちらの Blog は、 Accelerate connected vehicle deployment with the Connected Mobility Solution on AWS &nbsp;を翻訳したものです。 AWS は、オートモーティブクラウド開発者ポータル (ACDP) の追加を含む、 Connected Mobility Solution (CMS) の大幅な改善をお知らせできることを嬉しく思います。本改善には、高度な DevOps 機能、Cloud Formation や Cloud Developer Kit ( CDK ) などのデプロイツール、コネクテッド車両プラットフォーム (CVP) の開発と運用監視の改善に役立つ新しいプラグインとメトリックスが含まれます。重要なのは、 OTA やライフサイクル管理など、車両のリモート機能を、堅牢なコントロールプレーンを通じて、より適切に管理できるようになったことです。 CMS 内の ACDP (下図 1 参照: CMS on AWS — ACDP) は、CVP 開発者の包括的なハブとして機能します。これにより、CVP (下記の図 2: AWS 上の CMS — CVP アーキテクチャ) アセットのコラボレーション、デプロイ、運用を効率化できます。ACDP は、CVP に必要なツール、ドキュメント、指標を統合するように設計されているため、開発者は質の高いソリューションの提供に集中できます。これには、インフラストラクチャモジュール、再利用可能なコードコンポーネントのデプロイ、デプロイ可能なコードアセットの管理が含まれます。 ACDP を使用すると、お客様はコネクテッドカーのコンポーネントをよりシンプルで安全な方法で導入できます。たとえば、ACDP は、わかりやすい車両オンボーディング、データの標準化と保存のための統合データプレーン、データの異常や閾値違反に対する警告システムなどの機能を顧客に提供しています。さらに、ユーザーは車両管理ポータルと車両テレメトリーシミュレーターの恩恵を受けることができます。 図 1 : CMS on AWS — ACDP 図 2 : CMS on AWS — CVP アーキテクチャ モジュール式で直感的な CMS は、スケーラビリティと顧客による使いやすさを考慮して設計されています。これは、お客様がコネクテッドモビリティ機能を安全かつ効率的に導入および管理できるように設計されています。自動車メーカー、サプライヤー、モビリティテクノロジープロバイダーは CMS を使用して、コネクテッドビークルのデータに基づいて車両管理や車両のパーソナライズなどのサービスを提供できます。また、CMS は、開発者エクスペリエンスに重点を置いたプラットフォームエンジニアリングアプローチを通じて、コストの最適化、市場投入までの時間の短縮、開発者の作業負荷の軽減など、自動車業界のお客様が直面する主要な課題にも対処します。 業界レポート によると、このような優れた設計のプラットフォームは、最大 25% のコスト削減、40% の生産性向上、市場投入までの時間の 50% 短縮につながります。 注目すべき例としては、 同様のプラットフォーム を実装したトヨタが挙げられます。トヨタは、市場投入までの時間を大幅に短縮し、年間コストを 500 万ドル以上削減しました。 コストと開発時間を抑えながら、消費者の高まるデジタル期待に応えるため、AWS は新しい CMS を導入しました。AWS 自動車および製造部門のソリューションおよび GTM ディレクターである Bill Foyは、「このソリューションにより、お客様は自社またはパートナーのソリューションを革新し、より効率的にデプロイできるようになります」と強調しています。 CMS on AWS が一般公開されました。開始するには、 AWS Connected Mobility Solution をご覧ください。

お客様がコンタクトセンターを管理しているなら、組織が顧客の信頼とロイヤルティを構築する上でエージェントが重要な役割を果たしていることをご存知でしょう。コンタクトセンターに連絡したことがある人なら、エージェントが複雑な意思決定を導き、必要に応じて迅速かつ正確なソリューションを提供することがいかに重要であるかを知っています。これには時間がかかり、正しく行わないとフラストレーションがたまる可能性があります。 Amazon Connect の生成系 AI 機能 本日、 Amazon Connect の既存の人工知能 (AI) 機能に、 Amazon Bedrock を通じて利用できる大規模言語モデル (LLM) を活用した生成系 AI 機能が加わり、コンタクトセンターが顧客にサービスを提供する方法が劇的に変わったことをお知らせします。LLM は、一般に基盤モデル (FM) と呼ばれる膨大な量のデータについて事前にトレーニングされており、テキストを理解、学習、生成し、インタラクティブな会話を行い、質問に回答し、ダイアログやドキュメントを要約し、レコメンデーションを提供することができます。 Amazon Q in Connect: カスタマーサポートを迅速に行うための推奨される回答とアクション 組織は常に変化しています。こうした組織の変化に対応する高いレベルのパフォーマンスを維持するために、コンタクトセンターはエージェントのオンボーディング、トレーニング、コーチングを継続的に行っています。トレーニングやコーチングを受けたとしても、エージェントは顧客に優れたサービスを提供するために、製品ガイドや組織のポリシーなど、さまざまな情報源を検索しなければならないことがよくあります。これにより、顧客の待ち時間が長くなり、顧客満足度が低下し、コンタクトセンターのコストが増加する可能性があります。 Amazon Q in Connect は、生成系 AI を活用したエージェントアシスタントで、以前は Amazon Connect Wisdom として提供されていた機能を備えています。顧客の意図を理解し、関連する情報源を使用して正確な応答とアクションを行い、エージェントが顧客固有のニーズを伝え、解決するためのアクションをすべてリアルタイムで提供します。2024 年 3 月 1 日まで、Amazon Q in Connect を無料でお試しいただけます。この機能は簡単に有効にでき、Amazon Connect コンソールから始めることができます。 Amazon Connect Contact Lens: 生産性向上のためのコンタクト後の要約生成機能 顧客とのやり取りを改善し、詳細を後で参照できるようにするために、コンタクトセンターのマネージャーは、顧客とのやり取りのたびにエージェントが手動で作成するメモを活用しています。これらのメモには、顧客の問題への対処方法、会話の重要な場面、保留中のフォローアップ項目に関する詳細が含まれています。 Amazon Connect Contact Lens では、生成系 AI を活用したコンタクト後の要約作成が行えるようになり、コンタクトセンターのマネージャーがより効率的にモニタリングできるようになり、コンタクトの質とエージェントのパフォーマンスの向上を支援できるようになりました。例えば、要約を使用して顧客へのコミットメントを追跡し、フォローアップアクションが迅速に完了したことを確認できます。顧客とのやり取りの直後に、Contact Lens は会話を簡潔でまとまりのある要約にまとめることができるようになりました。 Amazon Connect の Amazon Lex: アシスト付きスロット解決 Amazon Lex を使用して、以前よりチャットボット、仮想エージェント、対話型音声応答 (IVR) を構築できました。これにより、顧客は人間のエージェントに話しかけることなく予定を立てることができます。例えば、「自分と 2 人の子供の旅行予約を変更する必要がある」というのは、従来のボットでは数値 (旅行予約に何人いるのか?) を把握して解決するのが難しい場合もあるでしょう。 新しいアシスト付きスロット解決機能により、Amazon Lex はユーザーの発話のスロット値を非常に正確に解決できるようになりました (例えば、3 という正しい数値を使って前の質問に回答するなど)。これは、精度を向上させ、より良い顧客体験を提供する LLM の高度な推論機能によって支えられています。より良いセルフサービス体験を構築するのに役立つ生成系 AI を利用した新しい機能など、 Amazon Lex のすべての機能をご覧ください。 Amazon Connect Customer Profiles: 統一された顧客プロファイルをより迅速に作成して、パーソナライズされた顧客体験を実現 顧客はパーソナライズされたカスタマーサービスエクスペリエンスを期待しています。これを実現するために、コンタクトセンターは顧客の好み、購入状況、やり取りを包括的に理解する必要があります。これを実現するために、コンタクトセンターの管理者は、複数のアプリケーションからの顧客データをマージして、統合された顧客プロファイルを作成しています。これらのアプリケーションにはそれぞれ、さまざまなタイプの顧客データがさまざまなデータストアにわたってさまざまな形式で保存されています。これらのさまざまなデータストアからのデータをつなぎ合わせるには、コンタクトセンターの管理者がデータを理解し、それを整理して統合された形式にまとめる方法を考え出す必要があります。これを実現するために、コンタクトセンターの管理者は何週間もかけて一つの顧客プロファイルにまとめています。 本日より、 Amazon Connect Customer Profiles は LLM を使用して、統合された顧客プロファイルの作成に必要な時間を短縮できます。コンタクトセンターの管理者が Amazon Simple Storage Service (Amazon S3) 、Adobe Analytics、Salesforce、ServiceNow、Zendesk などのデータソースを追加すると、Customer Profiles はデータを分析して、データ形式と内容が何を表し、データが顧客プロファイルとどのように関連しているかを理解します。次に、Customer Profiles は、さまざまなソースからのデータを整理して組み合わせて完全で正確なプロファイルにする方法を自動的に決定します。ほんの数ステップで、マネージャーは顧客プロファイルの確認、必要な編集、設定を完了できます。 Amazon Connect のアプリケーション内、ウェブ、動画機能 組織としては、使いやすく便利で優れたカスタマーサービスを提供したいと考えていることでしょう。この記事の前半で、セルフサービスチャットボットと、それがどのように役立つかについて説明しました。顧客は往々にして、チャットボットを超えて、エージェントとの音声会話を行いたいと思うことがあります。 Amazon Connect には、豊富でパーソナライズされたカスタマーエクスペリエンスを提供するのに役立つアプリ内機能、ウェブ機能、ビデオ機能が搭載されています (詳細については、 Amazon Lex の機能を参照 )。フルマネージド型の通信ウィジェットを使用すれば、数行のコードを記述するだけで、これらの機能をウェブアプリケーションやモバイルアプリケーションに実装できます。これにより、顧客はページを離れることなく、ウェブまたはモバイルアプリケーションからサポートを受けることができます。ビデオは、エージェントのみ、顧客のみ、またはエージェントと顧客の両方が有効化できます。 Amazon Connect SMS: 双方向 SMS 機能 ほとんどの人がモバイルデバイスを所有しており、外出先でもテキストベースのサポートを受けられる柔軟性が重宝されています。コンタクトセンターのリーダーはこのことを知っており、これまで、顧客に双方向の SMS を提供するために、接続されていないサードパーティーのソリューションに頼っていました。 Amazon Connect には現在、コンタクトセンターのリーダーがこの柔軟性を提供できるように、双方向の SMS 機能が搭載されています (詳細については、 Amazon Lex の機能 を参照してください)。これにより、コストのかかるサードパーティーソリューションとの統合なしに、顧客満足度を高め、エージェントの生産性を向上させることができます。SMS チャットは、通話やチャットと同じ設定、 Amazon Connect エージェントワークスペース 、分析を使用して有効にできます。 詳細はこちら Amazon Q in Connect 製品ページ Amazon Amazon Connect の開始方法 ユーザーガイド フィードバックを送信する AWS re:Post for Amazon Connect 、または通常の AWS サポート窓口を通じて – Veliswa 原文は こちら です。

AWS は発足から 3 年目を迎えたデジタル庁と、ガバメントクラウドの加速を継続して支援します 急ピッチでデジタル化を進める日本の政府、自治体、企業、スタートアップ 私たちアマゾン ウェブ サービス（以下、AWS）は、クラウドを中核としたデジタル技術には、社会の課題や困難を突破する力が備わっていると考えています。なぜならば、クラウドによって誰もが高度なテクノロジーと、様々なデータを簡単に利用できる社会を構築することができるからです。私達はこれを、テクノロジーとデータの民主化と呼び、AWS はこれらの民主化を通じて、国民・市民　一人ひとりが、デジタルの恩恵を享受できる、社会の実現に貢献するために、地域社会をより豊かに、そして地球と人々の発展を支える信頼性の高いテクノロジーを提供することを目指しています。そして、日本全体のデジタルトランスフォーメーション（以下、DX）を支援するため、日々活動を行っています。この思いは、政府が進めるビジョンである、全国どこでも 誰もが便利で快適に暮らせる 社会を目指す「 デジタル田園都市国家構想 」に一致するものです。 世界における日本のデジタル競争力の強化、最終的に市民・国民のより良い、心豊かな暮らしの実現のために、日本政府は DX をさらに加速しています。2021 年のデジタル庁創設、行政、教育、医療などのデジタル化、デジタル格差の解消、さらにガバメントクラウドの実現など、急ピッチでデジタル化を進めています。デジタル田園都市構想もその一つで、デジタルの力を活用して地域の社会課題の解決を目指し、地域でイノベーションを起こし新たな仕事を生み出すスタートアップ支援を進め、人の流れを作り、結婚・出産・子育てがしやすい環境作りを行うことを目指しています。 ガバメントクラウドの意義はますます大きく デジタル田園都市国家などを実現するデジタル基盤として進められているイニシアティブの中に、ガバメントクラウドがあります。ガバメントクラウドは、クラウドサービスの利点を最大限活用し、迅速、柔軟、セキュア、コスト効率の高いシステムを構築・提供し、最終的には国民、市民へのより良いサービスにつなげるもので、デジタル庁がけん引して進めています。官公庁や自治体のデジタル化施策のベースとなるこのガバメントクラウドに、AWS は 2021 年度から継続して採択され、 2024 年度も引き続き採択されています。ガバメントクラウドに必要な要素を AWS が実現している証左であると大変光栄に思うと同時に、日本政府、官公庁、自治体のインフラとして、引き続きコスト効率の良さを維持しながら、セキュアで、最新技術を利用できるクラウドを提供すべく、引き続き真摯に取り組み続けます。 また AWS は、ガバメントクラウド活用の支援のために、官公庁や自治体職員、および自治体を支援するパートナー向けに、AWS に関する基礎知識を学ぶ トレーニング （ハンズオンを含む）を2022 年 6 月から提供しています。 2023 年 10 月までに、のべ 1,000 人以上の官公庁・自治体職員・パートナーが参加しました。 AWS は公共、教育機関、非営利団体を支援してきた、クラウドベースのソリューションと経験を持つ世界中の AWS パートナーを認定する AWS 公共部門パートナー(PSP) プログラム を提供しており、日本の公共部門のお客様がイノベーションの文化を醸成し、パートナーやスタートアップ、シビックテックのエコシステムを活かして、地域体験を革新するために協働しています。 地方創生・地域活性化、行政の業務改善のための生成系 AI 活用など、自治体との様々な側面での連携を加速 AWS は、全国の自治体や地域行政におけるイノベーションを支援し、より良い社会と市民生活の実現に貢献すべく、様々な自治体、関係団体との連携を図っています。2022 年 9 月に つくば市 と研究開発型スタートアップの成長加速に向けてまた、同年同月に 浜松市 とデジタル・スマートシティ浜松の実現に向けて連携協定を締結しました。2023 年 5 月には 新潟県 と地域産業の活性化に向けた包括的な取り組み、同年 8 月に 北九州市 と地域の特色や強みを活かしながら地域課題を解決するための DX の推進に向けた取り組みを進めています。 例えば、新潟県との連携から、地域の人材育成支援に関して、すでにポジティブな動きが生まれています。AWS の認定トレーニングパートナーである トレノケート株式会社 は AWS と共に、新潟県の地域のリーダーを育てる新しい取り組みである NINNO ACCADEMIA において、AWS のクラスルームトレーニング Developing on AWS を 提供しています 。新潟の地域・社会課題を解決していく人材を育てるために、様々なプログラムを提供し、地域の DX を加速しています。 また、 大阪市 と 2023 年 9 月、行政 DX に向け、生成系 AI の活用に関して連携することで協定を締結。大阪市の行政業務の効率化と、市民サービス向上に向け、生成系AIの利活用の可能性と、利用にあたっての課題解決などについて、共同検証を行っています。 市民生活に直結する公共部門においては、データの確固たる信頼性や透明性が必須となってきます。私たちは、過去 20 年以上にわたり、人工知能（ AI ）や機械学習（ ML ）を誰でもが使うことができるように民主化し、グローバル企業や大規模な公共部門の組織からスタートアップまで、あらゆる規模のお客様が安全に容易に、そして適切なコストで革新的な AI ソリューションを構築できるよう注力しています。 このように AWS は、生成系 AI サービス、ソリューションを含めた最先端、かつ安全に安心して使っていただくテクノロジーや、幅広いサービスを提供しつつ、地域の活性化、市民へのより良いサービスの提供をデジタルを最大限に活用して取り組んでいる自治体と協働し、 DX の加速をサポートしています。 AWS ならではの AI / ML の支援・テクノロジーの民主化　日本の大規模言語モデルの構築支援と選択肢の提供 前日の大阪市の生成系 AI の取り組みの通り、生成系 AI をビジネスや公共部門領域に利用する動きが活発化しています。AWS ではこれまでに&nbsp; Amazon Bedrock 、 Amazon CodeWhisperer 、 Amazon Q &nbsp;などの生成系 AI サービスや&nbsp; AWS Generative AI Accelerator 、 AWS Generative AI Innovation Center &nbsp;といった生成系 AI 開発者支援プログラムを提供してきました。これら、Amazon の 20 年以上にわたる機械学習の経験から生まれたサービス・プログラムを活用することで、お客様は &nbsp;AWS 上で柔軟、セキュア、かつ費用対効果の高い生成系 AI アプリケーションを構築することができます。AWS では Amazon Bedrock や&nbsp; Amazon SageMaker JumpStart &nbsp;で多くの大規模言語モデル ( Large Language Model, LLM ) をお客様に提供しており、お客様の用途に合わせた幅広い選択肢と柔軟性を提供します。また、AWS はお客さまがこの新しいテクノロジーの価値をフルに活かせるように、生成系 AI の専門家からなるチームを設置しており、あらゆる組織が AI を活用できるように支援するという目標を掲げています。 その一環としてアマゾン ウェブ サービス ジャパンは 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の大規模言語モデルの開発を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。詳しくは こちら をご覧ください。 クラウドと AI に対応したスタートアップを含む中堅中小企業（ MSME ）が日本経済を牽引 冒頭、クラウドには社会の課題や困難を突破する力がありますとお伝えしました。それを証明するべく、AWSは、グローバルのコンサルティング企業であるアクセンチュアと共同で、社会課題に取り組む中堅中小企業（MSME: Micro, Small &amp; Medium Enterprises）のクラウドへの移行によってもたらされる日本経済、および社会へのインパクト潜在的効果について検証し、レポート「 日本においてクラウド主導経済が現実に：中堅中小企業（MSME）を通じてクラウドが経済と社会に与えるインパクトとは 」 を発表しました。 同レポートによると、日本経済はクラウドが主導するテクノロジーを採用した MSME によって、2030 年には医療、教育、農業の分野全体で年間総額 1 兆 9,000 億円相当の生産性向上効果、日本の全雇用の 7 ％にあたる 520 万人の雇用を生み出すと予測しています。 医療分野では、クラウド主導の MSME が登場することで、医療機関にアクセス困難で十分なサービスを受けられない地域の課題解消を実現する可能性があるとしています。2030 年には日本でクラウド主導の MSME が医療分野で大きく成長し、年間総額 1 兆 2,000 億円相当の生産性向上効果の創出を促し、6,000 万件のオンライン医療相談をサポートすることになると推計しています。 教育分野では、クラウド主導の MSME がデジタルプラットフォームを通じ、教育へのアクセス性向上とインクルージョン教育に関する課題への対応を支援できる可能性があります。2030 年に MSME が教育分野で年間総額 5,000 億円相当の生産性向上効果を創出し、日本の 400 万人の生徒に e ラーニングソリューションを提供するようになるほか、2030 年までに日本で約 2,000 万人の成人がクラウド主導の MSME を介しオンライン教育にアクセスするようになり、現在の利用者数の 185% 増となると見込んでいます。 農業分野でクラウド主導の MSME が AI やクラウドテクノロジーを通じ、データ主動型の農業生産を導入することで、食糧不足問題を解決する可能性があると期待されています。2030 年には、農業生産に関わる日本の MSME が年間 1,000 億円相当の生産性向上を創出し、3 軒に 1 軒の農業従事者が精密農業ソリューションを利用するようになるだろうと推計しています。これは現在の使用率の 130% 増にあたります。 AWS では、中堅中小企業、スタートアップがイノベーションを支える重要な存在となり、医療、教育のデジタルサービスへのアクセスを改善するなど、社会の課題に対処する上で重要な役割を果たす存在になるだろうと考えています。生成系 AI や高度なクラウドテクノロジーの導入を加速し、経済的・社会的メリットを速やかに可能にするために、AWS は政府、関連機関など各業界と協力し、日本のビジネスがすべての人々にとってより良い未来を築けるよう支援していきます。 社会課題の解決を積極的に取り組む自治体、企業、スタートアップを支援 ビジネス、地域のさらなる活性化実現のために、AWS では「 デジタル社会実現ツアー2023 」を開催しました。昨年初めてオンラインにて開催した「 デジタル社会実現ツアー 2022 」をさらに進化させ、2023 年は 8 月 22 日の高松会場を皮切りに、広島、北九州、大阪、新潟、横浜、名古屋、浜松、仙台、札幌、那覇、福岡、そして全国の自治体、スタートアップなどに集まっていただき、総集編のようなコンテンツとした 10 月 4 日の東京会場と、全国計 13 ヶ所でリアルに開催しました。 「デジタル社会実現ツアー 2023 」のテーマは、「地域創生を“さらに”一歩進めるには？」。政府が進めるデジタル田園都市国家構想によって実現を目指す地域創生や社会課題解決のために、地域交通のリ・デザイン、遠隔医療、こども政策、教育 DX、観光 DX、防災 DX、スマート農林水産業・食品産業など、各領域において、先行して取り組みを始めている先進的な企業やスタートアップおよびそれらと連携している自治体や関係各省庁の皆様を各会場にお招きしました。そこで、「プロジェクトの進め方（資金調達など）」「人材育成」「デジタル技術の活用」といった注目の各トピックについての成功談・失敗談についてお話いただきました。全国各地で開催することで、地域ならではの課題、チャレンジが話し合われました。様々なトピックやテーマについて、多くの様々な参加者の方から情報共有、ディスカッションが行われましたが、AWS を活用しつつ社会課題の解決に尽力している企業様をハイライトとして抜粋してご紹介します。 浜松会場では、「浜松市実証実験サポート事業」に採択されたプロジェクトとして、 株式会社フジヤマ が提案した、浜松市全域の盛土の変化を観測するWebシステムが紹介されました。低コストで利用できる衛星データを活用し、AI 学習を用いた盛土の変化検出手法の検証および Web システム構築を行うことで、市域全体の盛土監視システムの構築を目指すものです。 札幌会場では、 株式会社よびもり が知床（羅臼町と斜里町ウトロ）の海上にて、役場、観光船協議会および漁協とともに実施した、助け合い海難救助サービス「よびもり（ yobimori ）」の実証実験を紹介しました。「よびもり」は、海難事故が発生した場合、最新の位置情報を近くの漁船、観光船などにつないで、救助要請を可能とする仕組みです。 横浜会場では、神奈川県による「要配慮施設利用者の安全を守る避難確保計画の取組化」の実証実験として、 株式会社ネオジャパン の製品である desknet’s NEOとAppSuite にて構築した避難確保計画作成アプリケーションが紹介されました。横浜市の避難確保計画に関するサイトと情報をアプリ上に集約し、災害に対する意識啓発を促進している事例です。 「デジタル社会実現ツアー2023」は、全 13 会場の様子をオンデマンド視聴することができます。詳しくは こちら からご覧ください。 デジタル庁が進めるデジタルマーケットプレイスへの支援 現在、デジタル庁では官公庁や自治体などの行政機関がクラウドソフトウェア（SaaS）を調達する際に、オンライン上でほしいソフトウェアを検索、比較して、調達できるような手法「デジタルマーケットプレイス（DMP）」の開設準備を進めています。 DMP はデジタル庁が運営する調達プラットフォームで、多様なベンダーがサービスを登録し、その中から行政機関が必要なサービスを検索・選定し、簡易的に調達できるようになります。2024 年度下半期の本番サイトオープンにあわせ、国と自治体が調達の際に DMP を利用できるような国の制度整理を進め、会計制度上も利用できるものとする計画です。これに先立ち、2023 年度は α 版というカタログサイトが公開され、事業者が実際に製品を登録し、売り手側、買い手側のニーズや操作性等の確認・調査が行われる予定です。 公共調達の仕組みが大きく簡素化されることと、SaaS というクラウドによる提供形態の製品の紹介の場が作られることにより、これまで公共調達に参加しにくかった中堅中小企業やスタートアップなどにとっては大きなメリットとなります。また、買い手側も DMP というオンライン上で、いつでもどこでも、自分たちのニーズに合った製品を探し出すことができるようになります。 もともとはスタートアップであるアマゾンに出自をもつ AWS は、民間ビジネス領域のみならず、公共部門でのスタートアップの更なる活躍を継続して支援しており、これまでハードルが高かった公共調達に、より参入しやすくなるこの DMP に賛同し、成功を支援します。 例えば前述の、11 月 30 日に事業者向け機能がリリースされた カタログサイトα版 を構築したスタートアップである株式会社dotD（ドットディー）は、 AWSプロフェッショナルサービス によるコンサルティング支援を活用しました。また私たちは、AWS を活用頂いているパートナー向けに、カタログサイト α 版へ製品を登録するためのワークショップや意見交換のための交流会を実施しています。詳しくは こちら をご覧ください。 AWS では、日本の DMP 開設、本格稼働に最大限協力し、企業やスタートアップが公共調達のハードルを乗り越えて、公共部門で社会課題解決のために活躍し、さらに日本の行政サービスの質の向上およびコスト削減に向け貢献されることを全面的に協力し支援していきます。 AWS が考える継続支援への決意 AWS では、デジタル庁が掲げるデジタル田園国家構想を実現するための支援として、ガバメントクラウドに AWS を採用いただくにとどまらず、さらなる活動を継続して行っていくことが重要と考えています。今後、豊かな暮らしを実現していくためには、「経済・社会の発展」、それを実現する要素として「テクノロジーとデータの民主化」、さらに「社会課題の解決」、「付加価値の創造」という循環を作り出していくことが必要です。 しかも、付加価値の創造や社会課題の解決のためには従来の手法では難しい場面が出てくるかもしれません。そこで重要になるのが新しい考え方でテクノロジーを使うような新しい企業が誕生するための「スタートアップへの支援」です。こうして誕生したスタートアップは、「革新的なビジネスモデル」を生み出し、「経済・社会の発展」に寄与すると共に、付加価値の創造や社会課題の解決の一助となっていくでしょう。 日本のデジタル化、それによる市民のより良い暮らしの実現に向けて、AWS は引き続き全方位であらゆるステークホルダーと協力し、支援し、タッグを組み、安全で安心して信頼いただけるクラウドサービスの提供、活動を続けてまいります。 AWS の 2022 年の公共部門における取り組みについては、 こちら をご覧ください。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮

はじめに デジタル環境が急速に変化する今日、企業は効率的な業務運営、コスト削減、クラウドコンピューティングの最適活用を常に模索しています。企業の成長に伴い、Azure や Google Cloud Platform(GCP) から Amazon Web Services(AWS) への移行など、異なるクラウドプロバイダー間での仮想マシン(VM)移行が必要となることが多々あります。 しかし、クラウドへの移行を始めることは、課題や複雑さが多く困難な作業になりかねません。 そこで、 AWS Application Migration Service (AWS MGN) が移行プロセスを簡素化・合理化する強力なツールとして役立ちます。 AWS MGN は、高度に自動化されたリフト&amp;シフトソリューションを提供することで、クラウド移行の簡素化、促進、コスト削減を実現します。 1台のサーバーにつき最大 90 日間、サーバーの数に制限なく無料で移行できます。ほとんどのお客様は、この 90 日以内にサーバーの移行を完了し、AWS Application Migration Service を無料でご利用いただけます。 このブログでは、AWS MGN を使用して Azure 上の仮想マシンを AWS に移行する方法について解説します。 移行をスムーズに成功させるための手順、ベストプラクティス、留意点について説明し、AWS が提供する様々な機能を最適に活用できるよう助言します。 アーキテクチャの概要 AWS MGN は、物理サーバー、仮想マシン、クラウド上のサーバーを、簡単に別の場所に移行できるサービスです。 オンプレミスのデータセンターや別の AWS リージョン、他のクラウドプロバイダー上のサーバーから、AWS にサーバーを移行することができます。 以下のアーキテクチャ図は、AWS MGN を使ってオンプレミスのサーバーを AWS に移行する流れを示しています。 図 1. AWS MGN アーキテクチャ図 ソースサーバにインストールされた軽量なエージェントが、レプリケーションを実行します。この AWS レプリケーションエージェントは、TLS を利用してポート 443 を通じて安全に通信を行い、接続されているすべてのディスクをスキャンして、ターゲットリージョンへブロックレベルでレプリケーションを行います。最初のレプリケーションが完了すると、レプリケーションエージェントはソースサーバへの変更を監視し、その変更点をレプリケートしていきます。これにより、ターゲットリージョンに保存されたデータを最新の状態に保つことができます。 ソースとターゲットが完全に同期し、継続的レプリケーションモードになった後は、テストまたはカットオーバーを開始することができます。 テストまたはカットオーバーが開始されると、AWS MGN は Amazon Elastic Compute Cloud (Amazon EC2) &nbsp; の API を使用してターゲットインスタンスを起動し、新しい Amazon Elastic Block Store (Amazon EBS) &nbsp; ボリュームをアタッチします。 AWS MGNを利用することで、アプリケーションやワークロードの内容に関わらず、オンプレミスのデータセンターや他のクラウドプロバイダーから AWS へ仮想マシンを移行することができます。 ソリューション概要 AWS MGN を利用すると、仮想マシンを Amazon EC2 に移行できます。また、アプリケーションデータの同期も確認できます。 移行に関する手順は以下の通りです。 AWS MGN を利用してレプリケーション環境を構築します。 一時的な認証情報を作成します。 Azure の仮想マシンに AWS MGN エージェントをインストールします。 ソースサーバーの起動設定を行います。 テスト用インスタンスとカットオーバーインスタンスを起動します。 前提条件 Azure での WordPress サイトの作成 まず移行を行うには、 WordPress が構築されている Azure 仮想マシンが必要です。Azure 仮想マシンを作成する手順は以下の通りです。 Azure アカウント上で検索バーに「 WordPress 」と入力し、検索します。 検索に一致した Marketplace で [ WordPress ] オプションを選択します。App Service で WordPress を選択しないでください。選択すると、VM にアクセスできなくなります。 [ 作成 ] を選択します。 リソースグループ名 と 仮想マシン名 を入力します。 管理者アカウント に、 ユーザー名 と キーペア名 を入力します。これは後でインスタンスに接続するときに使用します。 [ 確認および作成 ] を選択します。 新しいキーペアを生成するように求められます。後で仮想マシンにアクセスできるように、プライベートキーをダウンロードするオプションを選択します。 ソースサーバーネットワーク AWS MGN レプリケーションエージェントを WordPress サーバーにインストールする際には、ネットワーク設定を適切に構成し、アクセスを許可する必要があります。手順は以下の通りです。 Azure アカウントで、仮想マシンを検索します。 WordPress ドキュメントの作成時に指定した名前の仮想マシンを選択します。 サイドバーの 設定 の [ネットワーク設定] タブを選択します。 図 2. WordPress を実行しているソースサーバーのネットワーク画面 [ 受信ポート ルール ] を選択します。宛先ポート範囲を 443 に設定し、プロトコルとして TCP を選択します。 DenyAllInbound の優先度よりもこのルールの優先度番号が小さいことを確認してください。 次に、[ ポート ルールの作成 ] – [ 送信ポート ルール ] を選択します。 このメニューで、宛先ポート範囲を 1500 に、プロトコルを TCP に設定します。残りはデフォルトのままにします。 セクション 1: AWS MGN 環境のセットアップ AWS MGN のランディングページで[ 使用を開始 ]をクリックします。このサービスに初めてログインした場合、サービスの初期設定を求められます。 図 3. AWS MGN サービス初期時のプロンプト コンソールの AWS MGN エリアにアクセスするのが初めてではない場合は、サイドバーの [ レプリケーションテンプレート ] に移動し、[ サービスのアクセス許可を再初期化 ] を選択することでアクセス許可を再設定できます。 サービスを初期化すると、 AWS Idenity and Access Management (IAM ) ロールとともにレプリケーションテンプレートが作成されます。テンプレートは、新しく追加されたソースサーバーごとにデータレプリケーションがどのように機能するかを規定します。また IAM ロールはレプリケーションエージェントをインストールするために必要な権限が付与されます。 構成されたレプリケーション設定は、個々のソースサーバーまたはソースサーバーのグループでいつでも変更できます。 レプリケーション設定の詳細 をご覧ください。 セクション 2: 一時的な認証情報の作成 ソースサーバーに AWS MGN エージェントをインストールするには、まず必要な認証情報を作成する必要があります。そのためには、インストール権限を持つ AWS IAM ロールを作成します。このロールを使用して、MGN で利用するための一時的な認証情報を生成します。 コンソールの AWS IAM に移動します。 サイドバーで、[ アクセス管理 ]の[ ロール ]タブを選択します。 右上の [ ロールを作成 ] ボタンを選択します。 図 4. 新しいロールを作成できる AWS IAM ロール画面 信頼されたエンティティタイプについては、[AWS アカウント] を選択し、[次へ] を選択します。 許可ポリシーの検索バーで、[AWSApplicationMigrationAgentInstallationPolicy] を検索し、その横にあるチェックボックスをオンにして選択します。次に、[次へ] を選択します。 ロール名には 「 mgn_install 」 を入力します。次に、下にスクロールして [ ロールを作成 ] を選択します。 ロール検索バーで、先ほど作成した mgn_install ロールを検索し、選択して概要にアクセスします。 概要に表示されている mgn_install の ARN をコピーします。 セッション時間が長く必要と想定される場合は、編集ボタンを選択し、必要に応じてロールの最大セッション時間を長くしてください。 図 5. mgn_install ロールの概要 セクション 3: Azure 仮想マシンに AWS MGN エージェントをインストールする コンソールの AWS MGN に移動します。ソースサーバーを選択し、[ サーバーを追加 ]を選択してエージェントインストーラーのリンクを取得します。 図 6. 新しいソースサーバーを追加できる AWS MGN ソースサーバー画面 [ サーバーを追加 ]を選択すると、AWS レプリケーションエージェントインストールに関する設定画面が表示されます。 図 7. AWS レプリケーションエージェント のインストール画面 ここでは、セクション2で作成した IAM ロールの認証情報(AccessKeyID、SecretAccessKey、および SessionToken)を提供する必要があります。そのため、 AWS Security Token Service (AWS STS) の AssumeRole API を利用して、一時的な認証情報を取得します。一時的な認証情報を取得するには以下の手順を実行します: コンソールページの左下にある CloudShell ボタンを選択して、コマンドラインインターフェイス (CLI) を開きます。 図 8. AWS CloudShell インターフェイス CLI に次のコマンドを挿入します。これにより、AccessKeyID、SecretAccessKey、および SessionToken が出力されます。これらのトークンは、AWS レプリケーションエージェントのインストールページの項目 に利用します。 (図 7 を参照)。 aws sts assume-role —role-arn [mgn_install の ARN] –-role-session-name “mgn-install” 図 9. aws sts assume-role コマンドを実行した後の CloudShell の出力 AccessKeyID、SecretAccessKey、および SessionToken を入力後、図7の項目5と6のコマンドをコピーして Azure 仮想マシン上で実行することで、Azure 仮想マシンにレプリケーションエージェントをインストールすることができます。 Azure 仮想マシンへの Secure Shell (SSH) または Remote Desktop Protocol (RDP) のガイダンスについては、次のドキュメントを参照してください。 https://learn.microsoft.com/en-us/azure/virtual-machines/linux-vm-connect?tabs=Linux 項目 5 のコマンドを正常に実行すると、次のようになります。 図 10. エージェントインストーラが正常にダウンロード完了した場合の出力 同様に、項目6のコマンドを実行すると、次のようになります。 図 11. レプリケーションエージェントを正常にインストール完了した場合の出力 AWS レプリケーションエージェント が正常にインストールされたことを示すプロンプトが表示された後、AWS MGN のソースサーバー一覧にソースサーバーが表示され、初期同期が開始されます。 図 12. MGN のアクティブなソースサーバーリストに表示されるサーバー エージェントのインストール後、ソースサーバに接続されているすべてのディスクが自動的にスキャンされ、検出されたディスク上のデータに対して複製が開始されます。 セクション 4: サーバー起動設定の構成 テストインスタンスとカットオーバーインスタンスを起動する前に、いくつかの設定を構成する必要があります。 設定を行うには、まずソースサーバーを選択します。ここから、図13に示すように、[ 起動設定 ]に移動できます。 [ 起動設定 ]では、[ 一般的な起動設定 ] と [ EC2 起動テンプレート ]の2つがあります。 図 13. ソースサーバーの起動設定 このユースケースでは、[ 一般的な起動設定 ] をデフォルトのままにします。 [ EC2 起動テンプレート ]については、[ ネットワーク設定 ] までスクロールし、[ 高度なネットワーク設定 ] を選択します。 図 14. EC2 起動テンプレート内のネットワーク設定 ここでは、WordPress サーバーが公開されている前提で、[ パブリック IP の自動割り当て ]を有効にする必要があります。次に、[ テンプレートのバージョンを作成 ] を選択して、これを新しいテンプレートバージョンとして保存します。 図 15. 高度なネットワーク設定 テンプレートを構成したら、テンプレートを開いて正しく構成されていることを確認する必要があります。そのためには、テンプレートバージョンを作成した後に表示される成功通知でテンプレート名を選択します。 図 16. 起動テンプレートが正常に作成された後に表示されるメッセージ AWS MGN はデフォルトのバージョンの EC2 起動テンプレートを使用します。新しく作成したテンプレートはデフォルトにはなっていないため、[ アクション ] に移動して [ デフォルトバージョンを設定 ] を選択する必要があります。ドロップダウンから最新のテンプレートバージョンを選択し、「 デフォルトバージョンとして設定 」を選択します。 図 17. デフォルトバージョンを設定するドロップダウンメニュー セクション 5.テストインスタンスとカットオーバーインスタンスの起動 最初にテストインスタンスを起動し、テストインスタンスで問題が無いことを確認した後カットオーバーに進みます。これは、カットオーバーのプロセスを完了する前に、インスタンスで問題が発生しないかどうかを事前に検証するためです。 ソースサーバーの [ 移行ライフサイクル ] 列に [ テストの準備完了 ] と表示され、データレプリケーションステータスが正常となっているを確認します。 次に、ソースサーバーを選択し、[ テストおよびカットオーバー ] から [ テストインスタンスを起動 ] を選択します。 図 18. [テストおよびカットオーバー] から[テストインスタンスを起動] を選択 テストインスタンスの起動に成功すると、[ アラート ]列に [ 起動済み ]と表示されます。サーバーを選択し、[ 移行ダッシュボード ]を表示して確認することもできます。起動ステータスが[ 成功 ]と表示されると、起動したテストインスタンスを EC2 で表示し、パブリック IPv4 アドレスを開くオプションが表示されます。これはカットオーバーインスタンスでも同様に表示されます。 (オプション) 検証に失敗した場合、[ アラート ]列にエラーメッセージが表示されます。再試行する前にサーバーのトラブルシューティングを行えるように、[ 移行ライフサイクル ]を[ テストの準備完了 ]に戻すオプションを選択できます。エラー一覧とトラブルシューティング方法については、 こちら をご覧ください。 テストが成功したら、[ テストおよびカットオーバー ]に移動し、[ カットオーバーの準備完了 ] としてマークできます。次に、[ カットオーバーインスタンスを起動 ] を選択します。テストと同様に、[ アラート ]列に [ 起動済み ] ステータスが表示されれば、カットオーバーが成功したことがわかります。ソースサーバー名を選択して、移行ダッシュボードを表示することもできます。 図 19. [テストおよびカットオーバー] から [カットオーバーインスタンスを起動]を選択 次に、ソースサーバーのリストからソースサーバーを選択し、[ 移行ダッシュボード ]から EC2 へのリンクを選択します。 図 20. 移行ダッシュボードで、起動した EC2 カットオーバーインスタンスに遷移 インスタンス概要から、新しいインスタンスのパブリック IPv4 アドレスを確認し、IPv4 アドレスを使用して WordPress ページにアクセスします。 図 21. カットオーバーインスタンスの EC2 概要とパブリック IPv4 アドレス IPv4 アドレスにアクセスし WordPress ページが機能していれば、カットオーバーは成功しています。移行を完了するには、コンソールで AWS MGN サービスに戻り、ソースサーバー に移動します。 ソースサーバーを選択し、[ テストおよびカットオーバー ]から[ カットオーバーを最終処理 ]を選択します。最終処理が完了すると、ソースサーバーの移行に使用されたリソースがすべてクリーンアップされ、破棄されます。 図 22. [テストおよびカットオーバー]から[カットオーバーを最終処理]を選択 セクション 6: クリーンアップ クリーンアップするには、ソースサーバーを選択し、[ アクション ]から「 アーカイブ済みとしてマーク 」を選択します。 アーカイブ済みとしてマークされたサーバーは AWS MGN コンソールに表示されなくなります。 (オプション)カットオーバーインスタンスを使用する目的でこれを実行した場合は、このステップに従わないでください。ただし、学習としてこのガイドに従った場合は、ターゲットの EC2 インスタンスを削除して、そのインスタンスとそれに関連する EBS ボリュームのコストが発生しないようにする必要があります。これを行うには、EC2 ダッシュボードにアクセスしてインスタンスを表示します。そこからインスタンスを選択し、[ インスタンスの状態 ] から [ インスタンスの終了 ] を選択します。 結論 このブログ記事では、AWS MGN を使用して Azure から AWS へ仮想マシンを移行する際の主な手順について説明しました。 移行をスムーズに行う方法として、AWS MGN の環境設定の方法、Azure の仮想マシンに MGN エージェントをインストールする手順を解説しました。さらに、AWS 側で起動テンプレートを設定する方法もステップバイステップで説明しました。 AWS MGN は、仮想マシンをクラウド間で移行するプロセスを簡略化することを目的としており、互換性の評価、データレプリケーション、カットオーバーなどのタスクを高度に自動化します。 この記事は特に Azure VM から AWS への移行に焦点を当てていますが、MGN はオンプレミス、Azure、GCP、AWS など、異なる環境間での異機種移行もサポートしています。 組織は、アプリケーションポートフォリオと要件を評価し、AWS MGN が自社のクラウド移行戦略とロードマップに適合し、どの部分で活用できるかを判断することができます。 翻訳はソリューションアーキテクト 駒野 達也 が担当しました。原文は こちら です。

はじめに 過去数年にわたり、産業や製造の領域では、 インダストリアル IoT (IIoT) 、人工知能 (AI) 、 機械学習 (ML) の進歩による変革が加速しています。この変革の中心にあるのはデータであり、これを効果的に活用すれば、ビジネスのオペレーション効率、イノベーション、顧客満足度を新たな高みに押し上げることができます。強固な産業データ基盤の構築は、単なる戦略的な活動ではありません。デジタル時代における成功を目指すメーカーや産業界にとって不可欠です。 AWS IoT SiteWise は、産業機器から大規模なデータを簡単に収集、整理、分析できるマネージドサービスであり、顧客がより適切でデータ主導の意思決定を行えるよう支援します。 Volkswagen Group 、 Coca-Cola İçecek 、 Yara International などのお客様は、AWS IoT SiteWise を使用して、工場全体で生成されたオペレーショナルテクノロジー (OT) データをコンテキスト化して分析できる産業用データプラットフォームを構築し、事業とビジネスのグローバルビューを構築しています。さらに、 Embassy of Things (EOT) 、 Tata Consulting Services (TCS)、 Edge2Web 、 TensorIoT 、 Radix Engineering などの AWS パートナーは、予知保全やアセットパフォーマンスモニタリングなどのユースケースを可能にする専用アプリケーションの基盤となっています。お客様やパートナーとのこうした取り組みを通じて、デジタルトランスフォーメーションの取り組みを拡大する上での主な障害は、プロジェクトの複雑さ、インフラストラクチャのコスト、価値実現までの時間にあることがわかりました。 こうした障害に対処するため、AWS IoT SiteWise ではお客様やパートナーが AWS IoT SiteWise に保存されている産業機器データに分析と AI/ML を適用する方法を簡素化する新機能をリリースしました。これらの新機能により、データをクラウドに取り込むコストを最大 70% 削減し、プロジェクトのタイムラインを数か月から数週間に短縮、ビジネスインテリジェンス (BI) ダッシュボードや ML アプリケーションでデータに簡単にアクセスできるようになります。これらの機能強化により、お客様はアセットモデルと階層をより迅速に導入し、取り込みから数分以内に分析ワークフローを実行し、予測メンテナンスのユースケースをより迅速に展開して計画外のダウンタイムを回避できます。今回の新機能により、AWS は、大量の多様な産業データを実用的な洞察に変換し、オペレーション効率を高め意思決定を改善することをより簡単かつ費用対効果の高い方法で実現できるようになりました。 このブログ記事では、AWS IoT SiteWise で最近リリースされた機能の詳細と、AWS のお客様とパートナーがデータ基盤の近代化を促進するためにこれらの機能をどのように使用しているかについて詳しく説明します。 変革のペースを加速する 業務全体の可視性を標準化することは、産業変革の重要な要素です。これは、従来の分断された手動の監視方法からの転換を意味し、コンテキスト化されたデータの統一されたビューに基づいて構築された、統合されたデータ主導型のアプローチが必要です。AWS IoT SiteWise は、このようなデータの標準化とコンテキストをアセットモデルで提供します。モデルはデータを整理し、企業、サイト、エリア、およびマシンレベルでの分析に役立ちます。しかし、産業のオペレーションが複雑であることを考えると、物理資産を正確に表すモデルの構築と維持には時間がかかり、洞察を得るまでの時間が遅れる可能性があります。 新たに追加された API により、AWS IoT SiteWise では、データヒストリアン、他の AWS アカウント、または AWS の独立系ソフトウェアベンダー (ISV) パートナーの場合は独自の産業データモデリングツールなどのさまざまなシステムから、 産業アセットモデルのメタデータを大規模にインポート、エクスポート、更新 ができるようになりました。 図 1: ヒストリアンなどの外部システムから機器メタデータをインポート さらに、AWS IoT SiteWise は、お客様が新しいアセットモデルを作成するために再利用できる アセットモデルコンポーネント とサブコンポーネントの作成をサポートするようになりました。アセットモデルコンポーネントにより、お客様は複雑な機械を企業全体で再利用可能な部品に分割できます。お客様は全社的なコンポーネントライブラリを作成できるため、モデルの標準化が促進され、業務の拡大や複雑化に伴うより効率的なスケーリングが可能になります。下の図は、再利用可能なサーボモーターコンポーネントを使用して複雑な溶接ロボットをモデル化する方法を示しています。新機能により、新しい産業用ユースケースを導入するまでの時間が数か月から数週間に短縮され、さまざまな産業用データソースからのデータを統合ビューにすばやく取り込むことで、価値実現までの時間が短縮されます。 図 2: 再利用可能なコンポーネントモデルを作成してアセットを記述し、データを整理 リアルタイムおよび過去の機器データの統合ビューの作成 AWS IoT SiteWise は、リアルタイムの機器データと過去の機器データの両方を安全に一元管理できるストレージを提供します。エンドユーザーと産業用アプリケーションは、AWS IoT SiteWise に保存されているデータを利用して、貴重な洞察を得てビジネス成果を促進できます。 機器からリアルタイムのデータを収集するために、AWS IoT SiteWise では AWS IoT SiteWise Edge を提供しています。これは AWS によって作成され、オンプレミスにデプロイされ、エッジでの機器の収集、整理、処理、監視を簡単に行えるようにするソフトウェアです。SiteWise Edge を使用すると、お客様は OPC-UA などの産業用プロトコルや標準を使用して機器に安全に接続し、機器からデータを読み取ることができます。AWS パートナーである Domatica 社と協力し、MQTT、Modbus、SIMATIC S7 などの 10 種類の産業用プロトコルのサポートを追加 しました。これにより、機器、機械、レガシーシステムから AWS IoT SiteWise に取り込んで、エッジでの処理や産業用データレイクを強化できるデータの種類が多様化されました。1 秒未満のレイテンシーでデータをクラウドに取り込むことで、お客様は AWS IoT SiteWise を使用して、産業活動全体にわたる何十万ものアセットをほぼリアルタイムで監視できます。 図3: AWS パートナーである Domatica 社の EasyEdge ソフトウェアをを利用することにより新たにサポートされたプロトコルによる機器への接続が可能 ただし、クラウドにおいてすべての機器データがニアリアルタイムで必要なわけではありません。エネルギー、組立製造、プロセス業界のお客様とのプロジェクトを通して、クラウドに送信された機器データのうち、クラウド上のダッシュボードで使用されているニアリアルタイムのデータはわずか10～30％であることがわかりました。残りの 70% ～ 90% は、BI ダッシュボードや機械学習モデルトレーニングなど、クラウド内のデータを数秒ではなく数分以内に必要とする分析アプリケーションで使用されます。そのため、データの取り込みと保存の方法を最適化する必要がありました。 そこで、分析のユースケースに適したコストとパフォーマンスを提供するために、 バッファリングされたデータ取り込みを発表 しました。バッファリングされたデータ取り込みでは、クラウドに取り込まれる前にエッジでバッファリングするデータストリームを顧客が設定できます。これにより、お客様はクラウドへのデータ取り込みコストを最大 70% 削減できます。 コスト効率が高く分析クエリ用に最適化されたストレージ AWS IoT SiteWise には複数のストレージ階層があり、パフォーマンスとコスト効率のバランスを取りながら、さまざまなユースケースを柔軟にサポートできます。ホットストレージ階層は頻繁にアクセスされるデータに最適化されており、インタラクティブダッシュボードなどのリアルタイムアプリケーションでは書き込みから読み取りまでの待ち時間が短くなります。コールドストレージ層は、 Amazon S3 バケットを使用して、稀に使用されるデータを保存します。新機能としてデータをコスト効率よく保存できるように設計された 新しいウォームストレージ階層 を追加しました。ウォームストレージ階層は BI、レポートツール、ML モデルトレーニングなどのアプリケーションで、書き込みから読み取りまでの待ち時間が中程度の大量のデータを取得するのに最適化されています。このウォームストレージ階層により、お客様は大量のデータを、 Amazon S3 に近い 1 GB あたりの価格で保持できます。 ウォームストレージ階層を使用しているお客様は、 新しい Query API も使用できます。Query API を使用すると、お客様は SQL に似たクエリステートメントを使用して、1 回の API リクエストで、アセットモデル、アセット、測定値、メトリクス、変換、集計からメタデータと時系列データを取得できます。この機能は、Amazon QuickSight、PowerBI、Microsoft Excel などのツールと互換性があり、ニアリアルタイムや過去の企業業績のレポートを作成できます。 お客様は、新しい Query API で SQL クエリステートメントを使用してデータを探索し、洞察を抽出できます。次の例は、ユーザーが名前に「Engine」を含むすべてのマシンの RPM 情報をクエリする方法を示しています。 select a.event_timestamp,b.asset_name ,c.property_name , a.quality,a.integer_value from raw_time_series a,asset b , asset_property c where a.event_timestamp &gt; 1698335614 and b.asset_name LIKE ‘Engine%’ and c.property_name = ‘RPM’ event_timestamp asset_name property_name quality integer_value 26-10-2023T15:53:34 Engine001 RPM GOOD 2857 26-10-2023T15:53:34 Engine002 RPM GOOD 2549 26-10-2023T15:63:34 Engine001 RPM GOOD 2753 26-10-2023T15:63:34 Engine002 RPM GOOD 2349 表 1: SQL ステートメントを使用したクエリによるデータ取得 機械学習を使用した予知保全プログラムの推進 複数のお客様が、AWS IoT SiteWise からの産業機器データを Amazon Lookout for Equipment と統合して、予測を行い、機器の異常な動作を検出できる機械学習モデルを作成しています。しかし、サービス間の連携のためにお客様が複数のステップを踏む必要があり、時間のかかるプロセスでした。 AWS IoT SiteWise と Amazon Lookout for Equipment の新しいネイティブ統合 により、連携のための複雑な仕組みの構築やコードを記述したりすることなく、これら 2 つのサービス間でデータを直接同期できるようになりました。これにより、Lookout for Equipment の機械学習モデルを AWS IoT SiteWise から簡単に構築でき、異常検出と予知保全が可能となります。 トヨタ自動車ノースアメリカ (TMNA) は、AWS IoT SiteWise データを使用して Amazon Lookout for Equipment で作成されたモデルを自社の CNC マシンにデプロイしました。サイトあたり200台以上の CNC マシンが年中無休で稼働していたため、TMNA メンテナンスチームにとって予知保全には時間とコストがかかりました。TMNA は、AWS IoT SiteWise を使用して、障害を数日前に予測し、計画外のダウンタイムを削減できる 予測メンテナンス ソリューションを開発しました。導入以来、お客様は数十件の事故や何時間ものダウンタイムを防ぐことができただけでなく、オペレーション可用性を過去 12 か月間の平均で 10% 向上させました。 「当社のフォーカスラインの稼働率は78～ 82% で、毎月約40時間のダウンタイムが発生していました。AWS の支援により、マシンに多くの問題が見つかりました。気付かないままにしておくと、重大な障害につながります。現在、当社の OA は 92% で、ダウンタイムは約20時間です。」— Braden Burford, Sr. Maintenance Engineer, Toyota 機器データのコンテキスト化による強力な洞察 産業の変革は、主に機器、機械、レガシーシステムから得られるデータの可能性を解き放つことに重点を置いています。従来のデータ管理システムでは、効率性、拡張性、革新性に向けた高い要求を満たすにはもはや十分ではありません。これらの機能強化により、AWS IoT SiteWise は、データを資産として活用するためのスケーラブルで統一された統合アプローチを可能にする最新の産業用データ基盤を実現します。コスト効率が高く、安全で再現性のあるフレームワークを提供することで、お客様が産業変革のための強固な基盤を構築し、業務を最適化するのに役立つ産業用データセットへのアクセスを可能にします。 AWS のお客様であるバイオ医薬品の世界的リーダーである Bristol Myers Squibb (BMS) は、AWS IoT SiteWise による産業データ基盤の近代化によって業務変革を実現されたお客様です。生物製剤、製薬、細胞療法の各部門にわたる事業戦略を強化するという目標を掲げており、BMS は従来のデータシステムの見直しの必要性を認識しました。彼らの主な目的は明確でした。1/ 企業全体の可視性を実現すること、2/ エンドツーエンドのトレーサビリティを確立すること。3/ プロセス監視、予測的資産保守、継続的プロセス検証 (CPV) のための検証済みの単一エンタープライズソリューションを実装すること。 BMS は、企業全体の可視性と分析を強化できるデータ管理への統合アプローチを求めて、AWS IoT SiteWise を採用しました。BMS は、Enterprise PI Historian からデータを引き出し、それを AWS 上の統合データレイクに送ることで、データ管理においてかつてないスケール、パフォーマンス、スピードを実現しました。 BMS の重要な進歩の 1 つは、エンタープライズリソースプランニング (ERP) やその他のシステムからの情報とデータを集約することで、データにコンテキストを追加できることでした。これにより、さまざまな場所で製造されている製品バッチのより詳細なサイト分析が可能になりました。 「生物製剤、製薬、細胞療法におけるビジネス戦略の改善を目指すにあたり、可視性とトレーサビリティの強化が不可欠であり、AWS IoT SiteWise は完璧なソリューションでした。AWS を使用してデータ基盤を最新化することで、さまざまなデータソースを統合データハブにシームレスに統合し、効率とスケーラビリティを最適化しました。この変革により、さまざまなシステムからのデータを組み合わせることができ、複数のサイトにわたる製品バッチの洞察に満ちた分析が可能になりました。これにより、アセットのメンテナンスを予測する能力が大幅に強化され、新しい潜在的なユースケースに光が当てられました。これはゲームチェンジャーです。」— Nitin Bhatti, GPS IT, Manufacturing Analytics at Bristol Myers Squibb BMS の変革は、将来のイノベーションの舞台となりました。インフラストラクチャが最新化されたことで、Predictive Asset Maintenance (PAM) や多変量分析など、新たなユースケースを検討できるようになりました。長期的なビジョンには、データの使用と分析を現場の担当者の範囲を超えて拡大し、企業全体の包括的な視野を提供することが含まれます。 AWS パートナーと協力してビジネス成果を実現 デジタルトランスフォーメーションを進めている産業界では、プロジェクトの拡大が難しいことに気付きました。PoC から大規模な企業への本格導入までイニシアチブをとることは、リソースを大量に消費し、専門的なスキルが必要です。AWS パートナーは、業界全体にわたる深い専門知識を持ち、基幹業務のユースケースを解決するソリューションを提供することで長期的な顧客価値を生み出すために必要な推進要因を理解しています。これらのパートナーは、お客様が AWS IoT SiteWise を使用して堅牢なデータ基盤を構築できるよう支援し、そのデータ基盤を使用してお客様の特殊なユースケースの解決を支援します。AWS IoT SiteWise パートナーのいくつかの例を以下に示します。 EOT は Twin Fusion を構築しました。これは、AWS IoT SiteWise を使用して、AWS クラウド内の高度な分析、ML、生成 AI を活用してレガシー IoT データの活用、管理、視覚化、アクションを実現する、Software-as-a-Service (SaaS) 製品です。Twin Fusion は、 産業データファブリック (IDF) に関する AWS ガイダンス の一部です。Twin Fusion は、マシンや時系列データからの IIoT データやセマンティックデータを AWS IoT SiteWise に取り込むためのエンドツーエンドのソリューションを提供します。Twin Fusionは、複数の産業用データソースからのメタデータを統合する企業全体のデジタルツイングラフアセットモデルを提供します。この製品は、エンドユーザーデータ分析、アセット階層検索、埋め込みMLモデル、およびAIによる産業資産の企業全体の最適化のためのオペレーションダッシュボードを提供します。 TCS は、時系列データを AWS サービスでモダナイズするパートナーであり、エッジと AWS クラウドに AWS IoT SiteWise をデプロイすることで、顧客の価値実現までの時間を短縮しています。TCS は、お客様が複数の時系列データを単一のエンタープライズクラウドヒストリアンに取り込み、データのサイロ化を解消して、機器のダウンタイムの最適化、サイクルタイムの改善、一貫した生産性、不良率の低下、環境コンプライアンスなどの産業上の課題を解決できるよう支援します。 Edge2Web は、ノーコードおよびローコードの産業用アプリケーションの オープンプラットフォーム の基盤として AWS IoT SiteWise を使用しています。Edge2Web アプリケーションは、お客様が資産をより適切に管理し、機械のダウンタイムを削減し、製品品質を向上させ、生産パフォーマンスを最適化するのに役立ちます。 TensorIoT は、AWS IoT SiteWise 上に構築された SmartInsights ソリューションを開発しました。SmartInsights は、「起こったこと」と「これから起こること」を1つの画面で確実に視覚化します。SmartInsights を使用すると、お客様は予知保全、リモートアセット監視、再生可能資産の性能予測と保守などのユースケースを解決できます。 Radix Engineering は、産業界のお客様がエッジに保存されている時系列データを活用し、AWS IoT SiteWise を使用して従来の産業オペレーション技術 (OT) アーキテクチャを最新化できるよう支援すると同時に、統合された機械学習 (ML) モデルと洞察により運用と信頼性の向上を促進することに重点を置いています。 これらのパートナーソリューションはそれぞれ、特定の産業上の課題に対処するだけでなく、長期的なビジネス価値と効率性を実現するためにデジタルトランスフォーメーションの取り組みを成功させる上で、専門知識と AWS IoT SiteWise などの高度なツールが果たす重要な役割を示しています。 変革の青写真 トヨタ自動車北米と Bristol Myers Squibb の成功事例は、他の企業の青写真として役立っています。これらのリーダーをはじめとする多くの企業が、スケーラブルで再現性のある産業データ基盤を提供するサービスとして AWS IoT SiteWise を採用し、それを日常業務に統合し、過去およびリアルタイムの機器データの力を活用してデジタルトランスフォーメーションの価値を実現しています。 AWS IoT SiteWise を開始するには、 ここをクリック してください。 re:Invent 2023 に参加する場合は、以下のセッションに参加して、これらの新機能を深く掘り下げてください。 IOT206 | Accelerating industrial transformation with IoT on AWS IOT215 | Accelerate shop floor digitization with edge-to-cloud data integration IOT212 | Modernizing your data historian with AWS IoT SiteWise IOT203 | Automated anomaly detection for smart manufacturing この記事は Sophie Pagalda、Sharon Allpress、Jan Borch、David Castro によって書かれた The Blueprint for Industrial Transformation: Building a Strong Data Foundation with AWS IoT SiteWise の日本語訳です。この記事は Solutions Architect の西亀真之が翻訳しました。

はじめに モノのインターネット ( IoT ) ワークロードを導入しようとする場合、企業はプラットフォームを複数の選択肢から選択することになります。この選択肢はさまざまで、独自デバイスのハードウェアを含めて完全にゼロから構築する方法や、事前に設定されたハードウェアを購入して、完全な SaaS (Software as a Service) IoT プラットフォームに接続するような方法があります。 このブログの目的は、IoT ソリューションの設計に必要なスキルや知識を理解し、どのコンポーネントを自前で開発して、どのコンポーネントを外部の技術ソリューションとして買ってくるのかを判断できるようにすることです。IoT ワークロードを AWS に移行しようと考えている場合は、 「&nbsp; AWS IoT Core へのシームレスな移行を計画する &nbsp;」&nbsp;をご参照ください。 AWS を利用することによる、移行プロセスの簡略化、提供可能なサポート、得られるメリットなどを理解するための最初のステップとして役立ちます。 一般的な AWS IoT アーキテクチャのコンポーネント デバイスの製造 ハードウェアの設計と製造では、考慮すべき要素がいくつかあります。 要件に基づき、ソリューションの現在および将来のニーズを満たすためにハードウェアを選択する必要があります。 IoT の一般的な制約、つまり電力(供給と消費)、接続性、セキュリティ、オペレーティングシステムの管理に関する意思決定が必要です。 ハードウェアを社内で製造していない場合、オリジナルデバイスメーカー ( ODM ) を選択する必要があります。ODM には、大量のデバイスを生産するための製造ライン、ツール、プロセスが揃っています。 通常、プリント基板 ( PCB ) の回路図、部品表、ファームウェア、プロビジョニング要件など、提供する仕様に基づいて製造できます。 デバイスのハードウェア制約を考慮する項目 : 消費電力 : デバイスの使用方法と場所は、電源供給に大きな影響を与えます。ウェアラブルデバイスは小さなバッテリーで動作しますが、テレビは AC 電源を必要とします。バッテリーを必要とするデバイスの場合、バッテリーが再充電可能か交換可能か、ハードウェアの寿命まで利用可能かを判断する必要があります。 オペレーティングシステムとファームウェア : オペレーティングシステムやファームウェアの選択は、デバイスの種類と期待されるタスクによって異なります。小型で低消費電力のデバイスは FreeRTOS などの リアルタイムオペレーティングシステム が必要かもしれませんし、大型で専用の電源を必要とするデバイスは Linux などのフルスタックオペレーティングシステムが必要になる場合もあります。 接続性 : IoT ソリューションには、 イーサネット 、 Wi-Fi 、 セルラー 、 LoRaWAN 、 Bluetooth Low Energy ( BLE ) など、多くの接続性とプロトコルのオプションがあります。デバイスの設置場所、可用性、消費電力、セキュリティ、ユースケースによって、ソリューションに最適な接続オプションが決まります。 AWS ではこのコンポーネントを支援するために、 AWS デバイス認定プログラム &nbsp;を完了した AWS パートナー製デバイスのリストである AWS Partner Device Catalog &nbsp;を提供しています。 このリストにあるデバイスは、AWS IoTとAWSのベストプラクティスとの互換性を確保し、市場への投入を高速化するのに役立ちます。さらに、自社製造のデバイスをお持ちの場合は、 AWS IoT Core Device Advisor &nbsp;を使用して、AWS IoT Core と確実かつ安全に接続できることを検証できます。 デバイスのプロビジョニング IoT ソリューションにおけるデバイスのプロビジョニング方法は、デバイスの機能とその製造プロセスによって異なります。ここでの主な焦点は、デバイスとその認証情報の作成方法にあります。 セキュリティは、あなた、エンドユーザ、デバイス製造業者にとって最優先事項であるべきです。X.509 証明書を使用する場合、製造プロセスで、デバイスが一意となる証明書と秘密鍵のペアを取得するタイミングと、IoT ソリューションにどのように登録するかを明確にする必要があります。 デバイスプロビジョニングと証明書管理を検討する際のポイント : メーカーの選択 : 信頼できる証明書チェーンは、ハードウェアを社内開発または OEM パートナーを選択することから始まります。後者の場合、サプライチェーン全体で証明書の整合性が維持されていることを確認するために、そのプロセスを検査する必要があります。&nbsp; 認証局 ( CA ) : デバイスの製造に柔軟性を持たせるために、AWS では独自の CA、サードパーティの CA、 Amazon ルート認証局 ( CA ) &nbsp;など、複数の選択肢を用意しています。&nbsp; ハードウェアセキュリティモジュール&nbsp; : IoT デバイスに組み込まれたセキュアエレメントは、デバイスセキュリティの基盤を形成します。これにより、証明書やシークレットの暗号化と改ざん防止の保存、ファームウェアとアプリケーションの検証が可能になります。これを支援するために、AWS には&nbsp; AWS IoT ExpressLink を搭載したさまざまな接続モジュールがあります。これらのモジュールには AWS が要求するセキュリティ要件を実装したソフトウェアが含まれています。 外部リソース : カスタムプロビジョニングプロセスを可能にするために、IoTソリューション内でのリソース作成が必要になる場合があります。 これらのリソースは、デバイスの稼働台数が増加するにつれてスケールするように設計する必要があります。 AWS の場合、これは&nbsp; Pre-provisioning hook &nbsp;として機能する&nbsp; AWS Lambda function になる可能性があります。 デバイスレベルのロジック : デバイスには、確実かつ安全にプロビジョニングされるため、オンデバイスのロジックが必要になる場合があります。 AWS では、 AWS IoT SDKs &nbsp;はこのオンデバイスのロジックを可能にするために設計されています。 AWS IoT Core を使用したデバイスのセキュアなプロビジョニングと登録の詳細については、 AWS IoT Core Device Provisioning &nbsp;や AWS ホワイトペーパーの&nbsp; Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core &nbsp;をご参照ください。 デバイス管理 成熟したプロビジョニングのプロセスがあれば、デバイスは最初に接続したときからセキュアで最新の状態に保たれますが、ファームウェアや証明書のローテーションなどの更新が必要になる場合があります。完全にコンプライアンスを遵守し、最高のユーザーエクスペリエンスを提供するためにはこうした更新が必要です。これらの更新のためのソリューションは、配信の中断、接続性、ロールバックルーチン、自動スケーリングへの対応が必要となるでしょう。 デバイス管理戦略を検討する際の考慮事項 : デバイス整理 : デバイスをすばやく識別し操作できることで、コンプライアンスから外れた場合のトラブルシューティングと隔離が可能になります。多数のデバイスを運用する場合、デバイスの整理、インデックス作成、分類を行うソリューションが必要になります。AWS では、 Fleet Hub for AWS IoT Device Management &nbsp;を使用できます。 デバイス監視 : デバイス群のステータスを監視できることは、誤動作やコンプライアンス違反のデバイスを特定するのに重要です。デバイスのメトリクス、ログ、設定などの観測データとセキュリティデータを収集する監視ソリューションを用意してください。 AWS IoT Device Defender は、稼働している多数のデバイスのセキュリティのための監査と継続的なインテリジェントな監視を提供します。 イベントへ対応 : ログ、メトリクス、アラームの最小セットを定義することで、運用チームは大きなビジネスの中断を防ぐことができます。監視ソリューションと統合できるスケーラブルなアラートソリューションが必要です。AWS では&nbsp; Amazon CloudWatch &nbsp;を使用できます。 Over-The-Air ( OTA ) アップデート対応 &nbsp;: デバイスは更新を受信して適用できるように設計する必要があります。IoT ソリューションは更新を送信し、デバイスの更新進捗を監視できる必要があります。AWS では、 AWS IoT Device Management Jobs &nbsp;を使用できます。 このコンポーネントを支援するために、 AWS IoT Device Management 、 AWS IoT Device Defender 、 AWS IoT Core &nbsp;は、稼働している IoT デバイス全体のデバイス整理、監視、アラート、OTA 更新のための完全な機能セットを提供します。 デバイスデータの取り込み すべての IoT ソリューションがデータ取り込みに焦点を当てるわけではありませんが、そうしたソリューションでは、このデータ取り込みがプライマリなコンポーネントとなり、ソリューションの全体的なアーキテクチャに影響します。このコンポーネントに対する要件は、ソリューションのスケール、コスト、セキュリティ、パフォーマンスに影響するため、現在と将来のデータ取り込みを考慮した IoT ソリューションのアーキテクチャを設計する必要があります。 データ取り込み戦略を検討する際の考慮事項 : データサイズ : デバイスがハードウェア的に制約されていない場合、効率を高めるためにメッセージサイズを一定に 保ち、小さいメッセージをバッチ処理することを検討してください。バッチ処理は、メッセージ送信時だけでなく、IoT Core に取り込んだ後に IoT ルールを使用して実行できる ことに留意してください。 データの頻度と構造 : デバイスがメッセージを送信する頻度を考慮し、ソリューションがそのスケールに対応できるように設計してください。頻度に加えて、データの構造がメッセージベースかストリーミングベースの IoT ワークロードかを決定します。 MQTT トピック設計 : このプロトコルを使用する場合は、最小限の権限コミュニケーションを実施しつつ、将来のデバイス導入をサポートできるスキーマのバランスをとる必要があります。適切なトピックスキーマは 、柔軟なメッセージフィルタリングとメッセージルーティングを可能にする共通の命名規則を実装します。 データストレージ : メッセージのフローと使用法を分析し、適切なストレージソリューションを特定してください。これらのストレージソリューションは、ユースケース、全体的なメッセージ構造、スケール ( 現在と将来の成長 ) 、コストなど、複数の考慮事項があります。&nbsp; ルーティング : 取り込んだ後、メッセージをストレージや他のサービスにルーティングするための、ルールベースの簡単なソリューションが必要です。これらのルールは、さらなるメッセージのバッチ処理、処理、アラートなどに使用できます。&nbsp; エッジゲートウェイ : 一般的なアーキテク チャパターンは、データを取り込み、処理、バッチ処理してから IoT ソリューションに送信するゲートウェイまたはブローカーを用意することです。これは、デバイスに近いローカルエンドポイント、または IoT ソリューションに近いクラウドベースのゲートウェイとして実装できます。 このコンポーネントの支援として、AWS IoT Core を使用すると、インフラを管理することなく、 数十億ものIoTデバイスを接続 し、 Amazon SQS &nbsp;、 Amazon Kinesis 、 Amazon SNS などの他の AWS サービスに 何兆ものメッセージをルーティング できます。AWS には、エッジランタイムを提供するオープンソースの&nbsp; AWS IoT Greengrass &nbsp;もあります。AWS IoT Core を使用したデータ取り込みのパターンの詳細は、AWS IoT ブログの「 IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 」をご参照ください。 リアルタイムのビデオとデータストリーム 前のセクションで説明したものに加えて、IoT ワークロードがビデオやその他の高容量データストリームで構成されている場合は、さらにいくつかの点を考慮する必要があります。データストリームを扱う IoT ワークロードは、ビデオ処理や分析などのアプリケーション向けに、高頻度かつ非構造化の生データを扱うことが多くなります。 ストリーミングベースのワークロードを考慮するポイント :&nbsp; プロデューサ側 : データストリームがどのように生成されるかは、IoT ソリューションの下流でどのようにインジェスト、処理、保存されるかに直接影響します。 デバイスのストリーミングプロトコル、ネットワークの可用性、アクセシビリティ 、コストの制約などの側面が、ストリームの生成方法に影響します。&nbsp; コンシューマ側 : データストリームの消費と処理は、IoT ソリューションの必要なスケールと全体的なコストに影響を与える可能性があります。ビデオストリームなどの高頻度データは、高可用性で管理が容易で、スループット要件を処理できる堅牢なアーキテクチャーが必要になります。 これらのストリームの直接的なビジネス価値を総合的な IoT ソリューションで考慮して、最もコスト効果的かつスケーラブルな方法で消費および処理することを決定してください。&nbsp; このようなアーキテクチャを支援するために、AWS には AWS IoT Greengrass 、Amazon Kinesis 、 Amazon Kinesis Video Streams があります。 AWS IoT Greengrass は、エッジでデータストリームを 容易に消費および処理し、 AWS 提供のコンポーネント を介して AWS に転送できるエッジランタイムを提供するオープンソースです。 Amazon Kinesis は、 デバイスから直接 、AWS IoT Greengrass Stream manager コンポーネント から、または AWS IoT ルール から生成されるストリーミングデータをコスト効果的に処理および分析できるマネージドサービスです。 Amazon Kinesis Video Streamsは、デバイスから直接、または AWS IoT Greengrass の Edge connector for Kinesis Video Streams &nbsp;を介して生成されたビデオストリームを、ソースプロトコルに関係なく安全に表示、処理、分析できるマネージド AWS サービスです。 デバイスのコマンド・アンド・コントロール コマンド・アンド・コントロールは、デバイスにアクションの実行を要求するメッセージを送信し、成功または失敗の確認応答を受け取る操作です。これは、デバイスへのコマンドメッセージまたは IoT ソリューションからデバイスの状態を変更して伝達することで実現できます。データ取り込みとコマンド・アンド・コントロールのための IoT ソリューションのメッセージングニーズを評価および最適化することで、パフォーマンスとコストのバランスが最適になります。 デバイスのコマンド・アンド・コントロール戦略についての検討パターン : コマンドメッセージング : 選択したメッセージングプロトコルを使用して、コマンドを直接デバイスに送信します。デバイス側のロジックを実装して、コマンドの受信、実行、デバイスの実行ステータスの報告をする必要があります。このパターンでは、IoT ソリューションでコマンドメッセージを確実に配信する必要があり、デバイスがオフラインになったり接続が切断された場合には、対処可能な障害が発生することに留意してください。 デバイスの状態 : デバイスの状態は IoT ソリューションで処理し、コマンドの設定や実行ステータスの更新に使用できます。この状態は、IoT ソリューションからの変更があった際にデバイスへ送信され、デバイス自身が変更を加えた場合にもそれを送り返すことができる、単純なドキュメントとすることができます。このパターンでは、デバイスが接続されていなくても、IoT ソリューションと対話できます。 このコンポーネントを支援するために、AWS IoT Core は&nbsp; AWS IoT Device Shadow service 　、 MQTT5 リクエスト/レスポンスパターン 、AWS IoT デバイス管理は AWS IoT Job 機能 を提供しています。デバイスのコマンド・アンド・コントロールの実装パターンの詳細は、「 AWS IoT Lens for the AWS Well-Architected Framework 」の デバイスコマンド の項を参照してください。 クラウドアーキテクチャ IoT ソリューションがクラウドに存在する場合、地域を限定した1つのサービスや小規模なデバイス群から始めることができます。これは概念実証やデモンストレーションには十分ですが、ソリューションを本番に移行する際には、クラウドベースのベストプラクティスを考慮して構築されていることを確認する必要があります。「 AWS Well-Architected framework &nbsp;」は、ソリューションの設計、構築、レビューの際に、AWS を安全かつ高パフォーマンス、回復性が高く、効率的に使用していることを確認するのに役立ちます。AWS IoT におけるクラウドベースのベストプラクティスの詳細は、 IoT Lens – AWS Well-Architected Framework &nbsp;を参照してください。 まとめ このブログでは、典型的な IoT ソリューションを構成する主要な技術要素に分解し、それぞれについて考慮すべき要件と注意点を明らかにしました。IoT ソリューションの構築は間違いなく複雑ですが、AWS IoT を活用することによって、その道のりを簡素化、合理化することができます。さらに、 AWS パートナー が構築した AWS IoT ソリューションを利用することで、市場投入までの時間を短縮することもご検討ください。 著者紹介 Kai-Matthias Dickman &nbsp;は、Amazon Web Services ( AWS ) の IoT ソリューションアーキテクトです。大企業の開発者や意思決定者と協力して、AWS IoT サービスの導入を推進することを楽しんでいます。IoT とクラウドに関する深い知識を持っており、スタートアップから大企業に至る世界中のお客様と協力して、AWS エコシステムを使った IoT ソリューションの構築を可能にする役割を担っています。 Nicholas Switzer &nbsp;は、Amazon Web Services の IoT ソリューションアーキテクトです。2022年に AWS に加入し、IoT 、エッジコンピューティング、コネクテッドプロダクト分野を専門としています。アメリカに拠点を置き、日常生活を改善するスマートプロダクトの構築を楽しんでいます。 この記事は Kai-Matthias Dickman &nbsp;,&nbsp; Nicholas Switzer &nbsp;によって書かれた Deploying and managing an IoT workload on AWS &nbsp;の日本語訳です。この記事は ソリューションアーキテクト の伊藤 一成が翻訳しました。

e コマース市場は年々拡大を続けており、小売業界のさらなる変革を後押ししています。小売業者は、より多くの顧客を EC サイトへ呼び込むことに尽力しており、特にブラックフライデーやサイバーマンデーなどのピーク時の売上において、EC サイトが占める割合が高まっています。 Statista によると 、2022 年第 3 四半期、米国の小売業全体の売上において、 e コマースの占める割合は 14.8 ％ で、これは前四半期を上回っており、金額にして約 2660 億ドルになります。 小売業のリーダーが、e コマース事業から更なる価値を得る方法を模索しているのは、驚くことではありません。そのため、多くの企業がウェブサイトのトラフィックを監視し、売上に影響を与え得るオンラインアクティビティの変化の兆候を見つけ出そうとしています。例えば、トラフィックが減少することは、製品の価格設定が最適でなかったことや、システム障害などの要因により、需要が減少したことを示す可能性があります。いずれにせよ、売上は打撃を受けることになります。 一方、e コマースのトラフィックが急増することは、小売業者にとって良いことのように思えますが、必ずしもそうとは限りません。例えば、価格設定にミスがあり、オンラインショップの顧客がとんでもない安値で商品を買い占めていった場合です。最近、ある大手小売業者が、ウェブサイト上の小数点の位置を間違えて、100 ドルの人気商品をわずか 10 ドルで表示したことがありました。オンラインショップの顧客は大喜びで商品を大量に注文し、小売業者はこの不手際を修正し、さらなる損失を食い止めるために奔走することになりました。 どちらのシナリオでも、重要なのは、e コマースのトラフィックを常に把握し、発生した問題を解決するためにチームを迅速に動員することです。そこで、アマゾン ウェブ サービス（ AWS ）の人工知能と機械学習ソリューションが役に立ちます。小売業者は、ビデオやデータストリームをリアルタイムで収集、処理、分析できる Amazon Kinesis や、メトリクス内の異常を自動的に検出し、その根本原因を特定する Amazon Lookout for Metrics などのサービスから多大なる恩恵を受けることができます。 トラフィックの変動に対処する 小売業者は、e コマースのトラフィックが季節、月、日付、時間帯によって大きく変化することをご存じでしょう。例えば、多くの e コマースサイトでは、朝方の時間帯よりも夕方の時間帯でトラフィックが多くなります。また、平日ではなく、週末にトラフィックが急増するケースもあります。一方、休日やその他のピーク時のトラフィックは、これらのトレンドのいずれにも当てはまらないかもしれません。このように動的で様々なパターンがあるため、ユーザートラフィックの少数派な異常をニアリアルタイムで検出することは非常に困難です。 大規模な e コマースを展開する企業の多くは、ユーザートラフィックの主要な異常を検出するための手順をすでに整えています。しかし、これらのプロセスは、静的なアラートや手動による監視技術に依存していることが多く、少数派な異常をニアリアルタイムで検出することは困難であり、問題が起こった際にチームが迅速に介入し、対応することが難しくなっています。 小売業者は、過去のデータパターンに基づいて、ユーザートラフィックのわずかな変化を検出することができるスマートなソリューションを必要としています。しかし、静的なルールに基づいてこれらの傾向をプログラミングすることは、非常に時間がかかり、導入後の効果もあまり期待できないことがあります。 予想されるトラフィックの変動を考慮しつつも、小売業者が自動的に少数派な（そして主要な）異常を検知したい際に、AWSの異常検知ソリューションがどのように役立つかを詳しく見ていきましょう。 図1. e コマーストラフィックのための異常検知ソリューションのアーキテクチャ AWS の異常検知ソリューションとの連携 このソリューションは、データ収集と異常検知を自動化し、データを操作して、重大性に基づいて異常をフィルタリングするためのグラフィカルユーザーインターフェースを提供します。ここからは、このソリューションがどのように機能するかを説明します。 顧客は、オンラインショッピングのために e コマースアプリケーションを利用します。 &nbsp; プロセスは、顧客がモバイルまたはデスクトップアプリケーションを使用して、e コマースのウェブサイトで商品を検索し、表示することから始まります。買い物かごに商品を入れた後、決済ページで購入を完了します。これらのページのトラフィックは、時間間隔に基づくデータの塊に分解されます。これらは、トラフィックのパターンを理解するために使用できるデータポイントとして機能します。 データは、取り込まれ、変換され、保存されます。 &nbsp; e コマースアプリケーションは、複数のフォーマットと異なる量のデータを生成します。それを理解するためには、データを継続的に取り込むストリーミングプラットフォームにデータを供給する必要があります。このソリューションでは、 Amazon Kinesis Data Streams （あらゆる規模のデータストリームの取得、処理、保存を支援）を使用して、ユーザーのトラフィックを取得し、e コマースアプリケーションとのやりとりを記録します。通常、収集したデータを修正または「変換」して、迅速な分析や機械学習に適した形式で保存する必要があります。 Amazon Kinesis Data Firehose （ストリーミングデータを取り込み、変換し、データレイク・データストア・分析サービスに配信することができるサービス）や AWS Lambda （サーバーやクラスタを意識せずにコードを実行できるサーバーレス、イベント駆動型のコンピューティングサービス）などの AWS サービスは、データを変換して分析用に準備するために役立ちます。データは、どこからでもどんな量のデータでも取り出せるように構築されたオブジェクトストレージサービス、 Amazon Simple Storage Service (Amazon S3) を使って、効率的にクラウドに保存されます。 トラフィックの異常を検出し、チームに通知します。 &nbsp; データをニアリアルタイムで分析し、異常を特定する準備が整ったので、ここからが Amazon Lookout for Metrics の出番です。まずは、Amazon Lookout for Metrics で 検出器 を作成し、Amazon S3 データリポジトリからデータを自動的に取り込むことから始めます。検出器が起動すると、Amazon Lookout for Metrics はデータの監視を開始し、異常があればニアリアルタイムでフラグを立てます。誤検知を減らすために、検知システムの感度を 0 から 100 の間で調整することができます。機械学習技術を使用して、Amazon Lookout for Metrics は、トラフィックパターンからフィードバックを得て、時間の経過とともに検出結果の継続的な改善をします。当然ながら、異常があればチームメンバーに通知したくなるでしょう。通知により、ウェブサイトで何が起きているのかを理解でき、必要に応じて迅速に是正措置を講じることができるようになります。このソリューションは、 Amazon Simple Notification Service (Amazon SNS) とシームレスに統合されており、SMS テキストメッセージ、モバイルプッシュ、電子メールを通じてアラートや通知を自動的に送信することができます。 まとめ AWS の異常検知ソリューションにより、小売業者は e コマースのトラフィックを監視し、売上に影響を与え得るトラフィックパターンの異常を迅速に検知するための強力なツールを手に入れました。これは、従来の静的アラートや手動による監視技術を大きく前進させるものです。オンライン販売の拡大と不必要な損失の回避を目指す小売業者にとって、このAWSのソリューションは、コストと時間のかかる自社開発ソリューションに投資することなく、目標を達成するための効果的な方法となり得るでしょう。 各サービスの詳細は Amazon Lookout for Metrics Developer Guide Amazon Kinesis Data Streams Developer Guide Amazon Kinesis Data Firehose Developer Guide 著者について Aditya Pendyala Aditya は、NYC を拠点とする AWS のシニアソリューションアーキテクトです。クラウドベースのアプリケーションのアーキテクトとして豊富な経験があります。現在、大企業向けに、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャの構築を支援し、クラウドに関するあらゆることの案内をしています。Shippensburg 大学でコンピュータサイエンスの理学修士号を取得しました。また、彼は、” When you cease to learn, you cease to grow “という言葉を信条としています。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。

テレコム 5G および IMS コンテナベースのワークロードは、 Multus CNI を利用してトラフィックとルーティングの分離とパケットアクセラレーションを実現します。Multus コンテナネットワークインターフェイスプラグインを使用すると、Kubernetes ポッドを複数のインターフェイスとネットワークに接続できるようになります。Multus CNIは「メタプラグイン」であり、 VPC CNI ( Amazon Elastic Kubernetes Service (Amazon EKS) のデフォルト CNI)、 IPVLAN CNI などの他のCNIを呼び出すことでこれを実現します。VPC CNI は Kubernetes ポッドのプライマリインターフェイスを管理しますが、IPVLAN CNI では、ワーカーノードの Elastic Network Interface (ENI) 上の同じ MAC アドレスを使用することで、ポッドがワーカーノードのセカンダリインターフェイスを使用できるようになります。Multus CNI は、 host-local 、 static 、および whereabouts などの IPAM CNI も呼び出します。 「 Amazon EKS now supports Multus CNI 」の記事は、Amazon EKS で Multus ワークロードをデプロイし始めるのに役立ちます。Amazon EKS に Multus ベースのワークロードをプロダクション向けにデプロイするには、次の 2 つのトピックの管理を計画する必要があります。 Multus ワーカーノードグループ: ワーカーノードサブネット、およびワーカーノードの IP アドレス管理。各ワーカーノード ENI にはサブネットの IP アドレスが必要 Multus ポッドネットワーク: ワーカーノードサブネットからの Multus ポッドの IP 管理、および Amazon Virtual Private Cloud (Amazon VPC) でのポッド通信。 この記事では、標準の Multus ノードグループのデプロイ方法と、Amazon VPC 内の Multus ワークロードで ipvlan CNI を使用する際の上記のトピックを管理するための課題とアプローチについて説明します。 標準的な Multus ノードグループ導入アプローチ 上の図は、IPVLAN CNIを使用した Multus ワークロードのデプロイ例を示しており、この記事で説明していきます。この例では、Amazon EKS クラスターと 2 つのワーカーノードを持つノードグループがあります。両方のワーカーノードは、次のように 2 つのサブネットに接続されます。 eth0 ネットワーク:10.10.12.0/24 (VPC CNI、即ちポッドのプライマリインターフェイスに使用) eth1 ネットワーク:10.10.1.0/24 (Multus ipvlan cni、即ちポッドのセカンダリインターフェイスに使用) 上のサンプルデプロイ方法では、デプロイは Amazon EKS クラスターデプロイから始まり、その後に Amazon EKS ノードグループのデプロイが続きます。ノードグループがデプロイされたら、Multus CNI と関連するプラグインをデプロイしてワークロードをサポートできます。プラグインがデプロイされたら、ワークロードをデプロイできます。 次のセクションでは、Multus ワーカーノードグループと IP 管理のデプロイ戦略について説明します。 Multus ワーカーノードグループのデプロイと IP 管理 Multus ワーカーノードデプロイ 自己管理型の Multus ノードグループは、オートスケーリンググループを使用して復元力（最小限のワーカー数を維持）とスケーラビリティを提供します。オートスケーリンググループは、 起動テンプレート を使用して Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードを構成します。オートスケーリンググループは、起動テンプレートと組み合わせて、同じサブネットに属する単一または複数のインターフェースを持つワーカーノードを作成できます。カスタムデプロイメント戦略では、カスタム AWS Lambda を使用して、異なるサブネットからの複数のネットワークインターフェイスアタッチを実現します。これにより、Amazon EC2 オートスケーリングライフサイクルフックに Multus インターフェイスが追加されます。 次の図に示すように、デプロイメントはオートスケーリンググループが起動テンプレートを使用して単一インターフェイス (eth0) のワーカーノードを作成するところから始まります。ワーカーが起動すると、カスタム Lambda が単一のインターフェイスノードを終了します。このスケールインにより、「autoscaling: EC2_INSTANCE_TERMINATING」イベントが発生し、カスタム Lambda がトリガーされてからノードをドレインします、もしくは何も行われません。 このイベントが完了すると、オートスケーリンググループは必要な容量を満たすためにスケールアウトし、「autoscaling: EC2_INSTANCE_LAUNCHING」イベントが発生します。このイベントはカスタム Lambda 関数をトリガーし、タグ (key: node.k8s.amazonaws.com/no_manage 値: true) を使用して Multus サブネットからセカンダリインターフェイスを追加します。 EKS Multus ノードグループの作成フロー ワーカーノードの IP 管理に関する課題 オートスケーリンググループは、Amazon EKS ワーカーノードグループに弾力性と復元力を提供し、すべてのインターフェイスに DHCP IP 割り当てを使用して同じようにサポートします。一方、Multus ポッドの場合、非 VPC IPAM CNI（ host-local 、 whereabouts 等）は、静的アドレス範囲/プールを使用してセカンダリインターフェイスでの IP 割り当てを管理します。ポッドの出力/入力は対応するワーカー ENI を介して行われるため、ポッド IP とワーカー ENI IP アドレスはサブネットから取得する必要があります。アプリケーション計画者は、Multus network-attachment-definition の構成とアノテーションによって、Multus ポッドの静的 IP 範囲を割り当てます。 同じサブネット上の 2 つの異なる別々の IP 割り当て方法 (DHCP と静的) は、ワークロードのデプロイにおいて興味深い課題となります。DHCP によるワーカーノードの IP 割り当てはランダムであり、他の静的割り当てを認識しないため、ポッドに対して計画された静的 IP 範囲から任意の IP アドレスを取得できます。Multus IPAM CNI ( host-local 、 whereabouts 等) は、この割り当てを認識しません。この IP アドレスがワーカーインターフェイスによって取得されると、アプリケーションポッドで IP 競合が発生し、IP 割り当てが失敗し、予期しないアプリケーションのデプロイが発生してしまいます。 ソリューション 以下のセクションでは、ワーカーノードと Multus ワークロードの IP アドレスを競合しない方法でより適切に管理するための 2 つの方法を紹介します。 アプローチ 1: カスタム Lambda を使用してワーカー IP を静的に割り当てる このソリューションアプローチは、ワーカーとポッド間の論理サブネット共有モデルで機能します。このアプローチでは、ワーカーノードはサブネットの最初から未割り当ての IP を取得し、Multusポッドはサブネットの終わりから未割り当ての IP を取得します。この割り当て戦略では、IP アドレスはワーカーノードインターフェイスにランダムに割り当てられるのではなく、IP 割り当てはサブネットで最初に空いている空き IP から静的に行われます。 詳細な説明、サンプル AWS CloudFormation テンプレート、サポートされている Lambda 関数については、GitHub リポジトリ「 Allocate Worker IPs statically via a custom lambda-based solution 」を参照してください。 アプローチ 2: ポッドの IP アドレスに VPC サブネット CIDR 予約 (静的) を使用する このアプローチでは、 VPC サブネット CIDR 予約 戦略を使用して、ワーカーノードと Multus ポッドの IP アドレス割り当てを分離します。このアプローチでは、Multus ポッドの IP CIDR 範囲を静的として明示的に予約でき、Amazon EC2 ワーカーノードの DHCP がこのブロックからワーカーノードに IP アドレスを割り当てないようにすることができます。 これを実現する為に、明示的 (静的) 割り当てのみを目的として、ポッド IP アドレスの塊に対して 1 つ以上のサブネット CIDR 予約を作成できます。サブネット CIDR の予約されていない塊は、オートスケーリンググループの背後にあるワーカーノードへの DHCP（デフォルト）割り当てに使用できます。 詳細な説明、サンプルの CloudFormation テンプレート、およびサポートされている Lambda 関数については、GitHub リポジトリ「 Use VPC subnet cidr reservation (static) for pods IP addresses 」を参照してください。 自動 Multus ポッドネットワーキング Amazon EKS クラスターと Multus ノードグループが前述のアプローチのいずれかでデプロイされたので、Multus を使用して Amazon EKS にワークロードをデプロイできます。次のステップとして、 git リポジトリ に記載されているように Multus CNI をデプロイし、 whereabouts IPAM CNI をインストールします。この記事では、 whereabouts IPAM CNI を使用してクラスターの一意の Multus IP アドレスを管理しています。 ここで、VPC での IP 通信の仕組み、ルーティングを有効にする方法、および自動化された方法で Multus ポッドに IP を割り当てる方法を理解しましょう。 Multus ポッドのIP 管理とルーティングの課題 次の例では、Multus ポッドをデプロイすると、セキュリティグループルール/NACL がトラフィックをブロックしていない場合でも、異なるワーカー上のポッド間通信が機能しないことに留意してください。ただし、同じワーカーノード上のポッド間の相互通信は正常に機能します。 ここでは、この動作について詳しく説明します。Amazon VPC クラウドは、ワークロードにレイヤー 3 ネットワーキングを提供します。ENI は、1 つ以上の IP アドレスと対応する MAC アドレスを含む論理ネットワークエンティティです。Amazon VPC は、ENI に割り当てられた IP アドレスに基づいて、トラフィックを正しい宛先にルーティングします。Amazon EC2 ワーカーノードに接続されている各 ENI には、適格な IP アドレスが割り当てられている必要があります。 ポッドのプライマリインターフェイスでは、Amazon VPC CNI は DHCP を使用してプライマリポッド IP アドレス (上の図では 10.10.12.x) をポッド eth0 (VPC CNI マネージドインターフェイス) に割り当て、これらの IP をワーカーノード ENI のセカンダリ IP として割り当てます。非 VPC IPAM CNI (whereabouts、host-local、static 等) は、IP アドレスを Multus ポッドに割り当てます。したがって、Amazon VPC はこの IP アドレスの割り当てを認識しません。さらに、これらの IP アドレスは、それぞれのワーカーノード ENI (上の図では eth1) のセカンダリ IP として割り当てられません。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで同じことを確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 この問題は、ポッドが想定する IP アドレスがそれぞれのワーカー ENI に割り当てられると解決されます。これらの IP がそれぞれの ENI (例: eth1) に割り当てられると、Amazon VPC は割り当てられた IP の マッピングを ENI へ更新し、指定された Multus IP アドレスにトラフィックをルーティングします。 次の例では、Multus ポッド IP アドレス 10.10.1.80 および 10.10.1.82 が、最初のワーカーノードの eth1 ENI 上のセカンダリ IP アドレスとして割り当てられます。同様に、10.10.1.81 セカンダリ IP が 2 番目のワーカーノード eth1 ENI に割り当てられます。 自動化ソリューション Amazon EC2 の IP アドレスの割り当て/IP アドレスの割り当て解除 API 呼び出しにより、ワーカーノード ENI での IP 割り当てを自動化できます。 git リポジトリ にあるサンプル Python コードとスクリプトでも同じ結果が得られます。 以下で説明する自動化アプローチでは、アプリケーションイメージやソースコードを変更する必要はありません。これらのポッドでカスタムの「IP 管理」コンテナを利用して、アプリケーションコンテナやそのアーキテクチャに影響を与えることなく、それぞれのワーカーノード ENI で IP 割り当ての自動化を実行できます。この追加のコンテナを使用して、ワークロードの pod/deployment/statefulset の仕様を強化できます。 この機能を提供し、次のいずれかのソリューションオプションで使用できる Docker コンテナイメージをビルドするには、「 How to build 」を参照してください。 アプローチ1: InitContainer ベースのIP 管理ソリューション このソリューションは、フローティング IP (次のアプローチで説明) などの特別な処理やカスタム処理を行わなくても、ほとんどの ipvlan CNI ポッドで機能します 。このアプローチでは、ワーカーに追加の CPU/メモリ要件の制約が追加されません。 この「IP 管理」コンテナは、ポッドが init 状態のときに最初のコンテナとして実行されます。このコンテナは、ポッドが初期 (init) 状態にあるときに、ポッドの IP アドレスを確認し、その IP アドレスを ENI に割り当てます。Multus IP アドレスがワーカーノード ENI に正常に割り当てられると、この initContainer は終了し、ポッドは初期状態から抜け出します。 このソリューションを使用するには、 InitContainer IP management ドキュメントとデプロイ手順を参照してください。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで、同じことを確認できます。Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 アプローチ 2: サイドカー IP 管理ソリューション このアプローチでは、「IP管理」コンテナはサイドカーコンテナとして動作します。さらに、initContainer とは異なり、Multus インターフェイス上のポッド IP アドレスを常に監視して、新規または変更された IP アドレスがないかどうかを確認します。これは、アクティブ/スタンバイポッドに対するカスタムの「フローティング IP」処理を持つポッドにとって役立ち、内部ロジックに基づいて、トラフィックを中断することなく「フローティング IP」がスタンバイポッドにフェイルオーバーします。この場合、サイドカーは IP アドレスの変更についてポッドを常に監視するため、Multus ベースのポッドごとにこのコンテナ用の CPU/メモリ (最小限) が追加で使用されます。 このソリューションを使用するには、 Sidecar IP management Solution のドキュメントと手順を参照してください。 Amazon EC2 コンソールで確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 クリーンアップ この記事でデプロイされたサンプル Multus ワークロードをクリーンアップするには、GitHub リポジトリの「 Cleanup 」を参照してください。さらに、今後の料金の発生を避けるために、CloudFormation コンソールから Multus Worker ノードグループを削除してください。Amazon EKS クラスターは Amazon EKS コンソールから削除できます。 まとめ この記事では、Amazon VPC クラウド内のワーカーノードと Multus ポッドの IP アドレスの IP 割り当て、管理、分離の際にお客様が直面する課題について説明しました。さらに、Multus ポッドがどのように Amazon EKS および Amazon VPC スコープで動作し、VPC内 でトラフィックをルーティングするかについても説明しました。 加えてこの記事では、ソフトウェア/イメージを変更することなく、Amazon EKS ノードグループと Multus ポッドの IP 管理自動化の、自動化サンプルメソッドも提供しております。 分かり易くするために、この記事の上の例では IPv4 の処理のみを説明しました。但し、 git リポジトリ のサンプル コードは IPv6 もサポートしています。様々なアプリケーションアーキテクチャやユースケースに応じて、git リポジトリ内のサンプル ソースコードをさらに調整して頂けます。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) Raghvendra Singh Raghvendra Singh は AWS 5G および AWS のネットワークトランスフォーメーションプラクティスのスペシャリストです。彼は AWS の 5G ソリューション設計全体、E2E 統合、ネットワークアーキテクチャ、自動化、セキュリティ全般を担当しています。彼は 4G/5G NFV 分野を専門とし、お客様が AWS 上でクラウドネイティブのコンテナネットワーク機能を導入および統合できるよう支援しています。

従来から、通信サービスプロバイダ (CSP) は Virtual Routing and Forwarding (VRF) 技術を使用して、データセンター (DC) ネットワークをネットワークドメインごとに分離しています。例えば、運用管理 (OAM)、シグナリング、ローミング、ユーザートラフィックネットワークなどのドメインなどです。また、データセンターの各 VRF ドメインを他のデータセンターと同等の VRF に接続して、ネットワークを地域的および全国的にカバーする必要があります。さらに、CSP がエンドカスタマーに提供するサービスでは、CSP がマルチ VRF ベースのネットワークをネットワーク分離したまま、外部のプライベートネットワークに拡張する必要があることもよくあります。従って、DC 間接続と通信ネットワーク拡張の両方で、ネットワーク分離（VRF）を維持し、複数の自律システム（AS）サポートを相互接続するための特定の要件が生じます。一般的な解決策として、 RFC4364 ではこの要件に対応する 2 つのオプションが導入されています。オプションA は、RFC 4364 の VRF to VRF 接続により、ネットワーク間相互接続（NNI）の両側のルーティングコンテキストが 1:1 で調整されることを意味します。また、オプションB は、NNI のラベルスイッチングパラダイムに基づくマルチプロトコルラベルスイッチング（MPLS）AS 間接続を、グローバル QoS ポリシー、強化スキーム、および単一のMP-eBGPセッションを備えた単一の MPLS 対応論理インターフェイスで使用します。AWS で実行されているアプリケーションを、既存のマルチ VRF で分離されたネットワーク上のワークロードに相互接続する場合、この要件とソリューションを実装する必要があります。最初で最も簡単な方法として、RFC4364 オプションAの方法で、アプリケーションを個別の Amazon Virtual Private Cloud（Amazon VPC）に分離し、各 VRF にマッピングすることを考えることができます。これは次の図1に示すように、オンプレミスの VRF と AWS 上にマップされた VPC の間に個別の AWS Site to Site (S2S) VPN または AWS Direct Connect (DX) で接続することにより実現します。 図1 VRF から VPC への相互接続 (RFC4364 オプション A) これはうまく機能し分かり易いですが、ネットワークアプリケーションをそれぞれの VPC に分離できる場合にのみ機能します。ただし、仮想ネットワーク機能（VNF）やコンテナネットワーク機能（CNF）などの通信ネットワークアプリケーション/アプライアンスのほとんどの場合、特定のアプライアンス（EPC（evolved packet core）や 5GC（5G Core）等）では、複数のネットワークドメインを1つの VPC 内に限定する必要があります（OAM VRF、シグナリングネットワーク VRF、ユーザープレーン VRF、ローミングインターフェイス VRF 等）。これにより通常、ネットワーク分離の要件を維持したまま通信サービスプロバイダのネットワークと AWS 間のネットワーク拡張を実装しようとすると、複雑さとコストが増えます。そのため、特に AWS 上の通信アプリケーションに 1 つの VPC アーキテクチャを使用する場合は、ベストプラクティスを検討することが合理的です。 図 2 VRF から単一 VPC への相互接続 この記事では、AWS と複数の VRF で分離された CSP ネットワーク間にハイブリッドネットワークを構築するための 5 つの実行可能なデザインパターンを紹介します。1) Customer Gateweay (CGW) のルートフィルター オプション設定によるパターン、2) AWS Transit Gateway (Transit Gateway) ルートテーブルの分離によるパターン、3) Transit Gateway ルートテーブルの分離と Transit Gateway Connect によるパターン、4) VPC 内の仮想ルータアプライアンスによるパターン、及び 5) Multi-VPC ENI Attachments 機能を使用したパターン、の5つです。パターン 1 ～ 3 及び 5 では、オンプレミス側プロバイダエッジ (PE) ルーターまたは Transit Gateway の各側で微調整された構成を持つネイティブ AWS ネットワーキング構造を使用します。一方パターン 4 では、RFC4363 オプション B 構成を実装するために、VPC 内に仮想ルータアプライアンスが必要になります。これら 5 つのパターン以外にも他のオプションが存在する可能性がありますが、これらを一般的なアプローチとして、また AWS の VPC アーキテクチャと既存の VRF 分離ネットワークの両方への影響を最小限に抑えるベストプラクティスとして紹介します。 パターン 1 – CGW（プロバイダエッジ（PE）ルータ）でルートマップ IN フィルタを使用して VRF を単一の VPC に接続する 最初のデザインパターンは、最もシンプルな AWS ネットワーク構成方法で、VRF ごとに個別 Site to Site (S2S) 仮想プライベートネットワーク (VPN) または Direct Connect (DX) 仮想インターフェイス (VIF) を利用し、PE ルータ側に特定の構成を行います。前の章で説明したように、1つの VPC が AWS ネットワークの 1つのルーティングドメインになります。したがって、S2S VPN または DX を介して VRF 分離が存在するオンプレミスネットワークに Amazon VPC を接続すると、すべての VPC CIDR 範囲が接続されているすべてのピア VRF に広報されます。この際、各 VRF ルータ（VPC への各 S2S 接続の CGW としても見られます）のルートポリシーマップは、各 VRF 向け他 Amazon VPC サブネットからの干渉を受けないように実装されることができます。このインバウンドルートポリシーは、Amazon VPC 内の Amazon Virtual Private Gateway (VGW) との BGP 関連付けを介した現在の VRF とは関係のない、広報されたサブネットをフィルタで除外するために、適用される必要があります。つまり、このパターンでは、オンプレミス VRF ルータ側での事前設定が必要ですが、各 VRF 対応にマッピングする事前定義された Amazon VPC サブネットに関する情報も必要になります。このプライベートネットワーク側の構成に加えて、インスタンスとサブネットインターフェイスでセキュリティグループとアクセス コントロールリスト (ACL) を使用して、セキュリティ及び分離の適切な境界を設定する必要もあります。これにより、VPC 内でのネットワーク分離を実装可能とします。 図3 デザインパターン1; PE ルータでルートフィルタを使用する 図 3 の VRF1 ルータの場合、VPC が VPC CIDR 10.0.0.0/16 範囲全体を広報している一方で、VRF-1 サブネットが VPC で 10.0.10.0/24 として事前に設定されている場合に、ルートマップフィルタ設定例を次のように記載できます。S2S VPN または DX 接続を介して広報された複数の VPC CIDR 範囲を受信してフィルタリングするには、広報するプレフィックスごとに新しいセカンダリ VPC CIDR を設定し、その CIDR から VPC サブネットを作成する必要があることに留意ください。DXと S2S VPN は、プライマリ VPC CIDR だけでなく、セカンダリ VPC CIDR ごとに1つの VPC CIDR プレフィックスを広報します。これにより、オンプレミスの CIDR に基づいてフィルタリングできます。 router bgp 65001 network 169.254.205.58 neighbor 169.254.205.57 remote-as 64512 neighbor 169.254.205.57 route-map SET-LOCAL-PREF in ! route-map SET-LOCAL-PREF permit 10 match ip address 2 set local-preference 120 ! route-map SET-LOCAL-PREF permit 20 ! access-list 2 permit 10.0.10.0 0.0.0.255 access-list 2 deny any パターン2 – Transit Gateway ルートテーブル分離を使用する マルチ VRF 用の個別の S2S VPN または DX VIF がある（つまり、各 S2S VPN または VIF が各 VRF に個別にある）場合は、それらを使用して各 VRF を単一の VPC に接続できます。この環境では、AWS Transit Gateway (TGW)と Transit Gateway ルートテーブル を使用して、VPC CIDR のルート伝播を各 VRF に分けることができます。このアプローチ（および次のパターン3）で覚えておくべく留意点の1つは、Transit Gateway はデータトラフィックの料金がかかるため、大量のトラフィックを処理する必要がある通信サービスプロバイダの 4G/5G コアネットワークのユースケースにてユーザートラフィックの伝送には、最適なオプションとはならない可能性がある点です。次の図4に示すように、このデザインパターンの重要な考え方は、VRF 側への Amazon VPC の伝播を無効にし、代わりに各 VRF 専用ルートテーブルで静的ルートを定義して、VPC CIDR 範囲内の対応するサブネットのみを含むようにすることです。次の図例では、結果として、PE ルータの VRF1 側は Transit Gateway 側の BGP 広報から Private-VRF1 サブネット範囲のみを受信し、VRF2 側では Private-VRF2 サブネット範囲のみを参照します。前のデザインパターンと同様に、VPC 内のネットワーク分離は、各サブネットレベルとインスタンスレベルで NACL とセキュリティグループを介して実装する必要があります。 図4 デザインパターン2; TGW ルートテーブル分離を使用する パターン3 – 単一の DX Transit VIF を介して Transit Gateway Connect を使用する 前のパターンと似ていますが、DX 接続が1つだけ存在する場合は、 Transit Gateway Connect 機能がより効果的です。Transit Gateway Connect は、単一の DX Transit VIF を介して複数の AS 及び複数の VRF ネットワークを AWS に相互接続する方法を提供します。これにより、Generic Routing Encapsulation (GRE) と Border Gateway Protocol (BGP) を使用したオンプレミスデータセンタと AWS ドメイン間の物理ネットワーク接続を簡素化できます。 図5 デザインパターン3; TGW Connect と TGW ルート テーブルの分離を使用する 上の図は、複数の VRF を使用した複数の Transit Gateway attachment タイプ Connect の実装を示しています。Direct Connect Gateway（DX-GW）はTransit VIF で構成され、Transit Gateway の CIDR 範囲を広報します。DX-GW は Transit Gateway に接続されるため、DX-GW アタッチメントが作成されます。DX-GW アタッチメントは、Transit Gateway attachment タイプ Connect のトランスポートになります。Transit Gateway attachment タイプ Connect を作成したら、Connect ピア (GREトンネル) を作成してオンプレミス VRF で GRE + BGP を設定します。Transit Gateway の GRE 外部 IP アドレス (ピア IP アドレス) は、Transit Gateway CIDR からの任意の IP になり、VRFアプライアンス側の GRE 外部 IP アドレスは、オンプレミスの PE ルータから広報されたアドレスのいずれかになります。CIDR ブロック内の BGP は、169.254.0.0/16 範囲の /29 CIDR である必要があります。/29 IPv4 範囲の最初のアドレスは、 VRF アプライアンスの BGP ピア IP アドレスになり、他の 2 つのアドレスが Transit Gateway BGP ピア用に選択されます。すべての GRE 接続に対して 2 つの BGP ピアを設定でき、これにより各 GRE トンネル内に組み込みの冗長性が提供されます。各 Transit Gateway タイプ Connect には、トラフィックを分離するための独自の Transit Gateway ルーティングテーブルがあります。VPC アタッチメントがルーティングテーブルの伝播に追加されると、VPC CIDR は VRF に動的に伝播されます。オンプレミス VRF は、対応する Transit Gateway attachment タイプ Connect がルーティング テーブルの伝播に追加されると、それぞれのルーティングテーブル上でそのネットワークを広報します。前のパターンと同様に、この場合も NACL とセキュリティグループを使用して VPC 内のネットワーク分離を確認する必要があります。 パターン 4 – 仮想ルーターアプライアンスを使用した VRF 分離 (RFC4364-オプション B) VPC 内の仮想ルータアプライアンスによって構築されたオーバーレイネットワークの使用を考慮できます。次の図が示すように、オンプレミスネットワークの PE ルータとこの仮想ルータアプライアンスの間に、MPLS over GRE 接続を介して確立されたオプション B のネットワーク間インターフェイス (NNI) を作成できます。 図6 デザインパターン4; 仮想ルータアプライアンスによるオーバーレイネットワークの使用 簡単な検証のため、このアーキテクチャは、AWS Marketplace の Juniper Networks Virtual SRX (vSRX) を使用して、次の図の例示的な構成でテストできます。VPC1 のルータアプライアンスの左側はオンプレミスの PE ルータを模倣し、別の VPC2 のルータアプライアンスの右側は、オーバーレイネットワークを提供する VPC 内の仮想ルータアプライアンスを表します。これにより、両方の VPC がインターネット上の S2S VPN 経由で接続されるようになります。 図7 デザインパターン4の検証環境例 このデモ環境では、異なる MPLS L3 VPN から/へのトラフィックは、AWS Transit VPC の仮想ルーターアプライアンス上で終端される単一のオプション B オーバーレイ接続を介して多重化されます。この仮想ルータアプライアンスは、対応するルートターゲットをインポートおよびエクスポートすることで、ローカルに設定された複数の VRF にフローを明確化し、AWS Transit VPC 内の 1 つまたは複数のサブネットにバインドできます。以下は自律システム境界ルータ (ASBR) として機能する vSRX の構成例です。 [edit configuration] routing-instances { vSRXForWorkload-LAN1 { interface ge-0/0/1.0; instance-type vrf; route-distinguisher 65002:1; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload1; vrf-table-label; } vSRXForWorkload-LAN2 { interface ge-0/0/2.0; instance-type vrf; route-distinguisher 65002:2; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload2; vrf-table-label; } } 共通または異なるルートターゲットに基づくインポート及びエクスポートポリシーの適格な組み合わせも実装できます。AWS 側では、これらの各サブネットを同じ VPC に属する共通または専用のルートテーブルに関連付けることができます。サブネットルートテーブルごとに、VPC 内で異なるルーティングルックアップを実装できます。さらに、ルーティングコンテキスト間の分離を実現でき、前のパターンと同様に NACL とセキュリティグループを使用することもできます。 パターン 5 – Multi-VPC ENI Attachments を使用した VRF 分離 Multi-VPC ENI Attachments は、VPC レベルの分離を通じてアプライアンスが複数の個別のネットワークインターフェイスを持つことをサポートする機能です。この機能により、図 8 及び 図 9 に示すように、VPC の分離を維持しながら、アプライアンスなどのネットワーク機能が複数の ENI を持つことが可能になります。 図8 – デザインパターン5 の検証環境例 (TGW 使用) 図9 – デザインパターン5の検証環境例（VGW 使用） 図 1 で前述したように、このアーキテクチャは RFC4364 オプション A に準拠しており、各オンプレミス VRF を専用 VRF VPC に接続します。Multi-VPC ENI Attachments 機能により、ネットワーク機能アプライアンスを複数の VRF に接続できます。このアーキテクチャを使用する場合、パターン 2 と同様に、VRF-VPC ごとに個別の TGW ルートテーブルを使用する (図 8) か、ネットワーク要件に基づいて各 VPC で VGW を使用する (図 9) かを選択できます。 まとめ 一般的なクラウドの概念では、Amazon VPC は 1 つのルーティングドメインを提供する単一のフラットネットワークであるため、一致する VRF ごとに個別の VPC を持つことが最もシンプルな方法になります。ただし、4G/5G コア ネットワーク (UPF や PGW など) のようなアプリケーションでは、ルータをプライベートネットワークの複数の VRF に接続する必要がありますが、これらアプリケーションは通常、複数の VPC に分割することが出来ません。従って、VRF で分離されたプライベートネットワークへの単一 VPC の統合というこの課題は、AWS 上でのモバイルネットワーク実装のコンテキストで表面化することがよくあります。この記事では、Amazon VPC を VRF で分離されたオンプレミスのプライベートネットワークに接続するための 5 つの異なるアプローチについて説明しました。これは、AWS 上に 5G コアネットワークやプライベート 4G/5G ネットワークを構築するなど、通信業界のユースケースで必要になることがよくあります。各アプローチには、実装の複雑さ、運用コスト、スケーラビリティと性能要件の制約に関して長所と短所があります。よって、リストされたアプローチを使用した詳細な実装は、ユースケースの環境に応じて決定されることを推奨します。 &nbsp; 長所 短所 パターン 1: PE ルータ（CGW）のルートマップフィルタ Amazon VPC 向けの最もシンプルな構成（S2S VPN, DX, VGW, Transit Gateway, サブネットルートテーブル） 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） PE ルータにはフィルタリング設定が必要 パターン2: 複数の S2S VPN または VIF を使用した Transit Gateway ルートテーブルの分離 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） 静的ルートの Transit Gateway ルートテーブルの設定が必要 Transit Gateway の使用が必要 パターン3: Transit Gateway ルートテーブルの分離、及び単一の Transit VIF を使用した Transit Gateway Connect 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 単一の VIF を活用 PE ルータには GRE のサポートが必要であり、GRE の制限（フローごとの制限等）に留意する必要がある 静的ルートの Transit Gateway ルートテーブルの設定が必要 Transit Gateway の使用が必要 パターン4: 仮想ルータベース ネットワークエンジニアにとって最も分かりやすい（従来の通信ネットワーク向け） オーバーレイおよびアンダーレイネットワークを構築するための追加コスト/複雑さ（高可用性、スケーラビリティ、性能に関する懸念を含む） パターン5: Multi-VPC ENI Attachments の使用 Amazon VPC 向けの最もシンプルな構成（S2S VPN, DX, VGW, Transit Gateway, サブネットルートテーブル） 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) 著者 Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワールドワイドテレコムビジネスユニットのプリンシパルテレコムソリューションアーキテクトです。彼は 5G 分野を専門としており、通信領域のパートナーや顧客と協力しながら、AWS 上で通信ワークロードの構築やデプロイをしています。 Gonzalo Gomez Herrero Gonzalo Gomez Herrero は、AWS テレコムビジネスユニット EMEA チームのプリンシパルソリューションアーキテクトです。彼は20年以上にわたり、ネットワーク設計、エンジニアリング、計画、導入、および運用において世界中の通信サービスプロバイダをサポートしており、さまざまな役割にわたってコンサルティング、プロフェッショナルサービス、ソリューションアーキテクチャを提供してきました。Gonzalo は、サラゴサ大学で電気通信工学の修士号を取得し、ミュンヘン工科大学でコンピューターサイエンスの大学院研究を行いました。 Ammar Latif Ammar Latif は AWS のプリンシパルテレコムソリューションアーキテクトです。彼は、クラウドテクノロジーを使用してビジネス上の課題に取り組むお客様を支援しています。これまでのキャリアを通じて、Ammar は世界中の多くのテレコムおよびメディアのお客様と協力してきました。Ammar はニュージャージー工科大学で博士号を取得しています。 Matt Lehwess Matt Lewess は AWS のシニアプリンシパルソリューションアーキテクトです。マットは、ネットワークサービスプロバイダ分野でネットワークエンジニアとして長年働いており、アジア太平洋地域と北米で大規模なWANネットワークを構築し、データセンタテクノロジーとそれに関連するネットワークインフラストラクチャを展開してきました。その結果、彼は Amazon VPC、AWS Direct Connect、およびその他の Amazon のインフラストラクチャに焦点を当てた製品やサービスを最もよく使って作業しています。Matt は AWS のパブリックスピーカーでもあり、AWS クラウドプラットフォームを使用してお客様が大規模な問題を解決できるよう支援しています。仕事以外では、Matt は屋内と屋外の両方で熱心なロッククライマーであり、熱心なサーファーです。 Young Jung Young Jung 博士は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトです。彼の主な焦点とミッションは、テレコムの Core /RAN パートナーとお客様が AWS 環境でクラウドネイティブ NFV ソリューションを設計及び構築出来るように支援することです。また、AWS のサービスとテクノロジーを活用したテレコムエッジサービス実装のため、通信業界向けの AWS Outposts のユースケースも専門としています。

通信サービスプロバイダ (CSP) が AWS 上に Long Term Evolution (LTE) または 5G ネットワーク機能をデプロイする場合、SGi (LTE の場合) または N6 (5G の場合) インターフェイスを介したユーザープレーンデータネットワークのブレークアウトに関するさまざまなオプションが存在します。3GPP は、SGi インターフェイスをパケットデータネットワーク（PDN）ゲートウェイ（S-GW およびP -GW）とデータネットワーク間の基準点として定義しています。さらに、N6 はユーザープレーン機能（UPF）とデータネットワークの間の基準点として定義されています。PDN は、公共の外部（インターネットなど）データネットワーク、プライベートパケットデータネットワーク（VPNなど）、またはオペレータ内パケットデータネットワークとすることができます。 この記事では、非ローミングシナリオでの AWS 上での LTE または 5G UPF のデータネットワークブレークアウトオプションについて説明します。UPF という用語は、3GPP TS 29.244 に記載されているように、SGW-U、PGW-U、TDF-U、UPF などのノードを指します。この記事では、PGW-U を P-GW と呼びます。 図 1: LTE の P-GW およびデータネットワーク (インターネット) 間の SGi インターフェイス 図2: 5G の UPF とデータネットワーク (インターネット) 間の N6 インターフェイス ソリューション設計 AWS 上の LTE または 5G ネットワークは、CSP によってパブリックネットワークまたはプライベートネットワークとして運営されています。各ネットワークタイプは、通常パブリックネットワークの消費者市場に関連する Enhanced Mobile Broad Band（eMBB: 高速大容量通信）、自動運転車に関連するユースケースのような遅延に厳しい要件がある Ultra Reliable Low Latency Communications（URLLC: 超信頼・低遅延通信）、データを送信する多数のデバイスをサポートするMassive Machine Type Communications（mMTC: 多数同時接続）など、様々なタイプのユースケースに対応します。ユースケースが何であれ、ユーザープレーンのトラフィックは P-GW または UPF を出てアプリケーションへ到達します。AWS 上でネットワーク機能を実行する場合、データネットワークにアクセスするにはさまざまな方法があります。5G UPF 機能をリファレンスとして使用する様々なブレークアウトアーキテクチャについて説明します。 設計1: AWS Internet Gateway 経由のパブリックデータネットワーク (インターネットなど) へのユーザープレーンのブレークアウト このアーキテクチャでは、N3 トラフィックはオンプレミスから AWS 上の UPF に到達します。UPF は、N6 インターフェイスに送信する前に、NAT を実行してユーザー機器 IP（UEIP）を UPF ENI IPに変換します。N6 ユーザープレーンのトラフィックブレイクアウトは、AWS Internet Gateway (IGW) 経由でパブリックデータネットワークであるインターネットに送られます。IGW は、VPC とインターネット間の通信を可能にする、水平方向に拡張された冗長で可用性の高い仮想プライベートクラウド (VPC) コンポーネントで、IPv4 とIPv6 のトラフィックをサポートしています。このアーキテクチャの UPF には、N6 トラフィックがインターネット宛先に到達するための1つ以上のパブリック IP アドレス（Elastic IP アドレスなど）が割り当てられています。N6 Elastic Network Interface (ENI) サブネットの VPC ルーティングテーブルには、インターネットトラフィック宛先のネクストホップとして IGW があります。 設計2: CSP のオンプレミスネットワークを介したパブリックデータネットワーク（インターネットなど）へのユーザープレーンのブレークアウト このアーキテクチャは、N6 トラフィックがルーティングでオンプレミスネットワークに戻ることをを示しています。このアプローチでは、AWS 上に配置されている UPF との間のユーザープレーントラフィックがヘアピンされます。このタイプのアーキテクチャを使用する CSP は、インターネットへの既存の ISP 接続またはエンタープライズ顧客へのプライベート接続を引き続き活用できます。N6 ENI サブネット向けの VPC ルーティングテーブルには、インターネットトラフィック宛先向けのネクストホップとして &nbsp; AWS Transit Gateway &nbsp;&nbsp;があります。Transit Gateway では、N6 データネットワークトラフィックは N6 Virtual Routing and Forwarding（VRF）セグメントに戻され、オンプレミスに到達します。 設計3: AWS Site-to-Site VPN によるプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、UPF からの N6 トラフィックが、 &nbsp;AWS Site-to-Site VPN または VPN アプライアンスを使用する安全な VPN 接続を介してサードパーティのロケーションに向けて終端するプライベートネットワークの一般的なユースケースとなります。AWS Site to Site VPN サービスは、仮想プライベートゲートウェイまたは AWS 側の Transit Gateway を使用して確立できます。Site to Site VPN の設定の詳細については、 こちら をご覧ください。AWS Site to Site VPN の単一の VPN 接続の帯域幅容量 (1.25Gbps) を考慮に入れる必要があります。ただし、複数 VPN トンネルの等価コストマルチパス（ECMP）では、トラフィックが必要とする全体帯域幅を増加させることも可能です。 設計4: VPC ピアリングによる AWS 上のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、5G ネットワーク機能とユースケースアプリケーションの両方が AWS 上のそれぞれの VPC 上で動作するプライベートネットワークの一般的なユースケースとなります。2 つの VPC は VPC ピアリングを使用して相互接続されます。VPC ピアリング接続は、プライベート IPv4 アドレスまたは IPv6 アドレスを使用してトラフィックをルーティングする 2 つの VPC 間のネットワーク接続です。いずれかの VPC 内のインスタンスまたはワーカーノードは、あたかも同じネットワーク内にあるかのように相互に通信できます。N3 トラフィックがオンプレミスから AWS 上の UPF に到着すると、UPF は NAT を実行して UEIP を UPF ENI IP に変換してから N6 インターフェイスに送信します。UPF からの N6 データネットワークトラフィックは、VPC ピアリングをネクストホップとして使用してアプリケーション VPC にルーティングされます。完全修飾ドメイン名 (FQDN) アプリケーションアドレスは、ネットワーク機能 VPC をアプリケーション VPC の Amazon Route 53 プライベートホストゾーンに関連付けることで解決されます。 設計5: Transit Gateway 経由の AWS 上のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、プライベートネットワークの他の一般的なユースケースの 1 つです。5G ネットワーク機能とユースケースアプリケーションの両方が AWS 上のそれぞれの VPC 上で 動作します。2つのVPCは、VPCアタッチメントを介して Transit Gateway を使用して相互接続されます。VPC アタッチメントの詳細については、 こちら をご覧ください。UPF からの N6 データネットワークトラフィックは、ネクストホップとして Transit Gateway 経由でアプリケーションにルーティングされます。FQDN アプリケーションアドレスは、ネットワーク機能 VPC をアプリケーション VPC の Route53 プライベートホストゾーンに関連付けることで解決されます。VPC ピアリングとは異なり、Transit Gateway では推移的なルーティングが可能です。 設計6: AWS Resource Access Manager 経由のサブネット共有による AWS上 のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、ある AWS アカウントで動作する UPF からの N6 データネットワークトラフィックが、別の AWS アカウントで動作しているアプリケーションに送信されるプライベートネットワークのユースケースです。UPF の N6 インターフェイスとアプリケーションインターフェイスの両方が同じサブネット上にあります。サブネット共有は AWS Resource Access Manager (AWS RAM) を使用してリソース共有を作成することで可能になります。VPC 所有者であるネットワーク機能 VPC は、アプリケーションアカウントとサブネットを共有します。 共有されると、アプリケーションアカウントはサブネットにアクセスし、VPC リソースを起動できるようになります。サブネット共有の詳細については、 こちら をご覧ください。 まとめ&nbsp; LTE や 5G のユーザープレーントラフィックをインターネットや非ローミングシナリオのアプリケーションにブレイクアウトする方法については、複数の設計があります。AWS はパブリックネットワークとプライベートネットワークの両方のユースケースで、CSP がアプリケーションに SGi または N6 トラフィックを送信できるようにする様々なサービスを提供しています。アーキテクチャ設計を選択する際には、遅延、アプリケーションのエントリポイントまたはアクセスポイント、そしてユースケースなどの要素を考慮する必要があります。詳細については、 AWS for Telecom をご覧ください。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワールドワイドテレコムビジネスユニットのプリンシパルテレコムソリューションアーキテクトです。彼は 5G 分野を専門としており、通信領域のパートナーや顧客と協力しながら、AWS 上で通信ワークロードの構築やデプロイをしています。

このブログは、AWSの以下のメンバーによって共同執筆されました： Pavol Masarovic, EMEA Principal SAP Innovation Architect Allison Quinn, Senior Analytics Solutions Architect Australia and New Zealand Peter Perbellini, Head of APJ Solutions Architecture, ERP on AWS はじめに AWSでは、お客様からSAPシステムをクラウドに移行するだけでなく、データに対して分析機能を活用し、組織の変革を実現したいという声をよく聞きます。去年リリースされたジョイントレファレンスアーキテクチャ (JRA) に沿って、RISE with SAP on AWS を採用している客様に更なる価値をもたらすために、AWS ネイティブサービスを統合しています。AWS と SAP BTP の ジョイントレファレンスアーキテクチャ は、異なるビジネスソリューションシナリオでどのように SAP BTP や AWS サービスを使用するかについて、お客様やパートナー様からの質問に対応するために開発されました。 SAP のお客様は既に AWS 上のデータレイクを活用し、SAP と SAP 以外のデータを組み合わせ、AWSの業界をリードするストレージとアナリティクス機能を活用しています。その中には、 Bizzy 、 Invista 、 Zalando 、 Burberry 、 Visy 、 Delivery Hero 、 Engie のようなお客様を含め、何年前からこのような取り組みを行っているお客様は複数います。お客様は、SAP と SAP 以外のデータ (例えば、CRM システムからのリード情報、顧客満足度点数、住宅統計、気象データ) を組み合わせたエンタープライズ・ダッシュボード、ML モデル、「what-if」シナリオを構築する方法を探しています。 AWS Analytics Fabric for SAP ソリューションを利用することで、SAP on AWS のお客様は、構築に必要な AWS サービスを考える負担がなくなり、構築作業を最大 90% 削減しながら、データドリブンアプローチにより数時間以内にSAPデータから実用的な洞察を得られます。 AWS Analytics Fabric for SAP を使用することで、ユーザーは製品、顧客、販売注文、納品、請求書などの機能領域を選択することができ、ソリューションのテンプレートには必要なテーブルとそれらの関連性を特定します。 AWS Analytics Fabric for SAP は以下の内容を含めます。 生成される データモデル は、ビジネスコンテキストを持ち、ビジネスフレンドリーな名前を提供 差分データ抽出 (CDC)、データ変換ルール、カスタムフィールドの自動的に含める包括的な機能を備えた、シンプルで適応性の高いニアリアルタイムの データパイプライン を実現 Amazon S3 で高度にスケーラブル可能な AWS データレイクを構築し、 Amazon S3 Intelligent Tiering を使用して費用対効果の高い階層に データを保存 ユーザが SAP データおよび&nbsp; SAP 以外のデータに対して高度な分析やレポート作成をするために、高品質のデータモデルを提供 AWS Analytics Fabric for SAP を使用する主なメリット AWS Analytics Fabrics for SAP は、RISE のお客様の変革を加速し、AWS のデータ分析や AI/ML サービスからさらなる価値を引き出すために構築されました。モダンデータアーキテクチャのフレームワークに基づいているため、SAP on AWS のすべてのお客様がデータを活用し、ビジネスユースケースの要件に応じて拡張することも可能です。これらのアクセラレータは、開発のベースラインとして使用したり、お客様の要件に合わせて簡単に変更・カスタマイズすることができます。 データの取り込みは、標準で提供される SAP Business Content Extractor に基づいています。これらは要件に応じて、 SAP HANA CDS ビューまたはソーステーブルから抽出するように変更できます。データ取り込み処理は、分単位の間隔でスケジュールし、差分データのみ抽出します。この方法では、データソースで行われた変更を含めすべてのデータが取り込まれます。 その後、データは Amazon Redshift にロードされますが、ロードの処理は AWS Step Functions で制御され、参照整合性のために適切な順序を保ちます。Amazon Redshift 側には、様々な SAP ソースを結合したデータモデルのサンプルも提供されており、 Amazon QuickSight でこれらのデータを迅速に利用し、洞察を得ることができます。お客様は、これらの事前定義されたデータモデルを簡単に改修したり、SAP のソースデータを Redshift やデータレイク環境で利用可能な他のデータと簡単にモデリングできます。 このアーキテクチャ図は、OData プロトコルを介して SAP からデータを抽出し、AWS 上で SAP データを使用してクラウドデータウェアハウス構成と構築ステップを表しています。 以下は各ステップの説明です。前提条件に関しては次のセクションで詳しく説明します。 前提条件 – 標準の SAP Business Content Extractors をインストールし、有効化します。SAP システムの SAP Gateway で、ODP ベースの OData を設定します。 前提条件 – Amazon AppFlow から SAP ソースシステムへの OData 接続先を作成します。SAP on AWS 又は VPN /ダイレクトコネクト経由で AWS との接続がある場合はPrivateLinkを使用可能であり、またはインターネット経由での接続も可能です。 前提条件 – データを保存する Amazon S3 バケットを作成します。 Amazon AppFlow で、ステップ 2 で作成した SAP ソースとの接続先を使用してフローを作成します。フローを実行して SAP からデータを抽出し、Amazon S3 バケットに保存します。 Amazon S3 バケットに抽出された SAP データのメタデータを認識するために、データカタログエントリを作成します。 ‘ COPY ‘ コマンドで Amazon Redshift にデータをロードします。データを適切にモデル化し、データの過去の動きを可視化する機能を有効にします Amazon Redshift をデータソースとして Amazon QuickSight でデータセットを作成します。要件に応じてビジネスデータのダッシュボードを作成します。 AWS Step Functions でエンド・ツー・エンドのプロセスを自動化します。 SAP ソースシステムから抽出されたデータにより、お客様は直ちに、受注件数、受注総額、未決済受注件数および未決済受注総額、返品件数、平均受注額（AOV）、納期遵守率（DIFOT）、請求済み受注、受注処理率等のOrder-to-Cashに関連する主要業績評価指標（KPI）を導き出すことができます。これに加えて、データの差分抽出（CDC）を活用することで、お客様は、注文数量変更や納品時間枠変更など、データ更新を含む各注文のジャーニーを時系列で分析することができます。 前提条件 AWS Analytics Fabric for SAPのデプロイには3つの前提条件があります。 Git レポジトリ に記載されているエクストラクタをSAPシステムでインストールします。既に SAP BW システムがある場合は、すでにインストールされているかもしれません。これらのエクストラクタは、トランザクションコード SEGW で ODataサービスのソース ODP として定義する必要があります。 Amazon AppFlow で SAP システムへの 接続先 を作成します。これは接続先の情報と認証情報だけの簡単な入力も可能であり、AWS と SAP システム間の AWS PrivateLink を使う場合 PrivateLinkの情報も必要になります。これは 1 回だけ行う必要があるステップです。 SAP データを格納する Amazon S3 バケット を作成します。 これらの前提条件が完了すれば、残りの構築ステップはスムーズになります。 デプロイメント デプロイは、 AWS CloudFormation テンプレートとスクリプトを使用して自動化されており、必要に応じて迅速に実装、変更、拡張することができます。テンプレートはパラメータ化されており、迅速なデプロイが可能です。AWS Analytics Fabric for SAP の初回リリースは、”Order to Cash ” プロセスにフォーカスしており、他のプロセスも今後リリースされる予定です。 Git リポジトリのガイダンスに従って、定義された順序で各コンポーネントを実装してください。 Git レポジトリ には、テンプレート以外に、ほかの参考情報も記載してあります。 デプロイのステップは以下になります。 SAP システムからデータを抽出するために Amazon AppFlow のフローをデプロイします。これにより、自動的にフローがアクティブになり、指定したタイミングに基づいてデータの取り込み処理が実行されます。 データエントリーの技術メタデータカタログである AWS Glue データカタログ をデプロイします。これにより、Amazon Athena などのサービスでデータを参照して利用できるようになります。 Redshift クラスタを作成するために、Git レポジトリに Redshift 用のスクリプトがあります。最初に DDL（データ定義言語）スクリプトを実行し、データをロードするためのテーブル定義を作成します。その後、ほかのスクリプトを実行し、データパイプラインコンポーネントとCDC（Change Data Capture）パイプライン管理を作成します。すべてのテンプレートスクリプトは定義済みですが、SAP ソースシステムでカスタマイズがある場合など、カスタマイズや変更、拡張が可能です。 プロセス全体のオーケストレーションとデータパイプラインアラートのために Step Functions をデプロイします。 Amazon QuickSight アカウント を作成し（まだアクティブなアカウントがない場合）、 Amazon Redshift クラスタ に接続し、Amazon Redshift で使用可能なモデリングされたデータに基づいてデータソースを定義します。 上記は、提供された CloudFormation テンプレートのデータセットを使って Amazon QuickSight での可視化の例です。SAP 注文の異常検知や予測を追加するために、機械学習を活用した洞察機能で Order-to-cash の様々な KPI を可視化することができます。 まとめ AWS Analytics Fabric for SAP は、ビジネスユーザーが SAP データから迅速に実用的な洞察を得られるために、簡単で効率的な方法を提供しています。AWS 上で SAP 環境を稼働しているお客様は、AWS マネジメントコンソールでこのサービスを使い始めることができます。また、オンプレミスで SAP システムを稼動しているお客様は、SAP データを Amazon S3 に格納することで、AWS 上で強力なデータレイクを作成し、SAP への投資効果拡大や企業データから新たな価値を得ることができます。 アクセラレータを利用するための初期費用は不要で、利用する AWS サービスに対する課金となります。例としては、Amazon AppFlow のフロー実行コストは、実行ごとにわずか $0.001 です。販売伝票ヘッダーの取込みを 5 分ごとに 24 時間実行する場合、1 日あたり 288 回の実行があり、1ヶ月あたりのコストは $8.76 となります ( 1 日288 回 * ( 月の平均 730 時間 / 1 日 24 時間) =　月に 8760 フロー実行 * $0.001 = $8.76 ) 。また、処理したデータ量に応じて、1GB までは 1GB あたり $0.02、1GB 以上は 1GB あたり $0.10 の課金になります。差分抽出を実行することで、データ処理コストを最小限に抑えられます。Glue データカタログは、最初の 100 万オブジェクトの保存料と、最初の月間 100 万リクエストは無料です。Redshift サーバーレスの価格は、RPU 時間（Redshift 処理ユニット）あたり $0.36 からです。AWS価格の詳細については、 AWS Pricing Calculator をご覧ください。(**この例の参考価格はすべて us-east-1 リージョンに基づいていることをご注意ください。) 始めるには、まず AWS Analytics Fabric for SAP のリポジトリ をご覧ください。AWS が何千のアクティブな SAP お客様にイノベーションプラットフォームとして選択された理由は、 AWS for SAP のページをご覧ください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。