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 のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 高野 翔史

10月20日(金)に無料ウェビナー AWS Purpose Built Database Webinar 「AWS リレーショナル データベースのディザスタ リカバリ戦略」 を開催します。 本セッションでは、Amazon RDS で商用データベースエンジン(Oracle Database, SQL Server)を用いる場合の最新情報についてご案内します。本セッションは以下の2部構成で開催されます。 「SQL Server のマネージドサービス Amazon RDS for SQL Server / Amazon RDS Custom for SQL Server」のセッションでは、Amazon RDS for SQL Server / Amazon RDS Cutom for SQL Serverの概要、利点、特徴、ライセンスモデルなどをご紹介いたします。 「Oracle Database のマネージドサービス Amazon RDS for Oracle / Amazon RDS Custom for Oracle」のセッションでは、Oracle Databaseにフォーカスし、Amazon RDS およびRDS Cutomをご紹介いたします。 AWSマネージドデータベースサービスに興味がある方は是非ご参加ください。 アジェンダ ※当日の進行により、時間割が若干変更となる場合がございます。 時間 プログラム 講師 14:00-14:30 SQL Server のマネージドサービス Amazon RDS for SQL Server / Amazon RDS Custom for SQL Server 北澤 英崇 14:30-15:00 Oracle Database のマネージドサービス Amazon RDS for Oracle / Amazon RDS Custom for Oracle 長久保 武 開催場所 当日は下記のZoomにアクセスし、Meeting IDを入力してウェビナーにご参加ください。 https://zoom.us/join Meeting ID: 86159868886 Passcode: 287376 講師プロフィール 北澤 英崇 データ事業本部 サービススペシャリストソリューション本部 シニアRDBMSスペシャリストソリューションアーキテクト 様々なデータベースの技術担当を経験。現在はデータベースを AWS 上に実装する際の技術支援全般を担当 長久保 武 データ事業本部 ポートフォリオスペシャリストソリューション本部 データベーススペシャリストソリューションアーキテクト 主にデジタルネイティブのお客様に対しデータベースに関する技術支援を担当 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 今回のアップデートで反響が大きかったものを取り上げると、 Amazon Bedrock を東京リージョンで提供開始しました。Amazon が提供する Amazon Titan や、主要な AI スタートアップ企業が提供する基盤モデル (Foundation Model) を API 経由で利用する機能をもつマネージドサービスです。また、Amazon Bedrock をどのように利用できるか学習できる 日本語ワークショップ があります。テキスト生成、文章要約、質問の回答、チャットボット、画像生成、コード生成といった方法を学習できます。ぜひご利用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年10月2日週の主要なアップデート 10/2(月) Amazon IVS introduces in-console broadcasting for low-latency streaming ライブ配信を提供する Amazon IVS の低レイテンシーストリーミング機能で、マネージメントコンソール内からブラウザを通じてライブ配信ができるようになりました。アップデート以前は、ライブ配信を行うために Amazon IVS のブロードキャスト SDK や、OBS といったライブ配信ソフトウェアを利用できました。今回のアップデートで、Web ブラウザを利用してライブ配信を行う選択肢が増え、より簡単に始めやすくなりました。 Application Load Balancer and Network Load Balancer now support registering instances addressed by IPv6 as targets Application Load Balancer や Network Load Balancer に紐づけるターゲットグループで、IPv6 を持つインスタンスを登録できるようになりました。アップデート以前は、インスタンスが持つ IPv6 アドレスを、ターゲットグループに「IP アドレス」として登録する必要がありました。今回のアップデートで、「インスタンス」として登録が出来るようになり、より簡易に設定ができるようになりました。また、この機能にあわせて、EC2 のオートスケーリンググループで IPv6 を持つインスタンスが増減した際に、自動的にターゲットグループに反映できるようになりました。 Amazon EC2 Hibernate now supports more operating systems Amazon EC2 の休止機能 (Hibernate) で、新たに Microsoft Windows Server 2022、Red Hat Enterprise Linux 9、Amazon Linux 2023 をサポートしました。休止機能は、稼働している EC2 インスタンスを一時停止することで、コスト最適化やインスタンス起動時間の短縮といったメリットがある機能です。休止を実行すると、EC2 インスタンス内で稼働しているプロセスがフリーズされ、RAM の内容が EBS ルートボリュームに保存されます。その後、通常のシャットダウンが実行されます。休止期間中、EBS の料金は継続して発生しますが、インスタンス部分の料金を削減できるためコスト最適化のメリットがあります。再開を実行すると、EBS ルートボリュームから RAM の情報を復元して、プロセスのフリーズが解除されます。サポートしている AMI は、AWS ドキュメントに Linux  、  Windows で各ページに記載されています。 10/3(火) Amazon ECR Public introduces new navigation and search features to the ECR Public Gallery Amazon ECR Public Gallery でコンテナイメージを探しやすくなるアップデートがありました。コンテナイメージを検索する際に、イメージ作成元をフィルター条件として指定できるようになり、「Docker」や「Amazon」が作成したコンテナイメージを探しやすくなりました。また、 Amazon ECR Public Gallery のランディングページ に、頻繁に使用されているリポジトリが掲載されるようになり、簡単にアクセスできるようになりました。 Amazon EventBridge announces support for wildcard filters in rules Amazon EventBridge でルールを指定する際にワイルドカードサポートしました。例えば、S3 バケットへアップロードしたファイルの内、特定の条件に当てはまるファイルを対象に、何らかの処理を実施したいとします。ルールを指定する際に「dir/*.png」と設定すると、特定のディレクトリ配下の .png 拡張子を持つファイルを対象にできるようになりました。また、「*specificname*」と指定すると、特定の文字列を含むファイルを対象にできます。詳細は こちらのドキュメント をご参照ください。 Lambda test events are now available in AWS SAM CLI AWS SAM CLI で Lambda 関数を開発する際に、Lambda テストイベントを利用できるようになりました。Lambda テストイベントは、Lambda 関数を呼び出す際の引数を JSON オブジェクトとして保存し、Lambda 関数の動作検証を支援する機能です。不具合を素早く発見することに繋がり、開発スピードの向上といったメリットがあります。複数の開発者間で JSON オブジェクトを共有できるため、チーム全体の一貫した検証に利用できます。アップデート前は、AWS マネジメントコンソール上でサポートされていましたが、今回のアップデートで AWS SAM CLI で利用できるようになりました。 10/4(水) Amazon DataZone is now generally available Amazon DataZone の一般提供を開始しました。DataZone のビジネスデータカタログは、各組織が持つデータを見つけやすくするポータル画面を提供します。社内に存在するデータを発見し、そのデータが持つビジネス上の意味を説明する仕組みがあります。部門をまたがったチームでプロジェクトを作り、部門の壁をこえたコラボレーションと、セルフサービス方式で Athena や Redshift にアクセスする機能を提供し、社内のデータ活用を促進します。東京リージョンを含めて、11 リージョンで一般提供が開始されました。 Amazon EKS Extended support for Kubernetes Versions now available in preview Amazon EKS で延長サポートがプレビュー公開となりました。従来通り、EKS のマイナーバージョンが提供されてから 14 カ月間は標準サポートの対象となります。今回のアップデートで、各マイナーバージョンに対して、最大 12 カ月のサポート延長が追加され、合計 26 カ月のサポートが提供されるようになりました。延長サポートの期間、Amazon EKS のコントロールプレーンのセキュリティパッチを提供します。また、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、EKS Optimized AMI、および EKS Fargateノード用の重要なパッチをリリースする予定です。標準サポートの 14 カ月が終了すると、そのバージョンで稼働しているクラスターは自動的に延長サポートに入ります。設定変更やリクエストは必要ありません。プレビュー期間中は追加料金無しで利用できますが、一般提供開始後は追加料金が発生する予定です。詳細は こちらのブログ をご確認ください。 10/5(木) Amazon SageMaker Canvas expands its support for ready-to-use models to include foundation models (FMs) Amazon SageMaker Canvas で基盤モデル (Foundation Models) を利用できるようになりました。Claude 2, Amazon Titan, Jurassic-2 (Amazon Bedrock で提供) などの基盤モデルを、Canvas で提供する Web 画面で簡単にアクセスが出来るようになりました。同時に 3 種類の基盤モデルが生成したテキストを横に並べて表示する機能があり、最適な回答を比較しながら選択できます。 また、 Canvas と IAM Identity Center を連携 することで SAML 2.0 認証が利用できるようになり、AWS マネージメントコンソールを介さずにアクセス提供が可能です。組織内に展開する際に、各従業員に AWS マネージメントコンソールへの権限付与をしたくない場合にご利用いただけます。 Amazon WorkSpaces Services expand Microsoft productivity apps offerings Amazon WorkSpaces と WorkSpaces Core で、Microsoft Office、Microsoft Project、Microsoft Visio といったアプリケーションの追加・削除を、データを保持したまま利用可能になりました。アップデート以前は、Microsoft Office などのアプリケーションが含まれた「バンドル」として提供されていたため、後から利用したい際には WorkSpaces のマイグレート処理が必要でした。マイグレートは、ルートボリューム (C ドライブ) のデータが削除される仕様で、データ退避の考慮などが必要でした。今回のアップデートで、既存の WorkSpaces にデータを保持しながらアプリケーションの追加や削除が可能になりました。 AWS App Runner launches improvements for using custom domains AWS App Runner でカスタムドメインを利用するとき、DNS レコードを Route 53 上で設定する操作が簡易になりました。アップデート以前では、App Runner でカスタムドメインを利用する際に、App Runner 側で指定される A レコードや CNAME レコードなどを手動で設定する必要がありました。今回のアップデートで、Route 53 を利用している場合、自動的に App Runner 側でレコードの追加、および検証を実施してくれる機能が追加されました。手動で設定が必要だった部分が、自動化にされたアップデートです。 10/6(金) Amazon Bedrock now available in Asia Pacific (Tokyo) AWS Region Amazon Bedrock が東京リージョンでサポートされました。Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要 AI 企業が提供する高性能な基盤モデルを単一のAPIで実行できるフルマネージドサービスです。API 経由で利用できるため、アプリケーションに組み込むことが出来ます。また、ファインチューニングや RAG などのテクニックを使って、お手元のデータを Bedrock に適用できます。この記事の冒頭でご紹介した 日本語ワークショップ も合わせてご活用ください。 Amazon QuickSight announces predictive analytics using Amazon SageMaker Canvas Amazon QuickSight は Amazon SageMaker Canvas で作成した予測モデルと連携機能をサポートしました。SageMaker Canvas は機械学習に関するコードを実装することなく、ノーコードで利用できる機械学習サービスです。QuickSight で作成した表テーブル、もしくはピボットテーブルのデータを、QuickSight から SageMaker Canvas にエクスポートできます。その後、SageMaker Canvas で作成した予測モデルを利用して QuickSight 上で予測結果を表示できます。詳細は こちらのドキュメント をご参照ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

※本記事に記載の内容は2023年10月10日の内容に基づいたものです。今後、サービスの更新や変更に伴い、本記事の内容と異なる部分が出てくる可能性がある点、予めご了承ください。 こんにちは！テクニカルトレーナーの室橋です。2023 年もいよいよ 10 月。学びの秋ですね。さて皆様、AWS クラウドの学習を、ゲームベースで行うことができる学習コンテンツの「 AWS Cloud Quest 」をご存じでしょうか？ ゲーム内で、ストーリーに沿って出題されるソリューション構築に関する課題を、実際のAWSのアカウントを使用しながら解いていく、RPGテイストのコンテンツ です。 AWS の学習を進めていく際に 懸念点になりがちなのが「自分のAWS アカウント作成するのはちょっと面倒かも」「リソース作成するとお金かかりそうだし、無料で勉強できないのかな？」「そもそも、何から勉強していったらいいかわからない」といったところ かもしれません。今回本ブログ記事でご案内していく「 AWS Cloud Quest 」で、そんな皆さんの学習に関する懸念を払い飛ばせるかもしれません！ 時間の無い方向けに、要点のみを先に挙げておきます。 「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」は 無料でプレイいただけます 。 今回日本語化された 「クラウドプラクティショナーロール」では 12 の課題、 9 つのサービスが学習可能 です。 実際の AWS アカウントを操作しながら AWS のサービスについて学習することが出来ます。 ゲーム内の課題毎に、 課題専用の AWS アカウントが払い出されます。自分の AWS アカウントは不要です。 ロールをすべてクリアすると、デジタルバッジがもらえます。 ではでは、ここから細かくご紹介していきましょう！ 「AWS Cloud Quest」とは？ 「 AWS Cloud Quest 」では、「クラウドプラクティショナー」「ソリューションアーキテクト」「サーバーレスデベロッパー」「機械学習」「セキュリティ」「データ分析」「ネットワーク」の7つのロール（学習カテゴリ）を英語版でご提供させていただいておりましたが、 2023 年 10 月 2 日より「クラウドプラクティショナー」ロールを日本語でご利用いただけるようになりました（他ロールは現在英語のみでのご提供となります） 。 「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」では、実際の AWS アカウントの環境を使用しながら、基本的なクラウドソリューションを構築していきます。 ストーリーベースで AWS クラウドの概念、セキュリティ概念、一般的なユースケース、請求モデルと価格モデル、ビジネスへの影響等について学習することが可能 です。それぞれの課題毎に「学習」「計画」「実践」「DIY」のフェーズが用意されているので、「学習」「計画」フェーズでサービスや構築するソリューションの内容を身に着けてから、「実践」フェーズを使用して、実際の AWS アカウントでソリューション構築を行い、「DIY」フェーズで「実際に内容が身についたかどうか」のチェックをしながら、AWS の学習を行っていきましょう。「クラウドプラクティショナー」ロールでは、 12 の課題 を解きながら 9 つのサービス （Amazon S3, Amazon EC2, AWS Pricing Calculator, Amazon VPC, Amazon DynamoDB, Amazon Relational Database Service, AWS Identity and Access Management, Amazon Elastic File System, Elastic Load Balancing）を、実際の環境を触りながら身に着けていくことができます！ AWS Cloud Quest では、 それぞれの課題毎に専用の AWS アカウントが用意されるので、ご自身で AWS アカウントを準備したり、使用したリソースの料金や後処理を気にする必要はありません 。ソフトウェアのインストールなどは不要で、Skill Builder の画面からコンテンツを開始いただけます。また、「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」は、 Skill Builder にご登録いただければ、無料でご利用いただくことが出来ます（他ロールのご利用にはSkill Builderのサブスクリプション登録が必要です）。 AWS Cloud Quest は、ロール毎、課題毎に、様々なサービスを利用しながらソリューションを構築していくため、 「AWS の、どのサービスから学習を始めればよいかわからない」と言われる初学者の方にもおすすめのコンテンツ となっております。クラウドプラクティショナーロールについては、最初の方はそれぞれのサービスを単体に近い形で使用した課題が出題されますが、ロール後半になるにつれて、複数のサービスを組み合わせた、やや応用的な課題も登場します。 また、ロール内のすべての課題をクリアすることによって、デジタルバッジを獲得することも可能です。実際のアカウントで、手を動かしながら学習をしたという、ひとつの目安としてもご利用いただけるのではないでしょうか。是非皆様の AWS 学習にお役立てください。 また、まだ日本語版はリリースされておりませんが、ソリューションアーキテクトロールをプレイした内容を こちらのブログ でご紹介しておりますので、クラウドプラクティショナーロールよりも一歩進んだ学習をされたい方は、あわせてご確認ください。 今回、このブログの中では文章ベースでのご案内でしたが、AWS Cloud Quest については、こちらに 5分程度の紹介用動画 もありますので、内容を手早く知りたい方は是非ご確認ください（こちらの動画は 8 月に公開した内容のため、「英語版のみでのご提供」という表現がありますが、クラウドプラクティショナーロールは上記の通り日本語化されております）。 まずは AWS Skill Builder に登録してみましょう！ 「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」は「 AWS Skill Builder 」に登録いただくことにより、無料でご利用いただくことが可能です。Skill Builder への登録は無料で行うことができます。また、 有償サブスクリプションプランに申し込んでいただく と、AWS Cloud Quest の異なるロールにチャレンジしたり、AWS 認定の公式模擬試験を解いたりすることができるようになります。学習するのにも丁度良い学びの秋に、AWS クラウドの学習を始めてみるのはいかがでしょうか？ 今後とも AWS のトレーニングをよろしくお願いいたします。

Amazon QuickSight はフルマネージドなクラウドネイティブ business intelligence (BI) サービスです。QuickSight のインターフェイス内でも、software as a service (SaaS) アプリケーションやウェブポータルに埋め込まれていても、データへの接続やインタラクティブなダッシュボードの作成、数万人のユーザーとのデータ、ダッシュボードの共有を簡単に行うことができます。QuickSight が組織全体の日々の意思決定に役立つインサイトを提供することで、エンドユーザーは、選択したアプリケーションの日常的なワークフローにシームレスに流入できる実用的なインサイトを期待しています。これにより、複数のプラットフォーム間でコンテキストを切り替えることなく、データドリブンな意思決定を行い、その決定に基づいてアクションを実行できるようになります。 QuickSight が埋め込みコールバックアクションのサポートを開始したことで、QuickSight のダッシュボード、ビジュアルを埋め込むお客様は、 Embedding SDK の新機能を使用して、リーダー (閲覧者) 向けの次のようなユースケース (これらに限りません) を利用できるようになりました。 レコードへの後続の処理に用いるフラグの付与 ステークホルダーに対する重要なインサイトに関する通知の送信 書き戻しによる即時データ更新 ユーザーの操作を追跡し、設計や選択を改善する 本記事では、埋め込みコールバックアクションを使用して、アプリケーションと QuickSight の埋め込みダッシュボードおよびビジュアルとの間にシームレスなインタラクションを構築する方法を示します。 ソリューションの概要 埋め込みコールバックアクションにより、開発者はアプリケーションと QuickSight の埋め込みダッシュボードやビジュアルをより緊密に統合できます。まず、開発者は Embedding SDK の新しい関数を使用して 1 つ以上のビジュアルの上にデータポイントコールバックを登録することで、ビジュアル上でのエンドユーザーのインタラクティビティを監視するコードをアプリケーションに記述できるようになりました。登録後、リーダーが円グラフの特定のスライスや棒グラフの棒などのデータポイントをクリックすると、そのデータポイントに関連するデータの行がサードパーティーのアプリケーションに送信されます。その後、このデータをキャプチャ、処理、修正したり、アプリケーションの別の部分に渡したりすることができます。 機能の一部として追加された新しい SDK アクションとイベントは以下の通りです。これらの新しいアクションとイベントにより、アプリケーション開発者はこれらのアクション関数のいずれかを呼び出して、ダッシュボードビジュアル上のアクションを一覧表示、取得、追加、または削除できます。その後、これらのアクションが登録されると、イベントコールバックを使用して、ピボットテーブルのセル、棒グラフの棒、円グラフのスライスをクリックするなどのユーザー操作をイベントとして受信し、それらのデータポイントをキャプチャし、適切なワークフローを呼び出してこれらのデータポイントをさらに処理します。 新しい SDK アクションは次の通りです。 getSheetVisuals — 指定されたシートのビジュアルのリストを返す getVisualActions, getActions — ダッシュボード上のビジュアルのアクションのリストを返す addVisualActions, addActions — ダッシュボード上のビジュアル用の既存のアクションリストにアクションを追加する removeVisualActions, removeActions — ダッシュボードのビジュアルからアクションを削除する setVisualActions, setActions — ダッシュボード上のビジュアル用に既存のアクションを新しいアクションリストでオーバーライドする 新しい SDK イベントは次の通りです。 GET_VISUAL_ACTIONS — GetVisualAction を呼び出したときにレスポンスを受信した後に発行され、ビジュアルのカスタムアクションのリストが含まれます。 ADD_VISUAL_ACTIONS — AddVisualAction を呼び出したときにレスポンスを受信した後に発行され、ビジュアルにカスタムアクションを追加する際の成功またはエラーが含まれます。 CALLBACK_OPERATION_INVOKED — CallbackOperation によるカスタムアクションを含むビジュアルデータポイントをクリックすると表示されます。これには、データポイントとその他のイベント情報が含まれます。 これらのアクションはすべて、Set, Get, Add, Remove という形式の CRUD 操作をサポートします。これは、既存のアクションを使用したり、新しいアクションを作成したり、埋め込みダッシュボードで有効にしたくないアクションを削除したりする場合に役立ちます。 前提条件 本記事の内容は、以下の前提条件を満たす必要があります。 Enterprise Edition の QuickSight サブスクリプション QuickSight Embedding SDK の最新バージョン ユースケースの概要 架空の会社、AnyCompany を考えてみましょう。AnyCompany は、倉庫を管理し、業務効率を最適化できる倉庫管理システムを提供する大手フルフィルメントテクノロジー企業です。QuickSight と その埋め込み機能を使用して、データドリブンな体験をソフトウェアアプリケーションにシームレスに統合しています。これらの埋め込み機能は、QuickSight の機能をエンドユーザーにもたらし、アプリケーション上でデータを分析して操作できます。現在、AnyCompany はエンドユーザー向けにダッシュボード埋め込みを使用しており、QuickSight ダッシュボード内からのユーザーアクションとイベントに基づいてワークフローをトリガーしたいと考えています。 AnyCompany には、さまざまなワークフローに関する次の重要な要件があります。 Email – AnyCompany は、在庫管理、注文処理、出荷追跡などのさまざまなマイルストーン (データポイント) についてエンドカスタマーに最新の情報を提供するために、ダッシュボードから email をトリガーするレコードにフラグを付けたいと考えています。 書き戻し — AnyCompany は、エンドユーザーが出荷、在庫、注文処理ステータスを埋め込みダッシュボードからデータベースに更新できるメカニズムをシームレスに提供したいと考えています。 使用状況分析 — AnyCompany は、倉庫のユーザーによるクリック分析に関するインサイトを導き出し、ユーザーベースの採用率とエンゲージメントを測定して継続的な改善を図り、使用パターンに基づいて体験を向上させたいと考えています。 以下のセクションでは、各ワークフローについて詳しく説明します。 Email ワークフロー 次の図は、QuickSight Embedding SDK の新しいイベントとアクション機能を使用して email ワークフローのレコードにフラグを付ける一連の手順を示しています。 ユーザーは、埋め込みアプリケーション内からダッシュボードにアクセスします。QuickSight Embedding SDK を使用してダッシュボードを埋め込む際に、アプリケーション開発者は SetVisualActions または SetActions を使用してビジュアルにアクションを登録し、エンドユーザーからのクリックイベントを監視します。エンドユーザーがダッシュボード内のビジュアルを操作すると (例えば、‘ Flag record ’という名前のカスタムアクションを使用して)、これらのイベントは親のアプリケーションに送信され、 CALLBACK_OPERATION_INVOKED を使用してこれらのイベントを監視することでデータポイントをキャプチャできます。この生成されたイベントのレスポンスには、すべてのイベント情報と、ユーザーがクリックしたデータポイントが含まれます。アプリケーション開発者は、発生したイベントの詳細を使用して email ワークフローをトリガーし、適切な UI を表示して email テンプレートをさらにカスタマイズできます。以下のスクリーンショットとコードスニペットは、メールワークフローで可能性を示しています。 次のコードスニペットは、アプリケーション開発者がダッシュボードをウェブアプリケーションに埋め込む際にアクションを動的に有効にする方法を示しています。この例では、テーブルビジュアルで ‘ Flag Record ’ アクションが有効になっています。 onMessage: async (messageEvent) => { const {eventName, message} = messageEvent; switch (eventName) { case 'CONTENT_LOADED': await visualFrame.addActions([ CustomActionId: 'flag-record-action', Name: 'Flag record', Trigger: 'DATA_POINT_MENU', Status: 'ENABLED', ActionOperations: [{ CallbackOperation: { EmbeddingMessage: {} } }] ]); 上記のコードを使用してビジュアル上でアクションを有効にした後、ユーザーがレコードを操作し始めると、次のスクリーンショットに示すように、レコードのメニューオプションに新しく追加された “Flag record” オプションが表示されます。 ユーザーが flag record をトリガーすると、次のコードスニペットに示すように、QuickSight Embedding SDK を介してイベントを処理できます。 case 'CALLBACK_OPERATION_INVOKED': const { Datapoints: [Datapoint], VisualId } = message; const aggregatedData = Datapoint.Columns.reduce((aggregatedRawData, column, index)=> { const columnType = Object.keys(column)[0]; if (columnType) { const valueType = Object.keys(column?.[columnType])[0]; if (valueType) { const columnMetadata = column[columnType][valueType]?.Column; const rawValue = Datapoint.RawValues[index][valueType]; const formattedValue = Datapoint.FormattedValues[index]; return { ...aggregatedRawData, [columnMetadata.ColumnName]: rawValue } } } return aggregatedRawData; }, {}); // Send data to backend server to send email await fetch('<REPLACE_WITH_BACKEND_SERVER_ENDPOINT>', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ data: aggregatedRawData }) }); 返されたデータに基づいて、次のスクリーンショットに示すように、レスポンスをさらに処理して email フローをトリガーできます。 書き戻しワークフロー 次の図は、QuickSight Embedding SDK の新しいイベントおよびアクション機能による書き戻しワークフローの一連のステップを示しています。 これは先程の例とまったく同じように機能しますが、email ワークフローをトリガーする代わりに、データを直接処理してデータベースに書き込むことができます。 コードスニペットは次の通りです。 onMessage: async (messageEvent) => { const {eventName, message} = messageEvent; switch (eventName) { case 'CONTENT_LOADED': await visualFrame.addActions([ CustomActionId: 'write-back-action', Name: 'write to database', Trigger: 'DATA_POINT_MENU', Status: 'ENABLED', ActionOperations: [{ CallbackOperation: { EmbeddingMessage: {} } }] ]); break; case 'CALLBACK_OPERATION_INVOKED': const { Datapoints: [Datapoint], VisualId } = message; const aggregatedData = Datapoint.Columns.reduce((aggregatedRawData, column, index) => { const columnType = Object.keys(column)[0]; if (columnType) { const valueType = Object.keys(column?.[columnType])[0]; if (valueType) { const columnMetadata = column[columnType][valueType]?.Column; const rawValue = Datapoint.RawValues[index][valueType]; const formattedValue = Datapoint.FormattedValues[index]; return { ...aggregatedRawData, [columnMetadata.ColumnName]: rawValue } } } return aggregatedRawData; }, {}); // Send data to backend server to write to database await fetch('<REPLACE_WITH_API_ENDPOINT>', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ data: aggregatedRawData }) }); break; default: console.warn(`Unhandled event: ${eventName}`); break; } } } 使用状況分析ワークフロー 次の図は、QuickSight Embedding SDK の新しいイベントとアクション機能を使用して使用状況分析を取得する一連の手順を示しています。 このワークフローでは、ユーザーによるビジュアル操作をすべてクリックベースで有効にし、すべてのデータポイントをユーザー ID、役割、部署などとともにデータベースに書き込むことができます。このデータをさらに分析して、エンドユーザーの採用とエンゲージメントに関するインサイトを得ることができます。さらに、このデータを使用してダッシュボードを改善したり、組織内でキャンペーンを実施したりして、認知度を高め、採用率を高めることができます。例えば、特定の部門が棒グラフを操作していて、ダッシュボードを読み込むたびに 2 つのレイヤーをドリルダウンしている場合、それらのメトリクスをトップレベルに表示することで、その部門のダッシュボードの表示を改善できます。 まとめ 埋め込みコールバックアクションは、特定のビジュアル操作をサブスクライブし、埋め込みダッシュボードでエンドユーザーによってトリガーされたイベントを監視するための方法を提供します。この投稿では、これらのアクションとイベントの応用例のさまざまなユースケースを説明しました。詳細については、「 Amazon QuickSight が埋め込みコールバックアクションのサポートを開始 」と「 Amazon QuickSight でランタイムに埋め込みコールバックアクションを追加する 」を参照してください。 ご質問やフィードバックがございましたら、コメントをお寄せください。その他のディスカッションや質問への回答を得るためのヘルプについては、 QuickSight コミュニティ をチェックしてください。 翻訳はソリューションアーキテクトの高橋が担当しました。原文は こちら です。 著者について Mayank Agarwal は、AWS のクラウドネイティブなフルマネージド BI サービスである Amazon QuickSight のプロダクトマネージャーです。彼は埋め込み分析と開発者体験に焦点を当てています。彼はハンドヘルドデバイスを開発する組み込みソフトウェアエンジニアとしてキャリアをスタートさせました。QuickSight に従事する前は、Credence ID でエンジニアリングチームを率い、AWS のサービスを使用してカスタムのモバイル組み込みデバイスとウェブソリューションを開発していました。これにより、政府部門、医療、取引のセキュリティアプリケーション向けに、生体認証の登録と識別を迅速、直感的、かつ費用対効果の高い方法で行うことができます。 Srikanth Baheti は Amazon QuickSight のスペシャライズドワールドワイドプリンシパルソリューションアーキテクトです。彼はコンサルタントとしてキャリアをスタートし、複数の民間および政府機関で働いていました。その後、PerkinElmer Health and Sciences & eResearch Technology Inc. に勤務し、トラフィックの多いウェブアプリケーション、AWS サービスとサーバーレスコンピューティングを使用するレポートプラットフォーム用の拡張性と保守性の高いデータパイプラインの設計と開発を担当しました。 Raji Sivasubramaniam は AWS のシニアソリューションアーキテクトで、Analytics 分野にフォーカスしています。Raji は、世界中の Fortune 500 および Fortune 100 企業向けの end-to-end のエンタープライズデータ管理、ビジネスインテリジェンス、分析ソリューションの設計を専門としています。彼女は、マネージドマーケット、医師ターゲティング、患者分析など、さまざまなヘルスケアデータセットを使った統合ヘルスケアデータと分析に豊富な経験があります。

2023 年 10 月 6 日現在、今回ご紹介する機能は、英語が標準言語となっております。 Amazon QuickSight のお客様は、 Amazon QuickSight Q の自然言語インターフェイスを使用して、ビジュアルの作成、計算の構築、およびビジュアルの改良を行う Generative Business Intelligence (BI) 機能をプレビューでお試し頂けるようになりました。たとえば、Q に “show me count of orders in 2023 by city as a map” (2023 年の都市別注文数を地図上に表示して) と尋ねると、すぐに 2023 年でフィルタリングされたフィールドの注文数が地図上で地理的に視覚化されます。QuickSight 計算エディタで “sales year over year” (前年比売上) と入力すると、すぐに正しい計算関数と売上のデータフィールドを含む QuickSight 表現が作成されます。また、 “change to table, add discount, and highlight discount > 10% blue” (テーブルを変更、割引を追加、割引が 10% 以上の場合青色で強調表示)というコマンドを使用して可視化を調整すると、可視化結果はテーブルに変換され、割引のためのフィールドが追加され、割引が 10% を超える値に条件付き書式が適用されます。これらの Generative BI 機能はダッシュボードの構築を加速し、QuickSight 作成者の時間を節約します。 これらの新機能は、 2023 AWS New York Summit で発表 された Generative BI 機能の第一弾です。これらは Q の自然言語クエリに関する AI イノベーションを基盤としており、2020 年以来ビジネスユーザーが SQL クエリを作成したり BI ツールを学んだりすることなくデータに対して質問することを可能にしてきました。QuickSight の Generative BI は、 Amazon Bedrock の大規模言語モデル (LLM) を利用しており、AWS 環境内でデータを安全に保持できます。 QuickSight Q でビジュアルを数秒で構築 ビジネスアナリストがより迅速にデータを分析してダッシュボードを構築できるよう、我々は Q の自然言語機能を調整しました。望まれる結果をほんの数単語で表現し、ビジュアルを作成することに注力しました。これによりビジネスアナリストは、どのフィールドを選択するか、どのフィルターを追加するか、どのビジュアルタイプを選択するかについて考える必要なく、目の前のタスク（例えば、2023年の売上を月単位で視覚化する）に集中することができます。BI での手動のポイントアンドクリックの手順は自然言語クエリに置き換えられ、不要となりました。 ダッシュボード作成インターフェース上での新しい Ask Q to build a visual では、アナリストはデータフィールド、データ値、使用するフィルター、実行する操作、使用するビジュアルタイプを質問することができます。 たとえば、“show me count of orders in 2023 by city as a map” (2023年の注文数を都市別に地図で表示して) という質問に対して、Q はフィルタされたマップをすぐに作成します。”sales of contactmatcher vs alchemy by month“ (コンタクトマッチャーとアルケミーの月別の売上を比較して) と質問された際は コンタクトマッチャー と アルケミー という製品を比較する折れ線グラフを作成し、“forecast sales of contactmatcher by month.” (コンタクトマッチャーの売上を月ごとに予測して) と質問された場合は予測を作成します。 また新しいビジュアル作成インターフェイスでは、ビジネスアナリストが他にどのような質問ができるかを確認できるように、質問のサンプルを提案する機能や、特定のデータ値を見つけるために役立つ先行入力の機能も用意されています。ビジネスアナリストを支援するため、Q は “top products” (トップ製品) などの漠然とした質問に対して最も適切と考えられる視覚化で回答し、質問をどのように解釈したかを説明します。例えば、Q は “top products” (トップ製品) を “total sales by product” (製品別の総売上高) と解釈し、作成者の質問に対して複数のデータが一致する可能性がある場合は、 Did you mean … セクションに代替の質問を表示します。Q は、QuickSight で設定された行レベルのセキュリティルールを尊重しながら、作成者がデータ中の特定の値やフィールド名を発見、選択できるようにするため、オートコンプリート機能も活用します。 ビジネスアナリストは Add to Analysis オプションを使用して、作成中のダッシュボードにビジュアルを追加する前にビジュアルタイプの変更やビジュアルへの予測の追加を容易に行えます。 複雑な計算を簡単に構築 ほとんどのビジネスアナリストにとって、計算は BI トレーニングの中で最も複雑で困難な作業であり、数か月から数年の経験を必要とします。ビジネスアナリストは QuickSight の新しい Generative BI 計算エディタを使用し、簡単な英語で求める結果を記述することで QuickSight 表現を構築し、複雑な計算を数秒で実行することができます。 計算エディタのインターフェイスの新しい Build for me オプションでは、計算に追加するデータフィールドが自動的に選択され、すぐに使用可能な表現が生成されます。例えば、“rolling 7 day average order count” (注文数の 7 日間移動平均) というプロンプトでは、windowAvg(count({Order ID}),[{Order Date} DESC],7,0,[]) という 計算フィールド を作成できます。自然言語から計算を生成することで、ビジネスアナリストは参考資料を調べたり、同僚に尋ねたり、あるいは単に試行錯誤に費やしたりする時間と労力を節約できます。 即座にビジュアルを改良し整える 説得力のあるダッシュボードの作成のためには、多くの場合、ビジネスアナリストチームが何時間もかけてビジュアルの調整と改良を行い、多くのポイントアンドクリックの手順でビジュアルのプロパティを変更し、組織に適する表示形式を実現する必要があります。QuickSight の Generative BI 機能により、ビジネスアナリストは自然言語のプロンプトを使用してビジュアルをカスタマイズし、特定の表示形式を実現できるようになりました。ビジュアルのカスタマイズは Build for me のプロンプトで指定することができ、さらに多くのビジュアルの編集作業を迅速に完了するために、1 つのプロンプトに複数のカスタマイズを含めることも可能です。 今回のプレビュー中は以下のカスタマイズがサポートされ、一般公開時にはさらに多くのカスタマイズがサポートされます。 ビジュアルタイプの変更 (例) “change to bar chart” (棒グラフに変更) 軸名やテーブル列名の変更 (例) “rename Y axis to Account Manager” (Y 軸の名前をアカウントマネージャーに変更) データズームの表示または非表示 (例) “show data zoom”(データズームを表示) ビジュアルまたは特定のフィールドウェルへのフィールドの追加 (例) “add profit” (利益の追加) ビジュアルのソート方法を変更 (例) “sort by sales descending” (売上の降順でソート) 条件付きフォーマットを適用 (例) “make profits < 0 red” (利益が 0 未満である場合に赤にする) 使用可能なカスタマイズオプションの一覧については、 ドキュメント を参照してください。サポートされる機能が増えた場合にはこちらの一覧が更新されます。 あなたのデータは、あなたの手元で、あなたの管理下に Generative BI 機能は特別なタグ付けやトレーニングなしに自動的に言語を理解し、あらゆるデータを処理します。また、ビジネスや組織のコンテキストを追加することで、Q のデフォルトの振る舞いを変更し、Q が特定の単語をどのように解釈するかを制御することができます。たとえば、同義語として他の名前をフィールドにマッピングしたり、“who” (誰が) 、“where” (どこに)、“how many” (何人で) などといった漠然とした質問に答える際の最適なフィールドを選択したりすることが可能です。QuickSight と Amazon Bedrock で使用されるお客様のデータは、サービスの向上には使用されず、サードパーティのモデルプロバイダーと共有されることもなく、転送中および保存中は暗号化されます。 QuickSight の Generative BI 機能を体験する 今回のプレビューは、US East (N. Virginia) および US West (Oregon) リージョンの Q アドオンを使用するすべての QuickSight アカウントでご利用可能です。 もし現在 Q をご利用でない場合は、無料トライアルから 開始 することができます。このプレビューを有効にするための手順は、QuickSight の作成者が QuickSight のプレビューマネージャーから Generative BI for QuickSight Authors オプションを選択することのみです。 AWS では現在、Amazon Bedrock の基本的な使用を含む、これらのプレビュー機能の使用に対しての課金は行われておりませんが、お客様が使用するその他の AWS サービスで発生する料金はお客様の負担となります。これらの AWS サービスの使用には標準の料金が適用されます。 翻訳はソリューションアーキテクトの守田が担当しました。原文は こちら です。 著者について Zac Woodall は、Amazon QuickSight の AIML 担当プリンシパルプロダクトマネージャーです。彼は Amazon QuickSight の AIML 機能のプロダクトリーダーとして、AI を改善して製品の簡素化を容易にし、データによりアクセスしやすくしています。彼は、AWS に入社する前は、スタートアップ、Tableau、Microsoft に勤務し、世界で最も使用されているエンタープライズソフトウェアやコンシューマー向けソフトウェアを 24 年間開発してきました。 Jose Kunnackal は、AWS のクラウドネイティブなフルマネージド BI サービスである Amazon QuickSight の製品管理担当ディレクターです。彼は Motorolaでキャリアをスタートし、通信システムやファーストレスポンダーシステム向けのソフトウェアを開発しました。その後、Trilibis Mobile でエンジニアリングディレクターを務め、AWS サービスを使用して SaaS モバイルウェブプラットフォームを構築しました。彼は、クラウドテクノロジーの潜在力により顧客がデータを最大限に活用できる可能性に興奮しています。

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの守田です。 2023 年 9 月 28 日に「第三十四回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回は「Container 編」ということで、AWS ソリューションアーキテクトや実際に AWS のコンテナサービスをご利用いただいているお客様から事例やサービスの機能についてご紹介頂きました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 AWS ソリューションアーキテクトから AWS のコンテナサービスの運用の工夫についてデモを交えてお伝えし、ゲストスピーカーとして株式会社ラクスの下西 章王様、freee 株式会社の藤原 彰人様 から AWS のコンテナサービスを用いたサービス構築・運用の事例についてご紹介頂きました。合計 1 時間半の中で盛りだくさんの内容でお送りしました。 本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！ 当日参加したメンバー アジェンダ 今月のお勧め 5 分間アップデート (5 分) スピーカー : アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 長屋 和真 今月の AWS のサービスアップデートを 5 分でご紹介しました。多くのアップデートの中から以下の 4 つをピックアップしました。 Amazon CloudWatch Logs、フィルターパターン構文での正規表現のサポートを発表 Amazon SES E メール受信サービスが 7 つの新しいリージョンに拡大 API Gateway コンソールの更新のお知らせ AWS Identity and Access Management、直近にアクセスされたアクションに関する情報を 140 以上のサービスに提供 AWS の新着情報については 公式ページ のほか、毎週のアップデート情報をまとめて発信している　 週刊 AWS を合わせてご覧頂くことがオススメです！ AWS 上でコンテナを爆速起動する⽅法をまとめてみた (15 分) スピーカー : アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 祖父江 宏祐 本セッションでは、コンテナ起動時間に課題を抱えているお客様に向けて、いくつかのメソッドを提供したいと考えています。デモも用意しますので、ぜひご参加ください。 AWS でメール配信システムを構築！ Amazon ECS on AWS Fargate で楽楽運用 (15 分) スピーカー : 株式会社ラクス インフラ開発部 東京インフラ開発2課 アシスタントマネージャー 下西 章王 様 今の時代、友人と連絡を取り合う際は SNS が主流だと思いますが、ビジネスの世界ではメルマガや、取引先との連絡ツールとしてメールが使われています。メールは「送れば届く」と思われているのですが、実はそうではありません。 本セッションではメールの裏側では何が起こっていて、AWS サービスを利用し、どう解決したのか？に焦点を当ててお伝えいたします。 メールの裏側の仕組み、AWS でのコンテナ運用といったノウハウを少しでも提供できる時間にさせていただきたいと思います。 Amazon EKS と Argo Workflows で実現するタスク実行と AWS リソースとの連携方法 (15 分) スピーカー : freee 株式会社 SRE / Developer Experience エンジニア 藤原 彰人 様 freee では kubernetes ネイティブのワークフローエンジンである Argo Workflows を採用しています。 登壇内容としては下記の ・Argo Workflows を導入することになった背景 ・本番運用している Amazon EKS クラスターに対して、Argo Workflows 導入するために活用した [Amazon RDS へのタスク実行結果の保管] や [Amazon S3 へのアーティファクトの保管] などの機能やアーキテクチャについて ・タスク実行以外の Argo Workflows の活用方法 について お話させて頂きます。 Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう！(15 分) スピーカー : アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 プラットフォームエンジニアリングは、開発者体験や生産性を高めるためのプラットフォームをセルフサービスのプロダクトとして提供するという概念です。本セッションでは、Amazon EKS と KubeVela を用いて、プラットフォームエンジニアリングの世界にちょっぴり DiveDeep します。 当日の様子 当日の内容を抜粋してご紹介します。 ※ 録画は後日アップロードし、リンクを記載させて頂きます。 AWS上でコンテナを爆速起動する⽅法をまとめてみた [ 資料 ] 最初のセッションはソリューションアーキテクトの祖父江より、 3 つのコンテナ起動の高速化手法、①コンテナイメージサイズを小さくする ②イメージキャッシュを利用する ③遅延読み込みを利用する、をご紹介しました。上記の 3 つの手法は、コンテナの起動において特に時間のかかる処理である、「コンテナイメージの取得」の処理時間を短縮するものです。 今回は ③遅延読み込みを利用する にフォーカスし、 AWS Fargate (以降、Fargate) での Seekable OCI (以降、SOCI) を用いた遅延読み込みのデモを行いました。SOCI の詳しいご紹介は こちら をご覧ください。デモでは、SOCI インデクスの作成されたコンテナイメージを Fargate で起動し、起動時間が短縮されることが確認できました。コンテナの起動時間の長さで悩まれているお客様には必見の内容です。 AWS でメール配信システムを構築！ Amazon ECS on AWS Fargate で楽楽運用 [ 資料 ] 2 つ目のセッションでは、株式会社ラクスの下西 章王様より、メール配信システムの構築に Amazon ECS とFargate を採択した理由や実際の運用で良さを感じられている点についてお話しして頂きました。現在運用されているメール配信システム blastengine は、API 経由でメールを登録し、配信することで、高いメール到達率の実現を可能にするサービスです。Fargate の選定理由は、デプロイの手軽さ、可用性、Auto Scaling といった特徴により楽に運用を行うことができると考えられたためです。セッションでは、実際に上記 3 つの特徴をどのように活かされているかについてご紹介頂きました。リリース後のインフラ側の障害はゼロに抑えられており、運用者もお客様も安心して頂けるサービスとなっています。Fargate を用いてサービスの運用を楽にすることにご興味のあるお客様、是非こちらのセッションをご覧ください。 Amazon EKS と Argo Workflows で実現するタスク実行と AWS リソースとの連携方法 [ 資料 ] 3 つ目のセッションでは、freee 株式会社 藤原 彰人様より、Argo Workflows を用いて Amazon EKS (以降、EKS) のクラスターのジョブ実行を管理する方法についてご紹介頂きました。EKS のジョブ実行管理に際して、Pull Request をトリガーとして Circle CI から EKS クラスターに対してシェルスクリプトを実行するという以前の構成では、権限統制の難しさ、Circle CI に与える権限の強さ、ジョブ実行の履歴の管理の難しさといった課題がありました。この課題を、Kubernetes 上で実行されるワークフローエンジンである Argo Workflows でのジョブ実行管理を行うことで解決されました。本セッションでは特に Workflow Archive と Artifact Repository の 2 つの機能にフォーカスしてご説明頂きました。Workflow Archive はワークフローの実行結果のデータを永続化することを可能にし、 Artifact Repository はログデータの永続化を可能にします。それぞれの構成内容や設定項目について具体的にご説明頂いているため、Argo Workflows を用いたジョブ実行管理にご興味のある方は是非ご確認ください。 Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう！ [ 資料 ] 最後のセッションでは、ソリューションアーキテクトの後藤より、KubeVela を用いた EKS の運用の改善手法についてご紹介し、KubeVela を用いてアプリケーションをデプロイするデモを実施しました。EKS の運用のよくある問題として、Kubernetes の活用には専門知識が必要であることから、Kubernetes を管理するインフラチームの負荷が高くなってしまう点が挙げられます。この状況は、内部向けのプラットフォームとして独自の抽象化レイヤーを作成し、アプリケーション開発チームにとって十分な抽象化を提供することで改善することが可能です。抽象化レイヤーの作成には OAM (Open Application Model) という、プラットフォームを意識せずにアプリケーションを記述する仕様を用います。KubeVela は、Kubernetes で 上記の OAM を実装するための OSS です。本セッションでは KubeVela を用いて実現できる抽象化の具体例や、KubeVela を用いて開発するアプリケーションの構成要素についてご説明しています。デモでは kubectl apply コマンドでマニフェストを適用してクラスター内のリソースを作成する流れと、Web UI を用いて GUI でアプリケーションをデプロイする流れを行いました。これにより、KubeVela を利用することでアプリケーション開発チームが Kubernetes の各種リソースの設定についての詳細な知識なしにアプリケーションをデプロイが可能であることが確認できました。EKS を活用されており、認知負荷を削減されたいと考えるお客様にぜひご覧頂きたい内容です。 いただいたご質問とその回答 「AWS 上でコンテナを爆速起動する⽅法をまとめてみた」について Q. SOCI は　 AWS Graviton 　ベースの Fargate でも利用可能でしょうか？ A. 先日 ARM64 の CPU アーキテクチャにも対応したため、ご利用頂けます。 「Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう！」について Q. KubeVela の Definition を自分達で作成する場合には、どのような流れで作成することになるのでしょうか？ A. プラットフォームを管理するチームが CUE 言語を使って書くことになります。ただし、 KubeVela CLI を用いて既存の YAML ファイルから Definition を作成することが可能なので、CLI を用いて雛形を作成し、その後カスタムして頂くことで手順を簡略化できます。 「Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう！」について Q. ナレッジシェアの観点において KubeVela と Kubernetes どちらでも必要になると思いますが、KubeVela の方が簡易に学習可能ということでしょうか？ A. どちらの場合もナレッジシェアは必要になりますが、KubeVela をうまく活用することでナレッジシェアの量を減らすことができると考えております。例えば、Kubernetes のリソースの詳細についての理解が不要となります。 次回予告 次回は「Serverless 編」です。 ゲストスピーカーとして、株式会社ゼンリンデータコムの 新谷 亮人様、株式会社 Serverless Operations の 金 仙優 様、Ragate 株式会社の久保 翔太様、木村情報技術株式会社の徳山 鐘三様をお招きしまして、AWS でのサーバーレスな環境を構築・運用するための 4 のセッションをご提供します。 次回も多くの方々のご参加を心よりお待ちしております！ 『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みでは複数月分をまとめてご選択頂くことが可能です！また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 第三十五回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Serverless 編- 開催日時：2023 年 10 月 26 日（木）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 100 台のサーバー運用からの脱却を目指して：初めての AWS サーバレス環境構築の裏側 スピーカー： 株式会社ゼンリンデータコム プロダクト第一開発部、シニアエンジニア 新谷 亮人 氏 16:25 – 16:40 人気番組の新作配信を安定起動させた、サーバーレスな AWS 分散負荷試験ソリューション「Distributed Load Testing」を使った負荷試験の仕組み スピーカー： 株式会社 Serverless Operations COO 金 仙優 氏 16:40 – 16:45 Q&A 16:45 – 17:00 【RDB 開発者向け】Amazon DynamoDB 設計ベストプラクティス事例紹介 スピーカー：Ragate 株式会社 開発部、プロジェクトマネージャー 久保 翔太 氏 17:00 – 17:15 AWS マルチアカウント戦略を採用したサーバーレスアプリケーションの管理と運用 スピーカー： 木村情報技術株式会社 システム開発本部 第三開発部 徳山 鐘三 氏 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション このブログの著者 守田 凜々佳 ( Morita Ririka ) ソリューションアーキテクトとして ISV/SaaS 系のお客様の技術支援を行っております。好きなサービスは Amazon QuickSight です。週末はヴァイオリンを弾いて過ごしています。

こんにちは。ソリューションアーキテクトの加藤です。 パイオニア株式会社 (以下、パイオニア) は、「より多くの人と、感動を」 をミッションに掲げ、モノ×コト（プロダクト ＆ ソリューションサービス）の両輪で、新しい移動体験の価値を創造しています。本ブログでは、パイオニアが AWS を活用し、どのようにデータカタログサイトを実現したかについて、パイオニア Piomatix 情報サービス部 櫛引 翔太 氏よりご紹介します。 1. イントロダクション これまでパイオニアは、カーナビ、カーオーディオなどを中心としたハードウェア主体で新しい価値を提供してきました。今でもハードウェアがパイオニアの主力の事業であることは変わりませんが、カーナビやドライブレコーダーといった車載機器から走行速度や自車位置など様々なプローブ情報を収集しており、それら多くのデータから新たな価値を生み出すことにも注力し、徐々にサービスビジネスを拡大しています。 その一環として、2019 年より、収集したデータの分析や活用を進めるため、データを 1 か所に集約するデータレイクの構築を行いました。データレイクの構築により、データサイエンスによるデータ分析が効率化され、新価値の早期検証が可能になりました。一方で、データサイエンスにより分析したデータを他のサービスへ活用する際に、ガバナンスやコンプライアンスを保つためにデータの管理者へ連絡する仕組みがシステム化されてないことや、データを蓄積する際のデータコピーにコストや時間がかかってしまうという課題も見つかりました。 また、”モノ×コト” ビジネスを実現するために、収集したデータからドライバーの走行の状況を把握し、適切なタイミングで必要な情報やナビゲーションを提供する独自のモビリティ AI プラットフォーム「 Piomatix 」を開発しました。その成果の 1 つとして、AI搭載通信型オールインワン車載器「 NP1 」を 2022 年 3 月に発売しました。このように、パイオニアでは、今まで以上にデータ活用を推進しており、同社内のデータレイクが抱える課題への対応が急務になってきました。 これらの課題を解決するために、 AWS Lake Formation と Microsoft Teams の承認アプリを組み合わせて、データ仮想化を実現するデータカタログサイトを開発しました。ここでは、本開発において工夫した点、すなわち、AWS Lake Formation を利用した自動アクセス制御や Microsoft Teams アプリとの連携によるデータ登録 / 利用の承認フロー (以下、社内承認フロー) の自動化、データカタログサイトに登録されたデータのバージョン更新後の後方互換性の確保のために実施した Amazon S3 データ配置ルールについてご紹介します。 2. ソリューション概要 データカタログサイトは AWS Lake Formation を中心としたアーキテクチャで構成しました。データカタログサイトに登録したいデータの基本情報を入力すると、自動で AWS Glue のテーブルを作成し、AWS Lake Formation でアクセス管理できる状態にしました。これにより、サイロ化されていた社内の Amazon S3 のデータを 1 か所に集約させることなく、コストを抑えてデータを一元管理できるようになりました。 また、社内承認フローは Amazon SES と Microsoft Power Automate を連携させ、社内コミュニケーションツールである Microsoft Teams 上で操作を行えるようにしました。 データの利用承認を得る際は、データの利用者自身の情報をデータカタログサイト上で入力すると、データ登録者の Microsoft Teams に通知が届きます。承認された場合、自動で利用者に対してデータへのアクセス権限を付与し、利用者が Amazon Athena などのサービスからそのデータをクエリできるようになります。加えて、登録されたデータのバージョン管理も行えるように、登録されるデータの Amazon S3 のプレフィックスルールを整備することで、後方互換性を確保しました。 データカタログサイトの開発によって、社内のサイロ化しているデータを動かすことなく一元化して可視化できるサイトが構築できました。また、データの登録 / 利用時の処理には、社内承認フローが組み込まれているため、ガバナンスやコンプライアンスなども考慮したセキュアなデータ利用が可能になりました。 3. ソリューション データカタログサイトで工夫した点は以下の 3 点です。 データ登録者は S3 へデータ配置するだけでよく、データカタログサイト上から AWS Glue と AWS Lake Formation の処理を自動で行えるようにしたことで、利用のハードルを下げたこと Microsoft Teams アプリ連携により社内承認フローをシステムに組み込んだことで、簡単で安全 なデータ活用を実現できたこと 社内の Amazon S3 のプレフィックスルールを整備したことにより、登録されたデータのバージョン更新時の後方互換性を確保したこと 以下が今回のソリューションのアーキテクチャです。どのようにこれらを実現したかを説明します。 3.1 AWS Glue + AWS Lake Formation で実現するデータアクセス制御 データカタログサイトの開発を任された私たちのチームは、API で素早く実装でき、かつ、社内で管理している各アカウント間のアクセス権を容易かつ安全に設定できるサービスを探していました。 検討した結果、登録したいデータを AWS Glue でテーブル化し、AWS Lake Formation API でテーブルへのアクセス権の操作を行うことにより、実現できることが分かりました。そして、API を起動する GUI が用意された Web ページをデータカタログサイトとして社員限定で公開しました。AWS Glue でテーブル化したことにより、データカタログサイトに登録するデータは Amazon Athena や Amazon EMR などからのクエリを利用できるようになり、分析が容易になります。さらに AWS Lake Formation では、データベースやテーブルを含むデータリソースの権限管理を一元化することができ、Tag-based access control 方式で複雑なクロスアカウントでのアクセス権の制御も容易になりました。これらによって複数ある AWS アカウント上の Amazon S3 のデータを、活用しやすい形で安全にアクセス管理できるようになりました。 3.2 Amazon SES を利用した Microsoft Teams アプリ連携 データ活用を促進するために社内でデータを公開 / 利用するといっても、ほとんどの場合、社内の承認フローが必要です。 この承認作業も、確認漏れなどが発生せず、誰でも使いやすい形を検討した結果、社内のコミュニケーションツールである Microsoft Teams と連携させることにしました。 データカタログサイトに登録する Amazon S3 のデータの、AWS Glue によるテーブル化処理が完了すると、Microsoft Power Automate を起動させ、登録時に設定した承認者のメールアドレスを利用して、承認アプリを起動します。Microsoft Teams アプリ上で承認フローが実行され、承認者から結果が返却されると、再び Amazon SES で設定したドメイン宛にメールが送信され、承認結果が Amazon S3 に自動的に保存されます。承認結果が保存されると、登録申請したデータがデータカタログサイトに反映され、社内で公開される形になります。 利用時は、データカタログサイトで公開されているデータに対して利用承認の申請をすると、そのデータの登録者の Microsoft Teams に通知が届きます。Microsoft Teams 上で利用承認のフローを完了することで、システムで自動的に利用者にアクセス権が付与され、利用できる仕組みになっています。 3.3 バージョン管理のための整備 以前社内で構築していたデータレイクでは、バージョン管理に課題がありました。データを利用したい理由は様々です。ただ最新のバージョンを分析できればいいというわけではありません。分析内容によっては、旧バージョンのデータ分析が必要といったニーズもあります。 それを解決するために 登録時の Amazon S3 へのデータ配置のルールを整備し、S3 のプレフィックスの構成をメジャー / マイナー / パッチバージョンという形式にしました。これによって、最新バージョンだけでなく、旧バージョンへのクエリもいつでも行えるようになりました。また、データ登録者が新バージョンにアップデートする際に、バージョン間の差異によって、今まで利用していたバージョンが急に使えなくなるといった混乱を防ぐこともできます。非常にシンプルな対応策ですが、このルール整備でそのようなバージョンに関するそれらの課題に対応できるようになりました。 3.4 まとめ このようにして私たちは、データカタログサイトを構築しました。データカタログサイトによって、データ登録者は、セキュリティや権限が自動で付与されることで、自ら利用者に対して複雑な管理をすることなく、データを迅速に提供できるようになりました。また、データ利用者は、必要な時に必要な情報をすぐ取得できるようになりました。データ登録者、利用者それぞれのニーズに対応しつつ、同時に従来の社内データレイクの課題を解決することができました。 4. 結論と今後の展望 AWS Glue や AWS Lake Formation によって安全で簡単なデータアクセス管理を実現し、 Amazon SES で E メールを AWS 上で受信することで Microsoft Teams のような外部サービスとの連携も円滑になり、社内で活用しやすいデータカタログサイトを構築することができました。 「Piomatix」が生かされたAI搭載通信型オールインワン車載器「NP1」には、ドライブ中に音声で近隣のお出かけ先候補を提案するサービスがあります。このサービスにおけるユーザーの行動データ分析に、今回開発したデータカタログサイトが活用されています。ここで分析された結果は、提携事業者へフィードバックされ、マーケティングに活かされています。このように、すでにリリースされている商品にも、円滑なデータ分析で貢献しています。 また、AWS は、私たちが今回作成したようなデータカタログサイトをすぐに構築できる Amazon DataZone のプレビューを 2023 年 3 月 29 日に公開しています。私たちもすぐに体験してみました。Amazon DataZone は、AWS Glue、AWS Lake Formation、Amazon Athena のそれぞれの良いところを兼ね備えた上に、非技術者でも利用しやすいようにデザインされた GUI、プロジェクトの管理機能、利用者間のデータ共有時に関する承認機能まで加わったサービスになっていました。まさに今回開発した内容が、非技術者にも使いやすい状態で実現されている非常に魅力的なサービスだと感じました。2023 年 10 月 4 日に、Amazon DataZone が一般公開されました。非技術者が使いづらいというのは現在のデータカタログサイトの課題でもあったので、今後 Amazon DataZone への移行も検討したいと思っています。このような新しい AWS サービスも取り入れながら、さらに社内のデータ活用が進むように常にアップデートを続けていきます。 参考リンク Amazon DataZone is now generally available Amazon DataZone Now Generally Available – Collaborate on Data Projects across Organizational Boundaries

データはデジタルトランスフォーメーションを実現する鍵です。小売業者はデータを組み合わせて顧客を一元的に把握することで、より良い顧客体験を構築し、購入コストを削減します。金融機関はデータを使用してリスクを管理し、金融商品をパーソナライズします。製造業者は生産システムのデータに接続して単価を下げたり、品質問題を軽減したりします。 これらの業界において、異なるデータソースからのデータを業界（産業）に向けたデータプラットフォームに繋げることが、価値を引き出すための第一歩です。 産業用データプラットフォームを構築する技術的側面は よく 理解 されています。 しかし、うまく設計された産業用データプラットフォームでも失敗する可能性があります。 本記事では、産業用データプラットフォームの成功を促進する 3 つのビジネス関連のメンタルモデルについて解説します。 ユーザー起点に考える 産業用データプラットフォームとそのユースケースは多様です。 産業用データプラットフォームは業界によって変わるだけでなく、業界内の各企業でニーズが異なります。 企業が、ユーザーを十分に理解していないまま、産業用データプラットフォームの構築を始めることはよく目にします。 彼らはどのようなデータを望んでいますか？彼らはそのデータをどのように使用するのでしょうか？彼らはどのようなビジネス価値を得るのでしょうか？データを民主化するだけでは、期待通りのビジネス成果が得られることはほとんどありません。 産業用データプラットフォームを構築する前に、産業データプラットフォームに対するビジネスのニーズを深く理解することが不可欠です。 つまり、ビジネスに関わるユーザーにインタビューをし、ニーズを文書化し、エンドユーザーへの価値を明確に説明し、エンドツーエンドでユーザージャーニーマップが必要になります。 Amazon では、このプロセスを Working Backwards と呼び、顧客視点からの価値を明確にした将来のプレスリリースの作成につながります。 この作業を前もって行うには労力と時間がかかりますが、目に見えるメリットが得られます。 まず、使いやすさ、スピード、柔軟性など、ユーザー体験を反映できます。 第二に、ユーザーエクスペリエンスの向上は、より早く、より多くの利用につながり、その結果、産業用データプラットフォームの利用促進と改善に使えるフィードバックが得られる様になります。 第三に、産業用データプラットフォームはユーザーのニーズに基づき構築されているため、ビジネス成果がより迅速かつ確実に実現されます。 大きく考え、小さく始める 通常、産業用データプラットフォームは完了するまでに数年かかる長期的な投資です。 このような道のりを踏まえて、企業は途中で価値を提供することに熱心です。 長期的な拡張性と短期的なビジネス価値のバランスを取ることは困難です。 間違いは2種類ありるとAWSは考えます。1. 組織はアーキテクチャ、ガバナンス、プロセスから取り組み、価値への道筋を定義しません。2. 企業全体に拡張できない業務向けのポイントソリューションを、統合プラットフォームに構築します。 産業用データプラットフォームを成功させるには、継続的な賛同を得ながら規模を拡大すること、すなわち企業は大きく考え、小さなことから始める必要があります。 つまり、産業用データプラットフォームをユースケースごとに段階的に構築すると同時に、構築されたコンポーネントを活用してプラットフォームの利用拡大および機能拡張する必要があります。 実際には、これには次の 4 つのステップが必要です。 産業用データプラットフォームのアーキテクチャ、データ標準、データモデルだけでなく、あるべき姿や未達成部分、今後行う作業を定義します。 各ユースケースがプラットフォームのあるべき姿に沿った拡張に貢献する”様に、優先順位を決めます。 再利用可能なコンポーネントや、他のユースケースで再利用できるほど小さいマイクロサービスで、各ユースケースを構築します。 統合された産業用データプラットフォームにコンポーネントを確実に組み込み、コンポーネントの発見と開発を容易ににします。 この方法で産業用データプラットフォームを構築すると、いくつかの利点が得られ、フライホイール効果に繋がります。 産業用データプラットフォームは、ユースケースからすぐにビジネス価値を発揮すると同時に、時間の経過とともにプラットフォームの機能を標準化された方式で拡張します。 産業用データプラットフォームが成長するにつれて、ユースケース開発のペースは加速するでしょう。 さらに、産業データプラットフォームは、ユースケースの採用から継続的にフィードバックを受けるため、大規模な投資をする前に、開発の軌道修正または方向転換が可能です。 オペレーティングモデルによる構築 産業用データプラットフォームには、ビジネスと IT の両方にまたがる多くの利害関係者がいます。 ビジネスリーダーは、産業用データプラットフォームの方向性を自社のニーズに合わせようと努めますが、IT リーダーは、 CCoE 、全社 IT 標準を推進するアーキテクチャガバナンスチーム、セキュリティチームなどの組織だけでなく、プロダクトマネージャー、 IT ストラテジスト、開発者の間でサイロ化されていることがよくあります。 AWS は、多くの企業が説明責任とリソースを結び付けて効果的な実行を担保しながら、主要な利害関係者を巻き込み産業用データプラットフォームの運用モデルとガバナンスモデルを定義することに苦労しています。 産業用データプラットフォームを構築するメンタルモデルは、コンポーネント間を疎結合な状態で連携することです。各製品はバリューストリームを中心に形成され、シングルスレッドリーダー (STL) を備えています。 たとえば、ユースケースから生まれる各マイクロサービスには、維持および運用する STL が必要です。一方、プラットフォームレベルに個別の STL を設定することで、マイクロサービスを他のマイクロサービスと同様に簡単に見つけて構成できます。 そのためには独立可能で自律的なチームを構築し、アーキテクチャ設計をAPIを介して相互接続された自律型モジュールに細分化して、バリューストリームのポートフォリオと連携させる必要があります。 独立したチームが所有・提供する疎結合の産業用データプラットフォームを構築すると、開発プロセスが簡素化され、加速します。 また責任の重複が減り、委員会や調整プロセスの肥大化を軽減します。 その結果、より迅速に、各チームにオーナーシップを持たせながら、産業用データプラットフォームを構築することができます。 結論 技術的・ビジネス的の両方の観点から、産業用データプラットフォームの構築は困難です。 しかし、それらが提供するビジネス価値は、その努力に見合う価値をもたらします。 企業がこの価値を引き出すためには、ユーザーから逆算し、大きく考えて小さなことから始めて、産業データプラットフォームの各コンポーネントのオーナーシップを明確にする必要があります。 関連文書 AWS におけるカスタマーデータプラットフォームに関するガイダンス ( 英文 ) サーバーレス・カスタマーデータプラットフォームを実装するための最新のアプローチ ( 英文 ) AWS でのカスタマーデータプラットフォーム構築の概要とアーキテクチャ ( 英文 ) AWS でのモダンデータアーキテクチャ AWS で始める産業用データプラットフォーム ( 英文 ) バリューストリームマッピングリソース AWS によるイノベーション 作者情報 Rishi Kumar Rishi Kumar は、アマゾンウェブサービス (AWS) のイノベーションとトランスフォーメーションプログラムのイノベーションデリバリースペシャリストです。 彼の職務は、 Amazon の Working Backwards メカニズムを活用して、さまざまな業界の顧客のイノベーションとTransformation Journey の支援です。 Rishi は、お客様のデータプラットフォーム戦略を支援することに情熱を注いでおり、各業界のお客様と協力してデータプラットフォームのあるべき姿を形作り、達成するための施策とロードマップを定義します。 Peter Gratzke Peter Gratzke は、アマゾンウェブサービス (AWS) のイノベーションとトランスフォーメーションプログラムチームの一員です。 彼は大企業の顧客が新しい製品やビジネスを構築し、より革新的になるための変革を支援しています。 この記事の翻訳はソリューションアーキテクトの梶山 政伸が担当しました。原文は こちら です。

2023 年 9 月 28 日に、生成系 AI を簡単に利用できるサービス Amazon Bedrock の一般提供 が開始されました。またイベント同日、10 月 3 日 には東京リージョンでも Amazon Bedrock が利用可能になりました。Amazon Bedrock では、複数の高性能な基盤モデルが提供されており、プライバシーとセキュリティを維持しながら、生成系 AI アプリケーションの開発を始めるための幅広い機能群を提供します。 Amazon Bedrock の一般提供が開始されたことにより、多くのお客様が Amazon Bedrock を活用して生成系 AI アプリケーションの開発を開始すると考えています。本イベントでは、 お客様の Amazon Bedrock の活用を支援するために、Amazon Bedrock の機能や価値、ユースケースなど関して、AWS の 生成系 AI の VP である Vasi Philomin によるセッションを設けました。また実際に、Amazon Bedrock を活用した事例について、株式会社竹中工務店様、アクセンチュア株式会社様、富士ソフト株式会社様から紹介いただきました。 代表執行役員社長 長崎 忠雄によるご挨拶 アマゾン ウェブ サービス ジャパン 代表執行役員社長の長崎 忠雄から、4月から Preview で提供されてきた Amazon Bedrock に対する日本のお客様の強い関心、そして、一般利用に関する強い要望があったことが説明されました。Amazon が過去25年に渡って、AI/ML に対して投資をし続けていること、具体的には、フルフィルセンターにおけるロボット、Alexaなど、AI/ML を活用した事例を挙げ、Amazon Bedock によって日本のお客様がさらに高度な AI 活用ができる可能性について言及されました。 AWS Vice President Generative AI, Vasi Philomin AWS の生成系 AI の Vice President である Vasi Philomin からは、Amazon Bedrock の一般提供に関して、Amazon Bedrock の特徴ととも説明されました。Amazon Bedrock の特徴として、インフラを管理することなく API 経由で基盤モデルへアクセスできること、ユースケースに合わせた基盤モデルを発見するための選択肢の提供、プライベートな環境でのモデルの Fine-tuning を紹介しました。Amazon Bedrock が東京リージョンでも利用可能になるというニュースも発表されました。 Amazon Bedrock の一般提供開始および東京リージョンでの利用開始については、Amazon Bedrock のモデルプロバイダーである Anthropic 社 CEO の Dario Amodei 様および Stability AI Japan 社 GM の Jerry Chi 様からのビデオメッセージもありました。 Amazon Bedrock を利用して、生成系 AI のための基盤モデルにすぐにアクセスすることができますが、生成系 AI をアプリケーションに統合するためには、さまざまなデータやアプリケーションとの連携が必要になります。このような課題に対して、生成系 AI のためのデータソースの管理や、API を呼び出して業務を自動で実行するための Agents for Amazon Bedrock もプレビューで提供されています。 Amazon Bedrock 以外にも、生成系 AI によってコードを生成し、オープンソースに類似したコードにフラグを立てるなどの機能をもった Amazon CodeWhisperer や、社内のコードベースに基づいてそれらを実現する Amazon CodeWhisperer customization capability (近日公開予定) についても説明がありました。 最後に生成系 AI を実際に活用していくまでのステップとして、(1) 生成系AIの正しいユースケースを選択して、(2) スキルレベルが様々な開発者のスキルアップを行い、(3) Amazon Bedrock によってユースケースの検証 (PoC) を始める、という3ステップが紹介されました。 AWS では生成系 AI のためのスキルアップのためのコースを提供しています。 株式会社竹中工務店 執行役員 デジタル室長 博士（工学）岩下 敬三 様 竹中工務店 岩下様からは、建設業における Amazon Bedrock の活用検証について説明をいただきました。建設業界における課題として、生産性の向上が必要とされており、竹中工務店様はデジタル化への取り組みを進めています。具体的な取り組みとして、BIMの導入、AIによる予測、BIによる状況の見える化、デジタルツインの実現などをご説明いただきました。特に生成系 AI という観点では、知識や経験を集約して全従業員の相談や、若手の育成に活用するデジタル棟梁の実現を目指されています。デジタル棟梁は、一般的な知識をもちつつも、棟梁として社内の情報や経験を蓄える必要があります。デジタル棟梁を実現するために、一般的な知識の部分を Amazon Bedrock の基盤モデルを利用して実現し、社内のデータソースから検索して利用する RAG (Retrieval Augmented Genetation) を構築・検証されています。具体的な検証結果として、暑い時期におけるコンクリートの取り扱いについて生成系AIに問い合わせた結果をご紹介いただき、RAG の有効性をご説明いただきました。 アクセンチュア株式会社 執行役員 ビジネス コンサルティング本部 AIセンター長 博士（理学）保科 学世 様 Accenture 様では現在、生成系 AI に関する取り組みを進められており、生成系 AI のための基盤として AWS を利用されています。すでに Amazon CodeWhisperer の利用によって生産性向上を実現されている ことが、生成系 AI 活用の成果として公表されています。業務改革の経験を豊富にもつ Accenture 様では、大規模言語モデルがどのような業種に影響があるかを分析されており、あらゆる業界で適用可能であると説明されました。生成系 AI を活用する手段として、Amazon Bedrock は企業向けに適用できるサービスとして評価いただいています。特に、AWS との連携やセキュリティ、Amazon以外の複数の基盤モデルの選択肢、性能とコストのバランスの良さについて言及いただきました。Accenture 様では、様々な AI の機能を利用できる AI Hub Platform をすでに構築済みで、生成系 AI を活用しつつも、生成系 AI だけでは解決できないタスクについては、AI Hub Platform で提供される機能と組み合わせて解決してくことを述べられました。それ以外にも Accenture 様が提供できる価値として、業務改革や Responsible AI に関する経験があり、AWS および Amazon Bedrock を活用して、これらを提供していくことが述べられました。 富士ソフト株式会社 執行役員 ソリューション事業本部 副本部長 山本 祥正 様 富士ソフト様では、機械学習に関する取り組みを進めており、機械学習に関する資格取得者が多数在籍、今年の AWS Summit Tokyo では DeepRacer Summit Circuit では3位に入賞する実績を残されています。Amazon Bedrock に関しても、プレビュー期間中に検証を進めていただき、特にエンタープライズ検索サービスである Amazon Kendra とあわせてRAG を構築されています。Amazon Bedrock 自体の精度の良さを評価いただきつつも、RAG によって、大規模言語モデルにおける Hallucination を抑えることで、より安全に利用できると評価いただきました。Amazon Kendra はデータソースを指定すれば利用可能で、データの正規化が不要であり、運用コスト面でもすぐれていると述べられました。さらに、もう一つのユースケースとして、デジタルツインにおける生成系 AI 活用の実証実験についても紹介いただきました。AWS IoT Twinamker 上に、Amazon Bedrock で生成した工場の状況に関する説明を表示し、管理者が状況を容易に把握することを可能にしています。 まとめ 本イベントでは、AWS の 生成系 AI の VP である Vasi からAmazon Bedrock に関する一般提供の開始と東京リージョンでの利用可能についての発表があり、様々な業種における生成系 AI のユースケースや検証の状況について、竹中工務店様、アクセンチュア様、富士ソフト様からご紹介いただきました。イベント終了後のネットワーキングにも多くのお客様が参加され、 Amazon Bedrock の利用について活発に議論いただいたり、今後の機能拡張に関する期待についても意見をお寄せいただきました。AWS ではお客様のフィードバックにもとづいて Amazon Bedrock をより便利にし、お客様のイノベーションをサポートします。

e コマースとデジタルショッピングのトレンドが存在感を示すようになり、従来の実店舗型小売店は岐路に立たされています。オンラインショッピングの台頭は消費者の期待を再定義し、小売業者は店舗での体験を活性化させる革新的な戦略を模索する必要に迫られています。このような状況の中、生成系 AI は顧客エンゲージメントを強化し、オペレーションを合理化し、購買体験を再定義することで、実店舗を再活性化する可能性を秘めた画期的なテクノロジーとして浮上しています。 David Dorf 氏の 生成系 AI が小売業にもたらす好影響 に関する素晴らしいブログで述べられているように、 e コマースやオンラインプラットフォームにおける AI の統合に多くの注目が集まっています ー 推薦エンジンやチャットボットにテキストと画像を活用することです。しかし、物理的な小売の領域において 生成系 AI の多大な可能性は、まだほとんど開拓されていません。 これは、イノベーションの革新的な機会をもたらしており、アマゾンウェブサービス (AWS) は、その機会を探求し発展させる準備ができています。 生成系 AI で実店舗の未来を切り拓く 図 1: 実店舗でのGenerative AIのユースケース AWSがサポートする 生成系 AIは、店舗でのリテール体験を再定義できる多くのユースケースを提供します： 労働力とタスクの管理 ： 効率的な従業員管理は、円滑な店舗運営と生産性の最大化に不可欠です。生成系 AI は、従業員のタスクパフォーマンスを分析し、パーソナライズされたトレーニングコンテンツを作成することで、極めて重要な役割を果たすことができます。さらに、定型的で付加価値のないタスクの自動化を支援することで、スタッフは格段の顧客サービスの提供に専念することができます。最後に、自然言語処理を使用した生成系 AI チャットボットは、既存のワークフォース管理ツールに統合することができ、店舗スタッフが迅速かつほぼリアルタイムで情報を照会するのに役立ちます。 店舗でのクライアンテリング ： 店舗でのパーソナライゼーションは、クライアンテリングなどのセールス手法を通じて、小売スタッフが買い物客と個別の関係を築くことを可能にし、ロイヤリティと売上の向上へつながります。今日、小売業者は Amazon Personalize を使用して、顧客データ、購買履歴、市場動向、嗜好を分析し、オーダーメイドのレコメンドを実現しています。生成系 AI の機能を追加することで、オーダーメイドのメッセージング、スクリプト、コミュニケーションの作成が可能になるだけでなく、キュレーションされた没入型のワードローブも可能になりました。このレベルのパーソナライズされたインタラクションは、キオスク、モバイルアプリ、さらにはウェアラブルデバイスを通じてデジタル配信することができるため、あらゆる顧客接点がユニークで記憶に残るものになります。 棚割り計画 ：効果的にデザインされた棚割りは、顧客体験に大きな影響を与え、購買活動を促進させます。生成系 AI は、過去の販売データ、顧客の流れ、棚のレイアウト、その他のデータソースを分析することで、小売業者が商品の棚割り計画を最適化するのに役立ちます。AI アルゴリズムは、売上の最大化やカスタマーナビゲーションの改善など、事前に定義された目的に基づいて複数のデザインオプションを生成できます。小売企業は、店舗を物理的に配置換えすることなく、仮想的にさまざまな構成を試すことで時間とリソースを節約できます。 在庫予測と管理 ： 正確な在庫管理は、在庫切れを防ぎ、在庫コストを最小化し、補充サイクルを最適化するために不可欠です。従来の機械学習（ML）ベースの予測ツールは、過去の販売データに基づいて需要を予測します。しかし、生成系 AIは、天気予報、経済状況、季節パターン、購買者の行動、マーケティング・キャンペーンなどの追加的な異種データを活用することで、予測能力を向上させます。このように複雑なデータを活用することで、小売企業は需要予測と自動在庫補充の効率を高め、市場の需要に積極的に対応することで効果的にリソースを配分できるようになります。 店舗レイアウトの最適化とデザイン ： 生成系 AI は、顧客の動線パターン、ヒートマップ、過去の販売データを分析し、最適化された店舗レイアウトとデザインを作成することができる。顧客エンゲージメントと販売コンバージョンレートを最大化するために、フロアレイアウト、サイネージ、通路配置の変更を提案することができます。さらに、生成系 AI は、視覚的に魅力的な店舗内装のデザインの支援にも活用できます。顧客の嗜好、現在のデザイントレンド、さらには購買行動に影響を与える心理的要因まで分析することで、AI は店舗の内装に関するデザインの提案を生成できます。 インタラクティブな商品のカスタマイズ ： 多くのフラグシップショップでは、消費者が運動靴やシャツなどの商品をカスタムメイドできるようになっています。生成系 AI の力を活用すれば、小売業者は店舗内でカスタマイズ機能を強化する機能を顧客に提供できます。例えば、衣料品店では、顧客は AI が生成したデザインオプションを使って衣料品をパーソナライズし、購入する商品を真にユニークなものにできます。 AWS：変革をリードする AWS は長年にわたり、小売企業が AI/ML を活用してプロセスを自動化し、顧客体験を向上させ、意思決定を最適化できるよう支援してきました。AWS は、AI/ML ツールへのアクセスを向上させる研究と方法の最前線に立ち続けている。AWS は、主要な AI スタートアップ企業やアマゾンの基盤モデル（Foundation Model, FM）を API を通じて利用可能にするフルマネージドサービス、 Amazon Bedrock を一般提供しています。 Agents for Amazon Bedrock は、さまざまなユースケースに対応する複雑なタスクをこなし、独自のデータソースに基づいてほぼリアルタイムの回答を提供できるGenerative AI ベースのアプリケーションを簡単に作成できる、フルマネージドの新しい機能です。 他に Amazon SageMaker JumpStart では、幅広いユースケースのアプリケーションに、事前に訓練されたオープンソースのモデルを使用することができます。 また、コメントや既存のコードに基づいて、スニペットから完全な関数までのコード提案をほぼリアルタイムで生成できる開発者ツール、 Amazon CodeWhisperer も利用できます。これは、 Amazon Personalize 、 Amazon Forecast 、 Amazon SageMaker のような既存のサービスに加え、小売業者の AI/ML 要件に対応するためにすぐに利用可能です。 結論 進化する小売業界では、パラダイムシフト、つまり漸進的な改善を超えた変革が求められています。生成系 AIは、物理的な小売業を、没入感があり、ダイナミックで、顧客中心の領域へと再構築することができる未開拓のフロンティアです。AWS は先見性のあるパートナーとして、この未来への道をリードしています。生成系 AI の力を活用することで、小売企業は店舗体験の本質そのものを再定義し、顧客とのより深いつながりを築き、小売イノベーションの次の時代の舞台を整えることができます。 その道筋は明確であり、テクノロジーは利用可能です。物理的な小売の未来は、生成系 AI と AWS によって再構築されることを待っています。 AWS がどのように貴社のビジネスを加速させることができるか、 AWS 担当者 にお問い合わせください。 さらに読む AWS で生成系 AI を使用した構築のための新ツールを発表 AWS における生成系 AI 小売業向け AWS 機械学習ブログ このブログはソリューションアーキテクトのSatoshi Terayama が翻訳しました。原文は こちら です。 Justin Swaler Justin Swaler は、AWS のワールドワイド・フィジカル・リテール部門長として、フィジカル・リテールのグローバル戦略とソートリーダーシップをリードしています。Justin は、イノベーション戦略、リテールオペレーション、製品開発、エグゼクティブリーダーシップなど、消費財、リテール、戦略分野で15年以上の経験を持ちます。消費者体験を戦略的に革新し、組織を改革することに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号、ケロッグ経営大学院でMBAを取得しています。