本記事は 2024/10/01 に投稿された Healthcare Industry Guide to AWS re:Invent 2024 | AWS for Industries  を翻訳した記事です。 2024 年は、ヘルスケアとテクノロジーの岐路に立つイノベーションにとって歴史の残る年となります。 AWS re:Invent 2024 が近づくにつれ、業界のパイオニアと AWS の専門家が、生成 AI、機械学習、高度なデータ戦略によって促進されるテクノロジー、ユースケース、ブレークスルーを紹介する態勢を整えています。 2024 年 12 月 2 日から 6 日にかけてラスベガスで開催される今年のカンファレンスは、何百ものセッションにわたる豊富な知識を提供します。「2024 年：生成 AI の成果の年」をテーマにした Healthcare and Life Sciences (HLS) industry track  では、TriZetto、Froedtert Health、Geisinger などの業界リーダーからの洞察を取り上げます。 Come learn and build with us! 参加は こちらから登録 していただけます。 AWS re: Invent に参加すると、このようなことができます： 生成 AI を実際の医療ユースケースに適用して、ビジネスの様々な側面を変革するスキルを身につける ヘルスケア向け専用の最新のソリューションについて知る AWS の専門家や同業他社とのネットワーキングを行う 今すぐ組織に適用できる、実用的な知識やベストプラクティスを学び持ち帰る 週の締めくくりには、最高のテクノロジーパーティーで成果を祝いましょう！ 参加に興味が湧いてきましたか？参加のためには次のことを行ってください： re: Invent についてより詳しく知るためには、 re:Invent website  を参照してください HLS Industry guide を確認し、関心のあるセッションを特定、アジェンダを計画しましょう   HLS Pavilion at the re:Invent Expo Hall  ( Venetian Hall B ) を訪れて、最新の生成 AI デモを体験してください。また、2人の非常に特別な小児患者によってデザインされた限定版のピンを手に入れましょう！ おすすめセッション：ヘルスケア ここからは、ヘルスケアセッション参加者向けに厳選されたセッションをご覧ください。おすすめライフサイエンスセッションについては、 life sciences industry guide to AWS re:Invent 2024  をご覧ください。 イノベーショントーク イノベーショントークでは、AWS の専門家がデータ、生成 AI、クラウド運用、モダナイゼーションなどの重要なトピックについて意見を交わします。 HLC201-INT | Accelerating healthcare & life sciences innovation with generative AI（生成 AI によるヘルスケアとライフサイエンスのイノベーションの加速） 12/5 (木) 12:00 PM – 1:30 PM（太平洋標準時） WPS202-INT | WWPS pre-keynote address: Igniting innovation for a better tomorrow（WWPS 基調講演前の講演：より良い未来のためのイノベーションの火付け役） 12/3 (火) 1:30 PM – 2:00 PM (太平洋標準時) ブレイクアウトセッション ブレイクアウトセッションでは 60 分の講義形式のセッションを行います。この幅広い魅力は多くの聴衆に配信されます。セッションは録画されるため、見逃した場合は、re: Invent の後にオンデマンドで視聴できます。 HLS208 | Accelerate healthcare innovation: TriZetto’s data-powered approach（ヘルスケアイノベーションを加速：TriZetto のデータ活用型アプローチ） 12/5 (木) 12:30 PM – 1:30 PM (太平洋標準時) HLS214 | Froedtert Health transforms patient engagement with generative AI（Froedtert Health は生成 AI で患者エンゲージメントを変革します） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) HLS207 | Geisinger’s epic journey: Scaling EHR operations on AWS（Geisinger の壮大な道のり：AWS での EHR オペレーションのスケーリング） 12/3 (火) 1:30 PM – 2:30 PM (太平洋標準時) NTA310 | HIPAA-compliant IVD SaaS: Werfen’s global AWS solution journey（HIPAA 準拠の IVD SaaS：Werfen のグローバル AWS ソリューションジャーニー） 12/4 (水) 4:00 PM – 5:00 PM (太平洋標準時) IDE104 | Inclusive wellness: Leveraging Amazon One Medical for LGBTQIA+ care（インクルーシブ・ウェルネス：アマゾン・ワン・メディカルを LGBTQIA+ のケアに活用） 12/4 (水) 10:00 AM – 11:00 AM (太平洋標準時) HYB201 | AWS wherever you need it: From the cloud to the edge（AWS 必要な場所ならどこでも：クラウドからエッジまで） 12/2 (月) 1:00 PM – 2:00 PM (太平洋標準時) MKT104 | Transform healthcare outcomes with AWS Marketplace（AWS マーケットプレイスで医療成果を変革） 12/2 (月) 12:00 PM – 1:00 PM (太平洋標準時) SEC224-S | Data security in the cloud, from Xsolis, an AI leader in healthcare (sponsored by Trend Micro)（ヘルスケアの AI リーダーである Xsolis が提供する、クラウド内のデータセキュリティ） 12/5 (木) 2:00 PM – 3:00 PM (太平洋標準時) ARC212-S | How Cambia supercharged their Amazon EKS based platform (sponsored by Datadog)（Cambia が Amazon EKS ベースのプラットフォームをどのように強化したか） 12/3 (火) 11:30 AM – 12:30 PM (太平洋標準時) ビルダーセッション 60 分間のビルダーセッションでは、AWS の専門家が指導し、AWS での構築に関する実践的な学習を提供します。これには簡単なデモンストレーションと、それに続くガイド付きの実践体験が含まれます。ご自身のラップトップを持参してご参加ください。 HLS203 | Enhancing patient and clinician experiences with AWS HealthScribe（AWS HealthScribe による患者と臨床医のエクスペリエンスの向上） 12/4 (水) 1:30 PM – 2:30 PM (太平洋標準時) STG317 | Use your own proprietary data to build customized generative AI apps（あなた独自のデータを使用し、カスタマイズされた生成 AI アプリケーションを構築） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) ワークショップ ワークショップは、参加者がグループに分かれて作業し、AWS を使用する際の問題の解決策を 2 時間で構築するインタラクティブなハンズオンセッションです。ご自身のラップトップを持参してご参加ください。 HLS202 | Amazon Q Apps for healthcare （ヘルスケア向け Amazon Q アプリ） 12/5 (木) 3:30 PM – 5:30 PM (太平洋標準時) AIM315 | Transforming intelligent document processing with generative AI（生成 AI によるインテリジェントな文書処理の変革 12/2 (月) 8:00 AM – 10:00 AM (太平洋標準時) IOT315 | Transforming healthcare with IoT, Amazon Location, and generative AI（ IoT、アマゾンロケーション、生成 AI によるヘルスケアの変革） 12/4 (水) 3:00 PM – 5:30 PM (太平洋標準時) チョークトーク チョークトークは、AWS の専門家による少人数向けの 60 分間の講義です。実用的なアーキテクチャの課題に関する技術的な議論を促進するための、インタラクティブなホワイトボードセッションがあります。 HLS304 | Accelerate healthcare innovation with real-world data and evidence（現実世界のデータとエビデンスでヘルスケアイノベーションを加速） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) HLS301 | Building an interoperable healthcare data layer with AWS（AWS による相互運用可能な医療データレイヤーの構築） 12/4 (水) 2:30 PM – 3:30 PM (太平洋標準時) HLS302 | Transform clinical apps with gen AI: Netsmart’s AI Data Lab journey（生成 AI による臨床アプリケーションの変革：Netsmart の AI データラボジャーニー） 12/4 (水) 10:00 AM – 11:00 AM (太平洋標準時) HLS305 | Optimize clinical documentation with generative AI: NextGen case study（生成 AI による臨床ドキュメンテーションの最適化：次世代ケーススタディ） 12/4 (水) 2:30 PM – 3:30 PM (太平洋標準時) DEV333 | Automating insurance claims and policy management using generative AI（生成 AI を使用した保険金請求とポリシー管理の自動化） 12/5 (木) 11:30 AM – 12:30 PM (太平洋標準時) CMP326 | Accelerate AI innovation for healthcare and life sciences on AWS（AWS でヘルスケアとライフサイエンスの AI イノベーションを加速） 12/4 (水) 10:30 PM – 11:30 PM (太平洋標準時) HYB310 | Addressing data residency requirements with hybrid and edge services（ハイブリッドサービスとエッジサービスによるデータレジデンシー要件への対応） 12/4 (水) 8:30 AM – 9:30 AM (太平洋標準時) ライトニングトーク ライトニングトークは、エキスポホールで開催される 20 分間のシアタープレゼンテーションです。特定のお客様事例、サービスデモ、AWS パートナーサービスなどに特化してお話しします。 PEX218 | AWS Partner Solutions: AI-based insights transforms radiology workflows（AWS パートナーソリューション：AI ベースの洞察が放射線医学のワークフローを変える） SMB204 | Using generative AI to restore the human connection in medicine（生成 AI を活用して医療における人と人とのつながりを回復させる） PEX207 | The good, teh bad, and the ugly of AI and cybersecurity（AI とサイバーセキュリティの良い点、悪い点、醜い点） PRO208 | Santa Clara County & AWS: Collaborative disease surveillance system（サンタクララ郡と AWS：共同疾病監視システム） SEC103-S | Managing cyber vulnerability in connected healthcare devices (Sponsored by Claroty)（コネクテッドヘルスケア機器におけるサイバー脆弱性の管理） PRO207 | Improving patient care with large-scale data engineering and ML（大規模データエンジニアリングと機械学習による患者ケアの向上） AIM242-S | Agentic AI and the journey to gen AI value realization (sponsored by ZS)（エージェント AI と生成 AI の価値実現への道のり） [注 : イベントカタログにセッションが増え次第、さらにセッションが追加されます] AWS for Industries Pavilion で AWS の専門家と出会い、アイデアを交換しましょう ヘルスケア・ライフサイエンス向けの最新の生成 AI イノベーションを見て、交流しましょう。AWS の業界サービスとソリューションを直接体験してください。あなたと同じクラウドの旅をしている AWS の専門家や仲間とつながりましょう。 AWS for Industries Pavilion 営業時間 (太平洋標準時) : 12/2 (月) 4:00 PM – 7:00 PM 12/3 (火) 10:00 AM – 6:00 PM 12/4 (水) 10:00 AM – 6:00 PM 12/5 (木) 10:00 AM – 4:00 PM パビリオンで予定されている生成 AI デモは以下の通りです： 生成 AI による創薬の変革 生成 AI による臨床試験の変革 生成 AI による患者と臨床医の体験の変革 さらに、 Undiagnosed Diseases Network  および John Hopkins 小児センターと提携して、小児患者さんがデザインした限定版のピンを配布します。未診断の病気と闘っている 11 歳のクーパーと拡張型心筋症の 7 歳のハナがデザインしたピンは、クラウドベースのイノベーションが患者に与え続けている影響を象徴的に思い出させてくれます。ベネチアンのヘルスケア＆ライフサイエンスエキスポパビリオンに立ち寄って、ピンを集めましょう。 それでは、ラスベガスでお会いできるのを楽しみにしています！ ヘルスケアとライフサイエンスの新時代を今すぐ開拓する方法の詳細については、 AWS for Healthcare and Life Sciences  をご覧ください。 おすすめライフサイエンスセッションについては、 life sciences industry guide to AWS re:Invent 2024  をご覧ください。 Oiendrilla Das Oiendrilla Das は、AWS のライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリーダーです。彼女はライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。Oiendrilla はマーケティングの MBA 学位を取得しており、MBA を取得する前にバイオテクノロジーのエンジニアリングを修了しました。 Jennifer Rouse Jennifer Rouse は、AWS のヘルスケアマーケティングのワールドワイドヘッドです。IBM や Cisco などの大企業や、2 つのクラウドベースのスタートアップで指導的役割を果たしてきました。直近では、Forrester Research/Sirius Decisions のグローバルアナリスト兼アドバイザーを務めました。彼女は、公共部門など、これまでサービスが行き届いていなかった業界で変化をもたらす企業でキャリアの多くを過ごしてきました。公共部門での経験から、医療、公共安全、教育、政府機関における人生を変える多くのテクノロジープログラムに取り組んできました。 Ryan Greene Ryan Greene は、AWS のグローバルヘルスケア及びライフサイエンスチームのシニアプロダクトマーケティングマネージャーです。ビルダーとしての考え方と、チームの運営方法を変革したいという情熱を持った彼は、複雑な問題に大規模に取り組むことを好みます。彼は 2 人の幼い子供たちからやる気を引き出し、革新的なアプローチを活用して世界で最も大規模な顧客の課題や作業負荷に対処することへのプロとしての関心を高めています。

2024 年 2 月に 更新された原文を日本語版として 9 月に反映しました： この記事は、コストベースの最適化とクエリ結果の再利用を含む Amazon Athena エンジンバージョン 3 の変更を反映するために確認および更新されました。 Amazon Athena は、オープンソースのフレームワークに基づいた対話型分析サービスで、標準の SQL を使って Amazon Simple Storage Service (Amazon S3) に格納されたオープンテーブルおよびファイル形式のデータを簡単に分析できます。Athena はサーバーレスなので、インフラストラクチャの管理は不要で、実行したクエリに対してのみ料金を支払います。Athena は使いやすく、Amazon S3 内のデータを指定し、スキーマを定義すれば、標準 SQL を使ってクエリを実行できます。 この投稿では、クエリのパフォーマンスを向上させるためのヒントのトップ10を紹介します。Amazon S3 への データ保存 とクエリ特有の チューニング に関連する側面に焦点を当てます。 ストレージ 本セクションでは、Athena で最大限の効果を得るためのデータの構造化方法について紹介します。Amazon S3 にデータを保存する場合、同じ実践方法を Amazon EMR のデータ処理アプリケーション (Spark、Trino、Presto、Hive など) にも適用できます。以下のベストプラクティスについて説明します。 データのパーティション分割 データのバケット化 圧縮の利用 ファイルサイズの最適化 列指向のファイル形式の利用 1. データのパーティション分割 パーティション分割は、テーブルを論理的なパーティションに分割し、日付、国、地域などのカラム値に基づいて関連するデータを同じパーティションに格納します。パーティションは仮想的な列として機能します。パーティションはパーティション値に基づいてデータが論理的に区分されます。テーブル作成時にパーティションを定義し、クエリごとにスキャンするデータ量を減らすことで、パフォーマンスが向上します。パーティションに基づいたフィルタを指定することで、クエリでスキャンするデータ量を制限できます。詳細は、 Partitioning data in Athena をご覧ください。 次の例は、S3 バケットに年ごとにパーティション分割されたデータセットを示しています。 $ aws s3 ls s3://athena-examples/flight/parquet/ PRE year=1987/ PRE year=1988/ PRE year=1989/ PRE year=1990/ PRE year=1991/ PRE year=1992/ PRE year=1993/ このデータセットの場合、テーブルには PARTITIONED BY (year STRING) 句を含め、Athena に年単位でパーティション分割されていることを伝える必要があります。テーブル作成後、たとえば ALTER TABLE ADD PARTITION を使用するか、 AWS Glue クローラーを使用するか、 MSCK REPAIR TABLE を実行して、各パーティションを追加する必要があります( Iceberg テーブルでは テーブルレイアウト情報が追跡されるため、 MSCK REPAIR TABLE の実行は必要なく、サポートもされていません)。また、テーブルはパーティションプロジェクションを使用するように構成することもできます (設定方法については、ボーナスチップのセクションを参照してください)。 パーティション化されたテーブルを問い合わせる際、 WHERE 句でパーティションキーを使用することで、スキャン対象となるパーティションを限定できます: SELECT dest, origin FROM flights WHERE year = '1991' このクエリを実行すると、Athena は年のパーティションキーにプレディケート (フィルター) があることを認識し、一致するパーティションからのみデータを読み込みます。この場合、 s3://athena-examples/flight/parquet/year=1991/ のデータのみが読み込まれます。 データセットには複数のパーティションキーを持つことができます。以下は、 AWS Open Data Registry の NOAA Global Historical Climatology Network データセット からの例です。このデータセットは、STATION と ELEMENT でパーティション分割されており、コマンドを実行すると、特定の STATION(=ASN00023351) の ELEMENT パーティションのリストを取得することができます。 $ aws s3 ls --no-sign-request s3://noaa-ghcn-pds/parquet/by_station/ STATION=ASN00023351 / PRE ELEMENT=DAPR/ PRE ELEMENT=DWPR/ PRE ELEMENT=MDPR/ PRE ELEMENT=PRCP/ このデータセットのテーブルには、 PARTITIONED BY (station STRING, element STRING) 句が含まれ、Athena にこのようにパーティション分割されていることを伝えます。 パーティション分割するカラムを決定する際は、以下の点を考慮してください。 クエリに適したパーティションキーを選択します。クエリから逆算して、データセットをフィルタリングするのによく使われるフィールドを見つけてください。 パーティションキーのカーディナリティ(パーティションキーが取りうるユニークな値の数を指します)は比較的低い方が良いです。テーブル内のパーティション数が増えるほど、パーティションメタデータの取得と処理のオーバーヘッドが高くなり、ファイルサイズが小さくなります。パーティションキーのカーディナリティが高すぎると、パーティション分割のメリットが失われる可能性があります。 データがある特定のパーティション値に偏っていて、ほとんどのクエリがその値を使用する場合、パーティション分割のメリットがオーバーヘッドで打ち消される可能性があります。 時間の経過とともに増大するデータセットは、一般的に日付でパーティションされるべきです。特定の期間、例えば過去 1 週間や過去 1 か月を見るクエリは一般的なパターンです。日付でパーティションすることで、全体のデータセットのサイズが時間とともに増大しても、これらのクエリが読み取るデータ量は一定に保たれます。 次の表は、パーティション分割されたテーブルとパーティション分割されていないテーブルのクエリ実行時間を比較しています。このテーブルは、業界標準のベンチマークデータセット TPC-H から取得されています。テーブルの両バージョンには、74 GB の非圧縮テキストデータが格納されています。パーティション分割されたテーブルは、 l_shipdate 列でパーティション分割され、2,526 のパーティションがあります。 クエリ パーティション分割されていないテーブル コスト パーティション分割されたテーブル コスト 節約分 . 実行時間 スキャンされたデータ . 実行時間 スキャンされたデータ . . SELECT COUNT(*) FROM lineitem WHERE l_shipdate = '1996-09-01' 4.8 秒 74.1 GB $0.36 0.7 秒 29.96 MB $0.0001 99% 安価 85% 高速 SELECT COUNT(*) FROM lineitem WHERE l_shipdate >= '1996-09-01' AND l_shipdate < '1996-10-01' 4.4 秒 74.1 GB $0.36 2.0 秒 898.58 MB $0.004 98% 安価 54% 高速 EXPLAIN コマンドを使用すると、クエリによってどのパーティションが読み取られるかを確認できます: EXPLAIN SELECT COUNT(*) FROM lineitem WHERE l_shipdate = '1996-09-01' 出力で SOURCE 項目を探し、その中の PARTITION_KEY ラベルを確認してください。この行は、クエリによって読み取られるパーティションを示しています。 … Fragment 1 [SOURCE] Output layout: [count_0] Output partitioning: SINGLE [] Aggregate[type = PARTIAL] │ Layout: [count_0:bigint] │ Estimates: {rows: 1 (9B), cpu: 0, memory: 9B, network: 0B} │ count_0 := count(*) └─ TableScan[table = awsdatacatalog:tpc_h:lineitem] Layout: [] Estimates: {rows: ? (0B), cpu: 0, memory: 0B, network: 0B} l_shipdate:string:PARTITION_KEY :: [[1996-09-01]] テーブルに複数のパーティションキーがある場合、それぞれのキー値について行が出力されます。クエリがパーティションキーの複数の値に一致する場合、出力にはそれぞれの値が含まれます。たとえば、クエリを変更して l_shipdate の値の範囲を選択した場合、最後の 2 行は次のようになります。 l_shipdate:string:PARTITION_KEY :: [[1996-09-01], [1996-09-02], [1996-09-03], [1996-09-04], [1996-09-05]] 次の表に示すように、パーティション分割にも、クエリでパーティションフィルターが使用されない場合にパフォーマンス低下が生じます。データを過剰にパーティション分割しないよう注意してください。過剰なパーティション分割は、多数の小さなファイルを生成するため、パフォーマンスが低下します。この点については、この記事の後半で詳しく説明します。 クエリ パーティション分割されていないテーブル パーティション分割されたテーブル 節約 . 実行時間 スキャンされたデータ 実行時間 スキャンされたデータ . SELECT COUNT(*) FROM lineitem 3.4 秒 74.1 GB 8.9 秒 74.1 GB 62% 遅い パーティション分割のもう一つのペナルティは、クエリに一致するパーティションを見つけるのにかかる時間です。この問題を軽減する方法の 1 つは、テーブルにパーティションインデックスを有効にすることです。これにより、テーブルにパーティションが数万個以上ある場合のパフォーマンスが向上する可能性があります。パーティションインデックスを使用すると、すべてのパーティションのメタデータを取得するのではなく、クエリのフィルタ内のパーティション値のメタデータのみがカタログから取得されます。その結果、このようにパーティションが多数あるテーブルに対するクエリが高速化されます。次の表は、パーティションインデックスがない場合とある場合のパーティション分割テーブルのクエリ実行時間を比較しています。このテーブルには約 10 万個のパーティションと非圧縮のテキストデータが含まれています。orders テーブルは o_custkey 列でパーティション分割されています。 クエリ パーティションインデックス = 無効 パーティションインデックス = 有効 高速化 . 実行時間 実行時間 . SELECT COUNT(*) FROM orders WHERE o_custkey BETWEEN 1 AND 100 19.5 秒 1.2 秒 16 倍 Athena での AWS Glue Data Catalog のパーティションインデックスの利点の詳細については、 AWS Glue Data Catalog パーティションインデックスを使用して Amazon Athena クエリのパフォーマンスを向上 を参照してください。 データをパーティション分割する方法の例については、この記事の後半にある最適化されたデータセットの作成に関するセクションを参照してください。 2. データのバケット化 クエリが読み取らなければならないデータ量を減らす別の方法は、各パーティション内のデータをバケット化することです。 バケット化 とは、ある列の値に基づいてレコードを別々のファイルに分散させる手法です。これにより、同じ値を持つすべてのレコードが同じファイルに入ります。バケット化は、高いカーディナリティを持つ列があり、多くのクエリがその列の特定の値を検索する場合に有用です。バケット化の良い候補は、ユーザーやデバイスの ID などの列です。 Athena で既にバケット化されたデータセットがある場合、 CREATE TABLE ステートメントの中で CLUSTERED BY ( <バケット化されたカラム> ) INTO <バケット数> BUCKETS と指定することで、バケット化されたカラムを指定できます。Athena は Hive または Spark でバケット化されたデータセットをサポートしており、Athena の CREATE TABLE AS (CTAS) でバケット化されたデータセットを作成できます。 次の表は、 c_custkey 列を使用して 32 個のバケットを作成した場合の顧客テーブルの違いを示しています。顧客テーブルのサイズは 2.29 GB です。 クエリ 非バケット化テーブル コスト c_custkey をクラスター化カラムとしてバケット化したテーブル コスト 節約分 . 実行時間 スキャンしたデータ . 実行時間 スキャンしたデータ . . SELECT COUNT(*) FROM customer WHERE c_custkey = 12677856 1.3 秒 2.29 GB $0.01145 0.82 秒 72.94 MB $0.0003645 97% 安く 37% 高速 前述のクエリに対して EXPLAIN ANALYZE を実行すると、バケット化が customer テーブルから Amazon S3 からのデータ読み取り量を減らすのに役立ったことがわかります。バケット化されていないテーブルとバケット化されたテーブルのクエリに対する EXPLAIN ANALYZE 出力の抜粋から、入力行数とデータサイズの違いがわかります。 以下はバケット化されていないテーブルの出力です: … ─ ScanFilterProject[table = awsdatacatalog:tpc_h:customer, filterPredicate = ("c_custkey" = 12677856), projectLocality = LOCAL, protectedBarrier = NONE] Layout: [] Estimates: {rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: 0, memory: 0B, network: 0B} CPU: 19.48s (99.94%), Scheduled: 37.43s (99.97%), Blocked: 0.00ns (0.00%), Output: 1 row (0B) Input avg.: 202702.70 rows , Input std.dev.: 4.83% c_custkey := c_custkey:int:REGULAR Input: 15000000 rows (2.29GB), Filtered: 100.00%, Physical input: 2.29GB, Physical input time: 0.00ms 以下はバケット化されたテーブルの出力です: … ─ ScanFilterProject[table = awsdatacatalog:tpc_h:customer buckets=32, filterPredicate = ("c_custkey" = 12677856), projectLocality = LOCAL, protectedBarrier = NONE] Layout: [] Estimates: {rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: 0, memory: 0B, network: 0B} CPU: 654.00ms (100.00%), Scheduled: 1.13s (100.00%), Blocked: 0.00ns (0.00%), Output: 1 row (0B) Input avg.: 156250.00 rows , Input std.dev.: 22.35% c_custkey := c_custkey:int:REGULAR Input: 468750 rows (72.94MB), Filtered: 100.00%, Physical input: 72.94MB, Physical input time: 0.00ns Athena でバケット化されたデータを扱う方法の詳細は、以下のリソースを参照してください。 Athena でのパーティション分割とバケット分割 CTAS クエリの例: バケット分割とパーティション分割されたテーブルの作成 データをバケットに分割する方法の例については、この記事の後半にある最適化されたデータセットの作成に関するセクションを参照してください。 3. 圧縮の利用 データを圧縮すると、クエリの実行速度が大幅に向上します。データサイズが小さくなることで、Amazon S3 からスキャンするデータ量が減るため、クエリの実行コストが下がります。また、Amazon S3 から Athena へのネットワークトラフィックも減少させることができます。 Athena は gzip、Snappy、zstd などの一般的な形式を含む、さまざまな圧縮形式をサポートしています。サポートされている形式の一覧については、 Athena の圧縮サポート を参照してください。 JSON や CSV などの圧縮されたテキストデータを問い合わせるには、特別な考慮が必要です。Athena がデータを読み取る際、データの並列処理を最大化するために、ファイルの異なる範囲をさまざまなノードに割り当てます。各範囲は スプリット と呼ばれ、並列で読み取れるファイルは スプリット可能 と呼ばれます。一般的な圧縮形式のほとんどはスプリット不可能です。つまり、リーダーは圧縮ファイルの先頭から読み取る必要があります。これは、データセットが単一の圧縮された CSV ファイルである場合、クエリ処理に使用できるのは 1 つのノードだけであることを意味します。 テキストファイルを圧縮したデータセットを作成する際は、ファイル数とファイルサイズのバランスを心がけてください。ファイルサイズの最適化については、次のセクションで詳しく説明します。 Parquet ファイルと ORC ファイルは、これらの形式がファイルを構成する複数のセクションを個別に圧縮し、ファイル内の各セクションの場所を含むメタデータを持つため、分割が可能です(ファイル全体が1つのセクションで構成されている場合は分割できないので注意が必要です)。 gzip 形式は高い圧縮率を持ち、他のツールやサービスでも幅広くサポートされています。 zstd (Zstandard) 形式は、パフォーマンスと圧縮率のバランスが良い新しい圧縮形式です。bzip2 と LZO 圧縮形式は分割可能ですが、パフォーマンスと互換性を重視する場合は推奨されません。 データを圧縮する方法の例については、この記事の後半にある最適化されたデータセットの作成に関するセクションを参照してください。 4. ファイルサイズの最適化 データを並列で読み取れ、1回の読み取り要求で可能な限り多くのデータを読み取れるときに、クエリは効率的に実行されます。各ファイルの読み取りにはオーバーヘッドがあり、例えばメタデータの取得、Amazon S3 への要求、圧縮辞書のセットアップなどが発生します。これは通常は気付かれませんが、ファイル数が増えるにつれて、オーバーヘッドが蓄積されます。クエリのパフォーマンスを最大化するには、ファイル数とサイズのバランスを取る必要があります。 一般的なガイドラインとして、128 MB 程度の分割を目指すことをお勧めします。分割とは、ファイルの一部を指します。たとえば、非圧縮テキストファイルのバイト範囲、または Parquet ファイルのページです。圧縮のセクションで説明したように、ほとんどの圧縮テキストファイルは分割できないため、一括して処理されます。Parquet や ORC などの分析用に最適化された形式は、いつでも分割可能です。 小さなファイルが多数生成される理由の 1 つは、前のセクションで説明したパーティション分割の過剰分割です。クエリのパフォーマンスが小さなファイルが多すぎるために低下していることを示す兆候は、クエリ統計の計画フェーズが全実行時間の数パーセントを超えることです。最悪の場合、クエリが「Please reduce your request rate.」という Amazon S3 エラーで失敗する可能性があります。これは、大量のファイルに対し、Athena が Amazon S3 のサービスクォータを超える数の参照リクエストを実行する場合に発生します。 詳細については、 ベストプラクティスデザインパターン: Amazon S3 のパフォーマンス最適化 を参照してください。 小さいファイルの問題を解決する 1 つの方法は、Amazon EMR の S3DistCP ユーティリティを使うことです。これを使って、小さなファイルを大きなオブジェクトにまとめることができます。また、S3DistCP を使えば、HDFS から Amazon S3 へ、Amazon S3 から Amazon S3 へ、Amazon S3 から HDFS へと、大量のデータを最適化された方法で移動できます。このセクションの最後で、Athena Spark を使ってデータを再処理する別の方法について説明します。 ファイル数が少なく、サイズが大きい方が、ディレクトリ内のファイルリスト取得が速くなり、Amazon S3 へのリクエスト数が減り、管理するメタデータも少なくなるというメリットがあります。 例えば、次の表は、100,000 個のファイルを読み取る必要があるクエリと、同じデータセットを単一のファイルとして格納したクエリの違いを比較しています。両方のファイルセットには同じデータが、圧縮されていないテキストファイルとして格納されています。データの総量は 74 GB です。 クエリ ファイル数 実行時間 SELECT COUNT(*) FROM lineitem 100,000 ファイル 11.5 秒 SELECT COUNT(*) FROM lineitem 1 ファイル 4.3 秒 処理速度向上率 . ~ 62% 同様に、次の表は、データが圧縮された場合にファイル数の違いがどのような影響を与えるかを比較しています。データは前の例と同じですが、それぞれ 10 ファイルと 100 ファイルに gzip 圧縮されています。 クエリ ファイル数 平均ファイルサイズ 実行時間 SELECT COUNT(*) FROM lineitem 10 ファイル 2.4 GB 60 秒 SELECT COUNT(*) FROM lineitem 100 ファイル 243 MB 6.8 秒 処理速度向上率 . . 約 88% ファイルサイズ、ファイル数、ファイルが圧縮されているかどうかによって、クエリのパフォーマンスに大きな違いが生じます。データが圧縮されていない場合、Athena は最適なサイズでファイルを並列処理できます。これにより、単一の非圧縮テキストファイルのほうが 10 万個の非圧縮ファイルを処理するよりも効率的です。データが圧縮されている場合、ファイル数とサイズの影響はさらに大きくなりますが、この場合、Athena がデータセットを並列処理できるように十分な数のファイルが必要になります。 データセットを最適化する方法については、この記事の後半にある小さなファイルを結合してデータセットを書き換える例を参照してください。 5. 列指向のファイル形式の利用 Apache Parquet と Apache ORC は、分析ワークロードで人気のあるファイル形式です。これらは、行ごとではなく列ごとにデータを格納することから、 列指向 のファイル形式と呼ばれることが多いです。また、読み込む必要のあるデータ量を様々な方法で削減できる機能も備えています。たとえば、列を個別に格納・圧縮することで、より高い圧縮率を実現でき、クエリで参照される列のみを読み込めます。 列指向のファイル形式では、データに対して複数の圧縮戦略が使用されます。たとえば、多くの繰り返し値を含む列は、値を 1 回格納し、繰り返し回数を付加するランレングス圧縮を使用してエンコードすることも、各値を検索テーブルへのポインタに置き換える辞書符号化を使用してエンコードすることもできます。テキストデータは、gzip、Snappy、zstd などの標準的な圧縮形式で圧縮できます。詳細については、 Athena の圧縮サポート を参照してください。 Parquet と ORC は、さまざまなデータセットに合わせて調整できます。たとえば、ブロック (Parquet) またはストライプ (ORC) サイズを大きくすると、状況によっては有益な場合があります。データセットに多数のカラムがある場合は、Parquet のデフォルト 128MB、ORC のデフォルト 64MB から大きくすることをお勧めします。これにより、各カラムの十分な値が一緒に格納され、読み取りの回数が減ります。 列指向のファイル形式を使ってデータセットを調整する別の方法は、クエリに頻繁に含まれる列でデータを並べ替えておくことです。Parquet と ORC は、各データブロックの列の最小値と最大値などのメタデータを格納しています。つまり、クエリエンジンは、そのブロックに含まれる値がクエリに一致しないと判断した場合、そのブロックのデータを読み込む必要がありません。これは 述語プッシュダウン と呼ばれます。たとえば、データにはタイムスタンプのようなものがあり、この属性でファイル内のデータを並べ替えておくと、特定の時間範囲を探すクエリは、タイムスタンプの前後のブロックのデータを読み込む必要がなくなります。 タイムスタンプによる並べ替えとパーティション分割を組み合わせると、さらにパフォーマンスが向上し、コストを節約できます。たとえば、数時間の時間枠で集計を行うことが多い場合を考えてみましょう。時間単位でパーティション分割することは可能ですが、ファイルが多すぎたり小さすぎたりするリスクがあります。代わりに、日単位でパーティション分割し、データをタイムスタンプで並べ替えることができます。このようにすると、粗粒度のパーティション分割を使用してクエリに含まれるファイルセットを一致するパーティションのみに減らし、並べ替えを使用して残りのファイル内のブロックをスキップできます。パーティションキーとタイムスタンプ列の両方でフィルタリングを行うことを忘れないでください。 次の表は、テキスト gzip、ソート無しの Parquet gzip、および l_partkey でソートされた Parquet gzip の同じデータセットに対する実行時間とスキャンされたデータを比較しています。 クエリ SELECT l_orderkey FROM lineitem WHERE l_partkey = 17766770 テキスト形式と比較した節約分 テキスト gzip データ 実行時間 11.9 秒 . スキャンしたデータ 23.7 GB . コスト $0.1 . ソート無しの Parquet gzip データ 実行時間 2.1 秒 ~ 82% 高速化 スキャンしたデータ 2.0 GB . コスト $0.009 ~ 91% 安価 l_partkey でソート済みの Parquet gzip データ 実行時間 1.1 秒 ~ 90% 高速化 スキャンしたデータ 38.8 MB . コスト $0.0001 ~ 99.9% 安価 最適化データセットの作成 このセクションでは、Athena Spark を使用してデータセットを変換し、前のセクションで説明した最適化を適用する方法を示します。このコードは、 Amazon EMR Serverless や AWS Glue ETL など、ほとんどの他の Spark ランタイムでも使用できます。Athena SQL を使ってデータを変換し、この記事で説明されている多くの最適化を適用することもできますが、Athena Spark の方がプロセスに対する設定オプションとコントロールが多くなります。 次のコードは最初に tpc_h データベースをデフォルトに設定します。このデータベースの場所は、データが書き込まれる場所を決定するために使用されます。次に、以下の操作を実行して customer_optimized という新しいテーブルを作成します: customer テーブルのすべての行を読み込みます coalesce を使用して、バケットごとにパーティションごとに書き込まれるファイル数を 4 に減らします sortWithinPartitions で c_name によってレコードを並べ替えます partitionBy で c_mktsegment と c_nationkey によってパーティション分割し、 bucketBy で c_custkey によって 32 のバケットに分割し、 zstd で圧縮された Parquet ファイルに書き込みます 次のコードを参照してください: spark.sql("use tpc_h") spark\ .read.table("customer")\ .coalesce(4)\ .sortWithinPartitions("c_name")\ .write\ .partitionBy("c_mktsegment", "c_nationkey")\ .bucketBy(32, "c_custkey") .saveAsTable("customer_optimized", format="parquet", compression="gzip") この例では、すべての最適化を同時に示しています。使用ケースによっては、1 つまたはいくつかの最適化だけが必要な場合があります。それぞれの最適化がもっとも役立つ場合については、この記事の前のセクションを参照してください。 Amazon EMR、EMR Serverless、AWS Glue ETL、または Athena SQL を使用してデータを処理する方法の詳細については、以下のリソースを参照してください。 Amazon Athena の CTAS と INSERT INTO ステートメントを使用して、S3 データレイクにデータを抽出、変換、ロードする Amazon Athena の UNLOAD 機能を使用して ETL と ML パイプラインを簡素化する AWS Glue と Amazon S3 を使用してデータレイクの基盤を構築する 大規模データセットを Parquet 形式に変換する 列指向のファイル形式への変換 クエリチューニング Athena SQL エンジンは、オープンソースの分散クエリエンジン Trino と Presto 上に構築されています。その動作を理解することで、クエリを実行する際の最適化の手がかりが得られます。このセクションでは、以下のベストプラクティスについて解説します。 ORDER BY の最適化 結合の最適化 GROUP BY の最適化 近似関数の利用 必要なカラムのみを含める 6. ORDER BY の最適化 ORDER BY 句は、クエリの結果を並べ替えた順序で返します。Athena は分散ソートを使用して、複数のノードでソート操作を並列に実行します。上位または下位 N 件の値を見るために ORDER BY 句を使用する場合は、 LIMIT 句を使用してソートのコストを削減し、クエリの実行時間を短縮できます。 例えば、次の表は、サイズが 7.25 GB の約 6,000 万行のテキスト形式非圧縮テーブルを使用したデータセットに対するクエリ実行時間をまとめたものです。 クエリ 実行時間 SELECT * FROM lineitem ORDER BY l_shipdate 274 秒 SELECT * FROM lineitem ORDER BY l_shipdate LIMIT 10000 4.6 秒 高速化 98% 高速 7. 結合の最適化 適切な結合順序を選ぶことは、クエリのパフォーマンスを向上させるために重要です。2 つのテーブルを結合する際は、大きい方のテーブルを結合の左側に、小さい方のテーブルを右側に指定してください。等値条件を使う一般的な結合の場合、Athena は右側のテーブルから検索テーブルを構築し、ワーカーノードに配布します。次に左側のテーブルをストリーミングし、検索テーブル内の一致する値を探して行を結合します。これは 分散ハッシュ結合 と呼ばれます。右側のテーブルから構築された検索テーブルはメモリ内に保持されるため、そのテーブルが小さいほど、使用するメモリが少なく、結合の実行速度が速くなります。 ハッシュテーブルがワーカーノード間に分散されているため、データスキュー(テーブル内のデータがクラスター内で偏って保持される状態)がパフォーマンスに影響を与える可能性があります。結合条件で使用されるカラムの値に偏りがある場合、1 つのノードが結合の大部分を処理しなければならず、他のノードは遊休状態になってしまいます。最高のパフォーマンスを得るには、結合条件のカラムに値が均一に分布するようにしてください。 次の表は、テキスト形式で圧縮されていない合計 74 GB のデータセットに対する実行時間を示しています。lineitem テーブルには約 6 億行、part テーブルには約 2,000 万行があります。 クエリ 実行時間 SELECT COUNT(*) FROM lineitem, part WHERE l_partkey = p_partkey 6.4 秒 SELECT COUNT(*) FROM part, lineitem WHERE p_partkey = l_partkey 8.1 秒 高速化 約 20% 高速 Athena コンソールの実行詳細ビジュアライザーを使用すると、結合の実行順序を確認できます。ビジュアライザーには、各テーブルから結合された行数も表示されます。ビジュアライザーの使用方法の詳細については、 完了したクエリの統計と実行詳細の表示 を参照してください。 3 つ以上のテーブルを結合する場合は、中間結果を減らすために、最初に大きなテーブルと最も小さなテーブルを結合し、次に他のテーブルと結合することを検討してください。 コストベースの結合最適化 テーブルに AWS Glue Data Catalog でテーブル統計情報がある場合、Athena はこれらを使用して、コストベースの最適化 (ここでの「コスト」は計算コストを指します) によりジョイン順序の変更と集約プッシュダウンを実行します。テーブルに統計情報がある場合、クエリ最適化エンジンはテーブルの順序のどれが最も効率的かを把握でき、自動的に最適化を行えます。つまり、大きなテーブルを手動でジョインの左側に配置する必要がなくなります。 コストベースの最適化機能の使用方法の詳細については、 Amazon Athena でコストベースの最適化機能を使ってクエリを高速化する および コストベースの最適化機能の使用 を参照してください。 パーティションテーブルの結合 パーティションテーブルを問い合わせる際は、すべてのテーブルのすべてのパーティションキーでフィルタを含めることが最適です。これにより、クエリプランナーはファイルのリストと読み取りをできるだけ省略できるようになります。 次の例では、 orders テーブルと lineitem テーブルが注文日 ( orders の o_orderdate 、 lineitem の l_orderdate ) でパーティションされています。最初のクエリでは l_orderdate に条件がないため、エンジンは lineitem テーブルのすべてのパーティションをスキャンする必要があります。注文日を結合条件に追加すると、クエリプランナーは 2 つのテーブルに対して1つのパーティションのみを読み込めば良いことがわかり、スキャンされるデータ量が大幅に減少します。 クエリ スキャンされたデータ 実行時間 SELECT AVG(l_extendedprice) FROM lineitem JOIN orders ON (l_orderkey = o_orderkey) AND o_orderdate = '1993-07-08' 68.1 GB 106 秒 SELECT AVG(l_extendedprice) FROM lineitem JOIN orders ON (l_orderkey = o_orderkey AND l_orderdate = o_orderdate ) AND o_orderdate = '1993-07-08' 35.4 MB 2 秒 前述のように、 EXPLAIN を使用してクエリによってどのパーティションが読み取られるかを確認できます。これは、複数のパーティション化されたテーブルを結合する際に特に重要です。 クエリに関わるテーブルの 1 つ以上のパーティションが、クエリの実行時に発見される情報に依存することがあります。最悪の場合、クエリプランナーがクエリを分析してパーティションを決定できないため、すべてのパーティションを読み取る必要があります。しかし、このような場合でも、Athena は 動的パーティションプルーニング と呼ばれるメカニズムを使用して、クエリの実行中にパーティションの読み取りをスキップできることがよくあります。たとえば、エンジンが結合条件にパーティションキーが関与していることを認識し、右側の値の数が少ない場合、ワーカーノード間でこの情報をブロードキャストできます。その後、ワーカーノードはこの情報を使用して、結合条件で後から除外されるパーティションのファイル読み取りをスキップできます。 次の例では、 orders テーブルと lineitem テーブルが注文日 ( orders の o_orderdate 、 lineitem の l_orderdate ) でパーティション分割されています。 lineitem テーブルは合計で約 75 GB の CSV で、orders は約 16 GB です。このクエリは、パーティションの約 10% に出現する特定の条件セットで注文された品目の平均価格を計算します。これらのパーティションは事前に分からないため、最悪の場合は 90 GB のデータをスキャンする必要がありますが、実際にはわずか 26.5 GB しかスキャンしません。 SELECT AVG(l_extendedprice) FROM lineitem JOIN orders ON (l_orderkey = o_orderkey AND l_orderdate = o_orderdate) WHERE o_clerk = 'Clerk#000094772' AND o_orderpriority = '1-URGENT' AND o_orderstatus = 'F' クエリが実行されると、Athena は条件を満たす行の o_orderdate の値を収集します。これらの値をクラスター全体にブロードキャストし、ノードが lineitem テーブルの一致しないパーティションの読み込みをスキップできるようにします。 EXPLAIN コマンドを使用すると、Athena が動的パーティションプルーニングを実行するかどうかを確認できます。出力で dynamicFilterAssignment を探してください。この例のクエリでは、EXPLAIN プランは次のようになります。 … Fragment 1 [HASH] Output layout: [avg_4] Output partitioning: SINGLE [] Aggregate[type = PARTIAL] │ Layout: [avg_4:row(double, bigint)] │ Estimates: {rows: 1 (55B), cpu: ?, memory: 55B, network: 0B} │ avg_4 := avg("l_extendedprice") └─ InnerJoin[criteria = ("l_orderkey" = "o_orderkey") AND ("l_orderdate" = "o_orderdate"), hash = [$hashvalue, $hashvalue_6], distribution = PARTITIONED] │ Layout: [l_extendedprice:double] │ Estimates: {rows: ? (?), cpu: ?, memory: ?, network: 0B} │ Distribution: PARTITIONED │ dynamicFilterAssignments = {o_orderkey -> #df_562, o_orderdate -> #df_563} ├─ RemoteSource[sourceFragmentIds = [2]] │ Layout: [l_orderkey:integer, l_extendedprice:double, l_orderdate:varchar, $hashvalue:bigint] └─ LocalExchange[partitioning = HASH, hashColumn = [$hashvalue_6], arguments = ["o_orderkey", "o_orderdate"]] │ Layout: [o_orderkey:integer, o_orderdate:varchar, $hashvalue_6:bigint] │ Estimates: {rows: ? (?), cpu: ?, memory: 0B, network: 0B} └─ RemoteSource[sourceFragmentIds = [3]] Layout: [o_orderkey:integer, o_orderdate:varchar, $hashvalue_7:bigint] … 動的パーティションプルーニングの詳細については、Trino ドキュメントの 動的フィルタリング をご覧ください。 クロスジョインに注意 結合条件は結合のパフォーマンスにも大きな影響を与えます。結合条件が複雑な場合、例えば LIKE や > を使用する場合、計算コストがはるかに高くなります。最悪の場合、一方の結合側のすべてのレコードを、もう一方の結合側のすべてのレコードと比較する必要があります。これは クロス結合 と呼ばれます。可能な限り、等値条件を使用してください。 EXPLAIN コマンドを使用すると、Athena がどのようなジョインを実行するかを確認できます。たとえば、 ON t1.name LIKE (t2.prefix || '%') のようなジョイン条件でクエリに対して EXPLAIN を実行すると、次のように出力されます。 Fragment 1 [HASH] … └─ CrossJoin[] クエリプランにクロスジョインが表示される場合は、代わりに等価条件を使用するようにクエリを書き換えることを検討してください。テーブルの 1 つが非常に小さい場合を除き、クロスジョインを含むクエリはクエリタイムアウト制限を超えるリスクが高くなります。 8. GROUP BY の最適化 集約を実行する際は、 GROUP BY 句に含めるカラムを可能な限り少なくして、必要な CPU とメモリの量を減らすべきです。さらに、値の分布が可能な限り均一なカラムでグループ化することを確認してください。 集約クエリのパフォーマンス問題の一因はデータスキューです。これは、多くの行が GROUP BY 句のカラムに同じ値を持っている場合に発生する可能性があります。集約中、行は GROUP BY 句のカラムのハッシュに基づいてワーカーノードに分散されます。データにスキューがある場合、1 つのノードが集約の大部分を処理しなければならず、他のノードはアイドル状態になる可能性があります。 冗長なカラムは、SQL 言語が式を GROUP BY 句に含めるか集約関数を使用することを要求するため、しばしば GROUP BY 句に追加されます。たとえば、 customer_id と customer_name カラムがあるテーブルの場合、1 つの customer_id に対して 1 つの名前しかないにもかかわらず、顧客ごとに集計する場合は GROUP BY c_custkey, c_name と書く必要があります。 GROUP BY 句に多くの冗長なカラムがある場合にクエリを高速化する方法の 1 つが ARBITRARY 関数です。この関数は、名前が示すように、そのグループから任意の値を返す集約関数です。 この例では、顧客ごとの注文数を知りたいと考えています。顧客テーブルと orders テーブルを結合すると、注文ごとに 1 行になるので、 GROUP BY c_custkey を使って顧客ごとに集約します。結果に顧客名を含めたいので、 GROUP BY 句に c_name 列を追加する代わりに、 ARBITRARY(c_name) を使用します。 SELECT c_custkey, ARBITRARY(c_name) AS c_name, COUNT(*) AS order_count FROM customer JOIN orders ON (customer.c_custkey = orders.o_custkey) GROUP BY c_custkey 可能な限り、 GROUP BY 句から不要なカラムを削除する必要があります。前の例のように 1 つのカラムしかない場合、パフォーマンスの向上は目立ちません。しかし、 GROUP BY 句に多数の列がある大規模なデータセットに対するクエリのパフォーマンスにとっては非常に重要です。 9. 近似関数の利用 大規模なデータセットを探索する際の一般的なユースケースは、 COUNT(DISTINCT column) を使用して特定の列の重複のない値の数をカウントすることです。例としては、Web ページにアクセスしたユニークユーザーの数を調べることが挙げられます。 正確な数値が必要ない場合 (例えば、どのウェブページを詳しく調べるかを探している場合)、 approx_distinct(column) の使用を検討してください。この関数は、完全な文字列ではなく、値のユニークなハッシュをカウントすることで、メモリ使用量を最小限に抑えようとします。注意点は、標準誤差が 2.3% あることです。 次の表は、テキスト形式で圧縮されていない約 6 億行の 74 GB のテーブルを使用したときの高速化の概要をまとめたものです。 クエリ 実行時間 SELECT COUNT(DISTINCT l_comment) FROM lineitem 7.7 秒 SELECT approx_distinct(l_comment) FROM lineitem 4.6 秒 高速化 約 40% 高速 詳細については、Trino ドキュメントの 概算集約関数 を参照してください。 10. 必要なカラムのみを含める クエリを実行する際は、 SELECT ステートメントで必要なカラムのみを選択し、すべてのカラムを選択しないようにしてください。カラム数を削減することで、クエリ全体のパイプラインを通して処理する必要があるデータ量が減り、最終的な結果に書き込まれるデータ量も減ります。これは特に、多数の文字列ベースのカラムを持つテーブルを照会したり、複数の結合や集約を実行する場合に特に効果的です。参照データが列指向のファイル形式の場合は、特定のカラムのデータのみが Amazon S3 から読み取られるため、スキャンされるデータ量が減ります。 次の表は、約 6000 万行のテキスト形式の非圧縮 7.25 GB のテーブルを使用したときの高速化の概要をまとめたものです。 クエリ 実行時間 SELECT * FROM lineitem, orders, customer WHERE l_orderkey = o_orderkey AND c_custkey = o_custkey 19.7 秒 SELECT c_name, l_quantity, o_totalprice FROM lineitem, orders, customer WHERE l_orderkey = o_orderkey AND c_custkey = o_custkey 5.2 秒 高速化 73% 高速 ボーナスのヒント このセクションでは、追加のパフォーマンスチューニングのヒントと、この記事の最初のバージョン以降にリリースされた新しいパフォーマンス指向の機能について説明します。 パーティションプロジェクションを使用したパーティション処理の最適化 パーティション数が非常に多く、AWS Glue のパーティションインデックスを使用していない場合、パーティション情報の処理が Athena クエリのボトルネックになる可能性があります。Athena の パーティションプロジェクション を使用すると、パーティション数が非常に多いテーブルのクエリ処理を高速化し、パーティション管理を自動化できます。パーティションプロジェクションは、パーティション情報をメタストアから取得するのではなく、パーティション情報を計算してクエリするため、このオーバーヘッドを最小限に抑えることができます。AWS Glue テーブルにパーティションのメタデータを追加する必要がなくなります(この機能は Athena でのみ利用することができる機能である点にご注意ください)。 パーティションプロジェクションでは、AWS Glue Data Catalog のようなリポジトリから読み取るのではなく、構成から計算されたパーティション値とロケーションが使用されます。メモリ内の操作はリモート操作よりも通常高速であるため、パーティションプロジェクションはパーティション数が非常に多いテーブルに対するクエリの実行時間を短縮できます。クエリと基盤となるデータの特性によっては、パーティションメタデータの取得で遅延が生じるクエリの実行時間を大幅に短縮できる可能性があります。 パーティションプロジェクションを使用するのは、パーティションのスキーマが同じである場合や、テーブルのスキーマがパーティションのスキーマを正確に記述している場合に理想的です。ID のような非常に値の種類が多い列や、非常に細かい粒度の日付範囲でパーティション分割するのに使用できます。 詳細については、 Amazon Athena でのパーティションプロジェクション をご覧ください。 大規模な結果セットを生成するクエリの高速化 (UNLOAD の利用) Athena で SELECT クエリを実行すると、非圧縮 CSV 形式の単一の結果ファイルが Amazon S3 に生成されます。クエリの出力結果が大きくなると予想される場合、単一のファイルへの書き込みに多くの時間がかかります。 UNLOAD を使用すると、結果を Amazon S3 の複数のファイルに分割できるため、書き込み段階で費やされる時間が短縮されます。また、結果セットの形式 (ORC、Parquet、Avro、JSON、TEXTFILE) と圧縮タイプ (Parquet、JSON、TEXTFILE の場合はデフォルトで gzip、ORC の場合は zlib) を指定できます。 次の表は、 SELECT と UNLOAD ステートメントの比較を示しています。このクエリでは、約 13 GB の非圧縮データが出力されることが予想されます。 クエリ SELECT * FROM lineitem LIMIT 85700000 UNLOAD (SELECT * FROM lineitem LIMIT 85700000) to with (format=’TEXTFILE’) 節約 実行時間 362 秒 33.2 秒 ~ 90% 高速化 結果セット 13 GB (CSV、非圧縮) 3.2 GB (CSV、gzip 圧縮) ~ 75% ストレージ削減 データが変更されていない場合のクエリ結果の再利用 データレイクのデータセットは、多くの場合、1 日に 1 回、または 1 日に数回しか更新されませんが、より頻繁にクエリが実行されることもよくあります。ダッシュボードを更新するためのクエリや、アプリケーションのビューにアクセスするたびに実行されるクエリがある可能性があります。前回実行した時から、データが変更されていない場合は、結果を再計算する必要はありません。実際、再計算するとより時間がかかり、コストも高くなります。このような状況では、クエリ結果の再利用を活用できます。これは、同じクエリが例えば過去 15 分以内に実行された場合、Athena がその実行結果を返すように指示する機能です。そのような結果がある場合、Athena はすぐにその結果を返し、データのスキャンは行われません。 クエリ結果の再利用の詳細については、 Amazon Athena のクエリ結果再利用によるコスト削減とクエリパフォーマンス向上 および クエリ結果の再利用 を参照してください。 結論 この投稿では、Athena SQL での対話型分析を最適化するためのトップ 10 のヒントを紹介しました。これらの実践方法は、Amazon EMR 上の Trino を使用する際にも適用できます。 この記事の トルコ語翻訳版 もご覧いただけます。 著者について Mert Hocanin は、AWS Lake Formation の Principal Big Data Architect です。 Pathik Shah は、Amazon Athena の Sr. ビッグデータアーキテクトです。2015 年に AWS に入社し、以来ビッグデータ分析の分野に注力し、AWS の分析サービスを使用してスケーラブルで堅牢なソリューションを構築するお客様をサポートしています。 Theo Tolv はスウェーデン、ストックホルムに拠点を置くシニアアナリティクスアーキテクトです。彼はキャリアの大半を小さなデータと大きなデータで仕事をしてきました。そして 2008 年から AWS 上で動作するアプリケーションを構築しています。余暇時間には、電子工作をいじったり、宇宙オペラを読むのが好きです。 監査履歴 2024 年 2 月に Theo Tolv 氏 (シニアアナリティクスアーキテクト) による最終確認と更新が行われました。翻訳はアナリティクススペシャリストソリューションアーキテクトの川村が担当しました。原文は こちら です。

9 月 30 日週の金曜日、私は Amazon Web Services (AWS) のスピーカーとして、杭州で開催された China Engineer’s Day 2024 (CED 2024) に出席する機会に恵まれました。これは、中国で最も影響力のあるプロの開発者コミュニティの 1 つである中国計算機学会 (CCF) によって主催されるイベントです。 CED 2024 では、AI 開発ツールが開発者の生産性を向上させる方法について話しました。光栄なことに CCF から優秀賞を授与され、 Amazon Q は出席者から大きな注目を集めました。 それでは、9 月 30 日週の AWS に関するその他のエキサイティングなニュースを見てみましょう。 9 月 30 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Q Business が HIPAA の対象に – Amazon Q Business が、 医療保険の相互運用性と説明責任に関する法律 (HIPAA) の認定を受けました。つまり、健康保険会社や医療提供者などのヘルスケアおよびライフサイエンス組織は、Amazon Q Business を使用して、米国の HIPAA 法で規制されている機密性の高いワークロードを実行できるようになりました。 NICE DCV が Amazon DCV に名称変更 – NICE DCV は、 Amazon DCV にリブランディングされました。この高性能リモートディスプレイプロトコルでは、ネットワーク状態が変化しても、任意のクラウドまたはデータセンターから任意のデバイスに、リモートデスクトップとアプリケーションストリーミングを安全に配信できます。Amazon DCV は、サーバー側で Windows ディストリビューションと主要な Linux ディストリビューションの両方をサポートしています。クライアントは、Windows、Linux、macOS 用のネイティブ DCV クライアントとウェブブラウザを使用して、デスクトップやアプリケーションストリーミングを受信できます。DCV サーバーとクライアントは暗号化されたピクセルのみを転送し、データは転送しないため、機密情報がダウンロードされることはありません。Amazon DCV on AWS を Amazon Elastic Compute Cloud (Amazon EC2) と併用すると、 33 の地理的リージョンと 31 のローカルゾーンにわたる AWS 108 のアベイラビリティーゾーン を利用できます。2024.0 リリースでは、最新の Ubuntu 24.04 LTS がサポートされるようになりました。詳細については、 Sébastien Stormacq による 新しいローンチブログ記事 をご覧ください。 AWS re:Post が re:Post Agent をリリース – AWS re:Post は、キュレーションされた知識や活気あるコミュニティへのアクセスを提供し、ユーザーが AWS でさらに成功できるよう支援します。re:Post Agent は、re:Post コミュニティの質問に迅速かつインテリジェントに回答できるよう設計された、 生成 AI アシスタントです。これにより、利用可能な AWS ナレッジベースが拡張されます。また、コミュニティのエキスパートは AI が生成した回答を確認することで、レピュテーションポイントを獲得できます。 Amazon Timestream for InfluxDB を使用した高度な設定 – 今回のリリースでは、ユーザーが AWS マネジメントコンソール からインスタンスの CPU、メモリ、ディスク使用率メトリクスを直接モニタリングできる機能が導入されました。 Amazon Bedrock のナレッジベースの新しいインジェスト停止 API – この新しい API により、ユーザーは進行中のインジェストジョブを自由に停止できるようになります。データインジェストのワークフローをより細かく制御できるため、ユーザーは完了を待つことなく、偶発的なインジェストプロセスや望ましくないインジェストプロセスをすばやく停止できます。新しい StopIngestionJob API を使用することで、進化するニーズに迅速に対応できるようになり、コスト削減につながる可能性があります。この機能は、 Amazon Bedrock のナレッジベース が提供されている、すべての AWS リージョン で利用できます。 Amazon AppStream 2.0 のストレージ制限の引き上げ – Amazon AppStream 2.0 では、アプリケーション設定パーシステンスのデフォルトサイズ制限が 1 GB から 5 GB に拡大されました。この引き上げにより、エンドユーザーは手動の介入なしで、またパフォーマンスやセッションセットアップ時間に影響を与えることなく、より多くのアプリケーションデータと設定を保存できるようになります。 先週は 40 以上ものローンチとリリースがありました。重要なものを選ぶのが難しかったほどです。すでに言及した内容に加えて、重要になる可能性のある機能アップデートのリストを次に示します。 Amazon Aurora Serverless v2 が最大 256 個の ACU のサポートを開始 Amazon Aurora MySQL が RDS データ API のサポートを開始 Amazon Aurora が PostgreSQL 16.4、15.8、14.13、13.16、12.20 をサポート Amazon Redshift が RA3.large インスタンスの提供を開始 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース その他にも、先週の注目アイテムをご紹介します。 Amazon WorkSpaces シンクライアント – Amazon WorkSpaces シンクライアントのインベントリは、 米国 、 フランス 、 ドイツ 、 イタリア 、 スペイン に加えて、 英国 の Amazon Business で購入できるようになりました。スマートかつ費用対効果の高いデバイスで、AWS エンドユーザーコンピューティングサービスへの安全なアクセスをすぐにご利用いただけます。この優れたガジェットは、デジタル要塞のようなものです。不正なデータストレージやアプリケーションを防止すると同時に、多数のシンクライアントを簡単に管理およびモニタリングするためのツールを IT 管理者に提供します。 ハリケーン「ヘレン」の影響を受けたコミュニティの支援 – AWS 災害対策 チームは、地域のパートナーや人道支援団体と緊密に連携して、米国南東部で支援を必要としている人々に重要な物資を届けています。また、AWS テクノロジーを導入して、再接続の支援、現場での救援活動の支援、地域での食糧配給ニーズのサポートを行なっています。 Amazon Pharmacy での処方箋の流れ – Amazon Pharmacy の AI ユースケースを読んで、薬の調剤プロセスの複雑さを解消し、患者体験を改善しましょう。このシステムでは、未加工の処方データを標準化された形式に転記し、医療略語を同等のフルテキストに変換し、医薬品の詳細を業界データベースと照合して検証します。この自動化プロセスとそれに続く薬剤師のレビューにより、潜在的な投薬ミスが 50% 減少し、処理速度が最大 90% 向上したため、薬剤師は重要なタスクとパーソナライズされたケアに集中できるようになりました。 WIRED 誌の生成 AI に関するソートリーダーシップの記事 – Antje による「Wired」のニュースコラムをご確認ください。AWS があらゆる規模や経験レベルの組織に AI の変革力を提供している方法について説明しています。すべての AI 愛好家やビジネスイノベーターにお勧めします。AWS は、生成 AI の魔法をあらゆる規模の企業にもたらすことを使命としており、テックに長けた企業にも新規参入企業にも、さまざまな AI ツールを提供しています。大きな夢を抱くスタートアップにも、業界をリードし続けることを目指す大企業にも、AWS は AI 革命のレッドカーペットを広げてお待ちしています。ワイルドなテックファンタジーを現実に変える、このチャンスをお見逃しなく! 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent 2024 – 12 月 2〜6 日にラスベガスで開催される、毎年恒例のテックイベントへの登録が開始されました。私も、新しいリリースについて知るのが待ちきれません。また、セキュリティトピックに焦点を当てた 2 つのチョークトーク (Dev311 – 生成 AI を使用したコードセキュリティの強化と、SEC228 – AWS 中国リージョンにおけるマルチレベル保護スキームのコンプライアンスへの対応) に参加できることを楽しみにしています。 AWS Innovate 移行、モダナイズ、構築 – クラウドを初めて使用する方も、経験豊富なユーザーも、AWS Innovate で何か新しいことを学習できます。これは無料のオンライン会議です。 北米 (10 月 15 日) またはヨーロッパ、中東、アフリカ (10 月 24 日) のうち、都合の良い時間と地域でご登録ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。10 月 12 日に ソフィアで 、10 月 19 日に ヴァドーダラー 、 スペイン 、 グアテマラ で開催される AWS Community Day をお見逃しなく。 今後開催される AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 10 月 7 日週はここまでです。10 月 14 日週の Weekly Roundup もお楽しみに! – Betty この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本稿は、2024 年 8 月 24 日に公開された “ Propelling Innovation: The People, Culture, and Process Imperatives “を翻訳したものです。 新たな需要に対し中小企業が対応するのは、小さな船で嵐の中をかき抜けるようなものです。テクノロジーの進歩が続く中、顧客の期待はさらに高まっています。このような波の中を乗り越えるためには、レジリエンスや適応性、積極的な問題解決力、そして慎重なリスク管理が必要不可欠となっています。 最近のデータ によると、テクノロジーの進歩とともに、顧客の 73% が更なる差別化を期待し、また顧客ニーズの変化に対応することを 65% の顧客が求めています。これは、商品や顧客体験の絶え間ない改善を望んでいることを示しており、競争の激しい事業環境においては、イノベーションを受け入れることが成功への鍵となっています。 しかし、数々の問題に直面する中で、テクノロジーファーストの考えに惑わされることなく、立ち位置をしっかりと保つことが重要です。イノベーションは真空の中で生まれるものではありません。多様な考えを奨励する活気に満ちたエコシステム、新しいアプローチを評価する企業文化、アイデアを具体的な成果につなげるプロセス、それらによってイノベーションは初めて生まれるのです。この3つの領域にフォーカスすることで、企業は新しい製品やサービスを素早くスケールさせ、顧客価値を最大化するための態勢を整えることができるのです。 イノベーションの原動力となる人材 デジタルツールはイノベーションを推進する上で重要な役割を果たしますが、それらを活かすことができる人材がいなければ空の器となります。適切な人材がいれば、顧客のニーズに沿ってビジネスを前に進めるだけでなく、未知の領域を積極的に探求し、イノベーションの旅に情熱的に取り組むことができます。Amazon の CEO、Andy Jassy はイノベーションについて次のように述べています。 「一般常識を疑い、常識の枠組みを超えて考えられる人こそがイノベーションを生み出すのです」。 しかし、実際のところ多くの人にとって、イノベーションは自分の快適な範囲を超えるものだと感じられています。議論の中心は楽しさや創造性に置かれがちですが、現実はそうではないのです。優秀な人だったとしても、顧客体験の向上やソリューションの効率化において、さまざまな課題に直面して前に進めなくなることがよくあります。これは、イノベーションとは大きな変革を意味すると誤解していることが原因です。実際には、小さな継続的な改善の方が、より大きな変革をもたらすことも多いのです。 社員にリスクをとることを奨励すれば、他の人が見落としていた新しい可能性やソリューションに気づくことができるようになります。変化への不安に立ち向かい、自己認識を高めることで、イノベーションに活かせる心の知能指数 (EQ：Emotional Intelligence Quotient) を培うことができます。研究では、リーダーの EQ が、既存の能力やIQ(Intelligence Quotient) よりも将来の成功を予測するのに優れた指標であることが示されていることから、これは非常に重要なことです。強い対人スキルは、部門を超えた関係構築、ステークホルダーへの影響力、新しいコンセプトに向けた関係者の巻き込みを可能にします。 好奇心を含んだ企業文化の醸成 テクノロジーの変革は、企業文化の変革と表裏一体です。なぜなら、イノベーションは個人の取り組みだけでは生まれないからです。組織全体が絶えず学習し続け、新発想に向けて活動していれば、ポジティブな変化を生み出す大きな原動力となります。全社を挙げて実験的な取り組みを推進できるのは、高いコストが払える大企業だけというわけではありません。むしろ、企業には、お金ではなく、成長のマインドセットを醸成することが求められるのです。 経営者が社員との間に心理的安全性を持つことができれば、社員一人一人が通常業務を超えて、会社の成功をリードする立場にもなれます。心理的安全性があることが、高いパフォーマンスを発揮し、イノベーションを起こすのに最も重要な要因だと 研究 からも裏付けられています。組織の進化と学びは、チームが互いに啓発し、弱点を見つめ直し、懸念を表明し、ためらわずに間違いを認められるような、そうした活気ある職場環境を醸成することから生まれるのです。 ただし、イノベーションのために重要なのは、企業内の課題ではなく、顧客ニーズに目を向けることです。 Amazon の Day1 カルチャーとオペレーションモデル をご覧ください。Amazonの 取り組みは、好奇心を評価し、顧客にこだわり、大胆に実験を重ねることで、顧客のニーズに応えようとしていることがことが分かります。一方で、Day 2 のカルチャーは、企業の成長に伴い広がり、意思決定が遅くなることで、ビジネスのアジリティに影響を与えることになります。 急成長を遂げている決済プラットフォームの「 Equals Money 」は、組織の各層に渡って成長のマインドセットを醸成することで、グローバルな成長目標を実現しています。共感性に富んだ経営層と、そして絶えず変化し続けようとする企業姿勢が、慢心を防ぎ、イノベーションを呼び起こしています。初期メンバー 6 人から 450 人以上にまで成長したにもかかわらず、同社は多様性のある視点を保ち続けています。さらに AWS とのイノベーションや変革に関する取り組みを通じ、Equals Money は常に顧客に目を向け続けています。 好奇心旺盛な姿勢は、外部の動向にも積極的に目を向けることにつながります。ただし、最新の技術動向に振り回されないことも重要です。顧客ニーズを起点として、そのニーズを解決するためにどのような技術が活用できるかを見極めていくことが、成功へと導く道筋となります。 アイデアから影響力へ 人材と企業文化がイノベーションの基礎を築く一方で、構造化されたメカニズムによって、アイデアは実際のソリューションへと変化します。例えば、Amazon におけるCutomer Obsession（顧客へのこだわり）という行動指針は、社員に顧客の代理として創造することを促します。顧客ニーズから逆算し、潜在的な欲求を理解することが重要となります – それは顧客自身が明確にニーズを表現できない場合でも同様です。 効果的なフレームワークを利用することで、早すぎる要件の議論によってビジネスが振り回されるのを防ぎ、顧客にとって価値のある整合した1つのビジョンに集中することができます。例えば、Amazon の PRFAQ (Press Release and FAQ) プロセスは、ビジョンを具体的な成果物へと固めていきます。まず、企業内で新製品によって得られる顧客体験を描いた未来のプレスリリースを作成することから始め、その後、仮定やリスク、未解決の課題を体系的に捉え、関係者間で調整するために広くPRFAQ を活用します。 これらの実践は、Amazon のようなグローバル大企業だけのものではありません。プロセスも必ずしも複雑なもの、または手間がかかるものでもないのです。Amazon のドキュメントには、通常 30 近くの PRFAQ が含まれますが、中小企業の場合は、自社向けの一貫性のある外部向けの 3 つの質問と内部向けの 3 つの質問を設定し、それらを繰り返し使え、広く展開可能なテンプレートに単に記入するだけで十分です。そして、実際の顧客との対話を通じてこれらの仮説を検証することができます。これにより、早い段階で先入観に気づき、市場に合致しないソリューションを盲目的に作らずにすむようになります。 イノベーションという到達目標 顧客の期待が高まり、技術進化が加速する中、絶えずイノベーションに取り組むことが事業を継続する重要な鍵となります。結局のところ、活発なイノベーションを実践として確立することは、多方面でのチャレンジとなります。これは変化に柔軟に対応できる感情知性と回復力を備えた人材を育てることについて言及しています。イノベーションは、実験志向やアジリティ、顧客にこだわるという文化を意図的に形作ることを必要としています。そしてイノベーションは、生のアイデアを具体的なソリューションへと変換するという、実証されたプロセスを必要としています。 これまで述べてきた全体的なアプローチこそが、人を中心としたイノベーションを推進することができますが、その実践方法はたくさんあります。人材、企業文化、プロセスを企業戦略の中心にすることについて、これまで以上に詳しく学びたい場合は、 AWS Connected Community のオンデマンドインサイトを探索してください。もしくはあなたが、 クラウド初心者 であれば、 AWS Cloud エキスパート にガイダンスを求め、自社のイノベーション創出をどのように支援できるかを確認してください。 Claire Gribbin Claire Gribbin は、AWS の SMB 部門のグローバルヘッドであり、SMB セグメントの次なる成長フェーズを牽引しています。10 年間世界各国でフィールド営業のリーダーを務めた後、Microsoft Azure にて顧客やパートナーのデジタルトランスフォーメーションを大規模に推進する SMB 戦略をリードしていました。Claire は米国を拠点としています。 本記事の飜訳は、カスタマーソリューションマネージャーの釈迦郡一郎が担当しました。

こんにちわ。ソリューションアーキテクトの齋藤です。 本稿では、AWS PrivateLink による企業間プライベートネットワーク接続の例についてご紹介します。 AWSは、グローバルでは数百万、日本でも数十万のお客様にご利用いただいているクラウドサービスであり、昨今、企業でAWSクラウドの環境を持っている場合が多く、企業間のプライベートネットワーク接続を AWS 上で構築するケースも増えてきました。その際、オンプレミスで構築するような専用線を敷設し、双方でルーター、ファイアウォール設置して DMZ を構築するような手法をそのまま踏襲するのではなく、AWS のサービスに置き換えて設計する必要があります。 まず、企業間のプライベートネットワーク接続の際に考慮となるポイントはどんなものがあるでしょうか。以下のオンプレミスにおける接続例を見てみましょう。 図1: オンプレミスにおける企業間プライベートネットワーク接続の構成例 上図は、企業 A と企業 B のデータセンター同士を専用線でプライベート接続している例です。企業Aから企業Bに対し、HTTP/HTTPS 通信、SFTP 通信を行う要件があります。前提条件・構成は、企業によって異なりますが、例として以下のように設定してみました。 前提条件 企業 A は、企業 B の提供する HTTP/HTTPS サービス、SFTP サーバーにインターネットを介さず、プライベートネットワーク経由でアクセスすること Inbound 通信は、必要な通信のみを許可すること 双方のプライベートネットワークアドレス帯の重複を考慮し、お互い合意をとった CIDR を DMZ に割り当て、NAT変換を行うこと 構成 DMZ に配置した Firewall アプライアンスで、アドレス変換( NAT )とアクセスコントロールを設定 DMZ に配置ルーター同士で DMZ の CIDR のみを経路交換 DMZ 内のコンポーネントは冗長性を持ち、ここでは 専用線、Firewallアプライアンス、ルーターがそれぞれ冗長構成 このような前提条件・構成を AWS でどのように実現できるのか見て行きましょう。 AWS における企業間接続 AWS で前述のようなオンプレミスで実施している企業間接続を実現したい場合、重要なことは、 DMZ を作って、Firewall で NAT とアクセスコントロールを導入することではありません。連携したい企業とのネットワーク接続要件を最小限のアクセスでセキュアに実現することです。 AWS では、 AWS PrivateLink を利用することで、企業間、つまり異なる AWS アカウントの VPC 間の全てのトラフィックを AWS のネットワーク内に維持しながら、AWS 内にホストされているサービスに対するプライベート接続を提供することができます。サービス利用者側の VPC 内にあるかのようにサービス提供側の VPC 内のサービスにプライベートに接続するために使用できる、可用性が高くスケーラブルなテクノロジーです。 Internet Gateway 、 NAT Gateway 、 VPC Peering 、 VPN 接続 等も不要であるため、サービス提供側はリソースを外部ネットワークに公開するリスクを低減することができます。 セキュリティグループ 等で、アクセス制御することも可能です。 以下の図は、AWS PrivateLink を用いて、異なる AWS アカウントの VPC 間で、AWS リソースへのネットワークアクセスを提供している構成例です。ここでは、企業 B のホストするHTTP(S) サービス、SFTP サービスを企業 A にプライベート接続で提供しています。サービス利用者側(企業 A )は、Direct Connect Gateway, Transit Gateway で接続されたオンプレミス環境と AWS 環境を持っており、アクセス元となるクライアントは、オンプレミスのネットワーク、VPC に存在することを想定しています。 図2: AWS PrivateLink を用いた企業間プライベートネットワーク接続の構成例 サービス利用者側（企業A：Consumer）、サービス提供者側（企業B：Service Provider）それぞれの構成を解説していきます。 サービス提供者側（企業 B：Service Provider） サービス提供側である企業 B は、 Application Load Balancer でホストされるHTTP(S) サービスと Amazon EC2 でホストする SFTP サービスを企業 A に提供をしたいです。この 2 つのサービスに対するプライベートアクセスを AWS PrivateLink を介して提供するためには、 Network Load Balancer (NLB) を構築し、NLB と関連づく AWS PrivateLink endpoint を作成、サービス利用者へアクセス権限を付与することで、別の AWS アカウントからのプライベートアクセスを実現します。NLB はレイヤー 4 で動作するロードバランサーで、Private Link endpoint 作成するために必要となるコンポーネントです。NLB は、HTTP/HTTPS(tcp/80,443) に対する接続リクエストを Application Load Balancer でホストされるHTTP(S) サービス、SFTP(tcp/22) に対する接続リクエストを、Amazon EC2 でホストする SFTP サービスにルーティングします。また、アクセスコントロールは、AWS PrivateLink における プリンシパルに対する許可設定 、NLB に紐づくセキュリティグループで行います。 サービス利用者側（企業 A：Consumer） サービス利用側は、企業 B から提供を受けた AWS PrivateLink のエンドポイントサービスから自社 AWS アカウントの VPC 内に VPC エンドポイントを作成することで対象のサービスへのプライベートアクセスができるようになります。作成した VPC エンドポイントに紐づくセキュリティグループでアクセスコントロールを行います。 このように、AWS PrivateLink を利用することで、企業間、つまり異なる AWS アカウントの VPC 間で必要な通信のみを許可するプライベートアクセスを実現することができます。また、お互いの VPC の CIDR 割り当てに依存しないため、IP の重複を考慮する必要もなく、DMZ を新たに構築する必要もありません。ここでは、企業 A から企業 B へのアクセス方向の例を挙げましたが、逆向きの場合は、同様のことを企業 A と B で入れ替えて実施することで、双方向にサービスの提供を行うことができます。 手順・構成方法 ここからは、具体的な手順の例として、以下の図のような ALB でホストされる HTTP サービス、Amazon EC2 でホストする SFTP サービスを、AWS PrivateLink で、別の AWS アカウントの VPC に提供する方法を紹介します。 AWS Account B (Service Provider) NLB の設定 ここでは、NLB の構築方法については省略しますが、以下のように、TCP/80 は ALB の属するターゲットグループ、TCP/22 は SFTP サーバーの属するターゲットグループにルーティングするリスナー設定を持つ NLB があり、これを別の AWS アカウントの VPC に AWS PrivateLink でプライベート接続を提供していきます。 NLB で使用するセキュリティグループでは以下のように、AWS Account A(Consumer) 側のアクセス元となるサーバーの CIDR を指定してアクセス許可を行います。 AWS Account B(Service Provider) PrivateLink Endpoint の作成 次に、PrivateLink Endpoint の作成を行います。AWS マネジメントコンソールの VPC のメニューのエンドポイントサービスから、エンドポイントサービスを作成を選択すると以下のような画面となりますので、対象の NLB を選択します。 作成を行うと、以下のように、エンドポイントサービスが作成されます。「サービス名」が提供先で必要な情報となります。また、NLB の存在するアベイラビリティゾーンがリストされていますが、提供先で作成する VPC エンドポイントも同じ アベリラビリティゾーン ID である必要があるため、合わせて伝える必要があります。 次に「プリンシパルを許可」のタブを開き、提供先となる AWS アカウントからの利用を許可します。 ここでは、AWS アカウント A の ID を指定するため、プリンシパルで arn:aws:iam::[AWS Account ID]:root のように記述します。事前に提供先の AWS アカウント ID は確認しておきましょう。 これで AWS アカウント B 側でのPrivate Link の作成は完了です。 AWS Account A(Consumer) VPC endpoint の作成 次に、AWS Account A 側での作業を行います。 AWS マネジメントコンソールの VPC のメニューから エンドポイント＞エンドポイントの作成を行います。 サービスカテゴリは、「その他のエンドポイントサービス」を選択し、サービス名で、AWS アカウント B 側で作成したエンドポイントサービスのサービス名を入力し、サービスの検証を行います。検証が成功すれば、そのまま設定を進めていきます。 エンドポイントを作成する VPC を選択すると、作成可能なアベイラビリティゾーンとサブネットが選択可能になります。ここで選択可能なアベイラビリティゾーンは、サービス提供側の NLB の存在するアベイラビリティゾーンであるため、エンドポイントを作成するサブネットのアベイラビリティゾーンは事前に確認しておきましょう。 エンドポイントに対し、セキュリティグループを設定しますので、事前に必要な通信を許可するセキュリティグループを作成しておきましょう。   AWS Account B(Service Provider) PrivateLink の承諾 承認設定で、特定のプリンシパルに許可を付与して自動的にすべての接続リクエストを承諾するか、手動で承諾するかエンドポイントサービスにアクセスできる AWS プリンシパルを制御できます。ここではデフォルトのままなので、手動で承諾します。 AWS Account A 側で、VPC エンドポイントを作成すると状態が承諾待ちになります。以下のように、AWS Account B 側でエンドポイントリクエストの承諾を完了することで、利用可能な状態となります。 AWS Account B 側   AWS Account A 側   AWS Account A(Consumer) 動作確認 それでは、AWS Account A にあるクライアントである EC2 インスタンスからアクセス確認をしてみます。アクセス先は VPC エンドポイントの DNS 名に対して行います。 HTTP リクエスト [ssm-user@ip-10-2-11-30 ~]$ curl http://vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com ip-10-1-22-193.ec2.internal (レスポンス結果) SFTP アクセス [ssm-user@ip-10-2-11-30 ~]$ sftp sftpuser@vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com sftpuser@vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com's password: Connected to vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com. sftp> AWS Account A の VPC 内にある EC2 インスタンスから、VPC 内のアドレスを持つ VPC エンドポイントを経由して、AWS Account B のVPC 内でホスティングされているサービスにアクセスをすることができました。 まとめ 本稿では、AWS PrivateLink を利用した 企業間プライベートネットワーク接続の例をご紹介しました。AWS PrivateLink を用いることで、必要最小限のアクセス許可で、お互いの VPC の CIDR の重複を考慮することなく、企業間プライベートネットワーク接続を構築することが可能です。 オンプレミス同士の接続を AWS クラウド同士の接続に移行をご検討されている際には、 AWS Well-Architected Framework において、「最小特権の原則に則った設計の一部として、可能な限り、ネットワークピアリングよりもポイントツーポイントフローを優先します。」と記述がある通り、AWS PrivateLink をまずご検討いただくことをお勧めします。 本稿が、AWSにおける企業間プライベートネットワーク接続をご検討されている方のお役に立てば幸いです。

新しい Amazon Web Services (AWS) コミュニティイベントが毎週開催されており、交流の輪を広げ、新しい事柄を学び、コミュニティに活発に参加することができます。コミュニティにいるときは、誰もが共に成長し、取り残される人は 1 人もいません。9 月 23 日週も例外ではありませんでした。そのハイライトとして、 Viktoria Semaan による How to Create Impactful Content and Build a Strong Personal Brand というタイトルの講演で幕を閉じた Dutch AWS Community Day や、 Peru User Group が企画した 2 日間の講演と学びの機会であり、 Jeff Barr が自分の運を創り出す方法について話した UGCONF & SERVERLESSDAY 2024 などが挙げられます。コミュニティイベントはまだまだ続いています。 近日開催予定の AWS Community Day でイベントをご確認ください。 9 月 23 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock が AI21 Labs による Jamba 1.5 モデルファミリーの提供を開始   – Jamba 1.5 Large モデルと 1.5 Mini モデルは 256,000 のコンテキストウィンドウを備えています。これは市場で最も長いコンテキストウィンドウの 1 つであり、長い時間がかかるドキュメント分析といった複雑なタスクの実行を可能にします。これらのモデルは構造化された JSON 出力、関数の呼び出し、およびドキュメント処理をネイティブにサポートしており、特化型 AI ソリューションのエンタープライズワークフローに統合されます。詳細については、「 Jamba 1.5 family of models by AI21 Labs is now available in Amazon Bedrock 」と ドキュメント を読み、 Amazon Bedrock の AI21 Labs ページ にアクセスしてください。 AWS GovCloud (米国) リージョンで AWS Lambda が Amazon Linux 2023 ランタイムのサポートを開始 – これらのランタイムは、Python 3.12、Node.js 20、Java 21、.NET 8、Ruby 3.3、および Amazon Linux 2023 などの最新の言語機能を提供します。デプロイフットプリントがより小さくなっており、更新されたライブラリと新しいパッケージマネージャーが装備されています。また、コンテナベースのイメージを使用して、関数をコンテナイメージとして構築し、デプロイすることもできます。 Amazon SageMaker Studio がアイドル状態になったアプリケーションの自動シャットダウンのサポートを開始 – Amazon SageMaker Distribution イメージ v2.0 以降を使用して、非アクティブな JupyterLab アプリケーションと CodeEditor アプリケーションを自動的にシャットダウンできるようになりました。管理者は、ドメインまたはユーザープロファイルレベルでアイドルシャットダウン時間を設定でき、オプションでユーザーによるカスタマイズも可能です。このコスト管理メカニズムは、使用されていないインスタンスの料金を回避するために役立ち、SageMaker Studio が提供されているすべての AWS リージョンで利用できます。 Amazon S3 が、あらゆる S3 ストレージクラスに対する S3 ライフサイクル移行ルールにデフォルトの128 KB 最小オブジェクトサイズを実装 – 移行リクエスト数を削減することで、多数の小規模オブジェクトが含まれるデータセットの移行コストを低減します。ユーザーは、デフォルトを上書きして最小オブジェクトサイズをカスタマイズできます。既存のルールは変更されませんが、新しい設定または変更された設定には新しいデフォルトが適用されます。 11 の追加リージョンで Amazon Redshift データ共有のための AWS Lake Formation の一元化されたアクセスコントロールの提供を開始 – 共有された Amazon Redshift データへのテーブル、列、および行レベルでのアクセスを含めた、きめ細かな許可管理を実現します。また、セキュリティの強化と管理の簡素化のために、タグベースのアクセスコントロールや、 AWS IAM アイデンティティセンター を用いた信頼できるアイデンティティの伝達もサポートしています。 Amazon Bedrock が Llama 3.2 生成 AI モデルの提供を開始 – このコレクションには、高度な推論タスク向けの 90B および 11B パラメータマルチモーダルモデルと、エッジデバイス向けの 3B および 1B テキスト専用モデルが含まれています。ビジョンタスクをサポートし、より優れたパフォーマンスを提供するこれらのモデルは、さまざまなアプリケーション全体で責任ある AI イノベーションを実現するように設計されています。これらのモデルは、128,000 のコンテキスト長と、8 言語での多言語機能をサポートしています。詳細については、「 Amazon Bedrock で利用可能になった Meta からの Llama 3.2 モデルの紹介 」をお読みください。 AWS End User Messaging SMS リソースを複数の AWS アカウント間で共有 – AWS Resource Access Manager (RAM) を使用して、電話番号、送信者 ID、電話プール、オプトアウトリストを共有できます。さらに、 Amazon SNS が AWS End User Messaging 経由で SMS テキストメッセージを配信するようになったため 、双方向メッセージングやきめ細かな許可といった拡張機能も提供されます。これらの更新は、AWS サービス全体で SMS メッセージングの柔軟性を向上させ、制御を強化します。 AWS Serverless Application Repository が AWS PrivateLink のサポートを開始 – インターネットに露出されることなく、 Amazon Virtual Private Cloud (VPC) から直接接続することを可能にします。この機能は、コミュニケーションを AWS ネットワーク内に留めておくことで、セキュリティを強化します。 AWS Serverless Application Repository が提供されているすべてのリージョンで利用でき、 AWS マネジメントコンソール 、または AWS コマンドラインインターフェイス (AWS CLI) を使用してセットアップできます。 Amazon SageMaker with MLflow がセキュアなトラフィックルーティングのために AWS PrivateLink のサポートを開始 – AWS ネットワーク内での Amazon Virtual Private Cloud (VPC) から MLflow Tracking Server へのセキュアなデータ転送を実現します。この機能は、パブリックインターネットへの露出を回避することで、機密情報の保護を強化します。ほとんどの AWS リージョンで利用でき、MLflow を使用した機械学習 (ML) と生成 AI 実験のセキュリティを向上させます。 Amazon EC2 C8g および M8g インスタンスの導入 – コンピューティング集約型および汎用ワークロードのパフォーマンスを向上させます。最大 3 倍の vCPU、3 倍のメモリ、75% 多いメモリ帯域幅、および 2 倍の L2 キャッシュを備えたこれらのインスタンスは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、マイクロサービスなどのさまざまなアプリケーションのデータ処理、スケーラビリティ、コスト効率性を向上させます。詳細については、「 Run your compute- intensive and general purpose workloads sustainably with the new Amazon EC2 C8g, M8g instances 」をお読みください。 Amazon SageMaker JumpStart が Llama 3.2 モデルの提供を開始 – これらのモデルは、1B パラメータから 90B パラメータにおよぶさまざまなサイズを提供しており、画像推論などのマルチモーダルタスクをサポートし、AI ワークロードをより効率的に実行できます。1B モデルと 3B モデルはファインチューニングが可能で、Llama Guard 3 11B Vision は責任あるイノベーションとシステムレベルの安全性をサポートします。詳細については、「 Llama 3.2 models from Meta are now available in Amazon SageMaker JumpStart 」をお読みください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Deploy generative AI agents in your contact center for voice and chat using Amazon Connect, Amazon Lex, and Amazon Bedrock Knowledge Bases – このソリューションはお客様との低レイテンシーでのやり取りを可能にし、ナレッジベースから質問に回答します。機能には、サーバーレスアーキテクチャでの会話分析、自動化されたテスト、ハルシネーション検出などがあります。 How AWS WAF threat intelligence features help protect the player experience for betting and gaming customers – AWS WAF は、ベッティングやゲーミングのためのボット保護を強化します。新しい機能には、ブラウザフィンガープリント、自動化検出、組織的なボットを識別するための ML モデルなどがあります。これらのツールは、スクレイピング、不正行為、分散型サービス拒否 (DDoS) 攻撃、およびチート行為に対抗することで、プレイヤーエクスペリエンスを保護します。 How to migrate 3DES keys from a FIPS to a non-FIPS AWS CloudHSM cluster – RSA-AES ラッピングを使用して、バックアップなしで 3DES (Triple Data Encryption Algorithm) キーを米国連邦情報処理規格 (FIPS) hsm1 クラスターから非 FIPS hsm2 クラスターにセキュアに転送する方法を学びます。この方法は、FIPS 140-3 レベル 3 のサポート、非 FIPS モード、より多くのキー容量、および相互 TLS (mTLS) を備えた新しい hsm2.medium インスタンスの使用を可能にします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。これらのイベントは、エキスパートによるテクニカルセッション、デモ、ワークショップを提供します。登録可能なイベントは、残すところ オタワ (10 月 9 日) のみになりました。 AWS Community Day  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。次回の AWS Community Day は、10 月 3 日に オランダ と ルーマニア 、および 10 月 5 日に ジャイプル 、 メキシコ 、 ボリビア 、 エクアドル 、 パナマ で開催される予定です。私は 10 月 5 日のパナマコミュニティに参加する予定で、とても楽しみにしています。 AWS GenAI Loft  – クラウドと AI に関する AWS の専門知識を紹介するコラボレーションスペース兼没入型エクスペリエンスであり、AI 製品やサービスを実際に体験し、業界リーダーとの独占セッションに参加して、投資家や同業者との交流の輪を広げる貴重な機会をスタートアップやデベロッパーに提供します。 お近くの GenAI Loft 開催地を見つけて 、登録するのをお忘れなく。私は、10 月 15 日の Gen AI Developer Day でサンフランシスコラウンジに参加し、いくつかのデモを行う予定です。参加される場合は、ぜひ立ち寄ってお声をおかけください! 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 今週はここまでです。10 月 7 日週の Weekly Roundup もお楽しみに! コミュニティイベントの写真を提供してくださった Dmytro Hlotenko 氏と Diana Alfaro 氏に感謝いたします。 – Eli この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024年10月10日、経済産業省と国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が協力して実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の2サイクル目 (2024年7月公募) における採択事業者のキックオフが行われ、本事業の採択事業者が発表されました。 7月の AWS ブログ でお伝えした通り、「経済産業省が計算リソース提供事業者から一括で確保し採択事業者へ提供する提供事業者」として AWS が選定され、同スキームを通じて NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge ) を提供します。また、「採択事業者が計算リソース提供事業者と個別に調整し直接確保」するスキームを通じて、上記 EC2 P5 インスタンスに加えて、採択事業者のニーズに合わせ Amazon SageMaker HyperPod および Amazon EC2 Trn1 インスタンス を提供することとなりました。 AWS は、計算リソース提供事業者として、GENIAC 支援チームを立ち上げたうえで以下の支援を提供します: 計算資源 : NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンスまたは EC2 Trn1 インスタンスの提供 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster や SageMaker HyperPod を活用した構築・管理の支援 開発者コミュニティ : 海外の機械学習エンジニアとの交流による最先端の開発動向 (11月)、国内の機械学習エンジニア同士の交流による知見共有 (11月) をはじめとした国内外の知見共有に向けた支援 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの go-to-market 支援や AWS Marketplace の活用、利用企業との AWS 主催イベントを通じたマッチング機会の提供 (11月) これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみを掲載): AI inside株式会社 AiHUB株式会社 SyntheticGestalt株式会社 Turing株式会社 カラクリ株式会社 ストックマーク株式会社 フューチャー株式会社 株式会社EQUES 株式会社Preferred Elements 株式会社ヒューマノーム研究所 株式会社ユビタス 株式会社リコー 国立研究開発法人海洋研究開発機構 採択事業者からコメントを頂きました: 先端AIアーキテクチャを用いた処理においても信頼性高く稼働するインフラサービスを提供するAWS様に、技術/ビジネスの両面にていつもお世話になっております。GENIACサイクル2における大規模なAIモデルの学習処理においても、SageMaker HyperPodを活用することで円滑に開発が進むことを期待させていただければと思います。 — ストックマーク株式会社 取締役CTO 有馬 幸介 氏 この度インバウンド業務の課題を解決することを目的に、アジア言語対応の強化を目指したモデル開発において、モデル開発に弊社リソースを集中させ、効率的に開発が推進できるよう、基盤モデル構築に最適化されたマネージド型のインフラストラクチャを提供する Amazon SageMaker HyperPod を選択しました。今後AWSとAI活用に向けて更なる協業を期待しています。 — 株式会社ユビタス CEO Wesley Kuo 氏 AWSからは技術・ビジネスの両面でご支援いただき大変感謝しております。AWS Trainium は効率的にLLM開発を進めることができる最適な選択肢だと思っております。 — カラクリ株式会社 取締役CPO 中山 智文 氏 Preferred Networksグループでは、世界最大級の高品質なデータセットを構築し、私たちが開発する大規模言語モデル「PLaMo」のさらなる進化と社会実装に向けて取り組みます。 研究開発の効率化のため、Amazon EC2 P5インスタンスおよびAWS ParallelClusterを利用します。 AWSからの多大なサポートと革新的なソリューションに感謝いたします。 — Preferred Networks 代表取締役 最高研究責任者, Preferred Elements 代表取締役社長 岡野原 大輔 氏 AWSが提供するEC2 P5インスタンスおよびAWS ParallelClusterを活用し、完全自動運転の実現に向けた身体性をもつマルチモーダル基盤モデルの開発を進めていきます。現実の多様な運転環境に対応するため、独自の大規模走行データを新規に構築し、これをもとに複雑な交通状況を理解・予測できるモデルの開発を行います。AWSのスケーラブルなインフラにより、膨大なデータの処理と大規模モデルの学習を効率的に進め、短期間で高精度なモデルの実現を目指しています。 — Turing株式会社 CTO 山口 祐 氏 地域または企業レベルで効果的な温暖化対策立案を目的とした気候サービスのための生成AI基盤モデル開発に当たり、大規模言語モデルを始めとした深層学習において高いパフォーマンスを発揮するNVIDIA H100 Tensor Core GPUを搭載したAmazon EC2 P5インスタンスを選択しました。基盤技術の開発から実用化・事業化、社会実装に向けた開発までが加速されることを期待しています。 — 国立研究開発法人海洋研究開発機構 付加価値情報創生部門 地球情報科学技術センター データサイエンス研究グループ 松岡 大祐 氏 AWS では日本のお客様に対し、昨年の AWS LLM 開発支援プログラム にはじまり、 グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。そこで得られた知見をもとに、GENIAC における日本の生成 AI 開発力向上に貢献できれば幸いです。

本ブログでは、消費財業界向けに発表した e-Book「 消費者に愛される ブランドを 構築する 」について紹介します。 消費財業界は、テクノロジーの急速な進歩により、かつてないほど多様性に富んだ時代を迎えています。企業は、商品の製造、流通、マーケティング、評価の方法を改善するために必要なデータ、分析、ツールを利用できるようになりました。しかし、消費財企業の経営幹部の多くは、自社のビジネスを継続的にモダナイズしなければ、事業の存続が危ぶまれる可能性さえあると考えています。次世代のコンピテンシーを迅速に適用できるよう努め、消費者に愛されるブランドの構築が事業成功の鍵になるのです。 ブランドとは、商品の品質、カスタマーサービス、マーケティングや広告の印象、評判などの無形要素を含む、企業に対する総合的な認識を表すものです。新たに公開された Amazon Web Services (AWS) の eBook では、消費財ブランドを高める際に欠かすことのできない重要な要素について解説しています。また、魅力的なブランドの構築に役立つ長期的な考慮事項や、消費財企業が AWS のクラウドテクノロジーを利用して、この動的な市場の進化する課題に対応する方法についても説明します。さらに、先進消費財企業の事例に見る 6 つの重要なソリューション分野や、AI によって消費財ブランドがどのように変革されるのかについても触れています。 魅力的なブランドを構築するための 4 つの重要な要素と長期的な考慮事項 魅力的なブランドを構築し維持するためのポイントについて整理しています。まずブランド構築のために、データ戦略、サプライチェーン、IT インフラ、イノベーションの 4 つの要素に注力することが重要です。さらに、長期的な視点から、パーソナライゼーション、D2C （Direct to Consumer）戦略、オムニチャネル販売、社会的責任、M&A 活動にも取り組む必要があります。これらの要素を組み合わせることで、消費者のニーズに応え、競争力のあるブランドを確立することができます。デジタル技術の活用と消費者中心のアプローチを通じて、ブランドの価値を高め、持続可能な成長を実現することが可能となります。 4 つの重要な要素 セキュリティに基づくデータ戦略の設定 ：消費者のプライバシーを尊重しつつ、パーソナライズされたレコメンデーションを提供するためのデータ戦略を策定します。 サプライチェーン業務のモダナイズ ：AI ベースの予測や在庫の最適化を通じて、消費者がいつでもどこでも商品を購入できるようにします。 IT インフラストラクチャの変革 ：クラウドインフラとマイクロサービスアーキテクチャを活用し、業務改善とコスト削減を実現します。 イノベーションのパイプライン確立 ：継続的に革新的な新商品を提供、ビジネス全体でイノベーションを推進します。 長期的な考慮事項 パーソナライズを強化してロイヤルティを高める ：AI と機械学習を活用し、すべてのタッチポイントでパーソナライズされた体験を提供します。 コスト効率の高い方法で D2C を実現する ：直接消費者とつながり、ファーストパーティデータを収集するための D2C 戦略を検討します。 商品をどこからでも購入可能にする ：オムニチャネル戦略を採用し、消費者がいつでもどこでも商品を購入できるようにします。 社会的責任と信頼性を一致させる ：環境への配慮や社会貢献活動を通じて、ブランドの信頼性を高めます。 M&A 活動をモニタリングする ：新商品やブランドの追加、競合他社の買収などの M&A 機会を常に探ります。 　 先進消費財企業の事例に見る 6 つの重要ソリューション分野と AWS の成功事例 消費財企業が AWS を選ぶ理由 上記の考慮事項を踏まえ、多くの消費財企業から AWS は選ばれてきました。AWS は、Amazon が過去 25 年間に使用および改良を重ねてきたものと同じクラウド機能を提供し、実証済みの価値をもたらすことで、消費者の信頼とブランドロイヤルティを高める消費財のユースケースを推進しています。AWS を利用することで、データプライバシーを保護しながら消費者のインサイトを得る、品質を犠牲にすることなくコストを削減する、モダンなITインフラストラクチャで俊敏性と柔軟性を得る、AIを活用した俊敏なイノベーションパイプラインを作成する、といったメリットがあります。 6 つの重要なソリューション分野とAWS の成功事例 AWS の先進的なソリューションは、消費財企業の様々な課題解決に貢献しています。商品開発から製造、サプライチェーン管理、マーケティング、コマース、IT インフラまで、幅広い分野で AWS のサービスが活用されています。AI 、IoT 、データ分析などの最新技術を駆使することで、消費者ニーズへの迅速な対応、効率的な業務運営、一貫したブランド体験の提供が可能になります。これらの成功事例は、AWS が消費財企業のデジタルトランスフォーメーションと競争力強化に不可欠なパートナーであることを示しています。 商品開発：高度な技術で商品開発を加速する 消費者のフィードバック、ソーシャルメディアでの口コミ、市場動向などをを収集、分析することから、新たな消費者の好みや満たされていないニーズを特定する、このインサイトドリブンなアプローチは、革新的な商品を開発するのに役立ちます。 紹介されている顧客事例 家庭用品からヘルスケア用品まで消費者製品の提供を手がける Helen of Troy は、 AWS IoT Core を使用して消費者の Bluetooth 対応デバイスである、コネクテッド体温計からデータを収集し、カスタマーエクスペリエンスの継続的な革新と改善を実現しています。このデータ分析により、スマートデバイスの最も有用な機能を特定し、効果的なリソース配分を行っています。例えば米国全土で体温データを収集していることで、ある地域で病気が増加している場合に、保護者に通知することが可能です。この通知が行動に影響を与え、感染症の伝染減少につながる可能性があります。 製造：品質とサステナビリティを維持しながら製造を最適化する 消費者はよりよい商品をより安く手に入れるだけでなく、持続可能な方法で生産された商品を求めてもいます。環境に配慮しつつ製造プロセスを最適化する新しい方法を模索し、消費者の期待に応え、上回らなくてはなりません。 紹介されている顧客事例 大手パルプ・製紙企業の Georgia-Pacific は、AWS で稼働する SAS Viya ソリューションを導入し、生産性と流通を向上させました。15,000 以上の機械学習モデルと分析プラットフォームにより、潜在的な機器の故障を予測して計画外のダウンタイムを 30% 削減しながら、安全上の事故や非効率的な機械運用、予期しない生産中断を防止しています サプライチェーン：AI ドリブンの分析によりサプライチェーンの回復力を向上させる サプライチェーンにおけるコラボレーションは、在庫管理の改善、在庫切れの減少、物流コストの削減につながります。消費者が購入したいときにどこからでも商品を購入できるようにすることで、カスタマーエクスペリエンスを向上させます。欠品によるブランドの信頼低下も防ぎます。 紹介されている顧客事例 飲料ボトリング会社 Coca-Cola Andina は、AWS を活用して社内向け Thanos アプリケーションを構築し、在庫管理やニアリアルタイムでの業務追跡を実現しました。これにより、各流通センターの状況確認や従業員の生産性追跡、注文ステータスの追跡が可能となり、業務の可視性が大幅に向上しました。分析チームの生産性が 80% 向上したことで、よりデータ駆動型の意思決定ができるようになったのです。 マーケティング：エンゲージメントの価値強化で、ブランドロイヤルティを高める ブランドロイヤルティを構築する体験を生み出すためには、商品の魅力を高めるだけでなく、有意義な消費者エンゲージメントを通じて、今日の競合ひしめく市場で差別化を図る必要があります。 紹介されている顧客事例 食品飲料メーカーである Danone Indonesia は、AWS パートナーの Treasure Data の顧客データプラットフォーム (CDP) を使用して、消費者の関心を特定し、ウェブサイトでのエンゲージメントを追跡、過去の購入履歴を確認しています。これにより、デジタルおよび非デジタルチャネルを通じた一貫したカスタマージャーニーの追跡が可能となり、AI ベースの商品レコメンデーションやライフタイムバリューの予測などが実現しました。 ユニファイドコマース：オムニチャネルコマースにより一貫性のある消費者エクスペリエンスを創出 現代のオムニチャネルコマースを理解し、商品をいつでも、どこからでも見つけられるように、小売業者とデジタルコマース機能をシームレスに連携する必要があります。また、消費者がどこでどのように買い物をしても一貫したブランド体験を提供できるようにすることも求められます。 紹介されている顧客事例 燻製器、グリル、バーベキュー用品でよく知られている Traeger は、 Amazon Connect の機能を活用して、データと機械学習モデルを使用した自動問題検出システムを構築しました。これにより、エージェントの顧客満足度と初回解決率が約 15% 向上し、通話時間も約 15% 短縮されました。 IT とデジタルトランスフォーメーション：IT インフラストラクチャのモダナイズによるビジネス成果の向上 消費財企業は、スピードと俊敏性を高めるために、クラウドベースのソリューションを使用してテクノロジーインフラストラクチャをモダナイズする必要があります。 紹介されている顧客事例 サントリー は、AWS を共通環境として採用し、5 つの異なるシステムを 1 つの一貫性のあるグローバルインフラストラクチャシステムに統合しました。インフラストラクチャの総保有コスト (TCO) を約 25% 削減できました。これにより、アプリ開発の高速化やメンテナンス負荷の軽減、セキュリティ対策の強化、ビジネスの可視化を実現しました。 　 AI によって消費財ブランドはどう変わるのか 消費財企業が AI を活用してブランド構築を強化する動きが加速しています。効率向上、意思決定の強化、イノベーション推進を目指す中で、特に以下において AI の利用が増加すると予想されています。 需要予測 : AI アルゴリズムが過去の売上データや市場動向を分析し、より正確な需要予測を生成。在庫の最適化と顧客体験の向上につながります。 サプライチェーンの最適化 : AI システムがリスク予測や非効率箇所の特定、配送ルートの最適化を行い、物流効率を高めコスト削減を実現します。 商品開発とイノベーション : 機械学習や NLP （自然言語処理）を活用し、消費者のフィードバックや市場動向を分析。消費者ニーズに合った商品開発や改良が可能になります。 品質管理と保証 : AI 画像認識システムが生産ライン上で効率的に商品を検査。一貫した品質確保と不良品リスクの軽減に貢献します。 価格の最適化 : AI アルゴリズムがリアルタイムで市場動向を分析し、最適な価格戦略を提案。競争力維持と収益最大化を両立させます。 カスタマーサービス : AI チャットボットやバーチャルアシスタントが 24 時間体制のサポートを提供。顧客体験の向上と人的リソースの効率化を実現します。 これらの分野で AI を活用することで、消費財企業はより効率的で革新的なブランド構築が可能になります。市場の変化に迅速に対応し、顧客ニーズを的確に捉えた商品開発やサービス提供が実現することで、ブランド価値の向上と競争力の強化が期待できます。 　 まとめ 消費財業界は、テクノロジーの急速な進歩により大きな変革期を迎えています。企業は、商品の製造、流通、マーケティング、評価の方法を改善するために必要なデータ、分析、ツールを利用できるようになりました。消費財企業が消費者に愛されるブランドを構築するためには、セキュリティに基づくデータ戦略の設定、サプライチェーン業務のモダナイズ、IT インフラストラクチャの変革、イノベーションのパイプラインの確立が重要です。 また、パーソナライズの強化、D2C の実現、商品の購入可能性の拡大、社会的責任と信頼性の一致、M&A 活動のモニタリングなど、長期的な考慮事項にも注目する必要があります。 本 eBook において、先進消費財企業の事例から、商品開発、製造、サプライチェーン、マーケティング、ユニファイドコマース、IT とデジタルトランスフォーメーションの 6 つの重要なソリューション分野における AWS の活用方法を学ぶことができます。AWS は、消費財ビジネスの業務と業績を変革する支援体制が整っています。消費財企業は、AWS の技術力とサービス、経験豊富なパートナーとビジネスイネーブラーを活用することで、スタートアップ並みの俊敏さで、チャンスを逃さず行動し、実践での効率性を高め、消費者に愛されるブランドを構築することができるのです。詳細についてはぜひ、本 eBook や その他の e-book をご参照ください。 消費財企業が成長するための極意 スマートストアテクノロジーの力を活用する 小売業のデジタルコマースを最適化する 4 つの重要なステップ 流通・小売・消費財企業のイノベーションを生成 AI で促進する 本ブログはソリューションアーキテクトの山下が執筆しました。

本ブログでは、消費財業界向けに発表した e-Book「 消費財企業が成長するための極意 」について紹介します。 消費財業界は、販売量と収益性の向上に焦点を当てた変革期を迎えています。 Deloitte の「 2024 Consumer Products Industry Outlook 」によると、72% もの経営幹部が、2024 年の業績目標を達成するためには販売数量を増やす必要があると答えています。販売量の増加は、収益、収益性、株主価値の向上を意味します。一方、消費者のし好の変化、競争激化、景気低迷、サプライチェーンの混乱などの要因はすべて、販売量停滞の一因となりかねません。成長を遂げるには、販売量と収益性のバランスが取れた戦略的なアプローチによる変革が必要です。この変革のカギとなるのが、クラウドテクノロジーとAI、特に生成 AI の活用です。 新たに公開された AWS の eBook では、 AWS が提供する包括的なクラウドソリューションを基盤として、消費財企業が成長するための方法を、IT とデジタルトランスフォーメーション、製品開発、消費財製造のスマート化、サプライチェーンの最適化、データドリブンマーケティング、e コマースという 6 つのビジネスの側面から、AI および AWS の活用について紹介しています。 IT とデジタルトランスフォーメーション ‐ AI で成果を生むための基盤を築く コード作成の高速化とエラー削減やデジタルトランスフォーメーションの加速と開発コスト削減という形で、AI の活用は開始されています。そして、IT とデジタルトランスフォーメーションは、AI 活用の基盤となり、強固なデータ戦略とモダンクラウドインフラストラクチャの構築が重要です。サイロ化されたデータをクラウドに集めてデータ基盤を確立してAIジャーニーをスタートするために、AWS は効率的なデータ管理に必要な柔軟性とスケーラビリティを提供します。そして生成 AI の導入により、開発プロセスの効率化やコスト削減が可能になります。 紹介されている顧客事例 Dole Packaged Foods は、AWS で稼働する Pillir の EdgeReady Cloud を活用して、製品発売プロセスを合理化しました。その結果、材料のマスターデータ管理コストを 30% 削減し、製品発売までの時間を短縮した事例を紹介しています。 製品開発 – 製品開発を最適化してイノベーションを起こす 成熟市場では、イノベーションが競争力維持の鍵となります。同じような商品だと価格競争になってしまうことも多く、そうならないためには製品開発の競争力が大事になります。AI は製品開発プロセスを革新し、消費者ニーズに合った画期的な製品の創出を支援します。また、生成 AI の導入により製品レビューの分析や新製品のアイデア創出が効率化され、市場投入までの時間短縮が可能になります。AWS は、AI やクラウドベーステクノロジーを最大限活用するためのインフラストラクチャ、サービス、ツール、ソリューションを提供し、企業が迅速な製品開発に集中できる環境を整えます。 紹介されている顧客事例 adidas は AI を活用して、販売実績、類似品、市場、競合他社に関する分析をまとめて、より適切な製品構成を決定しました。これにより、メンズの黒のパーカーの種類の最適化を実現しています。また15 万枚のシューズ画像で Stable Diffusion アルゴリズムをトレーニングし、迅速なアイデア創出と視覚化を実現している例についても紹介しています。 消費財製造のスマート化 – AI で製造コストを削減する Bain & Company によると、消費財業界の経営幹部の 54% が、2023 年の消費者支出削減の影響を大きく受けたと回答しています。消費者支出の削減への対応には、製品開発力だけでなく、AI を活用したスマートマニュファクチャリングによる、コスト削減も利益維持の鍵となります。AWS の製造業向けソリューションは、品質の向上、製造ラインのダウンタイムの削減、セキュリティ強化を実現し、製造オペレーションの変革を支援します。生成AIの導入により、機器のトラブルシューティングや診断が効率化され、ダウンタイムの削減ができる点についても紹介しています。 紹介されている顧客事例 Georgia-Pacific は、AWS パートナーである SAS の SAS Viya ソリューションを導入し、15,000 以上の機械学習モデルを実行しています。その結果、潜在的な機器の故障の警告を検出できるようになり、生産施設での計画外のダウンタイムを 30% 削減、さらに設備総合効率 (OEE) を 10% 向上できた事例となっています。 サプライチェーンの最適化 ‐ AI で俊敏性とレジリエンスを高める AI を活用したサプライチェーンの最適化は、効率的な製品配送と顧客満足度向上の要となります。予測の改善、在庫の最適化、マルチチャネル流通の実現により、企業の俊敏性とレジリエンスが高まります。生成 AI の導入により、複雑なサプライチェーンシナリオの分析や意思決定のサポートが可能になり、より戦略的なサプライチェーン管理が実現します。 紹介されている顧客事例 The Modern Milkman は、AWS パートナーの Peak と連携し、AI を活用した牛乳の需要予測を実装しました。これにより、サプライチェーンを全面的に合理化し、プロセスの効率を大幅に向上させ、食品廃棄を削減できています。向上した需要予測の精度とプロセスの効率性により、食品が傷まないようにする一方で、顧客にはこれまでどおり地元の農場の新鮮な商品を玄関先で受け取れ、新鮮な配達を実現できました。また、効率的な在庫管理プロセスにより、最大で週 3 回の注文を一晩で輸送および配達できるようになり、顧客体験の向上も実現しています。 データドリブンマーケティング ‐ 適切な消費者に適切なタイミングで訴求する データドリブンマーケティングは、効果的で強力なキャンペーンの実現と投資収益率の最大化を可能にします。顧客データプラットフォーム（ CDP ）の構築や、 AWS Clean Rooms などのツールの活用により、顧客データの力を最大限に引き出すことができます。生成AIの導入により、ターゲット顧客のセグメント化やパーソナライズされたコンテンツ作成が効率化され、より効果的なマーケティング活動が可能になります。 紹介されている顧客事例 水筒など飲料容器のメーカーの Pacific Market International（PMI） は、AWS パートナーの Amperity が提供する AI 搭載 CDP ソリューションを実装して分散している顧客データを統合し、統合カスタマービューを構築しました。その結果、高価格商品を買うセグメントが特定できて、そこに効果的なマーケティングを打つことができるようになり、それでクリックスルー率がが 350% 以上増加し、販売のコンバージョン率は 7 倍になりました。 e コマース – 消費者の購入機会を捉え接点を持つ eコマースにおける AI の活用は、オムニチャネル戦略と消費者直販（ D2C ）戦略の成功に不可欠です。需要計画、パーソナライズされたプロモーション、自動化されたカスタマーサービスなど、AI を活用することで販売機会を最大化できます。生成 AI の導入により、製品レビューの要約や検索体験の向上、インテリジェントなデジタルアシスタントの実現が可能となり、よりシームレスで魅力的な顧客体験を提供できます。 紹介されている顧客事例 L’Oréal Kerastase は、AWS パートナーの Valtech と協力して、ブラジルの消費者向けにシームレスでラグジュアリーなオンラインショッピング体験を 10 週間で構築しました。新しいプラットフォームにより、ブランドのサイトとバックエンドにおける e コマース機能が統合されていない部分が解消されてスムーズな UXを実現できました。これにより、デバイスやチャネルを問わずカートにアクセスできるようになり、ショッピング体験が向上したことで、カゴ落ちが減少しました。 まとめ 消費財企業が成長するための方法を IT とデジタルトランスフォーメーション、製品開発、消費財製造のスマート化、サプライチェーンの最適化、データドリブンマーケティング、e コマースという6つのビジネスの側面から、e-Book の一部を紹介しました。消費財業界では販売量と収益性に再びスポットが当たったことで、変革が進んでいます。AI は企業が優位に立つために必要な生産性と効率の向上をもたらしますが、AI を効果的に活用するには適切な戦略が必要です。AWS は、AI での成功を導く強固な基盤の設計と実装を支援します。AWS やパートナーが提供する AI などのクラウドベースソリューションは、お客様の成長の可能性を最大限に引き出すのに役立ちます。詳細についてはぜひ、本 eBook や その他の e-book をご参照ください。 スマートストアテクノロジーの力を活用する 小売業のデジタルコマースを最適化する 4 つの重要なステップ 流通・小売・消費財企業のイノベーションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの山下が執筆しました。

生成 AI が流通・小売・消費財業界にもたらす年間付加価値は 4,000 〜 6,600 億 USD と 試算 されています。多くの企業が生成 AI の導入を開始し、イノベーションや生産性向上を目指しています。2024 年には、マーケティング、カスタマーサービス、サプライチェーンなどの分野で AI ツールへの投資が検討されています。Amazon Web Services（AWS）は 25 年の経験を基に、エンタープライズグレードの生成 AI アプリケーションとインフラストラクチャを提供し、専門企業と提携して業界向けの AI ソリューションを展開しています。この e-book では、関連性の高いユースケースと導入のステップを紹介しています。本ブログはその概要と具体的なユースケースと関連する技術のハイライトを解説するものです。 生成 AI の導入を始めるには AWS は生成 AI を広く利用可能にし、流通・小売・消費財企業の変革を支援しています。生成 AI の効果的な導入には適切な戦略が必要で、以下の手順が推奨されます： 明確な目標を設定する 具体的で現実的なユースケースを特定する 最適な基盤モデル（FM）を選択する AWS のエキスパートやツールを活用する これらのステップを通じて、組織は生成 AI の導入を円滑に進め、イノベーションを促進できます。AWS は、 AWS Learning Needs Analysis ツールや AWS Skill Builder コースといった学習ツールを提供しています。AWS または AWS パートナーは、お客様が実行可能なロードマップを作成するお手伝いもしています。 生成 AI の導入における課題を検証する 流通・小売・消費財業界で生成 AI の競争が始まっています。導入には指針が必要で、技術とその影響の両面を考慮し、選択基準や成功指標、プロジェクト計画に反映させることが重要です。 生成 AI の活用事例: 流通・小売・消費財業界のユースケース AWS は小売業者と協働し、まず問題の最終的な解決策を構想し、そこを起点に逆算して考え、ビジネス目標を達成するために必要なタスクを特定します。この e-book では、さまざまなユースケースについて詳しく紹介しています。 ユースケース 1：消費者起点 生成 AI は、マーケティング、ショッピング、カスタマーサポートの各分野で顧客体験を向上させる強力なツールです。 マーケティングでは、消費者データの分析や、パーソナライズされたコンテンツ作成に活用できます。 ショッピングでは、AI スタイリストやバーチャル試着、ボイスコマースなどを通じて、最適な製品選びをサポートし、返品率の低減にも貢献します。 カスタマーサポートでは、AI チャットボットやエージェント支援システムにより、迅速な問題解決と顧客満足度の向上を実現します。 事例として、 Amazon Rufus があります。これは生成 AI を活用した自然言語で対応の可能なショッピングアシスタントで、Amazon の豊富なデータを基に、商品に関する質問への回答や比較、提案などを行い、消費者のショッピング体験を効率化・最適化します。シーンや目的に応じた買い物や商品カテゴリの比較、最適なおすすめ商品を見つけたり、商品詳細ページにいながら特定の商品について質問することができます。例えば、「ドリップ式とプアオーバー式（いわゆるハンドドリップ式）のコーヒーメーカーを比較してほしい」とユーザーが入力すると、それぞれの長所などを回答します。ユーザーがさらに「洗いやすいのはどっち」と質問すると「一般的にはドリップ式のほうが簡易」などと答えます。 ユースケース 2：製品起点 生成 AI は消費財企業の製品開発と市場投入を革新しています。顧客センチメント分析から新製品アイデアの創出、プロトタイプ作成、パッケージデザイン、品質確認、価格設定まで、幅広い用途があります。 The Very Group は、AWS の 生成 AI イノベーションセンター と協力し、AWS の技術を活用して高い精度で製品説明を作成するシステムを構築したことで製品の市場投入の速度を向上させました。 adidas は、大量の靴の画像データを用いて拡散アルゴリズムをトレーニングし、特定基準に基づく新しいランニングシューズデザインの生成を可能にしました。これにより、デザイナーは革新的なアイデアを得られ、創造性を高めることができます。 これらの事例は、生成 AI が製品開発プロセスを加速し、消費者ニーズへの対応を改善する可能性を示しています。 ユースケース 3：従業員起点 生成 AI は企業の日常業務を自動化し、効率性、従業員の定着率、品質を向上させることができます。特に、データレイクを持つ小売・消費財企業では、従業員への迅速な情報提供が可能になります。 従業員は自然言語でチャットボットに質問することで、在庫状況、機器の修理方法、過去の売上データなどの情報に簡単にアクセスできます。これにより、データに基づいたより良い意思決定が可能になります。また、生成ビジネスインテリジェンス（BI）を活用することで、実用的なインサイトやレポートの即時作成・共有も可能になります。 具体例として、 adidas の事例が挙げられます。同社は新入エンジニアが仕事を円滑に進められるようにチャットボットアシスタントを開発し、AWS 関連の質問に迅速に回答できるようにしました。 Amazon Titan Embeddings や Amazon Bedrock 、 LangChain を使用してアシスタントを構築しました。 さらに、 Amazon Q Developer を用いたパイロットプログラムも実施し、エンジニアのコーディング支援を提供しています。 adidas の Markus Rautert 氏は「Amazon Bedrock の導入により、インフラ管理の負担が軽減され、大規模言語モデルの開発プロジェクトの核心部分に集中できるようになりました。Amazon Bedrock を使用して、adidas のエンジニアは単一の会話型インターフェースを通じて、幅広い情報や回答を得ることができるようになりました」とコメントしています。 ユースケース 4：IT 起点 生成 AI は、プログラマーのコーディング効率を向上させます。大量のデータでトレーニングされた AI は、リアルタイムでコード案を生成し、複雑な作業を支援します。また、類似コードの検出や脆弱性のスキャン、修正提案も行い、開発プロセスを最適化します。 開始に適したツールとインフラストラクチャの選び方 目標を設定し、ユースケースを絞り込んだら、 次のことが可能になります。 生成 AI を活用したアプリケーションでユー ザー体験を変革する セキュアかつプライベートな生成 AI アプリケーションを簡単に構築してスケールする 最も高性能で低コストな生成 AI 向けインフラストラクチャのメリットを享受する データを差別化要因として活用する 1. 生成 AI を活用したアプリケーションでユーザーエクスペリエンスを変革する AWS には生成 AI を組み込んだ様々なアプリケーションが用意されており、今も開発が続けられています。自社にとって実現したいことが、すでに用意されているアプリケーションで解決されるのであれば、これを活用することは一つの選択肢です。例えば主要サービスの一つである Amazon Q は、コード生成、テスト、デバッグ機能を備え、複数ステップの計画・推論機能により開発者の要求に応じたコード生成が可能です。また、企業データリポジトリに接続し、データの要約、分析、対話を行うことで、従業員がより簡単に業務関連の情報にアクセスできます。この Amazon Q を使用した製品について、この e-book で紹介されているので、ご参照ください。 2. セキュアかつプライベートな生成 AI アプリケーションを簡単に構築してスケールする AWS は、あらゆる規模の組織や開発者が、生成 AI を組み込んだセキュアなアプリケーションを構築し、それをスケールさせるための環境を提供しています。主要なサービスである Amazon Bedrock を使うと、API を利用してさまざまな基盤モデルをアプリやシステムに組み込むことができます。モデルは複数の AI 企業から提供され、用途に合わせて簡単に切り替えられますし、自社のデータを用いたカスマイズやその評価、不適切な出力をフィルタする機能などが整っています。 実例として、 OfferUp の CTO Melissa Binde 氏は、Amazon Bedrock が提供するモデルの一つである、Amazon Titan Multimodal Embeddings を活用したセマンティック検索機能の実験について言及しています。「この新しいマルチモーダルモデルにより、キーワード検索の関連性が大幅に向上しています。 この進歩により、ユーザーマッチングの成功が大幅に促進され、買い手と売り手の両方に利益がもたらされます。」 3. 最も高性能で低コストな生成 AI 向けインフラストラクチャのメリットを 享受する AWS は、生成 AI を支える基盤モデル自体を自社で開発するのに最適なインフラストラクチャを提供しています。高性能の GPU ベース Amazon Elastic Compute Cloud （Amazon EC2）インスタンスや、専用アクセラレーターの AWS Trainium と AWS Inferentia を用意しており、これらを用いることで高性能で低コストな生成 AI 環境を作れます。 Databricks の事例では、AWS Trainium を使用して Mosaic MPT モデルのトレーニングを行い、高性能かつ低コストでスケーラブルな環境を実現しています。また、 Trainium2 の導入により、モデル構築の高速化と規模を拡大し、顧客が生成 AI アプリケーションの市場投入を加速させています。 4. データを差別化要因として活用する 生成 AI アプリケーションは大規模言語モデルだけで成立するわけではありません。自社で蓄えたデータを組み合わせて最適化することが必要になります。他社との差別化のために組織のデータを資産として活用します。そのためにはデータを蓄えるストレージやデータレイク、自社の様々なデータを統合するためのツールが必要です。そしてデータは資産であるため、セキュリティやガバナンスを確保することも重要です。AWS にはこれらのためのサービスが揃っています。 AWS パートナーとともに 生成 AI を活用する AWS の小売・消費財コンピテンシーパートナーは、生成 AI の実装を支援し、生産性向上、差別化された顧客体験の構築、イノベーションの加速を促進します。これらのパートナーは、製品開発、製造、サプライチェーン、ユニファイドコマースなど、多様な分野で AI を活用したビジネス価値創出を支援します。 効果的な導入のために、重要なユースケースの優先的な取り組み、ビジネスチームとテクノロジーチームの連携、AWS ワークショップの活用、PoC の実施、開発者のトレーニングが推奨されます。既に PoC を開始している場合は、ビジネス価値と ROI の測定、長期的な最適化計画、適切なインフラ導入、責任あるテクノロジー使用のためのコンプライアンスとガバナンスの確立が重要です。 まとめ 流通・小売業界、消費財業界のビジネスを成長させる方法については、 AWS にお問い合わせください。 流通・小売・消費財業界向け AWS の詳細はこちら 流通・小売・消費財業界のための生成 AI について また、AWS のパートナーは以下から探すことができます。 AWS リテールコンピテンシーパートナー を探す AWS 消費財パートナー を探す この e-book では AWS で生成 AI の導入を開始し、 変革とモダナイゼーションを加速する方法があることをご紹介しました。ぜひ、その他の e-book もご覧ください。 消費財企業が成長するための極意 スマートストアテクノロジーの力を活用する 小売業のデジタルコマースを最適化する 4 つの重要なステップ 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの松本が執筆しました。

本稿では、重複した IP アドレス範囲を持つネットワーク間接続のいくつかの方法を紹介していますが、第一に VPC の IP アドレス範囲は、通信するネットワークと重複しないように慎重に設計することが重要です。 お客様のネットワークにて、IP アドレス範囲が重複したリソース同士が通信する必要のある状況がよく見られます。これは、企業が買収された際、同じプライベート (RFC1918) アドレス範囲を使用している場合によく発生します。しかし、固有の IP アドレス範囲を持つサービスプロバイダーが、同じ IP アドレス範囲を持つ2つの異なるコンシューマーにアクセスを提供する際に発生する可能性もあります。 ネットワークの重複は意図せず発生することもあります。 Amazon SageMaker や AWS Cloud9 などの一部の AWS サービスでは、特定の IP アドレス範囲が自動的に予約されます。さらに、Docker などの一部のサードパーティ製品でも同様のことが行われます。定義済みの IP アドレスとの重複を避けるため、VPC を構築する際は、サービスやアプリケーションのドキュメントを必ず確認してください。 本稿では、IPv4 ベースのネットワークが抱える上記の障害に対するソリューションをいくつか説明します。アドレス空間のサイズを考えると、IPv6 を使用しているお客様にはこの問題は発生しないと予想されます。 アプリケーション間の通信方法によって、選択するソリューションが異なることに注意してください。アプリケーション間で完全な双方向接続が必要な場合があります (つまり、ネットワークセッションがどちら側からでも確立できる状態) 。また、「アウトバウンド」接続だけが必要な場合もあります。これは、一方のネットワークから他方のネットワークへのセッションは確立できるが、その逆はできない場合です。これらのパターンは、重複する IP アドレス範囲に対処するためのネットワークの設計方法に影響します。 Option 1: IP ネットワークのリナンバリング これは常にお客様へ最初に提案することです。上記のサービスプロバイダーのシナリオでは機能しません。ただし、ネットワークのリナンバリングを行う機会があれば、それが最善の選択肢です。ネットワーク構成の変更は簡単ではありませんが、次のような長期的な苦労を避けることができます。 ネットワーク管理コストの増加：以下に示す他ソリューションのほとんどは、有料のアプライアンスまたはサービスが必要です。ネットワークのリナンバリングは無料ではありません (結局、時間と人件費が発生します)。しかし長期的に見れば、重複するネットワークを相互に接続するために必要なコンポーネントを運用するための継続的なコストを削減できます。 複雑さの増大：一般的に、IP アドレス範囲の重複する2つ以上のネットワークを接続することは困難です！長期的に見れば、アプリケーション環境が拡大・変化したり、ネットワークが追加されるほど、ますます複雑になる可能性があります。 複雑なトラブルシューティング：問題が発生したとき、何が起きているのか、どこで起きているのか、そして対処するために何をすべきかを理解するのは、重複した IP アドレスに対処する必要がなくても十分複雑です。これら全てが混乱を招き、トラブルシューティングに通常よりもはるかに長い時間がかかる可能性があります。 互換性の問題：以下のソリューションはすべて、何らかの方法でネットワークアドレス変換 (NAT) を利用しています。一部のアプリケーションは、NAT では動作せず、他のアプリケーションでも使用方法に制限が生じる可能性があります。現在、 NAT で動作しないアプリケーションをお持ちでない場合でも、将来的にそのようなアプリケーションが環境にデプロイされる可能性があります。ネットワークのリナンバリングを実行すると、この問題を完全に回避できます。 NAT を利用すると管理オーバーヘッドも増えます：アプリケーションは重複する IP アドレスを使用するため、アプリケーションが使用する元の IP アドレスと NAT された IP アドレスを追跡し更新する際に、ファイアウォールルールが複雑になります。 一般に、長期的に見てより安価で容易になるため、重複するネットワークは可能な限り、リナンバリングすることを強く推奨します。 Option 2: AWS PrivateLink 2017年、AWS は PrivateLink の提供を開始しました。これは、IP アドレス範囲が重複している場合も含め、VPC 間で API またはアプリケーションのエンドポイントを簡単に公開できる HyperPlane ベースのサービスです。また、複数のコンシューマーに接続性を提供する必要があり、リモート IP アドレス範囲を制御できないサービスプロバイダーにも理想的です。さらに、IP アドレスが重複する複雑なネットワークを持つお客様にも同じメリットがあります。これは、基礎的なネットワークアドレススキームに変更を加える必要がないため、ここで示した中で最もシンプルな方法です。 下の図では、“Provider” VPC 内にあるアプリケーションを見ることができます。このアプリケーションには Network Load Balancer (NLB) が接続されており、PrivateLink を使用することで複数の “Consumer” VPC と NLB を共有することができます。下の図では、全 Consumer VPC、Provider VPC で IP アドレス範囲が重複しています。これは最悪のシナリオです。 各 Consumer VPC では、PrivateLink エンドポイントがローカル IP アドレスを持つ Elastic Network Interface として表示されます。Provider VPC では、Consumer VPC からの接続は、Provider VPC 内のローカル IP アドレスから来たように見えます。基盤となる HyperPlane サービスは、PrivateLink を機能させるために両側で NAT 操作を実行しています。 他にも次のようなセキュリティ上の利点があります。 PrivateLink の接続を確立する際、プロバイダーは Consumer VPC の所有者にリクエストを送信する必要があります。次に、所有者が承認する必要があります。これは VPC ピアリングの仕組みと同じです。プロバイダーは、承認なしにコンシューマー向けの PrivateLink を作成することはできません。 コンシューマーとプロバイダー間で許可されるのは、設定済みの TCP ポートのみです。これにより、コンシューマーは Provider VPC 内の特定のリソースにのみアクセスでき、それ以外にはアクセスできないことが保証されます。 Provider VPC 内のアプリケーションが Consumer VPC への接続を確立する方法はありません。 最後に、スケーラビリティのメリットがあります。プロバイダーはアプリケーションを数百の ConsumerVPC に公開できます。 PrivateLink には、NLB の形で冗長性が組み込まれています。これにより、バックエンドサーバーおよび Consumer VPC の構成にトラフィックが配信されます。さらに、PrivateLink エンドポイントを配置するサブネットも選択できます。下の図では、複数のアベイラビリティーゾーンにまたがるマルチサブネット環境を示しています。 お客様からよくある質問の 1 つとして、オンプレミスネットワークでこのような接続を実現する方法です。下の図では、複数の独立したカスタマーに接続された Provider VPC があり、各カスタマーは VPN 経由で AWS に接続されています。Provider VPC や全カスタマーの IP アドレス範囲が重複していることに注意してください。唯一の課題は、VPN サービスがアタッチされる VPC に割り当てられる IP アドレス範囲が、オンプレミスと重複しない IP アドレス範囲を見つけることです。この例では、オンプレミスのクライアントは VPN VPC 内の PrivateLink エンドポイントに割り当てられた IP アドレスに接続します。 このソリューションは、図のCustomer C が示す通り AWS Direct Connect でも機能します。Customer C も VPN VPC で異なる IP アドレス範囲を持っています。これは 172.16.0.0/16 が既に使用されているため、VPN VPC では異なる IP アドレス範囲を使用する必要があるためと考えられます。これは問題ではありません。VPN VPC の IP アドレス範囲は、Customer C が使用するネットワークとの重複を排除する必要があるだけなため、選択できる範囲は非常に広いです。 このオプションの設定は、追加メンテナンスが不要で、冗長性が高く、拡張性も高いため、簡単です。さらに、顧客ネットワーク間を分離できます。サービスプロバイダー環境でアプリケーションを作成する場合は、PrivateLink がネットワーク柔軟性を提供できるようにソリューションを設計することを検討してください。 価格ページ 通り、PrivateLink にはコストがかかることに注意してください。アプリケーションは単一の TCP ポートとして提供される必要があるため、アプリケーションによってはこのソリューションでは動作しない場合があります。アプリケーションが UDP を使用する場合、または複数の TCP ポートを持ち、クライアントがバックエンドサーバーのアフィニティを維持する必要がある場合、PrivateLink は適していません。 Option 3: VPCで複数 IP アドレス範囲を利用 アプリケーションが異なる層に分かれている場合があります。ユーザーや他のアプリケーションからのリクエストに応答するフロントエンドやミドルウェア、データベース、キャッシュ等で構成される1つ以上の “バックエンド” 層です。この環境では、フロントエンドのサブネットに重複しない IP アドレスを持たせる一方で、バックエンドのサブネットは他のアプリケーションと重複させることができます。 以下の図は、3つのアプリケーション VPC が AWS Transit Gateway に接続する様子を示しています。VPC の IP アドレス範囲は重複していますが、IP アドレス範囲の異なるフロントエンドサブネットが Transit Gateway にアドバタイズされているため、エンドユーザーはそれぞれにアクセスできることに注意してください。この場合、各 VPC の全てのサブネットをアドバタイズすべきではないため、Transit Gateway への自動ルート伝播を無効にする必要があります。 この環境では、IP アドレス範囲が重複する各 VPC (図では 10.0.0.0/22) を作成し、その後、各 VPC に重複しない2つ目の IP アドレス範囲を追加します。フロントエンドサブネットでは、Transit Gateway をターゲットとする他のフロントエンドサブネットへのルートを追加できます (またはデフォルトルートを使用できます)。 これは、バックエンドサブネットにあるサーバーをどのように管理するかという課題を解決するものではありません。実現する方法は、各 VPC のフロントエンドサブネットに踏み台ホストを配置することです。これにより、管理者は SSH または RDP を使用して踏み台ホストを経由して、バックエンドサブネットにアクセスできるようになります。また、 AWS Systems Manager を使用して、ホスト上でコマンドをリモート実行したり、バックエンドホストへの SSH トンネルを作成することもできます。 バックエンドサーバーでは、リポジトリからのコードのダウンロードや適切なサーバーからの更新、アプリケーションログの送信、パフォーマンスメトリクスの提供などが引き続き必要となります。このために、AWS サービス ( Amazon CloudWatch や Amazon Simple Storage Service (Amazon S3) など) のプライベートエンドポイントと組み合わせて使用することができます。サーバーが AWS 以外のエンドポイントへのアウトバウンドアクセスを必要とする場合は、フロントエンドサブネットでホストされている NAT またはプロキシサービスが必要となります。 このオプションは、重複するネットワークの一部だけをリナンバリングする必要がある場合、(フロントエンドのサブネットのみを変更することで) 作業を減らしつつ、(複雑なNATソリューションを実行せずにアプリケーションとユーザーが通信できるため) リスクの大部分を低減できることを意味します。ただし、追加コストがかかります。踏み台ホスト、NAT またはプロキシインスタンス、AWS サービス用プライベートエンドポイントなどです。また、管理コストをできるだけ低く抑えるために、このインフラストラクチャを自動化して展開および管理することを強く推奨します。 この図では、Web サーバー (または他アプリケーションのフロントエンドコンポーネント) はフロントエンドサブネットに配置されていますが、そのサブネットにロードバランサーを配置し、 Amazon Elastic Compute Cloud (Amazon EC2) コンポーネントを到達不可能な IP アドレス範囲を使用して別のサブネットに保持することもできます。 このオプションでは、他アプリケーションとの重複を心配することなく、数千の IP アドレスを持つバックエンドワークロードのサブネットをデプロイできます。さらに、フロントエンドサブネットには必要最小限の IP アドレスのみを使用して、(VPC の) 外部ネットワークからアプリケーションへのアクセスを確保できます。 最後に、バックエンドサブネットには IPv4 の代わりに IPv6 の使用を検討してください。このシナリオで IPv4 を使用する場合、(上記で説明した方法を除いて) バックエンドサブネットには到達できません。IPv6 を使用することで、サブネットをオーバーラップする必要がなくなり、IPv6 に移行すると回避策なしにサブネット内のリソースに到達できるようになります。 Option 4: Private NAT Gateway を使用してサブネットを隠蔽する 2021年、Private NAT Gateway の提供を開始しました 。 NAT Gateway が VPC ネットワーク全体をインターネットから “隠す” (単一の Elastic IP アドレスから来たように見せる) のと同じように、Private NAT Gateway も VPC から他のプライベートネットワークに接続する際にそれを可能にします。Elastic IP アドレスと Internet Gateway の代わりに、Private NAT Gateway はVPC 内で割り当てられたプライベート IP アドレスを、VPC が “隠れる “ ためのアドレスとして使用します。 これは、VPC からオンプレミスネットワークや他 VPC に接続したいが、VPC 内のリソースには直接接続したくない環境で役立ちます。オプション3 と非常に似ていますが、VPC からの外部接続を提供するために NAT やプロキシインスタンスを実行する必要がない点が異なります。 次の図は、Private NAT Gateway の動作を示しています： VPC の IP アドレス範囲は10.0.0.0/16ですが、その IP アドレス範囲外の2つのサブネット (10.31.10.0/24と10.31.11.0/24) が追加されていることに注意してください。各アベイラビリティーゾーンに Private NAT Gateway が追加されています (Internet-facing NAT Gateway と同様に1つで十分ですが、冗長性のため2つを推奨します)。これらは、セカンダリ IP アドレス範囲のサブネットに追加されています。NAT Gateway は、サブネットの IP アドレスを使用して、バックエンドサブネットからのワークロードの IP アドレスを変換します。 Transit Gateway 内で、フロントエンドサブネットへのルートを追加することで、戻りのトラフィックを Private NAT Gateway に送ることができます。VPC 内では、バックエンドサブネットからのトラフィックは、Internet-facing NAT Gateway のルートテーブルとほぼ同じ方法で Private NAT Gateway にルーティングされます。 この場合、バックエンドサブネットのインスタンス管理は、フロントエンドサブネットの SSM または踏み台ホストを使用して行う必要があります。アプリケーションのデプロイが自動化されていれば、これらのホストを人間が管理する必要はありません。これは望ましい結果です。 前のオプション同様に、IP アドレスを節約しつつ、ワークロードの関連性の高い重要な部分にルーティング可能で利用できる状態を維持する優れた方法です。このタイプの環境を作成する方法の詳細な手順は、 こちらの投稿 で見つけることができます。 Private NAT Gateway の使用には、 料金ページ に示されているように料金が発生することにご注意ください。 まとめ この投稿では、重複する IP ネットワークに対処するいくつかの方法を紹介しました。以下の表は、それぞれのオプションの比較を示しています。 オプション サービスコスト 冗長性 完全なネットワーク到達性 ソリューションの複雑さ メンテナンスの複雑さ 最適な対象 1: リナンバリング 低 N/A はい 低 低 全ての方におすすめ 2: PrivateLink 中 はい いいえ 低 低 サービスプロバイダー 3: VPCで複数 IP アドレス範囲を利用 中 はい いいえ 中 中 コンテナ / 大きなワークロード 4: Private NAT Gateway 中 可能 いいえ 中 中 コンテナ / 大きなワークロード 重複するネットワークをリナンバリングすることが、長期的には (コストや複雑さ、可視性の面で) 最も良い選択肢であることを覚えておいてください。PrivateLinkは、接続先のネットワークを制御できないサービスやアプリケーションプロバイダーに対処することに特化して設計されています。 本稿は、2022年6月16日に Networking & Content Delivery で公開された “ Connecting Networks with Overlapping IP Ranges ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

Amazon Quantum Ledger Database(Amazon QLDB) は、2025 年 7 月 31 日にサポートが終了することがアナウンスされています。本ブログでは、Amazon QLDB のサポート終了に伴う移行先のソリューションについてご紹介します。 Amazon QLDB のサポート終了 Amazon QLDB は、フルマネージド型の台帳データベースサービスです。Amazon QLDB は、2025 年 7 月 31 日にサポートが終了することがアナウンスされています。今回の Amazon QLDB のサポート終了のアナウンスに伴い、AWS では Amazon Aurora PostgreSQL への移行に関する ２ つのブログを公開しています。 ・ Amazon QLDB の Amazon Aurora PostgreSQL への移行 ・ 監査のユースケースで Amazon QLDB を Amazon Aurora PostgreSQL に置き換える また、Amazon QLDB の移行先候補としては、AWS のパートナーのソリューションもあります。ここでは、Amazon QLDB の移行先として株式会社 Scalar のソリューションであります ScalarDL をご紹介します。 株式会社 Scalar について 株式会社 Scalar は「データマネジメントの未来を創る」というビジョンのもとに、データの完全性・真正性を保証する ScalarDL や、データベースの仮想化を実現する ScalarDB などの製品を開発している会社です。 Amazon QLDB と ScalarDL Amazon QLDB は、追記型で不変なデータの変更履歴を提供します。この変更履歴は暗号学的な方法で保護されており、単にそれらを表示するだけでなく、各変更の完全性をさかのぼって検証することができます。 一方、ScalarDL も同様に追記型であり、暗号学的な方法に基づく不変なデータの変更履歴とその完全性検証機能を提供します。 ScalarDL は、データベースにおける改ざんなどの任意の故障(ビザンチン故障)の検知を実現するデータベースミドルウエアです。AWS Marketplace でも提供されており、Amazon DynamoDB や Amazon Aurora などと組み合わせて利用することができます。 Marketplace： ScalarDL Ledger Marketplace： ScalarDL Auditor 以降では、Amazon QLDB と ScalarDL の違いについて具体的に触れていきたいと思います。 Amazon QLDB と ScalarDL の違い Amazon QLDB と ScalarDL はどちらもデータの変更履歴機能と完全性検証機能を提供する点で共通していますが、そのデータモデルやアクセスインタフェース等いくつかの違いがあります。 データ操作 Amazon QLDB は、PartiQL と呼ばれる問合せ言語を用いて台帳のデータを追加・更新したり、参照したりすることができます。PartiQLはSQL互換な問合せ言語で、SELECT、INSERT、UPDATE といったステートメントで台帳にアクセスすることが可能です。 一方、ScalarDL では、「コントラクト」と呼ばれるビジネスロジックを記述した小さなプログラムを介して台帳にアクセスします。具体的には、コントラクトは Java 言語で記述することができ、get()、scan()、put() といったインタフェースを提供しているため、これらを用いて PartiQL の SELECT、INSERT、UPDATE ステートメントによる操作を置き換えることができます。 データモデル Amazon QLDB と ScalarDL では異なるデータモデルを採用しているため、移行に際してはいくつかの注意が必要です。Amazon QLDB はテーブルやインデックスといったリレーショナルデータベースに似たデータモデルを採用する一方、ScalarDL は高いスケーラビリティを実現するため、Key-Value 型に似たフラットでシンプルなデータモデルを採用しています。具体的に ScalarDL の台帳は、文字列型のID (アプリケーションが利用する主キー) で特定可能なレコードの集合として表現されます。そのため、ScalarDL ではテーブルを明示的に作るかわりに、ID にテーブルを識別するプレフィックスを含めることで仮想的にテーブル相当の機能を実現します。また、インデックスが必要な場合には、このデータモデル上でインデックスキーとレコードのマッピングを作成します。 なお、ScalarDL への移行をより容易にするため、株式会社 Scalar からテーブルやインデックスの作成および PartiQL の各種ステートメントに相当する事前定義済みのコントラクトの提供が 予定されています。 履歴表示処理 Amazon QLDB は、テーブル内のレコードの過去のバージョンにアクセスするため、history() 関数を提供しています。history() 関数を使用すると、時間の経過とともにデータレコードがどのように変化したかを確認できます。 ScalarDL では、コントラクトにおいて scan() インタフェースを使用することで、任意の範囲の過去のレコードバージョンを取得・表示することができます。 レコードの完全性 Amazon QLDB では、ダイジェストと呼ばれる暗号学的ハッシュを用いて台帳内のレコードの完全性を検証することができます。具体的には、ある時点における台帳のサマリーであるダイジェストを信頼できる第三者が保管しておき、そのダイジェストとレコードのバージョンを指定して検証を行います。レコードのバージョンのハッシュ値とマークルツリーと呼ばれる木構造で管理されたハッシュ値を用いてダイジェストを再計算することで、当該レコードバージョンの完全性を確認できます。 ScalarDL でもAmazon QLDB におけるダイジェストと似たように、暗号学的ハッシュを用いてレコードの完全性を検証できます。ScalarDL では、過去のレコードバージョンがハッシュチェーンでつながれています。そのため、過去の更新履歴をさかのぼって各レコードバージョンの内容を再計算し、正しくハッシュチェーンが構成されているかを検証することで、レコードの完全性を確認できます。この検証は、validate-ledger と呼ばれる CLI や API を使用して行います。また、ScalarDL では、コントラクトの実行や validate-ledger の実行の結果として、レコードのハッシュ値等を含んだ「プルーフ」を取得することができます。このプルーフを信頼できる第三者が保管しておくことで、検証の信頼性を高めることができます。さらに、Auditor と呼ばれるコンポーネントを追加で利用すれば、例えば、台帳を管理するプログラム自体の改ざんも含め、任意の故障(ビザンチン故障)を検知できるようになります。 更新イベントのフィード Amazon QLDB streams は、台帳で発生したすべてのデータ更新イベントをニアリアルタイムで Amazon Kinesis Data Streams にフィードします。フィードされたストリームデータは、台帳における重要なデータの更新状況の分析や疑わしいアクティビティの検出などに活用できます。 ScalarDL では、上記に似た分析プラットフォームを実現するために、台帳で読み書きされたデータを HTAP (ハイブリッド型トランザクション／アナリティクス処理) エンジンである ScalarDB へフィードできる「ファンクション」という機能を提供しています。ファンクションは、コントラクトと同様に Java 言語のプログラムであり、分析処理向けのデータ変換ロジックなども記述することができます。フィードされたデータは、ScalarDB を利用して、用途に合った様々な分析を行うことが可能です。 まとめ 以上、ScalarDL のご紹介と Amazon QLDB との違いについてご説明しました。Amazon QLDB からの移行先として ScalarDL について詳しく知りたい場合は、ScalarDL のドキュメンテーションサイトをご参照ください。 ・ ScalarDL Technical Overview ・ ScalarDL の実装 (製品ドキュメンテーション) また、Amazon QLDB からScalarDL への移行については、アプリケーションやデータの移行含め株式会社 Scalar にてサポート頂けますので、ScalarDL への移行を検討したい場合は、株式会社 Scalar か AWS の担当までお気軽にお問い合わせください。 問い合わせ先： qldb-migration@scalar-labs.com 本ブログ執筆にあたり、株式会社 Scalar の山田様、根本様にご協力頂きました。お二方、ありがとうございました。 著者について 山田 浩之 は、株式会社 Scalar の CTO 兼 co-CEO として、ScalarDL および ScalarDB の研究開発を指揮しています。 根本 潤 は、株式会社 Scalar の Principal Researcher として、ScalarDL および ScalarDB の研究開発を行っています。 内山 義夫は、AWS のシニアデータベーススペシャリストとして、データベースのクラウド化における技術的な課題解決を支援しています。  

(本記事は 2024/05/14に投稿された Continuously replicate Amazon DynamoDB changes to Amazon Aurora PostgreSQL using AWS Lambda を翻訳した記事です。) Amazon DynamoDB は、あらゆる規模で高性能アプリケーションを実行できるように設計された、フルマネージド型のサーバーレスなキーバリュー NoSQL データベースです。 Amazon Aurora は、クラウド向けに構築された MySQL および PostgreSQL と互換性のあるリレーショナルデータベースです。Aurora は、従来のエンタープライズデータベースのパフォーマンスと可用性と、オープンソースデータベースのシンプルさとコスト効率を兼ね備えています。サーバーレステクノロジーにより、キャパシティのプロビジョニングやパッチ適用などのインフラストラクチャ管理のタスクが不要になり、アプリケーションスタック全体の俊敏性を向上させます。 この投稿では、 Amazon DynamoDB Streams と AWS Lambda を使用して DynamoDB から Amazon Aurora PostgreSQL 互換エディション にデータをレプリケートすることで、大規模なリアルタイムのデータ変更を処理するソリューションを紹介します。 ユースケース 私たちのこのユースケースでは、お客様はオンプレミス環境でレガシーレポートアプリケーション、ビジネスインテリジェンス（BI）ツール、データウェアハウスを実行していました。長期計画として、データウェアハウスを Amazon Redshift にモダナイズしたいと考えていました。一方、ダウンストリームのレガシーレポート環境をサポートするために、DynamoDB から Amazon Aurora PostgreSQL 互換エディションにデータをレプリケートし、ユーザーがワンタイムクエリや集計クエリを実行できるようにしました。DynamoDB から Amazon Aurora PostgreSQL にデータをレプリケートするのは一般的なパターンではありませんが、お客様はデータを Amazon Aurora PostgreSQL に持ち込むことを希望しました。これにより、一時的に既存のレガシーアプリケーションを実行し続けることができ、同時に Amazon Redshift への移行を開始することができました。 ソリューション概要 DynamoDB では、パーティションキーと、オプションでソートキーを定義するだけでデータを操作できます。一方、Amazon Aurora などのリレーショナルデータベースでは、扱う属性ごとにテーブルスキーマを定義する必要があります。DynamoDB テーブルから変更をレプリケートするには、 DynamoDB Streams を使用して、アイテムレベルの変更を時系列でキャプチャし、この情報を最大 24 時間ログに保存します。レプリケーションは DynamoDB Streams が有効になってから開始されます。つまり、DynamoDB テーブルに既存のデータがあり、それを Aurora にレプリケートする必要がある場合は、 DynamoDB データを Amazon S3 にエクスポート するか、 AWS Data Pipeline を使用して DynamoDB データをエクスポートおよびインポート したりするなど、1 回限りのロードで対処する必要があります。DynamoDB はスキーマレスであるため、レプリケーションが中断されないように、DynamoDB に新しい属性を追加する場合は、リレーショナルデータベースの構造を最新の状態に保つ必要があります。Aurora は 1 秒あたり数十万件のトランザクション（TPS）を処理できますが、DynamoDB が受信する TPS がそれを超えると、Aurora でレイテンシーが発生する可能性があります。ソリューションを実装する前に、TPS の要件を理解し、レイテンシーの SLA に整合させることが重要です。 お客様と作業を進める中で、 Amazon Data Firehose を使用して DynamoDB から Aurora にデータをストリーミング するオプションについても話し合いました。しかし、お客様は、追加コストなしですぐに使用できるソリューションであり、24 時間以内のデータ保持に関するお客様のサービスレベルアグリーメント（SLA）を満たしていることから、DynamoDB Streams の利用を希望しました。 次の図は、ソリューションのアーキテクチャとワークフローを示しています。 データベース間のデータレプリケーションを有効にするには、次の手順を実行します。 DynamoDB テーブルを作成します。 DynamoDB から SQL へのテーブルマッピングを構成します。 DynamoDB テーブルの DynamoDB Streams を有効にします。 Powertools for AWS Lambda を使用して Amazon CloudWatch Logs および AWS Secrets Manager パラメータ用の Lambda 関数を作成します。 DynamoDB Streams の Lambda トリガーを設定します。 DynamoDB の変更を Amazon RDS で検証します。 前提条件 この記事を読むには、次の前提条件が必要です。 AWS コマンドラインインターフェイス （AWS CLI）のインストールと設定 AWS アカウント と AWS アカウントのリソースを操作するための適切な権限 AWS 上の仮想プライベートクラウド（VPC） データがレプリケートされる Aurora Serverless v2 DynamoDB から SQL へのテーブルマッピングの構成 次の表は、DynamoDB テーブルと SQL データベース間のマッピングを示しています。このユースケースでは、1 つの DynamoDB テーブルを 1 つの Aurora PostgreSQL テーブルにマッピングしています。 DynamoDB Table (Employees) SQL Table (Employees) Id (PrimaryKey), Type: Number Id (PrimaryKey), Type: Number empName, Type: String Name, Typre: Varchar(20) empDepartment, Type: String Department, Type: Varchar(10) 両方のテーブルの Id を主キーとして使用します。 DynamoDB SQL INSERT INSERT MODIFY UPDATE REMOVE DELETE DynamoDB テーブルの作成 次の AWS CLI コマンドは、 パーティションキー Id を数値として指定した Employees という名前の DynamoDB テーブルを作成しています。 aws dynamodb create-table \ --table-name Employees \ --attribute-definitions \ AttributeName=Id,AttributeType=N \ --key-schema \ AttributeName=Id,KeyType=HASH \ --provisioned-throughput \ ReadCapacityUnits=5,WriteCapacityUnits=5 \ --table-class STANDARD このテーブルは、5 つの読み取りキャパシティーユニット（RCU）と 5 つの書き込みキャパシティーユニット（WCU）でプロビジョニングされたスループットで構成されています。プロビジョニングされたキャパシティ料金の詳細については、 プロビジョニングされたキャパシティの料金 を参照してください。 DynamoDB テーブルで DynamoDB Streamsの有効化 DynamoDB Streams を有効 にするには、次の手順を実行します。 DynamoDB コンソールで、作成したテーブルに移動し、 エクスポートおよびストリーム タブを選択します。 DynamoDB ストリームの詳細 について、 オンにする を選択します。 DynamoDB Streams を有効にすると、DynamoDB テーブルのすべてのデータ操作言語（DML）アクションがストリーム内の項目としてキャプチャされます。 表示タイプ では新しく更新された値をキャプチャするために 新しいイメージ を選択し、新しい値を使って宛先を置き換えます。 ストリームをオンにする を選択します。 同様のことは CLI でも実行できます。次のコマンドは、新しいイメージの表示タイプを使用して Employees テーブルでのストリーミングを有効にします。 aws dynamodb update-table \ --table-name Employees \ --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE CloudWatch Logs と Secrets Manager パラメータ用の Lambda 関数を作成 このユースケースでは、SQL Replicator と呼ばれる Lambda 関数を使用します。この関数は、DynamoDB テーブルでデータが変更されたときに DynamoDB Streams によって呼び出されます。この関数は Aurora PostgreSQL Serverless への変更をレプリケートし、そのログは Powertools for Lambda を使用して CloudWatch Logs にキャプチャされます。Lambda のコードは Python で記述されています。PostgreSQL の接続には Psycopg データベースアダプターを使用し、logger と シークレットストア には Powertools for Lambda (Python) を使用します。 Lambda ロールポリシー Lambda ロールは、次の AWS 管理ポリシー を使用して構築されています。 AWSLambdaInvocation-DynamoDB — DynamoDB Streams への読み取りアクセスを提供します。 AWSLambdaBasicExecutionRole — CloudWatch Logs への書き込み権限を提供します。 awsLambdaVPCAccessExecutionRole — VPC 内のリソースにアクセスしながら Lambda 関数を実行する最小限の権限を提供します。ネットワークインターフェースの作成、表示、削除および CloudWatch Logs への書き込み権限が含まれます。 SecretsManagerReadWrite — AWS マネジメントコンソール 経由で Secrets Manager への読み取り/書き込みアクセスを提供します。 Secrets Manager で 送信先の RDS データベースシークレットを作成 し、Lambda 関数から使用することができます。統合については、 Improve security of Amazon RDS master database credentials using AWS Secrets Manager を参照してください。 次の Python コードは、DynamoDB から PostgreSQL にデータを同期する Lambda 関数用です。これには以下のアクションが含まれています。 json 、 psycopg2 、 aws_lambda_powertools などの必要なライブラリをインポートします。 ログを記録するために、 aws_lambda_powertools から logger を初期化します。 Secrets Manager から RDS データベースの認証情報を取得します。 psycopg2 を使用して PostgreSQL データベースに接続します。 DynamoDB イベントの各レコードについて、イベントタイプ（INSERT、 MODIFY、REMOVE）に基づいて PostgreSQL で CRUD 操作を実行します。 psycopg2 cursor を使用して SQL クエリを実行し、PostgreSQL データベース内のレコードを insert、update、deleteします。 各ステップで logger を使用して関連情報を記録します。 PostgreSQL からレコードを選択して同期されたデータを検証します。 最後にトランザクションをコミットします。 # Library imports import json import psycopg2 from aws_lambda_powertools import Logger from aws_lambda_powertools.utilities import parameters #Initialize Powertools Logger logger = Logger() #instruct Logger to log the incoming event @logger.inject_lambda_context(log_event=True) #Lambda Handler def lambda_handler(event, context): try: # Retrieve the secret value from AWS Secrets Manager secret_value = json.loads(parameters.get_secret(name="dev/rds")) #DB Connect mydb = psycopg2.connect( user=secret_value["username"], password=secret_value["password"], host=secret_value["host"], dbname=secret_value["engine"], port= secret_value["port"] ) mycursor = mydb.cursor() # For every record in the event for record in event["Records"]: event_name = record["eventName"] #based on the record event if event_name == "INSERT": logger.info("Inserting record", extra = { "record": record}) sql_script = "INSERT INTO public.\"Employees\" VALUES (%s,%s,%s)" sql_value = ( int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S","NA"), record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S","NA"), ) mycursor.execute(sql_script,sql_value) logger.info("Record inserted successfully into Employees table") elif event_name == "MODIFY": logger.info("Modifying record", extra = { "record": record}) sql_script = "UPDATE public.\"Employees\" SET \"Name\" = %s, \"Department\" = %s WHERE \"Id\" = %s" sql_value = ( record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S", record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S","NA")), record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S", record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S","NA")), int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), ) mycursor.execute(sql_script,sql_value) logger.info("Record modified successfully into Employees table") elif event_name == "REMOVE": logger.info("Removing record", extra = { "record": record}) sql_script = "DELETE FROM public.\"Employees\" WHERE \"Id\" = %s" sql_value = ( int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), ) mycursor.execute(sql_script,sql_value) logger.info("Record removed successfully from Employees table") #Verifying with the select the select statement mycursor.execute('SELECT * FROM public."Employees"') records = mycursor.fetchall() mycursor.close() mydb.commit() logger.info("Received event: ", extra = { "records": records}) except (Exception, psycopg2.Error) as error: logger.exception("Error while fetching data from PostgreSQL", extra= {"error": error}) 関数コードの「dev/rds」を、Lambda がデータベース認証に利用するシークレットの名前に置き換えます。RDS データベースのシークレットの作成については、 AWS Secrets Manager データベースシークレットの作成する を参照してください。 Secrets Manager のシークレットの値 参照用のシークレットの値は次のとおりです。 {"username":"admin","password":"xxxxxx","engine":"postgres","host":"database.cluster-abcdefghjklmn.us-east-1.rds.amazonaws.com","port":5432,"dbClusterIdentifier":"database-3"} Amazon Aurora は VPC にデプロイされているため、Lambda を同じ VPC にアタッチしました。Lambda と Amazon Aurora の両方にセキュリティグループルールを設定して、両者の接続を許可しています。詳細については、 Lambda 関数を使用して Amazon RDS データベースにアクセスする を参照してください。追加のヘルプについては、 Amazon RDS のトラブルシューティング を参照することもできます。 DynamoDB Streams の Lambda トリガーを設定 Lambda トリガーを使用すると、DynamoDB テーブルのデータ変更に対応するアプリケーションを構築することができます。DynamoDB と Lambda の統合の詳細については、 DynamoDB Streams と AWS Lambda のトリガー を参照してください。 トリガーは Lambda 関数を実行し、エラーが返された場合には、正常に処理されるか、データの有効期限が切れになるまでバッチを再試行します。より小さなバッチで再試行したり、再試行回数を制限したり、その他のオプションを Lambda 関数に設定したりすることもできます。バッチ処理の詳細については、 ポーリングストリームとバッチストリーム を参照してください。 Lambda トリガーは、DynamoDB の DML ボリュームに基づいてバッチサイズが 100 に設定されています。 Amazon RDS で DynamoDB の変更を検証する DynamoDB Streams と Lambda 関数をセットアップしたら、データ配信を検証することができます。AWS CLI またはコンソールを使用して DynamoDB の insert、update、delete を実行できます。この記事では、AWS CLI のサンプルコードを提供します。PostgreSQL クライアントを使用して接続し（この記事では pgAdmin を使用）、データを検証できます。 Insert AWS CLI で次のコードを使用して insert を実行します。 aws dynamodb put-item \ --table-name Employees --item "{\"Id\": {\"N\": \"2001\"},\"empDepartment\": {\"S\": \"AnyDept\"},\"empName\": {\"S\": \"Akua\"}}" Update AWS CLI で次のコードを使用して update を実行します。 aws dynamodb update-item --table-name Employees \ --key "{\"Id\": {\"N\": \"2001\"}}" \ --update-expression "SET empDepartment = :newval" \ --expression-attribute-values "{\":newval\": {\"S\": \"ExDept\"}}" 次のスクリーンショットは、テーブル内の update された値を示しています。 Delete AWS CLI で次のコードを使用して delete を実行します。 aws dynamodb delete-item --table-name Employees --key "{\"Id\": {\"N\": \"2001\"}}" 次のスクリーンショットは、レコードが delete されたことを示しています。 クリーンアップ Lambda 関数を削除します。 DynamoDB テーブルを削除します。 Aurora PostgreSQL Serverless データベースを削除します。 まとめ この記事では、Lambda を使用して DynamoDB の変更を Aurora に継続的にレプリケートするイベント駆動型ソリューションを構築しました。このソリューションは、ダウンストリームのレガシーレポートワークロードをサポートすることでお客様の問題を解決し、1 回限りのクエリと集計クエリを実行できるようにしました。 このソリューションを試してみて、コメントや質問がある場合はコメント欄に残してください。 著者について Aravind Hariharaputran は、Amazon Web Services のプロフェッショナルサービスチームのデータベースコンサルタントです。彼は Microsoft SQL Server を専門とするデータベース全般に情熱を注いでいます。お客様がオンプレミスのデータベースワークロードを AWS クラウドに移行して最適化するのを支援する技術ソリューションの構築を支援しています。家族と過ごしたり、クリケットをしたりすることを楽しんでいます Sakthivel Chellapparimanam は、Amazon Web Services の AWS プロフェッショナルサービスのクラウドアプリケーションアーキテクトです。お客様のクラウドアプリケーションの構築とクラウドへのアプリケーションの移行を支援しています。

(本記事は 2024/05/03に投稿された Introducing configurable maximum throughput for Amazon DynamoDB on-demand を翻訳した記事です。) Amazon DynamoDB はあらゆる規模のモダンなアプリケーションを開発できるサーバレスの NoSQL データベースサービスです。DynamoDB オンデマンドモード はキャパシティプランニングなしで毎秒数百万ものリクエストに対応し、テーブルに対してリクエストが発行されていない時には自動的にゼロへスケールダウンするため、真のサーバレスエクスペリエンスを提供します。オンデマンドモードのシンプルなリクエスト単位の料金モデルでは実際に使用したキャパシティに対してのみ料金が発生するため、アイドルキャパシティについて心配する必要がありません。データベースのワークロードを予測することが複雑な新しいアプリケーションを構築する場合や、トラフィックパターンが予測できない、変動しやすいアプリケーションを構築する場合、また、従量課金制のサーバレススタックを使用する場合に、オンデマンドモードを使用するお客様が増えています。オンデマンドモードを使用するテーブルの場合、DynamoDB は需要に合わせてお客様のワークロードの増減に応じてすぐにスケーリングし、アプリケーションがリクエストに応答できるようにします。 各オンデマンドテーブルのデフォルトのスループットレートは毎秒 40,000 回の読み取りリクエストと毎秒 40,000 回の書き込みリクエストです（ AWS サービスクォータ を利用して増やすことができます）。これはアカウント内のすべてのテーブルに一律に適用され、アカウント内のさまざまなワークロードや要件に合わせてカスタマイズしたり調整することはできません。オンデマンドモードではさまざまなトラフィックパターンに対応するために即座にスケーリングされるため、最適化されていなかったり、急いで書かれたコードによって急速なスケールアップを引き起こしリソースを消費してしまうことで、テーブルレベルの使用量やコストを抑えることが困難になる可能性があります。お客様から、コストとパフォーマンスの最適なバランスを実現するために、オンデマンドモードでの柔軟性と詳細な設定機能を求める声が頻繁に寄せられています。 本日、個々のオンデマンドテーブルと関連するグローバルセカンダリインデックス（GSI）の最大読み取りまたは書き込み（あるはその両方）スループットを設定できる新しいオプション機能をリリースします。これにより、テーブルレベルのコストとパフォーマンスのバランスをより簡単に取ることができます。指定された最大スループットを超えるオンデマンドリクエストは制限されますが、最大スループット設定はアプリケーションの要件に基づいていつでも変更できます。オンデマンドの最大スループットは、新規および既存のシングルリージョンおよびマルチリージョンのテーブル（グローバルテーブル）、インデックス、および Amazon Simple Storage Service （Amazon S3）ワークフローからのテーブルの復元時とデータのインポート時にも設定できます。 この記事では、一般的なユースケースをいくつか紹介し、オンデマンドテーブルの最大スループットを実装して組織の目標を達成する方法を説明します。また、この機能が他の DynamoDB リソースとどのように連携するかについても説明します。 一般的なユースケース このセクションではオンデマンドテーブルの最大スループットを設定する一般的なユースケースについて説明します。 オ ンデマンドスループットコストの最適化 ：オンデマンドテーブルの最大スループットの値を柔軟に設定できるため、コストの予測と管理がさらに高まり、お客様はさまざまなワークロード要件や予算に基づいて、本番環境と開発環境全体でサーバレスエクスペリエンスをより幅広く採用できるようになります。 コスト急増の防止 ：オンデマンドテーブルに最大スループットを事前に定義しておくことで、チームは最適化されていないコードや不正なプロセスから発生する可能性のある読み取りまたは書き込み量の偶発的な急増を防ぐことができます。この対策により、アプリケーション開発の初期段階や非生産的な環境であっても、コストへの影響を適切に管理することができます。 API使用量の管理 ：お客様がプロビジョニングされたキャパシティからオンデマンドモードに切り替えるシナリオでは、オンデマンドスループットの上限消費しきい値を設定することで、予期せずテーブルに対して実行できるワークロードトラフィック量にチームが不意を突かれることがないようにすることができます。これにより、組織が一定期間内でリソースを過剰に消費することを防ぎます。 ダウンストリームサービスの保護 ：お客様のアプリケーションにはサーバレスと非サーバレステクノロジーを含めることができます。サーバレスアーキテクチャの部分は需要に合わせてすぐに拡張されますが、キャパシティが固定化されたダウンストリームのコンポーネントは過負荷となる可能性があります。オンデマンドテーブルに最大スループットを設定することで、大量のイベントが複数のダウンストリームコンポーネントに伝播することによる予期しない副作用の発生することを防ぐことができます。 はじめに オンデマンドテーブルを作成すると、デフォルトでは、ワークロードに対する最大スループットの設定は有効になっていません。これは、テーブル毎、および関連するグローバルセカンダリインデックスに設定できるオプション機能です。これにより、読み取りと書き込み最大スループットを個別に設定して、特定の要件に基づいたアプローチを微調整できます。オンデマンドテーブルの最大スループットはベストエフォートで適用されるため、保証されたリクエスト上限ではなく目標として考える必要があります。 バーストキャパシティ が原因で、ワークロードが指定された最大スループットを一時的に超える可能性があります。この機能を使用するのに追加のコストはなく、 AWS コマンドラインインターフェース （AWS CLI）、 AWS マネジメントコンソール 、AWS SDK、または AWS CloudFormation を使用して開始することができます。 DynamoDB のコンソールを使用してオンデマンドテーブルの最大スループットを有効にするには、次の手順を実行します。 DynamoDB コンソールのナビゲーションペインで テーブル を選択します。 テーブルの作成 を選択します。 テーブルの名前、パーティションキー、およびソートキーを指定します。 テーブル設定 で、 設定をカスタマイズ を選択します。 読み取り/書き込みキャパシティの設定 には、 オンデマンド を選択します。 最大テーブルスループット で、読み取り、書き込み、またはその両方の制限を指定します (1 ～ 40,000 リクエストユニット)。 テーブルの作成 を選択します。 また、CLI、SDK、または AWS CloudFormation を使用して、 MaxReadRequestUnits と MaxWriteRequestUnits を含む OnDemandThroughput パラメータを使用して、テーブルまたはインデックスのオンデマンド最大スループットを設定することもできます。これらのパラメータを使用すると、 1 〜 AccountMaxTableLevelReads または AccountMaxTableLevelWrites の有効範囲内で、読み取りと書き込みの最大単位を指定できます。値を -1 に設定すると制限が無効になるため、オンデマンドテーブルのスループット制限を必要としないシナリオに柔軟に対応できます。 テーブルとインデックスの最大スループット設定を個別に構成できる柔軟性があります。さらに、特定の要件に基づいて、これらの設定を読み取り、書き込み、またはその両方に選択的に適用できます。ベストプラクティスに従って、グローバルセカンダリインデックスの最大スループット設定は関連するテーブルの最大スループット設定と一致させることをお勧めします。これは、グローバルセカンダリインデックスがテーブルに書き込まれたデータを効果的に複製できるようにするために MaxWriteRequestUnits において特に重要となります。 次の例は、CLI を使用してテーブルとインデックスのオンデマンド最大スループットを設定する方法を示しています。 aws dynamodb create-table \ --table-name MusicCollection \ --attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S AttributeName=Genre,AttributeType=S \ --key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST \ --on-demand-throughput MaxReadRequestUnits=500,MaxWriteRequestUnits=1000 \ --global-secondary-indexes \ "[ { \"IndexName\": \"My-Index\", \"KeySchema\": [ {\"AttributeName\":\"Genre\",\"KeyType\":\"HASH\"}, {\"AttributeName\":\"SongTitle\",\"KeyType\":\"RANGE\"} ], \"Projection\": { \"ProjectionType\":\"INCLUDE\", \"NonKeyAttributes\":[\"Artist\"] }, \"OnDemandThroughput\": { \"MaxReadRequestUnits\": 500, \"MaxWriteRequestUnits\": 1000 } } ]" { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" }, { "AttributeName": "Genre", "AttributeType": "S" }, { "AttributeName": "SongTitle", "AttributeType": "S" } ], "TableName": "MusicCollection", "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "TableStatus": "CREATING", "CreationDateTime": 1704890776.114, "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection", "TableId": "26b92833-aaf5-4e66-9d30-283d066785a7", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST" }, "GlobalSecondaryIndexes": [ { "IndexName": "My-Index", "KeySchema": [ { "AttributeName": "Genre", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "Projection": { "ProjectionType": "INCLUDE", "NonKeyAttributes": [ "Artist" ] }, "IndexStatus": "CREATING", "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "IndexSizeBytes": 0, "ItemCount": 0, "IndexArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection/index/My-Index", "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } ], "DeletionProtectionEnabled": false, "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } } グローバルテーブル オンデマンドモードの最大スループットを設定してグローバルテーブルの容量を管理できます。これは ProvisionedThroughput と同様のセマンティクスに従います。１つのグローバルテーブルレプリカで読み取りまたは書き込み（あるいはその両方）の最大スループット設定を指定すると、同じ最大スループット設定がすべてのレプリカテーブルに自動的に適用されます。データを適切にレプリケーションするためには、グローバルテーブル内のレプリカテーブルとセカンダリインデックスに同一の書き込みスループット設定がされていることが重要です。 UpdateTable API に導入された OnDemandThroughputOverride パラメーターを使用すると、レプリカごとに個別の読み取り制限を設定できるため、他のレプリカ設定から柔軟に独立できます。グローバルテーブルのキャパシティ設定について詳しくは、 グローバルテーブルを管理するためのベストプラクティスと要件ガイド を参照してください。 次の例は、CLI を使用してグローバルテーブルレプリカの MaxReadRequestUnits のオーバーライドを追加する方法を示しています。 aws dynamodb update-table \ --table-name MusicCollection \ --replica-updates '[ { "Create": { "RegionName": "us-west-2", "OnDemandThroughputOverride": { "MaxReadRequestUnits": 100 } } } ]' { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" }, { "AttributeName": "SongTitle", "AttributeType": "S" } ], "TableName": "MusicCollection", "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "TableStatus": "UPDATING", "CreationDateTime": 1710345744.514, "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection", "TableId": "4219b238-c3d4-472e-aba3-82ac4e5554ce", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST", "LastUpdateToPayPerRequestDateTime": 1710345744.514 }, "StreamSpecification": { "StreamEnabled": true, "StreamViewType": "NEW_AND_OLD_IMAGES" }, "LatestStreamLabel": "2024-03-13T16:03:49.907", "LatestStreamArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection/stream/2024-03-13T16:03:49.907", "GlobalTableVersion": "2019.11.21", "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE" } ], "DeletionProtectionEnabled": false, "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } } テーブルの更新が完了すると、 DescribeTable 応答には読み取り用のオーバーライドされた値が含まれるようになります。 … "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE", "OnDemandThroughputOverride": { "MaxReadRequestUnits": 100 } } ] … S3 ワークフローからの復元とインポート DynamoDB のバックアップと復元機能は、オンデマンドの最大スループットもサポートします。バックアップは作成時のスループット設定を保持し、手動で上書きしない限り、復元時に新しいテーブルに適用されます。 ImportTable を使用して Amazon S3 からデータをインポートする場合、 CreateTable オペレーションで提供される柔軟性と同様に、オンデマンドの最大スループット制限を指定するオプションがあります。 復元またはインポートに OnDemandThroughput を指定しても、これらの操作の実行時間には影響しません。 モニタリング、アラートおよびトラブルシューティング オンデマンドテーブルの最大テーブルスループットを指定する前に、ワークロードとトラフィックを理解することが重要です。AWS には、アプリケーションのモニタリングと理解に役立つさまざまなサービスがあります。たとえば、 Amazon CloudWatch はログ、メトリックス、イベントとしてモニタリングデータを収集し、AWS のリソース、アプリケーション、サービスを一元的に把握できるようにします。 アプリケーションを効果的にモニタリング することで、アプリケーションの通常の状態を把握できます。ワークロードを理解したら、レート制限に最適なテーブルを判断できます。モニタリングを簡素化にするために、CloudWatch は OnDemandMaxReadRequestUnits と OnDemandMaxWriteRequestUnits のメトリクスを提供しています。これらのメトリックスは５分間隔で発行され、 ProvisionedReadCapacityUnits と ProvisionedWriteCapacityUnits のメトリクスの頻度と一致します。 オンデマンドテーブルの最大スループットはベストエフォートベースで適用されるため、保証されたリクエストの上限ではなく目標として考える必要があります。バーストキャパシティが原因で、ワークロードが指定された最大スループットを一時的に超える可能性があります。場合によっては、DynamoDB はバーストキャパシティーを使用して、テーブルのスループット設定を超える読み取りまたは書き込みに対応します。バーストキャパシティーを使用すると、スロットリングされていた可能性のある予期しない読み込みまたは書き込みリクエストに対して一時的に対応できます。詳細については、 バーストキャパシティを効果的に使用する を参照してください。 アプリケーションがオンデマンドテーブルに設定した最大読み取りまたは書き込みスループットを超えると、DynamoDB は ThrottlingException メッセージで示されるように、これらのリクエストのスロットリングを開始し、システムが事前に設定されたスループット設定を準拠していることを示します。オンデマンドの最大スループット制限を超えてスロットリングした場合、「Throughput exceeds the maximum OnDemandThroughput configured on table or index」というメッセージが返されます。例外メッセージはこの機能専用のもので、スロットリングしているインスタンスをすばやく識別するために機能します。DynamoDB の例外に関する詳細については、 DynamoDB でのエラー処理 を参照してください。 まとめ この記事では、オンデマンドテーブルの最大スループットを設定して、不要な DynamoDB スループットコストの暴走を回避し、ダウンストリームアプリケーションへの影響を抑える方法を示しました。この機能を使用するのに追加コストはかかりません。AWS マネジメントコンソール、AWS CLI、AWS SDK、DynamoDB API、または AWS CloudFormation を使用して開始できます。詳細については、 DynamoDB 開発者ガイド を参照してください。 著者について Lee Hannigan は、アイルランドのドニゴールを拠点とするシニア DynamoDB スペシャリストソリューションアーキテクトです。ビッグデータと分析テクノロジーの強固な基盤に支えられた分散システムに関する豊富な専門知識を持っています。DynamoDB スペシャリストソリューションアーキテクトとして、 DynamoDB の機能を活用したワークロードの設計、評価、最適化に関してお客様を支援することに優れています。 Mazen Ali は AWS の Amazon DynamoDB のプリンシパルプロダクトマネージャーで、ニューヨーク市を拠点としています。プロダクトマネジメントとテクノロジー関連の分野で豊富な経歴を持ち、お客様の要件を理解し、プロダクト戦略を定義し、クロスファンクショナルチームと協力して魅力的なエクスペリエンスを構築することに情熱を注いでいます。仕事以外では、旅行、読書、スキー、ハイキングを楽しんでいます。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2024 年 8 月のアップデート まとめはいかがでしたでしょうか。今月はアップデート以外に、開発者向けに Amazon Connect のスキルアップに役立つトレーニングをお知らせいたします。 それでは今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートとトレーニングについて 2024 年 9 月のアップデート一覧 AWS Contact Center Blog のご紹介 AWS Black Belt Online Seminar のご紹介 1.注目のアップデートとトレーニングについて 注目#1 Amazon Connect Developer Learning & Badge Plan (Amazon Connect の新しい学習プランが公開) 2024年8月に、学習プランの1つ目として、コンタクトセンターのエンジニア、通信エンジニア、IVR エンジニア、テレフォニー管理者を対象とした Amazon Connect Communications Specialist を公開しました。ここでは、テレフォニー、IVR、フロー、ルーティング、オムニチャネルデプロイ、および AWS サービスとの統合を学ぶことができます。そして2024年9月に、2つ目の学習プランとして、Amazon Connect 開発者向けに特別に作成された Amazon Connect Developer Learning を公開しました。Amazon Connect のコア開発コンセプト、ビジネスユースケースに適した Amazon Connect の統合手法、Amazon Connect のフロントエンドやバックエンドの統合、AWS CloudFormation と AWS CDK を使用した Amazon Connect のソリューションをデプロイする方法を学ぶことができます。 このカリキュラムを修了し、ナレッジチェックを 80% 以上のスコアで合格すると、 Amazon Connect Developer Specialist デジタルバッジが Credly のプラットフォームを介して AWS から提供されます。これはクラウドスキルや経験を伝えるために役立てることができます。 このトレーニングは無償で利用可能で、現在は英語で提供しています。学習には AWS Skill Builder のアカウントが必要です。 注目#2 Amazon Connect Contact Lens now supports new ways to automate agent performance evaluations (Amazon Connect Contact Lens がエージェントのパフォーマンス評価を自動化する新しい方法をサポート) Amazon Connect Contact Lens のパフォーマンス評価機能で、会話から得たインサイト(検出された問い合わせ理由など)に基づいて、パフォーマンス評価の質問を自動的に該当なしとしてマークできるようになりました。また、最長保留時間、保留数、エージェントの対話および保留時間などの追加のメトリクスを使用して、評価フォームに質問への回答を自動的に入力できるようになりました。これにより、例えば、アカウントを開設するために電話をかけてきた顧客のみを対象として、エージェントが新しいアカウントのメリットと価格を説明したかどうかを確認できます。さらに、エージェントが顧客の問題を 10 分以内に効率的に解決できたかどうかや、繰り返しの保留操作により顧客を待たせなかったかどうかなどを自動的に評価できます。 パフォーマンス評価の自動化は、評価フォームで以下の設定を実施します。 評価フォーム内のすべての質問に対してオートメーションを設定します。メトリクスを使用するには、評価フォームの「スコアと重み」タブで「スコアリングの有効化」をオンにします。 評価フォームを有効にする前に [完全自動評価を有効にする] をオンにします。 2. 2024年9月のアップデート一覧 Amazon Connect expands AWS CloudFormation support for agent hierarchies (Amazon Connect がエージェント階層向けの AWS CloudFormation のサポートを拡大) – 09/14/2024 AWS CloudFormation を使用したエージェント階層構造の設定が可能になりました。CloudFormation テンプレートを活用すると、Amazon Connect の階層レベルを安全で効率的な方法で、かつ同じ設定を繰り返し実行できるようにデプロイできるため、手動設定に伴う人為的ミスのリスクが軽減されます。CloudFormation を使えば、時間とともに生じる設定の変更を追跡し、自動的かつ管理された方法で更新を適用することも可能です。また、バージョン管理機能によって必要に応じて変更をすぐにロールバックできます。CloudFormation のエージェント階層向けサポートは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド AWS CloudFormation ユーザーガイド ( AWS::Connect::UserHierarchyGroup / AWS::Connect::UserHierarchyStructure ) Amazon Connect launches AWS CloudFormation support for agent status (Amazon Connect がエージェントステータスに関する AWS CloudFormation のサポートを開始) – 09/14/2024 ルーティングプロファイル、キュー、Amazon S3 バケット、AWS Lambda などのコンタクトセンター設定に使用されるリソースに加えて、エージェントステータスも AWS CloudFormation でサポートされるようになりました。CloudFormation テンプレートを使用すると、Amazon Connect のカスタムエージェントステータスを安全で効率的な方法で、かつ同じ設定を繰り返し実行できるようにデプロイできます。これにより、設定を一貫して維持することができます。CloudFormation を使えば、時間とともに生じる設定の変更を追跡し、自動的かつ管理された方法で更新を適用することも可能です。また、バージョン管理機能によって必要に応じて変更をすぐにロールバックできます。CloudFormation のエージェントステータス向けサポートは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド AWS CloudFormation ユーザーガイド ( AWS::Connect::AgentStatus ) Amazon Connect Contact Lens now supports new ways to automate agent performance evaluations (Amazon Connect Contact Lens がエージェントのパフォーマンス評価を自動化する新しい方法をサポート) – 09/06/2024 Amazon Connect Contact Lens のパフォーマンス評価機能で、会話から得たインサイト(検出された問い合わせ理由など)に基づいて、パフォーマンス評価の質問を自動的に該当なしとしてマークできるようになりました。また、最長保留時間、保留数、エージェントの対話および保留時間などの追加のメトリクスを使用して、評価フォームに質問への回答を自動的に入力できるようになりました。今回のリリースでは、特定の条件下で該当する評価質問についてのみ、自動的に入力できます。例えば、アカウントを開設するために電話をかけてきた顧客のみを対象として、エージェントが新しいアカウントのメリットと価格を説明したかどうかを確認できます。さらに、エージェントが顧客の問題を 10 分以内に効率的に解決できたかどうかや、繰り返しの保留操作により顧客を待たせなかったかどうかを自動的に評価できます。これらの新機能により、パフォーマンス評価の自動化と精度の向上を期待できます。この機能は、Contact Lens のパフォーマンス評価が既に利用可能なすべてのリージョンで利用できます。 関連リンク 管理者ガイド (自動評価を送信するルールを作成) 管理者ガイド (自動評価フォームを作成) Release Notes Amazon Connect now provides a weekly view of agent schedules (Amazon Connect でエージェントのスケジュールの週次ビューが使用可能に) – 09/04/2024 予測、キャパシティプランニング、およびエージェントスケジューリングにおけるスケジュール機能で、エージェントのスケジュールの週次ビューが提供されるようになりました。これにより、コンタクトセンターのマネージャーは1週間分の人員配置を一目で把握しやすくなりました。今回のリリースにより、サービスレベル、占有率、予測時間と予定時間などの毎日集計されるメトリクスによって、必要なカバレッジが毎日提供されていることを確認できるようになりました。例えば、週次ビューから、水曜日に人員超過が発生し、金曜日に人員不足が発生しているかどうかを簡単に確認できます。そして、週次ビュー内でエージェントのシフトを水曜日から金曜日に移動できます。週次ビューでは、エージェントが毎日適切なシフトになっていること(各エージェントが8時間のシフトになっていることなど)、連続して働いている日数が多すぎないこと(各エージェントが毎週少なくとも2日間休暇を取っていることなど)の確認も簡単に行えます。週次ビューでは、エージェントのシフトを日々管理するのに費やす時間を短縮することにより、マネージャーの生産性が向上し、複数の日々の人員配置を単一のビューで確認しやすくなります。この機能は、Amazon Connect の予測、キャパシティプランニング、およびエージェントスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect now offers intraday forecasts (Amazon Connect が日内予測の提供を開始) – 09/04/2024 予測、キャパシティプランニング、スケジューリング機能の一部として、機械学習を活用した日内予測をダッシュボードで確認できるようになりました。日内予測では、15 分ごとに更新されるキューの平均応答時間、コンタクト件数、平均処理時間の将来の予測データを参照することができます。これらの予測結果を確認することで、1 日を通してキューのデータが推移するかを監視し、顧客の待ち時間やサービスレベルを改善するための対策を積極的に講じることができます。例えばコンタクトセンター管理者は、コンタクト件数が予想レベルを下回った場合、日内予測を使用してその落ち込みがいつまで続くかを特定し、必要な人員配置レベルを決定し、残りのエージェントをバックオフィス業務や他の件数の多いキューにシフトさせることができます。この機能は、Amazon Connect の予測、キャパシティプランニング、およびエージェントスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens can now generate transcriptions in 10 new languages (Amazon Connect Contact Lens で 10 の新しい言語で文字起こしが生成可能に) – 09/04/2024 Amazon Connect Contact Lens は、カタロニア語 (スペイン)、デンマーク語 (デンマーク)、オランダ語 (オランダ)、フィンランド語 (フィンランド)、インドネシア語 (インドネシア)、マレー語 (マレーシア)、ノルウェー語 (ブークモール) (ノルウェー)、ポーランド語 (ポーランド)、スウェーデン語 (スウェーデン)、タガログ語/フィリピン語 (フィリピン) を含む 10 の新しい言語で文字起こしをサポートします。今回のリリースにより、Contact Lens 会話分析では 33 の言語の文字起こしがサポートされます。 関連リンク Amazon Connect Contact Lens について 管理者ガイド 3. AWS Contact Center Blog のご紹介 エージェントワークスペースで機微情報を扱う方法 (日本語翻訳) コンタクトセンターのエージェントは、複雑なワークフローを伴うトピックでもお客様をサポートしています。 Amazon Connect エージェントワークスペース 内のステップバイステップガイドは、特定のユースケースを処理する方法をエージェントに明確な手順として示します。ステップバイステップガイドはエージェント向けのワークフローで、エージェントの選択に基づいて分岐したり、外部システムとデータを送受信したりできます。ステップバイステップガイドはエージェントの生産性を高め、トレーニング時間を短縮し、一貫したカスタマーエクスペリエンスの提供を支援します。このようにステップバイステップガイドを操作する際、エージェントは機密データや極秘データを収集・入力することも頻繁にあります。そのようなデータは、通話ログや画面録画に記録されるべきではありません。 このブログ記事では、特定のステップバイステップガイドが呼び出されたときに自動的に録画を一時停止し、ワークフローが完了したら録画を再開するソリューションについて詳しく説明します。このソリューションでは、ワークフロー区間中の記録を自動的に停止する方法についても説明しています。 Integrate your AI-powered IVR/IVA for seamless customer interactions with Amazon Connect (英語記事) コンタクトセンターの運用において、ユーザーエクスペリエンスとエージェントの生産性を向上させるため、生成 AI を活用することが考えられます。近年、エージェントアシストやインテリジェントボットなどの機能が注目を集めているのは、このようなコンタクトセンターの AI 支援型への変化を推進する流れによるものです。多くのお客様は既に、対話型音声応答 (IVR) や知的バーチャルアシスタント (IVA) を主要なカスタマーサポートチャネルとして活用し、解決時間の短縮と業務効率の最適化を図っています。そして、AI 駆動のカスタマー・インタラクションと人間のエージェントによるインタラクションのシームレスな統合を求める企業が増えています。本ブログ記事では、企業が AI 駆動の IVR システムや IVA と Amazon Connect をシームレスに統合することで、カスタマーエクスペリエンスをさらに向上させる方法について紹介します。また、そのような統合によるメリットや、AI 駆動のアシスタントとエージェントの間のシームレスな会話の引き継ぎを可能にするアーキテクチャパターンについても深掘りします。 Frost Radar recognizes AWS as a 2024 Leader for Contact Center as a Service in APAC and EMEA (英語記事) 2024年の Frost Radar レポートでは、アジア太平洋 (APAC) 地域およびヨーロッパ、中東、アフリカ (EMEA) 地域におけるコンタクトセンターサービス (CCaaS) 市場で、Amazon Web Services(AWS) がリーダーとして評価されています。このレポートでは、 Amazon Connect の継続的な革新と成長が高く評価されています。両レポートでは、Amazon Connect のクラウドネイティブなアーキテクチャ、高度な機能、そしてグローバルに高可用かつ拡張性のある通話ネットワークが、市場トレンドの変化に適応した事が成長できた主要な要因として取り上げられています。APAC の Frost Radar レポートでは、人工知能 (AI)、分析、機械学習 (ML)、自然言語処理 (NLP) の最新技術を活用して Amazon Connect が絶え間なく進化している取り組みが高く評価されています。また、顧客中心のイノベーション手法にも注目が集まっており、Amazon Connect の新機能の95%が顧客からのフィードバックに基づいて開発されていることが強調されています。Frost & Sullivan のアジア太平洋情報通信技術ディレクターである Krishna Baidya 氏は、「 AWS は Amazon Connect の AI 駆動のイノベーションによってアジア太平洋のクラウドコンタクトセンター市場をリードしており、顧客中心のアプローチと業界特化型ソリューションにより、デジタルトランスフォーメーションのパートナーとして位置付けられています」と述べています。本ブログ記事では、Frost Radar レポートが示す Amazon Connect の革新性と成長について詳しく紹介しています。 4. AWS Black Belt Online Seminar のご紹介 Amazon Connect のユーザー管理 (Amazon Connect 再入門シリーズ) ( PDF | YouTube ) Amazon Connect インスタンスを設定する際は、事前に Amazon Connect のユーザー管理方法を決定する必要があります。ユーザーとは、Amazon Connect アカウントを必要とするすべての人 (エージェント、コールセンターマネージャー、アナリストなど) のことです。本セッションでは Amazon Connect のユーザー管理の全体像について紹介し、Amazon Connect で利用できる ID 管理方式や、ユーザー管理に関連した各種機能、セキュリティ面からの注意点について解説します。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 10 月 31 日 (木) 14:00-18:00 に、 AWS AI Day を開催します。物理的に来場する点に加えて、ライブ配信での視聴が事前登録できるようになりました。現地では、QuizKnock が審査員を行う AI ハッカソン決勝戦、展示ブース、スピーカーと会話ができる Ask a Speaker の場があるため、可能でしたら来場いただいたほうが良いですが、お時間の都合で難しい場合は、ライブ配信をご利用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年9月30日週の主要なアップデート 9/30(月) Amazon Aurora MySQL で RDS Data API のサポート Amazon Aurora MySQL で RDS Data API をサポートしました。これにより、MySQL のコネクションを管理する必要なく、AWS SDK や API 経由で SQL ステートメントを実行できるようになりました。Aurora MySQL では Serverless v1 のみサポートしていましたが、これが Serverless v2、Provisioned で利用可能になった形です。コネクションプーリングを Data API 側で管理をしてくれるため、例えば Lambda からの接続がやりやすくなるメリットがあります。Aurora MySQL の 3.07 以降のバージョンで Data API をサポートしています。 AWS CloudShell で VPC 連携、Docker 対応、起動時間の高速化など最新機能を全リージョンでサポート AWS CloudShell で、VPC のサポート、起動時間の改善、Docker サポートといった最新機能をすべての商用リージョンでサポート開始しました。これらの機能は、CloudShell の一部のリージョンで利用可能でしたが、今回のアップデートですべての商用リージョンで提供開始になりました。CloudShell の VPC サポートにより、VPC 内にCloudShell 環境を作成できるようになりました。また、Docker 統合により、CloudShell の環境で Docker を扱えるようになり、コンテナの開発やデプロイが可能となりました。 AWS re:Post で生成 AI バーチャルアシスタント機能の追加 AWS re:Post と呼ばれる、Q&A コミュニティがあります。AWS のお客様、パートナー、AWS の従業員が参加しており、オンラインコミュニティを通じてエキスパートの回答を得られる仕組みがあります。今回のアップデートで、AWS re:Post に投稿した質問に、生成 AI を活用したバーチャルアシスタントが回答を提供してくれるようになりました。質問を投げた直後に回答が得られるため、一般的な技術ガイダンスをすばやく確認できます。場合によってはハルシネーションが発生することがあり、正確性を精査する必要がありますが、回答までの待ち時間をショートカットでき、便利にご活用いただけます。 10/1(火) Amazon Redshift で RA3.large インスタンスの提供開始 Amazon Redshift で、新たに小さなインスタンスタイプの RA3.large (2 vCPU と 16 GiB メモリ) を提供開始しました。RA3 世代は、コンピュートとストレージが分離されており、それぞれ個別にスケールを変更できる柔軟性があります。加えて、データシェアリング、Zero-ETL、マルチ AZ といった機能を利用できます。RA3 世代の中で一番小さいインスタンスサイズは、ra3.xlplus (4 vCPU と 32 GiB メモリ) でしたが、より小さいインスタンスがサポートされ、ワークロードにあわせた最適なリソースを構築しやすくなりました。 Amazon ElastiCache でリザーブドノードのサイズ柔軟性をサポート Amazon ElastiCache でリザーブドノードのサイズ柔軟性をサポートしました。これまでは、特定のノードタイプ (例 : cache.r7g.xlarge) を指定してリザーブドノードを購入し、指定したタイプでのみ割引が提供される方式でした。このアップデートで、購入したノードタイプに設定されているレートに基づき、同じノードファミリーに所属する他のノードタイプに自動的に割引が適用されるようになりました。例えば、r7g.xlarge ノードを購入し、r7g.2xlarge のより大きなノードにスケールアップをした場合、r7g.2xlarge ノードの 50% の使用量に対して、割引レートが自動的に適用されます。詳細は こちらのブログ をご確認ください。 AWS Incident Detection and Response で日本語対応のサポート AWS Incident Detection and Response サービスで、日本語でのインシデント対応をサポートしました。AWS Incident Detection and Response は、AWS Enterprise Support をご利用いただいているお客様を対象に、プロアクティブな対応とインシデント管理を提供するサービスです。インシデント管理エンジニア (IME) が、24 時間 365 日体制で、お客様のワークロードからのアラームを 5 分以内に検知して対応を行い、緩和と復旧のためのガイドをお客様に提供します。従来は英語のみのサポートでしたが、このアップデートで日本語を話す IME とコミュニケーションができるようになりました。ミッションクリティカルで重要なシステムに活用することで、問題が発生したときに迅速な対応がしやすくなります。利用を進める際には、担当営業にご確認ください。詳細は Document や FAQ をご覧ください。 10/2(水) Amazon AppStream 2.0 で自動タイムゾーン変更機能を提供 Amazon AppStream 2.0 で、アプリケーションおよびデスクトップストリーミングセッションにおいて、自動タイムゾーン変更機能を有効にできるようになりました。この新機能により、例えば、クライアントデバイスが日本語のタイムゾーンとなっている場合、アクセス先の AppStream 2.0 の環境においても、タイムゾーン、言語、入力方法が自動的に日本語タイムゾーンに基いて調整されます。この機能を利用するためには、2024 年 9 月 18 日以降にリリースされた AppStream 2.0 エージェントが含まれるイメージを使用する必要があります。 Amazon AppStream 2.0 のマルチセッションフリートで、プリンターリダイレクトとユーザーが選択した地域設定が利用可能 Amazon AppStream 2.0 のマルチセッションフリートで、ローカルプリンターリダイレクトとユーザー選択の地域設定をサポートしました。これらの機能はすでにシングルセッションフリートで利用可能でしたが、今回のローンチによりマルチセッションフリートにも拡張された形です。ローカルプリンターリダイレクトにより、ユーザーはストリーミングアプリケーションから印刷ジョブをローカルコンピューターに接続されたプリンターにリダイレクトできます。なお、AppStream 2.0 ストリーミングインスタンスにプリンタードライバーをインストールする必要はありません。 10/3(木) Amazon Aurora Serverless v2 で最大 256 ACU が利用可能に Amazon Aurora Serverless v2 で、最大 256 Aurora Capacity Unit (ACU) をサポートするようになりました。Aurora Serverless v2 は、オートスケールの仕組みがあり、最小、最大の ACU を指定する中で、ワークロードに合わせて自動的にオートスケールできます。1 ACU は、約 2 GiB のメモリと、それに対応する CPU、ネットワークリソースが提供されます。元々は、128 ACU が最大でしたが 256 ACU までサポートされるようになり、よりリソースが要求されるワークロードに適用しやすくなりました。 AWS Glue インタラクティブセッションでオートスケールの一般提供開始 AWS Glue のインタラクティブセッションでオートスケール機能の一般提供を開始しました。AWS Glue インタラクティブセッションは、AWS Glue のジョブ開発を効率化するためのサーバーレス機能です。Jupyter 互換のノートブックや PyCharm、IntelliJ、VS Code などの IDE を使用して、リモートの Apache Spark ランタイム環境にアクセスできます。今回のアップデートで、Glue バージョン 3.0 以上の AWS Glue インタラクティブセッションで、ワークロードに基づいてリソースを動的に拡大縮小できるようになりました。自動スケーリングにより、セッションのリソースを過剰にプロビジョニングしたり、ワーカー数の最適化に時間を費やしたり、アイドル状態のワーカーに対して支払いをしたりする心配がなくなります。 10/4(金) Amazon Workspaces で、ローカルデバイス間とのファイル転送機能を提供開始 Amazon WorkSpaces は、WorkSpaces パーソナルセッションとローカルコンピュータ間のファイル転送をサポートしました。従来は S3 や FSx などの他のサービスを経由してファイル転送を実現していましたが、直接のファイル転送ができるようになり、より利便性が向上しました。ファイル転送機能は、デフォルトでは無効化されており、グループポリシーを変更することでファイル転送機能を有効化できます。詳細は こちら をご覧ください。 Amazon EC2 でインスタンス作成後に vCPU の数変更やハイパースレッディングの無効化が可能に Amazon EC2 でインスタンス起動後に、CPU オプションを変更できるようになりました。停止中の EC2 インスタンスを対象に、vCPU 数の変更やハイパースレッディングの無効化が可能になり、ライセンスコストを削減できる場合があります。どのように費用が変わるかはライセンスによりますので、詳細はライセンス元などにご確認ください。この機能はすべての商用リージョンで利用可能です。詳細は こちらのドキュメント を参照ください。 AWS Application Composer は AWS Infrastructure Composer に名称変更 AWS Application Composer が AWS Infrastructure Composer に名称変更しました。re:Invent 2022 でローンチ以来、シンプルなドラッグアンドドロップインターフェースによって、サーバーレスアプリケーションアーキテクチャの構成を提供していました。ローンチ以降、CloudFormation リソースへのサポートを拡大し、お客様が必要とするアーキテクチャを構築できる選択肢が広がり、よりわかりやすく AWS Infrastructure Composer という名称に変更しました。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

9 月 25 日、 Amazon Elastic Compute Cloud (Amazon EC2) の C8g および M8g インスタンスの一般提供についてお知らせします。 C8g インスタンスは、 AWS Graviton4 ベース で、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、ゲーム、動画エンコーディング、科学的モデリング、分散分析、CPU ベースの機械学習 (ML) 推論、広告配信など、コンピューティングを多用するワークロードに適しています。 同じく Graviton4 ベースの M8g インスタンスは、汎用ワークロードにおいて優れたコストパフォーマンスを実現します。アプリケーションサーバー、マイクロサービス、ゲームサーバー、中規模データストア、キャッシュフリートなどのアプリケーション向けのインスタンスです。 これらの 2 つのインスタンスにおける改善点をいくつか見てみましょう。C8g および M8g インスタンスは、同等の 7g インスタンスと比較して、最大 3 倍の vCPU (最大 48xl)、3 倍のメモリ (C8g で最大 384 GB、M8g で最大 768 GB)、75% 増のメモリ帯域幅、2 倍の L2 キャッシュを実現します。これにより、大量のデータの処理、ワークロードのスケールアップ、結果が出るまでの時間の短縮、総保有コスト (TCO) の削減を実現します。また、Graviton3 ベースのインスタンスが最大 30 Gbps のネットワーク帯域幅と最大 20 Gbps の Amazon Elastic Block Storage (Amazon EBS) 帯域幅 を提供するのに対して、これらのインスタンスは、最大 50 Gbps のネットワーク帯域幅と最大 40 Gbps の Amazon EBS 帯域幅を提供します。R8g インスタンスと同様、C8g および M8g インスタンスには、2 つのベアメタルサイズ (metal-24xl と metal-48xl) があります。インスタンスを適切なサイズに設定し、物理リソースへの直接アクセスからメリットを得るワークロードをデプロイできます。 C8g インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8g.medium 1 2 最大 12.5 最大 10 c8g.large 2 4 最大 12.5 最大 10 c8g.xlarge 4 8 最大 12.5 最大 10 c8g.2xlarge 8 16 最大 15 最大 10 c8g.4xlarge 16 32 最大 15 最大 10 c8g.8xlarge 32 64 15 10 c8g.12xlarge 48 96 22.5 15 c8g.16xlarge 64 128 30 20 c8g.24xlarge 96 192 40 30 c8g.48xlarge 192 384 50 40 c8g.metal-24xl 96 192 40 30 c8g.metal-48xl 192 384 50 40 M8g インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) m8g.medium 1 4 最大 12.5 最大 10 m8g.large 2 8 最大 12.5 最大 10 m8g.xlarge 4 16 最大 12.5 最大 10 m8g.2xlarge 8 32 最大 15 最大 10 m8g.4xlarge 16 64 最大 15 最大 10 m8g.8xlarge 32 128 15 10 m8g.12xlarge 48 192 22.5 15 m8g.16xlarge 64 256 30 20 m8g.24xlarge 96 384 40 30 m8g.48xlarge 192 768 50 40 m8g.metal-24xl 96 384 40 30 m8g.metal-48xl 192 768 50 40 便利なヒント AWS Graviton4 プロセッサは、常時オンのメモリ暗号化、すべての vCPU の専用キャッシュ、ポインター認証のサポートにより、セキュリティを強化します。 これらのインスタンスは、従来の仮想化機能の多くを専用ハードウェアとソフトウェアにオフロードする、多用なビルディングブロックの集合である AWS Nitro System 上に構築されています。AWS Nitro System は高パフォーマンス、高可用性、高セキュリティを実現し、仮想化のオーバーヘッドを削減します。 C8g および M8g インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションで実行される、マイクロサービスベースのコンテナ化されたアプリケーションを含む、すべての Linux ベースのワークロードに適しています。 今すぐご利用いただけます C8g および M8g インスタンスは現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョンでご利用いただけます。Amazon EC2 でのいつものお支払いと同様に、使用した分の料金のみをお支払いいただきます。詳細については、「 Amazon EC2 の料金 」を参照してください。アプリケーションを Graviton インスタンスタイプに移行する際に役立つ一連の AWS Graviton リソース をご覧ください。また、 AWS Graviton Fast Start プログラムにアクセスして Graviton の導入を開始することもできます。 詳細については、 Amazon EC2 インスタンスページ にアクセスしてください。また、 EC2 の AWS re:Post 、または通常の AWS サポートの担当者までフィードバックをぜひお寄せください。 –  Veliswa 原文は こちら です。

この記事は Migrating from AWS App Mesh to Amazon VPC Lattice (記事公開日: 2024 年 10 月 1 日) を翻訳したものです。 慎重に検討した結果、2026 年 9 月 30 日をもって AWS App Mesh のサポートを終了することを決定しました。この日まで、既存の AWS App Mesh のお客様は、AWS CLI や AWS CloudFormation による新しいリソースの作成や新しいアカウントのオンボーディングなど、通常通りにサービスを利用できます。また、AWS はこの期間中も、AWS App Mesh にセキュリティと可用性に関する重要な更新を引き続き提供します。新規のお客様は、2024 年 9 月 24 日以降、AWS App Mesh にオンボーディングできなくなります。 マイクロサービスアーキテクチャの採用が進むにつれて、モダンな分散アプリケーションの複雑さを管理することが、多くの組織にとっての課題となっています。 Amazon VPC Lattice は、 re:Invent 2022 で発表 されたフルマネージドサービスで、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda 、 Amazon Elastic Compute Cloud (Amazon EC2) など、さまざまな AWS サービス間の通信の一貫した接続性、セキュリティ、監視を可能にします。 AWS App Mesh は、 Kubernetes クラスター内のサービスに高度なトラフィック管理と可観測性の機能を提供します。一方で VPC Lattice は、サイドカープロキシを管理する必要性をなくすことで、アプリケーションネットワーキングをシンプルにします。 本記事では、VPC Lattice が複雑な分散アプリケーションの管理をどのようにシンプルにできるかを探求し、App Mesh から VPC Lattice への移行に関する Amazon EKS のお客様へのガイダンスを提供します。 Amazon ECS で App Mesh を使用しているお客様は「 AWS App Mesh から Amazon ECS Service Connect への移行 」という記事をお読みいただくことをおすすめします。 App Mesh と VPC Lattice の比較 App Mesh と VPC Lattice はどちらもトラフィック管理とアプリケーション認識型ネットワーキングを提供しますが、基本的な概念とアーキテクチャが異なります。移行を開始する前に、これらの違いを理解することが重要です。 まず、リソースの論理的な境界線を提供するために、VPC Lattice には Service Network という概念があり、これは App Mesh の Service Mesh に相当します。 次に、VPC Lattice でアプリケーション内のマイクロサービスを表すには Service を作成します。これは App Mesh の Virtual Service に相当します。 VPC Lattice の Target Group は、App Mesh の Virtual Node と同じく、サービスを Kubernetes Pod グループに紐づけます。 最後に、VPC Lattice の Listener と Listener Rule は、App Mesh の Virtual Router と Route と似ています。これらは、Service 内の Target Group へのトラフィックルーティングを定義します。 以下の図は、各サービスの異なるコンポーネント間の比較を示しています。 App Mesh リソースの VPC Lattice のリソースへの変換 アーキテクチャ上、App Mesh はトラフィックルーティングのため、Pod ごとにサイドカーコンテナとして実行されるセルフマネージドの Envoy プロキシ に依存しています。 対照的に、VPC Lattice はマネージドなコントロールプレーンとデータプレーンを提供するため、Pod 内にコンポーネントを追加する必要はありません。可観測性のため、App Mesh はメトリクスを Amazon CloudWatch に転送する Amazon CloudWatch Agent with Prometheus Metrics Collection のインストールを必要とします。一方で VPC Lattice は、CloudWatch で ビルトインのメトリクス を提供します。 Amazon EKS 上で App Mesh を使用してアプリケーションを実行する場合、 Kubernetes Ingress 、 AWS Load Balancer Controller 、 App Mesh Virtual Gateway を使用してクラスター外部にアプリケーションを公開することが一般的です。 しかし、AWS アカウントや VPC をまたいでアプリケーションを公開するには、多くの場合 AWS Transit Gateway のような追加のネットワークリソースが必要です。 VPC Lattice は、ロードバランシングと AWS Resource Access Manager (RAM) を組み込むことで、この問題をネイティブに解決します。これにより、異なる AWS アカウントで実行されている他の AWS リソースから Kubernetes の Service にアクセスできるようになります。 さらに、VPC Lattice は Kubernetes リソースを VPC Lattice オブジェクトに紐づける Gateway API を実装しています。 加えて、VPC Lattice は 認証ポリシー によって AWS Identity and Access Management (IAM) 認証をサポートし、マイクロサービス間の大まかな粒度での認可を実現します。 料金設定については、App Mesh では Envoy プロキシの追加のコンピュートリソースに対してのみ料金が発生します。しかし 、VPC Lattice のコストは、プロビジョニングされたサービスの数、各サービスへのトラフィックのデータ処理料金、各サービスが受信する HTTP リクエストの数 (HTTP/HTTPS リスナーのみ) に基づいて決定されます。 詳細は、VPC Lattice の 料金ページ をご覧ください。 移行戦略 App Mesh から VPC Lattice へのアプリケーションの移行時には、 インプレース 、 カナリア 、 Blue/Green など、複数の戦略から選択できます。適切な戦略は、ゼロダウンタイムの必要性やメンテナンスウィンドウを設定できるかどうかなど、アプリケーションの要件によって異なります。 インプレースでの移行戦略では、App Mesh で実装された既存の Kubernetes Pod を新しい Pod で置き換えます。このアプローチは、各 Pod が Envoy サイドカーコンテナを削除するために再起動されるので、移行中のダウンタイムを許容できるアプリケーションに適しています。 別の方法として Blue/Green デプロイ戦略では、VPC Lattice 用に構成された新しい Namespace にアプリケーションの 2 つ目のコピーをデプロイし、元のアプリケーションは App Mesh で運用を続けます。 このアプローチでは、両方の環境を同時に実行しながら、ダウンタイムなしで App Mesh から VPC Lattice にトラフィックを徐々に移行できます。 移行のウォークスルー このセクションでは、サンプルアプリケーションを App Mesh から Amazon VPC Lattice に移行するための手順の概要を、インプレース移行戦略を用いて説明します。 詳細な手順については、本記事の後半で説明します。 このウォークスルーで使うアプリケーションは、 Polyglot デモ と呼ばれる複数階層のデモアプリケーションです。このアプリケーションは次の 3 つのマイクロサービスで構成されています。 フロントエンド：商品カタログのユーザーインターフェース Product Catalog バックエンド：カタログに保存されているアイテムのリストを提供する REST API サービス Catalog Detail バックエンド：バージョン番号やベンダー名など、各アイテムの追加情報を提供する REST API サービス 次の図は Polyglot デモのフロントエンドのユーザーインターフェースを示しています。これには、異なるサービス間のトラフィックフローのアーキテクチャ図が含まれています。フロントエンドサービスは Product Catalog サービスを呼び出します。Product Catalog サービスは次に Catalog Detail サービスを呼び出します。 Product Catalog アプリケーションのアーキテクチャ 移行のステップ このセクションでは、App Mesh から VPC Lattice にアプリケーションを移行する際の主なステップについて説明します。 ステップ 1：Amazon EKS クラスターとサンプルアプリケーションのデプロイ はじめに、 eksctl を使用して今回のデモの基盤となる EKS クラスターを作成します。クラスターが作成されたら、App Mesh とVPC Lattice の機能を示すために、Polyglot デモアプリケーションをデプロイします。最後に、すべてが必要に応じて機能していることを確認するために、Polyglot デモアプリケーションのテストを実行します。 ステップ 2：App Mesh を使用してサンプルアプリケーションを設定する AWS App Mesh Controller と関連する Kubernetes カスタムリソース定義 (CRD) をインストールします。これらのコンポーネントにより、Kubernetes API を通じて App Mesh リソースを作成できます。 次に、App Mesh を使用して Polyglot デモアプリケーションを実装し、Virtual Service と Virtual Node を作成します。 現実のシナリオであることを強調するために、Product Catalog サービスの 2 つのバージョンをデプロイし、VPC Lattice への移行中にアクティブな Canary ロールアウトをデモンストレーションします。 最後に、アプリケーションをテストして、構成が正しいことを再確認します。 これで、この環境は移行を開始する準備ができました。 ステップ 3：VPC Lattice リソースを作成する AWS Gateway API Controller と関連する Kubernetes CRDをインストールします。App Mesh Controller と同様に、Kubernetes API を通じて VPC Latticeリソースを作成できるようになります。続いて、移行に必要な中心となる VPC Lattice コンポーネントを作成します。これには、 VPC Lattice Service Network にマッピングするクラスター内のVPC Lattice GatewayClass と Gateway 、サンプルアプリケーションのトラフィックルールを作成するための TargetGroupPolicy と HTTPRoute が含まれます。 ステップ 4：サンプルアプリケーションを VPC Lattice に移行する インプレースでの移行の場合、Envoy プロキシなどの既存の App Mesh コンポーネントを Pod から削除し、アプリケーションを新しい VPC Lattice エンドポイントで構成する必要があります。そのためにまず、Kubernetes Namespace にアノテーションを付与して、 App Mesh Controller が Pod を操作できない ようにします。次に、VPC Lattice エンドポイントを使うように、Polyglot デモアプリケーションを再デプロイします。最後に、Polyglot デモアプリケーションをテストして、VPC Lattice を通じて正しく機能することを確認します。 ステップ5：アプリケーションの公開とカナリアデプロイメントの実装 VPC Lattice では、アプリケーションへのトラフィックを許可するために Elastic Load Balancing (ELB) を使用する必要があります。このステップでは、App Mesh Virtual Gatewayを削除し、 AWS Load Balancer Controller で新しい Network Load Balancer を作成します。最後に、Product Catalog の 2 番目のバージョンを再デプロイし、VPC Lattice HTTPRoute を使用して、重み付けルーティングにより両方の Pod 間でトラフィックを分散します。 VPC Lattice リソースの確認 VPC Lattice から App Mesh への移行した後に、VPC Lattice に関連するさまざまなリソースがアカウントでプロビジョニングされ、 VPC Lattice コンソール で確認できます。 1. リソースの論理的な境界として VPC Lattice Service Network を作成しました。 AWS マネジメントコンソールで、Product Catalog Service Network を示すスクリーンショット 2. Kubernetes HTTPRoute を使って、アプリケーションの各階層に 1 つずつ、3 つの VPC Lattice Service を作成しました。 AWS コンソールでの、VPC Lattice Service のスクリーンショット 3. 3 つの VPC Lattice Target Group を作成し、各 VPC Lattice Service に 1 つずつアタッチしました。各Target Group のルーティングルールとヘルスチェックは、Kubernetes の TargetGroupPolicy リソースで設定しました。 AWS コンソールの VPC Lattice Target Group のスクリーンショット 4. 最後に、VPC Lattice を使って、サービスの HTTPRoute を更新することで、Product Detail マイクロサービスの 2 つのバージョン間でトラフィックを分散しました。以下の YAML スニペットのバックエンドルールは、アプリケーションの重み付けルーティングを示しています。 rules: - backendRefs: - name: proddetail namespace: prodcatalog-ns-lattice kind: Service port: 3000 weight: 50 - name: proddetail2 namespace: prodcatalog-ns-lattice kind: Service port: 3000 weight: 50 Bash 以下の図は、App Mesh から VPC Lattice に移行した後のアプリケーションのアーキテクチャを示しています。 VPC Lattice で実装された Polygot デモアプリケーション ハンズオンの手順 このサンプルの移行を再現するには、この GitHub リポジトリ のステップバイステップの説明をご覧ください。 まとめ 本記事では、分散アプリケーションのアプリケーションネットワーキングサービスである VPC Lattice を探求しました。App Mesh の機能・リソースと比較し、既存の App Mesh デプロイの移行戦略について説明しました。VPC Lattice は App Mesh と比較して、マルチアカウントネットワーキング、設定の簡素化、観測性の向上、その他の AWS サービスとのシームレスな統合といった、いくつかの利点を提供します。 詳細については、次の VPC Lattice のリソースとブログを参照してください。 ユーザーガイド API リファレンス FAQ 料金 クォータ Amazon VPC Lattice と Amazon EKS における AWS IAM 認証の実装 Amazon VPC Lattice を使用した、アプリケーションのためのセキュアなマルチアカウント・マルチ VPC 接続の構築 VPC Lattice と Pod Identity IAM セッションタグを使用した EKS クラスター間セキュア通信 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

7 月に、AWS は Llama 3.1 モデルが Amazon Bedrock で利用可能になったことをお知らせしました 。 生成 AI テクノロジーが驚くべきスピードで向上している中、今日は Amazon Bedrock で利用可能になった Meta からの新しい Llama 3.2 モデル をご紹介したいと思います。 Llama 3.2 は、 大規模言語モデル (LLM) における Meta の最新の進歩を象徴するマルチモーダルビジョンモデルと軽量モデルを提供し、強化された機能と、さまざまなユースケース全体へのより広範な適用性を実現します。 責任あるイノベーションとシステムレベルでの安全性 に重点を置くこれらの新しいモデルは、幅広い業界ベンチマークで最新鋭のパフォーマンスを実証し、新世代の AI エクスペリエンスの構築に役立つ機能を導入します。 これらのモデルは、画像推論でビルダーにインスピレーションを与えるように設計されており、エッジアプリケーションでも利用しやすいため、AI の可能性が広がります。 Llama 3.2 のモデルコレクションは、エッジデバイスに適したテキスト専用の軽量な 1B および 3B パラメータモデルから、高解像度画像のマルチモーダルサポートを含めた高度な推論タスクに対応できる小サイズと中サイズの 11B および 90B パラメータモデルまで、さまざまなサイズで提供されます。Llama 3.2 11B と 90B はビジョンタスクをサポートするための最初の Llama モデルで、画像エンコーダ表現を言語モデルに統合する新しいモデルアーキテクチャを備えています。新しいモデルは、低減されたレイテンシーと改善されたパフォーマンスで AI ワークロードをより効率的に行うように設計されているため、幅広いアプリケーションに適しています。 すべての Llama 3.2 モデルは、128,000 のコンテキスト長をサポートすることで、Llama 3.1 で導入されたトークン容量拡張を維持しています。さらに、これらのモデルは、英語、ドイツ語、フランス語、イタリア語、ポルトガル語、ヒンディー語、スペイン語、およびタイ語を含む 8 言語に対する強化された多言語サポートも提供します。 既存のテキスト対応の Llama 3.1 8B、70B、および 405B モデル に加えて、Llama 3.2 もマルチモーダルユースケースをサポートしています。今後は、Meta の 4 つの新しい Llama 3.2 モデルである 90B、11B、3B、および 1B を Amazon Bedrock で使用して、クリエイティブなアイデアを構築、実験、およびスケールできるようになります。 Llama 3.2 90B Vision (テキスト + 画像入力) – Meta の最先端モデルであり、エンタープライズレベルのアプリケーションに最適です。このモデルは、一般知識、長文テキスト生成、多言語翻訳、コーディング、数学、および高度な推論に秀でています。また、画像推論機能も導入するため、画像理解タスクやビジュアル推論タスクの実行が可能になります。このモデルは、画像キャプション生成、画像テキスト検索、ビジュアルグラウンディング、ビジュアル質問応答とビジュアル推論、およびドキュメントビジュアル質問応答などのユースケースに最適です。 Llama 3.2 11B Vision (テキスト + 画像入力) – コンテンツ作成、会話型 AI、言語理解、およびビジュアル推論を必要とするエンタープライズアプリケーションに最適です。このモデルは、テキスト要約、センチメント分析、コード生成、および指示への追随で優れたパフォーマンスを実証しており、画像について推論する追加機能もあります。このモデルのユースケースは 90B バージョンと似ており、画像キャプション生成、画像テキスト検索、ビジュアルグラウンディング、ビジュアル質問応答とビジュアル推論、およびドキュメントビジュアル質問応答などがあります。 Llama 3.2 3B (テキスト入力) – 低レイテンシーの推論を必要とし、計算リソースが限られているアプリケーション向けに設計されており、テキスト要約、分類、および言語翻訳タスクに優れています。このモデルは、AI 搭載のモバイルライティングアシスタントやカスタマーサービスアプリケーションなどのユースケースに最適です。 Llama 3.2 1B (テキスト入力) – Llama 3.2 のモデルコレクションの中で最も軽量なモデルであり、エッジデバイスやモバイルアプリケーションでの検索と要約に最適です。このモデルは、個人情報管理や多言語での知識検索などのユースケースに最適です。 また、Llama 3.2 はカノニカルなツールチェーンコンポーネントとエージェント型アプリケーションを構築するための標準化されたインターフェイスである Llama Stack 上に構築されているため、構築とデプロイがこれまでになく簡単になります。Llama Stack API アダプタとディストリビューションは、Llama モデルの機能を最も効果的に活用できるように設計されており、さまざまなベンダー全体で Llama モデルのベンチマークを行う能力をお客様に提供します。 Meta は、複数の言語にまたがる 150 を超えるベンチマークデータセットで Llama3.2 をテストし、人間による評価を大規模に実施して、他の主要基盤モデルとの競争力を備えたパフォーマンスを実証しました。では、これらのモデルが実際に機能する仕組みを見てみましょう。 Amazon Bedrock での Llama 3.2 モデルの使用 Llama 3.2 モデルの使用を開始するには、 Amazon Bedrock コンソール に移動して、ナビゲーションペインで [モデルアクセス] を選択します。そこで、新しい Llama 3.2 モデルである Llama 3.2 1B、3B、11B Vision、および 90B Vision へのアクセスをリクエストします。 新しいビジョン機能をテストするため、別のブラウザタブを開いて、 Our World in Data ウェブサイト から Share of electricity generated by renewables グラフを PNG 形式でダウンロードしました。グラフの解像度は非常に高いため、サイズを 1024 ピクセル幅に変更します。 Amazon Bedrock コンソールに戻り、ナビゲーションペインの [プレイグラウンド] で [チャット] を選択し、カテゴリとして [Meta] を選択してから、 [Llama 3.2 90B Vision] モデルを選択します。 [ファイルを選択] を使用してサイズ変更されたグラフ画像を選択し、以下のプロンプトを使用します。 Based on this chart, which countries in Europe have the highest share? [実行] を選択すると、モデルが画像を分析して結果を返します。 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK を使用して、プログラム的にモデルにアクセスすることもできます。Llama 3.1 モデルを使用するときと違い、今回は ドキュメントの記述どおりにモデル ID を更新 するだけで済みます。また、米国および EU リージョン用の新しい クロスリージョン推論エンドポイント も使用できます。これらのエンドポイントは、それぞれ米国と EU 内のどのリージョンでも機能します。例えば、Llama 3.2 90B Vision モデルのクロスリージョン推論エンドポイントは以下のようになります。 us.meta.llama3-2-90b-instruct-v1:0 eu.meta.llama3-2-90b-instruct-v1:0 以下は、 Amazon Bedrock Converse API を使用した AWS CLI コマンドの例です。CLI の --query パラメータを使用して結果をフィルタリングし、出力メッセージのテキストコンテンツのみを表示します。 aws bedrock-runtime converse --messages '[{ "role": "user", "content": [ { "text": "Tell me the three largest cities in Italy." } ] }]' --model-id us.meta.llama3-2-90b-instruct-v1:0 --query 'output.message.content[*].text' --output text 出力では、 "assistant" からの応答メッセージが得られます。 The three largest cities in Italy are: 1.Rome (Roma) - population: approximately 2.8 million 2.Milan (Milano) - population: approximately 1.4 million 3.Naples (Napoli) - population: approximately 970,000 AWS SDK のいずれかを使用する場合も、それほど違いはありません。例えば、以下は AWS SDK for Python (Boto3) で Python を使用して、コンソールの例と同じ画像を分析する方法です。 import boto3 MODEL_ID = "us.meta.llama3-2-90b-instruct-v1:0" # MODEL_ID = "eu.meta.llama3-2-90b-instruct-v1:0" IMAGE_NAME = "share-electricity-renewable-small.png" bedrock_runtime = boto3.client("bedrock-runtime") with open(IMAGE_NAME, "rb") as f: image = f.read() user_message = "Based on this chart, which countries in Europe have the highest share?" messages = [ { "role": "user", "content": [ {"image": {"format": "png", "source": {"bytes": image}}}, {"text": user_message}, ], } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) Llama 3.2 モデルは、 Amazon SageMaker JumpStart でも利用できます。SageMaker JumpStart は、コンソールを使用して行う、または SageMaker Python SDK 経由でプログラム的に行う事前トレーニングされたモデルのデプロイを容易にする 機械学習 (ML) ハブです。SageMaker JumpStart では、責任あるイノベーションとシステムレベルでの安全性をサポートするために設計された、モデルの入力 (プロンプト) と出力 (応答) の安全性レベルの分類に役立つ新しいセーフガードモデルにアクセスしてデプロイすることも可能です。これには Llama Guard 3 11B Vision も含まれます。 また、今すぐ SageMaker JumpStart を使用して、Llama 3.2 1B および 3B モデルを簡単にファインチューニングすることもできます。ファインチューニングされたモデルは、 カスタムモデルとして Amazon Bedrock にインポート できます。Amazon Bedrock と Amazon SageMaker JumpStart でのすべての Llama 3.2 モデルコレクションのファインチューニングは、近日提供される予定です。 一般公開されている Llama 3.2 モデルの重みは、カスタムニーズに合わせて調整されたソリューションの提供を容易にします。例えば、Llama 3.2 モデルを特定のユースケースに合わせてファインチューニングし、 それをカスタムモデルとして Amazon Bedrock に取り込む ことができるため、ドメイン固有のタスクでのパフォーマンスが他のモデルを上回る可能性があります。パフォーマンス強化のためにファインチューニングを行う分野がコンテンツ制作、言語理解、またはビジュアル推論であるかにかかわらず、Amazon Bedrock と SageMaker での Llama 3.2 の可用性は、ソリューションの差別化を可能にするユニークで高性能な AI 機能の作成に役立ちます。 Llama 3.2 モデルアーキテクチャの詳細 前バージョンの成功を土台として構築された Llama 3.2 は、最上のパフォーマンスと多用途性を実現するように設計された高度なアーキテクチャを備えています。 自己回帰言語モデル – Llama 3.2 は最適化されたトランスフォーマーアーキテクチャを中核としているため、以前のコンテキストに基づいて次のトークンを予測することによるテキストの生成が可能になります。 ファインチューニング手法 – Llama 3.2 の指示チューニング型バージョンは、2 つの主な手法を採用しています。 教師付きファインチューニング (SFT) – このプロセスは、特定の指示に従って、より関連性の高い応答を生成するようにモデルを調整します。 人間のフィードバックによる強化学習 (RLHF) – この高度な手法は、モデルの出力を人間の好みに合わせて調整し、有用性と安全性を強化します。 マルチモーダル機能 – 11B および 90B Vison モデルでは、Llama 3.2 が画像理解に対する新しいアプローチを導入しています。 個別にトレーニングされた画像推論アダプタの重みがコア LLM の重みと統合されます。 これらのアダプタは、クロスアテンションメカニズム経由でメインモデルに接続されています。クロスアテンションは、モデルのあるセクションが別のコンポーネント出力の関連する部分に注目できるようにすることで、モデルの異なるセクション間での情報フローを可能にします。 画像が入力である場合、モデルは画像推論プロセスを「tool use」操作として扱い、テキスト処理と並行して高度なビジュアル分析を実行できるようにします。この文脈での tool use とは、モデルがその機能を補強して、タスクをより効果的に完了するために、外部のリソースや関数を使用するときに使用される総称です。 最適化された推論 – すべてのモデルがグループ化されたクエリアテンション (GQA) をサポートしています。推論の速度と効率性を向上させる GQA は、特に大規模な 90B モデルに有益です。 このアーキテクチャは、さまざまなモデルサイズ全体で優れたパフォーマンスと適応性を維持すると同時に、テキストの生成と理解から複雑な推論と画像分析におよぶ幅広いタスクを Llama 3.2 が処理できるようにします。 知っておくべきこと 現在、 Meta からの Llama 3.2 モデル は、以下の AWS リージョン にある Amazon Bedrock で一般提供されています。 Llama 3.2 1B および 3B モデルは米国西部 (オレゴン) および欧州 (フランクフルト) で利用でき、 クロスリージョン推論 では米国東部 (オハイオ、バージニア北部) および欧州 (アイルランド、パリ) リージョンで利用できます。 Llama 3.2 11B Vision および 90B Vision モデルは米国西部 (オレゴン) リージョンで利用でき、 クロスリージョン推論 では米国東部 (オハイオ、バージニア北部) で利用できます。 今後の更新については、 完全な AWS リージョンリスト を参照してください。コストの見積もりには、 Amazon Bedrock の料金ページ をご覧ください。 Llama 3.2 の特徴と機能の詳細については、 Amazon Bedrock ドキュメントの Llama モデルセクション をご覧ください。 Amazon Bedrock コンソール で Llama 3.2 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock までフィードバックをお寄せください。 community.aws では、詳しい技術コンテンツを検索し、ビルダーコミュニティが Amazon Bedrock を使用する方法を見出すことができます。皆さんが Amazon Bedrock で Llama 3.2 を使用して何を構築しているのかを教えください! – Danilo 原文は こちら です。

9 月 23 日、AI21 Labs のパワフルな新しい Jamba 1.5 ファミリーの大規模言語モデル (LLM) が Amazon Bedrock でご利用いただけるようになりました。これらのモデルは、ロングコンテキスト言語機能を大幅に向上させたもので、幅広いアプリケーションでスピード、効率、パフォーマンスを実現しています。Jamba 1.5 ファミリーのモデルには、Jamba 1.5 Mini と Jamba 1.5 Large が含まれます。どちらのモデルも、256K トークンのコンテキストウィンドウ、構造化された JSON 出力、関数呼び出しをサポートし、ドキュメントオブジェクトのダイジェストが可能です。 AI21 Labs は、企業向けの基盤モデルと人工知能 (AI) システムの構築におけるリーダーです。AI21 Labs と AWS は協力して、あらゆる業界のお客様が、現実世界の課題を解決し、戦略的コラボレーションを通じてイノベーションを促進する 生成 AI アプリケーションを構築、デプロイ、スケールできるよう支援しています。AI21 Labs の高度な本番対応モデルと Amazon の専用サービスおよび強力なインフラストラクチャを組み合わせることで、お客様は安全な環境で LLM を活用して、情報の処理、コミュニケーション、学習の未来を形作ることができます。 Jamba 1.5 とは? Jamba 1.5 モデルは、トランスフォーマーモデルアーキテクチャと Structured State Space モデル (SSM) テクノロジーを組み合わせた独自のハイブリッドアーキテクチャを活用しています。この革新的なアプローチにより、Jamba 1.5 モデルは、従来のトランスフォーマーモデルの高性能な特性を維持しながら、最大 256K トークンの長いコンテキストウィンドウを処理できます。このハイブリッド SSM/トランスフォーマーアーキテクチャの詳細については、ホワイトペーパー「 Jamba: A Hybrid Transformer-Mamba Language Model 」を参照してください。 これで、Amazon Bedrock で AI21 の新しい Jamba 1.5 モデルが 2 つ使用できるようになりました。 Jamba 1.5 Large は、あらゆるプロンプト長にわたる複雑な推論タスクに優れているため、長い入力と短い入力の両方で高品質の出力を必要とするアプリケーションに最適です。 Jamba 1.5 Mini は、長いプロンプトの低レイテンシー処理に最適化されているため、長いドキュメントやデータをすばやく分析できます。 Jamba 1.5 モデルの主な強みは次のとおりです。 長いコンテキスト処理 – 256K トークンのコンテキスト長を備えた Jamba 1.5 モデルは、長いドキュメントの要約や分析、エージェントワークフローや RAG ワークフローなど、エンタープライズアプリケーションの品質を向上させることができます。 多言語 – 英語、スペイン語、フランス語、ポルトガル語、イタリア語、オランダ語、ドイツ語、アラビア語、ヘブライ語をサポートしています。 デベロッパーに優しい – 構造化された JSON 出力、関数呼び出しをネイティブでサポートし、ドキュメントオブジェクトのダイジェストが可能です。 スピードと効率性 – AI21 は Jamba 1.5 モデルのパフォーマンスを測定し、同等のサイズの他のモデルよりも長いコンテキストでの推論が最大 2.5 倍速いことを示しました。詳細なパフォーマンス結果については、 AI21 ウェブサイトの Jamba モデルファミリーの発表 をご覧ください。 Amazon Bedrock の Jamba 1.5 モデルの使用を開始する 新しい Jamba 1.5 モデルを使い始めるには、 Amazon Bedrock コンソール に移動し、左下のペインで [Model access] (モデルアクセス) を選択して、Jamba 1.5 Mini または Jamba 1.5 Large へのアクセスをリクエストしてください。 Amazon Bedrock コンソールで Jamba 1.5 モデルをテストするには、左側のメニューペインの [Text] (テキスト) または [Chat] (チャット) プレイグラウンドを選択します。次に、 [Select model] (モデルを選択) を選択し、カテゴリとして [AI21] を選択し、モデルとして [Jamba 1.5 Mini] または [Jamba 1.5 Large] を選択します。 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) と現在のサンプルプロンプトを使用してモデルを呼び出す方法のコード例を取得できます。 Amazon Bedrock ドキュメントのコード例 に従って、 AWS SDK を使用して利用可能なモデルにアクセスし、さまざまなプログラミング言語を使用してアプリケーションを構築できます。 次の Python コード例は、テキスト生成用の Amazon Bedrock Converse API を使用して Jamba 1.5 モデルにテキストメッセージを送信する方法を示しています。 import boto3 from botocore.exceptions import ClientError # Create a Bedrock Runtime client. bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") # Set the model ID. # modelId = "ai21.jamba-1-5-mini-v1:0" model_id = "ai21.jamba-1-5-large-v1:0" # Start a conversation with the user message. user_message = "What are 3 fun facts about mambas?" conversation = [ { "role": "user", "content": [{"text": user_message}], } ] try: # Send the message to the model, using a basic inference configuration. response = bedrock_runtime.converse( modelId=model_id, messages=conversation, inferenceConfig={"maxTokens": 256, "temperature": 0.7, "topP": 0.8}, ) # Extract and print the response text. response_text = response["output"]["message"]["content"][0]["text"] print(response_text) except (ClientError, Exception) as e: print(f"ERROR: Can't invoke '{model_id}'.Reason: {e}") exit(1) Jamba 1.5 モデルは、ペアドキュメント分析、コンプライアンス分析、長いドキュメントの質問回答などのユースケースに最適です。複数の情報源の情報を簡単に比較したり、文章が特定のガイドラインを満たしているかどうかを確認したり、非常に長いドキュメントや複雑なドキュメントを処理したりできます。サンプルコードは AI21-on-AWS GitHub リポジトリ にあります。 Jamba モデルに効果的にプロンプトを表示する方法の詳細については、 AI21 のドキュメント をご覧ください。 今すぐご利用いただけます AI21 Labs の Jamba 1.5 ファミリーモデルは、本日、米国東部 (バージニア北部) AWS リージョンの Amazon Bedrock で一般公開されます。 今後の更新については、 全リージョンのリスト を確認してください。詳細については、 Amazon Bedrock の AI21 Labs 製品ページと 料金ページ をご覧ください。 Amazon Bedrock コンソール で Jamba 1.5 モデルを今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 community.aws サイトにアクセスして、深く掘り下げた技術コンテンツを検索し、ビルダーコミュニティがソリューションで Amazon Bedrock を使用する方法を見出しましょう。 –  Antje 原文は こちら です。