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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 です。週末はヴァイオリンを弾いて過ごしています。