Amazon DynamoDB はフルマネージド型のNoSQLデータベースであり、高速で予測可能なパフォーマンスとシームレスなスケーラビリティを提供します。さまざまな業界のお客様が最適なデータベースとしてDynamoDBを利用しています。 多くのEdTech企業が、試験の点数や講座の進捗状況を追跡するための永続的なデータストアとしてDynamoDBを利用しています。学生が進級していくにつれて、特定の教科の教材との関わり方や試験の得点が変化します。授業や課程を修了すると、学生が過去の教育リソースにアクセスする頻度は大幅に減りますが、コンプライアンスまたは契約上の義務により、EdTech企業は長期間（多くの場合5年以上）にわたって学生が利用できるようにしておく必要があります。このような、データアクセスパターンは教育分野にとどまらず、さまざまな業界のお客様に共通する課題です。そのため、DynamoDBのデータアクセシビリティを維持しつつコスト効率の良いストレージソリューションへの需要が高まっています。 DynamoDBはデータをテーブルに整理し、標準とStandard-Infrequent Access (標準 – IA)という 2 つの異なるストレージクラスを提供します。標準テーブルクラスはデフォルト設定で、一般的にほとんどのワークロードに適しています。一方で、標準-IA テーブルクラスは、アクセス頻度の低いデータを格納するテーブル専用に設計されています。標準-IAテーブルクラスでは、保存されているデータのギガバイト (GB) あたりのコスト効率が高まります。データが古くなり、アクセス頻度が低くなるにつれて、標準テーブルクラスから標準-IA テーブルクラスへの移行はコスト効率の高い戦略になります。組織は、標準テーブルクラスと同じパフォーマンスと統合機能を確保しながら、ストレージコストを節約できます。このアプローチにより、企業は DynamoDBのストレージ機能を効率的に利用しながら、コスト最適化とデータ可用性のバランスを取ることができます。ストレージがコストの約50%以上を占める DynamoDBテーブルを所有しているお客様は、データを標準-IAテーブルクラスに移行することを検討する必要があります。 DynamoDB標準テーブルクラスと標準-IAテーブルクラスの詳細な料金例については、料金ページの さまざまなテーブルクラスを使用した例 をご覧ください。 このブログでは、 Amazon DynamoDB Streams 、 DynamoDB 有効期限 (TTL)、および AWS Lambda を使用して標準テーブルクラスから標準-IAテーブルクラスにデータをアーカイブするためのカスタマイズされたソリューションを作成するためのプロセスについて説明します。 ソリューション概要 DynamoDB StreamsとLambdaの機能を組み合わせることで、標準テーブルクラスに加えられた変更をキャプチャし、それらの変更に基づいた特定のアクションをトリガーすることができます。TTLを使用すれば、データが一定の経過時間に達したときに標準テーブルクラスで自動的に期限切れとしてマークし、期限切れのデータを含むレコードをDynamoDB Streamsに生成することができます。その後、Lambdaのイベントフィルタリングにより、DynamoDB Streamsからの期限切れデータイベントのみを選択し処理することができます。このプロセスにより、不要な処理やコストを回避しながら、期限切れデータを効率的に処理することで、標準-IAテーブルクラスに移行することができます。 次の図はこのソリューションのアーキテクチャを示しています。 ワークフローには次のステップが含まれます: DynamoDB TTLは、アイテム属性に基づいて期限切れのアイテムを標準テーブルクラスから削除します。 DynamoDB Streamsは、期限切れのアイテムを含むストリームレコードを生成します。 Lambdaは DynamoDB Streamsからの削除イベントを処理します。Lambdaイベントフィルタリングでは、Lambdaは DynamoDB TTLからの削除イベントによってのみ呼び出されます。 データは標準-IA テーブルクラスに書き込まれます。 DynamoDB TTL を使用したデータの削除 DynamoDB TTLは、DynamoDB内でデータのライフサイクルを管理する便利な方法を提供します。TTLを使用すると、テーブル内の各アイテムにタイムスタンプを割り当てて、そのアイテムがいつ期限切れになったか、不要になったかを示すことができます。指定したタイムスタンプが経過すると、DynamoDBはアイテムをテーブルから自動的に削除するため、手動で削除する必要がなくなります。TTLの主な利点は、運用上のオーバーヘッドなしに期限切れのアイテムや不要なアイテムを削除することで、保存されているデータ量を減らすことができることです。これは、時間経過とともに古くなる大量のデータがある場合など、前述のようなシナリオで特に役立ちます。期限切れのアイテムを自動的に削除することで、テーブルを整理し、ワークロードにとって最も関連性が高く最新のデータのみを保持するようにできます。 重要なことは、DynamoDB は書き込みスループットを消費せずに期限切れのアイテムを削除するため、古いデータを削除する際に追加コストが発生したり、パフォーマンスに影響を与えることはありません。TTL付きのDynamoDBグローバルテーブルを利用する場合では、DynamoDBは全てのレプリカに対してTTLによる削除を複製します。この際、各レプリカリージョンで複製されたTTLによる削除に対して、テーブルに設定されているキャパシティモードとテーブルクラスに応じた書き込みコストが発生します。 DynamoDB Streamsの概要 DynamoDB Streamsは、DynamoDB テーブルのアイテムへの変更を含む時系列ログを提供します。アプリケーションがテーブル内のアイテムを作成、更新、削除すると、変更の記録がテーブルの対応するストリームに書き込まれます。 デフォルトでは、DynamoDB Streamsは DynamoDBのアイテムに対して実行された以下のアクションを収集します。 INSERT – 新しいアイテムがテーブルに追加 MODIFY – 既存のアイテムの１つまたは複数の属性が変更 REMOVE – アイテムがテーブルから削除 ユーザーは、次のオプションからキャプチャするデータを選択できます。 Key attributes only – 変更されたアイテムのキー属性のみ New image – 変更後に表示されるアイテム全体 Old image – 変更前に表示されていたアイテム全体 New and old images – アイテムの新しいイメージ (New image) と古いイメージ (Old image) の両方 DynamoDB Streamsを使用すると、TTLによって期限切れになったアイテムの情報をネイティブに収集し、さらなる処理に使用できます。 DynamoDB TTLでアイテムが期限切れになると、DynamoDB Streamsに次のフィールドを含むレコードが作成されます: Records[<index>].userIdentity.type "Service" Records[<index>].userIdentity.principalId "dynamodb.amazonaws.com" 次に、以下のように、これらのプロパティを Lambdaのイベントフィルターとして追加できます。 "Records": [ ... { "userIdentity": { "type": "Service", "principalId": "dynamodb.amazonaws.com" } } ... ] JSON このイベントフィルタを利用することで、お客様は Lambda関数が DynamoDB TTL削除からのみ呼び出されるようにできます。これにより、関数の呼び出し回数が減り、コスト削減につながります。 Lambdaを利用した、DynamoDB Standard-IA テーブルクラスへの書き込み Lambdaはコードを実行するためのコンピューティングサービスで、サーバーのプロビジョニングや管理は必要ありません。Lambdaはイベントに応じて可用性の高いコンピューティングインフラストラクチャ上でコードを実行し、消費したリソースに対してのみ課金されます。Lambdaは、DynamoDB Streamsを含むさまざまな AWS サービスとすぐに統合できます。 DynamoDB Streamsを Lambda関数のトリガーとして追加 することで、標準-IAテーブルクラスにデータを格納することができます。アイテムの挿入、更新、削除は DynamoDB Streamsに記録され、それに応じてLambda関数がトリガーされます。不要な処理を避けるため、Lambdaイベントフィルタリングを利用して、必要なイベントにのみ応答できます。DynamoDB StreamsはLambdaを含むさまざまな AWS サービスと統合できます。さらに、DynamoDB Streamsからデータを処理する際、Lambdaから呼びだされるGetRecords APIに料金はかかりません。ただし、 AWS Lambda料金表 に従って、Lambda関数の実行時間に応じた標準の料金が適用されます。 まとめ この記事では、DynamoDB TTL、DynamoDB Streams、およびイベントフィルタリング付きの Lambda を使用して、DynamoDB標準テーブルクラスからDynamoDB標準-IA テーブルクラスにデータをアーカイブする方法について説明しました。AWS サービスとネイティブな統合を活用することで、DynamoDB 標準-IAテーブルクラス内にデータをアーカイブするためのフルマネージドで費用対効果の高いソリューションを構築できます。DynamoDB APIを使用してデータへのアクセスを維持しつつ、コールドデータの保存コストを節約したいお客様は、上記のソリューションを実装することが出来ます。 会話に参加しましょう！あなたのフィードバックと経験は私たちとコミュニティにとってかけがえのないものです。以下のコメント欄で洞察を共有したり、質問をしたり、別の視点を提供してください。協力して理解を深めていきましょう！DynamoDB の使用についてさらに詳しく知りたい場合は、 開発者ガイド をご覧ください。 (本記事は 2023/10/13に投稿された Archive to cold storage with Amazon DynamoDB を翻訳した記事です。) 著者について Andrew Chen は、データ分析、機械学習、インフラストラクチャの仮想化に関心を持つEdtech Solutions Architectです。Andrewは以前、経営コンサルティングの経験があり、さまざまなクラウド移行プロジェクトのテクニカルリーダーとして働いていました。Andrewは自由時間には、釣り、ハイキング、カヤックを楽しんだり、金融市場の動向も追っています。 Lee Hannigan は、アイルランドのドニゴールを拠点とするSr. DynamoDB Specialist Solutions Architectです。ビッグデータと分析技術の強固な基盤に裏打ちされた分散システムに関する豊富な専門知識を持っています。DynamoDB Specialist Solutions Architectとして、DynamoDBの機能を活用したワークロードの設計、評価、最適化においてお客様を支援することに長けています。

この記事は “ Key takeaways from Gilead’s Innovation Talk at re:Invent 2023 ” を翻訳したものです。 寄稿:ギリアド・サイエンシズのシニアバイスプレジデント兼 Chief Information Officer (CIO) マーク・バーソン、AWS ヘルスケア・ライフサイエンス担当ゼネラルマネージャー ダン・シーラン。 re: Invent 2023 では、 ギリアド・サイエンシズ の CIO であるマーク・バーソン氏が、「 インダストリー向け生成AI 」をテーマにしたイノベーショントークに、AWS インダストリテクノロジー担当ディレクターであるショーン・ナンディ氏と共に参加しました。 講演では、生成 AI を使用して治療法の飛躍的進歩を加速させるというギリアドのアプローチが強調され、企業レベルでテクノロジーを実現するために、レジリエントなクラウドインフラストラクチャと強固なデータ基盤を確立するというギリアド社の取り組みが紹介されました。 講演のキーポイントは次のとおりです。 生成AI による治療の進歩の促進 製薬会社は、サイエンスイノベーションの最前線で、生死に関わる病気と闘う患者に画期的な治療薬を迅速に提供しなければならないという大きなプレッシャーに常に対峙しています。 しかし、新薬の開発プロセスには通常 10 年以上の時間と、数十億ドルもの費用がかかり、さらに上市までに 90% という恐ろしい失敗確率に直面しています。 生成AIは、新規化合物の同定と設計を加速し、治療法の開発プロセスを最適化することで、創薬を大きく変革することができます。 この新技術は、規制当局への申請、市場アクセス、製品化に関連する手作業属人的な作業や冗長なプロセスを自動化することで、サイクルタイムをさらに短縮できます。 ギリアドは、生成AIがビジネストランスフォーメーションに与える可能性を活用して科学の進歩を加速させ、クラウド、データ、AI の融合を活用したイノベーションを実現する最前線にいます。　同じく、意思決定の強化、効率の向上、クラウドスケールのデータからのインサイト抽出の促進など、ROI の高いさまざまなユースケースに対応する生成 AI ソリューションを模索しています。 「業界の複雑な課題を乗り越えるには、企業が俊敏、かつイノベーティブであり、進化する状況に適応する必要があります。私たちは、手に入れられるあらゆる利点を追求する必要があります。 私たちは生成AIをエンタープライズ企業の視点から模索しており、投資対象となる価値の高い生成 AI のユースケースを特定するためのエンタープライズアプローチを実装しています。」 — ギリアド・サイエンシズ社 CIO、マーク・バーソン氏 創薬の変革：生成AIによるターゲット評価の再構築 ギリアド社は研究開発能力を強化するためにさまざまな生成 AI のユースケースに投資していますが、その中でも最も注目しているユースケースの 1 つがターゲット評価です。 ターゲット評価は、創薬の初期段階における重要なステップです。新薬候補のターゲットとなる生体分子（タンパク質または核酸）の評価と特性評価が行われます。徹底した評価を行い、研究者が成功確率が高い新薬候補について、どのターゲットを研究対象として追求する価値があるかを優先順位付けします。 ただし、このプロセスには、ペタバイト規模のデータをマイニングし、関連するあらゆる研究を特定し、その研究を分析し、研究から得た知見を迅速に適用する必要があります。 ギリアド社は生成 AI を活用して、創薬ターゲット評価プロセスの効率と効果を飛躍的に向上させています。専門の LLM  (Large Language Models) を使用して、膨大な量の医科学文献やデータベースを迅速にクエリして分析しています。 これにより、科学者は自然言語検索を行って研究文献を要約したり、簡単なクエリで分子相互作用をシミュレートしたり、参考文献を含む合成研究レポートを動的に作成して更新したりできるため、最終的にはより安全で効果的な医薬品の開発を加速できます。 #1: LLMツールを使用して、膨大な量の科学文献とデータベースを迅速に分析します #2: 潜在的な創薬ターゲットに関連する研究を特定します #3: ターゲットの特定と検証の初期段階を大幅にスピードアップします 「生成 AI は単にテクノロジーだけの問題ではなく、私たちの働き方そのものを変革しうる存在なのです。」 ギリアド社は、生成AIによって高品質な創薬ターゲット評価レポートを効率的に生成することで、従来までの評価プロセスに必要としていた時間を数か月にまで大幅に短縮できると予測しています。 同社では、これらの LLM、アーキテクチャのパターン、LLMOP (大規模言語モデルオペレーション) を社内の他のユースケースで再利用することも検討しています。 「基本的には、同じだけのリソース配分でより多くのことを行うという考え方です」と Berson 氏は言います。 <左>：出来ること 機械と自然言語を使った対話が可能 標準化された研究レポートの作成 スピードを持った品質評価結果の生成　<右>：利点 要約されたコンテンツ作成が加速される 使いまわしが可能なアキテクチャ−パターンとLLMOpes 他の部門、部署で再利用できる可能性 生成 AI を実現するための強固なクラウドとデータ基盤の確立 まだ生成 AI のモデルをめぐる話題があったにもかかわらず、ギリアド社は早い段階で、強力、かつ競争力のある生成 AI  アプリケーション構築の鍵は、包括的なエンドツーエンドのデータ戦略を実装することにあることを認識していました。 AWS 上に構築された堅牢なクラウドインフラストラクチャにより、ギリアドは事業を効率的に拡大し、迅速かつ機敏にイノベーションを起こすことができます。 同社は コンピューティングとストレージのワークロードの 80% を AWS に移行し 、現在ではミッションクリティカルなワークロードをクラウドで実行しています。 「私たちは、クラウドがもたらすレジリエンス、スピード、スケーラビリティを高く評価しています」と Berson 氏は言います。 「これはギリアド社にとって戦略的なビジネス上の優先事項であり、創薬から製品化までのバリューチェーン全体を変革するためには不可欠です。」 「ギリアド社では、AWS 上に構築されたクラウド、データ、強固な分析基盤の上に 機械学習 (ML) と生成 AI を構築しています。 さらに、MLOps を自動化して ML ライフサイクル全体の効率化を実現しています。」 ギリアド社の エンタープライズデータプラットフォーム では、 ML と生成 AI の機能 を一から作り直すことなく活用できます。 データメッシュアーキテクチャ で運用されるこのプラットフォームは、組織のデータを一元化し、管理を拡大し、組織全体のコラボレーションを促進します。 また、分散型データオーナーシップモデルでは、データに最も近く、現場の状況を理解しているビジネスチームがデータを管理できるようになります。 ギリアド社のデータメッシュのもう 1 つの特徴は、「 データ・アズ・ア・プロダクト（DaaP） 」アプローチです。 組織全体のデータプロデューサーは、エンタープライズデータプラットフォームで 300 を超えるデータプロダクトを公開しています。 これらはデータ利用者がすぐに使用できるようになっており、データが検索可能、アドレス指定可能で、理解しやすく、信頼できる、有用、アクセス可能、安全、相互運用可能であるよう最大限の注意が払われています。 さらに、これらのデータ製品のライフサイクル全体を管理するさまざまなセルフサービスデータソリューションが、分散型データオーナーシップの全体的なコストを削減することで、この戦略全体をサポートしています。 「AWS では、進化するビジネスニーズにより迅速に対応するために、従来のモノリシックなアプローチから脱却して、最新のデータ編成とエンジニアリング手法を導入しています。」 ギリアド社は、機密性の高い患者データを扱うグローバルなライフサイエンス組織として、フェデレーションによる意思決定構造（Federated Decision-Making Accountability Structure）に基づいた強力なデータガバナンス運用モデルにより、データセキュリティとコンプライアンスを強化しています。 「私たちには中央集権的な企業基準とガバナンスがありますが、ドメインのオーナーシップは独自に保たれています」とバーソン氏は言います。 「これにより、変化に機敏に対応し、成長に直面しても ROI と持続可能性を高めることができます。」 ・データ メッシュ アプローチは、かつては大規模なデータを管理するために使用されていました。 ・各ビジネス部門による分析データのドメインオーナーシップ。 ・企業全体でデータを製品として共有する この強固な基盤が整ったギリアドは、AI、機械学習、ディープラーニング、分析の活用を全社的な機能として拡大し、複雑なデータを貴重なインサイトに変換し、分子、創薬ターゲット、疾患間の隠れた関係を明らかにしています。 また、AWS と協力して、データサイエンティストに最新のテクノロジーを提供し、すべての人にとってより健康的な世界を作るという大胆なビジョンに向けて、画期的な治療イノベーションを実現しています。 「私たちが AWS を選んだのは、その技術だけでなく、業界を変革し、共に再定義することに情熱を注いでいるからです。 私たちはまさに、その活動に可能性を実現する力を見出しています。」 将来を見据えた取り組み:生成AI のユースケースをプロトタイプから本番環境に移行 業界がより複雑で創薬ターゲットを絞った治療法に移行する中、今後 3～5 年は創薬における生成 AI の価値を実証する上で極めて重要です。 パイロットからプロトタイピング、本番環境に至るユースケースが増える中、ギリアドは生成 AI の実用的な使用に対する基本指針を確立し、将来を見据えた責任ある AI の使用を確保することに重点を置いています。 Berson 氏はセッションを締めくくりに、生成 AI の流行に乗り出している企業に向けた、示唆に富むアドバイスをいくつか述べました。独自の指針を確立し、当初から経営幹部の関与と賛同を得ましょう。 「生成 AI が 単に IT プロジェクトの一つになるのではなく、ビジネスと緊密に連携して構築され、ビジネス成果でその成功を測るような取り組みになるようにしましょう」と彼は警鐘を鳴らしました。 このre:Invent 2023 イノベーション トークの リプレイはこちら の YouTube でご覧ください。 re:Invent 2023での HCLS のその他の発表と ハイライト ToP10 については、このブログをご覧ください。 著者について Dan Sheeran Dan は AWS のヘルスケア・ライフサイエンスインダストリービジネスユニット (HCLS IBU) を率いており、ライフサイエンス、医療機器、保険者、データサービス、ヘルスケア ISV および OEM のすべての AWS のお客様をサポートしています。HCLS IBU は、お客様が AWS クラウドと機械学習サービス、および AWS パートナーのソリューションを活用して、新しい治療法、診断、およびデバイスを研究・開発し、患者の転帰を改善してより効率的に医療を提供できるよう支援します。2019 年に AWS に入社する前は、慢性疾患の予防と管理のための遠隔医療と機械学習に焦点を当てた 2 つのデジタルヘルススタートアップを設立し、率いていました。Danはシアトル地域に住んでいます。ノースウェスタン大学で経営学修士号、ジョージタウン大学で理学士号を取得しています。 翻訳は Senior Business Development Manager の亀田が担当しました。

Amazon Payment Services (APS) は、中東・北アフリカにおける決済サービスプロバイダーです。セキュアかつシームレスな支払い体験により、企業がオンラインプレゼンスを構築できるようサポートします。 Amazon Payment Services は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon CloudWatch、Amazon Simple Storage Service (Amazon S3) など、複数の AWS サービスに依存する広範囲かつ複雑なマイクロサービスベースのアーキテクチャを基盤としています。 APS の機能拡大に伴い、サービスの依存関係グラフも拡大し続けています。APS チームは、特定のフローでどのマイクロサービスが利用されているかを分析する、また、マイクロサービスのパフォーマンスと正常性を分析する際に問題に直面しました。このブログ記事では、マイクロサービスアーキテクチャにおいてユーザーリクエストフロー内でパフォーマンス問題を特定するプロセスについて説明します。 APS システムアーキテクチャ APS チームは、リダイレクトページ、カスタマイズされた決済ページ、モバイル SDK など 7 つの加盟店統合フローを扱っています。また、世界中の決済業者や第三者決済サービスプロバイダとの統合も管理しています。APS チームは、顧客のパフォーマンスやレイテンシーの報告される問題への対応を担当しています。全体的なシステムのパフォーマンス改善、ビジネスの成長、スケーラビリティも保証する責任があります。 APS のマイクロサービスアーキテクチャは、支払いシステムのコンポーネントを支払い機能に基づいた小規模で疎結合なシステムに分割するのに役立ちます。これにより、APS チームはお客様のニーズに迅速に対応でき、お客様の問題に対処できるため、システムを柔軟に運用できるようになります。さらに、APS チームは必要に応じて柔軟にスケールアップまたはダウンでき、高い可用性と信頼性を確保しながら APS のお客様に最適なパフォーマンスとメンテナンス性の高いソリューションを提供できるようになります。 マイクロサービスアーキテクチャによる APS の課題 顧客からのリクエストを実行すると、複数のマイクロサービスが呼び出される可能性があり、呼び出されるマイクロサービスの数はフローが意図する機能によって決まります。 APS では対応する複雑なユースケースが多いため、多数のフローに対して膨大な数のサービスに依存関係が生じていました。 これらの問題により、顧客のパフォーマンス問題の根本原因の特定が遅れ、新機能の提供に影響を与えていました。この遅れは、顧客満足度にも悪影響を及ぼしていました。さらに、これがシステムの全体的な安定性に影響を与え、システムの停止にもつながる可能性がありました。 彼らが直面した課題は以下のようなものでした: APS チームは呼び出されたマイクロサービス間の API 呼び出しのレイテンシーメトリクスを継続的に測定して、パフォーマンスやレイテンシーの問題を検出するのが大変でした。 マイクロサービスレベルでのレイテンシーのトラブルシューティングと評価に体系的なアプローチがありませんでした。結果として、パフォーマンスの問題に対処するときは手動でメトリクスの出力や追加のログを加える必要があり、オーバーヘッドと運用コストの増加につながりました。 各マイクロサービス内のコードブロックのパフォーマンスを分析するツールが利用できませんでした。 マイクロサービスをまたいでリクエストのエンドツーエンドの流れを追跡する包括的なツールがないため、APS チームはアプリケーションとインフラストラクチャのパフォーマンスを可視化できず、運用面と事業面の両方で影響がありました。 ソリューションの概要 ソリューションを検討する際、APS チームは先行コストを最小限に抑え、管理のオーバーヘッドを減らすソリューションを求めました。アプリケーションアーキテクチャの性質上、APS チームは信頼性が高く、効率的で、手頃な価格で、長い導入期間やセットアップのプロセスを必要とせずに結果が得られるマネージド サービスを希望していました。APS チームの業務をサポートし、課題を解決するための理想的なソリューションとしてAWS X-Ray が選択されました。AWS X-Ray は、API、SDK、ダッシュボード、および他の AWS 監視ツールとの統合で構成される、分散アプリケーショントレーシングサービスです。 複数のプログラミング言語に対応しており、アプリケーションのコンポーネント構成マップを表示できます。 通常、オペレーションチームは Amazon CloudWatch ServiceLens および Amazon CloudWatch Synthetics と併せて使い、AWS ホストのアプリケーションの遅延や障害原因を特定します。AWS X-Ray を使うことで、オペレーションチームはマイクロサービスアーキテクチャにわたる遅延、スロットル、エラー率、障害について秒単位でメトリクスを収集できました。これにより、内部のマイクロサービスか外部サービスプロバイダのいずれであっても、パフォーマンスの問題や動作不良コンポーネントの根本原因を特定しやすくなりました。 その 3 日後には、AWS X-Ray が導入されただけでなく、APS チームは実際のメリットを認識し、その機能を活用し始めました。セットアップは簡単で、APS チームは AWS X-Ray の AWS ドキュメントに従い、以下の手順を実行しました。 セットアップ ：AWS X-Ray Daemon セットアップ ：AWS X-Ray Amazon CloudWatch メトリクス 設定 ：AWS X-Ray Java SDK を使用して、Spring Aspect-Oriented Programming (AOP) を構成 次のイメージは、AWS X-Ray の全体のセットアップアーキテクチャ図です。 AWS X-Ray による課題解決とエンドユーザー体験の改善 AWS X-Ray を使用した結果、APS チームは基盤システムについて深い洞察を得ることができ、10 の改善領域、3 つのライフサイクル中の不要なネットワーク呼び出し、4 つの誤動作フローを特定しました。 その結果、レイテンシーが 25 % 低減し、全体的な顧客体験が改善され、顧客の信頼を得ることができました。以下、その方法を説明します。 HTTP Request Service map : AWS X-Ray のサービスマップは、顧客からのリクエストについて詳細なエンドツーエンドの視覚的な表現を提供します。バックエンド、フロントエンド、下流のサービス間の接続関係を示します。その結果、パフォーマンスのボトルネック、API レスポンスタイム、各ノードのネットワーク呼び出し回数を特定することができます。 リクエストサービスマップは、AWS X-Ray コンソールのトレースタブでリクエストトレース ID をクリックすると取得できます。以下は、ノード間の接続関係を示すトレーストレースリストとリクエストサービスマップの例です。レスポンスタイム、リクエスト数、サービスノード名などのテレメトリデータが含まれています。 コードベースのエンドツーエンドトレーシングとセグメント化されたタイムライン: AWS X-Ray は、意図したコードクラスに @XRayEnabled アノテーションを付けることで、リクエストライフサイクル中に実行されるインラインコードブロックメソッドについてリアルタイムのトレースを提供できます。AWS X-Ray SDK は Aspect Oriented Programming(AOP) を利用して、レスポンスタイムやHTTPステータスなど、コードメソッドレベルでテレメトリメトリクスを出力します。 AWS X-Ray トレースを通じて、APS チームはレスポンスタイムの長いコードメソッドを特定し、1 リクエスト中に呼び出されるメソッド数をカウントすることができました。これらのメトリクスを定量化することで、APS チームはデータに基づいてレイテンシーとパフォーマンスの改善施策を推進できました。 AWS X-Ray のトレースは、高レスポンスタイムを消費するコードメソッドを特定し、リクエスト中に消費されるメソッド数をカウントするのに役立ちました。これらのメトリクスを定量化できる機能により、APS チームはデータに基づいたアプローチでレイテンシーとパフォーマンスの改善施策を推進することができました。 API パフォーマンスメトリクスを含む Amazon CloudWatch ダッシュボード: AWS X-Ray を使えば、レスポンスタイム、APIリクエスト数、エラー/フォールト率、スロットル率など、複数の APIに跨ったパフォーマンスの評価軸で、インサイトとメトリクスを得ることができます。これらのメトリクスは Amazon CloudWatch からアクセスできるため、APS チームはその強力な可視化機能を活用することにしました。 データ可視化のために、APS チームは統計、期間、データバケッティングなどの機能を使用しました。棒グラフ、折れ線グラフなどの Amazon CloudWatch の可視化機能を使えば、P50、P90、P99のレイテンシーメトリクスを観察することで、レイテンシーやパフォーマンスの問題がある領域に素早く焦点を当てることできます。 これにより、潜在的なボトルネックを特定し、ユーザーエクスペリエンスを最適化し、強力な Amazon CloudWatch メトリクスアラームを活用してレイテンシーの問題を自動検出できます。 おわりに 要約すると、APS チームはレスポンスタイムが長いリクエストの根本原因を特定できました。APS チームはマイクロサービス API での API レイテンシーに対する SLA (サービス レベル アグリーメント) を設定しました。 ダウンストリームサービスからの生のセグメントデータの収集と、AWS X-Ray を通じて公開されるメトリクスを使用してアラームの構成を行った後、ダウンストリームサービスのレイテンシーダッシュボードを作成しました。 改善の余地のある領域を特定・対応したことで、顧客リクエストのレスポンスタイムを 25 % 削減できました。 この記事はソリューションアーキテクト小森谷一生が翻訳を担当しました。（オリジナルは こちら ）

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 4/1 にチーフエバンジェリストの Jeff Barr さんによる エイプリルフールの投稿 がありました。AWS “Chips” Taste Test と呼ばれるポテトチップスの味を食べ比べするミニ動画です。Graviton チップス、Inferentia チップス、Trainium チップス、Nitro チップスと名付けられた 4 種類のポテトチップスを試食しています。これらの名前は、AWS で提供される CPU やアクセラレーター、専用 HW の名称で、エイプリルフール的に紹介しています。Graviton チップスはチーズ味でした。興味があれば視聴してみてください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月1日週の主要なアップデート 4/1(月) Announcing per-second billing for EC2 Red Hat Enterprise Linux (RHEL)-based instances Amazon EC2 で Red Hat Enterprise Linux (RHEL) を稼働する際に、1 時間単位の課金から、1 秒単位にアップデートしました。この変更により、利用時間に応じてよりきめ細かく料金が算出されるようになり、短時間の利用でも無駄な支払いを抑えられるようになります。例えば、10 分間のみ利用した場合でも、従来は 1 時間分の料金が発生していましたが、今回の変更により実際の利用時間に応じて計算され、安価に利用しやすくなりました。留意点として、最小課金下限として 1 分が定義されています。RHEL を起動して 1 分を越えた場合に、1 秒単位の粒度で料金が計算されます。また、RHEL の料金体系そのものも変更がアナウンスされています。12 vCPU 以下のインスタンスは安価になる一方、16 vCPU 以上のインスタンスは上昇する傾向にあります。詳細は 公式の価格ページ をご確認ください。 Amazon EKS extended support for Kubernetes versions now generally available Amazon EKS の延長サポートが一般提供を開始し、EKS クラスターのサポート期間が最大 26 か月間に延長されました。従来の EKS では、新しい Kubernetes バージョンが利用可能になってから 14 か月間が標準のサポート期間でした。延長サポートを利用することで、標準サポート期間の終了後、最大 12 か月間の追加サポートを受けられるようになります。延長サポート期間では、Kubernetes コントロールプレーン、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、EKS 最適化 AMI、EKS Fargate ノードのセキュリティパッチと重要なパッチが提供されます。Kubernetes バージョン 1.21 以降で延長サポートが利用可能です。延長サポートの料金について、1 個の EKS クラスターに対して、1 時間あたり 0.60 USD の料金が発生します。料金については、 こちら をご覧ください。バージョンとサポート期間の詳細は、 こちら をご覧ください。 Private Access to the AWS Management Console is now available in all commercial AWS Regions AWS マネジメントコンソールのプライベートアクセスが、すべてのリージョンで利用ができるようになりました。この機能の主なユースケースは、組織内の端末から AWS マネジメントコンソールにアクセスする際に、個人利用の AWS アカウントのアクセスを制限することがあげられます。誤解されやすい点ですが、Private Access 機能は閉域網などのプライベートネットワークで、完全に閉じた環境で利用できるのではありません。Web Proxy の利用など、インターネットのアクセスは必要です。画像や JavaScript、CSS はインターネット経由で取得が必要です。また、Private Access で利用できないサービスも存在します。詳細については、 こちらのドキュメント を参照してください。 Amazon RDS for SQL Server supports Single-AZ Read Replica Amazon RDS for SQL Server で、シングル AZ リードレプリカをサポートしました。以前はデータベースインスタンスをマルチ AZ 構成にする必要がありましたが、今回の変更によりシングル AZ データベースインスタンスでもリードレプリカを使用できるようになります。リードレプリカは、ソースデータベースインスタンスとレプリカ間でデータベースを非同期的に複製します。このアップデートで、マルチ AZ が不要な場合でもパフォーマンスを損なうことなく可用性と耐久性が向上します。 4/2(火) Amazon Aurora zero-ETL integration with Amazon Redshift now in additional regions Amazon Aurora MySQL と Amazon Redshift 間のゼロ ETL 統合が、東京と大阪リージョンを含めた、11 のリージョンで追加サポートしました。ゼロ ETL 統合を使用すると、Aurora MySQL のデータを Amazon Redshift に自動レプリケートできます。データ連携の仕組みを構築する負担を軽減して、データ分析基盤や機械学習に活用いただけます。レプリケーションのデータフィルタリング機能を利用でき、柔軟なゼロ ETL 統合をご利用いただけます。 Announcing AWS Deadline Cloud AWS Deadline Cloud をサービスを新たに提供開始しました。 AWS Thinkbox Deadline のフルマネージドサービスとなっており、映画、テレビ、CM、ゲーム、産業デザインのビジュアルアセットのレンダリング管理を支援するサービスです。Autodesk Arnold、Autodesk Maya、Foundry Nuke、Luxion KeyShot、SideFX Houdini などの組み込み統合機能と、幅広いカスタマイズツールが用意されています。東京リージョンを含めた 8 リージョンでサービスが提供されています。 4/3(水) Mistral Large foundation model now available on Amazon Bedrock Amazon Bedrock で Mistral AI 社が開発した Mistral Large モデルを一般提供開始しました。トップクラスの推論能力、特定の指示に従う能力、そして多言語翻訳能力で広く知られています。コーディングと数学的タスクに優れ、英語、フランス語、スペイン語、ドイツ語、イタリア語に堪能です。バージニア北部、オレゴン、パリの 3 リージョンで提供されています。 AWS Clean Rooms ML is now generally available AWS Clean Rooms ML の一般提供を開始しました。企業がそのままの生データを他の企業に共有することなく、データを活用した共同活用をしながら、機械学習を利用して予測的な洞察を生成できます。この機能は、企業が類似セグメントの作成を支援するMLモデルとともに提供されます。例えば、ヘルスケア分野のお客様は、望ましい特性を持つ参加者の一覧を使って、臨床試験や医学研究の参加者の募集に活用できます。東京を含めた 11 リージョンで利用可能です。 4/4(木) Announcing general availability of Amazon EC2 G6 instances Amazon EC2 で、新たに G6 インスタンスの一般提供を開始しました。G6 インスタンスは、NVIDIA の L4 Tensor Core GPU を搭載しており、グラフィックス処理や機械学習の利用に適しています。G4dn インスタンスと比較して、ディープラーニングの推論およびグラフィックスワークロードのパフォーマンスを最大 2 倍に向上させています。G6 インスタンスは現在、バージニア北部、オハイオ、オレゴンの 3 つのリージョンで利用可能です。 AWS Lambda adds support for Ruby 3.3 AWS Lambda で Ruby 3.3 のランタイムをサポートしました。この新しい Ruby 3.3 ランタイムは、Amazon Linux 2023 の minimal コンテナイメージを基に作られています。以前の Amazon Linux 2 ベースと比べると、より小さなリソースで効率的なデプロイが可能になりました。この Ruby 3.3 ランタイムは、AWS Lambda が利用可能なすべてのリージョンで提供されています。 4/5(金) Amazon CodeCatalyst now supports adding tasks to issues Amazon CodeCatalyst のアップデートで、課題管理の Issue ボードに新しい機能が追加されました。これまでは 1 つの Issue に対してサブタスクを設定することができませんでしたが、今回のアップデートで 1 個の Issue に最大 100 個のサブタスクを紐づけられるようになりました。プロジェクトを進めていく上で、大きな課題を細かなサブタスクに分割して管理することは重要です。この新しいサブタスク機能を活用すれば、Issue 単位で進捗を把握しやすくなります。例えば、「新しい機能を実装する」という大きな Issue に対して、「設計を行う」「コーディングを行う」「テストを行う」などのサブタスクを設定することができます。 Amazon IVS Low-Latency Streaming now supports SRT ingest Amazon IVS で SRT (Secure Reliable Transport) プロトコルを使って、映像や音声を配信できるようになりました。これまでの RTMPS に加えて、SRT が利用できるようになった形です。SRT は、信頼性の低いネットワークでのストリーミングを改善し、ジッター、パケットロス、ネットワーク帯域幅の変動から保護するように設計されたプロトコルです。視聴者にとっては、バッファリングが少なく、より高品質の視聴体験が得られやすくなりました。 Amazon VPC CNI now supports automatic subnet discovery Amazon EKS で IPv4 アドレスの枯渇の対応しやすくするため、Enhanced Subnet Discovery の機能を提供開始しました。デフォルトでは、VPC CNI プラグインは、EKS ワーカーノードが稼働する Subnet 上の IPv4 アドレスを Pod に割り当てます。表現を変えると、ワーカーノードが接続されていない Subnet の IPv4 を Pod に割り当てることはできませんでした。Enhanced Subnet Discovery の機能により、VPC 内でタグ付けされたすべてのサブネットを利用して Pod の IP アドレスを設定できるようになりました。VPC 上で IP アドレスが枯渇した場合にも、VPC として CIDR を拡張する機能があり、これも併せることで柔軟な拡張が可能です。Enhanced Subnet Discovery を利用するには、バージョン EKS 1.25 以上、VPC CNI 1.18.0 以上といった前提条件があります。詳細は、こちらの ブログ をご確認ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

３月、2 つの高性能 Mistral AI モデルである Mistral 7B と Mixtral 8x7B が Amazon Bedrock で 使用可能になったことをお知らせしました。Mistral 7B は、Mistral の最初の基盤モデルとして、自然なコーディング機能で英語のテキスト生成タスクをサポートします。Mixtral 8x7B は、テキストの要約、質疑応答、テキストの分類、テキスト補完、コード生成に最適な、人気のある高品質の Sparse Mixture-of-Experts (MoE) モデルです。 4月2日、Amazon Bedrock で Mistral Large が利用可能になったことをお知らせします。Mistral Large は、実質的な推論機能を必要とする複雑なタスクや、合成テキスト生成およびコード生成などの高度に専門化されたタスクに最適です。 Mistral Large について知っておくべきこと: 英語、フランス語、スペイン語、ドイツ語、イタリア語でネイティブレベルの流暢さを備えており、文法や文化的背景のニュアンスをよく理解しています。 32K トークンのコンテキストウィンドウがあり、サイズが大きいドキュメントからでも正確な情報を取得できます。 その正確な Instruction Following により、モデレーションポリシーを設計できます。Mistral AI の人々は、ベータアシスタントデモンストレーターである le Chat のシステムレベルのモデレーションを設定するためにこれを使用しました。大規模言語モデル (LLM) との最初のインタラクションは、プロンプトを中心に展開します。効果的なプロンプトを作成する技術は、LLM から望ましい応答を生成するために不可欠です。また、 Mistral AI はサンプルプロンプトを含むガイド を提供しており、さまざまなプロンプト機能が示されています。 Mistral Large の開始方法 Bedrock で Mistral Large の使用を開始するには、まずモデルにアクセスする必要があります。Amazon Bedrock コンソールで、 [モデルアクセス] を選択してから、 [モデルアクセスを管理] を選択します。次に、[Mistral Large] を選択し、 [変更を保存] を選択します。 Mistral Large にアクセスできるようになると、Bedrock でモデルを使用できるようになります。更新されたステータスを表示するには、ベースモデルのテーブルを更新します。 Mistral Large の 複雑な推論 の側面が機能している様子を見るために、 [プレイグラウンド] セクションで次のプロンプトを試してみました。 プロンプト Calculate the difference in payment dates between the two customers whose payment amounts are closest to each other in the given dataset: '{ "transaction_id":{"0":"T1001","1":"T1002","2":"T1003","3":"T1004","4":"T1005"}, "customer_id":{"0":"C001","1":"C002","2":"C003","3":"C002","4":"C001"}, "payment_amount":{"0":125.5,"1":89.99,"2":120.0,"3":54.3,"4":210.2}, "payment_date":{"0":"2021-10-05","1":"2021-10-06","2":"2021-10-07","3":"2021-10-05","4":"2021-10-08"}, "payment_status":{"0":"Paid","1":"Unpaid","2":"Paid","3":"Paid","4":"Pending"} }' 出力 To find the difference in payment dates between the two customers whose payment amounts are closest to each other, we first need to identify the two closest payment amounts and then find their respective payment dates. The payment amounts are: 125.5, 89.99, 120.0, 54.3, 210.2 The two closest payment amounts are 125.5 and 120.0.The payment date for the payment amount 125.5 is '2021-10-05' and for the payment amount 120.0 is '2021-10-07'. The difference in payment dates can be calculated as follows: Date difference = |'2021-10-07' - '2021-10-05'| = 2 days So, the difference in payment dates between the two customers whose payment amounts are closest to each other is 2 days. 私はこの記事の前半で、Mistral Large が複数の言語でネイティブレベルの流暢さを備えており、文法や文化的背景のニュアンスをよく理解していると述べました。そこで、モデルのフランス語の理解度をテストしてみました。 プロンプト Lequel est le plus lourd une livre de fer ou un kilogramme de plume 出力 Un kilogramme de plumes est plus lourd qu'une livre de fer. Pour comprendre cela, il est important de se rappeler que : 1.Une livre (lb) est une unité de mesure de masse principalement utilisée aux États-Unis et dans d'autres systèmes de mesure impériaux, tandis qu'un kilogramme (kg) est l'unité de base de masse dans le système international d'unités (SI). 2. 1 kilogramme est approximativement égal à 2,2 livres. Donc, un kilogramme de plumes est plus lourd qu'une livre de fer, car il correspond à environ 2,2 livres de plumes. Mistral Large をプログラムで操作する また、 AWS コマンドラインインターフェイス (CLI) と AWS Software Development Kit (SDK) で Amazon Bedrock API を使用してさまざまな呼び出しを実行することもできます。AWS SDK を使用して Amazon Bedrock Runtime API を操作する Python のサンプルコードを次に示します。「You will only respond with a JSON object with the key X, Y, and Z.」(キー X、Y、Z を持つ JSON オブジェクトのみで応答してください) とプロンプトで指定すると、簡単なダウンストリームタスクで JSON 形式の出力を使用できます。 import boto3 import json bedrock = boto3.client(service_name="bedrock-runtime", region_name='us-east-1') prompt = """ <s>[INST]You are a summarization system that can provide summaries with associated confidence scores.In clear and concise language, provide three short summaries of the following essay, along with their confidence scores.You will only respond with a JSON object with the key Summary and Confidence.Do not provide explanations.[/INST] # Essay: The generative artificial intelligence (AI) revolution is in full swing, and customers of all sizes and across industries are taking advantage of this transformative technology to reshape their businesses.From reimagining workflows to make them more intuitive and easier to enhancing decision-making processes through rapid information synthesis, generative AI promises to redefine how we interact with machines.It’s been amazing to see the number of companies launching innovative generative AI applications on AWS using Amazon Bedrock.Siemens is integrating Amazon Bedrock into its low-code development platform Mendix to allow thousands of companies across multiple industries to create and upgrade applications with the power of generative AI.Accenture and Anthropic are collaborating with AWS to help organizations—especially those in highly-regulated industries like healthcare, public sector, banking, and insurance—responsibly adopt and scale generative AI technology with Amazon Bedrock.This collaboration will help organizations like the District of Columbia Department of Health speed innovation, improve customer service, and improve productivity, while keeping data private and secure.Amazon Pharmacy is using generative AI to fill prescriptions with speed and accuracy, making customer service faster and more helpful, and making sure that the right quantities of medications are stocked for customers. To power so many diverse applications, we recognized the need for model diversity and choice for generative AI early on.We know that different models excel in different areas, each with unique strengths tailored to specific use cases, leading us to provide customers with access to multiple state-of-the-art large language models (LLMs) and foundation models (FMs) through a unified service: Amazon Bedrock.By facilitating access to top models from Amazon, Anthropic, AI21 Labs, Cohere, Meta, Mistral AI, and Stability AI, we empower customers to experiment, evaluate, and ultimately select the model that delivers optimal performance for their needs. Announcing Mistral Large on Amazon Bedrock Today, we are excited to announce the next step on this journey with an expanded collaboration with Mistral AI.A French startup, Mistral AI has quickly established itself as a pioneering force in the generative AI landscape, known for its focus on portability, transparency, and its cost-effective design requiring fewer computational resources to run.We recently announced the availability of Mistral 7B and Mixtral 8x7B models on Amazon Bedrock, with weights that customers can inspect and modify.Today, Mistral AI is bringing its latest and most capable model, Mistral Large, to Amazon Bedrock, and is committed to making future models accessible to AWS customers.Mistral AI will also use AWS AI-optimized AWS Trainium and AWS Inferentia to build and deploy its future foundation models on Amazon Bedrock, benefitting from the price, performance, scale, and security of AWS.Along with this announcement, starting today, customers can use Amazon Bedrock in the AWS Europe (Paris) Region.At launch, customers will have access to some of the latest models from Amazon, Anthropic, Cohere, and Mistral AI, expanding their options to support various use cases from text understanding to complex reasoning. Mistral Large boasts exceptional language understanding and generation capabilities, which is ideal for complex tasks that require reasoning capabilities or ones that are highly specialized, such as synthetic text generation, code generation, Retrieval Augmented Generation (RAG), or agents.For example, customers can build AI agents capable of engaging in articulate conversations, generating nuanced content, and tackling complex reasoning tasks.The model’s strengths also extend to coding, with proficiency in code generation, review, and comments across mainstream coding languages.And Mistral Large’s exceptional multilingual performance, spanning French, German, Spanish, and Italian, in addition to English, presents a compelling opportunity for customers.By offering a model with robust multilingual support, AWS can better serve customers with diverse language needs, fostering global accessibility and inclusivity for generative AI solutions. By integrating Mistral Large into Amazon Bedrock, we can offer customers an even broader range of top-performing LLMs to choose from.No single model is optimized for every use case, and to unlock the value of generative AI, customers need access to a variety of models to discover what works best based for their business needs.We are committed to continuously introducing the best models, providing customers with access to the latest and most innovative generative AI capabilities. “We are excited to announce our collaboration with AWS to accelerate the adoption of our frontier AI technology with organizations around the world.Our mission is to make frontier AI ubiquitous, and to achieve this mission, we want to collaborate with the world’s leading cloud provider to distribute our top-tier models.We have a long and deep relationship with AWS and through strengthening this relationship today, we will be able to provide tailor-made AI to builders around the world.” – Arthur Mensch, CEO at Mistral AI. Customers appreciate choice Since we first announced Amazon Bedrock, we have been innovating at a rapid clip—adding more powerful features like agents and guardrails.And we’ve said all along that more exciting innovations, including new models will keep coming.With more model choice, customers tell us they can achieve remarkable results: “The ease of accessing different models from one API is one of the strengths of Bedrock.The model choices available have been exciting.As new models become available, our AI team is able to quickly and easily evaluate models to know if they fit our needs.The security and privacy that Bedrock provides makes it a great choice to use for our AI needs.” – Jamie Caramanica, SVP, Engineering at CS Disco. “Our top priority today is to help organizations use generative AI to support employees and enhance bots through a range of applications, such as stronger topic, sentiment, and tone detection from customer conversations, language translation, content creation and variation, knowledge optimization, answer highlighting, and auto summarization.To make it easier for them to tap into the potential of generative AI, we’re enabling our users with access to a variety of large language models, such as Genesys-developed models and multiple third-party foundational models through Amazon Bedrock, including Anthropic’s Claude, AI21 Labs’s Jurrassic-2, and Amazon Titan.Together with AWS, we’re offering customers exponential power to create differentiated experiences built around the needs of their business, while helping them prepare for the future.” – Glenn Nethercutt, CTO at Genesys. As the generative AI revolution continues to unfold, AWS is poised to shape its future, empowering customers across industries to drive innovation, streamline processes, and redefine how we interact with machines.Together with outstanding partners like Mistral AI, and with Amazon Bedrock as the foundation, our customers can build more innovative generative AI applications. Democratizing access to LLMs and FMs Amazon Bedrock is democratizing access to cutting-edge LLMs and FMs and AWS is the only cloud provider to offer the most popular and advanced FMs to customers.The collaboration with Mistral AI represents a significant milestone in this journey, further expanding Amazon Bedrock’s diverse model offerings and reinforcing our commitment to empowering customers with unparalleled choice through Amazon Bedrock.By recognizing that no single model can optimally serve every use case, AWS has paved the way for customers to unlock the full potential of generative AI.Through Amazon Bedrock, organizations can experiment with and take advantage of the unique strengths of multiple top-performing models, tailoring their solutions to specific needs, industry domains, and workloads.This unprecedented choice, combined with the robust security, privacy, and scalability of AWS, enables customers to harness the power of generative AI responsibly and with confidence, no matter their industry or regulatory constraints. """ body = json.dumps({ "prompt": prompt, "max_tokens": 512, "top_p": 0.8, "temperature": 0.5, }) modelId = "mistral.mistral-large-2402-v1:0" accept = "application/json" contentType = "application/json" response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) print(json.loads(response.get('body').read())) 次のような JSON 形式の出力を取得できます。 { "Summaries": [ { "Summary": "The author discusses their early experiences with programming and writing, starting with writing short stories and programming on an IBM 1401 in 9th grade. They then moved on to working with microcomputers, building their own from a Heathkit, and eventually convincing their father to buy a TRS-80 in 1980.They wrote simple games, a program to predict rocket flight trajectories, and a word processor.", "Confidence": 0.9 }, { "Summary": "The author began college as a philosophy major, but found it to be unfulfilling and switched to AI.They were inspired by a novel and a PBS documentary, as well as the potential for AI to create intelligent machines like those in the novel.Despite this excitement, they eventually realized that the traditional approach to AI was flawed and shifted their focus to Lisp.", "Confidence": 0.85 }, { "Summary": "The author briefly worked at Interleaf, where they found that their Lisp skills were highly valued.They eventually left Interleaf to return to RISD, but continued to work as a freelance Lisp hacker.While at RISD, they started painting still lives in their bedroom at night, which led to them applying to art schools and eventually attending the Accademia di Belli Arti in Florence.", "Confidence": 0.9 } ] } Mistral AI モデルのプロンプト機能の詳細については、 Mistral AI のドキュメント にアクセスしてください。 今すぐご利用いただけます Mistral Large は、他の Mistral AI モデル (Mistral 7B および Mixtral 8x7B) とともに、米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (パリ) リージョンにおいて、 Amazon Bedrock で現在ご利用いただけます 。今後の更新については、 詳細なリージョンのリスト をご覧ください。 community.aws で生成 AI コミュニティと共有し、学びましょう。 Amazon Bedrock コンソール で Mistral Large を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 当社と Mistral AI のコラボレーションと、それが当社のお客様にとって何を意味するかについてお読みください 。 – Veliswa 原文は こちら です。

こんにちは、AWS トレーニングデリバリーマネージャー の西村航です。 本記事は 2022 年 4 月に投稿した AWS 初学者向けの勉強方法 6 ステップ！2022 年版！ という記事を 2 年ぶりにアップデートした内容になります。投稿してから経過した 2 年間で公開された勉強方法を追記して、一部の勉強方法に関してはリンクの最新化を行いました。 皆さん、もしくは皆さんの周りでこんな方はいませんか。「AWS を勉強したいんだけど何から勉強すればよいだろう。どこかに勉強方法がまとまってないかな？」という悩みを抱えている方、または「同僚や部下に AWS の勉強を促しているけど、ちょうど良い教材とか無いかな？」という悩みを抱えている方。本記事はそういった AWS を勉強する際の悩みを抱えた AWS 初学者の方や AWS 初学者を育成する立場にある方を対象にした記事になります。 どのようなステップで知識を深めていけばよいのか、この勉強方法がなぜオススメなのか、疑問点やハマりどころに直面した際にどこのサイトをチェックすればいいのか、などハラオチしながら勉強を進められるように具体的に記載しています。 それでは、私がこれまでにお客様からいただいた質問をベースに、AWS 初学者向けの勉強方法を 6 ステップで順番にお話しします。 ステップ1. まず最初に何をするべき？ まず最初は、AWS が選ばれる理由や、ビジネスでの活用方法やビジネスにもたらす効果を事例ベースで学びましょう。AWS でどういうことができるのか、クラウドのメリットとは何なのか、を理解することで、「なぜ自分は AWS を勉強するのか」という勉強の理由をハラオチさせることができます。 また、皆さんがよく使う動画視聴サービスや EC サイトなど普段利用しているアプリケーションの裏側の仕組みも知ることができるため非常に面白いです。それでは、オススメのリンクを 3 つ紹介します。 1. AWS のクラウドが選ばれる 10 の理由 ★西村イチオシ AWS がお客様に選ばれる理由に関して説明されています。図や表を用いて読みやすく記載されています。「必要な時に、必要な分だけ、低価格で IT リソースを調達可能」「サービスを開始してから〇〇回以上の値下げを実施」など AWS のポイントがシンプルな言葉で説明されていて、分量もちょうど良いです。 2. お客様のクラウド導入事例 多種多様な業種や企業規模のお客様がどのようにクラウドを活用いただいているのかが網羅的にまとまっています。フィルター条件を適用することで、 エンタープライズなどのセグメント別、金融サービスなどの業種別、データレイクなどのユースケース別で見ることもできます。お客様の AWS の活用方法や、お客様のビジネスへの効果などが記載されているため、ビジネスの現場での AWS の活用シーンをイメージしやすくなります。 なお、耳慣れない単語に関しては辞書を引くような感覚で AWS 用語集 を利用いただくと理解が深まります。 3. AWS Summit Japan セッション資料・動画一覧 ( 2013 / 2014 / 2015 / 2016 / 2017 / 2018 / 2019 / 2020 / 2021 / 2022 / 2023 ) 当日のセッションが資料または動画で視聴できます。特にお客様事例セッションは、お客様のシステムにかける”熱意”が伝わってきますし、ビジネス上の課題を AWS でどのように解決していくのかのストーリーが分かりやすく、「AWS を勉強してみよう！」という気分になります。 ステップ2. AWS サービスの全体像を掴むには？ 先ほどのステップでは、AWS が選ばれる理由やビジネスでの活用例に関して説明しましたが、資料に目を通して AWS が提供するサービス数の多さに驚かれた方もいらっしゃると思います。 AWS のクラウドが選ばれる 10 の理由 でも記載されている通り、AWS はお客様の満足度を何よりも大事にしています。そのため、AWS では 200 を超えるサービスを提供しておりますが、その 90 %以上のサービス、機能は全世界のお客様からのリクエストをもとに実装されています。 とは言いつつも、サービスの多さゆえにサービスの全体像を理解するのが少し難しい、というのが初学者の方が最初に直面する壁です。その壁を乗りこえるためには、AWS のサービス群の全体を俯瞰しながら理解していき、点と点を線でつないでいきましょう。オススメの勉強方法は以下の 3 つです。 1. AWS Cloud Practitioner Essentials 日本語実写版 ★西村イチオシ 何度でも視聴できるオンデマンドの AWS デジタルトレーニングが AWS Skill Builder では無料で提供されており、 250 を超えるコースが日本語化されています。その中でも本コースは AWS を全体的に理解したい方を対象としている基礎レベルの内容になっておりますので、技術職の方に限らず営業職の方などにオススメです。日本の AWS 認定インストラクターが日本のスタジオで収録した日本語のコースとなっています。コーヒーショップをベースにした分かりやすいシナリオで、楽しんで視聴できるユニークな構成になっております。 2. Cloud for Beginners 日本語実写版 このコースでは キャパシティプランニングや CIDR といった IT に関する専門用語について適宜解説しながら進行しますので、AWS に関心がある非 IT 領域の方や学生の方にオススメです。ウェブサービスや AWS クラウドがどういうものなのかといった、AWS の学習をはじめる際に前提となる知識を効率よく学ぶことができます。また、コースの後半ではいくつかの代表的な AWS サービスについてとりあげ、その概要について紹介します。 3. AWSome Day Online Conference AWS クラウドジャーニーのはじめの一歩として、AWS に関する基礎知識を約 3 時間で学ぶ無償のオンライントイベントです。定期的に配信していますので、ぜひご参加ください。コンピューティング、ストレージ、データベース、ネットワークといった AWS の主要なサービスを段階的に学ぶことができます。ウェビナー開催中は 1:1 のチャットで AWS エキスパートに質問できますので、疑問点もその場で解決できます。 ステップ3. AWS の各サービスに詳しくなるには？ これまでのステップでは、AWS 全体に関する説明をしてきました。おそらく、各サービスの概要を知るにつれ、知りたいことや疑問点などが出てくると思います。例えば、「サービス A とサービス B は似ているように見えるが違いは何なのか」「サービス C の料金体系はどうなっているのか」「サービス D の設計時の制限値などは無いのか」などなど。 そのため、このステップではさらに一歩ふみこんで、疑問点を解消しつつ AWS の各サービスを深堀りしていくためのオススメのリンクを 4 つ紹介します。 1. AWS サービス別資料 ★西村イチオシ 真っ先にオススメするのが、「AWS サービス別資料」になります。サービスの要点をギュッ!と凝縮しつつ、サービス設計時の勘所を押さえた資料になっています。難しい専門用語も比喩表現を交えて分かりやすく解説されているため、気になるサービスに関しては最初に「AWS サービス別資料」に目を通しましょう。トップページの左側の技術カテゴリから選択することもできますし、サービス名で検索することもできます。PDF / YouTube のフォーマットで見ることができます。 2. AWS ドキュメント 「サービス別資料」でサービスの概要を理解した後に、より詳細にサービスの仕様などを理解したい場合は「AWS ドキュメント」を参照しましょう。HTML 形式で見やすい目次が画面左に表示されるので、知りたい情報に簡単にアクセスできます。ユーザーガイドだけでなく、開発者ガイドや API リファレンス、そしてチュートリアルも記載されています。 3. よくある質問 各サービスを勉強していて疑問がわいた時に、最初にアクセスするべきサイトが「よくある質問」になります。各サービスに関する製品および技術上の FAQ 集となっており、どういうサービスで何ができるのかといった基本的なことから、使用できるオプションなどの詳細まで網羅的に記載されています。 4. AWS re:Post AWS re:Post は AWS コミュニティの方々向けの Q&A サービスです。AWS に関する技術的な Q&A を検索したり、専門領域ごとのコミュニティグループに参加することができます。中でもオススメは AWS 情報センター です。AWS 情報センターでは「〇〇というエラーを解決する方法を教えて下さい」「〇〇を設定する方法を教えて下さい」などの実装に関する Q&A が豊富に記載されていますので、サービスを実装してハマりどころに直面した時に参照しましょう。 ステップ4. さらに知識を深めるには？ 「習うより慣れろ」という言葉がありますが、手を動かすことは学習定着率を高める上で非常に有効な方法です。勉強したサービスをハンズオンなどを通じて実際に触ってみることで、知識と実践を結びつけて理解することができます。 しかし、「どのサービスが入門に適しているのか分からない」「構築する際の手順書が欲しい」「できれば簡単なものから始めたい」と言った方もいらっしゃると思いますので、オススメのハンズオンを 3 つ紹介します。 1. AWS Cloud Quest ★西村イチオシ AWS Cloud Quest は実際に AWS を触りつつ初心者でもゲーム感覚で楽しく学べる 3D ロールプレイングゲームです。AWS Cloud Quest はロール毎や課題毎に様々なサービスを利用しながらソリューションを構築していくため、AWS のどのサービスから学習を始めればよいか悩んでいる初学者の方にもオススメのコンテンツとなっております。 また、ゲーム内の課題毎に、課題専用の AWS アカウントが払い出されますので、自身で AWS アカウントを用意する必要がありません。初級である AWS Cloud Quest: Cloud Practitioner は日本語版が無料で利用可能となっておりますので、詳細な説明は ゲームベースで学習できる AWS Cloud Quest: Cloud Practitioner が日本語で学習可能になりました の記事をご確認ください。 2. AWS ハンズオン資料 動画で勉強しつつ、用意されたシナリオと手順書に沿って進める入門者向けのハンズオンになります。特徴として「短い動画を見てからハンズオンで実際に触る」ステップを繰り返す構成になっていますので、歩幅を小さくじっくり理解しながら進めることができます。オンデマンド形式での配信となるので、移動時間などのスキマ時間で学習もできますし、分かりにくい部分を巻き戻して何度でもご覧いただくことができます。 3. JP Contents Hub JP Contents Hub は AWS に関する日本語のハンズオン・ワークショップ情報を一覧化して掲載されているウェブサイトです。このウェブサイトでは “日本語の” ハンズオンを限定して掲載していますので、日本語の手順で AWS のハンズオンを実施したいという方にオススメです。トップページの左側からカテゴリ別にハンズオンを選ぶこともできますし、特定のサービス名やキーワードで検索することもできます。そしてハンズオン一覧は継続的にアップデートされます。JP Contents Hub に関する詳細な説明は AWS 日本語ハンズオンまとめ JP Contents Hub のご紹介 の記事をご確認ください。 ステップ5. 最新情報をキャッチアップするには？ AWS のサービスは改善のサイクルが非常に早いため、サービスを使用する側も常に知識の鮮度を高める必要があります。また、最新技術を知ることで設計の幅を広げることもできます。 そのため、このステップでは各サービスの最新情報を効率よくキャッチアップできるオススメのリンクを 5 つ紹介します。 1. Amazon Web Services ブログ ★西村イチオシ 本記事を掲載している Amazon Web Services ブログ です。RSS 登録が可能です。AWS のサービスに関するアップデートを詳しく説明した記事など AWS 関連の様々な情報を掲載していますが、特に 週刊 AWS は要チェックです！前の週に公開された主要なアップデートや、日本のお客様に興味を持っていただけそうなものをピックアップして紹介しているので、「ちょっと先週は忙しくて AWS の最新情報を追いきれてない…」という方の助け舟になりますし、ダイジェスト版として重宝いただけると思います。 また、関連するブログとして AWS Startup ブログ と AWS JAPAN APN ブログ もオススメですので合わせてチェックしましょう。 2. AWS の最新情報 AWS の各サービスに関して、「〇〇サービスが東京リージョンで利用可能になりました」などの最新のアップデートが掲載されています。新しい機能拡張など設計にひびくアップデートもありますので、チェックしましょう。なお、本サイトは RSS 登録が可能ですので、RSS リーダーのスマートフォンアプリを利用することで、更新情報を自動的に取得することもできます。 3. builders.flash ディベロッパー向けのウェブマガジンで、様々なレベルの方に向けてバラエティに富んだ記事構成になっています。 AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?   などの AWS の設計や開発に関する記事だけでなく、 ハンズオンの「腹落ち問題」を改善する 5 Tips といった役立つ Tips をまとめた記事もあります。また手前味噌ですが、有識者に勉強方法をインタビューする ネットワークの勉強方法を聞いてみた といった初学者向けの記事などもあります。メンバー登録することでハンズオン記事をためす際に使える無料クーポンが配布されるなど様々な特典が用意されていますので、ぜひメンバー登録をしましょう。 4. SNS ( X / Facebook / YouTube ) オンラインイベントの配信開始などリアルタイム性のある内容に関しては X や Facebook をフォローすると情報を追いやすくなりますし、ブログ更新やセミナーの資料公開などの通知系の内容も投稿されています。また、様々な基調講演の内容なども YouTube で随時アップされますので、こちらもチャンネル登録しておきましょう。 5. AWS イベントスケジュール 開催を予定しているライブ配信イベントを一覧で確認することができます。また早期登録キャンペーンなど得する情報もチェックすることができますし、定期期にイベント情報をメールで取得することも可能です。なお、ライブ配信だけでなくオンデマンド配信のコンテンツも検索できますし、カテゴリーでお好みのイベントをフィルタリングすることもできます。 ステップ6. 中級レベルの情報を身に付けるには？ これまでに紹介した勉強方法を実践して基礎が固まってきた方、高度な情報にアクセスしたくなった方、より現場寄りなハンズオンを実装したい方に向けた勉強方法を 5 つ紹介します。 1. AWS アーキテクチャセンター ★西村イチオシ エキスパートがまとめた AWS の技術リソース郡を一覧できます。ドキュメントに関しては AWS ホワイトペーパーとガイド ではベストプラクティス等が記載された技術文書が集まっていますが、特に AWS Well-Architected Framework は設計原則と質問から構成される必読の AWS クラウドのベストプラクティス集になります。 また、  The Amazon Builders’ Library では Amazon のエンジニアが実際に開発・設計・リリース・運用する方法を説明していて、設計に関する考慮事項などの生の声が記載されていてオススメです。 2. AWS ソリューションンライブラリ AWS によって検証済みの実装例が参照できます。構成例に関しては 目的別クラウド構成と料金試算例 で代表的な構成とその試算例を幅広く紹介されていますので初回導入検討時の情報として活用いただけますが、より多くの構成例を確認したい場合は AWS リファレンスアーキテクチャ図 をご確認ください。200 を超えるアーキテクチャ図が掲載されていてポイントごとに解説もありますし、カテゴリ別・業種別にフィルタリングもできます。なお、お客様とパートナー様が実装したアーキテクチャを解説する動画を視聴できる This is My Architecture もオススメです。 3. クラウドコンピューティングコンセプトのハブ クラウドコンピューティングコンセプトのハブでは、クラウドコンピューティング関連の用語に関して深く分かりやすく説明された記事を閲覧して検索できる場所です。例えば ゼロ ETL とは何ですか？ の記事では、ゼロ ETL の概要説明だけでなく、解決する課題やメリット、そしてユースケースまで網羅的に説明されています。他にも、機械学習とは？DevOpsとは？など、改めて正しく深く理解したい用語が出てきた際にチェックしてみましょう。 4. ハンズオン 初級者向けのハンズオンをステップ 4 でご紹介しましたが、他にも複数のハンズオンがあります。 ハンズオンチュートリアル  や AWS Workshops  や  Modernization Workshops で探すことができます。前提条件や手順など含めて詳細に記載されています。オススメできるポイントとしては、レベルだけでなく、カテゴリ（セキュリテイ、IoT など）やタグ（Amazon VPC などのサービス名）が各ハンズオンで記載されていますので、習熟度や目的に応じてハンズオンをピックアップすることができます。 ちなみに、 AWS Samples や Amazon Web Services – Labs では GitHub 上に様々なワークショップのソースコード等を公開していますので、合わせてチェックしてみてください。 5. イベント 多くの新サービスや新機能が発表される AWS 最大のラーニングカンファレンスである AWS re:Invent など各イベントのコンテンツを一覧で確認できるのが AWS Events Content になります。ページ左側のフィルターでイベントだけでなく、レベルやカテゴリもピックアップできます。新サービスや新機能だけでは無く、サービスのベストプラクティスやデータ移行のワークロードなど面白いセッション資料も多数用意されていますので、是非目を通してみましょう。 お知らせ（AWS Skill Builder / AWS クラスルームトレーニング） 何度でも視聴できるオンデマンドの AWS デジタルトレーニングが AWS Skill Builder で公開されています。勉強の成果を確認するために AWS 認定資格を取得したいというお客様は、無料の公式練習問題集で認定試験の形式を確認できますし、トレーニングカテゴリで Exam Preparation を選択いただくと各認定試験の試験準備コースを視聴できます。さらに有償サブスクリプションにお申し込みいただくと、AWS 認定の公式模擬試験、ハンズオン、AWS Jam Journey など追加でコンテンツをお楽しみいただけます。詳細は AWS Skill Builder サブスクリプションのご案内  の記事をご確認ください。 なお、短期間で体系的に学びたいお客様のために、AWS 認定インストラクターが実施する有償集合研修の AWS クラスルームトレーニング も用意されております。オンサイトとオンラインの両方の形式で実施しております。AWS 認定インストラクターによる座学だけでなくハンズオンなども含めた充実した内容となっていますので、是非受講をご検討ください。どのコースを受講するかお悩みの方は AWS 認定インストラクターによる有償トレーニングコースの選び方  の記事を、そして有償トレーニングならではの価値を確認するために AWS 有償トレーニングのメリットってなんだろう  の記事も合わせてチェックしていただければと思います。 まとめ 本記事では、AWS 初学者向けの勉強方法を紹介しました。今日から早速始めてみましょう。 最後まで読んでいただき、本当にありがとうございました！ 著者について 西村 航 (Wataru Nishimura) @kuwablo AWS トレーニングサービス本部 トレーニングデリバリーマネージャー ツーリングが好きです。

コンタクトセンタープラットフォームを変革するという企業の決断には、技術的な改善の観点だけでなく、人的な観点も必要です。 Amazon Connect は、コンタクトセンター業務を変革したいと考えているあらゆる企業向けの、業界をリードするソリューションです。アメリカの技術調査およびコンサルティング企業である Gartner は、 2023 Gartner Magic Quadrant for Contact Center as a Service (CCaaS) を発表しました。AWS は、AI を活用した柔軟性の高いクラウドコンタクトセンターである Amazon Connect を 2017 年に発表して以来、初めてリーダーに選ばれました。お客様が Amazon Connect を選択する理由は、迅速な製品・機能の開発、コンタクトセンターの変革とテクノロジーの専門家の数、サードパーティのサービスパートナーや統合パートナーとの関係性が挙げられます。これらにより Amazon Connect はコンタクトセンターの移行とサービス統合に最適なソリューションとなっています。 Amazon Connect 製品はコンタクトセンターの技術基盤とデータ基盤を変革できますが、その活用には人的レベルの変革も必要です。 私は AWS プロフェッショナルサービス のエンゲージメントリーダーとして、小規模のお客様からフォーチュン 150 のお客様まで、様々なお客様を対象に Amazon Connect の導入を主導してきました。私の経験では、企業は導入後の運用サポートについて十分な優先順位を付けていません。プロフェッショナルサービスや AWS パートナーネットワーク の認定企業が、お客様のビジネス価値の期待に応える、または期待を上回るソリューションを設計、開発、テスト、そして本番環境に導入したら、次は何をすべきでしょうか。彼らの組織が引き続き、オンプレミスのコールセンターシステムを使用した運営方法に則っている場合、その企業はどのように今後規模を拡大し、最適化するのでしょうか。これこそが、エンゲージメントリーダーとお客様のリーダーが早い段階で足並みを揃え、頻繁に再検討しなければならない、導入の次のフェーズの考え方です。 AWS プロフェッショナルサービスの Amazon Connect プリンシパルコンサルタントである Naomi Hall は、2022 年 11 月の re:Invent で、 コンタクトセンターの変更管理 の重要性について講演しました。Naomi はステージに上がり、意図しない変更によってもたらされる、顧客体験のレジリエンシーに影響を与えるリスクの軽減のために、変更管理がいかに重要であるかについて話しました。 Naomi は、Amazon Connect に移行するビジネスリーダーが以下の分野を最優先に考えることを推奨しました。 開発プロセスの定義と文書化 AWS Lambda 関数と Amazon Lex ボットのエイリアスの利用 実稼働前の開発環境でのテストとデバッグ 独立した実稼働前環境での ユーザー受入テスト (UAT) 実施 自動化による不注意での変更リスクの低減 特に運用環境における最小権限アクセスの遵守 ソリューションの運用と拡張、エスカレーション手順に必要な役割と責任を持ち、運用の知識を集約する Center of Excellence (CoE) の確立 AWS ホワイトペーパー「 人工知能、機械学習、および生成 AI のための AWS クラウド導入フレームワーク 」では、コンタクトセンターのチーム変革の概念についてさらに詳しく説明しています。このホワイトペーパーの中では AI/ML ファーストの考え方ではなく「人」という視点の必要性を説明しています。Amazon Connect の使用が単なる技術的変革ではないことを理解することが、ユーザーに採用され、開発者や保守担当者がオーナーシップを発揮するための鍵となります。 Contact Center of Excellence (CCoE) として、以下の項目を検討することをお勧めします。順不同です。 変革をリードするチャンピオンの配置 Amazon Connect の導入には、多くのチームや業務が関わっています。チームには開発者、品質管理エンジニア、プロダクトオーナー、ビジネスアナリストが含まれ、業務の変革ではなく、まず導入に集中します。そして本番運用後の変革に焦点を当てる責任者を 1 人置くことが重要です。多くの場合、お客様はテクニカルデリバリーマネージャーまたはプロダクトオーナーを任命し、変革を彼らに委ねます。大規模なチームの取り組みをまとめた経験のある人を探すことを考えてみてください。開発とデプロイの期間、すべてのチームと連携し、障害を取り除き、意思決定者がいない場合は意思決定を行うことができる人が必要です。つまり、問題は起こりうり、リスクは存在するが、それでも変革が必要であることを理解している人でなければなりません。 ビジョンとすり合わせる チームには意思決定の根拠となる何かが必要です。例えば「完了」「技術面の準備ができた」とは何を指すのか。「成功」の定義は何か。 総合的な人材の発見とレビューの実施 この取り組みを最初から最後までサポートできる適切な人材はいますか。その人材は開発だけでなく、サポートに必要なスキルを持っていますか。 組織の管理変更に必要な指示 オンプレミス運用から Amazon Connect、あるいはハイブリッドモデルへの移行は、さまざまなレベルで、程度の差こそあれ、変化をもたらすでしょう。以前は必要なかった役割で、今必要なのはどのようなものですか。ビジネスを合理化するために、どこにリソースを割り当てるか、あるいは職務をなくせばよいでしょうか。変化が起こる前に対処すべき法務上および労働管理上の考慮事項はありますか。組織に、計画を実行するための指導やテンプレートを提供してくれる、認定された管理変更の専門家がいるかどうかを確認してください。 リーダーシップの役割と責任 各チームにプロダクトオーナーとテクニカルデリバリーリーダーを配置することをお勧めします。プロダクトオーナーは、ビジネスの視点を代表し、どのような価値を提供すべきかを理解しているビジネスサイドのメンバーです。テクニカルデリバリーリーダーは、開発がどのようなものであるべきかを理解しているメンバーです。 製品ロードマップの決定 製品ロードマップはありますか ? 製品ロードマップのイテレーションが UAT の完了時で終了していた場合、ロードマップは十分ではありません。また、テクノロジーだけにとどまってはいけません。Amazon Connect を使い始めてから 3 日、3 か月、3 年経った時、組織の人材、プロセス、手順はどのようになっているか定義します。 結論 コンタクトセンターの変革を決定では、ほとんどの企業が、どのプラットフォームを使用するかを決定するために時間と費用を費やしています。Amazon では、変革を行う最初のステップとして、コンタクトセンターに関するリソース、お客様の事例、AWS プロフェッショナルサービスを豊富に提供しています。Amazon Connect は業界をリードするコンタクトセンタープラットフォームです。そして、Amazon Connect を特別なものにしているのは、実装、運用、使用に関わる人々です。彼らは皆さんのクラウドジャーニーを支えてくれるでしょう。 著者について Corey Miller は、AWS プロフェッショナルサービスのシニアエンゲージメントマネージャーです。彼の職務は、お客様向けの導入プランを策定し、AWS、AWS パートナー、お客様チーム間の相乗効果を生み出すことです。Corey は 2 年ほど前に AWS に入社し、それ以前は米空軍に 28 年間勤務していました。Corey は旅行、ゴルフ、そして妻と 2 人の娘と過ごす時間を楽しんでいます。     翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は 2024 年 2 月 7 日に Neil Baillie (Principal Consultant) 、Sean O’Sullivan (Cloud Infrastructure Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ハイブリッドクラウド環境間で大量のデータを移行するのは、オンプレミスとクラウドの両方のネットワーク、ストレージ、コンピューティング、オペレーティングシステムレイヤーの技術的な制限の中で様々な要件が生じるため、大変な作業に見えるかもしれません。ユーザーは、コンプライアンス要件を満たすためにタスクスケジュールと転送時間を最適化しながら、復旧時間目標 (RTO) と復旧ポイント目標 (RPO) のバランスを取る必要があり、さらに難しい課題に直面します。これらの課題は、ハイブリッド環境間のレイテンシーやネットワーク帯域幅の制限などの技術的制約、移行が必要なデータセットの大きさや量など、様々な形で現れます。 2024 年 2 月 7 日、 AWS DataSync は、 マニフェスト をサポートすることを発表しました。これは、DataSync タスクで転送するソースファイルまたはオブジェクトの明確なリストを指定できる新機能です。マニフェストを使用すると、タスクで処理する必要がある一部のファイルまたはオブジェクトのみを指定することで、タスクの実行時間を短縮できます。 本記事では、DataSync が Amazon Simple Storage Service (Amazon S3) にある 1 億を超えるソースオブジェクトをどのように扱うのか、どのようにこれらのオブジェクトを自己管理型ストレージにコピー、同期するのかについて説明します。データ転送時の長い待ち時間のようなスケーリングを阻害する問題を防ぎ、より効率的にデータを移動するためのお勧めの方法を紹介します。 DataSync の概要 DataSync は、AWS への移行をシンプル化し、AWS へのデータ転送を加速します。オンプレミスのストレージ、エッジロケーション、他のクラウド、AWS Storage 間のデータ転送を迅速かつセキュアに行えるよう支援します。 大量のデータ (例えば 1 億件以上の S3 オブジェクト) の転送に DataSync を利用するユーザーは、DataSync に備わっている固有の上限値の範囲内を意識しながら、データ転送タスクを最適化する方法について戦略的に検討する必要があります。 マニフェストファイルの概要 マニフェストは、DataSync で転送したいファイルまたはオブジェクトのリストです。例えば、S3 バケット内のすべてのオブジェクトをコピーする代わりに、DataSync はマニフェストに含まれるオブジェクトのみをコピーできます。この機能により、ユーザーは DataSync で転送するものをより正確に制御できます。大規模に特定のファイルセットをターゲットにする場合、 インクルードフィルター の使用よりもマニフェストファイルの利用が好ましいでしょう。 関連するクォータの確認 AWS DataSync のクォータ では次のように記載されています。 タスクごとのファイルまたはオブジェクトの最大数は 5,000 万個です。目標が 1 億個を超えるオブジェクトを対象とする場合は、まずこの最初の制限を克服する必要があります。 上記のタスクフィルターに含めることができる最大文字数とタスク実行履歴が保持される日数のクォータも、ソリューションの作成を進めるにあたって関連します。 ソリューションの概要 このソリューションには次が含まれます。 データの再編成 : ソースデータを分割し、DataSync のタスク実行あたりの最大オブジェクト数の制限内に収めます。 マニフェストファイルを使ったイベント駆動 : 新規または変更されたデータのみを処理するタスクを構成します。 インクルードフィルターを使った大量一括処理 : 自動でソースデータを DataSync タスクが実行できるように大きなバッチに分割します。 前提条件 このソリューションでは、下記が必要です。 AWS アカウント DataSync の エージェント 中級程度の Python プログラミングスキル ソリューションの説明 次のセクションでは、さまざまなアプローチについて説明します。 データの再編成 DataSync タスクを設定する際は、タスクのクォータである 5000 万件未満にオブジェクト数を抑えるようタスクを定義するため、ソースデータの構造を整理してください。この再構成を行う際のオプションを、次の例で示します。 タイムスタンプに基づいて、オブジェクトをパスごとに別のバケットに分割。 オブジェクトの数が閾値に達したら、新しいパスまたはバケットを使用。 ただし、ソースデータに関連する特定のワークロードや他の外部要因によっては、これらが現実的でない場合があります。 マニフェストファイルによるイベント駆動 イベント駆動型のアプローチを利用すると、DataSync で転送されるべきファイルのみが特定のタスク実行に含まれるようになります。 manifest-config を指定した start-task-execution を呼び出すことで、DataSync タスク実行に対象のファイル/オブジェクトのリストを含むことができます。アプリケーションプログラミングインタフェース (API) のコードの詳細は、 DataSync ドキュメント で確認できます。 マニフェストファイルによって、スキャンと処理の対象がマニフェストファイルに指定されたファイル/オブジェクトだけに制限されます。これによって DataSync の全体の実行時間が短縮され、Amazon S3 のスキャン費用も最小限に抑えられます。 Amazon S3 に新しいオブジェクトが作成されると、 s3:ObjectCreated イベントが Amazon EventBridge に配信されます。Amazon S3 にアップロードされる新しいオブジェクトごとに、EventBridge はそのオブジェクトを記載する JSON ペイロードを、 Amazon Simple Queue Service (Amazon SQS) キューに送信します。 Amazon SQS をイベントの宛先とすることで、これらのイベントが処理のために持続的に取得されます。 AWS Lambda は、Amazon SQS との統合によりダイレクトで同期したイベントペイロードを処理するために必要な計算リソースを提供します。この統合により、 バッチウィンドウ を利用することで、最大 5 分間レコードをバッファリングすることが可能になります。 ソースバケットへのオブジェクトのアップロード頻度によっては、5 分より長い時間バッファリングできます。より多くのオブジェクトを渡すことで、DataSync タスクの呼び出し回数が減る利点があります。ただし、転送に遅延が生じます。より大きなデータセットを転送する影響と、RPO への影響のどちらを重視するかを評価する必要があります。 5 分より長いバッファ時間を実装するには、 スケジュールに従って実行する Amazon EventBridge ルールの作成 を使用することができます。 Amazon SQS からのメッセージの取得 Amazon SQS キューからメッセージを読み取るために、Lambda 関数は boto3 Amazon SQS クライアントライブラリの get_queue_attributes と receive_messages API コールを使用します。 Lambda 関数は利用可能なメッセージ数を理解するために、キューの長さを取得します。この値は実行中のキューの残っているアイテム数と比較することができます。これにより、すべてのメッセージが取得されることが保証されます。あるいは、単一のタスク実行でオブジェクトの数を制限したい場合もあります。これは、キューにメッセージを残すことで実現できます (RPO に影響を与える可能性があります) 。または、複数のタスクを生成することで実現できます (DataSync でキューされた後に、全体のジョブの一部として単一のタスクを停止または再開する必要がある場合、運用上使いやすいかもしれません) 。 import boto3 import os sqs_client = boto3.client('sqs') queue_url = os.environ['QUEUE_URL'] # Get the SQS queue length resp = sqs_client.get_queue_attributes( QueueUrl=queue_url, AttributeNames=[ 'ApproximateNumberOfMessages', 'ApproximateNumberOfMessagesNotVisible' ] ) approximate_queue_length = resp['Attributes']['ApproximateNumberOfMessages'] Amazon SQS のキューにあるメッセージ数を把握した後、最適なパフォーマンスを得るために各 DataSync タスクに送信するメッセージの総数を検討します。単一の DataSync タスクにメッセージを過剰にロードすると、遅延が発生する可能性があります。これは、DataSync がタスクを順次実行し、アクティブな DataSync タスクが完了するまでタスクがキューイングされるため、Amazon SQS キューに到着する新しいメッセージの全体的な処理時間に影響します。 この問題を緩和するために、DataSync タスクのオーバーヘッドを減らすように Amazon SQS メッセージをバッチ処理します。 例えば、5 分間で 1,000 メッセージをバッチ処理すると、1 つの DataSync タスクで毎秒 3.3 個の新規オブジェクトを処理できます。一度にバッチ処理するメッセージ数を選択するだけでなく、必要な RPO を確実に満たすために、5 分ごとなど、設定した間隔で Amazon SQS キューを空にする必要があります。 Amazon SQS のメッセージを取得するタイミングでは、 receive_message API を使うと、1 回の API コールで Amazon SQS キューから最大 10 件のメッセージを受信できます。次のコード例では、メッセージ数が 1000 件 または指定した件数になるまで、while ループを使ってキューからメッセージを取得しています。 ボリュームの大きさを考えると、この関数ではパフォーマンスを最適化するために yield 文を使用します。これにより、キューから取得した値のリストはメモリに格納されません。 QUEUE_URL = os.environ[“queue_url”] MAX_RECEIVE = 20000 def process_chunks(queue_length: int): processed_msg_count = 0 max_receive = MAX_RECEIVE receive_count = 0 # receive from SQS queue & build list of messages while receive_count < (max_receive / 10) and processed_msg_count < queue_length: receive_count += 1 try: resp = sqs_client.receive_message( QueueUrl=QUEUE_URL, AttributeNames=["All"], MaxNumberOfMessages=10 ) except Exception as e: logging.error("SQS Retrieve Error") logging.error(traceback.format_exc()) try: msgs = [] for message in resp["Messages"]: msgs.append(message) processed_msg_count += 1 yield msgs # Messages to be sent to DataSync except KeyError: return マニフェストの構築 Amazon SQS キューからメッセージを取得した後、DataSync にメッセージを渡す前にメッセージに対していくつかのアクションを実行する必要があります。 マニフェストファイルを構築するための手順： 各 Amazon SQS メッセージから、S3 オブジェクトの「Key」の値を抽出。 Amazon S3 にマニフェストファイルを書き込み。 重複がないことを確認。 フォルダやプレフィックスは含まれないことを確認。(マニフェストにはオブジェクトのみを含めることができる点に注意) Amazon S3 にマニフェストファイルを書き込む際は、次のルールに従う必要があります： オブジェクトのフルパスを指定する必要があります。フォルダ/パス/ディレクトリだけを指定することはできません。オブジェクトの特定のバージョン (カンマ区切り) を転送するように指定できます。 各オブジェクトは改行文字で区切ってください。 マニフェストファイルは csv ファイル (ファイル名.csv) として保存してください。 必要な IAM 権限： Lambda: Lambda 関数の実行ロールには、マニフェストファイルを含むパス (バケット/フォルダ) への s3:PutObject 権限が含まれている必要があります。 DataSync: DataSync タスクの AWS Identity and Access Management (IAM) ロールには、マニフェストファイルが保存されているパス (バケット/フォルダ) への s3:GetObject 権限と、オブジェクトバージョンを指定する場合は s3:GetObjectVersion 権限が含まれている必要があります。 他の検討事項としては、マニフェストファイル名があります。同じタスクを再実行したい場合、タスクの実行中や実行後にマニフェストファイルを削除または変更してはいけません。1 つの戦略として、Lambda 呼び出しから実行 ID を取得してファイル名に使うことが考えられます。これにより、名前の重複を防ぎ、実行 API にファイル名を渡すことができます。この手法では、Lambda が継続してファイルを生成するため、時々マニフェストバケットをクリーンアップする必要があります。 Amazon SQS メッセージごとに、S3 オブジェクトの「Key」値を抽出： Amazon SQS キューからのメッセージリストを、別の関数に読み込んで、各メッセージから S3 オブジェクトの Key 値を抽出できるようになりました。この関数は、このリストの一部であるディレクトリも処理し、マニフェストファイルから除外します。 def process_chunk_data(messages: list): manifest_data = [] processed_msgs = [] for msg in messages: msg_body = msg["Body"] payload = json.loads(msg_body) msg_key = payload["detail"]["object"]["key"] if msg_key[-1] != "/": # Prevents Dirs from manifest manifest_data.append(msg_key) else: logger.info(f"Directory found. Skipping from manifest: {msg_key}") processed_msgs.extend( [{"Id": msg["MessageId"], "ReceiptHandle": msg["ReceiptHandle"]}] ) return (manifest_data, processed_msgs) 重複する要素がなく、マニフェストファイルに保存される一意な要素のリストを確実に持つために、オブジェクトキーのリストを含むリスト変数 ( manifest_data など) に対して Python の set メソッドを使用します。 マニフェストファイルを Amazon S3 に書き込む： 転送対象のオブジェクトをマニフェストファイルに読み込んだ後、そのファイルをマニフェストバケットにアップロードする必要があります。 ファイル名を一意にするため、この例では、前述のとおり Lambda の呼び出しから context.aws_request_id を使用しています。 def publish_manifest(manifest_data: set, aws_request_id: str, idx: int): filename = f"{S3_MANIFEST_FOLDER}{aws_request_id}_{idx}.csv" result = s3_resource.Object(S3_BUCKET_NAME, filename).put( Body=','.join(manifest_data)[1:] ) if result.get("ResponseMetadata").get("HTTPStatusCode") == 200: logger.info(f"Manifest Upload: Successful: Size: {len(manifest_data)} File: {S3_BUCKET_NAME} {filename}") else: sys.exit(1) return filename DataSync 呼び出し マニフェストファイルが作成され Amazon S3 にアップロードされると、DataSync タスクが実行されます。Lambda 関数は、マニフェストファイルのパスを参照して StartTaskExecution API を呼び出します。 ds_client = boto3.client('datasync') DS_TASK_ARN = os.environ['ds_task_arn'] ds_client.start_task_execution( TaskArn=DS_TASK_ARN, OverrideOptions={ "VerifyMode": "ONLY_FILES_TRANSFERRED", "TransferMode": "ALL", }, ManifestConfig={ "Action": "TRANSFER", "Format": "CSV", "Source": { "S3": { "ManifestObjectPath": manifest_file, "S3BucketArn": S3_BUCKET_MANIFEST_ARN, "BucketAccessRoleArn": DS_S3_ROLE_ARN } } } ) Amazon SQS キューから正常に転送されたメッセージの削除 DataSync タスクが正常に実行された後、Amazon SQS キューのメッセージを安全に削除できます。前の process_chunk_data 関数では、タスクが正常に実行された場合に削除するメッセージを processed_msgs 変数に格納しています。この値は、次の delete_messages 関数に渡されます。 QUEUE_URL = os.environ["queue_url"] def delete_messages(processed_msgs: list): total_msgs = len(processed_msgs) processed_msg_buffer = processed_msgs deleted_msg_count = 0 while len(processed_msg_buffer) > 0: delete_msg_list = processed_msg_buffer[0:10] processed_msg_buffer = processed_msg_buffer[10:] try: resp = sqs_client.delete_message_batch( QueueUrl=QUEUE_URL, Entries=delete_msg_list ) deleted_msg_count += len(resp["Successful"]) except Exception as e: logging.error(traceback.format_exc()) if deleted_msg_count != total_msgs: raise RuntimeError( f"Failed to delete messages: total messages={total_msgs!r} resp={resp!r}" ) else: logger.info(f"Deleted {deleted_msg_count} from the queue") return total_msgs インクルードフィルターを利用した大容量バッチ 最初に大量のデータをシードする必要がある場合、大容量バッチを移動するには DataSync の使用が適しています。オフライン転送の代替手段として、そのタスクを実行頻度や期限によっては AWS Snowball を使用する方法があります。また、イベント駆動型のアプローチと組み合わせて、データセット全体の検証を不定期に実行する場合も DataSync が適しています。 DataSync では、 StartTaskExecution を VerifyMode オプションを POINT_IN_TIME_CONSISTENT に設定して呼び出すことで、データセット全体をチェックおよび検証できます。この場合、目的はデータセット全体を転送して検証することであるため、マニフェストを使用する必要はありません。VerifyMode を他のユースケースのマニフェストとともに使用する場合、オペレーションごとに特定し、転送するファイルのみをターゲットにするために ONLY_FILES_TRANSFERRED を指定する必要があります。 オブジェクトのクォータ バッチアプローチを使用する場合、上限のクォータがどこにあるかを理解するために、さらにいくつかの理論上の上限について説明する必要があります。 タスク実行ごとの最大ファイル数またはオブジェクト数は、5000 万件です。 単一のタスクにキューイングできるタスク実行の最大数は、50 件です。 最大数のタスクがキューイングされた場合のタスクごとの最大オブジェクト数は、25 億件です。 まずタスクがニーズに十分な規模かどうかを評価します。十分でない場合は、複数のターゲットをセットした複数のタスクを定義することを検討してください。 フィルターのクォータ タスクにオブジェクトを含めるには、インクルードフィルターを使用します。フィルターの最大長は 102,400 文字です。このクォータに達するタイミングと方法は、オブジェクトキーで使用されるパス構造によって異なります。パスプレフィックスが長いほど、フィルターの連結が最大長に達するまでの時間が短くなります。 フィルター文字列の作成 フィルターを作成する際は、タスク呼び出しを効率的に使用するために、タスクの最大値を超えないようにオブジェクトを含めてください。 フィルターオブジェクトは次のようになります： includes = [{ "FilterType": "SIMPLE_PATTERN", "Value": str(datasync_filter) }] UUID ベースのバッチ処理 フィルターの長さは、キープレフィックスが UUID (Universally Unique Identifier) を使用している場合、予測可能です。UUID は、各プレフィックスが一意になるように 16 進数 (Hex) で構築されます。詳細は次の表をご覧ください。 フィルターに含まれる桁数が増えると、フィルターに含まれるオブジェクトの数は減少します。桁数が多すぎると、必要なフィルターのプレフィックスの数が増え、全体のフィルター長が長すぎることがあります。含まれる桁数が少なすぎると、オブジェクトが多すぎることがあります。プレフィックスフィルターに含める最適な桁数を見つけるには、調査が必要となります。 例えば、オブジェクトキーでパスプレフィックスが 21 文字あり、1 桁のフィルターが 1 つある場合、21 + 1 = 22 文字になります。 1 桁の場合、16 個のプレフィックスグループが作成されます。区切り文字に | を使用するため、この場合のフィルター文字列の長さは (22 * 16)+ 15 = 367 文字になります。 3 桁の場合、フィルターは 21 + 3 = 24 文字で、プレフィックスグループは 4096 個になります。フィルター文字列の長さは (24 * 4096)+ 4095 = 102,399 文字となり、これは最大長以内です。桁数を増やすと文字列が長くなりすぎて最大長を超えてしまいます。 これらの例はすべて、UUID のサンプルセットが十分に大きく、エントロピーも十分にあり、オブジェクトが 1 桁のマッチプレフィックスに対して均等に分散していることを前提としています。 大容量バッチ UUID のコード例 次のサンプルコードは、前述の最適な処理を実装する方法を示しています。 Python を使用して UUID プレフィックスのフルセットを生成します： datasync_filter = '' number_of_digits = 3 prefix = 'path/to/objects/' hex_range = range(0, 16**number_of_digits) uuid_prefixes = [f"{i:x}".zfill(number_of_digits) for i in hex_range] # These can then be joined with the path prefix to create filter. for uuid_prefix in uuid_prefixes: # Append the Prefix to the Filter, adding delimiter for all but the first if datasync_filter: datasync_filter += '|' datasync_filter += f'{prefix}{uuid_prefix}*' datasync_filter は インクルード フィルターで使用できます。 クリーンアップ 使用されていないリソースは削除し、課金されないようにしてください。削除対象には Lambda 関数、Amazon SQS キュー、Amazon S3 内の使用していないサンプルデータが含まれます。 まとめ 本記事では、AWS DataSync を使って最大 1 億を超えるオブジェクトからなる大規模なデータセットをバッチ処理、処理、転送、検証する方法について説明しました。マニフェストを紹介し、この DataSync の新機能をイベント駆動型アーキテクチャの一部として使用して、タスクで処理が必要なファイルまたはオブジェクトのみを指定することで、タスク実行時間を短縮できることを確認しました。加えて、初期の大量データ転送が必要な顧客向けに、DataSync の インクルードフィルターを使う方法を実演しました。また、AWS DataSync サービスのクォータの一部を概説し、これらのしきい値を回避するためのデータ転送効率化方法を提案しました。 AWS DataSync とマニフェストの詳細については、以下のリンクを参照してください： AWS DataSync マニフェストの特徴 AWS DataSync ドキュメント AWS DataSync コンソール Neil Baillie Neil Baillie は AWS ProServe の Principal Consultant であり、英国中央政府チームの一員です。Neil は 20 年以上の業界経験があり、クラウドアーキテクチャとエンジニアリングのバックグラウンドを持っています。 彼は、お客様によるプロジェクトの実施と AWS の可能性の実現を支援することに重点を置いています。 Sean O’Sullivan Sean O’Sullivan は AWS ProServe のクラウドインフラストラクチャアーキテクトであり、EMEA プロフェッショナルサービスチームの一員です。業界で 7 年以上にわたり、お客様と協力してデジタルトランスフォーメーションプロジェクトを推進し、AWS クラウドを最大限に活用するためのソリューションの設計、自動化、再設計を支援してきました。

この記事は、2024 年 4 月 1 日に Karan Lakhwani によって執筆された「 Use Amazon CodeWhisperer to advance your cloud knowledge 」を翻訳したものです。 Amazon CodeWhisperer は人工知能 (AI) を活用した革新的な生産性ツールで、開発者の生産性を向上させ、クラウドの学習を加速できます。Amazon CodeWhisperer は 機械学習 (ML) を利用して、統合開発環境 (IDE) でインテリジェントなコード提案を行います。 Amazon CodeWhisperer は、何十億行もの Amazon のコードや公開されているコードを学習しています。組み込みのセキュリティスキャンを備えており、特定された問題を改善するためのコード提案を提供し、 AWS のベストプラクティスを満たした AWS サービスのデプロイを容易にします。Amazon CodeWhisperer を使って、コードサンプル、API リファレンス、Infrastructure as Code (IaC) テンプレートを生成することができるため、経験の浅いクラウドアーキテクトから経験豊富な開発者まで、クラウドの習熟度を高めることができます。 このブログでは、開発者やクラウドアーキテクトが Amazon CodeWhisperer を教育のツールとして活用する 3 つの実践的な方法を紹介します。 1. Infrastructure as Code テンプレートを作成する AWS を初めて使う人の多くは、 AWS マネジメントコンソール を使ってリソースを手動でデプロイします。しかし、クラウドの習熟度が高まるにつれ、 AWS CloudFormation や Terraform などのサービスを使った Infrastructure as Code (IaC) の採用が推奨されています。 IaC を使えば宣言的なコードテンプレートを介して AWS インフラストラクチャ全体をデプロイできるため、エラーを低減し、制御された方法で、繰り返し可能かつ拡張性のあるデプロイが可能になります。これらのテンプレートはブループリントの役割を果たし、 AWS リソースのデプロイ方法を学ぶのに最適です。 → Amazon CodeWhisperer を活用 Amazon CodeWhisperer があなたの指示と周辺のコードに基づいて IaC テンプレートを生成することで、 IaC の学習を加速させることができます。以下の例では、AWS CloudFormation テンプレートを作成するための指示をコメントとして記述しました。Amazon CodeWhisperer は、 CloudFormation テンプレートを作成する最初のステップである AWSTemplateFormatVersion セクションを生成しています。 次に、 Virtual Private Cloud (VPC) , サブネット , Elastic Compute Cloud (EC2) インスタンスを作成するための追加の手順を Amazon CodeWhisperer に指示しています。Amazon CodeWhisperer は、 AWSTemplateFormatVersion の行から、これが CloudFormation テンプレートであることを認識し、手順を実行するために必要なコード (グレー色で表示) を生成します。コードを受け入れるには、単純に Tab キーを押すだけです。 Amazon CodeWhisperer でコード生成を行うことで、構文、ドキュメント、リソース仕様を手動で調べる必要がないため、開発プロセスを高速化できます。 クラウド初学者は Amazon CodeWhisperer を使用して、 AWS CloudFormation テンプレートの形式や、 AWS サービスをプログラムでデプロイする方法を素早く理解することができます。このような方法は、新しい IaC の言語を学ぶ時や、クラウド環境を素早く学ぶ必要がある時に出発点として役立ちます。あなたが提供する仕様と指示に基づいて、Amazon CodeWhisperer は開発を進めることができます。 2. 組織のコードベースを学習する 新しいチームに参加したり、新しいプロジェクトに着手したりする際、組織のコーディングやクラウドアーキテクチャのベストプラクティスの複雑さを理解するのは難しいことがあります。Amazon CodeWhisperer は、組織の内部ライブラリやアーキテクチャパターンに基づいて提案を生成するようにカスタマイズできます。これにより、 Amazon CodeWhisperer はより関連性の高いコードを提案し、開発者はより早くオンボーディングでき、AWS クラウドサービスを習得するのに役立ちます。 → Amazon CodeWhisperer を活用 Amazon CodeWhisperer は、組織の GitHub, AWS CodeCommit, その他の Git リポジトリに接続できます。その後、 Amazon CodeWhisperer は組織にカスタマイズされたコード候補を生成し、ドキュメントや様々な開発プロジェクトを確認する必要なく、組織のコーディングスタイルとアーキテクチャパターンを迅速に学習できるようサポートします。 さらに、 Amazon CodeWhisperer は経験豊富な開発者やアーキテクトにとって継続的な学習ツールとなります。組織は新しい基準、ライブラリ、フレームワークをコードベースに追加でき、 Amazon CodeWhisperer はそれらを提案に組み込みます。これにより、熟練の開発者はアナウンスやドキュメントの変更を読む必要がなくなり、組織の変更や技術に関する最新情報を入手できます。 3. Amazon CodeWhisperer を Amazon Q と統合して学習を深める 時々、 Amazon CodeWhisperer が提案したコードよりも、さらに詳細な説明やガイダンスが必要な場合があります。このとき Amazon CodeWhisperer は IDE で利用可能なインタラクティブ生成 AI アシスタントの Amazon Q と統合できます。IDE の中で Amazon Q にコードの説明、リファクタリング、修正、最適化を求めることができ、より深い洞察が得られるので、推奨されたコードについてより多くを学ぶことができます。 最初の例において、生成されたコードを範囲選択して右クリックし、 Amazon Q にそのコードを説明するよう求めることができます (下の画像の右側) 。これにより、 Amazon Q チャットボットが開き (画像の左側) 、選択されたコードを説明してくれます。 Amazon CodeWhisperer と Amazon Q の統合により、コード生成と知識習得のループが生まれ、開発者はクラウド上で継続的にスキルアップしながらコーディングの生産性を高めることができます。 Amazon CodeWhisperer をさらに学習しましょう Amazon CodeWhisperer の詳細を学習するには、オンライン学習センターである AWS Skill Builder の無料 30 分コース「 Amazon CodeWhisperer – Getting Started (Japanese) 」をご確認ください。このコースでは、 Amazon CodeWhisperer の主要機能と、お使いの IDE に Amazon CodeWhisperer をインストールとセットアップし、使用開始する方法を学ぶことができます。Amazon CodeWhisperer は、Visual Studio Code, JetBrains IDE, AWS Cloud9, AWS Lambda, JupterLab などで利用可能です。 次に、AWS Jam の「 Build using Amazon CodeWhisperer 」で実践的な経験を積むことができます。これらの課題を通して、時間のかかるコーディングタスクを効果的に行い、生産性を最大化する方法を学びます。この AWS Jam には 7 つの魅力的なチャレンジが含まれており、自分のペースで完了できます。 AWS Skill Builder サブスクリプションの 7 日間無料トライアル を利用して、この Jam を無料で受講できます。 まとめ Amazon CodeWhisperer は、開発者やクラウドアーキテクトが AWS やその組織のアプリケーション開発プロセスについて学ぶ方法を強化する強力な AI ツールです。Amazon CodeWhisperer のコード生成機能、組織のコードベースに関する知識、Amazon Q との統合を活用することで、クラウドネイティブアプリケーションを構築しながら AWS について学ぶことができます。ぜひ深く掘り下げて、Amazon CodeWhisperer にクラウド教育を導いてもらいましょう! このブログは生成 AI モデルの Claude の支援を受けて執筆しました。このブログの構文とコンテンツを補強・改善するために Anthropic AI アシスタントを使用しています。 https://www.anthropic.com この記事の翻訳は Technical Instructor の西村 諄が担当しました。

このブログ記事は、トヨタ自動車 社会システム PF 開発部 坪田 沙弥香氏 とアマゾン ウェブ サービス ジャパン シニアソリューションアーキテクト 安藤 正祥、 同社 クラウドインフラアーキテクト 笹原 悠馬が共同で執筆し、トヨタ自動車が監修しています。 イントロダクション トヨタ自動車 (以下、トヨタ) は、大阪府堺市と共に現場状況が分かりにくい交通事故などの緊急を要する事案に対して、現場付近を走行する車両のドライブレコーダーの映像を活用する共同実証実験を行っています。 本記事では、トヨタがアマゾン ウェブ サービス (AWS) を活用し、「消防向けドラレコ映像活用システム（以下、消防ドラレコ）」を開発した事例についてご紹介します。 トヨタイムズニュース「人命救助へ1分1秒　交通死傷者ゼロへ堺市と協同 (toyotatimes.jp) 」 2024 年 3 月 18 日掲載 トヨタイムズニュース「堺市消防局とトヨタの新たな挑戦　火災や事故でドラレコ活用 (toyotatimes.jp) 」 クルマのデータ活用が示す可能性。お客様に安心・安全を贈るためのモビリティサービス｜トヨタ自動車株式会社｜就活・転職活動に役立つキャリア学習サイト (talent-book.jp) 背景 119 番通報は、災害現場に直面し心理的に余裕がない方からの通報も多く、現場状況を正しく把握できないことがあり、その結果として消防隊は現場に到着してから、緊急車両の追加出動や装備の見直しをすることもあります。消防ドラレコは、消防指令センターのオペレーターが 119 番通報だけで現場状況の把握が難しい場合、付近を走る車両のドラレコ映像を活用し、迅速かつ適切な消火、救急、救助活動に役立てるものです。 ソリューションの概要 119 番通報だけでは把握しきれない現場の状況をより正確につかむために、消防指令センターのオペレーターが消防ドラレコを通じて付近の車両の映像を閲覧します。現在、共同実証中の堺市では、協力企業と連携し、堺市消防局管内を走るバスやトラックなど約 400 台に搭載したドライブレコーダーからの映像を活用しております。 システムの特長（情報の流れイメージ） 出典：トヨタ 119 番の通報内容から消防指令センターのオペレーターが事故などの発生場所を特定 消防指令センターのオペレーターが現場の映像を必要とする事案か判断 2 で必要と判断した場合、システムにて事案発生地点を検索 GPS 情報を利用し、付近を走行するドライブレコーダー装着車両を選定 対象車両のドライブレコーダー映像を取得 消防指令センターでドライブレコーダー映像を確認し、迅速で適切な対応につなげる プライバシー尊重への取り組み 消防ドラレコではバスやトラック等の法人車両に約 400 台の専用ドライブレコーダーを設置し、その映像を活用しています。映像に対してプライバシーへの配慮を施した上で、データを暗号化し保管しています。また、映像には必然的に様々なものが映り込みますので、同じくプライバシーへの配慮に慎重に対応する必要があります。トヨタでは消防向けドラレコ映像活用システムについて、自社で定めるガイドラインに準拠するとともに、映像データに対してプライバシーに配慮した処置を施した上で、データを期限付きで保管するようにしています。これらの映像は、AWS のストレージサービス Amazon S3 に暗号化した状態で保管されていますが、S3 のライフサイクルのルールを活用して保管期限が過ぎたら自動的に削除されます。データベースでは Amazon DynamoDB を活用し、同じく保管期限が過ぎた項目を自動的に削除するように有効期限 (TTL: Time to Live) の機能を活用しています。 一方で人命救助に関わる状況ではより早く消防局に映像を安定的に提供することが期待されます。AWS のサーバーレスサービスを活用することで消防システムに配慮した可用性を実現しています。また、イベント駆動型アーキテクチャを採用することで、スケーラビリティを確保しながらも、プライバシーへの配慮に必要な処置を施しつつ、迅速な映像提供が可能になります。このように、AWS のサーバーレスサービスとイベント駆動型アーキテクチャの採用により、可用性と拡張性の両方が確保されています。 アーキテクチャ概略図 また、トヨタは有識者からのアドバイスのもと、市民への社会受容性調査を実施し、下記 3 点に配慮した上で映像を堺市消防局に提供しています。 堺市消防局で映像は保存せず、専用端末を介し、一時的な閲覧のみを可能にして提供 堺市消防局より閲覧要望のあった地点・時間のドラレコ映像のみを提供 映像に映り込んだ人や車両について個別に追跡したり、その行動特性や移動傾向等を分析したりすることを禁止 リーンな開発プロセス 消防ドラレコの開発は、まず短い期間で MVP (Minimum Viable Product) を開発した後、頻繁にシステムの改修を行いユーザーからのフィードバックを得る、リーン開発で進められています。MVP の開発において、 AWS プロフェッショナルサービス が主に AWS のアーキテクチャ構築への支援と、イテレーティブな開発プロセス習得の支援を行っています。 AWS のアーキテクチャ構築にあたり、AWS のアーキテクトはまず、トヨタの多岐にわたる技術課題を理解した後、それらの課題を解決する柔軟なアーキテクチャの検討を行いました。その結果、トヨタの消防ドラレコには、機能改修のリードタイムを短縮するために、コンピュートには AWS Lambda を、データベースには Amazon DynamoDB と、開発者がアプリケーション開発に注力できるようサーバーレスアーキテクチャが採用されています。また、インフラについては、AWS の各種マネージドサービスを活用することで、データの可用性や拡張性などの非機能要件を AWS で担保しながら、差別化につながらないシステムの維持運用の負荷をオフロードしています。例えば、データのバックアップは、マネージドサービスの機能を用いて行うことで、インフラを追加構築することなく設定のみで実現しています。さらに、エラーや障害の情報は、 Amazon CloudWatch と AWS Chatbot を組み合わせることで、アプリケーションを追加で開発することなく社内のチャットツールに通知をしています。 トヨタは、消防ドラレコの限られた検証期間を最大限活用するために、要件定義、設計、実装、テスト、リリース、ユーザーからのフィードバックをもとにした改善を素早く繰り返すイテレーティブな開発フレームワークとして、スクラムを取り入れています。 AWS プロフェッショナルサービス は、スクラムマスターに各セレモニーのファシリテーションやチーム内の課題管理などスクラムマスターとしての動き方についてコーチングを行うなど、トヨタの開発チームが、スクラムによるイテレーティブな開発プロセスを学び実践するためのトレーニングの提供などの支援を行っています。 このように AWS プロフェッショナルサービス の包括的な支援により、消防ドラレコの初期のシステム開発は迅速かつ短期間に進められ、加えて、トヨタの開発チームは、支援を受けている期間に獲得した AWS 活用に関するナレッジやスキルを継続してその後の開発にも生かし、実装に向けた取り組みを加速させています。 結び トヨタが大阪府堺市と共に取り組む消防向けドラレコ映像活用システムの AWS 活用事例は、車両のドラレコ映像を活用し、迅速かつ適切な消火、救急、救助活動に役立てることで社会に貢献していく願いが込められたものです。 AWS は、社会課題の解決とよりよい暮らしの実現に向け、モビリティ社会の究極の願いである「交通死傷者ゼロ」への取り組みを続けるトヨタへの支援を一層強化していきます。 シニアソリューションアーキテクト 安藤 正祥 クラウドインフラアーキテクト 笹原 悠馬

建築、エンジニアリング、建設 (AEC) や メディア & エンターテイメント (M&E) などの業界のお客様は、映画、テレビ、ゲーム、工業デザインのビジュアライゼーション、および 2D/3D デジタルコンテンツデータを取得して、画像や動画ファイルなどの出力を計算するレンダリングと呼ばれるプロセスを伴うデジタルメディア向けに最終フレームを生成します。また、特に映画やテレビ向けに 16K もの高解像度の 3D グラフィックスや視覚効果 (VFX) を生成するために、レンダリングにはかなり高いコンピューティング性能も必要です。これにより、お客様が一度に実行できるレンダリングプロジェクトの数が制限されます。 高解像度コンテンツのレンダリングに対する需要の高まりに対応するために、お客様は多くの場合、数百または数千のコンピューティングノードの性能を組み合わせてレンダリングジョブを処理する、いわゆる「レンダーファーム」を構築します。従来、レンダーファームの構築とデプロイには数週間、場合によっては数か月間かかる場合があり、ハードウェアを調達するために多大な計画と事前の取り組みが必要となります。 その結果、効率的な制作のために、お客様はますます、非常に高額な固定費が必要となる可能性のあるオンプレミスの専用レンダーファームではなく、スケーラブルなクラウドベースのレンダーファームに移行しています。しかし、クラウドでのレンダリングでは、依然としてお客様が独自のインフラストラクチャを管理し、プロジェクトごとにコストを管理するための特別なツールを構築するとともに、優先パートナーから提供されるソフトウェアライセンスのコストを自らモニタリングする必要があります。 4月2日、 AWS Deadline Cloud の一般提供の開始を発表しました。これは、クリエイティブチームが数分でレンダーファームを簡単に設定し、より多くのプロジェクトを並行して実行できるようにスケールしながら、使用したリソースについての料金のみを支払うことを可能にする、新しいフルマネージドサービスです。AWS Deadline Cloud は、レンダーファームの作成と管理、進行中のレンダーのプレビュー、レンダーログの表示と分析、およびこれらのコストの簡単な追跡を行う機能を備えたウェブベースのポータルを提供します。 Deadline Cloud を利用すると、デジタルコンテンツ作成 (DCC) ツールの統合とカスタマイズツールが組み込まれているため、ゼロからレンダリングを高速化できます。各ジョブのニーズに合わせてレンダリングパイプラインをカスタマイズするために必要な労力と開発時間を削減できます。また、既に所有しているライセンスを柔軟に使用することも、サードパーティーの DCC ソフトウェアやレンダラー ( Maya 、 Nuke 、 Houdini ) 用のサービスによって提供されるライセンスを使用することもできます。 AWS Deadline Cloud の概念 AWS Deadline Cloud を利用すると、DCC パイプラインやワークステーションから直接、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上でレンダリングプロジェクトやジョブを作成および管理できます。レンダーファーム、キューのコレクション、フリートを作成できます。キューは、送信されたジョブが配置され、レンダリングがスケジュールされる場所です。フリートは、複数のキューをサポートできるワーカーノードのグループです。キューは複数のフリートで処理できます。 プロジェクトに取り組む前に、必要なリソースにアクセスできる必要があります。また、ワークフォースの認証と認可を管理するには、関連付けられたファームを AWS IAM アイデンティティセンター と統合する必要があります。IT 管理者は、閲覧者、コントリビューター、マネージャー、所有者など、さまざまなレベルのユーザーやグループに対して、アクセス許可を作成したり、付与したりできます。 Deadline Cloud の 4 つの主要なコンポーネントは次のとおりです。 Deadline Cloud モニター – ジョブ、ステップ、タスクのステータス、ログ、他のトラブルシューティングメトリクスにアクセスできます。Deadline Cloud モニターは、ジョブの進行状況に対するリアルタイムのアクセスと更新を提供します。また、ログや他のトラブルシューティングメトリクスに対するアクセスも提供し、複数のファーム、フリート、キューのリストを閲覧してシステム使用率を確認することもできます。 Deadline Cloud サブミッター – AWS SDK または AWS コマンドラインインターフェイス (AWS CLI) を使用してレンダリングジョブを直接送信できます。Deadline Cloud サブミッターを使用して DCC ソフトウェアから送信することもできます。Deadline Cloud サブミッターは、オープンソースのテンプレート仕様である Open Job Description (OpenJD) をサポートする DCC 統合プラグインです。これを使用すると、アーティストは Maya や Nuke などの使い慣れたサードパーティーの DCC インターフェイスから Deadline Cloud にレンダリングジョブを送信でき、そこでプロジェクトリソースが管理され、ジョブが 1 か所でモニタリングされます。 Deadline Cloud 予算マネージャー – プロジェクトのコスト管理に役立てるために予算を作成および編集したり、使用されている AWS リソースの数とそれらのリソースの推定コストを表示したりできます。 Deadline Cloud 使用状況エクスプローラー – 使用状況エクスプローラーを使用すると、Amazon EC2 の公開料金レートと使用状況ベースのライセンス (UBL) に基づいて、おおよそのコンピューティングコストとライセンスコストを追跡できます。 AWS Deadline Cloud の利用を開始する AWS Deadline Cloud の利用を開始するには、Deadline Cloud モニターを使用してファームを定義および作成し、Deadline Cloud サブミッターをダウンロードして、お気に入りの DCC アプリケーション用のプラグインをわずか数回のクリックでインストールします。DCC アプリケーションでレンダリングジョブを定義し、プラグインのユーザーインターフェイス内で作成したファームにそれらのジョブを送信できます。 DCC プラグインは、必要な入力シーンデータを検出し、アカウント内の Amazon Simple Storage Service (Amazon S3) バケットにアップロードするジョブバンドルを構築して、ジョブをレンダリングするために Deadline Cloud に転送し、完成したフレームを S3 バケットに提供して、顧客がアクセスできるようにします。 1.Deadline Cloud モニターを使用してファームを定義する まず、Deadline Cloud モニターインフラストラクチャを作成し、ファームを定義しましょう。 Deadline Cloud コンソール で、 [Deadline Cloud を設定] を選択して、キューとフリート、グループとユーザーの追加、サービスロールの選択、タグのリソースへの追加など、ガイド付きエクスペリエンスを使用してファームを定義します。 このステップでは、Deadline Cloud リソースのすべてのデフォルト設定を選択するために、モニターの設定後のステップ 3 で [レビューにスキップ] を選択します。それ以外の場合は、 [次へ] を選択して、Deadline Cloud リソースをカスタマイズします。 モニターのインフラストラクチャを設定し、 [モニターの表示名] を入力します。この名前により、ファーム、キュー、フリート、使用状況を管理するためのウェブポータルである [モニター URL] が作成されます。設定完了後は、モニター URL を変更することはできません。 AWS リージョン はレンダーファームの物理的な場所であるため、レイテンシーを低減し、データ転送速度を向上させるには、スタジオに最も近いリージョンを選択する必要があります。 モニターにアクセスするために、新しいユーザーとグループを作成して、ユーザーを管理したり (グループ、許可、アプリケーションを割り当てるなど)、モニターからユーザーを削除したりできます。ユーザー、グループ、許可は IAM アイデンティティセンターで管理することもできます。そのため、リージョンで IAM アイデンティティセンターを設定していない場合は、最初にそれを有効にする必要があります。詳細については、AWS ドキュメントの「 Managing users in Deadline Cloud 」にアクセスしてください。 ステップ 2 では、ファームの名前や説明などのファームの詳細を定義できます。 [追加ファームの設定] では、 AWS Key Management Service (AWS KMS) キーを設定してデータとタグを暗号化し、リソースのフィルタリングや AWS コストの追跡のために AWS リソースを割り当てることができます。データはデフォルトで、AWS が所有および管理するキーを使用して暗号化されます。別のキーを選択するには、暗号化設定をカスタマイズします。 [レビューおよび作成にスキップ] を選択すると、デフォルト設定を使用してクイック設定プロセスを完了できます。 さらにオプションの設定を見てみましょう。 キューの詳細を定義するステップでは、キューのために S3 バケットを設定できます。ジョブアセットは、レンダリングプロセス中にジョブのアタッチメントとしてアップロードされます。ジョブのアタッチメントは、定義された S3 バケットに保存されます。さらに、キューのデフォルトの予算アクション、サービスアクセスロール、環境変数を設定できます。 フリートの詳細を定義するステップでは、フリート名、説明、 インスタンスオプション (スポットインスタンスまたはオンデマンドインスタンスのいずれか)、およびインスタンスの数とフリートワーカーの要件を定義するための 自動スケーリング 構成を設定します。デフォルトでは、保守的なワーカー要件が設定されています。これらの値は、レンダーファームを設定した後でいつでも更新できます。詳細については、AWS ドキュメントの「 Manage Deadline Cloud fleets 」にアクセスしてください。 ワーカーインスタンスは、vCPU とメモリサイズを使用して EC2 インスタンスタイプを定義します (例: c5.large 、 c5a.large 、 c6i.large )。ワーカーインスタンスのタイプを許可または除外することで、最大 100 個の EC2 インスタンスタイプをフィルタリングできます。 ファームを作成するために入力したすべての情報を確認し、 [ファームを作成] を選択します。 Deadline Cloud オンボーディングの進行状況が表示され、モニターとファームが使用できる状態になると成功メッセージが表示されます。プロセスの詳細については、AWS ドキュメントの「 Set up a Deadline Cloud monitor 」にアクセスしてください。 左側のペインの [ダッシュボード] で、作成したモニター、ファーム、ユーザー、グループの概要にアクセスできます。 [モニター] を選択してウェブポータルにアクセスし、ファーム、キュー、フリート、使用状況、予算を管理します。ユーザーアカウントにサインインした後、ウェブポータルにアクセスして、作成した Deadline Cloud リソースを探すことができます。 [ダウンロード] ページから、同じユーザーエクスペリエンスを備えた Deadline Cloud モニターデスクトップアプリケーションをダウンロードすることもできます。 モニターの使用方法の詳細については、AWS ドキュメントの「 Using the Deadline Cloud monitor 」にアクセスしてください。 2.ワークステーションを設定し、レンダリングジョブを Deadline Cloud に送信する アーティストが Maya、Nuke、Houdini 内からレンダリングジョブを簡単に送信できるように、Deadline Cloud サブミッターアプリケーションをインストールして、デスクトップでアーティストのためのワークステーションを設定しましょう。左側のメニューペインで [ダウンロード] を選択し、オペレーティングシステムに適したサブミッターインストーラーをダウンロードして、レンダーファームをテストします。 このプログラムは、Maya、Nuke、Houdini 用に Deadline Cloud サブミッター向けの最新の統合プラグインをインストールします。 例えば、デスクトップで Maya とアセットを開きます。テストするレンチファイルのサンプルがあります。メニューバーで [Windows] を選択し、サブメニューで [設定/詳細設定] を選択します。 [プラグインマネージャー] で、 DeadlineCloudSubmitter を検索します。 [ロード済み] を選択して、Deadline Cloud サブミッタープラグインをロードします。 Deadline Cloud サブミッターでまだ認証されていない場合は、 [Deadline Cloud ステータス] タブが表示されます。 [ログイン] を選択し、ブラウザのサインインウィンドウでユーザー認証情報を使用してサインインします。 次に、Deadline Cloud シェルフを選択し、「Deadline」シェルフにあるオレンジ色の Deadline Cloud のロゴを選択してサブミッターを起動します。サブミッターウィンドウから、レンダリングの送信先のファームとキューを選択します。必要に応じて、 [シーン設定] タブでフレーム範囲をオーバーライドしたり、 [出力パス] を変更したり、その両方を行ったりできます。 [送信] を選択すると、レンチターンテーブル Maya ファイルが、必要なすべてのテクスチャおよび Alembic キャッシュとともに Deadline Cloud にアップロードされ、ファームでレンダリングされます。Deadline Cloud モニターでレンダリングジョブをモニタリングできます。 レンダリングが完了したら (ジョブモニターの [成功] ステータスで示されます)、ジョブ、 [ジョブアクション] 、および [ダウンロード出力] を選択します。ジョブのスケジューリングとモニタリングの詳細については、AWS ドキュメントの「 Deadline Cloud jobs 」にアクセスしてください。 DJView などの画像表示アプリケーションを使用して、レンダリングされた画像を表示します。画像は次のようになります。 コマンドラインを使用したデベロッパー側の設定プロセスの詳細については、AWS ドキュメントの「 Setting up a developer workstation for Deadline Cloud 」にアクセスしてください。 3.Deadline Cloud の予算と使用状況の管理 Deadline Cloud のコスト管理をサポートするために、予算マネージャーを使用して予算を作成および編集できます。また、使用状況エクスプローラーを使用して、使用されている AWS リソースの数とそれらのリソースの推定コストを表示することもできます。 ファームの予算を作成するには、Deadline Cloud モニターページで [予算] を選択します。 予算の金額と制限を作成し、自動アクションを設定して、予算を超過する支出を削減または停止できます。 Deadline Cloud モニターページで [使用状況] を選択すると、各ファームで発生しているアクティビティに関するリアルタイムメトリクスが表示されます。ファームのコストをキュー、ジョブ、ユーザーなどのさまざまな変数ごとに確認できます。さまざまな時間枠を選択して、特定の期間中の使用状況を検索し、一定期間における使用状況の傾向を確認できます。 使用状況エクスプローラーに表示されるコストは概算です。リソースを管理するためのガイドとしてご利用ください。Amazon S3、 Amazon CloudWatch 、および使用状況エクスプローラーでは考慮されていない他のサービスなど、接続されている他の AWS リソースの使用により、他のコストが発生する可能性があります。 詳細については、AWS ドキュメントの「 Managing budgets and usage for Deadline Cloud 」にアクセスしてください。 今すぐご利用いただけます AWS Deadline Cloud は現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、および欧州 (アイルランド) リージョンでご利用いただけます。 Deadline Cloud コンソール で AWS Deadline Cloud をぜひお試しください。詳細については、 Deadline Cloud の製品ページ や AWS ドキュメントの「 Deadline Cloud ユーザーガイド 」にアクセスしてください。また、 AWS Deadline Cloud の AWS re:Post 宛てに、または通常の AWS サポートの連絡先担当者を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

この記事は、 Geospatial generative AI with Amazon Bedrock and Amazon Location Service を翻訳したのものです。 通常、地理空間ワークフローは、データを読み込んで変換し、地図、テキスト、グラフなどに可視化します。生成系 AI、自律型 エージェント を利用すると、これらのタスクを自動化できます。このブログでは、 Amazon Bedrock の基盤モデルからパワーエージェントまで、地理空間タスクを完了する方法について説明します。 これらのエージェントは、 Amazon Location Service を通じて利用できるジオコーディングなどのロケーションベースのサービスを使用して、さまざまなタスクを実行し、質問に答えることができます。エージェントを使用して Amazon Bedrock と Amazon Location Service の機能を橋渡しするサンプルコードを示し、構築時の設計における考慮事項について説明します。 Amazon Bedrockは、テキスト、画像、Embedding のための基礎モデルにアクセスするための使いやすい API を提供するフルマネージドサービスです。Amazon Locationは、Esri、HERE、Grab、OpenStreetMap などの信頼できるサードパーティから提供されたデータを使用して、地図、場所、ルーティング用の API を提供しています。 インフラストラクチャを完全に制御する必要がある場合は、 Amazon SageMaker JumpStart を使用することで、基盤モデルをデプロイでき、何百ものモデルにアクセスできます。 ソリューション概要 大規模言語モデル (LLM) の領域では、エージェントは LLM の助けを借りて自律的に推論してタスクを完了できるエンティティです。LLM はテキスト生成だけにとどまらず、会話を行ったり、ドメイン固有のタスクを完了できます。この動作を導くために推論パターンを採用しています。 研究論文「 Large Language Models are Zero-Shot Reasoners 」によると、LLM は知識の限界があるにもかかわらず、高レベルの推論に優れていることが分かります。 私たちは地理空間タスクを処理できるエージェントを作成するために、Amazon Bedrock の基盤モデルである Claude 2 を選択しました。全体的なコンセプトは単純明快で「地理空間データサイエンティストのように考えること」です。 このタスクには、データを読み取って変換し、関心を引くマップに視覚化する Python コードを書く必要があります。そのために Plan-and-Solve Prompting と呼ばれるプロンプトパターンを利用しました。 Plan-and-Solve 戦略を使用すると、最初のタスクとして複数のステップで推論し大まかな計画を立てることができます。これは、エージェントが使用する大まかな計画で、読み込み、変換、視覚化のワークフローに適しています。これらのサブタスクはそれぞれ Claude 2 に送られ、それぞれ解決されます。 ニューヨークにおける Inside Airbnb のリストプライスヒートマップを作成するサンプルタスクを考えてみます。タスクを完了するためのパスを計画するには、エージェントはデータセットを理解する必要があります。エージェントは、データセットの列とデータ型を知る必要があります。データセットからサマリーを生成して、エージェントがユーザーから指示されたタスク (ヒートマップの生成) を計画できるようにします。 前提条件 デモをデプロイするには、いくつかの前提条件があります。 アクセスキー のある AWS アカウント、または、Amazon Bedrock と Amazon Location Service へのアクセス権限のある AWS Identity and Access Management (IAM) ロール が必要になります。Amazon Location Service コンソールを使用して、 マップ 、 プレースインデックス 、および、 Amazon Location Service API キー を作成する必要があります。 また、Docker がインストールされているローカル環境か仮想環境が必要です。今回のデモンストレーションでは、Docker がインストールされた Amazon Linux の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用します。 データを読み込み要約する データセットに関するコンテキストをエージェントに渡すために、データを読み取り、タスクに関連する要約を提供できる Python コードを Claude 2 に生成させます。以下は、プロンプトの一部です。 全プロンプトはプロジェクトの prompts.py ファイルにあります。 Your Role: You are a geospatial data analyzer designed to analyze data schema from arbitrary geospatial datasets. Your Task: You are provided a set of file URLs. You need to generate a Python function that meets the following: Read each file using geopandas. Each file could be CSV, shape file, or GeoJSON. Use built-in function resolved_file_url = get_data_file_url ( file_url, session_id ) to get downloadable URLs. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import geopandas as gpd import pandas as pd import numpy as np def analyze_geospatial_data ( file_urls ) : dataframes = [ ] for file_url in file_urls : resolved_file_url = get_data_file_url ( file_url , 'a5b188fe-91f7-4f92-92fe-c4030721a427' , 'local' ) if file_url . endswith ( '.csv' ) : df = pd . read_csv ( resolved_file_url ) elif file_url . endswith ( '.shp' ) : df = gpd . read_file ( resolved_file_url ) elif file_url . endswith ( '.parquet' ) : df = pd . read_parquet ( resolved_file_url ) elif file_url . endswith ( '.geojson' ) : df = gpd . read_file ( resolved_file_url ) else : raise ValueError ( 'Unsupported file format' ) df = df . sample ( n = 3 , random_state = 42 ) dataframes . append ( { 'file_url' : file_url , 'resolved_file_url' : resolved_file_url , 'data_frame' : df , 'column_names' : list ( df . columns ) } ) return dataframes file_urls = [ 'agent://airbnb_listings_price.csv' ] dataframes = analyze_geospatial_data ( file_urls ) Python agent:// プレフィックスは、このファイルがセッションストレージフォルダー内に保存されていることを CLI に指示します。CLI が実行されると、ローカルデータを保存するための geospatial-agent-session-storage フォルダーが作成されます。エージェントは、アップロードされた Airbnb のデータとその列名を認識します。次に、Claude へ依頼するため、これらのインプットを使用してヒートマップを生成するためのヒントをプロンプトに渡します。 Your Role: You are a geospatial data analyzer designed to analyze data schema from arbitrary geospatial data sets. Your Task: You are provided with a table with some rows data. Your task is to generate a summary that describes the data in the table following the requirements below. The first sentence should be summary of the data in the table from the aspect of the user action. If there is no geometry column in the table, the second sentence should note column names that can be used to generate a geometry column in geopandas. Bash Claude 2 は以下のヒントを返します。 Summary: The table contains columns for listing id, name, host id, host name, location details like neighborhood, latitude, and longitude that can be used to generate a geometry column for plotting. Price column contains listing price that can be used to generate a heatmap of listing prices. Bash ソリューションを計画する Claude 2 に大まかな計画を生成してもらいます。Python の NetworkX というグラフライブラリを使うと、問題解決の手順を計画できます。 前回のプロンプトと同様に、Claude 2 のガイドとなるいくつかの条件を渡します。 Your Role: You are a geospatial data scientist and an expert Python developer. Your Task: A series of consecutive steps. Your Reply needs to meet these requirements: Create a single NetworkX graph. No disconnected components allowed. First operations are data loading. Use geopandas for spatial data. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import networkx as nx G = nx . DiGraph ( ) # Load the data G . add_node ( "airbnb_data_url" , node_type = "data" , data_path = "agent://airbnb_listings_price.csv" , description = "URL for Airbnb listing price data" ) G . add_node ( "load_data" , node_type = "operation" , operation_type = "load" , description = "Load the Airbnb listing price data" ) G . add_edge ( "airbnb_data_url" , "load_data" ) G . add_node ( "airbnb_df" , node_type = "data" , description = "Pandas DataFrame containing Airbnb listing prices" ) G . add_edge ( "load_data" , "airbnb_df" ) # Transform the data G . add_node ( "add_geometry" , node_type = "operation" , operation_type = "transform" , description = "Create a geometry column using latitude and longitude" ) G . add_edge ( "airbnb_df" , "add_geometry" ) G . add_node ( "airbnb_gdf" , node_type = "data" , description = "GeoDataFrame with geometry column added" ) G . add_edge ( "add_geometry" , "airbnb_gdf" ) # Visualize the data G . add_node ( "plot_heatmap" , node_type = "operation" , operation_type = "visualization" , description = "Generate a heatmap of listing prices" ) G . add_edge ( "airbnb_gdf" , "plot_heatmap" ) G . add_node ( "price_heatmap" , node_type = "data" , description = "The heatmap plot showing Airbnb listing prices" ) G . add_edge ( "plot_heatmap" , "price_heatmap" ) Python この NetworkX グラフでは、Claude 2 がプロセスを主に 3 つのセグメントに分解します。 データの読み込み — Airbnb のリストプライスを特定の URL から Pandas データフレームにインポートする データの変換 — 緯度と経度の座標に基づいたジオメトリ列の作成 データの視覚化 — Airbnb のリストプライスを表示するヒートマップの生成 このアプローチにより、地理空間タスクを明確かつ簡単に実装できます。 GraphViz を使用すると、以下のワークフローを視覚化できます。 計画を実行する Claude 2 から生成された計画を実行します。各ステップで Claude 2 に対応するコードを記述します。Claude 2 に焦点を絞るために、各タスクに大まかな条件を設けています。Claude 2 がそれぞれのフェーズで生成したコードについて詳細を説明します。 データの読み込む Airbnb のリストプライスのデータを Pandas DataFrame にロードするには、プロンプトを作成しいくつかのパラメーターを渡します。 Operation_task の「Load Airbnb data」は、上のグラフの load_data ノードを指しています。 Your Role: You are a geospatial data scientist and an expert Python developer. Operation_task: You need to generate a Python function to do: Load Airbnb data. Your Reply needs to meet these requirements: The function definition is: load_data ( airbnb_data_url = 'agent://airbnb_listings_price.csv' ) . When doing spatial joins, retain at least 1 geometry column. Point function requires importing shapely library. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import pandas as pd def load_data ( airbnb_data_url = 'agent://airbnb_listings_price.csv' ) : """ Load Airbnb listing price data """ file_url = get_data_file_url ( airbnb_data_url , session_id , storage_mode ) airbnb_df = pd . read_csv ( file_url ) return airbnb_df Python データの変換 次に、Claude 2 は、 latitude と longitude を使用して DataFrame に geometry 列を追加するコードを生成します。このプロンプトでは、以下の条件を設けています。 Your Role: You are a geospatial data scientist and an expert Python developer. Operation_task: You need to generate a Python function to do: Add geometry column from latitude/longitude. Your Reply needs to meet these requirements: The function definition is: add_geometry ( filtered_df ) . The function return line is: return airbnb_gdf. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import geopandas as gpd from shapely . geometry import Point def add_geometry ( airbnb_df ) : """ Add geometry column from latitude and longitude """ airbnb_df [ 'geometry' ] = airbnb_df . apply ( lambda row : Point ( row [ 'longitude' ] , row [ 'latitude' ] ) , axis = 1 ) airbnb_gdf = gpd . GeoDataFrame ( airbnb_df , geometry = 'geometry' ) return airbnb_gdf Python データの視覚化 最後に、Claude 2 は空間レンダリング用の Python ライブラリである pydeck を使用してヒートマップを生成します。このプロンプトでは、以下の条件を設けています。 Your Role: You are a geospatial data scientist and an expert Python developer. Operation_task: You need to generate a Python function to do: Generate heatmap from price. Your Reply needs to meet these requirements: The function definition is: generate_heatmap ( airbnb_gdf ) . The function return line is: return airbnb_heatmap. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import pandas as pd import geopandas as gpd import pydeck as pdk def plot_heatmap ( airbnb_gdf ) : """ Plot heatmap of listing prices """ price_heatmap = pdk . Deck ( map_style = location_map_style ( ) , initial_view_state = pdk . ViewState ( latitude = airbnb_gdf [ 'latitude' ] . mean ( ) , longitude = airbnb_gdf [ 'longitude' ] . mean ( ) , zoom = 11 , pitch = 50 , ) , layers = [ pdk . Layer ( 'HexagonLayer' , data = airbnb_gdf , get_position = [ 'longitude' , 'latitude' ] , radius = 100 , elevation_scale = 4 , elevation_range = [ 0 , 1000 ] , pickable = True , extruded = True , ) , pdk . Layer ( 'ScatterplotLayer' , data = airbnb_gdf , get_position = [ 'longitude' , 'latitude' ] , get_color = '[200, 30, 0, 160]' , get_radius = 200 , ) , ] , ) # Save heatmap HTML price_heatmap . to_html ( get_local_file_path ( 'airbnb_heatmap.html' , session_id , task_name ) ) return price_heatmap Python Claude 2 の応答には、各関数が指定された条件をどのように満たすかを説明する役立つメモも含まれています。たとえば、ヒートマップの視覚化では Claude 2 は次の点に注目しました。 "This function generates a heatmap of Airbnb listing prices using pydeck and saves the resulting HTML locally. It fulfills the requirements specified in the prompt." 生成されたコードを組み立てる Claude 2 がそれぞれの構成要素を生成したのでまとめます。エージェントは、これらすべてのスニペットを自動的に 1 つの Python ファイルにまとめます。このスクリプトは、各関数を順番に呼び出し、プロセス全体を効率化します。 最終的には、以下のようなコードになります。 session_id = "a5b188fe-91f7-4f92-92fe-c4030721a427" task_name = "1694813661_airbnb_listings_price_heatmap" storage_mode = "local" # Sequentially invoke the functions airbnb_df = load_data ( airbnb_data_url = 'agent://airbnb_listings_price.csv' ) airbnb_gdf = add_geometry ( airbnb_df ) price_heatmap = plot_heatmap ( airbnb_gdf ) Python スクリプトが実行されると、Claude 2 がヒートマップを生成するコードを含む HTML ファイルを作成します。以下の画像は、Amazon Location Service ベースマップのニューヨークに Airbnb のリストプライスヒートマップを表示しています。 Amazon Bedrock で Amazon Location Service を使う Plan-and-Solve エージェントは地理空間タスクを処理できますが、住所のジオコーディングなどのタスクには少し異なるアプローチをとる必要があります。そのためには、LLM を使って推論と実行を組み合わせる ReACT 戦略が使えます。 ReACT パターンでは、エージェントが顧客のインプットと自由に利用できる ツール に基づいて推論し実行します。Claude 2 搭載エージェントにジオコーディング機能を持たせるためのツールを開発しました。このツールは、Amazon Location Service の Places API で SearchPlaceIndexForText メソッドを使用して住所を地理座標に変換します。 Agent: Hi ! I'm Agent Smith, your conversational geospatial assistant. How can I assist you today? You: > ? Hello, can you give me the coordinates for 112 E 11th St, Austin, TX 78701 ? Agent: The coordinates for 112 E 11th St, Austin, TX 78701 are longitude -97.740590981087 and latitude 30.274118017533 . Bash この短いやり取りで、エージェントは住所のジオコーディングを解読し、ジオコーディングツールを起動して、緯度と経度を返します。 ヒートマップのプロット、住所のジオコーディングを行う場合でも、Claude 2 を React や Plan and Solve などのエージェントと組み合わせることで地理空間のワークフローを簡素化できます。 デモをデプロイする デプロイするには、以下の手順をご覧ください。 以下のリポジトリをローカルマシンまたは EC2 インスタンスに複製します。 aws configure --profile <profilename> を実行してデフォルトのリージョンの設定が必要になる場合があります。このアプリケーションは us-east-1 を使用してテストしました。 git clone https://github.com/aws-samples/amazon-location-geospatial-agent/ Bash リポジトリのクローンを作成されたら環境変数を設定します。 ディレクトリを複製されたプロジェクトフォルダーに変更します。 cd amazon-location-geospatial-agent Bash お好みのテキストエディタを使って .env ファイルを編集します。 vim .env Bash API キー、マップ名、プレースインデックス名を追加します。 API_KEY_NAME = AgentAPIKey MAP_NAME = AgentMap PLACE_INDEX_NAME = AgentPlaceIndex Bash 以下のコマンドを実行してコンテナを構築します。 docker build -t agent . Bash 以下のコマンドを実行して Docker コンテナを実行し接続します。 docker run --rm -it -v ~/.aws:/root/.aws --entrypoint bash agent Bash Airbnb のデータセットを取得します。 apt install -y wget wget http://data.insideairbnb.com/united-states/ny/new-york-city/2023-10-01/visualisations/listings.csv cp listings.csv data/listings.csv Bash 以下のコマンドを実行してセッションを作成します。 セッションを使用して独自のチャット環境を分離します。 SESSION_ID = "3c18d48c-9c9b-488f-8229-e2e8016fa851" FILE_NAME = "listings.csv" make create-session Bash これで、アプリケーションを起動する準備ができます。 以下のコマンドを実行してチャットアプリケーションを起動します。 poetry run agent --session-id 3c18d48c-9c9b-488f-8229-e2e8016fa851 --profile < profilename > Bash チャットプロンプトが表示されます。 以下の質問をしてみてください。 I've uploaded the file listings.csv. Draw a heatmap of Airbnb listing price. Bash エージェントは Airbnb_listings_price.csv を取得、CSV ファイルを /data フォルダーにダウンロード、解析して地理空間データフレームに変換します。次に、データを変換するコードと視覚化用のコードを生成します。 最後に、 /data フォルダーに書き込まれる HTML ファイルを作成します。HTML ファイルをブラウザーで開くとヒートマップを確認できます。 別の例では、Amazon Location Service の Places API を使用して住所をジオコーディングしています。エージェントに 112 E 11th St, Austin, TX 78701 の住所をジオコーディングするように依頼すると、以下のような回答が得られます。 まとめ この記事では、Amazon Bedrock と Amazon Location Service の概要と、これらを組み合わせて地理空間データを分析および視覚化する方法について説明しました。 また、Plan-and-Solve と ReACT、エージェントによる使用方法についても説明しました。 私たちのサンプルは入門に過ぎません。サンプルコードをダウンロードして、地理空間タスク用の独自のエージェントとツールを追加してみてください。 著者 Jeff Demuth は 2016 年に Amazon Web Services (AWS) に入社したソリューションアーキテクトです。 彼は地理空間コミュニティに焦点を当てており、地理情報システム（GIS）とテクノロジーに情熱を注いでいます。 仕事以外では、旅行、 Internet of Things (IoT) アプリケーションの構築、最新のガジェットに触れ楽しんでいます。 Swagata Prateek は、Amazon Web Services (AWS) の Amazon Location Service で働いているシニアソフトウェアエンジニアで生成系 AI と地理空間について重点的に取り組んでいます。

AWS  の最高情報セキュリティ責任者 (CISO) として、私は個人的にあらゆるスキルレベルと規模のセキュリティチームが生成AI のセキュリティをナビゲートできるよう支援することに全力を注いでいます。以前は AWS  のお客様であった私は、実践的にセキュリティを学び、AWS  セキュリティを構築し運用する人々と直接話すことの価値を知っています。だからこそ、毎年恒例のクラウドセキュリティイベント AWS re:Inforce 2024 にぜひご参加ください。このイベントでは、生成 AI 時代のセキュリティの未来を牽引する専門家、パートナー、ビルダーと協力することができます。 深い技術的専門知識、セキュリティ投資の優先順位付け方法の理解、または基本的なセキュリティのベストプラクティスの適用方法を学びたいかどうかにかかわらず、re:InforceはセキュリティとAIの融合について深く掘り下げる絶好の機会です。AI と機械学習 (ML) は、25 年以上にわたって Amazon が重点的に取り組んできました。生成AI が世界に与えている影響を活用し、それに適応することは刺激的です。 AWS re:Inforce は単なるカンファレンスではありません。クラウドセキュリティの分野におけるイノベーションとコラボレーションを促進する役割を果たします。今年は 6 月 10 日から 12 日まで、ペンシルバニア州 で、お客様のビジネスイニシアチブの推進に役立つように設計された 2.5 日間の没入型クラウドセキュリティ学習を開催します。AWS では、セキュリティはビジネスを促進する要素であると常に信じてきました。セキュリティはリスクを軽減し、回復力を強化し、自信に満ちたイノベーションを促進します。セキュリティは、組織が生成AIなどの新しいテクノロジーを迅速かつ安全に使用し、顧客、パートナー、従業員により良い体験を提供するのに役立ちます。 本イベントに期待できることは以下のとおりです。 現在のAWSのセキュリティ対策と未来 AWS re:Inforce 2024 は、2024年6月11日火曜日の午前9時 (東部標準時) の基調講演から始まります。 re:Inforceの頃には、私は 1 年近くにわたって AWS の CISO を務めていることになります。その間に AWS セキュリティで起こったすべてのイノベーションについて考えると信じられないほどです。これらのイノベーション、そこから学んだこと、そしてそれらを使用して AWS を保護する方法について聞くことができます。また、AWS セキュリティの将来についての私のビジョンについてもお話しします。Amazon の CSO である Steve Schmidt が登壇し、強固なセキュリティ文化が生成 AI の安全な使用をどのように支えているかについての考えを語ります。 生成 AI やその他の新しいトレンドに向けてセキュリティをナビゲート 今こそセキュリティチームがビルダーが生成 AI で自信を持ってイノベーションを起こせるようにする時です。生成 AI に関する AWS セキュリティの最新の進歩をいち早く聞くことができます。インタラクティブなセッションでは、AI ワークロードを安全に実装する方法を学んだり、他のお客様のユースケースを調べたり、AWS やパートナーによる AI 主導型セキュリティのデモを見たりできます。AWS のセキュリティ専門家が、暗号化、ジェネレーティブ AI、セキュリティ文化の構築など、重要なトピックについて掘り下げた講演を行う イノベーショントーク をぜひご覧ください。 今年は、より多くの学習機会を提供するために、イベントを半日延長しました。re:Inforce では、データ保護、IDとアクセス管理、脅威の検出とインシデント対応、ネットワークとインフラストラクチャのセキュリティ、ガバナンス、リスクとコンプライアンス、アプリケーションセキュリティなど、250を超えるさまざまなセッションから選択して、アジェンダをカスタマイズできます。今年は、AWS で安全にイノベーションを進めた直接の経験を共有していただくお客様の登壇者のラインナップが揃っています。90 社以上の信頼できるセキュリティパートナーが、お客様のセキュリティポートフォリオの簡素化と統合を支援します。セキュリティに関する専門知識を深めたいとお考えの方は、re:Inforce セッションの 70% 以上が上級レベルまたは専門家レベルであることがわかります。 AWS のセキュリティにおける最新のイノベーションを活用 100 を超えるインタラクティブ形式のセッションで、当社の最新の発表やプロダクト開始について聞き、これらのセキュリティイノベーションを運用する方法を学びます。 お客様からのフィードバックに応えて、チョークトーク、コードトーク、ワークショップ、ビルダーズセッションなど、よりインタラクティブなセッション形式を追加しました。 既にお持ちのセキュリティツールをさらに活用する方法を学ぶために、AWS の専門家と直接つながるこの機会をお見逃しなく。 AWS の専門家、パートナー同僚とつながる セキュリティコミュニティの他のメンバーと集まる機会は私にとって本当に活力を与えてくれます。 直接会うことで、仲間とつながり、メンターを見つけ、お互いから学ぶ機会がすべて得られます。 参加者マッチングツールを使ってキャリア開発の目標を前進させたり、Expo を探索して信頼できるパートナーとつながったり、セキュリティコミュニティの特定の関心グループ向けに設計されたラウンジやアクティビティに参加したりできます。 サイバーセキュリティとデジタル ID の実践と専門分野における卓越性を育むという共通の使命を持つ AWS Security Heroes 、セキュリティ専門家、IT リーダー、教育者、開発者に会いましょう。 あるいは、知識の共有やセキュリティコミュニティとのつながりに情熱を傾けている AWS Community Builders Program のメンバー、AWS の技術愛好家、新進気鋭のオピニオンリーダーと交流することもできます。 多様な AWS セキュリティコミュニティと新しいつながりを築くのにこれ以上の機会はありません。 SecBlofNakB というコードで今すぐ登録すると、期間限定で 150 米ドルの割引を受けられます。ただし、在庫がなくなり次第終了します。 クラウドセキュリティ業界でのキャリアを始めてから 5 年以内であれば、 All Builders Welcome Grant の対象となる可能性があります（訳者注。登録期限がありますのでご確認ください）。 この助成金は、包摂的、多様かつ公平なサイバーセキュリティコミュニティを構築するという当社の取り組みの一環として、少数精鋭の技術者が AWS re:Inforce  に参加するための経済的障壁を取り除いてくれます。 今後数週間にわたって、 AWS re: Inforce のウェブサイト 、 @awscloud 、 @AWSSecurityInfo で追加の詳細を共有する予定です。 今年の 6 月に AWS re:Inforce  に皆さんをお迎えできることを嬉しく思います。 ぜひ注目してください。 Chris 本Blogは、AWSのCISOであるChris Betzによる 原文 を松本照吾が翻訳しました。 なお、 日本からご参加のお客様のために学習に集中できるための公認ツアーを用意しています。 日本語のAWS re:Inforce ご紹介ページ からツアーのご案内をご確認いただけますので是非ご覧いただければ幸いです。

こんにちわ、ソリューションアーキテクトのザビオ( @zabbiozabbio )です！ 2/20日に 開催しましたWeb3@Startup Loft #6  の開催報告になります。 Web3@Loftとは Web3@Loft は AWS 上でブロックチェーンを始めようとしている、または、開発/運用しているデベロッパー、事業開発者のための、有志によるコミュニティイベントで、定期的に AWS Loft Tokyo で開催しております。 今回は「Web3 Gaming」にフォーカスし、実際に開発/運用されている各企業様にご登壇いただきました。 会場の雰囲気はこちら。今回も多くのお客様に聴講いただきました Amazon Web Services Japan G.K. Sr. Blockchain Specialist SA 中武 Amazon Managed Blockchain Web3 Update 2024 昨年のre:inventで紹介された、 AMB Access Polygon (Public Preview) を中心に、AMB AccessとQueryの概要、またセルフホスティングを柔軟に設定できる AWS Blockchain Node Runners を紹介いたしました。 AMB Access & AMB Queryに関しては こちら をご参照ください。 パネルディスカッション「Web3 Gaming 2024 Initiatives Tech Advancements & Strategic」 株式会社スクウェア・エニックス ブロックチェーン・エンタテインメント事業部 事業部長 畑 圭輔 様 株式会社スクウェア・エニックス ブロックチェーン・エンタテインメント事業部 テクニカルディレクター ディロロ マルタン 様 Polygon Labs Head of Business Development Japan ビール 依子 様 double jump.tokyo株式会社 代表取締役/CTO 満足 亮 様 株式会社ディー・エヌ・エー 島岡 秀知 様 株式会社GALLUSYS CTO 吉田 健一 様 ブロックチェーンゲームに関わりのある企業様をお呼びして、Tech/Bizの観点でパネルディスカッションを行いました。 2024年最新の取り組みから、実装におけるよくある課題、UI/UXはどこを意識してるの、Gameに関わるプレイヤーやステークホルダーとの関わり方、コミュニティ活性化の施策など、 様々なテーマに関して皆様のご意見や知見を共有いただけました。 (スポンサー枠) 株式会社SARAH様 (スポンサー枠) 株式会社HashPalette様 (スポンサー枠) 株式会社クリプトリエ様 (スポンサー枠) CryproGames株式会社 前回からの試みでスポンサーを募集したとこと4社からエントリーいただきました。 各社が独自の色を出し、サービスやプロダクトを紹介。 参加者も各ブースに立ち寄りながら、楽しくお話頂いてるようでした。 まとめ ブロックチェーンゲームに関わりのある企業様の具体的な課題や施策を共有いただきました。 次回も Web3@StartupLoft を開催予定です。日程確定したらアナウンスいたします！ このブログの著者 中武 優樹（Yuki Nakatake） Blockchain/Web3、Database、Zabbix が好きなソリューションアーキテクトです。

お客様がオンプレミス VMware 仮想環境のアプリケーションをリファクタリングせずに移行するために VMware Cloud on AWS を選択されることがますます増えてきました。将来的なクラウドネイティブ化を目指す場合にも、最初のステップとして VMware Cloud on AWS が選ばれるケースも増えてきています。今回は次のステップとして、VMware Cloud on AWS を起点としたデータベースの移行手法についてご紹介します。 AWS Database Migration Service (DMS) を使用して、VMware Cloud on AWS で実行されているデータベースを Amazon Relational Database Service (Amazon RDS) や Amazon Aurora に移行することもできます。ビジネスへの影響やリスクを最小限に抑えると同時に VMware Cloud on AWS 上のアプリケーションを維持しながら、 モダナイゼーション に向けたクラウドジャーニーの次のステップへ進むことができます。 それでは、VMware Cloud on AWS 上で実行されているデータベースを AWS DMS を活用して Amazon Aurora に移行する方法について説明していきます。 AWS Database Migraiton Service (DMS) について AWS DMS はこれまでに最小限のダウンタイムで 100 万以上のデータベースを安全に移行してきており、世界中のお客様からご利用いただいています。 図 1. AWS Database Migraiton Service (DMS) の概要 VMware Cloud on AWS と AWS DMS この投稿では、AWS DMS を使用して、VMware Cloud on AWS で実行されている MySQL を Amazon Aurora に移行する方法を紹介します。Amazon Aurora は、大規模環境でのパフォーマンスと高可用性を提供する最新の リレーショナルデータベース サービスであり、オープンソースの MySQL および PostgreSQL 互換エディションを提供し、サーバーレスならびに機械学習 (Machine Learning) 駆動型アプリケーションを構築するためのさまざまな開発者ツールをサポートしています。 アーキテクチャ概要 次のアーキテクチャの概要図は、AWS DMS が VMware Cloud on AWS 上で実行されている MySQL データベース仮想マシン (DB VM) を Elastic Network Interface (ENI)  を介して Connected VPC にデプロイされた Amazon Aurora に移行する方法を示しています。 図 2. AWS DMS を活用した VMware Cloud on AWS 上のデータベース移行の概要図 VMware Cloud on AWS と Connected VPC 間の通信は ENI を介して内部的に接続されているため、上図の通信はすべて AWS クラウド内にプライベートに保たれていることにもご留意ください。 前提条件 一般的な前提条件 WordPress アプリケーション仮想マシン (App VM) と MySQL データベース仮想マシン (DB VM) は、VMware Cloud on AWS 上で稼働しています。この例では、以下の環境を使用しました。 * VMware Cloud on AWS: SDDC バージョン 1.22 * App VM: Cent OS Linux 7、WordPress 6.2 * DB VM: Cent OS Linux 7、MySQL 8.0 * AWS DMS: Engine version 3.4.7 * Amazon Aurora: version 3 compatible with MySQL 8.0 VMware Cloud on AWS と Connected VPC との間で必要なすべての通信は確立しており、Connected VPC のセキュリティグループおよび VMware Cloud on AWS のファイアウォールルール で許可している。 AWS DMS の AWS Identity and Access Management (IAM) ポリシーで必要なアクションはすべて許可されている。AWS DMS のアクセス要件の詳細については、 AWS Database Migration Service のセキュリティ を参照ください。 Amazon Aurora は MySQL へのバージョン互換性があるエディションである。 Amazon Aurora と MySQL の両方が AWS DMS でサポートされているバージョンである。 データベースの詳細 ターゲットのデータベース Amazon Aurora (MySQL 互換) を Connected VPC 内でデプロイ済みです。 図 3. Connected VPC 内で稼働している Amazon Aurora (MySQL 互換) ソースのデータベース MySQL を WordPress のデータベースとして設定済みです。 図 4. WordPress のデータベースとして設定されている データベース仮想マシン (MySQL) セットアップ手順 この例では、次のセクションにわたって AWS DMS の設定について説明します。 1. Connected VPC にレプリケーションインスタンスを作成 2. ソースとターゲットのエンドポイントの作成 3. データベース移行タスクを作成して実行 4. WordPress の DB アクセスを MySQL から Amazon Aurora に切り替え、アプリケーション側の接続テストを実施 ステップ 1. AWS DMS レプリケーションインスタンスを作成 AWS DMS は、 VPC 内の Amazon EC2 インスタンスとして AWS DMS レプリケーションインスタンスを作成します。このレプリケーションインスタンスを使用し、データベースを移行します。もし高可用性とフェイルオーバーサポートが必要な場合は、マルチ AZ オプションを選択することもできます。 この例では、シングル AZ オプションを選択し、Connected VPC にレプリケーションインスタンスをデプロイしました。 Connected VPC に AWS DMS レプリケーションインスタンスを作成 Connected VPC にレプリケーションインスタンスを作成します。 図 5. AWS DMS レプリケーションインスタンスを作成 パラメータチェック 要件と環境に応じてパラメータを選択できます。 図 6. AWS DMS レプリケーションインスタンスの設定 ステップ 2. ソースとターゲットのエンドポイントの作成 エンドポイントの作成 ソース (移行元: MySQL 側) とターゲット (移行先: Amazon Aurora 側) の両方にエンドポイントを作成します。 エンドポイントは、データストアに関する接続、データストアのタイプ、およびロケーションの情報を提供します。AWS DMS はこの情報を使用してデータストアに接続し、ソースエンドポイントからターゲットエンドポイントにデータを移行します。またエンドポイントに対して追加で接続オプションも設定できます。 図 7. AWS DMS のエンドポイント ソースエンドポイントの作成 まず、ソースエンドポイントを作成します。VMware Cloud on AWS 上で稼働している DB VM (MySQL) のアクセス情報を登録します。 図 8. AWS DMS のソースエンドポイント ターゲットエンドポイントの作成 次に、ターゲットエンドポイントを作成します。Connected VPC 上で稼働する Amazon Aurora へのアクセス情報を登録します。 図 9. AWS DMS のターゲットエンドポイント (オプション) ターゲットエンドポイント接続テスト ターゲットエンドポイントを作成する前に、レプリケーションインスタンスへの接続をテストすることが可能です。 図 10. AWS DMS のターゲットエンドポイントへの接続テスト これで、AWS DMS での移行前のセットアップは完了です。 ステップ 3. データベース移行タスクを作成して実行する AWS DMS タスクはすべての作業が行われる場所です。移行や、ロギング要件、制御テーブルデータ、エラー処理などの特別な処理に使用するテーブル (またはビュー) とデータベースを指定します。 タスクは次の 3 つの主要なフェーズで構成されます。 * 既存データの移行 (フルロード) * キャッシュされた変更の適用 * 継続的なレプリケーション (変更データキャプチャ) AWS DMS 移行タスクがデータを移行する方法の詳細と概要については、 AWS DMS の概要 を参照してください。 既存データの移行 この例では、VMware Cloud on AWS 上の MySQL から Connected VPC 内の Amazon Aurora にデータを移行するために「Migration of existing data」を選択しています。 図 11. タスクの作成 Amazon Aurora に移行するために MySQL データベース「wordpress」を選択しています。 図 12. WordPress のデータベース指定 実行状況は「Status」で確認できます。 図 13. タスクのステータス確認 ステータスが 「Load complete 」となっています。これで、MySQL 内のデータが Amazon Aurora へ移行されたことが確認できました。 次に、WordPress アプリケーション側からもデータ移行が成功していることを確認します。 ステップ 4. WordPress のデータベースアクセスを MySQL から Amazon Aurora に切り替えてテスト データベースを移行したら、WordPress アプリケーションでテストしてみます。 「wp-config.php」設定ファイルを更新して WordPress (App VM) の DB アクセスを切り替えると、WordPress は Amazon Aurora にアクセスします。 図 14. WordPress の参照先データベースの変更 マイグレーション完了の確認 下図の通り、すべての WordPress のコンテンツが正常に移行されたことがわかりました。 図 15. WordPress のコンテンツ確認 その他の考慮事項 本番環境で AWS DMS を使用して同様のデータベース移行を行う場合は、以下のセキュリティガイドラインに従ってください。 * Amazon Aurora のセキュリティ * AWS Database Migration Service のセキュリティ * VMware Cloud on AWS のネットワークとセキュリティについて 各サービス利用コストも考慮する必要があります。この例では、AWS DMS をオンデマンドの Amazon EC2 インスタンスで使用してレプリケーションインスタンスとして実行したため、オンデマンド使用分が課金されます。一方、VMware Cloud on AWS SDDC と Connected VPC 間のデータ転送では、SDDC と送信先の Amazon EC2 インスタンスは同じ AWS アベイラビリティーゾーン (AZ) にあるために通信コストは発生しません。利用コストの詳細については、 AWS Database Migration Service の料金 をご参照ください。 Connected VPC ではなく他の VPC をデータベースの移行先として使用する場合は、ネットワーク接続に AWS Transit Gateway (TGW)  や  VMware Transit Connect (VTGW) を活用できます。 AWS DMS は、一般的なデータストアの多くをソース (移行元) として使用できます。Amazon EC2 インスタンスで実行されるセルフマネージドのデータベースでも、オンプレミスのデータベースでもかまいません。また、Amazon RDS や Amazon S3 などの AWS サービス上のデータストアをソースにすることもできます。対象となるデータストアの包括的なリストについては、 AWS DMS のソース をご参考ください。AWS DMS の詳細な前提条件については、 AWS Database Migration Service の前提条件 をご参照ください。 まとめ 一般的にデータベース移行は容易ではありませんが、AWS DMS を活用することでそのハードルを大幅に下げることができます。この記事をきっかけに、VMware Cloud on AWS を起点としたさらなるモダナイゼーションを検討していただけますと幸いです。 AWS DMS および VMware Cloud on AWS には多くの参考資料があります。以下に概要を示しますので、ぜひチェックしてみてください。 その他のリソース VMware Cloud on AWS のデータウェアハウスとビジネスインテリジェンス VMware Cloud on AWS のアカウントと VPC に関する考慮事項 VMware Cloud on AWS ハイブリッドネットワークデザインパターン AWS SCT と AWS DMS を使用して MySQL から Amazon Aurora に移行する方法 原文は こちら です。

組織には、データの価値を最大限に引き出すための強力な基盤が必要です。この基盤の目的は、データを整理し、品質を確保し、メタデータを管理して、組織のデータを照会できる集約されたカタログを作成することです。組織は、「データ基盤」と呼ばれるこの基盤によって、クリーンで整理され簡単にアクセスできるデータを活用して、より良い意思決定やビジネスインサイトを得ることができます。 データは新しい石油である — クライヴ・ロバート・ハンビー OBE, 数学者 ハンビーは、ビッグデータを「新しい石油」と宣言することで、ビッグデータへの関心を高めました。この比喩は、データドリブン・イノベーション、AI/ML 、および、生成 AI の土台となりました。多くの組織が、構造化データと非構造化データを大規模に、時には取り憑かれたように保存し始めました。「いつかこれが必要になるかもしれない」は、よく繰り返されるマントラでした ( そして今もそうです )。組織は、ファイルシステム、データベース、データウェアハウス、データレイクに保存されるデータを、無差別に収集しました。 データは新しい牛乳である：素早く使用しなければ傷んでしまう — エミリー・ゴルセンスキー, データサイエンティスト 残念ながら、データストアはフリーマーケットによく似たものです。自分が探しているものが分かっていれば、そこに多くの宝物を見つけることができますが、価値のないものに多額のお金を費やすこともあります。目的や特定のユースケースなしに収集されたデータは、それを二流の製品とみなす消費者から、すぐに懐疑的な見方をされます。出所が不明で、品質が不明で、説明が不十分だからです。この問題は多くの場合、本来のデータ作成者ではなく、データの出所、品質、意味に関する十分な知識がない、別のチームがデータを管理していることが原因です。 このような場合、データ基盤は技術的および組織的な観点から見ると、本来あるべきほど強力ではありません。これは問題です。 これにより、余分な作業が増えます。私の経験では ( 少なくとも私が働いたことのある会社では ) 、データサイエンティストの時間の最大 60％ は、ビジネス上の問題を解決する代わりに、データの整理、クリーニング、再フォーマットに費やされています。 加えて、保存されたデータが国のデータ保護規制に準拠している場合としていない場合があります。組織はこれらの規制を知り、その遵守を証明できなければなりません。私は IT 管理者として、データ保護当局から 7 桁の罰金通知を受けたことがあります。その理由は、ある従業員からの、私たちが規制に違反しているという告発からでしたが、ありがたいことに事実ではありませんでした。罰金が科されたのは、我々が特定のデータを、なぜ、またどのくらいの期間に渡って保存するのかを明確に文書化していないことが、データ保護当局によって発見されたためです。幸いなことに、私たちはその主張に反論することができましたが、そもそもこうした対処は不必要で避けられる仕事でした。 特に 生成 AI では、データ品質が重要です。これらの基盤モデルは一般的なデータを生成しますが、競合他社が同じモデルを使用して同じ結果を生み出している可能性が高いため、競争上の優位を生み出すことはできません。独自のデータを使用してモデルをトレーニングまたはカスタマイズする必要がありますが、低品質のデータでこれを行うと、結果が不十分になったり、モデルが内包する既存のバイアスが強まったりする可能性があります。 これらのデータ基盤の問題は、いくつかの理由でマネジメント層によって過小評価され、見過ごされがちです。 まず、ほとんどのマネージャーと従業員にはデータリテラシーが不足しています。 ガートナー社 は、データリテラシーを「文脈に沿って適切にデータを読み、書き、伝える能力。これは、データソースとその構造、および適用された分析手法と技法の理解を含む。また、ユースケース、アプリケーション、そして結果の価値を表現する能力も含む」と定義しています。ガートナー社の CDO ( Chief Data Officer ) サーベイによると、データリテラシーの低さは、CDO の成功を阻む 2 番目に大きい内部障害とされています。 第二に、データストレージとそれを使用するリスクの確度と影響を定期的に評価し監視するプロセスが導入されていることは、ほとんどありません。 第三に、マネジメント層が理解できるデータインベントリの概要は、めったにありません。データインベントリがある場合、非常に詳細な技術情報を使用するデータサイエンティスト向けに作成されたものです。 御社のデータの状態、リスク、および価値はご存知ですか？もしご存知なければ、ボタンを押して評価を提供できるのは誰ですか？ 強固なデータ基盤は以下の4つの側面で構成されます： 戦略 : ビジネス戦略に従い、戦略的取り組みをサポートする明確な データ戦略 を定義します。 技術に寄りすぎることは避けてください。これは方向性を提供することを目的としたものであり、詳細な手順を示すものではありません。効果的なデータ戦略は、データが技術的および組織的にどのように扱われるかを説明する明確かつ簡潔な原則で構成されます。 ドイツの不動産ウェブサイト Scout24 などの一部の組織は、これを データマニフェスト と呼んでいます。 カルチャー : かなりの数 ( 69 % ) の CDO が、データドリブンカルチャーの取り組みに大半の時間を費やしており、55 % がデータドリブンカルチャーの欠如が、ビジネス目標を達成するための最大の課題であると考えています。 私の同僚の Ishit Vachhrajani は、このトピックに関して強くお勧めできる 電子書籍 を執筆しています。 組織 : 分析データに対する、ビジネスドメイン観点での責任を明確に定義します。中央に集約されたデータチームでは、この責任があまり明確に定義されていないことがよくあります。 こうしたチームは、データを生成しません。彼らはトランザクション処理を行うアプリケーションからデータを抽出し、社内の他部門のためにそれを管理するのに最善を尽くします。分析データに対する統制を、中央に集約されたデータチームから、アプリケーションを使ってこのデータを生成している部門に移管することをお勧めします。 このやり方は、組織的データメッシュと呼ばれます。これらのチームは、社内外の顧客のニーズに合わせた特定のユースケースとビジネス上の問題に基づいてデータを保存します。 したがって、データに対する責任は、分散アプローチで組織的にプロデューサー ( 訳註: データ生成元 ) に移管されます。 技術的には、データを一つの データレイク に一元的に保存することも、 データメッシュ に分散して保存することもできます。 AWS は、これらの モダンデータアーキテクチャ の両方を構築するためのサービスを提供しています。能力と制御は密接に関連しているため、スタッフのデータリテラシーに投資する必要があります。 データプロデューサーは多くの場合、トランザクションデータを処理する能力はありますが、分析スキルが不足しています。これに対して AWS は、 データ分析トレーニング をご提供することにより、ご支援が可能です。さらに、適切なアクセス ポリシーを導入します。 デフォルトで誰もがすべてのデータにアクセスする必要があるわけではありませんが、誰もがデータ カタログで利用可能なデータを見つけ、必要に応じて API 経由でアクセスできるべきです。 AWS Lake Formation は安全なデータレイクを簡単に作成し、幅広い分析にデータを利用できるようにします。 Amazon DataZone を使用すると、ガバナンスとアクセス制御を備えた状態で、組織の境界を越えて大規模にデータを発見して共有できます。 テクノロジー ：さまざまな分析ユースケースをサポートする必要がある強固なデータ基盤にとって、全てのケースに画一的に対応するソリューションは、最適な選択ではないかもしれません。特に、それらのユースケースが異なる組織のものである場合は、なおさらです。Best-of-breed ( 訳註：各分野で最良のものを組み合わせる ) のアプローチを適用して、それぞれの状況やユースケースに最適なツールを使用することをおすすめします。これらのツールは、アーキテクチャの観点から見て、全体的な技術戦略とうまく統合され、整合している必要があります。AWS は、データの保存、クエリー、統合、カタログ化、ガバナンス、および処理を行うための、包括的な サービス を提供しています。これらのサービスにより、組織は集中型または分散型のデータアーキテクチャを大規模に構築できます。一般的には、クラウドトランスフォーメーションを加速し、AWS クラウドの可能性を最大限に引き出すことをお勧めします。データ分析システムの開発と運用には、バージョン管理、 CI / CD 、テスト自動化など、モダンで実績のあるソフトウェア開発手法を適用することが重要です。これにより、生産性と品質が向上すると同時に、開発時間が短縮され、変更の追跡可能性が向上します。 生成 AI は、将来を見据えたデータ基盤に貴重な貢献をすることができます。 Amazon Titan モデルのような大規模言語モデル ( LLM ) は、データのプロファイリング、メタデータの抽出とエンリッチメント、データカタログの管理、自然言語を用いた検索の強化に役立ちます。ただし、すべての生成 AI アプリケーションと同様に、AI が出力する結果と提案（例：生成されたメタデータは正しいか？ ) を批判的に確認する必要があります。 データおよびデータ基盤は複雑で分かりにくいように思えるかもしれませんが、明確かつ安全に使用することが可能です。あなたの組織のデータは多くのビジネスチャンスを作り出します。必要なのはそれらを利用することだけです。 データは新しいワインである データを適切に処理、保存、調整すれば、時間の経過とともにさらに向上する、驚くべき結果を得ることができます。注意深く取り扱わないと、すぐに品質が低下し、役に立たなくなります。 データ基盤に関してどのような経験をお持ちですか?　それらについて是非お聞きしたいです。 How to Build Data Capabilities , Ishit Vachhrajani How to Create a Data-Driven Culture , Ishit Vachhrajani Unmasking Your Organization’s Data Problem , Joe Chung Matthias Patzak Matthias は AWS ソリューションアーキテクチャのプリンシパルアドバイザーを務めた後、2023 年初頭にエンタープライズストラテジストチームに加わりました。この役職では、マティアスは経営陣と協力して、クラウドがイノベーションのスピードやITの効率を高め、自社のテクノロジーが生み出すビジネス価値を高めるのにどのように役立つかについて、人、プロセス、テクノロジーの観点から検討しています。AWS に入社する前は、マティアスは AutoScout24 で IT 担当副社長を務め、Home Shopping Europe でマネージングディレクターを務めていました。両社とも、リーン・アジャイルのオペレーションモデルを大規模に導入し、クラウドトランスフォーメーションを成功させた結果、納期の短縮、ビジネス価値の向上、企業価値の向上を実現しました。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルは こちら ）

4月1日は エイプリルフール です。約 10 年前、一部のテクノロジー企業は、読者を喜ばせるために、面白いが、実行不可能だと考えられていたアイデアについて 4 月 1 日に冗談を言っていました。Jeff Barr も過去にこのブログに一見突飛なアイデアを投稿しましたが、驚くことにそのうちのいくつかは実現しました。 例を次に示します。 年 冗談 現実 2010 年 Introducing QC2 – the Quantum Compute Cloud 。特定の種類の数学および論理の問題を驚くべき速度で解決する、本番対応の量子コンピュータ。 2019 年に、科学者、研究者、デベロッパーが 1 か所で、複数の量子ハードウェアプロバイダーから提供されるコンピュータを使用して実験を開始することを可能にするフルマネージドサービスである Amazon Braket をリリースしました。 2011 年 Announcing AWS $NAME 。クラウド、オンプレミス、さらには自宅や部屋上のシステムを見つけて自動的に統合する、スケーラブルなイベントサービス。 2019 年に、独自の AWS アプリケーションとサードパーティーアプリケーションを簡単に統合できるようにするために、 Amazon EventBridge を導入しました。 AWS IoT Events を利用すると、自宅の IoT デバイスからイベントを大規模にモニタリングして対応できます。 2012 年 New Amazon EC2 Fresh Servers 。空間移動的な提供と衛星フリートからの通信を使用して、新しい (物理) EC2 サーバーを 15 分で配信します。 2021 年に、AWS サービスが組み込まれた 1U/2U 物理サーバーである AWS Outposts サーバー をリリースしました。2023 年、 Project Kuiper は、低軌道における光メッシュネットワークのテストを成功裏に完了しました。現在必要なのは、 Amazon PrimeAir のドローン配送 に続く衛星倉庫と大気圏再突入テクノロジーを開発することだけです。 2013 年 PC2 – The New Punched Card Cloud 。新しい mf (メインフレーム) インスタンスファミリー、メインフレームマシンイメージ (MMI)、テープストレージ、1970 年代から 80 年代に使用されたメインフレームコンピュータ用のパンチカードインターフェイス。 2022 年に、メインフレームアプリケーションをモダナイズし、AWS フルマネージドランタイム環境にデプロイするのに役立つよう、 AWS Mainframe Modernization をリリースしました。 Jeff が戻ってきました! 今年は、チップのフレーバーとシリコンのイノベーションの間にユニークな類似点を描き、Jeff が満喫できるように AWS “Chips” Taste Test を用意しました。Jeff は、「Golden Nacho Cheese」、「Al Chili Lime」、「BBQ Training Wheels」を、 AWS Graviton 、 AWS Inferentia 、および AWS Trainium チップと比較しながら味見しました。 皆さんのお気に入りはどれですか? AWS のソーシャルメディアチャネルの LinkedIn や X での投稿 で楽しい動画をぜひご視聴ください。 3月25日週のリリース 私たちが好奇心を持ち、学び続け、高い水準にこだわれば、今後もさらに多くのアイデアが現実になるのを目にすることができるでしょう。同じことが、 生成人工知能 (生成 AI) の世界にも当てはまります。今週は、生成 AI テクノロジーを活用したいくつかのリリースをご紹介します。 Knowledge Bases for Amazon Bedrock – Anthropic の Claude 3 Sonnet 基盤モデル (FM) が、 検索拡張生成 (RAG) 用に内部データソースに接続するために Knowledge Bases for Amazon Bedrock で一般公開されました。 Knowledge Bases for Amazon Bedrock は、 メタデータフィルタリング をサポートしています。これにより、ドキュメントがクエリに確実に関連しているようにできるため、検索の精度が高くなります。クエリに含めるドキュメントまたはクエリから除外するドキュメントを指定することで検索結果を絞り込むことができ、その結果、Claude 3 Sonnet などの FM によってより関連性の高い応答が生成されます。 最後に、Knowledge Bases for Amazon Bedrock で、 プロンプトと検索結果の数をカスタマイズ できます。カスタムプロンプトを使用すると、コンテキスト、ユーザー入力、または出力インジケーターを追加することでプロンプトの指示をカスタマイズできます。これにより、モデルはユースケースのニーズにより良く合致する応答を生成できます。取得するパッセージの数を調整することで、最終的な応答を生成するために必要な情報の量を制御できるようになりました。これらの新機能の詳細については、AWS ドキュメントの「 Knowledge Bases for Amazon Bedrock 」をご覧ください。 Amazon Connect Contact Lens – AWS re:Invent 2023 では、問い合わせの質を高め、エージェントのパフォーマンスを改善するのに役立つよう、顧客との長い会話を簡潔で一貫性のあるコンテキストが豊富なコンタクトの概要に要約するために、 生成 AI 機能のプレビューを発表しました 。これらの 生成 AI を活用した問い合わせ後の概要 は現在、Amazon Connect Contact Lens でご利用いただけます。 Amazon DataZone – AWS re:Invent 2023 では、 包括的なビジネスデータの説明とコンテキストを生成する、生成 AI ベースの機能のプレビューも発表 し、分析のユースケースに関するレコメンデーションについてもご紹介しました。これらの 生成 AI を活用した説明に関するレコメンデーション は現在、Amazon DataZone でご利用いただけます。 他にも見逃せない重要なリリースがあります。 フロリダ州マイアミの新しい Local Zone – AWS Local Zones は、AWS リージョンが存在しない場所による多数の人々、産業、IT センターが、コンピューティング、ストレージ、データベース、他の選択されたサービスを近くで利用できるようにする AWS インフラストラクチャのデプロイです。 フロリダ州マイアミの新しい Local Zone を使用して、リアルタイムゲーム、ハイブリッド移行、ライブ動画ストリーミングなど、1 桁ミリ秒のレイテンシーを必要とするアプリケーションを実行できるようになりました。 Amazon EC2 コンソール設定 の [ゾーン] タブから、マイアミの新しい Local Zone (use1-mia2-az1) を有効にして開始できます。 新しい Amazon EC2 C7gn メタルインスタンス – AWS Graviton ベースの新しい C7gn ベアメタルインスタンス を使用して、詳細なパフォーマンス分析ツール、ベアメタルインフラストラクチャへの直接アクセスを必要とする特殊なワークロード、仮想環境でサポートされていないレガシーワークロード、ライセンスに制限のあるビジネスクリティカルなアプリケーションから恩恵を受けるアプリケーションを実行できます。EC2 C7gn メタルサイズには、64 vCPU と 128 GiB のメモリが搭載されています。 AWS Batch マルチコンテナジョブ – AWS Batch でマルチコンテナジョブ を使用できるため、自動運転車やロボット工学などの分野で大規模なシミュレーションをより簡単かつ迅速に実行できます。ジョブごとに複数のコンテナを実行できるため、AWS Batch が提供する高度なスケーリング、スケジューリング、コスト最適化を利用できるほか、3D 環境、ロボットセンサー、モニタリングサイドカーなどのさまざまなコンポーネントを表すモジュール式コンテナを使用できます。 Amazon Guardduty EC2 Runtime Monitoring – Amazon GuardDuty EC2 Runtime Monitoring の一般提供の開始 をお知らせします。これは、VPC フローログ、DNS クエリログ、AWS CloudTrail 管理イベントを継続的にモニタリングすることによって、実行時の EC2 インスタンスの脅威検出範囲を拡大し、GuardDuty が既に提供している異常検出を補完します。ホスト上の OS レベルのアクティビティと、検出された脅威に対するコンテナレベルのコンテキストを可視化できるようになりました。 AWS CodeBuild 向けの GitLab サポート – CodeBuild プロジェクトのソースプロバイダーとして GitLab および GitLab セルフマネージド を使用できるようになりました。GitLab リポジトリでホストされているソースコードの変更からビルドを開始できます。CodeBuild の新しいソースプロバイダーの使用を開始するには、「 AWS CodeBuild ユーザーガイド 」にアクセスしてください。 AWS コスト割り当てタグの遡及サポート – AWS コスト割り当てタグを 最大 12 か月間遡って有効にすることができます 。以前は、コスト割り当ての目的でリソースタグをアクティブ化した場合、タグは将来に向けてのみ有効になりました。コスト配分タグをバックフィルする期間を指定して、 バックフィルリクエストを送信します 。バックフィルが完了すると、前月のコストと使用量データに現在のコスト割り当てタグが付けられます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 生成 AI に関する他の注目の最新情報とニュース: Amazon と Anthropic による AI への投資 – Anthropic との戦略的なコラボレーションと投資における 最新のマイルストーン をお読みください。現在、Anthropic は AWS を主要クラウドプロバイダーとして利用しており、安全性の研究や将来の FM 開発などのミッションクリティカルなワークロードのために AWS Trainium および Inferentia チップを使用する予定です。3月初め、 Amazon Bedrock で Anthropic の最も強力な FM である Claude 3 へのアクセスを発表しました。 Sonnet は 3 月 4 日に、 Haiku は 3 月 13 日に利用可能になる旨をお知らせしました。詳細については、Claude on Amazon Bedrock の紹介動画をご視聴ください。 Amazon Bedrock 上に構築された仮想構築アシスタント – BrainBox AI は、Amazon Bedrock を利用した ARIA (Artificial Responsive Intelligent Assistant) のリリースを発表しました。ARIA は、建物管理に関連する日常のプロセスにシームレスに統合することで、建物の効率を高めるように設計されています。詳細については、 お客様事例を全文 お読みいただき、ARIA を使用して建物の CO2 排出量を削減する方法に関する動画をご視聴ください。 Amazon SageMaker JumpStart でソーラーモデルが利用可能に – Upstage Solar は、 Amazon SageMaker を利用して 100% 事前トレーニングされた大規模言語モデル (LLM) であり、そのコンパクトなサイズと強力な実績を使用して優れたパフォーマンスを発揮し、特定の目的のためのトレーニングに特化しています。そのため、このモデルはさまざまな言語、領域、タスクで多様な目的のために使用できます。現在、 Solar Mini は Amazon SageMaker JumpStart でご利用いただけます 。詳細については、SageMaker JumpStart でソーラーモデルをデプロイする方法をご覧ください。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週 執筆しています。先週のハイライトは、 Linux Foundation が、Redis インメモリ NoSQL データストアに代わるオープンソースである Valkey コミュニティを立ち上げた というニュースでした。 AWS の今後のイベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティが一堂に会して、つながり、コラボレーションし、AWS について学ぶための無料のオンラインおよび対面イベントにご参加ください。最寄りの都市でぜひご登録ください: パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 シドニー (4 月 10～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15～16 日)、 ソウル (5 月 16～17 日)、 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ドバイ (5 月 29 日)、 ストックホルム (6 月 4 日)、 マドリード (6 月 5 日)。 AWS re:Inforce – AWS re:Inforce で生成 AI 時代のクラウドセキュリティについて詳しく学びましょう。これは、ビジネスイニシアティブの推進に役立つように設計された、没入型クラウドセキュリティ学習であり、6 月 10～12 日にペンシルバニア州で 2 日半の日程で開催されます。re:Inforce で予定されている内容については、 AWS の Chief Information Security Officer (CISO) である Chris Betz の記事 をお読みください。 AWS Community Days – 世界中の AWS のエキスパートユーザーや業界リーダーが主導する技術的なディスカッション、ワークショップ、実践ラボを特徴とするコミュニティが主体となって開催するカンファレンスに参加しましょう: ムンバイ (4 月 6 日)、 ポーランド (4 月 11 日)、 ベイエリア (4 月 12 日)、 ケニア (4 月 20 日)、 トルコ (5 月 18 日)。 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの デベロッパー向けイベント のすべてを閲覧できます。 4月1日週はここまでです。4月8日週に再びアクセスして、新たな Week in Review をぜひお読みください! – Channy この記事は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

Amazon GuardDuty は、機械学習 (ML) ベースのセキュリティモニタリングおよびインテリジェントな脅威検出サービスであり、 さまざまな AWS データソース を分析および処理し、AWS アカウントとワークロードを継続的にモニタリングして悪意のあるアクティビティがないかを確認するとともに、可視性を高め、是正するための詳細なセキュリティに関する検出結果を提供します。 私は、オペレーティングシステム (OS) レベル、ネットワーク、ファイルイベントを分析して、環境内の特定の AWS ワークロードについての潜在的なランタイム脅威を検出する GuardDuty Runtime Monitoring の機能が気に入っています。私は 2023 年 3 月に、 Amazon Elastic Kubernetes Service (Amazon EKS) リソース向けにこの機能の一般提供が開始されることを 初めてご紹介 しました。Seb は 2023 年 11 月に、 Amazon Elastic Container Service (Amazon ECS) と AWS Fargate 向けに脅威検出を提供する Runtime Monitoring 機能の 拡張 と、 Amazon Elastic Compute Cloud (Amazon EC2) ワークロードの プレビュー についての記事を投稿しました。 3月29日は、 Amazon GuardDuty EC2 Runtime Monitoring の一般提供の開始をお知らせします。これは、実行時における EC2 インスタンスの脅威検出の対象範囲を拡大し、VPC フローログ、DNS クエリログ、および AWS CloudTrail 管理イベントを継続的にモニタリングすることで GuardDuty が既に提供している異常検出を補完するものです。ホスト上の OS レベルのアクティビティと、検出された脅威に対するコンテナレベルのコンテキストを可視化できるようになりました。 GuardDuty EC2 Runtime Monitoring を使用すると、EC2 ワークロード内のコンピューティングリソースをターゲットとしている可能性のある潜在的な脅威を特定して対応できます。EC2 ワークロードに対する脅威には、多くの場合、マルウェアのダウンロードや実行につながるリモートコード実行が含まれます。これには、暗号通貨関連のアクティビティに関連付けられた IP アドレス、またはマルウェアのコマンドアンドコントロール関連の IP アドレスに接続している、AWS 環境内のインスタンスまたはセルフマネージドコンテナが含まれる可能性があります。 GuardDuty Runtime Monitoring は、悪意のあるファイルのダウンロードと実行を伴う疑わしいコマンドを各ステップにわたって可視化するため、最初の侵害時や、ビジネスに悪影響を及ぼすイベントになる前に脅威を検出するのに役立ちます。また、 AWS Organizations を利用して、組織全体のアカウントやワークロードについてのランタイム脅威検出の対象範囲を一元的に有効にし、セキュリティの対象範囲を簡素化することもできます。 GuardDuty で EC2 Runtime Monitoring を設定する 数回クリックするだけで、 GuardDuty コンソール で GuardDuty EC2 Runtime Monitoring を有効にすることができます。初めて使用する場合は、Runtime Monitoring を有効にする必要があります。 EC2 Runtime Monitoring 機能を初めて使用するお客様は、 30 日間無料 でこの機能を試して、すべての機能と検出結果にアクセスできます。GuardDuty コンソールには、無料トライアルの残り日数が表示されます。 これで、実行時の動作をモニタリングする個々の EC2 インスタンスのために GuardDuty セキュリティエージェントを設定できるようになりました。GuardDuty セキュリティエージェントを自動または手動でデプロイすることを選択できます。GA では、 [自動エージェント設定] を有効にすることができます。これは、GuardDuty がお客様に代わってセキュリティエージェントを管理できるようにする機能であり、ほとんどのお客様に推奨されるオプションです。 エージェントは、 AWS Systems Manager を利用して EC2 インスタンスにデプロイされ、 Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを使用して、リソースに関連付けられたランタイムイベントを受信します。GuardDuty セキュリティエージェントを手動で管理する場合は、AWS ドキュメントの「 Managing the security agent Amazon EC2 instance manually 」にアクセスしてください。複数アカウント環境では、委任された GuardDuty 管理者アカウントが AWS Organizations を利用してメンバーアカウントを管理します。詳細については、AWS ドキュメントの「 Managing multiple accounts 」にアクセスしてください。 EC2 Runtime Monitoring を有効にすると、対象の EC2 インスタンスのリスト、アカウント ID、カバレッジステータス、および対応するリソースからランタイムイベントをエージェントが受信できるかどうかを [EC2 インスタンスランタイムカバレッジ] タブで確認できます。 カバレッジステータスが [異常] の場合、すなわち、現在実行時の検出結果を受信できない場合でも、EC2 インスタンスのための多層防御は提供されています。GuardDuty は、CloudTrail、VPC フロー、およびそれに関連付けられた DNS ログをモニタリングすることで、EC2 インスタンスに対する脅威を検出し続けます。 GuardDuty EC2 Runtime のセキュリティに関する検出結果を確認する GuardDuty が潜在的な脅威を検出し、セキュリティに関する検出結果を生成すると、正常な情報の詳細を表示できます。 Amazon EC2 リソースに固有のセキュリティに関する検出結果を検索する場合は、左側のペインで [検出結果] を選択します。フィルターバーを使用して、 [リソースタイプ] を [インスタンス] にするなど、特定の条件で検出結果のテーブルをフィルタリングできます。検出結果の重大度と詳細は、EC2 リソースが疑わしいアクティビティのターゲットであるか、またはアクティビティを実行するアクターであるかを示すリソースのロールに基づいて異なります。 3月29日のリリースにより、悪用されたドメイン、バックドア、暗号通貨関連のアクティビティ、不正な通信の検出など、EC2 インスタンスのために 30 を超える実行時のセキュリティに関する検出結果がサポートされます。詳細なリストについては、AWS ドキュメントの「 Runtime Monitoring finding types 」にアクセスしてください。 EC2 のセキュリティに関する検出結果を解決する EC2 のセキュリティに関する各検出結果を選択すると、詳細が表示されます。検出結果に関連付けられたすべての情報を検索し、問題のリソースを調査して、想定どおりに動作しているかどうかを確認できます。 アクティビティが承認されている場合は、 抑制ルール または 信頼されている IP リスト を使用して、そのリソースについての誤検知による通知を防ぐことができます。アクティビティが想定されないものである場合、セキュリティに関するベストプラクティスは、インスタンスが侵害されたと想定し、AWS ドキュメントの「 Remediating a potentially compromised Amazon EC2 instance 」で詳述されているアクションを実行することです。 GuardDuty EC2 Runtime Monitoring は、 AWS Security Hub や Amazon Detective などの他の AWS セキュリティサービスと統合できます。あるいは、 Amazon EventBridge を利用して、Splunk、Jira、ServiceNow などのセキュリティイベント管理またはワークフローシステムとの統合を使用したり、調査のためにワークロードを分離するなどの自動および半自動の応答をトリガーしたりすることもできます。 [Detective で調査] を選択すると、Detective が作成した AWS リソースのビジュアライゼーションを見つけて、セキュリティに関する問題を迅速かつ簡単に調査できます。詳細については、AWS ドキュメントの「 Integration with Amazon Detective 」にアクセスしてください。 知っておくべきこと GuardDuty EC2 Runtime Monitoring サポートは、 Amazon Linux 2 または Amazon Linux 2023 を実行している EC2 インスタンスで利用できるようになりました。エージェントの最大 CPU およびメモリ制限を設定するオプションがあります。詳細および今後の更新については、AWS ドキュメントの「 Prerequisites for Amazon EC2 instance support 」にアクセスしてください。 GuardDuty の 1 日の平均使用コストを見積もるには、左側のペインで [使用状況] を選択します。30 日間の無料トライアル期間中に、トライアル期間後のコストを見積もることができます。トライアル期間の終了後、モニタリングエージェントについて追跡された vCPU 時間ごとに料金が毎月請求されます。詳細については、「 Amazon GuardDuty の料金 」ページにアクセスしてください。 EC2 Runtime Monitoring を有効にすると、GuardDuty のコストを節約することもできます。この機能が有効になっている場合、セキュリティエージェントを実行している EC2 インスタンスから取得された GuardDuty の基本的な保護 VPC フローログについての料金は発生しません。これは、セキュリティエージェントから入手可能な、類似しているが、よりコンテキストを踏まえたネットワークデータによります。さらに、GuardDuty は引き続き VPC フローログを処理し、関連する検出結果を生成するため、エージェントにダウンタイムが発生した場合でも、ネットワークレベルのセキュリティカバレッジを引き続き実現できます。 今すぐご利用いただけます Amazon GuardDuty EC2 Runtime Monitoring は、AWS GovCloud (米国) リージョンと AWS 中国リージョンを除く、GuardDuty が利用可能なすべての AWS リージョンで使用できるようになりました。EC2 Runtime Monitoring を使用できるリージョンの詳細なリストについては、「 Region-specific feature availability 」にアクセスしてください。 GuardDuty コンソール で GuardDuty EC2 Runtime Monitoring をぜひお試しください。詳細については、「 Amazon GuardDuty ユーザーガイド 」にアクセスしてください。また、 AWS re:Post for Amazon GuardDuty 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

Babelfish for Aurora PostgreSQL には、SQL Server ワイヤプロトコルと、Microsoft SQL Server で使用されるクエリ言語である T-SQL のサポートが含まれています。つまり、開発者は Babelfish を使用して、データベースドライバーを切り替えたり、クエリを完全に書き直したりすることなく、 Amazon Aurora PostgreSQL Compatible エディション で既存の SQL Server アプリケーションを実行できます。 SQL Server から Babelfish for Aurora PostgreSQL に移行する場合、次のようなさまざまなデータ移行オプションがあります。 AWS Database Migration Service (AWS DMS) を使用する。詳細については、「 AWS Database Migration Service で Babelfish for Aurora PostgreSQL をターゲットとして指定可能に 」を参照してください。 SQL Server Integration Services (SSIS) を使用する。詳細については、「 SSIS と Babelfish を使用した SQL Server から Aurora PostgreSQL への移行 」を参照してください。 T-SQL insert コマンドの生成 (SQL Server Management Studio によるスクリプトの生成)。 一括コピープログラム (bcp) ユーティリティを使用する。 この投稿では、データ移行に bcp を使用する場合の詳細と制限について説明します。 ソリューション概要 SQL Server の開発者や管理者であれば、 bcp ユーティリティ について聞いたことがあるでしょう。bcp ユーティリティは、SQL Server データベースとの間で大量のデータをインポートまたはエクスポートできるコマンドラインツールです。 bcp を使用すると、ある SQL Server のテーブルから Babelfish for Aurora PostgreSQL にデータをすばやく転送できます。さらに、Insert メカニズムは行ごとではなく行のバッチを使用して最適化されるため、bcp は効率的です。また、ロギング操作を最小限に抑えることもできます。 Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL の使用 」を参照してください。 前提条件 以下の前提条件を満たしていることを確認してください。 SQL Server Management Studio (SSMS) または bcp ユーティリティ をインストールする必要があります。 SQL Server ネイティブクライアント を端末にインストールする必要があります。 bcp の制約 このデータ移行オプションには、次の制限があることに注意してください。 bcp はテーブルスキーマを移行しません。 bcp は SQL Server データベースと Babelfish を連携しますが、いくつかの制限があります。特定のオプション ( -C 、 -T 、 -G 、 -K 、 -R 、 -V 、 -h ) はサポートされていません。 Babelfish v2.1 (Aurora PostgreSQL 14.3) 以降でサポートされています。 フィールド / 行ターミネータがデータに含まれる場合、既知の問題があります。デフォルトのフィールドターミネータは \t (タブ文字) で、デフォルトの行ターミネータは \n (改行文字) です。使用しているフィールドターミネータがデータに含まれていて ( Major, Mary など) 、 , をフィールドターミネータとして使用している場合、このレコードをインポートする際に問題が発生します (無効な文字値のエラーメッセージ)。 たとえば、次の列があるテーブルを想像してみてください。 ID Name Date 1 Major,Mary 1981-01-01 2 John 1980-02-02 bcp をターミネーターフィールド ( -t ) として使用すると、次の出力が得られます。 1 ,Major,Mary,1981-01-01 2 ,John,1980-02-02 Bash 最初の行には、データに含まれていた追加項目があることに注意してください。このレコードのデータインポートは失敗する可能性があります。または、データをエクスポートおよびインポートするときに -t | パラメータやその他のカスタムターミネータ文字を使用することもできます。フィールドターミネータ -t | を使用すると、次のような出力が得られるはずです。 1|Major,Mary|1981-01-01 2|John|1980-02-02 Code 同じことが行ターミネータにも当てはまります。カスタマイズしたフィールド / 行ターミネータの使用方法の詳細については、「 フィールドターミネータと行ターミネータの指定 」を参照してください。 BCP を使用した SQL Server からのデータエクスポート 次の構文を参考にして、bcp を使用して SQL Server データベースからデータをエクスポートできます。 bcp [ schema.table_name ] out [ output_file ] -c -d [ database_name ] -S [ server_name ] -U [ username ] -P [ password ] Bash ソーステーブルの名前、出力ファイルの名前、およびデータベースアクセス認証情報を指定する必要があります。bcp は、テーブルの全てのデータを指定されたファイルにエクスポートします。 テーブルが数百ある場合は、次の T-SQL コマンドを使用して、データをエクスポートする bcp コマンドを生成できます。 USE MyDBName GO DECLARE @Folder VARCHAR ( 100 ) = 'c:\temp\', @dbName VARCHAR(100) = ' MyDBName ', @sqlInstance VARCHAR(50) = ' SQLServer Instance Name ', @user VARCHAR(50) = ' SQL Login ', @pwd VARCHAR(100) = ' MyPWD #123' SELECT CONCAT ( 'bcp ' , SCHEMA_NAME ( schema_id ) , '.' , name , ' out "' , @Folder , name , '.dat' , '" -c -d ' , @dbName , ' -S ' , @sqlInstance , ' -U ' , @user , ' -P ' , @pwd ) FROM sys . tables WHERE is_ms_shipped = 0 GO SQL bcp を使用した Babelfish for Aurora PostgreSQL へのデータインポート 次の構文を参考にして、bcp を使用して Babelfish にデータをインポートできます。 bcp [ schema.table_name ] in [ input_file ] -c -S [ server_name ] -d [ database_name ] -U [ username ] -P [ password ] Bash 保存先テーブルの名前、入力ファイルの名前、およびデータベースアクセス認証情報を指定する必要があります。bcp は、ファイルからすべてのデータを指定されたテーブルにインポートします。 データをインポートする場合、文字データ型 ( -c ) またはネイティブ形式 (データのエクスポート時に使用したバイナリ ( -n ) など) を使用してデータをエクスポートしたときと同じパラメータを使用することが非常に重要であることに注意してください。これはプラットフォーム間のデータ移行であるため、 -c パラメータを使用する必要があります。 テーブルが数百ある場合は、次の T-SQL コマンドを使用して、データをインポートする bcp コマンドを生成できます。 USE MyDBName GO DECLARE @Folder VARCHAR ( 100 ) = 'c:\temp\', @dbName VARCHAR(100) = ' MyDBName ', @sqlInstance VARCHAR(100) = ' Mybbf_instance . cluster - cxxxxxxxxxbpc . us - east - 1. rds . amazonaws . com ', @user VARCHAR(50) = ' postgreslogin ', @pwd VARCHAR(100) = ' MyPWD #123' SELECT CONCAT ( 'bcp ' , SCHEMA_NAME ( schema_id ) , '.' , name , ' in "' , @Folder , name , '.dat' , '" -e "' , @Folder , name , '.err' , '" -c -d ' , @dbName , ' -S ' , @sqlInstance , ' -U ' , @user , ' -P ' , @pwd ) FROM sys . tables WHERE is_ms_shipped = 0 SQL bcp パラメータ bcp には、データの形式や文字エンコーディングを指定する機能など、 多くの便利なパラメータ があります。 次の表は、bcp ユーティリティを使用して Babelfish for Aurora PostgreSQL にデータをインポートするときにサポートされる、一般的に使用されるパラメータをまとめたものです。 Parameter Description Default -b バッチごとの行数を指定します。各バッチは個別のトランザクションとしてインポートされ、記録されます。 All rows -c すべてのデータをテキストとしてフォーマットする操作を実行します。 -d 接続するデータベース名。 -e bcp が転送できなかった行を格納するエラーファイル。 このオプションは、インポートできなかった行とそれに対応するエラーメッセージを含むエラーファイルを生成します。 -m bcp が操作をキャンセルするまでに許容される最大エラー数。 デフォルトでは、bcp は操作がキャンセルされるまでに最大 10 件のエラーを考慮します。最初のエラーで操作をキャンセルするには、 -m 1 パラメータを使用します。 10 -P Babelfish for Aurora PostgreSQL または SQL Server に接続するためのログインパスワードを指定します。 -S Aurora PostgreSQL エンドポイント用の SQL Server または Babelfish を指定します。 -t フィールドターミネータに通知します。詳細については、「 フィールドターミネータと行ターミネータの指定 (SQL Server) 」を参照してください。 \t -U Babelfish for Aurora PostgreSQL または SQL Server に接続するためのログインユーザー。 bcp のエラーハンドリング このセクションでは、bcp を使用してデータをエクスポートおよびインポートするときに直面する可能性のあるいくつかの課題と、その処理方法について説明します。 テキストファイルを作成しているだけなので、通常、bcp エクスポートを実行しても問題はありません。ただし、このデータをインポートする場合、データの品質によっては問題が発生する可能性があります。最も一般的な問題は以下のとおりです。 主キー違反 区切りフィールドの間違い 無効なデータ bcp はデフォルトで、操作をキャンセルする前にエラーの数が 10 個に制限されていることを覚えておくことが重要です。bcp に最初のエラーで操作をキャンセルさせたい場合は、パラメータ -m 1 を渡すことでこの動作を変更できます。 -e パラメータを使用して、詳細なエラーを含むファイルを生成することもできます。 次のスクリーンショットは、データをインポートする際のエラーの例を示しています。 この例は、エラーが発生し、エラーが発生したにもかかわらずインポート処理が続行されたことを示しています。エラーメッセージには無効なデータがあったことが示されていますが、どのレコードがこの問題の原因になっているのか正確にはわかりません。最初のエラーでプロセスを停止させたい場合は、パラメータ m 1 を渡してください。 コマンドを繰り返し、 -e パラメータを追加してエラーファイルを生成してみましょう。bcp コマンドの出力は似ていますが、今度はエラーファイル SalesOrderDetail.err があることに注意してください。 エラーファイルを開くと、エラーの詳細と、問題の原因となっているレコードが表示されます。 最初のエラーは、8 行目に無効な文字が含まれていることを示しています。次の行には、bcp がインポートしようとしているレコードも表示されます。3 番目の列が分割されていることがわかります。これはターミネータフィールドにエラーがある可能性があります。bcp で生成されたファイルを開いて 8 行目を調べると、問題のあるレコードと行が表示されます。 エラーファイルの次のエラーは 41,079 行目にあります。エラーメッセージには、無効な日付形式があると表示されます。エラーファイルにはエラーのあるレコードも表示され、日付 213-06-30 のフィールドに入力ミスがあることがわかります。 3 番目のエラーは 88,898 行目にあります。エラーメッセージに Invalid character と表示され、日付フィールドに 2014-0i-29 という無効な文字が表示されます。 これらは、bcp でエラー処理を行う方法の例です。 -e パラメータを使用すると、エラーとエラーのあるレコードを検索する時間を大幅に節約できます。 ベストプラクティス bcp を使用して SQL Server データベースからデータを移行する場合、次のベストプラクティスを考慮する必要があります。 データ移行後に外部キーを作成することを検討してください。これにより、データの整合性が確保されます。外部キーを削除せずにデータをインポートする場合は、テーブルを正しい順序でロードするようにしてください。そうしないと、外部キー違反があることを知らせるエラーメッセージが表示され、操作が失敗します。 大きなテーブルや大量のデータをインポートする場合は、インデックスを削除し、bcp を使用してデータをロードしてから、インデックスを再作成することを検討してください。テーブルを読み込む前にインデックスを削除すると、データロード処理が速くなり、その後、必要に応じてインデックスを再作成します。 SQL Server を Aurora PostgreSQL に移行するので、文字データ型を使用してデータをエクスポートおよびインポートするには -c パラメータが必要です。 フィールドターミネータと行ターミネータがデータに含まれている場合は注意してください。 大量のレコードをインポートする場合、 -e パラメータを使用してエラーファイルを生成します。 まとめ この投稿では、AWS DMS、SSIS、またはカスタマイズされたスクリプトを使用する従来のアプローチを越えて、データ移行の代替オプションを検討しました。その過程で、bcp ユーティリティがサポートするさまざまなパラメータを示しました。これにより、データ移行プロセスを微調整できるようになりました。また、問題のあるデータや誤ったデータを扱う際に発生する可能性のある問題を調査するのに役立つ、エラーを効果的に処理する手法についても検討しました。 学習の締めくくりとして、bcp ユーティリティを使用して Babelfish へのデータ移行をスムーズかつ成功させるためのベストプラクティスを掘り下げました。 この機能と Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL の使用 」を参照してください。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Marcelo Fernandes は、AWS プロフェッショナルサービスチームのシニアデータベースアーキテクトです。データベースソリューションをオンプレミスのデータセンターから AWS に移行してモダナイズする過程で、お客様を支援してきました。 David Carvalho Queiroz は、データベースエンジニアリングマネージャーとして Amazon Games のライブオペレーションデータベースチームを率いています。Amazon Games 内の複数のタイトルのデータベースアーキテクチャの AWS への移行、データパイプライン開発、キャパシティプランニング、最適化/チューニング、自動化戦略、GDPR コンプライアンスを担当しています。 Eduardo Valentim は AWS プロフェッショナルサービスチームのシニアデータベースコンサルタントで、データベース分野で 17 年以上の経験があります。Eduardo はキャリアを通じて、移行、設計、パフォーマンスの最適化など、データベース関連の課題を抱えるお客様の支援をしてきました。Eduardo は、パフォーマンスとセキュリティに関する最新のベストプラクティスを常に把握することで、クライアントの環境が成功に向けて最適化されていることを確認しています。

SQL Server データベースを Babelfish for Aurora PostgreSQL に移行するには、通常、自動タスクと手動タスクの両方を実行する必要があります。自動化タスクには、 -rewrite フラグの付いた Babelfish Compass ツール を使用した自動コード変換と、 AWS Database Migration Service (AWS DMS) を使用したデータ移行が含まれます。手動タスクには、Babelfish Compass ツールを使用したデータベース互換性チェック、Babelfish でサポートされていない特定のデータベースオブジェクトの移行回避策、および結果の手動検証が含まれます。 この投稿では、SQL Server の MERGE ステートメントを Babelfish 互換の T-SQL コードに自動的に変換する Babelfish Compass ツールの -rewrite フラグ機能に焦点を当てます。この記事で紹介した一例が MERGE ステートメントですが、 -rewrite は他の機能にも使用できます。また、結果を手動で検証するベストプラクティスについても説明します。 Babelfish Compass を使用すると、ソースである SQL Server データベースがターゲットの Babelfish データベースと互換性があるかどうか、および Babelfish で現在サポートされていない機能や移行できない機能を確認できます。 PostgreSQL 15 は MERGE をサポートしていますが、 Babelfish はまだサポートしていません 。また、PostgreSQL の MERGE は SQL Server の MERGE と完全には同じではありません。たとえば、「RETURNING」や「NOT MATCHED BY SOURCE」という句はサポートされていません。 Babelfish Compass の -rewrite フラグの概要 -rewrite フラグを使用すると、Babelfish Compass 評価レポートの「unsupported」セクションに含まれている MERGE ステートメントを変換することができます。 コマンドプロンプトで Babelfish Compass ツールを実行します。 Mac および Linux でコンパスを実行するための手順はこちら。 BabelfishCompass.bat MyFirstReport C: \ work \ merge_example.sql -rewrite -reportoption xref Bash -rewrite フラグは、Babelfish Compass 評価レポートで、Babelfish ターゲットとの互換性を確保するために SQL コードを手動で書き直すよう提案されている場合に役立ちます。 Babelfish-compatible の T-SQL コードに変換する手作業の一部を取り除くことができます。ただし、対応する書き換えられた SQL コードを注意深く確認する必要もあります。 SQL Server の MERGE ステートメントの理解 SQL Server の MERGE は、挿入、更新、削除を 1 つのステートメントとトランザクションにまとめます。MERGE ステートメントは、ソーステーブルから行を選択し、1 回のトランザクションでターゲットテーブルに対して複数の DML 操作を実行します。 SQL Server MERGE のシナリオを示すために、SQL Server データベースと Babelfish に次のテストテーブルを作成します。 Person_Target はターゲットテーブルで Person_Source はソースで、その行はマージ条件に基づいて Person_Target テーブルにマージされます。 CREATE TABLE dbo . Person_Target ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) CREATE TABLE dbo . Person_Source ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) SQL 次の INSERT ステートメントは、 Person_Source テーブルと Person_Target テーブルにサンプルデータを挿入します。 INSERT INTO Person_Source values ( 1 , 'Ana Carolina Silva' ) , ( 3 , 'Carlos Salazar' ) , ( 4 , 'John Doe' ) INSERT INTO Person_Target values ( 1 , 'Ana Carolina ' ) , ( 2 , 'Diego Ramirez' ) , ( 3 , 'Carlos Salazar' ) SQL 次のコードは、 Person_Source テーブルのデータを Person_Target テーブルにマージします。MERGE の後のセミコロンは実際には必須です。 MERGE Person_Target T USING Person_Source S ON T . PersonID = S . PersonID WHEN MATCHED THEN UPDATE SET PersonName = S . PersonName WHEN NOT MATCHED BY TARGET THEN INSERT ( PersonID , PersonName ) VALUES ( S . PersonID , S . PersonName ) WHEN NOT MATCHED BY SOURCE THEN DELETE ; SQL Person_Target テーブルの各行について、SQL Server はマージ条件と呼ばれる検索条件を評価します。条件が一致すると、結果が true になり、SQL Server は Person_Source テーブルの対応するデータでターゲットテーブルの行を更新します。どの行でも条件に一致しない場合、結果は false となり、SQL Server は対応する行をソーステーブルからターゲットテーブルに挿入します。ソーステーブルのどの行でも条件が一致しない場合、その行はターゲットから削除されます。次の図は、このワークフローを示しています。 ターゲットテーブルを検証し、 Person_Target テーブル内のデータが前の図と一致するかどうかを確認できます。 Babelfish での SQL Server MERGE ステートメントの書き換え PostgreSQL の場合、MERGE ステートメントのような構造はありません。ただし、Compass ツールは MERGE を Babelfish の個々の挿入、更新、削除ステートメントとして書き換えることができます。 次のステートメントは、Babelfish に Person_Source テーブルと Person_Target テーブルを作成し、データを挿入します。 CREATE TABLE dbo . Person_Target ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) ; CREATE TABLE dbo . Person_Source ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) ; INSERT INTO Person_Source values ( 1 , 'Ana Carolina Silva' ) , ( 3 , 'Carlos Salazar' ) , ( 4 , 'John Doe' ) ; INSERT INTO Person_Target values ( 1 , 'Ana Carolina ' ) , ( 2 , 'Diego Ramirez' ) , ( 3 , 'Carlos Salazar' ) ; SQL 次のコードは、レポートフォルダー内の rewrite というフォルダー内に自動的に生成されます。 /* original MERGE statement -- MERGE Person_Target T USING Person_Source S ON T.PersonID=S.PersonID WHEN MATCHED THEN UPDATE SET PersonName=S.PersonName WHEN NOT MATCHED BY TARGET THEN INSERT (PersonID,PersonName) VALUES (S.PersonID,S.PersonName) WHEN NOT MATCHED BY SOURCE THEN DELETE; -- end original MERGE statement */ /*REWRITTEN*/ /* --- start rewritten MERGE statement #1 --- */ /* Note: please review/modify the rewritten SQL code below, especially for handling of ROLLBACK */ BEGIN TRANSACTION SAVE TRANSACTION savept_merge_rewritten_1 DECLARE @MERGE_REWRITTEN_ROWCOUNT_1 INT = 0 /* use instead of original @@ROWCOUNT */ DECLARE @MERGE_REWRITTEN_ERROR_1 INT /* temporary variable */ DECLARE @MERGE_REWRITTEN_RCTMP_1 INT /* temporary variable */ /* WHEN MATCHED THEN UPDATE */ UPDATE T SET PersonName = S . PersonName FROM Person_Target T , Person_Source S WHERE T . PersonID = S . PersonID SELECT @MERGE_REWRITTEN_ERROR_1 = @ @ERROR , @MERGE_REWRITTEN_RCTMP_1 = @ @ROWCOUNT IF @MERGE_REWRITTEN_ERROR_1 <> 0 GOTO lbl_rollback_merge_rewritten_1 SET @MERGE_REWRITTEN_ROWCOUNT_1 + = @MERGE_REWRITTEN_RCTMP_1 /* WHEN NOT MATCHED BY SOURCE THEN DELETE */ DELETE T FROM Person_Target T WHERE NOT EXISTS ( SELECT * FROM Person_Source S WHERE T . PersonID = S . PersonID ) SELECT @MERGE_REWRITTEN_ERROR_1 = @ @ERROR , @MERGE_REWRITTEN_RCTMP_1 = @ @ROWCOUNT IF @MERGE_REWRITTEN_ERROR_1 <> 0 GOTO lbl_rollback_merge_rewritten_1 SET @MERGE_REWRITTEN_ROWCOUNT_1 + = @MERGE_REWRITTEN_RCTMP_1 /* WHEN NOT MATCHED BY TARGET THEN INSERT */ INSERT INTO Person_Target ( PersonID , PersonName ) SELECT S . PersonID , S . PersonName FROM Person_Source S WHERE NOT EXISTS ( SELECT * FROM Person_Target T WHERE T . PersonID = S . PersonID ) SELECT @MERGE_REWRITTEN_ERROR_1 = @ @ERROR , @MERGE_REWRITTEN_RCTMP_1 = @ @ROWCOUNT IF @MERGE_REWRITTEN_ERROR_1 <> 0 GOTO lbl_rollback_merge_rewritten_1 SET @MERGE_REWRITTEN_ROWCOUNT_1 + = @MERGE_REWRITTEN_RCTMP_1 GOTO lbl_commit_merge_rewritten_1 /* in case of an error, roll back to savepoint at the start but do no abort the transaction: there may be an outermost transaction active*/ lbl_rollback_merge_rewritten_1: ROLLBACK TRANSACTION savept_merge_rewritten_1 lbl_commit_merge_rewritten_1: COMMIT ; /* --- end rewritten MERGE statement #1 --- */ END GO SQL 違いの1つは、 @@rowcount は SQL Server と異なるということです。これが、書き直されたコードに @MERGE_RWRITTEN_ROWCOUNT_n が含まれている理由です。 コードをプロシージャ用に変換した後で、SQL Server テーブルと Babelfish PostgreSQL の person_target テーブル内のデータが一致していることを確認できます。 考慮事項 MERGE ステートメントが文字列変数で動的に作成される場合、Babelfish Compass ツールを使用して書き換えることはありません。このようなシナリオでは、手動で変換する必要があります。 -rewrite フラグは Babelfish がサポートしていないかぎり MERGE に影響します。いったん機能がサポートされると、 -rewrite はそれ以上書き換えを試みません。 結論 この投稿では、SQL Server で使用される MERGE ステートメントの例を1つ取り上げて、Babelfish Compass ツールの -rewrite フラグを使用してそれらを同等の Babelfish T-SQL コードに変換する方法を説明しました。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Shyam Sunder Rakhecha は、インドのハイデラバードを拠点とする AWS のプロフェッショナルサービスチームのリードコンサルタントで、データベースの移行とモダナイゼーションを専門としています。AWS クラウドの移行と最適化においてお客様を支援しています。彼はデータベースという観点から新しいテクノロジーを探求することと、 RDBMS とビッグデータに興味を持っています。また、チームビルディングのイベントを開催したり、チームで集まったりするのも大好きです。