調査に参加した通信事業者の半数が今後2年以内の生成系AIの活用を計画し、生成系AIへの支出が現在の最大6倍に拡大すると予測 AWS通信およびエッジクラウド担当 チーフテクノロジストIshwar Parulkar（イシュワール・パルルカー） 生成系AIは、あらゆる場で活用され、すべての産業に大きなインパクトをもたらすとAWSは考えています。生成系AIは機械学習の普及に続く新たな波であり、通信業界を含む業界で、お客様体験や多様なビジネスアプリケーションを革新する可能性を秘めています。 AWSは、通信業界における生成系AIへの展望や論調、活用状況に対する理解を深めるため、戦略コンサルティング企業であるAltman Solonと協力し、北米、西欧、アジア太平洋地域の通信事業者の幹部100名以上を対象とした調査を実施しました。主な調査結果は以下のとおりです。 1.  生成系AIの活用は今後2年間で大きく拡大 通信事業者の4つの業務領域（製品・マーケティング、カスタマーサービス、ネットワーク、社内IT）をまたぐ17のユースケースについて調べたところ、生成系AIを既に活用しているか、活用に向けて取り組んでいるとした回答者は全体の19%でした。この数値は今後、さらに拡大する見込みで、調査結果によると1年以内に34%、2年以内に半数近く（48%）に達する見込みです。これに伴い、生成系AIへの支出も現在の最大6倍に急拡大する可能性があります。この急拡大を牽引するユースケースはチャットボットですが（詳細は後述）、通信事業者の64%は、検討している生成系AIのユースケースの多くが、既存のアプリケーションやプロセスではまだ実現されていない新たなアプリケーションだと述べています。 2. 北米の通信事業者が生成系AIの活用で他地域をわずかにリード 生成系AIの活用では、北米の通信事業者がわずかに先行しています（22%が活用、または活用に向けて既に取り組む）。欧州の通信事業者（同19%）は、EUの一般データ保護規則（GDPR）などのデータレジデンシーに関する域内規制のため、生成系AIの活用には、より慎重な姿勢を見せています。特に北米以外の通信事業者にとっては、AI活用やデータ規制、データレジデンシーに関する現行および今後の規制が重要な考慮点となります。中国やEUの多くでAI規制やAIへの監視が強化されているのに対し、米国やインドでは、規制や監視に関して、より消極的です。 アジア太平洋地域の通信事業者（同16%）は、他地域と比べ緩やかなデータ規制の環境にいますが、言語などのローカライゼーションの課題に面しています。生成系AIの多くは大規模言語モデル（LLM）をベースとしており、特定言語のデータコーパスによるトレーニングが必要です。現在の主要なLLMの多くは英語で構築・提供されており、AWSはこの溝を埋めるべく取り組んでいます。例えば、2023年7月に日本で発表した「 AWS LLM開発支援プログラム 」は、日本におけるLLM開発の加速を支援するもので、総額600万米ドル規模のAWSクレジットを提供するなど、LLMの多様性を推進する取組を進めています。 3.  顧客対応チャットボットが生成系AIのユースケースとして、いち早く普及 生成系AIがまずは顧客対応チャットボットに取り入れられていることは自然な流れであり、本調査でも広く活用される見込みであることが分かりました。回答者の92%が、導入の可能性の高いものとしてカスタマーサービスとチャットボットを挙げています。そのうち63%が、すでに開発を進めていると回答しました。 これは既存の基盤モデルを活用するものであり、最初の段階としては正しい方向である一方、将来的には生成系AIがネットワーク運用を支援すると、AWSは考えています。例えば、生成系AIは、通信事業者がネットワーク要素をインストールする際に参考とするマニュアルからデータを取り込むことができます。このデータをチャットボットと組み合わせることで、プロンプトに基づくインタラクティブなガイダンスを提供できるようになり、インストール作業のスピードアップや簡素化につながります。 他の主要なユースケースは、カスタマーサービス、ITにおけるガイド付き支援や文書作成など、社員の生産性向上を支援するものです。 活用ステージ別生成系AIユースケース （全回答者に占める割合。回答者数はユースケースごとに異なる） ※現在、取り組んでいる、または、高い可能性のもとで検証しているとした回答者の割合 4.   データセキュリティとガバナンスが生成系AI活用における最大のチャレンジであり、実現に向けた重要なイネーブラー 生成系AIの活用には、一方で課題があります。本調査に協力した通信事業者の約3分の2（61%）が、データセキュリティ、プライバシー、ガバナンスに関する懸念を表明しました。通信事業者が自社の業務に生成系AIを活用するには、各社が保有する膨大な量のデータが必要となります。広く利用可能なLLMはありますが、自社保有のデータがこうしたモデルそのものに組み込まれることには、知的財産権上の懸念があります。 ある通信事業者のIT部門責任者は、次のように話しています。「当社データのセキュリティを確保し、第3者に使用されないよう徹底する必要があります」 AWSはこうしたお客様の懸念を踏まえ、Amazon Bedrockではお客様のデータが利用する基盤モデルの学習に使用されないようにする機能が組み込まれています。お客様のデータはプライベートかつセキュアに保護されます。 この調査ではまた、アーリーアダプターのうち、データ習熟度上位30%の組織においては、生産性向上以外のユースケースでの生成系AIの活用が進んでいることが明らかになりました。例えば、製品・マーケティングなど、収益創出を目指したユースケースです。データ活用が進むこうした組織では、AIを専門とするセンターオブエクセレンスが設置されていること、高度なデータアナリティクスの活用が進んでいること、最新のデータ基盤（クラウドなど）が整備されていることなど、共通の特徴があります。 5.  通信事業者は、自社開発よりも、既存モデルの活用を想定 生成系AI活用における課題として技術的リソースの不足を挙げる通信事業者もありました。このような背景を考えると、社内で基盤モデルを構築したいと回答した通信事業者は15%にとどまり、その他は既存の基盤モデルの活用を想定していることも驚きではありません。回答者の約4分の3（65%）は既存の基盤モデルを社内の専有データで追加学習し、各社それぞれのニーズに対応させたいと考えています。私たちは、データ基盤のモダナイゼーションにおいて強固な基礎を保有するアーリーアダプターが独自の基盤モデルを構築する15%の層となり、マネタイゼーションに向けて新たな道を切り拓くものと考えています。 通信事業者はファインチューニングされた基盤モデルとともに、AWSのような大規模言語モデルへのアクセスを提供するベンダーに開発環境や専門的なサービスを提供してほしいと考えています。あるワイヤレス通信事業者の高度アナリティクス担当ゼネラルマネージャーが、「個人的には、これが通信業界における生成系AI活用において重要な促進剤になると思います」と述べているように、回答した通信事業者の44%は、フルマネージドサービス基盤を活用し、その基盤上で提供される基盤モデルを利用してアプリケーションを構築したいと考えています。 生成系AIはお客様のビジネスや顧客価値の提供を変革する大きな可能性を秘めています。私たちは、企業のニーズに合った柔軟なアプローチを提供することに注力しており、AWS InferentiaやAWS Traniumなど機械学習に最適化したAWS独自設計のクラウドインフラを活用して自社で基盤モデルを構築する、あるいは、Amazonの基盤モデル（Amazon Titan、Alexa）やサードパーティーの基盤モデルを活用してアプリケーションを開発する、Amazon BedrockやAmazon SageMaker Jumpstartといったサービスを活用して、基盤モデルにデータを追加してファインチューニングするの複数の選択肢をご用意しています。加えて、基盤モデルやAI、機械学習テクノロジーに関する専門知識なしにご利用いただける、Amazon CodeWhisperer、Amazon Quicksightなどの生成系AIアプリケーションもあります。 どのように生成系AIへの取り組みに着手するにせよ、通信事業者にとって最も重要なのは、今すぐ試行錯誤を開始することです。 生成系AIの現在、そして将来的な活用を展望した調査結果の詳細は、 調査レポート（英語） よりご覧ください。 このブログは、英文での 原文ブログ を参照し、アマゾン ウェブ サービス ジャパン合同会社　広報チームが翻訳・執筆しました。

みなさん、こんにちは、カスタマーソリューションマネージャー (CSM) の西口です。このブログ記事では、CSM としてお客様のクラウド活用やクラウド移行の加速をご支援している経験を踏まえ、クラウドの体験型ワークショップ (Experience-Based Acceleration(EBA)) の Party の一つである EBA FinOps Party をご紹介します。 FinOps という用語を皆さまご存じでしょうか。もしかするとあまり馴染みのない用語かもしれません。同じような用語でより耳にすることの多い DevOps が Development (開発) と Operations (運用) が密に連携して、高い品質を確保しつつ開発速度の向上と運用の効率化を目的とした取り組みを指しますが、それと同じように、FinOps は Financial (財務) と DevOps (開発および運用) が密に連携して、クラウドの費用予測や計画をより精微化しコストを最適化することで、財務の面でもクラウドリソースの効率的な利用を進めることを意味しています。 お客様はこの FinOps の一部の取り組みを EBA による実践的なアプローチで体験することが可能です。 EBA ではクラウド利用や移行におけるお客様課題に対して 5 つの Party と呼ばれるワークショップを提供しています。EBA FinOps Party はそのうちの一つです。この EBA FinOps Party を通じて、お客様ご自身で自らの部門やシステムを対象に FinOps を実践します。 EBA の詳細は こちら の記事をご確認ください。 EBA FinOps Party は、移行を行った後などでクラウドの支出が増えており組織として最適化したい、オンプレミスとクラウドの財務の考え方の違いが整理できておらず適切にクラウドを活用できているか自信がない、クラウドの費用計画では財務部門と IT 部門の連携が必要であることは理解しているが連携の一歩が踏み出せない、といったお客様に特におすすめします。 EBA FinOps Partyを実践する効果 EBA FinOps Party を実践する効果として、お客様内のコスト管理を担当する組織 (財務部門、業務部門、IT 部門) が「コストを最適化し続ける」意識を持つための契機を作ることができます。 昨今、IT システムのクラウド化をお客様クラウド推進組織 (Cloud Center of Excellence) が推進していただいている成果として、大変多くのお客様に AWS をご利用いただいています。しかし、それと並行して、景気の低迷や急激な円安によりクラウドの利用料が想定していたよりも高騰し、ビジネス課題として「コスト『削減』」が挙げられることも多くなってきました。これらに対し、AWS では単純な「削減」作業を実施するのではなく、定常的に無駄なコストを減らし適切なコスト状態とするための「最適化」活動として FinOps の実施および活動の定着を推奨をしています。この活動を実践するためのフレームワークが Cloud Financial Management  (CFM) です。 EBA FinOps Party は、このフレームワークと最適化手法をお客様が理解し、定常的な活動計画の立案までを体験するプログラムです。 EBA FinOps Partyでのアジェンダ例 今回のブログでは、日本のお客様向けアジェンダ例をご紹介します。日本では、お客様環境を変更するためのプロセスとして変更作業前に財務部門やアプリケーションチームとの協議、承諾といったプロセスが存在していたり、事前に手順検証を実施しリスクを軽減しておくといったプロセスが存在していることが多く、ワークショップ中に環境を変更するにはとてもハードルが高いと推測します。 そのため、日本のお客様向け EBA FinOps Party ではまず FinOps を始める契機を作ることを目的とし、以下 3 つに焦点を当てています。 CFM フレームワークを理解、認識する コスト最適化が可能な箇所の確認および最適化の手法を理解する エグゼクティブスポンサーからコスト最適化活動に対する支援を獲得する 標準的なアジェンダ例として、Day1 : 基礎編、Day2 : 実践編、Day3 : 報告会の 3 日間です。特に Day2 ではハンズオンやデモを取り入れ、活動施策を Day3 に向けた宿題として検討します。そして Day3 で施策を発表することで定量的な最適化成果を明示的に意識する内容となっています。これにより参加者に「コスト最適化活動し続ける」意識を高める体験を得ることができます。 Day1 (基礎編) ： CFM フレームワーク (座学) AWS の提唱する CFM フレームワークに関して、コストを最適化し続ける重要性と4つの柱「可視化」、「最適化」、「計画・予測」、「 FinOps の実践」を実現するための取組をセミナー形式で実施します。 Day2 (実践編) ：コスト最適化⼿法についての AWS サービスのハンズオンやデモ Day2 では、お客様課題に合ったコスト最適化手法について AWS サービスのハンズオンやデモをご提供します。 ※一例　 AWS Cost Explorer を用いたお客様のご利用状況確認手順ハンズオン、 AWS Budgets や AWS Instance Scheduler 、 Amazon QuickSight のデモまた、このハンズオンやデモの内容を踏まえ、参加メンバーには Day3 へ向けてご自身が関係するシステムやプロジェクトにおける最適化活動施策をご検討いただくことを宿題としてお渡しします。 Day3 (報告会) ：施策報告 Day2 で宿題として検討した最適化活動施策を、エグゼクティブに向けに発表します。エグゼクティブ向けに発表を行うことで、エクゼクティブには今後この施策を後押ししていただけるスポンサーになっていただくことを目的としています。 FinOps ベストプラクティス CFM フレームワークにもあるとおり、 4 つの柱のうち「可視化」、「最適化」、「計画・予測」の 3 つアクションを定常的に「 FinOps の実践」として実施することが非常に重要です。  可視化 AWS コスト配分タグ や AWS Cost Categories を用いたタグ付け戦略の策定、 AWS Cost Explorer や Amazon QuickSight を利用しお客様のクラウド利用料をグラフ化することで、「最適化」を行う対象リソースの可視化を行います。 最適化 「可視化」により確認した対象に対し、AWS の提唱する最適化手法である「クイックウィン最適化」あるいは「アーキテクチャ最適化」を計画、実施します。 クイックウィン最適化 適切なインスタンスサイズの選定、未使用リソースの停止等ご利用環境にて、オペレーションすることで最適化を実践できる手法です。 アーキテクチャ最適化 IaC による運用の自動化やサーバレス、マネージメントサービスの利用といったクラウドネイティブ化することで最適化を実践できる手法です。 計画・予測 新しいシステムの導入やサービスへの機能追加などによりクラウド環境が拡大する等、ビジネス状況を鑑みたクラウド利用料の計画、予測を行い、 AWS Budgets や Amazon Forecast 、 AWS Cost Anomaly Detection を利用しモニタリングします。 AWS Budgets 設定した予算に対し、閾値を設定することでその閾値を超過した場合、E メールまたは SNS 通知によるアラート通知が可能です。 Amazon Forecast AWS Cost Explorer では過去 12 か月分のデータを基にした予測となりますが、Amazon Forecast は AWS Cost and Usage Reports の請求情報データから機械学習を用いて、クラウド利用料の予測を行います。 AWS Cost Anomaly Detection AWS サービスの利用状況を機械学習モデルにより学習し、ベースラインを設け、このベースラインから大きく逸脱した値を「異常」として検知し、E メールまたは SNS 通知によるアラート通知が可能です。 コスト最適化を実践しているお客様事例 FinOps として CFM フレームワークの可視化、最適化、計画・予測を実践することで、コストの最適化がより身近になり、定常的なコスト最適化活動に一歩近づくでしょう。ここではコスト最適化活動を実践しているお客様の例を紹介します。 ナビタイムジャパン様 では、CFM による包括的なコスト最適化の診断の結果、ストレージコストを約 10% 削減しました。また EC2 のダウンサイジングなど 段階的なアプローチを行い、インフラコストはオンプレミス比で 30% の削減を達成できています。加えて、次世代プロセッサーを具備した最新世代のインスタンスへ変更したことにより、さらなるコスト削減とパフォーマンス向上を見込んでいます。 また、 NTT ドコモ様 では、IT 部門と利用部門に対して意識改革を促すため、CFM ワークショップを実施し、コストの最適化を進めた結果、過去の最大利用料より 30% のコストを削減しました。他のお客様においても、EBA FinOps Party を実施した結果、金融業界のお客様で約 120,000 USD、通信業界のお客様で約 500,000 USD、製造業のお客様で約 190,000 USD のコスト最適化を見込んでいます。 EBA FinOps Partyの始め方 EBA FinOps Party は、AWS のクラウド移行トータル支援プログラムである「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー 」の準備・移行フェーズにおける継続的なコスト最適化支援の無償プログラムの一つです。 EBA FinOps Party または AWS IT トランスフォーメーションパッケージにご興味ある方のご利用に向けた入り口は 2 つあり、 1) Web フォーム からお問い合わせ、 2) 担当営業までご連絡、どちらからでも可能です。 AWS へのコンタクトをお待ちしております。 参考情報 AWS によるクラウド財務管理 コスト最適化のためのアーキテクチャベストプラクティス コスト最適化の柱 – AWS Well-Architected フレームワーク AWS コスト最適化フレームワーク– AWS へ移行前後のコスト最適化を通してイノベーションを加速させる クラウド財務管理はコスト削減以上のメリットをもたらす アプリケーションのモダナイゼーションを加速する EBA Level up your Cloud Transformation with Experience-Based Acceleration (EBA) AWS ITトランスフォーメーションパッケージ 2023 ファミリー(ITX 2023) Vega Cloud brings FinOps solutions to their customers faster by embedding Amazon QuickSight AWS 導入事例：株式会社ナビタイムジャパン | AWS AWS 導入事例: NTTドコモ | AWS

AWS Glue Studio は AWS Glue DataBrew と統合されました。 AWS Glue Studio は、 AWS Glue で抽出、変換、ロード (ETL) ジョブを簡単に作成、実行、監視できるようにするグラフィカルインターフェイスです。 DataBrew は、コードを書かずにデータをクレンジングおよび正規化できる可視的なデータプレパレーションツールです。DataBrewで提供されている 200 を超える変換ステップを、AWS Glue Studio ビジュアルジョブで使用できるようになりました。 DataBrew において、レシピは、直感的なビジュアルインターフェイスで対話的に作成できる一連のデータ変換ステップです。このブログでは、DataBrew でレシピを作成し、それを AWS Glue Studio ビジュアル ETL ジョブの一部として適用する方法を説明します。 既存の DataBrew ユーザーもこの統合の恩恵を受けることができます。高度なジョブ設定と最新の AWS Glue エンジンバージョンを使用できることに加えて、AWS Glue Studio が提供している他のすべてのコンポーネントを使用して、より大規模なビジュアルワークフローの一部としてレシピを実行できるようになります。 この統合により、両方のツールの既存ユーザーに明確なメリットがもたらされます。 AWS Glue Studio では、全体的な ETL ダイアグラムをエンドツーエンドで一元的に表示できます。 DataBrew コンソール上で、値・統計・分布を確認しながらレシピをインタラクティブに定義し、テストおよびバージョン管理された処理ロジックを AWS Glue Studio ビジュアル ジョブで再利用できます。 AWS Glue ETL ジョブで複数の DataBrew レシピを統合でき、AWS Glue ワークフローを使用して複数のジョブを統合できます。 DataBrew レシピでは、増分データ処理のためのブックマーク、自動再試行、自動スケール、小さなファイルのグループ化などの AWS Glue ジョブ機能を使用して効率化を図ることができるようになります。 ソリューション概要 今回のユースケース例では、このブログ用に作成された医療請求データセットをクレンジングすることが要件となります。サンプルデータには、データプレパレーションにおける DataBrew の機能を実践するために意図的にいくつかのデータ品質の問題を組み込んでいます。次に、別のデータソースから取得した医療事業者に関する関連情報を追加して、請求データをデータカタログに取り込みます。 (そうすることでアナリストが可視化できるようになります)。 このソリューションは、請求データと医療事業者データの 2 つの CSV ファイルを読み取る AWS Glue Studio ビジュアルジョブで構成されます。このジョブは、データの品質問題に対処するために、請求データにレシピを適用させて、医療事業者データから必要な列を選択した上で、両方のデータセットを結合して、最後に結果を Amazon Simple Storage Service (Amazon S3) に保存して、データカタログ上にテーブルを作成します。出力データは、 Amazon Athena などの他のツールで使用できます。 DataBrew レシピの作成 まず、サンプルデータとして、請求データをデータストアに登録します。そうすることで、実際のデータを使用してインタラクティブエディターでレシピを作成できるようになり、変換を定義する際にその結果をレビューできるようになります。 次のリンクから請求データの CSV ファイルをダウンロードします: alabama_claims_data_Jun2023.csv 。 DataBrew コンソールのナビゲーション ペインで [データセット] を選択し、[新しいデータセットの接続] を選択します。 [ファイルをアップロード] オプションを選択します。 [データセット名] に Alabama Claims と入力します。 [アップロードするファイルを選択します] で、ローカル PC にダウンロードしたファイルを選択します。 [S3 送信先を入力] で、使用しているAWSアカウントとリージョンにあるバケット名を入力または参照します。 残りのオプションはデフォルトのままにし (CSV はカンマとヘッダーで区切られます)、データセットの作成を完了します。 ナビゲーションペインで [プロジェクト] を選択し、[プロジェクトの作成] を選択します。 プロジェクト名として、 ClaimsCleanup と入力します。 [レシピの詳細] の [アタッチされたレシピ] で、[新しいレシピを作成] を選択し、名前を ClaimsCleanup-recipe とし、 Alabama Claims データセットを選択します。 DataBrew に 適切な既存の IAM ロール を選択するか、新しい IAM ロールを作成します。これで、プロジェクトの作成は完了です。 以上で、構成可能なデータのサブセットを使用してセッションが作成されます。セッションの初期化が完了すると、一部のセルに無効な値または欠落した値が含まれていることがわかります。 Diagnosis Code 、 Claim Amount 、および Claim Date の列の値が欠落しており、データの一部の値には余分な文字が含まれています。 Diagnosis Code の値には「code 」(スペースが含まれる) という接頭辞が付く場合があり、 Procedure Code の値には、末尾に一重引用符が付いています。 Claim Amount の値は一部の計算に使用される可能性があるため、数値型に変換し、 Claim Date は Data 型に変換する必要があります。 対処すべきデータ品質の問題を特定したので、各問題をどのように対処するかを決定する必要があります。 レシピステップを追加するには、列のコンテキストメニュー、上部のツールバー、またはレシピの概要からなど、複数の方法があります。最後の方法を使用すると、指定されたステップタイプを検索して、このブログで作成したレシピを複製できます。 今回のユースケースでは Claim Amount は不可欠な値であるため、欠損のある行を削除することにします。 [欠損した値を削除] のステップを追加します。 ソース列で、[Claim Amount] を選択します。 デフォルトのアクション [欠落した値がある行を削除する]のままにし、[適用] を選択して保存します。 ステップの適用を反映してビューが更新され、 Claim Amount が欠損している行はなくなりました。 Diagnosis Code は空でもよいですが、 Claim Date には合理的に推測された値が必要です。データ内の行は時系列で並べ替えられるため、プレビューの前の行の有効な値を使用して、欠落している日付を代入できます。毎日請求が発生していると仮定すると、最大の問題は、その日の最初の請求データの日付が欠落している場合に、プレビューの日付が割り当てられてしまうことです。今回は説明のために、潜在的なエラーは許容できると考えてみましょう。 まず、列を string 型から date 型に変換します。 [型の変更] のステップを追加します。 ソース列として [Claim Date] を選択し、型として[date] を選択し、[適用] を選択します。 次に、欠落した日付を代入するために、[欠落した値を埋める/帰属] ステップを追加します。 ソース列に [Claim Date]、アクションとして [最後の有効な値で埋める] を選択します。 [変更のプレビュー] を選択して検証し、[適用] を選択してステップを保存します。 下記の画像のように、ここまででレシピには 3 つのステップが存在しているはずです。 次に、[引用符の削除] ステップを追加します。 ソース列に [Procedure Code]、削除する値に [先頭と末尾の引用符] を選択します。 プレビューにてステップが反映されていることを確認し、新しいステップとして適用します。 [特殊文字を削除] のステップを追加します。 ソース列に [Claim Amount] 選択し、[カスタム特殊文字] の [カスタム特殊文字を入力] に $ を入力します。 [型を変更] ステップを追加し、ソース列 [Claim Amount] 、タイプを [double] とします。 最後のステップとして、余分な “code ” プレフィックスを削除するために、[値またはパターンの置き換え] ステップを追加します。 ソース列で [Diagnosis Code] を選択し、[カスタム値を入力] に code と入力します (末尾にスペースを入れます)。 サンプルで特定したすべてのデータ品質の問題に対処したので、プロジェクトをレシピとして公開します。 レシピペインで [発行] を選択し、オプションでバージョンの説明を入力してレシピの発行を完了します。 発行するたびに、異なるバージョンのレシピが作成され、使用するレシピのバージョンを選択できるようになります。 AWS Glue Studio でビジュアル ETL ジョブを作成 次に、レシピを使用するジョブを作成します。次の手順を実行します。 AWS Glue Studio コンソールのナビゲーションペインで [Visual ETL] を選択します。 [Visual with a blank canvas] を選択し、ビジュアル ジョブを作成します。 ジョブの上部の “Untitled job” を任意の名前に置き換えます。 [Job Details] タブで、ジョブが使用するロールを指定します。 これは、Amazon S3 および AWS Glue データカタログへのアクセス許可を持つ、 AWS Glue に適した AWS Identity and Access Management (IAM) ロールである必要があります。先ほど DataBrew で使用したロールはジョブの実行には使用できないため、ここでは [IAM ロール] ドロップダウン メニューにはリストされないことに注意してください。 DataBrew ジョブとは違い、AWS Glue Studio では、ワーカー サイズ、自動スケーリング、 柔軟な実行 などのパフォーマンスとコストの設定を選択できるほか、最新の AWS Glue 4.0 ランタイムを使用することで大幅なパフォーマンスの改善を受けることができることに注目してください。このジョブでは、デフォルトの設定を使用できますが、節約のためにワーカーの数を減らします。この例では、2 Wokers で十分です。 [Visual] タブで、S3 ソースを追加し、 Providers という名前を付けます。 S3 URL には、 s3://awsglue-datasets/examples/medicare/Medicare_Hospital_Provider.csv と入力します。 データフォーマットとして [CSV] を選択し、[Infer schema] を選択します。 これで、ファイルヘッダーを使用してスキーマが [Output schema] タブにリストされます。 このユースケースでは、providers データセット内のすべての列を必要としないため、残りは削除できます。 Providers ノードを選択した状態で、Transforms で [Drop Fields] を追加します (Node parents を選択しなかった場合は、Node parents を手動で割り当てます)。 Provider Zip Code 以降のフィールドをすべて選択します。 その後、この Providers データを、Alabama 州の 請求データと結合します。ただし、2 番目のデータセットには州の情報がありません。Providers データから、必要なデータをフィルタリングすることで結合を最適化できます。 [Drop Fields] の子としてTransforms から[Filter] 追加します。 Alabama providers と名前を付け、Provider State が AL と一致するという条件を追加します。 2番目のソース (新しい S3 ソース) を追加し、 Alabama claims という名前を付けます。 S3 URL を入力するには、別のブラウザ タブで DataBrew を開き、ナビゲーションペインで [データセット] を選択し、表に表示されている Alabama claims の場所をコピーします (http リンクではなく、s3:// で始まるテキストをコピーします)。次に、ビジュアルジョブに戻り、S3 URL 欄に貼り付けます。正しい場合は、[Output schema] タブにデータフィールドがリストされていることがわかります。 CSV 形式を選択し、他のソースの場合と同様に [infer schema] します。 このソースの子として、ノードの追加メニューで recipe と検索し、[Data Preparation Recipe] を選択します。 新しいノードのプロパティで、 Claim cleanup Recipe という名前を付け、先ほど発行したレシピとバージョンを選択します。 ここでレシピの手順を確認し、必要に応じて DataBrew へのリンクを使用して変更を加えることができます。 結合ノードを追加し、 Alabama providers と Claim cleanup recipes の両方を親として選択します。 両方のソースの provider ID を結合条件として追加します。 最後のステップとして、S3 ノードをターゲットとして追加します (検索時に表示される最初のノードはソースであることに注意してください。ターゲットとして表示されるものを必ず選択してください)。 ノード設定では、デフォルト形式の JSON のままにし、ジョブの IAM ロールが書き込み権限を持つ S3 URL を入力します。 さらに、データ出力をカタログ内のテーブルとして利用できるようにします。 [データ カタログの更新オプション] セクションで、上から 2 番目のオプション [データ カタログにテーブルを作成し、その後の実行でスキーマを更新し、新しいパーティションを追加する] を選択し、テーブルを作成する権限があるデータベースを選択します。 名前を alabama_claims とし、partition key として Claim Date を選択します (これは説明のためであり、今回のような小さなテーブルでは、後でデータを追加しない場合、実際にはパーティションを必要としません)。 ジョブを保存してジョブを実行します。 [Run] タブでは、ジョブ ID リンクを使用してプロセスを追跡し、詳細なジョブメトリクスを確認できます。 ジョブが完了するまでに数分かかります。 ジョブが完了したら、Athena コンソールに移動します。 選択したデータベースでテーブル alabama_claims を検索し、コンテキスト メニューを使用して [テーブルのプレビュー] を選択します。これにより、テーブルに対して単純な SELECT * SQL ステートメントが実行されます。 ジョブの結果から、データが DataBrew レシピによってクレンジングされ、AWS Glue Studio の結合処理によって強化されたことがわかります。 Apache Spark は、AWS Glue Studio で作成されたジョブを実行するエンジンです。生成されるイベント ログ上で Spark UI を使用すると、ジョブの計画と実行に関するインサイトを表示でき、ジョブのパフォーマンスと潜在的なパフォーマンスのボトルネックを理解するのに役立ちます。たとえば、大規模なデータセットに対するこのジョブの場合、これを使用して、結合処理を実行する前にプロバイダーの状態を明示的にフィルタリングすることの影響を比較したり、自動バランス変換を追加して並列処理を改善することでメリットが得られるかどうかを確認できます。 デフォルトでは、ジョブは Apache Spark イベント ログを s3://aws-glue-assets-<アカウント ID>-<リージョン名>/sparkHistoryLogs/ のパスに保存します。ジョブを表示するには、 いずれかの方法 を使用して History server をインストールする必要があります。 後片付け このソリューションが不要になった際は、Amazon S3 に格納された生成ファイル、ジョブによって作成されたテーブル、DataBrew レシピ、および AWS Glue ジョブを削除してください。 まとめ このブログでは、AWS DataBrew のインタラクティブエディターを使用してレシピを作成し、発行されたレシピを AWS Glue Studio ビジュアル ETL ジョブの一部として使用する方法を説明しました。データプレパテレーションを実施して、AWS Glue Catalog のテーブルにデータを取り込む際に必要な一般的なタスクの例をいくつか含めました。 この例ではビジュアルジョブで 1 つのレシピを使用しましたが、ETL プロセス内で複数のレシピを使用したり、複数のジョブで同じレシピを再利用することも可能です。 これらの AWS Glue ソリューションを使用すると、コードを記述することなく、構築と運用が簡単な高度な ETL パイプラインを効果的に作成できます。両方のツールを組み合わせたソリューションをすぐに開始できます。 この記事は、Sr. Software Dev Engineer の Mikhail Smirnov とSr. Big Data Architect の Gonzalo Herreros が執筆しています。日本語訳はソリューションアーキテクトの三宅が翻訳しました。原文は こちら です。 執筆者について Mikhail Smirnov is a Sr. Software Dev Engineer on the AWS Glue team and part of the AWS Glue DataBrew development team. Outside of work, his interests include learning to play guitar and traveling with his family.   Gonzalo Herreros  is a Sr. Big Data Architect on the AWS Glue team. Based on Dublin, Ireland, he helps customers succeed with big data solutions based on AWS Glue. On his spare time, he enjoys board games and cycling.

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週、東京リージョンで利用開始になったことが話題になった Amazon Bedrock をはじめとして、AWSでは多様な生成系AI（Generative AI）サービスが用意されていますが、その生成系AIに関するイベントが今週17日（火）から3日間の日程で開催されます。生成系AIやLLMの基本が学べる初日、ユーザー事例多数の2日目、BedrockをはじめとするAWSサービスの高度な使い方を解説する3日目と充実した内容になっています。オンライン開催でどこからでも参加できますので、ご興味がある方はぜひ以下より登録してご参加ください。 – 生成系 AI を中心とした AI 最前線がここに AWS AI Week For Developers それでは、先週の主なアップデートについて振り返っていきましょう。 2023年10月9日週の主要なアップデート 10/9(月) AWS Glue now supports GitLab, BitBucket in its Git integration feature AWS Glue はETL処理のためのソースコードをGitサービスで管理することが可能です。これまではAWS CodeCommitおよびGitHubに対応していましたが、今回の発表でGitLabとBitBucketに対応し、より多様なコード管理環境に対応可能になりました。 AWS Verified Access is now available in two additional AWS regions AWS Verified Access が利用可能なリージョンとして、東京リージョンおよびシンガポールリージョンが追加されました。Verified Access はゼロトラストの基本原則に基づいて社内リソースにアクセス可能にするための環境を提供するサービスです。 10/10(火) Amazon Linux announces support for Ansible and Corretto 21 with AL2023.2 Amazon Linux 2023 の四半期アップデートの2回目、AL2023.2がリリースされました。これには無料のOpenJDKディストリビューションである Amazon Corretto 21 とAnsibleが含まれています。Amazon Linux 2023のリリースの考え方は こちらのブログ をご覧ください。 Announcing pgactive: Active-active Replication Extension for PostgreSQL on Amazon RDS pgactive が Amazon RDS for PostgreSQL で利用可能になりました。PostgreSQL 15.4-R2以降で利用可能です。pgactiveは複数のPostgreSQLデータベース間でactive-activeのレプリケーションを実現するextensionです。詳細は こちらのブログ をご覧ください。 10/11(水) Amazon FSx for NetApp ONTAP is now available in the AWS Asia Pacific (Osaka) Region Amazon FSx for NetApp ONTAP が大阪リージョンで利用可能になりました。Amazon FSx for NetApp ONTAP はフルマネージドの共有ストレージであり、 ONTAP のデータアクセスおよび管理機能が利用可能なサービスです。東京リージョンのFSx for Netapp ONTAPと SnapMirror によるレプリケーションを利用することも可能です。 New Amazon CloudWatch metric monitors EC2 instance reachability to EBS volumes Amazon CloudWatch にAttached EBS Status Check (StatusCheckFailed_AttachedEBSメトリクス)が追加されました。EBSボリュームとEC2間で通信が可能か、IO操作が可能かをチェックするメトリクスで、これを監視することでEBSボリュームで異常が発生した際に素早く問題に気づくことができます。 10/12(木) Amazon SageMaker Canvas expands content summarization and information extraction capabilities コードの記述なしで、機械学習モデルの学習や利用ができる Amazon SageMaker Canvas では、すぐに利用できる(ready-to-use)モデルとして、生成系AIのFM（Anthropic Claude 2 や Amazon Titan など）を利用した、コンテンツの要約と情報抽出(content summarization and information extraction)が用意されています。今回追加機能として、ユーザーが提供するドキュメント（インデックス）を指定可能になりました。現時点ではAmazon Kendraがドキュメントソースとして利用可能です。これによりKendraに格納した情報を知識源としたチャットベースの分析環境をコーディング不要で実現可能です。 AWS Step Functions launches Optimized Integration for Amazon EMR Serverless AWS Step Functions が Amazon EMR Serverless をネイティブにサポートし、EMR Serverless の API Actionとして CreateApplication, StartApplication, StopApplication, DeleteApplication, StartJobRun, CancelJobRun が呼び出せるようになりました。 Announcing new AWS Network Load Balancer (NLB) availability and performance capabilities AWS Network Load Balancer (NLB)で新たに3つの機能が追加されました。1つ目は Availability Zone DNS affinity で、DNSで同一AZ内でのターゲットを返す機能、2つ目は disable connection termination for unhealthy targets　でヘルスチェックに失敗した接続の切断をしないようにする機能、3つ目は UDP connection termination by default で、UDP接続にデフォルトでタイムアウトが設定されるようになったというものです。 Announcing AWS Lambda’s support for Internet Protocol Version 6 (IPv6) for outbound connections in VPC AWS Lambda で dual-stack構成のVPC内のリソースにIPv6でアクセスすることが可能になりました。これにより、VPC内のIPv4アドレスの残量を気にすることなくLambda関数を並列実行できるようになり、より大規模な利用がしやすくなりました。 10/13(金) Amazon EC2 C7gd, M7gd, and R7gd instances now available in additional regions Amazon EC2 の C7gd, M7gd, R7gd インスタンスが新たに東京リージョンとシンガポールリージョンで利用可能になりました。AWS Graviton3プロセッサに加え、ローカルストレージを搭載したインスタンスです。また、合わせて C7gd がシドニーリージョンで利用可能になったことがアナウンスされています。 Deploy ML models built in SageMaker Canvas to SageMaker real-time endpoints Amazon SageMaker Canvas では作成したMLモデルにデータを与えることでバルクで予想を出力させることが可能ですが、今回、これに加えてリアルタイム予測エンドポイントをデプロイすることが可能になりました。アプリケーションからAPIで呼び出すことで、リアルタイムに予測値を得ることが可能です。 Amazon EC2 now supports setting AMIs to a disabled state EC2のAmazon Machine Images (AMIs) でAMIをdisable（無効）に設定可能になりました。以前にパブリックに公開したAMIであっても、disableするとそこからEC2を起動することはできなくなります。 余談ですが、最後に紹介したAMIのアップデートの文中で、”Amazon Machine Images (AMIs; pronounced ah-mee)”という珍しい注記が含まれていました。AMI＝アーミィと発音しますということなのですが、良く質問があったのでしょうか？ちなみに筆者（下佐粉）は、エーエムアイ派です：） それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

北半球は美しい初秋の季節です。米国では地元のファーマーズマーケットやコーヒーショップがパンプキンに占領されています。re: Invent 2023まで後 50 日です。 Pre:Invent の公式シーズンの前に、10月2日週のエキサイティングなニュースや発表をいくつか見てみましょう。 10月2日週のリリース 私が注目したリリースを以下に記載しました。 AWS Control Tower – AWS Control Tower は、お客様の規制要件を満たし、転送中のデータの暗号化、保管中のデータの暗号化、強力な認証の使用などの統制目標を満たすために役立つ 22 のプロアクティブコントロールと 10 の AWS Security Hub 発見的コントロールをリリースしました。コントロールの詳細とリストについては、 AWS Control Tower ユーザーガイド を参照してください。 Amazon Bedrock – 米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンで Amazon Bedrock の提供 が開始されてからわずか 1 週間後、Amazon Bedrock は アジアパシフィック (東京) の AWS リージョンで利用可能 になりました。基盤モデルで生成系 AI アプリケーションの構築とスケーリングを開始するには、 Amazon Bedrock ドキュメント を参照して、 community.aws の生成系 AI スペース を探索し、 Amazon Bedrock ワークショップ の演習を利用してください。 Amazon OpenSearch Service – 検索、オブザーバビリティ、セキュリティ分析、機械学習 (ML) 機能が強化された OpenSearch バージョン 2.9 を Amazon OpenSearch Service で実行できるようになりました。OpenSearch Service は、バージョン 2.9 で 地理空間集約サポートを拡張 し、傾向とパターンの高レベルの概要のインサイトを収集してデータ内の相関関係を確立できるようになりました。OpenSearch Service 2.9 には、OpenTelemetry などの新しいスキーマ標準を活用するための OpenSearch Service Integrations も付属 するようになりました。また、ダッシュボードでの アラートと異常の管理、および視覚化折れ線グラフへのオーバーレイ が可能になりました。 Amazon SageMaker – SageMaker 特徴量ストアが、完全マネージド型のインメモリオンラインストアをサポート するようになり、高スループットの ML アプリケーション用のモデル提供に必要な特徴量をリアルタイムで取得できます。新しいオンラインストアは、オープンソースの Redis 上に構築されたインメモリデータストアである ElastiCache for Redis を利用しています。詳細については、 SageMaker デベロッパーガイド を参照してください。 また、 SageMaker Model Registry はプライベートモデルリポジトリのサポートを追加 しました。プライベート Docker リポジトリに保存されているモデルを登録し、複数のプライベート AWS モデル リポジトリと AWS 以外のモデルリポジトリにわたるすべてのモデルを 1 つの中央のサービスで追跡できるようになったので、スケールでの ML 運用 (MLOps) と ML ガバナンスを簡素化できます。使用を開始する方法については、 SageMaker デベロッパーガイド を参照してください。 Amazon SageMaker Canvas – SageMaker Canvas のサポートが拡張され、すぐに使えるモデルに基盤モデル (FM) が含まれるようになりました 。ノーコードのチャットインターフェースから、Claude 2、Amazon Titan、Jurassic-2 (Amazon Bedrock 搭載) などの FM だけでなく、Falcon や MPT (SageMaker JumpStart 搭載) などの公開されているモデルにもアクセスできるようになりました。詳細については、 SageMaker デベロッパーガイド を参照してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース 興味深いと思われるその他のブログ投稿とニュース項目をいくつかご紹介いたします。 オープンソースデータベースへの AWS の貢献の舞台裏 – この投稿では、過去 2 年間に AWS がアップストリームのデータベースに対して行ってきた重要なオープンソースの貢献をいくつか紹介するとともに主要な貢献者を紹介し、AWS がデータベースサービスのアップストリーム作業にどのように取り組んでいるかを紹介します。 AWS Trainium による迅速で費用対効果の高い Llama 2 の微調整 – この記事では、LLM トレーニング専用のアクセラレータである AWS Trainium で Meta の Llama 2 モデルを微調整してトレーニング時間とコストを削減する方法を紹介します。 Meta の Code Llama コード生成モデルが Amazon SageMaker JumpStart で利用可能に – Meta が開発した Code Llama FM を ワンクリックで SageMaker JumpStart にデプロイできるようになりました。この投稿では、詳細が手順ごとに説明されています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 Build On Generative AI – 生成系 AI のすべてを網羅した 週刊 Twitch ショー のシーズン 2 が盛り上がりを見せています。 毎週月曜日 9:00 (米国太平洋標準時) に同僚の Emily と Darko が AWS の新しい技術的および科学的パターンについて考察し、ゲストスピーカーを招いてその作業のデモを行い、生成系 AI の状態を改善するために構築されたものを紹介します。 今日のエピソード では、Emily と Darko が非構造化ドキュメントを構造化データに変換する方法について解説しました。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーたちが主催するコミュニティ主導のカンファレンスにご参加ください: DMV (DC、メリーランド、バージニア) (10 月 13 日)、 イタリア (10 月 18 日)、 UAE  (10 月 21 日)、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、 ブラジル (11 月 4 日)。 AWS Innovate: Every Application Edition  – 無料のオンラインカンファレンスに参加して、セキュリティと信頼性の強化、予算内でのパフォーマンスの最適化、アプリケーション開発のスピードアップ、生成系 AI でのアプリケーションの革新を実現する最先端の方法を探索してください。10 月 19 日の AWS Innovate Online アメリカ地区 と EMEA 、および 10 月 26 日の AWS Innovate Online アジアパシフィックと日本 に登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください 。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent のハイライト をチェックしてください。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 10月9日週はここまでです。10月16日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

コンピューティング最適化 Amazon EC2 C6a インスタンス は 2022 年 2 月にリリースされました。これは、第 3 世代 AMD EPYC (Milan) プロセッサを搭載しており、最大 3.6 GHz の周波数で動作します。 10月4日、最大周波数 3.7 GHz の第 4 世代 AMD EPYC (Genoa) プロセッサを搭載した新しいコンピューティング最適化 Amazon EC2 C7a インスタンスの一般提供の開始をお知らせします。このインスタンスでは、C6a インスタンスと比べてパフォーマンスが最大 50% 向上しています。このパフォーマンスの向上により、データ処理の高速化、ワークロードの統合、保有コストの削減を実現できます。 C7a インスタンスは、C6a インスタンスと比較して最大 50% 高いパフォーマンスを実現します。これらのインスタンスは、高性能ウェブサーバー、 バッチ処理 、 広告配信 、 機械学習 、 マルチプレイヤーゲーム 、 動画エンコーディング 、科学モデリングなどの ハイパフォーマンスコンピューティング (HPC) 、 機械学習 などのコンピューティングを多用するワークロードの実行に最適です。 C7a インスタンスは、 AVX-512、Vector Neural Network Instructions (VNNI) 、および bfloat16 (brain floating point) をサポートします。これらのインスタンスは、メモリ内のデータへの高速アクセスを可能にする Double Data Rate 5 (DDR5) メモリを備えており、前世代のインスタンスと比較して 2.25 倍のメモリ帯域幅を提供してレイテンシーを低減します。 C7a インスタンスは、最大 192 個の vCPU と 384 GiB の RAM を備えています。これにより、新しい中サイズのインスタンスが利用して、ワークロードのサイズをより正確に調整できるようになりました (1 個の vCPU、2 GiB を提供します)。詳細な仕様は次のとおりです。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c7a.medium 1 2 最大 12.5 最大 10 c7a.large 2 4 最大 12.5 最大 10 c7a.xlarge 4 8 最大 12.5 最大 10 c7a.2xlarge 8 16 最大 12.5 最大 10 c7a.4xlarge 16 32 最大 12.5 最大 10 c7a.8xlarge 32 64 12.5 10 c7a.12xlarge 48 96 18.75 15 c7a.16xlarge 64 128 25 20 c7a.24xlarge 96 192 37.5 30 c7a.32xlarge 128 256 50 40 c7a.48xlarge 192 384 50 40 c7a.metal-48xl 192 384 50 40 C7a インスタンスは最大 50 Gbps の拡張ネットワーキングと 40 Gbps の EBS 帯域幅を備えており、最大 128 個の EBS ボリュームをインスタンスにアタッチできます (前世代のインスタンスの EBS ボリュームアタッチメントは最大 28 個)。 C7a インスタンスは、AMD セキュアメモリ暗号化 (SME) を使用した常時オンのメモリ暗号化と、暗号化および復号アルゴリズム、畳み込みニューラルネットワーク (CNN) ベースのアルゴリズム、財務分析、および動画エンコーディングワークロードを高速化するための新しい AVX-512 命令 をサポートします。また、C7a インスタンスは、セキュリティを強化するために AES-256 をサポートします (C6a インスタンスでは AES-128)。 これらのインスタンスは AWS Nitro System 上に構築されており、ハイパフォーマンスコンピューティングや動画処理など、ネットワークレイテンシーの低減や、高度にスケーラブルなノード間通信の恩恵を受けるワークロード向けに Elastic Fabric Adaptor (EFA) をサポートしています。 今すぐご利用いただけます Amazon EC2 C7a インスタンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用できるようになりました。Amazon EC2 でのお支払いと同じように、使用した分の料金のみをお支払いいただきます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 EC2 C7a インスタンスページ と AWS/AMD パートナーページ を参照してください。 ec2-amd-customer-feedback@amazon.com 、 AWS re:Post for EC2 、または通常の AWS サポートの担当者を通じて、ぜひフィードバックをお寄せください。 — Channy 原文は こちら です。

2023 年 10 月 5 日木曜日に開催される参加無料のオンラインイベントである Data and Generative AI Day にぜひご参加ください。AWS は、 LinkedIn Live や YouTube などの複数のプラットフォームでイベントを同時にストリーミングします。 生成系 AI の領域では、組織のデータに秘められた力と可能性がこれまで以上に大きくなっています。生成系 AI には、顧客とのやり取りを再構築し、従業員の生産性を向上させ、創造的なアイデア出しを刺激し、画期的なイノベーションを推進する力があります。しかし、先進的なリーダーとして、このデータ駆動型の可能性を最大限に活用し、それを目に見える成果に変えるには、どのようなステップが必要となるのでしょうか? この半日間のイベントでは、AWS のエキスパート、パートナー、お客様、主要なスタートアップが、今日の進化し続ける環境の中で、データと生成系 AI を使用してイノベーションを推進する取り組みについてのインサイトを提供します。この革新的なテクノロジーがもたらすさまざまな機会や課題にどのように対応すべきかについて、業界リーダーからの実践的なガイダンスを得ながら、同時に将来に何が待ち受けているかを感じ取ることができます。 このイベントで予定されているハイライトをいくつかご紹介します。 AWS の Database, Analytics, and ML 担当 VP である Swami Sivasubramanian がイベントの開始に際して基調講演を行い、ビジネスリーダー向けにデータと AI を民主化するための青写真を共有します。Swami は、リーダーが生成系 AI の可能性を実際のビジネス価値に変えるための正しい考え方、戦略、ツールをどのように採り入れることができるのかについて語ります。 AWS の Enterprise Strategy 担当 Director である Tom Godden は、生成系 AI を活用してビジネスの成果を推進するための実践的な戦略について詳しく説明します。Tom は、組織全体で生成系 AI を試験運用する機会を特定するためのフレームワークを共有するとともに、これらの強力な新機能の活用方法について、ビジネスリーダーが時宜にかなったかたちで理解できるように説明します。 Informatica の Strategic Cloud Ecosystems 担当 Vice President である Gopinath Sankaran 氏は、生成系 AI がデータ管理に及ぼす影響に関するインサイトを共有するとともに、Informatica の AI を活用した Intelligent Data Management Cloud と AWS の AI および分析サービスが、インサイトとエクスペリエンスの新しい波をどのように強化できるかを探ります。 Deloitte の Data & AI 担当 Managing Director である Diego Saenz 氏と、Deloitte の Global Financial Services Industry (GFSI) Data, Analytics, & AI 担当 Principal の Jojy Matthew 氏は、綿密に練られたデータ戦略が、生成系 AI の成功にとって何を意味するかを共有します。Diego は、生成系 AI を活用してビジネス成果を推進するためにデータ資産の準備が整っているかどうかを評価するための実践的なアドバイスを共有します。 AWS のリーダー、ならびに AWS のお客様である FOX、Salesforce、および Booking.com は、データと生成系 AI に関する取り組みを共有し、この革新的なテクノロジーを活用して顧客と従業員のエクスペリエンスを再考する方法について説明します。 イベントページ でご登録いただくと、カレンダーにイベントリマインダーを追加できます。 当日お会いできるのを楽しみにしています。 – Irshad 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、列レベルのデータ暗号化をサポートしています。列レベルの暗号化では、すべての列または選択した列に適用できるより詳細なレベルのデータを暗号化できます。列レベルの暗号化では、列ごとに異なる暗号化キーを定義できます。 SQL Server では、接続、データ、ストアドプロシージャに暗号化を使用できます。暗号化の詳細については、「 SQL Server 暗号化 」を参照してください。 この投稿では、Amazon RDS for SQL Server に列レベルの暗号化を実装する方法を紹介します。 SQL Server の暗号化 Amazon RDS は、 データベースインスタンス 、 自動バックアップ 、 リードレプリカ 、 スナップショット の基盤となるストレージを保護するために、 AWS Key Management Service (AWS KMS) を使用して 保存時の暗号化 をネイティブに提供します。 Amazon RDS for SQL Server は、Microsoft SQL Server Enterprise Edition と Standard Edition でサポートされている透過的データ暗号化 (TDE) をサポートしています。 TDE はデータベース内の機密データを暗号化し、証明書を使用してデータを暗号化するキーを保護します。このソリューションでは、キーを持っていない人がデータを使用できないようにします。この種の保護は事前に計画しておく必要があります。TDE は、データおよびログファイルの I/O 暗号化と復号化をリアルタイムで行います。暗号化にはデータベース暗号化キー (DEK) を使用します。データベースブートレコードには、復旧時に使用できるようにキーが保存されます。DEK は対称キーです。サーバーのプライマリデータベースに保存される証明書または EKM モジュールが保護する非対称キーによって保護されます。 TDE は保存中のデータ、つまりデータファイルとログファイルを保護します。これにより、さまざまな業界で確立されている多くの法律、規制、ガイドラインに従うことができます。この機能により、ソフトウェア開発者は既存のアプリケーションを変更せずに AES および 3DES 暗号化アルゴリズムを使用してデータを暗号化し、データがストレージから読み取られるとデータを自動的に復号化できます。不正な復号化を防ぐために、TDE は暗号化キーをデータベース外部のセキュリティモジュールに保存します。データベースレベルの完全な暗号化を実装したいと考えているなら、TDE は良い選択肢です。 TDE はデータベース全体を暗号化しますが、列レベルの暗号化ではデータベース内の個々の列を暗号化できます。暗号化を行うと、対応する復号化キーやパスワードがないとデータが役に立たなくなります。暗号化を行ってもアクセス制御の問題は解決されません。ただし、一部のユースケースでは、アクセス制御がバイパスされてもデータ損失が制限され、セキュリティが強化されます。たとえば、データベースホストコンピューターの設定に誤りがあってハッカーが機密データを入手した場合、盗んだ情報が暗号化されていれば役に立ちません。 ソリューション概要 SQL Server の列レベルのデータ暗号化は、暗号化階層に基づいています。暗号化階層は、データと暗号化キーを保護するために使用されます。階層レベルは以下のとおりです。 Windows レベル – このレベルは、Windows データ保護 (DP) API を使用して次のレベルを暗号化して保護します。 SQL Server レベル – このレベルには Windows レベルで保護されているサービスマスターキー (SMK) が含まれています。SMK は次のレベルを保護するために使用されます。 データベースレベル – このレベルには、データベースマスターキー (DMK) と残りのキーと証明書が含まれます。DMK はデータベース内の証明書、対称キー、非対称キーを暗号化して保護します。 次の図は、完全な暗号化階層 ( Microsoft ドキュメント にあるアーキテクチャリファレンス) を示しています。 列レベルの暗号化は、対称キーまたは非対称キーをそれぞれ証明書またはパスワードと組み合わせて使用することで実現できます。次の図は、列レベルの対称暗号化と非対称暗号化の概要を示しています。 以下のセクションでは、両方の実装方法を示します。 方法 1: 対称キーによる列暗号化 対称キーによる列レベルの暗号化の実装手順は次のとおりです。 RDS インスタンスで、次のコマンドを使用して SMK が存在することを確認します。 Use Master go select * from sys.symmetric_keys go データベースの対称キーを作成するには、まず、対称キーストアの保護機能として機能するマスターキーと証明書を使用してユーザーデータベースを設定する必要があります。 データベースレベルのプライマリキーを作成します。 use <dbname> CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<password>’ 証明書を作成します。 use <dbname> CREATE CERTIFICATE <certificate-name> WITH SUBJECT = 'A label for this certificate' 対称キーを作成します。 use <dbname> CREATE SYMMETRIC KEY <key-name> WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE <certificate-name>; GO 列を暗号化します。 use <dbname> OPEN SYMMETRIC KEY <key-name> DECRYPTION BY CERTIFICATE <certificate-name>; UPDATE <table-name> SET <encrypted-column-name> = EncryptByKey(Key_GUID('<key-name>’), <column-name>); 列を復号化します。 use <dbname> OPEN SYMMETRIC KEY <key-name> DECRYPTION BY CERTIFICATE < certificate-name>; GO SELECT CONVERT(varchar, DecryptByKey(<encrypted-column-name>)) AS 'Decrypted-column’ FROM <table-name>; GO 方法 2: 非対称キーによる列暗号化 非対称キーによる列レベルの暗号化の実装手順は次のとおりです。 RDS インスタンスで、インスタンスの起動時に Amazon RDS ですでに作成されている SMK を確認します。 Use Master go select * from sys.symmetric_keys go ユーザーデータベースの非対称キーを作成するには、まずプライマリキーを使用してデータベースを設定し、次にパスワードで暗号化して非対称キーを作成する必要があります。 データベースレベルのプライマリキーを作成します。 use <dbname> CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<key-password>’ 非対称キーの作成します。 use <dbname> IF NOT EXISTS (SELECT * FROM sys.asymmetric_keys WHERE name = '<Asym-key-name>') BEGIN CREATE ASYMMETRIC KEY <Asym-key-name> WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD = '<Asym-key-password>' ; END GO 列を暗号化します。 use <dbname> UPDATE <table-name> SET <encrypted-column-name> = ENCRYPTBYASYMKEY(ASYMKEY_ID('<Asym-key-name>'), <column-name>) GO 列を復号化します。 use <dbname> SELECT *, <Decrypted-column-name> = CONVERT(CHAR(11),DECRYPTBYASYMKEY(ASYMKEY_ID ('<Asym-key-name>'), <encrypted-column-name>, N'<Asym-key-password>’)) FROM <table-name>; GO まとめ この投稿では、Amazon RDS for SQL Server に列レベルの暗号化を実装する方法を学びました。暗号化はセキュリティの確保に役立つ貴重な技術ですが、すべてのデータや接続に暗号化を考慮すべきではありません。暗号化を実装するかどうかを決めるときは、ユーザーがどのようにデータにアクセスするかを検討してください。ユーザーがパブリックネットワーク経由でデータにアクセスする場合は、セキュリティを強化するためにデータを暗号化することを強くお勧めします。ただし、すべてのアクセスがセキュアに設定されたイントラネットの中にある場合は、暗号化は必要ない場合があります。暗号化を使用する際には、パスワード、キー、証明書のメンテナンス方法も含める必要があります。 著者について Kiran Mulupuru は、アマゾンウェブサービスのデータベーススペシャリストテクニカルアカウントマネージャーです。Amazon RDS と Amazon Aurora データベースを専門としています。彼女はお客様と協力して、データベースの運用パフォーマンスに関する技術支援を提供し、データベースのベストプラクティスを共有しています。 Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関するソリューションを設計し、既存のデータベースを AWS クラウドに移行してモダナイズする支援や、AWS での大規模な移行のオーケストレーションを支援しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、Microsoft SQL Server を実行している DB インスタンスに保存されているデータを暗号化するための 透過的データ暗号化 (TDE) をサポートしています。 TDE は、データをストレージに書き込む前に自動的に暗号化し、ストレージからデータを読み取るときにデータを復号化します。 TDE 証明書の有効期限は、証明書がいつ作成されて有効期限と関連付けられるかによって異なります。Amazon RDS for SQL Server の場合、TDE 証明書は、 オプショングループ を使用してインスタンスで TDE を有効にした日から1 年後に有効期限が切れます。この TDE 証明書の有効期限が切れると、監査の観点から RDS for SQL Server インスタンスがコンプライアンス違反になります。ただし、証明書の有効期限が切れても TDE の動作は停止しません。 TDE が有効になっている Amazon RDS for SQL Server で適切な監査とコンプライアンスを確保するためのベストプラクティスとして、TDE 証明書を RDS for SQL Server インスタンスで毎年ローテーションする必要があります。これには、新しい証明書を作成し、既存の証明書の有効期限が切れる前に新しい証明書を使用することが含まれます。 ソリューション概要 TDE 暗号化階層には、サービスマスターキー (SMK) を暗号化する Windows オペレーティングシステムレベルのデータ保護 API (DPAPI) をはじめとする複数の保護レベルが含まれます。この SMK はプライマリデータベースのデータベースマスターキー (DMK) を暗号化し、TDE 用に作成された証明書の秘密キーを保護します。この証明書はデータベース暗号化キー (DEK) を保護し、それによってデータが暗号化および復号化されます。 次の図は、完全な暗号化階層 ( Microsoft からのアーキテクチャリファレンス) を示しています。 DEK は対称キーであり、SMK や DMK のように変化しません。ただし、証明書は作成プロセスの一環として有効期限付きで生成されるため、ローテーションが必要になります。次の図は、Amazon RDS for SQL server に TDE をハイレベルに実装するためのリファレンスアーキテクチャを示しています。 実装 TDE 対応の Amazon RDS for SQL Server で TDE 証明書を定期的にローテーションするには、次のステップを実行します。このプロセスにはダウンタイムは発生しないことに注意してください。ただし、大規模なデータベースを使用する場合はインスタンスのパフォーマンスを監視する必要があります。 RDS for SQL Server インスタンスがマルチ AZ モードの場合は、シングル AZ モードに変更します。   TDE オプションは永続的なオプション であり、すべての DB インスタンスとバックアップがオプション グループから関連付け解除されない限り、オプション グループから削除できないからです。 TDE 証明書の詳細を確認します。 USE [master] GO SELECT name FROM sys.certificates WHERE name LIKE 'RDSTDECertificate%' GO 暗号化されたデータベースを確認します。 USE [master] GO SELECT name FROM sys.databases WHERE is_encrypted = 1 GO SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys GO TDE を無効化します。 USE [DBNAME] ALTER DATABASE [DBNAME] SET ENCRYPTION OFF GO USE [DBNAME] DROP DATABASE ENCRYPTION KEY GO TDE を検証します。 USE [master] GO SELECT name FROM sys.databases WHERE is_encrypted = 1 GO SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys GO 復旧モデルを SIMPLE に変更します。これにより、ログファイル内の暗号化された値をすべて消去できます。 注意 : 復旧モデルを変更すると、 DMS のような復旧モデルに依存しているサービス に影響がある可能性があります。Amazon RDS for SQL Server の復旧モデル変更に関しては こちら をご参照ください。 ALTER DATABASE [DBNAME] SET RECOVERY SIMPLE GO 復旧モデルを FULL に変更します。 ALTER DATABASE [DBNAME] SET RECOVERY FULL GO TDE が有効になっていないオプショングループに切り替えるようにインスタンスを変更します。   この結果、古い TDE 証明書は RDS for SQL Server インスタンスから完全に削除されます。オプショングループの詳細については、「 オプショングループを使用する 」と「 オプショングループにオプションを追加する 」を参照してください。 RDS インスタンスが使用可能になったら、オプショングループに TDE オプションを追加すると、新しい証明書が生成されます。   データベース復旧モデルが FULL – SIMPLE – FULL と変更すると、新しいスナップショットが作成されます。 スナップショットが完成したら、Amazon RDS コンソールを使用してインスタンスをマルチ AZ に戻します。 オプショングループをアタッチし、シングル AZ に変更してからマルチ AZ に変更し直しても、ダウンタイムは発生しません。ただし、データベース復旧モードとマルチ AZ が変更されるため、このプロセス中は高可用性とポイントインタイムリカバリ (PITR) に影響があります。 Amazon RDS for SQL Server での TDE の制限事項 このソリューションには以下の制限があります。 このソリューションは、SQL Server 2019 Standard Edition と Enterprise Edition、および SQL Server 2012-2017 Enterprise Edition でのみサポートされています。 Amazon RDS は TDE 証明書のインポートまたはエクスポートをサポートしていません。 TDE 対応データベースのネイティブバックアップは作成できますが、そのバックアップをオンプレミスデータベースに復元することはできません。TDE 対応のオンプレミスデータベースのネイティブバックアップは復元できません。 まとめ この投稿では、RDS for SQL Server インスタンスで TDE 証明書をローテーションする方法を学びました。この方法を使うと、証明書の有効期限が切れる前に TDE 証明書を適時にローテーションし、インスタンスが適切にコンプライアンスを守れるようにすることができます。 著者について Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関するソリューションを設計し、既存のデータベースを AWS クラウドに移行してモダナイズする支援や、AWS での大規模な移行のオーケストレーションを支援しています。 Saroj Kumar Das は、アマゾンウェブサービスのクラウドサポートエンジニアです。彼は AWS のお客様と仕事をしており、SQL Server に特化した Amazon RDS データベースプラットフォームに関する深い技術的専門知識を提供しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

生成系 AI (Generative AI) への関心が広まったことで、ビジネス上の課題、特に顧客サービスの課題を解決するために AI の利用に再び注目が集まっています。生成系 AI は、会話、ストーリー、画像、動画、音楽など、新しいコンテンツやアイデアを生み出すことができる AI の一種です。 マッキンゼー によると、カスタマーエクスペリエンス (CX) は生成系 AI のトップユースケースの 1 つです。同社は生成系 AI をカスタマーケア領域に適用することで、生産性コストが 30 ～ 45% 改善すると予測しています。 3 部構成のブログ投稿シリーズの第 1 部では、生成系 AI とは何か、生成系 AI が CX 環境をどのように変えているか、そして生成系 AI がもたらすビジネス成果について見ていきます。第 2 回と第 3 回では、生成系 AI を成功させるための重要な考慮事項と、CX 環境で大規模言語モデル (LLM) を使用する際のベストプラクティスについて詳しく説明します。 生成系 AI によるカスタマーエクスペリエンスの革新 生成系 AI は、大量のデータに対して事前にトレーニングされた非常に大規模な 機械学習 モデルによって実現されています。たとえば、 Amazon Bedrock で公開されている Anthropic の Claude 2 は、1370 億個のパラメータを使用してトレーニングされました。これらの事前トレーニング済みモデルは、一般に基盤モデル (FM) と呼ばれます。大規模言語モデル (LLM) は、人間のようなテキストの理解と生成に重点を置いた FM の一種です。 LLM は、コンタクトセンターが大量のデータを管理および処理する方法を改善し、リアルタイムで CX を強化できるため、CX のユースケースで素晴らしい可能性をもたらします。たとえば、LLM の備える人間並みのテキスト生成機能は、CX にとってすぐに活用できる分野です。テキスト生成により、会話の要約のようなテキストを生成したり、エージェントをリアルタイムで支援することに利用できます。 LLM はコンタクトセンターでの自動化を成功させるための基礎となる、音声やチャットボットの会話の自然言語処理も改善します。 LLM が会話のコンテキスト（通話履歴、以前の会話の記録、以前の取引など）として膨大な量のメタデータを活用できるためです。さらに、 LLM は複雑で非線形の文章構造をより簡単に理解できるため、連絡の意図を正確に判断できます。 発信者が自然言語理解 (NLU) 旅行ボットと対話する例を考えてみましょう。旅行者がこのボットに「ノルウェーの首都」へ旅行する意図を伝えたとします。従来の NLU ボットには、その意図を適切に解決するためのコンテキストがありません。 NLU ボットは、結果を得るためのデータセットがはるかに限られているため、通常、LLM ほどパラメータートレーニングの深さはありません。しかし、 LLM を統合すれば、ボットは顧客がオスロへの旅行を希望していることを「理解」するでしょう。これは、 LLM が膨大なパラメータ知識を使って顧客の意図を解決するという、非常に単純な例です。 LLM が生成する応答よりも予測性の高い結果を得るために、回答を特定の小さなデータセットに限定したいというユースケースがあるかもしれません。これらのユースケースとトレードオフについては、このシリーズの今後のブログ記事で詳しく説明します。 生成系AIでコンタクトセンタービジネスはどう改善できるか 私たちはカスタマーエクスペリエンスの向上は、生成系 AI のトップユースケースの1つだと考えています。それは、生成系 AI によって、エージェントへの支援、マネージャー向けの洞察、顧客向けのセルフサービス体験をさらに改善する機会があるからです。 生成系 AI がコンタクトセンターでどれほど役立つかを検討する際には、達成しようとしているビジネス成果から始めることが重要です。これにより、コンタクトセンターにおける生成系 AI の具体的なユースケースを絞り込むことができます。生成系 AI の次の 3 つのユースケースは、エージェントの効率を高め、データをより正確に処理し、顧客がより複雑なクエリへの回答を得られるようにすることで、すぐにビジネス価値をもたらします。 生成系 AI は、エージェントが顧客の問題に対応する際の効率性と正確性を向上させることで、 処理時間をさらに短縮し、初回解決率を高める ことに役立つ可能性があります。生成系 AI で企業のナレッジコンテンツから要約された回答やアクションをリアルタイムに生成することで、エージェントの能力を助け、エージェントが顧客の問題を迅速かつ正確に解決できるようにします。たとえば、顧客が自動車保険の請求について問い合わせるために電話をかけてきた場合、 LLM は顧客の請求と保険契約に関する情報、保険会社の Web サイトにある修理店の詳細、内部リポジトリの保険契約書を活用して、エージェントに包括的な対応と顧客の問題解決に役立つ次のアクションを提供できます。 また生成系 AI により、少量のサンプルではなくすべてのコンタクトを分析することで、 対応中のリアルタイムおよび対応後の分析と品質保証の取り組みを強化 することもできます。これにより、マネージャーは洞察をより迅速に特定し、エージェントがポリシーを順守していることを確認できます。生成系 AI を使用して会話を簡潔にまとめることができるため、エージェントやマネージャーが会話を引き継ぐ際にメモを取ったり確認したり、経緯を共有したりする時間を短縮できます。たとえば、生成系 AI は、回線契約の問い合わせに関する長い会話を「顧客がエージェントから提示された 10 ドルのリベートを拒否した後、回線契約をキャンセルした」と要約できます。また、 LLM は、エージェントの能力がビジネス成果をどのように左右するか、さらなる洞察をマネージャーに提供します。その後、コーチングポイントやエージェントトレーニングなどの推奨アクションを提供して、パフォーマンスをさらに向上させることができます。 さらに、セルフサービスエクスペリエンスを最適化して、 様々なチャネルを活用し、自動セルフサービスエクスペリエンスの開発コストを削減 したいと考えているかもしれません。生成系 AI はここでも、企業が顧客の意図の複雑なニュアンスを理解しやすくすることで役に立ちます。また、セルフサービス体験の設計、構築、更新を容易にするコンタクトセンターの構成を改善するための、 LLM を活用した推奨事項も提供できます。 Amazon Connect と生成系 AI の組み合わせによる可能性 2017 年に Amazon Connect の提供を開始したとき、統合された AI 機能をゼロから構築しました。これにより National Australia Bank 、 Traeger 、 Accor 、 Just Energy などのお客様が、処理時間の短縮や顧客満足度の向上などの成果を実現しています。私たちは Amazon Connect の既存の組み込み AI 機能を生成系 AI を使って強化することで、さらなるビジネス価値をもたらす機会があると考えています。 以下のデモでは、生成系 AI をコンタクトセンターの 3 つのユースケース (エージェントアシスタンス、マネージャーアシスタンス、カスタマーセルフサービス) にどのように使用できるかを紹介します。 効率的で効果的なサービスを顧客に提供しながら、コンタクトセンターの実際のビジネス成果を促進する生成系 AI のアプリケーションについて、皆様と協力できることを嬉しく思います。 より深く生成系 AI を理解するための関連記事 生成系 AI のビジネス価値を組織で実現 How Technology Leaders Can Prepare for Generative AI (英文) How Your Organization Can Prepare for Generative AI (英文) An introduction to generative AI with Swami Sivasubramanian (英文) 上のデモビデオで紹介されている生成系 AI を活用したカスタマーセルフサービスソリューションを試す方法の詳細については、以下をご覧ください Deploy self-service question answering with the QnABot on AWS solution powered by Amazon Lex with Amazon Kendra and large language models (英文) 著者について  Mike Wallace は AWS でアメリカのカスタマーエクスペリエンス分野のソリューションアーキテクトをリードしています。 Andrea Caldwell は AWS の Amazon Connect のプロダクトマーケティングマネージャーです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

Amazon QuickSight は、クラウド向けに構築されたビジネスインテリジェンス (BI) サービスです。機械学習 (ML) を活用しており、スケーラブル、サーバーレス、埋め込み可能です。QuickSight により、Web ブラウザーやモバイルデバイスを介してアクセス可能な、インタラクティブなダッシュボードや高度な形式のレポートを作成および公開できます。2023 年 11 月 7 日から、QuickSight に新しい分析体験が導入されます。新しい体験では、QuickSight でダッシュボードをより直感的かつ効率的に作成できるようになります。本ブログでは、この再設計の主な体験を紹介し、作成者が美しいダッシュボードやレポートを作成するためにより改良されたワークフローについて説明します。 主要な体験 今回の再設計により、QuickSight は次のような重要な体験を実現しました。 3 ペインレイアウト – 新しく合理化されたレイアウトでは、データ、ビジュアライゼーション構築、オブジェクトプロパティの間を簡単に移動することが可能な、明確で整理されたワークスペースを提供します。3 ペインの分析体験には、ペインコンポーネントの更新、縦型に整理された新しいフィールドウェル、フィールドのドラッグアンドドロップ、追加/編集ワークフロー、ビジュアルタイプセレクターの再設計、プロパティペインが含まれます。 分析ツールバー – 作成、編集、ペイン管理といった重要な機能にたった 1 クリックでアクセスでき、分析体験全体を通してより効率的に作業することが可能になります。 以下は、作成プロセスを効率化するために、コアとなるオーサリングワークフローがどのように再設計されたかを示しています。 ビジュアルの追加 – 作成者は、キャンバスにビジュアルをシームレスに追加する作業をよりスムーズに、複数の方法で行うことができます。ビジュアルの追加と、テキストやカスタムコンテンツなどのその他のオブジェクトの追加を簡単に区別できるようにしました。これにより、作成者はより柔軟な制御を行えるようになります。 ビジュアルの変更 – 再設計された UI により、ビジュアルの変更がより意図的に行えるようになりました。作成者がビジュアルを選択しているか否かに基づいて、UI にてその状況を確認できます。これにより、意図しない変更を防ぎ、シームレスな変更を行うことが可能になりました。 ビジュアルへのデータの追加 – フィールドリストの横にある縦型のフィールドウェルを使用すると、データフィールドを簡単にドラッグアンドドロップできます。これにより作成者のワークフローが改善されます。 プロパティの編集 – Properties は画面の右側に設置された専用のペインとなり、1 つ以上のビジュアルのプロパティを簡単に編集できるようになりました。プロパティペインには、条件付き書式設定やアクションなど、オブジェクトに関連するすべてのプロパティが統合されるようになりました。 新しい体験へのナビゲーション – 導入された変更のほとんどは直感的に操作できるように設計されていますが、作成者が機能やワークフローを発見することができるように、様々な分析アクションを検索する機能も導入しました。分析メニューに統合されたクイック検索により、分析体験内の機能の発見がより簡単になります。クイック検索ではキー操作のたびに検索結果が絞り込まれるため、特定の機能を簡単に見つけることができます。ダッシュボード作成タスクの効率を向上させながら、目的の機能に移動することができます。 ベータ体験のオプトアウト – 以前の体験に戻したい場合は、2023 年 11 月 21 日まで可能です。オプトアウトするには、ツールバーの右上にある [New Look] をクリックし、 [Switch back] を選択します。新しい体験に変更する準備が完了次第、いつでもこのオプションから新しい UI に切り替えることができます。 まとめ 本ブログでは、再設計された分析体験によって、どのように QuickSight が多様なデータ分析要件に適した、強固、柔軟、安全な BI プラットフォームとしてより良く機能するのかについて説明しました。主要なオーサリングワークフローの再設計は、2023 年 11 月 7 日から利用可能です。 詳細については、 Amazon QuickSight や AWS の最新情報の Quicksight フィード を参照してください。 ご質問やご意見がございましたら、コメントを残してください。 追加のディスカッションや、質問への回答を得られるヘルプについては、 QuickSight コミュニティ をチェックしてください。 翻訳はソリューションアーキテクトの守田が担当しました。原文は こちら です。 著者について Rushabh Vora は、Amazon Web Services のクラウドネイティブなフルマネージド BI サービスである Amazon QuickSight のシニアテクニカルプロダクトマネージャーです。彼はデータ可視化に情熱を注いでいます。以前は、Amazon Business でプロダクトマネージャーとして働いていました。

本ブログ記事は、NASCAR の Event & Media Technology 担当 Managing Director である Chris Wolford と共同執筆しました。 はじめに National Association for Stock Car Auto Racing（NASCAR）は、1940 年代後半まで遡る、豊かな歴史を有します。時を経て、NASCAR は世界で最も人気のあるモータースポーツ組織の1つとなり、スーパースピードウェイ、オーバルトラック、ロードコース、ストリートサーキットを巡る、ホイールツーホイールレースの接戦をファンに届けています。何百万人もの視聴者が観戦する NASCAR 最高峰の NASCAR カップシリーズでは、40 台のレースカーが、時速 200 マイルを超える最高速度で競い合います。 レースの最中、クルーチーフ、スポッター、ピットクルー、エンジニア、その他のチームメンバーから成る各チームは、それぞれの協力のもと、さまざまなデータポイントを分析してリアルタイムの意思決定を行います。しかし、データはラップごとに絶えず変化していきます。たとえば、タイヤの摩耗状況は戦略を組み立てるうえで、チームにとって重要な要素となる場合があります。チームは、いつピットストップを行うか、またレース中に何回行うべきか決めなければなりません。ところが、タイヤの摩耗に関するデータはラップごとに異なる可能性があるため、データ分析を行い、全体的なレース戦略を実行に移すうえで、ドライバーやエンジニアと連携を図り、クルーの専門知識を活かすことは極めて重要となります。そこで、データ分析やその適用を効率化するクラウドベースのサービスとソリューションを提供しているのが Amazon Web Services（AWS）です。 NASCAR のデータパイプラインは、チーム内にとどまるものではありません。NASCAR はリアルタイムのレーシングデータを放送局やファンと共有し、比類なきファン体験を提供しています。「NASCAR は、単一のレースから他のどこよりも圧倒的に多くのコンテンツ、データ、ビデオを生み出しています。」と NASCAR の Operations and Technical Production 担当 VP である Steve Stum は述べています。「トラック上でより多くのコンテンツをクラウドへと移行を進めるに伴い、私たちは AWS の限界を押し広げてきました。そして、AWS のエンジニアは、そのデータをファンやレーシングチームのデバイスに取り込めるよう、優れたソリューションをいくつも提案してくれました。」 それでは、NASCAR が AWS を活用して、レーシングチーム、放送局、そしてファンにリアルタイムのデータをどのように提供しているかを探っていきましょう。 レースの未来：NASCAR の NextGen car (次世代車両) 2022年にデビューした NextGen car は、チームの競争力を高め、安全性を向上させ、コスト削減を図るために開発されました。新しい設計には、独立したリアサスペンションや、シングルラグナットを使用する新しい 18 インチホイールなど、前世代から多くの空気力学的および機械的な変更が加えられました。これらの機械的な設計変更以外にも、NextGen car にはテクノロジーの変更やアップグレードが施されました。この NextGen car により、競技中のパフォーマンスに関するインサイトがより多く提供されるようになり、NASCAR は、以前までは不可能だった、データポイントの追加を将来的には実現できるようになりました。 レース中、40 台の NextGen car に装備された多数のセンサーが、エンジン回転数からブレーキ圧に至るまで、合計 60 を超えるデータポイントであらゆるデータをキャプチャします。これらのデータポイントはすべて、各車両で毎秒数百回サンプリングされ、その結果、レース中には毎秒 612,000 件を超えるメッセージが送られます。メッセージあたりのサイズが 0.15 KB であることを踏まえると、NASCAR は、レース中に（時には最大 4 時間にわたって）約 92 MB/秒のデータ取り込みに対応できるシステムを必要としていました。いったん取り込んだデータは、競技チームや他の NASCAR パートナーにリアルタイムでストリーミングする必要がありました。さらに複雑なことに、この種のデータ収集は、レースシーズン中、全米の複数のレーストラックで利用可能でなければなりませんでした。 これを実現するために、NASCAR は AWS プロフェッショナルサービスと協業し、Event Racing Data Platform（ERDP）と呼ばれる、車両のテレメトリーデータを取り込み、ストリーミングするプラットフォームを構築しました。 図 1：Event Racing Data Platform のアーキテクチャ NextGen car からデータをキャプチャする NextGen car- のテレメトリーデータが辿るジャーニーの第一歩は、車両そのものから始まります。レースカーには 60 種類以上のセンサーが装備されており、エンジン、タイヤ、エクステリアなどからデータが収集されています。これらのデータはいずれも、各車両に搭載された電子制御ユニット（ECU）によって収集、集約されます。この集約されたデータパケットは、40 台の車両のそれぞれから極超短波（UHF）の電波を介して、各トラックの中継局に 10 ミリ秒ごとに送信されます。次にこの中継局は、このデータパケットを、トラックの内部ネットワーク上の UDP 経由で、NASCAR のモバイルデータセンター（MDC）に転送し、各レーストラックへとジャーニーは進みます。 超低レイテンシーでエッジからクラウドへと境界を押し広げる ジャーニーにおける現段階では、集約されたデータはトラック上の MDC に到達し、取り込みサーバーによってデコードおよびデアグリゲートされます。ここで、データメッセージはトレーラー車内のデータパブリッシュ用クラスターで利用できるようになります。その後、これらのデータメッセージは、MDC 内の Kubernetes クラスター上で稼働している NATS と呼ばれるオープンソースの pub/sub メッセージングシステムによって処理されます。このクラスターは、受信データのコピーをローカルに保持することに加え、クラウドで稼働している受信側の NATS クラスターにメッセージを伝播することを目的としています。車両を離れてからメッセージが利用可能になるまでの総経過時間は、ローカルのトラックでは 40 ミリ秒未満、クラウドでは 200 ミリ秒未満です。 トラック上の MDC と AWS 間の超低レイテンシー通信を実現するために、NASCAR は AWS Direct Connect （DX）接続を利用しています。Direct Connect を利用することは、このソリューションを全国のすべてのトラックで再現可能とするための非常に重要な要素となっています。各トラックには Direct Connect へのルーティングを備えたプライベートネットワークがあるため、トラックからクラウドへのデータ転送には常に AWS バックボーンネットワークが使用されています。これにより、パブリックインターネットをバイパスし、ソリューションに必要な超低レイテンシーを実現することができます。また、クラウドインフラストラクチャを単一の AWS リージョンに配置し、レースが物理的にどこで行われていても、同じパフォーマンスを提供することができます。 テレメトリーデータは、NATS クラスターから DX  接続を介して、NASCAR の AWS アカウントに配置されている、 Amazon Elastic Load Balancing のNetwork Load Balancer (NLB)に送信されます。NLB は、受信トラフィックのレイヤー 4 ロードバランサーとして機能するため、NLB を使用することで非常に高いスループットを得ることができます。送信先は受信側の NATS クラスターです。このクラスターは、同様に Kubernetes 上で稼働しており、 Amazon Elastic Kubernetes Service (EKS) で管理されています。これで、テレメトリーデータの準備が整い、ダウンストリームで消費可能となります。 データが車両を離れてからトラック上のサブスクライバーに届くまでの総経過時間は 40 ミリ秒弱であり、これがクラウド経由でアクセスできるサブスクライバーの場合、インターネットレイテンシーにもよりますが、200 ミリ秒弱となります。 NASCAR、レースチーム、自動車メーカーがどのようにデータを活用しているか NASCAR の AWS アカウントで利用可能なレーシングテレメトリーデータは、ダウンストリームでの活用方法や消費方法に従って、3 つの異なる送信先があります。 図 2：テレメトリーデータストレージ 何よりもまず、NASCAR はこのレーシングテレメトリーデータを信頼できる唯一の情報源として、安全かつ永続的に保存する必要があります。これを実現するために、テレメトリーデータは Amazon Kinesis Data Firehose  ストリームにストリーミングされます。Firehose は、AWS や他の HTTP のエンドポイントにあるダウンストリームの送信先にデータをリアルタイムでストリーミングするためのツールです。ここでは、 Amazon S3 バケットはレーシングテレメトリーデータの送信先として使用されています。業界をリードする耐久性、データの可用性、セキュリティ、パフォーマンスを備えた Amazon S3 は、NASCAR によって公式のレーシングデータのストレージサービスとして選定されました。 NASCAR が公式利用するためにこのテレメトリーをキャプチャする以外に、レーシングテレメトリーは、サブスクライバーが独自に利用できるようになっています。このサブスクライバーには、レースチーム、自動車メーカー、およびレースに関わるその他の第三者が含まれています。可能な限りリアルタイムに近いデータへのアクセスは、これら多くのサブスクライバーにとって必要不可欠です。どのレーシングチームもトラックでこのデータに直接アクセスできますが、現在では多くのチームに、リモートエンジニアやアナリティクスチームが組み入れられ、彼らが提供し得るインサイトや戦略の決定事項がレースの流れを変え、ドライバーにアドバンテージをもたらします。 図 3：リアルタイムのテレメトリーデータフロー レーシングテレメトリーデータをリアルタイムで取り込むために、サブスクライバーはパブリック向け NLB 経由で EKS クラスターに接続することができます。クラウドへのデータ取り込みと同様に、NLB は低レイテンシーのレイヤー 4 ルーティングを提供しているため、EKS 内のデータへの高速アクセスが可能です。実際にはこれにインターネットレイテンシーが加わり、車両外に配信されてから合計約 200 ミリ秒で、レーシングチームはレーシングテレメトリーデータにリモートアクセスすることができます。 この設計に組み込まれた NATS の重要な特徴の 1 つは、異なるサブスクライバー間でデータを分離している点が挙げられます。特定のレーシングチームが、そのチーム車両のテレメトリーデータを受け取る唯一の受信者であることを保証することは、競技の健全性を確保するうえで必要不可欠です。したがって、ERDP に接続してライブテレメトリーデータを受信するチームは、そのチームに適切なデータセットにのみ、リアルタイムでアクセスすることができます。 図 4：履歴データフロー リアルタイムでの消費に加えて、多くのサブスクライバー向けに、レース後の分析や車両のテレメトリーデータの利用に関するユースケースもあります。これをサポートするために、NASCAR の S3 バケットの公式レーシングデータを、お客様向けの他の S3 バケットにコピーする、データ同期サービスが提供されています。このデータ同期は、 AWS Lambda 関数を使用して実行されます。どのデータをどのチームと共有すべきかについての情報は、設定ファイルとして、これも S3 に保存されています。Lambda はこれらの設定を読み取り、未加工データを変換せずにお客様向けバケットにレーシングデータをコピーします。 データ用に個別の Amazon S3 バケットを用意することや、データ変換を行わないことなどの設計上の決定は、意図的に行われています。第一に、変更されていないデータを提供することで、サブスクライバーは提供されたテレメトリーやレーシングデータが、NASCAR 自身が管理する公式のレーシングデータ（信頼できる情報源）と一致していることを確認できます。第二に、メインとなる NASCAR のバケットをお客様向けバケットから切り離すことで、データセキュリティおよび耐障害性が向上します。レーシングテレメトリーデータとのやり取りを行うダウンストリームサービスは、公式の NASCAR のバケットと直接やり取りすることはありません。さらに、データの取り込みで問題が発生した場合、提供準備が整っていないデータ、または破損している可能性のあるデータはダウンストリームのサブスクライバーには提供されません。 まとめ NASCAR のテクノロジーへの投資は、より公平な競技の場、より接戦となる競争、そしてより魅力的なファン体験をもたらしています。AWS Direct Connect、ELB、EKS、および Kinesis Firehose は、NASCAR に超低レイテンシーのデータストリーミング機能を提供し、スポーツをモダナイズしています。Amazon S3 の業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスにより、NASCAR は有用なデータをダウンストリームに提供することができます。NASCAR のデータジャーニーストーリーから得た教訓は、たとえ時速 200 マイルで走行する必要のないビジネスであったとしても、より良いビジネス成果を上げるために、データ活用を推進しているあらゆるビジネスに応用できます。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口が担当しました。原文は こちら をご覧ください。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、ソリューションアーキテクトの山中です。 今年4回目の AWS Innovate を 10 月 26 日に開催します！ 今回はモダンアプリケーション開発にフォーカスした AWS Innovate – Modern Applications Edition です。お客様のビジネス成功に欠かせないアプリケーションをモダナイゼーションすることで得られるメリットやアプローチ方法について集中的に学んでいただくことができます。午前の部と午後の部の 2 回、同じ内容で開催しますので、ご都合に合わせてご参加ください。 Modern Application Edition では、テーマ別に「サーバーレス」、「コンテナ」、「デベロッパーエクスペリエンス」、「お客様事例」の計 4 トラック、16 セッションをご用意しています。 当日のアジェンダはこちらです。 セッションの見どころについて まず、オープニングセッションでは、モダンアプリケーションが提供する価値として「開発のアジリティ」「パフォーマンスやスケーラビリティの柔軟な調達」「セキュリティやレジリエンシーのクラウドインフラストラクチャへのオフロード」「実行環境の選択や開発効率向上によるコスト最適化」の全体像についてお話しをします。また、これまでの Amazon のイノベーションの歴史を振り返りながら、技術的なアプローチだけでなく、「人」や「プロセス」も含めたモダナイゼーション成功のポイントについてご紹介します。 続いて、各トラックです。 「サーバーレス」トラックでは、アプリケーションをサーバーレスで開発する際に、運用やセキュリティ、スケーラビリティなどの観点で押さえておくべきポイントを幅広くお伝えします。サーバーレスなアプリケーションを実際に運用される方は是非ご覧ください。また、サーバーレスなアプリケーションから生成系 AI を活用するためのアプローチについてのセッションも用意しています。 「コンテナ」トラックでは、コンテナ入門者向けに、既存のアプリケーションをコンテナで動かすにあたっての基本的な考え方や、素早くコンテナ上にアプリケーションをデプロイするためのサービスについて紹介します。また、本格的にコンテナを利用される方に向けて、コンテナを使ったプラットフォームエンジニアリングやコンテナのネットワーキングについても解説します。 「デベロッパーエクスペリエンス」トラックでは、開発者体験向上にフォーカスし IaC やオブザーバビリティの話題を扱います。また、統合 DevOps プラットフォームや生成系 AI によるコーディング支援など新しいサービスについてのセッションも用意しています。チーム開発やコーディングの効率化に対するアプローチをご紹介しますので、アプリケーション開発者の方は是非ご覧ください。 「お客様事例」トラックでは、AWS 上でモダンアプリケーションを効率的に開発・運用されている事例や、自社アプリケーションのモダナイゼーションに挑戦されている事例について、お客様からご紹介を頂きます。 AWS Innovate – Modern Applications Edition をより楽しむために イベントの申し込みは こちら になります。AWS が提供するセッションは Level 100、Level 200、Level 300 でセッションレベルを分類しています。トピックに関する前提知識に応じて、セッション選びの参考にしてみてください。 また、当日はライブ Q&A も実施します。セッションで気になったことや疑問点など、お気軽にご相談ください。 みなさまのご参加をお待ちしております。 – ソリューションアーキテクト 山中

コラボスタイルは、クラウド型ワークフロー製品の開発・販売と、ワークスタイル自体のデザインやワークプレイスを構築する事業を展開しています。2022年12月に、自社で開発しているクラウドワークフローシステム「コラボフロー」を Aurora PostgreSQL Serverless v2 化することでスケールアップ時のダウンタイムをゼロに、負荷の高かったスケールアップ作業時の運用負荷を大幅に削減することに成功しました。本ブログは、2023年8月9日に実施した、 2時間で学ぶ！Amazon Aurora オススメ機能 ～Aurora Serverless v2 ～ のイベント内で、コラボスタイルの成島様にご登壇いただいた発表内容を元に、Aurora Serverless v2化の導入検討から導入効果についてまとめたものになります。Aurora Serverless v2の導入を検討している方の参考になればと思います。 アーキテクチャ 以下は、Aurora Serverless v2採用前のコラボフローのアーキテクチャになります。インターネットからWAFを経由するリクエストがCloudFrontからALBを経てアプリケーションサーバーに振り分けられます。アプリケーションサーバーからのリクエストは、Aurora クラスターのWriterインスタンスにアクセスして実行されていました。 大規模な障害の発生 2022年の前半、コラボフローでユーザーの業務に影響するような障害が発生しました。障害の原因を分析した結果、大きく2点が原因であることがわかりました。１つはコラボフロー自体のサービス面の問題で、1. ユーザー数の急激な増加、2. 利用状況の変化、3. アクセス数の増加により、データベースへの負荷が急増したことが原因でした。そしてもう１つはエンジニアのマインド面で、データベース運用が特定のエンジニアに属人化していたことでそのエンジニアを頼りすぎてしまい、多角的な視点が欠如していたことに気づきました。この障害がきっかけで、コラボスタイルでは特定の個人ではなくチームとして対応できるようSREチームを立ち上げ、障害を起こさないインフラ作りをチームで推進することになりました。 スケールアップによる新たな課題 SREチームでは、データベースの負荷を分析して、必要であればAuroraのスケールアップを実施するような運用にしました。これによって、障害を未然に防ぐことができるようになりました。一方で、スケールアップにともなう新たな課題に直面することになりました。 スケールアップにともなう新たな問題 リザーブドインスタンス（RI）のサイジング １つ目はRIのサイジングです。RIは最低1年単位での契約になるため、見積もりも１年間の予測を立てる必要があります。ですが、この障害以降の半年間で２回のスケールアップを実施しており、１年間の予測を立てることが難しい状況になっていました。 検証負荷 コラボスタイルでは、インスタンスサイズの変更に多くの時間を使って検証作業を実施していました。アプリケーションサーバーも含めた検証環境の構築や負荷テスト、負荷テスト結果の分析など、多くの作業が発生するため、スケールアップ毎に多くの時間を割く必要がありました。 停止メンテナンスの増加 スケールアップによるメンテナンスが増えることは、コラボフローのサービスへの影響はもちろん、ユーザーへのメンテナンスの案内や、メンテナンスの夜間作業などのエンジニアへの負担など、間接的な運用負荷も増えることになります。また、このような状況だと年間でのメンテナンス計画も立てづらい状況でした。 監視時間の増加 RIのサイジングやメンテナンスが必要なタイミングを適切に把握するためには、分析作業の頻度も多くする必要があります。その結果、監視時間や分析作業、判定会議などの運用負荷が増加し、本来SREとして取り組むべき作業時間が削られる、という問題も発生していました。 Aurora Serverless v2の導入 このような課題を解消するために、Aurora Serverless v2を導入することを決めました。Aurora Serverless v2は負荷に応じてシームレスにスケーリングすることができるため、コラボフローでのスケーリング時の運用課題を解決できる機能でした。 また、Aurora Serverless v2への変更も、通常のプロビジョンドインスタンスと同じように変更することができます。今回の移行では、ReaderをServerless v2に変更して１ヶ月程度検証したあと、フェイルオーバーで WriterをServerless v2に変更する、といった手順で、徐々にServerless v2に変更しました。この手順であれば、万が一Serverless v2に問題があった場合でも、再度フェイルオーバーすることで簡単にプロビジョンドインスタンスに戻すことも可能でした。 Aurora Serverless v2の導入による効果 Aurora Serverless v2導入して半年以上経過しましたが、パフォーマンス等の問題は発生しておらず、課題だったスケーリングに伴う運用負荷も大幅に改善することができました。 Aurora Serverless v2の性能 Aurora Serverless v2の導入後、通常時はもちろん、サービスによる急激な負荷増大でスケーリングした時でも、4.5ms以下のレイテンシーでパフォーマンスを維持することができており、プロビジョンドと比較しても遜色ないパフォーマンスを実現できています。 運用負荷の改善、RIのサイジングの改善 Aurora Serverless v2はRIがないため、難しい見積もり作業自体が不要になりました。 検証負荷の改善 インスタンスサイズの変更に伴う検証作業は無くなりました。これにより、検証作業に関わるエンジニアの作業工数を削減することができ、本来SREが対応すべき作業にリソースを集中させることができるようになりました。さらに、以前は検証に伴う環境作成で発生するインスタンスコストも削減することができています。 停止メンテナンスの改善 スケールアップ作業自体が不要になり、エンジニアによる深夜対応なども改善されました。また、年間でのメンテナンス計画も立てやすくなりました。 監視時間の改善 RIのサイジングやメンテナンスが必要なタイミングを把握するためのモニタリングは不要になり、それに伴う打ち合わせなども無くなりました。一方で、Aurora Serverless v2のリソースを監視、分析して、最適化できるよう取り組んでいます。 Aurora Serverless v2の最適化 ここでは、SREチームで実施したAurora Serverless v2の最適化の取り組みの１つをご紹介します。SREチームがAurora Serverless v2のリソースを分析したところ、サービスの負荷が低い夜間の時間帯で思うようにスケールダウンがされず、日中のACU（Aurora Capacity Unit）のままのリソースが割り当てられていることがわかりました。ACUは、Aurora Serverless v2のデータベース容量で、1ACUあたり約 2 GiB のメモリとそれに対応する CPU、ネットワークが割り当てられます。 上記のグラフは、オレンジがACUのUtilizationで青がServerless Capacity、赤背景が負荷の低い夜間の時間帯です。ACUのUtilizationを見ると、負荷の低い赤背景の時間帯でも60ACUが割り当てられています。このため、負荷が低い時間帯に対してスケジュールで最小と最大のACUの設定を変更することにしました。このACUの最小値と最大値は再起動が不要で動的に変更可能であるため、Amazon EventBridgeのスケジュールでAWS Lambdaを呼び出し、値を変更することにしました。 この結果、負荷の低い時間帯にスケールダウンされるようになりました。これにより応答性能を維持しつつ、インスタンスのコストを12%削減することができています。 まとめ コラボスタイルでは、今回のAurora Serverless v2の導入を成功させたことで、運用時の課題を改善し、SREチームとして本来の業務に専念することができるようになりました。そして、SREチームが「サービスを守る最強の盾」と代表から評価されるほど、社内でサービスを安定させるためのキーファクターになったことや、開発部の中にSREチームの考え方を強く浸透させることができたこともAurora Serverless v2採用の効果だったと言えそうです。コラボスタイルのSREチームでは、引き続きAWSサービスを利用しつつシステムの安定化やコスト最適化などに取り組んでいく予定です。

拡張現実（AR）アプリケーションは、3D 機械設計や、3D デジタルツインモデルによる機器の修理補助や、医療手術の新人教育のアプリケーションに 3D の身体画像を使用し、学習効率を上げることに活用されています。こういったアプリケーション群には、リアルタイムでの 3D オブジェクトのレンダリングが必要になります。タイトルにあるリモートレンダリングとは、AR ヘッドセットの動作に応じてサーバー側で 3D コンテンツの操作を行い、レンダリングされたオブジェクトを即時にヘッドセットにストリーミングする技術です。リモートレンダリングの利点は、高いパフォーマンスと高品質な AR 体験を提供しつつ、携帯電話等のデバイスよりも低いコストでレンダリングできる所です。リモートレンダリングの利点としては、ローカルの GPU や限られたリソースしかないヘッドセットでの処理と比べると、サーバーがグラフ計算の処理のためのリソースを提供し、高解像度でストリーミングのプラットフォームを実現するところがあります。また、各ヘッドセットではなくサーバーでデータを持つため、データ保護の観点でも優れています。しかし一方で、リモートレンダリングでは、リアルタイム AR アプリケーションの特性であるインタラクティブな体験を提供するために低レイテンシーの応答時間、低ジッター、高スループットを実現する必要があります。 このブログでは、 AWS のエッジサービス 、特に AWS Wavelength と AWS Snowball が、パブリック 5G 環境とプライベート 5G 環境の双方で、どのようにリモートレンダリングを提供できるかを説明します。Holo-Light の XR (Extended Reality) エンジニアリング のアプリケーションである AR 3S が、リモートレンダリング技術と統合されている例を使用して、エッジコンピューティング環境におけるリモートレンダリングの要件とワークフローを説明します。 AR 3S とリモートレンダリングの要件 Holo-Light の AR 3S AR エンジニアリング・ワークスペースは、XR アプリケーションです。この XR アプリケーションは、エンジニアリングと製品開発を改善するためのツールで、AR/VRの中で 3D CAD データを使った共同作業を行うためのデジタルワークスペースを提供します。AR 3S を使用することにより、開発者は複雑な実物大の 3D モデルを視覚化し、物理的な部品と合成表示しながら、物理環境で評価を行い動作をさせることができます。 図 1. 複雑な 3D モデルの分解を示す AR 3S のユーザビュー このアプリケーションのアプローチとしては、サーバー上での リアルタイム 3D レンダリング、ジェスチャー認識、トラッキング を含む一連のエンジニアリングのためのツールと機能が含まれています。独自のストリーミング技術である ISAR SDK が組み込まれているため、XR アプリケーションは、強力なサーバー上で実行することができます。表示できる 3D ホログラムの詳細レベル、データサイズ、ポリゴン数に対し、サーバー上で制限するものはありません。ユーザーは、XR デバイス上のクライアントアプリから外部サーバー上の XR アプリに接続するだけで使用できます。AR 3S は 1 億ポリゴン以上を 1 秒間に 40～60 フレームのスピードで処理できます。一方、ARデータ用のゴーグルは、ローカルで機器自身のリソースを試用するため 100 万ポリゴン以下しかスムーズに処理することはありません。そのため現在、レンダリングの処理は、性能制限のある XR デバイス上から高性能のサーバー上に移行しつつあります。 図 2. ISAR SDK を使用したリモートレンダリングシナリオの例 リモートレンダリングでは通常、エンドユーザーの没入感を高めるために、XR デバイスからアプリの処理に行って戻る、ラウンドトリップのレイテンシ（”モーション-トゥ-フォトンレイテンシ “とも呼ばれる）を 20ms 未満にする必要があります。ネットワーク帯域幅要件に関しては、リモートレンダリングでは、XR デバイスがモーションセンサーデータをサーバーに送信するために約 10Kbps のアップロードでのスループットが必要です。また、サーバーがレンダリング画像を XR デバイスに送信するために 20Mbps のダウンロードでのスループットが必要です。複数ユーザーで 3D デザインを共同作業しているの場合など、同時に使用する XR デバイスの数が増えるにつれて、必要となるスループットは、アップロードとダウンロードのいずれも増加します。 この ISAR の XR-Streaming は WebRTC 標準に準拠しています。そのため、サーバーと AR デバイスが同じローカルネットワーク内に無い場合、通常は STUN（Session Traversal Utilities for NAT）または TURN サーバーを使用します。STUN または TURN は、サーバーとクライアントデバイス間の直接ピアツーピア接続を確立する目的で、WebRTC アプリケーションがネットワークアドレストランスレータ（NAT）やファイアウォールを検出して通信するために使用されます。STUN や TURN サーバー技術について詳しく知りたい方は、オンライン記事（ WebRTC Crash Course など）を検索して確認してください。 パブリック 5G 環境でのリモートレンダリングを実現するAWS Wavelength AWS Wavelength により、通信サービスプロバイダ（CSP）のパブリック 5G ネットワークの間に AWS のコンピュートやストレージサービスを持ち込むことができます。Wavelength は超低遅延アプリケーションを開発し、デプロイし、さらにスケールするための、モバイルデバイス用のエッジコンピューティングやインフラを提供します。現在、ベル・カナダ、ブリティッシュ・テレコム（BT）、KDDI、SK テレコム、ベライゾン、ボーダフォンの 6 つの CSP が、30 の AWS Wavelength Zone で AWS Wavelength サービスを提供しています。 AWS Wavelength と CSP の 5G 接続両方を活用して、パブリックなネットワーク内の、クラウドのエッジ環境で、リアルタイムのリモートレンダリングを必要とする AR や VR アプリケーション、または XR 全般の実行処理を可能にします。具体的なユースケースとして、例えばゲームや、製品設計開発におけるレビュー、没入型のトレーニングなどがあります。XR デバイスを使用するユーザーは、遠隔にいても、CSP のパブリック 5G サービスを利用して、これらのサービスを使用できます。 図 3 は、AWS Wavelength を使用してリモートレンダリングサーバーを提供する場合の、俯瞰的に見たソリューションアーキテクチャです。AWS VPC は、CSP ネットワーク内の AWS Wavelength Zone に拡大されます。AWS Wavelength Zone 内で、仮想化されたリモートレンダリングサーバーは GPU を搭載したり、単一または複数の AWS EC2 インスタンスにデプロイすることができます。AWS Wavelength Zone と特定ロケーションの CSP ネットワークは、AWS Wavelength のネットワークの構成の一部である通信キャリア のゲートウェイ（CGW）を介して接続されます。これにより、CSP ネットワークからのインバウンド通信と、CSP ネットワークとインターネットへのアウトバウンド通信を行うことができます。 XR デバイスまたはクライアントアプリケーションがレンダリングをできるようにするには、リモートレンダリングの管理者は、AWS Wavelength Zone 内の VPC のサブネットにある EC2 に、単一または複数の EC2 インスタンスに、XR ストリーミングサーバーをデプロイします。さらに、管理者は CGW を作成します。CGW を作成する際には、リモートレンダリングサーバーが配置されているサブネットを選択し、レンダリングストリームのトラフィックを CGW にルーティングすることが必要です。通信キャリアが提供している IP アドレスを EC2 インスタンスに割り当て、その EC2 インスタンスがその IP アドレスを使用できるようにします。CGW は、EC2 インスタンスのプライベート IP アドレスから、キャリア IP アドレスへの NAT を行います。EC2 インスタンス上の XR ストリーミングサーバーとクライアントデバイス間が直接 WebRTC ピアツーピアで接続できるようにするためには、CSP ネットワーク内または AWS Wavelength ゾーン内に STUN サーバーが必要になります。 XR アプリケーションのユーザーは、XR デバイスをキャリア IP 網 に接続し、リモートレンダリングができるようにします。 図 3. AWS Wavelength におけるリモートレンダリングのソリューション・アーキテクチャ プライベート5G環境でリモートレンダリングを実現するAWS Snowball Edge AWS Snowball Edge は物理デバイスで、GPU を使用した Amazon EC2 や、Amazon EKS Anywhere、AWS Lambda、AWS IoT Greengrass、また機械学習などのクラウドにおけるコンピュートとストレージのサービスを、エッジ側で提供します。このデバイスは耐久性が高い特徴があり、AWS リージョンから切り離されたスタンドアローンモードでも動作することができます。そのため、工場、病院、防衛のための施設などのプライベートな環境での使用に適しており、リソースはプライベートな使用向けで、外部からのネットワーク接続は遮断されているため、運用の履歴や保存されたデータはローカルにセキュアに保護されています。 例えば、自動車メーカーでは、デザイナーとエンジニアの共同作業を支援する 3D デザインレビューの段階で、閉鎖されたネットワーク環境で AR の使用が考えられます。この使用例では、メーカーはすべての設計、AR アプリケーションとそのリモートレンダリングと、データをオンプレミス内に保管する必要があります。 図 4 は、プライベートな 5G 環境でのリモートレンダリングに AWS Snowball Edge を使用する場合のソリューションのアーキテクチャの図です。AWS Snowball Edge デバイスのタイプが「Compute Optimized with GPU」であり、EC2 インスタンスタイプが「sbe-g」の場合、GPU を使用するリモートレンダリングを提供することができます。 AWS Snowball Edge デバイスは、10G RJ45 ポートが 2 つ、10G/25G SFP+/SFP28 ポートが 1 つ、40G/100G QSFP28 ポートが 1 つ持ちます。管理プレーンとデータプレーンを分離するため、AWS は管理用のトラフィックに RJ45 ポートを 1 つ、アプリケーション用のトラフィックに SFP+/SFP28 ポートを 1 つ使用することを推奨しています。 図 4. AWS Snowball Edge におけるリモートレンダリングのソリューションのアーキテクチャ 注意しなければならない点としては、AWS Snowball Edge の仮想ネットワークインターフェース（VNI）を RJ45 ポートに関連付け、ダイレクトネットワークインターフェース（DNI）を SPF+/SFP28 ポートに関連付けることです。前者は VNI と EC2 インスタンスの eth0 間で IP NAT を行います。後者は、ダイレクトネットワークインターフェース（DNI）と EC2 インスタンス eth1 間のレイヤー2 接続を可能にします。XR のストリーミングトラフィック、例えばデータプレーントラフィックが DNI パスを通過するといった場合、STUN サーバーは必要ありません。 図中の AWS OpsHub は、AWS Snowball Edge デバイスをローカルまたはリモートで管理するためのグラフィカルユーザーインターフェイスです。 AWS Snowball Edge は、AWS リージョンに接続することができますので、データのアップロードや画像のダウンロードなどのユースケースにおいて活用できます。IP Security (IPSec) トンネルによるセキュアな接続が必要な場合には、インターネット経由の AWS Site-to-Site VPN を使用します。 図中右側のプライベート5G ネットワークは、5G 無線アクセス・ネットワーク（RAN）と 5G コア・ネットワークの二つで構成されています。 5G コア・ネットワークはプライベートな環境のために周波数帯域を割り当てられ、オンプレミスに導入されます。RAN の例の一つとしては AirSpeed 1900/2900 で、RU、DU、CU が全てが扱える gNB ソリューションがあります。5G コアの例としては、AWS Snowball Edge 上で動作する Athonet 5G Core があります。 XR デバイスは、プライベート 5G ネットワークを通じて、AWS Snowball Edge デバイスで提供されているリモートレンダリングサービスを使用できます。XR デバイスは、5G モデム、テザリングされた 5G スマートフォン、または 5G の WiFi ホットスポットを介して 5G ネットワークに接続することができます。XR デバイスは、リモートレンダリングサービスのために AWS Snowball Edge への有線接続を使用することもできます。 XR ストリーミングを開始するには、XR デバイスで実行する XR アプリケーションのクライアントを、リモートレンダリングの EC2 DNI インターフェースの IP アドレスに向けます。 まとめ AR/VR または XR アプリケーションは、リアルタイムでオブジェクトをリモートレンダリングすることで、GPU などの重いコンピューティングリソースをXR デバイス上に必要としないため、XR デバイスのコストとエネルギー消費を抑えることができます。 また、リモートレンダリングは、サーバー内のデータを保護するため、データ保護の点でも優れています。また、AWS のエッジサービスは、リモートレンダリングのための低レイテンシーとダウンロードにおいてスループットの要件に合います。このブログで、具体的には、パブリック 5G 環境向けの AWS Wavelength とプライベート 5G 環境向けの AWS Snowball Edge を使った 2 つのリモートレンダリングのアーキテクチャを参考としてご紹介しました。また、Holo-Light AR 3S XR のストリーミングを例として、2 つのリモートレンダリングのソリューションがどのように機能するかを説明しました。 AWS エッジサービスによる XR のためのリモートレンダリングを始めるのでしたら、パブリックな 5G 環境向けの AWS Wavelength と、プライベートな 5Gやオンプレミスの有線回線を使用する AWS Snowball Edge についてご参照ください。 このブログではご紹介しておりませんが、エッジの AWS Local Zones でも、インターネット接続、または XR デバイスとのプライベート接続を使用して、リモートレンダリングを行うアプリケーションを提供することもできます。CSP がホストする AWS Wavelength と比べて、AWS Local Zones は AWS によって管理される点が異なります。エッジソリューションのもう一つの選択肢として、AWS Local Zones もご検討いただけます。 Holo-Light XR リモートレンダリングを使用するには、 Holo-Light 公式ウェブサイト とブログ、「 XR Streaming: How Holo-Light Solves Major Problems of Augmented and Virtual Reality 」をご覧ください。SDK と XR エンジニアリング・アプリケーションの 無料トライアル・アクセス については、Holo-Light 社にお問い合わせください。また、上記のソリューションに加えて、 AWS Marketplace で AR 3S Pro Cloud の Amazon Machine Image (AMI)をテストすることも可能です。 Jim Huang Jim Hung は AWS ワールドワイド・テレコム・ビジネス・ユニットのプリンシパル・ソリューション・アーキテクトです。通信サービスプロバイダーや独立系ソフトウェアベンダー向けに、マルチアクセス・エッジ・コンピューティング、有線ブロードバンド、プライベート・モバイル・ネットワークの分野でソリューションの設計・開発に携わっています。それ以前は、Cisco でクラウドエンジニアリングアーキテクトおよびチームマネージャーとしてネットワーク製品の開発に従事しました。マサチューセッツ大学 Amherst 校でコンピューター工学の博士号を取得。 Philipp Landgraf フィリップ・ランドグラフは、没入型のソフトウェアとテクノロジーを専門とする Holo-Light 社の XR ストリーミング担当シニア・ディレクターです。XR のユースケースと展開のスケールに合わせた集中型ストリーミング・プラットフォームの開発を担当。フィリップはミュンヘン工科大学で物理学の修士号をもち、XR ソフトウェアとハードウェアの開発、企業市場におけるクラウドとエッジコンピューティングのエキスパートです。フィリップにとって、メタバースはデジタル社会の次の大きな一歩であり、人々がデジタル空間でシームレスに創造、構築、運営できるようにすることです。 翻訳は Solutions Architect の伊藤ジャッジ向子が担当しました。原文は こちら です。

10月4日、組織内のデータプロデューサーとコンシューマーの間でデータをカタログ化、検出、分析、共有、管理するための新しいデータ管理サービスである Amazon DataZone の一般提供の開始を発表しました。 AWS re:Invent 2022 では Amazon DataZone についての 事前発表 を行い、2023 年 3 月には パブリックプレビューをリリース しました。 前回の re:Invent の基調講演で、AWS の Databases, Analytics, and Machine Learning 担当バイスプレジデントである Swami Sivasubramanian は次のように述べました。「幸いなことに、私は DataZone の初期ユーザーとして、AWS の週次のビジネスレビューミーティングを開催してきました。このミーティングでは、ビジネス戦略の参考とするために、販売パイプラインと収益予測からのデータを集めています」。 基調講演中、Amazon DataZone の製品責任者である Shikha Verma が主導した デモ では、組織がこの製品を利用してより効果的な広告キャンペーンを作成し、データを最大限に活用する方法を示すためにデモンストレーションが行われました。 「すべての企業は、さまざまなデータストアに存在するデータを所有および利用する複数のチームで構成されています。データ担当者はこのデータをまとめなければなりませんが、このデータにアクセスしたり、データを把握したりするための簡単な方法を持っていません。DataZone は、データプロデューサーからコンシューマーまで、組織内の誰もが統制された方法でデータにアクセスしたり、データを共有したりできる統合環境を提供します」 データプロデューサーは Amazon DataZone を利用して、 AWS Glue データカタログおよび Amazon Redshift テーブルからの構造化データアセットをビジネスデータカタログに追加します。データコンシューマーは、データカタログ内のデータアセットを検索およびサブスクライブし、他のビジネスユースケースの協力者と共有します。コンシューマーは、Amazon DataZone ポータルから直接アクセスできるツール (Amazon Redshift や Amazon Athena クエリエディタなど) を使用して、サブスクライブしたデータアセットを分析できます。統合されたパブリッシュ-サブスクライブワークフローは、プロジェクト全体でのアクセス監査機能を提供します。 Amazon DataZone のご紹介 Amazon DataZone についてまだなじみがないお客様のために、その主要な概念と機能をご紹介します。 Amazon DataZone ドメインは、独自のデータ (独自のデータアセットや、データまたはビジネス用語の独自の定義を含む) を管理でき、独自の管理基準を設けている場合がある、組織内の事業部門 (LOB) やビジネス領域の明確な境界を表します。ドメインには、データポータル、ビジネスデータカタログ、プロジェクトや環境、組み込みワークフローなどのすべてのコアコンポーネントが含まれます。 データポータル (AWS マネジメントコンソールの外部) – これは、さまざまなユーザーがセルフサービスの形式でデータのカタログ化、検出、管理、共有、分析を行うことができるウェブアプリケーションです。データポータルは、 AWS IAM アイデンティティセンター を介して、 AWS Identity and Access Manager (IAM) 認証情報、または ID プロバイダーから提供される既存の認証情報を使用してユーザーを認証します。 ビジネスデータカタログ – カタログでは、分類法またはビジネス用語集を定義できます。このコンポーネントを使用すると、ビジネスコンテキストを含めて組織全体のデータをカタログ化し、組織内の全員がデータを迅速に検索および理解できるようにすることができます。 データプロジェクトと環境 – プロジェクトを使用して、ユーザー、データアセット、分析ツールのビジネスユースケースベースのグループを作成することで、AWS 分析へのアクセスを簡素化できます。Amazon DataZone のプロジェクトは、プロジェクトメンバーが共同作業、データ交換、データアセットの共有を行うことができるスペースを提供します。プロジェクト内では、分析ツールやストレージなどの必要なインフラストラクチャをプロジェクトメンバーに提供する環境を作成して、プロジェクトメンバーが新しいデータを簡単に生成したり、アクセス権のあるデータを利用したりできるようにすることができます。 ガバナンスとアクセスコントロール – 組織全体のユーザーがカタログ内のデータへのアクセスをリクエストし、データの所有者がそれらのサブスクリプションリクエストを確認して承認することを可能にする、組み込みワークフローを使用できます。サブスクリプションリクエストが承認されると、Amazon DataZone は、 AWS Lake Formation や Amazon Redshift などの基盤となるデータストアで許可を管理することで、自動的にアクセスを付与できます。 詳細については、「 Amazon DataZone の用語と概念 」をご覧ください。 Amazon DataZone の開始方法 まず、製品マーケティングチームが製品の導入を促進するキャンペーンを実行したいというシナリオを考えてみましょう。これを行うには、営業チームが所有する製品販売データを分析する必要があります。このチュートリアルでは、データプロデューサーとして機能する営業チームが Amazon DataZone で販売データを公開します。その後、データコンシューマーとして機能するマーケティングチームが販売データをサブスクライブし、キャンペーン戦略を構築するためにそのデータを分析します。 DataZone の仕組みを理解するために、Amazon DataZone の 開始方法ガイド を要約したものを見てみましょう。 1.ドメインを作成する DataZone の利用を初めて開始する際には、まずドメインと、ビジネスデータカタログ、プロジェクト、環境などのすべてのコアコンポーネントをデータポータルに作成して、それらのコンポーネントがそのドメイン内に存在するようにします。 Amazon DataZone コンソール に移動し、 [ドメインを作成] を選択します。 [ドメイン名] と説明を入力し、他の値はすべてデフォルトのままにします。 例えば、 [サービスアクセス] セクションで、デフォルトで [新しいロールを作成して使用] を選択すると、Amazon DataZone は、DataZone がドメイン内のユーザーに代わって API 呼び出しを実行することを認可するために必要な許可を持つ新しいロールを自動的に作成します。DataZone がすべての設定ステップを実行できる Quick Setup オプションのチェックをオンにします。 最後に、 [ドメインを作成] を選択します。Amazon DataZone は必要な IAM ロールを作成し、このドメインが AWS Glue データカタログ、Amazon Redshift、Amazon Athena などのアカウント内のリソースを使用できるようにします。ドメインの作成が完了するまでに数分かかる場合があります。ドメインのステータスが [使用可能] になるまで待ちます。 2.データポータルでプロジェクトと環境を作成する ドメインが正常に作成されたらそのドメインを選択し、ドメインの概要ページでルートドメインのデータポータル URL を確認して書き留めます。この URL を使用して、Amazon DataZone データポータルにアクセスできます。 [データポータルを開く] を選択します。 営業チームとして新しいデータプロジェクトを作成して販売データを公開するには、 [プロジェクトを作成] を選択します。 ダイアログボックスで、 [名前] として「Sales producer project」と入力し、このプロジェクトの [説明] を入力して、 [作成] を選択します。 プロジェクトを作成したら、このプロジェクトでデータおよび分析ツール (Amazon Athena や Amazon Redshift など) を使用するための環境を作成する必要があります。概要ページで、または [環境] タブをクリックした後、 [環境を作成] を選択します。 [名前] として「publish-environment」と入力し、この環境の [説明] を入力して、 [環境プロファイル] を選択します。環境プロファイルは、プロジェクトに追加される AWS アカウント、リージョン、VPC の詳細、リソースやツールなど、環境を作成するために必要となる技術的な詳細が含まれる事前定義済みのテンプレートです。 いくつかのデフォルトの環境プロファイルを選択できます。 DataLakeProfile を選択すると、Amazon S3 および AWS Glue ベースのデータレイクからデータを公開できるようになります。また、Amazon Athena を利用してアクセスできる AWS Glue テーブルに対するクエリも簡素化されます。 次に、オプションのパラメータをすべて無視して、 [環境を作成] を選択します。環境が IAM ロール、Amazon S3 サフィックス、AWS Glue データベース、Athena ワークグループなどの特定のリソースを AWS アカウントに作成するのに約 1 分かかります。これにより、プロジェクトのメンバーがデータレイクでデータを生成および利用することがより容易になります。 3.データポータルでデータを公開する AWS Glue テーブルでデータを公開する環境を作成できました。Amazon Athena でこのテーブルを作成するには、 [環境] ページの右側にある [データのクエリ] (Athena のリンクが設定されています) を選択します。 これにより、Athena クエリエディタが新しいタブで開きます。データベースのドロップダウンから publishenvironment_pub_db を選択し、次のクエリをクエリエディタに貼り付けます。これにより、環境の AWS Glue データベースに catalog_sales というテーブルが作成されます。 CREATE TABLE catalog_sales AS SELECT 146776932 AS order_number, 23 AS quantity, 23.4 AS wholesale_cost, 45.0 as list_price, 43.0 as sales_price, 2.0 as discount, 12 as ship_mode_sk,13 as warehouse_sk, 23 as item_sk, 34 as catalog_page_sk, 232 as ship_customer_sk, 4556 as bill_customer_sk UNION ALL SELECT 46776931, 24, 24.4, 46, 44, 1, 14, 15, 24, 35, 222, 4551 UNION ALL SELECT 46777394, 42, 43.4, 60, 50, 10, 30, 20, 27, 43, 241, 4565 UNION ALL SELECT 46777831, 33, 40.4, 51, 46, 15, 16, 26, 33, 40, 234, 4563 UNION ALL SELECT 46779160, 29, 26.4, 50, 61, 8, 31, 15, 36, 40, 242, 4562 UNION ALL SELECT 46778595, 43, 28.4, 49, 47, 7, 28, 22, 27, 43, 224, 4555 UNION ALL SELECT 46779482, 34, 33.4, 64, 44, 10, 17, 27, 43, 52, 222, 4556 UNION ALL SELECT 46779650, 39, 37.4, 51, 62, 13, 31, 25, 31, 52, 224, 4551 UNION ALL SELECT 46780524, 33, 40.4, 60, 53, 18, 32, 31, 31, 39, 232, 4563 UNION ALL SELECT 46780634, 39, 35.4, 46, 44, 16, 33, 19, 31, 52, 242, 4557 UNION ALL SELECT 46781887, 24, 30.4, 54, 62, 13, 18, 29, 24, 52, 223, 4561 ドロップダウンメニューに 2 つのデータベースが表示されます。 publishenvironment_pub_db は、新しいデータを生成し、それを DataZone カタログに公開することを選択するためのスペースを提供します。もう 1 つの publishenvironment_sub_db は、プロジェクトメンバーがプロジェクト内のカタログのデータをサブスクライブまたはアクセスする場合に使用します。 catalog_sales テーブルが正常に作成されたことを確認してください。これで、Amazon DataZone カタログに公開できるデータアセットが完成しました。 データプロデューサーは、データポータルに戻って、このテーブルを DataZone カタログに公開できます。上部のメニューで [データ] タブを選択し、左側のナビゲーションペインで [データソース] を選択します。 環境内には、自動的に作成されたデフォルトのデータソースがあります。このデータソースを開くと、 catalog_sales テーブルを作成したばかりの環境の公開データベースが表示されます。 このデータソースは、公開データベース内で見つかったすべてのテーブルを DataZone に取り込みます。デフォルトでは、自動メタデータ生成が有効になっています。これは、データソースが DataZone に取り込むアセットが、そのアセットのテーブルと列のビジネス名を自動的に生成することを意味します。このデータソースで [実行] を選択します。 データソースの実行が完了すると、 [データソースの実行] に catalog sales テーブルが表示されます。 このアセットを開くと、テーブルのスキーマや、他のいくつかの技術的な詳細 (AWS アカウント、リージョン、データの物理的な場所など) を含む技術メタデータを、公開ジョブが自動的に抽出しているのを確認できます。 これらのメタデータが正しいと思われる場合は、各推奨項目の脳のアイコンをクリックするか、またはすべての推奨項目について [すべて承認] ボタンをクリックするだけで、これらの推奨項目を承諾できます。公開する準備ができたら、 [アセットを公開] を選択し、ダイアログボックスで再確認します。 4.データコンシューマーとしてデータをサブスクライブする 次に、役割をマーケティングチームに切り替えて、このテーブルのサブスクリプションまたはアクセスをリクエストする方法を見てみましょう。データコンシューマーとして、前と同じステップを繰り返して「Marketing consumer project」という新しいプロジェクトと「subscriber-environment」という新しい環境を作成します。 新しく作成したプロジェクトで、検索バーに「catalog sales」と入力すると、公開されたテーブルが検索結果に表示されます。 [カタログ販売データ] を選択します。 カタログで、 [サブスクライブ] を選択します。 [カタログ販売データをサブスクライブ] ウィンドウで、マーケティングコンシューマープロジェクトを選択し、サブスクリプションリクエストの理由を入力して、 [サブスクライブ] を選択します。 データプロデューサーとしてサブスクリプションリクエストを受け取ると、セールスプロデューサープロジェクトのタスクを通じて通知されます。ここではサブスクライバーとパブリッシャーの両方の役割を担っているため、通知が表示されます。 この通知をクリックすると、アクセスをリクエストしたプロジェクト、リクエストを実行したユーザー、およびアクセスが必要な理由を含むサブスクリプションリクエストが開きます。 [承認] を選択し、承認の理由を入力します。 サブスクリプションが承認されたので、マーケティングコンシューマープロジェクトでカタログ販売データを表示できるようになりました。これを確認するには、トップメニューの [データ] タブを選択し、左側のナビゲーションペインで [データソース] を選択します。 サブスクライブデータを分析するには、トップメニューの [環境] タブを選択し、マーケティングコンシューマープロジェクトで作成した Subscribe-environment を選択します。右側のペインに新しい [データのクエリ] リンクが表示されます。 カタログ販売テーブルがサブスクリプションデータベースの下に表示されていることがわかります。 このテーブルにアクセスできることを確認するには、テーブルをプレビューして、クエリが正常に実行されることを確認します。 これにより、Athena クエリエディタが新しいタブで開きます。データベースのドロップダウンから subscribeenvironment_sub_db を選択し、クエリエディタにクエリを入力します。 これで、コンシューマー (マーケティングチーム) としてサブスクライブし、プロデューサー (営業チーム) によってビジネスデータカタログに公開された販売データテーブルに対してクエリを実行できるようになりました。 AWS Glue テーブルや Amazon Redshift テーブルおよびビューの公開などの詳細なデモについては、YouTube のプレイリストをご覧ください。 GA での新機能 プレビュー中、お客様から多くの関心とすばらしいフィードバックをお寄せいただきました。少し時間を割いてそれらの機能を確認し、いくつかの改善点をご紹介します。 エンタープライズ対応ビジネスカタログ – ビジネスコンテキストを追加し、組織内の全員がデータを検出できるようにするために、自動メタデータ生成を使用してカタログをカスタマイズできます。自動メタデータ生成では、機械学習を使用して、データアセットと、それらのアセット内の列のビジネス名を自動的に生成します。また、メタデータのキュレーション機能も改善しました。GA では、複数のビジネス用語集の用語をアセットにアタッチしたり、用語集の用語をアセット内の個別の列にアタッチしたりできます。 データユーザー向けのセルフサービス – データの自律性を提供して、ユーザーがデータを公開および利用できるようにするために、API を使用してあらゆるタイプのアセットをカスタマイズし、カタログに取り込むことができます。データパブリッシャーは、取り込みジョブを通じてメタデータの検出を自動化することも、 Amazon Simple Storage Service (Amazon S3) からファイルを手動で公開することもできます。データコンシューマーは、ファセット検索を使用して、データを迅速に検索および理解できます。ユーザーは、システムの更新や実行すべきアクションについて通知を受けることができます。これらのイベントは、アクションをカスタマイズするために Amazon EventBridge を利用してお客様のイベントバスに出力されます。 分析へのアクセスの簡素化 – GA では、プロジェクトはビジネスユースケースベースの論理コンテナとして機能します。プロジェクトを作成し、特定のビジネスユースケースに基づいてユーザー、データ、分析ツールをグループ化して共同作業できます。プロジェクト内では、分析ツールやストレージなどの必要なインフラストラクチャをプロジェクトメンバーに提供する環境を作成して、プロジェクトメンバーが新しいデータを簡単に生成したり、アクセス権のあるデータを利用したりできるようにすることができます。これにより、ユーザーは、ニーズに応じて複数の機能や分析ツールを同じプロジェクトに追加できます。 統制されたデータ共有 – データプロデューサーは、コンシューマーがアクセスをリクエストし、データ所有者が承認することを可能にするサブスクリプション承認ワークフローを使用して、データへのアクセスを所有および管理します。公開時にアセットにアタッチされるサブスクリプション条件を設定したり、AWS マネージドのデータレイクと Amazon Redshift のサブスクリプション付与のフルフィルメントを自動化したりできるようになりました (他のソースのために EventBridge イベントを利用してカスタマイズすることもできます)。 今すぐご利用いただけます Amazon DataZone は現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム)、南米 (サンパウロ) の 11 の AWS リージョンで一般提供されています。 Amazon DataZone の無料トライアルをご利用いただけます。これには、利用開始後の最初の 3 暦月間にわたって、50 名のユーザーによる追加料金なしでの利用が含まれています。無料トライアルは、AWS アカウントに初めて Amazon DataZone ドメインを作成したときに開始されます。試用期間中に月間ユーザー数を超過した場合は、 標準料金 に基づいて課金されます。 詳細については、 製品ページ および ユーザーガイド をご覧ください。フィードバックは、 AWS re:Post for Amazon DataZone 宛てに、または通常の AWS サポートの連絡先を通じてお寄せいただけます。 – Channy 原文は こちら です。

9月25日週、私は AWS Summit Johannesburg に参加しました。これは 2019 年以来、自分の出身国、そして出身都市で開催される初めてのサミットだったので、参加する機会を得られたことは非常に特別なことでした。とても多くのお客様にお会いすることができ、AWS 上でどのように構築しているのかをお伺いできて光栄でした。 さて、AWS の最新情報を見てみましょう。知っておくべきいくつかのお知らせと今後のイベントをまとめました。それでは、始めましょう! 9月25日週のリリース Amazon Bedrock の一般提供を開始 – Amazon Bedrock は、AWS 上で生成系 AI を使用して構築するための新しいツールセットの一部として、2023年 4 月にプレビューで発表されました。このサービスの一般提供が開始されるという9月25日週のお知らせについて、多くのお客様から喜びの声が寄せられました。また、複数のお客様から、Amazon Bedrock を利用して構築しているものを既にご共有いただいています。 AWS サーバーレスヒーローである Jones Zachariah Noel 氏のこの気楽な投稿 は、Amazon Bedrock で Stability AI の Stable Diffusion XL 画像生成モデルを使用して生成した「交通渋滞した道路のあるベンガルール」の画像についてのものです。私はとても面白いと思いました。 Amazon MSK が Apache Kafka からデータレイクへのマネージドデータ配信を導入 – Amazon MSK は、お客様が本番環境での Apache Kafka の設定、スケール、管理に必要な作業を軽減できるように、2019 年にリリースされました。今後は、Apache Kafka クラスターから Amazon Simple Storage Service (Amazon S3) にデータを継続的にロードできるようになりました。 AWS のその他のニュース 以下では、他の注目すべきニュースやブログ記事をいくつかご紹介します。 Community.AWS Blog では、ビルダーは、クラウドを熱心に利用するユーザーのコミュニティと知識を共有したり、学習したりできます。このブログの寄稿者には、AWS の従業員、AWS ヒーロー、AWS コミュニティビルダー、および AWS コミュニティの他のメンバーが含まれます。先週、 AWS ヒーローである Johannes Koch 氏が、AppSync でマージされた API を利用したサーバーレスバックエンドとインタラクションする Flutter を使用して、シンプルなウェブサイトを構築する方法に関するすばらしい記事を公開しました 。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページを定期的にご覧ください。 AWS の今後のイベント 以下のイベントが近日開催予定です。 AWS Cloud Days (10 月 10 日、24 日) – アテネ と プラハ で開催される AWS Cloud Day で、AWS について学習しながら、似た考えを持つ他の仲間とつながり、コラボレーションできます。 AWS Innovate Online (10 月 19 日) – AWS Innovate Online に 登録 して、極めて広範なクラウドプラットフォームで次世代アプリケーションを構築、実行、スケールする方法を学びましょう。 80 以上 のセッションが 5 つの言語で提供されます。また、学習したすべての内容を証明する出席証明書が提供されます。 私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をいただけますと幸いです。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 – Veliswa 原文は こちら です。

9月28日、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の新機能を発表しました。この機能を使用することで、 Apache Kafka クラスターから Amazon Simple Storage Service (Amazon S3) にデータを継続的にロードできるようになります。抽出、変換、ロード (ETL) サービスである Amazon Kinesis Data Firehose を利用して、Kafka トピックからデータを読み取り、レコードを変換し、Amazon S3 の送信先に書き込みます。Kinesis Data Firehose はフルマネージドであり、コンソールで数回クリックするだけで設定できます。コードやインフラストラクチャは必要ありません。 Kafka は、システムまたはアプリケーション間で大量のデータを確実に移動するリアルタイムデータパイプラインを構築するために一般的に使用されています。これは、スケーラビリティと耐障害性に優れたパブリッシュ/サブスクライブメッセージングシステムを提供します。AWS の多くのお客様は、クリックストリームイベント、トランザクション、IoT イベント、アプリケーションやマシンのログなどのストリーミングデータをキャプチャするために Kafka を採用しており、リアルタイム分析と継続的な変換を実行して、このデータをデータレイクおよびデータベースにリアルタイムで配布するアプリケーションを持っています。 ただし、Kafka クラスターのデプロイに課題がないわけではありません。 1 つ目の課題は、Kafka クラスター自体をデプロイ、設定、メンテナンスすることです。この点に鑑みて、弊社は 2019 年 5 月 に Amazon MSK をリリースしました。MSK は、本番環境での Apache Kafka の設定、スケール、管理に必要な作業を減らします。インフラストラクチャは当社が管理するため、お客様はデータとアプリケーションに注力できます。2 つ目の課題は、Kafka からのデータを使用するアプリケーションコードを記述、デプロイ、管理することです。通常、 Kafka Connect フレームワーク を使用してコネクタをコーディングし、そのコネクタを実行するためのスケーラブルなインフラストラクチャをデプロイ、管理、メンテナンスする必要があります。インフラストラクチャに加えて、データ変換および圧縮ロジックをコーディングし、最終的なエラーを管理して、Kafka からの転送 (OUT) 中にデータが失われないように再試行ロジックをコーディングする必要もあります。 本日、 Amazon Kinesis Data Firehose を利用して Amazon MSK から Amazon S3 にデータを配信するためのフルマネージドソリューションが利用可能になったことを発表します。このソリューションはサーバーレスであるため、管理するサーバーインフラストラクチャは存在せず、コードも必要ありません。データ変換とエラー処理ロジックは、コンソールで数回クリックするだけで設定できます。 ソリューションのアーキテクチャを次の図に示します。 Amazon MSK はデータソース、Amazon S3 はデータの送信先であり、 Amazon Kinesis Data Firehose はデータ転送ロジックを管理します。 この新しい機能を使用すると、Amazon MSK からデータを読み取り、変換し、結果として得られたレコードを Amazon S3 に書き込むためのコードを開発する必要がなくなります。Kinesis Data Firehose は、読み取り、変換と圧縮、Amazon S3 に対する書き込みオペレーションを管理します。また、問題が発生した場合のエラーと再試行ロジックも処理します。システムは、処理できないレコードを、手動検査のために選択した S3 バケットに配信します。このシステムは、データストリームの処理に必要なインフラストラクチャも管理します。転送するデータ量に合わせて自動的にスケールアウトおよびスケールインします。お客様側でプロビジョニングやメンテナンスの操作を行う必要はありません。 Kinesis Data Firehose 配信ストリームは、パブリックとプライベートの両方の Amazon MSK プロビジョンドクラスターまたはサーバーレスクラスターをサポートします。また、MSK クラスターから読み取り、異なる AWS アカウントの S3 バケットに書き込むためのクロスアカウント接続もサポートしています。Data Firehose 配信ストリームは、MSK クラスターからデータを読み取り、設定可能なしきい値のサイズと時間でデータをバッファリングし、バッファリングされたデータを単一のファイルとして Amazon S3 に書き込みます。MSK と Data Firehose は同じ AWS リージョンに存在する必要がありますが、Data Firehose は他のリージョンの Amazon S3 バケットにデータを配信できます。 Kinesis Data Firehose 配信ストリームはデータ型も変換できます。JSON から Apache Parquet および Apache ORC 形式への変換をサポートする組み込み変換機能を備えています。これらは、スペースを節約し、Amazon S3 に対するクエリの高速化を可能にする列指向のデータ形式です。JSON 以外のデータの場合は、データを Apache Parquet/ORC に変換する前に、 AWS Lambda を利用して CSV、XML、構造化テキストなどの入力形式を JSON に変換できます。さらに、データを Amazon S3 に配信する前に、Data Firehose からデータ圧縮形式 ( GZIP 、 ZIP 、 SNAPPY など) を指定したり、データを raw 形式で Amazon S3 に配信したりできます。 仕組みを見てみましょう 使用を開始するために、Amazon MSK クラスターが既に設定されており、いくつかのアプリケーションがそのクラスターにデータをストリーミングしている AWS アカウントを使用します。使用を開始し、最初の Amazon MSK クラスターを作成するには、 チュートリアルをお読みいただく ことをお勧めします。 このデモでは、コンソールを使用してデータ配信ストリームを作成および設定します。これに代えて、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、または Terraform を使用することもできます。 AWS マネジメントコンソール の Amazon Kinesis Data Firehose ページに移動し、 [配信ストリームを作成] を選択します。 データ [ソース] として Amazon MSK を選択し、配信の [送信先] として Amazon S3 を選択します。このデモでは、プライベートクラスターに接続したいので、 [Amazon MSK クラスター接続] で [プライベートブートストラップブローカー] を選択します。 クラスターの完全な ARN を入力する必要があります。ほとんどのユーザーと同じように、私も ARN を思い出せないため、 [参照] を選択し、リストからクラスターを選択します。 最後に、この配信ストリームの読み取り元となるクラスターの [トピック] 名を入力します。 ソースを設定したら、ページを下方向にスクロールして、データ変換セクションを設定します。 [レコードを変換および転換] セクションで、独自の Lambda 関数を提供して JSON にないレコードを変換するか、またはソース JSON レコードを 2 つの使用可能な事前構築済みの送信先データ形式 ( Apache Parquet または Apache ORC ) のいずれかに変換するかを選択できます。 Amazon S3 からデータをクエリする場合、Apache Parquet および ORC 形式は JSON 形式よりも効率的です。ソースレコードが JSON 形式の場合、これらの送信先データ形式を選択できます。 AWS Glue のテーブルからデータスキーマを提供する必要もあります。 これらの組み込み変換機能により、Amazon S3 のコストが最適化され、ダウンストリーム分析クエリが Amazon Athena 、 Amazon Redshift Spectrum 、または他のシステムで実行される際にインサイトを取得するまでの時間が短縮されます。 最後に、送信先の Amazon S3 バケットの名前を入力します。繰り返しになりますが、思い出せない場合は、 [参照] ボタンを使用して、コンソールのガイドに従ってバケットのリストを確認します。必要に応じて、ファイル名として [S3 バケットプレフィックス] を入力します。このデモでは、 aws-news-blog と入力します。プレフィックス名を入力しない場合、Kinesis Data Firehose は、日付と時刻 (UTC) をデフォルト値として使用します。 [バッファのヒント、圧縮、暗号化] セクションで、バッファリングのデフォルト値を変更したり、データ圧縮を有効にしたりできるほか、 KMS キーを選択して、Amazon S3 の保管中のデータを暗号化することもできます。 準備ができたら、 [配信ストリームを作成] を選択します。しばらくすると、ストリームのステータスが (使用可能) に変わります。 ソースとして選択したクラスターにデータをストリーミングするアプリケーションがあると仮定した場合、S3 バケットに移動して、Kinesis Data Firehose がストリーミングする際に、選択した送信先の形式でデータが表示されることを確認できるようになりました。 ご覧のとおり、Kafka クラスターからのレコードの読み取り、変換、書き込みにコードは必要ありません。また、ストリーミングと変換ロジックを実行するための基盤となるインフラストラクチャを管理する必要もありません。 料金と利用可能なリージョン。 この新しい機能は現在、 Amazon MSK と Kinesis Data Firehose が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon MSK から送信されるデータ量 (GB/月で測定) についての料金をお支払いいただきます。請求システムでは、正確なレコードサイズが考慮されます。丸めはありません。いつものように、 料金ページ ですべての詳細をご確認いただけます。 この新しい機能を採用した後に、どの程度の量のインフラストラクチャやコードが廃止されるのかをお聞きするのが待ちきれません。 今すぐ、Amazon MSK と Amazon S3 の間の最初のデータストリームを設定しましょう 。 — seb 原文は こちら です。

Amazon Web Services (AWS) は、デジタルネイティブな食品飲料ブランドから大手ファッション、アパレル企業まで、世界中で多数の消費財（Consumer Packaged Goods; CPG）企業のお客様を支援しています。消費財企業にとって、データの統合と分析は長年にわたり投資の最優先事項となっています。柔軟で俊敏、そしてスケーラブルなクラウドプラットフォーム、またオンプレミス環境には存在しなかったような新しい分析基盤の利用の拡がりによって、この傾向は加速の傾向にあります。 データ分析が広範な業務領域に導入されていることは、次のようなソリューションの需要が市場で急速に成長することにも顕れています： データ分析市場 は、2023 年の 70.4 億ドルから、2030 年までに 3,034 億ドルに成長すると予測されている Analytics-as-a-Service 市場 は、2023 年の 92 億ドルから、 2030 年までに 401 億ドルに成長すると予測されている 産業分析市場 は年率 15.4% で成長し、2030 年までに 547 億ドルに達すると予想されている 人工知能市場 は、2023 年の 5,153 億ドルから 2030 年までに 2 兆 251 億ドルに成長すると予測されている よりデータ駆動な組織となりたい、という要望は過去 5 年間にわたり私たちのお客様における共通のテーマの一つです。データ駆動型の組織作りのベストプラクティスを明らかにするべく、我々は Amazon、AWS、先進的な消費財企業のお客様においてパフォーマンスの高いデータ駆動型組織とともに協業してきました。 コラボレーションの成果を、データ駆動型組織作り成功のための新しいアプローチ「 Making The Shift to Data Products – The missing guide for how organizations become data driven 」としてまとめました。このホワイトペーパーでは、ビジネス成果を上げるための自動化を提案し優先順位付けし、予算化、組織化、提供する方法に焦点を当てています。データプロダクトというアプローチは、IT 部門の分析チームの現行のオペレーションとは異なるものですが、消費者向けプロダクト（商品）でビジネスを成長させてきた消費財企業リーダーにとっては馴染みのあるものであるはずです。 消費財企業にとって商品管理は得意とするところです。大きな責任を持つブランドオーナー、厳しい SKU 最適化のテクニック、効率的にステージゲートを行うための手順を確立して、ブランド、商品、包装、価格、チャネルの決定をサプライチェーン、製造、販売のチーム全体で調整、承認できるようにしてきました。すべては、消費者に愛されるブランドを作りたいという願望から生まれています。データプロダクトはデータ分析に対する新しいアプローチではありますがが、消費財企業の既存の商品体験と文化がデータ駆動型組織作りにどれほど適用されているか知れば驚くことでしょう。 現状の課題 データ分析への投資に苦戦している消費財企業もあります。なぜなのでしょうか。苦戦している顧客企業から「データは豊富にあるのにインサイトに至らない」という話を聞きます。過去十年間におけるデータセットの爆発的な増加は驚くべきものであるにも関わらず、データから価値を引き出せている、と感じている企業はほとんどありません。さらに、データから洞察が得られていてもそれがビジネス上のアクションにほとんど繋げられていない、という声も聞きます。過去この領域に投資したのに投資効果をほとんど得られなかった企業リーダーは、ビジネスに変化をもたらす新しいテクノロジーの力に当然のことながら懐疑的になっています。顧客企業からの典型的な意見には次のようなものがあります： 「会議では、誰のスプレッドシートのデータが正しいのかが議論になる。」 「データは大量にあるが、意味のある活動に繋がっていない。」 「データセットを見つけアクセスすることがものすごく困難だ。」 「データにアクセスできても、データが意味するものを理解するのが困難だ。」 「データ分析の投資対効果が得られていない。」 データ分析への投資が企業の年間ビジネス目標や取り組みと一致しておらず、結果が未達に終わることがよくあります。データレイクのプロジェクトが組織のボトルネックにつながっている可能性もあります。分析やインサイトの基盤を導入するために、企業が望まないビジネスプロセスの変更が必要になる場合もあります。継続的オペレーションのための予算不足から分析プロジェクトが停滞することもあります。 しかしながら、こういった失敗のほとんどはテクノロジーに起因するものではなく、適切なプロセスの採用と展開方法が欠けていることによるものです。 データプロダクトへのアプローチ データプロダクトというアプローチをより詳しく見てみましょう。データプロダクトは、データと自動化を活用しダイレクトなビジネス価値を提供するものです。データプロダクトチームは俊敏性を備え、継続的に予算を提供できるプロダクトオーナー、そしてビジネスステークホルダーと緊密に連携する小規模チームがリードします。 データプロダクトには、ビジネス目標に対してどのようにパフォーマンスを発揮するかを測定するための SLA とメトリクスが明確に定義されます。データプロダクトには 4 つの成熟度レベルがあります： 可視性 アラート ガイダンス 自動化（最終目標） 組織内のデータプロダクトについてこの成熟度モデルのどの段階に該当するかを考えてみてください。取り組みを始めたばかりの組織は可視性に重点を置いていることが多いでしょう。一方、成熟したデータ組織であれば可視性から自動化までのプロダクトを揃え、より自動化にフォーカスしているでしょう。 可視性の一例として、 AWS Supply Chain Control Tower ダッシュボードが挙げられます。これは様々なシステムからデータを収集し、パフォーマンスや運用上の課題、商品の搬送状況を可視化します。このシステムを使用することで配送センター、仕分けセンター、フルフィルメントセンター、そしてビジネス全体で利用されるあらゆる輸送手段といったネットワーク全体の KPI をビジネスオーナーが確認することができます。 このダッシュボードは可視性レベル（成熟度は低い）の一例ではありますが、それでも実現するためには多くの作業を必要とします。このような可視性を実現するためには以下のような要素が要求されます： サプライチェーン内の各コンポーネントにアクセスするための標準 API 一元化されたデータウェアハウスへの統合。これによりレポート作成を可能にし、データ品質を強化 データ標準化 ロール（役割）に応じたデータアクセス制御 成熟度モデルの最終目標はデータプロダクトの自動化です。Amazon.com における商品検索機能はそのよい例です。Amazon で購入される商品の大部分は検索結果から参照されており、検索アルゴリズムの改善により消費者体験が大きく向上します。それが収益の増加に繋がっています。 Amazon が使用している検索機能には興味深い点がいくつかあります。まず、カート追加、クリック、購入といったユーザーのアクションによって学習された人工知能（AI）が使われています。この AI は一日に数回再学習されています。また、Amazon における長年にわたる商品検索とそこから購入に繋がったデータも考慮されます。マーチャンダイジングのスコアや価格、評価、レビューも考慮することで、Amazon は消費者が喜びそうな商品だけを紹介しています。最後に、消費者の検索レベルが高い場合には、配送速度も考慮し多様な種類の商品を表示します。成熟度の高い「自動化」データプロダクトとして、専任のチームと予算を持つプロダクトオーナーがおり、プロダクト自体が完全に自動化されています。 データプロダクト戦略を成功させるための 5 つの信条 データプロダクト戦略を構築し維持していく鍵として次の 5 つがあります： Working Backwards（ワーキング・バックワーズ） 。新しいデータプロダクトを提案する際、課題やビジネス目標から逆のぼって考えます。いくつかの質問を繰り返してデータプロダクトの必要性を明確にしていきます。このプロダクトのお客様は誰でしょう？お客様の課題や目標は何ですか？お客様にとっての最大のメリットは何ですか？ お客様の要望をどうやって知りますか？ Two pizza チーム 。小規模で俊敏なチーム（「ピザ 2 枚」で十分満足できる人数、という意味でこう呼ばれます）が、完全に責任を持ち迅速に行動します。プロダクトオーナー、ステークホルダー、プロダクトパイプライン、運用計画が備わっています。主要なパフォーマンス指標が識別されており、明確に定義された目標を持ちます。 ビジネス目標に基づく優先順位付け 。 多くの分析イニシアチブは年間のビジネス目標と一致していないため、分析からビジネス価値を得ることができないことがよくあります（ある世界規模の消費財企業では、構築したダッシュボードの 80% がまったく使用されていない、と話していました）。 集中管理されたデータチームが提供するデータやビジネス領域を理解していないことが多く、この状況をさらに悪化させます。最高のデータプロダクトチームはビジネスと高度に連携しており、チームのリーダーからのコミットメントを取り付けてから機能を提供します。 SLA と KPI 。データプロダクトに対し、稼働時間、データ品質、レスポンス時間などのサービスレベルを明確に定義します。顧客獲得コスト、予測精度、カートサイズといった KPI がいずれも収益増加、利益率向上というビジネス目標を達成するために積み上げられるようになります。 ロードマップ 。成功しているデータプロダクトオーナーは、ビジネスステークホルダーの意見に基づく機能のバックログを慎重に精選しています。チームの規模とビジネス価値に基づき継続的に予算を確保するための運営計画を実施しています。 データプロダクトのアプローチは、データセキュリティ、エンタープライズアーキテクチャ、ガバナンスに関する疑問を提起する新しい方法です。データプロダクトにおいては、データプロダクトチームにビジネス結果における責任が生じるという点がこれまでと根本的に異なります。 IT チームとエンタープライズアーキテクチャチームは CISO （Chief Information Security Officer）と協力し、クラウド環境のプロビジョニングやツールのゲートキーパーではなく、機能を実現するために活動します。データプロダクトチームは、データのセキュリティ、プライバシー、データ漏洩に関する企業の要件を満たさねばなりませんが、これらの要件を満たす方法に関しては柔軟性も備えます。 まとめ 統合されたデータと分析は、今後も長きにわたり消費財企業の投資最優先事項であり続けるでしょう。組織内のデータプロダクトについて考える際には、自分の組織が成熟度モデルのどこに位置するかの検討し、今回ご紹介した 5 つの信条を参考書として活用し、成功戦略を立てそれを維持してください。 詳細については、ホワイトペーパー「 Making The Shift to Data Products – The missing guide for how organizations become data driven 」もご覧ください。あるいは AWS Data Products にメールまで連絡ください。AWS 担当営業に問い合わせ、データ駆動への道を歩み始める方法を相談することもできます。 参考文書 AWS Digital Innovation Program Online Workshop Drive Costs Out: How AWS helps large CPG companies simplify and scale to drive operational efficiencies Build Great Brands Consumers Love   著者について Michael Connor Michael Connor は、AWS 消費財向けグローバルソリューションリードとして、クラウド テクノロジーを使用してお客様が収益増加とデジタル変革の目標を達成するお手伝いをしています。前職コカ・コーラのフリースタイルのチーフアーキテクトとして、デジタルイノベーション、データサイエンス、アナリティクス、エンタープライズアーキテクチャを主導した豊富な経験があります。デジタル変革の一環としてコカ・コーラ・ノースアメリカのエンタープライズクラウドへの移行をリードし、コカ・コーラのイノベーショングループを率いて開発した IP は 2020 年の同社のトップ 4 イノベーションのうちの3つにあたります。AWS カスタマーアドバイザリーボードのメンバーを 5 年間務めました。人工知能、自動化、プライバシー、文化、倫理といった領域に情熱を注いでいます。 Justin Honaman Justin Honaman は、AWS グローバルに消費財小売業界の Go-to-Market チームを率いています。食品飲料のセグメントリーダーでもあります。消費財小売業界において、世界中のお客様にサプライチェーン、e コマース、データ分析、デジタルエンゲージメントに関するビジネスソリューションを提供することに注力しています。   翻訳は Solutions Architect 杉中が担当しました。原文は こちら です。

こんにちは。ソリューションアーキテクト (以下 SA) の高野です。 2023 年 9 月 22 日に「 AWS 秋の Observability 祭り 」と題したイベントを開催しました。昨今システムを運用する上で重要となってきている Observability をテーマにしたイベントです。ご参加いただきました皆様には、改めて御礼申し上げます。 当日の様子と実施内容 AWS から Amazon CloudWatch をはじめとする Observability 関連サービスの最新アップデートやベストプラクティス、Observability のコード化のメリットをお伝えするとともに、実際に AWS 上のシステムを運用されているお客様 (株式会社 NTTドコモ様、株式会社デイトナ・インターナショナル様) から Observability を獲得するための実ノウハウを共有いただきました。本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開致します。システムに Observability を獲得したい方はぜひご確認下さい！     セッションの紹介 [AWS セッション] Amazon CloudWatch はじめとした Observability の最近のアップデート紹介 アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 伊藤 威 資料ダウンロード セミナー開始ということで、SA 伊藤より、Observability がなぜ必要なのか？という話から、AWS における Observability 関連サービスの概要、Amazon CloudWatch 全体像と最新のアップデートを紹介しました。Amazon CloudWatch は日々アップデートが重ねられており、できることが増えてきています。本資料に、2023 年の主要なアップデートをまとめて記載していますので、ぜひご確認下さい。 [AWS セッション] Observability と Dashboard Best Practice アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 宮崎 友貴 資料ダウンロード   次に SA 宮崎より、AWS における Observability のベストプラクティス、またその中でも重要なデータの可視化を行うダッシュボードのベストプラクティスと CloudWatch Dashboard をご紹介しました。AWS では Observability のベストプラクティスを公開しております。本資料では、その概要を紹介していますが、もうイベントで紹介できなかった部分や詳細については URL リンク を確認下さい。また、同様に、運用を可視化するためのダッシュボードについて Amazon で実際に取り入れている設計方針を公開しております。気になられる方は、 URL リンク をご確認下さい。 [お客様事例] NTTドコモ様 マイクロサービスのためのシステム運用を一瞬でラクにするオブザーバビリティ事例 株式会社NTTドコモ スマートライフカンパニー 第一プロダクトデザイン部 マーケティングイノベーション・カスタマーサクセス担当 森 晴菜 様、川嵜 哲生 様 資料ダウンロード NTTドコモ様は、スーパー販促プログラムと呼ばれている d ポイントや d 払いでお買い物をしてくれたお客様と、 友達追加無しで直接コミュニケーションが可能になるサービスを提供しています。本システムは、多数のシステムと連携しており、構成が複雑化していることから、どこで何が起きているか、Observability がないとシステム運用が難しい状態でした。当事例では、本システムでどのようにして “ラクに“ Observability を獲得したのかについてご紹介いただきました。 Amazon CloudWatch 等の AWS サービスの監視項目を ダッシュボードのテンプレートが提供されている Datadog に集約し、システム状況の可視化を効率的に行っている旨をご紹介いただきました。併せて、Amazon CloudWatch と Datadog の使い分けや、運用上取得が必須のメトリクスを Amazon CloudWatch カスタムメトリクスを使って取得している実例をご紹介いただきました。関連システムの多い状況下で運用している方に参考になるのではないかと思います。 [AWSセッション] Observability as Code の必要性 アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 津郷 光明 資料ダウンロード SA 津郷から、Observability as Code の必要性についてご紹介しました。日々の運用の中でシステム構成が変わることがあるかと思いますが、それに追従して、Observability に関するリソースも変更が必要になります。これを手動で変更すると設定ミスや開発スピードの低下が発生する可能性があります。そこで、本セッションでは、Observability に対しても Infrastructure as Code を適用し管理していくことで、本課題の解決に寄与できることを紹介しております。そのためのツールとして、AWS CloudFormation や AWS Cloud Development Kit (AWS CDK)、Terraform をご紹介し、AWS CDK を使った Observability as Code の実例をお見せしています。ご興味のある方はぜひご確認下さい。 [お客様事例] デイトナ・インターナショナル様 EC サイトのサーバ監視 : コード化の取り組みとメリット 株式会社デイトナ・インターナショナル DX 本部 システムソリューション部 WEB APPLICATION Sec 金子 誉万 様 資料ダウンロード デイトナ・インターナショナル様は、Daytona Park (デイトナパーク) という EC サイトを運営されております。 API 基盤は、AWS 上で稼働しており、AWS リソースを監視するための設定を手作業で行っていました。手作業では、リソース変更の度に、監視設定登録作業が必要になり運用負荷が高く、設定ミス・設定漏れが発生しやすいという課題を抱えている状態でありました。この状況を改善するために、Observability as Code をチャレンジされている旨をご紹介いただきました。セッション内で、AWS CDK と CDK for Terraform を組み合わせてリソース変更に監視設定が追従していく様子をデモで実演いただきました。AWS リソースの変更を AWS CDK で行うだけで、CDK for Terraform のコード変更なしに Datadog で構築されているダッシュボードが更新されます。リソース変更が頻繁に発生するようなシステムの運用をされている多くの方に参考になるのではないかと思います。 まとめ 今回は、運用しているシステムに Obsevability を獲得するために日々格闘しているお客様の実例をご紹介いただきました。本イベントをきっかけに、皆様のシステム運用が少しでもラクになり、皆様がハッピーになることを願っております。今後も、お客様のシステム運用が少しでも効率化できるように、このようなイベントを企画し、情報発信を継続していきます。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 高野 翔史