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

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

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

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

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

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

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

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

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

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

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

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

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

長年にわたり、小売業は新技術の出現によって大きな変化を経験してきました。バーコード、e コマース、携帯電話などがその例で、これらはすべて、買い物客が小売業者から購入する方法に大きな影響を与え、その度に消費者の期待を一新してきました。(同じことが、スーパーマーケット・フォーマットやモールのような非技術的な発明にも言えますが、ここでは技術のみにフォーカスします)。自社のビジネスに利益をもたらすため、新たなトレンドに敏感な小売業者はこうした進歩を受け入れ適応しようとします。 以下は、小売業に大きな影響を与えることが予想されるな 4 つのテクノロジーの概要です。小売業に特化したユースケースやソリューションなど、その他の詳細については、 Seismic shifts in Retail をご覧ください。 生成系 AI と機械学習 生成系 AI（人工知能）と機械学習テクノロジーは、小売業界に変革をもたらす可能性を秘めた強力なツールとして登場しました。これらの技術は、小売業者がデータを分析し、顧客の行動を理解し、情報に基づいた意思決定を行う方法に革命をもたらしています。これらのテクノロジーを活用することで、小売業者は貴重な洞察を引き出し、パーソナライズされた体験を提供し、業務のさまざまな側面を最適化することができます。 機械学習とは、システムがデータから学習し、時間とともに性能を明示的なプログラミングなしに改善できるようにするアルゴリズムを用いることを意味します。機械学習では、システムがデータから導き出されたパターンや洞察に基づいて、自動的に分析したり、予測や意思決定を行うことができます。小売業者は、 予測 や パーソナライゼーション などを最適化するために、様々な用途で機械学習を利用してきました。 機械学習の一種である 生成系 AI は、画像、動画、テキスト、あるいは仮想環境全体など、新しいコンテンツを生成するためのアルゴリズムとモデルの使用を指します。これらのモデルは、既存のデータパターンから学習し、元のデータに似た新しい出力を作成することができます。 Web 3 と空間コンピューティング ブロックチェーン や暗号通貨のような分散型テクノロジーを特徴とする Web3 は、仮想共有空間であるメタバースとともに、デジタル環境を再構築しつつあります。これらのテクノロジーが進化を続ける中、小売業界は大きな変革の崖っぷちに立たされています。小売業者は、没入型テクノロジーを活用してバーチャルな店頭を作り、顧客が商品を探し、バーチャルで試し、斬新な方法でブランドと関わることができるようになります。 コンピュータービジョンとセンサー コンピュータービジョンとセンサー技術は近年大きく進歩し、実店舗の真のデジタル化に貢献しています。コンピュータービジョンには、機械が視覚データを解釈し理解できるようにするためのアルゴリズムと人工知能の使用が含まれます。 物体検出、顔認識、画像分類 、追跡など、さまざまな機能が含まれます。センサーは、光、温度、動き、近接などの物理的な入力を検出・測定するデバイスです。小売業では、棚、ショッピングカート、店舗入口、ドレッシングルームなど、さまざまな場所にセンサーを配置してデータを収集し、リアルタイムのモニタリングを可能にします。 小売業者は、 顧客の動線パターンに関するデータを収集 するだけでなく、 Amazon の Just Walk Out テクノロジー を利用することで、会計時の無駄の多くを取り除くことができます。 コンポーザブルコマース デジタル革命は小売業界を変革し、新たなビジネスモデルと消費者の期待を可能にしました。競争力を維持し、進化する顧客の需要に応えるためには、小売業者は革新的なアプローチを採用しなければなりません。コンポーザブルコマース は、小売業者が迅速かつ効率的に適応できるようにする有望な戦略として登場しました。コンポーザブルコマースとは、マイクロサービスと呼ばれるあらかじめ構築された独立したコンポーネントを組み合わせることで、デジタルコマースエクスペリエンスの構築と変更を可能にする手法です。これらのマイクロサービスには、商品カタログ管理、チェックアウトプロセス、決済ゲートウェイ、パーソナライゼーションエンジンなど、さまざまな機能を包まれています。これらの機能を切り離すことで、小売業者は マイクロサービスやコンテナ 、 Amazon API Gateway 、 AWS AppSync などのサービスを利用して、柔軟でスケーラブルなコマースアーキテクチャを構築することができます。 AWSはどのように役立ちますか？ AWS は、問題の最終的な解決策を描き、その目標達成に必要なタスクを決定していくため、小売業者と一緒に課題から逆算して取り組みます。 AWS は、小売の文脈でこれらのテクノロジーを常に探求していて、変革に関心のある小売業者と一緒に挑戦することに意欲的です。 結論 ここまで見てきた 4 つの技術領域の中で、機械学習は深層学習や 生成系 AI、そして最終的には人間の能力を凌駕する自律システムである人工知能のような分野は、小売業にとって最大の可能性を秘めています。その性質上、機械学習テクノロジーは「学習」し、改善し続けます。しかし、他のテクノロジーも素晴らしい影響を与えるため、小売業者はこの 4 つすべてに注意深く追随し、どのユースケースが自社にとって最大の価値をもたらすかを見極める必要があります。 これらのテクノロジーの詳細については、小売業向けのユースケース、メリット、ソリューションを紹介した電子書籍 Seismic shifts in Retail をダウンロードしてください。AWSがどのように貴社のビジネスを加速させることができるか、 AWS 担当者 にお問い合わせください。 さらに読む 生成系AIが小売業にもたらす好影響 コンピュータービジョンにより通路やレジカウンターの顧客の動きを追跡 AWS 上でモダンなコマース MACH ソリューションを構築する 没入型コマースが商品を素晴らしく見せながら持続可能性の目標をどのように推進できるか コンセプトから構築：Just Walk Out テクノロジーが消費者にショッピングの新たな理由を与える方法 David Dorf David Dorf は、AWS のワールドワイド・リテール・スペシャリストとして、小売業向けソリューションの提供に注力しています。David は以前、Infor Retail、Oracle Retail、360Commerce、Circuit City、AMF Bowling、Schlumberger のリテール＆バンキング部門で、様々なテクノロジーを使ったリテールシステムの開発に携わっていました。また、NRF-ARTS の技術標準に数年間携わり、現在も Retail Orphan Initiative の慈善活動を支援しています。バージニア工科大学とペンシルベニア州立大学で学位を取得しています。

Amazon QuickSight はハイパースケールの統合ビジネスインテリジェンス ( BI ) でデータ主導型組織を強化します。QuickSight を使用すると、すべてのユーザーが同じ情報源を共有し、インタラクティブダッシュボード、ページ分割レポート、埋め込み分析、自然言語クエリを通じて、さまざまな分析ニーズに対応できます。 データセットパラメータ は、ダッシュボードでインタラクティブな体験を作成するのに役立つ、QuickSight の新しい種類のパラメータです。この投稿では、データセットパラメータとは何かを深く掘り下げ、データセットパラメータと分析パラメータの主な違いを説明し、データセットパラメータのさまざまな使用例とその利点について説明します。 データセットパラメータの概要 データセットパラメータについて詳しく説明する前に、まず QuickSight 分析パラメータ について説明しましょう。 QuickSight 分析パラメータは、アクションやオブジェクト間で値を連携できる名前付きの変数です。パラメータは、インタラクティブなダッシュボードを構築するのに役立ちます。QuickSight 分析では、パラメータを他の機能と関連付けることができます。例えば、ダッシュボードユーザーは、コントロール、フィルター、アクションを使用して複数の場所でパラメータ値を参照できます。また、計算フィールド、説明文、動的タイトル内でも参照できます。関連付けを行うと、ダッシュボード内の各ビジュアルは、ユーザーによるパラメータ値の選択に応じて動作します。パラメータは、あるダッシュボードを別のダッシュボードと接続するのにも役立ち、ダッシュボードユーザーは別の分析に含まれるデータにドリルダウンすることができます。 一方、 データセットパラメータ はデータセットに対して定義する変数です。データセットパラメータを使用すると、作成者は、 SQL を介して外部のデータソースとリアルタイム接続されているダッシュボードの操作性や読み込み時間を最適化できます。閲覧者がデータを操作すると、コントロール、フィルター、ビジュアルでの選択やアクションの内容が、カスタム SQLに埋め込まれたパラメータとしてリアルタイムにデータソースへ伝播されます。複数のデータセットパラメータを分析パラメータに紐づけることで、ユーザーはコントロール、ユーザーアクション、パラメータ化された URL、計算フィールドのほか、動的なビジュアルのタイトルやインサイトを使用して、さまざまな体験を構築できます。 以下の例では、ニューヨークでのタクシー乗車に関するデータを含むテーブルに対し、直接クエリ接続形式でデータセットを作成しています。カスタム SQL に WHERE 句を追加することで、乗車日に基づきデータセットをフィルタリングできるようにします。乗車日は後ほどダッシュボード閲覧者によって指定されます。SQL では <<$pPickupDate>> パラメータで指定された値と pickupdate 列の値が一致する行のみが抽出されます。これにより、特定のタクシー乗車日のデータのみに関心があるユーザーにとって、データセットのサイズを大幅に小さくすることができます。 以下コードを参照してください。 SELECT * FROM nytaxidata WHERE pickupdate = <<$pPickupDate>> ユーザーがパラメータに複数の値を入力できるようにするには、複数値のパラメータ （例えば pPickupDates ）を作成し、そのパラメータを次のように SQL の IN 述語に挿入します。 SELECT * FROM nytaxidata WHERE pickupdate in (<<$pPickupDates>>) データセットパラメータのユースケース このセクションでは、データセットパラメータを使用する一般的なユースケースとその利点について説明します。 直接クエリで最適化されたカスタム SQL データセットパラメータを使用することで、カスタム SQL で得られる柔軟性と、最適化された SQL で得られるパフォーマンスの両方のメリットを享受することができます。パラメータ化されたデータセットはロードされる際、比較的小さな結果セットにフィルタリングされます。作成者や閲覧者は、分析やダッシュボードの初期表示時、パラメータのデフォルト値を使用することで高速に読み込むことができます。さらに、後ほどダッシュボードのフィルターコントロールを使用しデータを細かく分析する際にもパラメータが適用されます。データ所有者としても、データセットによりバックエンドのデータベースに対する処理負荷を軽減し、スケーラビリティやパフォーマンスの向上を図りユーザーの同時実行性を上げることができます。 特に副問合せ内でデータをフィルタリングするようなネスト化されたクエリなど、複雑なカスタム SQL を含む直接クエリの場合、パフォーマンス向上効果はより明確になります。 分析全体で再利用可能な汎用データセット データセットのパラメータにより、データセットをさまざまな分析で広く再利用できるようになり、データ所有者がデータセットを準備して管理する労力を軽減できます。 SPICE データセットでも直接クエリデータセットでも、データセットパラメータを使用することにより、計算フィールドの参照パラメータを分析からデータセット側に移植できます。データセット所有者が作成したパラメータについて、分析作成者は複数の分析ごとに都度参照する計算フィールド作成するのではなく、データセット内にある計算フィールドとして再利用できるようになりました。 パラメータに依存する計算フィールドを分析からデータセット側に移植するオプションを選択すると、データセットに計算フィールドを作成して複数の分析で再利用することができます。これはガバナンスを重視するユースケースで有効です。データセット所有者は、パラメータに依存する計算フィールドを分析から分離し、分析の作成者が計算フィールドを変更できないようにすることでビジネスロジックを保護できます。 静的変数によるデータセットの保守性向上 カスタム SQL や計算フィールドの複数箇所で静的な値（プレースホルダー）を参照するデータセットがある場合、データセットパラメータを作成し複数箇所で再利用できるようになりました。これによりコードの保守性が向上可能です。 （ただし、カスタム SQL へのパラメータ挿入は直接クエリでのみ可能である点に注意してください。） ソリューション概要 このシナリオでは、まずデータセットパラメータなしでカスタム SQL 直接クエリデータセットを作成し、最適化されていない SQL が生成されることを確認します。そしてデータセットパラメータを使用しない場合、カスタム SQL がどのように実行されていくかをデモを通して観察します。次に、カスタム SQL を変更してデータセットパラメータを追加し、データセットパラメータを使用した場合に同じデータセットに対し、最適化されたクエリが生成されることを示します。 なお、この例では、データベースとして Amazon RDS for PostgreSQL を使用しますが、この機能は QuickSightで利用可能なその他のSQLベースのデータソースでも動作します。 分析パラメータを使用してデータをクエリする データソース、データセット、分析をセットアップするには以下手順を実行します。ご自身のデータを使用する場合は、次のセクションに進んでください。 QuickSight のデータソースを作成します。 次のスクリーンショットはデータソース接続の詳細を例示しています。 直接クエリのカスタム SQL データセットを作成します。 今回、 NYC OpenData で公開されているニューヨークのタクシー乗車データの部分集合である約100万件のレコードをサンプルとして使用します。データは nytaxidata と命名された RDS for PostgreSQL データベース上のテーブルにロードされています。 作成したデータセットを使いサンプルの分析を作成します。 ビジュアルからテーブルを選択し、いくつかの項目を フィールドリスト から追加します。 分析をリロードして、 PostgreSQL データベース上で生成されたクエリを確認します。 以下の RDS Performance Insights のスクリーンショットに示されている通り、データセット全体が読み込まれていることが分かります（ select * from nytaxidata ）。 QuickSight の分析にパラメータにリンクされたフィルターコントロールを追加します。その上で、このフィルターコントロールの値を任意のものに変更します。 データセットで定義したカスタムSQLは副問い合わせで使用され、Where句がありません。フィルター用のパラメータは引き続き主問合せ側の WHERE 句として使用されているため、カスタム SQL は副問合せとして結果セット全体をフェッチしてしまいます。カスタム SQL クエリではなく、データベーステーブルそのものをデータセットとして使用した場合は、そうならない可能性があります。テーブルを直接基にしたデータセットでは、パラメータ値は WHERE 句でデータベース側に引き渡されます。 では、カスタム SQL データセットの WHERE 句にパラメータを含められない課題を克服するにはどうすればよいでしょうか。データセットパラメータを使えばいいのです！ データセットパラメータを使用してクエリを最適化 データセットパラメータを使用して、より最適化されたクエリをデータベースに送信できるシナリオをいくつか見てみましょう。 まずデータセットパラメータ（例： pDSfareamount ）を作成し、カスタム SQL の等号演算子を使用した WHERE 句に追加します。データベースに渡された SQL に変化がないか確認します。 今回は、副問合せ（ select * from nytaxidata where fare_amount=0 ）の WHERE 句にデフォルト値を使用して最適化されたSQLが生成されていることが分かります。これにより、直接クエリデータセットのクエリパフォーマンスが向上します。 データセットパラメータと分析パラメータの紐づけ データセットパラメータは分析パラメータに紐づけることもでき、ダッシュボードのインタラクションからユーザーが選択した値をデータセットパラメータに引き渡すことができます。 また単一の分析パラメータを複数のデータセットパラメータに紐づけることもできます。親となる分析パラメータをフィルターコントロールまたはアクションと連携し、カスタム SQL に基づき複数のデータセットをフィルタリングできるようになりました。 このセクションでは、データセットパラメータを分析パラメータに紐づけ、フィルターコントロールと関連付けします。 まず、分析パラメータを作成し、それをデータセットパラメータに紐づけます（これまでに作成したデータセットパラメータを使用します）。 これで分析パラメータ（この例では pAfareamount ） が作成されます。パラメータコントロールを使用し、分析またはダッシュボードからデータセットのパラメータ値を動的に変更するために、コントロールオブジェクト Fare Amount を作成します。 pAfareamount を QuickSight のフィルターと関連付けることで、データセットパラメータに値を動的に渡すことができます。パラメータコントロールの値を変更すると、バックエンドのデータベースに対し副問合せ内に WHERE 句が含まれる最適化された SQL が生成されます。 データセットパラメータのさらなる使用例 これまで等号演算子を使用したデータセットパラメータの使い方を見てきましたが、データセットパラメータを使用する別のシナリオをいくつか見てみましょう。 次のスクリーンショットは、カスタム SQL 内で比較演算子を用いたデータセットパラメータの使用方法を示しています。 次の例は、2 つのデータセットパラメータを BETWEEN 述語とともに使用する方法を示しています。 次の例は、計算フィールド内でデータセットパラメータを使用する方法を示しています。 データセットパラメータはユーザー定義したスカラー関数（ UDF ）で使用することもできます。次の例では、 pickupdate をパラメータとして受け取り、 pickupdate が祝日かどうかに基づき 0 または 1 のフラグを返す is_holiday(pickupdate) というスカラー関数を定義しています。 さらに、データセットパラメータを使用して計算項目を導出することもできます。次の例では、実行時に指定された値と乗客数に基づき動的に surcharge_amount を計算しています。データセットパラメータを CASE 文とともに使用することで求めるべき surcharge_amount を導出していることが分かります。 最後の例は、分析でパラメータを使用している計算を、データセット側に移動して再利用する手順を示しています。 データセットパラメータの制約 QuickSight でデータセットパラメータを操作する際に生じる可能性のある既知の制約は次の通りです（この原文記事の執筆時点）。 データセットパラメータは SPICE に保存されているデータセットのカスタム SQL には挿入できません。 動的デフォルトは、データセットを使用している分析の分析ページでのみ設定できます。データセットのレベルでは動的デフォルトを設定することはできません。 データセットパラメータに紐づけられている分析パラメータの複数値コントロールではすべて選択オプションがサポートされていません（ただし、 ワークアラウンド はあります）。 データセットパラメータではカスケードコントロールがサポートされていません。 データセットパラメータは、データセットが直接クエリを使用している場合にのみ、データセットフィルターとして使用できます。 ダッシュボード閲覧者がレポートを電子メールで送信するようスケジュールする場合、選択したコントロールは電子メールに添付されたレポート内のデータセットパラメータに反映されません。代わりにパラメータのデフォルト値が使用されます。 より詳細な情報は Amazon QuickSight でのデータセットパラメータの使用 をご参照ください。 まとめ この投稿では、 QuickSight のデータセットパラメータを作成して分析パラメータに紐づける方法を説明しました。データセットパラメータは、最適化された SQL を生成することで、直接クエリ形式のカスタム SQL データセットを使用している QuickSight ダッシュボードのパフォーマンス向上に役立ちます。また、 SQL 比較演算子や計算項目、ユーザー定義されたスカラー関数、CASE文などでデータセットパラメータを使用する例もいくつか紹介しました。 データセットパラメータにより、データセットの所有者は、パラメータに依存する計算フィールドをデータセットレベルで一元的に作成および管理できます。このような計算フィールドは複数の分析で再利用でき、分析作成者が改ざんすることはできません。 QuickSight のデータセットパラメータが皆様のお役に立てば幸いです。我々は既にこの機能がさまざまなユースケースで創造的に活用されている様子を見てきました。既存 QuickSight 環境内の直接クエリ形式のカスタム SQL データセットを確認して最適化できそうな候補を探すか、データセットパラメータのその他の利点を享受できないかご検討頂くことをお勧めします。例えば、パラメータとして異なる値を持つ共通データセットに対し、さまざまなスライス分析（例えば、地域、製品、業種別顧客などの切り口での分析）を行う際、データセットパラメータを用いることでデータセット再利用の恩恵を享受することができます。 レガシーレポートを QuickSight に移行することを検討しているでしょうか？データセットパラメータは、企業の BI 開発者が既にパラメータ化された SQL を含むレガシーレポートを移行する際の作業負荷を軽減するのに役立ちます。これらの SQL は、QuickSight API によりパラメータとともに QuickSight データセットとして自動的に引き継ぐことができます（パラメータでエラーマークが表示された場合はクエリを多少調整することもできます）。 データセットパラメータの詳細については、 Amazon QuickSight でのデータセットパラメータの使用 を参照してください。 また是非 Quicksight コミュニティ に参加してQuickSightについて、質問したり、回答したり、他の人と一緒に学んだり、その他のリソースを探索したりしましょう。 このブログはソリューションアーキテクトの中嶋理人が翻訳しました。原文は こちら です。

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

はじめに このブログ記事は、 AWS IoT SiteWise での設備総合効率 (OEE) の使用に関するシリーズの第2回目です。この投稿では、AWS IoT SiteWise のネイティブ機能を使用して OEE を計算し、エンドツーエンドのソリューションとして計算値を収集、保存、変換、表示する方法を詳しく説明します。このプロセスを説明するユースケースとして、空港に設置された手荷物処理システム (BHS) を取り上げます。ユースケースの詳細については、まずこのシリーズのパート1、「 AWS IoT SiteWise による総合設備効率（OEE）ガイド 」をお読みください。 さらに、OEE 要素を自動化して、製薬、食品、飲料業界の製造生産ラインなど、他の多くのユースケースでこのソリューションの実装を効率化する方法についても説明します。このブログで説明されている概念を実践しやすいように、合成データを AWS IoT SiteWise にストリーミングし、本ブログで説明する計算を使用して OEE ダッシュボードを作成できるコードリポジトリも提供しています。 ユースケース OEE の計算を掘り下げる前に、基準系として使用する例を確認しましょう。この例は BHS で、OEE 計算に必要なデータポイントは、荷物を運ぶ回転式コンベア（カルーセル）内の BHS に設置されたハードウェアから収集されます。ハードウェアは4つのセンサーで構成されています。モーター監視用の振動センサー2つ、コンベア監視用のスピードセンサー1つ、手荷物の処理量をカウントする光電センサー1つです。 ソリューションのアーキテクチャは次のとおりです。 センサーデータは、AWS パートナーの CloudRail を通じて収集および整形されます。CloudRail のソリューションを利用すると、IIoT データの収集と AWS IoT SiteWise へのストリーミングが大幅に簡素化されます。この統合は、 CloudRail 管理ポータル から直接設定できます。このアーキテクチャには、センサーデータを S3 バケットを経由して他の AWS サービスで利用できるようにするための追加コンポーネントが含まれています。 AWS IoT SiteWise の前提条件 データを AWS IoT SiteWise に送信する前に、 モデルを作成し てそのプロパティを定義する必要があります。前述のように、次の測定値（機器からのデータストリーム）をもつ、4つのセンサーを1つのモデルにグループ化します。 Model:Carousel Asset Name: CarouselAsset Property { Measurement: Photo.Distance Measurement: Speed.PDV1 Measurement: VibrationL.Temperature Measurement: VibrationR.Temperature } 測定値に加えて、アセットモデルにいくつかの 属性 （静的データ）を追加します。属性は、OEE 計算に必要な様々な値となります。 Model:Carousel Asset Name: CarouselAsset Property { Attribute: SerialNumber Attribute: Photo.distanceBase Attribute: Photo.distanceThold Attribute: Speed.max_speed_alarm Attribute: Speed.min_speed_alarm Attribute: Vibration.max_temp_c_alarm Attribute: Ideal_Run_Rate_5_min } それでは、AWS IoT SiteWise コンソールに進み、空港の BHS を表すカルーセルモデルとアセットを作成しましょう。 左側のナビゲーションメニューを開き、 ビルド、モデル、モデルの作成 の順に選択して、このモデルの属性と測定値を定義します。 アセットモデルの作成について詳しくは、 ドキュメント をご覧ください。 OEE の計算 OEE の定義とその構成要素を見てみましょう。 OEE の標準計算式は次のとおりです。 コンポーネント 式 Availability Run_time/(Run_time + Down_time) Quality Successes / (Successes + Failures) Performance ((Successes + Failures) / Run_Time) / Ideal_Run_Rate OEE Availability * Quality * Performance BHS のパラメータ定義を見てみましょう。OEE パラメータの詳細については、 ドキュメント をご覧ください。 Ideal_Run_Rate: このケースの理想的な実行速度は 300 bags/hour で、これは 0.83333 bags/second に相当します。この値はシステムによって異なるため、製造元から入手するか、現場での観測性能に基づいて取得する必要があります。 Availability Availability = Run_time/(Run_time + Down_time) BHSには4つのセンサーがあり、そのセンサーのどの 測定値 （温度、振動など）を計算に含めるかを定義する必要があります。2つの振動センサーからの温度（摂氏）と速度センサーからの回転式コンベアの速度 (m/s) によって、稼働状況が決まります。 正しく動作するための許容値は、アセットモデルの以下の属性に基づいています。 Vibration.max_temp_c_alarm = 50 Speed.min_speed_alarm = 28 Speed.max_speed_alarm = 32 それでは、BHS の現在の状態を次のような数値コードで提供するデータ 変換 Equipment_State を定義してみましょう。 1024 – マシンはアイドル状態です 1020 – システムの異常動作、高温、または定義された正常範囲外の速度値などの障害 1000 – 計画的な停止 1111 – 通常運転 この簡略化されたユースケースでは BHS のアイドル状態は定義されていませんが、他のデータストリームを AWS IoT SiteWise に統合することで、例えば、プログラマブルロジックコントローラー (PLC) や、人間のオペレーターがシステムのアイドル状態かどうかを入力するシステムから情報を登録することも可能です。 変換を追加するには、AWS IoT SiteWise コンソールでモデルに移動し、 編集 を選択します。変換の定義までスクロールし、名前、データ型 (ダブル) を入力し、それぞれのフィールドに次の数式を入力します。 Equipment_state = if((Speed.PDV1>Speed.max_speed_alarm) or (Speed.PDV1<Speed.min_speed_alarm) or (VibrationL.Temperature>Vibration.max_temp_c_alarm) or (VibrationR.temperature>Vibration.max_temp_c_alarm),1020).elif(eq(Speed.PDV1,0),1000,1111) 数式は、コンソールに入力すると次のようになります。UI は、数式の構築を支援するため、モデルで既に定義されている属性や測定値が提案表示されます。 Equipment_State の定義が完了したら、BHS の他の状態を捕捉するため以下のように派生する変換を作成します。変換は他の変換を参照できます。 次のメトリクスを定義して、マシンデータを時系列で集計します。各 メトリクス の時間間隔は同じにしてください。 Fault_Time = statetime(Fault) – The machine’s total fault time (in seconds) Stop_Time = statetime(Stop) – The machine’s total planned stop time (in seconds) Run_Time = statetime(Running) – The machine’s total time (in seconds) running without issue. Down_Time = Idle_Time + Fault_Time + Stop_Time – The machine’s total downtime モデルのメトリクスの定義は次のようになります。 Quality Quality = Successes / (Successes + Failures) ここでは、何が成功と失敗を構成するのかを定義する必要があります。このケースでの計測単位はバッグ数ですが、バッグの個数計数が成功した場合とそうでない場合をどのように定義すれば良いでしょうか。BHS の4つのセンサーから得られる測定値とデータを使用します。 バッグの数は、光電センサーが提供している距離を見てカウントされます。つまり、バンドを通過する物体があると、センサーは「ベース」距離よりも小さい距離を報告することを利用します。これはバッグの通過数を算出する簡単な方法ですが、同時に、測定の精度に影響を与えうる複数の条件を考慮する必要があります。 品質計算には以下のモデル属性を使用します。 Photo.distanceBase = 108 Photo.distanceThold = 0.1 Photo.DistanceBase は、センサーの前に物体がないときにセンサーによって報告される距離です。この値は定期的に校正して調整する必要がある場合があります。振動や位置ずれなどの要因により、バッグが誤検出される可能性があるためです。 Photo.DistanceThold は、センサーの感度の閾値を定義するのに使用されます。これにより、ゴミや小さな物体（バッグのアタッチメントやベルトなど）が通常のバッグのようにカウントされるのを防ぐことができます。 次に、バッグカウント用に2つの変換を設定します。 Bag_Count = if(Photo.Distance < Photo.distanceBase,1,0) Dubious_Bag_Count = if((gt(Photo.Distance,Photo.distanceBase*(1-Photo.distanceThold)) and lt(Photo.Distance,Photo.distanceBase*0.95)) or (Speed.PDV1>Speed.max_speed_alarm) or (Photo.Distance>Photo.distanceBase),1,0) Bag_Count は光電センサーの前を通過する全てのバッグをカウントし、Dubious_Bag_Count は次の2つの異常と判定する条件下でバッグとして検出されたオブジェクトをカウントします。 検出される距離が基準距離の 95% から 90% の範囲に入るものです。これは、小さな物体や測定値のごくわずかな変動、振動による変化、またはセンサーが正しく取り付けられていないことを考慮したものです。 回転式コンベアの速度が定義された制限を超えた時にカウントされたバッグです。この状態では、センサーは回転式コンベア上で隣接するバッグをカウントできない可能性があります。 注:上記の条件は単純なルールであり、より良い結果を得るには、ベースの距離と閾値をフィールドデータで検証および分析することで適切な値を設定する必要があります。 成功と失敗をメトリクスとして以下のように定義します。 Successes = sum(Bag_Count) – sum(Dubious_Bag_Count) Failures = sum(Dubious_Bag_Count) 最後に、OEE Quality をメトリクスとして以下のように定義します。 Quality = Successes / (Successes + Failures) 他のすべてのメトリクス定義と同じ時間間隔を使用することを忘れないでください。 Performance Performance = ((Successes + Failures) / Run_Time) / Ideal_Run_Rate Quality の計算から成功と失敗のメトリクスを、Availability からの Run_Time のメトリクスを取得できます。従って、必要なのは ideal_run_rate_5_min です。このシステムでは、この値は 300 bags/hour = 0.0833333 bags/second となります。 OEE Value Availability、Quality、Performance が決まったので、OEE の最後のメトリクスを次のように定義します。 OEE = Availability * Quality * Performance 変換とメトリクスの定義を簡素化 変換とメトリクスとして定義される OEE コンポーネントを、AWS コンソールを使用する代わりにプログラムで定義することもできます。これは、Equipment_State の変換や Dubious_Bag_Count の変換のように複数の変数を含む複雑な式がある場合に特に便利です。また、自動化されたソリューションは手動ソリューションよりもエラーが発生しにくく、複数の環境で一貫して構成できます。 Python 用 AWS SDK (Boto3) を使用してこれを行う方法を見てみましょう。 まず、変換/メトリクス計算で参照する測定値と属性のプロパティ ID、およびモデル ID を特定します。 次に、メトリクス/変換の JSON を定義します。例えば、BHS の Equipment_State を計算する新しい変換を作成するには、以下の属性が必要です。 Vibration.max_temp_c_alarm Speed.max_speed_alarm Speed.min_speed_alarm And the following measurements: VibrationL.Temperature VibrationR.Temperature Speed.PDV1 以下に示す構造に従ってファイルを作成します。必ず、propertyId を置き換えて、equipment_state.json という名前で保存してください。 { "name": "Equipment_State", "dataType": "DOUBLE", "type": { "transform": { "expression": "if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111)", "variables": [ { "name": "var_vibrationrtemperature", "value": { "propertyId": "b9554855-b50f-4b56-a5f2-572fbd1a8967" } }, { "name": "var_vibrationltemperature", "value": { "propertyId": "e3f1c4e0-a05c-4652-b640-7e3402e8d6a1" } }, { "name": "var_vibrationmax_temp_c_alarm", "value": { "propertyId": "f54e16fd-dd9f-46b4-b8b2-c411cdef79a2" } }, { "name": "var_speedpdv1", "value": { "propertyId": "d17d07c7-442d-4897-911b-4b267519ae3d" } }, { "name": "var_speedmin_speed_alarm", "value": { "propertyId": "7a927051-a569-41c0-974f-7b7290d7e73c" } }, { "name": "var_speedmax_speed_alarm", "value": { "propertyId": "0897a3b4-1c52-4e80-80fc-0a632e09da7e" } } ] } } } 主となる expression は次のとおりです。 if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111) update_asset_model_sitewise.py というスクリプトの入手と、AWS IoT SiteWise にデータをストリーミングする方法の詳細については、 こちら のパブリックリポジトリにアクセスしてください。 次に、モデル ID と以前に定義したファイルの名前を引数として、次のスクリプトを実行します。 #python3 update_asset_model_sitewise.py --assetModelId [Asset Model ID] --property_file [JSON File defining the new property] --region [AWS Region] スクリプトが正常な応答を返した後、作成した新しいプロパティ ID は、前述のように AWS コンソールから直接取得できます。もしくは、AWS CLI を使用して更新されたモデル定義をクエリし、 jq ユーティリティを使用して結果をフィルタリングすることでも取得できます。 #aws iotsitewise describe-asset-model --asset-model-id [model ID] | jq .'assetModelProperties[] | select(.name=="Equipment_State_API")'.id その後、他の変換やメトリクスについても同じプロセスを繰り返して、OEE の計算に必要なすべてのコンポーネントを作成できます。 AWS IoT SiteWise アセットモデルの更新の詳細については、 API リファレンス をご覧ください。 まとめ このブログ記事では、AWS IoT SiteWise のネイティブ機能を使用して、実際のシナリオのセンサーデータを使用して OEE を計算し、物理システムから洞察に満ちた情報を取得する方法について説明しました。パブリックリポジトリで入手可能なデータを特定しながら、OEE の主要な要素である Availability、Quality、Performance を定義しました。最後に、計算とその自動化方法について詳しく説明しました。 読者の次のアクションとして、ここで紹介した内容をさらに発展させて、OEE 計算プロセスを独自のユースケースに適用すること、さらに、提供されている自動化ツールを使用して、産業システムを正確に監視するのに役立つデータ生成を簡素化および合理化していくことをお勧めします。 使用できるデータがない場合は、この パブリックリポジトリ に概説されている手順に従い合成データで AWS IoT SiteWise を使い、OEE が提供する洞察に満ちた情報を発見することをお勧めします。 著者について Juan Aristizabal Juan Aristizabal は、アマゾンウェブサービスのソリューションアーキテクトです。カナダ西部の新規開拓企業のクラウドへの移行を支援しています。彼は、データセンターテクノロジー、仮想化、クラウドに至るまで、企業の IT トランスフォーメーションに10年以上携わってきました。余暇には、家族と一緒に旅行したり、シンセサイザーやモジュラーシステムで演奏したりするのが好きです。 Syed Rehan Syed Rehan は、アマゾンウェブサービス (AWS) のシニアグローバル IoT サイバーセキュリティスペシャリストで、AWS IoT サービスチームで働いており、ロンドンを拠点としています。セキュリティの専門家、開発者、意思決定者と協力して、AWS IoT サービスの運用を推進している世界中の顧客を対象としています。Syed はサイバーセキュリティ、IoT、クラウドに関する深い知識を持っており、スタートアップからエンタープライズに至るまで、世界中のお客様が AWS エコシステムで IoT ソリューションを構築できるよう支援しています。 この記事は Calculating Overall Equipment Effectiveness (OEE) with AWS IoT SiteWise の日本語訳です。IoT Consultant の正村 雄介が翻訳しました。

クラウド内の SQL Server データベースを保護することは重要であり、 Amazon Relational Database Service for SQL Server (Amazon RDS) は、データベースインスタンスの機密性、整合性、可用性を確保するために役立ついくつかのセキュリティ機能を提供します。これらの機能には、保存中および転送中のデータ暗号化、安全なユーザー認証および認可メカニズム、ネットワーク分離、およびきめ細かいアクセス制御が含まれます。 この投稿では、Amazon RDS for SQL Server インスタンスのセキュリティ体制を強化するためのベストプラクティスを示します。 クラウドセキュリティの概要 クラウドセキュリティの 3 つの主な要素は認証、認可、監査であり、次の図に示すプロセスにさらに分類できます。 プロセスは次のとおりです。 ネットワークセキュリティ – ネットワークセキュリティには、基盤となるインフラストラクチャを不正なアクセスや脅威から保護し、許可されたアクセスのみを許可するようにインフラストラクチャを保護することが含まれます。 Amazon Virtual Private Cloud (Amazon VPC) は、選択した仮想ネットワークで AWS リソースを起動できる、AWS クラウドの論理的に分離されたセクションを提供します。これにより、ネットワークアクセス、ネットワーク分離、ネットワークトラフィックフローなど、AWS インフラストラクチャのセキュリティとネットワーク構成を制御できます。 DB 認証 – これは、データベースにアクセスしようとするユーザーまたはシステムを認証するプロセスです。これは重要なデータへの安全なアクセスを確保するために、ログインとパスワードの認証、多要素認証、証明書ベースの認証などのさまざまな方法を使用して実現できます。 DB 認可 – これは、ユーザーまたはシステムの ID が認証された後に、そのユーザーまたはシステムにアクセス権を付与するプロセスです。これにはデータの読み取りや書き込み、特定のデータベースオブジェクトへのアクセスなど、特定のタスクを実行する権限の付与が含まれる場合があります。これによってデータが安全で許可された個人とシステムのみがデータにアクセスできることが保証されます。 DB アクセス監 査 – このプロセスはアカウンティングとも呼ばれ、不正アクセス試行などのセキュリティ問題を検出し、規制およびコンプライアンスの義務を果たすためにデータベースアクティビティの監視と記録を保証します。これはデータベースイベントを監視し、警告を設定し、ログを分析して不審な動作を検出することで実現され、データベースのアクセスと変更に対する監査可能な証跡が得られます。 DB 暗号化 – これは転送中と保存中のデータを暗号化することで、データベースに含まれる機密データへの不要なアクセスを防ぐプロセスです。データベース内の機密データを保護するために、AWS はサーバー側の暗号化、クライアント側の暗号化、スナップショット暗号化などのさまざまな暗号化ソリューションを提供しています。これにより、データベースに不正なアクセスがあった場合でも、暗号化されたデータは安全に保たれ、読み取ることができなくなります。 DB セキュリティ監視 – これにはセキュリティ問題をタイムリーに検知して対応するために、データベースとデータベースが動作するシステムとネットワークのセキュリティを監視することが含まれます。これはデータベースイベントを監視し、セキュリティアラームを設定し、セキュリティ分析ツールを使用してセキュリティリスクを検出して対応することによって実現できます。 次のセクションでは、各コンポーネントについて詳しく説明します。 ネットワークセキュリティ ネットワークセキュリティは、データベースインスタンスを不正アクセスから保護するための重要な手順です。データベースへのすべてのネットワークトラフィックが、ネットワーク構成で明示的に許可されている既知のソースから発信されていることを確認することが重要です。これは主にセキュリティグループと ネットワークアクセスコントロールリスト (ACL) を使用して構成できます。 セキュリティグループ 各 RDS for SQL Server インスタンスは 1 つ以上の セキュリティグループ に関連付けられます。これらのセキュリティグループを使用すると、インスタンスへのトラフィックを許可する IP または IP アドレスの範囲、およびポートまたはポート範囲を指定して、データベースインスタンスへのトラフィックを制御できます。 セキュリティグループが最大限に活用されるようにするには、データベースへのアクセスが必要な特定のソースおよびポート番号または範囲に対するイングレスルールを必ず追加してください。セキュリティグループは本質的にステートフルであり、受信ルールを通じて許可されている受信トラフィックに対して送信のトラフィックを自動的に許可します。 ネットワークアクセスコントロールリスト (ネットワーク ACL) ネットワーク ACL を使用すると、VPC 内のネットワークトラフィックをきめ細かく制御できます。ネットワーク ACL ルールはステートレスであるため、受信ルールと送信ルールを個別に指定する必要があります。これらは、VPC 内でデータベースを確実に分離するために追加のポリシーを導入する必要がある場合に役立ちます。 VPC 内のプライベートサブネットに Amazon RDS for SQL Server インスタンスを作成し、ネットワーク ACL を作成して Amazon RDS for SQL Server サブネットに関連付けることで、VPC 内の特定のサブネットからの特定のトラフィックのみが Amazon RDS for SQL Server VPC に到達できるようにすることができます。セキュリティグループとは異なり、ネットワーク ACL はステートレスであり、受信トラフィックと送信トラフィックの両方に対してルールを定義する必要があることを覚えておくことが重要です。 ネットワーク ACL を使用している場合、Amazon RDS for SQL Server マルチ AZ インスタンスを構成する場合は UDP と TCP のポート 3343 でのトラフィックを必ず許可してください。 ネットワーク ACL を使用すると、サブネットレベルでトラフィックフローを制御できますが、管理と構成が複雑になる可能性があることに注意することが重要です。 そのため、定義されたソースからのトラフィックを許可する必要があってサブネットレベルで管理する必要がない場合は、セキュリティグループの方がこれらのルールを定義する方が適しています。セキュリティグループはインスタンスレベルで動作し、ネットワーク ACL はサブネットレベルで動作するからです。 Amazon RDS for SQL Server データベースインスタンスへのリモート接続 SQL Server Management Studio や他の SQL クライアントなどのツールを使用して、Amazon RDS for SQL Server にリモートで接続する方法は複数あります。ただし、アクセスを容易にしながらリモート接続の安全性を確保することが重要です。セキュリティやコスト削減などのさまざまな理由から、踏み台ホストを使用して接続を Amazon RDS に委任することをお勧めします。 このアプローチでは、踏み台ホストをデプロイして、AWS Systems Manager から Amazon RDS for SQL Server インスタンスへの SQL Server 接続をプロキシします。両方とも VPC 内のプライベート サブネット にデプロイされます。 AWS コマンドラインインターフェイス (AWS CLI) で Systems Manager を使用する手順については、「 AWS Systems Manager ユーザーガイド 」を参照してください。 次の図は、このアーキテクチャを示しています。 このアプローチは次のように機能します。 適切な API キーを使用して、 AWS コマンドラインインターフェイス と セッションマネージャープラグイン を備えた VDI/ デスクトップまたはラップトップなどの開発環境を構成します。環境から想定できる SSM 権限を持つ IAM ロールを使用することをお勧めします。 その後、データベースインスタンスがデプロイされているプライベートサブネット内に踏み台ホストまたはジャンプホストをデプロイし、データベースポートへのアクセスを許可するように踏み台ホストのセキュリティグループを構成できます。また、VPC エンドポイントに到達できるように、少なくとも 1 つのルールがアウトバウンド 433 (HTTPS) をカバーしていることを確認してください。 同様に Amazon RDS for SQL Server インスタンスにセキュリティグループを設定して、踏み台ホストのセキュリティグループからの受信トラフィックを許可します。 アクセス許可ポリシー SSMManatedInstanceCore を使用してインスタンスプロファイルを作成し、踏み台ホストに割り当てます。 ローカルワークステーションまたは VDI が適切な IAM ユーザーで構成されていることを確認するか、SSM 権限を持つ IAM ロールを引き受けます。 コマンドプロンプトを開き、次の AWS CLI コマンドを入力します。 aws ssm start-session ` --region <region> ` --target <bastion instance id> ` --document-name AWS-StartPortForwardingSessionToRemoteHost ` --parameters host=" <rds endpoint> ",portNumber="1433",localPortNumber="1433" 次のようなメッセージが表示されるはずです。 Starting session with SessionId: 12a3456bcdefghi789 Port 1433 opened for sessionId 12a3456bcdefghi789. Waiting for connections... これで、SQL Server Management Studio を開いてサーバー名 127.0.0.1,1433 に接続できるようになりました。これにより、踏み台ホストを介して Amazon RDS for SQL Server インスタンスに接続が転送されます。適切な証明書を使用して SSMS を構成し、接続プロパティ タブの [接続の暗号化] チェックボックスをオンにして、接続が暗号化されていることを確認します。 この図は Linux の踏み台インスタンスを示していますが、Windows インスタンスも同様に動作するため、Linux ホストである必要はありません。ただし、踏み台ホストがプロキシとして機能し、RDS インスタンスへの接続を通過させるためだけに存在することを考えると、コンピューティングリソースは最もコスト効率の高いオプションに基づく必要があります。 これは、次の理由からRDS for SQL Server インスタンスへのリモートアクセスを有効にする場合のベストプラクティスです。 開く必要があるポートは、踏み台ホストと RDS for SQL Server インスタンスの間のみです。 リモートデスクトップ SSH 接続のために IP 許可リストは必要ありません。 Amazon Elastic Compute Cloud (Amazon EC2) 踏み台ホストは、インターネットに公開せずにプライベートサブネット内に配置できます。 VDI と AWS 環境間の接続には、 AWS Direct Connect または AWS VPN を使用することを推奨します。Amazon EC2、Amazon RDS、および Systems Manager はすべて AWS PrivateLink を介して接続が行われるため、インターネットからのアクセスが制限されています。 これまでに説明した方法はネットワークセキュリティに役立ち、選択したトラフィックのみがデータベースに到達できるようにします。ただし、利用可能なさまざまな認証および承認方法を使用してデータベースレベルで RDS for SQL Server インスタンスをさらに保護するだけでなく、データベースに関連する重要なイベントが監視、記録され、さらなる分析や調査に利用できるように監視と監査を実施することも同様に重要です。次のセクションでは、データベースセキュリティのこれらの主要なコンポーネントについて説明します。 データベース認証 SQL または Windows 認証を使用して、RDS for SQL Server データベースに接続できます。 Windows 認証に NTLM または Kerberos を使用することもできます。 SQL Server 認証 SQL Server 内では、SQL Server 認証によってユーザー名とパスワードのペアが追跡されます。 Active Directory (AD) のメンバーではない場合に Amazon RDS for SQL Server に接続する唯一の方法は、SQL Server 認証を使用することです。 SQL Server ログインは、使用時に暗号化されたパスワードと SQL Server ログイン名がネットワーク経由で送信され、ユーザー情報が盗まれる可能性が高くなるため、プライバシーが下がります。したがって、可能な限り SQL Server 認証ではなく Windows 認証を使用してください。 Windows 認証 RDS for SQL Server インスタンスが AWS Managed Microsoft AD の AD ドメインにドメイン参加している場合は、Windows 認証を有効にすることができます。 Windows 認証を有効にすると、AD ドメイン ユーザーは Windows 資格情報を使用して SQL Server データベースにアクセスできるようになります。ユースケースによっては、これは、特に人間のユーザーが管理や手動クエリの実行のためにアクセスを必要とする場合、データベースへのアクセスを管理するための好ましい方法となる場合があります。 注意 ： 2023 年 7 月 10 日よりセルフマネージド型の Active Directory をサポートされるようになりました。詳細は、 こちら のブログを参照してください。 ドメインユーザーが RDS for SQL Server インスタンスにログインできるようにするには、インスタンスが AD ドメインにドメイン参加していることを確認し、次のクエリを実行してドメインユーザーのログインを作成します。 USE [master] GO CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ログインが作成されると、ユーザーはドメイン資格情報を使用してデータベースにアクセスできるようになります。適切なロールがユーザーに追加されていることを確認してください。次のセクションでは、最小権限に基づいてロールを割り当てるベストプラクティスについて説明します。 チームのすべてのメンバーがデータベースにアクセスする必要があるアプリケーションチームなど、複数のユーザーがデータベースにアクセスする必要がある場合があります。このような場合、すべてのユーザーで構成される AD セキュリティグループを作成し、AD グループ全体を RDS for SQL Server インスタンスに追加できます。このアプローチでは、AD グループにユーザーを追加または削除することで、データベースへのアクセスをディレクトリレベルで直接管理できます。 次の図は、このアーキテクチャを示しています。 Windows オペレーティングシステムでは、NTLM と Kerberos という 2 つの一般的なクライアント / サーバー認証方法があります。ただし、次の理由から NTLM よりも Kerberos の方が推奨されます。 チケット発行サービス、キー管理機能の 2 つのパートから構成されています。 暗号化を使用してネットワーク上でパスワードをキャッシュしたり転送したりしないためセキュリティが向上します。 Kerberos には、MiTM (中間者) 攻撃やリプレイ攻撃に対する保護機能が組み込まれています。 Kerberos により相互認証が可能になり、一部の傍受攻撃や不正アクセスを防ぐことができます。 Kerberos がユーザーの認証に失敗した場合、エンドポイントが登録された SPN (サービスプリンシパル名) ではない場合、システムは NTLM にフォールバックします。エンドポイントが登録された SPN である場合は、NTLM にフェイルバックせず失敗します。 次の表は、接続タイプをまとめたものです。 Connection Type SQL Server Connection String Login Type Auth_Scheme RDS Endpoint TestSQL.xxxxx.us-east-1.rds.amazon.com Windows Authentication NTLM RDS Fully qualified domain name (FQDN) TestSQL.octank.com Windows Authentication Kerberos RDS Endpoint TestSQL.xxxxx.us-east-1.rds.amazon.com SQL Authentication SQL RDS Fully qualified domain name (FQDN) TestSQL.octank.com SQL Authentication SQL 注意 : Always On の可用性グループリスナーは、Kerberos 認証をサポートしていません。 データベース認可 データベース認可に関しては、ロールと権限を使用してデータベースデータへの認可アクセスをユーザーレベルで制限する方法に焦点を当てています。 アプリケーション内でマスターユーザーを直接使用しないことを強くお勧めします。代わりに、アプリケーションに必要な最低限のアクセス権を持つデータベースユーザーを作成するベストプラクティスを採用してください。そうすることで個別のユーザーアカウントを作成することになり、各ユーザーには職務の義務を遂行するために必要な権限のみが付与されます。ロールベースのアクセス (RBAC) 制約を採用して、常に最小特権セキュリティを使用してください。 RBAC は一般にユーザーにデータベースへの読み取り専用アクセスを与えることで、最小限の権限を強制するために使用されます。 Amazon RDS を使用すると、ライフサイクル全体を通じてマスターユーザー認証情報を AWS Secrets Manger に保存および管理できます。 AWS Secrets Manager では 4 時間ごとにシークレットをローテーションできると同時に、同じマネージドローテーションエクスペリエンスを提供できます。 以下は Secrets Manager にパスワードを保存することで得られるメリットの一部です。 RDS はアプリケーションの変更を必要とせずにデータベースの認証情報を定期的にローテーションします。 Secrets Manager は人間のアクセスやプレーンテキストビューからデータベースの資格情報を保護します。 AWS CloudTrail と Amazon CloudWatch を使用するとデータベースの認証情報を簡単に監視できます。 Secrets Manager を使用すると IAM を使用してシークレット内のデータベース認証情報へのアクセスをきめ細かく制御できます。 プライマリユーザーの権限を誤って消去した場合は、データベースインスタンスを更新して新しいプライマリユーザーのパスワードを入力することで 権限を復元することができます 。また、データベースインスタンスの作成後はプライマリユーザー名を変更できないことにも注意してください。 データベースアクセス監査 データベースを監査する場合は、SQL Server Trace または SQL Server Audit を有効にすることで実行できます。 SQL Server Trace RDS for SQL Server インスタンスには、その上で実行される T-SQL を利用するデフォルトのサーバー側トレースがあり、システムの現在の実行トレースを提供するカタログビュー sys.traces を介してアクセスできます。ディレクトリ D:\rdsdbdata がサーバー側のトレースのログなどのデフォルトの格納場所になっている事が重要です。 fn_trace_gettable 関数を使用してトレースファイルを読み取ることができます。サーバー側のトレース結果をデータベーステーブルに保存することもできます。次のコードを参照してください。 SELECT * INTO RDSTrace FROM fn_trace_gettable('D:\rdsdbdata\Log\, default); このテーブルは任意のユーザーデータベースに対して作成でき、すべてのロールオーバーファイルを含むログディレクトリ内のすべてのファイルの結果がロードされます。 Amazon RDS はデフォルトで、7 日より古いトレースファイルとダンプファイルを削除します。ただし、 rds_set_configuration ストアドメソッドを使用すると、トレースファイルの保存期間を変更できます。たとえば、次のストアドプロシージャは、トレースファイルの保持時間を 24 時間 (1440 分) に変更します。 exec rdsadmin..rds_set_configuration 'tracefile retention', 1440; SQL Server Audit RDS for SQL Server インスタンスまたは単一データベースを監査するには、データベースエンジンで発生するイベントの追跡とレポートが必要になります。ネイティブな SQL Server Audit を使用すると、サーバーレベルのイベントのサーバー監査仕様と、データベースレベルのイベントのデータベース監査仕様を含めることができるサーバー監査を設計できます。監査されたイベントは常に監査ファイルに記録されます。 オプショングループを使用すると、RDS for SQL Server インスタンスで監査を有効にすることができます。 Amazon RDS ではデフォルトのオプショングループを変更できないため、新しいオプショングループを作成して sqladuit のオプションを追加する必要があることに注意してください。 これらの監査ファイルが削除され、 Amazon Simple Storage Service (Amazon S3) に移行される前に、それらをディスク上に保持するオプションが提供されます。監査ファイルはアカウントの S3 バケットに保存されます。監査ファイルは Amazon S3 に保存される前に圧縮されるため、Amazon S3 のコスト削減に役立ちます。 IAM ロールを定義することは、バケットにファイルを書き込む権限を Amazon RDS に付与するため重要です。 これは FedRAMP および HIPAA 監査用に予約されている名前領域であるため、監査ファイルは RDS_ で始まるべきではありません。 ファイルサイズは 2 ～ 50 MB の制限範囲内にすることをお勧めします。そうしないと、これらのファイルの Amazon S3 へのコピーが影響を受ける可能性があります。 AWS は、指定された保存期間の監査ログを保存してアーカイブします。デフォルトでは保持オプションは無効になっており、指定された S3 バケットに監査ログがオフロードされると AWS が監査ログを削除します。この動作は 1 ～ 840 時間の間で任意の値を設定することで変更できます。 ストアドプロシージャ rds_fn_get_audit_file を使用して、SQL Server のサーバー監査によって作成された監査ファイルから情報を取得します。監査が失敗した場合は、 シャットダウンせずに続行するか 、 操作を失敗するか 、のオプションを選択できます。 サーバーレベルの監査は、SQL Server のすべてのエディションでサポートされています。 SQL Server 2016 (13.x) SP1 では、すべてのバージョンでデータベースレベルの監査が可能です。以前は、データベースレベルの監査は Enterprise、Developer、および Evaluation エディションでのみ利用可能でした。 Amazon RDS for SQL Server は、データベースアクティビティストリームをサポートするようになりました。これにより、リレーショナルデータベースでのログインの失敗などのデータベースアクティビティのほぼリアルタイムのストリームを確認できるようになります。詳細については、「 データベースアクティビティストリームを使用した Amazon RDS for SQL Server の監査 」を参照してください。 データベースの暗号化 このセクションでは、転送中のデータ暗号化、保存時の暗号化、および透過的データ暗号化 (TDE) について説明します。 転送中のデータ暗号化 Secure Sockets Layer (SSL) を使用して、クライアントアプリと SQL Server を実行している RDS データベースインスタンス間の通信を暗号化できます。これを実現するには、 パラメータグループ を通じて rds.force_ssl パラメータを有効にします。デフォルトでは、 rds.force_ssl パラメータは 0 (オフ) に設定されています。接続で SSL の使用を強制するには、rds.force_ssl パラメータを 1 (オン) に設定します。 rds.force_ssl パラメータは静的であるため、値を変更した後に変更を有効にするためにデータベースインスタンスを再起動する必要があります。 SSL/TLS 接続は、クライアントとデータベースインスタンス間で送信されるデータを暗号化することにより、セキュリティ層を追加します。 RDS データベースインスタンスへの接続が確立されていることを確認することで、サーバー証明書によって保護のレベルがさらに高まります。これは、作成したすべてのデータベースインスタンスに自動的に展開されるサーバー証明書を検査することで実現されます。 SSL を使用して、次の 2 つの方法で RDS for SQL Server データベースインスタンスに接続できます。 すべての接続に SSL を強制する – これはクライアントには目に見えずに行われ、クライアントは利用するために何もする必要がありません。 個別の接続を SSL 暗号化する – これにより、特定のクライアントコンピューターからの SSL 接続が確立され、接続の暗号化にはクライアント側での作業が必要になります。 次のコマンドを使用すると、接続が暗号化されているかどうかを確認できます。 select ENCRYPT_OPTION from SYS.DM_EXEC_CONNECTIONS where SESSION_ID = @@SPID アプリケーションサーバー上で実行されている SQL クライアントからの接続を暗号化するには、接続文字列に encrypt=true を追加します。 JDBC 経由で接続するクライアントに SSL 暗号化を許可するには、Amazon RDS for SQL Server 証明書を Java CA 証明書 (cacerts) リポジトリに追加する必要がある場合があります。これは keytool ユーティリティを使用して可能です。証明書のダウンロードの詳細については、「 SSL/TLS を使用した DB インスタンスへの接続の暗号化 」を参照してください。 保存時のデータ暗号化 保存時の暗号化を有効にする場合は 2 つの選択肢があります。 AWS Key Management Service (AWS KMS) 暗号化キーを使用して保存時の暗号化を設定します。 SQL Server 2019 Enterprise Edition または Standard Edition を実行している場合は、透過的データ暗号化 (TDE) を利用します。 SQL Server 2019 より前は、TDE 機能は Enterprise エディションでのみ利用可能であったことに注意してください。 データベースインスタンスの作成中に、保存データの暗号化を許可するように AWS KMS を設定できます。暗号化されたデータベースインスタンスを作成するときは、クライアント制御のキーまたは Amazon RDS の AWS 管理のキーのいずれかを使用して暗号化できます。カスタマー管理キーのキー識別子を指定しない場合、Amazon RDS は AWS 管理キーを使用して新しいデータベースインスタンスを作成します。 Amazon RDS は、AWS アカウントの Amazon RDS 管理キーを生成します。 AWS アカウントには、リージョンごとに Amazon RDS 用の一意の AWS 管理キーがあります。 暗号化されたデータベースインスタンスで使用される AWS KMS キーは、構築後に変更することはできません。したがって、暗号化されたデータベースインスタンスを確立するときは、AWS KMS キーの必要性を必ず特定してください。 AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウドスケールのキー管理ソリューションを提供します。カスタマー管理キーを構築し、AWS KMS を使用してこれらのカスタマー管理キーの使用方法を管理するポリシーを指定できます。 AWS KMS は CloudTrail をサポートしているため、AWS KMS キーの使用状況を監査してカスタマー管理のキーが正しく利用されていることを確認できます。 Amazon RDS 暗号化データベースインスタンスの制限の詳細については、「 Amazon RDS リソースの暗号化 」を参照してください。 透過的なデータ暗号化 Amazon RDS では、SQL Server データベースインスタンスを暗号化するための透過的データ暗号化 (TDE) もサポートされています。 TDE を保存時の Amazon RDS 暗号化と組み合わせて使用することもできますが、そうするとデータベースのパフォーマンスに多少の影響が出る可能性があります。暗号化手法ごとに個別のキーが必要です。 TDE は、データをストレージに書き込む前に自動的に暗号化し、ストレージから読み取るときにデータを復号化します。 2 層のキーアーキテクチャで暗号化キーを管理します。データ暗号化キーを保護するために、データベースの主キーから発行された証明書が使用されます。データベース暗号化キーは、ユーザーデータベース上のデータの暗号化と復号化を担当します。 Amazon RDS は、データベースの主キーと TDE 証明書を保存および管理します。 データベースインスタンスが TDE 対応の オプショングループ にリンクされていない場合は、2 つのオプションがあります。オプショングループを作成するか、対応するオプショングループを変更することで TDE オプションを追加できます。 暗号化されたデータベースが少なくとも 1 つあるデータベースインスタンス上にデータベースがある場合、暗号化されていないデータベースのパフォーマンスが低下する可能性があります。そのため、暗号化されたデータベースと暗号化されていないデータベースを異なるデータベースインスタンスに保持することをお勧めします。 SQLSERVER BACKUP RESTORE および TRANSPARENT DATA ENCRYPTION オプションをデータベースインスタンスに関連付けられたオプショングループに追加する必要があります。 TDE 証明書は、RDS for SQL Server ストアドプロシージャを使用してバックアップ、復元、および削除できます。 Amazon RDS for SQL Server には、回復されたユーザー TDE 証明書を検査する機能があります。 追加の戦略 次の戦略を使用してデータを保護することもできます。 行レベルのセキュリティ – データベースユーザーのアクセスを自分の部門またはビジネスに関連するデータ行のみに制限する場合は、行レベルセキュリティ (RLS) を使用します。 RLS は、データ行アクセス制御の実装を支援します。 RLS を使用すると、アプリケーションのセキュリティの設計とコーディングが容易になります。これにより、アプリケーション層でアクセス制限メカニズムを維持するという依存関係がなくなります。代わりに、データベースシステムは、これらのアクセス制限を実装するためのプレースホルダーとして機能します。適切なテーブル値フィルター関数とセキュリティポリシーを設定すると、RLS を実装してセキュリティ設計の堅牢性と強度を強化できます。 RLS は、RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。 データマスキング – データマスキングは、侵入者がアクセスした場合に役に立たないように機密情報を隠すことを可能にするもう 1 つのデータセキュリティ戦略です。機密データを非特権ユーザーからマスクして保護します。デフォルトでは、データベース所有者は例外です。マスクされたデータは、概念実証またはデータ自体が必要ないその他のユースケースで元のデータを置き換えるために使用されます。繰り返しますが、データマスキングメカニズムはデータベースレベルで実行されるため、アプリケーションは現在のクエリを変更することなく機密データを隠すことができます。利用可能なマスキング形式は多数あります。さまざまな機密データカテゴリの個別のニーズに基づいて形式を選択します。データマスキングは、RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。 Always encrypted – このデータ暗号化アプローチは、アプリケーションとデータベースサーバー間のデータ転送中、保存中のデータ、およびデータの使用中の機密情報の保護に役立ちます。プレーンテキストを暗号化形式に変換することで、データベースシステム内で機密データが常に暗号化されて表示されることが保証されます。この方法では、テーブルまたはデータベース全体ではなく、選択した列のみが暗号化されることに注意することが重要です。適切な暗号化手法と暗号化キー (列暗号化キーと列主キー) を使用して列を効果的に暗号化できます。暗号化キーを定期的にローテーションすることで、組織のルールやコンプライアンス法を遵守できます。暗号化された列はかなり多くのスペースを必要とすることに注意してください。この機能は、2016 RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。詳細については、「 Amazon RDS for SQL Server を使用した Always Encrypted のセットアップ 」を参照してください。 SQL Server トリガー – トリガーは、特定の条件が満たされた場合に保存されている一連の命令を実行するオブジェクトです。これらを使用すると、オブジェクトへの不正な更新を回避したり、DML や DDL トリガーを使用して新しいログイン認証情報を作成したり、ログオントリガーを使用して Amazon RDS for SQL Server インスタンスに対する合計接続数を制限したりできます。これらのトリガーを Amazon CloudWatch アラームと組み合わせて使用すると、セキュリティポリシーに違反したときに自動メールを送信できます。 列レベルの暗号化 – このアプローチは、より詳細なレベルでデータを暗号化してすべての列または選択した列に適用できます。列レベルの暗号化を使用すると、列ごとに個別の暗号化キーを指定できます。詳細については、「 Amazon RDS for SQL Server での列レベルの暗号化 」を参照してください。 データベース監視 CloudWatch を使用すると、環境内の異常なアクティビティを特定してアラートを作成、自動アクションを実行して問題を解決できます。エラーと SQL エージェントのログが CloudWatch Logs に公開されるように、[ログエクスポート] オプションを必ず選択してください。 不正なログインデータや、RDS for SQL Server インスタンスのエラーログに報告されたエラーを CloudWatch に公開できます。 Amazon Simple Notice Service (Amazon SNS) を使用して、CloudWatch ロググループ、パターン、アラームに基づいてエンドユーザーに通知を提供できます。 SQL Server ログの CloudWatch Logs への公開はデフォルトでは有効になっていないことに注意してください。さらに、トレースファイルとダンプファイルの公開はサポートされていません。 SQL Server ログの CloudWatch Logs への公開は、アジアパシフィック (香港) を除くすべてのリージョンでサポートされています (この記事の執筆時点) 。 次の図は、CloudWatch を使用したアーキテクチャの例を示しています。 詳細については、「 Amazon RDS for SQL Server のモニタリングとアラートを設定する方法のベストプラクティス 」を参照してください。 追加の AWS サービス 次のサービスを使用して、セキュリティフレームワークの構築を支援することもできます。 AWS Trusted Advisor – AWS Trusted Advisor は、セキュリティ専門家によって厳選されたコアセキュリティのベストプラクティスを推奨します。これは、AWS 環境のセキュリティの向上に役立つ可能性があります。たとえば、Trusted Advisor は、RDS セキュリティグループのアクセスリスク、保護されていないアクセスキー、不要な S3 バケットのアクセス許可、ルートアカウントの MFA を特定できます。 Amazon Macie – Amazon Macie は、機械学習とパターンマッチングを採用したフルマネージドのデータセキュリティ ソリューションで、RDS for SQL Server インスタンス内の機密データの検出と保護を支援します。この手順は、Parquet で圧縮されたデータベースのスナップショットをキャプチャし、Amazon S3 に保存することを目的としています。その後、機密データを検索する Macie タスクを開始できます。その後、 Amazon Athena と Amazon QuickSight を使用して機密データを読み取り、分析できます。 まとめ この投稿では、接続、ネットワーキング、さまざまなセキュリティの選択に関するベストプラクティスを含め、Amazon RDS for SQL Server を適切に使用する方法の包括的な概要を説明しました。提供されたソリューションのレビューに基づいて、データベースに適切なセキュリティ方法を決定できます。 TDE 証明書のローテーションの詳細については、「 Amazon RDS for SQL Server での TDE 証明書のローテーション 」を参照してください。セキュリティパラメータのカスタマイズの詳細については、「 Amazon RDS for SQL Server のセキュリティパラメータのカスタマイズ 」を参照してください。 Amazon RDS のセキュリティの詳細については、「 Amazon RDS のセキュリティ 」を参照してください。 このトピックに関して質問や推奨事項がある場合は、コメントを残してください。 著者について Suprith Krishnappa C は、アマゾンウェブサービスのプロフェッショナルサービスチームのデータベースコンサルタントです。彼は企業顧客と協力して、データベースプロジェクトに関するテクニカルサポートや顧客ソリューションの設計を提供するほか、既存のデータベースを AWS クラウドに移行して最新化するのを支援しています。 Santhosh Srinivasan は、アマゾンウェブサービスのプロフェッショナルサービスチームに所属するシニアクラウドアプリケーションアーキテクトです。金融サービス業界を中心に、クラウドでの大規模エンタープライズアプリケーションの構築とモダナイゼーションを専門としています。     翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 今週号は各サービスの対応リージョン拡張のニュースが凄く多かったのですが、何よりも注目すべきは Amazon Bedrock の一般利用開始ですね。生成系AIアプリケーションにおいて大規模言語モデルや基盤モデルは中核をなすものですが、それ自体を安定的に稼働させ続けたり負荷に応じてスケーリングさせることが重要です。また、用途に応じたモデルを自分たちのデータを利用してカスタマイズするファインチューニングすることが必要になることもあります。こういった用途にあわせて開発されたサービスがAmazon Bedrockですので、ぜひ詳細を確認してみてください。 それでは、9 月 25 日週のアップデートを振り返ってみましょう。 2023 年 9 月 25 日週の主要なアップデート 9/25(月) Amazon EC2 Serial Consoleが大阪ほか10のリージョンでご利用可能に オンプレミスのハードウェアを触ってきたエンジニアの方にとっては懐かしく感じるかもしれませんが、Amazon EC2ではシリアルコンソールにアクセス可能です。このシリアルコンソールへのアクセス機能が大阪リージョンをはじめ11のリージョンでご利用いただけるようになりました。 9/26(火) Amazon DynamoDBがAmazon S3に対する増分エクスポートに対応 Amazon DynamoDBで、増分エクスポート機能(Incremental Export)が利用できるようになりました。指定した時間間隔内で変更されたデータのみをエクスポートするという風に動作し、DynamoDBで発生した変更を順次データレイクに流し込み分析する、といった用途で便利な機能です。 ブログ記事 もどうぞ。 Amazon EC2 Hpc7gインスタンスが東京リージョンほか2つのリージョンで利用可能に AWS Gravitonプロセッサを搭載したHPC向けのEC2インスタンス、Hpc7gインスタンスが東京・アイルランド・GovCloud(米国西部)の各リージョンでご利用いただけるようになりました。 Amazon MSKがApache Kafkaのバージョン3.5.1をサポート Amazon Managed Streaming for Apache Kafka(Amazon MSK)が Apache Kafkaのバージョン3.5.1 をサポートしました。新規に起動するクラスタと、既存のクラスタの双方でご利用いただけます。 Amazon EKSとAmazon EKS DistroでKubernetesのバージョン1.28をサポート Amazon EKSとAmazon EKS Distroで Kubernetesのバージョン1.28 がご利用いただけるようになりました。詳細については ブログ記事 をご覧ください。 Amazon Chime SDK meetings APIのエンドポイントが東京ほか5つのリージョンでご利用可能に Amazon Chime SDKを利用すると、リアルタイムのビデオ通話・音声通話の機能をアプリケーションに簡単に追加することが可能です。今回、ミーティングを作成・管理するためのAmazon Chime SDK meeting APIのエンドポイントが東京を始め6つのリージョンでご利用いただけるようになりました。 9/27(水) Amazon S3で削除マーカーに対する最終更新日時を提供開始 Amazon S3でHead/Get APIをリクエストした際に、削除マーカーの最終更新日時(Last-Modified Time)情報を取得できるようになりました。バージョニングが有効になっているバケットでは、オブジェクト削除を行うとデータが物理的に削除される代わりに削除マーカーが作成され、削除されている状態を論理的に表現します。この削除マーカーの最終更新日時が取得できるようになったということは、データ削除が行われた日時を容易に追跡できるようになった事を意味します。バケット内で発生した変化をトラッキングする必要がある場合に便利な機能です。 Amazon EC2 Instance Connectが大阪リージョンほか10のリージョンで利用可能に いわゆる踏み台サーバを利用することなく、パブリックなIPアドレスを持たないインスタンスへのSSH/RDP接続を可能にするEC2 Instance Connectが、大阪リージョンをはじめ11のリージョンで利用できるようになりました。 9/28(木) Amazon Bedrockが一般利用開始に 基盤モデルを利用した生成系AIアプリケーションを簡単に開発・スケーリングできるようにするためのサービス、Amazon Bedrockが一般利用開始になりました。様々な用途に合わせてAI21 Labs, Anthropic, Cohere, Meta, Stability AI, Amazonなどが提供する基盤モデルから最適なものを選択し、APIを利用してアプリケーションから呼び出すことで、アプリケーションの開発や運用維持を容易に実現します。 ブログ記事 や 料金設定のページ もご覧ください。 Amazon Titan Embeddingsが一般利用開始に 自然言語テキストを数値表現に変換する埋め込みモデルであるAmazon Titan Embeddingsが一般利用開始になりました。単語やフレーズ、ドキュメントなどの自然言語を利用して、意味的な類似性に基づいて検索したりパーソナライズする際に利用でき、検索拡張生成(RAG)という生成系AIアプリケーションで利用されるアプローチにも応用可能です。Titan Embeddingsは25の言語をサポートしています。 Amazon QuickSightのGenerative BI機能によるダッシュボード作成がプレビュー可能に Amazon QuickSightで3つのGenerative BI(生成系BI)機能をプレビューできるようになり、自然言語で指示することで求める出力結果を得ることができるようになりました。ひとつめはどのように可視化したいかを指示できる機能。ふたつめは複雑な計算を実行する機能。みっつめはダッシュボード上のグラフなどの見た目を調整する機能です。ちなみに、QuickSightのGenerative BI機能はAmazon Bedrockを利用して構築されています。 Amazon SageMaker Canvasによる予測が最大50%高速に コード開発不要で機械学習による予測を可能にするAmazon SageMaker Canvasで、精度とパフォーマンスを向上するためのアップデートが行われました。予測モデルの作成が最大50%高速になり、同時にモデルを利用した予測処理も最大45%高速になりました。 9/29(金) Amazon Inspectorが大阪ほか3つのリージョンで利用可能に 継続的な脆弱性管理を自動的かつ大規模に実行することを容易にする、Amazon Inspectorが大阪リージョンをはじめ4つのリージョンでご利用可能になりました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

本日 (2023 年 9 月 28 日)、AWS Amplify JavaScript Library の v6 Developer Preview を発表しました。これは、AWS クラウドバックエンドを使用した Web 開発へのアプローチ方法を改善するマイルストーンリリースです。私たちは皆様からのフィードバックに耳を傾けており、本日の発表では GitHub で皆様から寄せられていたバンドルサイズや、TypeScript と Next.js のサポートに対するリクエストのいくつかに対応しました。それでは早速、Amplify JavaScript v6 Developer Preview の新機能をご紹介します！ バンドルサイズの縮小によってアプリのロード時間を改善 スピードは贅沢品ではなく、必要不可欠なものです。そのため、私たちは ツリーシェイキング機能 と基盤となるインフラを改善しました。バンドルサイズを小さくすることで、アプリケーションのロード時間が短縮され、高速ブロードバンドであろうと、断続的な接続であろうと、ユーザーを飽きさせず、満足させることができます。 新しい Developer Preview 版では、Amplify は、カテゴリ全体ではなく、Amplify Auth や Storage などの各カテゴリから、アプリに必要な API のみをインポートします。 未使用の機能はツリーシェイクで除外されます。このツリーシェイク機能を実現するために、私たちはクラスベースの開発者体験から関数ベースの開発者体験へと移行しています。 関数ベースの開発者体験は、2 つの重要な点で Amplify JavaScript v5 とは異なります。 [赤色の下線部] カテゴリごとにクラスをインポートする代わりに、サブパスから特定の機能をインポートする必要があります。 [紫色の下線部] 関数のパラメータがオブジェクトになり、API の読みやすさを向上させるために「名前付きパラメータ」になりました。 TypeScript 体験の向上 私たちのチームは、TypeScript が多くのチームの開発ワークフローに不可欠なものとなり、より大規模で複雑なプロジェクトを管理しやすくなり、高い安全性のレベルを提供していることを理解しています。そのため、今回の Developer Preview では、Auth, Analytics, Storage の各カテゴリを皮切りに、TypeScript のサポートを強化しています。この TypeScript の機能強化は、GraphQL API や REST API を含むすべてのカテゴリに拡大していく予定です。 これらの TypeScript の強化により、より豊富なシンタックスハイライト、コード補完、ストリクトモードのサポートが得られます。また、アプリを実行する前にバグを特定するのに役立つ型チェックも忘れてはなりません。 Next.js App Router, API Routes, Middleware のサポート Next.js から利用可能なすべての機能に対する総合的なサポートを提供してほしいというのが、私たちのコミュニティからの頻繁な要望でした。これを念頭に置いて、Next.js の機能を組み込み、新しい Next.js アダプタを作成しました。Server Side Rendering (SSR), Middleware, Server Functions, App Router など、使いたい Next.js の機能に関係なく、Amplify JavaScript ライブラリでカバーできます。 Next.js アダプタは、Amplify Libraries を “Amplify Server Context” 内で実行することを可能にし、クラウド上で Amplify Libraries の機能を安全に使用する方法を提供します。 runWithAmplifyServerContext コールバックは、リクエストをサーバーサイドで自動的に分離し、クロスリクエストの状態汚染問題を回避します。 以下は、保護されたルートを実装するために、Next.js Middleware で Amplify Auth を使用する方法の例です。 import { runWithAmplifyServerContext } from '@aws-amplify/adapter-nextjs'; import { fetchAuthSession } from 'aws-amplify/auth/server'; import { NextRequest, NextResponse } from 'next/server'; export async function middleware(request: NextRequest) { const response = NextResponse.next(); const authenticated = await runWithAmplifyServerContext({ nextServerContext: { request, response }, operation: async (contextSpec) => { try { const session = await fetchAuthSession(contextSpec, {}); return session.tokens !== undefined; } catch (error) { console.log(error); return false; } }, }); if (authenticated) { return response; } return NextResponse.redirect(new URL('/sign-in', request.url)); } export const config = { matcher: [ /* * Match all request paths except for the ones starting with: * - api (API routes) * - _next/static (static files) * - _next/image (image optimization files) * - favicon.ico (favicon file) */ '/((?!api|_next/static|_next/image|favicon.ico|sign-in).*)', ], }; 始め方 これらの新しい機能拡張については、 ドキュメント をご覧ください。お客様がすぐに使い始められるよう、豊富なガイドと実用例をご用意しています。また、今後の機能拡張については Q4 のフォーカスエリア もご覧ください。 この Developer Preview は、AWS Amplify をモダンなアプリケーション開発のための最適なソリューションにするという我々のコミットメントを反映しています。しかし、まだ Day1 です。新機能をお試しいただき、 この RFC でご意見をお聞かせください 。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。