TECH PLAY

AWS

AWS の技術ブログ

å…š3302ä»¶

このブログは “ Medical content creation in the age of generative AI ” を翻蚳したものです。 生成AI やトランスフォヌマヌを掻甚した倧芏暡蚀語モデルLLMが最近の倧きなニュヌスになっおいたす。これらのモデルは、質問ぞの回答、文章の芁玄、コヌドおよびテキストの生成においお優れた性胜を発揮しおいたす。珟圚、LLMは、芏制の厳しいヘルスケア・ラむフサむ゚ンス業界HCLSを含む䌁業においお実際の業務で䜿甚されるようになっおきたした。ナヌスケヌスずしは、医療情報の抜出や臚床蚘録の芁玄から、マヌケティングコンテンツの生成や医療に関する法務レビュヌ (Medical Legal Review, MLR) の自動化たで倚岐にわたりたす。このブログでは、LLMを䜿甚しお疟患啓発のためのマヌケティングコンテンツを䜜成する方法を玹介したす。 マヌケティングコンテンツは、ラむフサむ゚ンス䌁業のコミュニケヌション戊略における重芁な芁玠です。たた、科孊的な内容は正確であるず同時に、察象読者にずっお魅力的でなければならないため、非垞にバランスが必芁な䜜業でもありたす。マヌケティングコンテンツの䞻な目的は、特定の疟患に぀いおの認知を高め、可胜な治療法に関する知識を患者ず医療埓事者に広めるこずです。最新か぀正確な情報にアクセスするこずで、医療埓事者はより倚くの情報に基づいお患者の治療を遞択するこずができたす。しかし、医療情報を取り扱うコンテンツは機埮性が高いため、培底した法什遵守ず評䟡プロセスにより、倚数のレビュヌサむクルを経る必芁があるため、䜜成プロセスには長い時間がかかり数日から数週間たす。 高床なテキスト生成機胜を備えたLLMは、プロダクトマネヌゞャヌやメディカル゚キスパヌトによる執筆ずレビュヌを支揎するこずで、このプロセスを合理化できるでしょうか この質問に答えるために、AWS 生成 AI むノベヌションセンタヌは最近、メディカルコンテンツ生成のための AI アシスタントを開発したした。このシステムは Amazon Bedrock を䜿っお構築されおおり、LLM 機胜を掻甚しお、疟患啓発に圹立぀厳遞されたメディカルコンテンツを生成したす。このAIアシスタントにより、察象分野の専門家SME: Subject Matter Expertが生成プロセスをより现かく制埡できるようにしながら、党䜓の生成時間を数週間から数時間に効果的に短瞮できたす。たた、自動改蚂機胜により、ナヌザヌはむンタラクティブなフィヌドバックルヌプを介しおLLMず察話し、指瀺やコメントを盎接LLMに送信できたす。通垞、コンテンツの改蚂がプロセスの䞻なボトルネックであるため、これは特に重芁です。 医孊関連情報は患者の健康に倧きな圱響を䞎える可胜性があるため、コンテンツの生成には正確性の確保ずいう芁件に察応する必芁がありたす。このため、ファクトチェックずルヌル評䟡のためのガヌドレヌルが远加され、システムが匷化されおいたす。これらのモゞュヌルの目的は、生成されたテキストのファクトチェックず、事前に指定された芏則や芏制ずの敎合性を評䟡するこずです。これらの機胜により、LLM の基盀ずなる生成ロゞックの透明性ず制埡性が向䞊したす。 この投皿では、䞻にコンテンツ生成モゞュヌルず改蚂モゞュヌルに焊点を圓おお、実装の詳现ず蚭蚈の遞択肢に぀いお説明したす。ファクトチェックずルヌル評䟡には特別な察応が必芁であり、今埌の投皿で説明したす。 図1: AI アシスタントずそのさたざたなコンポヌネントの抂芁 アヌキテクチャ 党䜓的なアヌキテクチャずコンテンツ䜜成プロセスの䞻な手順を図 2 に瀺したす。この゜リュヌションは以䞋のサヌビスを䜿甚しお蚭蚈されおいたす。 Amazon Elastic Container Service (ECS) : Streamlit UI をデプロむしお実行 Amazon Lambda : 生成ロゞックを含むバック゚ンドコヌドを実行 Amazon Textract : ドキュメントの解析、テキスト、およびレむアりトの抜出 Amazon Bedrock : サポヌトされおいる LLM や゚ンベディングモデルずのやり取り Amazon Translate : コンテンツ翻蚳 Amazon Simple Storage Service (S3) : ドキュメントず凊理枈みデヌタのキャッシュ 図2: コンテンツ生成ステップ ワヌクフロヌは䞋蚘の通り。 ステップ1では、ナヌザヌが、䜜りたいマヌケティングコンテンツの抂芁をアップロヌド、および関連する参考論文を遞択したす。さらに瀟内ルヌルやガむドラむンの情報を登録したす。 ステップ 2 では、ナヌザヌは Streamlit UI を䜿甚しおシステムを操䜜したす。最初にドキュメントをアップロヌドし、次に察象読者ず蚀語を遞択したす。 ステップ 3 では、フロント゚ンドが WebSocket API ず API ゲヌトりェむ経由で HTTPS リク゚ストを送信し、最初の Amazon Lambda 関数をトリガヌしたす。 ステップ 5 では、Lambda 関数が Amazon Textract をトリガヌしお PDF ドキュメントからデヌタを解析および抜出したす。 抜出されたデヌタは S3 バケットに保存され、ステップ 6 ず 7 に瀺すように、プロンプトの LLM ぞの入力ずしお䜿甚されたす。 ステップ 8 では、Lambda 関数がコンテンツ生成、芁玄、およびコンテンツ改蚂のロゞックをリク゚ストしたす。 オプションで、ステップ9では、LLMによっお生成されたコンテンツを、Amazon Translateを䜿甚しお他の蚀語に翻蚳できたす。 最埌に、LLM は入力デヌタずプロンプトに基づいお新しいコンテンツを生成したす。Lambda 関数を介しおそれをりェブ゜ケットに送り返したす。 生成パむプラむンの入力デヌタの準備 正確なメディカルコンテンツを䜜成するために、LLMには、察象ずなる疟患に関連する遞別された医孊デヌタ医孊雑誌、蚘事、りェブサむトなどが登録されたす。これらの文献は、プロダクトマネヌゞャヌ、メディカル゚キスパヌト、および適切な医療専門知識を持぀その他の担圓者によっお遞択されたす。 むンプットには、生成されたコンテンツが埓うべき䞀般的な芁件ずルヌルトヌン、スタむル、察象読者、単語数などを説明する抂芁も含たれたす。埓来のマヌケティングコンテンツ生成プロセスでは、この抂芁は通垞、コンテンツ䜜成業者に共有されたす。 たた、医療情報のプラむバシヌずセキュリティを保護するためのHIPAAプラむバシヌガむドラむンなど、より粟緻な芏則や芏制を統合するこずもできたす。さらに、これらの芏則は、䞀般的で普遍的に適甚できる堎合もあれば、特定のケヌスに固有の堎合もありたす。たずえば、䞀郚の芏制芁件は、䞀郚のマヌケット/地域たたは特定の疟患に適甚される堎合がありたす。今回の生成システムでは高床なパヌ゜ナラむズが可胜なため、入力デヌタを調敎するだけで、コンテンツを新しい蚭定に合わせお簡単に調敎および個別化が可胜です。 コンテンツは、患者たたは医療埓事者のいずれかを察象ずする読者に適合させる必芁がありたす。実際、内容のトヌン、スタむル、科孊的な耇雑さを、読者の持っおいる医孊知識にに応じお遞択する必芁がありたす。コンテンツのパヌ゜ナラむズは、地域チヌム間の盞乗効果ず効率の向䞊に぀ながるため、グロヌバルで業務を行うラむフサむ゚ンス䌁業にずっお非垞に重芁です。 システム蚭蚈の芳点からは、厳遞された蚘事や医孊論文を倧量に凊理する必芁があるかもしれたせん。これは、知りたい疟患が高床な医孊知識を必芁ずする堎合や、より新しい論文情報などに䟝存しおいる堎合に特に圓おはたりたす。さらに、参考文献には、プレヌンテキストたたはより耇雑な画像で構成されたさたざたな情報が含たれおおり、泚釈や衚が埋め蟌たれおいたす。システムを拡匵するには、この情報をシヌムレスに解析、抜出、保存するこずが重芁です。この目的のために、゚ンティティの認識ず抜出のための機械孊習 (ML) サヌビスである Amazon Textract を䜿甚しおいたす。 入力デヌタが凊理されるず、API 呌び出しを通じおコンテキスト情報ずしお LLM に送信されたす。 Anthropic Claude 3 のコンテキストりィンドりは200,000トヌクンにもなるため、オリゞナルの医孊コヌパスをそのたた䜿甚しお生成されるコンテンツの品質を向䞊させるかただし、レむテンシヌは倧きくなりたす、生成パむプラむンで䜿甚する前に参考文献を芁玄するかを遞択できたす。 医孊文献の芁玄は、党䜓的なパフォヌマンスを最適化する䞊で䞍可欠なステップであり、LLMの芁玄機胜を掻甚するこずで実珟されたす。このシステムではプロンプト゚ンゞニアリングを䜿甚しお芁玄の指瀺をLLMに送信したす。重芁なのは、芁玄を実行する堎合、タむトル、著者、日付など、蚘事のメタデヌタをできるだけ倚く保存する必芁があるずいうこずです。 図3: 簡略版の芁玄プロンプト 生成パむプラむンを開始するには、ナヌザヌは入力デヌタを UI にアップロヌドしたす。これにより Textract がトリガヌされ、オプションで芁玄 Lambda 関数がトリガヌされ、完了時に凊理されたデヌタが S3 バケットに曞き蟌たれたす。埌続の Lambda 関数は入力デヌタを S3 から盎接読み取るこずができたす。S3 からデヌタを読み取るこずで、倧きなペむロヌドを凊理する際に Websocket で通垞発生するスロットリング問題を回避できたす。 図4: コンテンツ生成パむプラむンの抂芁 コンテンツ生成 この゜リュヌションは䞻に、Bedrock LLMずのやり取りにおけるプロンプト゚ンゞニアリングが重芁な圹割を担っおいたす。すべおのむンプット文献、抂芁、ルヌルは、LangChain PrompteTemplateオブゞェクトを介しおLLMにパラメヌタヌずしお提䟛されたす。匕甚スタむルなどをフュヌショットの入力ずしおLLMに察しお提䟛したす。パラメヌタ効率の高いファむンチュヌニングの手法は、LLMを医療知識にさらに特化させるこずができ、埌の段階で怜蚎する予定です。 図5: 簡略版のコンテンツ生成プロンプト 私たちのパむプラむンは、さたざたな蚀語でコンテンツを生成できるずいう意味で倚蚀語です。たずえば、Claude 3は英語以倖にも数十皮類の蚀語でトレヌニングされおおり、それらの蚀語間でコンテンツを翻蚳するこずができたす。ただし、タヌゲット蚀語が耇雑なため、特殊なツヌルが必芁な堎合もあるこずを認識しおいたす。その堎合は、Amazon Translate を䜿甚しお远加の翻蚳手順を実行する必芁がありたす。 図6: ゚ヌラス・ダンロス症候矀の原因、症状、合䜵症に関する蚘事の生成を瀺す動画 コンテンツ改蚂 文曞の改蚂は、LLMにフィヌドバックを繰り返し求めるこずで、生成されたコンテンツをさらに調敎できるようになるため、この゜リュヌションにおける重芁な機胜です。この゜リュヌションは䞻にアシスタントずしお蚭蚈されおいるため、これらのフィヌドバックルヌプにより、既存のプロセスずシヌムレスに統合でき、専門家が正確なメディカルコンテンツを蚭蚈する際に効果的に支揎できたす。たずえば、ナヌザヌは、以前のバヌゞョンではLLMで完党には適甚されおいなかったルヌルを適甚したり、䞀郚のセクションの明確さず正確さを向䞊させたりするこずができたす。文曞の改蚂はテキスト党䜓に適甚できたす。たたは、ナヌザヌは個々の段萜を修正するこずを遞択できたす。いずれの堎合も、改蚂版ずフィヌドバックは新しいプロンプトに远加され、LLM に送信されお凊理されたす。 図7: 簡略版のコンテンツ改蚂プロンプト LLM に指瀺を送信するず、Lambda 関数は曎新されたプロンプトで新しいコンテンツ生成プロセスをトリガヌしたす。党䜓的な構文の䞀貫性を保぀には、他の段萜はそのたたにしお、蚘事党䜓を再生成するこずが望たしいです。ただし、フィヌドバックが提䟛されたセクションのみを再生成するこずで、プロセスを改善できたす。この堎合、テキストの䞀貫性に適切な泚意を払う必芁がありたす。この改蚂プロセスは、コンテンツがナヌザヌに満足のいくものであるず刀断されるたで、以前のバヌゞョンを改善するこずで再垰的に適甚できたす。 図8: ゚ヌラス・ダンロス症候矀の文献の改蚂を瀺す動画で、䟋えばナヌザは远加情報を芁求できる 結論 LLMで生成されたテキストの品質が最近向䞊したこずで、生成AIは、幅広いプロセスやビゞネスを合理化および最適化する可胜性を秘めた倉革的なテクノロゞヌになりたした。 疟患啓発のためのメディカルコンテンツの生成は、LLMを掻甚しお厳遞された質の高いマヌケティングコンテンツを数週間ではなく数時間で䜜成する方法を瀺す重芁な䟋です。これにより、オペレヌションが倧幅に改善され、地域チヌム間の盞乗効果が高たりたす。改蚂機胜により、この゜リュヌションは既存の埓来のプロセスずシヌムレスに統合でき、メディカル゚キスパヌトやプロダクトマネヌゞャヌを支揎する真のアシスタントツヌルずなりたす。 疟患啓発のためのマヌケティングコンテンツは、生成されるコンテンツの正確性が極めお重芁な、芏制の厳しいナヌスケヌスの䟋でもありたす。専門家がハルシネヌションや誀った蚘述の可胜性を怜出しお蚂正できるように、生成されたテキストに出兞文献を明蚘するこずで朜圚的なずれを怜出するこずを目的ずしたファクトチェックモゞュヌルを蚭蚈したした。 さらに、ルヌル評䟡機胜は、ルヌルや芏制の䞍適切な衚珟を自動的に匷調衚瀺するこずで、専門家のMLRプロセスに圹立ちたす。これらの補完的なガヌドレヌルにより、生成パむプラむンのスケヌラビリティず堅牢性の䞡方を確保し、その結果、業務に実装可胜な安党で責任あるAIの導入を実珟しおいたす。 参考文献 Vaswani, Ashish, et al. “Attention is all you need.” Advances in neural information processing systems 30 (2017). Brown, Tom, et al. “Language models are few-shot learners.” Advances in neural information processing systems 33 (2020): 1877-1901. Meskó, Bertalan, and Eric J. Topol. “The imperative for regulatory oversight of large language models (or generative AI) in healthcare.” NPJ digital medicine 1 (2023): 120. Clusmann, Jan, et al. “The future landscape of large language models in medicine.” Communications medicine 1 (2023): 141. He, Kai, et al. “A survey of large language models for healthcare: from data, technology, and applications to accountability and ethics.” arXiv preprint arXiv:2310.05694 (2023). Mu, Weiyi, et al. “Factors affecting quality of life in children and adolescents with hypermobile Ehlers‐Danlos syndrome/hypermobility spectrum disorders.” American journal of medical genetics Part A 179.4 (2019): 561-569. Berglund, Britta, Gun Nordström, and Kim LÃŒtzén. “Living a restricted life with Ehlers-Danlos syndrome (EDS).” International Journal of Nursing Studies 37.2 (2000): 111-118. 著者 Sarah Boufelja Y. デヌタサむ゚ンスず機械孊習の分野で8幎以䞊の経隓を持぀シニアデヌタサむ゚ンティストです。GenAIIセンタヌでの職務では、機械孊習ず生成AIのツヌルを䜿甚しお、䞻芁な関係者ず協力しおビゞネス䞊の問題に察凊したした。圌女の専門分野は、機械孊習、確率論、最適茞送の融合にありたす。 Liza (Elizaveta) Zinovyeva AWS 生成AI むノベヌションセンタヌの応甚科孊者で、ベルリンを拠点ずしおいたす。圌女は、さたざたな業界のお客様が生成AIを既存のアプリケヌションやワヌクフロヌに統合できるよう支揎しおいたす。圌女はAI/ML、金融、゜フトりェアセキュリティのトピックに情熱を泚いでいたす。䜙暇には、家族ず過ごしたり、スポヌツをしたり、新しいテクノロゞヌを孊んだり、テヌブルクむズを楜しんだりしおいたす。 Nikita Kozodoi AWS 生成AI むノベヌションセンタヌの応甚科孊者で、さたざたな業界のお客様の珟実䞖界のビゞネス問題を解決するための生成AI ず ML ゜リュヌションの構築ず開発を行っおいたす。䜙暇には、ビヌチバレヌボヌルをするのが倧奜きです。 Marion Eigner 耇数の生成AI゜リュヌションの立ち䞊げを䞻導しおきた生成AIストラテゞストです。゚ンタヌプラむズ・トランスフォヌメヌションずプロダクト・むノベヌションに関する専門知識を持぀圌女は、生成AIを掻甚した新しい補品やサヌビスの迅速なプロトタむプ䜜成、䞊垂、拡匵を䌁業を支揎するこずを専門ずしおいたす。 Nuno Castro AWS 生成AI むノベヌションセンタヌのシニア応甚科孊マネヌゞャヌです。生成AIカスタマヌ゚ンゲヌゞメントを率い、AWSのお客様がアむディ゚ヌション、プロトタむプ、プロダクションに至るたで、最もむンパクトのあるナヌスケヌスを芋぀けられるよう支揎しおいたす。金融、補造、旅行などの業界で17幎の経隓があり、10幎間MLチヌムを率いおきたした。 Aiham Taleb , PhD 生成AIむノベヌションセンタヌの応甚科孊者であり、AWSの䌁業顧客ず盎接連携しお、圱響の倧きいいく぀かのナヌスケヌスで生成AIを掻甚しおいたす。Aihamは教垫なし衚珟孊習の博士号を持ち、コンピュヌタヌビゞョン、自然蚀語凊理、医療画像凊理など、さたざたな機械孊習アプリケヌションにたたがる業界経隓がありたす。   このブログは Senior Solutions Architect, HCLS の束氞ず Senior Business Development Manager の亀田が翻蚳したした。
倚くの基幹系アプリケヌションが珟圚もメむンフレヌム䞊で皌働しおいたすが、急激に倉化するビゞネス環境に察応するべく、そのモダナむれヌションを図りたいず考えるお客様が増えおいたす。 AWS Mainframe Modernization は、メむンフレヌム䞊のアプリケヌションをAWSに移行し、皌働し、モダナむズするためのツヌルずマネヌゞドサヌビスの集たりです。その䞭の AWS Blu Age は、アプリケヌションの構造や゜ヌスコヌドの䟝存関係を分析し、リファクタリングするこずで、クラりド䞊で皌働するJavaコヌドに自動倉換したす。 メむンフレヌム䞊のワヌクロヌドを AWS に移行するずき、プログラムやデヌタの移行だけでなく、倚くの堎合バッチゞョブの運甚も怜蚎する必芁がありたす。 このブログでは、ゞョブスケゞュヌラヌの䟋ずしお A-AUTO を取り䞊げ、AWS Blu Age でリファクタリングしたアプリケヌションのバッチゞョブをスケゞュヌリングし自動実行する方法を玹介したす。 泚意 : AWS Blu Age ず A-AUTO の連携は動䜜確認枈であり、本ブログの蚘述はその確認結果に基づいおいたす。ただし、AWS Blu Age でリファクタリングしたバッチゞョブの実行は、ゞョブスケゞュヌラヌの実装から䞭立であり、特定のゞョブスケゞュヌラヌ補品に䟝存するものではありたせん。たた、䞊述の連携の動䜜をサポヌトもしくは保蚌するものではありたせん。 バッチゞョブ運甚の移行に関する課題ず゜リュヌション State Farm Insurance 瀟のブログ には、メむンフレヌムから AWS ぞのリプラットフォヌムに際しお埗られた教蚓の䞀぀ずしお、プラットフォヌム間の違いを極小化するため単䞀のゞョブでは無くゞョブフロヌの単䜍で移行する、ずいう蚘述がありたす。䟋えば、バッチゞョブが異垞終了したずきのリカバリヌやリランは、ゞョブフロヌの単䜍で怜蚎し手順化しおおく必芁がありたす。個々のプラットフォヌムに適した方法でリカバリヌやリランの方法を実珟し぀぀、業務的には埓来ず同様に凊理できるのが望たしいず考えられたす。 クラりド移行によりバッチゞョブ運甚の俊敏性を向䞊したい堎合は、 オンプレミス環境のバッチゞョブフロヌの AWS 移行方法怜蚎事䟋 に瀺されるように、AWS Step Functions によりクラりドネむティブなゞョブ運甚を実装するアプロヌチが参考になりたす。 䞀方で、バッチゞョブの運甚が業務的な運甚ず密接に連動しおおり、運甚を倉えたくない堎合は、AWS 環境で皌働するゞョブスケゞュヌラヌによる自動化が珟実的な遞択肢の䞀぀ずなりたす。 AWS Blu Age によるアプリケヌションの自動リファクタリング AWS Blu Age は、メむンフレヌムやオフコンのモノリシックなレガシヌコヌドを自動的にリファクタリングし、モダンなアプリケヌションを生成したす。COBOL や PL/I、4GL (RPG や Natural 等) を、Spring Framework ベヌスの Java コヌドに倉換し、JCL を Groovy スクリプトに倉換したす。BMS ゜ヌスから Angular ベヌスのコヌドを生成し、画面のレむアりトずファンクションキヌの操䜜を再珟したす。この過皋で、Db2 for z/OS や Db2 for IBM i, IMS/DB, VSAM に察する入出力は、Amazon Aurora, Amazon Releational Database Service (Amazon RDS) for PostgreSQL, Oracle, IBM Db2 等のデヌタベヌスに察する入出力に倉換されたす。 AWS Blu Age の自動リファクタリングにより、元のレガシヌコヌドの機胜をクラりド䞊で再珟するこずができたす。移行埌のバッチゞョブは、AWS Command Line Interface (AWS CLI) もしくは RESTful API で起動するこずができたす。手䜜業によるリラむトず比范するず、メむンフレヌムアプリケヌションに察する倉曎を最小限に抑え぀぀、918 ヶ月でモダンな Java アプリケヌションにリファクタリングするこずが可胜です。 ゞョブスケゞュヌラヌの䟋: A-AUTO A-AUTO は、IT システム䞊での業務凊理のゞョブスケゞュヌリング等の自動化を支揎する総合的な運甚管理ツヌルです。分散コンピュヌティング環境に察応した A-AUTO for UNIX / Windows は Amazon Elastic Compute Cloud (Amazon EC2) 䞊での皌働をサポヌトし、AWS 䞊で実行するバッチゞョブのスケゞュヌリングを実珟したす。 ゞョブスケゞュヌラヌず AWS Blu Age の連携によっお埗られる効果 AWS Blu Age によっおメむンフレヌムから AWS 䞊に移行したワヌクロヌドを、ゞョブスケゞュヌラヌず連携しお運甚するこずにより、いく぀かの効果が期埅できたす。 バッチゞョブの集䞭管理: ゞョブスケゞュヌラヌの機胜により、バッチゞョブの運甚に関わる日次・週次・月次のスケゞュヌルを予め蚭定しおおき、そのスケゞュヌルに埓っお自動的に実行するこずができたす。デヌタの到着をゞョブの実行トリガヌにするこずも可胜です。耇数のゞョブの先行/埌続の関係をゞョブネットワヌクずしお定矩し、管理するこずもできたす。 バッチゞョブ実行状況のリアルタむム監芖: ゞョブスケゞュヌラヌの機胜により、バッチゞョブおよびゞョブネットワヌクの実行状況をリアルタむムでモニタリングするこずができたす。 自動フェヌルオヌバヌ: 高可甚性および灜害察策の芁件に応じお、ゞョブスケゞュヌラヌおよび AWS Blu Age のアヌキテクチャを適切に構成するこずにより、障害発生時の自動フェヌルオヌバヌが可胜です。 既存コンピュヌティング環境で皌働するゞョブずの連携: AWS Blu Age をゞョブスケゞュヌラヌず組み合わせるこずにより、アプリケヌションずバッチゞョブ運甚を合わせおメむンフレヌムから AWS クラりドに移行し、既存の分散コンピュヌティング環境ずのゞョブ連携を維持し拡匵するこずができたす。 ゜リュヌション抂芁 A-AUTO ず AWS Blu Age はシングル構成での運甚も可胜ですが、ミッションクリティカルなワヌクロヌドの皌働をサポヌトするべく、高可甚性構成に察応しおいたす。 マルチ AZ 高可甚性アヌキテクチャ構成䟋 図 1. A-AUTO ず AWS Blu Age のマルチ AZ 高可甚性アヌキテクチャ 皌働系の EC2 むンスタンス①䞊で A-AUTO Server ず A-AUTO モニタヌが皌働したす。AUTO モニタヌは、AWS Blu Age ⑊に察しお、バッチゞョブの実行を指瀺し、ゞョブのステヌタスをモニタリングしたす。 皌働系の EC2 むンスタンス①ず埅機系の EC2 むンスタンス②はサむオステクノロゞヌ株匏䌚瀟の LifeKeeper ③によっお HA クラスタヌを構成したす。HA クラスタヌの仮想 IP アドレスで EC2 むンスタンスにアクセスするため、フェヌルオヌバヌが発生しおも A-AUTO クラむアントからのアクセスは圱響を受けたせん。 サむオステクノロゞヌ株匏䌚瀟の DataKeeper ⑥は、皌働系の Amazon Elastic Block Store (Amazon EBS) ボリュヌム④を埅機系の EBS ボリュヌム⑀にミラヌリングし、ロゞカル共有ディスクを構成したす。この構成䟋では DataKeeper を䜿いたしたが、利甚するゞョブスケゞュヌラヌ補品がサポヌトする他のクラスタリング゜リュヌションによる構成も可胜です。 AUTO モニタヌは、AWS Blu Age ⑊に察しお、バッチゞョブの実行を指瀺し、ゞョブのステヌタスをモニタリングしたす。 この堎合の RPO ず RTO は以䞋のようになりたす。 RPO: DataKeeper によるミラヌリングのタむムラグ(同期ミラヌリングの堎合の RPO はれロ) RTO: 皌働系 EC2 むンスタンスから埅機系 EC2 むンスタンスぞのフェヌルオヌバヌの蚭定倀(LifeKeeper のハヌトビヌト間隔×連続倱敗回数) 動䜜確認結果抂芁 今回の動䜜確認により、A-AUTO によるゞョブスケゞュヌリングが AWS Mainframe Modernization サヌビスず正垞に連携し、AWS Blu Age によっおリファクタリングしたレガシヌアプリケヌションのバッチゞョブを運甚できるこずが実蚌されたした。 EC2 むンスタンス䞊の Windows Server で皌働する A-AUTO にゞョブネットワヌク AUTO01 を登録し、実行したした。ゞョブネットワヌク AUTO01 は、AWS Blu Age 䞊のメむンフレヌムサンプルアプリケヌション CardDemo のバッチゞョブで構成され、以䞋の図のような構造になっおいたす。 図 2. AWS Mainframe Modernization サヌビスにデプロむした CardDemo アプリケヌションのアヌキテクチャ 図 3. ゞョブネットワヌク AUTO01 の構造 このゞョブネットワヌクは、3 ぀のバッチゞョブ: SORTTEST, LISTCAT, DUSRSECJ で構成されおいたす。各バッチゞョブの実䜓は共通のスクリプト M2JOB です。スクリプト M2JOB 内で AWS Mainframe Modernization サヌビスの API を呌び出す AWS CLI コマンドを発行し、バッチゞョブの実行を制埡したす。䟋えば、バッチゞョブの実行は、aws m2 start-batch-job コマンドで開始したす。 JCL を倉換した結果である Groovy スクリプトは、M2JOB の実行時パラメヌタずしお匕き枡したす。䟋えば、先頭のバッチゞョブ @M2JOB01 の定矩は以䞋のようになっおおり、ゞョブコヌド M2JOB に察しお、Groovy スクリプト SORTTEST.jcl.groovy が匕き枡されおいるこずがわかりたす。 図 4. バッチゞョブ @M2JOB01 の定矩 ゞョブネットワヌク AUTO01 の手動実行 図 5. ゞョブネットワヌク AUTO01 の実行開始操䜜 ゞョブネットワヌク AUTO01 の先頭のバッチゞョブ @M2JOB01 にホヌルド属性を蚭定しおあるため、初期状態ではキュヌむング枈みずいうステヌタスになりたす。@M2JOB01 を右クリックしおリリヌスするこずにより、その実行を手動で開始するこずができたす(①→②→③)。するず、バッチゞョブ @M2JOB01 が実行䞭になったこずが芖芚的にわかりたす(④)。 このずき、ゞョブネットワヌク AUTO01 の状態を衚瀺するず、ステヌタスは「キュヌむング枈み」から「実行䞭」に倉わっおいたす。 図 6. 実行䞭のゞョブネットワヌク AUTO01 の状態 実行䞭ステヌタスになったバッチゞョブ @M2JOB01 の詳现は以䞋のように確認するこずができたす。 図 7. 実行䞭のバッチゞョブ @M2JOB01 の詳现 バッチゞョブ @M2JOB01 の詳现画面で[ゞョブログ衚瀺]を抌すず(①)、その時点でのゞョブログが衚瀺されたす(②)。実行開始時に䞀意に発番される execution ID が確認でき(③)、実行開始日時ずステヌタス Running が衚瀺されたす。 ゞョブネットワヌク AUTO01 の各バッチゞョブの実行状態の掚移は、以䞋の図のように芖芚的に衚瀺されたす。実行䞭のバッチゞョブは緑色で衚瀺され、正垞終了するず青色に倉化したす。党おのバッチゞョブが青色になったこずで、このゞョブネットワヌク党䜓が正垞終了したこずがわかりたす。 図 8. ゞョブネットワヌク AUTO01 の実行状態の掚移 AWS Blu Age バッチゞョブの実行状態照䌚 以䞊から、A-AUTO の管理機胜により、AWS Blu Age のバッチゞョブの実行を䞀元的に管理できるこずがわかったず思いたす。䞀連の凊理は、AWS マネゞメントコン゜ヌルを操䜜せずに実行できたした。 䞀方で、同じバッチゞョブの実行状況を AWS マネゞメントコン゜ヌルで芋おも䞀貫性ある結果になっおいるこずを芋おみたしょう。以䞋の操䜜は、技術的な理解を深めお頂くための参考情報であり、通垞のゞョブ運甚で必芁なものではありたせん。 AWS マネゞメントコン゜ヌルで AWS Mainframe Modernization のアプリケヌションを遞ぶず、AWS Blu Age の CardDemo アプリケヌションが䞀芧に衚瀺されおいたす。 図 9. AWS Mainframe Modernization アプリケヌション 䞀芧の card-demo-app をクリックし、[バッチゞョブ]タブを遞ぶず、実行したバッチゞョブの䞀芧が衚瀺されたす。[ゞョブ名]欄の衚瀺から、A-AUTO で実行したバッチゞョブ DUSRSECJ, LISTCAT, SORTTEST を識別するこずができたす。 図 10. CardDemo アプリケヌションのバッチゞョブ䞀芧 この䞭で、䞊から 3 行目のバッチゞョブ SORTTEST をクリックするず、その詳现が以䞋のように衚瀺されたす。 図 11. CardDemo アプリケヌションのバッチゞョブ SORTTEST の詳现 リタヌンコヌドが 0 であるこずから、このバッチゞョブが正垞終了したこずがわかりたす。 実行 ID により、この実行を䞀意に識別するこずができたす。 このバッチゞョブの凊理内容は、䞋方に衚瀺されおいるスクリプト SORTTEST.jcl.groovy に蚘述されおいたす。A-AUTO の「図 4 バッチゞョブ @M2JOB01 の定矩」でパラメヌタに指定したのは、このスクリプト名でした。 Amazon CloudWatch Logs によるバッチゞョブの実行状態照䌚 CloudWatch Logs のロググルヌプで、AWS Blu Age のコン゜ヌルログを照䌚するこずができたす。 図 12. CloudWatch Logs のロググルヌプ䞀芧䞊の AWS Blu Age コン゜ヌルログ AWS Blu Age コン゜ヌルログのロググルヌプをクリックするず、その詳现が衚瀺されたす。 図 13. AWS Blu Age コン゜ヌルログのロググルヌプ詳现 ログストリヌムをクリックするず、その内容が以䞋のように衚瀺されたす。各セクションをクリックしお展開するず、コン゜ヌルに出力されたメッセヌゞが衚瀺されたす。この画面のマりスカヌ゜ル䜍眮に、AWS Blu Age ゞョブ SORTTEST の開始時に出力されたメッセヌゞが衚瀺されおいたす。 図 14. ログストリヌムの詳现衚瀺 おわりに メむンフレヌム䞊のワヌクロヌドを AWS Blu Age による自動リファクタリングで AWS クラりドに移行する際に、AWS クラりド䞊で皌働するゞョブスケゞュヌラヌず連携しお AWS Blu Age バッチゞョブが動䜜可胜であるこずが、今回確認できたした。珟行のバッチプログラムを AWS に移行するずき、珟行のバッチゞョブ運甚を螏襲しお運甚するこずが可胜です。曎に、芁件に応じた高可甚性構成での運甚も可胜ずなりたす。 AWS Mainframe Modernization に関するご盞談は、担圓営業にご連絡頂くか、もしくは公匏サむトの Web フォヌム でお問い合わせください。 著者 皆川 元 フィナンシャルサヌビスむンダストリ技術本郚 ゚マヌゞング゜リュヌション郚 ゜リュヌションアヌキテクト
このブログは 2024 幎 4 月 23 日に Jenna Leiner によっお執筆された内容を翻蚳したものです。原文は こちら を参照しお䞋さい。 䞖界のデゞタル化が進むに぀れ、䌁業はデゞタルトランスフォヌメヌションを掚進するために電力を倧量に消費する IT むンフラストラクチャず、環境の持続可胜性を䞡立させる耇雑な課題に盎面しおいたす。このような盞反する芁求により、デヌタセンタヌの゚ネルギヌ消費ず炭玠排出が倧きな泚目を集めおいたす。 IDC InfoBrief 報告曞「 Energy and Carbon Efficiency Benefits of Public Cloud Computing over Enterprise Datacenters , 1 」によるず、2023 幎の時点でパブリッククラりドデヌタセンタヌぱンタヌプラむズデヌタセンタヌよりも 3.8 倍゚ネルギヌ効率が高いず掚定されおいたす。情報技術、通信、コンシュヌマヌ技術垂堎における垂堎むンテリゞェンス、アドバむザリヌサヌビス、むベントの䞻芁グロヌバルプロバむダヌである IDC は、2023 幎のパブリッククラりドデヌタセンタヌの電力䜿甚効率 (PUE) が 1.22 だったのに察し、゚ンタヌプラむズデヌタセンタヌは 1.84 であったず掚定しおいたす。IDC の調査によるず、2023 幎のパブリッククラりドデヌタセンタヌは、゚ンタヌプラむズデヌタセンタヌよりも 4.7 倍炭玠効率が高かったず掚定され、この差は 2027 幎たでに 7 倍に広がるず予想されおいたす。その結果、IDC は 2027 幎たでにパブリッククラりド利甚による炭玠削枛量が、米囜で 2100 䞇台の自動車を道路から排陀したのず同等になるず掚定しおいたす。IDC は、炭玠䜿甚効率 (CUE) をデヌタセンタヌの運営に関連する炭玠排出量を枬定するために䜿甚される指暙ずしお定矩しおいたす。これは、゚ネルギヌ消費ず炭玠排出を盎接関係付けるため、デヌタセンタヌの環境ぞの圱響を評䟡するのに特に圹立ちたす。 IDC によるず、この炭玠効率化を掚進する䞻な芁因はいく぀かありたす。 カヌボンフリヌな゚ネルギヌ源 : クラりドプロバむダヌはカヌボンフリヌな゚ネルギヌに倧芏暡な投資を行っおいたす。IDC によるず、倪陜光、颚力、原子力、氎力発電などのカヌボンフリヌな゚ネルギヌ源によるパブリッククラりドの゚ネルギヌ消費の割合が、2023 幎の 61% から 2027 幎には 74% に増加するず掚定されおいたす。 より効率的なハヌドりェアず斜蚭 : クラりドデヌタセンタヌは、最初から゚ネルギヌ効率を考慮しお蚭蚈されおおり、高床な冷华システム、最適化されたサヌバヌレむアりト、スマヌトビルディングテクノロゞヌを掻甚しおいたす。たた、芏暡の経枈から効率投資に察するより倧きな収益を埗るこずができたす 利甚率の改善 : クラりドプロバむダヌは、仮想化ずコンテナ化によっおむンフラストラクチャの利甚率を最倧化し、コンピュヌティングリ゜ヌスをより効率的に䜿甚できるようにしおいたす。䞀方、゚ンタヌプラむズデヌタセンタヌでは利甚率が䜎い傟向にありたす。 より゚ネルギヌ効率の高いシリコン : クラりドプロバむダヌは、AI、機械孊習、高性胜コンピュヌティングなど特定のワヌクロヌドに特化したカスタムの゚ネルギヌ効率の高いシリコンチップの開発に投資しおいたす。これらのチップは、より䜎い電力消費で高い性胜を発揮するように蚭蚈されおおり、パブリッククラりドデヌタセンタヌの党䜓的な゚ネルギヌ芁求を倧幅に削枛したす。 クラりドの炭玠削枛機䌚は、単に運甚䞊の排出量だけに留たりたせん。IDC の調査によるず、パブリッククラりドデヌタセンタヌを利甚するず、゚ンタヌプラむズデヌタセンタヌず比范しお、幎間 34 〜 37% の゚ンボディドカヌボンが少なくなるこずがわかりたした。デヌタセンタヌに関連する゚ンボディドカヌボンずは、デヌタセンタヌの建蚭やハヌドりェアの補造に䌎う間接的な排出量のこずです。デヌタセンタヌの゚ンボディドカヌボンの䞀぀の源泉はサヌバヌむンフラストラクチャです。IDC は、パブリッククラりドデヌタセンタヌではサヌバヌが効率的に利甚されおいるため、同じタスクを実行するのに必芁なサヌバヌ数が少なくお枈むず結論付けたした。これにより、サヌバヌの補造ず茞送に䌎う゚ンボディドカヌボンが削枛されたす。IDC は、2027 幎だけでパブリッククラりドサヌビスを利甚するこずで、28 メガ二酞化炭玠換算トン (28 MMTCO2e) の゚ンボディドカヌボンが削枛できる可胜性があるず算出しおおり、これは 600 䞇台以䞊の自動車を道路から排陀するこずに盞圓したす。 パブリッククラりドデヌタセンタヌの゚ネルギヌず炭玠効率の利点により、IDC は生成型人工知胜 (生成 AI) ワヌクロヌドをパブリッククラりドデヌタセンタヌで実行する方が、゚ンタヌプラむズデヌタセンタヌで実行するよりも゚ネルギヌず炭玠効率が高いず掚定しおいたす。生成 AI は倧量に゚ネルギヌを消費する可胜性がありたすが、このレポヌトでは生成 AI の持続可胜性の利点が抂説されおいたす。 生成 AI における最も゚ネルギヌを消費するトレヌニングは、レむテンシヌに䟝存したせん。぀たり、トレヌニングのワヌクロヌドは、電力が利甚可胜な堎所、特に䜎炭玠たたはカヌボンフリヌの電力源がある堎所に配眮できたす。 䞀般に、お客様は第䞉者のデヌタセンタヌを利甚するこずを予定しおいたす。これらのデヌタセンタヌはより゚ネルギヌ効率が高く、カヌボンフリヌの電源を䜿甚する可胜性が高くなりたす。 このレポヌトでは、デヌタセンタヌポヌトフォリオの環境持続可胜性の向䞊を目指す䌁業リヌダヌに察しお、いく぀かの重芁なヒントをたずめおいたす。 珟圚のカヌボンフットプリントを評䟡 : たずは既存の IT むンフラストラクチャの゚ネルギヌ消費ず炭玠排出を把握するこずから始めたす。経営陣は、サステナビリティ戊略を支揎し、゚ネルギヌず炭玠効率の恩恵を埗るために、どのワヌクロヌドをパブリッククラりドに移行すべきかを怜蚎する必芁がありたす。 適切なパブリッククラりドプロバむダヌを遞択 : あなたの䟡倀芳ず持続可胜性の目暙に合臎し、ニヌズに適した関連゜リュヌションを提䟛するプロバむダヌを遞びたす。さらに、デヌタセンタヌポヌトフォリオの環境持続可胜性だけでなく、環境、瀟䌚、ガバナンス (ESG) にも泚目したす。ESG ぱネルギヌ消費ず炭玠排出だけにずどたりたせん。あなたの䟡倀芳に合臎した匷力な瀟䌚的およびガバナンス実践を持぀パブリッククラりドプロバむダヌを遞択しおください。 デヌタセンタヌの立地を考慮 : 党䜓的なグリッドの発電構成ずカヌボンフリヌ゚ネルギヌの利甚可胜性が、環境ぞの圱響に圱響を䞎える可胜性がありたす。寒冷地のデヌタセンタヌでは、冷华システムの゚ネルギヌ需芁を削枛できたす。 CloudOps ツヌルを䜿甚しおベストプラクティスを実装 : CloudOps ツヌルず実践は、サヌバヌ利甚率ずワヌクロヌドを最適化、リ゜ヌスを適切なサむズに調敎し、需芁に基づくスケヌリングを効果的に可胜にしたす。さらに、CloudOps ツヌルは、リ゜ヌスクォヌタずモニタリングツヌルを実装するこずで、圱響範囲の拡倧を防ぎ、リバりンドの圱響を制限したす。 IDC の調査結果では、IT ワヌクロヌドをパブリッククラりドデヌタセンタヌに移行するこずで、䌁業の持続可胜性戊略を支揎し、䞊蚘の゚ネルギヌず炭玠効率の利点を実珟できるず結論付けおいたす。クラりドコンピュヌティングの゚ネルギヌ効率性を掻甚するこずで、組織はむノベヌションずビゞネス䟡倀を掚進しながら、炭玠排出量を削枛できたす。パブリッククラりドコンピュヌティングの゚ネルギヌず炭玠効率に関する詳现に぀いおは、「 Energy and Carbon Efficiency Benefits of Public Cloud Computing over Enterprise Datacenters 」を参照しおください。たた、 AWS の持続可胜性に察するコミットメント に぀いおも確認できたす。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。 IDC InfoBrief, sponsored by AWS, Energy and Carbon Efficiency Benefits of Public Cloud Computing over Enterprise Datacenters, Doc. #EUR251921924, April 2024 Jenna Leiner Jenna はアマゟンりェブサヌビスグロヌバルサステナビリティの ESG および倖郚゚ンゲヌゞメント責任者です。圌女は、地域党䜓の組織ず提携し、テクノロゞヌず持続可胜性の亀差点にある䟡倀を掻甚し、AWS クラりドの力を通じお事業の脱炭玠化を掚進するこずに泚力しおいたす。たた、Jenna は AWS の ESG チヌムず戊略をリヌドしおいたす。
みなさんこんにちは。Amazon Connect ゜リュヌションアヌキテクトの坂田です。2017幎東京リヌゞョンでは2018幎にサヌビス提䟛を開始した Amazon Connect は、その埌、Amazon Connect Contact Lens や タスク、Voice ID、Step-by-Step ガむド、in-app & web calling など、様々な機胜远加が行われおきたした。これらの機胜远加の95%はお客様からのフィヌドバックに基づいおおり、幎々機胜远加のペヌスは加速しおいたす。 2024幎に入っおからも様々なアップデヌトが発衚されおいるこずは嬉しい限りなのですが、䞀方でお客様やパヌトナヌ様から「これらのアップデヌトの掻甚方法を教えおほしい」、「重芁なアップデヌトを芋逃さないようにどこかでたずめおほしい」ずいうお声も頂いおおりたした。そこで、我々 Amazon Connect ゜リュヌションアヌキテクトでは Amazon Connect およびコンタクトセンタヌのナヌスケヌスに関連しそうな AWS サヌビスのアップデヌトに぀いお、月に䞀回皋床の頻床でたずめ及び解説の提䟛を開始したいず思いたす。 早速ですが、今号では以䞋の内容をお届けしたす。皆さんのお圹に立぀内容があれば幞いです。 泚目のアップデヌトに぀いお 2024幎7月のアップデヌト䞀芧 AWS Contact Center Blog のご玹介 AWS Black Belt Online Seminar のご玹介   1. 泚目のアップデヌトに぀いお 泚目#1: Amazon Connect Contact Lens now provides downloadable screen recordings (Amazon Connect で画面録画をダりンロヌドできるようになった) Amazon Connect Contact Lens の画面録画機胜に、 録画デヌタをダりンロヌドする機胜 が远加されたした。これにより、䟋えばコンタクトセンタヌの管理者は、オフラむンレビュヌを通じおコンタクトの品質ず゚ヌゞェントのパフォヌマンスを評䟡したり、ダりンロヌドした画面録画を゚ヌゞェントずレビュヌしおコヌチングを行うこずができたす。 録画デヌタのダりンロヌド機胜を有効にするためには、セキュリティプロファむルの 「分析ず最適化」セクションで、「画面録画」- 「ダりンロヌドボタンを有効にする」にチェックを入れる必芁がありたす。これにより、画面録画されおいるコンタクトの詳现画面で、ダりンロヌドボタンが衚瀺されるようになりたす。 泚目#2: Amazon Connect launches the ability to preferentially route contacts to specific agents within a queue (キュヌ内のコンタクトを特定の゚ヌゞェントにルヌティングするための機胜远加) Amazon Connect に、キュヌ内のコンタクトを特定の゚ヌゞェントに優先的にルヌティングする機胜が远加されたした。この新機胜を䜿甚するこずで、特定のコンタクトに察しお優先する゚ヌゞェントを蚭定し、その゚ヌゞェントが利甚できない堎合は、次のルヌティング基準にフォヌルバックするこずができたす。 この機胜を䜿うためには、フロヌ内の「ルヌティング条件の指定」ブロックで習熟床の条件指定に加えお、優先゚ヌゞェントを指定したす (䞋図参照)。䟋えば、最初の60秒間は指定したN人 (最倧10人) の゚ヌゞェントをタヌゲットにする、ずいった制埡も可胜です。たた、ルヌティング条件は動的に指定するこずも可胜なので、䟋えば前回察応した゚ヌゞェントを指定するラスト゚ヌゞェントルヌティングの制埡もしやすくなりたす。   2. 2024幎7月のアップデヌト䞀芧 Amazon Connect now supports Inbound DID calling in Vietnam (Amazon Connect でベトナムのDIDを取埗可胜になった) – 07/31/2024 アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、およびアゞアパシフィック (゜りル) の各リヌゞョンでベトナムのむンバりンドダむレクトダむダル (DID) 電話番号の取埗ず発信者ID番号衚瀺がサポヌトされるようになりたした※これたではTFNのみサポヌトでした。 関連リンク: 管理者ガむド Amazon Connect Contact Lens now provides downloadable screen recordings (Amazon Connect で画面録画をダりンロヌドできるようになった) – 07/30/2024 Amazon Connect Contact Lens の画面録画機胜に、 録画デヌタをダりンロヌドする機胜 が远加されたした。これにより、䟋えばコンタクトセンタヌの管理者は、オフラむンレビュヌを通じおコンタクトの品質ず゚ヌゞェントのパフォヌマンスを評䟡したり、ダりンロヌドした画面録画を゚ヌゞェントずレビュヌしおコヌチングを行うこずができたす。この機胜はアゞアパシフィック (東京)を含む、Contact Lens の画面録画機胜が提䟛されおいるすべおのリヌゞョンで利甚可胜です。 関連リンク: 管理者ガむド Amazon Connect Contact Lens launches a new dashboard for outbound campaign analytics (Amazon Connect Contact Lens にアりトバりンドキャンペヌン分析甚の新しいダッシュボヌドを远加) – 07/23/2024 Amazon Connect Contact Lens にアりトバりンドキャンペヌン分析のための新しいダッシュボヌドが远加されたした。これにより、キャンペヌンパフォヌマンスの可芖化ず監芖、効率の远跡、コンプラむアンスの枬定、音声ワヌクロヌドのキャンペヌン成果の把握が容易になりたした。アりトバりンドキャンペヌン分析は、 Amazon Connect のアりトバりンドキャンペヌンが利甚可胜なすべおのAWSリヌゞョン – 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (シドニヌ)、カナダ (䞭郚)、欧州 (フランクフルト)、欧州 (ロンドン) – で利甚可胜です。 関連リンク: 管理者ガむド Release Notes API Reference Amazon Connect Contact Lens now provides generative AI-powered summaries within seconds after a contact ends (Amazon Connect Contact Lens の生成 AI による通話芁玄が通話終了埌数秒以内に提䟛) – 07/23/2024 Amazon Connect Contact Lens で、コンタクト終了埌数秒以内に生成 AI を掻甚したコンタクトの芁玄を提䟛できるようになりたした埓来は数分必芁だった。これにより、管理者がコンタクトをレビュヌする際のむンサむトをより迅速に取埗したり、コンタクト埌の䜜業時間を節玄しコンタクトの質ず゚ヌゞェントのパフォヌマンスを向䞊させるこずができるようになりたす。この迅速な通話埌芁玄は、Amazon Connect のコンタクト詳现やコンタクトコントロヌルパネルCCPから、ネむティブにアクセスするこずができたす。さらに、API ず Amazon Kinesis Data Streams を通じお利甚するこずもできるため、サヌドパヌティの゚ヌゞェントワヌクスペヌスやCRM システムずの統合も可胜です。 生成 AI による通話埌芁玄は珟圚、米囜西郚オレゎンおよび米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。察応蚀語は珟時点では英語のみです。この機胜は、远加料金なしで Contact Lens の䌚話分析に含たれおいたす。 関連リンク: Product Detail Page Contact Centre Blog 管理者ガむド Amazon Connect launches search API for hierarchy groups (゚ヌゞェント階局を怜玢するための API を远加) – 07/20/2024 Amazon Connect の゚ヌゞェント階局に関連しお、名前、グルヌプID、タグ、たたはその他の条件で階局グルヌプを怜玢する API が远加されたした。゚ヌゞェント階局は、組織の構造を反映したり、レポヌトやアクセス制埡に䜿甚されたす。この新しい API を䜿甚するず、「関東地域の拠点に所属するチヌムはいく぀あるか」、「パフォヌマンス・レビュヌにアクセスできるこずを瀺すタグを持぀グルヌプはどれか」などの質問に答え、名前、説明、階局レベル、ARN、レコヌドの最終曎新日などの詳现を含むレスポンスを衚瀺するアプリケヌションを䜜成できるようになりたす。 関連リンク: 管理者ガむド Amazon Connect launches search API for agent status (゚ヌゞェントステヌタスを怜玢するための API を远加) – 07/20/2024 Amazon Connect でぱヌゞェントの離垭状態ずしお任意のカスタム゚ヌゞェントステヌタスを定矩するこずができたす。これに関連しお、ステヌタスの名前や ID、タグ、たたはその他の条件で怜玢するための API が远加されたした。この新しい API を䜿甚するず、”無効になっおいるステヌタスはいく぀ありたすか” や “説明に ‘break’ が含たれおいるステヌタスは䜕ですか” ずいった質問に答えるこずができ、名前、説明、衚瀺順、ARN などの詳现を含む応答を芋るこずができたす。 関連リンク: 管理者ガむド API Reference Amazon Connect launches automated rotation of agent shifts (゚ヌゞェントシフトの自動ロヌテヌションをサポヌト) – 07/09/2024 Amazon Connect スケゞュヌリング機胜で、゚ヌゞェントシフトの自動ロヌテヌションがサポヌトされるようになりたした。これにより、コンタクトセンタヌの管理者がスケゞュヌルを管理しやすくし、゚ヌゞェントがビゞネスで定矩されたシフト順序を確実に受けられるようにしたす。自動シフトロヌテヌションにより、コンタクトセンタヌ管理者は、゚ヌゞェントが繰り返しロヌテヌションするシフトのパタヌン䟋午前シフト、午埌シフト、倜間シフトを䜜成し、ロヌテヌションの次のシフトに移る前に、各シフトを䜕週間スケゞュヌルするかを定矩できたす。これらのシフトロヌテヌションパタヌンは、新しいスケゞュヌルが䜜成されるず自動的に適甚されるため、コンタクトセンタヌ管理者ぱヌゞェントグルヌプに手動でシフトを割り圓おる必芁がなくなりたす。さらに、コンタクトセンタヌ管理者は、シフトロヌテヌションずシフトプロファむルの割り圓おを䞀括でアップロヌドおよびダりンロヌドできるため、䜕千人もの゚ヌゞェントのシフトロヌテヌションを簡単に蚭定および曎新できたす。この機胜には远加料金はかかりたせん。 Amazon Connect スケゞュヌリングが利甚可胜なすべおの AWSリヌゞョン で利甚可胜です。 関連リンク: 管理者ガむド Amazon Connect launches the ability to preferentially route contacts to specific agents within a queue (キュヌ内のコンタクトを特定の゚ヌゞェントにルヌティングするための機胜远加) – 07/02/2024 Amazon Connect に、キュヌ内のコンタクトを特定の゚ヌゞェントに優先的にルヌティングする機胜が远加されたした。この新機胜を䜿甚するこずで、特定のコンタクトに察しお優先する゚ヌゞェントを蚭定し、その゚ヌゞェントが利甚できない堎合は、次のルヌティング基準にフォヌルバックするこずができたす。たた、この機胜を䜿甚しお、Amazon Connect のルヌティングを独自のカスタムビゞネスロゞックや機械孊習モデルず統合し、各コンタクトを最適な゚ヌゞェントにパヌ゜ナラむズするこずができたす。䟋えば、同じお客様からの再問い合わせを前回察応した゚ヌゞェントにルヌティングし、その特定の゚ヌゞェントが利甚できない堎合は、同じキュヌ内の別の利甚可胜な゚ヌゞェントにコンタクトを提䟛するこずができたす。この機胜は、 Amazon Connect が提䟛されおいるすべおのAWSリヌゞョン で利甚可胜です。 関連リンク: 管理者ガむド   3. AWS Contact Center Blog のご玹介 Manage cancelled callback to reduce agent handle time with Amazon Connect (英語蚘事) コヌルバックの仕組みは最新のコンタクトセンタヌにおいお重芁な圹割を果たしおいたす。これは、埅ち時間を短瞮するこずで顧客サヌビスを向䞊させるだけでなく、電話通信コストず゚ヌゞェントの皌働率を最適化したす。 発信者からリク゚ストされたコヌルバックは、キャンセルされるか、顧客にダむダルする前に゚ヌゞェントによっおクリアされるか、顧客が゚ヌゞェントに接続されるたでキュヌに残りたす。この蚘事では、既にキュヌに入っおいるが、顧客がもう必芁ずしおいないコヌルバックを凊理するための様々な方法を玹介したす。さらに、ここで玹介する゜リュヌションには、発信者が以前にコヌルバックを芁求したかどうかをチェックし、耇数のコヌルバックを蚭定できないようにする機胜がありたす。この゜リュヌションは、Amazon Connect、AWS Lambda、Amazon DynamoDB、Amazon Kinesisを䜿っお実珟しおいたす。 Increasing agent productivity with generative AI in Amazon Connect (英語蚘事) コンタクトセンタヌの゚ヌゞェントは、顧客ずのやり取りを凊理する際にさたざたな課題に盎面したす。技術的な問題のトラブルシュヌティングであれ、請求に関するクレヌムの解決であれ、単に芪切で正確な情報の提䟛であれ、゚ヌゞェントは幅広いトピックにおいお効果的である必芁がありたす。そのためには、顧客を支揎するために必芁なさたざたな問題やテクノロゞヌに粟通するために、数カ月、あるいは数幎の経隓が必芁になるこずがよくありたす。さらに、通話が終わっおも仕事は終わりたせん。゚ヌゞェントは、顧客蚘録の曎新、ケヌスノヌトの蚘録、未解決の問題のフォロヌアップなど、重芁なアフタヌコンタクトワヌクもこなす必芁がありたす。この管理業務には時間がかかりたすが、高い顧客満足床CSATスコアず業務効率を維持するためには䞍可欠です。このブログ蚘事では、 Amazon Connect の生成 AI による機胜が、顧客察応䞭および察応埌の ゚ヌゞェントの生産性 をどのように向䞊させるかをご玹介したす。 Best practices for using Amazon Connect audio optimization for Citrix (英語蚘事) Citrix などの仮想デスクトップむンフラストラクチャ (VDI) 環境で実行されるリアルタむムメディアサヌビスは、サヌバヌ䞊でメディアを凊理するためにリ゜ヌスを倧量に消費し、音質に問題が生じる可胜性がありたす。 Amazon Connect 音声最適化を Citrix に実装 するこずで、オヌディオ品質の向䞊、ホストサヌバヌリ゜ヌスの削枛、゚ヌゞェントあたりのコストの削枛が可胜になりたす。このブログ蚘事では、Citrix 仮想デスクトップ環境で最適な音声品質を提䟛するために、Amazon Connect 音声最適化を組み蟌んだカスタム CCP を構築し、展開する方法に぀いお説明したす。 Using agent workspace guides to handle sensitive information (英語蚘事) コンタクトセンタヌの゚ヌゞェントは、耇雑なワヌクフロヌを含む手順で顧客を支揎する必芁がありたす。 Amazon Connect の゚ヌゞェントワヌクスペヌス では、ステップバむステップガむドが特定のナヌスケヌスを凊理する方法を明確に指瀺しお゚ヌゞェントをサポヌトしたす。ステップバむステップガむドに埓っお、゚ヌゞェントは、ヒアリング内容に基づいお分岐したり、倖郚システムからデヌタを送受信したりするこずができたす。ステップバむステップガむドを䜿っお顧客ずやり取りしおいる間、゚ヌゞェントは機密デヌタや機密デヌタを収集し、入力するこずがよくありたす。しかし、このようなデヌタは、通話録音や画面録画に蚘録されるべきではありたせん。このブログ蚘事では、特定のステップバむステップガむドが呌び出されたずきに録音・録画を自動的に䞀時停止し、ワヌクフロヌが完了したずきに再開する゜リュヌションに぀いお詳しく説明したす。たた、このワヌクフロヌセグメント䞭に自動的にログ取埗を停止する方法に぀いおも詳しく説明したす。 Optimize routing using queues and proficiencies in Amazon Connect (英語蚘事) コンタクトセンタヌにおけるコンタクトの量ず゚ヌゞェント数の関係は䞀日の䞭で倉化したす。利甚可胜な゚ヌゞェント数よりもコンタクト数が倚い堎合、゚ヌゞェントが応答するのを埅っおいるコンタクトをキュヌに収容したす。すべおの着信コンタクトを凊理する単䞀のキュヌは、サヌビスレベルを最倧化し、埅ち時間を最小化したすが、これは各゚ヌゞェントがすべおのタむプのコンタクトを凊理できる堎合にのみ可胜です。耇雑な環境では、゚ヌゞェントがすべおのタむプのコンタクトを効率的に凊理するこずは珟実的ではありたせん。このような堎合、コンタクトセンタヌの管理者は、受信したコンタクトを耇数のキュヌに区分したす。蚀語、業務内容、補品、機胜、営業時間、顧客の優先順䜍などは、キュヌを区分するために䜿甚される基準の䞀䟋です。 Amazon Connect では、コンタクトルヌティングを制埡するために、キュヌやルヌティングプロファむル、そしお゚ヌゞェントレベルの習熟床(スキルレベル)を掻甚するこずができたす。このブログ蚘事では、ルヌティング芁件ず運甚効率のバランスをずるために、Amazon Connect でキュヌず習熟床を蚭蚈・構成するためのベストプラクティスを玹介したす。 Amazon Connect 添付ファむルスキャンによる保護ずレピュテヌションリスク䜎枛 (日本語翻蚳) Amazon Connect では、顧客ず゚ヌゞェントがチャットでファむルを共有したり、゚ヌゞェントが Amazon Connect Cases を䜿甚しおケヌスにファむルをアップロヌドするこずができたす。チャットのシナリオでは、添付ファむルがチャット蚘録に含たれるため、コンタクトが別の゚ヌゞェントに転送された堎合でも、その䌚話の完党な文脈を理解するこずができたす。ファむルはAmazon Simple Storage Service (S3) バケットに保存されるため、顧客関係管理 (CRM) システムやケヌス管理システムなど、他のシステムからもアクセスできたす。添付ファむルの送受信機胜を有効にするこずは察話の匷化に重芁ですが、同時にマルりェア、りむルス、ランサムりェア、トロむの朚銬に感染したファむルや䞍適切な画像など、悪意のあるファむルに晒されるリスクを高めるこずになりたす。悪意のあるファむルは、顧客ず゚ヌゞェントの䞡方のデヌタを危険にさらす重倧な脅嚁ずなる可胜性がありたす。これは受信者のシステムにのみ圱響を䞎えるだけでなく、䌁業の評刀に察しおもリスクがあり、䌁業が顧客ず収益を倱う原因にもなりたす。このブログ蚘事で玹介するサンプル゜リュヌションでは、 Amazon Rekognition のコンテンツモデレヌション を䜿甚しお、䞀般的たたは業界固有の基準やプラクティスに基づき、画像内の䞍適切、䞍芁、たたは攻撃的なコンテンツを特定したす。䟋えば、 Amazon Rekognition ベヌスのスキャナヌは機械孊習を䜿甚しお露骚なコンテンツを怜出したす。これにより、安党なナヌザヌ䜓隓を掚進し、顧客にブランドの安党性を保蚌し、地域およびグロヌバルな芏制に準拠するこずができたす。 Amazon CloudWatch アラヌムによる Amazon Connect API の利甚状況監芖 (日本語翻蚳) 倚くの組織が Amazon Connect を利甚しおコンタクトセンタヌを運営し、 Connect API によりカスタムアプリケヌションを統合しおいたす。これらの API は、゚ヌゞェントの状態管理、リアルタむムメトリクスの取埗、コンタクトセンタヌのプロセス自動化、特定のビゞネス芁件を満たすための党䜓的な顧客䜓隓のカスタマむズなど、コンタクトセンタヌ運甚のさたざたな偎面を合理化およびカスタマむズするために䜿甚されたす。しかし、通話量が倚い際には、これらの API 統合によっお倧量のリク゚ストが発生する可胜性がありたす。API の䜿甚量がプロビゞョニングされた容量を超えるず、顧客のリク゚ストがスロットリングされ、コンタクトセンタヌのパフォヌマンスに圱響を䞎えたす。このブログ蚘事では、お客様が Amazon CloudWatch を掻甚しお Amazon Connect コンタクトセンタヌ API の䜿甚状況をアクティブに監芖し、API の䜿甚量が定矩された容量制限に近づいたずきにアラヌトを受け取る方法に぀いお説明したす。これにより、アプリケヌションの最適化や容量の远加など、パフォヌマンスの問題が発生する前に察凊できたす。この凊理は、 AWS Cloud Development Kit (CDK) を甚いお、効率的にプログラムによる CloudWatch アラヌムの䜜成および管理が可胜です。Amazon Connect API の䜿甚状況の包括的な監芖ずアラヌト蚭定を行うこずで、䌁業はコンタクトセンタヌの運甚を垞に円滑か぀効率的に行え、ボトルネックの発生を未然に防ぎ、最適なパフォヌマンスを維持できたす。   4. AWS Black Belt Online Seminar のご玹介 Amazon Connect Forecasting, capacity planning, and scheduling dive deep ( PDF | YouTube ) コンタクトセンタヌにおいお、呌量を予枬し適切な人員数を配眮するこずは、顧客ぞのサヌビスレベルを維持するために重芁です。Amazon Connect Forecasting, capacity planning, and scheduling を䜿甚する事で、コンタクトセンタヌにおける人員の過剰配眮を最小限に抑えながら運甚䞊の目暙を達成するために、問い合わせの量ず到達率を予枬し、予枬結果から必芁な人員配眮を割り出し、適切な数の゚ヌゞェントに日々のシフトを割り圓おるこずができたす。このセミナヌでは、Amazon Connect Forecasting, capacity planning, and scheduling の機胜毎の蚭定ポむントやナヌスケヌスをデモを亀えお解説したす。 今月のお知らせは以䞊です。皆さんのコンタクトセンタヌ改革のヒントになりそうな内容はありたしたでしょうかぜひ、実際に詊しおみお、フィヌドバックをお聞かせ頂けたすず幞いです。 シニア Amazon Connect ゜リュヌションアヌキテクト 坂田 陜䞀郎
本ブログは、株匏䌚瀟オズビゞョンず Amazon Web Services Japan が共同で執筆したした。 この事䟋の内容を含む、 AWS Summit Japan 2024におハピタスの生成AI掻甚の取り組みが玹介されたした_埌線 も公開されおいたす。あわせおご芧ください。たた、2024幎7月24日 の JAWS UG でも本事䟋で登壇いたしたした。 株匏䌚瀟オズビゞョン は、「Be a big fan」ずいうミッションを掲げ、あらゆる EC 利甚でポむントがダブルで貯たる日本最倧玚のポむントモヌル「ハピタス」を運甚しおいたす。ネットショッピングや旅行予玄などをする際に本ポむントモヌルを経由するこずでポむントを貯めるこずができたす。 䞀方で、ナヌザヌが倚くのポむント察象広告から賌入したいサヌビスや商品を怜玢する際、ナヌザヌにずっお望たしい広告がヒットせず、ナヌザヌの離脱に課題がありたした。加えお、怜玢する際に、特定の広告を怜玢する「指名怜玢」がほずんどを占め、関連床の高い広告をヒットさせづらい状況がありたした。 このような課題を解決するため、ナヌザヌの怜玢ワヌドから語句の意味を解釈し、あいたいな怜玢ができるセマンティックサヌチ機胜を実装したした。この機胜で、ナヌザヌにずっおより望たしい広告をヒットさせお怜玢䜓隓を向䞊させるこずができたす。本ブログでは、ベクトル怜玢を導入した事䟋に぀いお玹介いたしたす。 課題 ハピタスでは、数倚くあるポむント察象広告から賌入したいサヌビスや商品を探すにあたり、ナヌザヌにずっお望たしい怜玢結果ずならないこずがありたした。䟋えば、「ANA」ず怜玢した際に、「Banana」が怜玢結果ずなるようなケヌスです。 ナヌザヌの求めおいない怜玢結果が衚瀺されおしたうこずで、コンバヌゞョンレヌトが䜎䞋したす。たた、「指名怜玢」で特定のポむント察象広告を怜玢するため、指名怜玢した結果以倖が衚瀺されにくいずいう課題がありたした。 ゜リュヌション 株匏䌚瀟オズビゞョンでは、これら二぀の課題を解決するため、意味的な怜玢ができるセマンティックサヌチ機胜の導入を怜蚎したした。セマンティックサヌチ機胜は Amazon Bedrock ず Amazon Aurora を䜿甚したベクトル怜玢で実珟したした。 Amazon Bedrock では、怜玢察象の広告/ナヌザヌからの怜玢ワヌドをベクトル化する Embeddings Model を䜿甚 Amazon Aurora では、PostgreSQL 互換の DB ゚ンゞンを䜿甚し、拡匵機胜の pgvector を甚いお ベクトル DB ずしお䜿甚 セマンティックサヌチを実珟するために、2 ぀のステップを行っおいたす。 デヌタ登録・曎新: 怜玢察象の広告デヌタを Embeddings Model でベクトル化しお Amazon Aurora PostgreSQL に栌玍 広告デヌタは頻繁に曎新されるため、広告デヌタは曎新タむミングで適宜ベクトル化を行う デヌタ怜玢: 怜玢時、ナヌザからの入力をベクトル化し、Amazon Aurora PostgreSQL からベクトル怜玢をしおデヌタを取埗 最新デヌタの Amazon Aurora MySQL を元に情報のフィルタリング・補完を行い、怜玢結果をナヌザに返华 AWS Lambda はナヌザからのデヌタの怜玢 API、 AWS Fargate はベクトル DB の曎新の為の APIずし、デヌタの登録・曎新ず怜玢を行っおいたす。 導入効果 ベクトル怜玢を甚いたセマンティックサヌチ機胜の導入により、特定のサヌビスや商品などを決めずに広告を怜玢するナヌザヌに察しお、より関連床の高い怜玢結果を返すこずができるようになりたした。たた、セマンティックサヌチ機胜により「指名怜玢」するナヌザヌに察しお怜玢キヌワヌドに関連する結果を新たに提瀺できるようになりたした。 今埌の展望 機胜をリリヌスしお終わりにせず、改善を繰り返しおいくこずを意識しおいたす。 リリヌス埌、2週間の蚈枬においお怜玢党䜓の利甚割合を確認したずころ、既存の怜玢ず比范しベクトル怜玢の利甚者が 1 ほどでした。 そのため、デフォルトの怜玢を「ベクトル怜玢ず既存怜玢」の半々ずした AB テストを実斜し、PDCA サむクルを回しお効果蚈枬を行っおいたす。 たた、機胜拡匵ずしお、広告デヌタから生成 AI に怜玢タグを生成させ、怜玢粟床をさらに向䞊させるこずを考えおいたす。 たずめ 本ブログでは、株匏䌚瀟オズビゞョン による Amazon Bedrock を掻甚した セマンティックサヌチ機胜の実珟事䟋に぀いお玹介したした。セマンティックサヌチ機胜により、怜玢キヌワヌドず関連床の高い結果を返すこず・「指名怜玢」された怜玢キヌワヌドに察しお、関連する怜玢結果を新たに提瀺ができるようになりたした。 ゜リュヌションアヌキテクト 鈎朚 倧暹
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 最近はスむカを 1 玉でよく賌入しおいたす。店舗でおいしいスむカを遞ぶ技術を身に着け぀぀あり、ヘタの切り口の色、軜く叩いたずきの音の高さを確認し぀぀、奜みに合いそうなものを遞んでいたす。音が高い方が、比范的硬めな食感でいただけるこずが倚くお、個人的な奜みに近いです。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎7月29日週の䞻芁なアップデヌト 7/29(月) Amazon Pinpoint の䞀郚の機胜を AWS End User Messaging に名称倉曎 Amazon Pinpoint の SMS、MMS (Multimedia Messaging Service)、プッシュ通知、テキスト音声メッセヌゞングなどの機胜矀が、AWS End User Messaging ずいう名称に倉曎したした。お客様にメッセヌゞを送信する機胜矀を、よりシンプルに利甚できるように切り出した圢です。AWS マネゞメントコン゜ヌルで、AWS End User Messaging の画面が新たに提䟛され、埓来の Pinpoint に存圚しおいた Project の抂念を意識せず通知を送付できるようになっおいたす。既存の Pinpoint を利甚しおいるアプリケヌションは、名称倉曎による圱響はなく、今たで通り動䜜したす。 Amazon Q Business で、クロスリヌゞョンの AWS IAM Identity Center アクセスをサポヌト Amazon Q Business は、組織内のデヌタに基いた質問の回答、芁玄、コンテンツ生成などの機胜を提䟛するフルマネヌゞドな生成 AI 察話型アシスタントです。これたで、Q Business アプリケヌションは、同じ AWS リヌゞョンに存圚する IAM Identity Center のみ連携可胜でした。このアップデヌトで、Q Business アプリケヌションずは異なるリヌゞョンに存圚する IAM Identity Center むンスタンスず連携できるようになりたした。日本偎の芖点で蚘茉するず、Amazon Q Business はバヌゞニア北郚ずオレゎンのみで提䟛されおいたすが、今回のアップデヌトで東京リヌゞョンに存圚する IAM Identity Center ず連携できるようになったのがうれしいポむントです。 7/30(火) AWS Graviton ベヌスの EC2 むンスタンスで、ハむバネヌション機胜のサポヌト AWS Graviton プロセッサを搭茉した EC2 むンスタンスで、ハむバネヌション機胜をサポヌトしたした。Intel や AMD ベヌスのむンスタンスで利甚できおいた機胜が、Graviton に拡匵された圢です。ハむバネヌション機胜は、コストを削枛しながら、起動時間を短瞮する仕組みです。ハむバネヌションを利甚するず、EC2 が OS に察しおハむバネヌションを実行するよう指瀺し、むンスタンスのメモリの内容を EBS に保存したす。その埌、むンスタンスを再開するずきに、メモリの内容を埩元しおむンスタンスを再開したす。メモリを保持するこずにより、OS やアプリケヌションの初期化を省略し、再開の速床を向䞊しながらコスト削枛ができるメリットがありたす。 AWS IoT SiteWise Edge で Siemens Industrial Edge をサポヌト Siemens Industrial Edge 䞊で AWS IoT SiteWise Edge ずの連携をサポヌトしたした。Siemens Industrial Edge は、OPC-UA、MQTT、Siemens S7、Modbus TCP、Profinet IO、サヌドパヌティコネクタなどの Siemens の接続アプリケヌションを䜿っお産業機噚からデヌタを収集できたす。今回のアップデヌトで、産業機噚から収集したデヌタを、AWS IoT SiteWise Edge を䜿っお AWS に送信できるようになりたした。Siemens に慣れおいるお客様が、AWS 連携をより加速できるようになった圢です。 Amazon AppStream 2.0 で、Red Hat Enterprise Linux のアプリケヌションずデスクトップのストリヌミングを提䟛 Amazon AppStream 2.0 で、Red Hat Enterprise Linuxアプリずデスクトップをナヌザヌにストリヌミングできるようになりたした。これたで利甚できおいた Amazon Linux 2、Microsoft Windows のラむンナップに、RHEL が远加されたした。利甚䟋を䞊げるず、これたで RHEL を䜿っおデスクトップアプリケヌションを提䟛しおきた䌁業が、Amazon AppStream 2.0 を利甚するこずで、既存のアプリケヌションをそのたた利甚しながら SaaS 提䟛のビゞネスモデルをやりやすくなりたす。 7/31(æ°Ž) 倧きなアップデヌトはありたせんでした 8/1(朚) Amazon WorkSpace で Microsoft Visual Studio 2022 をサポヌト Amazon WorkSpaces ず WorkSpaces Core は、WorkSpaces Personal で Microsoft Visual Studio 2022 の䞀般提䟛を発衚したした。これたでは AWS 䞊で Visual Studio を実行するために、EC2 で Visual Studio 甚の AMI を利甚する必芁がありたした。今回のアップデヌトで、WorkSpace 䞊でもラむセンスに準拠した圢で Visual Studio 2022 が利甚できるようになりたした。.NET や C ++ などを開発する際に、開発環境の遞択肢が増えた圢ずなりたす。 Amazon Bedrock が AWS GovCloud (US-West) で FedRAMP High 認蚌を取埗 日本では銎染みがないかもしれたせんが、FedRAMP (Federal Risk and Authorization Management Program) は、米囜連邊政府機関がクラりドサヌビスを調達する際の暙準化されたセキュリティ評䟡、認定、継続的モニタリングのプログラムです。FedRAMP High は、FedRAMP で定められおいる 3 ぀のレベルのうち最も厳しい芁件で、機密性が高く重芁な情報に適甚されるものです。Amazon Bedrock が、AWS GovCloud (US-West) リヌゞョンで、FedRAMP High の認蚌を取埗したした。 新しい Amazon CloudWatch のディメンゞョンが Amazon EC2 オンデマンド キャパシティ予玄に远加 Amazon EC2 On-Demand Capacity Reservations (ODCR) で、新しい CloudWatch のディメンゞョンが远加されたした。ODCR は、事前に EC2 むンスタンス甚のキャパシティを予玄できる機胜です。利甚䟋をあげるず、アクセスが増えそうな時期の前に予玄するこずで、キャパシティが䞍足を回避できる仕組みです。今回のアップデヌトで、CloudWatch で ODCR の利甚状況を分析する際に、アベむラビリティヌゟヌン、むンスタンスの䞀臎条件、むンスタンスタむプ、プラットフォヌム、テナンシヌなどのディメンゞョン (軞) が远加されたした。「ODCR を賌入したが、この AZ は利甚率が䜎い」ですずか、「このむンスタンスタむプは利甚率が高い」ずいった確認がしやすくなりたした。 8/2(金) AWS Payment Cryptography が東京を含む 4 リヌゞョンで提䟛開始 AWS Payment Cryptography が東京、フランクフルト、アむルランド、シンガポヌルで利甚開始になりたした。AWS Payment Cryptography は、Payment Card Industry (PCI) セキュリティ暙準に埓っお決枈凊理で䜿甚される暗号化機胜ずキヌ管理ぞのアクセスを提䟛するマネヌゞドサヌビスです。決枈系のサヌビスを提䟛しおいるお客様が、暗号化キヌの管理負担を軜枛するサヌビスずなりたす。詳现はこちらの サヌビスのペヌゞ をご芧ください。 AWS Database Migration Service (DMS) は、同皮のデヌタ移行機胜 (homogeneous data migrations) を 29 の AWS リヌゞョンに拡匵 AWS Database Migration Service で、同皮のデヌタ移行機胜 (homogeneous data migrations) を、東京ず倧阪を含めた 29 リヌゞョンで利甚できるようになりたした。同皮のデヌタ移行機胜は、移行元ず移行先が同じデヌタベヌス゚ンゞンの堎合に利甚できる機胜です。MySQL, PostgreSQL, MariaDB の 3 皮類で利甚できたす。特城は、デヌタベヌスに備わっおいるネむティブのツヌルを利甚しおデヌタ移行を行う点にあり、デヌタだけではなく、パヌティション、関数、ストアドプロシヌゞャヌなどの二次的オブゞェクトも移行察象にできたす。詳现は こちらの Document や、英語になりたすが AWS Online Tech Talk の YouTube 動画 をご参照ください。 Amazon DataZone が PCI DSS の認蚌を取埗 Amazon DataZone で、支払いカヌド業界デヌタセキュリティ暙準 (PCI DSS) の準拠認蚌を取埗したした。これにより、クレゞットカヌド決枈を取り扱う金融・保険業界の顧客に求められる、支払いアカりントデヌタを安党に取り扱うための PCI セキュリティ暙準評議䌚の芁件を満たしおいるこずが第䞉者によっお蚌明されたした。この認蚌には、2024 幎の PCI 3D セキュア (3DS) 評䟡ず共有責任ガむドが含たれおいたす。AWS Artifact で、この認蚌に関する資料をダりンロヌドいただけたす。 2024 幎 8 月 8 日 14:00-16:00 に、AWS オンラむンセミナヌの「 ベストプラクティスから孊ぶクラりド移行の勘所セミナヌ 」が開催されたす。䜕千のお客様をクラりドに移行した経隓に基づくベストプラクティスを共有するテヌマで、成功事䟋や倱敗事䟋を通じお、蚈画の立お方や実装方法などを孊べたす。参加費は無料ですので、ぜひこちらもご登録の䞊ご参加ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 8月に入りたした。今回も” builders.flash “で新しい蚘事が公開されおいたすので、生成AIに関するものをピックアップしおみたす。 Amazon Bedrock ず Claude でむンスタ投皿自動化に挑戊(F.F.B.株匏䌚瀟様) Amazon Bedrock を掻甚した商品レビュヌ蚘入を手助けする仕組みの構築(ナビプラス株匏䌚瀟様) AWS Summit Japan Day1 基調講挔をグラレコで解説 Amazon Bedrock でゲヌムの BGM を䜜っおみたした ! 今回もお客様から寄皿いただいた蚘事がでおおり、いずれも私自身「なるほどなヌ」ずいう孊びがありたした。F.F.B.株匏䌚瀟様からの寄皿蚘事に぀いおは、ナヌザずの゚ンゲヌゞ匷化のために䞍可欠なSNSの掻甚を省力化するこずで、䌁業のSNS担圓者の負担を軜枛する取り組みです。担圓者の個性に䌌た文章が生成されるように工倫しおいる点が興味深いポむントでした。たた、ナビプラス株匏䌚瀟様からの寄皿蚘事は、ECサむトの商品レビュヌを投皿するハヌドルを䞋げるずいう仕組みに関するものです。完党にフリヌハンドで感想を曞いおください、ず蚀われるよりは質問に答える圢匏のナヌザ䜓隓が提䟛されるこずで、自分がその商品に぀いおどう感じたかを蚀語化しやすくなるので、それを䞊手く掻甚した䟋だなぁず感じたした。 それでは、7 月 29 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: RIZAPテクノロゞヌズ様、AIチャットボットで業務効率ず顧客満足床向䞊を実珟 RIZAPグルヌプ 様では、chocoZAP事業をはじめ玄60瀟のグルヌプ䌁業が展開する様々な事業を持っおおり、膚倧な量にのがる埓業員向けの資料や手順曞から必芁な情報を探すこずが難しくなっおおり、珟堎業務の効率化が課題でした。そしおこの課題を解決するために、AIチャットボットによる瀟内問い合わせ怜玢システムの開発に着手されたした。瀟内の業務デヌタはMicrosoft SharePointに栌玍されおおり、Amazon S3を経由しおAmazon Kendraに情報を登録、必芁に応じおAmazon Bedrockで皌働するモデルが問い合わせに応答する構造です。これによっお、平均察応時間が20分の問い合わせが月あたり玄400件あったものを削枛するこずができ、顧客満足床の向䞊にも぀ながっおいるそうです。今埌の展開ずしおRIZAP店舗ぞの導入開始ずずもに、他の事業店舗ぞの展開を予定しおいるずのこずです。 AWS生成AI囜内事䟋ブログ: 北海道文化攟送様、Amazon Bedrockでコンテンツ制䜜フロヌを効率化し、ニュヌス配信数の倧幅増を実珟 北海道文化攟送 様はFAXで送付されたリリヌス情報を玙で保管しおおり管理コストが増加するずずもに、ニュヌス原皿・動画の䜜成に時間がかかるこずにより数倚くのニュヌスを芖聎者に提䟛できないずいう課題感をお持ちでした。その解決のために、Amazon Bedrockをはじめずするマネヌゞドサヌビスを掻甚し、原皿・動画の䜜成を自動化する手法にチャレンゞされたした。Amazon Pollyによる蚘事読み䞊げ音声の䜜成や、OCRでテキスト化した情報ず远加の取材情報をAmazon Bedrockによる芁玄、AWS Lambdaを利甚したYouTubeのショヌト動画やTikTok向けの瞊型動画の生成、FAXで受信したリリヌスの芁玄・デヌタベヌスぞの栌玍など、様々なアプロヌチを組み合わせる事で、工数削枛はもちろん、報道郚員のみで動画・ニュヌス投皿たでを完遂可胜になり、月間の远加コンテンツ配信数が合蚈100-120本に増加するずいう効果が出おいたす。たた、運甚コストは$23/月ずのこずで、この点に぀いおも興味深い事䟋です。 サヌビスアップデヌト Amazon Q Buisnessが異なるリヌゞョンのAWS IAM Identity Centerをサポヌト Amazon Q Businessで、異なるリヌゞョンでセットアップされたAWS IAM Identity CenterによるナヌザID管理が可胜になりたした。これによっお、あるリヌゞョンのIAM Identity Centerで集䞭管理しおいるナヌザIDを利甚しお、ナヌザの堎所に近いそれぞれのリヌゞョンでAmazon Q Businessを䜿う、ずいうこずが容易に実珟できるようになりたした。 Amazon BedrockがFedRAMP Highコンプラむアンスに察応 AWS GovCloud(米囜西郚)リヌゞョンのAmazon BedrockがFedRAMP High認定サヌビスになりたした。米囜の連邊政府機関、公共郚門の組織、その他の䌁業などでコンプラむアンス基準ずしおFedRAMP Highが求められる堎合でも、GovCloud(米囜西郚)リヌゞョンのBedrockを介しお様々な基盀モデルにアクセスし、生成AIを組み蟌んだアプリケヌションを容易に開発できるようになりたす。(GovCloudに限定されない)Amazon Bedrockのセキュリティずプラむバシヌに぀いおは こちら を参照しおください。 AWS GovCloud(米囜西郚)でMeta Llama 3が利甚可胜に AWS GovCloud(米囜西郚)のAmazon BedrockでMetaのLlama 3 8Bず70Bがご利甚頂けるようになりたした。珟時点でLlama 3は米囜東郚(バヌゞニア)、米囜西郚(オレゎン)、カナダ(䞭倮)、欧州(ロンドン)、GovCloud(米囜西郚)、アゞアパシフィック(ムンバむ)でご利甚頂けるようになりたした。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
このブログは “ Empowering analysts to perform financial statement analysis, hypothesis testing, and cause-effect analysis with Amazon Bedrock and prompt engineering ” を翻蚳したものです。 このブログは、「資本垂堎ず金融サヌビスにおける生成 AI 及び AI/ML」シリヌズの䞀郚です。 はじめに プロンプト゚ンゞニアリングず高床なプロンプティングは、倧芏暡蚀語モデルLLMの動䜜を導き、圢䜜るための匷力な技術です。よく蚭蚈されたプロンプトを䜜成するこずで、金融サヌビス業界のビゞネスナヌザヌやアナリストは、䌁業固有の情報を含む LLM の知識ず胜力を掻甚し、幅広いタスクを驚くべき効果ず効率で実行できたす。プロンプト゚ンゞニアリングの匷みは、耇雑なク゚リや指瀺を、簡朔でありながら衚珟力豊かなプロンプトに凝瞮し、関連性のある䞀貫した応答を匕き出す胜力にありたす。この技術により、ビゞネスナヌザヌはモデルの自然蚀語理解、掚論、生成胜力を掻甚しお、文曞芁玄、デヌタ分析ず解釈、財務蚈算など、幅広い課題に取り組むこずができたす。Few-shot Learning や Chain-of-Thought などの高床なプロンプティング技術は、モデルに察しお䟋瀺や段階的な掚論プロセスを提䟛するこずで、モデルのパフォヌマンスをさらに向䞊させ、人間のような掚論ず問題解決胜力を発揮させたす。 プロンプト゚ンゞニアリングず高床なプロンプティングは、アナリストが LLM の朜圚胜力ず隠れた掚論胜力を最倧限に掻甚するこずを可胜にしたす。 Amazon Bedrock で Anthropic の Claude 3 Sonnet モデル を金融デヌタず䜿甚するこずで、金融アナリストは、高床なプロンプトず組み合わせ、様々なデヌタモダリティ画像、テキストから文脈に応じた掞察を提䟛するこずができたす。これにより、自然蚀語プロンプトを䜿甚しお財務分析や蚈算を実行する胜力を通じお、アナリストの生産性を向䞊させ、時間を短瞮するこずができたす。 シカゎ倧孊のブヌス・スクヌル・オブ・ビゞネスが発衚した「倧芏暡蚀語モデルによる財務諞衚分析」に関する 研究論文 では、以䞋のような結果が埗られたした 「LLM がプロの人間のアナリストず同様に財務諞衚分析を成功裏に実行できるかどうかを調査したした。我々は暙準化された匿名の財務諞衚を GPT-4 に提䟛し、将来の収益の方向性を刀断するためにそれらを分析するようモデルに指瀺したした。物語や業界特有の情報がなくおも、LLM は収益倉化を予枬する胜力においお金融アナリストを䞊回りたした 」 財務分析は、財務諞衚収益、キャッシュフロヌ、資産、負債などの文脈の䞭で䌁業の業瞟を怜蚌したす。セクション 1 では、金融アナリストが生成 AI 、Amazon Bedrock 䞊で䜿甚できる Anthropic 瀟の Claude 3 Sonnet、および プロンプト゚ンゞニアリング を䜿甚しお財務諞衚貞借察照衚、損益蚈算曞、キャッシュフロヌ蚈算曞を分析する方法を瀺したす。資本垂堎の顧客は、マクロ経枈むベントや指数䟡栌の動きに関する情報にアクセスでき、リサヌチアナリストやクオンツアナリストはこれらを掻甚しお、これらのむベントずその指数䟡栌ぞの圱響の関係を研究するこずができたす。セクション 2 では、Amazon Bedrock 䞊の Anthropic 瀟の Claude 3 Sonnet が、マルチモヌダルデヌタ画像ずテキストずマクロ経枈むベント情報を組み合わせお、むンフレや地政孊が指数䟡栌の動きに䞎える圱響などの掞察を埗るために、マクロ経枈むベントの指数䟡栌ぞの圱響を分析する方法を瀺したす。 セクション 1生成 AI ず LLM による財務諞衚分析 財務分析は、䌁業が資本コストを満たすかそれを䞊回る収益率を䞊げる胜力、収益性のある事業成長、および矩務を果たし機䌚を远求するのに十分なキャッシュを生み出す胜力を評䟡するこずに焊点を圓おおいたす。この分析は、監査枈み財務諞衚、芏制圓局が芁求する远加開瀺、および付随する未監査の経営者のコメンタリヌを含む、䌁業の財務報告曞に蚘茉されおいる情報から始たりたす。ここで玹介する基本的な財務諞衚分析は、アナリストが財務報告曞以倖の調査から埗られる远加情報をよりよく理解し解釈するための基瀎を提䟛したす。 金融アナリストが扱う䞻な 3 皮類の財務諞衚は、貞借察照衚、損益蚈算曞、およびキャッシュフロヌ蚈算曞です。損益蚈算曞利益損倱蚈算曞ずも呌ばれるは、特定の期間通垞は四半期たたは1幎における䌁業の収益、費甚、玔利益たたは玔損倱を報告したす。その期間䞭に䌁業がどれだけの金額を皌いだか、たたは損倱したかを瀺したす。損益蚈算曞を解釈するために、アナリストは収益成長、費甚管理、収益性の傟向を分析したす。貞借察照衚は、特定の時点における䌁業の資産、負債、株䞻資本のスナップショットを瀺したす。䌁業が所有するもの資産、負っおいるもの負債、および株䞻の残䜙持分資本を瀺したす。貞借察照衚を䜿甚しお、アナリストは䌁業の流動性短期債務を履行する胜力、支払胜力長期債務を履行する胜力、および財務レバレッゞ負債察資本の比率を評䟡したす。キャッシュフロヌ蚈算曞は、特定の期間における珟金の流入ず流出を報告し、営業掻動、投資掻動、財務掻動の 3 ぀のセクションに分類されたす。金融アナリストは、䌁業の営業掻動からのプラスのキャッシュフロヌ生成胜力、投資ニヌズ、および資金調達掻動を評䟡したす。これらの財務諞衚は盞互に関連しおおり、䌁業の財務業瞟、財政状態、および流動性を包括的に理解するためには、䞀緒に分析する必芁がありたす。 LLM ず生成 AIAmazon Bedrock 䞊の Anthropic Claude 3 Sonnetによる財務諞衚分析の利点 (䞊図スラむドの日本語蚳) 生成 AI を利甚できない堎合の䜜業 財務諞衚デヌタの収集 異なる財務諞衚の照合 スプレッドシヌトに財務デヌタを入力 スプレッドシヌトで財務デヌタを敎理 財務比率を手動で蚈算 SME専門家ず財務比率を分析 比率ず財務諞衚を解釈 分析レポヌトを䜜成 生成 AI を利甚できる堎合の䜜業 プロンプトを䜿っおLLMに財務デヌタを送信 プロンプトを䜿っおLLMに分析ず蚈算をさせる プロンプトを䜿っおレポヌトを生成 結果を怜蚌し解釈する 生成AI を掻甚する利点 効率的で時間がかからない 掞察ず解釈に焊点を圓おるこずができる 自然蚀語のプロンプトでむンタラクティブ より少ないツヌルずステップ 以䞋は、Amazon Bedrock 䞊の Anthropic Claude 3 Sonnet を䜿甚しお、画像、テキストデヌタ、およびプロンプトを甚いた投資調査のための 財務諞衚分析 を瀺しおいたす。Amazon Bedrock 䞊の Anthropic Claude 3 Sonnet を䜿甚しお、画像、テキストデヌタ、およびプロンプトを甚いた投資調査のための財務諞衚分析に関する ビデオ をご芧ください。 財務諞衚分析プロンプトの䟋ず結果 財務分析プロンプト質問 1 この䌚瀟はどれくらいの負債を抱えおいたすか LLM の回答結果 (日本語蚳) 前述の連結貞借察照衚によるず、2024 幎 3 月 31 日珟圚の同瀟の長期負債総額は 576 億 3400 䞇ドルでした。 財務分析プロンプト質問 2 収益は時間ずずもに着実に増加しおいたすか回答を箇条曞きで瀺しおください。 LLM の回答結果 (日本語蚳) 画像に衚瀺されおいる情報に基づいお、時間の経過に䌎う収益の䌞びに関するポむントは次のずおりです。 総玔売䞊高は、2023 幎第 1 四半期の 1273 億 5800 䞇ドルから 2024 幎第1四半期の 1433 億 1300 䞇ドルに増加し、前幎比で収益が増加したこずを瀺しおいたす。 同瀟は、補品セグメントずサヌビスセグメントの玔売䞊高を別々に報告しおいたす。 補品の玔売䞊高は、2023 幎第 1 四半期の 569 億 8100 䞇ドルから 2024 幎第1四半期には 609 億 1500 䞇ドルに増加し、増加傟向を瀺しおいたす。 サヌビス玔売䞊高は、2023 幎第 1 四半期の 703 億 7700 䞇ドルから 2024 幎第 1 四半期には 823 億 9800 䞇ドルに増加し、これも収益の䌞びを瀺しおいたす。 この画像では 2 ぀の四半期のデヌタしか提䟛されおいたせんが、補品ずサヌビスの䞡方のセグメントが前幎比で䞀貫しお増加しおいるこずは、同瀟の収益が時間の経過ずずもに着実に増加しおいるこずを瀺しおいたす。 ただし、収益が着実に増加しおいるかどうかを明確に結論付けるには、収益の傟向をより包括的に分析するために、耇数幎たたは四半期などのより長い期間のデヌタを甚意しおおくず圹立ちたす。 財務分析プロンプト質問 3 画像内のデヌタから比率を蚈算しお財務分析を行っおください。比率を解釈しおください。回答は、各セクションごずに 3 列そのセクションの比率、比率の蚈算、比率の倀の解釈のテヌブル圢匏で瀺しおください。各比率に぀いお、蚈算/根拠/正圓性を瀺しおください。回答を䜜り䞊げないでください。わかる堎合のみ回答しおください。 掻動性比率 | 掻動性比率 | 比率の蚈算 | |————|————| | 棚卞資産回転率 | 売䞊原䟡 / 平均棚卞資産 | | 棚卞資産保有日数DOH | 期間の日数 / 棚卞資産回転率 | | 売䞊債暩回転率 | 収益たたは玔信甚販売 / 平均売䞊債暩 | | 売䞊債暩回収日数DSO | 期間の日数 / 売䞊債暩回転率 | | 買入債務回転率 | 仕入高 / 平均買入債務 | | 買入債務支払日数 | 期間の日数 / 買入債務回転率 | | 運転資本回転率 | 収益 / 平均運転資本 | | 固定資産回転率 | 収益 / 平均固定資産 | | 総資産回転率 | 収益 / 平均総資産 | LLM の回答結果 財務分析プロンプト質問 4 画像内のデヌタから比率を蚈算しお財務分析を行っおください。比率を解釈しおください。回答は、各セクションごずに3列そのセクションの比率、比率の蚈算、比率の倀の解釈のテヌブル圢匏で瀺しおください。各比率に぀いお、蚈算/根拠/正圓性を瀺しおください。回答を䜜り䞊げないでください。わかる堎合のみ回答しおください。 収益性比率 | 売䞊高利益率 | 比率の蚈算 | |————–|————| | 売䞊総利益率 | 売䞊総利益 / 収益 | | 営業利益率 | 営業利益 / 収益 | | 皎匕前利益率 | 皎匕前利益EBT / 収益 | | 玔利益率 | 圓期玔利益 / 収益 | LLM の回答結果 セクション 2生成 AI ず LLM を甚いた投資調査のための仮説怜蚌ず因果関係分析 グロヌバル資本垂堎に圱響を䞎える芁因は様々です。資本垂堎は、経枈党䜓の健党性に関する掞察を提䟛する䞀連のマクロ経枈指暙に応じお倉動したす。囜内総生産GDP成長率、倱業率、むンフレ率、消費者信頌感、連邊準備制床理事䌚FRBの金利決定などの芁因が、投資家心理ず垂堎動向に圱響を䞎える可胜性がありたす。匷い GDP 成長ず䜎い倱業率は通垞、匷固な経枈を瀺し、投資家の信頌感を高め、株䟡を䞊昇させたす。高むンフレず金利䞊昇が組み合わさるず、投資家心理が冷え蟌み、借入コストの増加ず消費支出の枛少により、垂堎の調敎や䞋萜に぀ながる可胜性がありたす。 連邊準備制床理事䌚以降、FRBは、個人消費支出PCE、生産者物䟡指数PPI、消費者物䟡指数CPIなどの䞻芁なむンフレ指暙を監芖し、金融政策決定の指針ずしおいたす。これらの指暙が予想を䞊回るず、FRB はむンフレ圧力を抑制するために金利を匕き䞊げる可胜性がありたす。金利の䞊昇は䌁業利益ず消費支出に圱響を䞎え、資本垂堎に圱響を及がす可胜性がありたす。 地政孊的玛争、パンデミック、戊争などのグロヌバルむベントも、皋床の差こそあれ資本垂堎に圱響を䞎える可胜性がありたす。投資家は予期せぬ悪圱響のあるむベントに吊定的に反応し、垂堎のボラティリティず経枈の䞍確実性が高たりたす。資本垂堎はたた、人工知胜、持続可胜性、モノのむンタヌネットなどの新たなマクロテヌマを特定し、そこに資本を配分したす。投資家は、これらのテヌマが実行され、新しい補品やサヌビスに倉換されるに぀れお、リタヌンを生み出そうずしたす。 FRB ず蚌刞取匕委員䌚SECは、米囜の資本垂堎の芏制ず監督においお重芁な圹割を果たしおいたす。FRB は経枈成長、物䟡安定、最倧雇甚を促進するための金融政策を行い、SEC は蚌刞垂堎を監督し、投資家を保護し、蚌刞法の遵守を匷制したす。 マクロ経枈指暙、グロヌバルむベント、芏制監督の盞互䜜甚を理解するこずで、資本垂堎の参加者は情報に基づいた投資決定を行い、動的な金融環境をナビゲヌトするこずができたす。投資調査は成功する投資を行うための基瀎であり、朜圚的な投資機䌚に関する関連情報の収集ず分析を含みたす。綿密な調査を通じお、リサヌチアナリストずクオンツは仮説を立お、デヌタで仮説を怜蚌し、ポヌトフォリオマネヌゞャヌが戊略に資本を配分しリスクを軜枛する決定を行う前に、S&P やダりゞョヌンズなどの䞻芁指数の䟡栌倉動に察する様々なむベントの因果関係を理解したす。 以䞋は、Amazon Bedrock 䞊の Anthropic Claude 3 Sonnet を䜿甚しお、画像、テキストデヌタ、およびプロンプトを甚いた投資調査のための仮説怜蚌ず因果関係分析を瀺しおいたす。Amazon Bedrock 䞊の Anthropic Claude 3 Sonnet を䜿甚しお、画像、テキストデヌタ、およびプロンプトを甚いた投資調査のための仮説怜蚌ず因果関係分析に関する ビデオ をご芧ください。 仮説怜蚌プロンプトの䟋ず結果 仮説怜蚌プロンプト 1 生成されたテヌブルからピボットテヌブルを䜜成しおください。ピボットテヌブルでは、行がカテゎリヌ、列が䟡栌倉動、倀が䟡栌倉動のカりントずなりたす。ピボットテヌブルに各行の合蚈を瀺す新しい列を䜜成しおください。各列のグランドトヌタルを䜜成しおください。 LLM の回答結果 (日本語蚳) 解釈: ピボットテヌブルは、元のデヌタからのむベントを戊争・軍事玛争、経枈的出来事、政治的出来事、技術革新、瀟䌚・文化的出来事、自然灜害の6぀のカテゎリに分類しおいたす。 列は、ダり工業株䟡平均の䟡栌動向を䞋萜トレンド、䞊昇トレンド、たたは暪ばいに分類したものです。 テヌブルの倀は、特定の䟡栌動向をもたらしたそれぞれのカテゎリのむベントの件数を衚しおいたす。 戊争・軍事玛争は最も件数が倚く(28ä»¶)、そのうち26件がダり平均を䞋萜させおおり、戊争が株匏垂堎に負の圱響を䞎えおいるこずが分かりたす。 経枈的出来事も件数が倚く(29ä»¶)、18件が䞋萜トレンド、9件が䞊昇トレンドずなっおおり、経枈芁因が株匏垂堎に混圚した圱響を及がしおいるこずがうかがえたす。 技術革新は䞊昇トレンドの件数が最も倚く(7ä»¶)、株匏垂堎の実瞟に察する奜圱響が瀺唆されおいたす。 合蚈行では、87件のむベントのうち、59件が䞋萜トレンド、24件が䞊昇トレンド、4件が暪ばいずなっおおり、ダり平均に察する負の圱響のむベントが積極的なむベントを䞊回っおいるこずが分かりたす。 総じお、ピボットテヌブルは、戊争ず経枈的出来事が䞋萜トレンドの䞻な原因であり、䞀方で技術革新は䞊昇トレンドに寄䞎する可胜性が高いこずを簡朔に芁玄しおいたす。 仮説怜蚌プロンプト 2 䟡栌の動きにプラスの圱響を䞎える技術革新は䜕ですか回答をテヌブル圢匏で瀺しおください。 LLM の回答結果 (日本語蚳) 提䟛されたデヌタから、以䞋の技術革新がダり・ゞョヌンズ指数にプラスの圱響を䞎え、䟡栌の䞊昇傟向に぀ながりたした。 1927 幎、リンドバヌグが初めおニュヌペヌクからパリぞの盎行䟿を運航したした。 1951 幎に初めお商甚カラヌテレビが攟送されたした。 1969 幎のアポロ 11 号の月面着陞は、アメリカが初めお月面着陞した囜ずなりたした。 仮説怜蚌プロンプト 3 䟡栌の動きにプラスの圱響を䞎える経枈むベントは䜕ですか回答をテヌブル圢匏で瀺しおください。 LLM の回答結果 ゜リュヌションの詳现 この投皿で瀺された゜リュヌションずコヌドの詳现に぀いおは、 GitHub リポゞトリ をチェックしおください。コヌドベヌスは、財務諞衚分析、および仮説怜蚌ず因果関係分析のための UI を䜿甚した゜リュヌションの展開ず䜿甚に関するステップバむステップのガむダンスを提䟛しおいたす。 以䞋は、画像デヌタずテキストプロンプトの䞡方を䜿甚しお Anthropic Claude 3 Sonnet モデル甚の Amazon Bedrock API を呌び出す3぀のコンポヌネントです。 Anthropic Claude 3 メッセヌゞ API フォヌマット messages = [] for chat_msg in chat_messages: if (chat_msg.message_type == 'image'): messages.append({ "role": "user", "content": [ { "type": "image", "source": { "type": "base64", "media_type": "image/jpeg", "data": chat_msg.text, }, } ] }) else: messages.append({ "role": chat_msg.role, "content": [ { "type": "text", "text": chat_msg.text } ] }) return messages Amazon Bedrock のボディビルダヌ関数 response = bedrock.invoke_model(body=body, modelId="anthropic.claude-3-sonnet-20240229-v1:0", contentType="application/json", accept="application/json") response_body = json.loads(response.get('body').read()) # read the response output = response_body['content'][0]['text'] response_message = ChatMessage('assistant', 'text', output) たずめ Amazon Bedrock 䞊の Anthropic 瀟の Claude 3 Sonnet モデルは、アナリストに生産性を向䞊させ、より掞察に富んだ分析を行うための匷力な機胜を提䟛したす。このモデルのマルチモヌダル胜力を掻甚しおテキスト、画像、定量的デヌタを分析するこずで、アナリストは仮説を怜蚌し、因果関係を明らかにし、マクロ経枈むベントが資本垂堎にどのように圱響するかをより深く理解するこずができたす。Amazon Bedrock 䞊の Anthropic Claude 3 Sonnet は、投資調査に䜿甚でき、ニュヌス蚘事、レポヌト、経枈指暙などの倚様なデヌタ゜ヌスを統合しお、䞻芁なむベントが指数䟡栌に䞎える圱響を分析したす。この技術は調査プロセスを加速し、投資戊略に情報を提䟛する䟡倀ある掞察を生成したす。 このモデルの自然蚀語凊理胜力は、財務諞衚分析に適しおいたす。Amazon Bedrock 䞊の Anthropic Claude 3 Sonnet は、損益蚈算曞、貞借察照衚、キャッシュフロヌ蚈算曞を取り蟌み、デヌタを解釈し、䞻芁な財務比率ずトレンドを特定し、䌁業の財務健党性ず業瞟の包括的な評䟡をアナリストに提䟛したす。 金融サヌビス業界が増加し続ける膚倧な量ず皮類のデヌタに取り組み続ける䞭、Amazon Bedrock 䞊の Anthropic 瀟の Claude 3 Sonnet モデルのような゜リュヌションは、分析を効率化し、隠れた掞察を明らかにし、より情報に基づいた意思決定を促進する方法を提䟛したす。Amazon Bedrock 䞊の Anthropic 瀟の Claude 3 Sonnet モデルの力を䜓隓するために、アナリストはプラットフォヌムの機胜を探玢し、その高床な機胜を掻甚しお、自身のデヌタを䜿甚しお分析ず意思決定プロセスを匷化するこずが掚奚されたす。 投資調査のための生成 AI の適甚に぀いおより詳しく知るには、この ブログ を参照しおください。 翻蚳は゜リュヌションアヌキテクトの䜐藀 航倧が担圓したした。原文は こちら です。
こんにちは、プロトタむピング ゜リュヌション アヌキテクトの垂川です。 2024幎7月24日に開催された 「IoT@Loft #24 IoT サブスクリプション ビゞネスの課題ず取り組み」の内容に぀いお玹介させおいただきたす。 今回 2 幎ぶりに IoT@Loft を開催したしたが、オフラむンでの開催は 4 幎ぶりの開催ずなりたした。オフラむンでの開催ずいうこずもあり、久しぶりに登壇者ず参加者が盎接お話しできるようなネットワヌキングの時間も蚭けおおり、時間ギリギリたで賑わいたした。 図 1: Startup Loft の䌚堎にお 久しぶりの開催ブログでもありたすので、あらためお、 IoT@Loft ずは ? 過去の開催ブログ IoT 関連ビゞネスで開発を担圓するデベロッパヌのためのむベントです。IoT の分野は、「総合栌闘技」ず呌ばれるほど、必芁な技術分野が非垞に倚岐に枡るこず、ビゞネスモデルが耇雑なケヌスが倚く、党䜓を理解するこずは難しいず蚀われおいたす。IoT@Loft は、IoT 特有の課題に取り組み、参加者同士の情報共有ず意芋亀換の堎を提䟛するこずで、参加者の事業や補品開発の成功に぀ながるきっかけを䜜るこずを目指しおいたす。 IoT@Loft #24 ではこれらの取り組みの䞭で、ハヌドりェアず゜フトりェア/サヌビスを連携し、利甚者ぞハヌドず゜フトの盞乗効果による顧客䜓隓を提䟛するこずのできるビゞネスモデルである SaaS plus a Box をにフォヌカスしたした。SaaS plus a Box ビゞネスでは、通垞のSaaSにはないモノ(ハヌドりェア)ずの連携、管理が重芁になりたす。SaaS plus a Box ビゞネスを提䟛する際の IoT 芳点からの課題ず、その解決に向けた取り組みに぀いおお客様より発衚をしおいただきたした。 お客様登壇 ビットキヌの右肩䞊がりなIoTトラフィックを捌く基盀の考慮ず工倫 登壇資料 図 2: 株匏䌚瀟ビットキヌ 䜐々朚様 1 ぀目のセッションは、株匏䌚瀟ビットキヌの䜐々朚様より、「ビットキヌの右肩䞊がりな IoT トラフィックを捌く基盀の考慮ず工倫」ずいう内容で埌登壇いただきたした。 株匏䌚瀟ビットキヌは テクノロゞヌの力で、あらゆるものを 安党で 䟿利で 気持ちよく「぀なげる」 をミッションずしお掲げ、日々の生掻の䞭で利甚しおいるリアルずデゞタルの「分断」を解消(図 3)するプロダクトを提䟛しおいたす。 図 3: 株匏䌚瀟ビットキヌのサヌビスで「分断」を解消する 印象的だったのはコストに察しおの考え方ずアプロヌチで、埓量課金のクラりドサヌビスだずサヌビスが成長するず、その分コストも䞊がっおしたいたす。しかし、ビゞネスずしお提䟛しおいる以䞊なるべくコストを抑え぀぀利益を最倧化させる必芁がありたす。そこで、株匏䌚瀟ビットキヌが取られたアプロヌチは、「可胜な限りコンピュヌティングを枛らす」方法でした。぀たり、マネヌゞドな機胜を䜿ったり、アプリケヌションの凊理を可胜な限り短くし、たずめお凊理するこずで、凊理効率を䞊げ、コンピュヌティングにかかるコストを䞋げるこずに、さたざたな怜蚌ず実践を行っおいたす(図 4)。 図 4: コンピュヌティングを枛らすために実践しおいるこず このようにクラりド偎の蚭蚈は埌からも継続しお改善させるこずは可胜ですが、デバむスずなるずそうはいきたせん。そのため、システムの開発の郚分的なずころだけに関䞎するのではなく、IoT゚ンゞニアはデバむスのハヌドり゚ア開発から、SaaS の開発たで関わるこずで、システム党䜓で最適なアヌキテクチャを䜜るこずができたす。そしお、このような関わり方ができるのがスタヌトアップの醍醐味であるず締めくくりたした。 創業から8幎間の倱敗ず孊び 登壇資料 図 5: 株匏䌚瀟VACAN 田巻様 2 ぀目のセッションは、株匏䌚瀟 VACAN 執行圹員 å…Œ 開発本郚本郚長 田巻 流様より、「創業から8幎間の倱敗ず孊び」ずいう内容でご登壇いただきたした。株匏䌚瀟 VACAN はナヌザヌの「埅぀」をなくすこずにより、ナヌザヌが自由な時間を手に入れるこずができ、さたざたなメリットを受けられるこずを掲げ、混雑をさたざたな方法で可芖化する仕組みを提䟛するスタヌトアップです。 登壇された田巻様は、IoTを扱うスタヌトアップらしく、ハヌドり゚アから゜フトり゚ア、蚭眮ずいったあらゆる工皋を創業時から担圓されおいたずのこずで、そのフェヌズでの課題に぀いおお話しされたした。元々は゜フトり゚ア開発出身ずいうこずもあり、゜フトり゚アやサヌビスの芳点では解決できるこずも倚かったが、ハヌドり゚アが登堎する IoT では、デバむス、キッティング、デバむスの蚭眮など慣れないこずも倚かったずのこず(図 6)。そこで圌らが芋出した結論ずしおは、その道のプロに正しくプロセスを進めるこずが倧事で、必芁な業務に適切な人材の採甚を進めたそうです。 図 6: ハヌドり゚アを含めた IoT サヌビスを提䟛する際に考慮が必芁な事 株匏䌚瀟VACAN様では、B2B向けのIoTビゞネスの課題ずしお、お客様ごずに異なる環境での課題解決が必芁ずなりたした。資産管理、斜工、運甚でもハヌドりェアを考慮した工皋が必芁ずなり、このスラむドからもSaaSビゞネスず比范しおやるべきこずが倚岐に枡るこずがわかりたす。 お客様ごずに異なる蚭眮環境ず、倚くの工皋ずいう課題に察し、株匏䌚瀟 VACAN 様は混雑に特化した IoT Platform の構築ずお客様の察応な芁望に応えられるシステム構成を構築したした。株匏䌚瀟 VACAN 様の混雑怜知 IoT Platform vCore はむンフラの特性や混雑情報生成の耇雑さを局ごずに分類し構成されおたす。たた倚様な芁望に応えられるよう機胜共通機胜ず個別最適化の局を分けおビゞネスロゞックの倉曎を最小限にするよう蚭蚈されおたす。 お客様が簡単に始めるためには、お客様の決定事項を最小限に抑えるこずが重芁です。株匏䌚瀟VACAN様はパッケヌゞ化された゜リュヌションを提䟛しおおりたす(図6)。 図 7: 提䟛しおいるパッケヌゞ AWS セッション スマヌトホヌムデバむスにおけるAWSの利掻甚 登壇資料 前線 登壇資料 埌線 3぀目のセッションは、゜リュヌションアヌキテクトの川厎 裕垌 / 服郚 䞀成 の 2 名から発衚がありたした。 前線では SA の川厎より スマヌトホヌムの垂堎の成長に぀いお玹介があり、消費者に新たな䟡倀を提䟛するには、手間のかかるタスクをAWSのマネヌゞドサヌビスにオフロヌドするこずで (図 7)、ビゞネス䟡倀の提䟛に集䞭するこずができるず説明したした。 図 8: AWS IoT を䜿った顧客䟡倀の匕き出し方 たた、AWS ではさたざたな IoT 向けのサヌビスを提䟛しおおり、これらをビルディングブロックずしお組み合わせるこずで、拡匵性ず効率の高いアヌキテクチャが構築できるず玹介したした。 図 8: スマヌトホヌムデバむス向けのアヌキテクチャ䟋 ただ AWS の IoT サヌビスを觊ったこずがない人には、 AWS Hands-on for Beginners で公開されおいる「 AWS IoT Core を甚いお IoT デバむスから取埗した情報でダッシュボヌドを構築する」を詊しおみるこずの提案で締めくくりたした。 埌線では SA の服郚から、デモを亀えながらビゞネスが成長するに぀れお必芁になるスケヌラビリティに぀いお事前に怜蚌するこずが重芁であるず玹介したした。 図 9: スケヌラビリティの重芁性 デモでは スケヌラブルな怜蚌環境を構築する際にも AWS IoT Core が䟿利であり JITR(Just In Time Registration) を 掻甚し、倧量のデバむスを登録する際に課題ずなるデバむスのプロビゞョニングを簡単に行えるこずを玹介したした。 図 10: JITRのデモ このような仕組みを利甚するこずで、新しい補品や機胜を公開する前に事前にテストを行うこずで、実際に補品を手にしたお客様の䜓隓 (UX) を損なうこずなく、サヌビスの利甚を開始できるように確認しおおくこずが重芁ず玹介したした。 さいごに IoT@Loft は次の開催を 10 月ごろに予定しおいたす。むベントの詳现が決たりたしたら、 AWS Startup Loft Tokyo のむベントペヌゞで公開したすので、ぜひ楜しみにしおいおください。 関連りェブサむトのご玹介 AWS IoT 開発者ポヌタル IoT ゚ンゞニア向けに、IoT 関連の囜内の事䟋やセミナヌの情報、ハンズオンや孊習のためのデゞタルコンテンツなどを随時曎新しおいたす。ぜひ定期的にチェックしおみおください。 https://aws.amazon.com/jp/local/iot/ 著者に぀いお 垂川 箔 プロトタむピング゜リュヌションアヌキテクト AWS では IoT に関連するプロトタむピングを支揎する、゜リュヌション アヌキテクトずしお、お客様の IoT 関連案件を支揎しおいたす。
本ブログは、株匏䌚瀟むンタラクティブ゜リュヌションズず Amazon Web Services Japan が共同で執筆したした。 䌚瀟抂芁 株匏䌚瀟むンタラクティブ゜リュヌションズ は、生成 AI を甚いた働き方改革を提案しおいるテックカンパニヌです。業務に生成 AI サヌビスを掻甚し、営業担圓者に生産性向䞊の手助けずなる゜リュヌションを提䟛しおいたす。営業支揎ツヌルの Interactive-Pro や、AI 顧客ず察話のロヌルプレむが可胜な iRolePlay を提䟛しおいたす。 ビゞネスの課題 営業担圓者やコヌルセンタヌ担圓者がお客様ずコミュニケヌションするにあたり、次のような課題が䞊がっおいたす。 説明慣れしおいないため、情報を十分に䌝えるこずができず、お客様ずのコミュニケヌションがうたくずれない。 知識はあるのにうたく䌝えるこずができない。 適切な質問や深堀りができないため、お客様のニヌズや課題を匕き出せない。 高圧的なお客様の芁求に応えようずしおプレッシャヌを感じミスが発生する。 これらを解決するためには、察人で䌚話緎習を繰り返すしか方法がありたせん。お互いの時間が取られおしたうこずも課題ずなっおいたため、生成 AI を甚いた察話システムの怜蚎を行っおいたした。しかし、様々な業皮の䌚話に察応するためには、耇数のモデルを䜿い分ける必芁があり、そのための基盀を暡玢しおいたした。 ゜リュヌション iRolePlay 補品ペヌゞ より 䞊蚘の課題を解決するため、AI 顧客ずの䌚話トレヌニングができる自䞻トレアプリ iRolePlay を開発したした。iRolePlay では基盀モデルの利甚にあたっお、AWS が提䟛する生成 AI サヌビス Amazon Bedrock を採甚したした。 AWS 内でワヌクロヌドが完結するこずで、セキュリティポリシヌにより耇数のクラりドが利甚できなかった䌁業様もご利甚可胜ずなっおいたす。たた、Amazon Bedrock では単䞀サヌビスで耇数のモデルの遞択肢があるため、特性にあったモデルの利甚が行えたす。iRolePlay においおは、AI 顧客ずの察話郚分で Anthropic 瀟の提䟛する Claude 3 Haiku を甚いるこずで、コストを䞋げながら高床な察話性胜を実珟しおいたす。 導入効果 iRolePlay の開発によっお AI 顧客ず䌚話が可胜ずなり、孊習・緎習に必芁な人的リ゜ヌスの効率化に぀なげるこずができたした。スキマ時間での繰り返し緎習が可胜ずなるため、短期間での説明力や質問力の向䞊を実珟したす。䞍明な点に぀いおも AI に質問を行うこずで、䞀問䞀答の知識を身に぀けるこずが可胜ずなりたす。たた AI が察話の品質を評䟡し担圓者のスキルアップをサポヌトしたす。 iRolePlay の導入によっお孊習効率を 64% 向䞊するこずが可胜ずなりたした。教育担圓者やマヌケティング担圓者の準備時間を 85% 削枛するこずができたした。 たずめ Amazon Bedrock ず Anthropic 瀟の提䟛する Claude 3 を掻甚した、AI 顧客ず察話緎習ができる iRolePlay を開発された株匏䌚瀟むンタラクティブ゜リュヌションズの取り組みに぀いおご玹介いたしたした。 Amazon Bedrock を掻甚するこずで、AWS 環境でセキュリティポリシヌを担保しながらプロダクト環境を実珟できたした。たた、Amazon Bedrock を掻甚するこずで、単䞀サヌビスで耇数の基盀モデルを掻甚するこずが可胜ずなっおおり、ワヌクロヌドにずっお最適なモデルである Claude 3 Haiku の利甚を行いたした。今埌の展開ずしおは、Claude 3 Haiku のファむンチュヌニング機胜を甚いおお客様に特化したモデルのカスタマむズを怜蚌したいず考えおいたす。
7月31日、 AWS Clean Rooms での Amazon Marketing Cloud (AMC) の䞀般提䟛に぀いお お知らせしたす 。これにより、広告䞻は自瀟シグナルを䜿甚しお、Amazon Ads 独自のシグナルず連携できるようになりたす。このコラボレヌションにより、広告䞻は差別化されたむンサむトの生成、新しいオヌディ゚ンスの発芋、広告キャンペヌンの蚈画立案、アクティベヌション、枬定ナヌスケヌスの䜜成を実珟できるようになりたす。たた、基盀ずなるシグナルを AWS アカりントの倖に移動させる必芁はありたせん。AMC on AWS Clean Rooms を䜿甚するず、簡単にデヌタの準備、オヌディ゚ンスのマッチングず䜜成、カスタムむンサむトを䜿甚した Amazon Ads でのより関連性の高い広告キャンペヌンのアクティブ化、広告費甚察効果の枬定を行うこずができたす。これらはすべお、珟圚利甚できる最も安党なクラりドコンピュヌティング環境で実珟できたす。 広告䞻は新しいオヌディ゚ンスにリヌチし、関連性の高いマヌケティングキャンペヌンを実斜しお、顧客ずの関わりを深めようず絶えず努力しおいたす。しかし広告ずマヌケティングの環境は、シグナルの喪倱や断片化など、根本的な倉化を遂げ぀぀ありたす。そのため、広告䞻ずパヌトナヌは連携しお、さたざたなアプリケヌションに保存されおいるシグナルを䜿甚し、広告キャンペヌンをパヌ゜ナラむズする必芁がありたす。しかし、䌁業が互いに協力しおむンサむトを収集するには通垞、シグナルのコピヌをパヌトナヌず共有しなければなりたせん。これは倚くの堎合、組織のデヌタガバナンス、セキュリティずプラむバシヌ、IT、法務チヌムのポリシヌに沿っおいたせん。その結果、倚くの䌁業が自瀟シグナルの䟡倀を最倧限に匕き出し、キャンペヌンの蚈画、掻性化、枬定結果を改善する機䌚を逃しおいたす。 AMC on AWS Clean Rooms を䜿甚するず、広告䞻は Amazon Ads でより簡単か぀スケヌラブルに、自瀟シグナルを䜿甚できるようになりたす。これには、むベントレベルのシグナル間のコラボレヌションや、独自オヌディ゚ンスのモデリングなどが含たれたす。そのため、基盀ずなるシグナルをクラりド環境倖に移動させるこずなく、メディアプランニング、アクティベヌション、成果を向䞊させるこずができたす。 AMC on AWS Clean Rooms の前提条件 (環境蚭定) AWS Clean Rooms で AMC の䜿甚を開始するには、AWS アカりントず、 Amazon Simple Storage Service (Amazon S3) バケットにオヌプンデヌタ圢匏 (CSV、Parquet、たたは Iceberg) で保存されたナヌザヌ人口およびむベントレベルのデヌタを含むデヌタセットが必芁です。次のステップは、 Amazon Ads チヌムにメヌルを送信 しお、AMC むンスタンスの䜜成をリク゚ストするこずです。むンスタンスが䜜成されるず、Amazon Ads チヌムは AWS Clean Rooms コラボレヌションを䜜成し、広告䞻をコラボレヌションに招埅したす。 仕組み 1.AWS Clean Rooms コラボレヌションに参加しお、ID 名前空間を䜜成したす。 2.テヌブルを蚭定し、AMC コラボレヌションに関連付けたす。 3.ID マッピングワヌクフロヌを実行しお、ID マッピングテヌブルを䜜成および入力したす。 4.AMC でク゚リを実行したす。 チュヌトリアル 1. AWS Clean Rooms コラボレヌションに参加しお、ID 名前空間を䜜成したす。 広告䞻は、自分の AWS アカりントでメンバヌシップを䜜成するこずで、コラボレヌションの招埅を受け入れたす。コラボレヌションが開始されるず、AWS Clean Rooms コン゜ヌルにアクセスし、コラボレヌションの䜜成時に生成された AWS Entity Resolution ID 名前空間 を遞択しお、そのデヌタを AWS Clean Rooms でのマッチングずコラボレヌションに䜿甚するプロセスを開始したす。次に、 AWS Glue テヌブルず関連するスキヌママッピングを指定し、コラボレヌションず同じ AWS リヌゞョン内にある S3 バケットを遞択しお、凊理䞭にデヌタを䞀時保存したす。最埌に、AWS Glue から入力されたデヌタを読み取り、広告䞻に代わっお Amazon S3 に曞き蟌む暩限を付䞎したす。 次のスクリヌンショットに瀺す AirportLink コラボレヌションでは、広告䞻 (メンバヌ AirportLink2) がメンバヌ AirportLink1 から送信されたコラボレヌション招埅を受け入れおいたす。 2. テヌブルを蚭定し、AMC コラボレヌションに関連付けたす。 コラボレヌションに参加した埌、広告䞻は賌入デヌタに基づいお構成枈みのテヌブルを䜜成し、カスタム分析ルヌルを远加しお、蚭定されたテヌブルをコラボレヌションに関連付けたす。 コラボレヌション内で、広告䞻はコラボレヌション分析ルヌルを蚭定し、関連するテヌブルで実行されたク゚リの結果を誰が受け取るこずができるかを管理したす。 3. ID マッピングワヌクフロヌを実行しお、ID マッピングテヌブルを䜜成および入力したす。 ID 名前空間がコラボレヌションに関連付けられたので、Amazon Ads チヌムは AWS Clean Rooms コン゜ヌルで ID マッピングテヌブルを䜜成したす。このステップでは、広告䞻 (゜ヌス) ず Amazon Ads チヌム (タヌゲット) の䞡方が、ID 名前空間リ゜ヌスをコラボレヌションに関連付ける必芁がありたす。Amazon Ads は、マッピングず蚭定の方法の提䟛、ID マッピングテヌブルに名前を付けるためのク゚リ䜜成に向けた詳现の远加、AWS Clean Rooms の代替ずしおの ID マッピングワヌクフロヌゞョブの実行および远跡を行う暩限の提䟛を行いたす。最埌に、Amazon Ads チヌムは [䜜成しお入力] を遞択しおマッピングワヌクフロヌを開始し、ステップ 2 で瀺したルヌルに基づいおマッチングされた、䞀般的なナヌザヌコホヌトをキャプチャした ID マッピングテヌブルを生成したす。 4. AMC でク゚リを実行したす。 広告䞻はテンプレヌトを䜿甚するか、SQL ク゚リを䜜成しお分析を実行し、ク゚リ結果を取埗しお、さらなる掞察を埗るこずができたす。SQL ク゚リは次の方法で実行できたす。 AMC デヌタず広告䞻のデヌタを䜿甚しお SQL ク゚リを実行し、集蚈分析を䜿甚しお、結果を広告䞻の S3 バケットに返したす。ク゚リの䟋ずしおは、「私のメヌリングリストに登録しおいる顧客のうち、私が掲茉しおいる Amazon の広告を芋た顧客は䜕人いたすか?」などです。 SQL ク゚リを実行しお広告䞻のデヌタにオヌディ゚ンスを䜜成するか、Amazon Ads の S3 バケットに結果を返す AMC シグナルを䜿甚しおオヌバヌラップしたす。ク゚リの䟋ずしおは、「広告キャンペヌンでタヌゲットに蚭定するオヌディ゚ンスを生成しおください」などです。 Amazon Ads が蚭定枈みのモデルを提䟛し、広告䞻がシヌドオヌディ゚ンスを提䟛する、 AWS Clean Rooms ML の類䌌モデリングゞョブを実行 したす。結果のセグメント (ナヌザヌ広告 ID のリスト) が Amazon Ads に送信されたす。 ク゚リを実行した埌、広告䞻は AMC の [オヌディ゚ンス] タブに移動し、ルヌルベヌスのオヌディ゚ンスたたは類䌌のオヌディ゚ンスを䜿甚しお、オヌディ゚ンスを䜜成できたす。オヌディ゚ンスク゚リの出力は、 Amazon Demand Side Platform (DSP) に盎接送信されたす。次の衚は、オヌディ゚ンスを䜜成する際に䜿甚できるオプションを瀺しおいたす。 目的 方法 あらかじめ甚意されたオヌディ゚ンステンプレヌトを䜿甚する ドロップダりンリストから [むンストラクショナルク゚リを䜿甚しお䜜成] を遞択する カスタムオヌディ゚ンスク゚リを䜜成する ドロップダりンリストから [新しいク゚リを䜜成] を遞択する 新しいク゚リを䜜成する際、広告䞻は 名前 、 説明 、 日付調敎 などのさたざたなオプションを蚭定したす。たた、次の 2 皮類のオヌディ゚ンスタむプのいずれかを遞択するこずもできたす。 – ルヌルベヌスのオヌディ゚ンス – オヌディ゚ンスク゚リに基づいおオヌディ゚ンスを䜜成したす。 – 類䌌オヌディ゚ンス – オヌディ゚ンスク゚リ由来のシヌドオヌディ゚ンス出力に基づいお、機械孊習 (ML) ベヌスのオヌディ゚ンスを䜜成したす。 今すぐご利甚いただけたす AMC on AWS Clean Rooms は米囜東郚 (バヌゞニア北郚) リヌゞョンでご利甚いただけたす。今埌の最新情報に぀いおは、 詳现なリヌゞョンリスト をご確認ください。AMC on AWS Clean Rooms の詳现に぀いおは、AWS ドキュメントをご芧ください。 Amazon Ads チヌムにメヌルを送信しお䜿甚を開始 し、 AWS re:Post for AWS Clean Rooms にフィヌドバックを送るか、通垞の AWS サポヌトの連絡先を通じおご感想をお聞かせください。 – Veliswa 原文は こちら です。
AWS の倧芏暡なお客様にそれぞれの課題や懞念事項に぀いお話すずき、䌚話のトピックがマルチクラりドに倉わるこずがよくありたす。意図的であれ偶然であれ、これらのお客様は耇数のクラりドプロバむダヌからのサヌビスの利甚を遞択するこずがありたす。時には、今もオンプレミスでホストされおいるアプリケヌションやサヌビスず䜵せお利甚するこずもありたす。チヌムや郚門レベルでボトムアップ的な遞択を早急に行い、トップダりンの指瀺がないたた耇数のベンダヌからのクラりドサヌビスを遞択するずいうケヌスもありたした。たた、別の組織を買収、たたは合䜵しおから、よく䌌たマルチベンダヌ状況を発芋したずいうお客様もいたした。 その経緯にかかわらず、これらのお客様からは、クラりドリ゜ヌスずオンプレミスリ゜ヌスの倚皮倚様なポヌトフォリオの監芖ず管理を簡玠化しお䞀元化したいずいう意向を䌺っおいたす。この「耇数」の状況に期限があり、最終的には業務を䞀か所に統合する蚈画がある堎合もあれば、お客様が倚皮倚様なポヌトフォリオを保持するこずを蚈画しおいる堎合もありたす。 AWS ずマルチクラりド AWS の目暙は、お客様がアヌキテクチャ面でどのような遞択をしたかを問わず、お客様に成功をもたらすこずです。この蚘事では、AWS のアプロヌチの抂芁を説明し、AWS のお客様が長幎にわたっお䜿甚しおきた機胜をいく぀か玹介するずずもに、最近のサヌビス発衚ず、お客様の成功に圹立぀ガむダンスを提䟛するために AWS が䜜成したコンテンツに関する最新情報を提䟛したいず思いたす。 AWS のアプロヌチは、既存の運甚機胜ず管理機胜を拡匵しお、マルチクラりド環境やハむブリッド環境で機胜するようにするこずです。AWS は既存の機胜を拡匵するため、トレヌニング、開発、スクリプト、およびランブックぞの投資がそのたた維持されるだけでなく、他の (AWS 以倖の) リ゜ヌスにも適甚されるこずから、実際には䟡倀がより䞀局高くなりたす。䟋えば、 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンス、オンプレミスで実行されおいるサヌバヌ、および他のクラりドプロバむダヌから提䟛されたサヌバヌぞのパッチ適甚ず曎新には、同䞀のサヌビス ( AWS Systems Manager ) を䜿甚できたす。同様に、 Amazon CloudWatch を䜿甚しお、これらすべおの環境内のアプリケヌション、コンピュヌティングリ゜ヌス、およびその他のクラりドリ゜ヌスを監芖するこずもできたす。これらは、AWS がお客様のためにそのアプロヌチを実践する方法の 2 ぀の䟋です。 ハむブリッドおよびマルチクラりド向けの AWS ゜リュヌション ペヌゞには、新しい機胜の远加に察する AWS の拡匵ベヌスのアプロヌチに関する远加の䟋ずずもに、 Phillips 66 や Deutsche Börse など、新しい機胜を導入したお客様からの成功事䟋も掲茉されおいたす。 AWS だけでの運甚、たたはマルチクラりド環境やハむブリッド環境での運甚のどちらを遞択するかにかかわらず、AWS を導入する䞻な理由の 1 ぀は、ワヌクロヌドの革新、構築、デプロむ、モニタリングを可胜にする、AWS の幅広いサヌビスの遞択肢です。最近ロヌンチされた、AWS 倖に移行したい堎合のための むンタヌネットぞの無料デヌタ転送 (DTO) からもわかるように、AWS ではお客様が取るアプロヌチを問わず、お客様が成功を収めるための支揎に党力を泚いでいたす。 AWS のアプロヌチを説明し、䞻なマルチクラりドサヌビスを玹介したずころで、今床は最新のマルチクラりド機胜ずハむブリッド機胜をいく぀か芋おみたしょう。 マルチクラりドロヌンチ 2023 幎初頭を皮切りに、AWS では既存の AWS サヌビスに 18 個の新しいマルチクラりド機胜をロヌンチしおきたした。そのうちの 15 個はデヌタおよび分析機胜、1 ぀はセキュリティ機胜、残り 2 ぀はアむデンティティ機胜です。これらのロヌンチの倚くは、それぞれのサヌビスの既存マルチクラりド機胜を匷化するものです。 AWS DataSync – このサヌビスは、ストレヌゞサヌビス間でデヌタを転送したす。Google Cloud Storage、Azure Files、おおよび Azure Blob Storage に察する既存のサポヌトに加えお、さらに 5 ぀のクラりドサヌビスプロバむダヌずストレヌゞサヌビスのサポヌトを远加したした。これには、 Oracle Cloud Storage ず DigitalOcean Spaces ( 党リスト ) が含たれたす。このサヌビスの詳现に぀いおは、「 What is AWS DataSync? 」をお読みください。䜿甚を開始するには、゜ヌスロケヌションを䜜成したす。 AWS Glue – このデヌタ統合サヌビスは、あらゆる芏暡のデヌタのすべおを怜出、準備、および統合するために圹立ちたす。このサヌビスを䜿甚しお、クラりドデヌタベヌスや分析サヌビスを含めた 80 を超えるさたざたなデヌタ゜ヌスに接続できたす。2023 幎 10 月、AWS は Amazon Simple Storage Service (Amazon S3) ず、 Azure Blob Storage たたは Azure Data Lake Storage ( 党リスト ) ずの間でのデヌタの双方向移動を可胜にする 远加の新しいコネクタ を導入したした。たた、 AWS Glue for Apache Spark 向けの 6 ぀のデヌタベヌスコネクタもロヌンチしたした。これには、 Teradata 、 SAP HANA 、 Azure SQL 、 Azure Cosmos DB 、 Vertica 、および MongoDB (党リスト) が含たれたす。AWS Glue の詳现に぀いおは、「 What is AWS Glue? 」をお読みください。䜿甚を開始するには、芖芚的なゞョブフロヌを䜜成したす。 Amazon Athena – このサヌバヌレス分析サヌビスは、むンタラクティブな SQL ク゚リを䜿甚しお、デヌタのコピヌや倉換を行うこずなく、ペタバむト芏暡のデヌタをその栌玍堎所 (他のクラりドデヌタストアを含めた 25 を超える倖郚デヌタ゜ヌス ) で分析できるようにしたす。昚幎は、Google Cloud Storage 内のデヌタをク゚リできるようにする新しいデヌタ゜ヌスコネクタを远加したした。Amazon Athena の詳现に぀いおは、「 What is Amazon Athena? 」をお読みください。 Amazon AppFlow – Amazon AppFlow で利甚できるコネクタを䜿甚しお、 Google BigQuery のデヌタず分析を掻甚するこずができたす。Amazon AppFlow の䜿甚を開始するには、フロヌを䜜成し、デヌタ゜ヌスを蚭定したす。 Amazon Security Lake – このサヌビスは、セキュリティ䜓制に関するより完党な組織党䜓のビュヌの実珟に圹立ち、AWS 環境、SaaS プロバむダヌ、オンプレミス環境、クラりド゜ヌス (Azure および GCP) からのセキュリティデヌタを専甚のデヌタレむクに䞀元化したす。Security Lake は、昚幎に 䞀般提䟛 が開始され、珟圚は Open Cybersecurity Schema Framework (OCSF) 暙準をサポヌトする 80 を超える゜ヌス ( 党リスト ) からのセキュリティデヌタの収集ず分析をサポヌトしおいたす。 AWS Secrets Manager – このサヌビスは、デヌタベヌスの認蚌情報や API キヌなどのシヌクレットを䞀元的に管理したす。シヌクレットはセキュアな方法で暗号化され、䞀元的に監査するこずが可胜です。たた、ディザスタリカバリやマルチリヌゞョンアプリケヌションに圹立぀レプリケヌションもサポヌトされおいたす。AWS は昚幎、 オンプレミスたたはマルチクラりドワヌクロヌド内のシヌクレットの保存ず管理に AWS Secrets Manager を䜿甚 できるこずを発衚したした。詳现に぀いおは、「 What is AWS Secrets Manager? 」をお読みください。 AWS Identity and Access Management (IAM) – AWS IAM アむデンティティセンタヌが、 Google Workspace からの自動ナヌザヌプロビゞョニング をサポヌトするようになりたした。この統合は、管理者が耇数のアカりント党䜓での AWS アクセス管理を簡玠化するために圹立぀ず同時に、サむンむンにはナヌザヌが䜿い慣れた Google Workspace ゚クスペリ゚ンスを維持したす。 Amazon CloudWatch – このサヌビスは、アプリケヌション、AWS、オンプレミス、およびマルチクラりドずいったあらゆるタむプのメトリクスをク゚リし、芖芚化しお、アラヌムを発行できるようにしたす。re:Invent 2023 では、 ハむブリッド、マルチクラりド、およびオンプレミスのメトリクスの統合 に察し、さらなるサポヌトを远加したした。この新しい機胜は、 Amazon Managed Service for Prometheus 、汎甚 Prometheus 、 Amazon OpenSearch Service 、 Amazon RDS for MySQL 、 Amazon RDS for PostgreSQL 、 Amazon Simple Storage Service (Amazon S3) に保存されおいる CSV ファむル、および Microsoft Azure Monitor からデヌタを取埗するコネクタを遞択しお蚭定するこずを可胜にしたす。 マルチクラりドに関するコンテンツずガむダンス AWS の最近のマルチクラりドロヌンチに぀いお理解できたので、次は私の同僚が䜜成したブログ蚘事やその他のコンテンツを芋おいきたしょう。 たず、ブログ蚘事をいく぀か玹介したす。 マルチクラりド戊略を策定するための実蚌枈みのプラクティス Amazon CloudWatch で Azure ず AWS のワヌクロヌドを同時に監芖する Get custom data into Amazon Security Lake through ingesting Azure activity logs Set up AWS Private Certificate Authority to issue certificates for use with IAM Roles Anywhere デヌタ転送を簡玠化: Amazon AppFlow を利甚した Google BigQuery から Amazon S3 ぞの転送 Use AWS Secrets Manager to store and manage secrets in on-premises or multicloud workloads Enable external pipeline deployments to AWS Cloud by using IAM Roles Anywhere Train and deploy ML models in a multicloud environment using Amazon SageMaker How to view Azure costs using Amazon QuickSight Using AWS CloudFormation and AWS Cloud Development Kit to provision multicloud resources How to copy data from Azure Blob Storage to Amazon S3 using code AWS Systems Manager ず Amazon CloudWatch を䜿甚したハむブリッドおよびマルチクラりド環境の監芖 Multicloud data lake analytics with Amazon Athena 次に、 AWS re:Invent 2023 からの最も人気のあるマルチクラりド動画をいく぀か玹介したす。 Centralize your operations (COP320) Centralize hybrid & multicloud management with AWS (COP324) Strategies for navigating multicloud decisions and difficulties (ENT217) 最埌に、 ハむブリッドおよびマルチクラりド向けの AWS ゜リュヌション ペヌゞもぜひブックマヌクしおおいおください。 い぀でもお手䌝いしたす マルチクラりド環境で実行しおおり、簡玠化ず䞀元化を行う準備が敎っおいるずいう堎合は、AWS のアカりントマネヌゞャヌ (AM)、たたはテクニカルアカりントマネヌゞャヌ (TAM) たでご連絡ください。どちらのマネヌゞャヌも喜んでお手䌝いしたす! – Jeff ; 原文は こちら です。
今日の急速に倉化するビゞネス環境においお、優れた顧客䜓隓を提䟛するこずは最重芁課題です。顧客は、すべおの接点で、シヌムレスでパヌ゜ナラむズされたサポヌトを期埅しおおり、これらの進化する芁求に応えるため、䌁業は新しい方法を垞に探し求めおいたす。 AI を掻甚したクラりドコンタクトセンタヌ゜リュヌションである Amazon Connect は、業界を問わず䌁業が最新の技術の進歩を掻甚し、゚ヌゞェントを支揎し、顧客デヌタから掞察を抜出し、゚ンドナヌザヌを喜ばせるオムニチャネルサポヌトを提䟛できるよう支揎しおいたす。このブログでは、 Customer Contact Week (CCW) で発衚されたものを含め Amazon Connect の最新の機胜、そしおお客様サヌビスの提䟛を革新的に倉えおいる先進的な䌁業の事䟋をご玹介したす。 より統合された䜓隓によりコンタクトセンタヌの゚ヌゞェントを支揎 優れた顧客䜓隓の基盀は、コンタクトセンタヌの゚ヌゞェントの手にかかっおいたす。そのため、Amazon Connect では、゚ヌゞェントの䜓隓をより盎感的で効率的か぀力匷いものにするこずに泚力しおいたす。最近の䞻なアップデヌトの䞀぀は、 Amazon Connect ゚ヌゞェントワヌクスペヌスのビゞュアルの刷新 です。このリデザむンにより、゚ヌゞェントの利䟿性ず応答性が向䞊し、 Amazon Q in Connect による生成 AI を掻甚した゚ヌゞェント支揎、ステップバむステップのガむダンス、 Amazon Connect Cases によるケヌス管理、 Amazon Connect Customer Profiles による顧客の統合ビュヌなどの機胜にスムヌズにアクセスできるようになりたす。 さらに、Amazon Connect では珟圚、 カスタムビルドたたは内郚アプリケヌションを゚ヌゞェントワヌクスペヌスに盎接統合 するこずができたす。これにより、顧客がサポヌトを求めた際に、゚ヌゞェントは問題を解決するために必芁なすべおの関連情報やツヌルにアクセスできるようになりたす。たた、 Cloudscape Design System コンポヌネントを䜿甚するこずで、゚ヌゞェントワヌクスペヌスず䞀貫した倖芳ず操䜜性を持぀サヌドパヌティアプリケヌションを簡単に構築し、埋め蟌むこずができたす。サヌドパヌティアプリケヌションのサポヌトに぀いおの詳现は、 サヌドパヌティヌアプリケヌションの゚ヌゞェントワヌクスペヌスずの統合 をご芧ください。 ヘルスケア業界のスタッフィングおよび人材゜リュヌションの䞻芁プロバむダヌである Experis も、Amazon Connect の統合された゚ヌゞェント䜓隓のメリットを実際に䜓隓しおいたす。 Experis では、Amazon Connect Cases を䜿甚しお゚ヌゞェント䜓隓を䞀本化し、顧客レポヌトを簡玠化する機䌚があるず考えたした。以前は、゚ヌゞェントが Amazon Connect で察応を管理し、別のチケット発行システムを䜿甚しお患者の問題に察凊する必芁がありたした。Amazon Connect Cases に移行するこずを決め、珟圚でぱヌゞェントが Amazon Connect の゚ヌゞェントワヌクスペヌスで、音声、チャット、メヌルなどのチャネルを暪断しお察応ずケヌスを䞀元的に管理できるようになりたした。パヌトナヌの支揎を埗お、100 人を超える゚ヌゞェントに察しお 90 日以内に本番環境で゜リュヌションを立ち䞊げ、さらに゚ヌゞェントず機胜を远加し続けおいたす」ず、Experis Health Solutions の VP Managed Services である Josh Kitchen 氏は述べおいたす。「䟋えば、゚ヌゞェントは今や゚ヌゞェントワヌクスペヌスでナレッゞを怜玢し、より迅速に解決策を芋぀けるこずができたす。Amazon Connect により゚ヌゞェントの生産性が 15% 向䞊し、手䜜業による報告䜜業が䞍芁になったため、圓瀟は高成長垂堎でより競争力を持おるようになりたした。圓瀟は、効率性ず患者の満足床を垞に向䞊させるべく努力しおおり、Amazon Connect を長期的なむノベヌションパヌトナヌず䜍眮付けおいたす。 コンタクトセンタヌのデヌタから掞察を埗る 今日のデヌタ䞻導の䞖界においお、コンタクトセンタヌは顧客䜓隓の継続的な改善を掚進するために掻甚すべき貎重な掞察の宝庫ずいえたす。Amazon Connect は、このデヌタの䟡倀を匕き出すこずをこれたでになく簡単にする、 Amazon Connect の分析デヌタレむクを䞀般提䟛開始 したした。Amazon Connect はすでに、゚ヌゞェント、スヌパヌバむザヌ、コンタクトセンタヌマネヌゞャヌのニヌズを満たすための、 リアルタむムず履歎のレポヌトオプション を提䟛しおいたす。新しい分析デヌタレむクは、コンタクトセンタヌマネヌゞャヌがカスタムレポヌトを通じおより深い掞察を埗るこずを可胜にし、CRM や ERP などの他の゜ヌスからの情報ずコンタクトセンタヌデヌタを簡単に組み合わせるこずもできたす。サヌドパヌティの゜ヌスに察するク゚リは、耇雑なデヌタパむプラむンではなく、 れロ ETL を䜿甚したす。これにより、高床な分析がサポヌトされ、コンタクトセンタヌマネヌゞャヌが隠れたトレンドず最適化の機䌚を発芋するこずができたす。 コンタクトセンタヌのスヌパヌバむザヌにずっおのもう 1 ぀の画期的な進歩は、Amazon Connect 内の最新の生成 AI 機胜です。 Amazon Connect Contact Lens は、自動的に顧客ずの䌚話の文脈を含んだ芁玄を提䟛 し、スヌパヌバむザヌの品質やコンプラむアンスのレビュヌにかかる時間を節玄したす。さらに、Amazon Connect は、 ゚ヌゞェントの評䟡に぀いお生成 AI を掻甚した掚奚事項 (プレビュヌ) を管理者に提䟛し、より深い行動の掞察ずその評䟡の根拠を提䟛したす。 2024 幎 6 月 1 日から 2024 幎 8 月 31 日たで、初めお Amazon Connect Contact Lens を利甚されるお客様向けに、本番環境での利甚に先駆けお、音声の䌚話分析機胜 (䟋: 通話の曞き起こし、感情分析、生成 AI による䌚話の芁玄) を無料で評䟡する限定の機䌚が蚭けられおいたす。新しい Contact Lens 䌚話分析機胜では、最初の 2 か月間、月間 100,000 分の音声通話に察しお無料トラむアルを利甚できたす。詳现に぀いおは、 Amazon Connect 䟡栌ペヌゞ の「分析、むンサむト、最適化」タブを参照しおください。 オヌストラリアの䞻芁な健康保険事業者である nib Group は、Amazon Connect 分析の力を掻甚しお、より良い顧客成果を䞊げるこずができるようになりたした。月に 10 䞇件を超える顧客の通話ずチャットがあり、より良い成果に぀ながる掞察を発芋するこずが課題でした。今では、nib は Amazon Connect のコンタクトセンタヌ分析を䜿甚しお、顧客ずの䌚話の奥深くに隠れたトレンドを探り、より良い顧客サヌビスを提䟛できるようになりたした。 オムニチャネルか぀セルフサヌビスの顧客サポヌトを提䟛 顧客は、音声、チャット、SMS、その他のデゞタルチャネルなど、自分の奜みのチャネルで䌁業ずやりずりするこずを求めおいたす。Amazon Connect は、シヌムレスな オムニチャネル䜓隓 を実珟するこずで、この需芁に応えおいたす。 Amazon Connect は、 Apple Messages for Business ずの暙準統合を提䟛しおいたす。顧客は、iPhone、iPad、Mac デバむスの Apple Messages アプリケヌションを䜿っお簡単に䌁業ず察話できたす。セキュアなメッセヌゞング、Apple Pay 統合、リッチメディアサポヌトにより、䌁業はパヌ゜ナラむズされたサポヌト、予玄のスケゞュヌリング、効率的な取匕凊理を提䟛できたす。これにより、コミュニケヌションが迅速、䟿利、そしお魅力的になり、顧客満足床ずロむダリティが向䞊したす。 2023 幎に、顧客の問題を自動的に特定し、゚ヌゞェントが取るべき適切なアクションを掚奚する、゚ヌゞェントワヌクスペヌス甚の Step-by-step ガむドを発衚したした。最近では、 Step-by-step ガむドを䜿っお゚ンドナヌザヌ向けのガむド付きチャット䜓隓を提䟛する機胜 をリリヌスし、むンタラクティブなチャット䜓隓の䜜成を容易にしたした。カルヌセル、ドロップダりンリスト、フォヌムなどの動的コンポヌネントを蚭定するこずで、䌁業は顧客が問題をより早く解決でき、゚ヌゞェントに゚スカレヌションする必芁性を枛らすこずができたす。チャットが゚スカレヌションされた堎合、゚ヌゞェントはセルフサヌビスむンタラクションの内容を確認し、ガむド付きワヌクフロヌを継続できるため、よりパヌ゜ナラむズされた効率的なサポヌトを提䟛できたす。 英囜の䞻芁な銀行 NatWest Group は、Amazon Connect のセルフサヌビス機胜を掻甚しお顧客䜓隓を革新しおいたす。デヌタ䞻導の掞察力を掻甚しおセルフサヌビスを革新し、業務を効率化し、Amazon Connect によっお゚ヌゞェントがより倚くの問い合わせを、顧客ずの最初のコンタクトで解決できるようになった方法をご芧ください。 ペヌロッパ最倧の航空䌚瀟 Ryanair は、倧芏暡に埓業員およびお客様の優れた䜓隓を提䟛するため、AWS の革新的な AI ゜リュヌションを掻甚したした。Amazon Connect が顧客サヌビスセンタヌを合理化し、自動化の匷化によりシヌムレスなサポヌトを提䟛した方法をご芧ください。 私たちず始めたしょう 今日の競争の激しい環境䞋では、優れた顧客䜓隓を提䟛できる䌁業が成功したす。そしお、Amazon Connect の最新の機胜により、さたざたな業界の組織が、゚ヌゞェントを支揎し、デヌタから掞察を埗お、シヌムレスなオムニチャネルサポヌトを提䟛しおいたす。぀たり、顧客を喜ばせ、ビゞネスの成功を促進するのです。 Amazon Connect を䜿い始めたい、顧客䜓隓をさらに高いレベルに匕き䞊げる方法を探玢したい堎合は、以䞋の远加リ゜ヌスをご芧ください。 2024幎6月3日から6日たで開催される Customer Contact Week にご参加ですか AWS ブヌスにお立ち寄りいただくか、むベントに参加する AWS の専門家ずミヌティングをご予玄ください ※蚳泚: 本むベントはすでに終了しおおりミヌティングは申し蟌みできたせん Amazon Connect の最新情報をご芧になりたいですか ? AWS の新着情報 をご芧ください Amazon Connect の最新機胜や、AWS のリヌダヌ、Amazon Connect のお客様、業界の専門家からの情報を聞きたいですか? AWS Contact Center Day のオンデマンドセッション をご芧ください 今埌の Amazon Connect むベントをご確認になりたいですか ? Customer Experience Workshops & Events をご芧の䞊、開催予定のむベントにご登録ください Amazon Connect で顧客サヌビス䜓隓を倉革したいですか ? お問い合わせ ください 翻蚳はテクニカルアカりントマネヌゞャヌ高橋が担圓したした。原文は こちら です。
OpenSearch は、オヌプン゜ヌスの分散型怜玢゚ンゞンで、e コマヌス怜玢、゚ンタヌプラむズ怜玢 (コンテンツ管理怜玢、ドキュメント怜玢、ナレッゞ管理怜玢など)、サむト怜玢、アプリケヌション怜玢、セマンティック怜玢など、幅広いナヌスケヌスに適しおいたす。たた、むンタラクティブなログ分析、リアルタむムアプリケヌションモニタリング、セキュリティ分析などを実行できる分析スむヌトでもありたす。Apache Solr ず同様に、OpenSearch はドキュメントセットに察する怜玢を提䟛したす。OpenSearch にはデヌタの取り蟌みず分析を行う機胜も含たれおいたす。 Amazon OpenSearch Service は、AWS クラりドで OpenSearch のデプロむ、スケヌリング、モニタリングを行うこずができるフルマネヌゞドサヌビスです。 倚くの組織が Apache Solr ベヌスの怜玢゜リュヌションを OpenSearch に移行しおいたす。䞻な芁因は、総所有コストの䜎枛、スケヌラビリティ、安定性、発展した取り蟌みコネクタ ( Data Prepper , Fluent Bit , OpenSearch Ingestion など)、Zookeeper のような倖郚クラスタマネヌゞャヌの排陀、レポヌティングの匷化、OpenSearch Dashboards によるリッチな可芖化などです。 Solr から OpenSearch ぞの移行は、怜玢゜リュヌションを OpenSearch 向けに最適化するために完党なリファクタリングを行うアプロヌチをお勧めしたす。Solr ず OpenSearch はどちらも Apache Lucene をコアのむンデックス䜜成ずク゚リ凊理に䜿甚しおいたすが、システムの特性は異なりたす。蚈画を立お、実蚌実隓を行うこずで、OpenSearch から最良の結果を埗るこずができたす。このブログ蚘事では、Solr から OpenSearch ぞの移行に関わる戊略的考慮事項ず手順に぀いお詳しく説明したす。 䞻な違い Solr ず OpenSearch Service は、Apache Lucene を通じお提䟛される基本的な機胜を共有しおいたす。しかし、甚語や機胜には以䞋のような䞻な違いがありたす。 コレクションずむンデックス: OpenSearch では、コレクションはむンデックスず呌ばれたす。 シャヌドずレプリカ: Solr ず OpenSearch の䞡方で、シャヌドずレプリカずいう甚語が䜿甚されおいたす。 API 駆動のむンタラクション: OpenSearch ではすべおのむンタラクションが API 駆動であり、手動でのファむル倉曎や Zookeeper の蚭定が䞍芁です。OpenSearch むンデックスを䜜成する際、マッピング (スキヌマに盞圓) ず蚭定 (solrconfig に盞圓) をむンデックス䜜成 API 呌び出しの䞀郚ずしお定矩したす。 基本的な事項を説明したずころで、4 ぀の䞻芁コンポヌネントに぀いお、 Solr から OpenSearch に移行する方法を詳しく芋おいきたしょう。 コレクションからむンデックスぞ Solr のコレクションは、OpenSearch ではむンデックスず呌ばれたす。Solr のコレクションず同様に、OpenSearch のむンデックスにもシャヌドずレプリカがありたす。 シャヌドずレプリカの抂念は䞡方の怜玢゚ンゞンで類䌌しおいたすが、この移行を機に、より良いシャヌディング戊略を採甚するこずができたす。 シャヌド戊略のベストプラクティス に埓っお、OpenSearch のシャヌド、レプリカ、むンデックスのサむズを決定しおください。 移行の䞀環ずしお、デヌタモデルを再考しおください。デヌタモデルを怜蚎するこずで、怜玢のレむテンシヌずスルヌプットを倧幅に改善する可胜性を芋出すこずができたす。デヌタモデリングが䞍適切だず、怜玢パフォヌマンスの問題だけでなく、他の領域にも圱響が及びたす。䟋えば、特定の機胜を実装するための効果的なク゚リの実装が難しくなる堎合がありたす。このような堎合、解決策ずしおデヌタモデルの修正が求められる可胜性がありたす。 違い : Solr では、プラむマリシャヌドずレプリカシャヌドを同じノヌドに配眮できたす。OpenSearch では、プラむマリずレプリカは同じノヌドに配眮できたせん。さらに、OpenSearch Service は ゟヌンアりェアネス により、シャヌドを自動的に異なる Availability Zone (デヌタセンタヌ) に分散させるこずで、回埩力を高めるこずが可胜です。 OpenSearch ず Solr のレプリカの抂念は異なりたす。OpenSearch では、 number_of_shards を䜿甚しおプラむマリシャヌド数を定矩し、デヌタのパヌティショニングを決定したす。その埌、 number_of_replicas を䜿甚しおレプリカ数を蚭定したす。各レプリカはすべおのプラむマリシャヌドのコピヌです。぀たり、 number_of_shards を 5 に蚭定し、 number_of_replicas を 1 に蚭定するず、10 個のシャヌド (5 個のプラむマリシャヌドず 5 個のレプリカシャヌド) が生成されたす。Solr で replicationFactor=1 を蚭定するず、デヌタの 1 ぀のコピヌ (単䞀のプラむマリのみ) が生成されたす。 䟋えば、以䞋は Solr に察しお、 test ずいう名前のコレクションを 1 ぀のシャヌドず 0 個のレプリカで䜜成しおいたす。 http://localhost:8983/solr/admin/collections? _=action=CREATE &maxShardsPerNode=2 &name=test &numShards=1 &replicationFactor=1 &wt=json 以䞋は、OpenSearch に察しお、 test ずいう名前のむンデックスを 5 ぀のシャヌドず 1 ぀のレプリカで䜜成しおいたす。 PUT test { "settings": { "number_of_shards": 5, "number_of_replicas": 1 } } スキヌマからマッピングぞ Solr の schema.xml たたは managed-schema には、フィヌルド定矩、動的フィヌルド、コピヌフィヌルドのすべおが、フィヌルドタむプ (テキストアナラむザヌ、トヌクナむザヌ、たたはフィルタヌ) ずずもに含たれおいたす。スキヌマの管理には schema API を䜿甚したす。たたは、スキヌマレスモヌドで実行するこずもできたす。 OpenSearch には 動的マッピング があり、Solr のスキヌマレスモヌドのように動䜜したす。デヌタを取り蟌むために事前にむンデックスを䜜成する必芁はありたせん。新しいむンデックス名でデヌタをむンデクシングするこずで、OpenSearch マネヌゞドサヌビスのデフォルト蚭定 (䟋: “number_of_shards”: 5, “number_of_replicas”: 1) ず、むンデクシングされたデヌタに基づくマッピング (動的マッピング) でむンデックスが䜜成されたす。 しかしながら、事前に定矩された 厳密なマッピング を遞択するこずを匷くお勧めしたす。OpenSearch は、フィヌルドで最初に芋た倀に基づいおスキヌマを蚭定したす。実際には文字列フィヌルドであるものに、数倀が最初の倀ずしお珟れるず、OpenSearch は䞍適切にそのフィヌルドを数倀 (䟋えば敎数) ずしおマッピングしたす。その埌、そのフィヌルドに文字列倀でむンデクシングを詊みるず、䞍適切なマッピング䟋倖で倱敗したす。デヌタの内容ずフィヌルドタむプを把握しおいるのであれば、マッピングを盎接蚭定するこずにメリットがありたす。 ヒント : サンプルデヌタを甚いおむンデックス䜜成を行い、初期マッピングを生成しおください。その埌、マッピングを修正・敎理しお実際のむンデックスを正確に定矩するこずを怜蚎しおください。このアプロヌチは、マッピングを最初から手動で構築するのを避けるのに圹立ちたす。 Observability ワヌクロヌドの堎合は、 Simple Schema for Observability の䜿甚を怜蚎しおください。Simple Schema for Observability (ss4o ずしおも知られる) は、共通の統䞀された observability スキヌマに準拠するための暙準です。このスキヌマを導入するこずで、Observability ツヌルはデヌタを取り蟌み、自動的に抜出し、集玄しおカスタムダッシュボヌドを䜜成し、システムをより高いレベルで理解しやすくしたす。 倚くのフィヌルドタむプ (デヌタタむプ)、トヌクナむザヌ、フィルタヌは Solr ず OpenSearch の䞡方で同じです。どちらも Lucene の Java 怜玢ラむブラリをコアずしお䜿甚しおいるからです。 䟋を芋おみたしょう。 <!-- Solr schema.xml スニペット --> <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" /> <field name="name" type="string" indexed="true" stored="true" multiValued="true"/> <field name="address" type="text_general" indexed="true" stored="true"/> <field name="user_token" type="string" indexed="false" stored="true"/> <field name="age" type="pint" indexed="true" stored="true"/> <field name="last_modified" type="pdate" indexed="true" stored="true"/> <field name="city" type="text_general" indexed="true" stored="true"/> <uniqueKey>id</uniqueKey> <copyField source="name" dest="text"/> <copyField source="address" dest="text"/> <fieldType name="string" class="solr.StrField" sortMissingLast="true" /> <fieldType name="pint" class="solr.IntPointField" docValues="true"/> <fieldType name="pdate" class="solr.DatePointField" docValues="true"/> <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100"> <analyzer type="index"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.ASCIIFoldingFilterFactory" preserveOriginal="false" /> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> <analyzer type="query"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.ASCIIFoldingFilterFactory" preserveOriginal="false" /> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> </fieldType> PUT index_from_solr { "settings": { "analysis": { "analyzer": { "text_general": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "asciifolding" ] } } } }, "mappings": { "properties": { "name": { "type": "keyword", "copy_to": "text" }, "address": { "type": "text", "analyzer": "text_general" }, "user_token": { "type": "keyword", "index": false }, "age": { "type": "integer" }, "last_modified": { "type": "date" }, "city": { "type": "text", "analyzer": "text_general" }, "text": { "type": "text", "analyzer": "text_general" } } } } Solr ず比范しお OpenSearch で泚目すべき点は以䞋の通りです。 _id は垞に䞀意です。たた、明瀺的に定矩する必芁はありたせん。指定されない堎合は自動で採番されるためです。 マルチバリュヌを明瀺的に有効にする必芁はありたせん。OpenSearch は、各フィヌルドに 0 個以䞊の倀を含むこずができたす。 マッピングずアナラむザヌはむンデックス䜜成時に定矩されたす。新しいフィヌルドを远加したり、特定のマッピングパラメヌタを埌で曎新したりするこずはできたすが、フィヌルドを削陀するこずはできたせん。 ReIndex API でこの問題を解決できたす。Reindex API を䜿甚しお、あるむンデックスから別のむンデックスにデヌタをむンデクシング可胜です。 デフォルトでは、アナラむザヌはむンデックス時ずク゚リ時の䞡方に適甚されたす。䞀郚のケヌスでは、ク゚リ時に異なるアナラむザヌを指定するこずができたす。これにより、むンデックスマッピングで定矩されたアナラむザヌがオヌバヌラむドされたす。 むンデックステンプレヌト も、事前定矩されたマッピングず蚭定で新しいむンデックスを初期化する優れた方法です。䟋えば、ログデヌタ ずいった任意の時系列デヌタを継続的にむンデクシングする堎合、むンデックステンプレヌトを定矩しお、すべおのむンデックスが同じ数のシャヌドずレプリカを持぀ようにするこずができたす。たた、動的マッピング制埡やコンポヌネントテンプレヌトにも䜿甚できたす。 怜玢゜リュヌションを最適化する機䌚を探しおください。䟋えば、分析の結果、city フィヌルドが怜玢ではなくフィルタリングにのみ䜿甚されおいるこずが刀明した堎合、䞍必芁なテキスト凊理を削枛するために、そのフィヌルドタむプを text から keyword に倉曎するこずを怜蚎しおください。もう䞀぀の最適化ずしお、user_token フィヌルドが衚瀺目的でのみ䜿甚される堎合、 doc_values を無効にするこずが考えられたす。doc_values は text デヌタタむプではデフォルトで無効になっおいたす。 SolrConfig から OpenSearch の蚭定ぞ Solr では、solrconfig.xml がコレクション蚭定を担っおいたす。むンデックスの堎所、フォヌマット、キャッシング、コヌデックファクトリ、サヌキットブレヌカヌ、コミット、トランザクションログから、スロヌク゚リ蚭定、リク゚ストハンドラ、update processing chain に至るたで、あらゆる皮類の蚭定が含たれおいたす。 䟋を芋おみたしょう。 <codecFactory class="solr.SchemaCodecFactory"> <str name="compressionMode">`BEST_COMPRESSION`</str> </codecFactory> <autoCommit> <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> <openSearcher>false</openSearcher> </autoCommit> <autoSoftCommit> <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> </autoSoftCommit> <slowQueryThresholdMillis>1000</slowQueryThresholdMillis> <maxBooleanClauses>${solr.max.booleanClauses:2048}</maxBooleanClauses> <requestHandler name="/query" class="solr.SearchHandler"> <lst name="defaults"> <str name="echoParams">explicit</str> <str name="wt">json</str> <str name="indent">true</str> <str name="df">text</str> </lst> </requestHandler> <searchComponent name="spellcheck" class="solr.SpellCheckComponent"/> <searchComponent name="suggest" class="solr.SuggestComponent"/> <searchComponent name="elevator" class="solr.QueryElevationComponent"/> <searchComponent class="solr.HighlightComponent" name="highlight"/> <queryResponseWriter name="json" class="solr.JSONResponseWriter"/> <queryResponseWriter name="velocity" class="solr.VelocityResponseWriter" startup="lazy"/> <queryResponseWriter name="xslt" class="solr.XSLTResponseWriter"/> <updateRequestProcessorChain name="script"/> Solr ず比范しお OpenSearch で泚目すべき点は以䞋の通りです。 OpenSearch ず Solr ずもに、デフォルトのコヌデックは BEST_SPEED (LZ4 圧瞮アルゎリズム) です。たた BEST_COMPRESSION を代替コヌデックずしお提䟛しおいたす。さらに OpenSearch は zstd ず zstd_no_dict を提䟛しおいたす。各圧瞮コヌデックの ベンチマヌク も掻甚できたす。 ニアリアルタむム怜玢の堎合、 refresh_interval を蚭定する必芁がありたす。デフォルトは 1 秒で、ほずんどのナヌスケヌスで十分です。特にバッチむンデックス䜜成の堎合、むンデックス䜜成の速床ずスルヌプットを向䞊させるために、refresh_interval を 30 秒たたは 60 秒に増やすこずをお勧めしたす。 Max boolean clause は静的蚭定で、 indices.query.bool.max_clause_count 蚭定を䜿甚しおノヌドレベルで蚭定されたす。 明瀺的な requestHandler は必芁ありたせん。すべおの怜玢は _search たたは _msearch ゚ンドポむントを䜿甚したす。デフォルト倀を持぀ requestHandler を䜿甚するこずに慣れおいる堎合は、 怜玢テンプレヌト を䜿甚できたす。 /sql requestHandler の䜿甚に慣れおいる堎合、OpenSearch でも SQL 構文 を䜿甚しおク゚リを実行できたす。 Piped Processing Language も提䟛しおいたす。 Spellcheck ( Did-you-mean )、 ハむラむト はすべおク゚リ実行時に利甚可胜です。明瀺的に怜玢コンポヌネントを定矩する必芁はありたせん。 ほずんどの API レスポンスは JSON フォヌマットで固定されおいたす。 CAT API が唯䞀の䟋倖です。Solr で Velocity や XSLT が䜿甚されおいる堎合、アプリケヌション局で管理する必芁がありたす。CAT API は JSON、YAML、たたは CBOR 圢匏で応答したす。 updateRequestProcessorChain に぀いおは、OpenSearch は むンゞェストパむプラむン を提䟛しおいたす。むンデクシング前にデヌタの匷化や倉換を行うこずができたす。耇数のプロセッサステヌゞをチェヌンしおデヌタ倉換のパむプラむンを圢成できたす。プロセッサには GrokProcessor、CSVParser、JSONProcessor、KeyValue、Rename、Split、HTMLStrip、Drop、ScriptProcessor などがありたす。ただし、OpenSearch の倖郚でデヌタ倉換を行うこずを匷くお勧めしたす。 OpenSearch Ingestion では、デヌタ倉換のための適切なフレヌムワヌクず様々な組み蟌みフィルタヌを提䟛しおいたす。OpenSearch Ingestion は Data Prepper をベヌスに構成されおいるサヌバヌサむドのデヌタコレクタヌで、䞋流の分析ず可芖化のためにデヌタのフィルタリング、匷化、倉換、正芏化、集玄を行うこずができたす。 OpenSearch は、むンゞェストパむプラむンに加えお、怜玢時の操䜜に特化した 怜玢パむプラむン を提䟛しおいたす。怜玢パむプラむンを䜿甚するこずで、OpenSearch 内で怜玢ク゚リず怜玢結果を簡単に倉換できたす。珟圚利甚可胜な怜玢プロセッサには、フィルタヌク゚リ、ニュヌラルク゚リ゚ンリッチャヌ、正芏化、フィヌルド名倉曎、スクリプトプロセッサ、パヌ゜ナラむズ怜玢ランキングなどがあり、今埌さらに远加される予定です。 以䞋の画像は、refresh_interval ず slowlog の蚭定方法を瀺しおいたす。たた、他の可胜な蚭定も瀺しおいたす。 スロヌログは以䞋の画像のように蚭定できたすが、ク゚リフェヌズずフェッチフェヌズに察しお別々のしきい倀を蚭定するこずもできたす。 蚭定の移行前に、珟圚の怜玢システムの運甚経隓ずベストプラクティスに基づき、蚭定の調敎䜙地があるかを評䟡しおください。䟋えば、前述の䟋では、1 秒のスロヌログのしきい倀はログ蚘録にずっお負荷が高い可胜性があるため、再怜蚎する必芁があるかもしれたせん。同様に、max.booleanClauses も芋盎しにより削枛される可胜性がありたす。 違い : 䞀郚の蚭定は、むンデックスレベルではなく、クラスタヌレベルたたはノヌドレベルで行われたす。これには、 最倧ブヌル句 、 サヌキットブレヌカヌ蚭定 、 キャッシュ蚭定 などが含たれたす。 ク゚リの曞き換え ク゚リの曞き換えに぀いおは、それだけでブログ蚘事を曞けるほどの内容がありたすが、ここでは OpenSearch Dashboards で利甚可胜なオヌトコンプリヌト機胜を玹介したす。これはク゚リ䜜成を容易にするのに圹立ちたす。 Solr Admin UI ず同様に、OpenSearch にも OpenSearch Dashboards ず呌ばれる UI がありたす。OpenSearch Dashboards を䜿甚しお、OpenSearch クラスタヌを管理およびスケヌリングできたす。さらに、OpenSearch デヌタの可芖化、デヌタの探玢、可芳枬性のモニタリング、ク゚リの実行などの機胜も提䟛しおいたす。Solr UI のク゚リタブに盞圓するものは、OpenSearch Dashboard の Dev Tools です。Dev Tools は開発環境で、OpenSearch Dashboards 環境のセットアップ、ク゚リの実行、デヌタの探玢、問題のデバッグなどを行うこずができたす。 では、以䞋を実行するク゚リを構築しおみたしょう。 むンデックス内で “shirt” たたは “shoe” を怜玢する。 ナニヌクな顧客数を芋぀けるためのファセットク゚リを䜜成する。ファセットク゚リは OpenSearch では 集玄ク゚リ ず呌ばれたす。たた、aggs ク゚リずしおも知られおいたす。 Solr ク゚リは以䞋のようになりたす。 http://localhost:8983/solr/solr_sample_data_ecommerce/select?q=shirt OR shoe &facet=true &facet.field=customer_id &facet.limit=-1 &facet.mincount=1 &json.facet={ unique_customer_count:"unique(customer_id)" } 以䞋の画像は、䞊蚘の Solr ク゚リを OpenSearch ク゚リ DSL に曞き換える方法を瀺しおいたす。 結論 OpenSearch は、゚ンタヌプラむズ怜玢、サむト怜玢、アプリケヌション怜玢、e コマヌス怜玢、セマンティック怜玢、可芳枬性 (ログ可芳枬性、セキュリティ分析 (SIEM)、異垞怜出、トレヌス分析)、分析など、幅広いナヌスケヌスをカバヌしおいたす。Solr から OpenSearch ぞの移行は䞀般的なパタヌンになり぀぀ありたす。このブログ蚘事は、そのような移行に関するガむダンスを求めるチヌムのための出発点ずなるこずを考えお䜜成されおいたす。 OpenSearch Playground で OpenSearch をお詊しいただくこずが可胜です。AWS にお、 OpenSearch のマネヌゞドサヌビスである Amazon OpenSearch Service を䜿い始めるこずもできたす。 著者に぀いお Aswath Srinivasan iは、珟圚ドむツのミュンヘンを拠点ずする Amazon Web Services のシニア怜玢゚ンゞンアヌキテクトです。様々な怜玢技術で 17 幎以䞊の経隓を持぀ Aswath は、珟圚 OpenSearch に焊点を圓おおいたす。怜玢ずオヌプン゜ヌスの愛奜家であり、顧客や怜玢コミュニティの怜玢問題解決を支揎しおいたす。 Jon Handler カリフォルニア州パロアルトを拠点ずする Amazon Web Services のシニアプリンシパル゜リュヌションアヌキテクトです。Jon は OpenSearch ず Amazon OpenSearch Service ず密接に連携し、AWS クラりドに移行したい怜玢およびログ分析ワヌクロヌドを持぀幅広い顧客に支揎ずガむダンスを提䟛しおいたす。AWS に入瀟する前の Jon の゜フトりェア開発者ずしおのキャリアには、倧芏暡な e コマヌス怜玢゚ンゞンの 4 幎間のコヌディングが含たれおいたす。Jon はペンシルベニア倧孊で文孊士号を、ノヌスりェスタン倧孊でコンピュヌタヌサむ゚ンスず人工知胜の理孊修士号および博士号を取埗しおいたす。 本蚘事は゜リュヌションアヌキテクトの抎本が翻蚳いたしたした。原文は こちら です。
2024 幎 5 月および 6 月に公開された AWS Black Belt オンラむンセミナヌの資料及び動画に぀いおご案内させお頂きたす。 動画はオンデマンドでご芖聎いただけたす。 たた、過去の AWS Black Belt オンラむンセミナヌの資料及び動画は「 AWS サヌビス別資料集 」に䞀芧がございたす。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご芧ください。 AWS Cost Explorer AWS Cost Explorer は、コストず䜿甚状況を衚瀺および分析するために䜿甚できるサヌビスです。本セッションでは、AWS Cost Explorer の抂芁、基本的な利甚方法およびナヌスケヌスに぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 AWS Cost Explorer の抂芁・基本的な利甚方法を知りたい方 サヌビスやメンバヌアカりント別などのコストず利甚量を分析したい方 FinOps やコスト最適化を掚進したい方 本 BlackBelt で孊習できるこず AWS Cost Explorer の抂芁、基本的な利甚方法に぀いお孊んでいただけたす。 たた、いく぀かナヌスケヌスに぀いおも玹介したす 実際の分析䟋などに぀いおも孊んでいただけたす。 スピヌカヌ 加須屋 悠己 テクニカルアカりントマネヌゞャヌ なぜ今コンテナなのか 新芏サヌビスの8割近くがコンテナやサヌバレスで構築されおいるこずをご存知でしょうかコンテナはセキュリティガヌドレヌルず、CI/CD ず合わせお生産性を向䞊させるツヌルです。 AWS におけるコンテナ関連サヌビスは倚岐にわたりたす。それらの抂芁を把握できるように玹介したす。 資料 PDF  | 動画 YouTube  察象者 序論、あるいは盎接 AWS は觊らないが技術的方向を知っおおきたい人 本 BlackBelt で孊習できるこず なぜいたコンテナなのかず問われれば、生産性を䞊げるための必然的な遞択ず答えたす。 コンテナ、セキュリティガヌドレヌル、CI/CD は、珟代の゜フトりェア開発ずデプロむメントにおいお盞互に補完し合う重芁な芁玠です。コンテナ技術を掻甚するこずで、ガヌドレヌルを CI/CD パむプラむンに統合し、セキュリティリスクを軜枛しながら効率的で䞀貫性のあるデプロむメントを実珟できたす。これにより、組織は高品質でセキュアな゜フトりェアを迅速に提䟛するこずが可胜になりたす。 AWS コンテナ党䜓を少し詳しくなれる BlackBelt です。 スピヌカヌ 荒朚 靖宏 ゜リュヌションアヌキテクト Amazon Bedrock Overview 【Amazon Bedrock Series #01】 皆さん、生成 AI を掻甚しおいたすか Amazon Bedrock は、基盀モデルを掻甚した生成 AI アプリケヌションを簡単に構築できる AWS サヌビスです。Amazon Bedrock シリヌズ第回ずなる本動画では、Amazon Bedrock の抂芁や䞻な機胜の党䜓像をご玹介したす。 資料 PDF  | 動画 YouTube  察象者 これから生成 AI の掻甚を始めたいず考えおいる方 Amazon Bedrock のこずを初めお孊ぶ方 Amazon Bedrock がも぀各皮機胜に぀いお知りたい方 本 BlackBelt で孊習できるこず 生成 AI に関する AWS サヌビスである Amazon Bedrock に぀いお、抂芁や特城、䞻芁な各皮機胜など、サヌビスの党䜓像を掎んでいただくこずができたす。 スピヌカヌ 森䞋 裕介 ゜リュヌションアヌキテクト Amazon Connect Forecasting, capacity planning, and scheduling dive deep Amazon Connect Forecasting, capacity planning, and scheduling を䜿甚する事で、コンタクトセンタヌにおける人員の過剰配眮を最小限に抑えながら運甚䞊の目暙を達成するために、問い合わせの量ず到達率を予枬し、予枬結果から必芁な人員配眮を割り出し、適切な数の゚ヌゞェントに日々のシフトを割り圓おるこずができたす。このセミナヌでは、Amazon Connect   Forecasting, capacity planning, and scheduling の機胜毎の蚭定ポむントやナヌスケヌスをデモを亀えお解説したす。 資料 PDF  | 動画 YouTube  察象者 Amazon Connect ご利甚䞭の゚ンドナヌザヌ/パヌトナヌの方 これから Amazon Connect のご利甚を怜蚎されおいる方 コンタクトセンタヌにおける、予枬、人員配眮などの WFMワヌクフォヌスマネゞメント業務を行う担圓者 本 BlackBelt で孊習できるこず Amazon Connect の Forecasting, capacity planning, and scheduling を䜿甚したコンタクトセンタヌのワヌクフォヌスマネゞメント機胜の理解 スピヌカヌ 梅田 裕矩 シニア Connect スペシャリスト ゜リュヌション アヌキテクト 今埌の Black Belt オンラむンセミナヌ たた、珟時点で予定されおいる今埌の Black Belt オンラむンセミナヌに぀いおは以䞋の通りです。 公開月 タむトル 登壇予定者 2024-07 Amazon Location Service ゜リュヌションアヌキテクト 皲田倧陞 2024-07 Amazon ElastiCache Serverless ゜リュヌションアヌキテクト å € 勇人 2024-07 SaaS 成功のための基瀎戊略ず AWS 掻甚法 〜 SaaS 入門線〜 ゜リュヌションアヌキテクト 前田 進吟 2024-08 Amazon RDS ゜リュヌションアヌキテクト 塚井知之 2024-08 AWS Cloud Map 入門 ゜リュヌションアヌキテクト 倚田 慎也 2024-08 AWS Application Migration Service (AWS MGN) プラむベヌトネットワヌク経由でサヌバを Amazon EC2 ぞ移行する方法 ゜リュヌションアヌキテクト 鈎朚 槙将 2024-08 Amazon ECS 入門 ゜リュヌションアヌキテクト 吉田 英史 2024-08 AWS Cost Anomaly Detection テクニカルアカりントマネヌゞャヌ 加須屋悠己  
モノのむンタヌネット (IoT) は、日々テラバむトの情報を流す数十億のデバむスがあり、前䟋のないほどのデヌタを生成しおいたす。IoT デヌタから貎重な分析情報を埗ようずする䌁業や組織にに察しお、AWS が匷力な分析サヌビスを提䟛しおいたす。 AWS IoT Analytics は、IoT 分析に着手する倚くの顧客にずっお出発点ずなりたす。このフルマネヌゞドサヌビスでは、IoT デヌタの高速な収集、凊理、保存、分析が可胜です。AWS IoT Analytics では、デヌタを時系列デヌタストアに保存する前に、フィルタリング、倉換、加工を行うこずができたす。たた、このサヌビスには Amazon QuickSight ずの統合が含たれおおり、ダッシュボヌドやビゞュアラむれヌションを䜜成しお IoT デヌタを効果的に把握できたす。ただし、IoT の展開が進み、デヌタ量が増加するに぀れ、顧客はさらなる拡匵性ず柔軟性を必芁ずするようになり、分析芁件の進化に察応できなくなりたす。このような堎合に、Amazon Kinesis、Amazon S3、Amazon Athena などのサヌビスが圹立ちたす。これらのサヌビスは、それぞれ倧芏暡なストリヌミングデヌタ収集、耐久性ず経枈性に優れた保存、高速な SQL ベヌスのク゚リ実行を目的ずしお蚭蚈されおいたす。 この投皿では、IoT 分析ワヌクロヌドを AWS IoT Analytics から Kinesis、S3、Athena に移行するこずのメリットを探りたす。この移行により、最も芁求の高い IoT ナヌスケヌスに察応できるよう分析ワヌクロヌドを拡匵するこずが可胜になるこずず、移行の蚈画ず実行に圹立぀ステップバむステップのガむドに぀いお説明したす。 移行オプション AWS IoT Analytics から移行するこずを怜蚎する堎合、この移行のメリットず理由を理解するこずが重芁です。以䞋の衚は、既存の AWS IoT Analytics 機胜に察応する代替オプションを瀺しおいたす。 AWS IoT Analytics 代替サヌビス 理由 収集 AWS IoT Analytics では、BatchPutMessage API を䜿甚しお AWS IoT Core やその他の゜ヌスからデヌタを簡単に取り蟌めたす。この統合により、デバむスからアナリティクスプラットフォヌムたでのデヌタのシヌムレスなフロヌが確保されたす。 Amazon Kinesis Data Streams たたは Amazon Data Firehose Amazon Kinesis は堅牢な゜リュヌションを提䟛したす。Kinesis はデヌタをリアルタむムでストリヌミングするため、リアルタむムの分析や異垞怜知が必芁なアプリケヌションに䞍可欠な即座の凊理ず分析が可胜です。Amazon Data Firehose は、ストリヌミングデヌタを Amazon S3 に栌玍する前に、キャプチャず倉換を簡玠化しおくれたす。スルヌプットに合わせお自動的にスケヌリングしたす。 凊理 AWS IoT Analytics でデヌタを凊理する際は、クレンゞング、フィルタリング、倉換、倖郚゜ヌスでの匷化が行われたす。 Managed Streaming for Apache Flink たたは Amazon Data Firehose Managed Streaming for Apache Flink は、高床な IoT 分析シナリオに䞍可欠なパタヌンマッチングや集玄などの耇雑なむベント凊理をサポヌトしおいたす。 Amazon Data Firehose はより単玔な倉換を凊理し、カスタム凊理には AWS Lambda 関数を呌び出すこずができるので柔軟性があり、Flink ほど耇雑ではありたせん。 保存先 AWS IoT Analytics では、デヌタ保持ポリシヌやアクセス管理などの機胜を備えた、IoT デヌタ向けに最適化された時系列デヌタストアを䜿甚しおいたす。 Amazon S3 たたは Amazon Timestream Amazon S3 はスケヌラブル、堅牢、䜎コストのストレヌゞ゜リュヌションです。S3 ず他の AWS サヌビスずの統合により、倧芏暡デヌタセットの長期保存ず分析に最適です。 Amazon Timestream は、時系列デヌタ向けに䜜られたデヌタベヌスです。 S3 からのバッチロヌド ができたす。 分析 AWS IoT Analytics には、組み蟌みの SQL ク゚リ機胜、時系列分析、ホストされた Jupyter Notebook のサポヌトがあり、高床な分析ず機械孊習を簡単に実行できたす。 AWS Glue ず Amazon Athena AWS Glue は ETL プロセスを簡玠化し、デヌタの抜出、倉換、ロヌドを容易にしたす。たた、Athena ず統合されたデヌタカタログを提䟛し、ク゚リを容易にしたす。 Amazon Athena はさらに、むンフラストラクチャを管理するこずなく、S3 に保存されたデヌタに察しお盎接 SQL ク゚リを実行できるようになりたす。 ビゞュアラむズ AWS IoT Analytics は Amazon QuickSight ず統合されおいるので、芖芚化ずダッシュボヌドを䜜成できたす。S3 などの遞択した代替デヌタストアに応じお、匕き続き QuickSight を䜿甚できたす。 移行ガむド 珟行のアヌキテクチャでは、IoT デヌタは IoT Core ルヌルを経由しお IoT Core から AWS IoT Analytics に流れおいたす。AWS IoT Analytics がデヌタの取り蟌み、倉換、および栌玍を凊理したす。移行を完了するには、2 ぀のステップに埓う必芁がありたす。 ステップ 1: 継続的デヌタ取り蟌みのリダむレクト ステップ 2: 以前むンポヌトしたデヌタの゚クスポヌト 図 1: AWS IoT Analytics による IoT デヌタの取り蟌み甚の珟行のアヌキテクチャ ステップ 1: 継続的デヌタ取り蟌みのリダむレクト 移行の第䞀歩は、デヌタの継続的な取り蟌みを新しいサヌビスぞリダむレクトするこずです。特定のナヌスケヌスに基づき、次の 2 ぀のパタヌンをお勧めしたす: 図 2: IoT デヌタ取り蟌みのための提案アヌキテクチャパタヌン パタヌン 1: Amazon Kinesis Data Streams ず Amazon Managed Service for Apache Flink 抂芁 このパタヌンでは、たず AWS IoT Core にデヌタを公開するこずから始めたす。これは Amazon Kinesis Data Streams ず統合されおおり、倧量の垯域幅のデヌタをリアルタむムで収集、凊理、分析できたす。 メトリクスずアナリティクス デヌタの取り蟌み: IoT デヌタは、リアルタむムで Amazon Kinesis Data Streams に取り蟌たれたす。Kinesis Data Streams は、数癟䞇の IoT デバむスからの高スルヌプットのデヌタを凊理でき、リアルタむム分析ず異垞怜知が可胜です。 デヌタの凊理: Amazon Managed Streaming for Apache Flink を䜿甚しお、Kinesis Data Stream からデヌタを凊理、加工、フィルタリングしたす。Flink には、集蚈、結合、時間操䜜などの耇雑なむベント凊理のための堅牢な機胜がありたす。 デヌタの保存: Flink は凊理枈みのデヌタを Amazon S3 に出力し、保存ず远加の分析に利甚できたす。このデヌタは Amazon Athena でク゚リを実行したり、他の AWS の分析サヌビスず統合したりできたす。 このパタヌンが適するケヌス アプリケヌションがデヌタストリヌミングなど垯域の倧きいデヌタを扱い、パタヌンマッチングやりィンドり凊理ずいった高床な凊理が必芁な堎合、このパタヌンが最適です。 パタヌン 2: Amazon Data Firehose 抂芁 このパタヌンでは、デヌタがAWS IoT Coreに公開され、Amazon Data Firehoseず統合されるため、デヌタを盎接Amazon S3に保存できたす。このパタヌンはたた、AWS Lambdaを䜿った基本的な倉換もサポヌトしおいたす。 メトリクスず分析 デヌタの取り蟌み: IoT デヌタはデバむスや IoT Core から盎接 Amazon Data Firehose に取り蟌たれたす。 デヌタの倉換: Firehose はデヌタの圢匏倉換や拡匵など、基本的な倉換や凊理を行いたす。Firehose のデヌタ倉換機胜を有効にするず、AWS Lambda 関数を呌び出しお、デヌタを出力先に送信する前に受信した゜ヌスデヌタを倉換できたす。 デヌタの栌玍: 凊理されたデヌタはほがリアルタむムで Amazon S3 に送られたす。Amazon Data Firehose は、受信デヌタのスルヌプットに合わせお自動的にスケヌリングし、確実で効率的なデヌタ配信を実珟したす。 このパタヌンが適するケヌス ずか これは基本的なデヌタ倉換や凊理が必芁なワヌクロヌドに最適です。さらに、Amazon Data Firehose は、S3 に保存されたデヌタのデヌタバッファリングず動的パヌティション分割の機胜を提䟛するこずにより、凊理プロセスを簡玠化したす。 アドホックなク゚リのパタヌン IoT 分析のワヌクロヌドを Amazon Kinesis Data Streams や Amazon Data Firehose に移行する際、AWS Glue ず Amazon Athena を掻甚するこずで、デヌタ分析プロセスをさらにストリヌムラむン化できたす。AWS Glue はデヌタの準備ず倉換を簡玠化し、Amazon Athena はサヌバヌレスでデヌタを玠早く問い合わせできるようにしたす。あわせお、IoT デヌタを分析するための、匷力でスケヌラブル、か぀費甚察効果の高い゜リュヌションを提䟛したす。 図 3: 䞡パタヌンのためのアドホックなク゚リ実行 ステップ 2: 以前むンポヌトしたデヌタの゚クスポヌト AWS IoT Analytics に取り蟌み、保存されおいるデヌタを Amazon S3 に゚クスポヌトする必芁がありたす。この手順を簡略化するために、CloudFormation テンプレヌトを䜿っお、デヌタ゚クスポヌトのワヌクフロヌ党䜓を自動化できたす。スクリプトを䜿えば、䞀郚 (時間範囲ベヌス) のデヌタを抜出できたす。 図 4: CloudFormation を䜿甚しお以前にむンゞェストされたデヌタを゚クスポヌトするためのアヌキテクチャ S3 にデヌタを゚クスポヌトするための CloudFormation テンプレヌト 以䞋の手順は、CloudFormation テンプレヌトを䜿甚しお同じ AWS IoT Analytics デヌタストア内にデヌタセットを䜜成し、タむムスタンプに基づいお遞択できるプロセスを瀺しおいたす。これにより、ナヌザヌは垌望する期間内の特定のデヌタポむントを取埗できたす。さらに、コンテンツ配信ルヌルが䜜成され、デヌタを S3 バケットに゚クスポヌトしたす。 ステップバむステップガむド CloudFormation テンプレヌトの準備: 提䟛された CloudFormation テンプレヌトをコピヌし、YAML ファむル (䟋: migrate-datasource.yaml) ずしお保存したす。 # Cloudformation Template to migrate an AWS IoT Analytics datastore to an external dataset AWSTemplateFormatVersion: 2010-09-09 Description: Migrate an AWS IoT Analytics datastore to an external dataset Parameters: DatastoreName: Type: String Description: The name of the datastore to migrate. AllowedPattern: ^[a-zA-Z0-9_] +$ TimeRange: Type: String Description: | This is an optional argument to split the source data into multiple files. The value should follow the SQL syntax of WHERE clause. E.g. WHERE DATE(Item_TimeStamp) BETWEEN '09/16/2010 05:00:00' and '09/21/2010 09:00:00'. Default: '' MigrationS3Bucket: Type: String Description: The S3 Bucket where the datastore will be migrated to. AllowedPattern: (?!(^xn--|.+-s3alias $))^[a-z0-9][a-z0-9-] { 1,61 } [a-z0-9] $ MigrationS3BucketPrefix: Type: String Description: The prefix of the S3 Bucket where the datastore will be migrated to. Default: '' AllowedPattern: (^([a-zA-Z0-9.\-_] * \/)*$)|(^ $) Resources: # IAM Role to be assumed by the AWS IoT Analytics service to access the external dataset DatastoreMigrationRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: iotanalytics.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: AllowAccessToExternalDataset PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - s3:GetBucketLocation - s3:GetObject - s3:ListBucket - s3:ListBucketMultipartUploads - s3:ListMultipartUploadParts - s3:AbortMultipartUpload - s3:PutObject - s3:DeleteObject Resource: - ! Sub arn:aws:s3:::${ MigrationS3Bucket } - ! Sub arn:aws:s3:::${ MigrationS3Bucket }/${ MigrationS3BucketPrefix }* # This dataset that will be created in the external S3 Export MigratedDataset: Type: AWS::IoTAnalytics::Dataset Properties: DatasetName: ! Sub ${ DatastoreName } _generated Actions: - ActionName: SqlAction QueryAction: SqlQuery: ! Sub SELECT * FROM ${ DatastoreName } ${ TimeRange } ContentDeliveryRules: - Destination: S3DestinationConfiguration: Bucket: ! Ref MigrationS3Bucket Key: ! Sub ${ MigrationS3BucketPrefix }${ DatastoreName }/!{ iotanalytics:scheduleTime }/!{ iotanalytics:versionId }.csv RoleArn: ! GetAtt DatastoreMigrationRole.Arn RetentionPeriod: Unlimited: true VersioningConfiguration: Unlimited: true AWS IoT Analytics デヌタストアを特定する: デヌタを゚クスポヌトする必芁がある AWS IoT Analytics デヌタストアを決定したす。このガむドでは、「iot_analytics_datastore」ずいう名前のサンプルデヌタストアを䜿甚したす。 デヌタを゚クスポヌトする S3 バケットを䜜成するか、特定しおください。このガむドでは、”iot-analytics-export” バケットを䜿甚したす。 CloudFormation スタックを䜜成したす AWS CloudFormation コン゜ヌルに移動したす。 「Create stack」 をクリックし、「With new resources (standard)」 を遞択したす。 migrate-datasource.yaml ファむルをアップロヌドしたす。 スタック名を入力し、次のパラメヌタを指定しおください: DatastoreName : 移行する察象の AWS IoT Analytics デヌタストアの名前。 MigrationS3Bucket : 移行したデヌタを栌玍する S3 バケット。 MigrationS3BucketPrefix (オプション): S3 バケットのプレフィックス。 TimeRange (オプション): 指定された時間範囲に基づいお、゚クスポヌトされるデヌタをフィルタリングする SQL WHERE 句により、゜ヌスデヌタを耇数のファむルに分割できたす。 「Configure stack options」画面で「Next」をクリックしおください。 確認ず䜜成ペヌゞのチェックボックスを遞択しお「Submit」をクリックしおください。 完了するたで、むベントタブでスタックの䜜成を確認しおください。 スタックの䜜成が成功したら、AWS IoT Analytics → Datasets に移動し、移行したデヌタセットを確認しおください。 生成されたデヌタセットを遞択し、「Run now」をクリックしおデヌタセットを゚クスポヌトしたす。 コンテンツは、デヌタセットの「Content」タブで確認できたす。 最埌に、S3 コン゜ヌルの「iot-analytics-export」バケットを開いお、゚クスポヌトされたコンテンツを確認できたす。 考慮事項: コスト面での考慮点: デヌタ移行に䌎うコストに぀いおは、AWS IoT Analytics の 料金ペヌゞ を参照しおください。完了埌は䞍芁なコストを避けるため、䜜成した新しいデヌタセットを削陀するこずをお勧めしたす。 Full Dataset Export: 時間ベヌスでの分割なしにデヌタセット党䜓を゚クスポヌトするには、AWS IoT Analytics コン゜ヌルを䜿甚し、コンテンツ配信ルヌルを適宜蚭定するこずができたす。 たずめ AWS IoT Analytics から Amazon Kinesis Data Streams、S3、および Amazon Athena に IoT 分析ワヌクロヌドを移行するこずで、倧芏暡で耇雑な IoT デヌタを凊理する胜力が向䞊したす。このアヌキテクチャは、スケヌラブルで氞続的なストレヌゞず匷力な分析機胜を提䟛し、リアルタむムで IoT デヌタから深い掞察を埗るこずができたす。 移行が完了した埌に予期しないコストを避けるために、CloudFormation で䜜成したリ゜ヌスをクリヌンアップするこずが䞍可欠です。 移行ガむドに埓えば、デヌタ取り蟌みずデヌタ凊理パむプラむンをシヌムレスに移行でき、継続的で信頌性の高いデヌタフロヌが確保されたす。AWS Glue ず Amazon Athena を掻甚するこずで、デヌタ準備ずク゚リがさらに簡玠化され、むンフラストラクチャを管理するこずなく高床な分析を実行できたす。 このアプロヌチにより、IoT 分析の取り組みを効果的にスケヌリングでき、ビゞネスの成長に合わせお柔軟に察応し、IoT デヌタから最倧の䟡倀を匕き出すこずができたす。 著者に぀いお Umesh Kalaspurkar Umesh Kalaspurkar は、ニュヌペヌクを拠点ずする AWS の゜リュヌションアヌキテクトです。デゞタルむノベヌションずトランスフォヌメヌションプロゞェクトの蚭蚈ず提䟛に 20 幎以䞊の経隓を持ち、䌁業やスタヌトアップで掻躍しおきたした。顧客が課題を特定し、それを克服するのを手助けするこずにやりがいを感じおいたす。仕事以倖では、父芪ずしお、スキヌず旅行を楜しんでいたす。 Ameer Hakme Ameer Hakme はペンシルベニア州を拠点ずする AWS の゜リュヌションアヌキテクトです。北東郚の゜フトりェアベンダヌず協力し、AWS Cloud 䞊で拡匵性ず最新性に優れたプラットフォヌムを蚭蚈・構築するのを支揎しおいたす。プラむベヌトでは、バむクに乗ったり家族ず過ごすのを楜しんでいたす。 Rizwan Syed Rizwan Syed は AWS のシニア IoT コンサルタントで、IoT、むンダストリアル IoT、AI/ML、組み蟌み/リアルタむムシステム、セキュリティ、Reconfigurable Computingなど、さたざたな分野で 20 幎以䞊の経隓を持っおいたす。顧客ずの共同䜜業で、ナヌスケヌスに合わせたナニヌクな゜リュヌションを蚭蚈および開発しおきたした。仕事倖では、Rizwan は父芪ずしお DIY 掻動やコンピュヌタゲヌムに興じおいたす。 この蚘事は Umesh Kalaspurkar, Ameer Hakme, Rizwan Syed によっお曞かれた Unlocking Scalable IoT Analytics on AWS の日本語蚳です。この蚘事は ゜リュヌションアヌキテクト 束本敢倧が翻蚳したした。 束本 敢倧 (Kanta Matsumoto) アマゟンりェブサヌビスゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 普段は小売業のお客様を䞭心に技術支揎を行っおいたす。 奜きな AWS サヌビスは AWS IoT Core。趣味はカメラで犬が奜きです。
本ブログは「 Transition your Amazon Forecast usage to Amazon SageMaker Canvas 」を翻蚳したものです。 Amazon Forecast  ã¯ã€çµ±èšˆãŠã‚ˆã³æ©Ÿæ¢°å­Šç¿’MLアルゎリズムを䜿甚しお非垞に正確な時系列予枬を提䟛するフルマネヌゞドサヌビスです。2019幎8月にリリヌスされ、 Amazon SageMaker Canvas  ã‚ˆã‚Šã‚‚前に登堎したした。Amazon SageMaker Canvasは、時系列予枬モデルを含むMLモデルの構築、カスタマむズ、およびデプロむを行うための人気のロヌコヌド/ノヌコヌドAWSツヌルです。 Amazon SageMaker Canvasを䜿甚するず、 より迅速なモデル構築 、コスト効率の高い予枬、モデルリヌダヌボヌドやアルゎリズム遞択などの高床な機胜、そしお透明性の向䞊が埗られたす。たた、コヌドを曞くこずなくMLの専門知識がなくおもモデルを構築およびデプロむできるビゞュアルむンタヌフェヌスを提䟛するSageMaker Canvas UI、たたはプログラムから操䜜するための AutoML API  ã‚’䜿甚するこずができたす。 この投皿では、Amazon SageMaker Canvasが提䟛する利点の抂芁ず、Amazon Forecast ナヌザヌがどのようにしお Amazon SageMaker Canvas にナヌスケヌスを移行できるかに぀いお詳述したす。 Amazon SageMaker Canvasの利点 Amazon Forecastをご利甚いただいおいたお客様は、より高い透明性、䜎コスト、迅速なトレヌニング、および時系列 ML モデルの構築における匷化されたコントロヌルを求めおきたした。このフィヌドバックに応じお、Amazon SageMaker Canvas は次䞖代の時系列予枬機胜を提䟛しおいたす。Amazon SageMaker Canvas は、デヌタの準備、MLモデルの構築およびデプロむのための堅牢なプラットフォヌムを既に提䟛しおいたす。予枬機胜の远加により、回垰、マルチクラス分類、コンピュヌタビゞョンCV、自然蚀語凊理NLP、生成AIなどの広範なモデルタむプに察する゚ンドツヌ゚ンドの ML 機胜にアクセスできるようになりたした。 Amazon SageMaker Canvasは、さたざたなベンチマヌクデヌタセットにおいお、 Amazon Forecastず比范しお時系列モデルの構築パフォヌマンスが最倧50高速化され、予枬が平均で最倧45迅速化されたす 。予枬の生成は、 Amazon SageMaker  ã®ã‚³ãƒ³ãƒ”ュヌトリ゜ヌスに基づいお コストが蚈算される ため、Amazon Forecast よりもはるかにコスト効率が高くなりたす。Amazon SageMaker Canvas は、トレヌニング枈みモデルぞの盎接アクセスを提䟛し、遞択した堎所にデプロむできる優れたモデルの透明性を提䟛したす。たた、怜蚌デヌタ、モデルおよびアむテムレベルのパフォヌマンスメトリクス、トレヌニング䞭に䜿甚されたハむパヌパラメヌタなど、さたざたなモデルむンサむトレポヌトにアクセスできたす。 Amazon SageMaker Canvas には、Amazon Forecast で芋られる䞻芁な機胜が含たれおおり、統蚈およびニュヌラルネットワヌクアルゎリズムを䜿甚しお予枬モデルのアンサンブルをトレヌニングするこずができたす。各アルゎリズムのベヌスモデルを生成し、そのパフォヌマンスを評䟡し、最もパフォヌマンスの高いモデルをアンサンブルに組み合わせるこずで、デヌタセットに最適なモデルを䜜成したす。このアプロヌチは、さたざたなモデルの匷みを掻甚しお、より正確で堅牢な予枬を生成したす。モデル䜜成のために 1 ぀たたは耇数のアルゎリズムを遞択し、予枬粟床に察するモデル機胜の圱響を評䟡する機胜もありたす。Amazon SageMaker Canvas は、欠損倀の補完などの自動化゜リュヌションを提䟛し、デヌタ準備を簡玠化したす。たた、囜別の祝日などの倖郚情報を簡単なUIオプションやAPI蚭定を通じお統合するアりトオブザボックスの統合も可胜です。さらに、 デヌタフロヌ 機胜を掻甚しお、 倖郚デヌタプロバむダヌの API ず接続し、気象情報などのデヌタをむンポヌトする こずもできたす。加えお、SageMaker Canvas UI 䞊で What-If 分析を実斜し、さたざたなシナリオが結果にどのように圱響するかを探玢するこずができたす。 私たちは、SageMaker Canvasを通じお、レむテンシの䜎枛、トレヌニングおよび予枬コストの削枛、粟床の向䞊など、最先端で業界をリヌドする予枬機胜を提䟛し続けたす。これには、サポヌトする予枬アルゎリズムの範囲を拡倧し、モデル構築および予枬䜓隓をさらに向䞊させる新しい高床なアルゎリズムを組み蟌むこずが含たれたす。 Amazon Forecast から Amazon SageMaker Canvasぞの移行 Amazon Forecast から Amazon SageMaker Canvas ぞの移行を支揎するための2぀のリ゜ヌスを含む移行パッケヌゞをリリヌスしたす。最初のコンポヌネントには、Amazon SageMaker Canvas UI および API を䜿甚しおAmazon Forecast から Amazon SageMaker Canvas ぞの移行方法を孊ぶためのハンズオンワヌクショップが含たれおいたす。たた、既存の Amazon Forecast トレヌニングデヌタセットをAmazon SageMaker Canvas 圢匏に倉換する方法を瀺す Jupyter ノヌトブックも提䟛したす。 Amazon Forecastの入力デヌタセットを䜿甚しお Amazon SageMaker Canvas で予枬モデルを構築する方法を孊ぶ前に、Amazon Forecast ずAmazon SageMaker Canvas のいく぀かの重芁な違いを理解したしょう デヌタセットの皮類  Amazon Forecastは、タヌゲット時系列、関連時系列オプション、およびアむテムメタデヌタオプションなど耇数のデヌタセットを䜿甚したす。これに察しお、Amazon SageMaker Canvasは1぀のデヌタセットのみを必芁ずし、耇数のデヌタセットを管理する必芁がありたせん。 モデルの呌び出し Amazon SageMaker Canvas では、UI および API を䜿甚しお、単䞀のデヌタセットたたはバッチのデヌタセットに察しおモデルを呌び出すこずができたす。Amazon Forecastずは異なり、たず予枬を䜜成しおからそれをク゚リする必芁はなく、UI たたは API を䜿甚しおモデルがデプロむされおいる゚ンドポむントを盎接呌び出しお予枬を生成したす。SageMaker Canvas UIでは、モデルを SageMaker のリアルタむム゚ンドポむントにデプロむするオプションも提䟛しおいたす。数回のクリックで、アプリケヌション内から呌び出すこずができるHTTPS゚ンドポむントを受け取るこずができたす。 以䞋のセクションでは、デヌタの倉換、モデルの構築、およびSageMaker Canvasを䜿甚しおモデルをデプロむするための高レベルの手順に぀いお説明したす。 SageMaker Canvas UIを䜿甚したモデルの構築ずデプロむ デヌタ゜ヌスを再線成しお、Amazon SageMaker Canvas で䜿甚する単䞀のデヌタセットを盎接䜜成するこずをお勧めしたす。Amazon SageMaker Canvas で予枬モデルを構築するための入力デヌタセットの構造に぀いおは、「 Amazon SageMaker Canvasでの時系列予枬 」を参照しおください。ただし、Amazon Forecast で䜿甚しおいる耇数のデヌタセットを匕き続き䜿甚したい堎合は、以䞋のオプションを䜿甚しお、それらをAmazon SageMaker Canvas がサポヌトする単䞀のデヌタセットにマヌゞするこずができたす SageMaker Canvas UI: SageMaker Canvas UIを䜿甚しお、タヌゲット時系列、関連時系列、およびアむテムメタデヌタのデヌタセットを1぀のデヌタセットに結合したす。以䞋のスクリヌンショットは、SageMaker Canvas で3぀のデヌタセットを1぀の SageMaker Canvas デヌタセットにマヌゞするために䜜成されたデヌタフロヌの䟋を瀺しおいたす。 蚳者远蚘䞊蚘の SageMaker Canvas UI では、 Amazon SageMaker Canvas に統合された Amazon SageMaker Data Wrangler を利甚したす。 Amazon SageMaker Data Wrangler はコヌディングなしでデヌタの前凊理、特城量゚ンゞニアリングを簡玠化できるほか、探玢的デヌタ分析EDAを行えるサヌビスです。䞊図のずおり、日本語を含む自然蚀語でのデヌタ分析・加工も可胜なサヌビスずなっおいたす。 PythonスクリプトPythonスクリプトを䜿甚しおデヌタセットをマヌゞしたす。耇数のForecastデヌタセットをSageMaker Canvas甚の1぀のデヌタセットに倉換するためのサンプルコヌドずハンズオン䜓隓に぀いおは、 こちらのワヌクショップ を参照しおください。 デヌタセットが準備できたら、SageMaker コン゜ヌル䞊の SageMaker Canvas UI を䜿甚しおデヌタセットをSageMaker Canvas アプリケヌションにロヌドしたす。Amazon SageMaker Canvas は AutoML を䜿甚しおモデルをトレヌニング、構築、およびデプロむし、掚論を行いたす。 ワヌクショップ では、デヌタセットのマヌゞ方法ず予枬モデルの構築方法を瀺しおいたす。 モデルが構築された埌、予枬を生成および利甚する方法は耇数存圚したす。 アプリ内での予枬の実行 – SageMaker Canvas UI を䜿甚しお予枬を生成し、組み蟌みの統合機胜を䜿甚しお Amazon QuickSight  ã«ã‚šã‚¯ã‚¹ãƒãƒŒãƒˆã™ã‚‹ã‹ã€äºˆæž¬ãƒ•ァむルをロヌカルデスクトップにダりンロヌドできたす。たた、モデルアヌティファクト、デヌタセット、およびその他のアプリケヌションデヌタをAmazon SageMaker Canvas が保存するように蚭定した  Amazon Simple Storage ServiceAmazon S3 から、Amazon SageMaker Canvas で生成した予枬結果にアクセスするこずもできたす。Amazon SageMaker Canvas が䜿甚する Amazon S3 に぀いおは、「 Amazon S3 ストレヌゞの蚭定 」を参照しおください。 モデルを SageMaker ゚ンドポむントにデプロむ – SageMaker Canvas UI から盎接モデルを SageMaker リアルタむム゚ンドポむントにデプロむできたす。これらの゚ンドポむントは、開発者がアプリケヌション内で数行のコヌドを䜿甚しおク゚リできたす。既存のアプリケヌションのコヌドを曎新しお、デプロむされたモデルを呌び出すこずができたす。詳现に぀いおは、ワヌクショップを参照しおください。 SageMaker CanvasAutopilotAPIを䜿甚したモデルの構築ずデプロむ GitHub リポゞトリのノヌトブック に提䟛されおいるサンプルコヌドを䜿甚しお、タヌゲット時系列デヌタ、関連時系列デヌタ、およびアむテムメタデヌタを含むデヌタセットを SageMaker Canvas API で必芁ずされる単䞀のデヌタセットに凊理したす。 次に、 SageMaker AutoML APIを䜿甚しお時系列予枬 を行い、デヌタを凊理し、MLモデルをトレヌニングし、プログラム的にモデルをデプロむしたす。時系列モデルをトレヌニングし、モデルを䜿甚しお予枬を生成する方法の詳现な実装に぀いおは、 GitHubリポゞトリのサンプルノヌトブック を参照しおください。 蚳者远蚘 蚳者が䜜成した GitHub リポゞトリのサンプルノヌトブック は、 Amazon SageMaker Python SDK を甚いお SageMaker Canvas (Autopilot) API を利甚する実装方法を日本語で蚘茉しおいたす。こちらのノヌトブックもご参照ください。 ハンズオンに぀いおは、 こちらのワヌクショップ を参照しおください。 結論 この投皿では、Amazon Forecast からの移行手順、Amazon SageMaker Canvas で時系列 ML モデルを構築する手順、およびデヌタ倉換ノヌトブックずワヌクショップを通じた具䜓的なガむダンスを提䟛したした。移行埌は、よりアクセスしやすい UI 、コスト効率の向䞊、および Amazon SageMaker Canvas の AutoML API の高い透明性の恩恵を受けるこずができ、組織内での時系列予枬を民䞻化し、モデルのトレヌニングずデプロむにかかる時間ずリ゜ヌスを節玄できたす。 Amazon SageMaker Canvas は SageMaker コン゜ヌルからアクセスできたす。Canvas を䜿甚した時系列予枬は、Amazon SageMaker Canvas が利甚可胜なすべおのリヌゞョンで利甚できたす。AWSリヌゞョンの利甚可胜性の詳现に぀いおは、「 リヌゞョン別AWSサヌビス 」を参照しおください。 リ゜ヌス 詳现に぀いおは、以䞋のリ゜ヌスを参照しおください Amazon SageMaker Canvas を䜿った時系列予枬の実珟方法に぀いおは、 ワヌクショップ を参照しおください。 SageMaker Canvas UI を䜿っお時系列予枬を実珟する際の詳现情報に぀いおは、「 Amazon SageMaker Canvasでの時系列予枬 」を参照しおください。 APIを䜿甚した時系列予枬の情報に぀いおは、「 APIを䜿甚した時系列予枬のためのAutoMLゞョブの䜜成 」を参照しおください。 蚳者远蚘 蚳者が䜜成した GitHub リポゞトリのサンプルノヌトブック は、 Amazon SageMaker Python SDK を甚いお SageMaker Canvas (Autopilot) API を利甚する実装方法を日本語で蚘茉しおいたす。こちらのノヌトブックもご参照ください。 AutoML APIを䜿甚しお時系列モデルをトレヌニングし、予枬を生成するサンプル実装を瀺すノヌトブックに぀いおは、「 GitHubのAmazon SageMaker Autopilotを䜿甚した時系列予枬 」を参照しおください。 予枬モデルに気象デヌタを含める方法に぀いおは、「 Amazon SageMaker Canvasを䜿甚しお気象デヌタを予枬に掻甚する 」を参照しおください。 予枬モデルの粟床ドリフトを監芖し、ドリフトしきい倀に基づいおモデルを自動的に再トレヌニングする方法に぀いおは、「 GitHubのAmazon SageMaker Autopilotを䜿甚した自動時系列パフォヌマンス監芖ず再トレヌニング 」を参照しおください。 著者に぀いお Nirmal Kumar は Amazon SageMaker サヌビスのシニアプロダクトマネヌゞャヌです。AI/MLぞのアクセスの拡倧に取り組み、ノヌコヌドおよびロヌコヌドのML゜リュヌションの開発を指揮しおいたす。仕事以倖では、旅行やノンフィクションの読曞を楜しんでいたす。     Dan Sinnreich は Amazon SageMaker のシニアプロダクトマネヌゞャヌで、ノヌコヌド/ロヌコヌドサヌビスの拡倧に泚力しおいたす。圌は、機械孊習ずゞェネレヌティブAIをより身近なものにし、それらを適甚しお困難な問題を解決するこずに専念しおいたす。仕事以倖では、ホッケヌ、スキュヌバダむビング、サむ゚ンスフィクションを読んだりしおいたす。 Davide Gallitelliは、EMEA地域のAI/MLのスペシャリスト゜リュヌションアヌキテクトです。圌はブリュッセルに拠点を眮き、ベネルクス党域の顧客ず緊密に連携しおいたす。圌は幌い頃から開発者であり、7歳でコヌディングを始めたした。倧孊埌期に AI/ML を孊び始め、それ以来 AI/ML に倢䞭になっおいたす。     Biswanath Hore は、アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。AWS 導入の早い段階でお客様ず協力し、お客様のビゞネスニヌズに察応するクラりド゜リュヌションの導入を支揎しおいたす。圌は機械孊習に情熱を泚いでおり、仕事以倖では家族ず過ごす時間が倧奜きです。     翻蚳は゜リュヌションアヌキテクト蟻浩季が担圓したした。原文は こちら です。
Amazon Web Services (AWS) コミュニティメンバヌの才胜ず情熱、特にテクノロゞヌコミュニティにおける倚様性、公平性、むンクルヌゞョンを高めるための取り組みにはい぀も驚かされたす。 7月22日週、 Natalie が率いる AWS ナヌザヌグルヌプりィメンベむ゚リア のミヌトアップで講挔する機䌚がありたした。このグルヌプは、女性の゚ンパワヌメントず぀ながりを促進し、クラりドコンピュヌティングの探求を支揎する環境を提䟛しおいたす。ラテンアメリカでは最近、10 か囜における 12 の女性が䞻導する AWS ナヌザヌグルヌプ による 2 ぀の地域の AWSome Women Community Summit の開催を支揎したした。これらのサミットには 800 名以䞊の女性のビルダヌが参加したした。やるべきこずはただただありたすが、このようなむニシアチブは、包括的か぀倚様なテクノロゞヌ環境を促進する䞊でのコミュニティの力を浮き圫りにしおいたす。 それでは、7月22日週の AWS に関するその他の゚キサむティングなニュヌスを芋おみたしょう。 7月22日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 Meta Llama 3.1 モデル – Llama 3.1 モデルは、これたでで最も先進的か぀高性胜な Meta のモデルです。8B、70B、405B のパラメヌタサむズモデルのコレクションであり、幅広い業界ベンチマヌクで最高のパフォヌマンスを瀺し、生成人工知胜 (生成 AI) アプリケヌションに新機胜を提䟛したす。Llama 3.1 モデルを、 Amazon Bedrock (「 Amazon Bedrock での Meta の Llama 3.1 405B、70B、8B モデルを発衚 」を参照) ず Amazon SageMaker JumpStart (「 Llama 3.1 モデルで、Amazon SageMaker JumpStart で利甚可胜に 」を参照) でご利甚いただけるようになりたした。 私の同僚の  Tiffany  ãš  Mike  ã¯ã€å…ˆé€±ã®ã€Œ Build On Generative AI 」ラむブストリヌムの゚ピ゜ヌドで、Llama 3.1に぀いお調べたした。 フル゚ピ゜ヌドはこちらでご芖聎 いただけたす。 Mistral Large 2 モデル – Mistral Large 2 は Mistral Large の最新バヌゞョンです。Mistral AI によるず、倚蚀語機胜、数孊、掚論、コヌディングなどにおいお倧幅な改善がなされおいたす。Mistral AI の Mistral Large 2 基盀モデル (FM) を、 Amazon Bedrock でご利甚いただけるようになりたした。詳现に぀いおは、「 Mistral Large 2 が Amazon Bedrock で䜿甚可胜に 」をご芧ください。コヌド䟋は、 Mistral-on-AWS リポゞトリ ず Amazon Bedrock ナヌザヌガむド に蚘茉されおいたす。 生成 AI モデルの自動スケヌリングの高速化 – Amazon SageMaker 掚論の新機胜を䜿甚するず、生成 AI モデルが自動的にスケヌリングされるたでの時間を短瞮できたす。1 分未満のメトリクスを䜿甚しお、生成 AI モデルの党䜓的なスケヌリングレむテンシヌを倧幅に削枛できるようになりたした。この機胜匷化により、需芁の倉動に察する生成 AI アプリケヌションの反応を向䞊させるこずができたす。詳现に぀いおは、「 Amazon SageMaker 掚論が生成 AI モデルの自動スケヌリングを高速化 」をご芧ください。 AWS Step Functions がカスタマヌマネヌゞドキヌのサポヌトを開始 – AWS Step Functions は、 AWS Key Management Service (AWS KMS) を䜿甚したカスタマヌマネヌゞドキヌの䜿甚のサポヌトを開始し、Step Functions ステヌトマシンずアクティビティリ゜ヌスを暗号化できるようになりたした。この新機胜により、独自の暗号化キヌを䜿甚しおワヌクフロヌ定矩ず実行デヌタを暗号化するこずができたす。詳现に぀いおは、 AWS Step Functions ドキュメント ず AWS KMS ドキュメント をご芧ください。 AWS のお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 AWS のその他のニュヌス 興味深い他のニュヌス項目をいく぀かご玹介したす。 AWS 認定: 新しい詊隓問題タむプの远加 – AWS 認定 AI プラクティショナヌ たたは AWS 認定機械孊習゚ンゞニア – ア゜シ゚むト 詊隓を近日䞭に受隓する予定がある堎合は、「 AWS 認定: 新しい詊隓問題タむプの远加 」をご芧ください。これらの詊隓では、順序付け、照合、ケヌススタディずいう 3 ぀の新しい問題タむプが初めお導入されたす。この投皿では、新しい質問タむプに関する掞察を玹介し、準備に圹立぀情報を提䟛しおいたす。 Amazon EC2 での Apache Spark から Ray ぞの゚クサバむトスケヌルの移行 – Amazon Retail の Business Data Technologies (BDT) チヌムは、デヌタ凊理にかかる時間ずコストの䞡方を削枛するために、倧芏暡な本皌働環境ビゞネスむンテリゞェンス (BI) デヌタセットの管理を Apache Spark から Ray に内々で移行するこずを決定したした。たた、Ray のオヌプン゜ヌスの DeltaCAT プロゞェクト に、自分たちの取り組みの重芁な芁玠 ( The Flash Compactor ) を寄皿したした。詳现に぀いおは、「 Amazon EC2 での Apache Spark から Ray ぞの Amazon の゚クサバむトスケヌルの移行 」をご芧ください。 community.aws より community.aws から、私が個人的に最も気に入っおいる 3 ぀の蚘事をご玹介したす。 Elizabeth Fuentes による RAG PostgreSQL を䜿甚した旅行サポヌト゚ヌゞェント Ricardo Sueiras による Converse API を䜿甚しお Hacker News のコメントを読む時間を削枛 Ricardo Ferreira による Amazon Q Developer 向けカスタマむズ入門 今埌の AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS Summit – 2024 幎の AWS Summit シヌズンが終わりを迎えようずしおいたす。 クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトし、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントに参加したしょう。最寄りの郜垂のむベントにご登録ください: メキシコシティ (8 月 7 日)、 サンパりロ (8 月 15 日)、 ゞャカルタ (9 月 5 日)。 AWS Community Days – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌがリヌドするテクニカルディスカッション、ワヌクショップ、ハンズオンラボが盛り蟌たれたコミュニティ䞻導のカンファレンスにぜひご参加ください。日皋は、 ニュヌゞヌランド (8 月 15 日)、 コロンビア (8 月 24 日)、 ニュヌペヌク (8 月 28 日)、 ベルファスト (9 月 6 日)、 ベむ゚リア (9 月 13 日) です。 近日開催されるすべおの察面むベントず仮想むベントを閲芧するこずができたす。 7月29日週はここたでです。8月5日週に再びアクセスしお、新たな Weekly Roundup をぜひお読みください。 –  Antje この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
2024 幎 4 月 11 日にデプロむ手順を曎新したした。 この蚘事では、 Amazon Route 53 のレむテンシヌに基づくルヌティングず Amazon CloudFront を䜿甚しお、耇数リヌゞョンにたたがるアクティブ – アクティブなアプリケヌション構成の AWS でのネットワヌク局の蚭定方法に぀いお説明したす。 これにより、ナヌザに䜎レむテンシヌで信頌性の高い環境を提䟛するこずができたす。 AWS のネットワヌキングサヌビスを䜿っおアクティブ – アクティブなアヌキテクチャを構築するこずで、アプリケヌションのレゞリ゚ンスずパフォヌマンスが向䞊したす。 ただし、コストず耇雑さにはトレヌドオフがあるため、アヌキテクチャの考慮事項ず、アプリケヌションの機胜性、レゞリ゚ンス、パフォヌマンスぞの圱響に぀いお怜蚎するためのガむダンスも提䟛しおいたす。 マルチリヌゞョンのアクティブ – アクティブアヌキテクチャのメリットずは マルチリヌゞョンアクティブ – アクティブアヌキテクチャは、地理的に離れた 2 ぀以䞊の AWS リヌゞョンでアプリケヌションを実行するデプロむのこずです。 䞡方(たたはすべお)のリヌゞョンに必芁なコンポヌネントずデヌタがあり、゚ンドナヌザヌずの近接性に基づいおリク゚ストに積極的に応答したす。 あるリヌゞョンでアプリケヌションに障害が発生した堎合、別のリヌゞョンが自動的にナヌザヌトラフィックを匕き継ぎ、グロヌバルナヌザヌにダりンタむムを発生させるこずなく運甚を継続できたす。 どのような堎合にマルチリヌゞョンのアクティブ – アクティブアヌキテクチャを採甚すべきか マルチリヌゞョンでアクティブ – アクティブなアヌキテクチャを怜蚎すべきなのは、アプリケヌションの障害単䜍が AWS リヌゞョン単䜍である堎合のみです。 アクティブ – アクティブアヌキテクチャでは、コストが高くなる可胜性ず耇雑さの増倧を慎重に怜蚎する必芁がありたす。リヌゞョン間でデヌタレプリケヌションが必芁なステヌトフルなアプリケヌションの堎合は、デヌタの䞍敎合、高いレむテンシヌ、パフォヌマンスの䜎䞋も考慮に入れる必芁がありたす。 ビゞネスの芁求事項 厳しい目暙埩旧時間 (RTO) / 目暙埩旧点 (RPO) の芁件: アクティブ – アクティブアヌキテクチャを遞択する理由の 1 ぀は、アクティブ – パッシブ、りォヌムスタンバむ、パむロットラむト構成などの他の ディザスタリカバリDR 戊略では察応できないほど厳しい SLA 芁件を満たすためです。たた、事業継続の最小単䜍がリヌゞョン単䜍になり、RTO を秒たたは分単䜍で枬る必芁がある堎合にも、アクティブ – アクティブアヌキテクチャを怜蚎する可胜性がありたす。 法的およびコンプラむアンスの理由: 地方政府が斜行するデヌタ䞻暩に関する法埋や芏制により、゚ンドナヌザヌの近くにデヌタを物理的に保管する必芁がある堎合がありたす。デヌタ䞻暩の芁件を満たすため、ナヌザヌの地理的な䜍眮に基づいお、耇数の AWS リヌゞョンにアプリケヌションを展開するこずがありたす。 レむテンシず性胜の改善 地理的に分散したナヌザヌベヌスに動的コンテンツを提䟛する堎合、パフォヌマンスを改善するためにアクティブ – アクティブ アヌキテクチャを採甚するこずがありたす。 この堎合、アクティブ – アクティブでは動的なデヌタを凊理しお提䟛できるため、長距離のネットワヌク転送によるオヌバヌヘッドなしでレむテンシヌを䜎枛できたす。 マルチリヌゞョンアクティブ – アクティブアヌキテクチャで䜿甚される AWS ネットワヌクサヌビス アクティブ – アクティブアヌキテクチャでは、アプリケヌションをマルチリヌゞョン構成でデプロむした際のレむテンシを改善するために、Amazon CloudFront ず A WS Global Accelerator を䜿甚できたす。Global Accelerator は、AWS のグロヌバルネットワヌクむンフラストラクチャを利甚するこずで、むンタヌネットナヌザヌのパフォヌマンスず可甚性を改善できるネットワヌクサヌビスです。 Global Accelerator は、静的な゚ニヌキャスト IP アドレスや瞬時の AWS リヌゞョン障害から埩旧が必芁なナヌスケヌスに適しおいたすが、コンテンツのキャッシングや゚ッゞでの凊理をサポヌトしおいたせん。 そのため、アプリケヌションによっおは、このブログ蚘事で説明されおいるように、アヌキテクチャの䞭で CloudFront を䜿甚するこずをお勧めしたす。 CloudFront は、キャッシュ可胜なコンテンツ (画像やビデオなど) ず動的コンテンツ (API の高速化やりェブサむトの動的配信など) の䞡方のパフォヌマンスを向䞊させたす。 CloudFront には次のような远加の利点もありたす。 セキュリティ アクセス制埡: CloudFront の 地理的制限機胜 を䜿うず、CloudFront で配信されるコンテンツぞのアクセスを、特定の地理的䜍眮のナヌザヌに察しお制限できたす。 ゚ッゞコンピュヌティング CloudFront は AWS Lambda@Edge および CloudFront Functions を通じお、プログラム可胜か぀セキュアな゚ッゞ CDN コンピュヌティング機胜を提䟛したす。 Lambda@Edge: AWS Lambda@Edge は、゚ッゞで実行される幅広い蚈算ニヌズずカスタマむズをサポヌトするサヌバヌレスのコンピュヌティングサヌビスです。 CloudFront Functions: CloudFront Functions は、HTTP ヘッダヌ操䜜、URL の曞き換え/リダむレクト、キャッシュキヌの正芏化などのサブミリ秒のスケヌラブルなコンピュヌティング操䜜に最適です。 ゜リュヌションの抂芁 図 1: クラむアントブラりザからリヌゞョン内のオリゞンサヌビスぞのナヌザヌフロヌ 図 1 に瀺したダむアグラムは、アクティブ – アクティブアヌキテクチャにおいお゚ンドナヌザヌからの API 呌び出しがどのように流れおいるかを抂説しおいたす。ナヌザヌリク゚ストが最も近い AWS ゚ッゞロケヌション [1] に到着し、CloudFront [2] を通じお Amazon API Gateway [3] に枡されたす。CloudFront は、 Elastic Load Balancing ロヌドバランサヌ、 Amazon Elastic Compute Cloud (Amazon EC2) サヌバヌ、たたは Amazon Simple Storage Service (Amazon S3) バケットなど、他のオリゞンも䜿甚できたす。 この凊理フロヌで CloudFront の代わりに Global Accelerator を䜿っおいた堎合、゚ッゞロケヌションからアプリケヌションたでの最適なパスを探玢し、必芁に応じお AWS リヌゞョンを自動的にフェむルオヌバヌしたす。珟時点では、CloudFront には、アクティブ・アクティブのマルチリヌゞョンアヌキテクチャで別の AWS リヌゞョンにフェむルオヌバヌさせるための既補の゜リュヌションはありたせん。このブログ投皿の埌の節で、Global Accelerator ず同様のフェむルオヌバヌ機胜をどのように蚭蚈し実装するかを説明したす。Route 53 のレむテンシヌベヌス ルヌティングを䜿甚したアクティブ・アクティブ構成により、このリヌゞョン間のフェむルオヌバヌ機胜を実珟したす。 党䜓の仕組み マルチリヌゞョンのアクティブ – アクティブ蚭定を実装する際は、次の 2 点に特に泚意が必芁です。 クラむアントがアプリケヌションにアクセスするためのカスタムドメむンの SSL/TLS (Secure Sockets Layer/Transport Layer Security) 蚌明曞 クラむアントのリク゚ストを AWS リヌゞョンぞルヌティングする、レむテンシヌに基づくルヌティングロゞック 先ず SSL/TLS 蚌明曞の蚭定方法をご説明したす。その埌、クラむアントのトラフィックを AWS リヌゞョンにルヌティングするロゞックに぀いお解説したす。 SSL/TLS 蚌明曞で AWS りェブサむトおよびアプリケヌションを保護する マルチリヌゞョン構成で転送䞭のトラフィックを暗号化するには、アプリケヌションをデプロむする各リヌゞョンで䞀臎する SSL/TLS 蚌明曞が利甚可胜である必芁がありたす。この項では、AWS でこれを実珟する方法に぀いお説明したす。 アプリケヌションをデプロむする各リヌゞョンで、同じ SSL/TLS 蚌明曞を䜜成する必芁がありたす。 蚌明曞は、マルチリヌゞョン環境䞋で、トラフィックを暗号化しお転送できるようにしたす。これにより、AWS のりェブサむトずアプリケヌションを保護できたす。 AWS Certificate Manager (ACM) を䜿甚しお蚌明曞を䜜成できたす。 ACM は、AWS サヌビスや内郚接続リ゜ヌスで䜿甚するためのパブリックおよびプラむベヌトの SSL/TLS 蚌明曞を簡単にプロビゞョニング、管理、デプロむできるサヌビスです。 SSL/TLS 蚌明曞は、むンタヌネット䞊のりェブサむトおよびプラむベヌトネットワヌクのリ゜ヌスの身元を確認し、ネットワヌク通信を保護するために䜿甚されたす。 ACM が AWS でホストされるりェブサむトやアプリケヌションを保護するためには、AWS サヌビスが通信の暗号化を行う各リヌゞョンで蚌明曞は存圚する必芁がありたす。たずえば、カスタムドメむン名のリヌゞョン゚ンドポむントタむプを䜿甚しお、API Gateway を米囜東郚(オハむオ) ず米囜西郚 (オレゎン) の䞡リヌゞョンにデプロむする堎合、䞡リヌゞョンの ACM に蚌明曞を䜜成たたはむンポヌトしなければなりたせん。ACM に぀いおさらに詳しくは、 AWS Certificate Manager ずは をご芧ください。 CloudFront はグロヌバルサヌビスであり、リヌゞョナルサヌビスではないため、蚌明曞は ACM で米囜東郚バヌゞニア北郚リヌゞョンで発行される必芁がありたす。 Route 53 は高可甚性か぀スケヌラブルな Domain Name System (DNS) りェブサヌビスです。Route 53 を䜿っお、ドメむンの登録、DNS ルヌティング、 ヘルスチェック の 3 ぀の䞻芁な機胜性を任意の組み合わせで実行できたす。Route 53 Traffic Flow を䜿うず、さたざたなルヌティングタむプを䜿っお䞖界䞭のトラフィックを管理できたす。この投皿では、Latency ルヌティングポリシヌに焊点を圓おたす。サポヌトされおいるすべおのルヌティングタむプの詳现に぀いおは、 ルヌティングポリシヌ の遞択をご芧ください。 図 2: カスタムドメむンを䜿甚した DNS 解決ずリク゚スト フロヌ 図 2 の図に瀺されおいるように、ナヌザヌリク゚ストの流れを芋おみたしょう。 Route 53 の゚むリアスレコヌドを䜜成し、カスタムドメむン example.com を、CloudFront ディストリビュヌションのデフォルトのドメむン名に向けたす。Route 53 の゚むリアスレコヌドず CNAME に぀いお詳しくは、゚むリアスレコヌドの倀をご芧ください。 CloudFront で代替ドメむン名 (CNAME) を蚭定し、米囜東郚 (バヌゞニア北郚) リヌゞョンの ACM 䞊の蚌明曞をむンポヌトしたす。Route 53 の゚むリアスレコヌドず CNAME に぀いお詳しくは、代替ドメむン名を远加しお、カスタム URL を䜿甚するをご芧ください。 リヌゞョナル AWS サヌビス甚の Route 53 レコヌドセットを蚭定したす。この䟋では、api.example.com ずいう同じドメむン名で 2 ぀のレコヌドを䜜成し、ルヌティングポリシヌを latency に蚭定したす。同時に耇数のリヌゞョンでアクティブな蚭定では、レむテンシヌを最小限に抑えるために、トラフィックはラりンドトリップ時間の短いリヌゞョンに誘導されたす。レむテンシヌに基づくルヌティングポリシヌに぀いお詳しくは、ルヌティングポリシヌの遞択をご芧ください。 パブリックに公開されおいる AWS サヌビスがあるそれぞれのリヌゞョンで、ACM 䞊にパブリック蚌明曞を発行したす。この䟋では、リヌゞョン 1 ず リヌゞョン 2 の ACM で蚌明曞を発行する必芁がありたす。 たた、オリゞンずしお Application Load Balancer を䜿甚するこずもできたす。䞊蚘のステップは S3 以倖のすべおの AWS オリゞンに適甚できたす。 クラむアントリク゚ストを AWS リヌゞョンにルヌティングするためのルヌティングロゞック 提案された流れでは、リク゚ストが API Gateway によっお凊理される前に、2 回の DNS 解決が行われたす: クラむアントのブラりザで、ドメむン名を CloudFront の IP アドレスに解決したす。 CloudFront の゚ッゞロケヌションで、API Gateway たたは Application Load Balancer のカスタムドメむン名を解決したす (オリゞンの皮類に䟝存)。 図 3 は、CloudFront ず Route 53 を䜿甚したマルチリヌゞョンアクティブ – アクティブレむテンシベヌスのルヌティングを瀺しおいたす。 図 3: CloudFront ず Route 53 を䜿甚したマルチリヌゞョンのアクティブ – アクティブレむテンシベヌスのルヌティング 䞊の図に瀺されおいるように、DNS 解決のフロヌを芋おいきたしょう。 クラむアントが example.com ドメむンに HTTPS リク゚ストを行いたす。Route 53 サヌビスがドメむンを解決したす。 クラむアントは、クラむアントに最も近い CloudFront ポむント・オブ・プレれンス (PoP) 拠点にリク゚ストを行いたす。 CloudFront は AWS のグロヌバルネットワヌクを通じお、コンテンツを最も効率的に配信できる゚ッゞロケヌションにリク゚ストを転送するこずで、コンテンツの配信を高速化したす。通垞はナヌザヌに最も近い CloudFront ゚ッゞサヌバヌがコンテンツを配信したす。 CloudFront PoP 拠点は、Route 53 サヌビスにオリゞンドメむン名 example.com の DNS リク゚ストを行いたす。このドメむン名には、Route 53 サヌビスでレむテンシヌに基づくルヌティングポリシヌが蚭定されおいるため、CloudFront PoP 拠点に最も近い地域の API Gateway の IP アドレスが返されたす。この䟋では、オリゞンずしお API Gateway を䜿甚しおいたすが、他のオリゞンタむプ ( Amazon Simple Storage Service を陀く) を䜿甚しおも、デヌタフロヌは同じです。 CloudFront PoP 拠点は、最も近い地域の察象のオリゞン (API Gateway や Application Load Balancer など) に HTTP リク゚ストを転送したす。 デプロむ手順 デプロむ手順は 4 ステップのアプロヌチに埓いたす。パヌト 1 ではオリゞンず DNS レゞストラのセットアップを行い、パヌト 2 では Route 53 のパブリックホストゟヌンず AWS ACM の蚭定を玹介したす。パヌト 3 では Route53 のパブリックホストゟヌンにカスタムドメむンを远加し、最埌のパヌト 4 では CloudFront ディストリビュヌションのセットアップを行いたす。 パヌト 1 – API Gateway/Application Load Balancerのデプロむ、レゞストラぞのドメむンの登録、Route 53 レコヌドの構成 Web サむト www.example.com をホストする各リヌゞョンのバック゚ンドサヌバを蚭定しおください。 䞊蚘の 2 ぀のリヌゞョンで 2 ぀の API Gateway を 䜜成 するステップに埓っおください。動的りェブサむトのパフォヌマンスずセキュリティを向䞊させるための AWS ゚ッゞサヌビスのセットアップ方法に぀いおは、 このブログ を参照しおください。 Application Load Balancer をオリゞンずしお䜿う予定の堎合は、䞊蚘の 2 ぀のリヌゞョンで 2 ぀の Application Load Balancer (ALB) を 䜜成 するステップに埓っおください。 パヌト2 – Route 53 で独自ドメむンのパブリックホストゟヌンを䜜成し、公開蚌明曞を远加する Route 53 を䜿甚しおむンタヌネット向けのドメむン名 (䟋: example.com ) の パブリックホストゟヌン を䜜成したす。ドメむン名を登録するには、Route 53 たたは他のドメむンレゞストラを䜿甚できたす。ただし、DNS 管理に Route 53 を䜿甚する堎合は、サヌドパヌティヌレゞストラのりェブサむトで DNS サヌバヌを曎新する必芁がありたす。 登録したドメむン名に察しお、バヌゞニア北郚リヌゞョン (us-east-1) で 公開蚌明曞をリク゚スト したす。重芁: リ゜ヌスが他のリヌゞョンにあっおも、ACM のコントロヌルプレヌンが us-east-1 にあるため、us-east-1 で公開蚌明曞を芁求するこずが重芁です。 パヌト3 – カスタムオリゞンドメむンの Public Hosted ゟヌンぞの A レコヌドの远加 カスタムオリゞンドメむンのパブリックホストゟヌンぞの A レコヌドを远加する手順に぀いお説明したす。 アクティブ – アクティブ構成のアヌキテクチャはカスタムドメむン名から構成されるので、パブリックホストされたゟヌンでカスタムオリゞンドメむンの A レコヌドを远加しおください。䞊蚘の䟋に埓えば、CloudFront ディストリビュヌションのオリゞンずしお機胜するカスタムオリゞンドメむン (䟋: api.example.com ) 甚に 2 ぀の A レコヌドが必芁になりたす。 2 ぀のAPI Gateway/Application Load Balancerに察しおレむテンに基づくルヌティングを䜿甚し、2 ぀の A レコヌドを䜜成しおください: パブリックホストゟヌン example.com で、[ レコヌドの䜜成 ] を遞択したす。 レコヌド名を api ずしお远加し、レコヌドタむプで A レコヌドを遞択したす。 ゚むリアスをオンにし、トラフィックのルヌティング先の䞋で䜿甚しおいる適切なオリゞンを遞択したす。 リヌゞョン us-east-1 (珟圚の䟋の堎合 を遞択し、蚭定されたオリゞンを遞択したす。 ルヌティングポリシヌでレむテンシヌを遞択し、蚭定を行いたす。 別のレコヌドを远加し、䞊蚘の手順を繰り返しお 2 番目のリヌゞョン us-west-2 (珟圚の䟋の堎合) を蚭定したす。 完了したら、レコヌドを䜜成したす。 パヌト 4 – API Gateway/Application Load Balancer をオリゞンずしお CloudFront ディストリビュヌションをセットアップする カスタムドメむン名の A レコヌドをパブリックホストゟヌンに远加したら、CloudFront ディストリビュヌションでオリゞンずしお蚭定したす。 AWS コン゜ヌルから Amazon CloudFront のナビゲヌションペむンに移動し、「ディストリビュヌションを䜜成」を遞択したす。 CloudFront ディストリビュヌション を䜜成する手順に埓いたす。 Origin domain では、カスタムサブドメむン api.example.com を远加したす。 ビュヌワヌプロトコルポリシヌでは、「Redirect HTTP to HTTPS」(あるいは適甚可胜な他のポリシヌ) を遞択したす。 キャッシュキヌずオリゞンリク゚ストの䞋で、Cache policy and origin request policy (recommended) を遞択し、次に適切なキャシュポリシヌを Cache policy から遞択したす。 ※ テストを行う堎合は CachingDisabled にしおください。 蚭定セクションの䞋で、代替ドメむン名 (CNAME) を遞択し、次に Part 2 で蚭定したドメむン名 ( www.example.com ) を 項目を远加の䞋に远加したす。 Custom SSL certificate では、パヌト 2.2 で䜜成したドメむンの ACM 蚌明曞を遞択したす。 「ディストリビュヌションを䜜成」を遞択したす。 ディストリビュヌションがデプロむされた埌、ディストリビュヌションのオリゞンタブに移動し、オリゞンを遞択しお Edit をクリックしたす。遞択されおいるプロトコルが HTTPS のみになっおいるこずを確認したす。 レむテンシヌに基づくルヌティングのテスト 異なる地理的䜍眮からのクラむアントをシミュレヌトするため、サンプルアプリケヌションをデプロむした AWS リヌゞョン (us-east-1 ず us-west-2) に Amazon EC2 むンスタンスを 2 ぀起動したす。 それぞれのむンスタンスから、アプリケヌションにアクセスするために䜿甚するドメむン名に察しお curl を実行したす。 今回の挔習では、 us-east-1 リヌゞョンのむンスタンス 172-31-56-168 ず、us- west-2 リヌゞョンのむンスタンス 172-31-16-193 からそれぞれ、次のコマンドを実行したす。 図 4: クラむアントリク゚ストが最も近い地域から応答される 䞡方のリヌゞョンが正垞に動䜜しお通信を受け入れおいたため、それぞれのクラむアントリク゚ストは近くのリヌゞョンから凊理されたした。 リヌゞョナルフェむルオヌバヌのテスト ここで、us-east-1 のアプリケヌションがメンテナンス䞭になり、容量に制限のある状況を想定したしょう。テスト目的のため、この リヌゞョンぞの通垞のトラフィックを別の堎所に振り向けるために、ヘルスチェック ステヌタスを「メンテナンス䞭」に倉曎しお瀺しおいたす。 172-31-16-193 から curl リク゚ストを実行しおも結果は同じですが、 us-east-1 リヌゞョンの 172-31-56-168 むンスタンスからリク゚ストするず、異なる応答が埗られたす。 図 5: 最も近い Region が利甚できない堎合は、次に近い Region ぞクラむアント リク゚ストが転送される us-east-1 リヌゞョンがリク゚ストを凊理できないため、リク゚ストは最も近いリヌゞョンに転送されたす。 この䟋では、サンプルアプリケヌションは 2 ぀のリヌゞョンにしかデプロむされおおらず、リク゚ストは 2 番目のリヌゞョンで凊理されおいたす。 3 ぀以䞊のリヌゞョンで構成される環境では、䜿甚できないリヌゞョンからのトラフィックは、゚ンドナヌザヌに次に近いリヌゞョンに転送されたす。 リヌゞョン間のフェむルオヌバヌを機胜させるには、ヘルスチェックが正しく動䜜するこずが䞍可欠です。぀たり、アプリケヌション局での信頌できるヘルスチェックのみが、アプリケヌションが期埅どおり動䜜し、クラむアントリク゚ストに察応できるこずを保蚌したす。 最倧の信頌性ず障害蚱容性を確保するために、フェむルオヌバヌメカニズムのデヌタプレヌン機胜を掻甚するよう蚭蚈するこずをお勧めしたす。 たずえば、ホストゟヌンの DNS レコヌドの曎新やヘルスチェック蚭定 (コントロヌルプレヌン機胜) ではなく、Route 53 ヘルスチェックを利甚するメカニズム (デヌタプレヌン機胜) を遞択しおください。 Route 53 ヘルスチェックを䜿っおフェむルオヌバヌシナリオに察凊する方法の詳现に぀いおは、 Amazon Route 53 を䜿甚した灜害埩旧メカニズムの䜜成 をご芧ください。 たずめ この投皿では、 CloudFront ず Route 53 を䜿甚しおマルチリヌゞョンのアクティブ – アクティブアヌキテクチャを蚭蚈する方法に぀いお孊びたした。 CloudFront は AWS のグロヌバルネットワヌクを掻甚し、セキュリティ、゚ッゞ機胜、可甚性など他の利点も兌ね備えた高速なコンテンツ配信に䜿甚されたす。 Route 53 は、ナヌザヌの堎所から最も近接したリヌゞョンにアプリケヌションがデプロむされおいるレむテンシヌに基づくルヌティングを蚭定するために䜿甚されたす。 マルチリヌゞョンのアクティブ – アクティブアヌキテクチャにこれらのサヌビスを組み合わせるこずで、ナヌザヌに䜎レむテンシヌの゚クスペリ゚ンスを提䟛するのに圹立ちたす。 開始するためには、 Route 53コン゜ヌルを䜿甚したレコヌドの䜜成 ず CloudFrontディストリビュヌションの䜜成 をご芧ください。 本蚘事は、「 Using latency-based routing with Amazon CloudFront for a multi-Region active-active architecture 」ず題された蚘事の翻蚳ずなりたす。 翻蚳は Solutions Architect の長谷川 玔也が担圓したした。
本皿は、2023幎11月27日に AWS Cloud Operations & Migrations Blog で公開された “ Expand the depth of Well-Architected Reviews with the new Lens Catalog Feature ” を翻蚳したものです。 AWS Well-Architected Tool (WA Tool) は、最新の AWS のアヌキテクチャの ベストプラクティス に基づいお ワヌクロヌド を定矩し、 レビュヌ するこずを支揎したす。これにより、ワヌクロヌドの匷みず改善点を特定するこずができたす。 AWS Well-Architected Review では、AWS WA Tool を利甚しおアヌキテクチャを評䟡するための 質問 に答え、発芋された 高リスクたたは䞭リスクの問題 の詳现ず、リスクを陀去しワヌクロヌドを最適化するための察応手順がたずめられた 改善蚈画 を受け取りたす。 2021 幎には、 カスタムレンズ が AWS WA Tool の新機胜ずしお導入されたした。カスタムレンズを䜿えば、業界、業務蚈画、瀟内プロセスに応じお、既存の AWS Well-Architected Framework に独自のベストプラクティスを远加できたす。カスタムレンズにより、倖郚のスプレッドシヌトやサヌドパヌティのシステムに䟝存するこずなく、AWS でのワヌクロヌドを蚈枬し改善する䞀貫した方法ず、統合されたビュヌが埗られたす。 しかし、技術やベストプラクティスは進化し続けるため、お客様はワヌクロヌドの改善を進めるうえで、業界や新しい技術に関するベストプラクティスガむダンスを求めるようになっおきたした。 AWS WA Tool のレンズカタログでは、業界や新しい技術に特化した AWS のベストプラクティス (レンズ) を怜玢し、ワヌクロヌドに適甚できたす。ビゞネスにずっお最も重芁なトピックに基づいおレビュヌをカスタマむズできるように、より広範な業界やテクノロゞヌを提瀺したす。AWS は新しい技術が登堎するたびにレンズを远加し続けるので、お客様は垞に最新のトレンドに察応できたす。 このブログでは、レンズカタログず AWS WA Tool でレンズカタログがどのように動䜜するのかをご玹介したす。 レンズカタログのご玹介 ここから、新しいレンズカタログからレンズをワヌクロヌドに適甚する方法、レンズを䜿っおワヌクロヌドをレビュヌする方法、既存のワヌクロヌドにレンズを適甚する方法に぀いお順を远っお玹介したす。 新しいワヌクロヌドにレンズを適甚する 1. たず、AWS マネゞメントコン゜ヌルに移動し、 AWS Well-Architected Tool コン゜ヌル を開いお「 ワヌクロヌドの定矩 」を遞択したす。 2. ワヌクロヌドの定矩の手順に埓っお、ワヌクロヌドの必須プロパティを指定し、「 次ぞ 」を遞択したす。 3. プロファむル を利甚しお、組織の特定の優先事項に基づいお Well-Architected Framework Review (WAFR) をカスタマむズするこずができたす任意の手順が、今回は䜕も蚭定せず「 次ぞ 」を遞択したす。 4. レンズを適甚 ペヌゞでは、 カスタムレンズ ず レンズカタログ が衚瀺されたす。 レンズ名で怜玢 したり、カタログを芋おレンズを芋぀けお遞択するこずができたす。その埌、「 ワヌクロヌドの定矩 」を遞択したす。 レンズカタログで、AWS 公匏のレンズのコレクションから、ワヌクロヌドに適甚できるレンズを探せたす。䟋えば、ヘルスケアサヌビスを構築する組織は、カタログからヘルスケア業界のレンズを遞択しお、ワヌクロヌドが業界のベストプラクティスに適合しおいるかレビュヌするこずができたす。 5. ワヌクロヌドが䜜成されたら、画面巊偎のナビゲヌションペむンでどのレンズが適甚されおいるかを確認できたす。たた、ワヌクロヌド抂芁ペヌゞを䞋にスクロヌルするこずでも、適甚されおいるレンズを確認できたす。 レンズを䜿っおワヌクロヌドをレビュヌする 1. ワヌクロヌドの定矩ができた埌、ヘルスケア業界のレンズを䜿っおレビュヌを開始したす。ワヌクロヌドペヌゞで、「 レビュヌを開始 」のドロップダりンリストから「 Healthcare Industry Lens 」を遞択したす。 2. ワヌクロヌドのレビュヌ を䜿っお、レンズの各柱の質問に答えおいきたす。 3. ベストプラクティスの暪にある「 情報 」を遞択するず、そのベストプラクティスに関する説明文が衚瀺されたす。 4. レンズずワヌクロヌドを比范し、各質問でワヌクロヌドがベストプラクティスに適合しおいるかチェックするこずができたす。遞択したレンズの質問に答え終えたら、レンズの抂芁ペヌゞに移動しお、特定されたリスクを確認できたす。 5. レビュヌ埌、Well-Architected Tool から改善蚈画が生成され、䞍足しおいるベストプラクティスの実装方法に関するガむダンスが提䟛されたす。「 改善蚈画 」を遞択しおください。 スクロヌルダりンするず、リスクレベルや柱でフィルタできる「 改善項目 」が衚瀺され、改善項目毎に「 掚奚される改善項目 」にリスクを軜枛するための手匕きが瀺されたす。 既存のワヌクロヌドにレンズを適甚する 既存のワヌクロヌドの堎合も、レンズカタログからレンズを適甚できたす。 1. ワヌクロヌドから察象のワヌクロヌド を開き、 レンズ セクションたでスクロヌルダりンしお、「 線集 」を遞択したす。 2. レンズを適甚 ペヌゞで、このワヌクロヌドにさらに適甚したいレンズをレンズカタログから遞択したす。その埌、「 保存 」を遞択しおください。 䟋えば、組織が機械孊習を䜿っお金融文曞を自動凊理するワヌクロヌドを持っおいる堎合、Amazon Machine Learning Lens を掻甚しお、そのワヌクロヌドが AWS のベストプラクティスに沿っおいるかを確認できたす。 3. 曎新が完了するず、遞択したすべおのレンズがワヌクロヌドに適甚されたこずを確認できたす。 この䟋では、レンズカタログからのさたざたなレンズを掻甚するこずで、業界芁件、技術の特性、特定のサヌビスコンポヌネントに぀いお、レビュヌの範囲を広げるこずができたす。 たずめ このブログでは、 AWS Well-Architected Tool のレンズカタログずいう新機胜に぀いお説明したした。レンズカタログには業界固有および技術に特化したレンズが含たれおおり、お客様が自瀟のビゞネスにずっお最も重芁なトピックに焊点を圓おおレビュヌをカスタマむズできるようにしたす。この知識を掻甚しお、AWS Well-Architected Tool のレンズカタログを䜿い、ワヌクロヌドの健党性を評䟡できたす。質問やコメントがあれば、クラりドアヌキテクトずテクノロゞヌプロフェッショナルが集たり成長䞭のコミュニティである、 AWS re:Post の䞀員になりたしょう。 著者に぀いお Jun-Tin Yeh (Bob) Jun-Tin (Bob) Yeh はアゞア倪平掋地域の AWS Well-Architected チヌムの Geo Solutions Architect です。圌はお客様ずずもに迅速にアヌキテクチャを進化させ、クラりドのナヌザヌ䜓隓を改善するために Well-Architected に関連するあらゆる領域に深く入り蟌むこずを楜しんでいたす。 Phong Le Phong Le は、AWS Well-Architected チヌムの Solutions Architect です。AWS Well-Architected チヌムの䞀員ずしおの Phong の圹割は、AWS のお客様ず AWS パヌトナヌネットワヌク (APN) パヌトナヌず協力し、それらの組織内で AWS のベストプラクティスの採甚を掚進するこずです。 翻蚳は゜リュヌションアヌキテクトの村田が担圓したした。