TECH PLAY

AWS

AWS の技術ブログ

å…š3323ä»¶

日本政府は成長ず分配の奜埪環を目指す「新しい資本䞻矩」の実珟に向けお、瀟䌚課題の解決に取り組むスタヌトアップがそのドラむバヌであるず捉えスタヌトアップぞの支揎を匷化し、持続可胜な瀟䌚を目指しおいたす。さらに、スタヌトアップ育成5か幎蚈画の䞭では、グロヌバル垂堎での優䜍性ずいう芳点から非蚀語技術の創出を目指し研究開発型スタヌトアップぞの支揎に関する予算が倚く割り圓おられおおり、その成長に期埅が寄せられおいたす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟以䞋、AWSゞャパンは、クラりドを始めずした新たなデゞタルテクノロゞヌを瀟䌚実装するうえで欠かせないのがスタヌトアップであるず考え、過去10幎にわたり数千におよぶ日本のスタヌトアップを支揎しおきたした。その䞭でも研究開発型のスタヌトアップ支揎に関連しお、AWSゞャパンは2022幎9月に぀くば垂ず研究開発型スタヌトアップの成長加速に向けた連携を発衚し支揎するなど、より良い瀟䌚ず垂民生掻の実珟に貢献すべく、様々な関係団䜓ずの連携を図っおいたす。 慶應矩塟倧孊は、倚様な瀟䌚課題を解決できるスタヌトアップを倚く茩出するために、2026幎たでに倧孊発のスタヌトアップの蚭立数を300瀟ずするこずを目暙ずし、経枈産業省の2022幎床調査で倧孊別のスタヌトアップ䌁業数が党囜䜍ずなるなど、育成を匷化しおいたす。 このような背景からAWSゞャパンは、本日、 慶應矩塟倧孊むノベヌション掚進本郚 ずスタヌトアップの支揎に぀いお連携しお取り組んでいくこずを発衚したした。この連携により、瀟䌚課題の解決に挑戊する慶應矩塟倧孊発スタヌトアップは、コンピュヌティングに関する支揎を受けるこずで、AWSの人工知胜 (AI) や機械孊習 (ML)ずいった最新のテクノロゞヌの掻甚が容易になるずずもに、起業やその埌の成長をさらに加速しおいくこずが期埅されたす。AWSゞャパンは、慶應矩塟倧孊ずずもに、囜内の産業掻性化の支揎のみならず、グロヌバルの瀟䌚課題解決の支揎に向けお取り組んでいきたす。 この連携は、 慶應矩塟倧孊関連スタヌトアップ や起業を目指す研究者に察する倚角的な支揎䜓制の構築を特城ずしおおり、具䜓的には、䞻にAWSゞャパンが提䟛する以䞋の4぀の支揎から成り立っおいたす。 蚈算リ゜ヌス提䟛  AWS Activate※プログラムを掻甚し、慶應矩塟倧孊関連スタヌトアップに察しお、最倧$5,000分のAWS利甚バりチャヌや他のSaaSのディスカりントを提䟛したす。 技術・人材支揎  AWS゚ンゞニアによる個別の技術盞談䌚を開催し、CTO人材の孊習やネットワヌキングの機䌚を提䟛したす。これには、オンサむトのワヌクショップも含たれたす。 情報提䟛  セキュリティ察策、デヌタ保護法芏、IT運甚コスト最適化、AI/MLの最新サヌビスなどに関する情報発信を行いたす。これらはセミナヌや勉匷䌚の圢で実斜したす。 起業文化醞成  セミナヌやむベントを通じお起業文化を醞成したす。具䜓的には、AWSが䌁画するアントレ教育関連むベントぞの玹介や、補助金や事業化支揎の制床掻甚に関する情報提䟛を行いたす。 慶應矩塟倧孊 むノベヌション掚進本郚 統括本郚長 倩谷 雅行のコメント 「党瀟䌚の先導者」ずいう慶應矩塟の目的の䞋、研究・教育成果を基にしたスタヌトアップ創出に力を入れる本孊にずっお、䞖界芏暡のクラりドサヌビスを展開するAWSゞャパンずの連携は倧きな意味を持぀ものず考えおいたす。慶應矩塟倧孊むノベヌション掚進本郚は、本連携協定の䞋、スタヌトアップ・゚コシステムの発展に貢献し、䞖界芏暡の課題解決ができるようなディヌプテック䌁業の成長を支揎しおいきたす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 執行圹員 パブリックセクタヌ 統括本郚長 宇䜐芋 朮のコメント 慶應矩塟倧孊むノベヌション掚進本郚ずAWSゞャパンの連携は、起業を志す研究者や孊生が必芁ずする支揎を提䟛するこずで、慶應矩塟倧孊を䞭心ずしたスタヌトアップコミュニティの拡倧を目指すものです。この連携により倧孊の研究が玠早く瀟䌚実装されるモデルを構築し、囜内の産業掻性化のみならず、グロヌバルの瀟䌚課題解決に貢献したいず考えたす。慶應矩塟倧孊ずAWSゞャパンが日本のむノベヌション創出における先導者になるこずを期埅しおいたす。 ※AWS Activate は、スタヌトアップ䌁業のゞャヌニヌでのあらゆるステップを簡玠化するために蚭蚈された無料のツヌル、リ゜ヌス、およびコンテンツを、ふさわしいスタヌトアップ䌁業に提䟛するものです。メンバヌは登録埌すぐに、AWS が厳遞した、ビゞネスおよび技術的なニヌズに関する゚キスパヌトのヒント、トレヌニングずサポヌト、事前構築枈みのむンフラストラクチャテンプレヌトなどの特兞を受け取るこずができたす。
このブログ蚘事では、スケヌラブルで回埩力のある䞍動産リヌスず怜玢のためのむベント駆動型サヌバヌレス゜リュヌションを構築する方法を玹介したす。この゜リュヌションは、䞍動産投資信蚗 (REIT) の先駆者である AvalonBay Communities, Inc. 向けに開発されたした。この゜リュヌションにより以䞋が可胜になりたす。 1 日あたり 150,000 件以䞊のマルチパラメヌタ怜玢 1 か月あたり 3,500 件以䞊のリヌス申請ぞの察応ず 85,000 件の家賃支払い凊理 AvalonBay ぱクむティ REIT です。同瀟は、米囜の䞻芁垂堎でアパヌトの開発、再開発、買収、管理を行っおきた長い実瞟があり、革新的なテクノロゞヌ゜リュヌションを䜿甚しお顧客に長期的な䟡倀をもたらしおいたす。AvalonBay はデヌタ䞻導型のむンサむトがビゞネスの成長に貢献するこずを理解しおいたした。しかし、䞍動産から䞍動産管理システム、財務システム、䌚蚈システムたで、耇数のデヌタセット間の耇雑な盞互䟝存関係を管理するには、新しい゜リュヌションが必芁であるこずに気づきたした。 課題 AvalonBay は、2022 幎 9 月 30 日珟圚、12 の州ずワシントンD.C. の 88,405 戞の集合䜏宅を含む 293 のアパヌトコミュニティを盎接的、間接的に保有しおいたす。このうち 18 のコミュニティは開発䞭、 1 ぀は再開発䞭でした。こうした状況は、耇数の地域で、様々な基準に基づいおアパヌトを怜玢しお賃貞するこずを怜蚎しおいる瀟内倖のナヌザヌずっお課題ずなりたした。たずえば、特定のアメニティ、賃貞条件、家具、空宀日が蚭定されおいる建物内のナニットを芋぀けるこずが必芁です。 ゜リュヌション抂芁 AvalonBay の申蟌者ず居䜏者向けのフルマネヌゞド型のリヌシング゜リュヌションは、アマゟンりェブサヌビス (AWS) 䞊にホストされおいたす。この゜リュヌションは安党で、オヌトスケヌリングが可胜で、マルチリヌゞョンに察応しおいるため、リ゜ヌスを効率的に䜿甚しながら耐障害性ずパフォヌマンスを確保できたす。 このむベント駆動型の゜リュヌションの䞭では、 AvalonBay のリヌシングサヌビスが耇数の AWS リヌゞョン䞊にホストされおおり、さたざたな地域のナヌザヌに察しお䜎レむテンシヌの応答を提䟛したす。 このブログ蚘事では、図 1 に瀺す1 ぀のリヌゞョン (Region East) のみでのナヌスケヌス実装に焊点を圓おおいたす。 図1 : AvalonBay リヌシング凊理プラットフォヌム この゜リュヌションには、䌚瀟の䞻芁な目暙を達成するために、いく぀かの AWS サヌビスが統合されおいたす。それぞれのアヌキテクチャずその目的に぀いお芋おいきたしょう。 Amazon Route 53 : AvalonBay のリヌシング凊理゜リュヌションではサヌビス障害が継続しおしたう状況は容認できたせん。リヌシング凊理は マルチ AZ アヌキテクチャによっお高い耐障害性を提䟛するだけでなく、マルチリヌゞョンのアクティブ-アクティブ構成のアヌキテクチャによっお、リヌゞョンレベルの高可甚性を実珟したす。 レむテンシヌに基づくルヌティング を備えた Amazon Route 53 では、数秒以内にリク゚ストを別のリヌゞョンに動的に再ルヌティングできたす。 Amazon API Gateway : Amazon Route 53 のレむテンシヌに基づくルヌティングは、耇数の AWS リヌゞョンの API ゲヌトりェむ゚ンドポむントにトラフィックをルヌティングするように蚭定されおいたす。 Amazon Cognito ナヌザヌプヌル を䜿甚しお API ぞのアクセスを制埡するために API Gateway Authorizer が远加されおいたす。 Provisioned Concurrency が有効化された AWS Lambda : AWS Lambda は耇数のアベむラビリティヌゟヌンを跚いでオヌトスケヌリングし、プラむベヌトサブネットを介しお保護されるよう蚭定されおいたす。これにより、アベむラビリティヌゟヌン党䜓にわたる氎平スケヌリング機胜、自己修埩胜力、耐障害性が実珟したす。 Provisioned Concurrency は、実行環境のセットアップによるコヌルドスタヌトを最小限に抑え、 API 呌び出しにかかる時間を倧幅に短瞮したす。 Amazon Aurora Serverless v2 PostgreSQL 互換゚ディション : Amazon Aurora Serverless v2 は Amazon Aurora 甚のオンデマンドの自動スケヌリング蚭定です。リヌシング凊理゜リュヌションには、Amazon Aurora Serverless v2 PostgreSQL 互換゚ディションが䜿甚されおいたす。Amazon Aurora Global Database は 2 ぀のリヌゞョンで構成されおいたす。 us-east-1 リヌゞョンはプラむマリクラスタヌ、 us-west-2 リヌゞョンはセカンダリヌクラスタヌです。 蚈画的なフェむルオヌバヌ、蚈画倖のフェむルオヌバヌの䞡方に察応可胜なグロヌバルデヌタベヌス゚ンドポむントの自動管理は、Amazon Route 53 プラむベヌトホストゟヌン、 Amazon EventBridge 、 AWS Lambda によっお蚭定されおいたす。 Amazon RDS Proxy for Aurora : Amazon RDS Proxy を䜿甚するず、リヌシングアプリケヌションがデヌタベヌス接続をプヌルしお共有できるため、スケヌリング胜力が向䞊したす。たた、アプリケヌション接続を維持したたたスタンバむデヌタベヌスむンスタンスに自動接続できるので、リヌシング゜リュヌションのデヌタベヌス障害に察する耐性が高たりたす。 Amazon EventBridge : Amazon EventBridge は、䞻に次の2぀の目的で゜リュヌションをサポヌトしたす。 リヌシングフロヌの監芖 – リヌス申請プロセス䞭、この゜リュヌションは AvalonBay 、プロパティマネゞメント、ファむナンスポヌタル、管理業務などの倖郚アプリケヌションで䜿甚される様々なむベントを生成したす。リヌシングむベントは AWS Lambda 、 Amazon Simple Notification Service (Amazon SNS) 、倖郚の API ゚ンドポむントなど、耇数の宛先に察しおのむベントルヌルが蚭定された Amazon EventBridge に送信されたす。 Amazon Aurora Serverless v2 グロヌバルフェむルオヌバヌ凊理 – Amazon Aurora は、あらゆる皮類のグロヌバルデヌタベヌスアクティビティを含むアクションやむベントをもずにむベント情報を生成したす。 蚈画されたフェむルオヌバヌが実行された時 – AWS コマンドラむンむンタヌフェむス (AWS CLI) 、API 、コン゜ヌルのいずれかを介しお、グロヌバルデヌタベヌスフェむルオヌバヌプロセスが開始され、むベントが生成されたす。 Aurora クラスタヌの 1 ぀が AWS CLI 、 API 、コン゜ヌルを䜿甚しおグロヌバルクラスタヌから削陀されるず、Aurora クラスタヌは単䞀のプラむマリクラスタヌずしお昇栌されたす。このプロセスが完了するず、むベントが生成されたす。EventBridge ルヌルは、グロヌバルデヌタベヌスが管理する蚈画的フェむルオヌバヌが正垞に完了した際のむベントパタヌンに合わせお䜜成されおいたす。フェむルオヌバヌが完了するず完了むベントが怜出され、このルヌルがトリガヌされたす。むベントルヌルは、グロヌバルデヌタベヌスのフェむルオヌバヌ時にトリガヌされる Amazon CloudFront CNAME レコヌドを正しい倀に曎新する Lambda 関数を呌び出すように蚭定されおいたす。 スケヌラブルな怜玢゜リュヌション リヌシングの専門家は芁求された情報を埗るために、AvalonBay の怜玢゜リュヌションを䜿甚しお膚倧な量の物件情報を簡単にスキャンできる必芁がありたす。 Amazon OpenSearch Service を䜿甚するず、゚ヌゞェントはプロパティプロファむルやその他の資産デヌタを生成しお、䞀臎するナニットを特定し、゚ンドカスタマヌに迅速に察応できたす。Amazon OpenSearch Service はビゞネスデヌタや運甚デヌタのリアルタむム怜玢、監芖、分析を安党に実珟する完党にオヌプン゜ヌスの怜玢および分析゚ンゞンです。Amazon OpenSearch Service はアプリケヌション監芖、ログ分析、オブザヌバビリティ、りェブサむト怜玢などのナヌスケヌスに採甚されおいたす。 Amazon OpenSearch Service を特城ずする AvalonBay 怜玢サヌビスの゜リュヌションアヌキテクチャを図 2 に瀺したす。 図2 AvalonBay 怜玢サヌビスアヌキテクチャ AvalonBay の怜玢には、キヌワヌドず URI怜玢 、SQL ベヌスの怜玢、 カスタムパッケヌゞ怜玢 を含んだ怜玢条件が必芁です。これらの詳现は Amazon OpenSearch Service 開発者ガむド に蚘茉されおいたす。 Amazon OpenSearch は、障害が発生した OpenSearch サヌビスノヌドを自動的に怜出しお眮き換えるため、むンフラ管理に関するオヌバヌヘッドが軜枛されたす。このアヌキテクチャヌを段階的に詳しく芋おいきたしょう。 Amazon Kinesis むベントストリヌム – AvalonBay コミュニティでは、アメニティ、機胜、プロモヌション、䟡栌などの怜玢属性をニアリアルタむムで曎新する必芁がありたす。さたざたなプロデュヌサヌによっお䜜成されたむベントは Amazon Kinesis を通じおストリヌミングされ、 Amazon OpenSearch Service に挿入、曎新されたす。 Amazon OpenSearch Service – Amazon OpenSearch Service ぱンドツヌ゚ンドのコミュニティ怜玢に䜿甚されたす。マネヌゞドサヌビスによっおAmazon OpenSearch Service クラスタヌは AWS クラりドに簡単にデプロむ、運甚、スケヌリングするこずができたす。コミュニティ怜玢デヌタは読み取り専甚であるため、䜿甚頻床に応じお UltraWarm ストレヌゞ ず コヌルドストレヌゞ を䜿甚したす。 Amazon Simple Storage Service (S3) – さたざたなコミュニティ文曞、ポリシヌ、画像ファむル、動画ファむルは䞻芁な怜玢芁玠です。これらは契玄䞊の矩務により、䜕幎にもわたっお安党か぀確実に維持されなければなりたせん。Amazon S3 は、 高い耐久性 、 ラむフサむクルルヌル 、さたざたな 保存管理 により、この䜜業を簡玠化したす。 たずめ この蚘事では、AvalonBay が AWS のサヌバヌレスプラットフォヌムを利甚しお、耐障害性、パフォヌマンス、拡匵性を損なうこずなく、カスタムされたリヌシングず怜玢゜リュヌションをデプロむした方法に぀いお説明したした。この゜リュヌションはフルマネヌゞド型で幎䞭無䌑で皌働し、オンプレミスに远加の機噚を甚意する必芁はありたせん。 リヌシングず怜玢の゜リュヌションに AWS を遞択したこずで、AvalonBay はコスト面でのメリットを生かしながら、動的に芏暡を拡倧し、将来の成長需芁に察応できるようになりたした。さらに、AWS のサヌビスは䞖界䞭で利甚できるため、パフォヌマンス芁件を満たすサヌビスを地理的に離れた堎所にデプロむするこずが可胜になりたす。 著者に぀いお Amarpreet Kalra Amarpreet Kalra は AWS のシニア゜リュヌションアヌキテクトで、お客様ず協力しお AWS のベストプラクティスを䜿甚しお AWS のシステムアヌキテクチャを蚭蚈しおいたす。Amarpreet は、15 幎間金融サヌビス向けの分散システムの蚭蚈ず構築をしおきたした。䜙暇はノヌスカロラむナ州シャヌロットで家族ず静かな生掻を送っおいたす。 Dr. Ivan Panushev Dr. Ivan Panushev は AWS の゚ンゞニアリング、建蚭、䞍動産担圓プリンシパルパヌトナヌ゜リュヌションアヌキテクトです。たた、米囜囜立建築科孊研究所 (NIBS) の米囜党囜 BIM プログラム運営委員䌚のメンバヌでもありたす。Dr.Panushevは、ハヌバヌド倧孊で工孊ず蚭蚈の博士号、修士号、孊士号を取埗しおいたす。 Kausik Dey Kausik Dey はニュヌゞャヌゞヌ州に拠点を眮く AvalonBay の゜フトりェア゚ンゞニアリング担圓ディレクタヌです。スケヌラブルで耐障害性ず可甚性に優れた゜リュヌションのアヌキテクチャ蚭蚈、実装に 20 幎以䞊携わっおきたした。ビゞネス関係者ず協力しおデゞタルトランスフォヌメヌションず AWS 導入の道のりをサポヌトするこずを楜しんでいたす。圌の重点分野は、サヌバヌレス、アプリケヌション統合、セキュリティです。䜙暇は旅行や読曞に費やしおいたす。 翻蚳は゜リュヌションアヌキテクトの奈良が担圓したした。原文は こちら です。
デヌタマむグレヌションは、組織がクラりドに移行するための重芁な第䞀歩です。倚くの堎合、ビゞネスクリティカルなアプリケヌション、デヌタベヌス、デヌタアナリティクスワヌクロヌド、デヌタりェアハりス、ビッグデヌタ、孊習枈みの人工知胜/機械孊習 (AI/ML) モデルのリフトアンドシフトが必芁ずなりたす。デヌタはさたざたなレむダヌで生成・保存されたす。そのため、マむグレヌションのプロセスは耇雑なものずなり、デヌタの取り蟌みずマむグレヌションのプロセスを合理的な方法論を甚いお適切に蚭蚈し、継続的なデヌタ転送をできるようにするこずが重芁です。 Globe Telecom はフィリピンの倧手通信サヌビスプロバむダヌです。フィリピン囜内で最倧玚のモバむル、固定回線、ブロヌドバンドネットワヌクを運営しおおり、玄 6,000 䞇人もの顧客を抱えおいたす。Globe Telecom は、りェブポヌタル、コンテンツ登録プラットフォヌム、オンラむンストア、セルフサヌビスアプリに AWS を利甚するこずで、優れた顧客䜓隓を提䟛しおいたす。 この蚘事では、Cloudera data を Amazon Simple Storage Service (Amazon S3)ぞ移行した内容を含む、Globe Telecom のデヌタマむグレヌションの道のりを玹介したす。このプロゞェクトでは、Globe Telecom の Enterprise Data Office (EDO) は異なる事業䞻䜓毎に分散しおデヌタを所有しおいたした。Globe Telecom は、7.2 PBのHadoop Distributed File System (HDFS) デヌタを、4ヶ月以内にネットワヌク経由での移行を呜じられたした。移行䞭もシステムは継続しお本番皌動しおおり、皌働䞭の Cloudera からS3 バケットぞデヌタ転送を継続するこずで、デヌタを最新の状態に保ちたした。Globe Telecom が保有する Cloudera のラむセンスは曎新期限が迫っおいたした。たた、新しく生成されたデヌタがオンプレミスのストレヌゞの容量を圧迫し、ストレヌゞの容量䞊限に達する懞念があったこずもあり、厳しいスケゞュヌルでの移行が必芁でした。 Globe Telecom の技術的な芁求事項 Globe Telecom は生デヌタを栌玍するデヌタレむクずしお、 Amazon S3 䞊に集䞭型のデヌタリポゞトリの構築・管理を行う必芁がありたした。 Amazon S3 にデヌタが到着するず、前凊理、分析゚ンゞンずの共有埌にデヌタむンサむトを実斜する必芁がありたした。ビゞネスナヌザヌはその埌、Business Intelligence (BI) ツヌルを掻甚したデヌタの芖芚化を行い、デヌタ䞻導のビゞネス䞊の意思決定に圹立おおいたす。 Globe Telecom の デヌタマむグレヌションに察する芁件: Cloudera は HDFS の゜ヌス ステヌゞング゚リアを䜿甚しない HDFS ストレヌゞノヌドからのデヌタマむグレヌションの実珟 10Gb/s の垯域を持぀ AWS Direct Connect を掻甚したオンラむンデヌタマむグレ―ション デヌタサむズずしおは、7.2 PBあり、履歎デヌタず新しく受信したデヌタから構成 総ファむル数は 10億以䞊 履歎デヌタず新しいデヌタセットの増分同期 マむグレヌション実斜に必芁になるオンプレミスリ゜ヌスぞの圱響は最小限にする 自動化、モニタリング、レポヌティング及びスクリプトのサポヌト ゜リュヌションの評䟡 圓初は履歎デヌタ移行、新しく取り蟌んだデヌタの転送、及び゜ヌスずなる Cloudera システムからオヌプンファむル同期を実行する機胜をも぀ベンダヌの補品を怜蚎しおいたした。党䜓的な機胜セットは魅力的で、Globe Telecom の䞻芁な芁件を満たしおいたした。しかし、ラむセンス費甚、むンフラ芁件、そしお本蚘事で扱う内容のように倧芏暡ケヌスの堎合、耇雑さが重くのしかかり導入を断念したした。曎に抂念実蚌(Proof of Concept, PoC )実隓を行うために゜フトりェアを入手するこずも困難でした。 そこで、HDFS のデヌタを Amazon S3 ぞマむグレヌションするために、 AWS DataSync を含む他゜リュヌションの評䟡し、 DataSync を採甚したした。採甚理由ずしおは、Globe Telecom の䞻芁な芁件を満たしおおり、耇数の DataSync ゚ヌゞェントを䜿甚するこずによっおスケヌルアりトアヌキテクチャを構築できる柔軟性が提䟛されるずいうずころでした。 PoC の間、Globe Telecom は以䞋のような成功基準を挙げ、各ツヌルに察しお䞀連のテストを実斜しおいたす: 俊敏性 信頌性 機胜性 可甚性ずスケヌラビリティ セキュリティ サポヌトず将来性 コスト テストは拮抗した競争ずなっおおり、䞊蚘の芁玠の䞭で差別化可胜なものは、コスト、可甚性、スケヌラビリティでした。最終的に DataSync の遞定に圱響を䞎えた芁玠ずしおは、これらのものに加え、次のような理由がありたした。 簡単なセットアップずデプロむ AWS Command Line Interface (AWS CLI)ずスクリプトをサポヌト ゜ヌスずタヌゲット間の増分デヌタ転送 単䞀ダッシュボヌドでのモニタリング タスクベヌスで拡匵可胜 Amazon Elastic Compute Cloud (Amazon EC2) 䞊の DataSync゚ヌゞェント シンプルな料金䜓系 ゜リュヌションの抂芁 Globe Telecom は、DataSync を䜿甚しお 7.2PBの Cloudera デヌタをマむグレヌションするために独自の゜リュヌションアヌキテクチャを構築したした。AWS ずしおは、䜎レむテンシヌアクセスずパフォヌマンスを向䞊させるためには、゜ヌスストレヌゞのできるだけ近くで DataSync ゚ヌゞェントを実行するこずを掚奚しおいたす。しかし、Globe Telecom がずった構成は、党おの DataSync ゚ヌゞェントは EC2 むンスタンスずしお皌働しおいたす。これは、オンプレミスのフットプリントを無くすアプロヌチがずられたからです。DataSync ゚ヌゞェントに぀いおの詳现は、 DataSync ゚ヌゞェントの芁件 を参照しおください。 各 タスク の実行に際しおは、” include filters “を適甚しおいたす。この機胜は AWS DataSync が有するナニヌクな機胜です。゜ヌスストレヌゞの特定フォルダをタヌゲットに、耇数のDataSync ゚ヌゞェントにおデヌタ転送を行うこずで、デヌタ転送をスケヌルさせるこずが可胜です。これにより、耇数の゚ヌゞェントを甚いお DataSyncタスクの䞊列化を実珟しおいたす。PoC 実斜に際しおこのような準備や調査を现密に実斜しおいく事によっお、スムヌズな PoC 実斜を実珟しおいたす。 レゞリ゚ンスのための構成 EC2 むンスタンスを Availability Zones (AZ)に分散させ、”include filters”でタスクに基づいた゚ヌゞェントのグルヌプ化を実斜しおいたす。こうするこずで、HDFS デヌタマむグレヌションに際しお匟力性のあるアヌキテクチャを構築しおいたす。今回の環境は、10 Gbpsの垯域が利甚できるネットワヌクず、䞀貫した読み取りスルヌプットを提䟛する゜ヌスストレヌゞが存圚しおいたこずもあり、埅ち時間やパフォヌマンス問題は発生しおいたせん。たた、゚ヌゞェントごずのタスク割り圓おを慎重に蚈画し、フィルタを䜿甚するこずによっお、デヌタの取り蟌みの最適化が行えおいたす。 それぞれの AZ で実行されるタスクでは、各゜ヌス HDFS ロケヌションに蚭定された3぀の DataSync ゚ヌゞェントが利甚されたす。䞇が䞀の事態に備え远加でで 2぀、スタンバむ゚ヌゞェントの配備・起動を行っおいたす。DataSync タスクぱヌゞェント間での自動フェむルオヌバヌ機胜の提䟛はありたせん。しかしながら問題が発生した゚ヌゞェントの代わりにスタンバむ゚ヌゞェントを利甚可胜です。 スケヌルのためのデザむン DataSync ゚ヌゞェントは、オンプレミスずセキュアな゚ンドツヌ゚ンド接続を提䟛するプラむベヌト VPC ゚ンドポむント を䜿甚しアクティベヌトしたした。珟圚の゜ヌスシステムにおいお、以䞋のパフォヌマンスを達成しおいたす: ゜ヌスシステム ネットワヌク垯域 ネットワヌクスルヌプット 読み蟌み IoPS Cloudera CDH 5.13.3, 370 デヌタノヌド, 2 ネヌムノヌド 10 Gb/s 800 MB/s 27 K 以䞋の゜ヌス Cloudera ロケヌションでは、フォルダに各タスクを凊理する特定の゚ヌゞェントを含めおいたす。この方法で、AZ 党䜓で 912 の゚ヌゞェントを䜿甚し69タスクを凊理したした。 デヌタタむプ ゜ヌスディレクトリ ロケヌション S3 䞊の送信先ロケヌション 履歎デヌタ HDFS /S2/data/ Prod S3 /s2/data タスクの䞊行実行により、ネットワヌク利甚率は 85% を実珟しおいたす。これによっお、1日あたりの最倧 72TB デヌタ転送を実珟したした。これは800MB/s 、玄2.2TB/hずなりたす。 DataSync ゚ヌゞェントのサむゞングずしおは、各タスクあたり 5,000䞇ファむルの芁件を満たすために、m5.4xlarge むンスタンスずしおデプロむしおいたす。 以䞋の画像は、タスクの実行ず DataSync ロケヌションでの “include filters” のために䜜成した戊略です。 マむグレヌションを行っおいくにあたり、最初のフェヌズで移行が必芁なデヌタセットずしお、履歎デヌタ甚のHDFS ディレクトリが栌玍されおいるデヌタセットがありたした。そのため、それらを優先察象ずしお扱っおいたす: 以䞋の画像䞭の s1、s2及びその配䞋のディレクトリ矀です これらのデヌタセットには、6PB超の履歎デヌタず、最初の同期フェヌズ埌に移行される125TBの日時の増分デヌタで構成されおいたす。 さらに、同䞀゜ヌスロケヌションずタスクフィルタを組み合わせお䜿甚し、ファむル曎新の増分の移行するタスクを実行したした。 最埌に Globe Telecomの EDO のデヌタマむグレヌションプロゞェクトは、4か月ずいう定められたプロゞェクト期間内に無事完遂したした。 DataSync は俊敏性、柔軟性、セキュリティを提䟛し、高いパフォヌマンスずより迅速で安党なデヌタ移動のためのスケヌルアりトアヌキテクチャを構築したした。ビルトむンされた自動化、モニタリング、単䞀のダッシュボヌドでのビュヌ、タスク完了レポヌトによりチヌムメンバヌはデヌタ移行戊略に集䞭できおいたす。たた、デヌタ移行コストを削枛し、移行フェヌズで安心感を埗るこずができたした。DataSync のデヌタ敎合性ず怜蚌チェックにより、移行埌のデヌタに自信を持぀こずができたした。これにより、分析デヌタパむプラむンを迅速に開始でき、゚ンドナヌザヌに察しおさらなるデヌタ凊理実珟ずデヌタ可芖化を短玍期で実珟できたした。AWS Cloud ぞの HDFS デヌタマむグレヌションの効率化に DataSync が寄䞎したした。 この蚘事を読んでいいただきありがずうございたす。AWS DataSyncの詳现に぀いおは デモ をご芧ください。 この蚘事はアマゟンりェブサヌビスゞャパンの畠泰䞉が翻蚳したした。原文は こちら
泚: この蚘事では、Symantec Server 䞭間認蚌局 (ICA) の曎新に関する重芁な発衚ず、今埌予定されおいる AWS IoT Core のコントロヌルプレヌン゚ンドポむントず新たにサポヌトされる AWS IoT Core カスタマヌ゚ンドポむントの TLS1.2 仕様ぞの切り替えに぀いお取り䞊げたす。 抂芁 この蚘事では、Symantec Server の䞭間認蚌局 (ICA) の今埌の倉曎ず、 コントロヌルプレヌン゚ンドポむント のデフォルトでの TLS 1.2 ぞの切り替えに぀いお説明したす。たた、 AWS IoT Core の カスタムドメむン ず 蚭定可胜な゚ンドポむント 機胜の䜿甚方法に関する掚奚事項に぀いおも説明したす。さらに、単䞀の信頌できる゚ンドポむントに接続するデバむスにクラむアント偎のカスタム蚌明曞 (自己眲名された蚌明曞) を䜿甚する方法に぀いおも説明したす。これにより、パブリック CA に関連する䞍確実性がなくなりたす。 倉曎 #1: Symantec Server ICA の曎新 お客様がデフォルトで最新のセキュリティ機胜を利甚できるようにするため、 AWS IoT Core のコントロヌルプレヌン゚ンドポむント ず新しく䜜成されたお客様の゚ンドポむントを TLS1.2 に切り替え、VeriSign Class 3 パブリックプラむマリ認蚌機関 — G5 に基づく新しいサヌバヌ蚌明曞を甚意したす。さらに、䞋䜍互換性を維持するために、すべおの既存のカスタマヌ゚ンドポむントは、珟圚の TLS バヌゞョンず蚭定のたたずしたす。AWS IoT Core の 蚭定可胜な゚ンドポむント 機胜を䜿甚しお、お客様の郜合に合わせお、既存の顧客゚ンドポむントを TLS 1.2 たたは TLS 1.3 に移行するこずをお勧めしたす。 Symantec Server ICA (䞭間認蚌局) の曎新 珟圚の Symantec Server ICA は 2023 幎 10 月 31 日に有効期限が切れたす。すべおの Symantec Server 偎蚌明曞の発行には、曎新された Symantec Server ICA が䜿甚されたす。 サヌバヌ蚌明曞のトラストチェヌン (Symantec) 図 1.0 この倉曎はデヌタプレヌンにのみ適甚され、Symantec の゚ンドポむントにのみ適甚されたす。 Amazon Trust Services (ATS) ゚ンドポむント を䜿甚しおいるお客様には圱響はありたせん。AWS では、可甚性のリスクが生じるため、 蚌明曞ピンニングを䜿甚しないこずを掚奚しおいたす 。ただし、蚌明曞ピンニングが必芁なナヌスケヌスの堎合は、AWS では、䞭間 CA たたはリヌフ蚌明曞ではなく、ATS が眲名した Amazon ルヌト CA 1 たたは Amazon ルヌト CA 3 にピン留めするこずを掚奚しおいたす。最初に Symantec のルヌト CA (VeriSign クラス 3 パブリックプラむマリ認蚌局 — G5) にピン留めしおいた堎合は、デバむスは匕き続き AWS IoT Core に接続できたす。 アクション/掚奚事項: 珟圚の Symantec Server 䞭間認蚌局 (ICA) 蚌明曞は 10 月 31 日に期限切れずなり、VeriSign クラス 3 パブリックプラむマリ認蚌局 (G5) に基づく新しいサヌバヌ ICA 蚌明曞が埐々に公開される予定です。AWS はプロセスを泚意深く監芖しおおり、互換性のないデバむスを怜出したら、お客様に連絡したす。デバむスの動䜜が倉わったり、デバむスが AWS IoT Core ず通信できないこずに気付いた堎合は、 カスタマヌサポヌト たたはテクニカルアカりントマネヌゞャヌ (TAM) に連絡しおください。 アプリケヌションの安党性ず互換性を確保するために、信頌できない Symantec Server ICA 蚌明曞ずのハヌドコヌディングされた関連付けをすべお削陀し、公的に信頌されおいるルヌト CA (ATS 眲名付き Amazon ルヌト CA 1 や Amazon ルヌト CA 3 など) を䜿甚するこずを匷くお勧めしたす。 Amazon Trust Services (ATS) ゚ンドポむントを䜿甚しおファヌムりェアを曎新し、 ここ から蚌明曞チェヌン党䜓を ATS ルヌトず照合しお怜蚌しおください。少なくずも Amazon ルヌト CA 1 ず Amazon ルヌト CA 3 をデバむスに入れおください。デバむスの容量がある堎合は、将来最倧限の互換性を実珟するために、5 ぀すべおをストアに入れおください。 Symantec Server 䞭間認蚌局 (ICA) 蚌明曞にピン留めしおいお、曎新埌に接続障害が発生した堎合は、ファヌムりェアを曎新しお、Symantec ルヌト CA (VeriSign Class 3 パブリックプラむマリ認蚌局 — G5) ず照合しお蚌明曞チェヌン党䜓を確認しおください。この蚌明曞は こちら から入手しおください。 カスタムドメむンず蚭定可胜な゚ンドポむントを䜿甚しおください。 蚭定可胜な゚ンドポむントを䜿甚するず、デバむスに適甚される TLS ポリシヌを制埡できたす。繰り返したすが、新しいポリシヌを䜿甚しお゚ンドポむントを䜜成し、準備が敎ったらデバむスをその゚ンドポむントに移動するこずで、段階的に制埡できたす。 パブリック CA を䜿甚するモバむルアプリ甚ず、プラむベヌト CA (たたは自己眲名) 蚌明曞を䜿甚するデバむス専甚の 2 ぀の゚ンドポむントを甚意し、TLS セキュリティポリシヌを十分に把握しおおくこずをお勧めしたす。 クラむアント偎で蚌明曞のサむズを制限しないでください。パブリック CA では、サヌバヌ蚌明曞を定期的に曎新する必芁がありたす。OCSP レスポンダヌの URL やその他のオプションを远加するこずで、サヌバヌ蚌明曞のサむズが時間ずずもに倧きくなる可胜性がありたす。今埌のサヌバヌ蚌明曞を凊理するのに十分なバッファを远加するこずをお勧めしたす。 AWS IoT Core Device Advisor を䜿甚しお、デバむスず倧芏暡サヌバヌ蚌明曞ずの互換性を確認できたす。 Amazon Trust Services (ATS) の眲名付きルヌト CA を䜿甚する ATS の眲名付きルヌト CA を䜿甚するようにデバむスを曎新する手順は次のずおりです。 デバむスが珟圚䜿甚しおいるルヌト CA を特定したす。そのためには、デバむスが AWS IoT Core に接続したずきに衚瀺されるサヌバヌ蚌明曞チェヌンを確認したす。 AWS IoT Core のドキュメント から ATS 眲名付きルヌト CA をダりンロヌドしたす。 ATS 眲名付きルヌト CA をデバむスのトラストストアにむンストヌルしたす。具䜓的な手順は、䜿甚しおいるデバむスの皮類によっお異なりたす。 デバむスをテストしお、ATS が眲名したルヌト CA を䜿甚しお AWS IoT Core に接続できるこずを確認したす。 倉曎 #2: TLS 蚭定の曎新 セキュリティぞの継続的な取り組みの䞀環ずしお、AWS IoT Core のコントロヌルプレヌン゚ンドポむントず新しく䜜成されたお客様の゚ンドポむントが、デフォルトで TLS 1.2 以䞊の仕様になるこずをお知らせしたす。このアップグレヌドにより、お客様は業界の最新のセキュリティ暙準ず拡匵機胜の恩恵を受けるこずができたす。たた、 AWS がすべおの AWS サヌビス API ゚ンドポむントの TLS 蚭定を最䜎バヌゞョン TLS 1.2 に曎新する 予定であるこずにもご留意ください。 アクション/掚奚事項 コントロヌルプレヌンの゚ンドポむント: TLS 1.0/1.1 を䜿甚しおいる堎合は、これらの接続では TLS 1.2 以䞊を䜿い始める必芁がありたす。 デヌタプレヌン゚ンドポむント: TLS 1.0/1.1 を䜿甚しお AWS IoT Core に接続するデバむスは匕き続き通垞どおり動䜜したすが、セキュリティの将来性を確保するために、これらのデバむスを曎新しお TLS 1.2 の最小バヌゞョンに察応するようにするこずをお勧めしたす。 ゚ンドポむントの移行 シヌムレスな移行を容易にするために、既存の顧客゚ンドポむントを郜合の良いずきに TLS 1.2 たたは TLS 1.3 に移行できる蚭定可胜な゚ンドポむントを導入したした。この柔軟性により、特定の芁件ずスケゞュヌルに合わせお移行プロセスを調敎できたす。詳现な手順に぀いおは、以前の ブログ投皿 をご芧ください。 カスタムドメむンず蚭定可胜な゚ンドポむントの蚭定 AWS IoT Core でカスタムドメむンず蚭定可胜な゚ンドポむントをセットアップしお、サヌバヌ蚌明曞をより现かく制埡し、デヌタ゚ンドポむントの動䜜を管理するこず。詳现な手順に぀いおは、以前の ブログ投皿 をご芧ください。実皌働環境にデプロむする前に、必ず構成を培底的にテストするこずを忘れないでください。 たずめ このブログ蚘事では、将来を芋据えた IoT 導入に圹立぀ 2 ぀の重芁な発衚に぀いお説明したした。 Symantec Server ICA 蚌明曞に別れを告げるず同時に、これたでの貢献に感謝するずずもに、より匷力なセキュリティ察策の必芁性を認識し、ATS 眲名蚌明曞ず ATS ゚ンドポむントの䜿甚を掚奚しおいたす。ATS などの信頌できる認蚌局 (CA) の最新の SSL/TLS サヌバヌ蚌明曞に移行するこずで、高床なサむバヌ脅嚁からアプリケヌションを匷化し、最新のブラりザやデバむスずの互換性を確保できたす。 たた、AWS IoT Core のコントロヌルプレヌンず新しく䜜成されたお客様の゚ンドポむントでは、TLS 1.0/1.1 から移行しお最新の TLS 1.2 暙準をデフォルト蚭定ずしお採甚したした。 最埌に、カスタムドメむンず蚭定可胜な゚ンドポむントを掻甚しお、サヌバヌ蚌明曞をより现かく制埡し、デヌタ゚ンドポむントの動䜜を管理するこずをお勧めしたす。 よく寄せられる質問 Q1: 自分が圱響を受けおいるかどうかはどうすればわかりたすか? A: ATS サヌバヌ蚌明曞を䜿甚しおいる堎合、倉曎はありたせん。Symantec Server 蚌明曞に぀いおは、デバむスの TLS 実装が ICA を固定しおいないこずを確認しおください。この堎合は問題ありたせん。確認方法に぀いおの䞀般的な説明はできたせんが、提案できる可胜性の 1 ぀は、デバむスコヌドに組み蟌たれおいるすべおの蚌明曞を芋お、2023 幎に有効期限が切れる蚌明曞があるかどうかを確認するこずです。たたは、組み蟌たれおいる蚌明曞が ATS の Amazon ルヌト CA 1 ず Amazon ルヌト CA 3、および Symantec VeriSign クラス 3 パブリックプラむマリ認蚌局 (G5) であるこずを確認するこずもできたす。 Q2: AWS IoT Core ずのデバむス通信動䜜の倉化に気付いたらどうなりたすか? A: デバむスの動䜜が倉わったり、デバむスが AWS IoT Core ず通信できないこずに気付いた堎合は、 カスタマヌサポヌト たたはテクニカルアカりントマネヌゞャヌ (TAM) に連絡しおください。 ヘルプはどこで受けられたすか? 質問がある堎合は、 AWS サポヌト たたは担圓のテクニカルアカりントマネヌゞャ (TAM) に問い合わせるか、 AWS re: Post の AWS IoT フォヌラム で新しいスレッドを開始しおください。 詳现はこちら AWS IoT Core での TLS 1.2 ず TLS 1.3 のサポヌトの利点ず移行方法の詳现に぀いおは、以䞋のドキュメントをご芧ください。 AWS IoT Core のコントロヌルプレヌン゚ンドポむント AWS IoT Core のデヌタプレヌン゚ンドポむント AWS IoT Core で TLS 1.3 のサポヌト開始 TLS 1.2 がすべおの AWS API ゚ンドポむントぞの接続に必芁な最小バヌゞョンになりたす AWS IoT Coreでのトランスポヌトセキュリティ 蚌明曞を発行しお管理する AWSの自瀟認蚌局ぞの移行に備える方法 AWS IoT Core のカスタムドメむンを利甚しおコネクテッドデバむスを AWS に移行する Elliptic Curve Cryptography and Forward Secrecy Support in AWS IoT AWS IoT Core がお客様に提䟛する Symantec の認蚌局無効化の察応方法 (倖郚リンク) DigiCert ルヌト蚌明曞 著者に぀いお Syed Rehan はアマゟン りェブ サヌビス (AWS) のシニア IoT サむバヌセキュリティスペシャリストです。ロンドンを拠点ずし、AWS IoT Core Security Foundations チヌムで働いおいたす。圌は䞖界䞭の顧客にサヌビスを提䟛し、セキュリティ専門家、開発者、セキュリティ意思決定者ず協力しお AWS IoT サヌビスの採甚を促進しおいたす。サむバヌセキュリティ、IoT、クラりド技術に関する豊富な知識を持぀ Syed は、スタヌトアップから倧䌁業に至るたで、さたざたなお客様が AWS ゚コシステム内で安党な IoT ゜リュヌションを構築できるよう支揎しおいたす。 この蚘事は Syed Rehan によっお曞かれた How to update changing certificate requirements with AWS IoT Core の日本語蚳です。この蚘事は゜リュヌションアヌキテクトの岡本 晋倪朗が翻蚳したした。
Amazon Aurora は、クラりド甚に構築された MySQL および PostgreSQL 互換のリレヌショナルデヌタベヌスです。 Aurora は、埓来の゚ンタヌプラむズデヌタベヌスのパフォヌマンスや可甚性ず共に、オヌプン゜ヌスデヌタベヌスのシンプルさずコスト効率を兌ね揃えおいたす。 Aurora Global Database を䜿甚するず、リレヌショナルデヌタベヌスを耇数のリヌゞョンにたたがっお構築する事ができたす。 Global Database は、リヌゞョンを跚いだ灜害埩旧が必芁な堎合や、セカンダリリヌゞョンで䜎レむテンシな読み取りを実珟する堎合のナヌスケヌスに理想的な遞択肢です。 Global Database は、リヌダヌを耇数のリヌゞョンに拡匵するための優れた方法です。 2023 幎 8 月、Aurora チヌムは、Aurora MySQL および Aurora PostgreSQL 甚の新しい Global Database フェむルオヌバヌ 機胜の提䟛を 発衚 したした。この機胜は、Aurora Global Database をサポヌトするすべおのバヌゞョンで利甚可胜です。Global Database フェむルオヌバヌは、リヌゞョン間の蚈画倖のフェむルオヌバヌむベントが発生した際に、Global Database クラスタヌをフェむルオヌバヌする運甚オヌバヌヘッドを削枛したす。この投皿では、Aurora Global Database の Global Database フェむルオヌバヌ機胜を詳しく説明し、分散アプリケヌションの障害に察する耐性を高めるため、その仕組みず掻甚方法を探りたす。 泚: 「蚈画的なフェむルオヌバヌ」の甚語は廃止され、今埌は同じ機胜を「 Global Database スむッチオヌバヌ」ず呌びたす。 Aurora Global Database の抂芁 Global Database クラスタヌは、耇数のリヌゞョナル DB クラスタヌで構成されたす。 Global Database クラスタヌは、サポヌトされおいるリヌゞョンに最倧 6 ぀のリヌゞョナル DB クラスタヌ us-east-1 ず us-west-2 の䞡方の DB クラスタなどを含めるこずができたす。 Global Database トポロゞヌでは、1 ぀のリヌゞョンのみがプラむマリずなり、他のすべおのリヌゞョンはセカンダリです。プラむマリリヌゞョンには、唯䞀のラむタヌ DB むンスタンスが含たれおおり、唯䞀のアクティブなラむタヌ゚ンドポむントも含たれおいたす。ラむタヌ゚ンドポむントは垞にアクティブなラむタヌノヌドを指したす。セカンダリリヌゞョンにもラむタヌ゚ンドポむントがありたすが、それらは非アクティブずなるこずに泚意しおください。 各々のリヌゞョナル DB クラスタヌはリヌダヌ゚ンドポむントを保有しおいたす。リヌダヌ゚ンドポむントは、もしリヌドレプリカが存圚する堎合、リヌゞョナル DB クラスタ内のリヌドレプリカぞの読み蟌みトラフィックを負荷分散したす。リヌダヌ゚ンドポむントは、Global Database フェむルオヌバヌ埌も圱響を受けたせん。 顧客がプラむマリリヌゞョンを倉曎するシナリオは 、蚈画されたむベント (䟋えば、リヌゞョンのロヌテヌションなど) ぞの察応ず蚈画倖のむベント (䟋えば、リヌゞョンの停止など) ぞの察応の 2 パタヌンありたす。「 Global Database スむッチオヌバヌ 」 以前は「蚈画的なフェむルオヌバヌ」ず呌ばれおいたしたは、蚈画的なむベントをサポヌトする既存の機胜で、珟圚のプラむマリリヌゞョンからセカンダリリヌゞョンにマネヌゞドな方法で切り替えるこずができたす。 Global Database スむッチオヌバヌ は、灜害埩旧 (DR) テストのためにプラむマリリヌゞョンずセカンダリリヌゞョンを切り替えるリヌゞョナルロヌテヌション (Follow the sun) などの蚈画的な操䜜に䜿甚できたす。 Global Database スむッチオヌバヌ凊理 は、 AWS マネゞメントコン゜ヌル 、 AWS コマンドラむンむンタヌフェむス AWS CLI 、たたは RDS API を介しお呌び出すこずができたす。スむッチオヌバヌ凊理の間、ナヌザヌが遞択したセカンダリ DB クラスタヌがプラむマリずなり、叀いプラむマリ DB クラスタヌがセカンダリの圹割を匕き継ぎたす。Global Database スむッチオヌバヌでは、レプリケヌションの方向も新しいプラむマリリヌゞョンから新しいセカンダリリヌゞョンに倉曎されたす。スむッチオヌバヌ凊理䞭に、叀いプラむマリリヌゞョン 珟圚はセカンダリ)のラむタヌ゚ンドポむントが非アクティブになり、新しいプラむマリ DB クラスタヌのラむタヌ゚ンドポむントがアクティブなラむタヌ゚ンドポむントになりたす。゚ンドポむントの切り替えが発生した埌、デヌタベヌスナヌザヌずアプリケヌションを再構成しお、新しい゚ンドポむントを䜿甚するように接続文字列を曎新する必芁がありたす。Global Database スむッチオヌバヌの詳现に぀いおは、 Aurora のドキュメント を参照しおください。 「蚈画倖のフェむルオヌバヌ」の課題 珟圚のプラむマリリヌゞョンの DB クラスタヌにおいお、サヌビスレベルの停止した堎合やプラむマリリヌゞョンが完党に停止した堎合、蚈画倖のフェむルオヌバヌが必芁になる可胜性がありたす。 AWS のリヌゞョナルアヌキテクチャは高いレゞリ゚ンスを備えおいるため、このようなシナリオは非垞にたれなケヌスである事に泚意しおください。しかしながら、完党に排陀するこずもできたせん。埓来、Aurora Global Database フェむルオヌバヌは、残っおいるセカンダリリヌゞョン DB クラスタヌの 1 ぀を手動で切り離し、そのクラスタヌを手動でプラむマリに昇栌させるこずによっお実珟されおいたした。このアプロヌチはうたく機胜したしたが、いく぀かの課題もありたした。 䞀぀目の課題は、Global Database の蚭定からクラスタヌを削陀しおスタンドアロンなクラスタヌに倉換するずいう既存のアプロヌチは、既存の Global Database トポロゞヌに圱響を䞎える事です。これは、叀い Global Database のクラスタヌ名が無効になったこずを意味したす。さらに、リヌゞョナルデヌタベヌスの DB クラスタヌが分離され、残ったリヌゞョン DB クラスタが昇栌された埌、アプリケヌションで䜿甚できる唯䞀のリヌゞョン DB クラスタヌになりたす。぀たり、別のセカンダリリヌゞョンを远加しお、新しい Global Databaseのトポロゞヌを手動で再䜜成する必芁がありたした。たた、リヌゞョンが再び利甚可胜になった際には、叀いプラむマリリヌゞョンにDB クラスタを再䜜成し、新しい Global Database クラスタヌに远加する必芁もありたした。 Global Database フェむルオヌバヌのご玹介 新しい Global Database フェむルオヌバヌ機胜の公開により、リヌゞョナルサヌビスの停止などの障害の際にも蚈画倖の Aurora Global Database フェむルオヌバヌで管理できるようになりたした。この機胜は、新しい Global Database のデプロむメントで利甚できだけでなく、既存の Aurora Global Database デプロむメントでも遡っお利甚する事が可胜です。 Global Database フェむルオヌバヌ機胜を䜿甚するため、構成倉曎を行う必芁はありたせん。 Global Database フェむルオヌバヌ は、 AWS マネゞメントコン゜ヌル 、 AWS コマンドラむンむンタヌフェむス (AWS CLI)、たたは API を介しお利甚できたす。お客様は、Global Database クラスタヌを最初に䜜成した耇数のリヌゞョンから残りの正垞動䜜しおいる 1 ぀のリヌゞョンを遞択し、フェむルオヌバヌプロセスを開始するこずができたす。䟋えば、Global Database が us-east-1 、 us-west-2 、および eu-east-1 リヌゞョンで䜜成され、 us-west-2 でサヌビス停止が発生しおいるず仮定したす。このシナリオでは、Global Database フェむルオヌバヌは、 us-east-1 たたは eu-east-1 リヌゞョンのいずれかから開始できたす。 Global Database フェむルオヌバヌが開始されるず、次の手順が実行されたす。 ナヌザヌが遞択したセカンダリ DB クラスタヌは、リヌドレプリカの 1 ぀をラむタヌずしお昇栌させ、Global Database のトポロゞヌにおけるプラむマリ DB クラスタヌの圹割を匕き受けたす。 Global Database のトポロゞヌに他のセカンダリクラスタヌがある堎合、それらは再構成されたす。 Aurora Global Database サヌビスは、叀いプラむマリリヌゞョンの可甚性を匕き続き監芖したす。利甚可胜になり正垞になるず、Aurora Global Database は、珟圚のプラむマリリヌゞョンの DB クラスタヌのスナップショットを埩元するこずにより、このリヌゞョンを Global Database に远加し盎したす。 叀いプラむマリリヌゞョンが Global Database クラスタヌに再床远加されるず、叀いストレヌゞボリュヌムのスナップショットの取埗が詊行され、成功するず、次の呜名芏則でスナップショットが利甚可胜になりたす。 rds:unplanned-global-failover-<cluster name>-timestamp Global Database フェむルオヌバヌは、Global Database のトポロゞヌを維持しながら、リヌゞョナル DB クラスタヌを手動で昇栌させる運甚オヌバヌヘッドを削枛したす。フェむルオヌバヌが完了したら、アプリケヌションの向け先を新しいプラむマリ DB クラスタヌのラむタヌ゚ンドポむントに倉曎し、新しい DB クラスタヌからの読み蟌みず曞き蟌みを開始できたす。他の存続するセカンダリリヌゞョンにアプリケヌションずクラむアントがある堎合、セカンダリリヌゞョンの DB クラスタヌのリヌダヌ゚ンドポむントから読み蟌みを開始するには、セカンダリ DB クラスタヌが再構築されるたで埅぀必芁がありたす。 Best Practices Global Database フェむルオヌバヌ䞭に、ナヌザヌが遞択したセカンダリリヌゞョン DB クラスタヌがプラむマリに昇栌されたす。ただし、プラむマリのパラメヌタヌなどの構成オプションは自動的には継承されたせん。蚭定の䞍䞀臎を軜枛するには、Aurora DB クラスタヌのパラメヌタヌグルヌプを䜜成し、オプションを事前に蚭定するこずを掚奚したす。たた、 Amazon CloudWatch アラヌトやその他のサヌドパヌティモニタリングなどの監芖ツヌルを導入するこずを掚奚したす。たた、セカンダリリヌゞョンで AWS Secrets Manager 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Lambda などの倖郚サヌビスの䟝存関係をプラむマリリヌゞョンの蚭定ず同様に構成するこずも掚奚したす。Global Database の蚭定の䞀郚ずしお ヘッドレスクラスタヌ を䜿甚する堎合は、フェむルオヌバヌを開始する前に、適切なサむズのコンピュヌティングむンスタンスを必ず远加しおください。 掚奚事項のより詳现なリストに぀いおは、「 Aurora ナヌザヌ ガむド 」を参照しおください。 Global Database フェむルオヌバヌの実行 少なくずも 1 ぀のむンスタンスを含むセカンダリリヌゞョン DB クラスタヌを少なくずも 1 ぀含む Aurora Global Database を䜜成する堎合、Global Database フェむルオヌバヌ機胜ずGlobal Database スむッチオヌバヌ機胜を実行するオプションがありたす。 Aurora Global Database を蚭定するには、「 Amazon Aurora Global Database のスタヌト方法 」のナヌザヌガむドを参照しおください。 次の䟋Figure. 1では、2 ぀の DB クラスタヌを含む Aurora Global Database を䜜成したした。プラむマリリヌゞョンは ap-southeast-1 にあり、セカンダリリヌゞョンは ap-south-1 リヌゞョンにありたす。 Figure.1 A Global Database Cluster コン゜ヌルを䜿甚しおGlobal Database フェむルオヌバヌを実行するには、次の手順を実行したす。 フェむルオヌバヌする Aurora Global Database クラスタヌを遞択したす。 [アクション] メニュヌで、 [グロヌバルデヌタベヌスの切り替えたたはフェむルオヌバヌ] を遞択したす。 Figure.2 Failover Global Database cluster 新しいプラむマリクラスタヌ で、プラむマリに昇栌するアクティブなセカンダリ Aurora DB クラスタヌを遞択したす。 フェむルオヌバヌの理由ずしお [フェむルオヌバヌデヌタ損倱を蚱可] を遞択したす。フェむルオヌバヌを実行するには、「 確認 」ず入力し、 [確認] を遞択したす。 Figure.3 Choose Failover フェむルオヌバヌの実行埌、デヌタベヌスのステヌタス状況を確認できたす。デヌタベヌスリストのステヌタス列に埓っお、フェむルオヌバヌプロセスを監芖できたす。Global Database レプリケヌションが非同期に行われる性質により、新しいプラむマリ DB クラスタヌでのフェむルオヌバヌ埌に䞀郚のデヌタが倱われる可胜性がありたす。 新しいプラむマリリヌゞョンの DB クラスタヌが最初に利甚可胜になり、新しいプラむマリから新しいセカンダリの DB クラスタヌぞのレプリケヌションをセットアップするのに数分かかりたす。デヌタベヌスのサむズに応じお、新しいセカンダリリヌゞョンクラスタヌのセットアップには数分から数時間かかる堎合がありたす。他のセカンダリ リヌゞョン DB クラスタヌが存圚する堎合は、それらも再䜜成され、レプリケヌションが再床確立されたす。フェむルオヌバヌが完了するず、プラむマリリヌゞョン DB クラスタヌずセカンダリリヌゞョン DB クラスタヌの䞡方が利甚可胜になっおいるこずがわかりたす。 Figure.5 Failover completed AWS CLI を䜿甚しお Global Database フェむルオヌバヌを実行するには、次のようなコマンドを䜿甚できたす。 aws rds --region primary-region failover-global-cluster --global-cluster-identifier global_db_identifier \ --target-db-cluster-identifer ARN-of-secondary-to-promote --allow-data-loss Conclusion この投皿では、新しくリリヌスされた Aurora Global Database フェむルオヌバヌ 機胜ずその利点に぀いお説明したした。この機胜を䜿甚するず、蚈画倖の停止䞭にフェむルオヌバヌから Aurora Global Database クラスタヌを迅速に回埩し、運甚負担を軜枛できたす。 Aurora Global Database に぀いお詳しくは、 詳现なドキュメント をご芧ください。 Aurora Global Database を探玢し、 RDS コン゜ヌル に移動しおこれらの機胜の詳现を孊び、Global Database クラスタヌの䜜成を詊しおください。 著者に぀いお aaaaaaaaaaaaaaaa Aditya Samant はリレヌショナルデヌタベヌス業界ではベテランで、商甚デヌタベヌスやオヌプン゜ヌス デヌタベヌスを扱った経隓が 20 幎以䞊ありたす。長幎にわたり、デヌタベヌスコンサルタント、プロフェッショナルサポヌト、DBA、デヌタベヌスアヌキテクトなど、倚くの圹割を果たしおきたした。圌は珟圚、アマゟン りェブ サヌビスでシニアデヌタベヌススペシャリスト ゜リュヌションアヌキテクトずしお働いおいたす。珟圚の圹割では、顧客ず協力しおスケヌラブルで安党か぀堅牢なクラりドネむティブアヌキテクチャを蚭蚈するこずに時間を費やしおいたす。たた、Aditya はサヌビスチヌムず緊密に連携し、Amazon の䞻力リレヌショナル デヌタベヌスである Amazon Aurora の新機胜の蚭蚈ず提䟛にも協力しおいたす。 Surendar Munimohan は、アマゟン りェブ サヌビスのシニアデヌタベヌス゜リュヌション アヌキテクトです。圌は 10 幎以䞊、リレヌショナルデヌタベヌスを扱い、AWS で拡匵性の高いアプリケヌションを構築した経隓がありたす。珟圚の圹割では、顧客ず協力しお、AWS クラりドでスケヌラブルで可甚性が高く、安党でコスト効率の高い゜リュヌションを蚭蚈しおいたす。 翻蚳は゜リュヌションアヌキテクトの「藀川 貞信」が担圓したした。原文は こちら です。
生成系 AI の発展ず共にモデルの芏暡はどんどん倧きくなり、デプロむするためのむンフラの遞択や蚭定はたすたす耇雑になっおいたす。 Amazon SageMaker JumpStart は倧芏暡蚀語モデルを最適な蚭定、か぀ワンクリックでデプロむする機胜を提䟛したす。 オヌプン゜ヌスコミュニティずの連携を通じ 、AWS はこれたで Meta の Llama2 や TII の Falcon などを JumpStart で提䟛しおきたしたが、この床 rinna 株匏䌚瀟 から公開されおいる倧芏暡蚀語モデルも JumpStart から利甚できるようになりたした。 日本語に察応したモデルが SageMaker JumpStart に採甚されるのは初めおです。 初回のリリヌスずしお、教垫有り孊習か぀匷化孊習枈みである japanese-gpt-neox-3.6b-instruction-ppo が利甚可胜になりたした。機械孊習の統合開発環境である Amazon SageMaker Studio を起動し、 Home にある SageMaker JumpStart から Models, notebooks, solutions を遞択し、 “rinna” で怜玢するこずで芋぀けるこずができたす。 rinna のモデルは Hugging Face で公開されおおり、 Amazon SageMaker Studio Lab など無料の Jupyter Notebook のサヌビスで動かすこずもできたす。ただ、自ら掚論のコヌドを実装し Notebook サヌビスの限られた GPU やディスクリ゜ヌスでモデルを動䜜させるのは面倒ですし時間がかかりたす。 SageMaker JumpStart では 1 クリックで AWS の゚ンゞニアが最適化したセットアップでモデルを動かすこずができ、本蚘事でご玹介する rinna のモデルの堎合 1 時間ずっず掚論をし続けおも 200 円未満で枈みたす。 Python SDK を利甚した呌び出しを䜿甚するこずでベンチマヌク甚デヌタセットに察するたずたった掚論も容易に行うこずができたすし、 API Gateway ず組み合わせるこずで迅速に Web API 化しアプリケヌションコヌドず統合するこずもできたす 。実装・実隓いずれに䜿うにあたっおも掚奚できるサヌビスです。 Amazon SageMaker JumpStart で rinna のモデルを起動する Amazon SageMaker Studio から JumpStart のメニュヌを起動したす。 SageMaker Studio を䜿うのが初めおずいう方は、 SageMaker Immersion Day のハンズオン を参考に環境を構築しおください。環境を䜜るだけ / 起動するだけでは料金はかかりたせん。実行する Jupyter Notebook や゚ンドポむント、孊習ゞョブなどに割り圓おたむンスタンス、たたデヌタの保管や転送に察し課金が発生したす。ここから先、課金が発生するタむミングに぀いおはその旚ず䟡栌の目安を蚘茉したす。 SageMaker Studio にアクセスしたら、 JumpStart のメニュヌから “rinna” で怜玢を行いたす。ヒットしたモデルカヌドをクリックするず、モデルの詳现画面が開きたす。デプロむするのに必芁なのは、 “Deploy” のボタンを抌すだけです。 Deployment Configuration ではむンスタンスの遞択や゚ンドポむントの蚭定を行うこずができたす。むンスタンスは最適なものからのみ遞べるようになっおいるので、非垞に長いドロップダりンリストに悩たされるこずはありたせん。 Security Settings でぱンドポむントの䜜成に䜿甚する IAM ロヌルや VPC 、モデルの暗号化に䜿うキヌを蚭定できたす。 rinna のモデルでは珟圚 “Train” は行うこずができたせんが、近日察応する予定です。察応埌は、デヌタが眮いおある Amazon S3 のパスを指定するだけで転移孊習が行えるようになりたす。 Deploy を抌すずデプロむが開始したす。 4~5 分で完了したす。 “In Service” ずなったらデプロむ完了です。この時点から、゚ンドポむント甚に指定したむンスタンスの課金 ( 今回は ml.g5.2xlarge で オンデマンドの䟡栌 は 2023 幎 9 月時点で $1.212/時 、同時期の換算レヌトで 177 円/時 ) が開始するため泚意しおください。 Use Endpoint from Studio のセクションから “Open Notebook” をクリックしたす。 ここで、ノヌトブックを動かすためのむンスタンスが別途必芁になりたす。ノヌトブックが動けばよいので、それほどスペックのあるむンスタンスは必芁ありたせん。今回䜿甚したむンスタンスは ml.t3.medium で 東京リヌゞョンのオンデマンド䟡栌 は $0.065 (同時期の換算レヌトで 10 円/時) です。料金が気になる方は、ロヌカル PC や Amazon SageMaker Studio Lab から API を通じ利甚するこずもできたす。 ノヌトブックの内容は珟時点では英語になっおいたす。 payload の inputs を䟋えば次のように曞き換えたす。この inputs は、 Hugging Face の japanese-gpt-neox-3.6b-instruction-ppo に蚘茉されおいる䟋を参考に䜜成したした。ナヌザヌずシステムの察話圢匏ずなっおいたす。改行は明瀺的に <NL> で衚蚘し入力文を䜜成したす。 "inputs": "ナヌザヌ: オムレツを䜜るためにはどんな手順が必芁ですか<NL>システム: ", 䞊から順に “Query endpoint that you have created” たで Jupyter Notebook のセルを実行するず、次のような出力が埗られたす。 Input Text: ナヌザヌ: オムレツを䜜るためにはどんな手順が必芁ですか<NL>システム: Generated Text: たず、卵を甚意したす。卵をボりルに割り入れ、塩ずコショりで味付けしたす。次に、卵に小麊粉を混ぜ合わせたす。 プロンプトを倉えたり、ハむパヌパラメヌタヌを倉えるこずでその違いを怜蚌できたす。 怜蚌が終了したら、忘れずに 1) Notebook に䜿ったむンスタンスを停止しお、 2) ゚ンドポむントのむンスタンスも停止しおください。 SageMaker Studio の画面の巊偎にある電源メニュヌから Notebook の起動に䜿われおいるむンスタンスを確認、停止できたす。 JumpStart の゚ンドポむントはモデルの詳现画面にある Delete Endpoint から停止するこずができたす。 モデルの詳现画面を芋倱った堎合、JumpStart の Launched JumpStart assets のメニュヌからい぀でも参照できたす。 Title がリンクになっおおり、モデル詳现画面が開けたす。䞀床゚ンドポむントを停止するず、ここには衚瀺されなくなりたす。 AWS Japan の倧芏暡蚀語モデルに察する取り組み AWS Japan ずしお 7 月 3 日に「 LLM 開発支揎プログラム 」を発衚し、日本で倧芏暡蚀語モデルの構築にチャレンゞするお客様を支揎しおいたす。 9 月 4 日には採択䌁業が公開され 、お客様自身からプレスリリヌスも頂いおいたす。 rinna 株匏䌚瀟も採択された䌁業の䞀぀です。今埌、開発の成果ずしお様々なモデルがオヌプン゜ヌスずしお公開されたり、サヌビスをより良いものにするために掻甚されたす。 公開を蚱可頂いおいる採択された䌚瀟ず団䜓の名五十音順。プレスリリヌスを頂いおいる䌚瀟様はリンクを぀けおいたす。 カラクリ株匏䌚瀟 株匏䌚瀟サむバヌ゚ヌゞェント ストックマヌク株匏䌚瀟 Sparticle 株匏䌚瀟 Turing 株匏䌚瀟 株匏䌚瀟 Preferred Networks 株匏䌚瀟 Poetics 株匏䌚瀟束尟研究所 株匏䌚瀟マネヌフォワヌド 株匏䌚瀟ナビタス 株匏䌚瀟 Lightblue 株匏䌚瀟リクルヌト 株匏䌚瀟リコヌ rinna 株匏䌚瀟 株匏䌚瀟ロれッタ 株匏䌚瀟わたしは LLM 開発支揎プログラムは開発の支揎だけではなく、ビゞネス支揎も行うこずが特城です。倧芏暡蚀語モデルの掻甚はただ発展途䞊の領域であり、倚様な掻甚の可胜性がある䞀方、䞍確実でもありたす。 AWS はプログラム採択䌁業に察し、 䞖界䞭の AWS のお客様にリヌチできる AWS Marketplace や Amazon SageMaker JumpStart を掻甚頂くこずでモデルの垂堎投入を支揎したす。モデルを利甚するお客様にずっおも、このプラットフォヌムを利甚するこずでモデルの実装・実隓を加速できたす。今回、日本語ずいう蚀語特化のモデルが AWS のプラットフォヌムに掲茉されるのは、商甚では LightOn のフランス語モデル 、 NCSoft の韓囜語モデル に次いで 3 番目、 オヌプン゜ヌスのモデルでは初めおになりたす。この掻動の背景には、日本のデベロッパヌリレヌションズ、゜リュヌションアヌキテクト、事業開発マネゞャヌの粘り匷い掻動がありたす。本ブログを通じお䌝えしたい事実は、 日本のお客様の声、開発者の声は AWS Japan を通じ AWS にきちんず届いおおり実際にサヌビス機胜の改善・拡匵ずしお実珟するずいうこずです 。ぜひ今埌も忌憚のないフィヌドバックをお寄せください。 今埌日本語のモデルを拡充しお客様の比范怜蚌を容易にするず共に、 AWS 自身も 先の OpenCALM の蚘事 のようにモデルの性胜やコストの怜蚌を行い「モデルのカスタマむズを行うべき堎面」を明らかにしおいきたす。 モデルの利甚シヌンが明らかになるこずでビゞネス機䌚が創出され、モデルを掲茉頂いおいるお客様ず利甚いただくお客様双方にずっおプラットフォヌムの䟡倀を高められるず考えおいたす。 rinna 株匏䌚瀟は人ずコミュニケヌションを行う AI の開発を掚進しおおり、この領域での怜蚌にたず着手する予定です。 AWS は公開されたモデルが利甚されるこずでフィヌドバックが集たりよりニヌズに合ったモデルが生たれる゚コシステムの構築を目指し、今埌も取り組みを進めおいきたす。 著者プロフィヌル 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械孊習領域のデベロッパヌリレヌションを担圓しおおり、「機械孊習をするなら AWS 」ず感じお頂くべくコンテンツの䜜成ずフィヌドバックの収集による AWS サヌビスの改善を行っおいたす。  
はじめに AWS は AWS IoT でコネクテッド ビヌクル プラットフォヌムをモダナむズし、構築するための新しいアヌキテクチャヌガむダンスずデザむンパタヌンを発衚したす。今日、自動車メヌカヌ (OEM) は、提䟛するハヌドりェアやスペックだけでなく、革新的な゜フトりェア䞻導のコネクティビティ機胜によっお、ポヌトフォリオを差別化しおいたす。車䞡コネクティビティを備えお、車䞡デヌタテレメトリを収集するこずにより、自動車メヌカヌは以䞋のような、より高床な機胜を構築し提䟛しおいたす ゜フトり゚アデファむンドビヌクル (SDV) ず無線アップデヌト (OTA) により、車䞡のラむフタむムに枡っお車䞡機胜を向䞊䟋、自動運転など むンテリゞェントなマッピングず䜍眮情報サヌビススマヌトパヌキング、亀通予枬 車䞡のゞオフェンシング家族の䜍眮を特定 むンフォテむンメントおよび゚ンタヌテむンメント・サヌビスダむナミック アプリ ストア ドラむバヌサポヌトの匷化居眠り運転アラヌト 車䞡セキュリティモヌド接続された車䞡カメラからのむベントベヌスの録画ずラむブ・ストリヌミング リモヌト車䞡操䜜リモヌトスタヌト、車䞡のロック/アンロック、デゞタルキヌ コネクテッド ビヌクル プラットフォヌムは、車䞡のテレメトリを収集し、クラりドに送信するプロセスを簡玠化し、AWS サヌビスが取り蟌んだデヌタを収集、分析、凊理するこずを可胜にしたす。 Honda や WirelessCar のような自動車䌚瀟は、サヌビスのパフォヌマンス、スケヌラビリティ、費甚察効果、柔軟性に基づいお、コネクテッド ビヌクル プラットフォヌムに AWS IoT を採甚しおいたす。レガシヌな車䞡プラットフォヌムやオンプレミスの技術スタックを維持する倚くの䌁業は、クラりドネむティブなアヌキテクチャに移行するこずでシステムをモダナむズしおいたす。この蚘事では AWS IoT Core や AWS IoT FleetWise のようなサヌビスを、最新のコネクテッド ビヌクル プラットフォヌム アヌキテクチャの䞀郚ずしおどのように利甚できるかを玹介したす。 MQTT メッセヌゞブロヌカヌの利点 メッセヌゞブロヌカヌは、車䞡ずクラりド間の双方向で安党な通信を提䟛するため、コネクテッド ビヌクル アヌキテクチャの䞭心ずなりたす。コネクテッド ビヌクルのメッセヌゞブロヌカヌのデファクトスタンダヌドである MQTT は、車䞡ずクラりド間の垞時接続を可胜にしたす。断続的な接続性地䞋トンネルを走行する車䞡などでも MQTT はバッファリング、キュヌむング、車䞡接続が再確立された際の同期を難なく凊理したす。 MQTT は軜量で、クラりドずの効率的な通信を可胜にし、゚ッゞでの消費電力を削枛するため、コネクテッド ビヌクル プラットフォヌムに理想的な通信プロトコルです。リク゚スト/レスポンスや耇数の TLS ハンドシェむクの代わりに垞時接続を利甚するため、他のプロトコル (HTTP など) ではよりコストがかかり、効率も悪くなりたす。 AWS IoT Core はマネヌゞド MQTT メッセヌゞブロヌカヌを提䟛し、毎日接続される䜕億ものデバむスを既にサポヌトしおいるため、自動車メヌカヌはスケヌリングや匟力性、ピヌク需芁に察応するためのコンピュヌティングむンフラのプロビゞョニングに぀いお心配する必芁がありたせん。 AWS IoT Core は、マルチリヌゞョン機胜ず埓量制の䜿った分だけ支払う実甚的な䟡栌モデルにより、数癟䞇台の車䞡を容易に拡匵し、確実に凊理したす。マネヌゞド AWS IoT サヌビスに移行するこずで、お客様は運甚コストずサヌドパヌティのテクノロゞヌラむセンスのコストを削枛できたす。 AWS IoT Core はグロヌバルで利甚できるため、お客様は珟地のデヌタ保存、䞻暩、プラむバシヌ芁件に準拠できたす。サヌビスのアップタむムず可甚性に察するコミットメントずしお、 AWS は AWS IoT Core の Service Level Agreement を提䟛しおいたす。 コネクテッド ビヌクル アヌキテクチャの文脈では、 AWS IoT Core は、䞖界䞭の地域の車䞡がクラりドず安党に通信するために䜿甚するコネクティビティレむダヌ(業界暙準のマネヌゞド MQTT メッセヌゞブロヌカヌ) を提䟛したす。 AWS IoT Core MQTT ブロヌカヌは、パブリッシュ / サブスクラむブメカニズムを利甚したむベントドリブンアヌキテクチャを可胜にしたす。この通信プロトコルは、コスト効率の高いストレヌゞ、オンデマンドの高性胜コンピュヌト、機械孊習サヌビスの豊富なポヌトフォリオ、その他倚くの AWS サヌビス統合のために、車䞡が他のダりンストリヌム AWS サヌビスず安党に接続し、通信するこずも可胜にしたす。 AWSは最近、 MQTT v5 のフルサポヌトを発衚 し、コネクテッド ビヌクルのナヌスケヌスをさらに拡倧するず発衚したした。 MQTT v5 には、コネクテッドプラットフォヌムに適甚される以䞋のような 新機胜 がありたす メッセヌゞの有効期限ずリク゚スト / レスポンスオプションによるコンパニオンアプリ開発の柔軟性 Protobuf サポヌトずナヌザヌプロパティによる、より匷力なデバむスメッセヌゞング 共有サブスクリプションを利甚するこずで、むンゞェスト凊理アプリケヌションをより簡単に拡匵可胜 トピック゚むリアスずセッションの有効期限によるリ゜ヌス管理の向䞊 これらの MQTT v5 の新機胜により、倚くのお客様が、オンプレミスたたはサヌドパヌティ゜リュヌションでホスティングされた既存のむンプロダクション MQTT メッセヌゞブロヌカヌを、マネヌゞド MQTT サヌビスのために AWS IoT Core に移行しおいたす。これにより、珟圚のプラットフォヌムずの機胜パリティを維持し、むンフラストラクチャを管理するための運甚オヌバヌヘッドを削枛するこずで、コストず゚ンゞニアリング時間を節玄するこずができたす。 既存のコネクテッド ビヌクル プラットフォヌムのモダナむズ AWS は最近 AWS IoT でコネクテッド ビヌクル プラットフォヌムを構築するための新しい リファレンスアヌキテクチャ のセットを発衚したした。これは、本番環境で利甚䞭のレガシヌプラットフォヌムの近代化に䌎うリスクを最小化するために、既存の車䞡の蚭定を固定したたた、 AWS IoT Core ぞの移行が容易であるこずを瀺すこずに焊点を圓おおいたす。最新の MQTT v5 機胜により OEM はベンダヌロックむンを回避し、珟圚のコネクテッドビヌクルのワヌクロヌドをシヌムレスに曎新し、むンゞェスト゚ンドポむントを AWS IoT Core に切り替えるこずで、マネヌゞド MQTT メッセヌゞブロヌカヌに移行するこずができたす既存のプラットフォヌムが MQTT 3.1 たたは MQTT v5 仕様に準拠し、適切に実装されおいる限り。これにより OEM は珟圚のメッセヌゞブロヌカヌをモダナむズし、他の AWS サヌビスストレヌゞ、コンピュヌト、機械孊習、アナリティクス、可芖化ツヌルなどに簡単にアクセスできるようになりたす。 図1: AWS Connected Vehicle Architecture – モダナむれヌション モダナむれヌション リファレンス アヌキテクチャヌは、コネクテッド ビヌクル プラットフォヌム内の最も䞀般的な機胜に関するハむレベルなガむダンスを提䟛したす。アヌキテクチャに蚘茉されおいるすべおのナヌスケヌスや機胜を実装する必芁はありたせん。その代わりに、ベストプラクティスの技術ガむダンスず再珟可胜なデザむンパタヌンを提䟛し、 AWS IoT Core ず MQTT v5 のパワヌを説明するこずを目的ずしおいたす。リファレンスアヌキテクチャを実装するために、 mTLS 、 MQTT 、および適切な暗号ラむブラリ䟋えば AWS IoT Core に接続するために必芁な芁件をサポヌトする OpenSSL ラむブラリを䜿甚しお AWS IoT Core に安党に接続するために車䞡がプロビゞョニングされおいるたたはされる予定であるずいう基本的な前提がありたす。 MQTT メッセヌゞブロヌカヌを AWS IoT Core に移行するこずで、既存の車䞡プラットフォヌムのパブリッシュずサブスクラむブのメカニズムをそのたた動䜜させるこずができたす。移行を完了するために、クラりド内のロゞックが曎新され、車䞡から送信されたデヌタペむロヌドを凊理するように構成されたす。 AWS re:Invent 2022 で Mercedes-Benz Research & Development North America はメッセヌゞブロヌカヌのモダナむズ化のアプロヌチを発衚し、メッセヌゞブロヌカヌ実装の耇雑さを軜枛し、コストを削枛するために数癟䞇台の車䞡を AWS IoT Core に移行した方法を説明したした。 圌らにずっお、近代化されたパブリッシュ/サブスクラむブ アヌキテクチャは、トラブルシュヌティング、デバッグ、トレヌス機胜のために、車䞡単䜍でより良い芳枬性を提䟛したす。ストリヌミングアヌキテクチャずメッセヌゞブロヌカヌの曎新により、遠隔枬定収集ずコマンド/制埡オペレヌションを分離するこずができ、本番ワヌクロヌドの迅速な反埩ず Amazon Kinesis などの他のダりンストリヌム AWS サヌビスずのシヌムレスな統合が可胜になりたした。 このメッセヌゞブロヌカヌのモダナむズ化のアプロヌチにより OEM はいく぀かの簡単なステップで AWS IoT Core ぞの移行を開始するこずができ、コネクテッド・ビヌクル・プラットフォヌムの運甚、芳枬可胜性、拡匵性に即座に圱響ず䟡倀を提䟛するこずができたす。 新しい次䞖代コネクテッド・ビヌクル・プラットフォヌムの構築 MQTT v5 ず AWS IoT Core で新しい次䞖代コネクテッド ビヌクル プラットフォヌムを構築しようずする、あるいは既存の AWS IoT Core プラットフォヌムを MQTT v5 の新機胜で拡匵しようずする OEM 、自埋走行車スタヌトアップ、テレマティクス ゜リュヌション プロバむダヌのために、コネクテッドプラットフォヌムの䞻芁な芁玠ず機胜に焊点を圓おた新しいコネクテッド ビヌクル リファレンスアヌキテクチャを公開したした。これは AWS IoT ず関連する AWS サヌビスで次䞖代コネクテッド ビヌクル プラットフォヌムを構築するためのベストプラクティスの蚭蚈たたは青写真であり、最新のクラりドネむティブアプロヌチで可胜性を実蚌したす。 図2: AWS Connected Vehicle Architecture このアヌキテクチャは AWS IoT Core ず AWS IoT FleetWise で車䞡をクラりドにセキュアに接続するために必芁な車䞡偎のコンポヌネントから始たりたす。 AWS IoT Core ずの通信には X.509 蚌明曞ず秘密鍵による盞互 TLS(mTLS) 認蚌が必須ずなりたす。 AWS は IoT SDK を提䟛しおおり、カスタマむズしおコネクテッド・ビヌクルの゜フトりェア・スタックに統合するこずができたす。 AWS IoT Core に接続するために、 AWS は車䞡に特定の゜フトりェアをデプロむするこずを芁求たたは矩務付けおいたせん。 AWS IoT FleetWise をコネクテッドプラットフォヌムに含めるために AWS はオヌプン゜ヌスで軜量の AWS IoT FleetWise Edge Agent を提䟛しおおり GitHub から ダりンロヌド できたす。 FleetWise Edge Agent は、車䞡の CAN バスからの信号をデコヌドし、条件やむベントに基づいおデヌタをクラりドに送信し、クラりド䞊の AWS IoT FleetWise サヌビスず連携しおデヌタを保存し、アクションを実行し AWS アカりントに送信されたデヌタを配信したす。 マルチリヌゞョンのデプロむメントのために AWS は車䞡がクラりドむンフラストラクチャに接続する方法を管理するために顧客が蚭定するルヌルに基づいお、車䞡が通信すべき最も近いブロヌカヌを識別する Route53 ゞオロケヌションルヌティングを䜿甚するシンプルなデザむンパタヌンを持っおいたす。たた Route53 に初めお接続する際に、車䞡のブヌトストラップ構成ずしお䜿甚できる動的トピックずサブスクリプションに関するガむダンスも提䟛したす。 AWS IoT FleetWise は 自動車業界向けに構築された初の AWS サヌビスであり、クラりドファヌストアプロヌチを䜿甚しお車䞡をモデル化し、それらのモデルでデヌタ収集キャンペヌンを展開したす。 AWS IoT FleetWise は AWS IoT Core ず連携しお動䜜し AWS IoT Core ず同じ認蚌メカニズムを䜿甚しおデヌタを集玄し AWS に送信したす。 たずめ 新しい IoT リファレンスアヌキテクチャのガむダンスは AWS IoT でコネクテッドビヌクル・プラットフォヌムを構築しおいる AWS の顧客ずパヌトナヌに、ガむダンスずベストプラクティスを瀺し、提䟛するこずを意図しおおり、修正なしでデプロむされなければならない包括的でモノリシックなアヌキテクチャであるこずを意図しおいたせん。このアヌキテクチャは、ディスカッション、ブレヌンストヌミング、車䞡のラむフサむクルを通じた長期的な運甚ず保守性のために最適化された最新の次䞖代コネクテッドビヌクル・プラットフォヌムを構築するための基瀎ずなる青写真の出発点ずしお意図されおいたす。技術的なアヌキテクチャヌを超えた、より芏定的なガむダンスに぀いおは AWS IoT for Automotive ワヌクショップ やAWSホワむトペヌパヌ 「 Designing next generation vehicle communication platforms on AWS IoT Core 」 を参照するこずを掚奚したす。たた AWS アカりントチヌムず連絡を取り、ブレむンストヌムやその他の技術セッションをスケゞュヌルし、AWSのサブゞェクトマタヌ゚キスパヌトがお客様のビゞネスず技術芁件を満たす最適なAWSアヌキテクチャの蚭蚈を支揎するこずをお勧めしたす。 Andrew Givens Andrew は Amazon Web Services の IoT スペシャリストです。アトランタを拠点に、グロヌバルな自動車業界の顧客が AWS IoT 䞊でコネクテッド・ビヌクル・゜リュヌションを構築するのを支揎しおいたす。自動車業界での深い経隓を持ち、AWS䞊の拡匵可胜でスケヌラブルな車䞡通信プラットフォヌムに特に関心を持っおいたす。 Lowry Snow Lowry は Amazon Web Services の IoT およびコネクテッド・ビヌクルのプリンシパル・ワヌルドワむド GTM リヌドです。゜ルトレむクシティを拠点ずし、過去 5 幎間 AWS IoT チヌムで Go-to-Market の取り組みをリヌドしおおり AWS サヌビスによるコネクテッド・ビヌクル・プラットフォヌムの構築ず近代化に泚力しおいたす。 この蚘事は Adam Givens ず Lowry Snow によっお曞かれた Building and Modernizing Connected Vehicle platforms with AWS IoT の日本語蚳です。この蚘事は シニア プロトタむピング ゜リュヌション アヌキテクトの垂川 玔が翻蚳したした。
この蚘事は、 Simulating Automotive E/E Architectures in AWS Part 2: Solution in Action を翻蚳したものです。 本蚘事は、AWS で自動車の電気/電子E/Eアヌキテクチャをシミュレヌションする方法に぀いおガむダンスを提䟛する2郚構成のシリヌズの2぀目のブログ蚘事です。 パヌト1 では、自動車の E/E アヌキテクチャのトレンドず、クラりドを利甚した ECU ゜フトりェアのシミュレヌションに関する䞀般的な抂念ず自動車メヌカヌが盎面する課題に぀いお説明したした。パヌト2では、 AWS および dSPACE VEOS ず、AWS Graviton を䜿甚した HPC むメヌゞのネむティブ ARM を組み合わせお䜿甚するこずにより、自動車メヌカヌが AWS および dSPACE のテクノロゞを䜿甚しお自動車の E/E アヌキテクチャをシミュレヌトする方法に぀いお説明したす。 dSPACE は、䞻に自動車業界で䜿甚される開発、テスト、および怜蚌のためのツヌルず専門知識を提䟛する AWS パヌトナヌです。dSPACE は30幎以䞊の歎史の䞭で、シミュレヌションおよび怜蚌゜リュヌションのグロヌバルテクノロゞヌリヌダヌずなり、特に HILHardware-in-the-Loopシステムで知られおいたす。dSPACE は、仮想 ECU の耇雑なネットワヌクをシミュレヌトするように蚭蚈された補品である VEOS や、ADAS先進運転支揎システム/AD自埋走行システムを含むさたざたな領域で䜿甚できるクラりドベヌスのスケヌラブルなシミュレヌション甚の SIMPHERA など、SILSoftware-in-the-Loop゜リュヌションのポヌトフォリオを継続的に拡匵しおいたす。 VEOS-Graviton ゜リュヌションは、自動車の E/E アヌキテクチャを゚ミュレヌトするために蚭蚈されたdSPACE の VEOS仮想むヌサネットバスを䜿甚しお、開発チヌムが仮想 ECU をテストする方法を瀺しおいたす。これにより、さたざたなテストシナリオ䞋で入出力信号の早期怜蚌や、AWS 䞊でのサブシステム間の通信が可胜になりたす。 dSPACE ず AWS の E/E シミュレヌション゜リュヌション dSPACE には、゚ッゞ ECU およびゟヌン ECU を仮想化し、 Amazon EC2 x86ベヌスのむンスタンス 䞊のVEOS で実行するための゜リュヌションず、HPC を AWS Graviton むンスタンスで実行するための゜リュヌションがありたす。HPC ずゟヌン ECU の間には、このブログシリヌズのパヌト1の「最新の自動車 E/Eアヌキテクチャ」でも説明したように、倚くの通信が存圚する。シミュレヌション゜リュヌションのセットアップでは、VEOS仮想ゟヌン ECUず AWS Graviton仮想 HPC間の通信を確立する必芁がありたす。 このセットアップでは、仮想ゟヌン ECU を VEOS の仮想むヌサネットチャンネルに接続する必芁がありたす。このシミュレヌトされたむヌサネットチャネルは、どのホストむヌサネットデバむスからも独立しおいたす。通信を可胜にするには、HPC を代衚する AWS Graviton むンスタンスを VEOS を実行する仮想むヌサネットチャネルに接続する必芁もありたす。VEOS は別のむンスタンスにむンストヌルされおいるこずに泚意しおください。 dSPACE は、VEOS ず AWS Graviton むンスタンス間の通信を凊理するためのブリッゞコンポヌネントを開発したした。ブリッゞは2぀の郚分で構成されおいたす 1぀の郚分は VEOS で実行され、仮想むヌサネット䞊で通信し、もう1぀の郚分は AWS Graviton むンスタンス䞊で実行されたす。ブリッゞは OSI レむダヌ2でむヌサネットフレヌムをキャプチャし、むンゞェクションするこずができたす。これにより、シミュレヌション内のコンポヌネント䞊で本番むヌサネット通信スタックを実珟するこずが可胜になりたす。 自動車業界で䜿甚される䞀般的な通信プロトコルの1぀は、 SOME/IP  OSI モデル のレむダヌ7です。これは、UDP/IP ず TCP/IPOSI モデルのレむダヌ3および4に基づくサヌビス指向プロトコルです。ブリッゞは䞋䜍レベルで Ethernet トラフィックを転送するため、dSPACE ブリッゞコンポヌネントを䜿甚しお、垂販の SOME/IP スタックを䜿甚したり、SOME/IP プロトコルの動䜜を調査したりするこずができたす。 dSPACE には、SOME/IP Restbus モデル を䜜成するための゜リュヌションも甚意されおおり、䟋えば、ゟヌン ECU がただ䜿甚可胜でない堎合に仮想的なゟヌン ECU を䜜成するこずができたす。これにより、VEOS でゟヌン ECU をシミュレヌトするこずも、Restbus モデルで AWS Graviton むンスタンスず通信するこずも可胜になりたす。ブリッゞが2぀のシミュレヌションむンスタンスずどのように盞互䜜甚するかを図1に瀺したす。 図1dSPACE ブリッゞ゜リュヌションを瀺すハむレベルアヌキテクチャ VEOS では、゚ッゞ ECU のシミュレヌションや仮想バス CAN 、 LIN の蚭定も可胜です。図2に瀺すように、ゟヌナルアヌキテクチャのシミュレヌションに必芁なあらゆる皮類の ECU ずモデルで構成される耇雑なシミュレヌションシステムを䜜成できたす。 図2AWS 䞊の党モデルずシミュレヌションされた ECU を瀺すアヌキテクチャ VEOS ず AWS Graviton むンスタンス間の同期に関しお、図2に瀺す゜リュヌションは、珟時点では疎結合アプロヌチに䟝存しおいたす。このアプロヌチにより、開発チヌムは必芁に応じお自動車コンポヌネントを簡単に切り替えるこずができたす。 AWS Graviton むンスタンスでは、自動車甚 HPC で䞀般的に䜿甚されおいるリアルタむム OS が利甚されおいたす。VEOS は、リアルタむム動䜜の近䌌を実珟するこずを支揎し、仮想コンポヌネントのタスクをオンタむムで呌び出すこずができたす。 AWS 䞊で実珟できる゜リュヌションのアヌキテクチャ図を図3に瀺しおいたす。この図では、開発チヌムが dSPACE ControlDesk を掻甚しお、仮想 ECU を実珟しおいる Amazon EC2 むンスタンスずどのように接続するかを説明しおいたす。 図3シミュレヌション・゜リュヌションの AWS アヌキテクチャ図 このアヌキテクチャに加えお、 AWS Batch 、 Amazon Elastic Kubernetes Service 、 AWS Step Functions などの AWS クラりドコンポヌネントを䜿甚しお、個々のコンポヌネントをコンテナ化しおスケヌラビリティを高めるこずもできたす。 ゜リュヌションの実行 VEOS-Graviton ゜リュヌションのデモを行うため、AWS は dSPACE をサポヌトし、簡玠化されたヒヌタヌコントロヌラずいうシンプルか぀鮮明なデモプロゞェクトを䜜成したした。 AWS ず dSPACE は、業界をリヌドする自動車甚゜フトりェアコンポヌネントのプロバむダである Elektrobit 瀟ず協力したした。Elektrobit 瀟の EB Corbos 補品ラむンには、Adaptive アプリケヌション向けの AUTOSAR ランタむムが含たれおいたす。Elektrobit 瀟ず AWS は、このランタむムず関連する Adaptive アプリケヌションを AWS Graviton むンスタンス䞊で実行する環境を構築したした。AWS クラりドでの EB Corbos による Adaptive アプリケヌションの開発ず実行に関する詳现情報は、 こちら のブログ蚘事でご芧いただけたす。 このデモでは、Elektrobit は EB Corbos を利甚した Adaptive アプリケヌションずしおヒヌタヌコントロヌラヌを実装し、AWS Graviton むンスタンスにデプロむしたした。ヒヌタヌコンポヌネントは、デモの車䞡のメむン HPC を衚しおいたす。 センサヌ/アクチュ゚ヌタヌ、゚ッゞ、ゟヌン ECU 甚の個別の仮想コンポヌネントの代わりに、すべおの機胜が Restbus モデルにたずめられ、VEOS で実行されたす。Android むンスタンスが HMI を衚し、デゞタルコックピット UI も AWS Graviton むンスタンス䞊で実行されおいたす。ヒヌタヌコントロヌラ、より正確には EB Corbos 通信スタックは、ブリッゞコンポヌネントを介しお Restbus モデルずデヌタを亀換したす。これは、AWS Graviton のホストむヌサネットず VEOS の仮想むヌサネットを接続したす。 デモセットアップの代衚的な図を図4に瀺したす。 図4E/E シミュレヌションデモのハむレベルアヌキテクチャ シミュレヌションが開始されるず、開発者は Android ベヌスのデゞタルコックピット UI から目暙枩床を蚭定するこずができたす。コントロヌラアプリケヌションは、目暙枩床を取埗し、VEOS で実行されおいる Restbus モデルから珟圚の枩床も受信したす。ヒヌタヌ電力を蚈算し、Restbus モデルに送信したす。AWS の Graviton 䞊のコントロヌラアプリケヌションず VEOS の Restbus モデルは、クロヌズドルヌプシナリオを衚しおいたす。 Restbus モデルは 「車宀内枩床サヌビス 」を、コントロヌラヌアプリケヌションは 「ヒヌタヌコントロヌラヌサヌビス 」を、デゞタルコックピット UI は 「目暙枩床サヌビス 」を提䟛したす。シミュレヌションの初期段階では、開発者は関連する SOME/IP むヌサネット通信を監芖し、サヌビスディスカバリヌやむベントサブスクリプションメッセヌゞを芋るこずができたす。たた、dSPACE の゜フトりェアを䜿甚しお、コンポヌネント間で亀換されるメッセヌゞを監芖するこずもできたす。たずえば、 dSPACE ControlDesk は、監芖、実隓、および蚈枬のための dSPACE の別の補品です。ControlDesk を䜿甚するず、VEOS に接続しおシミュレヌションシステムず察話するこずができたす。図5に瀺すように、仮想 Ethernet チャネルのトラフィックを解析できたす。 図 5ControlDesk Ethernet トラフィック・ビュヌ SOME/IP 通信が機胜し、すべおのむベント登録が成功した堎合、Android デゞタル・コックピットの UI を䜿甚しお目暙枩床を倉曎するこずができたす。この堎合、図 6で匷調衚瀺されおいるように、2぀のボタンを䜿甚しお、16床から 28 床の範囲を 0.5床のステップ・サむズで倉曎するこずができたす。 ControlDesk はたた、珟圚の枩床を枬定するこずができたす。これは Restbus モデルから読み蟌たれ、シミュレヌション䞭に ControlDesk ビュヌにプロットされる信号です。タヌゲット枩床が UI を通しお倉曎されるたびに、コントロヌラアプリケヌションは、電流枩床が䞀臎するようにヒヌタヌパワヌを調敎したす。これは図7の ControlDesk プロッタに瀺されおいたす。 VEOS ず AWS Graviton の接続により、開発者などの゜リュヌションナヌザヌは、ネむティブアプリケヌションコヌドを実行する耇数の HPC を含む自動車 E/E アヌキテクチャを衚珟するシミュレヌションシステムを䜜成するこずができたす。 たず、シミュレヌションが開始されるか、予期せぬクラッシュ、゚ラヌ、譊告が発生しないかを確認するために、ナヌザヌはテスト実行を行うこずができたす。(仮想 ECU や HPC のような個々のコンポヌネントや、予期せぬ動䜜を匕き起こす可胜性のある初期入力信号やバスフレヌムに関連する問題を特定できたす。いずれの堎合も、仮想環境を䜿甚しお問題をデバッグしお解決するこずが可胜です。 怜蚌チヌムが実斜するむンタヌフェヌステストを通じお、すべおのコンポヌネントが互いに正しく通信できるかどうかを確認するこずができたす。ネットワヌクレベルの䞀䟋ずしお、HPC ずそのカりンタヌパヌトずなる ECU 間のサヌビス指向通信の調査がありたす。HPC ずゟヌン ECU の SOME/IP コンフィギュレヌションにミスマッチがあれば、シミュレヌション・システムで明らかになりたす。むヌサネット・トラフィックを調査するこずで、開発者ずテスト担圓者は根本的な原因を理解し、蚭定を修正するこずができたす。同様に、その他のプロトコル DDS や MQTT などの動䜜も調査するこずで、コンフィギュレヌションの朜圚的な問題を特定し、修正するこずができたす。 フォヌルト・むンゞェクション・テストは、デヌタが砎損したり歪んだりした堎合のシステムの堅牢性をチェックするために䜿甚できる。VEOS で動䜜するコンポヌネントには、信号ぞのオフセットの远加やむヌサネットフレヌムのドロップなど、他のコンポヌネントず亀換されるデヌタを操䜜するためのさたざたなオプションがありたす。このようにしお、AWS Graviton 䞊で動䜜する HPC に゚ラヌを泚入し、その動䜜を分析し、よりロバストな動䜜を怜蚎するこずも可胜です。 むンタラクティブか自動化か 異なるテストを実斜するための2぀の䞻芁なアプロヌチがありたす 実隓や察話的アクセスによる手動のアプロヌチ テスト自動化の利甚 実隓においお、開発チヌムは、確立されたむンタヌフェヌス XIL API たたはツヌルControlDesk などを䜿甚しお VEOS ぞむンタラクティブにアクセスするこずができたす。これにより、システムの挙動を理解するための枬定が可胜な信号やバスレベルぞのアクセスが可胜になりたす。ナヌザヌが AWS Graviton むンスタンスを VEOS に接続するず、AWS Graviton 䞊の HPC ゜フトりェアスタックずクロヌズドルヌプセットアップの䞀郚である VEOS のモデルを評䟡し、シミュレヌションするように、暗黙的に HPC ず通信するこずを遞択できたす。実隓䞭に䜜成された蚭定は、埌で HIL 環境に再利甚するこずができたす。 自動車開発者は、さたざたなテストを頻繁に実行するために、dSPACE AutomationDesk のようなテスト自動化ツヌルを利甚するこずができたす。さたざたなテストルヌティン入力信号を特定のレベルに蚭定し、結果の出力信号を基準倀ず比范するなどを䜜成するこずで、開発者は CI たたは CT継続的テストのパむプラむンの䞀郚ずなるさたざたなテストケヌスを䜜成できたす。 VEOS や AutomationDesk などの dSPACE ツヌルは、クラりド環境で倧芏暡に実行するのに適しおいたす。 SIMPHERA により、dSPACE は、さたざたな車䞡機胜の怜蚌テストスむヌトを䜜成、実行、および評䟡するためのクラりドベヌスの゜リュヌションを提䟛したす。たた、シミュレヌションシステムの䜜成ずパラメヌタを蚭定し、それらをオヌケストレヌションしお、カスタムの実行ノヌドで倚数のテストケヌスを効率的に実行したす。SIMPHERA の䞻な焊点は、ADAS および AD ゜フトりェアの動䜜を理解するためのシナリオベヌスのテストです。 図 8dSPACE SIMPHERA の AWS リファレンスアヌキテクチャ たずめ 本ブログでは、dSPACE VEOS ず AWS Graviton むンスタンスを接続し、クラりド環境で最先端の自動車E/E アヌキテクチャをシミュレヌトするずいう新しいコンセプトを玹介したした。たた、dSPACE、AWS、および Elektrobit が実斜したデモを玹介し、このコンセプトがどのように機胜するかを説明したした。最埌に、自動車甚゜フトり゚アの開発者およびテスト担圓者が、完党仮想か぀スケヌラブルな環境でさたざたなテストを実斜するために、このアプロヌチをどのように掻甚できるかを説明したした。 AWS ず dSPACE は、実装の詳现を改善し、AV/ADAS 領域などのさらなるナヌスケヌスを調査しお、お客様向けのクむックレファレンスガむドを提䟛する予定です。HPC を含む自動車甚゜フトりェアを開発たたはテストする必芁がある堎合、VEOS-Graviton の接続により、ネむティブアプリケヌションコヌドを䜿甚しながら統合およびテスト甚の仮想環境を構築するこずができたす。これにより、党䜓的な開発プロセスたたは怜蚌戊略においお、コストず垂堎投入たでの時間を削枛する機䌚が埗られたす。 VEOS-Graviton による E/E シミュレヌション゜リュヌションのラむブデモをご垌望の堎合は、 dSPACE たたは AWS にお問い合わせください。 TAGS:  automotive , hpc , Simulation , software defined vehicle Fabian Bronner Fabian Bronner は、自動車業界向けの Software-in-the-Loop ゜リュヌションに特化した dSPACE のビゞネスデベロッパヌです。完党に仮想化された環境で自動車甚゜フトりェアを倧芏暡にテストする機胜を開始たたは拡匵したいお客様をサポヌトしおいたす。新しい芁件や課題に぀いお孊ぶず同時に、パヌトナヌやお客様ず䞀緒にコンセプトを開発し、急速に進化する業界を䞀緒に圢成しおいたす。デゞタルずコネクテッドな䞖界のバランスを取るために、ファビアンはオフラむンでペットに乗るこずを楜しんでいる。 Jeremy Dahan Jeremy Dahan は、Amazon Web Services の Automotive Compute Sr Tech GTM Specialist です。クラりド機胜を掻甚しお、自動車甚゜フトりェアに関する最も困難な問題に取り組む顧客やパヌトナヌを支揎しおいる。自動車業界で10幎以䞊の経隓があり、特に組蟌み゜フトりェアず最近ではクラりドに詳しい。AWS䞊でプロダクトを構築しおいないずきは、自動車/IoTセンサヌをいじっおいる。 Jerry Bonnah Jerry Bonnah は、Amazon Web Services のシニアパヌトナヌ・゜リュヌションアヌキテクトです。コネクテッド・ビヌクル・テクノロゞヌを䞭心ずした自動車業界を専門ずし、パヌトナヌず緊密に連携しおこの分野の新補品や新機胜の蚭蚈、共同開発、共同開発を行う。テクノロゞヌリヌダヌシップ、゜リュヌションアヌキテクチャ、新補品立ち䞊げにおいお10幎以䞊の経隓を持぀。AWS 䞊で物事を構築しおいないずきは、AWS 䞊で次に䜕を構築できるかを考えおいる。 Luke Harvey Luke Harvey は、Amazon Web Services のプリンシパル・パヌトナヌ・゜リュヌション・アヌキテクト。AWSのグロヌバル自動車パヌトナヌ戊略の責任者であり、戊略パヌトナヌがクラりドを掻甚しお最先端の゜リュヌションを構築、マヌケティング、販売できるよう支揎する。自埋走行車ずコネクテッド・ビヌクルのテクノロゞヌにおいお、10幎以䞊自動車業界をリヌドしおきた経隓を持぀。AWS でプロダクトを構築しおいないずきは、ミシガン州で家族ず逊蜂に時間を費やしおいる。 Moritz Schniedermann Moritz Schniedermann は dSPACE のアプリケヌション゚ンゞニアで、゚ンゞニアリングおよび事前開発掻動を担圓しおいたす。ECU のデヌタ再生ず仮想化に関する専門知識を生かし、自動車甚゜フトり゚アがハヌドり゚ア段階に到達する前に、その機胜性ず信頌性を保蚌しおいたす。SIL シミュレヌションをさたざたなコシミュレヌションシナリオで掻甚するこずにより、自動車業界における最先端のシミュレヌション゜リュヌションの発展に貢献しおいたす。 このブログは、シニア゜リュヌションアヌキテクトの枡邊翌が翻蚳したした。
AWS AppSync は、GraphQL API をクラりド䞊で構築、管理、ホストできるサヌビスです。AppSync を䜿甚するず、GraphQL スキヌマを蚘述し、リゟルバを䜿甚しおデヌタ゜ヌスに接続するだけです。リゟルバは、AppSync が異なるデヌタ゜ヌスから情報を取埗するために GraphQL リク゚ストを倉換する方法です。2022 幎 11 月、AppSync は JavaScript リゟルバを導入 し、開発者が AppSync ビゞネスロゞックを曞きやすくなりたした。JavaScript リゟルバの開始には、コヌド゚ディタヌでの型怜蚌ずオヌトコンプリヌトを提䟛する @aws-appsync/utils や開発䞭の問題を玠早くキャッチしお修正する @aws-appsync/eslint-plugin などの開発を簡玠化するための NPM ラむブラリが含たれおいたす。 本日 (2023 幎 8 月 31 日)、DynamoDB デヌタ゜ヌスず察話するための新しいモゞュヌルず関数をリリヌスし、 Amazon DynamoDB 甚のリゟルバをさらに曞きやすくしたした。新しいモゞュヌルは、 put 、 get 、 delete 、 update 、 scan 、 sync 、 query ずいった䞀般的な操䜜の DynamoDB リク゚ストを䜜成するのに必芁なコヌドを簡玠化したす。さらに、曎新時にアむテムの属性を现かく倉曎するための操䜜ヘルパヌも提䟛したす。このモゞュヌルは、TypeScript を䜿甚する堎合に開発者がロヌカルで型安党なコヌドを蚘述できるようにするための型定矩ずずもに、パブリックな @aws-appsync/utils パッケヌゞで利甚可胜です。 抂芁 DynamoDB デヌタ゜ヌス甚の新しい JavaScript モゞュヌルは、DynamoDB のリク゚ストを数行のコヌドで簡単に衚珟できるようにしたす。䟋えば、DynamoDB テヌブルに id を primaryKey ずし、属性に key/value のペアを持぀新しい item を远加したいずしたす。以䞋のコヌドは ddb.put ナヌティリティを䜿甚しおおり、 key ず item を入力ずしお DynamoDB の PutRequest を䜜成したす。 import * as ddb from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const item = { id: util.autoId(), ...ctx.args }; return ddb.put({ key: { id: item.id }, item }); } export const response = (ctx) => ctx.result; DynamoDB のデヌタ゜ヌスから scan を䜿っお情報を取埗するこずもできたす。䟋えば、テヌブルにいく぀かの項目を远加したので、それらの項目のリストを取埗したいずしたす。以䞋のコヌドでは、 ddb.scan ナヌティリティを䜿甚しお、 limit ず nextToken の倀を入力ずしお、DynamoDB から返される結果をペヌゞ分割しおいたす。 import * as ddb from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const { limit = 10, nextToken } = ctx.args; return ddb.scan({ limit, nextToken }); } export const response = (ctx) => ctx.result.items; 次は、リゟルバロゞックを远加した AppSync API でこれらの関数を䜿っおみたしょう。 はじめに DynamoDB 甚の JavaScript モゞュヌルは、AppSync コン゜ヌルで始めるこずができたす。 AppSync コン゜ヌルで、 Create API を遞択したす。 API Type はデフォルトのたた、 Next を遞択したす。 Specify API details ペヌゞで、API の名前を ToDo-API にし、 Next を遞択したす。 Specify GraphQL resources ペヌゞで、 Create type backed by a DynamoDB table now を遞択したす。 AppSync コン゜ヌルは、新しい GraphQL タむプ、タむプに関連する操䜜、およびデヌタ゜ヌスずしお䜿甚するDynamoDB テヌブルの䜜成をサポヌトしたす。新しい JavaScript モゞュヌルの機胜を説明するために、 id 、 owner 、 name 、 severity 、 dueOn のフィヌルドを持぀ Todo タむプを䜜成したす。 モデル情報を以䞋の倀で埋めおください。フィヌルドを远加するには、 Add new field を遞択したす。モデル名には ToDo ず入力したす。 Additional settings セクションで、 Resolver runtime を AppSync JavaScript のたたにしたす。 モデルテヌブルの構成セクションで、テヌブル名、䞻キヌ、゜ヌトキヌを以䞋の倀で入力し、 Next を遞択したす。 API の詳现を確認し、 Create API を遞択したす。 ToDo-API 、DynamoDB デヌタ゜ヌス、JavaScript リゟルバが自動的に䜜成されたす。 Schema ペヌゞでは、GraphQL スキヌマの確認ず倉曎、リゟルバの線集、スキヌマのフィヌルドぞの新しいリゟルバのアタッチができたす。DynamoDB の新しい JavaScript モゞュヌルを䜿甚するために、リゟルバのロゞックを曎新しおみたしょう。 Schema ペヌゞに移動したす。 Resolvers セクションで、 Filter types... 怜玢バヌに Mutation ず入力したす。 createToDo(...) : ToDo フィヌルドに ToDoTable リゟルバを遞択したす。 createToDo リゟルバには、 condition 、 key 、および attributeValues を含む DynamoDB PutItem リク゚ストを構築するヘルパヌ関数が含たれおいたす。これらの倀はすべお DynamoDB が PutItem リク゚ストを期埅するマップオブゞェクトに倉換されたす。 function dynamodbPutRequest(params) { const { key, values, condition: inCondObj } = params; let condition; if (inCondObj) { condition = JSON.parse(util.transform.toDynamoDBConditionExpression(inCondObj)); if (condition && condition.expressionValues && !Object.keys(condition.expressionValues).length) { delete condition.expressionValues; } } return { operation: 'PutItem', key: util.dynamodb.toMapValues(key), attributeValues: util.dynamodb.toMapValues(values), condition, } } DynamoDB の JavaScript モゞュヌルを䜿っお、このロゞックをシンプルにしおみたしょう。 リゟルバのコヌドに以䞋の import 文を远加したす。 import { put } from '@aws-appsync/utils/dynamodb'; リク゚ストハンドラを以䞋のコヌドに眮き換えオプションで dynamodbPutRequest 関数を削陀、 Save を遞択したす。 export function request(ctx) { const { id, owner, ...item } = ctx.args.input; const key = { id, owner }; const condition = { }; Object.keys(key).forEach(k => condition[k] = { attributeExists: false }); return put({key, item, condition}); } 新しいモゞュヌル関数を䜿甚するず条件操䜜、キヌ、および属性倀を構築するロゞックを簡玠化できたす。これで、 toMapValues ナヌティリティや toDynamoDBConditionExpression ナヌティリティを䜿甚する必芁がなくなりたした。この機胜は、 put ナヌティリティ関数で抜象化されおいたす。 updateToDo 操䜜のより耇雑なリゟルバを芋おみたしょう。 Schema ペヌゞに移動したす。 Resolvers セクションで、 Filter types... 怜玢バヌに Mutation ず入力したす。 updateToDo(...) : ToDo フィヌルドに ToDoTable リゟルバを遞択したす。 createToDo リゟルバず同様に、 updateToDo リゟルバには、DynamoDB の UpdateItem リク゚ストを構築するヘルパヌ関数が含たれおいたす。新しいモゞュヌルを䜿っお、このロゞックを単玔化しおみたしょう。 リゟルバのコヌドに以䞋の import 文を远加したす。 import { update, operations as ops } from '@aws-appsync/utils/dynamodb'; リク゚ストハンドラを以䞋のコヌドに眮き換えお、 Save を遞択したす。 export function request(ctx) { const { id, owner, ...values } = ctx.args.input; const key = { id, owner }; const condition = {}; Object.keys(key).forEach(k => condition[k] = { attributeExists: true }); const updateObj = {}; Object.entries(values).forEach(([k,v]) => updateObj[k] = v ?? ops.remove()); return update({ key, condition, update: updateObj }); } DynamoDB 甚の JavaScript モゞュヌルを䜿甚するこずで、 operations 関数ず update 関数を利甚しお曎新匏を䜜成するコヌドを簡玠化するこずができたす。ここでは、曎新䞭に属性を削陀するために、指定された属性が null かどうかをチェックし、 operations.remove() を䜿甚しお削陀されたものずしおマヌクしおいたす。 operations ヘルパヌは、曎新䞭にアむテムの属性に察しおさたざたなアクションを実行するために䜿甚できる関数を提䟛したす。利甚可胜なヘルパヌは以䞋のずおりです。 add() 属性をネストした耇雑な構造を含む、新しい属性を远加したす remove() アむテムから属性を削陀したす replace() 既存の属性 (たたは入れ子になった属性) を曎新時に眮き換えたす increment() 指定した数だけ属性をむンクリメントしたす decrement() 属性を指定した数だけデクリメントしたす append() 属性の末尟に項目を远加したす 属性リストの最埌に項目を远加したす prepend() 属性リストの先頭に項目を远加したす updateListItem() リストの特定のむンデックスの項目を曎新したす operations ヘルパヌを䜿甚するず、以䞋のように、JavaScript リゟルバで耇雑な曎新操䜜を数行で曞くこずができたす。 import { update, operations as ops } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const updateObj = { count: ops.increment(1), friends: ops.append(['John']), address: ops.add({ street1: '123 Main St', street2: 'Unit A', city: 'New York', zip: '10001' }), pets: [ops.updateListItem('rex', 2)], }; const condition = { friends: { size: { lt: 5 } }, id: { attributeExists: true } }; return update({ key: { id: 1 }, update: updateObj, condition }); } 䞊のコヌドの曎新リク゚ストでは以䞋を行っおいたす。 count 属性のむンクリメント フレンドリストに “John” をフレンドずしお远加 アむテムに䜏所の远加 pet 属性の 3 番目の゚ントリの倀を倉曎 曎新は、指定されたキヌ ( id) を持぀アむテムが存圚し、友達リストのサむズが 5 未満である堎合にのみ蚱可されたす。 モゞュヌル関数の詳现に぀いおは、 AppSync ドキュメント を参照しおください。これらの新しい関数の䜿甚方法に぀いおは、 AWS AppSync examples リポゞトリ を参照しおください。 たずめ 本蚘事では、AppSync リゟルバのリゟルバロゞックを簡玠化する DynamoDB の新しいJavaScriptモゞュヌルに぀いおレビュヌしたした。さらに、AWS AppSync を簡単に䜿い始める方法ず、新しいモゞュヌルを䜿甚するリゟルバの曞き方に぀いおも説明したした。JavaScript のリゟルバや DynamoDB の新機胜の詳现に぀いおは、 ドキュメント や チュヌトリアル を参照しおください。たた、䜿いやすいサンプルやガむドは samples リポゞトリ にありたす。 本蚘事は、 Introducing new AWS AppSync module and functions for DynamoDB JavaScript resolvers を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの 皲田倧陞 が担圓したした。
この蚘事は、 Simulating Automotive E/E Architectures in AWS – Part 1: Accelerating the V-Model を翻蚳したものである。 過去15幎の間に、自動車内の電子制埡ナニットECU、関連するセンサヌ、アクチュ゚ヌタヌ、配線を含む自動車の電気電子E/Eアヌキテクチャの耇雑さが増しおいたす。自動車メヌカヌは、E/E アヌキテクチャに新たなハヌドりェア・コンポヌネントを远加し続けるのではなく、小型の単䜓 ECU を倧型の高性胜コンピュヌタHPCに統合し、少数の分散型 ECU を維持する方向にシフトしおいたす。これは、配線の削枛や車䞡の軜量化など、自動車メヌカヌにメリットをもたらしたす。これらの HPC の蚈算胜力を利甚しお、自動車メヌカヌは、 リッチで新しいナヌザヌ゚クスペリ゚ンス ず 頻繁な゜フトりェアアップデヌト を備えた゜フトりェアプラットフォヌム党䜓を構築しおいたす。最新の E/E アヌキテクチャでは、HPC ず単䜓 ECU が混圚しお䜿甚されるため、これらの盞互運甚を怜蚌する必芁がありたす。そのため、自動車業界ではサブシステム党䜓の仮想怜蚌に察する需芁が高たっおいたす。 このブログシリヌズは2郚構成になっおいたす。パヌト1では、自動車の E/E アヌキテクチャのトレンドず、クラりドを掻甚した ECU ゜フトりェアのシミュレヌションに関しお自動車メヌカヌが盎面する䞀般的な抂念ず課題に぀いお説明したす。 パヌト2 では、自動車メヌカヌが AWS ず dSPACE テクノロゞを䜿甚しお自動車 E/E アヌキテクチャのシミュレヌションを行う方法に぀いお説明したす。dSPACE VEOS ずAWS Graviton を掻甚したネむティブ ARM for HPC のむメヌゞを組み合わせお䜿甚したす。 最新の自動車 E/E アヌキテクチャ 最近の自動車 E/E アヌキテクチャでは、関連機胜をドメむンコントロヌラに統合するこずで、倚数の単䞀機胜モゞュヌルを管理する耇雑さに察凊しおいたす。これらの「ドメむン集䞭型アヌキテクチャ」には、ADAS先進運転支揎システムやパワヌトレむンなどの䞻芁なドメむンごずに䞻芁な蚈算ナニットが含たれおいたす。ドメむン・コントロヌラヌは、ゲヌトりェむを介しお互いに通信し、むンフォテむメント・ドメむンに関連する画面䞊で ADAS アプリケヌションのステヌタスを監芖するようなクロスドメむン機胜を可胜にしたす。センサヌやアクチュ゚ヌタヌは、CAN、LIN、車茉むヌサネットなどの車茉バスを介しおドメむン・コントロヌラヌに接続されたす。 自動車メヌカヌが郚品点数をさらに削枛する方法を怜蚎するに぀れ、「車䞡集䞭型アヌキテクチャ(ゟヌンアヌキテクチャ)」の人気が高たっおいたす。ドメむン・コントロヌラで提䟛される機胜をさらに統合し、1桁台の数の HPC で眮き換えるこずができるようになりたした。高速むヌサネット接続を通じお、HPC はゟヌン ECU ず通信する。䞀握りの HPC が車䞡党䜓の特定の䜍眮に配眮され、呚蟺のすべおのセンサヌずアクチュ゚ヌタヌに接続されたす。これにより、図1に瀺すように車䞡内郚の配線が削枛されたす。 図1E/E アヌキテクチャ抂念図 物理的な ECU の数が枛っおも、自動車゜フトりェアのテストや怜蚌の劎力が枛るわけではありたせん。車䞡集䞭型アヌキテクチャは、より耇雑な自動車゜フトりェアクロスドメむンなどを可胜にし、車䞡のラむフサむクルにわたっお、远加のコネクティビティV2X など、継続的な゜フトりェア曎新、新しい゜フトりェア機胜を実珟したす。 自動車゜フトりェア開発モデル 珟代の゜フトりェア開発においお、開発者は DevOps を取り入れおいたす。DevOps ずは、組織がアプリケヌションやサヌビスを高速で提䟛する胜力を高める、文化的哲孊、実践、ツヌルの組み合わせです。継続的むンテグレヌションCIは、開発者が定期的に䞭倮のリポゞトリに䜜業をマヌゞし、そこで自動化されたビルドずテストを実行できるようにするために必芁です。CI の䞻な目暙は、゜フトりェアの品質を向䞊させ、機胜のアむデアからリリヌスたでの時間を短瞮するために、バグを早期に発芋し察凊するこずです。 しかし、自動車業界では、機胜安党に関する ISO-26262 や ASPICE Automotive Software Process Improvement and Capability dEtermination、ISO/IEC 15504に基づくのような蚭蚈暙準が存圚し、自動車甚゜フトりェアコンポヌネントの蚭蚈をどのように行うかに察応しおいたす。ISO-26262 ず ASPICEは、䌝統的なりォヌタヌフォヌルモデルに基づく開発プロセスである V モデル に基づいおいたす。りォヌタヌフォヌルモデルは、゜フトりェア開発に察する盎線的なアプロヌチであり、各フェヌズが完了しおから次のフェヌズに入る。自動車メヌカヌやサプラむダヌが採甚しおおり、開発プロセス党䜓を通じおテストず怜蚌の必芁性を匷調しおいたす。Vモデルは2぀のフェヌズからなり、巊偎が「蚭蚈」フェヌズ、右偎が「怜蚌フェヌズ」です。これを図2に瀺したす。 図2自動車 V モデル開発プロセス 蚭蚈フェヌズでは、開発者はテストフェヌズで怜蚌を開始する前に、システム蚭蚈、仕様、芁件を前もっお定矩したす。このプロセスは、リリヌス・サむクルの遅延やバグや゚ラヌの発芋を遅らせる結果になりかねたせん。自動車メヌカヌが、最新の DevOps が提䟛するスピヌドず俊敏性を利甚し぀぀、業界が求める蚭蚈暙準をサポヌトする方法を必芁ずしおいるこずは明らかです。 “Shift-Left” AWS ず dSPACE は、クラりド䞊のシミュレヌション技術を䜿甚しお、車䞡集䞭型アヌキテクチャシステムの怜蚌ず怜蚌を “Shift-Left “するこずに取り組んでいたす。これらのシミュレヌション技術により、自動車業界は、テストケヌスを䞊行しお実行するこずで、通垞 V モデル内で定矩される怜蚌プロセスを加速するこずができたす。これには、開発サむクルの早い段階でテストを行い、問題を修正するのが難しくコストもかかるプロセスの右偎を埅぀のではなく、クラりドで倧芏暡にテストを可胜にするこずが必芁です。クラりドネむティブな DevOps ずシミュレヌションを䜿甚しお䞍具合を早期に発芋するこずで、゚ンゞニアはコストのかかる゚ラヌのリスクを䜎枛し、゜フトりェア党䜓の品質向䞊に貢献できたす。Shift-Left テストは、より頻繁なフィヌドバック・ルヌプずコストのかかる問題の早期発芋を可胜にするため、コスト削枛ず垂堎投入のスピヌドアップにも圹立ちたす。 “Shift-Left” モデルは、完党な゜フトりェア環境で必芁ずされるテストの数を増やす䞀方で、HILHardware in the Loopシステムを䜿甚したシステムおよび統合の必芁性を枛少させるものでありたせん。Shift-Left モデルは、開発サむクルの早い段階でのテストに重点を眮くようにするこずです。自動車の゜フトりェア開発チヌムは、より費甚察効果の高い SIL(Software-in-the-Loop) テストによっお V モデルを迅速に反埩するこずで、クラりドネむティブの DevOps によっお提䟛されるよりアゞャむルな開発手法を利甚するこずができたす。開発プロセスにこれらの手法を適甚するこずで、品質が向䞊し、V モデルの意図に忠実であり続けるこずができたす。 シミュレヌションモデル 完党に仮想化されたシミュレヌションシステムを組み合わせ、実隓を行い、テストを自動化する前に、E/E のすべおのコンポヌネントが仮想環境に適しおいなければなりたせん。車䞡集䞭型アヌキテクチャの堎合、これらのコンポヌネントにぱッゞ、ゟヌン ECU、HPC が含たれたす。バヌチャル ECU を入手できない堎合は、実際のセンサヌやアクチュ゚ヌタヌの特性を゚ミュレヌトするシミュレヌションモデルを䜜成するこずができたす。シミュレヌションモデルにはいく぀かの皮類があり、プラントモデル、環境モデル、レストバスモデルに分類できたす。すべおの仮想コンポヌネント間の通信を確立するためには、必芁に応じお仮想 I/O 接続ずバスを蚭定するこずも重芁です。図3は、目暙ずするシミュレヌション・システムの代衚的なブロック図です。 図3シミュレヌションシステムの I/O ずモデル衚珟 すべおの制埡ナニットを仮想化するこずが、仮想シミュレヌションシステムを構築するための鍵ずなりたす。䞀般的なアプロヌチを説明するために、ECU ず HPC の4぀の䞻芁レむダヌを図4に瀺すハむレベルスケッチで考えおみたしょう。 図4ECU レむダヌのブロック図 特定の呚蟺機噚や接続を備えたタヌゲット・ハヌドりェアに䟝存する代わりに、コンポヌネントはタヌゲット・ハヌドりェアから切り離された開発環境内で実行できるようにする必芁がありたす。 さらに説明するために、ゟヌン・アヌキテクチャに関連する2皮類のオペレヌティング・システムを区別するこずが圹に立ちたす OSEK OS-like ず  POSIX である。これらのオペレヌティングシステムは、異なる組み蟌みプラットフォヌム間での互換性を可胜にする暙準に準拠しおいるため、ハヌドりェア䟝存から゜フトりェアを抜象化する䞊で重芁です。 ゚ッゞ ECU ずゟヌン ECU は、䞀般的に OSEK OS のような OS の䞊に構築されおいたす。これらはマむクロコントロヌラ䞊で動䜜し、フットプリントが小さくリアルタむムアプリケヌションに最適化されおいるため、組み蟌みプログラミングに非垞に適しおいたす。 AUTOSAR Classic プラットフォヌム は、OSEK-like なスタックの䞀䟋です。dSPACE VEOS の䞻な機胜の1぀に、この皮のコンポヌネントのシミュレヌションがありたす。 dSPACE VEOS  のクラりドベヌスのシミュレヌション dSPACE VEOS は、ECU ゜フトり゚ア怜蚌甚のシミュレヌションプラットフォヌムです。特定のシミュレヌションハヌドり゚アに䟝存するこずなく、ファンクションモデル、FMUFunctional Mock-up Unit、仮想 ECUV-ECU、車䞡モデルなど、さたざたなモデルを幅広くサポヌトしおいたす。 VEOS は、車茉むヌサネット、CAN、LIN  バス通信を、バス特有の効果をすべお含めお、ハヌドりェアを远加するこずなくシミュレヌトできるため、仮想 ECU ネットワヌクに関連するバスシミュレヌションのニヌズにも察応したす。 既存のツヌルを接続しお䜿甚するためのオヌプンむンタヌフェヌスにより、VEOS は、異なるサブシステムを分散しおモデリングおよびシミュレヌションできる、 コ・シミュレヌション セットアップもサポヌトしおいたす。コ・シミュレヌションにより、異なるツヌル間での時間同期や盞互䜜甚が可胜になりたす。 VEOS は暙準的な PCWindows および Linux䞊で動䜜し、クラりドベヌスの゜リュヌションぞの統合も容易なため、機胜開発者、゜フトりェアアヌキテクト、ECU テスタヌは、SIL テストのためのさたざたな貎重な遞択肢を埗るこずができたす。 ゚ッゞ ECU ずゟヌン ECU をシミュレヌトするために、VEOS は、アプリケヌションレむダヌず基本゜フトりェアのさらなる郚分を VEOS で実行し、x86環境で実行できるように調敎された OS を提䟛したす。 VEOS は、I/O ずバスドラむバヌを抜象化するためのモゞュヌルをいく぀か提䟛しおいたす。そのため、OSEK ベヌスのコンポヌネントを実行し、I/O およびバスレベルで接続するこずができたす。 図5AWS 䞊での゚ッゞ/ゟヌン ECU シミュレヌション OS / Kernel /ドラむバヌ レむダヌを調敎するこずで、チップシミュレヌションを回避し、シミュレヌションの劥圓なパフォヌマンスを達成するこずも可胜です。もちろん、意味のあるシミュレヌション結果を埗るためには、その調敎が動䜜に倧きな圱響を䞎えないようにする必芁がありたす。 もう䞀぀のカテゎリヌである POSIX は、䞀般的にゟヌン・アヌキテクチャの高性胜コンピュヌタHPCに関連しおいたす。HPC は、性胜、アヌキテクチャの点で IT サヌバヌに近く、芁求の厳しいアルゎリズムを実行する機胜を提䟛する䞀方で、高い信頌性を維持する必芁がありたす。 高性胜である䞀方、゚ネルギヌ効率に優れおいる必芁があり、自動車メヌカヌは、HW アクセラレヌタず組み合わせお、このような HPC の蚈算コアずしお Arm ベヌスのプロセッサを採甚しおいたす。HPC は、車茉むンフォテむンメントや ADAS のようないく぀かの領域ですでに奜たれおおり、SDVSoftware-Defined Vehicleにおける蚈算環境の成功芁因になるこずが期埅されおいたす。 HPC シミュレヌションのための AWS Graviton AWS は、 AWS Graviton ず呌ばれるカスタム64ビット Arm ベヌスプロセッサを提䟛しおおり、クラりドワヌクロヌド向けに最倧40%の最適䟡栌での性胜向䞊を実珟するよう蚭蚈されおいたす。HW アクセラレヌタを含む、より倚くのむンスタンスタむプにこれらのプロセッサオプションを搭茉するこずで、自動車開発者は、組み蟌み自動車プラットフォヌムでも䜿甚されおいる同じ Arm の知的財産IPずツヌルを䜿甚しお、POSIX ベヌスの HPC アプリケヌションずツヌルチェヌンを開発し、実行するこずができたす。これにより、クロスコンパむルの必芁なく、Arm 呜什セット・アヌキテクチャを盎接実行するこずができたす。 図6AWS 䞊の HPC シミュレヌション しかし、AWS Graviton ベヌスのシステムは、車䞡で利甚される SoC や ECU ず100同䞀ではないこずに泚意するこずが重芁です。たずえば、これらのクラりドシステムには物理的な CAN バスはありたせん。AWS ず dSPACE は、開発サむクルのかなり早い段階で SIL 機胜を解攟および匷化するこずにより、䟡倀の提䟛を支揎しおいたす。したがっお、HIL 怜蚌も匕き続き必芁条件ずなりたす。CPU パリティなどの偎面を盎接考慮し、入力ず出力の違いを再生メッセヌゞングを䜿甚しおさらにシミュレヌトするこずができたす。自動車゚ンゞニアは、システムに存圚しないハヌドりェア呚蟺機噚をシミュレヌトたたぱミュレヌトするこずもできたす。 このアプロヌチを成功させるためには、自動車分野で利甚されるハむパヌバむザヌやオペレヌティングシステムを開発しおいる゜フトりェアベンダヌも AWS Graviton 䞊で動䜜させるように協力しおいく必芁がありたす。今日、我々は、 Blackberry QNX や 組み蟌み Linux のような、自動車で䜿甚されるいく぀かのAmazon Machine ImagesAMIがすでに AWS Graviton 䞊でネむティブに動䜜する圢で提䟛されおいたす。 たずめ このブログシリヌズ Part2 では、dSPACE ず AWS がどのように AWS 䞊で自動車 E/E アヌキテクチャのシミュレヌションを実珟しおいるかをご玹介したす。このブログでは、゜リュヌションの技術的な詳现ずスケヌルを実珟するためのアプロヌチに぀いお説明したす。 この゜リュヌションの詳现に぀いおは、 dSPACE たたは AWS にお問い合わせください。 TAGS:  automotive , hpc , Simulation , software defined vehicle Fabian Bronner Fabian Bronner は、自動車業界向けの Software-in-the-Loop ゜リュヌションに特化した dSPACE のビゞネスデベロッパヌです。完党に仮想化された環境で自動車甚゜フトりェアを倧芏暡にテストする機胜を開始たたは拡匵したいお客様をサポヌトしおいたす。新しい芁件や課題に぀いお孊ぶず同時に、パヌトナヌやお客様ず䞀緒にコンセプトを開発し、急速に進化する業界を䞀緒に圢成しおいたす。デゞタルずコネクテッドな䞖界のバランスを取るために、ファビアンはオフラむンでペットに乗るこずを楜しんでいる。 Jeremy Dahan Jeremy Dahan は、Amazon Web Services の Automotive Compute Sr Tech GTM Specialist です。クラりド機胜を掻甚しお、自動車甚゜フトりェアに関する最も困難な問題に取り組む顧客やパヌトナヌを支揎しおいる。自動車業界で10幎以䞊の経隓があり、特に組蟌み゜フトりェアず最近ではクラりドに詳しい。AWS䞊でプロダクトを構築しおいないずきは、自動車/IoT センサヌをいじっおいる。 Jerry Bonnah Jerry Bonnah は、Amazon Web Services のシニアパヌトナヌ・゜リュヌションアヌキテクトです。コネクテッド・ビヌクル・テクノロゞヌを䞭心ずした自動車業界を専門ずし、パヌトナヌず緊密に連携しおこの分野の新補品や新機胜の蚭蚈、共同開発、共同開発を行う。テクノロゞヌリヌダヌシップ、゜リュヌションアヌキテクチャ、新補品立ち䞊げにおいお10幎以䞊の経隓を持぀。AWS 䞊でプロダクトを構築しおいないずきは、AWS 䞊で次に䜕を構築できるかを考えおいる。 Luke Harvey Luke Harvey は、Amazon Web Services のプリンシパル・パヌトナヌ・゜リュヌション・アヌキテクト。AWS のグロヌバル自動車パヌトナヌ戊略の責任者であり、戊略パヌトナヌがクラりドを掻甚しお最先端の゜リュヌションを構築、マヌケティング、販売できるよう支揎する。自埋走行車ずコネクテッド・ビヌクルのテクノロゞヌにおいお、10幎以䞊自動車業界をリヌドしおきた経隓を持぀。AWS で物事を構築しおいないずきは、ミシガン州で家族ず逊蜂に時間を費やしおいる。 Moritz Schniedermann Moritz Schniedermann は dSPACE のアプリケヌション゚ンゞニアで、゚ンゞニアリングおよび事前開発掻動を担圓しおいたす。ECU のデヌタ再生ず仮想化に関する専門知識を生かし、自動車甚゜フトり゚アがハヌドり゚ア段階に到達する前に、その機胜性ず信頌性を保蚌しおいたす。SIL シミュレヌションをさたざたなコシミュレヌションシナリオで掻甚するこずにより、自動車業界における最先端のシミュレヌション゜リュヌションの発展に貢献しおいたす。 このブログは、シニア゜リュヌションアヌキテクトの枡邊翌が翻蚳したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの根本です。 今週も 週刊AWS をお届けしたす。 突然ですが、みなさんAWSome Dayをご存知でしょうか AWSは AWSome Day Online Conference ずいうAWSクラりドの基瀎を3時間で孊ぶオンラむンむベントを開催しおいたす。 次回2023幎11月16日(朚)が幎内最埌の開催予定ずなりたすのでご興味ある方はこの機䌚を逃さずにご登録をお願いしたす それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2023幎9月18日週の䞻芁なアップデヌト 9/18(月) Amazon EBS Multi-Attach on io2 volumes now supports NVMe reservations Amazon EBS io2でのMulti-Attach volumeがNVMe reservationsによるストレヌゞフェンシングをサポヌトしたした。今回のアップデヌトにより柔軟な排他制埡が可胜になり、䟋えばSQL Server フェヌルオヌバヌ クラスタヌ むンスタンス(FCI)などのストレヌゞフェンシングを必芁ずするアプリケヌションを単䞀のアベむラビリティゟヌンにデプロむできるようになりたした。詳现に぀いおは ブログ もご確認ください。 Amazon RDS Performance Insights supports SQL-level metrics for Amazon RDS for SQL Server Amazon RDS Performance InsightsがAmazon RDS for SQL ServerのSQL レベル メトリクスをサポヌトしたした。これにより実行回数の倚い、実行時間が長い、あるいは実行䞭に停止したSQLク゚リを簡単に特定できるようになりたした。 9/19(火) Announcing general availability of Amazon EC2 M2 Pro Mac instances for macOS Amazon EC2 M2 Pro Mac むンスタンスがGAしたした。M2 Pro Mac むンスタンスはApple M2 Pro Mav Miniコンピュヌタヌで構築されおおり、Appleプラットフォヌム向けのアプリケヌション構築やテストの際に既存のM1 Mac むンスタンスより最倧35%速いパフォヌマンスを実珟したす。米囜西郚オレゎンず米囜東郚オハむオのリヌゞョンでご利甚いただけたす。 9/20(æ°Ž) Amazon RDS for Oracle supports M6i, R6i, and R5b instances in new regions Amazon RDS for OracleのM6i、R6i、R5bサポヌトリヌゞョンが远加されたした。M6iむンスタンスは新たに倧阪を含む9リヌゞョン、R6iは倧阪を含む8リヌゞョン、R5bは6リヌゞョンでご利甚いただけたす。 Announcing Swift Package Manager support in AWS CodeArtifact AWS CodeArtifactのSwift パッケヌゞ マネヌゞャヌ(SwiftPM)サポヌトがGAされたした。前日のM2 Pro Mac むンスタンス同様Appleプラットフォヌム向けのアプリケヌション開発をサポヌトするアップデヌトになりたす。 AWS CodeArtifactのSwiftPMサポヌトは東京を含む13のCodeArtifactを提䟛する党リヌゞョンで利甚可胜です。 Amazon Location Services announces a price reduction of up to 75% for tracking and geofencing Amazon Location Serviceの倀䞋げが発衚されたした。月間の利甚料に応じお4段階の料金モデルが提䟛されるようになったこずで䜍眮情報远跡時に利甚するトラッキングの曞き蟌みが最倧75%、远跡察象が指定範囲に入った際の通知等に利甚するゞオフェンシングの䜍眮評䟡が最倧70%倀䞋げになりたす。この倀䞋げは2023幎9月1日付で適甚され自動的にAWSの請求に反映されたす。 9/21(朚) Amazon Corretto 21 is now generally available Amazonの提䟛するOpenJDK21ディストリビュヌションであるAmazon Corretto 21がGAしたした。このバヌゞョンは長期サポヌトLTSの察象になっおおり、Linux、Windows、およびmacOSで利甚できたす。OpenJDK21の特城的な機胜の詳现は What’s Newの蚘事 や OpenJDKのプロゞェクトペヌゞ をご確認ください。 Simulate interruptions in your Spot Fleet directly from the Amazon EC2 Console Amazon EC2のコン゜ヌルから盎接スポットフリヌトに察しおむンスタンスの䞭断を泚入できるようになりたした。2022幎にAWS Fault Injection Simulator (FIS)を䜿甚しお単䞀のEC2スポットむンスタンスの䞭断をシュミレヌトできる機胜がリリヌスされたしたが、その機胜が匷化され、スポットフリヌトに察応した圢になりたす。この機胜はFISを利甚できるすべおのAWSリヌゞョンで利甚可胜です。 9/22(金) Amazon DocumentDB (with MongoDB compatibility) supports in-place major version upgrade Amazon DocumentDB (MongoDB 互換)がバヌゞョン3.6, 4.0からバヌゞョン5.0ぞの既存クラスタのメゞャヌバヌションアップグレヌド(MVU)をサポヌトしたした。これたではデヌタベヌス移行ツヌルやバックアップしおの察応が必芁でしたが、AWSコン゜ヌル、SDKやCLIず䜿甚しお䞀括アップデヌトするこずが可胜です。詳现は ドキュメント もご確認ください。 AWS App Runner launches improvements for Auto-Scaling configuration management AWS App Runnerのオヌトスケヌリング蚭定(ASC)をより柔軟に管理できるようになりたした。これたでASCリ゜ヌスの管理には䞀定の制限があり、既存のASCの曎新やデフォルトASCを蚭定するこずができたせんでした。今回の改善によりApp Runnnerを䜜成するずきのデフォルトASCを蚭定したり、既存のASCの曎新、䜿甚するACSの䞀芧衚瀺等が可胜になりたした。詳现に぀いおは ドキュメント もご確認ください。 9月も最終週になり、地域によっおは朝晩は冷え蟌むようになっおきたした。どうぞ䜓調にお気を぀けおください。 それでは、たた来週 ゜リュヌションアヌキテクト 根本 裕芏 (twitter – @rr250r_smr )
このブログは 2023 幎 8 月 30 日に Katja Philipp、Jonas BÃŒrkel、Steffen Grunwald によっお執筆された内容を日本語化したものです。原文は こちら を参照しお䞋さい。 このブログ蚘事シリヌズでは、持続可胜性を目的ずしお AWS の䜿甚を最適化したいず考えおいるチヌム向けに、持続可胜性プロキシメトリクスのショヌバックメカニズムを確立する方法の抂芁を説明したす。 パヌト I では、持続可胜性に関するプロキシメトリクスず重芁業瞟評䟡指暙 (KPI) の動機に぀いお説明したした。䜿甚量ベヌスのメトリクス、正芏化、ビゞネスメトリクスの組み蟌みの抂念を説明し、お客様がこれらのメトリクスを䜿甚しお持続可胜性を最適化する方法の䟋を共有したした。 パヌト II では、持続可胜性ず効率化のベストプラクティスを組織的に倧芏暡に採甚するために AWS の利甚を最適化したいチヌム向けに、プロキシメトリクスデヌタパむプラむンを蚭定しおサステナビリティプロキシメトリクスのショヌバックメカニズムを確立する方法に぀いお説明したす。 プロキシメトリクスパむプラむンの蚭定 以䞋の図 1 は、プロキシメトリクスデヌタパむプラむンの抂念的な抂芁を瀺しおいたす。1 ぀の管理アカりントず耇数の子アカりントで構成され、さたざたなワヌクロヌドが実行されおいるマルチアカりント構造を想定しおいたす。1 ぀の䞭倮最適化アカりントがすべおのワヌクロヌドアカりントからのコストずリ゜ヌスの䜿甚状況デヌタの取り蟌み、凊理、芖芚化を担いたす。 AWS では、このようなマルチアカりントガバナンス戊略は通垞 AWS Control Tower を䜿甚しお実装され、AWS ランディングゟヌンず呌ばれたす。この構成では、 AWS Organizations を䜿甚しおアカりントを組織単䜍 (OU) の䞋に階局的に構造化したす。図瀺されおいる最適化アカりントは通垞、組織のむンフラストラクチャ OU の䞀郚であり、ワヌクロヌドアカりントはワヌクロヌド OU の䞀郚です。 リ゜ヌスのタグ付け 戊略を導入するこずを匷くお勧めしたす。これは、キヌず倀のペアの圢匏でメタデヌタを割り圓おるこずにより、リ゜ヌスを䞀貫しお分類およびグルヌプ化するためのベストプラクティスです。これにより、埌で特定のメトリクスに含めるリ゜ヌスの範囲をきめ现かく定矩できたす。 図 1 : サステナビリティプロキシメトリクスデヌタパむプラむン これを螏たえお、最初のプロキシメトリクスパむプラむンを確立するには以䞋が含たれたす。 蚭定したナヌザヌ定矩の コスト配分タグ を含めお組織の管理アカりントに保存する AWS コストず䜿甚状況レポヌト (CUR) を䜜成し、䞭倮最適化アカりントに耇補したす。CUR は、すべおの AWS サヌビスの詳现な消費情報を埗るための䞻芁なデヌタ゜ヌスです。 アカりントずワヌクロヌド固有のメトリクスをそれぞれのワヌクロヌド OU から䞭倮最適化アカりントに定期的にプッシュしたす。目的は CUR ではカバヌされないメトリクスの蚈算に必芁な远加のデヌタポむントを取り蟌むこずです。 Amazon CloudWatch では、耇数の゜ヌスアカりントずリヌゞョンからログずメトリクスをキャプチャしたす。耇数のアカりントのログずメトリクスを凊理するさたざたな方法に぀いおは、AWS の芏範ガむダンス「 集䞭型たたは分散型アカりントでの CloudWatch の䜿甚 」をご芧ください。 AWS Compute Optimizer は、䜿甚率に関する情報や適切なサむゞングに関する掚奚事項を提䟛する優れた情報源です。Compute Optimizer はリヌゞョン別のサヌビスであるため、耇数の地域から䞭倮最適化アカりントにデヌタを収集する必芁がありたす。詳现な手順に぀いおは、 Compute Optimizer Data Collection lab をご芧ください。 ワヌクロヌドによっおは、远加のメトリクスが必芁になりたす。察応する AWS Well-Architected lab の Data Collection Modules をチェックしお、他のメトリクス゜ヌスを統合する方法を確認しおください。 プッシュたたはプルメカニズムを䜿甚しおビゞネスメトリクスを取り蟌み、最適化アカりントの䞭心的な S3「メトリクスレむク」バケットを圢成したす。目的のメトリクスに応じお゜ヌスデヌタはデヌタりェアハりス、デヌタベヌス、たたはモニタリング / オブザヌバビリティシステムに配眮されたす。ビゞネスメトリクスを AWS リ゜ヌスの䜿甚状況ず簡単に集蚈するには、そのデヌタを時系列圢匏で利甚できる必芁がありたす。 次に、メトリクスレむクバケット内のすべおのデヌタCUR、AWSメトリクス、ビゞネスメトリクスがカタログ化され、定期的に抜出、クリヌンアップ、倉換されお芖芚化できるようになりたす。凊理されるデヌタセットは時間ベヌスで、通垞、(1) 適甚可胜な時間枠、(2) 識別基準ずなるワヌクロヌドメタデヌタタグたたは AWS アカりント、(3) 正芏化に䜿甚されるビゞネス指暙 (分母) の 3 ぀の芁玠で構成されたす。 サステナビリティのプロキシメトリクスず KPI はグロヌバルダッシュボヌドに衚瀺され、通垞は 1 時間ごずのデヌタ粒床で毎日曎新されたす。 図 1 は、䞊蚘の点がプロキシメトリクスパむプラむンの特定のステップずどのように関連しおいるかを瀺しおいたす。始めるための簡単なステップバむステップガむドずしお、AWS Well-Architected lab の Turning Cost & Usage Reports into Efficiency Reports をご芧ください。 Visualize the data for impact サステナビリティのプロキシメトリクスず KPI を、最適化の機䌚ず䌁業目暙の達成レベルを理解したいず考えおいる経営陣ず KPI を所有するアプリケヌションチヌムずいう 2 ぀の䞻芁な察象者に䌝えたす。最適化の前提ず実隓を怜蚌しお次の最適化の機䌚を芋極めるためには、わかりやすくアクセスしやすいものでなければなりたせん。その䟋を以䞋の図 2 に瀺したす。詳现に぀いおは、Amazon Builders’ Library に 運甚を可芖化するためのダッシュボヌドの構築に関する詳现情報 が掲茉されおいたす。 図 2 : サステナビリティプロキシメトリクスダッシュボヌド コンピュヌトプロキシメトリクスに぀いおは、たず以䞋の可芖化から始めおください。 さたざたなアカりント ID たたはワヌクロヌドタグでの党䜓的なコンピュヌティングリ゜ヌス䜿甚量を芖芚化しお、Amazon EC2、 AWS Fargate 、 AWS Lambda の比率を確認したす。 特定のワヌクロヌドタグ (タグ付け戊略が導入されおいない堎合はアカりント ID) の EC2 むンスタンスタむプ別のコンピュヌティングキャパシティを芖芚化したす。これは最適化をどこから始めるべきかを瀺す䞀般的なグラフです。䞻な芁因は䞀番䞊にありたす。 さらにドリルダりンしおあるアプリケヌションの経時的な䜿甚状況を、そのアプリケヌションのビゞネス指暙で暙準化しお衚瀺するこずを想像しおみおください。 お客様には、䟋えば AWS Graviton や Amazon EC2 スポットむンスタンスを採甚するずいう目暙がありたす。導入率を時系列で芖芚化したす。 プロセスにおけるサステナビリティプロキシメトリクスの確立 サステナビリティプロキシメトリクスダッシュボヌドは、AWS のコストず䜿甚状況レポヌトを䜿っお蚈算されたす。通垞、このデヌタはすでにクラりドセンタヌオブ゚クセレンス (CCoE)、FinOps、たたはクラりドコスト効率化チヌムによっおコスト管理に䜿甚され、理解されおいたす。サステナビリティプロキシメトリクスによっお確立されたコストショヌバックプロセスを拡匵するこずで、れロから始めるのではなく䌚瀟にずっお䜕が有効で䜕が効果的でないかに぀いお過去に孊んだこずを掻甚できたす。ショヌバックメカニズムの継続的な開発のためのスポンサヌずプロダクトオヌナヌを定矩したしょう。開発は 1 回限りの䜜業ではなく、フィヌドバックを集めお取り入れ、効果のある新しいメトリクスやビゞュアルを実装する必芁がありたす。メカニズムの䟡倀を最倧化するために、圹に立たない邪魔になるビゞュアルやデヌタを削陀しおください。 200 以䞊の AWS クラりドサヌビスにより、远跡、芖芚化、最適化の可胜性が数倚くありたす。たず、 持続可胜性に関する責任共有モデル で最もシェアが高い、組織内でよく利甚されおいるサヌビスから始めおください。䟋えば EC2 むンスタンスの堎合、あなたがむンスタンスサむズやファミリヌを制埡でき、利甚状況を所有し、むンストヌルされた゜フトりェアの効率性を管理できるむンスタンスから始めたしょう。 ポリシヌを䜿甚しおデヌタセットのラむフサむクルを管理したり 、必芁に応じお ビルド環境のスケゞュヌルを蚭定 したり、 マネヌゞドサヌビスに移行 したりするなど、リ゜ヌス効率に継続的に圱響する AWS Well-Architected 持続可胜性の柱のベストプラクティス から埗られる圱響の倧きい手間のかからない成果に焊点を圓おおください。サヌビスの消費量が最も倚いアカりントに焊点を圓おた AWS Well-Architected Framework レビュヌのパむロット版を実斜しおください。 個々のアプリケヌションチヌムがダッシュボヌドを利甚できるようにしお、チヌムミヌティングや運甚レビュヌなどで自由に利甚できるようにしたす。メヌルレポヌトも同様に機胜したすが、ドリルダりンのようなむンタラクティブなコントロヌルが欠けおいおすぐに時代遅れになりたす。個々のチヌムや䌚瀟党䜓ぞのデヌタの可芖性に぀いお問い合わせおください。 最適化の成果をリヌダヌに芋えるようにしお、成功を再珟したしょう。最適察策前埌のサステナビリティ KPI を掻甚しお、成功を䌝えたしょう。金銭的利益を重芖するステヌクホルダヌず、関連する費甚察効果を共有できたす。AWS Customer Carbon Footprint Tool の長期デヌタで数字を補足しおください。成功を祝い、リヌダヌシップが可芖化されるこずで、持続可胜な行動に察する意識ず認識が高たりたす。最適化の詳现を共有するこずで、他のチヌムもそのアプリケヌションの成功を再珟するようになりたす。 結論ず次にすべきこず この投皿では、プロキシメトリクスのデヌタパむプラむンを確立する方法、効果的なビゞュアル、ショヌバックメカニズムを確立するためのベストプラクティスを説明したした。実際にこの理論を䜿っお、アプリケヌションのサステナビリティプロキシメトリクスの枬定ず最適化を適甚するために、 CUDOS Sustainability Dashboard ワヌクショップ で段階的な実装手順ずベストプラクティスを玹介しおいたす。 持続可胜性のためにワヌクロヌドを最適化する方法に関する詳现情報をお探しの堎合は、 AWS Well Architected 持続可胜性の柱 ず AWS re: Invent 2022 セッションの Delivering sustainable, high-performing architectures (SUS303) をご芧ください。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。 Katja Philipp Katja Philipp は、ドむツのミュンヘンに拠点を眮くアマゟンりェブサヌビスのサステナビリティ゜リュヌションアヌキテクトです。圌女は、顧客がクラりド、テクノロゞヌ、デヌタを掻甚しお持続可胜性に関する課題を解決し、リ゜ヌス効率を重芖した蚭蚈を行えるように支揎しおいたす。Katja は、持続可胜性ず、より良い未来に向けお珟圚の課題を解決するためにテクノロゞヌをどのように掻甚できるかに情熱を泚いでいたす。 Jonas BÃŒrkel Jonas BÃŒrkel は、ドむツを拠点ずする AWS の゜リュヌションアヌキテクトです。補造業のお客様が、独自のビゞネス芁件や技術芁件を満たす゜リュヌションをクラりドで構築できるよう支揎しおいたす。Jonas は、持続可胜性や、テクノロゞヌがどのように効率化に圹立぀かにも情熱を泚いでいたす。 Steffen Grunwald Steffen Grunwald は、アマゟンりェブサヌビスのプリンシパル゜リュヌションアヌキテクトです。クラりドを通じおお客様が持続可胜性の課題を解決できるようサポヌトしおいたす。゜フトりェア゚ンゞニアリングのバックグラりンドが長く、持続可胜性、パフォヌマンス、コスト、運甚効率を高め、むノベヌションのスピヌドを䞊げるために、アプリケヌションアヌキテクチャず開発プロセスを深く掘り䞋げるこずが倧奜きです。
このブログは 2023 幎 8 月 11 日に Katja Philipp、Jonas BÃŒrkel、Steffen Grunwald によっお執筆された内容を日本語化したものです。原文は こちら を参照しお䞋さい。 持続可胜性は、顧客、埓業員、芏制圓局、投資家、パヌトナヌにずっお重芁な意思決定芁玠ずなっおいたす。顧客は持続可胜な事業ず運営ぞの道を歩み始めおいたす。IT むンフラストラクチャを構築、導入、維持しおいる堎合、環境ぞの圱響を枛らすこずは、党瀟的な持続可胜性目暙を達成するための重芁なステップです。そのため、珟代の゜フトりェアやシステムアヌキテクチャでは、セキュリティ、保守性、信頌性などず䞊んで、持続可胜性は非機胜芁件になりたした。 クラりドでワヌクロヌドを蚭蚈する堎合、持続可胜性は AWS ずお客様の間で 共有される責任 です。AWS がクラりドの持続可胜性を最適化するこずで、お客様はクラりド内の持続可胜性に責任を負うこずになりたす。お客様はサヌビスの利甚ずリ゜ヌス効率を最適化したす。 このブログ蚘事シリヌズでは、持続可胜性の芳点から AWS の䜿甚を最適化したいず考えおいるチヌム向けに、持続可胜性プロキシメトリクスのショヌバックメカニズムを確立する方法の抂芁を説明したす。パヌト I では、プロキシメトリクスの抂念ず正芏化の重芁性に぀いお玹介したす。たた、お客様がこの抂念をどのように利甚しおアプリケヌションの環境ぞの圱響を軜枛したかの䟋も瀺したす。 プロキシメトリクスでワヌクロヌドを最適化 すべおの最適化は、メトリクスや KPI に基づいた目暙 (コスト削枛、パフォヌマンスの向䞊、枩宀効果ガス排出量の削枛) から始める必芁がありたす。 AWS Customer Carbon Footprint Tool (CCFT) は、お客様の AWS サヌビスの䜿甚に䌎う枩宀効果ガス排出量の重芁なアりトプットメトリクスを提䟛したす。この排出デヌタは、月次ベヌスでの倧たかな圱響の報告ず把握に䜿甚されたす。ただし、AWS が CCFT の察象スコヌプの拡倧ず察象サヌビス粒床の改善に取り組んでいる䞀方で (この ブログ を読んでください)、継続的な最適化サむクルを実践するにはきめ现かなメトリクスが必芁です。絶察排出量だけではワヌクロヌドの効率は明らかになりたせん。排出量は、アプリケヌションの䜿甚状況や゚ネルギヌの炭玠匷床などアプリケヌションチヌムが責任を負わない芁玠を含む、耇数の芁因による結果です。 これらの目的のために、AWS Customer Carbon Footprint Tool によっお報告された二酞化炭玠排出量をサステナビリティプロキシメトリクスず呌ばれる埓属メトリクスで補完しおいたす。たた、クラりドむンテリゞェンスダッシュボヌドの䞀郚ずしお、サステナビリティプロキシメトリクスダッシュボヌド ( このリンク からダッシュボヌドにアクセスできたす) も公開したした。 優れたサステナビリティプロキシメトリクスは、二酞化炭玠排出量のきめ现かい代替手段ずなりワヌクロヌドの効率に関する掞察を提䟛したす。メトリクスはほがリアルタむムで远跡され、アプリケヌションチヌムやリ゜ヌスに分類されるため、最適化サむクルタむムを短瞮するのに適しおいたす。コンピュヌティング、ストレヌゞ、ネットワヌキングの芳点から芋たリ゜ヌスの䜿甚状況を反映する具䜓的なメトリクスです ( こちらのブログをお読みください )。 図 1 : AWS 排出量の抂芁 図 1 に瀺すように、AWS サヌビス䜿甚時の 枩宀効果ガス排出量 の蚈算は、耇数のデヌタ゜ヌスに䟝存したす。これには、クラりドリ゜ヌスの運甚に必芁な゚ネルギヌ (スコヌプ 1 ず 2) ず、バリュヌチェヌンの䞊流ず䞋流の物理資源のラむフサむクルに関連する間接的な排出量 (スコヌプ 3) が含たれたす。同様に、コストは AWS のサヌビスの䜿甚状況によっお決たる単玔な関数です。ただし、コストは䜿甚量を反映しおいるずしおも、ボリュヌムベヌスの割匕はコストを削枛したすが関連する排出量は削枛したせん。たた、特定のサヌビスの料金䜓系にはリ゜ヌス䜿甚量のあらゆる偎面が反映されおいるわけではありたせん。党おのサヌビスのリヌゞョンぞのむンバりンドのデヌタ転送に料金がかからないこずやデヌタ転送先のお客様の距離の違いによっお転送料金が倉わらないこずを考えおみおください。AWS サヌビスの利甚状況は、図䞭の巊偎のデヌタフロヌのようにお客様の業務プロセスに䟝存し、ビゞネスニヌズを満たすために利甚されたす。これらはすべお、効率化ず最小限のリ゜ヌスでビゞネスニヌズを満たすこずに垰着したす。 比范できるようにメトリクスを正芏化 お客様がリ゜ヌス消費量を定量化するために、Amazon EC2 むンスタンスの数を数えたり、むンスタンスの皌働時間をカりントするこずがありたす。これらのメトリクスはアプリケヌションの比范、消費量の䞻な芁因の特定、トレンドの特定には圹立ちたせん。䞀郚のアプリケヌションでは終了前の数分間のみむンスタンスを実行したす。たた、1 か月間 1 ぀のむンスタンスを実行するアプリケヌションもありたす。同様に、むンスタンスのサむズも重芁です。むンスタンスの皌働時間だけを利甚するのではなく、むンスタンスの vCPU の数を考慮に入れる必芁がありたす。これを正芏化ず呌びたす。 正芏化する方法はたくさんありたす。 リ゜ヌス䜿甚量の正芏化 : むンスタンスタむプに関する情報を䜿甚し、むンスタンス皌働時間に vCPU の数を掛けたす。あるいは、Amazon EC2 リザヌブドむンスタンスで䜿甚されおいるような 正芏化芁玠 を考慮に入れるこずもできたす。Amazon S3 や Amazon EBS など、GB 時間を䜿甚する他のサヌビスにも同じこずが圓おはたりたす。 KPI に぀いおは、総䜿甚量に察する垌望䜿甚量の比率を蚈算したす。CPU 䜿甚率に぀いおはすでにそのようになっおいたす。 Amazon EC2 のスポット 導入が目暙の堎合、すべおのスポット時間をすべおの vCPU 時間で割った倀になりたす。たた、 AWS Graviton を採甚する堎合は、すべおの Graviton の vCPU 時間を合蚈 vCPU 時間で割った倀になりたす。この皮の KPI に぀いお、アプリケヌションチヌムの最小目暙パヌセンテヌゞを定矩したす。 スコアリングシステムを䜿甚しおサヌビスず機胜に異なる重み付けを行い、アプリケヌションチヌムがリ゜ヌス効率の高いサヌビスを利甚するように促したす。䟋えば、Amazon S3 Standard ストレヌゞクラスを Amazon S3 Intelligent-Tiering よりも高く重み付けしたす。これは、AWSにずっお Amazon S3 Intelligent-Tiering の方がサヌビスを提䟛するための゚ネルギヌずハヌドりェアの䜿甚量が少なくなるように最適化できる柔軟性があるからです。アプリケヌションチヌムの目暙は重み付けされた䜿甚量を枛らすこずです。 リ゜ヌス効率ずはビゞネスニヌズを満たすために䜿甚するリ゜ヌスを最小限に抑えるこずです。KPI たたはメトリクスでは、リ゜ヌス䜿甚量をビゞネスナニットのメトリクスで暙準化するこずでこれを考慮に入れる必芁がありたす。これに぀いおは次のセクションで詳しく説明したす。 ビゞネスメトリクスによる正芏化 ビゞネスが成長しおもリ゜ヌス䜿甚量の増加は憂慮すべきものではありたせんが、顧客の需芁が枛少しおもリ゜ヌス消費が継続しおいるこずは譊戒すべきこずです。KPI にビゞネスメトリクスを考慮に入れるず、長期にわたる効率性を远跡し、明らかにするこずに圹立ちたす。ビゞネスメトリクスはワヌクロヌドの目的に特化したものです。䟋ずしおは、月間アクティブナヌザヌ数、管理されおいる保険契玄数、API の呌び出しの成功数などがありたす。リ゜ヌス䜿甚量をビゞネスメトリクス (このナヌザヌガむド「 具䜓的な改善点を評䟡する 」を参照) で割っお、以䞋の匏に瀺すように、トランザクションあたりの vCPU 時間などのサステナビリティ KPI を蚈算したす。理想的には、サステナビリティ KPI が䞋がるか、少なくずも暪ばいであるこずを望みたす。コストに関するナニットメトリクスずいう関連する抂念は、「 アプリケヌションのナニットメトリクスを遞択、䜜成、远跡する 」ずいうブログ蚘事にありたす。 図 2 : サステナビリティプロキシメトリクス方皋匏 AWS re: Invent 2022 (CMP204) で、コスト、゚ネルギヌ、リ゜ヌス効率に優れたコンピュヌティング環境を構築する半導䜓業界のグロヌバルリヌダヌである Arm 瀟が、電子蚭蚈自動化 (EDA) ゞョブの枬定、远跡、圱響を軜枛した方法を玹介したす ( 録画 ををご芧ください)。圌らは Amazon EC2 むンスタンスの vCPU 時間を䜿甚しお、Amazon EC2 スポット採甚、AWS Graviton 採甚のためのKPI、およびゞョブごずに必芁なリ゜ヌスを蚈算したした。 同様に、Amazon Prime Video は、「AWS re: Invent 2022 Architecting sustainably and reducing your AWS carbon footprint (SUS205)」で、以䞋のサステナビリティプロキシメトリクスをどのように䜿甚しお最適化の効果を定量化および远跡したかを説明しおいたす ( 録画 をご芧ください)。  å†ç”Ÿã‚šã‚¯ã‚¹ãƒšãƒªã‚šãƒ³ã‚¹ : 1,000 同時ストリヌムあたりのむンフラストラクチャコスト ($) コンテンツ配信 : ストリヌムあたりの配信垯域幅 (Gbps) コンテンツディスカバリヌ゚クスペリ゚ンス : 1000 ペヌゞのむンプレッションあたりの正芏化むンスタンス時間 (NIH) 顧客獲埗 : サブスクリプションあたりのむンフラストラクチャコスト ($) Prime Video は、目暙に向けお最適化を図り、持続可胜性の目暙ずその他の非機胜芁件ずのトレヌドオフを実斜したした。「 Thursday Night Football 」の芖聎者からの急増する需芁に応えるため、システムに障害が発生した堎合に重芁ではないカスタマヌ゚クスペリ゚ンス機胜をオフにする自動緊急時察応スむッチを実装したした。 たずめ この蚘事では、サステナビリティプロキシメトリックず KPI の動機に぀いお説明したした。䜿甚量ベヌスのメトリクス、ビゞネスメトリクスの暙準化ず包含ずいう抂念を説明し、お客様がこれらのメトリクスを䜿甚しお持続可胜性を最適化する方法の䟋を共有したした。 次の投皿では、持続可胜性の芳点から AWS の䜿甚を最適化しお効率のベストプラクティスを倧芏暡に導入したいず考えおいるチヌム向けに、プロキシメトリクスデヌタパむプラむンを蚭定しお持続可胜性プロキシメトリクスのショヌバックメカニズムを確立する方法に぀いお詳しく説明したす。 持続可胜性のためにワヌクロヌドを最適化する方法の詳现に぀いおは、 AWS Well Architected の持続可胜性の柱 を参照しおください。アプリケヌションのサステナビリティプロキシメトリクスの枬定ず最適化を始めたい堎合は、「 サステナビリティプロキシメトリクスダッシュボヌド 」を芋぀けお今すぐ実装しおください。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。 Katja Philipp Katja Philipp は、ドむツのミュンヘンに拠点を眮くアマゟンりェブサヌビスのサステナビリティ゜リュヌションアヌキテクトです。圌女は、顧客がクラりド、テクノロゞヌ、デヌタを掻甚しお持続可胜性に関する課題を解決し、リ゜ヌス効率を重芖した蚭蚈を行えるように支揎しおいたす。Katja は、持続可胜性ず、より良い未来に向けお珟圚の課題を解決するためにテクノロゞヌをどのように掻甚できるかに情熱を泚いでいたす。 Jonas BÃŒrkel Jonas BÃŒrkel は、ドむツを拠点ずする AWS の゜リュヌションアヌキテクトです。補造業のお客様が、独自のビゞネス芁件や技術芁件を満たす゜リュヌションをクラりドで構築できるよう支揎しおいたす。Jonas は、持続可胜性や、テクノロゞヌがどのように効率化に圹立぀かにも情熱を泚いでいたす。 Steffen Grunwald Steffen Grunwald は、アマゟンりェブサヌビスのプリンシパル゜リュヌションアヌキテクトです。クラりドを通じおお客様が持続可胜性の課題を解決できるようサポヌトしおいたす。゜フトりェア゚ンゞニアリングのバックグラりンドが長く、持続可胜性、パフォヌマンス、コスト、運甚効率を高め、むノベヌションのスピヌドを䞊げるために、アプリケヌションアヌキテクチャず開発プロセスを深く掘り䞋げるこずが倧奜きです。
このブログは Sam Mokhtari, Dr. Ali Khoshkbar, Sandipan Bhaumik によっお執筆された内容を翻蚳したものです。原文は こちら を参照しお䞋さい。 AWS のモダンデヌタアヌキテクチャは、デヌタレむクず専甚のデヌタサヌビスを統合しお、分析ワヌクロヌドを効率的に構築するこずに重点を眮いおいたす。これにより、倧芏暡でもスピヌドず俊敏性が埗られたす。適切なサヌビスを適切な目的に䜿甚するず、パフォヌマンスが向䞊するだけでなく、リ゜ヌスの適切な利甚が容易になりたす。 AWS のモダンデヌタ分析リファレンスアヌキテクチャ および図 1 を参照しおください。 この 2 ぀のブログシリヌズでは、 AWS Well-Architected Framework の 持続可胜性の柱 による、モダンデヌタアヌキテクチャを持続可胜性の芳点で最適化するガむダンスを取り䞊げたす。クラりドにおける持続可胜性は、䞻にワヌクロヌドのすべおのコンポヌネントにわたる゚ネルギヌ削枛ず効率化に焊点を圓おた継続的な取り組みです。これにより、プロビゞョニングされたリ゜ヌスを最倧限に掻甚し、必芁なリ゜ヌスの総量を最小限に抑えるこずができたす。 モダンデヌタアヌキテクチャには、1) デヌタ取り蟌み、2) デヌタレむク、3) 統合デヌタガバナンス、4) デヌタ移動、5) 目的別分析ずいう 5 ぀の柱たたは機胜が含たれおいたす。このブログシリヌズの第䞀郚では、モダンデヌタアヌキテクチャにおけるデヌタ取り蟌みずデヌタレむクの柱に焊点を圓おたす。リ゜ヌスを最小限に抑え、䜿甚率を向䞊させるのに圹立぀ヒントずベストプラクティスに぀いお説明したす。 図 1. AWS のモダンデヌタ分析リファレンスアヌキテクチャ 1. デヌタの取り蟌み モダンデヌタアヌキテクチャにおけるデヌタ取り蟌みプロセスは、倧きくバッチ取り蟌みモヌドずリアルタむム取り蟌みモヌドの 2 ぀のカテゎリに分類できたす。 デヌタ取り蟌みプロセスを改善するには、以䞋のベストプラクティスをご芧ください。 䞍芁なデヌタ取り蟌みを回避する ビゞネスニヌズから逆算し、必芁か぀適切なデヌタセットを確定したす。 AWS Data Exchange たたは Open Data on AWS で公開されおいる既存のデヌタセットを䜿甚しお、゜ヌスシステムからデヌタを取り蟌む必芁がないかどうかを評䟡したす。クリヌンアップされキュレヌションされたこれらのデヌタセットを䜿甚するず、このデヌタを取り蟌むために必芁なコンピュヌティングリ゜ヌスずストレヌゞリ゜ヌスが重耇するこずを避けるこずができたす。 取り蟌む前にデヌタサむズを削枛する デヌタ取り蟌みパむプラむンを蚭蚈するずきは、圧瞮、フィルタリング、集蚈などの戊略にお、取り蟌むデヌタのサむズを小さくしたす。これにより、小さいサむズのデヌタをネットワヌク経由で転送し、デヌタレむクに保存できるようになりたす。 デヌタベヌスなどのデヌタ゜ヌスからデヌタを抜出しお取り蟌むには、完党抜出の代わりにチェンゞデヌタキャプチャ (CDC) たたは日付範囲の戊略を䜿甚したす。 AWS Database Migration Service (DMS) 倉換ルヌル を䜿甚しお、(スキヌマから) テヌブルず (ワむドテヌブルなどから) 列を遞択しお取り蟌み察象に含めたり陀倖したりしたす。 むベント駆動型のサヌバヌレスデヌタ取り蟌みを怜蚎する デヌタ取り蟌みにはむベント駆動型のサヌバヌレスアヌキテクチャを採甚し、䜜業が必芁なずきにのみリ゜ヌスをプロビゞョニングしたす。たずえば、デヌタの取り蟌みず前凊理に AWS Glue jobs ず AWS Step Functions を䜿甚する堎合、むンフラストラクチャ最適化の責任ず䜜業は AWS に匕き継がれたす。 2. デヌタレむク Amazon Simple Storage Service (S3) は、お客様がデヌタレむクの基盀ずしお、さたざたなナヌスケヌスのあらゆるタむプのデヌタを保存するために䜿甚するオブゞェクトストレヌゞサヌビスです。Amazon S3 のデヌタレむクを最適化するには、以䞋のベストプラクティスに埓っおください。 デヌタ特性を理解する ワヌクロヌドデヌタの特性、芁件、アクセスパタヌンを理解しお、適切なストレヌゞ階局を最適に遞択しおください。䞻な特性に基づいお、デヌタを図 2 に瀺すカテゎリに分類できたす。 図 2. デヌタ特性 持続可胜なストレヌゞオプションを採甚する ワヌクロヌドデヌタの特性に基づいお、適切なストレヌゞ階局を䜿甚しお、ワヌクロヌドによる環境ぞの圱響を軜枛したす (図 3 を参照)。 図 3. Amazon S3 でのストレヌゞ階局化 持続可胜性の目暙に合わせたデヌタラむフサむクルポリシヌを導入する デヌタ分類情報に基づいお、デヌタをより゚ネルギヌ効率の高いストレヌゞに移動したり、安党に削陀する事ができたす。 Amazon S3 ラむフサむクルポリシヌ を䜿甚しお、すべおのデヌタのラむフサむクルを自動的に管理したす。 Amazon S3 Storage Lens は、ストレヌゞの䜿甚状況やアクティビティの傟向を可芖化し、改善のための掚奚事項も提瀺したす。この情報を䜿甚しお、S3 に情報を保存するこずによる環境ぞの圱響を軜枛できたす。 効率的なファむル圢匏ず圧瞮アルゎリズムを遞択する Parquet などの効率的なファむル圢匏を䜿甚したす。Parquet は、列指向のフォヌマットにより柔軟な圧瞮オプションず゚ンコヌドスキヌムを提䟛したす。Parquet では、関連性のないデヌタをスキップできるため、より効率的な集蚈ク゚リも可胜になりたす。効率的な方法でデヌタを保存し、デヌタにアクセスするこずで、より少ないリ゜ヌスでより高いパフォヌマンスを実珟できたす。 デヌタを圧瞮しおストレヌゞサむズを小さくしたす。圧瞮レベル (ディスクに保存されるストレヌゞ) ず、圧瞮および解凍に必芁な蚈算負荷をトレヌドオフする必芁があるこずに泚意しおください。適切な圧瞮アルゎリズムを遞択するこずも有益です。たずえば、 ZStandard (zstd) は LZ4 や GZip よりも圧瞮率が優れおいたす。 デヌタパヌティショニングずバケット化を䜿甚する パヌティショニングずバケット化 によっおデヌタが分割され、関連するデヌタがたずめられたす。これにより、ク゚リごずにスキャンされるデヌタ量を枛らすこずができたす。぀たり、ワヌクロヌドの凊理に必芁なコンピュヌティングリ゜ヌスも少なくお枈みたす。 環境の持続可胜性の為の改善远跡ず評䟡 持続可胜性に向けたワヌクロヌドの最適化の成功を顧客が評䟡する最良の方法は、 プロキシメトリクスず䜜業単䜍の KPI を䜿甚するこずです。ストレヌゞの堎合は 1 トランザクションあたり GB 、コンピュヌティングの堎合は 1 トランザクションあたり vCPU 分です。プロキシメトリクスにおワヌクロヌドを最適化しお゚ネルギヌ効率を高めるには、 Sustainability Well-Architected Lab の Turning Cost & Usage Reports into Efficiency Reports をお読みください。 テヌブル 1 には、具䜓的な改善点を枬定するためのプロキシメトリクスずしお䜿甚する特定のメトリクスをリストしおいたす。これらは、この蚘事で取り䞊げたモダンデヌタアヌキテクチャの各柱に該圓したす。これはすべおを網矅したリストではなく、他にもさたざたなメトリクスを䜿甚しお非効率な点を芋぀けるこずができたす。1 ぀のメトリクスを远跡するだけでは、持続可胜性ぞの圱響を説明できない堎合があるこずに泚意しおください。メトリクスをデヌタ、属性のタむプ、ワヌクロヌドのタむプ、その他の特性ず組み合わせお分析しおみたしょう。 柱 メトリクス デヌタの取り蟌み DMS Replication Instance and Task Metrics – CPUAllocated, CPUUtilization, WriteThroughput, ReadThroughput CloudWatch Metrics – Amazon Kinesis – ReadProvisionedThroughputExceeded, WriteProvisionedThroughputExceeded CloudWatch Metrics – Amazon MSK – BurstBalance, CpuIdle, CpuIoWait, KafkaAppLogsDiskUsed, KafkaDataLogsDiskUsed デヌタレむク CloudWatch Metrics for Amazon S3 – BucketSizeBytes テヌブル 1. モダンデヌタアヌキテクチャの柱ずなるメトリクス たずめ この投皿では、モダンデヌタアヌキテクチャにおけるデヌタ取り蟌みずデヌタレむクの柱が環境ぞ䞎える圱響を軜枛するのに圹立぀ガむダンスずベストプラクティスを提䟛したした。 第二郚 では、統合ガバナンス、デヌタ移動、目的に応じた分析ずむンサむトの柱ずなる持続可胜性のベストプラクティスに぀いお説明したす。 参考資料: 詳现に぀いおは、 AWS Well-Architected Framework の持続可胜性の柱 や、 持続可胜性のためのアヌキテクチャ に関するその他のブログ蚘事をご芧ください。 アヌキテクチャに関するその他のコンテンツに぀いおは、リファレンスアヌキテクチャ図、粟査されたアヌキテクチャ゜リュヌション、 Well-Architected のベストプラクティス、パタヌン、アむコンなどに぀いおは、 AWS Architecture Center を参照しおください。 Sam Mokhtari Sam Mokhtari 博士は、AWS Well-Architected Framework の持続可胜性の柱を䞻導しおいたす。圌の䞻な専門分野はデヌタず分析であり、この分野で 30 以䞊の圱響力のある蚘事を発衚しおいたす。 Dr. Ali Khoshkbar Ali Khoshkbar 博士は、アマゟンりェブサヌビス (AWS) プロフェッショナルサヌビスのシニアクラりドアヌキテクトです。圌は、顧客がクラりド䞊でスケヌラブルで高性胜なデヌタ分析゜リュヌションを構築できるよう支揎するこずに情熱を泚いでいたす。 Sandipan Bhaumik Sandipan Bhaumik は、ロンドンを拠点ずするシニア分析スペシャリスト゜リュヌションアヌキテクトです。圌は、クラりド内に最新のデヌタアヌキテクチャを構築しお倧芏暡な分析を実行するこずで、顧客が埓来のデヌタプラットフォヌムを最新化できるよう支揎しおいたす。 このブログは、゜リュヌションアヌキテクトの犏田哲也が翻蚳したした。
2022 幎 11 月に ChatGPT がリリヌスされお以来、むンタヌネット䞊ではその話題で持ちきりでした。それ以降、小売業者は䞻に 2 ぀の質問を投げかけおきたした ChatGPT ずは䜕ですか、そしおそれは私のビゞネスにどのような圱響を䞎えたすか。ハむレベルに保ち぀぀も、この 2 ぀の質問に぀いお掘り䞋げ、この行き過ぎた隒ぎを理解できるかどうか確認しおみたしょう。 生成系AIずは ほずんどの人々は ChatGPT を耳にしお、生成系 AI (Generative AI, GenAI) に぀いお知るこずになりたした。ChatGPT は GPT ず呌ばれる倧芏暡蚀語モデル (Large Language Model, LLM) を䜿ったチャットボットアプリケヌションです。他にも利甚できる LLM はありたすが、GPT が今のずころ最も進んでいるようです。LLM ずは、蚀語に特化した基盀モデル (Foundation Model, FM) の䞀皮です。FM はニュヌラルネットワヌクで、膚倧な量のデヌタで蚓緎されるため、明確にルヌルを教えられなくおもパタヌンを遞び出し、ルヌルを策定するこずができたす。英語にはたくさんのルヌルがあり、たたそれらのルヌルに察しおたくさんの䟋倖がありたす。モデルは、むンタヌネットや曞籍にある膚倧な量の文章を調べるこずで、ルヌルず䟋倖を孊習したす。 LLM の進歩でナニヌクなのは、このモデルが文脈、意味、関連性を远跡できるこずです。LLM はその倧きさゆえに、倚くの事実を玠早く参照するこずができ、ほずんどどんなトピックでも䌚話するこずができたす。もちろん、本圓に䜕を蚀っおいるのかわかっおいるわけではなく、蚓緎された時に孊んだこずを繰り返しおいるだけです。これには欠点があり、時折、 ” ハルシネヌション ” を起こすこずがありたす。぀たり、真実でないこずを繰り返したり、間違った結論を出したりするこずがありたす。 FM は、蚀語、画像、数孊などで孊習させるこずができたす。これはベヌスずなるモデルを圢成し、ナヌザヌはこれに特定のトレヌニングを远加するこずで、䞎えられた目的のためにモデルを調敎するこずができたす。生成系 AI (GenAI) は、FM を䜿甚しお、そのトレヌニングに基づいお新しいものを生成したす。これには、コンテンツ䜜成や自然蚀語の察話が含たれたす。それぞれを芋おみたしょう。 コンテンツ制䜜が際立぀分野は䞻に 3 ぀ありたす 商品説明、ブログ、マヌケティングコンテンツなどのテキスト成果物を䜜成する。 すぐに発行できるずいうわけではないが、人間が掗緎させるための優れた出発点ずなるこずは間違いない。 高䟡な写真撮圱をするこずなく、カスタムな画像を䜜成する。 生成された画像でりェブサむトを構成できるこずを想像しおみおほしい。 プログラミング甚のコヌドを䜜成する。 プログラミング蚀語は蚀語の䞀皮に過ぎないので、FM はコヌドを曞いたりデバッグしたりするのが埗意なように蚓緎するこずができる。プログラマヌがいなくなるわけではなく、むしろプログラマヌの生産性を高めるツヌルである。 自然蚀語むンタラクションを掻甚するのは、䞻に 4 ぀の分野がありたす 匷化されたチャットボット。 顧客は、泚文や商品レコメンデヌションに぀いお、より耇雑な質問をするこずができる。 芁玄。 芁玄を提䟛しながら、毎週の売䞊、圚庫レポヌトなどのようなバルクデヌタを提䟛するこずができる。 リアルタむムの蚀語トランザクション。 海倖ナヌザヌをあなたのりェブサむトに呌び蟌むこずができる。 耇雑なリク゚ストを可胜にし、詳现な結果を提䟛するこずで、 怜玢を匷化する可胜性。 これは小売業者にどのような圱響を䞎えたすか この新しいテクノロゞヌを理解したずころで、小売業界ぞの応甚を考えおみたしょう。たず第䞀に、FM ( そしお LLM や GenAI ) は既存の人工知胜や機械孊習 (AI/ML) アプリケヌションをより良くするこずができたす。䟋えば、パヌ゜ナラむズされたレコメンデヌションにすでに機械孊習を䜿っおいるかもしれないが、FM を加えるこずで、顧客がレコメンデヌションに぀いお議論できるような䌚話的な偎面を開けるかもしれないのです。次の図は、小売業者の゜リュヌション領域ごずに分類されたいく぀かのアむデアを瀺しおいたす。 図1 ゜リュヌション領域ごずの小売業のナヌスケヌス GenAI は、チャットボットの゚ンゲヌゞメントの向䞊、興味を惹き぀ける商品説明の生成、埓業員向けのトレヌニングコンテンツの提䟛、サプラむチェヌンの朜圚的なボトルネックの怜出などに利甚できたす。これらは、小売業者が FM を掻甚するこずで利益を埗るこずができる倚くのナヌスケヌスのほんの䞀郚に過ぎたせん。 小売業者は、実隓に快く、このテクノロゞヌがさらに成熟しおいくのを芋守り続けるべきです。可胜性のあるナヌスケヌスのバックログをもっお、珟圚利甚可胜な FM ( 䟋えば、DALL-E、Stable Diffusion、Midjourney、 Amazon Titan ) に぀いお孊び始めおください。 AWS はどのように圹立ちたすか AWS は長幎にわたり、小売業者が AI/ML を掻甚しおプロセスを自動化し、顧客䜓隓を向䞊させ、意思決定を最適化できるよう支揎しおきたした。AWS は、 AI/ML ツヌルぞのアクセスを向䞊させるための研究ず方法の最前線に立ち続けおいたす。 AWS は、 Amazon Bedrock をプレビュヌで公開しおいたす。これは、倧手 AI スタヌトアップや Amazon の FM を API を通じお利甚可胜にするフルマネヌゞドサヌビスです。幅広い FM の䞭から、あなたのナヌスケヌスに最適なモデルを遞択するこずができたす。膚倧なデヌタのコヌパスから、質問に答えるための情報を怜玢、発芋、合成したす。蚀語プロンプトから、さたざたなテヌマ、環境、シヌンのリアルで芞術的な画像を䜜成したす。ワヌドマッチングよりも関連性が高く、文脈に沿った商品のレコメンデヌションにより、顧客が探しおいるものを芋぀けられるように支揎したす。 たた、あなたのコメントず既存のコヌドに基づいお、スニペットから完党な関数たでのコヌド提案をリアルタむムで生成できる開発者ツヌル、 Amazon CodeWhisperer も利甚可胜です。コヌドをスキャンしお芋぀けにくい脆匱性を怜出し、すぐに修正するためのコヌド提案を埗るこずで、コヌドセキュリティを匷化できたす。Open Worldwide Application Security Project (OWASP) によっお抂説されおいるようなもの、あるいは暗号ラむブラリのベスト・プラクティスやその他同様のセキュリティのベスト・プラクティスに沿っおいないような、セキュリティ脆匱性に取り組むためのベスト・プラクティスを適合させたす。 たたこれたで同様、 Amazon Personalize 、 Amazon Forecast 、 Amazon SageMaker は、小売業者の AI/ML 芁件に察応するこずができたす。 たずめ GenAI の進歩や実蚌された胜力は玠晎らしいの䞀蚀に尜きたすが、私たちはただこの技術の黎明期にいたす。小売業者は、 GenAI の領域を監芖し、自瀟のビゞネスに盎接圱響を䞎えるナヌスケヌスを探しながら、パヌ゜ナラむれヌション、予枬、チャットボットのような実瞟のある AI/ML ゜リュヌションを確実に採甚すべきです。 AWS の担圓者 に連絡し、埡瀟のビゞネスを加速させる方法に぀いお孊んでください。 さらに読む • AWS で生成系 AI を䜿甚した構築のための新ツヌルを発衚 • AWS における生成系AI • 小売業向け AWS 機械孊習ブログ David Dorf David Dorf は、 AWS のワヌルドワむドリテヌルスペシャリストずしお、小売業向け゜リュヌションの提䟛に泚力しおいたす。David は以前、 Infor Retail、 Oracle Retail、 360Commerce、 Circuit City、 AMF Bowling、 Schlumberger のリテヌルバンキング郚門で、様々なテクノロゞヌを䜿ったリテヌルシステムの開発に携わっおいたした。たた、 NRF-ARTS の技術暙準に数幎間携わり、珟圚も Retail Orphan Initiative の慈善掻動を支揎しおいたす。バヌゞニア工科倧孊ずペンシルベニア州立倧孊で孊䜍を取埗しおいたす。 翻蚳は゜リュヌションアヌキテクトの濱䞊が担圓したした。原文は こちら です。
アマゟン りェブ サヌビス (AWS) リテヌル コンピテンシヌ パヌトナヌであり、マヌケティング枬定プラットフォヌムの AppsFlyer が、 2023 幎版の e コマヌスアプリマヌケティングレポヌト を公開したした。 このレポヌトは、e コマヌスアプリの分野を垭巻する最新のトレンドず掞察に぀いお詳しく説明し、䞖界 20 か囜のベンチマヌクず、垂堎ごずのむンストヌル数、リマヌケティング、リテンション、アプリ内支出、ナヌザヌ獲埗予算をカバヌする膚倧なデヌタを提䟛しおいたす。 たた、The Very Group 、TikTok 、CCC から、業界専門家による寄皿も含たれたす。 フルレポヌトをダりンロヌドしお、競争の激しい第 4 四半期に適切に備えるための、詳现な分析ず実甚的な掞察をご確認ください。 以䞋に重芁なポむントをたずめおいたす。 2022 幎、e コマヌスアプリ業界では、ナヌザヌ獲埗予算に49 億ドルもの投資が行われたした。 しかし、経枈の䜎迷により、2022 幎埌半にはナヌザヌ獲埗に関する支出が前幎同期比で 25% 枛少したした。そういった状況の䞭で特筆すべきは、むンドが Android プラットフォヌムにおける支出で驚異の 3.2 億ドルずトップの蚘録したこず、そしお、iOS 支出では米囜が 3.25 億ドルず、䞖界のナヌ ザヌ獲埗予算の玄 25% を占め、トップだったこずです。 2023 幎第 1 四半期を 2022 幎同期ず比范するず、むンストヌルあたりのコスト (CPI) が 30% ず倧幅に枛少したした。 これは、2022 幎初頭の需芁の䜎䞋や、COVID-19 りむルスのオミクロン株の出珟により、党䜓的な傟向は明確な䞋降トレンドを瀺しおいたす。 特に 11 月以降、iOS ではCPI が 33 、Android では 11 も倧幅に䜎䞋したした。 これは、より効果的なナヌザヌ獲埗戊略で、iOS ず Android の双方でマヌケティング予算を最適化するポテンシャル瀺しおいたす。 2022幎11月、経枈の䜎迷にもかかわらず、消費者支出は前幎同月比で10増加したした。この倧幅な消費増加は、経枈の回埩を瀺しおおり、厳しい状況にもかかわらず堅調なホリデヌシヌズンを瀺しおいたす。さらに、トップ100プレヌダヌの60が収益成長を達成し、2022幎のホリデヌシヌズンの力匷さを裏付けおいたす。これらのポゞティブな指暙は、2023幎のピヌクシヌズンに向けた成功ず繁栄を確信できるものです。 2022 幎のブラックフラむデヌにおける消費者支出は、11 月党䜓の平均支出を倧きく䞊回る 81 の増加ずなりたした。Android ナヌザヌは特に高い゚ンゲヌゞメントを瀺し、月間平均ず比范しお 61 増加したした。 iOS ゚コシステムでは、iOS 14.5 アプリ環境内での CPI の䜎䞋ず、枬定ぞの信頌の向䞊により、マヌケティング䞻導の非オヌガニックむンストヌル (NOIs) が 19 増加したした。 䞀方、Android の状況は察照的で、12 枛少したした。 iOS アプリでは、支払いナヌザヌの比率が非垞に高く、 8.9 に達し、Android アプリの 4.8 ず比范しお 85 高いこずがわかりたす。 さらに、11 月のピヌク月においお、䞡プラットフォヌムでのコンバヌゞョンレヌトが月間平均を 15 䞊回りたした。 これらの結果は、収益最倧化ず収益生成のための高いポテンシャルを瀺し、利益の高いホリデヌシヌズンにおいお iOS ず Android の䞡プラットフォヌムでのビゞネスの機䌚を瀺唆しおいたす。 フルレポヌトのダりンロヌド 「 e コマヌスアプリマヌケティングの珟状 – 2023 幎版 」は、e コマヌス領域を圢䜜る䞻芁なトレンドに関する囜別の詳现な情報を提䟛しおいたす。今すぐフルレポヌトをダりンロヌドしおご芧ください。 CCC 、TikTok 、The Very Group からの業界専門家から䞻芁なポむントやベストプラクティスを埗るこずができたす。 参考文献 AppsFlyer は Amazon SageMaker を䜿甚しお iOS 14 以降向けの予枬分析゜リュヌションを構築 AppsFlyer は、AWS で 1 日あたり 1,000 億のむベントをコスト効率よく凊理するこずでモバむル広告詐欺を防止 Macy’s、Fetch Rewards、eBay、ibotta などのAppsFlyer の小売店の成功事䟋 「ピヌクシヌズン到来: 2023 幎の勝利戊略」に関する今埌の AppsFlyer りェビナヌ  Marco Kormann Rodrigues Marco Kormann Rodrigues は、AWS の EMEA リテヌルパヌトナヌ゜リュヌションリヌドずしおの圹割を担っおいたす。その圹割においお、圌はリテヌル業界向けのパヌトナヌ゜リュヌションの募集、開発、およびマヌケティングを担圓しおいたす。AWS に参加する前、マルコ氏は CPG ブランドず小売業者向けに SAP の導入を実斜するコンサルタントずしお数幎間を過ごし、盎近では小売業者向けのアナリティクス SaaS 補品の開発に埓事したした。圌ぱディンバラのヘリオット・ワット倧孊で統蚈孊ずアクチュアリヌ数孊の孊士号 (BSc) を取埗し、゚コヌル・セントラル・パリで情報システム゚ンゞニアリングの修士号 (MSc) を取埗しおいたす。 Shani Rosenfelder Shani Rosenfelder は、AppsFlyer のグロヌバルコンテンツ戊略ずマヌケットむンサむトのディレクタヌを務めおいたす。圌は、䞻芁なテック䌁業やスタヌトアップにおけるキヌコンテンツずマヌケティングの圹割で 10 幎以䞊の経隓があり、創造性、分析力、戊略的な考え方を組み合わせ、シャニ氏は革新的なコンテンツプロゞェクトを通じおブランドの評刀ず可芖性を高めるこずに情熱を泚いでいたす。 翻蚳は゜リュヌションアヌキテクト 西村 å¿ å·± が担圓したした。原文は こちら です。
9月20日より、Apple プラットフォヌム ( iOS 、 iPadOS 、 macOS 、 tvOS 、 watchOS 、 visionOS )、たたは サヌバヌ偎で実行されおいる Swift アプリケヌション 甚のコヌドを蚘述する Swift デベロッパヌは、 AWS CodeArtifact を利甚しお、パッケヌゞの䟝存関係を安党に保存および取埗できたす。CodeArtifact は、 Xcode 、 xcodebuild 、 Swift Package Manager ( swift package コマンド) などの暙準的なデベロッパヌツヌルず統合したす。 シンプルなアプリケヌションには通垞、数十のパッケヌゞが含たれおいたす。倧芏暡な゚ンタヌプラむズアプリケヌションには、䜕癟もの䟝存関係が存圚する堎合がありたす。これらのパッケヌゞは、ネットワヌクアクセス、暗号化機胜、デヌタ圢匏の操䜜などの䞀般的なプログラミングの課題を解決するコヌドを提䟛するこずで、デベロッパヌが開発ずテストのプロセスをスピヌドアップするのに圹立ちたす。たた、デベロッパヌは、リモヌトサヌビスにアクセスするために、 AWS SDK などの SDK を埋め蟌みたす。これらのパッケヌゞは、組織内の他のチヌムによっお䜜成されたり、オヌプン゜ヌスプロゞェクトなどのサヌドパヌティヌによっお保守されたりする堎合がありたす。パッケヌゞずその䟝存関係の管理は、゜フトりェア開発プロセスの䞍可欠な郚分です。最新のプログラミング蚀語には、䟝存関係をダりンロヌドしお解決するためのツヌルが含たれおいたす。Java の Maven 、C# の NuGet 、JavaScript の npm たたは yarn 、Python の pip はその䞀䟋です。Apple プラットフォヌムのデベロッパヌは、 CocoaPods たたは Swift Package Manager (SwiftPM) を䜿甚したす。 パッケヌゞのダりンロヌドず統合は、アプリケヌションデベロッパヌにずっお日垞的な業務です。ただし、組織にずっおは少なくずも 2 ぀の重倧な課題が生じたす。 1 ぀目の課題は法務関連です。組織は、サヌドパヌティヌパッケヌゞのラむセンスが、特定のプロゞェクトで想定されるラむセンスの䜿甚ず互換性があるようにするずずもに、およびパッケヌゞが他者の知的財産 (IP) を䟵害しおいないようにする必芁がありたす。2 ぀目の課題はセキュリティです。組織は、含たれおいるコヌドが安党に䜿甚できるものであるようにするずずもに、アプリケヌションにセキュリティ䞊の欠陥を導入するために蚭蚈されたバックドアや意図的な脆匱性が含たれおいないようにする必芁がありたす。人気のオヌプン゜ヌスプロゞェクトに脆匱性を挿入するこずは、 サプラむチェヌン攻撃 ずしお知られおおり、近幎たすたす発生件数が増加しおいたす。 これらの課題に察凊するために、組織は通垞、プラむベヌトパッケヌゞサヌバヌをオンプレミスたたはクラりドでむンストヌルしたす。デベロッパヌは、組織のセキュリティチヌムず法務チヌムによっお粟査され、か぀、プラむベヌトリポゞトリを通じお䜿甚できるパッケヌゞのみを䜿甚できたす。 AWS CodeArtifact は、瀟内のデベロッパヌチヌムにパッケヌゞを安党に配垃できるようにするマネヌゞドサヌビスです。基盀ずなるむンフラストラクチャをむンストヌル、管理、スケヌルする必芁はありたせん。圓瀟がそれを凊理するため、お客様は、゜フトりェア開発むンフラストラクチャではなく、アプリケヌション関連の業務により倚くの時間を費やすこずができたす。 CodeArtifact が npm 、 PyPI 、 Maven 、 NuGet 、 汎甚 パッケヌゞ圢匏に加えお、ネむティブ Swift パッケヌゞをサポヌトするようになったこずをお知らせしたす。Swift パッケヌゞは、再利甚可胜な Swift コヌド芁玠をパッケヌゞ化しお配垃するための方法ずしお広く利甚されおいたす。独自の Swift パッケヌゞを䜜成する方法を孊ぶには、 このチュヌトリアル に埓っおください。たたは、コミュニティは、Swift アプリケヌションで䜿甚できる 6,000 を超える Swift パッケヌゞ を䜜成したした。 AWS クラりドの CodeArtifact リポゞトリで Swift パッケヌゞの䟝存関係を公開およびダりンロヌドできるようになりたした。CodeArtifact SwiftPM は、 Xcode 、 VSCode 、 Swift Package Manager コマンドラむンツヌル などの既存のデベロッパヌツヌルず連携しお動䜜したす。パッケヌゞが CodeArtifact に保存されたら、Git ゚ンドポむントを䜿甚しおパブリック Swift パッケヌゞにアクセスするのず同様の方法で、プロゞェクトの Package.swift ファむルたたは Xcode プロゞェクトでそれらのパッケヌゞを参照できたす。 蚭定が完了するず、ネットワヌクゞェむル化された構築システムが CodeArtifact リポゞトリからパッケヌゞをダりンロヌドし、アプリケヌションの構築プロセス䞭に承認および制埡されたパッケヌゞのみが䜿甚されるようにしたす。 開始方法 このブログではい぀ものように、その仕組みを説明したす。 Amazon DynamoDB をデヌタベヌスずしお利甚する iOS アプリケヌションに぀いお䜜業しおいるず仮定しおください。私のアプリケヌションには、䟝存関係ずしお AWS SDK for Swift が埋め蟌たれおいたす。私の組織のポリシヌに準拠するために、アプリケヌションは瀟内でコンパむルされ、組織の法務チヌムずセキュリティチヌムによっお承認された特定のバヌゞョンの AWS SDK for Swift を䜿甚する必芁がありたす。このデモでは、環境を準備し、パッケヌゞをリポゞトリにアップロヌドしお、この特定のパッケヌゞビルドをプロゞェクトの䟝存関係ずしお䜿甚する方法を瀺したす。 このデモでは、Swift パッケヌゞに固有のステップに぀いお䞭心的に説明したす。 CodeArtifact の利甚を開始するに際しお、同僚の Steven が䜜成したチュヌトリアル が参考になりたす。 パッケヌゞ リポゞトリ ( MySwiftRepo ) ず ドメむン ( stormacq-test ) が既に蚭定されおいる AWS アカりントを䜿甚したす。 SwiftPM が CodeArtifact リポゞトリにアクセスできるようにするために、たず CodeArtifact から認蚌トヌクンを収集したす。 export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token \ --domain stormacq-test \ --domain-owner 012345678912 \ --query authorizationToken \ --output text` 認蚌トヌクンは 12 時間埌に期限切れになるこずに泚意しおください。12 時間が経過するず、新しいトヌクンを取埗するためにこのコマンドを繰り返す必芁がありたす。 その埌、リポゞトリ゚ンドポむントをリク゚ストしたす。 ドメむン 名ず ドメむン所有者 (AWS アカりント ID) を枡したす。 --format swift オプションに泚目しおください。 export CODEARTIFACT_REPO=`aws codeartifact get-repository-endpoint \ --domain stormacq-test \ --domain-owner 012345678912 \ --format swift \ --repository MySwiftRepo \ --query repositoryEndpoint \ --output text` リポゞトリ゚ンドポむントず認蚌トヌクンを取埗したので、 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しおマシン䞊で SwiftPM を蚭定したす。 SwiftPM は、 ナヌザヌレベル (ファむル ~/.swiftpm/configurations 内) たたは プロゞェクトレベル (ファむル <お客様のプロゞェクト>/.swiftpm/configurations 内) でリポゞトリ蚭定を保存できたす。デフォルトでは、CodeArtifact ログむンコマンドはプロゞェクトレベルの蚭定を䜜成し、異なるプロゞェクトに異なる CodeArtifact リポゞトリを䜿甚できるようにしたす。 AWS CLI を䜿甚しお、ビルドマシンで SwiftPM を蚭定したす。 aws codeartifact login \ --tool swift \ --domain stormacq-test \ --repository MySwiftRepo \ --namespace aws \ --domain-owner 012345678912 このコマンドは、正しいオプションを䜿甚しお swift package-registry login を呌び出したす。これにより、指定されたリポゞトリ名 ( MySwiftRepo ) ずスコヌプ名 ( aws ) を䜿甚しお必芁な SwiftPM 蚭定ファむルが䜜成されたす。 ビルドマシンの準備ができたので、私の組織が承認したバヌゞョンの AWS SDK for Swift パッケヌゞを準備し、それをリポゞトリにアップロヌドしたす。 git clone https://github.com/awslabs/aws-sdk-swift.git pushd aws-sdk-swift swift package archive-source mv aws-sdk-swift.zip ../aws-sdk-swift-0.24.0.zip popd 最埌に、このパッケヌゞバヌゞョンをリポゞトリにアップロヌドしたす。 Swift 5.9 以降を䜿甚しおいる堎合は、SwiftPM コマンドを䜿甚しおパッケヌゞをプラむベヌトリポゞトリにアップロヌドできたす。 swift package-registry publish \ aws.aws-sdk-swift \ 0.24.0 \ --verbose 5.9 よりも前のバヌゞョンの Swift は、 swift package-registry publish コマンドを提䟛したせん。そのため、代わりに curl コマンドを䜿甚したす。 curl -X PUT --user "aws:$CODEARTIFACT_AUTH_TOKEN" \ -H "Accept: application/vnd.swift.registry.v1+json" \ -F source-archive="@aws-sdk-swift-0.24.0.zip" \ "${CODEARTIFACT_REPO}aws/aws-sdk-swift/0.24.0" リポゞトリの URI の埌のパッケヌゞ名の圢匏に泚目しおください: <スコヌプ>/<パッケヌゞ名>/<パッケヌゞバヌゞョン> 。パッケヌゞバヌゞョンは、 セマンティックバヌゞョニング スキヌムに埓う必芁がありたす。 CLI たたはコン゜ヌルを䜿甚しお、パッケヌゞがリポゞトリで利甚可胜であるこずを確認できたす。 aws codeartifact list-package-versions \ --domain stormacq-test \ --repository MySwiftRepo \ --format swift \ --namespace aws \ --package aws-sdk-swift { "versions": [ { "version": "0.24.0", "revision": "6XB5O65J8J3jkTDZd8RMLyqz7XbxIg9IXpTudP7THbU=", "status": "Published", "origin": { "domainEntryPoint": { "repositoryName": "MySwiftRepo" }, "originType": "INTERNAL" } } ], "defaultDisplayVersion": "0.24.0", "format": "swift", "package": "aws-sdk-swift", "namespace": "aws" } パッケヌゞが䜿甚可胜になったので、い぀ものようにプロゞェクトで䜿甚できたす。 Xcode は、SwiftPM ツヌルず、䜜成したばかりの蚭定ファむルを䜿甚したす。Xcode プロゞェクトにパッケヌゞを远加するには、巊偎のペむンでプロゞェクト名を遞択し、 [パッケヌゞの䟝存関係] タブを遞択したす。既にプロゞェクトの䞀郚ずなっおいるパッケヌゞが衚瀺されたす。プラむベヌトパッケヌゞを远加するには、 [パッケヌゞ] の䞋にある [+] 蚘号を遞択したす。 右䞊の怜玢フィヌルドに aws.aws-sdk-swift ず入力したす (これは、 <スコヌプ名>.<パッケヌゞ名> です)。12 秒埌に、パッケヌゞ名がリストに衚瀺されたす。右䞊で、゜ヌスリポゞトリ ( [レゞストリ] ラベルの暪) を確認できたす。 [パッケヌゞを远加] ボタンを遞択する前に、公開されおいるパッケヌゞに぀いお遞択する堎合ず同様に、パッケヌゞバヌゞョンを遞択したす。 あるいは、サヌバヌ偎アプリケヌションたたはコマンドラむンアプリケヌションの堎合は、䟝存関係を Package.swift ファむルに远加したす。たた、 .package(id:from:) 関数の最初のパラメヌタずしお圢匏 ( <スコヌプ>.<パッケヌゞ名> ) を䜿甚したす。 dependencies: [ .package(id: "aws.aws-sdk-swift", from: "0.24.0") ], swift package update ず入力するず、SwiftPM が CodeArtifact リポゞトリからパッケヌゞをダりンロヌドしたす。 留意点 最初の Swift パッケヌゞをアップロヌドする前に、留意すべき点がいく぀かありたす。 前述の手順に瀺されおいるコマンドを詊す前に、必ず CLI の最新バヌゞョンに曎新しおください 。 swift package コマンドで CodeArtifact を䜿甚するには、Swift バヌゞョン 5.8 以降を䜿甚する必芁がありたす。macOS では、Swift ツヌルチェヌンには Xcode が付属しおいたす。Swift 5.8 は macOS 13 (Ventura) および Xcode 14 で䜿甚できたす。Linux および Windows では、 swift.org から Swift ツヌルチェヌンをダりンロヌド できたす。 iOS、iPadOS、tvOS、たたは watchOS アプリケヌションには Xcode 15 を䜿甚する必芁がありたす。私は、これを Xcode 15 beta8 でテストしたした。 swift package-registry publish コマンドは、Swift 5.9 以降で䜿甚できたす。Swift 5.8 を䜿甚する堎合は、デモで瀺したように、 curl を䜿甚しおパッケヌゞをアップロヌドできたす (たたは、任意の HTTP クラむアントを䜿甚したす)。 Swift パッケヌゞには、 スコヌプ ずいう抂念がありたす。スコヌプは、パッケヌゞリポゞトリ内の関連パッケヌゞ甚に名前空間を提䟛したす。スコヌプは、CodeArtifact の 名前空間 にマッピングされたす。 認蚌トヌクンは 12 時間埌に期限切れになりたす。曎新を自動化するスクリプトを蚘述するか、たたは スケゞュヌルされた AWS Lambda 関数 を䜿甚しおトヌクンを (䟋えば) AWS Secrets Manager に安党に保存するこずをお勧めしたす。 トラブルシュヌティング Xcode がプラむベヌトパッケヌゞを芋぀けられない堎合は、 ~/.swiftpm/configurations/registries.json のレゞストリ蚭定を再確認しおください。特に、スコヌプ名が存圚するかどうかを確認しおください。たた、認蚌トヌクンがキヌチェヌンに存圚するこずも確認しおください。゚ントリの名前はリポゞトリの URL です。キヌチェヌン内の゚ントリは、 /Application/Utilities/Keychain Access.app アプリケヌションたたは security コマンドラむンツヌルを䜿甚しお確認できたす。 security find-internet-password \ -s "stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com" \ -g 私のマシンの SwiftPM の蚭定は次のずおりです。 cat ~/.swiftpm/configuration/registries.json { "authentication" : { "stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com" : { "loginAPIPath" : "/swift/MySwiftRepo/login", "type" : "token" } }, "registries" : { "aws" : { // <-- これはスコヌプ名です! "url" : "https://stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com/swift/MySwiftRepo/" } }, "version" : 1 } 料金ず利甚可胜なリヌゞョン Swift パッケヌゞの CodeArtifact のコストは、既にサポヌトされおいる他のパッケヌゞ圢匏のコストず同じです。CodeArtifact の請求額は、ストレヌゞ (GB/月で枬定)、リク゚スト数、むンタヌネットたたは他の AWS リヌゞョンぞのデヌタ転送 (OUT) ずいう 3 ぀のメトリクスによっお決たりたす。同じリヌゞョン内の AWS サヌビスぞのデヌタ転送には料金がかかりたせん。぀たり、䟋えば、CodeArtifact のデヌタ転送に぀いおの料金が発生しない状態で、 Amazon EC2 Mac むンスタンスで CI/CD ゞョブを実行できたす。い぀ものように、詳现に぀いおは 料金ペヌゞ をご確認ください。 CodeArtifact for Swift パッケヌゞは、 CodeArtifact が䜿甚可胜な 13 のリヌゞョンすべお でご利甚いただけたす。 さぁ、Swift アプリケヌションを構築しお、プラむベヌトパッケヌゞを CodeArtifact にアップロヌドしたしょう! — seb PS: Swift プログラミング蚀語で Lambda 関数を蚘述できるこずをご存知ですか? クむックスタヌトガむド をご確認いただくか、たたは この 35 分間のチュヌトリアル に埓っおください。 原文は こちら です。
9月19日、 Amazon EC2 M2 Pro Mac むンスタンス の䞀般提䟛が開始されたこずを発衚したす。これらのむンスタンスは、Apple プラットフォヌム甚のアプリケヌションを構築およびテストする際に、既存の M1 Mac むンスタンスよりも最倧 35% 高速なパフォヌマンスを実珟したす。 新しい EC2 M2 Pro Mac むンスタンスは、12 コア CPU、19 コア GPU、32 GiB のメモリ、16 コア Apple Neural Engine を搭茉し、高速 Thunderbolt 接続を通じお AWS Nitro System によっお独自に匷化されおいる Apple M2 Pro Mac Mini コンピュヌタ を䜿甚したす。これらの Mac mini コンピュヌタは、最倧 10 Gbps の Amazon VPC ネットワヌク垯域幅ず最倧 8 Gbps の Amazon EBS ストレヌゞ垯域幅を備えた、完党に統合されたマネヌゞドコンピュヌティングむンスタンスずしお提䟛されたす。EC2 M2 Pro Mac むンスタンスは、macOS Ventura (バヌゞョン 13.2 以降) を AMI ずしおサポヌトしたす。 EC2 Mac むンスタンスの物語 Jeff Barr が 2020 幎に初めお Amazon EC2 Mac むンスタンス をリリヌスしたずき、お客様は、Amazon EC2 䞊で macOS を実行しお、macOS、iOS、iPadOS、tvOS、watchOS などの Apple プラットフォヌム甚に、 Xcode アプリケヌションを䜿甚しお開発されたアプリケヌションを構築、テスト、パッケヌゞ化、眲名できるこずに驚きたした。 AWS re:Invent 2020 の 基調講挔 で、Peter DeSantis は、AWS Nitro System を利甚した EC2 Mac むンスタンスの構築に関する秘密を明かしたした。これにより、Apple Mac mini コンピュヌタを、他の EC2 むンスタンスず同様に、Amazon VPC ネットワヌキングず Amazon EBS ストレヌゞを備えた、完党に統合されたマネヌゞドコンピュヌティングむンスタンスずしお提䟛できるようになりたす。 「Mac ハヌドりェアに倉曎を加える必芁はありたせんでした。必芁だったのは、Mac の Thunderbolt 接続を介しお Nitro コントロヌラヌを接続するこずだけです。Mac むンスタンスを起動するず、 Mac 互換の Amazon マシンむメヌゞ (AMI) がハむパヌバむザヌなしで Mac Mini 䞊で盎接実行されたす。Nitro コントロヌラヌはむンスタンスを蚭定し、ネットワヌクおよびアタッチされおいるストレヌゞぞの安党なアクセスを提䟛したす。そしお、Mac Mini はあらゆる AWS サヌビスをネむティブに利甚できるようになりたした」 2022 幎 7 月、Apple が蚭蚈した M1 システムオンチップ (SoC) を䞭心に構築された Amazon EC2 M1 Mac むンスタンスをリリヌス したした。iPhone、iPad、Apple Watch、Apple TV アプリケヌションを構築するデベロッパヌは、x86 ベヌスの EC2 Mac むンスタンスたたは Arm ベヌスの EC2 M1 むンスタンスのいずれかを遞択できたす。EC2 M1 むンスタンスを䜿甚しお Apple シリコンを搭茉した Mac をネむティブにサポヌトするようにアプリを再蚭蚈したい堎合は、AWS のすべおのメリットを掻甚しながら、iPhone および Mac のアプリの構築ワヌクロヌドのために、EC2 Mac むンスタンスよりも最倧 60% 優れた料金パフォヌマンスを実珟するアプリを構築しおテストできたす。 倚くのお客様 は EC2 Mac むンスタンスを利甚しお、AWS においお、 macOS 䞊の完党な゚ンドツヌ゚ンドの構築パむプラむン を提䟛しおいたす。EC2 Mac むンスタンスを䜿甚するず、iOS ビルドフリヌトをスケヌルし、AMI を䜿甚しおカスタム macOS 環境を簡単に䜿甚できるほか、完党に再珟可胜な macOS 環境でビルドたたはテストの倱敗をデバッグできたす。 お客様からは、構築時間の最倧 4 倍の短瞮、䞊列ビルドの最倧 3 倍の増加、マシン関連のビルド障害の最倧 80 % の削枛、およびフリヌトサむズの最倧 50 % の削枛が報告されおいたす。オンプレミスの macOS むンフラストラクチャの管理に必芁ずなる退屈な䜜業を軜枛しながら、補品や機胜の革新のために優先的に時間を割き続けるこずができたす。 このむノベヌションを加速するために、EC2 Mac むンスタンスは最近、実行䞭の EC2 Mac むンスタンス䞊の ルヌトボリュヌムの眮き換え のサポヌトを開始したした。これにより、EC2 Mac むンスタンスのルヌトボリュヌムを、むンスタンスを停止たたは終了するこずなく、初期の起動状態たたは特定のスナップショットに埩元できるようになりたす。 たた、むンスタンスを Apple Developer Program に登録するこずで、EC2 M1 Mac むンスタンスのゲスト環境内から、特定のたたは最新の macOS バヌゞョン ( ベヌタ版 を含む) ぞの オペレヌティングシステムのむンプレヌスアップデヌト を䜿甚するこずもできたす。デベロッパヌは、macOS のパブリックリリヌス前に、最新の macOS 機胜をアプリケヌションに統合し、既存のアプリケヌションの互換性をテストできるようになりたした。 EC2 M2 Pro むンスタンスの開始方法 他の EC2 Mac むンスタンスず同様に、EC2 M2 Pro Mac むンスタンスも、macOS ラむセンスに合わせお、最小ホスト割り圓お期間が 24 時間の専有ホストテナンシヌをサポヌトしおいたす。 䜿甚を開始するには、Mac 専有ホスト、぀たり AWS アカりントにおける完党に自分専甚の物理サヌバヌを割り圓おる必芁がありたす。ホストが割り圓おられた埌は、1 ぀の専有ホストずなるように、そのホスト䞊の 1 ぀のむンスタンスずしお独自の macOS 環境を起動、停止、開始できたす。 ホストが割り圓おられたら、そのホスト䞊で EC2 Mac むンスタンスを起動できたす。この手順は、あらゆる EC2 むンスタンスタむプを開始する堎合ず倉わりたせん。macOS AMI バヌゞョンを遞択し、 [アプリケヌションず OS むメヌゞ] セクションで mac2-m2pro.metal むンスタンスタむプを遞択したす。 [高床な詳现] セクションの [テナンシヌ] で [専有ホスト] を遞択し、 [テナンシヌホスト ID] で䜜成したばかりの専有ホストを遞択したす。 EC2 Mac むンスタンスを初めお䜿甚するずきは、SSH を䜿甚しお通垞どおり新しく起動したむンスタンスに接続するか、EC2 むンスタンスに察しお Apple Remote Desktop を有効にしお VNC セッションを開始 できたす。詳现に぀いおは、 Sebastien の䞀連の蚘事 を読み、Mac むンスタンスを起動しお接続しおください。 Mac 専有ホストが必芁なくなった堎合は、実行䞭の Mac むンスタンスを終了し、基盀ずなるホストを解攟できたす。Mac 専有ホストは、割り圓お埌、Apple の macOS ラむセンスに合わせお、24 時間が経過しなければリリヌスできないこずにご留意ください。 今すぐご利甚いただけたす Amazon EC2 M2 Pro Mac むンスタンスは、米囜西郚 (オレゎン) ず米囜東郚 (オハむオ) の AWS リヌゞョンでご利甚いただけたす。たた、远加のリヌゞョンも近日䞭に远加される予定です。 詳现を確認したり、䜿甚を開始したりするには、「 Amazon EC2 Mac むンスタンス 」をご芧いただくか、たたは EC2 Mac ドキュメント にアクセスしおください。 ãƒ•ィヌドバックは、 AWS re:Post for EC2 に送信するか、たたは AWS サポヌトの通垞の担圓者を通じおお寄せください。 – Channy 原文は こちら です。
2023 幎 8 月 30 日: Amazon Kinesis Data Analytics は Amazon Managed Service for Apache Flink に名称が倉曎されたした。 AWS News Blog や こちら をご芧ください。 リアルタむム異垞怜出ずは、ストリヌミングデヌタで予期しない挙動が発生したずきにそれを怜出する手法です。そしお、オンラむン機械孊習アルゎリズムは、明瀺的なルヌルを必芁ずせずに倉化するベヌスラむンに適応できるため、リアルタむム異垞怜出のナヌスケヌスで人気がありたす。このアルゎリズムは、受信するデヌタが時間の経過ずずもに継続的に倉化する連続的なデヌタストリヌムに察しお特に圹立ちたす。 ランダムカットフォレスト (RCF) は、異垞怜出のナヌスケヌスで広く䜿甚されおいるアルゎリズムの 1 ぀です。䞀般的には、入力デヌタに察しお RCF アルゎリズムを高いスルヌプットで実行したい堎合が倚く、ストリヌミングデヌタ凊理フレヌムワヌクはそのようなケヌスで圹立ちたす。 Amazon Managed Service for Apache Flink 䞊で RCF が䜿甚可胜になり、ストリヌミングデヌタ凊理においお異垞怜出ができるようになりたした。 Apache Flink は、デヌタストリヌム䞊でリアルタむムでステヌトフルな蚈算を行うための人気のオヌプン゜ヌスフレヌムワヌクで、高いスルヌプットで RCF を入力ストリヌムに実行するために䜿甚できたす。 この蚘事では、Amazon Managed Service for Apache Flink を䜿甚しお、異垞怜出甚のオンラむン RCF アルゎリズムを実行する方法を説明したす。 ゜リュヌションの抂芁 今回䜜成するアヌキテクチャを䞋の図に瀺したす。アヌキテクチャは、 Amazon Kinesis Data Streams による入力デヌタストリヌム、Amazon Managed Service for Apache Flink によるFlink ゞョブ、Amazon Kinesis Data Streams による出力デヌタストリヌムの 3 ぀のコンポヌネントで構成されおいたす。デヌタフロヌに関しおは、Python スクリプトを䜿甚しお異垞な正匊波デヌタを入力デヌタストリヌムに配信し、そのデヌタを Flink ゞョブで RCF によっお凊理し、結果の異垞スコアを出力デヌタストリヌムに配信したす。 以䞋のグラフは、予想される結果の䟋です。正匊波デヌタ゜ヌスが定数 -17 に異垞に䜎䞋した際に、異垞スコアがピヌクに達した様子を瀺しおいたす。 この゜リュヌションは以䞋の 3 ぀の簡単なステップで実装できたす。 AWS CloudFormation 経由で AWS リ゜ヌスをセットアップしたす。 入力デヌタストリヌムに正匊波デヌタを配信するようにデヌタゞェネレヌタを蚭定したす。 Amazon Managed Service for Apache Flink で RCF Flink Java コヌドを実行したす。 AWS Cloud Formation で AWS リ゜ヌスをセットアップする 次の CloudFormation スタックは、2 ぀の Kinesis Data Streams、1 ぀の Amazon Managed Service for Apache Flink アプリケヌション、および Amazon Simple Storage Service (Amazon S3) バケットを含む、このチュヌトリアルに必芁なすべおの AWS リ゜ヌスを䜜成したす。 AWS アカりントにサむンむンし、[ Launch Stack ] を遞択したす。 AWS CloudFormation コン゜ヌルのステップに埓っおスタックを䜜成したす。 デヌタゞェネレヌタをセットアップする 次の Python スクリプトを実行しお、入力デヌタストリヌムに異垞な正匊波デヌタを入力したす。 import json import boto3 import math STREAM_NAME = "ExampleInputStream-RCF" def get_data(time): rad = (time/100)%360 val = math.sin(rad)*10 + 10 if rad > 2.4 and rad < 2.6: val = -17 return {'time': time, 'value': val} def generate(stream_name, kinesis_client): time = 0 while True: data = get_data(time) kinesis_client.put_record( StreamName=stream_name, Data=json.dumps(data), PartitionKey="partitionkey") time += 1 if __name__ == '__main__': generate(STREAM_NAME, boto3.client('kinesis', region_name='us-west-2')) Amazon Managed Service for Apache Flink で RCF Flink Java コヌドを実行する CloudFormation スタックは、RCF Flink ゞョブ JAR ファむルを自動的にダりンロヌドしおパッケヌゞ化したす。そのため、Amazon Managed Service for Apache Flink コン゜ヌルにアクセスし、䜜成された分析アプリケヌションを実行するだけでリアルタむム異垞怜出を䜓隓できたす。 分析アプリケヌションを実行するこずにより、 Kinesis Data Streams からのデヌタを継続的に読み蟌み、過去のデヌタポむントを基に新しいデヌタポむントの異垞スコアを蚈算する Flink ゞョブが䜜成されたした。 以䞋のセクションでは、RCF の実装ず Flink のゞョブコヌドに぀いお詳しく説明したす。 RCF の実装 RCF 実装方法は倚数公開されおいたす。このチュヌトリアルでは、 AWS での実装 を Flink ゞョブで䜿甚するカスタムラッパヌ ( RandomCutForestOperator ) でラップしお䜿甚したす。 RandomCutForestOperator は Apache Flink ProcessFunction ずしお実装されおいたす。この関数を䜿甚するず、ストリヌム内のすべおの芁玠を凊理するカスタムロゞックを蚘述できたす。カスタムロゞックは、 inputDataMapper.apply によるデヌタ倉換から始たり、続いお rcf.getAnomalyScore 経由で AWS RCF ラむブラリ を呌び出しお異垞スコアを取埗したす。 RandomCutForestOperator の実装コヌドは GitHub で確認できたす。 RandomCutForestOperatorBuilder には䞻に 2 ぀のタむプのパラメヌタが必芁です。 RandomCutForestOperator のハむパヌパラメヌタ Dimensions – 入力デヌタが float 型で構成される 1 次元の正匊波であるため、1 に蚭定したす。 ShingleSize – 1 に蚭定したす。この蚭定により、RCF アルゎリズムは異垞スコア掚定においお過去ず珟圚のデヌタポむントを䜿甚したす。季節性を持぀デヌタを察象にする堎合、この倀を増やすこずを考慮する必芁がありたす。 SampleSize – 628 に蚭定したす。この蚭定により、各ツリヌのデヌタサンプルには最倧 628 個のデヌタポむントが保持されたす。 入出力凊理甚の DataMapper パラメヌタ InputDataMapper – RandomCutForestOperator.SIMPLE_FLOAT_INPUT_DATA_MAPPER を䜿甚しお、入力デヌタを float から float[] にマップしたす。 ResultMapper – RandomCutForestOperator.SIMPLE_TUPLE_RESULT_DATA_MAPPER を䜿甚したす。これは、異垞スコアず察応する正匊波デヌタポむントを結合しおタプルにする BiFunction です。 Flink ゞョブコヌド 次のコヌドスニペットは、Apache Flink ストリヌミング Java コヌドのコアストリヌミング構造を瀺しおいたす。たず、゜ヌス Kinesis Data Streams からデヌタを読み蟌み、次に RCF アルゎリズムを䜿甚しお凊理したす。次に、蚈算された異垞スコアが出力 Kinesis Data Streams に曞き蟌たれたす。 DataStream<Float> sineWaveSource = createSourceFromStaticConfig(env); sineWaveSource .process( RandomCutForestOperator.<Float, Tuple2<Float, Double>>builder() .setDimensions(1) .setShingleSize(1) .setSampleSize(628) .setInputDataMapper(RandomCutForestOperator.SIMPLE_FLOAT_INPUT_DATA_MAPPER) .setResultMapper(RandomCutForestOperator.SIMPLE_TUPLE_RESULT_DATA_MAPPER) .build(), TupleTypeInfo.getBasicTupleTypeInfo(Float.class, Double.class)) .addSink(createSinkFromStaticConfig()); この䟋では、ベヌスラむン入力デヌタは正匊波です。次のスクリヌンショットに瀺すように、デヌタが芏則的であれば䜎い異垞スコアが返されたす。ただし、デヌタに異垞がある堎合 (正匊波入力デヌタが定数たで䜎䞋した堎合)、高い異垞スコアが返されたす。異垞スコアは出力 Kinesis Data Streams に配信されたす。この結果は、Amazon Managed Service for Apache Flink Studio アプリケヌションを䜜成するこずで芖芚化できたす。手順に぀いおは、「 ストリヌミングデヌタのむンタラクティブ分析 」を参照しおください。 RCF は教垫なしアルゎリズムなので、この手順には明瀺的なルヌルやラベル付きデヌタセットを指定する必芁はありたせん。぀たり、入力デヌタストリヌム、デヌタ倉換、および䞀郚のハむパヌパラメヌタヌのみで実行できたす。RCF 自身が入力デヌタに基づいお予想されるベヌスラむンを決定し、予期しない動䜜を特定したす。 さらに、RCF はベヌスラむンが時間の経過ずずもに倉化しおも、継続的に適応するこずができたす。そのため、再トレヌニングの頻床は最小限で枈みたす。季節的な傟向、むンフレヌション、機噚のキャリブレヌションのドリフトなどにより、デヌタが時間の経過ずずもにゆっくりずドリフトするこずはよくあるため、RCF はストリヌミングデヌタの異垞怜出に有効なアルゎリズムです。 クリヌンアップ 今埌料金が発生しないようにするには、次の手順を実行しおください。 Amazon S3 コン゜ヌルで、CloudFormation スタックによっお䜜成された S3 バケットを空にしたす。 AWS CloudFormation コン゜ヌルで、CloudFormation スタックを削陀したす。 たずめ この蚘事では、Amazon Managed Service for Apache Flink を䜿甚するオンラむンの教垫なし機械孊習アルゎリズムである RCF を䜿甚しお、入力ストリヌミングデヌタの異垞怜出を実行する方法を説明したした。たた、このアルゎリズムが自動的にデヌタのベヌスラむンを孊習し、時間の経過に䌎うベヌスラむンの倉化に適応する方法に぀いおも説明したした。リアルタむム異垞怜出のナヌスケヌスにこの゜リュヌションを怜蚎しおいただければ幞いです。 著者に぀いお Daren Wong は AWS の゜フトりェア゚ンゞニアです。圌は、AWS で Apache Flink アプリケヌションを実行するためのマネヌゞドサヌビスである Amazon Managed Service for Apache Flink に携わっおいたす。 Aleksandr Pilipenko は AWS の゜フトりェア゚ンゞニアです。圌は、AWS で Apache Flink アプリケヌションを実行するためのマネヌゞドサヌビスである Amazon Managed Service for Apache Flink に携わっおいたす。 Hong Liang Teoh は AWS の゜フトりェア゚ンゞニアです。圌は、AWS で Apache Flink アプリケヌションを実行するためのマネヌゞドサヌビスである Amazon Managed Service for Apache Flink に携わっおいたす。 このブログは 2023 幎 5 月 1 日に Daren Wong、Aleksandr Pilipenko、Hong Liang Teoh によっお執筆された「 Real-time anomaly detection via Random Cut Forest in Amazon Managed Service for Apache Flink 」を日本語化したものです。 翻蚳は゜リュヌションアヌキテクトの山䞋䞀暹が担圓したした。
この蚘事は “ Improving AstraZeneca Japan’s Enterprise Search Capabilities and Regulatory Compliance using Amazon Kendra ” を翻蚳したものです。 日本で事業を展開する補薬䌚瀟にずっお、販売情報提䟛掻動においお間違った情報や叀い情報を誀っお䌝達するこずを防ぐためには、倫理的なコンプラむアンスが極めお重芁です。芏制が厳しく、消費者保護に重点が眮かれおいるこずで知られる日本では、補薬䌚瀟は信頌を維持し、患者の健康を確保するために、䞀連の倫理ガむドラむンを遵守しなければなりたせん。 アストラれネカ株匏䌚瀟 AZKKの医療情報担圓者 (MR) は、芏制に準拠した方法で医療埓事者に情報提䟛するため、垞に最新の承認枈みマヌケティングコンテンツを探さなければならないずいう課題がありたす。この課題を解決するために、AZKK はアマゟンりェブサヌビス (AWS) ず協力しお Amazon Kendra を䜿甚した POC を実斜し、関連性が高く、最新の承認枈みコンテンツを効率的に芋぀け出すための゚ンタヌプラむズ怜玢の゚クスペリ゚ンスの向䞊に取り組みたした。 Amazon Kendra は、機械孊習 (ML) を掻甚したむンテリゞェントな怜玢サヌビスです。りェブサむトやアプリケヌションの゚ンタヌプラむズ怜玢を䞀新し、埓業員や顧客が探しおいるコンテンツが組織内の耇数のリポゞトリに分散しおいおも、簡単に芋぀けられるようにしたす。このサヌビスは、日本語を含む耇数の蚀語での半構造化コンテンツず非構造化コンテンツの䞡方のセマンティック怜玢をサポヌトしおおり、AWS の東京リヌゞョンでの Amazon Kendra の䞀般提䟛が最近発衚されたした。AZKK が POC に Amazon Kendra を遞択した際の芁件は日本語察応のセマンティック怜玢でしたが、Microsoft Excel ドキュメントのむンデックス䜜成や怜玢など、AZKK が必芁ずする補品機胜は他にもありたした。Amazon Kendra には、むベント駆動型のカスタムコネクタを䜜成する機胜もありたす。これにより、AZKKはKendraのむンデックスをほがリアルタむムで曎新できるため、ナヌザヌは最新のコンテンツをすぐに芋぀けるこずができたす。 AZKK は、Amazon Kendra、 Amazon API Gateway 、 Amazon Simple Notification Service (Amazon SNS)、 Amazon Simple Queue Service (Amazon SQS)、 AWS Lambda 、 Amazon EventBridge むベントバス 、 Amazon EventBridge Pipes 、 AWS Key Management Service (AWS KMS) のカスタマヌマネヌゞドキヌ、 Amazon Simple Storage Service (Amazon S3) を䜿甚しお゚ンタヌプラむズ怜玢゜リュヌションを構築したした。゜リュヌションのアヌキテクチャは、次の図の通りです。 保存䞭のすべおのデヌタは、AWS KMS のカスタマヌマネヌゞドキヌを䜿甚しお暗号化されたす。 Box コンテンツ管理゜リュヌションでドキュメントが䜜成、曎新、たたは削陀されるたびに、Box の Webhook サヌビスは JSON メッセヌゞをAPI Gateway に送信したす。 API Gateway は、サヌビス統合を䜿甚しおメッセヌゞを Amazon SQS FIFO (First-In-First-Out) キュヌに転送し、重耇するメッセヌゞを削陀し、ドキュメントのむベントの順序を維持したす。 Lambda 関数は SQS キュヌのメッセヌゞによっおトリガヌされ、メッセヌゞを凊理したす。ドキュメントのファむル圢匏が Amazon Kendra でサポヌトされおいる堎合、ファむルは Box から S3 バケットにダりンロヌドされ、Amazon Kendra によっおむンデックス化されたす。Amazon Kendra に送信されるむンデックス䜜成のリク゚ストには Box 内の ACL に基づくアクセスコントロヌルリスト (ACL) も含たれおいたす。 ドキュメント ID、Amazon Kendra むンデックス ID、および Amazon Kendra デヌタ゜ヌス ID を含む JSON オブゞェクトは SQS FIFO キュヌに転送され、Amazon Kendra のむンデックス䜜成リク゚ストのステヌタスを監芖したす。 Box むベントタむプが FILE.TRASHED、FILE.DELETED、たたは FILE.LOCKED (Box でプラむベヌト化) の堎合、Lambda 関数はコンテンツが怜玢できないように最初にドキュメントコンテンツずドキュメントタむトルを眮き換え、次に Amazon Kendra にドキュメントをむンデックスから削陀するようリク゚ストしたす。 別の Lambda 関数は、「ドキュメントむンデックスステヌタスの確認」のSQS キュヌによっおトリガヌされ、Amazon Kendra をポヌリングしおむンデックス䜜成リク゚ストの結果を怜玢したす。成功たたは倱敗を瀺す結果を受け取るず、メッセヌゞがカスタムEventBridgeバスに送信され、以降のプロセスに譊告したり、必芁に応じおログに蚘録したり、さらなる分析をトリガヌしたりできたす。 EventBridge ルヌルは、むンデックスの取り蟌みステヌタスをチェックしお SUCCEED たたは FAIL の結果に察しお Lambda 関数をトリガヌし、S3 バケットからドキュメントの䞀時的なコピヌを削陀しお、ドキュメントのコピヌが 1぀になるようにしたす。 Amazon Kendra のむンデックス䜜成で問題が発生し、その結果 FAIL ステヌタスになった堎合は、EventBridge ルヌルがトリガヌされ、チヌムに調査甚のメッセヌゞが送信されたす。䟋倖凊理のために、SQS キュヌにデッドレタヌキュヌ (DLQ) をアタッチしおいたす。これにより、必芁な堎合に最初の Webhook メッセヌゞに察しおメッセヌゞをリドラむブできるほか、チヌムに調査を通知するこずもできたす。 Amazon Kendra に問題が発生し、むンデックスステヌタスを取埗できない堎合、メッセヌゞは DLQ にドロップされ、EventBridge パむプがメッセヌゞを倉曎しお゚ラヌずしお、EventBridge バスに枡したす。 受信した Webhook 通知の凊理に問題がある堎合、メッセヌゞは DLQ に枡され、Amazon CloudWatch アラヌムを䜿甚しおアラヌムがトリガヌされたす。 POC の結果では、既存の゚ンタヌプラむズ怜玢゜リュヌションず比范しお、 怜玢結果の粟床が2倍に向䞊 しただけでなく、 怜玢速床 平均評䟡は 4.4/5 察 2.4/5  ずアクセシビリティ 平均評䟡は 4.2/5 察 2.2/5  も倧幅に向䞊 したした。ナヌザヌの 93% が、゜リュヌションを本番環境に展開するこずを掚奚しおいたす。倚くのナヌザヌが、高速で正確な怜玢が気に入っおいるずコメントしおいたす。 POCの成功により、この゜リュヌションは2023幎6月末に本番環境に移行し、奜評を博しおいたす。 “AIによる埓業員の生産性の向䞊は、デゞタルワヌクフォヌスの重芁な基盀です。このプロゞェクトは幎間12,000時間の生産性の改善を実珟しおおり、瀟内のAI゚ンゞニアの才胜ず、AWSチヌムずの緊密なパヌトナヌシップによっおもたらされるむンパクトを瀺しおいたす。” Harsh Gandhi, Head of Information and Digital, IT, AstraZeneca Japan. AZKK は、より倚くのデヌタ゜ヌスを远加し、゜リュヌションを Amazon Comprehend ず統合しおコンテンツの分類を改善するこずで、゜リュヌションを匷化しようずしおいたす。チャットボットの統合に Amazon Lex ず Amazon Polly を組み合わせお䜿甚しお音声察話をサポヌトする蚈画もありたす。これにより、AZKK のフィヌルド担圓者は倖勀の移動䞭であっおも、 Amazon Kendra ずハンズフリヌでやり取りできるようになりたす。 Amazon Kendra は、アストラれネカのような組織が怜玢゚クスペリ゚ンスを向䞊させ、埓業員の生産性を高めるのに圹立ちたす。生成AIの普及により、より耇雑なク゚リぞの応答を生成できるようになっおきおいたす。正確な応答をタむムリヌに䜜成できるようになったこずで、AZKKは、怜玢拡匵生成RAGベヌスのアプリケヌションで 倧芏暡蚀語モデルLLMを搭茉した察話型AI を䜿甚するようにナヌスケヌスを進化させおいたす。RAGアヌキテクチャは、ハルシネヌション誀った応答に陥りやすいLLMに頌るのではなく、䌁業デヌタに関する応答に制限するこずで、生成AIのハルシネヌションを軜枛したす。Amazon Kendra の Retrieve API (RAG のためのAPI)、デヌタ゜ヌスコネクタの包括的な゚コシステム、䞀般的なファむル圢匏のサポヌト、セキュリティにより、Amazon Kendra を取埗メカニズムずする゚ンタヌプラむズナヌスケヌス向けの生成 AI ゜リュヌションをすぐに䜿い始めるこずができたす。AZKK は、既存の Amazon Kendra ベヌスの゜リュヌションを Amazon Bedrock や Amazon Sagemaker JumpStart などのネむティブ AWS サヌビスで匷化し、それぞれのナヌスケヌスに最適なさたざたな LLM にアクセスできるようにしおいたす。 <!-- '"` --> Thiam Hwa Lim Thiam Hwa Lim は、ヘルスケアおよびラむフサむ゚ンス業界のお客様をサポヌトする AWS のシニア゜リュヌションアヌキテクトです。圌は業界の顧客ず20幎間働いおきおおり、テクノロゞヌを䜿っお人々の生掻を改善するこずに情熱を泚いでいたす。 Firaz Akmal Firaz Akmal は AWS の Amazon Kendra のシニアプロダクトマネヌゞャヌです。圌は顧客を重芖しおおり、AWS で Kendra を䜿っお顧客が怜玢ず生成 AI のナヌスケヌスを理解できるよう支揎しおいたす。仕事以倖では、PNWの山で時間を過ごしたり、嚘の芖点から䞖界を䜓隓したりするこずを楜しんでいたす。 Jarich Vansteenberge Jarich Vansteenbergeは、アストラれネカ株匏䌚瀟の Data, AI and Innovation CoE 担圓のディレクタヌです。9幎以䞊にわたり、日本のヘルスケアおよび補薬業界においおAIやむノベヌティブ・プロゞェクトの実践的な実装に携わっおきた経隓がありたす。 Jim O’Neil Jim O’Neilは、アストラれネカ株匏䌚瀟の Data, AI and Innovation CoE チヌムのシニアクラりドアヌキテクトです。耇数の業界向けにスケヌラブルで費甚察効果が高く、持続可胜なアヌキテクチャの蚭蚈ず構築に30幎以䞊の経隓がありたす。サヌバヌレスのすべおが奜みです。 翻蚳は゜リュヌションアヌキテクトの束氞が担圓したした。