AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3668ä»¶

はじめに 本ブログは、党日本空茞株匏䌚瀟ず Amazon Web Services Japan が共同で執筆したした。 みなさん、こんにちは。 AWS ゜リュヌションアヌキテクトの䞉宅です。 党日本空茞株匏䌚瀟様では、2021 幎よりグルヌプ党瀟を暪断したデヌタマネゞメント基盀ずしお「BlueLake」を敎備し、瀟内のデヌタ掻甚の掚進に取り組たれおいたす。2024 幎 6 月 20日  21 日に開催された AWS Summit Japan では、党日本空茞株匏䌚瀟 ãƒ‡ã‚žã‚¿ãƒ«å€‰é©å®€ むノベヌション掚進郚 ãƒ‡ãƒŒã‚¿ãƒžãƒã‚žãƒ¡ãƒ³ãƒˆãƒãƒŒãƒ  の䞞山 様にご登壇いただき、デヌタ掻甚の取り組みで埗たナレッゞを 14 の秘䌝ずしお玹介いただきたした。 本蚘事は、ANA 様のご登壇内容をブログ蚘事ずしお再構成したものずなりたす。 私が所属する ANA デゞタル倉革宀 むノベヌション掚進郚 デヌタマネゞメントチヌムでは䞻に、ANA を䞭心ずしたグルヌプのデヌタ戊略の策定ず、それに沿ったデヌタ基盀の環境敎備ず開発管理を行っおいたす。デヌタ掻甚の掚進を担う同郚のデヌタデザむンチヌムや、BlueLake のシステム開発や運甚を担うグルヌプ䌚瀟の ANA システムズ株匏䌚瀟ずも協力しお、ANA のデヌタ掻甚を進めおいたす。 ANA グルヌプのかかげる「デヌタの民䞻化」ずは ANA グルヌプのデヌタの民䞻化は、グルヌプ  䞇人の埓業員䞀人䞀人がデヌタを自由に扱い、䟡倀を生み出すこずができる状態を目指しおいたす。これたでの ANA におけるデヌタ掻甚は、各システム郚門が䞭心ずなっお、デヌタの収集から加工・集蚈・分析し、結果を共有するたでを行っおきたした。デヌタの民䞻化を実珟するために、デヌタの収集はシステム郚門が行い、それ以降はレベルや目的に応じおシステム郚門ずビゞネス郚門が共に手を取り合い、協創しながら実行しおいくこずにしたした。デヌタ掻甚の䞭心はビゞネス郚門で掚進し、システム郚門はそうした取り組みを環境ずスキルの䞡面でサポヌトしたす。 ANA のデヌタの民䞻化の取り組みは倧きく「仕組み」「人財」「ガバナンス」に倧別するこずができたす。 たずは「仕組み」ずしお、BlueLake 基盀のアヌキテクチャ、デヌタ掻甚ツヌルである BlueLake Apps に関する秘䌝に぀いお 8 ぀玹介したす。 秘䌝 1 デヌタを物理的に 1 箇所に集める戊略 ANA グルヌプは䞻力ブランドの ANA に加えお、Peach や Air Japan を含めた航空事業を展開しおいたす。たた、マむルで買い物ができる EC サむトの ANA Mall やモバむル決枈サヌビスの ANA Pay ずいった 「ノン゚ア」 ず呌ばれる非航空事業にも泚力しおおり、マむルで生掻できる䞖界の実珟に向けお、様々なサヌビスを提䟛しおいたす。 BlueLake が立ち䞊がる前から存圚しおいるデヌタ基盀は、航空事業に特化した業務別のデヌタ基盀であったため、デヌタの民䞻化を掚進しおいくためにも、統合的なデヌタ基盀を再構築する必芁がありたした。様々なデヌタの管理方法があるなか、ANA では物理的にデヌタを 1 箇所に集玄させお、䞀元管理をしおいたす。個別の業務ごずに特化したシステムから生み出されるデヌタは、デヌタの型や持ち方、キヌなどがそれぞれで異なっおいたす。最近は SaaS を利甚するこずも増えおきおおり、デヌタは耇雑性を増しおいたす。 そのなかで、様々な特性のあるデヌタを時間の断面でコントロヌルするこずがデヌタを分析する䞊で重芁であるず考え、耇数の芁玠を、固定した時間で暪断的に収集し、デヌタずしお扱いやすい圢で保持できるよう䞀貫性もったコントロヌルを行っおいたす。 秘䌝 2 プラむバシヌに配慮した 2 局構造 倚くの人が自由にデヌタを扱えるように、BlueLake では、確実なコンプラむアンスのもずでデヌタを管理する必芁がありたした。BlueLake ではプラむバシヌを考慮し、生デヌタを扱う局ず仮名加工枈みデヌタを扱う局の 2 局構造でデヌタを管理しおいたす。具䜓的なアヌキテクチャずしおは、Amazon S3 を掻甚した デヌタレむクず、Amazon Redshift ず Snowflake を掻甚したデヌタりェアハりスから構成されおおり、この 2 ぀の構造をそれぞれ別の AWS アカりントで完党に分離するこずでデヌタの管理を行っおいたす。4 䞇人が自由に䜿えるデヌタは䞻に䞋図の䞋の段のデヌタになっおおり、仮名加工凊理が斜されおいお、個人情報保護法や GDPR などにも察応しおいたす。完党に分離した 2 局構造によっおデヌタをしっかりず守り぀぀、柔軟に掻甚できる環境を実珟しおいたす。 秘䌝 3 Amazon S3 を䞭心ずしたアヌキテクチャ デヌタレむクずしお Amazon S3 を採甚しおいたす。デヌタ掻甚に関するトレンドの移り倉わりは非垞に早いですが、䜵せお毎回抜本的にアヌキテクチャを刷新するのは非垞にコストがかかりたす。そこで私たちは Amazon S3 を䞭心ずするこずで、時代や戊略に合わせおサヌビスの䜿い分けをしおいたす。Amazon S3 はコネクタヌも非垞に豊富で、DeltaLake や Iceberg ずいったフォヌマットにも察応しおいたす。私たちは AmazonS3 を䞭心ずしお、様々なサヌビスを組み合わせながら、目的やスキルレベルに応じたツヌルを甚意しおいたす。 秘䌝 4 目的やレベル別に倚皮なツヌルを敎備 ANA グルヌプの 4 䞇人の埓業員は日々の業務も、デヌタ掻甚スキルも様々です。こうした人たちが䜕か 1 ぀のツヌルを䜿っおデヌタを掻甚するのは非垞に難しいだろうず考え、ANA では珟圚 6 ぀の デヌタ掻甚ツヌルである BlueLake Apps を敎備しおいたす。機埮な情報を取り扱う「BlueLake Custo」、デヌタ抜出を行う「BlueLake Exto」、瀟内基準のレポヌトを党瀟に展開する「BlueLake Repo」、セルフ BI ツヌルの「BlueLake Pivo」、デヌタ実隓環境の「BlueLake Labo」、そしおなんでもできる「BlueLake Pro」 の 6 ぀です。リッチなラむンナップにも芋えたすが、ラむセンス課金のツヌルは利甚者を芋定めお、埓量課金のツヌルは䜿いすぎないようにガバナンスを効かせるこずで、コストを抑えながら運甚しおいたす。目的やスキルレベルに応じお䜿い分けのできるツヌルを甚意するこずで、デヌタ掻甚の可胜性が広がるず考えおいたす。 秘䌝 5 4 䞇人が同じ基準で芋られるダッシュボヌド デヌタを掻甚する䞊で、同じ目線でデヌタを捉えおいくこずは非垞に重芁だず考えおいたす。しかし、郚門や郚眲が倚いず、独自の集蚈や分析が行われるため、基準を合わせお物事を進めるのが難しい堎面もありたす。 そこで、BlueLake Repo は 4 䞇人が同じ基準で芋られるダッシュボヌドを目指しお、Amazon QuickSight を甚いお展開しおいたす。展開にあたっお工倫したポむントが 2 ぀ありたす。1 ぀は、アカりント䜜成の郚分で、瀟内が䜿っおいるグルヌプりェアの IdP ず Amazon Cognito ず AWS Lambda を組み合わせお、自動でアカりントが䜜成される仕組みを構築したした。 2 ぀目は、Amazon QuickSight の埋め蟌み機胜を䜿い、“BlueLake Repo” の名称で瀟内向けのサヌビスずしお展開したこずです。BlueLake Repo では、ナヌザヌが高床の分析を行うこずはありたせん。そのため、デヌタ掻甚の第䞀歩ずしお、利甚するハヌドルをできる限り䞋げお、誰でも気軜に BlueLake に飛び蟌んでこれるように工倫しおいたす。 秘䌝 6 抜出ツヌルは必芁珟圚の答え デヌタ掻甚ツヌルを敎理しおいく䞭で、デヌタ抜出が分析の目的になるこずはないため、業務敎理を行っおデヌタ抜出をなくすべきだ、ずいうアドバむスを䜕床か䌺ったこずがありたした。私自身、もしアドバむスをする立堎なら同じこずを蚀うかもしれたせんが、実際、デヌタ抜出を無くすのはそう簡単ではありたせん。これたでの瀟内のデヌタ掻甚の状況を螏たえお、デヌタ抜出をなくすのはただ早いず刀断したした。しかしながら、意倖にも抜出に特化したツヌルずいうのは䞖の䞭にあたりありたせんでした。 そこで、AWS のサヌビスを駆䜿しお、ドラッグドロップで䜿える SQL ツヌルである BlueLake Exto 開発したした。ただこのツヌルはリリヌスしお間もないため機胜も最沢には備わっおいないのですが、 GUI で䜜成した SQL をレシピずしお保存できる機胜や、瀟員同士でレシピを共有できる機胜などを開発する予定です。䌚瀟ごずに文化や眮かれた環境が異なるため、必ずしもデヌタマネゞメント䞀般論に埓う必芁はないず考えおいたす。 秘䌝 7 ナヌザヌフレンドリヌな”ナレッゞの宝庫” 基盀である BlueLake ず デヌタ掻甚ツヌルの BlueLake Apps 、これらを敎備しただけでは、デヌタの民䞻化はなかなか進みたせん。BlueLake ず BlueLake Apps の橋枡しをするのがデヌタカタログです。 ANA のデヌタを掻甚する 4 䞇人の埓業員が利甚するこずを考えるず、デヌタカタログには、ずにかくデヌタも UI も分かりやすいこず、デヌタに関する質問やナレッゞを共有できるこず、そしお 4 䞇人が䜿えるコストであるこずが求められたした。圓時、䞖の䞭にはいわゆるデヌタをよく知る人たちが利甚するデヌタカタログはありたしたが、どれも高機胜で、私たちの利甚目的に合っおいたせんでした。 そのため、デヌタカタログも AWS のサヌビスを掻甚しお内補で開発するこずにしたした。それがANA のデヌタカタログ「Moana」です。無駄な情報は省き、分かりやすい UI にし、南囜リゟヌトを圷圿させる可愛らしい名前にしおいたす。カタログ機胜に加えお、瀟内甚語をたずめたディクショナリヌ機胜や瀟員同士の SNS 機胜を搭茉し、ANA のデヌタの民䞻化を掚進する䞊で欠かせないツヌルに成長しおいたす。䞖の䞭にないものを自分たちで䜜るこずができるのが、AWS の良いずころだず思いたす。 秘䌝 8 AWS は自瀟の䞖界芳を衚珟できる デヌタの民䞻化を瀟内に広めおいくこずは、マヌケティング掻動そのものであるず考えおいたす。ずにかく倚くの人に BlueLake を知っおもらう、そしお、BlueLake ず聞けば、デヌタを䟿利に䜿えるプラットフォヌムであるずむメヌゞしおもらえるようになるこずが、非垞に重芁であるず考えおいたす。 瀟内では垞に Apps 名でコミュニケヌションを行っおいるため、Apps を補品名で呌ぶ人たちはほずんどいたせん。レベルに合わせた自分たちの䞖界芳を衚珟する䞊でも、AWS のカスタマむズ性の高さは非垞に有効であるず考えおいたす。 ここからは、デヌタを掻甚する人「人財」に関する秘䌝を 2 ぀玹介したす。 秘䌝 9 倚様なチャネルを駆䜿したコミュニティ ANA ではデヌタコミュニティを BlueLake DataCircle ず名付けお、様々な取り組みを行っおいたす。 コミュニティの特城ずしお、倚様なチャネルを䜿っおコミュニティ掻動を圢成しおいるこずが挙げられたす。具䜓的には、BlueLake の玹介むベントや、初玚者向けにデヌタの重芁性や危険性を䌝えるむベントを開催したり、もう少し具䜓的に興味を持っおもらうために、瀟内倖のデヌタ掻甚を行っおいる人ずの察談むベントも開催しおいたす。 少し倉わった取り組みずしお、デヌタドリブン通信ずいうものがありたす。デヌタに特化した瀟内報を我々で䜜成し、デヌタ掻甚で知っおおいおほしい情報や、瀟内のデヌタ掻甚事䟋を読みやすくたずめお、グルヌプ党䜓のポヌタルサむトで発信しおいたす。 秘䌝 10 100 時間を超える内補のデヌタ教育プログラム 党瀟に向けた啓発ず文化の醞成を目的にしたコミュニティ掻動以倖にも、実際にデヌタを扱える人を逊成するための掻動を内補で行っおいたす。参加垌望者はこちらから遞ぶのではなく募集し、それぞれが業務での課題やデヌタ掻甚の可胜性を感じながら教育に取り組みたす。そしお、その講垫は私ず同様グランドスタッフ経隓者や元敎備士で珟圚デヌタサむ゚ンティストずしお瀟内で掻躍しおいるメンバヌが行いたす。100 時間を超える研修を通じお、デヌタ掻甚っおこういうこずかずいう勘所ず基瀎的なスキルを身に぀け、業務を理解したデヌタの専門家ずなり、各郚門で掻躍しおいたす。 最埌に、「ガバナンス」に関する秘䌝を 4 ぀玹介したす。 秘䌝 11 ANA が着目した八぀の項目 たず最初にガバナンスに着手した際、DMBOK の茪読から始めたした。内容をメンバヌで分担しながら理解するずころたでは良かったのですが、いざ ANA のガバナンスをたずめるずきに困ったのが項目の遞定でした。最初からあれもこれもで、絵に描いた逅になっおしたっおは、ガバナンスをたずめる意味がありたせん。悩んだ挙句、私たちは 8 ぀の項目を採甚したした。今回は、工倫したガバナンスの䞀郚を玹介したす。 秘䌝 12 ANA のデヌタスチュワヌドは  皮類 䟋えば、䞊蚘の項目 2 の「䜓制ず圹割」の䞭では、デヌタスチュワヌドを定矩しおいたす。デヌタスチュワヌドにも様々なものがありたすが、ANA ではたず、BlueLake デヌタスチュワヌドず、業務デヌタスチュワヌドの 2 ぀を定矩するずころから始めおいたす。BlueLake デヌタスチュワヌドはデヌタガバナンス・デヌタマネゞメントの芖点で、開発・運甚を統制しおいたす。業務デヌタスチュワヌドは瀟内のデヌタ利甚者からの開発・掻甚案件を集玄し、優先床決め等を行いたす。双方がデヌタスチュワヌドシップ䌚議にお定期的にコミュニケヌションをずるこずで、ANAのデヌタのありたい姿を実珟させおいたす。 秘䌝 13 安党に䟡倀を創出するためのルヌル グルヌプ 4 䞇人がデヌタを掻甚しおいく䞊で欠かせないのが、グルヌプ䌚瀟暪断でのルヌルです。「利甚料及び契玄」の項目では、グルヌプ䌚瀟ずのデヌタやツヌルの利甚に関する芏定や、個人情報に関する囜内倖の法什ぞの察応方針を定めおいたす。たた、セキュリティやプラむバシヌに関する教育や啓発にも取り組んでいたす。契玄や利甚料の調敎は非垞に倧倉です。しかし、グルヌプ党䜓でデヌタによっお安党に䟡倀を生み出す䞊では必芁䞍可欠だず考えおいたす。 秘䌝 14 BlueLake DataManagement 最埌の秘䌝ずしお、ここたでお話しした党おの秘䌝は、デヌタ戊略、デヌタマネゞメントポリシヌ、デヌタ利掻甚ガむドラむンの 郚構成で、BlueLake Data Management ずしお、䜓系的に文曞化しおたずめおいたす。ANA ではこの BlueLake デヌタマネゞメントに沿っお、デヌタの基盀をデザむンし、デヌタから䟡倀を生み出す土壌を敎備しおいたす。 最埌に これら 14 の秘䌝は、デヌタの民䞻化のための手段に過ぎたせん。そしおデヌタの民䞻化自䜓もたた、目的ではありたせん。 デゞタルずデヌタを掻甚したビゞネスの倉革を通しお、ANA をご利甚になるお客様の䜓隓䟡倀を向䞊させ、 䞇人の埓業員の働き方に倉化をもたらし、そしお、䌁業の持続性ず ESG を䞡立した䟡倀創造を掚進しおいきたいず考えおいたす。お客様、埓業員、環境、この 3 ぀にプラスの䟡倀をもたらすために、今埌もデヌタの掻甚に取り組んでいきたす。
シニア GTM アナリティクススペシャリスト゜リュヌションアヌキテクトの倧薗です。 2024 幎 11 月 7 日に「 デヌタガバナンス事䟋祭り〜AWSで実珟するモダンな取り組み〜 」を開催したした。今回の事䟋祭りでは AWS の Analytics サヌビスを掻甚しおデヌタガバナンスの取り組みを実珟しおいる富士通株匏䌚瀟様、株匏䌚瀟日本経枈新聞瀟様、 LINEダフヌ株匏䌚瀟様、党日本空茞株匏䌚瀟様にご登壇いただき、AWS からもデヌタガバナンスを実珟する AWS サヌビスを玹介したした。本ブログでは圓日の各発衚内容に぀いお玹介したす。 デヌタガバナンスを実珟する AWS サヌビスのご玹介 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 神郚 掋介 資料ダりンロヌド デヌタガバナンスの重芁性ず AWS デヌタガバナンスフレヌムワヌクのご玹介 AWS の神郚からは、オヌプニングセッションずしお、デヌタガバナンスを実珟するための様々な AWS サヌビスに぀いおご玹介したした。 昚今の様々な調査結果も瀺すように、デヌタガバナンスは䌁業にずっお重芁な取り組みずなっおいたす。デヌタガバナンスの目的にはデヌタを保護する守りの偎面ず、デヌタを掻甚しおむノベヌションを掚進する攻めの偎面の 2 ぀がありたすが、デヌタの増加、デヌタ゜ヌスの増加、デヌタ掻甚者の増加ずいった課題から掚進を難しくさせおいる点に觊れ、AWS で提唱しおいるデヌタガバナンスフレヌムワヌクに぀いおご玹介したした。デヌタを取埗しおから掻甚するたでのフロヌにおいお、重芁な 3 ぀の領域ずしお Curate、Understand、Protect の 3぀があり、AWS ではこのフレヌムワヌクに基づいお様々なサヌビスを提䟛しデヌタガバナンスを支揎しおいる点を説明し、各領域における代衚的なサヌビスを玹介しおいきたした。 フレヌムワヌクの 3 領域における AWS の代衚的なサヌビス たず Curate の領域では、 AWS Glue (Glue) の機密デヌタ怜知やデヌタ品質管理の機胜が玹介されたした。Glue を䜿うこずで信頌性の高いデヌタを䜜り出し、品質を維持できるためのデヌタガバナンスの第䞀歩ずなりたす。次に Understand の領域では、 Amazon DataZone (DataZone) のデヌタポヌタル、メタデヌタ、デヌタリネヌゞの機胜が玹介されたした。DataZone を利甚するこずで、どのようなデヌタがあるかを簡単に怜玢でき、メタデヌタから詳现を理解できるほか、生成 AI によりメタデヌタを自動生成するこずも可胜です。たたデヌタリネヌゞ機胜によりデヌタのルヌトや倉曎履歎を远跡できたす。最埌の Protect の領域では、 Amazon Redshift (Redshift) のダむナミックデヌタマスキングず Apache Iceberg が取り䞊げられたした。Redshift のダむナミックデヌタマスキングを掻甚するこずにより、ナヌザヌごずにデヌタの衚瀺内容を動的に制埡でき、デヌタのセキュア化ずデヌタ掻甚の䞡立を図れたす。Apache Iceberg はタむムトラベル機胜やスキヌマ進化機胜を持ち、デヌタ倉曎の远跡や監査芁件ぞの察応が容易になりたす。 このように AWS のサヌビスや最新のテクノロゞヌを掻甚するこずで、デヌタガバナンスの実珟が加速できるこずを匷調し、セッションを締めくくりたした。 富士通のデヌタ利掻甚プラットフォヌム OneData におけるデヌタガバナンスの取り組み 富士通株匏䌚瀟 デゞタルシステムプラットフォヌム本郚 Enabling Technologies 統括郚 マネヌゞャヌ ä¹…äž‹ 泰明 氏 資料ダりンロヌド デヌタセキュリティの確保ずデヌタ利掻甚の促進の䞡立 富士通株匏䌚瀟 (以䞋、富士通) では党瀟を挙げたデゞタルトランスフォヌメヌションの䞭栞に、デヌタドリブン経営の実珟を掲げおいたす。それに向けた経営プロゞェクト「OneFujitsu」の䞀環ずしお、党瀟デヌタ利掻甚プラットフォヌム「OneData」の敎備が始たりたした。「OneData」ではデヌタの提䟛者、利甚者、デヌタ利掻甚掚進者の 3 ぀の圹割を定矩し、適切なデヌタガバナンスの䞋でデヌタ利掻甚を促進するサヌビスが提䟛されおいたす。しかし、デヌタ利掻甚を進める䞊では、デヌタセキュリティの確保ずデヌタ利掻甚の促進ずいう 2 ぀の偎面を䞡立させるこずが、デヌタガバナンスの倧きな課題ずなりたす。守りず攻めの䞡立は容易ではありたせん。そこで富士通では具䜓的に 2 ぀の取り組みを実斜し、このデヌタガバナンスの課題解決を目指したした。 ビゞネスデヌタカタログの導入 1 ぀目は AWS のデヌタガバナンスサヌビス DataZone を掻甚したビゞネスデヌタカタログです。DataZone の導入により、デヌタ怜玢、理解、利甚蚱可の䞀連の流れをデヌタガバナンスの䞋で䞀元的に実珟できるよう構築を進めおいたす。業務コンテキストに基づきデヌタを発芋し䟡倀を理解した䞊で、メタデヌタを参照しながらデヌタの利甚蚱可を 1぀の Web ポヌタルから申請できるようにしたす。これたで倖郚ワヌクフロヌを経る必芁があった利甚蚱可プロセスも DataZone 䞊で完結し、デヌタガバナンスに基づくデヌタ利掻甚のアゞリティの倧幅な向䞊を目指しおいたす。 デヌタ品質管理の導入 2 ぀目はデヌタ品質管理の取り組みです。DataZone ず Glue Data Quality を組み合わせ、提䟛偎ず利甚偎の双方でデヌタガバナンスに基づくデヌタ品質の可芖化を進めおいたす。提䟛偎ではデヌタの業務ルヌル適合性をチェックし、問題があれば䞊流システムの改善に圹立おたす。利甚偎では分析芁件に基づきデヌタ品質を確認の䞊、デヌタアセットをサブスクラむブすべきかを刀断するこずで、デヌタガバナンスに基づく粟床の高いデヌタ掻甚の実珟を目指しおいたす。 このようにデヌタガバナンスの芳点から、富士通では AWS サヌビスを掻甚しながらデヌタ利掻甚の促進ずセキュリティ確保の䞡立を実践しおいたす。今埌も AWS の機胜拡充に期埅を寄せ぀぀、「OneData」におけるデヌタガバナンスの取り組みを進化させおいく考えだず述べられおいたした。 Apache Icebergで実珟する次䞖代デヌタガバナンス日経リスクコンプラむアンスの挑戊 株匏䌚瀟日本経枈新聞瀟 情報サヌビスナニット ゜フトりェア゚ンゞニア 倧塚 恭平 氏 資料ダりンロヌド デヌタドリブンサヌビス開発に取り組む日本経枈新聞瀟が盎面した課題 株匏䌚瀟日本経枈新聞瀟 (以䞋、日本経枈新聞瀟) が提䟛する法人向けサヌビス「日経リスク&コンプラむアンス」においお、Apache Iceberg を掻甚した次䞖代のデヌタガバナンス基盀に぀いお玹介されたした。日本経枈新聞瀟は、取匕先のリスク評䟡を行うための法人向けサヌビス開発においお、金融庁のガむドラむンに準拠するための新機胜を远加する必芁に迫られおいたした。具䜓的には、サヌビスを利甚しお取匕先のリスク評䟡を行った際の操䜜蚘録を保管し、必芁に応じお提瀺できるようにする必芁がありたした。幎間数億レコヌドの操䜜蚘録を扱う芋蟌みだったため、堅牢でスケヌラブルか぀䜎コストなストレヌゞ基盀が求められたした。様々なアヌキテクチャを怜蚎した結果、デヌタレむクを支えるオヌプン゜ヌス技術である Apache Iceberg を掻甚する方針を決めたした。 Apache Iceberg の特長を生かしたアヌキテクチャ 日本経枈新聞瀟が Apache Iceberg を遞んだ理由は、 Amazon Athena (Athena) を含む倚くのコンピュヌト゚ンゞンが Apache Iceberg をサポヌトしおいるこず、 Amazon S3 (S3) に操䜜レコヌドを䜎コストで保存できるこず、トランザクション性や スキヌマ進化、デヌタの論理削陀などの高床な機胜に察応できるこずにありたした。実際に構築したアヌキテクチャでは、アプリケヌションから Amazon Kinesis Data Streams に操䜜レコヌドをストリヌミングで曞き蟌み、Glue で Apache Iceberg 圢匏に倉換しお S3 ぞ保存しおいたす。ナヌザヌがアプリで操䜜履歎を参照する際は、Athena を䜿っお S3 䞊のデヌタをク゚リしたす。 Apache Iceberg を甚いるこずで、䜎コストでありながら高い可甚性ずデヌタ敎合性を実珟。たた日付やテナント ID で パヌティショニングを行うこずで、ク゚リの高速化ずコスト最適化も図れたずのこずです。さらに定期的に AWS Step Functions (Step Functions) を䜿ったメンテナンスゞョブを実行し、スモヌルファむル化の解消やレコヌド削陀などのテヌブル最適化を行なっおいたす。 日本経枈新聞瀟では、本プロゞェクトを通じお倧量デヌタを安党に䜎コストで保持し、高速なク゚リずセキュアな消去を実珟 するシステムの構築ノりハりを埗るこずができたした。今埌は Apache Iceberg ゚コシステムの進化に远付するこずで、よりシンプルか぀䜎コストなアヌキテクチャを実珟し、他サヌビスぞのアヌキテクチャ暪展開を怜蚎しおいるずのこずでした。 LINEダフヌ瀟での DWH ずしおの AWS 導入背景ず安党管理のための取り組み LINEダフヌ株匏䌚瀟 デヌタ゚ンゞニアリング郚 デヌタマネゞメントチヌム リヌダヌ å°Ÿå°» 恒 氏 資料ダりンロヌド 金融デヌタを取り扱う堅牢なオンプレミスデヌタレむクを Amazon Redshift Serverless に移行 LINEダフヌ株匏䌚瀟 (以䞋、LINEダフヌ) では、金融デヌタを取り扱う既存の Hadoop ベヌスのオンプレミスデヌタレむクシステムが EOL を迎えたこずから、新たなデヌタりェアハりス (DWH) の導入を進めたした。既存システムではメンテナンスコスト増加や゚ンゞニア採甚の難しさ、デヌタ利掻甚の課題があったため、 FISC 芁件を満たしセキュリティを匷化し぀぀、効率的な運甚ずデヌタ掻甚の促進を実珟できるクラりドベヌスの DWH が求められおいたした。 LINEダフヌではセキュリティ、管理・運甚、スケヌラビリティ、デヌタ掻甚の 4 ぀の芳点を重芁な芁件ずしお捉え、これらの芁件を満たすプラットフォヌムずしお Amazon Redshift Serverless (Redshift Serverless) を䞭心ずした AWS のサヌビス矀を遞定したした。セキュリティ面では AWS IAM Identity Center ず既存 Identity Provider (IdP) の連携によりナヌザヌ認蚌ず暩限の䞀元管理を実珟し、運甚面ではオンプレミスず連携した既存 Notebook の流甚ず AWS マネヌゞドサヌビスの掻甚により容易な運甚が実珟できる芋蟌みが立ちたした。スケヌラビリティでは Redshift Serverless や Glue などのサヌバヌレスサヌビスを掻甚するこずにより、デヌタ量に応じた柔軟なスケヌリングが可胜ずなり、デヌタ掻甚面では非開発職でも利甚可胜な BI /分析ツヌルず連携しおデヌタ掻甚を促進できるず刀断されたした。 デヌタ収集ず掻甚のアヌキテクチャ 実際に構築したアヌキテクチャでは、オンプレミスのデヌタを AWS Direct Connect で転送し、Glue や Step Functions などのサヌビスで機密デヌタのハッシュ化など、適切な ETL 凊理を行った䞊で Redshift Serverless に取り蟌んでいたす。ナヌザヌ認蚌には IdP を掻甚した Single Sign On (SSO) で AWS マネヌゞメントコン゜ヌルでログむンし、Redshift Serverless が提䟛する機胜であるロヌルベヌスのアクセスコントロヌルを行なっおいたす。そのうえで利甚者は、汎甚的な分析のために Redshift Query Editor v2.0 、可芖化に Amazon QuickSight (QuickSight)、高床な分析の甚途ずしお Amazon SageMaker (SageMaker) などのサヌビスを䜿っおデヌタ掻甚を行なっおいるずのこずです。 オンプレミスデヌタレむクを運甚しおいた尟尻氏は、この DWH 導入プロゞェクトを通じお、少人数チヌムでもクラりドであれば迅速なシステム構築が可胜であるこずを実感されたした。䞀方で、予期せぬ制限にも盎面し、運甚での工倫が必芁になるケヌスもあったずいいたす。しかし、AWS の豊富なサヌビスを組み合わせるこずで、こうした課題を乗り越えるこずができたず述べおいたす。今埌は、この導入した基盀を生かしおデヌタカタログ゜リュヌションの導入やデヌタマスキングの実斜など、曎にデヌタガバナンスの取り組みを匷化しおいき、組織党䜓のデヌタ掻甚の成熟床を高めおいくずのこずでした。 ANAグルヌプで実践するデヌタマネゞメントず私たちが倧切にしおいるこず 党日本空茞株匏䌚瀟 デゞタル倉革宀 むノベヌション掚進郚 デヌタマネゞメントチヌム äžžå±± 雄倧 氏 グルヌプ内倖のデヌタを䞀元集玄する BlueLake 党日本空茞株匏䌚瀟 (以䞋、ANA) は、グルヌプ暪断でデヌタの掻甚を掚進するため、デヌタ基盀「BlueLake」の敎備を進めおきたした。事業の拡倧に䌎いデヌタ量やそのバリ゚ヌションが増加するなど課題が増えおきたため、2021 幎にデヌタマネゞメント構想を掲げ、人材育成支揎、プロセスの敎備、システムの進化の 3 本柱で取り組みを開始したした。その䞭栞ずなるのが BlueLake です。BlueLake では ANA グルヌプ内倖のデヌタを䞀元集玄し、スキルレベルに応じたツヌルで掻甚できる環境を敎備しおいたす。ガバナンスを重芖し、デヌタの蓄積から䟡倀創出たでの䞀貫したプロセスを蚭蚈しおいたす。 BlueLake においお倧切にしおいる 3 ぀のこず BlueLakeには 3 ぀の特城がありたす。1 ぀目は「安心で安党なデヌタ基盀」であるこずです。S3 をデヌタレむクずしお掻甚し、生デヌタを分析可胜な Redshift、匿名加工デヌタのみを扱う Snowflake などを組み合わせた 2 局構造ずなっおいたす。個人情報や機密デヌタは Redshift 偎で適切に加工し、Snowflake 偎には公開デヌタのみを眮くこずで、セキュリティを確保し぀぀瀟員の自由な掻甚を可胜にしおいるずのこずです。2 ぀目の特城は、「ワクワクするデヌタ分析ツヌル」の提䟛です。ANA グルヌプには 4 䞇人の埓業員がおり、デヌタリテラシヌは様々です。そこで QuickSight、 Amazon WorkSpaces 、Tableau など、目的やスキルに合わせお䜿い分けられる倚様なツヌルを甚意しおいたす。ツヌル名も補品名ではなく”BlueLake XXX”ずいうキャッチヌな呌称を甚いるなど、デヌタ掻甚ぞの芪しみやすさを意識しおいるずのこずです。3 ぀目は、「二぀の Single Source of Truth (SSoT)」の実珟です。SSoT には 2 ぀の偎面があり、1 ぀目は「デヌタの民䞻化のための SSoT」で、BlueLake 内でデヌタの暙準化を行い、異なる゜ヌスのデヌタを結合できるよう環境を敎えおいたす。レむダヌ化やデヌタモデリングにも取り組んでいたす。2 ぀目は「デヌタ基盀ずしおの SSoT」で、S3 にデヌタをファむルずしお集玄し、基盀アヌキテクチャを単玔化するこずで、時代の倉化 (技術の進化のスピヌド) に柔軟に察応できるよう心がけおいたす。珟圚、新たに Open Table Format 導入を芋据え、Apache Iceberg の怜蚌も進めおいるずのこずでした。 デヌタ戊略、デヌタマネゞメントポリシヌ、デヌタ利掻甚ガむドラむンの文曞化 たた ANA では、デヌタマネゞメントに関しお、デヌタ戊略、デヌタマネゞメントポリシヌ、デヌタ利掻甚ガむドラむンの 3 郚構成で䜓系的な文曞化を行っおいたす。その䞭栞ずなるのがデヌタマネゞメントポリシヌで、その䞭で䞊述したような BlueLake のデヌタ基盀に関する方針やルヌル、䜓制などを定矩しおいたす。しかし䞞山氏は、デヌタマネゞメントの考え方を文曞化するだけでは実行に移すこずは容易ではなく、組織党䜓でデヌタマネゞメントを理解し取り組んでいく必芁があるず匷調したした。そのため ANA では、デヌタ掻甚掚進䜓制を戊略、実行、監督の 3 ぀に分けた䞉暩分立の䜓制を怜蚎䞭です。戊略は BlueLake の党瀟暪断掚進、実行はデヌタ゚ンゞニアなどによる開発、監督ではリスクマネゞメントやガバナンスの芳点での圹割を想定しおいるずのこずです。 デヌタガバナンスでは最終的に人が最も重芁です。優れたポリシヌがあっおもそれを実行する人がいなければ絵に描いた逅ずなっおしたいたす。ANA では埓業員の力を結集し、デヌタ掻甚を通じた事業や瀟䌚ぞの貢献を目指しおいくず宣蚀され、セッションを締めくくりたした。 たずめ 「デヌタガバナンス事䟋祭り」ず題した本セミナヌでは、近幎泚目されおいるデヌタガバナンスずいうテヌマに関連する、倚様な芳点を含む事䟋が盛り沢山ずなりたした。各瀟よりご発衚いただいたセッションにお玹介された AWS サヌビスにご興味ある堎合は無料で個別盞談䌚を開催しおおりたす。皆様からのお申蟌みをお埅ちしおおりたす。 お申蟌みリンク 本ブログは、゜リュヌションアヌキテクトの倧薗が䜜成したした。
はじめに 2024 幎 10 月 10 日、新聞・出版・メディア業界のお客様向けに、「AWS Media Seminar 2024 – 今から始めるPublisher 向け生成 AI」ずいうテヌマでセミナヌをオンラむンにお開催いたしたした。このセミナヌの開催報告ずしお圓日お話しした内容や資料をご玹介いたしたす。文章生成やコンテンツ分析、PDF 解析など、生成 AI は Publisher にずっおも様々な掻甚方法が芋いだされるようになり、業務効率化や新しい䟡倀の創造に倧きく貢献し始めおいたす。本セミナヌでは、このように生成 AI の掻甚が広がっおきた䞭で芋えおきた課題にどう向き合っおいくのか、Amazon や 囜内のお客様の事䟋を亀えながら AWS セッションにおお話させお頂きたした。続いお、生成 AI を先駆的に掻甚しむノベヌションを実珟しおいるお客様にご登壇頂き、具䜓的な怜蚌結果や自瀟プロダクトぞ組み蟌む際の工倫点、 Amazon Bedrock の掻甚堎面ず遞定理由などをお話頂きたした。 Publisher のための生成 AI の事䟋ずはじめかた アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 メディア゜リュヌション郚 ゜リュヌションアヌキテクト 向井 織 【 資料 】 【 動画 】 オヌプニングセッションずしおアマゟン りェブ サヌビス ゞャパン 向井より、生成 AI をはじめる䞊でのビゞネス面ず技術面の課題に察するアプロヌチをお話させお頂きたした。ビゞネス面の課題に぀いおは耇数の Publisher 向けの事䟋ず共に生成 AI をどう始めたらよいのかアむデアを挙げさせお頂き、技術面の課題を解決するために提䟛された Amazon Bedrock に぀いおご玹介したした。 この䞭で生成 AI をはじめる 1 ぀のアむデアずしお、生成 AI を掻甚したビゞネスナヌスケヌスのサンプル集ずなる Generative AI Use Cases JP をご玹介しおおりたす。 ママ向け Q&A サヌビス mamari の怜玢機胜向䞊における生成 AI 掻甚 LLM 時代の新しい怜玢䜓隓に向けた詊み 〜 コネヒト株匏䌚瀟 機械孊習゚ンゞニア 池之䞊 陜平 様 【 資料 】 【 動画 】 コネヒト株匏䌚瀟池之䞊様より、ママ向け Q&A サヌビスにおける生成 AI を掻甚した怜玢機胜の改善の取り組みをご玹介いただきたした。この䞭で埓来の党文怜玢ず近幎泚目を集めおいるベクトル怜玢に぀いお、実際の Q&A デヌタを扱った耇数のク゚リパタヌンにおける怜玢結果の違いに぀いおお話し頂いおおりたす。 生成 AI ず Amazon Titan で始めるコンテンツのタグ付けずコンテンツ掚薊 note株匏䌚瀟 機械孊習゚ンゞニア 挆山 和暹 様 【 資料 】 【 動画 】 note株匏䌚瀟挆山様より、むンタヌネット䞊でコンテンツを発衚できる note における生成 AI を掻甚したコンテンツのレコメンド機胜の改善の取り組みをご玹介いただきたした。この䞭で Amazon Titan Text Embeddings を掻甚したタグ付けの事䟋や、生成 AI を掻甚したタグ付けを改良する工倫に぀いおお話し頂いおおりたす。 コンテンツ制䜜支揎サヌビス ALOFA における生成 AI 掻甚 株匏䌚瀟朝日新聞瀟 メディア事業本郚メディア研究開発センタヌ 嘉田 算侖 様 【 資料 】 【 動画 】 株匏䌚瀟朝日新聞瀟嘉田様より、メディア研究開発センタヌで取り組たれおいる線集業務の䜜業効率化に向けた取り組みをご玹介いただきたした。取材埌の文字起こし䜜業は蚘事制䜜の䞭でも負担が倧きいプロセスです。この䜜業を効率化するプロダクト 「ALOFA」の 特城や構成ず工倫点、Amazon Bedrock の掻甚堎面ず遞定理由に぀いおお話し頂きたした。 おわりに 本ブログでは、2024 幎 10 月 10 日に開催された「AWS Media Seminar 2024 – 今から始めるPublisher 向け生成 AI」の内容をご玹介させおいただきたした。本セミナヌに参加いただいた皆さた、誠にありがずうございたした。匕き続き皆様に圹立぀情報を、セミナヌやブログで発信しおいきたす。どうぞよろしくお願い臎したす。 本ブログは゜リュヌションアヌキテクト向井が担圓したした。
珟代の倉化のペヌスが速く競争の激しい補造業界では、䌁業はサプラむチェヌンの管理においお、出荷の遅延、郚品䞍足、茞送のボトルネックずいった重倧な課題に盎面しおいたす。 補造業の䌁業は、需芁を予枬し、垂堎の倉動に合わせお生産を調敎しながら、材料や郚品のサプラむダ、生産蚭備、補品の流通チャネルからなるネットワヌクの耇雑さに苊劎するこずがよくありたす。 補品の䟛絊を保蚌しながら圚庫コストを最小限に抑えるには、原材料の入手可胜性、生産胜力、物流、消費者の嗜奜を慎重に怜蚎する必芁がありたす。 埓来のサプラむチェヌン手法は、こうした動的な芁因に察しお䞍十分であるこずが倚く、効率の䜎䞋、圚庫切れ、過剰圚庫に぀ながりたす。 補造業の䌁業に圱響を及がすサプラむチェヌンの課題 補造業の䌁業は、生産蚈画や材料管理から可芖性やデヌタ統合に至るたで、サプラむチェヌン業務党䜓でさたざたな課題に盎面しおいたす。 䞻な耇雑さは次のずおりです。 資材需芁ず生産胜力のバランスを取り、スルヌプットを最適化する効果的な資材資源蚈画MRPの策定。 氎の䜿甚量、プラスチック、リサむクルに関するサステナビリティの目暙に合わせながら、補品蚭蚈の曎新や芏制遵守による材料組成の倉化を監芖。 䜜業指瀺やメンテナンス䜜業に必芁なスペアパヌツや資材を可芖化するこずで、ダりンタむムず朜圚的な収益損倱の最小化。 ゚ンドツヌ゚ンドのサプラむチェヌンの透明性を実珟するこずで、デヌタドリブンな意思決定、需芁シグナルの怜出、圚庫予枬の生成、シミュレヌションによるリスク評䟡、混乱ぞの積極的な察凊。 このブログでは、 AWS Supply Chain ず Amazon Q を連携させ、サプラむチェヌンの課題に察する解決策をどのように提䟛するのかを説明したす。 これらの゜リュヌションは、サプラむチェヌンデヌタ、生成 AI、機械孊習MLを掻甚するこずで、実甚的な掞察を提䟛したす。 こうしたテクノロゞヌは、補造業の䌁業に革新的な戊略ずデヌタドリブンな掚奚事項を提䟛し、業務の合理化、リ゜ヌスの最適化、倧きな倉化を芋越した察応に圹立ちたす。 AWS Supply Chain AWS Supply Chain は、サプラむチェヌンネットワヌク党䜓の可芖性、トレヌサビリティ、蚈画を匷化するクラりドベヌスのアプリケヌションです。 その䞭心ずなるのが、分析のために 耇数の゜ヌス からのデヌタを統合するリポゞトリである サプラむチェヌンデヌタレむク SCDLです。 AWS Supply Chain は、デヌタから掞察を埗る機胜、ML を掻甚した需芁予枬、圚庫最適化、高床な分析により、デヌタドリブンな意思決定を促進したす。 サプラむチェヌン業務を最新化するための次のような 包括的な機胜 を提䟛したす。 掞察 : 過剰圚庫や圚庫切れなどのリスクを特定し、カスタムりォッチリストやアラヌトのオプションを䜿甚しお圚庫マップ䞊で可芖化したす。 掚奚アクションずコラボレヌション : ランク付けされたリスク情報ずずもに、圚庫移動の遞択肢を提瀺し、過去の決定から孊習しお掚奚事項を改善したす。たた、問題を迅速に解決するために組み蟌たれたコラボレヌションツヌルも含たれおいたす。 需芁蚈画 : ML を䜿甚しお正確な需芁予枬を生成し、垂堎の状況に基づいお調敎し、リアルタむムで曎新しお䜙剰圚庫ず廃棄物を削枛したす。 䟛絊蚈画 : ML モデルを䜿甚しお必芁な資材賌入を予枬および蚈画し、圚庫管理を改善し、コストを削枛したす。 N階局の可芖性 : 倖郚パヌトナヌにむンサむトを広げ、取匕先ずの泚文や䟛絊蚈画を確認するこずで蚈画の正確性を高めたす。 サステナビリティ : サプラむダヌから環境、瀟䌚、ガバナンスESGデヌタを収集しお管理し、サステナビリティ基準の遵守を確保したす。 耇数の拠点の圚庫を最適化するこずで、補造業の䌁業は統合されたサプラむチェヌンデヌタから埗られる透明性、説明性を実珟し、実甚的なアクションに぀ながる分析胜力を向䞊させるこずができ、運甚の優秀性オペレヌショナル゚クセレンス、収益性、顧客満足床を高めるこずができたす。 Amazon Q Amazon Bedrock を搭茉した生成 AI アシスタントである Amazon Q が、 AWS Supply Chain に統合されたした。 Amazon Q の自然蚀語むンタヌフェヌスにより、SCDL 内のデヌタぞの問い合わせず分析が可胜になり、耇雑な「䜕」や「なぜ」 「もしも」 ずいう質問に察するむンテリゞェントな回答が埗られたす。䟋えば、Amazon Q は「航空貚物で泚文を急ぐ堎合はどうなりたすか」ず質問するず「航空貚物は通垞 2 日で到着するため、収益ぞの圱響は 95,000 USD 枛りたすが、急送費甚には 2,400 USD が远加されたす」ず回答する可胜性がありたす。 ML モデルを掻甚するこずで、Amazon Q はサプラむチェヌンのデヌタを解釈し、貎重な掞察を導き出し、実行可胜な掚奚事項を生成したす。 䌚話型のむンタヌフェむスにより、耇雑な SQL ク゚リやデヌタ操䜜を必芁ずせずに自然に察話できたす。 AWS Supply Chain の Amazon Q は、戊略的掞察を求める経営幹郚でも、詳现な運甚を怜蚎しおいるサプラむチェヌンの分析担圓者でも、それぞれのニヌズに合わせお適応したす。 AI による掞察により、ボトルネック箇所の特定、プロセスの最適化、運甚効率の向䞊に圹立ちたす。 生成 AI による補造゚クセレンスの掚進 AWS Supply Chain with Amazon Q は、生成 AI ず機械孊習を掻甚しお、耇雑なサプラむチェヌンの課題に取り組んでいたす。 AWS の安党で高性胜なむンフラストラクチャにより、メヌカヌは AI の採甚を加速させ、垂堎投入たでの時間を短瞮し、生産性を高め、業務を合理化し、サプラむチェヌンを最適化できたす。 補造業の䌁業はすでに AWS AI/ML サヌビスを䜿甚しお業務を匷化し、デヌタドリブンな意思決定を可胜にしおいたす。 以䞋にいく぀か䟋を挙げたす。 迅速な蚺断ず問題解決による補造珟堎の生産性の向䞊 : ゚レベヌタヌおよび゚スカレヌタヌ業界のグロヌバルリヌダヌである KONE は、原因分析ず解決たでの時間を短瞮するこずで、珟堎での顧客サヌビスの迅速化を実珟しおいたす。 同瀟は Amazon Bedrock を䜿甚しお、瀟内文曞を掻甚する生成 AI アプリケヌションを倧芏暡展開しおいたす。 生成 AI テクノロゞヌを䜿甚しおマニュアル、工堎デヌタの分析結果、履歎デヌタをトレヌニングするこずで、技術者は問題のトラブルシュヌティングを効率的に行い、機噚メンテナンスの詳现なガむドを䜜成できたす。 このアプロヌチは、補造環境における蚺断、問題解決、意思決定、および資産保守プロセスをスピヌドアップするこずにより、補造珟堎の生産性を向䞊させたす。 合成画像デヌタによる補品品質ず欠陥怜出の匷化 : 補薬䌚瀟の Merck は、AWS のサヌビスず生成 AI を䜿甚しお欠陥画像を合成し、正確で堅牢な欠陥怜出モデルをトレヌニングする際のデヌタの制玄を克服しおいたす。 生成 AI により、Merck のようなメヌカヌは合成画像を生成し、「良い」䟋ず「悪い」䟋でデヌタセットを補匷できたす。 このアプロヌチにより、Merck は補品ラむン党䜓で党䜓の䞍良品を 50% 以䞊削枛し、効率の向䞊ず廃棄物の削枛を実珟したした。 顧客がサステナビリティの目暙を達成できるようにする : むンテリゞェントな気候および゚ネルギヌ゜リュヌションの䞖界的リヌダヌである Carrier は、AWS のサヌビスを利甚しお Abound Net Zero Management プラットフォヌムを拡匵・匷化しおいたす。 Carrier は、Amazon Bedrock ず Amazon Textract を掻甚するこずで、お客様が゚ネルギヌ消費を管理し、二酞化炭玠排出量を削枛できるよう支揎しおいたす。 この゜リュヌションにより、顧客は公共料金の請求曞を珟地の蚀語でアップロヌドでき、Carrier は生成 AI を䜿甚しおこのデヌタをサステナビリティに関する実甚的な掞察に倉換したす。 このむニシアチブは、より安党で持続可胜な䞖界を創造するずいう Carrier の䜿呜ず䞀臎しおいたす。 これらの顧客事䟋は、生成 AI ゜リュヌションが、いかに補造業の䌁業がむノベヌションを掚進し、業務効率を高め、競争が激化する環境においお時代を先取りする力を䞎えおいるかを瀺しおいたす。 たずめ 珟代における競争の激しい補造環境では、効果的なサプラむチェヌン管理が運甚の優秀性ず持続的な成長の鍵ずなりたす。 埓来の方法では、珟代のサプラむチェヌンの耇雑さに察凊するには䞍十分であるこずが倚く、非効率に぀ながりたす。 補造業の䌁業は、これらの課題を克服するために AWS Supply Chain や Amazon Q などの゜リュヌションに目を向けおいたす。 AWS Supply Chain の䞀元化された SCDL ず高床な分析機胜を掻甚するこずで、䌁業はデヌタ䞻導の意思決定、可芖性の向䞊、蚈画の最適化を実珟できたす。 Amazon Q では、補造業の䌁業は自然蚀語による問い合わせを通じおむンテリゞェントな掞察ず実甚的な掚奚事項を埗るこずができたす。 生成 AI が珟実䞖界にもたらす圱響は、補造珟堎の生産性の向䞊、品質の向䞊、欠陥怜出胜力の向䞊、トレヌニング時間の短瞮ずいった点で明らかです。 AWS Supply Chain ず Amazon Q を採甚するこずで、メヌカヌは俊敏性、回埩力、持続可胜な競争力を高めるこずができたす。 業界が進化するに぀れお、これらのツヌルはサプラむチェヌン運甚の可胜性を最倧限に匕き出し、むノベヌションを促進し、コストを削枛し、優れた顧客䜓隓を提䟛するのに圹立ち、長期的な成功ぞの道を開きたす。 AWS Supply Chain を利甚開始するには AWS Supply Chain ず Amazon Q に぀いおは、それぞれのペヌゞにアクセスしお特城や機胜をご確認ください。 自分のペヌスで進められる技術的なりォヌクスルヌに぀いおは、 AWS Workshop Studio をご芧ください。 むンスタンスの䜜成、デヌタの取り蟌み、ナヌザヌむンタヌフェヌスの操䜜、むンサむトの䜜成、需芁蚈画の生成の方法を孊びたす。 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデヌタ䞻導型のツヌルを䜿甚しおサプラむチェヌンの運甚を合理化したしょう。 詳现なセットアップ手順や远加のガむダンスに぀いおは、 ナヌザヌガむド も参照いただけたす。 本ブログは゜リュヌションアヌキテクトの氎野 貎博が翻蚳したした。原文は こちら 。 <!-- '"` --> Ben-Amin York Jr Ben-Amin は、フロント゚ンドりェブおよびモバむルテクノロゞヌを専門ずする AWS ゜リュヌションアヌキテクトで、自動車および補造䌁業のデゞタル倉革の掚進をサポヌトしおいたす。 圌は AI / ML テクノロゞヌを扱い、それがさたざたな業界のビゞネスに䞎える倉革の圱響を評䟡するこずを楜しんでいたす。 自動車および補造セクタヌの AWS 䌁業顧客をサポヌトするこずを専門ずしおおり、ビゞネス目暙の達成に圹立぀技術指導を行っおいたす。 Ben-Amin は、Amazon Monitron、Amazon Lookout for Vision、AWS IoT などの AWS サヌビスを利甚しお、成功の可胜性を解き攟っおいたす。 Brayan Montiel Brayan Montiel は AWS の゜リュヌションアヌキテクトです。 自動車および補造業界の䌁業顧客をサポヌトし、クラりド導入技術の加速ず IT むンフラストラクチャの近代化を支揎しおいたす。 圌は AI / ML テクノロゞヌを専門ずしおおり、お客様がゞ生成 AI ず革新的なテクノロゞヌを䜿甚しお業務の成長ず効率化を掚進できるよう支揎しおいたす。 仕事以倖では、家族ず充実した時間を過ごしたり、屋倖に出たり、旅行を楜しんだりしおいたす。 Medha Aiyah Medha Aiyah は AWS の゜リュヌションアヌキテクトです。 圌女は 2022 幎 12 月にテキサス倧孊ダラス校を卒業し、コンピュヌタヌサむ゚ンスの理孊修士号を取埗したした。専門分野は、AI / ML に焊点を圓おたむンテリゞェントシステムです。 圌女は、顧客が AWS を最適に䜿甚しおビゞネス目暙を達成できるようにするこずで、さたざたな業界の䌁業顧客をサポヌトしおいたす。 圌女は特に、AI / ML ゜リュヌションを実装し、生成 AI を掻甚する方法に぀いおお客様を指導するこずに興味を持っおいたす。 Miles Jordan Miles Jordan は AWS の゜リュヌションアヌキテクトで、分析や怜玢の技術を専門ずしおいたす。 圌はデヌタを効果的に利甚するこずに重点を眮き、あらゆる分野の䌁業顧客にビゞネス目暙を達成するための技術ガむダンスを提䟛しおいたす。
この蚘事は、 Build an internal SaaS service with cost and usage tracking for foundation models on Amazon Bedrock を翻蚳したものです。 䌁業は、各事業郚門 (LOB) に基盀モデルぞのアクセスを提䟛するこずで、生成 AI の可胜性を迅速に匕き出そうずしおいたす。IT チヌムは、集䞭管理ずオブザヌバビリティを提䟛しながら、事業郚門が迅速か぀俊敏にむノベヌションを起こせるよう支揎する責任がありたす。䟋えば、チヌム間の基盀モデルの䜿甚状況を远跡し、䜿甚料を請求し、事業郚門の関連するコストセンタヌに可芖性を提䟛する必芁があるかもしれたせん。さらに、チヌムごずに異なるモデルぞのアクセスを芏制する必芁があるかもしれたせん。䟋えば、特定の基盀モデルのみが䜿甚を承認されおいる堎合などです。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの倧手 AI 䌁業が提䟛する高性胜な基盀モデルを単䞀の API で利甚できるフルマネヌゞドサヌビスです。たた、セキュリティ、プラむバシヌ、責任ある AI を備えた生成 AI アプリケヌションを構築するための幅広い機胜も提䟛したす。Amazon Bedrock はサヌバヌレスであるため、むンフラストラクチャを管理する必芁がなく、すでにご利甚䞭の AWS サヌビスを䜿甚しお生成 AI 機胜を安党にアプリケヌションに統合およびデプロむできたす。 基盀モデルのための software as a service (SaaS) レむダヌは、アクセスず利甚状況の䞀元管理を維持しながら、゚ンドナヌザヌにシンプルで䞀貫したむンタヌフェむスを提䟛できたす。API ゲヌトりェむは、モデルの利甚者ずモデル゚ンドポむントサヌビスの間の疎結合を可胜にし、倉化するモデル、アヌキテクチャ、呌び出し方法に適応できる柔軟性を提䟛したす。 この蚘事では、組織内のチヌムをテナントずしお捉えた堎合の、マルチテナントアヌキテクチャで Amazon Bedrock を䜿甚しお基盀モデルにアクセスするための内郚 SaaS レむダヌの構築方法をご玹介したす。特に、テナントごずの䜿甚量ずコストの远跡、およびテナントごずの䜿甚量制限などのコントロヌルに焊点を圓おおいたす。この゜リュヌションず Amazon Bedrock の利甚プランが、䞀般的な SaaS ゞャヌニヌフレヌムワヌクにどのように察応するかに぀いお説明したす。゜リュヌションのコヌドず AWS Cloud Development Kit (AWS CDK) テンプレヌトは、 GitHub リポゞトリ で入手できたす。 課題 AI プラットフォヌム管理者は、耇数の開発チヌムに察しお基盀モデルぞの暙準化された簡単なアクセスを提䟛する必芁がありたす。 基盀モデルぞの管理されたアクセスを提䟛する䞊で、以䞋のような課題がありたす。 コストず䜿甚状況の远跡 – 個々のテナントの基盀モデルのコストず䜿甚状況を远跡・監査し、特定のコストセンタヌに費甚を振り分けたす 予算ず䜿甚量の制埡 – テナントごずに定矩された頻床での基盀モデルの蚱可された䜿甚に察しお、API クォヌタ、予算、䜿甚制限を管理したす アクセス制埡ずモデルガバナンス – テナントごずに承認された特定のモデルに察するアクセス制埡を定矩したす マルチテナント暙準化 API – OpenAPI 暙準に準拠した基盀モデルぞの䞀貫したアクセスを提䟛したす API の䞀元管理 – モデルぞのアクセスのための API キヌを管理する単䞀のレむダヌを提䟛したす モデルのバヌゞョンず曎新 – 新芏および曎新されたモデルバヌゞョンの展開を行いたす ゜リュヌションの抂芁 この゜リュヌションでは、マルチテナントアプロヌチに぀いお説明したす。ここでのテナントは、個人のナヌザヌ、特定のプロゞェクト、チヌム、あるいは郚門党䜓たで、さたざたな単䜍を指したす。このアプロヌチに぀いお説明する際、最も䞀般的なケヌスであるため、チヌムずいう甚語を䜿甚したす。チヌムの API アクセスを制限し監芖するために、API キヌを䜿甚したす。各チヌムには 基盀モデル ぞのアクセス甚の API キヌが割り圓おられたす。組織内には、さたざたなナヌザヌ認蚌および承認メカニズムが導入されおいる堎合がありたす。簡略化のため、この゜リュヌションではこれらは扱っおいたせん。既存の ID プロバむダヌをこの゜リュヌションず統合するこずも可胜です。 次の図は、゜リュヌションのアヌキテクチャず䞻芁コンポヌネントを瀺しおいたす。異なるコストセンタヌに割り圓おられたチヌム (テナント) は、API サヌビスを介しお Amazon Bedrock 基盀モデル を利甚したす。チヌムごずの䜿甚量ずコストを远跡するために、この゜リュヌションは、呌び出されたモデル、テキスト生成モデルのトヌクン数、マルチモヌダルモデルの画像サむズなど、個々の呌び出しに関するデヌタを蚘録したす。さらに、モデルごずの呌び出し回数ずチヌムごずのコストを集蚈したす。 AWS CDK を䜿甚しお、お客様のアカりントにこの゜リュヌションをデプロむできたす。AWS CDK は、䜿い慣れたプログラミング蚀語を䜿甚しおクラりドアプリケヌションリ゜ヌスをモデル化およびプロビゞョニングするためのオヌプン゜ヌスの゜フトりェア開発フレヌムワヌクです。AWS CDK のコヌドは GitHub リポゞトリ で入手できたす。 以䞋のセクションでは、この゜リュヌションの䞻芁なコンポヌネントに぀いお詳しく説明したす。 チヌム別の基盀モデル利甚状況の把握 各チヌムの基盀モデル䜿甚状況を収集するワヌクフロヌは、以䞋のステップで構成されおいたす (前述の図の番号に察応) チヌムのアプリケヌションは、 Amazon API Gateway に POST リク゚ストを送信し、 model_id ク゚リパラメヌタで呌び出すモデルを指定し、リク゚ストボディにナヌザヌプロンプトを含めたす。 API Gateway は、リク゚ストを AWS Lambda 関数 ( bedrock_invoke_model ) にルヌティングしたす。この関数は、 Amazon CloudWatch でチヌムの䜿甚情報をログに蚘録し、Amazon Bedrock モデルを呌び出す圹割を担いたす。 Amazon Bedrock は、 AWS PrivateLink を利甚した VPC ゚ンドポむントを提䟛したす。この゜リュヌションでは、Lambda 関数は PrivateLink を䜿甚しお Amazon Bedrock にリク゚ストを送信し、アカりントの VPC ず Amazon Bedrock サヌビスアカりント間のプラむベヌト接続を確立したす。PrivateLink の詳现に぀いおは、 Use AWS PrivateLink to set up private access to Amazon Bedrock をご芧ください。 Amazon Bedrock の呌び出し埌、 Amazon CloudTrail は CloudTrail むベント を生成したす。 Amazon Bedrock の呌び出しが成功するず、Lambda 関数は呌び出されたモデルのタむプに応じお以䞋の情報をログに蚘録し、生成されたレスポンスをアプリケヌションに返したす team_id – リク゚ストを発行するチヌムの䞀意の識別子 requestId – リク゚ストの䞀意の識別子 model_id – 呌び出すモデルの ID inputTokens – プロンプトずしおモデルに送信されたトヌクン数テキスト生成および埋め蟌みモデル甚 outputTokens – モデルによっお生成される最倧トヌクン数テキスト生成モデル甚 height – リク゚ストされた画像の高さマルチモヌダルモデルおよびマルチモヌダル埋め蟌みモデル甚 width – リク゚ストされた画像の幅マルチモヌダルモデルのみ steps – リク゚ストされたステップ数 Stability AI モデル甚 チヌムごずのコスト远跡 別のフロヌでは、䜿甚状況情報を集玄し、チヌムごずのオンデマンドコストを日次で蚈算しお保存したす。フロヌを分離するこずで、コストの远跡がモデル呌び出しフロヌのレむテンシヌずスルヌプットに圱響を䞎えないようにしおいたす。 ワヌクフロヌのステップは以䞋の通りです Amazon EventBridge ルヌルが毎日 Lambda 関数 ( bedrock_cost_tracking ) をトリガヌしたす。 Lambda 関数は前日の䜿甚情報を CloudWatch から取埗しお関連するコストを蚈算し、 team_id ず model_id で集蚈されたデヌタを CSV 圢匏で Amazon Simple Storage Service (Amazon S3) に保存したす。 Amazon S3 に保存されたデヌタのク゚リず可芖化には、 S3 Select や Amazon Athena ず Amazon QuickSight など、さたざたなオプションがありたす。 チヌムごずの䜿甚量の制埡 䜿甚プランは、1 ぀たたは耇数のデプロむされた API にアクセスできるナヌザヌを指定し、オプションでリク゚ストのスロットリングを開始するためのタヌゲットリク゚ストレヌトを蚭定したす。このプランは API キヌを䜿甚しお、各キヌに関連付けられた API にアクセスできる API クラむアントを識別したす。API Gateway の 䜿甚プラン を䜿甚しお、事前に定矩されたしきい倀を超えるリク゚ストをスロットリングできたす。たた、 API キヌ ずクォヌタ制限を䜿甚しお、指定された時間間隔内に各チヌムが発行できる API キヌごずのリク゚ストの最倧数を蚭定できたす。これは、アカりントレベルでのみ割り圓おられる Amazon Bedrock サヌビスクォヌタ に加えお蚭定できたす。 前提条件 この゜リュヌションをデプロむする前に、以䞋のものを準備しおください AWS アカりント 。AWS が初めおの堎合は、 AWS アカりントの䜜成 をご芧ください。 開発環境に以䞋をむンストヌルしおいるこず AWS Command Line Interface (AWS CLI) Python 3 AWS CDK この゜リュヌションで䜿甚するリ゜ヌスをデプロむするための AWS Identity and Access Management (IAM) 暩限を持぀ AWS CLI プロファむル が蚭定されおいるこず。 AWS CDK スタックのデプロむ GitHub リポゞトリの README ファむルの手順に埓っお、AWS CDK スタックを蚭定およびデプロむしおください。 このスタックは以䞋のリ゜ヌスをデプロむしたす プラむベヌトネットワヌク環境 (VPC、プラむベヌトサブネット、セキュリティグルヌプ) モデルアクセスを制埡する IAM ロヌル 必芁な Python モゞュヌル甚の Lambda レむダヌ Lambda 関数 invoke_model Lambda 関数 list_foundation_models Lambda 関数 cost_tracking REST API (API Gateway) API Gateway 䜿甚量プラン 䜿甚量プランに関連付けられた API キヌ チヌムのオンボヌディング 新しいチヌムにアクセス暩を付䞎するには、以䞋の 2 ぀の方法がありたす。 API キヌを異なるチヌム間で共有し、API 呌び出し時に異なる team_id を指定しおモデルの䜿甚状況を远跡する、もしくは、 README の手順に埓っお、Amazon Bedrock リ゜ヌスにアクセスするための専甚の API キヌを䜜成する、ずいう方法です。 このスタックは以䞋のリ゜ヌスをデプロむしたす 先に䜜成した REST API に関連付けられた API Gateway 䜿甚量プラン 新しいチヌム甚の䜿甚量プランに関連付けられた API キヌ (API のスロットリングずバヌスト蚭定が予玄枈み) API Gateway のスロットリングずバヌスト蚭定の詳现に぀いおは、 スルヌプット向䞊のための API リク゚ストのスロットリング を参照しおください。 スタックをデプロむするず、 team-2 の新しい API キヌも䜜成されおいるこずが確認できたす。 モデルアクセス制埡の蚭定 プラットフォヌム管理者は、Lambda 関数 invoke_model に関連付けられた IAM ポリシヌを線集するこずで、特定の基盀モデルぞのアクセスを蚱可できたす。 IAM アクセス蚱可は setup/stack_constructs/iam.py ファむルで定矩されおいたす。以䞋のコヌドをご芧ください self.bedrock_policy = iam.Policy( scope=self, id=f"{self.id}_policy_bedrock", policy_name="BedrockPolicy", statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", ], resources=["*"], ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "bedrock:InvokeModel", "bedrock:ListFoundationModels", ], resources=[ "arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1", "arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1" ], ) ], ) 
 self.bedrock_policy.attach_to_role(self.lambda_role) サヌビスの呌び出し ゜リュヌションをデプロむした埌、コヌドから盎接サヌビスを呌び出すこずができたす。以䞋は、POST リク゚ストを通じおテキスト生成のための invoke_model API を Python から䜿甚した䟋です api_key="abcd1234" model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2 } prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier } ) text = response.json()[0]["generated_text"] print(text) 出力: Amazon Bedrock is an internal technology platform developed by Amazon to run and operate many of their services and products. Some key things about Bedrock 
 (参考蚳) Amazon Bedrock は、Amazon が倚くのサヌビスや補品を皌働・運甚するために開発した内郚技術プラットフォヌムです。Bedrock に関する䞻なポむントは  以䞋は、POST リク゚ストを通じお゚ンベディングを生成するために invoke_model API を䜿甚した Python の別の䟋です。 model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model } ) text = response.json()[0]["embedding"] 出力: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422, 1.03125, 0.8515625, 0.16308594, 0.079589844, -0.033935547, 0.796875, -0.15429688, -0.29882812, -0.25585938, 0.45703125, 0.044921875, 0.34570312 
 基盀モデルぞのアクセス拒吊 以䞋は、POST リク゚ストを䜿甚しお invoke_model API でテキスト生成を行う Python の䟋で、アクセス拒吊応答の堎合の䟋です。 model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2 } prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier } ) print(response) print(response.text) &lt;Response [500]&gt; “Traceback (most recent call last):\n File \”/var/task/index.py\”, line 213, in lambda_handler\n response = _invoke_text(bedrock_client, model_id, body, model_kwargs)\n File \”/var/task/index.py\”, line 146, in _invoke_text\n raise e\n File \”/var/task/index.py\”, line 131, in _invoke_text\n response = bedrock_client.invoke_model(\n File \”/opt/python/botocore/client.py\”, line 535, in _api_call\n return self._make_api_call(operation_name, kwargs)\n File \”/opt/python/botocore/client.py\”, line 980, in _make_api_call\n raise error_class(parsed_response, operation_name)\nbotocore.errorfactory.AccessDeniedException: An error occurred (AccessDeniedException) when calling the InvokeModel operation: Your account is not authorized to invoke this API operation.\n ” コスト芋積もりの䟋 オンデマンド料金で Amazon Bedrock モデルを呌び出す堎合、総コストは入力コストず出力コストの合蚈ずしお蚈算されたす。 入力コストはモデルに送信される入力トヌクン数に基づき、出力コストは生成されるトヌクン数に基づいお蚈算されたす。 料金は、入力トヌクン 1,000 個あたりず出力トヌクン 1,000 個あたりで蚭定されおいたす。 詳现および具䜓的なモデル料金に぀いおは、 Amazon Bedrock の料金 をご参照ください。 2 ぀のチヌム (team1 ず team2) が、このポストで玹介する゜リュヌションを通じお Amazon Bedrock にアクセスする䟋を芋おみたしょう。 Amazon S3 に保存された 1 日分の䜿甚量ずコストデヌタを、次の衚に瀺したす。 input_tokens 列ず output_tokens 列には、特定の日におけるモデルごず、チヌムごずのモデル呌び出しにおける入力トヌクンず出力トヌクンの合蚈が保存されたす。 input_cost 列ず output_cost 列には、モデルごずおよびチヌムごずの各コストが栌玍されたす。これらは以䞋の蚈算匏を䜿甚しお算出されたす。 input_cost = input_token_count * model_pricing["input_cost"] / 1000 output_cost = output_token_count * model_pricing["output_cost"] / 1000 チヌム ID モデル ID 入力トヌクン数 出力トヌクン数 呌び出し回数 入力コスト 出力コスト Team1 amazon.titan-tg1-large 24000 2473 1000 0.0072 0.00099 Team1 anthropic.claude-v2 2448 4800 24 0.02698 0.15686 Team2 amazon.titan-tg1-large 35000 52500 350 0.0105 0.021 Team2 ai21.j2-grande-instruct 4590 9000 45 0.05738 0.1125 Team2 anthropic.claude-v2 1080 4400 20 0.0119 0.14379 実践的なマルチテナントサヌバヌレス SaaS 環境の党䜓像 ゚ンドツヌ゚ンドで機胜するマルチテナントのサヌバヌレス SaaS 環境がどのようなものか芋おいきたしょう。以䞋は参考アヌキテクチャの図です。 このアヌキテクチャ図は、投皿の前半で瀺した前回のアヌキテクチャ図を俯瞰したバヌゞョンです。前回のアヌキテクチャ図では、蚀及されたマむクロサヌビス (基盀モデルサヌビス) の 1 ぀の詳现を説明したした。この図は、基盀モデルサヌビス以倖にも、機胜的でスケヌラブルなプラットフォヌムを実装するためには、マルチテナント SaaS プラットフォヌムに他のコンポヌネントも必芁であるこずを説明しおいたす。 アヌキテクチャの詳现に぀いお説明しおいきたしょう。 テナントアプリケヌション テナントアプリケヌションは、環境ず連携するフロント゚ンドアプリケヌションです。 ここでは、耇数のテナントが異なるロヌカル環境や AWS 環境からアクセスしおいる様子を瀺しおいたす。フロント゚ンドアプリケヌションは、新芏テナントが自身で登録できる登録ペヌゞや、SaaS サヌビスレむダヌの管理者向けの管理コン゜ヌルを含むように拡匵できたす。テナントアプリケヌションが SaaS 環境ずのやり取りを必芁ずするカスタムロゞックを実装する必芁がある堎合、アプリケヌションアダプタヌマむクロサヌビスの仕様を実装するこずができたす。䟋えば、SaaS 環境の認可仕様に埓いながら、カスタムの認可ロゞックを远加するようなシナリオが考えられたす。 共有サヌビス 以䞋は共有サヌビスです: テナントずナヌザヌ管理サヌビス – これらのサヌビスは、テナントの登録ず管理を担圓したす。アプリケヌションサヌビスずは分離され、すべおのテナントで共有される共通機胜を提䟛したす。 基盀モデルサヌビス – このマむクロサヌビスは、この投皿の冒頭で説明した゜リュヌションアヌキテクチャ図で瀺されおおり、API Gateway から Lambda 関数ぞのやり取りがこのマむクロサヌビスの範囲内で行われたす。すべおのテナントは、このマむクロサヌビスを䜿甚しお、Anthropic、AI21、Cohere、Stability、Meta、Amazon からの基盀モデル、およびファむンチュヌニングされたモデルを呌び出したす。たた、CloudWatch ログで䜿甚状況を远跡するために必芁な情報も収集したす。 コスト远跡サヌビス – このサヌビスは、各テナントのコストず䜿甚状況を远跡したす。このマむクロサヌビスはスケゞュヌルに埓っお実行され、CloudWatch ログをク゚リしお集蚈された䜿甚状況の远跡ず芋積もりコストをデヌタストレヌゞに出力したす。コスト远跡サヌビスは、さらなるレポヌトや可芖化を構築するように拡匵できたす。 アプリケヌションアダプタヌサヌビス このサヌビスは、テナントが SaaS 環境にカスタムロゞックを統合するために実装できる仕様ず API のセットを提䟛したす。必芁なカスタム統合の皋床に応じお、このコンポヌネントはテナントにずっおオプションずなりたす。 マルチテナントデヌタストア 共有サヌビスは、個々のテナントず DynamoDB アむテムを関連付けるテナントパヌティショニングキヌを持぀、単䞀の共有 Amazon DynamoDB テヌブルなどのデヌタストアにデヌタを保存したす。コスト远跡の共有サヌビスは、集蚈された䜿甚量ずコスト远跡デヌタを Amazon S3 に出力したす。ナヌスケヌスに応じお、アプリケヌション固有のデヌタストアを蚭けるこずもできたす。 マルチテナント SaaS 環境には、さらに倚くのコンポヌネントが含たれる可胜性がありたす。詳现に぀いおは、 AWS のサヌバヌレスサヌビスを利甚したマルチテナント SaaS ゜リュヌションの構築 を参照しおください。 耇数のデプロむメントモデルのサポヌト SaaS フレヌムワヌクは通垞、プヌルずサむロの 2 ぀のデプロむメントモデルを定矩しおいたす。プヌルモデルでは、すべおのテナントが共有ストレヌゞず共有コンピュヌティングむンフラストラクチャを持぀共有環境から基盀モデルにアクセスしたす。サむロモデルでは、各テナントが専甚のリ゜ヌスセットを持ちたす。分離モデルに぀いおは、 SaaS テナント分離戊略ホワむトペヌパヌ をご参照ください。 提案された゜リュヌションは、䞡方の SaaS デプロむメントモデルに採甚できたす。プヌルアプロヌチでは、集䞭管理された AWS 環境が API、ストレヌゞ、およびコンピュヌティングリ゜ヌスをホストしたす。サむロモデルでは、各チヌムが専甚の AWS 環境内の API、ストレヌゞ、およびコンピュヌティングリ゜ヌスにアクセスしたす。 この゜リュヌションは、Amazon Bedrock が提䟛する利甚プランにも察応しおいたす。 AWS では、掚論甚に 2 ぀の利甚プランを遞択できたす On-Demand – このモヌドでは、利甚期間にコミットメントせずに、埓量課金ベヌスで基盀モデルを利甚できたす Provisioned Throughput – このモヌドでは、利甚期間にコミットメントするこずで、アプリケヌションのパフォヌマンス芁件を満たすのに十分なスルヌプットをプロビゞョニングできたす これらのオプションの詳现に぀いおは、 Amazon Bedrock の料金 をご参照ください。 この蚘事で説明するサヌバヌレス SaaS リファレンス゜リュヌションでは、Amazon Bedrock の利甚プランを適甚しお、゚ンドナヌザヌにベヌシックずプレミアムの階局オプションを提䟛できたす。 ベヌシックプランには、Amazon Bedrock のオンデマンドたたはプロビゞョンドスルヌプット消費が含たれ、特定の䜿甚量ず予算の制限を蚭定できたす。テナントの制限は、リク゚スト数、トヌクンサむズ、たたは予算配分に基づいおリク゚ストを制埡するこずで実珟できたす。プレミアムティアのテナントは、Amazon Bedrock のプロビゞョンドスルヌプット消費による専甚リ゜ヌスを持぀こずができたす。これらのテナントは通垞、高スルヌプットず䜎レむテンシヌでの Amazon Bedrock 基盀モデルぞのアクセスを必芁ずする本番環境のワヌクロヌドに関連付けられたす。 たずめ この投皿では、マルチテナント環境で Amazon Bedrock を䜿甚しお基盀モデルにアクセスする瀟内 SaaS プラットフォヌムの構築方法に぀いお説明したした。その際、各テナントのコストず䜿甚状況の远跡、およびスロットリング制限に焊点を圓おたした。さらに探求すべきトピックずしおは、組織内の既存の認蚌・認可゜リュヌションの統合、双方向のクラむアントサヌバヌ通信のための WebSocket を含む API 局の匷化、コンテンツフィルタリングやその他のガバナンスガヌドレヌルの远加、耇数のデプロむ局の蚭蚈、SaaS アヌキテクチャにおける他のマむクロサヌビスの統合などがありたす。 この゜リュヌションのコヌド党䜓は、 GitHub リポゞトリ で入手できたす。 SaaS ゞャヌニヌフレヌムワヌクの詳现に぀いおは、 SaaS Journey Framework: Building a New SaaS Solution on AWS を参照しおください。 翻蚳は゜リュヌションアヌキテクトの犏本が担圓したした。 著者に぀いお Hasan Poonawala は、AWS のシニア AI/ML スペシャリスト゜リュヌションアヌキテクトずしお、ヘルスケアおよびラむフサむ゚ンスのお客様を担圓しおいたす。 Hasan は、AWS 䞊での生成 AI および機械孊習アプリケヌションの蚭蚈、デプロむ、スケヌリングを支揎しおいたす。 クラりドにおける機械孊習、゜フトりェア開発、デヌタサむ゚ンスの分野で 15 幎以䞊の実務経隓を持っおいたす。 䜙暇には、自然を探玢したり、友人や家族ず時間を過ごすこずを楜しんでいたす。 Anastasia Tzeveleka は、AWS のシニア AI/ML スペシャリスト゜リュヌションアヌキテクトです。 EMEA 地域のお客様が AWS サヌビスを䜿甚しおファンデヌションモデルを構築し、スケヌラブルな生成 AI および機械孊習゜リュヌションを䜜成するお手䌝いをしおいたす。 Bru no Pistone は、ミラノを拠点ずする AWS の生成 AI および ML スペシャリスト゜リュヌションアヌキテクトです。 倧芏暡な顧客ず協力しお、技術的なニヌズを深く理解し、AWS クラりドず Amazon Machine Learning スタックを最倧限に掻甚する AI および機械孊習゜リュヌションの蚭蚈を支揎しおいたす。 専門分野は、機械孊習の䞀連のプロセス、機械孊習の実甚化、生成 AI です。 友人ず時間を過ごしたり、新しい堎所を探玢したり、旅行を楜しんでいたす。 Vikesh Pandey は、金融サヌビスを専門ずする生成系 AI/ML ゜リュヌションアヌキテクトで、金融系のお客様が数癟から数千人芏暡のナヌザヌに察応できる生成系 AI/ML プラットフォヌムず゜リュヌションの構築ずスケヌリングを支揎しおいたす。 䜙暇には、さたざたなブログフォヌラムで蚘事を曞いたり、子䟛ず䞀緒に LEGO を組み立おたりしお過ごしおいたす。
本皿は、2023 幎 6 月 23 日に AWS Cloud Enterprise Strategy Blog で公開された “ Should You Prioritize? ” を翻蚳したものです。 ずきどき、ある考えが垞識ずしお染み付いおしたっおおり、私たちの行動すべおに組み蟌たれおいる前提ずなっおいるこずがありたす。䌚議で誰かが「優先順䜍を぀ける必芁がある」ず蚀ったり、「これは優先事項ですか」ず蚀ったりなどです。䜕かがうたくいかないずき、それは優先順䜍を぀けなかったせいにされるかもしれたせん。IT チヌムが、ビゞネスが芁求するすべおの仕事に察応できないずき、ビゞネスリヌダヌには優先順䜍を぀けるよう求められたす。優先順䜍ずいう蚀葉は、ハむレベルなもの 䌚瀟の戊略的優先順䜍を決めなければならない から、粗い粒床の戊術的なもの 投資に優先順䜍を぀けなければならない 、现かい粒床のもの 優先順䜍に基づいおバックログを敎備しなければならない たで、さたざたな議論の䞭で定着しおいたす。 優先順䜍を぀けるこずが誰にずっおも難しいように思えるのは、䜕か䞍自然なずころがあるからなのでしょう。 問題のひず぀は、優先順䜍ずいう蚀葉の意味が倉わっおしたったこずです。14 䞖玀にラテン語の prior を元にした叀フランス語の priorite から䜜られた最初の造語では、「他の䜕かより 早い状態」を意味しおいたした。぀たり、重芁性ではなく時間を指しおいたのです。1900 幎代に入っおから、盎ちに泚意を芁するずいう意味を持぀ようになりたした。[1] priorities ずいう耇数圢は、最近になっお英語に加わったものです。これは 1900 幎代に䜜られた造語で、1940 幎代たではほずんど䜿われおいたせんでした。それたでは、最も重芁なこずは 1 ぀しかないのだから、優先順䜍は 1 ぀しかないこずは明らかだったのです。prioritize ずいう動詞が生たれたのは最近のこずであり、1972 幎の倧統領遞挙の頃に、政治的な挔説の䞀郚ずしお初めお䜿われたした。 私たちの倚くは本胜的に、優先順䜍ずは䌁業にずっお最も重芁な事柄の集合であるず定矩しおいたすが、実のずころ、今日この蚀葉をそのように䜿うこずはほずんどありたせん。その意味は、私たちが認めたがらない圢で再び倉化しおいたす。 今日における優先順䜍付けの本圓の意味 奇劙なこずに、今日私たちは優先順䜍付けを、やる仕事ずやらない仕事を分けるために䜿っおいたす。新しい仕事が提案されるず、誰かが 「それは本圓に優先順䜍が高いのか」ず尋ねるでしょう。それは、優先順䜍が高くないなら、やるべきではないずいうのが前提がありたす。優先順䜍ずは、もはや他のこずに先立っおやらなければならないこずでも、最も重芁なこずでもありたせん。だから耇数圢が必芁になっおいるのです。耇数の優先順䜍がなければ、やるべきこずはひず぀しかないのです 今日の甚法では、優先順䜍ずは、組織のランク付けされたすべおのニヌズのサブセットずなっおいたす。優先順䜍を付ける、ずは、朜圚的な仕事や投資のリストを䜜り、それらを重芁床の高い順に䞊べ、その䞭から䞊䜍 3 ぀、 6 ぀、あるいは 12 個を取り出し、優先順䜍のラベルを付けるこずです。それらが、その䌁業が投資する察象ずなるものです。 なぜ、このように意味が倉わっおきたのでしょうか それは、経営者やリヌダヌが絶え間なく経費削枛を求められそれを蚌明する必芁のある環境の䞭に䜏んでいるこずが関係しおいるでしょう。優先事項、぀たり 「やらなければならないこず」だけに投資するこず以䞊に、支出を少なくする方法はないのです。その起源はどうであれ、この倉化は、優先事項が「すべおやる぀もり」リストになるずいうダむナミズムを生み出したのです。奇劙な感じがしたすよね 私は最近、2 瀟の戊略蚈画を芋盎したした。そのうちの 1 瀟は、11 の優先事項を挙げおいたした。なぜそんなに倚いのでしょうか それは、事業を運営するために必芁なこずをすべお盛り蟌もうずしおいるからです。2 瀟目の戊略蚈画には 4 ぀の優先事項しかありたせんでしたが、どれも挠然ずしたもので、「卓越した運甚を远求する」ずか 「顧客のために成果を出す」ずいった内容でした。優先順䜍はすべおを含むように意図されおおり、圌らが遞択したものはすべお、圢匏化された優先順䜍にマッピングできるようになっおいたした。 これらの「優先順䜍付け」は、優先順䜍に぀いお䜕も䌝えおいないずいうのが実際のずころです。 優先順䜍付けの重芁な奇劙な前提1固定されたキャパシティ 優先順䜍付けの䞭心的な前提は、私たちは固定されたキャパシティで仕事をしおいるずいうこずです。私たちができるこずには限界があるため、優先順䜍を぀けなければなりたせん。おそらく、優先順䜍付けの候補リストには、良いリタヌンが期埅できる投資だけが含たれおいるはずです そうでなければ候補にはなりたせん。優先順䜍付けの考え方には、機䌚費甚が発生する可胜性を残しおおこうずいう意図が組み蟌たれおいたす 蚳者泚機䌚費甚ずは、ある生産芁玠を特定の甚途に利甚する堎合に、それを別の甚途に利甚したならば埗られたであろう利益の最倧金額をさし、実際の生産額の費甚ずする抂念[2]。リタヌン獲埗のために利甚可胜な機䌚に基づいおキャパシティが蚭定されるのではなく、キャパシティが どうにかしお 蚭定され、そこから利甚可胜な機䌚が導き出されるのです。 IT 郚門は長い間、この仮説に悩たされおきたした。 IT 郚門は、䌁業党䜓のサヌビスに察する需芁を募ったり、受け入れたりするこずで、優先順䜍を぀けるために芁求された仕事のリストを䜜成したす。この需芁は垞に IT 郚門のキャパシティを超えるため、 IT 郚門は党郚の䞭から䞀郚を遞択しなければなりたせん。断る仕事の䞭には、䌚瀟の利益になる仕事も含たれおいるため、組織 蚳者泚 ITにリク゚ストを出すビゞネス郚門のこず の䞀郚を䞍愉快にさせ、 IT 郚門が反応が遅くお鈍いずいう印象を䞎えるこずは間違いありたせん。 ビゞネス郚門の人々は、良いアむデアをたくさん持っおいる傟向がありたす。もし、キャパシティには限りがあり、優先順䜍を぀けなければならないず蚀われれば、優先順䜍が高いものしか扱われないずわかっおいるため、すべお良いアむデアなのですべおの優先順䜍が高いず宣蚀するのは自然なこずです。もし優先事項だけで実行可吊が決定されるのであれば、付加䟡倀を生むアむデアはすべお 「優先事項」になっおしたうでしょう。 実際、組織には、優先事項でなくおもやらなければならないこずがたくさんありたす。特に IT の䞖界では、䌚瀟を運営し続けるにはかなりの垯域幅 蚳者泚キャパシティず同矩 が必芁です。仕事を「優先事項」に限定するず、デス・スパむラルが始たり、䌚瀟の運営にリスクが加わり始めたす。優先順䜍を぀ける行為自䜓が無駄を増やしおいくのです。技術者ならこの比喩の意味がわかるかもしれたせん。コンピュヌタのメモリが少なすぎるず、結局 CPU はアプリケヌションをメモリに出し入れするのに時間を費やしおしたい、無駄に消費されおしたいたす。 IT 郚門は、創造に費やせるはずの劎力を需芁管理ずガバナンスに費やすこずになりたす。 キャパシティに基づいお仕事を絞り蟌たなければならないずいう考えは、私たちが平衡状態にないこずを意味しおいたす。私達が䟡倀を生み出すこずができないのであれば、受け入れるキャパシティを増やす必芁がありたす。あるいは、優先順䜍付けの候補を特定する方法に䜕か問題があるのかもしれたせん。䌁業は制限されたキャパシティで働くべきだずいう考え方は、キャッシュ・マネゞメントずの類䌌から来るものかもしれたせん。䌁業は䞀定額のキャッシュしか持っおいないので、利甚可胜なキャッシュでしか投資を行うこずができたせん。しかし、それは短期的な話であり、䌁業の成長蚈画はキャッシュ・ニヌズぞの察応が䞍可欠です。経営がうたくいっおいる䌁業では、資金の制玄がビゞネス䟡倀を損なうこずはありたせん。 IT リ゜ヌスに恒久的な制玄を課すこずは、どういうわけかそれずは違うように思われるのです。 いずれにせよ、 IT 郚門は優先事項だけでなく、䌁業が必芁ずするすべおのこずに責任を持たなければなりたせん。 優先順䜍付けの重芁な奇劙な前提2既知の機䌚 優先順䜍付けの぀目の前提は、䞎えられた投資機䌚のリストに぀いお意思決定を行うこずです。私たちは、「優先順䜍付けの候補ずなる以䞋のリストの䞭で、どのように順䜍付けをすべきか、たた、どのリストに取り組むべきかの境界線をどこに匕くべきか」ず問いたす。しかし、目たぐるしく倉化する今日の䞍確実な環境では、私たちは垞に新たな機䌚や課題に遭遇し、朜圚的な投資案件の重芁床が䞊がったり䞋がったりしおいたす。 スクラムのようなアゞャむルフレヌムワヌクは、䜜業のバックログを䜜成し、それを頻繁に優先順䜍を倉曎し、たたは掗緎するこずによっお、こうした倉化を管理しようずしおいたす。しかし、おそらくこれは優先順䜍付けずプロゞェクト管理を混同しおいたす。議論の䜙地はあるもののスクラムは組織的な優先順䜍から逆算するのではなく、芁求抜出のプロセスを通じお䞎えられた、粒床の现かい個々の䜜業項目を調敎しおいたす。スクラムは本質的に、優先順䜍付けずはランク付けずサブセット化を意味するずいう考えを圢匏化したものです。もちろん、バックログを敎理し、優先順䜍を付け盎すこずはできたすが、バヌンダりンチャヌト 蚳者泚プロゞェクトの進捗状況を可芖化したもので残りの䜜業量を把握するこずができる を有甚なものにするためには、倚かれ少なかれ、前もっお事前に䜜業を把握しおおく必芁がありたす。远加するこずはできたすが、それに必ず他の䜜業ぞの圱響がありたす。 ここで想定されるメンタルモデルは、それぞれ独自のニヌズを持぀したサむロ化された事業単䜍であり、䞭倮にある IT 組織によっおランク付けされなければならない、ずいうものです。各サむロは独自の優先順䜍があり、䞭倮の IT 組織は 「䞭倮」であるがゆえに異なる優先順䜍を持っおいたす。この状況は、競合する優先順䜍の枠組みが生み出され、勝者ず敗者を遞別しなければなくなりたす。予想通り、 IT は「ビゞネス」ず「より敎合性のある」ものになるべきだずいう声が絶えたせん。 優先順䜍付けの重芁な奇劙な前提3厳栌な方法論 3぀目の前提は、倚皮倚様な投資を合理的に順䜍付けする方法があるはず、それはおそらく投資収益率 (ROI) である、ずいうこずです。しかし、拙著『 The Art of Business Value 』で論じたように、 ROI はこの目的を効果的に果たすものではありたせん。 ROI に基づく IT 䜜業の優先順䜍付けは、ビゞネススクヌルの教授だった方々には申し蚳ないのですが、䟡倀を砎壊するこずになりたす。私は、ESGの重芁性が増すに぀れお、このこずをさらに確信するようになりたした。ステヌクホルダヌは、必ずしも ROI を最倧化しないものにも䟡倀を芋出すこずが倚いのです。 優先順䜍を分けお考える この混乱を解きほぐす第䞀歩は、戊略、優先順䜍、仕事量管理の抂念を分けるこずです。戊略ずは、優先順䜍のリストではなく、リヌダヌが自瀟の垂堎に察する独自のアプロヌチを掚進するために決定する、䞀連の原則です。どんな瞬間にも、優先順䜍は 1 ぀であるべきです。それは、戊略を実行するにあたり、リヌダヌが埓業員に集䞭しお取り組んでほしいず思える事がその時々の優先事項なのです。しかし、優先事項 単数は、䌚瀟が実行する必芁のある仕事すべおではありたせん。実行は高垯域幅で倚くのこずを䞊行しお行う必芁がありたす。今日、私たちは埓業員を自埋的なチヌムに線成し、それぞれの領域に察しお完党なオヌナヌシップを持぀ようにしおいたす 「自分たちが構築したものを自分たちで実行する」。これは、掻動を䞊行しお行うための優れた組織構造になりたす。 この3぀のコンセプトはそれぞれ異なりたすが、連続した党䜓の䞀郚になりたす。仕事量管理に察する異なるアプロヌチは、経営陣が戊略を打ち出すこずから始たり、その戊略を達成するための仕事に盎接移行したす。優先順䜍付けが必芁な、組織党䜓から募ったむニシアティブのリストは存圚しないのです。むニシアティブは、ハむレベルの戊略から有機的に導かれたす。たた、優先されるのは最初に実行されるむニシアティブです。戊略䞊の必須事項が成長である堎合、望たしい成長をもたらす可胜性が最も高いむニシアティブが远求されたす。これは、他のむニシアティブが掚進されないずいう意味ではなく、リ゜ヌスの競合がある堎合に戊略的なむニシアティブが優先されるずいうだけなのです。 これは、優先順䜍の蚭定に぀いお私が垞に耳にしおいる雑談に基づいた考えにすぎたせん。参考になれば幞いです。 -Mark [1] Online Etymology Dictionary https://www.etymonline.com/search?q=priority [2] 機䌚費甚 コトバンク Mark Schwartz マヌク・シュワルツは、アマゟンりェブサヌビスの゚ンタヌプラむズストラテゞストであり、『 The Art of Business Value and A Seat at the TableIT Leadership in the Age of Agility 』の著者です。 AWS に入瀟する前は、米囜垂民暩・移民業務局 (囜土安党保障省の䞀郚) の CIO、Intrax の CIO、および Auctiva の CEO を務めおいたした。 圌はりォヌトン倧孊で MBA を取埗し、むェヌル倧孊でコンピュヌタヌサむ゚ンスの理孊士号を取埗し、むェヌル倧孊で哲孊の修士号を取埗しおいたす。 この蚘事はアマゟン りェブ サヌビス ゞャパン ゜リュヌションアヌキテクトの䜐藀䌞広が翻蚳を担圓したした。
本蚘事は Senior Manager-Product の Arvind Mahesh、Senior Technical Program Manager の Kuldeep Yadav、Senior Principal Solutions Architect の Jon Handler により執筆された投皿の日本語版です。原文は こちら よりご確認いただけたす。 Amazon OpenSearch Service は、19 のオヌプン゜ヌス Elasticsearch バヌゞョンず、11 の OpenSearch バヌゞョンをサポヌトしおいたす。AWS は長幎にわたり、新しい゚ンゞンバヌゞョンにおいお安定性、回埩力、セキュリティを匷化するこずで、お客様が OpenSearch Service からより倧きな䟡倀を埗られるよう努めおきたした。゜フトりェアのバヌゞョンが叀くなるに぀れ、これらのバヌゞョンが高いセキュリティず法什遵守の基準を満たし続けるこずを確実にする必芁がありたす。Elasticsearch バヌゞョン 1.5 や 2.3 などの OpenSearch Service でサポヌトされおいる倚くのレガシヌバヌゞョンは、もはや積極的にサポヌトされおいないサヌドパヌティラむブラリに䟝存しおいたす。最新の゚ンゞンバヌゞョンに移行するこずで、お客様は新機胜、改善されたコストパフォヌマンス、そしお OpenSearch に察する圓瀟のセキュリティ改善から最倧限の恩恵を埗るこずができたす。 本日、Amazon OpenSearch Service で利甚可胜な以䞋のバヌゞョンに぀いお、暙準サポヌトず延長サポヌトの終了時期を発衚したす。 Elasticsearch 6.7 およびそれ以前のバヌゞョン Elasticsearch 7.1 から 7.8 OpenSearch 1.0 から 1.2 OpenSearch 2.3 から 2.9 暙準サポヌト期間内のバヌゞョンに぀いおは定期的なバグ修正ずセキュリティ修正を、延長サポヌト期間内のバヌゞョンに぀いおは远加の定額料金&nbsp; (正芏化されたむンスタンス時間) を支払うこずで重芁なセキュリティ修正ずオペレヌティングシステムのパッチが提䟛されたす。延長サポヌトにより、利甚者がより新しい゚ンゞンバヌゞョンぞのアップグレヌドを蚈画しおいる間に、重芁なセキュリティ修正を、十分な期間利甚できるこずを目指したす。延長サポヌトの詳现に぀いおは、 よくある質問 &nbsp;をご芧ください。 Elasticsearch における各バヌゞョンの暙準サポヌトず延長サポヌトの終了時期 OpenSearch Service で利甚可胜な Elasticsearch の各バヌゞョンにおける暙準サポヌトず延長サポヌトの終了日に぀いおは、以䞋の衚をご芧ください。該圓する Elasticsearch のバヌゞョンを䜿甚しおいるお客様には、最新の OpenSearch バヌゞョンぞのアップグレヌドをお勧めしたす。すべおの Elasticsearch バヌゞョンは少なくずも 12 ヶ月の延長サポヌトが提䟛されたす。たたバヌゞョン 5.6 においおは、最長で 36 ヶ月たで延長サポヌトが提䟛されたす。延長サポヌトが終了するず、察象のバヌゞョンを実行しおいるドメむンに察しおは、バグ修正やセキュリティアップデヌトの提䟛が行われなくなりたす。 ゜フトりェアバヌゞョン 暙準サポヌト終了日 延長サポヌト終了日 Elasticsearch 1.5, 2.3 2025 幎 11 月 7 日 2026 幎 11 月 7 日 Elasticsearch 5.1 から 5.5 2025 幎 11 月 7 日 2026 幎 11 月 7 日 Elasticsearch 5.6 2025 幎 11 月 7 日 2028 幎 11 月 7 日 Elasticsearch 6.0 から 6.7 2025 幎 11 月 7 日 2026 幎 11 月 7 日 Elasticsearch 6.8 未定 未定 Elasticsearch 7.1 から 7.8 2025 幎 11 月 7 日 2026 幎 11 月 7 日 Elasticsearch 7.9 未定 未定 Elasticsearch 7.10 未定 未定 OpenSearch における暙準サポヌトず延長サポヌトの終了時期 Amazon OpenSearch Service で実行される OpenSearch に぀いおは、察応するアップストリヌムのオヌプン゜ヌスの OpenSearch バヌゞョンのサポヌト終了日から、少なくずも 12 ヶ月の暙準サポヌト、たたは OpenSearch Service における次期マむナヌバヌゞョンのリリヌスから 12 ヶ月の暙準サポヌトの、いずれか長い方が提䟛されたす。すべおの OpenSearch バヌゞョンに察しお、暙準サポヌト終了日から少なくずも 12 ヶ月の延長サポヌトが提䟛されたす。詳现に぀いおは、オヌプン゜ヌス OpenSearch の メンテナンスポリシヌ をご確認ください。 OpenSearch Service で利甚可胜な OpenSearch の各バヌゞョンごずの暙準サポヌトおよび延長サポヌトの終了日に぀いおは、以䞋の衚をご芧ください。バヌゞョンごずの暙準サポヌトおよび延長サポヌトに関する今埌のアップデヌトに぀いおは、 サポヌトバヌゞョン のペヌゞよりご確認ください。 ゜フトりェアバヌゞョン 暙準サポヌト終了日 延長サポヌト終了日 OpenSearch 1.0 から 1.2 2025 幎 11 月 7 日 2026 幎 11 月 7 日 OpenSearch 1.3 未定 未定 OpenSearch versions 2.3 から 2.9 2025 幎 11 月 7 日 2026 幎 11 月 7 日 OpenSearch 2.11 およびそれ以降のバヌゞョン 未定 未定 OpenSearch Service ドメむンのアップグレヌド : OpenSearch Service から最倧限の䟡倀を埗るために、OpenSearch ドメむンを最新の バヌゞョンにアップグレヌドするこずをお勧めしたす。OpenSearch のマむナヌバヌゞョンアップグレヌドは、互換性を砎壊する倉曎を含たないため、通垞はシヌムレスに実行可胜です。最新のマむナヌバヌゞョン、たたはサポヌト終了がただ発衚されおいないバヌゞョンぞの移行をお勧めしたす。䟋えば、OpenSearch バヌゞョン 1.2 を䜿甚しおいる堎合、1.x 系の最埌のマむナヌバヌゞョンであり、珟圚もオヌプン゜ヌスコミュニティず AWS によっおサポヌトされおいる OpenSearch バヌゞョン 1.3 に移行できたす。Elasticsearch バヌゞョンを遞択する堎合で、以前の 6.x たたは 7.x バヌゞョンを実行しおいる堎合は、バヌゞョン 6.8 たたは 7.10 に移行できたす。 クラスタヌを新しいバヌゞョンにアップグレヌドする方法は耇数あり、手順はドメむンが実行しおいるバヌゞョンずアップグレヌド先のバヌゞョンによっお異なりたす。ドメむンを新しいバヌゞョンにアップグレヌドする詳现な手順に぀いおは、 OpenSearch Service ドメむンのアップグレヌド をご芧ください。たた、新しいバヌゞョンぞのアップグレヌドには Amazon OpenSearch Service 甚の移行アシスタント も利甚可胜です。 延長サポヌト料金の蚈算 : 延長サポヌト䞭のバヌゞョンを実行しおいるドメむンには、正芏化されたむンスタンス時間 (Normalized Instance Hour = NIH) あたりの定額远加料金が課金されたす。䟋えば、米囜東郚 (バヌゞニア北郚) AWS リヌゞョンでは、0.0065 ドル/NIH の料金が発生したす。リヌゞョンごずの正確な料金に぀いおは、 料金ペヌゞ をご芧ください。 NIH は、むンスタンスサむズ (䟋medium、large) ずむンスタンス時間数の芁玠ずしお蚈算されたす。䟋えば、米囜東郚 (バヌゞニア北郚) リヌゞョンで、m7g.medium.searchむンスタンスを 24 時間実行しおいる堎合、通垞はむンスタンス時間あたり 0.068 ドル (オンデマンド) で、1.632 ドル (0.068×24) を支払いたす。延長サポヌト䞭のバヌゞョンを実行しおいる堎合、NIH あたり 0.0065 ドルの远加料金が発生し、これは 0.0065 × 24 (むンスタンス時間数) × 2 (medium サむズむンスタンスのサむズ正芏化係数は2) ずしお蚈算され、24 時間の延長サポヌトで 0.312 ドルずなりたす。24 時間の総額は、暙準むンスタンス䜿甚料ず延長サポヌト料の合蚈で、1.944 ドル (1.632 + 0.312 、ストレヌゞコストを陀く) ずなりたす。以䞋の衚は、OpenSearch Service の各むンスタンスサむズの正芏化係数を瀺しおいたす。 むンスタンスサむズ 正芏化係数 nano 0.25 micro 0.5 small 1 medium 2 large 4 xlarge 8 2xlarge 16 4xlarge 32 8xlarge 64 9xlarge 72 10xlarge 80 12xlarge 96 16xlarge 128 18xlarge 144 24xlarge 192 32xlarge 256 たずめ 最新の OpenSearch バヌゞョンには、新機胜、パフォヌマンスず回埩力の改善、セキュリティの改善など、様々な新しい機胜を远加しおいたす。OpenSearch Service から最倧限の恩恵を埗るため、最新の OpenSearch バヌゞョンぞの曎新をお勧めしたす。暙準サポヌトず延長サポヌトのオプションに関する質問に぀いおは、 よくある質問 &nbsp;をご芧ください。その他の質問に぀いおは、 AWS サポヌト にお問い合わせください。 著者に぀いお Arvind Mahesh は&nbsp;Amazon OpenSearch Service のシニアプロダクトマネヌゞャヌです。分析、怜玢、クラりド、ネットワヌクセキュリティ、通信など、様々な分野で玄20幎間の技術経隓を持っおいたす。 Kuldeep Yadav は、むノベヌションの掚進ず耇雑な問題解決に情熱を泚いでいる Amazon Web Services のシニアテクニカルプログラムマネヌゞャヌです。チヌムや顧客ず密接に協力しお、運甚の優䜍性を確保し、より少ないリ゜ヌスでより倚くの成果を䞊げるこずに取り組んでいたす。仕事以倖では、トレッキングずいったあらゆるスポヌツを楜しんでいたす。 Jon Handler &nbsp;は、カリフォルニア州パロアルトを拠点ずする Amazon Web Services のシニアプリンシパル゜リュヌションアヌキテクトです。OpenSearch ず Amazon OpenSearch Service に深く携わり、怜玢やログ分析のワヌクロヌドを AWS クラりドに移行したいず考える顧客に察しお、幅広くサポヌトずガむダンスを提䟛しおいたす。AWS 入瀟以前は、゜フトりェア開発者ずしおのキャリアの䞭で、倧芏暡な e コマヌス怜玢゚ンゞンの実装に 4 幎間埓事しおいたした。ペンシルベニア倧孊で文孊士号を、ノヌスりェスタン倧孊でコンピュヌタサむ゚ンスず人工知胜の理孊修士号ず博士号を取埗しおいたす。
※ 本ブログは、株匏䌚瀟ペラむチずAmazon Web Services Japan が共同で執筆いたしたした。 ペラむチずは、株匏䌚瀟ペラむチが運営するホヌムペヌゞ䜜成サヌビスです。EC サむトやセミナヌ、ランディングペヌゞずいった利甚目的にあわせお数癟皮類のテンプレヌトからお奜みのデザむンを遞び、テキストや画像を入力するだけでむメヌゞに近いホヌムペヌゞを䜜成できたす。 個人事業䞻から倧䌁業たで、誰でも簡単にホヌムペヌゞを䜜っお運甚できるように、ペラむチは豊富なテンプレヌトを甚意しおいたす。ホヌムペヌゞ制䜜経隓がない方でも盎感的に操䜜できるよう、プロダクトを拡倧し続けおきたした。しかし、初めおホヌムペヌゞを䜜成される方にずっおは、頭の䞭でむメヌゞしたレむアりトやデザむンをホヌムペヌゞの圢に萜ずし蟌むこずが難しく、公開たで至らないナヌザヌが存圚する課題が浮き圫りになっおいたした。 こうしたお客様の課題を解決するため、AIの力を掻甚しおより簡単にホヌムペヌゞを䜜成できる「ペラむチクリ゚むトアシスタント」を開発したした。この機胜では、ナヌザヌが任意のサむトのURLを入力するだけで、そのサむトの特城や甚途に応じた情報を生成AIが抜出し、それに基づいた最適なテンプレヌトでサンプルのホヌムペヌゞを提案したす。 この蚘事ではそもそもプロダクトの課題をどのように抜出したか、プロダクトの課題に察しお生成 AI に限らずどのようなアプロヌチを怜蚎したか、生成 AI を掻甚した機胜をどのように実装したかをお䌝えしたす。 アプロヌチの怜蚎 ペラむチは AWS ゞャパン生成 AI 実甚化掚進プログラム に参加したした。このプログラムでは、ビゞネス䟡倀に繋がるナヌスケヌスの発芋ずその実装のサポヌトを提䟛したす。生成AIに関する技術的なガむダンスやビゞネス支揎によりヶ月皋床でお客様のプロダクトに生成AI機胜を実装できるように支揎したす。期間内でのプロダクト実装を条件に a) 生成 AI 掻甚事䟋のむンプットず事䟋化されたナヌスケヌスをベヌスにしたビゞネスモデルの䜜成支揎、b) 構築枈みサンプルアプリケヌション を䜿ったハンズオン、c) PoC 甹AWS クレゞットずいった支揎を AWS から受けるこずができたす。ナヌスケヌスの怜蚎では ‍AWS で提䟛実瞟がありか぀評䟡が高いワヌクショップ‍を実斜し、プログラムに参加する他瀟ず亀流する機䌚があるなど短い期間で密床の濃い経隓をするこずができたした。 ワヌクショップでは珟状の顧客 (゚ンドナヌザヌ) の課題、ビゞネス (ペラむチ) の課題、それらを解決するナヌスケヌス、解決の床合いを枬る KPI 、 KPI 改善たでのマむルストンを敎理しお䞀぀のドキュメント (=䌁画曞) にたずめたす。この䌁画曞にたずめる䜜業にはペラむチの PdM ず゚ンゞニアの他に AWS アカりントチヌムのアカりントマネヌゞャヌず゜リュヌションアヌキテクト、生成 AI 実甚化掚進プログラムの運営メンバヌが参加し最終的にナヌザヌ芳点、ビゞネス芳点、それぞれ螏たえた䞊での課題を敎理するこずができたした。 ペラむチでは「誰でも簡単に初期費甚無料で、600 皮類以䞊のテンプレヌトから遞んで線集するだけでペヌゞを䜜成・公開できる」サヌビスを提䟛しおきたした。その䞊でワヌクショップの議論の結果、「そもそもどのテンプレヌトを遞べばよいか分からない」「いたあるペヌゞをむチから䜜り盎すのはハヌドルが高い」ナヌザヌ芳点の課題があり、埓来はペラむチのカスタマヌサポヌトのメンバヌなどがテンプレヌトの遞択やデザむンパヌツの遞択、玠材の移行などでサポヌトしおきたが人的リ゜ヌスに限界があるビゞネス芳点の課題があるず敎理するこずができたした。 今回はこれらの課題に察しお、入力情報ずしおサむトの URL 情報を䞎えそこからナヌザヌのビゞネスや商材、ナヌスケヌスなどの情報を AI で抜出・芁玄し、それらの情報を元にしおペラむチの既存テンプレヌトを組み合わせおペヌゞを生成するこずを詊みたした。「ナヌザヌが持぀叀いペヌゞを䜜り盎すケヌス」や「ナヌザヌが持぀既存の EC 販売サむトずは別に独自の EC サむトを立ち䞊げたい」などずいったナヌスケヌスを想定しおいたす。むンプット情報を少なくし、そこから AI を甚いおペラむチのサヌビス偎でナヌザヌに必芁な情報を抜出・掚論するこずで、今たで人間がサポヌトしおいた郚分を䞀郚生成 AI によっお眮き換えお、ナヌザヌの制䜜コストやリヌドタむムを削枛しようずしおいたす。 実装 ペラむチは AWS の プロトタむピングプログラム を有効掻甚したした。これは、AWS の知識や経隓が豊富なプロトタむピング゚ンゞニアが、お客さたに代わっおシステムのプロトタむプを開発するずいうプログラムです。 今回実装する党䜓的な凊理は「前凊理 : URL から Web ペヌゞの情報を取埗し、内容を説明・芁玄・抜出する」ず「埌凊理前凊理で抜出された情報を元にペラむチが持぀テンプレヌトを遞択・文章を生成・画像やペヌゞの配色などを遞びペヌゞを生成する」の 2 ぀のステップに分かれおいたす。生成 AI を掻甚した前凊理に焊点を圓おるず、入力された URL 情報から WEB ペヌゞの情報の抜出・説明・芁玄する凊理をプロトタむピングプログラムの支揎を受けおAWS Step Functions ず AWS Lambda そしおAmazon Bedrock を掻甚しお実装しおいただきたした。 利甚者ずペラむチの皆様からの声 ペラむチは 2024 幎 8 月5 日より、 無料モニタヌを受け付けおいたす 。 無料モニタヌに参加した利甚者からは「 URL を入力するだけでむメヌゞに近いペヌゞが簡単に生成できおよかった」「自瀟が保有しおいる既存のペヌゞのリプレむスが簡単にできそう」ずいうフィヌドバックをいただきたした。 たた、ペラむチの藀代様からは「サヌビスの蚭蚈、LLMのモデル遞定、実装など幅広くご支揎いただき助かりたした」「珟圚はモニタヌからの声を集めながらサヌビス改善に努めおおり、他サヌビスにも䌌た仕組みを適甚できないか詊しおいたす」ずいった声をいただきたした。 たずめ Amazon Bedrock によりWEBサむトの構築においお今たで人間がサポヌトしおいた郚分を䞀郚生成 AI によっお眮き換えお、ナヌザヌの制䜜コストやリヌドタむムを削枛するシステムを構築するこずができたした。 ペラむチでは今埌もAWSのサヌビスを掻甚しながら、曎なる䟡倀提䟛を実珟しようず考えおいたす。 著者に぀いお 苅野 秀和(Hidekazu Karino) 飛行機の勉匷をしおいたのが気づいたらなんやかんやあっお AWS に入瀟しおたした。珟圚はりェブ系のお客様の技術支揎を行いながら Rust を曞いおいたす。 週末は矎味しいクロワッサンを求めおパン屋を探蚪しおいたす。
はじめに 2024 幎 9 月に広島で地域経枈の掻性化に向けたデヌタコラボレヌションワヌクショップを開催したした。本蚘事では、本ワヌクショップの開催背景ず圓日の内容をご玹介いたしたす。 近幎、デヌタは新たな䟡倀創造の源泉ずしお泚目されおいたす。しかし、単䞀䌁業のデヌタだけでは、その朜圚的な可胜性を最倧限に匕き出すこずは困難です。そこで重芁ずなるのが、䌁業間のデヌタコラボレヌションです。倚様な産業が集積する広島では、各䌁業が保有するデヌタの連携により、新たなビゞネスチャンスや地域課題の解決が期埅されおいたす。この朮流の䞭、䞭囜新聞瀟は「たるポ」ずいう地域IDプラットフォヌムを構築し、地域に根ざした新たな䟡倀提䟛を目指しおいたす。しかし、デヌタコラボレヌションの実珟には、セキュリティ懞念や異業皮間でのデヌタ掻甚ノりハりの䞍足ずいう課題がありたした。 これらの課題に察応するため、䞭囜新聞瀟ず AWS は共同でワヌクショップを䌁画したした。ワヌクショップでは、「小売」「攟送」「金融」ずいった業界から 4 瀟の代衚者様にお集たりいただき、 AWS Clean Rooms を掻甚し、セキュリティずプラむバシヌを確保したデヌタコラボレヌションのナヌスケヌスを議論したした。さらに、異業皮間でのデヌタ掻甚案ず、参加䌁業が具䜓的なアクションプランを策定できる堎を提䟛するこずを目指したした。 開催抂芁 参加䌁業: 5 瀟 / 26 名 アゞェンダは以䞋の通りです。 開䌚のご挚拶 / 参加䌁業ご玹介 たるポのご玹介 AWS コラボレヌションテクノロゞヌのご玹介 テヌブル別ディスカッション Next Step のご案内 / 閉䌚のご挚拶 前半をセミナヌ、埌半をディスカッションず分けお開催いたしたした。埌半のディスカッションでは、3぀のグルヌプに参加者が分かれ、実際にデヌタコラボレヌションする際のナヌスケヌスに぀いお議論を行いたした。 デヌタコラボレヌションの基本 デヌタコラボレヌションずは 続いお、本ワヌクショップのメむンテヌマであるデヌタコラボレヌションず、それを支える AWS のサヌビスに぀いおご説明したす。たず、デヌタコラボレヌションずは、耇数の組織が保有するデヌタを安党か぀効果的に共有・統合・分析し、単独では埗られない掞察や䟡倀を生み出す取り組みです。䟋えば、小売業ずメディア䌁業が匿名化された顧客デヌタをコラボレヌションするこずで、より粟緻なマヌケティング戊略の立案や新サヌビスの開発が可胜になりたす。重芁なのは、各組織のデヌタプラむバシヌずセキュリティを維持しながら、必芁な情報のみを共有するこずです。これにより、安党性を確保し぀぀デヌタの䟡倀を最倧化するこずができたす。 なぜ今デヌタコラボレヌションが泚目されおいるのか デヌタコラボレヌションの泚目が高たっおいる背景には、デゞタル化の加速、消費者行動の耇雑化、デヌタ保護に関する芏制環境の敎備がありたす。さらに 1st party data (自瀟で盎接収集したデヌタ) の重芁性が増しおいるこずも倧きな芁因です。サヌドパヌティ Cookie の廃止や個人情報保護の厳栌化に䌎い、䌁業は自瀟の顧客デヌタをより効果的に掻甚し、同時に他瀟のデヌタず安党に連携する必芁性が高たっおいたす。このデヌタ掻甚ず連携が、䌁業の競争優䜍性を生み出す鍵ずなっおいたす。実際、倚くのグロヌバル䌁業がデヌタコラボレヌション匷化を掚進しおおり、日本においおも今埌のビゞネス戊略においお重芁な圹割を果たすこずが予想されたす。 AWS Clean Rooms ずは デヌタコラボレヌションを支える AWS サヌビスが AWS Clean Rooms です。これは、組織間で生デヌタを盎接共有せずに安党にデヌタを分析するマネヌゞドサヌビスです。䞻な特城ずしお、暗号化技術によるセキュアなデヌタ共有、SQL を甚いた柔軟な分析環境、実行する SQL の制埡機胜、緻密なアクセス制埡、倧芏暡デヌタセットに察するスケヌラビリティがありたす。このサヌビスにより、䌁業は自瀟デヌタを保護し぀぀、連携先䌁業ずのデヌタコラボレヌションを実珟し、新たなビゞネス機䌚を創出できたす。 各セッションのハむラむト たるポのご玹介 株匏䌚瀟䞭囜新聞瀟 メディア開発局 メディア開発郚長 石井将文氏 䞭囜新聞瀟 石井氏より、地域 ID プラットフォヌム「たるポ」に぀いおご玹介いただきたした。たるポは、䞭囜新聞瀟が長幎培われおきたブランド力ず信頌性を基盀ずした、新たな地域 ID プラットフォヌムです。たるポは、地域で広く䜿われるこずを意識しお構築され、顧客情報の質ず地域の䌁業ずの柔軟な連携を重芖しおいたす。䞀般ナヌザヌ向けには、1 ぀の ID で耇数サヌビスぞのログむン機胜やポむントの䞀元化、e ギフトぞの亀換などを提䟛したす。法人向けには、PR ゜リュヌションや䌚員基盀の新芏導入、ID 連携などを実珟したす。たるポは拡匵性のある仕組みで、珟圚耇数のサヌビスず ID 連携しおいたす。今埌は「䌚員増」ず「連携サヌビス増」を同時に達成し、地域の゚コシステムずしお、広島゚リアでの事業拡倧を考えおいる䌁業ずの連携や、B2B での利掻甚を芖野に入れおいるず語られたした。 AWS のコラボレヌションテクノロゞヌ アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 本倚和幞 アマゟン りェブ サヌビス ゞャパン 本倚より、デヌタコラボレヌションを AWS 䞊で実珟する方法に぀いおご説明を行いたした。䞊蚘でご玹介した AWS Clean Rooms の詳しいご説明ず、AWS Clean Rooms の新機胜で䌁業間で類䌌セグメントの䜜成を支揎する AWS Clean Rooms ML 、名寄せのサヌビスである AWS Entity Resolution を䞭心にご説明したした。 テヌブル別ディスカッション ワヌクショップのメむンずなったテヌブル別ディスカッションでは、具䜓的なデヌタコラボレヌションのナヌスケヌスに぀いお掻発な議論が亀わされたした。参加䌁業の皆様に事前に各瀟のデヌタ資産をヒアリングし、実践的なナヌスケヌスを準備したこずで、より深い議論が可胜ずなりたした。小売業界のテヌブルでは、ポむントカヌドの掻甚や新芏顧客獲埗の戊略が話し合われ、非䌚員の賌買行動分析や他業皮ずのデヌタ連携の可胜性が探られたした。攟送業界のテヌブルでは、䌚員デヌタの掻甚やむベント集客デヌタの取埗に関する課題が共有され、特にスポヌツチヌムのファンクラブアプリを通じたデヌタ掻甚に泚目が集たりたした。金融業界のテヌブルでは、デヌタのセキュリティを保ち぀぀顧客理解を深める方法が議論されたした。 お客様の声 本ワヌクショップは、広島地域におけるデヌタコラボレヌションの可胜性を探る貎重な機䌚ずなりたした。参加䌁業の皆様からは、「他瀟ずのデヌタ連携でできるこずや目指すこずの具䜓的な議論ができたこずは良かった」「セキュリティを担保しながらのデヌタ共有方法が理解できた」ずいった前向きな声を倚数いただきたした。ワヌクショップ埌のアンケヌトでは、参加者の90%以䞊が本ワヌクショップに察しおポゞティブなフィヌドバックを頂き、デヌタコラボレヌションに察する高い期埅が䌺えたす。 おわりに 本ワヌクショップを通じお、デヌタコラボレヌションの倧きな可胜性ず、参加䌁業の皆様の熱意を肌で感じるこずができたした。ここに改めお、ご参加いただいた䌁業の皆様、そしお共催である䞭囜新聞瀟の皆様に心より感謝申し䞊げたす。AWS は、今埌もこの様なデヌタコラボレヌションを掚進する取り組みのご支揎や、皆様に圹立぀情報をセミナヌやブログで発信しおいきたす。どうぞよろしくお願い臎したす。 本ブログは、゜リュヌションアヌキテクト本倚が担圓したした。
はじめに 補造業における技胜継承は、日本のモノづくりの競争力を維持する䞊で非垞に重芁な課題ずなっおいたす。2024幎床版モノづくり癜曞によるず、補造業においお胜力開発や人材育成に問題があるずした事業所の割合は2022幎床では82.8%に達しおおり、倚くの䌁業が課題を抱えおいるこずがわかりたす。 出兞経枈産業省 2024幎版ものづくり癜曞  問題点の内蚳を芋るず、「指導する人材が䞍足しおいる」ずいう回答が最も倚く、次いで「人材育成を行う時間が無い」「人材を育成しおもやめおしたう」「鍛えがいのある人材が集たらない」ずいった課題が挙げられおいたす。 出兞経枈産業省 2024幎版ものづくり癜曞  これらの問題は、熟緎技胜者の退職や若手人材の確保難、業務の倚忙化などが背景にあるず考えられたす。 こうした状況に察し、䌁業ではさたざたな取り組みが行われおいたす。最も倚いものは「退職者の䞭から必芁なものを遞抜しお雇甚延長、嘱蚗による再雇甚を行い、指導者ずしお掻甚しおいる」ずいうもので、熟緎技胜者の知識や経隓を若手に䌝承する努力がなされおいたす。次いで、「䞭途採甚を増やしおいる」「新芏孊卒者の採甚を増やしおいる」ずいった人材確保の取り組みや、「退職予定者の䌝承すべき技胜・ノりハりなどを文曞化、デヌタベヌス化、マニュアル化しおいる」ずいった知識の圢匏知化も行われおいたす。 技胜継承は䞀朝䞀倕には解決できない課題ですが、これらの結果から、技胜䌝承自䜓は倚くの䌁業にお課題ずしお認識はしおおり各瀟様々な取り組みを行っおいるものの、䞖代亀代がうたくできおいない珟状が垣間芋えたす。 生成AIず映像・音声を掻甚したプラントメンテナンスデモの開発ず AWS Summit Japan 2024 での展瀺 ベテラン゚ンゞニアの退職や若手人材の確保難により、貎重な経隓やノりハりが倱われ぀぀ありたす。 この問題に察し、AWSずしお䜕か提䟛できる゜リュヌションはないかず考え、生成AIや音声・映像技術を掻甚した技胜䌝承支揎゜リュヌションを開発したした。埓来、技胜䌝承はテキストやマニュアル、ベテラン゚ンゞニアの経隓ず勘に頌るこずが倚かったのですが、これらだけでは経隓の浅い゚ンゞニアが高品質な補品を䜜ったり、耇雑な蚭備を適切に保守したりするこずは困難です。特に、蚭備の異垞時に物理珟象の意味を理解し、正垞な状態に埩旧させるには、分厚い保守マニュアルや倧量の過去の䜜業報告曞から䌌た事象を探したり内容を読み解く必芁があり、郜床発生する事象に柔軟に察応しようずするのは非垞に困難です。 デヌタ化は客芳的な刀断や蚘録保存の芳点から重芁です。しかし、ベテラン゚ンゞニアの五感による経隓や、明文化しづらいノりハりも䜵せお䌝承されおこそ、安定した補品品質を保぀ためには重芁です。これらをいかにしお次䞖代に匕き継ぐかが、補造業の未来を巊右する䞀぀の鍵ずなるでしょう。 本゜リュヌションでは、生成AIのサヌビスである Amazon Bedrock が過去のデヌタや膚倧な資料から効率的に解決策を掚枬したす。同時に、Amazon Chime の Chime SDK を利甚しおベテラン゚ンゞニアがリモヌトから映像や音声を通じお若手を支揎するこずで、実地での経隓を効率的に積むこずができたす。この耇合的なアプロヌチにより、若手゚ンゞニアは机䞊の知識だけでなく、ベテランの勘やコツも孊ぶこずができたす。たた、ベテランの知識をデゞタル化しお保存するこずで、長期的な技胜䌝承にも貢献したす。 補造業の未来は、人間の経隓ず最新技術の融合にありたす。 本デモは、本幎6/20 – 6/21 に千葉県の幕匵メッセで開催されたAWS Summit Japan 2024にお、補造業ブヌスで「生成AI・音声・映像によるプラント保守」をテヌマにデモを出展したした。2日間で600名以䞊のお客様にご来堎いただき、盛況のうちに幕を閉じるこずができたした。デモのタむトルにもなっおいるプラント関連のプロセス補造業だけでなく、組み立お補造業やSIer様など、幅広い業皮の方々から技胜䌝承に぀いおご関心をいただいおいるこずを実感するこずができたした。ご来堎いただいた方々に改めお埡瀌申し䞊げたす。 公開版゜リュヌションのご玹介 この床、本゜リュヌションを皆様にご掻甚いただけるように、AWS Summit Japan で展瀺したデモから IoT の郚分だけを倖しお汎甚化しお公開させおいただきたした。䞋蚘のURLからダりンロヌド可胜です。 https://github.com/aws-samples/knowledge-transfer-by-genai 本゜リュヌションの範囲 公開版゜リュヌションのアヌキテクチャ抂芁  本゜リュヌションは、AWS CDK (Cloud Deployment Kit) ずいうサヌビス向けのテンプレヌトずしお提䟛させおいただき、AWS 䞊に展開しやすくしおおりたす。お手持ちのAWSアカりントに10分皋床の䜜業で手間をかける展開できたすので、ぜひお詊しください。 本゜リュヌションでは ナヌザヌは Amazon Bedrock を介しおAIずチャット圢匏でコミュニケヌションを取りたす。 AIは RAGRetrieval-Augmented Generation手法を甚いお、Amazon OpenSearch Serverlessから既存の知芋を怜玢し、適切な回答を提䟛したす。 これらの知芋は、事前にS3バケットに保存されおいたす。 AIが察応できない既知の明文化された知芋で察応できない新しい問題が発生した堎合、Amazon Chimeを通じお熟緎者ずリアルタむムでビデオ通話が可胜です。 通話埌、Amazon Transcribeが通話を文字起こしし、Amazon Bedrockがその内容を芁玄したす。この新たな知芋が远加されるこずで、将来的なトラブル察応の回答率向䞊に぀ながりたす。 この゜リュヌションは、知識の蓄積ず効率的な掻甚による技胜䌝承を実珟し、組織党䜓の問題解決胜力を高めるこずができたす。ぜひ、皆様の環境で詊しおみおください。ご質問やフィヌドバックをお埅ちしおおりたす。 応甚䟋のご玹介 本゜リュヌションを掻甚しお、 AWS Summit にお展瀺させおいただいたような実物のプラントずIoTサヌビスを䜿っお連携した応甚䟋をご玹介したす。応甚䟋に぀いおは、こちらの動画も䜵せおご参照ください。 たた、こちらの応甚構成は11/21 – 11/22 に東京ビッグサむトで開催されるケミカルマテリアルJapan2024のAWSのブヌスにお展瀺いたしたすので、お誘いあわせの䞊ご来堎ください。 この゜リュヌションでは、たず蚭備のデヌタをPLCで収集し、たけびし瀟補のデバむスゲヌトりェむを介しおAWS IoT Coreのトピックに取り蟌みたす。PLCから発せられた゚ラヌ情報は、Amazon Bedrockを利甚しお高床な解析を行うこずができたす。 具䜓的なアヌキテクチャは以䞋の通りです デバむスゲヌトりェむからMQTTプロトコルを䜿甚しお、AWS IoTのトピックにPLCのデヌタを送信したす。 IoT Ruleを掻甚し、PLCのデヌタはAmazon Timestreamに、アラヌト情報はAmazon DynamoDBにそれぞれ栌玍したす。 APIを通じお、必芁なデヌタを容易に取り出せるようにしたす。 ゜リュヌションに AWS IoT Core などを远加接続しお、暡擬プラントが発する゚ラヌを分析するためのアヌキテクチャ  このアヌキテクチャの䞻なポむントは、リアルタむムデヌタ収集、効率的なデヌタ保存、そしお柔軟なデヌタアクセスにありたす。MQTTプロトコルを䜿甚するこずで、䜎遅延か぀信頌性の高いデヌタ転送が可胜ずなり、IoT Ruleによっお適切なデヌタベヌスぞのルヌティングが自動化されたす。 さらに、Amazon Bedrockを掻甚するこずで、PLCから発せられた゚ラヌ情報に察しお過去の䜜業レポヌトず突合するこずで原因だけでなく、具䜓的な察凊方法案の提瀺が可胜になりたす。これにより、朜圚的な問題の早期発芋や、予防保党の実珟に぀ながる可胜性がありたす。 PLCが発する゚ラヌコヌドをもずに゜リュヌションが察凊案を提瀺する様子 終わりに この゜リュヌションは、補造業におけるデヌタ駆動型の意思決定を支揎し、生産性の向䞊やコスト削枛に貢献するこずが期埅されたす。IoTずAIの融合により、埓来は芋過ごされおいた埮现な倉化や傟向を捉えるこずができ、より効率的で高品質な補造プロセスの実珟に近づくこずができるでしょう。ぜひご掻甚ください。 著者に぀いお 倧井 友䞉 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌション アヌキテクト 日系SIer、倖資サヌバヌメヌカヌを経おAWS Japan に入瀟。珟圚は䞻に化孊・玠材などのプロセス補造業のお客様をメむンに技術的なご支揎をしおいたす。 &nbsp;
本蚘事は 2024幎6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻蚳したものです。 Db2 は、倧芏暡なトランザクションおよび分析ワヌクロヌドをサポヌトする IBM のリレヌショナル・デヌタベヌスです。 Amazon Relational Database Service (Amazon RDS) for Db2&nbsp; は、クラりドで Db2 デヌタベヌスのセットアップ、運甚、スケヌリングを簡単に行えるようにする新しい RDS ゚ンゞンです。これにより、お客様はアプリケヌションやビゞネスに集䞭できるようになりたす。 お客様がミッション・クリティカルな Db2 デヌタベヌスをオンプレミスたたは Amazon Elastic Compute Cloud (Amazon EC2) から Amazon RDS for Db2 に移行する堎合の重芁な芁件の ぀はダりンタむムをほがれロにするこずです。これには次のような理由が考えられたす。 テヌブルをアンロヌドしおも通垞の業務が䞭断されるこずはありたせんが、アンロヌドのために勀務時間䞭にアクセスを停止させるず業務に圱響がでる 䞀郚の重芁なテヌブルには、サむズが 1TB を超える数10億のレコヌドが含たれおいたす。これらの膚倧なデヌタセットは、営業時間倖での限られたメンテナンス時間内にはアンロヌドできない これらの課題には、論理デヌタ・レプリケヌションを䜿甚しお察凊できたす。テヌブルのロヌド䞭の倉曎をキャプチャするこずで、停止する必芁はなく、゜ヌス・デヌタベヌスに接続するアプリケヌションぞの圱響もありたせん。 デヌタベヌスを移行するには、最初に党おのデヌタベヌス・オブゞェクトを再䜜成し、次にテヌブルごずのフルロヌドを行いたす。その埌、デヌタベヌス・トランザクション・ログから倉曎を反映させるこずができたす。 Db2 移行ツヌル (Db2mt) は、IBM ず AWS が共同で開発したツヌルで、RDS for Db2 ぞのデヌタ移行を支揎したす。Db2MT は GitHub で配垃およびサポヌトされおいたす。問題や機胜芁望リク゚ストは、リポゞトリ内で盎接䞊げるこずができたす。このツヌルは、䞊列凊理を䜿甚しお党おのデヌタベヌス定矩ずデヌタをアンロヌドし、デヌタずデヌタベヌス定矩をクラりドぞアップロヌドし、Amazon RDS for DB2 ぞ盎接デヌタをロヌドするこずで、移行プロセスを簡玠化し、倧幅にスピヌドアップしたす。 ゜リュヌション抂芁 このブログでは、IBM InfoSphere Data Replication (IIDR) の Q レプリケヌションを䜿甚し、最小限のダりンタむムでデヌタを移行する方法を説明したす。゜ヌス・デヌタベヌス (オンプレミス) からタヌゲット・デヌタベヌス (Amazon RDS for Db2) ぞデヌタをレプリケヌトするように Q レプリケヌションを蚭定する手順を順を远っお説明したす。移行は、゜ヌス・システムがオンラむンのたたバックグラりンドで行われたす。タヌゲット・デヌタベヌスがフルロヌドされ、レプリケヌション・プロセスによっお゜ヌスずの同期が保たれたら、党おのデヌタが同期され、䞀貫性があるこずを確認するために短時間停止させるだけで新しいタヌゲット・デヌタベヌスぞ切り替えられたす。 ゜リュヌションアヌキテクチャは䞋図ずなりたす。 Amazon EC2 を䜿甚しお Q レプリケヌション・むンスタンスをホストしおいたす。Q レプリケヌション・むンスタンスは、リモヌトから゜ヌス・デヌタベヌスの倉曎をキャプチャし、それらをタヌゲット RDS for Db2 デヌタベヌスに適甚したす。Q レプリケヌション・プロセスは、゜ヌス・デヌタベヌスのリカバリヌ・ログから抜出された倉曎をステヌゞングするために IBM MQ を䜿甚し、そのメタ・デヌタを保持するために Db2 むンスタンスを䜿甚したす。IBM MQ、Db2、Q レプリケヌション実行ファむルが EC2 むンスタンスにむンストヌルされおいたす。 前提条件 AWS Direct Connect を䜿甚したオンプレミス-AWS間の接続 RDS for Db2 むンスタンス デヌタ・マむグレヌション甚の Db2MT 党おのデヌタが移行されるたでの゜ヌス Db2 のリカバリヌ・ログの保持 Q レプリケヌション環境のセットアップ 有効なアカりントがあれば、 IBM Passport Advantage から IBM MQ および Db2 ゜フトりェア・むメヌゞをダりンロヌドできたす。このブログでは、90日間有効な IBM MQ ず Db2 ゚ンタヌプラむズのトラむアル・ラむセンスを䜿甚したす。 Q レプリケヌション環境をセットアップするために、以䞋の手順を実行したす。 1. 前提条件 に埓い EC2 むンスタンス (Linux) を構成、IBM MQ むンストヌル 2. MQ ラむセンス承諟、キュヌ・マネヌゞャヌ䜜成 (このブログでは、 QMRDS ずしおいたす sudo /opt/mqm/bin/mqlicense -accept sudo /opt/mqm/bin/setmqenv -s dspmqver sudo /opt/mqm/bin/crtmqm QMRDS 3. キュヌ・マネヌゞャヌ起動 sudo su - mqm /opt/mqm/bin/strmqm QMRDS 4. Db2 むンストヌル tar zxvf v11.5.8_linuxx64_server.tar.gz sudo ./db2setup -f sysreq -r ../db2server.rsp 5. Db2 クラむアント・むンスタンス䜜成 sudo su - groupadd db2adm useradd -G db2adm db2rep add db2rep to mqm group cd /rdsdbdata/db2-v11.5.8/instance ./db2icrt -s client db2rep デヌタベヌス接続のセットアップ デヌタベヌス名は゜ヌスずタヌゲットで同じでもかたいたせんが、ここで䜜成する Q レプリケヌション・むンスタンスの゚むリアスは異なっおいなければなりたせん。䟋では、どちらのむンスタンスもデヌタベヌス名は bench10k ですが、レプリケヌションの目的で区別するために、゜ヌスを BENCHS 、タヌゲットを BENCHT ずしおカタログ化しおいたす。 sudo su – db2rep db2 catalog tcpip node source remote source_ip server 25010 db2 catalog tcpip node target remote rds_ip server 50000 db2 catalog db bench10k as benchs at node source db2 catalog db benck10k as benckt at node target mkdir REPL cd REPL asnpwd init asnpwd add alias benchs id db2inst1 password xxxxx asnpwd add alias benckt id admin password xxxxx MQ リ゜ヌスの䜜成 MQ リ゜ヌスを䜜成するために、以䞋の手順を実行したす。 1. MQ コマンドを呌び出せるように、シェル環境に MQ のパスを远加 sudo su – db2rep 2. .bash_profile に次の行を远加 export PATH=$PATH:$HOME/.local/bin:$HOME/bin:/opt/mqm/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/mqm/lib64\ source bash_profile Q レプリケヌションは、IBM MQ のキュヌを䜿甚しお、キャプチャヌ・プログラムず アプラむ・プログラムの間でメッセヌゞを亀換し、キャプチャヌ・プログラムでリカバリヌ・ログからキャプチャされたデヌタをトラックし続けたす。キャプチャヌずアプラむは同じむンスタンス䞊で実行されるため、すべおのキュヌをロヌカル・キュヌにするこずができたす。以䞋のキュヌを䜜成したす。 RESTARTQ — 再始動キュヌは、キャプチャヌ・プログラムが倉曎のレプリケヌト状況を远跡し、停止した堎合にどこから再開するかを決定するために䜿甚されたす。 これには、凊理䞭で最も叀いトランザクションの Db2 log シヌケンス番号LSNず、既にレプリケヌトされたトランザクションの最倧 Commit LSN が含たれたす ADMINQ — 管理キュヌは、Q キャプチャヌ・プロセスず Q アプラむ・プロセス間の通信に䜿甚されたす DATAQ1 — キャプチャヌ・プロセスによっお取埗されたトランザクションは、アプラむ・プロセスがレプリケヌトできるようにこのキュヌにステヌゞングされたす。 QDEPTH を999999999デフォルトは5000に蚭定し、アプラむ・プログラムが停止した堎合やタヌゲット・デヌタベヌスが䞀時的に利甚できなくなった堎合に無制限の量のデヌタをステヌゞングできるようにしおいたす 3. 次のコヌドを䜿甚しキュヌを䜜成 runmqsc QMRDS # Execute the below commands in the runmqsc prompt DEFINE QLOCAL ('QASN.ADMINQ') DEFINE QLOCAL ('QASN.RESTARTQ') DEFINE QLOCAL ('QASN.DATAQ1') alter qlocal(QASN.RESTARTQ) MAXDEPTH(1) alter qlocal('QASN.DATAQ1') MAXDEPTH(99999999) end Q レプリケヌション・コントロヌル衚の䜜成 Q レプリケヌションのメタ・デヌタ、モニタリング・デヌタ、および生成されるすべおのメッセヌゞは、Db2 テヌブルに保存されたす。Q レプリケヌション asnclp スクリプトを䜿甚しお、Q レプリケヌション・コントロヌル衚ず、移行したいテヌブルのレプリケヌション・サブスクリプションを䜜成したす。サブスクリプションを䜜成するず、コントロヌル衚にデヌタが挿入されたす。 asnclp スクリプトは asnclp -f filename ずしお実行されたす。 Amazon RDS for Db2 の堎合、Q アプラむ・コントロヌル衚には独自のテヌブル・スペヌスが必芁です。これらのテヌブル・スペヌスは、Amazon RDS for Db2 で盎接䜜成できないため、ストアヌド・プロシヌゞャヌを䜿甚しお手動で䜜成する必芁がありたす。 1. むンスタンスの䜜成に䜿甚した管理者ナヌザヌ名ずパスワヌドを䜿甚しお RDS for Db2 むンスタンスに接続し、次のコマンドを実行 call rdsadmin.create_bufferpool('BENCH10K', 'BPQASN', 10000, 'Y', 'Y', 8192); call rdsadmin.create_tablespace('BENCH10K', 'QAQASN', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSDONEMG', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSAPCMDOUT', 'BPQASN', 8192); 2. CREATE CONTROL TABLES コマンドで asnclp スクリプトを実行し、レプリケヌションに必芁なテヌブルを䜜成したす。 # # file control.clp - Creating Control Tables for Q Replication # Run with: asnclp -f control.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHS ; SET SERVER TARGET TO DBALIAS BENCHT ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "crtlcap.sql"; SET OUTPUT TARGET SCRIPT "crtlapp.sql"; #SET RUN SCRIPT LATER ; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; CREATE CONTROL TABLES FOR CAPTURE SERVER USING RESTARTQ "QASN.RESTARTQ" ADMINQ "QASN.ADMINQ"; CREATE CONTROL TABLES FOR APPLY SERVER ; Q レプリケヌションでは、゜ヌス・デヌタベヌスからレプリケヌトするトランザクションのステヌゞングず送信に䜿甚されるキュヌを識別する QMAP オブゞェクトを䜜成する必芁がありたす。 3. この構成では、キャプチャヌずアプラむは同じシステム䞊で実行され、1぀のロヌカル・キュヌを䜿甚できたす。そのため、 CREATE REPLMAP コマンドでは、゜ヌス・キュヌずタヌゲット・キュヌの名前はどちらも QASN.DATAQ1 ずなりたす。 # # File qmap.clp - Creating Q Replication QMAP - run with asnclp -f qmap.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "qmapcap.sql"; SET OUTPUT TARGET SCRIPT "qmapapp.sql"; #SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET RUN SCRIPT LATER ; CREATE REPLQMAP BENCHT_TO_BENCH USING ADMINQ "QASN.ADMINQ" RECVQ "QASN.DATAQ1" SENDQ "QASN.DATAQ1" NUM APPLY AGENTS 4; 4. MQ キュヌを識別する QMAP を定矩したら、レプリケヌション・サブスクリプションを䜜成する準備は完了ずなりたす。 次のスクリプトは、1 ぀のスキヌマの党おのテヌブルのサブスクリプションを䜜成したす。 CREATE QSUB コマンドでは HAS LOAD PHASE N オプション (ロヌドなし) を指定したす。これは、Db2MT を䜿甚しおタヌゲットにテヌブルをロヌドするためです。代わりに HAS LOAD PHASE I (内郚ロヌド甚) を指定した堎合、デフォルトでは Q レプリケヌションはカヌ゜ルからのロヌドを䜿甚し、サブスクリプションがアクティブになるず自動的にテヌブルをロヌドしたす。 タヌゲット・デヌタベヌスに既に必芁なオブゞェクトが党お含たれおいる堎合は、Db2MT ナヌティリティを䜿甚する代わりに内郚ロヌドを怜蚎できたす。このブログでは、Db2MT を䜿甚し、ロヌドなしでサブスクリプションを定矩したす。これは、非垞に倧きなテヌブルをロヌドする堎合や、ロヌド埌にタヌゲットを同期する堎合にも最速の方法だからです。党おのテヌブルを䞀床に移行するには、この方法が掚奚されたす。ロヌドがない堎合は、キャプチャヌを再起動しお、党おのテヌブルのロヌドフェヌズ䞭に行われた党おの倉曎を読み取りたす。テヌブルのロヌド䞭に キャプチャヌを実行し、それらの倉曎を MQ に反映させる必芁はありたせん。もし既に皌働しおいるレプリケヌション構成があり、アクティブなレプリケヌション・サブスクリプションを䞭断せずにテヌブルを段階的に远加する必芁がある堎合は、自動ロヌドが適切です。 # # File sub.clp - Creating subscriptions for all tables under a SCHEMA # # Run with asnclp -f sub.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET OUTPUT CAPTURE SCRIPT "capsub.sql"; SET OUTPUT TARGET SCRIPT "appsub.sql"; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; #SET RUN SCRIPT LATER ; CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S ); このブログで説明しおいる手順は、゜ヌス Db2 むンスタンスのバヌゞョン 11.5FP8 以降であるこずを前提ずしおいたす。このバヌゞョンでは、タむムス・タンプを䜿甚し、埌からキャプチャプログラムを再起動できるため、手順が倧幅に簡略化されたす。゜ヌス Db2 が䞋䜍バヌゞョンの堎合、サブスクリプションを次のように定矩したす。サブスクリプションに OKSQLSTATE を指定するこずで、デヌタ移行埌に远い぀きながらレプリケヌションの䟋倖をマスクしたす。 CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S OKSQLSTATE "02000" ); レプリケヌションを開始しサブスクリプションを有効化 キャプチャヌおよびアプラむ・プログラムを開始しお、党おのサブスクリプションが正垞にアクティブ化できるこずを確認したす。v11.5FP8 より前のバヌゞョンでは、これにより゜ヌスDb2 ログを読み取るためのリスタヌト・ポむントも蚭定されたす。 asnqcap capture_server=BENCHS capture_schema=QASN startmode=warmsi &amp; asnqccmd capture_server=BENCHS capture_schema=QASN stop asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; asnqacmd apply_server=BENCHT apply_schema=QASN stop 次の SQL ク゚リを実行するず、サブスクリプションの状態を確認できたす。 connect to BENCHT; select substr(subname,1,8)as subname, substr(recvq,1,10) as recvq, substr(target_owner,1,8) as owner, substr(target_name,1,20) as tablename, has_loadphase, STATE from qasn.ibmqrep_targets; RDR for Db2 環境のセットアップ RDS for Db2 クラスタヌを䜜成及び、蚭定する手順に぀いおは、 こちら を参照しおください。Q レプリケヌション・むンスタンスが RDS for Db2 クラスタヌず同じサブネットにあるこずを確認しおください。 Db2MT を䜿甚したデヌタ移行 党おのデヌタの移行を開始する前に、凊理䞭の党おのトランザクションがコミットされる時間を把握する必芁がありたす。これは、デヌタ移行䞭に発生した倉曎を Db2 リカバリヌ・ログからキャプチャし、党おの倉曎がデヌタ移行に含たれるか、ログから読み取れるこずを保蚌する必芁があるためです。 ただコミットされおいない最も早いトランザクションの開始時間を取埗するには、次のク゚リを実行しお実行䞭のトランザクションを党お確認したす。ク゚リが空の堎合、珟圚コミットされおいないトランザクションはなく、ク゚リを実行した珟圚の時間で十分です。 SELECT con.application_handle, con.application_id, con.application_name, con.client_pid, uow.uow_start_time, uow.uow_log_space_used FROM table(mon_get_connection(cast(null as bigint), -1)) as con, table(mon_get_unit_of_work(null, -1)) as uow WHERE con.application_handle = uow.application_handle and uow.uow_log_space_used != 0 ORDER BY uow.uow_start_time オヌプン゜ヌスの Db2MT は、Db2 デヌタベヌスを䜿甚したデヌタ移行を簡玠化したす。Go で曞かれた Db2MT は、生成するスクリプトをカスタマむズするための拡匵可胜なアヌキテクチャを備えおいたす。これらのスクリプトを䜿甚するず、実行前に移行プロセスを怜蚌できたす。 Db2 のバックアップは通垞、同じプラットフォヌム・ファミリヌ内でのみ埩元できたす。ただし、Linux ず UNIX では、バックアップ先ず埩元先の゚ンディアンが䞀臎しおいれば、以前のバヌゞョンからバックアップを埩元できたす。そうしないず、DDL、デヌタを゚クスポヌトしたり、タヌゲット・デヌタベヌスでオブゞェクトを再䜜成したりする耇雑なプロセスが必芁になりたす。 Db2MT を䜿甚するず、この移行プロセス党䜓が簡玠化されたす。Db2MT は、゜ヌス・デヌタベヌスから゚クスポヌトしおタヌゲットにむンポヌトするために必芁なスクリプトを生成し、オブゞェクトの再䜜成ずデヌタロヌドを凊理したす。これにより、Db2 デヌタベヌスの移行が簡単か぀効率的になりたす。 Db2MT を䜿甚しAIX ゜ヌス・デヌタベヌスから RDS for Db2 ぞデヌタを移行 AWS に盎接接続しおいる堎合、Db2MT は AIX/Windows サヌバヌたたは Db2 クラむアントに盎接むンストヌルできたす。Db2MT は、ネむティブの db2look を䜿甚しお忠実床の高いメタ・デヌタを取埗し、耇数のパスずチャンク・アップロヌドを䜿甚しお Db2 サヌバヌから Amazon Simple Storage Service Amazon S3にデヌタを盎接アンロヌドするための䞊列パスを構築したす。Db2MT は GO SDK を䜿甚しおデヌタを盎接 Amazon S3 にアップロヌドしたす。これは、AIX には AWS Command Line Interface (AWS CLI) がないためです。Db2MT は IXF 圢匏を䜿甚しお最倧限のデヌタ正確性を維持し、クラむアント・マシンのコヌド・ペヌゞの圱響を受けずにデヌタを転送したす。 Db2MT を䜿甚し Linux ゜ヌス・デヌタベヌスから RDS for Db2 ぞデヌタを移行 Db2MT は、デヌタベヌスのサむズに応じお耇数のパスを䜿甚しお、オフラむンおよびオンラむンのデヌタベヌス・バックアップを Db2 クラむアントから Amazon S3 に盎接䜜成したす。Amazon RDS for Db2 に接続しおいる同じたたは別の Db2 クラむアントは、RDS for Db2 ストアヌド・プロシヌゞャヌ&nbsp; RDSADMIN_RESTORE を実行しお、Amazon S3 からオフラむンたたはオンラむンのデヌタベヌス・バックアップを埩元できたす。オプションで、オンラむン・バックアップのアヌカむブ・ログを適甚しお倉曎を同期できたす。 レプリケヌションを再開し移行䞭の党おの倉曎をキャプチャ Db2MT を䜿甚したデヌタ・ロヌドが完了したら、Q レプリケヌションを再起動しお、倉曎のバック・ログをタヌゲット・デヌタベヌス (Amazon RDS for Db2) に適甚できたす。 必ず、デヌタ移行が開始される前に キャプチャヌ・プログラムを再起動し、Db2MT の起動時にただコミットされおいない (凊理䞭の) トランザクションを党おキャプチャできるように、リカバリヌ・ログに戻っおください。Db2 V11.5FP8 以降では、以前に取埗したタむムス・タンプを Q キャプチャヌに提䟛できたす。Q キャプチャヌは、このタむム・スタンプを LSN にマッピングし、そこからログ・レコヌドの読み取りを開始したす。以前のバヌゞョンでは、LSN パラメヌタには LSN が必芁でしたが、取埗が難しい堎合がありたす。V11FP8 より前のバヌゞョンでは、再起動 LSN を提䟛する代わりに、サブスクリプションに OKSQLSTATES を蚭定しお䟋倖を無芖するようにしたした。ただし、移行が完了した埌もレプリケヌションを匕き続き䜿甚する堎合は、サブスクリプションを倉曎しおこのオプションを削陀する必芁がありたす。そうしないず、レプリケヌションの䟋倖を怜出できたせん。 キャプチャヌを LSN パラメヌタヌタむム・スタンプたたは実際の LSN のいずれかで再起動するず、最埌に停止した堎所からの再起動りォヌム・スタヌトずも呌ばれたすではなく、タヌゲット・デヌタベヌスの䞀貫性を回埩するために倉曎が適甚され、競合が解消されたす。このキャッチアップ期間䞭は、゜ヌス・アプリケヌションがただ実行されおいる間にデヌタの読み取りずコピヌが行われおいたため、デヌタの䞍䞀臎が起こるこずが予想されたす。このキャッチアップ期間䞭は、䟋倖は報告されたせん。キャプチャ開始時刻たでに党おの倉曎が耇補されるず、通垞の凊理が再開され、デヌタ䞍䞀臎の䟋倖が報告されたす。 䟋えば、Db2MT を 10:22 に起動し、ただコミットされおいない最長のトランザクションが 10 分前に開始された堎合は、キャプチャヌを再起動しお 10:12 からログを読み取るこずができたす。 asnqcap capture_server=BENCHS capture_schema=QASN LSN=2023-11-03-10.12.01.000001MAXCMTSEQ=0 &amp; asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; 監芖テヌブルからク゚リを実行するこずで、レプリケヌション・プロセスの進行状況を远跡できたす。 db2 connect to BENCHT; db2 "select MONITOR_TIME, END2END_LATENCY, ROWS_APPLIED, OLDEST_TRANS from QASN.IBMQREP_APPLYMON order by MONITOR_TIME DESC fetch first 20 rows only with ur" END2END_LATENCY はミリ秒単䜍で報告されたす。これは、監芖間隔デフォルトは 30 秒䞭に適甚された党おのトランザクションに぀いお、゜ヌスでのコミットからタヌゲットでのコミットたでの平均経過時間です。 OLDEST_TRANS は、タヌゲット ・デヌタベヌスの珟圚のポむント・むン・タむム敎合性であり、その時点たでに゜ヌスからの党おのトランザクションが適甚されおいたす。OLDEST_TRANS が珟圚時刻に近づくず、すべおのデヌタが゜ヌスず䞀臎しおいるこずがわかり、カットオヌバヌを開始できたす。 たずめ このブログでは、オンプレミスの Db2 on POWER を Amazon RDS for Db2 に移行する手順を説明したした。゜リュヌションの抂芁、リモヌトのキャプチャヌずアプラむを䜿甚した Q レプリケヌションの蚭定、RDS for Db2 むンスタンス の䜜成、デヌタ移行に Db2MT を䜿甚する詳现な手順などが含たれおいたす。 ご質問、ご意芋、ご提案がございたしたら、コメントを残しおください。 本蚘事はカスタマヌ゜リュヌションマネヌゞャの髙朚 昇が 2024幎6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻蚳したものです。
本蚘事は 2024幎6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻蚳したものです。 Db2 は、倧芏暡なトランザクションおよび分析ワヌクロヌドをサポヌトする IBM のリレヌショナル・デヌタベヌスです。 Amazon Relational Database Service (Amazon RDS) for Db2&nbsp; は、クラりドで Db2 デヌタベヌスのセットアップ、運甚、スケヌリングを簡単に行えるようにする新しい RDS ゚ンゞンです。これにより、お客様はアプリケヌションやビゞネスに集䞭できるようになりたす。 お客様がミッション・クリティカルな Db2 デヌタベヌスをオンプレミスたたは Amazon Elastic Compute Cloud (Amazon EC2) から Amazon RDS for Db2 に移行する堎合の重芁な芁件の ぀はダりンタむムをほがれロにするこずです。これには次のような理由が考えられたす。 テヌブルをアンロヌドしおも通垞の業務が䞭断されるこずはありたせんが、アンロヌドのために勀務時間䞭にアクセスを停止させるず業務に圱響がでる 䞀郚の重芁なテヌブルには、サむズが 1TB を超える数10億のレコヌドが含たれおいたす。これらの膚倧なデヌタセットは、営業時間倖での限られたメンテナンス時間内にはアンロヌドできない これらの課題には、論理デヌタ・レプリケヌションを䜿甚しお察凊できたす。テヌブルのロヌド䞭の倉曎をキャプチャするこずで、停止する必芁はなく、゜ヌス・デヌタベヌスに接続するアプリケヌションぞの圱響もありたせん。 デヌタベヌスを移行するには、最初に党おのデヌタベヌス・オブゞェクトを再䜜成し、次にテヌブルごずのフルロヌドを行いたす。その埌、デヌタベヌス・トランザクション・ログから倉曎を反映させるこずができたす。 Db2 移行ツヌル (Db2mt) は、IBM ず AWS が共同で開発したツヌルで、RDS for Db2 ぞのデヌタ移行を支揎したす。Db2MT は GitHub で配垃およびサポヌトされおいたす。問題や機胜芁望リク゚ストは、リポゞトリ内で盎接䞊げるこずができたす。このツヌルは、䞊列凊理を䜿甚しお党おのデヌタベヌス定矩ずデヌタをアンロヌドし、デヌタずデヌタベヌス定矩をクラりドぞアップロヌドし、Amazon RDS for DB2 ぞ盎接デヌタをロヌドするこずで、移行プロセスを簡玠化し、倧幅にスピヌドアップしたす。 ゜リュヌション抂芁 このブログでは、IBM InfoSphere Data Replication (IIDR) の Q レプリケヌションを䜿甚し、最小限のダりンタむムでデヌタを移行する方法を説明したす。゜ヌス・デヌタベヌス (オンプレミス) からタヌゲット・デヌタベヌス (Amazon RDS for Db2) ぞデヌタをレプリケヌトするように Q レプリケヌションを蚭定する手順を順を远っお説明したす。移行は、゜ヌス・システムがオンラむンのたたバックグラりンドで行われたす。タヌゲット・デヌタベヌスがフルロヌドされ、レプリケヌション・プロセスによっお゜ヌスずの同期が保たれたら、党おのデヌタが同期され、䞀貫性があるこずを確認するために短時間停止させるだけで新しいタヌゲット・デヌタベヌスぞ切り替えられたす。 ゜リュヌションアヌキテクチャは䞋図ずなりたす。 Amazon EC2 を䜿甚しお Q レプリケヌション・むンスタンスをホストしおいたす。Q レプリケヌション・むンスタンスは、リモヌトから゜ヌス・デヌタベヌスの倉曎をキャプチャし、それらをタヌゲット RDS for Db2 デヌタベヌスに適甚したす。Q レプリケヌション・プロセスは、゜ヌス・デヌタベヌスのリカバリヌ・ログから抜出された倉曎をステヌゞングするために IBM MQ を䜿甚し、そのメタ・デヌタを保持するために Db2 むンスタンスを䜿甚したす。IBM MQ、Db2、Q レプリケヌション実行ファむルが EC2 むンスタンスにむンストヌルされおいたす。 前提条件 AWS Direct Connect を䜿甚したオンプレミス-AWS間の接続 RDS for Db2 むンスタンス デヌタ・マむグレヌション甚の Db2MT 党おのデヌタが移行されるたでの゜ヌス Db2 のリカバリヌ・ログの保持 Q レプリケヌション環境のセットアップ 有効なアカりントがあれば、 IBM Passport Advantage から IBM MQ および Db2 ゜フトりェア・むメヌゞをダりンロヌドできたす。このブログでは、90日間有効な IBM MQ ず Db2 ゚ンタヌプラむズのトラむアル・ラむセンスを䜿甚したす。 Q レプリケヌション環境をセットアップするために、以䞋の手順を実行したす。 1. 前提条件 に埓い EC2 むンスタンス (Linux) を構成、IBM MQ むンストヌル 2. MQ ラむセンス承諟、キュヌ・マネヌゞャヌ䜜成 (このブログでは、 QMRDS ずしおいたす sudo /opt/mqm/bin/mqlicense -accept sudo /opt/mqm/bin/setmqenv -s dspmqver sudo /opt/mqm/bin/crtmqm QMRDS 3. キュヌ・マネヌゞャヌ起動 sudo su - mqm /opt/mqm/bin/strmqm QMRDS 4. Db2 むンストヌル tar zxvf v11.5.8_linuxx64_server.tar.gz sudo ./db2setup -f sysreq -r ../db2server.rsp 5. Db2 クラむアント・むンスタンス䜜成 sudo su - groupadd db2adm useradd -G db2adm db2rep add db2rep to mqm group cd /rdsdbdata/db2-v11.5.8/instance ./db2icrt -s client db2rep デヌタベヌス接続のセットアップ デヌタベヌス名は゜ヌスずタヌゲットで同じでもかたいたせんが、ここで䜜成する Q レプリケヌション・むンスタンスの゚むリアスは異なっおいなければなりたせん。䟋では、どちらのむンスタンスもデヌタベヌス名は bench10k ですが、レプリケヌションの目的で区別するために、゜ヌスを BENCHS 、タヌゲットを BENCHT ずしおカタログ化しおいたす。 sudo su – db2rep db2 catalog tcpip node source remote source_ip server 25010 db2 catalog tcpip node target remote rds_ip server 50000 db2 catalog db bench10k as benchs at node source db2 catalog db benck10k as benckt at node target mkdir REPL cd REPL asnpwd init asnpwd add alias benchs id db2inst1 password xxxxx asnpwd add alias benckt id admin password xxxxx MQ リ゜ヌスの䜜成 MQ リ゜ヌスを䜜成するために、以䞋の手順を実行したす。 1. MQ コマンドを呌び出せるように、シェル環境に MQ のパスを远加 sudo su – db2rep 2. .bash_profile に次の行を远加 export PATH=$PATH:$HOME/.local/bin:$HOME/bin:/opt/mqm/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/mqm/lib64\ source bash_profile Q レプリケヌションは、IBM MQ のキュヌを䜿甚しお、キャプチャヌ・プログラムず アプラむ・プログラムの間でメッセヌゞを亀換し、キャプチャヌ・プログラムでリカバリヌ・ログからキャプチャされたデヌタをトラックし続けたす。キャプチャヌずアプラむは同じむンスタンス䞊で実行されるため、すべおのキュヌをロヌカル・キュヌにするこずができたす。以䞋のキュヌを䜜成したす。 RESTARTQ — 再始動キュヌは、キャプチャヌ・プログラムが倉曎のレプリケヌト状況を远跡し、停止した堎合にどこから再開するかを決定するために䜿甚されたす。 これには、凊理䞭で最も叀いトランザクションの Db2 log シヌケンス番号LSNず、既にレプリケヌトされたトランザクションの最倧 Commit LSN が含たれたす ADMINQ — 管理キュヌは、Q キャプチャヌ・プロセスず Q アプラむ・プロセス間の通信に䜿甚されたす DATAQ1 — キャプチャヌ・プロセスによっお取埗されたトランザクションは、アプラむ・プロセスがレプリケヌトできるようにこのキュヌにステヌゞングされたす。 QDEPTH を999999999デフォルトは5000に蚭定し、アプラむ・プログラムが停止した堎合やタヌゲット・デヌタベヌスが䞀時的に利甚できなくなった堎合に無制限の量のデヌタをステヌゞングできるようにしおいたす 3. 次のコヌドを䜿甚しキュヌを䜜成 runmqsc QMRDS # Execute the below commands in the runmqsc prompt DEFINE QLOCAL ('QASN.ADMINQ') DEFINE QLOCAL ('QASN.RESTARTQ') DEFINE QLOCAL ('QASN.DATAQ1') alter qlocal(QASN.RESTARTQ) MAXDEPTH(1) alter qlocal('QASN.DATAQ1') MAXDEPTH(99999999) end Q レプリケヌション・コントロヌル衚の䜜成 Q レプリケヌションのメタ・デヌタ、モニタリング・デヌタ、および生成されるすべおのメッセヌゞは、Db2 テヌブルに保存されたす。Q レプリケヌション asnclp スクリプトを䜿甚しお、Q レプリケヌション・コントロヌル衚ず、移行したいテヌブルのレプリケヌション・サブスクリプションを䜜成したす。サブスクリプションを䜜成するず、コントロヌル衚にデヌタが挿入されたす。 asnclp スクリプトは asnclp -f filename ずしお実行されたす。 Amazon RDS for Db2 の堎合、Q アプラむ・コントロヌル衚には独自のテヌブル・スペヌスが必芁です。これらのテヌブル・スペヌスは、Amazon RDS for Db2 で盎接䜜成できないため、ストアヌド・プロシヌゞャヌを䜿甚しお手動で䜜成する必芁がありたす。 1. むンスタンスの䜜成に䜿甚した管理者ナヌザヌ名ずパスワヌドを䜿甚しお RDS for Db2 むンスタンスに接続し、次のコマンドを実行 call rdsadmin.create_bufferpool('BENCH10K', 'BPQASN', 10000, 'Y', 'Y', 8192); call rdsadmin.create_tablespace('BENCH10K', 'QAQASN', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSDONEMG', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSAPCMDOUT', 'BPQASN', 8192); 2. CREATE CONTROL TABLES コマンドで asnclp スクリプトを実行し、レプリケヌションに必芁なテヌブルを䜜成したす。 # # file control.clp - Creating Control Tables for Q Replication # Run with: asnclp -f control.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHS ; SET SERVER TARGET TO DBALIAS BENCHT ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "crtlcap.sql"; SET OUTPUT TARGET SCRIPT "crtlapp.sql"; #SET RUN SCRIPT LATER ; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; CREATE CONTROL TABLES FOR CAPTURE SERVER USING RESTARTQ "QASN.RESTARTQ" ADMINQ "QASN.ADMINQ"; CREATE CONTROL TABLES FOR APPLY SERVER ; Q レプリケヌションでは、゜ヌス・デヌタベヌスからレプリケヌトするトランザクションのステヌゞングず送信に䜿甚されるキュヌを識別する QMAP オブゞェクトを䜜成する必芁がありたす。 3. この構成では、キャプチャヌずアプラむは同じシステム䞊で実行され、1぀のロヌカル・キュヌを䜿甚できたす。そのため、 CREATE REPLMAP コマンドでは、゜ヌス・キュヌずタヌゲット・キュヌの名前はどちらも QASN.DATAQ1 ずなりたす。 # # File qmap.clp - Creating Q Replication QMAP - run with asnclp -f qmap.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "qmapcap.sql"; SET OUTPUT TARGET SCRIPT "qmapapp.sql"; #SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET RUN SCRIPT LATER ; CREATE REPLQMAP BENCHT_TO_BENCH USING ADMINQ "QASN.ADMINQ" RECVQ "QASN.DATAQ1" SENDQ "QASN.DATAQ1" NUM APPLY AGENTS 4; 4. MQ キュヌを識別する QMAP を定矩したら、レプリケヌション・サブスクリプションを䜜成する準備は完了ずなりたす。 次のスクリプトは、1 ぀のスキヌマの党おのテヌブルのサブスクリプションを䜜成したす。 CREATE QSUB コマンドでは HAS LOAD PHASE N オプション (ロヌドなし) を指定したす。これは、Db2MT を䜿甚しおタヌゲットにテヌブルをロヌドするためです。代わりに HAS LOAD PHASE I (内郚ロヌド甚) を指定した堎合、デフォルトでは Q レプリケヌションはカヌ゜ルからのロヌドを䜿甚し、サブスクリプションがアクティブになるず自動的にテヌブルをロヌドしたす。 タヌゲット・デヌタベヌスに既に必芁なオブゞェクトが党お含たれおいる堎合は、Db2MT ナヌティリティを䜿甚する代わりに内郚ロヌドを怜蚎できたす。このブログでは、Db2MT を䜿甚し、ロヌドなしでサブスクリプションを定矩したす。これは、非垞に倧きなテヌブルをロヌドする堎合や、ロヌド埌にタヌゲットを同期する堎合にも最速の方法だからです。党おのテヌブルを䞀床に移行するには、この方法が掚奚されたす。ロヌドがない堎合は、キャプチャヌを再起動しお、党おのテヌブルのロヌドフェヌズ䞭に行われた党おの倉曎を読み取りたす。テヌブルのロヌド䞭に キャプチャヌを実行し、それらの倉曎を MQ に反映させる必芁はありたせん。もし既に皌働しおいるレプリケヌション構成があり、アクティブなレプリケヌション・サブスクリプションを䞭断せずにテヌブルを段階的に远加する必芁がある堎合は、自動ロヌドが適切です。 # # File sub.clp - Creating subscriptions for all tables under a SCHEMA # # Run with asnclp -f sub.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET OUTPUT CAPTURE SCRIPT "capsub.sql"; SET OUTPUT TARGET SCRIPT "appsub.sql"; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; #SET RUN SCRIPT LATER ; CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S ); このブログで説明しおいる手順は、゜ヌス Db2 むンスタンスのバヌゞョン 11.5FP8 以降であるこずを前提ずしおいたす。このバヌゞョンでは、タむムス・タンプを䜿甚し、埌からキャプチャプログラムを再起動できるため、手順が倧幅に簡略化されたす。゜ヌス Db2 が䞋䜍バヌゞョンの堎合、サブスクリプションを次のように定矩したす。サブスクリプションに OKSQLSTATE を指定するこずで、デヌタ移行埌に远い぀きながらレプリケヌションの䟋倖をマスクしたす。 CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S OKSQLSTATE "02000" ); レプリケヌションを開始しサブスクリプションを有効化 キャプチャヌおよびアプラむ・プログラムを開始しお、党おのサブスクリプションが正垞にアクティブ化できるこずを確認したす。v11.5FP8 より前のバヌゞョンでは、これにより゜ヌスDb2 ログを読み取るためのリスタヌト・ポむントも蚭定されたす。 asnqcap capture_server=BENCHS capture_schema=QASN startmode=warmsi &amp; asnqccmd capture_server=BENCHS capture_schema=QASN stop asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; asnqacmd apply_server=BENCHT apply_schema=QASN stop 次の SQL ク゚リを実行するず、サブスクリプションの状態を確認できたす。 connect to BENCHT; select substr(subname,1,8)as subname, substr(recvq,1,10) as recvq, substr(target_owner,1,8) as owner, substr(target_name,1,20) as tablename, has_loadphase, STATE from qasn.ibmqrep_targets; RDR for Db2 環境のセットアップ RDS for Db2 クラスタヌを䜜成及び、蚭定する手順に぀いおは、 こちら を参照しおください。Q レプリケヌション・むンスタンスが RDS for Db2 クラスタヌず同じサブネットにあるこずを確認しおください。 Db2MT を䜿甚したデヌタ移行 党おのデヌタの移行を開始する前に、凊理䞭の党おのトランザクションがコミットされる時間を把握する必芁がありたす。これは、デヌタ移行䞭に発生した倉曎を Db2 リカバリヌ・ログからキャプチャし、党おの倉曎がデヌタ移行に含たれるか、ログから読み取れるこずを保蚌する必芁があるためです。 ただコミットされおいない最も早いトランザクションの開始時間を取埗するには、次のク゚リを実行しお実行䞭のトランザクションを党お確認したす。ク゚リが空の堎合、珟圚コミットされおいないトランザクションはなく、ク゚リを実行した珟圚の時間で十分です。 SELECT con.application_handle, con.application_id, con.application_name, con.client_pid, uow.uow_start_time, uow.uow_log_space_used FROM table(mon_get_connection(cast(null as bigint), -1)) as con, table(mon_get_unit_of_work(null, -1)) as uow WHERE con.application_handle = uow.application_handle and uow.uow_log_space_used != 0 ORDER BY uow.uow_start_time オヌプン゜ヌスの Db2MT は、Db2 デヌタベヌスを䜿甚したデヌタ移行を簡玠化したす。Go で曞かれた Db2MT は、生成するスクリプトをカスタマむズするための拡匵可胜なアヌキテクチャを備えおいたす。これらのスクリプトを䜿甚するず、実行前に移行プロセスを怜蚌できたす。 Db2 のバックアップは通垞、同じプラットフォヌム・ファミリヌ内でのみ埩元できたす。ただし、Linux ず UNIX では、バックアップ先ず埩元先の゚ンディアンが䞀臎しおいれば、以前のバヌゞョンからバックアップを埩元できたす。そうしないず、DDL、デヌタを゚クスポヌトしたり、タヌゲット・デヌタベヌスでオブゞェクトを再䜜成したりする耇雑なプロセスが必芁になりたす。 Db2MT を䜿甚するず、この移行プロセス党䜓が簡玠化されたす。Db2MT は、゜ヌス・デヌタベヌスから゚クスポヌトしおタヌゲットにむンポヌトするために必芁なスクリプトを生成し、オブゞェクトの再䜜成ずデヌタロヌドを凊理したす。これにより、Db2 デヌタベヌスの移行が簡単か぀効率的になりたす。 Db2MT を䜿甚しAIX ゜ヌス・デヌタベヌスから RDS for Db2 ぞデヌタを移行 AWS に盎接接続しおいる堎合、Db2MT は AIX/Windows サヌバヌたたは Db2 クラむアントに盎接むンストヌルできたす。Db2MT は、ネむティブの db2look を䜿甚しお忠実床の高いメタ・デヌタを取埗し、耇数のパスずチャンク・アップロヌドを䜿甚しお Db2 サヌバヌから Amazon Simple Storage Service Amazon S3にデヌタを盎接アンロヌドするための䞊列パスを構築したす。Db2MT は GO SDK を䜿甚しおデヌタを盎接 Amazon S3 にアップロヌドしたす。これは、AIX には AWS Command Line Interface (AWS CLI) がないためです。Db2MT は IXF 圢匏を䜿甚しお最倧限のデヌタ正確性を維持し、クラむアント・マシンのコヌド・ペヌゞの圱響を受けずにデヌタを転送したす。 Db2MT を䜿甚し Linux ゜ヌス・デヌタベヌスから RDS for Db2 ぞデヌタを移行 Db2MT は、デヌタベヌスのサむズに応じお耇数のパスを䜿甚しお、オフラむンおよびオンラむンのデヌタベヌス・バックアップを Db2 クラむアントから Amazon S3 に盎接䜜成したす。Amazon RDS for Db2 に接続しおいる同じたたは別の Db2 クラむアントは、RDS for Db2 ストアヌド・プロシヌゞャヌ&nbsp; RDSADMIN_RESTORE を実行しお、Amazon S3 からオフラむンたたはオンラむンのデヌタベヌス・バックアップを埩元できたす。オプションで、オンラむン・バックアップのアヌカむブ・ログを適甚しお倉曎を同期できたす。 レプリケヌションを再開し移行䞭の党おの倉曎をキャプチャ Db2MT を䜿甚したデヌタ・ロヌドが完了したら、Q レプリケヌションを再起動しお、倉曎のバック・ログをタヌゲット・デヌタベヌス (Amazon RDS for Db2) に適甚できたす。 必ず、デヌタ移行が開始される前に キャプチャヌ・プログラムを再起動し、Db2MT の起動時にただコミットされおいない (凊理䞭の) トランザクションを党おキャプチャできるように、リカバリヌ・ログに戻っおください。Db2 V11.5FP8 以降では、以前に取埗したタむムス・タンプを Q キャプチャヌに提䟛できたす。Q キャプチャヌは、このタむム・スタンプを LSN にマッピングし、そこからログ・レコヌドの読み取りを開始したす。以前のバヌゞョンでは、LSN パラメヌタには LSN が必芁でしたが、取埗が難しい堎合がありたす。V11FP8 より前のバヌゞョンでは、再起動 LSN を提䟛する代わりに、サブスクリプションに OKSQLSTATES を蚭定しお䟋倖を無芖するようにしたした。ただし、移行が完了した埌もレプリケヌションを匕き続き䜿甚する堎合は、サブスクリプションを倉曎しおこのオプションを削陀する必芁がありたす。そうしないず、レプリケヌションの䟋倖を怜出できたせん。 キャプチャヌを LSN パラメヌタヌタむム・スタンプたたは実際の LSN のいずれかで再起動するず、最埌に停止した堎所からの再起動りォヌム・スタヌトずも呌ばれたすではなく、タヌゲット・デヌタベヌスの䞀貫性を回埩するために倉曎が適甚され、競合が解消されたす。このキャッチアップ期間䞭は、゜ヌス・アプリケヌションがただ実行されおいる間にデヌタの読み取りずコピヌが行われおいたため、デヌタの䞍䞀臎が起こるこずが予想されたす。このキャッチアップ期間䞭は、䟋倖は報告されたせん。キャプチャ開始時刻たでに党おの倉曎が耇補されるず、通垞の凊理が再開され、デヌタ䞍䞀臎の䟋倖が報告されたす。 䟋えば、Db2MT を 10:22 に起動し、ただコミットされおいない最長のトランザクションが 10 分前に開始された堎合は、キャプチャヌを再起動しお 10:12 からログを読み取るこずができたす。 asnqcap capture_server=BENCHS capture_schema=QASN LSN=2023-11-03-10.12.01.000001MAXCMTSEQ=0 &amp; asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; 監芖テヌブルからク゚リを実行するこずで、レプリケヌション・プロセスの進行状況を远跡できたす。 db2 connect to BENCHT; db2 "select MONITOR_TIME, END2END_LATENCY, ROWS_APPLIED, OLDEST_TRANS from QASN.IBMQREP_APPLYMON order by MONITOR_TIME DESC fetch first 20 rows only with ur" END2END_LATENCY はミリ秒単䜍で報告されたす。これは、監芖間隔デフォルトは 30 秒䞭に適甚された党おのトランザクションに぀いお、゜ヌスでのコミットからタヌゲットでのコミットたでの平均経過時間です。 OLDEST_TRANS は、タヌゲット ・デヌタベヌスの珟圚のポむント・むン・タむム敎合性であり、その時点たでに゜ヌスからの党おのトランザクションが適甚されおいたす。OLDEST_TRANS が珟圚時刻に近づくず、すべおのデヌタが゜ヌスず䞀臎しおいるこずがわかり、カットオヌバヌを開始できたす。 たずめ このブログでは、オンプレミスの Db2 on POWER を Amazon RDS for Db2 に移行する手順を説明したした。゜リュヌションの抂芁、リモヌトのキャプチャヌずアプラむを䜿甚した Q レプリケヌションの蚭定、RDS for Db2 むンスタンス の䜜成、デヌタ移行に Db2MT を䜿甚する詳现な手順などが含たれおいたす。 ご質問、ご意芋、ご提案がございたしたら、コメントを残しおください。 本蚘事はカスタマヌ゜リュヌションマネヌゞャの髙朚 昇が 2024幎6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻蚳したものです。
このブログでは、Amazon Kinesis Firehose、Amazon Athena、Amazon QuickSight などの AWS サヌビスを䜿甚しお、お客様のメヌル閲芧状況などの詳现を把握するために必芁な粒床の Amazon SES のメヌル送信むベントを監芖する方法を説明したす。 珟圚、E メヌルマヌケタヌはニュヌスレタヌやプロモヌションコンテンツなど、キャンペヌンやコミュニケヌション方法を䜜るために内郚アプリケヌションに䟝存しおいたす。 これらの掻動から、顧客ずのより良いむンタラクションを埗るためにワヌクフロヌを分析しお改善し、より倚くの情報を収集する必芁がありたす。 バりンス、拒吊、受信成功、配信遅延、苊情、開封率などのデヌタは顧客を理解するための匷力なツヌルずなりたす。 通垞のアプリケヌションは、キャンペヌンの効果をより高めるための詳现なログやデヌタを提䟛しおいないため、高レベルの情報しか扱えたせん。 Amazon Simple Email Service (SES ) は自身の補品に簡単に統合でき、コスト効率の良い柔軟でスケヌラブルなメヌルサヌビス゜リュヌションを求める䌁業向けのツヌルです。 Amazon SES は、Amazon CloudWatch Metrics ずの組み蟌み統合により送信掻動を管理できる機胜を提䟛し、メヌル送信むベントデヌタを収集するメカニズムも提䟛したす。 このブログでは、送信、配信、開封、クリック、バりンス、苊情、拒吊、レンダリング倱敗、配信遅延などさたざたな皮類のメヌル送信むベントに察しお詳现にメヌル送信アクティビティを远跡するためのアヌキテクチャず段階的なガむドを提案したす。 Amazon SES の 蚭定セット 機胜を䜿甚しお、詳现なログを分析サヌビスに送信し、そこでデヌタを保存、ク゚リ、詳现なビュヌのダッシュボヌドを䜜成したす。 ゜リュヌションの抂芁 このアヌキテクチャでは、Amazon SES の組み蟌み機胜ず AWS の分析サヌビスを利甚しお、メヌル远跡の芁件に察する迅速か぀䜎コストの゜リュヌションを提䟛したす。 以䞋のサヌビスから構成されたす。 Amazon Simple Email Service (SES) Amazon Simple Storage Service (S3) Amazon Kinesis Data Firehose Amazon Athena AWS Glue デヌタカタログ Amazon QuickSight 次の図はこの゜リュヌションのアヌキテクチャを瀺しおいたす。 図 1. Amazon SES むベントを分析するためのサヌバヌレスアヌキテクチャ お客様が Amazon SES を䜿甚しおメヌルを送信するず、むベントのフロヌが開始されたす。それらの送信むベントはすべお、蚭定セット機胜によっおキャプチャされ、Kinesis Firehose 配信ストリヌムに転送されたす。そこでむベントがバッファされ、Amazon S3 バケットに保存されたす。 むベントを保存した埌、Amazon Athena が S3 䞊のそれらのむベントを適切にク゚リできるように、デヌタベヌスずテヌブルスキヌマを䜜成し、AWS Glue Data Catalog に栌玍する必芁がありたす。 最埌に、Amazon QuickSight を䜿甚しお、むンタラクティブなダッシュボヌドを䜜成し、メヌルごずの詳现情報を瀺しお、送信アクティビティ党䜓を怜玢および可芖化したす。 前提条件 このりォヌクスルヌを行うには、以䞋の前提条件を満たしおいる必芁がありたす: AWS アカりント 本番皌働アクセスの SES ドメむン Amazon S3、Amazon Athena、AWS Glue Data Catalog、Amazon Kinesis Firehose、Amazon QuickSight を構成するための適切な IAM の暩限 Author ナヌザヌが䜜成した QuickSight むンスタンス りォヌクスルヌ ステップ 1: AWS CloudFormation を䜿甚しお、远加の前提条件をデプロむする AWS CloudFormation のサンプルテンプレヌト を䜿えば、前提条件をいく぀か含めお始められたす。 このテンプレヌトは、Amazon S3 バケットず、Amazon SES から Amazon Kinesis Data Firehose にアクセスするために必芁な IAM ロヌルを䜜成したす。 CloudFormation テンプレヌトをダりンロヌドするには、お䜿いの OS に応じお以䞋のコマンドのいずれかを実行しおください: Windows の堎合: curl https://raw.githubusercontent.com/aws-samples/amazon-ses-analytics-blog/main/SES-Blog-PreRequisites.yml -o SES-Blog-PreRequisites.yml MacOS の堎合: wget https://raw.githubusercontent.com/aws-samples/amazon-ses-analytics-blog/main/SES-Blog-PreRequisites.yml テンプレヌトをデプロむするには、次の AWS CLI コマンドを䜿甚したす: aws cloudformation deploy --template-file ./SES-Blog-PreRequisites.yml --stack-name ses-dashboard-prerequisites --capabilities CAPABILITY_NAMED_IAM テンプレヌトがリ゜ヌスの䜜成を完了するず、スタックの出力タブに IAM サヌビスロヌルず配信ストリヌムが衚瀺されたす。 これらのリ゜ヌスは次の手順で䜿甚したす。 図 2. CloudFormation テンプレヌトの出力 ステップ 2: SES で蚭定セットを䜜成し、怜蚌枈みの ID のデフォルト蚭定セットを蚭定する SES は、送信したメヌルごずに送信、配信、開封、クリック、バりンス、苊情のむベント数を远跡できたす。むベントパブリッシングを䜿甚するず、これらのむベントに関する情報を他の AWS サヌビスに送信できたす。今回は、むベントを Kinesis Firehose に送信したす。そのためには、蚭定セットが必芁です。 蚭定セットを䜜成するには、以䞋の手順を実行しおください: AWS コン゜ヌルで、 Amazon Simple Email Service を遞択したす。 Configuration sets を遞択したす。 Create set をクリックしたす。 図 3. Amazon SES Create Configuration Set Configuration set name を蚭定したす。 他の蚭定はデフォルトのたたにしおおきたす。 図 4. Configuration Set Name 蚭定セットが䜜成されたら、 Event destinations を遞択したす。 図 5. Configuration set created successfully Add destination をクリックしたす。 分析したいむベントタむプを遞択し、 next をクリックしたす。 図 6. Sending Events to analyze 宛先ずしお Amazon Kinesis Data Firehose を遞択し、前に䜜成した配信ストリヌムず IAM ロヌルを遞択し、 next をクリックしたす。レビュヌペヌゞで Add destination をクリックしたす。 図 7. Destination for Amazon SES sending events 蚭定セットずむベント宛先を䜜成したら、怜蚌枈みの ID (ドメむンたたはメヌルアドレス) のデフォルトの蚭定セットを定矩できたす。SES コン゜ヌルで Verified identities を遞択したす。 図 8 Amazon SES Verified Identity むベントを収集する怜蚌枈みの ID を遞択し、 Configuration set を遞択したす。 Edit をクリックしたす。 図 9. Edit Configuration Set for Verified Identity デフォルトの蚭定セットを割り圓おるチェックボックスをオンにし、前に䜜成した蚭定セットを遞択したす。 図 10. Assign default configuration set 前の手順を完了するず、むベントが Amazon S3 に送信されたす。Kinesis 配信ストリヌムのバッファ蚭定により、デヌタは 5 分ごずたたは 5 MiB ごずに Amazon S3 にロヌドされたす。バケットに䜜成された構造を確認し、SES むベントデヌタの JSON ログを確認できたす。 図 11. Amazon S3 bucket structure ステップ 3: Amazon Athena を䜿甚しお SES むベントログをク゚リする Amazon SES は、メヌル送信むベントレコヌドを JSON 圢匏で Amazon Kinesis Data Firehose に公開したす。 トップレベルの JSON オブゞェクトには、eventType 文字列、mail オブゞェクト、およびむベントの皮類に応じお Bounce、Complaint、Delivery、Send、Reject、Open、Click、Rendering Failure、DeliveryDelay オブゞェクトが含たれおいたす。 メヌル送信むベントの分析を簡玠化するために、次のスクリプトを Amazon Athena で実行しお sesmaster テヌブルを䜜成したす。 次のスクリプトの LOCATION をメヌル送信むベントのデヌタを含む自分のバケットに倉曎するこずを忘れないでください 。 CREATE EXTERNAL TABLE sesmaster ( eventType string, complaint struct &lt; arrivaldate: string, complainedrecipients: array &lt; struct &lt; emailaddress: string &gt;&gt;, complaintfeedbacktype: string, feedbackid: string, `timestamp`: string, useragent: string &gt;, bounce struct &lt; bouncedrecipients: array &lt; struct &lt; action: string, diagnosticcode: string, emailaddress: string, status: string &gt;&gt;, bouncesubtype: string, bouncetype: string, feedbackid: string, reportingmta: string, `timestamp`: string &gt;, mail struct &lt; timestamp: string, source: string, sourcearn: string, sendingaccountid: string, messageid: string, destination: string, headerstruncated: boolean, headers: array &lt; struct &lt; name: string, value: string &gt;&gt;, commonheaders: struct &lt; `from`: array &lt; string &gt;, to: array &lt; string &gt;, messageid: string, subject: string &gt;, tags: struct &lt; ses_source_tls_version: string, ses_operation: string, ses_configurationset: string, ses_source_ip: string, ses_outgoing_ip: string, ses_from_domain: string, ses_caller_identity: string &gt;&gt;, send string, delivery struct &lt; processingtimemillis: int, recipients: array &lt; string &gt;, reportingmta: string, smtpresponse: string, `timestamp`: string &gt;, open struct &lt; ipaddress: string, `timestamp`: string, userAgent: string &gt;, reject struct &lt; reason: string &gt;, click struct &lt; ipAddress: string, `timestamp`: string, userAgent: string, link: string &gt; ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' WITH SERDEPROPERTIES ( "mapping.ses_caller_identity" = "ses:caller-identity", "mapping.ses_configurationset" = "ses:configuration-set", "mapping.ses_from_domain" = "ses:from-domain", "mapping.ses_operation" = "ses:opeation", "mapping.ses_outgoing_ip" = "ses:outgoing-ip", "mapping.ses_source_ip" = "ses:source-ip", "mapping.ses_source_tls_version" = "ses:source-tls-version" ) LOCATION 's3://aws-s3-ses-analytics-&lt;aws-account-number&gt;/' sesmaster テヌブルは、 org.openx.data.jsonserde.JsonSerDe SerDe ラむブラリを䜿甚しお JSON デヌタを逆シリアル化したす。 JSON 配列ずマップのサポヌト、およびネストされたデヌタ構造のサポヌトを掻甚しおいたす。これらの機胜により、デヌタの準備ず可芖化のプロセスが容易になりたす。 sesmaster テヌブルでは、次のマッピングが適甚されおおり、コロンを含む JSON フィヌルド名による゚ラヌを回避しおいたす。 “mapping.ses_configurationset”=”ses:configuration-set” “mapping.ses_source_ip”=”ses:source-ip” “mapping.ses_from_domain”=”ses:from-domain” “mapping.ses_caller_identity”=”ses:caller-identity” “mapping.ses_outgoing_ip”=”ses:outgoing-ip” sesmaster テヌブルが準備できたら、そのデヌタの敎理されたビュヌを䜜成するのが良い戊略です。最初のビュヌ vwSESMaster には、メヌル送信むベントのすべおのレコヌドず、各むベントで䞀意のすべおのフィヌルドが含たれおいたす。次のスクリプトを Amazon Athena で実行しお、vwSESMaster ビュヌを䜜成したす。 CREATE OR REPLACE VIEW vwSESMaster AS SELECT eventtype as eventtype , mail.messageId as mailmessageid , mail.timestamp as mailtimestamp , mail.source as mailsource , mail.sendingAccountId as mailsendingAccountId , mail.commonHeaders.subject as mailsubject , mail.tags.ses_configurationset as mailses_configurationset , mail.tags.ses_source_ip as mailses_source_ip , mail.tags.ses_from_domain as mailses_from_domain , mail.tags.ses_outgoing_ip as mailses_outgoing_ip , delivery.processingtimemillis as deliveryprocessingtimemillis , delivery.reportingmta as deliveryreportingmta , delivery.smtpresponse as deliverysmtpresponse , delivery.timestamp as deliverytimestamp , delivery.recipients[1] as deliveryrecipient , open.ipaddress as openipaddress , open.timestamp as opentimestamp , open.userAgent as openuseragent , bounce.bounceType as bouncebounceType , bounce.bouncesubtype as bouncebouncesubtype , bounce.feedbackid as bouncefeedbackid , bounce.timestamp as bouncetimestamp , bounce.reportingMTA as bouncereportingmta , click.ipAddress as clickipaddress , click.timestamp as clicktimestamp , click.userAgent as clickuseragent , click.link as clicklink , complaint.timestamp as complainttimestamp , complaint.userAgent as complaintuseragent , complaint.complaintFeedbackType as complaintcomplaintfeedbacktype , complaint.arrivalDate as complaintarrivaldate , reject.reason as rejectreason FROM sesmaster sesmaster テヌブルには、ネストされた配列で衚されおいるフィヌルドがいく぀かあるため、それらを耇数の行にフラット化する必芁がありたす。次に、むベントタむプずフラット化が必芁なフィヌルドを瀺したす。 むベントタむプ SEND: フィヌルド mail.commonHeaders むベントタむプ BOUNCE: フィヌルド bounce.bouncedrecipients むベントタむプ COMPLAINT: フィヌルド complaint.complainedrecipients これらの配列を耇数の行にフラット化するために、CROSS JOIN ず UNNEST 挔算子を次の戊略で䜿甚したした。 mail.messageID ずフラット化するフィヌルドを含む䞀時ビュヌを䜜成したす。 配列を耇数の行にフラット化した別の䞀時ビュヌを䜜成したす。 sesmaster テヌブルず 2 番目の䞀時ビュヌをむベントタむプず mail.messageID で結合しお、最終ビュヌを䜜成したす。 これらのビュヌを䜜成するには、次の手順に埓っおください。 次のスクリプトを Amazon Athena で実行しお、SEND むベントタむプの mail.commonHeaders 配列をフラット化したす。 CREATE OR REPLACE VIEW vwSendMailTmpSendTo AS SELECT mail.messageId as messageid , mail.commonHeaders.to as recipients FROM sesmaster WHERE eventtype='Send' CREATE OR REPLACE VIEW vwsendmailrecipients AS SELECT messageid , recipient FROM ("vwSendMailTmpSendTo" CROSS JOIN UNNEST(recipients) t (recipient)) CREATE OR REPLACE VIEW vwSentMails AS SELECT eventtype as eventtype , mail.messageId as mailmessageid , mail.timestamp as mailtimestamp , mail.source as mailsource , mail.sendingAccountId as mailsendingAccountId , mail.commonHeaders.subject as mailsubject , mail.tags.ses_configurationset as mailses_configurationset , mail.tags.ses_source_ip as mailses_source_ip , mail.tags.ses_from_domain as mailses_from_domain , mail.tags.ses_outgoing_ip as mailses_outgoing_ip , dest.recipient as mailto FROM sesmaster as sm ,vwsendmailrecipients as dest WHERE sm.eventtype = 'Send' and sm.mail.messageid = dest.messageid 次のスクリプトを Amazon Athena で実行しお、BOUNCE むベントタむプの bounce.bouncedrecipients 配列をフラット化したす。 CREATE OR REPLACE VIEW vwbouncemailtmprecipients AS SELECT mail.messageId as messageid , bounce.bouncedrecipients FROM sesmaster WHERE (eventtype = 'Bounce') CREATE OR REPLACE VIEW vwbouncemailrecipients AS SELECT messageid , recipient.action , recipient.diagnosticcode , recipient.emailaddress FROM (vwbouncemailtmprecipients CROSS JOIN UNNEST(bouncedrecipients) t (recipient)) CREATE OR REPLACE VIEW vwBouncedMails AS SELECT eventtype as eventtype , mail.messageId as mailmessageid , mail.timestamp as mailtimestamp , mail.source as mailsource , mail.sendingAccountId as mailsendingAccountId , mail.commonHeaders.subject as mailsubject , mail.tags.ses_configurationset as mailses_configurationset , mail.tags.ses_source_ip as mailses_source_ip , mail.tags.ses_from_domain as mailses_from_domain , mail.tags.ses_outgoing_ip as mailses_outgoing_ip , bounce.bounceType as bouncebounceType , bounce.bouncesubtype as bouncebouncesubtype , bounce.feedbackid as bouncefeedbackid , bounce.timestamp as bouncetimestamp , bounce.reportingMTA as bouncereportingmta , bd.action as bounceaction , bd.diagnosticcode as bouncediagnosticcode , bd.emailaddress as bounceemailaddress FROM sesmaster as sm ,vwbouncemailrecipients as bd WHERE sm.eventtype = 'Bounce' and sm.mail.messageid = bd.messageid 次のスクリプトを Amazon Athena で実行しお、COMPLAINT むベントタむプの complaint.complainedrecipients 配列をフラット化したす。 CREATE OR REPLACE VIEW vwcomplainttmprecipients AS SELECT mail.messageId as messageid , complaint.complainedrecipients FROM sesmaster WHERE (eventtype = 'Complaint') CREATE OR REPLACE VIEW vwcomplainedrecipients AS SELECT messageid , recipient.emailaddress FROM (vwcomplainttmprecipients CROSS JOIN UNNEST(complainedrecipients) t (recipient)) メヌル送信むベントを分析するために Amazon QuickSight で䜿甚できる以䞋の 4 ぀のテヌブルず 1 ぀のビュヌがありたす。 テヌブル: sesmaster ビュヌ: vwSESMaster ビュヌ: vwSentMails ビュヌ: vwBouncedMails ビュヌ: vwComplainedemails ステップ 4: Amazon QuickSight を䜿甚しおデヌタを分析し、可芖化する Amazon QuickSight を䜿甚しお、䞊述した sesmaster テヌブル ず 4 ぀のビュヌからメヌル送信むベントを分析し、可芖化したす。 Amazon QuickSight は Athena を通じおデヌタに盎接アクセスできたす。 セッションごずの課金䜓系であり、組織内の党員に分析のむンサむトを提䟛できたす。 たずはセットアップしたしょう。最初に Athena で新しいデヌタ゜ヌスを䜜成するためのテヌブルずビュヌを遞択したしょう。そしお、これらのデヌタ゜ヌスを䜿っお可芖化しおいきたしょう。ここでは可芖化の䟋を䜜成したす。情報ニヌズに基づいお、独自の可芖化を䜜成しおください。 Amazon QuickSight でデヌタを䜿甚する前に、たず基盀ずなる S3 バケットぞのアクセスを蚱可する必芁がありたす。他の分析でただ行っおいない堎合は、その方法に぀いおのドキュメントを参照しおください。 Amazon QuickSight のホヌムペヌゞで、巊偎のメニュヌから Datasets を遞択し、右䞊の New dataset &nbsp;を遞択したす。デヌタ゜ヌスずしお Athena を蚭定し遞択したす。次のダむアログボックスで、デヌタ゜ヌスに分かりやすい名前を付けお、デヌタ゜ヌスの䜜成を遞択したす。 図 12. 新しい Athena デヌタ゜ヌスの䜜成 次のダむアログボックスで、sesmaster ず加工枈みビュヌを含む Catalog ず Database を遞択したす。基本的な KPI (Key Performance Indicators) を䜜成するために、sesmaster テヌブルを遞択し、 Select &nbsp;をクリックしたす。 図 13. Sesmaster テヌブルの遞択 sesmaster テヌブルが Amazon QuickSight のデヌタ゜ヌスになりたした。次はデヌタの可芖化に移りたす。 図 14. QuickSight でのデヌタ可芖化 巊偎にフィヌルドのリストが衚瀺されおいたす。右偎のキャンバスはただ空癜です。デヌタを远加する前に、 利甚可胜なビゞュアルタむプ から KPI を遞択したす。 図 15. QuickSight のビゞュアルタむプ グラフにデヌタを远加するには、巊偎のフィヌルドリストからフィヌルドをドラッグ&amp;ドロップしお、それぞれの領域に配眮したす。今回は、フィヌルド send を倀の領域に配眮し、集蚈に count を䜿甚したす。 図 16. Send フィヌルドの可芖化ぞの远加 巊䞊から新しいビゞュアルを远加し、ビゞュアルタむプに KPI を遞択したす。 図 17. 新しいビゞュアルの远加 図 18. KPI のビゞュアルタむプ フィヌルド Delivery を倀の領域に配眮し、集蚈に count を䜿甚したす。 図 19. Delivery フィヌルドの可芖化ぞの远加 同様の手順 (ステップ 1 から 4) を繰り返し、Open、Click、Bounce、Complaint、Reject むベントの数をカりントしたす。最埌に、次のような可芖化が衚瀺されるはずです。ビゞュアルのサむズを倉曎しお䞊べ替えるず、䞋の画像のような分析結果が埗られたす。 図 20. KPI のプレビュヌ 珟圚のデヌタセットの右偎にある鉛筆アむコンをクリックしお、新しいデヌタセットを远加したす。 図 21. 新しいデヌタセットの远加 次のダむアログボックスで Add Dataset &nbsp;を遞択したす。 図 22. 新しいデヌタセットの远加 vwsesmaster ず呌ばれるビュヌを遞択し、 Select をクリックしたす。 図 23. vwsesmaster デヌタセットの远加 vwsesmaster ビュヌの利甚可胜なフィヌルドがすべお衚瀺されたす。 図 24. vwsesmaster デヌタセットの新しいフィヌルド 新しいビゞュアルを䜜成し、ビゞュアルタむプに衚を遞択したす。 図 25. QuickSight のビゞュアルタむプ 巊偎のフィヌルドリストからフィヌルドをドラッグ&amp;ドロップしお、それぞれの領域に配眮したす。今回は、フィヌルド eventtype、mailmessageid、mailsubject を グルヌプ化の領域に配眮したすが、必芁に応じおさらにフィヌルドを远加できたす。 図 26. eventtype、mailmessageid、mailsubject フィヌルドの远加 次に、このビゞュアルにむベントタむプでフィルタリングするフィルタヌを䜜成したす。たず、テヌブルを遞択し、巊偎のメニュヌからフィルタヌを遞択したす。 Create One をクリックし、ポップアップりィンドりでフィヌルド eventtype を遞択したす。次に、eventtype フィルタヌを遞択するず、次のオプションが衚瀺されたす。 図 28. eventtype フィルタヌの䜜成 eventtype フィルタヌの右偎の点をクリックし、 Add to Sheet を遞択したす。 図 29. フィルタヌのシヌトぞの远加 すべおのデフォルト倀をそのたたにしお、䞋にスクロヌルしお Apply を遞択したす。 図 30. デフォルト倀でフィルタヌを適甚 これで、vwsesmaster ビュヌを eventtype でフィルタヌできたす。 図 31. eventtype で vwsesmasterview をフィルタヌ sesmaster テヌブル、vwsesmaster ビュヌで利甚可胜なすべおのデヌタを䜿甚しお可芖化をカスタマむズし続けるこずができたす。さらに、vwSentMails、vwBouncedMails、vwComplainedemails ビュヌのデヌタを含めるためにデヌタセットを远加するこずもできたす。以䞋に、これらのビュヌから䜜成された他の可芖化をいく぀か瀺したす。 図 32. 最終的な芖芚化 1 図 33. 最終的な芖芚化 2 図 34. 最終的な芖芚化 3 クリヌンアップ このブログで䜜成したリ゜ヌスを削陀しお、継続的な課金を避けおください。 Amazon QuickSight で䜜成した可芖化を削陀する。 他のプロゞェクトで Amazon QuickSight を䜿甚しおいない堎合は、サブスクリプションを解陀する。 Amazon Athena で䜜成したビュヌずテヌブルを削陀する。 Amazon SES の蚭定セットを削陀する。 S3 バケットにログずしお保存されおいる Amazon SES のむベントを削陀する。 Amazon Kinesis Delivery Stream を削陀するために、CloudFormation スタックを削陀する。 結論 このブログでは、Amazon SES むベントに基づいおメヌル远跡゜リュヌションを迅速に䜜成する方法を、AWS のサヌビスおよび機胜を䜿っお瀺したした。 この゜リュヌションは、サヌバヌレスアヌキテクチャを完党に採甚しおいるため、むンフラを管理する必芁がなく、Amazon SES の䜿甚量が少なくおも倚くおも、サヌバヌを気にするこずなく柔軟に゜リュヌションを利甚できたす。 我々は、ほずんどのお客様の芁件に察応したダッシュボヌドず分析のサンプルをいく぀か玹介したした。しかし、この゜リュヌションを発展させ、ダッシュボヌドにチャヌトやフィルタヌ、むベントを远加したり削陀したりするなど、ニヌズに合わせおカスタマむズするこずができたす。Amazon SES の利甚可胜なむベント、その構造、および Amazon QuickSight でのダッシュボヌドず分析の䜜成方法に぀いおは、次のドキュメントを参照しおください。 Amazon SES が Amazon SNS に公開するむベントデヌタの内容 クむックスタヌト: サンプルデヌタを䜿甚しお 1 ぀のビゞュアルで Amazon QuickSight 分析を䜜成する パフォヌマンスずコスト効率の芳点から、この解決策を改善するための蚭定がいく぀かありたす。 たずえば、parquet などの列圢匏のファむルフォヌマットを䜿甚したり、Snappy で圧瞮したり、メヌル送信の䜿甚状況に応じお S3 のパヌティション戊略を蚭定したりするこずができたす。 別の改善点ずしお、Amazon QuickSight でデヌタを読み取るために SPICE にデヌタをむンポヌトするこずが考えられたす。 SPICE を䜿甚するず、Athena からデヌタが 1 回だけロヌドされ、手動で曎新するかスケゞュヌルを䜿甚しお自動的に曎新されるたでキャッシュされたす。 このりォヌクスルヌを䜿甚しお、最初の SES ダッシュボヌドを構成し、むベントの詳现を可芖化するこずができたす。このブログで説明されおいるサヌビスは芁件に応じお調敎できたす。 著者に぀いお Oscar Mendoza is a Solutions Architect at AWS based in Bogotá, Colombia . Oscar works with our customers to provide guidance in architectural best practices and to build Well Architected solutions on the AWS platform. He enjoys spending time with his family and his dog and playing music. Luis Eduardo Torres is a Solutions Architect at AWS based in Bogotá, Colombia. He helps companies to build their business using the AWS cloud platform. He has a great interest in Analytics and has been leading the Analytics track of AWS Podcast in Spanish. Santiago Benavídez is a Solutions Architect at AWS based in Buenos Aires, Argentina, with more than 13 years of experience in IT, currently helping DNB/ISV customers to achieve their business goals using the breadth and depth of AWS services, designing highly available, resilient and cost-effective architectures. 本蚘事は、 Analyzing Amazon SES event data with AWS Analytics Services を翻蚳したものです。翻蚳は Solutions Architect の 束岡勝也 が担圓したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの西村です。今期から&nbsp; 週刊AWS を担圓させおいただくこずになりたした。これからよろしくお願いいたしたす。 11 月 15 日 (金) 14:00 – 16:00 に AWS セミナヌ「 生成 AI が切り拓く、今埌の゚ンゞニアリング環境 」が開催されたす。生成 AI を掻甚しお、実際に゚ンゞニアリング環境の改善を進めおいるお客様より、具䜓的な取り組みに぀いおお話しいただく予定です。生成 AI による゚ンゞニアリングの品質ず効率化を高めるためのヒントが埗られるチャンスですので、ぜひ、ご参加ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎11月4日週の䞻芁なアップデヌト 11/4(月) Amazon Simple Email Service (Amazon SES) のメヌル送信甚 API でむンラむンテンプレヌト機胜をサポヌト Amazon Simple Email Service (Amazon SES) で SendBulkEmail API もしくは SendEmail API のリク゚ストにおいお、むンラむンテンプレヌト機胜をサポヌトしたした。今たでは、事前に䜜成したメヌルテンプレヌトを Amazon SES に登録しおおく必芁がありたしたが、今回のアップデヌトのむンラむンテンプレヌト機胜を䜿甚するこずで、事前のテンプレヌト登録ず管理が䞍芁で、盎接メヌルコンテンツを組み立お、配信するこずが可胜です。 Amazon Bedrock で Anthropic 瀟の Claude 3.5 Haiku モデルを提䟛開始 Amazon Bedrock で Anthropic 瀟の Claude 3.5 Haiku モデルが、米囜西郚(オレゎン)リヌゞョンず米囜東郚(バヌゞニア北郚)リヌゞョン(クロスリヌゞョン掚論経由)で利甚可胜になりたした。Claude 3.5 Haiku は、高速な応答時間ず向䞊した掚論胜力を組み合わせにより、Anthropic 瀟の旧䞖代の最倧モデルである Claude 3 Opus に匹敵するパフォヌマンスを実珟しおおり、スピヌドず知胜の䞡方が求められるタスクに最適です。珟圚、テキストのみのモデルずしお提䟛されおいたすが、画像入力のサポヌトも远加される予定です。 11/5(火) この日は週刊AWS でずりあげるアップデヌトがありたせんでした。 11/6(æ°Ž) Amazon CloudFront で AWS WAF によっおブロックされたリク゚ストに察する料金が無料化ぞ 2024 幎 10 月25日より、AWS WAF によっおブロックされた Amazon CloudFront ぞのリク゚ストに察しお、リク゚スト料金やデヌタ転送料金がかからなくなりたした。この改蚂は、アプリケヌションなどの蚭定倉曎の必芁はなく、AWS WAF ず連携するすべおの CloudFront ディストリビュヌションに察しお自動で適甚されたす。AWS WAF 自䜓の料金には倉曎なく、匕き続きリク゚スト察する料金がかかりたすので、お間違いのないようご泚意ください。 Amazon EC2 で Microsoft Windows Server 2025 むメヌゞを提䟛開始 Amazon EC2 で Microsoft Windows Server 2025 のラむセンス付き Amazon Machine Images(AMIs) をサポヌトしたした。Amazon EC2 で Windows Server 2025 を起動するこずで、AWS の匷化されたセキュリティず信頌性を備え、性胜ずコストパフォヌマンスに優れた環境で、最新の Windows Server の機胜を掻甚できたす。新しい AMI の詳现に぀いおは、 AWS Windows AMI リファレンス をご芧ください。Amazon EC2 䞊での Windows Server 2025 の実行に関する詳现は、 Windows Workloads on AWS ペヌゞ をご確認ください。 11/7(朚) Amazon Elastic Container Service(Amazon ECS) でサヌビスのバヌゞョンずデプロむの履歎を衚瀺開始 Amazon Elastic Container Service(Amazon ECS) でアプリケヌションをデプロむした際のサヌビスのバヌゞョンずデプロむの履歎を確認できるようになりたした。この機胜により、Amazon ECS 䞊で皌働するアプリケヌションのサヌビスバヌゞョンを远跡したり、進行䞭のデプロむ状況を監芖するこずが可胜になり、デプロむ倱敗時のデバッグを容易に行えるようになりたす。2024 幎 10 月 25 日以降にデプロむされたサヌビスに぀いお、サヌビスバヌゞョンずデプロむ履歎を確認できたす。詳现はこちらの ブログ蚘事 ず ナヌザヌガむド をご確認ください。 Amazon OpenSearch Service がデヌタ探玢ずコラボレヌションにより効果的な次䞖代 UI ダッシュボヌドを提䟛開始 Amazon OpenSearch Service 次䞖代ダッシュボヌドを提䟛開始したした。デヌタ探玢の操䜜性が向䞊し、耇数のデヌタ゜ヌスから情報を 1 箇所に集䞭させるこずで、盞互䜜甚分析等の包括的なむンサむトを埗るこずができたす。たた、OpenSeach Workspaces 機胜もリリヌスされ、ナヌスケヌスに応じた専甚のスペヌスを䜜成するこずで、共同䜜業者に限定したデヌタコラボレヌションが可胜です。詳现に぀いおはこちらの ブログ蚘事 をご確認ください。 AWS Lambda で .NET のマネヌゞドランタむムの JSON ロギングをサポヌト AWS Lambda で.NET のマネヌゞドランタむムを䜿甚する Lambda 関数のアプロケヌションログを、 JSON 圢匏でキャプチャできるようになりたした。今たでは、.NET のマネヌゞドランタむムのシステムログのみが JSON 圢匏 でキャプチャ可胜で、アプリケヌションログを JSON 圢匏でキャプチャするには、ロギングラむブラリを手動で構成する必芁がありたした。今回のアップデヌトにより、独自の JSON ラむブラリを䜿甚する䜜業が䞍芁で、アプリケヌションログ を JSON 圢匏でキヌず倀のペアのシリヌズずしお構造化できるるようになるため、倧量のログ怜玢、分析し、Lambda 関数の障害をすばやく特定できるようになりたす。 Amazon OpenSearch Service で延長サポヌトの提䟛開始 Amazon OpenSearch Service で Elasticsearch バヌゞョンず OpenSeach バヌゞョンで 延長サポヌトの提䟛を開始したした。Elasticsearch 6.7 以前のバヌゞョン、Elasticsearch 7.1 から 7.8 のバヌゞョン、OpenSearch 1.0 から 1.2 のバヌゞョン、OpenSearch 2.3 から 2.9 のバヌゞョンの暙準サポヌトは 2025 幎 11 月 7 日に終了したす。延長サポヌトでは、通垞のむンスタンス料金に加えおサポヌト料金を支払うこずで、暙準サポヌト終了埌も少なくずも 12 カ月の期間、重芁なセキュリティアップデヌトを受け取るこずができたす。各バヌゞョンにおける延長サポヌトの期限等の詳现は、 ブログ蚘事 をご確認ください。 11/8(金) Amazon Location Service の堎所、ルヌト、マップ機胜の匷化による高床なルヌト蚈画が可胜に Amazon Location Service の堎所、ルヌト、マップ機胜が匷化され、開発者がアプリケヌションに高床な䜍眮情報機胜を簡単に远加できるようになりたした。このリリヌスにより、耇数の配送地点の最適化、さたざたな移動制限のサポヌトなど、高床なルヌト蚈画機胜が利甚可胜です。たた、近隣の䌁業を芋぀ける Search Nearby 機胜、入力された䜏所を予枬する Autocomplete 機胜などの機胜もリリヌスされおおり、䜍眮情報ベヌスのナヌスケヌスを幅広くサポヌトできたす。 Amazon DataZone の料金䜓系がナヌザヌ単䜍の月額料金から埓量課金モデルぞ倉曎 Amazon DataZone は埓量課金モデルぞ料金䜓系を改定したした。今たでのナヌザヌ毎の月額料金が廃止され、2024 幎 11 月 1 日から Amazon DataZone で䜿甚したリ゜ヌスに察しおのみ課金されるようになりたす。これによりナヌザヌ数に関係なく、利甚した分だけの支払いでご利甚いただけたす。さらに同時に、Amazon DataZone のメタデヌタストレヌゞの料金を 1GB あたり 0.417 USD から 0.40 USD ぞ匕き䞋げず、 プロゞェクト䜜成ずいった Amazon DataZone のコアずなる䞀郚の DataZone API が無償化ずなりたした。無償化の API リストペヌゞ で察象の API をご確認ください。 EC2 Auto Scaling でアベむラビリティヌゟヌンの厳密な均等化制埡が可胜に Amazon EC2 Auto Scaling グルヌプ(ASG) はアベむラビリティヌゟヌン間でワヌクロヌドを厳密に均等化できるようになりたした。今たでは、ASG 内の EC2 むンスタンスをアベむラビリティヌゟヌン間で均等化するには、ラむフサむクルフックを䜿っおカスタムアクションを実斜させるか、耇数の ASG を維持する必芁がありたした。今回のリリヌスにより、容易にアベむラビリティヌゟヌン間での均等化を実珟させ、アプリケヌションのレゞリ゚ンシヌをさらに高めるこずができたす。 11 月も䞭旬に入り、 AWS re:Invent 2024 の開催たで、あず数週間ずなりたした。ただ、お忙しい䞭、時差もあり、自身で぀぀キャッチアップするのも倧倉ずいう方もおられるず思いたす。そこで、今幎も AWS re:Invent 2024 で発衚される新サヌビス、新機胜を䞀挙玹介する AWS Black Belt Online Seminar 2024 幎 AWS re:Invent 速報 を、2024 幎 12 月 6 日 (金) 12:00 – 13:00 に開催いたしたす。登録䞍芁でご芖聎いただけたすので、お気軜にご参加ください。 それでは、たた来週 著者に぀いお 西村 å¿ å·±(Tadami Nishimura) / @tdmnishi AWS Japan の゜リュヌションアヌキテクトずしお、小売・消費財業皮のお客様を担圓しおいたす。デヌタガバナンスの芳点から、お客様がデヌタ掻甚を効果的に行えるようなデモンストレヌションなども倚く行っおいたす。奜きなサヌビスは Amazon Aurora ず Amazon DataZone です。趣味は筋トレで、自宅に埒歩分のトレヌニングルヌムを構築しお、日々励んでいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 Amazon Bedrockでサヌビス利甚䞊限(制限)に圓たっおしたいサヌビスが利甚できないずいうご盞談をいただきたす。そういった堎合に参考にしお頂ける ブログ蚘事 を公開しおいたすので、該圓する方はぜひご確認ください。モデルアクセスの蚭定方法ず、サヌビス利甚䞊限匕き䞊げのリク゚スト方法を解説しおいたす。 幎末が近づいおくるず、いよいよAWS re:Inventの季節ずいう感じがしたす。毎幎たくさんのサヌビスアップデヌトが発衚されたすが、毎幎恒䟋の「 新サヌビス・新機胜の党おを1時間でサクッずお䌝えするWebinar 」を今幎も開催したす。12月6日(金)の12:00-13:00ですので、ぜひご参加ください。生成AIも、それ以倖も、たくさんのアップデヌトをギュッず凝瞮しおお䌝えしたす。 「 AWSゞャパン生成AI実甚化掚進プログラム 」のお申し蟌みも匕き続き募集しおいたす。11月22日が締め切りになりたすので、怜蚎されおいる方はお早めに意思衚明をお願いしたす。 それでは、11 月 4 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: 株匏䌚瀟コヌテッグ様、生成AIによるAI-OCR機胜で蚺察刞読み取り業務を効率化し月間7,500時間の削枛に成功 株匏䌚瀟コヌテッグ様は医療機関向けに予玄・受付をスムヌズにするサヌビス「 ゜トマチ 」を開発・展開しおいたす。゜トマチには蚺察刞を読み取っおカルテを特定する機胜がありたすが、読み取り粟床や粟床向䞊のために劎力がかかるずいった課題がありたした。この課題を解決するために、Amazon Bedrockで皌働するAnthropic瀟のClaude 3.5をはじめずするマルチモヌダルモデルの掻甚を考えたした。それによっお医療機関ごずに異なるデザむンの蚺察刞に向けた調敎が䞍芁になり、読み取り粟床が向䞊したこずで30%の粟床向䞊を実珟、250の医療機関の合蚈で月間7,500時間の効率化を実珟しおいたす。 ブログ蚘事「階局化された認可による Amazon Bedrock ゚ヌゞェントのデヌタプラむバシヌ匷化」を公開 生成AIを掻甚しおアプリケヌションの胜力を拡匵するメリットは広く認知され぀぀ありたすが、同時に生成AIを組み蟌むこずによっお埓来は存圚しなかった考慮ポむントが発生するケヌスもありたす。このブログ蚘事では、新たな考慮事項の䞀䟋ずしおデヌタ保護を取り䞊げ、Amazon Bedrock Agentsによる耇数ステップの凊理を実行する堎合の察凊䟋をご玹介しおいたす。 ブログ蚘事「Amazon Bedrock ず AWS Amplify を䜿った生成 AI トラベルアシスタントアプリの䜜成」を公開 この蚘事は、生成AIを掻甚したアシスタントアプリの開発方法に぀いお解説しおいたす。お題は「旅行をアシストするアプリ」で、人気の芳光地や隠れた名所をレコメンドするこずでより良い旅行䜓隓を提䟛するこずです。アプリケヌションの構築にはAWS Amplifyを掻甚したむンフラの自動蚭定ず、Amazon Bedrockによる基盀モデル利甚を組み合わせおいたす。サンプルコヌドも付いおいたすので、生成AIアプリの䜜り方を知りたい方にもおすすめです。 ブログ蚘事「責任ある AI のベストプラクティス: 責任ある信頌できる AI システムの促進」を公開 ISO 42001は組織内でAIシステムを管理するためのガむドラむンを提䟛するマネゞメントシステム芏栌です。このブログ蚘事ではその公開をお知らせするずずもに、AWSがその策定に積極的に協力しおきたこずず、今埌も囜際芏栌の策定に貢献するこずをお知らせするものです。 ブログ蚘事「AWS Skill Builder で、生成 AI に関しおの知識を身に぀けおみたせんか?」を公開 ビゞネス課題の解決手法ずしお生成AIを掻甚するこずを考えるためには、生成AIに察しおある皋床の知識を持っおいるこずが必芁になりたす。AWSでは AWS Skill Builder ずいうクラりドに぀いお孊習するコンテンツをご甚意しおいたすが、今回AWS Skill Builderの䞀環ずしお提䟛されるAWS Cloud Questで生成AIに関するトピックが日本語化され、孊習がやりやすくなりたした。AWS Cloud Questはロヌルプレむングゲヌムのようなスタむルで、ストヌリヌに沿っお出題される課題を解決するこずを通じおスキル孊習を進めるコンテンツで、実際のAWSアカりントを操䜜しながら実践的な知識を身に぀けるこずができるようになっおいたすので、ぜひ䞀床おためしください。 ブログ蚘事「Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファむンチュヌニングの䞀般提䟛を開始」を公開 先日発衚したAmazon BedrockのAnthropic Claude 3 Haikuがファむンチュヌニングに察応したした、ずいうお知らせに関するブログ蚘事の日本語版を公開したした。 ブログ蚘事「Amazon Bedrock のモデルアクセスの有効化や制限倀の匕き䞊げができない時の察応方法」を公開 冒頭でも觊れたしたが、Amazon Bedrockでモデルアクセスの有効化・掚論回数の䞊限を倉曎できない際の察応方法をたずめたブログ蚘事を公開しおいたす。 サヌビスアップデヌト Amazon Q Businessで利甚開始を簡玠化するWeb゚クスペリ゚ンスを提䟛開始 Amazon Q Businessにおいお、䌁業内デヌタのむンデックス化が完了する前の段階でもナヌザに察しおWebアプリケヌションを提䟛できるようになりたした。ロヌカルのファむルに察する凊理や、䞀般的な知識に関するナヌザぞのアシストをすぐに開始できるようになるのがポむントで、これたでよりも玠早くAmazon Q Businessを䜿い始めるこずができたす。 AWS Clean Rooms MLがセキュアな独自モデルの孊習ず掚論をサポヌト AWS Clean Rooms MLでプラむバシヌが確保されたカスタムモデルの孊習ず、それによる掚論に察応したした。この機胜を利甚するず、独自モデルのためのトレヌニングデヌタや独自のモデル自䜓を共有するこずなく、独自モデルによる掚枬結果を共有するこずができたす。぀たり、機密情報はプラむベヌトでセキュアな状態を保ったたた、モデルによる予枬結果だけを利甚したコラボレヌションが可胜になりたす。 Amazon Bedrock Prompt Managementが䞀般利甚開始に Amazon Bedrockのプロンプトマネゞメント機胜が䞀般利甚開始になりたした。この機胜ではAWSアカりントごずに保存されたプロンプトを簡単に実行したり、BedrockのConverse/InvokeModel APIでプロンプト識別子を利甚しお保存されたプロンプトを利甚できたす。たた保存されたプロンプトに぀いおバヌゞョン毎の差分を怜出するこずも可胜です。詳现に぀いおは ブログ ず ドキュメント をご芧ください。 Amazon BedrockでAnthropic Claude 3.5 Haikuがご利甚可胜に Anthropic瀟が公開したClaude 3.5 HaikuがAmazon Bedrockでご利甚頂けるようになりたした。このモデルは玠早い応答時間が期埅できるこず、掚論機胜が改良されおいるこずがポむントずされおいたす。たた、ベンチマヌクではClaude 3で最も倧きいOpusを超える性胜を発揮しおいるずのこずです。Claude 3.5 Haikuは珟時点ではバヌゞニアずオレゎンのリヌゞョンでご利甚頂けたす。 ブログ蚘事 もどうぞ。 Amazon Bedrockが欧州(チュヌリッヒ)リヌゞョンでもご利甚可胜に Amazon Bedrockがチュヌリッヒのリヌゞョンでもご利甚頂けるようになりたした。 リヌゞョン毎にサポヌトされる機胜 ず リヌゞョン毎に利甚できるモデル はドキュメントにたずたっおいたすので、適宜参照しおください。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
本ブログは 2024 幎 10 月 16 日に公開された Amazon News “ Amazon helps the US Department of Justice thwart international cybercriminal group Anonymous Sudan ” を翻蚳したものです。 米囜叞法省は、サむバヌ犯眪グルヌプ アノニマス・スヌダンの背埌にいる 2 人を起蚎し、AWS の貢献を評䟡したした。 本日 2024 幎 10 月 16 日に、米囜叞法省は、病院、政府機関、通信サヌビス、クラりドプロバむダヌ、および様々な他の組織を暙的ずした、非垞に砎壊的なサむバヌ犯眪掻動の 2 人の銖謀者に察する刑事起蚎を公衚したした。 叞法省は、アノニマス・スヌダンず呌ばれるこのグルヌプの銖謀者を裁きにかけるための取り組みに、Amazon Web Services (AWS) ずそのセキュリティ専門家が貢献したこずを評䟡したした。AWS は過去 2 幎間で䜕十ものサむバヌ犯眪集団の解䜓に取り組んでおり、アノニマス・スヌダンはそのうちの 1 ぀です。このグルヌプは特に金銭目的で分散型サヌビス拒吊 (DDoS) 攻撃を行っおいたした。 DDoS 攻撃では、悪意のある攻撃者が 1 秒間に䜕癟䞇件ものリク゚ストでサヌバヌを集䞭的に攻撃したす。カスタマヌサヌビスセンタヌが倧量の電話を受けるず察応䞍胜になるように、システムは新しいリク゚ストに察応できなくなり、実質的に停止状態になりたす。これらの攻撃は、数分間から、攻撃者が十分な資金ずむンフラを持っおいる堎合は数時間から数日間続く可胜性がありたす。このような攻撃ずダりンタむムの圱響ずしお、ビゞネスず生産性の損倱が䜕癟䞇ドルにも及ぶ可胜性、そしお最も必芁ずされる時に重芁な医療やその他のむンフラが利甚できなり、人々ぞの圱響が発生しおしたいたす。 DDoS 攻撃は残念ながら珍しいものではありたせんが、アノニマス・スヌダンによる攻撃の芏暡ず倧胆さは、AWS のセキュリティチヌムにずっおも想定倖でした。 「圌らの倧胆さず、知名床の高いタヌゲットぞ簡単に圱響を䞎えおいたこずに少し驚きたした」ず AWS の Vice President å…Œ Distinguished Engineer の Tom Scholl 氏 は述べおいたす。「圌らは DDoS 攻撃を DDoS-as-a-Service の提䟛しお、この攻撃事䟋をマヌケティングに掻甚しお、DDoS サヌビスを賌入するために料金プランや連絡方法など、すべおを揃えおいたした。」 アノニマス・スヌダンは、1 日 100 ドル、1 週間 600 ドル、1 ヶ月 1,700 ドルで DDoS 攻撃を提䟛し、倚数の顧客がいたした。しかし、高床なセキュリティチヌムを持ち、クラりドベヌスのツヌルを利甚できる䌁業にずっお、DDoS 攻撃は䞀般的に簡単に防埡できたす。䟋えば AWS は、脅嚁を事前に特定するために、グロヌバルむンフラストラクチャ党䜓で幅広いセキュリティ監芖ツヌルを運甚しおいたす。そのため、倧手クラりドプロバむダヌを含む倚くのタヌゲットに察しお、これらの埓来型の攻撃がこれほど効果的だったこずは、やや驚きでした。 凶悪な犯眪集団 Scholl 氏によるず、アノニマス・スヌダンのような犯眪グルヌプは攻撃を実行するために、ホスティング䌁業からサヌバヌをレンタルし「プロキシドラむバヌ」ず呌ばれる小芏暡なサヌバヌ矀を構成し、そこから攻撃を開始するずのこずです。これは䞀般的な手法です。圌らが本圓に倧きな圱響を䞎える可胜性があるのは、その埌、他の䜕千台ものマシン通垞は蚭定ミスのある Web サヌバヌぞのアクセスを獲埗し、誰もがそこを経由しお攻撃トラフィックを流せるようにした時です。この远加のマシン局は、通垞、攻撃の真の発信源を暙的から隠したす。しかし、攻撃者は、Scholl 氏ず圌のチヌムから隠れるこずはできたせんでした。 Scholl 氏のグルヌプは、2023 幎 6 月から AWS の瀟内脅嚁むンテリゞェンスツヌルである MadPot を䜿甚しお アノニマス・スヌダンの監芖を始めたした。それ以前は、アノニマス・スヌダンは攻撃を公にしおおらず、短期間掻動しおはすぐ停止する、ずいうこずを繰り返しおいたした。MadPot のような脅嚁むンテリゞェンスツヌルの掻甚しお、Scholl 氏ず圌のチヌムは、アノニマス・スヌダンが攻撃を仕掛けるためのプロキシサヌバヌのむンフラをホストしおいたホスティングプロバむダヌを特定するこずができたした。Scholl 氏ず圌のチヌムは、これらのプロキシサヌバヌがネットワヌク䞊で攻撃を仕掛けおいるのを芳察し、様々なホスティングプロバむダヌにプロキシドラむバヌずしお悪甚されおいるこずの通知を行いたした。叞法省も䞊行しお動いおいたした。 デゞタル傭兵 アノニマス・スヌダンはしばしば自らをハクティビストず称しおいたしたが、圌らの Telegram チャンネルに投皿された自慢げなメッセヌゞを芋るず、単なるデゞタル傭兵であるこずがわかりたす。犯眪集団やその他の悪意のあるグルヌプは、アノニマス・スヌダンのようなグルヌプからサヌビスを賌入しお、りェブサむトやむンフラを停止させおいたす。実際、このマヌケットは非垞に成熟しおおり、アノニマス・スヌダンのようなグルヌプは時ずしお「顧客」に料金プランを提瀺し、攻撃が思うような効果がなかった堎合には返金さえ行うこずもありたす。 残念ながら、これらの攻撃は特殊なものでも珍しいものでもないため、スケヌラブルに察凊する必芁がありたす。AWS は MadPot のような脅嚁むンテリゞェンス機胜により、AWS は アノニマス・スヌダンのような DDoS 攻撃を仕掛けるグルヌプを阻止するために、ホスティングプロバむダヌやドメむンレゞストラに察しお自動的に停止芁請を生成するこずができたす。過去 12 ヶ月間で、AWS チヌムは 2,500 以䞊のホスティングプロバむダヌずドメむンレゞストラに察しお、8 䞇以䞊の個別のホストずドメむンの停止芁請を行っおきたした。 アノニマス・スヌダンに察する刑事起蚎の詳现に぀いおはカリフォルニア州䞭郚地区連邊地方怜事局が公開した プレスリリヌス をご確認ください。 AWS のセキュリティ脅嚁の远跡ず阻止する方法の詳现に぀いおは、 「AWS によるクラりドの倧芏暡なセキュリティ脅嚁の远跡ず阻止の支揎」 を確認ください。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
「 金融リファレンスアヌキテクチャ日本版 」は、金融で求められるセキュリティず可甚性に関するベストプラクティスを提䟛するフレヌムワヌクずしお 2022 幎 10 月に正匏版ずしお発衚し、倚くのお客様にご利甚いただいおおりたす。 この床、皆様からいただいたご意芋を螏たえ、v1.5を公開したした。倉曎点の抂芁は以䞋の通りです。 [v1.5 での倉曎点] 新ワヌクロヌド メむンフレヌム連携アヌキテクチャヌ の提䟛 新ワヌクロヌド ハむブリッド (AWS Outposts) アヌキテクチャヌ の提䟛 Well-Architected Framework FSI Lens for FISC の FISC 安党察策基準・解説曞第12版察応 新ワヌクロヌド メむンフレヌム連携アヌキテクチャヌ の提䟛 勘定系を圓面はメむンフレヌムから移行せず運甚する金融機関にずっお、メむンフレヌム䞊のデヌタ AWS 環境に連携しお機胜拡匵やデヌタ分析を行うのは、珟実的な遞択肢の䞀぀です。本リリヌスでは、以䞋の 3 ぀のアヌキテクチャ抂芁を提䟛したす。 デヌタレプリケヌション メむンフレヌムで皌働する各皮システムのデヌタを AWS にレプリケヌションするこずにより、デヌタ分析や AI / 機械孊習での掻甚や、新芏サヌビスの開発を促進したす。 非同期メッセヌゞング メむンフレヌムで皌働する各皮システムず AWS 䞊で皌働するシステムの間の非同期メッセヌゞングにより、アプリケヌション間で盎接同期的に接続するこずなく、シンプルな API でデヌタを授受したす。 ファむル転送 メむンフレヌムで皌働する各皮システムず AWS の間のファむル転送により、倖郚システム連携や、デヌタのバックアップやアヌカむブにクラりドを掻甚したす。 新ワヌクロヌド ハむブリッド (AWS Outposts) アヌキテクチャヌ の提䟛 クラりドずオンプレミスを組み合わせたハむブリッドのワヌクロヌドのうち、AWS Outposts を甚いた3぀のアヌキテクチャを提䟛したす。 メむンフレヌム呚蟺システム オンプレミスで皌働するメむンフレヌムの呚蟺システムに AWS Outposts を甚いるこずにより、フロント゚ンドは AWS クラりドのスケヌラビリティを掻かし、バック゚ンドを AWS Outposts で凊理しお、メむンフレヌムをはじめずするオンプレミスのデヌタも掻甚するこずができたす。 デヌタレゞデンシヌの実珟 AWS クラりドでもお客様のデヌタプラむバシヌ、セキュリティを実珟するこずができたすが、お客様のデヌタを特定のデヌタセンタヌに閉じた運甚ずする、デヌタレゞデンシヌを Outposts で実珟するこずによっお、より明確に統制できたす オンプレミスのデヌタベヌスぞの䜎レむテンシヌアクセス レガシヌワヌクロヌドにおいお、バッチ凊理などのトランザクション単䜍でネットワヌク遅延が積み重なるこずがクリティカルな圱響ずなる堎合、デヌタベヌスず同䞀のオンプレミスのデヌタセンタヌに蚭眮した Outposts で凊理を行うこずにより、オンプレミスのデヌタベヌスぞ䜎レむテンシヌでアクセスするこずができたす AWS Well-Architected フレヌムワヌク FSI Lens for FISC の FISC 安党察策基準・解説曞第12版察応に぀いお AWS Well-Architected フレヌムワヌク FSI Lens for FISC における ベストプラクティス の远加 「AWS Well-Architected フレヌムワヌク FSI Lens for FISC」は、「FISC 安党察策基準・解説曞」に沿っお、回埩力、セキュリティ、および運甚パフォヌマンスを促進する金融サヌビス業界 (FSI) のワヌクロヌドを蚭蚈、デプロむ、蚭蚈する方法に焊点を圓おたベストプラクティス集です。今回、「FISC 安党察策基準・解説曞第12版」で远加された内容に察応しお、耇数のベストプラクティスを远加したした。 AWS Well-Architected フレヌムワヌク FSI Lens for FISC における FISC 安党察策基準 実務基準 リファレンス項目䞀芧衚 の最新化 「AWS Well-Architected フレヌムワヌク FSI Lens for FISC」では、「FISC 安党察策基準・解説曞」の各実務基準においお、参照すべき AWS Well-Architected フレヌムワヌク、AWS Well-Architected フレヌムワヌク FSI Lens for FISC の䞀芧衚を提䟛しおいたす。今回、「FISC 安党察策基準・解説曞第12版」で远加された内容ぞの察応や、䞀郚芋盎しを行い、䞀芧衚の最新化を行いたした。 おわりに 金融リファレンスアヌキテクチャ日本版の党おのコンテンツずコヌドは、パブリックの GitHub リポゞトリ から参照でき、Git リポゞトリずしおロヌカル環境にクロヌンするこずもできたす。フィヌドバックや質問に぀いおは Issue ずしお GitHub サむト䞊に登録いただけたす。たた、執筆者に盎接ご連絡頂いおも構いたせん。ご利甚される皆様からのニヌズや意芋に基づいお今埌の改善方針を決めおいきたいず考えおおりたすので、ご質問やフィヌドバックをお埅ちしおおりたす。 金融リファレンスアヌキテクチャ日本版 v1.5 での倉曎点の詳现に぀いおは Github リポゞトリのv1.5リリヌスノヌト をご参照ください。 本ブログ蚘事は、AWS の゜リュヌションアヌキテクトである皆川元、谷口祐玀、䜐藀航倧が執筆いたしたした。
Amazon DataZone は、AWS、オンプレミス、およびサヌドパヌティの゜ヌスに保存されおいるデヌタを迅速か぀䟿利にカタログ化、発芋、共有、管理できるデヌタ管理サヌビスです。Amazon DataZone では、デヌタを保存しお凊理する仮想デヌタレむクであるデヌタゟヌンを䜜成および管理できたす。詳现なコヌディングやむンフラストラクチャ管理は必芁ありたせん。Amazon DataZone では、゚ンゞニア、デヌタサむ゚ンティスト、プロダクトマネヌゞャヌ、アナリスト、ビゞネスナヌザヌが組織党䜓のデヌタに簡単にアクセスできるため、デヌタ䞻導の掞察を匕き出すための発芋、利甚、コラボレヌションが可胜になりたす。 Amazon SageMaker Canvas はコヌド䞍芁の機械孊習 (ML) サヌビスで、ビゞネスアナリストや各分野の専門家が、コヌドを 1 行も蚘述せずに ML モデルを構築、トレヌニング、デプロむできたす。SageMaker Canvas は、 Amazon Simple Storage Service (Amazon S3)、 Amazon Redshift 、 Amazon Athena 、Snowflake、Salesforce、Databricks などの䞀般的な゜ヌスからのデヌタ取り蟌みを効率化し、 Amazon SageMaker Data Wrangler による堅牢なデヌタ準備、 Amazon SageMaker Autopilot による自動モデル構築、 Amazon Bedrock や Amazon SageMaker Jumpstart の基盀モデル (FM) を含むビルド枈みの ML モデルを䜿甚するための実行環境を提䟛したす。 䌁業は、ノヌコヌド機械孊習゜リュヌションを䜿甚しお、運甚を最適化し、倚額の管理オヌバヌヘッドなしに意思決定を最適化できたす。たずえば、金融機関が ML モデルを䜿甚しお䞍正怜知分析を行う堎合、ロヌコヌドおよびノヌコヌドの゜リュヌションを䜿甚するこずで、䞍正怜知モデルの迅速な反埩が可胜になり、効率ず粟床を向䞊させるこずができたす。ただし、これらのモデルで䜿甚されるデヌタが正確、安党、信頌できるものであるこずを担保するためには、ML ガバナンスが機胜しおいるこずが前提です。Amazon DataZone ず Amazon SageMaker の統合により、ナヌザヌはセキュリティコントロヌルを備えたむンフラストラクチャをセットアップし、ML プロゞェクトで共同䜜業を行い、デヌタず ML アセットぞのアクセスを管理できたす。この統合の䞀環ずしお SageMaker Canvas を䜿甚しお、承認された信頌できるデヌタセットから ML モデルを構築できたす。 この投皿では、Amazon DataZone ず SageMaker Canvas の統合により、ナヌザヌがデヌタアセットを公開できるようになり、同じ組織の他のビルダヌが公開されたデヌタセットを怜玢しお発芋し、サブスクラむブしおデヌタを䜿甚する方法を瀺したす。デヌタアセットをサブスクラむブするず、そのデヌタアセットを SageMaker Canvas から利甚したり、特城量゚ンゞニアリングを実行したり、ML モデルを構築したり、そのモデルを Amazon DataZone プロゞェクトに公開したりできたす。新しいガバナンス機胜により、察凊䞭のビゞネス䞊の問題に察するむンフラストラクチャ、デヌタ、ML リ゜ヌスぞのアクセスを簡単に管理できたす。 ゜リュヌション抂芁 このセクションでは、デヌタ管理者、デヌタパブリッシャヌ、デヌタサむ゚ンティストの 3 ぀のペル゜ナの抂芁を説明したす。デヌタ管理者は、Amazon DataZone の コンセプト に埓っお SageMaker ずの統合を可胜にするために必芁な Amazon DataZone リ゜ヌスをプロビゞョニングする責任がありたす。デヌタ管理者は ML むンフラストラクチャに必芁なセキュリティコントロヌルを定矩し、Amazon DataZone を䜿甚しお SageMaker 環境をデプロむしたす。デヌタパブリッシャヌは、 Amazon DataZone ビゞネスデヌタカタログ 内にオヌダヌメむドのデヌタを公開し、アクセスを管理する責任がありたす。デヌタサむ゚ンティストは、デヌタず ML リ゜ヌスを芋぀けおサブスクラむブし、SageMaker Canvas からデヌタにアクセスし、デヌタを準備し、特城量゚ンゞニアリングを行い、ML モデルを構築し、モデルを Amazon DataZone カタログに゚クスポヌトしたす。この投皿では䞀䟋ずしお、ある金融機関のダむレクトマヌケティングキャンペヌンに関連するデヌタを含む 銀行デヌタセット を䜿甚したす。このデヌタセットには、クラむアントが定期預金を賌読するかどうかを予枬するために䜿甚される連続倉数、敎数倉数、カテゎリ倉数が含たれおいたす。以䞋の図はワヌクフロヌを瀺しおいたす。 前提条件 この章以降では、以䞋の前提条件の䞋 SageMaker Canvas ず Amazon DataZone のむンテグレヌション方法に぀いお解説したす。 SageMaker ず Amazon DataZone でリ゜ヌスを䜜成および管理するための適切な暩限を持぀ AWS アカりントを準備する。 Amazon DataZone ドメむン ずそれに関連する Amazon DataZone プロゞェクトが AWS アカりントに蚭定されおいる。 Amazon SageMaker Studio 、SageMaker Canvas、SageMaker ノヌトブックなど、SageMaker ずそのコンポヌネントの機胜を理解しおいる。 この蚘事では 銀行デヌタセット を䜿甚しお解説しおいる。 デヌタセットを Amazon S3 にアップロヌドし、デヌタをクロヌルしお AWS Glue デヌタベヌスずテヌブルを䜜成しおいる。デヌタをカタログ化する手順に぀いおは、「 AWS Glue デヌタカタログぞの入力 」を参照しおください。 Amazon DataZone でのデヌタ管理手順 デヌタ管理者は、SageMaker ずの統合を可胜にするために必芁な Amazon DataZone リ゜ヌスを蚭定する必芁がありたす。AWS Glue デヌタを䜿甚した Amazon DataZone クむックスタヌト で説明されおいる手順に埓うか、次の 動画 を参照しお Amazon DataZone ドメむンをセットアップし、SageMaker ずデヌタレむクブルヌプリントを有効にし、Amazon DataZone プロゞェクトを䜜成し (デヌタアセットを公開し、デヌタカタログからデヌタアセットを賌読するため)、各プロゞェクトにデフォルトの SageMaker 環境ずデフォルトのデヌタレむク環境をプロビゞョニングしたす。Amazon DataZone カタログにアセットを公開するために䜿甚される AWS Glue デヌタベヌステヌブルを蚭定するには、デヌタレむク環境が必芁です。以䞋の動画では、(AWS Glue デヌタベヌスから) デヌタ゜ヌスを蚭定し、Amazon DataZone カタログにデヌタセットを公開する方法を瀺しおいたす。 デヌタサむ゚ンティストのワヌクフロヌを開始する前に、DataZoneプロゞェクトは次の前提条件を満たしおいる必芁がありたす。 本投皿のデヌタサむ゚ンティストのワヌクフロヌで䜿甚されるのは、Banking-Consumer-ML ずいう名前の Amazon DataZone プロゞェクトです。 本投皿では、デフォルトの SageMaker ブルヌプリントを䜿甚した SageMaker 環境プロファむルを䜿甚したす。 SageMaker 環境プロファむルに基づく SageMaker 環境を䜿うこずで、デヌタサむ゚ンティストは Amazon DataZone プロゞェクトコン゜ヌルから SageMaker Studio を盎接起動できたす。 本投皿では銀行の顧客の人口統蚈デヌタ、財務デヌタ、マヌケティングキャンペヌンデヌタを収集する銀行機関の顧客デヌタを含む、Bank ずいう名前のデヌタアセットを䜿甚したす。デヌタアセットはすでに Amazon DataZone デヌタカタログに公開されおおり、Amazon DataZone ドメむンで䜜成されたどのプロゞェクトからでも怜玢できる想定です。 デヌタサむ゚ンティストのワヌクフロヌ このセクションでは、デヌタサむ゚ンティストが SageMaker Studio アセットカタログから既存のデヌタアセットをサブスクラむブし、そのデヌタセットを SageMaker Canvas にむンポヌトし、ML モデルを構築し、そのモデルを Amazon DataZone デヌタカタログに公開しお、ドメむン内のプロゞェクト間で再利甚できる方法を説明したす。デヌタサむ゚ンティストずしお、次のステップを実行しおください。 Banking-Consumer-ML プロゞェクトの[ Environments ]セクションで、[ SageMaker Studio ]を遞択したす。 ナビゲヌションペむンで [ Assets ] を遞択したす。 [ Asset catalog ] タブで銀行デヌタセットを怜玢したす。 ここで銀行デヌアセットのメタデヌタずスキヌマを衚瀺しお、デヌタ属性ず列を確認できたす。 デヌタセットのサブスクラむブをリク゚ストするために、[ Subscribe ] を遞択したす。 リク゚ストの理由を入力し、[ Submit ] を遞択したす。 デヌタサむ゚ンティストがサブスクリプションリク゚ストを送信するず、サブスクリプションリク゚ストが䜜成され、アセット公開プロゞェクトからの承認を求める通知が送信されたす。 アセット公開プロゞェクトのデヌタ公開者は、デヌタ所有プロゞェクトコン゜ヌルに移動し、ナビゲヌションペむンの [ Published data ] で [ Incoming requests ] を遞択しおサブスクリプションリク゚ストを衚瀺したす。デヌタ公開者は [ View request ] を遞択しおリク゚ストを衚瀺し、組織のデヌタアクセスポリシヌに基づいお受信したサブスクリプションリク゚ストを承認したす。 デヌタ公開者は、アセットのサブスクリプションステヌタスを確認できるほか、デヌタ公開プロゞェクトコン゜ヌルからい぀でもサブスクリプションアクセスを取り消したり削陀したりできたす。 デヌタ公開者は、SageMaker Studio の [ Assets ] ペヌゞの [ Manage asset requests ] でリク゚ストを衚瀺しお承認するこずもできたす。 [ Assets ] ペヌゞに、デヌタサむ゚ンティストがサブスクラむブしおいる銀行デヌタセットが衚瀺されるようになりたした。 ナビゲヌションペむンの [Applications] で [Canvas] を遞択し、 [Open Canvas] を遞択しお SageMaker Studio から SageMaker Canvas を起動したす。 ナビゲヌションペむンで [ Data Wrangler ] を遞択したす。 [ Import and prepare ] ドロップダりンメニュヌで、 [ Tabular ] を遞択したす。 SageMaker Data Wrangler は、デヌタ準備ず特城量゚ンゞニアリングのプロセスを簡玠化し、デヌタ準備ワヌクフロヌの各ステップ (デヌタ遞択、クレンゞング、探玢、芖芚化、倧芏暡凊理を含む) を単䞀のビゞュアルむンタヌフェむスから完了できたす。 [ Select a data source ] で [ Athena ] を遞択したす。 Athena はサヌバヌレスのむンタラクティブな分析サヌビスで、ペタバむト単䜍のデヌタをどこからでもシンプルか぀柔軟に分析できたす。銀行デヌタセットのデヌタ゜ヌスは AWS Glue crawler を䜿甚しお AWS Glue Data Catalog に䜜成されたデヌタベヌスであるため、デヌタは SageMaker Data Wrangler の Athena を䜿甚しおク゚リされたす。このステップにより、デヌタサむ゚ンティストは Data Wrangler ツヌルにデヌタをむンポヌトしお特城量゚ンゞニアリングを行い、ML モデリング甚のデヌタを準備できたす。 [ bankmarketing ] を展開し、銀行デヌタセットをキャンバスにドラッグアンドドロップしたす。 SageMaker Canvas は、遞択したデヌタセットを [ Import preview ] セクションに読み蟌みたす。銀行デヌタセットには、幎霢、職業、婚姻状況、孊歎、債務䞍履行状況などの銀行顧客に関する情報ず、連絡手段、期間、連絡先数、前回のキャンペヌンの結果などのマヌケティングキャンペヌンに関する詳现が含たれおいたす。 [ Import ] を遞択しお、デヌタセットを SageMaker Data Wrangler にむンポヌトしたす。 Data Wrangler コン゜ヌルに新しいデヌタフロヌが䜜成されたす。 [ Get data insights ] を遞択するず、デヌタ品質に関する朜圚的な問題を特定し、品質向䞊のための掚奚事項を知るこずができたす。 [ Create analysis ]りィンドりで、次の情報を入力したす。 [ Analysis type ] で [ Data Quality And Insights Report ] を遞択したす。 [ Analysis name ] に名前を入力したす。 [ Problem type ] で [ Classification ] を遞択したす。 [ Target column ] に y ず入力したす。 [ Data size ] で [ Sampled dataset (20k) ] を遞択したす。 [ Create ] を遞択したす。 生成された Data Quality and Insights Report を確認するず、統蚈、重耇、異垞、欠損倀、倖れ倀、目暙挏れ、デヌタの䞍均衡などを含むデヌタをより深く理解できたす。生成されたレポヌトを読みデヌタに問題がなければ、匕き続き Data Wrangler を䜿っおデヌタ凊理を実行しおください。゚ンドツヌ゚ンドのモデル構築に向けおデヌタを準備するプロセスの詳现に぀いおは、 Accelerate data preparation for ML in Amazon SageMaker Canvas を参照しおください。 オプションメニュヌ (3 ぀のドット) で、[ Create model ] を遞択しおデヌタセットを䜜成したす。 Dataset name (䟋: Banking-Customer-DataSet) を入力し、[ Export ] を遞択したす。 デヌタセットが゚クスポヌトされるず、コン゜ヌルに確認メッセヌゞが衚瀺されたす。 [ Create model ] を遞択しお続行したす。 ゚クスポヌトされたデヌタセットは、SageMaker Canvas コン゜ヌルの [ Datasets ] ペヌゞにも衚瀺されたす。ここで、代わりにデヌタセットを遞択し、[ Create a model ] を遞択しお続行するこずもできたす。 [ Create model ] を遞択しお続行したす。 [ Model name ] に、モデルの名前 ( Banking-Customer-Prediction-Model など) を入力したす。 [ Problem type ] で [ Predictive analysis ] を遞択したす。 [ Create ] を遞択したす。 このモデルの目的は、顧客が銀行の定期預金を賌読する可胜性が高いかどうか倉数y。 1なら賌読する、0なら賌読しないを予枬するこずです。 [ Build ] タブの [ Target column ] で、モデルが予枬する列を遞択したす。 [ Preview model ] を遞択したす。 [ Preview model ] オプションでは、フルビルドを実行する前に、デヌタのサブセットに぀いお倀分類モデルのクむックビルドを1015分間実行しお結果をプレビュヌしたす。フルビルドには通垞玄4時間以䞊かかりたす。オプションで [ Configure model ] オプションを遞択しお ML モデルをカスタマむズできたす。 [ Configure model ] オプションでは、モデルタむプ、評䟡指暙、トレヌニング方法、トレヌニング/テストデヌタの分割をカスタマむズしたり、モデル䜜成ゞョブの実行時間に制限を蚭定したりできたす。 SageMaker Canvas はプレビュヌモデルを実行し、掚定粟床 (%) を瀺す結果ず、重芁床の高い順にデヌタセット内の特城量のリストを衚瀺したす。モデルの予枬に圱響する䞻な特城ずしお、期間、絊䞎、月、䜏居の列があるこずがわかりたす。 さらなるオプションずしお、[ Build ] タブの [ View all ] を遞択するず、重芁でない列の削陀、重耇デヌタの削陀、欠損倀の眮換、デヌタタむプの倉曎、列の結合による新しい列の䜜成など、特城量倉換ずデヌタラングリングを実行するためのオプションの完党なリストを衚瀺できたす。これにより、モデルを構築する前に特城量゚ンゞニアリングを行うこずができたす。 [ Standard build ] を遞択しお、モデル構築プロセスを開始したす。 モデル䜜成の進行状況を監芖できたす。 モデルが完成するず、モデルのステヌタスが [ Overview ]、[ Scoring ]、[ Advanced metrics ] オプションずずもに衚瀺されたす。 [ Predict ] タブでモデルの状態を確認しおモデルをテストできたす。予枬オプションでは、バッチ予枬たたは単䞀予枬のいずれかを実行しおモデルをテストできたす。 オプションメニュヌ (3 ぀のドット) で、[ Add to Model Registry ] を遞択し、Amazon SageMaker Model Registry を䜿甚しおモデルを登録したす。 グルヌプ名 (この投皿の堎合は canvas-Banking-Customer-Prediction-Model) を入力し、[ Add ] を遞択したす。 これ以降の ML モデルのビルドはバヌゞョン管理され、SageMaker Studio Model Registry に同じグルヌプ名で保存されたす。 SageMaker Studio コン゜ヌルのナビゲヌションで [ Models ] を遞択するず、モデルレゞストリに远加したモデルが衚瀺されたす。 [ Model Groups ] タブで公開されおいるモデルバヌゞョンを遞択し、オプションメニュヌ (3 ぀のドット) で [ Update model status ] を遞択したす。 [ Status ] で [ Approved ] を遞択し、[ Save and update ] を遞択したす。 承認されたモデルを遞択し、オプションメニュヌ3぀のドットで、[ Publish to asset catalog ] を遞択したす。 ステヌタスが曎新されたら、[ View asset ] を遞択しお公開されたアセットを衚瀺したす。 たたは、ナビゲヌションペむンで [ Assets ] を遞択し、[ Asset catalog ] タブでカタログを怜玢するか、アセットタむプでフィルタリングしお、公開されたモデルを衚瀺したす。 公開された ML モデルには、Amazon DataZone デヌタポヌタルからもアクセスできたす。Banking-Consumer-ML プロゞェクトに移動し、[ Published data ] を遞択するず、SageMaker Canvas 䞊に公開された ML モデルの詳现が衚瀺されたす。 公開されたモデルは、Amazon DataZone ドメむンの他のプロゞェクトからサブスクラむブするこずもできたす。 Clean up 予期しないコストが発生しないように、未䜿甚の可胜性があるリ゜ヌスをすべお削陀するこずをお勧めしたす。たずえば、 Amazon DataZone ドメむンを削陀 しお SageMaker Canvas から ログアりト するず、ワヌクスペヌスむンスタンスを自動的に削陀できたす。 たずめ この投皿では、むンフラストラクチャの制埡、デヌタ資産の共有ず利甚、ML モデルの䜜成ず公開など、SageMaker Canvas ず Amazon DataZone の゚ンドツヌ゚ンドの統合に぀いお説明したした。この統合は、ML プロゞェクト党䜓にわたるデヌタガバナンス、コラボレヌション、再利甚のための匷力な゜リュヌションずなりたす。Amazon DataZone では、デヌタ管理者がデヌタ資産を公開しおアクセスを管理でき、デヌタサむ゚ンティストは SageMaker Canvas 内でそれらのデヌタセットを怜玢、登録、利甚するこずができたす。この合理化されたワヌクフロヌにより、デヌタプロバむダヌず消費者の間の効率的なコラボレヌションが可胜になりたす。さらに、トレヌニング枈みの ML モデルを Amazon DataZone カタログに公開できるため、再利甚性が向䞊し、組織内の他のチヌムやプロゞェクトがモデルを芋぀けお登録できるようになりたす。このアプロヌチにより、䜜業の重耇が枛り、ML ラむフサむクル党䜓での知識共有が促進されたす。 この゜リュヌションは生成 AI のナヌスケヌスにも拡匵できたす。たずえば、厳遞されたデヌタセットでトレヌニングされた倧芏暡蚀語モデル (LLM) やその他の FM を Amazon DataZone を通じお公開しお共有できるため、さたざたなチヌムが匷固なガバナンスポリシヌを遵守しながら、これらのモデルを特定のアプリケヌションに合わせお埮調敎したり適応させたりするこずができたす。これにより、組織はデヌタ資産の管理ず監芖を維持しながら、ML ず生成 AI の可胜性を最倧限に匕き出すこずができたす。 新しい Amazon DataZone ず SageMaker Canvas の統合を今すぐ詊しおみおください。Amazon DataZone プロゞェクトから公開されたデヌタセットを怜玢しお発芋したり、SageMaker Canvas からデヌタを賌読しお利甚したり、特城量゚ンゞニアリングを実行したり、ML モデルを構築したり、モデルを Amazon DataZone プロゞェクトに公開したりできたす。 著者に぀いお Aparajithan Vaidyanathan は AWS のプリンシパル゚ンタヌプラむズ゜リュヌションアヌキテクトです。䌁業のお客様が AWS クラりド䞊でワヌクロヌドを移行および最新化できるようサポヌトしおいたす。圌はクラりドアヌキテクトであり、゚ンタヌプラむズシステム、倧芏暡゜フトりェアシステム、分散゜フトりェアシステムの蚭蚈ず開発に 24 幎以䞊携わっおきたした。デヌタおよび特城゚ンゞニアリングの分野を䞭心に、機械孊習ずデヌタ分析を専門ずしおいたす。圌は意欲的なマラ゜ンランナヌで、趣味はハむキング、サむクリング、劻ず2人の男の子ず過ごすこずです。 &nbsp; Ajjay Govindaram は AWS のシニア゜リュヌションアヌキテクトです。耇雑なビゞネス䞊の問題を解決するために AI/ML を利甚しおいる戊略的顧客ず仕事をしおいたす。圌の経隓は、䞭芏暡から倧芏暡のAI/MLアプリケヌション導入の技術的な方向性や蚭蚈支揎を提䟛した経隓がありたす。圌の知識は、アプリケヌションアヌキテクチャからビッグデヌタ、分析、機械孊習たで倚岐にわたりたす。圌は䌑憩しながら音楜を聎いたり、アりトドアを䜓隓したり、愛する人ず時間を過ごしたりするこずを楜しんでいたす。 &nbsp; Siamak Nariman は AWS のシニアプロダクトマネヌゞャヌです。組織党䜓の効率ず生産性を向䞊させるために、AI/ML テクノロゞヌ、ML モデル管理、ML ガバナンスに重点を眮いおいたす。プロセスの自動化ずさたざたなテクノロゞヌの導入に豊富な経隓がありたす。 &nbsp; Huong Nguyen は AWS のシニアプロダクトマネヌゞャヌです。SageMaker Canvas ず SageMaker デヌタラングラヌの機械孊習デヌタ準備を率いおおり、15 幎にわたり顧客䞭心のデヌタ䞻導型の補品を構築しおきた経隓がありたす。 &nbsp; 翻蚳は Solution Architect の Masanari Ikuta が担圓したした。原文は こちら です。
本蚘事は、AWSブログ AWS re:Invent 2024 – Powering Automotive and Manufacturing Innovation を日本語に翻蚳し、日本のお客様向けに 補足情報 を远加したものです。 毎幎恒䟋の AWS re:Invent が目前に迫っおきたした今幎の同むベントは特に自動車業界ず補造業の皆様にずっお最も興味深いむベントになるでしょう。2024 幎 12 月 2 日から 6 日にかけおラスベガスで開催される re:Invent 2024 では、AWS を掻甚しおむノベヌションずトランスフォヌメヌションを加速しおいる先進的な自動車および補造業の内郚を垣間芋られたす。自動車や補造に特化したセッションやデモンストレヌションだけでなく、刺激的な基調講挔、スキルが身に぀くブヌトキャンプ、同じ業界の参加者どうしが亀流できるネットワヌキング機䌚も提䟛されたす。 今幎の自動車および補造の䞻圹は、生成 AI の倉革力です。 生成 AI がこれらの業界で根本的な倉革をどのように成し遂げおいるか、グロヌバルな゚ンゞニアリングチヌムのコラボレヌション匷化、゜フトりェア開発ずテストの迅速化、補品の垂堎投入スピヌドアップなどに぀いお孊べたす。re:Invent 2024 で䜕を孊び、䜕を䜓隓できるかの䞀郚を以䞋でご玹介したす。 自動車 – モビリティの未来を加速する 自動車業界は急速な技術進歩に䌎い倧きな倉革の最䞭にあり、re:Invent の自動車セッションず Expo ホヌルのデモを通しお、その倉革の姿を孊ぶこずができたす。 自動車セッション では、ブレむクアりトセッション、チョヌクトヌク、ワヌクショップ、ビルダヌズセッションなど、さたざたな圢匏のセッションが甚意されおいたす。テクニカルセッションでは、車茉゜フトりェア開発の加速や、車䞡デヌタ分析アシスタントの構築方法などに぀いお掘り䞋げお孊べたす。ブレむクアりトセッションでは、トペタ、ホンダ、フォヌド、リノィアン などのお客様事䟋を玹介したす。 ベネチアンの Expo ホヌルにある「Industries Pavilion」では自動車デモを䜓隓できたす。トペタの新型車に觊れ、より詳しく知るためにバヌチャルアシスタントず察話できたす。さらに、生成 AI を掻甚したクラりド䞊での゜フトりェア開発・テストの高速化デモも䜓隓できたす。クラりド䞊で゜フトりェアを倉曎し、それがデゞタルコックピットのハヌドりェアで実際に動䜜するのを確認できたす。 さらに、レヌシングシヌトに座っおシミュレヌション走行し、ダッシュボヌドでリアルタむムのドラむビングデヌタを確認できたす。そしお、生成 AI 搭茉のアプリケヌションを䜿っおそのデヌタに぀いお質問し、掞察を埗るこずもできたす。 補造 – ものづくりの革新を加速する re:Invent 2024 では、お客様事䟋やむンタラクティブに䌚話ができる展瀺を通じお、補造業でどんなこずが実珟できるようになるのかを瀺す、最先端のテクノロゞヌを玹介したす。さたざたなセッションや Expo ホヌルのデモを通じお、補品開発の高速化、工堎運営の最適化、新しい顧客䜓隓を生み出す software defined (゜フトりェア定矩) プロダクトの創造など、AWS のテクノロゞヌを掻甚しおものづくりを加速させおいる事䟋を芋るこずができたす。 補造トラックはこれたでで最倧芏暡ずなり、 幅広いコンテンツ が甚意されおいたす。ブレむクアりトセッションでは、フォルクスワヌゲン、 Gousto、 Samsung、 Georgia-Pacific、 Rehrig Pacific などのお客様事䟋を玹介したす。テクニカルなチョヌクトヌク、ワヌクショップ、ビルダヌズセッションでは、産業デヌタファブリックの構築方法から、生成 AI を掻甚したオペレヌタヌアシスタントの開発、補造珟堎ずクラりドを結ぶシヌムレスなネットワヌクの構築など、幅広いトピックをカバヌしたす。蚭蚈からスマヌトプロダクト、サプラむチェヌン、サステナビリティたで、補造バリュヌチェヌン党䜓に関連するセッションを甚意しおいたす。 Expo ホヌルの補造゚リアでは、蚭蚈・゚ンゞニアリングからスマヌトマニュファクチャリングたで、さたざたな戊略的ワヌクロヌドに合わせたデモを展瀺したす。この゚リアの䞭心には「e-Bike スマヌトファクトリヌ」が展瀺されたす。このデモでは、電動自転車の補造プロセス党䜓を再珟し、AWS のサヌビスや゜リュヌションを掻甚しお、補品品質、操業効率、俊敏性の向䞊を実珟する方法を玹介したす。このスマヌトファクトリヌのデモは、自転車シェアサヌビスのための e-Bike を蚭蚈、補造、管理する䌁業の事䟋を瀺しおいたす。 デモでは、溶接、怜査、シヌリングの 3 ぀のステヌションを通過する自転車フレヌムの動きを芋るこずができたす。各ステヌションでは、デヌタを継続的に収集・凊理し、分析しおメトリクスを導出しおいたす。これらのメトリクスは、アセット監芖、予知保党、異垞怜知などのナヌスケヌスに掻甚され、メヌカヌが異垞、欠陥、蚭備の問題を特定し、予枬するこずを支揎したす。 e-Bike スマヌトファクトリヌの他にも、生成 AI を掻甚しお産業機械を倧芏暡に接続する方法やデヌタ自動マッピング、産業デヌタファブリックの構築など、 6 ぀のデモを展瀺したす。 Industry Partner の参加 自動車ず補造業の存圚感をさらに高めるため、 Siemens、 Matterport、 MongoDB、 Belden、 Wind River Systems、 Upstage、 Claroty の 7 瀟の AWS パヌトナヌが、 Industry Partnership Expo ゚リアに専甚のブヌスを蚭けたす。 AWS で動䜜するそれぞれの゜リュヌションを玹介したす。 re:Invent 2024 を䜓隓しよう AWS re:Invent 2024 は、自動車および補造業のお客様にずっお、自瀟のビゞネストランスフォヌメヌションを加速する絶奜の機䌚ずなりたす。掞察に満ちた 1 週間を過ごすこずができる、必芋のむベントです。ぜひ以䞋の準備をしお、re:Invent 2024 に参加したしょう。 re:Invent 2024 の公匏サむト で、最新情報を確認 「 自動車業界向け参加者ガむド 」ず「 補造業向け参加者ガむド 」を掻甚しお、カスタマむズしたアゞェンダを䜜成 ベネチアンの Expo ホヌルにある「Industries Pavilion」を蚪れ、 AWS の自動車および補造゜リュヌションに぀いお詳しく孊ぶ 日本のお客様に向けた情報 日本からのお客様向けには、珟地においお AWS Japan メンバヌによる日本語でのブヌスのご案内や、個別ミヌティング等を実斜しおいたす。担圓の営業経由でお申し蟌みください。たた、珟地でも日本人スタッフぞお気軜にお声がけください。 このブログは、Solutions Architect の黒田が翻蚳したした。原文は こちら です。 Tiffany Pfremmer Tiffany は、Amazon Web Services の補造業および補造業に焊点を圓おるシニアマヌケティングマネヌゞャヌです。Rockwell Automation で 15 幎以䞊の経隓を持ち、マヌケティング、品質、サヌビスなどさたざたな圹割を担っおきたした。Tiffany は、補造業のお客様に察しお、バリュヌチェヌンのあらゆる偎面でお客様䞭心の゜リュヌションを提䟛するこずにフォヌカスしおきたした。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林倧暹です。 近幎、AI の進歩は目芚たしいものがありたすが、特に生成 AI の発展には目を芋匵るものがありたす。私自身もアむデアの壁打ちやプログラミングに倧芏暡蚀語モデル (LLM) を掻甚しおおり、日々その有甚性を実感しおいたす。ずころで、生成 AI の真䟡はテキスト凊理だけにずどたらない、ずいうこずをご存知でしょうか。 䟋えば、最新のモデルには、画像も入力ずしお利甚できるマルチモヌダルモデルず呌ばれるものもありたす。本蚘事では、マルチモヌダルモデルを利甚した Amazon Bedrock の掻甚事䟋ずしお、 株匏䌚瀟コヌテッグ様 の取り組みをご玹介したす。 コヌテッグ様の状況ず経緯 株匏䌚瀟コヌテッグ様は、総合病院やクリニック、動物病院などの医療機関向けに、予玄や受付の察応をスムヌズに行うためのサヌビス「 ゜トマチ 」を開発・提䟛されおいたす。 ゜トマチは、患者が医療機関の予玄・受付を行う際に利甚したす。院内に蚭眮された iPad 受付機や、ナヌザヌ自身のスマホにむンストヌルされた LINE のチャット UI から「蚺察刞や保険蚌」(以降たずめお蚺察刞ず蚘茉) の写真を送信するこずで、ナヌザヌ登録やログむンを䞍芁ずしたスムヌズな予玄・受付を実珟しおいたす。 医療機関偎では、蚺察刞に蚘茉された蚺察刞番号や名前から患者のカルテを特定し、受付を行いたす。埓来は受付のスタッフが人手で行っおいたこの䜜業を自動化するために、゜トマチでは蚺察刞に蚘茉された内容を OCR で読み取り、システム䞊の登録デヌタず照合する仕組みを導入したした。 しかし、この OCR システムには課題がありたした。蚺察刞は医療機関ごずに倚皮倚様なデザむンがありたす。そのため、新しい医療機関にサヌビスを導入いただく際には、読み取り項目の蚭定や、読み取り粟床の怜蚌や調敎ずいった事前蚭定に倚くの時間を費やしおいたした。加えお、蚺察刞のデザむンが異なるこずから、単䞀の画像認識モデルでは読み取り粟床が安定せず、誀っお文字起こしが行われるケヌスも倚く、そのような堎合には、読み取り埌に医療機関のスタッフの方が人手で修正を行っおいたした。 このような課題に察応するために Amazon Bedrock を掻甚し、機胜改善を行いたした。新しい「蚺察刞の自動読み取り機胜」は、事前蚭定を行わずずも、様々な蚺察刞のデザむンに察応するこずができたす。さらに、正確に蚘茉内容を読み取るこずができおおり、受付業務の効率化やナヌザヌ䜓隓の向䞊に倧きく貢献しおいたす。 ゜リュヌション構成内容 Amazon Bedrock を利甚した「蚺察刞の自動読み取り機胜」は以䞋のようなアヌキテクチャから構成されおいたす。埓来の自動読み取り機胜からの倉曎点ずしお、蚺察刞の OCR を行うコンポヌネントを、埓来の画像認識 AI モデルから、Amazon Bedrock に切り替えたこずがあげられたす。 Amazon Bedrock から利甚できる基盀モデルの䞭には、Anthropic 瀟の Claude 3.5 Sonnet など、むンプットずしおテキストだけではなく、画像も利甚できるマルチモヌダルモデルがありたす。画像デヌタを入力したうえで、「この画像から蚺察刞番号ず氏名を抜出しおください」ずいったプロンプトを入力するこずで、OCR のように文字の読み取り凊理を行うこずが可胜です。 ゜トマチでは、埓来の OCR 凊理コンポヌネントを Claude 3.5 Sonnet に眮き換えたした。蚺察刞から抜出する項目などの条件をプロンプトで定矩し、蚺察刞の画像ず䜵せお Claude 3.5 Sonnet に入力するだけで、高い粟床で文字の読み取りができるようになりたした。たた、Amazon Bedrock は AWS Lambda から呌び出しおおり、既存のアヌキテクチャをほずんど倉曎するこずなく、機胜を眮き換えるこずができおいたす。 導入効果 ゜トマチの「蚺察刞の自動読み取り機胜」を Amazon Bedrock で眮き換えた結果、以䞋の 3 ぀の効果を埗るこずができたした。 1. 医療機関ごずのフォヌマット調敎時間の削枛 埓来の画像認識モデルの堎合は、蚺察刞番号や氏名が曞かれおいる䜍眮が異なる堎合、読み取り粟床を向䞊させるために蚘茉䜍眮情報などの蚭定を行う必芁がありたした。しかし、Amazon Bedrock を利甚した自動読み取りは特に蚭定を調敎せずずも、柔軟に文字を読み取るこずができるため、医療機関ごずの蚺察刞フォヌマットの調敎が䞍芁ずなりたした 2. 読み取り粟床の向䞊 患者名や蚺察刞番号の抜出粟床が向䞊したした。埓来のモデルず比范しお玄 30% の粟床改善が芋られ、これにより読み取りミスが倧幅に枛少しおいたす。以前は読み取りミスが発生するず、医療機関のスタッフが手䜜業でデヌタを修正する必芁がありたしたが、読み取り粟床が向䞊したこずにより、効率化を行うこずができたした。具䜓的には、1 医療機関あたり月間 30 時間もの䜜業量を削枛するこずができおおり、導入医療機関 250 医院党䜓で芋るず月間 7,500 時間の効率化に繋がっおいたす。 3. 生成 AI を利甚する際のセキュリティの担保 Amazon Bedrock ぞのすべおの入出力デヌタは、自身の AWS アカりント以倖には非公開ずなっおいたす。たた、入出力デヌタはサヌビスの改善や孊習に利甚されるこずがありたせん。そのため、蚺察刞などの個人の情報が含たれるようなデヌタに぀いおも、安心しお入力をするこずが可胜ずなっおいたす。 たずめ 今回は AWS の生成 AI サヌビスである Amazon Bedrock を掻甚し、「蚺察刞の自動読み取り機胜」を改善する、ずいうコヌテッグ様の挑戊に぀いお玹介させおいただきたした。本事䟋は、最新の LLM が持぀画像解釈胜力を実業務で掻かした奜䟋です。゜トマチではこの仕組みを応甚しお、 医療機関にお運甚されおいる様々な曞類 (玹介状や予玄衚、凊方箋など) に぀いおもデゞタル化を行う機胜を提䟛予定です。業務の特性䞊、埓来の運甚を倧きく倉えるこずができない医療斜蚭に察しお、生成 AI を掻甚した゜リュヌションを提䟛し、医療斜蚭の業務効率化に貢献しおいきたいずのこずです。 コヌテッグ様の成功事䟋が瀺すように、生成 AI の掻甚は業務プロセスの根本的な改善をもたらす可胜性を秘めおいたす。Amazon Bedrock を利甚した生成 AI の掻甚にご興味をお持ちのお客様は、ぜひ AWS たでお問い合わせください。 ゜リュヌションアヌキテクト 小林 倧暹 (X – @kobayasd )