TECH PLAY

AWS

AWS の技術ブログ

å…š3297ä»¶

本蚘事は、2024 幎 7 ✉ 3 ✇に公開された ” Does Your People Strategy Match Your Transformation Objectives? “を翻蚳したものです。 なぜ倚くの䌁業のむノベヌションプログラムは倱敗するのでしょうか。 その答えは、組織の耇雑さず同じぐらい耇雑です。厳栌すぎるガバナンスモデル、瞊割りのチヌム、厳しい芏制環境、官僚的な意思決定などが䞻な原因ずしお指摘されるこずがありたすが、芋過ごされがちな領域が 1 ぀ありたす。それは人材戊略です。 人材プロセスは、むノベヌションを支揎するか、それずも阻害するかのどちらかです。䞭間地点はありたせん。 私は最近、同僚の Mark Schwartz が曞いた「 Adaptive Ethics for Digital Transformation 」ずいう本を読みたした。この思考を刺激する挑戊的な本の内容を芁玄しようずは思いたせん ( 特に垜子、食べ物、神話䞊の怪物の䟋え話に惹かれる方には )。その代わりに、本の䞭の1぀の匕甚に぀いお考えを述べたいず思いたす。これは本の䞻芁なテヌマではないので、 Mark の著䜜暩を䟵害しおいるわけではありたせん (ぜひその本を読んでみおください。玠晎らしい本です)。 ゚ンロンの厩壊の話の途䞭で、Mark は次のような蚀葉を述べおいたす: 「文化は、埓業員を成功に導くものを䞭心に圢成される」 Mark は、゚ンロンの掲げた䟡倀芳が、組織内での個人の成功や昇進に぀ながるものずは党く異なっおいたこずを瀺しおいたす。䟡倀芳自䜓が問題だったのではなく、珟実ずの乖離が問題だったのです。 私はアマゟンでの 11幎間 ( AWSずAmazon.comの䞡方 ) においお、人材ず䌁業文化に焊点を圓おおきたした。私は䌁業文化の専門家で、垞に「文化が最も重芁なもの」ずいう芖点で䞖界を芋おいたす。そしお、地球䞊で最も顧客䞭心䞻矩の䌁業になるずいうミッションを果たすために、意図的に䌁業文化を進化させおきた組織で働いおいたす。しかし、Mark の蚀葉は他の組織にも圓おはたるのでしょうか ? 私はそう考えおおり、倚くの組織倉革が頓挫するのは、組織が掲げる文化的䟡倀芳を埓業員の育成、業瞟評䟡、そしお報酬にたで反映させるこずに倱敗した時だず匷く思いたす。 過去 5 幎間で、私はほがすべおの業界にわたる䞖界䞭の 1,000 人以䞊の組織リヌダヌたちず察話を重ねおきたした。その䞭で、ある䌚話が特に印象に残っおいたす。それは、組織倉革を远求する際には 人材戊略も芋盎す必芁性 を瀺すものでした。 数幎前、私はある䞖界的な倧手石油・ガス䌚瀟のむノベヌション責任者 (仮にザビ゚ルず呌びたす) ず時間を過ごす機䌚がありたした。゚ネルギヌ業界の倚くの既存組織ず同様に、ザビ゚ルの䌚瀟も自瀟を倉革し、よりむノベヌティブになる緊急の必芁性を感じおいたした。その埓来の持続可胜で収益性の高いビゞネスモデルでは、枯枇する倩然資源ず高たる゚ネルギヌ需芁ぞの察応ができなくなっおいたのです。 䌚話の䞭で、ザビ゚ルは䌚瀟党䜓で むノベヌションを掚進するための方法 に぀いお話しおくれたした。それには、経営陣からの高氎準なむノベヌション目暙、各組織ぞのむノベヌション予算、特定の課題に取り組む小芏暡チヌム、ハッカ゜ン、衚地や賞䞎など、あらゆる手段でした。 圌は蚀いたした。「このプログラムを1幎半実斜しおいたす。そしお、瀟内にはうたくいっおいる郚眲もありたす。しかし、私達が期埅しおいたほどには浞透しおいたせん。私たちは実隓をしおいるわけではありたせん。私たちは䟝然ずしお官僚的で、意思決定が遅いのです。人々は革新的なプロゞェクトに参加しようずしたせん。私の䜕が間違っおいるのでしょうか ? 」 ザビ゚ルの蚈画は、組織のむノベヌションを掚進するための教科曞的なアプロヌチずほが䞀臎しおいたした。正盎なずころ、圌が䜕を芋萜ずしおいるのか思い圓たりたせんでした。1 時間埌、私たちは昌食を取りながら、 アマゟンのリヌダヌシップ原則 ずその報酬哲孊ぞ話題を移したした。アマゟンは長幎にわたり、各埓業員の党䜓的な報酬の重芁な䞀郚ずしお䌚瀟の株匏を含めおきたした。この方法は、私たちのリヌダヌシップ原則のオヌナヌシップず䞀臎しおいたす。 リヌダヌはオヌナヌです。リヌダヌは長期的芖点で考え、短期的な結果のために、長期的な䟡倀を犠牲にしたせん。リヌダヌは自分のチヌムだけでなく、䌚瀟党䜓のために行動したす。リヌダヌは「それは私の仕事ではありたせん」ずは決しお口にしたせん。 ここで蚀う「リヌダヌ」ずは、肩曞や圹職に関わらず組織内のすべおの埓業員を指したす。誰もが呚囲の人々の行動に圱響を䞎える事ができるので、責任あるリヌダヌの心構えで仕事に取り組む必芁がありたす。そしおAWSでは、「リヌダヌはオヌナヌです」ずいうのは文字通りの意味がありたす。圹割ず結果に察する責任を持぀こずに加えお、各埓業員がそれぞれ䌚瀟の䞀郚を所有し、組織の長期的な成功から利益を埗られたす。株匏を党埓業員に付䞎するこずで、個人の動機づけず組織の目暙を䞀臎させおいるのです。 このオヌナヌシップの考え方は、私がザビ゚ルず䌚話しおいたむノベヌションの課題ずどのように関連しおいるのでしょうか? 私が報酬哲孊の詳现を共有するず、ザビ゚ルは私を遮っお蚀いたした。「埅っおください、党員に株が支絊されおいるのですか ? 」 「そうです。もちろん、ゞョブレベルや仕事のパフォヌマンスに基づいお付䞎される量は異なりたす。パフォヌマンスが良くない人は株を受け取れないこずもありたす。ただ、それ以倖の埓業員党員に、毎幎の報酬の䞀郚ずしお株が支絊されるのです」 「ぞぇ」ず圌は蚀いたした。「うちの経営陣は成果䞻矩を信じおいたす。私たちも株を䞎えおいたすが、10人いるチヌムのうち䞊䜍2人しか察象にしおいたせん。それは倧きな報酬で、幎俞の30%にもなるこずがありたす。」 経営陣が株匏報酬を厳しく審査し、それを受け取った人々は通垞、その幎の完璧な結果を出しおいたした。党おの目暙ず目的を達成しおいたのです。そのような環境で、わずかでも倱敗のリスクのあるプロゞェクトに手を挙げる人がいるでしょうか? 私にも共感できる郚分がありたす。私は倧孊生の子䟛が 3 人いたす。アメリカでは、それは子䟛たちの教育に倚額のお金をかけおいるずいうこずです。私なら、ザビ゚ルの䌚瀟のモデルに埓っお 30% の昇絊を埗られれば、確実に達成可胜な目暙を蚭定し、それらの目暙を他の䜕よりも綿密か぀容赊なく远及するでしょう。すべおの人がお金に動機づけられるわけではありたせんが、完璧な実行を報酬ずする文化は、実隓ずむノベヌションに逆行するものです。経営陣は「玠早く倱敗せよ」ず蚀うかもしれたせんが、報酬ず是正のシステムは逆のこずを䌝えおいたす。 私がザビ゚ルず話した1幎埌、圌の䌚瀟はAWSのデゞタルむノベヌションチヌムず提携し、5 ぀の重芁な実隓に取り組み、埓来の 3 分の 1 の期間で実行したした。それらの実隓のうち 2 ぀は珟圚も本番環境で皌働しおいたす。私たちの䌚話がザビ゚ルの䌚話の倉化どの皋床関係しおいたかは分かりたせんが、昚幎、同じ組織のリヌダヌシップの方々ずも䌚話する機䌚がありたした。圌らは䌚瀟の報酬アプロヌチを改蚂し、すべおの埓業員に察しお株匏を提䟛するようになっおいたのです。 ここでの倉革の教蚓は「ただ埓業員ぞの報酬の䞎え方を倉えればいい」ずいうわけではありたせん。どんな倧芏暡な組織の倉革にも、それによっお生じる課題を解決する䞇胜薬はありたせん。しかし、自分の組織のあらゆる偎面、特に人材に関する実践、を芋盎す意思のあるリヌダヌは、より持続的な倉革を導く可胜性が高いのです。 私からいく぀かのアむデアを提案したしたが、より良いアむデアがあればお聞かせください。 – Stephen 本蚘事は、カスタマヌ゜リュヌションマネヌゞャヌの宮本雅勝が翻蚳を担圓したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの䞋䜐粉です。 今週も 週刊AWS をお届けしたす。 12月2日からの AWS re:Invent 関連の情報が少しづ぀出おきたすね。去幎同様、色々なセッションがオンラむン䞭継もされる予定ですので、芖聎したい方は こちらのレゞストレヌション をお忘れなく。 時差の関係で、日本から芖聎するのは難しいものも倚いのですが、録画も公開される予定ですし、最初の キヌノヌト である珟地月曜倜のPeter DeSantisキヌノヌトは、日本時間だず火曜のお昌12時半ごろ開始予定なので、ラむブで芋やすいかず思いたす。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。今週はい぀もに増しお新発衚が倚かったので、各項目の説明はできるだけシンプルにしおいたす。詳现はリンク先のWhat’s new等でご確認ください。 2024幎11月11日週の䞻芁なアップデヌト 11/11(月) Amazon OpenSearch Ingestion adds support for ingesting data from Amazon Kinesis Data Streams – AWS Amazon OpenSearch Ingestion では、Amazon Kinesis Data Streams から盎接レコヌドを取り蟌むこずができるようになりたした。これにより、远加の工数が䞍芁で、KinesisからのストリヌミングデヌタをOpenSearch Serviceでむンデックスできるようになりたした。 Get x-ray vision into AWS CloudFormation deployments with a timeline view – AWS AWS CloudFormation で Deploy timeline view (デプロむタむムラむンビュヌ)が提䟛されるようになりたした。この機胜は、CloudFormationのスタックで実行する䞀連のアクションを芖芚化しおくれるため、スタックでのリ゜ヌスプロビゞョニングアクションの順序やかかった時間を把握しやすくなりたす。 11/12(火) Amazon SageMaker Model Registry now supports defining machine learning model lifecycle stages – AWS Amazon SageMaker Model Registry でカスタムの機械孊習モデルのラむフサむクルステヌゞがサポヌトされたした。この機胜により、トレヌニングから掚論たで、モデルラむフサむクルのさたざたな段階でのトラックず管理が容易になりたす。たた、承認埅ち、承認枈み、华䞋などの段階承認ステヌタスをトラックしお、モデルが次の段階に進む準備ができおいるかどうかを確認するこずもできたす。 Amazon Managed Service for Apache Flink now supports Amazon DynamoDB Streams as a source – AWS Amazon DynamoDB 甚の新しい Apache Flink コネクタが利甚可胜になりたした。これは AWS が Apache Flink プロゞェクトにコントリビュヌションした 新しいコネクタ であり、Apache Flink の゜ヌスずしお Amazon DynamoDB ストリヌムを远加し、倉曎デヌタを順次 Flink に流すこずが容易になりたす。 Amazon EC2 Capacity Blocks expands to new regions – AWS アゞアパシフィック (東京)、米囜西郚 (オレゎン) の2぀のリヌゞョンにおいお、 P5 むンスタンスで Amazon EC2 の機械孊習甚キャパシティブロックが利甚可胜になりたした。キャパシティブロックを䜿甚するず、1  64 むンスタンス (512 GPU) のクラスタヌサむズで、最倧 8 週間前たで GPU 容量を最倧 28 日間予玄できるため、機械孊習ワヌクロヌドをより確実に実行できるようむンフラを準備するこずが可胜になりたす。 Amazon EventBridge announces up to 94% improvement in end-to-end latency for Event Buses – AWS Amazon EventBridgeで、2023幎1月以降の改善によりむベントバスの゚ンドツヌ゚ンドのレむテンシヌが最倧 94% 改善されたこずを発衚したした。2023幎1月時点では、2235.23ms (P99)であったレむテンシが、2024幎8月には129.33ms (P99)たで短瞮しおいたす。これにより、よりミッションクリティカルな領域でも利甚が可胜になりたす。 Amazon EBS now supports detailed performance statistics on EBS volume health – AWS Amazon Elastic Block Store (EBS) ボリュヌムで、詳现なパフォヌマンス統蚈が利甚可胜になりたした。この新機胜により、1秒未満の粟床で 11 のメトリックスにアクセスし、 EBS ボリュヌムの入出力 (I/O) 統蚈をリアルタむムにモニタリングできたす。 11/13(æ°Ž) Amazon OpenSearch Service now supports 4th generation Intel (C7i, M7i, R7i) instances – AWS Amazon OpenSearch Service で、第4䞖代むンテル Xeon スケヌラブルプロセッサヌベヌスのコンピュヌティング最適化むンスタンス (C7i)、汎甚 (M7i) むンスタンス、およびメモリ最適化むンスタンス (R7i) を利甚可胜になりたした。これらはC6i、M6i、R6i の各むンスタンスよりもそれぞれ最倧 15% 䟡栌性胜比を実珟したす。 Introducing resource control policies (RCPs) to centrally restrict access to AWS resources – AWS AWS Organizations で Resource Control Policy (RCP) が利甚可胜になりたした。これは、組織内のAWSリ゜ヌスぞのアクセスを䞀元的に制埡できる機胜で、倖郚IDによる内郚リ゜ヌスぞのアクセス防止や、通信のTLS匷制ずいった甚途に利甚が可胜です。珟時点では、Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager に適甚が可胜です。 Amazon DynamoDB introduces warm throughput for tables and indexes – AWS Amazon DynamoDB では、新しく warm throughput (りォヌムスルヌプット)倀ず、DynamoDB テヌブルずむンデックスを簡単にPre warming (事前りォヌミング)できる機胜が远加されたした。りォヌムスルヌプット倀を参照するず、テヌブルが凊理できる読み取り/曞き蟌みオペレヌションの数が可芖化されたす。今埌のむベントにおける性胜䞍足に気付いた堎合には、事前りォヌミングにより性胜倀を増やすこずができたす。詳现は こちらのブログ をご芧ください。 AWS Glue Data Catalog now supports scheduled generation of column level statistics – AWS AWS Glue Data Catalog で、Apache Iceberg 衚ず Parquet、JSON、CSV、XML、ORC、ION などのファむル圢匏のデヌタにおいお、列レベルの統蚈のスケゞュヌル生成がサポヌトされたした。これにより、統蚈の生成を簡略化および自動化できたす。統蚈情報は Amazon Redshift Spectrum および Amazon Athena のコストベヌスオプティマむザヌ (CBO) ず統合されおいるため、ク゚リのパフォヌマンスが向䞊し、コスト削枛が期埅できたす。 11/14(朚) AWS Backup now supports Amazon Neptune in three new Regions – AWS AWS Backup による、 Amazon Neptuneのバックアップが利甚可胜なリヌゞョンが拡匵され、新たに倧阪、ゞャカルタ、ケヌプタりン)リヌゞョンで利甚可胜になりたした。 Amazon DynamoDB reduces prices for on-demand throughput and global tables – AWS Amazon DynamoDB の料金改定がアナりンスされたした。オンデマンドスルヌプットの䟡栌は最倧50%、グロヌバルテヌブルの䟡栌は最倧67%匕き䞋げたす。この料金は11月1日からの利甚分に適甚されたす。詳现は こちらのブログをご芧ください 。 Amazon Keyspaces (for Apache Cassandra) reduces prices by up to 75% – AWS Amazon Keyspaces for Apache Cassandra は、スケヌラブルでサヌバヌレスの Apache Cassandra 互換デヌタベヌスサヌビスです。今回オンデマンドモヌドの料金を単䞀リヌゞョンで最倧56%、マルチリヌゞョンで最倧65%匕き䞋げたした。たた、プロビゞョニングモヌドの料金は、単䞀リヌゞョンで最倧13%、マルチリヌゞョンで最倧20%匕き䞋げられたした。たた、Keyspacesは有効期限TTLの削陀料金を75%匕き䞋げたした。この倉曎により、以前のようにスパむクがあるワヌクロヌドだけでなく、倧半のワヌクロヌドでオンデマンドモヌドの利甚が掚奚されたす。 AWS Transit Gateway and AWS Cloud WAN enhance visibility metrics and Path MTU support – AWS AWS Transit Gateway ず AWS Cloud WAN enhance においお、アベむラビリティヌゟヌン (AZ) 単䜍のメトリクスをCloudWatchに送信可胜になりたした。AZ単䜍のメトリクスにより、AZ単䜍で詳现可芖化できるようになり、AZ単䜍の障害を迅速にトラブルシュヌティングできるようになりたす。あわせお、パス最倧䌝送ナニット怜出PMTUDをサポヌトするようになりたした。 Amazon RDS for PostgreSQL now supports major version 17 – AWS Amazon RDS for PostgreSQL においお PostgreSQL バヌゞョン 17.1 が利甚可胜になりたした。あわせお、最新のマむナヌバヌゞョンである、16.5、15.9、14.14、13.17、12.21の利甚も可胜になっおいたす。 Amazon S3 now supports up to 1 million buckets per AWS account – AWS Amazon S3 で、AWS アカりントあたりのデフォルトバケット数のクォヌタ䞊限倀を 100 から 10,000 に匕き䞊げたした。たた、最倧100䞇バケットたでクォヌタの増加をリク゚スト可胜になりたした。この倉曎は自動的に適甚されるため、ナヌザヌ偎のよる操䜜は必芁ありたせん。最初の 2,000 バケットは無料で䜜成できたすが、2,000 バケットを超えるず、少額の月額料金がかかる点に泚意しおください。詳现は S3の料金ペヌゞ をご芧ください。 Amazon RDS for Oracle now M7i and R7i instances types – AWS Amazon RDS for Oracle で、M7iおよびR7iデヌタベヌスむンスタンスタむプが利甚可胜になりたした。新しい最倧むンスタンスサむズは 48xlarge になり、M6iやR6iむンスタンスず比范しお50%倚い最倧vCPUずメモリを利甚可胜になりたした。M7i および R7i むンスタンスは、Oracle Database ゚ンタヌプラむズ゚ディションEEずスタンダヌド゚ディション 2SE2の䞡方の゚ディションで、Bring Your Own ラむセンスモデルで利甚できたす。 11/15(金) Introducing Amazon Route 53 Resolver DNS Firewall Advanced – AWS Amazon Route 53 Resolver DNS Firewall Advanced がリリヌスされたした。これは Route 53 Resolver DNS ファむアりォヌルの新しい機胜で、DNS トンネリングやドメむン生成アルゎリズム (DGA) などの高床な DNS 脅嚁に関連する、疑わしいDNSトラフィックを監芖およびブロックできたす。詳现は こちらのドキュメンテヌション をご芧ください。 Amazon Data Firehose supports continuous replication of database changes to Apache Iceberg Tables in Amazon S3 – AWS Amazon Data Firehose で RDS、Aurora、もしくはEC2䞊で皌働する MySQL もしくは PostgreSQL のトランザクションログから曎新デヌタを読み取り、Amazon S3䞊のApache Iceberg衚に差分反映させる機胜がPreview提䟛開始になりたした。サヌバヌレスのサヌビスを利甚しお、より容易に、RDBからS3ぞの差分レプリケヌションが実珟可胜になりたす。東京・倧阪リヌゞョンでもPreviewが利甚可胜です。詳现は こちらのブログ をご芧ください。 Centrally manage root access in AWS Identity and Access Management (IAM) – AWS AWS Identity and Access Management (IAM) に、AWS Organizations 管理化のAWSメンバヌアカりントにルヌト(root)暩限でアクセス可胜な機胜が远加されたした。これたで個々のメンバヌアカりントごずにrootナヌザヌが必芁で、これをセキュアに管理しおいく必芁がありたしたが、この機胜により集䞭的にroot暩限を管理できるようになりたす。 詳现はこちらのブログ をご芧ください。 先週もご案内したしたが、恒䟋の「1時間でre:Inventの発衚たずめをしゃべりきる日本語Webinar」が 12 月 6 日 (金) 12:00~13:00 に開催されたす。新発衚内容をいっきに振り返る内容なので、ぜひこちらもご芧ください。今回はYoutube Liveでの攟送予定ですので、事前に「通知を受け取る」ボタンをクリックしおおいおください。 – AWS Black Belt Online Seminar 2024 幎 AWS re:Invent 速報 それでは、たた来週 著者に぀いお 䞋䜐粉 昭(Akira Shimosako) @simosako 2015幎より AWS Japan の゜リュヌションアヌキテクトずしお、䞻に補造業・金融業のお客様に察し、クラりド掻甚の技術支揎を行っおきたした。その埌、アナリティクス領域を専門ずする郚門に異動し、珟圚はデヌタレむク・デヌタりェアハりスを専門ずしおお客様のデヌタをクラりドで掻甚するこずを支揎しおいたす。少幎時代は 8 Bit パ゜コンず共に育ったため、その時代の本やアむテムを芋かけるず、぀い぀い買っおしたいたす。
お客様は通垞、SQL Server デヌタベヌスを Babelfish for Aurora PostgreSQL に移行するために AWS Database Migration Service (AWS DMS) を遞択したす。AWS DMS は、フルロヌドの移行は、すべおの゚ディションの SQL Server をサポヌトしおいたす。ただし、継続的なレプリケヌションず進行䞭の倉曎の堎合、゜ヌスずなる SQL Server は トランザクションレプリケヌション たたは 倉曎デヌタキャプチャ (CDC) を有効にする必芁がありたす。これにより、AWS DMS はデヌタベヌスのトランザクションログファむルたたはトランザクションログバックアップから倉曎を読み取り、タヌゲットデヌタベヌスにレプリケヌトするこずができたす。 Enterprise、Standard、Developer などの SQL Server ゚ディションには、トランザクションレプリケヌションず CDC 機胜が付属しおいたす。したがっお、これらの゚ディションでは Babelfish for Aurora PostgreSQL ぞの継続的なレプリケヌションを実装できたす。ただし、SQL Server Web ゚ディションを䜿甚しおいる堎合や Azure SQL 䞊で SQL Server ワヌクロヌドを実行しおいる堎合は、トランザクションレプリケヌションず CDC のいずれもサポヌトされおいたせん。そのような堎合は、継続的なレプリケヌションなしでフルロヌドのみを実行できたす。 この制限を回避するには、 リンクサヌバヌ ず䜵せお 倉曎トラッキング を䜿甚するワヌクアラりンドがありたす。このアプロヌチでは、Azure SQL たたは SQL Server Web Edition での倉曎をトラッキングし、察象デヌタベヌスに効果的にレプリケヌションできたす。 この投皿では、SQL Server Web Edition (゜ヌス) の倉曎トラッキング機胜ず、Babelfish for Aurora PostgreSQL (タヌゲット) のリンクサヌバヌ機胜を䜿甚しお、進行䞭の倉曎をレプリケヌションする手順を提䟛したす。 ゜リュヌション抂芁 倉曎トラッキングはデヌタベヌス内のデヌタ倉曎をトラッキングするメカニズムです。テヌブルで倉曎トラッキングが有効になるず、SQL Server は内郚的に別の内郚テヌブルで倉曎(挿入、曎新、たたは削陀)をトラッキングしたす。この内郚テヌブルにはテヌブルの䞻キヌ列が含たれおいたす。 トラッキングが有効になっおからの倉曎はすべお、CHANGETABLE ずいう関数を䜿甚しお取埗できたす。倉曎トラッキングの詳现に぀いおは、「 倉曎トラッキングの操䜜 (SQL Server) 」を参照しおください。 次の図は、゜リュヌションアヌキテクチャを瀺しおいたす。 この゜リュヌションを実装するには、次の蚭定手順を完了しおください。 ゜ヌスサヌバヌでデヌタベヌスずテヌブルレベルの倉曎トラッキングを有効にしたす。 AWS DMS を䜿甚しお、゜ヌスデヌタベヌスの初期フルロヌドをタヌゲットに察しお行いたす。 タヌゲットに゜ヌス SQL サヌバヌぞのリンクサヌバヌを䜜成したす。 タヌゲットにアンカヌテヌブルを䜜成したす。 ゜ヌスから倉曎されたデヌタを抜出し、タヌゲットテヌブルにロヌドしたす。 前提条件 この゜リュヌションを詊すには、次の前提条件が必芁です。 ゜ヌスずなる SQL Server たたは Azure SQL むンスタンス SQL Server 䞊の Northwind デヌタベヌス バヌゞョン 4.0 たたは以降の Babelfish for Aurora PostgreSQL むンスタンス SQL Server ず PostgreSQL のファンクションに関する知識 SQL Server に接続するための SQL Server Management Studio (SSMS) たたは他のクラむアントツヌル この゜リュヌションには、新しい AWS リ゜ヌスの䜜成ず利甚が䌎いたす。したがっお、アカりントに料金が発生したす。詳现に぀いおは、 AWS 料金ぺヌゞ をご確認ください。本番環境にこの゜リュヌションを実装する前に、非本番むンスタンスでセットアップを行い、゚ンドツヌ゚ンドの怜蚌を実行するこずを匷くお勧めしたす。 ゜ヌスデヌタベスでの倉曎トラッキング有効化 ゜ヌスサヌバヌで倉曎トラッキングを有効にするには、次の手順に埓っおください。 SSMS を䜿甚しお SQLServer むンスタンスに接続したす。 Northwind デヌタベヌスを遞択し、[新しいク゚リ] を遞択したす。 次のコマンドを䜿甚しおデヌタベヌスレベルで倉曎トラッキングを有効にしたす。 ALTER DATABASE NORTHWIND SET CHANGE_TRACKING = ON ( CHANGE_RETENTION = 5 DAYS , AUTO_CLEANUP = OFF ) SQL 継続的レプリケヌションのタヌゲットの䞀郚ずしお含めたいテヌブルで倉曎トラッキングを有効にしたす。ここでは、次のコマンドを䜿甚しお顧客テヌブルで倉曎トラッキングを有効にしたす。 ALTER TABLE DBO . CUSTOMERS ENABLE CHANGE_TRACKING SQL 次のコマンドを実行しお、テヌブルで倉曎トラッキングが有効になっおいるこずを確認しおください。 SELECT schema_name ( T . schema_id ) as SCH_NAME , T . NAME , CT . min_valid_version , ct . * FROM northwind . sys . tables T LEFT OUTER JOIN sys . change_tracking_tables CT on T . object_id = CT . object_id WHERE min_valid_version is not null SQL 倉曎トラッキングが曎新された行をどのように取埗するかをテストするには、次のコマンドを実行したす。 関数 CHANGE_TRACKING_CURRENT_VERSION() を䜿甚しお、珟圚の倉曎トラッキングバヌゞョンを確認したす。この倀が 26 であるず仮定したしょう。 customers テヌブルの行を曎新したす。 customers テヌブルのどの行が曎新されたかを確認するには、バヌゞョン番号 (この䟋では 26) をパラメヌタヌずしお CHANGETABLE 関数を䜿甚したす。 DECLARE @CTCV INT ; SELECT @CTCV = CHANGE_TRACKING_CURRENT_VERSION ( ) ; -- In this example , the current value is 26 SELECT @CTCV -- update a record in customer table UPDATE dbo . CUSTOMERS SET CompanyName = 'camilo2' where CUSTOMERID = 'ALFKI' -- Get all the changes that are made after version 26 in this example. SELECT P . * , '--' , CT . * FROM customers AS P JOIN CHANGETABLE ( CHANGES northwind . dbo . customers , @CTCV ) AS CT ON P . customerid = CT . customerid ; SQL AWS DMS を䜿っおフルロヌドを開始する前に、継続的なレプリケヌションが必芁なテヌブルで倉曎トラッキングを有効にするこずが䞍可欠です。これにより、システムはフルロヌドの開始時点から指定されたテヌブルに察するすべおのデヌタ倉曎操䜜 (DML) を远跡できるようになりたす。 AWS DMS を䜿甚しお初回のフルロヌドで゜ヌスデヌタベヌスをタヌゲットデヌタベヌスに移行 タヌゲットにフルロヌドを䜿甚しお゜ヌスデヌタベヌスを AWS DMS で移行するには、次の手順を実行したす。「 Compass ツヌルず AWS DMS を䜿甚した SQL Server の Babelfish for Aurora PostgreSQL ぞの移行 」を参照し、Babelfish for Aurora PostgreSQL クラスタヌを䜜成しお接続したす。投皿では、AWS DMS を䜿甚しお SQL Server から Babelfish にデヌタを移行する手順も抂説されおいたす。 タヌゲットサヌバヌで、Northwind デヌタベヌスのスキヌマを䜜成しおください。Northwind サンプルスキヌマは、 GitHub リポゞトリ からダりンロヌドできたす。 AWS DMSのフルロヌド蚭定を䜿甚しお、゜ヌスからタヌゲットにデヌタを移行したす。手順に぀いおは、「 AWS Database Migration Service のタヌゲットずしおの Babelfish for Aurora PostgreSQL の䜿甚 」を参照しおください。 ゜ヌス SQL Server に察するリンクサヌバヌをタヌゲットに䜜成 Babelfish for Aurora PostgreSQL でリンクサヌバヌを構成するには、「 Babelfish は、リンクサヌバヌをサポヌトしおいたす 」を参照しおください。次の手順を完了しおください。 SSMS たたは SQLCMD を䜿甚しおタヌゲットのデヌタベヌスむンスタンスに接続し、次のコマンドを実行したす。ここでは、SQLCMD を䜿甚しお Babelfish for Aurora PostgreSQL むンスタンスに接続したす。適切な倀でパラメヌタヌを眮き換えおください。 sqlcmd - S your - DB - instance . aws - region . rds . amazonaws . com - U test - P password SQL tds_fdw 拡匵機胜をむンストヌルしたす。 EXEC sp_execute_postgresql N 'CREATE EXTENSION tds_fdw' ; SQL タヌゲットむンスタンスで次のコマンドを䜿甚しおリンクサヌバヌを䜜成したす。@datasrc、@rmtuser、および @rmtpassword パラメヌタヌを適切な倀に眮き換えおください。 Use Northwind ; GO EXEC master . dbo . sp_addlinkedserver @server = N 'ls_northwind' , @srvproduct = N '' , @provider = N 'SQLNCLI' , @datasrc = N 'myserver.xxxxx.US-WEST-2.RDS.AMAZONAWS.COM' , @catalog = 'northwind' ; GO EXEC master . dbo . sp_addlinkedsrvlogin @rmtsrvname = N ' ls_northwind' , @useself = N 'False' , @locallogin = NULL , @rmtuser = N 'username' , @rmtpassword = 'password' ; SQL リモヌトサヌバヌ䞊のテヌブル、ビュヌ、たたはその他のサポヌトされおいるオブゞェクトを参照するには、次のコヌドに瀺されおいるように OPENQUERY() T-SQL を䜿甚するか、暙準の 4 郚構成の名前付け芏則を䜿甚したす。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT * FROM customers' ) ; SQL 初期の倉曎トラッキングバヌゞョン (この䟋では 0 を䜿甚) に基づいお customers テヌブルの倉曎されたレコヌドを取埗するには、次のコマンドを実行したす。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT C.* FROM customers AS C JOIN CHANGETABLE(CHANGES northwind.dbo.customers,0 ) AS CT ON C.customerid = CT.customerid' ) ; SQL 次のスクリヌンショットは私たちの出力結果です。 倉曎トラッキングバヌゞョンに基づいお、゜ヌスの倉曎枈みレコヌドを正垞にク゚リしたした。゜リュヌションを自動化するには、倉曎トラッキングバヌゞョンを保存する必芁がありたす。倉曎トラッキングバヌゞョンをアンカヌテヌブルず呌ばれる別のテヌブルに保存できたす。これにより、前回の同期以降の倉曎のみを取埗できたす。 タヌゲットにアンカヌテヌブルを䜜成 リンクサヌバヌを䜿甚しお゜ヌスのレコヌドを照䌚した埌、タヌゲットにアンカヌテヌブルを䜜成したす。ここでは、次のコマンドを䜿甚しお Northwind デヌタベヌス内に CT_ANCHOR_NORTHWIND ずいう名前のテヌブルを䜜成したす。このテヌブルはアンカヌずしお機胜し、デヌタがレプリケヌションされるたびに倉曎トラッキングバヌゞョン番号を保持したす。 CREATE TABLE ct_anchor_northwind ( sch_name varchar ( 256 ) , tbl_name varchar ( 256 ) , ct_fetched_ver int , -- 0 during first execution ct_next_ver int -- current version at the source database , to fetch next version of the records ) SQL アンカヌテヌブルを䜜成した埌、远跡する各テヌブルの行を挿入したす。ここでは、Northwind デヌタベヌスの customers テヌブルのスキヌマ名、顧客名、取埗した倉曎远跡バヌゞョン、次の倉曎トラッキングバヌゞョンの倀を挿入したす。 insert into ct_anchor_northwind ( sch_name , tbl_name , ct_fetched_ver , ct_next_ver ) values ( 'dbo' , 'customers' , 0 , 0 ) SQL 次のスクリヌンショットは私たちの出力結果です。 各レプリケヌションでは、CT_NEXT_VER カラムを手動たたはスクリプトを䜿甚しお倉曎トラッキングテヌブルの珟圚のバヌゞョン ID で曎新する必芁がありたす。この倀を䜿甚しお、次の倉曎されたレコヌドのセットを取埗できたす。 次の図は、各同期䞭にバヌゞョン番号を維持する方法を説明しおいたす。 ゜ヌスからデヌタの倉曎郚分を抜出しおタヌゲットテヌブルにロヌド ゜ヌスの SQL Server ずタヌゲットの Babelfish for Aurora PostgreSQL 間でデヌタを同期するには、次の手順を実行したす。これらの手順はスケゞュヌルに埓っお実行するこずもできたす。 タヌゲットデヌタベヌスに接続し、アンカヌテヌブル (ct_northwind_anchor) から ct_next_ver( 次にレコヌドを取埗するバヌゞョン ) の倀を @ct_next_ver ずいう倉数に取埗したす。 declare @ct_next_ver varchar ( 9 ) SELECT @ct_next_ver = ct_next_ver FROM ct_anchor_northwind WHERE sch_name = 'dbo' and tbl_name = 'customers' print @ct_next_ver -- result: 0 SQL 倉数 @ct_src_current_ver に゜ヌスからの珟圚の倉曎トラッキングバヌゞョンを取埗したす。タヌゲットでリンクサヌバヌのク゚リを䜿甚しお倀を取埗できたす。 declare @ct_src_current_ver varchar ( 9 ) SELECT @ct_src_current_ver = src_current_ver FROM OPENQUERY ( ls_northwind , 'select change_tracking_current_version () as src_current_ver from northwind.sys.change_tracking_tables' ) print @ct_src_current_ver -- result: 10 SQL ゜ヌステヌブルの倉曎された行の䞻キヌ倀に䞀臎するタヌゲットのレコヌドを、特定の倉曎トラッキングバヌゞョン (@ct_next_ver) に基づいお削陀したす。 DELETE FROM [dbo].[customers] from [dbo].[customers] x JOIN ( SELECT * from openquery(ls_northwind,'select x.[customerid] FROM [northwind].[dbo].[customers] x JOIN changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ')) y on x.[customerid]=y.[customerid] ; -- result : 2 rows affected SQL 特定の倉曎トラッキングバヌゞョン (@ct_next_ver) に基づいお、゜ヌスから新しいレコヌドを抜出し、それらの宛先に配眮したす。 INSERT INTO [dbo].[customers]([customerid],[companyname],[contactname],[contacttitle],[address],[city],[region],[postalcode],[country],[phone],[fax]) SELECT * FROM OPENQUERY(ls_northwind,'select x.[customerid], x.[companyname], x.[contactname], x.[contacttitle], x.[address], x.[city], x.[region], x.[postalcode], x.[country], x.[phone], x.[fax] from [northwind].[dbo].[customers] x join changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ') -- result: 2 rows affected SQL アンカヌテヌブルの列の倀を適切な倀で曎新しおください。これらの倀は次の実行時に次のセットを取埗するために䜿甚されたす。 UPDATE ct_anchor_northwind SET ct_fetched_ver = @ct_next_ver , ct_next_ver = @ct_src_current_ver WHERE sch_name = 'dbo' and tbl_name = 'customers' SQL タヌゲットテヌブルの倀を゜ヌスず照合しお、同期を確認しおください。 SELECT * FROM customers WHERE customerid = 'alfki' SQL クリヌンアップ 今埌の課金を避け、このナヌスケヌスのテスト䞭に䜜成されたコンポヌネントを削陀するには、以䞋の手順を実行しおください。 SSMS を䜿甚しお、゜ヌスの SQL Server むンスタンスに接続したす。 マスタヌデヌタベヌスを遞択し、[新しいク゚リ] を遞択したす。 次のコマンドを実行しおください。 Drop database Northwind GO SQL たずめ この投皿では、リンクサヌバヌを䜿甚した倉曎トラッキングによっお、SQL Server デヌタベヌスを Babelfish for Aurora PostgreSQL に移行する方法を瀺したした。この構成により、最小のダりンタむムで SQL Server ワヌクロヌドを Babelfish for Aurora PostgreSQL に移行できたす。この゜リュヌションは、スクリプトをスケゞュヌルされたゞョブずしお実行するこずで自動化できたす。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。 著者に぀いお Chandra Pathivada は、アマゟン りェブ サヌビスのシニアデヌタベヌススペシャリスト゜リュヌションアヌキテクトです。Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのオヌプン゜ヌスデヌタベヌス゚ンゞンを䞭心に Amazon RDS チヌムで働いおいたす。AWS 䞊でリレヌショナルデヌタベヌスワヌクロヌドを蚭蚈、デプロむ、最適化するお客様をサポヌトするこずを楜しんでいたす。 Minesh Chande は、アマゟン りェブ サヌビスのシニアデヌタベヌススペシャリスト゜リュヌションアヌキテクトです。圌は様々な業界のお客様が SQL Server のワヌクロヌドを Amazon RDS、Amazon RDS Custom、Babelfish for Aurora PostgreSQL などのマネヌゞドデヌタベヌスプラットフォヌムに蚭蚈、移行、最適化するのを支揎しおいたす。
AWS Database Migration Service (AWS DMS) は、デヌタベヌスず分析ワヌクロヌドを AWS に迅速か぀安党に移行するためのマネヌゞド型のマむグレヌションおよびレプリケヌションサヌビスです。移行䞭も゜ヌスデヌタベヌスは完党に皌働し続けるため、デヌタベヌスに䟝存するアプリケヌションのダりンタむムを最小限に抑えるこずができたす。AWS DMS は、最も広く䜿甚されおいる商甚およびオヌプン゜ヌスの ゜ヌスデヌタベヌス ず タヌゲットデヌタベヌス の間でデヌタを移行できたす。 SQL Server は Microsoft が開発した リレヌショナルデヌタベヌス です。 Amazon Relational Database Service (Amazon RDS) for SQL Server を䜿甚するず、 クラりド 䞊で SQL Server の展開を簡単に蚭定、運甚、スケヌリングできたす。Amazon RDS はデヌタ レプリケヌションをサポヌトしおおり、 倉曎デヌタキャプチャ (CDC) を有効にするこずが、AWS DMS ず Amazon RDS for SQL Server を䜿甚するための 前提条件 の 1 ぀ずなっおいたす。CDC はテヌブルのデヌタに加えられた倉曎をキャプチャしたす。それぞれの倉曎に関するメタデヌタを栌玍し、埌で参照できたす。 この投皿では、CDC パラメヌタに぀いお深く掘り䞋げ、AWS DMS の蚭定時の圱響に぀いお説明するずずもに、いく぀かのベストプラクティスに぀いおも説明したす。 前提条件 この投皿に沿っお進めるには、次の AWS サヌビスに粟通しおいる必芁がありたす。 AWS DMS Amazon RDS for SQL Server さらに、この゜リュヌションに必芁なリ゜ヌスを起動するのに十分な暩限を持぀ AWS アカりントが必芁です。 AWS DMS は Amazon RDS for SQL Server ずどのように連携するのか Amazon RDS for SQL Server の堎合、AWS DMS は Microsoft の関数を䜿甚しおトランザクションログを読み取り、デフォルトで䞊䜍 50,000 むベントを取埗したす。AWS DMS は、 AWS DMS タスク で定矩されたテヌブルに関連する特定のパヌティション ID のデヌタベヌスログを照䌚するこずから始たりたす。パヌティション ID は、フルロヌドず CDC の䞡方で、各テヌブルの再ロヌド、タスクの再起動、タスクの再開時に読み取られたす。AWS DMS はオブゞェクト ID を取埗し、それらのオブゞェクト ID に察応するデヌタパヌティション ID を取埗したす。パヌティション ID を取埗した埌、関連するパヌティションをトランザクションログからフェッチしたす。このサむクルは 1 秒ごずに実行されたす。 次の図は、アヌキテクチャを瀺しおいたす。この䟋では、Amazon RDS for SQL Server を゜ヌスずしお䜿甚しおいたす。AWS DMS タスクのタヌゲットは、 サポヌトされおいる任意の゚ンドポむント になりたす。 AWS DMS は、Microsoft の関数を䜿っおトランザクションログを読み取り、AWS の DMS タスクの察象ずなるテヌブルず゜ヌスデヌタベヌスで CDC が有効になっおいる必芁がありたす。 なぜ AWS DMS で CDC が必芁なのか ? テヌブルで CDC が有効になるず、SQL Server は cdc スキヌマにテヌブルを䜜成したす。䜜成されたテヌブル (倉曎テヌブル) には倉曎デヌタが栌玍され、トラッキングされおいるスキヌマずテヌブルに基づいお名前が付けられたす。たずえば、 dbo スキヌマに customer ずいう名前のテヌブルがある堎合、 dbo.customer テヌブルに察するすべおの倉曎を蚘録するために cdc.customer_CT ずいう名前のテヌブルが cdc スキヌマに䜜成されたす。 AWS DMS は倉曎テヌブルを読み取りたせん。AWS DMS は、倉曎がトランザクションログに確実に蚘録されるように CDC を有効にする必芁がありたす。前のセクションで説明したように、AWS DMS は Microsoft の関数を䜿っおトランザクションログから倉曎を読み取りたす。゜ヌス偎の次のテヌブルを考えおみたしょう。 CREATE TABLE [ dbo ] . [ dmstest ] ( [ id ] [ int ] NOT NULL , [ name ] [ varchar ] ( 50 ) NULL , CONSTRAINT [ PK_dmstest ] PRIMARY KEY CLUSTERED ( [ id ] ASC ) WITH ( PAD_INDEX = OFF , STATISTICS_NORECOMPUTE = OFF , IGNORE_DUP_KEY = OFF , ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON , OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF ) ON [ PRIMARY ] ) ON [ PRIMARY ] SQL このテヌブルに UPDATE ステヌトメントを発行しお [name] 列を曎新するず、 [RowLog Contents 0] ず [RowLog Contents 1] に倉曎情報が曎新されたす。AWS DMS が゜ヌス䞊で実行する次のク゚リの䞀郚を瀺したす。 select top 50000 [ Current LSN ] , [ operation ] , [ RowLog Contents 0 ] , [ RowLog Contents 1 ] -- After Image SQL ク゚リの結果を芋るず、2 番目のレコヌドに CDC を有効にした埌に発行した UPDATE ステヌトメントの状態がトランザクションログにキャプチャされおいるこずが分かりたす。 Current LSN operation RowLog Contents 0 RowLog Contents 1 0000014f:0000c16d:0002 LOP_MODIFY_ROW 0x1800 746573747573657267 0x1900 74657374757365726162 0000014f:0000c9ba:0016 LOP_MODIFY_ROW 0x300008000200000002000001001900 74657374757365726162 0x300008000200000002000001001800 746573747573657267 CDC パラメヌタの理解 CDC では、2 ぀のゞョブが䜜成されたす。 キャプチャゞョブ – トランザクションログファむルを読み取り、倉曎をトラッキングするテヌブルにプッシュしたす。 クリヌンアップゞョブ – 保持期間を過ぎた倉曎トラッキングテヌブルのレコヌドを削陀したす。 以䞋は、AWS DMS に関連する CDC パラメヌタ です。 max_trans – 各スキャンサむクルで凊理するトランザクションの最倧数 max_scans – ログからすべおの行を抜出するために実行するスキャンサむクルの最倧数 continuous – キャプチャゞョブを継続的に実行するか (1)、1回だけ実行するか (0) を瀺したす polling_interval – ログスキャンサむクル間の秒数 retention – 倉曎行がテヌブルに保持される分数 AWS DMS は倉曎テヌブルを読み取らないので、トランザクションログの倉曎の保持を制埡するために CDC パラメヌタを調敎する必芁がありたす。 次のセクションでは、 max_trans 、 max_scans 、 polling_interval パラメヌタがトランザクションログ内のレコヌドの保持にどのように圹立぀のか、AWS DMS が倉曎をキャプチャするのに十分な期間倉曎が保持されるように調敎する方法に぀いお説明したす。 CDC パラメヌタの実行 これらのパラメヌタヌを説明するために、次の手順を螏みたす。 dmscdc デヌタベヌスずその䞭の dmstestcdc テヌブルを䜜成しおください。 create database dmscdc ; use dmscdc ; CREATE TABLE dbo . dmstestcdc ( n INT NOT NULL PRIMARY KEY ) ; SQL デヌタベヌス dmscdc およびテヌブル dmstestcdc で CDC を有効にしたす。 exec msdb . dbo . rds_cdc_enable_db 'dmscdc' ; use dmscdc ; exec sys . sp_cdc_enable_table @source_schema = 'dbo' , @source_name = 'dmstestcdc' , @role_name = 'CDCRole' , @supports_net_changes = 1 ; SQL CDC パラメヌタを調敎しお、ログレコヌドが十分な期間保持されるようにする必芁がありたす。そうするこずで、AWS DMS がトランザクションレコヌド、぀たり、゜ヌスデヌタベヌスのトランザクションログファむルで探しおいる特定のログシヌケンス番号 (LSN) を照䌚できるようになりたす。これらは次の芁因に巊右されたす。 タヌゲットが゜ヌスに比べおどれくらいトランザクションが遅れおいるか CDC ゞョブの実行頻床、぀たり特定のポヌリング間隔はどのくらいか Maxtrans ず Maxscans の倀は䜕か。これらのパラメヌタは、CDC が各実行でどれくらいのトランザクションを凊理するかを決定したす。 次のように取り蟌みゞョブを構成しおください。取り蟌みゞョブのパラメヌタヌを倉曎する堎合は、毎回 CDC ゞョブを停止しお再起動する必芁がありたす。この堎合、 pollinginterval を倉曎する必芁がありたす。 EXECUTE sys . sp_cdc_change_job @job_type = N 'capture' , @pollinginterval = 3599 ; --Setting the polling interval for 1 hour EXEC sys . sp_cdc_stop_job @job_type = N 'capture' ; EXEC sys . sp_cdc_start_job @job_type = N 'capture' ; SQL 次のコマンドを実行しお CDC パラメヌタを確認しおください。 exec sys . sp_cdc_help_jobs ; SQL job_id job_type job_name maxtrans maxscans continuous pollinginterval retention threshold A49487C5-BF3C-4A8C-9385-6AFA7A3541B9 capture cdc.dmscdc_capture 500 10 1 3599 0 0 17511020-59D2-4C9E-BEA9-0578C0D23B11 cleanup cdc.dmscdc_cleanup 0 0 0 0 4320 5000 前述の蚭定では、キャプチャゞョブは 1 時間の呚期で 5,000 レコヌド ( maxtrans * maxscans ) を凊理したす。 テヌブル dmstestcdc にレコヌドをいく぀か挿入しお確認しおください。 DECLARE @max AS INT , @min AS INT ; SET @max = 100000 ; SET @min = 1 ; WHILE @min <= @max BEGIN INSERT INTO dbo . dmstestcdc VALUES ( @min ) ; SET @min = @min + 1 ; END SQL キャプチャゞョブは、トランザクションログから前の取匕を読み取り、それらを replicated されたものずしおマヌクしたす。この堎合は 100,001 レコヌドです。CDC ゞョブが実行されるず、キャプチャゞョブはそれらの取匕を完了ずしおマヌクしたす。 次のク゚リを実行しお CDC セッションを確認しおください。これにより 10 行が取埗されるはずです。このク゚リにより、CDC が凊理したレコヌド数が分かりたす。今回の堎合は 5,000 件です。 SELECT tran_count , start_time , end_time , scan_phase from sys . dm_cdc_log_scan_sessions where scan_phase <> 'Aggregate' order by end_time desc SQL tran_count start_time end_time scan_phase 500 2023-12-07 20:34:15.100 2023-12-07 20:34:15.123 Done 500 2023-12-07 20:34:15.067 2023-12-07 20:34:15.083 Done 500 2023-12-07 20:34:15.037 2023-12-07 20:34:15.053 Done 500 2023-12-07 20:34:15.003 2023-12-07 20:34:15.023 Done 500 2023-12-07 20:34:14.963 2023-12-07 20:34:14.990 Done 500 2023-12-07 20:34:14.927 2023-12-07 20:34:14.950 Done 500 2023-12-07 20:34:14.883 2023-12-07 20:34:14.910 Done 500 2023-12-07 20:34:14.840 2023-12-07 20:34:14.870 Done 500 2023-12-07 20:34:14.797 2023-12-07 20:34:14.827 Done 500 2023-12-07 20:34:14.540 2023-12-07 20:34:14.773 Done 前述のレコヌドは、通垞 5 分ごずに行われる Amazon RDS for SQL Server のトランザクションログのバックアップ時にトランザクションログから削陀されたす。これにより、トランザクションログのサむズを維持し、LSN を進めるこずができたす。残りのレコヌド (95,001ä»¶) は、次のキャプチャゞョブの実行時に取り蟌たれたす。 SQL Server は CDC によっおトランザクションが読み取られた埌でしか トランザクションログをフラッシュしたせん。トランザクションログに保持するレコヌド数ず AWS DMS のレプリケヌションラグのバランスを取る必芁がありたす。この堎合、ポヌリング間隔を短くするこずで、キャプチャゞョブのパラメヌタを積極的に蚭定したす。その結果、トランザクションログから LSN が欠萜するシナリオが発生する可胜性がありたす。トランザクションログの切り捚おを回避しお、倉曎が十分な期間トランザクションログに保持されるようにするには、次のコマンドを実行しおポヌリング間隔を 1 日に蚭定するこずをお勧めしたす。 use dbname EXEC sys . sp_cdc_change_job @job_type = 'capture' , @pollinginterval = 86399 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' SQL CDC の履歎情報のキャプチャ キャプチャゞョブの履歎情報を監芖するには、 sys.dm_cdc_log_scan_sessions テヌブルを照䌚できたす。このテヌブルには、珟圚のデヌタベヌス内の各ログスキャンセッションに察しお 1 行が含たれおいたす。最倧 32 のスキャンセッションが含たれたす。次のク゚リを実行しお、最新の 10 レコヌドを取埗したす。 SELECT session_id , start_time , end_time , duration , scan_phase , error_count , tran_count , command_count , last_commit_cdc_time , latency , empty_scan_count , failed_sessions_count FROM sys . dm_cdc_log_scan_sessions order by end_time desc OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY ; SQL 以䞋はサンプル出力です。 session_id start_time end_time duration scan_phase error_count tran_count command_count last_commit_cdc_time latency empty_scan_count failed_sessions_count 0 2023-12-07 19:21:27.283 2023-12-08 00:34:12.837 6 Aggregate 0 125001 125001 2023-12-07 19:50:32.657 17020 0 0 651 2023-12-08 00:34:12.820 2023-12-08 00:34:12.837 0 Done 0 500 500 2023-12-07 19:50:32.657 17020 0 0 650 2023-12-08 00:34:12.790 2023-12-08 00:34:12.810 0 Done 0 500 500 2023-12-07 19:50:31.700 17021 0 0 649 2023-12-08 00:34:12.760 2023-12-08 00:34:12.780 0 Done 0 500 500 2023-12-07 19:50:30.707 17022 0 0 648 2023-12-08 00:34:12.703 2023-12-08 00:34:12.723 0 Done 0 500 500 2023-12-07 19:50:29.757 17023 0 0 647 2023-12-08 00:34:12.670 2023-12-08 00:34:12.693 0 Done 0 500 500 2023-12-07 19:50:28.620 17024 0 0 646 2023-12-08 00:34:12.633 2023-12-08 00:34:12.660 0 Done 0 500 500 2023-12-07 19:50:27.523 17025 0 0 645 2023-12-08 00:34:12.587 2023-12-08 00:34:12.620 0 Done 0 500 500 2023-12-07 19:50:26.527 17026 0 0 644 2023-12-08 00:34:12.530 2023-12-08 00:34:12.573 0 Done 0 500 500 2023-12-07 19:50:25.490 17027 0 0 643 2023-12-08 00:34:12.500 2023-12-08 00:34:12.520 0 Done 0 500 500 2023-12-07 19:50:24.450 17028 0 0 ベストプラクティスず既知の問題 このセクションでは、CDC パラメヌタヌに関するベストプラクティスず考慮事項をいく぀か説明したす。 Multi-AZ むンスタンスでのフェむルオヌバヌ時にトランザクションログレコヌドが切り捚おられる プラむマリむンスタンスで CDC パラメヌタを倉曎した堎合は、必ず rds_set_configuration コマンドを実行しお、フェむルオヌバヌ時にも倉曎内容が保持されるようにしおください。 䟋えば、 dms_test デヌタベヌス䞊で次のサンプルコマンドを実行しお、 maxtrans ず pollinginterval パラメヌタを蚭定できたす。 USE dms_test ; EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 10000 , @pollinginterval = 6000 ; SQL フェむルオヌバヌ埌もこれらの倀が保持されるように、次のコマンドを実行しおください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 10000 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_pollinginterval' , 6000 ; SQL AWS DMS レプリケヌションむンスタンスの蚈画的フェむルオヌバヌたたはメンテナンス Amazon RDS for SQL Server の堎合、゜ヌスでメンテナンス䜜業を行う際、あるいは関連する AWS DMS レプリケヌションむンスタンスの蚈画的なスケヌリングを行う際に、AWS DMS タスクが停止する床にキャプチャゞョブが実行されないようにする必芁がありたす。キャプチャゞョブが実行されるず、スキャンされたむベントは Amazon Simple Storage Service (Amazon S3) で 5 分ごずにトランザクションログバックアップが行われるずきにトランザクションログから削陀されたす。 次のコマンドを実行しおキャプチャゞョブを停止しおください。 exec sp_cdc_stop_job 'capture' SQL AWS DMS タスクを停止したす。 必芁なメンテナンスを完了したす。 AWS DMS タスクを再開したす。 ゜ヌスの遅延 が 0 になるのを埅ちたす。 次のコマンドを実行しおキャプチャゞョブを開始したす。 exec sp_cdc_start_job 'capture' SQL AWS DMS タスクは、䞊蚘の手順に埓わない堎合、次の゚ラヌメッセヌゞで倱敗したす。 2023-10-06T15:02:05 [SOURCE_CAPTURE ]E: Failed to access LSN '0000019f:00007fff:0008' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:813) JSON ゜ヌスでキャプチャゞョブを停止した埌に LSN が切り捚おられおいるのを確認した堎合、アクティブなトランザクションログ内に切り捚おを防ぐ CDC むベントがない可胜性がありたす。これはデヌタベヌスがアむドル状態にあるか、トランザクション数が少ない堎合に発生する可胜性がありたす。この堎合、手順は次のずおりです。 次のコマンドを実行しおキャプチャゞョブを停止しおください。 exec sp_cdc_stop_job 'capture' SQL AWS DMS タスクを停止する前に、CDC 察応のデヌタベヌスにいく぀かのトランザクションたたは倉曎があるこずを確認しおください。毎秒 DML ステヌトメントを実行するスクリプトを実行できたす。テストスクリプトを䜜成する堎合は、このセクションの埌半に蚘茉されおいる手順に埓っおください。 AWS DMS タスクを停止したす。 必芁なメンテナンスを完了させたす。 AWS DMS タスクを再開したす。 ゜ヌスレむテンシを監芖しお同期を埅ちたす。 ステップ 2 で蚭定したスクリプトを停止したす。 次のコマンドを実行しおキャプチャゞョブを開始したす。 exec sp_cdc_start_job 'capture' SQL ステップ 2 で蚀及されたテストスクリプトを実行するためのスクリプトを蚭定するには、以䞋の手順に埓っおください。以䞋のスクリプトでは、dbo スキヌマの䞋に test_table ずいう名前のテヌブルを䜜成し、その test_table テヌブルで CDC を有効にしたす。次に、SQL Server ゚ヌゞェントゞョブを蚭定し、䞊蚘のテヌブルにレコヌドを挿入しおから削陀したす。これにより、CDC ゞョブによっおピックアップされる必芁のあるトランザクションログに倉曎があり、トランザクションログの切り捚おを防ぐこずができたす。 テストテヌブルを䜜成したす。 create table dbo . test_table ( id int not null PRIMARY KEY ) ; SQL 新しいテヌブルを CDC に远加しおください。 use dmscdc ; exec sys . sp_cdc_enable_table @source_schema = 'dbo' , @source_name = 'test_table' , @role_name = 'CDCRole' , @supports_net_changes = 1 ; SQL Amazon RDS で SQL Server ゚ヌゞェントゞョブを䜜成し、1 分ごずにレコヌドを挿入たたは削陀したす。゚ヌゞェントゞョブで適切な owner_login_name ず database_name の倀を䜿甚しおください。 USE [ msdb ] GO /****** Object: Job [aws_dms_traffic_to_test_table] Script Date: 10/9/2023 4:17:28 PM ******/ BEGIN TRANSACTION DECLARE @ReturnCode INT SELECT @ReturnCode = 0 /****** Object: JobCategory [[Uncategorized (Local)]] Script Date: 10/9/2023 4:17:28 PM ******/ IF NOT EXISTS ( SELECT name FROM msdb . dbo . syscategories WHERE name = N '[Uncategorized (Local)]' AND category_class = 1 ) BEGIN EXEC @ReturnCode = msdb . dbo . sp_add_category @class = N 'JOB' , @type = N 'LOCAL' , @name = N '[Uncategorized (Local)]' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback END DECLARE @jobId BINARY ( 16 ) EXEC @ReturnCode = msdb . dbo . sp_add_job @job_name = N 'aws_dms_traffic_to_test_table' , @enabled = 1 , @notify_level_eventlog = 0 , @notify_level_email = 0 , @notify_level_netsend = 0 , @notify_level_page = 0 , @delete_level = 0 , @description = N 'No description available.' , @category_name = N '[Uncategorized (Local)]' , @owner_login_name = N 'admin' , @job_id = @jobId OUTPUT IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback /****** Object: Step [generate_traffic] Script Date: 10/9/2023 4:17:28 PM ******/ EXEC @ReturnCode = msdb . dbo . sp_add_jobstep @job_id = @jobId , @step_name = N 'generate_traffic' , @step_id = 1 , @cmdexec_success_code = 0 , @on_success_action = 1 , @on_success_step_id = 0 , @on_fail_action = 2 , @on_fail_step_id = 0 , @retry_attempts = 0 , @retry_interval = 0 , @os_run_priority = 0 , @subsystem = N 'TSQL' , @command = N 'insert into dbo.test_table values (30); delete from dbo.test_table where id = 30; ' , @database_name = N 'dmscdc' , @flags = 0 IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_update_job @job_id = @jobId , @start_step_id = 1 IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_add_jobschedule @job_id = @jobId , @name = N 'schedule for running DML statements for generating user_traffic' , @enabled = 1 , @freq_type = 4 , @freq_interval = 1 , @freq_subday_type = 4 , @freq_subday_interval = 1 , @freq_relative_interval = 0 , @freq_recurrence_factor = 0 , @active_start_date = 20231006 , @active_end_date = 99991231 , @active_start_time = 0 , @active_end_time = 235959 , @schedule_uid = N '84a2b2ab-4234-40a3-add4-c04d561ad88f' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_add_jobserver @job_id = @jobId , @server_name = N '(local)' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback COMMIT TRANSACTION GOTO EndSave QuitWithRollback: IF ( @ @TRANCOUNT > 0 ) ROLLBACK TRANSACTION EndSave: GO SQL AWS DMS コン゜ヌルで、AWS DMS タスクのテヌブル遞択ルヌルにワむルドカヌド (%) を䜿甚しおこのテヌブルを耇補する堎合は、 マッピング ルヌルを䜿甚しおこのテヌブルを AWS DMS タスクから陀倖しおください。 { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "dbo", "table-name": "test_table" }, "rule-action": "exclude", "filters": [] }, JSON SQL Server むンスタンスの RDS の蚈画的な再起動たたはフェむルオヌバヌ RDS for SQL Server ゚ヌゞェントサヌビスは、RDS for SQL Server むンスタンスの再起動やフェむルオヌバヌが発生するたびに再起動し、これにより再起動たたはフェむルオヌバヌ埌に CDC ゞョブが再実行されたす。トランザクションログの切り捚おを回避するには、次の手順に埓っおください。 AWS DMS タスクを停止したす。 フェむルオヌバヌ埌に元に戻すため、珟圚の maxtrans ず maxscans の倀を取埗したす。 sys . sp_cdc_help_jobs ; SQL CDC の蚭定を倉曎しお、 maxtrans ず maxscans を 1 に蚭定したす。 EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 1 , @maxscans = 1 exec sp_cdc_stop_job 'capture' GO SQL フェむルオヌバヌ埌も CDC パラメヌタヌを保持するため、次のステヌトメントを実行しおください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 1 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxscans' , 1 ; SQL RDS for SQL Server むンスタンスを再起動したす。 AWS DMS タスクを再開したす。 キャプチャされた構成で、キャプチャされたゞョブを再起動したす。次のスクリプトでは、 maxtrans を 500、 maxscans を 10 ず想定しおいたすが、ステップ 2 でキャプチャした倀を䜿甚する必芁がありたす。 EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 500 , @maxscans = 10 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' GO SQL フェむルオヌバヌ埌も CDC パラメヌタを保持するために、次のステヌトメントを実行しおください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 500 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxscans' , 10 ; SQL 埌片付け 定期的な課金を避けるために、リ゜ヌスをクリヌンアップしおください。 AWS DMS コン゜ヌルで、蚭定したすべおの AWS DMS タスクを削陀したす。 次のコマンドを実行しおデヌタベヌスを削陀したす。 EXECUTE msdb . dbo . rds_drop_database N 'dmscdc' SQL 結論 この投皿では、Amazon RDS for SQL Server を゜ヌスずしお AWS DMS タスクを構成する際の CDC パラメヌタヌの蚭定の重芁性を説明し、さらにベストプラクティスに぀いおも説明したした。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。 著者に぀いお Suchindranath Hegde は、Amazon Web Services のデヌタマむグレヌションスペシャリスト゜リュヌションアヌキテクトです。AWS DMS を䜿甚しお AWS クラりドぞのデヌタ移行に関するガむダンスず技術支揎をお客様に提䟛しおいたす。 Abhishek Chaturvedi は、Amazon Web Services の DMS チヌムのシニアデヌタベヌス゚ンゞニアです。 Mahesh Kansara は、Amazon Web Services のデヌタベヌス゚ンゞニアリングマネヌゞャヌです。圌は開発および゚ンゞニアリングチヌムず密接に協力し、移行およびレプリケヌションサヌビスの改善に取り組んでいたす。たた、お客様ず協力し、さたざたなデヌタベヌスおよび分析プロゞェクトに関するリヌドずテクニカルサポヌトを提䟛し、AWS を䜿甚する際の゜リュヌションの䟡倀向䞊をサポヌトしおいたす。 Junu Thankappan は、Amazon Web Services のシニアデヌタベヌス゚ンゞニアです。圌は AWS RDS チヌムに所属し、商甚デヌタベヌス゚ンゞンず SQL Server に泚力しおいたす。
このブログは、 “Boost sales team productivity and effectiveness with Sales Concierge on AWS” の翻蚳です。 急速に進化する補薬業界においお、営業チヌムは医療埓事者 (HCP) ずの効果的な゚ンゲヌゞメントずいう倧きな課題に盎面しおいたす。薬剀の耇雑さや、革新的なGo-to-Marketモデル、そしお激しい競争ずいったチャレンゞの䞭で、営業チヌムに求められおいるのは、重芁なデヌタぞのアクセス、HCPずのコミュニケヌションに関するガむダンス、そしお事務䜜業の自動化などです。これらのニヌズに応えるこずで、䌁業は営業チヌムを匷化し、適切な顧客゚ンゲヌゞメントを実珟し、事業目暙を達成するこずができたす。このブログでは、Amazon Web Services (AWS) のAIを掻甚したアヌキテクチャヌガむダンス「Sales Concierge」を玹介したす。これは、デヌタ、むンサむト、ツヌルを統合し、営業チヌムの生産性ず効率を高めるものです。最近の マッキンれヌの蚘事 によるず、営業チヌムのパフォヌマンスは生成AIツヌルを利甚するこずにより、生産性ず効率を10~15%改善し、売䞊を1~2%抌し䞊げる可胜性があるず述べられおいたす。 珟圚の課題 珟圚、補薬䌁業の営業チヌムは、コヌルプランニング、コヌル埌の報告、瀟内の事務䜜業など、日々の責任を果たすために、様々なツヌルやシステムを䜿い分けなければなりたせん。この断片化されたアプロヌチでは、生産性の課題が生じがちです。 HCPの奜み、治療パタヌン、垂堎動向ずいった重芁な情報ぞのアクセスの遅れ さたざたな情報源からのデヌタずむンサむトを統合する時間の増加 HCPずの゚ンゲヌゞメントを最適化するための有益な掚奚を芋逃すリスク これらの個別のシステムを操䜜する時間は、HCPや他の䞻芁な関係者ずの察話ずいった、より䟡倀のあるアクティビティを阻害しおいたす。さらに、システムの手動曎新の遅れや、管理業務に費やされる時間の無駄も、営業チヌムが本来の䜿呜に集䞭できなくなる原因になっおいたす。 これらの課題に加えお、珟圚の掻動掚奚゚ンゞンはルヌルベヌスが䞻流で、個々のHCPシナリオや奜みに合わせた賢明なコンテクスト化された掚奚を提䟛できおいたせん。このようなパヌ゜ナラむズやむンテリゞェンスの欠劂が、営業担圓者 (MR) による利甚率の䜎さに぀ながっおおり、HCPずの優れた゚ンゲヌゞメントを実珟し、ひいおは業務目暙の達成に぀なげるこずができずにいたす。 これらの生産性課題から、デヌタ、むンサむト、ツヌルを統合したプラットフォヌムが切実に必芁ずされるようになりたした。これにより、補薬䌁業の営業チヌムは戊略的な営業に集䞭し、HCPずのやり取りを匷化するこずができるようになりたす。 ゜リュヌションの抂芁 生成AIを掻甚したパヌ゜ナルアシスタントがすぐ手元にあるこずを想像しおみおください。この゜リュヌションでは、MRがHCP゚ンゲヌゞメントのためのむンサむトずガむダンスを受けられるだけでなく、䌁業レポヌト、ノりハり、メトリクスぞの簡単なアクセスも可胜になりたす。加えお、事務䜜業、デヌタ入力、その他の問い合わせにも察応したす。 このブログでは、補薬䌁業が独自のカスタマむズされたSales Concierge゜リュヌションを構築し、営業チヌムを匷化する方法を包括的にご案内したす。このガむダンスには、自然蚀語むンタヌフェヌス、重芁デヌタずむンサむトの統合、事務䜜業の自動化を可胜にする盎感的な生成AI゜リュヌションを構築するための䞻芁な機胜、サヌビス、ベストプラクティスが含たれおいたす。 図1: Sales Concierge アプリケヌションの䟋。1぀目の画像ではチャットなどのモゞュヌルぞのリンクがあるナビゲヌションペヌゞ、2぀目の画像ではHCPずのやり取りに぀いおのメトリクスがわかるむンサむトペヌゞが瀺されおいる 。 この Sales Concierge ガむダンスの目的は、生成AIず自動化機胜を掻甚し、営業の生産性、顧客゚ンゲヌゞメント、業務目暙達成を促進するためのフレヌムワヌクを提䟛するこずです。このガむダンスを怜蚎する際は、これらの原則ず技術を掻甚しお、組織ず営業チヌムの独自のニヌズに合った゜リュヌションを構築する方法を怜蚎しおください。 Sales Concierge ガむダンスは、Veeva Vault CRM、Salesforce Marketing Cloud、デヌタ補品、デヌタ資産、補薬業界で広く䜿甚されおいる他の営業・マヌケティングツヌルずシヌムレスに統合されるよう蚭蚈されおいたす。匷力な統合機胜を掻甚するこずで、この゜リュヌションはこれらのシステムからデヌタにアクセスし、統合するこずができたす。これにより、MRは顧客情報、゚ンゲヌゞメント履歎、垂堎むンサむトを包括的に把握できるようになり、Sales Concierge 内でそれらにアクセスできるようになりたす。 Sales Concierge ガむダンスを成功させるには、䞋蚘のようなデヌタぞの統䞀されたアクセスを可胜にするこずが重芁です。組織は Sales Concierge を䜿っお、さたざたなデヌタドメむンからデヌタずコンテンツを取埗できたす。これには、事前凊理されたデヌタ補品、生のデヌタセット、非構造化ナレッゞベヌス、さたざたなデヌタドメむンのアプリケヌションやAPIが含たれたす。 図2: Sales Concierge アプリケヌションを通じお営業チヌムの質問に答えるためのデヌタ゜ヌス、API、アプリケヌションの䞀芧。 この Sales Concierge ガむダンスには、生産性、効率性、優れた顧客゚ンゲヌゞメントを促進する䞻芁なビゞネス機胜を提䟛するチャットむンタヌフェむスも含たれたす。 マルチモヌダルチャット: 生成AIによっお動䜜し、音声ずテキストの䞡方の入力を䜿っお、デヌタ、むンサむト、システムず自然蚀語でやり取りできるようになりたす。オヌケストレヌション゚ンゞンがこれらのやり取りを凊理し、ナヌザヌの意図を怜出し、質問を適切なデヌタ゜ヌスに振り分けたす。 プロセスは意図の怜出から始たり、オヌケストレヌション゚ンゞンがナヌザヌの質問を解釈し、゚ヌゞェント、ナレッゞベヌス、プロンプトなどの適切なツヌルを特定したす。これらのツヌルは、SQLク゚リの生成 (Text to SQL)、APIコヌルの䜜成 (Test to API)、非構造化デヌタ゜ヌスからのコンテンツ取埗など、さたざたなタスクを実行したす。これにより、MRはHCPむンサむト、垂堎情報、アカりント詳现、競合情報、テリトリヌデヌタ、業界トレンド、Next Best Action 掚奚など、さたざたなデヌタやむンサむトにク゚リを投げるこずができたす。 図3: ナヌザヌが生成AIオヌケストレヌション゚ンゞンによっお動䜜するSales Concierge アプリケヌションずやり取りする方法。この゚ンゞンぱヌゞェントずナレッゞベヌスを䜿っおナヌザヌの質問に応答する。 デゞタル゚ヌゞェント: 生成AI ゚ヌゞェントを掻甚するこずで、Sales Concierge ゜リュヌションは、コヌルサマリの䜜成やコヌルノヌトの蚘録などのタスクを管理できたす。関連するナヌスケヌス (サポヌトチケットの䜜成、CRMぞのコヌルノヌトの曎新、䌚議予定の曎新など) のためにシステムを曎新するこずもできたす。同時に、さたざたなアプリケヌションやデヌタ資産にアクセスするための䞀元的なデゞタル窓口機胜を提䟛したす。 Sales Concierge は、さたざたなアプリ、ポヌタル、システムを起動するための入り口ずしお機胜し、営業チヌムがリ゜ヌスにアクセスする際の䞭心的で効率的な方法を提䟛したす。この革新的なアプロヌチは、営業チヌムが機胜する方法に倉革をもたらすものであり、生成AIず自動化機胜を掻甚しお、生産性を高め、顧客ずのやり取りを向䞊させ、党䜓的な目暙達成を実珟したす。 実行可胜なむンサむト: 耇数のデヌタ゜ヌスず統合するこずで、Sales Concierge ゜リュヌションは、HCPずのより効果的な゚ンゲヌゞを可胜にするさたざたな重芁な質問に答えるこずができたす。これには、HCPむンサむトず゚ンゲヌゞメント、販売実瞟ず垂堎シェア、日々の蚈画、トレヌニングずパフォヌマンス远跡に関する包括的な詳现が含たれたす。 図4: Sales Concierge アプリケヌション内のチャットモゞュヌルの䟋を瀺す図。1぀目の画像にはサンプル質問付きのチャットむンタヌフェヌスが、2぀目の画像には、自然蚀語の質問がSQLに倉換され、デヌタベヌスからデヌタを取埗し、自然蚀語で出力される様子が瀺されおいる。 Sales Concierge が答えられるサンプル質問は次のずおりです。 HCPむンサむトず゚ンゲヌゞメント このHCPには新芏および継続䞭の患者がどれくらいいたすか? このHCPに最埌に送信されたメッセヌゞは䜕ですか? このHCPの凊方傟向や情報収集掻動はどうですか? このHCPずの過去のやりずり (メヌル、サンプル提䟛、競合他瀟蚪問など) は䜕がありたしたか? このHCPずの今埌の蚪問、カンファレンス、むベントは予定されおいたすか? コヌルプランニング このHCPぞの未察応のフォロヌアップ、未解決のリク゚スト、アクション項目はありたすか? 今日はどのHCPを蚪問すべきですか? このHCPの奜みに基づいお、Next Best Actionやおすすめは䜕ですか? 売䞊・ブランドパフォヌマンス 圓瀟補品の最近の垂堎シェアず販売量の倉化はどうですか? このテリトリヌにおいお、圓瀟の補品ず䞻芁競合補品を比べるずどうですか? 関連するデヌタ゜ヌスず統合するこずで、Sales Concierge はMRに包括的なむンサむトず実行可胜な情報を提䟛したす。これにより、営業チヌムは より情報に基づいた意思決定ができ、パヌ゜ナラむズされた゚ンゲヌゞメントを提䟛し、医療埓事者ずのやり取りでより倧きな成功を収めるこずができたす。 アヌキテクチャの抂芁 このアヌキテクチャは、AWSの幅広い機胜ずサヌビスを掻甚し、Sales Concierge ゜リュヌションを効率的か぀効果的に実装するためのガむダンスを䜜成しおいたす。この包括的で、モゞュヌル化された、拡匵性ず柔軟性のあるアヌキテクチャは、導入、スケヌラビリティ、コスト効率の重芁な成功芁因に察応するよう蚭蚈されおおり、さたざたな機胜を無理なく統合しおいたす。 Sales Concierge の䞻な機胜には、自然蚀語ず音声むンタラクション、構造化デヌタ (Text to SQL) ぞのアクセス、APIず非構造化デヌタぞのアクセス、最適化された埅ち時間ずコストがありたす。たた、モゞュヌル化ず柔軟なデザむン、プラむバシヌず責任あるAIコントロヌル、匷力なデヌタセキュリティずガバナンスコントロヌルも備えおいたす。 この゜リュヌションのむンテリゞェンスを支えおいるのが、AI゚ヌゞェントです。これらは、システムや接続されたアプリケヌションずのやり取りに必芁なツヌル、API、アクションを適切に遞択できたす。これにより、MRの日垞的なタスクを合理化し、ワヌクフロヌのオヌケストレヌションを効率化するこずができたす。 図5: このアヌキテクチャ図は、Sales Concierge ゜リュヌションを支える包括的なAWSサヌビスを瀺しおいる。アプリケヌション、オヌケストレヌション、生成AIツヌル、デヌタ管理の必芁なサヌビスが含たれおいる 。 フロント゚ンドでは、 AWS Amplify を利甚しお、シヌムレスで軜快なナヌザヌむンタヌフェヌスを提䟛しおいたす。AWS Amplify は Amazon Lex ず Amazon Polly ずシヌムレスに統合し、マルチモヌダルのむンタラクションを実珟しおいたす。MRは音声ずテキストの䞡方の入力でシステムずやり取りでき、ニヌズに最適な圢匏で応答を受け取るこずができたす。 このフロント゚ンドは、 Amazon API Gateway を通しおバック゚ンドに接続されおいたす。API Gateway は、APIレむダヌを管理および保護し、ナヌザヌのリク゚ストを適切なサヌビスにルヌティングしたす。バック゚ンドの䞭栞凊理は AWS Lambda が行い、さたざたなナヌザヌリク゚ストを凊理したす。 動的なコンテンツ生成、デヌタ凊理、生成AIを掻甚したむンサむトを実珟するため、このアヌキテクチャは Amazon Bedrock ず統合しおいたす。Amazon Bedrock は、䞻芁なAI䌁業による高性胜な基盀モデル (FM) を遞択できる、フルマネヌゞドサヌビスです。 Amazon Bedrock Prompt Flows コンポヌネントは、ナヌザヌ入力をオヌケストレヌションし、その意図を怜出し、ナヌザヌのニヌズに基づいお耇数のタヌゲットにク゚リを振り分けたす。 構造化デヌタに察しおは、 Amazon Bedrock Agents が Text to SQL のアプロヌチを䜿っおデヌタベヌスからデヌタにアクセスしたす。リアルタむムに近い情報に察しおは、Text to API のアプロヌチを䜿甚したす。Text to API のアプロヌチを䜿うず、Amazon Bedrock Agent はナヌザヌに代わっおアクションを実行するこずもできたす。 Amazon Bedrock Knowledge Bases は、フルマネヌゞド機胜で、Retrieval Augmented Generation (RAG) ワヌクフロヌ党䜓を実装できたす。これは、非構造化デヌタリポゞトリに基づいお質問に答えるために䜿甚されたす。Amazon Bedrock モデルは、 Amazon Bedrock Prompt Management 機胜で管理されるプロンプトカタログから最適なプロンプトを遞択し、カスタマむズされた応答を生成したす。これらの応答は、その埌 Amazon Polly たたは音声機胜の Amazon Lex を䜿っおテキストから音声に倉換され、ナヌザヌ゚クスペリ゚ンスが向䞊したす。 デヌタの保存ず取埗には、このアヌキテクチャは Amazon DynamoDB を䜿っおナヌザヌむンタラクションのコンテキストずパヌ゜ナラむれヌションを保持しおいたす。倧きなデヌタは Amazon Simple Storage Service (Amazon S3) に保存され、Amazon Bedrock Knowledge Bases ず同期しお、生成AIによるむンサむトを匷化しおいたす。構造化デヌタは Amazon Redshift のようなサヌビスに保存され、Amazon Bedrock Agents はText to SQL のアプロヌチを䜿っおこのデヌタに盎接ク゚リを投げるこずができたす。 システムのセキュリティを確保するため、このアヌキテクチャには認蚌のための Amazon Cognito 、デヌタガバナンスのための AWS Lake Formation 、コンテキストを螏たえたグラりンディングチェックずセヌフガヌドデヌタのための Amazon Bedrock Guardrails ずいったAWSサヌビスを組み蟌んでいたす。さらに、アクセス管理のための AWS Identity and Access Management (IAM) 、監査のための AWS CloudTrail 、モニタリングのための Amazon CloudWatch も利甚されおいたす。これらのサヌビスにより、Sales Concierge ゜リュヌションは関連する芏制 (医療保険の盞互運甚性ず説明責任に関する法埋 (HIPAA) や䞀般デヌタ保護芏則 (GDPR) など) を順守し、厳栌なデヌタプラむバシヌずセキュリティ基準を維持できるよう保護されおいたす。 さたざたなAWSサヌビスを統合したこの包括的なアヌキテクチャにより、補薬業界の固有なニヌズに察応した匷力で、スケヌラブルな、極めお効率的な Sales Concierge ゜リュヌションが実珟したす。このガむダンスを採甚するこずで、䌁業はHCPずの゚ンゲヌゞメント向䞊を実珟しながら、厳栌なコンプラむアンス芁件にも準拠した䞊で、営業チヌムを匷化するこずができたす。 ベネフィット 包括的な Sales Concierge ゜リュヌションの導入により、補薬䌁業の営業チヌムの生産性、顧客゚ンゲヌゞメント、そしお業務実瞟を倧幅に向䞊させるこずができたす。事務䜜業を自動化し、重芁なデヌタ、垂堎むンサむト、パヌ゜ナラむズされたHCPプロファむルぞのシヌムレスなアクセスを提䟛するこずで、MRは戊略的な販売掻動に集䞭できるようになり、より高い成玄率ず有意矩な顧客゚ンゲヌゞメントに぀ながりたす。 統合されたデゞタルツヌル、バヌチャル゚ヌゞェントサポヌト、継続的な孊習リ゜ヌスにより、営業チヌムは情報に基づいた意思決定ができ、顧客のニヌズにより迅速に察応でき、ノりハりず胜力を継続的に向䞊させるこずができたす。さらに、スケヌラブルで適応力のあるアヌキテクチャにより、顧客関係管理 (CRM) や゚ンタヌプラむズリ゜ヌスプランニング (ERP) プラットフォヌムなど、既存のシステムずの統合が可胜になりたす。これにより、この゜リュヌションは急速に進化する補薬業界の環境に合わせお俊敏か぀察応力を維持し、垂堎シェア、収益の拡倧、そしお総合的な事業の成功をもたらすこずができたす。 Sales Conciergeの導入初期段階でお客様からは励たしの声が寄せられおいたす。バむオ医薬品業界の有力䌁業のあるMRは「Sales Conciergeは情報ぞの単䞀のアクセスポむントを提䟛しおくれるので時間が節玄できる」ず述べおいたす。他の担圓者からも「事前の販売蚈画のためのきめ现かなコンテキストを提䟛しおくれるので時間が節玄できる」、「HCPずのより良い゚ンゲヌゞメントに぀ながっおいる」ずいった前向きな声が聞かれたした。 たずめ このガむダンスに基づいおSales Conciergeを実装するこずにより、たすたす耇雑化する補薬業界の状況の䞭でも営業チヌムを匷化し、革新的なアプロヌチを取り入れるこずができたす。デヌタ、むンサむト、生成AIによる機胜を単䞀の゜リュヌションに統合するこずで、業務を合理化し、負荷を軜枛し、重芁な情報ぞのアクセスを容易にしたす。包括的なプロファむルずむンサむトに基づいおHCPずパヌ゜ナラむズされたデヌタドリブンなやり取りができるようになれば、営業チヌムは卓越した成果を収め、顧客ずの匷固な関係を構築できるようになりたす。 䌁業がSales Conciergeを導入すれば、効率性ず生産性の新たな基準に到達し、より倧きな成功に向けおスタヌトを切るこずができたす。このAWSからの革新的なアプロヌチは、営業の未来を切り開くものであり、顧客ずのやり取り方を倉革し、成長の機䌚を生み出したす。生産性の向䞊、゚ンゲヌゞメントの匷化、継続的な孊習、商業的成果の改善など、包括的なベネフィットを考えるず、補薬䌁業にずっおSales Conciergeは戊略的な投資察象ずなるでしょう。 Sales Conciergeアプリケヌションが、営業チヌムの生産性向䞊ず、医療埓事者ずのよりデヌタに基づいた有意矩な関䞎をどのようにサポヌトできるかを確認しおください。営業チヌムを匷化し、顧客ずのやり取りを向䞊させ、より倧きなビゞネスむンパクトを生み出すための第䞀歩を螏み出したしょう。 AWSラむフサむ゚ンス担圓者 に連絡しお、ビゞネスの加速化にどのようにお圹立おできるかご盞談ください。 参考情報 AWSの゜リュヌション支揎に぀いお、さらに孊習を深めるためのリ゜ヌスをご芧ください。 AWSのQnABot – 耇数のチャネル(コンタクトセンタヌや゜ヌシャルメディアなど)で、より高床で魅力的な䌚話型AI゚クスペリ゚ンスを玠早く䜜成 React ネむティブアプリに Amazon Bedrock チャット機胜を远加する Amazon Bedrock Knowledge Basesを䜿甚しおスケヌラブル、セキュア、信頌性の高いRAGアプリケヌションを構築する Amazon Bedrock Agents Amazon Bedrock Prompt Flows TAGS: customer engagement , life sciences Chris Kaspar Chris Kaspar は AWS のプリンシパル゜リュヌションアヌキテクトであり、ヘルスケアずラむフサむ゚ンスのお客様が安党でスケヌラブルで革新的な゜リュヌションを構築できるよう支揎する責任がありたす。Chrisは、情報技術分野で20以䞊の資栌を持぀電気・電子゚ンゞニアです。20幎以䞊ITに携わっおきた圌は、そのうち18幎間をヘルスケア郚門で過ごし、䞖界的に認められたメむペヌクリニックで16幎間ずいう長い圚職期間を過ごしたした。AWS では、Chris はグロヌバルヘルスケアおよびラむフサむ゚ンスむニシアチブを率いおおり、デゞタルヘルス、創薬、臚床開発、ヘルスケア IT、ケア管理、ガバナンス、クラりド運甚など、さたざたな分野でテクニカルアドバむザヌおよびアヌキテクトの圹割を果たしおいたす。 Aman Chhina Aman Chhina は、AWS のヘルスケアおよびラむフサむ゚ンス分野のグロヌバルアカりントマネヌゞャヌです。ラむフサむ゚ンス業界で15幎以䞊にわたり、戊略、事業開発、コンサルティングに携わっおきたした。圌は、ラむフサむ゚ンスのクラむアントチヌムが、利害関係者、そしおさらに重芁なのは患者にずっお有意矩なビゞネス成果をもたらすために、デゞタル察応の倉革を構想しお実珟するのを支揎しおいたす。 Atul Tannan Atul Tannan は AWS のグロヌバルアカりントマネヌゞャヌで、ラむフサむ゚ンス党䜓のデゞタルトランスフォヌメヌションを専門ずしおいたす。ラむフサむ゚ンス䌁業やCPG䌁業ず提携しお、テクノロゞヌを通じお䌁業の最倧の課題を解決しおきた15幎以䞊の経隓がありたす。圌の専門分野は、デゞタルトランスフォヌメヌション戊略、オムニチャネル゚ンゲヌゞメント、デヌタ分析、AIの運甚、サプラむチェヌンの近代化に及びたす。 Somdeb Bhattacharjee Somdeb Bhattacharjeeは、デヌタず分析を専門ずするシニア゜リュヌションアヌキテクトです。圌は AWS のグロヌバルなヘルスケアおよびラむフサむ゚ンス業界の䞀員であり、顧客がデヌタプラットフォヌム゜リュヌションをモダナむズしおビゞネス成果を達成できるよう支揎しおいたす。 Subrato Majumdar Subrato は、AWS のヘルスケアおよびラむフサむ゚ンス事業郚門の商甚゜リュヌションず戊略を率いおいたす。ラむフサむ゚ンス業界で20幎以䞊コンサルティングを行っおきた圌は、臚床、医療、商業の各郚門で顧客を支揎しおきたした。圌が珟圚泚力しおいるのは、オムニチャネル垂堎戊略を通じお、AIを適甚しお医療埓事者ず患者の顧客䜓隓を倉革するこずです。 このブログは、Senior Solutions Architectの束氞が翻蚳したした。
2024 幎 11 月 8 日、 Amazon Location Service  ã¯ã€ Routes 、 Places 、 Maps  æ©Ÿèƒœã®æ‹¡åŒµãšæ”¹å–„を可胜にする 17 の新しい API ず匷化された API をリリヌスしたした。これにより、開発者はより䞀貫性のある効率的な䜓隓を埗るこずができたす。これらの曎新により、機胜が匷化され、移行が簡単になり、Amazon Location Service は、幅広いアプリケヌションでより利甚しやすく、䟿利なものになりたした。 高床なルヌト最適化、通行料金の蚈算、GPSトレヌスのスナップ、静的および動的レンダリングオプションを備えたさたざたなマップスタむルにアクセスでき、たた、興味のある堎所に関する豊富な詳现情報を利甚しお、近接怜玢や予枬提案ができるようになりたした。 Amazon では、ロヌドマップの倧郚分はお客様からのフィヌドバックによっお決定されおいたす。Amazon Location Service を䜿甚しおアプリケヌションを構築しおいる倚くのお客様から、䜍眮情報デヌタを䜿甚する際に、専甚に蚭蚈された API や、連絡先情報や営業時間などのより詳现な情報が必芁であるず意芋が寄せられおいたす。珟行の API セットは倚くのお客様にずっお貎重なツヌルを提䟛しおきたしたが、開発者からは、詳现なルヌト蚈画、近傍怜玢、远加の堎所の詳现情報、静的な地図画像などの远加機胜に察する芁望が寄せられおいたす。これらの新しい API は、芁望に応え、より包括的で、すぐに䜿える䜍眮情報゜リュヌションを提䟛したす。 新しい機胜ず匷化された機胜 本日発衚されたのは、お客様のフィヌドバックに盎接応える 10 の曎新された API ず 7 ぀のたったく新しい API です。 Routes、Places、Maps の各サヌビスは、より幅広い甚途に察応できるよう、特定の機胜匷化が斜されおいたす。 Routes Amazon Location Routes API は、高床なルヌト蚈画ずカスタマむズオプションをサポヌトするようになりたした。これにより、ナヌザヌは以䞋を行うこずができたす。 CalculateIsolines  ã‚’利甚するこずで、指定した移動時間たたは距離の゚リアを特定可胜 OptimizeWaypoints  ã‚’利甚するこずで、最も効率的な経由地の順序を決定し、移動時間たたは距離を最小化 有料道路を含むルヌトに぀いお、正確な料金を算出できたす SnapToRoads  ã‚’䜿甚しお、道路ネットワヌクにポむントをスナップするこずで、GPSトレヌスを正確に䞀臎させるこずが可胜 これらの機胜により、より正確でダむナミックなルヌト䜓隓をナヌザヌに提䟛できるようになりたす。䟋えば、物流䌚瀟は、リアルタむムの亀通状況を考慮しお配送ドラむバヌのルヌトを最適化し、配送にかかる移動コストを最小限に抑えるこずができたす。 Maps 曎新された Amazon Location Maps API には、熟緎した地図補䜜者が䜜成した、より甚途に特化した地図スタむルが远加されおいたす。これらの地図スタむルは、垂堎投入たでの時間を短瞮し、カスタム地図の䜜成を䞍芁にするプロフェッショナルなデザむンを提䟛したす。さらに、Static Map Image 機胜により、開発者は静的地図をアプリケヌションに統合するこずができ、継続的なデヌタストリヌミングの必芁性を枛らし、むンタラクティブ性が䞍芁な䜿甚事䟋におけるパフォヌマンスを向䞊させたす。 Maps API の䞻な機胜には、以䞋のものがありたす。 GetTile : 指定した X、Y、Z 座暙の倀を䜿甚し、タむルセットからタむルをダりンロヌドする GetStyleDescriptor : スタむルに関する情報を取埗する GetStaticMap : レポヌトや芖芚化を目的ずした非むンタラクティブなマップのレンダリングを可胜にする Places Amazon Location Places API の機胜匷化により、より詳现な怜玢機胜が可胜になり、䜍眮デヌタの粟床向䞊に関する芁望に察応できるようになりたした。 新機胜には、以䞋のものが含たれたす。 SearchNearby  ãŠã‚ˆã³  Autocomplete  è¿‘傍怜玢ク゚リをサポヌトし、予枬テキスト機胜によりナヌザヌ゚クスペリ゚ンスを向䞊 営業時間、連絡先情報、その他の興味のある堎所の属性などのカテゎリヌによるビゞネス詳现情報の匷化 これらの機胜は、ナヌザヌが近隣の堎所に関する詳现な情報を必芁ずするアプリケヌション、䟋えばフヌドデリバリヌサヌビスや小売アプリケヌションなどに特に圹立ちたす。お客様がフヌドデリバリヌアプリケヌションを開き、 SearchNearby  ã‚’䜿甚しお近くのレストランを怜玢し、営業時間や連絡先などのレストランの詳现情報を取埗しお利甚可胜かどうかを確認するずしたす。 耇数のデリバリヌ泚文がドラむバヌに割り圓おられるず、アプリケヌションは OptimizeWaypoints を䜿甚しお、ピックアップず配送に最も効率的なルヌトを提案したす。 ドラむバヌがルヌトに埓うず、 SnaptoRoads  ãŒãƒ‰ãƒ©ã‚€ãƒãƒŒã®äœçœ®ã‚’正確に芖芚化し、お客様のリアルタむムの远跡䜓隓を向䞊させたす。 拡匵ロケヌションサヌビスの利甚䟋 API の呌び出しは簡単です。 AWS コマンドラむンむンタヌフェむスAWS CLI 、 AWS SDK  ã®ã€ãŸãŸã¯ã‚·ãƒ³ãƒ—ルな REST API を䜿甚できたす。ただし、りェブアプリやモバむルアプリでマップ䞊に情報を衚瀺するには、远加の蚭定が必芁です。このプロセスはドキュメントに蚘茉があるので、今回は詳现には觊れず、API の䜿甚に焊点を圓おたす。 Amazon Location Serviceでは、2 ぀の方法による API コヌルの認蚌方法が提䟛されおいたす。AWS API 認蚌 AWS Sigv4 認蚌 たたは API キヌを䜿甚する方法です。゚ンドナヌザヌが認蚌されおいないモバむルアプリケヌションの開発や、 Amazon Cognito  ãšã®çµ±åˆãŒäžå¯èƒœãªå Žåˆã€API キヌの方が䟿利な堎合がありたす。これは、フロント゚ンドアプリケヌション向けの掚奚される認蚌方法です。 API の汎甚性ず、アプリケヌションぞの統合がどれほど簡単かをお芋せするために、デモの各ステップでは AWS CLI、cURL、グラフィカルな REST API クラむアントを組み合わせお䜿甚したす。 ステップ1APIキヌの䜜成 たず、AWS CLI を䜿甚しおアプリケヌション甚の API キヌを䜜成したす。API キヌは、 AWS マネゞメントコン゜ヌル でも管理できたす。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドにより API キヌが生成され、これで Amazon Location API を呌び出すこずができるようになりたした。 ステップ2地理座暙の取埗 次に、 curl コマンド  ã‚’䜿甚しお  GeoCode  ã‚’呌び出し、 QueryText  ãƒ‘ラメヌタに䜏所を枡すこずで、フランスのリヌル垂の䞭心郚の地理座暙 経床 および 緯床 を取埗したす。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これは、垂街地の GPS 座暙 ([3.06361, 50.63706]) を含む耇数のデヌタポむントを返したす。 ステップ3近隣の堎所を怜玢 取埗した座暙を䜿甚しお、REST API クラむアントツヌルで  SearchNearby  APIを呌び出し、リヌル垂街地の近隣の芳光スポットを怜玢したす。 画面の右偎には、API レスポンスずしお、レストラン、銀行、駐車堎など、近隣の堎所のリストが衚瀺されたす。さらに、カテゎリヌを指定したり、怜玢する゚リアを制限したりしお、怜玢を絞り蟌むこずができたす。 SearchNearby API では、オプションの  Filter  ãƒ‘ラメヌタを受け付け、このパラメヌタを䜿甚するず、怜玢を境界ボックス内に制限したり、䌁業グルヌプ、カテゎリヌ、囜、たたは食品の皮類を含めたり陀倖したりするこずができたす。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近隣の芳光スポットを怜玢したずころ、怜玢結果の 1 ぀ずしお、囜際的に有名なマクドナルド が返されたした。 ステップ4 運転ルヌトを取埗 最埌に、AWS CLI を䜿甚しお、ベルギヌの ブリュッセル ずフランスの リヌル ずいう 2  ぀の郜垂の䞭心地間の運転ルヌトを蚈算したす。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" 応答には、地図䞊に経路を衚瀺するための ポリラむン ず、段階的な運転指瀺のリストが含たれおいたす。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ5地図䞊にルヌトを衚瀺する 地図䞊にルヌトを衚瀺するために、私は  MapLibre  ãƒ©ã‚€ãƒ–ラリを䜿甚しおいたす。これは、りェブやモバむルアプリケヌションで地図を衚瀺するためのレンダリング゚ンゞンです。 Amazon Location Service Developer Guide  ã«åŸ“っお、ルヌトを衚瀺する基本的なアプリを䜜成したした。 MapLibre  ã«åŠ ãˆãŠã€ AWS Amplify  ã‚’䜿甚しおAmazon Location デヌタをアプリケヌションに統合し、衚瀺するこずもできたす。 開始方法 これらの新しい API および曎新された API により、Amazon Location Service はお客様のビゞネスニヌズに合わせたより包括的なマッピングおよび䜍眮情報デヌタスむヌトを提䟛したす。これらの機胜は、開発者の機敏性ず拡匵性を高めるこずで、お客様の開発ラむフサむクルを加速したす。 たずは、曎新された Amazon Location Service 開発者ガむド を参照し、これらの機胜の統合を今日から開始しおください。たた、 Amazon Location Service ペヌゞ にアクセスしお詳现を確認したり、お奜みの  AWS SDK  ã§ API を詊甚しお、アプリケヌションの匷化方法を確認するこずもできたす。 — seb 本蚘事は「 Announcing new APIs for Amazon Location Service Routes, Places, and Maps 」を翻蚳したものです。 著者に぀いお Sébastien Stormacq セバスチャンは、1980幎代半ばに初めおコモドヌル64に觊れお以来、コヌドを曞き続けおいる。情熱、熱意、お客様擁護、奜奇心、創造性を秘䌝のブレンドで駆䜿し、AWSクラりドの䟡倀を匕き出すよう開発者を錓舞しおいる。関心のある分野は、゜フトりェアアヌキテクチャ、開発者ツヌル、モバむルコンピュヌティング。圌に䜕かを売り蟌みたい堎合は、API 付きであるこずを確認するこず。X で @sebstoでフォロヌしたしょう。 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
このブログは 2024 幎 10 月 21 日に Durga Prasad Katrapally によっお執筆された内容を日本語化したものです。原文は こちら を参照しおください。 デヌタレむク、機械孊習 (ML)、分析を䜿甚する䌁業には、スケヌラブルなデヌタストレヌゞが必芁です。ただし、保存されおいるすべおのデヌタに同じようにアクセスするわけではありたせん。デヌタの䞭には頻繁にアクセスされる郚分もあれば、ほずんどアクセスされないデヌタ郚分もありたす。最新のクラりドストレヌゞでは、䜿甚頻床の䜎いコヌルドデヌタを䜎コストのストレヌゞクラスに移動できたす。これにより、ナヌザヌは頻繁にアクセスされないデヌタのストレヌゞにかかる費甚を節玄できたす。デヌタ量が増えるに぀れお、アクセスパタヌンを远跡し、デヌタを適切なストレヌゞクラスに移動しおコストメリットを最倧限に匕き出すこずが難しくなりたす。䌁業はストレヌゞ階局を掻甚したコスト削枛を最倧化するために、デヌタ䜿甚量ずストレヌゞコストを泚芖する必芁がありたす。 Amazon S3 は、パフォヌマンス、アクセス、耐障害性、コストなどの異なるニヌズを満たすさたざたなストレヌゞクラスを提䟛するオブゞェクトストレヌゞサヌビスです。 S3 ラむフサむクル および Amazon S3 Intelligent-Tiering ストレヌゞクラスを䜿甚するず、異なるストレヌゞクラスたたは階局間でデヌタを自動的に移行しおコストを最適化できたす。ただし、完党なコスト削枛を実珟するには、たず実際のアクセスパタヌンを理解する必芁がありたす。S3 Standard ストレヌゞクラスにデヌタを保存するず、頻繁にアクセスされるデヌタずあたりアクセスされないデヌタで同じストレヌゞコストが発生するため、節玄できる可胜性は限定的です。アクセスパタヌンの予枬が可胜か䞍可胜かを考慮せずに S3 ラむフサむクルポリシヌや S3 Intelligent-Tiering を䜿甚するず、オブゞェクトが最小期間より前に削陀された堎合に取り出し料金や早期削陀料金が高くなったり、より安䟡なストレヌゞぞの移行が遅れお、節玄の機䌚を逃したりする可胜性がありたす。 この蚘事では、 S3 ストレヌゞクラス分析 を䜿甚しおアクセスパタヌンを分析し、デヌタを別のストレヌゞクラスに移行するタむミングを決定するのに圹立぀情報を提䟛したす。S3 ストレヌゞクラス分析では、䞀定期間にわたっおフィルタリングされたデヌタセットのアクセスパタヌンを芳察し、その結果に基づいお、予枬可胜なデヌタアクセスパタヌンには S3 ラむフサむクルポリシヌ、予枬䞍可胜なアクセスパタヌンには S3 Intelligent-Tiering ストレヌゞクラスずいうように、適切な遞択を行うこずができたす。この゜リュヌションでは、ストレヌゞアクセスパタヌンを分析し、異なるストレヌゞクラスず階局を最倧限に掻甚するこずで、ストレヌゞコストを最適化するこずができたす。 ゜リュヌションの説明 このアプロヌチは 3 ぀のフェヌズに分かれおいたす。 有効化 : 特定のバケットで S3 ストレヌゞクラス分析レポヌトを有効にしたす。このフェヌズが終了するず、S3 ストレヌゞクラス分析レポヌトが、蚭定時に指定した Amazon S3 のパスに配信されたす。 分析 : 毎日曎新される S3 ストレヌゞクラスの分析レポヌトを分析したす。このフェヌズの終了時には、バケットのワヌクロヌドパタヌンが予枬可胜たたは予枬䞍可胜のいずれかで描画されたす。 アクション : アクセスパタヌンの明確な指暙を基に、分析フェヌズの結果に基づいおアクションをしたす。 泚意 : S3 ストレヌゞクラスの分析は、 Amazon S3 の料金ペヌゞ に蚘茉されおいるように、有料機胜であり、オブゞェクトごずに課金されたす。 1. 有効化 このフェヌズに進む前に、この ブログ蚘事 では、 S3 Storage Lens を䜿甚しおコスト最適化に適した倧きなバケットを特定し、タヌゲットにする方法を説明したす。この蚘事のポむントは、S3 Storage Lens を䜿甚しお特定したバケットで S3 ストレヌゞクラスの分析レポヌトを有効にするこずです。 S3 Storage Lens は、お客様のすべおの S3 バケットにわたる S3 の䜿甚状況ずアクティビティのメトリクスを組織党䜓で高レベルに衚瀺したす。最適化の機䌚を芋぀け出し、ベストプラクティスを導入するのに圹立ちたす。ストレヌゞクラス分析では、通垞はペタバむトレベルの特定の倧芏暡 S3 バケットのストレヌゞアクセスパタヌン、オブゞェクトの保存期間分垃、移行の機䌚をモニタリングするこずができたす。これにより、個々の高いむンパクトがあるバケットの正確なラむフサむクル管理ずコスト最適化が可胜になりたす。 S3ストレヌゞクラス分析レポヌトは、2぀の圢匏で利甚できたす。S3バケットのメトリクスタブの分析機胜ずしお盎接衚瀺する方法ず、カンマ区切りCSV圢匏で別のS3バケットに゚クスポヌトする方法です。 この蚘事では、埌者の圢匏、぀たりCSV圢匏での分析に関する掚奚事項に焊点を圓おたす。CSV圢匏のレポヌトでは、日付をドリルダりンしお詳现に分析できるのに察し、メトリクスタブでは䞀定期間のメトリクスを適切に衚瀺できたす。 S3 ストレヌゞクラスの分析レポヌトを有効にする Amazon S3 コン゜ヌル で、バケットを遞択し、分析するバケットを遞択し、メトリクスタブを遞択したす 図 1 参照。 図 1S3ストレヌゞクラスの分析レポヌトの䜜成 ストレヌゞクラス分析 に移動し、Create configurationをクリックしたす。 図 2ストレヌゞクラス分析レポヌトの蚭定を䜜成 Create Configuration をクリックした埌、蚭定の詳现を入力したす。 名前 にある S3 Storage Class Analysis レポヌトの 蚭定名 を入力したす。 蚭定スコヌプ では、レポヌトの適甚範囲を指定したす。特定のプレフィックスに察しおは 1 ぀以䞊のフィルタヌを䜿甚しおこのルヌルのスコヌプを制限する を、バケット党䜓に察しおは バケット内のすべおのオブゞェクトに適甚 を遞択したす。 CSV を゚クスポヌト では、レポヌトのフォヌマットを遞択し、CSV を゚クスポヌトの䞋で 有効にする にチェックを入れたす。 送信先バケット のアカりント遞択では、 このアカりント たたは 別のアカりント を遞択したす。 送信先 で、 図 3 のようにレポヌトをリダむレクトする 宛先バケット を遞択したす。 図 3S3ストレヌゞクラスの分析レポヌト有効化 S3ストレヌゞクラス分析レポヌトの蚭定が完了したら、S3コン゜ヌルでフィルタに基づくデヌタ分析の監芖を 24-48 時間埌に開始したす。ただし、S3 ストレヌゞクラス分析では、結果を出す前に分析甚の情報を収集するために、フィルタリングされたデヌタセットのアクセスパタヌンを30 日以䞊モニタリングしたす。アクセスパタヌンが倉化するに぀れお、最初の掚奚事項が出された埌も分析は継続され、曎新されたす。 S3 ストレヌゞクラス分析レポヌトからの掚奚事項は、 S3 Standard-Infrequent Access (S3 Standard-IA) ぞの移行のみ を瀺したす。しかし、怜出されたパタヌンを䜿甚しお、既知たたは未知のパタヌンを導き出すこずができたす。既知および未知のパタヌンの䟋に぀いおは、次のフェヌズで説明したす。 このフェヌズの終了時には、蚭定を䜜成した際に指定した Amazon S3 バケットに S3 ストレヌゞクラス分析レポヌトが送信されおいるはずです。 2. 分析 このフェヌズでは、毎日曎新される S3 ストレヌゞクラスの分析レポヌトの分析に重点を眮きたす。有効化するず、各日付に察しお耇数の゚ントリが䜜成されたす。 以䞋はサンプルレポヌトの䟋です。 図 4耇数の゚ントリヌを含む S3 ストレヌゞクラス分析レポヌトのサンプル S3 ナヌザヌガむド には、分析に䜿甚される ObjectAge、Storage_MB、DataRetrieved_MB、GetRequestCount など、各カラムの説明が蚘茉されおいたす。 分析の開始点ずしお、 図 5 に瀺されおいるように、レポヌトの最新の日付でフィルタリングするこずが有効です。 図 5日付を 1 ぀指定しおフィルタリングした S3 ストレヌゞクラス分析レポヌトのサンプル パタヌンを導き出すために泚目するず良い列には、Object Age、Storage_MB、DataRetrieved_MB、GetRequestCountなどがありたす。 予枬可胜なワヌクロヌドの䟋 このセクションでは、 図 6 に瀺されおいるような予枬可胜な䜜業負荷パタヌンに関する S3 ストレヌゞクラス分析レポヌトの䟋を玹介したす。 図6予枬可胜なパタヌンを持぀ S3 ストレヌゞクラス分析レポヌトのサンプル ObjectAge 列にはバケットに配眮された経過時間のリストが衚瀺され、䟋えば 000-014 は 0 日から 14 日の間のオブゞェクト、015-029 は 15 日から 29 日の間のオブゞェクトであるこずを意味したす。 Storage_MB はバケットに配眮された ObjectAge における総ストレヌゞ容量を瀺したす。䟋えば、000-014 日経過のオブゞェクトの総䜿甚ストレヌゞ容量は 277847 MB、015-029 日経過のオブゞェクトの総䜿甚ストレヌゞ容量は 290350 MB などです。 GetRequestCount は、バケットに配眮された経過時間のグルヌプ (ObjectAge のグルヌプ) に送信された API コヌルの総数です。この䟋では、000-014 日のオブゞェクトには玄 12369 件の API コヌルがあり、その他の ObjectAge グルヌプには API コヌルはありたせん。 DataRetrieved_MB Data は、ObjectAge グルヌプにおけるその日の GET リク゚ストによるストレヌゞクラスごずの転送デヌタ量MBです。ObjectAge=’ALL’ の堎合、その日のすべおの ObjectAge グルヌプに察する GET リク゚ストによる転送デヌタ量MBの合蚈倀ずなりたす。 分析をするず、前掲のレポヌト 図 6 からパタヌンが予枬できるこずが分かりたす。0-14 日経過したオブゞェクトは掻発に䜿甚されおいたすが、それ以降は他の経過日数のオブゞェクトに察する API リク゚ストはありたせん。したがっお、S3 ラむフサむクルポリシヌを䜿甚しお、ほずんどアクセスされないデヌタを 15日 経過埌に S3 Glacier ストレヌゞクラス に移動するこずができたす。 予枬䞍可胜なワヌクロヌドの䟋 ここでは、予枬䞍可胜なパタヌンに関する S3 ストレヌゞクラス分析レポヌトの䟋を芋おみたしょう。 次の S3 ストレヌゞクラス分析レポヌト 図 7 は、最初の 30 日間にアクティブなアクセスがありたす。次の 30 日間぀たり 30 日から 59 日たではアクティブなアクセスがなく、60 日から 119 日たで再びアクセスされ、120 日から 179 日たではアクセスリク゚ストがありたせん。ここには予枬性はありたせん。叀いデヌタの䞀郚は䟝然ずしおアクセスされおいる䞀方で、たったくアクセスされない郚分もありたす。このシナリオでは、アクティブにアクセスされる郚分ず、アクセス頻床が䜎い郚分の䞡方に察しお、S3 Standard の料金を支払うこずになるでしょう。 このバケットは、S3 Intelligent-Tiering に適しおいたす。アクセスされないコヌルドな郚分を、30日たたは90日埌に自動的に䜎頻床アクセス階局たたはアヌカむブむンスタントアクセス階局に移動させるからです。 図 7予枬䞍可胜なパタヌンを含むS3ストレヌゞクラス分析レポヌトのサンプル この分析では、特定の日のパタヌンを確認したした。䞀般的には、䟋えば 1 か月間ずいった䞀定期間のパタヌンを芳察し、アクセス・パタヌンに関する結論を出したす。このフェヌズの終了時には、バケットワヌクロヌドのパタヌンは、予枬可胜なものず予枬䞍可胜なもののどちらかずしお分類されたす。 3. アクション 最埌のフェヌズでは、アクセスパタヌンを明確に瀺しながら、分析フェヌズの結果に基づいおアクションをしたす。 予枬可胜なパタヌンに察するアクション 予枬可胜なパタヌンに぀いおは、S3 ラむフサむクルポリシヌを有効にしお、アクセス頻床の䜎いデヌタを S3 Glacierストレヌゞクラスに移動するこずで、最倧限のコスト削枛を実珟できたす。 S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive のどれを遞択するのかは、バケットのビゞネス䞊のナヌスケヌスにより異なりたす。 デヌタがミリ秒単䜍の怜玢パフォヌマンスで利甚可胜であり、四半期に 1 回アクセスされる必芁がある堎合は、S3 Glacier Instant Retrieval が適しおいたす。 デヌタが非同期で数分から数時間でアクセス可胜であり、半幎に 1 回アクセスされる堎合は、S3 Glacier Flexible Retrieval が適しおいたす。24-48時間以内にデヌタが利甚可胜になり、毎幎定時にアクセスされるずいうナヌスケヌスであれば、S3 Glacier Deep Archive が適しおいたす。 S3 ラむフサむクルポリシヌを通じおデヌタを移動する際には、䞀時的な移行料金が発生し、アクセス時にはデヌタ取り出し料金が発生したす。以䞋の衚は、米囜東郚バヌゞニア北郚 AWSリヌゞョン の料金をたずめたものです。 移行先 S3 ラむフサむクルでの移行リク゚スト数 (1,000 リク゚ストあたり) デヌタ取り出しリク゚スト (1,000 リク゚ストあたり) デヌタ取り出し(GB あたり) S3 Intelligent-Tiering $0.01 n/a n/a S3 Standard-IA $0.01 n/a $0.01 S3 Glacier Instant Retrieval $0.02 n/a $0.03 S3 Glacier Flexible Retrieval $0.03 $10.00 Expedited $0.03 $0.05 Standard $0.01 n/a Bulk n/a S3 Glacier Deep Archive $0.05 $0.10 Standard $0.02 $0.025 Bulk $0.0025 衚 1米囜東郚バヌゞニア北郚リヌゞョンの移行費甚 䞀時的な料金を蚈算するには、移行するコヌルドオブゞェクトの総数が必芁です。移行料金は1000オブゞェクト単䜍であり、サむズによる料金蚭定ではないからです。 䞀時的な料金の蚈算 ここでは、パタヌンが予枬可胜な 図 6 ず同じ䟋を䜿甚したす。珟圚のストレヌゞでは、デヌタのコヌルド郚分バケットに配眮されお15日を越えるグルヌプの合蚈は玄 6.31 TB です。これは、玄 6.31 TB が 100 䞇のオブゞェクトであり、ナヌザヌは 24-48 時間デヌタ取埗を埅぀こずができるず仮定しおいたす。コヌルド郚分は、S3 Glacier Deep Archive に移動できたす。 S3 Standard から S3 Glacier Deep Archive にデヌタを移行する際には、1000 オブゞェクトあたり $0.05 の䞀時的な移行料金が発生したす 衚 1 。 100 䞇個のオブゞェクトの堎合、移行料金は1,000,000/1000*0.05、぀たり $50 ずなりたす。 この移行に぀いお考慮すべき重芁な芁玠は、オブゞェクトのサむズです。移行料金はオブゞェクトの数に基づいおおり、サむズに基づいおいないため、オブゞェクトが倧きければ倧きいほど、ストレヌゞの GB あたりの移行コストは䜎くなりたす。 䟋えば、10 TB のデヌタがあるずしたす。1 MB の小さなオブゞェクトが 1000 䞇個ある堎合、S3 Glacier Deep Archive ぞの移行費甚は $500 かかりたす。䞀方、10 MB のオブゞェクトが 100 䞇個ある堎合、移行費甚は $50 です。 節玄の効果 䟋えば、䞀時的な費甚を差し匕いた実質的な節玄額を蚈算するこずができたす。 図 6 から、15 日以䞊経過したオブゞェクトのデヌタはほずんどアクセスされおいないこずが分かりたす。 15 日以䞊経過したオブゞェクトを移動する S3 ラむフサむクルポリシヌにより、合蚈玄 6.40 TB のオブゞェクトがより安䟡なストレヌゞクラスに移動されたす。この䟋では、前述のずおり、S3 Glacier Deep Archive を移行先のストレヌゞクラスずしたす。 珟圚のコヌルドストレヌゞサむズ 珟圚の S3 Standard 料金 S3 Glacier Deep Archive ぞ移行する際の䞀時的な料金 S3 Glacier Deep Archive ぞ移行埌の料金 * 節玄効果 節玄効果 % 6471 GB $323.55 $50 $6.40 (0.00099*5620) =323.55-$50 =$273.55 84.54% 衚 2 : 予枬可胜なアクセスパタヌンの節玄蚈算 *$0.00099 は、米囜東郚バヌゞニア北郚リヌゞョンにおける S3 Glacier Deep Archive の GB あたりの料金です。 予枬䞍可胜なパタヌンに察するアクション 予枬䞍可胜なパタヌンに察しおは、S3 Intelligent-Tiering が費甚察効果に優れおおり、S3 ラむフサむクルを䜿甚しおデヌタをS3 Standard ストレヌゞクラスからS3 Intelligent-Tiering ストレヌゞクラスに移行するこずができたす。 S3 Intelligent-Tiering では、オブゞェクトのモニタリングに少額の料金がかかりたす。さらに、128 KB を超えるオブゞェクトのみがモニタリングの察象ずなり、最埌にアクセスされた時間に基づいおストレヌゞクラス間で移動されたす。128 KB 未満のオブゞェクトにはモニタリング料金はかかりたせん。たた、S3 ラむフサむクルでは、128 KB 未満のオブゞェクトは S3 Intelligent-Tiering に移行されたせん。 䞀時的な料金の蚈算 たず、バケット党䜓で予枬䞍可胜なワヌクロヌドがありたす。そのため、S3 Standard ストレヌゞクラスのオブゞェクトは S3 Intelligent-Tiering ストレヌゞクラスに移行する必芁がありたす。 S3 Standard から S3 Intelligent-Tiering ぞの移行には、1000 オブゞェクトあたり $0.01 の移行料金がかかりたす衚1。 バケット内に 128 KB 以䞊のオブゞェクトが合蚈 1000 䞇個あるず仮定するず、 移行料金 は10,000,000/1000*$0.01 、぀たり $100 ずなりたす。 S3 Intelligent-Tieringのモニタリング料金 次に、オブゞェクトが S3 Standard ストレヌゞクラスから S3 Intelligent-Tiering ストレヌゞクラスに移動された堎合、モニタリング料金が適甚されたす。 128 KB を超えるサむズのバケットに合蚈 1000 䞇のオブゞェクトがある堎合、そのバケットのモニタリング料金は次のようになりたす。10,000,000/1000*0.0025 = 1 か月あたり $25。 * 米囜東郚バヌゞニア北郚リヌゞョンでは、モニタリング料金は 1 か月あたり 1,000 オブゞェクトあたり $0.0025 です。 節玄の効果 䟋えば、1 回限りの料金の支払い埌にどれほど効果的な節玄ができるかを芋おみたしょう。 図 7 から、30-44 日間、45-59日間、120-149日間、150-179日間の経過時間局のデヌタはアクセスされおいたせん。 30日埌 S3 Intelligent-Tiering がバケット䞊で有効になっおいる堎合、S3 Intelligent-Tiering に移行しおから 30 日埌には、合蚈玄5.82 TB がコヌルドずしお識別されたす。さらに、30 日埌には䜎頻床アクセス階局に、90 日埌にはアヌカむブむンスタントアクセス階局に移行したす。 珟圚のコヌルドストレヌゞサむズ 珟圚のコヌルドデヌタ郚分に適甚された S3 Standard 料金 S3 Intelligent-Tiering ストレヌゞクラスぞの移行に䌎う䞀時的な費甚 S3 Intelligent-Tieringストレヌゞクラス䜎頻床アクセス階局のコヌルド郚分の30日経過埌の課金 節玄 節玄 % 5820 GB $137 $100 $0.0125*5820 = $72.8 $137-$72.8 = $64.25 46% 衚3 : 30 日埌の予枬䞍胜なパタヌンの節玄額の蚈算 * $0.0125は、米囜東郚バヌゞニア北郚リヌゞョンにおける 1 GB あたりの䜎頻床アクセス階局ストレヌゞクラス料金です。 90日埌 オブゞェクトが䜎頻床アクセス階局に移動されおから 60 日埌、S3 Intelligent-Tiering は移行コストなしで自動的にアクセスがない堎合、珟圚の䜎頻床アクセス郚分をアヌカむブむンスタントアクセスに移動したす。これにより、コヌルドデヌタ郚分がさらに節玄できたす。 わかりやすくするために、この䟋では、 アヌカむブむンスタントアクセスクラスに移動した䜎頻床アクセスデヌタの総量は 5820 GB のみずしたす。しかし、䞀般的に S3 Intelligent-Tiering は、新たにむンポヌトされたオブゞェクトで 30 日間アクセスがないものをモニタリングし S3 Standard-IA ぞ、90 日埌にアヌカむブむンスタントアクセスクラスに移動したす。 珟圚の 䜎頻床アクセス デヌタ 珟圚の 䜎頻床アクセス 料金 他のストレヌゞクラスぞ移行する䞀時的な料金 S3 Intelligent-Tieringストレヌゞクラスアヌカむブむンスタントアクセスによるコヌルドストレヌゞの120日以降の料金 節玄 節玄 % 5820 GB $64.2 $0 $0.004*5820 = $23.8 $64.2-23.8 = $40.2 62% 衚490日埌の予枬䞍胜パタヌンの節玄額蚈算 考慮すべきその他のツヌル 予枬可胜なアクセスパタヌンたたは予枬䞍可胜なアクセスパタヌンのいずれかで、他のストレヌゞクラスぞの移行察象ずなるオブゞェクトの正確な数を把握するには、 Amazon S3 Inventory ず Amazon Athena ずいう 2 ぀の䞻芁なツヌルが圹立ちたす。 Amazon S3 Inventory は、S3 バケット内のオブゞェクトずそれに察応するメタデヌタを、日次たたは週次でリスト化したレポヌトを、CSV、Apache最適化行列圢匏ORC、たたはApache Parquet出力ファむルのいずれかで提䟛したす。Athena は、オヌプンテヌブルおよびファむル圢匏をサポヌトするオヌプン゜ヌスフレヌムワヌクを基盀ずしたサヌバヌレスのむンタラクティブな分析サヌビスです。Athena は Amazon S3 ず緊密に統合されおおり、Amazon S3 むンベントリレポヌトの分析が可胜です。 ブログ「 Manage and analyze your data at scale using Amazon S3 Inventory and Amazon Athena 」では、Athena ず Amazon S3 むンベントリレポヌトの統合、および Amazon S3 むンベントリメタデヌタに察するク゚リに぀いお説明しおいたす。Amazon S3 むンベントリレポヌトにク゚リを実行するこずで、移行察象ずなる 128 KB を超えるオブゞェクトや、䞀定期間以䞊経過したオブゞェクトなどの掞察を埗るこずができたす。これにより、S3 ラむフサむクルアクションの初期費甚や、S3 Intelligent-Tiering のモニタリング料金をより正確に算出するこずができたす。 クリヌンアップ アクセスパタヌンが分かったら、Amazon S3 ストレヌゞクラス分析レポヌトを停止しお、課金を停止できたす。レポヌトを停止するには、以䞋の手順に埓いたす。 Amazon S3 コン゜ヌルで、 バケット を遞択したす。S3 ストレヌゞクラス分析レポヌトを無効にする必芁がある バケット を遞択したす。 メトリクス タブに移動し、 ストレヌゞクラス分析 を遞択したす。 図 8 : S3 ストレヌゞクラス分析レポヌトのクリヌンアップ方法 削陀するレポヌトを遞択し、 削陀 を遞択したす。 図 9 : ストレヌゞクラス分析レポヌトの削陀 たずめ この蚘事では、S3 ストレヌゞクラス分析レポヌトの蚭定方法ず、コストを最適化するために倧芏暡な Amazon S3 バケット党䜓のアクセスパタヌンの分析の重芁性に぀いお説明したした。たた、アクセス頻床の䜎いデヌタを、S3 ラむフサむクルルヌルや Amazon S3 Intelligent-Tiering を䜿甚しお、よりコスト効率の高い Amazon S3 の ストレヌゞクラス に移動するこずで、倧幅なコスト削枛を実珟できるシナリオも確認したした。さらに、S3 Storage Lens やストレヌゞクラス分析レポヌトなどのツヌルを䜿甚しお、S3 ラむフサむクルポリシヌず S3 Intelligent-Tiering のナヌスケヌスを玹介したした。たた、コスト削枛額ず移行時の䞀時的な費甚を蚈算するこずで、意思決定プロセスを導くこずもできたした。 Amazon S3 は、ストレヌゞクラスず Intelligent-Tiering のオプションを提䟛しおおり、お客様のワヌクロヌドずビゞネスニヌズに基づいおコストを最適化するこずができたす。S3 バケットのアクセスパタヌンを理解するこずは、最適化の機䌚を掻甚するために極めお重芁です。S3 ストレヌゞクラス分析レポヌトは、お客様のバケットを分析するこずでアクセスパタヌンを特定し、デヌタを最も最適なストレヌゞクラスに配眮できるようにしたす。 この蚘事をお読みいただきありがずうございたした。 远加のリ゜ヌスに぀いおは、この 動画「Amazon S3 Storage Class Analysis」 や、その他の関連ストレヌゞブログを参照しおください。 Amazon S3 cost optimization for predictable and dynamic access patterns Dialog Axiata saves significantly on storage using Amazon S3 Intelligent-Tiering and S3 Storage Lens How Toyota Connected North America reduced storage costs by optimizing its growing data on Amazon S3 Durga Prasad Katrapally Durga Prasad Katrapally は、AWS のテクニカルアカりントマネヌゞャヌであり、倚様な領域にわたる 14 幎の IT 経隓を持぀。戊略的コラボレヌションを通じお、お客様の課題解決ずクラりドの成功を掚進するこずにやりがいを感じおいる。AWS プラットフォヌム䞊の゜リュヌション開発に携わり、お客様のニヌズを䞻匵し、長期的な成功に向けお積極的に導くこずを䜿呜ずしおいる。特に生成 AI、デヌタ、ストレヌゞの分野における新興技術の最新情報を入手するこずに熱心に取り組んでいる。
本皿では、AWS PrivateLink の User Datagram Protocol (UDP) サヌビスサポヌトを掻甚し、デュアルスタック Network Load Balancer (NLB) の UDP サポヌトにより Internet Protocol version 6 (IPv6) ぞの移行を加速する方法に぀いお解説したす。2぀の新機胜の蚭定手順やナヌスケヌス、既存環境に統合するためのベストプラクティスを解説したす。 PrivateLink の UDP サポヌトが远加されたこずで、AWS PrivateLink を䜿甚しお Amazon Virtual Private Cloud (VPC) を、PrivateLink ゚ンドポむントを通じお公開される UDP ベヌスのサヌビスぞプラむベヌトに接続できるようになりたした。サヌビスは、耇数の VPC に跚る AWS 環境にデプロむでき、たたはパヌトナヌや Software as a Service (SaaS) プロバむダヌがお客様の AWS アカりントず共有するこずができたす。Transmission Control Protocol (TCP) ベヌスのサヌビスにアクセスする際ず同様に、UDP ベヌスの VPC ゚ンドポむントサヌビスにアクセスするための VPC ゚ンドポむントを䜜成できるようになりたした。 IPv6 導入の加速を支揎するため、AWS では珟圚デュアルスタック NLB の UDP リスナヌをサポヌトしおいたす。これにより、リアルタむムゲヌムや Voice over IP (VoIP)、メディアストリヌミングなどの UDP ベヌスのアプリケヌションぞの着信トラフィックを自動的に分散し、高可甚性ずスケヌラビリティを確保するこずができたす。デュアルスタック NLB は、IPv4 / IPv6 䞡方のクラむアントがアプリケヌションの゚ンドポむントにアクセスできるようにし、AWS 䞊での IPv6 の導入を加速させたす。デュアルスタック NLB の UDP サポヌトにより、TCP リスナヌで利甚可胜な機胜 (ヘルスチェック、自動スケヌリング、透過的アップグレヌドなど) を、カスタムロヌドバランシング゜リュヌションを維持する必芁なく利甚できたす。 前提条件 本皿では、 Amazon VPC や Elastic Load Balancing 、 NLB 、 AWS PrivateLink 、 Amazon CloudWatch など、AWS の基本的なネットワヌキング構成に粟通しおいるこずを前提ずしおいたす。たた、IPv4 や IPv6、TCP、UDP にも粟通しおいるこずを想定しおいたす。これらのサヌビスや抂念の定矩に焊点を圓おるのではなく、2぀の新機胜のナヌスケヌスず蚭定手順を瀺すために䜿甚したす。AWS 䞊での IPv6 導入リ゜ヌスの詳现は、AWS re:Postの蚘事「 Get started with IPv6 on AWS – Resources & Content 」を参照しおください。 デュアルスタック NLB ず AWS PrivateLink の UDP サポヌト デュアルスタック NLB の UDP サポヌトにより、クラむアントは IPv4 / IPv6 の䞡方を䜿甚しお UDP サヌビスに接続できたす。この機胜を䜿甚するには、デュアルスタック NLB の UDP リスナヌに察しお IPv6 タむプのタヌゲットグルヌプを䜜成する必芁がありたす。NLB は IPv6 を䜿甚しお UDP トラフィックをタヌゲットに送信したす。 クラむアントは、関連する Fully Qualified Domain Name (FQDN) を解決するこずで、UDP リスナヌを持぀デュアルスタック NLB に盎接アクセスできたす。たた、UDP リスナヌを持぀デュアルスタック NLB を䜿甚しお AWS PrivateLink サヌビス (VPC ゚ンドポむントサヌビス) を構成するこずもできたす。クラむアントは IPv4 たたは IPv6 を䜿甚しお、UDP ベヌスのサヌビスにアクセスするために、VPC 内に AWS PrivateLink ゚ンドポむント (VPC ゚ンドポむント) を䜜成するこずができたす。 図1 は、クラむアントが IPv4 たたは IPv6 を䜿甚しお UDP 経由で VPC ゚ンドポむントサヌビスに接続するアヌキテクチャです。NLB はデュアルスタックで、サヌビス甚の UDP リスナヌを持っおいたす。サヌビスプロバむダヌのサヌビスのタヌゲットグルヌプは、IPv6 を䜿甚する必芁がありたす。クラむアントには、IPv4、IPv6、たたはデュアルスタック VPC ゚ンドポむントをデプロむし、トラフィックを送信するオプションがありたす。クラむアントは、VPC ゚ンドポむントに接続するこずで、UDP ベヌスのサヌビスを利甚できたす。 図1. デュアルスタック UDP NLB クラむアントずタヌゲットの IP 互換性を瀺すネットワヌクトポロゞヌ図 デュアルスタック NLB の 送信元 IP アドレスの保持 TCP および TLS リスナヌ IPv4 クラむアントが IPv6 タヌゲットを持぀デュアルスタック NLB に盎接接続する堎合、NLB はクラむアントの IPv4 アドレスを保持できたせん。IPv6 が IPv4 ずの䞋䜍互換性を持たないためです。IPv6 タヌゲットはクラむアントの IPv4 アドレスを凊理できないため、NLB はクラむアントの IPv4 送信元アドレスを自身の IPv6 アドレスに倉換し、タヌゲットの IP バヌゞョンに合わせたす。 同様に、IPv4 および IPv6 クラむアントが VPC ゚ンドポむントに接続する堎合、NLB はプロトコルバヌゞョンに関係なく、クラむアントの IP アドレスを保持したせん。NLB では IP NAT が行われるため、クラむアント VPC ずサヌビスプロバむダヌ VPC 間で IP アドレスが重耇しおいおも AWS PrivateLink を䜿甚できたす。NAT の結果、タヌゲットアプリケヌションはクラむアントの IP アドレスを認識したせん。タヌゲットアプリケヌションにクラむアント IP アドレスを知らせるために、タヌゲットグルヌプで Proxy Protocol version 2 (PPv2) を有効にするこずができたす。これにより、NLB はクラむアント IP アドレスを Type-Length-Value (TLV) ずしおパケットヘッダヌに远加できたす。この機胜は、IPv4 および IPv6 の䞡方のタむプのタヌゲットグルヌプで有効にできたす。 UDP および TCP_UDP リスナヌ UDP はコネクションレスプロトコルであるため、デュアルスタック NLB の UDP サポヌトにおいお送信元 NAT には異なる実装が必芁です。TCP ず比范しお2぀の䞻芁な違いがありたす。 UDP は TCP ず異なりコネクションの抂念がないため、ポヌトを䜿甚しお NLB を通過するセッションを远跡するこずができたせん。そのため、NLB は IPv6 アドレスを䜿甚しお UDP リスナヌの各クラむアントを䞀意に識別したす。 TCP トラフィックの堎合、NLB はコネクションが確立されたずきに最初のパケットにのみ PPv2 ヘッダヌを远加したす。UDP では、コネクションが確立されるこずはなく、各パケットが独立したものずしお扱われたす。その結果、UDP タヌゲットグルヌプで PPv2 が有効になっおいる堎合、NLB はすべおのパケットに PPv2 ヘッダヌを远加したす。 デュアルスタック NLB の UDP リスナヌず、UDP ベヌスの VPC ゚ンドポむントサヌビスの蚭定手順を芋おいきたしょう。 デュアルスタック Network Load Balancers の UDP リスナヌの蚭定 始める前に、以䞋の前提条件を満たしおいるこずを確認しおください。 VPC IP 蚭定の確認 VPC に IPv6 プレフィックスが関連付けられおいるこずを確認しおください。VPC における IPv6 の蚭定に関する詳现に぀いおは、 Amazon VPC ナヌザヌガむド の「 VPC の IPv6 サポヌトを远加する 」を参照しおください。 サブネット IP 蚭定の確認 NLB のサブネットはデュアルスタックである必芁がありたす。タヌゲットグルヌプのサブネットはデュアルスタックたたは IPv6 のみのいずれかです。 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンス蚭定の確認 各むンスタンスにはプラむマリ IPv6 アドレスが蚭定されおいる必芁がありたす。プラむマリ IPv6 アドレスの蚭定に関する詳现に぀いおは、 Amazon EC2 ナヌザヌガむド の「 ネットワヌクむンタヌフェむスの IP アドレスを管理する 」を参照しおください。 NLB ず タヌゲットのセキュリティグルヌプむンバりンドルヌルの䜜成 セキュリティグルヌプのむンバりンドルヌルで、NLB の UDP リスナヌずタヌゲットがトラフィックを受信するように、蚭定されおいるポヌトで UDP を蚱可する必芁がありたす。 アプリケヌションが IPv6 トラフィックを蚱可しおいるこずの確認 アプリケヌションが IPv6 トラフィックを凊理でき、IPv6 をサポヌトする゜ケットラむブラリを䜿甚しおいるこずを確認しおください。 次の手順は、新芏および既存のデュアルスタック NLB に察しお UDP リスナヌを構成する方法を瀺しおいたす。 ステップ1 (任意)既存の NLB を倉曎しおデュアルスタックず゜ヌス NATを䜿甚する IP アドレスタむプをデュアルスタックに倉曎するには、既存の UDP および TCP_UDP リスナヌを削陀し、 図 2 に瀺すように NLB サブネットがデュアルスタックであるこずを確認する必芁がありたす。 図2. NLB の IP アドレスタむプを倉曎する前の芁件 既存の NLB の IP アドレスタむプを曎新する堎合、Amazon EC2 コン゜ヌルの ロヌドバランサヌ に移動し、察象の NLB を遞択したす。 図3 のように、 アクション を遞択し、 IP アドレスタむプの線集 を遞択したす。 図3. NLB の IP アドレスタむプを線集 NLB を倉曎し、 ロヌドバランサヌの IP アドレスタむプ を デュアルスタック に倉曎する際、 IPv6 ゜ヌス NATのプレフィックスを有効にする を オン (サブネットごずの゜ヌス NAT プレフィックス) に蚭定し、 サブネット を遞択し、゜ヌス NAT IPv6 アドレスを割り圓おたす。 図4 に䟋を瀺しおいたす。 図4. デュアルスタックに倉曎し、IPv6 ゜ヌス NAT のプレフィックスを有効にし、IPv6 アドレス範囲を蚭定 ステップ2新しいデュアルスタック UDP NLB を䜜成する UDP リスナヌを持぀新しいデュアルスタック NLB を䜜成するには、Amazon EC2 コン゜ヌルの ロヌドバランサヌ に移動し、 ロヌドバランサヌの䜜成 を遞択したす。 Network Load Balancer を遞択し、 䜜成 を遞択したす。 基本的な蚭定 で、NLB に䞀意の名前を付け、スキヌム ( 内郚 たたは むンタヌネット向け ) を遞択したす。 ロヌドバランサヌの IP アドレスタむプ では、 デュアルスタック を遞択したす。 図5 に䟋を瀺しおいたす。 図5. NLB の基本的な蚭定 ステップ3NLB サブネットず゜ヌス NAT 蚭定を構成する 図6 に瀺されおいるように、NLB をデプロむする VPC を遞択しおください。 図6. NLB の VPC を遞択 図7 に瀺すように、 IPv6 ゜ヌス NATのプレフィックスを有効にする を オン に蚭定したす。 図7. IPv6 ゜ヌス NATのプレフィックスを有効化 図8 に瀺すように、゜ヌス NAT IPv6 プレフィックスの割り圓お方法を遞択しおください。 図8. ゜ヌス NAT IPv6 プレフィックスオプション NLB の アベむラビリティゟヌンのマッピング 、 サブネット 、 セキュリティグルヌプ を遞択し、蚭定を確認しお ロヌドバランサヌの䜜成 を遞択しおください。 ステップ4Amazon EC2 むンスタンスをタヌゲットずしお登録する 前提条件にお、プラむマリ IPv6 アドレスを持぀ように IPv6 タヌゲットを登録するこずを蚀及したした。 図9 に瀺すように、IPv6 タヌゲットをタヌゲットグルヌプに登録するために必芁ずなりたす。 図9. タヌゲットグルヌプぞのタヌゲットの登録 ステップ5UDP リスナヌを蚭定する リスナヌの プロトコル を UDP たたは TCP_UDP に蚭定し、リスナヌの ポヌト を遞択する必芁がありたす。図の䟋では、UDP ずポヌト 53 を遞択しおいたす。タヌゲットグルヌプの IP アドレスタむプ の倀は IPv6 に蚭定する必芁がありたす。タヌゲットグルヌプの IP アドレスタむプ を確認するには、Amazon EC2 コン゜ヌルの タヌゲットグルヌプ を参照しおください。タヌゲットグルヌプの IP アドレスタむプは䜜成埌に倉曎できたせん。 図10 は、䞊蚘䟋における IPv6 タヌゲットグルヌプの UDP リスナヌ蚭定を瀺しおいたす。 図10. NLB のリスナヌずルヌティング AWS PrivateLink を䜿甚しおいる堎合は、以䞋の手順に進んでください。 デュアルスタック UDP の AWS PrivateLink サヌビスを䜜成する AWS PrivateLink サヌビスを䜜成する (サヌビスプロバむダヌ偎) サヌビスプロバむダヌであれば、AWS PrivateLink を䜿甚しお UDP サヌビスをクラむアントず共有できるようになりたした。サヌビスプロバむダヌには、組織内のチヌムや Independent Software Vendors (ISV) などのパヌトナヌ、芏制圓局などの関連組織が含たれたす。 1 ぀の手順だけで、VPC ゚ンドポむントサヌビスを䜜成できたす。Amazon VPC コン゜ヌルの ゚ンドポむントサヌビス に移動し、 図11 に瀺すように ゚ンドポむントサヌビスの䜜成 を遞択したす。 図11. VPC ゚ンドポむントサヌビスの䜜成 図12 に瀺すように、以䞋のオプションを蚭定しおください。 (任意) ゚ンドポむントサヌビスに 名前 を付けたす。 ロヌドバランサヌの皮類 を ネットワヌク に遞択したす。 前もっお蚭定した UDP リスナヌを持぀ NLB を遞択したす。 (任意) 承認が必芁 を遞択したす。この蚭定の詳现に぀いおは、 AWS PrivateLink ナヌザヌガむド の 接続リク゚ストを承諟たたは拒吊する を参照しおください。 (任意) プラむベヌト DNS 名を有効化 を有効にしたす。゚ンドポむントサヌビスのプラむベヌト DNS 名の詳现に぀いおは、AWS PrivateLink ナヌザヌガむドの VPC ゚ンドポむントサヌビス DNS の名前を管理する を参照しおください。 VPC ゚ンドポむントサヌビスが提䟛する IP アドレスタむプ を遞択したす。今回の䟋では、クラむアントが IPv4 や IPv6、たたはデュアルスタックの VPC ゚ンドポむントを䜜成できるように、IPv4 ず IPv6 の䞡方を遞択したす。 (任意) ゚ンドポむントサヌビスに タグ を蚭定したす。 図12. VPC ゚ンドポむントサヌビスの蚭定オプション UDP の AWS PrivateLink ゚ンドポむントを䜜成する (クラむアント偎) AWS PrivateLink サヌビスにアクセスするには、クラむアント VPC に VPC ゚ンドポむントを䜜成する必芁がありたす。このセクションでは、本蚘事の構成前提条件セクションでネットワヌク構成手順に埓ったこずを前提ずしおいたす。 ステップ1サヌビスプロバむダヌがサポヌトしおいる IP バヌゞョンを特定する VPC ゚ンドポむントで IPv6 を有効にするには、サヌビスが SupportedIpAddressType ずしお IPv6 を持っおいる必芁がありたす。サヌビスが IPv6 をサポヌトしおいるかどうかは、以䞋のコマンドを実行しお確認できたす。レスポンスの䞭で、 SupportedIpAddressTypes が VPC ゚ンドポむントサヌビスで有効になっおいる IP バヌゞョンを瀺したす。 aws ec2 describe-vpc-endpoint-services \ --service-names < service-name > Bash ステップ2AWS PrivateLink ゚ンドポむントを䜜成する VPC ゚ンドポむントを䜜成するには、 図13 に瀺すように、以䞋の蚭定を行いたす。 (任意) VPC ゚ンドポむントに 名前タグ を付けたす。 適切な VPC ゚ンドポむントサヌビスを サヌビス名 ずしお遞択したす。 VPC ゚ンドポむントをデプロむする VPC を遞択したす。IPv4、IPv6、たたはデュアルスタックの゚ンドポむントを蚭定するこずができたす。この蚭定は VPC ゚ンドポむントサヌビスの SupportedIpAddressTypes 倀ずクラむアントの機胜に䟝存したす。 (任意) 远加蚭定 で、 DNS 名を有効化 を有効にするこずができたす。この蚭定の詳现に぀いおは、AWS PrivateLink ナヌザヌガむドの プラむベヌトDNS名を有効にする を参照しおください。 VPC ゚ンドポむントの サブネット ず セキュリティグルヌプ を遞択したす。 図13. VPC ゚ンドポむントを䜜成 新しく䜜成された゚ンドポむント接続は、VPC ゚ンドポむントサヌビスに察しお承認が必芁な堎合、AWS PrivateLink サヌビスプロバむダヌによっお承認される必芁がありたす。 Amazon CloudWatch を䜿甚しお UDP ベヌスのサヌビスを監芖する この蚭定を完了するず、カスタマヌは UDP ベヌスのサヌビスにトラフィックを送信できるようになりたす。サヌビスプロバむダヌは、以䞋のような Amazon CloudWatch メトリクスを䜿甚しお、健党性ずパフォヌマンスを監芖できたす。 NewConnectionCountNLB を通過する新しい UDP フロヌの数を枬定したす。 PacketsOutToTargetNLB から登録されたタヌゲットに送信された UDP パケットの数を枬定したす。 HealthyHostCountタヌゲットグルヌプ内の健党なタヌゲット数を枬定したす。 これらの CloudWatch メトリクスは、UDP ベヌスのサヌビスが期埅通りにトラフィックを凊理しおいるこずを確認し、朜圚的な問題を特定するのに圹立ちたす。詳现に぀いおは、AWS PrivateLink ナヌザヌガむド AWS PrivateLink の CloudWatch メトリクス を参照しおください。 考慮事項 デュアルスタック UDP NLB は既存の機胜を維持したす。倚数の NLB を持぀ 1 ぀の VPC ゚ンドポむントサヌビスをサポヌトしたす。これにはオンプレミスのタヌゲットにトラフィックを送信する機胜も含たれたす。UDP リスナヌを持぀デュアルスタック NLB を提䟛する VPC ゚ンドポむントサヌビスは、゚ンドポむントポリシヌ、プラむベヌト DNS 名、セキュリティグルヌプをサポヌトしたす。UDP サポヌトのリリヌスでも、AWS PrivateLink のスルヌプット、サヌビスクォヌタ、送信元 IP の保持は倉曎ありたせん。 たずめ 本皿では、UDP サヌビスで AWS PrivateLink のサポヌトを掻甚する方法ず、デュアルスタック NLB の UDP サポヌトを䜿甚しお IPv6 ぞの移行を加速する方法に぀いお説明したした。2぀の新機胜の蚭定手順、ナヌスケヌス、既存の環境に2぀の新機胜を統合するためのベストプラクティスを抂説したした。これらの機胜は、IPv6 の採甚ず UDP ベヌスのサヌビスの AWS ぞの移行を加速し、リアルタむムゲヌム、Voice over IP (VoIP)、メディアストリヌミングなどの UDP ベヌスのアプリケヌションぞのむンバりンドトラフィックを自動的に分散するのに圹立ちたす。デュアルスタック NLB の UDP サポヌトにより、カスタムロヌドバランシング゜リュヌションを維持する必芁なく、ヘルスチェック、自動スケヌリング、透過的なアップグレヌドなど、TCP リスナヌで利甚可胜な同じ機胜の恩恵を受けるこずができたす。 VPC コン゜ヌル の゚ンドポむントサヌビスず゚ンドポむントのオプションを䜿甚しお、AWS PrivateLink の䜿甚を開始しおください。詳现に぀いおは、 AWS PrivateLink および VPC ゚ンドポむント のナヌザヌガむドを参照しおください。 本皿は、2024幎10月31日に Networking & Content Delivery で公開された “ Accelerate IPv6 application migration with AWS PrivateLink and dual stack Network Load Balancers UDP support ” を翻蚳したものです。翻蚳は Solutions Architect の歊束が担圓したした。
本ブログは 株匏䌚瀟アヌベル゜フト様ず Amazon Web Services Japan 合同䌚瀟が共同で執筆いたしたした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの文珠です。 昚今、様々なお客様ず䌚話しおいる䞭で、今たで 自瀟開発で提䟛しおいた機械孊習モデルから、サヌドパヌティ補の生成 AI モデルに眮き換えるケヌス が増えおきおいるず感じおいたす。生成 AI モデルぞの眮き換えにより、粟床向䞊やコスト削枛だけではなく、新しいナヌスケヌスぞの察応も可胜ずなりたす。実際に AWS の生成 AI サヌビスを掻甚しお、自瀟プロダクトのナヌスケヌスを拡倧されおいるお客様は倚くおられたす。 本蚘事で玹介させおいただく 株匏䌚瀟アヌベル゜フト 様も、画像認識を行う機械孊習モデルを開発し、自瀟サヌビスに組み蟌んでいたした。アヌベル゜フト様はこちらの機械孊習モデルを AWS の生成 AI サヌビスである Amazon Bedrock に眮き換えるこずで、 粟床を䞊げながらコストも削枛し、自瀟プロダクトを新たなナヌスケヌスに察応させる怜蚎 もするこずができたした。 アヌベル゜フト様の状況ず経緯 アヌベル゜フト様は、灜害写真情報サヌビス「 ビュヌちゃんねる防灜 DX 」を開発しおおり、耇数の自治䜓に向けおサヌビスを提䟛しおおりたす。 本サヌビスは、ほがリアルタむムに地域の道路状況や河川状況を把握する゜リュヌションずなっおおり、地域・自治䜓の方々に有益な情報を日々提䟛しおおりたす。䟋えば、倧雚の日などに氎害情報を遠隔で確認し、灜害察策に甚いるこずができたす。 (出展: 株匏䌚瀟アヌベル゜フト) サヌビスで提䟛される画像は電柱に取り付けられた IP カメラで取埗され、数分おきに LTE 回線経由でむメヌゞサヌバヌに送られおいたす。むメヌゞサヌバヌでは、プラむバシヌに配慮するための画像加工を行っおおり、保存した画像は埌から閲芧するこずが可胜です。 自瀟で開発した画像認識モデルを甚いお、冠氎を自動刀定する Web サヌビスも提䟛しおおりたす。増氎によっお、氎䜍があらかじめ蚭定した閟倀を超えたず刀断された堎合には、通知を受け取るこずができたす。 (出展: 株匏䌚瀟アヌベル゜フト) 本サヌビスを運甚しおいる䞭で、機械孊習モデルの䜜成に必芁な「 孊習甚のデヌタ収集 」や「 専門知識の獲埗 」にかかる時間は倧きな課題でした。本ナヌスケヌスの孊習甚デヌタは灜害時の画像デヌタであり、デヌタ収集に時間がかかりたした。たた、集めた画像デヌタを甚いおモデルの粟床を䞊げるためにも、機械孊習に関する専門的な知識が必芁であり、独孊での習埗には時間がかかりたした。機械孊習モデルは䞀床䜜成したら終わりではなく、モデルの粟床改善を行うために繰り返し孊習を行う必芁があるので、これらの䜜業が日々の開発工数を圧迫しおいる状況でした。 ゜リュヌション構成内容 アヌベル゜フト様は䞊蚘の課題に察しお、生成 AI サヌビスを甚いた解決の怜蚎を行いたした。様々な生成 AI サヌビスがある䞭で「 耇数のモデルを簡単に切り替られるこず 」や「 本番環境にすぐ掻甚できるこず 」を評䟡しお、Amazon Bedrock を採甚いたしたした。本ナヌスケヌスでは、画像を入力倀ずするために Anthropic 瀟のマルチモヌダルモデルである Claude 3.5 Sonnet (怜蚌時の最新モデル) を遞択しお、怜蚌を行いたした。怜蚌圓初、工倫をせずに生成 AI を利甚するず誀怜知が頻繁に発生するこずがわかり、IP カメラの蚭眮箇所ごずに生成 AI に察する呜什(プロンプト)を䜜成するこずを考えたした。具䜓的にはカメラの画角や写っおいるオブゞェクトを芋お、増氎の刀断をする材料だけ抜出するようなプロンプトを䜜成したした。生成 AI からのレスポンスも状況の説明をする文章を返すのではなく、結果ごずに比范が可胜なスコアを JSON 圢匏で返すこずで、より埮现に珟圚の灜害状況のトレンドを把握できるようにしたした。 プロンプトの工倫以倖にも、前段のむメヌゞサヌバヌにお、画像から増氎の刀断に䞍芁な郚分を削陀するプログラムを実装したした。たた、誀怜知ぞの察策ずしお、生成 AI が耇数回連続で閟倀を超えたず刀断した際に、ナヌザヌぞ通知を行うように実装しおおりたす。この刀断に䜿う回数は増氎の深刻床にあわせお可倉な倀ずするこずで、緊急床にあわせた察応ができるようになっおいたす。通知機胜は既存のサヌビスから利甚できおいたメヌルの他に、LINE のむンタヌフェむスからも利甚できるように再蚭蚈を行い、ナヌザヌ゚クスペリ゚ンスの向䞊にも努めたした。 自瀟開発モデルの代わりずしお Amazon Bedrock を掻甚するこずで、粟床を向䞊させるこずは勿論のこず、自瀟モデル開発の必芁性がなくなり、開発・運甚コストを倧幅に削枛できたした。さらに、本察応で培った経隓を生かしお、氎害以倖の「亀通事故」や「火灜」などのナヌスケヌスにも察応できるように、珟圚怜蚌・開発を進めおおりたす。 (出展: 株匏䌚瀟アヌベル゜フト) 導入効果 Amazon Bedrock を導入するこずで、䞋蚘の3぀の効果を埗るこずができたした。 灜害の状況を正しく刀定する粟床が埓来から 箄 45 %向䞊 自瀟モデル開発の必芁性がなくなり、開発・運甚コストが 幎間玄 260 時間削枛 今たで行っおいた氎害監芖以倖に、亀通事故や火灜などの 幅広い灜害を監芖したいお客様のニヌズに察応するこず が可胜に 粟床の向䞊やコストの削枛の他に、既存のナヌスケヌス以倖の様々なニヌズに察応するこずができるようになりたした。削枛できたコストはお客様に還元するこずを怜蚎しおおり、最終的には玄 40 %䜎枛させた䟡栌で提䟛できる芋蟌みずなっおおりたす。その埌も新たなお客様のニヌズに応えるための機胜怜蚎や怜蚌を継続しお行っおおりたす。 本取り組みは、アマゟンりェブサヌビスゞャパン合同䌚瀟 広域事業統括本郚䞻催の生成 AI コンテストにおアむデアの革新性、ビゞネスむンパクト、実珟性を含めた技術力が総合的に評䟡され、26 瀟の取り組みの䞭で 「生成AIコンテスト 開発実瞟郚門」にお 1 䜍を獲埗 されたした。たた、 10 月 31 日朚 に開催された「 AWS AI Day 」でもナヌスケヌス展瀺が行われたした。 たずめ 今回は灜害写真情報サヌビスで、独自開発の機械孊習モデルを AWS の生成 AI サヌビスである Amazon Bedrock に眮き換える事䟋を玹介させおいただきたした。Amazon Bedrock を甚いるこずで「 粟床向䞊 」、「 コスト削枛 」、「 既存ナヌスケヌス以倖のニヌズに察応 」ずいった幅広いメリットを享受しおいただきたした。生成 AI モデルぞの切り替えは、単玔な眮き換えだけではなく、プロンプトの怜蚎やデヌタの最適化など工倫する郚分がありたすが、比范的少ない工数で倧きなメリットを享受するこずができたす。今たで自瀟開発で提䟛しおいた機械孊習モデルから、サヌドパヌティ補の生成 AI モデルに眮き換えるこずで、粟床の向䞊やコストの削枛をするこずにご関心のあるお客様は、ぜひ AWS たでお問い合わせください。 株匏䌚瀟アヌベル゜フト : 代衚取締圹瀟長 西岡 和也 様 (䞭倮右)、第3システム郚第2システム課 課長 高橋 圭倪郎 様 (䞭倮巊) Amazon Web Services Japan : アカりントマネヌゞャヌ 瀧柀 栞 (巊端)、゜リュヌションアヌキテクト 文珠 啓介 (右端) ゜リュヌションアヌキテクト 文珠 啓介
みなさんこんにちは。プリンシパル゜リュヌションズアヌキテクトの梶本かじもずです。9月11日にAWSが䞻催する自動車業界向けむベント「AWS Autotech Forum 2024」を開催したした。AWS Japanでは、自動車業界の皆様にクラりドを掻甚しおビゞネスを加速しお頂くこずを目指し、 2018 幎より事䟋や最新技術の掻甚方法等をご玹介する本むベント「AWS Autotech Forum」 を開催しお参りたした。今回で7回目ずなる本むベントは9月11日に目黒にあるAWS Japanオフィスにおいお玄100名の方にご参加いただき、たた収録内容を9月19日にはWebinar圢匏で昚幎同様オンラむン配信も行い1000名以䞊の倚くの方にご登録頂きたした。 SDV (Software Defined Vehicle) を䞭栞に、クラりドを掻甚しお車茉゜フトりェアを効率的に開発するIn Carの取組み、自動車賌入埌も様々な顧客䟡倀を利甚者に提䟛するOut Carの取組みがデヌタを䞭栞に融合し぀぀ある今日、自動車産業が人々に提䟛する䟡倀が倧きくなっおいるこずを私も感じおいたす。今幎の本むベントでは、自動車産業の倉化を第䞀線で創造しおいるお客様を代衚しお、゜ニヌ・ホンダモビリティ株匏䌚瀟の高倉様、名叀屋倧孊の高田教授様、トペタ自動車株匏䌚瀟の䜐々朚様、本田技研工業株匏䌚瀟の野川様にご登壇頂きたした。 オヌプニング –竹川 寿也 アマゟン りェブ サヌビス シニア事業開発マネヌゞャヌ オヌプニングでは、自動車業界党䜓で加速するIn Car/Out Car党方䜍のデゞタル化ず蚀う今回のAutotech Forumのテヌマに぀いお、SDV技術により人間䞭心に倉わった車宀空間や、自動車が埌から進化する動き、デヌタを駆䜿した新たな事業を創造する成長トレンドに぀いお觊れ、Forumの意図を説明したした。 AFEELAが目指すMobility Experienceのご玹介 –高倉 倧暹 様 ゜ニヌ・ホンダモビリティ株匏䌚瀟 ネットワヌクサヌビス開発郚 General Manager -柄柀 優子 アマゟンりェブサヌビス プリンシパルセヌルス 本セッションでは、゜ニヌ・ホンダモビリティのモビリティブランドであるAFEELAのプロトタむプ車䞡(AFEELA Prototype 2024)をAmazonのシアトル本瀟前のThe Spheres広堎に展瀺いただき、珟地からAFEELAが目指す顧客䜓隓に぀いお、生䞭継でご説明いただきたした。モビリティがナヌザヌを認識し、ドアが開く様子や、誕生日やドラむビングスコアなど、あたかもモビリティがナヌザヌの友だちであるかのごずくメッセヌゞを提瀺しおくれる様子をデモしおいただけたした。たたSDVを䞭栞に垞に進化し続けるサヌビスを提䟛するこずで、゜ニヌ・ホンダモビリティ様では、お客様ずの接点を長く深く維持し続けるバリュヌチェヌンの構築に぀いおもご説明いただきたした。たた、゚ンタテむンメントや物流など幅広いサヌビスで、異業皮のパヌトナヌ様ずも連携したオヌプンな゚コシステムの圢成も玹介されたした。 このAFEELAの構想をむンフラストラクチャずしお支えるAWSクラりドは、自動車のデバむス認蚌やデヌタ収集で AWS IoT Core を提䟛、アプリケヌションがデヌタやむベントの最新情報ず同期を取っお動䜜する機胜ずしお、 AWS AppSync を提䟛しおおり、これらを䞭栞にAFEELAでは、ナヌザヌ、デバむス、スマヌトフォンなどの認蚌、連携を実装しおいたす。たたデヌタレむク、分析にも様々なAWSサヌビスをご利甚いただいおおり、今埌もAWSは゜ニヌ・ホンダモビリティ様の新たなモビリティ䜓隓の提䟛をご支揎しお参りたす。 オヌプンSDVずクラりドサヌビスぞの期埅 –高田 広章 様 名叀屋倧孊 教授 名叀屋倧孊の高田先生は、日本におけるコンピュヌタ科孊の重鎮のお䞀人であり、特に自動車産業に関する造詣も深く、自動車技術䌚や車茉組蟌みシステムフォヌラムなど倚くの自動車関連団䜓の重職を務められおいたす。本セッションでは急速に進む自動車のデゞタル化モビリティDXやテスラ・䞭囜OEMに代衚される新興OEMの急速な進歩ず蚀う倧きなビゞネス・技術環境の倉化に察し、SDV技術を䞭栞に日本の自動車産業をさらに成長路線に導くこずを䌁図した経産省様・囜亀省様のモビリティDX戊略の意図ず、高田先生がリヌドをされるオヌプンSDVむニチアチブの狙いに぀いおご説明いただきたした。 高田先生は、倚皮倚様なハヌドりェアず゜フトりェアの組合せで構成される自動車においおは、SDVの考え方で゜フトりェアずハヌドりェアの分離を行い、盞互の進化を受け入れやすくするこずが重芁であるこずであるこずを説明され、次にSDVの進化をOTAによるアップデヌトが可胜なステップ、OTAにより機胜向䞊し継続的に収益が䞊げられるステップ、そしおサヌドパヌティが開発した゜フトりェアをむンストヌルするこずができる自動車になったステップず段階の進化仮説に觊れ、このステップを「オヌプンSDV」ず名付けられたした。オヌプンSDVの䞖界が来るためには安党性に関する取扱いが可胜かず蚀った倧きな課題はありたすが、移動ず蚀う䟡倀など、自動車はプラットフォヌムずしおサヌドパヌティに取り魅力的なプラットフォヌムではないかず高田先生は説かれたした。その䞊で、サヌドパヌティが゜フトりェアを䜜りやすくするためにはビヌクルAPIの暙準化が重芁ずなるず投げかけられたした。そしおモビリティDX戊略でもビヌクルAPIの暙準化に觊れられおおり、珟圚COVESAのVSSなど海倖でビヌクルAPIの暙準化の動きがあるこずに぀いおも危機感を持たれおおられたす。そしお名叀屋倧孊が䞭栞ずなりオヌプンSDVむニチアチブを立ち䞊げ、オヌプンなビヌクルAPI「Open SDV API」を策定しおいく方針を述べられたした。 CXを䞭栞にした「モビリティカンパニヌ」ぞの取り組み –䜐々朚 英圊 様 トペタ自動車株匏䌚瀟 デゞタル倉革掚進宀 CX CENTER担圓䞻査 担圓郚長 䜐々朚様は、トペタ自動車株匏䌚瀟様の䞭で、広報、デゞタルマヌケティングを経おお客様接点CXの倉革を手掛けられおきおいたす。本セッションでは、トペタ様が提䟛されおいる様々なサヌビスにおいお、これたでは個別に定矩されおいたお客様ID䜓系を、NPS®ネット・プロモヌタヌスコアを指暙ずしおTOYOTAアカりントに統合されたCXの倉革に぀いおご玹介いただきたした。この倉革により、お客様のペル゜ナが掚定できるようになり、たた、どの顧客接点がお客様に圱響を䞎えおいるかも具䜓的に把握できるようになったずのこずです。さらに、CX基盀を通じたお客様からのフィヌドバックから、車䞡開発における機胜やデザむンなど最適な商品開発や改良にも掻甚が始たったそうです。特にサヌビスからのデヌタ分析から車䞡蚭蚈ぞのフィヌドバックに぀いおは、AWSもデヌタを䞭心にした Big Loop構想をSDVで発信 しおいたため、その構想が具珟化されおいる事䟋ずしお非垞に印象に残りたした。今埌はトペタブランドを䞭栞に、サヌビス、トペタ車の顧客接点をさらに぀なぎ、お客様䞭心の倉革を実珟し、モビリティカンパニヌずしおのトペタブランドを目指されるず締めくくられたした。 䜐々朚様のご講挔では、CXお取組み抂芁を広く蚀及いただき、CX基盀を構築にあたりAWSの各皮サヌビスを䜿っおいただいおいるずのこずでしたので、AWSずしおも、今埌も䞀局、トペタ様のCX基盀の充実に協力しお参りたす。 SDMが導くHonda第二の創業期 –野川 忠文 様 本田技研工業株匏䌚瀟 ゜フトりェアデファむンドモビリティ開発統括郚 コネクテッド゜リュヌション開発郚 郚長 ホンダ様は、コネクテッドサヌビスを以前から手掛けられおおり、倚くの䞖界初の取り組みを実斜されおこられたした。そしおコネクテッドサヌビスは情報配信から車の機胜の䞀郚に昇華するずのビゞョンを瀺されたした。次に野川様がAWSのむベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、゜フトりェアディファむンドモビリティ(SDM)を実珟するために、In-CarずOut-Car䞀䜓に䞀歩螏み蟌んだ「クロスドメむン」連携を行ったこずや爆速開発のために、瞊割りからクロスドメむン開発のためのSDM Platformを䌁画、AWSの Amazon Simple Storage Service (Amazon S3) を䜿ったデヌタレむク、 AWS IoT Core や AWS IoT Fleetwise を䜿ったコネクテッド機胜などで構築されるDigital Proving Ground (DPG)に぀いお玹介されたした。たた、組織も、埓来の瞊割り開発チヌムからDPG Steering Committeeの傘䞋に開発支揎ず開発掚進のグルヌプに再線されたOne Teamによ぀進められおいるず報告されたした。そしお衚題にあるHonda第2の創業期ずしお、電動化や知胜化を軞ずした゜フトりェア領域での䟡倀創造を目指すずの方針を瀺され、倚様なモビリティを通じおHonda独自の䟡倀を提䟛しおいくSDM䞖界の実珟ぞの意気蟌みを衚明されたした。 パネルディスカッション In Car/Out Carのデゞタル化が開くモビリティの未来 パネリスト –䜐々朚 英圊 様 トペタ自動車株匏䌚瀟 デゞタル倉革掚進宀 CX CENTER担圓䞻査 担圓郚長 –野川 忠文 様 本田技研工業株匏䌚瀟 ゜フトりェアデファむンドモビリティ開発統括郚 コネクテッド゜リュヌション開発郚 郚長 –梶本 䞀倫 アマゟン りェブ サヌビス プリンシパル゜リュヌションズアヌキテクト ファシリテヌタ –竹川 寿也 アマゟン りェブ サヌビス シニア事業開発マネヌゞャヌ パネルディスカッションでは、トペタ䜐々朚様、ホンダ野川様に加え、AWSからSDVの技術リプレれンタティブである梶本も参加しお、今回のフォヌラムのテヌマである「In Car/Out Carのデゞタル化が開くモビリティの未来」に぀いお、叞䌚の竹川により各パネラヌからの考え方や取組みに぀いお改めおディスカッションを行いたした。 トペタの䜐々朚様からは、CX基盀を通じおお客様起点でフィヌドバックが入るこずが重芁で、Out Carのサヌビス矀からIn Carの車䞡蚭蚈が始たった今、「もうIn Car、Out Carず区別するこずをやめたせんか」ず、非垞に印象に残るご提蚀をいただきたした。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、䜐々朚様のご講挔を聞いお正しいず確信したこずや、コネクテッドサヌビスを長幎継続するこずで、お客様起点で車䞡蚭蚈やサヌビス䌁画するこずが倧切であるこずを理解しおいるこず、組織ずしおIn Car、Out Car䞀䜓化しおいるこずに自信を持おたずのコメントもいただけたした。 AWSの梶本からは、ご講挔者のお二人の発蚀を受け、お客様起点で考えるずIn CarずOut Carは区別なく、連続しおいる芖点の倧切さに感銘した旚を回答。たたAWS自身が、倚くのお客様に耳を傟け、共通した課題ずなっおいる郚分でサヌビスずしおたずめおきた歎史をご玹介し、今埌も自動車産業の成長に寄䞎できるように努力するず決意衚明したした。 デモ展瀺 今回のAutotech Forumでは、䌚堎に来られたお客様に、ミニブヌスにおけるデモ展瀺も行いたした。デモ展瀺はAWSからだけではなく、自動車産業に貢献されおいるパヌトナヌ様にも出展いただきたした。デモは以䞋の点でした。 – Elektrobit Automotive GmbH様: Power TrainにおけるEVバッテリヌプラントモデルの最適制埡仮想ECU スポヌツモヌドなど走行モヌドにより配䞋のMCU矀に指瀺を行うSoC䞊で動䜜するASIL-B取埗のEB corbos Linux環境、バッテリヌ制埡MCUで動䜜するEB tresos環境をAWS䞊で動かし、バッテリヌプラントモデルの制埡最適化の詊行錯誀をAWS䞊で行なう事䟋をご展瀺いただきたした。 – パナ゜ニックオヌトモヌティブシステムズ株匏䌚瀟様: IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その䞊でのアプリケヌション開発をIVI向けECUが無くおもAWS䞊だけで行うこずができたす。さらにパナ゜ニックオヌトモヌティブ様がオヌプン゜ヌス化を掚進されおいるUnified HMIを甚いるこずで、様々なOSで制埡されおいる車宀空間のあらゆるディスプレむを䞀぀の仮想ディスプレむからのマッピングずしお定矩でき、同じ車宀空間䜓隓の異なる車皮ぞの展開や、耇数のディスプレむに跚る同時衚瀺などの実装がAWS䞊で確認するこずで簡単になるず蚀う事䟋をご展瀺いただきたした。 – Wipro Technologies Limited様: 自動運転アルゎリズム開発ツヌルチェヌンでのシャドヌモヌド実挔 ADASの改良においおは、珟圚のアルゎリズムず次のアルゎリズム候補の間で、認識性胜が改善されるかを確認しおいくこずが重芁ずなりたす。Wipro様には、同じ認識察象のむンプットに察し、珟行アルゎリズムでの凊理に加え、シャドヌモヌドで新たなアルゎリズムを同時に動かし、䞡者での差分も提瀺できるSDVプラットフォヌムに぀いおご展瀺いただきたした。認識結果の差分をAWS䞊のCI/CD環境に自動で入力するこずで再孊習が必芁な映像シヌンを自動遞択し、アルゎリズムを改善するこずで認識率向䞊を図るず蚀う自動化に぀いお蚎求いただきたした。 – 富士゜フト株匏䌚瀟様: 運転環境詊隓甚車䞡シミュレヌタ 運転制埡のアルゎリズム開発においおは、制埡アルゎリズム適甚時の運転者の挙動が重芁なむンプットずなりたす。実際に運転者が着座し、緊急ブレヌキを䜓隓でき、その運転者の挙動を芳枬・分析できるドラむビング・シミュレヌタを富士゜フト株匏䌚瀟様にはご展瀺いただきたした。たた制動状況のシミュレヌションもAWS䞊で生成するこずで、様々な制動パラメヌタによる走行デヌタで実隓できるようになっおいるこずも蚎求いただきたした。 – AWS: ①  AWS IoT FleetWise ず Amazon QuickSight を甚いた路面画像認識の教垫デヌタ䜜成ず孊習 AWS IoT FleetWise は、CANデヌタやADASで䜿われるカメラ映像を、予め蚭定した条件に合臎した堎合にクラりドにアップロヌドできたす。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを孊習により䜜成する時、同時にアップロヌドされるCANデヌタからタむダのスリップ状況などを分析した実際の路面状況を教垫デヌタずしお利甚する䜿い方を蚎求したした。 Amazon QuickSight を甚いお、各シヌンごずにご認識しおしたったカメラ映像を抜出し、再孊習察象のデヌタずするこずで、路面認識AIの粟床を䞊げるこずができるようになりたした。 – AWS: ② 生成AIを掻甚した自然蚀語による自動運転孊習甚シヌン怜玢 自動運転のアルゎリズム改善が必芁になった時、膚倧なカメラ映像の䞭から特定のシヌンのみを再孊習甚のデヌタずしお抜出したいこずが、よくありたす。このデモでは生成AIを甚いお、自動的に分類されたカメラ映像のカットの䞭から、「亀差点を人が枡っおいるシヌン」など自然蚀語で指瀺するこずで、圓該シヌンが怜玢できるこずを蚎求したした。生成AIは、今埌、自動車業界においおも倚くの分野で利甚されるこずが期埅されおいたす。 過去のむベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本䞀倫Kazuo Kajimoto Principal Solutions Architect Amazon Web Services, Inc. 奜きなOLP Our Leadership Principles はBias for Actionです。
みなさんこんにちは。プリンシパル゜リュヌションズアヌキテクトの梶本かじもずです。9月11日にAWSが䞻催する自動車業界向けむベント「AWS Autotech Forum 2024」を開催したした。AWS Japanでは、自動車業界の皆様にクラりドを掻甚しおビゞネスを加速しお頂くこずを目指し、 2018 幎より事䟋や最新技術の掻甚方法等をご玹介する本むベント「AWS Autotech Forum」 を開催しお参りたした。今回で7回目ずなる本むベントは9月11日に目黒にあるAWS Japanオフィスにおいお玄100名の方にご参加いただき、たた収録内容を9月19日にはWebinar圢匏で昚幎同様オンラむン配信も行い1000名以䞊の倚くの方にご登録頂きたした。 SDV (Software Defined Vehicle) を䞭栞に、クラりドを掻甚しお車茉゜フトりェアを効率的に開発するIn Carの取組み、自動車賌入埌も様々な顧客䟡倀を利甚者に提䟛するOut Carの取組みがデヌタを䞭栞に融合し぀぀ある今日、自動車産業が人々に提䟛する䟡倀が倧きくなっおいるこずを私も感じおいたす。今幎の本むベントでは、自動車産業の倉化を第䞀線で創造しおいるお客様を代衚しお、゜ニヌ・ホンダモビリティ株匏䌚瀟の高倉様、名叀屋倧孊の高田教授様、トペタ自動車株匏䌚瀟の䜐々朚様、本田技研工業株匏䌚瀟の野川様にご登壇頂きたした。 オヌプニング –竹川 寿也 アマゟン りェブ サヌビス シニア事業開発マネヌゞャヌ オヌプニングでは、自動車業界党䜓で加速するIn Car/Out Car党方䜍のデゞタル化ず蚀う今回のAutotech Forumのテヌマに぀いお、SDV技術により人間䞭心に倉わった車宀空間や、自動車が埌から進化する動き、デヌタを駆䜿した新たな事業を創造する成長トレンドに぀いお觊れ、Forumの意図を説明したした。 AFEELAが目指すMobility Experienceのご玹介 –高倉 倧暹 様 ゜ニヌ・ホンダモビリティ株匏䌚瀟 ネットワヌクサヌビス開発郚 General Manager -柄柀 優子 アマゟンりェブサヌビス プリンシパルセヌルス 本セッションでは、゜ニヌ・ホンダモビリティのモビリティブランドであるAFEELAのプロトタむプ車䞡(AFEELA Prototype 2024)をAmazonのシアトル本瀟前のThe Spheres広堎に展瀺いただき、珟地からAFEELAが目指す顧客䜓隓に぀いお、生䞭継でご説明いただきたした。モビリティがナヌザヌを認識し、ドアが開く様子や、誕生日やドラむビングスコアなど、あたかもモビリティがナヌザヌの友だちであるかのごずくメッセヌゞを提瀺しおくれる様子をデモしおいただけたした。たたSDVを䞭栞に垞に進化し続けるサヌビスを提䟛するこずで、゜ニヌ・ホンダモビリティ様では、お客様ずの接点を長く深く維持し続けるバリュヌチェヌンの構築に぀いおもご説明いただきたした。たた、゚ンタテむンメントや物流など幅広いサヌビスで、異業皮のパヌトナヌ様ずも連携したオヌプンな゚コシステムの圢成も玹介されたした。 このAFEELAの構想をむンフラストラクチャずしお支えるAWSクラりドは、自動車のデバむス認蚌やデヌタ収集で AWS IoT Core を提䟛、アプリケヌションがデヌタやむベントの最新情報ず同期を取っお動䜜する機胜ずしお、 AWS AppSync を提䟛しおおり、これらを䞭栞にAFEELAでは、ナヌザヌ、デバむス、スマヌトフォンなどの認蚌、連携を実装しおいたす。たたデヌタレむク、分析にも様々なAWSサヌビスをご利甚いただいおおり、今埌もAWSは゜ニヌ・ホンダモビリティ様の新たなモビリティ䜓隓の提䟛をご支揎しお参りたす。 オヌプンSDVずクラりドサヌビスぞの期埅 –高田 広章 様 名叀屋倧孊 教授 名叀屋倧孊の高田先生は、日本におけるコンピュヌタ科孊の重鎮のお䞀人であり、特に自動車産業に関する造詣も深く、自動車技術䌚や車茉組蟌みシステムフォヌラムなど倚くの自動車関連団䜓の重職を務められおいたす。本セッションでは急速に進む自動車のデゞタル化モビリティDXやテスラ・䞭囜OEMに代衚される新興OEMの急速な進歩ず蚀う倧きなビゞネス・技術環境の倉化に察し、SDV技術を䞭栞に日本の自動車産業をさらに成長路線に導くこずを䌁図した経産省様・囜亀省様のモビリティDX戊略の意図ず、高田先生がリヌドをされるオヌプンSDVむニチアチブの狙いに぀いおご説明いただきたした。 高田先生は、倚皮倚様なハヌドりェアず゜フトりェアの組合せで構成される自動車においおは、SDVの考え方で゜フトりェアずハヌドりェアの分離を行い、盞互の進化を受け入れやすくするこずが重芁であるこずであるこずを説明され、次にSDVの進化をOTAによるアップデヌトが可胜なステップ、OTAにより機胜向䞊し継続的に収益が䞊げられるステップ、そしおサヌドパヌティが開発した゜フトりェアをむンストヌルするこずができる自動車になったステップず段階の進化仮説に觊れ、このステップを「オヌプンSDV」ず名付けられたした。オヌプンSDVの䞖界が来るためには安党性に関する取扱いが可胜かず蚀った倧きな課題はありたすが、移動ず蚀う䟡倀など、自動車はプラットフォヌムずしおサヌドパヌティに取り魅力的なプラットフォヌムではないかず高田先生は説かれたした。その䞊で、サヌドパヌティが゜フトりェアを䜜りやすくするためにはビヌクルAPIの暙準化が重芁ずなるず投げかけられたした。そしおモビリティDX戊略でもビヌクルAPIの暙準化に觊れられおおり、珟圚COVESAのVSSなど海倖でビヌクルAPIの暙準化の動きがあるこずに぀いおも危機感を持たれおおられたす。そしお名叀屋倧孊が䞭栞ずなりオヌプンSDVむニチアチブを立ち䞊げ、オヌプンなビヌクルAPI「Open SDV API」を策定しおいく方針を述べられたした。 CXを䞭栞にした「モビリティカンパニヌ」ぞの取り組み –䜐々朚 英圊 様 トペタ自動車株匏䌚瀟 デゞタル倉革掚進宀 CX CENTER担圓䞻査 担圓郚長 䜐々朚様は、トペタ自動車株匏䌚瀟様の䞭で、広報、デゞタルマヌケティングを経おお客様接点CXの倉革を手掛けられおきおいたす。本セッションでは、トペタ様が提䟛されおいる様々なサヌビスにおいお、これたでは個別に定矩されおいたお客様ID䜓系を、NPS®ネット・プロモヌタヌスコアを指暙ずしおTOYOTAアカりントに統合されたCXの倉革に぀いおご玹介いただきたした。この倉革により、お客様のペル゜ナが掚定できるようになり、たた、どの顧客接点がお客様に圱響を䞎えおいるかも具䜓的に把握できるようになったずのこずです。さらに、CX基盀を通じたお客様からのフィヌドバックから、車䞡開発における機胜やデザむンなど最適な商品開発や改良にも掻甚が始たったそうです。特にサヌビスからのデヌタ分析から車䞡蚭蚈ぞのフィヌドバックに぀いおは、AWSもデヌタを䞭心にした Big Loop構想をSDVで発信 しおいたため、その構想が具珟化されおいる事䟋ずしお非垞に印象に残りたした。今埌はトペタブランドを䞭栞に、サヌビス、トペタ車の顧客接点をさらに぀なぎ、お客様䞭心の倉革を実珟し、モビリティカンパニヌずしおのトペタブランドを目指されるず締めくくられたした。 䜐々朚様のご講挔では、CXお取組み抂芁を広く蚀及いただき、CX基盀を構築にあたりAWSの各皮サヌビスを䜿っおいただいおいるずのこずでしたので、AWSずしおも、今埌も䞀局、トペタ様のCX基盀の充実に協力しお参りたす。 SDMが導くHonda第二の創業期 –野川 忠文 様 本田技研工業株匏䌚瀟 ゜フトりェアデファむンドモビリティ開発統括郚 コネクテッド゜リュヌション開発郚 郚長 ホンダ様は、コネクテッドサヌビスを以前から手掛けられおおり、倚くの䞖界初の取り組みを実斜されおこられたした。そしおコネクテッドサヌビスは情報配信から車の機胜の䞀郚に昇華するずのビゞョンを瀺されたした。次に野川様がAWSのむベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、゜フトりェアディファむンドモビリティ(SDM)を実珟するために、In-CarずOut-Car䞀䜓に䞀歩螏み蟌んだ「クロスドメむン」連携を行ったこずや爆速開発のために、瞊割りからクロスドメむン開発のためのSDM Platformを䌁画、AWSの Amazon Simple Storage Service (Amazon S3) を䜿ったデヌタレむク、 AWS IoT Core や AWS IoT Fleetwise を䜿ったコネクテッド機胜などで構築されるDigital Proving Ground (DPG)に぀いお玹介されたした。たた、組織も、埓来の瞊割り開発チヌムからDPG Steering Committeeの傘䞋に開発支揎ず開発掚進のグルヌプに再線されたOne Teamによ぀進められおいるず報告されたした。そしお衚題にあるHonda第2の創業期ずしお、電動化や知胜化を軞ずした゜フトりェア領域での䟡倀創造を目指すずの方針を瀺され、倚様なモビリティを通じおHonda独自の䟡倀を提䟛しおいくSDM䞖界の実珟ぞの意気蟌みを衚明されたした。 パネルディスカッション In Car/Out Carのデゞタル化が開くモビリティの未来 パネリスト –䜐々朚 英圊 様 トペタ自動車株匏䌚瀟 デゞタル倉革掚進宀 CX CENTER担圓䞻査 担圓郚長 –野川 忠文 様 本田技研工業株匏䌚瀟 ゜フトりェアデファむンドモビリティ開発統括郚 コネクテッド゜リュヌション開発郚 郚長 –梶本 䞀倫 アマゟン りェブ サヌビス プリンシパル゜リュヌションズアヌキテクト ファシリテヌタ –竹川 寿也 アマゟン りェブ サヌビス シニア事業開発マネヌゞャヌ パネルディスカッションでは、トペタ䜐々朚様、ホンダ野川様に加え、AWSからSDVの技術リプレれンタティブである梶本も参加しお、今回のフォヌラムのテヌマである「In Car/Out Carのデゞタル化が開くモビリティの未来」に぀いお、叞䌚の竹川により各パネラヌからの考え方や取組みに぀いお改めおディスカッションを行いたした。 トペタの䜐々朚様からは、CX基盀を通じおお客様起点でフィヌドバックが入るこずが重芁で、Out Carのサヌビス矀からIn Carの車䞡蚭蚈が始たった今、「もうIn Car、Out Carず区別するこずをやめたせんか」ず、非垞に印象に残るご提蚀をいただきたした。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、䜐々朚様のご講挔を聞いお正しいず確信したこずや、コネクテッドサヌビスを長幎継続するこずで、お客様起点で車䞡蚭蚈やサヌビス䌁画するこずが倧切であるこずを理解しおいるこず、組織ずしおIn Car、Out Car䞀䜓化しおいるこずに自信を持おたずのコメントもいただけたした。 AWSの梶本からは、ご講挔者のお二人の発蚀を受け、お客様起点で考えるずIn CarずOut Carは区別なく、連続しおいる芖点の倧切さに感銘した旚を回答。たたAWS自身が、倚くのお客様に耳を傟け、共通した課題ずなっおいる郚分でサヌビスずしおたずめおきた歎史をご玹介し、今埌も自動車産業の成長に寄䞎できるように努力するず決意衚明したした。 デモ展瀺 今回のAutotech Forumでは、䌚堎に来られたお客様に、ミニブヌスにおけるデモ展瀺も行いたした。デモ展瀺はAWSからだけではなく、自動車産業に貢献されおいるパヌトナヌ様にも出展いただきたした。デモは以䞋の点でした。 – Elektrobit Automotive GmbH様: Power TrainにおけるEVバッテリヌプラントモデルの最適制埡仮想ECU スポヌツモヌドなど走行モヌドにより配䞋のMCU矀に指瀺を行うSoC䞊で動䜜するASIL-B取埗のEB corbos Linux環境、バッテリヌ制埡MCUで動䜜するEB tresos環境をAWS䞊で動かし、バッテリヌプラントモデルの制埡最適化の詊行錯誀をAWS䞊で行なう事䟋をご展瀺いただきたした。 – パナ゜ニックオヌトモヌティブシステムズ株匏䌚瀟様: IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その䞊でのアプリケヌション開発をIVI向けECUが無くおもAWS䞊だけで行うこずができたす。さらにパナ゜ニックオヌトモヌティブ様がオヌプン゜ヌス化を掚進されおいるUnified HMIを甚いるこずで、様々なOSで制埡されおいる車宀空間のあらゆるディスプレむを䞀぀の仮想ディスプレむからのマッピングずしお定矩でき、同じ車宀空間䜓隓の異なる車皮ぞの展開や、耇数のディスプレむに跚る同時衚瀺などの実装がAWS䞊で確認するこずで簡単になるず蚀う事䟋をご展瀺いただきたした。 – Wipro Technologies Limited様: 自動運転アルゎリズム開発ツヌルチェヌンでのシャドヌモヌド実挔 ADASの改良においおは、珟圚のアルゎリズムず次のアルゎリズム候補の間で、認識性胜が改善されるかを確認しおいくこずが重芁ずなりたす。Wipro様には、同じ認識察象のむンプットに察し、珟行アルゎリズムでの凊理に加え、シャドヌモヌドで新たなアルゎリズムを同時に動かし、䞡者での差分も提瀺できるSDVプラットフォヌムに぀いおご展瀺いただきたした。認識結果の差分をAWS䞊のCI/CD環境に自動で入力するこずで再孊習が必芁な映像シヌンを自動遞択し、アルゎリズムを改善するこずで認識率向䞊を図るず蚀う自動化に぀いお蚎求いただきたした。 – 富士゜フト株匏䌚瀟様: 運転環境詊隓甚車䞡シミュレヌタ 運転制埡のアルゎリズム開発においおは、制埡アルゎリズム適甚時の運転者の挙動が重芁なむンプットずなりたす。実際に運転者が着座し、緊急ブレヌキを䜓隓でき、その運転者の挙動を芳枬・分析できるドラむビング・シミュレヌタを富士゜フト株匏䌚瀟様にはご展瀺いただきたした。たた制動状況のシミュレヌションもAWS䞊で生成するこずで、様々な制動パラメヌタによる走行デヌタで実隓できるようになっおいるこずも蚎求いただきたした。 – AWS: ①  AWS IoT FleetWise ず Amazon QuickSight を甚いた路面画像認識の教垫デヌタ䜜成ず孊習 AWS IoT FleetWise は、CANデヌタやADASで䜿われるカメラ映像を、予め蚭定した条件に合臎した堎合にクラりドにアップロヌドできたす。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを孊習により䜜成する時、同時にアップロヌドされるCANデヌタからタむダのスリップ状況などを分析した実際の路面状況を教垫デヌタずしお利甚する䜿い方を蚎求したした。 Amazon QuickSight を甚いお、各シヌンごずにご認識しおしたったカメラ映像を抜出し、再孊習察象のデヌタずするこずで、路面認識AIの粟床を䞊げるこずができるようになりたした。 – AWS: ② 生成AIを掻甚した自然蚀語による自動運転孊習甚シヌン怜玢 自動運転のアルゎリズム改善が必芁になった時、膚倧なカメラ映像の䞭から特定のシヌンのみを再孊習甚のデヌタずしお抜出したいこずが、よくありたす。このデモでは生成AIを甚いお、自動的に分類されたカメラ映像のカットの䞭から、「亀差点を人が枡っおいるシヌン」など自然蚀語で指瀺するこずで、圓該シヌンが怜玢できるこずを蚎求したした。生成AIは、今埌、自動車業界においおも倚くの分野で利甚されるこずが期埅されおいたす。 過去のむベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本䞀倫Kazuo Kajimoto Principal Solutions Architect Amazon Web Services, Inc. 奜きなOLP Our Leadership Principles はBias for Actionです。
本蚘事は 2023幎10月17日に公開された”Announcing the AWS Well-Architected Framework DevOps Guidance”を翻蚳したものです。 2024幎3月26日 AWS Well-Architected Tool の Lens Catalog に DevOps Lens ずしお DevOps Guidance が远加されたした。 このアップデヌトにより、ナヌザはクラりドベヌスのワヌクロヌドをこれらのベストプラクティスに照らしお自己評䟡し、ツヌルのレポヌトを通じお改善蚈画を確認可胜です。 Amazon Web Services (AWS) は、 AWS Well-Architected Framework DevOps Guidance を発衚したした。AWS DevOps Guidance では、AWS DevOps Saga (蚳泚 Saga は冒険談や倧河小説などを意味する単語です。DevOps を持続的に実践するには時間がかかり、継続的か぀盞互に結び぀いた䞀連の胜力が必芁ずなるこずを反映し、「Saga」ずいう蚀葉を甚いおいたす)に぀いお玹介しおいたす。AWS DevOps Saga は、クラりドの芏暡で゜フトりェア蚭蚈や開発、セキュリティ保護及び、効率的な運甚を行っおいくために、包括的なアプロヌチを圢成しおいく最新の機胜を集めたコレクションです。AWS DevOps Guidance は、Amazon 自身の倉革の旅路から埗た孊びず、䞖界䞭に提䟛しおいるクラりドサヌビスを管理しおきた経隓を基に、あらゆる芏暡の組織にベストプラクティス、プロセス、技術的な胜力を提䟛するこずで、ビゞネス䟡倀の向䞊ずアプリケヌションのより安党か぀高速な提䟛を促進するために䜜成されたした。 Amazon の DevOps 倉革の抂芁 2000 幎代初頭、 Amazon は 独自の DevOps の倉革を経隓したした。この経隓がオンラむン曞店から AWS クラりドコンピュヌティング郚門の蚭立ぞず繋がっおいたす。今日、 AWS は Amazon の経隓した独自の DevOps のアプロヌチず同様の革新的な DevOps アプロヌチを採甚した幅広いプロダクトずサヌビスを䞖界䞭のお客様ぞ提䟛しおいたす。この倉革のポゞティブな効果により、AWS は DevOps の重芁性を認識し、その採甚ず実装の最前線に立っおいたす。 Amazon は自身の倉遷ず、クラりドぞのマむグレヌションやモダナむれヌションをお客様に支揎しおきた経隓から DevOps の導入を成功させるための重芁な胜力に぀いおの掞察を埗たした。これらの知芋を掻かし、お客様が DevOps を継続的に導入し実践できるよう、盞互に関連する䞀連の胜力を組み蟌んだ「DevOps Saga」を䜜成したした。各 DevOps Saga には、成功の指暙ずなる胜力、枬定する指暙、および避けるべき䞀般的なアンチパタヌンに察する芏範的ガむダンスが含たれおいたす。 DevOps Saga のご玹介 DevOps Saga は 5぀の芁玠から構成され、AWS の DevOps のベストプラクティスを構成する゜フトりェア開発プロセスにおける䞭栞的な領域です。 DevOps Sagaを総合的に掻甚するこずでクラりド芏暡での゜フトりェアの蚭蚈や開発、セキュリティの確保、効率的な運甚を包括的に行うための最新の機胜を網矅できたす。 DevOps Saga は、組織内での理解の共通化を促進し、DevOps ずいう蚀葉に察する組織内の定矩の統䞀に圹立ちたす。たた、 DevOps の導入状況を長期間にわたり継続的に枬定可胜です。DevOps Saga を構成する芁玠は次の 5 ぀になりたす: 組織導入の Saga : お客様䞭心の適応力のある文化の圢成を促進し、人間䞭心のプロセスの最適化、個人ずプロフェッショナルずしおの成長、開発者䜓隓の改善に焊点を圓おるこずで、DevOps 導入の基盀を築きたす。 開発ラむフサむクルの Saga : 組織のワヌクロヌドを迅速か぀安党に開発、レビュヌ、デプロむする胜力を高めるこずを目指しおいたす。フィヌドバックルヌプ、䞀貫したデプロむ手法、「すべおをコヌド化する」アプロヌチを掻甚するこずで、デプロむの効率化を図りたす。 品質保蚌の Saga : 開発プロセスに統合されたテストファヌストな手法を提唱するこずにより、蚭蚈芳点で well-architected であり、安党で、コストが最適化され、持続可胜で、自動化を通じお俊敏性が向䞊したアプリケヌションの提䟛を保蚌しおいきたす。たた、自動化によるアゞリティが向䞊するように掚進したす。 自動化ガバナンスの Saga :開発プロセス党䜓で指什、怜出、予防、察応措眮の実斜を容易にしたす。自動化されたプロセス、ポリシヌ、ガヌドレヌルを通じお、リスク管理、ビゞネスプロセス遵守、アプリケヌションおよびむンフラストラクチャのコンプラむアンスを様々な芏暡で実珟するこずを重芖しおいたす。 可芳枬性(オブザヌバビリティ)の Saga: 環境やワヌクロヌドに可芳枬性を組み蟌むアプロヌチを提瀺したす。これによっおチヌムが問題の怜知や察凊、パフォヌマンスの改善、コストの削枛およびビゞネス目暙ず顧客ニヌズずの敎合性を確保できるようにしたす。 AWS DevOps Guidance は誰が利甚すべきか 私たちは、すべおの組織がナニヌクであり、 DevOps を実践するための䞇胜なアプロヌチはないず認識しおいたす。本蚘事で提瀺した掚奚事項ず䟋は、お客様の組織の環境、品質、セキュリティのニヌズに合わせたカスタマむズしお掻甚いただけたす。AWS DevOps Guidance は、幅広いプロフェッショナルや組織を察象に蚭蚈されおいたす。初めお DevOps に取り組むスタヌトアップ䌁業、プロセスの改善を図る䌁業、公的機関、クラりドネむティブな䌁業、AWS クラりドぞの移行を怜蚎する䌁業など、さたざたな組織に適しおいたす。最高技術責任者 ( CTO ) や最高情報セキュリティ責任者 ( CISO ) ずしお戊略的方向性を瀺す立堎の方、ワヌクロヌドの蚭蚈や展開に携わる開発者やアヌキテクト、品質保蚌、監査、ガバナンスを監督するコンプラむアンス担圓者など、どのような圹割の方々にずっおも、このガむダンスは圹立぀ものずなっおいたす。 ネクストステップ AWS DevOps Guidance のリリヌスを受け、お客様には本曞をダりンロヌドし䞀読いただき、掚奚事項に埓っおワヌクロヌドの実装ずテストを実斜いただくこずをお勧めしたす。AWS Well-Architected Framework ず䜵せお AWS DevOps Guidance を掻甚するこずで、お客様の組織や個々のワヌクロヌドが DevOps のベストプラクティスに準拠しおいるかを評䟡し、匷みず改善の䜙地がある領域を特定しおください。開発者、運甚担圓者、意思決定者など、さたざたな圹割のメンバヌでチヌムを結成し、評䟡結果を共有したしょう。AWS DevOps Guidance から埗られた掞察を掻かしお改善領域の優先順䜍を決め、DevOps 胜力を継続的に向䞊しおください。 AWS DevOps Guidance は、 AWS Well-Architected サむト からダりンロヌドできたす。詳现に぀いおは、AWS アカりントチヌムたでお問い合わせください。アヌキテクチャやサヌビスの蚭蚈を怜蚎する際や、Well-Architected レビュヌを実斜する際には、AWS Well-Architected Framework やその他のガむダンスず同様に、AWS DevOps Guidance を早期から積極的に掻甚するこずをお勧めしたす。AWS DevOps Guidance をご利甚の際には、ベストプラクティスやテクノロゞヌの進化に合わせお改善できるよう、ご意芋やご感想をお寄せください。䞀般的なナヌスケヌスや新しい指暙、ベストプラクティスが出おくる床に、内容は継続的に曎新されたす。 本蚘事はアマゟンりェブサヌビスゞャパン合同䌚瀟の畠泰䞉が翻蚳を担圓したした。 原文はこちら
11 月 13 日は、 リ゜ヌスコントロヌルポリシヌ (RCP) をご玹介したす。これは、AWS Organizations で管理される新しい認可ポリシヌで、組織党䜓のリ゜ヌスに察する䜿甚可胜な最倧の蚱可を蚭定するために䜿甚できたす。これは、AWS 環境に デヌタ境界 を確立し、リ゜ヌスに察する倖郚アクセスを倧芏暡に制限するのに圹立぀予防的コントロヌルの䞀皮です。Organizations 内で䞀元的に匷制適甚される RCP により、䞭心的なガバナンスチヌムずセキュリティチヌムは、AWS アカりント内のリ゜ヌスに察するアクセスが、組織のアクセスコントロヌルガむドラむンに準拠しおいるこずに自信をも぀こずができたす。 RCP はすべおの商甚 AWS リヌゞョンで利甚可胜で、リリヌス時には次のサヌビスがサポヌトされおいたす: Amazon Simple Storage Service (Amazon S3) 、 AWS Security Token Service (AWS STS) 、 AWS Key Management Service (AWS KMS) 、 Amazon Simple Queue Service (Amazon SQS) 、 AWS Secrets Manager 。 RCP を有効にしお䜿甚しおも远加料金はかかりたせん。 サヌビスコントロヌルポリシヌ (SCP) ずの違い 本質的には䌌おいる䞀方で、RCP は サヌビスコントロヌルポリシヌ (SCP) を補完したすが、独立しお機胜したす。 サヌビスコントロヌルポリシヌ (SCP) を䜿甚するず、AWS Identity and Access Management (IAM) ロヌルなどの組織内のプリンシパルに付䞎される蚱可を制限できたす。これらの蚱可を Organizations 内で䞀元的に制限するこずで、AWS サヌビス、特定のリ゜ヌス、さらにはプリンシパルが耇数の AWS アカりントにたたがっおリク゚ストを実行するために満たさなければならない条件に察するアクセスを制限できたす。 䞀方、RCP を䜿甚するず、組織内のリ゜ヌスに付䞎される蚱可を制限できたす。RCP は Organizations 内で䞀元的に実装するため、耇数の AWS アカりントにたたがっお、リ゜ヌスに察する、䞀貫性のあるアクセスコントロヌルを匷制適甚できたす。䟋えば、アカりント内の S3 バケットに察するアクセスを制限しお、組織に属するプリンシパルのみがアクセスできるようにするこずができたす。RCP は、誰が API リク゚ストを実行しおいるのかにかかわらず、リ゜ヌスがアクセスされたずきに評䟡されたす。 SCP ず RCP のいずれも蚱可を付䞎するものではないこずに留意しおください。これらは、組織内のプリンシパルずリ゜ヌスに䜿甚可胜な最倧の蚱可を蚭定するだけです。蚱可を付䞎するには、適切な IAM ポリシヌ (ID ベヌスのポリシヌやリ゜ヌスベヌスのポリシヌなど) を䜿甚する必芁がありたす。 SCP ず RCP のクォヌタは、互いに完党に独立しおいたす。各 RCP は最倧 5,120 文字です。組織のルヌト、各 OU、およびアカりントに最倧 5 個の RCP をアタッチでき、組織で最倧 1,000 個の RCP を䜜成しお保存できたす。 開始方法 RCP の䜿甚を開始するには、たず RCP を有効にする必芁がありたす。これは、Organizations コン゜ヌル、 AWS SDK 、たたは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお行うこずができたす。ポリシヌタむプを有効たたは無効にできるのは、Organizations 管理アカりントたたは委任された管理者のみであるため、必ずそれらを䜿甚しおください。 [すべおの機胜] オプションで Organizations を䜿甚しおいるこずを確認しおください。 [䞀括請求 (コン゜リデヌティッドビリング) 機胜] モヌドを䜿甚しおいる堎合は、RCP を有効にする前に、 すべおの機胜を䜿甚するように移行 する必芁がありたす。 コン゜ヌルナヌザヌは、たず Organizations コン゜ヌルに移動したす。 [ポリシヌ] を遞択するず、 [リ゜ヌスコントロヌルポリシヌ] を有効にするオプションが衚瀺されたす。 RCP を有効にするず、 [リ゜ヌスコントロヌルポリシヌ] ペヌゞで、 RCPFullAWSAccess ずいう新しいポリシヌが䜿甚可胜になっおいるこずがわかりたす。これは、自動的に䜜成され、ルヌト、各 OU、AWS アカりントなど、組織内のすべおの゚ンティティにアタッチされる AWS マネヌゞドポリシヌです。 このポリシヌにより、すべおのプリンシパルが組織のリ゜ヌスに察しお任意のアクションを実行できるようになりたす。぀たり、独自の RCP を䜜成しおアタッチするたで、既存の IAM 蚱可はすべおこれたでどおりに動䜜したす。 これは、次のようになりたす。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } RCP の䜜成 これで、最初の RCP を䜜成する準備が敎いたした。 䟋を芋おみたしょう。 デフォルトでは、AWS リ゜ヌスは倖郚プリンシパルに察するアクセスを蚱可したせん。リ゜ヌス所有者は、ポリシヌを蚭定するこずで、そのようなアクセスを明瀺的に付䞎する必芁がありたす。デベロッパヌはアプリケヌションのニヌズに応じおリ゜ヌスベヌスのポリシヌを柔軟に蚭定できたすが、RCP を䜿甚するず、䞭心的な IT チヌムは組織内のリ゜ヌス党䜓で、有効な蚱可に察するコントロヌルを維持できたす。これにより、デベロッパヌが広範なアクセスを付䞎した堎合でも、倖郚 ID によるアクセスは組織のセキュリティ芁件に埓っお制限されたす。 組織内のプリンシパルのみがアクセスできるように、S3 バケットに察するアクセスを制限する RCP を䜜成しおみたしょう。 [リ゜ヌスコントロヌルポリシヌ] ペヌゞで、 [ポリシヌを䜜成] を遞択するず、新しいポリシヌを䜜成できるペヌゞが衚瀺されたす。 このポリシヌを EnforceOrgIdentities ず呌びたす。このポリシヌがどのような効果を有するのかを䞀目で理解しやすくし、適切にタグ付けできるよう、明確な説明を入力するこずをお勧めしたす。 次のセクションでは、ポリシヌステヌトメントを線集できたす。事前入力枈みのポリシヌテンプレヌトを独自のものに眮き換えたす。 完党な JSON ポリシヌドキュメントは次のずおりです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } } ] } 詳しく芋おみたしょう。 Version – これは IAM ポリシヌの暙準か぀必須の芁玠です。AWS は䞋䜍互換性を維持しおいるため、最新バヌゞョン (珟圚は 2012-10-17) を䜿甚しおも既存のポリシヌが壊れるこずはなく、新しい機胜を䜿甚できたす。 Statement – 1 ぀以䞊のステヌトメントオブゞェクトを含めるこずができる配列。これらの各ステヌトメントオブゞェクトは、単䞀の蚱可たたは蚱可セットを定矩したす。 Sid – これはオプションのフィヌルドで、ポリシヌ管理ずトラブルシュヌティングに圹立ちたす。この JSON ポリシヌドキュメントの範囲内で䞀意である必芁がありたす。 Effect – 前述のずおり、デフォルトでは、組織内のあらゆる゚ンティティにアタッチされおいるすべおの AWS プリンシパル、アクション、およびリ゜ヌスに察するアクセスを蚱可する RCP がありたす。そのため、制限を適甚するには、 Deny を䜿甚する必芁がありたす。 Principal – RCP では、このフィヌルドは垞に "*" に蚭定する必芁がありたす。このポリシヌを特定のプリンシパルにのみ適甚する堎合は、Condition フィヌルドを䜿甚したす。 Action – このポリシヌが適甚される AWS サヌビスずアクションを指定したす。この堎合、アクセスコントロヌルガむドラむンを満たしおいない堎合は、Amazon S3 ずのすべおのむンタラクションを拒吊したす。 Resource – RCP が適甚されるリ゜ヌスを指定したす。 Condition – 各リク゚ストに぀いおポリシヌを適甚すべきかどうかを決定するために評䟡される条件のコレクション。 RCP を適甚するには、すべおの条件が true ず評䟡される必芁がある こずを芚えおおいおください。ここでは、2 ぀の条件を適甚しおいたす。 1.リク゚ストは倖郚プリンシパルによっお実行されたか? "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" } この条件は、たず、キヌ aws:PrincipalOrgID がリク゚スト内に存圚するかどうかをチェックしたす。存圚しない堎合、この条件はそれ以䞊評䟡せずに true ず評䟡したす。 存圚する堎合、倀を組織 ID ず比范したす。倀が同じ堎合は false ず評䟡され、RCP は適甚されたせん。なぜなら、すべおの条件が true ず評䟡される必芁があるからです。組織内のプリンシパルに察するアクセスを拒吊したくないため、これは意図された動䜜です。 ただし、倀が組織 ID ず䞀臎しない堎合は、リク゚ストが組織倖のプリンシパルによっお実行されたこずを意味したす。条件は true ず評䟡されたす。これは、2 ぀目の条件も true ず評䟡されれば、RCP が適甚される可胜性がただあるこずを意味したす。 2.リク゚ストは AWS サヌビスからのものか? "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } この条件は、 aws:PrincipalIsAWSService ずいう特別なキヌがリク゚ストに含たれおいるかどうかをテストしたす。このキヌは、眲名されたすべおの API リク゚ストのリク゚ストコンテキストに自動的に挿入され、S3 バケットにむベントを曞き蟌む AWS CloudTrail などの AWS サヌビスからのものである堎合は true に蚭定されたす。このキヌが存圚しない堎合、この条件は true ず評䟡されたす。 存圚する堎合は、ステヌトメントで宣蚀した倀ず比范されたす。ここでは、倀が false ず等しいかどうかをテストしおいたす。等しい堎合は、リク゚ストが AWS サヌビスによっお実行されたものではなく、組織倖の誰かによっお実行された可胜性があるこずを意味するため、 true を返したす。それ以倖の堎合は、 false を返したす。 ぀たり、リク゚ストが組織内のプリンシパルからのものではなく、AWS サヌビスからのものでもない堎合、S3 バケットに察するアクセスは拒吊されたす。 このポリシヌは単なるサンプルであり、独自のビゞネス目暙ずセキュリティ目暙に合わせおカスタマむズすべきです。䟋えば、このポリシヌをカスタマむズしお、ビゞネスパヌトナヌによるアクセスを蚱可したり、AWS サヌビスに察するアクセスを制限しお、パヌトナヌがお客様に代わっおのみリ゜ヌスにアクセスできるようにしたりするこずができたす。詳现に぀いおは、「 Establishing a data perimeter on AWS: Allow only trusted identities to access company data 」をご芧ください。 RCP のアタッチ RCP をアタッチするプロセスは SCP に䌌おいたす。前述のように、組織のルヌト、OU、たたは組織内の特定の AWS アカりントに RCP をアタッチできたす。 RCP をアタッチした埌、圱響を受ける AWS リ゜ヌスに察するアクセスリク゚ストは RCP 制限に準拠する必芁がありたす。倧芏暡に匷制適甚する前に、アカりント内のリ゜ヌスに察する RCP の圱響を培底的にテストするこずをお勧めしたす。個々のテストアカりントたたはテスト OU に RCP をアタッチするこずから始めるこずができたす。 実際の動䜜 これで RCP を䜜成しおアタッチしたので、実際に機胜しおいる様子を確認する準備ができたした。 デベロッパヌがリ゜ヌスベヌスのポリシヌを組織内の S3 バケットにアタッチし、倖郚アカりントの ID に察しおアクセスを明瀺的に付䞎したず仮定したす。 RCP は、ナヌザヌが RCP で蚱可されおいるよりも蚱容床が高いリ゜ヌスベヌスのポリシヌを保存するこずを劚げたせん。ただし、前述のずおり、RCP は認可プロセスの䞀環ずしお評䟡されるため、倖郚 ID によるリク゚ストはいずれにしおも拒吊されたす。 この倖郚アカりントを䜿甚しおバケットにアクセスを詊みるこずで、これを蚌明できたす。今回は AWS CLI から実行したす。 $ aws s3api get-object —bucket 123124ffeiufskdjfgbwer \ --key sensitivefile.txt \ --region us-east-1 local_file An error occurred (AccessDenied) when calling the GetObject operation: Access Denied 環境内での RCP のデプロむのスケヌル これたで、コン゜ヌルを䜿甚しお RCP を管理する方法に぀いお芋おきたした。ただし、倧芏暡なコントロヌル管理の堎合は、それらを Infrastructure as Code ずしお蚭定するこずを怜蚎し、既存の継続的むンテグレヌションおよび継続的デリバリヌ (CI/CD) パむプラむンずプロセスに統合されるこずを確認すべきです。 AWS Control Tower を䜿甚する堎合は、SCP ベヌスのコントロヌルに加えお RCP ベヌスのコントロヌルをデプロむできたす。䟋えば、AWS Control Tower を䜿甚しお、前述の䟋で䜜成したものず同様の RCP をデプロむし、倖郚プリンシパルが組織内の S3 バケットにアクセスできないようにするこずができたす。これにより、マネヌゞドアカりントのリ゜ヌスに RCP が䞀貫しお適甚され、アクセスコントロヌルガバナンスが倧芏暡に合理化および䞀元化されたす。 さらに、SCP ず同様に、AWS Control Tower は RCP のためにドリフト怜出もサポヌトしおいたす。AWS Control Tower の倖郚で RCP が倉曎たたは削陀された堎合、ドリフトに぀いお通知され、是正のステップが提䟛されたす。 たずめ リ゜ヌスコントロヌルポリシヌ (RCP) は、組織内の AWS リ゜ヌスに䜿甚可胜な最倧の蚱可に察する䞀元管理を提䟛したす。SCP ずずもに、RCP は AWS 環境党䜓で デヌタ境界 を䞀元的に確立し、意図しないアクセスを倧芏暡に防ぐのに圹立ちたす。SCP ず RCP は独立したコントロヌルであり、異なる䞀連のセキュリティ目暙を達成するこずを可胜にしたす。SCP たたは RCP のみを有効にするか、たたは䞡方のポリシヌタむプを䜵甚しお、倚局防埡セキュリティモデルの䞀郚ずしお包括的なセキュリティベヌスラむンを確立するかを遞択できたす。 詳现に぀いおは、「 AWS Organizations ナヌザヌガむド 」の「Resource control policies (RCPs)」をご芧ください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。
私は数幎前から AWS BuilderCards の進歩を芋おきたした。あらゆるスキルレベルのプレむダヌがこのカヌドを䜿甚しお、楜しく興味をそそる方法で AWS に぀いお孊び、カヌドを組み合わせおアヌキテクチャを圢成しようず (友奜的に) 競い合い、プレむしながら知識を埗おポむントを獲埗しおいたす。 これたでに 15,000 セット以䞊の BuilderCards が印刷され、3 回の re:Invent、15 回の AWS Summit、耇数のコミュニティむベントで䜿甚されおいたす。䟋えば、 JAWS Days 2024 の期間䞭、東京で楜しい時間を過ごしおいる AWS 愛奜家グルヌプの写真をご芧ください。 プレむダヌからのフィヌドバックは非垞に奜意的で、1,500 件以䞊の返信においお星 4.8 の顧客満足床スコア (CSAT) を獲埗しおいたす。 第 2 ゚ディションの発売開始 AWS BuilderCards の第 2 ゚ディションが re:Invent 2024 で配垃され、たもなくオンラむンでも賌入できるようになるずお知らせできるこずを嬉しく思いたす。第 1 ゚ディションぞのフィヌドバックに応えお、第 2 ゚ディションに倚くの倉曎を加えたした。抂芁は次のずおりです。 デザむン – 倉曎埌のデザむンでは、カヌドの内容に重点を眮き、カヌドをより魅力的で遊び心のあるものにするために、グラデヌションやパタヌンが远加されおいたす。フォントサむズが倧きくなり、ゲヌム゚フェクトがアむコンずしお衚瀺されるようになり、QR コヌドが BuilderCards サむトを指すようになりたした。 ゲヌムの仕組み – 仕組みが芋盎され、バランスの改善、プレむの簡玠化、䞀郚のバむアスの排陀が行われたした。䞀般的なオンプレミスデヌタセンタヌ環境を衚すスタヌタヌカヌドもいく぀かありたす。 生成 AI アドオンパック – この新しいデッキには、生成 AI ず AWS アヌキテクチャが連携する方法を瀺すために蚭蚈された、50 枚の BuilderCards が远加されおいたす。このアドオンパックには、ミッションカヌドのセットも含たれおいたす。これらのカヌドは、公開されおいるベストプラクティスや゜リュヌションにリンクする QR コヌドを䜿甚しお、コンテキストを远加したす。カヌドはより倧きくなり、テキストずアヌキテクチャ図が远加されたした。䜿甚は任意で、プレむダヌはミッションを完了するず远加ポむントを獲埗できたす。各デッキには、カスタマむズに圹立぀空癜の BuilderCards が 5 枚ず空癜のミッションカヌドが 2 枚含たれおいたす。 BuilderCards を入手 re:Invent 2024 に参加する予定なら、Caesar’s Forum の 1 階にある PeerTalk ゚リアの隣の BuilderCards プレむ゚リアを蚪れおください。 日曜日 – 午前 10 時午埌 6 時 月曜日 – 午前 9 時午埌 5 時 火曜日 – 午前 9 時午埌 5 時 氎曜日 – 午前 9 時午埌 5 時 朚曜日 – 午前 9 時午埌 4 時 re:Invent の他の参加者ず察戊したり、自分のゲヌムパックやアドオンパックを入手しお持ち垰ったりするこずができたす (1 日あたり 1,000 個をプレれントいたしたす)。 山口正埳 氏 (AWS ヒヌロヌ) ず 抎本航介 氏 (AWS コミュニティビルダヌ) の努力のおかげで、その堎でプレむできる日本語の BuilderCards もご甚意したす。翻蚳プロセスの詳现に぀いおは、抎本氏のブログ蚘事 ( AWS BuilderCards Japanese Edition for JAWS DAYS ) をご芧ください。 re:Invent に参加できない堎合でも、すぐに自分のデッキを賌入できるようになりたす。詳现に぀いおは、ここに戻っおご確認ください! ご期埅ください BuilderCards チヌムは、拡匵パックや远加の蚀語パックなど、その他の特兞の開発に取り組んでいたす。 – Jeff ; 原文は こちら です。
AWS ニュヌスブログは 20 呚幎を迎えたした ! 2004 幎 11 月 9 日、Jeff Barr は 初めおのブログ蚘事 を公開したした。圓初、圌は TypePad を䜿甚しお個人のブログサむトを開蚭したした。䌚瀟やチヌムではなく、自分の個人的な声を読者に届けたかったのです。 2014 幎 4 月 29 日、圓瀟は 新しい AWS ブログサむト を䜜成し、すべおの投皿をそのペヌゞに移行したした。珟圚、AWS ニュヌスブログには 4,300 件を超える投皿があり、そのうちの 3,200 件以䞊が Jeff による投皿です。 2016 幎 12 月以降、AWS ニュヌスブログには新しいラむタヌが远加されたしたが、匕き続き、初日に打ち立おられた AWS ニュヌスブロガヌ向けの Jeff のリヌダヌシップ・プリンシプル に沿っお掻動しおいたす。AWS ニュヌスブログのナニヌクな点は、ブログ䜜成者が Customer Obsession (顧客第䞀䞻矩) のリヌダヌシップ・プリンシプルに沿っお補品チヌムの機胜を事前に利甚しおいるこず、そしお Frugality (倹玄) のプリンシパルに埓っお、お客様がそれらをすばやく䜿甚しお時間を節玄する方法のりォヌクスルヌに焊点を圓おおいるこずです。 過去 20 幎間、Jeff が果たしおきた基本的か぀極めお重芁な圹割にずおも感謝しおいたす。たた、これからの 20 幎を楜しみにしおいたす! 11 月 4 日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 Amazon MSK 向けの新しい Express ブロヌカヌ – Express ブロヌカヌは Amazon MSK Provisioned の新しいブロヌカヌタむプで、暙準の Apache Kafka ブロヌカヌず比范しお、ブロヌカヌあたりのスルヌプットが最倧 3 倍向䞊し、スケヌルが最倧 20 倍速くなり、回埩時間が 90% 短瞮されるように蚭蚈されおいたす。Express ブロヌカヌには、デフォルトで Kafka のベストプラクティスが事前蚭定されおおり、すべおの Kafka API をサポヌトし、同じ䜎レむテンシヌパフォヌマンスを提䟛するため、既存のクラむアントアプリケヌションを倉曎するこずなく匕き続き䜿甚できたす。 新しい Amazon Kinesis Client Library 3.0 – Kinesis Client Library (KCL) 3.0 では、ストリヌミングデヌタを凊理するためのコンピュヌティングコストを、以前の KCL バヌゞョンず比范しお最倧 33% 削枛できるようになりたした。KCL 3.0 では、ストリヌム凊理ワヌカヌのリ゜ヌス䜿甚率を継続的にモニタリングし、過床に䜿甚しおいるワヌカヌから十分に䜿甚されおいない他のワヌカヌにロヌドを自動的に再配分する、匷化されたロヌドバランシングアルゎリズムが導入されおいたす。詳现に぀いおは、 AWS ビッグデヌタブログの蚘事 をご芧ください。 Amazon EC2 での Microsoft Windows Server 2025 むメヌゞ – License Included (LI) Amazon マシンむメヌゞ (AMI) で Microsoft Windows Server 2025 のサポヌトを開始したした。これにより、Windows Server の最新バヌゞョンを簡単か぀柔軟に起動する方法をお客様に提䟛できるようになりたした。 Amazon EC2 で Windows Server 2025 を実行するこずにより、お客様は Windows Server の最新機胜を䜿甚しお AWS のセキュリティ、パフォヌマンス、信頌性を掻甚できたす。Amazon EC2 で Windows Server 2025 を実行する方法の詳现に぀いおは、「 AWS での Windows ワヌクロヌド 」を参照しおください。 Amazon Bedrock での Anthropic の Claude 3.5 Haiku モデル – Claude 3.5 Haiku は、Anthropic の最速モデルの次䞖代であり 、 迅速な応答時間ず改善された掚論機胜を兌ね備えおいるため、スピヌドずむンテリゞェンスの䞡方を必芁ずするタスクに適しおいたす。Claude 3.5 Haiku はあらゆるスキルセットで向䞊しおおり、コヌディングを含む倚くのむンテリゞェンスベンチマヌクで、Anthropic の前䞖代か぀最倧のモデルである Claude 3 Opus をも䞊回っおいたす。詳现に぀いおは、 AWS ニュヌスブログの蚘事 をお読みください。 Amazon Bedrock Prompt Management GA – Amazon Bedrock Prompt Management で、プロンプトの䜜成、テスト、バヌゞョニング、共有を簡玠化できたす。䞀般公開時に、プロンプトを蚭定し、生成 AI アプリケヌションでそれらを呌び出すための拡匵オプションを提䟛する新機胜を远加したした。これには構造化プロンプトや、Converse ず InvokeModel API の統合などが含たれたす。詳现に぀いおは、 AWS 機械孊習のブログ蚘事 をご芧ください。 Amazon Polly 向けの 6 ぀の新しい合成型生成音声 – 生成゚ンゞンは、生成 AI テクノロゞヌを掻甚した Amazon Polly の最も高床な音声合成 (TTS) モデルです。Ayanda (南アフリカ英語)、Léa (フランス語)、Lucia (ペヌロッパスペむン語)、Lupe (アメリカスペむン語)、Mía (メキシコスペむン語)、Vicki (ドむツ語) の 6 ぀の合成型生成音声 (女性) を新たに远加したした。これにより、13 の声ず 9 ぀のロケヌルが拡匵され、衚珟力豊かで魅力的な声の遞択肢が増えたした。 Amazon OpenSearch Service 延長サポヌト – 埓来の Elasticsearch バヌゞョンず OpenSearch バヌゞョンの暙準サポヌトおよび延長サポヌトのタむムラむンの終了をお知らせしたす。6.7 たでのレガシヌ Elasticsearch バヌゞョン、7.1〜7.8 たでの Elasticsearch バヌゞョン、1.0〜1.2 たでの OpenSearch バヌゞョン、2.3〜2.9 たでの OpenSearch バヌゞョンの暙準サポヌトは、2025 幎 11 月 7 日に終了したす。延長サポヌトでは、通垞のむンスタンス料金に重ねお段階的な定額料金を支払うこずで、暙準サポヌトの終了埌も重芁なセキュリティアップデヌトを匕き続き受けるこずができたす。詳现に぀いおは、 AWS ビッグデヌタブログの蚘事 をご芧ください。 AWS からの発衚の完党なリストに぀いおは、「AWS の最新情報」ペヌゞを定期的にご確認ください。 AWS のその他のニュヌス 興味深い他のニュヌス項目をいく぀かご玹介したす。 CEO の AWS デヌタセンタヌ蚪問 – AWS の CEO である Matt Garman は先日、匊瀟の AWS デヌタセンタヌの 1 ぀を蚪問しお玠晎らしい時間を過ごし、チヌムによっおもたらされる継続的なむノベヌションを確認するこずができたした。もちろん、Amazon の䞊玚幹郚がフルフィルメントセンタヌ、コンタクトセンタヌ、デヌタセンタヌを蚪れ、お客様のために䜜業を行うのは圓然のこずです。AWS デヌタセンタヌは、あらゆる面でお客様向けに蚭蚈されおおり、最倧の回埩力、パフォヌマンス、゚ネルギヌ効率を実珟したす。 AWS は、AWS デヌタセンタヌの近くで䞭小䌁業の支揎、雇甚の創出、持続可胜性に関する取り組みの立ち䞊げ、教育プログラムの開発を行っおいたす。最新情報を入手 – コミュニティでの AWS: About Amazon News では、米囜䞭のデヌタセンタヌの近くで起きおいるこずをご玹介したす 。 Amazon での Amazon Q Business – 以前、ずある Amazon ストヌリヌをご玹介 したした。 Amazon Q Developer のコヌド倉換を䜿甚しお、 30,000 件以䞊の叀い Java アプリケヌションを Java 17 バヌゞョンに移行 したずいうものです。最新バヌゞョンの Java に移行したこずで、以前の手動䜜業に比べお 4,500 幎分以䞊もの開発者の劎力が削枛され、同瀟は幎間 2 億 6,000 侇 USD を節玄したした。 今日ご玹介するのは、 Amazon での Amazon Q Business のもう 1 ぀のドッグフヌディングのストヌリヌ です。Amazon は Amazon Q Business ず共同で瀟内チャットボットを構築し、Amazon の開発者から寄せられた 100 䞇件を超える質問を解決したした。これにより、手䜜業による技術調査に費やす時間を 45 䞇時間以䞊削枛できたした。 私たちのチヌムは、䜕癟䞇もの内郚文曞を䜿っお Amazon Q Business をオンボヌディングし、チヌムが毎日䜿甚するツヌルに Q Business を統合したした。開発者は、Q&A 掲瀺板や Slack チャンネルで、耇雑な技術的質問ぞの回答を䜕時間も埅぀のではなく、数秒で埗られるようになりたした。 PGA TOUR の TOURCast – ゎルフがお奜きなら、このニュヌスに興味があるはずです。 PGA TOUR は、 TOURCast を日本の 2024 ZOZO CHAMPIONSHIP でデビュヌさせたした。これは、 CDW を利甚した ShotLink ず呌ばれる新しいスコアリングシステムに基づいお、より良い統蚈デヌタを収集しお広め、ファンずゲヌムずの距離を近づけるためです。PGA TOUR がこのテクノロゞヌをアゞアに持ち蟌み、AWS の柔軟性ずスケヌラビリティを掻甚しお独自の課題を克服したのはこれが初めおです。 PGA TOUR のボランティアが ZOZO CHAMPIONSHIP のフェアりェむに、特定のショットデヌタを入力しお Shotlink Select Plus にフィヌドバックする GPS 機噚を蚭眮しおいるずころ。[画像: PGA TOUR] 同瀟は過去 2 幎間で、新しいクラりドスタックにスコアリングシステムを完党に再構築したした。AWS クラりドでは、ハむテクレヌダヌシステム、カメラ、手動入力のいずれから送信されるデヌタであっおも、システムがすべおシヌムレスに凊理したす。 今埌の AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS GenAI Lofts – AWS GenAI Lofts は、テクノロゞヌを玹介するだけに留たらず、スタヌトアップ、開発者、投資者、業界゚キスパヌトが䞀堂に集たっお亀流する堎も提䟛したす。深いむンサむトを埗たい、たたは 生成 AI の専門家から質問の回答を埗たいず考えおいるかにかかわらず、GenAI Loft は皆さんのニヌズに察応し、次のむノベヌションの構築を開始するために必芁な事柄のすべおを提䟛したす。 サンパりロ (11 月 20 日たで) ず パリ (11 月 25 日たで) のむベントに参加したしょう。 AWS Community Day – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌがリヌドするテクニカルディスカッション、ワヌクショップ、ハンズオンラボが盛り蟌たれたコミュニティ䞻導のカンファレンスに参加したしょう。日皋は、 むンドネシア、ゞャカルタ (11 月 23 日)、 むンド、コヌチ (11 月 14 日) です。 AWS re:Invent – 12 月 2〜6 日にラスベガスで開催される毎幎恒䟋の孊習むベントに、匕き続き ご登録 いただけたす。驚くこずに、Amazon の CEO である Andy Jassy は、 今幎も戻っおきお AWS re:Invent に参加するず発蚀したした。圌はこう語っおいたす。「い぀ものように、このむベントを孊習むベントにするこずが最優先事項です。そうすれば、お客様は倧きな成果を取り戻し、自身の顧客䜓隓やビゞネスを倉えるこずができたす。たた、皆様に気に入っおいただけるず考えおいるさたざたなこずを発衚する予定です」 お䌚いできるのを楜しみにしおいたす! 近日開催されるすべおの察面むベントず仮想むベントを閲芧できたす。 11 月 11 日週はここたでです。11 月 18 日週の Weekly Roundup もお楜しみに! – Channy この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚AWS からの興味深いニュヌスやお知らせを簡単にたずめたものを毎週ご玹介したす! 原文は こちら です。
AWS CloudFormation を利甚するこずで、クラりドアプリケヌションのむンフラストラクチャをコヌドずしおモデル化しおプロビゞョニングするこずが容易になりたす。 CloudFormation テンプレヌトは盎接 JSON たたは YAML で蚘述できるだけでなく、 AWS Cloud Development Kit (CDK) などのツヌルで生成するこずもできたす。これらのテンプレヌトが CloudFormation サヌビスにサブミットされるず、リ゜ヌスはスタックずいう単䜍でたずめられ、䟝存関係を反映した順序でデプロむされたす。スタックむベントの詳现は コン゜ヌル 䞊で衚圢匏で確認できたす。 そしおこの床、より芖芚的で盎感的なむベントのビュヌを提䟛する deployment timeline view ずいう新機胜が登堎したした。この機胜はスタック操䜜で CloudFormation が実行した䞀連のアクションを芖芚化したす。この機胜が提䟛する芖芚的なタむムラむンは、リ゜ヌスがプロビゞョニングされた正確な順序、リ゜ヌス間の䟝存関係、プロビゞョニングにかかった時間を瀺したす。デプロむが倱敗した際は根本原因ず考えられる箇所を瀺したす。デプロむの舞台裏で起きおいるこずに぀いおの远加コンテキストず可芖性を提䟛するこずで既存の衚圢匏のビュヌを補完したす。 図 1: CloudFormation deployment timeline view の機胜の抂芁 どのように動䜜するか 新機胜の deployment timeline view を利甚するために必芁なのは、スタックの䜜成、曎新、削陀の操䜜だけです。AWS CloudFormation コン゜ヌルで Events タブを遞択し、Table view の暪にある Timeline view タブをクリックしたす。 CloudFormation がテンプレヌトで定矩されたリ゜ヌスのプロビゞョニングを開始するず、各リ゜ヌス操䜜がタむムラむンビュヌで棒線ずしお衚瀺されたす。 リ゜ヌスは、最新の操䜜があったリ゜ヌスが䞀番䞊になるように時系列順に垂盎に積み䞊げらたす。各リ゜ヌスアクションは、それぞれのアクションに応じお色分けされた氎平の棒で芖芚化されたす。 ダヌクモヌドではロヌルバック䞭ずロヌルバック完了のスむッチの色が切り替わる バヌの䞊にカヌ゜ルを移動させるず、完党なリ゜ヌス名やリ゜ヌス操䜜の開始/終了時刻など詳现な情報が衚瀺されたす。 デプロむが倱敗した堎合は、CloudFormation は倱敗の原因ず考えられるリ゜ヌス操䜜のバヌを赀癜の瞞暡様で匷調衚瀺したす。このバヌにカヌ゜ルを移動するず、具䜓的な倱敗理由が衚瀺されたす。 シンプルなスタックを䜜成する CloudFormation コン゜ヌルを䜿甚しおシンプルなスタックを䜜成したす。デプロむを開始しお芖芚的なタむムラむンビュヌを確認したす。 1. CloudFormation コン゜ヌルから、 Create stack をクリックし、 with new resources を遞択したす。 図 2: CloudFormation コン゜ヌルの create stack ボタン 2. スタック䜜成りィザヌドで Choose an existing template をクリックし Upload a template file を遞択したす。 Choose file をクリックしデプロむするスタックのテンプレヌトファむルを遞択しおアップロヌドしたす。この蚘事では、 こちら で提䟛されおいるテンプレヌトを䜿甚したす。このテンプレヌトをダりンロヌドしお䜿甚するほかに、独自のテンプレヌトを䜿甚するこずもできたす。独自のテンプレヌトを䜿甚した堎合はタむムラむンビュヌの内容がこの蚘事ずは異なるものになりたす。 (翻蚳者補足: ここで玹介されおいるテンプレヌトはオレゎンリヌゞョンでのみデプロむに成功したす) 図 3: CloudFormation コン゜ヌルの スタック䜜成りィザヌド アプリケヌションスタックには、Amazon EC2 むンスタンス ( AWS::EC2::Instance )、Amazon VPC ( AWS::EC2::VPC )、およびサブネット ( AWS::EC2::Subnet ) やむンタヌネットゲヌトりェむ ( AWS::EC2::InternetGateway ) などの VPC リ゜ヌスが含たれおいたす。 3. テンプレヌトをアップロヌドしたら Next をクリックし、必芁に応じおスタック名ずパラメヌタを入力したす。 スタックデプロむの埌続の手順を完了させ、スタックの䜜成を開始したす。 4. スタックむベントペヌゞで、 Table view の暪の Timeline view タブをクリックしたす。 CloudFormation が最初に VPC、その埌でサブネット、最埌に EC2 むンスタンスをプロビゞョニングしおいく間の進捗状況をリアルタむムで確認できたす。 図 4: CloudFormation が実行䞭のデプロむのタむムラむンビュヌ 5. タむムラむンは 5 秒ごずに衚瀺をリフレッシュし、デプロむの進捗状況を曎新したす。5 秒埌、次のようなタむムラむンビュヌが衚瀺されたす。 図 5: 5 秒埌に曎新されたタむムラむン 図 6: 完了したデプロむのタむムラむンビュヌ 䞊のタむムラむンでは、CloudFormation によっおプロビゞョニングされたリ゜ヌスを衚すバヌが䞋から䞊に向かっお䞊び、それぞれのリ゜ヌス操䜜が発生した順序やリ゜ヌス間の䟝存関係を読み取るこずができたす。 バヌは操䜜の進行にずもなっお青 (進行䞭)、黄 (敎合性チェック䞭)、緑 (成功)たたは赀 (倱敗) に倉化したす。 図 7: リ゜ヌス詳现ポップオヌバヌ いずれかのバヌにカヌ゜ルを眮くず、各デプロむフェヌズの開始/終了時間や完党なリ゜ヌス名などの詳现が衚瀺されたす。グラフのポップオヌバヌに衚瀺される詳现情報から、CloudFormation が InternetGateway リ゜ヌスを 2 秒で䜜成し、その埌 15 秒埅機しおリ゜ヌスが完党に動䜜しおいるかどうかを確認しおから完了ずしおマヌクしたこずを読み取るこずができたす。このフェヌズをリ゜ヌス敎合性チェックフェヌズ (resource consistency check phase)、たたはリ゜ヌス安定化フェヌズ (resource stabilization phase) ず呌びたす。これによっお CloudFormation をはじめずする Infrastructure as Code (IaC) ツヌルは埩元力のあるデプロむメントを確かなものにするこずができたす。詳しくは CloudFormation optimistic stabilization strategy の蚘事 (日本語翻蚳版は こちら ) をお読みください。 ロヌルバック完了状態のスタック スタックのデプロむが倱敗した堎合、CloudFormation は珟圚のスタック操䜜の前の安定した状態にロヌルバックしたす。 以䞋のタむムラむンビュヌでは、倱敗したスタック操䜜が完党にロヌルバックされた状態で衚瀺されおいたす。 赀ず癜の瞞暡様で匷調衚瀺されおいるリ゜ヌスが根本原因である可胜性が高いので、すぐにトラブルシュヌティングを開始できたす。 図 8: ロヌルバック完了状態のスタックのタむムラむンビュヌ たずめ 新機胜の CloudFormation deployment timeline view では、CloudFormation が Infrastructure as Code のテンプレヌトで定矩されたリ゜ヌスをプロビゞョニングする際のオヌケストレヌションフロヌず䟝存関係を可芖化できるようになりたした。 この芖芚的なタむムラむンビュヌを掻甚するこずで、デプロむメントの倱敗の根本原因を玠早く特定したり、プロビゞョニングプロセスの理解を深めるこずができたす。 この機胜は、珟圚 CloudFormation がサポヌトされおいるすべおの AWS リヌゞョンで利甚可胜です。 ぜひ CloudFormation コン゜ヌルにアクセスし deployment timeline view を䜿っおみおください。 著者玹介: Idriss Laouali Abdou Idriss は AWS のシニアプロダクトマネヌゞャヌであり、AWS IaC のお客様に最高の䜓隓を提䟛するこずに尜力しおいたす。仕事以倖では、䜕千人もの孊生を支揎する教育コンテンツを䜜成したり、料理をしたり、ダンスをしたりしおいたす。 Jamie To Jamie はフロント゚ンド゚ンゞニアであり、過去 3 幎間 AWS IaC のお客様にコン゜ヌル機胜を提䟛しおきたした。仕事以倖では、絵を描いたり、フヌズボヌルをしたりするのが奜きです。 Puran Zhang Puran は 過去 4 幎間フロント゚ンド゚ンゞニアずしお IaC コン゜ヌルに貢献しおきたした。仕事以倖では、キッチンやコヌヒヌバヌにいるずころ、たたは次のレストランぞ急いでいるずころをよく芋かけたす。 本蚘事は 2024/11/11 に投皿された  Peek inside your AWS CloudFormation Deployments with timeline view を翻蚳したものです。翻蚳は Solutions Architect : 囜兌 呚平 (Shuhei Kunikane) が担圓したした。
11 月 8 日、 Amazon Location Service は、 Routes 、 Places 、 Maps 機胜の胜力を拡匵および改善する 17 個の匷化された新たな API をリリヌスしたした。これにより、開発者にずっお総合的か぀効率的な゚クスペリ゚ンスが実珟したす。機胜を匷化し、移行を簡玠化するこれらの曎新により、Amazon Location Service は幅広いアプリケヌションでさらに利甚しやすく、䟿利になりたした。 静的および動的レンダリングオプションを䜿甚しお、高床なルヌト最適化、通行料蚈算、GPS トレヌススナップ、さたざたなマップスタむルにアクセスできるようになりたした。たた、関心のある地点に関する豊富で詳现な情報を利甚しお、近接床ベヌスの怜玢ず予枬提案を実行できるようになりたした。 Amazon のロヌドマップの倧郚分は、お客様からのフィヌドバックに基づいおいたす。Amazon Location Service を䜿甚しおアプリケヌションを構築しおいる倚くのお客様から、䜍眮情報ベヌスのデヌタを扱う際には、専甚の API ず、連絡先情報や営業時間などのより詳现な情報が必芁であるずのご意芋が寄せられおいたす。珟圚の API セットは倚くのお客様に貎重なツヌルを提䟛しおきたしたが、開発者は詳现なルヌトプランニング、近接床ベヌスの怜玢、远加の堎所の詳现、静的マップ画像などの远加機胜を望んでいるず衚明しおいたす。これらの新しい API は開発者の芁求に応え、すぐに䜿甚できるより包括的な䜍眮情報゜リュヌションを提䟛したす。 新機胜ず拡匵機胜 11 月 8 日のリリヌスでは、お客様のフィヌドバックに盎接応える、10 個の曎新された API ず 7 個のたったく新しい API を玹介したす。Routes、Places、Maps の各サヌビスには、より幅広いナヌスケヌスをサポヌトできるように蚭蚈された、特定の機胜匷化が斜されおいたす。 Routes Amazon Location Routes API は、高床なルヌトプランニングずカスタマむズオプションをサポヌトするようになり、ナヌザヌは次のこずができるようになりたした。 CalculateIsolines で、特定の移動時間たたは距離内のサヌビス゚リアを特定する OptimizeWaypoints で最も効率的なりェむポむントの順序を決定し、移動時間たたは距離を最小限に抑える 通行料を蚈算しお、有料道路を含むルヌトの正確なコスト芋積もりを提䟛する SnapToRoads で地点を道路網にスナップするこずで、GPS トレヌスを正確に照合する これらの機胜により、ナヌザヌのためにより正確か぀動的なルヌト゚クスペリ゚ンスを蚭蚈できたす。䟋えば、物流䌚瀟では、ラむブ亀通量を考慮しお配達にかかる亀通費を最小限に抑えながら、ドラむバヌのルヌトをリアルタむムで最適化できたす。 Maps 曎新された Amazon Location Maps API には、熟緎した地図補䜜者によっお䜜成された、甚途に合ったマップスタむルが含たれおいたす。これらのマップスタむルは、垂堎投入たでの時間を短瞮し、カスタムマップ䜜成の必芁性を排陀するプロフェッショナルなデザむンを提䟛したす。さらに、Static Map Image 機胜により、開発者は静的マップをアプリケヌション内で統合できるため、継続的なデヌタストリヌミングの必芁性が削枛され、やりずりが䞍芁なナヌスケヌスでのパフォヌマンスが向䞊したす。 Maps API の䞻な機胜は次のずおりです。 GetTile で X、Y、Z 軞の倀を指定しお、タむルセットからタむルをダりンロヌドする GetStyleDescriptor でスタむルに関する情報を返す GetStaticMap で、レポヌトや芖芚化を目的ずした非むンタラクティブなマップのレンダリングを可胜にする Places Amazon Location Places API の匷化によっお、より詳现な怜玢機胜が実珟され、䜍眮情報デヌタをよりきめ现かいものにしおほしいずいうリク゚ストに察応できるようになりたした。この新機胜には以䞋のものが含たれたす。 SearchNearby ず Autocomplete が近接床ベヌスのク゚リをサポヌトし、予枬倉換機胜を有効にしたこずによる、ナヌザヌ゚クスペリ゚ンスの向䞊 関心のある地点の営業時間、連絡先情報、远加属性などのカテゎリを䜿甚したビゞネス詳现の匷化 これらの機胜は、フヌドデリバリヌサヌビスや小売アプリケヌションなど、ナヌザヌが近くの堎所に関する詳现情報を必芁ずするアプリケヌションで特に圹立ちたす。䟋えば、顧客がフヌドデリバリヌアプリケヌションを開き、 SearchNearby を䜿甚しお近くのレストランを怜玢し、営業時間や連絡先情報などのレストランの詳现を取埗しお空き状況を確認するずしたす。耇数の配達泚文がドラむバヌに割り圓おられるず、アプリケヌションは OptimizeWaypoints を䜿甚しお、最も効率的な集荷および配達のルヌトを提案したす。ドラむバヌがルヌトをたどるず、 SnaptoRoads がドラむバヌの䜍眮を正確に芖芚化し、顧客によるリアルタむムの远跡䜓隓を向䞊したす。 Enhanced Location Service の実行 API の呌び出しは簡単です。 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、圓瀟の AWS SDK のいずれか、たたはプレヌンな REST API を䜿甚できたす。ただし、りェブアプリたたはモバむルアプリのマップに情報を衚瀺するには、远加の蚭定が必芁です。このプロセスは詳しく説明されおいたすが、非垞に詳现であるため、ここにすべお蚘茉するこずはできたせん。このデモでは、API の䜿甚に焊点を圓おたす。 Amazon Location Service では、API コヌルを AWS API 認蚌 ( AWS Sigv4 認蚌 ) たたは API キヌを介する方法の 2 ぀の方法で認蚌できたす。API キヌは、゚ンドナヌザヌが認蚌されおいないモバむルアプリケヌションの開発者にずっお、たたは Amazon Cognito ずの統合が䞍可胜な堎合に䟿利です。これはフロント゚ンドアプリケヌションに掚奚される認蚌方法です。 API の倚様性ず、アプリケヌション内での統合がいかに簡単かを瀺すために、デモの各ステップで AWS CLI、cURL、グラフィカル REST API クラむアントを組み合わせお䜿甚したす。 ステップ 1: API キヌの䜜成 たず、AWS CLI を䜿甚しおアプリケヌションの API キヌを䜜成したす。 AWS マネゞメントコン゜ヌル で API キヌを管理するこずもできたす。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドによっお API キヌが生成され、これを䜿甚しお Amazon Location API を呌び出すこずができたす。 ステップ 2: 地理座暙の取埗 次に、 cURL を䜿甚しお GeoCode を呌び出し、 QueryText パラメヌタに䜏所を枡すこずで、フランスのリヌル䞭心郚の地理座暙 ( 経床 ず 緯床 ) を取埗したす。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これにより、垂内䞭心郚の GPS 座暙 [3.06361, 50.63706] を含む耇数のデヌタポむントが返されたす。 ステップ 3: 近くの堎所の怜玢 取埗した座暙を䜿甚しながら、REST API クラむアントツヌルを利甚しお SearchNearby API を呌び出し、リヌル䞭心郚呚蟺の興味深い堎所を芋぀けたす。 画面の右偎に、API レスポンスが衚瀺されたす。レストラン、銀行、駐車堎などの近くの堎所のリストです。カテゎリを指定したり、怜玢範囲を制限したりするこずで、さらに怜玢を絞り蟌めたす。 SearchNearby API では、バりンディングボックス内の怜玢を制限したり、ビゞネスチェヌン、カテゎリ、囜、食品の皮類を含めたり陀倖したりするのに圹立぀、オプションの Filter パラメヌタを䜿甚できたす。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近くの関心のある堎所を怜玢したずころ、返された結果の 1 ぀は、囜際的に有名なマクドナルドでした 。 ステップ 4: 道順の取埗 最埌に、AWS CLI を䜿甚しお 2 ぀の垂内䞭心郚 (ベルギヌの ブリュッセル ずフランスの リヌル ) 間のルヌトを蚈算したす。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" レスポンスには、マップ䞊にパスをレンダリングするための ポリラむン ず、ルヌト案内のステップバむステップリストが含たれたす。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ 5: マップでの道順の衚瀺 マップ䞊のルヌトを芖芚化するには、りェブアプリケヌションやモバむルアプリケヌションでマップを衚瀺するためのレンダリング゚ンゞンである MapLibre ラむブラリを䜿甚したす。 Amazon Location Service デベロッパヌガむド の手順に沿っお、ルヌトを衚瀺する基本的なアプリを䜜成したした。 MapLibre に加えお、 AWS Amplify を䜿甚しおアプリケヌションに Amazon Location デヌタを統合しお衚瀺するこずもできたす。 開始方法 これらの新芏および曎新された API を䜿甚しお、Amazon Location Service はお客様のビゞネスニヌズに応える、より包括的なマッピングおよびロケヌションデヌタのスむヌトを提䟛したす。これにより、開発者の俊敏性ずスケヌラビリティが向䞊し、開発ラむフサむクルが加速されたす。 はじめに、曎新された Amazon Location Service デベロッパヌガむド を確認し、今すぐこれらの機胜の統合を開始しおください。 Amazon Location Service ペヌゞ にアクセスしお詳现を確認したり、お気に入りの AWS SDK で API を詊しお、アプリケヌションをどのように匷化できるかを確認したりするこずもできたす。 — seb 原文は こちら です。
11 月 7 日、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の新しいブロヌカヌタむプである゚クスプレスブロヌカヌの䞀般提䟛に぀いお発衚したす。Apache Kafka を実行しおいる暙準ブロヌカヌず比范しお、ブロヌカヌあたりのスルヌプットが最倧 3 倍向䞊し、スケヌルが最倧 20 倍速くなり、埩旧時間が 90% 短瞮されるように蚭蚈されおいたす。゚クスプレスブロヌカヌには、デフォルトで Kafka のベストプラクティスが事前蚭定されおおり、Kafka API をサポヌトし、Amazon MSK のお客様が期埅するのず同じ䜎レむテンシヌパフォヌマンスを提䟛するため、既存のクラむアントアプリケヌションを倉曎するこずなく匕き続き䜿甚できたす。 ゚クスプレスブロヌカヌを䜿甚するず、Amazon MSK でプロビゞョニングされたクラスタヌを䜿甚する際に、Kafka アプリケヌションのコンピュヌティングずストレヌゞの䌞瞮性が向䞊したす。Amazon MSK は、Apache Kafka をベヌスにした可甚性が高くスケヌラブルなアプリケヌションを簡単に構築しお実行できる、フルマネヌゞド型の AWS サヌビスです。 ゚クスプレスブロヌカヌが持぀䞻な機胜ず、享受できる利点に぀いお詳しく芋おいきたしょう。 ハンズフリヌストレヌゞ管理による運甚の簡略化 – ゚クスプレスブロヌカヌは、事前プロビゞョニングなしで無制限のストレヌゞを提䟛し、ディスク関連のボトルネックを解消したす。クラスタヌのサむズ蚭定はより単玔で、必芁なのは入力ず出力のスルヌプットをブロヌカヌごずの掚奚スルヌプットで割ったものです。これにより、プロアクティブなディスク容量の監芖ずスケヌリングが䞍芁になり、クラスタヌ管理が簡玠化され、朜圚的な障害の原因が排陀されるこずで耐障害性が向䞊したす。 ブロヌカヌの数が少なく、ブロヌカヌあたりのスルヌプットは最倧 3 倍 – ブロヌカヌあたりのスルヌプットが高いほど、同じワヌクロヌドでクラスタヌを小さくできたす。暙準ブロヌカヌのスルヌプットはクラむアントトラフィックずバックグラりンド操䜜を考慮に入れる必芁がありたす。 m7g.16xl の暙準ブロヌカヌは 154 MBps の入力を安党に凊理したす。゚クスプレスブロヌカヌは独自の蚭定ずリ゜ヌス分離を採甚しおいるため、 m7g.16xl サむズのむンスタンスでは、クラスタヌむベント䞭にパフォヌマンスや可甚性を損なうこずなく、最倧 500 MBps の入力を安党に管理できたす。 20 倍の高速スケヌリングによる高い䜿甚率 – ゚クスプレスブロヌカヌはスケヌリング䞭のデヌタ移動を枛らし、暙準ブロヌカヌの最倧 20 倍の速床を実珟したす。これにより、より迅速で信頌性の高いクラスタヌサむズ蚭定が可胜になりたす。各ブロヌカヌの入力スルヌプットキャパシティを監芖し、数分以内にブロヌカヌを远加できるため、トラフィックの急増を芋越しおオヌバヌプロビゞョニングを行う必芁がなくなりたす。 耐障害性が高く、埩旧速床が 90% 向䞊 – ゚クスプレスブロヌカヌは、高い耐障害性を必芁ずするミッションクリティカルなアプリケヌション向けに蚭蚈されおいたす。蚭定ミスによる障害を枛らす 3 ぀の方法のレプリケヌション (RF=3) など、ベストプラクティスがデフォルトであらかじめ蚭定されおいたす。たた、゚クスプレスブロヌカヌは、暙準の Apache Kafka ブロヌカヌず比范しお、䞀時的な障害からの埩旧が 90% 速くなりたす。゚クスプレスブロヌカヌの再調敎ず埩旧は、最小限のクラスタヌリ゜ヌスしか䜿甚しないため、キャパシティプランニングが簡玠化されたす。これにより、リ゜ヌス䜿甚率が高たるリスクがなくなり、クラスタヌのサむズを適正化する際に継続的に監芖する必芁がなくなりたす。 Amazon MSK では、次のように、ワヌクロヌドず奜みに応じおオプションを遞択できたす。 MSK プロビゞョンド MSK Serverless 暙準ブロヌカヌ ゚クスプレスブロヌカヌ 蚭定範囲 柔軟性が最も高い 柔軟 柔軟性が最も䜎い クラスタヌの再調敎 カスタマヌマネヌゞド カスタマヌマネヌゞド ただし、最倧で 20 倍速く MSK マネヌゞド 容量管理 はい はい (コンピュヌティングのみ) なし ストレヌゞ管理 はい なし なし ゚クスプレスブロヌカヌは、コストを削枛し、耐障害性を高め、運甚䞊のオヌバヌヘッドを抑えるこずができるため、すべおの Kafka ワヌクロヌドに最適な遞択肢ずなっおいたす。容量、蚭定、スケヌル方法の偎面を䞀切管理せずに Kafka を䜿甚したい堎合は、 Amazon MSK Serverless を遞択できたす。これにより、完党に抜象化された Apache Kafka ゚クスペリ゚ンスが提䟛され、むンフラストラクチャの管理が䞍芁になり、自動的にスケヌルされ、リ゜ヌス利甚を最適化する必芁のない埓量制料金の消費モデルで請求されたす。 Amazon MSK の゚クスプレスブロヌカヌの開始方法 ゚クスプレスブロヌカヌを䜿い始めるには、Amazon MSK が提䟛する サむズ蚭定ず料金のワヌクシヌト を䜿甚できたす。このワヌクシヌトは、ワヌクロヌドに察応するために必芁なクラスタヌサむズを芋積もるのに圹立ちたす。たた、発生する月次総コストのおおよその芋積もりも埗られたす。 ワヌクロヌドのスルヌプット芁件は、クラスタヌのサむズを決定する䞻な芁因です。クラスタヌに必芁なブロヌカヌのサむズず数を決定するには、パヌティションや接続数などの他の芁玠も考慮する必芁がありたす。䟋えば、ストリヌミングアプリケヌションで 30 MBps のデヌタ入力 (曞き蟌み) ず 80 MBps のデヌタ出力 (読み取り) の容量が必芁な堎合は、3 ぀の express.m7g.large ブロヌカヌを䜿甚しおスルヌプットのニヌズを満たすこずができたす (ワヌクロヌドのパヌティション数が、Amazon MSK が m7g.large むンスタンスに掚奚するパヌティションの最倧数以内であるこずを前提ずしたす)。 次の衚は、持続可胜で安党な運甚のための、むンスタンスサむズあたりの掚奚最倧入力数、出力数、およびパヌティション数を瀺しおいたす。これらの掚奚事項の詳现に぀いおは、Amazon MSK デベロッパヌガむドの ベストプラクティス セクションをご芧ください。 むンスタンスサむズ 入力 (MBps) 出力 (MBps) express.m7g.large 15.6 31.2 express.m7g.4xlarge 124.9 249.8 express.m7g.16xlarge 500.0 1000.0 ワヌクロヌドに必芁な゚クスプレスブロヌカヌの数ずサむズを決定したら、 AWS マネゞメントコン゜ヌル に移動するか、 CreateCluster API を䜿甚しお Amazon MSK でプロビゞョニングされたクラスタヌを䜜成したす。 Amazon MSK コン゜ヌル で新しいクラスタヌを䜜成するずきに、 [Broker type] (ブロヌカヌタむプ) オプションで [Express brokers] (゚クスプレスブロヌカヌ) を遞択し、そのブロヌカヌに察しおプロビゞョニングするコンピュヌティング容量の量を遞択したす。スクリヌンショットでわかるように、゚クスプレスブロヌカヌには Apache Kafka 3.6.0 バヌゞョンず Graviton ベヌスのむンスタンスを䜿甚できたす。゚クスプレスブロヌカヌのストレヌゞを事前にプロビゞョニングする必芁はありたせん。 たた、これらの蚭定の䞀郚をカスタマむズしお、奜みに応じおクラスタヌのパフォヌマンスをさらにファむンチュヌニングするこずもできたす。詳现に぀いおは、Amazon MSK デベロッパヌガむドの「 ゚クスプレスブロヌカヌの蚭定 」を参照しおください。 AWS コマンドラむンむンタヌフェむス (AWS CLI) で MSK クラスタヌを䜜成するには、 create-cluster コマンドを䜿甚したす。 aws kafka create-cluster \ --cluster-name "channy-express-cluster" \ --kafka-version "3.6.0" \ --number-of-broker-nodes 3 \ --broker-node-group-info file://brokernodegroupinfo.json brokernodegroupinfo.json ずいう名前の JSON ファむルには、Amazon MSK にブロヌカヌノヌドを分散させたい 3 ぀のサブネットを指定したす。 { "InstanceType": "express.m7g.large", "BrokerAZDistribution": "DEFAULT", "ClientSubnets": [ "subnet-0123456789111abcd", "subnet-0123456789222abcd", "subnet-0123456789333abcd" ] } クラスタヌが䜜成されるず、ブヌトストラップ接続文字列を䜿甚しおクラむアントをクラスタヌ゚ンドポむントに接続できたす。 ゚クスプレスブロヌカヌを䜿甚するず、垂盎方向にスケヌル (むンスタンスサむズを倉曎) たたは氎平方向にスケヌル (ブロヌカヌを远加) できたす。垂盎スケヌリングにより、パヌティションを再割り圓おしなくおもスルヌプットが 2 倍になりたす。氎平スケヌリングではブロヌカヌが 3 ぀セットで远加され、さらに倚くのパヌティションを䜜成できたすが、新しいブロヌカヌがトラフィックを凊理するにはパヌティションを再割り圓おする必芁がありたす。 ゚クスプレスブロヌカヌの䞻な利点は、数分以内にブロヌカヌを远加しおパヌティションを再調敎できるこずです。䞀方、暙準ブロヌカヌを远加した埌のパヌティションの再調敎には数時間かかるこずがありたす。以䞋のグラフは、クラスタヌに 3 ぀の゚クスプレスブロヌカヌを远加し、各新しいブロヌカヌに 2000 個のパヌティションを再割り圓おした埌に、パヌティションの再調敎にかかった時間を瀺しおいたす。 ご芧のように、これらのパヌティションを再割り圓おしお新しいブロヌカヌの远加容量を掻甚するのに玄 10 分かかりたした。暙準ブロヌカヌで構成される同等のクラスタヌで同じ実隓を行ったずころ、パヌティションの再割り圓おには 24 時間以䞊かかりたした。 パヌティションの再割り圓おの詳现に぀いおは、Apache Kafka ドキュメントの「 クラスタヌの拡匵 」を参照しおください。 知っおおくべきこず ゚クスプレスブロヌカヌに぀いお知っおおくべきこずは次のずおりです。 デヌタ移行 – Amazon MSK Replicator を䜿甚しお、既存の Kafka たたは MSK クラスタヌのデヌタを゚クスプレスブロヌカヌで構成されるクラスタヌに移行できたす。これにより、クラスタヌのデヌタずメタデヌタの䞡方が新しいクラスタヌにコピヌされたす。 モニタリング – クラスタヌ内の゚クスプレスブロヌカヌで構成されるクラスタヌを Amazon CloudWatch メトリクスを䜿甚しおブロヌカヌレベルでモニタリングできたす。たた、Prometheus によるオヌプンモニタリングを有効にしお、JMX ゚クスポヌタヌずノヌド゚クスポヌタヌを䜿甚しおメトリクスを公開できたす。 セキュリティ – 他のブロヌカヌタむプず同様に、Amazon MSK は AWS Key Management Service (AWS KMS) ず統合しお、゚クスプレスブロヌカヌのストレヌゞを透過的にサヌバヌ偎で暗号化したす。゚クスプレスブロヌカヌを䜿甚しお MSK クラスタヌを䜜成するずきに、Amazon MSK が保管䞭のデヌタの暗号化に䜿甚する AWS KMS キヌを指定できたす。KMS キヌを指定しない堎合、Amazon MSK が AWS マネヌゞドキヌを䜜成し、ナヌザヌに代わっお䜿甚したす。 今すぐご利甚いただけたす ゚クスプレスブロヌカヌタむプは、11 月 7 日より米囜東郚 (オハむオ)、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アむルランド)、欧州 (ストックホルム) の各リヌゞョンでご利甚いただけたす。 ゚クスプレスブロヌカヌの Apache Kafka ブロヌカヌむンスタンスの䜿甚に察しお時間単䜍の料金 (1 秒単䜍で請求) が発生したす。手数料は、MSK クラスタヌ内のブロヌカヌむンスタンスずアクティブなブロヌカヌの芏暡によっお異なりたす。たた、゚クスプレスブロヌカヌに曞き蟌たれるデヌタの GB 単䜍の料金 (バむト単䜍の解像床で請求) もお支払いいただきたす。詳现に぀いおは、「 Amazon MSK の料金 」ペヌゞにアクセスしおください。 Amazon MSK コン゜ヌル で Amazon MSK の゚クスプレスブロヌカヌをお詊しください。詳现に぀いおは、 Amazon MSK デベロッパヌガむド をご芧ください。たた、 AWS re:Post for Amazon MSK 宛おに、たたは通垞の AWS サポヌトの連絡先を通じお、ぜひフィヌドバックをお寄せください。 – Channy 原文は こちら です。
(本蚘事は 2024/11/06 に投皿された How チャネルコヌポレヌション modernized their architecture with Amazon DynamoDB, Part 2: Streams を翻蚳した蚘事です。) この蚘事は、チャネルコヌポレヌションの TaeHun Yoon ず Changsoon Kim ず共同で執筆されたした。 チャネルコヌポレヌション は、 B2B ゜フトりェア・アズ・ア・サヌビス SaaS スタヌトアップ䌁業で、オヌルむンワン AI メッセンゞャヌ「 チャネルトヌク 」を運営しおいたす。このシリヌズの 第1郚 では、 NoSQL 採甚の動機、ビゞネス成長に䌎う技術的問題、そしお PostgreSQL から Amazon DynamoDB ぞの移行に関する考慮事項に぀いお玹介したした。この投皿では、 DynamoDB だけでは察凊できなかった郚分を解決するために、他のサヌビスず統合した経隓を共有したす。 背景構造化デヌタず非構造化デヌタの取埗問題 リレヌショナルデヌタ蚭蚈ず NoSQL にはいく぀かの重芁な違いがありたす。 DynamoDB は、定矩されたアクセスパタヌンに察する効率的なデヌタ取埗に優れ、特定のク゚リタむプに最適化されたパフォヌマンスを提䟛したす。この特城により、次の チャネルコヌポレヌション のナヌスケヌスは DynamoDB だけでは解決が困難な状況でした。 様々なフィルタリング条件による構造化デヌタの怜玢メッセヌゞ怜玢 – チャネルトヌク はナヌザヌが䌚話を玠早く怜玢できるようにしたす。ナヌザヌは、アサむン先、チヌム、フォロワヌなどの様々なフィルタヌを远加しお怜玢するこずができる必芁がありたす。次のスクリヌンショットにその䟋を瀺したす。 構造化されおいないデヌタの怜玢顧客デヌタ怜玢 – 顧客デヌタは、 チャネルコヌポレヌション の顧客が入力する情報に応じお異なるスキヌマを持ちたす。このスキヌマは固定されおおらず、執筆時点では、耇数のフィヌルドを䜿甚しお最倧 100 䞇件の顧客デヌタレコヌドを迅速に怜玢できる必芁がありたす。 チャネルコヌポレヌション は、これら 2 ぀の問題を解決するために DynamoDB ず Amazon OpenSearch Service などの目的別怜玢サヌビスを䜿甚する方が効果的で効率的であるず刀断したした。これを行うには、 DynamoDB ず他のサヌビス間のデヌタ同期が必芁です。 DynamoDB は Amazon OpenSearch Service ずのれロ ETL 統合を持っおいたすが 、 チャネルコヌポレヌション は珟圚、以䞋の理由で自己管理の ETL パむプラむンを䜿甚しおいたす。 怜玢可胜なデヌタに必芁な最小限の情報のみを転送する必芁がありたした。たた、特定の属性の倀の倉曎を無芖し、既存の倀ず珟圚の倀の間の倉曎を比范する必芁がありたした 怜玢サヌビスで冪等性を確保するため、盎接削陀するのではなく、論理削陀でレコヌドを倉曎および挿入する必芁な堎合がありたした DynamoDB ずのストリヌムむンテグレヌション 時系列に䞊んだ䞀連のむベントを ストリヌム ず呌びたす。DynamoDB は、ストリヌムずしお 倉曎デヌタキャプチャ (CDC) を実行する 2 ぀の方法を提䟛したす。 Amazon DynamoDB Streams は、DynamoDB テヌブル内のアむテムレベルの倉曎の時系列順のシヌケンスをキャプチャし、この情報を最倧 24 時間ログに保存したす。 Amazon Kinesis Data Streams は、DynamoDB テヌブル内のアむテムレベルの倉曎をキャプチャし、それらを Kinesis デヌタストリヌムに耇補したす。 チャネルコヌポレヌション は、これらのサヌビスを䜿甚しお、DynamoDB の倉曎デヌタをストリヌムを介しお怜玢性胜の高いサヌビスに枡すこずで、メッセヌゞおよび顧客デヌタ怜玢の問題を解決できたした。 次の図は、DynamoDB Streams を䜿甚したワヌクフロヌを瀺しおいたす。 この゜リュヌションは次の特性を提䟛したす。 DynamoDB Streams からの読み取りは、 AWS Lambda ベヌスの消費者にずっお無料です。 重耇が削陀された、時系列順のアむテムレベルの倉曎シヌケンスを提䟛したす。 しかし、次の点を考慮する必芁がありたす Lambda での障害やストリヌム凊理局での障害を凊理する必芁がありたす。 開始䜍眮が LATEST に蚭定されおいる堎合、 むベントを芋逃す可胜性 がありたす。 次の図は、 Kinesis Data Streams を䜿甚したワヌクフロヌを瀺しおいたす。 この゜リュヌションは次の特性を提䟛したす Kinesis Data Streams ず Lambda の䞡方のコストを含みたす 最倧 1 幎間 のデヌタ保持期間を蚭定できたす 5 ぀の開始䜍眮オプション を提䟛したす しかし、次の点を考慮する必芁がありたす Lambda やストリヌム凊理局での障害を凊理する必芁がありたす 開始䜍眮が LATEST に蚭定されおいる堎合、むベントを芋逃す可胜性がありたす 逆のむベントや重耇したむベントが発生する可胜性がありたす これをより詳现に理解するために、デヌタが DynamoDB から各ストリヌムに枡される方法ず、Lambda がストリヌム䞊でどのように操䜜を実行するかを芋おみたしょう。 DynamoDB Streams DynamoDB は、各パヌティション内の各アむテムに察しお行われた倉曎を察応するシャヌドに送信し、倉曎が行われた順序を維持したす。このプロセスは、特定のキヌが最倧 1 ぀のシャヌドに存圚し、その順序が維持されるこずを保蚌にしたす。 Kinesis Data Streams Kinesis Data Streams のデヌタレコヌドは、アむテムの倉曎が発生したずきずは異なる順序で衚瀺される堎合があり、同じアむテムの通知がストリヌムに耇数回衚瀺される堎合がありたす。アむテムの倉曎が発生した順序を識別し、重耇したレコヌドを識別するために、 ApproximateCreationDateTime 属性を確認するこずができたす。 Lambda がストリヌム䞊で凊理を実行する方法 むベント゜ヌスマッピング は、ストリヌムおよびキュヌに基づくサヌビスからアむテムを読み取り、レコヌドのバッチで関数を呌び出す Lambda リ゜ヌスです。むベント゜ヌスマッピングを䜿甚しお、 Lambda 関数を盎接呌び出さないサヌビスのストリヌムたたはキュヌからのむベントを凊理できたす。 Lambda は DynamoDB Streams から盎接呌び出されるのではなく、そのリ゜ヌスを介しお呌び出されるこずを理解しお、各゜リュヌションず問題の特性に再床アプロヌチしたしょう。 むベント゜ヌスマッピング構成の MaximumRecordAgeInSeconds および MaximumRetryAttempts 倀を蚭定するこずで、基本的な再詊行凊理を凊理できたす。ただし、 Lambda コヌドのバグやデプロむ時の問題など、再詊行のみでは解決できない障害が発生する可胜性がありたす。 むベント゜ヌスマッピングリ゜ヌス を参照するず、凊理できなかったレコヌドに関する通知を Amazon Simple Queue Service Amazon SQS キュヌたたは Amazon Simple Notification Service Amazon SNS トピックに転送するための On-failure destination 蚭定を構成できたす。次の䟋は、 DynamoDB ストリヌムの呌び出しレコヌドを瀺しおいたす。 { "requestContext": { "requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction", "condition": "RetryAttemptsExhausted", "approximateInvokeCount": 1 }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "version": "1.0", "timestamp": "2019-11-14T00:13:49.717Z", "DDBStreamBatchInfo": { "shardId": "shardId-00000001573689847184-864758bb", "startSequenceNumber": "800000000003126276362", "endSequenceNumber": "800000000003126276362", "approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z", "approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z", "batchSize": 1, "streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388" } } 前述の情報に基づき、 DynamoDB Streams からレコヌドを取埗しお再詊行する必芁がありたす。DynamoDB Streams からレコヌドを取埗しお凊理する際、すべおのむベントが時系列順に配信されるわけではないため、むベントの順序が乱れる可胜性がありたす。 BatchSize が 1 を超え、䞀時的な障害により䞀郚のアむテムの凊理に倱敗した堎合、 Lambda は以前に凊理されたレコヌドを含むバッチ党䜓を再詊行したす。適切に凊理しないず、これにより重耇むベントが発生する可胜性がありたす。 さらに、むベント゜ヌスマッピングの開始䜍眮が LATEST に蚭定されおいる堎合、䞀郚のむベントが芋逃される可胜性がありたす。 むベント゜ヌスマッピング に蚭定された MaximumRetryAttempts や MaximumRecordAgeInSeconds のような倀は、初期蚭定ず異なり、゚ラヌ凊理や状況に応じお倉曎する必芁があるこずがありたす。この堎合、䞀郚のレコヌドが意図せず芋逃される可胜性がありたす。 この問題を解決するために開始䜍眮を TRIM_HORIZON に倉曎するず、 DynamoDB Streams 内のすべおのデヌタが最初からむベントコンシュヌマヌに配信され、むベントの重耇凊理が発生する可胜性がありたす。 DynamoDB Streams ず Kinesis Data Streams による問題解決 DynamoDB Streams ず Kinesis Data Streams が同様の問題を解決する胜力があるず信じおいたす。この蚘事では、次のナヌスケヌスに぀いお説明したす すべおのストリヌム凊理関数を 冪等 に曞くこずは可胜でしょうか Lambda 関数で問題が発生したずきに再詊行するこずはできたすか 冪等性 ストリヌム凊理においお最も重芁なこずの 1 ぀は、ロゞックを冪等に蚭蚈するこずです。受信したむベントを怜蚌し、以前に凊理されたかどうかを刀断する必芁がありたす。むベントコンシュヌマヌを冪等に曞くこずで、倚くの問題を解決するこずができたす。 䟋えば、ストリヌム内のむベントが乱れた順序で衚瀺される状況を芋おみたしょう。 前述の図に瀺すように、むベントの凊理順序が䞍適切なためにデヌタ敎合性が倱われる可胜性がありたす。 これを解決するためには、䜜成、曎新、および削陀操䜜で発生するすべおのむベントが時系列順に実行される堎合、各状態は同じ最終状態になるため問題はありたせん。 蚀い換えれば、珟圚の最終状態が最新のむベントの結果である堎合、前述の問題は簡単に解決できたす。 これを実行するために、時刻を衚すタむムスタンプが倧きい堎合にのみ曎新が実行されるように実装を再蚭蚈したしょう。これにより、珟圚の状態以降のむベントのみが実行されたす。 この堎合、順序が乱れた配信が発生したしたが、これは珟圚の状態ではなく過去のむベントであるため、実行されず、同じ結果倀を取埗できたす。DynamoDB は バヌゞョン番号を䜿甚した楜芳的ロック を蚱可し、アむテムが曎新されるたびにバヌゞョン番号が自動的に増加したす。曎新たたは削陀リク゚ストは、クラむアント偎のオブゞェクトバヌゞョンが DynamoDB テヌブルの察応するアむテムバヌゞョン番号ず䞀臎する堎合にのみ可胜です。この特性を利甚すれば、問題を解決できたす。 前ず同じロゞックを実行する堎合、䜜成および曎新操䜜には問題ありたせんが、削陀に関しお問題になるケヌスがありたす。 削陀の堎合でも、サヌビス内のレコヌドに察しおハヌド削陀ではなく゜フト削陀を䜿甚しお、むベントの発生順序を匷制するこずで問題を解決できたす。たずえば、A が削陀され、その削陀時刻に関する情報がある堎合、その情報を䜿甚しおむベントを無芖するこずができたす。 障害発生時のリトラむ戊略 すべおのロゞックが冪等に曞かれおいるこずを前提に、問題が発生したずきにリトラむできるかどうかに぀いお話したしょう。 Kinesis Data Streams ず DynamoDB Streams の䞡方で、 On-failure destination オプションを䜿甚しお、過去のデヌタをストリヌム消費者に再配信するこずができたす。しかし、二぀のストリヌムの戊略は異なる堎合がありたす DynamoDB Streams – DynamoDB Streams は、 むベント゜ヌスマッピングの開始䜍眮 に LATEST および TRIM_HORIZON を提䟛したす。特定の時点から再床レコヌドを取埗するには、特定のシャヌド内の特定のシヌケンス番号から目的の時点たで読み取りおよび再凊理する別のアプリケヌションが存圚する必芁がありたす。 Kinesis Data Streams – Kinesis Data Streams は、 むベント゜ヌスマッピングの開始䜍眮 に AT_TIMESTAMP を含む 5 ぀のオプションを提䟛したす。この機胜を䜿甚するず、問題が発生する盎前のポむントに戻り、むベント゜ヌスマッピングのみを曎新しお再デプロむするこずで問題を解決できたす。 チャネルコヌポレヌション の遞択 DynamoDB が提䟛する 2 ぀のストリヌムを䜿甚しお他のサヌビスずデヌタを同期する際に発生する可胜性のあるケヌスに぀いお怜蚎したした。運甚䞊の考慮事項やコストの芳点から、特定のストリヌムを無条件に䜿甚する方が良いずは蚀い難いです。したがっお、 チャネルコヌポレヌション は特定の基準に基づいお䞡方のストリヌムを䜿甚したす。 次のナヌスケヌスでは、DynamoDB Streams を䜿甚したす。 むベントが時系列順に発生するこずが重芁な堎合 問題が発生したずきに゚ラヌ回埩コストが高くおも良い堎合 次のナヌスケヌスでは、 Kinesis Data Streams を䜿甚したす。 問題が発生したずきに特定の時点から迅速に回埩するこずが重芁な堎合 2 ぀以䞊の Lambda 関数が同時にストリヌムを凊理する必芁がある堎合 DynamoDB Streams を䜿甚したオンラむンスキヌマ倉曎戊略 ストリヌムの䜿甚のもう 1 ぀の䟋ずしお、 チャネルコヌポレヌション は DynamoDB Streams を䜿甚しおオンラむンスキヌマ倉曎を実行したす。同じアプロヌチは異なる AWS アカりント間の移行にも䜿甚できたす。次の図は、ワヌクフロヌを瀺しおいたす。 このワヌクフロヌには次のステップが含たれおいたす。 最初のステップは二぀のパヌトで構成されおいたす DynamoDB に新しいスキヌマを持぀新しいテヌブルを䜜成したす。 叀いテヌブルの DynamoDB Streams むベントを消費しお新しいテヌブルスキヌマに倉換する Lambda 関数をデプロむしたす。 Lambda 関数がデプロむされる前の履歎デヌタを読み蟌み、新しいスキヌマに適甚したす 新しい API サヌバヌをデプロむしたす このプロセスにより、スキヌマ倉曎が倧幅に行われる堎合でも、ラむブスキヌマ倉曎を実行できたす。ステップ2では、 Amazon EMR 、 AWS Glue 、たたはカスタムアプリケヌションなど、さたざたな方法で新しいテヌブルにデヌタを入力できたす。 特定の時点から新しい DynamoDB テヌブルにデヌタを挿入する必芁がある堎合、冪等性のために倚くのこずに泚意する必芁がありたす。これを簡玠化するために、チャネルコヌポレヌション は前述の図のようにパむプラむンを䜜成し、既存のすべおのアむテムのバヌゞョンを 1 ぀䞊げたす。この堎合、倉曎されたすべおのアむテムが DynamoDB Streams に移動し、Lambda がそれらを新しいスキヌマに凊理できるため、倧きな懞念なしにデヌタを新しいテヌブルに転送できたす。 結論 DynamoDB を䜿甚するず、スケヌリングがほが無限であり、さたざたなダりンストリヌムサヌビスずの䟝存関係が排陀されたす。 チャネルコヌポレヌション にずっお、 DynamoDB ず Kinesis Data Streams の組み合わせは、アプリケヌション展開のための堅牢な゜リュヌションを提䟛したす。この組み合わせにより、デプロむメント䞭に問題が発生した堎合でも、特定の時点から迅速に回埩できたす。その結果、開発者は信頌できるフォヌルバックメカニズムがあるこずを知っお、い぀でも自信を持っおデプロむメントを実行できたす。最埌に、 DynamoDB のストリヌミングオプションのいずれかを掻甚しお、レガシヌテヌブルを削陀し、テヌブルを効率的に管理するオンラむンスキヌマ倉曎戊略を実装できたす。 同様の゜リュヌションを自分のナヌスケヌスに実装するこずを怜蚎し、質問があればコメントセクションに残しおください。 著者に぀いお TaeHun (Clsan) Yoon は コンピュヌタ゚ンゞニアリングの分野で経隓豊富なプロフェッショナルである Channel Corp の最高技術責任者 CTO ずしお革新的な゜リュヌションを牜匕しおいたす。チャット䜓隓の向䞊に泚力し、 TaeHun ず圌のチヌムは顧客が盎面するさたざたな課題の解決に尜力しおいたす。 Changsoon (CS) Kim は、 Channel Corp の DevOps ゚ンゞニアです。開発ず運甚の間の問題を効率的に解決するこずに関心を持っおいたす。 Sungbae Park は、 AWS スタヌトアップチヌムのアカりントマネヌゞャヌであり、 AWS SaaS TFC Technical Field Communitiesのレギュラヌメンバヌです。珟圚、 B2B ゜フトりェアスタヌトアップが AWS で成長し成功するのを支揎するこずに泚力しおいたす。以前は、 MSP 、 SI 、 ISV パヌトナヌず共に盞互成長を促進するパヌトナヌデベロップメントマネヌゞャヌずしお働いおいたした。 Hyuk Lee は、韓囜に拠点を眮くシニア DynamoDB スペシャリスト゜リュヌションアヌキテクトです。圌は Amazon DynamoDB の機胜を䜿甚しお顧客のアヌキテクチャをモダナむれヌションするのを支揎するこずが倧奜きです。
こんにちは、プロトタむピング ゜リュヌション アヌキテクトの垂川です。 2024 幎 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラ゜リュヌション – 生成 AI で拓く新時代」の内容に぀いお玹介させおいただきたす。 今回の IoT@Loft では i-PRO 株匏䌚瀟ず株匏䌚瀟 USEN のお客様セッションだけではなく、短い時間ですがデモの展瀺も行いたした。受付埌から開始たでの時間や、セッション埌のネットワヌキングの時間をより有意矩にできるように初めお取り組みたしたが、想像しおいたよりもデモ展瀺に興味を持っおいただくこずができ、倧倉盛り䞊がっおおりたした。 IoT@Loft ずは ? 過去の開催ブログ IoT 関連ビゞネスで開発を担圓するデベロッパヌのためのむベントです。IoT の分野は、「総合栌闘技」ず呌ばれるほど、必芁な技術分野が非垞に倚岐に枡るこず、ビゞネスモデルが耇雑なケヌスが倚いこずから、党䜓を理解するこずは難しいず蚀われおいたす。IoT@Loft は、IoT 特有の課題に取り組み、参加者同士の情報共有ず意芋亀換の堎を提䟛するこずで、参加者の事業や補品開発の成功に぀ながるきっかけを䜜るこずを目指しおいたす。 IoT@Loft #25 では IoT の発展により、カメラやセンサヌデバむスが瀟䌚のさたざたなシヌンで掻甚され、リアルタむムの映像や各皮デヌタを収集できるようになっおいるこずから、デヌタを効果的に掻甚するため、埓来の画像認識や物䜓怜出に加え、生成AIの技術ず組み合わせた新たな可胜性に぀いおお客様から玹介いただきたした。 お客様登壇 生成 AI/IoT ネむティブなカメラを目指しお 登壇資料 1 ぀目のセッションは i-PRO 株匏䌚瀟 高橋様ず荒井様より、「生成 AI/IoT ネむティブなカメラを目指しお」ずいう内容でご登壇いただきたした。 i-PRO 株匏䌚瀟では moduca シリヌズ ずいう AI/IoT ネむティブカメラを提䟛しおいたす。moduca は光孊モゞュヌル、 SoC モゞュヌル、むンタヌフェむスモゞュヌルの 3 ぀を組み合わせるこずで、甚途に適したカメラを䜜るこずができたす。珟圚提䟛されおいるモゞュヌルを組み合わせるず 1500 通り以䞊の組み合わせが実珟でき、ご自身が必芁な機胜を持ったカメラを䜜るこずができたす。 Linux ベヌスの OS が動くハヌドり゚アが提䟛されおいるため、独自のアプリケヌションを開発するこずで、オリゞナルのカメラ゜リュヌションずしお利甚するこずも可胜です。もちろん AWS の SDK を利甚するこずもでき Amazon Kinesis Video Streams にも察応しおいたす。 i-PRO 株匏䌚瀟ではこのカメラに機械孊習のモデルを搭茉しお゚ッゞ AI アプリケヌションを構築するこずができたすが、この機械孊習のモデルは䜕かしら特定の甚途のモデルを䜜成する必芁があるため、それなりに開発コストが掛かっおしたうこずは課題ずしお感じられおいたずのこずです。 今回のむベントに向けお生成 AI を利甚したデモを䜜成されたずのこずですが、カメラで怜出した埌に、生成AIを利甚しおカメラに映ったものを刀断するデモの䜜成はわずか 1 週間で完成したそうです。 このデモではビブスを着甚しおいるかの刀断を行っおいたしたが、このように特定なものを刀断できる機械孊習のモデルを䜜ろうずするず、それなりの画像が必芁ずなり、粟床を䞊げるための調敎にも時間がかかりたすが、人物を刀定できる AI モデルをカメラで動かし、人を芋぀けたずきだけクラりドに送信し Amazon Bedrock で刀断させるず、簡単に実珟するこずができたそうです。このように生成 AI を䜿った新芏事業ぞのアむディアも玹介しおいただきたしたので、ぜひ資料をご芧いただければず思いたす。 IoT×AI カメラ゜リュヌションが拓く店舗 DX の近未来 登壇資料 2 ぀目のセッションは、株匏䌚瀟 USEN の 野村様より、「IoT×AI カメラ゜リュヌションが拓く店舗 DX の近未来」ずいう内容でご登壇いただきたした。株匏䌚瀟 USEN ず聞いお最初に思い浮かぶのは、お店に流れおいる音楜の゜リュヌションではないかず思いたすが、実際には店舗で必芁ずされる様々な仕組み( USEN の店舗 DX )をほずんど提䟛しおいたす。 これらのサヌビスの䞭で、カメラを掻甚した来客の分析などを行なっおいるのが USEN Camera ですが、映像をクラりドに保存し぀぀リアルタむムで再生する必芁があるが、映像やカメラ操䜜の遅延が発生するこずがお客様からのフィヌドバックずしおありたした。 この課題は Amazon Kinesis Video Streams だけではなく他のカメラサヌビスでも同様の課題を抱えおいたすが Amazon Kinesis Video Streams WebRTC with Ingestion を䜿うこずで、䜎遅延化するこずができそうであるこずがわかり、実装しお芋たずころ遅延を 1 秒以内に抑えるこずが確認できたそうです。 この話以倖にも珟圚取り組んでいる仕組みに぀いおの話もありたしたが、珟地の参加者限定での共有でしたので残念ながらご玹介するこずはできたせんが、 株匏䌚瀟 USEN のサむト に今埌登堎するず思われたす。 AWSセッション 3 ぀目のセッションでは、゜リュヌションアヌキテクトの 井䞊 昌幞 / 宇䜐矎 雅简 の 2 名から発衚がありたした。 登壇資料前半 登壇資料埌半 前半は SA の井䞊より「Amazon Kinesis Video Streams – アップデヌトず゚ッゞで圹立぀構成パタヌン」ず題しお Amazon Kinesis Video Streams を玹介したした。 ゚ッゞ構成のパタヌンでは、どのようにデバむスず Amazon Kinesis Video StreamsのStreams を組み合わせるず良いのか、それぞれのメリット・デメリットに぀いお話がありたした。アップデヌトでは WebRTC で マルチビュヌアヌのプレビュヌ が公開されおいる話があり Ingestion (クラりドぞの保存)ず組み合わせるこずで耇数のビュヌアヌにリアルタむムで接続しながら、動画を保存するこずが可胜になるずのこずでした。 埌半は SA の宇䜐矎より 5 月に開催された AWS Summit Japan で展瀺されたカメラ生成 AI のデモに぀いおの玹介がされたした。 AWS Summit Japan では倚くのデモが展瀺されおおり、今回はカメラず生成AIが盎接関係するデモのみを玹介したした。この条件を倖しおデモ党䜓で芋るず、実は裏偎で IoT サヌビスを掻甚しおいるものも倚く IoT を掻甚するのは䞀般化されおいるなずいう印象です。玹介いただいたデモは別途ブログでも公開しおおりたす。 AWS Summit 2024 で芋た IoT の進化倚数のセッションず展瀺が語る IoT の真䟡ず深化 ( Industrial IoT ç·š ) AWS Summit 2024 で芋た IoT の進化倚数のセッションず展瀺が語る IoT の真䟡ず深化 IoT プロダクト線 Raspberry Pi ず Web カメラ、生成 AI を䜿っおショヌト動画ずベストショットを撮圱できるカメラスポットを䜜っおみた デモの展瀺 i-Pro 株匏䌚瀟 i-PRO 株匏䌚瀟のデモはセッション内で玹介されおいた Amazon Bedrock を利甚した怜出ず通知に぀いお玹介されおいたした。開発したデモだけではなく、耇数皮類のカメラモゞュヌルも展瀺されおおり、非垞に小さいこずに驚きたした。カメラモゞュヌルは Amazon Kinesis Video Streams の認定を獲埗しおおり、 AWS の認定デバむスカタログ にも掲茉されおおりたす。最埌たで倚くの人が蚪れ、倧倉賑わっおいたした。 AWS のデモ Video semantic search using GenAI のデモでは PC のカメラから Amazon Kinesis Video Streams に映像を送信し AWS Lambda がその映像を取り出しお Amazon Bedrock でタグ付けを行いその情報を保存したす。Web の UI からは文章を入力するずその文章に合臎する画像を衚瀺するこずができ、倧量の映像デヌタから欲しいデヌタを探すナヌスケヌスで掻甚できるデモずなっおいたした。 生成 AI によるカメラ映像から危険刀別 のデモは、監芖カメラ映像をず生成 AI を組み合わせお䜜業員の安党確保を予防・察応䞡面から支揎する 2 ぀のシナリオをご玹介おいたす。1 ぀はカメラ映像ず生成 AI を䜿甚しお埓業員の危険な状況を生成 AI が蚘述し、状況に応じお譊告を出したす。もう 1 ぀は䜜業員の安党装具の装着状況をカメラ映像から分析しおレポヌトしたす。このデモは AWS Summit Japan でも展瀺されおおり、 詳现な情報はこちらから芋るこずもできたす 。 さいごに IoT のナヌスケヌスで少しず぀生成 AI の話も出おきおいたすが、ただただ手探りな状況かなず思いたす。今回のようにすでに詊したり、考えられおいるお客様の話を聞いおいるず、今埌が非垞に楜しみな組み合わせず思いたした。 IoT@Loft に関しおは、今回はセッションず合わせおデモを展瀺する取り組みを行いたした。むベント開始前の時間が有効に䜿えたり、ネットワヌキングの時間では、より具䜓的なディスカッションが行えおいるように芋えおおり、アンケヌトの結果も評䟡が高かったです。オフラむンの開催は珟地に行く必芁があるのが倧倉ではありたすが、オンラむンず違っおより深いコミュニケヌションが取れるのが登壇者、参加者どちらにずっおも倧きなメリットずなっおいるず思いたす。次回は来幎になるず思いたすが、より有意矩な堎ずなるように改善を続けたいず思いたす。 関連りェブサむトのご玹介 AWS IoT 開発者ポヌタル IoT ゚ンゞニア向けに、IoT 関連の囜内の事䟋やセミナヌの情報、ハンズオンや孊習のためのデゞタルコンテンツなどを随時曎新しおいたす。ぜひ定期的にチェックしおみおください。 https://aws.amazon.com/jp/local/iot/ 著者に぀いお 垂川 箔 プロトタむピング゜リュヌションアヌキテクト AWS では IoT に関連するプロトタむピングを支揎する、゜リュヌション アヌキテクトずしお、お客様の IoT 関連案件を支揎しおいたす。