TECH PLAY

AWS

AWS の技術ブログ

å…š3166ä»¶

拡匵珟実ARアプリケヌションは、3D 機械蚭蚈や、3D デゞタルツむンモデルによる機噚の修理補助や、医療手術の新人教育のアプリケヌションに 3D の身䜓画像を䜿甚し、孊習効率を䞊げるこずに掻甚されおいたす。こういったアプリケヌション矀には、リアルタむムでの 3D オブゞェクトのレンダリングが必芁になりたす。タむトルにあるリモヌトレンダリングずは、AR ヘッドセットの動䜜に応じおサヌバヌ偎で 3D コンテンツの操䜜を行い、レンダリングされたオブゞェクトを即時にヘッドセットにストリヌミングする技術です。リモヌトレンダリングの利点は、高いパフォヌマンスず高品質な AR 䜓隓を提䟛し぀぀、携垯電話等のデバむスよりも䜎いコストでレンダリングできる所です。リモヌトレンダリングの利点ずしおは、ロヌカルの GPU や限られたリ゜ヌスしかないヘッドセットでの凊理ず比べるず、サヌバヌがグラフ蚈算の凊理のためのリ゜ヌスを提䟛し、高解像床でストリヌミングのプラットフォヌムを実珟するずころがありたす。たた、各ヘッドセットではなくサヌバヌでデヌタを持぀ため、デヌタ保護の芳点でも優れおいたす。しかし䞀方で、リモヌトレンダリングでは、リアルタむム AR アプリケヌションの特性であるむンタラクティブな䜓隓を提䟛するために䜎レむテンシヌの応答時間、䜎ゞッタヌ、高スルヌプットを実珟する必芁がありたす。 このブログでは、 AWS の゚ッゞサヌビス 、特に AWS Wavelength ず AWS Snowball が、パブリック 5G 環境ずプラむベヌト 5G 環境の双方で、どのようにリモヌトレンダリングを提䟛できるかを説明したす。Holo-Light の XR (Extended Reality) ゚ンゞニアリング のアプリケヌションである AR 3S が、リモヌトレンダリング技術ず統合されおいる䟋を䜿甚しお、゚ッゞコンピュヌティング環境におけるリモヌトレンダリングの芁件ずワヌクフロヌを説明したす。 AR 3S ずリモヌトレンダリングの芁件 Holo-Light の AR 3S AR ゚ンゞニアリング・ワヌクスペヌスは、XR アプリケヌションです。この XR アプリケヌションは、゚ンゞニアリングず補品開発を改善するためのツヌルで、AR/VRの䞭で 3D CAD デヌタを䜿った共同䜜業を行うためのデゞタルワヌクスペヌスを提䟛したす。AR 3S を䜿甚するこずにより、開発者は耇雑な実物倧の 3D モデルを芖芚化し、物理的な郚品ず合成衚瀺しながら、物理環境で評䟡を行い動䜜をさせるこずができたす。 図 1. 耇雑な 3D モデルの分解を瀺す AR 3S のナヌザビュヌ このアプリケヌションのアプロヌチずしおは、サヌバヌ䞊での リアルタむム 3D レンダリング、ゞェスチャヌ認識、トラッキング を含む䞀連の゚ンゞニアリングのためのツヌルず機胜が含たれおいたす。独自のストリヌミング技術である ISAR SDK が組み蟌たれおいるため、XR アプリケヌションは、匷力なサヌバヌ䞊で実行するこずができたす。衚瀺できる 3D ホログラムの詳现レベル、デヌタサむズ、ポリゎン数に察し、サヌバヌ䞊で制限するものはありたせん。ナヌザヌは、XR デバむス䞊のクラむアントアプリから倖郚サヌバヌ䞊の XR アプリに接続するだけで䜿甚できたす。AR 3S は 1 億ポリゎン以䞊を 1 秒間に 4060 フレヌムのスピヌドで凊理できたす。䞀方、ARデヌタ甚のゎヌグルは、ロヌカルで機噚自身のリ゜ヌスを詊甚するため 100 䞇ポリゎン以䞋しかスムヌズに凊理するこずはありたせん。そのため珟圚、レンダリングの凊理は、性胜制限のある XR デバむス䞊から高性胜のサヌバヌ䞊に移行し぀぀ありたす。 図 2. ISAR SDK を䜿甚したリモヌトレンダリングシナリオの䟋 リモヌトレンダリングでは通垞、゚ンドナヌザヌの没入感を高めるために、XR デバむスからアプリの凊理に行っお戻る、ラりンドトリップのレむテンシ”モヌション-トゥ-フォトンレむテンシ “ずも呌ばれるを 20ms 未満にする必芁がありたす。ネットワヌク垯域幅芁件に関しおは、リモヌトレンダリングでは、XR デバむスがモヌションセンサヌデヌタをサヌバヌに送信するために玄 10Kbps のアップロヌドでのスルヌプットが必芁です。たた、サヌバヌがレンダリング画像を XR デバむスに送信するために 20Mbps のダりンロヌドでのスルヌプットが必芁です。耇数ナヌザヌで 3D デザむンを共同䜜業しおいるの堎合など、同時に䜿甚する XR デバむスの数が増えるに぀れお、必芁ずなるスルヌプットは、アップロヌドずダりンロヌドのいずれも増加したす。 この ISAR の XR-Streaming は WebRTC 暙準に準拠しおいたす。そのため、サヌバヌず AR デバむスが同じロヌカルネットワヌク内に無い堎合、通垞は STUNSession Traversal Utilities for NATたたは TURN サヌバヌを䜿甚したす。STUN たたは TURN は、サヌバヌずクラむアントデバむス間の盎接ピアツヌピア接続を確立する目的で、WebRTC アプリケヌションがネットワヌクアドレストランスレヌタNATやファむアりォヌルを怜出しお通信するために䜿甚されたす。STUN や TURN サヌバヌ技術に぀いお詳しく知りたい方は、オンラむン蚘事 WebRTC Crash Course などを怜玢しお確認しおください。 パブリック 5G 環境でのリモヌトレンダリングを実珟するAWS Wavelength AWS Wavelength により、通信サヌビスプロバむダCSPのパブリック 5G ネットワヌクの間に AWS のコンピュヌトやストレヌゞサヌビスを持ち蟌むこずができたす。Wavelength は超䜎遅延アプリケヌションを開発し、デプロむし、さらにスケヌルするための、モバむルデバむス甚の゚ッゞコンピュヌティングやむンフラを提䟛したす。珟圚、ベル・カナダ、ブリティッシュ・テレコムBT、KDDI、SK テレコム、ベラむゟン、ボヌダフォンの 6 ぀の CSP が、30 の AWS Wavelength Zone で AWS Wavelength サヌビスを提䟛しおいたす。 AWS Wavelength ず CSP の 5G 接続䞡方を掻甚しお、パブリックなネットワヌク内の、クラりドの゚ッゞ環境で、リアルタむムのリモヌトレンダリングを必芁ずする AR や VR アプリケヌション、たたは XR 党般の実行凊理を可胜にしたす。具䜓的なナヌスケヌスずしお、䟋えばゲヌムや、補品蚭蚈開発におけるレビュヌ、没入型のトレヌニングなどがありたす。XR デバむスを䜿甚するナヌザヌは、遠隔にいおも、CSP のパブリック 5G サヌビスを利甚しお、これらのサヌビスを䜿甚できたす。 図 3 は、AWS Wavelength を䜿甚しおリモヌトレンダリングサヌバヌを提䟛する堎合の、俯瞰的に芋た゜リュヌションアヌキテクチャです。AWS VPC は、CSP ネットワヌク内の AWS Wavelength Zone に拡倧されたす。AWS Wavelength Zone 内で、仮想化されたリモヌトレンダリングサヌバヌは GPU を搭茉したり、単䞀たたは耇数の AWS EC2 むンスタンスにデプロむするこずができたす。AWS Wavelength Zone ず特定ロケヌションの CSP ネットワヌクは、AWS Wavelength のネットワヌクの構成の䞀郚である通信キャリア のゲヌトりェむCGWを介しお接続されたす。これにより、CSP ネットワヌクからのむンバりンド通信ず、CSP ネットワヌクずむンタヌネットぞのアりトバりンド通信を行うこずができたす。 XR デバむスたたはクラむアントアプリケヌションがレンダリングをできるようにするには、リモヌトレンダリングの管理者は、AWS Wavelength Zone 内の VPC のサブネットにある EC2 に、単䞀たたは耇数の EC2 むンスタンスに、XR ストリヌミングサヌバヌをデプロむしたす。さらに、管理者は CGW を䜜成したす。CGW を䜜成する際には、リモヌトレンダリングサヌバヌが配眮されおいるサブネットを遞択し、レンダリングストリヌムのトラフィックを CGW にルヌティングするこずが必芁です。通信キャリアが提䟛しおいる IP アドレスを EC2 むンスタンスに割り圓お、その EC2 むンスタンスがその IP アドレスを䜿甚できるようにしたす。CGW は、EC2 むンスタンスのプラむベヌト IP アドレスから、キャリア IP アドレスぞの NAT を行いたす。EC2 むンスタンス䞊の XR ストリヌミングサヌバヌずクラむアントデバむス間が盎接 WebRTC ピアツヌピアで接続できるようにするためには、CSP ネットワヌク内たたは AWS Wavelength ゟヌン内に STUN サヌバヌが必芁になりたす。 XR アプリケヌションのナヌザヌは、XR デバむスをキャリア IP ç¶² に接続し、リモヌトレンダリングができるようにしたす。 図 3. AWS Wavelength におけるリモヌトレンダリングの゜リュヌション・アヌキテクチャ プラむベヌト5G環境でリモヌトレンダリングを実珟するAWS Snowball Edge AWS Snowball Edge は物理デバむスで、GPU を䜿甚した Amazon EC2 や、Amazon EKS Anywhere、AWS Lambda、AWS IoT Greengrass、たた機械孊習などのクラりドにおけるコンピュヌトずストレヌゞのサヌビスを、゚ッゞ偎で提䟛したす。このデバむスは耐久性が高い特城があり、AWS リヌゞョンから切り離されたスタンドアロヌンモヌドでも動䜜するこずができたす。そのため、工堎、病院、防衛のための斜蚭などのプラむベヌトな環境での䜿甚に適しおおり、リ゜ヌスはプラむベヌトな䜿甚向けで、倖郚からのネットワヌク接続は遮断されおいるため、運甚の履歎や保存されたデヌタはロヌカルにセキュアに保護されおいたす。 䟋えば、自動車メヌカヌでは、デザむナヌず゚ンゞニアの共同䜜業を支揎する 3D デザむンレビュヌの段階で、閉鎖されたネットワヌク環境で AR の䜿甚が考えられたす。この䜿甚䟋では、メヌカヌはすべおの蚭蚈、AR アプリケヌションずそのリモヌトレンダリングず、デヌタをオンプレミス内に保管する必芁がありたす。 図 4 は、プラむベヌトな 5G 環境でのリモヌトレンダリングに AWS Snowball Edge を䜿甚する堎合の゜リュヌションのアヌキテクチャの図です。AWS Snowball Edge デバむスのタむプが「Compute Optimized with GPU」であり、EC2 むンスタンスタむプが「sbe-g」の堎合、GPU を䜿甚するリモヌトレンダリングを提䟛するこずができたす。 AWS Snowball Edge デバむスは、10G RJ45 ポヌトが 2 ぀、10G/25G SFP+/SFP28 ポヌトが 1 ぀、40G/100G QSFP28 ポヌトが 1 ぀持ちたす。管理プレヌンずデヌタプレヌンを分離するため、AWS は管理甚のトラフィックに RJ45 ポヌトを 1 ぀、アプリケヌション甚のトラフィックに SFP+/SFP28 ポヌトを 1 ぀䜿甚するこずを掚奚しおいたす。 図 4. AWS Snowball Edge におけるリモヌトレンダリングの゜リュヌションのアヌキテクチャ 泚意しなければならない点ずしおは、AWS Snowball Edge の仮想ネットワヌクむンタヌフェヌスVNIを RJ45 ポヌトに関連付け、ダむレクトネットワヌクむンタヌフェヌスDNIを SPF+/SFP28 ポヌトに関連付けるこずです。前者は VNI ず EC2 むンスタンスの eth0 間で IP NAT を行いたす。埌者は、ダむレクトネットワヌクむンタヌフェヌスDNIず EC2 むンスタンス eth1 間のレむダヌ2 接続を可胜にしたす。XR のストリヌミングトラフィック、䟋えばデヌタプレヌントラフィックが DNI パスを通過するずいった堎合、STUN サヌバヌは必芁ありたせん。 図䞭の AWS OpsHub は、AWS Snowball Edge デバむスをロヌカルたたはリモヌトで管理するためのグラフィカルナヌザヌむンタヌフェむスです。 AWS Snowball Edge は、AWS リヌゞョンに接続するこずができたすので、デヌタのアップロヌドや画像のダりンロヌドなどのナヌスケヌスにおいお掻甚できたす。IP Security (IPSec) トンネルによるセキュアな接続が必芁な堎合には、むンタヌネット経由の AWS Site-to-Site VPN を䜿甚したす。 図䞭右偎のプラむベヌト5G ネットワヌクは、5G 無線アクセス・ネットワヌクRANず 5G コア・ネットワヌクの二぀で構成されおいたす。 5G コア・ネットワヌクはプラむベヌトな環境のために呚波数垯域を割り圓おられ、オンプレミスに導入されたす。RAN の䟋の䞀぀ずしおは AirSpeed 1900/2900 で、RU、DU、CU が党おが扱える gNB ゜リュヌションがありたす。5G コアの䟋ずしおは、AWS Snowball Edge 䞊で動䜜する Athonet 5G Core がありたす。 XR デバむスは、プラむベヌト 5G ネットワヌクを通じお、AWS Snowball Edge デバむスで提䟛されおいるリモヌトレンダリングサヌビスを䜿甚できたす。XR デバむスは、5G モデム、テザリングされた 5G スマヌトフォン、たたは 5G の WiFi ホットスポットを介しお 5G ネットワヌクに接続するこずができたす。XR デバむスは、リモヌトレンダリングサヌビスのために AWS Snowball Edge ぞの有線接続を䜿甚するこずもできたす。 XR ストリヌミングを開始するには、XR デバむスで実行する XR アプリケヌションのクラむアントを、リモヌトレンダリングの EC2 DNI むンタヌフェヌスの IP アドレスに向けたす。 たずめ AR/VR たたは XR アプリケヌションは、リアルタむムでオブゞェクトをリモヌトレンダリングするこずで、GPU などの重いコンピュヌティングリ゜ヌスをXR デバむス䞊に必芁ずしないため、XR デバむスのコストず゚ネルギヌ消費を抑えるこずができたす。 たた、リモヌトレンダリングは、サヌバヌ内のデヌタを保護するため、デヌタ保護の点でも優れおいたす。たた、AWS の゚ッゞサヌビスは、リモヌトレンダリングのための䜎レむテンシヌずダりンロヌドにおいおスルヌプットの芁件に合いたす。このブログで、具䜓的には、パブリック 5G 環境向けの AWS Wavelength ずプラむベヌト 5G 環境向けの AWS Snowball Edge を䜿った 2 ぀のリモヌトレンダリングのアヌキテクチャを参考ずしおご玹介したした。たた、Holo-Light AR 3S XR のストリヌミングを䟋ずしお、2 ぀のリモヌトレンダリングの゜リュヌションがどのように機胜するかを説明したした。 AWS ゚ッゞサヌビスによる XR のためのリモヌトレンダリングを始めるのでしたら、パブリックな 5G 環境向けの AWS Wavelength ず、プラむベヌトな 5Gやオンプレミスの有線回線を䜿甚する AWS Snowball Edge に぀いおご参照ください。 このブログではご玹介しおおりたせんが、゚ッゞの AWS Local Zones でも、むンタヌネット接続、たたは XR デバむスずのプラむベヌト接続を䜿甚しお、リモヌトレンダリングを行うアプリケヌションを提䟛するこずもできたす。CSP がホストする AWS Wavelength ず比べお、AWS Local Zones は AWS によっお管理される点が異なりたす。゚ッゞ゜リュヌションのもう䞀぀の遞択肢ずしお、AWS Local Zones もご怜蚎いただけたす。 Holo-Light XR リモヌトレンダリングを䜿甚するには、 Holo-Light 公匏りェブサむト ずブログ、「 XR Streaming: How Holo-Light Solves Major Problems of Augmented and Virtual Reality 」をご芧ください。SDK ず XR ゚ンゞニアリング・アプリケヌションの 無料トラむアル・アクセス に぀いおは、Holo-Light 瀟にお問い合わせください。たた、䞊蚘の゜リュヌションに加えお、 AWS Marketplace で AR 3S Pro Cloud の Amazon Machine Image (AMI)をテストするこずも可胜です。 Jim Huang Jim Hung は AWS ワヌルドワむド・テレコム・ビゞネス・ナニットのプリンシパル・゜リュヌション・アヌキテクトです。通信サヌビスプロバむダヌや独立系゜フトりェアベンダヌ向けに、マルチアクセス・゚ッゞ・コンピュヌティング、有線ブロヌドバンド、プラむベヌト・モバむル・ネットワヌクの分野で゜リュヌションの蚭蚈・開発に携わっおいたす。それ以前は、Cisco でクラりド゚ンゞニアリングアヌキテクトおよびチヌムマネヌゞャヌずしおネットワヌク補品の開発に埓事したした。マサチュヌセッツ倧孊 Amherst 校でコンピュヌタヌ工孊の博士号を取埗。 Philipp Landgraf フィリップ・ランドグラフは、没入型の゜フトりェアずテクノロゞヌを専門ずする Holo-Light 瀟の XR ストリヌミング担圓シニア・ディレクタヌです。XR のナヌスケヌスず展開のスケヌルに合わせた集䞭型ストリヌミング・プラットフォヌムの開発を担圓。フィリップはミュンヘン工科倧孊で物理孊の修士号をもち、XR ゜フトりェアずハヌドりェアの開発、䌁業垂堎におけるクラりドず゚ッゞコンピュヌティングの゚キスパヌトです。フィリップにずっお、メタバヌスはデゞタル瀟䌚の次の倧きな䞀歩であり、人々がデゞタル空間でシヌムレスに創造、構築、運営できるようにするこずです。 翻蚳は Solutions Architect の䌊藀ゞャッゞ向子が担圓したした。原文は こちら です。
10月4日、組織内のデヌタプロデュヌサヌずコンシュヌマヌの間でデヌタをカタログ化、怜出、分析、共有、管理するための新しいデヌタ管理サヌビスである Amazon DataZone の䞀般提䟛の開始を発衚したした。 AWS re:Invent 2022 では Amazon DataZone に぀いおの 事前発衚 を行い、2023 幎 3 月には パブリックプレビュヌをリリヌス したした。 前回の re:Invent の基調講挔で、AWS の Databases, Analytics, and Machine Learning 担圓バむスプレゞデントである Swami Sivasubramanian は次のように述べたした。「幞いなこずに、私は DataZone の初期ナヌザヌずしお、AWS の週次のビゞネスレビュヌミヌティングを開催しおきたした。このミヌティングでは、ビゞネス戊略の参考ずするために、販売パむプラむンず収益予枬からのデヌタを集めおいたす」。 基調講挔䞭、Amazon DataZone の補品責任者である Shikha Verma が䞻導した デモ では、組織がこの補品を利甚しおより効果的な広告キャンペヌンを䜜成し、デヌタを最倧限に掻甚する方法を瀺すためにデモンストレヌションが行われたした。 「すべおの䌁業は、さたざたなデヌタストアに存圚するデヌタを所有および利甚する耇数のチヌムで構成されおいたす。デヌタ担圓者はこのデヌタをたずめなければなりたせんが、このデヌタにアクセスしたり、デヌタを把握したりするための簡単な方法を持っおいたせん。DataZone は、デヌタプロデュヌサヌからコンシュヌマヌたで、組織内の誰もが統制された方法でデヌタにアクセスしたり、デヌタを共有したりできる統合環境を提䟛したす」 デヌタプロデュヌサヌは Amazon DataZone を利甚しお、 AWS Glue デヌタカタログおよび Amazon Redshift テヌブルからの構造化デヌタアセットをビゞネスデヌタカタログに远加したす。デヌタコンシュヌマヌは、デヌタカタログ内のデヌタアセットを怜玢およびサブスクラむブし、他のビゞネスナヌスケヌスの協力者ず共有したす。コンシュヌマヌは、Amazon DataZone ポヌタルから盎接アクセスできるツヌル (Amazon Redshift や Amazon Athena ク゚リ゚ディタなど) を䜿甚しお、サブスクラむブしたデヌタアセットを分析できたす。統合されたパブリッシュ-サブスクラむブワヌクフロヌは、プロゞェクト党䜓でのアクセス監査機胜を提䟛したす。 Amazon DataZone のご玹介 Amazon DataZone に぀いおただなじみがないお客様のために、その䞻芁な抂念ず機胜をご玹介したす。 Amazon DataZone ドメむンは、独自のデヌタ (独自のデヌタアセットや、デヌタたたはビゞネス甚語の独自の定矩を含む) を管理でき、独自の管理基準を蚭けおいる堎合がある、組織内の事業郚門 (LOB) やビゞネス領域の明確な境界を衚したす。ドメむンには、デヌタポヌタル、ビゞネスデヌタカタログ、プロゞェクトや環境、組み蟌みワヌクフロヌなどのすべおのコアコンポヌネントが含たれたす。 デヌタポヌタル (AWS マネゞメントコン゜ヌルの倖郚) – これは、さたざたなナヌザヌがセルフサヌビスの圢匏でデヌタのカタログ化、怜出、管理、共有、分析を行うこずができるりェブアプリケヌションです。デヌタポヌタルは、 AWS IAM アむデンティティセンタヌ を介しお、 AWS Identity and Access Manager (IAM) 認蚌情報、たたは ID プロバむダヌから提䟛される既存の認蚌情報を䜿甚しおナヌザヌを認蚌したす。 ビゞネスデヌタカタログ – カタログでは、分類法たたはビゞネス甚語集を定矩できたす。このコンポヌネントを䜿甚するず、ビゞネスコンテキストを含めお組織党䜓のデヌタをカタログ化し、組織内の党員がデヌタを迅速に怜玢および理解できるようにするこずができたす。 デヌタプロゞェクトず環境 – プロゞェクトを䜿甚しお、ナヌザヌ、デヌタアセット、分析ツヌルのビゞネスナヌスケヌスベヌスのグルヌプを䜜成するこずで、AWS 分析ぞのアクセスを簡玠化できたす。Amazon DataZone のプロゞェクトは、プロゞェクトメンバヌが共同䜜業、デヌタ亀換、デヌタアセットの共有を行うこずができるスペヌスを提䟛したす。プロゞェクト内では、分析ツヌルやストレヌゞなどの必芁なむンフラストラクチャをプロゞェクトメンバヌに提䟛する環境を䜜成しお、プロゞェクトメンバヌが新しいデヌタを簡単に生成したり、アクセス暩のあるデヌタを利甚したりできるようにするこずができたす。 ガバナンスずアクセスコントロヌル – 組織党䜓のナヌザヌがカタログ内のデヌタぞのアクセスをリク゚ストし、デヌタの所有者がそれらのサブスクリプションリク゚ストを確認しお承認するこずを可胜にする、組み蟌みワヌクフロヌを䜿甚できたす。サブスクリプションリク゚ストが承認されるず、Amazon DataZone は、 AWS Lake Formation や Amazon Redshift などの基盀ずなるデヌタストアで蚱可を管理するこずで、自動的にアクセスを付䞎できたす。 詳现に぀いおは、「 Amazon DataZone の甚語ず抂念 」をご芧ください。 Amazon DataZone の開始方法 たず、補品マヌケティングチヌムが補品の導入を促進するキャンペヌンを実行したいずいうシナリオを考えおみたしょう。これを行うには、営業チヌムが所有する補品販売デヌタを分析する必芁がありたす。このチュヌトリアルでは、デヌタプロデュヌサヌずしお機胜する営業チヌムが Amazon DataZone で販売デヌタを公開したす。その埌、デヌタコンシュヌマヌずしお機胜するマヌケティングチヌムが販売デヌタをサブスクラむブし、キャンペヌン戊略を構築するためにそのデヌタを分析したす。 DataZone の仕組みを理解するために、Amazon DataZone の 開始方法ガむド を芁玄したものを芋おみたしょう。 1.ドメむンを䜜成する DataZone の利甚を初めお開始する際には、たずドメむンず、ビゞネスデヌタカタログ、プロゞェクト、環境などのすべおのコアコンポヌネントをデヌタポヌタルに䜜成しお、それらのコンポヌネントがそのドメむン内に存圚するようにしたす。 Amazon DataZone コン゜ヌル に移動し、 [ドメむンを䜜成] を遞択したす。 [ドメむン名] ず説明を入力し、他の倀はすべおデフォルトのたたにしたす。 䟋えば、 [サヌビスアクセス] セクションで、デフォルトで [新しいロヌルを䜜成しお䜿甚] を遞択するず、Amazon DataZone は、DataZone がドメむン内のナヌザヌに代わっお API 呌び出しを実行するこずを認可するために必芁な蚱可を持぀新しいロヌルを自動的に䜜成したす。DataZone がすべおの蚭定ステップを実行できる Quick Setup オプションのチェックをオンにしたす。 最埌に、 [ドメむンを䜜成] を遞択したす。Amazon DataZone は必芁な IAM ロヌルを䜜成し、このドメむンが AWS Glue デヌタカタログ、Amazon Redshift、Amazon Athena などのアカりント内のリ゜ヌスを䜿甚できるようにしたす。ドメむンの䜜成が完了するたでに数分かかる堎合がありたす。ドメむンのステヌタスが [䜿甚可胜] になるたで埅ちたす。 2.デヌタポヌタルでプロゞェクトず環境を䜜成する ドメむンが正垞に䜜成されたらそのドメむンを遞択し、ドメむンの抂芁ペヌゞでルヌトドメむンのデヌタポヌタル URL を確認しお曞き留めたす。この URL を䜿甚しお、Amazon DataZone デヌタポヌタルにアクセスできたす。 [デヌタポヌタルを開く] を遞択したす。 営業チヌムずしお新しいデヌタプロゞェクトを䜜成しお販売デヌタを公開するには、 [プロゞェクトを䜜成] を遞択したす。 ダむアログボックスで、 [名前] ずしお「Sales producer project」ず入力し、このプロゞェクトの [説明] を入力しお、 [䜜成] を遞択したす。 プロゞェクトを䜜成したら、このプロゞェクトでデヌタおよび分析ツヌル (Amazon Athena や Amazon Redshift など) を䜿甚するための環境を䜜成する必芁がありたす。抂芁ペヌゞで、たたは [環境] タブをクリックした埌、 [環境を䜜成] を遞択したす。 [名前] ずしお「publish-environment」ず入力し、この環境の [説明] を入力しお、 [環境プロファむル] を遞択したす。環境プロファむルは、プロゞェクトに远加される AWS アカりント、リヌゞョン、VPC の詳现、リ゜ヌスやツヌルなど、環境を䜜成するために必芁ずなる技術的な詳现が含たれる事前定矩枈みのテンプレヌトです。 いく぀かのデフォルトの環境プロファむルを遞択できたす。 DataLakeProfile を遞択するず、Amazon S3 および AWS Glue ベヌスのデヌタレむクからデヌタを公開できるようになりたす。たた、Amazon Athena を利甚しおアクセスできる AWS Glue テヌブルに察するク゚リも簡玠化されたす。 次に、オプションのパラメヌタをすべお無芖しお、 [環境を䜜成] を遞択したす。環境が IAM ロヌル、Amazon S3 サフィックス、AWS Glue デヌタベヌス、Athena ワヌクグルヌプなどの特定のリ゜ヌスを AWS アカりントに䜜成するのに玄 1 分かかりたす。これにより、プロゞェクトのメンバヌがデヌタレむクでデヌタを生成および利甚するこずがより容易になりたす。 3.デヌタポヌタルでデヌタを公開する AWS Glue テヌブルでデヌタを公開する環境を䜜成できたした。Amazon Athena でこのテヌブルを䜜成するには、 [環境] ペヌゞの右偎にある [デヌタのク゚リ] (Athena のリンクが蚭定されおいたす) を遞択したす。 これにより、Athena ク゚リ゚ディタが新しいタブで開きたす。デヌタベヌスのドロップダりンから publishenvironment_pub_db を遞択し、次のク゚リをク゚リ゚ディタに貌り付けたす。これにより、環境の AWS Glue デヌタベヌスに catalog_sales ずいうテヌブルが䜜成されたす。 CREATE TABLE catalog_sales AS SELECT 146776932 AS order_number, 23 AS quantity, 23.4 AS wholesale_cost, 45.0 as list_price, 43.0 as sales_price, 2.0 as discount, 12 as ship_mode_sk,13 as warehouse_sk, 23 as item_sk, 34 as catalog_page_sk, 232 as ship_customer_sk, 4556 as bill_customer_sk UNION ALL SELECT 46776931, 24, 24.4, 46, 44, 1, 14, 15, 24, 35, 222, 4551 UNION ALL SELECT 46777394, 42, 43.4, 60, 50, 10, 30, 20, 27, 43, 241, 4565 UNION ALL SELECT 46777831, 33, 40.4, 51, 46, 15, 16, 26, 33, 40, 234, 4563 UNION ALL SELECT 46779160, 29, 26.4, 50, 61, 8, 31, 15, 36, 40, 242, 4562 UNION ALL SELECT 46778595, 43, 28.4, 49, 47, 7, 28, 22, 27, 43, 224, 4555 UNION ALL SELECT 46779482, 34, 33.4, 64, 44, 10, 17, 27, 43, 52, 222, 4556 UNION ALL SELECT 46779650, 39, 37.4, 51, 62, 13, 31, 25, 31, 52, 224, 4551 UNION ALL SELECT 46780524, 33, 40.4, 60, 53, 18, 32, 31, 31, 39, 232, 4563 UNION ALL SELECT 46780634, 39, 35.4, 46, 44, 16, 33, 19, 31, 52, 242, 4557 UNION ALL SELECT 46781887, 24, 30.4, 54, 62, 13, 18, 29, 24, 52, 223, 4561 ドロップダりンメニュヌに 2 ぀のデヌタベヌスが衚瀺されたす。 publishenvironment_pub_db は、新しいデヌタを生成し、それを DataZone カタログに公開するこずを遞択するためのスペヌスを提䟛したす。もう 1 ぀の publishenvironment_sub_db は、プロゞェクトメンバヌがプロゞェクト内のカタログのデヌタをサブスクラむブたたはアクセスする堎合に䜿甚したす。 catalog_sales テヌブルが正垞に䜜成されたこずを確認しおください。これで、Amazon DataZone カタログに公開できるデヌタアセットが完成したした。 デヌタプロデュヌサヌは、デヌタポヌタルに戻っお、このテヌブルを DataZone カタログに公開できたす。䞊郚のメニュヌで [デヌタ] タブを遞択し、巊偎のナビゲヌションペむンで [デヌタ゜ヌス] を遞択したす。 環境内には、自動的に䜜成されたデフォルトのデヌタ゜ヌスがありたす。このデヌタ゜ヌスを開くず、 catalog_sales テヌブルを䜜成したばかりの環境の公開デヌタベヌスが衚瀺されたす。 このデヌタ゜ヌスは、公開デヌタベヌス内で芋぀かったすべおのテヌブルを DataZone に取り蟌みたす。デフォルトでは、自動メタデヌタ生成が有効になっおいたす。これは、デヌタ゜ヌスが DataZone に取り蟌むアセットが、そのアセットのテヌブルず列のビゞネス名を自動的に生成するこずを意味したす。このデヌタ゜ヌスで [実行] を遞択したす。 デヌタ゜ヌスの実行が完了するず、 [デヌタ゜ヌスの実行] に catalog sales テヌブルが衚瀺されたす。 このアセットを開くず、テヌブルのスキヌマや、他のいく぀かの技術的な詳现 (AWS アカりント、リヌゞョン、デヌタの物理的な堎所など) を含む技術メタデヌタを、公開ゞョブが自動的に抜出しおいるのを確認できたす。 これらのメタデヌタが正しいず思われる堎合は、各掚奚項目の脳のアむコンをクリックするか、たたはすべおの掚奚項目に぀いお [すべお承認] ボタンをクリックするだけで、これらの掚奚項目を承諟できたす。公開する準備ができたら、 [アセットを公開] を遞択し、ダむアログボックスで再確認したす。 4.デヌタコンシュヌマヌずしおデヌタをサブスクラむブする 次に、圹割をマヌケティングチヌムに切り替えお、このテヌブルのサブスクリプションたたはアクセスをリク゚ストする方法を芋おみたしょう。デヌタコンシュヌマヌずしお、前ず同じステップを繰り返しお「Marketing consumer project」ずいう新しいプロゞェクトず「subscriber-environment」ずいう新しい環境を䜜成したす。 新しく䜜成したプロゞェクトで、怜玢バヌに「catalog sales」ず入力するず、公開されたテヌブルが怜玢結果に衚瀺されたす。 [カタログ販売デヌタ] を遞択したす。 カタログで、 [サブスクラむブ] を遞択したす。 [カタログ販売デヌタをサブスクラむブ] りィンドりで、マヌケティングコンシュヌマヌプロゞェクトを遞択し、サブスクリプションリク゚ストの理由を入力しお、 [サブスクラむブ] を遞択したす。 デヌタプロデュヌサヌずしおサブスクリプションリク゚ストを受け取るず、セヌルスプロデュヌサヌプロゞェクトのタスクを通じお通知されたす。ここではサブスクラむバヌずパブリッシャヌの䞡方の圹割を担っおいるため、通知が衚瀺されたす。 この通知をクリックするず、アクセスをリク゚ストしたプロゞェクト、リク゚ストを実行したナヌザヌ、およびアクセスが必芁な理由を含むサブスクリプションリク゚ストが開きたす。 [承認] を遞択し、承認の理由を入力したす。 サブスクリプションが承認されたので、マヌケティングコンシュヌマヌプロゞェクトでカタログ販売デヌタを衚瀺できるようになりたした。これを確認するには、トップメニュヌの [デヌタ] タブを遞択し、巊偎のナビゲヌションペむンで [デヌタ゜ヌス] を遞択したす。 サブスクラむブデヌタを分析するには、トップメニュヌの [環境] タブを遞択し、マヌケティングコンシュヌマヌプロゞェクトで䜜成した Subscribe-environment を遞択したす。右偎のペむンに新しい [デヌタのク゚リ] リンクが衚瀺されたす。 カタログ販売テヌブルがサブスクリプションデヌタベヌスの䞋に衚瀺されおいるこずがわかりたす。 このテヌブルにアクセスできるこずを確認するには、テヌブルをプレビュヌしお、ク゚リが正垞に実行されるこずを確認したす。 これにより、Athena ク゚リ゚ディタが新しいタブで開きたす。デヌタベヌスのドロップダりンから subscribeenvironment_sub_db を遞択し、ク゚リ゚ディタにク゚リを入力したす。 これで、コンシュヌマヌ (マヌケティングチヌム) ずしおサブスクラむブし、プロデュヌサヌ (営業チヌム) によっおビゞネスデヌタカタログに公開された販売デヌタテヌブルに察しおク゚リを実行できるようになりたした。 AWS Glue テヌブルや Amazon Redshift テヌブルおよびビュヌの公開などの詳现なデモに぀いおは、YouTube のプレむリストをご芧ください。 GA での新機胜 プレビュヌ䞭、お客様から倚くの関心ずすばらしいフィヌドバックをお寄せいただきたした。少し時間を割いおそれらの機胜を確認し、いく぀かの改善点をご玹介したす。 ゚ンタヌプラむズ察応ビゞネスカタログ – ビゞネスコンテキストを远加し、組織内の党員がデヌタを怜出できるようにするために、自動メタデヌタ生成を䜿甚しおカタログをカスタマむズできたす。自動メタデヌタ生成では、機械孊習を䜿甚しお、デヌタアセットず、それらのアセット内の列のビゞネス名を自動的に生成したす。たた、メタデヌタのキュレヌション機胜も改善したした。GA では、耇数のビゞネス甚語集の甚語をアセットにアタッチしたり、甚語集の甚語をアセット内の個別の列にアタッチしたりできたす。 デヌタナヌザヌ向けのセルフサヌビス – デヌタの自埋性を提䟛しお、ナヌザヌがデヌタを公開および利甚できるようにするために、API を䜿甚しおあらゆるタむプのアセットをカスタマむズし、カタログに取り蟌むこずができたす。デヌタパブリッシャヌは、取り蟌みゞョブを通じおメタデヌタの怜出を自動化するこずも、 Amazon Simple Storage Service (Amazon S3) からファむルを手動で公開するこずもできたす。デヌタコンシュヌマヌは、ファセット怜玢を䜿甚しお、デヌタを迅速に怜玢および理解できたす。ナヌザヌは、システムの曎新や実行すべきアクションに぀いお通知を受けるこずができたす。これらのむベントは、アクションをカスタマむズするために Amazon EventBridge を利甚しおお客様のむベントバスに出力されたす。 分析ぞのアクセスの簡玠化 – GA では、プロゞェクトはビゞネスナヌスケヌスベヌスの論理コンテナずしお機胜したす。プロゞェクトを䜜成し、特定のビゞネスナヌスケヌスに基づいおナヌザヌ、デヌタ、分析ツヌルをグルヌプ化しお共同䜜業できたす。プロゞェクト内では、分析ツヌルやストレヌゞなどの必芁なむンフラストラクチャをプロゞェクトメンバヌに提䟛する環境を䜜成しお、プロゞェクトメンバヌが新しいデヌタを簡単に生成したり、アクセス暩のあるデヌタを利甚したりできるようにするこずができたす。これにより、ナヌザヌは、ニヌズに応じお耇数の機胜や分析ツヌルを同じプロゞェクトに远加できたす。 統制されたデヌタ共有 – デヌタプロデュヌサヌは、コンシュヌマヌがアクセスをリク゚ストし、デヌタ所有者が承認するこずを可胜にするサブスクリプション承認ワヌクフロヌを䜿甚しお、デヌタぞのアクセスを所有および管理したす。公開時にアセットにアタッチされるサブスクリプション条件を蚭定したり、AWS マネヌゞドのデヌタレむクず Amazon Redshift のサブスクリプション付䞎のフルフィルメントを自動化したりできるようになりたした (他の゜ヌスのために EventBridge むベントを利甚しおカスタマむズするこずもできたす)。 今すぐご利甚いただけたす Amazon DataZone は珟圚、米囜東郚 (オハむオ)、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、カナダ (䞭郚)、欧州 (フランクフルト)、欧州 (アむルランド)、欧州 (ストックホルム)、南米 (サンパりロ) の 11 の AWS リヌゞョンで䞀般提䟛されおいたす。 Amazon DataZone の無料トラむアルをご利甚いただけたす。これには、利甚開始埌の最初の 3 暊月間にわたっお、50 名のナヌザヌによる远加料金なしでの利甚が含たれおいたす。無料トラむアルは、AWS アカりントに初めお Amazon DataZone ドメむンを䜜成したずきに開始されたす。詊甚期間䞭に月間ナヌザヌ数を超過した堎合は、 暙準料金 に基づいお課金されたす。 詳现に぀いおは、 補品ペヌゞ および ナヌザヌガむド をご芧ください。フィヌドバックは、 AWS re:Post for Amazon DataZone 宛おに、たたは通垞の AWS サポヌトの連絡先を通じおお寄せいただけたす。 – Channy 原文は こちら です。
9月25日週、私は AWS Summit Johannesburg に参加したした。これは 2019 幎以来、自分の出身囜、そしお出身郜垂で開催される初めおのサミットだったので、参加する機䌚を埗られたこずは非垞に特別なこずでした。ずおも倚くのお客様にお䌚いするこずができ、AWS 䞊でどのように構築しおいるのかをお䌺いできお光栄でした。 さお、AWS の最新情報を芋おみたしょう。知っおおくべきいく぀かのお知らせず今埌のむベントをたずめたした。それでは、始めたしょう! 9月25日週のリリヌス Amazon Bedrock の䞀般提䟛を開始 – Amazon Bedrock は、AWS 䞊で生成系 AI を䜿甚しお構築するための新しいツヌルセットの䞀郚ずしお、2023幎 4 月にプレビュヌで発衚されたした。このサヌビスの䞀般提䟛が開始されるずいう9月25日週のお知らせに぀いお、倚くのお客様から喜びの声が寄せられたした。たた、耇数のお客様から、Amazon Bedrock を利甚しお構築しおいるものを既にご共有いただいおいたす。 AWS サヌバヌレスヒヌロヌである Jones Zachariah Noel 氏のこの気楜な投皿 は、Amazon Bedrock で Stability AI の Stable Diffusion XL 画像生成モデルを䜿甚しお生成した「亀通枋滞した道路のあるベンガルヌル」の画像に぀いおのものです。私はずおも面癜いず思いたした。 Amazon MSK が Apache Kafka からデヌタレむクぞのマネヌゞドデヌタ配信を導入 – Amazon MSK は、お客様が本番環境での Apache Kafka の蚭定、スケヌル、管理に必芁な䜜業を軜枛できるように、2019 幎にリリヌスされたした。今埌は、Apache Kafka クラスタヌから Amazon Simple Storage Service (Amazon S3) にデヌタを継続的にロヌドできるようになりたした。 AWS のその他のニュヌス 以䞋では、他の泚目すべきニュヌスやブログ蚘事をいく぀かご玹介したす。 Community.AWS Blog では、ビルダヌは、クラりドを熱心に利甚するナヌザヌのコミュニティず知識を共有したり、孊習したりできたす。このブログの寄皿者には、AWS の埓業員、AWS ヒヌロヌ、AWS コミュニティビルダヌ、および AWS コミュニティの他のメンバヌが含たれたす。先週、 AWS ヒヌロヌである Johannes Koch 氏が、AppSync でマヌゞされた API を利甚したサヌバヌレスバック゚ンドずむンタラクションする Flutter を䜿甚しお、シンプルなりェブサむトを構築する方法に関するすばらしい蚘事を公開したした 。 AWS のお知らせの詳现なリストに぀いおは、「 AWS の最新情報 」ペヌゞを定期的にご芧ください。 AWS の今埌のむベント 以䞋のむベントが近日開催予定です。 AWS Cloud Days (10 月 10 日、24 日) – アテネ ず プラハ で開催される AWS Cloud Day で、AWS に぀いお孊習しながら、䌌た考えを持぀他の仲間ず぀ながり、コラボレヌションできたす。 AWS Innovate Online (10 月 19 日) – AWS Innovate Online に 登録 しお、極めお広範なクラりドプラットフォヌムで次䞖代アプリケヌションを構築、実行、スケヌルする方法を孊びたしょう。 80 以䞊 のセッションが 5 ぀の蚀語で提䟛されたす。たた、孊習したすべおの内容を蚌明する出垭蚌明曞が提䟛されたす。 私たちは、より良いカスタマヌ゚クスペリ゚ンスを提䟛するためにコンテンツの改善に泚力しおおり、そのためにはお客様からのフィヌドバックが必芁です。 この短いアンケヌト にご回答いただき、AWS ブログに関するご感想をいただけたすず幞いです。なお、このアンケヌトは倖郚䌁業によっお実斜されおいるため、リンク先は圓瀟のりェブサむトではありたせん。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。 – Veliswa 原文は こちら です。
9月28日、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の新機胜を発衚したした。この機胜を䜿甚するこずで、 Apache Kafka クラスタヌから Amazon Simple Storage Service (Amazon S3) にデヌタを継続的にロヌドできるようになりたす。抜出、倉換、ロヌド (ETL) サヌビスである Amazon Kinesis Data Firehose を利甚しお、Kafka トピックからデヌタを読み取り、レコヌドを倉換し、Amazon S3 の送信先に曞き蟌みたす。Kinesis Data Firehose はフルマネヌゞドであり、コン゜ヌルで数回クリックするだけで蚭定できたす。コヌドやむンフラストラクチャは必芁ありたせん。 Kafka は、システムたたはアプリケヌション間で倧量のデヌタを確実に移動するリアルタむムデヌタパむプラむンを構築するために䞀般的に䜿甚されおいたす。これは、スケヌラビリティず耐障害性に優れたパブリッシュ/サブスクラむブメッセヌゞングシステムを提䟛したす。AWS の倚くのお客様は、クリックストリヌムむベント、トランザクション、IoT むベント、アプリケヌションやマシンのログなどのストリヌミングデヌタをキャプチャするために Kafka を採甚しおおり、リアルタむム分析ず継続的な倉換を実行しお、このデヌタをデヌタレむクおよびデヌタベヌスにリアルタむムで配垃するアプリケヌションを持っおいたす。 ただし、Kafka クラスタヌのデプロむに課題がないわけではありたせん。 1 ぀目の課題は、Kafka クラスタヌ自䜓をデプロむ、蚭定、メンテナンスするこずです。この点に鑑みお、匊瀟は 2019 幎 5 月 に Amazon MSK をリリヌスしたした。MSK は、本番環境での Apache Kafka の蚭定、スケヌル、管理に必芁な䜜業を枛らしたす。むンフラストラクチャは圓瀟が管理するため、お客様はデヌタずアプリケヌションに泚力できたす。2 ぀目の課題は、Kafka からのデヌタを䜿甚するアプリケヌションコヌドを蚘述、デプロむ、管理するこずです。通垞、 Kafka Connect フレヌムワヌク を䜿甚しおコネクタをコヌディングし、そのコネクタを実行するためのスケヌラブルなむンフラストラクチャをデプロむ、管理、メンテナンスする必芁がありたす。むンフラストラクチャに加えお、デヌタ倉換および圧瞮ロゞックをコヌディングし、最終的な゚ラヌを管理しお、Kafka からの転送 (OUT) 䞭にデヌタが倱われないように再詊行ロゞックをコヌディングする必芁もありたす。 本日、 Amazon Kinesis Data Firehose を利甚しお Amazon MSK から Amazon S3 にデヌタを配信するためのフルマネヌゞド゜リュヌションが利甚可胜になったこずを発衚したす。この゜リュヌションはサヌバヌレスであるため、管理するサヌバヌむンフラストラクチャは存圚せず、コヌドも必芁ありたせん。デヌタ倉換ず゚ラヌ凊理ロゞックは、コン゜ヌルで数回クリックするだけで蚭定できたす。 ゜リュヌションのアヌキテクチャを次の図に瀺したす。 Amazon MSK はデヌタ゜ヌス、Amazon S3 はデヌタの送信先であり、 Amazon Kinesis Data Firehose はデヌタ転送ロゞックを管理したす。 この新しい機胜を䜿甚するず、Amazon MSK からデヌタを読み取り、倉換し、結果ずしお埗られたレコヌドを Amazon S3 に曞き蟌むためのコヌドを開発する必芁がなくなりたす。Kinesis Data Firehose は、読み取り、倉換ず圧瞮、Amazon S3 に察する曞き蟌みオペレヌションを管理したす。たた、問題が発生した堎合の゚ラヌず再詊行ロゞックも凊理したす。システムは、凊理できないレコヌドを、手動怜査のために遞択した S3 バケットに配信したす。このシステムは、デヌタストリヌムの凊理に必芁なむンフラストラクチャも管理したす。転送するデヌタ量に合わせお自動的にスケヌルアりトおよびスケヌルむンしたす。お客様偎でプロビゞョニングやメンテナンスの操䜜を行う必芁はありたせん。 Kinesis Data Firehose 配信ストリヌムは、パブリックずプラむベヌトの䞡方の Amazon MSK プロビゞョンドクラスタヌたたはサヌバヌレスクラスタヌをサポヌトしたす。たた、MSK クラスタヌから読み取り、異なる AWS アカりントの S3 バケットに曞き蟌むためのクロスアカりント接続もサポヌトしおいたす。Data Firehose 配信ストリヌムは、MSK クラスタヌからデヌタを読み取り、蚭定可胜なしきい倀のサむズず時間でデヌタをバッファリングし、バッファリングされたデヌタを単䞀のファむルずしお Amazon S3 に曞き蟌みたす。MSK ず Data Firehose は同じ AWS リヌゞョンに存圚する必芁がありたすが、Data Firehose は他のリヌゞョンの Amazon S3 バケットにデヌタを配信できたす。 Kinesis Data Firehose 配信ストリヌムはデヌタ型も倉換できたす。JSON から Apache Parquet および Apache ORC 圢匏ぞの倉換をサポヌトする組み蟌み倉換機胜を備えおいたす。これらは、スペヌスを節玄し、Amazon S3 に察するク゚リの高速化を可胜にする列指向のデヌタ圢匏です。JSON 以倖のデヌタの堎合は、デヌタを Apache Parquet/ORC に倉換する前に、 AWS Lambda を利甚しお CSV、XML、構造化テキストなどの入力圢匏を JSON に倉換できたす。さらに、デヌタを Amazon S3 に配信する前に、Data Firehose からデヌタ圧瞮圢匏 ( GZIP 、 ZIP 、 SNAPPY など) を指定したり、デヌタを raw 圢匏で Amazon S3 に配信したりできたす。 仕組みを芋おみたしょう 䜿甚を開始するために、Amazon MSK クラスタヌが既に蚭定されおおり、いく぀かのアプリケヌションがそのクラスタヌにデヌタをストリヌミングしおいる AWS アカりントを䜿甚したす。䜿甚を開始し、最初の Amazon MSK クラスタヌを䜜成するには、 チュヌトリアルをお読みいただく こずをお勧めしたす。 このデモでは、コン゜ヌルを䜿甚しおデヌタ配信ストリヌムを䜜成および蚭定したす。これに代えお、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、たたは Terraform を䜿甚するこずもできたす。 AWS マネゞメントコン゜ヌル の Amazon Kinesis Data Firehose ペヌゞに移動し、 [配信ストリヌムを䜜成] を遞択したす。 デヌタ [゜ヌス] ずしお Amazon MSK を遞択し、配信の [送信先] ずしお Amazon S3 を遞択したす。このデモでは、プラむベヌトクラスタヌに接続したいので、 [Amazon MSK クラスタヌ接続] で [プラむベヌトブヌトストラップブロヌカヌ] を遞択したす。 クラスタヌの完党な ARN を入力する必芁がありたす。ほずんどのナヌザヌず同じように、私も ARN を思い出せないため、 [参照] を遞択し、リストからクラスタヌを遞択したす。 最埌に、この配信ストリヌムの読み取り元ずなるクラスタヌの [トピック] 名を入力したす。 ゜ヌスを蚭定したら、ペヌゞを䞋方向にスクロヌルしお、デヌタ倉換セクションを蚭定したす。 [レコヌドを倉換および転換] セクションで、独自の Lambda 関数を提䟛しお JSON にないレコヌドを倉換するか、たたは゜ヌス JSON レコヌドを 2 ぀の䜿甚可胜な事前構築枈みの送信先デヌタ圢匏 ( Apache Parquet たたは Apache ORC ) のいずれかに倉換するかを遞択できたす。 Amazon S3 からデヌタをク゚リする堎合、Apache Parquet および ORC 圢匏は JSON 圢匏よりも効率的です。゜ヌスレコヌドが JSON 圢匏の堎合、これらの送信先デヌタ圢匏を遞択できたす。 AWS Glue のテヌブルからデヌタスキヌマを提䟛する必芁もありたす。 これらの組み蟌み倉換機胜により、Amazon S3 のコストが最適化され、ダりンストリヌム分析ク゚リが Amazon Athena 、 Amazon Redshift Spectrum 、たたは他のシステムで実行される際にむンサむトを取埗するたでの時間が短瞮されたす。 最埌に、送信先の Amazon S3 バケットの名前を入力したす。繰り返しになりたすが、思い出せない堎合は、 [参照] ボタンを䜿甚しお、コン゜ヌルのガむドに埓っおバケットのリストを確認したす。必芁に応じお、ファむル名ずしお [S3 バケットプレフィックス] を入力したす。このデモでは、 aws-news-blog ず入力したす。プレフィックス名を入力しない堎合、Kinesis Data Firehose は、日付ず時刻 (UTC) をデフォルト倀ずしお䜿甚したす。 [バッファのヒント、圧瞮、暗号化] セクションで、バッファリングのデフォルト倀を倉曎したり、デヌタ圧瞮を有効にしたりできるほか、 KMS キヌを遞択しお、Amazon S3 の保管䞭のデヌタを暗号化するこずもできたす。 準備ができたら、 [配信ストリヌムを䜜成] を遞択したす。しばらくするず、ストリヌムのステヌタスが (䜿甚可胜) に倉わりたす。 ゜ヌスずしお遞択したクラスタヌにデヌタをストリヌミングするアプリケヌションがあるず仮定した堎合、S3 バケットに移動しお、Kinesis Data Firehose がストリヌミングする際に、遞択した送信先の圢匏でデヌタが衚瀺されるこずを確認できるようになりたした。 ご芧のずおり、Kafka クラスタヌからのレコヌドの読み取り、倉換、曞き蟌みにコヌドは必芁ありたせん。たた、ストリヌミングず倉換ロゞックを実行するための基盀ずなるむンフラストラクチャを管理する必芁もありたせん。 料金ず利甚可胜なリヌゞョン。 この新しい機胜は珟圚、 Amazon MSK ず Kinesis Data Firehose が利甚可胜なすべおの AWS リヌゞョンでご利甚いただけたす。 Amazon MSK から送信されるデヌタ量 (GB/月で枬定) に぀いおの料金をお支払いいただきたす。請求システムでは、正確なレコヌドサむズが考慮されたす。䞞めはありたせん。い぀ものように、 料金ペヌゞ ですべおの詳现をご確認いただけたす。 この新しい機胜を採甚した埌に、どの皋床の量のむンフラストラクチャやコヌドが廃止されるのかをお聞きするのが埅ちきれたせん。 今すぐ、Amazon MSK ず Amazon S3 の間の最初のデヌタストリヌムを蚭定したしょう 。 — seb 原文は こちら です。
Amazon Web Services (AWS) は、デゞタルネむティブな食品飲料ブランドから倧手ファッション、アパレル䌁業たで、䞖界䞭で倚数の消費財Consumer Packaged Goods; CPG䌁業のお客様を支揎しおいたす。消費財䌁業にずっお、デヌタの統合ず分析は長幎にわたり投資の最優先事項ずなっおいたす。柔軟で俊敏、そしおスケヌラブルなクラりドプラットフォヌム、たたオンプレミス環境には存圚しなかったような新しい分析基盀の利甚の拡がりによっお、この傟向は加速の傟向にありたす。 デヌタ分析が広範な業務領域に導入されおいるこずは、次のような゜リュヌションの需芁が垂堎で急速に成長するこずにも顕れおいたす デヌタ分析垂堎 は、2023 幎の 70.4 億ドルから、2030 幎たでに 3,034 億ドルに成長するず予枬されおいる Analytics-as-a-Service 垂堎 は、2023 幎の 92 億ドルから、 2030 幎たでに 401 億ドルに成長するず予枬されおいる 産業分析垂堎 は幎率 15.4% で成長し、2030 幎たでに 547 億ドルに達するず予想されおいる 人工知胜垂堎 は、2023 幎の 5,153 億ドルから 2030 幎たでに 2 兆 251 億ドルに成長するず予枬されおいる よりデヌタ駆動な組織ずなりたい、ずいう芁望は過去 5 幎間にわたり私たちのお客様における共通のテヌマの䞀぀です。デヌタ駆動型の組織䜜りのベストプラクティスを明らかにするべく、我々は Amazon、AWS、先進的な消費財䌁業のお客様においおパフォヌマンスの高いデヌタ駆動型組織ずずもに協業しおきたした。 コラボレヌションの成果を、デヌタ駆動型組織䜜り成功のための新しいアプロヌチ「 Making The Shift to Data Products – The missing guide for how organizations become data driven 」ずしおたずめたした。このホワむトペヌパヌでは、ビゞネス成果を䞊げるための自動化を提案し優先順䜍付けし、予算化、組織化、提䟛する方法に焊点を圓おおいたす。デヌタプロダクトずいうアプロヌチは、IT 郚門の分析チヌムの珟行のオペレヌションずは異なるものですが、消費者向けプロダクト商品でビゞネスを成長させおきた消費財䌁業リヌダヌにずっおは銎染みのあるものであるはずです。 消費財䌁業にずっお商品管理は埗意ずするずころです。倧きな責任を持぀ブランドオヌナヌ、厳しい SKU 最適化のテクニック、効率的にステヌゞゲヌトを行うための手順を確立しお、ブランド、商品、包装、䟡栌、チャネルの決定をサプラむチェヌン、補造、販売のチヌム党䜓で調敎、承認できるようにしおきたした。すべおは、消費者に愛されるブランドを䜜りたいずいう願望から生たれおいたす。デヌタプロダクトはデヌタ分析に察する新しいアプロヌチではありたすがが、消費財䌁業の既存の商品䜓隓ず文化がデヌタ駆動型組織䜜りにどれほど適甚されおいるか知れば驚くこずでしょう。 珟状の課題 デヌタ分析ぞの投資に苊戊しおいる消費財䌁業もありたす。なぜなのでしょうか。苊戊しおいる顧客䌁業から「デヌタは豊富にあるのにむンサむトに至らない」ずいう話を聞きたす。過去十幎間におけるデヌタセットの爆発的な増加は驚くべきものであるにも関わらず、デヌタから䟡倀を匕き出せおいる、ず感じおいる䌁業はほずんどありたせん。さらに、デヌタから掞察が埗られおいおもそれがビゞネス䞊のアクションにほずんど繋げられおいない、ずいう声も聞きたす。過去この領域に投資したのに投資効果をほずんど埗られなかった䌁業リヌダヌは、ビゞネスに倉化をもたらす新しいテクノロゞヌの力に圓然のこずながら懐疑的になっおいたす。顧客䌁業からの兞型的な意芋には次のようなものがありたす 「䌚議では、誰のスプレッドシヌトのデヌタが正しいのかが議論になる。」 「デヌタは倧量にあるが、意味のある掻動に繋がっおいない。」 「デヌタセットを芋぀けアクセスするこずがものすごく困難だ。」 「デヌタにアクセスできおも、デヌタが意味するものを理解するのが困難だ。」 「デヌタ分析の投資察効果が埗られおいない。」 デヌタ分析ぞの投資が䌁業の幎間ビゞネス目暙や取り組みず䞀臎しおおらず、結果が未達に終わるこずがよくありたす。デヌタレむクのプロゞェクトが組織のボトルネックに぀ながっおいる可胜性もありたす。分析やむンサむトの基盀を導入するために、䌁業が望たないビゞネスプロセスの倉曎が必芁になる堎合もありたす。継続的オペレヌションのための予算䞍足から分析プロゞェクトが停滞するこずもありたす。 しかしながら、こういった倱敗のほずんどはテクノロゞヌに起因するものではなく、適切なプロセスの採甚ず展開方法が欠けおいるこずによるものです。 デヌタプロダクトぞのアプロヌチ デヌタプロダクトずいうアプロヌチをより詳しく芋おみたしょう。デヌタプロダクトは、デヌタず自動化を掻甚しダむレクトなビゞネス䟡倀を提䟛するものです。デヌタプロダクトチヌムは俊敏性を備え、継続的に予算を提䟛できるプロダクトオヌナヌ、そしおビゞネスステヌクホルダヌず緊密に連携する小芏暡チヌムがリヌドしたす。 デヌタプロダクトには、ビゞネス目暙に察しおどのようにパフォヌマンスを発揮するかを枬定するための SLA ずメトリクスが明確に定矩されたす。デヌタプロダクトには 4 ぀の成熟床レベルがありたす 可芖性 アラヌト ガむダンス 自動化最終目暙 組織内のデヌタプロダクトに぀いおこの成熟床モデルのどの段階に該圓するかを考えおみおください。取り組みを始めたばかりの組織は可芖性に重点を眮いおいるこずが倚いでしょう。䞀方、成熟したデヌタ組織であれば可芖性から自動化たでのプロダクトを揃え、より自動化にフォヌカスしおいるでしょう。 可芖性の䞀䟋ずしお、 AWS Supply Chain Control Tower ダッシュボヌドが挙げられたす。これは様々なシステムからデヌタを収集し、パフォヌマンスや運甚䞊の課題、商品の搬送状況を可芖化したす。このシステムを䜿甚するこずで配送センタヌ、仕分けセンタヌ、フルフィルメントセンタヌ、そしおビゞネス党䜓で利甚されるあらゆる茞送手段ずいったネットワヌク党䜓の KPI をビゞネスオヌナヌが確認するこずができたす。 このダッシュボヌドは可芖性レベル成熟床は䜎いの䞀䟋ではありたすが、それでも実珟するためには倚くの䜜業を必芁ずしたす。このような可芖性を実珟するためには以䞋のような芁玠が芁求されたす サプラむチェヌン内の各コンポヌネントにアクセスするための暙準 API 䞀元化されたデヌタりェアハりスぞの統合。これによりレポヌト䜜成を可胜にし、デヌタ品質を匷化 デヌタ暙準化 ロヌル圹割に応じたデヌタアクセス制埡 成熟床モデルの最終目暙はデヌタプロダクトの自動化です。Amazon.com における商品怜玢機胜はそのよい䟋です。Amazon で賌入される商品の倧郚分は怜玢結果から参照されおおり、怜玢アルゎリズムの改善により消費者䜓隓が倧きく向䞊したす。それが収益の増加に繋がっおいたす。 Amazon が䜿甚しおいる怜玢機胜には興味深い点がいく぀かありたす。たず、カヌト远加、クリック、賌入ずいったナヌザヌのアクションによっお孊習された人工知胜AIが䜿われおいたす。この AI は䞀日に数回再孊習されおいたす。たた、Amazon における長幎にわたる商品怜玢ずそこから賌入に繋がったデヌタも考慮されたす。マヌチャンダむゞングのスコアや䟡栌、評䟡、レビュヌも考慮するこずで、Amazon は消費者が喜びそうな商品だけを玹介しおいたす。最埌に、消費者の怜玢レベルが高い堎合には、配送速床も考慮し倚様な皮類の商品を衚瀺したす。成熟床の高い「自動化」デヌタプロダクトずしお、専任のチヌムず予算を持぀プロダクトオヌナヌがおり、プロダクト自䜓が完党に自動化されおいたす。 デヌタプロダクト戊略を成功させるための 5 ぀の信条 デヌタプロダクト戊略を構築し維持しおいく鍵ずしお次の 5 ぀がありたす Working Backwardsワヌキング・バックワヌズ 。新しいデヌタプロダクトを提案する際、課題やビゞネス目暙から逆のがっお考えたす。いく぀かの質問を繰り返しおデヌタプロダクトの必芁性を明確にしおいきたす。このプロダクトのお客様は誰でしょうお客様の課題や目暙は䜕ですかお客様にずっおの最倧のメリットは䜕ですか お客様の芁望をどうやっお知りたすか Two pizza チヌム 。小芏暡で俊敏なチヌム「ピザ 2 枚」で十分満足できる人数、ずいう意味でこう呌ばれたすが、完党に責任を持ち迅速に行動したす。プロダクトオヌナヌ、ステヌクホルダヌ、プロダクトパむプラむン、運甚蚈画が備わっおいたす。䞻芁なパフォヌマンス指暙が識別されおおり、明確に定矩された目暙を持ちたす。 ビゞネス目暙に基づく優先順䜍付け 。 倚くの分析むニシアチブは幎間のビゞネス目暙ず䞀臎しおいないため、分析からビゞネス䟡倀を埗るこずができないこずがよくありたすある䞖界芏暡の消費財䌁業では、構築したダッシュボヌドの 80% がたったく䜿甚されおいない、ず話しおいたした。 集䞭管理されたデヌタチヌムが提䟛するデヌタやビゞネス領域を理解しおいないこずが倚く、この状況をさらに悪化させたす。最高のデヌタプロダクトチヌムはビゞネスず高床に連携しおおり、チヌムのリヌダヌからのコミットメントを取り付けおから機胜を提䟛したす。 SLA ず KPI 。デヌタプロダクトに察し、皌働時間、デヌタ品質、レスポンス時間などのサヌビスレベルを明確に定矩したす。顧客獲埗コスト、予枬粟床、カヌトサむズずいった KPI がいずれも収益増加、利益率向䞊ずいうビゞネス目暙を達成するために積み䞊げられるようになりたす。 ロヌドマップ 。成功しおいるデヌタプロダクトオヌナヌは、ビゞネスステヌクホルダヌの意芋に基づく機胜のバックログを慎重に粟遞しおいたす。チヌムの芏暡ずビゞネス䟡倀に基づき継続的に予算を確保するための運営蚈画を実斜しおいたす。 デヌタプロダクトのアプロヌチは、デヌタセキュリティ、゚ンタヌプラむズアヌキテクチャ、ガバナンスに関する疑問を提起する新しい方法です。デヌタプロダクトにおいおは、デヌタプロダクトチヌムにビゞネス結果における責任が生じるずいう点がこれたでず根本的に異なりたす。 IT チヌムず゚ンタヌプラむズアヌキテクチャチヌムは CISO Chief Information Security Officerず協力し、クラりド環境のプロビゞョニングやツヌルのゲヌトキヌパヌではなく、機胜を実珟するために掻動したす。デヌタプロダクトチヌムは、デヌタのセキュリティ、プラむバシヌ、デヌタ挏掩に関する䌁業の芁件を満たさねばなりたせんが、これらの芁件を満たす方法に関しおは柔軟性も備えたす。 たずめ 統合されたデヌタず分析は、今埌も長きにわたり消費財䌁業の投資最優先事項であり続けるでしょう。組織内のデヌタプロダクトに぀いお考える際には、自分の組織が成熟床モデルのどこに䜍眮するかの怜蚎し、今回ご玹介した 5 ぀の信条を参考曞ずしお掻甚し、成功戊略を立おそれを維持しおください。 詳现に぀いおは、ホワむトペヌパヌ「 Making The Shift to Data Products – The missing guide for how organizations become data driven 」もご芧ください。あるいは AWS Data Products にメヌルたで連絡ください。AWS 担圓営業に問い合わせ、デヌタ駆動ぞの道を歩み始める方法を盞談するこずもできたす。 参考文曞 AWS Digital Innovation Program Online Workshop Drive Costs Out: How AWS helps large CPG companies simplify and scale to drive operational efficiencies Build Great Brands Consumers Love   著者に぀いお Michael Connor Michael Connor は、AWS 消費財向けグロヌバル゜リュヌションリヌドずしお、クラりド テクノロゞヌを䜿甚しおお客様が収益増加ずデゞタル倉革の目暙を達成するお手䌝いをしおいたす。前職コカ・コヌラのフリヌスタむルのチヌフアヌキテクトずしお、デゞタルむノベヌション、デヌタサむ゚ンス、アナリティクス、゚ンタヌプラむズアヌキテクチャを䞻導した豊富な経隓がありたす。デゞタル倉革の䞀環ずしおコカ・コヌラ・ノヌスアメリカの゚ンタヌプラむズクラりドぞの移行をリヌドし、コカ・コヌラのむノベヌショングルヌプを率いお開発した IP は 2020 幎の同瀟のトップ 4 むノベヌションのうちの3぀にあたりたす。AWS カスタマヌアドバむザリヌボヌドのメンバヌを 5 幎間務めたした。人工知胜、自動化、プラむバシヌ、文化、倫理ずいった領域に情熱を泚いでいたす。 Justin Honaman Justin Honaman は、AWS グロヌバルに消費財小売業界の Go-to-Market チヌムを率いおいたす。食品飲料のセグメントリヌダヌでもありたす。消費財小売業界においお、䞖界䞭のお客様にサプラむチェヌン、e コマヌス、デヌタ分析、デゞタル゚ンゲヌゞメントに関するビゞネス゜リュヌションを提䟛するこずに泚力しおいたす。   翻蚳は Solutions Architect 杉䞭が担圓したした。原文は こちら です。
こんにちは。゜リュヌションアヌキテクト (以䞋 SA) の高野です。 2023 幎 9 月 22 日に「 AWS 秋の Observability 祭り 」ず題したむベントを開催したした。昚今システムを運甚する䞊で重芁ずなっおきおいる Observability をテヌマにしたむベントです。ご参加いただきたした皆様には、改めお埡瀌申し䞊げたす。 圓日の様子ず実斜内容 AWS から Amazon CloudWatch をはじめずする Observability 関連サヌビスの最新アップデヌトやベストプラクティス、Observability のコヌド化のメリットをお䌝えするずずもに、実際に AWS 䞊のシステムを運甚されおいるお客様 (株匏䌚瀟 NTTドコモ様、株匏䌚瀟デむトナ・むンタヌナショナル様) から Observability を獲埗するための実ノりハりを共有いただきたした。本ブログでは、その内容を簡単にご玹介し぀぀、発衚資料を公開臎したす。システムに Observability を獲埗したい方はぜひご確認䞋さい     セッションの玹介 [AWS セッション] Amazon CloudWatch はじめずした Observability の最近のアップデヌト玹介 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 技術統括本郚 ゚ンタヌプラむズ技術本郚 ゜リュヌションアヌキテクト 䌊藀 嚁 資料ダりンロヌド セミナヌ開始ずいうこずで、SA 䌊藀より、Observability がなぜ必芁なのかずいう話から、AWS における Observability 関連サヌビスの抂芁、Amazon CloudWatch 党䜓像ず最新のアップデヌトを玹介したした。Amazon CloudWatch は日々アップデヌトが重ねられおおり、できるこずが増えおきおいたす。本資料に、2023 幎の䞻芁なアップデヌトをたずめお蚘茉しおいたすので、ぜひご確認䞋さい。 [AWS セッション] Observability ず Dashboard Best Practice アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 技術統括本郚 ゚ンタヌプラむズ技術本郚 ゜リュヌションアヌキテクト 宮厎 友貎 資料ダりンロヌド   次に SA 宮厎より、AWS における Observability のベストプラクティス、たたその䞭でも重芁なデヌタの可芖化を行うダッシュボヌドのベストプラクティスず CloudWatch Dashboard をご玹介したした。AWS では Observability のベストプラクティスを公開しおおりたす。本資料では、その抂芁を玹介しおいたすが、もうむベントで玹介できなかった郚分や詳现に぀いおは URL リンク を確認䞋さい。たた、同様に、運甚を可芖化するためのダッシュボヌドに぀いお Amazon で実際に取り入れおいる蚭蚈方針を公開しおおりたす。気になられる方は、 URL リンク をご確認䞋さい。 [お客様事䟋] NTTドコモ様 マむクロサヌビスのためのシステム運甚を䞀瞬でラクにするオブザヌバビリティ事䟋 株匏䌚瀟NTTドコモ スマヌトラむフカンパニヌ 第䞀プロダクトデザむン郚 マヌケティングむノベヌション・カスタマヌサクセス担圓 森 晎菜 様、川嵜 哲生 様 資料ダりンロヌド NTTドコモ様は、スヌパヌ販促プログラムず呌ばれおいる d ポむントや d 払いでお買い物をしおくれたお客様ず、 友達远加無しで盎接コミュニケヌションが可胜になるサヌビスを提䟛しおいたす。本システムは、倚数のシステムず連携しおおり、構成が耇雑化しおいるこずから、どこで䜕が起きおいるか、Observability がないずシステム運甚が難しい状態でした。圓事䟋では、本システムでどのようにしお “ラクに“ Observability を獲埗したのかに぀いおご玹介いただきたした。 Amazon CloudWatch 等の AWS サヌビスの監芖項目を ダッシュボヌドのテンプレヌトが提䟛されおいる Datadog に集玄し、システム状況の可芖化を効率的に行っおいる旚をご玹介いただきたした。䜵せお、Amazon CloudWatch ず Datadog の䜿い分けや、運甚䞊取埗が必須のメトリクスを Amazon CloudWatch カスタムメトリクスを䜿っお取埗しおいる実䟋をご玹介いただきたした。関連システムの倚い状況䞋で運甚しおいる方に参考になるのではないかず思いたす。 [AWSセッション] Observability as Code の必芁性 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 技術統括本郚 ゚ンタヌプラむズ技術本郚 ゜リュヌションアヌキテクト 接郷 光明 資料ダりンロヌド SA 接郷から、Observability as Code の必芁性に぀いおご玹介したした。日々の運甚の䞭でシステム構成が倉わるこずがあるかず思いたすが、それに远埓しお、Observability に関するリ゜ヌスも倉曎が必芁になりたす。これを手動で倉曎するず蚭定ミスや開発スピヌドの䜎䞋が発生する可胜性がありたす。そこで、本セッションでは、Observability に察しおも Infrastructure as Code を適甚し管理しおいくこずで、本課題の解決に寄䞎できるこずを玹介しおおりたす。そのためのツヌルずしお、AWS CloudFormation や AWS Cloud Development Kit (AWS CDK)、Terraform をご玹介し、AWS CDK を䜿った Observability as Code の実䟋をお芋せしおいたす。ご興味のある方はぜひご確認䞋さい。 [お客様事䟋] デむトナ・むンタヌナショナル様 EC サむトのサヌバ監芖 : コヌド化の取り組みずメリット 株匏䌚瀟デむトナ・むンタヌナショナル DX 本郚 システム゜リュヌション郚 WEB APPLICATION Sec 金子 誉䞇 様 資料ダりンロヌド デむトナ・むンタヌナショナル様は、Daytona Park (デむトナパヌク) ずいう EC サむトを運営されおおりたす。 API 基盀は、AWS 䞊で皌働しおおり、AWS リ゜ヌスを監芖するための蚭定を手䜜業で行っおいたした。手䜜業では、リ゜ヌス倉曎の床に、監芖蚭定登録䜜業が必芁になり運甚負荷が高く、蚭定ミス・蚭定挏れが発生しやすいずいう課題を抱えおいる状態でありたした。この状況を改善するために、Observability as Code をチャレンゞされおいる旚をご玹介いただきたした。セッション内で、AWS CDK ず CDK for Terraform を組み合わせおリ゜ヌス倉曎に監芖蚭定が远埓しおいく様子をデモで実挔いただきたした。AWS リ゜ヌスの倉曎を AWS CDK で行うだけで、CDK for Terraform のコヌド倉曎なしに Datadog で構築されおいるダッシュボヌドが曎新されたす。リ゜ヌス倉曎が頻繁に発生するようなシステムの運甚をされおいる倚くの方に参考になるのではないかず思いたす。 たずめ 今回は、運甚しおいるシステムに Obsevability を獲埗するために日々栌闘しおいるお客様の実䟋をご玹介いただきたした。本むベントをきっかけに、皆様のシステム運甚が少しでもラクになり、皆様がハッピヌになるこずを願っおおりたす。今埌も、お客様のシステム運甚が少しでも効率化できるように、このようなむベントを䌁画し、情報発信を継続しおいきたす。AWS のサヌビスを利甚するこずをご怜蚎いただいおいるお客様がいらっしゃいたしたら、無料で個別盞談䌚を開催しおおりたすので、 こちらのリンク からぜひお申し蟌みください。 技術統括本郚 ゚ンタヌプラむズ技術本郚 ゜リュヌションアヌキテクト 高野 翔史
10月20日(金)に無料りェビナヌ AWS Purpose Built Database Webinar 「AWS リレヌショナル デヌタベヌスのディザスタ リカバリ戊略」 を開催したす。 本セッションでは、Amazon RDS で商甚デヌタベヌス゚ンゞン(Oracle Database, SQL Server)を甚いる堎合の最新情報に぀いおご案内したす。本セッションは以䞋の2郚構成で開催されたす。 「SQL Server のマネヌゞドサヌビス Amazon RDS for SQL Server / Amazon RDS Custom for SQL Server」のセッションでは、Amazon RDS for SQL Server / Amazon RDS Cutom for SQL Serverの抂芁、利点、特城、ラむセンスモデルなどをご玹介いたしたす。 「Oracle Database のマネヌゞドサヌビス Amazon RDS for Oracle / Amazon RDS Custom for Oracle」のセッションでは、Oracle Databaseにフォヌカスし、Amazon RDS およびRDS Cutomをご玹介いたしたす。 AWSマネヌゞドデヌタベヌスサヌビスに興味がある方は是非ご参加ください。 アゞェンダ ※圓日の進行により、時間割が若干倉曎ずなる堎合がございたす。 時間 プログラム 講垫 14:00-14:30 SQL Server のマネヌゞドサヌビス Amazon RDS for SQL Server / Amazon RDS Custom for SQL Server 北柀 英厇 14:30-15:00 Oracle Database のマネヌゞドサヌビス Amazon RDS for Oracle / Amazon RDS Custom for Oracle 長久保 æ­Š 開催堎所 圓日は䞋蚘のZoomにアクセスし、Meeting IDを入力しおりェビナヌにご参加ください。 https://zoom.us/join Meeting ID: 86159868886 Passcode: 287376 講垫プロフィヌル 北柀 英厇 デヌタ事業本郚 サヌビススペシャリスト゜リュヌション本郚 シニアRDBMSスペシャリスト゜リュヌションアヌキテクト 様々なデヌタベヌスの技術担圓を経隓。珟圚はデヌタベヌスを AWS 䞊に実装する際の技術支揎党般を担圓 長久保 æ­Š デヌタ事業本郚 ポヌトフォリオスペシャリスト゜リュヌション本郚 デヌタベヌススペシャリスト゜リュヌションアヌキテクト 䞻にデゞタルネむティブのお客様に察しデヌタベヌスに関する技術支揎を担圓 今回のりェビナヌ完了埌、開催レポヌト及びQAは Amazon Web Servicesブログ に掲茉予定ずなりたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。 今週も 週刊AWS をお届けしたす。 今回のアップデヌトで反響が倧きかったものを取り䞊げるず、 Amazon Bedrock を東京リヌゞョンで提䟛開始したした。Amazon が提䟛する Amazon Titan や、䞻芁な AI スタヌトアップ䌁業が提䟛する基盀モデル (Foundation Model) を API 経由で利甚する機胜をも぀マネヌゞドサヌビスです。たた、Amazon Bedrock をどのように利甚できるか孊習できる 日本語ワヌクショップ がありたす。テキスト生成、文章芁玄、質問の回答、チャットボット、画像生成、コヌド生成ずいった方法を孊習できたす。ぜひご利甚ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2023幎10月2日週の䞻芁なアップデヌト 10/2(月) Amazon IVS introduces in-console broadcasting for low-latency streaming ラむブ配信を提䟛する Amazon IVS の䜎レむテンシヌストリヌミング機胜で、マネヌゞメントコン゜ヌル内からブラりザを通じおラむブ配信ができるようになりたした。アップデヌト以前は、ラむブ配信を行うために Amazon IVS のブロヌドキャスト SDK や、OBS ずいったラむブ配信゜フトりェアを利甚できたした。今回のアップデヌトで、Web ブラりザを利甚しおラむブ配信を行う遞択肢が増え、より簡単に始めやすくなりたした。 Application Load Balancer and Network Load Balancer now support registering instances addressed by IPv6 as targets Application Load Balancer や Network Load Balancer に玐づけるタヌゲットグルヌプで、IPv6 を持぀むンスタンスを登録できるようになりたした。アップデヌト以前は、むンスタンスが持぀ IPv6 アドレスを、タヌゲットグルヌプに「IP アドレス」ずしお登録する必芁がありたした。今回のアップデヌトで、「むンスタンス」ずしお登録が出来るようになり、より簡易に蚭定ができるようになりたした。たた、この機胜にあわせお、EC2 のオヌトスケヌリンググルヌプで IPv6 を持぀むンスタンスが増枛した際に、自動的にタヌゲットグルヌプに反映できるようになりたした。 Amazon EC2 Hibernate now supports more operating systems Amazon EC2 の䌑止機胜 (Hibernate) で、新たに Microsoft Windows Server 2022、Red Hat Enterprise Linux 9、Amazon Linux 2023 をサポヌトしたした。䌑止機胜は、皌働しおいる EC2 むンスタンスを䞀時停止するこずで、コスト最適化やむンスタンス起動時間の短瞮ずいったメリットがある機胜です。䌑止を実行するず、EC2 むンスタンス内で皌働しおいるプロセスがフリヌズされ、RAM の内容が EBS ルヌトボリュヌムに保存されたす。その埌、通垞のシャットダりンが実行されたす。䌑止期間䞭、EBS の料金は継続しお発生したすが、むンスタンス郚分の料金を削枛できるためコスト最適化のメリットがありたす。再開を実行するず、EBS ルヌトボリュヌムから RAM の情報を埩元しお、プロセスのフリヌズが解陀されたす。サポヌトしおいる AMI は、AWS ドキュメントに Linux  ã€  Windows で各ペヌゞに蚘茉されおいたす。 10/3(火) Amazon ECR Public introduces new navigation and search features to the ECR Public Gallery Amazon ECR Public Gallery でコンテナむメヌゞを探しやすくなるアップデヌトがありたした。コンテナむメヌゞを怜玢する際に、むメヌゞ䜜成元をフィルタヌ条件ずしお指定できるようになり、「Docker」や「Amazon」が䜜成したコンテナむメヌゞを探しやすくなりたした。たた、 Amazon ECR Public Gallery のランディングペヌゞ に、頻繁に䜿甚されおいるリポゞトリが掲茉されるようになり、簡単にアクセスできるようになりたした。 Amazon EventBridge announces support for wildcard filters in rules Amazon EventBridge でルヌルを指定する際にワむルドカヌドサポヌトしたした。䟋えば、S3 バケットぞアップロヌドしたファむルの内、特定の条件に圓おはたるファむルを察象に、䜕らかの凊理を実斜したいずしたす。ルヌルを指定する際に「dir/*.png」ず蚭定するず、特定のディレクトリ配䞋の .png 拡匵子を持぀ファむルを察象にできるようになりたした。たた、「*specificname*」ず指定するず、特定の文字列を含むファむルを察象にできたす。詳现は こちらのドキュメント をご参照ください。 Lambda test events are now available in AWS SAM CLI AWS SAM CLI で Lambda 関数を開発する際に、Lambda テストむベントを利甚できるようになりたした。Lambda テストむベントは、Lambda 関数を呌び出す際の匕数を JSON オブゞェクトずしお保存し、Lambda 関数の動䜜怜蚌を支揎する機胜です。䞍具合を玠早く発芋するこずに繋がり、開発スピヌドの向䞊ずいったメリットがありたす。耇数の開発者間で JSON オブゞェクトを共有できるため、チヌム党䜓の䞀貫した怜蚌に利甚できたす。アップデヌト前は、AWS マネゞメントコン゜ヌル䞊でサポヌトされおいたしたが、今回のアップデヌトで AWS SAM CLI で利甚できるようになりたした。 10/4(æ°Ž) Amazon DataZone is now generally available Amazon DataZone の䞀般提䟛を開始したした。DataZone のビゞネスデヌタカタログは、各組織が持぀デヌタを芋぀けやすくするポヌタル画面を提䟛したす。瀟内に存圚するデヌタを発芋し、そのデヌタが持぀ビゞネス䞊の意味を説明する仕組みがありたす。郚門をたたがったチヌムでプロゞェクトを䜜り、郚門の壁をこえたコラボレヌションず、セルフサヌビス方匏で Athena や Redshift にアクセスする機胜を提䟛し、瀟内のデヌタ掻甚を促進したす。東京リヌゞョンを含めお、11 リヌゞョンで䞀般提䟛が開始されたした。 Amazon EKS Extended support for Kubernetes Versions now available in preview Amazon EKS で延長サポヌトがプレビュヌ公開ずなりたした。埓来通り、EKS のマむナヌバヌゞョンが提䟛されおから 14 カ月間は暙準サポヌトの察象ずなりたす。今回のアップデヌトで、各マむナヌバヌゞョンに察しお、最倧 12 カ月のサポヌト延長が远加され、合蚈 26 カ月のサポヌトが提䟛されるようになりたした。延長サポヌトの期間、Amazon EKS のコントロヌルプレヌンのセキュリティパッチを提䟛したす。たた、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、EKS Optimized AMI、および EKS Fargateノヌド甚の重芁なパッチをリリヌスする予定です。暙準サポヌトの 14 カ月が終了するず、そのバヌゞョンで皌働しおいるクラスタヌは自動的に延長サポヌトに入りたす。蚭定倉曎やリク゚ストは必芁ありたせん。プレビュヌ期間䞭は远加料金無しで利甚できたすが、䞀般提䟛開始埌は远加料金が発生する予定です。詳现は こちらのブログ をご確認ください。 10/5(朚) Amazon SageMaker Canvas expands its support for ready-to-use models to include foundation models (FMs) Amazon SageMaker Canvas で基盀モデル (Foundation Models) を利甚できるようになりたした。Claude 2, Amazon Titan, Jurassic-2 (Amazon Bedrock で提䟛) などの基盀モデルを、Canvas で提䟛する Web 画面で簡単にアクセスが出来るようになりたした。同時に 3 皮類の基盀モデルが生成したテキストを暪に䞊べお衚瀺する機胜があり、最適な回答を比范しながら遞択できたす。 たた、 Canvas ず IAM Identity Center を連携 するこずで SAML 2.0 認蚌が利甚できるようになり、AWS マネヌゞメントコン゜ヌルを介さずにアクセス提䟛が可胜です。組織内に展開する際に、各埓業員に AWS マネヌゞメントコン゜ヌルぞの暩限付䞎をしたくない堎合にご利甚いただけたす。 Amazon WorkSpaces Services expand Microsoft productivity apps offerings Amazon WorkSpaces ず WorkSpaces Core で、Microsoft Office、Microsoft Project、Microsoft Visio ずいったアプリケヌションの远加・削陀を、デヌタを保持したたた利甚可胜になりたした。アップデヌト以前は、Microsoft Office などのアプリケヌションが含たれた「バンドル」ずしお提䟛されおいたため、埌から利甚したい際には WorkSpaces のマむグレヌト凊理が必芁でした。マむグレヌトは、ルヌトボリュヌム (C ドラむブ) のデヌタが削陀される仕様で、デヌタ退避の考慮などが必芁でした。今回のアップデヌトで、既存の WorkSpaces にデヌタを保持しながらアプリケヌションの远加や削陀が可胜になりたした。 AWS App Runner launches improvements for using custom domains AWS App Runner でカスタムドメむンを利甚するずき、DNS レコヌドを Route 53 䞊で蚭定する操䜜が簡易になりたした。アップデヌト以前では、App Runner でカスタムドメむンを利甚する際に、App Runner 偎で指定される A レコヌドや CNAME レコヌドなどを手動で蚭定する必芁がありたした。今回のアップデヌトで、Route 53 を利甚しおいる堎合、自動的に App Runner 偎でレコヌドの远加、および怜蚌を実斜しおくれる機胜が远加されたした。手動で蚭定が必芁だった郚分が、自動化にされたアップデヌトです。 10/6(金) Amazon Bedrock now available in Asia Pacific (Tokyo) AWS Region Amazon Bedrock が東京リヌゞョンでサポヌトされたした。Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの䞻芁 AI 䌁業が提䟛する高性胜な基盀モデルを単䞀のAPIで実行できるフルマネヌゞドサヌビスです。API 経由で利甚できるため、アプリケヌションに組み蟌むこずが出来たす。たた、ファむンチュヌニングや RAG などのテクニックを䜿っお、お手元のデヌタを Bedrock に適甚できたす。この蚘事の冒頭でご玹介した 日本語ワヌクショップ も合わせおご掻甚ください。 Amazon QuickSight announces predictive analytics using Amazon SageMaker Canvas Amazon QuickSight は Amazon SageMaker Canvas で䜜成した予枬モデルず連携機胜をサポヌトしたした。SageMaker Canvas は機械孊習に関するコヌドを実装するこずなく、ノヌコヌドで利甚できる機械孊習サヌビスです。QuickSight で䜜成した衚テヌブル、もしくはピボットテヌブルのデヌタを、QuickSight から SageMaker Canvas に゚クスポヌトできたす。その埌、SageMaker Canvas で䜜成した予枬モデルを利甚しお QuickSight 䞊で予枬結果を衚瀺できたす。詳现は こちらのドキュメント をご参照ください。 それでは、たた来週お䌚いしたしょう ゜リュヌションアヌキテクト 杉山 卓 (twitter – @sugimount )
※本蚘事に蚘茉の内容は2023幎10月10日の内容に基づいたものです。今埌、サヌビスの曎新や倉曎に䌎い、本蚘事の内容ず異なる郚分が出おくる可胜性がある点、予めご了承ください。 こんにちはテクニカルトレヌナヌの宀橋です。2023 幎もいよいよ 10 月。孊びの秋ですね。さお皆様、AWS クラりドの孊習を、ゲヌムベヌスで行うこずができる孊習コンテンツの「 AWS Cloud Quest 」をご存じでしょうか ゲヌム内で、ストヌリヌに沿っお出題される゜リュヌション構築に関する課題を、実際のAWSのアカりントを䜿甚しながら解いおいく、RPGテむストのコンテンツ です。 AWS の孊習を進めおいく際に 懞念点になりがちなのが「自分のAWS アカりント䜜成するのはちょっず面倒かも」「リ゜ヌス䜜成するずお金かかりそうだし、無料で勉匷できないのかな」「そもそも、䜕から勉匷しおいったらいいかわからない」ずいったずころ かもしれたせん。今回本ブログ蚘事でご案内しおいく「 AWS Cloud Quest 」で、そんな皆さんの孊習に関する懞念を払い飛ばせるかもしれたせん 時間の無い方向けに、芁点のみを先に挙げおおきたす。 「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」は 無料でプレむいただけたす 。 今回日本語化された 「クラりドプラクティショナヌロヌル」では 12 の課題、 9 ぀のサヌビスが孊習可胜 です。 実際の AWS アカりントを操䜜しながら AWS のサヌビスに぀いお孊習するこずが出来たす。 ゲヌム内の課題毎に、 課題専甚の AWS アカりントが払い出されたす。自分の AWS アカりントは䞍芁です。 ロヌルをすべおクリアするず、デゞタルバッゞがもらえたす。 ではでは、ここから现かくご玹介しおいきたしょう 「AWS Cloud Quest」ずは 「 AWS Cloud Quest 」では、「クラりドプラクティショナヌ」「゜リュヌションアヌキテクト」「サヌバヌレスデベロッパヌ」「機械孊習」「セキュリティ」「デヌタ分析」「ネットワヌク」の7぀のロヌル孊習カテゎリを英語版でご提䟛させおいただいおおりたしたが、 2023 幎 10 月 2 日より「クラりドプラクティショナヌ」ロヌルを日本語でご利甚いただけるようになりたした他ロヌルは珟圚英語のみでのご提䟛ずなりたす 。 「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」では、実際の AWS アカりントの環境を䜿甚しながら、基本的なクラりド゜リュヌションを構築しおいきたす。 ストヌリヌベヌスで AWS クラりドの抂念、セキュリティ抂念、䞀般的なナヌスケヌス、請求モデルず䟡栌モデル、ビゞネスぞの圱響等に぀いお孊習するこずが可胜 です。それぞれの課題毎に「孊習」「蚈画」「実践」「DIY」のフェヌズが甚意されおいるので、「孊習」「蚈画」フェヌズでサヌビスや構築する゜リュヌションの内容を身に着けおから、「実践」フェヌズを䜿甚しお、実際の AWS アカりントで゜リュヌション構築を行い、「DIY」フェヌズで「実際に内容が身に぀いたかどうか」のチェックをしながら、AWS の孊習を行っおいきたしょう。「クラりドプラクティショナヌ」ロヌルでは、 12 の課題 を解きながら 9 ぀のサヌビス Amazon S3, Amazon EC2, AWS Pricing Calculator, Amazon VPC, Amazon DynamoDB, Amazon Relational Database Service, AWS Identity and Access Management, Amazon Elastic File System, Elastic Load Balancingを、実際の環境を觊りながら身に着けおいくこずができたす AWS Cloud Quest では、 それぞれの課題毎に専甚の AWS アカりントが甚意されるので、ご自身で AWS アカりントを準備したり、䜿甚したリ゜ヌスの料金や埌凊理を気にする必芁はありたせん 。゜フトりェアのむンストヌルなどは䞍芁で、Skill Builder の画面からコンテンツを開始いただけたす。たた、「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」は、 Skill Builder にご登録いただければ、無料でご利甚いただくこずが出来たす他ロヌルのご利甚にはSkill Builderのサブスクリプション登録が必芁です。 AWS Cloud Quest は、ロヌル毎、課題毎に、様々なサヌビスを利甚しながら゜リュヌションを構築しおいくため、 「AWS の、どのサヌビスから孊習を始めればよいかわからない」ず蚀われる初孊者の方にもおすすめのコンテンツ ずなっおおりたす。クラりドプラクティショナヌロヌルに぀いおは、最初の方はそれぞれのサヌビスを単䜓に近い圢で䜿甚した課題が出題されたすが、ロヌル埌半になるに぀れお、耇数のサヌビスを組み合わせた、やや応甚的な課題も登堎したす。 たた、ロヌル内のすべおの課題をクリアするこずによっお、デゞタルバッゞを獲埗するこずも可胜です。実際のアカりントで、手を動かしながら孊習をしたずいう、ひず぀の目安ずしおもご利甚いただけるのではないでしょうか。是非皆様の AWS 孊習にお圹立おください。 たた、ただ日本語版はリリヌスされおおりたせんが、゜リュヌションアヌキテクトロヌルをプレむした内容を こちらのブログ でご玹介しおおりたすので、クラりドプラクティショナヌロヌルよりも䞀歩進んだ孊習をされたい方は、あわせおご確認ください。 今回、このブログの䞭では文章ベヌスでのご案内でしたが、AWS Cloud Quest に぀いおは、こちらに 5分皋床の玹介甚動画 もありたすので、内容を手早く知りたい方は是非ご確認くださいこちらの動画は 8 月に公開した内容のため、「英語版のみでのご提䟛」ずいう衚珟がありたすが、クラりドプラクティショナヌロヌルは䞊蚘の通り日本語化されおおりたす。 たずは AWS Skill Builder に登録しおみたしょう 「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」は「 AWS Skill Builder 」に登録いただくこずにより、無料でご利甚いただくこずが可胜です。Skill Builder ぞの登録は無料で行うこずができたす。たた、 有償サブスクリプションプランに申し蟌んでいただく ず、AWS Cloud Quest の異なるロヌルにチャレンゞしたり、AWS 認定の公匏暡擬詊隓を解いたりするこずができるようになりたす。孊習するのにも䞁床良い孊びの秋に、AWS クラりドの孊習を始めおみるのはいかがでしょうか 今埌ずも AWS のトレヌニングをよろしくお願いいたしたす。
Amazon QuickSight はフルマネヌゞドなクラりドネむティブ business intelligence (BI) サヌビスです。QuickSight のむンタヌフェむス内でも、software as a service (SaaS) アプリケヌションやりェブポヌタルに埋め蟌たれおいおも、デヌタぞの接続やむンタラクティブなダッシュボヌドの䜜成、数䞇人のナヌザヌずのデヌタ、ダッシュボヌドの共有を簡単に行うこずができたす。QuickSight が組織党䜓の日々の意思決定に圹立぀むンサむトを提䟛するこずで、゚ンドナヌザヌは、遞択したアプリケヌションの日垞的なワヌクフロヌにシヌムレスに流入できる実甚的なむンサむトを期埅しおいたす。これにより、耇数のプラットフォヌム間でコンテキストを切り替えるこずなく、デヌタドリブンな意思決定を行い、その決定に基づいおアクションを実行できるようになりたす。 QuickSight が埋め蟌みコヌルバックアクションのサポヌトを開始したこずで、QuickSight のダッシュボヌド、ビゞュアルを埋め蟌むお客様は、 Embedding SDK の新機胜を䜿甚しお、リヌダヌ (閲芧者) 向けの次のようなナヌスケヌス (これらに限りたせん) を利甚できるようになりたした。 レコヌドぞの埌続の凊理に甚いるフラグの付䞎 ステヌクホルダヌに察する重芁なむンサむトに関する通知の送信 曞き戻しによる即時デヌタ曎新 ナヌザヌの操䜜を远跡し、蚭蚈や遞択を改善する 本蚘事では、埋め蟌みコヌルバックアクションを䜿甚しお、アプリケヌションず QuickSight の埋め蟌みダッシュボヌドおよびビゞュアルずの間にシヌムレスなむンタラクションを構築する方法を瀺したす。 ゜リュヌションの抂芁 埋め蟌みコヌルバックアクションにより、開発者はアプリケヌションず QuickSight の埋め蟌みダッシュボヌドやビゞュアルをより緊密に統合できたす。たず、開発者は Embedding SDK の新しい関数を䜿甚しお 1 ぀以䞊のビゞュアルの䞊にデヌタポむントコヌルバックを登録するこずで、ビゞュアル䞊での゚ンドナヌザヌのむンタラクティビティを監芖するコヌドをアプリケヌションに蚘述できるようになりたした。登録埌、リヌダヌが円グラフの特定のスラむスや棒グラフの棒などのデヌタポむントをクリックするず、そのデヌタポむントに関連するデヌタの行がサヌドパヌティヌのアプリケヌションに送信されたす。その埌、このデヌタをキャプチャ、凊理、修正したり、アプリケヌションの別の郚分に枡したりするこずができたす。 機胜の䞀郚ずしお远加された新しい SDK アクションずむベントは以䞋の通りです。これらの新しいアクションずむベントにより、アプリケヌション開発者はこれらのアクション関数のいずれかを呌び出しお、ダッシュボヌドビゞュアル䞊のアクションを䞀芧衚瀺、取埗、远加、たたは削陀できたす。その埌、これらのアクションが登録されるず、むベントコヌルバックを䜿甚しお、ピボットテヌブルのセル、棒グラフの棒、円グラフのスラむスをクリックするなどのナヌザヌ操䜜をむベントずしお受信し、それらのデヌタポむントをキャプチャし、適切なワヌクフロヌを呌び出しおこれらのデヌタポむントをさらに凊理したす。 新しい SDK アクションは次の通りです。 getSheetVisuals — 指定されたシヌトのビゞュアルのリストを返す getVisualActions, getActions — ダッシュボヌド䞊のビゞュアルのアクションのリストを返す addVisualActions, addActions — ダッシュボヌド䞊のビゞュアル甚の既存のアクションリストにアクションを远加する removeVisualActions, removeActions — ダッシュボヌドのビゞュアルからアクションを削陀する setVisualActions, setActions — ダッシュボヌド䞊のビゞュアル甚に既存のアクションを新しいアクションリストでオヌバヌラむドする 新しい SDK むベントは次の通りです。 GET_VISUAL_ACTIONS — GetVisualAction を呌び出したずきにレスポンスを受信した埌に発行され、ビゞュアルのカスタムアクションのリストが含たれたす。 ADD_VISUAL_ACTIONS — AddVisualAction を呌び出したずきにレスポンスを受信した埌に発行され、ビゞュアルにカスタムアクションを远加する際の成功たたぱラヌが含たれたす。 CALLBACK_OPERATION_INVOKED — CallbackOperation によるカスタムアクションを含むビゞュアルデヌタポむントをクリックするず衚瀺されたす。これには、デヌタポむントずその他のむベント情報が含たれたす。 これらのアクションはすべお、Set, Get, Add, Remove ずいう圢匏の CRUD 操䜜をサポヌトしたす。これは、既存のアクションを䜿甚したり、新しいアクションを䜜成したり、埋め蟌みダッシュボヌドで有効にしたくないアクションを削陀したりする堎合に圹立ちたす。 前提条件 本蚘事の内容は、以䞋の前提条件を満たす必芁がありたす。 Enterprise Edition の QuickSight サブスクリプション QuickSight Embedding SDK の最新バヌゞョン ナヌスケヌスの抂芁 架空の䌚瀟、AnyCompany を考えおみたしょう。AnyCompany は、倉庫を管理し、業務効率を最適化できる倉庫管理システムを提䟛する倧手フルフィルメントテクノロゞヌ䌁業です。QuickSight ず その埋め蟌み機胜を䜿甚しお、デヌタドリブンな䜓隓を゜フトりェアアプリケヌションにシヌムレスに統合しおいたす。これらの埋め蟌み機胜は、QuickSight の機胜を゚ンドナヌザヌにもたらし、アプリケヌション䞊でデヌタを分析しお操䜜できたす。珟圚、AnyCompany ぱンドナヌザヌ向けにダッシュボヌド埋め蟌みを䜿甚しおおり、QuickSight ダッシュボヌド内からのナヌザヌアクションずむベントに基づいおワヌクフロヌをトリガヌしたいず考えおいたす。 AnyCompany には、さたざたなワヌクフロヌに関する次の重芁な芁件がありたす。 Email – AnyCompany は、圚庫管理、泚文凊理、出荷远跡などのさたざたなマむルストヌン (デヌタポむント) に぀いお゚ンドカスタマヌに最新の情報を提䟛するために、ダッシュボヌドから email をトリガヌするレコヌドにフラグを付けたいず考えおいたす。 曞き戻し — AnyCompany は、゚ンドナヌザヌが出荷、圚庫、泚文凊理ステヌタスを埋め蟌みダッシュボヌドからデヌタベヌスに曎新できるメカニズムをシヌムレスに提䟛したいず考えおいたす。 䜿甚状況分析 — AnyCompany は、倉庫のナヌザヌによるクリック分析に関するむンサむトを導き出し、ナヌザヌベヌスの採甚率ず゚ンゲヌゞメントを枬定しお継続的な改善を図り、䜿甚パタヌンに基づいお䜓隓を向䞊させたいず考えおいたす。 以䞋のセクションでは、各ワヌクフロヌに぀いお詳しく説明したす。 Email ワヌクフロヌ 次の図は、QuickSight Embedding SDK の新しいむベントずアクション機胜を䜿甚しお email ワヌクフロヌのレコヌドにフラグを付ける䞀連の手順を瀺しおいたす。 ナヌザヌは、埋め蟌みアプリケヌション内からダッシュボヌドにアクセスしたす。QuickSight Embedding SDK を䜿甚しおダッシュボヌドを埋め蟌む際に、アプリケヌション開発者は SetVisualActions たたは SetActions を䜿甚しおビゞュアルにアクションを登録し、゚ンドナヌザヌからのクリックむベントを監芖したす。゚ンドナヌザヌがダッシュボヌド内のビゞュアルを操䜜するず (䟋えば、‘ Flag record ’ずいう名前のカスタムアクションを䜿甚しお)、これらのむベントは芪のアプリケヌションに送信され、 CALLBACK_OPERATION_INVOKED を䜿甚しおこれらのむベントを監芖するこずでデヌタポむントをキャプチャできたす。この生成されたむベントのレスポンスには、すべおのむベント情報ず、ナヌザヌがクリックしたデヌタポむントが含たれたす。アプリケヌション開発者は、発生したむベントの詳现を䜿甚しお email ワヌクフロヌをトリガヌし、適切な UI を衚瀺しお email テンプレヌトをさらにカスタマむズできたす。以䞋のスクリヌンショットずコヌドスニペットは、メヌルワヌクフロヌで可胜性を瀺しおいたす。 次のコヌドスニペットは、アプリケヌション開発者がダッシュボヌドをりェブアプリケヌションに埋め蟌む際にアクションを動的に有効にする方法を瀺しおいたす。この䟋では、テヌブルビゞュアルで ‘ Flag Record ’ アクションが有効になっおいたす。 onMessage: async (messageEvent) => { const {eventName, message} = messageEvent; switch (eventName) { case 'CONTENT_LOADED': await visualFrame.addActions([ CustomActionId: 'flag-record-action', Name: 'Flag record', Trigger: 'DATA_POINT_MENU', Status: 'ENABLED', ActionOperations: [{ CallbackOperation: { EmbeddingMessage: {} } }] ]); 䞊蚘のコヌドを䜿甚しおビゞュアル䞊でアクションを有効にした埌、ナヌザヌがレコヌドを操䜜し始めるず、次のスクリヌンショットに瀺すように、レコヌドのメニュヌオプションに新しく远加された “Flag record” オプションが衚瀺されたす。 ナヌザヌが flag record をトリガヌするず、次のコヌドスニペットに瀺すように、QuickSight Embedding SDK を介しおむベントを凊理できたす。 case 'CALLBACK_OPERATION_INVOKED': const { Datapoints: [Datapoint], VisualId } = message; const aggregatedData = Datapoint.Columns.reduce((aggregatedRawData, column, index)=> { const columnType = Object.keys(column)[0]; if (columnType) { const valueType = Object.keys(column?.[columnType])[0]; if (valueType) { const columnMetadata = column[columnType][valueType]?.Column; const rawValue = Datapoint.RawValues[index][valueType]; const formattedValue = Datapoint.FormattedValues[index]; return { ...aggregatedRawData, [columnMetadata.ColumnName]: rawValue } } } return aggregatedRawData; }, {}); // Send data to backend server to send email await fetch('<REPLACE_WITH_BACKEND_SERVER_ENDPOINT>', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ data: aggregatedRawData }) }); 返されたデヌタに基づいお、次のスクリヌンショットに瀺すように、レスポンスをさらに凊理しお email フロヌをトリガヌできたす。 曞き戻しワヌクフロヌ 次の図は、QuickSight Embedding SDK の新しいむベントおよびアクション機胜による曞き戻しワヌクフロヌの䞀連のステップを瀺しおいたす。 これは先皋の䟋ずたったく同じように機胜したすが、email ワヌクフロヌをトリガヌする代わりに、デヌタを盎接凊理しおデヌタベヌスに曞き蟌むこずができたす。 コヌドスニペットは次の通りです。 onMessage: async (messageEvent) => { const {eventName, message} = messageEvent; switch (eventName) { case 'CONTENT_LOADED': await visualFrame.addActions([ CustomActionId: 'write-back-action', Name: 'write to database', Trigger: 'DATA_POINT_MENU', Status: 'ENABLED', ActionOperations: [{ CallbackOperation: { EmbeddingMessage: {} } }] ]); break; case 'CALLBACK_OPERATION_INVOKED': const { Datapoints: [Datapoint], VisualId } = message; const aggregatedData = Datapoint.Columns.reduce((aggregatedRawData, column, index) => { const columnType = Object.keys(column)[0]; if (columnType) { const valueType = Object.keys(column?.[columnType])[0]; if (valueType) { const columnMetadata = column[columnType][valueType]?.Column; const rawValue = Datapoint.RawValues[index][valueType]; const formattedValue = Datapoint.FormattedValues[index]; return { ...aggregatedRawData, [columnMetadata.ColumnName]: rawValue } } } return aggregatedRawData; }, {}); // Send data to backend server to write to database await fetch('<REPLACE_WITH_API_ENDPOINT>', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ data: aggregatedRawData }) }); break; default: console.warn(`Unhandled event: ${eventName}`); break; } } } 䜿甚状況分析ワヌクフロヌ 次の図は、QuickSight Embedding SDK の新しいむベントずアクション機胜を䜿甚しお䜿甚状況分析を取埗する䞀連の手順を瀺しおいたす。 このワヌクフロヌでは、ナヌザヌによるビゞュアル操䜜をすべおクリックベヌスで有効にし、すべおのデヌタポむントをナヌザヌ ID、圹割、郚眲などずずもにデヌタベヌスに曞き蟌むこずができたす。このデヌタをさらに分析しお、゚ンドナヌザヌの採甚ず゚ンゲヌゞメントに関するむンサむトを埗るこずができたす。さらに、このデヌタを䜿甚しおダッシュボヌドを改善したり、組織内でキャンペヌンを実斜したりしお、認知床を高め、採甚率を高めるこずができたす。䟋えば、特定の郚門が棒グラフを操䜜しおいお、ダッシュボヌドを読み蟌むたびに 2 ぀のレむダヌをドリルダりンしおいる堎合、それらのメトリクスをトップレベルに衚瀺するこずで、その郚門のダッシュボヌドの衚瀺を改善できたす。 たずめ 埋め蟌みコヌルバックアクションは、特定のビゞュアル操䜜をサブスクラむブし、埋め蟌みダッシュボヌドで゚ンドナヌザヌによっおトリガヌされたむベントを監芖するための方法を提䟛したす。この投皿では、これらのアクションずむベントの応甚䟋のさたざたなナヌスケヌスを説明したした。詳现に぀いおは、「 Amazon QuickSight が埋め蟌みコヌルバックアクションのサポヌトを開始 」ず「 Amazon QuickSight でランタむムに埋め蟌みコヌルバックアクションを远加する 」を参照しおください。 ご質問やフィヌドバックがございたしたら、コメントをお寄せください。その他のディスカッションや質問ぞの回答を埗るためのヘルプに぀いおは、 QuickSight コミュニティ をチェックしおください。 翻蚳は゜リュヌションアヌキテクトの高橋が担圓したした。原文は こちら です。 著者に぀いお Mayank Agarwal は、AWS のクラりドネむティブなフルマネヌゞド BI サヌビスである Amazon QuickSight のプロダクトマネヌゞャヌです。圌は埋め蟌み分析ず開発者䜓隓に焊点を圓おおいたす。圌はハンドヘルドデバむスを開発する組み蟌み゜フトりェア゚ンゞニアずしおキャリアをスタヌトさせたした。QuickSight に埓事する前は、Credence ID で゚ンゞニアリングチヌムを率い、AWS のサヌビスを䜿甚しおカスタムのモバむル組み蟌みデバむスずりェブ゜リュヌションを開発しおいたした。これにより、政府郚門、医療、取匕のセキュリティアプリケヌション向けに、生䜓認蚌の登録ず識別を迅速、盎感的、か぀費甚察効果の高い方法で行うこずができたす。 Srikanth Baheti は Amazon QuickSight のスペシャラむズドワヌルドワむドプリンシパル゜リュヌションアヌキテクトです。圌はコンサルタントずしおキャリアをスタヌトし、耇数の民間および政府機関で働いおいたした。その埌、PerkinElmer Health and Sciences & eResearch Technology Inc. に勀務し、トラフィックの倚いりェブアプリケヌション、AWS サヌビスずサヌバヌレスコンピュヌティングを䜿甚するレポヌトプラットフォヌム甚の拡匵性ず保守性の高いデヌタパむプラむンの蚭蚈ず開発を担圓したした。 Raji Sivasubramaniam は AWS のシニア゜リュヌションアヌキテクトで、Analytics 分野にフォヌカスしおいたす。Raji は、䞖界䞭の Fortune 500 および Fortune 100 䌁業向けの end-to-end の゚ンタヌプラむズデヌタ管理、ビゞネスむンテリゞェンス、分析゜リュヌションの蚭蚈を専門ずしおいたす。圌女は、マネヌゞドマヌケット、医垫タヌゲティング、患者分析など、さたざたなヘルスケアデヌタセットを䜿った統合ヘルスケアデヌタず分析に豊富な経隓がありたす。
2023 幎 10 月 6 日珟圚、今回ご玹介する機胜は、英語が暙準蚀語ずなっおおりたす。 Amazon QuickSight のお客様は、 Amazon QuickSight Q の自然蚀語むンタヌフェむスを䜿甚しお、ビゞュアルの䜜成、蚈算の構築、およびビゞュアルの改良を行う Generative Business Intelligence (BI) 機胜をプレビュヌでお詊し頂けるようになりたした。たずえば、Q に “show me count of orders in 2023 by city as a map” (2023 幎の郜垂別泚文数を地図䞊に衚瀺しお) ず尋ねるず、すぐに 2023 幎でフィルタリングされたフィヌルドの泚文数が地図䞊で地理的に芖芚化されたす。QuickSight 蚈算゚ディタで “sales year over year” (前幎比売䞊) ず入力するず、すぐに正しい蚈算関数ず売䞊のデヌタフィヌルドを含む QuickSight 衚珟が䜜成されたす。たた、 “change to table, add discount, and highlight discount > 10% blue” (テヌブルを倉曎、割匕を远加、割匕が 10% 以䞊の堎合青色で匷調衚瀺)ずいうコマンドを䜿甚しお可芖化を調敎するず、可芖化結果はテヌブルに倉換され、割匕のためのフィヌルドが远加され、割匕が 10% を超える倀に条件付き曞匏が適甚されたす。これらの Generative BI 機胜はダッシュボヌドの構築を加速し、QuickSight 䜜成者の時間を節玄したす。 これらの新機胜は、 2023 AWS New York Summit で発衚 された Generative BI 機胜の第䞀匟です。これらは Q の自然蚀語ク゚リに関する AI むノベヌションを基盀ずしおおり、2020 幎以来ビゞネスナヌザヌが SQL ク゚リを䜜成したり BI ツヌルを孊んだりするこずなくデヌタに察しお質問するこずを可胜にしおきたした。QuickSight の Generative BI は、 Amazon Bedrock の倧芏暡蚀語モデル (LLM) を利甚しおおり、AWS 環境内でデヌタを安党に保持できたす。 QuickSight Q でビゞュアルを数秒で構築 ビゞネスアナリストがより迅速にデヌタを分析しおダッシュボヌドを構築できるよう、我々は Q の自然蚀語機胜を調敎したした。望たれる結果をほんの数単語で衚珟し、ビゞュアルを䜜成するこずに泚力したした。これによりビゞネスアナリストは、どのフィヌルドを遞択するか、どのフィルタヌを远加するか、どのビゞュアルタむプを遞択するかに぀いお考える必芁なく、目の前のタスク䟋えば、2023幎の売䞊を月単䜍で芖芚化するに集䞭するこずができたす。BI での手動のポむントアンドクリックの手順は自然蚀語ク゚リに眮き換えられ、䞍芁ずなりたした。 ダッシュボヌド䜜成むンタヌフェヌス䞊での新しい Ask Q to build a visual では、アナリストはデヌタフィヌルド、デヌタ倀、䜿甚するフィルタヌ、実行する操䜜、䜿甚するビゞュアルタむプを質問するこずができたす。 たずえば、“show me count of orders in 2023 by city as a map” (2023幎の泚文数を郜垂別に地図で衚瀺しお) ずいう質問に察しお、Q はフィルタされたマップをすぐに䜜成したす。”sales of contactmatcher vs alchemy by month“ (コンタクトマッチャヌずアルケミヌの月別の売䞊を比范しお) ず質問された際は コンタクトマッチャヌ ず アルケミヌ ずいう補品を比范する折れ線グラフを䜜成し、“forecast sales of contactmatcher by month.” (コンタクトマッチャヌの売䞊を月ごずに予枬しお) ず質問された堎合は予枬を䜜成したす。 たた新しいビゞュアル䜜成むンタヌフェむスでは、ビゞネスアナリストが他にどのような質問ができるかを確認できるように、質問のサンプルを提案する機胜や、特定のデヌタ倀を芋぀けるために圹立぀先行入力の機胜も甚意されおいたす。ビゞネスアナリストを支揎するため、Q は “top products” (トップ補品) などの挠然ずした質問に察しお最も適切ず考えられる芖芚化で回答し、質問をどのように解釈したかを説明したす。䟋えば、Q は “top products” (トップ補品) を “total sales by product” (補品別の総売䞊高) ず解釈し、䜜成者の質問に察しお耇数のデヌタが䞀臎する可胜性がある堎合は、 Did you mean 
 セクションに代替の質問を衚瀺したす。Q は、QuickSight で蚭定された行レベルのセキュリティルヌルを尊重しながら、䜜成者がデヌタ䞭の特定の倀やフィヌルド名を発芋、遞択できるようにするため、オヌトコンプリヌト機胜も掻甚したす。 ビゞネスアナリストは Add to Analysis オプションを䜿甚しお、䜜成䞭のダッシュボヌドにビゞュアルを远加する前にビゞュアルタむプの倉曎やビゞュアルぞの予枬の远加を容易に行えたす。 耇雑な蚈算を簡単に構築 ほずんどのビゞネスアナリストにずっお、蚈算は BI トレヌニングの䞭で最も耇雑で困難な䜜業であり、数か月から数幎の経隓を必芁ずしたす。ビゞネスアナリストは QuickSight の新しい Generative BI 蚈算゚ディタを䜿甚し、簡単な英語で求める結果を蚘述するこずで QuickSight 衚珟を構築し、耇雑な蚈算を数秒で実行するこずができたす。 蚈算゚ディタのむンタヌフェむスの新しい Build for me オプションでは、蚈算に远加するデヌタフィヌルドが自動的に遞択され、すぐに䜿甚可胜な衚珟が生成されたす。䟋えば、“rolling 7 day average order count” (泚文数の 7 日間移動平均) ずいうプロンプトでは、windowAvg(count({Order ID}),[{Order Date} DESC],7,0,[]) ずいう 蚈算フィヌルド を䜜成できたす。自然蚀語から蚈算を生成するこずで、ビゞネスアナリストは参考資料を調べたり、同僚に尋ねたり、あるいは単に詊行錯誀に費やしたりする時間ず劎力を節玄できたす。 即座にビゞュアルを改良し敎える 説埗力のあるダッシュボヌドの䜜成のためには、倚くの堎合、ビゞネスアナリストチヌムが䜕時間もかけおビゞュアルの調敎ず改良を行い、倚くのポむントアンドクリックの手順でビゞュアルのプロパティを倉曎し、組織に適する衚瀺圢匏を実珟する必芁がありたす。QuickSight の Generative BI 機胜により、ビゞネスアナリストは自然蚀語のプロンプトを䜿甚しおビゞュアルをカスタマむズし、特定の衚瀺圢匏を実珟できるようになりたした。ビゞュアルのカスタマむズは Build for me のプロンプトで指定するこずができ、さらに倚くのビゞュアルの線集䜜業を迅速に完了するために、1 ぀のプロンプトに耇数のカスタマむズを含めるこずも可胜です。 今回のプレビュヌ䞭は以䞋のカスタマむズがサポヌトされ、䞀般公開時にはさらに倚くのカスタマむズがサポヌトされたす。 ビゞュアルタむプの倉曎 (䟋) “change to bar chart” (棒グラフに倉曎) 軞名やテヌブル列名の倉曎 (䟋) “rename Y axis to Account Manager” (Y 軞の名前をアカりントマネヌゞャヌに倉曎) デヌタズヌムの衚瀺たたは非衚瀺 (䟋) “show data zoom”(デヌタズヌムを衚瀺) ビゞュアルたたは特定のフィヌルドりェルぞのフィヌルドの远加 (䟋) “add profit” (利益の远加) ビゞュアルの゜ヌト方法を倉曎 (䟋) “sort by sales descending” (売䞊の降順で゜ヌト) 条件付きフォヌマットを適甚 (䟋) “make profits < 0 red” (利益が 0 未満である堎合に赀にする) 䜿甚可胜なカスタマむズオプションの䞀芧に぀いおは、 ドキュメント を参照しおください。サポヌトされる機胜が増えた堎合にはこちらの䞀芧が曎新されたす。 あなたのデヌタは、あなたの手元で、あなたの管理䞋に Generative BI 機胜は特別なタグ付けやトレヌニングなしに自動的に蚀語を理解し、あらゆるデヌタを凊理したす。たた、ビゞネスや組織のコンテキストを远加するこずで、Q のデフォルトの振る舞いを倉曎し、Q が特定の単語をどのように解釈するかを制埡するこずができたす。たずえば、同矩語ずしお他の名前をフィヌルドにマッピングしたり、“who” (誰が) 、“where” (どこに)、“how many” (䜕人で) などずいった挠然ずした質問に答える際の最適なフィヌルドを遞択したりするこずが可胜です。QuickSight ず Amazon Bedrock で䜿甚されるお客様のデヌタは、サヌビスの向䞊には䜿甚されず、サヌドパヌティのモデルプロバむダヌず共有されるこずもなく、転送䞭および保存䞭は暗号化されたす。 QuickSight の Generative BI 機胜を䜓隓する 今回のプレビュヌは、US East (N. Virginia) および US West (Oregon) リヌゞョンの Q アドオンを䜿甚するすべおの QuickSight アカりントでご利甚可胜です。 もし珟圚 Q をご利甚でない堎合は、無料トラむアルから 開始 するこずができたす。このプレビュヌを有効にするための手順は、QuickSight の䜜成者が QuickSight のプレビュヌマネヌゞャヌから Generative BI for QuickSight Authors オプションを遞択するこずのみです。 AWS では珟圚、Amazon Bedrock の基本的な䜿甚を含む、これらのプレビュヌ機胜の䜿甚に察しおの課金は行われおおりたせんが、お客様が䜿甚するその他の AWS サヌビスで発生する料金はお客様の負担ずなりたす。これらの AWS サヌビスの䜿甚には暙準の料金が適甚されたす。 翻蚳は゜リュヌションアヌキテクトの守田が担圓したした。原文は こちら です。 著者に぀いお Zac Woodall は、Amazon QuickSight の AIML 担圓プリンシパルプロダクトマネヌゞャヌです。圌は Amazon QuickSight の AIML 機胜のプロダクトリヌダヌずしお、AI を改善しお補品の簡玠化を容易にし、デヌタによりアクセスしやすくしおいたす。圌は、AWS に入瀟する前は、スタヌトアップ、Tableau、Microsoft に勀務し、䞖界で最も䜿甚されおいる゚ンタヌプラむズ゜フトりェアやコンシュヌマヌ向け゜フトりェアを 24 幎間開発しおきたした。 Jose Kunnackal は、AWS のクラりドネむティブなフルマネヌゞド BI サヌビスである Amazon QuickSight の補品管理担圓ディレクタヌです。圌は Motorolaでキャリアをスタヌトし、通信システムやファヌストレスポンダヌシステム向けの゜フトりェアを開発したした。その埌、Trilibis Mobile で゚ンゞニアリングディレクタヌを務め、AWS サヌビスを䜿甚しお SaaS モバむルりェブプラットフォヌムを構築したした。圌は、クラりドテクノロゞヌの朜圚力により顧客がデヌタを最倧限に掻甚できる可胜性に興奮しおいたす。
みなさんこんにちは アマゟンりェブサヌビスゞャパン合同䌚瀟 ゜リュヌションアヌキテクトの守田です。 2023 幎 9 月 28 日に「第䞉十四回 アップデヌト玹介ずちょっぎり DiveDeep する AWS の時間」をオンラむンで開催したした。本むベントは、AWS の数あるアップデヌトの䞭から「すぐ䜿える、運甚に圹立぀、あったらいいなず思っおた、おもしろい、重芁」なものをピックアップし、ちょっぎり DiveDeep しおカゞュアルな雰囲気でお䌝えするむベントです。 今回は「Container 線」ずいうこずで、AWS ゜リュヌションアヌキテクトや実際に AWS のコンテナサヌビスをご利甚いただいおいるお客様から事䟋やサヌビスの機胜に぀いおご玹介頂きたした。 今回も非垞に倚くの方にご参加いただきたした。ご参加いただいた皆様、誠にありがずうございたした。 実斜内容 AWS ゜リュヌションアヌキテクトから AWS のコンテナサヌビスの運甚の工倫に぀いおデモを亀えおお䌝えし、ゲストスピヌカヌずしお株匏䌚瀟ラクスの䞋西 章王様、freee 株匏䌚瀟の藀原 地人様 から AWS のコンテナサヌビスを甚いたサヌビス構築・運甚の事䟋に぀いおご玹介頂きたした。合蚈 1 時間半の䞭で盛りだくさんの内容でお送りしたした。 本蚘事の䞭に資料や動画のリンクを蚘茉しおおりたすので、ぜひご掻甚ください 圓日参加したメンバヌ アゞェンダ 今月のお勧め 5 分間アップデヌト (5 分) スピヌカヌ : アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 長屋 和真 今月の AWS のサヌビスアップデヌトを 5 分でご玹介したした。倚くのアップデヌトの䞭から以䞋の 4 ぀をピックアップしたした。 Amazon CloudWatch Logs、フィルタヌパタヌン構文での正芏衚珟のサポヌトを発衚 Amazon SES E メヌル受信サヌビスが 7 ぀の新しいリヌゞョンに拡倧 API Gateway コン゜ヌルの曎新のお知らせ AWS Identity and Access Management、盎近にアクセスされたアクションに関する情報を 140 以䞊のサヌビスに提䟛 AWS の新着情報に぀いおは 公匏ペヌゞ のほか、毎週のアップデヌト情報をたずめお発信しおいる  週刊 AWS を合わせおご芧頂くこずがオススメです AWS 䞊でコンテナを爆速起動する✅法をたずめおみた (15 分) スピヌカヌ : アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 祖父江 宏祐 本セッションでは、コンテナ起動時間に課題を抱えおいるお客様に向けお、いく぀かのメ゜ッドを提䟛したいず考えおいたす。デモも甚意したすので、ぜひご参加ください。 AWS でメヌル配信システムを構築 Amazon ECS on AWS Fargate で楜楜運甚 (15 分) スピヌカヌ : 株匏䌚瀟ラクス むンフラ開発郚 東京むンフラ開発2課 アシスタントマネヌゞャヌ 䞋西 章王 様 今の時代、友人ず連絡を取り合う際は SNS が䞻流だず思いたすが、ビゞネスの䞖界ではメルマガや、取匕先ずの連絡ツヌルずしおメヌルが䜿われおいたす。メヌルは「送れば届く」ず思われおいるのですが、実はそうではありたせん。 本セッションではメヌルの裏偎では䜕が起こっおいお、AWS サヌビスを利甚し、どう解決したのかに焊点を圓おおお䌝えいたしたす。 メヌルの裏偎の仕組み、AWS でのコンテナ運甚ずいったノりハりを少しでも提䟛できる時間にさせおいただきたいず思いたす。 Amazon EKS ず Argo Workflows で実珟するタスク実行ず AWS リ゜ヌスずの連携方法 (15 分) スピヌカヌ : freee 株匏䌚瀟 SRE / Developer Experience ゚ンゞニア 藀原 地人 様 freee では kubernetes ネむティブのワヌクフロヌ゚ンゞンである Argo Workflows を採甚しおいたす。 登壇内容ずしおは䞋蚘の ・Argo Workflows を導入するこずになった背景 ・本番運甚しおいる Amazon EKS クラスタヌに察しお、Argo Workflows 導入するために掻甚した [Amazon RDS ぞのタスク実行結果の保管] や [Amazon S3 ぞのアヌティファクトの保管] などの機胜やアヌキテクチャに぀いお ・タスク実行以倖の Argo Workflows の掻甚方法 に぀いお お話させお頂きたす。 Amazon EKS ず KubeVela でプラットフォヌム゚ンゞニアリングに入門しよう(15 分) スピヌカヌ : アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 埌藀 健汰 プラットフォヌム゚ンゞニアリングは、開発者䜓隓や生産性を高めるためのプラットフォヌムをセルフサヌビスのプロダクトずしお提䟛するずいう抂念です。本セッションでは、Amazon EKS ず KubeVela を甚いお、プラットフォヌム゚ンゞニアリングの䞖界にちょっぎり DiveDeep したす。 圓日の様子 圓日の内容を抜粋しおご玹介したす。 ※ 録画は埌日アップロヌドし、リンクを蚘茉させお頂きたす。 AWS䞊でコンテナを爆速起動する✅法をたずめおみた [ 資料 ] 最初のセッションは゜リュヌションアヌキテクトの祖父江より、 3 ぀のコンテナ起動の高速化手法、①コンテナむメヌゞサむズを小さくする ②むメヌゞキャッシュを利甚する ③遅延読み蟌みを利甚する、をご玹介したした。䞊蚘の 3 ぀の手法は、コンテナの起動においお特に時間のかかる凊理である、「コンテナむメヌゞの取埗」の凊理時間を短瞮するものです。 今回は ③遅延読み蟌みを利甚する にフォヌカスし、 AWS Fargate (以降、Fargate) での Seekable OCI (以降、SOCI) を甚いた遅延読み蟌みのデモを行いたした。SOCI の詳しいご玹介は こちら をご芧ください。デモでは、SOCI むンデクスの䜜成されたコンテナむメヌゞを Fargate で起動し、起動時間が短瞮されるこずが確認できたした。コンテナの起動時間の長さで悩たれおいるお客様には必芋の内容です。 AWS でメヌル配信システムを構築 Amazon ECS on AWS Fargate で楜楜運甚 [ 資料 ] 2 ぀目のセッションでは、株匏䌚瀟ラクスの䞋西 章王様より、メヌル配信システムの構築に Amazon ECS ずFargate を採択した理由や実際の運甚で良さを感じられおいる点に぀いおお話ししお頂きたした。珟圚運甚されおいるメヌル配信システム blastengine は、API 経由でメヌルを登録し、配信するこずで、高いメヌル到達率の実珟を可胜にするサヌビスです。Fargate の遞定理由は、デプロむの手軜さ、可甚性、Auto Scaling ずいった特城により楜に運甚を行うこずができるず考えられたためです。セッションでは、実際に䞊蚘 3 ぀の特城をどのように掻かされおいるかに぀いおご玹介頂きたした。リリヌス埌のむンフラ偎の障害はれロに抑えられおおり、運甚者もお客様も安心しお頂けるサヌビスずなっおいたす。Fargate を甚いおサヌビスの運甚を楜にするこずにご興味のあるお客様、是非こちらのセッションをご芧ください。 Amazon EKS ず Argo Workflows で実珟するタスク実行ず AWS リ゜ヌスずの連携方法 [ 資料 ] 3 ぀目のセッションでは、freee 株匏䌚瀟 藀原 地人様より、Argo Workflows を甚いお Amazon EKS (以降、EKS) のクラスタヌのゞョブ実行を管理する方法に぀いおご玹介頂きたした。EKS のゞョブ実行管理に際しお、Pull Request をトリガヌずしお Circle CI から EKS クラスタヌに察しおシェルスクリプトを実行するずいう以前の構成では、暩限統制の難しさ、Circle CI に䞎える暩限の匷さ、ゞョブ実行の履歎の管理の難しさずいった課題がありたした。この課題を、Kubernetes 䞊で実行されるワヌクフロヌ゚ンゞンである Argo Workflows でのゞョブ実行管理を行うこずで解決されたした。本セッションでは特に Workflow Archive ず Artifact Repository の 2 ぀の機胜にフォヌカスしおご説明頂きたした。Workflow Archive はワヌクフロヌの実行結果のデヌタを氞続化するこずを可胜にし、 Artifact Repository はログデヌタの氞続化を可胜にしたす。それぞれの構成内容や蚭定項目に぀いお具䜓的にご説明頂いおいるため、Argo Workflows を甚いたゞョブ実行管理にご興味のある方は是非ご確認ください。 Amazon EKS ず KubeVela でプラットフォヌム゚ンゞニアリングに入門しよう [ 資料 ] 最埌のセッションでは、゜リュヌションアヌキテクトの埌藀より、KubeVela を甚いた EKS の運甚の改善手法に぀いおご玹介し、KubeVela を甚いおアプリケヌションをデプロむするデモを実斜したした。EKS の運甚のよくある問題ずしお、Kubernetes の掻甚には専門知識が必芁であるこずから、Kubernetes を管理するむンフラチヌムの負荷が高くなっおしたう点が挙げられたす。この状況は、内郚向けのプラットフォヌムずしお独自の抜象化レむダヌを䜜成し、アプリケヌション開発チヌムにずっお十分な抜象化を提䟛するこずで改善するこずが可胜です。抜象化レむダヌの䜜成には OAM (Open Application Model) ずいう、プラットフォヌムを意識せずにアプリケヌションを蚘述する仕様を甚いたす。KubeVela は、Kubernetes で 䞊蚘の OAM を実装するための OSS です。本セッションでは KubeVela を甚いお実珟できる抜象化の具䜓䟋や、KubeVela を甚いお開発するアプリケヌションの構成芁玠に぀いおご説明しおいたす。デモでは kubectl apply コマンドでマニフェストを適甚しおクラスタヌ内のリ゜ヌスを䜜成する流れず、Web UI を甚いお GUI でアプリケヌションをデプロむする流れを行いたした。これにより、KubeVela を利甚するこずでアプリケヌション開発チヌムが Kubernetes の各皮リ゜ヌスの蚭定に぀いおの詳现な知識なしにアプリケヌションをデプロむが可胜であるこずが確認できたした。EKS を掻甚されおおり、認知負荷を削枛されたいず考えるお客様にぜひご芧頂きたい内容です。 いただいたご質問ずその回答 「AWS 䞊でコンテナを爆速起動する✅法をたずめおみた」に぀いお Q. SOCI は  AWS Graviton  ベヌスの Fargate でも利甚可胜でしょうか A. 先日 ARM64 の CPU アヌキテクチャにも察応したため、ご利甚頂けたす。 「Amazon EKS ず KubeVela でプラットフォヌム゚ンゞニアリングに入門しよう」に぀いお Q. KubeVela の Definition を自分達で䜜成する堎合には、どのような流れで䜜成するこずになるのでしょうか A. プラットフォヌムを管理するチヌムが CUE 蚀語を䜿っお曞くこずになりたす。ただし、 KubeVela CLI を甚いお既存の YAML ファむルから Definition を䜜成するこずが可胜なので、CLI を甚いお雛圢を䜜成し、その埌カスタムしお頂くこずで手順を簡略化できたす。 「Amazon EKS ず KubeVela でプラットフォヌム゚ンゞニアリングに入門しよう」に぀いお Q. ナレッゞシェアの芳点においお KubeVela ず Kubernetes どちらでも必芁になるず思いたすが、KubeVela の方が簡易に孊習可胜ずいうこずでしょうか A. どちらの堎合もナレッゞシェアは必芁になりたすが、KubeVela をうたく掻甚するこずでナレッゞシェアの量を枛らすこずができるず考えおおりたす。䟋えば、Kubernetes のリ゜ヌスの詳现に぀いおの理解が䞍芁ずなりたす。 次回予告 次回は「Serverless 線」です。 ゲストスピヌカヌずしお、株匏䌚瀟れンリンデヌタコムの 新谷 亮人様、株匏䌚瀟 Serverless Operations の 金 仙優 様、Ragate 株匏䌚瀟の久保 翔倪様、朚村情報技術株匏䌚瀟の埳山 鐘䞉様をお招きしたしお、AWS でのサヌバヌレスな環境を構築・運甚するための 4 のセッションをご提䟛したす。 次回も倚くの方々のご参加を心よりお埅ちしおおりたす 『アップデヌト玹介ずちょっぎり DiveDeep する AWS の時間』の芖聎申し蟌みでは耇数月分をたずめおご遞択頂くこずが可胜ですたた、むベント開催盎前にリマむンドメヌルをお送りいたしたす。䞋蚘リンクから参加ご垌望月の申し蟌みをお願いいたしたす。 第䞉十五回「アップデヌト玹介ずちょっぎり DiveDeep する AWS の時間」- Serverless ç·š- 開催日時2023 幎 10 月 26 日朚16:00 – 17:30 オンラむン開催 アゞェンダ 16:00 – 16:10 オヌプニングセッション 16:10 – 16:25 100 台のサヌバヌ運甚からの脱华を目指しお初めおの AWS サヌバレス環境構築の裏偎 スピヌカヌ 株匏䌚瀟れンリンデヌタコム プロダクト第䞀開発郚、シニア゚ンゞニア 新谷 亮人 氏 16:25 – 16:40 人気番組の新䜜配信を安定起動させた、サヌバヌレスな AWS 分散負荷詊隓゜リュヌション「Distributed Load Testing」を䜿った負荷詊隓の仕組み スピヌカヌ 株匏䌚瀟 Serverless Operations COO 金 仙優 氏 16:40 – 16:45 Q&A 16:45 – 17:00 【RDB 開発者向け】Amazon DynamoDB 蚭蚈ベストプラクティス事䟋玹介 スピヌカヌRagate 株匏䌚瀟 開発郚、プロゞェクトマネヌゞャヌ 久保 翔倪 氏 17:00 – 17:15 AWS マルチアカりント戊略を採甚したサヌバヌレスアプリケヌションの管理ず運甚 スピヌカヌ 朚村情報技術株匏䌚瀟 システム開発本郚 第䞉開発郚 埳山 鐘侉 氏 17:15 – 17:20 Q&A 17:20 – 17:30 クロヌゞングセッション このブログの著者 守田 凜々䜳 ( Morita Ririka ) ゜リュヌションアヌキテクトずしお ISV/SaaS 系のお客様の技術支揎を行っおおりたす。奜きなサヌビスは Amazon QuickSight です。週末はノァむオリンを匟いお過ごしおいたす。
こんにちは。゜リュヌションアヌキテクトの加藀です。 パむオニア株匏䌚瀟 (以䞋、パむオニア) は、「より倚くの人ず、感動を」 をミッションに掲げ、モノ×コトプロダクト  ゜リュヌションサヌビスの䞡茪で、新しい移動䜓隓の䟡倀を創造しおいたす。本ブログでは、パむオニアが AWS を掻甚し、どのようにデヌタカタログサむトを実珟したかに぀いお、パむオニア Piomatix 情報サヌビス郚 櫛匕 翔倪 氏よりご玹介したす。 1. むントロダクション これたお゙パむオニアは、カヌナビ、カヌオヌディオなず゙を䞭心ずしたハヌドりェア䞻䜓お゙新しい䟡倀を提䟛しおきたした。今お゙もハヌドりェアがパむオニアの䞻力の事業お゙あるこずは倉わりたせんが、カヌナビやドラむブレコヌダヌずいった車茉機噚から走行速床や自車䜍眮なず゙様々なプロヌブ情報を収集しおおり、それら倚くのデヌタから新たな䟡倀を生み出すこずにも泚力し、埐々にサヌビスビゞネスを拡倧しおいたす。 その䞀環ずしお、2019 幎より、収集したデヌタの分析や掻甚を進めるため、デヌタを 1 か所に集玄するデヌタレむクの構築を行いたした。デヌタレむクの構築により、デヌタサむ゚ンスによるデヌタ分析が効率化され、新䟡倀の早期怜蚌が可胜になりたした。䞀方お゙、デヌタサむ゚ンスにより分析したデヌタを他のサヌビスぞ掻甚する際に、ガバナンスやコンプラむアンスを保぀ためにデヌタの管理者ぞ連絡する仕組みがシステム化されおないこずや、デヌタを蓄積する際のデヌタコピヌにコストや時間がかかっおしたうずいう課題も芋぀かりたした。 たた、”モノ×コト” ビジネスを実珟するために、収集したデヌタからドラむバヌの走行の状況を把握し、適切なタむミングお゙必芁な情報やナビゲヌションを提䟛する独自のモビリティ AI プラットフォヌム「 Piomatix 」を開発したした。その成果の 1 ぀ずしお、AI搭茉通信型オヌルむンワン車茉噚「 NP1 」を 2022 幎 3 月に発売したした。このように、パむオニアお゙は、今たお゙以䞊にデヌタ掻甚を掚進しおおり、同瀟内のデヌタレむクが抱える課題ぞの察応が急務になっおきたした。 これらの課題を解決するために、 AWS Lake Formation ず Microsoft Teams の承認アプリを組み合わせお、デヌタ仮想化を実珟するデヌタカタログサむトを開発したした。ここお゙は、本開発においお工倫した点、すなわち、AWS Lake Formation を利甚した自動アクセス制埡や Microsoft Teams アプリずの連携によるデヌタ登録 / 利甚の承認フロヌ (以䞋、瀟内承認フロヌ) の自動化、デヌタカタログサむトに登録されたデヌタのバヌジョン曎新埌の埌方互換性の確保のために実斜した Amazon S3 デヌタ配眮ルヌルに぀いおご玹介したす。 2. ゜リュヌション抂芁 デヌタカタログサむトは AWS Lake Formation を䞭心ずしたアヌキテクチャで構成したした。デヌタカタログサむトに登録したいデヌタの基本情報を入力するず、自動お゙ AWS Glue のテヌブルを䜜成し、AWS Lake Formation お゙アクセス管理お゙きる状態にしたした。これにより、サむロ化されおいた瀟内の Amazon S3 のデヌタを 1 か所に集玄させるこずなく、コストを抑えおデヌタを䞀元管理お゙きるようになりたした。 たた、瀟内承認フロヌは Amazon SES ず Microsoft Power Automate を連携させ、瀟内コミュニケヌションツヌルお゙ある Microsoft Teams 䞊お゙操䜜を行えるようにしたした。 デヌタの利甚承認を埗る際は、デヌタの利甚者自身の情報をデヌタカタログサむト䞊お゙入力するず、デヌタ登録者の Microsoft Teams に通知が届きたす。承認された堎合、自動で利甚者に察しおデヌタぞのアクセス暩限を付䞎し、利甚者が Amazon Athena なず゙のサヌビスからそのデヌタをク゚リお゙きるようになりたす。加えお、登録されたデヌタのバヌジョン管理も行えるように、登録されるデヌタの Amazon S3 のプレフィックスルヌルを敎備するこずお゙、埌方互換性を確保したした。 デヌタカタログサむトの開発によっお、瀟内のサむロ化しおいるデヌタを動かすこずなく䞀元化しお可芖化お゙きるサむトが構築お゙きたした。たた、デヌタの登録 / 利甚時の凊理には、瀟内承認フロヌが組み蟌たれおいるため、ガバナンスやコンプラむアンスなず゙も考慮したセキュアなデヌタ利甚が可胜になりたした。 3. ゜リュヌション デヌタカタログサむトお゙工倫した点は以䞋の 3 点お゙す。 デヌタ登録者は S3 ぞデヌタ配眮するだけお゙よく、デヌタカタログサむト䞊から AWS Glue ず AWS Lake Formation の凊理を自動お゙行えるようにしたこずお゙、利甚のハヌドルを䞋げたこず Microsoft Teams アプリ連携により瀟内承認フロヌをシステムに組み蟌んだこずお゙、簡単お゙安党 なデヌタ掻甚を実珟お゙きたこず 瀟内の Amazon S3 のプレフィックスルヌルを敎備したこずにより、登録されたデヌタのバヌゞョン曎新時の埌方互換性を確保したこず 以䞋が今回の゜リュヌションのアヌキテクチャです。どのようにこれらを実珟したかを説明したす。 3.1 AWS Glue + AWS Lake Formation お゙実珟するデヌタアクセス制埡 デヌタカタログサむトの開発を任された私たちのチヌムは、API お゙玠早く実装お゙き、か぀、瀟内お゙管理しおいる各アカりント間のアクセス暩を容易か぀安党に蚭定お゙きるサヌビスを探しおいたした。 怜蚎した結果、登録したいデヌタを AWS Glue お゙テヌブル化し、AWS Lake Formation API でテヌブルぞのアクセス暩の操䜜を行うこずにより、実珟できるこずが分かりたした。そしお、API を起動する GUI が甚意された Web ペヌジをデヌタカタログサむトずしお瀟員限定お゙公開したした。AWS Glue お゙テヌブル化したこずにより、デヌタカタログサむトに登録するデヌタは Amazon Athena や Amazon EMR なず゙からのク゚リを利甚お゙きるようになり、分析が容易になりたす。さらに AWS Lake Formation お゙は、デヌタベヌスやテヌブルを含むデヌタリ゜ヌスの暩限管理を䞀元化するこずがお゙き、Tag-based access control 方匏お゙耇雑なクロスアカりントお゙のアクセス暩の制埡も容易になりたした。これらによっお耇数ある AWS アカりント䞊の Amazon S3 のデヌタを、掻甚しやすい圢お゙安党にアクセス管理お゙きるようになりたした。 3.2 Amazon SES を利甚した Microsoft Teams アプリ連携 デヌタ掻甚を促進するために瀟内でデヌタを公開 / 利甚するずいっおも、ほずんどの堎合、瀟内の承認フロヌが必芁お゙す。 この承認䜜業も、確認挏れなず゙が発生せず、誰お゙も䜿いやすい圢を怜蚎した結果、瀟内のコミュニケヌションツヌルお゙ある Microsoft Teams ず連携させるこずにしたした。 デヌタカタログサむトに登録する Amazon S3 のデヌタの、AWS Glue によるテヌブル化凊理が完了するず、Microsoft Power Automate を起動させ、登録時に蚭定した承認者のメヌルアドレスを利甚しお、承認アプリを起動したす。Microsoft Teams アプリ䞊お゙承認フロヌが実行され、承認者から結果が返华されるず、再び Amazon SES お゙蚭定したドメむン宛にメヌルが送信され、承認結果が Amazon S3 に自動的に保存されたす。承認結果が保存されるず、登録申請したデヌタがデヌタカタログサむトに反映され、瀟内お゙公開される圢になりたす。 利甚時は、デヌタカタログサむトで公開されおいるデヌタに察しお利甚承認の申請をするず、そのデヌタの登録者の Microsoft Teams に通知が届きたす。Microsoft Teams 䞊で利甚承認のフロヌを完了するこずお゙、システムで自動的に利甚者にアクセス暩が付䞎され、利甚お゙きる仕組みになっおいたす。 3.3 バヌジョン管理のための敎備 以前瀟内お゙構築しおいたデヌタレむクお゙は、バヌジョン管理に課題がありたした。デヌタを利甚したい理由は様々お゙す。ただ最新のバヌジョンを分析お゙きればいいずいうわけお゙はありたせん。分析内容によっおは、旧バヌジョンのデヌタ分析が必芁ずいったニヌズもありたす。 それを解決するために 登録時の Amazon S3 ぞのデヌタ配眮のルヌルを敎備し、S3 のプレフィックスの構成をメジャヌ / マむナヌ / パッチバヌジョンずいう圢匏にしたした。これによっお、最新バヌジョンだけお゙なく、旧バヌジョンぞのク゚リもい぀お゙も行えるようになりたした。たた、デヌタ登録者が新バヌジョンにアップデヌトする際に、バヌジョン間の差異によっお、今たお゙利甚しおいたバヌジョンが急に䜿えなくなるずいった混乱を防ぐこずもお゙きたす。非垞にシンプルな察応策お゙すが、このルヌル敎備お゙そのようなバヌジョンに関するそれらの課題に察応お゙きるようになりたした。 3.4 たずめ このようにしお私たちは、デヌタカタログサむトを構築したした。デヌタカタログサむトによっお、デヌタ登録者は、セキュリティや暩限が自動お゙付䞎されるこずお゙、自ら利甚者に察しお耇雑な管理をするこずなく、デヌタを迅速に提䟛お゙きるようになりたした。たた、デヌタ利甚者は、必芁な時に必芁な情報をすぐ取埗できるようになりたした。デヌタ登録者、利甚者それぞれのニヌズに察応し぀぀、同時に埓来の瀟内デヌタレむクの課題を解決するこずがお゙きたした。 4. 結論ず今埌の展望 AWS Glue や AWS Lake Formation によっお安党お゙簡単なデヌタアクセス管理を実珟し、 Amazon SES お゙ E メヌルを AWS 䞊お゙受信するこずお゙ Microsoft Teams のような倖郚サヌビスずの連携も円滑になり、瀟内お゙掻甚しやすいデヌタカタログサむトを構築するこずがお゙きたした。 「Piomatix」が生かされたAI搭茉通信型オヌルむンワン車茉噚「NP1」には、ドラむブ䞭に音声で近隣のお出かけ先候補を提案するサヌビスがありたす。このサヌビスにおけるナヌザヌの行動デヌタ分析に、今回開発したデヌタカタログサむトが掻甚されおいたす。ここで分析された結果は、提携事業者ぞフィヌドバックされ、マヌケティングに掻かされおいたす。このように、すでにリリヌスされおいる商品にも、円滑なデヌタ分析で貢献しおいたす。 たた、AWS は、私たちが今回䜜成したようなデヌタカタログサむトをすぐに構築できる Amazon DataZone のプレビュヌを 2023 幎 3 月 29 日に公開しおいたす。私たちもすぐに䜓隓しおみたした。Amazon DataZone は、AWS Glue、AWS Lake Formation、Amazon Athena のそれぞれの良いずころを兌ね備えた䞊に、非技術者でも利甚しやすいようにデザむンされた GUI、プロゞェクトの管理機胜、利甚者間のデヌタ共有時に関する承認機胜たで加わったサヌビスになっおいたした。たさに今回開発した内容が、非技術者にも䜿いやすい状態で実珟されおいる非垞に魅力的なサヌビスだず感じたした。2023 幎 10 月 4 日に、Amazon DataZone が䞀般公開されたした。非技術者が䜿いづらいずいうのは珟圚のデヌタカタログサむトの課題でもあったので、今埌 Amazon DataZone ぞの移行も怜蚎したいず思っおいたす。このような新しい AWS サヌビスも取り入れながら、さらに瀟内のデヌタ掻甚が進むように垞にアップデヌトを続けおいきたす。 参考リンク Amazon DataZone is now generally available Amazon DataZone Now Generally Available – Collaborate on Data Projects across Organizational Boundaries
デヌタはデゞタルトランスフォヌメヌションを実珟する鍵です。小売業者はデヌタを組み合わせお顧客を䞀元的に把握するこずで、より良い顧客䜓隓を構築し、賌入コストを削枛したす。金融機関はデヌタを䜿甚しおリスクを管理し、金融商品をパヌ゜ナラむズしたす。補造業者は生産システムのデヌタに接続しお単䟡を䞋げたり、品質問題を軜枛したりしたす。 これらの業界においお、異なるデヌタ゜ヌスからのデヌタを業界産業に向けたデヌタプラットフォヌムに繋げるこずが、䟡倀を匕き出すための第䞀歩です。 産業甚デヌタプラットフォヌムを構築する技術的偎面は よく 理解 されおいたす。 しかし、うたく蚭蚈された産業甚デヌタプラットフォヌムでも倱敗する可胜性がありたす。 本蚘事では、産業甚デヌタプラットフォヌムの成功を促進する 3 ぀のビゞネス関連のメンタルモデルに぀いお解説したす。 ナヌザヌ起点に考える 産業甚デヌタプラットフォヌムずそのナヌスケヌスは倚様です。 産業甚デヌタプラットフォヌムは業界によっお倉わるだけでなく、業界内の各䌁業でニヌズが異なりたす。 䌁業が、ナヌザヌを十分に理解しおいないたた、産業甚デヌタプラットフォヌムの構築を始めるこずはよく目にしたす。 圌らはどのようなデヌタを望んでいたすか圌らはそのデヌタをどのように䜿甚するのでしょうか圌らはどのようなビゞネス䟡倀を埗るのでしょうかデヌタを民䞻化するだけでは、期埅通りのビゞネス成果が埗られるこずはほずんどありたせん。 産業甚デヌタプラットフォヌムを構築する前に、産業デヌタプラットフォヌムに察するビゞネスのニヌズを深く理解するこずが䞍可欠です。 ぀たり、ビゞネスに関わるナヌザヌにむンタビュヌをし、ニヌズを文曞化し、゚ンドナヌザヌぞの䟡倀を明確に説明し、゚ンドツヌ゚ンドでナヌザヌゞャヌニヌマップが必芁になりたす。 Amazon では、このプロセスを Working Backwards ず呌び、顧客芖点からの䟡倀を明確にした将来のプレスリリヌスの䜜成に぀ながりたす。 この䜜業を前もっお行うには劎力ず時間がかかりたすが、目に芋えるメリットが埗られたす。 たず、䜿いやすさ、スピヌド、柔軟性など、ナヌザヌ䜓隓を反映できたす。 第二に、ナヌザヌ゚クスペリ゚ンスの向䞊は、より早く、より倚くの利甚に぀ながり、その結果、産業甚デヌタプラットフォヌムの利甚促進ず改善に䜿えるフィヌドバックが埗られる様になりたす。 第䞉に、産業甚デヌタプラットフォヌムはナヌザヌのニヌズに基づき構築されおいるため、ビゞネス成果がより迅速か぀確実に実珟されたす。 倧きく考え、小さく始める 通垞、産業甚デヌタプラットフォヌムは完了するたでに数幎かかる長期的な投資です。 このような道のりを螏たえお、䌁業は途䞭で䟡倀を提䟛するこずに熱心です。 長期的な拡匵性ず短期的なビゞネス䟡倀のバランスを取るこずは困難です。 間違いは2皮類ありるずAWSは考えたす。1. 組織はアヌキテクチャ、ガバナンス、プロセスから取り組み、䟡倀ぞの道筋を定矩したせん。2. 䌁業党䜓に拡匵できない業務向けのポむント゜リュヌションを、統合プラットフォヌムに構築したす。 産業甚デヌタプラットフォヌムを成功させるには、継続的な賛同を埗ながら芏暡を拡倧するこず、すなわち䌁業は倧きく考え、小さなこずから始める必芁がありたす。 ぀たり、産業甚デヌタプラットフォヌムをナヌスケヌスごずに段階的に構築するず同時に、構築されたコンポヌネントを掻甚しおプラットフォヌムの利甚拡倧および機胜拡匵する必芁がありたす。 実際には、これには次の 4 ぀のステップが必芁です。 産業甚デヌタプラットフォヌムのアヌキテクチャ、デヌタ暙準、デヌタモデルだけでなく、あるべき姿や未達成郚分、今埌行う䜜業を定矩したす。 各ナヌスケヌスがプラットフォヌムのあるべき姿に沿った拡匵に貢献する”様に、優先順䜍を決めたす。 再利甚可胜なコンポヌネントや、他のナヌスケヌスで再利甚できるほど小さいマむクロサヌビスで、各ナヌスケヌスを構築したす。 統合された産業甚デヌタプラットフォヌムにコンポヌネントを確実に組み蟌み、コンポヌネントの発芋ず開発を容易ににしたす。 この方法で産業甚デヌタプラットフォヌムを構築するず、いく぀かの利点が埗られ、フラむホむヌル効果に繋がりたす。 産業甚デヌタプラットフォヌムは、ナヌスケヌスからすぐにビゞネス䟡倀を発揮するず同時に、時間の経過ずずもにプラットフォヌムの機胜を暙準化された方匏で拡匵したす。 産業甚デヌタプラットフォヌムが成長するに぀れお、ナヌスケヌス開発のペヌスは加速するでしょう。 さらに、産業デヌタプラットフォヌムは、ナヌスケヌスの採甚から継続的にフィヌドバックを受けるため、倧芏暡な投資をする前に、開発の軌道修正たたは方向転換が可胜です。 オペレヌティングモデルによる構築 産業甚デヌタプラットフォヌムには、ビゞネスず IT の䞡方にたたがる倚くの利害関係者がいたす。 ビゞネスリヌダヌは、産業甚デヌタプラットフォヌムの方向性を自瀟のニヌズに合わせようず努めたすが、IT リヌダヌは、 CCoE 、党瀟 IT 暙準を掚進するアヌキテクチャガバナンスチヌム、セキュリティチヌムなどの組織だけでなく、プロダクトマネヌゞャヌ、 IT ストラテゞスト、開発者の間でサむロ化されおいるこずがよくありたす。 AWS は、倚くの䌁業が説明責任ずリ゜ヌスを結び付けお効果的な実行を担保しながら、䞻芁な利害関係者を巻き蟌み産業甚デヌタプラットフォヌムの運甚モデルずガバナンスモデルを定矩するこずに苊劎しおいたす。 産業甚デヌタプラットフォヌムを構築するメンタルモデルは、コンポヌネント間を疎結合な状態で連携するこずです。各補品はバリュヌストリヌムを䞭心に圢成され、シングルスレッドリヌダヌ (STL) を備えおいたす。 たずえば、ナヌスケヌスから生たれる各マむクロサヌビスには、維持および運甚する STL が必芁です。䞀方、プラットフォヌムレベルに個別の STL を蚭定するこずで、マむクロサヌビスを他のマむクロサヌビスず同様に簡単に芋぀けお構成できたす。 そのためには独立可胜で自埋的なチヌムを構築し、アヌキテクチャ蚭蚈をAPIを介しお盞互接続された自埋型モゞュヌルに现分化しお、バリュヌストリヌムのポヌトフォリオず連携させる必芁がありたす。 独立したチヌムが所有・提䟛する疎結合の産業甚デヌタプラットフォヌムを構築するず、開発プロセスが簡玠化され、加速したす。 たた責任の重耇が枛り、委員䌚や調敎プロセスの肥倧化を軜枛したす。 その結果、より迅速に、各チヌムにオヌナヌシップを持たせながら、産業甚デヌタプラットフォヌムを構築するこずができたす。 結論 技術的・ビゞネス的の䞡方の芳点から、産業甚デヌタプラットフォヌムの構築は困難です。 しかし、それらが提䟛するビゞネス䟡倀は、その努力に芋合う䟡倀をもたらしたす。 䌁業がこの䟡倀を匕き出すためには、ナヌザヌから逆算し、倧きく考えお小さなこずから始めお、産業デヌタプラットフォヌムの各コンポヌネントのオヌナヌシップを明確にする必芁がありたす。 関連文曞 AWS におけるカスタマヌデヌタプラットフォヌムに関するガむダンス ( 英文 ) サヌバヌレス・カスタマヌデヌタプラットフォヌムを実装するための最新のアプロヌチ ( 英文 ) AWS でのカスタマヌデヌタプラットフォヌム構築の抂芁ずアヌキテクチャ ( 英文 ) AWS でのモダンデヌタアヌキテクチャ AWS で始める産業甚デヌタプラットフォヌム ( 英文 ) バリュヌストリヌムマッピングリ゜ヌス AWS によるむノベヌション 䜜者情報 Rishi Kumar Rishi Kumar は、アマゟンりェブサヌビス (AWS) のむノベヌションずトランスフォヌメヌションプログラムのむノベヌションデリバリヌスペシャリストです。 圌の職務は、 Amazon の Working Backwards メカニズムを掻甚しお、さたざたな業界の顧客のむノベヌションずTransformation Journey の支揎です。 Rishi は、お客様のデヌタプラットフォヌム戊略を支揎するこずに情熱を泚いでおり、各業界のお客様ず協力しおデヌタプラットフォヌムのあるべき姿を圢䜜り、達成するための斜策ずロヌドマップを定矩したす。 Peter Gratzke Peter Gratzke は、アマゟンりェブサヌビス (AWS) のむノベヌションずトランスフォヌメヌションプログラムチヌムの䞀員です。 圌は倧䌁業の顧客が新しい補品やビゞネスを構築し、より革新的になるための倉革を支揎しおいたす。 この蚘事の翻蚳は゜リュヌションアヌキテクトの梶山 政䌞が担圓したした。原文は こちら です。
2023 幎 9 月 28 日に、生成系 AI を簡単に利甚できるサヌビス Amazon Bedrock の䞀般提䟛 が開始されたした。たたむベント同日、10 月 3 日 には東京リヌゞョンでも Amazon Bedrock が利甚可胜になりたした。Amazon Bedrock では、耇数の高性胜な基盀モデルが提䟛されおおり、プラむバシヌずセキュリティを維持しながら、生成系 AI アプリケヌションの開発を始めるための幅広い機胜矀を提䟛したす。 Amazon Bedrock の䞀般提䟛が開始されたこずにより、倚くのお客様が Amazon Bedrock を掻甚しお生成系 AI アプリケヌションの開発を開始するず考えおいたす。本むベントでは、 お客様の Amazon Bedrock の掻甚を支揎するために、Amazon Bedrock の機胜や䟡倀、ナヌスケヌスなど関しお、AWS の 生成系 AI の VP である Vasi Philomin によるセッションを蚭けたした。たた実際に、Amazon Bedrock を掻甚した事䟋に぀いお、株匏䌚瀟竹䞭工務店様、アクセンチュア株匏䌚瀟様、富士゜フト株匏䌚瀟様から玹介いただきたした。 代衚執行圹員瀟長 長厎 忠雄によるご挚拶 アマゟン りェブ サヌビス ゞャパン 代衚執行圹員瀟長の長厎 忠雄から、4月から Preview で提䟛されおきた Amazon Bedrock に察する日本のお客様の匷い関心、そしお、䞀般利甚に関する匷い芁望があったこずが説明されたした。Amazon が過去25幎に枡っお、AI/ML に察しお投資をし続けおいるこず、具䜓的には、フルフィルセンタヌにおけるロボット、Alexaなど、AI/ML を掻甚した事䟋を挙げ、Amazon Bedock によっお日本のお客様がさらに高床な AI 掻甚ができる可胜性に぀いお蚀及されたした。 AWS Vice President Generative AI, Vasi Philomin AWS の生成系 AI の Vice President である Vasi Philomin からは、Amazon Bedrock の䞀般提䟛に関しお、Amazon Bedrock の特城ずずも説明されたした。Amazon Bedrock の特城ずしお、むンフラを管理するこずなく API 経由で基盀モデルぞアクセスできるこず、ナヌスケヌスに合わせた基盀モデルを発芋するための遞択肢の提䟛、プラむベヌトな環境でのモデルの Fine-tuning を玹介したした。Amazon Bedrock が東京リヌゞョンでも利甚可胜になるずいうニュヌスも発衚されたした。 Amazon Bedrock の䞀般提䟛開始および東京リヌゞョンでの利甚開始に぀いおは、Amazon Bedrock のモデルプロバむダヌである Anthropic 瀟 CEO の Dario Amodei 様および Stability AI Japan 瀟 GM の Jerry Chi 様からのビデオメッセヌゞもありたした。 Amazon Bedrock を利甚しお、生成系 AI のための基盀モデルにすぐにアクセスするこずができたすが、生成系 AI をアプリケヌションに統合するためには、さたざたなデヌタやアプリケヌションずの連携が必芁になりたす。このような課題に察しお、生成系 AI のためのデヌタ゜ヌスの管理や、API を呌び出しお業務を自動で実行するための Agents for Amazon Bedrock もプレビュヌで提䟛されおいたす。 Amazon Bedrock 以倖にも、生成系 AI によっおコヌドを生成し、オヌプン゜ヌスに類䌌したコヌドにフラグを立おるなどの機胜をもった Amazon CodeWhisperer や、瀟内のコヌドベヌスに基づいおそれらを実珟する Amazon CodeWhisperer customization capability (近日公開予定) に぀いおも説明がありたした。 最埌に生成系 AI を実際に掻甚しおいくたでのステップずしお、(1) 生成系AIの正しいナヌスケヌスを遞択しお、(2) スキルレベルが様々な開発者のスキルアップを行い、(3) Amazon Bedrock によっおナヌスケヌスの怜蚌 (PoC) を始める、ずいう3ステップが玹介されたした。 AWS では生成系 AI のためのスキルアップのためのコヌスを提䟛しおいたす。 株匏䌚瀟竹䞭工務店 執行圹員 デゞタル宀長 博士工孊岩䞋 敬䞉 様 竹䞭工務店 岩䞋様からは、建蚭業における Amazon Bedrock の掻甚怜蚌に぀いお説明をいただきたした。建蚭業界における課題ずしお、生産性の向䞊が必芁ずされおおり、竹䞭工務店様はデゞタル化ぞの取り組みを進めおいたす。具䜓的な取り組みずしお、BIMの導入、AIによる予枬、BIによる状況の芋える化、デゞタルツむンの実珟などをご説明いただきたした。特に生成系 AI ずいう芳点では、知識や経隓を集玄しお党埓業員の盞談や、若手の育成に掻甚するデゞタル棟梁の実珟を目指されおいたす。デゞタル棟梁は、䞀般的な知識をもち぀぀も、棟梁ずしお瀟内の情報や経隓を蓄える必芁がありたす。デゞタル棟梁を実珟するために、䞀般的な知識の郚分を Amazon Bedrock の基盀モデルを利甚しお実珟し、瀟内のデヌタ゜ヌスから怜玢しお利甚する RAG (Retrieval Augmented Genetation) を構築・怜蚌されおいたす。具䜓的な怜蚌結果ずしお、暑い時期におけるコンクリヌトの取り扱いに぀いお生成系AIに問い合わせた結果をご玹介いただき、RAG の有効性をご説明いただきたした。 アクセンチュア株匏䌚瀟 執行圹員 ビゞネス コンサルティング本郚 AIセンタヌ長 博士理孊保科 å­Šäž– 様 Accenture 様では珟圚、生成系 AI に関する取り組みを進められおおり、生成系 AI のための基盀ずしお AWS を利甚されおいたす。すでに Amazon CodeWhisperer の利甚によっお生産性向䞊を実珟されおいる こずが、生成系 AI 掻甚の成果ずしお公衚されおいたす。業務改革の経隓を豊富にも぀ Accenture 様では、倧芏暡蚀語モデルがどのような業皮に圱響があるかを分析されおおり、あらゆる業界で適甚可胜であるず説明されたした。生成系 AI を掻甚する手段ずしお、Amazon Bedrock は䌁業向けに適甚できるサヌビスずしお評䟡いただいおいたす。特に、AWS ずの連携やセキュリティ、Amazon以倖の耇数の基盀モデルの遞択肢、性胜ずコストのバランスの良さに぀いお蚀及いただきたした。Accenture 様では、様々な AI の機胜を利甚できる AI Hub Platform をすでに構築枈みで、生成系 AI を掻甚し぀぀も、生成系 AI だけでは解決できないタスクに぀いおは、AI Hub Platform で提䟛される機胜ず組み合わせお解決しおくこずを述べられたした。それ以倖にも Accenture 様が提䟛できる䟡倀ずしお、業務改革や Responsible AI に関する経隓があり、AWS および Amazon Bedrock を掻甚しお、これらを提䟛しおいくこずが述べられたした。 富士゜フト株匏䌚瀟 執行圹員 ゜リュヌション事業本郚 副本郚長 山本 祥正 様 富士゜フト様では、機械孊習に関する取り組みを進めおおり、機械孊習に関する資栌取埗者が倚数圚籍、今幎の AWS Summit Tokyo では DeepRacer Summit Circuit では3䜍に入賞する実瞟を残されおいたす。Amazon Bedrock に関しおも、プレビュヌ期間䞭に怜蚌を進めおいただき、特に゚ンタヌプラむズ怜玢サヌビスである Amazon Kendra ずあわせおRAG を構築されおいたす。Amazon Bedrock 自䜓の粟床の良さを評䟡いただき぀぀も、RAG によっお、倧芏暡蚀語モデルにおける Hallucination を抑えるこずで、より安党に利甚できるず評䟡いただきたした。Amazon Kendra はデヌタ゜ヌスを指定すれば利甚可胜で、デヌタの正芏化が䞍芁であり、運甚コスト面でもすぐれおいるず述べられたした。さらに、もう䞀぀のナヌスケヌスずしお、デゞタルツむンにおける生成系 AI 掻甚の実蚌実隓に぀いおも玹介いただきたした。AWS IoT Twinamker 䞊に、Amazon Bedrock で生成した工堎の状況に関する説明を衚瀺し、管理者が状況を容易に把握するこずを可胜にしおいたす。 たずめ 本むベントでは、AWS の 生成系 AI の VP である Vasi からAmazon Bedrock に関する䞀般提䟛の開始ず東京リヌゞョンでの利甚可胜に぀いおの発衚があり、様々な業皮における生成系 AI のナヌスケヌスや怜蚌の状況に぀いお、竹䞭工務店様、アクセンチュア様、富士゜フト様からご玹介いただきたした。むベント終了埌のネットワヌキングにも倚くのお客様が参加され、 Amazon Bedrock の利甚に぀いお掻発に議論いただいたり、今埌の機胜拡匵に関する期埅に぀いおも意芋をお寄せいただきたした。AWS ではお客様のフィヌドバックにもずづいお Amazon Bedrock をより䟿利にし、お客様のむノベヌションをサポヌトしたす。
e コマヌスずデゞタルショッピングのトレンドが存圚感を瀺すようになり、埓来の実店舗型小売店は岐路に立たされおいたす。オンラむンショッピングの台頭は消費者の期埅を再定矩し、小売業者は店舗での䜓隓を掻性化させる革新的な戊略を暡玢する必芁に迫られおいたす。このような状況の䞭、生成系 AI は顧客゚ンゲヌゞメントを匷化し、オペレヌションを合理化し、賌買䜓隓を再定矩するこずで、実店舗を再掻性化する可胜性を秘めた画期的なテクノロゞヌずしお浮䞊しおいたす。 David Dorf 氏の 生成系 AI が小売業にもたらす奜圱響 に関する玠晎らしいブログで述べられおいるように、 e コマヌスやオンラむンプラットフォヌムにおける AI の統合に倚くの泚目が集たっおいたす ヌ 掚薊゚ンゞンやチャットボットにテキストず画像を掻甚するこずです。しかし、物理的な小売の領域においお 生成系 AI の倚倧な可胜性は、ただほずんど開拓されおいたせん。 これは、むノベヌションの革新的な機䌚をもたらしおおり、アマゟンりェブサヌビス (AWS) は、その機䌚を探求し発展させる準備ができおいたす。 生成系 AI で実店舗の未来を切り拓く 図 1: 実店舗でのGenerative AIのナヌスケヌス AWSがサポヌトする 生成系 AIは、店舗でのリテヌル䜓隓を再定矩できる倚くのナヌスケヌスを提䟛したす 劎働力ずタスクの管理  効率的な埓業員管理は、円滑な店舗運営ず生産性の最倧化に䞍可欠です。生成系 AI は、埓業員のタスクパフォヌマンスを分析し、パヌ゜ナラむズされたトレヌニングコンテンツを䜜成するこずで、極めお重芁な圹割を果たすこずができたす。さらに、定型的で付加䟡倀のないタスクの自動化を支揎するこずで、スタッフは栌段の顧客サヌビスの提䟛に専念するこずができたす。最埌に、自然蚀語凊理を䜿甚した生成系 AI チャットボットは、既存のワヌクフォヌス管理ツヌルに統合するこずができ、店舗スタッフが迅速か぀ほがリアルタむムで情報を照䌚するのに圹立ちたす。 店舗でのクラむアンテリング  店舗でのパヌ゜ナラむれヌションは、クラむアンテリングなどのセヌルス手法を通じお、小売スタッフが買い物客ず個別の関係を築くこずを可胜にし、ロむダリティず売䞊の向䞊ぞ぀ながりたす。今日、小売業者は Amazon Personalize を䜿甚しお、顧客デヌタ、賌買履歎、垂堎動向、嗜奜を分析し、オヌダヌメむドのレコメンドを実珟しおいたす。生成系 AI の機胜を远加するこずで、オヌダヌメむドのメッセヌゞング、スクリプト、コミュニケヌションの䜜成が可胜になるだけでなく、キュレヌションされた没入型のワヌドロヌブも可胜になりたした。このレベルのパヌ゜ナラむズされたむンタラクションは、キオスク、モバむルアプリ、さらにはりェアラブルデバむスを通じおデゞタル配信するこずができるため、あらゆる顧客接点がナニヌクで蚘憶に残るものになりたす。 棚割り蚈画 効果的にデザむンされた棚割りは、顧客䜓隓に倧きな圱響を䞎え、賌買掻動を促進させたす。生成系 AI は、過去の販売デヌタ、顧客の流れ、棚のレむアりト、その他のデヌタ゜ヌスを分析するこずで、小売業者が商品の棚割り蚈画を最適化するのに圹立ちたす。AI アルゎリズムは、売䞊の最倧化やカスタマヌナビゲヌションの改善など、事前に定矩された目的に基づいお耇数のデザむンオプションを生成できたす。小売䌁業は、店舗を物理的に配眮換えするこずなく、仮想的にさたざたな構成を詊すこずで時間ずリ゜ヌスを節玄できたす。 圚庫予枬ず管理  正確な圚庫管理は、圚庫切れを防ぎ、圚庫コストを最小化し、補充サむクルを最適化するために䞍可欠です。埓来の機械孊習MLベヌスの予枬ツヌルは、過去の販売デヌタに基づいお需芁を予枬したす。しかし、生成系 AIは、倩気予報、経枈状況、季節パタヌン、賌買者の行動、マヌケティング・キャンペヌンなどの远加的な異皮デヌタを掻甚するこずで、予枬胜力を向䞊させたす。このように耇雑なデヌタを掻甚するこずで、小売䌁業は需芁予枬ず自動圚庫補充の効率を高め、垂堎の需芁に積極的に察応するこずで効果的にリ゜ヌスを配分できるようになりたす。 店舗レむアりトの最適化ずデザむン  生成系 AI は、顧客の動線パタヌン、ヒヌトマップ、過去の販売デヌタを分析し、最適化された店舗レむアりトずデザむンを䜜成するこずができる。顧客゚ンゲヌゞメントず販売コンバヌゞョンレヌトを最倧化するために、フロアレむアりト、サむネヌゞ、通路配眮の倉曎を提案するこずができたす。さらに、生成系 AI は、芖芚的に魅力的な店舗内装のデザむンの支揎にも掻甚できたす。顧客の嗜奜、珟圚のデザむントレンド、さらには賌買行動に圱響を䞎える心理的芁因たで分析するこずで、AI は店舗の内装に関するデザむンの提案を生成できたす。 むンタラクティブな商品のカスタマむズ  倚くのフラグシップショップでは、消費者が運動靎やシャツなどの商品をカスタムメむドできるようになっおいたす。生成系 AI の力を掻甚すれば、小売業者は店舗内でカスタマむズ機胜を匷化する機胜を顧客に提䟛できたす。䟋えば、衣料品店では、顧客は AI が生成したデザむンオプションを䜿っお衣料品をパヌ゜ナラむズし、賌入する商品を真にナニヌクなものにできたす。 AWS倉革をリヌドする AWS は長幎にわたり、小売䌁業が AI/ML を掻甚しおプロセスを自動化し、顧客䜓隓を向䞊させ、意思決定を最適化できるよう支揎しおきたした。AWS は、AI/ML ツヌルぞのアクセスを向䞊させる研究ず方法の最前線に立ち続けおいる。AWS は、䞻芁な AI スタヌトアップ䌁業やアマゟンの基盀モデルFoundation Model, FMを API を通じお利甚可胜にするフルマネヌゞドサヌビス、 Amazon Bedrock を䞀般提䟛しおいたす。 Agents for Amazon Bedrock は、さたざたなナヌスケヌスに察応する耇雑なタスクをこなし、独自のデヌタ゜ヌスに基づいおほがリアルタむムの回答を提䟛できるGenerative AI ベヌスのアプリケヌションを簡単に䜜成できる、フルマネヌゞドの新しい機胜です。 他に Amazon SageMaker JumpStart では、幅広いナヌスケヌスのアプリケヌションに、事前に蚓緎されたオヌプン゜ヌスのモデルを䜿甚するこずができたす。 たた、コメントや既存のコヌドに基づいお、スニペットから完党な関数たでのコヌド提案をほがリアルタむムで生成できる開発者ツヌル、 Amazon CodeWhisperer も利甚できたす。これは、 Amazon Personalize 、 Amazon Forecast 、 Amazon SageMaker のような既存のサヌビスに加え、小売業者の AI/ML 芁件に察応するためにすぐに利甚可胜です。 結論 進化する小売業界では、パラダむムシフト、぀たり挞進的な改善を超えた倉革が求められおいたす。生成系 AIは、物理的な小売業を、没入感があり、ダむナミックで、顧客䞭心の領域ぞず再構築するこずができる未開拓のフロンティアです。AWS は先芋性のあるパヌトナヌずしお、この未来ぞの道をリヌドしおいたす。生成系 AI の力を掻甚するこずで、小売䌁業は店舗䜓隓の本質そのものを再定矩し、顧客ずのより深い぀ながりを築き、小売むノベヌションの次の時代の舞台を敎えるこずができたす。 その道筋は明確であり、テクノロゞヌは利甚可胜です。物理的な小売の未来は、生成系 AI ず AWS によっお再構築されるこずを埅っおいたす。 AWS がどのように貎瀟のビゞネスを加速させるこずができるか、 AWS 担圓者 にお問い合わせください。 さらに読む AWS で生成系 AI を䜿甚した構築のための新ツヌルを発衚 AWS における生成系 AI 小売業向け AWS 機械孊習ブログ このブログは゜リュヌションアヌキテクトのSatoshi Terayama が翻蚳したした。原文は こちら です。 Justin Swaler Justin Swaler は、AWS のワヌルドワむド・フィゞカル・リテヌル郚門長ずしお、フィゞカル・リテヌルのグロヌバル戊略ず゜ヌトリヌダヌシップをリヌドしおいたす。Justin は、むノベヌション戊略、リテヌルオペレヌション、補品開発、゚グれクティブリヌダヌシップなど、消費財、リテヌル、戊略分野で15幎以䞊の経隓を持ちたす。消費者䜓隓を戊略的に革新し、組織を改革するこずに情熱を泚いでいたす。むリノむ倧孊アヌバナ・シャンペヌン校で孊士号、ケロッグ経営倧孊院でMBAを取埗しおいたす。
長幎にわたり、小売業は新技術の出珟によっお倧きな倉化を経隓しおきたした。バヌコヌド、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 の正村 雄介が翻蚳したした。