この投稿は2023年10月26日に投稿された The Game Developer’s Guide to re:Invent 2023 を日本語化したものです。 AWS re:Invent 2023 の開催が迫りつつあります。re:Invent は開発者向けの年次カンファレンスで、今年は、11月27日から12月1日までの日程でラスベガスにて開催されます。 AWS for Games は、世界中からの参加者を迎えるための準備を進めています。今年は、 re:Invent の基調講演 で発表される情報のほか、参加者は AWS for Games チームが厳選したパネルディスカッション、プレゼンテーション、ハンズオン形式の学習体験などの多種多様でエキサイティングなコンテンツを楽しむことができます。 今回のイベントのプログラムは、ゲーム開発者やその後ろにある業界が直面している最も大きな課題やトレンドについての議論を引き出すように設計されています。プログラムには、アマゾン ウェブ サービス（AWS）のお客様である Riot Games、Epic Games、ニンテンドーシステムズによるセッションも含まれています。参加者はカスタマーブレークアウトレクチャーを聴講したり、AWSのエキスパートと1時間の少人数チョークトークでリアルワールドアーキテクチャの課題について議論することもできるほか、2時間のハンズオンワークショップに参加し少人数のグループワークで AWS サービスを使って問題を解いたり、主要な業界テーマをカバーした20分のライトニングトークを聞いたりなど、様々なコンテンツを楽しむことができます。 さらに、AWS for Games は11月28日火曜日の午後6時から8時半まで Villa Azure にて VIP ネットワーキングイベント を主催します。イベント参加者はネットワーキングのほか、AI フォトブースを含む楽しいインタラクティブなゲーム体験に参加することもできます。会場では食べ物や飲み物をご用意しております。 こちら からお早めに参加登録することをおすすめします。 the Venetian 内に位置する AWS re:Invent expo フロアの AWS for Industry Pavilion ブース#580にもぜひお立ち寄りください。ブースでは AWS for Games のインタラクティブデモをご用意しています。デモでは AWS のお客様が作ったマルチプレイゲームをプレイしながら、ゲームの開発とデプロイで使われた AWS サービスについて学ぶことができます。 おすすめセッションお探しであれば、AWS for Games チームがまとめた AWS for Games re:Invent 参加者ガイド と下記の AWS for Games re:Invent 2023 スケジュールハイライトとを合わせてご参照ください。 また、AWS Events というモバイルアプリ（ iOS 、 Android 対応）をダウンロードし、 re:Invent のプランニングと参加時のガイドにご活用ください。今からでも参加登録は可能です。 こちら から参加できるセッションとイベントの確認および参加者枠の予約をしてください。 AWS for Games re:Invent 2023 スケジュールハイライト： 11月27日（月） 8:30 AM-10:30 AM: GAM302: ワークショップ: AWS 上でスケーラブルでクロスプラットフォームのゲームバックエンドを構築する インタラクティブなワークショップに参加し、クロスプラットフォームの ID と認証、サーバレスおよびコンテナ形式のバックエンドマイクロサービスのテンプレート、そしてゲームエンジンとの統合を備えた、エンドツーエンドのセキュアでスケーラブルなゲームバックエンドソリューションを AWS 上でデプロイしてみましょう。 10:30 AM-11:30 AM: GAM305: ブレークアウトセッション: Warhammer 40,000: Darktide を1時間で0から100,000プレイヤーまでスケールさせる Fatshark からサーバレスバックエンドアーキテクチャ、 Amazon GameLift 、 AWS Global Accelerator の組み合わせを駆使してゲームを大規模にスケールさせる方法について学びましょう。 11:30 AM-12:30 PM: GAM301: チョークトーク: AWS Graviton を用いてコスト効率の高いゲームを構築する Amazon Elastic Kubernetes Service（Amazon EKS） にデプロイされた Unreal Engine で作られた x86 向けマルチプレイヤーゲームをご覧になってください。そしてコンピュートリソースに Graviton インスタンスを導入する手立てについて学びましょう。 12:00 PM-1:00 PM: ANT309: チョークトーク: 機械学習とリアルタイムパーソナライゼーションによるゲーム体験の最適化 データの取り込みと機械学習モデルの更新ができるニアリアルタイムの機械学習パイプラインの構築方法について学びましょう。このパイプラインにより、リアルタイムのパーソナライゼーションが可能となり、プレイヤーにカスタマイズされたコンテンツを提供することでプレイヤー行動に影響を与えることができます。 3:00 PM-4:00 PM: ANT320: ブレークアウトセッション: Electronic Arts が Amazon EMR を使ってデータプラットフォームをモダナイズした方法 Electronic Arts は Amazon EMR への移行（HDFS から Amazon S3 への移行、500以上の ETL ジョブの Apache Spark から Amazon EMR への移行を含む）により、データプラットフォームのモダナイズを実現しました。その移行について学びましょう。 11月28日（火） 5:00 PM-6:00 PM: SVS308: ブレークアウトセッション: 低遅延のイベントドリブンアーキテクチャの構築 Marvel Snap を作り出した Second Dinner が、サーバレスなバックエンドデザイン、 AWS Lambda を用いた HTTP リクエストハンドリングやデータ処理、そしてAWS Lambda とその他の AWS サービスとの統合についてお話しします。 Amazon EventBridge を使ったイベントドリブンなワークフローについて学びましょう。 11月29日（水） 9:00 AM-11:00 AM: GAM401: ワークショップ: LLMOps を用いた生成系 AI アプリケーションの運用 生成系 AI とゲーム開発についてのインタラクティブなワークショップに参加し、AWS 上でテキストや画像生成アプリケーションを運用する方法について学びましょう。LLMOps に基づき、生成系AIアプリケーションに CI（continuous integration、継続的統合）/CD（continuous deployment、継続的デプロイ）/CT（continuous tuning、継続的チューニング）を適用します。 10:00 AM-11:00 AM: GAM306: ブレークアウトセッション: ニンテンドーeショップのモダナイゼーション: マイクロサービスとプラットフォームエンジニアリング 任天堂が Nintendo Switch やその他の任天堂のプラットフォームから利用できるニンテンドーeショップをモノリスからマイクロサービスアーキテクチャへ移行した方法について学びましょう。 1:30 PM-2:30 PM: GAM304: ブレークアウトセッション: 脱データセンター: リーグ・オブ・レジェンドとVALORANTの物語 Riot Games は、最大規模な2つのゲームを中断なくオンプレミスからクラウドに移行することに成功しました。彼らから移行のプロセスとノウハウについて聞きましょう。 1:30 PM-2:30 PM: GAM303: チョークトーク: コンピュート、コンテナ、Amazon GameLiftでマルチプレイゲームを展開する サーバレスなアーキテクチャでゲームのバックエンドを構築する方法を学び、マネージドなソリューションである Amazon GameLift、Amazon EKS や Amazon Elastic Container Service（Amazon ECS） を利用したコンテナベースのソリューション、 Amazon EC2 上のバーチャルマシンといったゲームサーバホスティングソリューションから、どのように最適な技術選定ができるかについて学びましょう。 3:00 PM-4:00 PM: GAM307: ブレークアウトセッション: Mortal Kombat 1 のマルチプレイヤーゲームを百万人規模にスケールさせる方法 ワーナーゲームによるセッションにご参加ください。Mortal Kombat 1 の新バージョンは世界中から百万人規模のプレイヤーに対応できるスケーリング性能を有しています。それを支えるバックエンドアーキテクチャについて学びましょう。 5:30 PM-6:30 PM: DAT334: ブレークアウトセッション: Amazon Timestream を活用した Epic Games のUX向上策 Epic Games は Unreal Engine（様々な業界で利用されている 3D 制作エンジン）でゲームに変革をもたらしました。Epic Games がどのように Amazon Timestream を活用し、同社の様々なゲームにわたる膨大な数のユーザのゲームプレイをモニタリングし、さらにそこから洞察を得ることを可能にしたスケーラブルなソリューションを構築したかについて学びましょう。 11月30日（木） 11:00 AM-12:00 PM: STG203: ブレークアウトセッション: AWS Backup の最新情報 AWS と Supercell による AWS Backup の新機能紹介セッションに参加しましょう。このセッションでは、データ保護ボリシーのセキュリティ、管理、および監査に関する実践的なティップスを学び、開発者から AWS のマネージドなデータ保護サービス群が、どのように転送中および保存されたデータを強力に保護することができるかについて聞くことができます。 以上、セッションとイベントの紹介でしたが、これらは今年の11月に開催される re:Invent で体験できるもののごく一部にすぎません。 AWS for Games ブログ や LinkedIn をチェックして re:Invent のリアルタイムな情報をゲットしましょう。ラスベガスでお会いすることを楽しみにしています！ 翻訳はソリューションアーキテクトの Lin が担当しました。原文は こちら です。

AWS re:Invent 2023 が間近に迫っており、 Amazon Connect チームでは、11 月 27 日から 12 月 1 日までラスベガスにて世界中からの参加者の方々を歓迎する準備をしています。今年の参加者は、Amazon Connect チームによって厳選された興味深いプレゼンテーションやハンズオンでの学習体験などの数々をご覧いただけます。 顧客サービス向けの生成系 AI が話題になっている中、この興味深い技術から価値を引き出し、顧客体験を向上させる方法を学ぶため、ブレイクアウトセッション、チョークトーク、ビルダーセッション、ワークショップを見逃さないでください。ここでは皆様が re:Invent のスケジュールを立てて、ラスベガスでの一週間を最大限に活用するための ガイド をご紹介します。 re:Invent 基調講演 での発表に加えて、皆様にご参加いただきたいセッションがいくつかあります。 BIZ225-INT | C-Suite leaders talk generative AI and applications （経営幹部が生成系 AI とそのアプリケーションについて語る） 11 月 28 日 (火) 午後 5 時 ～ 午後 6 時 (PDT) （日本時間: 11 月 29 日 (水) 午前 9 時 〜 午前 10 時） AWS アプリケーションズ VP の Dilip Kumar と、Asana、U.S. Bank、Woodside Energy の経営幹部とのパネルセッションでは、生成系 AI がビジネスの成果、顧客サービス、従業員幸福度についての考え方をどう変革しているかを取り上げます。このイノベーションのトークでは、生成系 AI によって組織内で変革されるプロセスとシステム、そして自社のリーダーが自社の技術スタックに統合する際に予期すべき課題についてご説明します。生成系 AI の新機能やサービスを含む、AWS アプリケーションズグループの新しい取り組みについてご紹介します。 スピーカー: Dilip Kumar（AWS アプリケーションズ VP）、Alex Hood（Asana 最高製品責任者）、Kent Lemon（U.S. Bank コンタクトセンター カスタマーエンゲージメント SVP）、Meg O’Neill（Woodside Energy Group CEO） BIZ216 | What’s next in contact centers with Amazon Connect and generative AI（Amazon Connect と生成系 AI を用いたコンタクトセンターの今後の展望） 11 月 29 日 (水) 午前 10 時 ～ 午前 11 時 (PDT) （日本時間: 11 月 30 日 (木) 午前 2 時 〜 午前 3 時） クラウドにより、各社がコンタクトセンターをモダナイズし、イノベーションを加速し、よりよい顧客サービスを大規模に提供できるようになっています。今日、ビジネスリーダーやコンタクトセンターのリーダーは、顧客によりよいサービスを提供し、エージェントを支援・強化し、データから顧客とビジネスについてインサイトを引き出すためのイノベーションを加速するために、生成系 AI のような AI 技術に注目しています。このセッションでは、Amazon Connect の新機能や、顧客とビジネスによりよい成果をもたらすために各社が運用と日々のエージェント業務を最適化している方法をご紹介します。 スピーカー: Pasquale DeMaio（Amazon Connect VP）、Chris Short（Capital One プロダクトマネジメント シニアディレクター）、Ram Mepperla（Capital One ソフトウェアエンジニアリング ディレクター） さらに、11 月 29 日 (水) に Venetian の Villa Azur で開催される 顧客体験レセプションへの出席にお申し込み いただくと、Amazon Connect のエキスパートやユーザーと交流する機会を得ることができます。当日の re:Invent セッション後の夜に立ち寄って、おいしい軽食、遊び心あふれるカクテル、会話を楽しみながら、コンタクトセンターと顧客体験をレベルアップする方法を探りましょう。 ご登録・ご予約はまだ間に合います！皆様と re:Invent 2023 でお会いできるのを楽しみにしています。 re:Invent の顧客体験のガイドはこちらからダウンロードしてください。 翻訳はソリューションアーキテクト遠藤が担当しました。原文は こちら です。

開発者とフロントエンドフレームワークの作成者が AWS Amplify Hosting 上でフルマネージドの Server Side Rendering (SSR) アプリケーションをデプロイできるようにする、新しいデプロイ仕様の一般提供を開始しました。このデプロイ仕様によって、Amplify Hosting の SSR 機能がすべてのフレームワークで利用可能になります。これらの文書化された規約に従うことで、開発者やフレームワークの作者は、Nuxt, SvelteKit, Astro、さらには Express サーバーのような一般的な SSR フレームワークで構築されたアプリケーションをデプロイすることができます。この仕様では、Compute, Image optimization, Routing rules, Static assets のための規約ベースの基本要素を定義しています。 主な機能は以下の通りです。 Static assets – フレームワークに静的ファイルをホストする機能を提供します。 Compute – フレームワークに Node.js HTTP サーバーを 3000 番ポートで実行する機能を提供します。 Image Optimization – フレームワークに実行時に画像を最適化する機能を提供します。 Routing Rules – フレームワークに入ってくるリクエストパスを特定のターゲットにマッピングする機能を提供します。 この新しい SSR のデプロイ仕様は、 Nuxt が Nitro サーバプリセットで行ったように開発者とフレームワークの作成者が SSR の基本要素を利用するためのアダプタを構築するために設計されています。さらに、開発者が基本要素をフル活用するために、Express.js のような他のフレームワークや技術で同様の実装することも可能にします。 この仕様と、Compute, Image optimization, Routing rules, Static assets に関する規約ベースの基本要素は、 Amplify Hosting SSR デプロイ仕様ドキュメント に記載されています。 Nuxt のサポート Nitro サーバー内でこのビルトインアダプターパターンを使用した Nuxt のサポートを開始されました。これによって Nuxt SSR アプリの Amplify Hosting へのデプロイを、プロジェクトに依存関係を追加することなく開始できるようになりました。新しいデプロイ仕様を使用して、Nuxt チームは、設定無しで Nuxt アプリを Amplify Hosting にデプロイできるアダプタを作成しました。以下にその方法を紹介します。 ソリューションの概要 この新機能を活用するため、Nuxt チームと協力して、Amplify Hosting への Nuxt SSR デプロイをサポートしました。この仕様は、Nuxt を駆動する Nitro サーバー内の組み込みデプロイプリセット に実装されており、Nitro 上に構築されたあらゆるフレームワークをサポートしています。 この記事では、Nuxt SSR アプリケーションを Amplify Hosting にデプロイすることに焦点を当てます。Nuxt アプリケーションは、Nitro サーバから利用可能な設定不要の組み込みアダプタを使用します。わずか数ステップで、Nuxt SSR アプリを作成して Amplify Hosting にデプロイできます。 Nuxt SSR アプリのデプロイ Nuxt アプリは Amplify Hosting に簡単にデプロイすることが出来ます。Nuxt の依存関係さえあれば、デプロイすることができまです。Nuxt は Nitro サーバー経由で組み込みアダプタを実装しているため、最小限のセットアップで Amplify Hosting にデプロイできます。 アプリをローカルで実行し、テストしたら、CI/CD で Amplify Hosting にデプロイできます。Amplify CI/CDでのビルドプロセス中に、Nitro サーバーは Amplify CI/CD パイプラインにあることを認識し、設定不要の Nitro プリセットを aws_amplify として自動的に選択します。このステップでは、アプリのビルド出力を Amplify Hosting のデプロイ仕様に合わせて調整します。このプロセス全体は、Nuxt 組み込みアダプタによって行われます。 新しい Nuxt アプリを始める はじめに、 nuxi を使用して 新しい Nuxt アプリ を作成します。 npx nuxi@latest init この例では、パッケージマネージャとして npm を使っています。インストール完了のメッセージが表示され、Git リポジトリを初期化するプロンプトが表示されます。 ✔ Which package manager would you like to use? npm ◐ Installing dependencies... > postinstall > nuxt prepare ✔ Types generated in .nuxt ✔ Installation completed. ✔ Initialize git repository? Yes ℹ Initializing git repository... Initialized empty Git repository in ... ✨ Nuxt project has been created with the v3 template. Next steps: › cd nuxt-app › Start development server with npm run dev プロジェクト内の package.json ファイルは以下の例のようになり、Nuxt と Vue の典型的な依存関係が含まれます。 { "name": "nuxt-app", "private": true, "type": "module", "scripts": { "build": "nuxt build", "dev": "nuxt dev", "generate": "nuxt generate", "preview": "nuxt preview", "postinstall": "nuxt prepare" }, "devDependencies": { "@nuxt/devtools": "latest", "nuxt": "^3.8.1", "vue": "^3.3.8", "vue-router": "^4.2.5" } } GitHub に新しいリポジトリを作成し、ローカルのリポジトリをそこにプッシュします。 Amplify Hosting でアプリを作成できるようになりました。Amplify Hosting で、 Host web app をクリックし、新しいアプリを作成します。 次に、GitHub リポジトリとブランチに接続します。 Amplify のアプリ名を入力します。Nuxt の場合、ビルドとテストの設定は自動検出によって自動的に入力されます。以下の例と一致することを確認し、必要に応じてパッケージマネージャのインストールコマンドを調整します。この設定では、ビルド環境を設定し、デプロイするアーティファクトの baseDirectory を .amplify-hosting に指定します。 version: 1 frontend: phases: preBuild: commands: - nvm use 18 - corepack enable - npx --yes nypm i build: commands: - npm run build artifacts: baseDirectory: .amplify-hosting files: - '**/*' Nitro サーバーアダプタは、デプロイ仕様に従ってファイルを整理し、 .amplify-hosting ディレクトリに自動で移動します。 ビルド設定で SSR アプリのログを有効にする アプリの サーバーサイドロギング を有効にすることができます。アプリがデプロイされると、 Amazon CloudWatch アカウントへのサーバーサイドロギングが有効になります。つまり、アプリケーションサーバーまたは Nuxt server route からのログはすべてそこにキャプチャされます。 有効にするには、 Build and test settings の Enable SSR app logs チェックボックスをオンにします。チェックボックスを選択すると、 IAM Role の選択または作成オプションが表示されます。サーバーサイドレンダリングロギングのIAM ロールを選択または作成します。Amplify Hosting に IAM ロールの作成を許可することを選択した場合、その IAM ロールはすでに CloudWatch Logs を作成する権限を持っています。 次の画面で、 Save and deploy を選択します。 アプリが正常にデプロイされたら、Amplify アプリの URL に移動します。これで Nuxt アプリが公開されました！ Nuxt image <NuxtImg> および <NuxtPicture> コンポーネントを完全に利用するには、 @nuxt/image モジュールをインストールしてアプリを設定します。モジュールでアプリを設定したら、変更をデプロイします。Amplify Hosting は自動的に画像の最適化を有効にし、コンポーネントを使用する際に画像のリサイズや変換が可能になります。 Nuxt サーバーサイドログの表示 オプションとして、いくつかのステップで CloudWatch へのサーバーサイドロギング出力をテストできます。まず、アプリの server/api/hello.ts に Nuxt server route を追加します。これは “Hello, World” の例で、ルートがリクエストを受信したときに追加の console.log() も追加します。 export default defineEventHandler((event) => { console.log('server route requested') return { hello: "world", }; }); アプリを保存し、新しい変更を GitHub のリポジトリにプッシュします。これによってアプリをビルドしてデプロイするための新しい CI/CD プロセスが開始されます。 デプロイされたら、新しいサーバーのエンドポイント ( main.<app-id> .amplifyapp.com/api/hello ) にアクセスしてください。サーバーは JSON レスポンスを返しますが、私たちの場合はシンプルな { hello: "world" } です。 サーバーサイドのログを見るには、 Monitoring > Hosting compute logs で Amplify アプリのCloudWatch ログストリームに移動します。最新の CloudWatch ログストリームをクリックします。 CloudWatch コンソールを開きます。最新の Log stream をクリックします。 これらのログでは、サーバールートで追加されたステートメントログが出力されます。 新しい Amplify Hosting SSR デプロイ仕様を利用する設定不要のアダプタのおかげで、Amplify Hosting での Nuxt アプリのデプロイは合理化されています。互換性のあるアダプタを持つフレームワークを使用している場合、Amplify Hosting は自動的に SSR の基本要素を使用してアプリケーションを認識し、デプロイします。 クリーンアップ 最後に、不要になったアプリケーションを削除します。これを行うには、このアプリの Amplify Hosting コンソールの App settings > General に移動し、 Delete app をクリックします。また、アプリのデプロイ設定中に SSR ロギング用の IAM ロールを作成した場合は、そのロールを削除する必要があります。ロールの名前は、 AmplifySSRLoggingRole-<app-id> のパターンに従います。 まとめ Nitro サーバの aws_amplify 用の設定不要なプロバイダを使用して、わずか数ステップで Nuxt アプリをビルドして Amplify Hosting にデプロイできるようになりました。この方法では、デプロイプロセスが簡素化され、Amplify Hosting 上の Nuxt アプリのビルド設定を検証するだけで済みます。Nuxt 3 アプリを Amplify Hosting 上で稼働させるための簡単で迅速な方法です。 この新しいデプロイ仕様により、開発者やフレームワークの作成者は、この仕様で概説されている SSR の基本要素を利用するための独自のアダプタを構築できるようになります。つまり、あらゆる SSR フレームワークでも、カスタムビルドのアダプタを使えば、Amplify Hosting 上で同じ合理的で効率的なデプロイプロセスを利用することができるのです。 Amplify Hosting の拡張された SSR 機能とアダプタの構築に関するドキュメントをより深く知るには、 Amplify Hostingによる SSR アプリのデプロイのドキュメント をご覧ください。 その他のリソース Amplify Hosting の SSR フレームワークサポート デプロイマニフェストを使用して Express サーバーを Amplify Hosting にデプロイ Nitro サーバー AWS Amplify プロバイダー の詳細設定 本記事は「 Introducing Support for Hosting Any SSR app on AWS Amplify Hosting 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS は、お客様のルートアカウントの所有者もしくは運用、セキュリティ、請求の連絡先へ、サービス通知や計画されているアクティビティに関する定期的な更新を電子メールで提供します。AWS はまた、 AWS Health を通じて粒度の高い通知もお客様に提供し、お客様に直接関係のある問題についてのアラートを微調整できるようにしています。ヘルスダッシュボードのモニタリング機能に加え、お客様はその基盤となっている API 、つまり AWS Health API の恩恵を受けることも可能です。AWS Health API を使うことにより、お客様はリソースに影響のあるすべての通知を収集し、それらの通知をお客様固有のビジネスニーズに合うようにカスタマイズすることができます。実際に使用されている AWS Health API の例としては AWS Health Aware フレームワークがあります。それにより、お客様は通知を収集し、それを電子メール、Slack、 Amazon EventBridge などの複数のコミュニケーションチャネルに送信することができます。 AWS のお客様は多くの場合、Organization (AWS Organizations の組織) 全体で複数のアカウントをお持ちです。これらのアカウントはそれぞれ AWS Health イベント に基づいてアラートを生成する場合があり、お客様が Organization を数百アカウントに拡大するにつれて、それらのアラートを適切なチームに大規模にリダイレクトすることが重要になってきます。 このブログでは、AWS Health を使用して AWS インフラストラクチャのヘルスイベントに関するアラートを生成するフレームワークに関するガイダンスを提供します。そして、 適切なタグ付け戦略 を使用して既存のワークフローに合うように通知を微調整することで、リソースを特定しアラートを適切な担当部署に送信することができるようにします。同様のフレームワークは現在 Zoom Video Communications 社でも稼働中で、Yasin Mohammed 氏 (クラウド運用担当マネージャー) は「AWS リソースにタグベースのフィルタリングを使って AWS Health 通知を自動的に通知するメカニズムを設定することにより、複数のアカウントやリージョンにわたって Zoom のヘルスモニタリングとアラートのメカニズムを合理化することができました」と話しています。 前提条件 お客様が AWS Health API を最大限に活用するには、まず ビジネスサポートもしくはエンタープライズサポート に登録されていることを確認する必要があります。それらが有効になると、お客様は AWS Health API をクエリするコードを記述して AWS Health アラートをカスタマイズできるようになります。organization 全体にこのソリューションをデプロイして AWS Health アラートを収集したいお客様は、AWS Health Aware フレームワークを使用することができます。これは、それらのアラートを EventBridge や SNS、電子メールなどと統合できる無料かつオープンソースのフレームワークです。 Amazon Elastic Compute Cloud (EC2) 、 Amazon EventBridge 、 AWS Lambda の IAM 権限に関する中級レベルの理解 Amazon EC2 および Amazon EventBridge の API に関する中級レベルの理解 ソリューションアーキテクチャ 多くのエンタープライズのお客様に当てはまるシナリオは、さまざまなビジネスユニットに多くのアカウントがあり、それらがさまざまな運用チームや開発チームによって管理されているような場合です。これらのチームは、データベースやセキュリティなど、特定の専門分野や責任範囲があるため、複数のアカウントにわたり特定のリソースに準じて編成されることもあります。たとえば、一部のリソースに予定されている変更をアカウントレベルで運用チームに通知する必要がある場合や、特定のデータベースに関する通知がある際にデータベース管理者にアラートを送る必要がある場合もあります。 そのようなシナリオにおいては、 AWS リソースをタグ付けするためのベストプラクティス にあるように AWS リソースにタグを付けることが重要です。いったんリソースにタグを付ければ、タグ情報に基づいて AWS Health アラートを送ることができます。AWS Health イベントは生成されると EventBridge に送られます 。Amazon EventBridge では、関連する AWS リソースからタグ情報を取得することでアラートを微調整できる Lambda 関数を、トリガするように EventBridge ルール を設定することができます。リソース環境やチーム名などを追加するといった AWS Health イベントの強化も Lambda 関数を使用することにより可能です。専用の カスタムイベントバス を作成して別々のグループ/チームに通知することもできます。Lambda 関数は強化された AWS Health イベントをカスタムイベントバスに送り、そのカスタムイベントバスではメッセージを Amazon SNS に配信して適切なユーザー/アプリケーションに通知します。ここで、AWS Health はベストエフォートベースでイベントを配信することに注意してください。イベントは EventBridge に配信されることが常に保証されているわけではありません。このフレームワークは AWS Health Aware もサポートしているため、このアラートフレームワークを organization 全体にデプロイし、適切なチームが自分たちの担当するリソースについてのアラートを各自が希望する通知方法でタイムリーに受けるようにすることができます。 図 1: ソリューションアーキテクチャ ユースケース例 この例では、DEV 環境の EC2 インスタンスにアラートを設定します。EC2 インスタンスの環境情報は environment タグを使って取得します。また、 customEventBus タグを使用して専用のイベントバスを指定します。この専用のカスタムイベントバスは SNS トピックを使用して DEV 環境管理者に通知を行います。 図 2: EC2 インスタンスのタグ EC2 インスタンスへのタグ付けに加えて、 AWS アカウント 、 Amazon RDS リソースなどのほぼすべての AWS リソースにタグを付けることができます。 AWS Organizations を使用している場合には、AWS リソースに タグポリシー を強制してチームが運用上のベストプラクティスに従うようにすることができます。 EC2 インスタンスにタグが付けられると、EventBridge を使ってそのインスタンスに対する AWS Health イベントを受信します。EventBridge ルールによりトリガされる Lambda 関数をデプロイして、AWS Health イベントの JSON ペイロードを検査し、EC2 環境情報を使って AWS Health イベントペイロードを強化し、カスタムイベントバスにアラートをリダイレクトします。専用のカスタムイベントバスは SNS を使ってアラートを適切なチャネルに配信します。 ユースケースのウォークスルー ステップ 1: インフラストラクチャチームにアラートを送信する SNS トピックを作成する Amazon SNS コンソール に移動します。 左側のパネルから [トピック] を選択し、右側のパネルから [トピックの作成] を選択します。 [トピックの作成] ページの [タイプ] で [スタンダード] を選択し、[名前] に “health-alerts” のような名前を入力します。 残りの設定はそのままにして、[トピックの作成] を選択します。 電子メールで サブスクリプションの作成 を行い、メールボックスの電子メール確認でそれを確認します。 ステップ 2: インフラストラクチャチーム専用のカスタムイベントバスを作成する Amazon EventBridge コンソール に移動します。 左側のパネルから [イベントバス] を選択し、右側のパネルから [イベントバスを作成] を選択します。 [名前] に “health-events” のような名前を入力し、[作成] を選択します。 ステップ 3: 必要なサービスへの読み書きを行うための Lambda 関数用の実行ロールを作成する IAM コンソール に移動し、左側のパネルから [ポリシー] を選択します。 右側のパネルから、[ポリシーの作成] を選択します。 ユースケースに基づいて Lambda がお客様の代わりにサービスを呼び出すために必要となる権限を追加します。この例では、基本的な Lambda 実行ポリシー ( AWSLambdaBasicExecutionRole ) に加えて、対象となる EventBridge にイベントを送信し EC2 のタグを読み取る必要があります。各サービスの IAM ドキュメントを参照して、このポリシーをニーズに合わせてカスタマイズしてください。 権限の追加が完了したら [次へ] を選択します。 ポリシーに “EnrichHealthEventsPolicy” のような名前を付けて、オプションで [説明] に説明を入力します。 [ポリシーの作成] を選択します。 IAM ポリシーを設定したら、ポリシーから Lambda 実行ロールを作成します。 IAM コンソールに移動し、左側のパネルから [ロール] を選択します。 右側のパネルから [ロールを作成] を選択します。 [AWS のサービス] を選択します。ユースケースでは [Lambda] を選択し、[次へ] を選択します。 先ほど作成した “EnrichHealthEventsPolicy” を選択し、[次へ] を選択します。 ロールに “EnrichHealthEventsLambdaRole” のような名前を付けて、[ロールを作成] を選択します。 ステップ 4: Lambda 関数を追加して EC2 タグを取得し、AWS Health イベントを強化する Lambda コンソール に移動します。 右側のパネルから [関数の作成] を選択し、[一から作成] を選択します。 関数に “EnrichHealthEvents” のような名前を与えます。 ランタイムを選択します (この例では、Python を使用します)。 [デフォルトの実行ロールの変更] を選択し、ステップ 3 で作成した実行ロールを選択します。 [関数の作成] を選択します (これで簡単な “hello world” 関数が作成され、次のステップに進むために保存しておくことができます)。 [Deploy] を選択します。 後から、必要に応じて Lambda 関数を強化、反復、カスタマイズ、テストすることができます。 EC2 インスタンスの AWS_EC2_MAINTENANCE_SCHEDULED に対するテストの AWS Health Event の構造は以下の通りです: 図 3: AWS Health Event スキーマ Python で Lambda 関数をコーディングする際の Tips： 図 3 を参照すると、以下のコードスニペット (python) を使用して affectedEntities を参照することで EC2 インスタンスのインスタンス ID を取得できます: ec2InstanceId= event['detail']['affectedEntities'][0]['entityValue'] 影響を受けた EC2 インスタンスに関連付けられている environment と customEventBus のタグを取得します。これを行うために、EC2 インスタンス ID で インスタンスをフィルタリングし 、タグキーをループ処理してタグ値を取得します。 イベントは environment フィールドを追加するだけで強化されます: event['environment'] = environment 最後に、 put_events API コールを使用してステップ 2 で作成したカスタムイベントバスに強化したイベントを送信します: cloudwatch_events = boto3.client('events') response = cloudwatch_events.put_events( Entries=[ { 'Source': 'modifiedHealthEvent', 'EventBusName': eventBusName, 'DetailType': 'enrichedEvent', 'Detail': json.dumps(event) } ] ) ステップ 5: EventBridge ルールを作成してイベントをカスタムイベントバスから SNS へ送信する EventBridge コンソール に移動します。 右側のパネルから、[使用を開始する] で [イベントブリッジルール] を選択し、[ルールを作成] を選択します。 [ルールの詳細] ページで、[名前] にルールの名前 (例: “send-enriched-events”) を入力し、[イベントバス] でステップ 2 で作成したイベントバス (例：“health-events”) を選択して [次へ] を選択します。 [イベントパターンを構築] ページで [イベントソース] の [イベントソース] で [すべてのイベント] を選択します。他のオプションはすべてそのままにして、[次へ] を選択します。 [ターゲットを選択] ページにおいて、[AWS のサービス] を選択します。[ターゲットを選択] ではステップ 1 で作成した SNS トピック (例：“health-alerts”) を選択します。[次へ] を選択します。 [タグを設定] ページはデフォルトのままにし、[次へ] を選択します。 [レビューと作成] ページで [ルールの作成] を選択します。 ステップ 6: AWS Health イベントを Lambda 関数に送信する EventBridge ルールを作成する EventBridge コンソール に移動します。右側のパネルから、[使用を開始する] で [イベントブリッジルール] を選択し、[ルールを作成] を選択します。 [ルールの詳細] ページで、[名前] にルールの名前 (例: “health-events-rule”) を入力し、[イベントバス] で default を選択します。[次へ] を選択します。 [イベントパターンを構築] ページで [作成のメソッド] まで移動し、[パターンフォームを使用する] を選択します。 [イベントパターン] の [イベントソース] で [AWS のサービス] を選択し、[AWS のサービス] では [Health] を選択します。イベントタイプについては [特定のヘルスイベント] を選択します。[特定のサービス] で [EC2] を選択します。[次へ] を選択します。 図 4: EC2 ヘルスイベントをフィルタリングするためのイベントパターン [ターゲットを選択] ページにおいて、[AWS のサービス] を選択します。[ターゲットを選択] では [Lambda 関数] を選択します。[関数] でステップ 4 で作成した Lambda 関数 (例：“EnrichHealthEvents”) を指定します。[次へ] を選択します。 [タグを設定] ページはデフォルトのままにし、[次へ] を選択します。 [レビューと作成] ページで [ルールの作成] を選択します。 ソリューションのテスト ソリューションをテストするには、Lambda のテスト機能の使用を検討してください。 Lambda コンソール に移動し、ステップ 4 で作成した Lambda 関数を選択します。 [テスト] タブに移動し、図 3 のイベント構造を変更して [ 新しいイベントを作成 ] を行います。 [コード] に移動し、[Test] ドロップダウンで作成したテストイベントを選択します。[Test] を選択します。 これによりテストヘルスイベントがトリガーされ、ステップ 1 で設定したメールアドレスに通知が届くはずです。 これでこの例で提供されているウォークスルーをお客様のビジネスニーズに合わせて変更できるようになりました。リソースとタグに応じて、ご利用の環境でソリューションをテストしてみてください。 まとめ このブログ記事では、AWS リソースに関連するタグを割り当ててアラート通知を自動化し、通知ノイズを減らしながら AWS Health イベントへの応答を改善するフレームワークについて紹介しました。AWS Health イベントを解析し、関連するチーム向けにそれを強化する方法を紹介しました。AWS Health の詳細については AWS Health ドキュメント をご参照ください。 著者について Pranjal Gururani Pranjal Gururani はシアトルを拠点とする AWS のソリューションアーキテクトです。Pranjal はさまざまなお客様と一緒にビジネス上の課題に対処するクラウドソリューションを構築しています。彼はハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。 John Bickle John Bickle はカナダのモントリオールを拠点とするシニアテクニカルアカウントマネージャー兼エンタープライズサポートリーダーです。John はお客様と緊密に連携してオペレーショナルエクセレンスを実現し、複雑さを軽減し、ダウンタイムをなくすことに喜びを感じています。余暇には音楽、セーリング、写真撮影を楽しんでいます。 Ballu Singh Ballu Singh は AWS のプリンシパルソリューションアーキテクトです。彼はサンフランシスコのベイエリアに住んでおり、お客様が AWS 上でアプリケーションを設計し最適化できるように支援しています。余暇には読書や家族との時間を楽しんでいます。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

Amazon Pinpoint は、SMS やテキストメッセージング、E メール、モバイルプッシュ、音声、アプリ内メッセージングなどのコミュニケーションチャネルを利用して、アプリケーション開発者が顧客とエンゲージメントを取るのに役立つマルチチャネルコミュニケーションサービスです。 Amazon Pinpoint SMS は、Web、モバイル、ビジネスアプリケーションで SMS および音声メッセージングを提供するために必要なグローバル スケール、回復力、柔軟性を提供します。 SMS メッセージングは、ワンタイムパスコードの検証、タイムリーなアラート、双方向チャットなどのユースケースで、そのグローバルなリーチと普及性のために使用されます。 現在、Amazon Pinpoint SMS は 240 を超える国と地域にメッセージを送信しています。 ここでは、新しい Pinpoint SMS 管理コンソールを使用して、SMS リソースを正しく最初に設定する方法を確認します。 このブログでは、管理コンソールを使用した Pinpoint SMS のセットアップと構成の手順を説明します。 また、すべてのセットアップと構成は、 Pinpoint SMS API を使用して完了することもできます。 詳細については、Pinpoint SMS ドキュメント を参照するか、 Amazon Pinpoint SMS ワークショップ を完了してください。 Pinpoint SMS 管理コンソールは、 Pinpoint SMS API の既存の機能の制御を提供し、SMS および音声リソースを作成および管理することができます。 さらに、Pinpoint SMS コンソールには、セットアッププロセスをガイドし、SMS リソースをリクエストおよび管理するためのクイックスタート – SMS セットアップガイドまたは発信者リクエストフローがあります。 Amazon Pinpoint SMS を使用した SMS の動作についての背景が必要な場合は、 Amazon Pinpoint でのグローバル SMS 送信の管理方法 を参照してください。 以下は、このブログ投稿でポイントとなるいくつかの重要な SMS の概念です。 重要な SMS の概念とリソース 電話プール: 電話プールリソースは、すべて同じ設定を共有し、番号が利用できなくなった場合のフェイルオーバーを提供する電話番号と送信者 ID のコレクションです。 発信者: 発信者とは、電話番号または送信者 ID を指します。 電話番号: 発信者番号とも呼ばれ、電話番号は送信者を識別する数字の文字列です。これはロングコード、ショートコード、料金無料通話番号 (TFN)、10 桁のロングコード (10DLC) です。詳細については、 電話番号または送信者 ID の選択 を参照してください。 検証済みの宛先電話番号: アカウントがサンドボックスの場合、検証プロセスを経た電話番号にのみ SMS メッセージを送信できます。 その電話番号は検証コードが含まれる SMS メッセージを受信します。 受信したコードをコンソールに入力してプロセスを完了する必要があります。 シミュレーター電話番号: シミュレーター電話番号は、他の発信元および宛先電話番号と同じように動作しますが、SMS メッセージはモバイルキャリアには送信されません。 シミュレーター電話番号には登録が必要なく、テストシナリオに使用されます。 ※現状日本のシミュレーター番号はありません 送信者 ID: 発信者 ID とも呼ばれ、送信者 ID は送信者を識別するアルファベットと数字の文字列です。 詳細については、 電話番号または送信者 ID の選択 を参照してください。 登録済み電話番号: 一部の国では、電話番号や送信者 ID を購入する前に、会社のIDを登録する必要があります。 また、その国の受信者に送信するメッセージのレビューも必要です。 登録は外部の第三者によって処理されるため、電話番号のタイプと国によって登録処理にかかる時間が異なります。 必要なすべての登録が完了すると、電話番号のステータスがアクティブに変更され、使用できるようになります。 登録が必要な国の詳細については、 サポートされている国と地域 (SMS チャネル) を参照してください。 はじめに AWS 管理コンソールにサインインし、Amazon Pinpoint を検索します。 AWS アカウントをお持ちでない場合は、アカウントを作成するために次の 手順 に従ってください。 Amazon Pinpoint コンソールで、Amazon Pinpoint SMS と Amazon Pinpoint Campaign Orchestration のどちらを管理するかを選択できます。 Pinpoint SMS は、SMS 送信のために関連リソースを設定および構成するアプリケーション開発者がアクセスする場所です。Pinpoint Campaign Orchestration は、顧客セグメントを管理し、キャンペーンやマルチステップ ジャーニーを使用してメッセージを送信するビルダーを対象としています。 Pinpoint Campaign Orchestration は、Pinpoint SMS や Amazon SES (Simple Email Service) などのチャネルを利用してメッセージを配信します。 このブログでは、管理コンソールを使用した Pinpoint SMS の構成方法について説明します。 クイックスタート – SMS セットアップ ガイド Pinpoint SMS コンソールを選択すると、[概要] ページが表示されます。 このページには、SMS リソースの概要とクイックスタート – SMS セットアップ ガイドが表示されます。 このガイドでは、SMS メッセージの送信を開始するための適切な SMS リソースの作成を案内します。 クイックスタート ガイドに概説されている手順は推奨ですが、必須ではありません。 ステップ1: 電話プールの作成 電話プールは、同じ設定を共有し、番号が利用できなくなった場合のフェイルオーバーを提供する電話番号と送信者 ID のコレクションです。電話プールは、番号のレジリエンスを管理する利点があり、送信アプリケーションからの複雑さを取り除き、電話番号と送信者 ID を管理するための論理的なグルーピングを提供します。例えば、電話プールは、OTP (ワンタイムパスワード) メッセージのために使用するなど、ユースケースごとにグループ化できます。 ナビゲーションペインの [概要] で、[クイックスタート] セクションの [プールを作成] を選択します。[プールのセットアップ] セクションで、プール名にプールの名前を入力します。プールを作成するには、プールに関連付ける発信元 ID 、電話番号または送信者 ID を選択する必要があります。追加の発信元 ID は、プールが電話プールページで作成された後に追加できます。アカウントにアクティブな電話番号または送信者 ID がない場合は、テストに使用でき、登録は必要ないシミュレータ番号を選択することをお勧めします。発信元 ID を選択したら、[電話プールの作成]を選択してステップ1を完了できます。 ステップ2: 設定セットの作成 設定セットは、メッセージの送信時に適用されるルールのセットです。 例えば、設定セットは、メッセージに関連するイベントの宛先を指定できます。 SMS イベント(配信または失敗イベントなど)が発生すると、メッセージの送信時に指定した設定セットに関連付けられた宛先にルーティングされます。 メッセージの送信時に設定セットを使用する必要はありませんが、使用することをお勧めします。 SMS および音声イベントをAmazon CloudWatch、Amazon Kinesis Data Firehose、およびAmazon SNSに送信することをサポートしています。 ナビゲーションペインの [概要] で、[クイックスタート] セクションの [セットを作成] を選択します。 [設定セットの詳細] セクションで、設定セット名に名前を入力します。 [イベント送信先の設定] では、CloudWatch、Kinesis Data Firehose、および SNS を自動的に作成および構成してすべてのイベントを記録する CloudFormation スタックを作成する「クイックスタート」オプション、またはセットアップするイベント送信先を手動で選択する「詳細設定」オプションを選択します。 選択後、[作成]を選択してステップ2を完了します。 ステップ3: SMS 送信のテスト SMS シミュレータを使用してテストメッセージを送信します。 送信元を選択し、送信先の番号を選択します。 メッセージのステータスを追跡するには、SMS イベントを公開する設定セットを追加します。 ナビゲーションペインの [概要] で、[クイックスタート] セクションの [テストメッセージを送信] を選択します。 [発信者] セクションで、アカウントの電話プール、電話番号、または送信者 ID を選択します。 次に、[送信先番号] セクションで、テストメッセージを送信するシミュレーター番号またはアクティブな宛先番号を選択します。 アカウントがサンドボックスの場合、シミュレータ番号または検証済みの宛先番号にのみメッセージを送信できます。 アカウントが本番になると、シミュレータ番号または任意のアクティブな宛先番号にメッセージを送信できます。 SMS イベントを追跡するために、設定セットを選択できます。 次に、[メッセージ本文] セクションで、サンプルメッセージを入力してテストメッセージを送信します。 注意 – 米国のシミュレータ番号から送信している場合(または米国のシミュレータ番号のみが含まれる電話プールから送信している場合)、米国のシミュレータの宛先番号にのみメッセージを送信できます。 シミュレータの電話番号は、他の電話番号と同様に機能しますが、SMSメッセージはモバイルキャリアには送信されません。 ステップ4: 本番アクセスのリクエスト 最後に、アカウントが サンドボックスの場合、使用できる金額に制限があり、検証済みの宛先電話番号にのみ送信できます。 これらの制限を削除するには、サンドボックスから本番への移行をリクエストしてください。 本番に移行するには、 AWS Support Center  でケースを開きます。 まとめ 本番アクセスのリクエスト後、アカウント構成の設定を完了するために推奨されるステップを実行しました。 アカウントで次のリソースをテストおよび構成しました。 電話プール: 電話プールは、同じ設定を共有し、番号が利用できなくなった場合のフェイルオーバーを提供する電話番号と送信者 ID のコレクションです。電話プールは、番号のレジリエンスを管理する利点があり、送信アプリケーションからの複雑さを取り除き、電話番号と送信者 ID を管理するための論理的なグルーピングを提供します。 発信元: プールの設定の一環として、プールに少なくとも1つの発信元を関連付ける必要があります。発信元は、電話番号または送信者 ID を指します。シミュレータ番号を選択した場合は、新しい 電話番号  または送信者 ID をリクエストできます。 設定セット: 設定セットを使用すると、SMS イベントを整理、追跡、構成して、それらを公開する場所を指定できます。 次のステップ 管理コンソールの [リクエスト発信者] フローを使用して  発信元  の電話番号や送信者 ID などをリクエストできます。発信元がサポートされており、 登録  が必要な場合は、管理コンソールで電話番号または送信者 ID の登録を自動で行うことができます。 この記事は、 Simplify your SMS setup with the new Amazon Pinpoint SMS console を翻訳したものです。翻訳は Solution Architect の 中村 達也 が担当しました。

　本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第2回の前半となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。前半については、 こちらのリンク からご確認ください。 　なお、第1回の寄稿については、「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半) 」をご参照ください。 ４．システムアーキテクチャ 　次に、私たちが検討を進めている次世代スマートメーターシステムのアーキテクチャの概要をご紹介します。 　上述の開発方針に沿って疎結合アーキテクチャを実装するにあたって、サブシステム間の連携では疎結合を基本としています。具体的には、HES から MDMS 、そして MDMS からデータを一元管理するメーターデータ活用基盤へのサブシステム間連携においては、Amazon SQS を活用してシステム間を非同期に連携させながら、高い弾力性とリアルタイム性の高いデータ転送を同時実現できるよう設計しました。SQS をベースとした仕組みを構築することで、定期的に大量に発生する検針値や、停電や復電時に大量に送信されてくるイベント情報などをバッファリングしながら受信して、後続処理に高速に連携していくことができ、大量のバーストトラフィックに対して弾力性を保ったニアリアルタイムの処理が可能なアーキテクチャを組んでいます。 　また、疎結合アーキテクチャを基本とするサブシステム内では、マイクロサービスの活用を進めます。業務ロジックを見直して機能を細分化し、使用量計算や計器イベントの処理などは AWS Lambda などを活用、パッケージ的なアプリケーション実行環境は Amazon ECS, AWS Fargate をベースとしたコンテナ環境で実現、その上で、Amazon S3 や Amazon DynamoDB などと API 連携することで疎結合アーキテクチャを組み上げます。現在は制度が決まっていない将来的な新機能実装については、機能細分化されたサーバレスやコンテナを活用しながら柔軟かつ俊敏な開発を実現します。 　データベースのセキュリティやバージョンアップの対応に係る運用保守性の向上などを念頭に置いて、AWS マネージドサービスを中心に据えてシステムを組み上げる方針としており、これに伴い、S3 だけではなく、Amazon Aurora 、 Amazon KeySpaces、DynamoDB や Amazon RDS for PostgreSQL といったデータベースや、データ連携のための Amazon API Gateway など各種マネージドサービスを活用しています。 　スマートメーターシステムで収集された検針値データや設備情報などの将来的な高度利活用やその活性化に向けて、まずはメーターデータ活用基盤のデータストアにそれら情報を一元的に集約管理するとともに、これを起点としたデータ活用の仕組みを Lambda や API Gateway などを利用しながら先行開発します。データ利活用の高度化に向けては、このデータストアに Amazon QuickSight などを連携して手軽なデータ分析が可能な環境を整備するとともに、AI/ML サービスも試行錯誤の段階から活用して業務適用できるようにしていく計画です。 　図 6 に、私たちが開発を進めているシステムの全体概要を示します。 図 6 当社の次世代スマートメーターシステムのアーキテクチャ概要 ５．共通基盤の導入とシステム統制 　私たちの 15 年間に亘るスマートメーターの取り組みの中で、様々な課題に直面してきました。それらは例えば、システム間での機能重複や、複雑な連携方式など、データ利活用に際して柔軟性に欠ける課題や、システムベンダの独自 OS や商用データベース、ミドルウェア採用に伴う経済性や将来持続性の課題、システムのブラックボックス化や業務処理ロジックの隠匿化などの課題、更には半導体枯渇によるサーバハードウェア調達納期の遅延など、将来の不確実性も含めた課題というものでした。これらの課題は、一元的なシステムコンセプトのもとでの開発ができなかったことが根源的な要因だと考えており、今回は自らの開発コンセプトを入れ込むことを重視しています。 　そのためには私たちが今回開発プラットフォームとする AWS クラウド上のシステム基盤を正しく理解する必要があります。つまり、アプリケーションレイヤから、それを支えるインフラレイヤまで、すべてをシステムベンダに任せてシステム開発するのではなく、今回は、クラウドのインフラレイヤと、その上のアプリケーション用の AWS アカウント管理からネットワーク機能、セキュリティ対策など、システム全体に係る共通的な機能を「共通基盤」として整理したうえで、私たちが管理することでアプリケーションレイヤの開発方向性を含めて全体統制することとしました。私たちがインフラレイヤを正しく理解し、深層まで把握することで、これを基盤とするアプリケーションの開発についても、システムベンダとしっかり連携して協調しながら進めることができると考えています。システムベンダにとっても、業務に紐付くアプリケーション開発により注力することができるようになるため、結果としてこれまで以上のシステム品質確保が可能になり、将来的なデータ利活用にも確かな道筋を手に入れることができるものと考えています。 　私たちがクラウドのインフラレイヤを正しく理解して所管し、将来的なデータ利活用まで手の内化していくための取り組みのポイントが三つあります。 　一つ目は、AWS のマルチアカウント戦略に基づいて、AWS アカウントを分割することです。これによって責任範囲を明確化するとともに、セキュリティ面の強化を図ります。具体的には、共通基盤は私たちが管理した上でシステムベンダごとに AWS アカウントを分割し、ベンダにはアカウント内でシステム構築や保守を実施いただきます。また、システム間の接続点は最小化し責任分界点を明確化します。必要なユーザ ID も、共通基盤側から提供します。これを、AWS のマルチアカウント戦略(*2)の考え方の元、整理したものが、図 7 となります。 (*2) Organizing Your AWS Environment Using Multiple Accounts 　このように、本番、試験、開発という環境を分離して整備するとともに、各環境内において共通基盤やサブシステムごとの責任分解を AWS アカウントにより明確に分割しています。これにより、システムベンダは付与されたアカウント内においてアプリケーションシステムの開発に注力し、システムの運用保守も担当いただきます。 図 7 AWS アカウントのシステム間分割による責任範囲の明確化とセキュリティ強化 二つ目は、AWS の責任共有モデルをベースに、AWS とシステムベンダ、および私たちの責任範囲を明確にすることです。これに伴い、OS など標準化が必要なものは共通基盤として私たちが管理してベンダに提供します。OS 種別やバージョンに係るシステムごとのバラツキをなくすことができ、TCO 削減にもつながります。具体イメージは、図 8 となります。 図 8 共通的なインフラ機能の一元管理 　三つ目は、 AWS Professional Services の協力を得ることです。クラウドのフル活用を実現するためには、共通基盤の導入が必要不可欠であり、その上でシステムベンダ各社との協力をより緊密にしていくことが重要だと考えています。これには、私たちが当事者としてシステムを正しく理解して、環境変化に伴うシステムの拡張や変更に着実に対応していくことが求められ、つまりは私たちが AWS を正しく理解することが必須であり、AWS Professional Services の協力を得て検討やスキル・知見の獲得を加速しています。AWS Professional Services のメンバーと随時協調を取りながら、多岐にわたる技術課題を適切に理解し柔軟かつ的確に課題解決を図りつつ、プロジェクト推進にかかる PMO のサポートや私たちのメンバーの教育支援など、包括的な支援をうけることで、システム開発を加速させて取り組みを進めています。 6．おわりに 　今回の寄稿では、AWS を活用する次世代スマートメーターシステムについて、技術的な観点も交えて取り組み状況をご紹介しました。次回は現行スマートメーターシステムのクラウドシフトについてご紹介したいと考えています。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

　本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第2回の前半となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。 　なお、第1回の寄稿については、「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半) 」をご参照ください。 １．はじめに 　本稿では、三部構成で当社の取り組みを紹介します。第１回では、当社スマートメーターシステムにおけるクラウド活用に向けた議論の全体像をご紹介しました。今回は、AWS を活用した次世代スマートメーターシステムの全体像について、技術的な観点も交えて私たちの現在の取り組み状況をご紹介します。 (図 1) 図 1 スマートメーターシステムと本稿における説明対象範囲 ２．次世代システムの要件 　当社では次世代スマートメーターシステムの開発にあたり、15 年間に亘る現行スマートメーターシステムの開発や維持運用の経験、次世代スマートメーター制度検討会の取りまとめ内容や社外ニーズ、および最新技術動向を踏まえ、開発コンセプトを社内で議論しました。 　現行システムを開発した 15 年前は基本がオンプレミス環境であり、アプリケーションは私たちの観点での開発を行うものの、機能配置やシステム間連携方法などのアーキテクチャは、システム毎に異なるベンダに依存することになり、ベンダ間調整によりシステム全体を構築しました。つまり、私たちのコンセプトに基づく一元的なシステム開発は不可能で、その結果、システム間での機能重複や複雑なシステム間連携があり、結果として柔軟なデータ活用に制約が生じていました。 　次世代スマートメーター制度検討会では、再生可能エネルギーのコスト低下やエネルギーマネジメントの高度化、レジリエンス強化に対する関心の高まり、更には 2050 年カーボンニュートラル宣言等を背景とした分散型エネルギーリソースの導入拡大の進展がこれまで以上に期待されるようになってきていることが指摘されました。それらの結果、分散化・多層化を志向する次世代配電プラットフォームにおいて、データを活用した電力ネットワークの運用の高度化、電力分野以外への電力データの利用拡大、需要側リソースの拡大に伴う取引ニーズの多様化などへの対応を目的として、新仕様スマートメーターシステムへのアップグレードの必要性が取りまとめられております。 　私たちは社内外の環境変化を踏まえ、2023 年 8 月に関西電力送配電グループビジョンを制定し、関西一円のネットワーク設備、人財と技術、お客さまや社会の皆さまとのつながりといった送配電グループが有するプラットフォームを深化・拡大させることで、電気の安定供給のみならず、お客さまや社会に新たな価値を提供するエネルギープラットフォーマーへ進化し続けたいという考えを公表しました。そのキーとなるツールが、スマートメーターやそのデータを活用するためのシステムであると考えています。 　これらの背景のもと、次世代スマートメーターシステムの基本コンセプトは、「データの一元管理」、「類似機能の統廃合」、「相互影響しにくい疎結合な機能配置」であると考え、スマートメーターシステムに接続する周辺システムの更新計画、現行スマートメーターシステムから次世代システムへの円滑な移行等も踏まえ、将来にわたって柔軟かつ効率的な運用が可能なシステムを、シンプルかつ低コストに実現することも併せてコンセプトとして謳い、RFP を実施しました。より端的に表現すると、システムには、徹底的な拡張性や機能開発への柔軟性、および可用性を求め、今後想定される現行システムの移行や、スマートメーターへの機能追加要望、現行と次世代のシステム混在期の円滑な業務運用の実現、更にはスマートメーターシステムと周辺システムとの連携を推進し、再生可能エネルギーの導入拡大やレジリエンスの強化、およびお客さまの多様なニーズへの着実な対応にもつなげていきたいと考えています。 　これまで 15 年間のスマートメーターシステムの開発と運用の経験を踏まえると、当社が目指す姿の実現のためには、システム開発の考え方を抜本的に見直す必要があると考えました。実績のある従来の技術を継続採用することでリスク軽減が図れることは理解しながらも、私たちは新しい技術を正しく評価し、リスクコントールをしながら活用する方向性があると認識し、今回構築する全てのシステムを、AWS のクラウド上に実装するとともに、できる限り AWS サービスを利用することが望ましいと考え、開発に着手しております。その具体的な考えを、次章以降で記載いたします。 ３．次世代スマートメーターシステム開発方針 　前章で紹介した通り、次世代スマートメーターシステムでは、メーターの収容数や処理負荷増大に対する拡張性、現時点では未確定の将来の制度への対応などを見据え、新機能開発に係る実装の柔軟性とその俊敏性、送配電事業のレジリエンスを支える本システムの可用性を、将来にわたって高度に実現していくことが求められています。 　従来のモノリシックシステムアーキテクチャの考え方を踏襲した場合、スケールアップや機能追加、改修において、サイジングや一体的な機能開発などに多くの時間を要し、対応の柔軟性や俊敏性に制約が生じる傾向にあります。今回私たちは、品質を確保しながら柔軟なシステム開発の実現を志向するモダンアプリケーション開発手法によるアプローチを選択しました。モダンアプリケーションという考え方における重要な構成要素である、マイクロサービスやコンテナを用いてアプリケーションをより小さな機能単位にモジュール化して分割することで、システムとしての拡張性や将来機能実装への高い柔軟性、俊敏性を実現します。また、疎結合アーキテクチャを適切に取り込むことで、作業や障害時における影響範囲を限定し、システム全体としての可用性を高める仕組みとします ( 図 2) 。 図 2 当社のスマートメーターシステムにおける疎結合化の実現イメージ 　サブシステム内においては、疎結合化と拡張性の担保に留意しています。具体的には例えば、データベースや S3 にデータを配置し、データ授受は API 連携を基本とするとともに、データイベントをトリガーとしたイベント駆動型の仕組みを採用して非同期な機能間連携を実現します。これによって、次世代スマートメーターシステムのような大規模で複雑なシステムにおいても、耐障害性、スケーラビリティ、柔軟性の同時実現が図れます( 図 3)。 図 3 イベント駆動型アーキテクチャの特長 　また、システム開発時において、システムベンダがアプリケーション開発に注力できるようサーバレスやコンテナを積極的に活用するとともに、データベースをはじめインフラ周りは、システムベンダが個別構築するのではなく AWS マネージドサービスの利用を基本原則としました。 AWS の各種マネージドサービスを活用することで、拡張性やセキュリティ対応を AWS サービスで担保させながら、データベース等に係るシステムの維持運用を AWS にオフロードすることで当社側の業務負荷の軽減も狙っており、クラウドメリットを最大限享受する方向性としています( 図 4)。 図 4 AWS マネージドサービス活用によるメリット 　さらに、AWS クラウドにデータを一元的に集約管理することで、そのデータレイクを中心としてデータアナリティクスサービスや拡大を続ける AI/ML サービスなど AWS の最先端技術を活用し、将来に亘る高度なデータ利活用に向けた道筋を具現化していきます。AWS の分析サービスを活用することで、要件定義や設計、構築などのステップを踏まずに、ニーズが発生した初期段階から、すぐ簡単に手軽に試行錯誤しながら有用性や方向性を見極めていくことができます。メーターデータ分析の活用事例については AWS でも紹介されており（ *1、図 5 ）、これらも参考に最先端技術を「必要な時に、いつでも、手軽に」使って、データ分析やデータ利活用に取り組めるように進めて参ります。 (*1) https://aws.amazon.com/jp/solutions/guidance/meter-data-analytics-on-aws/ 図 5 メーターデータ分析に係る AWS のソリューション事例 　このような検討背景を踏まえて、当社のシステム開発方針は以下のとおり策定しました。 疎結合アーキテクチャによる拡張性とシステム開発に対する柔軟性、高い可用性の実現 マネージドサービス活用によるスケーラビリティや俊敏性、運用最適化の実現 スマートメーターデータを分析し利活用するための AWS のデータ分析サービスの活用 　当社のシステム開発方針をシステムベンダ各社と共有しながら、AWS クラウド上での次世代スマートメーターシステムの開発を進めています。 　本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「３．次世代スマートメーターシステム開発方針まで」をご紹介致しました。後半については、「 寄稿：関西電力送配電株式会社におけるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第2回) – 後半 」をご参照ください。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

このブログは Neil Salamack（Senior Product Marketing Manager）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 11 月 27 日から 12 月 1 日にかけて、 AWS re:Invent 2023 がネバダ州のラスベガスで開催されます。AWS re:Invent はクラウド愛好家や専門家、初学者に対して他にない体験を提供します。あなたは、企業を変革する生産的なソリューションを見つけるための 5 日間の機会と、新しいスキルを素早く習得するための 2000 を超えるセッションに参加できます。また、このイベントでは、あなたのキャリアやビジネスにとって次の大きなステップとなりうる繋がりを築くための 100 を超える方法が用意されています。 re:Invent ではインフラストラクチャを最適化するための AWS ファイルストレージサービスについて、学習する機会が多く含まれています。このブログでは、AWS ファイルストレージに関する全てのセッションをリスト化し、セッション選択と予約を手助けします。これらのセッションは満席になりつつありますので、必ず「座席の予約はこちら」と書かれたリンクをクリックし、席を確保してください。また、興味のあるセッションについてはお気に入りに登録することもできます。カタログページにて表示されるセッション情報には、星のアイコンが表示されます。こちらを選択することで、お気に入りとしてマークすることができます。お気に入りから外す場合は、もう一度星のアイコンを選択してください。それでは、re:Invent に参加しながら AWS ファイルストレージに関連する知識を最大化するための 3 つの簡単なステップを見ていきましょう。 STEP 1 – 基調講演や Innovation Talk に参加し、全体像を把握しましょう 毎年 re:Invent の基調講演では、最も重要な発表が行われます。基調講演に参加することで、あなたの構築するアプリケーションやビジネスの強化に役に立つ、クラウドの状況を変えるようなニュースや製品発表を聞くことができます。 re:Invent の Web サイト から基調講演や Innovation Talk のリストを確認し、スケジュールに追加してください。 まずは、AWS の著名なエンジニアである Andy Warfield のセッションです。このセッションでは、AWS のストレージに関する最新のイノベーションと、社内において洞察と革新を加速するためのアジャイルで弾力性を備えたデータ基盤を構築する方法やその視点を紹介します。AWS の高性能なストレージを使用してデータアクセスを高速化し、データレイクを簡素化、 AI/ML 機能を強化することで、組織がどのように競争上の優位性を向上させているかご覧ください。Andy は、データドリブンなビジネスの裏側で、セキュリティ、ガバナンス、分析、アプリケーション開発をサポートする AWS ストレージサービスがどのように機能しているのか、重要なポイントを紹介します。 Andy Warfield, AWS の Vice President で著名なエンジニア STG227-INT: AWS ストレージ : The backbone for your data-driven business – Innovation Talk （データドリブンビジネスの裏側） 11 月 28 日（火）2:00 PM – 3:00 PM PST（日本時刻：29 日 7:00 AM – 8:00 AM） 加えて、AWS ストレージチームは 11 月 30 日（木）12:30 PM – 1:30 PM PST（日本時刻：1 日 5:30 AM – 6:30 AM）に開催される Innovation Talk の「Putting your data to work with generative AI（あなたのデータを生成系 AI で活用する）」への参加を推奨しております。AWS の Vice President, Technology である Mai-Lan Tomsen Bukovec と一緒に、生成系 AI によってデータレイクをビジネスアドバンテージに繋げる方法を学びましょう。独自の生成系 AI ソリューションを構築する際に、独自データセットを活用するための戦略をご覧ください。具体的には、Amazon SageMaker、Amazon Bedrock、および PyTorch などの一般的なフレームワークと、AWS のコンピューティング、ストレージ、分析サービスを使用して、データセットを活用する方法を学びます。そして、非構造化データ（映像、画像、PDF）、半構造化データ（Parquet）、テーブルフォーマットデータ（Iceberg）を機械学習トレーニングやファインチューニング、チェックポインティング、プロンプトエンジニアリングに使用するためのベストプラクティスを紹介します。またビジネスデータを、カスタマイズされた生成系 AI ソリューションに取り込むための、顧客が現在使用しているアーキテクチャについてもお話しします。 Mai-Lan Tomsen Bukovec, AWS の Vice President, Technology AIM250-INT Putting your data to work with generative AI – Innovation Talk （あなたのデータを生成系 AI で活用する） 11 月 30 日（木）12:30 PM – 1:30 PM PST（日本時刻：1 日 5:30 AM – 6:30 AM） STEP 2 – AWS ファイルストレージセッションを予約しましょう AWS re:Invent では、基調講演形式の Breakout session、インタラクティブ形式の Chalk talk、ハンズオン形式の Workshop、Builders session 等様々なタイプのセッションに参加ができます。 Breakout Sessions AWS re:Invent の Breakout session は 1 時間の講義形式です。このようなセッションは会場全体で行われ、すべてのレベル（200 – 400）の全てのトピックを網羅します。またバーチャル参加者向けに、Breakout session はオンデマンド形式で配信される予定です。 STG311 | AWS storage for serverless application development （サーバレスアプリケーション開発向けの AWS ストレージ） サーバーレスなイベント駆動型コンピューティングサービスにより、サーバーをプロビジョニングしたり管理することなく、事実上あらゆる種類のアプリケーションやバックエンドサービスのコードを実行できます。このセッションでは、Amazon EFS や Amazon S3 などの AWS ストレージサービス全体を紹介し、一般的なワークフローを掘り下げて、どのストレージサービスが自身のワークロードに適しているかを判断できるようにします。AWS ストレージが、大規模にスケールし、分析ワークロードをアジャイルに実行し、総所有コストを削減するようなアプリケーションの構築に、どのように役立つかを考えてみましょう。 座席の予約はこちら STG212 | Accelerate generative AI and ML workloads with AWS storage（AWS ストレージで生成系 AI とML ワークロードを加速する） 最近の AI と機械学習技術の進歩に加え、様々な業界で AI を利活用する動きが市場主導により進んだ結果、多くの IT 組織で 新たなストレージが求められています。このセッションでは、さまざまな AI/ML サービスと統合可能で高性能かつスケーラブルな AWS のストレージが、機械学習ワークロードを構成し、イノベーションを加速させる方法を学びます。 座席の予約はこちら STG338 | Scale analytics and SaaS applications with serverless elastic storage（サーバレスで弾力性のあるストレージを使用し、分析・SaaS アプリケーションをスケーリング） クラウドネイティブなアプリケーションのデプロイやスケーリングを望む開発者やアナリスト、データサイエンティストは、クラウドリソースを通してデータを共有する必要があります。Amazon EFS はサーバレスでスケーラブルなストレージを提供し、高い IOPS パフォーマンス、低レイテンシー、スループットの自動増減を実現するように設計されています。このセッションでは、データを共有し共同作業をする方法、簡単にスケールできる SaaS アプリケーションを構築する方法、ストレージの俊敏性を高めて分析ワークロードを実行する方法、アクティブ、非アクティブなデータが混在する状況で全体的な保管コストを削減する方法を学びます。 座席の予約はこちら STG209 | Network-attached storage in the cloud with Amazon FSx（Amazon FSx によるクラウド内でのネットワーク接続型ストレージ） 規模が大きい状況で、パフォーマンスや可用性に悪影響を与えずファイルベースのワークロードをクラウドに移行することは、困難になるケースがあります。Amazon FSx ファミリーは、このようなネットワーク接続ストレージ （NAS）の課題に対応でき、フルマネージドサービスとしてアプリケーションやコードを変更することなく、共有ストレージ、耐障害性、管理互換性を実現します。このセッションでは、メディアエンターテイメント、教育、ヘルスケア、ライフサイエンス、通信分野の専門家によるユースケースを交えながら、俊敏性の向上、コスト削減、自動的なスケーリング方法について紹介します。このセッションに参加することで、自信を持って移行プランを作成できるようになります。 座席の予約はこちら STG340 | Accelerate ML and HPC with high performance file storage（高性能なファイルストレージで ML や HPC の活用を加速する） 負荷の高いワークロードを高速化することは、機械学習（ML）トレーニングの高速化や、より多くの HPC ジョブを短時間で完了できるようになるなどのメリットをもたらします。Amazon FSx for Lustre は、ML、EDA、金融モデリング、天気予報、ビデオレンダリングとトランスコーディングなど、要求の厳しい HPC ワークロードを高速化します。このセッションでは、ミリ秒以内のレイテンシー、最大数百 GB/s のスループット、数百万の IOPS を提供する共有ストレージ Amazon FSx for Lusture が、コンピューティングワークロードを高速化し、あらゆる規模の企業でどのように採用されているかをお話しします。大規模な稼働が可能で、数回クリックするだけで簡単に構成できるフルマネージド型の Lustre サービスの利点についても説明します。 座席の予約はこちら STG219 | What’s new with AWS file storage（AWS ファイルストレージの最新情報） AWS は様々な種類のフルマネージドなストレージサービスを提供しています。共有ファイルストレージである Amazon EFS や Amazon FSx はほぼすべてのアプリケーションをサポートしているため、特定のユースケース、求められるパフォーマンス、アプリケーションやワークフローとの互換性に基づいて、最適なサービスを選択できます。このセッションに参加して、ファイルストレージの最新情報を聞き、機能豊富でパフォーマンスの高いファイルストレージへの移行・実行・拡張に関する実践的なヒントを学んでください。 座席の予約はこちら STG341 | Meet performance demands for your business-critical applications（ビジネスクリティカルなアプリケーションのパフォーマンス要求を満たす） あらゆる業界の組織には、オンプレミスにありながらもクラウド移行の候補となっている、本番環境レベルのアプリケーションがあります。これまで、性能が高くフル機能を持ったファイルシステムを、クラウドにて見つけるのは困難でした。汎用的なクラウドにおける選択肢は魅力的に見えますが、複雑であり、エンタープライズクラスの機能を持たない傾向もあります。一方で、AWS のファイルストレージは、クラウド移行の促進、効率化によるコスト削減、ビジネスクリティカルなワークロードのモダナイズに役立ちます。このセッションに参加し、VMware などの環境、SAP HANA、Oracle Database/Oracle RAC、Microsoft SQL Server などのデータベース移行に関する専門家のアドバイスを受けましょう。また、メディアエンターテイメント、金融、ヘルスケア等の業界固有の基幹業務ユースケースについても聞くことができます。 座席の予約はこちら Chalk talks Chalk talk は少ない参加者で、非常にインタラクティブに行われるセッション形式です。AWS の専門家による簡単な講義で始まり、続いて参加者との Q&A が行われます。 STG343 | Powering compute-heavy workloads with burst-to-cloud storage（クラウドへのバーストストレージで計算量の大きいワークロードを強化） 高いパフォーマンスが要求される、スパイクのあるワークロードや予測不可能なワークロードがありますか？アプリケーションの高速化やリソース拡張をすぐに実行しなければならないのに、オンプレミスのコンピューティングリソースでは不十分ではありませんか？この Chalk talk に参加して、AWS ファイルストレージを用いたハイブリッドクラウド戦略を採用することにより、データの保存場所に依らないファイルデータをより迅速かつ簡単に処理する方法を話し合いましょう。スケーラブルなパフォーマンス、高速ファイルキャッシュなどの機能が、分散型機械学習トレーニング、メディアレンダリングとトランスコーディング、電子設計自動化（EDA）、ビッグデータ分析などのワークロードに柔軟性をもたらす方法をご覧ください。 座席の予約はこちら STG402 | Boost performance and run compute-intensive workloads at scale（パフォーマンスを向上させ、コンピュート負荷の高いワークロードを大規模に実行） Amazon FSx はクラウドで実行されるパフォーマンスに敏感なワークロードの一部を強化します。AWS ファイルストレージサービスを使用することで、継続的なパフォーマンスの向上と最適化を実施できます。この Chalk talk では、参加者のパフォーマンスに関する質問に答え、データ使用量を最適化するベストプラクティスを提供します。パフォーマンスモードについて詳しく学習し、IOPS の向上、スループットの最適化、レイテンシーの最小化する方法に関するガイダンスを受けることができます。 座席の予約はこちら STG221 | How to match your workload with the right file storage（ワークロードから適切なファイルストレージを選択する方法） ストレージはアプリケーション導入を成功させるための土台です。一方、適切なファイルシステムの選択は、そのシステムが既に使用しているものや使い慣れたものとどの程度一致するかという観点から検討が始まります。ワークロードに適したクラウドファイルサービスをどのように選択しますか？この Chalk talk では、ファイルシステムの機能とユースケースをより適切にマッチさせるための意思決定プロセスについて説明します。AWS の専門家と相談して、Amazon EFS と Amazon FSx ファミリー、どのファイルサービスを選択するかを決定しましょう。複雑さやコストを抑えた拡張・移行に役立つ情報を入手してください。 座席の予約はこちら STG344 | How to protect unstructured files to achieve data resiliency（非構造化ファイルを保護し、データの耐障害性を高める方法） データ量の増加の管理は容易ではありません。近年生成されるデータのほとんどは、非構造化ファイルで構成されています。大規模から小さなファイルまで存在し、それらは NAS システム、Unix サーバー、Windows サーバー、およびクラウドに保存されます。一方で、非構造化ファイルには、データ保護とコンプライアンス要件を満たす必要のある機密データが含まれていることが多く、独特な課題があります。データを保護し、安全に保つための方法を知っていますか？この Chalk talk に参加して、Amazon FSx ファミリーと Amazon EFS のファイルストレージを使用した、クラウドにおいてファイルベースのアプリケーションを安全に実行するためのヒントとツールについて話し合ってください。 座席の予約はこちら STG342 | Build and run analytics and SaaS applications at scale（分析や SaaS アプリケーションを大規模に構築して実行する） 分析ワークロードを強化し、スケーラブルなパフォーマンスを持った SaaS（Software as a Service）アプリケーションを構築するにはどうすれば良いでしょうか？Amazon EFS を使用することで、容量やパフォーマンスのプロビジョニングや管理が不要で弾力性のあるファイルストレージにより、データの分析や共有が可能になり、SaaS アプリケーションの開発とデータ分析のワークロードを加速できます。この Chalk talk に参加して、ファイルワークロードにおける予測不可能なパフォーマンスニーズをサポートする方法を学び、ワークロードに必要な一貫性を習得してください。 座席の予約はこちら STG223 | Lower your TCO of storing data for large file datasets（大きなファイルデータセットを保存する際の TCO 削減） パフォーマンスの最適化、容量のプロビジョニング、またデータ階層化の管理を行う適切なタイミングはいつですか？管理を複雑にせず、データの可用性、耐久性、保護を実現したいとお考えですか？この Chalk talk に参加して、必要な時にすぐ利用できる実質的に無制限なファイルストレージを使用して、データの価値を最大化する方法を探りましょう。Amazon EFS がパフォーマンスとストレージ容量、両方の観点でどのように柔軟にスケーリングされ、高いスケーラビリティを備えているかをご覧ください。データを大規模に活用して価値を最大化し、総所有コスト（TCO）を低く抑える方法をご紹介します。 座席の予約はこちら Workshops Workshop は、2 時間のハンズオンセッションで、チームに分かれて AWS のサービスを使用した問題解決を行います。Workshop では、参加者を小グループにまとめ、交流を促すシナリオを提示します。これにより、互いに学びを得る機会が得られます。 STG316 | Increase your database agility with Amazon FSx（Amazon FSx を使用して、データベースのアジリティを高める） SQL Server、PostgreSQL、Oracle、SAP HANA などのデータベースをクラウドに移行することは、お客様のクラウドジャーニーにおける大切な部分です。この Workshop では、Amazon FSx を使用して Amazon EC2 上にセルフマネージドデータベースを構築、実際に SQL Server、PostgreSQL、MySQL を使用してみます。Amazon FSx の高度なスナップショット、クローニング、バックアップ、およびレプリケーション機能により、RPO や RTO を数時間から数秒にまで短縮する方法をご覧ください。加えて運用だけでなく、追加の容量が不要なクローニングを使用して、開発者にデータベースのコピーを即座に提供することで、開発と更新のサイクルを短縮する方法のデモンストレーションをご覧いただきます。参加する場合はラップトップを持参してください。 座席の予約はこちら STG403 | Get insights faster: Accelerate your Amazon S3 data lake（Amazon S3 のデータレイクを加速しより早く洞察を得る） Amazon FSx for Lustre を使用することで、Amazon S3 に保存されたデータセットの取得が高速化され、より迅速に洞察を得ることができます。Amazon FSx for Lustre は Amazon S3 と統合されているため、高性能ファイルシステムから Amazon S3 のデータにアクセスして処理することができます。この Workshop では、ミリ秒未満のレイテンシーで大規模な S3 ワークロードを処理する方法を学びます。Amazon FSx for Lustre ファイルシステムを作成し、それを S3 バケットにリンク、Amazon EC2 クラスターを起動して、Amazon FSx for Lustre ファイルシステムをマウントします。Amazon FSx for Lustre が S3 オブジェクトをファイルとして Amazon EC2 インスタンスに表示し、大規模なファイルシステムでスケールアウト可能な高速スループットと高い IOPS を実現する方法をご覧ください。参加する場合はラップトップを持参してください。 座席の予約はこちら Builders sessions Builders session は 60 分間の小さなグループセッションです。1 テーブルにつき最大 6 人の参加者で、1 人の AWS エキスパートが質問に答えガイダンスを提供します。参加者はあなたと AWS エキスパート、そしてラップトップだけです。 STG405 | Rightsizing VMware Cloud compute and storage（VMware Cloudにおけるコンピュートとストレージのライトサイジング） VMware Cloud on AWS の運用が加速するにつれて、組織はストレージを大量に消費するワークロードに合わせて拡張する必要性を認識しています。この Builders session で、クラウドコンピューティングとは別にクラウドストレージを拡張することで、コストを削減および管理する方法を理解してください。TCO を削減し、Amazon FSx for NetApp ONTAP を VMware Cloud on AWS で実行されているワークロードへ補完的なデータストアとして統合する方法をご覧ください。参加する場合はラップトップを持参してください。 座席の予約はこちら STEP 3 – AWS Expo の AWS ストレージキオスクに訪問しましょう Expo には学習と交流の機会が多くあります。AWS Village に立ち寄って、製品、サービス、ソリューションについて掘り下げてみましょう。AWS ストレージキオスクでは、あらゆる分野（ファイル・ブロック・オブジェクト）の AWS ストレージ専門家が常駐しています。弊社のアーキテクトが、お客様の質問や課題に対して、ワークロードに最適なアプローチを提供できるようにお手伝いします。 今すぐ登録を！ 今年の re:Invent は、素晴らしく有益になること間違いなしです。まだ登録していない場合は、 こちら から今すぐ登録してください。ラスベガスでお会いしましょう！ 翻訳はソリューションアーキテクトの吉澤が担当しました。

このブログ記事は、Microsoft SQL Server のライセンスに関する推奨を生成する AWS Compute Optimizer の新しい機能について説明します。 AWS Compute Optimizer は、 Amazon Elastic Compute Cloud (Amazon EC2) 上で Microsoft SQL Server を実行しているお客様にライセンスコストの最適化を提案する機能があり、それによって大きなライセンスコストの削減効果を得ることが出来ます。 AWS Compute Optimizer は、 推定ワークロードタイプ を活用して SQL Server が Amazon EC2 インスタンス上で実行されているかどうかを検出します。そして、SQL Server Enterprise エディションの機能が使用されているかどうかを検出し、SQL Server Standard エディションへのダウングレードのオプションがあることを提示することで、ライセンスコストの削減を推奨します。 パフォーマンスと SQL Server ライセンスの最適化における課題への対応 データベース管理者（DBA）は、Amazon EC2 インスタンス上の SQL Server を最適化する簡単な方法を探しています。データベースのパフォーマンスへのニーズは頻繁に変化する為、ハードウェア要件、機能、設定に違いが発生してきます。それにより、お客様はデータベースのパフォーマンスを手動で分析・評価する専任の DBA を必要とすることになります。 AWS Compute Optimizer は、Amazon EC2 インスタンスと Amazon Elastic Block Store（Amazon EBS）ボリュームの適切なサイズをお客様に推奨し、インフラストラクチャのコスト削減を実現します。DBA は、AWS Compute Optimizer と推定ワークロードタイプを使用することで、SQL Server のワークロードを実行している Amazon EC2 インスタンスを迅速かつ容易に特定し、大規模なアプリケーションとデータベースのリリース後に提案される推奨事項をレビューすることができます。サイジングの適正化の分析と推奨は、主に Amazon EC2 インスタンスと Amazon EBS ボリュームのコストとパフォーマンスの最適化に重点を置いていますが、必要とするデータベース機能に関するインサイトはない為、エディションの推奨については限定的なものとなります。 SQL Server ワークロードのコスト最適化でよく見落とされるのがライセンスについてです。例えば、SQL Server Enterprise エディションの機能は、アプリケーションが最初に公開されたときには必要であったかもしれませんが、その後のリリースでは使用されなくなっているかもしれません。アプリケーション/データベースごとの個々のリリースの変更に関する深い知識がなければ、機能要件の変化を見逃してしまい、SQL Server エディションのダウングレードの機会に気付けない可能性があります。 エディションのダウングレードの機会を見つけるもう一つのユースケースは SQL Server のバージョンアップです。SQL Server Enterprise Edition と Standard Editionの機能はバージョンが変わると変更されることがあります。例えば、Transparent Data Encryption（TDE）は SQL Server Enterprise エディションでよく使われる機能です。SQL Server 2019 のリリースにより TDE はStandard エディションで利用できるようになり、Enterprise エディションの要件がなくなりました。AWS Compute Optimizer は、Amazon EC2 上で SQL Server のワークロードを実行しているお客様に対して、SQL Server のライセンスエディションのダウングレードを提案します。 AWS Compute Optimizer は、以下のような SQL Server の Enterprise Edition の様々な機能についてチェックします。  128 GB 以上のメモリのバッファプール、または 48 vCPU 以上 を必要とするインスタンス 可用性グループ、リソースガバナー、非同期リードレプリカなど、よく使用される機能 NUMA 対応やメモリ最適化 tempdb メタデータなど、使用頻度の低い機能  これらの機能や制限が無い場合、AWS Compute Optimizer は SQL Server エディションのダウングレードを推奨し、オンデマンド価格によるコスト削減の余地を提示します（図 1 参照）。SQL Server エディションの機能比較について詳しく知りたい場合は「 SQL Server 2022 の各エディションとサポートされている機能 」を参照してください。 図 1. AWS Compute Optimizer は Amazon EC2 と Amazon EBS に対して、プロビジョニング不足、最適化、またはオーバープロビジョニングのリソースを素早く特定することができる推奨を提示します。 これらの自動化されたインサイトと推奨は、お客様と DBA が SQL Server のエディションをダウングレードし、ワークロードのコストを最適化する機会を簡単に特定して検証するのに役立ちます。AWS Compute Optimizer が SQL Server のエディション機能を評価することで、DBA とお客様は、常に最もコスト最適化された SQL Server のエディションを使用していることに安心できます。 SQL Server Standard エディションは Enterprise エディションよりも73%も価格が安い ため、表 1 に示すように Enterprise エディションから Standard エディションにダウングレードすることで大幅なコスト削減が可能です。表示されている価格は、SQL Server 2022 および SQL Server 2019 の、このブログ記事の公開日時点、2023/9/26 時点での Microsoft の公開価格に基づいています。 表1. SQL Server Enterprise Edition と Standard Edition の価格比較 SQL Server のライセンス費用を削減するだけでなく、SQL Server を Enterprise エディションから Standard エディションにダウングレードすることで、BYOL のお客様はソフトウェアアシュアランスのコストも削減することができます。BYOL のお客様は、利用しない Enterprise エディション・ライセンスを再利用または温存することによって再調達のコストを削減することができ、ライセンス投資を最適化できます。 AWS Compute Optimizer のサイジングの適正化の推奨機能は、追加費用なしで利用できます。エディションのダウングレードの推奨には、有料のカスタムメトリックを使用する Amazon CloudWatch Application Insights を有効にする必要があります。詳しくは、 Amazon CloudWatch Application Insights とは 、をご覧ください。 AWS Compute Optimizer を使い始めるには 1. AWS Compute Optimizer の推奨を受け取るには、 AWS Compute Optimizer にオプトイン する必要があります。オプトインすると、Amazon EC2 インスタンスタイプ、Amazon EBS ボリュームの IOPS やスループットなど、リソースの適切なサイジングの推奨を受け取るようになります。推定ワークロードタイプ機能はデフォルトで有効になっているため、SQL Server が Amazon EC2 インスタンスで実行されているかどうかを検出するために追加の設定は必要ありません。また、Amazon EC2 インスタンス上の SQL Server ワークロードに対して エージェントによるメモリ使用 を有効化し、メモリ使用量に関するより深いインサイトを得ることを推奨します。 2. AWS Compute Optimizer の 商用ソフトウェアライセンス推奨機能 を利用するには、個々のAmazon EC2 インスタンスに対して Amazon CloudWatch Application Insights を有効にする必要があります。どの Amazon EC2 インスタンスが Amazon CloudWatch Application Insights を有効にしているか、または有効にする必要があるかを表示するには、図 3 に示すように、AWS Compute Optimizer コンソール内のナビゲーションペインで「Licenses」をクリックします。 図 3. AWS Compute Optimizer の Licenses セクションにて、SQL Serverワークロードが実行されていることを検出した Amazon EC2 インスタンスの詳細を表示できます。 3. ライセンスの推奨ダッシュボードでは、SQL Server ワークロードを実行している Amazon EC2 インスタンスが一覧表示され、検出結果によって並べ替えることができます。検出される可能性のある定義は3つあります。 a. 最適化 – これらの Amazon EC2 インスタンスでは、Amazon CloudWatch Application Insights が有効になっており、AWS Compute Optimizer は Enterprise 機能が使用されていると検知したため、すでに最適化されていると判断しています。 b. 最適化されていない – これらの Amazon EC2 インスタンスでは、Amazon CloudWatch Application Insights が有効になっており、AWS Compute Optimizer は、SQL Server Enterprise Edition の機能を使用していないことを検知したため、Standard Edition へのダウングレードを検討が必要と判断しています。 c. メトリクスが不十分 – これらのインスタンスでは、Amazon CloudWatch Application Insights が有効になっていないか、適切な権限がないため、推奨が提供できません。 4. メトリクスが不十分と表示された Amazon EC2 インスタンスについては、インスタンスIDをクリックして、アプリケーションインサイトの有効化手順を始めて下さい。 5. AWS Compute Optimizer と Amazon CloudWatch Application Insights がアクセスして SQL Server Enterprise エディションの機能使用状況を確認できるようにするには、シークレットを選択するか、作成する必要があります（図 4 参照）。シークレットは SQL Server 認証インスタンスログイン、ユーザー名、パスワードとなり、ターゲットの SQL Server インスタンスで設定する必要があります。SQL Server ログインには以下の権限があることを確認する必要があります。 GRANT VIEW SERVER STATE TO [LOGIN]; GRANT VIEW ANY DEFINITION TO [LOGIN]; ログインを作成し、対象の SQL Server インスタンスへの権限を付与したら、 AWS Secrets Manager を使用して、Amazon CloudWatch Application Insights が使用する為のログイン認証情報を保存することができます。ドロップダウンボックスからシークレットを選択してください。 図 4. ドロップダウンボックスから、Amazon Cloudwatch Application Insights にデータベースへのアクセスを許可するために作成したシークレットを選択できます。 6. また、Amazon EC2 インスタンスが上記で 選択したシークレットにアクセス できるように、 IAM ポリシーとインスタンスロール を設定する必要があります。このインスタンスロールは、ライセンスの推奨を有効にするために、SQL Server を実行している対象のAmazon EC2 インスタンスにアタッチする必要があります。”Confirm Instance Role and Policy is attached” をチェックしてください。 7. これで “ Enable license recommendations” を選択できるようになります（図 5 参照）。これを選択すると、上部に “CloudWatch Application Insights is successfully enabled” という緑色のチェックマークが表示されます。 図 5. シークレットを設定しインスタンスロールとポリシーがアタッチされると Enable License Recommendations をクリック出来るようになります。 Amazon CloudWatch Application Insights を有効にした後、AWS Compute Optimizer のダッシュボードにレコメンデーションが表示されるまで、通常は24時間かかります。有効化のプロセスでは、ターゲットの Amazon EC2 インスタンスに PrometheusSqlExporterSQL（図 6 参照）という Windows サービスをデプロイします。SQL Server Enterprise Edition の機能が使用されているかどうかを判断するためにはこのサービスが必要です。 図 6. インストールされた PrometheusSglExporterSQL サービスが実行されていることを示す Windows Services コンソール。 推奨の詳細を表示するには、ライセンスの推奨ダッシュボードの “Findings” 列で “over-provisioned” と識別されたインスタンス ID をクリックします (図 7 を参照)。インスタンスの詳細ページに移動し、上部に “License recommendations” という新しいタブが表示されます。このタブでは”最適化されていない”などの検知と”ライセンスがオーバープロビジョニングされている”などの理由を確認できます。 図 7. AWS Compute Optimizer 内の “License recommendations” セクションの表示。この例では、Enterprise Edition から Standard Edition へのダウングレードを推奨する SQL Server インスタンスが示されています。 インスタンス ID をクリックすると、”License recommendations” の更に詳細を見ることができます。インスタンス固有のページでは、現在のライセンスのコストと推奨との比較の詳細が表示されます。図 8 は、Enterprise が現在のエディションで Standard が推奨です。 図 8. AWS Compute Optimizer の “License recommendations” セクションでインスタンスIDを選択すると、そのインスタンスに対する固有の推奨事項の詳細ビューに移動します。 また、SQL Server のエディションをダウングレードした場合の、月々の削減見込み額や削減機会の割合などの詳細も表示されます。図 9 では、Amazon EC2 の削減コストと SQL Server の推奨での削減コストが円グラフで分割され、両方の推定削減コストが示されています。推奨には、ダウングレードした場合のオンデマンドのコストと、現在のエディションに留まった場合のコストも含まれているため、お客様はコスト削減の全体像を可視化することができます。 図 9. AWS Compute Optimizer のダッシュボードから、ライセンスの推奨による潜在的なコスト削減を素早く確認することが出来ます。 SQL Server Enterprise エディションから SQL Server Standard エディションへのダウングレード Amazon EC2 上で SQL Server の License Included の AMI を使用して SQL Server を実行しているお客様は、SQL Server のインプレースダウングレードではなく、新しい SQL Server Standard エディションの AMI を起動してデータベースを移行する必要があります。異なる SQL Server ネイティブの移行方法については、 SQL Server データベース移行方法のドキュメント を参照してください。 AWS Systems Manager の自動化のドキュメントは、SQL Server BYOL モデルで SQL Server を Amazon EC2 上で実行しているお客様が、SQL Server Enterprise エディションから Standard または Developer エディションにダウングレードする際にも役立ちます。自動化を使用してエディションをダウングレードする方法については、こちらのブログ記事を参照してください： Downgrade SQL Server Enterprise edition using AWS Systems Manager Document to reduce cost. まとめ 適切な SQL Server エディションを選択することで、お客様は必要な SQL Server 機能を確実に使用しながら、大幅なコスト削減を実現できます。AWS Compute Optimizer に SQL Server Enterprise Edition の機能評価が追加されたことで、組織は SQL Server のライセンスとインフラストラクチャのコストを削減することができます。この機能を使用することで、お客様はAmazon EC2 インスタンス上の SQL Server が、パフォーマンス、ライセンス、およびコストが最適化された状態で実行されていることを確認できます。 AWS は、他のどのクラウドプロバイダーよりもはるかに多くのサービスと、それらのサービス内の多くの機能を備えており、既存のアプリケーションをより迅速、簡単、かつコスト効率よくクラウドに移行し、想像できるほぼすべてのものを構築することが出来ます。Microsoft アプリケーションに必要なインフラストラクチャを提供し、お客様が望むビジネス成果を実現しましょう。マイクロソフトのワークロードに関するその他のガイダンスとオプションについては、 .NET on AWS と AWS Database のブログをご覧ください。移行とモダナイゼーションの旅を始めるには、今すぐ お問い合わせ ください。   投稿者について Blake Lyles Blake Lyles は、SQL Server を専門とする Microsoft Workloads Specialist Solutions Architect です。ブレイクはアマゾンに 6 年以上在籍し、そのほとんどの期間を EC2 上の SQL Server、RDS のサポート、Database Migration Service、Amazon DocumentDBなどのデータベースワークロードに費やしてきました。Blake は、顧客が AWS 上でデータベースワークロードを移行し、近代化するのを支援してきました。 Reghardt van Rooyen Reghardt van Rooyen は Amazon Web Services のシニア・スペシャリスト・ソリューション・アーキテクトです。14 年間の SQL Server データベース管理とリーダーシップの経験を活かし、企業のお客様向けの高スループット SQL Server HADR ソリューションのアーキテクチャリングを専門としています。常に探究心を持ち、お客様の実装がパフォーマンスとコストの最適化につながることを確実なものとなるように、AWS のインフラストラクチャと SQL Server データベースのパフォーマンス限界を探ります。南アフリカ出身で、ラグビー、バーベキュー、家族や友人と屋外で過ごすことが趣味です。 Blake Lyles Yogi はプリンシパル・ソリューション・アーキテクトであり、22年にわたりさまざまな Microsoft テクノロジーに携わってきた経験があります。AWS 上で Microsoft のワークロードを実行するためのAWSに関する深い専門知識を持っています。 翻訳はソリューションアーキテクト樋口が担当しました。原文は こちら です。

2023 年 10 月 5 日に「AWS で実践！ Analytics Modernization ～事例祭り編～」を開催しました。今回の事例祭りでは新しく GA された Zero-ETL を活用したデモや Amazon OpenSearch Service を用いたベクトル検索、また AWS Clean Rooms と AWS の分析・予測サービスをつなげた一連のデモをご紹介しました。また AWS サービスを用いてビジネス価値を創出しているお客様事例としてパイオニア株式会社 様にご登壇いただきました。本ブログでは当日の各発表内容を紹介いたします。 Zero-ETL Integration を活用した業務データベースのニアリアルタイム分析 アマゾンウェブサービスジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 濱岡 洋太 資料ダウンロード AWS の濱岡からは 2022 年の re:Invent で発表された新機能である Zero-ETL Integration を使い、 Amazon Aurora に保管されているデータを Amazon Redshift へニアリアルタイムに連携・分析する方法についてご紹介しました。 業務系データベースには時事刻々と変化する最新のデータが保管されており、そのデータを分析することで新たなインサイトを生むことが期待されます。一方、分析のために業務データベースから分析データベースへデータを連携しようとするとデータ鮮度の低下や ETL 処理の構築・運用コストが課題として挙がります。業務データベースを分析する上ではデータ連携をいかに素早く、簡単に実現するかが重要となりますが、従来この 2 つを両立することは困難でした。 Zero-ETL 統合は ETL パイプラインなしで Aurora MySQL から Amazon Redshift へニアリアルタイムにデータを連携する機能です。Zero-ETL 統合を使用することで、これまで自前で組んでいた ETL 処理等のデータ連携の仕組みを代替し、かつデータ鮮度を簡単に向上することが可能です。Aurora 側での変更は 50 パーセンタイルが 15 秒以内に Redshift へ連携され、また更新はストレージレイヤーで行われるため Aurora 及び Redshift のコンピュートリソースへの影響は最小限に抑えられます。 デモでは、Webアプリケーションのバックエンドとして使用されている Amazon Aurora のデータを Zero-ETL 統合を使用して Amazon Redshift へ連携し、Amazon Managed Grafana を使用して可視化を行いました。 画面左側では Webアプリケーションを模した Amazon EC2 インスタンスから、 Amazon Aurora へ 1 秒ごとにデータを INSERT しています。INSERT されたデータは Zero-ETL 統合によって自動的に Amazon Redshift へ同期されます。画面右側の Amazon Managed Grafana から Amazon Redshift へクエリを行い、データがニアリアルタイムに連携されていることが確認できました。 Zero-ETL 統合を使って業務データベースを素早くかつ簡単に連携する方法についてご紹介しました。Zero-ETL 統合は本イベント実施時点ではプレビュー中でしたが、2023年11月7日より一般利用可能となっていますので是非ご活用ください。 車両走行データを活用した渋滞情報生成基盤のご紹介 パイオニア株式会社 Cross Technology Center サービス技術企画部 先行開発グループ 宮本 祥平 氏 資料ダウンロード 1937 年に国産初ダイナミックスピーカーの開発を行い翌年創業しました。音をメインにしていたところから時代の変化とともに変革していき、近年ではカーエレクトロニクス事業を基幹事業としており、「より多くの人と、感動を」を理念に事業をしてます。市販事業の中で、音声だけで操作ができる対話するドライビングパートナーである NP1 の販売が開始されました。またドライバーの運転スタイルを学習し、パーソナライズされたデバイスへと進化をします。それ以外に、近年はデータソリューション事業にも力を入れています。モビリティデータやインテリジェントカメラの映像データ、位置情報などと連携しクラウドソリューションを提供しています。 パイオニアが保有するデータとして全国道路総延長 70 万 km のデータや、走行時の定点画像データ 2 億枚、それ以外にこちらに記載のデータを保有しており、今後データを活用したサービス提供していきたいと考えています。 渋滞情報生成基盤として、2006 年からスマートループ渋滞情報のサービスを提供しています。その後さまざまなデータがアップロードされ、データ量が増えてきた一方、各サービスがサイロ化されデータが連携できていなかったため、AWS 上にデータレイクを構築し、データの集約を行いました。そして今回、新規渋滞情報生成基盤の商用化に向け開発を行いました。 ポイントは 3 つあり、リアルタイムのストリーミング処理による走行データの渋滞情報への反映速度改善、複数データソース毎の仕様差分の吸収、データ流量に応じたスケールイン/アウトです。 いくつかの車載器から点列データが AWS Lambda を介しアップロードされます。Amazon EKS のコンテナにデータを渡し、点列データからマッチングデータへ変換を行います。その際道路情報は Amazon EBS に格納をしています。別経路からは道路情報が付与されているマッチングデータがアップロードされます。これはコンテナ 2 に直接アップロードできるようにしています。その後、Amazon Aurora と Amazon Kinesis Data Firehose にデータを渡しています。Firehose からは Amazon Glue を介し、Amazon S3 上に渋滞統計データを保存しています。 いくつか改善事例をご紹介します。まずは Amazon Kinesis と AWS Lambda の部分です。走行データの渋滞情報への反映速度の改善と各走行データソースのアップロードがバラバラであったという課題に対し、Amazon Kinesis Data Streams と AWS Lambda をそれぞれのサービスにデプロイしました。それにより、随時データ処理ができたこと、後段の共通処理をそれぞれの AWS Lambda で調整ができるようになったこと、また新規データの追加が共通パターンを利用できるようになったことが改善として挙げられます。 また Amazon EKS についてですが、開発当初は EKS にするか Lambda にするか検討していましたが、マップマッチング処理が必要であった点、またその処理が高負荷かつ処理時間が長い点、EKS の方が料金割引がある点で EKS を採用しました。 次はアーカイブデータ分析についてです。こちらではリアルタイムに処理されてきた個別所要時間データを保有しています。そのデータを分析するために、Amazon Athena を用いて分析を行っています。また AWS Glue job を用いて大量データ統計処理を行い、Amazon S3 に保存しています。データの品質チェックには自作のデータチェック用の AWS Glue job を用いています。また Amazon Sagemaker を利用してデータの分析や可視化を行い、品質改善を行っています。ただし課題として、データ分析自体は自動化できていなく、確認したいデータを都度 Amazon Sagemaker で確認しなければいけない点があります。 3点目はストレージの検討です。当初左の図の様な Amazon EFS の構成を検討していましたが、Amazon EBS に地図データを配置することとしました。その際 gp3 を採用することで無料枠を超えてもファイルアクセスをすることができ、Amazon EFS と比較しコスト削減ができました。 最後は Amazon Aurora のタイプについてです。今回のシステムでは Aurora standard で実装しましたが、I/O 数が多くなり、Amazon Aurora のインスタンス料金よりも I/O 料金の方が高くなってしまいました。そこで新しい Aurora I/O-Optimized に変更することで、30-50% のコスト削減に成功しました。 今後の展望は、Amazon SageMaker Notebook 上で可視化しているものをダッシュボード化したいと考えています。その際は Amazon QuickSight の利用を考えています。また手動でデータチェックをしている部分を AWS Glue Data Quality の利用を検討しています。 まとめです。大量データのリアルタイム処理には、処理速度や I/O 数に合わせ、運用費を意識してアーキテクチャを構築すること。データの品質を保ちつつ、生成したデータの分析がしやすいアーキテクチャを構築すること。やりたいことに対し、新しい AWS サービスが対応しているかはすぐに調べること。迷ったり悩んだりした場合は AWS に相談することで方針が決まったことが挙げられます。 OpenSearch を使用したベクトル検索 アマゾンウェブサービスジャパン合同会社 プロトタイプエンジニアリング本部 プロトタイピングエンジニア 後藤 駿介 資料ダウンロード AWS の後藤からは、近年注目を集めている技術の一つであるベクトル検索を OpenSearch で行う方法についてご紹介しました。セッションの中では、ベクトル検索の基本やベクトル検索のユースケースを説明した後、Amazon OpenSearch Service や Amazon OpenSearch Serverless が持つベクトル検索機能を紹介し、最後に OpenSearch Serverless でベクトル検索をするデモを実施しました。 ベクトル検索とは、音声・画像・テキストなどのメディアの情報を機械学習の技術などを用いて数列値 (ベクトル) に埋め込むことで検索を行う技術のことを指します。埋め込みに使用される機械学習モデルでは、メディア同士近い性質を持つものは互いに近い距離のベクトルとして埋め込まれるように学習されます。そのため、テキストの検索では、伝統的に使用されてきたキーワード検索よりも、単語や文章の意味を考慮した検索が可能になります。またテキストに限らず、画像や音声などのデータに対しても、それらのメディアの類似度による検索を行うことができます。 ベクトル検索の代表的なユースケースとして、レコメンド、画像検索、RAG などがあります。レコメンドでは、商品情報やユーザー情報をベクトル化して、ユーザーにおすすめのコンテンツを推薦します。画像検索では、画像を CNN などの機械学習モデルを使用してベクトル化して、類似画像を取得します。RAG では、クエリに関連したドキュメントを取得するためにベクトル検索が使用されることがあります。 k-NN 検索とは、入力のベクトルと類似したベクトルを k 個返す検索のことです。k-NN 検索を正確に実行しようとすると、データ量に対して比例して計算量が増大しています。数万くらいのデータ量であればそれでもパフォーマンスに問題は出ませんが、更に大きな量のデータに対して k-NN 検索を実行しようとするとパフォーマンスに大きな問題が生じる可能性があります。近似 k-NN 検索では、近似的に類似したベクトルを取得することで、データ量が増大しても高速に処理できるようになります。上述したようなユースケースのアプリケーションで大規模なデータを扱う場合は近似 k-NN の使用が欠かせません。OpenSearch では近似 k-NN にも対応しており、大規模なデータに対して高速に検索することが可能です。 OpenSearch が持つ k-NN 機能は、AWS のマネージドサービスである Amazon OpenSearch Service や Amazon OpenSearch Serverless からも利用可能です。OpenSearch Service では、非近似 k-NN だけでなく、近似 k-NN アルゴリズムとして、HNSW と IVF アルゴリズムが使用可能です。また、メモリの消費を抑える手法である PQ を使用することも可能となっています。こうした選択肢があることで、お客様の要件に合わせたベクトル検索が可能になります。 また、プレビューではありますが、OpenSearch Serverless でもベクトル検索が可能となっています。OpenSearch Serverless は OpenSearch Service とは異なり、クラスターのサイジングやシャーディング戦略を考える必要なく OpenSearch を利用することが可能になります。OpenSearch Serverless でのベクトル検索は、OpenSearch Service と同様の操作で行うことができます。動画の中では、OpenSearch Serverless を起動して、データを投入して検索する流れをデモンストレーションしておりますので、ぜひそちらをご確認ください。 AWS Clean Rooms と AWS の分析・予測サービスとの親和性 アマゾンウェブサービスジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 佐藤 祥多 資料ダウンロード AWS の佐藤からは2022年の re;Invent で発表された AWS Clean Rooms についてご紹介し、AWS Clean Rooms とノーコード予測分析サービスである Amazon SageMaker Canvas とデータ可視化ツールである Amazon QuickSight を組み合わせたデモを実施しました。 AWS Clean Rooms は AWS 上でデータを安全に共有するためのデータクリーンルームを作ることができるサービスです。データクリーンルームとは、プライバシーやセキュリティが保護された状態でデータを共有することができる場を指します。昨今、企業内や組織間だけのデータ共有ではなく、企業や組織の枠組みを超えてデータ共有を行い、新しいビジネスインサイトを得るための取り組みが活発化しています。そういったビジネスニーズを満たすため、AWS Clean Rooms は AWS を利用しているすべてのお客様に手軽にデータクリーンルームを作れる機能を提供します。 AWS Clean Rooms は Amazon Athena のような SQL による操作で、共有されたデータに対して単体で分析を行うことや自身が保有するデータと組み合わせて分析を行うことができます。AWS Clean Rooms は安全にデータ共有を行うためのいくつかの機能を有しています。 コラボレーション：AWS Clean Rooms はデータ共有を行う場としてコラボレーションを作成できます。データを共有する AWS Account, データの分析を実行する AWS Account, データの分析結果を取得する AWS Account をコラボレーションに最大5つまで参加させることが可能です。データ分析の実行と結果取得は同じ AWS Account にすることも可能です。コラボレーションのオーナーはコラボレーションに参加させる AWS Account をコントロールすることで、誰が/誰に/何ができるのかを制御することができます。 生データを共有せずにデータ共有可能：AWS Clean Rooms では生データを共有せずに AWS Clean Rooms を利用するパートナーとデータ共有することが可能です。Amazon Simple Storage Service (S3) に保存され、AWS Glue Data Catalog に登録されたデータに AWS Clean Rooms は AWS Account を跨いでアクセスし、分析された結果だけをデータ共有先の Amazon S3 バケットに転送します。 分析ルールによる出力制限の設定：コラボレーションに参加しているデータ共有をする AWS Account は共有されたデータに対して特定のクエリしか許可しない分析ルールを設定することが可能です。この分析ルールを設定することで、SUM や AVG といった統計情報しか出力しない制御を実現することや、共有先が保持している ID に合致したものだけを共有先にデータ提供するといった制御を実現することが可能です。 AWS Clean Rooms で共有されたデータは S3 に保存されるため、AWS の分析サービスや機械学習サービスを利用してさらなる分析や予測を行うことが可能です。Amazon QuickSight はデータを可視化するためのマネージドな Business Intellijence (BI) ツールです。マネージドであるため BI ツールのインフラを管理しなくても良いという特徴や、様々なアプリケーションに埋め込みが可能な埋め込み機能などがあります。 Amazon SageMaker Canvas はノーコードで機械学習モデルを作成してモデルを適応できる AutoML のサービスです。こちらも AWS Clean Rooms による分析結果を活用できるサービスになっています。 このセッションでは、新規広告を打った場合の効果を予測するというデモシナリオを AWS Clean Rooms, Amazon SageMaker Canvas, Amazon QuickSight を組み合わせて実施しました。デモの詳細な中身については動画を閲覧いただけると幸いです。 まとめ これまでの事例祭りに続き、Analytics 領域の先進的な事例が盛り沢山のセミナーとなりました。 日本のお客様向けに AWS アナリティクスサービスの最新動向 を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております。 お申込みリンク 。 井形 健太郎・濱岡 洋太  

競争の激しい今日の世界でビジネスを成功させるには、優れたカスタマーサービスを提供することが不可欠です。コンタクトセンターは、多くの場合、主要な顧客接点の一つであり、通話録音は、企業が可能な限り最高の顧客体験を提供するのに役立つ貴重なツールです。インサイトに富んだ情報源を提供することで、次のような複数の目的を果たすことができます。 品質保証: 通話録音は、エージェントのカスタマーサービスの効果を信頼できる方法で評価します。エージェントのパフォーマンス、社内基準との整合性、顧客満足度などの要素を評価するために利用できます。 トレーニング: 通話録音は、新しいエージェントが様々なシナリオに慣れるための貴重なトレーニングリソースとなるだけでなく、既存のエージェントが自分のパフォーマンスを自己評価したり、マネージャーが対象を絞ったトレーニングプログラムを構築したりするための貴重なトレーニングリソースにもなります。 インサイト: 通話録音は、顧客の行動や感情に関する貴重なインサイトを提供するため、企業は顧客のフィードバックやレビューを収集したり、繰り返し発生するテーマを特定したり、マーケティングイニシアチブの影響を評価したりすることができます。 コンプライアンス: 通話録音は、顧客とのやりとりを記録し、会社の方針や手順への順守を保証することで、コンタクトセンターが規制要件を満たすのに役立ちます。 通話録音には数多くの利点がありますが、様々な管理上の課題を引き起こすこともあります。コンタクトセンターが生成する通話録音が増え続ける中、大量の蓄積データを費用対効果の高い方法で管理することが難しくなる場合があります。さらに、いくつかの業界では、通話録音の保存と維持に関して厳しい規制が課せられています。これは、特に通話録音を長期間保存することを義務付けられている企業にとって、大きな課題となる可能性があります。さらに、企業にとっては、通話録音や保有する機密情報のセキュリティと保護を確保することも不可欠です。 Amazon Connect にはフルマネージド型のネイティブ通話録音機能があり、お客様は最小限の設定とオペレーション労力で、エージェントと顧客との会話を録音して安全に保存できます。この投稿では、コスト最適化、セキュリティ、データ戦略を含む、前述のよくある課題に対処するために、Amazon Connect の通話録音に適用できる追加のベストプラクティスについて説明します。取り上げるトピックには以下が含まれます。 通話録音の偶発的または悪意のある削除からの保護 通話録音ライフサイクルの理解と管理、およびコスト最適化アプローチ 通話録音アクセスの監査 1. 通話録音の偶発的あるいは悪意のある削除からの保護 通話録音は Amazon S3 にネイティブに保存され、99.999999999%（11 個の「9」）の データ耐久性 を備えています。提供されている高い耐久性に加えて、各企業にとっては明確なアプローチを取り、これらの通話録音を悪意のあるまたは偶発的な削除や上書きから保護するための安全対策を講じることがベストプラクティスです。次のような様々なアプローチを使用できます。 IAM とバケットポリシー。 通話録音バケットに適用される バケットポリシーやユーザーポリシー はすべて、最小権限の許可モデルに準拠していることを確認してください。既存のポリシーを定期的に見直し、不要になったポリシーはすべて削除してください。お客様は IAM の 最終アクセス情報 を利用して、レビューの際に役立てることができます。 Amazon Connect のユーザーアクセス許可。 Amazon Connect インスタンス内の設定済みユーザーに、それぞれの 役割と責任に適したアクセス権限 が付与されていることを確認します。アクセス権限の範囲を必要なものだけに絞り込むのがベストプラクティスです。 バックアップ。 従来的に通話録音のバックアップを取り、保存要件に従って保存します。 AWS Backup for Amazon S3 は、AWS サービスのデータ保護を簡単に一元化および自動化できるフルマネージドサービスで、このプラクティスを簡素化するために活用できます。 通話録音に対する S3 オブジェクトロック。 多忙なコンタクトセンターでは、通話録音がすぐに蓄積されてしまいます。データのコピーを余分に作成して保存する従来型のバックアップ方法ではストレージコストが増加し、大規模になると非常に高額になる可能性があります。通話録音用バケットに Amazon S3 オブジェクトロックを組み合わせることは、一定期間の間に通話録音を偶発的または悪意ある削除から守るための費用対効果の良い代替方法となり、さらに Write-Once Read-Many (WORM) ストレージを利用することで無期限に守ることもできます。さらに、オブジェクトロックは使用しても追加コストが発生しません。詳細については、 Amazon S3 ユーザーガイド と Amazon Connect 管理者ガイド を参照してください。 2. 通話録音ライフサイクルの理解と管理 一般的に、コールセンター環境において、通話録音はライフサイクルの初期段階、つまり品質保証、エージェント評価、トレーニングと開発の一環として録音された直後に、最も頻繁にアクセスされます。通話録音が古くなるにつれてアクセス頻度は低下し、一部の録音だけが特定の長期にわたる顧客からの問い合わせや内部調査のサポートや、コンプライアンスと監査の目的のためにアクセスされます。 通話録音が典型的にどうアクセスされるかと、そのアクセスが通話録音の存続期間を通じてどのように変化するかを理解することで、大幅にコスト最適化できる可能性があります。デフォルトでは、通話録音は頻繁にアクセスされるデータ用に設計された、可用性と耐久性に優れたストレージクラスに保存されます。古くてアクセス頻度の低い通話録音を低コストのアーカイブストレージクラスに移行すると、同等に高レベルなデータ耐久性と可用性とアクセス時間を維持しながら、ストレージコストを大幅に削減できます。 Amazon S3 ライフサイクルポリシー では、個々の通話録音の経過期間に基づいて通話録音を別のストレージクラスに移動する自動化されたメカニズムが提供されています。例えばお客様は、あらかじめ決められた期間を過ぎた通話録音を、即時アクセスできる低コストのアーカイブストレージクラスである Amazon S3 Glacier Instant Retrieval に移動できます。 取り出しリクエストに対する Glacier Instant Retrieval の料金 には注意が必要ですが、典型的には大幅なストレージコストの削減幅がこれを上回ります。アクセスパターンが異なるお客様も、使用する ストレージクラス を要件に合わせて調整することで同様のアプローチをとることができます。 3. 通話録音アクセスのロギングと監査 最高レベルのセキュリティと監視を確保するには、通話録音へのアクセスに対して包括的なロギングと監査のアプローチを実装することが重要です。これにより不正アクセスを検出して防止できるだけでなく、録音にアクセスしたユーザーやアクセス日時、アクセス元の場所を明確かつ検証可能な形で記録できます。この情報は、コンプライアンス監査に使用できるだけでなく、セキュリティ調査の際にも役立ちます。 以下のいずれかのアプローチを使用することで、お客様は通話録音バケット内のすべてのアクセスを簡単に記録、監査、把握できます。 AWS CloudTrail を使用して Amazon S3 API 呼び出しを記録する。 AWS CloudTrail はユーザーやロール、AWS サービスから実行されたアクションの記録を提供するサービスです。 CloudTrail ログには、ユーザーが再生のために通話録音をいつ取得したかなど、実行された API 呼び出しに関する詳細が含まれます。サーバーレスのインタラクティブクエリサービスである Amazon Athena を使用すると、お客様は標準 SQL を使用してこれらのログを素早く分析し、貴重なインサイトを得ることができます。 Athena ユーザーガイドはすぐに使い始めるための ステップバイステップの手順 を提供しています。 サーバーアクセスログを使用してリクエストを記録する。 Amazon S3 サーバーアクセスログは、通話録音バケットに対するリクエストの詳細な記録を提供できます。こちらも Amazon Athena により標準 SQL を使用してログを分析できます。 こちらのナレッジ記事 では、すぐに使い始めるためのサンプルクエリを含むステップバイステップガイドを提供しています。 こちらのリソース では、上記のロギングオプションに関する情報を提供し、それぞれの違いを取り上げて最適な方法を判断しやすくしています。要件によっては両方を組み合わせることも可能です。 結論 このブログでは、Amazon Connect での通話録音の管理に関する一連のベストプラクティスを紹介しました。まず、偶発的および悪意のある削除から通話録音を保護するための様々なアプローチとして、アクセス許可、バックアップ、オブジェクトロックなどを確認しました。続いて、通話録音のライフサイクルと、適切なストレージクラスを活用してコストを最適化する方法を検討しました。最後に、通話録音へのアクセスを記録および監査するための 2 つの簡単な方法として、AWS CloudTrail や S3 サーバーアクセスロギングの使用方法と、Amazon Athena を使用してこれらを迅速に分析して貴重なインサイトを得る方法について詳しく説明しました。 次のステップ 通話録音のさらなる最適化についてより詳しく知りたい場合は、次のブログ記事 「Amazon Connect 通話録音のアーカイブコストを最適化するためのサーバーレスアーキテクチャ」 と 関連するコードリポジトリ をご覧になることをお勧めします。 ここで取り上げているトピックについて質問がある場合やガイダンスが必要な場合は、いつでもお手伝いします。 AWS サポートセンター からお問い合わせいただけます。エンタープライズサポートをご利用されている AWS のお客様は、サポート関連の事柄や緊急の問題のエスカレーションについて、TAM にお問い合わせください。 無料の仮想イベント、AWS Contact Center Day にご参加ください。カスタマーサービスの未来や、機械学習が顧客とエージェントのエクスペリエンスを最適化する方法などについて学ぶことができます。 今すぐ登録 » ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 翻訳はソリューションアーキテクト遠藤が担当しました。原文は こちら です。

Amazon QuickSight は、クラウドネイティブなサーバーレスビジネスインテリジェンス (BI) サービスです。ビジュアライゼーションの構築、アドホックな分析の実行、異常検知、予測、自然言語クエリなどの機械学習 (ML) 機能によってインサイトを得ることが可能です。また QuickSight は高性能なインメモリエンジンである SPICE (Super-fast, Parallel, In-memory Calculation Engine)を利用して迅速に高度な計算を実行し、ビジュアルを提供します。 BigQuery は Google Cloud のフルマネージドかつペタバイト規模のコスト効率の高い分析データウェアハウスであり、膨大な量のデータに対してニアリアルタイムでの分析を実行できます。BigQuery を使用するとインフラストラクチャの構築や管理が不要であるため、ユーザーは有益なインサイトの発見や、オンデマンドおよびキャパシティベースの柔軟な選択肢の活用に集中することができます。 本ブログでは、OAuth を通じてBigQuery のデータを QuickSight に取り込みシンプルなダッシュボードを作成するために必要な BigQuery の権限と接続の設定の詳細についてご説明します。 前提条件 以下が準備されていることを確認してください AWS アカウント Enterprise Edition の QuickSight アカウント Google Cloud アカウント BigQuery 権限の設定 このセクションは Google アカウントの管理者向けです。ユーザーが QuickSight でデータを表示するために必要となる権限を設定する必要があります。以下の手順を実行してください Google Cloud コンソールを開き、ナビゲーションペインで [IAM と管理] を選択します。 権限の設定ページが開き、プリンシパル(メールアドレス) 別、またはロール別にすべての権限が一覧で表示されます。 [アクセス権を付与] を選択します。 QuickSight にて BigQuery へのアクセスを許可する際のプリンシパルとなるメールアドレスを入力します。ユーザはこのログイン認証情報を使用して QuickSight にアクセスします。以下の例では、ユーザーは quicksight.user@gmail.com を設定しています。 [ロールを割り当てる] で、以下のロールを割り当てます BigQuery メタデータ閲覧者 (BigQuery Metadata Viewer) … プロジェクトレベルで設定します。これは、QuickSight ですべてのデータセットとテーブルを検出、表示するために必要です。 BigQuery ジョブユーザー (BigQuery Job User) … プロジェクトレベルで設定します。 ナビゲーションペインで [BigQuery] を選択します。 データセット (画像では QuickSight_Demo ) のオプションメニューを選択し、 [共有] を選択します。 [プリンシパルを追加] を選択します。 以上の手順により、ユーザーは QuickSight でデータを表示できるようになります。設定した権限に応じて、これは以前のロールのようにプロジェクトで実行することも、 データセット やテーブルのレベルで実行することも可能です。 本ブログでは、 QuickSight_Demo というデータセットを、quicksight.user@gmail.com のユーザーに、 BigQuery データ閲覧者(BigQuery Data Viewer) というロールを選択して共有します。 BigQuery からの接続詳細の取得 QuickSight との接続を開始する際に、BigQuery から以下の情報を取得することが必要です： Google Cloud アカウントのメールアドレスとパスワード プロジェクト ID データセットの地域 以下の手順で情報を収集できます Google アカウントのメールアドレスとパスワードをお持ちでない場合は、Google アカウント管理者にお問い合わせください。 プロジェクト ID を収集するには、 Google Cloud コンソール を開き、プロジェクト名を選択します。 ポップアップウィンドウで、プロジェクトの ID をコピーします。 または、BigQuery の管理者に連絡してプロジェクト ID を取得することも可能です。 Google Cloud のナビゲーションペインで、 [BigQuery] を選択します。 エクスプローラ で、QuickSight に取り込みたいデータセットを選択します。 データセット情報の データのロケーション(Data location) からデータセットの地域を取得します。画像の例では、 QuickSight_Demo をデータセットとして選択し、データのロケーションはデータセットの地域である US となっています。 または、BigQuery 管理者に連絡して、データセットの地域を確認することも可能です。 QuickSight で BigQuery のデータを分析する QuickSight で BigQuery のデータを分析するためには、 BigQuery のデータソースを作成する必要があります。以下の手順を実行します QuickSight コンソールで、ナビゲーションペインの [データセット] を選択します。 [新しいデータセット] を選択します。 Google BigQuery をデータソースとして選択します。 データソース名 に分かりやすい名前を入力します。(本ブログでは BigQuery Demo としています) 先ほど収集したプロジェクト ID と地域の詳細を入力します。 [サインイン] を選択します。 プロンプトが表示されたら、Google アカウントのメールアドレスとパスワードを入力します。 アクセスの詳細を確認し、 [続行] を選択します。 これまでの手順により、指定したプロジェクト ID とデータセットリージョンを QuickSight で管理し、BigQuery データを表示する権限が QuickSight に付与されます。 以上で Amazon QuickSight での BigQuery データソースの作成は完了です。続けて以下のステップでデータセットを作成します。 [データセット] にて、使用するデータセット ( QuickSight_Demo ) を選択します。 使用するテーブルを選択します。 (本ブログでは Sample_All_Flights を選択しています) [データの編集/プレビュー] を選択、または独自の SQL 文を使用したい場合は [カスタムSQLを使用] を選択します。 データ準備のページで、 [保存して公開] を選択し、 [発行して視覚化] を選択します。(こちらのデータは SPICE 上に取り込まれます) ビジュアルタイプを選択します。（本ブログでは、垂直積み上げ 100 パーセント棒グラフを使用します） 列を設定します。(本ブログでは、 X軸 、 値 、 グループ/色 として、それぞれ fl_date 、 origin_city_name 、 late_aircraft_delay を使用しします) 棒グラフにカーソルを合わせると、サンプルデータに基づいて Dallas/Fort Worth が May 15, 2015 に 50 %の航空機遅延を経験していることが確認できます。 ダッシュボードを公開するには、 [共有] を選択します。 本ブログで使用したデータは、今回のデモのために作成されたサンプルであり、実際の空港やフライトのデータを表現しているわけではないことに注意してください。 まとめ 本ブログでは、QuickSight にデータをインポートし、シンプルなダッシュボードを構築するためにBigQuery で必要な権限と接続情報についてご説明しました。 もしまだお持ちでなければ、次のステップとして Enterprise Edition の QuickSight アカウントを作成することをおすすめします。本ブログでは、QuickSight の基本的な機能のみをご紹介しました。QuickSight の高度なトピックに関するディスカッションや回答については、 QuickSight Community をご覧ください。 もしまだ BigQuery をご利用でない場合は、 Google Cloud Console からサインアップしてください。 翻訳はソリューションアーキテクトの守田が担当しました。原文は こちら です。 著者について Vignessh Baskaran は Amazon QuickSight のデータコネクティビティ領域を担当するプロダクトマネージャー。大規模データおよび分析ソリューションの開発において 7 年以上の経験を持つ。以前は、AWS の Sr. Sales Analytics Lead として、QuickSight を用いた包括的な BI ソリューションを構築し、AWS Worldwide Specialist Sales チームにグローバルで採用された。 Jobin George は Google の Staff Solutions Architect で、大規模データおよび分析ソリューションの設計と実装の 10 年以上の経験を持つ。Google の主要顧客や Data & Analytics パートナーに対して、技術的なガイダンスや設計に関するアドバイス、ソートリーダーシップを提供している。

この記事は Amazon EKS and Kubernetes sessions at AWS re:Invent 2023 (記事公開日: 2023 年 11 月 15 日) を翻訳したものです。 Introduction AWS re: Invent 2023 が間近に迫っており、Kubernetes とクラウドネイティブ関連のトピックに焦点を当てた全セッションが公開されました。適切なセッションを見つけて選択しやすくするために、セッションを主要な重点分野別にグループ化し、re: Invent セッションカタログへのリンクとともにリストアップしました。リンクをクリックしてから詳細ページが表示されるまで少し時間がかかることに注意してください。 見逃せないセッションの 1 つは「 CON203: Amazon EKS の未来 」です。こちらのセッションには AWS の Kubernetes 関連サービスの責任者である Nate Taber、Anthropic のクラウド責任者である Nova Dasarma、Slack のエンジニアリング担当ディレクターである Alex Demetri が出演します。Nova は Anthropic が Amazon Elastic Kubernetes Service ( Amazon EKS ) を使用して大規模言語モデル (LLM) をトレーニングした方法を紹介します。Alex は Slack が社内開発プラットフォームを Amazon EKS で標準化した方法を紹介します。Nate は最近の Amazon EKS のイノベーション、現在の重点分野、将来のロードマップの早期展望について説明します。 Expo ホール の Amazon EKS ブースまたは AWS モダンアプリケーションとオープンソースゾーン に立ち寄って、Kubernetes と Amazon EKS について AWS のエキスパートと話してみましょう。いくつかのデモンストレーションをチェックして、新しいオープンソース仲間と出会い、カスタムビルドのアーケードゲームで運試しをしてください！ プラットフォーム構築のための Kubernetes 私たちは Amazon EKS 上で、コンテナと Kubernetes を使用して革新的な開発者プラットフォームとアプリケーションを構築するお客様から常に刺激を受けています。今年の re: Invent のラインナップには、開発者が Kubernetes への移行を加速させるのに役立つ複数のセッションが用意されています。コンテナ化の取り組みを始めたばかりでも、既存のワークロードの最適化を検討している場合でも、これらのセッションでは必要な Kubernetes の知識が得られます。AWS のエキスパートに会い、同じような課題に直面している仲間とつながりましょう。 Amazon EKS がどのように Kubernetes をどんな規模のチームでも管理しやすくしているのか、一緒に明らかにしていきましょう。 CON206 | Amazon EKS で Kubernetes ジャーニーを加速させましょう (ブレイクアウトセッション) CON207 | Red Hat OpenShift Service on AWS (ROSA) を使用して AWS 上で OpenShift を実行する (ブレイクアウトセッション) CON305 | 組織全体で Kubernetes をスケーリングするための基礎 (ワークショップ) CON310 | AWS 上でのクラウドネイティブ Java (開発者向けセッション) CON311 | Amazon EKS によるプラットフォームエンジニアリング (ブレイクアウトセッション) CON327 | Amazon EKS の内部構造 (ブレイクアウトセッション) CON406 | Amazon EKS: Infrastructure as Code、GitOps or CI/CD? (チョークトーク) CON402 | Amazon EKS でのアプリケーションデプロイ: パターン、プラクティス、設計 (ワークショップ) Data on EKS (DoEKS) 大規模データ処理のパターン、生成系 AI モデルのデプロイ、 Data on EKS を使った Amazon EKS アーキテクチャのベストプラクティスを深く掘り下げます。Amazon EKS で機械学習ライフサイクルを管理するためのアプローチについて説明します。そして、Amazon EKS 上のデータを活用して生成系 AI アプリケーションを構築するワークショップを実際に体験してください。 CON309 | Amazon EKS での大規模データ処理 (ブレイクアウトセッション) CON312 | AI の未来を切り開く: Amazon EKS への 生成系 AI モデルのデプロイ (ブレイクアウトセッション) CON328 | Amazon EKS での MLOps アーキテクチャパターン (チョークトーク) CON404 | Amazon EKS でのデータを活用した生成系 AI (ワークショップ) CMP327 | Amazon EKS でのデータおよび分析ワークロードの最適化 (チョークトーク) CMP401 | Amazon EKS でコスト効率の高い Apache Spark データパイプラインを構築する (ワークショップ) コスト最適化とコストパフォーマンス クラスターの効率を最大化し、無駄を省く Amazon EKS のベストプラクティスを紹介します。Karpenter がリアルタイムのリソースニーズに合わせてノードグループを自動的にスケーリングし、コンピューティングコストを削減する方法をご覧ください。Kubernetes の支出とビジネス価値を一致させるための FinOps アプローチをご覧ください。コストを最適化することで、予算を新しい取り組みに充てることができるため、イノベーションが促進されます。環境の管理と最適化のための革新的な方法の提供を支援する AWS のエキスパートやパートナーに会いましょう。 CON306 | Karpenter: Amazon EKS ベストプラクティスとクラウドコスト最適化 (ワークショップ) CON331 | Karpenterのパワーを活用し Kubernetes のスケール、最適化、アップグレードを実現する (ブレイクアウトセッション) CON332 | Kubernetes を採用した FinOps: ビジネスイノベーションのためのコスト最適化 (チョークトーク) セキュリティ AWS では、Kubernetes ワークロードを実行するお客様にとってセキュリティが最優先事項であることを認識しています。Amazon EKS を安全にデプロイするためのツールとベストプラクティスを紹介します。クラスターを保護するために、ワークロードの分離、ネットワークポリシー、ランタイムセキュリティについて詳しく説明します。Amazon EKS を使用して初期段階から安全なソフトウェアファクトリを確立する方法を説明します。また、マルチテナントの Amazon EKS 環境におけるガバナンスとコンプライアンスのためのセキュリティ制御についても紹介します。 CON335 | Amazon EKS での Kubernetes ワークロードのセキュリティ保護 (ブレイクアウトセッション) CON334 | コンテナ環境を保護するための戦略とベストプラクティス (チョークトーク) CON302 | Amazon EKS を使用して AWS 上に安全なソフトウェアファクトリを構築する (ワークショップ) スケーラビリティ、耐障害性、接続性 お客様が Amazon EKS を使ってパフォーマンス、可用性、イノベーションの新たなスケールを実現できるよう支援することに私たちは全力を注いでいます。Amazon EKS のネットワーキング、スケーリング、エッジデプロイオプションについて学んでください。コンテナイメージの公開や、保護のための Amazon Elastic Container Registry ( Amazon ECR ) について詳しく説明します。また、Kubernetes API を拡張して AWS サービスを簡単にプロビジョニングする方法についても説明します。 CON308 | Amazon ECR によるパブリックイメージのオーナーシップの取得 (チョークトーク) CON329 | アーキテクチャに適したエッジコンテナサービスの選択 (チョークトーク) CON330 | Amazon EKS のネットワーキングの謎を解き明かす (チョークトーク) CON333 | AWS サービスをプロビジョニングするための Kubernetes API の拡張 (チョークトーク) CON405 | Amazon ECR に Dive Deep する (ブレイクアウトセッション) 直接参加できない方は、基調講演とリーダーシップセッションのライブストリームにご参加ください。 イベントに登録 すると、バーチャル専用パスを選択できます。ブレイクアウトセッションは、re: Invent の後に AWS のイベント YouTube でご覧いただけるようになります。 これらのセッションの詳細や、AWS の専門知識がお客様にどのように役立つかを知りたい場合は、AWS のアカウントチームにお問い合わせください。 ご来場またはオンラインでお会いできるのを楽しみにしています！Kubernetes を企業で使用する方法の詳細については、 Amazon EKS のウェブページをご覧ください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

本記事は Amazon Mexico FP＆A の Gonzalo Lezma によるゲスト投稿です。 メキシコの財務計画と分析（FP＆A）チームは、 Amazon Mexico に関連する計画、分析、報告について、Amazon の CFO と経営陣に戦略的サポートを提供しています。私たちは、すべてのビジネスグループの内部損益（P＆L）レポートなど、主要な財務成果物を作成および管理します。また、月次予測見積もり、年間運用計画、3年予測などの計画プロセスにも関与しています。 私たちのチームは5つの主要な課題に取り組む必要がありました。手動による定期的なレポート作成、さまざまなソースからのデータの管理、大きくて遅いスプレッドシートからの移行、ビジネスユーザーによるアドホックなデータインサイト抽出の実現、および差異分析です。これらの問題に取り組むために、私たちはビジネスインテリジェンス（BI）のニーズに合わせて Amazon QuickSight を選択しました。 この投稿では、QuickSight によって私たちが財務分析とビジネス分析に集中できるようになり、ビジネス戦略の推進に役立てるようになったかについて説明します。 定期的なレポート作成の完全自動化 データの時間当たりのボリュームが多く、ビジネスグループやサブプロダクトが複数あるために、レポートを手動で作成・管理には時間がかかります。対象となるレポートでは処理すべきデータが大量にあり、さらに多くの利害関係者を満足させる必要があります。したがって、定期報告では、レポートの作成、スプレッドシートの数式チェック、報告数値の検証といった作業に多くの人と時間を割り当てる必要があります。 QuickSight のダッシュボードでは損益（P＆L）が表示され、データベースが更新されるとすぐに数値が更新されるため、定期的なレポート作成が大幅に簡素化されます。これにより人間の介入が必要なくなり、レポート作成で誤りが発生するリスクが排除されます。現在のところ、レポート作成プロセス自動化の結果として、従来1週間かかっていたレポートのメンテナンスと仕上げ作業にかかる時間をゼロにすることができています。また、 QuickSight アラート機能（次のスクリーンショットを参照）を使用して、特定の指標が事前定義されたしきい値を超えたときに通知を行っており、損益の大幅な変化をきめ細かく把握することも可能になりました。 さまざまなソースからのデータ メキシコでは新しい市場やチャネルが絶えず出現しているため、それらすべてが財務計画システムに統合されているわけではありません。そのため、シャドー P＆L やレポートは一般的で避けられない状況にあります。そのため、チームは財務数値の正確性や一貫性を損なうことなくそれらを追跡する方法を見つける必要があり、このことはさらに大きな課題となります。さらに、複数のチャネルとチームがそれらの数値を報告しているために、すべてのチームのデータソースを手動で更新するには時間がかかります。 QuickSight では、比較的新しい財務計画システムに未反映のチャネルや製品に関するデータを読み込むことができます。チームには Amazon Redshift 、CSV ファイル、Excel スプレッドシートなど、データをロードするためのさまざまなオプションがあり、レポート対象とするデータの粒度と範囲には事実上制限がありません。 大きくて遅いスプレッドシート スプレッドシートは財務分析の一般的なツールですが、大規模で複雑なデータセットを取り扱うには限界があります。これは分析のパフォーマンス、信頼性、検証に影響します。スプレッドシートは遅く、かさばり、エラーが発生しやすくなるため、大規模なデータセットを効率的に管理することが困難になります。 QuickSight が使用する SPICE (Super-fast, Parallel, In-memory Calculation Engine) のインメモリエンジンは、チームが過去に試したTableau や Excel などの他のソリューションと比べても比類のないもので、大規模なスプレッドシートを操作する必要性を劇的に減らすことができています。チームはレポートの内容を分析し詳しい説明を行う必要がありますが、それに加え、ただレポートを読んだり視覚化したりするのにも苦労をしている状況でした。 以下に示す MX 財務計画および分析ダッシュボードは、当社の事業の商品総売上高への主要な貢献要因を示しています。グラフに示されているように、売上全体の伸びの 20.92％ に対し、9.09％ が NAFN チャネルによるものであることがわかります。以下のグラフは、どの製品が売上の増加を牽引したかを示しています。 アドホックなデータインサイトの抽出 財務分野では、特定の商品・期間における直近のトレンドに関するアドホックな財務データが必要になることが頻繁にあります。チームが取り組んでいるチャネル、製品、シナリオの数を考えると、これは取り組むべき大きな問題になります。これらのデータからインサイトを抽出するにはかなりの処理能力が必要となり、チームが集中すべき他の重要なタスクを実行する時間を奪う可能性があります。 Amazon QuickSight Q はデータに関する様々なシンプルな質問に直観的かつ迅速に回答してくれるため、チームは自然言語での問い合わせによりデータからアドホックなインサイトを得ることができます。次のスクリーンショットは、 Q を使用して送料のレポートを行う際によく取得されるグラフを示しています。 差異分析 正確でインサイトに富んだ差異分析を提供することは、財務分析に携わる人にとって大きな課題です（たとえば、ミックス効果とレート効果を分離して価格や単位あたりの利益を説明する場合など）。財務分野でこの問題に取り組む方であれば、巨大で理解しづらいスプレッドシートを目にする機会も多いかもしれません。 QuickSight URLアクション （次のgifとスクリーンショットを参照）を使用すると、分析したい差異を右クリックすることで特定の差異の詳細を説明するシートにリンクさせることができます。これにより、チームが持っていた巨大で扱いにくい Excel の差異分析ツールを代替することが可能になります。 まとめ QuickSight の導入とダッシュボードの動的かつインタラクティブな性質により、社内のユーザーはマウスをクリックするだけでデータをより深く調査・分析できまるようになりました。また、ビジュアルの作成は直感的で、インサイトに富み、そして迅速に行えます。実際、今回紹介したソリューションとツールの全体は、専任の BI チームを必要とせずに構築されました。これに加えて、私たちは顧客の QuickSight の使用状況を確認するための社内向け QuickSight ダッシュボードを作成しました。これにより、どの領域・ユーザーがよりアクティブで、どの機能がパートナーによってより多く使用されているかを完全に把握することができます。 私たちは QuickSight ソリューションにより、自動化、セルフサービス BI、リクエストへの迅速な対応、および柔軟性を実現しています。 QuickSight のダッシュボード、レポートがビジネスにどのように役立つかについて、詳しくは Amazon QuickSight をご覧ください。 記事の翻訳は Solutions Architect 宮﨑 太郎が担当しました。原文は こちら です。

Solution Architect Empowerment Team (SET) は、AWS Worldwide Specialist Organization (WWSO) 内の部門で、1,600 人のスペシャリストソリューションアーキテクトにサービスを提供しています。その主力プロダクトである OZONE は、次の 4 つの主要分野でこれらのアーキテクトを支援するために設計された、データドリブンエンパワーメントフレームワークです。 Amazon の顧客重視の価値観に則った重要な顧客活動へのフォーカス 生産性と効率性の最大化 アーキテクトの活動が AWS の顧客とサービス利用に与えたインパクトの可視化 リーダーがデータを用いて迅速で影響力のある意思決定を行うための支援 SET はさまざまな部門のさまざまな社内パートナーと協力して、専用のデータインテリジェンスツールを開発しています。これらのツールは、ソリューションアーキテクトのリーダーや関係者により早く、より価値のあるインサイトを活用できるようにすることで、広範なチームが相対するお客様の体験向上に役立ちます。 このブログ記事では、SET がインサイト配信環境を Amazon QuickSight に移行して、コスト削減とスケーラビリティを実現した方法について説明します。 様々なデータ、複雑な計算、パフォーマンスに関する課題 OZONE は、顧客エンゲージメント、トレーニングなどさまざまな AWS ソースからのデータを使用し、スペシャリストソリューションアーキテクトにデータドリブンのインサイトを提供するサービスです。 これらの強力なインサイトを提供するために、OZONE は、データセットの統合、複雑なクエリの実行、カスタム計算と視覚化を備えたダッシュボードの提供が可能な、強力なビジネスインテリジェンス (BI) ツールで動作させる必要がありました。 特に、クエリ、分析、複雑な計算の実行には各々のデータセット (200 GB 以上) を利用する必要があり、作業で利用している大規模で分散した多くのデータソースに対応したいと考えていました。データの利用にあたっては、データ収集・加工のパイプラインを介して追加のデータを取り込む必要があったため、既に保持しているクラウド資産との連携や統合も重要でした。そして、機械学習を使用してデータ分析を強化し、パターンを検出し、インサイトを得るまでの時間を短縮するなど、よりインテリジェントな方法でこれらのデータを使用できるようにしたいと考えていました。 さらに、ビジュアルのレンダリング時間短縮は優先度の高い課題でした。以前の BI ツールではダッシュボードの読み込み時間が遅く、前払いのライセンスモデルを使用していたため、より広範なユーザーに対してセルフサービス分析を提供することが困難でした。 これらすべてを念頭に置き、BI のニーズに応える代替ツールを探す時が来たと判断しました。理想的には、大規模利用でも費用対効果が高く、既存のクラウド技術スタックとうまく統合でき、より高度なデータモデリングと分析が可能なものです。 Amazon QuickSight によりBI の摩擦を軽減し、高度な機能を有効化する 新しい BI ツールを探すとき、私たちはいくつかの重要なニーズを念頭に置いていました。コスト削減や他の分野での改善が実現でき、なおかつ手頃な価格で拡張できる分析ソリューションが理想です。 2022 年 8 月、私たちは OZONE ダッシュボードを QuickSight に移行することを決定し、次のことが可能になりました。 ユーザーベースのライセンスコストからの脱却 より複雑な計算や高度な分析が可能なダッシュボードの構築 OZONE の幅広いユーザーへの公開 データパイプライン用のクラウド技術スタック ( Amazon S3 、 Amazon DynamoDB 、 AWS Glue 、 Amazon Redshift など) を活用 Amazon QuickSight Q のような高度な機能を導入、会話機能やその他の次世代機能を有効化 重要なビジネスインサイトをより早く、より確実に提示 QuickSight はデータウェアハウス向けの Amazon Redshift など他の AWS サービスと統合されており、シームレスなデータフローとより効率的な分析パイプラインの構築が可能になりました。 また、目標設定方法論 (目標や主要な結果など) に関するさまざまなビジネスユースケースを実装することもできました。KPI とメトリクスを設計し、組織、チーム、機能レベルにおける戦略的ビジネス目標に対するほとんどの進捗状況を測定することが可能です。これらの指標には、ソリューションアーキテクトのアクティビティ、Salesforce の商談価値、営業サイクルの長さ、商談勝率、製品価値、ソリューションアーキテクトのエンゲージメントメトリクスなどが含まれます。これらの洞察により、OZONE はベースライン、データトレンド、予測、What-if 分析などのデータモデルをサポートし、ソリューションアーキテクトのリーダーシップによる、より多くの情報に基づいたビジネス上の意思決定を可能にします。 OZONE Reflections / Insights ダッシュボード 私たちの OZONE エンパワーメントフレームワークは、関係者がより良い意思決定を行うために必要な深いインサイトを得られるようにするもので、「Reflections」と「Insights」という 2 つの主要なダッシュボードで構成されています。私たちは QuickSight を使用し、これらのダッシュボードをわずか 3 か月で導入することができました。 これらの高度にインタラクティブなダッシュボードにより、ユーザーはビジュアルをドリルダウンし、フィルターを適用し、分析を探索することで、より深い洞察を得ることができます。また、QuickSight にはさまざまな組み込みの視覚化オプションがあり、これらのインサイトやレポートを簡単にカスタマイズすることができます。 OZONE Reflections は、スペシャリストソリューションアーキテクト、およびソリューションアーキテクトのリーダーシップに対し、自分たちの取り組みが顧客にどのような変化をもたらすかをより明確に把握するために必要なツールを提供します。このダッシュボードでは、ソリューションアーキテクトのアクティビティをドメイン、チーム、各ソリューションアーキテクトの各レベルで分析し、定義された大目標の達成状況を確認することができます。また、アクティビティ状況から予測されるペースを計算して、ソリューションアーキテクト、チーム、ドメインが定義した目標に対してどの程度進捗しているかを把握することもできます。関係者はドメインレベルのインサイトについては Domain Reflection ダッシュボード、チームレベルのインサイトについては Team Reflection ダッシュボード、ソリューションアーキテクトレベルのインサイトについては Solution Architect Reflection ダッシュボードを参照することが可能です。 OZONE Insights は、WWSO ソリューションアーキテクトのリーダーが主要なビジネス目標の達成におけるドメインの有効性判断を可能とするための KPI とメトリクスをダッシュボードとして提供します。 このインサイトはソリューションアーキテクトの影響を測定する上でも不可欠となっており、顧客エンゲージメントや、顧客の成果を促進するその他のドメイン固有の活動への参加状況を測定することによって行われます。ダッシュボードには 5 つの主要なビジネス指標が示されています：[1] スペシャリストソリューションアーキテクトのエンゲージメント率とその商談が月間経常収益に与える影響、[2] スペシャリストソリューションアーキテクトの関与した商談の勝率と商談のサイクルタイムに与える影響、[3] トップスペシャリストソリューションアーキテクトのドメインアクティビティ、[4] どのステージで商談に参加しているか、 [5] スペシャリストの参加によって影響を受ける顧客の数 OZONE の QuickSight ダッシュボードは、AWS 財務チームが管理している Amazon Redshift クラスターからデータを取得します。複数のデータソースを利用して顧客とアカウントのデータを取得することで、ダッシュボードは顧客向けアクティビティの主要なメトリクスと KPI に関する情報をユーザーに提供できます。 OZONE は、Web アプリケーションポータルを介して、ドメイン、チーム、および機能レベルのスペシャリストソリューションアーキテクトチームからの情報を収集するため、データの消費者であると同時に作成者でもあります。私たちのデータパイプラインは Amazon DynamoDB、AWS Glue、および Amazon S3 を使用して構築されており、Amazon Redshift クラスターに統合されています。このアップストリームデータについては、ETL と airflow を介して夜間更新のサイクルを維持しています。そうすることで、QuickSight においてダッシュボードを作成する際に、常に最新のデータセットを使用し続けることができます。 以下の図は、OZONE の技術アーキテクチャと、Web アプリケーションから QuickSight へのデータフローを示しています。 また、 埋め込み分析 にも QuickSight を使用しています。QuickSight の埋め込み機能により、一元管理された Web アプリケーションポータルである OZONE Intelligence Suite にインタラクティブなダッシュボードを埋め込むことができました。 このツールにより、利用者に対して単一のビュー、つまり、ビジネスへのインパクトとソリューションアーキテクトのパフォーマンスに関するインサイトを得るのに役立つ統合データエクスペリエンスを提供することができます。 スペシャリストソリューションアーキテクト向け BI ユーザーエクスペリエンスの強化 QuickSight の様々な利点により、スペシャリストソリューションアーキテクトリーダーのユーザーエクスペリエンスが強化されました。 より高速なインサイトの獲得 QuickSight を使用すると、さまざまなデータソースを統合、分析や視覚化のための複雑な計算を準備といった時間のかかるタスクを削減し、より迅速にインサイトを得ることができます。QuickSight の活用はユーザーの時間を大幅に節約する結果に繋がりました。Amazon Redshift は、分析に必要なデータモデルを構築し QuickSight に接続して分析を行う際に役立っています。多くの Amazon Redshift データレイクのデータを簡単に結合し、分析用のデータモデルを作成できます。 より素早いデータ統合とユーザーエクスペリエンス OZONE の SPICE モードは 5,000 万件を超えるレコードの消費を加速します。SPICE の共通部分式除去 (CSE) 機能によりクエリが最適化されることでダッシュボードの読み込みや複雑な計算の結果が速くなり、全体的なユーザーエクスペリエンスが向上します。 アクセシビリティとスケーラビリティの向上 QuickSight の拡張性により、WWSO 組織内の 1,600 人のスペシャリストソリューションアーキテクト全員が、パフォーマンスに影響を与えることなく複数のデータセットに同時にアクセスできます。これにより、OZONE の提供範囲を現在のユーザーベースを超えて拡大することも可能になりました。 より速く、より自然なレポート作成とデータ視覚化 OZONE は QuickSight のオートナラティブ機能を使用しています。オートナラティブ機能は、分析の簡単な要約を説明分の形式で提供します。これにより、スペシャリストソリューションアーキテクトのリーダーは重要なインサイトを簡単に抽出し、定期的なビジネスアップデートに役立てることができます。こうした自動化された説明文はスペシャリストソリューションアーキテクトの与えるインパクトに焦点を当てているため、ビジネスレビューの文書やレポートに直接コピーできます。OZONE のダッシュボードでは、時系列データを使用したトレンドの視覚化や比較分析もサポートされており、これらの説明をさらにわかりやすいものにしています。 Q を利用した自然言語クエリ OZONE は QuickSight Q を通じて、スペシャリストソリューションアーキテクトのリーダーからの質問を解釈し、カスタムビジュアルを生成、データインサイトを迅速に得ることができます。基礎となる OZONE データセットの Q トピックは、回答精度を向上させるようにトレーニングされており、エンドユーザーは Reflections ダッシュボードではカバーされていないビジネス上の質問への回答を得ることができるようになっています。 全体的として、QuickSight は開発プロセスを合理化し、さまざまなデータセットにわたる重要なデータインサイトを統合し、スペシャリストソリューションアーキテクトのリーダーが大規模なデータをもとにタイムリーな意思決定を行えるようになりました。 OZONE チームと QuickSight チームとのコラボレーションにより、読み込み時間が短縮され、クエリ時間が最適化された、パフォーマンス効率の高いビジネスインテリジェンスダッシュボードが生まれ、ユーザーエクスペリエンスの向上を実現することができました。また、スペシャリストソリューションアーキテクトが AWS サービスの採用やさまざまなビジネスセグメントにわたるカスタマージャーニーへの影響を測定できるようになったことで、WWSO ソリューションアーキテクト組織内の運用効率が向上しました。 QuickSight ダッシュボードは美しく見えます。また、以前のツールよりも読み込みがはるかに高速です。全体として、ダッシュボードは非常に便利で、満足しています。チームのすべてのソリューションアーキテクトへの伝道はすでに始まっています 。 — WWSO SA リーダー QuickSight をはじめましょう ZONE チームでは QuickSight への移行により、組織全体にわたるデータ統合とインサイトの提供を改善することができました。 QuickSight の採用により、サービスの提供コストをはるかに抑えながら、これまで以上に多くのことを行えるようになりました。また、同時に ML 対応の分析や自然言語クエリなど、これまで以上に魅力的な高度な機能を簡単に試すことも可能になりました。 QuickSight がお客様のビジネスの費用対効果、プロセス効率、インサイト提供の向上にどのように役立つかについて、詳しくは Amazon QuickSight をご覧ください。 記事の翻訳は Solutions Architect 宮﨑 太郎が担当しました。原文は こちら です。

2023 年 7 月: この投稿の内容について正確性の確認をしました。 私たちのお客様の多くは、大規模なミッションクリティカルな SQL Server データベースに Amazon Relational Database Service (Amazon RDS) for SQL Server を使用しています。お客様は、Amazon RDS for SQL Server における大規模なデータベースを保護するための最適なソリューションを求めています。これにより、データ損失の許容範囲であるリカバリポイント目標 (RPO) と、サービスの中断からサービスの復旧までの最大許容遅延時間であるリカバリ時間目標 (RTO) の要件を満たすことができます。 データベース管理者の責任の 1 つは、会社のデータを保護することです。Amazon RDS for SQL Server には、データのバックアップとリストアに役立つ 複数のオプション があります。Amazon RDS for SQL Server を使用して大規模データベースのバックアップ戦略を立てる際には、次の点を考慮する必要があります。 データベースのサイズはどのくらいなのか？ RDS DB インスタンス上の個々のデータベースまたは複数のデータベースのどちらをリストアするのか? バックアップとリカバリの戦略には、リージョン内および リージョン間の保護 が必要なのか? 通常、Amazon RDS for SQL Server のデータを保護するには、自動バックアップまたは 手動スナップショット の使用、 AWS Backup 、 ネイティブバックアップとリストア 、またはその組み合わせなど、複数の方法から選択できます。ただし、(5 TB を超える) 大規模な SQL Server データベースを管理すると、何テラバイトもの情報が含まれることがあり、面倒な場合があります。 この投稿では、Amazon RDS for SQL Server でホストされている大規模な SQL Server データベースの 2 つのバックアップとリストアのオプションについて説明します。 ネイティブバックアップ/リストアアプローチ Amazon RDS は SQL Server データベースの ネイティブバックアップとリストア をサポートしています。RDS for SQL Server データベースのフルバックアップを作成し、そのファイルを Amazon Simple Storage Service (Amazon S3) に保存できます。その後、そのバックアップファイルを既存の RDS for SQL Server DB インスタンスにリストアできます。このバックアップファイルをオンプレミスサーバーまたは別の RDS for SQL Server DB インスタンスにリストアすることもできます。 SQL_SERVER_BACKUP_Restore オプショングループ を追加することで、Amazon RDS for SQL Server の ネイティブ SQL バックアップとリストア を有効にできます。 次の図は、ネイティブバックアップおよびリストアソリューションのアーキテクチャを示しています。 前提条件 始める前に、次の前提条件が必要です。 Amazon RDS for SQL Server インスタンス Amazon RDS for SQL Server へのアクセス許可 を持つ S3 バケット データベースを複数のバックアップファイルにバックアップする 次のコマンドを使用して、RDS for SQL Server データベースのネイティブバックアップを実行します。 exec msdb.dbo.rds_backup_database @source_db_name='database_name', @s3_arn_to_backup_to='arn:aws:s3:::bucket_name/file_name.extension', [@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'], [@overwrite_s3_backup_file=0|1], [@type='DIFFERENTIAL|FULL'], [@number_of_files=n]; @number_of_files は、バックアップが分割 (チャンク) されるファイルの数を示します。最大数は 10 です。 複数ファイルへのバックアップは、フルバックアップと差分バックアップの両方でサポートされています。値 1 を入力するかパラメータを省略すると、単一のバックアップファイルが作成されます。 大規模なデータベースのバックアップを生成する場合は、バックアップファイルを複数に分割して生成することをお勧めします。このプロセスにより、バックアップの生成時間が短縮されます。ビジネス要件が Amazon S3 から大規模なデータベースのバックアップをダウンロードすることである場合、複数のバックアップファイルをダウンロードする方が 1 つの大きなバックアップファイルをダウンロードするよりも高速です。 次のスクリプトは、gp2 ストレージと r5b.4xlarge インスタンスを使用してサンプルの RDS for SQL Server データベース (10 TB) を単一のバックアップファイルにバックアップします。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBSingleFile.bak' , @overwrite_s3_backup_file=1; 単一のバックアップファイルを使ったとき、個々の Amazon S3 オブジェクト のサイズは最小 0 バイトから最大 5 TB までの範囲であるためバックアップは次のエラーで失敗しました。 “[2022-09-09 13:26:22.083] タスクの実行が開始されました。 [2022-09-09 13:26:22.300] タスクの失敗または RDS 自動バックアップの優先バックアップウインドウとの重複のため、タスクが中止されました。 [2022-09-09 13:26:22.303] タスクは中止されました [2022-09-09 13:26:22.310] S3 にアップロードするための 524288000 バイトを超える S3 チャンクを生成できません。” この制限を回避するために、データベースを複数のファイルにバックアップする別のアプローチを採用します。この方法は、RPO と RTO を削減するためにも推奨されます。 4 つのバックアップファイルを使用して同じスクリプトを実行できます。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBMultiFile*.bak' , @number_of_files=4; 次のスクリーンショットに示すように、バックアップは正常に完了しました。 さまざまなデータベースサイズで同様のテストを実行しました。 たとえば、5 TB データベースの単一ファイルのバックアップを作成するには、次のコマンドを使用します。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak' , @overwrite_s3_backup_file=1; 次のスクリーンショットはバックアップを実行した結果を示しています。 1 つのファイルを使用した 5TB データベースのバックアップは 602 分で完了しました。 複数のバックアップファイルからデータベースをリストアする 単純なスクリプトをプロシージャとして作成、コンパイルして、それを T-SQL ツールとして使用することで大きなデータベースバックアップファイルをいくつかの小さなファイルに分割できます。 バックアップファイルからデータベースをリストアするには、 restore Database コマンド用のすべてのバックアップファイルが必要であることに注意してください。 この手順は、SQL Server バージョン 2014 以降で機能します。 複数ファイルのバックアップを使用して 10 TB データベースをリストアするには、次のリストアコマンドを使用します。アスタリスク (*) は、S3 ARN の file_name 部分のどこにでも使用できます。アスタリスクは、生成されたファイル内で一連の英数字の文字列に置き換えられます。 exec msdb.dbo.rds_restore_database @restore_db_name= 'TPCC' , @s3_arn_to_restore_from= 'arn:aws:s3:::sqlbackup-tpcc/backup/10TB/TPCC10TBbackup*' ; 次のスクリーンショットは、リストアが 470 分で正常に完了したことを示しています。 次のリストアコマンドを使用して、単一のデータベースファイルバックアップを使用して 5 TB データベースをリストアします。 exec msdb.dbo.rds_restore_database @restore_db_name= 'TPCC' , @s3_arn_to_restore_from= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak' ; 次のスクリーンショットは、リストアが 1008 分で正常に完了したことを示しています。 テスト結果 次の表は、r5b.4xlarge インスタンスを使用して Amazon RDS for SQL Server のさまざまなデータベースサイズで実行されたテストをまとめたものです。 1 TB および 5 TB のデータベースサイズのバックアップとリストアにかかる時間は、単一ファイルと比較して 4 つのマルチファイルを使用することで改善されることがわかりました。 1 つのファイルで S3 にアップロードできる最大オブジェクトは 5 TB であるため、現時点では 5 TB を超えるデータベースサイズ (例: 10 TB) を 1 つのファイルでバックアップおよびリストアすることはできません。 Test Instance Activity Type Single File (minutes) Four Files (minutes) Performance Improvement (%) 1 TB (gp2, 3 TB storage allocated) Backup 151 56 62.91 1 TB (gp2, 3 TB storage allocated) Restore 200 57 71.50 1 TB (i01-40000 IOPS) Backup 140 52 62.86 1 TB (i01-40000 IOPS) Restore 154 54 64.93 5TB (gp2, 10 TB storage allocated) Backup 602 235 60.96 5TB (gp2, 10 TB storage allocated) Restore 1008 291 71.23 5 TB (io1-40000 IOPS) Backup 601 212 64.73 5 TB (io1-40000 IOPS) Restore 991 208 79.01 10TB (gp2,16TB storage allocated) Backup N/A 663 N/A 10TB (gp2,16TB storage allocated) Restore N/A 681 N/A 10 TB (io1-40000 IOPS) Backup N/A 590 N/A 10 TB (io1-40000 IOPS) Restore N/A 470 N/A 影響を確認するために、バックアップファイルの数を 8 に増やして同様のテストを実行しました。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB8files*' , @number_of_files=8; この特定のインスタンスでは、テストしたインスタンスサイズで 4 つのバックアップファイルを使用した場合と比較して、結果にタイミングの違いはありませんでした。 最適なファイル数 はインスタンスのサイズによって異なります。たとえば、インスタンスに 32 vCPU がある場合、インスタンスを 8 つのファイルに分割する方が 4 つのファイルよりも高速になります。 スナップショットアプローチ Amazon RDS for SQL Server では、自動バックアップに加えて 手動スナップショット を取得できます。これらは DB インスタンスのストレージボリュームスナップショットであり、個々のデータベースだけでなく DB インスタンス全体をバックアップします。スナップショットバックアップにかかる時間は、DB インスタンスのサイズとクラスによって異なります。このテストでは、r5b.4xlarge インスタンスを使用しました。 私たちが気づいた興味深い結果の 1 つは、16 TB のストレージが割り当てられた 10 TB のデータベースの場合、最初の手動スナップショット (バックアップ) に約 11 時間かかったということです。ただし、スナップショットからのリストアにはわずか 23 分しかかかりませんでした。これは、データベースの RTO を短縮するのに役立ちます。 データベースインスタンスの最初のスナップショットには、データベースインスタンス全体のデータが含まれています。同じデータベースインスタンスの後続のスナップショットは増分です。つまり、最新のスナップショットの後に変更されたデータのみが保存されます。 最初の手動スナップショットの後、次のスナップショット取得にかかる時間はわずか 5 分、リストア時間は 20 分でした。スナップショットによるリストアアプローチは、他のデータベースの RPO と RTO を短縮するのにも役立ちます。 リストアされたデータベースインスタンスのステータスが利用可能になるとすぐに使用できます。 DB インスタンスはバックグラウンドでデータの読み込みを続けます。これは遅延読み込みとして知られています。迅速なアクセスが必要なテーブルに対する遅延読み込みの影響を軽減するには、 SELECT * などのテーブル全体のスキャンを伴う操作を実行できます。これにより、RDS for SQL Server インスタンスはバックアップされたテーブルデータを Amazon S3 からダウンロードできるようになります。 次の表は、初期スナップショットバックアップとリストアに関する調査結果をまとめたものです。 Test Instance Activity Type Duration (Minutes) 1 TB (gp2, 3 TB storage allocated) Snapshot_Backup 109 1 TB (gp2, 3 TB storage allocated) Snapshot_Restore 16 5 TB (gp2, 10 TB storage allocated) Snapshot_Backup 480 5 TB (gp2, 10 TB storage allocated) Snapshot_Restore 20 10 TB (gp2, 16 TB storage allocated) Snapshot_Backup 635 10 TB (gp2, 16 TB storage allocated) Snapshot_Restore 23 後片付け この投稿のリソースの使用が終了したら、不要な料金が発生しないように AWS リソースをクリーンアップしてください。具体的には、このテストで使用した RDS for SQL Server インスタンスと S3 バケットからすべてのオブジェクトを削除します。 結論 この投稿では、Amazon RDS for SQL Server でホストされている大規模な SQL Server データベースを最小限の RTO と RPO でバックアップおよびリストアする方法に関する 2 つのアプローチについて説明しました。まず、SQL Server のネイティブバックアップを使用して複数のファイルにバックアップとリストアを最適化する方法を説明しました。この方法は、単一ファイルにバックアップする場合と比較して、バックアップ時間とリストア時間を短縮するのに役立ちます。次に、手動スナップショットのアプローチとパフォーマンステストから得られた結果を示しました。 著者について Yogi Barot は、AWS のマイクロソフトスペシャリストプリンシパルソリューションアーキテクトです。さまざまな Microsoft テクノロジを扱った 22 年の経験があり、専門は SQL Server およびさまざまなデータベース テクノロジです。 Yogi は、AWS での Microsoft ワークロードの実行に関する深い AWS の知識と専門知識を持っています。 Vikas Babu Gali は、アマゾンウェブサービスの Microsoft ワークロードを専門とするシニアスペシャリストソリューションアーキテクトです。インド出身の Vikas は、クリケットをしたり、屋外で家族や友人と時間を過ごすことを楽しんでいます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

生成系 AI は、多くの企業にとって関心のある分野です。 Gartner は、2024 年までに、エンタープライズアプリケーションの 40% に会話型 AI が組み込まれると予測しています。2020 年には、この数字は 5% 未満でした。AWS では、さまざまなビジネスセグメントで生成系 AI をどのように使用できるかお客様から頻繁に聞かれます。カスタマーエクスペリエンス (CX) は特に大きな関心を集めている分野です。 この 3 部構成のブログ投稿シリーズの 第 1 部 では、生成系 AI とは何か、それが CX の状況をどのように変えているか、そしてそれがもたらすビジネス成果について説明しました。また、 Amazon Connect による 生成系 AI の活用例のデモ も紹介しました。 シリーズの第2部では、ビジネス上の課題を解決するために、他の方法と比較してどのような場合に生成系 AI を使用すべきかに焦点を当てます。また、問題提起から逆算して、ユースケースに適用できる最適なテクノロジーの決定をお手伝いします。 顧客体験の向上に向けた大規模言語モデル (LLM) の適用 ほとんどの LLM は、 基盤モデル (FM) を使用して構築されています。 FM は、広範囲にわたる一般化されたデータとラベル付けされていないデータに基づいてトレーニングされます。FM は、言語の理解、テキストや画像の生成、自然言語での会話など、さまざまな一般的なタスクを実行できます。FM は、他のモデルを構築するための基盤となります。また、FM 自体を直接使用することもできます。 LLM で作成された出力は、まるで人間が書いたかのように見えるため、カスタマーエクスペリエンスアプリケーションにおける人間とテクノロジーのインターフェースとして理想的です。ただし、他のテクノロジーと同様に、生成系 AI の使用には賛否両論があります。適切な用途を判断するには、これらを慎重に検討する必要があります。 適用機会のある領域 生成系 AI は、他の機械学習技術では簡単には実現できない顧客体験を向上させる機会を提供します。LLM は非常に柔軟です。同じモデルで、質問への回答、文書の要約、言語の翻訳、文章の完成など、複数のタスクを実行できます。自然な「人間が作成したような」コンテンツを生成できるため、定型化された情報に頼る必要がなくなり、回答を高度にパーソナライズできるようになります。生成系 AI の実際のユースケースを見てみましょう。 Amazon.com では現在、生成系 AI を使用して、1つの製品に関する複数のレビューを要約しています。以下の例では、Amazon.com は生成系 AI を使用して、ストレージキャビネットに関する 3,000 件を超えるレビューを、読みやすく、データが豊富な 1 件のレビューにまとめています。購入者は時間をかけて複数のレビューを熟読する代わりに、このまとめを見ることで、購入について迅速に決定を下すことができます。 生成系 AI は、知識集約型の自然言語処理にも使用できます。これは、 LLM がナレッジベースのアーカイブにある特定の質問に答えるために使用する手法です。これはコンタクトセンターのエージェントを補助するアプリケーションで非常に役立ちます。 以下の例では、顧客がレンタカー会社に連絡してキャンセル料について問い合わせています。 音声文字起こしを使用して、キャンセルに関する質問があったことをシステムが検出し、インテリジェント検索を使用してその質問に関連する内部文書を検索しました。そして、生成系 AI は、それらの文書から導き出された回答を要約することで、このユースケースを強化します。 エージェントが顧客に提供できるソリューションを含む簡潔な応答を生成系 AI が返しました。これにより、エージェントは複数のナレッジ記事を熟読して回答を作成するための時間を節約でき、平均処理時間 (AHT) を節約できます。 生成系 AI の活用例のデモ の中でもこのシナリオの全容を説明しています。 課題がある領域 適用機会だけでなく、生成系 AI にはいくつかの課題もあります。これには、対応の正確さ、コスト管理、スピード、使いやすさなどがあります。LLM は非常に大規模で強力なモデルであるため、他の従来の AI モデルや代替の自動化技術よりも処理速度が遅く、コストも高くなる可能性があります。また、他の方法よりもリスクが高い場合もあります。例えば、一見もっともらしく見えるコンテンツが生成されたり（ハルシネーション）、偏見が含まれていたり、会社の特定の価値観に沿っていないようなアウトプットを生み出すことがあります。アウトプットを完全にコントロールできないと、ガバナンスやコンプライアンスに影響を与える可能性があるため、それらを考慮する必要があります。 生成系 AI の課題への取り組み AWS では、設計、開発、デプロイ、運用全体を通じて責任ある AI を念頭に置いて FM を構築しています。AWS は、正確性、公平性、知的財産と著作権に関する考慮事項、適切な使用、プライバシーなど、さまざまな要素を考慮しています。これらの要素は、トレーニングデータの取得プロセス全体、FM 自体、またユーザープロンプトの前処理や出力の後処理に使用する技術 においても対処されています。AWS は、お客様からのフィードバックを基に機能を積極的に改善していますが、モデルの学習には顧客データを使用しないため、ユーザーのプライバシーとセキュリティがより強化されています。 生成系 AI の利用者としては、考慮すべき緩和戦略があります。その鍵となるのが、人間に最新情報を伝えることです。企業が生成系 AI の使用方法を学習、適用する場合は、顧客向けのユースケースではなく、社内のユースケースから始めましょう。生成系 AI モデル ( Anthropic の Claude 2 や Amazon Titan など) と直接やり取りする場合、プロンプトエンジニアリングの分野が重要になります。つまり、モデルが提供する出力を制御し、特定のニーズに合わせて出力を形作る入力を作成する方法を学ぶことです。プライバシーやセキュリティの問題に対処するには、Llama-2 などのモデルやホスト可能な他のモデルを自社サーバー上で完全にセルフホストすることを選択できます。ただし、これらの分野に重点を置き、確かな実績を持つ AWS のような信頼できるプロバイダーのマネージドサービスを使用することもできます。生成型 AI の利用者として、責任ある AI に対してできる最大の寄与できる点は、ユースケースを慎重に選択することです。 Working backwards: 生成系 AI に適したユースケースか判断する方法 Amazonでは、お客様のニーズから始めて、お客様が直面している問題の根源にたどり着くことを、「Working backwards」と呼びます。まず、ソリューションから始めるのではなく、問題から逆算して、適切なソリューションが何であるかを評価してください。次に、その業務に適したツールを見つけます (複数ある場合もあります)。問題から逆算していくうちに、その問題を解決するためのさまざまなアプローチが見つかるかもしれません。場合によっては、手動によるプロセスを採用したり、ロジックやルールを適用したりすることもあります。また、従来の AI を使用したり、生成系 AI を利用することもあります。各選択肢を詳細に説明し、その長所と短所を評価します。このプロセスは、チェックリストというよりは旅のようなものであることに注意してください。 手動プロセス — 手動プロセスでは、プロセスの各段階で人員が必要です。このプロセスは単なるデータドライバーでなく、毎回意思決定が下されるような、少量で機密性の高いワークロードや複雑なワークロードに適しています。例えば、人命の損失に関する保険金請求業務では、人間が高い判断力と共感力をもって処理することを望むでしょう。しかし、エージェントや熟練した作業者が必要でいくつかの課題があるため、手動プロセスの拡張は困難です。トレーニング、スケジューリング、人員の減少/退職の管理や人件費が、この方法を大規模に展開する際の複雑さの原因となっています。 ロジックとルール — 単純で反復的なタスクは、論理的な意思決定に基づくフローを使用して解決できます。これらには生成系 AI は必要ありません。その一例として、従来の 自動音声応答 (IVR) システムや、セルフサービス用のメニュー方式のチャットボットを使用して顧客をエージェントにルーティングすることが挙げられます。このような場合、フローは単純で、繰り返し可能で、論理的で、ルールに基づきます。この場合の利点は、コストが低く (非常にシンプルな自動化と複雑でないサービスが必要)、リスクが低い (監査/テスト/理解/変更が容易) ことです。また、多くの場合組織ですでに持っているスキルセットでもあります。このアプローチの課題は、より複雑な要件や意思決定に基づく要件には対応できないことです。 従来の AI — 問題がより複雑になり、単純なルールやロジックでは複雑になりすぎた場合、従来のAIが活躍するようになります。たとえば、IVR で従来の会話型 AI を使用してユーザーの意図を検出し、パスワードのリセットなどの簡単なタスクを処理できます。生成系 AI でも同じことができますが、ユースケースによっては、大きなハンマーを使って画びょうを打ち込むような方法になることもあります。従来の AI システムは 1 種類の仕事をするように訓練されていますが、一般的にこれは特定のタスクに対して非常にうまく機能することを意味します。特定の機能だけが必要であれば、より小規模な単一目的のモデルを実行する方が、一般的に低コストで高速です。 注目すべきは、従来のAIは、文字起こし、分類、自然言語理解などのコンタクトセンターのユースケースで依然として大きな役割を果たすということです。生成系 AI は、既存の AI ソリューションに取って代わるのではなく、より強化するものです。Amazon Connect は従来の AI をさまざまな方法で活用しており、AI を中核として開発されました。たとえば、 Amazon Connect Contact Lens は、文字起こしと理解モデルを使用してコンタクトセンターの分析を行います 。 生成系 AI — この項目で説明したいのは、生成系 AI が差別化要因となり、他に着目しているオプションに比べて大幅に改善するユースケースです。こうしたシナリオは、多くの場合、(従来の AI では実現できなかった) 新しいアウトプットを生み出すことが鍵となるシナリオです。たとえば、先ほどの Amazon.com のレビューの例から、生成系 AI は要約に優れていることがわかります。 コンタクトセンターではどうでしょうか？ A) 休暇のために予約をしているお客様からの電話の例を見てみましょう。以下は、通話の記録のスクリーンショットです。通話の書き起こしの横には、生成系 AI を使用して作成された、通話の詳細で簡潔な要約が表示されます。 通話をレビューするマネージャーやスーパーバイザーは、書き起こし全体を読む時間を費やすことなく、概要をすばやく閲覧できるようになります。 B) もう1つの複雑な例として、生成系 AI の推論機能を使用してエージェントコーチングツールを作成することが挙げられます。 このツールにより、生成された通話の書き起こしを基に、評価フォームの質問に対する答えをスーパーバイザーに自動的に回答できるようになります。下のスクリーンショットは、書き起こしのサンプルとそれに関連する評価フォームを示しています。評価フォームには、生成系 AI が提供した分析を使用した回答が自動的に入力されます。 単純な分類器とは異なり、質問には「はい」または「いいえ」以上の答えを得ることができ、答えの背後にある理由もわかります。これにより、スーパーバイザーとマネージャーは、生成系 AI が提供した答えをすばやく検証できます。その後、必要に応じてスーパーバイザーが答えを調整できます。 どちらの例でも、生成系 AI は人間によるプロセスを強化して効率を高め、スーパーバイザーやエージェントが顧客に集中できる時間を増やしています。ただし、これらのアウトプットを最大限に活用する方法についてスタッフを教育することが重要です。特定の会社やユースケースに最適なアウトプットが得られるようにシステムをチューニングするためには、ある程度の繰り返しが必要な場合があります。重要なのはこうした生成系 AI のアウトプットをやみくもに受け入れてはいけないことです。 上記の例では生成系 AI が問題を解決しましたが、すべてのユースケースに適しているとは限りません。私たちは、ユースケースの選択方法に責任を持つ必要があります。生成系 AI が適切なソリューションかどうかを判断するうえで参考になる質問をいくつかご紹介します。 このユースケースは、AI を使用するのが無責任なユースケース（不正確な出力などによる潜在的な害が価値を上回るケース）ではないか このユースケースは、既存の方法ですでに解決されており、生成系 AI に切り替えても大幅に改善される可能性が低いのではないか このユースケースは、既存のソリューションで置き換えるよりも、生成系 AI を使って強化できるユースケースなのか 実験や効果の評価にはどれくらいの初期費用がかかるのか。既存のマネージドサービスやすぐに使用できる標準の機能はないか 反復して実装を安全にテストしたり、学習する時間を確保できるか この決定を下すのにふさわしいスキルがあるか 生成系 AI は強力なツールですが、習得するには時間と投資も必要です。各ユースケースやビジネスに独自の微妙な違いがあり、検討すべき点も異なります。 結論 生成系 AI は、まだ大きな可能性を秘めた非常に新しいテクノロジーであり、成長の余地があります。生成系 AI をいち早く試すことで、新しい機能が登場したときに、適切な機会にそれを採用する準備が整います。詳細については、 AWS での生成系 AI をご覧ください。ここでは、その他の実際のユースケース、教材、 Amazon Bedrock などのテクノロジー 、そしてもちろん相談できる専門家も見つけることができます。私たちはカスタマーサービスのユースケースに適したテクノロジーソリューションを見つけるために、逆算して取り組む方法について、お客様と協力する準備が整っています。生成系 AI と Amazon Connect を使い始める方法については、アカウントチームに相談することをお勧めします。 著者について Mike Wallace は AWS でアメリカのカスタマーエクスペリエンス分野のソリューションアーキテクトをリードしています。 Gillian Armstrong はビルダーソリューションアーキテクトです。彼女は、クラウドがテクノロジーを使って問題を解決する機会をより多くの人に広げていることにわくわくしています。特に、会話型 AI などのコグニティブテクノロジーによって、人間らしい方法でコンピューターと対話できるようになったことに興奮しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

先日(2023/9/14) に開催した AWS オンラインセミナー「さあ、始めよう！ AWS が提供するサーバーレス時系列データベース」の資料・動画を公開しました。今回のセミナーでは Amazon Timestream を利用した事例や、実際のデモをご覧いただきながら時系列データの活用方法をご紹介しています。 当日、参加者の皆様には数多くの QA を頂きありがとうございました。頂いた QA の一部についても共有しておりますので、併せてご参照ください。 【資料/動画】 時系列データのユースケースと Timestream 概要 資料 ( PDF ) | 動画 ( Youtube ) Demo for Beginners – 初めての Timestream 入門 資料 ( PDF ) | 動画 ( Youtube ) Amazon Timestream 新機能紹介とデモ 資料 ( PDF ) | 動画 ( Youtube )   【QA】 Q. 時系列データ分析に Amazon Redshift を使っているのですが、Timestream との違いを教えてください。 A. Redshift は、データウェアハウス専用のリレーショナルデータベースに位置づけられます（参考： AWS が提供するクラウドデータベース ）。ポイントとしては Timestream は時系列に特化した関数が用意されているという点です。一方で Redshift はより汎用性の高い DWH 専用の RDB になりますので、時系列データに特化してシンプルにデータを扱いたい場合に Timestream をご検討いただければ思います。 Q. メモリストアからマグネティックストアに変更するのは簡単に出来ますでしょうか？ A. メモリストアの保持期間を過ぎると自動的にマグネティックストアにデータは移行されますが、一方で現時点でメモリストアの保持期限内でマグネティックストアに変換する事は出来ません。よって本日ご紹介したバックアップ機能を利用し、メモリストアのデータをマグネティックストアにリストアすることをご検討ください。 Q. テーブル作成時、それぞれのデータストアの保持期間を設定するとのことですが、マグネティックストアの保持期間が経過するとデータは削除されますか？保持期間経過後のデータを、例えば S3 の Glacier Deep Archive などに移行することは可能でしょうか？ A. 保持期間が経過すると削除されます。 Timestream の Export 機能を利用して出力したデータを S3 に移動いただくことが可能です。（参考： Amazon Timestream が Amazon S3 へのデータのアンロードのサポートを開始 ） Q. Single measure と Multi measure の使い分けを教えてください。 A. 基本的には Multi measure の利用を前提にご検討ください。一方で SELECT 対象の列が2個以下といったように少ないことが事前に把握できている場合は、クエリコストの観点で Single measure の方が良いです。 Q. Amazon DynamoDB から Timestream への移行を検討していますが、 DynamoDB 側の既存データにおいて NULL 型を許容している項目についての扱いに悩んでいます。 A. 対象が Dimension 列となる場合は NULL も許容されます。一方で Measure の場合は1つのレコードに対して何かしら値が格納されている必要があり NULL は許容されません（ Multi measure の場合は1つ以上値が入っている必要があります）。従いまして例えば NA といった値を格納することや、レコード自体を格納せずに欠損値として扱い、クエリ実行時に補完関数を利用するといったケースが考えられます。 Q. SQL を実行しないとテーブルアイテムの探索はできない、という理解で良いでしょうか？ A. 各テーブルのカラム情報はクエリエディタを利用し確認できます。一方で、テーブルに格納されているデータ自体は SQL で検索いただく必要がございます。 Q. bin関数を利用する際に、 UTC ⇔ JST の変換は可能でしょうか？ A. 現時点で Timestream では Timezone を事前に変更しておくことはできませんが、 SQL での問い合わせの際に date_add 関数で時刻計算が可能です。例えば timestamp が UTC という前提で、以下のような関数をご利用いただくと JST での出力が可能となります。 bin(date_add('hour' , 9 , timestamp ), 1d) Q. バッチロードに対応するのは CSV だけでしょうか？データを Paruqet や AVRO で用意しているため。 A. はい、現時点では CSV ファイルのみの対応になります。 Parquet や AVRO の場合は一旦 CSV に変換していただく必要がございます。 Q. バッチロードは増分追加のイメージでしょうか？洗い替えの機能もあるのでしょうか？ A. はい、増分追加となります。現時点で洗い替えはできませんので、仮に洗い替えをしたい場合はテーブル作成から再度実行いただく必要がございます。 Q. 1000万件 CSV データのロード時間はどのぐらいでしょうか？ A. ファイルの分割数やカラム数によってインポート時間は変わるため、実機にてお試しいただければと思います。尚、バッチロードのベストプラクティスが公開されているので、こちらを元にお試しいただくことを推奨致します。（参考： Batch load best practices – Amazon Timestream ） Q. DynanoDB のように検証用途でローカル PC に Timestream をセットアップして利用することは可能ですか？ A. 現時点で Timestream をローカル PC にセットアップする手段は提供していません。尚、 Timestream では一定の範囲内で無料でお使いいただくことができますので、無料利用枠でのご利用をご検討ください（参考： AWS 無料利用枠 ） Q. Timestream のユースケースにおいて IoT Application での利用がありましたが、 Timestream をデータレイクとして活用できるのでしょうか？データレイクを作る場合は Amazon S3 が望ましいのでしょうか？ A. 時系列データに特化して扱いたい場合は Timestream をデータレイクとして利用することも考えれるかとは思いますが、こちらはユースケースに依存します。例えば IoT デバイスから出力されたデータを一時的に Timestream に格納し、欠損データの補完やミリ秒から秒単位への変換作業、また時系列関数や分析関数を利用した集計作業を行なった上で、汎用データを格納する先としての S3 に流し込む、といったユースケースもあろうかと思います。このように適材適所で検討する必要がありますので、まずはお客様のやりたいことを元にアーキテクチャを一緒に検討できますので、AWSの担当者までご相談いただければと思います。   — 著者 長久保 武 データベース スペシャリスト ソリューション アーキテクト

今年は新たにAWS カスタマーエクスペリエンスチームが re: Invent 体験の向上に役立つヒントや、AWS をさらに使いやすくするためのさまざまな改善点について学ぶためのヒントを紹介します。AWS Village のキオスクにお越しください。そして以下のセッションをぜひチェックしてください。セッションでは、アプリケーション管理、インシデント対応の自動化に関するベストプラクティスを取り上げ、クラウドへの移行を加速させるために役立つ製品を紹介します。 参加する前に準備しよう AWS Console Mobile Application（AWS コンソールモバイルアプリケーション）をダウンロードして、重要なイベントを見逃さないように通知を設定 AWS Console Mobile Application では、選択した AWS リソースの表示と管理が可能で、プッシュ通知を受信して最新情報を入手したり、外出先でも AWS リソースに接続したりできます。 AWS User Notifications （AWS ユーザー通知）は、AWS Healthイベント、Amazon CloudWatch アラーム、Amazon EC2 インスタンスの状態変化などの AWS サービスからの通知を AWS Console Notifications Center(AWS コンソール通知センター)で設定して表示できるようにする新しいサービスです。100 以上の AWS サービスの通知を設定したり、カスタム通知フィルタを設定したり (たとえば、タグが = 本番稼働中であり、状態が「開始中」のバージニア北部リージョン の EC2 インスタンスなど)、通知を受け取りたいチャネル (電子メール、AWS Console Mobile Applicationへのモバイルプッシュ通知、または AWS Chatbot による Slack や Microsoft Teams などのチャットクライアントなど) を指定したり、イベント集約を有効にしたりして、関連するイベントをバンドルして生成される通知の数を減らすことができます。 AWS User Notificationの過去のブログ投稿 で詳細をご覧ください。 AWS Chatbot、AWS User Notifications、AWS Console Mobile Applicationにより、外出先でも接続状態を維持 セッションのご紹介 セッションカタログ にある以下のセッションをお気に入りに登録して、AWSの製品やサービスについて詳しく学んでください。 DOP324 | Accelerating application development with AWS client-side tools (AWS クライアントサイドツールによるアプリケーション開発の加速) 11 月 27 日午前 9 時( Pacific Time )、Caesars Forum, Level 1, Summit 221 AWS はクラウドサービスだけではありません。質の高いアプリケーションを簡単に開発できるように設計された AWS のクライアントサイドのツールとライブラリが多数あります。このchalk talkでは、開発環境で利用できるツールをいくつか紹介します。AWS アプリケーション開発を加速させるコマンドラインツール (AWS CLI)、ライブラリ (AWS SDK)、IDE 統合、アプリケーションフレームワークについて詳しく学んでください。周りのみんながアジェンダの設定を手伝ってくれるので、どのビルダーにとっても必ず得るものがあるはずです。 COP313 | Automate incident management of modern workloads using ChatOps (ChatOps を使用して最新のワークロードのインシデント管理を自動化する) 11 月 27 日午後 4 時 30 分( Pacific Time )、Caesars Forum, Level 1, Academy 416 問題への対処、システム停止の最小化、インシデント対応の改善には、迅速かつ効率的に行動することが重要です。このビルダー向けセッションでは、AWS Chatbotや AWS Systems Manager などの AWS サービスと、Microsoft Teams や Slack などの一般的なコミュニケーションおよびコラボレーションプラットフォームを使用して ChatOps を実装する方法を学びます。chat-drivenな運用ワークフローを実装して、最新のワークロードの運用上の問題の診断と修正を支援する方法をご覧ください。参加するにはノートパソコンを持参する必要があります。 COP334 | Simplify application management for operational excellence (アプリケーション管理を簡素化してオペレーショナルエクセレンスを実現) 11 月 29 日午前 10 時( Pacific Time )、Caesars Forum, Level 1, Alliance 305 アプリケーションが進化し成長するにつれ、複数のサービスにまたがる複数のアプリケーションの監視とサポートは、運用チームにとってどんどん難しくなっているかもしれません。このchalk talkでは、AWS の専門家と共に深く掘り下げて、AWS Service Catalog AppRegistry と AWS Systems Manager の機能であるApplication Managerを使用して、アプリケーション全体のオペレーショナルエクセレンスを維持する方法を学びます。AWS クラウドでアプリケーションを定義する方法を学び、それらのアプリケーションに対して運用上のアクションを実行して、コンプライアンス、コスト、パフォーマンスに関連する問題に対処し、修正する方法を探ります。 DOP220 | Simplify building applications with AWS SDKs (AWS SDK でアプリケーション構築を簡素化) 11 月 29 日午後 3 時( Pacific Time )、Wynn, Level 1, Lafite 9 AWS SDK は、アプリケーションやサービスからAWS サービスを使用する上で重要な役割を果たします。このセッションでは、AWS SDK の現状と将来について学びます。開発者体験を簡素化し、新しい機能を活用する方法をご覧ください。SDK がどのように進化し、複数の言語で一貫したエクスペリエンスを提供し、高レベルの抽象化によってより多くのことができるようになり、AWS での構築が容易になるかをご覧ください。Smithy のようなオープンソースツールを使用して AWS SDK を構築する方法と、これらのツールを使用して顧客のニーズに応える独自の SDK を構築する方法をご覧ください。 COP328 | How to manage applications at scale and innovate faster with AWS (AWS を使用してアプリケーションを大規模に管理し、イノベーションを加速する方法) 11 月 29 日午後 4 時 30 分( Pacific Time )、Caesars Forum, Level 1, Academy 407 アプリケーションをサポートするエンジニア、アプリケーションセキュリティを監視する IT 管理者、アプリケーション支出を調査する財務アナリスト、アプリケーションの信頼性を維持する運用スペシャリストたちにとって、増え続けるアプリケーションリソースを管理することはますます困難になるかもしれません。AWS のサービスとツールがどのようにアプリケーション管理を簡素化し、問題の迅速な修正、より迅速なイノベーション、時間の節約、安全なスケーリングを実現できるかをぜひご覧ください。Amazon CloudWatch でアプリケーションのパフォーマンスを管理する方法、AWS Security Hub でセキュリティ体制を改善する方法、AWS Cost Explorer でコストを最適化する方法、AWS Systems Manager でアプリケーション全体のオペレーショナルエクセレンスを向上させる方法をご覧ください。 エキスパートに会いましょう Expoの AWS Village でAWSのエキスパートと交流しましょう セッションへの参加に加えて、The Venetianホテルを会場としているExpoの、 AWS Village内 にある AWS マネジメントコンソール とカスタマーエクスペリエンスのキオスクにもぜひお越しください ( キャンパスマップ )。ホイールを回して賞品を獲得したり、AWSのエキスパートに会いましょう。 AWS マネジメントコンソール AWS マネジメントコンソールのPrincipal Product Managerである Grace Kitzmiller が、ツールバーのCloudShell、プライベートアクセス、その他のエクスペリエンスの改善などの新機能を紹介します。#AWSwishlist をお持ちいただき、AWS マネジメントコンソールのキオスクで詳細をご覧ください。 AWS Chatbot AWS Chatbot のPrincipal Product Managerである Abhijit Barde は、カンファレンス全体を通して AWS マネジメントコンソールのキオスクに出席しています。ぜひ立ち寄って、組織で ChatOps を有効にする方法を学び、彼のセッション「COP313 | Automate incident management of modern workloads using ChatOps(ChatOps を使用して最新のワークロードのインシデント管理を自動化する)」に参加してください。 Cloudscape Design System Olga MadejskaはAWS デザインシステムである Cloudscape の責任者です。カスタマーエクスペリエンスキオスクに立ち寄って、AWS マネジメントコンソールのユーザーインターフェイスと、ウェブアプリケーションを構築するためのオープンソースデザインシステムである Cloudscape の使用方法について話し合ってください。 AWS Documentation AWS Documentation 担当Senior Product Managerの Betty Liou は、カンファレンス全体を通して AWS Village の AWS カスタマーエクスペリエンスキオスクに出席しています。技術ドキュメントチームと re: Invent でリリースされる新機能の詳細をご覧ください。 PeerTalk 最後に、本ブログの著者であるRick Suttlesは個別相談の専門家として皆さんとお会いする準備ができています！ re: Inventの参加者は PeerTalk を対面で利用できるようになりました。私または私たちのチームの誰かとの１対１ミーティングをリクエストして、50以上あるグループミートアップに登録してください。 筆者 Rick Suttles 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。

VMware Cloud on AWS チームは、 AWS re:Invent 2023 でお客様とお会いできることを楽しみにしています。より速く、より費用対効果の高いクラウドへの移行方法を探しているお客様向けに、洞察に満ちたセッションをご用意しています。VMware Cloud on AWS のブレイクアウト・セッション、チョーク・トーク、ワークショップでは、移行のベストプラクティス、災害対策、モダナイゼーションなどのトピックを取り上げています。 AWS re:Invent は年間で最も包括的なクラウドコンピューティングイベントであり、活気に満ちた刺激的なコミュニティで皆様にお会いできるのを楽しみにしています。私たちのセッションをお客様のアジェンダに追加して、インスピレーションを得て学ぶ準備をしてください！ VMware は AWS パートナーであり、re:Invent Emerald スポンサーでもあります。今年のカンファレンスでは、エキサイティングなセッションを予定しています。re:Invent での VMware のプレゼンスについて、詳しくは VMware のスポンサーページ をご覧ください。 エンタープライズワークロードのブースでお待ちしています ご質問があれば、エンタープライズワークロードのブースで VMware Cloud on AWS チームが直接お答えします。以下の時間帯に、エキスポの AWS Village のブース #35 にお立ち寄りください。 11 月 28 日 — 午前 10 時～午後 12 時 11 月 28 日 — 午後 2 時～午後 4 時 11 月 29 日 — 午後 12 時～午後 2 時 11 月 30 日 — 午後 2 時～午後 4 時 (※ 時間はいずれも現地時間、太平洋標準時（PST）です。) re:Invent 2023 VMware Cloud on AWS セッション・コンテンツ ブレイクアウト・セッション AWS のエキスパート、お客様、パートナーが提供するブレイクアウト・セッションは、特定のトピックについて1時間かけて深く掘り下げた講義形式のセッションです。VMware Cloud on AWS ブレイクアウト・セッションを提供すること、そして、ハネウェルとフィリップス66の2社をステージにお招きできることを嬉しく思います。 ENT101 – An enterprise cloud journey: Speed and scale with VMware Cloud on AWS スピードと規模は、どの組織のデジタル変革においても重要な成功要因です。ハネウェルがどのようにしてデジタルトランスフォーメーションへの道を切り開き、移行前に直面していた課題を克服したかを知ることができます。VMware Cloud on AWS を使用して、既存のハードウェアをどのように使用し、アプリケーションを書き直さずに移行し、既存のスキルを最大限に活用できるかをご覧ください。このセッションに参加して、厳しい期限が迫っている大規模な移行に取り組む方法について、AWSとハネウェルの双方のベストプラクティスを学びましょう。 太平洋標準時 11 月 28 日 — 午後 12 時 30 分 — 午後 1 時 30 分 | MGM Grand 120 | アジェンダに追加 ENT102 – Fueling resilience: Phillips 66’s journey with VMware Cloud on AWS 変化を乗り越え、イノベーションを受け入れることは、ビジネスを成功させるために不可欠です。複雑なクラウド移行に取り組み、データ保護を確保し、レガシーシステムに囲まれた業界において競争力を獲得する方法について、AWS と フィリップス66から直接話を聞くことができます。フィリップス66の迅速でスケーラブルなクラウド運用の過程からインスピレーションを得て、ご自分の移行に適用する方法に関する実践的なヒントを学んでください。 太平洋標準時 11 月 29 日 — 午前 8 時 30 分 — 午前 9 時 30 分 | MGM Grand 120 | アジェンダに追加 チョーク・トーク チョーク・トークは、少人数の参加者で行われる、非常にインタラクティブな1時間のセッションです。それぞれが AWS のエキスパートによる短い講義から始まり、その後、聴衆との質疑応答が行われます。VMware Cloud on AWS のエキスパートは、技術的なディスカッションに参加して、お客様のあらゆる質問に喜んでお答えします。 ENT209 – Are you well-architected? Enhance VMware workload migration with AWS VMware ワークロードのクラウド準備状況を評価し、依存関係を特定する方法を学べます。AWS Well-Architected フレームワークを使用して堅牢な移行計画を作成し、そのフレームワークの 6 つの柱をワークロード設計に適用する方法をご覧ください。AWS のエキスパートに相談して、耐障害性、拡張性、費用対効果の高い設計に関する重要な考慮事項を見つけながら、自信を持って VMware ワークロードをクラウドに移行できるようになります。 セッション 1: 太平洋標準時 11 月 29 日 — 午後 4 時 30 分 — 午後 5 時 30 分 | MGM Boulevard 169 | アジェンダに追加 セッション 2: 太平洋標準時 11 月 30 日 — 午後 12 時 30 分 — 午後 1 時 30 分 | MGM Grand 101 | アジェンダに追加 ENT320 – Advanced hybrid network architectures for VMWare Cloud on AWS オンプレミスと VMware Cloud on AWS の間で vSphere ベースのハイブリッド環境を運用する予定がある、または現在実行している場合は、AWS Direct Connect、AWS Site-to-Site VPN 、AWS Transit Gateway 、および VMware Transit Connect を使用して堅牢なネットワークアーキテクチャを構築する方法をご覧ください。セキュリティアプライアンスによる入出力セキュリティ、カスタム Tier-1 ゲートウェイによるマルチテナンシー、マルチエッジ SDDC による帯域幅のスケーリングなどの高度な概念について、詳しく学んでください。 太平洋標準時 11 月 29 日 — 午前 10 時 30 分 — 午前 11 時 30 分 | MGM Premier 320 | アジェンダに追加 ワークショップ ワークショップは 2 時間のインタラクティブなセッションで、少人数のチームで AWS サービスを使用して実際の問題を解決します。各ワークショップは、メインスピーカーによる短い講義（10～15分）から始まり、残りの時間はグループでの作業に費やされます。ご自分のラップトップを忘れずにお持ちください。 ENT313 – Deep dive into backup and data protection for VMware Cloud on AWS ハイブリッドクラウド環境を採用する上では、強固なバックアップおよびデータ保護戦略を確立することが重要です。AWS 責任共有モデルによってクラウド上で信頼できるセキュリティを実現する方法についてエキスパートの話を聞いてください。実践的な演習を通じて、AWS Backup がワークロードの保護と信頼性の高い移行にどのように役立つかを学べます。参加にはご自身のラップトップが必要になります。 セッション 1: 太平洋標準時 11 月 27 日 — 午後 2 時 30 分 — 午後 4 時 30 分 | Caesars Forum Summit 216 | アジェンダに追加 セッション 2: 太平洋標準時 11 月 29 日 — 午後 3 時 00 分 — 午後 5 時 00 分 | Mandalay Bay Islander I | アジェンダに追加 ENT329 – Scale VMware Cloud on AWS without adding nodes 追加のストレージサービスを使って VMware Cloud on AWS SDDC を拡張する、実践的なスキルを身に付けましょう。実践的な演習を通じて、さまざまなユースケースに適したストレージオプションを特定し、クラウドインフラストラクチャを最適化する方法を学ぶことができます。AWS のエキスパートが、VMware Cloud Flex Storage、Amazon FSx for NetApp ONTAP、Amazon FSx for Windows File Server、および AWS DataSync によるストレージアーキテクチャの作成について、順を追って説明します。参加にはご自身のラップトップが必要になります。 太平洋標準時 11 月 30 日 — 午後 2 時 00 分 — 午後 4 時 00 分 | Caesars Forum Summit 228 | アジェンダに追加 AWS re:Invent 2023 でお会いしましょう VMware Cloud on AWSチームは、AWS re:Invent 2023 で皆様にお会いすることを楽しみにしています。会場のさまざまな洞察に満ちた体験を通して、ラスベガスで皆様とご一緒できるのが楽しみです。 VMware Cloud on AWS が、クラウドへの移行をより速く、安全で、費用対効果の高い方法で実現する方法について詳しくは、当社の Web サイトにアクセスして、最新情報をフォローしてください。 VMware Cloud on AWS Web サイト (AWS) VMware Cloud on AWS Web サイト (VMware) この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。