2023 年 7 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Personalize 基礎編 レコメンドを機械学習の専門知識無しで利用できる Amazon Personalize の使い方を紹介します 資料（ PDF ） | 動画（ YouTube ） 対象者 レコメンドの導入を検討されている方 本 BlackBelt で学習できること Amazon Personalize がなぜ必要なのかと基本的な使い方 スピーカー 近藤健二郎 ソリューションアーキテクト Amazon Neptune ではじめるグラフデータベース入門 近年注目を集めているグラフデータベースについて、 Amazon Neptune の便利機能や簡単なクエリの実行結果を交えながらご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースに関する基本的な知識を持っている方 データベースに関連する開発や運用経験を持っている方 グラフデータベースに興味を持っている方 Amazon Neptune に興味を持っている方 本 BlackBelt で学習できること グラフデータベースの概念やユースケース グラフデータベースのクエリ基礎知識 Amazon Neptune の概要 グラフデータベースの学習方法 スピーカー 木村達也 ソリューションアーキテクト DX の加速に向けた AWS クラウド導入フレームワーク (AWS CAF) の活用 AWS クラウド導入フレームワーク (AWS CAF) は、AWS の経験とベストプラクティスを活用しており、AWS の利用によるデジタルトランスフォーメーション (DX) とビジネスの成果の加速を促すフレームワークです。本セミナーでは、AWS CAF を活用していただくために、そのホワイトペーパーを読み解くための、コツやポイントを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 DX 推進の施策を検討中の システム / DX 部門の方 クラウド活用を体系的に進めたい IT 担当者、または CCoE の方 オンプレミスとクラウドの考え方の違いを確認したいシステム部門の方 本 BlackBelt で学習できること AWS クラウド導入フレームワーク (AWS CAF) の読み解く方法を学習でき、クラウドを活用したデジタルフォーメーション（DX）の進め方を学ぶことができます。 スピーカー 釈迦郡一郎 カスタマーソリューションマネージャー モダナイゼーションプロジェクト立ち上げに向けたポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。一方で、抽象的なために全容が把握しずらい、検討したが関係者の共通認識がはかれないまま進めた結果頓挫してしまった、どこから手をつければいいか分からない、といった声も聞くようになってきました。本セッションでは、モダナイゼーションプロジェクトの立ち上げに向けて、事前に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 モダナイゼーションに取り組むうえで、企画フェーズでの検討内容に関心があるリーダー、責任者の方 システムのモダナイゼーションに取り組もうとしているが、その対象選定や方針策定のポイントを確認したい方 本 BlackBelt で学習できること モダナイゼーションプロジェクト立ち上げ前に検討・考慮すべきポイント モダナイゼーションに取組む上での対象選定や方針策定の進め方 スピーカー 平岩梨果 ソリューションアーキテクト Modernize Enterprise Java Application エンタープライズにおける Java アプリケーションをモダナイゼーションするポイントやアプローチについて、AWS の各種サービスの組み合わせ方を紹介しながら理解を深めます。 資料（ PDF ） | 動画（ YouTube ） 対象者 Java アプリケーションのモダナイゼーションに関心のある、IT アーキテクトやソフトウェアエンジニア Java アプリケーションの維持運用に課題を感じている方 本 BlackBelt で学習できること エンタープライズの Java アプリケーションの構成要素や処理方式に対し、AWS の各種サービスを組み合わせることでどのようなモダナイゼーションが実現できるのか、どのようなメリットがあるのか、について理解を深めることができます。 スピーカー 倉元貴一 ソリューションアーキテクト AWS CDK 概要 (Basic #1) AWS Cloud Development Kit (AWS CDK) の概要から開発の流れまでをご紹介します。AWS CDK で Amazon VPC をデプロイするデモも含んでいます。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア プログラミングの知識がある、あるいはこれから学ぶ方 本 BlackBelt で学習できること Infrastructure as Code の基礎から、AWS CDK のコンセプトや誕生ストーリー、開発の流れまでを概観できます。 スピーカー 高野賢司 ソリューションアーキテクト AWS CloudFormation#1 基礎編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。 本セミナーは、AWS CloudFormation について解説するシリーズの初回である基礎編です。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation をこれから学ぶ方、概要をお知りになりたい方 本 BlackBelt で学習できること AWS CloudFormation を扱う上で必要になる用語や、基本機能について解説しています。 AWS CloudFormation の基本的な使い方について学習いただけます。 スピーカー 福井敦 パートナーソリューションアーキテクト Amazon GameLift FlexMatch マルチプレイヤーゲーム用のマネージドなマッチメイキングサービス Amazon GameLift FlexMatch について網羅的に解説します 資料（ PDF ） | 動画（ YouTube ） 対象者 マッチメイキングの導入を検討されている方 現行のマッチメイキングの仕組みに課題を感じている方 本 BlackBelt で学習できること Amazon GameLift FlexMatch の抑えておきたい概念と仕組みについて網羅的に学習できます スピーカー 秋山周平 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-08 AWS Cloud Development Kit (CDK) 開発の基礎 ソリューションアーキテクト 高野 賢司 2023-08 AWS Control Tower 基本編 ソリューションアーキテクト 桂井俊朗 2023-08 AWS Control Tower 手順編 既存 Organizations での有効化 クラウドサポートエンジニア 大西朔 2023-08 Amazon CloudFront ( レポート / モニタリング / ロギング編 ) ソリューションアーキテクト 長谷川純也 2023-08 Amazon Personalize 応用編 ソリューションアーキテクト 近藤健二郎 2023-09 AWS Batch HPC スペシャリストソリューションアーキテクト 小林広志 2023-09 Amazon Managed Grafana ソリューションアーキテクト 大井友三 2023-09 Amazon Kinesis Video Streams 基礎編 ソリューションアーキテクト 宇佐美雅紀 2023-09 Amazon Kinesis Video Streams 応用編 IoT スペシャリストソリューションアーキテクト 三平悠磨 2023-09 AWS SimSpace Weaver コンセプト編 ソリューションアーキテクト 阿南麻里子 2023-09 Virtual Andon on AWS ソリューションアーキテクト 山田航司 2023-09 ミニチュア工場デモ : AWS IoT によるデータ集約と可視化 ソリューションアーキテクト 鈴木健吾 2023-09 AWS Key Management Service セキュリティソリューションアーキテクト 平賀敬博 2023-09 AWS Secrets Manager ソリューションアーキテクト 押川令 2023-09 Amazon GameLift FleetIQ ソリューションアーキテクト 安藤怜央  

デジタルの力で地域活性化を目指すデジタル田園都市国家構想に基づき、それぞれの地域の社会課題の解決や、その地域の強みや特色を活かしたデジタルトランスフォーメーション（DX）が加速しています。また2021年9月のデジタル庁発足後、ガバメントクラウドの導入が各自治体で本格的に進み始めています。一方でそれを推進すべきデジタル人材の不足は大きな課題です。 2006年に他社に先駆けてサービスを開始して以来、世界で最も包括的かつ幅広く採用されたクラウドサービスを提供するアマゾン ウェブ サービス（以下、AWS）は、クラウドサービスの提供にとどまらず、デジタル人材の育成支援にも取り組んでおり、最新のデジタルテクノロジーやグローバルの知見の提供などを通じて、地域経済活性化や地域創生に向けたDXの加速を支援しています。 アマゾン ウェブ サービス ジャパン合同会社（以下、AWSジャパン）では、全国の自治体や地域行政におけるイノベーションを支援し、より良い社会と市民生活の実現に貢献すべく、様々な自治体、関係団体との連携を図っています。2022年9月にはつくば市と研究開発型スタートアップの成長加速に向けた連携協定、また、同年同月に浜松市とデジタル・スマートシティ浜松の実現に向けた連携協定、2023年5月には新潟県と地域産業の活性化に向けた包括的な連携協定を締結しました。そしてこのたび、地域創生に向けた自治体におけるDXの加速を支援するため、AWSジャパンは2023年8月17日に北九州市と連携協定を締結しました。 アマゾン ウェブ サービス ジャパン合同会社 執行役員　パブリックセクター 統括本部長　宇佐見 潮は次のように述べています。「北九州市は『デジタルで快適・便利な幸せなまち』というミッションの実現を目指して、市の行政および地域産業全体でデジタルトランスフォーメーション（DX）に取り組まれています。また、同市は地域のポテンシャルや強みを生かした独自の戦略を打ち出し、“バックアップ首都構想”の実現や宇宙産業の推進に力を入れています。これらを支援する今回のイニシアチブは、デジタル田園都市国家構想が目指す地域創生の布石となることでしょう。北九州市との連携を通じて AWS のクラウドテクノロジーと多様な支援プログラムを提供し、北九州の目指すミッションに向けて伴走できることを心から嬉しく思います」   （写真左）AWSジャパン　執行役員 パブリックセクター統括本部長 宇佐見 潮／（写真右）北九州市 市長 武内 和久 北九州市は、「デジタルで快適・便利な幸せな街へ」のミッションのもと、DXを契機に必要な見直し・改善に取り組み、市民サービスの向上と業務の効率化を同時に実現することを推し進めています。 AWSジャパンは、北九州市の地域の特色や強みを活かしながら地域課題を解決するためのDXの推進に向けて、以下の4つの項目において、最新のクラウドテクノロジー、グローバルの知見・ネットワーク、デジタルスキル支援を通じて、北九州市のミッション実現を支援します。 1）“バックアップ首都構想 ”の実現に向けた支援 2）行政や地域のDX促進に向けた支援 3）スタートアップ育成に向けた支援 4）宇宙産業の推進に向けた支援 1. “バックアップ首都構想”実現に向けた支援 北九州市は、低災害リスクや、エネルギーや水の安定供給など、北九州市のポテンシャルを活かし、首都圏に集中する企業などが災害時にも業務を維持できるよう、バックアップ機能を誘致する“バックアップ首都構想”を掲げています。 この構想に基づく企業誘致には、北九州市におけるデジタル人材、特にクラウド人材が不可欠です。そこでAWSジャパンは在北九州市の企業と連携し、ハンズオンセッションを実施するなど、地域の企業にクラウドスキルトレーニングを提供し、デジタル人材の育成を支援します。 2. 行政や地域のDX促進に向けた支援 地域のイノベーションを推進するために、地域の産業やビジネスのイノベーション、DXを支える北九州市の職員がクラウドについて理解を深めていただくことが重要です。AWSのパートナー企業が実施するクラウド人材育成プログラムを市の職員に提供し、職員のデジタルスキルの向上をサポートしていきます。 また、地域のデジタル人材の層を厚くし、北九州市全体のイノベーションを促進・支援するために、地域の高等教育機関などと連携し、クラウド学習プログラムであるAWS Academy を活用した学生のクラウドスキルトレーニングや将来のデジタル人材育成を行います。 AWS Academyを通じて、教材や実習環境だけではなく、講師の登壇までのトレーニングも含むパッケージ化されたプログラムを高等教育機関向けに提供し、学生たちが将来、業界で認知されている認定資格を取得し、需要の高いクラウド関連の仕事に就けるように支援します。 3. スタートアップ育成に向けた支援 AWSでは、クラウドをはじめとしたデジタルテクノロジーを社会実装するうえで、スタートアップが欠かせないと考えています。それにより、過去10年にわたり数千におよぶ日本のスタートアップを支援してきました。北九州市との連携においてもそのノウハウを共有し、北九州市のスタートアップのすそ野をより一層拡大していきます。 まず、「COMPASS小倉」等の市内コワーキングスペースを利用する企業に対し、AWSのクレジットを利用できる AWS Activate などの支援プログラムを提供します。AWS Activateとは、スタートアップが自身のビジネスの立ち上げや拡大に向けてAWSを速やかに運用開始するために必要なリソースを包括的に提供するスタートアップ支援プログラムです。 4. 宇宙産業の推進に向けた支援 北九州市は市の成長戦略の一つとして宇宙産業に力を入れており、宇宙ビッグデータの利活用などを進めていく方針を打ち出しています。AWSは2020年に航空宇宙・衛星産業におけるイノベーションの加速に特化したチームを立ち上げ、官民のお客様の宇宙関連のビジネスをサポートしています。 今後、AWSの宇宙産業に関する知見や企業間のネットワークを北九州市と共有することで、市の宇宙産業推進のステージに合わせた連携を図っていきます。また、宇宙に関するアイデアコンテストやハッカソン等の共同開催も予定していきます。 AWSは、デジタル技術を活用して地域創生や社会課題解決に取り組む自治体や地域産業、スタートアップを、AWSの最新のテクノロジーやサービスなどの提供を通じて支援します。それにより市民や住民のより良い豊かな市民の暮らしに貢献することを、様々なステークホルダーと共に目指していきます。

2021 年 11 月、最高 3.6 GHz の周波数で動作する第 3 世代 AMD EPYC (Milan) プロセッサを搭載した Amazon EC2 M6a インスタンスがリリース されました。これにより、M5a インスタンスに比べてコストパフォーマンスが最大 35% 向上します。SAP など、x86 命令に依存するワークロードを実行する 多くのお客様 は、クラウドの利用を最適化する方法を模索しています。これらのお客様は、EC2 が提供するコンピューティングオプションを活用しています。 8月15日、最大周波数 3.7 GHz の第 4 世代 AMD EPYC (Genoa) プロセッサを搭載した新しい汎用 Amazon EC2 M7a インスタンスの一般提供をお知らせします。このインスタンスでは、M6a インスタンスと比べてパフォーマンスが最大 50% 向上しています。このパフォーマンスの向上により、データ処理の高速化、ワークロードの統合、保有コストの削減が実現します。 M7a インスタンスは、 AVX-512、Vector Neural Network Instructions (VNNI) 、および bfloat16 (Brain Floating Point 16) をサポートします。これらのインスタンスには、データインメモリへの高速アクセスが可能な Double Data Rate 5 (DDR5) メモリが搭載されていて、M6a インスタンスに比べて 2.25 倍のメモリ帯域幅を提供するので、レイテンシーを低く抑えることができます。 SAP 認定の M7a インスタンスは、金融アプリケーション、アプリケーションサーバー、シミュレーションモデリング、ゲーム、中規模データストア、アプリケーション開発環境、キャッシングフリートなど、高パフォーマンスと高スループットのメリットを活用するアプリケーションに理想的です。 M7a インスタンスでは、768 GiB の RAM で最大 192 の vCPU を使用できます。詳細な仕様は次のとおりです。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) m7a.medium 1 4 最大 12.5 最大 10 m7a.large 2 8 最大 12.5 最大 10 m7a.xlarge 4 16 最大 12.5 最大 10 m7a.2xlarge 8 32 最大 12.5 最大 10 m7a.4xlarge 16 64 最大 12.5 最大 10 m7a.8xlarge 32 128 12.5 10 m7a.12xlarge 48 192 18.75 15 m7a.16xlarge 64 256 25 20 m7a.24xlarge 96 384 37.5 30 m7a.32xlarge 128 512 50 40 m7a.48xlarge 192 768 50 40 m7a.metal-48xl 192 768 50 40 M7a インスタンスには最大 50 Gbps の拡張ネットワーキングと 40 Gbps の EBS 帯域幅があり、これは M6a インスタンスと同様です。ただし、1 つの vCPU、4 GiB を提供する新しいミディアムインスタンスサイズでは、ワークロードのサイズをより正確に調整できます。最大サイズは 192 の vCPU、768 GiB です。 新しいインスタンスは、従来の仮想化機能の多くを専用ハードウェアにオフロードするビルディングブロック技術の集合体である AWS Nitro System をベースに構築されており、高性能、高可用性、高セキュリティのクラウドインスタンスが実現しています。 今すぐご利用いただけます 8月15日、Amazon EC2 M7a インスタンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用できるようになりました。Amazon EC2 でいつも支払うのと同じように、使用した分の料金のみをお支払いいただきます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 EC2 M7a インスタンス と AWS/AMD パートナーページ を参照してください。 ec2-amd-customer-feedback@amazon.com 、 AWS re:Post for EC2 、または通常の AWS サポートの担当者を通じて、ぜひフィードバックをお寄せください。 — Channy 原文は こちら です。

夏を満喫するためにカリフォルニアで数日を過ごしている間に AWS では多くのことが起こりました。一緒に見ていきましょう！ 8月7日週のリリース 私が注目したリリースを以下に記載しました。 Amazon MWAA での Apache Airflow バージョン 2.6 のサポート – Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は エンドツーエンドのデータパイプラインをクラウドでセットアップして運用するために使用できる Apache Airflow 用のマネージドオーケストレーションサービスです。Apache Airflow バージョン 2.6 では、ワークフローのセキュリティと信頼性を強化する重要なセキュリティ更新とバグ修正が導入されています。現在 Apache Airflow バージョン 2.x を実行している場合は、バージョン 2.6.3 にシームレスにアップグレードできるようになりました。 この AWS ビッグデータブログの投稿 をご覧ください。 Amazon EMR Studio が AWS Lake Formation のきめ細かいアクセスコントロールのサポートを追加 – Amazon EMR Studio は、 Amazon EMR クラスター上で実行するフルマネージド型の Jupyter Notebook 用のウェブベースの統合開発環境 (IDE) です。EMR Studio ワークスペースから EMR クラスターに接続する際、接続する AWS Identity and Access Management (IAM) ロールを選択できるようになりました。Apache Spark インタラクティブノートブックは、このランタイム IAM ロールにアタッチされたポリシーで許可されているデータとリソースにのみアクセスします。 AWS Lake Formation で管理されているデータレイクからデータにアクセスする場合、このランタイムロールにアタッチされたポリシーを使用して、テーブルレベルと列レベルのアクセスを強制できます。詳細については、 Amazon EMR のドキュメント をご覧ください。 AWS Security Hub が 12 の新しいセキュリティコントロールをローンチ – AWS Security Hub は、セキュリティのベストプラクティスチェックを実行し、アラートの集約と自動修復の有効化を行う Cloud Security Posture Management (CSPM) サービスです。新たにリリースされたコントロールにより、Security Hub は Amazon Athena 、 Amazon DocumentDB (MongoDB 互換)、 Amazon Neptune という 3 つの AWS のサービスをサポートするようになりました。Security Hub では、 Amazon Relational Database Service (Amazon RDS) に対するコントロールも追加されています。AWS Security Hub では、現在、276 のコントロールが提供されています。詳細については、 AWS Security Hub のドキュメント を参照してください。 AWS イスラエル (テルアビブ) リージョンで利用可能になった AWS のサービス – AWS イスラエル (テルアビブ) リージョンが 2023 年 8 月 1 日にオープンしました 。8月7日週、イスラエル (テルアビブ) リージョンで利用可能なサービスのリストに、 AWS Service Catalog 、 Amazon SageMaker 、 Amazon EFS 、 Amazon Kinesis Data Analytics が追加されました。可用性に関する最新情報については、 AWS リージョン別のサービス表 を確認してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース 興味深いと思われるその他のブログ投稿とニュース項目をいくつかご紹介いたします。 2023 Gartner Magic Quadrant において AWS が Amazon Connect で Contact Center as a Service のリーダーに認定 – 柔軟な AI 搭載のクラウドコンタクトセンターである Amazon Connect が 2017 年にローンチされて以来、AWS は初のリーダーに選出されました。 全文を読む。 生成系 AI を使用したクリエイティブな広告生成 – この AWS Machine Learning ブログ投稿 では、生成系 AI を使用して魅力的で革新的な広告を大規模に生成する方法を示しています。Inpainting の手法に加えて、画像の背景、視覚的に魅力的なコンテンツをシームレスに作成する方法、そして不要な画像アーティファクトを削減する方法について説明します。 AWS オープンソースニュースと更新情報 – 私の同僚の Ricardo が 週刊のオープンソースニュースレター を執筆し、AWS コミュニティの新しいオープンソースプロジェクト、ツール、デモを紹介しています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 生成系 AI 上での構築 – 生成系 AI のすべてを網羅した 週刊 Twitch ショー のシーズン 2 が始まりました。 毎週月曜日 9:00 (米国太平洋標準時) に同僚の Emily と Darko が AWS の新しい技術的および科学的パターンについて考察し、ゲストスピーカーを招いてその作業のデモを行い、生成系 AI の状態を改善するために構築されたものを紹介します。 本日のエピソードでは、Emily と Darko が最新モデルの LLAMA-2 と Falcon について話し、Retrieval-Augmented Generation のデザインパターンで探求します。 ビデオはこちらからご覧いただけます 。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 AWS NLP カンファレンス 2023 – 9 月 13 日から 14 日にロンドンで開催 されるこの対面式イベントで AWS の自然言語処理 (NLP) 機能を活用する最新のトレンド、画期的な研究、革新的なアプリケーションの詳細を確認してください。今年のカンファレンスでは、多くの生成系 AI アプリケーションやユースケースのバックボーンを形成する大規模言語モデル (LLM) に主な焦点を当てます。 こちらからご登録 いただけます。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ (8 月 30 日) とヨハネスブルグ (9 月 26 日) の 2 回の対面イベントです。 AWS Community Day – AWS ユーザーグループリーダーが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 西アフリカ (8 月 19 日)、 台湾 (8 月 26 日)、 ニュージーランド (9 月 6 日)、 レバノン (9 月 9 日)、 ミュンヘン (9 月 14 日) で開催されます。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 登録が開始されました 。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 8月14日週はここまでです。8月21日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 —  Antje P.S.私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をお聞かせください。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 原文は こちら です。

この記事では、 Amazon Neptune Serverless の一般的なユースケースと、推奨されるベストプラクティスに従ってコストとパフォーマンスの両方を最適化する方法を紹介します。 Amazon Neptune は、グラフ・アプリケーションの構築と実行を容易にする、クラウド向けに最適化されたフルマネージド・データベース・サービスです。 RDF と プロパティグラフ 両方のグラフ・データモデルをサポートしています。データベース管理を簡素化し、新規アプリケーションの構築や既存アプリケーションの移行を迅速に行うことができます。高価なライセンス料からの脱却を目指す組織は、Neptuneに移行することで、最新のオープンソース・イノベーションの恩恵を受けることができます。求められる要件に対してカスタマイズできるよう、 高可用性や耐久性 など幅広い機能を提供します。 Neptune Serverless は、オンデマンドの自動スケーリング構成で、必要に応じてNeptuneクラスタをスケールするようにデザインされています。Neptune Serverlessでは、 いくつかの制限 はありますが、プロビジョニングされたインスタンスと同じ機能を使用できます。費用対効果が高く、データベースの容量を管理・最適化することなく、グラフのワークロードを実行し、迅速にスケーリングすることができます。Neptune Serverlessインスタンスでは、次のようなメリットがあります。 迅速かつ無停止のキャパシティ・スケーリング きめ細かく予測可能なキャパシティ調整 高可用性、ディザスタリカバリ、拡張機能 すでにNeptuneを使用している場合、アプリケーションを変更することなく簡単に移行することが可能 Neptune Serverlessクラスタのスケーリング構成は Neptune Capacity Unit （NCU）で定義され、NCUはそれぞれ2 GBのメモリと、関連する仮想プロセッサ（vCPU）およびネットワーク容量で構成されます。サポートされる NCU の最小値は 1.0 で、最大値は 128 です。NCU 構成は 0.5 NCU 単位で調整できます。Neptune Serverlessはコンピュートリソースのみスケールすることにご注意ください。 ストレージの上限 は変わらず、サーバーレスのスケーリングの影響を受けません。 Neptune Serverlessの一般的な使用例 Neptune Serverlessは、非定常的かつ突発的なトラフィックを伴うワークロードに最適です。定常的で予測可能なトラフィックを持つワークロードに使用することはお勧めしません。その理由は、定常的なワークロードの場合、プロビジョニングされたインスタンスの方がコスト効率が良いからです。たとえば、プロビジョニングされた db.r5.xlarge インスタンスを選択する方が、NCU=16 最小値=最大値に設定して 、NCU=16 のままのサーバーレスインスタンスよりも費用対効果が高くなります。 以下は、サーバーレスがデータの分離や費用対効果などの利点を提供できる、その他の使用例です。 Neptuneの新規利用あるいは新規アプリケーションに対するリソースの最適化 Neptuneを初めて利用するお客様にとって、グラフデータのワークロードに必要なインフラストラクチャを決定することが困難な場合があります。お客様のワークロードに 最適なインスタンスサイズを推定する方法 を提供していますが、クエリのレイテンシや予想されるトラフィックなどの追加情報が必要であり、初期段階では明らかにできないケースが多くあります。そのため、新規でNeptuneを利用するお客様や新規アプリケーションにとっては、キャパシティ要件を決定することが難しくなります。代わりに、コンピュートリソースの計算を気にせずにNeptune Serverlessを開始し、それまでのリソース消費量を確認することで要件を満たすプロビジョニング・インスタンス・サイズを特定することができます。また、アプリケーションの書き込み/読み込みが多かったり、トラフィックにばらつきがあることに気づいたら、 サーバーレスインスタンスとプロビジョニングインスタンス を1つのクラスタで組み合わせることもできます。 開発環境とテスト環境 多くのお客様は、本番環境ではない開発環境とテスト環境でコストを削減する新しい方法を模索しています。開発チームやテストチームが大規模なインスタンスをデプロイし、その停止や削除を忘れてしまうことは、多くのお客様にとって懸念事項です。しかし、開発チームやテストチームは、大規模な負荷テストを実行できるインスタンスをデプロイしなければいけません。サーバーレスは両方の長所を提供することができます。つまり、稼働していない期間中のコストを削減するために最小NCU数が少ないサーバーレスインスタンスをデプロイすることができ、開発チームやテストチームが高稼働期間中に迅速にスケーリングできるように最大NCU数が多いサーバーレスインスタンスをデプロイすることができます。 テナントごとのデータベースを備えたマルチテナント・アプリケーション 何千人ものエンドユーザーにサービスを提供する SaaS (Software as a Service) アプリケーションのようなプラットフォームでは、現在または予想される需要に基づいて Neptune クラスタを過剰または過小にプロビジョニングすることがよくあります。また、個々の顧客データを分離する必要がある場合、データの分離要件に直面することもあります。Neptune Serverlessを使用すると、個々のNeptuneクラスタを提供することで各顧客のデータを物理的に分離できるだけでなく、Neptune Serverlessの自動スケーリング機能を使用して、基盤となるインフラストラクチャを積極的に管理する必要がなくなり、各テナントデータベースを独立してスケーリングできます。 データベースに支えられたいくつかのアプリケーション 今日の最新のアプリケーション・アーキテクチャでは、何百、何千ものカスタム・アプリケーションが存在し、それぞれが1つ以上のデータベースによって成り立っています。アプリケーションの要件が進化するにつれて、それらをサポートし続けるためのデータベース容量も追随しなければなりません。費用対効果の高い方法でデータベース・フリートの容量調整を管理することは、困難かつ労力を要します。サーバーレスは、アプリケーションと関連するキャパシティ要件が進化するにつれて、データベース・キャパシティの管理負担を軽減するのに役立ちます。 効率的な水平および垂直スケーリング スケーラビリティを必要とするアプリケーションは、より高いスループットを得るために、データベースを複数のインスタンスに分割することがお勧めです。各インスタンスの容量を予測するのは困難で非効率的です。なぜなら、予想されるリクエスト数と各クエリのレイテンシに関する複雑な情報や経験が必要だからです。インスタンスの数が少なすぎると、データを再配置しなければならず、ダウンタイムが発生します。インスタンスの数が多すぎると、すべてのインスタンスが均等に利用されないため、高いコストを支払うことになります。サーバーレスインスタンスを使用することで、初期コストをあまり追加することなく、アプリケーションを複数のインスタンスにシャードすることができ、シャードされたデータベースはそれぞれ、必要なときに必要な容量を垂直方向に拡張することができます。過少利用や過剰なプロビジョニング、不要なコストの支払いは必要ありません。 Global DatabaseとNeptune Serverlessによるディザスタリカバリ Neptune Global Database は、プライマリーインスタンスと最大 5 つのセカンダリーリージョン間でグラフデータをレプリケートする機能を提供します。これにより、リージョン全体が停止した場合のディザスタリカバリの機能を提供します。しかし現実には、リージョン全体で障害が発生する可能性は低いため、セカンダリーリージョンにプロビジョニングされたNeptuneインスタンスは十分に活用されないケースもあります。セカンダリーリージョンでプロビジョニングされたインスタンスの代わりにサーバーレスインスタンスを使用することで、NCUの最小値を許容可能な最小値に設定することで、積極的に使用されていない間のコストを節約することができます。また、必要に応じて、クラスタ構成を更新することでNCU値を増やし、新しい需要に合わせて自動的にスケールさせることもできます。 Neptune Serverlessのベストプラクティス このセクションでは、Neptune Serverlessを使用する際のベストプラクティスを紹介します。 ワークロードと機能に最適な最小および最大NCUの構成 次のことを検討します。 一括ロードを使用するワークロード – バルクロードのようなリソース集約型のワークロードには、Neptune Serverlessを適切に構成することをお勧めします。最大 NCU は、希望するレートでデータを取り込むことができるレベルに設定する必要があります。たとえば、バルクロード操作時に 128 NCU に設定すると、Neptune は一括ロードに必要なリソースを確保できます。正確な最大 NCU は、取り込むデータ量と希望するデータ取り込みレートに依存します。また、NCU 最小値=最大値 とする構成は、スケーリングが容易にならないため、この種のユースケースではアンチパターンです。この場合、同じようなサイズ（メモリ・サイズとvCPU数）のプロビジョニングされたNeptuneインスタンスの方が良い選択かもしれません。 サーバーレスリーダーインスタンスを大規模なプロビジョニングされたプライマリーインスタンスと組み合わせて使用する場合、書き込みの数に追いつけず、共有ストレージからの読み込みを再起動するような状況が発生します。この場合、プライマリーからのレプリケーショントラフィックを満たすためにサーバーレスリーダーインスタンスの最小NCU構成を1NCU以上の値にスケールアップするか、一括ロード操作中に一時的に削除する必要があります。詳細については、 一括ロード中に再起動を繰り返さないようにする を参照してください。 IAMデータベース認証が有効になっているNeptuneクラスタ – AWS Identity and Access Management (IAM)データベース認証 が有効になっているNeptuneクラスタでは、エラーを回避するために最低でも2以上の最小NCU値が必要です。 トラフィックが急増するワークロードをサーバーレスインスタンスに切り替える 需要が急増し、一貫性のないワークロードに対しては、サーバーレスインスタンスを使用することで、Neptuneクラスタに関連するコンピュートリソースを垂直方向にスケールする自動化されたコスト効率の高いメカニズムが提供されます。しかし、トラフィックが一貫しているワークロードでは、サーバーレスインスタンスを使用すると、同じ容量のプロビジョニングされたインスタンスを使用する場合と比較してコスト効率が悪くなります。また、サーバーレスクラスターでNCU 最小値=最大値を設定することは、推奨されるパターンに反しています。要件によっては、プロビジョニングされたインスタンスの方がコスト効率とパフォーマンスが高く、ニーズを満たせるかもしれません。 最小容量を増やし、より高速なスケーリングを可能にする Neptune Serverlessは、最小NCUの設定値に基づく速度でスケールします。最小NCUが1.0に設定されている場合、サーバーレスクラスターが重いトラフィックに対応する容量を提供するためにスケールアップするのに時間がかかります。これは、Neptune Serverlessが 現在使用されているサーバーレス容量に基づいてスケーリング増分を選択 するためです。これを高い値に設定することで、特にデータベースへの需要が増加することが分かっているイベントの前に、Neptune Serverless はより高いスケーリング率を使用し、需要に対応するためにより速くスケールアップします。 リーダーインスタンスの正しい昇格階層を設定する Neptune Serverlessリーダーインスタンスが最小NCUまでスケールダウンせず、プライマリーインスタンスと同じかそれ以上の容量にとどまっている場合は、リーダーインスタンスの昇格階層を確認してください。Tier 0または1では、サーバーレスリーダーインスタンスはライターインスタンスと同じ容量に維持されます。リーダーの昇格階層を2以上に変更することで、ライターから独立してスケールアップあるいはスケールダウンするようになります。詳細については、 Neptune Serverlessインスタンスの昇格階層 の設定を参照してください。 Neptune Serverlessと自動スケーリングの組み合わせ Neptuneリードレプリカ自動スケーリング を使用して、接続要件とワークロードに基づいてNeptuneクラスタ内のレプリカ数を自動的に調整できます。また、Neptune Serverless を使用して、アプリケーションからの突然のトラフィック急増にも対応することができます。CPU使用率ベースの自動スケーリングを使用する場合、最小値と最大値の両方のNCUを低く設定したり、最小値と最大値のNCUの範囲を狭く実装したりすると、Neptuneリードレプリカの追加と削除が急激に行われることがあります。 クエリのタイムアウトを正しく設定し、クエリがバックグラウンドで実行され、コストがかかるのを防ぐ プロビジョンドインスタンスと比較して、長時間稼働するワークロードに対してNeptune Serverlessを実行するコストは高くなるため、特定の要件に対応できるように クエリタイムアウトパラメータ(neptune_query_timeout) を調整することをお勧めします。短時間のクエリのみが予想される場合は、クエリタイムアウトを短く設定します。これは、バックグラウンドで実行されている予期せぬ長時間実行クエリによって不要なコストが発生するのを避けるためです。 サーバーレスインスタンスを監視してコストと最適化を図る サーバーレスクラスターやインスタンスを監視するために、 サーバーレスインスタンス用のAmazon CloudWatchメトリクス が2つ追加されています。 ServerlessDatabaseCapacity – (インスタンスレベルの) 現在のインスタンス容量、または (クラスタレベルの) 全インスタンスの全値の平均を提供する NCUUtilization – ServerlessDatabaseCapacity を NCU の最大値で割って、使用可能な容量の割合をレポートする もし NCUUtilization メトリックが100%に近づいている場合は、サーバーレスインスタンス全体でNCUの最大値を増やすことを検討してください。 Neptune Serverlessの価格 サーバーレスインスタンスをデプロイする際、価格設定などはプロビジョニングインスタンスと同じ要素が適用されます。 ストレージはGB/月で請求 消費されたI/Oオペレーション バックアップ・ストレージ データ転送料金 Global Database やスナップショットエクスポートなどの特別機能の料金 サーバーレスインスタンスの課金の主な違いは、 1時間あたりのNCUでの使用量 に基づいて価格が設定されることです。実際のコストは、Neptuneクラスタがデプロイされたリージョンによって異なります。 Neptune Serverlessの価格比較 以下は、サーバーレスインスタンスと db.r6g.8xlarge プロビジョニングインスタンスを使用した場合の、30日間にわたるスパイク上のトラフィックと一貫したトラフィックを持つワークロードのコスト比較です。どちらの見積もりにも以下の構成が含まれています。 リージョンは us-east-1 50GBのデータと100GBのバックアップ 月間2億回のI/Oオペレーション 月間50GBのデータ転送 月間10GBのデータ転送 次の表は、トラフィックが急増しているワークロードの例を比較したものです。最大 NCU (128) で 1 日あたり 1 時間、最小 NCU (1) で 1 日あたり 23 時間です。 Serverless Provisioned (db.r6g.8xlarge) Instance charges $728.42 $3,804.62 Storage charges $7.10 $7.10 I/O charges $40.00 $40.00 Data transfer charges $0.00 $0.00 Total charges $775.52 $3,851.72 サーバーレスを使用した場合、プロビジョニングされたインスタンスと比較して、スパイク特性の高いワークロードにかかるコストの差は、月額 3,076.20ドル の節約となりました。 次の表は、最大NCU（128）で1日あたり23時間、最小NCU（1）で1日あたり1時間、一貫したトラフィックのワークロードの例を比較したものです。 Serverless Provisioned (db.r6g.8xlarge) Instance charges $14,206.80 $3,804.62 Storage charges $7.10 $7.10 I/O charges $40.00 $40.00 Data transfer charges $0.00 $0.00 Total charges $14,253.90 $3,851.72 一貫したワークロードに対してプロビジョニングされたインスタンスとサーバーレスを使用した場合のコストの差は、月額 10,402.18ドル の増加となりました。 Neptune Serverlessの制約 Neptune Serverlessは垂直スケーラビリティとコスト効率を迅速に提供できますが、その制約を理解することが重要です。 サーバーレスは すべての地域で利用できるわけではない （訳注:東京リージョンではご利用可能です） エンジンリリース1.2.0.1 以降で使用可能 Neptuneの ルックアップキャッシュ とは互換性がない サーバーレスインスタンスの最大メモリは256GB（最大NCUは128） 詳細は Amazon Neptune Serverless constraints を参照してください。 まとめ この投稿では、Neptune Serverlessの一般的なユースケースとベストプラクティスについて説明しました。様々なトラフィックやデータ分離を必要とするワークロードに対してプロビジョニングされたインスタンスよりもサーバーレスインスタンスを使用したり、本番環境ではない開発環境やテスト環境などで高い費用対効果を得たりすることでメリットを得ることができます。さらに、同じNeptuneクラスタ内でサーバーレスインスタンスと従来のプロビジョニングされたインスタンスを組み合わせることで、最も負荷の高いワークロードに対して柔軟性とスケーラビリティを提供する方法についても説明しました。 Neptune Serverlessを始めるには、 Neptuneコンソール にアクセスするか、 Amazon Neptune Serverless を参照して詳細を確認してください。 著者について Kevin Phillips は、Amazon Web Servicesの英国で働くNeptuneスペシャリスト・ソリューション・アーキテクトです。18年にわたる開発とソリューション・アーキテクチャの経験を生かし、顧客のサポートと指導にあたっています。 Ankit Gupta は、インドの Amazon Neptune Platform チームのソフトウェア開発マネージャーで、製品立ち上げ当初から Neptune チームの一員です。AWSの顧客や社内の開発チームと協力し、Neptuneのユーザビリティ、パフォーマンス、スケーラビリティ、ユーザーエクスペリエンスの向上に取り組んでいます。 本記事は 2023/06/28に投稿された Use cases and best practices to optimize cost and performance with Amazon Neptune Serverless を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。

AWS AppSync は、アプリケーションがデータに接続するためのスケーラブルな API を簡単に構築できるマネージドサービスです。AppSync を使用することで、 Amazon DynamoDB に接続する API で Web アプリケーションを強化する場合や、ユーザーにイベントの ライブアップデートを提供する リアルタイムダッシュボードを構築する場合に、アプリケーションを需要に合わせてシームレスに拡張することができます。昨年、AppSync は AppSync パイプラインリゾルバと AppSync 関数で JavaScript のサポートを開始しました。これにより、お客様はリゾルバを JavaScript で記述し、AppSync の JavaScript ランタイム上で実行してクエリを解決できるようになりました。また、JavaScript リゾルバにより、お客様は一般的な変換や翻訳操作のために追加の計算リソースを使うことなく、リゾルバでより多くのことを行えるようになりました。 AppSync は JavaScript のサポートをユニットリゾルバに拡張しました。開発者は、単一のリゾルバで JavaScript の単一データソースアクセスパターンを扱えるようになりました。開発者は、複雑なアクセスパターンを処理したり、 パイプラインリゾルバで JavaScript 関数と Velocity Template Language (VTL) 関数を混在させたりすることができます。本記事では、独自の API で JavaScript リゾルバを使用する方法について説明します。 はじめに AWS AppSync コンソールで JavaScript リゾルバを始めることができます。コンソールで “Create API” を選択し、”design from scratch” を選択します。API に名前を付け、ステップ 2 で “Create type backed by a DynamoDB table now” を選択します。ここでコンソールは、新しい GraphQL 型とオペレーションの作成をサポートしてくれます。型を持つ DynamoDB テーブルを作成します。 id 、 owner 、 name 、 severity 、 dueOn のフィールドを持つ Todo 型を作成してみましょう。コンソールで、リゾルバに AppSync JavaScript ランタイムを事前に選択します。 DynamoDB テーブルで構築されたデータモデルを構成します。 次に、データを格納するテーブルを設定します。テーブル名を “todos” とし、プライマリキーを id 、ソートキーを owner に設定します。 owner で Todo を取得するためのインデックスを追加します。インデックス名を “owner-dueon-index” とし、主キーを owner 、ソートキーを dueOn とします。 “Next” をクリックし、オプションを確認して API を作成します。API が作成され、リゾルバが自動的に生成されます。スキーマページから、生成されたリゾルバを 1 つ選択するか、任意のフィールドに新しいリゾルバをアタッチすることができます。 id を与えなくても Todo が作成できるようににスキーマを変更してみましょう。 CreateTodoInput を以下のように更新します。 input CreateTodoInput { id: String owner: String! name: String severity: Int dueOn: AWSDate } 次に、”Resolvers” の画面で、 createTodo フィールドを見つけ、そのリゾルバをクリックします。編集するコードは 1 行だけです。以下のように修正を行います。 修正前 const { id, owner, ...values } = ctx.args.input; 修正後 const { id = util.autoId(), owner, ...values } = ctx.args.input; この単純な変更では、AppSync ユーティリティの autoId を使用して、一意な ID が提供されていない場合に新しい一意な ID を生成します。”Queries” の画面から、Query や Mutation の送信や、Subscription の設定ができます。 例えば、以下のように Todo を作成することができます。 mutation create { createTodo(input: {name: "first todo", owner: "brice", severity: 10, dueOn: "2023-08-10"}) { dueOn id name owner severity } } 次に、 owner を使用して作成した Todo を取得することができます。 query byOwner { queryTodosByOwnerDueonIndex(owner: "brice") { items { id name owner } } } どのスキーマフィールドにもリゾルバをアタッチすることができます。リゾルバをアタッチするには、リゾルバの型、ランタイム、データソースを選択します。 リゾルバが作成されると、いくつかのサンプルコードから選択して、独自のリゾルバを書き始めることができます。 AWS CDK の使用 AWS CDK プロジェクトでは JavaScript リゾルバを使用できます。ローカルで作業する場合は、TypeScript、AppSyncユーティリティライブラリや型、AWS Amplify codegen を活用してコーディング体験を向上させることができます。CDK プロジェクトで TypeScript を使い始めるには、AppSync リゾルバサンプルリポジトリの Todo API CDK サンプルを利用できます。この例では、ファイル名に基づいてリゾルバをデータソースに自動的にリンクするローカルのヘルパーコンストラクトを使用しています。まずリポジトリをローカルにクローンし、依存関係をインストールします。 $ git clone https://github.com/aws-samples/aws-appsync-resolver-samples.git $ cd aws-appsync-resolver-samples $ cd examples/cdk/constructs/appsync-helper $ npm run init $ cd ../../dynamodb-todo-app $ npm install アプリのリゾルバは lib/appsync/resolvers にあります。 Mutation.createTodo.[todos].ts を見てください。 ./lib/appsync/codegen にある自動生成コードの型を使用しています。codegen の型は、 ./lib/appsync/schema.graphql にあるスキーマファイルから自動生成されます。codegen を生成するには、以下を実行します。 $ npm run codegen (このコマンドは amplify codegen を呼び出します。) これで、コード内で型を使用できるようになります。スキーマが変更された場合はいつでも codegen を再実行し、型を更新することができます。これは Mutation.createTodo のリゾルバです。 import { util, Context } from '@aws-appsync/utils'; import { CreateTodoMutationVariables } from '../codegen'; import { dynamodbPutRequest } from './utils'; export { checkErrorsAndRespond as response } from './utils'; export function request(ctx: Context<CreateTodoMutationVariables>) { const { input: values } = ctx.arguments; const key = { id: util.autoId() }; const condition = { id: { attributeExists: false } }; console.log('--> create todo with requested values: ', values); return dynamodbPutRequest({ key, values, condition }); } このリゾルバは、DynamoDB の PutItem リクエストを作成するためにヘルパー関数 dynamodbPutRequest を使用します。また、レスポンス処理には、レスポンスとしてエクスポートするヘルパー関数 checkErrorsAndRespond を使用します。これはよくあるパターンなので、すべてのリゾルバに書くのではなく、プロジェクトのユーティリティのリストに追加します。 /** * Checks for errors and returns the `result */ export function checkErrorsAndRespond(ctx: Context) { if (ctx.error) { util.error(ctx.error.message, ctx.error.type); } return ctx.result; } リゾルバをローカルで操作する際には、TypeScript、インポート、エクスポート、外部ユーティリティを使用できます。リゾルバを保存する前にコードをバンドルするだけです。バンドルの詳細については、AppSync の ドキュメント をご参照ください。このプロジェクトでは、リゾルバを自動的にバンドルし、データソースにアタッチしてくれます。詳細については、 ヘルパーコンストラクト をご参照ください。 変更をデプロイする準備ができたら、以下を実行してください。 $ npm run cdk deploy プロジェクトが終了したら、リソースを削除することができます。 $ npm run cdk destroy リゾルバのコードサンプルだけでなく、その他のサンプルも リポジトリ にあります。 まとめ 本記事では、ユニットリゾルバで JavaScript が新たにサポートされたことについて説明しました。コンソールから簡単に始める方法を説明し、CDK プロジェクトのユニットリゾルバで TypeScript などの機能をどのように使用できるかを見ました。これで、すべてのリゾルバと関数で AppSync JavaScript ランタイム を利用できるようになり、データアクセスのすべてのユースケースを使い慣れた方法で簡単に扱えます。まだ JavaScript リゾルバを試したことがないのであれば、ぜひ試してみてください。AWS AppSync コンソールのサンプルやサンプルリポジトリで簡単に始めることができることを忘れないでください。 JavaScript リゾルバの詳細については、 ドキュメント や チュートリアル を参照してください。詳細なガイド付きウォークスルーについては、 AWS AppSync Immersion Day Workshop をご覧ください。 サンプルリポジトリ には、使いやすいサンプルやガイドがあります。 本記事は、 AWS AppSync now supports JavaScript for all resolvers in GraphQL APIs を翻訳したものです。翻訳はソリューションアーキテクトの 稲田大陸 が担当しました。

この記事では、 Amazon SageMaker Processing API を使用して数値最適化問題を解く方法について説明します。最適化とは、様々な制約条件のもと、ある関数の最小値（または最大値）を求めるプロセスです。このパターンは、作業スタッフのシフト作成や輸送ルート選定、在庫配分、形状や軌跡の最適化など、ビジネスにおける重要な問題の解決に役立ちます。このような問題を解くためには、商用もしくはオープンソースで提供される“ソルバー”というソフトウェアが利用されます。この記事では、無償で利用できる3つの一般的な Python のソルバーを SageMaker Processingで実行し、これらの最適化問題を解く方法を示します。 概要 SageMaker Processing により、データサイエンティストと ML エンジニアは、SageMaker 上で前処理や後処理、モデル評価などのAIや機械学習に必要なタスクを簡単に実行できるようになります。このSDKは、 scikit-learn と Spark の組み込みコンテナを使用しますが、独自の Docker イメージを使用することもできます。これにより、SageMaker Processing に限らず、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) のようなAWSコンテナサービス、あるいはオンプレミスであっても、どんなコードも実行できるという柔軟性が得られます。まず、一般的な最適化パッケージとソルバーを含んだ Docker イメージをビルドし、以下の3つの最適化例題を解きます。 物流ネットワークを通じて商品を出荷するコストを最小化する 病院における看護師のシフトをスケジューリングする アポロ11号の月着陸船を最小の燃料で着陸させる軌道を求める それぞれの例題を、対応するソルバーを使用して解きます。おおまかには以下のステップに沿って各例題を解決します（こちらの ノートブック を参照）。 最適化ソルバー（GLPK や CBC など）に対応する Python インターフェース（Pyomo や PuLP など）を含む Docker コンテナのイメージをビルドする。 Amazon Elastic Container Registry (Amazon ECR) のリポジトリにビルドしたコンテナイメージをプッシュする。 SageMaker Python SDKを使用して（ノートブックなどから）Amazon ECRの Docker イメージを指定し、実際の最適化問題のコードを含むPythonファイルを送信します。 ノートブックまたは Amazon CloudWatch Logs でログを監視し、指定した Amazon Simple Storage Service （Amazon S3）の出力フォルダで結果を取得します。 以下にこの処理の全体像を図解します。 それでは始めましょう。 DockerコンテナのビルドとECRへのプッシュ まずは以下のような Docker ファイルを作成します。 FROM continuumio/anaconda3 RUN pip install boto3 pandas scikit-learn pulp pyomo inspyred ortools scipy deap RUN conda install -c conda-forge ipopt coincbc glpk ENV PYTHONUNBUFFERED=TRUE ENTRYPOINT ["python"] このコードでは、ソルバーにアクセスする Python インタフェースをインストールしています。ソルバーとは PuLP や Pyomo、Inspyred、OR-Tools、Scipy、DEAP のようなソフトウェアです。これらソルバーについてのより詳細な情報は、この記事の最後にある 参考情報 のセクションを参考にしてください。 以下のコードをノートブックから実行することで、コンテナイメージがビルドされ、Amazon ECR にプッシュされます。 import boto3 account_id = boto3.client('sts').get_caller_identity().get('Account') ecr_repository = 'sagemaker-opt-container' tag = ':latest' processing_repository_uri = '{}.dkr.ecr.{}.amazonaws.com/{}'.format(account_id, region, ecr_repository + tag) # Create ECR repository and push docker image !docker build -t $ecr_repository docker !$(aws ecr get-login --region $region --registry-ids $account_id --no-include-email) !aws ecr create-repository --repository-name $ecr_repository !docker tag {ecr_repository + tag} $processing_repository_uri !docker push $processing_repository_uri 上記のコードを実行した結果、以下のような出力が得られます（出力結果はサンプルであるため実行環境によって異なる点にご注意ください）。 Sending build context to Docker daemon 2.048kB Step 1/5 : FROM continuumio/anaconda3 ---> bbf09a95b565 Step 2/5 : RUN pip install boto3 pandas scikit-learn pulp pyomo inspyred ortools scipy deap ---> Using cache ---> 90655e74a46d Step 3/5 : RUN conda install -c conda-forge ipopt coincbc glpk ---> Using cache ---> d61d5542b339 Step 4/5 : ENV PYTHONUNBUFFERED=TRUE ---> Using cache ---> 56636836f8ae Step 5/5 : ENTRYPOINT ["python"] ---> Using cache ---> f3e5b0f6e957 Successfully built f3e5b0f6e957 Successfully tagged sagemaker-opt-container:latest WARNING! Using --password via the CLI is insecure. Use --password-stdin. WARNING! Your password will be stored unencrypted in /home/ec2-user/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded { "repository": { "repositoryArn": "arn:aws:ecr:us-east-2:xxxxxxxxxxxx:repository/sagemaker-opt-container", "registryId": "xxxxxxxxxxxx", "repositoryName": "sagemaker-opt-container", "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/sagemaker-opt-container", "createdAt": 1691281443.0, "imageTagMutability": "MUTABLE", "imageScanningConfiguration": { "scanOnPush": false }, "encryptionConfiguration": { "encryptionType": "AES256" } } } The push refers to repository [xxxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/sagemaker-opt-container] 689828f5: Preparing 7ca1d711: Preparing 8bbb3a9d: Preparing 8bbb3a9d: Pushing 2.302GB/4.828GBPushing 1.843GB/4.828GB 8bbb3a9d: Pushed 4.954GB/4.828GBPushing 2.811GB/4.828GBPushing 3.629GB/4.828GBPushing 3.851GB/4.828GBPushing 3.973GB/4.828GBPushing 4.42GB/4.828GBPushing 4.437GB/4.828GBPushing 4.531GB/4.828GBlatest: digest: sha256:428c97609616197615e370da1f78b3aefaebd9ae7ac7739bad0ecb7849512cd1 size: 1169 SageMaker Python SDKによるジョブの実行 まず、以下のように SageMaker Processing ScriptProcessor を初期化します。 script_processor = ScriptProcessor(command=['python'], image_uri=processing_repository_uri, role=role, instance_count=1, instance_type='ml.m5.xlarge') そして、スクリプトファイル(この記事では“preprocessing.py”というファイル名で作成します)を記述し、以下のように SageMaker の Processingジョブを実行します。 from sagemaker.processing import ProcessingInput, ProcessingOutput script_processor.run(code='preprocessing.py', outputs=[ProcessingOutput(output_name='data', source='/opt/ml/processing/data')]) script_processor_job_description = script_processor.jobs[-1].describe() print(script_processor_job_description) 例題1: 最小のコストで商品を配送する流通ネットワークを選択する オハイオ州に拠点を置く鋼鉄製造会社であるAmerican Steel社は、ヤングスタウンとピッツバーグにある2つの製鉄所で鋼鉄を生産しています。同社は地域倉庫と現場倉庫で構成される流通ネットワークを通じて、完成品の鋼鉄を小売り顧客に供給しています。 このネットワークでは、American Steel社の2つの製鉄所ヤングスタウン（ノード1）とピッツバーグ（ノード2）で製造された鋼鉄が、現場倉庫であるオールバニ、ヒューストン、テンペ、ゲーリー（ノード6、7、8、9）へ出荷されます。ただしその途中で、シンシナティ、カンザスシティ、シカゴ（ノード3、4、5）の3つの地域倉庫を経由します。なお、一部の現場倉庫へは製鉄所から直接製品が供給されることもあります。 以下の表は、それぞれの都市間で輸送可能な鋼鉄の最小および最大量と、1,000トンあたり1ヶ月の鋼鉄の輸送コストを示しています。例えば、ヤングスタウンからカンザスシティへの出荷は鉄道会社によって行われますが、最小出荷量が1,000トン/月の契約を結んでいます。ただし、鉄道会社の車両数の制限により1ヶ月に5,000トン以上を出荷することができません。 発地 着地 コスト 最小輸送量/月 最大輸送量/月 Youngstown Albany 500 – 1000 Youngstown Cincinnati 350 – 3000 Youngstown Kansas City 450 1000 5000 Youngstown Chicago 375 – 5000 Pittsburgh Cincinnati 350 – 2000 Pittsburgh Kansas City 450 2000 3000 Pittsburgh Chicago 400 – 4000 Pittsburgh Gary 450 – 2000 Cincinnati Albany 350 1000 5000 Cincinnati Houston 550 – 6000 Kansas City Houston 375 – 4000 Kansas City Tempe 650 – 4000 Chicago Tempe 600 – 2000 Chicago Gary 120 – 4000 一般的な転送問題と同様、American Steel社の目的はネットワークを通じて商品を出荷するコストを最小限にすることです。 本例題では、次の流入保存制約に従う必要があります。製品を製造する”製鉄所“には「供給」が定義されており、ここから流出する商品は「供給」量以下である必要があります。また、消費地に近い”現場倉庫“には「需要」が定義されており、「需要」量以上の商品が流入される必要があります。また、各ノードへの流入量は流出量以上である必要があります。 この問題は以下のようにコード化されます。 %%writefile preprocessing.py import argparse import os import warnings """ The American Steel Problem for the PuLP Modeller Authors: Antony Phillips, Dr Stuart Mitchell 2007 """ # Import PuLP modeller functions from pulp import * # List of all the nodes Nodes = ["Youngstown", "Pittsburgh", "Cincinatti", "Kansas City", "Chicago", "Albany", "Houston", "Tempe", "Gary"] nodeData = {# NODE Supply Demand "Youngstown": [10000,0], "Pittsburgh": [15000,0], "Cincinatti": [0,0], "Kansas City": [0,0], "Chicago": [0,0], "Albany": [0,3000], "Houston": [0,7000], "Tempe": [0,4000], "Gary": [0,6000]} # List of all the arcs Arcs = [("Youngstown","Albany"), ("Youngstown","Cincinatti"), ("Youngstown","Kansas City"), ("Youngstown","Chicago"), ("Pittsburgh","Cincinatti"), ("Pittsburgh","Kansas City"), ("Pittsburgh","Chicago"), ("Pittsburgh","Gary"), ("Cincinatti","Albany"), ("Cincinatti","Houston"), ("Kansas City","Houston"), ("Kansas City","Tempe"), ("Chicago","Tempe"), ("Chicago","Gary")] arcData = { # ARC Cost Min Max ("Youngstown","Albany"): [0.5,0,1000], ("Youngstown","Cincinatti"): [0.35,0,3000], ("Youngstown","Kansas City"): [0.45,1000,5000], ("Youngstown","Chicago"): [0.375,0,5000], ("Pittsburgh","Cincinatti"): [0.35,0,2000], ("Pittsburgh","Kansas City"): [0.45,2000,3000], ("Pittsburgh","Chicago"): [0.4,0,4000], ("Pittsburgh","Gary"): [0.45,0,2000], ("Cincinatti","Albany"): [0.35,1000,5000], ("Cincinatti","Houston"): [0.55,0,6000], ("Kansas City","Houston"): [0.375,0,4000], ("Kansas City","Tempe"): [0.65,0,4000], ("Chicago","Tempe"): [0.6,0,2000], ("Chicago","Gary"): [0.12,0,4000]} # Splits the dictionaries to be more understandable (supply, demand) = splitDict(nodeData) (costs, mins, maxs) = splitDict(arcData) # Creates the boundless Variables as Integers vars = LpVariable.dicts("Route",Arcs,None,None,LpInteger) # Creates the upper and lower bounds on the variables for a in Arcs: vars[a].bounds(mins[a], maxs[a]) # Creates the 'prob' variable to contain the problem data prob = LpProblem("American Steel Problem",LpMinimize) # Creates the objective function prob += lpSum([vars[a]* costs[a] for a in Arcs]), "Total Cost of Transport" # Creates all problem constraints - this ensures the amount going into each node is at least equal to the amount leaving for n in Nodes: prob += (supply[n]+ lpSum([vars[(i,j)] for (i,j) in Arcs if j == n]) >= demand[n]+ lpSum([vars[(i,j)] for (i,j) in Arcs if i == n])), "Steel Flow Conservation in Node %s"%n # The problem data is written to an .lp file prob.writeLP('/opt/ml/processing/data/' + 'AmericanSteelProblem.lp') # The problem is solved using PuLP's choice of Solver prob.solve() # The status of the solution is printed to the screen print("Status:", LpStatus[prob.status]) # Each of the variables is printed with it's resolved optimum value for v in prob.variables(): print(v.name, "=", v.varValue) # The optimised objective function value is printed to the screen print("Total Cost of Transportation = ", value(prob.objective)) この例題を PuLP とそのデフォルトのソルバーである CBC を script_processor.run で実行します。この最適化ジョブは以下のログを出力します。 Status: Optimal Route_('Chicago',_'Gary') = 4000.0 Route_('Chicago',_'Tempe') = 2000.0 Route_('Cincinatti',_'Albany') = 2000.0 Route_('Cincinatti',_'Houston') = 3000.0 Route_('Kansas_City',_'Houston') = 4000.0 Route_('Kansas_City',_'Tempe') = 2000.0 Route_('Pittsburgh',_'Chicago') = 3000.0 Route_('Pittsburgh',_'Cincinatti') = 2000.0 Route_('Pittsburgh',_'Gary') = 2000.0 Route_('Pittsburgh',_'Kansas_City') = 3000.0 Route_('Youngstown',_'Albany') = 1000.0 Route_('Youngstown',_'Chicago') = 3000.0 Route_('Youngstown',_'Cincinatti') = 3000.0 Route_('Youngstown',_'Kansas_City') = 3000.0 Total Cost of Transportation = 15005.0 例題2: 病院における看護師のシフトをスケジューリングする（ナーススケジューリング） この例題では、4人の看護師の3日間の勤務スケジュールを作成します。ただし、勤務表の作成にあたっては以下の条件を満たす必要があります。 1日のスケジュールは 8 時間の 3 つのシフトで構成されます。 1日の中で 1 人の看護師が割り当てられるシフトは1つです。複数のシフトを勤務することはできません。 各看護師は 3 日間の期間中に少なくとも 2 つのシフトに割り当てられます。 このスケジューリング問題についてさらに詳しい情報は こちら をご参照ください。 この例題は以下のようにコード化されます。 %%writefile preprocessing.py from __future__ import print_function from ortools.sat.python import cp_model class NursesPartialSolutionPrinter(cp_model.CpSolverSolutionCallback): """Print intermediate solutions.""" def __init__(self, shifts, num_nurses, num_days, num_shifts, sols): cp_model.CpSolverSolutionCallback.__init__(self) self._shifts = shifts self._num_nurses = num_nurses self._num_days = num_days self._num_shifts = num_shifts self._solutions = set(sols) self._solution_count = 0 def on_solution_callback(self): if self._solution_count in self._solutions: print('Solution %i' % self._solution_count) for d in range(self._num_days): print('Day %i' % d) for n in range(self._num_nurses): is_working = False for s in range(self._num_shifts): if self.Value(self._shifts[(n, d, s)]): is_working = True print(' Nurse %i works shift %i' % (n, s)) if not is_working: print(' Nurse {} does not work'.format(n)) print() self._solution_count += 1 def solution_count(self): return self._solution_count def main(): # Data. num_nurses = 4 num_shifts = 3 num_days = 3 all_nurses = range(num_nurses) all_shifts = range(num_shifts) all_days = range(num_days) # Creates the model. model = cp_model.CpModel() # Creates shift variables. # shifts[(n, d, s)]: nurse 'n' works shift 's' on day 'd'. shifts = {} for n in all_nurses: for d in all_days: for s in all_shifts: shifts[(n, d, s)] = model.NewBoolVar('shift_n%id%is%i' % (n, d, s)) # Each shift is assigned to exactly one nurse in the schedule period. for d in all_days: for s in all_shifts: model.Add(sum(shifts[(n, d, s)] for n in all_nurses) == 1) # Each nurse works at most one shift per day. for n in all_nurses: for d in all_days: model.Add(sum(shifts[(n, d, s)] for s in all_shifts) <= 1) # min_shifts_per_nurse is the largest integer such that every nurse # can be assigned at least that many shifts. If the number of nurses doesn't # divide the total number of shifts over the schedule period, # some nurses have to work one more shift, for a total of # min_shifts_per_nurse + 1. min_shifts_per_nurse = (num_shifts * num_days) // num_nurses max_shifts_per_nurse = min_shifts_per_nurse + 1 for n in all_nurses: num_shifts_worked = sum( shifts[(n, d, s)] for d in all_days for s in all_shifts) model.Add(min_shifts_per_nurse <= num_shifts_worked) model.Add(num_shifts_worked <= max_shifts_per_nurse) # Creates the solver and solve. solver = cp_model.CpSolver() solver.parameters.linearization_level = 0 # Display the first five solutions. a_few_solutions = range(5) solution_printer = NursesPartialSolutionPrinter(shifts, num_nurses, num_days, num_shifts, a_few_solutions) solver.SearchForAllSolutions(model, solution_printer) # Statistics. print() print('Statistics') print(' - conflicts : %i' % solver.NumConflicts()) print(' - branches : %i' % solver.NumBranches()) print(' - wall time : %f s' % solver.WallTime()) print(' - solutions found : %i' % solution_printer.solution_count()) if __name__ == '__main__': main() この例題を OR-Tools とソルバーのCP-SATを使うよう、 script_processor.run で実行します。この最適化ジョブは以下のログを出力します。 Solution 0 Day 0 Nurse 0 does not work Nurse 1 works shift 0 Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 2 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 1 Day 0 Nurse 0 works shift 0 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 does not work Nurse 1 works shift 2 Nurse 2 works shift 1 Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 2 Day 0 Nurse 0 works shift 0 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 1 Nurse 1 works shift 2 Nurse 2 does not work Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 3 Day 0 Nurse 0 works shift 0 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 does not work Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 4 Day 0 Nurse 0 does not work Nurse 1 works shift 0 Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 does not work Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Statistics - conflicts : 37 - branches : 41231 - wall time : 0.367511 s - solutions found : 5184 例題3: アポロ11号の月着陸船を最小の燃料で着陸させる軌道を求める この例題では、 Pyomo によるシンプルな宇宙ロケットのモデルを使用して、月面着陸のための制御ポリシーを計算します。 ここで使用しているパラメータは、1969年7月20日のアポロ11号月着陸船の月への降下時のものです。高度 h で垂直飛行中の質量 m のロケットの場合、運動量バランスにより次のモデルが得られます。 このモデルでは、 u は推進剤の質量流量、ve はロケットに対する排気の速度を表しています。モデリングと制御のこの最初の試みでは、燃料の燃焼によるロケットの質量の変化を無視します。 燃料消費量は以下の式で算出されます。 さらに以下で燃料消費量が最小となるような軌道を求めます。 この例題は以下のようにコード化されます。 %%writefile preprocessing.py import numpy as np from pyomo.environ import * from pyomo.dae import * #Define constants ... # lunar module m_ascent_dry = 2445.0 # kg mass of ascent stage without fuel m_ascent_fuel = 2376.0 # kg mass of ascent stage fuel m_descent_dry = 2034.0 # kg mass of descent stage without fuel m_descent_fuel = 8248.0 # kg mass of descent stage fuel m_fuel = m_descent_fuel m_dry = m_ascent_dry + m_ascent_fuel + m_descent_dry m_total = m_dry + m_fuel # descent engine characteristics v_exhaust = 3050.0 # m/s u_max = 45050.0/v_exhaust # 45050 newtons / exhaust velocity # landing mission specifications h_initial = 100000.0 # meters v_initial = 1520 # orbital velocity m/s g = 1.62 # m/s**2 m = ConcreteModel() m.t = ContinuousSet(bounds=(0, 1)) m.h = Var(m.t) m.u = Var(m.t, bounds=(0, u_max)) m.T = Var(domain=NonNegativeReals) m.v = DerivativeVar(m.h, wrt=m.t) m.a = DerivativeVar(m.v, wrt=m.t) m.fuel = Integral(m.t, wrt=m.t, rule = lambda m, t: m.u[t]*m.T) m.obj = Objective(expr=m.fuel, sense=minimize) m.ode1 = Constraint(m.t, rule = lambda m, t: m_total*m.a[t]/m.T**2 == -m_total*g + v_exhaust*m.u[t]) m.h[0].fix(h_initial) m.v[0].fix(-v_initial) m.h[1].fix(0) # land on surface m.v[1].fix(0) # soft landing def solve(m): TransformationFactory('dae.finite_difference').apply_to(m, nfe=50, scheme='FORWARD') SolverFactory('ipopt').solve(m, tee=True) solve(m) この連続時間の軌道最適化問題を解決するため、 Pyomo と非線形最適化ソルバー Ipopt を使用します。 実行結果は以下のように ScriptProcessor.run のログに出力されます。 Ipopt 3.12.13: ****************************************************************************** This program contains Ipopt, a library for large-scale nonlinear optimization. Ipopt is released as open source code under the Eclipse Public License (EPL). For more information visit http://projects.coin-or.org/Ipopt ****************************************************************************** This is Ipopt version 3.12.13, running with linear solver mumps. NOTE: Other linear solvers might be more efficient (see Ipopt documentation). Number of nonzeros in equality constraint Jacobian...: 448 Number of nonzeros in inequality constraint Jacobian.: 0 Number of nonzeros in Lagrangian Hessian.............: 154 Error in an AMPL evaluation. Run with "halt_on_ampl_error yes" to see details. Error evaluating Jacobian of equality constraints at user provided starting point. No scaling factors for equality constraints computed! Total number of variables............................: 201 variables with only lower bounds: 1 variables with lower and upper bounds: 51 variables with only upper bounds: 0 Total number of equality constraints.................: 151 Total number of inequality constraints...............: 0 inequality constraints with only lower bounds: 0 inequality constraints with lower and upper bounds: 0 inequality constraints with only upper bounds: 0 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 0 9.9999800e-05 5.00e+06 9.90e-01 -1.0 0.00e+00 - 0.00e+00 0.00e+00 0 1r 9.9999800e-05 5.00e+06 9.99e+02 6.7 0.00e+00 - 0.00e+00 4.29e-14R 4 2r 2.1397987e+02 5.00e+06 4.78e+08 6.7 2.14e+05 - 1.00e+00 6.83e-05f 1 3r 2.1342176e+02 5.00e+06 1.36e+08 3.2 4.37e+04 - 7.16e-01 6.16e-01f 1 4r 1.7048263e+02 4.99e+06 4.67e+07 3.2 1.60e+04 - 9.85e-01 4.16e-01f 1 5r 1.5143799e+02 4.99e+06 2.50e+07 3.2 3.57e+03 - 5.88e-01 7.62e-01f 1 6r 1.3041897e+02 4.99e+06 2.08e+07 3.2 1.89e+03 - 2.75e-01 8.14e-01f 1 7r 1.1452223e+02 4.99e+06 3.17e+04 3.2 1.97e+03 - 9.78e-01 8.18e-01f 1 8r 1.1168709e+02 4.99e+06 2.72e+05 3.2 3.36e-01 4.0 9.78e-01 1.00e+00f 1 9r 1.0774716e+02 4.99e+06 1.66e+05 3.2 4.28e+03 - 9.36e-01 9.70e-02f 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 10r 8.7784873e+01 5.00e+06 5.08e+04 3.2 3.69e+03 - 8.74e-01 7.24e-01f 1 11r 7.9008215e+01 5.00e+06 1.88e+04 2.5 1.09e+03 - 1.22e-01 8.35e-01h 1 12r 1.1960245e+02 5.00e+06 4.34e+03 2.5 1.81e+03 - 6.76e-01 1.00e+00f 1 13r 1.2344166e+02 5.00e+06 1.35e+03 1.8 1.66e+02 - 8.23e-01 1.00e+00f 1 14r 2.0065756e+02 4.99e+06 6.85e+02 1.1 4.28e+03 - 4.26e-01 1.00e+00f 1 15r 3.0115879e+02 4.99e+06 4.78e+01 1.1 9.69e+03 - 7.64e-01 1.00e+00f 1 16r 3.0355974e+02 4.99e+06 5.30e+00 1.1 4.92e+00 - 1.00e+00 1.00e+00f 1 17r 3.0555655e+02 4.99e+06 6.83e+02 0.4 7.49e+00 - 1.00e+00 1.00e+00f 1 18r 4.4494526e+02 4.97e+06 2.28e+01 0.4 2.17e+04 - 8.05e-01 1.00e+00f 1 19r 3.9588385e+02 4.97e+06 3.77e+00 0.4 4.73e+00 - 1.00e+00 1.00e+00f 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 20r 4.0158949e+02 4.97e+06 7.79e-02 0.4 5.70e-01 - 1.00e+00 1.00e+00h 1 21r 4.0076180e+02 4.97e+06 9.88e+02 -1.0 1.80e+00 - 1.00e+00 1.00e+00f 1 22r 5.4964501e+02 4.95e+06 7.59e+02 -1.0 1.57e+05 - 2.48e-01 2.32e-01f 1 23r 5.5056601e+02 4.95e+06 7.57e+02 -1.0 1.21e+05 - 1.00e+00 3.02e-03f 1 24r 5.5057553e+02 4.95e+06 7.57e+02 -1.0 1.09e+05 - 8.13e-01 3.34e-05f 1 25r 5.5898777e+02 4.95e+06 7.00e+02 -1.0 3.82e+04 - 1.00e+00 7.48e-02f 1 26r 6.0274077e+02 4.96e+06 3.93e+02 -1.0 3.53e+04 - 1.00e+00 4.39e-01f 1 27r 6.0301192e+02 4.96e+06 3.90e+02 -1.0 1.98e+04 - 1.00e+00 7.83e-03f 1 28r 6.0301418e+02 4.96e+06 3.89e+02 -1.0 1.61e+04 - 1.00e+00 9.62e-05f 1 29r 5.9834909e+02 4.96e+06 3.71e+02 -1.0 3.63e+03 - 1.00e+00 1.85e-01f 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 30r 5.7601446e+02 4.95e+06 1.67e+00 -1.0 2.96e+03 - 1.00e+00 1.00e+00f 1 31r 5.6977301e+02 4.95e+06 6.41e-02 -1.0 1.22e+00 - 1.00e+00 1.00e+00h 1 32r 5.7024128e+02 4.95e+06 9.05e-05 -1.0 4.89e-02 - 1.00e+00 1.00e+00h 1 33r 5.6989454e+02 4.95e+06 6.84e+02 -2.5 9.30e-02 - 1.00e+00 1.00e+00f 1 34r 5.7613459e+02 4.94e+06 5.38e+02 -2.5 5.65e+04 - 4.67e-01 2.13e-01f 1 35r 5.7617358e+02 4.94e+06 5.37e+02 -2.5 4.45e+04 - 1.00e+00 9.52e-04f 1 36r 6.6264177e+02 4.90e+06 3.78e+01 -2.5 4.45e+04 - 6.62e-01 9.30e-01f 1 37r 7.5101828e+02 4.90e+06 7.59e+01 -2.5 3.12e+03 - 1.25e-02 1.00e+00f 1 38r 7.5705424e+02 4.90e+06 8.60e-02 -2.5 7.04e-01 - 1.00e+00 1.00e+00h 1 39r 7.5713736e+02 4.90e+06 2.85e-05 -2.5 9.02e-03 - 1.00e+00 1.00e+00h 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 40r 7.5713093e+02 4.90e+06 4.90e+02 -5.7 6.76e-03 - 1.00e+00 9.99e-01f 1 41r 1.0909809e+03 4.78e+06 4.67e+02 -5.7 2.54e+06 - 6.15e-02 4.62e-02f 1 42r 1.0909867e+03 4.78e+06 4.67e+02 -5.7 2.42e+06 - 1.00e+00 9.55e-07f 1 43r 1.5672936e+03 4.59e+06 8.15e+03 -5.7 2.42e+06 - 3.36e-03 7.69e-02f 1 44r 1.7598365e+03 4.50e+06 8.17e+03 -5.7 2.24e+06 - 4.43e-08 4.23e-02f 1 45r 5.7264420e+03 2.36e+06 4.60e+03 -5.7 2.14e+06 - 7.07e-02 1.00e+00f 1 46 4.3546591e+03 2.35e+06 1.50e+01 -1.0 2.51e+08 - 3.52e-03 2.97e-03f 1 47 3.7700543e+03 2.16e+06 1.94e+01 -1.0 2.87e+06 - 3.27e-01 8.10e-02f 1 48 3.9963720e+03 1.02e+06 7.97e+00 -1.0 3.70e+05 - 3.47e-01 5.26e-01h 1 49 4.0601733e+03 5.28e+05 5.09e+00 -1.0 1.57e+06 - 5.24e-03 4.85e-01h 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 50 4.0596593e+03 5.27e+05 3.53e+00 -1.0 4.32e+06 - 7.60e-01 1.81e-03h 1 51 4.1577305e+03 9.40e+04 7.32e-01 -1.0 4.01e+05 - 9.09e-01 8.22e-01h 1 52 4.1754490e+03 1.27e+01 4.74e-02 -1.0 5.08e+04 - 8.32e-01 1.00e+00h 1 53 4.1752565e+03 7.78e-02 8.68e-07 -1.0 1.49e+04 - 1.00e+00 1.00e+00h 1 54 4.1704409e+03 1.60e+00 3.18e-05 -2.5 1.16e+04 - 1.00e+00 1.00e+00f 1 55 4.1704236e+03 6.98e-04 2.83e-08 -2.5 1.41e+03 - 1.00e+00 1.00e+00h 1 56 4.1702897e+03 1.15e-03 2.31e-08 -3.8 2.98e+02 - 1.00e+00 1.00e+00f 1 57 4.1702823e+03 3.63e-06 5.75e-11 -5.7 1.67e+01 - 1.00e+00 1.00e+00h 1 58 4.1702822e+03 1.28e-09 1.62e-14 -8.6 2.04e-01 - 1.00e+00 1.00e+00h 1 Number of Iterations....: 58 (scaled) (unscaled) Objective...............: 4.1702822027548118e+03 4.1702822027548118e+03 Dual infeasibility......: 1.6235231869939369e-14 1.6235231869939369e-14 Constraint violation....: 1.2805685400962830e-09 1.2805685400962830e-09 Complementarity.........: 2.5079038009909822e-09 2.5079038009909822e-09 Overall NLP error.......: 2.5079038009909822e-09 2.5079038009909822e-09 Number of objective function evaluations = 63 Number of objective gradient evaluations = 16 Number of equality constraint evaluations = 63 Number of inequality constraint evaluations = 0 Number of equality constraint Jacobian evaluations = 60 Number of inequality constraint Jacobian evaluations = 0 Number of Lagrangian Hessian evaluations = 58 Total CPU secs in IPOPT (w/o function evaluations) = 0.682 Total CPU secs in NLP function evaluations = 0.002 EXIT: Optimal Solution Found. まとめ この記事では、SageMaker Processing を使用して数値最適化問題を解決するために、様々なフロントエンドツールやソルバーを試しました。さらに、Scipy.optimize やDEAP、Inspyred を使用して他の例題を試してみてください。自社におけるビジネス問題を SageMaker Processing を使用して解決する際には、次のセクションの参考文献や他の例題を参照してください。もし現在、機械学習プロジェクトで SageMaker API を使用している場合、最適化を実行するために SageMaker Processing を使用することは、シンプルな方式です。ただし、最適化問題の解決のためにこれらのオープンソースライブラリを実行するには、Lambda や Fargate などの他のAWSサービスも検討することをおすすめします。また、この記事で使用したオープンソースライブラリは最小限のサポートで提供される一方、CPLX や Gurobi などの商用ライブラリは常に高いパフォーマンスを追求しており、通常はプレミアムサポートも提供されています。 参考情報 Training APIs: Processing https://pypi.org/project/PuLP/ OR-Tools: Get Started Guides Pyomo Documentation 5.7.2 inspyred: Recipes Optimization and root finding (scipy.optimize) DEAP documentation https://www.gurobi.com/ CPLEX optimzer OR Tools code license PuLP code license Pyomo code license 著者について Shreyas Subramanian は AI/ML specialist Solutions Architect です。機械学習を使ってAWSのお客様の課題解決に取り組んでいます。 この記事の翻訳はソリューションアーキテクトの横山誠が担当しました。原文は こちら です。

人気の React フレームワークである Next.js は、開発者がモダンな Web アプリケーションを構築する方法を変えました。Next.js は、Static Site Generation (SSG) や Server Side Rendering (SSR) といった強力な機能を提供し、アプリケーションのパフォーマンスとユーザー体験を最適化します。本記事では、SSG と SSR の主な違い、利点、いつどちらかを選択するか、それぞれのアプローチで AWS Amplify を使ってデプロイする方法を説明します。Amplify は、フロントエンドの Web やモバイル開発者が AWS 上でフルスタックのアプリケーションを簡単に構築、ホストできるようにする包括的なソリューションです。 Static Site Generation (SSG) とは？ Static Site Generation は、ビルド時に静的な HTML ファイルを生成します。アプリをビルドするたびに、全てのページが作成されます。ユーザーが Web サイトにアクセスするとこれらのファイルがユーザーに提供され、サーバーは余計な作業をする必要がなくなります。このアプローチは、ブログやドキュメントサイトのような、頻繁に変更されないコンテンツを持つ Web サイトに適しています。 SSG の利点 速度 ： レンダリングされた HTML ファイルが直接提供されるため、ロード時間が短縮されます。 スケーラビリティ ： 静的ファイルは CDN によって簡単に提供され、アプリケーションの能力を向上させ、グローバルなトラフィックを処理することができます。 Server Side Rendering (SSR) とは？ Server Side Rendering は、ユーザーがリクエストしたときに、サーバー上で各ページを生成します。SSR では、ページを事前にレンダリングするサーバーがあります。それは、変数を差し込むテンプレートのようなもので、サーバーはすべてのレンダリングを処理します。。これはリクエスト時に発生するので、ユーザがページをリクエストすると、サーバ側でレンダリングされたページを取得します。このレンダリングはすべてサーバーサイドで行われ、ブラウザで実行されることはありません。そのため、ページがすでにサーバでレンダリングされてクライアントに提供されるのを待っている SSG とは異なり、SSR はリクエストを受け取ったときにサーバでページをレンダリングします。SSR は、e コマースサイトやソーシャルメディアプラットフォームのような、頻繁に変更される動的またはパーソナライズされたコンテンツを持つ Web サイトに最適です。 SSR の利点 一貫したユーザー体験 ： ユーザーは、その場で生成された最新のコンテンツを見ることができ、常に最新の情報を得ることができます。 パーソナライゼーション ： SSR は、ユーザーの嗜好やその他の動的なデータに基づいて、ユニークなコンテンツを提供することができます。 SSG と SSR のどちらを選ぶべきか コンテンツは頻繁に更新されていますか？コンテンツが頻繁に変更されない場合は、パフォーマンスとスケーラビリティを向上させるために SSG を選択する方が良いでしょう。動的なコンテンツの場合、SSR はユーザーに最新の情報を提供します。 あなたの Web サイトはインタラクティブなユーザー体験を提供しますか？ SSR Web サイトはインタラクティブなユーザー体験を提供しますが、SSG Web サイトは CSR や SSR と組み合わされていない限り、動的コンテンツをほとんど含まない静的なサイトです。 ビルド時とランタイムのどちらにレンダリングコストをかけたいですか？ ビルド時にレンダリングコストを発生させたい場合は SSG を、ランタイムに発生させたい場合は SSR を選択してください。 SEO 対策は必要ですか？ SEO のための SSR と SSG の主な違いは、サーバーの応答時間だけです。 ビジネス要件を考慮する SSG は優れた SEO 効果を提供しますが、SSRは 検索ランキングに重要な動的コンテンツとパーソナライゼーションをより良くサポートします。 ユーザー体験 ： ユーザーがリアルタイムのデータやパーソナライズされたコンテンツを必要としているかどうかを検討しましょう。もし必要であれば、SSR の方がよいでしょう。そうでない場合は、SSG の方がより低いサーバー要件でより高速な体験を提供します。 最新データ ： SSRページはユーザーからのリクエストごとにサーバー上で生成されるため、常に最新のデータを表示します。すべてのリクエストで、常に最新/最新の情報を得ることができます。 Next.js の SSG と SSR： 正しいレンダリングアプローチの選択 この記事では、Next.jsの2つのレンダリングアプローチ、SSGとSSRについて説明します。また、あなたのアプリケーションに最適なレンダリングアプローチを判断するためのコードベース例も紹介します。 Next.js は、n 個の動的生成ルートを生成する機能をサポートしています。コードベースの例では、過去数日間の Hacker News のトップ投稿を 100 件取得し、それらの ID をホームページにレンダリングします。 クリックすると、それぞれのページに投稿の詳細が表示されます。これらの各ページはまた、 pages/[hackerNewsArticleId] のようなルートを持ちます。あなたは、そのテンプレートページが slug 指定で pages フォルダで利用可能であることを見ることができます。 この静的に生成されるパスのリストを定義するために getStaticProps と getStaticPaths の 2 つの Next.js 関数を使います。 getStaticProps は、ビルド時にページをプリレンダリングし、Hacker News API から投稿情報のリストを取得し、その情報を getStaticPaths と同様にコンポーネントの props に渡します。 2番目の関数である getStaticPaths は動的ルーティングに非常に重要です。 getStaticProps から ID のリストを受け取り、以下のようなパスオブジェクトのリストを作成します。 export async function getStaticPaths() { return { paths: [{ params: { id: '1' } }, { params: { id: '2' } }], fallback: false, // can also be true or 'blocking' } } Next.js はこのパスのリストを取り込み、それぞれのパラメータに対して新しいページを生成します。また、個々のページにルーティングするために、プライマリコンポーネントに Hacker News ID をインジェストしてレンダリングするようにしました。動的にレンダリングされたコンポーネントページに行くと、再び getStaticProps メソッドを呼び出して Hacker News の詳細エンドポイントを呼び出し、投稿のタイトルや投票数などを取得していることがわかります。これはコンパイル時のブログ記事のスナップショットであることに注意してください。 SSG のアプローチ GitHub リポジトリ から、SSG Next.js アプリを Amplify にデプロイする方法を説明します。まずは、以下をクリックして、このプロジェクトを自分の環境にデプロイしてください。Amplify でのデプロイとホスティングの詳細は こちら を確認してください。 Connect to GitHub を選択し、aws-amplify-console を認証します。 Deploy App ページで、 Create new role を選択します。 ロールを作成したら、 Deploy App ページで既存のロールをリフレッシュし、作成したばかりのロールを選択します。 Save and Deploy を選択します。 アプリのデプロイには 2 ～ 3 分かかります。ボックスが表示されたら、 Continue をクリックします。その後、Amplify アプリがプロビジョニング、ビルド、デプロイの各段階に進むのを確認できます。 デプロイが完了すると、そのドメインでホストされている Web サイトにアクセスできるようになります。 ドメインを選択すると、Amplify アプリに移動し、SSG Next.js アプリが表示されます。 SSR のアプローチ Next.js の Web アプリケーション を GitHub から直接 Amplify にデプロイする方法を見ていきましょう。 実は Amplify にデプロイするときに、すでに SSR ページをデプロイしています。Next.js のすごいところは、ビルド時に生成するページもあれば、SSR を利用して動的なデータをレンダリングするページもあることです。 特定のページで Server Side Rendering を使用するには、 getServerSideProps という非同期関数をエクスポートします。この関数は、リクエストごとにサーバーから呼び出されます。 ホストされているリンクで、 /ssr ルートに移動します(ie. https://main..amplifyapp.com/ssr). このようなページが表示されるはずです。 よくある問題 Next.js では、Create React App (CRA) や React Router といったライブラリを活用する、非常に人気のあるフロントエンド・フレームワークとは異なるパラダイム・シフトが必要です。 CRA は、React アプリケーションを作成するためのボイラープレート・プロジェクトを提供するスターターキットです。CRA は Client Side Rendering (CSR) を使用し、アプリケーションはブラウザでレンダリングされ、通常、ユーザーのインタラクションに基づいてネットワークリクエストを分割するのがベストプラクティスです。SSG と比較すると、すべてのデータを一度にロードしなければなりません。 Static Site Generation 大規模な静的 Web サイトでは、ビルドやデータ取得にかかる時間をすべて顧客に渡す代わりに、サイトがビルドされるのを何時間も待つことになるかもしれません。静的ページの数が 2 倍になるたびに、ビルド時間も 2 倍になります。 10,000 のアイテムがある e コマース・ Web サイトの場合、各アイテムのフェッチ／ビルドに約 1 秒かかるとすると、ビルドとデプロイに 3 時間近くかかることになります。 この場合、 Incremental Static Regeneration (ISR) が適しています。これによって Web サイト全体を再構築することなく変更を加えることができます。 データ・フェッチ 最近の Web 開発では、ユーザーの viewport (表示領域) を埋めるのに十分な API 呼び出しだけを行い、潜在的に後続のユーザーアクションのためのデータをプリフェッチすることがが推奨されることがよくあります。しかし、SSG では、 Web ページ全体と潜在的なユーザーのアクションをすべて入力するために必要なすべての API をコールする必要があります。 ページの更新 例えば、複数のセクションがあるブログのページなど、 Web サイトのあるページが頻繁に更新される場合、SSG はひとつのページに含まれる変更のために、サイト全体を頻繁にリビルドす必要があるかもしれません。 その結果、SSG ページはビルド時に HTTP ヘッダやクエリパラメータのようなリクエストに直接アクセスすることができません。もしこれらにアクセスしたければ、SSG に加えてカスタムミドルウェアを書かなければなりません。 Server Side Rendering レイテンシ 生成プロセスにおいて、外部 API からのデータ取得のように、最終的にページの読み込み速度に影響を与える外部要因があります。API のレスポンスが遅ければ、ページ生成の読み込み時間は遅くなります。また、SSR はリクエストごとにページを生成するので、SSG に比べて遅くなります。 SSR のページでキャッシュを有効にし、読み込み時間速度を改善するには、 getServerSideProps を呼び出すときに、追加の HTTP ヘッダ、Cache-Control を追加する必要があります。 こちら を参照してください。キャッシュについてもっと学びたい場合は、 こちら も参照ください。 スケーラビリティ SSR はリクエストごとにサーバーがフロントエンドを処理し生成する必要があり、Web サイトが複雑なページを持ち、処理するエンドクライアントが多い場合、スケーラビリティが低く、速度も遅くなります。 SSR の 動的 HTMLは静的な CDN (例：CloudFront) によってキャッシュされることができず、サーバーとの往復時間が長くなり、ページをリクエストしてからサーバーによって最初のバイトが読み込まれるまでの時間 (TTFB: Time to First Byte) が遅くなります。 SEO Google と Bing は、最新のレンダリングエンジンで同じChromium ベースのクローラーを活用すると発表しましたが、JavaScript は依然として検索エンジンがページを解析する能力を複雑にし、SEO ランクを下げる可能性があります。検索エンジンは JavaScript ファイルをダウンロードする必要があり、サイトの他の部分に移動する前にバンドル全体が読み込まれるのを待てない可能性があります。結局のところ、Google や Bing があなたのページをどのようにランク付けするかは不確実であり、クローラーを楽にすることは理にかなっていると言えるでしょう。 クリーンアップ Amplify アプリの削除 GitHub アプリの削除 まとめ SSG も SSR も、Next.js アプリケーションの種類によってそれぞれの利点があります。プロジェクトのコンテンツ頻度、SEO、ユーザー体験、開発の複雑さなどを理解することで、Next.js プロジェクトで SSG と SSR のどちらを使うべきか、十分な情報を得た上で決定することができます。最終的には、特定のユースケースと、パフォーマンス、スケーラビリティ、動的コンテンツのトレードオフ次第です。 まずは、 Amplify Hosting を利用して、ユーザー認証機能付きの Next.js 13 Web アプリを構築 してみてください。 著者について Alexa Perlov Alexa Perlov は、ニューヨークを拠点とするAmazon Web Services のソリューションアーキテクトです。メディアとエンターテインメントの戦略的アカウントのビジネス目標達成のために AWS を活用するサポートをしてます。技術トレーニングをリードし、幅広いクラウドドメインに焦点を当てたプロトタイプを開発しています。 Michael Tran Michael Tran は Amazon Web Services のプロトタイピングアクセラレーションチームのソリューションアーキテクトです。技術的なガイダンスを提供し、AWS 上で可能なアートを示すことで顧客のイノベーションを支援しています。専門は AI/ML 分野におけるプロトタイプの構築。 本記事は、 SSG vs SSR in Next.js Web Applications: Choosing the Right Rendering Approach を翻訳したものです。翻訳はソリューションアーキテクトの 稲田大陸 が担当しました。

はじめに AWS IoT Core を使ってモノのインターネット (IoT) デバイスのフリートを管理する際に、特定のデバイスやデバイスのセットを ID や能力に基づいて検索し発見する方法として、AWS IoT のモノのタイプの属性を使うことはデバイスの発見を容易にするために推奨される方法の一つです。 「モノ」とは、AWS IoT Core の IoT 対応デバイスのようなエンティティの論理的な名前です。モノのプロビジョニング中に、AWS IoT レジストリ内での識別と検索を容易にするために、検索可能な属性を付与することができます。 AWS IoT レジストリ からモノを検索したいのはどんな場合でしょうか? その質問に答えるために、Lighting-as-a-Service (LaaS) プロバイダまたはその顧客が（セルフサービスポータルを通じて）、既に設置されている照明から、特定の製品タイプ、モデル番号、ワット数、輝度、色、製造バッチがいくつあるかを特定する必要がある、コネクテッド照明のユースケースを考えてみましょう。 AWS IoT Core では、モノに検索可能な属性の数が 3 つまでという制限があり、追加の属性に基づいてデバイスを検索したいときには十分でない場合があります。本記事では、AWS IoT Core の モノのタイプ と AWS IoT Device Management の フリートインデックス の組み合わせを使って、この課題を軽減する方法を紹介します。 フリートインデックスにより、フリート管理者はデバイスフリートを整理、調査、トラブルシューティングすることができます。デバイスのグループに検索を実行し、状態、接続性、デバイス違反を含むデバイス属性のさまざまな組み合わせに基づくデバイスレコードの統計を集計できます。例えば、ある場所に設置されたあるモデルの電球のうち、現在何個が接続切断されていて、古いバージョンのファームウェアを実行しているか、といった情報を検索することができます。 前提条件 AWS IoT Core の デバイスプロビジョニング 機能と AWS IoT Device Management のフリートインデックス機能の基本的な理解が必要です。 チュートリアル それでは、検索不可能な属性をモノに追加する方法と、検索不可能な属性を使っていてもフリートインデックスを使って検索する方法を見てみましょう。 MyFirstThing というモノをプロビジョニングし、検索可能な属性を付けてみましょう。下図からわかるように、検索可能な属性は 3 つしか付与することができません。 このモノにさらに属性を追加するために、モノに「モノのタイプ」を付与することができます。 モノのタイプは、同じタイプに関連付けられたすべてのモノに共通する説明と構成情報を保存することを可能にします。これにより、レジストリ内のモノの管理が簡単になります。例えば、一つ一つの電球に個別に属性を割り当てる代わりに、LightBulb というモノのタイプを作成し、シリアル番号、光度、ワット数などの電球の属性を関連付けることができます。さらに、既存のモノのタイプを LightBulb に変更すれば、モノのタイプの属性を継承し、モノのタイプで定義された各属性の値を指定することができるようになります。 モノのタイプをモノに割り当てることはオプションですが、これを使うことで 47 の検索不可能な属性が追加可能となります。この関連付けにより、下図のように合計 50 の属性が使用可能になります。 本記事では、メーカー、シリアル番号、ワット数などの検索可能な属性を持つ LightBulb タイプを作成し、 MyFirstThing に割り当てました。また下図でわかるように、3 つの検索不可能な属性（色、ファームウェア・タイプ、輝度）を追加しました。 では、AWS CLI の list things コマンドを使って検索してみます。検索可能な属性で検索すると、LightBulb_1 がヒットします。 aws iot list-things --attribute-name "wattage" --attribute-value '40' { "things": [ { "thingName": "LightBulb_1", "thingTypeName": "LightBulb", "thingArn": "arn:aws:iot:ap-south-1:************:thing/LightBulb_1", "attributes": { "Color": "White", "Firmware_Type_Version": "Smart_LED.1.0", "Luminosity": "100", "manufacturer": "xyz_corp", "serialnumber": "123", "wattage": "40" }, "version": 5 } ] } しかし、検索不可能な属性で検索すると、モノのタイプで追加された属性は検索不可能であるため、コマンドは何も返しません。 aws iot list-things --attribute-name "Color" --attribute-value 'White' { "things": [] } そこで、AWS IoT Device Management のフリートインデックス機能が役に立ちます。 AWS IoT Device Management のフリートインデックス機能を使えば、AWS IoT レジストリ、AWS IoT デバイスシャドウ、AWS IoT への接続状態、AWS IoT Device Defender での違反といったソースからデバイスデータのインデックスを作成、検索、集約することができます。 フリートインデックス機能は、前述したような主要な機能を備えていますが、本記事ではモノのタイプの属性に基づくインデックス作成と検索にのみ焦点を当てます。 それでは、AWS IoT コンソールを使ってフリートインデックスを有効にしましょう（既に有効になっている場合はこのステップは飛ばしてください）。左のパネルから 設定 を選択し、 フリートのインデックス作成  までスクロールし、以下のように インデックス作成の管理 を選択します。 フリートインデックスの管理画面で、以下のようにスイッチを切り替えてフリートインデックスを有効化し、画面下部の 更新 を選択して設定を保存します。 前の画面に表示されている他のチェックボックスは、デバイスシャドウ、接続状態、および Device Defender の違反に基づくインデックス作成と検索を可能にしますが、これらはこの記事の範囲外であるためここでは選択しません。 フリートインデックスが有効化されたら、下図に示すように AWS IoT のモノの管理コンソールから  高度な検索 を選択します。 検索ボックスを使って、検索不可能な属性を検索します。例えば、color の値が white である場合、以下のように、一致する属性値を持つものが画面下部に検索結果として表示されます。 また、AWS CLI を使用して、検索不可能な属性 color の値が white であるデバイスに対して同様の検索を実行することもできます。 aws iot search-index –query-string ‘attributes.color=White’ { "things": [ { "thingName": "LightBulb_1", "thingId": "******************************", "thingTypeName": "LightBulb", "attributes": { "Color": "White", "Firmware_Type_Version": "Smart_LED.1.0", "Luminosity": "100", "manufacturer": "xyz_corp", "serialnumber": "123", "wattage": "40" } } ] } なお、AWS IoT Device Management のフリートインデックス作成は、管理者がデバイス群を整理、調査、トラブルシューティングできるようにするものであり、管理用途でのみ使用すべきことにご注意ください。 フリートインデックスと検索機能は、インデックスの更新と検索の実行数によって課金されます。詳しくは 価格ページ をご覧ください。また、制限とクォータについては こちら をご覧ください。 まとめ 本記事では、AWS IoT モノのタイプと AWS IoT Device Management のフリートインデックスを使ってデバイスの検索性を向上する方法を紹介した。モノのタイプを使用すると、モノに追加の属性（検索不可）を付与することができ、これらは検索不可の属性でありながら、フリートインデックス機能を使用することでこれらの属性が検索可能となります。 その他のAWS IoT Core 関連のリソースについては、 ウェブサイト をご覧ください。 この記事は Ankush Sharma によって書かれた How to improve device discoverability by unlocking 50 AWS IoT thing type attributes の日本語訳です。この記事はソリューションアーキテクトの中西貴大が翻訳しました。

このブログ記事は AWS offers new artificial intelligence, machine learning, and generative AI guides to plan your AI strategy を翻訳したものです。 人工知能 (AI) および機械学習 (ML) に関するブレイクスルーはこの数か月の間、毎日のように話題になっていますが、それには正当な理由があります。これらのテクノロジーの新たな進化や機能は、あらゆる分野や業界のお客様に新たなビジネスチャンスをもたらすものだからです。その一方、これらの技術の進化があまりにも高速であるため、各企業では、これらのブレイクスルーが自分たちにとって具体的に何を意味するのかを評価することが難しくなっています。 アマゾン ウェブ サービス (以下、AWS) では、長年にわたり、AI、ML、そして Generative AI (以下、生成系AI) へのアクセスと理解の民主化に投資してきました。 生成系 AI の最新開発に関する発表 や 1 億ドル規模の Generative AI Innovation Centerの設立 を通じて、AWS は、これらのイノベーションが個人と組織の両方の生活に果たす役割を深く理解するため、最前線に立って支援を行っています。AI と ML に関する選択肢を理解しやすくするため、AWS は 2 つの新しいガイドを公開しました： AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI と、 AWS機械学習サービスを選択するための意思決定ガイド です。 AI, ML, 生成系AIのためのAWSクラウド導入フレームワーク AI, ML, 生成系AIのためのAWSクラウド導入フレームワーク ( AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI (以下, CAF-AI)) は、AI への移行を支援する目的で設計されており、AI/ML によってビジネス価値を生み出そうとする組織にとってのメンタルモデルを示しています。AWS自身、および当社のお客様の経験に基づいて作られた本フレームワークのベストプラクティスにより、AI 変革を実現し、AWSでのAIの革新的な利用を通じてビジネス成果を加速させています。 AWSのお客様およびパートナーチームでも利用されているCAF-AIは、AIによる変革のための戦略の導出、優先順位付け、進化、およびコミュニケーションに役立ちます。以下の図は、お客様が求めるビジネス成果 (1) を起点に考える「Working Backwards」のアプローチにより、AI、ML、生成系AIがもたらす機会 (2) 、自社内で変革の対象とする領域 (3) 、および基盤となるケイパビリティ (4) を、AI戦略のアクションアイテムの評価、導出、実装という反復的なプロセス (5) を通じてAIジャーニーを簡素化する方法を示しています。 CAF-AIでは、AIとMLに関する組織内のケイパビリティが成熟するにつれて経験する可能性のあるAI/MLジャーニーについて説明します。その指針を示すため、組織がAIの成熟度をさらに高めるために役立つことが確認されている基本的なケイパビリティの進化に焦点を当てています。 また、これらの基本的なケイパビリティのターゲット状態の概要を通じて規範的なガイダンスを提供し、その過程でビジネス価値を生み出すためにケイパビリティを段階的に進化させる方法を説明します。以下の図は、クラウドと AI/ML の運用のための基本的なケイパビリティを示しています。ここでいうケイパビリティとは、所定のプロセスを使用してリソース (人、技術、その他の有形または無形の資産) を投入して成果を達成する組織の能力を指します。CAF-AIは現在も進化を続けている知識の指標であるため、時間の経過とともに成長し、変化することが見込まれます。 CAF-AI は、お客様の ML と AI への取り組みの出発点および方向付けのポイントとして設計されており、組織が中期的な AI と ML のアジェンダを策定し、それに影響する重要なトピックや視点を理解しようとする際にインスピレーションを得られるドキュメントとなることを意図しています。AI/ML ジャーニーのどの段階にいるかによって、特定のセクションに焦点を当ててそこでスキルを磨くことも、ドキュメント全体を使って成熟度を判断し、短期的な改善領域を導出することも可能です。 AI/MLが適用可能なビジネス課題は単一の機能や領域に限定されないため、AI/MLが差別化要素となる市場で競争の場をリセットする方法を探しているあらゆるビジネスの機能と業界ドメインに当てはまります。 AI、ML、生成系AIのための AWS クラウド導入フレームワーク は、この成果を達成するために AWS が提供する多くのツールの 1 つです。AI/MLは、何十年もの間解決するのが経済的ではない (またはAI/MLなしでは技術的に不可能だった) 問題に対するソリューションと解決への道筋を可能にするため、結果的に得られるビジネス成果の可能性は計り知れません。 AWS機械学習を選択するための意思決定ガイド AWSは、常にお客様のための選択肢を重視してきました。AI の活用機会の拡大にあたり、お客様のビジネスニーズに最適なサービス、モデル、インフラストラクチャを選択できるよう、適切なサポートを受けられることが最も重要と考えています。 AWS機械学習サービスを選択するための意思決定ガイド は、AWS が提供する AI および ML サービスの詳細な概要を示し、お客様とお客様のユースケースに適したサービスの選択方法に関する体系的なガイダンスを提供することを目的としています。 本ガイドは、適切な選択を行うための基準の明確化と検討にも役立てることができます。たとえば、AWS が提供する AI/ML サービスの適用範囲 (下記スクリーンショット参照) について説明しています。この説明を参照することにより、お客様において必要な制御とカスタマイズの度合いなど、さまざまなレベルの管理要件に対応するサービスを選定することが可能になります。 また、本ガイドでは、生成系AIの基盤モデルの力を引き出すための AWS サービスの独自機能や、急速に進化する生成系AIの分野を最大限に活用できる機会についても説明しています。 さらに、本ガイドには、特定のサービスの詳細、詳細なサービスレベルのテクニカルガイドへのリンク、主要サービスの独自の機能を強調した比較表、AI サービスと ML サービスの選択基準が掲載されています。AWS で AI、ML、生成系 AIの サービスを使い始めるのに役立つ主要なリソースへのリンクもまとめられています。 AWS が提供する AI、ML、生成系 AI サービスの幅広さを理解したいお客様におかれましては、本ガイドは良いスタートポイントになると考えています。 結論 このブログ記事で紹介した AWS機械学習サービスを選択するための意思決定ガイド と、 AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI では、お客様からよく聞かれる技術的ならびに非技術的な質問が網羅されています。これらのリソースが皆様のお役に立てば幸いです。各リソースに対するフィードバックをお待ちしています。 著者について Caleb Wilkinson はAIソリューションの構築に10年以上携わっています。AWSのシニアMLストラテジストとして、組織が責任のある形でAIからベネフィットが得られる可能性を広げるための革新的なAIアプリケーションを開拓しています。本記事で紹介したCAF-AIの共著者の一人です。 Alexander Wöhlke は、AI/ ML の分野で 10 年の経験があります。AWS Generative AI Innovation CenterのシニアMLストラテジスト 兼 テクニカルプロダクトマネージャーです。大規模組織のAI戦略策定に取り組んでおり、お客様が技術開発の最前線で計算されたリスクを取れるよう支援しています。本記事で紹介したCAF-AIの共著者の一人です。 Geof Wheelwright は AWS Decision Content チームのマネージャーです。本チームは、AWS 入門リソースセンターに掲載されている意思決定ガイドの執筆と開発を行っており、本記事で紹介した「AWS 機械学習サービスを選択するための意思決定ガイド」も作成しました。1980年代初頭にシンプルなテキストベースの Apple II 搭載版の ELIZA を体験して以来、AIとその先祖に相当する技術との仕事を楽しんでいます。

企業などの組織は、重要なデータを保護し、データを復元できるようにするため、データ保護やアーカイブのソリューションを利用しています。ハイブリッドアーキテクチャに移行するにつれて、データが様々な場所やプラットフォームに分散されるようになり、このような複雑性に対応できるバックアップソリューションが課題となっています。 インフラストラクチャの自動的なプロビジョニングと、クラウドをベースにしたリモートバックアップとリカバリのソリューションが登場したことにより、クラウドネイティブなワークロードに適合する高度なデータ保護とバックアップ戦略を採用できるようになりました。 VMware Cloud on AWS は、VMware によるエンタープライズグレードの SDDC (Software-Defined Data Center) と、Amazon Web Services (AWS) の グローバルインフラストラクチャ 上で稼働する Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスを統合した、共同開発によるフルマネージドサービスです。この統合によって、仮想マシン (VM) をリプラットフォームすることなく、ワークロードを VMware Cloud on AWS にシームレスに移行することができます。 一方 AWS Backup は、さまざまな AWS サービスのデータバックアップを一元化および自動化するフルマネージドバックアップサービスです。re:Invent 2021 において、VMware をサポートすることが発表され、VMware Cloud on AWS、VMware Cloud on AWS Outposts、オンプレミスの VMware で稼働する仮想マシンについてもデータ保護を一元化および自動化できるようになっています。 さらに 2022 年 6 月、VMware ワークロード向けの AWS PrivateLink のサポートが加わりました。VMware 環境から、Virtual Private Cloud (VPC) のプライベートインターフェースエンドポイントを介して、 AWS Backup に直接アクセスすることができます。 この記事では、VMware Cloud on AWS で実行されるワークロードを保護するために、プライベートインターフェース VPC エンドポイント (AWS PrivateLink) を用いて AWS Backup を利用する際、考慮すべきアーキテクチャ設計について説明します。 ソリューションの概要 AWS Backup は VMware vSphere と統合されており、AWS エコシステム内での仮想マシンのバックアップのスケジューリング、管理、保存を可能にします。バックアップを異なる AWS リージョンやアカウント間でコピーすることもできる、事業継続とランサムウェア攻撃からの保護のための包括的なソリューションです。手動または指定されたスケジュールに従って、バックアップを作成することができます。 最初のバックアップの復旧ポイントは仮想マシンの完全なスナップショットで構成されます。その後のバックアップは増分で、最後のバックアップ以降の変更分のみを取得します。さらに、バックアップをウォームストレージ層から、より経済的なコールドストレージ層に自動的に移行することでコストを削減します。 デフォルトでは、仮想マシンのアプリケーション整合性を保持したバックアップを実現するために、VMware Tools の静止設定を使用します。VMware Tools が利用できない場合には、クラッシュ整合性バックアップを取得します。ネットワークの転送効率を高めるため、バックアップは圧縮されて転送されます。 AWS ではセキュリティが最優先事項であり、AWS Backup は強固な 暗号化対策 を採用しています。仮想マシンのバックアップは、非常に安全な AES-256 暗号化アルゴリズムを使用して、転送中と保管時に暗号化されます。 カスタマーマネージドキー を使用してクラウドに保存されたバックアップを暗号化することで、セキュリティを強化できます。 図 1 – VMware Cloud on AWS と AWS Backup の統合アーキテクチャ 図 1 に示すように、VMware Cloud on AWS 上で動作する AWS Backup ゲートウェイアプライアンスに接続するためのインターフェース VPC エンドポイントが、Connected VPC がある AWS アカウントで実行されます。 AWS Backup を実行するための前提条件を詳しく説明する前に、AWS Backup の基本的な用語を確認しておきましょう。 AWS Backup ゲートウェイアプライアンス ： VMware Cloud on AWS 上で動作し、AWS Backup インターフェース VPC エンドポイントを通じて、AWS Backup コントロールプレーンにプライベート接続します。バックアップゲートウェイは ESXi ホストとの通信を確立し、VMware vCenter Server を介して、すべての仮想マシンを検出し、仮想マシンスナップショットを取得したり、データのバックアップとリストアを管理します。 AWS Backup インターフェース VPC エンドポイント ： AWS Backup ゲートウェイアプライアンスから AWS Backup コントロールプレーンにプライベートでアクセスできます。 AWS Backup バックアップボールト ： バックアップデータを保管および整理するコンテナです。クロスリージョンコピーにより、事業継続やコンプライアンス要件のために、本番データから離れた場所にある複数のバックアップボールトにデータを保管することができます。 前提条件 AWS Backup インターフェース VPC エンドポイントを使用して、VMware Cloud on AWS のために AWS Backup をデプロイするには、いくつかの前提条件があります。 VMware Cloud on AWS SDDC で、vCenter Server の FQDN 解決アドレスを プライベート IP アドレス に設定します。 VMware Cloud on AWS SDDC の管理ゲートウェイ (MGW) とコンピューティングゲートウェイ (CGW) のデフォルトのドメインネームシステム (DNS) ゾーンが、組織内部の DNS サーバーを利用するように構成 されていることを確認します。 vCenter へのアクセスを許可するために、前提条件となる ファイアウォールルールを設定 します。 AWS Backup ゲートウェイアプライアンス用のコンピュートネットワークセグメントを作成します。 AWS Backup サービスを実行する AWS アカウントを指定します。 AWS Backup インターフェース VPC エンドポイントをホストする VPC を指定します。 SDDC 上で動作する AWS Backup ゲートウェイアプライアンスと、以下のいずれかにある AWS Backup インターフェース VPC エンドポイント間のネットワーク接続を確認します。 Connected VPC ： クロスアカウント Elastic Network Interface を使用して、接続が確立されています。 (作業は必要ありません) その他の VPC ： VMware Transit Connect の外部 VPC アタッチメントを使用して VPC 接続を構成します。 AWS Backup の仮想マシンのサポートを有効化します。 作業手順 ステップ 1 ：インターフェース VPC エンドポイントを作成する 以下の手順に従って、AWS Backup サービスに接続するインターフェース VPC エンドポイントを作成します。 Amazon VPC コンソールのナビゲーションペインで、 エンドポイント を選択し、 エンドポイントを作成 をクリックします。 図 2 – Amazon VPC コンソールからエンドポイントを作成 サービスカテゴリ で AWS のサービス を選択し、 サービス は com.amazonaws.ap-northeast-1.backup-gateway (東京リージョンの場合) を検索して選択します。 図 3 – AWS Backup ゲートウェイインターフェースのエンドポイントを選択 VPC では、AWS Backup インターフェース VPC エンドポイントを作成する VPC を選択します。 サブネット では、 AWS Availability Zone (AZ) ごとに 1 つのサブネットを選択します。 セキュリティグループでは、デフォルト以外の適切な セキュリティグループ を選択します。 ポリシー では、 フルアクセス または カスタム を選択して、組織の AWS セキュリティポリシーと一致する VPC エンドポイントポリシーをアタッチし、 エンドポイントを作成 をクリックします。 インターフェース VPC エンドポイントが作成されたら、 DNS 名 を記録します。 図 4 – インターフェース VPC エンドポイントの DNS 名を記録 ステップ 2 ：AWS Backup ゲートウェイを導入する 手順に従って、AWS Backup ゲートウェイを作成します。 AWS Backup コンソールのナビゲーションペインで、 外部リソース セクションの ゲートウェイ を選択し、 ゲートウェイを作成 をクリックします。 図 5 – AWS Backup コンソールから AWS Backup ゲートウェイを作成 ゲートウェイを設定 セクションで、 OVF テンプレートをダウンロード をクリックし、指示に従って AWS Backup ゲートウェイアプライアンスをデプロイします。 OVF で仮想マシンをデプロイしたら、パワーオンを行います。 これらの手順を実行するために使用するマシンや踏み台サーバーが、AWS Backup ゲートウェイアプライアンスに到達可能なネットワークに接続されていることを確認します。そうでない場合は、SDDC の NSX Manager からパブリック IP アドレスを使用して受信ネットワークアクセス変換 (NAT) ルールを構成することで、ネットワークの疎通を確保します。パブリック IP アドレスを忘れずに記録してください。 ゲートウェイの設定手順に進みます。 ゲートウェイ接続 セクションで、前の手順で設定した仮想マシンの IP アドレスを指定し、組織の命名規則に従ってゲートウェイ名を設定します。 エンドポイント のタイプで VPC でホスト を選択し、前の手順で作成した VPC エンドポイントを選択します。インターフェース VPC エンドポイントを作成し、ゲートウェイタグセクションに必要なタグ (オプション) を追加します。最後に、 ゲートウェイを作成 をクリックします。 図 6 – AWS Backup ゲートウェイを構成し、インターフェースのエンドポイントを選択 ステップ 3 ：AWS Backup ゲートウェイに vCenter ハイパーバイザーを追加する 手順に従って、VMware Cloud on AWS SDDC の vCenter Server をハイパーバイザーとして AWS Backup ゲートウェイに追加します。 AWS Backup コンソールのナビゲーションペインで、 外部リソース セクションの ハイパーバイザー を選択し、 ハイパーバイザーを追加 をクリックします。 図 7 – AWS Backup ゲートウェイにハイパーバイザーを追加 ハイパーバイザーの設定では、 ハイパーバイザー名 、 vCenter サーバーの IP アドレスまたは完全修飾ドメイン名 (FQDN)、vCenter のユーザー認証情報、組織のポリシーに一致する暗号化キー (AWS 所有またはお客様所有) を指定します。デフォルトの SDDC 管理者 ( cloudadmin@vmc.local ) を使用するか、 必要な VMware の権限 を持つサービスアカウントを作成して使用することもできます。 図 8 – 認証情報とともにハイパーバイザー (vSphere) を指定 ドロップダウンリストボックスから前の手順で作成した ゲートウェイ を選択します。次に、 ゲートウェイ接続テスト を実行してハイパーバイザーが正常に接続されていることを確認します。 ハイパーバイザーのタグ (オプション) および VMware タグマッピング (オプション) では必要なタグを追加し、 ハイパーバイザーを追加 をクリックします。デフォルト以外の AWS Identity and Access Management (IAM) ロールを使用する場合には、 kms:Decrypt アクションが含まれていることを確認し、AWS Backup が AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用してハイパーバイザーの認証情報を暗号化および復号化できるようにします。 ハイパーバイザーが正常に追加され、接続ステータスが オンライン であることを確認します。 ステップ 4 ：VMware Cloud on AWS のファイアウォールルールを追加する 手順に従って、AWS Backup ゲートウェイと SDDC の ESXi ホスト間の通信を確保します。この手順は、AWS Backup のプロビジョニングと操作を適切に機能させるために必要です。 VMware Cloud コンソールから SDDC の NSX Manager にログインし、 セキュリティ タブから ゲートウェイファイアウォール に移動します。 管理ゲートウェイ のファイアウォールに対して以下のようにルールを追加します。 送信元 ： AWS Backup ゲートウェイアプライアンス 宛先：  ESXi サービス： プロビジョニングとリモートコンソール ( 902 ) 、HTTPS ( 443 ) ベストプラクティス VMware Cloud on AWS ワークロードに対する AWS Backup 導入に関して、以下に推奨事項を記載します。 導入においては AWS Backup インターフェースの VPC エンドポイントを常に使用し、パイロットや PoC の場合でもパブリックにアクセス可能なエンドポイントは利用しないようにします。 可能な限り、AWS Backup インターフェースの VPC エンドポイントを connected VPC 内に作成してください。VMware Transit Connect または AWS Transit Gateway を使用して AWS Backupインターフェースの VPC エンドポイントにアクセスすると、想定外のデータ処理コストの増大を招く可能性があります。 アベイラビリティゾーン (AZ) 間のデータ転送コストを回避するために、AWS Backup のインターフェース VPC エンドポイントが、VMware Cloud on AWS SDDC と同じアベイラビリティゾーン (AZ) にある VPC サブネットに作成されていることを確認してください。 以下の要素に関連するコストを評価して管理します。 インターフェース VPC エンドポイントを通じて処理される データの GB あたりのコスト ウォーム/コールド ストレージの 1 GB /月あたりのバックアップコスト ウォーム/コールド ストレージの 1 GB /月あたりのリストアコスト アイテムごとのリストア費用 (仮想マシンまたはディスクごと) クロスアベイラビリティゾーン (AZ) 料金 (該当する場合) クロスリージョン料金  (リージョンをまたがるバックアップボールトの場合) AWS Backup 監査マネージャのコスト (オプション) 必須ではありませんが、関連するタグを利用することを推奨します (ゲートウェイ、ハイパーバイザー、VMware タグマッピングなど) 。タグを使用すると、ユーザーが定義したキーと値をメタデータとして割り当てることができます。タグは、目的、所有者、環境、その他の条件に基づいて、リソースの管理、識別、整理、検索、フィルタリングを支援します。 AWS Backup は AES-256 暗号化アルゴリズムを採用していますが、カスタマーマネージドキーの自動キーローテーションを有効にすることを推奨します。 まとめ AWS Backup は、複雑なバックアップインフラストラクチャを導入および管理することなく、AWS 上の VMware Cloud で稼働する仮想マシンを保護するソリューションです。 仮想マシン向け AWS Backup の詳細につきましては、 製品ページ をご覧ください。 VMware Cloud on AWS、AWS Backup の実装、設計、ベストプラクティスに関するガイダンスについては、お気軽に お問合せ ください。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。 リソース VMware と VMware Cloud on AWS のための AWS Backup AWS Backup 製品ドキュメント AWS Backup の価格 AWS Backup for VMware ローンチブログ

AWS Black Belt オンラインセミナー Amazon Redshift の資料及び動画をご紹介します。 過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Black Belt へのご意見、ご感想は Twitterの #awsblackbelt をご利用いただき、フィードバックをお寄せください。 Amazon Redshift Overview AWS の Analytics サービスの 1 つであるデータウェアハウス Amazon Redshift は 2012 年のサービス開始以来、データからインサイトを得るための重要な機能を数多く提供してきています。Amazon Redshift の 3 つの特徴にそって、これらの機能を幅広くご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースの導入や運用に携わるデータベース管理者 AWS 環境におけるデータウェアハウスに関心がある方 Amazon Redshift の機能を網羅的に学びたい方 本 BlackBelt で学習できること Amazon Redshift の 3 つの特徴と重要な機能を幅広く学ぶことができます。 スピーカー 池田敬之（ソリューションアーキテクト） Amazon Redshift 運用管理 Amazon Redshift は、高速、スケーラブルで費用対効果の高いデータウェアハウスのマネージドサービスで、データウェアハウスにおける運用タスクの多くが自動化・簡易化されています。本セッションでは、Amazon Redshift の運用管理について詳しく解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Redshift をご利用予定の方、あるいはご利用されている方 Amazon Redshift について深く学びたい方 本 BlackBelt で学習できること Amazon Redshift の自動化された運用タスクと、モニタリングと性能改善方法、利用者の増加に対処する方法について学ぶことができます。 スピーカー 平井健治（ソリューションアーキテクト）

この記事は Centrally manage access and permissions for Amazon Redshift data sharing with AWS Lake Formation の翻訳記事です。 現代のグローバルなデータドリブン組織は、データを資産として扱い、さまざまな事業部門 (LOB) で使用して、タイムリーな洞察とより適切なビジネス上の意思決定を推進しています。 Amazon Redshift データ共有 を使用すると、あるクラスターから別のクラスターにデータをコピーしたり移動したりすることなく、ある Amazon Redshift データウェアハウス内のトランザクションの一貫性を保ったライブデータを別の Amazon Redshift データウェアハウスと安全に共有できます。同じ AWS アカウント内、アカウント間、リージョン間でデータ共有が使用可能です。 一部のお客様は、異なるアカウントの 50 ～ 100 のデータウェアハウスとデータを共有し、相互に共有を行っているため、誰がどのデータにアクセスしているかを追跡することが困難になっています。アクセス情報を取得するには、個々のアカウントの Amazon Redshift コンソールで確認しなければいけません。また、多くのお客様は、 Amazon Simple Storage Service (Amazon S3) 上にデータレイクを持っており、さまざまなビジネスユニット内およびビジネスユニット間で共有されています。組織が成長し、データが民主化されるにつれて、管理者はガバナンスと監査のためにデータ共有を一元管理し、きめ細かいアクセス制御を適用できる機能を必要としています。 お客様からの要望から逆算して、次の新機能を発表します。Amazon Redshift データ共有と AWS Lake Formation の統合により、Amazon Redshift のお客様は AWS Lake Formation を使用して Amazon Redshift データ共有へのアクセスを一元管理できるようになります。 AWS Lake Formation は、Amazon S3 を活用したデータレイクを一元管理するための一般的な選択肢です。今回、AWS Lake Formation による Amazon Redshift データ共有のサポートにより、新しい設計パターンが増え、データウェアハウス全体のガバナンスとセキュリティ体制を広げます。この統合により、AWS Lake Formation を使用して、フェデレーテッド AWS Identity and Access Management (IAM) ユーザーおよび IAM ロールに Amazon Redshift データ共有で共有されているテーブルおよびビューに対するきめ細かいアクセス制御を定義できます。 お客様は、ビジネスユニット間でデータを共有するメカニズムを提供する データメッシュ のアプローチを用いています。また、お客様は モダンデータアーキテクチャ を使用して、データレイクストアや Amazon Redshift のマネージドストレージからのデータをビジネスユニット間で共有しています。 AWS Lake Formation は、ビジネスユニット内およびビジネスユニット全体にデータガバナンスを適用する機能を提供します。これにより、安全なデータアクセスと共有、簡単なデータ検出、およびデータアクセスの集中監査が可能になります。 ユナイテッド航空 は人々をつなぎ、世界を一つにする事業を行っています。 「データ駆動型企業として、ユナイテッド航空は、革新的なモダンデータ駆動型アプリケーションを構築する分析コミュニティ向けに統合されたデータと分析エクスペリエンスを生み出そうとしています。 我々は、Athena、Aurora、Amazon Redshift、AWS Lake Formation などのさまざまな AWS サービスを使用して Purpose Built なデータメッシュ アーキテクチャを構築し、きめ細かいデータアクセスとコラボレーションに関する管理とガバナンスを簡素化することで、これを達成できると考えています。」 -Ashok Srinivas, Director of ML Engineering and Sarang Bapat, Director of Data Engineering. この投稿では、AWS Lake Formation を使って Amazon Redshift データ共有のアクセスと権限を一元管理する方法を示します。 ソリューション概要 このソリューションでは、データガバナンスのために Amazon Redshift データ共有と AWS Lake Formation を統合することがデータドメインの構築にどのように役立つか、またデータメッシュアプローチを使用してデータドメインを統合し、ビジネスユニット全体でのデータ共有とフェデレーションを可能にする方法を示します。次の図は、ソリューションのアーキテクチャを示しています。 データメッシュは、分散型のドメイン指向のアーキテクチャです。一元管理されたフェデレーテッドデータカタログを介してデータプロデューサーとデータコンシューマーを分離することを重視しています。通常、プロデューサーとコンシューマーはそれぞれ独自のアカウント内で運用されます。これらのデータメッシュ特性の詳細は次のとおりです。 データプロデューサー – データプロデューサーはデータプロダクトを所有し、データの生成や正確性の維持、データプロダクトを最新の状態に保つ責任があります。データプロデューサーはどのデータセットを公開して利用できるかを決定し、セントラルガバナンスアカウントの一元管理されたデータカタログにデータセットを登録することでデータセットを共有します。セントラルのガバナンススチュワードまたは管理者チームとともにデータプロダクトを管理するためのプロデューサー側のスチュワードまたは管理者が存在する場合があります。 セントラルガバナンスアカウント – AWS Lake Formation により、共有データセットに対するきめ細かいアクセス管理が可能になります。一元化されたデータカタログにより、コンシューマーは共有データセットをすばやく検索できるようになり、管理者は共有データセットに対するアクセス許可を一元管理できるようになり、セキュリティチームはビジネスユニット全体でのデータプロダクトの使用状況を監査および追跡できるようになります。 データコンシューマー – データコンシューマーは、セントラルガバナンス アカウントから共有リソースへのアクセスを取得します。これらのリソースはコンシューマーの AWS Glue データカタログ内で利用できるため、コンシューマー側のデータスチュワードや管理者が管理できるデータベースやテーブルへのきめ細かいアクセスが可能になります。 次の手順では、データメッシュアーキテクチャのセントラルガバナンスパターンで、AWS Lake Formation によって Amazon Redshift データ共有をどのように統制管理できるかの概要を示します。 プロデューサーアカウントでは、 Amazon Redshift プロデューサークラスター内にデータオブジェクトが作成および維持されます。データウェアハウス管理者は、Amazon Redshift データ共有を作成し、データセット (テーブル、ビュー) を共有に追加します。 データウェアハウス管理者は、セントラルガバナンスアカウントのデータカタログへのデータ共有へのアクセスを許可します。 セントラルガバナンスアカウントでは、データレイク管理者が AWS Lake Formation で管理できるようにAmazon Redshift データ共有を受け入れ、 そのデータ共有を指す AWS Glue データベースを作成します。 データレイク管理者は、 AWS Lake Formation のクロスアカウント共有 を使用して、AWS Glue データベースとテーブルをコンシューマーアカウントと共有します。 コンシューマーアカウントでは、データレイク管理者は AWS Resource Access Manager (AWS RAM) 経由でリソース共有の招待を受け入れるとデータベースがリストされているのが確認できます。 データレイク管理者は、きめ細かいアクセス制御を定義し、アカウント内の IAM ユーザー (この投稿では consumer1 と consumer2 ) にデータベースとテーブルに対するアクセス許可を付与します。 Amazon Redshift クラスターでは、データウェアハウス管理者が Glue データベースを指す Amazon Redshift データベースを作成し、作成された Amazon Redshift データベースの使用を IAM ユーザーに許可します。 IAM ユーザーとしてのデータアナリストは、Amazon Redshift クエリエディタなどの好みのツールを使用して、AWS Lake Formation のきめ細かい権限に基づいてデータセットにアクセスできるようになります。 この投稿の例では、次のアカウント設定を使用します。 プロデューサーアカウント – 123456789012 セントラルアカウント – 112233445566 コンシューマーアカウント – 665544332211 前提条件 Amazon Redshift データ共有を作成し、データセットを追加する プロデューサーアカウントで、暗号化を有効にした RA3 ノードタイプを使用して Amazon Redshift クラスターを作成します。次の手順を実行します。 Amazon Redshift コンソールで、 クラスターサブネットグループ を作成します。 詳細については、「 コンソールを使用したクラスター サブネット グループの管理 」を参照してください。 [Create cluster] を選択します。 [Cluster identifier] には、選択したクラスター名を指定します。 [Node type] で、RA3 ノードタイプのいずれかを選択します。 この機能は、RA3 ノードタイプでのみサポートされます。 [Number of nodes] に、クラスターに必要なノードの数を入力します。 [Database configurations] で、管理者ユーザー名と管理者ユーザーのパスワードを選択します。 [Cluster permissions] で、IAM ロールを選択し、それをデフォルトとして設定できます。 デフォルトの IAM ロールの詳細については、「 Amazon Redshift 用にデフォルトの IAM ロールを作成する 」を参照してください。 デフォルト設定を変更するには、 [Additional configurations] の横にある [Use defaults] オプションをオンにします。 [Network and security] で、次のように指定します。 [Virtual private cloud (VPC)] では、クラスターをデプロイする VPC を選択します。 [VPC security groups] では、デフォルトのままにするか、適切なセキュリティ グループを追加します。 [Cluster subnet group] で、作成したクラスターサブネットグループを選択します。 [Database configuration] の [Encryption] セクションで、[Use AWS Key Management Service (AWS KMS)] または [Use a hardware security module (HSM)] を選択します。 暗号化はデフォルトでは無効になっています。 [Choose an AWS KMS key] では、既存の AWS Key Management Service (AWS KMS) キーを選択する、もしくは [Create an AWS KMS key] を選択して、新しいキーを作成することができます。 新しいキーを作成する場合には、「 キーの作成 」を参照してください。 [Create cluster] を選択します。 この投稿では、次の スクリプト を使用してテーブルを作成し、プロデューサーの Amazon Redshift クラスターにデータをロードします。 データ共有の承認 AWS Command Line Interface (AWS CLI) の最新バージョンをインストールまたは更新して、AWS CLI を実行してデータ共有を承認します。手順については、「 AWS CLI の最新バージョンのインストールまたは更新 」を参照してください。 AWS Lake Formation の権限を設定 AWS Lake Formation で AWS Glue データカタログを使用するには、セントラルガバナンスアカウントで次の手順を実行して、IAM ベースのアクセス制御ではなく、Lake Formation のアクセス許可を使用してカタログリソースを制御するようにデータカタログ設定を更新します。 AWS Lake Formation コンソール に管理者としてサインインします。 ナビゲーション ウィンドウの [Data catalog] で、 [Settings] を選択します。 [Use only IAM access control for new databases] の選択を解除します。 [Use only IAM access control for new tables in new databases] の選択を解除します。 [Cross account version settings] で [Version 3] を選択します。 [Save] を選択します。 IAM ユーザーをデータレイク管理者として設定する 既存のデータレイク管理者ユーザーまたはロールを使用している場合は、次の管理ポリシーを追加し、以下のセットアップ手順をスキップします。 AWSGlueServiceRole AmazonRedshiftFullAccess それ以外の場合、IAM ユーザーをデータレイク管理者として設定するには、次の手順を実行します。 IAM コンソールのナビゲーションペインで [Users] を選択します。 データレイク管理者として指定する IAM ユーザーを選択します。 [Permissions] タブで [Add an inline policy] を選択します。 <AccountID> を自分のアカウント ID に置き換え、次のポリシーを追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action":"iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringEquals": { "iam:AWSServiceName":"lakeformation.amazonaws.com" } } }, { "Effect": "Allow", "Action": ["iam:PutRolePolicy"], "Resource": "arn:aws:iam::<AccountID>:role/aws-service role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess" }, { "Effect": "Allow", "Action": [ "ram:AcceptResourceShareInvitation", "ram:RejectResourceShareInvitation", "ec2:DescribeAvailabilityZones", "ram:EnableSharingWithAwsOrganization" ], "Resource": "*" } ] } JSON ポリシー名を指定します。 設定を確認して保存します。 [Add permissions] ボタンを選択し、[Attach existing policies directly] を選択します。 次のポリシーを追加します。 AWSLakeFormationCrossAccountManager AWSGlueConsoleFullAccess AWSGlueServiceRole AWSLakeFormationDataAdmin AWSCloudShellFullAccess AmazonRedshiftFullAccess [Next: Review and add permissions] を選択します。 データコンシューマーアカウントの設定 コンシューマー アカウントでは、セントラルガバナンスアカウントで前述した手順に従って、AWS Lake Formation とデータレイク管理者をセットアップします。 データコンシューマーアカウントで、暗号化付きの RA3 ノードタイプを使用して Amazon Redshift クラスターを作成します (プロデューサーアカウントで Amazon Redshift クラスターを作成する手順を参照してください)。 [Launch Stack] を選択して AWS CloudFormation テンプレートをデプロイし、ポリシーを持つ 2 人の IAM ユーザーを作成します。 スタックは、データアナリストとして次のユーザーを作成します consumer1 consumer2 CloudFormation スタックが作成されたら、スタックの [Outputs] タブに移動します。 ConsoleIAMLoginURL と LFUsersCredentials の値を取得します。 LFUsersCredentials の値を選択して、 AWS Secrets Manager コンソールに移動します。 [Secret value] セクションで、[Retrieve secret value] を選択します。 パスワードのシークレット値を取得します。 consumer1 と consumer2 はどちらも、 AWSマネジメントコンソール にログインするために、これと同じパスワードを使用する必要があります。 AWS Lake Formation を使用して Amazon Redshift データ共有を設定する プロデューサーアカウント コンソールを使用してデータ共有を作成 プロデューサーアカウントで Amazon Redshift データ共有を作成し、セントラルアカウントの AWS Lake Formation と共有するには、次の手順を実行します。 Amazon Redshift コンソールで、データ共有を作成するクラスターを選択します。 クラスターの詳細ページで、 [Datashares] タブに移動します。 [Datashares created in my namespace] で、[Connect to database] を選択します。 [Create datashare] を選択します。 [Datashare type]として、[Datashare] を選択します。 [Datashare name] に名前を入力します (この投稿では、demotahoeds)。 [Database name] で、データ共有オブジェクトを追加するデータベースを選択します (この投稿では dev) 。 [Publicly accessible] で、[Turn off] を選択します (または、パブリックにアクセス可能なクラスターとデータ共有を共有するには [Turn on] を選択します)。 [DataShare objects] で、[Add] を選択してスキーマをデータ共有に追加します (この投稿ではパブリック スキーマ) 。 [Tables and views] で [Add] を選択し、テーブルとビューをデータ共有に追加します (この投稿では、テーブル customer とビュー customer_view を追加します)。 [Data consumers] で、[Publish to AWS Data Catalog] を選択します。 [Publish to the following accounts] で、[Other AWS accounts] を選択します。 コンシューマーアカウントの AWS アカウント ID を指定します。この投稿では、Lake Formation 中央ガバナンス アカウントの AWS アカウント ID を提供します。 同じアカウント内で共有するには、[Local account] を選択します。 [Create datashare] を選択します。 データ共有が作成されたら、[Datashares] タブに戻り、 [Datashares created in my namespace] の下の検索バーにデータ共有名を入力して確認できます。 データ共有名を選択すると、その詳細が表示されます。 [Data consumers] の下に、コンシューマーアカウントのデータカタログのコンシューマーのステータスが [Pending Authorization] として表示されます。 コンシューマーデータカタログのチェックボックスを選択すると、 [Authorize] ボタンが有効になります。 [Authorize] をクリックして、コンシューマーアカウントのデータカタログへのデータ共有アクセスを承認すると、コンシューマーのステータスが [Authorized] に変わります。 SQL コマンドを使用してデータ共有を作成する プロデューサーアカウントでデータ共有を作成し、セントラルアカウントの AWS Lake Formation と共有するには、次の手順を実行します。 Amazon Redshift コンソールのナビゲーションペインで、[Query editor V2] を選択します。 クラスター名を選択 (右クリック) し、[Edit connection] または [Create Connection] を選択します。 [Authentication] で、[Temporary credentials] を選択します。 さまざまな認証方法の詳細については、「 Amazon Redshift データベースに接続する 」を参照してください。 [Database] にデータベース名を入力します (この投稿では dev) 。 [User name] に、データベースへのアクセスを許可されたユーザーを入力します (この投稿では awsuser) 。 [Save] を選択してデータベースに接続します。 次の SQL コマンドを実行してデータ共有を作成し、共有するデータオブジェクトを追加します。 create datashare demotahoeds ; ALTER DATASHARE demotahoeds ADD SCHEMA PUBLIC ; ALTER DATASHARE demotahoeds ADD TABLE customer ; ALTER DATASHARE demotahoeds ADD TABLE customer_view ; Bash 次の SQL コマンドを実行して、プロデューサーのデータ共有をセントラルガバナンスアカウントと共有します。 GRANT USAGE ON DATASHARE demotahoeds TO ACCOUNT ' <central-aws-account-id> ' via DATA CATALOG Bash 次の SQL コマンドを実行すると、作成されたデータ共有と共有されたオブジェクトを確認できます。 DESC DATASHARE demotahoeds Bash AWS CLI を使用して次のコマンドを実行して、セントラルデータカタログに対するデータ共有を承認し、AWS Lake Formation がデータ共有を管理できるようにします。 AWS マネジメントコンソールを使用して承認する手順については、「 データ共有の承認と承認の取り消し 」を参照してください。 aws redshift authorize-data-share \ --data-share-arn 'arn:aws:redshift: <producer-region> : <producer-aws-account-id> :datashare: <producer-cluster-namespace> /demotahoeds' \ --consumer-identifier DataCatalog/ <central-aws-account-id> Code 以下は出力例です。 { "DataShareArn": "arn:aws:redshift:us-east-1:XXXXXXXXXX:datashare:cd8d91b5-0c17-4567-a52a-59f1bdda71cd/demotahoeds", "ProducerArn": "arn:aws:redshift:us-east-1:XXXXXXXXXX:namespace:cd8d91b5-0c17-4567-a52a-59f1bdda71cd", "AllowPubliclyAccessibleConsumers": false, "DataShareAssociations": [{ "ConsumerIdentifier": "DataCatalog/XXXXXXXXXXXX", "Status": "AUTHORIZED", "CreatedDate": "2022-11-09T21:10:30.507000+00:00", "StatusChangeDate": "2022-11-09T21:10:50.932000+00:00" }] } JSON 前のセクションで説明した手順に従って、コンソールでデータ共有のステータスを確認できます。 セントラルカタログアカウント データレイク管理者は、セントラルガバナンスアカウントで AWS Lake Formation とのデータ共有を受け入れて登録し、同様にデータベースを作成します。次の手順を実行します。 データレイク管理者の IAM ユーザーまたはロールとしてコンソールにサインインします。 AWS Lake Formation コンソールに初めてログインする場合は、[Add myself] を選択し、[Get Started] を選択します。 ナビゲーションペインの [Data catalog] で、 [Data sharing] を選択し、 [Configuration] タブで Amazon Redshift データ共有の Invitations を表示します。 データ共有を選択し、[Review invitation] を選択します。 invitation の詳細を示すウィンドウが表示されます。 [Accept] を選択して、Amazon Redshift データ共有を AWS Glue データカタログに登録します。 AWS Glue データベースの名前を入力し、[Skip to Review and create] を選択します。 内容を確認し、[Create database] を選択します。 AWS Glue データベースが Amazon Redshift データ共有上に作成されると、それらのデータベースを [Shared databases] で表示できます。 AWS CLI を使用してデータ共有を登録し、データベースを作成することもできます。次のコマンドを使用します。 セントラルアカウントと共有される Amazon Redshift データ共有について確認します。 aws redshift describe-data-shares Bash Amazon Redshift データ共有を受け入れて Data Catalog に関連付けます。 aws redshift associate-data-share-consumer \ --data-share-arn 'arn:aws:redshift: <producer-region> : <producer-aws-account-id> :datashare: <producer-cluster-namespace> /demotahoeds' \ --consumer-arn arn:aws:glue:us-east-1: < central-aws-account-id > :catalog Bash 以下は出力例です。 { "DataShareArn": "arn:aws:redshift:us-east-1:123456789012:datashare:cd8d91b5-0c17-4567-a52a-59f1bdda71cd/demotahoeds", "ProducerArn": "arn:aws:redshift:us-east-1:123456789012:namespace:cd8d91b5-0c17-4567-a52a-59f1bdda71cd", "AllowPubliclyAccessibleConsumers": false, "DataShareAssociations": [ { "ConsumerIdentifier": "arn:aws:glue:us-east-1:112233445566:catalog", "Status": "ACTIVE", "ConsumerRegion": "us-east-1", "CreatedDate": "2022-11-09T23:25:22.378000+00:00", "StatusChangeDate": "2022-11-09T23:25:22.378000+00:00" } ] } JSON AWS Lake Formation に Amazon Redshift データ共有を登録します。 aws lakeformation register-resource \ --resource-arn arn:aws:redshift: < producer-region > : < producer-aws-account-id > :datashare: < producer-cluster-namespace > /demotahoeds Bash 受け入れられた Amazon Redshift データ共有を指す AWS Glue データベースを作成します。 aws glue create-database --region <central-catalog-region> --cli-input-json '{ "CatalogId": " <central-aws-account-id> ", "DatabaseInput": { "Name": "demotahoedb", "FederatedDatabase": { "Identifier": "arn:aws:redshift: <producer-region> : <producer-aws-account-id> :datashare: <producer-cluster-namespace> /demotahoeds", "ConnectionName": "aws:redshift" } } }' JSON これで、セントラルガバナンスアカウントのデータレイク管理者は、AWS Lake Formation のクロスアカウント共有機能を使用して、データベースとテーブルの両方に対するコンシューマーアカウントへのアクセスを表示および共有できるようになりました。 データコンシューマーにデータ共有アクセスを許可する 共有された AWS Glue データベースに対するコンシューマーアカウントへのアクセス許可を付与するには、次の手順を実行します。 AWS Lake Formation コンソールのナビゲーションペインの [Permissions] で、 [Data lake permissions] を選択します。 [Grant] を選択します。 [Principals] で、 [External accounts] を選択します。 コンシューマーアカウント ID を入力して Enter キーを押します (この投稿では 665544332211)。 [LF-Tags or catalog resources] で、 [Named data catalog resources] を選択します。 [Databases] では、データベース demotahoedb を選択します。 [Database permissions] と [Grantable permissions] の両方に [Describe] を選択します。 [Grant] を選択します。 コンシューマーアカウントにテーブルに対するアクセス許可を付与するには、次の手順を実行します。 AWS Lake Formation コンソールのナビゲーション ペインの [Permissions] で、[Data lake permissions] を選択します。 [Grant] を選択します。 [Principals] で、 [External accounts] を選択します。 コンシューマーアカウントを指定します (この投稿では 665544332211 を使用します)。 [LF-Tags or catalog resources] で、 [Named data catalog resources] を選択します。 [Databases] では、データベース [demotahoedb] を選択します。 [Tables] で、 [All tables] を選択します。 [Table permissions] と [Grantable permissions] の両方で [Describe] と [Select] を選択します。 [Grant] を選択して変更を適用します。 コンシューマーアカウント コンシューマー管理者はセントラルガバナンスアカウントから共有リソースを受け取り、次の表に示すように、コンシューマーアカウント内の他のユーザーにアクセスを委任します。 IAM User Object Access Object Type Access Level consumer1 public.customer Table All consumer2 public.customer_view View specific columns: c_customer_id , c_birth_country , cd_gender , cd_marital_status , cd_education_status データ コンシューマー アカウントで、次の手順に従って、アカウントと共有されているリソースを受け入れます。 データレイク管理者の IAM ユーザーまたはロールとしてコンソールにサインインします。 AWS Lake Formation コンソールに初めてログインする場合は、[Add myself] を選択し、[Get Started] を選択します。 AWS RAM コンソールにサインインします。 ナビゲーション ウィンドウの [Shared with me] で [Resource shares] を選択し、保留中の Invitation を表示します。2 つの Invitation を受け取ります。 保留中の Inviation を選択し、リソース共有を受け入れます。 AWS Lake formation コンソールのナビゲーションペインの [Data catalog] で、[Databases] を選択して、クロスアカウント共有データベースを表示します。 AWS Lake Formation を使用してデータアナリストと IAM ユーザーにアクセスを許可する これで、コンシューマーアカウントのデータレイク管理者は、共有データベースとテーブルに対するアクセス許可をコンシューマーアカウントのユーザーに委任できるようになりました。 consumer1 と consumer2 にデータベース権限を付与する IAM ユーザー consumer1 と consumer2 にデータベース権限を付与するには、次の手順に従います。 AWS Lake Formation コンソールのナビゲーション ペインの [Data catalog] で、 [Databases] を選択します。 データベース demotahoedb を選択し、 [Actions] メニューから [Grant] を選択します。 [Principals] で、 [IAM users and roles] を選択します。 IAM ユーザー consumer1 と consumer2 を選択します。 [LF-Tags or catalog resources] では、demotahoedb がデータベースとしてすでに選択されています。 [Database permissions] で [Describe] を選択します。 [Grant] を選択して権限を適用します。 consumer1 にテーブル権限を付与する IAM ユーザー consumer1 にテーブル public.customer に対するアクセス許可を付与するには、次の手順に従います。 ナビゲーション ペインの [Data catalog] で、 [Databases] を選択します。 データベース demotahoedb を選択し、「Actions」メニューから「Grant」を選択します。 [Principals] で、 [IAM users and roles] を選択します。 IAM ユーザー consumer1 を選択します。 [LF-Tags or catalog resources] では、 demotahoedb がデータベースとしてすでに選択されています。 [Tables] で、 public.customer を選択します。 [Table permissions] で [Describe] と [Select] を選択します。 [Grant] を選択して権限を適用します。 consumer2 に列権限を付与する IAM ユーザー consumer2 に public.customer_view の機密情報ではない列に対するアクセス許可を付与するには、次の手順に従います。 ナビゲーション ペインの [Data catalog] で、 [Databases] を選択します。 データベース demotahoedb を選択し、 [Actions] メニューから [Grant] を選択します。 [Principals] で、 [IAM users and roles] を選択します。 IAM ユーザー consumer2 を選択します。 [LF-Tags or catalog resources] では、 demotahoedb がデータベースとしてすでに選択されています。 [Tables] で、 public.customer_view を選択します。 [Table permissions] で [Select] を選択します。 [Data permissions] で、 [Column-based access] を選択します。 [Include columns] を選択し、機密情報ではない列 ( c_customer_id 、 c_birth_country 、 cd_gender 、 cd_marital_status 、および cd_education_status ) を選択します。 [Grant] を選択して権限を適用します。 コンシューマーアカウントの Amazon Redshift クラスターからデータ共有の利用設定を行う コンシューマー 用の Amazon Redshift データウェアハウスで、Query Editor V2 を使用して管理者ユーザーとしてログインし、次の手順を実行します。 次の SQL コマンドを使用して、共有されたカタログデータベースから Amazon Redshift データベースを作成します。 CREATE DATABASE demotahoedb FROM ARN 'arn:aws:glue: <central-region> : <central-aws-account-id> :database/demotahoedb' WITH DATA CATALOG SCHEMA demotahoedb ; SQL 次の SQL コマンドを実行して、Amazon Redshift データベースを作成し、IAM ユーザー consumer1 と consumer2 に作成したデータベースに対して USAGE の許可を与えます。 CREATE USER IAM:consumer1 password disable ; CREATE USER IAM:consumer2 password disable ; GRANT USAGE ON DATABASE demotahoedb TO IAM:consumer1 ; GRANT USAGE ON DATABASE demotahoedb TO IAM:consumer2 ; Bash AWS Lake Formation アクセス許可を強制するために IAM 認証を利用します。次の手順に従ってクエリエディタ v2 を設定します。 クエリエディタ v2 の左下隅にある設定アイコンを選択し、[Account Settings] を選択します。 [Connection settings] で、[Authenticate with IAM credentials] を選択します。 [Save]を選択します。 コンシューマーユーザーとして共有データセットをクエリする IAM ユーザー consumer1 が Amazon Redshift からデータ共有アクセス権があることを検証するには、次の手順を実行します。 IAM ユーザー consumer1 としてコンソールにサインインします。 Amazon Redshift コンソールのナビゲーションペインで [Query Editor V2] を選択します。 コンシューマークラスタに接続するには、ツリー ビュー ペインでコンシューマークラスタを選択します。 プロンプトが表示されたら、 [Authentication] で [Temporary credentials using your IAM identity] を選択します。 [Database] にデータベース名を入力します (この投稿では dev ) 。 ユーザー名は現在の IAM アイデンティティ にマッピングされます(この投稿では consumer1 )。 [Save] を選択します。 データベースに接続したら、次の SQL コマンドを使用して、現在ログインしているユーザーを確認できます。 select current_user ; Bash コンシューマーアカウントで作成されたフェデレーションデータベースを検索するには、次の SQL コマンドを実行します。 SHOW DATABASES FROM DATA CATALOG [ ACCOUNT ' <id1> ' , ' <id2> ' ] [ LIKE 'expression' ] ; Bash consumer1 の権限を検証するには、次の SQL コマンドを実行します。 select * from demotahoedb.public.customer limit 10 ; Bash 次のスクリーンショットに示すように、 consumer1 はデータ共有の customer オブジェクトに正常にアクセスできます。 では、 consumer2 が同じコンシューマークラスタ上のデータ共有テーブル「public.customer」にアクセスできないことを検証してみましょう。 コンソールからログアウトし、IAM ユーザー consumer2 としてサインインします。 同じ手順に従って、クエリエディタ v2 を使用してデータベースに接続します。 接続できたら、同じクエリを実行します。 select * from demotahoedb.public.customer limit 10 ; Bash ユーザー consumer2 は、次のスクリーンショットに示すように、アクセスの拒否エラーを受け取るはずです。 consumer2 に対する public.customer_view ビューの 列レベルのアクセス権限を検証してみましょう。 consumer2 としてクエリエディタ v2 に接続し、次の SQL コマンドを実行します。 select c_customer_id,c_birth_country,cd_gender,cd_marital_status from demotahoedb.public.customer_view limit 10 ; Bash 次のスクリーンショットでは、consumer2 が AWS Lake Formation によって許可された列にのみアクセスできることがわかります。 まとめ データメッシュアプローチは、組織がビジネスユニット間でデータを共有できる方法を提供します。各ドメインは、データの取り込み、データ処理、データの提供を担当します。ドメインの担当者は、データ所有者でありドメインの専門家であり、データの品質と正確性に対して責任を負います。データガバナンスのために AWS Lake Formation と Amazon Redshift データ共有を使用すると、データメッシュアーキテクチャの構築が容易になり、きめ細かいアクセス制御によるビジネスユニット間のデータ共有とフェデレーションが可能になります。 AWS Lake Formation との Amazon Redshift データ共有の開始に貢献していただいた皆様に心より感謝いたします。 Debu Panda, Michael Chess, Vlad Ponomarenko, Ting Yan, Erol Murtezaoglu, Sharda Khubchandani, Rui Bi 参考情報 Modern Data Architecture on AWS Designing a data lake for growth and scale on the AWS Cloud Design a data mesh architecture using AWS Lake Formation and AWS Glue 翻訳はソリューションアーキテクトの池田 敬之が担当しました。

イントロダクション AWS Copilot CLI は、 Amazon Elastic Container Service ( Amazon ECS ) , AWS Fargate 及び AWS App Runner 上で コンテナのビルドや管理運用する際にデベロッパーが用いるツールで、 2020 年にローンチ しました。 このブログでは、AWS Copilot CLI を使用して、Amazon ECS 及び AWS Fargate 上で publisher サービスと subscriber ワーカーサービスを簡単に実装する方法説明します。これらのサービスは、 pub/sub アーキテクチャ 内でそれぞれがイベントを publish 及び consume します。 この機能を説明するために、 このブログ に掲載されたモノと似たアーキテクチャを元に、publish/subscribe(pub/sub) アーキテクチャを作成します。しかし、 AWS Lambda に頼ることなく、AWS Fargate 上で動作する Amazon ECS サービスを用いると共に、AWS Copilot CLI を用いてリソースの作成と管理をします。 このブログでは、あなたは E コマースプラットフォームの所有者と仮定します。そして、プラットフォームに注文が送信される度にマイクロサービスがトピックにメッセージを送信し、このメッセージに関心があるいくつかのマイクロサービスは、非同期に受け取った注文に対して処理を始めます。注文を処理できるマイクロサービスは様々あると考えられ、たとえば、注文フルフィルメントマイクロサービス、インボイスのマイクロサービス、特定の閾値を超える注文に対してキャンペーンコードを生成するようなプロモーションマイクロサービスなどです。このブログでは、フルフィルメントマイクローサビス及びプロモーションマイクロサービスを実装します。 ソリューションのアーキテクチャは下記の図の通りです。 ソリューションの概要 pub/sub でのメッセージングは非同期メッセージングパターンで、送信者または受信者のidを知ることなくメッセージを交換できます。このパターンでは、サービス間の通信を疎結合にできるので、アプリケーションを分離できます。送信者 ( publisher とも呼ばれる ) は、トピックに対してメッセージをブロードキャストします。一方で受信者 ( subscriber とも呼ばれる ) は異なるトピックをサブスクライブし、当該トピックにメッセージが送信されるとフィルタリングポリシーを参照し、合致するメッセージを受信します。 受信者は、送信者からのメッセージを無限に受け取ることができますが、topic-queue chaining と呼ばれるパターンを用いることをオススメします。この名前が示すように、SNS トピックを SQS キューに紐付けます。もし、サービスが例外を実行した際やメンテナンスを必要としている際でも、メッセージはキューに保持されます。これには、キューがバッファとして機能し、最終的にロードバランサーとして機能するという利点もあります。 AWS Copilot CLIは、topic-queue chaining パターンのpub/sub アーキテクチャを以下のように簡単に実装できます。 サービスマニフェストを修正するだけで、 Amazon SNS トピック にメッセージを送信する publisher サービスを作成します。 トピックに送信された通知を処理するため 1 つ以上の Amazon SQS キュー を含む worker サービス、障害を処理する デッドレターキュー ( DLQ )、キューからメッセージを取得し、非同期にメッセージを処理するAWS Fargate 上で動作する Amazon ECS サービスを作成します。 このブログでは、AWS Copilot CLI が提供する Load Balanced Web Service と Worker Service を用いて以下のアーキテクチャを実装します。 ウォークスルー ここからは、皆さんと次の作業を実施していきます。 サンプルリポジトリのクローンとコードの確認 AWS Copilot CLI を用いて、マイクロサービスのための環境の構築 publisher と SNS トピックの作成 subscriber、SQS キュー、subscriber のポリシーの作成 実装した pub/sub アーキテクチャがどのように動作するか確認 前提条件 このウォークスルーでは、以下の前提条件を満たす必要があります。 AWS アカウント の用意 AWS Copilot CLI がインストール済み ( version v1.22 以上 ) AWS CLI または 環境変数 を用いて適切に設定された AWS クレデンシャル Docker がインストールされ、実行可能であること サンプルリポジトリのクローン 最初のステップでは、Github リポジトリをクローンするディレクトリに移動し、git clone を実行します。 git clone https://github.com/aws-samples/aws-copilot-pubsub クローンしたディレクトリに移動し、サブディレクトリを確認してください。サービスごとにフォルダーがあり、1 つは publisher 用、もう 1 つは fulfilment と promotion という名前の 2 つの subscriber 用です。下記にフォルダー構成を示します。 aws-copilot-pubsub/ ├─ subscribers/ │ ├─ fulfilment/ │ │ └─ ... │ ├─ promotion/ │ │ ├─ requirements.txt │ │ ├─ promotion.py │ │ └─ Dockerfile ├─ publisher/ │ └─ ... アプリケーションと環境の作成 まず最初に、Service、Environment、Pipeline を関連づける論理グループを作成します。AWS Copilot では、これを Application と呼びます。 copilot app init pubsub 上記のコマンドを実行すると、AWS Copilot はマニフェストと呼ばれる IaC の YAML 構成ファイルを保持するために ./copilot フォルダを利用します。それにより、AWS Copilot CLI を用いて AWS 上にコンテナ化されたアプリケーションを簡単にデプロイすることを可能にします。合わせてリソース作成に使われるインフラストラクチャロールもいくつか作成されます。 次のステップでは、デプロイするアプリケーションのための環境を構築します。AWS Copilot では、アプリケーションのデプロイメントを論理的に分離した環境を非常に簡単な方法で作成する事ができます。一般的なユースケースは、テスト環境 及び 独立した本番環境を用意し、テスト環境で検証された場合にのみ、アプリケーションを本番環境にデプロイすることです。このウォークスルーでは、以下のコマンドで作成した test という名前のテスト環境にサービスをデプロイします。 copilot env init \ 　　 --app pubsub \ 　　--name test \ 　　--region 'eu-west-1' \ 　　--default-config \ 　　 --profile default 上記のコマンドを実行すると、AWS Copilot は指定されたプロファイル認証情報 (default profile) を使用して、サービスをホストするために必要なインフラストラクチャを作成します。プロファイルを省略すると、 ~/.aws/credentials ファイル内のプロファイルのうち一つを選択するように促されます。AWS Copilot は、選択された認証情報を用い、ユーザに代わってリソースの作成を開始します。初期構成が出来上がった後は、ユーザは、 ./copilot/environments/test/manifest.yaml ファイルを修正することにより環境をアップデートできます。今回は、環境に変更を加えることはしません。下記のコマンドで環境をデプロイします。 copilot env deploy --name test 作成された環境ごとに、AWS Copilot は、分離されたネットワークスタック、コンピュートエンジンに AWS Fargate を用いた Amazon ECS クラスタを作成します。このプロセスが完了するまで、およそ 2 分かかります。少しストレッチして待ちましょう。もし、AWS Copilot が裏で何を作成しているか詳しく知りたいなら、AWS CloudFormation コンソールへアクセスしてスタックの進行状況を確認しましょう。スタックは、 <appName>-<envName> と名づけられるので、今回の場合は、 pubsub-test です。 publisher の作成 現在、皆さんの環境はデプロイ済みであり、当該環境にAmazon ECS クラスタが既に存在するので　皆さんは SNS トピックにメッセージを送信する “publisher” と命名されたマイクロサービスをデプロイすることができます。 まず最初に、 ./publisher ディレクトリを探しましょう。内部には、ロジックを実装する Python ファイルと、コードと依存関係を含むコンテナイメージの作成に用いる Dockerfile があることがわかります。 publisher/ │ ├─ templates │ │ ├─ index.html │ │ └─ order.html │ ├─ requirements.txt │ ├─ publisher.py │ └─ Dockerfile コードはとてもシンプルです。なぜなら、 Flask や Jinja のテンプレートを活用して、以下の画像に示すような小規模なフロントエンドを作成するからです。 フロントエンドは、2つのフィールドを持つフォームを提供しています。一つは顧客名、もう一つは注文金額です。これは、リクエストの処理をトリガーするためのシンプルな方法です。Send ボタンが押されると、マイクロサービスはフォームを処理し、注文のデータを DynamoDB テーブルへ記録し、SNS トピックへメッセージを送信します。それにより、subscriber マイクロサービス上で非同期に処理が開始できます そのようなマイクロサービスを実装するためには、複数のインフラストラクチャコンポーネントを作成する必要があり、そのプロセスに時間がかかる場合があります。インフラストラクチャの作り方を理解するのに時間を費やすよりも、マイクロサービス開発に時間を効率的に使うために、AWS Copilot は いくつかの CLI コマンドや 追加設定した AWS Copilot YAML マニフェストファイルを通して Elastic Load Balancing (Application Load Balancer または Network Load Balancer のいずれか)、Amazon ECR リポジトリ、タスク定義、Amazon ECS タスクに加え、 SNS トピックや DynamoDB テーブルといったリソースを作成する手助けをします。 ここでは、 Load Balanced Web Service と呼ばれる AWS Copilot のパターンを使用し、Amazon ECS サービス 及び パブリックアクセスが可能な Application Load Balancer (ALB) を作成します。そのため、以下のコマンドで実行します。 copilot svc init \ --app pubsub \ --svc-type "Load Balanced Web Service" \ --name "publisher" \ --port 5000 \ --dockerfile "publisher/Dockerfile" 上記のコマンドを実行すると、コンテナイメージを安全に保存でき、プライベートで利用可能なAmazon ECR リポジトリと、サービスの構成オプションが記載されたマニフェストファイルが copilot/publisher/manifest.yml に作成されます。 サービスをデプロイする前に生成された manifest.yml ファイルを確認します。マニフェストファイルがどのようにサービス構成を保持しているか確認し、割り当てられたCPU、メモリ、タスク数などの構成オプションを変更できます。 このウォークスルーでは、2 つの追加リソースを加える必要があります。publisher がメッセージを送信するための SNS トピックとリクエストを保持するデータベースです。 AWS Copilot CLI で SNS トピックを簡単に作成するために、下記のセクションをマニフェストファイルに追加します。 publish: topics: - name: ordersTopic 宣言したトピックごとに AWS Copilot は標準 SNS トピックを作成し、 COPILOT_SNS_TOPIC_ARNS という環境変数を通してリソースの Amazon Resource Name(ARN) を注入します。そして、トピックへメッセージを送信するために Amazon ECS タスクに適切な権限を渡します。当該環境変数は JSON 構造で、key にトピック名、各 key はトピック ARN を value に持ちます。それゆえ Python では、以下のようなコードでこれらの辞書のような構造体にアクセスします。 dest_topic_name = 'ordersTopic' sns_topics_arn = json.loads(os.getenv("COPILOT_SNS_TOPIC_ARNS")) topic_arn = sns_topics_arn[dest_topic_name] ここでは、標準 SNS トピックを作成していることに注意して下さい。FIFO (first-in, first-out) が必要なケースでは、マニフェストファイルにトピック設定に fifo property を追加してこの動作を有効にできます。もし FIFO を有効するならば、全ての subscriber は同様に FIFO SQS キューを利用しなければならないことを覚えておいてください。ここでは、物事をシンプルにするために、標準 SNS トピックを利用します。 データベーステーブルを追加するために、ターミナルで以下のコマンドを実行します。 copilot storage init \ --name ordersTable \ --storage-type DynamoDB \ --workload publisher \ --partition-key id:S \ --no-sort --no-lsi このコマンドは、 copilot/publisher ディレクトリの下に addons/ordersTable.yml を作成します。当該ファイルには、AWS Copilot CLI を用いてデプロイされた DynamoDB テーブルの設定が記載されています。 マニフェストファイルとアドオンファイルで必要なリソースを定義できたので、実際にリソースを作成していきます。ローカルで実行している Docker デーモンが、コンテナイメージをビルドし、その後、Amazon Elastic Container Registry (Amazon ECR) にアップロードされ、Amazon ECS タスクのイメージとして利用されます。 備考：下記のコマンドを実行する前 または コマンドの実行失敗の際には Docker デーモンが起動していることを確認してください。 copilot svc deploy --name publisher --env test ターミナルにリソースの作成状況が表示されます。サービスとアドオンが作成された後、Application Load Balancer の DNS 名を受け取ります。これでインターネットを介して、サービスにアクセスできるようになりました。 1 つ目の subscriber (fulfilment) の作成 前のステップで、注文を送信する publisher 用のインフラストラクチャと サービスを作成しました。しかし、注文を処理する subscriber 用のインフラストラクチャとサービスは作成していません。それでは、1 つ目の subscriber サービスを作成しましょう。まず初めに、下記のコマンドでサービスの定義を作成しましょう。 copilot svc init \ --app pubsub \ --svc-type "Worker Service" \ --name fulfilment \ --port 5000 \ --dockerfile "subscribers/fulfilment/Dockerfile" \ --subscribe-topics "publisher:ordersTopic" ここでは、AWS Copilot CLI が提供する Worker Service というサービスタイプを用います。Worker Service では、バッファとして動作し、メッセージを保持する SQS キュー と AWS Fargate 上で動作する Amazon ECS サービスが作成されます。 さらに、 <svcName>:<topicName> の表記でサブスクライブしたいトピックを選択していることに注目してください。あるいは、上記のフラグ引数をせず、省略することも可能です。その場合、コマンドを実行した際に 既に存在する SNS トピックをサブスクライブするように促されます。その際は、スペースバーを押してトピックを選択し、最後にエンターキーを押します。 Which topics do you want to subscribe to? [Use arrows to move, space to select, type to filter, ? for more help] > [x] ordersTopic (publisher) コマンドが発行されると、 copilot/fulfilment ディレクトリ下にサービス用の新しいマニフェストファイルが作成されていることがわかります。マニフェストファイル内に、トピックのサブスクリプションが追加されたセクションがあることを確認してください。 subscribe: topics: - name: ordersTopic service: publisher 上記の設定により、AWS Copilot CLI は COPILOT_QUEUE_URI 環境変数を注入するため、SQS キュー内のイベントへアクセスする事ができます。キューから何度読んでもアプリケーションが正常に処理できない特定のメッセージがある際、通常 当該メッセージは、手動で検査するために Dead-Letter Queue (DLQ) と呼ばれる別のキューへルーティングされます。AWS Copilot では、DLQ の作成 及び 再送設定 の指定がとても簡単です。皆さんがすることは、以下のセクションをマニフェストファイルに追加することだけです。 subscribe: topics: - name: ordersTopic service: publisher queue: dead_letter: tries: 3 マニフェストを修正したら、以下のコマンドを用いて Amazon ECS 及び AWS Fargate に subscriber サービスをデプロイできます。 copilot svc deploy --name fulfilment --env test 2 つ目の subscriber (promotion) の作成 前のステップでは、ordersTopic トピックに送られた各メッセージを処理する subscriber サービスを作成しました。しかし、いくつかのマイクロサービスでは、受け取った全てのメッセージを処理する必要はなく、特定の特徴を持った一部のメッセージのみ処理する必要があります。そのため、多くの顧客は新しいトピックを作成したり、またはメッセージを処理するかどうかを決定するコンシューマーで何かしらの前処理をします。しかし、それは良いプラクティスではありません。ベストプラクティスは、SNS のネイティブの機能を利用することです。SNS は、メッセージコンテキストに沿ってメッセージ属性を公開することができるため、subscriber は サブスクリプションフィルタリングポリシー を指定して、受信するメッセージを定義できます。これにより、追加のトピックの作成 または 前処理が不要になります。 このステップでデプロイするサービスは、promotion という名前で、$80 以上の注文を処理します。このシナリオでは、20% のクーポンコードが発行され、次回の購入時に利用できます。先にデプロイしたサービスと同様に、以下を実行してサービスを作成します。 copilot svc init \ --app pubsub \ --svc-type "Worker Service" \ --name promotion \ --port 5000 \ --dockerfile "subscribers/promotion/Dockerfile" \ --subscribe-topics "publisher:ordersTopic" SNS トピックサブスクリプションのフィルターポリシーを指定する新しいセクションを copilot/promotion/manifest.yml マニフェストファイルに追加します。 subscribe: topics: - name: ordersTopic service: publisher filter_policy: amount: - numeric: - ">=" - 80 queue: dead_letter: tries: 3 マニフェストを修正した後、以下のコマンドで Amazon ECS 及び AWS Fargate に subscriber サービスをデプロイすることができます。 copilot svc deploy --name promotion --env test 動作確認 全てのマイクロサービスを作成したので、想定通りに機能するかテストします。ブラウザを開き、publisher サービスを作成後に得られたロードバランサーの DNS 名を入力して下さい。もし、DNS 名を忘れてしまった場合、以下のコマンドを実行してください。 copilot svc show --name publisher --json | jq '.routes[0].url' または、以下を実行して下さい。 copilot svc show --name publisher そして、 COPILOT_LB_DNS という変数の値をコピーして下さい。 ページを更新するたびに、新しい名前と注文の合計が生成されますが、必要に応じてフィールドを変更することができます。 このとき、裏側で起きている事象を知るためには、ターミナルを開き、以下のコマンドを実行して下さい。 copilot svc logs \ --name publisher \ --env test \ --follow \ --since 1s 上記のコマンドで publisher サービスのログを表示することができるのため、ウィンドウを調整すれば、フロントエンドの画面とターミナルで同時に確認することができます。最初は何も表示されないかもしれませんが、送信ボタンを押すとすぐに以下のような出力が表示されるはずです。 2 つの subscriber サービスで起きていることを確認するために、以下のコマンドでログを確認します。 copilot svc logs \ --name fulfilment\ --env test \ --follow \ --since 1s copilot svc logs \ --name promotion \ --env test \ --follow \ --since 1s 同時に 3 つのターミナルを起動することをオススメします。それにより、各マイクロサービス内でどのような処理がなされているのか確認することができます。さまざまな金額を入力して、閾値を満たさない注文が promotion マイクロサービスでどのように処理されないかを確認してください。注文が永続化されていることを確認するため、送信された全注文を保持する DynamoDB 内のアイテムテーブルを調べることもできます。 クリーンアップ 将来的な料金の発生を避けるため、リソースを削除します。デモのリソースを正しく作成した場合、以下のコマンドを実行することで全てのサービスと関連するインフラストラクチャは削除されます。 copilot app delete pubsub おわりに AWS Copilot CLI によって pub/sub アーキテクチャを簡単に構築できました。サービスに必要なインフラストラクチャやポリシーの作成に時間を費やすのではなく、必要なリソースをデプロイするのに役立つサービステンプレート と コマンドを使用することで、本当に重要なことに集中できるようになりました。AWS Copilot CLI は、SNS トピックの構築、SQS キューの構築、サブスクリプションの設定、フィルターポリシーの設定、DLQ の構築、再配送設定、サービスへ URI の設定ができるため、publisher と subscriber を作成することが、これまで以上に簡単になりました。 AWS Copilot は、 オープンソースのツール で、 パブリックロードマップ から状況を確認することができます。また、 GitHub issues の作成や Gitter でのディスカッションに 参加頂ける と幸いです。 AWS Copilot Documentation AWS Copilot Public Sprint Board on GitHub AWS Copilot Gitter Chat Room それでは。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

お客様は 2008 年以来、AWS 上で SAP ワークロードを実行しています。SAP と AWS は 14 年以上に渡るパートナーシップと、お客様のために共同でイノベーションを起こしてきました。SAP は、SAP Concur、SAP CX（SAP Qualtrics によるカスタマーエクスペリエンス）、SAP NS2 HANA Secure Cloud などの社内システムやお客様向けサービスの運用に、長年にわたり一貫して AWS サービスを活用してきました。SAP 最大の SAP Business Technology Platform（SAP BTP）のデプロイは AWS 上にあり、お客様が ERP コアを中心にイノベーションを起こせるよう 80 以上のサービスを提供しています。SAP BTP ポートフォリオは、SAP HANA Cloud、SAP Integration Suite、SAP Data Warehouse Cloud、SAP Analytics Cloud など、アプリケーション開発と自動化、プランニング、データ／アナリティクス、統合、人工知能に対応するさまざまなサービスで構成されています。SAP on AWS のお客様は一貫して、クラウドに移行する動機の 1 つは、AWS インフラのコスト削減とスケーラビリティに加えて、ストレージ、データ分析、IoT、機械学習、自動化機能などの AWS サービスと SAP を統合することだと語っています。このようなお客様ニーズから逆算して、AWS と SAP は最初のステップとしてジョイント・リファレンス・アーキテクチャ・ガイダンスを通じてお客様にイノベーションを提供し、その後の自動化を提供するために継続的に投資しています。このブログでは、AWS と SAP が、初期のハイレベルなビジネスユースケースのリファレンスアーキテクチャパターンを通じて、お客様に共同ガイダンスを発行するアプローチについて説明します。また、各アーキテクチャパターンの詳細な実装ガイダンスの追加リファレンスもあります。 RISE with SAP on AWS RISE with SAP は、オンプレミスで SAP やその他の ERP ワークロードを実行し、クラウド上の SAP S/4HANA への移行を検討しているお客様向けの、SAP によるフルマネージドソリューションです。AWSとSAPは、RISE with SAPを通じて、お客様がガイド付きのトランスフォーメーション・ジャーニーを通じて、このビジネス変革を加速できるよう協力してきました。AWS 上の RISE with SAP のお客様は、現在クラウドの旅のどの段階にいるかにかかわらず、迅速に移行、展開、革新することができます。SAP S/4HANA Cloud（RISE with SAP を通じて提供）は、お客様のビジネスプロセスを業界標準に合わせることを支援し、重要なビジネスプロセスの中央リポジトリとして機能を果たします。AWS と連携した SAP BTP は、ERP コアの統合された拡張機能としてアプリケーション開発、統合、アナリティクスのフレームワークを提供することで、 クリーンコア モデルを採用する簡素化されたアーキテクチャアプローチを提供し、移行の簡素化と迅速化、ビジネスプロセスの自動化と最適化、360° アナリティクスなどのメリットをもたらします。 ジョイント・リファレンス・アーキテクチャのアプローチ AWS と SAP は、ビジネスプロセスの統合、拡張、データ管理、アナリティクスシナリオなどの分野のリファレンスアーキテクチャパターンを考案するために提携しています。これらのパターンは、SAP BTP の基本サービスに沿ったプラットフォーム、データ・トゥ・バリュー、アプリケーションを含む 3 つの基本的な柱によって推進されます。これらの柱はそれぞれ、イノベーションに対応し、SAP BTP と AWS のサービスを補完して利用することで、お客様のビジネスオペレーションの効率化を促進します。この図（図1 – SAP BTP on AWS ジョイント・リファレンス・アーキテクチャの概要）は、AWS と SAP BTP のサービスの強みを組み合わせ、プラットフォーム、データ・トゥ・バリュー、アプリケーションの基本的な柱を確立するための包括的なアーキテクチャを表しています。この初期アーキテクチャの焦点は、 SAP Build Work Zone 、 SAP Cloud Integration 、 SAP Data Warehouse Cloud などの SAP BTP の基盤となるサービスと、 Amazon Route 53 、 Amazon Sagemaker 、 Amazon Redshift などの AWS サービスによる、高可用性、ビルトイン弾力性、自動化と技術的負債の削減に重点を置いたイノベーションです。 図 1 – SAP BTP on AWS ジョイント・リファレンス・アーキテクチャの概要 プラットフォーム基盤 ミッションクリティカルなビジネスアプリケーションの基本要件の 1 つは、ビジネスの継続性です。現代のビジネスアプリケーションは、ビジネスの継続性だけでなく、信頼性の向上とレイテンシの低減も要求しています。お客様は、厳格な監視フレームワークと信頼性の高いフェイルオーバー戦略を通じて、障害に強いアーキテクチャを持つことに依存しています。耐障害性の高い実装により、お客様は AWS グローバルインフラストラクチャ を使用して、重要なアプリケーションへの中断のないアクセスを維持します。プラットフォーム基盤の柱では、 Amazon Route 53 サービスと連携して AWS リージョンを活用することで、 SAP Build Work Zone や SAP Integration Suite といった SAP BTP の基盤サービスが高い耐障害性を持つようにすることに注力しています。このアーキテクチャガイダンスの詳細と実装については、 こちら をご覧ください。 データから付加価値を創出 データはあらゆるビジネスにおいて最も価値のある資産の 1 つであり、お客様はますますクラウド上のマルチソースデータストレージ戦略を採用するようになっています。 データフェデレーション 戦略は、データの重複やデータパイプラインを排除することで、マルチソースデータへのリアルタイムアクセスを提供するため、お客様の効率化に役立ちます。また、技術的負債を削減し、総所有コスト（TCO）を最適化することにもつながります。SAP Datasphere（旧名称 SAP Data Warehouse Cloud） を通じて、SAP、 Amazon Redshift 、 Amazon S3 、 Amazon Athena を含む様々なデータソースをセキュアに連携・融合することで、効率的なプランニング、キュレーション、機械学習、アナリティクスを可能にします。Amazon AthenaとSAP Datasphere を使用した双方向データ連携の可能性の 1 つについて、こちらの ブログ で説明しています。 データウェアハウスに蓄積されたデータから、お客様は機械学習技術を駆使して有意義な洞察を引き出し、ビジネスの将来の戦略的ニーズを予測しようとしています。ライブ SQL 接続を使用して、SAP FedML は SAP DWC から Amazon Sagemaker へのデータソースを支援し、AWS データストアと SAP にネイティブに存在する結合データセットに基づいてモデル化、トレーニング、予測を行います。この処理されたデータセットは、AWS 内でネイティブに消費されるか、FedML を通して SAP DWC に戻されます。詳細なアーキテクチャガイダンスについては、こちらの ブログ を参照してください。 統合とアプリケーション開発 現代のアプリケーションは、アプリケーションレイヤーだけでなく、基盤となるインフラやデータレイヤーにもビルトインされた弾力性のあるフレームワークを持つことが期待されており、それによって全体的に分散された弾力性が生まれます。 SAP Cloud Application Programming Model（CAP） は、言語、ライブラリ、ツールのフレームワークとして機能し、開発者を実証済みのベストプラクティスの道へと導き、繰り返し発生するタスクに対してすぐに使える豊富なソリューションを提供します。SAP BTP 内でネイティブに構築されたこれらのアプリケーションは、Amazon Route 53 や Amazon Aurora のような AWS サービスの組み合わせにより、高可用性を実現できます。 Amazon Aurora は、MySQL と PostgreSQL の完全な互換性を備えたクラウド用に構築されたリレーショナルデータベース管理システム（RDBMS）で、商用グレードのデータベースのパフォーマンスと可用性を低コストでお客様に提供します。このアーキテクチャ・ガイダンスの詳細と実装については、 こちら をご覧ください。 SAP BTP と AWS のその他の統合可能性には、 Amazon Simple notification Service （SNS）を活用して通知を送受信する SAP S/4HANA ビジネスプロセス拡張アプリケーションの構築が含まれます。この統合は、より迅速なサポート対応と解決のために、ビジネスプロセスや技術的なアプリケーション監査のためのリアルタイム通知を必要とする企業にとって特に有用です。また、IoT センサーと定期的に相互作用する CAP アプリケーションは、データ受信時に、確立された優先度レベルに基づいて Amazon SNS を使用して必要な通知をトリガーすることができます。こちらの ブログ では、お客様が SAP Business partners を作成する際の SAP S/4HANA 移行シナリオに関連する実際のユースケースを取り上げています。 まとめ このブログでは、SAP BTP と AWS サービスを使用して SAP エコシステムを近代化するためのアーキテクチャパターンを提供する SAP と AWS のハイレベルな戦略について説明しました。各パターンは、実際のユースケースを伴う簡単なソリューション概要とともに説明されています。これらのアーキテクチャパターンの詳細な実装については、SAP の各リファレンスブログで説明されています。このブログは、AWS と SAP が計画している一連の詳細な共同リファレンスアーキテクチャガイダンスの始まりとなります。 SAP on AWS ワークロードのための共同リファレンスアーキテクチャに関して、共同チームが 2022 年に発表した以下のセッションをチェックしてください。 AWS re:Invent 2022 – Accelerate value for your business w w/SAP & AWS reference architecture (PRT105) SAP TechED 2022 – Amplify the Value of SAP Investments on AWS with a Joint Reference Architecture [DT200] さらに参考になる文献をいくつかご紹介します。 SAP and AWS – Joint Reference Architectures to maximize utilization and investments AWS and SAP BTP – Driving more value from your SAP ERP journey to the cloud Query SAP HANA using Athena Federated Query and join with data in your Amazon S3 data lake SAP on AWS 、 Amazon Route53 、 Amazon Sagemaker 、 Amazon Redshift 、 Amazon Athena 、 Amazon Aurora の詳細については、 AWS 製品ドキュメント を参照してください。 さらに専門的なガイダンスが必要な場合は、AWS アカウントチームに連絡して、ローカルの SAP スペシャリストソリューションアーキテクトに依頼してください。 SAP on AWS ディスカッションへの参加 お客様のアカウントチームと AWS サポートチャネルに加えて、私たちは最近 re:Post – A Reimagined Q&A Experience for the AWS Community を立ち上げました。私たちの SAP on AWS ソリューションアーキテクチャチームは、定期的に SAP on AWS トピックを監視し、お客様やパートナー様を支援するためのディスカッションや質問にお答えしています。もしあなたの質問がサポートに関連したものでなければ、re:Post で議論に参加し、コミュニティのナレッジベースに追加することを検討してください。何千ものアクティブなお客様が AWS 上で SAP を実行していることについては、 SAP on AWS のページをご覧ください。 クレジット ジョイント・リファレンス・アーキテクチャに関する AWS と SAP のパートナーシップは、SAP と AWS の組織からの深い協力と貢献の結果です。専門知識、サポート、ご指導をいただいた以下のメンバーに感謝いたします。 チーム AWS：Sabari Radhakrishnan, Sunny Patwari, Rajesh Chigurupati, Yuva Athur, Ganesh Suryanarayanan, Krishnakumar Ramadoss, Spencer Martenson, Adam Hill, Scott Rigney, Soulat Khan and Erik Kamman. チーム SAP：Madankumar Pichamuthu, Sangeetha Krishnamoorthy, Karishm.a Kapur, Weikun Liu, Haridas Nair, Sivakumar N and Anirban Majumdar. 翻訳は Partner SA 松本が担当しました。原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの濱野谷です。2023年7月28日にオンラインで開催された「 テキストから画像への生成系AIによる革新的技術の紹介 」では、生成系 AI によるテキストからの画像生成について３つのセッションをお届けしました。 オープニングで、AWS の AIML GTM スペシャリストの浅倉より、AWS の AI/ML 関連のサービスの一覧の中で、AI による画像生成に関係するサービスの位置づけをご紹介しました。その後、Stability AI Japan の Jerry Chi 様より、画像生成 AI モデルを提供する立場から画像生成 AI 技術の進化と活用事例についてご紹介いただきました。次に株式会社リコーの梅津様より、生成系 AI を活用したソリューションを提供し、顧客価値を創造する取り組みについてご紹介いただきました。最後に、AWS の機械学習ソリューションアーキテクトの呉より、Amazon SageMaker JumpStart を利用した生成系 AI の利用と Fine Tune について紹介いたしました。 「画像生成 AI 技術の進化と活用事例」 Stability AI Japan 株式会社 Head of Japan Jerry Chi 様 Jerry Chi 様からは、 Stability AI Japan 様が提供する画像生成モデルである Stable Diffusion についてご紹介いただきました。Stable Diffusion は2022年8月のリリース以降、日本でも多くのユーザに利用されている、画像生成の人気モデルです。2023年6月23日に最新バージョンの Stable Diffusion XL 1.0 がリリースされました。Stable Diffusion を使用する方法は、１． Stability Platform API を使用する、２． Amazon SageMaker JumpStart のソリューションテンプレートを使用してモデルをデプロイする、３． Amazon Bedrock を使用してAPI経由で使用する、の３つの選択肢から選択できます。 Stable Diffusionは様々な機能を有しています。画像の一部をAIで塗りつぶす inpainting 、写真を枠外に拡張して描画する Uncrop 、１枚の画像から被写体の向きや背景のバリエーションを作成する Reimagine 、ラフスケッチから画像を生成する Stable Doodle などの拡張機能や改造を、Stability AI 様が Web 上で公開している画像編集 AI ツールの Clipdrop で無料で体験することができます。 これらの機能の活用事例として、広告やプロモーションの画像や動画の作成、アニメ制作におけるキャラクター描画や背景の生成、プロダクトや建築・インテリアのデザイン、画像認識モデルの訓練のためのシンセティックデータ（合成データ）生成など幅広い分野での事例もご紹介いただきました。特に、シンセティックデータの生成では、異常検知などデータの収集にお金と時間をかけても集めにくいデータを、早く安く生成することが可能になります。事例では、違法漁業検知 AI の訓練データとして、本物の船の写真を68枚だけ用意し、Stable Diffusion でシンセティックデータを生成した例をお話しいただきました。 まとめとして、今後も生成系 AI の活用は拡大していき誰でもクリエイターになれる時代が来る、それを使いこなすためには、生成される多くの画像をキュレーションしたりプロデュースするスキルが必要になってくる、とのメッセージをいただきました。 「生成系 AI を活用した商品・サービス提供による顧客価値の創造　生成系 AI のソリューション活用に向けて　～リコーの取り組み～」 株式会社リコー デジタル戦略部 デジタル技術開発センター 所長 梅津 良昭 様 株式会社リコーの梅津様からは、生成 AI を活用した顧客価値の創造の事例として、「働く現場での AI 活用」と、「オフィス領域での高度な AI 活用」の２つの取り組みについてご紹介いただきました。 まず、「働く現場での生成 AI 」では、工場設備などのインフラ点検、屋内物流、加工現場などで、画像や映像生成の AI を活用しています。その一例として、工場の配管やメーターをチェックする自動走行式ロボットについてお話しいただきました。ロボットは敷地内のメーターや設備をカメラを使って確認し、異常が有った場合のみ通知を送ります。サビや煙が発生した異常な状態は画像を使ってトレーニングを行う必要が有りますが、実際に異常な状態になった画像を多く集めるのは困難です。そこで、画像生成 AI を使ってトレーニング用の異常系データのバリエーションを生成し、ロボットのトレーニングに活用しているとのことでした。また、ロボットの自動走行のトレーニングにも、走行経路の画像にトラックや荷物などの障害物を追加した画像を生成しているとのことでした。この他にも、VSLAM 技術や振動モニタリング技術などのリコーが得意とするセンシング技術と、AI 技術を組み合わせることで、向上・設備稼働の自動化や、自動点検、警備等のソリューションの提供を目指していくとのメッセージをいただきました。 続いて紹介いただいた「オフィス領域での高度な AI 活用」では、言語系 AI を中心として AI を活用してオフィス領域での業務に価値を提供しています。この領域については、2023 年 4 月の AWS Summit Tokyo でも 事例セッション に登壇いただいています。この領域では、Transformer を用いた LLMの OSS の言語モデルをベースとして、お客様データの追加学習や FineTuning を行う事で、企業に特化したモデルを作成し、業務に活用するソリューションを提供しています。業務活用の事例としては、生成 AI を使い始めるきっかけやユースケースの掘り起こしを目的とした RICHO Chatbot Service からはじまり、企業のドキュメントを使って高度な検索を実現するベクトル検索や、お客様ドキュメントを追加学習したカスタム GPT3 の開発、将来的にはより高度な業務への AI インテグレーションも対応可能とのことです。開発中の AI インテグレーションの例として、眼鏡型ヒアラブル端末を使って、AO 機器の保守エンジニアがトラブル対応時にリコー製 カスタム GPT3 から解決方法の情報を得る例と、対話型サイネージ等でユーザーと対話するデジタルヒューマンの例をお話しいただきました。 最後に、AI を使いたい企業向けにノーコード AI 開発や運用を行える環境の提供を開始したというアナウンスと、使ってみたい企業がいらっしゃれば是非一緒にやっていきたいとのメッセージをいただきました。 「Amazon SageMaker を活用した生成系 AI への第一歩と第二歩の Tuner へのガイド」 [ Slides ] アマゾン ウェブ サービス ジャパン合同会社 機械学習ソリューションアーキテクト 呉 和仁 最後のセッションでは、 Amazon SageMaker を使い、第一歩として基盤モデルのデプロイ、第二歩として FineTune を実施する方法を、デモを使って紹介しました。 <【デモ】生成系AIを使ってみる> 第一歩のデモの中では、最初のセッションでも紹介された Stable Diffusion を利用した画像生成と、 rinna 社の提供する日本語の生成系 AI である japanese-gpt-neo-x-3.6b を利用した言語生成をそれぞれ実施しています。 画像生成では、「印象派風のコテージ」「仕事をしている風景」といった一般的なテキストには、それらしい画像が生成されました。一方で、「呉和仁」という特定の人物を指すテキストには、なんとなく人間のような画像は生成されましたが、本人とは似ていないという課題が発生しました。 テキスト生成では、AIと連歌を嗜もうとしました。最初に、連歌の定義を質問したところ、誤った情報であるハルシネーションを回答するという課題が発生しました。続けて藤原道長の短歌の上の句（五・七・五）「この世をば　わが世とぞ思ふ　望月の」を入力し、下の句（七・七）を詠むように指示を出すと、本来の下の句である「かけたることも　なしと思へば」でも、七・七調でもない句が出力されてしまい、連化にならないという課題が発生しました。これらの課題を解決するのが、後半のデモで実施する Fine Tuneです。 また、デモの中では、 Amazon SageMaker Jump Start を使って提供されるモデルをデプロイしたり、 Amazon SageMaker Studio を使って、公開されている Jupiter Notebook 形式のファイルから簡単に生成系AIの利用を開始していました。このように、AWS のサービスを使うと、アルゴリズムの選定やモデルを動かすまでのトレーニングなどの機械学習の開始に必要な膨大な苦労を回避して、生成系 AI の利用を開始することができます。 <【デモ】生成系AIを Fine Tuneする> 第二歩のデモとして、公開されている学習済みモデルで要件を満たせない場合に、少量のデータで再学習しモデルを微調整する FineTune を実演しました。 画像生成では、第一歩のデモで生成できなかった「呉和仁」の６枚の画像と、プロンプトをS3にアップロードし、Amazon SageMaker JumpStart の Train Model を使って学習します。Fine Tune 後のモデルを使うと、オフィスにいるような画像を生成することが出来ました。 テキスト生成では、古今和歌集、新古今和歌集のデータをクロールしたデータや、現代文の短歌をアップロードし、短歌の特徴に合わせて Fine Tune します。Fine Tune 後のモデルでは、ほぼ七・七調で古文独特の言い回しを用いた下の句を生成することができました。また、このデモの関連記事が builders.flash に掲載されています。 デモを通してお伝えしたように、現在では、多くの企業がモデルを公開しており自由に使うことができます。一方で、同じようなモデルを使う他社と差別化するには、用途に合わせたデータを溜めて Fine Tune することが必要です。そのために、良いデータを溜め続け、顧客体験を改善していくことが差別化の重要要素となります。 最後に、API からサーバレスで基盤モデルを使用できる Amazon Bedrock についても言及が有りました。Amazon Bedrock でも Amazon SageMaker と同様 Fine Tune が可能です。そのため、どのようなサービスで生成系AIモデルを使う場合でも、集めたデータは無駄にならないので、データを集める仕組みを今から検討しましょう、というメッセージを伝えさせていただきました。 質問 セミナーを通して参加者から多くのご質問をいただきました。その中から、ピックアップして回答いたします。 Q. Stable Diffusionで同じ prompt で複数回画像を生成すると、異なる画像が生成されますが、どのような仕組みでしょうか？ Stable Diffusionでは、ランダムノイズを使用して元の画像を生成し、ノイズを除去していくことによって画像を生成します。元のランダムノイズが異なるので、異なる画像が表示されます。 一方で、seed と呼ばれる値で画像の生成を制御することが可能です。デフォルトではランダムな画像が生成されるように設定されていますが、seed に固定値を設定して同じ画像を生成することが可能です。 Q. AWS の SageMaker や Bedrock などのサービスで、入力したプロンプトや FineTune の学習データが公開モデルの学習に使われるということはあるでしょうか？ ありません。お客様の推論およびトレーニングデータは、AWS が提供する基盤モデルの更新やトレーニングに使用、共有されることは有りません。 Q. 初心者が最短で生成系 AI を試すには、どの方法が良いでしょうか？ Amazon SageMaker JumpStart がおすすめです。 事前トレーニング済みのモデルが複数公開されており 、用途に合ったものを選択して簡単にデプロイできます。 Q. デモの中で、6 画像の Fine Tune の所要時間が14分でしたが、Fine Tuneにかかる時間を短縮できるオプションはありますか？ Jobの起動オーバーヘッドが１０分くらい占めるので、実時間は４分程度です。また、Epoch 数やバッチサイズなどハイパーパラメータを調整することでも学習時間を変えられます。 Q. デモの読み上げ音声はどのように実装していたのでしょうか？ Amazon Polly を使って音声を生成しています。 Q. FIne Tune したモデルはどのような費用がかかりますか？使用中の他に、使わない場合も費用が発生しますか？ モデル使用中の料金は、選択するインスタンスのサイズによって料金は異なります。詳しくは、 Amazon SageMaker の料金 のJumpStartの料金をご参照ください。 モデルを Amazon S3 に保存するため、モデルを使用しない間もリージョンの S3 標準タイプの料金 が発生します。S3 の料金はリージョンにより異なりますが、一例として、バージニア北部の S3 標準の料金は、0.023 USD / GB / 月ですので、200MB程度の rinna の Fine Tune 済みモデルを保存すると、月に0.0005 USD 程度の料金が発生します。 まとめ 今回は、「テキストから画像への生成系 AI による革新的技術の紹介」というテーマで、生成系AI によるテキストから画像への生成の基本原理とそのメカニズム紹介いたしました。画像生成 AI モデルを提供する Sitability AI 様と、生成系AIをビジネスに活用するソリューションを提供するリコー様と、それぞれ異なる立場から活用例をご紹介いただき、非常に学びの多いイベントとなりました。また、AWS からは、AWS 上で生成系 AI モデルを動かす方法と、公開されているモデルを Fine Tune して差別化を行っていくためにデータ収集をする重要性をお話しさせていただきました。 これまでの AI/ML 関連イベントの開催報告と登壇スライドは、以下のリンクからご覧いただけます。 AWS AI/ML@Tokyo 開催報告まとめ TAGS: AI/ML@Tokyo , Artificial Intelligence , Generative AI , Amazon SageMaker , AI/ML

本投稿は、ゲストである Grafana Labs の Senior Software Engineer の Michael Mandrus と Amazon Timestream の Senior Technical Product Manager の Igor Shvartser の共著となります。 多くの組織にとって、パフォーマンスとコスト効率の良い監視と分析は、ミッションクリティカルなアプリケーションの要件となっています。この要件に伴い、特に DevOps 、 セキュリティ 、 IoT アプリケーションでよく見られるアクティビティの急増時に、運用ダッシュボードと視覚化を使用する事が増えています。これらのダッシュボードは、多くのアナリストにより同時に表示され、短い間で何度もリロードされますが、こういった頻繁な使用により、コストの急騰やクエリの遅延を招き、チームの生産性の低下につながる事があります。また、より時間に敏感な状況では、ダッシュボードの読み込みを待って時間を無駄にしてしまわない事が重要です。 Grafana は時系列データベースと統合してソフトウェアスタックを監視、視覚化出来る主要なオープン可観測性プラットフォームです。Grafana は頻繁にアクセスされるデータをキャッシュする機能を提供します。また、1 日に数兆件のイベントを処理可能なスケーラビリティを持ち、サーバレスで高速に動作する時系列データベースである Amazon Timestream と統合する事ができます。 幅広い業界のお客様が Grafana を Timstream と統合して利用しており、ダッシュボードからリアルタイムの洞察を導き出し、重要なアプリケーションを監視し、Web サイトやアプリケーションの数百万のリアルタイムイベントを分析しています。Grafana と Timestream を統合して利用する事で、運用ダッシュボードを構築し、ソースとなる Timestream テーブルでは無く、Grafana が保持するキャッシュから結果を読み込む事が出来ます。これによりダッシュボードの読み込み時間が短縮され、クエリコストが削減され、クエリがスロットリングする可能性は低減します。 この投稿では、Timestream のデータを使って Grafana のダッシュボードを作成する方法と、 Grafana Query Caching 機能を使ってクエリキャッシュを構成する方法を紹介します。 ソリューションの概要 Grafana を利用すると、ユーザは パネルのコレクション から構築されたダッシュボードを作成して、様々なソースデータの視覚化を実現できます。 Grafana Plugins Catalog からダウンロードして利用できるプラグインを通じて、様々なデータソースが利用できるようになります。プラグインをインストール後、特定のデータベースへ接続するように構成されたデータソースインスタンスを作成します。データソースの構成、利用方法については Timestream plugin を参照して下さい。また、本ソリューションを利用する際のコストについては注意して下さい。 データソースインスタンスを構成後、クエリを作成し、Grafana で利用可能な可視化の方法を選択して結果を表示させる事により、ダッシュボードパネルを作る事ができます。パネルをロードすると、ダッシュボードで指定された時間範囲を組み合わせたクエリが実行されます。 Grafana のクエリキャッシュ機能 (Grafana Cloud、Grafana Enterprise で利用可能) はデータソースインスタンス、クエリ、及び時間範囲を使用してキャッシュのキーを作成します。パネルがロードされると、Grafana はまずローカルキャッシュで要求されたデータを確認し、見つかった場合はキャッシュからデータを返します。見つからない場合は、Grafana はデータソースに対してクエリを実行し、結果をローカルキャッシュに保存します。つまり、ダッシュボードの初期ロードでは通常の時間がかかりますが、その後の同様の時間範囲を指定したロードはほぼ瞬時に行われる事になります。これは、時間範囲を最も近い間隔にまとめ、キャッシュヒットの可能性を高める事で実現されます。尚、クエリキャッシュとその有効期限 (TTL) はデータソースインスタンス毎に構成できます。 Timestream を始める Timestream の利用を開始するには、チュートリアルとサンプルのアプリケーションを含む こちら を確認して下さい。このチュートリアルでは、サンプルデータセットが入力されたデータベースを作成し、サンプルクエリを実行する方法を示します。また、サンプルアプリケーションは、データベース／テーブルを作成し、テーブルにサンプルデータを設定し、サンプルクエリを実行する方法を示します。AWS コンソールに直接アクセスしたり、AWS コマンドラインインターフェース (CLI) や AWS SDK を使用したりする事も出来ます。 尚、Timestream を初めて利用する場合には、使用量割当の条件を遵守する必要がありますが、1ヵ月間の 無料トライアル で試す事が出来ます。 Timestream プラグインの構成 本セクションでは、データベースキャッシュ機能を備えた Timestream プラグインの構成と使用方法について説明します。Timestream データベースを設定し、Grafana からクエリを実行する為の前提条件と手順については、 こちら を参照して下さい。 1. Timestream プラグインを インストール します。 2. 新しいデータソースを追加します。 3. 接続情報の詳細を入力します。 4. 追加の詳細を入力し、 Save & test を選択して、接続を検証します（スクリーンショットの構成情報は例であり、実際の詳細とは異なる場合がある点に注意して下さい） 5. Cache のタブで、 Enable を選択します。 6. Cache 設定 (オプション) を構成します。 7. クエリを作成し、ビジュアライゼーションを選択してパネルを作成します（スクリーンショットの構成と SQL クエリは例であり、実際の詳細とは異なる場合がある点に注意して下さい） 8. パネルをリロードし、応答がキャッシュされた事を確認します。 これで完了です！必要な可視化が得られるまでは、ダッシュボードの構築を続けましょう。以下は特に広い時間の範囲が選択された Timestream のダッシュボードの例です。クエリサイズ (1 か月分の Timestream データ) が大きい為、初回はダッシュボードを全てロードするのに時間がかかりましたが、リフレッシュ時はクエリキャッシュを利用する為、Timestream へのアクセスは発生せず、ダッシュボードを表示するのに 100 ms 以下 (99% 短縮) で完了しました。 考慮事項 Grafana のクエリキャッシュ機能を使う場合は、現在、以下 2 点の考慮事項があります。 キャッシュキーは特定のタイムスタンプによって決まります。つまり、クエリに利用する時間範囲が既にキャッシュに保存されている時間範囲に収まらない場合は、Grafana はデータベースに対して全く新しいクエリを発行する必要があります。例えば、 t0 から t1 に対してクエリを実行し、次に t0 から t2 に対してクエリを実行すると、Grafana は t1 から t2 では無く、 t0 から t2 に対してクエリを実行します。同じ事は結果のサブセットにも当てはまります。 もしも複数の利用者が同じダッシュボードを同時にロードした際、キャッシュにデータが無い場合は、各クエリは重複排除されずに並行してデータソースに送信され、キャッシュスタンピード (データソースにアクセスが殺到して高負荷となる事) が発生する可能性があります。キャッシュスタンピードを監視する方法としては、Grafana のメトリック grafana_http_requests_in_flight をモニターする事が挙げられます。これは、事象発生時には、同メトリックが増加する為です。また、キャッシュスタンピードを予防するには、 max_conns_per_host や、 max_open_conns_default 等のパラメータを Grafana に設定し、データソースへの接続数を調節する必要があります。 Grafana チームはこれらの制限に対応する拡張機能の可能性を積極的に調査しており、Grafana の将来のバージョンに含める事を検討しています。進捗情報と今後のリリースでの修正にご期待下さい。 結論 本投稿では、Timestream で Grafana クエリキャッシュを利用する方法について説明しました。クエリキャッシュは運用ダッシュボードのパフォーマンスを向上させ、クエリコストを削減する為の重要な機能です。Timestream での Grafana の使用、及びサンプルアプリケーションとダッシュボードの作成について説明する追加ドキュメントについては、 Grafana の Timestream 開発者ガイド を確認して下さい。 Grafana Cloud はメトリクス、ログ、トレース、ダッシュボードを使い始める最も簡単な方法です。また Grafana は最近、永久無料枠として、3 人までのユーザに対して、全てのエンタープライズプラグインへのアクセスを含む新機能を追加しました。さらにあらゆるユースケースに対応するプランも用意しています。今すぐ無料で サインアップ しましょう！ Timestream を確認して開始するには、 こちら をご確認下さい。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

Amazon FSx for Lustre は、オープンソースの Lustre ファイルシステムのスケーラビリティと高いパフォーマンスを備えたフルマネージド型共有ストレージを提供し、Linux ベースのワークロードをサポートします。FSx for Lustre は、ストレージ速度とスループットを重視するワークロードに向いています。これは、FSx for Lustre が、人工知能 (AI) や機械学習 (ML)、ハイパフォーマンスコンピューティング (HPC)、金融モデリング、メディア処理を含むワークロードにおいて、ストレージボトルネックを回避し、コンピューティングリソースの使用率を高め、価値を生み出すまでの時間を短縮できるためです。FSx for Lustre は Amazon Simple Storage Service (Amazon S3) とネイティブに統合され、自動インポートとエクスポートによって双方向の変更を同期するため、高性能な POSIX 準拠のファイルシステムを通じて Amazon S3 データレイクにオンデマンドでアクセスできます。 FSx for Lustre のファイルリリースを8月9日に発表いたしました。この機能により、Amazon S3 と同期されたファイルデータをリリースして、データライフサイクルを管理することができます。ファイルリリースによってストレージスペースが解放されるため、Amazon S3 から FSx for Lustre の遅延読み込みによってリリースされたファイルへのオンデマンドアクセスを保持しながらも、引き続きファイルシステムに新しいデータを書き込むことができます。リリースするディレクトリを指定し、オプションで最終アクセスからの最短時間を指定すると、指定したディレクトリのデータと、最終アクセスからの最短時間 (指定されている場合) のみがリリースされます。ファイルリリースは、使用頻度の低いファイルデータを S3 に移動させることで、S3 階層化を活用できるようにするので、データライフサイクル管理において有用です。 ファイルリリースタスクは、 AWS マネジメントコンソール を使用して開始するか、 AWS CLI 、AWS SDK、または一定間隔でリリース・タスクをスケジュールする Amazon EventBridge スケジューラ を使用して API コールを行うことで開始されます。必要に応じて、リリースタスクの終了時に完了レポートを受け取るように選択できます。 リリースタスクの開始 例として、コンソールを使用してリリースタスクを開始する方法を見てみましょう。リリースするファイルの条件 (ディレクトリや最終アクセスからの時間など) を指定するために、リリースデータリポジトリタスク (DRT) を定義します。DRT は、Amazon S3 と同期され、指定された条件を満たすすべてのファイルをリリースします。リリース DRT は順番に処理されるということに注意してください。つまり、別の DRT (インポートやエクスポートなど) の進行中にリリース DRT を送信すると、リリース DRT はキューに入れられますが、インポートまたはエクスポート DRT が完了するまでは処理されません。 注 : データリポジトリの関連付けを機能させるには、ファイルシステムの自動バックアップを無効にする必要があります (これを行うには、 [バックアップ] タブを使用してください)。次に、ファイルシステムと関連付けられた S3 バケットが同じ AWS リージョンにあることを確認します。 FSx for Lustre ファイルシステム my-fsx-test が既にあります。 ファイルシステム上のディレクトリと S3 バケットまたはプレフィックスとの間のリンクである、 データリポジトリの関連付けを作成 します。 ファイルシステムに関連付ける S3 バケット名または S3 プレフィックスを指定します。 データリポジトリの関連付けを作成したら、 [リリースタスクの作成] を選択します。 リリースタスクは、特定の条件に基づいてリリースしたいディレクトリまたはファイルをリリースします (このリリースが機能するためには、これらのファイルまたはディレクトリを S3 バケットと同期する必要があることに再度ご留意ください)。(ディレクトリに加えて) リリースのための最短最終アクセスを指定した場合、それ以降最近にアクセスされていないファイルがリリースされます。 この例では、完了レポートを [無効にする ] を選択しました。しかし、完了レポートを [有効にする] を選択した場合、リリースタスクはリリースタスクの終了時にレポートを生成します。 リリースされたファイルには、既存の FSx for Lustre 機能を使用して引き続きアクセスでき、Amazon S3 からオンデマンドでデータをファイルシステムに自動的に取得することができます。これはリリースされても、メタデータがファイルシステムに残るためです。 ファイルをリリースしても、ファイルシステムが容量一杯となることを自動的に防ぐわけではありません。次のリリースタスクを実行する前に、使用可能なストレージ容量を超えるデータを書き込まないようにすることが重要です。 今すぐご利用いただけます 本日より、FSx for Lustre のファイルリリースは、FSx for Lustre がサポートされているすべての AWS リージョン、Lustre バージョン 2.12 以降を実行しているすべての新規または既存の S3 リンクファイルシステムでご利用いただけます。FSx for Lustre のファイルリリースでは、追加コストは発生しません。ただし、後でファイルシステムから再びアクセスするファイルをリリースした場合、それらのファイルがファイルシステムに読み込まれる際に、通常の Amazon S3 リクエストとデータ取り出しのコストが発生します (該当する場合)。 詳細については、 Amazon FSx for Lustre ページ にアクセスしてください。また、 AWS re:Post for Amazon FSx for Lustre 、または通常の AWS サポートの担当者までフィードバックをぜひお寄せください。 – Veliswa 原文は こちら です。

このブログは 2023 年 6 月 16 日に Sumiran Tandon（Senior Product Manager）と、Rohit Aswani（Senior Specialist Solutions Architect）、Shubham Singh（Senior Network Specialist Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 オンプレミスで利用しているアプリケーションがクラウドのストレージを使用する場合、コンプライアンス要件によりプライベート接続が義務付けられることがよくあります。これらの要件を満たすため、お客様は AWS Direct Connect や、 AWS Site-to-Site VPN 接続経由で AWS PrivateLink を使用して、 Amazon S3（S3） へのプライベート接続を構成します。その結果、AWS 間とデータが直接送信され、パブリックインターネットは経由しません。AWS PrivateLink を使用すると、 Amazon Virtual Private Cloud（VPC） にインターフェイスエンドポイントをプロビジョニングして、プライベート IP アドレスを S3 に割り当てます。AWS PrivateLink は、これらのプライベート IP に対してグローバルで一意のパブリック DNS 名を自動的にプロビジョニングします。アプリケーションはこのパブリック DNS 名を使用して S3 にアクセスできます。S3 のリージョナル名（s3.<Region>.amazonaws.com）を使用する際に、オンプレミスのクライアントがこれらのプライベート IP アドレスを指すように、オンプレミスでカスタム DNS エントリを作成できますが、オペレーションのオーバーヘッドが増え管理が困難になるため、この方法はお勧めできません。 プライベート接続の DNS 設定を簡素化するために、S3 インターフェイス VPC エンドポイント でプライベート DNS オプションを サポート しました。S3 のプライベート DNS を使用することで、オンプレミスのアプリケーションからは AWS PrivateLink を使用してインターフェイス VPC エンドポイント経由で S3 にアクセスができ、VPC 内のアプリケーションからのリクエストについては ゲートウェイ VPC エンドポイント を使用して S3 にアクセスできます。このようにリクエストをルーティングすることで、コードの作成やクライアントの設定を変更しなくても低コストでプライベートネットワーク接続を活用できます。 この記事では、AWS PrivateLink を使用してプライベート DNS で S3 にアクセスする方法を説明します。また、さまざまなシナリオの設定オプションについて検討し、クライアントがゲートウェイ VPC エンドポイントとインターフェイス VPC エンドポイントを経由して S3 に接続していることを確認する方法について説明します。 S3 VPC エンドポイント VPC から S3 への接続に使用できる VPC エンドポイント には、ゲートウェイエンドポイントとインターフェイスエンドポイントの 2 種類があります。 ゲートウェイ VPC エンドポイントは、インターネットゲートウェイや VPC の NAT デバイスを必要とせずに、S3 または Amazon DynamoDB への信頼性の高い接続を提供します。ゲートウェイ VPC エンドポイントは AWS マネジメントコンソールで数回クリックするだけで設定でき、VPC ルートテーブルを使用して VPC 内のクライアントからのリクエストを AWS ネットワーク経由で S3 または Amazon DynamoDB のパブリック IP にルーティングできます。ゲートウェイ VPC エンドポイントには追加料金がかからず、ゲートウェイエンドポイントが作成された各 VPC のローカルリソースからの接続のみがサポートされます。 インターフェイス VPC エンドポイントは、 AWS PrivateLink を使用して 140 を超える AWS サービスとサードパーティ SaaS アプリケーション にプライベート接続を提供します。インターフェイス VPC エンドポイントは、VPC サブネットにプライベート IP アドレスを持つ Elastic Network Interface（ENI）を作成します。インターフェイス VPC エンドポイントは、AWS Direct Connect または AWS Site-to-Site VPN を介したオンプレミスからの接続をサポートします。インターフェイス VPC エンドポイントを設定すると、VPC 内とオンプレミスの両方から名前解決が可能な AWS PrivateLink が提供するエンドポイントのパブリック DNS 名 が作成できます。インターフェイス VPC エンドポイントには 2 つの料金があります。1 つは各アベイラビリティーゾーンでプロビジョニングされる各 VPC エンドポイントの時間単位の料金で、もう 1 つは GB 単位のデータ処理料金です。料金の詳細については、 AWS PrivateLink の料金ページ をご覧ください。 S3 にアクセスする最もコスト効率の高い方法は、可能であれば ゲートウェイ VPC エンドポイントを使用（例：リージョンの Amazon EC2 インスタンスからの接続）し、オンプレミスなど他の場所からの接続の場合は インターフェイス VPC エンドポイントを使用することです。 プライベート DNS 名で S3 インターフェイスエンドポイントにアクセス 図 1 は、AWS Direct Connect または AWS Site-to-Site VPN を介してオンプレミスから接続するハイブリッドネットワーク設定を示しています。このセットアップでは、 Amazon Route 53 インバウンド Resolver エンドポイント を設定し、オンプレミスの DNS リゾルバーで条件付きフォワードを設定して DNS クエリをインバウンド Resolver エンドポイントのプライベート IP アドレスに転送します。次に、S3 のインターフェイス VPC エンドポイントを作成すると、プライベート DNS 名を有効にするオプションが表示されます。 図 1: AWS Direct Connectまたは AWS Site-to-Site VPN 経由でオンプレミスから接続する構成 S3 インターフェイス VPC エンドポイントの プライベート DNS を有効にすると、AWS はプライベートホストゾーンを作成し、VPC に関連付けます。このホストゾーンには、以下の S3 DNS 名のプライベート IP を持つインターフェイス VPC エンドポイントのリソースレコードが含まれます。 リージョナルバケット（例：s3.<Region>.amazonaws.com） コントロール（例：s3-control.<Region>.amazonaws.com） アクセスポイント（例：s3-accesspoint.<Region>.amazonaws.com） サービスのリージョナルや、コントロール、アクセスポイントのエンドポイントにリクエストをすることで、S3 への AWS の プライベートネットワーク接続が使用できます。詳細については「 Amazon S3 用の AWS PrivateLink 」のドキュメントを参照してください。 図 1 のウォークスルー オンプレミスのクライアントより、リージョナル S3 バケットをターゲットにした DNS クエリを実施します。 オンプレミスの DNS サーバーは、AWS Site-to-Site VPN または AWS Direct Connect 接続を介して、S3 インターフェイス VPC エンドポイントを持つ同じ VPC に関連付けられている各 Route 53 インバウンド Resolver エンドポイントにクエリを転送します。 Route 53 インバウンド Resolver エンドポイントは、クエリを AWS が管理する Route 53 ホストゾーンに転送し、DNS 応答で S3 インターフェイス VPC エンドポイントの IP アドレスを返します。 オンプレミスのクライアントは、S3 インターフェイス VPC エンドポイントへ接続します。 S3 インターフェイスエンドポイントは、クライアントのクエリを AWS PrivateLink 経由で指定された S3 バケットに転送します。 New： インバウンドエンドポイントのみプライベート DNS を有効にする 多くのお客様は、オンプレミスと AWS リージョンでアプリケーションを所有しており、どちらも同じ VPC の S3 にデータが格納されています。これらのお客様から、オンプレミスからのトラフィックをインターフェイスエンドポイント経由でルーティングし、AWS 内からのトラフィックをゲートウェイエンドポイント経由で簡単にルーティングする方法が欲しいと言われていました。この課題を解決するために、「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションを導入しました。S3 インターフェイスエンドポイントの「 DNS 名を有効化 」を有効にすると、「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションがデフォルトで有効になります。この場合、オンプレミスから S3 への DNS クエリについては S3 インターフェイスエンドポイントのプライベート IP アドレスに名前解決され、 同じ VPC 内のリソースから S3 への DNS クエリについては引き続きゲートウェイ VPC エンドポイントを使用して S3 のパブリック IP アドレスに名前解決されます。この設定が機能するためには、VPC にゲートウェイエンドポイントが構成されている必要があります。VPC にゲートウェイエンドポイントが構成されていない場合にこの設定を有効にしようとすると、AWS マネジメントコンソールに以下のエラーが表示されます（ 図 2 ）。 「To set PrivateDnsOnlyForInboundResolverEndpoint to true, the VPC <vpce_id> must have a Gateway endpoint for the service.」 これを解決するには、VPC にゲートウェイエンドポイントを作成してください。または「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」を無効にして、すべてのトラフィックをインターフェイスエンドポイント経由でルーティングすることもできます。 図 2: PrivateDNSonlyForInboundEndpoint が有効かつゲートウェインエンドポイント未構成時のエラー 前提条件 まず、以下の前提条件が満たされていることを確認してください。 VPC エンドポイント経由で接続したい S3 バケットと同じリージョンに VPC を作成します。 EnableDNShostNames  と  EnableDNSSupport  の 属性 が true に設定されていることを確認してください。 プライベート仮想インターフェイス（VIF）を使用した AWS Direct Connect 接続もしくは AWS Site-to-Site VPN 接続を作成して、データセンターとの接続を確立してください。 手順 1 で作成した VPC に S3 のゲートウェイ VPC エンドポイント を作成し、「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」を有効にしてください。 S3 インターフェイス VPC エンドポイント作成とプライベート DNS オプション有効化 S3 インターフェイス VPC エンドポイントを作成するために、VPC コンソールに移動し「 エンドポイント 」を選択し、「 エンドポイントを作成 」をクリックしてください。 「 サービスカテゴリ 」で「 AWS のサービス 」を選択します。次に、検索ボックスに「S3」を入力してサービス名をフィルタリングします。「 サービス名 」のサービスが「S3」となっており、「 タイプ 」が「Interface」と表示されていることを確認してください（ 図 3a ）。 図 3a: S3 インターフェイスエンドポイント作成 VPC とアベイラビリティーゾーン、サブネットをそれぞれ選択し、適切なセキュリティグループを選択します。セキュリティグループには、オンプレミスネットワークからのポート 443 のインンバウンドトラフィックを許可するよう構成してください。 「 追加設定 」 で、インターフェイスエンドポイントの「 DNS 名を有効化 」を選択します。デフォルトで「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」は選択されており、VPC 内部からのトラフィックはゲートウェイ VPC エンドポイントを経由し、オンプレミスからのトラフィックはインターフェイス VPC エンドポイントを経由します。 「 エンドポイントを作成 」 を選択します。以下のスクリーンショット（ 図 3b ）を参照してください。 図 3b: プライベート DNS オプションの有効化 エンドポイントはさまざまな ステータス を経て作成されるため少々時間がかかります。インターフェイスエンドポイントのステータスが「使用可能」になったら、「 詳細 」を選択して設定を表示できます（ 図 4a ）。「DNS 名」フィールドに、サービスへのアクセスに使用される DNS 名が表示されます。プライベート DNS を有効にすると、デフォルトの S3 リージョン DNS 名も表示されます。 図 4a: インターフェイス VPC エンドポイントの詳細 「 サブネット 」を選択すると、インターフェイスエンドポイントの場所や、各サブネットのエンドポイントネットワークインターフェイス ID が表示されます。以下のスクリーンショット（ 図 4b ）では、VPC のエンドポイントネットワークインターフェイスのプライベート IP アドレスは 10.0.4.122 と 10.0.23.155 となっています。 図 4b: インターフェイス VPC エンドポイントのサブネット情報 プライベート DNS オプションのシナリオ S3 ゲートウェイとインターフェイス VPC エンドポイントを使用して、VPC とオンプレミスでホストされているアプリケーションから S3 へのクライアント接続に影響を与える DNS オプションのさまざまな組み合わせについて理解しましょう。 シナリオ 1：プライベート DNS 無効 この構成では、ゲートウェイエンドポイントが作成された VPC 内のクライアントからのトラフィックは S3 リージョナルエンドポイントに接続できます。VPC 外のクライアント（オンプレミスまたは相互接続された別の VPC）からは、エンドポイント固有の DNS 名を使用するか、この ブログ で説明しているオプションを使用して S3 に接続できます。プライベート DNS が false に設定されている場合、「インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint）」は設定できません。 このオプションは、独自のプライベートホストゾーンでプライベート DNS 名を柔軟に管理したい場合に便利です。 ゲートウェイエンドポイントを使用する VPC 内のクライアント dig s3. <Region> .amazonaws.com +short 54.x.y.z (Public IP address(es) of S3 service endpoint) エンドポイント固有の DNS 名を使用する VPC またはオンプレミスのクライアント dig *.vpce-0cd6fd8a1a7d95f7e-4nyak8fx.s3. <Region> .vpce.amazonaws.com +short 10.0.23.155 10.0.4.122 上記の出力結果では、VPC 内のクライアントが S3 サービスエンドポイントのパブリック IP アドレスに名前解決されているのに対して、データセンターのクライアントは S3 の VPC エンドポイント ENI IP アドレスに名前解決されていることを示しています。 シナリオ 2：プライベート DNS 有効 この構成では、VPC 内トラフィックとオンプレミストラフィックの両方が S3 インターフェイス VPC エンドポイントを経由して流れます。このオプションは DNS の管理を簡素化するので、1 種類のエンドポイントのみを使用するようにアーキテクチャをシンプルにしたい場合に便利です。ただし、VPC のリソースから S3 へのトラフィックに対して、S3 インターフェイス VPC エンドポイントのデータ転送料金も発生するため、コスト効率の高いソリューションではありません。 図 5 に示すように、緑と青の色は VPC とオンプレミス環境内の EC2 インスタンスから S3 インターフェイス VPC エンドポイントを経由してトラフィックが流れていることを示しています。 図 5: 「プライベート DNS」を有効、「インバウンドエンドポイントのみプライベート DNS を有効にする」を無効 図 5 のウォークスルー 手順 1 ～ 5 はすべて 図 1 で説明した内容と同じです。ただし、 「プライベート DNS」が有効になっているため、VPC 内およびオンプレミスのクライアントのみが S3 インターフェイス VPC エンドポイント経由で S3 に接続します。 VPC 内のクライアント dig s3. <Region> .amazonaws.com +short 10.0.23.155 10.0.4.122 オンプレミスアプリケーションのクライアント dig s3. <Region> .amazonaws.com +short 10.0.23.155 10.0.4.122 上記の出力結果は、VPC 内のクライアントとオンプレミスのクライアントの両方が S3 VPC エンドポイント ENI IP アドレスに解決されていることを示しています。 シナリオ 3：インバウンド Resolver エンドポイントのみにプライベート DNS を使用する この構成では、VPC 内のアプリケーションからのトラフィックはゲートウェイ VPC エンドポイントを経由し、オンプレミスからのトラフィックは S3 インターフェイス VPC エンドポイントを経由します。このオプションでは、VPC およびオンプレミスアプリケーション内から S3 にアクセスする際に費用対効果の高いネットワーク設計を提供します。この構成を選択する際には、VPC 内のゲートウェイ VPC エンドポイントを維持する必要があります。これは、トラフィックが常に AWS プライベートネットワーク上に留まるようにするためです。ゲートウェイエンドポイントがない場合に、VPC 内のトラフィックが誤ってインターネットゲートウェイを経由したり、インターネットゲートウェイがない場合にドロップされる可能性を排除できます。このため、アプリケーションを実行している VPC にゲートウェイ VPC エンドポイントが存在しない場合は「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションが選択できなくなります。既存のインターフェイスエンドポイントを「インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint）」に更新したい場合は、VPC に S3 ゲートウェイ VPC エンドポイントが構成されていることを確認する必要があります。ゲートウェイ VPC エンドポイントとプライベート DNS 名の管理の詳細については、AWS PrivateLink ガイドの「 ゲートウェイエンドポイント 」と「 VPC エンドポイントサービスの DNS 名を管理する 」をそれぞれ参照してください。 図 6  では、青いパスはゲートウェイ VPC エンドポイントを経由する VPC 内の Amazon EC2 インスタンスからのトラフィック示しており、緑のパスはインターフェイス VPC エンドポイントを使用するオンプレミスから S3 へのトラフィックフローを示しています。 図 6: 「プライベート DNS」を有効、「インバウンドエンドポイントのみプライベート DNS を有効にする」を有効 図 6 のウォークスルー 手順 1 ～ 5 はすべて 図 1 説明した内容と同じです。ただし、「 プライベート DNS 」と「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」の両方が有効になっているため、VPC 内のクライアントは S3 のゲートウェイ VPC エンドポイント経由で S3 に接続し、オンプレミスのクライアントは S3 のインターフェイス VPC エンドポイント経由で S3 に接続します。 ゲートウェイエンドポイントを使用する VPC 内のクライアント $ dig s3. <Region> .amazonaws.com +short 54.x.y.z (Public IP address(es) of S3 service endpoint) インターフェイスエンドポイントを使用するオンプレミスのクライアント $ dig s3. <Region> .amazonaws.com +short 10.0.23.155 10.0.4.122 「プライベート DNS」と「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」 の両方が有効になっている場合は、ゲートウェイ VPC エンドポイントを削除できません。削除しようとすると、以下のエラーが出力されます。 「Gateway endpoint cannot be deleted while Interface endpoint for the service has PrivateDnsOnlyForInboundResolverEndpoint set to true.」 上記が発生した場合にゲートウェイ VPC エンドポイントを削除するには、インターフェイス VPC エンドポイントを変更し「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」 オプションの選択を解除する必要があります。 まとめ この記事では、S3 インターフェイス VPC エンドポイントにプライベート DNS を使用して、オンプレミスアプリケーションを変更せずに S3 にアクセスする方法について説明しました。S3 へのネットワーク接続を最適化するために「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションを使用する方法について説明しました。これらのオプションを使用すると、コードの作成やクライアントに設定変更をしなくても、低コストのプライベートネットワーク接続が活用できます。S3 用の AWS PrivateLink の使用を開始するには、この ページ にアクセスしてください。 S3 用の AWS PrivateLink の詳細については、以下のブログを参照してください。 Secure hybrid access to Amazon S3 using AWS PrivateLink Choosing Your VPC Endpoint Strategy for Amazon S3 AWS Partners use AWS PrivateLink to connect privately to Amazon S3 翻訳はプロフェッショナルサービス本部の葉山が担当しました。 Sumiran Tandon Sumiran は、ワシントン州シアトルに拠点を置く Amazon S3 チームの AWS のシニアプロダクトマネージャーです。彼女は、顧客が複雑なビジネス上の課題を解決できるように、革新的でお客様中心の製品を構築することに重点を置いています。彼女はデューク大学でMBAの学位を取得しています。 Rohit Aswani Rohit は、AWS のネットワーキングを専門とするシニアスペシャリストソリューションアーキテクトであり、スケーラブルで可用性が高く、安全で、回復力があり、費用対効果の高いネットワークをお客様が構築および設計できるよう支援しています。ノースイースタン大学でコンピューターネットワークを専門とする電気通信システム管理の修士号を取得しています。余暇には、Rohit はハイキング、旅行、新しいコーヒーショップの探索を楽しんでいます。 Shubham Singh Shubham は AWS のシニアネットワークスペシャリストソリューションアーキテクトです。彼は、お客様が AWS サービスを使用して革新的で回復力があり、費用対効果の高いソリューションを設計できるよう支援しています。彼はテクノロジーに情熱を注いでおり、ネットワークとセキュリティのソリューションを構築することを楽しんでいます。ノースイースタン大学でコンピューターネットワークを専門とする電気通信システム管理の修士号を取得しています。

第 5 回の AWS Storage Day へようこそ! このバーチャルイベントは、8月9日、太平洋標準時の午前 9:00 (東部標準時正午) に開催され、 AWS On Air Twitch チャンネル で視聴できます。最初の AWS Storage Day は 2019 年に開催されました。このイベントはイノベーションデーへと発展し、毎年皆様をお迎えできることを楽しみにしています。 昨年の Storage Day の投稿 で、データを安全に保護しながら活用できるようにすることを目指した AWS Storage の絶え間ない革新について書きました。今年の Storage Day は、AI/ML 用のストレージ、データ保護と耐障害性、およびクラウドへの移行のメリットに焦点を当てています。 AWS Storage Day の主要テーマ AI/ML 用のストレージ に関しては、データ量はかつてない速度で増加しており、テラバイトからペタバイト、さらには エクサバイトにまで 急増しています。AWS の最新のデータアーキテクチャでは、 スケーラブルなデータレイク を迅速に構築し、目的別に構築された幅広いデータサービスを使用したり、パフォーマンスを犠牲にすることなくシステムを低コストで拡張したり、組織の境界を越えてデータを共有したり、コンプライアンス、セキュリティ、ガバナンスを管理したりできるため、規模を問わず迅速かつ機敏に意思決定を行うことができます。 機械学習モデルをトレーニングして 生成系 AI アプリケーションを構築 するには、適切なデータ戦略を策定する必要があります。ライブイベントで楽しみにしているセッションのリストの中で、 Optimize generative AI and ML with AWS Infrastructure (生成系 AI と ML を AWS インフラストラクチャで最適化する) セッションでは、データを有意義なインサイトに変換する方法について話し合います。 クラウドを使い始めたばかりか、 アプリケーションを AWS に移行することを計画しているか 、既に AWS でアプリケーションを構築しているかにかかわらず、 データを保護し、事業継続目標を達成する のに役立つリソースがあります。当社の データ保護 と 耐障害性 の機能およびソリューションは、目標復旧時点 (RPO) と目標復旧時間 (RTO) 全体にわたって、ビジネス継続性目標を達成し、データ損失が発生した際のディザスタリカバリを実現するのに役立ちます。今日、世界では前例のないほどのデータ増加が起こっているため、データの保存場所、保護方法、およびデータにアクセスできるユーザーの決定は、かつてないほど優先度が高まっています。 Protect data in AWS amid a rapidly evolving cyber landscape (急速に進化するサイバー情勢の中で AWS でデータを保護する) セッションにぜひ参加して、詳細をご覧ください。 データを クラウドに 移動 する場合、さまざまなユースケースに合わせてどこにデータを移動するか、移動するデータの種類、利用可能なネットワークリソースなどを把握する必要があります。クラウドに移行する理由はたくさんあります。最近、 Enterprise Strategy Group (ESG) は、組織がオンプレミスのワークロードを AWS クラウドインフラストラクチャに移行することで、コンピューティング、ネットワーク、およびストレージのコストを最大 66% 削減したことを検証しました。ESG は、オンプレミスのワークロードを AWS に移行することで、組織はコストの削減、パフォーマンスの向上、運用効率の向上、価値実現までの時間の短縮、ビジネスの俊敏性の向上を実現できることを確認しました。 お客様のユースケースに基づいて、クラウドへの移行方法について説明するセッションを多数用意しています。私が最も楽しみにしているのは、 Hybrid cloud storage and edge compute: AWS, where you need it (ハイブリッドクラウドストレージとエッジコンピューティング: 必要な場所で AWS) セッションです。このセッションでは、完全にクラウドに移行できないワークロードに関する考慮事項について説明します。 これらすべてのテーマなどに対応する AWS Storage サービスの幅広いポートフォリオ や機能に関連する新しい発表、リーダーシップに関するインサイト、教育コンテンツについて、専門家から話を聞きましょう。本日、 Amazon Simple Storage Service (Amazon S3) 、 Amazon FSx for Windows File Server 、 Amazon Elastic File System (Amazon EFS) 、 Amazon FSx for OpenZFS などに関する発表があります。 以下に詳細を示します。 Amazon EBS の 15 年 少し前に、 Jeff Barr の「AWS ブログを執筆して 15 年」というタイトルの記事 を読みました。 この記事では、Jeff が初期の AWS のサービスと機能について執筆した記事をいくつか紹介しています。 Amazon Elastic Block Store (Amazon EBS) は、 Amazon EC2 の使用を簡素化するサービス としてこのリストに含まれています。 Amazon EBS の発売が発表されてから 15 年が経ち、8月9日、このサービスの 15 周年を祝います。Amazon EBS を有効に活用し、当社が考案と簡素化、繰り返し、改善に役立つ非常に有益なフィードバックを提供してくれた最初のユーザーの一人なら、光陰矢の如しと感じていらっしゃることでしょう。現在、Amazon EBS は毎日 100 兆件を超える I/O オペレーションを処理しており、毎日 3 億 9,000 万を超える EBS ボリュームが作成されています。 Amazon EBS を初めてご利用になる場合は、AWS のセールス、マーケティング、グローバルサービス担当シニアバイスプレジデントである Matt Garman との炉辺談話にご参加ください。2008 年のサービス開始の背景にあった戦略とお客様が抱えていた課題についてお話します。また、EBS の長期顧客である Stripe から、12 年前に Stripe が設立されて以来 EBS とともに成長してきた話も聞くことができます。 Amazon EBS は、Amazon EC2 インスタンスの直接的なストレージアタッチメントとして、より多くのお客様のワークロードをサポートするために、スケーラビリティとパフォーマンスを継続的に改善してきました。8 月 2 日、カスタム第 4 世代 Intel Xeon Scalable プロセッサを搭載した Amazon EC2 M7i インスタンスがリリース されたことで、前世代 M6i インスタンスの 28 個から増加し、最大 128 個の Amazon EBS ボリュームをアタッチできます。ボリュームアタッチメントの数が多いほど、インスタンスあたりのストレージ密度を高め、リソース使用率を向上させ、総コンピューティングコストを削減できます。 大規模なデータベースアプリケーションでは、1 インスタンスあたり最大 127 のコンテナをホストでき、コスト効率の高い方法でスケーリングできます。これにより、追加のインスタンスをプロビジョニングする必要がなくなり、必要なリソースに対してのみ支払いが発生します。ボリュームアタッチメントの数が多いほど、データベースのストレージフットプリントが拡大しても、このような強力な M7i インスタンスで利用できるメモリと vCPU を最大限に活用できます。また、EBS では、作成できるマルチボリュームスナップショットの数を増やしており、最大 128 個の EBS ボリュームをインスタンスにアタッチできます。これにより、インスタンスにアタッチされたすべてのボリュームの Crash-consistent バックアップを作成できます。 15 years of innovations with Amazon EBS (Amazon EBS とともにイノベーションを起こして 15 年) セッションに参加して、Amazon EBS の最初のビジョンが、クラウドインフラストラクチャに対するお客様の高まる需要を満たすためにどのように進化してきたかについて話し合いましょう。 Mountpoint for Amazon S3 現在一般提供されている Mountpoint for Amazon S3 は、高スループットのアクセスを実現し、Amazon S3 上のデータレイクのコンピューティングコストを削減する新しいオープンソースのファイルクライアントです。Mountpoint for Amazon S3 は、ローカルファイルシステム API 呼び出しを S3 オブジェクト API 呼び出しに変換するファイルクライアントです。Mountpoint for Amazon S3 を使用すると、Amazon S3 バケットをローカルファイルシステムとしてコンピューティングインスタンスにマウントし、Amazon S3 の伸縮自在なストレージとスループットを備えたファイルインターフェイスを介してオブジェクトにアクセスできます。Mountpoint for Amazon S3 は、 既存のファイルに対する順次読み取り操作とランダム読み取り操作、および新しいファイルを作成するための順次書き込み操作 をサポートします。 Deep dive and demo of Mountpoint for Amazon S3 (Mountpoint for Amazon S3 の詳細説明とデモ) セッションでは、ファイルクライアントを使用してファイル API を使って Amazon S3 のオブジェクトにアクセスする方法を示します。これにより、データを大規模に保存しやすくなり、分析と機械学習のワークロードによってデータの価値を最大化できるようになります。 このブログ記事 を読んで、Mountpoint for Amazon S3 の詳細と開始方法 (デモを含む) をご覧ください。 Amazon S3 Glacier Flexible Retrieval でコールドストレージをより迅速に稼働させる Amazon S3 Glacier Flexible Retrieval は、追加費用なしでデータ復元時間を最大 85% 短縮します。 Amazon S3 バッチオペレーション を使用する際、より高速なデータ復元が自動的に標準取得層に適用されます。これらの復元は数分以内にオブジェクトを返し始めるため、復元されたデータをより迅速に処理できます。復元されたデータを継続的な復元と並行して処理することで、データワークフローを加速し、ビジネスニーズに迅速に対応できます。これで、メディアのトランスコーディング、運用バックアップの復元、機械学習モデルのトレーニング、履歴データの分析を行っていようと、アーカイブからのデータ復元を高速化できます。 2022 年に発表された、 S3 Glacier を改善して数百万のオブジェクトに対して最大 10 倍のスループットを復元できるようにしたこと と相まって、あらゆる規模の S3 Glacier データ復元で、開始時間の短縮と完了時間の短縮というメリットがもたらされました。 Maximize the value of cold data with Amazon S3 Glacier (Amazon S3 Glacier でコールドデータの価値を最大化する) セッションに参加して、あらゆる規模のあらゆる業界の組織がデータアーカイブを変革してビジネス価値を引き出し、俊敏性を高め、ストレージコストを節約する上で、Amazon S3 Glacier がどのように役立つかを学んでください。 このブログ記事 を読んで、Amazon S3 Glacier Flexible Retrieval のパフォーマンスの向上について詳しく学び、S3 Glacier Flexible Retrieval からより高速な標準取り出しを開始する方法についてのステップバイステップのガイダンスをご覧ください。 幅広いファイルワークロードをサポート ファイルシステムに依存する幅広いユースケースに対応するため、当社はそれぞれ異なるニーズに対応したファイルシステムサービスのポートフォリオを用意しています。 Amazon EFS は、コンピューティングリソース間でデータを共有するために柔軟なエクスペリエンスが得られるように構築されたサーバーレスファイルシステムです。Amazon FSx を使用すると、機能豊富で高性能なファイルシステムをクラウドで簡単かつ費用対効果の高い方法で起動、実行、拡張できます。これにより、コード、プロセス、またはデータの管理方法を変更せずにクラウドに移行できます。 Amazon EFS で ML 研究とビッグデータ分析を強化する Amazon EFS は、ストレージ容量とスループットパフォーマンスの両方で高いスケーラビリティを実現するように設計された、サーバーレスで完全にスケーラブルなファイルストレージを提供します。ちょうど7月31日週、より高速な読み取り/書き込み IOPS のサポートが強化され、より要求の厳しいワークロードの処理が容易になったことを発表しました。Amazon EFS のパフォーマンス性能が向上し、ファイルシステムあたり最大 55,000 件の読み取り IOPS と最大 25,000 件の書き込み IOPS がサポートされるようになりました。このようなパフォーマンスの強化により、KubeFlow による機械学習 (ML) 研究、IBM Symphony による金融シミュレーション、Domino Data Lab、Hadoop、Spark によるビッグデータ処理など、より要求の厳しいワークフローの実行を支援します。 Build and run analytics and SaaS applications at scale (分析と SaaS アプリケーションを大規模に構築して実行する) セッションに参加して、最近の Amazon EFS パフォーマンスの改善がどのようにさらに多くのワークロードの強化に役立つかを聞いてください。 Amazon FSx for OpenZFS のマルチ AZ ファイルシステム Amazon FSx for OpenZFS でファイルシステムを作成する際にマルチ AZ 配置オプションを使用できるようになりました。これにより、複数の AWS アベイラビリティーゾーンにまたがるファイルストレージを簡単にデプロイできるようになり、ビジネスクリティカルなワークロードにマルチ AZ レジリエンスを提供できます。今回のリリースでは、Amazon FSx for OpenZFS のパワー、俊敏性、シンプルさを活用して、幅広いワークロードに対応できます。これには、複数の AZ にまたがる可用性の高い共有ストレージを必要とするデータベース、基幹業務、ウェブサービスアプリケーションなどのビジネスクリティカルなワークロードが含まれます。 新しいマルチ AZ ファイルシステムは、さまざまなワークロードに対応する高レベルのパフォーマンスを実現するように設計されています。これには、金融サービス分析、メディアおよびエンターテイメントワークフロー、半導体チップ設計、ゲーム開発およびストリーミングなどのパフォーマンスを重視するワークロードが含まれ、頻繁にアクセスされるキャッシュデータでは最大 21 GB/秒のスループットで 100 万 IOPS、永続ディスクストレージからアクセスするデータでは最大 10 GB/秒で 350,000 IOPS を実現します。 Migrate NAS to AWS to reduce TCO and gain agility (NAS を AWS に移行して TCO を削減し、俊敏性を向上させる) セッションに参加して、Amazon FSx for OpenZFS によるマルチ AZ について詳しく学びましょう。 Amazon FSx for Windows File Server の新しい、より高いスループットキャパシティレベル Amazon FSx for Windows File Server のパフォーマンスの向上により、SQL Server データベース、メディア処理、クラウド動画編集、仮想デスクトップインフラストラクチャ (VDI) など、パフォーマンスを重視するワークロードの結果が出るまでの時間を短縮できます。 4 つの新しい高スループットキャパシティレベルを追加して、使用可能な最大 I/O を以前の I/O である 2 GB/秒から最大 12 GB/秒に増やします。このようなスループットの向上は、それに応じてディスク IOPS のレベルも高くなり、最大 350,000 IOPS まで向上するように設計されています。 さらに、FSx for Windows File Server を使用することで、SSD ファイルシステムのデフォルトの 3 IOPS/GiB よりも高い IOPS をプロビジョニングできます。これにより、SSD IOPS をストレージ容量とは無関係にスケールできるため、パフォーマンスが重視されるワークロードのコストを最適化できます。 Migrate NAS to AWS to reduce TCO and gain agility (NAS を AWS に移行して TCO を削減し、俊敏性を向上させる) セッションに参加して、Amazon FSx for Windows File Server のパフォーマンス向上について詳しく学びましょう。 AWS Backup 用の論理的にエアギャップのあるボールト AWS Backup は、フルマネージド型のポリシーベースのデータ保護ソリューションです。これにより、お客様は (コンピューティング、ストレージ、データベースにわたる) 19 の AWS サービスと、VMware Cloud on AWS やオンプレミスなどのサードパーティーアプリケーション、および SAP HANA on Amazon EC2 にわたってバックアップの復元を一元化および自動化できます。 8月9日、マルウェアイベントを軽減するための追加の保護レイヤーとして機能する新しいタイプの AWS Backup Vault として、 論理的にエアギャップのあるボールトのプレビューを発表しました 。論理的にエアギャップのあるボールトにより、お客様は別の信頼できるアカウントを通じてアプリケーションデータを回復できます。 Deep dive on data recovery for ransomware events (ランサムウェアイベントの際のデータ復旧に関する詳細情報) セッションに参加して、AWS Backup の論理的にエアギャップのあるボールトについて詳しく学びましょう。 AWS DataSync を使用して他のクラウドとの間でデータをコピーする AWS DataSync はオンラインのデータ移動および検出サービスです。これにより、データ移行が簡素化され、ファイルまたはオブジェクトデータを AWS ストレージサービスとの間で迅速、簡単、安全に転送できます。DataSync は、AWS ストレージサービスとの間でのデータ移行のサポートに加えて、Google Cloud Storage、Azure Files、Azure Blob Storage などの他のクラウドとの間のコピーもサポートしています。DataSync を使用すると、他のクラウド上の Amazon S3 互換ストレージと Amazon S3 などの AWS ストレージサービスとの間でオブジェクトデータを大規模に移動できます。現在、他のクラウドとの間でデータをコピーできるように DataSync のサポートを拡大しており 、DigitalOcean Spaces、Wasabi Cloud Storage、Backblaze B2 Cloud Storage、Cloudflare R2 Storage、Oracle Cloud Storage などもサポートされています。 Identify and accelerate data migrations at scale (大規模なデータ移行を識別し促進する) セッションに参加して、この DataSync のサポートの策だいについて詳しく学びましょう。 オンラインでご参加ください Twitch の AWS On Air チャンネルで AWS Storage Day のバーチャルイベントに今すぐご参加ください 。このイベントは、太平洋標準時の 8 月 9 日の午前 9 時 (東部標準時正午) からライブ配信が始まります。すべてのセッションは、Storage Day の約 2 日後にオンデマンドで提供される予定です。 お会いできるのを楽しみにしています! –  Veliswa  原文は こちら です。