AWS Trusted Advisor は、コスト最適化、パフォーマンス、耐障害性、セキュリティ、サービスの制限、運用上の優秀性のカテゴリーのベストプラクティスチェックを使用して継続的に AWS 環境を評価し、AWS Well-Architected Framework の AWS ベストプラクティスからの逸脱を修正するアクションを推奨します。AWS Well-Architected Framework は、お客様がクラウドワークロードを効果的に設計、構築するためのアーキテクチャのベストプラクティスとガイダンスを集めたものです。 2023 年 10 月 26 日、Trusted Advisor は新しく運用上の優秀性のチェックカテゴリーを追加し、 AWS Config と統合したことで、すべてのカテゴリーで合わせて 64 の新しいベストプラクティスチェックを提供しました。このローンチにより、AWS 環境の運用準備状況が改善され、Trusted Advisor チェックの適用範囲が広がり、AWS Well-Architected Framework のベストプラクティスとの整合性を高めることができます。 本ブログ投稿では、新しい 運用上の優秀性 カテゴリーについて詳しく説明し、Trusted Advisor が運用リスクと最適化の機会の特定にどのように役立つかをサンプルシナリオを通して説明します。 AWS Well-Architected ベストプラクティスと整合した AWS Trusted Advisor ビジネスと AWS 環境が進化するにつれ、競合環境で優位に立つために必要な拡張性や継続的な変化への対応力には、適切な運用能力を確保することが重要です。このため、AWS Well-Architected Framework では、 運用上の優秀性の柱 に文書化されている運用関連のベストプラクティスに特に重点を置いています。 運用上の優秀性 の柱の重点分野の 1 つには、ワークロード環境を運用するにあたって十分な 準備 が整っているかどうかの確認に必要なベストプラクティスが含まれています。例えば、「 OPS05-BP05 パッチ管理を実行する 」では、エラーと運用のオーバーヘッドを削減するために、パッチ管理を大規模に実行できる適切な機能群を備えたクラウド環境を準備するようアドバイスしています。EC2 インスタンスの場合は、AWS Systems Manager Patch Manager や Change Manager などの自動化されたサービス機能と統合するのがベストプラクティスです。 Systems Manager の自動化機能を使用するための前提条件として、EC2 インスタンスに AWS Systems Manager エージェント パッケージがインストールされ、AWS Systems Manager サービスに正しく登録されていることを確認する必要があります。 ブログの次のセクションでは、EC2 インスタンスが Systems Manager によって管理されているかどうかを検出するために、 AWS Config データソースの Trusted Advisor チェックを使用する 方法を紹介します。 AWS Trusted Advisor による運用上の優秀性 この例では、最近導入された運用上の優秀性 チェック が、AWS Config ルールを使用して AWS 環境を調査するのにどのように役立ち、その後、ワークロードの運用効率を向上させる機会が生じた際にレコメンデーションをどのように提供するかを学びます。 以下は、Trusted Advisor と AWS Config の統合を通して、 AWS Systems Manager によって管理されていない Amazon EC2 インスタンスを特定する詳細な手順です。 AWS Config ルール名を抽出するには (コンソール) Trusted Advisor の 運用上の優秀性 タブで、[ Amazon EC2 インスタンスは AWS Systems Manager によって管理されていません ] のチェックを展開します。 ソース セクションで、AWS Config マネージドルール名 [ ec2-instance-managed-by-systems-manager ] をコピーします。 図 1 – AWS Trusted Advisor での運用上の優秀性チェックの例 対応する AWS Config マネージドルールを有効化する (コンソール) AWS コンソールで AWS Config に移動します。 AWS Config をまだ有効にしていない場合は、 開始方法のドキュメント を参照して AWS Config を有効にしてください。 AWS Config の使用量に基づいて料金が請求されることに注意してください。 詳細については、 AWS Config の料金 を参照してください。 ルール ページで、 ルールを追加 を選択します。 図 2 – AWS Config のルール追加例 AWS によって管理されるルールの追加 を選択します。 検索バーで AWS マネージドルール名 [ ec2-instance-managed-by-systems-manager ] を検索すると、関連する説明とともに対象のルールが表示されます。 [ ec2-instance-managed-by-systems-manager ] ルール名の左側のラジオボタンをクリックします。 次へ を選択します。 図 3 – [ec2-instance-managed-by-systems-manager] という名前の AWS Config マネージドルールの追加例 ルールの設定 ページで、デフォルト設定のまま 次へ を選択します。 図 4 – ルールの設定ページの AWS Config マネージドルールの詳細の例 確認と作成 ページで、AWS Config マネージドルールが必要なものであることを確認します。確認してルールを保存すると、ルールの概要ページに表示されます。 図 5 – [ec2-instance-maned-by-systems-manager] ルールが AWS Config に正常に追加される これで、この特定のチェックに対して Trusted Advisor の運用上の優秀性のレコメンデーションを生成するための前提条件が満たされました。 AWS Config ルールが評価結果を生成すると、ほぼリアルタイムで Trusted Advisor に結果が表示されます。 Systems Manager によって管理されていない EC2 インスタンスを特定する (コンソール) Trusted Advisor の 運用上の優秀性 タブで [ 調査が推奨されます ] の項目を確認します。 図 6 – Trusted Advisor の運用上の優秀性で調査が推奨される項目の例 [ Amazon EC2 インスタンスは AWS Systems Manager によって管理されていません ] のチェックを展開して、結果を確認します。 この例では、Systems Manager によって管理されていない 4 つの EC2 インスタンスが強調表示されています。 これらの EC2 インスタンスのリソース、AWS Config ルール、および入力パラメータを確認します。 図 7 – Trusted Advisor で検出されたソース、アラート基準、推奨されるアクション、その他のリソースの詳細の例 運用上の優秀性の [ AWS Systems Manager によって管理されていない Amazon EC2 インスタンス ] チェックでは、集中管理、自動化、インベントリ、パッチ管理、変更管理、OS 設定の一貫性を提供することで、Amazon EC2 インスタンスを効率的に管理する方法を説明しています。 Trusted Advisor は組織が運用のオーバーヘッドを削減して Amazon EC2 インスタンスのフリートを管理するために、運用のベストプラクティスの実装をガイドする 推奨されるアクション も提供します。 この例では、Trusted Advisor が Systems Manager の EC2 インスタンス のセットアップ 手順をガイドし、 EC2 インスタンスが Systems Manager に表示されない 場合のトラブルシューティングを行います。 このチェックは、AWS Well-Architected Framework のベストプラクティス「 OPS05-BP03 構成管理システムを使用する 」と「 OPS05-BP05 パッチ管理を実行する 」に沿ったもので、これにより、運用チームは反復可能で監査可能な構成変更を行い、労力を低減することができます。AWS Systems Manager によって EC2 インスタンスが管理されると、運用チームは Systems Manager Patch Manager と Change Manager を使用した自動パッチ管理の活用や一貫した変更管理プロセスの確立によって、運用効率を向上させることができます。 上記のシナリオと同様に、チェックに対応する AWS Config マネージドルールをデプロイすることで、他の Trusted Advisor の運用上の優秀性のチェックを有効化することもできます。 AWS Config マネージドルールが有効化されると、Trusted Advisor は AWS リソースを継続的に評価し、運用のベストプラクティスから逸脱するリソース設定がある場合にフラグを立てます。 各チェックの 推奨されるアクション に基づいて、AWS 環境の運用上の優秀性の達成に役立つ修正アクションを実行できます。 結論 運用上の優秀性は、規模を拡大し、継続的なビジネス変化のスピードに対応するために不可欠です。 このブログ投稿では、Trusted Advisor の新しい運用上の優秀性カテゴリを紹介しました。 また、AWS Config データソースからの新しいチェックも共有しました。これらのチェックは、AWS Well-Architected の運用上の優秀性のベストプラクティスに沿っており、お客様環境の運用態勢を改善できるように設計されています。 Trusted Advisor の新しい運用上の優秀性のチェックの詳細については、 Trusted Advisor チェックリファレンス をご覧ください。 著者について: Jang Whan Han Jang Whan は AWS Well-Architected GEO ソリューションアーキテクトであり、AWS クラウドにワークロードをデプロイするための AWS ベストプラクティスを実証するサンプルシナリオとハンズオンラボを構築しています。彼は特に AWS パートナーネットワーク (APN) パートナーや AWS のお客様を対象に AWS ベストプラクティスを推進することに専念してきました。 Jerry Chen Jerry Chen は現在、Amazon Web Service (AWS) のシニア AWS Well-Architected GEO ソリューションアーキテクトです。彼は AWS のお客様とパートナー向けのクラウドセキュリティと運用アーキテクチャの設計に注力してきました。 LinkedIn で Jerry をフォローできます。 翻訳はテクニカルアカウントマネージャーの河野が担当しました。原文は こちら です。

このブログは 2024 年 3 月 13 日に Brad Beaulieu（Booz Allen 社）、Christopher Smith（Principal Solutions Architect）、Dru Grote（Booz Allen Hamilton 社）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 2015 年の AWS Snowball デバイスの発表以来、ユーザーは Amazon Web Services（AWS）Snow Family を用いて、オンプレミスと AWS リージョン 間でペタバイトのデータを転送することに成功しています。ユーザーは、AWS Snow Family を用いてデータを移行するだけではありません。AWS Snowball Edge Compute Optimized デバイスを使用して、ネットワーク接続が拒否される、中断する、断続的になる、制限される環境（DDIL = Denied, Disrupted, Intermittent or Limited）でデータの処理が必要なアプリケーションをホストすることが増えています。エッジでのデータ処理により、より迅速にインサイトを得ることができますが、長期保存のためにユーザーはエッジで取得したデータをアーカイブしてエンタープライズデータレイクに保存することがよくあります。データを AWS に送る最も簡単な方法は、インポート ジョブ プロセスの一部として AWS Snowball デバイスを返却することです。しかし、インポートジョブはオンプレミスから AWS への 1 回限りのデータ移動ソリューションであり、返送、集荷、データ取り込みに関する時間の遅れが発生します。 インポートジョブは、事業継続計画やレガシーデータの移行に関連する大規模なオフラインデータのクラウドへのバックアップには最適です。しかし、一回のインポートジョブでは、継続的にデータを選別し転送することが必要な 機械学習（ML）モデルの再トレーニング や 企業データに対するビジネスインテリジェンスレポーティング などのユースケースが求めるニアリアルタイムのデータ転送パイプラインの要件を満たすことはできません。 2023 年の AWS Snowball Edge Compute Optimized デバイス上の Amazon Simle Storage Service (S3) 互換ストレージ と、 AWS Snowball デバイス上の Amazon S3 互換ストレージ向け AWS DataSync の提供開始により、データのライフサイクル要件を満たしながら、 エッジ を含めたあらゆる場所でデータを処理し保存することができます。 この記事では、 AWS DataSync エージェントを Amazon Elastic Compute Cloud（Amazon EC2）互換のコンピュートインスタンス として AWS Snowball Edge デバイスにロードする手順を説明します。また、AWS Snowball Edge の Amazon S3 互換ストレージバケットと AWS リージョンの Amazon S3 バケット間でオブジェクトを比較して転送するように AWS DataSync を設定します。この方法では、ネットワークが断続的な場合に組み込みのリトライとネットワーク回復メカニズムが機能します。さらに、AWS DataSync タスクはネットワーク接続が制限される場面でも最大帯域幅を指定することができます。どちらの機能も遠隔の通信環境や過酷な通信環境では必要とされるものです。 ソリューションの概要 このシナリオでは、カメラを用いて高解像度の非圧縮ビデオを AWS Snowball Edge デバイス上の Amazon S3 バケットに保存します。AWS Snowball Edge 上の Amazon EC2 互換のコンピュートインスタンス上で人工知能（AI）アプリケーションがビデオを処理して興味のある物体を特定します。分析後、生の映像はダウンサンプリングされ、人が確認できるようにアーカイブされる必要があります。 このソリューションには、以下の AWS サービスと機能が含まれています: AWS Snowball Edge Compute Optimized デバイスは、ローカルコンピューティングとストレージのみのジョブから作成します。 データ用と Amazon Machine Images (AMI) 用の 2 つのバケットを用意した AWS Snowball Edge デバイス上の Amazon S3 互換ストレージ AWS リージョンの Amazon S3 バケットへオブジェクトをレプリケートするように設定された Amazon EC2 上で稼動する AWS DataSync エージェント AWS リージョンの Amazon S3 バケット AWS DataSync 図 1. AWS Snowball Edge、Amazon S3、AWS DataSync のアーキテクチャ 前提条件 この記事に従うには、以下の前提条件が必要です: 少なくとも 1 つの AWS リージョン（この例では、us-east-1 リージョンを使用）の管理者権限を持つ AWS アカウントが必要です。 スタンドアロンの AWS アカウントを作成 します。 Amazon S3 互換のストレージがある AWS Snowball Edge、ロック解除コードとマニフェストファイルへのアクセス、インターネットへの接続環境が必要です。詳細については、「 AWS Snowball Edge の開始方法 」を参照してください。 電源とネットワークケーブル、および AWS Snowball Edge デバイスとワークステーションとインターネットを相互接続するためのネットワークデバイスなどの、AWS Snowball Edge およびワークステーションに関する追加の機材が必要です。 90 ギガバイト（GB）の空きストレージと AWS Snowball Edge へのネットワーク接続、および以下のソフトウェアがインストールされた Windows または Mac のワークステーションが必要です: AWS Command Line Interface (AWS CLI ) &gt;= 2.11.15 AWS Snowball Edge Client (SBE CLI) &gt;= 1.2.0 AWS OpsHub for Snow Family &gt;= 1.15.11 Terraform &gt;= 1.5.0 ウォークスルー AWS Snowball Edge デバイス上の Amazon S3 互換ストレージから AWS リージョンの Amazon S3 バケットにオブジェクトをレプリケートするには、以下の手順を実行します: AWS Snowball Edge デバイスで Amazon S3 互換ストレージサービスを開始 AWS Snowball Edge 上の Amazon S3 Control（バケット）と Amazon S3 API（オブジェクト）のエンドポイントと通信するように AWS CLI を設定 AWS Snowball Edge 上に、2 つの Amazon S3 互換ストレージのバケットを作成 AWS Snowball Edge デバイス上で VM Import/Export (VMIE) サービスを有効にするために、 AWS Identity and Access Management (IAM) ロールとポリシーを作成 Amazon EC2 インスタンスから AWS DataSync AMI を作成し、オンプレミス環境にエクスポート AWS Snowball Edge デバイス上に Amazon EC2 互換のコンピュートインスタンスとして AWS DataSync エージェントをインポートして起動 Infrastructure-as-Code (IaC) をデプロイしてエージェントをアクティベートし、AWS DataSync タスクとロケーションを作成して、ユーザー定義のスケジュールで AWS Snowball Edge デバイスから AWS リージョンの Amazon S3 バケットにレプリケート AWS DataSync レプリケーションタスクを検証し実行 Step 1: AWS Snowball Edge デバイスで Amazon S3 互換ストレージサービスを開始 AWS Snowball Edge デバイスの注文、受け取り、インストール、ネットワーク接続の確立が完了した後、このステップではデバイスへの接続、設定、Amazon S3 互換サービスの起動を行います。デバイス上では S3-snow サービスと表現され、以下では S3-snow として参照します。 SBE CLI を使用して S3-snow サービスのロックを解除し、起動してください。または、AWS OpsHub for Snow Family を使用して、GUI でのワークフローを使用することもできます。 AWS Snow Family Management Console からマニフェストファイルをダウンロードし、ロック解除コードをメモします。AWS Snowball Edge デバイスがお客様の施設にある間、不正アクセスを防ぐために、ロック解除コードとマニフェストファイルを別々の場所に保管することをお勧めします。 ワークステーションで SBE CLI を使用して、AWS Snowball Edge の認証情報を持つプロファイルとして “snowsbe” を設定します: snowballEdge configure --profile snowsbe マニフェストファイルへのパス、ロック解除コード、および AWS Snowball Edge のエンドポイントを https://&lt;IP ADDRESS&gt; という形式で入力するよう求められます。 次のコマンドを使用して、AWS Snowball Edge デバイスのロックを解除します: snowballEdge unlock-device --profile snowsbe 次のコマンドを実行して、デバイスのロックを解除したことを確認します: snowballEdge describe-device --profile snowsbe デバイスのロックが解除されたら、AWS Snowball Edge 上で Amazon S3 互換ストレージを設定する必要があります。このサービスには 2 つの Virtual Network Interfaces (VNI) が必要です。1 つは Amazon S3 API（オブジェクト）エンドポイント用で、もう 1 つは Amazon S3 Control（バケット）エンドポイント用です。エッジデバイスと AWS リージョン間でバケットを同期するタスクを実行するために、AWS DataSync エージェントが通信する Amazon S3 エンドポイントのホスト名またはインターネットプロトコル（IP）アドレスを指す Terraform 変数値を後で設定します。2 つの異なるエンドポイントを区別する最も簡単な方法は、バケットとオブジェクトのどちらに対してアクションを実行しているかを確認することです。Amazon S3 Control エンドポイントはバケット操作用で、Amazon S3 API エンドポイントはオブジェクト操作用です。 次のコマンドを実行して、デバイスの物理ネットワークインターフェース ID を取得します: snowballEdge describe-device --profile snowsbe AWS Snowball Edge デバイスと同じサブネット上で利用可能な IP アドレスを 2 つ特定します。次のコマンドを実行して VNI を作成し、“VirtualNetworkingInterfaceArn” の値を取得します。これを 2 回 — Amazon S3 エンドポイントごとに 1 回ずつ（各 IP アドレスは別々に入力する必要があります）実行する必要があります: snowballEdge create-virtual-network-interface --ip-address-assignment static --physical-network-interface-id "&lt;PHYSICAL_INT_ID&gt;" --static-ip-address-configuration IpAddress=&lt;IP_ADDRESS&gt;,NetMask=&lt;NETMASK&gt; --profile snowsbe S3-snow サービスを開始し、先程作成した IP アドレスの VNI Amazon Resource Names (ARN) を指定します（指定する順番によって、 Control か オブジェクト エンドポイントかが決まります）: snowballEdge start-service --service-id s3-snow --device-ip-addresses &lt;SNOWBALL_IP&gt; --virtual-network-interface-arns &lt;S3_CONTROL_VNI_ARN&gt; &lt;S3_OBJECT_VNI_ARN&gt; --profile snowsbe オプション: 次のコマンドを実行して、サービスがアクティブであることを確認します: snowballEdge describe-service --service-id s3-snow --profile snowsbe Step 2: AWS Snowball Edge 上の Amazon S3 Control（バケット）と Amazon S3 API（オブジェクト）のエンドポイントと通信するように AWS CLI を設定 AWS Snowball Edge 上で Amazon S3 互換のストレージサービスが有効になったので、 Amazon S3 Control と Amazon S3 API コマンドを使用 するために AWS CLI の認証情報を設定する必要があります。 1. 次のコマンドを実行して、SBE CLI からアクセスキーを取得します: snowballEdge list-access-keys --profile snowsbe 2. アクセスキーを使って、対応するシークレットアクセスキーを取得します: snowballEdge get-secret-access-key --access-key-id &lt;ACCESS_KEY_ID&gt; --profile snowsbe 3. AWS Snowball Edge の証明書とそれぞれの ARN をリストします: snowballEdge list-certificates --profile snowsbe 4. 前述の証明書の ARN 値を使用して、AWS Snowball Edge の証明書をダウンロードしてローカルに保存します。出力された証明書を拡張子「.pem」のファイルに保存します: snowballEdge get-certificate --certificate-arn &lt;CERT_ARN&gt; --profile snowsbe &gt; ~/.aws/snowsbe_cert.pem 5. .pem ファイルの権限を読み取り専用に設定し、システム上の他のユーザーがアクセスできないようにします: a. Linux の場合: chmod 400 ~/.aws/snowsbe_cert.pem b. Windows の場合: ファイルを右クリック &gt; プロパティ &gt; 読み取り専用に切り替える 6. ~/.aws/config ファイルを編集し、この AWS Snowball Edge デバイス用のプロファイルを作成します: Step 3: AWS Snowball Edge 上に、2 つの Amazon S3 互換ストレージのバケットを作成 AWS Snowball Edge デバイスの AWS CLI プロファイルを設定した後、AWS CLI から Amazon S3 Control API にアクセスして Amazon S3 バケットを作成できます。 ダウンサンプリングした動画を保存するバケットを AWS Snowball Edge 上に作成します: aws s3control create-bucket --bucket &lt;downsampled-bucket-video&gt; --profile snowsbe --endpoint-url https://&lt;S3_CONTROL_IP&gt; 次に、AWS DataSync エージェントを AMI として保存するバケットを作成します: aws s3control create-bucket --bucket &lt;ami-bucket&gt; --profile snowsbe --endpoint-url https://&lt;S3_CONTROL_IP&gt; Step 4: AWS Snowball Edge デバイス上で VM Import/Export (VMIE) サービスを有効にするために、AWS Identity and Access Management (IAM) ロールとポリシーを作成 AWS DataSync エージェントを AWS Snowball Edge 上の Amazon EC2 互換のコンピュートインスタンスとしてインポートするには、VMIE サービスを使用します。AWS Snowball Edge へと VMIE サービスを適用するには、インポート処理に必要な権限を与えられた AWS IAM ロールと AWS IAM ポリシーが必要です。 この例では、AWS CLI を使用して AWS IAM ポリシーと AWS IAM ロールを作成し、AWS IAM ポリシーを AWS IAM ロールにアタッチして、AWS Snowball Edge 上の VMIE サービスが AWS IAM ロールを引き受けるための AWS IAM 信頼ポリシーを作成します。AWS OpsHub の GUI を使用した AWS IAM ポリシーの設定に関するウォークスルーは、 この Amazon Storage Blog の Step 3 を参照してください。 AWS IAM 信頼ポリシーファイル をローカルにダウンロードし、”trust-policy.json” と名付けます: 参照した trust-policy.json を使用して AWS IAM ロールを作成します: aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:6089 AWS IAM ポリシーファイル をローカルにダウンロードし、”iam-policy.json” と名前を付けます。AWS アカウント ID、AWS Snowball Edge のジョブ ID、Step 3.2 で作成した &lt;ami-bucket&gt; を反映するようにファイルを編集します。 iam-policy.json ファイルを使用して、AWS Snowball Edge で AWS IAM ポリシーを作成します: aws iam create-policy --policy-name vmimport-resource-policy --policy-document file://iam-policy.json --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:6089 前のステップの AWS IAM ポリシーの ARN を使用して、AWS IAM ポリシーの vmimport-resource-policy を AWS IAM ロールである vmimport にアタッチします: aws iam attach-role-policy --role-name vmimport --policy-arn arn:aws:iam::&lt;ACCOUNT-ID&gt;:policy/vmimport-resource-policy --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:6089 Step 5: Amazon EC2 インスタンスから AWS DataSync AMI を作成し、オンプレミス環境にエクスポート AWS DataSync を設定する最初のステップは、 AWS DataSync エージェントをデプロイ することです。AWS DataSync エージェントをデプロイする場所を選択する場合は、できるだけ AWS Snowball Edge に近い場所にデプロイしレイテンシを削減し、AWS DataSync のインライン圧縮を使用し転送時間とネットワーク転送コストを削減します。この例では、AWS DataSync エージェントを AWS SnowBall Edge 上に直接デプロイし、Amazon S3 互換ストレージサービスへのレイテンシを低減すると同時に、ローカルコンピューティング機能を使用します。 Amazon EC2 インスタンスに最新の AWS DataSync エージェントをデプロイして、AWS リージョンにプライベートの AWS DataSync エージェント AMI を作成します。この方法では、以下の手順で AWS Snowball Edge 上で AWS DataSync エージェントを実行する際に、SSH 経由でローカルコンソールにアクセスすることができます: 1. AWS Snowball Edge 上の VMIE サービスに関する Step 4 のガイダンスと同様に、AWS リージョンタイプの VMIE サービスに必要な前準備を完了して、AWS DataSync エージェントのイメージを Amazon S3 にエクスポートする準備をします: a. AWS DataSync サービスと同じ AWS リージョンに、イメージを保存するための Amazon S3 バケットを作成 します。 b. 適切な権限を持つ VMIE サービス用の AWS IAM ロールを作成 します。 2. 以下のガイダンスに従って、 AWS DataSync エージェントを Amazon EC2 インスタンスとしてデプロイ します: a. AWS DataSync AMI には、AWS DataSync サービスおよび Amazon S3 バケットと同じ AWS リージョンを使用します。 b. 以下の設定でインスタンスを起動します: i. c4.xl インスタンスを使用します。これは前世代の xen ハイパーバイザーで実行され、AWS Snowball Edge にインポートする前に、必要なネットワークとストレージのドライバーがインストールされていることを確認します。 ii. 後でローカルにおいて AWS Snowball Edge デバイス上でキーペアを作成 できるため、ログイン用のキーペアを作成せずに進めます。 iii.リージョンのデフォルト Amazon VPC サブネットを選択します。 iv. パブリック接続は不要なので、パブリック IP の自動割り当てを無効にします。 v. 既存のデフォルトセキュリティグループを選択して、インバウンド接続を制限します。 vi. ブロックデバイスマッピングで、暗号化された Amazon Elastic Block Store（Amazon EBS）スナップショットを含むイメージをエクスポートできない ため、 Amazon EBS ボリュームは暗号化しません。AWS リージョンが デフォルトで Amazon EBS ボリュームを暗号化 しないことを確認します。 3. インスタンスを数分間実行後、 インスタンスを停止 して AMI を作成する準備をします。 4. 停止した AWS DataSync 用の Amazon EC2 インスタンスから AMI を作成 します。 5. VMIE サービスを使用して AMI をエクスポート します。 a. Step 5.4 の ami-id を使用します。 b. RAW の disk-image-format を使用します。 c. Step 5.1 の Amazon S3 バケット名 “S3Bucket= &lt;name&gt; ” を使用します。 d. デフォルトの Amazon S3 プレフィックス値 “S3Prefix=export/” を使用します。 6. AWS DataSync エージェント用の Amazon EC2 インスタンスを終了 します。 7. Step 5.5 で作成した Amazon S3 バケットから、.raw イメージファイルをローカルマシンにダウンロードします。 AWS Management Console を使用することもできますが、AWS CLI は大きなデータの転送に最適化されています。ファイルサイズが ~80 GB あるので、高速なインターネット接続の使用を推奨します: aws s3 cp s3://&lt;export bucket name&gt;/export/&lt;image-name&gt;.raw &lt;path for local object storage&gt;/datasync-agent.raw Step 6: AWS Snowball Edge デバイス上に Amazon EC2 互換のコンピュートインスタンスとして AWS DataSync エージェントをインポートして起動 AWS DataSync エージェントイメージを AWS Snowball Edge に サイドロード する準備ができました。エージェント登録キーの取得やトラブルシューティング時のサポートのために AWS DataSync エージェントのローカルコンソールにアクセスする 必要がある場合は、必ず ローカルの AWS SnowBall Edge キーペアを作成 し、そのキーを関連付けた Amazon EC2 互換のコンピュートインスタンスを起動してください。 この例では、以下の手順で Terraform を使用して AWS DataSync エージェントをアクティベートしたため、関連する SSH キーペアなしで AWS DataSync エージェントを AWS Snowball Edge デバイスにデプロイしました: 1. AWS DataSync エージェントのイメージをアップロードして、AWS SnowBall Edge 上で Amazon EC2 互換のコンピュートインスタンスとして実行します: a. datasync-agent.raw イメージファイルを S3-snow における ami-bucket（Step 3.2 で作成）へとアップロードします。.raw ファイルは約 85 GB なので、デバイスにローカル接続されていない場合は、高帯域幅のネットワークを介してアップロードすることをお勧めします。 aws s3 cp datasync-agent.raw s3://&lt;ami-bucket&gt;/datasync-agent --profile snowsbe --endpoint-url https://&lt;S3_OBJECT_IP&gt; b. アップロードされた datasync-agent.raw イメージをスナップショット &lt;SNAPSHOT_ID&gt; としてインポートします: aws ec2 import-snapshot --disk-container "Format=RAW,UserBucket={S3Bucket=&lt;ami-bucket&gt;,S3Key=datasync-agent}" --description "DataSync Image" --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 c. .raw ファイルからスナップショットへのインポートが完了したことを判断するには、ステータスが “ Pending ” から “ Completed ” に変わったことを確認します: aws ec2 describe-import-snapshot-tasks --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 d. スナップショットを AMI として登録します。前のステップで SnapshotID をキャプチャし、 Mac または Windows ターミナル を使用して以下を更新してください: aws ec2 register-image --name DataSync --description "DataSync agent" --block-device-mappings "[{\"DeviceName\": \"/dev/sda1\",\"Ebs\":{\"Encrypted\":false,\"DeleteOnTermination\":false,\"SnapshotId\":\"&lt;SNAPSHOTID&gt;\",\"VolumeSize\":80}}]" --root-device-name /dev/sda1 --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 2. AWS DataSync エージェントのセキュリティグループを作成します。 デフォルトの AWS Snowball Edge セキュリティグループ は、インバウンドとアウトバウンドのすべてのトラフィックを許可します。AWS Snow Family でのセキュリティグループの詳細については、「 AWS Snowball Edge デバイスでのセキュリティグループの使用と管理 」を参照してください。ユースケースの要件に合わせて AWS DataSync ネットワーク要件 を確認します。以下の手順に従って、AWS DataSync エージェントのテストとアクティベーションのために、インバウンドのネットワーク接続を制限しました: a. ‘datasync-agent’ という新しいセキュリティグループを作成します: aws ec2 create-security-group --group-name datasync-agent --description "Security group for the DataSync agent operating as EC2-compatible compute instance" --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 b. 前のコマンドの group-ID 値と LAN のサブネットを使用して、接続テスト用に ICMP を許可するインバウンドルールエントリーを作成します: aws ec2 authorize-security-group-ingress --group-id &lt;s.sg-id&gt; --ip-permissions '[{"IpProtocol": "icmp", "FromPort": -1, "ToPort": -1, "IpRanges": [{"CidrIp": "&lt;Local Area Network Subnet/CIDR &gt;", "Description": "ICMP inbound from local area network"}]}]' --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 c. Terraform ワークステーション（例えばローカルワークステーション）から Amazon EC2 DataSync エージェントをアクティベートするために、HTTP (TCP/80) を許可するインバウンドルールエントリーを作成します。このルールは、Amazon EC2 互換のコンピュートインスタンスのローカルコンソールから SSH 経由で AWS DataSync エージェントのアクティベーションキーを取得しない場合に必要です: aws ec2 authorize-security-group-ingress --group-id &lt;s.sg-id&gt; --protocol tcp --port 80 --cidr &lt;Terraform Host IP/32&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 オプション: ワークステーションの IP から AWS DataSync エージェントへのローカルコンソールアクセス用に SSH 接続を許可するインバウンドルールエントリーを作成します。 aws ec2 authorize-security-group-ingress --group-id &lt;s.sg-id&gt; --protocol tcp --port 22 --cidr &lt;local workstation IP/32&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 d. セキュリティグループルールの構成を検証します: aws ec2 describe-security-groups --group-id &lt;s.sg-id&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 3. AWS DataSync エージェントを AWS Snowball Edge 上の Amazon EC2 互換コンピュートインスタンスとして起動します: a. AWS DataSync エージェント AMI を起動します: aws ec2 run-instances --image-id &lt;IMAGE_ID&gt; --instance-type sbe-c.2xlarge --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 b. 状態の “Name” が Running に変わるまで状態を確認します: aws ec2 describe-instances --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 c. インスタンスが Running 状態になったら、SBE CLI を使用して AWS DataSync エージェント用の Amazon EC2 互換のコンピュートインスタンスに IP アドレスを割り当てます。物理インターフェース ID は、前の Step 1.5 で確認できます。インスタンスの LAN サブネットで使用可能な IP を選択します: snowballEdge create-virtual-network-interface --physical-network-interface-id &lt;PHYSICAL_INT_ID&gt; --ip-address-assignment STATIC --static-ip-address-configuration IpAddress=&lt;IP_ADDRESS&gt;,Netmask=&lt;NETMASK&gt; --profile snowsbe d. VNI をインスタンスに関連付けます: aws ec2 associate-address --public-ip &lt;IP_ADDRESS&gt; --instance-id &lt;DATASYNC_INSTANCE_ID&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 e. 新しいセキュリティグループ datasync-agent をインスタンスに割り当て、デフォルトのセキュリティグループを置き換えます: aws ec2 modify-instance-attribute --instance-id &lt;datasync instance ID&gt; --groups &lt;s.sg-id&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 f. 以下の 2 つのステップのいずれかで、AWS DataSync エージェントをアクティベートします: i. Terraform ワークステーションから AWS DataSync エージェントにアクセスできる場合は、Terraform の datasync_agent_ip_address 変数に AWS DataSync エージェントの IP アドレスを入力します。以下の Terraform を適用すると、エージェントは自動的にアクティベートします。 ii. Terraform から AWS DataSync エージェントにアクセスできない場合（AWS Management Console にアクセスするワークステーションが http://&lt;AGENT_ADDRESS&gt; の AWS DataSync エージェントにアクセスできることを確認してください）、AWS Management Console からアクティベーションキーを取得します: 1. AWS Management Console で AWS DataSync サービス を開き、 エージェント を選択します。リージョンが AWS Snowball Edge と同じであることを確認します。 2. エージェントの作成 を選択します。 3. Activation key セクションで、 エージェントのアドレス 欄に AWS DataSync エージェントの IP アドレスを入力し、 キーを取得する を選択します。 4. アクティベーションキー をコピーし、Terraform の datasync_agent_activation_key 変数に入力します: Step 7: Infrastructure-as-Code (IaC) をデプロイしてエージェントをアクティベートし、AWS DataSync タスクとロケーションを作成して、ユーザー定義のスケジュールで AWS Snowball Edge デバイスから AWS リージョンの Amazon S3 バケットにレプリケート AWS DataSync エージェントがデプロイされたので、Terraform を使ってこれらのタスクを実行します: エージェントをアクティベートします。 Amazon S3 バケットと Amazon CloudWatch ロググループを暗号化するために、2 つの AWS Key Management Service (AWS KMS) キーを作成します。 暗号化された Amazon S3 バケットを作成し、AWS DataSync タスクからダウンサンプリングされた動画を受け取ります。 AWS DataSync タスクの実行ログを保存するために、暗号化された Amazon CloudWatch ロググループを作成します。 エージェントが実行する AWS DataSync タスクを作成します。AWS Management Console の代わりに、 このチュートリアルガイド を使用することができます。 AWS DataSync タスクのソースバケットと宛先バケットを設定します。 AWS DataSync タスクを毎晩実行するようにスケジュールします。 設定した AWS DataSync タスク構成では、ソースバケットと宛先バケット間で変更されたデータまたは異なるデータのみを転送することで、時間とコストを節約しています。S3-snow バケット内のダウンサンプリングされた動画ファイルは、外部アプリケーションによって定期的に自動的に削除されるため、宛先バケットからも削除されないように、削除されたファイルを保持する設定（デフォルト）を適用しています。 また、 Amazon S3 バケットライフサイクルルール を用いて、一定期間が経過したファイルを自動的に削除することもできます。 Amazon CloudWatch Logs 上の AWS DataSync 実行ログは、コスト最適化のため 30 日間しか保持しないことに注意してください。ログ保持のニーズに合わせて更新してください。 a. provider.tf ファイルをローカルにダウンロードし、Terraform の作業ディレクトリにロードします。 b. variables.tf ファイルをローカルにダウンロードし、Terraform の作業ディレクトリにロードします。 c. main.tf ファイルをローカルにダウンロードし、Terraform の作業ディレクトリにロードします。 erraform.tfvars のようなファイル内の変数は環境に応じて設定してください。また、使用する前に以下の variables.tf の変数も修正してください: local_storage_hostname -クォーテーションで囲まれた文字列である &lt;S3_OBJECT_IP&gt; local_storage_bucket -クォーテーションで囲まれた文字列である &lt;downsampled-bucket-video&gt; local_storage_certificate -Step 2.6 で設定したパスとオブジェクト名 aws_region -us-east-1 を使用していない場合は変更 datasync_agent_ip_address または datasync_agent_activation_key -Step 6.3 f で選択したアクティベート方法に対して null をクォーテーションで囲んだ文字列型に置き換えて設定 さらに、以下のシェル変数をそれぞれ AWS SnowballEdge デバイスのアクセスキーとシークレットアクセスキーに設定します: export TF_VAR_local_storage_ak="SNOWBALLEDGE_ACCESS_KEY_ID" export TF_VAR_local_storage_sk="SNOWBALLEDGE_SECRET_ACCESS_KEY" または、Terraform の適用中にプロンプトが表示されたら、キー情報を入力することもできます。 Terraform ファイルを含む作業ディレクトリに移動し、マニフェストを適用します: terraform init terraform apply Step 8: AWS DataSync レプリケーションタスクを検証し実行 全ての設定が適切であることを確認するには、S3-snow バケット &lt;downsampled-bucket-video&gt; にファイルをアップロードし、手動で AWS DataSync タスクを実行します: テストファイルを S3-snow バケットにアップロードします: aws s3 cp &lt;testvideo.mpg&gt; s3://&lt;downsampled-bucket-video&gt;/&lt;testfile.mpg&gt; --profile snowsbe --endpoint-url https://&lt;S3_OBJECT_IP&gt; AWS DataSync タスクを実行します。&lt;DATASYNC_TASK_ARN&gt; は terraform apply の出力の最終行、またはコンソールの AWS DataSync サービスページの タスク にあります: aws datasync start-task-execution --task-arn &lt;DATASYNC_TASK_ARN&gt; 前のステップの出力で表示されたタスク実行 ARN から、タスクのステータスをチェックします: aws datasync describe-task-execution --task-execution-arn &lt;TASK_EXECUTION_ARN&gt; タスクが “Success” を返した場合、テストファイル ( testvideo.mpg ) は Amazon S3 の宛先バケットで利用可能になっているはずです。タスクが “Success” 以外のステータスで終了した場合、Amazon CloudWatch 上のタスク実行に関するログを確認することでトラブルシュートできます。“/aws/datasync/” に続くランダムな 12 文字のプレフィックスを持った Amazon CloudWatch のロググループをチェックしてください。 タスクのステータスを監視し、失敗した際に通知を作成するために、 Amazon EventBridge ルール を設定することもできます。また、監査目的で Amazon CloudWatch 上のログの保持期間を 30 日以上に設定したり、コスト最適化のために Amazon S3 バケットキー を有効にすることもできます。 2,000 万以上のファイル、オブジェクト、およびディレクトリをレプリケートするには、AWS DataSync エージェントに用いるインスタンスタイプを sbe-c.2xlarge から sbe-c.4xlarge に変更 し、 必要要件である 64 GB のメモリ を確保してください。 最後に、AWS DataSync がこれらのリクエストをどのように使用し、Amazon S3 のコストにどのような影響を与えるかをよりよく理解するために、AWS DataSync を使用する際の Amazon S3 のリクエストコスト を調べることをお勧めします。 クリーンアップ Terraform でデプロイしたインフラストラクチャを破棄するには、まず AWS リージョンの Amazon S3 バケットに保存されているオブジェクトをすべて完全に削除 します。また、新しく作成した Amazon S3 バケットの削除防止を解除するために、main.tfコードの 77 行目をコメントアウトまたは削除する必要があります。 最後に、ターミナルウィンドウから以下を実行します: terraform destroy まとめ この記事では、AWS DataSync を設定してエッジから AWS リージョンにデータを自動的かつ効率的に移行する方法を紹介しました。AWS Snowball Edge デバイス上の Amazon S3 互換ストレージを設定するために必要な手順を詳しく説明し、AMI とアプリケーションデータ用に 2 つのバケットを作成しました。AWS Snowball Edge に AWS DataSync エージェントをデプロイし、AWS Snowball Edge の Amazon S3 互換バケットから Amazon S3 バケットに変更されたデータを定期的に自動移行する AWS DataSync タスクをプログラムで構成する方法を説明しました。 このソリューションの全部または一部を使用することで、現場の AWS Snowball Edge デバイスとお客様のご希望の AWS リージョン間のあらゆるメディアデータの同期に関連するタイムラグを簡素化および削減し、機械学習の運用パイプラインやエンタープライズデータレイクへの保存などのユースケースを実現することができます。 <!-- '"` --> TAGS: Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage , AWS DataSync , AWS Snow Family Brad Beaulieu Brad Beaulieu は、Booz Allen 社の CTO (Chief Technology Office) である BrightLabs チームのプリンシパルとして、米国連邦政府および民間クライアント向けのエッジクラウド投資を主導しています。2009 年から Booz Allen 社に勤務し、クラウドセキュリティやマネージドサービスに関するさまざまな取り組みを行っています。裏庭でのガーデニングや山でのハイキングなど、アウトドアが趣味です。 Christopher Smith Christopher Smith は Amazon Web Services (AWS) の米国連邦政府パートナーチームの Principal Solutions Architect です。2003 年に民間企業に入って以来、米国連邦政府をサポートしています。自由な時間を家族のために使うことでワークライフバランスを管理し、可能な限りトリビアやアウトドアを楽しんでいます。 Dru Grote Dru Grote は Booz Allen Hamilton 社の Senior Lead Technologist です。クラウドにおける自動化および監視ソリューションのセキュアな実装に情熱を注いでいます。キーボードから離れているときは、写真を撮ったり、サイクリングをしています。

自動車、ロボット工学、金融などの業界では、製品を改善するために、シミュレーション、機械学習 (ML) モデルのトレーニング、ビッグデータ分析などの計算ワークロードの実装が増加の一途をたどっています。例えば、自動車メーカーはシミュレーションに依拠して自動運転機能をテストし、ロボット工学分野の企業は ML アルゴリズムをトレーニングしてロボットの認識機能を強化しているほか、金融業界の企業は詳細な分析を実行して、リスク管理、取引処理、不正行為の検出を改善しています。 シミュレーションを含むこれらのワークロードの一部は、コンポーネントの多様性と厳しい計算要件により、実行が特に複雑です。例えば、運転シミュレーションには、3D 仮想環境、車両センサーデータ、車両の挙動を制御する車両ダイナミクスなどの生成が伴います。ロボット工学シミュレーションでは、大規模な倉庫環境で、相互に、および他のシステムとインタラクションする何百もの自律型配送ロボットをテストする可能性があります。 AWS Batch は、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Fargate 、および Amazon EC2 スポット または オンデマンド インスタンスなど、さまざまな AWS コンピューティングサービスにわたってバッチワークロードを実行するのに役立つフルマネージドサービスです。従来、AWS Batch では単一コンテナのジョブのみが許可されており、すべてのコンポーネントをモノリシックコンテナにマージするには追加のステップが必要でした。また、データログ記録などの追加サービスを提供することでメインアプリケーションを補完する補助コンテナである、別個の「サイドカー」コンテナも使用できませんでした。コードの変更はコンテナ全体の再構築を意味するため、この追加の作業には、ソフトウェア開発、IT 運用、品質保証 (QA) などの複数のチームにわたる調整が必要でした。 AWS Batch はマルチコンテナジョブを提供するようになりました。これにより、自動運転車やロボット工学などの分野で大規模なシミュレーションをより簡単かつ迅速に実行できます。これらのワークロードは通常、シミュレーション自体と、シミュレーションとインタラクションするテスト対象のシステム (エージェントとも呼ばれます) に分割されます。これらの 2 つのコンポーネントは、多くの場合、異なるチームによって開発および最適化されます。ジョブごとに複数のコンテナを実行できるため、AWS Batch が提供する高度なスケーリング、スケジューリング、コストの最適化を利用できるほか、3D 環境、ロボットセンサー、モニタリングサイドカーなどのさまざまなコンポーネントを表すモジュール式コンテナを使用できます。実際、 IPG Automotive 、 MORAI 、 Robotec.ai などのお客様は既に AWS Batch マルチコンテナジョブを使用してクラウドでシミュレーションソフトウェアを実行しています。 簡単な例を使用して実際にこれがどのように機能するかを見て、迷路を解くのを楽しんでみましょう。 コンテナ上で実行されるシミュレーションの構築 本番環境では、おそらく既存のシミュレーションソフトウェアを使用することになります。この記事では、エージェント/モデルシミュレーションの簡易バージョンを構築しました。コードの詳細に興味がない場合は、このセクションを飛ばして、AWS Batch の設定方法にお進みください。 このシミュレーションでは、探索する世界はランダムに生成された 2D の迷路です。エージェントには、迷路を探索して鍵を見つけ、出口に到達するというタスクが課されています。ある意味、これは 3 つの場所がある経路探索問題の典型的な例です。 これは、開始 ( S )、終了 ( E )、およびキー ( K ) の位置を示した迷路のサンプルマップです。 エージェントとモデルを 2 つの別々のコンテナに分離することで、異なるチームがそれぞれを個別に作業できるようになります。各チームは、シミュレーションに詳細を追加したり、エージェントが迷路を探索する方法についてより優れた戦略を見つけたりするなど、自分の担当部分の改善に集中できます。 迷路モデルのコードは次のとおりです ( app.py )。どちらの例でも Python を使用しました。このモデルは、エージェントが迷路内を移動したり、鍵を見つけて出口に到達したかどうかを把握したりするために使用できる REST API を公開します。迷路モデルは REST API に Flask を使用します。 import json import random from flask import Flask, request, Response ready = False # マップデータを迷路内に保存する方法 # サイズ指定あり (幅 x 高さ) = (4 x 3) # # 012345678 # 0: +-+-+ +-+ # 1: | | | | # 2: +-+ +-+-+ # 3: | | | | # 4: +-+-+ +-+ # 5: | | | | | # 6: +-+-+-+-+ # 7: 未使用 class WrongDirection(Exception): pass class Maze: UP, RIGHT, DOWN, LEFT = 0, 1, 2, 3 OPEN, WALL = 0, 1 @staticmethod def distance(p1, p2): (x1, y1) = p1 (x2, y2) = p2 return abs(y2-y1) + abs(x2-x1) @staticmethod def random_dir(): return random.randrange(4) @staticmethod def go_dir(x, y, d): if d == Maze.UP: return (x, y - 1) elif d == Maze.RIGHT: return (x + 1, y) elif d == Maze.DOWN: return (x, y + 1) elif d == Maze.LEFT: return (x - 1, y) else: raise WrongDirection(f"Direction: {d}") def __init__(self, width, height): self.width = width self.height = height self.generate() def area(self): return self.width * self.height def min_lenght(self): return self.area() / 5 def min_distance(self): return (self.width + self.height) / 5 def get_pos_dir(self, x, y, d): if d == Maze.UP: return self.maze[y][2 * x + 1] elif d == Maze.RIGHT: return self.maze[y][2 * x + 2] elif d == Maze.DOWN: return self.maze[y + 1][2 * x + 1] elif d == Maze.LEFT: return self.maze[y][2 * x] else: raise WrongDirection(f"Direction: {d}") def set_pos_dir(self, x, y, d, v): if d == Maze.UP: self.maze[y][2 * x + 1] = v elif d == Maze.RIGHT: self.maze[y][2 * x + 2] = v elif d == Maze.DOWN: self.maze[y + 1][2 * x + 1] = v elif d == Maze.LEFT: self.maze[y][2 * x] = v else: WrongDirection(f"Direction: {d} Value: {v}") def is_inside(self, x, y): return 0 &lt;= y &lt; self.height and 0 &lt;= x &lt; self.width def generate(self): self.maze = [] # すべての境界を閉じます for y in range(0, self.height + 1): self.maze.append([Maze.WALL] * (2 * self.width + 1)) # いずれかの境界線でランダムな開始点を取得します if random.random() &lt; 0.5: sx = random.randrange(self.width) if random.random() &lt; 0.5: sy = 0 self.set_pos_dir(sx, sy, Maze.UP, Maze.OPEN) else: sy = self.height - 1 self.set_pos_dir(sx, sy, Maze.DOWN, Maze.OPEN) else: sy = random.randrange(self.height) if random.random() &lt; 0.5: sx = 0 self.set_pos_dir(sx, sy, Maze.LEFT, Maze.OPEN) else: sx = self.width - 1 self.set_pos_dir(sx, sy, Maze.RIGHT, Maze.OPEN) self.start = (sx, sy) been = [self.start] pos = -1 solved = False generate_status = 0 old_generate_status = 0 while len(been) &lt; self.area(): (x, y) = been[pos] sd = Maze.random_dir() for nd in range(4): d = (sd + nd) % 4 if self.get_pos_dir(x, y, d) != Maze.WALL: continue (nx, ny) = Maze.go_dir(x, y, d) if (nx, ny) in been: continue if self.is_inside(nx, ny): self.set_pos_dir(x, y, d, Maze.OPEN) been.append((nx, ny)) pos = -1 generate_status = len(been) / self.area() if generate_status - old_generate_status &gt; 0.1: old_generate_status = generate_status print(f"{generate_status * 100:.2f}%") break elif solved or len(been) &lt; self.min_lenght(): continue else: self.set_pos_dir(x, y, d, Maze.OPEN) self.end = (x, y) solved = True pos = -1 - random.randrange(len(been)) break else: pos -= 1 if pos &lt; -len(been): pos = -1 self.key = None while(self.key == None): kx = random.randrange(self.width) ky = random.randrange(self.height) if (Maze.distance(self.start, (kx,ky)) &gt; self.min_distance() and Maze.distance(self.end, (kx,ky)) &gt; self.min_distance()): self.key = (kx, ky) def get_label(self, x, y): if (x, y) == self.start: c = 'S' elif (x, y) == self.end: c = 'E' elif (x, y) == self.key: c = 'K' else: c = ' ' return c def map(self, moves=[]): map = '' for py in range(self.height * 2 + 1): row = '' for px in range(self.width * 2 + 1): x = int(px / 2) y = int(py / 2) if py % 2 == 0: # 偶数行 if px % 2 == 0: c = '+' else: v = self.get_pos_dir(x, y, self.UP) if v == Maze.OPEN: c = ' ' elif v == Maze.WALL: c = '-' else: # 奇数行 if px % 2 == 0: v = self.get_pos_dir(x, y, self.LEFT) if v == Maze.OPEN: c = ' ' elif v == Maze.WALL: c = '|' else: c = self.get_label(x, y) if c == ' ' and [x, y] in moves: c = '*' row += c map += row + '\n' return map app = Flask(__name__) @app.route('/') def hello_maze(): return "&lt;p&gt;Hello, Maze!&lt;/p&gt;" @app.route('/maze/map', methods=['GET', 'POST']) def maze_map(): if not ready: return Response(status=503, retry_after=10) if request.method == 'GET': return '&lt;pre&gt;' + maze.map() + '&lt;/pre&gt;' else: moves = request.get_json() return maze.map(moves) @app.route('/maze/start') def maze_start(): if not ready: return Response(status=503, retry_after=10) start = { 'x': maze.start[0], 'y': maze.start[1] } return json.dumps(start) @app.route('/maze/size') def maze_size(): if not ready: return Response(status=503, retry_after=10) size = { 'width': maze.width, 'height': maze.height } return json.dumps(size) @app.route('/maze/pos/&lt;int:y&gt;/&lt;int:x&gt;') def maze_pos(y, x): if not ready: return Response(status=503, retry_after=10) pos = { 'here': maze.get_label(x, y), 'up': maze.get_pos_dir(x, y, Maze.UP), 'down': maze.get_pos_dir(x, y, Maze.DOWN), 'left': maze.get_pos_dir(x, y, Maze.LEFT), 'right': maze.get_pos_dir(x, y, Maze.RIGHT), } return json.dumps(pos) WIDTH = 80 HEIGHT = 20 maze = Maze(WIDTH, HEIGHT) ready = True 迷路モデル ( requirements.txt 内) の唯一の要件は、 Flask モジュールです。 迷路モデルを実行するコンテナイメージを作成するには、この Dockerfile を使用します。 FROM --platform=linux/amd64 public.ecr.aws/docker/library/python:3.12-alpine WORKDIR /app COPY requirements.txt requirements.txt RUN pip3 install -r requirements.txt COPY . . CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0", "--port=5555"] エージェントのコードは次のとおりです ( agent.py )。まず、エージェントはモデルに迷路のサイズと開始位置をたずねます。その後、独自の戦略を適用して迷路を探索し、解決します。この実装では、エージェントはルートをランダムに選択し、同じパスを複数回たどることを避けようとします。 import random import requests from requests.adapters import HTTPAdapter, Retry HOST = '127.0.0.1' PORT = 5555 BASE_URL = f"http://{HOST}:{PORT}/maze" UP, RIGHT, DOWN, LEFT = 0, 1, 2, 3 OPEN, WALL = 0, 1 s = requests.Session() retries = Retry(total=10, backoff_factor=1) s.mount('http://', HTTPAdapter(max_retries=retries)) r = s.get(f"{BASE_URL}/size") size = r.json() print('SIZE', size) r = s.get(f"{BASE_URL}/start") start = r.json() print('START', start) y = start['y'] x = start['x'] found_key = False been = set((x, y)) moves = [(x, y)] moves_stack = [(x, y)] while True: r = s.get(f"{BASE_URL}/pos/{y}/{x}") pos = r.json() if pos['here'] == 'K' and not found_key: print(f"({x}, {y}) key found") found_key = True been = set((x, y)) moves_stack = [(x, y)] if pos['here'] == 'E' and found_key: print(f"({x}, {y}) exit") break dirs = list(range(4)) random.shuffle(dirs) for d in dirs: nx, ny = x, y if d == UP and pos['up'] == 0: ny -= 1 if d == RIGHT and pos['right'] == 0: nx += 1 if d == DOWN and pos['down'] == 0: ny += 1 if d == LEFT and pos['left'] == 0: nx -= 1 if nx &lt; 0 or nx &gt;= size['width'] or ny &lt; 0 or ny &gt;= size['height']: continue if (nx, ny) in been: continue x, y = nx, ny been.add((x, y)) moves.append((x, y)) moves_stack.append((x, y)) break else: if len(moves_stack) &gt; 0: x, y = moves_stack.pop() else: print("No moves left") break print(f"Solution length: {len(moves)}") print(moves) r = s.post(f'{BASE_URL}/map', json=moves) print(r.text) s.close() エージェントの唯一の依存関係 ( requirements.txt 内) は、 requests モジュールです。 これは、エージェントのコンテナイメージを作成するために使用する Dockerfile です。 FROM --platform=linux/amd64 public.ecr.aws/docker/library/python:3.12-alpine WORKDIR /app COPY requirements.txt requirements.txt RUN pip3 install -r requirements.txt COPY . . CMD [ "python3", "agent.py"] この簡略化されたバージョンのシミュレーションはローカルで簡単に実行できますが、クラウドを利用すると、より大規模に実行し (より大規模で詳細な迷路で実行するなど)、複数のエージェントをテストして使用する最適な戦略を見つけることができます。現実のシナリオでは、エージェントの改善はその後、自動運転車やロボット掃除機などの物理デバイスに実装されます。 マルチコンテナジョブを使用したシミュレーションの実行 AWS Batch を利用してジョブを実行するには、次の 3 つのリソースを設定する必要があります: ジョブを実行する コンピューティング環境 ジョブを送信する ジョブキュー 使用するコンテナイメージなど、ジョブの実行方法を記述する ジョブ定義 AWS Batch コンソール で、ナビゲーションペインから [コンピューティング環境] を選択し、次に [作成] を選択します。現在、Fargate、Amazon EC2、または Amazon EKS を利用する選択肢があります。Fargate を利用すると、ジョブ定義で指定したリソース要件に厳密に一致させることができます。ただし、シミュレーションでは通常、大量ではあるものの静的な量のリソースにアクセスする必要があり、計算を高速化するために GPU が使用されます。そのため、ここでは [Amazon EC2] を選択します。 AWS Batch が EC2 インスタンスをスケールおよび設定できるように、 [マネージド] オーケストレーションタイプを選択します。その後、コンピューティング環境の名前を入力し、サービスにリンクされたロール (AWS Batch が以前に作成したもの) と、(EC2 インスタンス上で実行されている) ECS コンテナエージェントが私に代わって AWS API に対して呼び出しを実行するために使用するインスタンスロールを選択します。 [次へ] を選択します。 [インスタンス構成] 設定で、EC2 インスタンスのサイズとタイプを選択します。例えば、GPU を備えたインスタンスタイプや Graviton プロセッサを使用するインスタンスタイプを選択できます。特別な要件はなく、すべての設定をデフォルト値のままにします。 [ネットワーク構成] で、コンソールでは既に [デフォルト VPC] と [デフォルトセキュリティグループ] が選択されています。最後のステップでは、すべての設定を確認し、コンピューティング環境の作成を完了します。 ここで、ナビゲーションペインから [ジョブキュー] を選択し、次に [作成] を選択します。その後、コンピューティング環境に使用したのと同じオーケストレーションタイプ ( Amazon EC2 ) を選択します。 [ジョブキューの設定] で、ジョブキューの名前を入力します。 [接続されたコンピューティング環境] ドロップダウンで、作成したばかりのコンピューティング環境を選択し、キューの作成を完了します。 ナビゲーションペインから [ジョブ定義] を選択し、次に [作成] を選択します。前と同様に、オーケストレーションタイプとして [Amazon EC2] を選択します。 複数のコンテナを使用するには、 [従来の containerProperties 構造を使用] オプションを無効にして、次のステップに進みます。デフォルトでは、アカウントに従来のジョブ定義が既に存在する場合、コンソールは従来の単一コンテナジョブ定義を作成します。私の場合はそのようになります。従来のジョブ定義を持たないアカウントの場合、コンソールではこのオプションが無効になっています。 ジョブ定義の名前を入力します。その後、このジョブにどの許可が必要かを考える必要があります。このジョブに使用するコンテナイメージは、 Amazon ECR プライベートリポジトリに保存されています。AWS Batch がこれらのイメージをコンピューティング環境にダウンロードできるようにするには、 [タスクプロパティ] セクションで、ECR リポジトリに対する読み取り専用アクセスを付与する [実行ロール] を選択します。シミュレーションコードは AWS API を呼び出していないため、 [タスクロール] を設定する必要はありません。例えば、コードが結果を Amazon Simple Storage Service (Amazon S3) バケットにアップロードする場合、そのための許可を付与するロールをここで選択できます。 次のステップでは、このジョブで使用される 2 つのコンテナを設定します。1 つ目は maze-model です。名前と画像の場所を入力します。ここでは、vCPU、メモリ、GPU の観点からコンテナのリソース要件を指定できます。これは、 ECS タスク のコンテナの設定に似ています。 エージェント用の 2 番目のコンテナを追加し、以前と同様に名前、イメージの場所、リソース要件を入力します。エージェントは迷路の開始直後に迷路にアクセスする必要があるため、 [依存関係] セクションを使用してコンテナの依存関係を追加します。コンテナ名として maze-model を選択し、条件として START を選択します。この依存関係を追加しない場合、 maze-model コンテナが実行されて応答できるようになる前に、 agent コンテナが失敗する可能性があります。このジョブ定義では両方のコンテナに必須のフラグが設定されているため、ジョブ全体が失敗して終了します。 すべての設定を確認し、ジョブ定義を完了します。これで、仕事を始めることができます。 ナビゲーションペインの [ジョブ] セクションで、新しいジョブを送信します。名前を入力し、ジョブキューと作成したばかりのジョブ定義を選択します。 次のステップでは、設定を上書きしてジョブを作成する必要はありません。数分後、ジョブは成功し、2 つのコンテナのログにアクセスできるようになりました。 エージェントは迷路を解決したので、ログからすべての詳細を取得できます。エージェントがどのように開始され、キーを取得し、出口を見つけたかを示すジョブの出力を次に示します。 SIZE {'width': 80, 'height': 20} START {'x': 0, 'y': 18} (32, 2) key found (79, 16) exit Solution length: 437 [(0, 18), (1, 18), (0, 18), ..., (79, 14), (79, 15), (79, 16)] マップでは、赤いアスタリスク ( * ) は、開始 ( S )、キー ( K )、および終了 ( E ) の場所間でエージェントがたどるパスを示しています。 サイドカーコンテナによるオブザーバビリティの向上 複数のコンポーネントを使用して複雑なジョブを実行する場合、これらのコンポーネントが何を行っているかをより明確に把握することができます。例えば、エラーやパフォーマンスの問題が発生した場合、この情報は問題が発生した場所とその内容を見つけるのに役立ちます。 アプリケーションをインストルメント化するには、 AWS Distro for OpenTelemetry を使用します。 まず、 agent コンテナと maze-model コンテナを更新して、 この記事で説明されている Python 自動インストルメンテーションを使用します 。Go、Java、JavaScript など、他のプラットフォームにも同様のチュートリアルがあります。自分のアプリケーションに固有の情報を取得するために、 コードを手動でインストルメント化する というオプションがあります。 その後、 Amazon ECR Public Gallery の AWS Distro for OpenTelemetry Collector を使用してサイドカーコンテナを追加します。 collector コンテナは、他のコンテナからテレメトリデータを受信し、トレースを AWS X-Ray に送信して、メトリクスを Amazon CloudWatch 、 Amazon Managed Service for Prometheus 、またはセルフマネージド Prometheus に送信します。OpenTelemetry を使用すると、 複数のモニタリングおよびオブザーバビリティプラットフォーム とのデータの共有が容易になります。 この方法で収集されたテレメトリデータを使用すると、何が起こっているかをより良く理解し、問題を解決するための時間を短縮するのに役立つダッシュボード (例えば、CloudWatch または Amazon Managed Grafana を利用) やアラーム (CloudWatch または Prometheus を利用) を設定できます。より一般的には、サイドカーコンテナは、AWS Batch ジョブからのテレメトリデータをモニタリングおよびオブザーバビリティプラットフォームに統合するのに役立ちます。 知っておくべきこと AWS Batch によるマルチコンテナジョブのサポートは現在、Batch が提供されているすべての AWS リージョン において、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK でご利用いただけます。詳細については、 AWS サービス (リージョン別) をご覧ください。 AWS Batch でマルチコンテナジョブを使用する場合、追加料金はかかりません。実際、AWS Batch の利用には追加料金はかかりません。お支払いいただくのは、EC2 インスタンスや Fargate コンテナなど、アプリケーションを保存および実行するために作成した AWS リソースの料金のみです。コストを最適化するために、コンピューティング環境で リザーブドインスタンス 、 Savings Plan 、EC2 スポットインスタンス、Fargate を使用できます。 マルチコンテナジョブを使用すると、ジョブの準備作業が減ることで開発時間が短縮されるほか、複数のチームの作業を 1 つのコンテナにマージするカスタムツールの必要性がなくなります。また、コンポーネントの責任を明確に定義することで DevOps を簡素化し、チームが他の作業に煩わされることなく自分の専門分野の問題を迅速に特定して修正できるようにします。 詳細については、「 AWS Batch ユーザーガイド 」でマルチコンテナジョブを設定する方法をご覧ください。 – Danilo 原文は こちら です。

組織の目的に応じたリソースタグを一貫して適用することは、簡単ではないケースがあります。例えば、正確な原価配分や細かなアクセス制御などを行いたい時です。また、開発者が開発やテストの初期段階で作成した別環境のリソースをクリーンアップする時に、問題に直面することもあるでしょう。適切なタグ付けがされていないと、組織から離れた開発者が作成したお試しリソースを特定したり、プロジェクトが終了した際にリソースをクリーンアップするのが難しくなります。 AWSリソースへのタグ付けは、ワークロード開発の初期段階で見落とされがちです。開発者にタグ付与ルールを守らせるのに苦労するユーザーもいます。AWS リソースに対して正確で意味のあるタグを一貫して付けることこそが、ベストプラクティスです。 AWS Organizations の全機能を有効にしているユーザーに人気の方法の1つは、すべてのリソースに特定のタグを付けることを要求するサービス制御ポリシー (SCP) を作成し、タグポリシーを使ってリソースに有効なタグが付けられるようにすることです。AWS Organizations は複数の AWS アカウントの管理をポリシーベースで行え、AWS リソースのスケーリングに伴う環境を一元管理できます。 あるいは、企業が現在 AWS Organizations を使用していないか、より柔軟なソリューションが必要な場合は、AWS Resource Explorer と AWS CloudTrail を使って適切なタグが自動的に付けられるようにできます。このブログで説明するソリューションでは、AWS リソースに適切なタグが非同期的に付けられるよう自動化する方法が示されています。これにより、AWS リソースをカテゴリ分けして追跡し、変動するコストを制御・監視できるようになります。 ソリューションの概要 自動タグ付けソリューション（resource-autotagger）は、自動化されたワークフローを使用して、新しく作成されたリソースに必要なタグを適用します。このソリューションでは、AWS Resource Explorer と AWS CloudTrail の 2 つのコアサービスを利用しています。Amazon CloudWatch Events で作成されたルールにより、タグ付けプロセスがスケジュールされます。AWS Lambda 関数と Amazon DynamoDB テーブルは、タグ付けされていないリソースを対応する CloudTrail 作成イベントにマッピングするために動作しています。 前提条件 このソリューションでは、自動タグ付けに AWS Resource Explorer と AWS CloudTrail を利用しています。そのため、これらのサービスをアカウントで有効にする必要があります。ソリューションを展開する前に、次の 2 つのアクションを完了する必要があります。 ・Resource Explorer のインデックス作成を有効にする ・CloudTrail を有効にし、証跡がない場合は作成する 図1: 自動タグ付けソリューション（resource-autotagger）のワークフロー ソリューションフロー ソリューションの動作フローは次のとおりです。 １　Amazon EventBridge スケジューラルールは、新しいリソースが作成されたかどうかを検出するために30分ごとに実行されるように設定されています。 ２　スケジューラルールはLambda関数をトリガーします。 ３　Lambda関数は、Amazon S3バケットに保存されたマッピングファイルをスキャンして、リソースタイプのリストとそのマッピングされたCloudTrailのイベント名とイベントソースを取得します。このデモでは、リソースタイプの一覧には、Amazon EC2、S3バケット、Lambda、Amazon ECS が含まれています。 ４　マッピングファイルからのすべてのリソースタイプについて、Lambda関数はAWS Resource Explorerを使用して、適切なタグ付けがされていないリソースを検索します。 ５　Resource Explorerから返されたリソース識別子ごとに、Lambda関数はステップ4のマッピングファイルを使用して、リソース識別子、CloudTrailイベントソース、CloudTrailイベント名を使用してCloudTrailイベントを参照し、リソースを作成したプリンシパル情報を見つけます。 ６　Lambda関数はCloudTrailイベントから作成されたリソースのプリンシパル情報に基づいてタグリストを生成し、 リソースグループタグ付けAPI を呼び出してリソースに自動的にタグを付けます。 ソリューションのデプロイ 今回初めて AWS Cloud Development Kit (CDK) を利用する場合は、CDKのインストールを行う必要があります。 アプリケーションをローカルマシンにクローンします。 git clone https://github.com/aws-samples/resource-autotagger.git プロジェクトディレクトリに移動します。 cd resource-autotagger AWS Cloud Development Kit (AWS CDK) と Lambda 関数のノード依存関係をインストールします。 npm install AWS アカウントで AWS CDK がまだセットアップされていない場合は、以下のコマンドを実行してブートストラップします。 cdk bootstrap AWS CDK でソリューションリソースをデプロイします。 cdk deploy ソリューションをデプロイした後、数分以内に「Created by」や「IAM Role name」などのユーザー識別タグがリソースに適用されていることがわかります。 他の AWS サービスへのソリューションの拡張 このデモソリューションでは、S3バケット内のマッピングファイルに格納されたマッピング情報に基づいて、Amazon EC2、S3バケット、Lambda、Amazon ECSのリソースに自動的にタグを付けることをカバーしています。このソリューションを他のAWSサービスに拡張するには、マッピングファイルを追加のリソースタイプとそれに対応するCloudTrailのイベント名、イベントソース、およびリソースエクスプローラーのリソースタイプ値で更新する必要があります。 追加のリソースタイプにタグを付けるために必要なAWS IAMの許可は、AWS Lambdaの実行ポリシーに追加する必要があることに注意してください。 例）Amazon API Gatewayリソースの作成タグ付けを追加する手順は次のとおりです。 1. API Gateway REST APIの作成とAPI Gateway REST APIクエリのCloudTrailイベント名、CloudTrailイベントソース、およびリソースエクスプローラーのリソースタイプを特定します。この情報はステップ2とステップ3でマッピングファイルを更新するために必要になります。Amazon API Gatewayの場合、CloudTrailの作成イベント名は “ CreateRestApi “、イベントソースは “amazonaws.com”、リソースエクスプローラーのリソースタイプは “apigateway:restapis” です。 2. Amazon S3コンソールに移動し、”resourceautotagcdkstack-resourceautotagbucket” で始まるS3バケット名を開きます。このバケットには “json” という名前のJSONファイルが含まれています。 3. ステップ1で特定した値を使用して、JSONファイルを次のJSONの構造で更新し、バケットにアップロードします。Globalプロパティは、グローバルに一意のリソース(S3バケットなど)にのみ適用されることに注意してください。”CT”で始まるプロパティはCloudTrailのプロパティを指し、”RE”はリソースエクスプローラーのプロパティを指します。 { "CTEventName": "CreateRestApi", "CTEventSource": "apigateway.amazonaws.com", "REResourceType": "apigateway:restapis", "Global": false } 4. IAM コンソールに移動します。左側のナビゲーションで [ロール] をクリックし、AWS CDK デプロイメントから作成された Lambda 実行用の IAM ロールを検索します。ロール名は ResourceAutoTagCdkStack- で始まります。 5. 許可ポリシーから[許可を追加] をクリックしてから [インラインポリシーを作成] をクリックします。[ポリシーエディタ] 画面でJSONを選択し、次のコードブロックに示されている IAM ステートメントを追加して、Lambda 関数が REST API にタグを追加できるようにします。&lt;region&gt; は、デプロイ先のリージョンに置き換えてください。 { "Sid": "ResourceAutoTaggerAPIGatewayTagging", "Effect": "Allow", "Action": ["apigateway:POST","apigateway:PUT","apigateway:PATCH"], "Resource": "arn:aws:apigateway:&lt;region&gt;::/*/*" } 図2:権限を追加した後のサンプルLambda関数の実行ポリシー 6. 次へをクリックして変更を保存します。 クリーンアップ 自動タグ付け機能をテストした後の課金を避けるために、次のコマンドを実行して、クローンされたリポジトリのルートディレクトリから AWD CDK スタックを削除してください。 cdk destroy 考慮事項 AWS リソースエクスプローラーには、1か月あたり10,000回の検索操作の制限があり、1回のクエリで最大1,000件の結果を返すことができます。これにより、アカウントごとに月間最大10,000,000の AWS リソースにタグを付けることができます。 さらに、AWS リソースには、リソースごとに最大50個のタグを付けることができます。このソリューションでは、既に50個のタグが付いているリソースには指定したタグを追加できません。 現在のソリューションは1つの AWS アカウントに限定されており、複数のアカウントにまたがってタグを付けることはできません。 まとめ このブログでは、AWS リソースエクスプローラーと Amazon CloudTrail を組み合わせて、リソースのタグ付けを自動化する方法を示しました。このソリューションは、既存のワークロードに影響を与えずに、必要なタグを AWS リソースに適用する柔軟で、カスタマイズ可能な代替方法です。サービスコントロールポリシーを有効にする必要はなく、バックグラウンドで非同期に実行されるため、AWS リソースにタグが付けられます。 関連リソース AWSリソースタグ付けの準備、方法と有効なAWSサービス AWS コスト配分タグの使用 属性ベースのアクセス制御 (ABAC) を使用した細かいアクセス制御 AWS リソースのタグ付けのベストプラクティス 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。 著者について Nikhil Enmudi Nikhilは AWS のシニアソリューションアーキテクトであり、サーバーレスソリューションにスペシャリティを持っています。彼は、グローバルな独立系ソフトウェアベンダー (ISV) 顧客のクラウド移行を支援し、ソフトウェア製品向けのソリューション構築を支援しています。 &nbsp; &nbsp; Yohan Supangat Yohanは AWS のソリューションアーキテクトであり、サーバーレスソリューションにスペシャリティを持っています。彼は、エンタープライズの新規顧客と協力し、AWS のテクノロジーとサービスの採用を支援し、ビジネス目標の達成を支援しています。

AWS Summit のシーズンが始まります! 4月1日週は AWS Summit Paris 、4月8日週には AWS Summit Amsterdam で、お客様、パートナー、報道関係者の皆様にお会いできるのを楽しみにしています。私はモバイルアプリデベロッパーが生成人工知能 (AI) を使用して生産性を高める方法を説明する予定です。見かけたらぜひお声がけください。 Summit での講演の準備が終わったので、3月18日週の AWS のリリースを振り返り、この要約を書きました。 3月18日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS License Manager を利用することで、 Amazon Relational Database Service (Amazon RDS) で IBM Db2 ライセンスを追跡可能に – 2023 年 12 月に IBM Db2 をリリースしたとき 、私は Amazon RDS についての記事を書き、自分の Db2 ライセンスを使用する必要がある旨をお伝えしました。3月25日より、 AWS License Manager を利用して Amazon RDS for Db2 の使用状況を追跡できるようになりました。 License Manager を利用すると、ライセンスをより良く管理でき、その可視性が高まるため、ライセンスの超過を制限したり、コンプライアンス違反や誤報のリスクを軽減したりするのに役立ちます。 AWS CodeBuild で AWS Lambda のカスタムイメージのサポートを開始 – Lambda コンピューティングで実行するように設定されたプロジェクトのために Amazon Elastic Container Registry (Amazon ECR) リポジトリに保存されている コンピューティングコンテナイメージを使用 できるようになりました。以前は、 AWS CodeBuild によって提供されるマネージドコンテナイメージの 1 つを使用する必要がありました。AWS マネージドコンテナイメージには、 AWS コマンドラインインターフェイス (AWS CLI) 、 サーバーレスアプリケーションモデル 、およびさまざまなプログラミング言語ランタイムのサポートが含まれています。 AWS CodeArtifact パッケージグループ設定 – パッケージリポジトリの管理者は、 複数のパッケージの設定を 1 か所で管理 できるようになりました。パッケージグループを使用すると、内部のデベロッパーによって、またはアップストリームリポジトリから、パッケージが更新される方法を定義できます。内部のデベロッパーによるパッケージの公開を許可またはブロックしたり、パッケージのグループについてのアップストリームの更新を許可またはブロックしたりできるようになりました。 詳細については、私のブログ記事をお読みください 。 Savings Plans のキャンセル – Savings Plans の購入後 7 日以内であればキャンセルできる機能 を発表しました。 Savings Plans は柔軟な料金モデルで、1 年間または 3 年間の時間単位の一定の支出を確約する代わりに、オンデマンド料金と比較して請求額を最大 72% 削減できます。購入してから間もない Savings Plan がニーズに最適ではないことがわかった場合は、それをキャンセルし、必要に応じて、ニーズにより合った別の Savings Plan を再購入できます。 Amazon EC2 Mac 専有ホストで、サポートされている macOS バージョンの表示が可能に – EC2 Mac 専有ホストでサポートされている 最新の macOS バージョンを表示できるようになりました 。これにより、専有ホストが希望の macOS バージョンのインスタンスをサポートできるかどうかを事前に検証できます。 Amazon Corretto 22 の一般公開を開始 – OpenJDK の機能リリースである Corretto 22 では、デベロッパー向けにさまざまな新機能と機能強化が導入されています。ストリームギャザラーや名前のない変数などの新機能は、より明確でメンテナンスしやすいコードを記述するのに役立ちます。さらに、ガベージコレクションアルゴリズムの最適化により、パフォーマンスが改善されます。同時実行性、クラスファイル、外部関数用の既存のライブラリも更新され、堅牢で効率的な Java アプリケーションを構築するためのより強力なツールキットが提供されます。 Amazon DynamoDB でリソースベースのポリシーと AWS PrivateLink のサポートを開始 – AWS PrivateLink を利用すると、 Amazon Virtual Private Cloud (Amazon VPC) 、 Amazon DynamoDB 、およびインターフェイス VPC エンドポイントとプライベート IP アドレスを使用するオンプレミスデータセンター間のプライベートネットワーク接続を簡素化できます。一方、 リソースベースのポリシー は、 DynamoDB リソースのアクセスコントロールを簡素化するのに役立ちます。リソースベースのポリシーを使用すると、リソースにアクセスできる AWS Identity and Access Management (IAM) プリンシパルと、そのリソースに対して実行できるアクションを指定できます。リソースベースのポリシーを DynamoDB テーブルまたはストリームにアタッチできます。また、リソースベースのポリシーにより、異なる AWS アカウントの IAM プリンシパルとリソースを共有するためのクロスアカウントアクセスコントロールも簡素化されます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加のニュース項目、オープンソースプロジェクト、Twitch の番組をいくつかご紹介します。 British Broadcasting Corporation (BBC) が 25 PB のアーカイブを Amazon S3 Glacier に移行 – BBC Archives Technology and Services チームは、100 年前の重要なアーカイブを一元化、デジタル化、移行する最新のソリューションを必要としていました。同社は Amazon Simple Storage Service (Amazon S3) Glacier Instant Retrieval の利用を開始しました。これは、ほとんどアクセスされず、ミリ秒単位での取得が必要な長期データ用に、極めて低コストのストレージを提供するアーカイブストレージクラスです。計算してみたところ、25 PB のデータを保存するには 2,788,555 枚の DVD ディスクが必要です。DVD の山が高さ 41.8 キロメートル (25.9 マイル) に達するところを想像してみてください! ぜひ全文をお読みください 。 Build On Generative AI – 生成 AI のあらゆるトピックを取り上げる人気の 毎週の Twitch 番組 のシーズン 3 が盛り上がりを見せています。 毎週月曜日、午前 9 時 (米国太平洋時間) にストリーミング配信されます。私の同僚の Tiffany と Darko が生成 AI のさまざまな側面について話し合い、ゲストスピーカーをお招きして、そのデモをご紹介します。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週 執筆しています。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – 冒頭でお伝えしたように、今年も AWS Summit のシーズンがやってきました。 最初のイベントは来週 パリ で開催されます (4 月 3 日)。その後は、 アムステルダム (4 月 9 日)、 シドニー (4 月 10～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15～16 日)、 ソウル (5 月 16～17 日) と続きます。AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、つながり、コラボレーションし、AWS について学ぶための一連の無料のオンラインおよび対面イベントです。 AWS re:Inforce – ペンシルベニア州フィラデルフィアで開催される AWS re:Inforce (6 月 10～12 日) にぜひご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながり、AWS のお客様のセキュリティジャーニーについて学ぶことができます。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 3月25日週はここまでです。4月1日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

ソリューションアーキテクトの池田です。2024 年 3 月 12 日に「 AWS Compute Performance and Efficiency 」を目黒で開催しました。本セミナーでは、Amazon Elastic Compute Cloud (Amazon EC2) をコスト効率よく活用する方法について、海外のスペシャリストも交えて解説しました。インスタンスの選び方や AWS Graviton の活用、Kubernetes 環境での最適化、そして最新事例もご紹介をしました。 本記事では、発表内容の概要と発表資料を掲載しています。 セミナー概要 タイトル: 「 AWS Compute Performance and Efficiency 」 日時: 2024 年 3 月 12 日（火） セッション詳細 9:40 -10:10 「AWS における効率的なコンピュートサービス活用入門」 講師: Senior Specialist Solutions Architect, Compute 宮本大輔 概要: AWS で、Amazon EC2 を中心としたコンピュートサービスを効率的に活用するにはどうしたらよいでしょうか。本セッションでは、スポットインスタンスや AWS 独自の CPU である Graviton の活用を中心に、インスタンスサイズの最適化や Compute Optimizer 、Auto Scaling など、コンピュートサービスのコストを最適化するための幅広い戦略やツールについてご紹介します。 資料 10:10-10:30 「 Graviton Migration Story 」 講師: ASEAN Principal EC2 Specialist, Abhishek Singh 概要: Grab は配車や配送、決済など様々なサービスを東南アジアを中心に展開している企業です。本セッションでは、Grab がいかにして AWS Graviton に移行し、コスト最適化を成功させたかについてご紹介いたします。 本セッションの資料については非公開のため、参考情報を紹介いたします。 過去の関連動画 10:50-11:40 「 Deep Dive AWS Graviton パフォーマンス」 講師: Sr Mgr, Solutions Architecture, Arthur Petitpierre, Solutions Architect 石神 靖弘 概要: Graviton で最大の性能を引き出すにはどうしたらよいでしょうか。本セッションでは Graviton のアーキテクチャ詳細に加え、パフォーマンスを最大化し、コストを最小化するためのポイントについて紹介します。 資料 11:40-12:30 「 Karpenter をもちいた Kubernetes 環境でのコンテナ活用最適化」 講師: Sr. Specialist SA, EC2 Graviton, Wayne Toh, コンテナスペシャリストソリューションアーキテクト 落水 恭介 概要: Kubernetes におけるオープンソースの autoscaler である Karpenter を用いることで、x86 だけでなく、arm アーキテクチャである Graviton を組み合わせたマルチアーキテクチャ環境を構築し、最適化されたコンピュート環境を構築することが可能です。本セッションでは、Karpenter やマルチアーキテクチャコンテナイメージを作成するためのデプロイパイプラインについて、デモンストレーションを交えてご紹介します。 資料 まとめ 本セミナーでは、 Amazon EC2 をコスト効率よく活用するために、インスタンスの選び方、 AWS Gravitonの活用、Kubernetes 環境での最適化、そして最新事例のご紹介もしました。 セミナーにご参加いただいた皆様ありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき今後の AWS 活用の参考になりましたら幸いです。

こんにちは。カスタマーソリューションマネージャーの長倉です。 カスタマーソリューションマネージャーとしてお客様の CCoE をご支援する中で、クラウド人材、 IT 人材の育成に関するご相談を多くいただきます。 このブログでは、ビジネス成果を実現する人材育成計画を立案するためのポイントとして、人材育成計画のゴール設定、現状分析の重要性、実際のラーニングパス作成する上で活用できる AWS のプログラムを、一部お客様の事例とともにご紹介していきます。 人材育成のゴールの設定 人材育成において、ゴール設定はきわめて重要です。人材育成計画を立案する際は、知識やスキルの底上げだけを目的とするのではなく、育成した人材によってどのようなビジネス価値を実現したいのかを明確にすることが肝要です。例えば、「内製要員を中心とした体制で次期システムの AWS 上での構築と運用を実現し、ビジネスアジリティ向上を実現する体制を構築する」というゴールを設定し、ゴールを達成するための目標を「 AWS の運用業務をこなせる人材を現在の5名から15名に増やす」「次期システムの設計ができるアーキテクトを10名育成する」と数値を含めた指標として設定することで、具体的な計画の作成が容易となり、ゴールから逆算しての計画立案が可能となります。また、トレーニング完了後も、目的を達成したかの評価が容易となります。 ゴール設定に当たっては、教育のスポンサーとなる経営陣と十分に協議し、合意形成を図る事が重要です。人材育成計画を立案する部門/担当（例えば CCoE ）が、現状の課題を踏まえた人材育成のゴール、それによって実現するビジネス価値について経営陣との合意形成を図ってください。また、ゴールに設定したビジネス価値実現のために育成した人材の実業務やプロジェクトへのアサインが必要となる場合は、計画時点で育成した人材のアサイン計画を経営陣と合意してください。育成した人材を実務にアサインすることで、設定したビジネス価値の実現に初めてつなげる事ができます。 人材育成計画で設定したゴールの達成と学習する文化の醸成には、人材育成への投資やアサイン計画の後押しといった経営陣のバックアップが必要不可欠となります。 現状分析の実施 具体的な計画を立てる前に、人材育成の対象者に対する現状分析を実施し、ゴールとのギャップを特定する必要があります。人材育成対象者の所属部門や役割が異なる場合、習熟度も異なります。個別の状況を考慮した人材育成計画を立てるために現状分析は不可欠です。現状分析の実施にあたって、対象者が少ない場合は有識者によるヒアリングが効果的ですが、対象の人数が多くなるとヒアリングによる把握は困難になるため、アンケートを元にスキルマップを作成する方法が有効です。 AWS では、Web アンケート形式で対象者の AWS に関するスキルや学習状況を収集し、結果をレポートとして提供するツールとして LNA（Learning Needs Analysis） を提供しています。この情報をゴールの検討や組織内のクラウドに関するスキルギャップ特定に活用することができます。教育の定着状況を把握するために、定期的に年次で実施するといった活用も有用です。ご興味のある方は担当の AWS 営業にご相談ください。また、 LNA に関しては AWS ブログ「 LNAによるギャップ分析を活用した効率的なAWSスキル育成計画の立案 」で説明されていますのでぜひご参照ください。 ラーニングパスの設定 設定したゴールと現状分析の結果を元に、どういったギャップがあるかを確認し、それを埋めるラーニングパスを作成します。具体的には、ゴール達成のためにどういったロールの人材が必要になるのか、そのロールにはどういったスキルレベルが必要になるかをブレイクダウンします。ロールと求めるスキルレベルを具体化することで、現状とのギャップがより明確になります。具体化したギャップを埋めるために、どういった研修や学習コンテンツが必要かを検討し、それを組み合わせてラーニングパスを作成していきますが、ロールやスキルレベル別にラーニングパスを検討するのは骨が折れる作業です。 AWS ではロール別/ソリューション別/業種別のラーニングパスを AWS Ramp-Up Guides として公開しています。AWS Ramp-Up Guides では、 AWS Skill Builder のコンテンツや クラスルームトレーニング 、動画やドキュメントを組み合わせ、スキルを習得するためのラーニングパスがまとめられています。それ以外にも、 クラスルームトレーニングのデータシート ではロール別/ソリューション別のスキル習得に必要なクラスルームトレーニング が確認でき、 AWS Skill Builder でも Learning Plan として、ロール別のスキル習得に必要なオンラインコンテンツを活用したラーニングパスがまとめられています。これらの情報を参考にカスタマイズしていくことでラーニングパスを作成ください。 ラーニングパスの作成に加えて、効果的な学習を実施するためには、学習時間の確保/チームとして学びを進める体制/学習のためのコンテンツの用意/学習の途中経過の確認とフィードバック といった点に留意する必要があります。以下で留意いただきたいポイントをご紹介します。 業務時間中に学習時間を確保する 学習のための時間を自主的に確保するのは難しく、また、育成対象者のスキルレベルや学習意欲の違いにより、コンテンツのみを用意して実施を自主性に任せた形式とすると、進捗や習熟度にばらつきが出てしまいます。人材育成のゴールを達成するため、組織全体として人材育成を支援している姿勢を明確に示すためにも、人材育成計画をリードする部門が主体となり、経営層に対して業務時間内に一定の学習時間を確保するよう調整してください。 一緒に学んでいくチーム/コミュニティを作る IPAによる デジタル時代のスキル変革などに関する調査（2022年度）全体報告書 の中で、 IT 人材の学びを阻む障壁として、「共に学ぶ仲間や相談相手がいないために挫折してしまう」という課題が挙げられています。学習時に相談できる仲間がいる事によって、モチベーションを維持して継続的な学習の実施が期待できるだけでなく、学習した内容をアウトプットする機会を持つ事につながり、知識の定着・学習効率のアップが期待できます。また、一緒に学ぶチーム/コミュニティを組成し、その中に講師やメンターを設定することで、習熟度に応じた学び合いが実現できます。育成対象者に加えてメンターや講師をアサインするのが難しい場合もあると思いますが、あるお客様の事例で、学びの各テーマごとに人材育成の対象者どうしで講師を分担するという取り組みをされていました。自分が講師となった領域についてはみなさん積極的に学習されたそうです。その結果、入社歴2,3年の若いメンバーが特定のテーマに詳しくなり、ベテラン社員が若いメンバーの詳しいテーマについて、日常的に質問するようになったそうです。一緒に学んでいくチーム/コミュニティを作ることで、効率的で継続的な学習の実現に加えて、組織全体で人材育成に取り組む文化の醸成につなげる事が期待できますのでぜひご検討ください。 学習のためのコンテンツの用意 人によって最適な学習環境は異なります。効果的な人材育成のためには多様なコンテンツ、学習者の特徴に合わせた環境を用意する事が重要です。知識を体系的に学ぶ学び方を好む方もいれば、手を動かして学びたいという方もいるでしょう。学習者に合わせた様々な学習機会提供の重要性については「 日本におけるデジタル人材育成の現状と推進する上での勘所（後編） 」でも詳しく紹介しているので、ぜひご参照ください。 AWS では学習者の特徴にあわせることが可能な、多様なコンテンツ、トレーニングを用意しています。 クラスルームトレーニング では、短期集中で集合研修形式による AWS の学習が可能です。会社ごとで実施するプライベートトレーニングも提供しておりますので、ご興味のある方は担当の AWS 営業にご相談ください。また、 AWS Skill Builder ではオンラインのコンテンツを提供しており、学習者が自由な時間に好きなコンテンツを選んで学習が可能です。座学でのデジタルトレーニングに加えて、学習者が楽しんで学べる「 AWS Cloud Quest 」「 AWS Industry Quest 」といったゲームベースで学習ができるコンテンツや、演習用の AWS アカウントが払い出され、 AWS サービスに触れてみることができるハンズオンラボである AWS Builder Labs 、個人またはチーム単位で発生する様々な課題（セキュリティ、インフラ、 DevOps 、 ML 、サーバレスなど）を解決してスコアを競う実践的な演習の「 AWS Jam 」といったコンテンツがあります。「 AWS Jam 」は、チーム対抗で課題解決を目指す「 AWS Jam イベント」と、個人で解決を目指す「 AWS Jam Journey 」が用意されており、実際の AWS 環境で発生する障害や課題の解決に取り組んでいくコンテンツとなっています。詳細な説明や、解決策が提示されない中、個人・チームで試行錯誤しながら課題を解決していきます。課題には難易度ごとにスコアが設定されており、スコアを競いながら実際の業務で発生する障害対応や、各種課題の解決を手を動かしながら体験できる事で、実践力を強化するとともに、 AWS スキルの可視化が可能となります。同様のコンテンツとして、「AWS Jam」がクラスルームトレーニングの一環としても提供されております。ご興味のある方は クラスルームトレーニングのデータシート から全コースのデータシートをダウンロードすることでご確認いただけますので、ぜひご確認ください。 演習の実施が難しい場合は、メンターの十分なフォローの元、実務の実施を人材育成計画に組み込むのも効果的です。学習者に合った多様な学習コンテンツの提供とチームで学ぶ機会を適切に組み合わせていくことが、人材育成の成功につながります。 学習の途中経過の確認とフィードバック 人材育成の進捗と効果を測るために、第三者が客観的に評価できる基準を設定することが重要です。学習過程で定期的に理解度やスキル習得度を確認していき、基準を満たしていない場合は計画を見直し、目標達成に向けた改善を図ります。評価基準の例として、認定資格の取得や有識者によるスキルレベルのチェックが挙げられます。 AWSでは 認定資格/認定試験 を用意しています。認定資格の取得をラーニングパスに組み込む事で、人材育成の進捗を測れるようになるだけでなく、社内のクラウド知識とスキルの見える化を実現できます。また、認定資格/認定試験の内容は定期的にアップデートされるため、テクノロジーの進化へも対応が可能となるため、活用をご検討ください。 業務へのアサイン/経営陣との合意 ラーニングパスに基づいた学習の完了後、計画段階で合意した育成した人材の実案件やプロジェクトへのアサインを実施してください。人材育成が計画通りに進まなかったり、プロジェクトが予定通りに始まらないといったケースもあると思います。こういったケースで育成した人材のスキルが活かされない状況が発生しないように、学習の途中経過とあわせて、定期的に経営陣と人材育成の状況を報告・共有し、実案件へのアサイン計画についても状況に変化に対応できるよう調整を続けてください。人材育成をビジネス価値の向上につなげている事例として、 オムロンソフトウェア様のクラウド人財育成の取り組み があります。オムロンソフトウェア様では、トレーニングで獲得した知識をすぐに試せるように、事業部の壁を超えてクラウド案件に人財をアサインされています。スキルを高めるためのサポートは、独自の能力開発制度体系を用意し、職種別に必要な知識・スキルの習得を可能にする支援を行っており、特に重視されているのが、実践をとおして現場で使える技術を早期に身に付ける事と考えておられます。その他のお客様によるトレーニング実施の事例も、 お客様インタビュー – クラウド人材育成 でご確認いただけますのでぜひご参照ください。 学習する文化の醸成 継続して学習を実施していくため、学びによって得られた成果を業務評価につなげる事が大切です。評価につながる事により、各自の学習意欲が高まるという好循環につながります。ただし、その実現は簡単ではありません。人材育成計画検討部門（人事部や CCoE ）が中心となり、人材育成の計画段階から、経営陣と密に連携を取りながら、学習によって発揮できる成果とその評価方法を明確化することが重要です。 学習の成果が適正に評価されることで、自律的なスキルアップの文化が生まれます。組織全体で学びを推進するための仕組みづくり（例えば人材育成の成功体験を共有会やイントラネットを活用して社内で共有）ができれば、自律的にスキルアップしていく文化を組織として醸成できるようになります。 現場主導での学習 ここまで、人材育成のゴールを設定し、教育の成果としてビジネスバリューを発揮するために経営陣と合意して実際の業務にアサインすることの重要性をご紹介させていただきました。一方で、経営陣と合意して大規模に教育を推進するのは難しいが、現場の取り組みとして教育を推進していく必要がある、というケースもあると思います。こういったケースでも、人材育成のゴールを設定し、現状分析を行ったうえでラーニングパスを設定するというプロセスは同様に有効です。ゴールの設定や、現状分析、ラーニングパスの設定は社内の有識者や既にスキルを保有している方の歩んできた道のりを参考としたうえで検討してください。また、学習にあたっては、チーム単位で勉強会を開催し、先に紹介させていただいたように相互に講師を務めるといった取り組みを実施し、各人が積極的に参加できる仕組みをぜひご検討ください。 まとめ 人材育成計画を実現するうえでのゴール設定と学習していくための仕組みづくりの重要性についてご理解いただけたと思います。経営層を含む関係者とゴールを共有し、現状とのギャップを洗い出すことができれば、そのギャップを埋める手段としてのコンテンツは AWS から多数提供されていますので積極的に活用ください。 IT 技術、特にクラウドサービスの技術の進歩は早いため、最新の動向を把握し、より効果的にクラウドを活用してビジネス価値を最大化するには、計画した期間の学習が終わったら完了ではなく、継続して学び続ける必要があります。継続して学び続けるための仕組みづくりを人材育成計画検討部門が推進していってください。 参考リンク LNA(Learning Needs Analysis) LNAによるギャップ分析を活用した効率的なAWSスキル育成計画の立案 AWS Ramp-up Guides AWS Skill Builder クラスルームトレーニング クラスルームトレーニングのデータシート Learning Plan デジタル時代のスキル変革などに関する調査（2022年度）全体報告書 日本におけるデジタル人材育成の現状と推進する上での勘所（後編）AWSトレーニングデータシート AWS Cloud Quest AWS Industry Quest AWS Jam AWS 認定 オムロン ソフトウェア株式会社：グループのデジタル戦略実現に向けて AWS 人財を育成。半年間のトレーニングで 7 名が AWS 認定 5 冠を取得 お客様インタビュー – クラウド人材育成 今から始める CCoE、3 つの環境条件と 3 つの心構えとは CCoEブログ 著者 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネジャー 長倉隆浩

イントロダクション 今日のデジタル時代において、クラウドへの移行は「なぜやるのか」ではなく、「いつやるのか」というトピックになりました。インフラコストの削減以外にも、クラウドには柔軟性、機動性、信頼性の向上など多くの利点があります。しかし、クラウド移行には多くの利点がある一方で、進捗を妨げる予期せぬ費用が発生する可能性もあります。移行コストは、組織の規模、アプリケーションの複雑さ、移行プロセスの期間によって大きく異なります。さらに、現在の経済状況下では、限られたIT予算と効率性の必要性がクラウド移行の取り組みをさらに複雑にしています。 このブログでは、大規模な企業のクラウド移行におけるコスト削減戦略について考えていきます。 クラウド移行を開始する前に クラウド移行を成功させるためには、組織全体の利害関係者を結集させるビジネスドライバーを特定することが不可欠です。これには、移行プロジェクトの範囲、利点、およびタイムラインを概説したデータドリブンなビジネスケースを作成する必要があります。移行タイムラインをデータセンター退去などの具体的なビジネス成果と合わせることで、進捗状況を評価する具体的な基準が得られます。 AWS Migration Evaluator などのツールを活用して、コスト効率の良い移行のための説得力のあるビジネスケースを作成してください。 クラウド移行の複雑さに立ち向かうことは大変な作業ですが、適切なパートナーがそばにいれば、その旅路は容易で報われるものになります。AWSは、顧客の移行コストを軽減するために、 AWS Migration Acceleration Program (MAP)を提供しています。AWS MAPは、ツール、ベストプラクティス、 AWS パートナーネットワーク (APN)へのアクセス、および移行への投資を提供します。プログラムの早期段階からAWSに相談することで、クラウドマイグレーションジャーニーの各ステップを確認し、最適化されたアプローチを確保することができます。 MAPでは、移行に3ステップのアプローチ(図1参照)を推奨しています。Assess(評価)、Mobilize(準備)、Migrate &amp; Modernaize (移行とモダナイズ）です。 図1 – AWS MAPの3ステップアプローチ 評価フェーズ このフェーズの目標は、クラウドで運用する組織の準備状況を評価することです。 現在のオンプレミスのIT資産（Assets）を理解することは、移行作業とクラウドコストを見積もるために不可欠です。移行を検討する際に組織が直面する一般的な問題の1つが「ダブルバブルコスト」であることを覚えておいてください。このバブルは、組織が現在のオンプレミスインフラの費用を負担しながら、新しくクラウド移行のコストが発生することで形成されます。 インフラストラクチャの組み合わせに基づいて適切なディスカバリーツールを選択するには、 AWS規範的ガイダンス を参照してください。ディスカバリーには、移行計画時に見落とされがちな、サードパーティのライセンスコストの評価を含める必要があります。AWS MAPには、ライセンスコストを理解するための実証済みのフレームワーク「 Optimization and Licensing Assessment (OLA)」が含まれており(図2参照)、クラウドネイティブで費用対効果の高い代替案を提供します。多くのAWSの顧客がOLAを活用することで、大幅なコスト削減を実現しています。この包括的な発見は、（１）コミットメント支出に基づいた割引価格を提供するAWSホスティングプラン(Savings plansとリザーブドインスタンス)の選択、(２)移行の加速と「ダブルバブルコスト」の削減のための移行計画に役立ちます。 古い機器の保守コストを削減することで、ダブルバブルコストを軽減する別の選択肢は、ReluTechなどのAWSパートナーが提供するIT売却のアプローチです。このアプローチには、ITメンテナンスの外部委託、高額なITリフレッシュの回避、オンプレミスアセットの購入とリースバックなどのコスト削減戦略が組み込まれており、顧客がクラウドへの移行を迅速かつ費用対効果の高い方法で行えるようサポートします。 &nbsp; 図2 – ライセンス: 移行コスト削減の大きな要因 次のステップは、クラウドへの移行と運用の準備状況を評価することです。 AWS Migration Readiness Assessment (MRA) は、ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、運用の6つの AWS Cloud Adoption Framework (CAF) の柱に沿って組織を評価する無料のワークショップです。MRAの出力には、特定された課題に対処するための計画と、 AWS Learning Needs Analysis (LNA) などの追加ワークショップの推奨事項が含まれます。LNAはAWSスキルの準備状況を評価し、カスタマイズされた学習計画を推奨します。AWS Immersion Daysは、移行イニシアチブに参加する従業員にクラウドサービスのハンズオントレーニングを提供します。 詳細なポートフォリオの発見、ホスティング計画、およびMRAの出力により、プログラムはモビライズフェーズに移行する準備ができます。 モビライズフェーズ このフェーズの目標は、移行のためのベースラインとなるクラウド環境を構築し、再現可能な移行パターンを持ったアプリケーションの移行戦略を策定することです。 これには、（１）クロスファンクショナルチームであるCCoE(Cloud Center of Excellence)を設立し、クラウド移行におけるガバナンスとベストプラクティスを標準化する。（２）適切に設計された基礎となるクラウド環境(ランディングゾーン)を構築する。（３）評価フェーズで実施したMRAから特定されたギャップに対処する ことが含まれます。 組織はこの段階で、初期のワークロードの選択と移行の順序付け、移行戦略の曖昧さ、セキュリティとコンプライアンスのフレームワーク、有識者や専門家の有無など、潜在的な障害に気づく必要があります。これらの懸念に早期に対処することで、分析の停滞を防ぎ、移行の期限を守ることができます。 AWS Experience Based Acceleration (EBA)は、アジャイルでハンズオンのアプローチで、摩擦点と障害を解決することを目指しています。EBAでは、お客様の主要な意思決定者とAWSの専門家が集中的なワークショップ環境に集まり、「実際にやってみて証明する（do it to prove it approach）」アプローチで障害を解決するのを支援します。プラットフォームEBAと移行EBAを組み合わせると、モビライズフェーズの目標を達成するのに最適です。プラットフォームEBAでは適切に設計されたランディングゾーンを作成し、移行EBAではいくつかのアプリケーションを素早く移行してランディングゾーンをテストします。CCoEは引き続きガードレールを見直し、繰り返し可能なパターンを確立し、コスト最適化の管理を実装します。 社員の余力や専門知識が限られている場合は、AWS MAP パートナー資金調達プロセスを活用して、適切に設計されたランディングゾーンと繰り返し可能な移行アプローチの構築に関連するコストを、AWS Professional Services またはAWSパートナーを起用して補填することができます。 この段階で最も重要な活動の1つが移行のwaveの計画です。事前に移行のwaveを計画しておくと、チームが移行プロセスに慣れるにつれ、プロジェクトがスムーズに進むようになります。 適切に設計されたランディングゾーン、テスト済みの移行アプローチ、移行のwaveの計画ができれば、移行を加速させる時が来ます！ 移行フェーズ このフェーズの目標は、ダブルバブルコストを抑え、ビジネスケースで概説されているクラウド導入の利点を実現するために、ワークロードをクラウドに迅速に移行することです。 AWS Cloud Migration Factory は、ワークロードをAWSに大規模に移行するための移行ガバナンスと自動化レイヤーです。Maydenは、AWS Cloud Migration Factoryを活用して、6週間でAWSに300台のサーバーを移行しました。 AWS Application Migration Service や AWS Database Migration Service (DMS)などのAWSツールを活用して、ビジネス運用を中断することなく移行を迅速化し、コストを削減します。これらのツールは幅広いアプリケーションをサポートしており、追加の投資は必要ありません。また、段階的な価格設定オプションが用意されています。 最初は小さく始め、その後の各waveで移行の速度を上げていくことを計画します。最初のwaveでは、単一のアプリケーションまたは依存関係の少ないアプリケーションから始めます。複雑なアプリケーションは後続のwaveに加えることで、チームが学習し調整する時間を確保できます。さらに、チームはプロセスの改善を特定し実施して、後続のwaveの速度を上げることができます。 移行が進行中は、AWS Cost Optimization の専門家と定期的に打ち合わせを行い、コスト削減の機会を確認することが重要です。 また、この時点で次の大きなステップである「モダナイゼーション」を開始することも重要です。 移行とモダナイゼーションの両方が、継続的なコスト最適化と、クラウドの利点を完全に実現するためのキーです。(図3参照)。 図3 – マイグレーションとモダナイゼーションは、クラウドの恩恵を完全に実現するために重要 まとめ 企業のクラウド移行を主導することは難しい課題ですが、実証されているコスト削減戦略を活用することで、成功の可能性を最大化できます。 このブログで参照されているAWSクラウドサービスの詳細については、以下のリンクを参照してください。 ・ Cloud Migrations Services on AWS ・ AWS Migration Evaluator ・ AWS Migration Acceleration Planning (MAP) ・ AWS Migration Readiness Assessment (MRA) ・ AWS Optimization and Licensing Assessment (OLA) ・ AWS Learning Needs Analysis (LNA) ・ AWS Cloud Adoption Framework (CAF) ・ AWS Experience Based Acceleration (EBA) ・ AWS Application Migration Service ・ AWS Prescriptive Guidance Strategy and best practices for AWS large migrations 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。 著者について Sai S Jeedigunta Sai S Jeedigunta Sai Jeediguntaは、AWSのシニアカスタマーソリューションマネージャーです。クラウド変革の取り組みを推進し、クラウドの恩恵を実現するために、経営陣や部門横断的なチームとパートナーシップを組むことに情熱を注いでいます。20年以上にわたり、大手企業向けのIT インフラストラクチャ関連の業務を主導してきました。 Joe Rader Joe Rader Joe RaderはAWSのシニアカスタマーソリューションマネージャーで、2020年から在職しています。Joeは、お客様がクラウドで成功を収められるよう支援し、長期的な成功に焦点を当て、常にコスト削減を意識しています。Joeには30年以上のIT経験があります。

強烈なインパクトを残したイベント Amazon Web Services (AWS) re:Invent 2023 を振り返ってみると、今年の会議がネバダ州ラスベガスで開催されたことは、自動車および製造業界にとっては特に革新と先進思考の中心であったことが明らかです。このダイジェストでは、イベント中に発表された豊富な情報と発表を詳細に確認しつつ、特に自動車産業を前進させることができるコンテンツについて整理しています。 AWS の自動車および製造業界ビジネスユニット (IBU) チームの洞察に富んだブレイクアウトセッションから、ワークショップやチョークトークで実証された実用的なアプリケーションに至るまで、 re:Invent 2023 で提供されたリソースは、自動車分野の進化する課題に対処するためのものです。このダイジェストは、業界が安全で持続可能でお客様中心のモビリティの未来に向かって加速するために、変革のナビゲートについて考え、今後お客様にとっての優れたモビリティ体験を保証します。 AWS では、独自のコラボレーションとイノベーションを通じて、持続可能で安全なモビリティ、製品、サービス、ソリューションの提供を加速し、お客様が変革の課題を解決するのを支援することに尽力しています。 AWS 内の自動車および製造業界ビジネスユニット (IBU) は、複数の大手 OEM 、 Tier1 、お客様、パートナーと協力し、 8 つの戦略的ワークロードに焦点を当てています。このブログ投稿では、 re:Invent で発表された自動車および製造業界に関連する発表を 8 つの戦略的ワークロードに分けて紹介しています。各セクションの中で re:Invent セッションで録画があった場合はそのリンクを記しています。 ソフトウェア定義車両 (SDV) ソフトウェア定義車両 (SDV) の分野は、車両のソフトウェアを再構築し新しいモビリティソリューションに不可欠なサービスへのアクセス、理解、使用、更新を改善するユースケースに触れています。 AWS の次世代クラウドファーストのインテリジェントなコードパイプラインに対するビジョンを概観する AUT102 ブレイクアウトセッションでは、 Traton と Volvo が製品化までの時間を短縮し、車両からクラウドへの連続性を維持することで開発コストを削減している方法について学ぶことができました。この連続性は、異なるコンテキストに車両の機能を分割し、開発ワークフロー内で Amazon Elastic Cloud Compute (Amazon EC2) インスタンス用の BlackBerry QNX AMI を利用しています。これらの革新により、チームはバグを早期に特定し、コード品質を向上させ、ハードウェア・イン・ザ・ループ (HIL) システムへの依存を減らすことができます。これは業界におけるシフトレフトアプローチへの証です。 チョークトークセッション AUT203 では、クラウドネイティブなツールと仮想化されたターゲットを使用した加速とスケールアップについて、車両へのデプロイ前にクラウドでコードを構築しテストするための、 SDV アーキテクチャ向けの最新クラウドネイティブ革新が紹介されました。ディスカッションの焦点は、仮想エンジニアリングワークベンチ、仮想電子制御ユニット、 CI/CD パイプラインであり、 Amazon CodeWhisperer を使用した生成型人工知能（生成 AI ）が生産性向上にどのように役立てられるかを示すユースケースについて深く掘り下げました。オリジナル機器メーカー (OEM) と様々な階層のサプライヤーは、 SDV の現在の採用状況を議論し、チョークトーク中に今後の取り組みを概説しました。 AUT301 ワークショップ 「 Automotive software development with Virtual Engineering Workbench (VEW) 」には、 100 人以上の開発者とアーキテクトが参加しました。このワークショップでは、 AWS 上で車載グレード評価機能を構築しテストする方法を実演しました。参加者が事前に設定された AUTOSAR ＆QNX ランタイム環境を作成し、 AWS Service Catalog に公開しました。 VEW セルフサービスポータルから、ユーザーは事前に設定された AUTOSAR ＆ QNX 環境を選択し、ログインしてデモ車両機能アプリケーションを開発しました。参加者はその後、仮想ターゲット（仮想 ECU ）上で車両アプリケーションを統合・実行し、 Amazon EC2 インスタンス上で機能を検証しテストしました。さらに、 VEW のエンドツーエンドのビジョンについて議論し、 OEM の特定の要件とワークフローに合わせて拡張・カスタマイズする方法を提供しました。 ライトニングトーク AUT103 「 Accelerate automotive cockpit development with Panasonic SkipGen on AWS 」では、 Panasonic SkipGen on AWS Graviton が自動車コックピットドメインコントローラーの開発を革命的に進化させる方法について深掘りしました。これにより SkipGen は業界に変革をもたらし、 AWS 上で完全な現代のコックピットソフトウェア開発、コンピューティングオフロードおよび 大規模なテストを可能にしました。 AWS は、クラウドネイティブな Software Developer Workbench がどのように拡張し、 SDV 時代の車両ソフトウェア開発を加速しているかについてのデモを示しました。自動車業界のパビリオンでの体験では、 BMW i7 車両の開発に関する情報を含む 8 つのデモを AWS が展示しました。 自動運転モビリティ 自動運転モビリティ分野では、 AWS は Amazon が長年にわたり自律システム、ロボティクス、機械学習において蓄積した経験を活用し、自動運転車の開発を加速していることについて触れました。 ブレイクアウトセッション AUT202 では、 BMW が Qualcomm と協力してクラウド上で次世代の高度自動運転開発プラットフォームを開発する方法についての事例が講演されました。 ブレイクアウトセッション AUT206 では、 Torc Robotics が AWS 上でデジタルテストプラットフォームを作成し、シミュレーションで何百万マイルものテストを実行し、レベル 4 の自動運転機能のテストカバレッジを最大化する方法について掘り下げられました。このセッションでは、 AWS の管理サービスを使用してプラットフォームを設定する方法について話されました。講演者は、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Simple Storage Service (Amazon S3) を使用してプラットフォームを設定する方法、直面した技術的な課題、学んだ教訓、および実装されたソリューションの結果としての利点について詳しく説明しました。 次世代トラッキングに関するブレイクアウトセッション PRO301 では、「 Iveco が AWS を使用して自動運転のための生成 AI を活用し、安全性と効率性の新たな高みを実現する方法」について紹介しました。このビジョンを実現するため、 Iveco は AWS 上で構築された生成 AI 技術を利用して、ドライバーと車両の関係を再定義しています。 AWS プロフェッショナルサービスの協力のもと、 Iveco はプライバシーに準拠したフリートデータにカスタマイズされた生成モデルをトレーニングし、ドライバー体験を向上させています。 チョークトークセッション AUT302 では、自動運転開発における生成 AI と 自然言語処理 (NLP) に基づくシーン検索に焦点を当てました。このディスカッションでは、自動運転機能の開発において直面する最も重要な課題について詳しく議論しました。ペタバイト規模のデータから、トレーニングやテストに関連するシーンを特定するために、生成 AI を使用する方法についてのインサイトが説明されました。またこのチョークトークでは、参加者は生成 AI がシーン選択を加速し、低頻度なイベントや意味的に類似したシーンを特定する方法を学びました。これらは、 ML トレーニング、テスト、検証などの下流タスクで使用されます。 ビルダーセッション AUT303 では、 ADDF ソリューションにおいて、モデルトレーニングのためのシナリオ内にオブジェクトを追加するために生成AIを使用しました。自動車メーカーは通常、自動運転や高度自動運転機能の開発のために車両テストフリートから何百ペタバイトものドライブデータを収集しますが、 ML エンジニアがコーナーケースに対してモデルをトレーニングするために必要になる正確なシナリオを記録していないことがあります。このビルダーセッションでは、生成 AI を使用して、停止標識などのイメージやオブジェクトを既存のシーンに追加する方法を実演しました。 デモブースでは、 お客様がクラウドで高度に自動化された運転機能を開発する際にサポートするための様々なツールを展示しました。他にもデータの取り込み、データの前処理、シーン生成、シーン検索、大規模な再シミュレーションのサポートに使用される AWS サービスが紹介されました。 接続モビリティ 接続モビリティ分野では、 AWS のお客様は、データの力を活用して、インテリジェントでパーソナライズされた機能や収益を生み出すモビリティサービスを構築しています。 AWS IoT FleetWise チームは、車両ビジョンシステムデータの収集をサポートすることを 発表 し、お客様がカメラ、 LiDAR 、 Radar などのビジョンサブシステムからメタデータ、オブジェクトリストと検出データ、画像やビデオを収集できるようにしました。 特に好評だったブレイクアウトセッション ALX201 は、車内ボイスエクスペリエンスをコンセプトから現実に変えることに焦点を当てました。参加者は、 BMW が独自の次世代 AI ボイスアシスタントを構築し、車内ボイスエクスペリエンスを新たな高みに引き上げる方法を学びました。インターネット接続に関係なく、埋め込み型ニューラルテキストトゥスピーチ SDK を展開することで、 BMW のクラウド環境を強化し、お客様に途切れのない自然なボイスエクスペリエンスを提供したことについて学びました。 別のブレイクアウトセッション IOT 204 では、 AWS IoT Connected Vehicle (CV) プラットフォームを使用した接続車両プラットフォームの革新と近代化について掘り下げました。このセッションでは、 AI による保証と修理通知、ライブビデオストリーミングと再生、 EV バッテリーの健康監視などの革新的なアプリケーションの可能性を強調しました。 American Honda Motor Company は、 AWS IoT Core への移行についてを共有し将来の革新に向けた計画を概説しました。 ANT 317 セッション「電気自動車からのリアルタイムアナリティクス構築」では、 Rivian が AWS 上での接続モビリティユースケースを共有しました。 Rivian の車両データプラットフォームは、デジタルコマース、保険、先進運転支援システム、車両の信頼性、スマート診断、充電、車両サービスなど、様々なドメインをサポートする基盤サービスとして機能しています。 ブレイクアウトセッション IOT 309 「 AWS IoT Core を使用してアプリケーションを革新する – MQTT 5 」では、 MQTT 5 の概要を説明した後、接続された車両のユースケースを探求しました。参加者は、 MQTT のパブリッシュおよびサブスクライブメッセージ機能を使用して、潜在的に断続的なネットワーク接続で通信する方法を学びました。またライブデモでは、共有サブスクリプションを使用してフリートとアプリケーションをスケールする方法を紹介しました。 デモエリアでは AWS Connected Mobility Solution 2.0 (CMS) を展示しており、大規模な接続モビリティインフラの開発、展開、管理がどのように容易になるかについて触れていました。 デジタルカスタマーエンゲージメント デジタルカスタマーエンゲージメント (DCE) の分野では、 AWS はお客様がパーソナライズされたマーケティングコンテンツ、没入型デジタル体験、リアルタイムデータ分析を通じてお客様エンゲージメントを増加させるのを支援しています。これには、広告、ファイナンス、アフターサービス、リピート購入体験など、所有のライフサイクル全体とお客様の旅にわたる様々な側面が含まれます。 AIM 206 ブレイクアウトセッション「 Generative AI で価値とビジネス成果を実現する」では、 AI と人間の心の融合、技術進歩によって駆動される急激なイノベーションについて発表しました。このセッションでは、 Ferrari が DXC Technology と AWS と共に生成 AI を探求している方法、生成 AI の導入における主な障害、メインストリームの導入に焦点を当てるべき分野、内部および外部の消費者の両方に対する価値ストリームマッピングを構築する方法を学びました。 チョークトークセッション AUT 204 「 Generative AI で未来へと進む」では、 AWS Generative AI Innovation Center の専門家によって提示されたように、 Amazon Bedrock と Amazon CodeWhisperer がプレセールスからポストセールスまでのお客様旅行全体のデジタル体験を強化するためにどのように採用されているかについて議論しました。 デモエリアでは、コールセンターから予測保守に至るまで生成 AI がデジタルお客様体験をどのように強化しているかが披露されました。 製造 製造 業界では、 AWS はショップフロアからのデータをキャプチャ、分析、視覚化することにより、製造業務と全体的な設備効率を最適化しています。 AIM 216 ブレイクアウトセッション「大規模な予測保守」では、 Amazon Monitron を用いた Koch Ag &amp; Energy Solutions (KAES) のジャーニーが共有されました。予期しない機器の故障は産業施設にとってコストがかかる一方、保守を頻繁にスケジュールすることは資源の無駄遣いです。このセッションでは、 Koch AG から、彼らが Amazon Monitron を活用して産業用機械に予測保守を実装する方法について聞くことができました。 チョークトークセッション AIM240 「 Amazon Q で従業員に生成 AI の力を提供する」では、 Amazon Q が従業員に生成 AI の力への安全かつ迅速なアクセスを提供する方法を実演しました。 Amazon Q は自然言語を理解し、接続されたデータソースを使用して文脈に沿った回答を提供し、ドキュメントを要約し、コンテンツを生成し、企業アプリケーションやドキュメントリポジトリ全体でアクションを自動化することができます。これはショップフロアアプリケーションでの作業者ガイダンスの実装に特に有用です。 サプライチェーン AWS は、 re:Invent 2022 で AWS Supply Chain サービスを発表しました。このサービスは、機械学習 (ML) を活用したサプライチェーンアプリケーションによりリスクを軽減し、コストを削減します。お客様は、生産プロセス全体を追跡し追跡するために必要なエンドツーエンドのサプライチェーンの可視性を得ることができ、前例のない効率性を実現します。 AUT207-INT インダストリアルイノベーションセッションでは、自動車、航空宇宙、消費者電子機器を含むさまざまな産業分野のクラウドインダストリアル企業が、ビジネスを再創造し、運用を最適化し、市場投入までの時間を短縮し、新しい収益ストリームを生成するために、データとクラウドテクノロジーをどのように活用しているかが紹介されました。 Siemens 社は、 AWS を活用した Xcelerator インダストリアルソフトウェアポートフォリオや新しい工場自動化の提供を行い、 Industrial Metaverse 内で仮想工場を構築した方法について発表しました。 Honda は、日本と北米で AWS との協業について議論しつつ製品開発、サプライチェーン、製造全体での革新を加速する計画を語りました。 製品エンジニアリング AWS は、製品開発者やエンジニアが AWS 上の ハイパフォーマンスコンピューティング (HPC) 、モデルベースの設計、大規模並列シミュレーションを使用して複雑な問題を解決することを支援しています。 MFG 106 ブレイクアウトセッションでは、 トヨタモーターノースアメリカ と Autodesk の登壇者が、人工知能がどのように計算集約的なシミュレーションとモデリングを迅速化し、製品設計とデジタルエンジニアリングを加速させ、最終的に市場投入までの時間を短縮するかについて議論しました。 持続可能性と EV （電気自動車） 電気自動車 (EV) では、バッテリーが持続可能性とコストにおける最大の要因です。チョークトークセッション AUT 201 「バッテリーデジタルツインの力を解き放つ」では、物理的なバッテリーシステムの仮想表現であるバッテリーデジタルツインモデルが紹介されました。このセッションでは、 Mahindra と Our Next Energy がリアルタイムの車両バッテリーデータを機械学習アルゴリズムやデータ分析と組み合わせて、バッテリー性能の最適化、バッテリー寿命の延長、故障の検出、安全性の向上を図る方法を追求しました。 ワークショップ IOT 305 「 AWS IoT を使用した EV バッテリーの異常検出」では、電気自動車 (EV) バッテリーの異常を早期に検出するソリューションがデモンストレーションされ、参加者は車両のフリートの管理、プロビジョニング認証、車両モデリング、キャンペーン作成、データの取り込み、および洞察のためのダッシュボードの設定において実践的体験ができました。 デモエリアでは、 お客様が AWS 上で高度にスケーラブルで低遅延の OCPP EV 充電 CPO ソリューション を構築するのに AWS のサービスがどのように使用されているかを示しました。別のデモでは、 AWS がバッテリーサーキュラーエコノミー内のステークホルダー間の透明性と信頼性にどのように貢献しているかを示しました。さらに、 AWS はバッテリーデジタルツインを使用してバッテリー性能の最適化、バッテリー寿命の延長、 EV 効率の向上を実現する方法をデモンストレーションしました。 結論 AWS は、 re:Invent 2023 で 8 つの戦略的ワークロード領域における革新とお客様の成功事例を発表しました。 AWS は、中国リージョンで展開する OEM （オリジナル機器メーカー）にとってのプリファードクラウドプロバイダーとなり、対象として SAIC や BYD を含むといった発表がありました。 AWS for Automotive チームは、お客様と共に、またお客様のために革新を続けています。他の re:Invent 2023 の発表 に最新の情報については、 AWS for Automotive のページを探索するか、今すぐ担当の AWS チームにご 連絡 ください。 このブログは「 Recap of AWS re:Invent 2023 for the Automotive Industry 」と題された記事の翻訳となります。 翻訳は Solutions Architect Leader のショーン・セーヒーと Solutions Architect の佐藤高士が担当しました。

現代の車は単なる交通手段を超えて、つながったモノのインターネット (IoT) デバイスに進化しており、従来の車における所有と使用のあり方を再定義しています。 このビジョンの変化は、移動に関連する課題の解決方法を変えています。自動車産業は、スマート充電、バッテリーの状態監視、予知保全、フリート管理、循環型経 済などの課題に対処するために、人工知能 (AI) による「デジタルツイン」を活用しています。 デジタルツインとは、物理的なシステムを仮想的に表現することであり、データを動的に更新して物理システムの構造、状態、振る舞いを模擬します。 Amazon Web Services (AWS) は、デジタルツインの使用事例の幅広さを考慮して、顧客が使用事例を分類しデジタルツインを大規模に構築および展開するために必要なサービス、技術、データ、モデルを理解するのを支援するために、 4-level index を提案しています。 2022 年、Management- und IT-Beratung GmbH ( MHP ) は AWS との戦略的協業契約 を発表し、モビリティと製造業におけるクラウドの変革をさらに支援することになりました。MHP は、モビリティと製造環境における長年の専門知識をもつ AWS のアドバンスドティアサービスパートナー であり、クラウド戦略、アーキテクチャ、開発、移行、運用の課題に焦点を当てて協力しています。 この記事では、MHP が AWS と協力して電気自動車のレベル 4 デジタルツインを構築し展開する取り組みをご紹介します。具体的にはライブデータ、フリートの知識、AI を活用して電気自動車 (EV) のバッテリーを監視および分析する手段についてです。 フリートからドライバーの振る舞い（ドライバーツイン）とバッテリーの特性（バッテリーツイン）を学ぶことによってバッテリーの健康状態とパフォーマンスの管理を行う事例をご紹介します。また、業界における課題についても触れ、AWS 上で構築および展開された技術的なソリューションとリファレンスアーキテクチャについて深掘りします。 電気自動車のバッテリーに関する課題 電気自動車のバッテリーの管理と最適化は、バッテリー製造業者、自動車メーカー (OEM) 、および利用者の全てにとって重要です。 電気自動車のバッテリーに関して、最適な長期健康状態と残存価値に向けてどのように充電するかの最適解を導き出すのは難しいです。なぜなら、それぞれの電気自動車は異なる環境条件や使用パターンに晒されているからです。 結果として、各バッテリーそれぞれの具体的なサービス履歴に基づいて個別に運用性能を計算する必要があります。バッテリーの状態 (SoH) や充電状態 (SoC) などの特性をモニタリングし予測することで、航続距離の懸念や予知保全、残存価値、および再利用などの課題に対処できます。 現在、バッテリーのこれらのパラメータを計算するために開発された物理ベースのモデルには、2 つの主な問題があります。精度が低いことと、計算コストが高いということです。これらのモデルは、ドライバーの振る舞いなどの重要な要素を過度に単純化（または無視）するか、逆に詳細なバッテリー電気化学を数値的に解くことを試みて過度に複雑化してしまっていることが課題です。 物理ベースとデータドリブンのハイブリットアプローチを使用したデジタルツインによって、現実世界の要素の影響を考慮しながら、リアルタイムに実行可能な運用モデルを作成することができるようになります。 ソリューションのショーケース この記事で詳細に説明されているソリューションは、いくつかの課題に対処する必要があります。以下の要件を満たす必要があります。 大規模な車両台数に対してスケーラブルであること。 デジタルツインがより複雑になるにつれて、コンポーネントを追加できるようにモジュール化されていること。 個々の電気自動車のモデルを自動的に再キャリブレーションし、正確な予測を続けるためのスケーラブルなメカニズムを提供できること。 以下の 図 1 に示されているスクリーンショットは、4 台の車両フリートにおける展開ソリューションです。また以下のビデオも、MHP のデジタルツインのプラットフォームを理解するのに役立ちます。 バッテリーの健康状態は、電気自動車の残存価値の直接的な指標です。SoH の劣化は、使用パターンや環境条件、そしてバッテリーの管理に強く依存しています。 ショーケースでは、運転パターンに基づいて EV のバッテリーの SoH を予測することに焦点を当てています。私たちは、2 つのデジタルツインを使用して電気自動車をモデル化しています。1 つ目はドライバーをモデル化し、2 つ目はバッテリーをモデル化します。両方のデジタルツインには、人工的なドライバーの振る舞いデータおよびバッテリーの劣化データを使用した合成データが利用されます。 ドライバーのデジタルツインは、次のトリップがいつ発生するか、トリップの所要時間はどれくらいか、そして他のドライバーに関連する情報を、カーネル密度推定を用いた振る舞いモデルに基づくサンプリングベースのアプローチで予測します。バッテリーのデジタルツインは、ドライバーのデジタルツインからのデータを使用して、バッテリーの将来の健康状態を予測し、バッテリーの劣化をモデリングします。 図 1 – 4 台の車両フリートにおける展開ソリューションのスクリーンショット サービスアーキテクチャ ここに示されているアーキテクチャでは、 AWS IoT FleetWise を使用してシミュレートされた車両データを Amazon Timestream データベースに取り込みます。データは、カスタムビルトの MHP デジタルツインサービスによって受信され、予測メタデータは Amazon DynamoDB に保存され、予測結果は再び Amazon Timestream に格納されます。 予測結果は AWS IoT TwinMaker にフィードされた後に、 Amazon Managed Service for Grafana を介してフリートオペレーターが簡単に使用できるダッシュボードで健康状態や他の車両情報を監視できるようになります。 図 2 – 全体的なサービスのアーキテクチャ MHP のデジタルツインサービスは、レベル4のデジタルツインソリューションの中心的な役割を果たします。運用データをデジタルツインモデルに渡し、モデルを実行し、モデルエラーを計算し、必要に応じてデジタルツインモデルを再キャリブレーションします。 このサービスは、 aws-do-pm のオープンソースフレームワークの一部として開発されたモデルキャリブレーション技術を活用しています。図 3 は MHP のデジタルツインサービスのアーキテクチャを示しています。 MHP のデジタルツインサービスには、新しいコンポーネントが追加されるにつれて成長する、いわばモジュラー型デジタルツインを可能にする 2 つの主要な機能があります。 まずデジタルツインは、各々が独自のデジタルツインで表されるサブモジュールに分割されます。それぞれの子デジタルツインは相互作用することで、親ツインの振る舞いを合成することができます。例えば、バッテリーは、セルのデジタルツインを使用してモデリングすることができますし、異なるコンポーネントのデジタルツインを使用して車をモデリングすることができます。モデリングの深さは、ユースケースと利用可能なモデリング技術に依存します。 次に、図3に示されるように、各デジタルツインは3つのモジュールに分割されます。新しいデータが利用可能になる度にモデルを更新して予測を改善するために、これらのモジュールはレベル4のリビングデジタルツインの基本的な要件を反映しています。これを可能にするために、すべてのデジタルツインにはデータサービス、更新サービス、予測サービスの 3 つのモジュールが含まれています。 図 3 – デジタルツインサービスのアーキテクチャ データサービスは、モデルへのデータの取り込みを処理します。また、予測結果をデータベースに書き込み、モデルパラメータをシリアライズする責任も持ちます。 更新サービスは、初期トレーニングを実行したり、モデル全体を更新したり、予測エラーが大きくなった場合にモデルにベイジアンキャリブレーションを実行することができます。 このベイジアン更新は、非線形システムのパラメータ推定に使用される Unscented Kalman Filter (UKF) に基づいています。UKF は、ガイダンス、ナビゲーション、車両の制御からロボットの動作計画や軌跡最適化まで、さまざまなフィールドで適用される手法です。UKF は、予測モデリングのための aws-do-pm フレームワークでも中心的な役割を果たしています。 これらの 3 つのモジュールは、個々のタスクとして開発され、 AWS Fargate 上に展開されます。各サービスは、スケーラビリティを確保するために Application Load Balancer を使用します。AWS Fargate 上のそれぞれのツインサービスとモジュール間メッセージのやり取りは、リモートプロシージャコール (RPC) フレームワークである gRPC を介して処理されます。 新しい外部データは、 Amazon Simple Notification Service (SNS) トピックで収集され、 AWS Lambda 関数に受信されます。Lambda 関数は gRPC リクエストを使用して、新しいデータを対応するデジタルツインに転送します。 結論 この記事では、MHP が AWS と協力して電気自動車の課題、特に EV バッテリーのパフォーマンスに対応するためにモジュラー型でスケーラブルなデジタルツインソリューションの構築に取り組んでいることに触れました。 このソリューションは、AWS が提案する 4-level のインデックス に基づく レベル 4 のリビングデジタルツイン です。詳細については、 MHP の ホワイトペーパー や ウェビナー をご覧ください。 上記は自動車産業の例ですが、デジタルツインには無限の可能性があります。 MHP – AWS パートナースポットライト MHP は、 1996 年に Porche AG の子会社として設立された AWS のアドバンストティアサービスパートナーです。 MHP のアプローチは、自動車業界をはじめとするさまざまな業界に対するマネジメントおよび IT コンサルティング、および深いプロセスノウハウの提供を含んでおり、顧客が自社のビジネスの将来をより良いものにすることができるよう支援しています。 MHPにお問い合わせ | パートナー概要 本ブログは、 Using Digital Twins to Drive Electric Vehicle Battery Insights with MHP and AWS を翻訳したものです。 翻訳は Solutions Architect Leader ショーン・セーヒーと Solutions Architect 佐藤高士が担当しました。

Apache Flink は、ストリームおよびバッチ処理向けの、パワフルなプログラミングインターフェースを提供するオープンソースの分散処理エンジンです。ステートフルな処理やイベントタイムセマンティクスをサポートしています。Apache Flink は、複数のプログラミング言語、Java、Python、Scala、SQL、および異なる抽象化レベルの複数の API をサポートしています。これらを単一のアプリケーション内で組み合わせて使用することも可能です。 Amazon Managed Service for Apache Flink は、Apache Flink アプリケーションをフルマネージド、サーバーレスで実行可能なサービスです。このたび、 Apache Flink 1.18.1 がサポートされたことをお知らせします。 本投稿では、直近のメジャーリリース 1.16、1.17、1.18 で導入され、かつ Managed Service for Apache Flink でサポートされた、Apache Flink の興味深い機能の一部について説明していきます。 新しいコネクタ Apache Flink バージョン 1.18.1 で利用可能な新機能を詳しくみていく前に、新しいオープンソースコネクタについて説明させてください。 OpenSearch 専用の OpenSearch コネクタが利用可能になりました。本コネクタにより、Apache Flink アプリケーションは Elasticsearch の互換モードに頼らずに、直接 OpenSearch にデータを書き込むことができます。本コネクタは Amazon OpenSearch Service のプロビジョンドクラスター、および OpenSearch Service Serverless と互換性があります。 新しいコネクタは SQL と Table API をサポートし、Java と Python の両方で動作します。また、Java については DataStream API もサポートされています。本コネクタは Flink のチェックポインティングと同期して書き込みを行うため、追加設定なしで at-least-once を保証しています。一意の ID とアップサート方式を組み合わせることで、exactly-once を達成することも可能です。 デフォルトでは、コネクタは OpenSearch バージョン 1.x のクライアントライブラリを使用します。 適切な依存関係を追加することで 、バージョン 2.x に切り替えることができます。 Amazon DynamoDB Apache Flink アプリケーション開発者は、 Amazon DynamoDB にデータを書き込むための専用のコネクタを利用できるようになりました。 本コネクタは、AWS によって開発され、今や Apache Flink プロジェクトの不可欠なコンポーネントである Apache Flink AsyncSink をベースとしています。Apache Flink AsyncSink を活用することで、ノンブロッキングな書き込みリクエストとアダプティブバッチングにより、効率のよい出力コネクタを簡単に実装できます。 本コネクタは SQL と Table API (Java と Python)、および DataStream API (Java のみ) の両方をサポートします。デフォルトでは、スループットを最適化するためにバッチ書き込みを行います。SQL バージョンにおける注目すべき機能は、PARTITIONED BY 句のサポートです。1 つ以上のキーを指定することで、クライアント側の重複排除を実現でき、各バッチ書き込み時に最新のレコードのみを指定されたキーごとに送信することができます。DataStream API でも、各バッチ内で上書きするパーティションキーのリストを指定することで、同等の処理を実現できます。 このコネクタはシンクとしてのみ動作します。DynamoDB からのデータ読み取りには使用できません。DynamoDB のデータを検索するには、 Flink Async I/O API を使って参照処理を実装するか、SQL の場合はカスタムユーザー定義関数 (UDF) を実装する必要があります。 MongoDB 興味深い別のコネクタとして、 MongoDB 向けのものがあります。本コネクタはソースとシンクの両方で、 SQL と Table API と DataStream API が利用可能です。新しいコネクタは、公式な Apache Flink プロジェクトの一部であり、コミュニティによってサポートされています。本コネクタは、MongoDB 自身が提供していた以前のコネクタに置き換わるものです。以前のコネクタでは、Flink の Sink および Source API のみをサポートしていました。 他のデータストアコネクタと同様に、ソースコネクタはバッチモードで bounded source として、または参照用として使用できます。シンクコネクタはバッチモードとストリーミングの両方で利用可能で、upsert および append の両モードをサポートします。 本コネクタには多くの注目すべき機能がありますが、その中でも言及しておきたいのは、ソースにおける参照時のキャッシュ有効化と、シンクにおける追加設定なしでの at-least-once 保証の二点です。プライマリキーが定義されている場合、シンクは idempotent upserts により、exactly-once をサポートすることもできます。 コネクタのバージョニング 新機能ではありませんが、コネクタのバージョン管理が新しくなった点は、以前の Apache Flink アプリケーションを更新する際に考慮すべき重要な要素となります。 Apache Flink バージョン 1.17 以降、ほとんどのコネクタがメインの Apache Flink ディストリビューションから外部化され、独立したバージョン管理に従うようになりました。 依存関係を正しく含めるためには、 - の形式でアーティファクトバージョンを指定する必要があります。 例えば、本投稿の執筆時点で最新の Kafka コネクタは、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) とも連携する、バージョン 3.1.0 です。Apache Flink 1.18 で本コネクタを使用する場合は、次の依存関係を使用する必要があります。 &lt;dependency&gt; &lt;groupId&gt;org.apache.flink&lt;/groupId&gt; &lt;artifactId&gt;flink-connector-kafka&lt;/artifactId&gt; &lt;version&gt;3.1.0-1.18&lt;/version&gt; &lt;/dependency&gt; Amazon Kinesis の新しいコネクタバージョンは 4.2.0 です。Apache Flink 1.18 における依存関係は以下のとおりです。 &lt;dependency&gt; &lt;groupId&gt;org.apache.flink&lt;/groupId&gt; &lt;artifactId&gt;flink-connector-kinesis&lt;/artifactId&gt; &lt;version&gt;4.2.0-1.18&lt;/version&gt; &lt;/dependency&gt; 次のセクションでは、Apache Flink 1.18 から利用可能となった強力な新機能の中で、Amazon Managed Service for Apache Flink でサポートされているものについて、さらに説明していきます。 SQL Apache Flink SQL において、オプティマイザに効果的なクエリプランを提案するために、 hints を結合クエリに付与可能となりました。特にストリーミングアプリケーションでは、外部システム (一般的にはデータベース) からクエリされたデータを使用して、ストリーミングデータを表すテーブルのエンリッチのために、 lookup joins が使用されます。バージョン 1.16 以降、lookup joins にいくつかの改善が導入され、結合の動作を調整してパフォーマンスを向上できるようになりました。 ルックアップキャッシュ は、最も頻繁に使用されるレコードをメモリにキャッシュすることで、データベースの負荷を軽減する強力な機能です。以前は、ルックアップキャッシュはいくつかのコネクタのみの専用機能でした。Apache Flink 1.16 以降、このオプションはルックアップをサポートしているすべてのコネクタで利用可能になりました ( FLIP-221 )。執筆時点では、 JDBC 、 Hive 、および HBase コネクタがルックアップキャッシュをサポートしています。ルックアップキャッシュには 3 つのモードがあります。メモリ上にすべて保持できる小さなデータセットの場合は FULL 、大きなデータセットの場合は最新のレコードのみをキャッシュする PARTIAL 、キャッシュを完全に無効にする NONE です。 PARTIAL キャッシュでは、バッファ行数と有効期限を設定可能です。 非同期ルックアップ はパフォーマンスを大幅に改善するための異なるアプローチです。非同期ルックアップは、Apache Flink SQL における DataStream API で利用可能な非同期 I/O と同様の機能を提供します。これにより、Apache Flink は、前のルックアップへの応答を受信するまでスレッドをブロックすることなく、データベースに新しい要求を送信できます。非同期 I/O と同様に、結果の順序付けを強制や、順不同な結果の許容、バッファ容量やタイムアウトの調整が可能です。 PARTIAL または NONE ルックアップキャッシュと組み合わせて、外部データベースのルックアップ失敗時の動作を設定する lookup retry strategy を設定することもできます。 これらの動作はすべて LOOKUP ヒントを使用して制御できます。以下に非同期ルックアップを使用したルックアップ結合を示します。 SELECT /*+ LOOKUP('table'='Customers', 'async'='true', 'output-mode'='allow_unordered') */ O.order_id, O.total, C.address FROM Orders AS O JOIN Customers FOR SYSTEM_TIME AS OF O.proc_time AS C ON O.customer_id = O.customer_id PyFlink このセクションでは、PyFlink の新機能と改善点について説明します。 Python 3.10 のサポート Apache Flink 1.18 では、PyFlink ユーザー向けのいくつかの改善が導入されました。 最も重要なのは、Python 3.10 がサポートされ、Python 3.6 のサポートが完全に削除されたことです ( FLINK-29421 )。 Managed Service for Apache Flink も、Python 3.10 ランタイムを使用して PyFlink アプリケーションを実行します。 機能差異の解消 プログラミング API の観点から見ると、PyFlink は、バージョンを重ねるごとに Java に近づいています。DataStream API では、サイド出力やブロードキャスト状態などの機能がサポートされるようになり、ウィンドウ API における不足も解消されました。また PyFlink は DataStream API から直接 Amazon Kinesis Data Streams などの新しいコネクタをサポートするようになりました。 スレッドモードの改善 PyFlink は非常に効率的です。PyFlink で Flink API オペレータを実行するオーバーヘッドは、Java や Scala に比べて最小限に抑えられています。これは、アプリケーションの言語に関係なく、ランタイムが実際にオペレータの実装を JVM で直接実行するためです。しかし、ユーザー定義関数の場合は少し異なります。 lambda x: x + 1 のような単純な Python コードでも、複雑な Pandas 関数でも、Python ランタイムで実行する必要があるためです。 デフォルトでは、Apache Flink は JVM の外部で、各 Task Manager 上で Python ランタイムを実行します。各レコードはシリアライズされ、プロセス間通信を介して Python ランタイムに渡され、デシリアライズされて処理されます。その結果は再度シリアライズされ、JVM に戻され、デシリアライズされます。これが PyFlink の PROCESS モード です。非常に安定していますが、オーバーヘッドが発生し、場合によってはパフォーマンスのボトルネックになる可能性があります。 Apache Flink バージョン 1.15 以降では、PyFlink 向けに THREAD モード もサポートしています。このモードでは、Python のユーザー定義関数が JVM 内で実行されるため、シリアライズ/デシリアライズおよび、プロセス間通信のオーバーヘッドが取り除かれます。THREAD モードには いくつかの制限 があります。たとえば、Pandas や UDAF (多数の入力レコードから 1 つの出力レコードを生成するユーザー定義集約関数) では使用できません。しかしながら、PyFlink アプリケーションのパフォーマンスを大幅に向上させることができます。 バージョン 1.16 では、THREAD モードのサポートが大幅に拡張され、Python DataStream API もカバーされるようになりました。 Managed Service for Apache Flink は THREAD モードをサポートしており、 PyFlink アプリケーションから直接有効化が可能です 。 Apple Silicon サポート Apple Silicon ベースのマシンで PyFlink アプリケーションの開発をする際に、PyFlink 1.15 においては、Apple Silicon における既知の Python 依存関係の問題に遭遇したかもしれません。これらの問題はついに解決されました ( FLINK-25188 )。これらの制限は、Apache Flink の Managed Service 上で実行される PyFlink アプリケーションには影響しませんでした。バージョン 1.16 より前は、M1、M2、M3 チップセットを使用するマシン上で PyFlink アプリケーションを開発する場合、PyFlink 1.15 以前をマシン上に直接インストールすることができないため、 回避策 を適用する必要がありました。 アンアラインドチェックポイントの改善 Apache Flink 1.15 ではすでに Incremental Checkpoint と Buffer Debloating がサポートされています。特にこれらの機能を組み合わせて使用することで、チェックポイントのパフォーマンスを改善し、バックプレッシャーが発生している場合でもチェックポインティングの期間をより予測可能とすることができます。これらの機能の詳細については、 Amazon Managed Streaming for Apache Flink アプリケーション向けのバッファデブロートとアンアラインドチェックポイント をご覧ください。 バージョン 1.16 および 1.17 では、安定性とパフォーマンスを向上させるためにいくつかの変更が導入されました。 データスキューの処理 Apache Flink は ウォーターマークによるイベントタイムのセマンティクスをサポートしています 。ウォーターマークは、通常はソースオペレーターからフローに挿入される特別なレコードで、イベントタイムウィンドウ集計などのオペレーターのイベントタイムの進行をマークします。一般的な手法は、最新の観測されたイベントタイムからウォーターマークを遅延させ、ある程度の範囲でイベントが順不同になることを許容することです。 しかし、ウォーターマークの使用には課題があります。アプリケーションが複数のソースを持つ場合、例えば Kafka トピックの複数のパーティションからイベントを受信する場合、ウォーターマークは各パーティションごとに独立して生成されます。内部的には、各オペレーターは常に、すべての入力パーティションで同じウォーターマークを待機します。これは実質的に最も遅いパーティションに合わせることを意味します。これがネックとなり、あるパーティションがデータを受信していない場合は、ウォーターマークが進まず、エンドツーエンドのレイテンシが増加します。このため、多くのストリーミングソースに オプションとしてアイドルタイムアウト が導入されています。設定したタイムアウト後は、レコードを受信していないパーティションを無視してウォーターマークの生成を行い、ウォーターマークを進めることができます。 1 つのソースがほかよりもイベントを大幅に早く受信している場合、逆の課題に直面する可能性があります。ウォーターマークはもっとも遅いパーティションに揃えられるため、ウィンドウ集約のためにウォーターマークを待つ必要が生じます。高速なソースからのレコードは、バッファリングされながら待たされることになります。オペレータ状態が制御できない程に、バッファリングされたデータが肥大化する恐れがあります。 より高速なソースの問題に対処するため、Apache Flink 1.17 以降では、ソース分割におけるウォーターマークアライメントを有効化できます ( FLINK-28853 )。デフォルトでは無効になっているこのメカニズムにより、特定のパーティションが他のパーティションと比べてウォーターマークを速く進めすぎないようになります。複数のソース (複数の入力トピックなど) を 1 つのアライメントグループ ID に割り当て、現在のウォーターマークからの最大ドリフト期間を指定することで、これらを束ねることができます。特定のパーティションがイベントを高速で受信する場合、ソースオペレーターはドリフトが指定されたしきい値を下回るまで、そのパーティションの消費を一時停止します。それぞれのソースごとに有効化できます。必要なのは、同じ ID を持つすべてのソースを結びつける整列グループ ID と、現在の最小ウォーターマークからの最大ドリフト時間を指定することです。これにより、あまりにも速く進んでいるソースサブタスクの消費が一時停止し、ドリフトが指定された閾値を下回るまで待機します。 以下のコードスニペットは、Kafka ソースから協会のない順序性のウォーターマークを出力するために、ソース分割のウォーターマークアラインメントを設定する方法を示しています。 KafkaSource kafkaSource = ... DataStream stream = env.fromSource( kafkaSource, WatermarkStrategy.forBoundedOutOfOrderness( Duration.ofSeconds(20)) .withWatermarkAlignment("alignment-group-1", Duration.ofSeconds(20), Duration.ofSeconds(1)), "Kafka source")); この機能は、 FLIP-217 に準拠した、ソース分割のウォーターマークアラインメントをサポートしているソースでのみ利用可能です。執筆時点では、主要なストリーミングソースコネクタのうち、Kafka ソースのみがこの機能をサポートしています。 Protobuf フォーマットの直接サポート 現在、SQL と Table API は、 Protobuf 形式 を直接サポートしています。この形式を利用するには、 .proto スキーマ定義ファイルから Protobuf の Java クラスを生成し、アプリケーションの依存関係に含める必要があります。 Protobuf フォーマットは SQL およびテーブル API でのみ利用可能で、Protobuf でシリアルライズされたデータをソースまたはシンクから読み書きする場合にのみ機能します。現在、Flink はステートを直接シリアルライザブルする Protobuf を直接サポートしておらず、Avro などのように schema evolution もサポートしていません。アプリケーション用に カスタムシリアライザー を登録する必要がありますが、オーバーヘッドを伴います。 Apache Flink をオープンソースのまま維持 Apache Flink は、サブタスク間のデータ送信を、内部的に Akka に依存してきました。 2022 年、Akka を開発している企業である Lightbend は、 今後の Akka バージョンのライセンスを Apache 2.0 からより制限的なライセンスに変更し、Apache Flink で使用されているバージョンである Akka 2.6 にはこれ以上のセキュリティアップデートや修正が提供されないこと を発表しました。 Akka は従来から非常に安定しており、頻繁な更新は必要ありませんでしたが、このライセンスの変更は Apache Flink プロジェクトにとってリスクとなりました。Apache Flink コミュニティの決定は、Akka 2.6 のフォークである Apache Pekko ( FLINK-32468 ) に置き換えることでした。このフォークは Apache 2.0 ライセンスを維持し、コミュニティによって必要な更新が加えられます。それまでの間、Apache Flink コミュニティは、Akka ならびに Pekko への依存関係を完全に削除するかどうかを検討しています。 ステート圧縮 Apache Flink は、すべてのチェックポイントとセーブポイントに対してオプションの圧縮 (デフォルト: オフ) を提供します。 Apache Flink は、スナップショット圧縮が有効になっている場合にオペレーターの状態を適切に復元できないという Flink 1.18.1 の バグ を特定しました。これにより、データが失われるか、チェックポイントから復元できなくなる可能性があります。これを解決するために、Managed Service for Apache Flink は、Apache Flink の将来のバージョンに含まれる 修正 をバックポートしました。 Managed Service for Apache Flink におけるインプレースバージョンアップグレード Apache Flink 1.15 以前のバージョンを使用して Managed Service for Apache Flink で現在アプリケーションを実行している場合、 AWS コマンドラインインターフェース (AWS CLI)、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) または AWS API を使用するツールのいずれかを使用して、ステートを失うことなくバージョン 1.18 にインプレースアップグレードが可能です。 UpdateApplication API アクションによって、既存の Managed Service for Apache Flink アプリケーションの Apache Flink ランタイムバージョンを更新できるようになりました。実行中のアプリケーションに直接 UpdateApplication を使用できます。 インプレースアップグレードを続行する前に、アプリケーションに含まれる依存関係を検証したうえで更新し、新しい Apache Flink バージョンと互換性があることを確認する必要があります。特に、Apache Flink ライブラリ、コネクタ、場合によっては Scala バージョンを更新する必要があります。 また、更新を続行する前に、更新されたアプリケーションをテストすることをお勧めします。リグレッションが発生していないことを確認するために、ターゲットの Apache Flink ランタイムバージョンを使用して、ローカルもしくは本番以外の環境でテストすることをお勧めします。 最後に、アプリケーションがステートフルである場合は、実行中のアプリケーションの状態の スナップショット を取得することをお勧めします。これにより、以前のアプリケーションバージョンにロールバック可能となります。 準備ができたら、 UpdateApplication API アクションまたは update-application AWS CLI コマンドを使用して、アプリケーションのランタイムバージョンを更新し、更新された依存関係を含む新しいアプリケーションアーティファクト、JAR、または zip ファイルをポイントできるようになります。 プロセスと API の詳細については、 Apache Flink のインプレース バージョン アップグレード を参照してください。ドキュメントには、ステップバイステップの手順とアップグレードプロセスを説明する動画が含まれています。 まとめ この投稿では、Apache Flink の Amazon マネージドサービスでサポートされている Apache Flink の新機能のいくつかを調べました。このリストは包括的なものではありません。 Apache Flink は、SQL およびテーブル API のオペレーターレベル TTL [FLIP-292] やタイムトラベル [FLIP-308] など、非常に有望な機能もいくつか導入しましたが、これらは API ではまだサポートされておらず、ユーザーが実際にアクセスできる状態にありません。そのため、本投稿で取り上げる対象から外しました。 Apache Flink 1.18 で利用できる興味深い新機能と新しいコネクタのいくつかと、Apache Flink のマネージド サービスが既存のアプリケーションのアップグレードにどのように役立つかを見てきました。 最近のリリースの詳細については、Apache Flink ブログとリリースノートをご覧ください。 Amazon Managed Service for Apache Flink のリリースノート Apache Flink 1.16 リリース記事 および リリースノート Apache Flink 1.17 リリース記事 および リリースノート Apache Flink 1.18 リリース記事 および リリースノート Apache Flink を初めて使用する場合は、 適切な API と言語を選択するガイド を参照し、 スタートガイド に従って Apache Flink のマネージド サービスの使用を開始することをお勧めします。 著者について Lorenzo Nicora は AWS でシニア ストリーミング ソリューション アーキテクトとして働いており、EMEA 全体の顧客をサポートしています。彼は 25 年以上にわたってクラウドネイティブでデータ集約型のシステムを構築しており、コンサルティング会社や FinTech 製品会社の両方を通じて金融業界で働いています。彼はオープンソース テクノロジーを幅広く活用し、Apache Flink などのいくつかのプロジェクトに貢献してきました。 Francisco Morillo は AWS のストリーミング ソリューション アーキテクトです。 Francisco は AWS の顧客と協力し、AWS のサービスを使用したリアルタイム分析アーキテクチャの設計を支援し、Amazon MSK および Amazon Managed Service for Apache Flink をサポートしています。 本記事は、 Amazon Managed Service for Apache Flink now supports Apache Flink version 1.18 を翻訳したものです。翻訳は Solutions Architect の榎本が担当しました。

本記事は、 Announcing data filtering for Amazon Aurora MySQL zero-ETL integration with Amazon Redshift を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 組織がよりデータドリブンになり、データを競争力向上の源として利用するようになると、売上の成長、コスト削減、ビジネスの最適化のために、データ分析を実行し主要なビジネス上の課題をより深く理解しようとします。 稼働中のサービスにまつわるデータで分析を実行するために、データベース、データウェアハウス、ETL(extract, transform, and load) パイプラインの組み合わせで構成されるソリューションを構築する場合があります。 ETL とは、データエンジニアが異なるソースからのデータを組み合わせるために使用するプロセスです。 ETL パイプラインの構築と保守の労力を軽減するために、AWS は Amazon Redshift との Amazon Aurora ゼロ ETL 統合 を AWS re:Invent 2022 で発表しました。この機能は現在、 Amazon Aurora MySQL 互換エディション 3.05.0 以降で一般提供されています。 AWS は本日、ゼロ ETL 統合のデータフィルタリングを発表しました。これにより、Amazon Aurora MySQL と Amazon Redshift 間のゼロ ETL 統合においてデータを選択して取り込むことができます。この機能により、分析ユースケースにおいて、データウェアハウスである Redshift にレプリケートする個々のデータベースとテーブルを選択できます。 この投稿では、この機能を使用できるユースケースの概要を示し、この機能を使用してニアリアルタイムの運用分析を開始する方法について段階的に説明します。 データフィルタリングの使用例 データフィルタリングを使用すると、Amazon Aurora MySQL から Amazon Redshift へレプリケートするデータベースとテーブルを選択できます。 複数のフィルターをゼロ ETL 統合に適用できるため、レプリケーションを特定のニーズに合わせて調整できます。 データフィルタリングは、 exclude フィルターまたは include フィルターのいずれかのルールを適用し、正規表現を使用して複数のデータベースとテーブルを照合できます。 このセクションでは、データフィルタリングの一般的なユースケースについて説明します。 PII データを含むテーブルをレプリケーションから除外することによるデータセキュリティの向上 サービス内で運用されているデータベースには、個人を特定できる情報(PII)が含まれていることがよくあります。これは性質上センシティブな情報であり、郵送先住所、顧客確認書類、クレジットカード情報などが含まれます。 厳格なセキュリティコンプライアンス規制のため、分析ユースケースに個人を特定できる情報(PII)を使用したくない場合があります。データフィルタリングを使用すると、PII データを含むデータベースやテーブルをフィルタリングして、Amazon Redshift へのレプリケーションから除外できます。これにより、分析ワークロードのデータセキュリティとコンプライアンスが向上します。 特定のユースケースに必要なテーブルをレプリケートすることで、ストレージコストを節約し、分析ワークロードを管理 サービス内で運用されているデータベースには、分析に役立たない様々なデータセットが含まれていることがよくあります。これには補助データ、特定のアプリケーションデータ、異なるアプリケーションのための同じデータセットの複数のコピーが含まれます。 さらに、Redshift を利用したデータウェアハウスはそれぞれの異なるユースケースごとに構築することが一般的です。そういったアーキテクチャでは、個々のエンドポイントで異なるデータセットを利用できる必要があります。 データフィルタリングを使用すると、ユースケースで必要なデータセットのみをレプリケートできます。 これにより、使用されていないデータを保存する必要性をなくすことでコストを節約できます。 既存のゼロ ETL 統合を変更して、必要に応じてより制限的なデータレプリケーションを適用することもできます。 既存の統合にデータフィルターを追加すると、Aurora は新しいフィルターを使用してレプリケートされるデータを完全に再評価します。 これにより、対象の Redshift エンドポイントから新しくフィルタリングされたデータが削除されます。 Aurora の Amazon Redshift とのゼロ ETL 統合のクォータの詳細については、 クォータ を参照してください。 小規模なデータレプリケーションから開始し、必要に応じてテーブルを段階的に追加する Amazon Redshift 上でより多くの分析ユースケースが開発されるにつれ、個々のゼロ ETL レプリケーションにさらにテーブルを追加したいと考えるかもしれません。 将来的に使用する可能性に備えて、Aurora データベースのすべてのテーブルを Amazon Redshift にレプリケートするのではなく、データフィルタリングを使用することで、Aurora データベースの一部のテーブルのサブセットから小規模に開始し、必要に応じてフィルターにさらにテーブルを増分的に追加できます。 ゼロ ETL 統合のデータフィルターが更新されレプリケーションの対象にテーブルが追加された際には、Aurora はフィルター全体を評価しなおします。これにより、以前にレプリケートされたテーブルを使用しているワークロードは、新しいテーブルを追加しても影響を受けることはありません。 レプリケーションプロセスの負荷分散によるワークロードごとのパフォーマンスを向上する 大規模なトランザクションデータベースの場合、レプリケーションとその下流の処理を複数の Redshift クラスタにロードバランスする必要があるかもしれません。これにより、個々の Redshift エンドポイントのコンピューティング要件を削減し、ワークロードを複数のエンドポイントに分割することができます。複数の Redshift エンドポイントにわたってワークロードをロードバランスすることで、エンドポイントが個々のワークロードに適切にサイズ設定されたデータメッシュアーキテクチャを効果的に作成できます。これによりパフォーマンスが向上し、全体的なコストが低減できます。 データフィルタリングを使用すると、異なるデータベースとテーブルを個別の Redshift エンドポイントにレプリケートできます。 次の図は、ゼロ ETL 統合でデータフィルターを使用して、Aurora の異なるデータベースを Redshift エンドポイントに分割する方法を示しています。 使用例 TICKIT データベースを考えてみましょう。TICKIT サンプルデータベースには、ユーザーが各種イベントのチケットを売買する架空の会社のデータが含まれています。この会社のビジネスアナリストは、Aurora MySQL データベースに保存されているデータを使用して、さまざまなメトリックを生成したいと考えており、この分析をニアリアルタイムで実行したいと考えています。そこで、この会社はゼロ ETL がソリューションになりうるのではないかと考えました。 会社のアナリストが必要なデータセットを調査している間に、users テーブルには顧客ユーザー情報に関する個人情報が含まれているが、その情報は分析要件にとって有用ではないことがわかりました。 したがって、users テーブルを除くすべてのデータをレプリケートしたいと考えており、ゼロ ETL のデータフィルタリングを使用して　それを実現したいと考えています。 セットアップ まず、 Amazon Aurora と Amazon Redshift のゼロ ETL 統合を使用したニアリアルタイム運用分析のためのスタートガイド に従って、新しい Aurora MySQL データベース、 Amazon Redshift Serverless エンドポイント、ゼロ ETL 統合を作成します。 次に Redshift クエリエディター v2 を開き、users テーブルからのデータが正常にレプリケートされていることを確認するために、次のクエリを実行します。 select * from aurora_zeroetl.demodb.users ; データフィルター データフィルターは、 Amazon Relational Database Service (Amazon RDS) のゼロ ETL 統合に直接適用されます。 単一の統合に対して複数のフィルターを定義でき、各フィルターは Include フィルター型または Exclude フィルター型のいずれかとして定義されます。 データフィルターは、既存および将来のデータベーステーブルにパターンを適用して、適用するフィルターを決定します。 データフィルタの適用 ゼロ ETL 統合から users テーブルを削除するフィルターを適用するには、次のステップを行います。 Amazon RDS コンソールのナビゲーションペインで、 ゼロ ETL 統合 を選択します。 フィルターを追加するゼロ ETL 統合を選択します。 デフォルトのフィルターは、 include:*.* というフィルターで表され、すべてのデータベースとテーブルを含めます。 変更 を選択します。 ソース セクションで フィルターを追加する を選択します。 フィルタータイプを選択する で 除外する を選択します。 フィルター式 に demodb.users と入力します。 フィルター式の順序が重要になります。フィルターは左から右、上から下に評価され、後続のフィルターが前のフィルターをオーバーライドします。この例では、Aurora はすべてのテーブルを含める必要があると評価し(フィルター 1)、次に demodb.users テーブルを除外する必要があると評価します(フィルター 2)。exclusion フィルターは inclusion フィルターの後にあるため、inclusion フィルターをオーバーライドします。 続行 を選択します。 変更内容をレビューし、フィルターの並び順が正しいことを確認したら、　 変更内容を保存 を選択します。 統合が追加され、変更が適用されるまで 変更中 の状態になります。これには最大 30 分かかる場合があります。変更の適用が完了したかどうかを確認するには、ゼロ ETL 統合を選択し、そのステータスを確認してください。 アクティブ と表示されていれば、変更が適用されたことを意味します。 変更の確認 ゼロ ETL 統合が更新されたことを確認するには、次のステップを完了してください: Redshift クエリエディター v2 で、Redshift クラスターに接続します。 作成した aurora-zeroetl データベースを右クリックで選択し、 更新 を選択します。 demodb と Tables を展開します。 users テーブルはレプリケーションから削除されたため、もう利用することができなくなっています。 他のすべてのテーブルは引き続き利用可能です。 以前と同じ SELECT ステートメントを実行すると、オブジェクトがデータベースに存在しないというエラーが発生します: select * from aurora_zeroetl.demodb.users ; AWS CLI を使用したデータフィルタの適用 会社のビジネスアナリストは、Aurora MySQL データベースにさらに多くのデータベースが追加されていることを理解し、 demodb データベースのみが Redshift クラスタにレプリケートされるようにしたいと考えています。 このため、 AWS Command Line Interface (AWS CLI) を使用して、ゼロ ETL 統合のフィルタを更新したいと考えています。 AWS CLI を使用したゼロ ETL 統合にデータフィルターを追加するには、 modify-integration コマンドを呼び出すことができます。 統合識別子に加えて、 include フィルターと exclude フィルターをコンマ区切りでならべたリストを使用して、 --data-filter パラメータを指定します。 ゼロ ETL 統合のフィルターを変更するには、次のステップを完了します: AWS CLI がインストールされたターミナルを開きます。 利用可能なすべての統合を表示して確認するには、次のコマンドを入力します。 aws rds describe-integrations 更新したい統合を見つけ、統合識別子をコピーします。 統合識別子は、統合の ARN の末尾にある英数字の文字列です。 前のステップでコピーした識別子で &lt;integration identifier&gt; を更新し、次のコマンドを実行します: aws rds modify-integration --integration-identifier " &lt;integration identifier&gt; " --data-filter 'exclude: *.*, include: demodb.*, exclude: demodb.users' Aurora がこのフィルターを評価するとき、デフォルトですべてを除外し、 demodb データベースのみを含めますが、 demodb.users テーブルは除外します。 データフィルターは、データベースとテーブルに対して正規表現を利用したフィルタリングが可能です。 たとえば、 user で始まるテーブルをすべてフィルタリングしたい場合は、次のように実行できます: aws rds modify-integration --integration-identifier " " --data-filter 'exclude: *.*, include: demodb.*, exclude *./^user/' 前のフィルターの変更と同様に、変更が適用されるまで統合が追加され 変更中 の状態になります。これには最大 30 分かかる場合があります。 アクティブ と表示されたら、変更が適用されたことを意味します。 クリーンアップ ゼロ ETL 統合に追加されたフィルターを削除するには、次のステップを完了してください: Amazon RDS コンソールのナビゲーションペインで、 ゼロ ETL 統合 を選択します。 該当のゼロ ETL 統合を選択します。 変更 を選択します。 削除したいフィルターのとなりにある 削除 を選択します。 exclusion フィルターを inclusion フィルターに変更することもできます。 あるいは、AWS CLI を使用して次のコマンドを実行することもできます: aws rds modify-integration --integration-identifier " " --data-filter 'include: *.*' 「 続行 」を選択します。 「 変更を保存 」を選択します。 データフィルターの変更を適用するには、最大 30 分かかります。 データフィルターを削除すると、Aurora は、削除されたフィルターが存在しなかったかのように、残りのフィルターを再評価します。 以前はフィルタリング基準に一致しなかったが、変更によって一致するようになったデータは、ターゲットの Redshift データウェアハウスにレプリケートされます。 結論 この投稿では、Amazon Aurora MySQL から Amazon Redshift へのゼロ ETL 統合にデータフィルタリングを設定する方法を示しました。これにより、必要なデータのみをレプリケートしながら、トランザクションデータや運用データでニアリアルタイムな分析を行うことができます。 データフィルタリングを使用すると、ワークロードを個別の Redshift エンドポイントに分割したり、プライベートまたは機密データセットのレプリケーションを制限したり、必要なデータセットのみをレプリケートすることでワークロードのパフォーマンスを向上させたりすることができます。 Amazon Redshift との Aurora ゼロ ETL 統合の詳細については、 Amazon Redshift との Aurora ゼロ ETL 統合の利用 および ゼロ ETL 統合の利用 を参照してください。 著者について Jyoti Aggarwal は、AWS ゼロ ETL の製品管理リードです。彼女は、パフォーマンス、顧客エクスペリエンス、セキュリティに関する取り組みの推進など、製品およびビジネス戦略を主導しています。彼女は、クラウド コンピューティング、データ パイプライン、分析、人工知能 (AI)、およびデータベース、データ ウェアハウス、データ レイクなどのデータ サービスに関する専門知識をもたらします。 Sean Beath は、アマゾン ウェブ サービスのAnalytics Solutions Architect です。彼は、AWS のサービスを使用したデータ プラットフォームの最新化の配信ライフサイクル全体の経験があり、顧客と協力して AWS での分析価値の向上を支援しています。 Gokul Soundararajan AWS の主任エンジニアであり、トロント大学で博士号を取得し、ストレージ、データベース、分析の分野で働いてきました。

このブログ記事は Senior Solutions Architect の Dmitriy Novikov と Senior Edge Specialist Solutions Architect の Harith Gaddamanugu によって書かれました。 ネットワークセキュリティオペレーターの多くの方にとって、アプリケーションの稼働時間を守ることは、ネットワークトラフィックのベースラインを設定し、不審な送信者を調査し、リスクを軽減するための最善の方法を決定するという、時間のかかる課題となっています。このプロセスを簡素化し、常にネットワークセキュリティの状態を把握することが、セキュリティオペレーションスタッフを増員することなくアプリケーションを拡張しようとしている IT 組織の目標となっています。この課題に対処するため AWS WAF でアプリケーションを保護している場合に、セキュリティ状況に関する十分な情報に基づいて意思決定ができるようにするための AWS WAF traffic overview ダッシュボード を導入しました。 この記事では新しいダッシュボードを紹介し、AWS WAF を使用してアプリケーションの全体的なセキュリティを把握して、ダッシュボードから得られる洞察に基づいて意思決定できるようにするための、いくつかのユースケースを詳しく説明します。 Traffic overview ダッシュボードの紹介 AWS WAF の Traffic overview ダッシュボードには、セキュリティ関連のメトリクスが表示されるため、分散型サービス拒否 (DDoS) イベント発生時に レートベースのルール を追加するなど、数クリックでセキュリティリスクを特定して対処できます。これらのダッシュボードには、AWS WAF がアプリケーションの Web トラフィックを評価する際に収集する Amazon CloudWatch メトリクスをほぼリアルタイムで表示することができます。 これらのダッシュボードはデフォルトで利用できるため、追加の設定は必要ありません。AWS WAF で監視する各 Web ACL について合計リクエスト数、ブロックされたリクエスト数、許可されたリクエスト数、ボットと非ボットのリクエストの割合、ボットカテゴリ、CAPTCHA 解決率、上位 10 件のマッチしたルールなどのメトリクスが表示されます。 総リクエスト数、ブロックされたリクエスト数、ブロックされた一般的な攻撃などのデフォルトメトリクスにアクセスすることも、最も重要なメトリクスと視覚化を選んでダッシュボードをカスタマイズすることもできます。 これらのダッシュボードは可視性を高め、以下のような質問に答えることができます: AWS WAF で検査されたトラフィックの何%がブロックされていますか? ブロックされているトラフィックの主な発信国はどこですか? AWS WAF が検知して保護している攻撃は何ですか? 今週のトラフィックパターンは先週と比べてどうですか? ダッシュボードには CloudWatch との間でネイティブかつシームレスな統合が用意されており、ダッシュボードと CloudWatch を行き来しながら、より詳細なメトリクスを CloudWatch で確認することができます。また、既存の CloudWatch ウィジェットやメトリクスを Traffic overview ダッシュボードに追加し、実績のある可視性をダッシュボードに取り込むこともできます。 Traffic overview ダッシュボードの導入とともに、AWS WAF の Sampled requests は Web ACL 内のスタンドアロンタブになりました。このタブでは、AWS WAF が検査した Web リクエストのルールマッチのグラフを確認できます。さらに、リクエストサンプリングを有効にしている場合、AWS WAF が検査した Web リクエストのサンプルをテーブルビューで確認できます。 リクエストのサンプルには Web ACL のルールの条件に一致した最大 100 件のリクエストと、ルールに一致せず Web ACL のデフォルトアクションが適用されたリクエスト 100 件が含まれます。サンプル内のリクエストは、過去 3 時間以内にコンテンツへのリクエストを受信した保護リソースからのものです。 以下の図は Traffic overview ダッシュボードのレイアウトの一例を示しています。ここでは攻撃タイプ、クライアントデバイスタイプ、国別などのアクションの取れる洞察が、表示されるカテゴリごとに検査されたリクエストが分類されています。この情報と期待するトラフィックプロファイルを比較することで、さらに調査する必要があるか、すぐにトラフィックをブロックするかを判断できます。図1 の例では、Web アプリケーションがフランスからのトラフィックを想定しておらず、デスクトップ専用のアプリケーションである場合、モバイルデバイスからのフランス発信のリクエストをブロックすることを検討するかもしれません。 図1: 複数のカテゴリを示すセクションがあるダッシュボード ユースケース1: ダッシュボードを使用してトラフィックパターンを分析する Webトラフィックの可視化に加えて、新しいダッシュボードを使って潜在的な脅威や問題を示すパターンを分析できます。ダッシュボードのグラフやメトリクスを確認することで、さらなる調査が必要な異常なトラフィックの増加や減少を発見できます。 トップレベルの Traffic overview では、ハイレベルのトラフィックとパターンが表示されます。そこから、特定のルールやルールグループの傾向とメトリクスを確認するために Web ACL メトリクスに掘り下げることができます。ダッシュボードには許可されたリクエスト、ブロックされたリクエストなどのメトリクスが表示されます。 予想されるトラフィックパターンからの逸脱に関する通知やアラートは、イベントを探る合図となります。探索中、ダッシュボードを使ってイベントを孤立させるのではなく、より広い文脈を理解できます。これにより、セキュリティイベントや設定ミスのルールを示す異常なトレンドを検出するのが簡単になります。例えば、通常は特定の国から 1 分あたり 2,000 件のリクエストがあるサービスで、突如 1 万件のリクエストがあった場合は調査する必要があります。ダッシュボードを使用すると、さまざまな側面からトラフィックを確認できます。リクエストの増加だけでは脅威の明確な兆候とはならないかもしれませんが、予期せぬデバイスタイプなどの別の兆候があれば、フォローアップ対応を取る十分な理由となります。 次の図は Web ACL のルールによるアクションと、最も一致したルールを示しています。 図2: ウェブリクエストの多次元的なダッシュボード このダッシュボードでは、時間経過に伴うブロックされたリクエストとアクセス許可されたリクエストのトップも表示されます。ブロックされたリクエストの異常なスパイクが、特定の IP アドレス、国、またはユーザーエージェントからのトラフィックのスパイクに対応しているかどうかを確認してください。これは、悪意のある活動またはボットトラフィックの試みを示している可能性があります。 次の図は、特定のベクターが保護されたウェブアプリケーションに対して使用されていることを示す、ルールへのマッチ件数が不相応に多いことを示しています。 図3: 最上位のルールは、攻撃のベクトルを示している可能性があります 同様に上位の許可されたリクエストを確認してください。特定のURLへのトラフィックに急増が見られた場合は、アプリケーションが適切に機能しているかどうかを調査する必要があります。 トラフィックを分析した後の次のステップ トラフィックパターンを分析した後、検討すべき次のステップは以下の通りです。 調査結果に基づいて、正常または悪意のあるトラフィックとより一致するように AWS WAF ルールを調整します。 正規表現 や条件を調整することで、False Positive（偽陽性）や False Negative（偽陰性）を減らすことができるかもしれません。正常なトラフィックをブロックしているルールを調整します AWS WAF のロギング を設定し、専用のセキュリティ情報およびイベント管理 （SIEM）ソリューションがある場合は、異常に対する自動アラートを可能にするためにロギングを統合します 既知の悪意のある IP を自動的にブロックするように AWS WAF を設定します。特定された脅威の発信元に基づいて IP ブロックリストを維持できます。さらに Amazon 脅威リサーチチームが定期的に更新する、 Amazon IP レピュテーションリスト のマネージドルールグループを使用できます 特定のページへのトラフィックの急増が見られた場合は、不審なパターンの原因がアプリケーションの問題でないかをチェックします トラフィックフローで新しい攻撃パターンを発見した場合は、それをブロックする新しいルールを追加します。次に、メトリクスを確認して、新しいルールの影響を確認します DDoS 攻撃やその他の悪意のあるトラフィックのスパイクのために送信元 IP を監視します。レートベースのルールを使って、これらのスパイクを緩和するのに役立ちます トラフィックフラッディングが発生した場合は、DDoS 保護付きの CloudFront を使用して、追加の保護レイヤを実装します 新しいダッシュボードにより、アプリケーションに到達するトラフィックについて貴重な洞察が得られ、トラフィック分析における推測の必要がなくなります。得られた洞察を活用して AWS WAF の保護を細かく調整し、可用性やデータが影響を受ける前に脅威をブロックできます。潜在的な脅威を検出し、保護を最適化するための情報に基づいた決定を行うために、データを定期的に分析してください。 例えば、ダッシュボードで過去のトラフィックパターンと比べて、トラフィックが発生すると予測していない国から不審な急増があった場合、Web ACL に 地理的一致ルールステートメント を作成して、そのトラフィックが Web アプリケーションに到達するのを防ぐことができます。 このダッシュボードは、洞察を得るための優れたツールであり、AWS WAFマネージドルールがトラフィックを保護する方法を理解するのに役立ちます。 ユースケース2: オンボーディング中のボットトラフィックを理解し、Bot Control ルールグループを細かく調整する AWS WAF Bot Control を使用するとスクレイパー、スキャナー、クローラー、ステータスモニター、検索エンジンなどのボットを監視、ブロック、またはレート制限できます。ルールグループのターゲットインスペクションレベルを使用すると、自己識別しないボットにチャレンジできるため、悪意のあるボットがWebサイトに対して操作することが困難になり、コストがかかります。 Traffic overview ダッシュボードの Bot Control タブでは、現在のトラフィックの内、ボットからのものがどの程度か (Bot Control を有効にしていない場合はリクエストのサンプリング、有効にしている場合は実時間の CloudWatch メトリクスに基づいて) 確認できます。 オンボーディングフェーズではこのダッシュボードを使用してトラフィックを監視し、さまざまなタイプのボットからのトラフィックがどの程度あるかを理解します。これをボット管理のカスタマイズの出発点として利用できます。例えば Bot Control ルールグループをカウントモードで有効にし、望ましいトラフィックが誤ってラベル付けされていないか確認できます。次に、「 AWS WAF Bot Control の例: 特定のブロックされたボットを許可する 」で説明されているように、ルールの例外を追加できます。 次の図はボットによって生成、検出されたリクエストのさまざまな次元を視覚化するウィジェットのコレクションを示しています。カテゴリとボリュームを理解することでさらにログを詳しく調査すべきか、望ましくないトラフィックはそのカテゴリをブロックするか情報に基づいた決定を下すことができます。 図4: ダッシュボード上のボット関連メトリックのコレクション 開始した後は同じダッシュボードを使って、ボットトラフィックを監視し、自己識別しない高度なボットに対するターゲット検出を追加するかどうかを評価できます。ターゲット保護ではブラウザ問い合わせ、フィンガープリンティング、行動のヒューリスティクスなどの検出手法を使用して、悪意のあるボットトラフィックを特定します。AWS WAF トークンはこれらの高度な保護に不可欠です。 AWS WAF はサイレントチャレンジや CAPTCHA パズルに正常に応答したクライアントに対して、トークンを作成、更新、暗号化します。トークンを持つクライアントが Web リクエストを送信すると暗号化されたトークンが含まれ、AWS WAF はトークンを復号化してその内容を検証します。 Bot Control ダッシュボードの「トークンステータス」ペインには、様々なトークンステータスラベルのカウントと、リクエストに適用されたルールアクションのペアが表示されます。 IP token absent thresholds ペインには、トークン無しでリクエストを多数送信した IPに関するデータが表示されます。この情報を使って AWS WAF の設定を細かく調整できます。 例えば Bot Control ルールグループ内で、有効なトークンがないリクエストがルールグループの評価を終了し、Web ACL による評価が続行される可能性があります。トークンがない、またはトークンが拒否されたリクエストをブロックするには、マネージドルールグループの直後に実行されるルールを追加して、 ルールグループが処理しなかったリクエストをキャプチャしてブロック できます。図5 に示す Token status ペインを参照してトークンを取得するリクエストの量を監視し、そのようなリクエストをレート制限またはブロックするかどうかを決定できます。 図5: トークンステータスではトークンを取得するリクエストの量を監視できます CloudFront セキュリティダッシュボードとの比較 AWS WAF traffic overview ダッシュボードは、AWS WAF で保護されているリソースに到達する Web トラフィックの全体的な可視性を向上させます。一方 CloudFront セキュリティダッシュボード は、AWS WAF の可視性と制御を CloudFront ディストリビューションに直接もたらします。潜在的な脅威や問題を示す可能性のあるパターンの詳細な可視性と分析が必要な場合は、AWS WAF traffic overview ダッシュボードが最適です。アプリケーションの配信とセキュリティを一箇所で管理し、サービスコンソール間を移動することなくアプリケーションのトップセキュリティトレンド、許可および遮断されたトラフィック、ボット活動を確認したい場合は、CloudFront セキュリティダッシュボードの方が適している可能性があります。 可用性と価格設定 新しいダッシュボードは AWS WAF コンソールでトラフィックをより適切に監視できます。デフォルトで無料で利用でき、追加の設定は必要ありません。CloudWatch ロギングには別の価格モデルがあり、フルロギングを有効にしている場合は CloudWatch の料金が発生します。CloudWatch の料金の詳細については こちら をご覧ください。環境のニーズに合わせてダッシュボードをカスタマイズすることもできます。 結論 AWS WAF traffic overview ダッシュボードを使用すると、Web セキュリティの状況と境界保護を改善する必要があるトラフィックパターンについて、実行可能な洞察を得ることができます。 この記事では、ダッシュボードを使用して Web アプリケーションを保護する方法を学びました。トラフィックパターン分析と次の可能なステップを説明しました。さらに、ボットからのトラフィックを観察し、アプリケーションのニーズに応じてそれらに関連するアクションを実行する方法を学びました。 AWS WAF traffic overview ダッシュボードは、ほとんどのユースケースに対応し、Web トラフィックのセキュリティ可視性のデフォルトのオプションとして設計されています。もしカスタムソリューションを作成したい場合は「 Deploy a dashboard for AWS WAF with minimal effort 」というブログのガイダンスを参照してください。 このブログは「 Introducing the AWS WAF traffic overview dashboard 」と題された記事の翻訳となります。 翻訳は Senior Solutions Architect の森が担当しました。

こんにちは、AWS トレーニングデリバリーマネージャー の西村航です。 こんな悩みをかかえている方はいませんか？「生成 AI を勉強したいんだけど何から勉強すればよいだろう？」という方、または「基盤モデルをチューニングしたり自社開発したりすることに興味があるけど、どこかに勉強方法がまとまってないかな？」という方。本記事はそういった 生成 AI を勉強したい初学者の方や生成 AI を活用した開発がしたいエンジニアの方を対象にした記事になります。 どこで生成 AI を勉強するのか？ AWS Skill Builder で勉強しましょう。AWS Skill Builder は AWS のオンライン学習センターです。何度でも視聴できるオンデマンドの AWS デジタルトレーニング、AWS 認定の公式練習問題、ゲーム形式で AWS を学べる AWS Cloud Quest などなど、幅広い AWS 学習コンテンツにアクセスすることができます。さらに AWS Skill Builder の 有償サブスクリプション にお申し込みいただくと、AWS 認定の公式模擬試験、ハンズオンラボ、AWS Jam Journey などの追加コンテンツをお楽しみいただけます。 本記事では 生成 AI を勉強する方法に関して、学習リソースとして AWS Skill Builder やイベント資料・ブログ記事をご紹介しつつ、４つのステップに分けてお話していきます。 ステップは勉強の内容や目的によって分かれています。 ステップ 1：生成 AI の基礎を勉強したい初学者の方 ステップ 2：公開済み生成 AI 基盤モデルや API をまず活用してみたいエンジニアの方 ステップ 3：公開済み生成 AI 基盤モデルをチューニングしたいエンジニアの方 ステップ 4：生成 AI の基盤モデルを自社開発したいエンジニアの方 それではここから各ステップに分けて詳細にお話していきます。 ステップ1. 生成 AI とは 本ステップは、エンジニアロールではない営業職や企画職の方なども含めた生成 AI 初学者を対象に、そもそも生成 AI とは何か？ユースケースは？といった生成 AI の基礎内容を取り扱います。 1. AWS で始める生成系 AI for Entry ：AWS における生成 AI の学習の第一歩となる日本オリジナルコースです。これから生成 AI を業務で活用していく上で、そもそも生成 AI とは何なのか、どのような技術的背景や種類があるのか、業務で活用する上でのユースケースや課題などを学習します。また、それらの課題に対して、AWS がどのように活用できるかを学習します。 2. Generative AI for Executives ：生成 AI の概要を説明するコースです。受講者は、生成 AI とは何か、それがどのようにして経営者の懸念や課題に対応するのか、またどのようにしてビジネスの成長をサポートするのかを学びます。また、AI が数多くの業界に大変革をもたらす可能性をどれほど秘めているのかも学びます。 3. Introduction to Generative AI – Art of the Possible ：3部構成のシリーズの1個目です。生成 AI とそのユースケースやリスクと利点について紹介するコースです。このコースを修了すると、受講者は生成 AI、およびそのリスクと利点の基本を説明できるようになります。また、自身のビジネスでコンテンツ生成をどのように活用できるかを説明できるようになります。 4. Planning a Generative AI Project ：3部構成のシリーズの2個目です。生成 AI に関する技術的な基本と主要な用語について学ぶコースです。また、生成 AI プロジェクトを計画するためのステップを学び、生成 AI を使用するリスクと利点を評価します。 5. Building a Generative AI-Ready Organization ：3部構成のシリーズの3個目です。このコースを修了すると、生成 AI 対応組織の構築に関する主な考慮事項を説明できるようになります。また、従業員をスキルアップさせ、職場に生成 AI の思考を導入するためのツールや知識を身に付けることができます。 6. AI ユースケースエクスプローラー ： AI に関してユースケースを探すことができるサイトになります。業種やビジネス機能やビジネス成果、テクノロジー など複数のフィルタリングメニューから選択することもできますので、興味のあるユースケースが探しやすい構成となっています。 7. 生成系 AI でプロダクトの価値を高めるには ：自社の現状を分析して、生成 AI でプロダクトの価値を上げる3ステップを知ることができる資料です。すぐに始めることができる生成 AI 活用プロジェクトチャートなど AWS の機械学習のサービスをどのように使うのか分かりやすく記載されています。 ステップ2. プロプライエタリ 本ステップでは、エントリーレベルの生成 AI エンジニアの方を対象に、公開済み生成 AI 基盤モデルや API を活用する際に必要な情報を取り扱います。 1. Amazon Bedrock Getting Started ：Amazon Bedrock は生成 AI アプリケーションの構築とスケールを素早く行うための基盤モデルと一連のツールを提供するフルマネージドサービスです。このコースでは、Amazon Bedrock の利点、特徴、一般的なユースケース、技術的概念、コストについて学習します。また、チャットボットソリューションを構築するために、他の AWS サービスと Amazon Bedrock を組み合わせて使用したアーキテクチャも確認することができます。 2. Amazon Bedrock で始める生成系 AI アプリケーション ：Amazon Bedrock を使った 生成 AI アプリケーションでどんなことができるのかを、実際にサンプルアプリケーションを動かしながら紹介するコースです。アプリケーションのコードは公開されていますので、実際に動かしてみたいという方は、動画を見ながら一緒に環境構築してみていただくこともできます。 3. Foundations of Prompt Engineering ：効果的なプロンプトを設計するための原則、テクニック、ベストプラクティスについて学習するコースです。プロンプトエンジニアリングの基礎から高度なプロンプトテクニックまでカバーしています。また、基盤モデルを操作する際に、プロンプトの誤用を防ぎ、バイアスを軽減する方法についても学習します。 4. Amazon CodeWhisperer – Getting Started ：Amazon CodeWhisperer は生成 AI を活用した高度なコーディングコンパニオンで、ユーザーの入力時にユーザーとやり取りしながらコードを提案することで、コーディングの効率と生産性を高めます。このコースでは、サポートされている統合開発環境 (IDE) やコードエディタに CodeWhisperer をインストールして、使用する方法を学習します。 5. Amazon Transcribe Getting Started ：Amazon Transcribe は、音声をテキストに変換できるフルマネージドの人工知能 (AI) サービスで、自動音声認識技術 (ASR) を用いて音声をテキストに変換します。この Getting Started コースでは、Amazon Transcribe の利点、特徴、一般的なユースケース、技術的概念、コストについて学習します。 6. Amazon Kendra Getting Started ：Amazon Kendra は、機械学習による高精度な検索結果と非構造化データの検索機能を提供する自然言語検索サービスです。このコースでは、Amazon Kendra の利点、特徴、一般的なユースケース、技術的概念について学習します。また、ユースケースにさらに適応できる Amazon Kendra を使用した検索ソリューションのアーキテクチャも確認します。 7. PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス ：PartyRock は生成 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。PartyRock でアプリケーションを作成してカスタマイズして公開する一連の流れをブログ記事で確認することができます。 8. Build Using Amazon CodeWhisperer ：AWS の安全なサンドボックス環境で一連の課題をこなすことで、DevOps プロフェッショナルの皆様に Amazon CodeWhisperer による構築を実際に経験してもらう、実践的なハンズオンラボです。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 9. Build a Question-answering Bot using Generative AI ：このハンズオンラボでは、AWS のサービスに関する質問に答えるチャットボットを作成します。ハンズオンラボは、大規模言語モデル (LLM) のデプロイ、Amazon Kendra データソースとの統合、さらに、ユーザーの質問に対する回答を見つけるために、LLM にクエリを実行して検索拡張生成 (RAG) を使用する Amazon Lex V2 チャットボットの作成といった実践的な経験を提供するよう設計されていますので、このハンズオンラボを実施することで言語モデルの基本的な機能に情報を追加して強化する方法を理解できます。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 ステップ3. チューニング 本ステップでは、ミドル〜ハイレベルの生成 AI エンジニアの方を対象に、公開済み生成 AI 基盤モデルをチューニングする情報を取り扱います。 1. Amazon SageMaker JumpStart で始める生成系AI ：Amazon SageMaker は、機械学習モデルの構築、トレーニング、デプロイを簡単にするフルマネージドサービスです。このコースでは、生成 AI に興味があるが、どのように始めればよいかわからないという方に向けて、Amazon SageMaker を使って、シンプルかつ迅速に生成 AI の基盤モデルをデプロイしたり、チューニングする方法を紹介します。Amazon SageMaker の機能には、ユーザーが迅速に機械学習を開始できるよう Amazon SageMaker JumpStart と呼ばれる機械学習ハブが含まれています。今回のコースでは、画像生成のユースケースをテーマに、Amazon SageMaker JumpStart で公開されている基盤モデルの利用方法をデモ動画で解説していきます。 2. AWS Cloud Quest: Machine Learning ：AWS Cloud Quest は、AWSのサービスを利用した演習や実習を通して、実践的なAWSスキルを身につけることができるロールベースの学習ゲームです。AWS Cloud Quest ではいくつかの技術領域から選択できるロールがありますが、本 Machine Learning Role では AWS AI サービスを使用したソリューション構築を支援するソリューション構築課題を探索します。なお、2024年3月時点では英語版のみの提供となります。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 3. Jam Journey GenAI re:Invent 2023 ：re:Invent 2023 にて使用されたハンズオンラボです。AWS 環境を触りながら与えられた課題を解決していく実践形式のハンズオンラボで、生成 AI をテーマにした課題が複数ピックアップされています。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 4. AWS AI Week For Developers ：オンラインイベント AWS AI Week for Developers の動画を YouTube で視聴することができます。生成 AI を中心とした AI 技術の基礎から最新情報、そして開発者視点の活用方法 / 適用事例など、「まだ生成 AI について十分な知識がない」とお考えの方から、すでに知識をお持ちの方まで、スキルレベルに合わせた内容になっており、どなたにもお楽しみいただけるコンテンツとなっております。 ステップ4. スクラッチ 本ステップでは、ミドル〜ハイレベルの生成 AI エンジニアの方を対象に、生成 AI の基盤モデルを自社開発する際に必要な情報を取り扱います。 1. AWS で作る自社用基盤モデル (YouTube) ：本セッションでは、AWS が提供する機械学習基盤を活用して、自社用の大規模言語モデルを独自に学習させるためのベストプラクティスや事例について取り扱います。基盤モデルの特徴と独自構築の必要性、基盤モデル構築のための開発プロセス、基盤モデル作成に関わる AWS の支援体制・テクノロジーを順を追ってお話します。 2. AWS での生成 AI 基礎 Technical Deep Dive Series ：YouTube にて視聴できる英語の動画コンテンツになります。本コンテンツでは、最先端の基盤モデルを事前トレーニング、ファインチューニング、デプロイするための概念的な基礎、実践的なアドバイス、実践的なガイダンスなど技術的に深堀りすることができます。 3. 大規模言語モデルからはじめる生成AI ：DeepLearning.AI と AWS が共同で Coursera 上で提供するコースです。このコースを受講することにより、データサイエンティストやエンジニアの方は、実世界のアプリケーション向けに LLM を選択、トレーニング、ファインチューニング、デプロイするエキスパートになるための準備を整えることができます。このオンデマンドコースは、約 16 時間の動画、クイズ、ハンズオンラボ、追加の読み物を含む 3 週間のコンテンツで構成されています。 4. FMOps/LLMOps : 生成系 AI の運用と MLOps との違い ：最近、多くのお客様は大規模言語モデル (Large Language Model: LLM) に高い期待を示しており、生成 AI がビジネスをどのように変革できるか考えています。しかし、そのようなソリューションやモデルをビジネスの日常業務に持ち込むことは簡単な作業ではありません。本ブログ記事では、MLOps の原則を利用して生成 AI アプリケーションを運用化する方法について説明します。これにより、基盤モデル運用 (FMOps) の基盤が築かれます。さらに、Text to Text のアプリケーションや LLM 運用 (LLMOps) について深掘りします。 Next Action Next Action では、さらに生成 AI を活用したシステム構築に向けて提案や実装方法の引き出しを増やしていくための、ワークショップ・フレームワーク・事例を取り扱います。 Action 1. Workshop で理解を深める 1. Generative AI Use Cases JP ：生成 AI を活用したビジネスユースケースのデモンストレーションです。 2. Amazon Bedrock Workshop ：Amazon Bedrock を通じて基盤モデルを活用する実践的な体験を提供するワークショップです。 3. Generative AI Workshop ：ユースケースに活用できる生成 AI モデルの構築、トレーニング、デプロイについて、エンドツーエンドで理解できるワークショップです。 4. ML Enablement Workshop ：組織横断的にチームを組成し、機械学習による成長サイクルを実現する計画を立てるワークショップです。 Action 2. フレームワークを理解する 1. CAF-AI ：CAF-AI は AI への移行を支援する目的で設計されており、AI/ML によってビジネス価値を生み出そうとする組織にとってのメンタルモデルを示しています。 2. Machine Learning Lens | AWS Well-Architected ：MLワークロードを設計する際に適用することができるガイダンスとアーキテクチャーの原則です。 Action 3. 事例やアップデートを確認する 1. AWS サービス別資料 (機械学習とAI) ：AI/ML のサービス別資料です。 2. AWS Summit Tokyo 2023(機械学習とAI) ：AI/ML カテゴリの AWS Summit Tokyo 2023 セッション資料です。 3. AWS ブログ(カテゴリ：GenerativeAI) ：AWS 公式ブログに投稿されている生成 AI の記事です。 まとめ 本記事では AWS Skill Builder で生成 AI を勉強する 4 ステップ を紹介しました。 今日から早速始めてみましょう。 最後まで読んでいただき、本当にありがとうございました！ 著者について 西村 航 (Wataru Nishimura) @kuwablo AWS トレーニングサービス本部 トレーニングデリバリーマネージャー ジャスミン茶が好きです。

Claude 3 によってパワーアップされた生成 AI、Next.js、 AWS Amplify 、 Amazon Bedrock &nbsp;の世界に飛び込んでいきましょう。このガイドでは、ユーザーが食材のリストを入力し、Claude 3 が入力された食材にもとづいて美味しいレシピを提案するレシピ提案アプリの作成方法を紹介します。 2023 年 11 月、AWS Amplify は次世代のフルスタックアプリ構築機能の パブリックプレビュー を発表しました。 Amplify Gen 2 はコードファーストの開発者エクスペリエンスを採用しており、開発者は TypeScript と AWS Cloud Development Kit ( AWS CDK ) を使用して、認証やデータ利用のユースケースを含むクラウドリソースを定義およびプロビジョニングできます。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの先進的な AI 企業から選択した高性能な基盤モデル (FM) をフルマネージドで提供するサービスです。単一の API を通じてこれらのモデルにアクセスできるほか、セキュリティ、プライバシー、責任ある AI の観点を考慮した生成型 AI アプリケーションを構築するために必要な幅広い機能を利用できます。Amazon Bedrock では、選択したモデルに関係なく単一の API にアクセスできるため、異なる FM を利用したり、コード変更を最小限に抑えて最新バージョンのモデルにアップグレードしたりする柔軟性が得られます。 AWS Amplify は、データ管理、UI コンポーネント、ホスティングなどの機能群を提供し、クラウドでの Web アプリ開発を加速します。生成AI アプリを構築する際、Amplify はプロセスを簡略化し、シームレスな開発に必要なツールを提供します。さらに、AWS CDK が Amplify Gen 2 を動作させることで、Amazon Bedrock への接続はほんの数行のコードで実現できます。この強力な組み合わせにより、レシピジェネレーターアプリの開発、デプロイ、スケーリングを効率的に行うとともに、セキュリティとパフォーマンスを確保できます。 前提条件 AWS アカウント 。Amplify は AWS 無料利用枠 が含まれています。 Node.js v18.17 以降 npm v9 以降 git v2.14.1 以降 テキストエディタ。このガイドでは VSCode を使用しますが、好みの IDE を使用できます。 Amazon Bedrock モデルアクセス Amazon Bedrock を使用すると、ユーザーはさまざまな生成 AI モデルへのアクセスをリクエストできます。 この例では、Anthropic の Claude 3 Sonnet へのアクセスが必要です。 以下の手順に従ってアクセスをリクエストしてください。 ステップ 1: AWS コンソールにサインインし、Amazon Bedrock に移動します。リージョン選択から us-east-1 リージョンを選択します。 ステップ 2: Claude モデルを選択し、 「モデルアクセスをリクエスト」 ボタンをクリックしてください。 ステップ 3: &nbsp; 「モデルアクセスを管理」 ボタンを選択 ステップ 4: Claude 3 Sonnet のオプションをチェックし、 「変更を保存」 ボタンをクリックしてください。 リポジトリのクローン ステップ 1: AWS Samples の リポジトリ に移動し、Fork ボタンから自分のリポジトリに Fork します ステップ 2: 端末で以下のコマンドを実行してアプリをクローンします git clone https://github.com/[REPLACE_YOUR_GITHUB_NAME]/recipe-ai ステップ 3: 端末で以下のコマンドを実行することで、VSCode で新しくクローンしたリポジトリのディレクトリを開きます。 cd recipe-ai code . -r VSCode でリポジトリフォルダを開きます。amplify ディレクトリにはバックエンドの詳細設定が含まれています。（次のセクションで説明します） ステップ 4: 以下のコマンドを実行して、Amplify Gen 2 パッケージを含む必要なパッケージをインストールします npm ｃi Amplify バックエンド 最終的なアプリ(記事の冒頭の gif を参照)では、ユーザーは食材を入力し、Amazon Bedrock からレシピをリクエストするボタンをクリックします。 このコードはクローンしたリポジトリにあります。 ここでは、Amplify アプリを Amazon Bedrock と接続するための主要なステップを説明します。 リポジトリには、データディレクトリを含む amplify フォルダがあります。 amplify/data/resource.ts ファイルには、食材のリストを受け取り、それらの食材に基づいてレシピを生成するために Amazon Bedrock にリンクできる GraphQL クエリを定義しました。このクエリは、Amazon Bedrock からのレスポンスを構造化するためにカスタムタイプを使用します。 GraphQL API のスキーマは 2 つの主要な部分から構成されます: askBedrock クエリは、 ingredients という文字列の配列を受け取り、 BedrockResponse を返します。 .authorization([a.allow.public()]) を使用して公開アクセス可能にしました。 .handler(a.handler.custom({ entry: "./bedrock.js", dataSource: "bedrockDS" })) 行は、 bedrockDS をデータソースとして使用し、 bedrock.js 内で定義されているこのクエリのカスタムハンドラを設定します。 BedrockResponse は body と error の 2 つの文字列型フィールドを持つカスタムタイプです。このカスタムタイプは、 askBedrock クエリからのレスポンスを構造化するために使用されます。 ... const schema = a.schema({ BedrockResponse: a.customType({ body: a.string(), error: a.string(), }), askBedrock: a .query() .arguments({ ingredients: a.string().array() }) .returns(a.ref("BedrockResponse")) .authorization([a.allow.public()]) .handler( a.handler.custom({ entry: "./bedrock.js", dataSource: "bedrockDS" }) ), }); ... amplify/backend.ts ファイルでは、Amazon Bedrock へのクエリを接続するために bedrockDS という名前の HTTP データソースを作成します。このデータソースは、 us-east-1 リージョンの Bedrock サービスに関連付けられています。さらに、 addToPrincipalPolicy メソッドを使用して、 bedrockDS データソースのプリンシパルに新しいポリシーを追加します。ポリシーステートメントは、許可されたリソースとアクションを指定します。この場合、リソースは Claude 3 モデルの AWS ARN(Amazon リソースネーム)であり、許可されたアクションは bedrock:InvokeModel です。 const bedrockDataSource = backend.data.resources.graphqlApi.addHttpDataSource( "bedrockDS", "https://bedrock-runtime.us-east-1.amazonaws.com", { authorizationConfig: { signingRegion: "us-east-1", signingServiceName: "bedrock", }, } ); bedrockDataSource.grantPrincipal.addToPrincipalPolicy( new PolicyStatement({ resources: [ "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0", ], actions: ["bedrock:InvokeModel"], }) ); amplify/data/bedrock.js &nbsp;ファイルには、 askBedrock ハンドラの実装のロジックが含まれています。 これは、クエリの入力パラメータ、つまり ingredients を利用してプロンプトを生成し、メッセージ配列の一部としてプロンプト文字列をリクエスト本文に含めることで、Claude 3 モデルに対して POST リクエストを使用し、 HTTP データソース (今回はAmazon Bedrock) に送信します。 export function request(ctx) { const { ingredients = [] } = ctx.args ; const prompt = `Suggest a recipe idea using these ingredients : ${ ingredients.join( "," )}.` ; return { resourcePath: `/model/anthropic.claude-3-sonnet-20240229-v1:0/invoke`, method: "POST", params: { headers: { "Content-Type": "application/json", }, body: { anthropic_version: "bedrock-2023-05-31", max_tokens: 1000, messages: [ { role: "user", content: [ { type: "text", text: `\n\nHuman:${ prompt } \n\nAssistant:`, }, ], }, ], }, }, }; } export function response(ctx) { return { body: ctx.result.body, }; } アプリを実行すると(次のセクションで示されているように)、 amplifyconfiguration.json という名前のファイルが自動的に生成されます。このファイルには、API のエンドポイントの詳細が含まれています。 src/app/amplify-utils.ts で、以下のように Amplify クライアントライブラリを初期化して設定します。次に、Amplify バックエンドへの完全型付き API リクエストを容易にするデータクライアントを作成します。 import config from "@/../amplifyconfiguration.json"; import { Amplify } from "aws-amplify"; import { generateClient } from "aws-amplify/data"; import { type Schema } from "../../amplify/data/resource"; Amplify.configure(config); export const amplifyClient = generateClient(); このアプリは、 src/app/page.tsx ファイルを使用して、食材のリストを送信するためのフォームをユーザーに提示します。 送信されると、 src/app/actions.ts ファイルの generateRecipe 関数が呼び出され、生成されたレシピを取得してユーザーに表示します。 src/app/actions.ts ファイルには、 generateRecipe 関数があります。この関数は Amplify クライアントを利用して askBedrock クエリを呼び出し、食材をパラメータとして渡して Amazon Bedrock から AI 生成されたレシピを取得します。 import { amplifyClient } from "./amplify-utils"; export async function generateRecipe(formData: FormData) { const response = await amplifyClient.queries.askBedrock({ ingredients: [formData.get("ingredients")?.toString() || ""], }); const res = JSON.parse(response.data ?.body !); const content = res.content[0].text ; return content || ""; } アプリの実行 ステップ 1 : Amplify は各開発者に個人用のクラウド サンドボックス環境を提供し、高速なビルド、テスト、反復のための隔離された開発スペースを提供します。クラウド サンドボックス環境を開始するには、新しいターミナル ウィンドウを開き、次のコマンドを実行します: npx amplify sandbox ステップ 2: ローカルホスト開発サーバーを起動するために、以下のコマンドを実行します。 npm run dev アプリのデプロイ アプリが正しく機能するようになったので、Amplify でデプロイしてホストしましょう。Amplify は、組み込みの CI/CD を備えたフルマネージドのホスティングサービスを提供し、Git ブランチを使用した本番環境とステージング環境の設定を簡素化します。Gen 2 では、リポジトリの各 Git ブランチごとに Amplify のフルスタック環境が作成されます。 ステップ 1: AWS コンソールにサインインし、使用したい AWS リージョンを選択します。パブリックプレビューのバナーをクリックし、「 Amplify Gen 2 を試す 」を選択します。 ステップ 2 : 「オプション 2: 既存のアプリケーションを使用して開始」 を選択し、 GitHub を選んだ後、 「次へ」 を選択して進めます。 ステップ 3 GitHub にログインし、「 Authorize AWS Amplify 」ボタンをクリックします。 ステップ 4: ドロップダウンリストからリポジトリとブランチを選択し、 「次へ」 を選択して進めます。 注: ドロップダウンリストにリポジトリが表示されない場合は、「 View GitHub permissions 」ボタンをクリックしてください。次に、リポジトリを選択し、アクセスを許可するために「 Install &amp; Authorize 」ボタンをクリックしてください。 ステップ 5: 設定を確認し、 「次へ」&nbsp; ボタンをクリックして進めてください。 ステップ 6: 最後に、「 保存してデプロイ 」ボタンをクリックして、デプロイプロセスを開始します。 ステップ 7: デプロイプロセスが完了するのを待ち、 「デプロイされたURLにアクセス」 ボタンを使用して Web アプリを開きます。 リソースのクリーンアップ このチュートリアルを終えたので、以下に示すように Amplify コンソールからアプリを削除することで、バックエンドリソースを削除し予期しないコストを防ぐことができます。 結論 おめでとうございます! AWS Amplify Gen 2 と Amazon Bedrock を使用して、生成 AI の力を借りたレシピジェネレーターアプリを開発することに成功しました。 加えて、Amplify Hosting を使用して AWS にアプリをデプロイしました。 Amplify Gen 2 を始めるには、 クイックスタートチュートリアル をお試しください。 フィードバックや機能リクエストは、 コミュニティ Discord にご参加ください。 この記事は、 Use Generative AI and Next.js with AWS Amplify to build a Fullstack Recipe Generator を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。 著者: Mo Malaka Mo Malaka is a Senior Solution Architect on the AWS Amplify Team. The Solution Architecture team educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Mo enjoys using technology to solve problems and making people ’ s lives easier. You can find Mo on YouTube or on Twitter .

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 寒暖差が激しく体調管理が難しいですが、みなさんいかがお過ごしでしょうか？ 自分は数年ぶりに風邪をひいてしまい、やっと回復しました。みなさんもお気を付けください。 さて、直近でいくつかイベントが予定されています。ご都合つく方はぜひご活用ください！ 2024 年 3 月 28 日 (木) – サーバレスで始めるAWS データベースサービス-RDS/Aurora編 – AWS 物流 DX セミナー 2024 2024 年 4 月 11 日 (木) – IBM Db2 の資産を AWS で活用する – 生成 AI の新展開 – マルチモーダル生成 AI の活用方法 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年3月18日週の主要なアップデート 3/18(月) Get visibility to your auto deployment configuration with a new StackSets API AWS CloudFromation StackSetsにListStackSetAutoDeploymentTargets APIが追加されました。AWS CloudFormation StackSetsは、複数のアカウントおよび AWS リージョン のスタックを 1 度のオペレーションで、作成、更新、削除できるようにする機能です。StackSetsはOUをターゲットにすることができますが、自動デプロイする際OUによって利用可能なリージョンが違う場合、どのOUのどのリージョンに適用されているか各アカウントにログインして確認する必要がありました。今回のアップデートはこれを一覧表示できるAPIのリリースです。 AWS Secrets Manager announces support for Amazon Redshift Serverless data warehouse AWS Secrets ManagerがAmazon Redfhift サーバレスをサポートしました。これにより、データウェアハウスへのユーザー認証情報のローテーションを管理するといった認証情報の面倒な作業が不要になり、AWS Secrets Managerから直接作成および設定が可能になります。この機能はAmazon Redshift サーバーレスが利用可能なすべての AWS リージョンでご利用いただけます。詳細は ドキュメント もご確認ください。 New Amazon SageMaker integration with NVIDIA NIM inference microservices Amazon SageMakerとNVIDIA NIM inference microservicesが統合され、NVIDIAアクセラレータコンピューティングインフラストラクチャ上で大規模言語モデル(LLM)の価格パフォーマンスをさらに向上させることができるようになりました。NIMはNVIDIA AI エンタープライズソフトウェアプラットフォームの一部としてLLMによる推論用の高性能なAIコンテナを提供する機能です。推論のために最適化された様々なLLMのコンテナを提供しており。Llama 2 (7B、13B、70B)、Mistral-7b-Instruct、Mixtral-8x7b、NVIDIA Nemotron-3 などがサポートされる他、それ以外のモデルのGPU最適化バージョンを作成するためのツールも提供します。Amazon SageMaker が利用可能なすべての AWS リージョンでアクセスできます。詳細については ブログ もご確認ください。 Amazon Managed Service for Apache Flink adds support for Apache Flink 1.18 Amazon Managed Service for Apache FlinkがApache Flink 1.18をサポートしました。Ver 1.18で新たにサポートされる機能などの詳細については ドキュメント をご確認ください。同時にAmazon Managed Service for Apache Flinkの インプレースアップグレードのサポート も発表されています。これによりより簡素にトレーサビリティを確保してアップグレードが可能です。インプレースアップグレードの詳細は こちら もご確認ください。 3/19(火) Amazon Corretto 22 is now generally available Amazon Corretto 22の一般提供がGAしました。Linux, MacOS, Windows各々のバージョンを こちら からダウンロード可能です。OpenJDK 22のフィーチャーリリースの詳細に関しては OpenJDK 22のプロジェクトページ をご確認ください。 Amazon DynamoDB now supports AWS PrivateLink DynamoDBがPrivateLinkをサポートしました。これによりVPCや、オンプレミスからのプライベートネットワークからインターフェイスエンドポイントを介してアクセス可能になります。DynamoDBのPrivateLinkは全ての商用リージョンで使用可能です。詳細は ドキュメント もご確認ください。 AWS CodeBuild now supports custom images for AWS Lambda compute AWS CodeBuildで、AWS Lambda を使用してソフトウェアパッケージのビルドとテストを実行する際に、これまではマネージドコンテナイメージのみ利用可能でした。今回のアップデートによりLambdaの場合もAmazon ECRに保存されているコンテナイメージを使用できるようになり柔軟性が上がります。このアップデートは東京を含む10のリージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 3/20(水) AWS announces a 7-day window to return Savings Plans Savings Plansを購入後、7日以内であれば返品できるようになりました。Savings Plansは柔軟な価格設定モデルで、1年または3年の利用契約をすることで、最大72%削減できる購入方法です。今回のアップデートで購入した後に最適ではないと気付いた場合に返品し、別の貯蓄プランを再購入でるようになりました。この機能は、中国リージョンを除くすべての AWS リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Neptune Database is now available in AWS Asia Pacific (Osaka) Region 大阪リージョンでAmazon Neptuneをご利用可能になりました。エンジンバージョン 1.1.0.0 以降および、R5、R5d、R6g、R6i、X2g、T4g、サーバーレスのインスタンスタイプがご利用いただけます。 Amazon Aurora zero-ETL integration with Amazon Redshift announces support for data filtering and CloudFormation Amazon MySQL to RedshiftのZero-ETL integrationでデータフィルタリングと、CloudFormationによるリソース設定・デプロイをサポートしました。データフィルタリングを使うことでレプリケートされるデータベースやテーブルを指定することができるので、より効率的にデータ分析との統合が可能になります。この機能は東京を含む9のリージョンでご利用いただけます。こちらの ブログ もご確認ください。 Amazon DynamoDB now supports resource-based policies Amazon DynamoDBがリソースベースのポリシーをサポートしました。リソースにアクセスできるIDおよびIAMプリンパルと、実行できるアクションを指定することが可能です。これにより、IAMプリンシパルによるクロスアカウントアクセスの制御も簡素化することができます。この機能はすべてのAWS 商用リージョンで利用できます。詳細については ドキュメント もご確認ください。 3/21(木) Amazon RDS Multi-AZ deployments with readable standby instances now support C6gd database instances Amazon RDSのc6gdインスタンスが２つの2つの読み取り可能なスタンバイを備えたマルチAZ 構成をサポートしました。PostgreSQLのバージョン 16.1以降、15.2以降、14.5以降、13.8以降、およびMySQLのバージョン 8.0.28以降で利用できます。東京、大阪リージョンを含む14のリージョンで利用可能です。 Announcing Package Group Configuration in AWS CodeArtifact AWS CodeArtifactがパッケージグループ設定の機能をサポートしました。この機能を使うと、パッケージ形式、名前空間および名前に基づいてCodeArtifactのパッケージをグループ定義できます。パッケージグループにPublish、External Upstream、Internal Upstreamのルール設定ができるため、意図しない公開や、パブリックリポジトリからのインポートを制御しセキュリティを強化できます。 3/22(金) Amazon DataZone launches enhancements to Amazon Redshift integration Amazon DataZoneとAmazon Redshiftの統合機能が強化されました。Datazone管理者はDefaultDatawarehouseBlueprint上にパラメーターセットを作成することができるようになりました。パラメーターセットを元にして環境プロファイルを作成することで、利用者は自分でパラメータ設定することなく環境を作成できるためプロセスを簡略化できます。この機能は東京を含む13のリージョンで利用可能です。詳細は ドキュメント もご確認ください。 Amazon MSK Connect now supports deleting worker configurations and tagging resources Amazon MSK ConnectでCloudFormationを利用したワーカー設定の削除やリソースのタグ付、カスタムプラグインの管理等がサポートされました。このアップデートによりリソースの管理やデプロイの自動化が容易になります。これらの機能はAmazon MSK Connect が利用可能なすべてのAWSリージョンでご利用いただけます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

※このブログは ” Highlighting modern innovations in cloud-based broadcast production at Inter BEE 2023 ” を翻訳したものです。 このブログは、Waves Audio Ltd のアソシエイト・プロダクト・マネージャー兼プロダクト・アプリケーション・エンジニアである Daniel Kamhaji が共同執筆しています。 はじめに このブログ記事では、 2023 年 11 月 15 日～ 17 日に幕張メッセで開催された Inter BEE で、アマゾンウェブサービス（ AWS ）ジャパンが紹介した、クラウドベースの放送制作における最新のイノベーションについて詳しく説明します。Inter BEE 2023 の AWS ブースでの Waves Cloud MX の役割に焦点を当てて、放送制作を形作るテクノロジーとコラボレーションをご紹介します。イノベーションが、信頼性が高く高度なライブプロダクションワークフローの基準をどのように設定しているかを明らかにします。さらに、AWS が提供するシグナルフローと配信サービスについても触れ、それらが日本市場に与える影響と、世界中のライブ放送とメディア制作の進化する状況に焦点を当てています。 Inter BEE 2023 における AWS ブース AWS Japan ブースで Waves Audio や業界のリーダーたちと未来の放送技術を紹介 国際放送機器展「 Inter BEE 」は、コンテンツビジネスにおける最新のイノベーションをグローバルに紹介する展示会です。毎年開催されるこのイベントと展示会は、テクノロジーの先駆者たちとのコラボレーションの拠点となり、放送ソリューションとワークフローの機能を紹介しています。Waves Audio Ltd. は、Inter BEE 2023 に AWS Japan と共に参加し、クラウドワークフローにおける業界の革新を紹介し、ライブ放送制作技術の一連のツール群を紹介しました。業界リーダー間の団結を示すブースでは、 ソニーの M2L-X ソフトウェアビジョンスイッチャー 、 SiennaND プロセッシングエンジン 、 Viz Trio &amp; &nbsp; Viz Engine 、 Telos Alliance Infinity VIP 、 Ateme TitanLive 、 LiveU Cloud Connect 、 TAG Video Systems &nbsp;Multiviewer 、 Waves Cloud &nbsp;MX オーディオミキシングプラットフォーム 、基本的なメディアサービス機能を提供する AWS Elemental により統合されました。これらの要素が一体となって、現在の技術的実装度合いを実証し、放送制作の発展のための実践的な青写真を提供するまとまりのあるエコシステムを作り上げています。 Inter BEE 2023 の AWS ブースでのライブプロダクション・デモンストレーションシステム コア接続 : NDI プロトコルによるストリームの簡略化 NDI (ネットワーク・デバイス・インターフェース) は、NewTek が標準的な LAN ネットワークを使用した IP 伝送およびライブプロダクション用に開発したオープンプロトコルです。その使いやすさと信頼性により、制作チェーンのさまざまな要素をつなぎ、理解のしやすさと信頼性によりプロセスの合理化を促進する、放送環境における魅力的なツールとなっています。 オペレーターのための操作方法 Waves Cloud MX は中心的な役割を担い、NDI オーディオ入力をライブフィードとして 4ch 、NDI による追加の 8ch のローカル再生を巧みにミックスして、洗練された最終ミックスを生み出しました。 NVIDIA GRID &nbsp;ドライバーを搭載した Windows サーバー上で g4dn.4xlarge タイプの &nbsp; Amazon Elastic Compute Cloud &nbsp;(Amazon EC2) インスタンスを活用することで、本番環境では CPU パワーをオンデマンドでスケールアップし、必要に応じて最適なパフォーマンスを実現できます。 この適応性により、オペレーターはオーディオ処理用の広範なツールキットを活用できます。これらには、複数のマイクのリアルタイム自動バランスを実現する Dugan Speech プラグイン 、複雑なオーディオシェーピング用の F6 Floating-Band Dynamic EQ 、正確なノイズ抑制用の WNS 、正確なラウドネスメータリング用の WLM および Dorrough プラグインなどがあり、それぞれがプレミアムなサウンド体験に貢献しています。 150 種類以上の Waves プラグインを幅広く取り揃えているため、オーディオプロフェッショナルに豊富なインテリジェントでクリエイティブな機能を提供できます。Cloud MX のライセンスは &nbsp; Amazon Elastic Block Store &nbsp;(EBS) ドライブでアクティベートされるため、インスタンス間のライセンス移動が容易になり、デプロイプロセスが合理化されます。 NICE DCVとWaves FITコントローラーによる制御と仮想化の強化 操作感とバーチャルを融合させた Waves FIT コントロールサーフェス は、オーディオオペレーターにハンズオンフェーダーとエンコーダーインターフェースを提供します。コントローラーはローカルコンピューターに直接接続され、Amazon EC2 環境の RTP Midi を介して UDP IP パケットを介して制御情報を送信します。このセットアップにより、低レイテンシー測定により、オペレーターとクラウド間の応答性が向上します。 NICE DCV とタッチパネルディスプレイは、もう1つのコントロールサーフェスとしてリモートデスクトップ操作を提供しました。ユーザーは複数のタッチディスプレイでミキサーを操作でき、Waves Cloud MX の EC2 インスタンスに接続することで、ミキサーのウィンドウを好みに合わせて柔軟に広げたり配置したりできます。これにより、オペレーターは NICE DCV を介してローカルコンピューターのスピーカー構成でオーディオをモニタリングすることもでき、専用の Waves ASIO NDI コントロールパネルを使用してさまざまなオーディオドライバーやプロトコルの制限を回避できます。これにより、オーディオを Windows システムオーディオに送ることができます。 タッチスクリーンとフィットコントローラーを備えた Waves オーディオディスプレイ シグナルフロー : ライブ制作の全体像 1. このシステムの信号フローは、定義された経路をたどります。セキュア・リライアブル・トランスポート（ SRT ）ストリームは、Sienna の「 IP Connect SRT 」を介してオンプレミスの場所から送信され、NDI ストリームに変換され、本番環境ですぐに使用できます。 2. ブースのプレゼンテーションステージでは、 AWS Elemental Link デバイスを使用してライブ映像を撮影しました。これらのデバイスは、エンコーディングにおいて重要な役割を果たし、カメラやビデオ制作機器などのライブビデオソースをクラウドにリンクします。 3. さらに、LiveU は自社の LiveU Cloud Connect ソリューションを使用して、ブースでライブ信号を提供しました。このシステムは、LiveU LU800 マルチカメラフィールドユニットと LiveU クラウド EC2 インスタンスを効率的にブリッジし、LiveU の信頼性の高いトランスポートストリームプロトコル（ LRT ）を介したスムーズで統合された接続を保証します。 4. Amazon S3 &nbsp;はシステムのコアリポジトリとして機能し、Sienna ND プロセッシングエンジン、ソニーのスイッチャー、Waves Audio などの要素間でコンテンツを共有できます。デモシステムのメイン配信ハブおよび中央ストレージとして機能し、各パートナーソリューション用のビデオファイルやオーディオファイルなどのコンテンツを準備します。 5. その後、EC2 インスタンスでホストされる Sienna ND プロセッシングエンジンは、受信ストリームを処理し、メディアソースから追加のストリームを作成します。これにより、NDI 対応カメラからのライブフィードと事前に録画されたコンテンツの両方が、制作セットアップ内の目的の宛先向けに管理および準備されます。 6. NDI ストリームがセットアップをナビゲートすると、ソニー のM2L-X ソフトウェアベースのスイッチャーが ソニー製コントロールパネルでビデオスイッチングを管理し、エクスペリエンスをさらに向上させます。さらに、Viz Trio と Viz Engine によるグラフィックの強化により、視覚体験がさらに洗練され、リアルタイムのグラフィックレンダリングと管理が可能になり、視覚的に魅力的でダイナミックなライブコンテンツが視聴者に配信されます。同時に、32 ビットの浮動小数点倍精度ミックスエンジンを搭載した Waves Cloud MX は、オーディオフィードをミキシングして処理します。ミキサーは、処理されたオーディオを NDI を介して Sienna ND の「 NDIソースコネクト 」に送り、次に「オーディオエンベッダー」に送り、そこでビデオと同期します。その後、この新しい結合フィードは、ソニーのスイッチャーを介してループバックされます。 7. 番組全体は SRT ストリームを介して &nbsp; AWS Elemental MediaConnect にブロードキャストされ、そこでライブビデオフィードの管理と配信が実行されます。 この段階で、 SRT 信号は Ateme TitanLive を通過し、ライブプロダクションとマスタープレイアウトシステムの間の接続ブリッジとして機能し、そこでライブビデオフィードを管理および配信します。その後、Ateme TitanLive は放送を複数のストリーミングプラットフォームに配信し、コンテンツの作成から視聴までの流れを完了します。さらに、 AWS Elemental MediaConnect の出力信号は、 TAG VS Multiveier ソリューションと &nbsp;&nbsp; AWS Elemental MediaLive に送られ、クラウドマスタープレイアウトのデモンストレーションに向けてさらにモニタリングと処理が行われます。 ライブプロダクションデプロイメントのアーキテクチャ概要 結論 : 業界をリードするソリューションを統合して放送技術を進歩させる Inter BEE 2023 はクラウドベースの放送制作技術におけるイノベーションのショーケースだった。さまざまなメーカーの統合や AWS サービスの使用など、これらの進歩は、ライブ放送制作のワークフローに革命をもたらしています。これは、信頼性と最先端のパフォーマンスへのこだわりが日本市場ですでに話題を呼んでおり、ライブ放送やメディア制作への期待を変えています。 詳細については、以下のリソースを参照してください。 Inter BEE ウェブサイト 国際放送機器展とその業界における意義について詳しくは、Inter BEE の公式ウェブサイトをご覧ください。 WavesAudio ウェブサイト Waves Audio のウェブサイトにアクセスして、Waves Cloud MX をはじめとするオーディオミキシング技術の最新イノベーションをご覧ください。 ソニー M2L-X ソフトウェアビジョンスイッチャー ソニーの M2L-X ソフトウェアビジョンスイッチャーと、ビデオスイッチングテクノロジーにおけるその役割などについて詳しく学んでください。 Viz Trio と Viz Engine これらのテクノロジーの詳細については、Viz Trio と Viz Engine のサイトをご覧ください。 SiennaND プロセッシングエンジン さまざまなプロトコルなどのストリーム処理のための主要コンポーネントである SiennaND プロセッシングエンジンをご覧ください。 NDI (ネットワークデバイスインターフェイス) 中核となる接続フレームワークである NDI と、オーディオストリームとビデオストリームの統合を簡素化する上での NDI の役割について学んでください。 Ateme TitanLive Ateme TitanLive がさまざまなストリーミングプラットフォームへの放送コンテンツの配信にどのように貢献しているかをご覧ください。 Telos Alliance Infinity VIP このテクノロジーの詳細については、Telos Alliance Infinity VIP ページをご覧ください。 LiveU Cloud Connect IP ベースのライブブロードキャストソリューションの詳細については、LiveU Cloud Connect ページを参照してください。 Tag Video Systems Multiviewer Tag Video Systems Multiviewer の詳細をご覧ください。 メディア・ インテグレーション株式会社 日本最大のプロ仕様制作ソフトウェアの販売代理店であり、Waves 製品の日本における公式再販業者です。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 執筆及び翻訳は SA 斎藤、確認は SA 小林が担当しました。原文は こちら をご覧ください。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。前半については、 こちらのリンク からご確認ください。 4．クラウド利活用の重要なポイント 一方、私たちが新たにクラウド上での開発を進めている次世代スマートメーターシステムでは、前回の 第 2 回のブログの 3 章 でご紹介したように、疎結合アーキテクチャによる拡張性とシステム開発に対する柔軟性、高い可用性の実現、マネージドサービス活用によるスケーラビリティや俊敏性、および運用最適化の実現、スマートメーターデータを分析し利活用するための AWS のデータ分析サービスの活用、という 3 つの開発方針に基づいて取り組んでいます。 この方針に沿って TCO 削減を含めたクラウドメリットを最大限に享受するため、AWS サービスの最適な組み合わせでシステム開発を進めていくことが重要ですが、AWS は多様なサービスや機能を提供しており、それぞれに特長や利用方法も異なります。要件やニーズにマッチした最適なサービスや機能を選択するためには、AWS クラウドを正しく理解して使いこなしていくことが肝要です。また、データの保護やアクセス制御など適切なセキュリティ対策を実現していくためには、AWS クラウドのセキュリティ機能やベストプラクティスを理解して使う必要があります。 こういった背景を踏まえて、AWS クラウド上でシステム開発を進めるうえで特に重要なのは、次の三つのポイントだと考えています。 私たち自身がシステムとクラウドを正しく理解すること。 システムベンダーがクラウドを正しく理解して受け入れ、積極的な活用に向けた体制整備ができていること。 私たち自身もシステムベンダーも、継続的なクラウドスキル獲得と向上を図っていくこと。 つまり、私たち自身の強い意志は不可欠ですが、それだけでクラウド活用を成功させることは容易ではなく、やはりクラウド活用を積極的に伴走してくれるシステムベンダーを私たちが適切に選択し、綿密に協業しながらシステム開発を進めることが不可欠です。 4-1. システムとクラウドに対する私たち自身の正しい理解 従来のシステム開発の経緯を顧みて、上記の方針に沿って着実にシステム開発を進めていくためには、アプリケーションシステムの全体像を私たち自身が正しく捉えることが重要と考え、業務とシステムの両面から現行システムへの理解を深めるよう取り組みを進めています。同時に、クラウド活用の議論を進めていくためにも、私たち自身がまずクラウドを正しく理解することも重要です。この点については、 第 2 回のブログの 5 章 の共通基盤の導入とシステム統制で詳しくご紹介した通りです。つまり、私たちがインフラレイヤを正しく理解し、深層まで把握することで、これを基盤とするアプリケーションの開発についても、システムベンダーとしっかり連携して協調しながら進めることができると考えています。 クラウド活用に関連して、よくある議論として「自分たちが所有することで得られる安心」に根差した意見提起がなされることもありますが、私たちはこれまで取り組んだ結果として、「クラウドを正しく理解する」ことで、自分たちが所有する以上のメリットがクラウド活用により享受できると考えています。特にフォーカスされやすいセキュリティ面で言うと、AWS を利用する場合、AWS 自身が多種多様なセキュリティ対策とそれを保証するための 認証 を取得しています。こうした対策を自分たち自身で実現しようとすると、自らがその検討や実装に時間を割く必要があります。しかし、餅は餅屋です。セキュリティ面を含めたインフラの整備や維持運用はクラウド事業者にアウトソーシングし、私たちはそれらを適切に利用しながら環境準備する( 責任共有モデル )とともに、本来実現したい業務要件に的を絞り、システム開発に本質的に注力すべきと考えています。 4-2. システムベンダーの適切なクラウドの理解と体制整備 また、正しいクラウド活用に向けては、私たちがクラウドを活用しようとする理由や動機、またどのように取り組もうとしているか、その方針などクラウド活用に係る基本スタンスの整理と、システムベンダーへのメッセージングも非常に重要です。クラウド活用方針を正しく伝えない限り、従来のサーバを Amazon EC2(EC2) 上に載せ換えてクラウド実現しただけ、ということになりかねません。それがたとえパッケージシステムであっても、そのまま EC2 の上に載せただけではクラウドの本質的なメリットを享受できるような取り組みとは言えません。クラウドメリットを最大限享受していくうえでは、マイクロサービスアーキテクチャの思想に根差し、AWS サービスのビルディングブロックを形成しながら AWS マネージドサービスをフル活用するようなシステム構想など、多様なサービスや機能を適材適所で選択しながら開発を進めていく必要性があります。 従来、オンプレミスでサーバ環境を整備しシステムを構築してきたシステムベンダーは、ともすればクラウド上に従来のシステムを組む方向に流れがちだと感じており、ユーザである私たちの強いニーズや意図を明確にシステムベンダーに示し、それを伝えなければ、クラウド活用に係る検討さえもなかなか進まないという状況はよく見られるかと思います。システムベンダーがクラウド活用の必要性を腹落ちして理解し、従来のやり方を刷新し、将来性を見据えて積極的なクラウド活用を一体的に推進できるよう、システムベンダーを活用する私たちからの積極的な働きかけは不可欠です。つまり、保有する安心感やメリットからクラウド活用へのマインドチェンジが重要なポイントだと考えます。アプリケーション開発を担うのはシステムベンダーであることから、このマインドチェンジは、私たちユーザのみならずシステムベンダーも一緒に実現すべきなのは明白です。そういった姿勢で並走できるシステムベンダーを私たちが選択し、相互に協調したシステム開発でなければクラウドの正しい活用は成功し得えないといえます。 その大前提としては、システムベンダーがそもそも正しくクラウドを理解していることが必須です。まず、システムベンダーがこれまで組み上げてきたアプリケーションシステム自体が、クラウド上でも正しく動くことを前提として理解を進め、クラウドの仕様や要件を適切に取り入れ組み直すことで、システムの移行や運用におけるトラブルや障害を防ぐことができます。また、その際には AWS のサービスやその機能を正しく理解することを通して、マイクロサービスの考え方やサーバレスアーキテクチャ、各種マネージドサービスの活用などクラウドメリットを最大限享受できるように設計開発を進めることで、システム自体の性能や信頼性を向上させることができます。堅牢なシステムの組み上げには、クラウドセキュリティを正しく理解することも不可欠です。 こういった協業関係を深化させるうえでも、 第 2 回のブログの 5 章 で説明したような共通基盤の導入を通して私たちがインフラを統制し、アプリ開発を担うシステムベンダーに必要な環境を共有する形で協業体制を整理してシステム開発を進めることも有効と考えています。 なお、私たちのプロジェクトにおいては、 AWS Professional Services も本プロジェクトに参画し、システムベンダーの自律的な取り組みを促しながら、システムベンダーの全体統括や技術支援という立ち位置で、私たちやシステムベンダーと常にコミュニケーションを図りながら強力なプロジェクト推進に協力いただいています。 4-3.　継続的なクラウドスキル獲得と向上 こういったクラウド活用推進において重要な考え方として、コンテナやサーバレスに代表されるクラウドと相性の良い技術の採用とその技術習得は非常に重要です。新しい技術を採用することが目的であればシステムとして導入することでゴールを達成できますが、 第 2 回のブログの 5 章 の共通基盤に係る説明でも触れた通り、自分たちのスキル醸成を狙うためには技術力向上の実現とは切り離せない取り組みであり、これら AWS クラウドの技術を理解しながら活用することも必須と考えています。新しい技術の習得やそれに伴うスキル醸成には、どうしても属人的な活動になりがちですが、それをいかに組織的に実現するか、当社の関係者にモチベーション高く活動を継続的に行っていくかという観点は、私たちが目指すスマートメーターシステムの実現や、その先のデータ利活用の更なる高度化にとっても必要不可欠だと考えています。 5. まとめ 本ブログでは、私たちのスマートメーターシステムの取り組みについて、現行世代システムのクラウドシフトとフルクラウドによる次世代システムの開発という、性格の異なる二つのプロジェクトの同時並行の様を、私たちの着眼点や留意事項を中心にご紹介してきました。 いずれのシステムもクラウドをベースにする、という判断は大きな判断であり、ブログの中でも紹介致しました通り、詰めた社内議論を経て、やっと合意形成を取り付けて進めてきました。クラウド推進側にも慎重側にも、踏み込んだ議論を要求してきたこともあり、私たちも非常に苦労してここまで進めて参った次第です。 AWS の紹介で海外の同業者との意見交換の場を持つことができましたが、そこで聞けたのは、私たちが経験してきたような社内議論を繰り広げてクラウド採用に至った等の話でした。日本に比べて進んでいる印象の海外事業者といえども社内にはクラウド慎重派がいて、クラウドの導入が手放しで円滑に進んでいるわけではない、ということがよく分かりました。また、国にもよりますが、規制当局がクラウドの利用に制限を設けたり、そもそも OT システムについてはクラウド利用を認めていなかったりなどの事情があることも分かりました。 このように、クラウドの利活用については、まだ慎重に考える関係者や制約となる規制の存在など、課題が残っているものの、これもブログにてお示しした通り、システムの将来における拡張性や柔軟性、これから間違いなく肝になるデータ利活用の環境整備、という観点からクラウドの徹底的な利活用は避けて通れないと考えています。 クラウドを徹底的に利活用していくためには、私たちのようなエンドユーザーとシステムベンダーの双方が、何を目指しているのか、そのためにどういう仕組みを導入しようとしているのか等々、相互理解を深め、双方ともに知見や知識、スキルを磨き続けていく意識が問われてくると考えています。私たちが導入した共通基盤の考え方や、それに伴うインフラ統制やアカウント管理のあり方などが、そうした意識を形にした一つの姿だと思います。また、こうした地道な意識浸透の活動を進めていくに当たって、クラウドのプロ中のプロである AWS、なかんずく AWS Professional Services の方々に負うところが非常に大きく、彼らのサポート無しには私たちの活動は簡単に頓挫していたように思います。私たちの取り組みはまだまだ道半ばではありますが、この場をお借りして改めてお礼申し上げます。 このブログが、読者皆様方のこれから先のシステム開発にあたって、クラウド利用を考えられる一助になれば幸いです。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。 連載記事として、以下も公開されておりますので、ぜひご参照ください。 第 1 回の記事「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 1 回) – 前半 」 第 2 回の記事「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 2 回) – 前半 」 1. はじめに 本稿では、三部構成で当社の取り組みをご紹介してきました。 第 1 回 は、当社スマートメーターシステムにおけるクラウド活用に向けた議論の全体像をご紹介しました。 第 2 回 では、次世代スマートメーターシステムの全体像について、技術的な観点も交えて私たちの現在の取り組みをご紹介しました。最後となる今回、第 3 回は、現行スマートメーターシステムのクラウド移行を中心に、私たちのクラウド活用に関する思いとこだわり、及びその取り組みについてご紹介します。 2. オンプレミスからクラウド活用へ 　当社の現行スマートメーターシステムは、第 1 回のブログで記載した通り、他電力に先立って開発を進めていた当時の背景もあって、昨今のようなメーターデータの収集管理システムのパッケージソリューションが存在しない中、複数のシステムベンダーとの協力のもと試行錯誤しながらシステム開発を進め、システムベンダーの技術や仕様に基づいて組み上げたシステムを、当社データセンターで構築しました。スマートメーターは 2012 年から当社管内のお客さまに本格導入を開始し、2023 年 3 月に全戸導入が完了するまで、スマートメーターの設置台数の拡大に伴い、現行システムで利用するサーバ数も増台しながらも、継続的な安定稼働を実現してきました。 一方で、そのような経緯で開発されたシステムであるため、独自 OS や商用データベースおよびミドルウェア採用に伴う経済性や将来持続性の問題、開発と運用のシステムベンダー依存に伴うシステムのブラックボックス化、業務処理ロジックの隠匿化などの課題に直面しており、また、スマートメーター収容数の拡大に伴うサーバハードウェアの増台、サーバのメーカー保守切れ対応の継続的な発生、さらにそのリプレイスに伴う OS やミドルウェアの技術検証など影響範囲が広く、コスト面だけではなく人的な業務負担も大きくなっていました。加えて、昨今の社会情勢の大きな変化により、半導体枯渇によるサーバのハードウェアの調達納期の遅延に代表される将来の不確実性といった、様々な課題も顕在化しています。そしてそのような複雑な状況が、スマートメーターから収集されるデータの柔軟かつ高度な利活用の拡大の障壁となっていました。 自社のオンプレミス環境でシステム運用していれば、私たちと同じような状況に陥り、同様の課題に直面するケースも多いかと思います。私たちは、それら課題に対する包括的な解決方策として、クラウド技術の活用が一つの選択肢になると考え、現行スマートメーターシステムのクラウドシフトを指向することにしました。 3. 現行スマートメーターシステムにおけるクラウド活用方針 本章では、私たちの現行システムにおける AWS 機能やサービスの捉え方やシステム移行の方針についてご紹介します。掲げた方針は 3 点あります。 現行システムのクラウド移行に向けた取り組み方針 AWS クラウドのサービスで代替できるものは、AWS に任せてオフロードする AWS クラウドならではの柔軟性をフル活用する 開発を進めながら AWS クラウドの技術革新や新サービスを随時取り込む 3-1. AWS クラウドサービスへのオフロード オンプレミスではディスク故障など日々のハードウェア障害にも個々に対処していく必要がありますが、クラウドではそういった障害対応は AWS にオフロードし私たちは意識する必要がなくなります。また、オフロードする割合を高めることで、インフラの構築や運用保守は、単にサービスの利用という形に置き換えることができます。つまり、データベースさえも組み上げる必要はなく、単にサービスを選んで利用するだけというように、システム構築の体制や考え方も大きく変わります( 図 1 )。 私たちのオンプレミスのサーバシステムでは、信頼性確保に必要となるクラスタソフトなどミドルウェアはシステムベンダー各社各様のものを採用されてきましたが、こういったミドルウェアはまず脱却の対象として位置付けました。その実現のため、 Amazon Elastic File System(EFS) や Amazon FSx 等を活用したステートレス化を含めたアプリケーション改修を実施するとともに、 Elastic Load Balancing(ELB) を活用したサーバ群のヘルスチェックを組み合わせ、かつ、マルチ AZ による拠点間冗長も実現しながら、システム全体としてのシステム信頼度を向上させています。 併せて、商用データベースの脱却も基本としています。検討当初から DB on Amazon EC2 の考え方は一切取らず、 Amazon Aurora または Amazon RDS の AWS マネージドサービス活用を前提とした移行検討を行っています。こういった AWS の各種マネージドサービスの積極活用の考え方は、マネージドサービスを活用した方が信頼性や運用保守性の向上とともに、運用負荷軽減に確実につながると評価した結果です。 図 1. AWS マネージドサービス活用による IT インフラ業務の AWS へのオフロード 3-2. AWSクラウドならではの柔軟性の活用 クラウドでは、リソースを必要な時に使って不要となれば捨てる、という身軽さがあり、「後戻りできる」というメリットがあります。 例えば、従来はサーバのリソースサイジングを緻密に行ったうえで、サーバの調達や導入に時間をかけながら進めていましたが、クラウドにおいては、「好きなときに、好きなリソースを、好きなだけ使える」という従量課金の考えのもと、その時点で決めた構成やソリューションを、よりよいものに柔軟に変更できます( 図 2 )。私たちの検討においては、インスタンスの変更も柔軟かつ簡単であることから、リソースサイジングを綿密に行うことなく、机上検討や実機検証を進めながらインスタンスタイプの選定を進めています。 図 2. AWS を活用する IT インフラ調達観点でのメリット また、従来は本番環境や開発環境をそれぞれ整備するのに、それぞれ大きな手間とコストをかけてきました。私たちは、今回、IT インフラの構築において Infrastructure as Code（IaC）を積極活用しています。IaC を活用し IT インフラのデプロイを自動化することで、人的ミスも回避することができますし、システム構成の見直しもアプリ開発を進めながら柔軟に対応可能です( 図 3 )。 図 3. AWS における IaC メリット 3-3.技術革新や新サービスの随時取り込み 導入当時には適切と判断したアーキテクチャであったとしても、導入からの時間経過に伴う技術革新により、当時よりも選択肢が増えたことで検討の幅が広がり、より良い構成を選択できる可能性があります( 図 4, 図 5 )。 例えば、私たちが検討を進める中で、「 Network Load Balancer(NLB) でセキュリティグループのサポートを開始 」という発表が 2023 年 8 月にありました。当初は、NLB についてはセキュリティグループチェーンの対象外としていましたが、この発表を受けて設計変更した結果、システム全体にわたるセキュリティグループのチェーン化を取り込みシンプルな仕組みでのセキュリティ確保が実現できています。 現在進めている、次世代スマートメーターシステムの構築においても、同様により良いサービスや機能が提供開始された場合には、それを活用しながら開発を進める方向です。 図 4. AWS の技術革新による新サービス・新機能の提供拡大 図 5. アナリティクス分野を含めて拡大する AWS サービス(抜粋) 本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「 3．現行スマートメーターシステムにおけるクラウド活用方針まで」をご紹介致しました。後半については、「 寄稿：関西電力送配電株式会社におけるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 3 回) – 後半 」をご参照ください。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

はじめに 2023 年初頭の初回リリース以来、 AWS Systems Manager for SAP チームは SAP のお客様が AWS で SAP システムを管理できるように、お客様からのフィードバックに基づいてサービスの強化に取り組んできました。このブログでは、AWS Systems Manager Application Manager でリリースされた次の 2 つの機能強化について説明します。 AWS System Manager Application Manager コンソールによる SAP HANA データベースシステムの登録:AWS Systems Manager Application Manager コンソールが導入される前は、SAP HANA データベースシステムの登録と検出には AWS コマンドラインインターフェイス (CLI) を使用する必要がありました。AWS System Manager Application Manager コンソールを使用して、コマンドラインインターフェイスに加えて SAP HANA データベースへの運用アクティビティの登録と実行が可能になりました。これには、シングルノードと高可用性 SAP HANA データベースシステムの両方のサポートが含まれます。 AWS Systems Manager (SSM) for SAP と SSM アプリケーションレジストリーのアプリケーションタグ付けを統合すると、AWS Systems Manager Application Manager コンソールから SAP HANA アプリケーションのインサイトを確認できます。複雑な SAP ワークロードを実行している AWS のお客様は、SAP 自動化タスクの管理に苦労することがよくあります。多くのお客様が、オンプレミスでのデプロイから引き継いだツールやスクリプトを使用しており、これらのアプリケーションの管理と運用を一元的に管理してほしいという要望がありました。SSM Application Manager には、SAP アプリケーションの管理を容易にするためのこれらの 機能が備わっています 。AWS Systems Manager (SSM) for SAP と SSM アプリケーションレジストリーのアプリケーションタギングとの統合が開始されたことで、お客様は AWS Systems Manager Application Manager コンソールから登録された SAP HANA アプリケーションのアプリケーション詳細を表示できるようになります。この統合により、特定の SAP アプリケーションのコンテキストにおけるリソース、インスタンス、モニタリング、および推定コストに関する詳細が提供され、カスタマーエクスペリエンスが向上します。 概要 このセクションでは、AWS Systems Manager Application Manager コンソールで SAP HANA データベース (シングルノード及び高可用性) システムを簡単に登録する方法を示します。 前提条件 ここに記載 されているバージョン要件を満たす SAP HANA データベースシステム AWS Systems Manager for SAP ユーザーガイド の「はじめに」セクションに記載されているステップを完了しました。 AWS Systems Manager Application Manager コンソールによる SAP HANA データベースシステムの登録 リンク先 の AWS Systems Manager コンソールを開きます。 左側のナビゲーションペインで Application Manager を選択します。 Create Application を選択し、 Enterprise Workload を選択します。 Application name&nbsp; (例:「HANADBHA」) を入力し、SAP HANA Database High Availability のように Application Description を入力します。 Browse instances を選択し、登録したい SAP HANA データベースのインスタンス ID を選択します。注:高可用性 SAP HANA データベースを登録するには、プライマリノードまたはセカンダリノードのインスタンス ID を選択できます。 登録する SAP HANA データベースシステムの SAP System identifer (SID) と SAP instance number を入力します。 HANA システムデータベースのセキュリティ認証情報を含む AWS Secretes Manager に保存されているシークレットの Secret ID を選択します。 テナントデータベースを追加するには、 Add credential を選択します。 テナントデータベース名を入力し、HANA テナントデータベースのセキュリティ認証情報を含む AWS Secretes Manager に保存されているシークレットのシークレット ID を選択します。 Create を選択します。 登録プロセスが完了するまでに約 3 ～ 5 分かかります。 登録が完了すると、登録が完了したことを知らせる緑色のメッセージバーがコンソールの上部に表示されます。 登録が完了すると、アプリケーションマネージャー画面に戻り、登録したアプリケーションが一覧表示されます。 アプリケーションの詳細を表示 登録したアプリケーションの詳細を表示するには、 Find Application でアプリケーション名を検索します。登録されたアプリケーションが一覧表示されたら、以下に示すようにリスト内のアプリケーション名を選択します。 Application Manager 画面でアプリケーションを選択すると、次に示すように、Application type, Application ID, Application source など、登録したアプリケーションの詳細が表示されます。Application Manager アプリケーションの操作方法や AWS リソースに関する運用情報の表示方法の詳細については、 アプリケーションの使用 を参照してください。 システムを構成するコンポーネントを確認するには、 Resources タブを選択し、Topology セクションまでスクロールします。 登録したシステムは高可用性システムなので、3 つのコンポーネントが登録されていることがわかります。 HDB – HDB00 = 論理データベースを表す親コンポーネント HDB – HDB00-sappridb = プライマリデータベースホストエンティティを表す子コンポーネント HDB – HDB00-sapsecdb = セカンダリデータベースホストエンティティを表す子コンポーネント *注-登録プロセスでは、プライマリデータベースのインスタンス ID を選択するだけで良く、セカンダリデータベースは AWS Systems Manager for SAP によって自動的に検出され登録されます。 特定のコンポーネントに関する追加情報を表示するには、コンポーネント名の左にあるラジオボタンを選択します。この例では、SAP HANA データベースバージョン、OS バージョン、SAP HANA System Replication モード、SAP ホスト名など、SAP Systems Manager for SAP によって登録されたセカンダリ SAP HANA データベースシステムの詳細を確認します。 Application Manager コンソールで SSM for SAP の設定が完了すると、さまざまなウィジェットが有効になっていることがわかります。まず、Overview タブから特定の SAP アプリケーションのダッシュボードを確認します。詳細については、 Register an application with AWS Systems Manager Application Manager を参照してください。 SAP アプリケーションを Amazon CloudWatch Application Insights とコストレポートにオンボードする アプリケーションのタグ付け機能により、SSM Application Manager は SAP アプリケーションを実行している特定の EC2 インスタンスにタグを適用できます。登録後は、SAP システムのログを SSM コンソールに追加するための追加の手動設定や追加の手順は必要ありません。インサイトを表示するには、SSM Application Manager の Monitoring タブから SAP アプリケーションを CloudWatch Application Insights にオンボードする必要があります。 以下の手順に従って、SAP application with CloudWatch Application Insights for SSM で SAP アプリケーションをオンボーディングします。 Application Manager コンソールで SAP アプリケーションを見つけて選択し、Application Details ビューに移動します。 Components ツリーで、アプリケーション名を選択します。 Monitoring タブの Application Insights セクションに移動し、 Add an Application ボタンを選択します。 これにより、 CloudWatch Application Insights の Add an Application widget ウィジェットが開きます。 Specify application details ページの Select an Application or resource group のドロップダウンリストから、SAP リソースを含む SSM for SAP アプリケーションの名前を選択します。 Monitor EventBridge events で、”integrate Application Insights monitoring with CloudWatch Events” チェックボックスを選択すると、通知や Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health API, Amazon RDS、Amazon S3、AWS Step Functions から分析情報を取得できます。 Integrate with AWS Systems Manager OpsCenter で、 Generate AWS Systems Manager OpsCenter OpsItems for remedial actions の横にあるチェックボックスを選択すると、選択したアプリケーションで問題が検出されたときに通知を表示して受け取ることができます。お客様の AWS リソースに関連する OpSitems と呼ばれる運用上の作業項目を解決するために実行されるオペレーションを追跡するには、SNS トピック ARN を指定します。 Next を選択してモニタリングの設定を続行します。 表示されている特定の HANA データベースの箇条書きアイコンを選択します。 &nbsp;Review detected components ページでは、監視対象コンポーネントとそのワークロードが CloudWatch Application Insights によって一覧のように自動的に検出されます。 Next を選択します。 &nbsp;Specify component details ページで、HANA データベースのユーザー名とパスワードを入力します。 Next を選択します。 Review and submit でアプリケーション監視設定を確認し、 Submit を選択します。 アプリケーション詳細ページが開き、アプリケーションの概要、監視対象コンポーネントとワークロード、および監視対象外のコンポーネントとワークロードのリストを表示できます。設定を送信すると、アカウントが SAP アプリケーションのすべてのメトリクスとアラームをデプロイします。これには最大 2 時間かかることがあります。 Application Manager コンソールに戻り、お使いの SAP アプリケーションを見つけて選択し、アプリケーション詳細ビューの Monitoring タブに移動します。これで、アプリケーションインサイトの監視情報が表示されるはずです。 Monitoring タブでは、SAP アプリケーションからのアプリケーションインサイトとアラームを確認できます。 Instances タブ のスクリーンショットをご覧ください。 EC2 インスタンスには、自動的に追加された新しい AWS Application タグが付けられます。これにより、EC2 コンソールにアクセスしなくても EC2 インスタンスの停止などのアクションを実行したり、EC2 インスタンスの詳細を表示したりできます。 Compliance タブでは、コンプライアンス違反項目、保留中のパッチ、修正すべきランブックを確認できます。 Runbooks タブでは、選択した Runbook の実行ログとステータスを確認できます。Compliance、Opsitems、Runbooks などの一部のタブは、現在のバージョンでは SAP アプリケーションに対応していません。今後 SSMSAP が SSM AppManager とより緊密に統合されるときに、これらのタブを含める予定です。 Logs タブでは、CloudWatch から SAP アプリケーションのログにアクセスできます。 Cost タブでは、アプリケーションのコスト履歴とコスト傾向を調べたり、それに合ったコスト削減の推奨事項を受け取ったり、リソース支出を最適化したりできます。現在統合されている SSM for SAP 用 Cost Explorer では、HANA (シングルノード、HA) が稼働している基盤となる EC2 インスタンスに基づいてコスト計算を行うことができます。 結論 このブログでは、AWS System Manager Application Manager コンソールを使用して、コマンドラインインターフェイスに加えて SAP ワークロードで運用アクティビティを登録および実行する方法について説明しました。また、AWS Systems Manager (SSM) アプリケーションマネージャーコンソールを使用して、1 つの画面から SAP アプリケーションを管理および運用する方法についても学びました。SSM アプリケーションマネージャーと MyApplications には、SAP アプリケーションの管理を容易にするためのこれらの機能が備わっています。 SAP ワークロードの移行、近代化、革新において、何千ものお客様が AWS を信頼している理由については、 SAP on AWS ページ をご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。