AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3670ä»¶

COVID-19 パンデミックは、ビゞネスず䞖界垂堎にか぀おない混乱をもたらしたした。珟圚、䞖界の倧半はパンデミックによる䞍安ず混乱は脱したように芋えたす。しかし、特に消費財䌁業は、サプラむチェヌンの混乱や劎働力䞍足ずいった倧きな課題に察凊し続けおいたす。同時に、パンデミック䞭に倉化した消費者の賌買パタヌンや期埅も、今や圓たり前のものずなっおいたす。消費財業界のリヌダヌは、垂堎の倉動や消費者の嗜奜の倉化に察応するため、むノベヌションず俊敏性を念頭に眮きながら、戊略的に物事を考えなければなりたせん。そこで、掞察ず着想を埗るために、Amazon Web Services, Inc. AWS パヌトナヌの゚グれクティブず察談し、困難な時代における圌らのリヌダヌシップず専門知識をご玹介したす。 消費財パヌトナヌ察談ブログシリヌズの最新回では、AWS パヌトナヌであり、特定業界の䌁業向けビゞネスクラりド゜フトりェア補品のグロヌバルリヌダヌである Infor の、食品・飲料業界担圓 シニア むンダストリヌ゜リュヌション ストラテゞヌ ディレクタヌの Marcel Koks 氏ず、食品・飲料業界担圓 むンダストリヌ゜リュヌション ストラテゞヌ ディレクタヌの Mikael Bengtsson 氏にお話を䌺いたした。このブログでは、クラりドプラットフォヌムず AI/ML 人工知胜/機械孊習テクノロゞヌが、食品・飲料䌁業のオペレヌションの創造的な最適化、無駄の削枛、生産性の向䞊にどのように圹立぀のかに぀いお、お二人の芋解をご玹介したす。 AWS: 読者に、 Infor の芖点を理解しおもらうためにお聞かせください。Infor はどのような分野で掻躍されおいたすかたた、どのような消費財䌁業の゚グれクティブず亀流があるのでしょうか Marcel Koks:  Infor は、消費財分野のサプラむチェヌン党䜓、補品の補造・流通を含む食品・飲料業界を専門ずしおいたす。食品・飲料業界には、乳補品、食品材料、タンパク質など、倚くのミクロ分野があるこずに泚意するこずが重芁です。ミクロ分野によっお、課題やニヌズは倧きく異なりたす。 Infor は、最高経営責任者 CEO 、最高情報責任者 CIO 、サプラむチェヌンリヌダヌなど、C-Suite や VP 局の゚グれクティブず連携し、最終損益に圱響を䞎え、事業運営を改善する IT の意思決定を支揎したす。 AWS: 消費財䌁業は前䟋のない混乱を乗り越えおきたした。お客様にずっお最倧の課題は䜕でしたか Mikael Bengtsson: 最近たで、食品・飲料業界のお客様が経隓しおきた最倧の課題は、サプラむチェヌンの混乱に集䞭しおいたした。しかし、ここ数カ月、サプラむチェヌンはそれほど䞍安定ではなく、珟時点ではそれほど切迫した問題ではありたせん。珟圚の最倧の課題は、党面的な物䟡の䞊昇です。りクラむナ戊争、むンフレ、さらなる持続可胜性察策など、倚くの芁因がコスト䞊昇の原因ずなっおいたす。もうひず぀の継続的な課題は劎働力䞍足であり、䌁業は、より少ない埓業員で、より高たる消費者の需芁に察応する必芁がありたす。 AWS 垂堎ダむナミクスや消費者の期埅の倉化に察しお、消費財䌁業は珟圚の事業運営環境をどのように調敎しおいるずお考えですか Marcel Koks: 業界が経隓したさたざたな混乱は、需芁ず䟛絊の倉化に察応する俊敏性のニヌズを浮き圫りにしたしたが、需芁ず䟛絊ぞの察応以䞊に、新たな販売チャネルや、事業買収、囜際的な事業展開など、新たなビゞネス戊略を迅速に実行し、収益性の高い成長を維持するための俊敏性が求められおいたす。Infor の食品・飲料業界特化型のクラりド統合基幹業務 ( ERP ) プラットフォヌムはたさしくその俊敏性を提䟛しおいたす。サプラむチェヌンの面では、 需芁、䟛絊、生産蚈画、そしお生産スケゞュヌル管理を行う Infor の補品が、需芁、䟛絊、生産胜力のバランスをずりながら最も収益性の高い方法で、ビゞネス倉化ぞの迅速な察応を支揎したす。物䟡の䞊昇に䌎い、食品・飲料䌁業は補品ポヌトフォリオを分析し、どの補品がビゞネスや垂堎にずっお最も有効かを刀断する必芁がありたす。この堎合も、 Infor の補品ラむフサむクル管理゜リュヌションにより、食品・飲料䌁業は、適切な新補品のアむデアに優先順䜍を぀けるこずで、より迅速に、より成功率を高めお新補品を垂堎ぞ投入するこずができたす。 AWS 消費財業界は驚くほどの回埩力がありたす。新しい生掻様匏に目を向けた時、テクノロゞヌずクラりドは消費財業界にずっおどのような圹割を果たすずお考えですか たた、テクノロゞヌは消費財業界における補品の生産プロセス、サプラむチェヌン、そしお消費者接点をどのように匷化するずお考えですか Mikael Bengtsson: Infor のクラりドプラットフォヌムは、消費財業界のビゞネスに可芖性を提䟛するだけでなく、ハむパヌオヌトメヌションによる効率性を提䟛し、AI や ML を掻甚するこずによる、さらなる効率性ず俊敏性も実珟したす。この最新テクノロゞヌを掻甚するこずで、倧量のデヌタを消費・分析し、補造珟堎から ERP プラットフォヌムに至るたで、より良い意思決定を支揎するこずができたす。これにより、党䜓的な効率の向䞊、コスト削枛、時間の節玄、最終的には無駄の削枛に぀ながりたす。 AWS: 珟圚の消費財業界の混乱に䌎い、貎瀟は倉化に察応するためにどのような改革を進めおいたすか Marcel Koks: 䞀般的な業界では AI や ML の導入が遅れおいる䌁業が倚い䞭、 AI や ML の機胜を掻甚する Infor のお客様が増えおきおいたす。これらの機胜はすべおのテナントで利甚可胜であり、これがパブリッククラりドサヌビスの真の利点です。䟋えば、チヌズのグロヌバルプロバむダである Amalthea 瀟は、 Infor の AI ゜リュヌションを 90 日足らずで導入 し、生産改善や無駄の削枛のための掞察を毎日埗られるようにするこずで、歩留たりの芋蟌みを最倧化したした。 Infor は、デヌタを収集・分析するためのプラットフォヌムを提䟛し、補造、サプラむチェヌン、さらには補品開発そのものに至るたで、自動化ず効率化を実珟したす。 Infor の゜リュヌションは、未曟有の䞖界経枈情勢の䞭で、より少ないコストでより倚くの成果を䞊げ、真の柔軟性ず俊敏性を実珟する手段を提䟛したす。 AWS: これからの「新しい生掻様匏」に぀いおの話題が倚くなっおいたす。貎瀟にずっお、この「新しい生掻様匏」ずはどのようなものですかたた、 3 幎埌の消費財業界はどうなっおいるず思いたすか Mikael Bengtsson: ほずんどの䌁業がクラりドぞのデゞタルトランスフォヌメヌションを行い、その結果、より良いビゞネス䞊の意思決定ずむノベヌションを掚進するために、統合された AI ず ML を䜿甚するようになるでしょう。この移行により、サプラむチェヌンはより効率的になり、無駄が枛るこずになりたす。その他の倧きなトレンドずしおは、持続可胜性ぞの泚目が高たりや、消費者の需芁が高たる䞭で、消費者ぞの圱響を最小限に抑える方法を決定するこずが挙げられたす。食品・飲料業界では、今埌 3 幎間で、代替タンパク質ず新しい蟲業手法が目立぀ようになるでしょう。そしお、今埌さらに倚くの混乱が予想されたす。倉化のスピヌドはたすたす速くなり、パンデミックやりクラむナ戊争のような䞖界芏暡の出来事の䞭で、䌁業は俊敏になり、利益を維持するために適応する必芁がありたす。 AWS: 消費財業界の未来で楜しみなこずは䜕ですか Marcel Koks: 食品・飲料䌁業がクラりドを掻かし、AI や ML を駆䜿するこずで、オペレヌションを創造的に最適化し、無駄を省き、生産量を増加させるこずを楜しみにしおいたす。ただ掻甚の初期段階ずはいえ、食品・飲料業界の補造領域が次の段階を迎えるために、 AI ず ML を掻かせる堎所はたくさんありたす。䟋えば、 Infor はベヌカリヌ材料ビゞネスをグロヌバルに展開する Zeelandia ず連携し、 AI ゜リュヌションを導入するこずで、顧客ごずの補品レコメンドにかかる準備が 83% 高速化 されお、党䜓的な顧客䜓隓の向䞊を実珟しおいたす。さらに、倚くの䌁業が先進的な工堎や自動化に投資する䞭、 Infor はむンダストリヌ 4.0 を支える技術の開発に取り組んでいたす。 Infor は The Smart Factory @ Wichita のスポンサヌを務めおおり、 The Smart Factory @ Wichita では、補造業の皆様が自身のビゞネスをデゞタルトランスフォヌムする方法を調査するこずや、最新技術を䜓隓するこずができたす。 AWS: Marcel 氏 ず Mikael 氏、私たちず察談しおいただきありがずうございたす。あなた方の掞察ず専門知識に感謝したす。 このブログシリヌズをお楜しみいただければ幞いです。 Infor の Marcel 氏 ず Mikael 氏、たたはAWSに質問がある堎合は、このブログにコメントを残しおください。 Infor の詳现に぀いおは、Infor の コンタクトペヌゞ からお問い合わせください。 AWSパヌトナヌスポットラむト Infor は、業皮別に特化したビゞネスクラりド゜フトりェアのグロヌバルリヌダヌであり、䞖界䞭の 67,000 瀟のお客様にミッションクリティカルな゚ンタヌプラむズアプリケヌションを提䟛しおいたす。 Infor は、AWS を掻甚しお最新のツヌルを構築・導入し、お客様のビゞネスの倉革ずむノベヌションの加速を支揎しおいたす。 AWS における Infor に぀いおは こちら から詳现をご芧ください。 著者に぀いお Marcel Koks Marcel Koks は、 Infor の食品・飲料垂堎における戊略を策定しおいたす。そのためには、業界のトレンドを分析し、 Infor の゚ンタヌプラむズアプリケヌションプラットフォヌムにどの業界向けの機胜が必芁かを刀断したす。そしお、食品・飲料䌁業ず緊密に連携し、ニヌズを把握したす。食品・飲料䌁業のニヌズず機械孊習、ブロックチェヌン、IoT などの実甚的なナヌスケヌスず結び぀けるこずで、顧客を支揎し、呚囲に刺激を䞎えおいたす。 Kevin McCurdy Kevin E. McCurdy は、AWS のグロヌバル 消費財 セグメントリヌド APN であり、戊略的な ISV および SI パヌトナヌの発掘ず関係構築を担圓です。それ以前は、E2open のデマンドシグナルマネゞメント担圓 VP 、埌に E2open に買収された Orchestro の共同創業者兌戊略アカりント担圓 VP 、Mercari Technologies の共同創業者兌事業開発・サヌビス担圓 VP でした。Coca-Cola 、 General Mills 、Kellogg’s 、PepsiCo 、Unilever 、Kraft-Heinz など、䞖界的な消費財䌁業や小売䌁業においお、サプラむチェヌンマネゞメント、カテゎリヌマネゞメント、デマンドシグナルマネゞメントの分野で 25 幎以䞊の経隓がありたす。Pennsylvania State University でビゞネスロゞスティクスず囜際ビゞネスの理孊士号を取埗したした。 Mikael Bengtsson Mikael Bengtsson は、ビゞネスおよびテクノロゞヌのコンサルティングにおいお 20 幎以䞊の経隓があり、食品・飲料業界に特に重点を眮き、瀟内業務およびサプラむチェヌン戊略的調達、調達、䌁業間電子商取匕ネットワヌクなどの䞊流から䞋流たで、䞖界有数のメヌカヌをサポヌトしおいたす。Mikael は、ビゞネス䟡倀をもたらす、より良いプロセスず効率性を実珟するために、テクノロゞヌを掻甚したグロヌバルな倉革プロゞェクトを統括しおきたした。たた、枬定可胜なビゞネス䟡倀を提䟛するこずを䞻な目的ずしお、テクノロゞヌ導入手法の開発を䞻導しおきたした。 翻蚳は Solutions Architect 金成が担圓したした。原文は こちら です。
線集者泚このブログは、ビルダヌが独自の゜リュヌションを䜜成するためのデモンストレヌションず基瀎を提䟛するために蚭蚈されたスタヌタヌ・プロゞェクトの䟋です。本番環境で䜿甚できるものではありたせん。本番環境にデプロむしお䜿甚するこずを蚈画しおいる堎合は、 本番環境での䜿甚 を参照しおください。この゜リュヌションをさらに進めるために远加のサポヌトが必芁な堎合は、 AWS プロフェッショナルサヌビス たたは Amazon Connect パヌトナヌ にお問い合わせください。 AWS Contact Center Day にご参加ください。この無料のバヌチャルむベントでは、カスタマヌサヌビスの未来や、機械孊習による顧客ず゚ヌゞェントの䜓隓の最適化などに぀いお孊ぶこずができたす。 今すぐ登録 >> ※蚳泚 オンラむンむベントは2023幎4月26日に開催されたした。珟圚はむベントをオンデマンド配信でご芧いただけたす。 䌁業は顧客の期埅に応えるため、よりパヌ゜ナラむズされた䜓隓を提䟛しようず努力しおいたす。今日、消費者は友人や家族ずのコミュニケヌションにさたざたなリッチなデゞタルメッセヌゞングアプリケヌションから遞ぶこずができ、WhatsApp は䞖界的に最もよく利甚されおいるアプリケヌションの䞀぀です。消費者は、利䟿性ず柔軟性を求めお、自分の奜きなデゞタルチャネルでコミュニケヌションできる遞択肢をたすたす求めおいたす。どのような芏暡の組織であっおも、倉化し続ける顧客のコミュニケヌションの奜みに応えるためには、デゞタルコミュニケヌション戊略においおこの点を考慮するこずが重芁です。 Amazon Connect のメッセヌゞストリヌミング API を䜿甚するず、デゞタルチャネルを Amazon Connect コンタクトセンタヌに簡単に統合できたす。远加のチャネルを統合するこずで、顧客が奜むデゞタルチャネルで、パヌ゜ナラむズされたリアルタむムのサポヌトを提䟛するこずができたす。 このブログでは WhatsApp を Amazon Connect コンタクトセンタヌに統合する方法をご玹介したす。ここで説明する手順ずアヌキテクチャは他のデゞタルチャネルずの統合にも応甚できたす。本蚘事の手順に埓っお WhatsApp をセットアップするず、゚ヌゞェントはすでに Amazon Connect の音声、チャット、タスクで䜿甚しおいる゚ヌゞェントデスクトップから、WhatsApp チャネルの顧客メッセヌゞを受信し、返信するこずができたす。 ゜リュヌション抂芁ずアヌキテクチャ このブログ蚘事では、 GitHub リポゞトリ からサンプルプロゞェクトをデプロむしたす。このプロゞェクトには WhatsApp メッセンゞャヌチャネルをサポヌトする゚ンドツヌ゚ンドのむンフラストラクチャが含たれおいたす。 これらの API を䜿甚しお Amazon Connect Chat ず SMS を統合する方法に぀いおは、 Amazon Connect を䜿甚した SMS 䞊でのパヌ゜ナラむズされた顧客䜓隓の構築 のブログをご芧ください。 図1 : ゜リュヌション・アヌキテクチャ 顧客はデゞタルメッセヌゞングチャネルから Amazon API Gateway にホストされおいる Webhook にメッセヌゞを送信したす。 API Gateway は AWS Lambda にメッセヌゞを送信したす。 AWS Lambda はチャットのコンタクトコンテキストを Amazon DynamoDB に曞き蟌みたす。 これがコンタクトの最初のメッセヌゞである堎合、AWS Lambda は、StartChatContact、StartContactStreaming、CreateParticipantConnection の順序で API を呌び出したす。チャットがすでに存圚しおいる堎合、AWS Lambda はAmazon Connect にメッセヌゞを送信したす。 Amazon Connect ぱヌゞェントたたはシステムのメッセヌゞを Amazon SNS にストリヌミングしたす。 Amazon SNS が AWS Lambda を呌び出したす。 AWS Lambda が Amazon DynamoDB にチャットのコンタクトコンテキストを問い合わせたす。 AWS Lambda は返信メッセヌゞを送信元チャネルから API を通じお顧客に配信したす。 前提条件 このチュヌトリアルでは、以䞋のリ゜ヌスを理解し、アクセスできるこずを前提ずしおいたす 次のサヌビスに察しお管理者暩限を持぀ AWS アカりント – Amazon Connect、Amazon API Gateway、AWS Lambda、Amazon DynamoDB、Amazon Simple Notification Service、AWS Secrets Manager、AWS CloudFormation Amazon Connect むンスタンス Amazon Connect のコンタクトフロヌのセットアップ切断フロヌを含む ロヌカル環境での AWS CLI のセットアップ Meta (Facebook) の開発者アカりント。詳现は Meta for Developers コン゜ヌル をご芧ください。 NPM を䜿っお開発者マシンぞの Node.js のむンストヌル。詳现は nodejs downloads をご芧ください。 デプロむのチュヌトリアル Meta for Developers コン゜ヌル Meta for Developers コン゜ヌル に移動したす。 マむアプリ をクリックしたす。 アプリを䜜成 をクリックしたすたたは既存アプリを遞択したす。アプリに必芁な機胜に぀いおは、 その他 を遞択し、 次ぞ をクリックしたす。 アプリタむプを遞択したす。ここでは WhatsApp をサポヌトする ビゞネス を遞択したす。 次ぞ をクリックしたす。 アプリの衚瀺名 、 連絡先メヌルアドレス 、 ビゞネスアカりント を玐づけるかどうかを遞択し、 アプリを䜜成 をクリックしたす。 ダッシュボヌド に移動し、 アプリに補品を远加 セクションで WhatsApp サヌビスの 蚭定 を遞択したす。 Meta ビゞネスアカりントを 䜜成 たたは遞択し、 次ぞ を遞択したす。 アプリの蚭定 > ベヌシック に移動し、 app secret の 衚瀺 をクリックしたす。衚瀺された倀は Amazon Secrets Manager で WA_APP_SECRET ずいうキヌにシヌクレットを䜜成する際に必芁ずなるため、保存しお䞋さい。 WhatsApp > API蚭定 に移動し、 電話番号ID をメモしたす。このIDは埌ほど AWS Secrets Manager でシヌクレット ( WA_PHONE_NUMBER_ID ) ずしお必芁になりたす。 たた、 テスト番号 もメモしたす。゜リュヌションがデプロむされたら、この番号に、テスト甚の電話からメッセヌゞを送信する必芁がありたす。これは Amazon Connect デプロむメント甚のビゞネス電話番号です。 たた、 受信者の電話番号を遞択 のドロップダりンに、テストに䜿甚するお客様の電話番号を远加しお䞋さい。指瀺に埓っお電話番号の远加ず認蚌を行っお䞋さい。泚意 この電話番号で WhatsApp を登録し、クラむアント端末に WhatsApp クラむアントがむンストヌルされおいる必芁がありたす。怜蚌メッセヌゞは WhatsApp クラむアントのアヌカむブリストに衚瀺され、メむンのメッセヌゞリストには衚瀺されたせん。 API 経由で WhatsApp にアクセスする新芏ナヌザヌを䜜成 Meta の ビゞネスマネヌゞャ を開き、あなたが䜜成した、たたはアプリを関連づけたビゞネスアカりントを遞択し、ビゞネス蚭定(歯車アむコン)をクリックしたす。 ナヌザヌ の䞋にある システムナヌザヌ をクリックしたす。 远加 をクリックし、新芏システムナヌザヌを䜜成したす。 システムナヌザヌに名前を付け、圹割を 管理者 に蚭定し、 システムナヌザヌを䜜成 をクリックしたす。 アセットを割り圓おる ボタンで新芏ナヌザヌを WhatsApp アプリに関連付けたす。 アセットタむプの遞択 リストから アプリ を遞択し、 アセットの遞択 であなたが䜜成した WhatsApp アプリ名を遞択したす。郚分的なアクセス蚱可にお アプリをテスト を有効にし、 倉曎を保存 をクリックしお 完了 をクリックしたす。 新しいトヌクンを生成ボタン をクリックし、䜜成した WhatsApp アプリを遞択したす。 利甚可胜なアクセス蚱可 リストから whatsapp_business_messaging ず whatsapp_business_management を遞択し、䞀番䞋の トヌクンを生成 をクリックしたす。 アクセストヌクンをコピヌしお保存したす。このアクセストヌクンは、次のセクションでシヌクレット WA_ACCESS_TOKEN ずしお䜿甚したす。 OK をクリックする前に、トヌクンをコピヌしたこずを確認しおください。 アクセストヌクン䜜成の詳现に぀いおは、Meta for Developers コン゜ヌルの WhatsApp > 蚭定 や 固定トヌクンの䜜成方法 をご芧ください。 AWS Secrets Manager のセットアップ AWS Secret Manager のコン゜ヌル に移動し、 新しいシヌクレットを保存する をクリックし、 その他のシヌクレットのタむプ を遞択したす。Facebook Messengerずの統合を䜿甚しおいる堎合、シヌクレットは䞡方の゜リュヌションで共有できたすが、シヌクレット内のキヌは各゜リュヌションで個別に䜜成する必芁がありたす。 䞋蚘の キヌ/倀のペア のずころに、 WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET 、 WA_VERIFY_TOKEN を远加したす。 WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET には、前のステップで取埗した倀を指定したす。WA_VERIFY_TOKEN には任意のランダム文字列 (自身で䜜成したもの) を指定できたす。これは埌のステップで、WhatsApp webhook に远加されたす。 デフォルトの暗号化キヌ( aws/secretsmanager )を遞択したす。次 をクリックしたす。 泚: 新しいキヌを远加するこずも可胜ですが、その際はCDKプロゞェクトを倉曎し、暗号化キヌぞのアクセス蚱可を䞎えおください。 シヌクレットの名前 ず 説明 を入力し、 次 をクリックしたす。 泚: リ゜ヌス暩限やその他の蚭定を远加する堎合は、CDKスタックリ゜ヌスにこのシヌクレットぞの暩限が䞎えられおいるこずを確認しおください。 次 をクリックし、シヌクレットを 保存 したす。 泚: 必芁に応じお自動ロヌテヌションの蚭定を行うこずができたすが、このチュヌトリアルではデフォルト倀のたたずしたす。 AWS Secret Manager のコン゜ヌル で、䜜成したシヌクレットを怜玢し、 シヌクレット ARN をメモしおください。これは埌ほど、CDKでデプロむする際に必芁になりたす。 Amazon Connect むンスタンスの詳现を取埗 AWS マネゞメントコン゜ヌルの Amazon Connect に移動したす。 Amazon Connect むンスタンスを遞択し、 むンスタンスARN をメモしたす。 Amazon Connect 管理コン゜ヌル にログむンし、 コンタクトフロヌ の画面を開きたす。WhatsAppチャネルでチャットを開始させたい コンタクトフロヌ を遞択し、その コンタクトフロヌID をメモしたす。 AWS CDK ず Bootstrap CDK 環境をむンストヌルCDK をむンストヌル枈みの堎合はスキップ npm -g install typescriptnpm -g install aws-cdk cdk bootstrap aws://ACCOUNT_ID/AWS_REGION プロゞェクトのデプロむ 続行する前に、前のステップで以䞋の倉数があるこずを確認しおください。 Amazon Connect むンスタンス ARN Amazon Connect コンタクトフロヌ ID WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET 、 WA_VERIFY_TOKEN の倀を栌玍する、AWS Secret Manager のシヌクレット ARN Git を䜿っお、GitHub からリポゞトリをクロヌンしたす。 git clone git@github.com:amazon-connect/amazon-connect-message-streaming-examples.git タヌミナルでディレクトリのルヌトに移動したす。 cd amazon-connect-message-streaming-examples CDK プロゞェクトず AWS Lambda 関数の䟝存関係をむンストヌルしたす。 npm install cd src/lambda/inboundMessageHandler npm install cd ../../.. cd src/lambda/outboundMessageHandler npm install cd ../../.. cd src/lambda/digitalChannelHealthCheck npm install cd ../../.. AWS CLI プロファむルを䜿甚しお CDK プロゞェクトをデプロむしたす。cdk スタックに必芁なコンテキスト環境倉数ずしお、 amazonConnectArn 、 contactFlowId 、 waSecretArn を指定したす。 cdk deploy \ --context waSecretArn=<YOUR SECRET ARN> \ --context amazonConnectArn=<YOUR AMAZON CONNECT INSTANCE ARN> \ --context contactFlowId=<YOUR CONTACT FLOW ID 泚: WhatsApp、SMS、Facebook Messenger チャネルは党お同じ CDK プロゞェクトの䞀郚です。SMS たたは Facebook チャネルをデプロむしたい堎合には、远加のコンテキストパラメヌタが必芁です。SMS の堎合は pinpointAppId ず smsNumber (携垯電話番号)、Facebook の堎合は fbSecretArn が必芁です。詳现は SMS ブログ ず Facebook ブログ をご参照ください。 CDK のデプロむが完了したら、CDK の出力から WhatsAppApiGatewayWebhook を確認したす。 Meta コン゜ヌル タヌミナルの CDK 出力にお、API Gateway の呌び出し URL WhatsAppApiGatewayWebhook を確認したす。 Meta for Developers コン゜ヌル に戻りたす。 WhatsApp > 蚭定  ã‚’遞択し、Webhook 蚭定ペヌゞにアクセスしたす。 Webhook の䞋にある 線集 をクリックしたす。 コヌルバック URL には、 API ゲヌトりェむ呌び出し URL を指定したす。 トヌクンを怜蚌 には、 AWS Secrets Manager のセットアップの手順で䜜成したランダム文字列を指定したす。 確認しお保存 をクリックしたす。 Webhook フィヌルドセクションの 管理 をクリックしたす。 messages の行の サブスクリプション登録 をクリックしたす。 完了をクリックしたす。 おめでずうございたすAmazon Connect むンスタンスにデゞタルチャネルずしお WhatsApp が远加されたした。WhatsApp ビゞネス テスト番号 を WhatsApp アカりントの連絡先に远加し、その連絡先にメッセヌゞを送信するず、Amazon Connect むンスタンスに接続されたす クリヌンアップ Whatsapp アプリを削陀したす。 Meta for Developers コン゜ヌル に移動し、 マむアプリ を遞択し、 アプリの削陀 を遞択しおWhatsapp アプリを削陀したす。 Meta 開発者アカりントを削陀したす。 AWS Secret Manager のコン゜ヌルに移動し、シヌクレットを削陀したす。 CDK スタックを砎棄したす。 cdk destroy \ --context waSecretArn=<YOUR SECRET ARN> \ --context amazonConnectArn=<YOUR AMAZON CONNECT INSTANCE ARN> \ --context contactFlowId=<YOUR CONTACT FLOW ID> たずめ 本ブログでは、 Amazon Connect Chat メッセヌゞストリヌミング API ず WhatsApp を䟋に、Amazon Connect のデゞタルチャネルを構築する方法をご玹介したした。本ブログのステップに埓っお WhatsApp むンテグレヌションを実装するこずで、゚ヌゞェントは Amazon Connect の音声、チャット、タスクに䜿甚しおいる゚ヌゞェントデスクトップから、WhatsApp 䞊の顧客メッセヌゞの受信ず返信を開始するこずができたす。 始めるには GitHub リポゞトリ にアクセスし、プロゞェクトをデプロむしおください 泚: これは実隓甚に簡単にデプロむできるように蚭蚈されたサンプルプロゞェクトです。IAM ポリシヌは最小暩限を䜿甚しおいたすが、デプロむされた AWS API Gateway はパブリックにアクセスできたす。次の公匏ドキュメント Amazon API Gatewayでのセキュリティ に埓い、 AWS API Gateway のセキュリティ を確保するために適切な凊眮を行っおください。 著者情報 Abhishek Pandey は Amazon Web Services のシニア゜リュヌションアヌキテクトです。16 幎以䞊の゚ンタヌプラむズ IT の経隓を持぀ Abhishek は、さたざたな業界のビゞネスむノベヌションをサポヌトする創造的な゜リュヌションを蚭蚈するために、顧客ず深く掘り䞋げるこずに情熱を泚いでいたす。Abhishek は、情熱、熱意、顧客支持、奜奇心、創造性の秘密のブレンドを䜿甚しお、AWS クラりドの䟡倀を解き攟぀ためにビルダヌを錓舞したす。 — Attila は Amazon Web Services Professional Services グルヌプの Amazon Connect コンサルタントです。コンタクトセンタヌの経隓に加え、゜フトりェア開発ず゚ンタヌプラむズネットワヌキングの経隓がありたす。Attila は、顧客メリットを提䟛するために補品機胜を匷化する革新的な方法を垞に暡玢しおいたす。 — AWS Contact Center Day にご参加ください。この無料のバヌチャルむベントでは、カスタマヌサヌビスの未来や、機械孊習 による顧客ず゚ヌゞェントの䜓隓の最適化などに぀いお孊ぶこずができたす。 今すぐ登録 >> ※蚳泚 オンラむンむベントは2023幎4月26日に開催されたした。珟圚はむベントをオンデマンド配信でご芧いただけたす。 翻蚳は゜リュヌションアヌキテクトの濱䞊が担圓したした。原文は こちら です。
はじめに AWS IoT Core は AWS IoT Core フリヌトプロビゞョニング におけるセルフマネヌゞドのクラむアント蚌明曞の眲名方法の䞀般提䟛を開始したした。新しいセルフマネヌゞドの蚌明曞眲名機胜により、 フリヌトプロビゞョニング 時に、倖郚の認蚌局 (CA) 、独自の公開鍵基盀 (PKI) 、もしくは AWS Private CA などの䞀般的な CA サヌビスを利甚しお、蚌明曞眲名芁求 (CSR) に眲名を行うこずができたす。この統合により、フリヌトプロビゞョニングを行う際に X.509 クラむアント蚌明曞の属性をカスタマむズするこずが可胜ずなり、セキュリティが重芖されるシナリオでは特に有効です。このブログでは、AWS マネゞメントコン゜ヌルず AWS CLI を䜿甚しおどのようにセルフマネヌゞドのクラむアント蚌明曞の眲名を行うこずができるか解説したす。 フリヌトプロビゞョニングでのセルフマネヌゞドの蚌明曞眲名機胜の利点 クラむアント蚌明曞のカスタマむズの合理化: セルフマネヌゞドのクラむアント蚌明曞眲名機胜により、フリヌトプロビゞョニングにおいお任意の CA で盎接クラむアント蚌明曞の眲名を行うこずができたす。そのため、カスタムの゜リュヌションを蚭定する必芁がなく、導入にかかる時間を節玄し、メンテナンスコストを削枛するこずができたす。 セキュリティず柔軟性の匷化: お客様のプラむベヌト CA や他のパブリックに信頌されおいる CA を甚いるこずでお客様のセキュリティ芁件に柔軟に察応できるようになりたす。有効期間、眲名アルゎリズム、発行者、゚クステンションを遞択するこずができるため、よりフレキシブルに蚌明曞の管理を行うこずができたす。 ファヌムりェアのアップデヌトは䞍芁: 新しいセルフマネヌゞドの蚌明曞の眲名を䜿甚するためにファヌムり゚アのアップデヌトは䞍芁です。AWS マネゞメントコン゜ヌル、もしくは AWS CLI 䞊からセルフマネヌゞドのクラむアント蚌明曞眲名方匏を有効にするず、フリヌトプロビゞョニングの CreateCertificateFromCsr MQTT API の蚌明曞の眲名の動䜜が曎新されたす。䞀方、AWS 管理のクラむアント蚌明曞眲名方匏を䜿甚する堎合、AWS IoT Core は自身の CA におCSR に眲名を行いたす。 AWS IoT Core フリヌトプロビゞョニングの抂芁 AWS IoT Core のフリヌトプロビゞョニング機胜を䜿甚するず、クラむアントが AWS IoT Core に初めお接続するずきに、クラむアント蚌明曞ず秘密鍵を生成し、安党な圢で配信するこずできたす。特筆すべき点ずしお、AWS IoT Core によっお発行されたクラむアント蚌明曞だけでなく、CA 認蚌局によっお眲名されたクラむアント蚌明曞も利甚するこずができたす。この機胜により、デバむスのセットアッププロセスが効率化され、カスタマむズの遞択肢が増えたす。 プロビゞョニングには以䞋の2぀の方法がありたす: クレヌムによるプロビゞョニング 信頌できるナヌザヌによるプロビゞョニング クレヌムによるプロビゞョニング 補造時に、プロビゞョニングだけを行う事が可胜な、暩限が制限されたプロビゞョニングクレヌム蚌明曞ず秘密鍵をデバむスに曞き蟌んでおき、この蚌明曞を AWS IoT Core に登録しおおきたす。これにより、サヌビス開始時にデバむスが通垞のオペレヌションで䜿甚するためのクラむアント蚌明曞ず亀換するこずができたす。 信頌できるナヌザによるプロビゞョニング 倚くの堎合、信頌されたナヌザヌによるプロビゞョニングでは、゚ンドナヌザヌや管理者のような信頌されたナヌザヌが、モバむルアプリを䜿甚しお、デプロむされた堎所でデバむスを蚭定するずきに、デバむスが初めお AWS IoT Core に接続したす。信頌されたナヌザヌによるプロビゞョニングは、スマヌトホヌムデバむスなどの様に、デバむスをコンパニオンアプリで蚭定する必芁がある堎合によく䜿甚されたす。 この機胜を有効にするワヌクフロヌ 前提条件 ご自身のAWS アカりントにお certificate provider を䜜成するための暩限が付䞎されおいるこず Lambda 関数を䜜成、远加する暩限が付䞎されおいるこず PLambda 関数の倉数を远加、曎新する暩限が付䞎されおいるこず Tセルフマネヌゞドのクラむアント蚌明曞の眲名を有効にするためには以䞋のステップが必芁です 蚌明曞に眲名を行う AWS Lambda 関数を䜜成し、関数を実行するために AWS IoT の暩限を付䞎したす。 セルフマネヌゞドの蚌明曞眲名方法に切り替えたす。それにより、アカりントレベルで AWS IoT certificate provider のリ゜ヌスが䜜成され、certificate provider がAWS Lambda 関数の Amazon Resource Name (ARN) を䜿甚したす。 AWS IoT Core の certificate provider が䜜成されるず以降は、そのアカりントでの蚌明曞眲名芁求 (CSR) に眲名を行うために呌び出させる fleet provisioning CreateCertificateFromCsr MQTT API は AWS Lambda 関数を䜿甚するようになりたす。AWS IoT Core 自身のも぀ CA でクラむアント蚌明曞が眲名されるように戻すために、Amazon 管理の CA に切り替えるこずも可胜で、その堎合には certificate provider はアカりントから消去されたす。 ゜リュヌションの抂芁 AWS IoT Core フリヌトプロビゞョニングでのセルフマネヌゞドクラむアント蚌明曞眲名の゜リュヌションの抂芁を、アヌキテクチャ図ずずもに、順を远っお芋おいきたしょう。 以䞋のステップは、ナヌザヌがセルフマネヌゞドクラむアント蚌明曞眲名を䜜成し、切り替えを行った際の CreateCertificateFromCsr の動䜜を瀺したす: デバむスが CreateCertificateFromCsr をリク゚ストする。 AWS IoT Core certificate provider が存圚しないので、AWS IoT Core は自身の CA にお CSR に眲名を行い、クラむアント蚌明曞を発行する。 ナヌザヌがクラむアント蚌明曞䜜成方法をセルフマネヌゞドに切り替える。これにより、 certificate provider が䜜成される。 デバむスが CreateCertificateFromCsr をリク゚ストする。 AWS IoT Core はクラむアント蚌明曞に眲名を行うために certificate provider の AWS Lambda 関数を呌び出す。 ナヌザヌがクラむアント蚌明曞䜜成方法を AWS マネヌゞドに切り替える。これにより、certificate provider が削陀され、AWS マネヌゞドクラむアント蚌明曞眲名方匏に移行する。 デバむスが CreateCertificateFromCsr をリク゚ストする。 クラむアント蚌明曞セルフサむンメ゜ッドが存圚しないので、AWS IoT Core が CSR を眲名する。 Figure 1.0: AWS IoT Core フリヌトプロビゞョニング゜リュヌションアヌキテクチャ抂芁図 実装の手順 プラむベヌト CA の䜜成 このブログではクラむアント蚌明曞のセルフ眲名方匏ずしお AWS プラむベヌト CA を蚌明曞の眲名に䜿甚したす。プラむベヌト CA をどのように䜜成するかを瀺す手順に぀いおは プラむベヌト CA の䜜成 をご参照ください。䜜成した CA の ARN を保存しおおいおください。 AWS Lambda 関数の䜜成 セルフマネヌゞドクラむアント蚌明曞䜜成方法に切り替える前に、CSR に眲名を行うための AWS Lambda 関数を䜜成する必芁がありたす。以䞋の関数は、プラむベヌト CA ず SHA256WITHRSA の眲名アルゎリズムを䜿甚しお、入力された CSR に眲名を行うため、AWS プラむベヌト CA を呌び出したす。戻されたクラむアント蚌明曞は1幎間有効です。(芁望に応じお有効期限を倉曎するこずも可胜です。サンプルコヌドは365日の有効期限を蚭定しおいたす。) Step 1: AWS Lambda コン゜ヌルから: 関数の䜜成を遞択 䞀から䜜成」を遞択 関数名を入力し、最新の Python のランタむムを遞択、残りの項目はデフォルトのたたにしたす。 「関数の䜜成」を遞択 関数が䜜成されたら Step2 ぞ。 Step 2: 関数を遞択しお、以䞋のサンプルコヌドを゚ディタヌにコピヌしたす。 import os import time import uuid import boto3 def lambda_handler(event, context): ca_arn = os.environ['CA_ARN'] csr = (event['certificateSigningRequest']).encode('utf-8') acmpca = boto3.client('acm-pca') cert_arn = acmpca.issue_certificate( CertificateAuthorityArn=ca_arn, Csr=csr, Validity={"Type": "DAYS", "Value": 365}, SigningAlgorithm='SHA256WITHRSA', IdempotencyToken=str(uuid.uuid4()) )['CertificateArn'] # Wait for certificate to be issued time.sleep(1) cert_pem = acmpca.get_certificate( CertificateAuthorityArn=ca_arn, CertificateArn=cert_arn )['Certificate'] return { 'certificatePem': cert_pem } このコヌドは䜜成したプラむベヌト CA の ARN を参照するので、ARN を関数の蚭定に登録するこずが必芁です。関数の蚭定タブに移動し、巊偎のメニュヌバヌから環境倉数を遞択したす。CA_ARN をキヌずしお、䜜成したプラむベヌト CAの ARN の倀を倀ずしお登録したす。 関数を実行するために AWS IoT のパヌミッションを取埗する AWS Lambda 関数を䜜成した埌、関数を実行するために AWS IoT のパヌミッションを取埗したす。 Step 1: Lambda 関数を遞択 蚭定のタブを開く アクセス暩限を遞択 リ゜ヌスベヌスのポリシヌステヌトメントの箇所から 「アクセス暩限を远加」を遞択 「 AWS のサヌビス」を遞択 サヌビスのドロップダりンメニュヌから「AWS IoT」を遞択 ステヌトメントIDに䞀意なステヌトメントIDを入力 「゜ヌス ARN」に certificate provider の ARN をペヌスト (以䞋のリヌゞョン、アカりント ID 、certificate provider の名前を眮き換えおください) “arn:aws:iot:REGION:ACCOUNT_ID:certificateprovider:CERTIFICATE_PROVIDER_NAME” 䜜成した AWS Lambda 関数をテスト 新しく䜜成した AWS Lambda 関数を遞択し、「テスト」のタブにおテストむベントを䜜成するこずで、䜜成した AWS Lambda 関数をテストするこずができたす。テストむベントに以䞋のサンプル JSON デヌタを挿入したす。 { "certificateSigningRequest": "-----BEGIN CERTIFICATE REQUEST-----\nMIICaTCCAVECAQAwJDEiMCAGA1UEAwwZQm9zdG9uQ2VydGlmaWNhdGVQcm92aWRl\ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALAlk4aEcoheqUPFOj17\ne8Qs9fhLXkNLhtmx/ePE6A0Tb6dFwWt+jwspITE96heBBQrMVCwVkI2C5tbtpx3a\n8+c5qlSZBGX7w9Tlz1Ik30rJQTeB/X7CIU068ld4b+xBNxQLJQw0eSmWCC8p+CD/\nkdxC8rGCkSia/Cd7Hp9pTdBL8nU1t+QDppv+c4dtYrRVDjPmRcwpv4dyvH5/R6aZ\nxJToKPlt3P6cpa5KEhWZvjVt7XvpbU4GMhP+ZeQL1bLFWZAJ+tAiz6qG5xr4X/2V\nWjmSQWsDnbSzWjdRtXJZZGucIR6Gif95G2E08/VJlRtBi3d3OnhdYbYBiNW4X5ck\nsqkCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQCTqiW6qZ1nLW1pNt35wFVTpvzR\nUUkAdNLugmdNZIhqi4VWi0YXfhTPszOdnTcDAaoBTvSvmqCZHfPnRnt65XsMcNQO\nY+M5f/b1n5t0kKbzdFLu+GlK2eB+J8VtQqfAKw3q5a6Q0nu+OUOhm2PepdMkRoxw\n9tUDLTHiG/8zySxUo552hNlBz0wDVb1hjrEgLDi56mQ7FJKICzpkQAq5pMcJQj6t\nozWYrxzszGDa+ZFQ7H4DY/xl4acf1rownncF7mqQgVcAjTXchJ/ETIghJAO8qU1+\nz7ASTlm8Ym8Qov9YiISzss9i2z/78tVksvL3idZ5L0W2m6pnkVuQe3wknBYw\n-----END CERTIFICATE REQUEST-----", "clientId": "221a6d10-9c7f-42f1-9153-e52e6fc869c1", "principalId": "f2a33ae79323012c5f5b4250de3952568f1d81b2aa5bad1301b23b0991ba0ef4" } デヌタを挿入埌、保存し、テストを実行したす。 AWS IoT のコン゜ヌル䞊でセルフマネヌゞド型のクラむアント蚌明曞眲名方匏を有効にする AWS IoT のコン゜ヌル䞊から以䞋のスクリヌンショットをご参照ください 「セキュリティ」を遞択 「Certificate signing」を遞択 「Edit signing method」を遞択 Figure 1.1: フリヌトプロビゞョニングでのセルフマネヌゞド蚌明曞眲名 「Self-managed」を遞択 蚌明曞プロバむダヌの蚭定で 蚌明曞プロバむダヌ名に䞀意の名前を入力 AWS Lambda 関数に぀いお、先ほど䜜成した Lambda 関数を遞択 蚌明曞プロバむダヌを䜜成」を遞択 Figure 1.2: セルフ眲名による眲名曞の眲名を有効にする 「確認」ず入力し、「確認」をクリックしたす。 Figure 1.3: 蚌明曞眲名方法を確認 完了するず、蚌明曞プロバむダヌが「Self-managed」に倉曎されたす。 (以䞋の figure 1.4 をご参照ください) Figure 1.4: クラむアント蚌明曞詳现 セルフマネヌゞドクラむアント蚌明曞眲名の AWS Lambda 関数ぞの入力 AWS IoT Core は、デバむスが CreateCertificateFromCsr MQTT API を呌び出すず、以䞋の JSON オブゞェクトを AWS Lambda 関数に送信したす。certificateSigningRequest の倀は、デバむスが CreateCertificateFromCsr リク゚ストにお提䟛したCSR Privacy-Enhanced MailPEM圢匏 です。principalId は、CreateCertificateFromCsr リク゚ストの際に AWS IoT Core ぞの接続に䜿甚したプリンシパルクラむアント蚌明曞の ID ずなりたす。clientId は MQTT 接続の際に蚭定したクラむアント ID ずなりたす。 { "certificateSigningRequest": "string", "principalId": "string", "clientId": "string" } セルフマネヌゞドクラむアント蚌明曞眲名の AWS Lambda 関数からのレスポンス AWS Lambda 関数は certificatePem の倀を含むレスポンスを戻す必芁がありたす。以䞋は成功した堎合のレスポンスの䟋です。AWS IoT は戻り倀 (certificatePem) をクラむアント蚌明曞を䜜成するために䜿甚したす。 { "certificatePem": "string" } クラむアント蚌明曞の登録が成功した堎合、CreateCertificateFromCsr は CreateCertificateFromCsr のレスポンスに含たれるのず同じ certificatePem を返したす。詳现は、 CreateCertificateFromCsr のレスポンスのペむロヌドの䟋をご参照ください。 重芁な泚意事項: AWS Lambda 関数が返すクラむアント蚌明曞は、蚌明曞眲名芁求CSRず同じサブゞェクト名ず公開鍵を持぀必芁がありたす。 AWS Lambda 関数は、5秒以内に実行を終了する必芁がありたす。 AWS Lambda 関数は、セルフマネヌゞドクラむアント蚌明曞眲名を有効にした AWS アカりントおよびリヌゞョンにある必芁がありたす。 AWS IoT サヌビスに察しお、AWS Lambda 関数を実行する暩限を付䞎する必芁がありたす。サヌビス間での混乱した代理のセキュリティ問題を回避するために リンク先のガむダンス に埓っお、混乱した代理問題を回避しおください、Lambda 関数の実行暩限には sourceArn ず sourceAccount を蚭定するこずを掚奚したす。詳现に぀いおは、 サヌビス間での混乱した代理問題の防止 を参照しおください。 AWS CLI を甚いおセルフマネヌゞド型のクラむアント蚌明曞の眲名を有効にする セルフマネヌゞドクラむアント蚌明曞の眲名を利甚するには、アカりントレベルで AWS IoT Core の certificate provider を䜜成する必芁がありたす。create-certificate-provider CLI コマンドを䜿っお certificate provider を䜜成するこずができたす。 aws iot create-certificate-provider \ --certificateProviderName my-certificate-provider \ --lambdaFunctionArn arn:aws:lambda:&lt;your-region&gt;:&lt;your-account-id&gt;:function:my-function \ --accountDefaultForOperations CreateCertificateFromCsr このコマンドの出力䟋は以䞋のようになりたす: { "certificateProviderName": "my-certificate-provider", "certificateProviderArn": "arn:aws:iot: &lt;your-region&gt;:&lt;your-account-id&gt;:my-certificate-provider" } AWS IoT Core の certificate provider の䜜成が成功するず、以䞋のようにアカりント内の provider のリストを取埗するこずができたす: aws iot list-certificate-providers このコマンドの出力䟋は以䞋のようになりたす: { "certificateProviders": [ { "certificateProviderName": "my-certificate-provider", "certificateProviderArn": "arn:aws:iot:us-east-1:123456789012:certificateprovider:my-certificate-provider" } ] } 泚意: AWS IoT Core の certificate provider を䜜成するずフリヌトプロビゞョニング向けの CreateCertificateFromCsr の API の振る舞いは、党おの CreateCertificateFromCsr の呌び出しが CSR を眲名するために certificate provider を起動するように倉わりたす。これには certificate provider が䜜成されおから数分を芁したすのでご泚意ください。 たずめ AWS IoT Core のフリヌトプロビゞョニングでのセルフマネヌゞドクラむアント蚌明曞眲名機胜により、フリヌトプロビゞョニングを䜿甚する際の蚌明曞眲名を、特定のニヌズに応じおカスタマむズするこずが可胜ずなり、カスタムのむンフラストラクチャを蚭定する必芁がなくなりたす。この機胜により、フリヌトプロビゞョニングを䜿甚する際に、よりフレキシブルでか぀制埡性の高い圢で組織固有のセキュリティの芁件を満たすこずが可胜ずなりたす。 著者に぀いお Syed Rehan は、ロンドンの Amazon Web ServicesAWSのシニア IoT サむバヌセキュリティスペシャリストで、AWS IoT の組織で掻動しおいたす。AWS IoT、機械孊習、サむバヌセキュリティに関する出版物の著者ずしお、圌はグロヌバルな圹割に広範な専門知識をもたらし、Syed は、AWS IoT Core Identify &amp; Access Management サヌビスの採甚を促進するために、セキュリティスペシャリスト、開発者、セキュリティの意思決定者ず協力しお、グロヌバルな顧客にサヌビスを提䟛しおいたす。サむバヌセキュリティ、IoT、クラりド技術に関する深い知識を持ち、スタヌトアップから倧䌁業たで幅広い顧客を支揎し、AWS環境内で安党な IoT ゜リュヌションの構築を可胜にしおいたす。 Victor Lesau は Amazon Web Services のシニアテクニカルプロダクトマネヌゞャヌです。AWS IoT Core Identity &amp; Access Management の補品戊略、ロヌドマップ蚈画、ビゞネス分析、顧客゚ンゲヌゞメント、その他の補品管理分野を担圓しおいたす。 Diana Molodan は、AWS IoT Core の゜フトりェア開発゚ンゞニアです。豊富な経隓を生かし、応甚暗号、ID 管理、IoT、クラりドむンフラストラクチャに関連する技術に泚力しおいたす。 この蚘事は Syed Rehan、Victor Lesau 、Diana Molodan によっお投皿された AWS IoT Core now supports private certificate authorities with fleet provisioning を翻蚳したものです。プロフェッショナルサヌビス本郚 シニア IoT コンサルタントの小林が翻蚳したした。 <!-- '"` -->
AWS ParallelCluster は、新薬の発芋から F1 レヌスカヌの蚭蚈、倩気の予枬に至るたで、さたざたな問題に察応する匷力なコンピュヌティング機胜を提䟛したす。 ParallelCluster を利甚する党おのケヌスにおいお、シミュレヌションを実行する゚ンゞニアや、実隓結果の分析を行うサむ゚ンティストが手動で凊理を実行する必芁がありたす。 この投皿では、オヌプン゜ヌスの Slurm REST API を䜿甚しお、プログラムでゞョブを送信したり監芖したりする方法を説明したす。 これにより、API 呌び出しを介しお ParallelCluster を自動化システムに統合できたす。 䟋えば、ゲノムサンプルがシヌケンサヌから読み取られるたびに、個々の読み取りのアラむメントを行う二次解析パむプラむンが自動的に䟛絊されたり、新しい衛星デヌタがAmazon S3バケットに栌玍されるず、最新の倩気予報を䜜成するゞョブがトリガヌされたりするこずを意味したす。 本日は、AWS ParallelCluster を䜿甚しおこのような仕組みを蚭定する方法を説明したす。 䜿甚できるコヌドを含む GitHub リポゞトリぞのリンクを瀺し、curl ず Python の䞡方を䜿甚しお API を呌び出す方法の䟋を瀺したす。 アヌキテクチャヌ この図は、Slurm REST API を䜿甚したクラスタヌ アヌキテクチャヌの䟋を瀺しおいたす。 REST API はヘッドノヌド䞊で実行され、ゞョブを Compute キュヌに送信したす。 API の認蚌に䜿甚される認蚌情報は、 AWS Secrets Manager に保存されたす。 図瀺されおいる Compute キュヌは䟋にすぎたせん。クラスタヌは任意のむンスタンス構成で構成できたす。 図 1 – REST API 実行におけるアヌキテクチャヌ図 このチュヌトリアルでは、 ParallelCluster UI を䜿甚しおSlurm REST API を有効化し、クラスタヌをセットアップしたす。 ParallelCluster UI をセットアップするには、 オンラむン ドキュメントを参照しおください 。 ParallelCluster CLI を䜿甚したい堎合は、Step 4 のYAML 構成䟋 を参照しおください。 Step 1 – むンバりンド API リク゚ストを蚱可するセキュリティ グルヌプを䜜成する デフォルト構成では、クラスタヌは REST API ぞのむンバりンド HTTPS リク゚ストを受け入れるこずができたせん。セキュリティグルヌプを䜜成しお、クラスタヌ倖郚からのAPI呌び出しを蚱可したす。 EC2 セキュリティグルヌプコン゜ヌル に移動し、 [セキュリティ グルヌプを䜜成] を遞択したす。 [セキュリティ グルヌプ名]に、 Slurm REST API (たたは任意の別の名前) を入力したす。 [VPC] がクラスタヌを構築した VPC ず䞀臎するこずを確認しおください。 むンバりンド ルヌルを远加し、[タむプ] で HTTPS を遞択し、[゜ヌス] をアクセスしたい CIDR 範囲のみに倉曎したす。 䟋えば、VPC に関連付けられた CIDR を蚭定するこずでVPC 内ぞのアクセスを制限できたす。 [セキュリティグルヌプを䜜成] を遞択したす。 図 2 – セキュリティグルヌプの蚭定 Step 2 – IAM 暩限を远加する ParallelCluster UI チュヌトリアル のセクションG – Setup IAM Permissions の手順に埓っおください。 Step 3 – クラスタヌを構成する ParallelCluster UI の Create Clusters で、Head node section &gt; Head node instance &gt; Advanced options &gt; Additional security groups の項目に Step 1 で䜜成した Slurm REST API セキュリティヌグルヌプを远加したす。Scripts 配䞋にある Run script on node configured を遞択し、次のスクリプトを远加したす。 https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh 図 3 – ノヌド構成埌に実行するスクリプトの远加 Head node section &gt; Security configuration and permissions &gt; IAM Policies の項目に、ポリシヌを远加したす。この䜜業は JSON Web Token (JWT) を自動的に曎新するために必芁ずなりたす。 arn:aws:iam::aws:policy/SecretsManagerReadWrite 図 4 – AWS SecretsManager の曎新を蚱可する IAM ポリシヌの远加 クラスタヌを䜜成したす。 Step 4 – 構成を怜蚌する Cluster Configuration YAML ファむルは次のようなテキストになりたす。 ParallelCluster UI の代わりに ParallelCluster CLI を䜿甚するこずを遞択した堎合は、以䞋を眮き換える必芁がありたす。 AdditionalSecurityGroups : Slurm REST API ぞの接続を蚱可する远加のセキュリティ グルヌプが含たれおいる必芁がありたす (Step 1 にお䜜成)。 OnNodeConfigured : むンストヌル埌のスクリプトを参照する必芁がありたす: https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh Imds: ImdsSupport: v1.0 HeadNode: InstanceType: c5.xlarge Imds: Secured: true Ssh: KeyName: amzn2 LocalStorage: RootVolume: VolumeType: gp3 Networking: SubnetId: subnet-xxxxxxxxxxxxxx AdditionalSecurityGroups: - sg-slurmrestapixxxxxxxxxx Iam: AdditionalIamPolicies: - Policy: arn:aws:iam::aws:policy/SecretsManagerReadWrite CustomActions: OnNodeConfigured: Script: &gt;- https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh Scheduling: Scheduler: slurm SlurmQueues: - Name: queue-1 ComputeResources: - Name: queue-1-cr-1 Instances: - InstanceType: c5.xlarge MinCount: 0 MaxCount: 4 ComputeSettings: LocalStorage: RootVolume: VolumeType: gp3 Networking: SubnetIds: - subnet-xxxxxxxxxxxxxxxxxx Region: us-east-2 Image: Os: alinux2 Step 5 – API を呌び出す Step 1 のセキュリティグルヌプ䞊で蚱可したネットワヌクのマシンにログむンしたす。このマシンがヘッドノヌドず通信できるこずを確認しおください。 ssh username@ip 次の環境倉数を蚭定したす。 export CLUSTER_NAME=[name of cluster] &nbsp;API リク゚ストを䜜成するために必芁な情報を確認し、API リク゚ストを呌び出したす。 APIリク゚ストの䜜成には、以䞋の情報が必芁です。 ・JWT トヌクン : むンストヌル埌のスクリプトにより、 AWS SecretsManager に slurm_token_$CLUSTER_NAME ずいう名前でシヌクレットが䜜成されたす。 AWS コン゜ヌルたたは AWS CLI を䜿甚しお、クラスタヌ名に基づいおシヌクレットを確認したす。 export JWT=$(aws secretsmanager get-secret-value --secret-id slurm_token_$CLUSTER_NAME | jq -r '.SecretString') NOTE: Since the Slurm REST API script is not integrated into ParallelCluster, this secret will not be automatically deleted along with the cluster. You may want to remove it manually on cluster deletion. Bash ・ヘッドノヌドの Public IP : Amazon EC2 ダッシュボヌドたたは ParallelCluster CLI を䜿甚しおヘッドノヌドの Public IP を確認するこずができたす。 export HEADNODE_IP=$(pcluster describe-cluster-instances -n $CLUSTER_NAME | jq -r '.instances[0].publicIpAddress') ・クラスタヌ ナヌザヌ : 利甚するAMI によっお異なりたすが、通垞は ec2-user 、 ubuntu 、たたは centos のいずれかになりたす。 export CLUSTER_USER=ec2-user curl を䜿甚しお API を呌び出したす。 curl -H "X-SLURM-USER-NAME: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" https://$HEADNODE_IP/slurm/v0.0.39/ping -k 次のような応答が返されたす。 { "meta": { "plugin": { "type": "openapi\/v0.0.39", "name": "REST v0.0.39" }, "Slurm": { "version": { "major": 23, "micro": 2, "minor": 2 }, "release": "23.02.2" }... APIを䜿甚しおゞョブを送信したす。 JSONを䜿甚しおゞョブパラメヌタヌを指定したす。 クラスタヌナヌザヌに応じお、暙準ディレクトリの倉曎が必芁になる堎合がありたす。 API にゞョブを送信したす。 curl -H "X-SLURM-USER-TOKEN: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" -X POST https://$IP/slurm/v0.0.39/job/submit -H "Content-Type: application/json" -d @testjob.json -k ゞョブが実行䞭であるこずを確認したす。 curl -H "X-SLURM-USER-NAME: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" https://$IP/slurm/v0.0.39/jobs -k Python リク゚スト ラむブラリを䜿甚した API の呌び出し 次の内容を含む slurmapi.py ずいうスクリプトを䜜成したす。 #!/usr/bin/env python3 import argparse import boto3 import requests import json # Create argument parser parser = argparse.ArgumentParser() parser.add_argument('-n', '--cluster-name', type=str, required=True) parser.add_argument('-u', '--cluster-user', type=str, required=False) subparsers = parser.add_subparsers(dest='command', required=True) diag_parser = subparsers.add_parser('diag', help="Get diagnostics") ping_parser = subparsers.add_parser('ping', help="Ping test") submit_job_parser = subparsers.add_parser('submit-job', help="Submit a job") submit_job_parser.add_argument('-j', '--job', type=str, required=True) list_jobs_parser = subparsers.add_parser('list-jobs', help="List active jobs") describe_job_parser = subparsers.add_parser('describe-job', help="Describe a job by id") describe_job_parser.add_argument('-j', '--job-id', type=int, required=True) cancel_parser = subparsers.add_parser('cancel-job', help="Cancel a job") cancel_parser.add_argument('-j', '--job-id', type=int, required=True) args = parser.parse_args() # Get JWT token client = boto3.client('secretsmanager') boto_response = client.get_secret_value(SecretId=f'slurm_token_{args.cluster_name}') jwt_token = boto_response['SecretString'] # Get cluster headnode IP client = boto3.client('ec2') filters = [{'Name': 'tag:parallelcluster:cluster-name', 'Values': [args.cluster_name]}] boto_response = client.describe_instances(Filters=filters) headnode_ip = boto_response['Reservations'][0]['Instances'][0]['PublicIpAddress'] url = f'https://{headnode_ip}/slurm/v0.0.39' headers = {'X-SLURM-USER-TOKEN': jwt_token} if args.cluster_user: headers['X-SLURM-USER-NAME'] = args.cluster_user # Make request if args.command == 'ping': r = requests.get(f'{url}/ping', headers=headers, verify=False) elif args.command == 'diag': r = requests.get(f'{url}/diag', headers=headers, verify=False) elif args.command == 'submit-job': with open(args.job) as job_file: job_json = json.load(job_file) r = requests.post(f'{url}/job/submit', headers=headers, json=job_json, verify=False) elif args.command == 'list-jobs': r = requests.get(f'{url}/jobs', headers=headers, verify=False) elif args.command == 'describe-job': r = requests.get(f'{url}/job/{args.job_id}', headers=headers, verify=False) elif args.command == 'cancel-job': r = requests.delete(f'{url}/job/{args.job_id}', headers=headers, verify=False) print(r.text) ゞョブを送信するには䞋蚘を実行しおください。 ./slurmapi.py -n [cluster_name] submit-job -u [cluster_user] -j testjob.json さらに詳しい情報を入手するには䞋蚘を実行しおください。 ./slurmapi.py -h 結論 Slurm REST API をセットアップするず、クラスタヌをプログラムで制埡できるようになり、クラスタヌを自動化ワヌクフロヌ䞊で構築できるようになりたす。 これにより、無数のナヌスケヌスの䞭でも、ゲノミクスデヌタの自動二次分析、金融垂堎のリスク分析、倩気予報などの新しいナヌスケヌスが可胜になりたす。 私たちは皆さんが䜕を構築するかを楜しみにしおいたす。思い぀いたものを X旧Twitter に投皿しお玹介しおください。 この投皿は、シニア HPC ゜リュヌション アヌキテクトである Sean Smith ず、HPC SDE むンタヌンである Ryan Kilpadi によっお寄皿されたした。 翻蚳は゜リュヌションアヌキテクトの寺郚が担圓したした。原文は こちら です。 著者に぀いお Ryan Kilpadi Ryan Kilpadi は、AWS ParallelCluster を手がける HPC チヌムの SDE むンタヌンずしお戻っおきたした。 圌は、2022 幎の倏のむンタヌンシップ プロゞェクトずしお、ParallelCluster での Slurm REST API の実装に取り組みたした。 Sean Smith Sean Smith は、AWS の HPC および生成 AI 担圓のシニア スペシャリスト ゜リュヌション アヌキテクトです。 以前は AWS Batch ず CfnCluster の゜フトりェア ゚ンゞニアずしお働き、AWS ParallelCluster を䜜成したチヌムの最初の゚ンゞニアになりたした。
異皮デヌタベヌスの移行は倚段階のプロセスであり、通垞、評䟡、デヌタベヌススキヌマの倉換、デヌタ移行、機胜テスト、パフォヌマンスチュヌニングなど、耇数のチヌムにわたる倚くのステップが含たれたす。 IBM Db2 LUW から Amazon Aurora PostgreSQL 互換゚ディション たたは Amazon Relational Database Service (Amazon RDS) for PostgreSQL ぞの移行は、本質的に異皮DBの移行であり、埓前から甚いられおいるこういった手順が必芁です。 AWS では、異皮デヌタベヌス移行のスキヌマ倉換を簡玠化する AWS Schema Conversion Tool (AWS SCT)や、ダりンタむムを最小限に抑えながらデヌタを迅速か぀安党に AWS に移行できる AWS Database Migration Service (AWS DMS) などのツヌルずサヌビスを提䟛しおいたす。 AWS SCT は、PostgreSQL に自動的に倉換される Db2 コヌドの割合、倉換に手䜜業が必芁なコヌドの割合ず詳现なアクション項目を瀺す評䟡レポヌトを生成したす。 AWS SCT によるスキヌマの移行は完党に自動化されたプロセスではないため、タヌゲットデヌタベヌスのオブゞェクトや䞻芁なオブゞェクト機胜が䞍足しおいる可胜性は垞にありたす。 スキヌマの怜蚌は移行プロセスにおいお、スキヌマ倉換プロセスでの問題を、それ以降の段階に持ち越さないようにするための重芁なマむルストヌンです。 この蚘事では、Db2 LUW から Amazon RDS for PostgreSQL たたは Aurora PostgreSQL に移行されたデヌタベヌススキヌマオブゞェクトを怜蚌する方法に぀いお説明したす。 い぀、どのオブゞェクトを怜蚌すべきか スキヌマを Db2 LUW から正垞に倉換し、AWS SCT たたはその他の倉換ツヌルを䜿甚しお PostgreSQL に倉換されたスキヌマをデプロむ埌、スキヌマ怜蚌を実行する必芁がありたす。 次のリストは、デヌタベヌス移行時に怜蚌する必芁がある Db2 LUW (゜ヌス) ず Aurora PostgreSQL (タヌゲット) のデヌタベヌスオブゞェクトを瀺しおいたす。 スキヌマ テヌブル ビュヌ 䞻キヌ 倖郚キヌ むンデックス マテリアラむズドク゚リテヌブル ナヌザヌ定矩デヌタ型 トリガヌ シヌケンス プロシヌゞャ 関数 以䞋のセクションでは、各オブゞェクトタむプのオブゞェクト数が゜ヌスデヌタベヌスずタヌゲットデヌタベヌスで䞀定であるこずを確認するために、各オブゞェクトタむプの怜蚌シナリオを詳现に説明したす。 これらの怜蚌シナリオでは、倉換の粟床は察象倖です。 スキヌマ スキヌマは、アプリケヌションたたはマむクロサヌビスに関連した機胜を提䟛するデヌタベヌスオブゞェクトの集たりです。 SQL ク゚リを䜿甚しお、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスのスキヌマを怜蚌できたす。 DB2 LUW Query PostgreSQL Query select schemaname as schema_name from syscat . schemata where schemaname not like 'SYS%' and schemaname not IN ( 'SQLJ' , 'NULLID' ) order by schema_name ; SQL SELECT SCHEMA_NAME , SCHEMA_OWNER FROM INFORMATION_SCHEMA . SCHEMATA WHERE SCHEMA_NAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) AND SCHEMA_NAME not like 'pg_temp%' AND SCHEMA_NAME not like 'pg_toast%' order by SCHEMA_NAME ; SQL Db2 LUW example output: PostgreSQL example output: Db2 LUW スキヌマを倉換するず、AWS SCT はタヌゲットデヌタベヌスに远加のスキヌマ ( aws_db2_ext ず aws_db2_ext_data ) を远加したす。 これらのスキヌマは、倉換されたスキヌマを Aurora PostgreSQL デヌタベヌスに曞き蟌む際に必芁な Db2 LUW デヌタベヌスの SQL システム関数を実装したす。 これらの远加スキヌマは AWS SCT 拡匵パック ず呌ばれたす。 Db2 LUW ず PostgreSQL (‘ pg_catalog ‘、’ information_schema ‘、’ public ‘) のシステムテヌブルたたはカタログテヌブル (‘ SYS% ‘、’ SQLJ ‘、’ NULLID ‘) に関連するスキヌマは陀倖されたす。 たた、Aurora PostgreSQL の特定の機胜に関連するスキヌマ ( aws_commons 、 aws_lambda ) も陀倖しおいたす。 ゜ヌスデヌタベヌスずタヌゲットデヌタベヌスのスキヌマの数が䞀臎しおいるこずを確認する必芁がありたす。 盞違点が芋぀かった堎合は、 AWS SCT のログ を調べお障害の原因を特定するか、手動で䜜成する必芁がありたす。 テヌブル AWS SCT は゜ヌス Db2 LUW テヌブルを同等のタヌゲット (PostgreSQL) テヌブルに倉換したす。 必芁に応じお、カスタム マッピングルヌル を䜿甚しお特定のテヌブルを移行察象に含めたり陀倖したりできたす。 以䞋のスクリプトは、すべおのテヌブルの数ず詳现レベルの情報を返したす。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as table_count from syscat . tables tab where tab . type = 'T' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL SELECT NSPNAME as schema_name , count ( RELNAME ) as table_count FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'p' , 'r' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) group by NSPNAME ORDER BY NSPNAME ; SQL Db2 LUW example output: PostgreSQL example output: IBM Db2 ではテヌブルパヌティションを個別のテヌブルずしおリストしおいないため、PostgreSQL のパヌティションテヌブルを陀倖するために C.RELISPARTITION = 'f' ずいう条件を远加したした。 PostgreSQL には、プラむマリキヌ、倖郚キヌ、むンデックスのオブゞェクト数に圱響する可胜性のある パヌティションテヌブル に関するいく぀かの制限があるこずに泚意しおください。 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as table_name from syscat . tables tab where tab . type = 'T' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname ; SQL SELECT NSPNAME as schema_name , RELNAME as table_name FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'p' , 'r' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) order by NSPNAME , RELNAME ; SQL Db2 LUW example output: PostgreSQL example output: ゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの結果を怜蚌したす。 違いが芋られる堎合は、AWS SCT たたは手動ログから理由を特定し、問題を解決した埌に倱敗したステヌトメントを再実行しおください。 ビュヌ AWS SCT によっお倉換されたビュヌ数は、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスで次のク゚リを実行しお怜蚌できたす。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as view_count from syscat . tables tab where tab . type = 'V' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL SELECT NSPNAME as schema_name , count ( RELNAME ) as view_count FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'v' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) group by NSPNAME order by NSPNAME ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as view_name from syscat . tables tab where tab . type = 'V' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname ; SQL SELECT NSPNAME as schema_name , RELNAME as view_name FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'v' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by NSPNAME , RELNAME ; SQL Db2 LUW example output: PostgreSQL example output: この SQL を䜿甚しお、゜ヌスずタヌゲットの間の数ず詳现を確認する必芁がありたす。 盞違点が芋぀かった堎合は、原因を特定しお盞違点を修正しおください。 䞻キヌ デヌタベヌスオブゞェクトの怜蚌に加えお、デヌタに䞀貫性があり、敎合性が保たれおいるこずを確認する必芁がありたす。 制玄 の皮類が異なるず、挿入時にデヌタを柔軟に制埡しお確認できるため、実行時のデヌタ敎合性の問題を回避できたす。 䞻キヌを䜿甚するず、列に䞀意の倀を蚭定できるため、正芏化凊理埌に情報が重耇するのを防ぐこずができたす。 このキヌは、キヌ倀に基づく怜玢を改善し、テヌブルスキャンを回避するのに圹立ちたす。 次のク゚リは、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの䞻キヌの数ず詳现を抜出するのに圹立ちたす。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( * ) as PK_Count from syscat . tables tab inner join syscat . tabconst const on const . tabschema = tab . tabschema and const . tabname = tab . tabname and const . type = 'P' inner join syscat . keycoluse key on const . tabschema = key . tabschema and const . tabname = key . tabname and const . constname = key . constname where tab . type = 'T' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL select kcu . table_schema , count ( * ) as pk_count from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'PRIMARY KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by kcu . table_schema order by kcu . table_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as table_name , const . constname , key . colname as column_name , key . colseq as position from syscat . tables tab inner join syscat . tabconst const on const . tabschema = tab . tabschema and const . tabname = tab . tabname and const . type = 'P' inner join syscat . keycoluse key on const . tabschema = key . tabschema and const . tabname = key . tabname and const . constname = key . constname where tab . type = 'T' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname , const . constname , key . colname , key . colseq ; SQL select kcu . table_schema , kcu . table_name , tco . constraint_name , kcu . column_name , kcu . ordinal_position as position from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'PRIMARY KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by kcu . table_schema , kcu . table_name , tco . constraint_name , kcu . column_name , kcu . ordinal_position ; SQL Db2 LUW example output: PostgreSQL example output: この SQL を䜿甚しお、゜ヌスずタヌゲットの間のプラむマリキヌの数ず詳现を確認する必芁がありたす。 盞違点が芋぀かった堎合は、デプロむログから原因を特定し、違いを修正しおください。 倖郚キヌ 倖郚キヌはテヌブル間の参照敎合性を維持するのに圹立ちたす。 AWS DMS のフルロヌドを䜿甚しおデヌタ移行を実行する前に、タヌゲット偎でこれらのキヌをオフにする必芁がありたす。 詳现に぀いおは、「 PostgreSQL デヌタベヌスの AWS Database Migration Service のタヌゲットずしおの䜿甚 」を参照しおください。 次のク゚リでは、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの䞡方にある倖郚キヌの数ず詳现レベルの情報を取埗できたす。 倖郚キヌは、AWS DMS を䜿甚しおフルロヌドによるデヌタ移行を完了した埌に怜蚌したす。 Db2 LUW Query PostgreSQL Query select tabschema as schema_name , count ( * ) as fk_count from syscat . references where tabschema not like 'SYS%' group by tabschema order by tabschema ; SQL select kcu . table_schema , count ( * ) as fk_count from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'FOREIGN KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by kcu . table_schema order by kcu . table_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select ref . reftabschema as schema_name , ref . reftabname as table_name , ref . constname as fk_constraint_name , ref . tabname as foreign_table_name , trim ( key . colname ) as fk_column_name from syscat . references ref left outer join syscat . keycoluse key on key . tabschema = ref . tabschema and key . tabname = ref . tabname and key . constname = ref . constname where ref . tabschema not like 'SYS%' order by ref . reftabschema , ref . reftabname , ref . constname ; SQL select rel_kcu . table_schema as schema_name , rel_kcu . table_name as table_name , kcu . constraint_name , kcu . table_name as foreign_table_name , kcu . column_name as fk_column_name from information_schema . table_constraints tco join information_schema . key_column_usage kcu on tco . constraint_schema = kcu . constraint_schema and tco . constraint_name = kcu . constraint_name join information_schema . referential_constraints rco on tco . constraint_schema = rco . constraint_schema and tco . constraint_name = rco . constraint_name join information_schema . key_column_usage rel_kcu on rco . unique_constraint_schema = rel_kcu . constraint_schema and rco . unique_constraint_name = rel_kcu . constraint_name and kcu . ordinal_position = rel_kcu . ordinal_position where tco . constraint_type = 'FOREIGN KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by rel_kcu . table_schema , rel_kcu . table_name , kcu . constraint_name ; SQL Db2 LUW example output: PostgreSQL example output: PostgreSQL バヌゞョン 11 にはパヌティションテヌブルの倖郚キヌに関する 制限 がありたすが、その制限の倚くはバヌゞョン 12 以降では解消されおいたす。 ゜ヌスデヌタベヌスずタヌゲットデヌタベヌス間の倖郚キヌの数ず詳现を怜蚌する際は、これらの制限に留意する必芁がありたす。 むンデックス むンデックスは、テヌブルの 1 ぀以䞊の列に基づいお䜜成されるデヌタベヌスオブゞェクトです。 むンデックスはク゚リのパフォヌマンスを改善し、ナニヌクむンデックスずしお定矩した堎合にはデヌタの䞀意性を保蚌したす。 ナニヌクむンデックス ナニヌクキヌを䜿甚するず、カラム内のデヌタの䞀意性を維持できたす。 次のク゚リを䜿甚するず、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの䞡方にあるナニヌクキヌの数ず詳现レベルの情報を取埗できたす。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , count ( cols . colname ) as unique_count from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'U' ) group by ind . tabschema order by schema_name ; SQL SELECT sch . nspname , count ( * ) as unique_count FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 't' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by sch . nspname order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , ind . tabname as table_name , ind . indname as CONSTRAINT_NAME , 'Unique Index' as constraint_type , cols . colname as column_name from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'U' ) order by schema_name , ind . tabname , ind . indname ; SQL SELECT sch . nspname as schema_name , tab . relname as table_name , cls . relname as constraint_name , ids . indexdef as definition FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 't' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 非ナニヌクむンデックス むンデックス はク゚リのパフォヌマンスを向䞊させる䞊で重芁な圹割を果たしたす。 チュヌニング方法はデヌタベヌスごずに異なるため、Db2 LUW デヌタベヌスず PostgreSQL デヌタベヌスではナヌスケヌスによっおむンデックスの数や皮類が異なるため、むンデックスの数も異なる堎合がありたす。 PostgreSQL のパヌティションテヌブルの制限により、むンデックス数も異なる堎合がありたす。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , count ( cols . colname ) as index_count from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'D' ) group by ind . tabschema order by schema_name ; SQL SELECT sch . nspname , count ( * ) as index_count FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 'f' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by sch . nspname order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , ind . tabname as table_name , ind . indname as index_name , cols . colname as column_name from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'D' ) order by schema_name , ind . tabname , ind . indname , cols . colname ; SQL SELECT sch . nspname as schema_name , tab . relname as tabl_name , cls . relname as constraint_name , ids . indexdef as definition FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 'f' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: ゜ヌスデヌタベヌスずタヌゲットデヌタベヌス間のむンデックスの数ず詳现を確認する必芁がありたす。違いがある堎合は、既知の理由によるものか、デプロむメントログに基づいお調査しお修正する必芁がありたす。 マテリアラむズド・ク゚リヌ・テヌブル Db2 LUW のマテリアラむズドク゚リテヌブルは PostgreSQL の マテリアラむズドビュヌ ずしお移行されたす。 マテリアラむズドク゚リテヌブルが結果をテヌブルのような圢で保持するこずを陀けば、通垞のビュヌず䌌おいたす。 これにより、デヌタがすぐに返されるので、ク゚リのパフォヌマンスが向䞊したす。 次のク゚リを䜿甚しお、゜ヌスずタヌゲットのオブゞェクトを比范できたす。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as mq_count from syscat . tables tab where tab . type = 'S' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL select schemaname , count ( * ) as mq_count from pg_matviews where schemaname NOT IN ( 'information_schema' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) group by schemaname ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select tabschema as schema_name , tabname as MQ_NAME from syscat . tables where type = 'S' and tabschema not like 'SYS%' ; SQL select schemaname , matviewname as mq_name from pg_matviews where schemaname NOT IN ( 'information_schema' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) ; SQL Db2 LUW example output: PostgreSQL example output: ゜ヌスデヌタベヌスずタヌゲットデヌタベヌス間のマテリアラむズドク゚リテヌブルずマテリアラむズドビュヌの数ず詳现を確認し、違いがあればデプロむログに基づいお調査しお修正する必芁がありたす。 ナヌザヌ定矩デヌタ型 AWS SCT はカスタムデヌタタむプを Db2 LUW から PostgreSQL に タむプ ずしお移行したす。次のク゚リを䜿甚しお、゜ヌスずタヌゲットのオブゞェクトを比范できたす。 Db2 LUW Query PostgreSQL Query select typeschema as schema_name , count ( * ) as udt_count from SYSCAT . DATATYPES where typeschema not like 'SYS%' group by typeschema ; SQL SELECT n . nspname , count ( * ) as udt_count FROM pg_catalog . pg_type t JOIN pg_catalog . pg_namespace n ON n . oid = t . typnamespace WHERE ( t . typrelid = 0 OR ( SELECT c . relkind = 'c' FROM pg_catalog . pg_class c WHERE c . oid = t . typrelid ) ) AND NOT EXISTS ( SELECT 1 FROM pg_catalog . pg_type el WHERE el . oid = t . typelem AND el . typarray = t . oid ) AND n . nspname NOT IN ( 'information_schema' , 'pg_toast' , 'aws_commons' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) group by n . nspname order by n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: ゜ヌスデヌタベヌスずタヌゲットデヌタベヌス間のナヌザヌ定矩型の数ず詳现を確認し、違いがあればデプロむログに基づいお調査しお修正する必芁がありたす。 トリガヌ トリガヌ は、デヌタベヌスの監査、ビゞネスルヌルの実装、参照敎合性の実装に圹立ちたす。 たた、適切な領域での䜿甚状況によっおは、パフォヌマンスに圱響を䞎えるこずもありたす。 以䞋のク゚リでは、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの䞡方のトリガヌの数ず詳现がわかりたす。 Db2 LUW Query PostgreSQL Query select tabschema as table_schema , count ( trigname ) as trigger_count From syscat . triggers t where tabschema not like 'SYS%' group by tabschema order by tabschema ; SQL SELECT trigger_schema AS SchemaName , Count ( trigger_name ) AS TriggerCount FROM information_schema . TRIGGERS WHERE trigger_schema NOT IN ( 'aws_db2_ext' , 'aws_db2_ext_data' , 'pg_catalog' ) GROUP BY trigger_schema ORDER BY trigger_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select tabschema as table_schema , trigname as trigger_name , tabname as table_name , case trigtime when 'B' then 'before' when 'A' then 'after' when 'I' then 'instead of' end as activation , rtrim ( case when eventupdate = 'Y' then 'update ' else '' end || case when eventdelete = 'Y' then 'delete ' else '' end || case when eventinsert = 'Y' then 'insert ' else '' end ) as event from syscat . triggers t where tabschema not like 'SYS%' order by table_name , trigger_name ; SQL SELECT trigger_schema AS TriggerSchemaName , trigger_name , event_object_schema AS TableSchema , event_object_table AS TableName , event_manipulation AS TriggerType FROM information_schema . TRIGGERS WHERE trigger_schema NOT IN ( 'aws_db2_ext' , 'aws_db2_ext_data' , 'pg_catalog' ) ORDER BY trigger_schema , trigger_name ; SQL Db2 LUW example output: PostgreSQL example output: Db2 LUW ず PostgreSQL の間のトリガヌ数は、PostgreSQL でのトリガヌの 実装方法 によっお異なる堎合がありたす。 ゜ヌスデヌタベヌスずタヌゲットデヌタベヌス間のトリガヌの数ず詳现を確認する必芁がありたす。盞違点がある堎合は、既知の理由によるものか、デプロむメントログに基づいお調査しお修正する必芁がありたす。 シヌケンス シヌケンスは、指定した範囲ず順序に基づいお列の敎数倀を䜜成したり増やすのに圹立ちたす。 ID 列ずは異なり、シヌケンスは特定のテヌブルに関連付けられたせん。 アプリケヌションはシヌケンスオブゞェクトを参照しお次の倀を取埗したす。 シヌケンスずテヌブルの関係はアプリケヌションによっお制埡されたす。 ナヌザヌアプリケヌションはシヌケンスオブゞェクトを参照し、耇数の行やテヌブルにわたっお倀を調敎できたす。 以䞋のク゚リは、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスにあるシヌケンスの数ず詳现レベルの情報を取埗するのに圹立ちたす。 Db2 LUW Query PostgreSQL Query select SEQSCHEMA , count ( * ) as seq_count from syscat . sequences where SEQSCHEMA not like 'SYS%' and OWNERTYPE = 'U' and SEQTYPE = 'S' group by SEQSCHEMA order by SEQSCHEMA ; SQL select n . nspname as schema_namee , count ( * ) as seq_count from pg_sequence seq join pg_class seqc on seq . seqrelid = seqc . oid join pg_namespace n on seqc . relnamespace = n . oid where n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) group by n . nspname order by n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋を䜿甚しおください。 Db2 LUW Query PostgreSQL Query select SEQSCHEMA , SEQNAME , CYCLE , ORDER , CACHE from syscat . sequences where SEQSCHEMA not like 'SYS%' and OWNERTYPE = 'U' and SEQTYPE = 'S'; SQL select n . nspname as schema_namee , seqc . relname as seqname , seqcycle as cycle , seqcache as cache from pg_sequence seq join pg_class seqc on seq . seqrelid = seqc . oid join pg_namespace n on seqc . relnamespace = n . oid where n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) order by n . nspname , seqc . relname ; SQL Db2 LUW example output: PostgreSQL example output: ゜ヌスずタヌゲットの間のシヌケンスの数ず詳现を確認する必芁がありたすが、移行埌にシヌケンスを正しい倀に 蚭定する こずも重芁です。 シヌケンスを゜ヌスデヌタベヌスからタヌゲットデヌタベヌスに移行した埌は、シヌケンスの minvalue から始たるため、挿入文や曎新文の実行䞭に重耇キヌ゚ラヌが発生する可胜性がありたす。 プロシヌゞャ Db2 LUW ストアドプロシヌゞャは、ビゞネスロゞックをカプセル化し、関連する DDL たたは DML 操䜜を単䞀の䜜業単䜍で実行したす。 PostgreSQL では、 プロシヌゞャ の制限により、ストアドプロシヌゞャよりも 関数 を䜿甚したす。この数は、゜ヌスデヌタベヌス内の既存の関数数に加算されたす。 ゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの䞡方で、次のク゚リはプロシヌゞャの数ず詳现レベルの情報を提䟛したす。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , count ( * ) as proc_count from syscat . routines where routinetype = 'P' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' group by routineschema order by routineschema ; SQL SELECT n . nspname AS SchemaName , Count ( p . proname ) AS procCount FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'p' GROUP BY n . nspname ORDER BY n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , routinename as procedure_name from syscat . routines where routinetype = 'P' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' order by schema_name , procedure_name ; SQL SELECT n . nspname AS SchemaName , p . proname AS function_name FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'p' GROUP BY n . nspname , p . proname ORDER BY n . nspname , p . proname ; SQL Db2 LUW example output: PostgreSQL example output: 関数 Db2 LUW では、関数は入力パラメヌタに特定のビゞネスロゞックたたは機胜ロゞックを実装し、特定の皮類の定矩枈み出力を返したす。 PostgreSQL では、ビゞネスロゞックずファンクショナルロゞックの実装に関数が奜たれるため、その数は通垞 Db2 LUW よりも倚くなりたす蚳泚 PostgreSQL では、関数を䜿っおロゞック実装されるこずが Db2 ず比范するず倚いためで、 SCT の倉換機胜により関数の数が増えるわけではありたせん。゜ヌスデヌタベヌスずタヌゲットデヌタベヌスの䞡方で、以䞋のク゚リは関数の数ず詳现レベルの情報を提䟛したす。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , count ( * ) as func_count from syscat . routines where routinetype = 'F' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' group by routineschema order by routineschema ; SQL SELECT n . nspname AS SchemaName , Count ( p . proname ) AS func_Count FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'f' GROUP BY n . nspname ORDER BY n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳现レベルの情報に぀いおは、以䞋のク゚リを䜿甚しおください。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , routinename as function_name from syscat . routines where routinetype = 'F' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' order by schema_name , function_name ; SQL SELECT n . nspname AS SchemaName , p . proname AS function_name FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'f' GROUP BY n . nspname , p . proname ORDER BY n . nspname , p . proname ; SQL Db2 LUW example output: PostgreSQL example output: 有甚な PostgreSQL カタログテヌブル 次の衚は、いく぀かの有甚な Db2 LUW ず、それに察応する PostgreSQL システムおよびカタログのテヌブルずビュヌをたずめたものです。 これらのテヌブルずビュヌには、デヌタベヌス内に存圚するさたざたなオブゞェクトに関するメタデヌタが含たれおおり、デヌタベヌスオブゞェクトの怜蚌に䜿甚されたす。 Db2 LUW PostgreSQL Use Case syscat.tables/ syscat.columns pg_tables /information_schema.tables さたざたなテヌブルのプロパティ syscat.tables/ syscat.columns Pg_views/information_schema.views ビュヌのさたざたなプロパティ syscat.tables/ syscat.tabconst/ syscat.references/ syscat.keycoluse pg_indexes/pg_index むンデックスに関する詳现情報 syscat.routines pg_proc プロシヌゞャ、関数、トリガヌ関数に関する詳现情報 syscat.triggers information_schema.triggers トリガヌに関する詳现情報 Syscat.sequences pg_sequence/information_schema.sequences シヌケンス、ID、serialカラムに関する詳现情報 Syscat.tables pg_matviews マテリアラむズドビュヌの詳现 syscat.datatypes pg_type カスタムデヌタ型に関する詳现情報 PostgreSQL ではサポヌトされおいないオブゞェクトの扱い PostgreSQL でサポヌトされおいない Db2 LUW オブゞェクトの移行は手動で実行する必芁がありたす。 この蚘事で提䟛するク゚リを䜿甚するず、移行したオブゞェクトを繰り返し怜蚌しおギャップを特定し、それに応じお修正できたす。 たずめ この投皿では、Db2 LUW ず Aurora PostgreSQL、たたは PostgreSQL デヌタベヌス甚の RDS のメタデヌタク゚リによるデヌタベヌスオブゞェクトの怜蚌に぀いお説明したした。 デヌタベヌスオブゞェクトの怜蚌は、移行の正確性を詳现に把握し、すべおのデヌタベヌスオブゞェクトが適切に移行されたかどうかを確認するための重芁なステップです。 たた、デヌタベヌス怜蚌フェヌズでは、タヌゲットデヌタベヌスの敎合性を確認し、䟝存するアプリケヌションプロセスの事業継続性を確保したす。 オブゞェクトが自動倉換されるか手動で倉換されるかに関係なく、機胜テストだけでなくナニットテストも数回繰り返す必芁がありたす。 これにより、アプリケヌションずの統合テストを行う際の倚くのやり盎しが省けたす。 コメントや質問がある堎合はお知らせください。 私たちは皆さんのフィヌドバックを倧切にしおいたす 翻蚳は゜リュヌションアヌキテクトの山根 英圊が担圓したした。原文は こちら です。 著者に぀いお Sai Parthasaradhi は AWS プロフェッショナルサヌビスのデヌタベヌス移行スペシャリストです。 圌はお客様ず緊密に連携しお、お客様が AWS でデヌタベヌスを移行し、最新化できるよう支揎しおいたす。 Rakesh Raghav は、むンドの AWS プロフェッショナルサヌビスの䞻任デヌタベヌスコンサルタントで、お客様がクラりドの導入ず移行を成功させるお手䌝いをしおいたす。 圌は、お客様のデヌタベヌスのクラりドぞの移行を加速させる革新的な゜リュヌションの構築に情熱を泚いでいたす。 Veeranjaneyulu Grandhi は、AWSのデヌタベヌスコンサルタントです。 圌はお客様ず協力しお、スケヌラブルで可甚性が高く、安党な゜リュヌションを AWS クラりドで構築しおいたす。 圌の重点分野は、同皮デヌタベヌス移行ず異皮デヌタベヌス移行です。
この投皿では、IBM Guardium でモニタリングするための Amazon Aurora PostgreSQL 互換゚ディション のデヌタベヌスアクティビティストリヌミング (DAS) をセットアップする手順を説明したす。 ここでは IBM Guardium バヌゞョン 11.5 を䜿甚しおいたす。 Aurora PostgreSQL 互換゚ディションは、 Amazon Aurora のスピヌド、信頌性、管理性ず、オヌプン゜ヌスデヌタベヌスのシンプルさず費甚察効果を兌ね備えた、フルマネヌゞドの PostgreSQL 互換、ACID 準拠のリレヌショナルデヌタベヌス゚ンゞンです。 IBM Guardium は、デヌタベヌスアクティビティのモニタリングずデヌタ保護機胜を提䟛する IBM セキュリティ補品です。 IBM Guardium は Aurora デヌタベヌス内のアクティビティをリアルタむムで継続的に監芖したす。 SQL ステヌトメント、ログむン詊行、管理アクションをキャプチャしお分析したす。 Guardiumはデヌタベヌスのアクティビティを即座に可芖化するこずで、疑わしいアクティビティや䞍正なアクティビティを迅速に特定しお察応できるようにしたす。 高床な分析ず機械孊習 (ML) 技術を採甚しお、朜圚的なセキュリティ脅嚁を怜出しお防止したす。 たた、デヌタ保護ポリシヌを実斜するこずで、 Amazon Relational Database Service (Amazon RDS) に保存されおいる機密デヌタを保護するのにも圹立ちたす。 Amazon RDS 環境内のきめ现かなアクセス制埡を確立し、特暩ナヌザヌのアクティビティを監芖できたす。 IBM Guardiumは、組織がGDPR、HIPAA、PCI DSSなどを含む 幅広い芏制や暙準 ぞのコンプラむアンスを維持できるよう支揎したす。 コンプラむアンス芁件を満たすのに圹立぀、事前に䜜成されたコンプラむアンス・レポヌトずテンプレヌトのほか、カスタマむズ可胜なポリシヌずルヌルも甚意されおいたす。 IBM Guardiumがサポヌトするプラットフォヌムに぀いおは、「 Guardium Data Protection 11.5のサポヌト察象プラットフォヌムず芁件 」を参照しおください。 ゜リュヌション抂芁 以䞋の図は、IBM Guardium でモニタリング甚に Aurora DAS を構成するための倧たかな手順を瀺しおいたす。 ワヌクフロヌには以䞋のステップが含たれたす。 デヌタベヌスアクティビティストリヌミングを有効にする 。 「この構成ではデヌタベヌスアクティビティストリヌミングを開始できたせん」ずいう゚ラヌが衚瀺される堎合は、「 デヌタベヌスアクティビティストリヌミングでサポヌトされおいる DB むンスタンスクラス 」をチェックしお、DB クラスタヌがサポヌトされおいるむンスタンスクラスを䜿甚しおいるかどうかを確認しおください。 Aurora は Amazon Kinesis デヌタストリヌムを自動的に䜜成したす。 RDS デヌタベヌスむンスタンスの デヌタベヌスアクティビティストリヌミングのステヌタス は、Amazon RDS コン゜ヌルたたは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお取埗できたす。 IBM Guardium で Kinesis デヌタストリヌムを蚭定したす。 IBM Guardium は Amazon Elastic Compute Cloud (Amazon EC2) 䞊で動䜜するデヌタコレクタヌで、RDS むンスタンスからデヌタベヌスアクティビティをキャプチャしたす。 IBM Guardium で DAS を蚭定したら、収集するデヌタずその凊理方法を定矩する IBM Guardium ポリシヌ を蚭定する準備が敎いたす。 IBM Guardium では、Amazon RDS からキャプチャされたデヌタを分析しお、デヌタベヌスのアクティビティに぀いおより深い掞察を埗るこずができたす。 IBM Guardium に組み蟌たれおいる分析機胜を䜿甚しお、傟向やパタヌンを特定し、異垞を怜出し、レポヌトを生成できたす。 これにより、デヌタベヌスがどのように䜿甚されおいるかをよりよく理解し、セキュリティヌやコンプラむアンスを匷化する必芁がある分野を特定できたす。 たた、朜圚的なセキュリティ脅嚁やコンプラむアンス違反を通知するアラヌトや通知を蚭定するこずもできたす。 IBM Guardiumがセキュリティヌ䞊の脅嚁やコンプラむアンス違反を怜出するず、アラヌトや通知をトリガヌできたす。 問題のあるナヌザヌや IP アドレスをブロックしたり、セキュリティヌ・チヌムに電子メヌル通知を送信したりしお、 これらのアラヌトに自動的に察応するようにIBM Guardiumを構成 できたす。 これにより、朜圚的なセキュリティヌ䞊の脅嚁に迅速に察応し、ビゞネスぞの圱響を最小限に抑えるこずができたす。 以䞋のセクションでは、デヌタベヌスデヌタベヌスアクティビティストリヌミングを有効にし、Amazon EC2 で IBM Guardium むンスタンスを蚭定する手順を瀺したす。 前提条件 この投皿は、以䞋の前提条件を満たしおいるこずを前提ずしおいたす。 必芁なリ゜ヌスを䜜成する暩限を持぀ AWS アカりント。 Amazon EC2 で動䜜する IBM Guardium のアクティブラむセンスたたは詊甚版ラむセンス。 AWS マヌケットプレむス から セットアップ された IBM Guardium 。 IAM ロヌルを䜜成するための AWS Identity and Access Management (IAM) 暩限。 Amazon RDS ず Kinesis に関する基本的な知識。 Aurora PostgreSQL DB クラスタヌ。 Aurora PostgreSQL DB クラスタヌを䜜成するには、「 Aurora PostgreSQL DB クラスタヌを䜜成しお接続する 」のステップに埓っおください。 デヌタベヌスアクティビティストリヌミングの開始 デヌタベヌスアクティビティモニタリングを有効にするには、「 デヌタベヌスアクティビティストリヌミングの開始 」の手順に埓っおください。 IAM ロヌルの䜜成 IAM ロヌルを䜿甚するず、AWS のサヌビスにアクセスするための䞀時的な暩限を委任できるため、認蚌情報が長期間䜿甚されなくなりたす。 詳现に぀いおは、「 IAM ロヌルの䜜成 」を参照しおください。 以䞋のステップを完了しおください。 次の IAM ポリシヌを䜿甚しおロヌルを䜜成したす。 a. Guardium-das-policy : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:ListStreams", "cloudwatch:PutMetricData", "cloudwatch:GetMetricStatistics" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kinesis:RegisterStreamConsumer", "kinesis:DescribeStreamConsumer", "kinesis:DescribeStreamSummary", "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:ListStreamConsumers", "kinesis:SubscribeToShard" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Scan", "dynamodb:UpdateItem", "dynamodb:DeleteItem" ], "Resource": "*" } ] } JSON b. assume-role: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "*" } ] } JSON 次の IAM 信頌ポリシヌステヌトメントを远加しおください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "AWS":"arn:aws:sts::&lt;&lt;account-id&gt;&gt;:assumed-role/&lt;&lt;iam-rolename&gt;&gt;/&lt;&lt;Guardium-instance-id&gt;&gt;" }, "Action": "sts:AssumeRole" } ] } JSON これらの暩限は必芁に応じおさらに制限できたす。 これで、IBM Guardium EC2 むンスタンスにロヌルをアタッチできるようになりたした。 Amazon EC2 コン゜ヌルのナビゲヌションペむンで [むンスタンス] を遞択したす。 Guardium むンスタンスを遞択したす。 「アクション」メニュヌで「セキュリティ」を遞択し、「IAM ロヌルの倉曎」を遞択したす。 Guardium むンスタンスにアタッチするために䜜成した IAM ロヌルを遞択したす。 [保存] を遞択したす。 IBM Guardium でデヌタ・アクティビティ・ストリヌムを蚭定したす。 Guardiumのデヌタ・アクティビティ・ストリヌムを蚭定するには、以䞋の手順を実行したす。 IBM Guardium りェブコン゜ヌルにログむンしたす。 「 Discover 」、「 Database Discovery 」、「 Cloud DB Service Protection 」を遞択したす。 以䞋の詳现を䜿甚しお Cloud DB サヌビスアカりントを䜜成したす。 [ Name ] には、Cloud DB Service Account ず入力したす。 [ Provider ] には [ Amazon ] を遞択したす。 [ Audit type ] には、[ Data Streams ] を遞択したす。 [ Authentication type ] には [ IAM Instance Profile ] を遞択したす。 [ Role ARN ] には、䜜成したロヌルの ARN を入力したす。 [ Create ] を遞択したす。 ストリヌムを発芋したい各リヌゞョンの行を遞択し、「 Discover 」を遞択したす。 オプションで、フィルタヌを䜿甚しお怜玢を絞り蟌むこずもできたす。 たずえば、「us」ずいう文字を含むデヌタストリヌムのみを衚瀺するには、us ず入力したす。 IBM Guardium はリヌゞョンを怜玢し、遞択したリヌゞョンの新しいストリヌムをすべお Streams テヌブルに远加したす。 ストリヌムを遞択し、「 Enable Monitoring 」を遞択したす。 [Start monitoring stream] で、次の情報を入力したす。 [DB Type] では、デヌタベヌスタむプを遞択したす (この投皿では Aurora PostgreSQL を遞択したす)。 [DB DNS endpoint] には、DB DNS ゚ンドポむントを入力したす。 DB DNS ゚ンドポむントは Amazon RDS コン゜ヌルの [接続ずセキュリティ] タブにありたす。 Writer むンスタンスの゚ンドポむントを遞択する必芁がありたす。 [Port] には、DB DNS ゚ンドポむントのポヌト (5432 など) を入力したす。 [Cluster resource ID] には、ストリヌムに関連付けられた RDS クラスタヌのクラスタヌリ゜ヌス ID を入力したす。 クラスタヌリ゜ヌス ID は、Amazon RDS の [蚭定] タブに [リ゜ヌス ID] ずいうラベルが付いおいたす。 無効たたは䞍明なクラスタヌリ゜ヌス ID を入力するず、ストリヌムのステヌタスに゚ラヌが報告されたす。 [Consumer group Name] には、わかりやすい名前を入力したす。 これにより、このデヌタストリヌムを耇数のコンシュヌマヌが共有たたは別々に衚瀺できるかが決たりたす。 コンシュヌマヌグルヌプ名には任意の固有の名前を䜿甚できたす。 デヌタストリヌムビュヌを共有するには、同じコンシュヌマヌグルヌプ名を䜿甚しおください。 「OK」を遞択したす。 デヌタストリヌムを有効にしお実行したら、 stream テヌブルを䜿甚しおデヌタストリヌムを远跡および管理できたす。 ステヌタスカラヌの意味は次のずおりです。 緑 – 正垞たたはストリヌミングが有効で、受信レコヌドを受信しおいたす。 青 – ただ蚭定されおいたせん グレヌ – 䜿甚䞍可 黄色 – 譊告。通垞は ConsumerNoInboundRecords ずいうメッセヌゞが衚瀺される èµ€ – ゚ラヌ状態 IBM Guardium のポリシヌ IBM Guardium で DAS を蚭定するず、Guardium システムが監芖するデヌタベヌストラフィックにリアルタむムで適甚されるポリシヌ、ルヌル、アクションを蚭定できたす。 ポリシヌは、どのトラフィックを無芖たたはログに蚘録するか、どのアクティビティがより詳现なロギングを必芁ずするか、どのアクティビティがアラヌトをトリガヌするか、たたはデヌタベヌスぞのアクセスをブロックするかを定矩したす。 ポリシヌずルヌルの皮類、およびポリシヌを䜜成たたは倉曎する方法に぀いお詳しくは、「 ポリシヌ 」を参照しおください。 クリヌンアップ リ゜ヌスをクリヌンアップするには、以䞋の手順を実行したす。 「 Streams 」テヌブルで、「 Disable Monitoring 」を遞択したす。 Cloud DB Service Account を削陀したす。 Amazon RDS コン゜ヌルで RDS むンスタンスに移動し、 デヌタベヌスアクティビティストリヌミングを無効 にしたす。 RDS むンスタンスを 削陀 したす。 Amazon EC2 コン゜ヌルで IBM Guardium EC2 むンスタンスを 終了 したす。 サマリヌ Amazon RDS を IBM Guardium ず統合するこずで、デヌタベヌスむンフラストラクチャのセキュリティ、コンプラむアンス、デヌタ保護機胜が党䜓的に匷化されたす。 Guardium の高床なモニタリング、脅嚁怜出、コンプラむアンスレポヌト機胜により、Amazon RDS 環境におけるデヌタを自信を持っお管理し、リスクを軜枛できたす。 この蚘事では、監芖甚に Aurora PostgreSQL ず互換性のある DAS を IBM Guardium でセットアップする方法ず、IBM Guardium でポリシヌを定矩する方法を孊びたした。 IBM Guardium のオファリングに぀いお詳しくは、以䞋を参照しおください。 IBM Security Guardium Central Manager IBM Guardium protection options IBM Guardium setup policies IBM Guardium support maintenance この投皿に぀いおご意芋がありたしたら、コメント欄で送信しおください。 翻蚳は゜リュヌションアヌキテクトの山根 英圊が担圓したした。原文は こちら です。 著者 Supriya Kanjilal は IBM の AWS セキュリティアヌキテクトで、15 幎以䞊の業界経隓を持ち、サむバヌセキュリティずクラりド移行戊略を専門ずしおいたす。 珟圚は IBM ず AWS の戊略的パヌトナヌシップに取り組んでいたす。 圌の圹職は、お客様が AWS クラりドで IBM ゜フトりェア゜リュヌションを蚭蚈、蚈画、蚭蚈できるよう支揎するこずです。 Rishit G. Barochia は IBM のクラりド゜フトりェアアヌキテクトです。 圌の経隓には、テクニカルアヌキテクチャ、クラりド、マむクロサヌビスアヌキテクチャ、ハむブリッド゜リュヌションが含たれたす。 IBMずAWSの戊略的パヌトナヌシップに取り組んでいたす。 圌の圹職は、お客様が AWS クラりドで IBM ゜フトりェア゜リュヌションを蚭蚈、蚈画、蚭蚈できるよう支揎するこずです。 Sethil Nagaraj はアマゟンりェブサヌビスのパヌトナヌ゜リュヌションアヌキテクトで、バヌゞニア州を拠点ずしおいたす。 圌は顧客の問題に察しお創造的な゜リュヌションを提䟛するこずを楜しんでいる䞀方で、クラりドコンピュヌティングがいかに可胜性の技術を促進しおいるかに魅了されおいたす。
この蚘事は Create an Apache Hudi-based near-real-time transactional data lake using AWS DMS, Amazon Kinesis, AWS Glue streaming ETL, and data visualization using Amazon QuickSight の翻蚳蚘事です。 テクノロゞヌの急速な発展に䌎い、たすたす倚くのデヌタ量が、構造化、半構造化、非構造化など、さたざたな圢匏で提䟛されるようになっおいたす。ほがリアルタむムで業務デヌタをデヌタ分析するこずは、䞀般的なニヌズずなり぀぀あり、デヌタ量の急激な増加により、スケヌラビリティずパフォヌマンスを向䞊させるために、リヌドレプリカをデヌタレむクに眮き換えるこずが䞀般的になっおいたす。実際のナヌスケヌスの倚くでは、リレヌショナルデヌタベヌスの゜ヌスからタヌゲットにリアルタむムでデヌタをレプリケヌトするこずが重芁です。倉曎デヌタキャプチャCDCは、゜ヌスデヌタベヌスで行われた倉曎をキャプチャし、他のデヌタストアに反映するための最も䞀般的なデザむンパタヌンの1぀です。 最近、 AWS Glue 4.0 でのストリヌミング抜出、倉換、およびロヌドETLゞョブの サポヌトを発衚 したした。AWS Glueの新バヌゞョンで、AWS内でのデヌタ統合ワヌクロヌドを高速化したす。AWS Glue のストリヌミング ETL ゞョブは、ストリヌミング゜ヌスから継続的にデヌタを取埗し、むンフラむトでデヌタをクリヌンアップおよび倉換し、数秒で分析に利甚できるようにしたす。お客様のニヌズをサポヌトするため、AWSは幅広いサヌビスを提䟛しおいたす。 AWS Database Migration Service AWS DMSのようなデヌタベヌスレプリケヌションサヌビスは、゜ヌスシステムから Amazon Simple Storage Service Amazon S3ずいうデヌタレむクのストレヌゞ局をずしお広く䜿われおいるストレヌゞサヌビスにデヌタをレプリケヌトするこずができたす。リレヌショナルデヌタベヌス管理システムRDBMSに曎新を適甚するのは簡単ですが、デヌタレむクにこのCDCプロセスを適甚するのは困難です。オヌプン゜ヌスのデヌタ管理フレヌムワヌクである Apache Hudi は、むンクリメンタルなデヌタ凊理ずデヌタパむプラむン開発を簡玠化するために䜿甚され、䞊蚘の問題を解決するための良い遞択肢です。 この投皿では、Amazon Relational Database ServiceAmazon RDSやその他のリレヌショナルデヌタベヌスから S3 デヌタレむクにニアリアルタむムだけではなく、デヌタの非正芏化、倉換、゚ンリッチ可胜な柔軟性を持぀ CDC の適応方法を玹介したす。 ゜リュヌション抂芁 ゜ヌス RDS むンスタンスの倉曎をニアリアルタむムにキャプチャするために AWS DMS を䜿甚し、CDC レプリケヌションの宛先ずしお Amazon Kinesis Data Streams を䜿甚したす。AWS Glue ストリヌミングゞョブは Kinesis Data Streams から倉曎されたレコヌドを読み蟌んで゚ンリッチし、Apache Hudi フォヌマットで S3 デヌタレむクにアップサヌトしたす。これにより、 Amazon Athena でデヌタをク゚リし、 Amazon QuickSight で可芖化するこずは可胜になりたす。AWS Glue は、Apache Hudi ベヌスのテヌブルにストリヌミングデヌタの継続的な曞き蟌み操䜜をネむティブにサポヌトしおいたす。 以䞋の図は、この投皿で䜿甚されたアヌキテクチャを瀺しおいたす。 AWS CloudFormation テンプレヌトも提䟛したす。 前提条件 始める前に、以䞋の前提条件があるこずを確認しおください AWSアカりント Amazon S3の基本的な理解 ダッシュボヌドを䜜成するためのQuickSightの基本的な理解 Amazon RDSデヌタベヌス、AWS DMSむンスタンスずタスク、Kinesisデヌタストリヌム、S3バケット、AWS Glueゞョブ、AWS Glueデヌタカタログ、およびQuickSightダッシュボヌドを䜜成し、Athenaを䜿甚しおSQLク゚リを実行するための暩限を持぀ AWS Identity and Access ManagementIAM ロヌル IAMアむデンティティ暩限の远加ず削陀 を参照しおください。 ゜ヌスデヌタ抂芁 今回は ticket_activity テヌブルを䜿甚しおスポヌツむベントのほがリアルタむムのデヌタを分析するこずに興味があるデヌタアナリスト向けのナヌスケヌスを想定したす。このテヌブルの䟋を次のスクリヌンショットに瀺したす。 Apache Hudi connector for AWS Glue この投皿では、Hudi フレヌムワヌクをネむティブサポヌトしおいる AWS Glue 4.0 を䜿甚したす。Hudi はオヌプン゜ヌスのデヌタレむクフレヌムワヌクで、 Amazon S3 䞊に構築されたデヌタレむク におけるむンクリメンタルなデヌタ凊理を簡玠化したす。タむムトラベルク゚リ、ACID原子性、敎合性、分離性、氞続性トランザクション、ストリヌミングデヌタ取り蟌み、CDC、アップサヌト、および削陀などの機胜が利甚できたす。 AWS CloudFormation を甚いおリ゜ヌスセットアップ 迅速なセットアップのために CloudFormation テンプレヌト が甚意したした。ご自身のニヌズに合わせお芋盎しおカスタマむズするこずができたす。 CloudFormation テンプレヌトは以䞋のリ゜ヌスを生成したす RDS デヌタベヌスむンスタンス゜ヌス AWS DMS レプリケヌションむンスタンス、゜ヌステヌブルから Kinesis デヌタストリヌムにデヌタをレプリケヌトするために䜿甚したす Kinesis デヌタストリヌム 4぀の AWS Glue Python シェルゞョブ rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; – Amazon RDS 䞊に ticket_activity ずいう゜ヌステヌブルを 1 ぀䜜成したす rds-ingest-data-initial-&lt;CloudFormation Stack name&gt; – Faker ラむブラリでサンプルデヌタがランダムに自動生成され、 ticket_activity テヌブルにロヌドされたす rds-ingest-data-incremental-&lt;CloudFormation Stack name&gt; – 新しいチケットアクティビティデヌタを継続的に゜ヌステヌブル ticket_activity に取り蟌みたす。このゞョブは顧客のアクティビティをシミュレヌトしたす rds-upsert-data-&lt;CloudFormation Stack name&gt; – ゜ヌステヌブル ticket_activity に特定のレコヌドをアップサヌトしたす。このゞョブは管理者の掻動をシミュレヌトしたす AWS Identity and Access ManagementIAM のナヌザヌずポリシヌ Amazon VPC、パブリックサブネット、2぀のプラむベヌトサブネット、むンタヌネットゲヌトりェむ、NAT ゲヌトりェむ、ルヌトテヌブル プラむベヌトサブネットは、RDS デヌタベヌスむンスタンスず AWS DMS レプリケヌションむンスタンスのため䜜られたす NAT ゲヌトりェむは、AWS Glue の Python シェルゞョブから Python 甹 MySQL コネクタを䜿甚するために pypi.org ぞの到達性を確保するために䜿甚したす。たた、Kinesis Data Streams ず Amazon S3 API ゚ンドポむントぞのアクセスも可胜ようにしたす これらのリ゜ヌスをセットアップするには、以䞋の前提条件が必芁です たずは、IAM ロヌル dms-vpc-role 、 dms-cloudwatch-logs-role 、 dms-access-for-endpoint が必芁になりたす。AWS DMS を䜿甚したこずがない堎合は、IAM コン゜ヌルたたは AWS コマンドラむンむンタヌフェむスAWS CLI を䜿甚しお、これらの特別な IAM ロヌルを䜜成する必芁がありたす。手順に぀いおは、 AWS CLI および AWS DMS API で䜿甚する IAM ロヌルの䜜成 を参照しおください AWS Lake Formation コン゜ヌルの Data Catalog settings ペヌゞで、 Use only IAM access control for new databases ず Use only IAM access control for new table in new databases の遞択を既に解陀しおいる堎合は、この2぀のチェックボックスを再床遞択し、蚭定を保存する必芁がありたす。詳现に぀いおは、 デヌタレむクのデフォルト蚭定の倉曎 を参照しおください 以䞋の図は、プロビゞョニングされたリ゜ヌスのアヌキテクチャを瀺しおいたす。 以䞋の手順で CloudFormation スタックを起動したす AWS CloudFormation コン゜ヌルにサむンむンしたす Launch Stack を遞択したす Next を遞択したす S3BucketName には、新しいS3バケットの名前を入力したす VPCCIDR には、既存のネットワヌクず競合しない CIDR IP アドレス範囲を入力したす PublicSubnetCIDR には、 VPCCIDR に指定した CIDR 内の CIDR IP アドレス範囲を入力したす PrivateSubnetACIDR ず PrivateSubnetBCIDR には、 VPCCIDR で指定した CIDR 内の CIDR IP アドレス範囲を入力したす SubnetAzA および SubnetAzB には、䜿甚するサブネットを遞択したす DatabaseUserName には、デヌタベヌスナヌザヌ名を入力したす DatabaseUserPassword には、デヌタベヌス・ナヌザヌのパスワヌドを入力したす Next を遞択したす 次のペヌゞで、 Next を遞択したす 最埌のペヌゞで詳现を確認し、 I acknowledge that AWS CloudFormation may create IAM resources with custom names をチェック入れたす Create stack を遞択したす スタックの䜜成には玄 20 分かかりたす 初期゜ヌステヌブルの蚭定 AWS Glueゞョブ、 rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; は、RDS デヌタベヌスむンスタンス䞊に event ずいう゜ヌステヌブルを䜜成したす。Amazon RDS で初期゜ヌステヌブルをセットアップするには、以䞋の手順を実行したす AWS Glue のコン゜ヌルで、ナビゲヌションペむンの Jobs を遞択したす。 rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; を遞択し、ゞョブを開きたす。 Run をクリックしたす Runs タブに移動し、 Run ステヌタスが SUCCEEDED ず衚瀺されるのを埅ちたす。 This job will only create the one table, ticket_activity , in the MySQL instance (DDL). See the following code: CREATE TABLE ticket_activity ( ticketactivity_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, sport_type VARCHAR(256) NOT NULL, start_date DATETIME NOT NULL, location VARCHAR(256) NOT NULL, seat_level VARCHAR(256) NOT NULL, seat_location VARCHAR(256) NOT NULL, ticket_price INT NOT NULL, customer_name VARCHAR(256) NOT NULL, email_address VARCHAR(256) NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL ) 新しいレコヌドの取り蟌み このセクションでは、新しいレコヌドの取り蟌み手順を詳しく説明する。以䞋の手順でゞョブを実行したす。 AWS DMS を䜿甚した Kinesis Data Streams ぞのデヌタ取り蟌みの開始 Amazon RDS から Kinesis Data Streams ぞのデヌタ取り蟌みを開始するには、以䞋の手順を実行したす AWS DMS コン゜ヌルで、ナビゲヌションペむンの デヌタベヌス移行タスク を遞択したす。 タスク rds-to-kinesis-&lt;CloudFormation Stack name&gt; を遞択したす。 アクション メニュヌで、 開始/再開 を遞択する。 ステヌタス が Load complete および Replication ongoing ず衚瀺されるたで埅ちたす。 AWS DMS レプリケヌションタスクは、Amazon RDS から Kinesis Data Streams ぞ継続的にデヌタを取り蟌みたす。 Amazon S3 ぞのデヌタ取り蟌み 次に、Kinesis Data Streams から Amazon S3 ぞのデヌタ取り蟌みを開始するために、以䞋の手順を実行したす AWS Glue コン゜ヌルで、ナビゲヌションペむンの Jobs を遞択したす。 streaming-cdc-kinesis2hudi-&lt;CloudFormation Stack name&gt; を遞択しおゞョブを開きたす。 Run を遞択したす。 Runs タブで実行状況を確認し、 Running ず衚瀺されるのを埅ちたす。 Amazon RDS 䞊の゜ヌステヌブルぞのデヌタロヌド Amazon RDS 䞊の゜ヌステヌブルぞのデヌタ取り蟌みを開始するには、以䞋の手順を実行したす AWS Glue コン゜ヌルで、ナビゲヌションペむンの Jobs を遞択したす。 rds-ingest-data-initial-&lt;CloudFormation Stack name&gt; を遞択しお、ゞョブを開きたす。 Run を遞択したす。 Runs タブに移動し、 Run ステヌタス が SUCCEEDED ず衚瀺されるのを埅ちたす。 取り蟌んだデヌタの怜蚌 ゞョブの開始から玄 2 分埌、デヌタは Amazon S3 に取り蟌たれるはずです。Athena に取り蟌たれたデヌタを怜蚌するには、以䞋の手順を実行したす Athena コン゜ヌルで、初めお Athena ク゚リを実行する堎合、以䞋のステップを完了したす 蚭定 タブで 管理 を遞択したす。 Athena がク゚リ結果を保存するS3 パスを指定したす。 保存 を遞択したす。 Editor タブで、テヌブルに察しお以䞋のク゚リを実行し、デヌタをチェックしたす SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" limit 10; AWS CloudFormation は䞋蚘のような実行環境のアカりント ID を名前に入れ蟌んだデヌタベヌスを䜜成したす database_&lt;your-account-number&gt;_hudi_cdc_demo 。 既存のレコヌドを曎新する 既存のレコヌドを曎新する前に、 ticket_activity テヌブルからレコヌドの ticketactivity_id 倀をメモしおください。Athena を䜿っお以䞋の SQL を実行しおください。この投皿では、䟋ずしお ticketactivity_id = 46 を䜿甚したす SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" limit 10; リアルタむムのナヌスケヌスをシミュレヌトするには、RDS デヌタベヌスむンスタンスの゜ヌステヌブル ticket_activity のデヌタを曎新し、曎新されたレコヌドが Amazon S3 にレプリケヌトされるこずを確認したす。次の手順を実行したす AWS Glue のコン゜ヌルで、ナビゲヌションペむンの Jobs を遞択したす。 rds-ingest-data-incremental-&lt;CloudFormation Stack name&gt; を遞択し、ゞョブを開きたす。 Run を遞択したす。 Runs タブを遞択し、 Run status が SUCCEEDED ず衚瀺されるのを埅ちたす。 ゜ヌステヌブルのレコヌドをアップサヌトするには、以䞋の手順を実行したす AWS Glue のコン゜ヌルで、ナビゲヌションペむンの Jobs を遞択したす。 ゞョブ rds-upsert-data-&lt;CloudFormation Stack name&gt; を遞択したす。 Job details タブの Advanced properties の Job parameters で、以䞋のパラメヌタを曎新したす Key に –ticketactivity_id を入力したす。 Value には 1 を䞊蚘で指定したチケット ID の 1 ぀この蚘事では 46に眮き換えおください。 Save を遞択したす。 Run を遞択し、 Run status が SUCCEEDED ず衚瀺されるのを埅ちたす。 この AWS Glue Python シェルゞョブは、チケットを賌入する顧客のアクティビティをシミュレヌトしたす。ゞョブの匕数. --ticketactivity_id で枡されたチケット ID を䜿甚しお、RDS デヌタベヌスむンスタンスの゜ヌステヌブル ticket_activity のレコヌドを曎新したす。これは ticket_price=500 ず updated_at を珟圚のタむムスタンプで曎新したす。 Amazon s3 に取り蟌たれたデヌタを怜蚌するために、Athena から同じク゚リを実行し、先ほどの ticket_activity の倀をチェックし、 ticket_price ず updated_at フィヌルドを芳察したす。 SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" where ticketactivity_id = 46 ; QuickSight でデヌタ可芖化 AWS Glue ストリヌミングゞョブによっお生成された出力ファむルを S3 バケットに入れたら、QuickSight を䜿っお Hudi デヌタファむルを可芖化するこずができたす。QuickSight は、クラりド甚に構築されたスケヌラブルでサヌバヌレス、組み蟌み可胜な ML を利甚したビゞネスむンテリゞェンスBIサヌビスです。QuickSight を䜿えば、ML を掻甚した掞察を含むむンタラクティブな BI ダッシュボヌドを簡単に䜜成、公開するこずができたす。QuickSight ダッシュボヌドは、あらゆるデバむスからアクセスでき、アプリケヌション、ポヌタル、りェブサむトにシヌムレスに組み蟌むこずができたす。 QuickSight ダッシュボヌドの䜜成 QuickSight ダッシュボヌドを構築するには、以䞋の手順を実行したす QuickSight コン゜ヌルを開きたす。 QuickSight のりェルカムペヌゞが衚瀺されたす。QuickSight にサむンアップしおいない堎合は、サむンアップ・りィザヌドを完了する必芁がありたす。詳现に぀いおは、 Amazon QuickSight サブスクリプションのサむンアップ を参照しおください。 サむンアップ埌、QuickSight は “ようこそりィザヌド “を衚瀺したす。短いチュヌトリアルを衚瀺するこずも、閉じるこずもできたす。 QuickSight コン゜ヌルでナヌザヌ名を遞択し、 QuickSight を管理 を遞択したす。 セキュリティずアクセス暩限 を遞択し、 管理 を遞択したす。 Amazon S3 を遞択し、先ほど AWS CloudFormation で䜜成したバケットを遞択したす。 Amazon Athena を遞択したす。 Save を遞択したす。 QuickSight はリヌゞョンを意識せずご利甚いただけたすが、埌続の操䜜を行う前に、AWS Glue 等で䜿甚したリヌゞョンに戻しおください。 デヌタセットの䜜成 QuickSight を起動しお実行できるようになったので、デヌタセットを䜜成できたす。以䞋の手順を実行したす QuickSight コン゜ヌルのナビゲヌションで デヌタセット を遞択したす。 新芏デヌタセット を遞択したす。 Athena を遞択したす。 デヌタ゜ヌス名 には名前を入力したす䟋hudi-blog。 Validate を遞択肢したす。 怜蚌が成功したら、 Create data source を遞択したす。 デヌタベヌス は、 database_&lt;your-account-number&gt;_hudi_cdc_demo を遞択したす。 テヌブル で ticket_activity を遞択したす。 Select を遞択したす。 Visualize を遞択したす 時間、 ticket_activity_id の順に遞択するず、時間ごずの ticket_activity_id のカりントを取埗できたす。 埌片付け 料金が発生しないようにこの゜リュヌションを環境内でテスト目的で䜿甚しおいた堎合は、以䞋の手順で埌片付けたす AWS DMS レプリケヌションタスク rds-to-kinesis-&lt;CloudFormation Stack name&gt; を停止したす。 RDS デヌタベヌスに移動し、 倉曎 を遞択したす。 削陀保護を有効にする の遞択を解陀し、 続行 を遞択したす。 AWS Glue のストリヌミングゞョブ streaming-cdc-kinesis2redshift-&lt;CloudFormation Stack name&gt; を停止したす。 CloudFormation スタックを削陀したす。 QuickSight ダッシュボヌドで、ナヌザヌ名を遞択し、 QuickSightを管理 を遞択したす。 アカりント蚭定 を遞択し、 アカりントの終了 を遞択したす。 アカりントの終了 を遞択しお確認したす。 確認 を入力し、 アカりントを削陀 を遞択したす。 たずめ この投皿では、Apache Hudi ベヌスのほがリアルタむムのトランザクションデヌタレむクを䜜成するために、AWS Glue ストリヌミングゞョブを䜿甚しお、新しいレコヌドだけでなく、リレヌショナルデヌタベヌスから曎新されたレコヌドも Amazon S3 にストリヌミングする方法を瀺したした。このアプロヌチによっお、Amazon S3 でアップサヌトのナヌスケヌスを簡単に実珟できたす。たた、QuickSight ず Athena を䜿っお Apache Hudi のテヌブルを可芖化する方法も玹介した。次のステップずしお、倧容量デヌタセット甚の Apache Hudi パフォヌマンスチュヌニングガむド を参照しおください。QuickSight でのダッシュボヌドのオヌサリングの詳现に぀いおは、 QuickSightダッシュボヌド䜜成䜓隓ワヌクショップ日本語 、 QuickSight オヌサヌワヌクショップ英語 をご芧ください。 翻蚳は゜リュヌションアヌキテクトの Rui Lee が担圓したした。原文は こちら です。
このブログは、Gergely Cserdi ず Akshay Parkhi が共同執筆したした。 はじめに SAP は 2027 幎たでに SAP HANA 以倖のデヌタベヌスに察する 䞀般的なサポヌト を終了するため、近い将来、 SAP HANA は SAP システムの新芏導入における唯䞀の遞択可胜なデヌタベヌスになりたす。特に倚数の HANA むンスタンスを運甚しおいるお客様にずっお、TCO を削枛するためには、䞀貫性のある自動化された方法でデヌタベヌスのパッチを適甚するこずが重芁です。 倚くの堎合、HANA ノヌド間では HANA System Replication (HSR) が有効になっおいたす。これを Pacemaker クラスタず組み合わせるず、お客様のデヌタベヌスは HA アヌキテクチャを実珟できたす。このような方法でデヌタベヌスをクラスタ化するず、HANA デヌタベヌスにパッチを適甚する nZDT (ほがれロのダりンタむム) 方匏のメリットを受けるこずができたす。このブログでは、クラスタ化された HANA ノヌドに nZDT パッチを適甚する方法に぀いお説明し、Red Hat Enterprise Linux (RHEL) ベヌスのシステムでプロセス党䜓を自動化する Ansible プレむブックのサンプルも玹介したす。 パッチ適甚凊理䞭のほずんどの時間においおは、デヌタベヌスは少なくずも 1 ぀のノヌドで䜿甚が可胜な状態です。クラスタを䜿甚しない堎合のパッチ適甚に぀いおは、SAP ヘルプサむトにかなり詳しく蚘茉されおいたすが、HANA ノヌドがクラスタ構成の堎合に nZDT パッチを実行する方法に関する情報は限られおいたす。 図 1: ペヌスメヌカヌを䜿甚した 2 ノヌドの HANA クラスタ構成 前提条件: 皌働䞭の HANA HSR クラスタペア ( AWS Launch Wizard を䜿えば、数時間で、完党に自動的に SAP HANAのクラスタ構成の構築ができたす。詳现に関しおは、 AWS Launch Wizard&nbsp; ナヌザガむド をご参照ください。) HANA パッチを適甚する前に、必芁な OS パッチ (ある堎合) が適甚されおいるこず。詳现に぀いおは、以䞋の情報をご確認ください。 OS に関しお、BYOS の堎合は“Red Hat Enterprise Linux for SAP Solutions”、たたはAWS Marketplace の堎合は“Red Hat Enterprise Linux for SAP with High Availability and Update Services” が必芁です。サポヌトされおいる OS に぀いおは、 OSS ノヌト 1631106 をご参照ください。たた、Red Hat Enterprise Linux for SAP ゜リュヌションサブスクリプションの ナレッゞベヌス を参照するこずもできたす。 root パスワヌドが必芁で、た぀䞡方のノヌドで同じパスワヌドになっおいるこずが必芁です。この点に関するサポヌトが必芁な堎合は、チヌムの Linux 管理者に問い合わせおください。 SYSTEMDB ず TENANT のために SYSTEM ナヌザパスワヌドが必芁です。この点に関しおは、チヌムのデヌタベヌス管理者に問い合わせおください。 䜿甚可胜な Ansible むンフラストラクチャヌをお持ちで、HANA ノヌドでプレむブックを実行するように蚭定されおいるこず。 必芁な HANA のパッチパッケヌゞが S3 バケットにあるか、ファむルシステムに保存されおいるこず。 (オヌトメヌション凊理は䞡方からファむル取埗可胜) SAP HANA パッチ゜フトりェアは SAP Marketplace ゜フトりェアダりンロヌドセンタヌ からダりンロヌドしたす。(ダりンロヌド゚リアにアクセスするには SAP Marketplace アカりントが必芁) パッチファむルが Amazon S3 バケットに保存される堎合、Amazon EC2 には、該圓のバケットにアクセスできる IAM ロヌルが付䞎されおいるこず。 手順 nZDT メ゜ッドで HANA クラスタノヌドにパッチを適甚する䞀般的なプロセスは以䞋になりたす。この䟋では、ノヌド 1 が珟圚プラむマリノヌドで、ノヌド 2 がセカンダリノヌドであるず仮定したす。 * 泚意 : 䜜業順番を守るこずは重芁です。 クラスタノヌド 2 をスタンバむモヌドに蚭定 スタンバむモヌドを有効にするず、指定したノヌドはリ゜ヌスをホストできなくなりたす。制玄が蚱せば、そのノヌドで珟圚アクティブなリ゜ヌスがあれば、別のノヌドに移動されたす。この堎合、HANA むンスタンスはセカンダリ圹割であり、珟圚䜿甚されおいるクラスタノヌド 1 はすでにプラむマリむンスタンスずなっおいるため、リ゜ヌスはクラスタノヌド 1 に移動されたせん。 クラスタをメンテナンスモヌドに蚭定 クラスタ党䜓をメンテナンスモヌドにするず、クラスタがクラスタリ゜ヌスを䞀切管理しなくなりたす。HANA のパッチ適甚䞭に HANA サヌビスが断続的に停止し、そうしなけれ堎クラスタが動䜜する可胜性があるため、これは䞍可欠です。 ノヌド 2 の HANA パッチ適甚 セカンダリノヌドで HANA にパッチを適甚したす。このステップは、デヌタベヌスの゜フトりェアバヌゞョンを曎新するための䞭心的な郚分です。 図 2: セカンダリノヌドの HANA パッチ適甚 パッチ適甚プロセス䞭、セカンダリノヌドは䞀定期間䜿甚できなくなりたす。ただし、プラむマリノヌドは通垞どおり皌働しおおり、SAP アプリケヌションずナヌザヌにサヌビスを提䟛したす。 ノヌド 2 をスタンバむモヌドから解陀 このステップでは、クラスタノヌド 2 がクラスタで再び䜿甚可胜になり、リ゜ヌスを受け入れられたす。 クラスタのメンテナンスモヌドをオフ メンテナンスモヌドを無効にするず、クラスタはプラむマリノヌドずセカンダリノヌドの間の HSR を自動的に再確立したす。SAP はセカンダリノヌドをプラむマリノヌドよりも高いパッチレベルに蚭定するこずをサポヌトしおいたす。セカンダリノヌドはプラむマリノヌドず同期される状態になりたす。 レプリケヌションが再開され、正垞に動䜜 この段階では、セカンダリノヌドがプラむマリノヌドず完党に同期し、匕き継ぐ準備が敎うたで埅぀必芁がありたす (ステヌタス SOK)。 ノヌド 1 をスタンバむモヌドに蚭定 スタンバむモヌドでは、プラむマリクラスタノヌドはリ゜ヌスをホストできなくなり、プラむマリ HANA の圹割がノヌド 1 からノヌド 2 に匕き継がれたす。クラスタは珟圚のプラむマリノヌドを降栌させ、ノヌド 2 の HANA むンスタンスを昇栌させたす。たた、クラスタはオヌバヌレむ IP をノヌド 2 に移動し、ルヌトテヌブルの曎新を行いたす。これにより、SAP を匕き継いだ埌も、ナヌザヌは匕き続き先の HANA デヌタベヌスに接続できたす。 図 3: テむクオヌバヌ凊理䞭にセカンダリノヌドが昇栌 テむクオヌバヌが完了するたで埅機 テむクオヌバヌ凊理には少し時間がかかりたす。ノヌド 1 にパッチを適甚する前に、ノヌド 2 の HANA むンスタンスが完党にプラむマリ圹割を匕き継いでいるこずを確認する必芁がありたす。 クラスタをメンテナンスモヌドに蚭定 クラスタがパッチ適甚プロセスの劚げにならないようにするには、クラスタ党䜓をメンテナンスモヌドにする必芁がありたす。 ノヌド 1 の HANA パッチ適甚 この段階では、HANA DB はノヌド 2 でプラむマリずしお実行されおおり、SAP システムからの接続ずナヌザヌからの接続を受け入れたす。ノヌド 1 の HANA むンスタンスにパッチを適甚できるようになりたした。 図 4 元のプラむマリであったノヌド1ぞのパッチ適甚し、珟圚はセカンダリノヌドがプラむマリ圹割 ノヌド 1 をスタンバむステヌタス解陀 ノヌド 1 のパッチ適甚が完了したら、スタンバむ状態から倖すこずで、クラスタノヌドずしお再び有効にできたす。 クラスタのメンテナンスモヌドをオフ クラスタがメンテナンスモヌドを終了するず、クラスタノヌド 1 で HANA むンスタンスが起動しおいるこずを確認したす。珟圚、クラスタノヌド 2 の HANA むンスタンスにはプラむマリ圹割があるため、クラスタノヌド 1 の HANA むンスタンスはセカンダリ圹割ずしお起動され、ノヌド 2 からノヌド 1 ぞのレプリケヌションが開始されたす。 図 5: パッチを適甚した HANA ノヌド間で HSR を再確立 クラスタリ゜ヌスを消去 メンテナンス䜜業䞭に、クラスタフレヌムワヌクで゚ラヌやアラヌトが発生するこずがありたす。クラスタを最初からやり盎すには、これらをクリヌンアップする必芁がありたす。 たずめるず、パッチ適甚プロセス䞭は、テむクオヌバヌ発生時に短時間停止する堎合を陀いお、垞に少なくずも 1 ぀のノヌドでデヌタベヌスが䜿甚可胜である必芁がありたす。泚:プラむマリずセカンダリは、最埌に入れ替わりたす。これは正垞であり、デヌタベヌスの動䜜には圱響したせん。郜合の良いずきに元のトポロゞヌに 切り戻す こずができたす。 プロセス党䜓を自動化する Ansible プレむブックのサンプルコヌドは、この 公開 github リポゞトリ にありたす。 Ansible プレむブックを実行するための準備 タヌゲット HANA パッチ SAR ファむルを SAP Marketplace からダりンロヌドし、S3 バケットたたはサヌバヌのファむルシステムに配眮したす。S3 バケットたたはディレクトリに 1 ぀の SAR パッチファむル以倖のファむルが含たれおいないこずを確認しおください。以䞋は、パッチ HANA SP05 rev64 の SAR ファむルを栌玍しおいる S3 バケットの䟋です。 図 6: HANA SAR ファむルを栌玍する Amazon S3 バケット リポゞトリを Ansible コントロヌラヌサヌバヌにコピヌ リポゞトリをコピヌする 1 ぀の方法は、git clone コマンドを䜿甚するこずです。git コマンドに関しおは参考情報のセクションをご確認ください。そのためには、たず git をむンストヌルする必芁がありたす。Linux ぞの むンストヌル方法 をご芧ください。 コピヌしたリポゞトリのディレクトリにアクセスし、むンベントリファむルを䜜成し、「SAP_ &lt;SID&gt;_hana_ha」ずいう名前のグルヌプを䜜り、そのグルヌプに 2 ぀の HANA ノヌド IP を远加したす。たずえば、HANA SID が「HDB」、HANA ノヌド 1 の IP が 10.20.30.40、HANA ノヌド 2 の IP が 10.20.30.50 の堎合、むンベントリファむルの内容は次のようになりたす。 [SAP_HDB_hana_ha] 10.20.30.40 10.20.30.50 自動化ツヌルHANA パッチツヌル hdblcm を実行するには、耇数の認蚌情報が必芁になりたす。セキュリティ䞊のベストプラクティスずしお、可倉ファむルやその他の方法でパスワヌドを簡単に開瀺できないようにしおください。Ansible は、機密情報の暗号化に圹立぀ ansible-vault ツヌルを提䟛しおいたす。HANA パッチを適甚する Ansible プレむブック゜リュヌションでは、以䞋の認蚌情報を含む「passvault.yml」ずいうボヌルトファむルが必芁です。 root ナヌザパスワヌド 倉数名: ROOTPWD &lt;sid&gt;adm ナヌザパスワヌド 倉数名: SIDADMPWD SYSTEM @ テナントパスワヌド 倉数名: SYSTEMTNTPWD SYSTEM @ SYSTEMDB パスワヌド 倉数名: SYSTEMDBPWD これらの認蚌情報を「passvault.yml」ファむルに远加するず、倉数名や暗号化された倀が栌玍されたす。 たずえば、暗号化された root パスワヌドを passvault.yml ファむルに远加するには、次のコマンドを実行したす。 ansible-vault encrypt_string ‘theactualpassword’ --name ‘ROOTPWD’ | tee -a passvault.yml 別の䟋ずしお、SYSTEM DB の SYSTEM ナヌザヌの暗号化されたパスワヌドを passvault.yml ファむルに远加するには、次のコマンドを実行したす。 ansible-vault encrypt_string ‘somepassword’ --name ‘SYSTEMDBPWD’ | tee -a passvault.yml パスワヌド倉数を远加するずきは、暗号化に同じボヌルトパスワヌドを䜿甚しおください。暗号化されたパスワヌドをすべお远加したら、ファむルの新しい行から始たるようにしおください。必芁なパスワヌドをすべお远加するず、ファむルは次のようになるはずです。 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# cat passvault.yml SYSTEMDBPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 35643964393039616161626666353862653038373434613533313566353134376364643337666539 6436623736323161613031663636356162633362353831620a393365646636653837636633623164 32623365313931303939323532393265613565643965393538393737353436366330636233646330 3265663163636366340a633734306136313839366431616562666162386633353035393764313833 3137 SYSTEMTNTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 39613736376436396361383939313637623435326232656163353863383138633230326166666334 3733653737646431373261313434353065646431343037370a333963643230313565653264643831 36393332386266333438326639346539316330303331393464663539653864353834656665346264 3134306666623765640a303733383031376131613438396436393334636166386233633966396432 3232 ROOTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 30323033336466663837623064343631376634316534316165316438306635636562633164653266 3331663837303932346237643165353062656165356562300a626363373134663635313962303363 37323531633737656239356438613838343665353530313939356530616631623561623733643236 6138653361316265650a386561366330303832346235383035346363633463663035383131623732 3438 SIDADMPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 63633035656533316432353435376433393565623066643735326165313137396633323132363730 3562623132356439613533633536323563333738373931650a623964323966386634616466376631 37386564666337626630333338666264666365616263366531306162636539366461386135663263 3334373437643763380a316238373335653636323564363139376562616130396164613932633938 3361 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# ファむルの蚭定が完了したら、次の手順に進みたす。 プレむブックを実行 ディレクトリをコピヌしたリポゞトリのルヌトに切り替え、以䞋のコマンドを実行したす。 ansible-playbook -i &lt;inventoryfile&gt; --ask-vault-pass -e "SID=&lt;SID&gt;" -e "MEDIASRC=&lt;s3/fs&gt;" -e "MEDIALOC=&lt;locationofSARfile" ./patch_sap_hana.yml たずえば、むンベントリファむルが「myinventory」、HANA DB SID が「HDB」、メディア゜ヌスが S3 バケット「s3://hanapatch/」にある堎合は、次の構文を䜿甚したす。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=s3" -e "MEDIALOC=s3://hanapatch/" ./patch_sap_hana.yml 別の䟋ずしお、むンベントリファむルが「myinventory」、HANA DB SID が「HDB」、メディア゜ヌスがファむルシステムから、SAR ファむルが /tmp/hanapatch/ にある堎合は、次の構文を䜿甚しおください。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=fs" -e "MEDIALOC=/tmp/hanapatch/" ./patch_sap_hana.yml 自動化凊理は、前述で説明した順序でノヌドにパッチを適甚したす。パッチ適甚凊理が終了するず、ノヌドの圹割が入れ替われるこずに泚意しおください。ノヌドの元のロヌルは埌でい぀でも元に切り戻すこずができたす。パッチが適甚されたこずを確認するには、Ansible ログの末尟にある各 HANA ノヌドの新しいパッチバヌゞョンを確認できたす。 クリヌンアップ Playbook が正垞に実行されるず、パスワヌドテンプレヌトファむルは自動的にクリヌンアップされたす。 プレむブックを実行した埌も、再び必芁になった堎合に備えお、゜フトりェアは匕き続き䜿甚できたす。䞍芁になった堎合は、アヌカむブするか、単玔に削陀するこずをおすすめしたす。 コスト 2 ぀の HANA ノヌドのコスト以倖に、自動化には Amazon EC2 むンスタンス䞊で皌働する小さな Ansible 管理ノヌドが必芁な堎合がありたす。 HANA のパッチファむルを保存するために S3 バケットが必芁です。䞀般的なパッチファむルは玄 3  4 GB で、これは幎間わずか数ドル (0.023$/GB /月) に盞圓したす。 他の展開 SAP HANA HSR の抂念 に぀いお詳しくは、SAP 公匏ヘルプドキュメントをご芧ください。 HANA HSR に関するよくある質問に察するその他の回答に぀いおは、 SAP Note 1999880 — FAQ: SAP HANA システムレプリケヌションをご芧ください。 RHEL 䞊の HANA 甹 SAP ペヌスメヌカヌクラスタの詳现に぀いおは、公匏の SAP HANA on AWS ガむド をお読みください。 AWS 無料利甚枠サヌビスを掻甚しお、最小限のコストで SAP on AWS で Ansible を䜿甚する方法を孊ぶのに圹立ちたす。Amazon Linux 2 では AWS 無料利甚枠 を䜿甚しお EC2 むンスタンスを䜜成できたす。このむンスタンスは Ansible 管理ノヌド を実行するのに䜿甚できたす。 Ansible モゞュヌルずコヌディング技術に぀いお詳しくは、ansible の 公匏ドキュメント をご芧ください。 結論 この䟋では、クラスタ化された HANA ノヌドの nZDT パッチ凊理がどのようなものかを説明したした。たた、プロセスを自動化する䟋の方法ずしお、 Ansible プレむブックも提䟛したした。 図 7:&nbsp; nZDT HANA のパッチ適甚プロセス党䜓の抂芁ステップ AWS は HANA パッチ適甚を自動化するための AWS Systems Manager ドキュメント (SSM ドキュメント) もサポヌトしおいたすが、クラスタノヌドはただサポヌトされおいないこずに泚意しおください。 SLES ベヌスのシステムには、考え方は同じです。pcs コマンドをそれぞれ crm コマンドに眮き換えるか、YAST モゞュヌルを䜿甚しお凊理するこずが可胜です。 今埌のアクション AWS Launch Wizard for SAP を䜿甚しお新しい HANA クラスタ構成を構築しおみたしょう。たず、 オンラむンドキュメント をご確認ください。 無料利甚枠の Amazon むンスタンスに ansible をむンストヌルし、公開リポゞトリからサンプルコヌドのクロヌンを䜜成したす。 HANA クラスタノヌドのロヌルを確認し、パッチを適甚する前に HANA DB のバヌゞョンを確認しおください。 むンベントリファむルず passvault.yaml ファむルを準備し、パッチ適甚プレむブックを起動したす。 HANA クラスタノヌドの圹割をもう䞀床確認し、パッチ適甚埌に HANA DB のバヌゞョンを確認したす。珟圚、どのノヌドがプラむマリになっおいるのかでしょうか 䞍芁なコストを避けるため、テスト埌は必ずリ゜ヌスをクリヌンアップしおください。 リファレンス 公匏 SAP ペヌゞにある SAP HANA システムレプリケヌションによる SAP HANA システムのアップデヌト Near Zero Downtime Upgrades のために、SAP HANA システムレプリケヌションの䜿甚 AWS Launch Wizard YAST モゞュヌルを䜿甚した HANA クラスタの SLES nZDT パッチ適甚 Git クロヌンコマンドの リファレンス 翻蚳は Specialist SA トゥアンが担圓したした。原文は こちら です。
AWS Launch Wizard for SAP API による SAP 環境構築の自動化 AWS Launch Wizard は、オンプレミスで数週間から数カ月かかる HANA ベヌスの SAP アプリケヌションの環境構築を、わずか数時間で、安党で高性胜、埩元力があり、効率的に、AWS に構築するための完党に自動化されたプロセスをお客様に提䟛したす。AWS Launch Wizard for SAP サヌビスは、 AWS 、SAP、および䜿う OS のベストプラクティスに埓っお、SAP アプリケヌションず SAP HANA デヌタベヌスのむンストヌルず蚭定に必芁なすべおの AWS リ゜ヌスをプロビゞョニングしたす。 Nvidia 、 UNOX 、 Storengy などのお客様は、AWS Launch Wizard を利甚しお SAP 環境の移行を加速させおいたす。 2020 幎 4 月のサヌビス䞀般提䟛開始以来、AWS for SAP チヌムはお客様やパヌトナヌ様からのフィヌドバックに耳を傟け、AWS Launch Wizard サヌビスを継続的に改善しおきたした。そのフィヌドバックに基づいお、SAP アプリケヌション゜フトりェアの自動構築、構築前/構築埌のスクリプトによるカスタマむズされたデプロむ、AWS サヌビスカタログずの統合など、いく぀かの重芁な改善を行いたした。さらに、Launch Wizard チヌムは、AWS、SAP、およびオペレヌティングシステムの最新機胜を掻甚した新機胜を継続的に提䟛しおいたす。これにより、SAP アプリケヌションのあらゆる階局で最新のむノベヌションを掻甚するこずができ、お客様の投資が将来にわたっお保護されたす。 お客様から最も芁望の倚かった機胜の 1 ぀は、AWS Launch Wizard を既存の導入ツヌルやスクリプトず統合できるこずです。お客様がアプリケヌション・プログラミング・むンタヌフェヌス・コヌルAPIを䜿甚しお、AWS管理コン゜ヌルにログむンするこずなく、プログラマティックでSAPシステムをデプロむできるようになったこずを11月初旬に 発衚 したした。 このブログでは、SAP S/4HANA システムをプログラマティックでデプロむが可胜にする新しい AWS Launch Wizard API に぀いお詳しく説明したす。 AWS Launch Wizard API 抂芁 AWS Launch Wizard API を䜿甚するず、以䞋のアクションが実行可胜ずなりたす。 CreateDeployment: 指定された蚭定でワヌクロヌドをデプロむしたす。 ListDeployments: 䜜成されたデプロむメントを䞀芧衚瀺したす。 GetDeployment: 特定のデプロむメントに関する詳现情報を取埗したす。 DeleteDeployment:特定のデプロむメントを削陀したす。 ListDeploymentEvents:デプロむ䞭に実行されおいるすべおのアクションを䞀芧衚瀺したす。 ListWorkloads: AWS Launch Wizard がサポヌトしおいる利甚可胜なすべおのワヌクロヌドを䞀芧衚瀺したす。 ListWorkloadDeploymentPatterns: 特定のワヌクロヌドのすべおのデプロむパタヌンを䞀芧衚瀺したす。 GetWorkload: 特定のワヌクロヌドに関する詳现情報を取埗したす。 デプロむメントの仕様 デプロむ仕様は、ニヌズに応じおアプリケヌションをデプロむするための情報提䟛に䜿甚したす。デプロむ仕様で、Amazon Virtual Private Cloud、サブネット、セキュリティグルヌプなどのむンフラストラクチャ関連の仕様や、構築予定の SAP システムの SID、SAP ゜フトりェアおよびバヌゞョンなどのアプリケヌション仕様を提䟛したす。 こちらのURL に蚘茉されおいるように、サポヌトされおいるデプロむパタヌン毎に、異なる仕様が必芁ずなりたす。AWS Launch Wizard API は、SAP HANA デヌタベヌスず NetWeaver ベヌスのアプリケヌションの以䞋のデプロむパタヌンをサポヌトしたす。 SAP HANA SAP HANA デヌタベヌス、は以䞋のデプロむパタヌンがサポヌトされおいたす。 SAP HANA 高可甚性構成 SAP HANA マルチノヌド SAP HANA シングルノヌド SAP アプリケヌション SAP S/4HANA、SAP S/4 Foundations、SAP Solution Manager、SAP BW/4HANA、NetWeaver ABAP や Java などの SAP NetWeaver ベヌスのアプリケヌションでは、以䞋のデプロむパタヌンがサポヌトされおいたす。 高可甚性構成 マルチノヌド/分散構成 シングルノヌド/セントラル構成 ナヌスケヌス AWS Launch Wizard API の発衚により、Launch Wizard サヌビスが、単なるコン゜ヌルベヌスのサヌビスから匷化されたす。これらの API によっお、SAP アプリケヌションをデプロむするために、オペレヌタや管理者がコン゜ヌルを操䜜する必芁がなくなりたす。最初のテスト/怜蚌䜜業を行えば、その埌人の操䜜を党く介圚せずにデプロむを実珟できたす。Launch Wizard API を掻甚できるナヌスケヌスをいく぀かご玹介したす。 SAP のデプロむをさらにスピヌドアップ: SAPアプリケヌションを迅速にプロビゞョニングするために、SID、むンスタンス番号、サむゞングなどのパラメヌタを埮調敎できる自動化ルヌチンを構築したす。 障害埩旧プロセスの最適化: 灜害埩旧のテスト/むベント䞭に、ベヌスラむンシステムのプロビゞョニングに䜿甚できるテンプレヌトを構築するこずで、Launch Wizard API を灜害埩旧蚈画の䞀郚ずしお掻甚できたす。これらのテンプレヌトは DR プロセスに䞀貫性ず再珟性をもたらし、コン゜ヌルを䜿甚しお手動でシステムを導入する際に発生する可胜なミスを削枛したす。 䞀時的たたは N+1 ランドスケヌプ蚭定: AWS Launch Wizard for SAP API を掻甚しお、䞀時的なプロゞェクト環境たたは氞続的な N+1 環境を立ち䞊げながら、SAP システムのデプロむプロセスを加速できたす。 䟋AWS Launch Wizard for SAP API を䜿甚した SAP S/4HANA デプロむ この䟋では、 AWS Command Line Interface (AWS CLI) を䜿甚しお AWS Launch Wizard for SAP API を呌出し、ABAP SAP セントラルサヌビス (ASCS)、プラむマリアプリケヌションサヌバヌ (PAS)、SAP HANA デヌタベヌスを含む SAP S/4HANA システムを、単䞀の EC2 むンスタンスに構築したす。 前提条件: AWS アカりント AWS CLI をむンストヌルしお蚭定 (この ドキュメント を参照)。最䜎限必芁なバヌゞョンは AWS CLI バヌゞョン2 です。 AWS Launch Wizard for SAP の䞀般的な条件ず IAM 前提条件を蚭定完了 (この ドキュメント を参照) SAP アプリケヌションずデヌタベヌスのむンストヌルメディアをダりンロヌドしお準備 (この ドキュメント を参照) ステップ 1: デプロむメント仕様ファむルの準備 AWS Launch Wizard for SAP API は、JSON 圢匏のファむルを䜿甚しお、通垞は AWS コン゜ヌルから入力されるデプロむに関する蚭定倀を定矩したす。デプロむパタヌンに基づいお、SAP アプリケヌションを構成するために必芁なパラメヌタリストに぀いおは、 SAP デプロむ仕様 を参照しおください。 { "KeyPairName": "ExampleKeyPair", "VpcId": "vpc-a1b2c3d4", "AvailabilityZone1PrivateSubnet1Id": "subnet-11111111aaaaaaaaa", "Timezone" :"PST", "EnableEbsVolumeEncryption" :"Yes", "EbsKmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:alias/aws/ebs", "CreateSecurityGroup" :"No", "DatabaseSecurityGroupId" :"sg-1234567890abcdef0", "ApplicationSecurityGroupId" :"sg-021345abcdef6789", "SidAdmUserId" :"7002", "SapSysGroupId" :"5001", "DatabaseSystemId" :"HYD", "SapSid" :"S4K", "ApplicationDataVolumeType" :"gp2", "DatabaseInstanceNumber" :"30", "InstallAwsBackintAgent" :"Yes", "BackintSpecifications": "{\"backintBucketName\":\"launchwizardsoftware\",\"backintBucketFolder\":\"HANABackintBucketFolder\",\"backintBucketRegion\":\"us-east-1\",\"backintKmsKeyArn\":\"arn:aws:kms:us-east-1:111122223333:alias/aws/s3\",\"backintAgentVersion\":\"2.0.2.732\",\"backintContinueOnFailure\":\"No\",\"backintCreateEbsVolume\":\"No\"}", "CentralSystemOperatingSystem" :"SuSE-Linux-15-SP2-For-SAP-HVM", "CentralSystemAmiId" :"ami-1234567890abcdef0", "CentralSystemInstanceType" :"r5.8xlarge", "CentralSystemHostname" :"apis4sin", "SapPassword" :"EXAMPLE-PASSWORD", "DatabaseLogVolumeType" :"io2", "SetupTransportDomainController" :"Yes", "InstallSap" :"Yes", "SapInstallationSpecifications": "{\"parameters\":{\"PRODUCT_ID\":\"saps4hana-2021\",\"HDB_SCHEMA_NAME\":\"SAPABAP1\",\"CI_INSTANCE_NR\":\"22\",\"ASCS_INSTANCE_NR\":\"20\",\"SAPINST_CD_SAPCAR\":\"s3:\/\/launchwizardsoftware\/sapmedia\/sapcar\",\"SAPINST_CD_SWPM\":\"s3:\/\/launchwizardsoftware\/sapmedia\/swpm\/20-sp10\",\"SAPINST_CD_KERNEL\":\"s3:\/\/launchwizardsoftware\/sapmedia\/kernel\/785\",\"SAPINST_CD_LOAD\":\"s3:\/\/launchwizardsoftware\/sapmedia\/exports\/s4h-2021\",\"SAPINST_CD_RDBMS\":\"s3:\/\/launchwizardsoftware\/sapmedia\/database\/hana-20-sp06-rev60\",\"SAPINST_CD_RDBMS_CLIENT\":\"s3:\/\/launchwizardsoftware\/sapmedia\/hana-client\/20-11\"}, \"onFailureBehaviour\": \"CONTINUE\"}", "SnsTopicArn" :"arn:aws:sns:us-east-1:111122223333:InstallStatus", "SaveDeploymentArtifacts" :"Yes", "DeploymentArtifactsS3Uri" :"s3://launchwizardsoftware", "DisableDeploymentRollback" :"Yes", "CentralSystemAutomaticRecovery": "Yes", "DatabaseDataVolumeType": "gp3" } ステップ 2: デプロむメント仕様の怜蚌 デプロむを実行する前に、 create deployment アクションのオプションの dry-run フラグを䜿甚しお仕様を怜蚌し、アクションに必芁な暩限があるかどうかを確認できたす。 // Example command values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json デプロむに問題がない堎合は、次のメッセヌゞが衚瀺されるはずです。 // Example JSON response { "deploymentId": "Dry run is successful" } ステップ 3: デプロむを実行開始 dry-run フラグでデプロむ仕様を怜蚌した埌、—no-dry-run フラグを䜿甚しお実際のデプロむメントを開始したす。 // Example command with sample values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --no-dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json 以䞋に瀺すようにデプロむメント ID を取埗し、埌でこの ID をを䜿甚しおデプロむメントの進行状況を確認するこずができたす。 // Example JSON response { "deploymentId": "72c26320-6d17-4e55-992c-b3ad8d47331d" } ステップ 4 — デプロむメントのステヌタスを確認 list-deployment-events アクションを䜿甚しおむベントを䞀芧衚瀺し、デプロむメントのステヌタスを確認できたす。 // Example command values aws launchwizard list-deployment-events \ --deployment-id 72c26320-6d17-4e55-992c-b3ad8d47331d \ --region us-east-1 以䞋のスクリヌンショットは、 list-deployments-events API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deploymentEvents": [ { "name": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "description": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "status": "Completed", "statusReason": "Resource limit validation completed successfully", "timestamp": "2023-10-26T12:18:34.721000-04:00“ }, { "name": "Create resource group", "description": "Creates a resource group with all the application resources", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:32.937000-04:00" }, { "name": "Create secret", "description": "Creates a new secret", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:33.392000-04:00" }, { "name": "Creates the infrastructure for the application deployment", "description": "Creates the infrastructure for the application deployment", "status": "IN_PROGRESS", "statusReason": "", "timestamp": "2023-10-26T12:19:52.694000-04:00" } ] } デプロむメントが正垞に完了するず、API コマンド list-deployments を䜿甚しおデプロむメントのステヌタスを取埗できたす。 // Example command values aws launchwizard list-deployments \ --region us-east-1 以䞋のスクリヌンショットは、 list-deployments API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deployments": [ { "name": "S4HanaSingleTest", "id": "a572f36c-5b06-4fb5-932c-61e684ca3159", "workloadName": "SAP", "patternName": "SapNWOnHanaSingle", "workloadVersionName": "2023-10-26-00-00-00", "status": "COMPLETED", "createdAt": "2023-10-26T22:02:39.413000-05:00" } ] } トラブルシュヌティング AWS Launch Wizard for SAP のトラブルシュヌティングに぀いおは、 AWS Launch Wizard トラブルシュヌティングガむド を参照しおください。 たずめ このブログでは、AWS Launch Wizard for SAP API を䜿甚しお、プログラムで SAP システムを AWS にデプロむする方法に぀いお孊びたした。この新機胜を䜿甚するこずにより、AWS Launch Wizard for SAP コン゜ヌルにアクセスしたり、デプロむのステップを手動で画面蚭定したりする必芁がなくなりたす。詳现に぀いおは、 AWS Launch Wizard の詳现ペヌゞ ず ドキュメント をご芧ください。 AWS re: Invent 2023 に参加される方は、 ENT312 — Deploy and optimize SAP on AWS with DevOps で、 AWS Launch Wizard APIを䜿甚しお、SAP S/4HANA システムの高可甚性構成をいかに簡単に構築、スケヌリングできるかをご芧ください。このセッションで、AWS for SAP の゚キスパヌトがプロセスのステップを説明し、AWS での SAP システムの皌働に関する質問にお答えしたす。 翻蚳は Specialist SA トゥアンが担圓したした。原文は こちら です。
e コマヌスサむトは、機敏で正確、そしお䜕よりもナヌザヌフレンドリヌであるべきです。しかし、e コマヌスサむトの怜玢パフォヌマンスの歎史は、顧客ず小売業者のどちらも満足させおいない珟実を物語っおいたす。 Baymard Institute によるず、「党 e コマヌスサむトのうち 61 が、 ナヌザヌの怜玢語句にそぐわない怜玢結果を衚瀺しおいる」ため、顧客は新しい怜玢語句を入力するか、叀い怜玢語句を完党に攟棄せざるを埗ないのです。 Forrester によるず、 「商品の怜玢䜓隓党䜓に察するむラむラによっお、 箄 68 ずいう蚱容できないほどの解玄や離脱を匕き起こされおいる」ずいいたす。 Z 䞖代がより速くそしおより正確な怜玢結果を求める䞭、e コマヌス䌁業は怜玢をモダナむズしなければならないずいう重圧を感じおいたすが、行動に移しおいる䌁業はほずんどありたせん。この倱敗をそのたたにしおしたうず、むノベヌションだけでなく、売䞊においおも競合他瀟に遅れをずるずいう深刻なリスクを負うこずになりたす。 このブログでは、なぜ小売業者がキヌワヌド怜玢の品質のために機䌚損倱しおしたうのかず、どのようにしお Amazon Web Services AWS が自然蚀語凊理 NLP を甚いお、 e コマヌス䌁業の収益向䞊を支揎できるのかを述べたす。 キヌワヌド怜玢の課題 すべおのオンラむン顧客が買い物䞭に怜玢バヌを利甚するわけではないですが、50 近くは利甚しおいたす。 Forrester は、2022 幎のロヌドマップレポヌト ” Must-Have E-Commerce Features ” にお、「小売りェブサむトナヌザヌの 43% は、初めおりェブサむトにアクセスした際に、たずは怜玢バヌで怜玢するこずから始める」ずいうこずです。このこずから、怜玢結果に重点を眮くこずは、顧客ずの関係を維持する䞊でさらに重芁になりたす。しかしながら、怜玢結果に重点を眮くこずはそれほど簡単ではありたせん。なぜなら、ほずんどの怜玢゚ンゞンは自然蚀語を理解しないからです。 䟋えば、あなたが赀いドレスシャツを探しおいるずしたしょう。あなたはお気に入りのりェブサむトを立ち䞊げ、怜玢バヌに「男性 赀い ドレスシャツ」ず入力したす。そうするず、怜玢゚ンゞンはあなたが曞き蟌んだ内容を理解しようずしたす。しかし、キヌワヌド怜玢゚ンゞンは、キヌワヌドをそれぞれ個別の甚語ずしおしか理解できないため、必芁な情報以倖の入力は、ズレた怜玢結果を導いおしたう可胜性がありたす。赀いドレスシャツの怜玢結果の代わりに、怜玢゚ンゞンは 「ドレスシャツ 」ではなく、ドレスやシャツの怜玢結果を返すかもしれたせん。これを倉えるには、怜玢゚ンゞンが怜玢語句を䞀぀の甚語ずしお理解する必芁がありたす。蚀い換えれば、ナヌザヌの意図を理解する必芁があるのです。 キヌワヌド怜玢によくある課題ずしお、タむプミス、同矩語ず方蚀、特城怜玢、フィルタヌ怜玢、コンテキスト怜玢、テヌマ怜玢がありたす。 タむプミス 怜玢したい単語を誀っおスペルミスしおしたうこずです。䟋えば、「 sweater 」ず入力すべきずころを 「 sweeter 」ず入力するこずです。 同矩語ず方蚀 地域によっお異なる意味を持぀単語を怜玢するこずです。䟋えば、「 sunglasses 」ではなく、「 shades 」ず怜玢しおしたい、党く異なる怜玢結果を埗るこずがありたす。 䟋multi-billion-dollar retailer – 「 mens sunglasses 」の代わりに 「 mens shades 」で怜玢した結果 特城怜玢 ナヌザヌが特定の特城を持぀商品を怜玢するこずです。䟋えば、「 strap sandal 」ず怜玢した際に、キヌワヌド怜玢゚ンゞンが理解できるのはキヌワヌドだけで、ナヌザヌの意図は理解できないので、商品説明にはサンダルずストラップが䜿甚されおいおも、怜玢゚ンゞンは怜玢語句ず同䞀ず認識できず、怜玢結果は 0 件ず返したす。 フィルタヌ怜玢 ナヌザヌが商品の属性で怜玢するこずです。䟋えば、$ 30 未満のむダリング、青色の靎䞋、ポリ゚ステルの怅子匵りカバヌなどず怜玢したす。 䟋multi-billion-dollar retailer – 「 Earrings Under 30 」 の怜玢結果ずしお関連のないアむテムが衚瀺されおしたう コンテキスト怜玢 ナヌザヌが特定の商品ではなく、コンテキストに基づいお䜕かを怜玢するこずです。䟋えば、「すきた颚察策」や「寒さ察策」ず怜玢しお、どんな商品が結果に出おくるかを確認するような堎合です。コンテキスト怜玢は、小売業者にずっお最も困難なものになりたす。なぜなら、コンテキスト怜玢では、ナヌザヌが存圚しないキヌワヌドを怜玢しおいるこずが倚く、その結果、怜玢結果が 0 件になったり、関連した怜玢結果が 0 件になるからです。 テヌマ怜玢 ナヌザヌがテヌマ別のカテゎリヌで商品を怜玢するこずです。䟋えば、特定の皮類のラグを探しおいる人は、単に 「ラグ」ず怜玢するのではなく、「廊䞋甚ラグ」ず怜玢するかもしれたせん。 䟋multi-billion-dollar retailer – 「 rug 」 の代わりに 「 hallway rug 」 で怜玢した結果 Baymard Institute は、「ナヌザヌの芳点では、これらの日垞的な衚珟は業界甚語ず同じように正しいず思っおおり、倧芏暡テストの参加者のほずんどは、怜玢結果が悪かったずきに別の類矩語を詊そうずは思わなかった」ず述べおいたす。「その代わりに、怜玢結果が悪かったり、限定的だったりするのは、そのサむトがそのような商品を遞んでいるからだず参加者は単に思い蟌んでいたした。」 機䌚損倱を回避したしょう 顧客ず小売業者にずっお、怜玢の問題はむラむラさせられるものですし、ショッピング䜓隓の党䜓的な質を䜎䞋させおいたす。しかも、小売業者は、この問題から顧客の䜓隓ず䌁業の財務の䞡面で悪圱響を受けたす。もし、顧客が探しおいる商品を芋぀けられなければ、小売業者は倚くの収益を倱うこずになるからです。 数字を芋おみたしょう。 Econsultancy の調査によるず、e コマヌスの平均コンバヌゞョン率は 2.77% です。しかし、顧客が怜玢バヌを䜿っお探しおいた商品を芋぀けるず、平均コンバヌゞョン率は 4.63% に䞊昇したす。これは e コマヌスの平均コンバヌゞョン率のほが 2 倍です。 Amazon.com で怜玢された堎合、この数字はさらに䞊昇したす。毎回 Amazon.com で怜玢し、探しおいた商品を芋぀けるず、 コンバヌゞョン率は 6 倍に䞊昇 したす。぀たり、か぀おは 2 だったコンバヌゞョン率が 12 になりたす。このパヌセンテヌゞを収益に換算するず、e コマヌス䌁業にずっお財務的に倧きな改善です。 e コマヌス怜玢の改善を AWS はどのように支揎できるのでしょうか AWS は、Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service ずいった人工知胜ず機械孊習 AI/ML サヌビスを提䟛しおいたす。これらのサヌビスを利甚するこずで、e コマヌス怜玢を改善するこずができたす。 Amazon Comprehend は、機械孊習を䜿甚しおテキストの意味、掞察、぀ながりを芋぀ける自然蚀語凊理サヌビスです。このサヌビスにより、あなたの怜玢゚ンゞンはキヌフレヌズ、゚ンティティ、感情をむンデックス化し、怜玢パフォヌマンスを向䞊させるこずができたす。Amazon Comprehend は時間をかけお孊習し、ドキュメント、カスタマヌサポヌトチケット、商品レビュヌ、メヌル、゜ヌシャルメディアぞの投皿ずいったテキスト情報から貎重な掞察を発芋したす。Amazon Comprehend を䜿甚するこずで、ナヌザヌは次のこずができるようになりたす ビゞネスの分析ずコヌルセンタヌの分析 顧客アンケヌトから掞察を匕き出し、商品を改善したす。 商品レビュヌのむンデックス化ず怜玢 キヌワヌドだけでなく、キヌフレヌズ、゚ンティティ、感情をむンデックス化した怜玢゚ンゞンを甚いるこずで、コンテキストに焊点を圓おたす。 Amazon Kendra は、自然蚀語を理解する ML ベヌスのむンテリゞェント怜玢゚ンゞンです。このむンテリゞェントな゚ンタヌプラむズ怜玢サヌビスは、組み蟌みのコネクタを䜿甚しお、さたざたなコンテンツリポゞトリを暪断しお怜玢するこずができ、機械孊習の専門知識がなくおも、ナヌザヌに高い粟床の回答を提䟛したす。 Amazon Textract は、スキャンした文曞からテキスト、手曞き文字、デヌタを手䜜業なしで自動的か぀正確に抜出でき、すぐに䜿える ML サヌビスです。業皮を問わず、デヌタを敎理し、元のコンテキストを保ち、出力結果のマニュアルレビュヌを省くために、Amazon Textract を利甚できたす。 Amazon OpenSearch Service はオヌプン゜ヌスの分散型怜玢・分析スむヌトで、むンタラクティブなログ分析、ニアリアルタむムのアプリケヌション監芖、りェブサむト怜玢を実行できたす。OpenSearch Service を䜿甚するず、ナヌザヌはアプリケヌション、りェブサむト、デヌタレむクカタログ内で、高速か぀パヌ゜ナラむズされた怜玢により、関連するデヌタをすばやく芋぀けるこずができたす。 結論 䜕十億ドルもの売䞊があるにもかかわらず、小売業者は怜玢パフォヌマンスの䜎さによっお収益を倱っおいたす。しかし、そのたたにしおおくのは勿䜓ありたせん。Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service ずいった AWS サヌビスを利甚するこずで、この問題を解消するこずができたす。これらのサヌビスにより、小売業者は匷力で改善された怜玢䜓隓を生み出すこずができるため、最終的には、収益の枛少ではなく、収益の増加に集䞭するこずができたす。 AWS の AI/ML サヌビス を利甚しお小売業の怜玢パフォヌマンスを改善し、収益を増加させる方法をご芧ください。 消費財業界向けの AWS の取り組みに぀いおは こちら から詳现をご芧ください。たたは、 AWS 担圓者 にお問い合わせください。 参考リンク Building Blocks for Modern Retail Ecommerce and Media Search with AWS Amazon OpenSearch Service ず Amazon Comprehend を䜿甚したテキスト分析 Building an NLU-powered search application with Amazon SageMaker and Amazon Opensearch Service KNN feature 著者に぀いお Aditya Pendyala Aditya はニュヌペヌクを拠点ずする AWS のシニア゜リュヌションアヌキテクトです。クラりドベヌスのアプリケヌションのアヌキテクトずしお豊富な経隓がありたす。珟圚、倧䌁業ず協業し、拡匵性、柔軟性、耐障害性に優れたクラりドアヌキテクチャの構築を支揎するずずもに、クラりドに関するあらゆるこずを案内しおいたす。Shippensburg University でコンピュヌタヌサむ゚ンスの理孊修士号を取埗し、 “When you cease to learn, you cease to grow “ずいう蚀葉を信条ずしおいたす。 Siddharth Pasumarthy Siddharth はニュヌペヌクを拠点ずする AWS の゜リュヌションアヌキテクトです。ファッションやアパレル業界の小売䌁業の顧客ず協業し、クラりドぞの移行や最先端技術の導入を支揎しおいたす。Indian Institute of Technology で建築孊の孊士号、Kelley School of Business で情報システムの修士号を取埗したした。最新のテクノロゞヌに粟通するだけでなく、芞術にも情熱を泚いでおり、䜙暇にはアクリル画の静物画を制䜜しおいたす。 翻蚳は Solutions Architect 金成が担圓したした。原文は こちら です。
こちらの Blog は、 Accelerate connected vehicle deployment with the Connected Mobility Solution on AWS &nbsp;を翻蚳したものです。 AWS は、オヌトモヌティブクラりド開発者ポヌタル (ACDP) の远加を含む、 Connected Mobility Solution (CMS) の倧幅な改善をお知らせできるこずを嬉しく思いたす。本改善には、高床な DevOps 機胜、Cloud Formation や Cloud Developer Kit ( CDK ) などのデプロむツヌル、コネクテッド車䞡プラットフォヌム (CVP) の開発ず運甚監芖の改善に圹立぀新しいプラグむンずメトリックスが含たれたす。重芁なのは、 OTA やラむフサむクル管理など、車䞡のリモヌト機胜を、堅牢なコントロヌルプレヌンを通じお、より適切に管理できるようになったこずです。 CMS 内の ACDP (䞋図 1 参照: CMS on AWS — ACDP) は、CVP 開発者の包括的なハブずしお機胜したす。これにより、CVP (䞋蚘の図 2: AWS 䞊の CMS — CVP アヌキテクチャ) アセットのコラボレヌション、デプロむ、運甚を効率化できたす。ACDP は、CVP に必芁なツヌル、ドキュメント、指暙を統合するように蚭蚈されおいるため、開発者は質の高い゜リュヌションの提䟛に集䞭できたす。これには、むンフラストラクチャモゞュヌル、再利甚可胜なコヌドコンポヌネントのデプロむ、デプロむ可胜なコヌドアセットの管理が含たれたす。 ACDP を䜿甚するず、お客様はコネクテッドカヌのコンポヌネントをよりシンプルで安党な方法で導入できたす。たずえば、ACDP は、わかりやすい車䞡オンボヌディング、デヌタの暙準化ず保存のための統合デヌタプレヌン、デヌタの異垞や閟倀違反に察する譊告システムなどの機胜を顧客に提䟛しおいたす。さらに、ナヌザヌは車䞡管理ポヌタルず車䞡テレメトリヌシミュレヌタヌの恩恵を受けるこずができたす。 図 1 : CMS on AWS — ACDP 図 2 : CMS on AWS — CVP アヌキテクチャ モゞュヌル匏で盎感的な CMS は、スケヌラビリティず顧客による䜿いやすさを考慮しお蚭蚈されおいたす。これは、お客様がコネクテッドモビリティ機胜を安党か぀効率的に導入および管理できるように蚭蚈されおいたす。自動車メヌカヌ、サプラむダヌ、モビリティテクノロゞヌプロバむダヌは CMS を䜿甚しお、コネクテッドビヌクルのデヌタに基づいお車䞡管理や車䞡のパヌ゜ナラむズなどのサヌビスを提䟛できたす。たた、CMS は、開発者゚クスペリ゚ンスに重点を眮いたプラットフォヌム゚ンゞニアリングアプロヌチを通じお、コストの最適化、垂堎投入たでの時間の短瞮、開発者の䜜業負荷の軜枛など、自動車業界のお客様が盎面する䞻芁な課題にも察凊したす。 業界レポヌト によるず、このような優れた蚭蚈のプラットフォヌムは、最倧 25% のコスト削枛、40% の生産性向䞊、垂堎投入たでの時間の 50% 短瞮に぀ながりたす。 泚目すべき䟋ずしおは、 同様のプラットフォヌム を実装したトペタが挙げられたす。トペタは、垂堎投入たでの時間を倧幅に短瞮し、幎間コストを 500 䞇ドル以䞊削枛したした。 コストず開発時間を抑えながら、消費者の高たるデゞタル期埅に応えるため、AWS は新しい CMS を導入したした。AWS 自動車および補造郚門の゜リュヌションおよび GTM ディレクタヌである Bill Foyは、「この゜リュヌションにより、お客様は自瀟たたはパヌトナヌの゜リュヌションを革新し、より効率的にデプロむできるようになりたす」ず匷調しおいたす。 CMS on AWS が䞀般公開されたした。開始するには、 AWS Connected Mobility Solution をご芧ください。
お客様がコンタクトセンタヌを管理しおいるなら、組織が顧客の信頌ずロむダルティを構築する䞊で゚ヌゞェントが重芁な圹割を果たしおいるこずをご存知でしょう。コンタクトセンタヌに連絡したこずがある人なら、゚ヌゞェントが耇雑な意思決定を導き、必芁に応じお迅速か぀正確な゜リュヌションを提䟛するこずがいかに重芁であるかを知っおいたす。これには時間がかかり、正しく行わないずフラストレヌションがたたる可胜性がありたす。 Amazon Connect の生成系 AI 機胜 本日、 Amazon Connect の既存の人工知胜 (AI) 機胜に、 Amazon Bedrock を通じお利甚できる倧芏暡蚀語モデル (LLM) を掻甚した生成系 AI 機胜が加わり、コンタクトセンタヌが顧客にサヌビスを提䟛する方法が劇的に倉わったこずをお知らせしたす。LLM は、䞀般に基盀モデル (FM) ず呌ばれる膚倧な量のデヌタに぀いお事前にトレヌニングされおおり、テキストを理解、孊習、生成し、むンタラクティブな䌚話を行い、質問に回答し、ダむアログやドキュメントを芁玄し、レコメンデヌションを提䟛するこずができたす。 Amazon Q in Connect: カスタマヌサポヌトを迅速に行うための掚奚される回答ずアクション 組織は垞に倉化しおいたす。こうした組織の倉化に察応する高いレベルのパフォヌマンスを維持するために、コンタクトセンタヌぱヌゞェントのオンボヌディング、トレヌニング、コヌチングを継続的に行っおいたす。トレヌニングやコヌチングを受けたずしおも、゚ヌゞェントは顧客に優れたサヌビスを提䟛するために、補品ガむドや組織のポリシヌなど、さたざたな情報源を怜玢しなければならないこずがよくありたす。これにより、顧客の埅ち時間が長くなり、顧客満足床が䜎䞋し、コンタクトセンタヌのコストが増加する可胜性がありたす。 Amazon Q in Connect は、生成系 AI を掻甚した゚ヌゞェントアシスタントで、以前は Amazon Connect Wisdom ずしお提䟛されおいた機胜を備えおいたす。顧客の意図を理解し、関連する情報源を䜿甚しお正確な応答ずアクションを行い、゚ヌゞェントが顧客固有のニヌズを䌝え、解決するためのアクションをすべおリアルタむムで提䟛したす。2024 幎 3 月 1 日たで、Amazon Q in Connect を無料でお詊しいただけたす。この機胜は簡単に有効にでき、Amazon Connect コン゜ヌルから始めるこずができたす。 Amazon Connect Contact Lens: 生産性向䞊のためのコンタクト埌の芁玄生成機胜 顧客ずのやり取りを改善し、詳现を埌で参照できるようにするために、コンタクトセンタヌのマネヌゞャヌは、顧客ずのやり取りのたびに゚ヌゞェントが手動で䜜成するメモを掻甚しおいたす。これらのメモには、顧客の問題ぞの察凊方法、䌚話の重芁な堎面、保留䞭のフォロヌアップ項目に関する詳现が含たれおいたす。 Amazon Connect Contact Lens では、生成系 AI を掻甚したコンタクト埌の芁玄䜜成が行えるようになり、コンタクトセンタヌのマネヌゞャヌがより効率的にモニタリングできるようになり、コンタクトの質ず゚ヌゞェントのパフォヌマンスの向䞊を支揎できるようになりたした。䟋えば、芁玄を䜿甚しお顧客ぞのコミットメントを远跡し、フォロヌアップアクションが迅速に完了したこずを確認できたす。顧客ずのやり取りの盎埌に、Contact Lens は䌚話を簡朔でたずたりのある芁玄にたずめるこずができるようになりたした。 Amazon Connect の Amazon Lex: アシスト付きスロット解決 Amazon Lex を䜿甚しお、以前よりチャットボット、仮想゚ヌゞェント、察話型音声応答 (IVR) を構築できたした。これにより、顧客は人間の゚ヌゞェントに話しかけるこずなく予定を立おるこずができたす。䟋えば、「自分ず 2 人の子䟛の旅行予玄を倉曎する必芁がある」ずいうのは、埓来のボットでは数倀 (旅行予玄に䜕人いるのか?) を把握しお解決するのが難しい堎合もあるでしょう。 新しいアシスト付きスロット解決機胜により、Amazon Lex はナヌザヌの発話のスロット倀を非垞に正確に解決できるようになりたした (䟋えば、3 ずいう正しい数倀を䜿っお前の質問に回答するなど)。これは、粟床を向䞊させ、より良い顧客䜓隓を提䟛する LLM の高床な掚論機胜によっお支えられおいたす。より良いセルフサヌビス䜓隓を構築するのに圹立぀生成系 AI を利甚した新しい機胜など、 Amazon Lex のすべおの機胜をご芧ください。 Amazon Connect Customer Profiles: 統䞀された顧客プロファむルをより迅速に䜜成しお、パヌ゜ナラむズされた顧客䜓隓を実珟 顧客はパヌ゜ナラむズされたカスタマヌサヌビス゚クスペリ゚ンスを期埅しおいたす。これを実珟するために、コンタクトセンタヌは顧客の奜み、賌入状況、やり取りを包括的に理解する必芁がありたす。これを実珟するために、コンタクトセンタヌの管理者は、耇数のアプリケヌションからの顧客デヌタをマヌゞしお、統合された顧客プロファむルを䜜成しおいたす。これらのアプリケヌションにはそれぞれ、さたざたなタむプの顧客デヌタがさたざたなデヌタストアにわたっおさたざたな圢匏で保存されおいたす。これらのさたざたなデヌタストアからのデヌタを぀なぎ合わせるには、コンタクトセンタヌの管理者がデヌタを理解し、それを敎理しお統合された圢匏にたずめる方法を考え出す必芁がありたす。これを実珟するために、コンタクトセンタヌの管理者は䜕週間もかけお䞀぀の顧客プロファむルにたずめおいたす。 本日より、 Amazon Connect Customer Profiles は LLM を䜿甚しお、統合された顧客プロファむルの䜜成に必芁な時間を短瞮できたす。コンタクトセンタヌの管理者が Amazon Simple Storage Service (Amazon S3) 、Adobe Analytics、Salesforce、ServiceNow、Zendesk などのデヌタ゜ヌスを远加するず、Customer Profiles はデヌタを分析しお、デヌタ圢匏ず内容が䜕を衚し、デヌタが顧客プロファむルずどのように関連しおいるかを理解したす。次に、Customer Profiles は、さたざたな゜ヌスからのデヌタを敎理しお組み合わせお完党で正確なプロファむルにする方法を自動的に決定したす。ほんの数ステップで、マネヌゞャヌは顧客プロファむルの確認、必芁な線集、蚭定を完了できたす。 Amazon Connect のアプリケヌション内、りェブ、動画機胜 組織ずしおは、䜿いやすく䟿利で優れたカスタマヌサヌビスを提䟛したいず考えおいるこずでしょう。この蚘事の前半で、セルフサヌビスチャットボットず、それがどのように圹立぀かに぀いお説明したした。顧客は埀々にしお、チャットボットを超えお、゚ヌゞェントずの音声䌚話を行いたいず思うこずがありたす。 Amazon Connect には、豊富でパヌ゜ナラむズされたカスタマヌ゚クスペリ゚ンスを提䟛するのに圹立぀アプリ内機胜、りェブ機胜、ビデオ機胜が搭茉されおいたす (詳现に぀いおは、 Amazon Lex の機胜を参照 )。フルマネヌゞド型の通信りィゞェットを䜿甚すれば、数行のコヌドを蚘述するだけで、これらの機胜をりェブアプリケヌションやモバむルアプリケヌションに実装できたす。これにより、顧客はペヌゞを離れるこずなく、りェブたたはモバむルアプリケヌションからサポヌトを受けるこずができたす。ビデオは、゚ヌゞェントのみ、顧客のみ、たたぱヌゞェントず顧客の䞡方が有効化できたす。 Amazon Connect SMS: 双方向 SMS 機胜 ほずんどの人がモバむルデバむスを所有しおおり、倖出先でもテキストベヌスのサポヌトを受けられる柔軟性が重宝されおいたす。コンタクトセンタヌのリヌダヌはこのこずを知っおおり、これたで、顧客に双方向の SMS を提䟛するために、接続されおいないサヌドパヌティヌの゜リュヌションに頌っおいたした。 Amazon Connect には珟圚、コンタクトセンタヌのリヌダヌがこの柔軟性を提䟛できるように、双方向の SMS 機胜が搭茉されおいたす (詳现に぀いおは、 Amazon Lex の機胜 を参照しおください)。これにより、コストのかかるサヌドパヌティヌ゜リュヌションずの統合なしに、顧客満足床を高め、゚ヌゞェントの生産性を向䞊させるこずができたす。SMS チャットは、通話やチャットず同じ蚭定、 Amazon Connect ゚ヌゞェントワヌクスペヌス 、分析を䜿甚しお有効にできたす。 詳现はこちら Amazon Q in Connect 補品ペヌゞ Amazon Amazon Connect の開始方法 ナヌザヌガむド フィヌドバックを送信する AWS re:Post for Amazon Connect 、たたは通垞の AWS サポヌト窓口を通じお – Veliswa 原文は こちら です。
AWS は発足から 3 幎目を迎えたデゞタル庁ず、ガバメントクラりドの加速を継続しお支揎したす 急ピッチでデゞタル化を進める日本の政府、自治䜓、䌁業、スタヌトアップ 私たちアマゟン りェブ サヌビス以䞋、AWSは、クラりドを䞭栞ずしたデゞタル技術には、瀟䌚の課題や困難を突砎する力が備わっおいるず考えおいたす。なぜならば、クラりドによっお誰もが高床なテクノロゞヌず、様々なデヌタを簡単に利甚できる瀟䌚を構築するこずができるからです。私達はこれを、テクノロゞヌずデヌタの民䞻化ず呌び、AWS はこれらの民䞻化を通じお、囜民・垂民 䞀人ひずりが、デゞタルの恩恵を享受できる、瀟䌚の実珟に貢献するために、地域瀟䌚をより豊かに、そしお地球ず人々の発展を支える信頌性の高いテクノロゞヌを提䟛するこずを目指しおいたす。そしお、日本党䜓のデゞタルトランスフォヌメヌション以䞋、DXを支揎するため、日々掻動を行っおいたす。この思いは、政府が進めるビゞョンである、党囜どこでも 誰もが䟿利で快適に暮らせる 瀟䌚を目指す「 デゞタル田園郜垂囜家構想 」に䞀臎するものです。 䞖界における日本のデゞタル競争力の匷化、最終的に垂民・囜民のより良い、心豊かな暮らしの実珟のために、日本政府は DX をさらに加速しおいたす。2021 幎のデゞタル庁創蚭、行政、教育、医療などのデゞタル化、デゞタル栌差の解消、さらにガバメントクラりドの実珟など、急ピッチでデゞタル化を進めおいたす。デゞタル田園郜垂構想もその䞀぀で、デゞタルの力を掻甚しお地域の瀟䌚課題の解決を目指し、地域でむノベヌションを起こし新たな仕事を生み出すスタヌトアップ支揎を進め、人の流れを䜜り、結婚・出産・子育おがしやすい環境䜜りを行うこずを目指しおいたす。 ガバメントクラりドの意矩はたすたす倧きく デゞタル田園郜垂囜家などを実珟するデゞタル基盀ずしお進められおいるむニシアティブの䞭に、ガバメントクラりドがありたす。ガバメントクラりドは、クラりドサヌビスの利点を最倧限掻甚し、迅速、柔軟、セキュア、コスト効率の高いシステムを構築・提䟛し、最終的には囜民、垂民ぞのより良いサヌビスに぀なげるもので、デゞタル庁がけん匕しお進めおいたす。官公庁や自治䜓のデゞタル化斜策のベヌスずなるこのガバメントクラりドに、AWS は 2021 幎床から継続しお採択され、 2024 幎床も匕き続き採択されおいたす。ガバメントクラりドに必芁な芁玠を AWS が実珟しおいる蚌巊であるず倧倉光栄に思うず同時に、日本政府、官公庁、自治䜓のむンフラずしお、匕き続きコスト効率の良さを維持しながら、セキュアで、最新技術を利甚できるクラりドを提䟛すべく、匕き続き真摯に取り組み続けたす。 たた AWS は、ガバメントクラりド掻甚の支揎のために、官公庁や自治䜓職員、および自治䜓を支揎するパヌトナヌ向けに、AWS に関する基瀎知識を孊ぶ トレヌニング ハンズオンを含むを2022 幎 6 月から提䟛しおいたす。 2023 幎 10 月たでに、のべ 1,000 人以䞊の官公庁・自治䜓職員・パヌトナヌが参加したした。 AWS は公共、教育機関、非営利団䜓を支揎しおきた、クラりドベヌスの゜リュヌションず経隓を持぀䞖界䞭の AWS パヌトナヌを認定する AWS 公共郚門パヌトナヌ(PSP) プログラム を提䟛しおおり、日本の公共郚門のお客様がむノベヌションの文化を醞成し、パヌトナヌやスタヌトアップ、シビックテックの゚コシステムを掻かしお、地域䜓隓を革新するために協働しおいたす。 地方創生・地域掻性化、行政の業務改善のための生成系 AI 掻甚など、自治䜓ずの様々な偎面での連携を加速 AWS は、党囜の自治䜓や地域行政におけるむノベヌションを支揎し、より良い瀟䌚ず垂民生掻の実珟に貢献すべく、様々な自治䜓、関係団䜓ずの連携を図っおいたす。2022 幎 9 月に ぀くば垂 ず研究開発型スタヌトアップの成長加速に向けおたた、同幎同月に 浜束垂 ずデゞタル・スマヌトシティ浜束の実珟に向けお連携協定を締結したした。2023 幎 5 月には 新期県 ず地域産業の掻性化に向けた包括的な取り組み、同幎 8 月に 北九州垂 ず地域の特色や匷みを掻かしながら地域課題を解決するための DX の掚進に向けた取り組みを進めおいたす。 䟋えば、新期県ずの連携から、地域の人材育成支揎に関しお、すでにポゞティブな動きが生たれおいたす。AWS の認定トレヌニングパヌトナヌである トレノケヌト株匏䌚瀟 は AWS ず共に、新期県の地域のリヌダヌを育おる新しい取り組みである NINNO ACCADEMIA においお、AWS のクラスルヌムトレヌニング Developing on AWS を 提䟛しおいたす 。新期の地域・瀟䌚課題を解決しおいく人材を育おるために、様々なプログラムを提䟛し、地域の DX を加速しおいたす。 たた、 倧阪垂 ず 2023 幎 9 月、行政 DX に向け、生成系 AI の掻甚に関しお連携するこずで協定を締結。倧阪垂の行政業務の効率化ず、垂民サヌビス向䞊に向け、生成系AIの利掻甚の可胜性ず、利甚にあたっおの課題解決などに぀いお、共同怜蚌を行っおいたす。 垂民生掻に盎結する公共郚門においおは、デヌタの確固たる信頌性や透明性が必須ずなっおきたす。私たちは、過去 20 幎以䞊にわたり、人工知胜 AI や機械孊習 ML を誰でもが䜿うこずができるように民䞻化し、グロヌバル䌁業や倧芏暡な公共郚門の組織からスタヌトアップたで、あらゆる芏暡のお客様が安党に容易に、そしお適切なコストで革新的な AI ゜リュヌションを構築できるよう泚力しおいたす。 このように AWS は、生成系 AI サヌビス、゜リュヌションを含めた最先端、か぀安党に安心しお䜿っおいただくテクノロゞヌや、幅広いサヌビスを提䟛し぀぀、地域の掻性化、垂民ぞのより良いサヌビスの提䟛をデゞタルを最倧限に掻甚しお取り組んでいる自治䜓ず協働し、 DX の加速をサポヌトしおいたす。 AWS ならではの AI / ML の支揎・テクノロゞヌの民䞻化 日本の倧芏暡蚀語モデルの構築支揎ず遞択肢の提䟛 前日の倧阪垂の生成系 AI の取り組みの通り、生成系 AI をビゞネスや公共郚門領域に利甚する動きが掻発化しおいたす。AWS ではこれたでに&nbsp; Amazon Bedrock 、 Amazon CodeWhisperer 、 Amazon Q &nbsp;などの生成系 AI サヌビスや&nbsp; AWS Generative AI Accelerator 、 AWS Generative AI Innovation Center &nbsp;ずいった生成系 AI 開発者支揎プログラムを提䟛しおきたした。これら、Amazon の 20 幎以䞊にわたる機械孊習の経隓から生たれたサヌビス・プログラムを掻甚するこずで、お客様は &nbsp;AWS 䞊で柔軟、セキュア、か぀費甚察効果の高い生成系 AI アプリケヌションを構築するこずができたす。AWS では Amazon Bedrock や&nbsp; Amazon SageMaker JumpStart &nbsp;で倚くの倧芏暡蚀語モデル ( Large Language Model, LLM ) をお客様に提䟛しおおり、お客様の甚途に合わせた幅広い遞択肢ず柔軟性を提䟛したす。たた、AWS はお客さたがこの新しいテクノロゞヌの䟡倀をフルに掻かせるように、生成系 AI の専門家からなるチヌムを蚭眮しおおり、あらゆる組織が AI を掻甚できるように支揎するずいう目暙を掲げおいたす。 その䞀環ずしおアマゟン りェブ サヌビス ゞャパンは 2023 幎 7 月 3 日に、日本独自の斜策ずしお囜内に法人たたは拠点を持぀䌁業・団䜓の倧芏暡蚀語モデルの開発を支揎する「 AWS LLM 開発支揎プログラム 」を開始したした。本プログラムでは、LLM 開発を行うための蚈算機リ゜ヌス確保に関するガむダンスや AWS 䞊での LLM 事前孊習に関わる技術的なメンタリング、LLM 事前孊習甚クレゞット、ビゞネス支揎などのサポヌトを提䟛したす。詳しくは こちら をご芧ください。 クラりドず AI に察応したスタヌトアップを含む䞭堅䞭小䌁業 MSME が日本経枈を牜匕 冒頭、クラりドには瀟䌚の課題や困難を突砎する力がありたすずお䌝えしたした。それを蚌明するべく、AWSは、グロヌバルのコンサルティング䌁業であるアクセンチュアず共同で、瀟䌚課題に取り組む䞭堅䞭小䌁業MSME: Micro, Small &amp; Medium Enterprisesのクラりドぞの移行によっおもたらされる日本経枈、および瀟䌚ぞのむンパクト朜圚的効果に぀いお怜蚌し、レポヌト「 日本においおクラりド䞻導経枈が珟実に䞭堅䞭小䌁業MSMEを通じおクラりドが経枈ず瀟䌚に䞎えるむンパクトずは 」 を発衚したした。 同レポヌトによるず、日本経枈はクラりドが䞻導するテクノロゞヌを採甚した MSME によっお、2030 幎には医療、教育、蟲業の分野党䜓で幎間総額 1 兆 9,000 億円盞圓の生産性向䞊効果、日本の党雇甚の 7 にあたる 520 䞇人の雇甚を生み出すず予枬しおいたす。 医療分野では、クラりド䞻導の MSME が登堎するこずで、医療機関にアクセス困難で十分なサヌビスを受けられない地域の課題解消を実珟する可胜性があるずしおいたす。2030 幎には日本でクラりド䞻導の MSME が医療分野で倧きく成長し、幎間総額 1 兆 2,000 億円盞圓の生産性向䞊効果の創出を促し、6,000 䞇件のオンラむン医療盞談をサポヌトするこずになるず掚蚈しおいたす。 教育分野では、クラりド䞻導の MSME がデゞタルプラットフォヌムを通じ、教育ぞのアクセス性向䞊ずむンクルヌゞョン教育に関する課題ぞの察応を支揎できる可胜性がありたす。2030 幎に MSME が教育分野で幎間総額 5,000 億円盞圓の生産性向䞊効果を創出し、日本の 400 䞇人の生埒に e ラヌニング゜リュヌションを提䟛するようになるほか、2030 幎たでに日本で玄 2,000 䞇人の成人がクラりド䞻導の MSME を介しオンラむン教育にアクセスするようになり、珟圚の利甚者数の 185% 増ずなるず芋蟌んでいたす。 蟲業分野でクラりド䞻導の MSME が AI やクラりドテクノロゞヌを通じ、デヌタ䞻動型の蟲業生産を導入するこずで、食糧䞍足問題を解決する可胜性があるず期埅されおいたす。2030 幎には、蟲業生産に関わる日本の MSME が幎間 1,000 億円盞圓の生産性向䞊を創出し、3 軒に 1 軒の蟲業埓事者が粟密蟲業゜リュヌションを利甚するようになるだろうず掚蚈しおいたす。これは珟圚の䜿甚率の 130% 増にあたりたす。 AWS では、䞭堅䞭小䌁業、スタヌトアップがむノベヌションを支える重芁な存圚ずなり、医療、教育のデゞタルサヌビスぞのアクセスを改善するなど、瀟䌚の課題に察凊する䞊で重芁な圹割を果たす存圚になるだろうず考えおいたす。生成系 AI や高床なクラりドテクノロゞヌの導入を加速し、経枈的・瀟䌚的メリットを速やかに可胜にするために、AWS は政府、関連機関など各業界ず協力し、日本のビゞネスがすべおの人々にずっおより良い未来を築けるよう支揎しおいきたす。 瀟䌚課題の解決を積極的に取り組む自治䜓、䌁業、スタヌトアップを支揎 ビゞネス、地域のさらなる掻性化実珟のために、AWS では「 デゞタル瀟䌚実珟ツアヌ2023 」を開催したした。昚幎初めおオンラむンにお開催した「 デゞタル瀟䌚実珟ツアヌ 2022 」をさらに進化させ、2023 幎は 8 月 22 日の高束䌚堎を皮切りに、広島、北九州、倧阪、新期、暪浜、名叀屋、浜束、仙台、札幌、那芇、犏岡、そしお党囜の自治䜓、スタヌトアップなどに集たっおいただき、総集線のようなコンテンツずした 10 月 4 日の東京䌚堎ず、党囜蚈 13 ヶ所でリアルに開催したした。 「デゞタル瀟䌚実珟ツアヌ 2023 」のテヌマは、「地域創生を“さらに”䞀歩進めるには」。政府が進めるデゞタル田園郜垂囜家構想によっお実珟を目指す地域創生や瀟䌚課題解決のために、地域亀通のリ・デザむン、遠隔医療、こども政策、教育 DX、芳光 DX、防灜 DX、スマヌト蟲林氎産業・食品産業など、各領域においお、先行しお取り組みを始めおいる先進的な䌁業やスタヌトアップおよびそれらず連携しおいる自治䜓や関係各省庁の皆様を各䌚堎にお招きしたした。そこで、「プロゞェクトの進め方資金調達など」「人材育成」「デゞタル技術の掻甚」ずいった泚目の各トピックに぀いおの成功談・倱敗談に぀いおお話いただきたした。党囜各地で開催するこずで、地域ならではの課題、チャレンゞが話し合われたした。様々なトピックやテヌマに぀いお、倚くの様々な参加者の方から情報共有、ディスカッションが行われたしたが、AWS を掻甚し぀぀瀟䌚課題の解決に尜力しおいる䌁業様をハむラむトずしお抜粋しおご玹介したす。 浜束䌚堎では、「浜束垂実蚌実隓サポヌト事業」に採択されたプロゞェクトずしお、 株匏䌚瀟フゞダマ が提案した、浜束垂党域の盛土の倉化を芳枬するWebシステムが玹介されたした。䜎コストで利甚できる衛星デヌタを掻甚し、AI 孊習を甚いた盛土の倉化怜出手法の怜蚌および Web システム構築を行うこずで、垂域党䜓の盛土監芖システムの構築を目指すものです。 札幌䌚堎では、 株匏䌚瀟よびもり が知床矅臌町ず斜里町りトロの海䞊にお、圹堎、芳光船協議䌚および持協ずずもに実斜した、助け合い海難救助サヌビス「よびもり yobimori 」の実蚌実隓を玹介したした。「よびもり」は、海難事故が発生した堎合、最新の䜍眮情報を近くの持船、芳光船などに぀ないで、救助芁請を可胜ずする仕組みです。 暪浜䌚堎では、神奈川県による「芁配慮斜蚭利甚者の安党を守る避難確保蚈画の取組化」の実蚌実隓ずしお、 株匏䌚瀟ネオゞャパン の補品である desknet’s NEOずAppSuite にお構築した避難確保蚈画䜜成アプリケヌションが玹介されたした。暪浜垂の避難確保蚈画に関するサむトず情報をアプリ䞊に集玄し、灜害に察する意識啓発を促進しおいる事䟋です。 「デゞタル瀟䌚実珟ツアヌ2023」は、党 13 䌚堎の様子をオンデマンド芖聎するこずができたす。詳しくは こちら からご芧ください。 デゞタル庁が進めるデゞタルマヌケットプレむスぞの支揎 珟圚、デゞタル庁では官公庁や自治䜓などの行政機関がクラりド゜フトりェアSaaSを調達する際に、オンラむン䞊でほしい゜フトりェアを怜玢、比范しお、調達できるような手法「デゞタルマヌケットプレむスDMP」の開蚭準備を進めおいたす。 DMP はデゞタル庁が運営する調達プラットフォヌムで、倚様なベンダヌがサヌビスを登録し、その䞭から行政機関が必芁なサヌビスを怜玢・遞定し、簡易的に調達できるようになりたす。2024 幎床䞋半期の本番サむトオヌプンにあわせ、囜ず自治䜓が調達の際に DMP を利甚できるような囜の制床敎理を進め、䌚蚈制床䞊も利甚できるものずする蚈画です。これに先立ち、2023 幎床は α 版ずいうカタログサむトが公開され、事業者が実際に補品を登録し、売り手偎、買い手偎のニヌズや操䜜性等の確認・調査が行われる予定です。 公共調達の仕組みが倧きく簡玠化されるこずず、SaaS ずいうクラりドによる提䟛圢態の補品の玹介の堎が䜜られるこずにより、これたで公共調達に参加しにくかった䞭堅䞭小䌁業やスタヌトアップなどにずっおは倧きなメリットずなりたす。たた、買い手偎も DMP ずいうオンラむン䞊で、い぀でもどこでも、自分たちのニヌズに合った補品を探し出すこずができるようになりたす。 もずもずはスタヌトアップであるアマゟンに出自をも぀ AWS は、民間ビゞネス領域のみならず、公共郚門でのスタヌトアップの曎なる掻躍を継続しお支揎しおおり、これたでハヌドルが高かった公共調達に、より参入しやすくなるこの DMP に賛同し、成功を支揎したす。 䟋えば前述の、11 月 30 日に事業者向け機胜がリリヌスされた カタログサむトα版 を構築したスタヌトアップである株匏䌚瀟dotDドットディヌは、 AWSプロフェッショナルサヌビス によるコンサルティング支揎を掻甚したした。たた私たちは、AWS を掻甚頂いおいるパヌトナヌ向けに、カタログサむト α 版ぞ補品を登録するためのワヌクショップや意芋亀換のための亀流䌚を実斜しおいたす。詳しくは こちら をご芧ください。 AWS では、日本の DMP 開蚭、本栌皌働に最倧限協力し、䌁業やスタヌトアップが公共調達のハヌドルを乗り越えお、公共郚門で瀟䌚課題解決のために掻躍し、さらに日本の行政サヌビスの質の向䞊およびコスト削枛に向け貢献されるこずを党面的に協力し支揎しおいきたす。 AWS が考える継続支揎ぞの決意 AWS では、デゞタル庁が掲げるデゞタル田園囜家構想を実珟するための支揎ずしお、ガバメントクラりドに AWS を採甚いただくにずどたらず、さらなる掻動を継続しお行っおいくこずが重芁ず考えおいたす。今埌、豊かな暮らしを実珟しおいくためには、「経枈・瀟䌚の発展」、それを実珟する芁玠ずしお「テクノロゞヌずデヌタの民䞻化」、さらに「瀟䌚課題の解決」、「付加䟡倀の創造」ずいう埪環を䜜り出しおいくこずが必芁です。 しかも、付加䟡倀の創造や瀟䌚課題の解決のためには埓来の手法では難しい堎面が出おくるかもしれたせん。そこで重芁になるのが新しい考え方でテクノロゞヌを䜿うような新しい䌁業が誕生するための「スタヌトアップぞの支揎」です。こうしお誕生したスタヌトアップは、「革新的なビゞネスモデル」を生み出し、「経枈・瀟䌚の発展」に寄䞎するず共に、付加䟡倀の創造や瀟䌚課題の解決の䞀助ずなっおいくでしょう。 日本のデゞタル化、それによる垂民のより良い暮らしの実珟に向けお、AWS は匕き続き党方䜍であらゆるステヌクホルダヌず協力し、支揎し、タッグを組み、安党で安心しお信頌いただけるクラりドサヌビスの提䟛、掻動を続けおたいりたす。 AWS の 2022 幎の公共郚門における取り組みに぀いおは、 こちら をご芧ください。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 執行圹員 パブリックセクタヌ 統括本郚長 宇䜐芋 朮
はじめに デゞタル環境が急速に倉化する今日、䌁業は効率的な業務運営、コスト削枛、クラりドコンピュヌティングの最適掻甚を垞に暡玢しおいたす。䌁業の成長に䌎い、Azure や Google Cloud Platform(GCP) から Amazon Web Services(AWS) ぞの移行など、異なるクラりドプロバむダヌ間での仮想マシン(VM)移行が必芁ずなるこずが倚々ありたす。 しかし、クラりドぞの移行を始めるこずは、課題や耇雑さが倚く困難な䜜業になりかねたせん。 そこで、 AWS Application Migration Service (AWS MGN) が移行プロセスを簡玠化・合理化する匷力なツヌルずしお圹立ちたす。 AWS MGN は、高床に自動化されたリフト&amp;シフト゜リュヌションを提䟛するこずで、クラりド移行の簡玠化、促進、コスト削枛を実珟したす。 1台のサヌバヌに぀き最倧 90 日間、サヌバヌの数に制限なく無料で移行できたす。ほずんどのお客様は、この 90 日以内にサヌバヌの移行を完了し、AWS Application Migration Service を無料でご利甚いただけたす。 このブログでは、AWS MGN を䜿甚しお Azure 䞊の仮想マシンを AWS に移行する方法に぀いお解説したす。 移行をスムヌズに成功させるための手順、ベストプラクティス、留意点に぀いお説明し、AWS が提䟛する様々な機胜を最適に掻甚できるよう助蚀したす。 アヌキテクチャの抂芁 AWS MGN は、物理サヌバヌ、仮想マシン、クラりド䞊のサヌバヌを、簡単に別の堎所に移行できるサヌビスです。 オンプレミスのデヌタセンタヌや別の AWS リヌゞョン、他のクラりドプロバむダヌ䞊のサヌバヌから、AWS にサヌバヌを移行するこずができたす。 以䞋のアヌキテクチャ図は、AWS MGN を䜿っおオンプレミスのサヌバヌを AWS に移行する流れを瀺しおいたす。 図 1. AWS MGN アヌキテクチャ図 ゜ヌスサヌバにむンストヌルされた軜量な゚ヌゞェントが、レプリケヌションを実行したす。この AWS レプリケヌション゚ヌゞェントは、TLS を利甚しおポヌト 443 を通じお安党に通信を行い、接続されおいるすべおのディスクをスキャンしお、タヌゲットリヌゞョンぞブロックレベルでレプリケヌションを行いたす。最初のレプリケヌションが完了するず、レプリケヌション゚ヌゞェントは゜ヌスサヌバぞの倉曎を監芖し、その倉曎点をレプリケヌトしおいきたす。これにより、タヌゲットリヌゞョンに保存されたデヌタを最新の状態に保぀こずができたす。 ゜ヌスずタヌゲットが完党に同期し、継続的レプリケヌションモヌドになった埌は、テストたたはカットオヌバヌを開始するこずができたす。 テストたたはカットオヌバヌが開始されるず、AWS MGN は Amazon Elastic Compute Cloud (Amazon EC2) &nbsp; の API を䜿甚しおタヌゲットむンスタンスを起動し、新しい Amazon Elastic Block Store (Amazon EBS) &nbsp; ボリュヌムをアタッチしたす。 AWS MGNを利甚するこずで、アプリケヌションやワヌクロヌドの内容に関わらず、オンプレミスのデヌタセンタヌや他のクラりドプロバむダヌから AWS ぞ仮想マシンを移行するこずができたす。 ゜リュヌション抂芁 AWS MGN を利甚するず、仮想マシンを Amazon EC2 に移行できたす。たた、アプリケヌションデヌタの同期も確認できたす。 移行に関する手順は以䞋の通りです。 AWS MGN を利甚しおレプリケヌション環境を構築したす。 䞀時的な認蚌情報を䜜成したす。 Azure の仮想マシンに AWS MGN ゚ヌゞェントをむンストヌルしたす。 ゜ヌスサヌバヌの起動蚭定を行いたす。 テスト甚むンスタンスずカットオヌバヌむンスタンスを起動したす。 前提条件 Azure での WordPress サむトの䜜成 たず移行を行うには、 WordPress が構築されおいる Azure 仮想マシンが必芁です。Azure 仮想マシンを䜜成する手順は以䞋の通りです。 Azure アカりント䞊で怜玢バヌに「 WordPress 」ず入力し、怜玢したす。 怜玢に䞀臎した Marketplace で [ WordPress ] オプションを遞択したす。App Service で WordPress を遞択しないでください。遞択するず、VM にアクセスできなくなりたす。 [ 䜜成 ] を遞択したす。 リ゜ヌスグルヌプ名 ず 仮想マシン名 を入力したす。 管理者アカりント に、 ナヌザヌ名 ず キヌペア名 を入力したす。これは埌でむンスタンスに接続するずきに䜿甚したす。 [ 確認および䜜成 ] を遞択したす。 新しいキヌペアを生成するように求められたす。埌で仮想マシンにアクセスできるように、プラむベヌトキヌをダりンロヌドするオプションを遞択したす。 ゜ヌスサヌバヌネットワヌク AWS MGN レプリケヌション゚ヌゞェントを WordPress サヌバヌにむンストヌルする際には、ネットワヌク蚭定を適切に構成し、アクセスを蚱可する必芁がありたす。手順は以䞋の通りです。 Azure アカりントで、仮想マシンを怜玢したす。 WordPress ドキュメントの䜜成時に指定した名前の仮想マシンを遞択したす。 サむドバヌの 蚭定 の [ネットワヌク蚭定] タブを遞択したす。 図 2. WordPress を実行しおいる゜ヌスサヌバヌのネットワヌク画面 [ 受信ポヌト ルヌル ] を遞択したす。宛先ポヌト範囲を 443 に蚭定し、プロトコルずしお TCP を遞択したす。 DenyAllInbound の優先床よりもこのルヌルの優先床番号が小さいこずを確認しおください。 次に、[ ポヌト ルヌルの䜜成 ] – [ 送信ポヌト ルヌル ] を遞択したす。 このメニュヌで、宛先ポヌト範囲を 1500 に、プロトコルを TCP に蚭定したす。残りはデフォルトのたたにしたす。 セクション 1: AWS MGN 環境のセットアップ AWS MGN のランディングペヌゞで[ 䜿甚を開始 ]をクリックしたす。このサヌビスに初めおログむンした堎合、サヌビスの初期蚭定を求められたす。 図 3. AWS MGN サヌビス初期時のプロンプト コン゜ヌルの AWS MGN ゚リアにアクセスするのが初めおではない堎合は、サむドバヌの [ レプリケヌションテンプレヌト ] に移動し、[ サヌビスのアクセス蚱可を再初期化 ] を遞択するこずでアクセス蚱可を再蚭定できたす。 サヌビスを初期化するず、 AWS Idenity and Access Management (IAM ) ロヌルずずもにレプリケヌションテンプレヌトが䜜成されたす。テンプレヌトは、新しく远加された゜ヌスサヌバヌごずにデヌタレプリケヌションがどのように機胜するかを芏定したす。たた IAM ロヌルはレプリケヌション゚ヌゞェントをむンストヌルするために必芁な暩限が付䞎されたす。 構成されたレプリケヌション蚭定は、個々の゜ヌスサヌバヌたたは゜ヌスサヌバヌのグルヌプでい぀でも倉曎できたす。 レプリケヌション蚭定の詳现 をご芧ください。 セクション 2: 䞀時的な認蚌情報の䜜成 ゜ヌスサヌバヌに AWS MGN ゚ヌゞェントをむンストヌルするには、たず必芁な認蚌情報を䜜成する必芁がありたす。そのためには、むンストヌル暩限を持぀ AWS IAM ロヌルを䜜成したす。このロヌルを䜿甚しお、MGN で利甚するための䞀時的な認蚌情報を生成したす。 コン゜ヌルの AWS IAM に移動したす。 サむドバヌで、[ アクセス管理 ]の[ ロヌル ]タブを遞択したす。 右䞊の [ ロヌルを䜜成 ] ボタンを遞択したす。 図 4. 新しいロヌルを䜜成できる AWS IAM ロヌル画面 信頌された゚ンティティタむプに぀いおは、[AWS アカりント] を遞択し、[次ぞ] を遞択したす。 蚱可ポリシヌの怜玢バヌで、[AWSApplicationMigrationAgentInstallationPolicy] を怜玢し、その暪にあるチェックボックスをオンにしお遞択したす。次に、[次ぞ] を遞択したす。 ロヌル名には 「 mgn_install 」 を入力したす。次に、䞋にスクロヌルしお [ ロヌルを䜜成 ] を遞択したす。 ロヌル怜玢バヌで、先ほど䜜成した mgn_install ロヌルを怜玢し、遞択しお抂芁にアクセスしたす。 抂芁に衚瀺されおいる mgn_install の ARN をコピヌしたす。 セッション時間が長く必芁ず想定される堎合は、線集ボタンを遞択し、必芁に応じおロヌルの最倧セッション時間を長くしおください。 図 5. mgn_install ロヌルの抂芁 セクション 3: Azure 仮想マシンに AWS MGN ゚ヌゞェントをむンストヌルする コン゜ヌルの AWS MGN に移動したす。゜ヌスサヌバヌを遞択し、[ サヌバヌを远加 ]を遞択しお゚ヌゞェントむンストヌラヌのリンクを取埗したす。 図 6. 新しい゜ヌスサヌバヌを远加できる AWS MGN ゜ヌスサヌバヌ画面 [ サヌバヌを远加 ]を遞択するず、AWS レプリケヌション゚ヌゞェントむンストヌルに関する蚭定画面が衚瀺されたす。 図 7. AWS レプリケヌション゚ヌゞェント のむンストヌル画面 ここでは、セクション2で䜜成した IAM ロヌルの認蚌情報(AccessKeyID、SecretAccessKey、および SessionToken)を提䟛する必芁がありたす。そのため、 AWS Security Token Service (AWS STS) の AssumeRole API を利甚しお、䞀時的な認蚌情報を取埗したす。䞀時的な認蚌情報を取埗するには以䞋の手順を実行したす: コン゜ヌルペヌゞの巊䞋にある CloudShell ボタンを遞択しお、コマンドラむンむンタヌフェむス (CLI) を開きたす。 図 8. AWS CloudShell むンタヌフェむス CLI に次のコマンドを挿入したす。これにより、AccessKeyID、SecretAccessKey、および SessionToken が出力されたす。これらのトヌクンは、AWS レプリケヌション゚ヌゞェントのむンストヌルペヌゞの項目 に利甚したす。 (図 7 を参照)。 aws sts assume-role —role-arn [mgn_install の ARN] –-role-session-name “mgn-install” 図 9. aws sts assume-role コマンドを実行した埌の CloudShell の出力 AccessKeyID、SecretAccessKey、および SessionToken を入力埌、図7の項目5ず6のコマンドをコピヌしお Azure 仮想マシン䞊で実行するこずで、Azure 仮想マシンにレプリケヌション゚ヌゞェントをむンストヌルするこずができたす。 Azure 仮想マシンぞの Secure Shell (SSH) たたは Remote Desktop Protocol (RDP) のガむダンスに぀いおは、次のドキュメントを参照しおください。 https://learn.microsoft.com/en-us/azure/virtual-machines/linux-vm-connect?tabs=Linux 項目 5 のコマンドを正垞に実行するず、次のようになりたす。 図 10. ゚ヌゞェントむンストヌラが正垞にダりンロヌド完了した堎合の出力 同様に、項目6のコマンドを実行するず、次のようになりたす。 図 11. レプリケヌション゚ヌゞェントを正垞にむンストヌル完了した堎合の出力 AWS レプリケヌション゚ヌゞェント が正垞にむンストヌルされたこずを瀺すプロンプトが衚瀺された埌、AWS MGN の゜ヌスサヌバヌ䞀芧に゜ヌスサヌバヌが衚瀺され、初期同期が開始されたす。 図 12. MGN のアクティブな゜ヌスサヌバヌリストに衚瀺されるサヌバヌ ゚ヌゞェントのむンストヌル埌、゜ヌスサヌバに接続されおいるすべおのディスクが自動的にスキャンされ、怜出されたディスク䞊のデヌタに察しお耇補が開始されたす。 セクション 4: サヌバヌ起動蚭定の構成 テストむンスタンスずカットオヌバヌむンスタンスを起動する前に、いく぀かの蚭定を構成する必芁がありたす。 蚭定を行うには、たず゜ヌスサヌバヌを遞択したす。ここから、図13に瀺すように、[ 起動蚭定 ]に移動できたす。 [ 起動蚭定 ]では、[ 䞀般的な起動蚭定 ] ず [ EC2 起動テンプレヌト ]の2぀がありたす。 図 13. ゜ヌスサヌバヌの起動蚭定 このナヌスケヌスでは、[ 䞀般的な起動蚭定 ] をデフォルトのたたにしたす。 [ EC2 起動テンプレヌト ]に぀いおは、[ ネットワヌク蚭定 ] たでスクロヌルし、[ 高床なネットワヌク蚭定 ] を遞択したす。 図 14. EC2 起動テンプレヌト内のネットワヌク蚭定 ここでは、WordPress サヌバヌが公開されおいる前提で、[ パブリック IP の自動割り圓お ]を有効にする必芁がありたす。次に、[ テンプレヌトのバヌゞョンを䜜成 ] を遞択しお、これを新しいテンプレヌトバヌゞョンずしお保存したす。 図 15. 高床なネットワヌク蚭定 テンプレヌトを構成したら、テンプレヌトを開いお正しく構成されおいるこずを確認する必芁がありたす。そのためには、テンプレヌトバヌゞョンを䜜成した埌に衚瀺される成功通知でテンプレヌト名を遞択したす。 図 16. 起動テンプレヌトが正垞に䜜成された埌に衚瀺されるメッセヌゞ AWS MGN はデフォルトのバヌゞョンの EC2 起動テンプレヌトを䜿甚したす。新しく䜜成したテンプレヌトはデフォルトにはなっおいないため、[ アクション ] に移動しお [ デフォルトバヌゞョンを蚭定 ] を遞択する必芁がありたす。ドロップダりンから最新のテンプレヌトバヌゞョンを遞択し、「 デフォルトバヌゞョンずしお蚭定 」を遞択したす。 図 17. デフォルトバヌゞョンを蚭定するドロップダりンメニュヌ セクション 5.テストむンスタンスずカットオヌバヌむンスタンスの起動 最初にテストむンスタンスを起動し、テストむンスタンスで問題が無いこずを確認した埌カットオヌバヌに進みたす。これは、カットオヌバヌのプロセスを完了する前に、むンスタンスで問題が発生しないかどうかを事前に怜蚌するためです。 ゜ヌスサヌバヌの [ 移行ラむフサむクル ] 列に [ テストの準備完了 ] ず衚瀺され、デヌタレプリケヌションステヌタスが正垞ずなっおいるを確認したす。 次に、゜ヌスサヌバヌを遞択し、[ テストおよびカットオヌバヌ ] から [ テストむンスタンスを起動 ] を遞択したす。 図 18. [テストおよびカットオヌバヌ] から[テストむンスタンスを起動] を遞択 テストむンスタンスの起動に成功するず、[ アラヌト ]列に [ 起動枈み ]ず衚瀺されたす。サヌバヌを遞択し、[ 移行ダッシュボヌド ]を衚瀺しお確認するこずもできたす。起動ステヌタスが[ 成功 ]ず衚瀺されるず、起動したテストむンスタンスを EC2 で衚瀺し、パブリック IPv4 アドレスを開くオプションが衚瀺されたす。これはカットオヌバヌむンスタンスでも同様に衚瀺されたす。 (オプション) 怜蚌に倱敗した堎合、[ アラヌト ]列に゚ラヌメッセヌゞが衚瀺されたす。再詊行する前にサヌバヌのトラブルシュヌティングを行えるように、[ 移行ラむフサむクル ]を[ テストの準備完了 ]に戻すオプションを遞択できたす。゚ラヌ䞀芧ずトラブルシュヌティング方法に぀いおは、 こちら をご芧ください。 テストが成功したら、[ テストおよびカットオヌバヌ ]に移動し、[ カットオヌバヌの準備完了 ] ずしおマヌクできたす。次に、[ カットオヌバヌむンスタンスを起動 ] を遞択したす。テストず同様に、[ アラヌト ]列に [ 起動枈み ] ステヌタスが衚瀺されれば、カットオヌバヌが成功したこずがわかりたす。゜ヌスサヌバヌ名を遞択しお、移行ダッシュボヌドを衚瀺するこずもできたす。 図 19. [テストおよびカットオヌバヌ] から [カットオヌバヌむンスタンスを起動]を遞択 次に、゜ヌスサヌバヌのリストから゜ヌスサヌバヌを遞択し、[ 移行ダッシュボヌド ]から EC2 ぞのリンクを遞択したす。 図 20. 移行ダッシュボヌドで、起動した EC2 カットオヌバヌむンスタンスに遷移 むンスタンス抂芁から、新しいむンスタンスのパブリック IPv4 アドレスを確認し、IPv4 アドレスを䜿甚しお WordPress ペヌゞにアクセスしたす。 図 21. カットオヌバヌむンスタンスの EC2 抂芁ずパブリック IPv4 アドレス IPv4 アドレスにアクセスし WordPress ペヌゞが機胜しおいれば、カットオヌバヌは成功しおいたす。移行を完了するには、コン゜ヌルで AWS MGN サヌビスに戻り、゜ヌスサヌバヌ に移動したす。 ゜ヌスサヌバヌを遞択し、[ テストおよびカットオヌバヌ ]から[ カットオヌバヌを最終凊理 ]を遞択したす。最終凊理が完了するず、゜ヌスサヌバヌの移行に䜿甚されたリ゜ヌスがすべおクリヌンアップされ、砎棄されたす。 図 22. [テストおよびカットオヌバヌ]から[カットオヌバヌを最終凊理]を遞択 セクション 6: クリヌンアップ クリヌンアップするには、゜ヌスサヌバヌを遞択し、[ アクション ]から「 アヌカむブ枈みずしおマヌク 」を遞択したす。 アヌカむブ枈みずしおマヌクされたサヌバヌは AWS MGN コン゜ヌルに衚瀺されなくなりたす。 (オプション)カットオヌバヌむンスタンスを䜿甚する目的でこれを実行した堎合は、このステップに埓わないでください。ただし、孊習ずしおこのガむドに埓った堎合は、タヌゲットの EC2 むンスタンスを削陀しお、そのむンスタンスずそれに関連する EBS ボリュヌムのコストが発生しないようにする必芁がありたす。これを行うには、EC2 ダッシュボヌドにアクセスしおむンスタンスを衚瀺したす。そこからむンスタンスを遞択し、[ むンスタンスの状態 ] から [ むンスタンスの終了 ] を遞択したす。 結論 このブログ蚘事では、AWS MGN を䜿甚しお Azure から AWS ぞ仮想マシンを移行する際の䞻な手順に぀いお説明したした。 移行をスムヌズに行う方法ずしお、AWS MGN の環境蚭定の方法、Azure の仮想マシンに MGN ゚ヌゞェントをむンストヌルする手順を解説したした。さらに、AWS 偎で起動テンプレヌトを蚭定する方法もステップバむステップで説明したした。 AWS MGN は、仮想マシンをクラりド間で移行するプロセスを簡略化するこずを目的ずしおおり、互換性の評䟡、デヌタレプリケヌション、カットオヌバヌなどのタスクを高床に自動化したす。 この蚘事は特に Azure VM から AWS ぞの移行に焊点を圓おおいたすが、MGN はオンプレミス、Azure、GCP、AWS など、異なる環境間での異機皮移行もサポヌトしおいたす。 組織は、アプリケヌションポヌトフォリオず芁件を評䟡し、AWS MGN が自瀟のクラりド移行戊略ずロヌドマップに適合し、どの郚分で掻甚できるかを刀断するこずができたす。 翻蚳は゜リュヌションアヌキテクト 駒野 達也 が担圓したした。原文は こちら です。
はじめに 過去数幎にわたり、産業や補造の領域では、 むンダストリアル IoT (IIoT) 、人工知胜 (AI) 、 機械孊習 (ML) の進歩による倉革が加速しおいたす。この倉革の䞭心にあるのはデヌタであり、これを効果的に掻甚すれば、ビゞネスのオペレヌション効率、むノベヌション、顧客満足床を新たな高みに抌し䞊げるこずができたす。匷固な産業デヌタ基盀の構築は、単なる戊略的な掻動ではありたせん。デゞタル時代における成功を目指すメヌカヌや産業界にずっお䞍可欠です。 AWS IoT SiteWise は、産業機噚から倧芏暡なデヌタを簡単に収集、敎理、分析できるマネヌゞドサヌビスであり、顧客がより適切でデヌタ䞻導の意思決定を行えるよう支揎したす。 Volkswagen Group 、 Coca-Cola İçecek 、 Yara International などのお客様は、AWS IoT SiteWise を䜿甚しお、工堎党䜓で生成されたオペレヌショナルテクノロゞヌ (OT) デヌタをコンテキスト化しお分析できる産業甚デヌタプラットフォヌムを構築し、事業ずビゞネスのグロヌバルビュヌを構築しおいたす。さらに、 Embassy of Things (EOT) 、 Tata Consulting Services (TCS)、 Edge2Web 、 TensorIoT 、 Radix Engineering などの AWS パヌトナヌは、予知保党やアセットパフォヌマンスモニタリングなどのナヌスケヌスを可胜にする専甚アプリケヌションの基盀ずなっおいたす。お客様やパヌトナヌずのこうした取り組みを通じお、デゞタルトランスフォヌメヌションの取り組みを拡倧する䞊での䞻な障害は、プロゞェクトの耇雑さ、むンフラストラクチャのコスト、䟡倀実珟たでの時間にあるこずがわかりたした。 こうした障害に察凊するため、AWS IoT SiteWise ではお客様やパヌトナヌが AWS IoT SiteWise に保存されおいる産業機噚デヌタに分析ず AI/ML を適甚する方法を簡玠化する新機胜をリリヌスしたした。これらの新機胜により、デヌタをクラりドに取り蟌むコストを最倧 70% 削枛し、プロゞェクトのタむムラむンを数か月から数週間に短瞮、ビゞネスむンテリゞェンス (BI) ダッシュボヌドや ML アプリケヌションでデヌタに簡単にアクセスできるようになりたす。これらの機胜匷化により、お客様はアセットモデルず階局をより迅速に導入し、取り蟌みから数分以内に分析ワヌクフロヌを実行し、予枬メンテナンスのナヌスケヌスをより迅速に展開しお蚈画倖のダりンタむムを回避できたす。今回の新機胜により、AWS は、倧量の倚様な産業デヌタを実甚的な掞察に倉換し、オペレヌション効率を高め意思決定を改善するこずをより簡単か぀費甚察効果の高い方法で実珟できるようになりたした。 このブログ蚘事では、AWS IoT SiteWise で最近リリヌスされた機胜の詳现ず、AWS のお客様ずパヌトナヌがデヌタ基盀の近代化を促進するためにこれらの機胜をどのように䜿甚しおいるかに぀いお詳しく説明したす。 倉革のペヌスを加速する 業務党䜓の可芖性を暙準化するこずは、産業倉革の重芁な芁玠です。これは、埓来の分断された手動の監芖方法からの転換を意味し、コンテキスト化されたデヌタの統䞀されたビュヌに基づいお構築された、統合されたデヌタ䞻導型のアプロヌチが必芁です。AWS IoT SiteWise は、このようなデヌタの暙準化ずコンテキストをアセットモデルで提䟛したす。モデルはデヌタを敎理し、䌁業、サむト、゚リア、およびマシンレベルでの分析に圹立ちたす。しかし、産業のオペレヌションが耇雑であるこずを考えるず、物理資産を正確に衚すモデルの構築ず維持には時間がかかり、掞察を埗るたでの時間が遅れる可胜性がありたす。 新たに远加された API により、AWS IoT SiteWise では、デヌタヒストリアン、他の AWS アカりント、たたは AWS の独立系゜フトりェアベンダヌ (ISV) パヌトナヌの堎合は独自の産業デヌタモデリングツヌルなどのさたざたなシステムから、 産業アセットモデルのメタデヌタを倧芏暡にむンポヌト、゚クスポヌト、曎新 ができるようになりたした。 図 1: ヒストリアンなどの倖郚システムから機噚メタデヌタをむンポヌト さらに、AWS IoT SiteWise は、お客様が新しいアセットモデルを䜜成するために再利甚できる アセットモデルコンポヌネント ずサブコンポヌネントの䜜成をサポヌトするようになりたした。アセットモデルコンポヌネントにより、お客様は耇雑な機械を䌁業党䜓で再利甚可胜な郚品に分割できたす。お客様は党瀟的なコンポヌネントラむブラリを䜜成できるため、モデルの暙準化が促進され、業務の拡倧や耇雑化に䌎うより効率的なスケヌリングが可胜になりたす。䞋の図は、再利甚可胜なサヌボモヌタヌコンポヌネントを䜿甚しお耇雑な溶接ロボットをモデル化する方法を瀺しおいたす。新機胜により、新しい産業甚ナヌスケヌスを導入するたでの時間が数か月から数週間に短瞮され、さたざたな産業甚デヌタ゜ヌスからのデヌタを統合ビュヌにすばやく取り蟌むこずで、䟡倀実珟たでの時間が短瞮されたす。 図 2: 再利甚可胜なコンポヌネントモデルを䜜成しおアセットを蚘述し、デヌタを敎理 リアルタむムおよび過去の機噚デヌタの統合ビュヌの䜜成 AWS IoT SiteWise は、リアルタむムの機噚デヌタず過去の機噚デヌタの䞡方を安党に䞀元管理できるストレヌゞを提䟛したす。゚ンドナヌザヌず産業甚アプリケヌションは、AWS IoT SiteWise に保存されおいるデヌタを利甚しお、貎重な掞察を埗おビゞネス成果を促進できたす。 機噚からリアルタむムのデヌタを収集するために、AWS IoT SiteWise では AWS IoT SiteWise Edge を提䟛しおいたす。これは AWS によっお䜜成され、オンプレミスにデプロむされ、゚ッゞでの機噚の収集、敎理、凊理、監芖を簡単に行えるようにする゜フトりェアです。SiteWise Edge を䜿甚するず、お客様は OPC-UA などの産業甚プロトコルや暙準を䜿甚しお機噚に安党に接続し、機噚からデヌタを読み取るこずができたす。AWS パヌトナヌである Domatica 瀟ず協力し、MQTT、Modbus、SIMATIC S7 などの 10 皮類の産業甚プロトコルのサポヌトを远加 したした。これにより、機噚、機械、レガシヌシステムから AWS IoT SiteWise に取り蟌んで、゚ッゞでの凊理や産業甚デヌタレむクを匷化できるデヌタの皮類が倚様化されたした。1 秒未満のレむテンシヌでデヌタをクラりドに取り蟌むこずで、お客様は AWS IoT SiteWise を䜿甚しお、産業掻動党䜓にわたる䜕十䞇ものアセットをほがリアルタむムで監芖できたす。 図3: AWS パヌトナヌである Domatica 瀟の EasyEdge ゜フトりェアをを利甚するこずにより新たにサポヌトされたプロトコルによる機噚ぞの接続が可胜 ただし、クラりドにおいおすべおの機噚デヌタがニアリアルタむムで必芁なわけではありたせん。゚ネルギヌ、組立補造、プロセス業界のお客様ずのプロゞェクトを通しお、クラりドに送信された機噚デヌタのうち、クラりド䞊のダッシュボヌドで䜿甚されおいるニアリアルタむムのデヌタはわずか1030であるこずがわかりたした。残りの 70%  90% は、BI ダッシュボヌドや機械孊習モデルトレヌニングなど、クラりド内のデヌタを数秒ではなく数分以内に必芁ずする分析アプリケヌションで䜿甚されたす。そのため、デヌタの取り蟌みず保存の方法を最適化する必芁がありたした。 そこで、分析のナヌスケヌスに適したコストずパフォヌマンスを提䟛するために、 バッファリングされたデヌタ取り蟌みを発衚 したした。バッファリングされたデヌタ取り蟌みでは、クラりドに取り蟌たれる前に゚ッゞでバッファリングするデヌタストリヌムを顧客が蚭定できたす。これにより、お客様はクラりドぞのデヌタ取り蟌みコストを最倧 70% 削枛できたす。 コスト効率が高く分析ク゚リ甚に最適化されたストレヌゞ AWS IoT SiteWise には耇数のストレヌゞ階局があり、パフォヌマンスずコスト効率のバランスを取りながら、さたざたなナヌスケヌスを柔軟にサポヌトできたす。ホットストレヌゞ階局は頻繁にアクセスされるデヌタに最適化されおおり、むンタラクティブダッシュボヌドなどのリアルタむムアプリケヌションでは曞き蟌みから読み取りたでの埅ち時間が短くなりたす。コヌルドストレヌゞ局は、 Amazon S3 バケットを䜿甚しお、皀に䜿甚されるデヌタを保存したす。新機胜ずしおデヌタをコスト効率よく保存できるように蚭蚈された 新しいりォヌムストレヌゞ階局 を远加したした。りォヌムストレヌゞ階局は BI、レポヌトツヌル、ML モデルトレヌニングなどのアプリケヌションで、曞き蟌みから読み取りたでの埅ち時間が䞭皋床の倧量のデヌタを取埗するのに最適化されおいたす。このりォヌムストレヌゞ階局により、お客様は倧量のデヌタを、 Amazon S3 に近い 1 GB あたりの䟡栌で保持できたす。 りォヌムストレヌゞ階局を䜿甚しおいるお客様は、 新しい Query API も䜿甚できたす。Query API を䜿甚するず、お客様は SQL に䌌たク゚リステヌトメントを䜿甚しお、1 回の API リク゚ストで、アセットモデル、アセット、枬定倀、メトリクス、倉換、集蚈からメタデヌタず時系列デヌタを取埗できたす。この機胜は、Amazon QuickSight、PowerBI、Microsoft Excel などのツヌルず互換性があり、ニアリアルタむムや過去の䌁業業瞟のレポヌトを䜜成できたす。 お客様は、新しい Query API で SQL ク゚リステヌトメントを䜿甚しおデヌタを探玢し、掞察を抜出できたす。次の䟋は、ナヌザヌが名前に「Engine」を含むすべおのマシンの RPM 情報をク゚リする方法を瀺しおいたす。 select a.event_timestamp,b.asset_name ,c.property_name , a.quality,a.integer_value from raw_time_series a,asset b , asset_property c where a.event_timestamp &gt; 1698335614 and b.asset_name LIKE ‘Engine%’ and c.property_name = ‘RPM’ event_timestamp asset_name property_name quality integer_value 26-10-2023T15:53:34 Engine001 RPM GOOD 2857 26-10-2023T15:53:34 Engine002 RPM GOOD 2549 26-10-2023T15:63:34 Engine001 RPM GOOD 2753 26-10-2023T15:63:34 Engine002 RPM GOOD 2349 衚 1: SQL ステヌトメントを䜿甚したク゚リによるデヌタ取埗 機械孊習を䜿甚した予知保党プログラムの掚進 耇数のお客様が、AWS IoT SiteWise からの産業機噚デヌタを Amazon Lookout for Equipment ず統合しお、予枬を行い、機噚の異垞な動䜜を怜出できる機械孊習モデルを䜜成しおいたす。しかし、サヌビス間の連携のためにお客様が耇数のステップを螏む必芁があり、時間のかかるプロセスでした。 AWS IoT SiteWise ず Amazon Lookout for Equipment の新しいネむティブ統合 により、連携のための耇雑な仕組みの構築やコヌドを蚘述したりするこずなく、これら 2 ぀のサヌビス間でデヌタを盎接同期できるようになりたした。これにより、Lookout for Equipment の機械孊習モデルを AWS IoT SiteWise から簡単に構築でき、異垞怜出ず予知保党が可胜ずなりたす。 トペタ自動車ノヌスアメリカ (TMNA) は、AWS IoT SiteWise デヌタを䜿甚しお Amazon Lookout for Equipment で䜜成されたモデルを自瀟の CNC マシンにデプロむしたした。サむトあたり200台以䞊の CNC マシンが幎䞭無䌑で皌働しおいたため、TMNA メンテナンスチヌムにずっお予知保党には時間ずコストがかかりたした。TMNA は、AWS IoT SiteWise を䜿甚しお、障害を数日前に予枬し、蚈画倖のダりンタむムを削枛できる 予枬メンテナンス ゜リュヌションを開発したした。導入以来、お客様は数十件の事故や䜕時間ものダりンタむムを防ぐこずができただけでなく、オペレヌション可甚性を過去 12 か月間の平均で 10% 向䞊させたした。 「圓瀟のフォヌカスラむンの皌働率は78 82% で、毎月玄40時間のダりンタむムが発生しおいたした。AWS の支揎により、マシンに倚くの問題が芋぀かりたした。気付かないたたにしおおくず、重倧な障害に぀ながりたす。珟圚、圓瀟の OA は 92% で、ダりンタむムは玄20時間です。」— Braden Burford, Sr. Maintenance Engineer, Toyota 機噚デヌタのコンテキスト化による匷力な掞察 産業の倉革は、䞻に機噚、機械、レガシヌシステムから埗られるデヌタの可胜性を解き攟぀こずに重点を眮いおいたす。埓来のデヌタ管理システムでは、効率性、拡匵性、革新性に向けた高い芁求を満たすにはもはや十分ではありたせん。これらの機胜匷化により、AWS IoT SiteWise は、デヌタを資産ずしお掻甚するためのスケヌラブルで統䞀された統合アプロヌチを可胜にする最新の産業甚デヌタ基盀を実珟したす。コスト効率が高く、安党で再珟性のあるフレヌムワヌクを提䟛するこずで、お客様が産業倉革のための匷固な基盀を構築し、業務を最適化するのに圹立぀産業甚デヌタセットぞのアクセスを可胜にしたす。 AWS のお客様であるバむオ医薬品の䞖界的リヌダヌである Bristol Myers Squibb (BMS) は、AWS IoT SiteWise による産業デヌタ基盀の近代化によっお業務倉革を実珟されたお客様です。生物補剀、補薬、现胞療法の各郚門にわたる事業戊略を匷化するずいう目暙を掲げおおり、BMS は埓来のデヌタシステムの芋盎しの必芁性を認識したした。圌らの䞻な目的は明確でした。1/ 䌁業党䜓の可芖性を実珟するこず、2/ ゚ンドツヌ゚ンドのトレヌサビリティを確立するこず。3/ プロセス監芖、予枬的資産保守、継続的プロセス怜蚌 (CPV) のための怜蚌枈みの単䞀゚ンタヌプラむズ゜リュヌションを実装するこず。 BMS は、䌁業党䜓の可芖性ず分析を匷化できるデヌタ管理ぞの統合アプロヌチを求めお、AWS IoT SiteWise を採甚したした。BMS は、Enterprise PI Historian からデヌタを匕き出し、それを AWS 䞊の統合デヌタレむクに送るこずで、デヌタ管理においおか぀おないスケヌル、パフォヌマンス、スピヌドを実珟したした。 BMS の重芁な進歩の 1 ぀は、゚ンタヌプラむズリ゜ヌスプランニング (ERP) やその他のシステムからの情報ずデヌタを集玄するこずで、デヌタにコンテキストを远加できるこずでした。これにより、さたざたな堎所で補造されおいる補品バッチのより詳现なサむト分析が可胜になりたした。 「生物補剀、補薬、现胞療法におけるビゞネス戊略の改善を目指すにあたり、可芖性ずトレヌサビリティの匷化が䞍可欠であり、AWS IoT SiteWise は完璧な゜リュヌションでした。AWS を䜿甚しおデヌタ基盀を最新化するこずで、さたざたなデヌタ゜ヌスを統合デヌタハブにシヌムレスに統合し、効率ずスケヌラビリティを最適化したした。この倉革により、さたざたなシステムからのデヌタを組み合わせるこずができ、耇数のサむトにわたる補品バッチの掞察に満ちた分析が可胜になりたした。これにより、アセットのメンテナンスを予枬する胜力が倧幅に匷化され、新しい朜圚的なナヌスケヌスに光が圓おられたした。これはゲヌムチェンゞャヌです。」— Nitin Bhatti, GPS IT, Manufacturing Analytics at Bristol Myers Squibb BMS の倉革は、将来のむノベヌションの舞台ずなりたした。むンフラストラクチャが最新化されたこずで、Predictive Asset Maintenance (PAM) や倚倉量分析など、新たなナヌスケヌスを怜蚎できるようになりたした。長期的なビゞョンには、デヌタの䜿甚ず分析を珟堎の担圓者の範囲を超えお拡倧し、䌁業党䜓の包括的な芖野を提䟛するこずが含たれたす。 AWS パヌトナヌず協力しおビゞネス成果を実珟 デゞタルトランスフォヌメヌションを進めおいる産業界では、プロゞェクトの拡倧が難しいこずに気付きたした。PoC から倧芏暡な䌁業ぞの本栌導入たでむニシアチブをずるこずは、リ゜ヌスを倧量に消費し、専門的なスキルが必芁です。AWS パヌトナヌは、業界党䜓にわたる深い専門知識を持ち、基幹業務のナヌスケヌスを解決する゜リュヌションを提䟛するこずで長期的な顧客䟡倀を生み出すために必芁な掚進芁因を理解しおいたす。これらのパヌトナヌは、お客様が AWS IoT SiteWise を䜿甚しお堅牢なデヌタ基盀を構築できるよう支揎し、そのデヌタ基盀を䜿甚しおお客様の特殊なナヌスケヌスの解決を支揎したす。AWS IoT SiteWise パヌトナヌのいく぀かの䟋を以䞋に瀺したす。 EOT は Twin Fusion を構築したした。これは、AWS IoT SiteWise を䜿甚しお、AWS クラりド内の高床な分析、ML、生成 AI を掻甚しおレガシヌ IoT デヌタの掻甚、管理、芖芚化、アクションを実珟する、Software-as-a-Service (SaaS) 補品です。Twin Fusion は、 産業デヌタファブリック (IDF) に関する AWS ガむダンス の䞀郚です。Twin Fusion は、マシンや時系列デヌタからの IIoT デヌタやセマンティックデヌタを AWS IoT SiteWise に取り蟌むための゚ンドツヌ゚ンドの゜リュヌションを提䟛したす。Twin Fusionは、耇数の産業甚デヌタ゜ヌスからのメタデヌタを統合する䌁業党䜓のデゞタルツむングラフアセットモデルを提䟛したす。この補品は、゚ンドナヌザヌデヌタ分析、アセット階局怜玢、埋め蟌みMLモデル、およびAIによる産業資産の䌁業党䜓の最適化のためのオペレヌションダッシュボヌドを提䟛したす。 TCS は、時系列デヌタを AWS サヌビスでモダナむズするパヌトナヌであり、゚ッゞず AWS クラりドに AWS IoT SiteWise をデプロむするこずで、顧客の䟡倀実珟たでの時間を短瞮しおいたす。TCS は、お客様が耇数の時系列デヌタを単䞀の゚ンタヌプラむズクラりドヒストリアンに取り蟌み、デヌタのサむロ化を解消しお、機噚のダりンタむムの最適化、サむクルタむムの改善、䞀貫した生産性、䞍良率の䜎䞋、環境コンプラむアンスなどの産業䞊の課題を解決できるよう支揎したす。 Edge2Web は、ノヌコヌドおよびロヌコヌドの産業甚アプリケヌションの オヌプンプラットフォヌム の基盀ずしお AWS IoT SiteWise を䜿甚しおいたす。Edge2Web アプリケヌションは、お客様が資産をより適切に管理し、機械のダりンタむムを削枛し、補品品質を向䞊させ、生産パフォヌマンスを最適化するのに圹立ちたす。 TensorIoT は、AWS IoT SiteWise 䞊に構築された SmartInsights ゜リュヌションを開発したした。SmartInsights は、「起こったこず」ず「これから起こるこず」を1぀の画面で確実に芖芚化したす。SmartInsights を䜿甚するず、お客様は予知保党、リモヌトアセット監芖、再生可胜資産の性胜予枬ず保守などのナヌスケヌスを解決できたす。 Radix Engineering は、産業界のお客様が゚ッゞに保存されおいる時系列デヌタを掻甚し、AWS IoT SiteWise を䜿甚しお埓来の産業オペレヌション技術 (OT) アヌキテクチャを最新化できるよう支揎するず同時に、統合された機械孊習 (ML) モデルず掞察により運甚ず信頌性の向䞊を促進するこずに重点を眮いおいたす。 これらのパヌトナヌ゜リュヌションはそれぞれ、特定の産業䞊の課題に察凊するだけでなく、長期的なビゞネス䟡倀ず効率性を実珟するためにデゞタルトランスフォヌメヌションの取り組みを成功させる䞊で、専門知識ず AWS IoT SiteWise などの高床なツヌルが果たす重芁な圹割を瀺しおいたす。 倉革の青写真 トペタ自動車北米ず Bristol Myers Squibb の成功事䟋は、他の䌁業の青写真ずしお圹立っおいたす。これらのリヌダヌをはじめずする倚くの䌁業が、スケヌラブルで再珟性のある産業デヌタ基盀を提䟛するサヌビスずしお AWS IoT SiteWise を採甚し、それを日垞業務に統合し、過去およびリアルタむムの機噚デヌタの力を掻甚しおデゞタルトランスフォヌメヌションの䟡倀を実珟しおいたす。 AWS IoT SiteWise を開始するには、 ここをクリック しおください。 re:Invent 2023 に参加する堎合は、以䞋のセッションに参加しお、これらの新機胜を深く掘り䞋げおください。 IOT206 | Accelerating industrial transformation with IoT on AWS IOT215 | Accelerate shop floor digitization with edge-to-cloud data integration IOT212 | Modernizing your data historian with AWS IoT SiteWise IOT203 | Automated anomaly detection for smart manufacturing この蚘事は Sophie Pagalda、Sharon Allpress、Jan Borch、David Castro によっお曞かれた The Blueprint for Industrial Transformation: Building a Strong Data Foundation with AWS IoT SiteWise の日本語蚳です。この蚘事は Solutions Architect の西亀真之が翻蚳したした。
はじめに モノのむンタヌネット ( IoT ) ワヌクロヌドを導入しようずする堎合、䌁業はプラットフォヌムを耇数の遞択肢から遞択するこずになりたす。この遞択肢はさたざたで、独自デバむスのハヌドりェアを含めお完党にれロから構築する方法や、事前に蚭定されたハヌドりェアを賌入しお、完党な SaaS (Software as a Service) IoT プラットフォヌムに接続するような方法がありたす。 このブログの目的は、IoT ゜リュヌションの蚭蚈に必芁なスキルや知識を理解し、どのコンポヌネントを自前で開発しお、どのコンポヌネントを倖郚の技術゜リュヌションずしお買っおくるのかを刀断できるようにするこずです。IoT ワヌクロヌドを AWS に移行しようず考えおいる堎合は、 「&nbsp; AWS IoT Core ぞのシヌムレスな移行を蚈画する &nbsp;」&nbsp;をご参照ください。 AWS を利甚するこずによる、移行プロセスの簡略化、提䟛可胜なサポヌト、埗られるメリットなどを理解するための最初のステップずしお圹立ちたす。 䞀般的な AWS IoT アヌキテクチャのコンポヌネント デバむスの補造 ハヌドりェアの蚭蚈ず補造では、考慮すべき芁玠がいく぀かありたす。 芁件に基づき、゜リュヌションの珟圚および将来のニヌズを満たすためにハヌドりェアを遞択する必芁がありたす。 IoT の䞀般的な制玄、぀たり電力(䟛絊ず消費)、接続性、セキュリティ、オペレヌティングシステムの管理に関する意思決定が必芁です。 ハヌドりェアを瀟内で補造しおいない堎合、オリゞナルデバむスメヌカヌ ( ODM ) を遞択する必芁がありたす。ODM には、倧量のデバむスを生産するための補造ラむン、ツヌル、プロセスが揃っおいたす。 通垞、プリント基板 ( PCB ) の回路図、郚品衚、ファヌムりェア、プロビゞョニング芁件など、提䟛する仕様に基づいお補造できたす。 デバむスのハヌドりェア制玄を考慮する項目 : 消費電力 : デバむスの䜿甚方法ず堎所は、電源䟛絊に倧きな圱響を䞎えたす。りェアラブルデバむスは小さなバッテリヌで動䜜したすが、テレビは AC 電源を必芁ずしたす。バッテリヌを必芁ずするデバむスの堎合、バッテリヌが再充電可胜か亀換可胜か、ハヌドりェアの寿呜たで利甚可胜かを刀断する必芁がありたす。 オペレヌティングシステムずファヌムりェア : オペレヌティングシステムやファヌムりェアの遞択は、デバむスの皮類ず期埅されるタスクによっお異なりたす。小型で䜎消費電力のデバむスは FreeRTOS などの リアルタむムオペレヌティングシステム が必芁かもしれたせんし、倧型で専甚の電源を必芁ずするデバむスは Linux などのフルスタックオペレヌティングシステムが必芁になる堎合もありたす。 接続性 : IoT ゜リュヌションには、 むヌサネット 、 Wi-Fi 、 セルラヌ 、 LoRaWAN 、 Bluetooth Low Energy ( BLE ) など、倚くの接続性ずプロトコルのオプションがありたす。デバむスの蚭眮堎所、可甚性、消費電力、セキュリティ、ナヌスケヌスによっお、゜リュヌションに最適な接続オプションが決たりたす。 AWS ではこのコンポヌネントを支揎するために、 AWS デバむス認定プログラム &nbsp;を完了した AWS パヌトナヌ補デバむスのリストである AWS Partner Device Catalog &nbsp;を提䟛しおいたす。 このリストにあるデバむスは、AWS IoTずAWSのベストプラクティスずの互換性を確保し、垂堎ぞの投入を高速化するのに圹立ちたす。さらに、自瀟補造のデバむスをお持ちの堎合は、 AWS IoT Core Device Advisor &nbsp;を䜿甚しお、AWS IoT Core ず確実か぀安党に接続できるこずを怜蚌できたす。 デバむスのプロビゞョニング IoT ゜リュヌションにおけるデバむスのプロビゞョニング方法は、デバむスの機胜ずその補造プロセスによっお異なりたす。ここでの䞻な焊点は、デバむスずその認蚌情報の䜜成方法にありたす。 セキュリティは、あなた、゚ンドナヌザ、デバむス補造業者にずっお最優先事項であるべきです。X.509 蚌明曞を䜿甚する堎合、補造プロセスで、デバむスが䞀意ずなる蚌明曞ず秘密鍵のペアを取埗するタむミングず、IoT ゜リュヌションにどのように登録するかを明確にする必芁がありたす。 デバむスプロビゞョニングず蚌明曞管理を怜蚎する際のポむント : メヌカヌの遞択 : 信頌できる蚌明曞チェヌンは、ハヌドりェアを瀟内開発たたは OEM パヌトナヌを遞択するこずから始たりたす。埌者の堎合、サプラむチェヌン党䜓で蚌明曞の敎合性が維持されおいるこずを確認するために、そのプロセスを怜査する必芁がありたす。&nbsp; 認蚌局 ( CA ) : デバむスの補造に柔軟性を持たせるために、AWS では独自の CA、サヌドパヌティの CA、 Amazon ルヌト認蚌局 ( CA ) &nbsp;など、耇数の遞択肢を甚意しおいたす。&nbsp; ハヌドりェアセキュリティモゞュヌル&nbsp; : IoT デバむスに組み蟌たれたセキュア゚レメントは、デバむスセキュリティの基盀を圢成したす。これにより、蚌明曞やシヌクレットの暗号化ず改ざん防止の保存、ファヌムりェアずアプリケヌションの怜蚌が可胜になりたす。これを支揎するために、AWS には&nbsp; AWS IoT ExpressLink を搭茉したさたざたな接続モゞュヌルがありたす。これらのモゞュヌルには AWS が芁求するセキュリティ芁件を実装した゜フトりェアが含たれおいたす。 倖郚リ゜ヌス : カスタムプロビゞョニングプロセスを可胜にするために、IoT゜リュヌション内でのリ゜ヌス䜜成が必芁になる堎合がありたす。 これらのリ゜ヌスは、デバむスの皌働台数が増加するに぀れおスケヌルするように蚭蚈する必芁がありたす。 AWS の堎合、これは&nbsp; Pre-provisioning hook &nbsp;ずしお機胜する&nbsp; AWS Lambda function になる可胜性がありたす。 デバむスレベルのロゞック : デバむスには、確実か぀安党にプロビゞョニングされるため、オンデバむスのロゞックが必芁になる堎合がありたす。 AWS では、 AWS IoT SDKs &nbsp;はこのオンデバむスのロゞックを可胜にするために蚭蚈されおいたす。 AWS IoT Core を䜿甚したデバむスのセキュアなプロビゞョニングず登録の詳现に぀いおは、 AWS IoT Core Device Provisioning &nbsp;や AWS ホワむトペヌパヌの&nbsp; Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core &nbsp;をご参照ください。 デバむス管理 成熟したプロビゞョニングのプロセスがあれば、デバむスは最初に接続したずきからセキュアで最新の状態に保たれたすが、ファヌムりェアや蚌明曞のロヌテヌションなどの曎新が必芁になる堎合がありたす。完党にコンプラむアンスを遵守し、最高のナヌザヌ゚クスペリ゚ンスを提䟛するためにはこうした曎新が必芁です。これらの曎新のための゜リュヌションは、配信の䞭断、接続性、ロヌルバックルヌチン、自動スケヌリングぞの察応が必芁ずなるでしょう。 デバむス管理戊略を怜蚎する際の考慮事項 : デバむス敎理 : デバむスをすばやく識別し操䜜できるこずで、コンプラむアンスから倖れた堎合のトラブルシュヌティングず隔離が可胜になりたす。倚数のデバむスを運甚する堎合、デバむスの敎理、むンデックス䜜成、分類を行う゜リュヌションが必芁になりたす。AWS では、 Fleet Hub for AWS IoT Device Management &nbsp;を䜿甚できたす。 デバむス監芖 : デバむス矀のステヌタスを監芖できるこずは、誀動䜜やコンプラむアンス違反のデバむスを特定するのに重芁です。デバむスのメトリクス、ログ、蚭定などの芳枬デヌタずセキュリティデヌタを収集する監芖゜リュヌションを甚意しおください。 AWS IoT Device Defender は、皌働しおいる倚数のデバむスのセキュリティのための監査ず継続的なむンテリゞェントな監芖を提䟛したす。 むベントぞ察応 : ログ、メトリクス、アラヌムの最小セットを定矩するこずで、運甚チヌムは倧きなビゞネスの䞭断を防ぐこずができたす。監芖゜リュヌションず統合できるスケヌラブルなアラヌト゜リュヌションが必芁です。AWS では&nbsp; Amazon CloudWatch &nbsp;を䜿甚できたす。 Over-The-Air ( OTA ) アップデヌト察応 &nbsp;: デバむスは曎新を受信しお適甚できるように蚭蚈する必芁がありたす。IoT ゜リュヌションは曎新を送信し、デバむスの曎新進捗を監芖できる必芁がありたす。AWS では、 AWS IoT Device Management Jobs &nbsp;を䜿甚できたす。 このコンポヌネントを支揎するために、 AWS IoT Device Management 、 AWS IoT Device Defender 、 AWS IoT Core &nbsp;は、皌働しおいる IoT デバむス党䜓のデバむス敎理、監芖、アラヌト、OTA 曎新のための完党な機胜セットを提䟛したす。 デバむスデヌタの取り蟌み すべおの IoT ゜リュヌションがデヌタ取り蟌みに焊点を圓おるわけではありたせんが、そうした゜リュヌションでは、このデヌタ取り蟌みがプラむマリなコンポヌネントずなり、゜リュヌションの党䜓的なアヌキテクチャに圱響したす。このコンポヌネントに察する芁件は、゜リュヌションのスケヌル、コスト、セキュリティ、パフォヌマンスに圱響するため、珟圚ず将来のデヌタ取り蟌みを考慮した IoT ゜リュヌションのアヌキテクチャを蚭蚈する必芁がありたす。 デヌタ取り蟌み戊略を怜蚎する際の考慮事項 : デヌタサむズ : デバむスがハヌドりェア的に制玄されおいない堎合、効率を高めるためにメッセヌゞサむズを䞀定に 保ち、小さいメッセヌゞをバッチ凊理するこずを怜蚎しおください。バッチ凊理は、メッセヌゞ送信時だけでなく、IoT Core に取り蟌んだ埌に IoT ルヌルを䜿甚しお実行できる こずに留意しおください。 デヌタの頻床ず構造 : デバむスがメッセヌゞを送信する頻床を考慮し、゜リュヌションがそのスケヌルに察応できるように蚭蚈しおください。頻床に加えお、デヌタの構造がメッセヌゞベヌスかストリヌミングベヌスの IoT ワヌクロヌドかを決定したす。 MQTT トピック蚭蚈 : このプロトコルを䜿甚する堎合は、最小限の暩限コミュニケヌションを実斜し぀぀、将来のデバむス導入をサポヌトできるスキヌマのバランスをずる必芁がありたす。適切なトピックスキヌマは 、柔軟なメッセヌゞフィルタリングずメッセヌゞルヌティングを可胜にする共通の呜名芏則を実装したす。 デヌタストレヌゞ : メッセヌゞのフロヌず䜿甚法を分析し、適切なストレヌゞ゜リュヌションを特定しおください。これらのストレヌゞ゜リュヌションは、ナヌスケヌス、党䜓的なメッセヌゞ構造、スケヌル ( 珟圚ず将来の成長 ) 、コストなど、耇数の考慮事項がありたす。&nbsp; ルヌティング : 取り蟌んだ埌、メッセヌゞをストレヌゞや他のサヌビスにルヌティングするための、ルヌルベヌスの簡単な゜リュヌションが必芁です。これらのルヌルは、さらなるメッセヌゞのバッチ凊理、凊理、アラヌトなどに䜿甚できたす。&nbsp; ゚ッゞゲヌトりェむ : 䞀般的なアヌキテク チャパタヌンは、デヌタを取り蟌み、凊理、バッチ凊理しおから IoT ゜リュヌションに送信するゲヌトりェむたたはブロヌカヌを甚意するこずです。これは、デバむスに近いロヌカル゚ンドポむント、たたは IoT ゜リュヌションに近いクラりドベヌスのゲヌトりェむずしお実装できたす。 このコンポヌネントの支揎ずしお、AWS IoT Core を䜿甚するず、むンフラを管理するこずなく、 数十億ものIoTデバむスを接続 し、 Amazon SQS &nbsp;、 Amazon Kinesis 、 Amazon SNS などの他の AWS サヌビスに 䜕兆ものメッセヌゞをルヌティング できたす。AWS には、゚ッゞランタむムを提䟛するオヌプン゜ヌスの&nbsp; AWS IoT Greengrass &nbsp;もありたす。AWS IoT Core を䜿甚したデヌタ取り蟌みのパタヌンの詳现は、AWS IoT ブログの「 IoT デヌタの取り蟌みず可芖化のための7぀のパタヌン – ナヌスケヌスに最適なものを決定する方法 」をご参照ください。 リアルタむムのビデオずデヌタストリヌム 前のセクションで説明したものに加えお、IoT ワヌクロヌドがビデオやその他の高容量デヌタストリヌムで構成されおいる堎合は、さらにいく぀かの点を考慮する必芁がありたす。デヌタストリヌムを扱う IoT ワヌクロヌドは、ビデオ凊理や分析などのアプリケヌション向けに、高頻床か぀非構造化の生デヌタを扱うこずが倚くなりたす。 ストリヌミングベヌスのワヌクロヌドを考慮するポむント :&nbsp; プロデュヌサ偎 : デヌタストリヌムがどのように生成されるかは、IoT ゜リュヌションの䞋流でどのようにむンゞェスト、凊理、保存されるかに盎接圱響したす。 デバむスのストリヌミングプロトコル、ネットワヌクの可甚性、アクセシビリティ 、コストの制玄などの偎面が、ストリヌムの生成方法に圱響したす。&nbsp; コンシュヌマ偎 : デヌタストリヌムの消費ず凊理は、IoT ゜リュヌションの必芁なスケヌルず党䜓的なコストに圱響を䞎える可胜性がありたす。ビデオストリヌムなどの高頻床デヌタは、高可甚性で管理が容易で、スルヌプット芁件を凊理できる堅牢なアヌキテクチャヌが必芁になりたす。 これらのストリヌムの盎接的なビゞネス䟡倀を総合的な IoT ゜リュヌションで考慮しお、最もコスト効果的か぀スケヌラブルな方法で消費および凊理するこずを決定しおください。&nbsp; このようなアヌキテクチャを支揎するために、AWS には AWS IoT Greengrass 、Amazon Kinesis 、 Amazon Kinesis Video Streams がありたす。 AWS IoT Greengrass は、゚ッゞでデヌタストリヌムを 容易に消費および凊理し、 AWS 提䟛のコンポヌネント を介しお AWS に転送できる゚ッゞランタむムを提䟛するオヌプン゜ヌスです。 Amazon Kinesis は、 デバむスから盎接 、AWS IoT Greengrass Stream manager コンポヌネント から、たたは AWS IoT ルヌル から生成されるストリヌミングデヌタをコスト効果的に凊理および分析できるマネヌゞドサヌビスです。 Amazon Kinesis Video Streamsは、デバむスから盎接、たたは AWS IoT Greengrass の Edge connector for Kinesis Video Streams &nbsp;を介しお生成されたビデオストリヌムを、゜ヌスプロトコルに関係なく安党に衚瀺、凊理、分析できるマネヌゞド AWS サヌビスです。 デバむスのコマンド・アンド・コントロヌル コマンド・アンド・コントロヌルは、デバむスにアクションの実行を芁求するメッセヌゞを送信し、成功たたは倱敗の確認応答を受け取る操䜜です。これは、デバむスぞのコマンドメッセヌゞたたは IoT ゜リュヌションからデバむスの状態を倉曎しお䌝達するこずで実珟できたす。デヌタ取り蟌みずコマンド・アンド・コントロヌルのための IoT ゜リュヌションのメッセヌゞングニヌズを評䟡および最適化するこずで、パフォヌマンスずコストのバランスが最適になりたす。 デバむスのコマンド・アンド・コントロヌル戊略に぀いおの怜蚎パタヌン : コマンドメッセヌゞング : 遞択したメッセヌゞングプロトコルを䜿甚しお、コマンドを盎接デバむスに送信したす。デバむス偎のロゞックを実装しお、コマンドの受信、実行、デバむスの実行ステヌタスの報告をする必芁がありたす。このパタヌンでは、IoT ゜リュヌションでコマンドメッセヌゞを確実に配信する必芁があり、デバむスがオフラむンになったり接続が切断された堎合には、察凊可胜な障害が発生するこずに留意しおください。 デバむスの状態 : デバむスの状態は IoT ゜リュヌションで凊理し、コマンドの蚭定や実行ステヌタスの曎新に䜿甚できたす。この状態は、IoT ゜リュヌションからの倉曎があった際にデバむスぞ送信され、デバむス自身が倉曎を加えた堎合にもそれを送り返すこずができる、単玔なドキュメントずするこずができたす。このパタヌンでは、デバむスが接続されおいなくおも、IoT ゜リュヌションず察話できたす。 このコンポヌネントを支揎するために、AWS IoT Core は&nbsp; AWS IoT Device Shadow service  、 MQTT5 リク゚スト/レスポンスパタヌン 、AWS IoT デバむス管理は AWS IoT Job 機胜 を提䟛しおいたす。デバむスのコマンド・アンド・コントロヌルの実装パタヌンの詳现は、「 AWS IoT Lens for the AWS Well-Architected Framework 」の デバむスコマンド の項を参照しおください。 クラりドアヌキテクチャ IoT ゜リュヌションがクラりドに存圚する堎合、地域を限定した1぀のサヌビスや小芏暡なデバむス矀から始めるこずができたす。これは抂念実蚌やデモンストレヌションには十分ですが、゜リュヌションを本番に移行する際には、クラりドベヌスのベストプラクティスを考慮しお構築されおいるこずを確認する必芁がありたす。「 AWS Well-Architected framework &nbsp;」は、゜リュヌションの蚭蚈、構築、レビュヌの際に、AWS を安党か぀高パフォヌマンス、回埩性が高く、効率的に䜿甚しおいるこずを確認するのに圹立ちたす。AWS IoT におけるクラりドベヌスのベストプラクティスの詳现は、 IoT Lens – AWS Well-Architected Framework &nbsp;を参照しおください。 たずめ このブログでは、兞型的な IoT ゜リュヌションを構成する䞻芁な技術芁玠に分解し、それぞれに぀いお考慮すべき芁件ず泚意点を明らかにしたした。IoT ゜リュヌションの構築は間違いなく耇雑ですが、AWS IoT を掻甚するこずによっお、その道のりを簡玠化、合理化するこずができたす。さらに、 AWS パヌトナヌ が構築した AWS IoT ゜リュヌションを利甚するこずで、垂堎投入たでの時間を短瞮するこずもご怜蚎ください。 著者玹介 Kai-Matthias Dickman &nbsp;は、Amazon Web Services ( AWS ) の IoT ゜リュヌションアヌキテクトです。倧䌁業の開発者や意思決定者ず協力しお、AWS IoT サヌビスの導入を掚進するこずを楜しんでいたす。IoT ずクラりドに関する深い知識を持っおおり、スタヌトアップから倧䌁業に至る䞖界䞭のお客様ず協力しお、AWS ゚コシステムを䜿った IoT ゜リュヌションの構築を可胜にする圹割を担っおいたす。 Nicholas Switzer &nbsp;は、Amazon Web Services の IoT ゜リュヌションアヌキテクトです。2022幎に AWS に加入し、IoT 、゚ッゞコンピュヌティング、コネクテッドプロダクト分野を専門ずしおいたす。アメリカに拠点を眮き、日垞生掻を改善するスマヌトプロダクトの構築を楜しんでいたす。 この蚘事は Kai-Matthias Dickman &nbsp;,&nbsp; Nicholas Switzer &nbsp;によっお曞かれた Deploying and managing an IoT workload on AWS &nbsp;の日本語蚳です。この蚘事は ゜リュヌションアヌキテクト の䌊藀 䞀成が翻蚳したした。
e コマヌス垂堎は幎々拡倧を続けおおり、小売業界のさらなる倉革を埌抌ししおいたす。小売業者は、より倚くの顧客を EC サむトぞ呌び蟌むこずに尜力しおおり、特にブラックフラむデヌやサむバヌマンデヌなどのピヌク時の売䞊においお、EC サむトが占める割合が高たっおいたす。 Statista によるず 、2022 幎第 3 四半期、米囜の小売業党䜓の売䞊においお、 e コマヌスの占める割合は 14.8  で、これは前四半期を䞊回っおおり、金額にしお玄 2660 億ドルになりたす。 小売業のリヌダヌが、e コマヌス事業から曎なる䟡倀を埗る方法を暡玢しおいるのは、驚くこずではありたせん。そのため、倚くの䌁業がりェブサむトのトラフィックを監芖し、売䞊に圱響を䞎え埗るオンラむンアクティビティの倉化の兆候を芋぀け出そうずしおいたす。䟋えば、トラフィックが枛少するこずは、補品の䟡栌蚭定が最適でなかったこずや、システム障害などの芁因により、需芁が枛少したこずを瀺す可胜性がありたす。いずれにせよ、売䞊は打撃を受けるこずになりたす。 䞀方、e コマヌスのトラフィックが急増するこずは、小売業者にずっお良いこずのように思えたすが、必ずしもそうずは限りたせん。䟋えば、䟡栌蚭定にミスがあり、オンラむンショップの顧客がずんでもない安倀で商品を買い占めおいった堎合です。最近、ある倧手小売業者が、りェブサむト䞊の小数点の䜍眮を間違えお、100 ドルの人気商品をわずか 10 ドルで衚瀺したこずがありたした。オンラむンショップの顧客は倧喜びで商品を倧量に泚文し、小売業者はこの䞍手際を修正し、さらなる損倱を食い止めるために奔走するこずになりたした。 どちらのシナリオでも、重芁なのは、e コマヌスのトラフィックを垞に把握し、発生した問題を解決するためにチヌムを迅速に動員するこずです。そこで、アマゟン りェブ サヌビス AWS の人工知胜ず機械孊習゜リュヌションが圹に立ちたす。小売業者は、ビデオやデヌタストリヌムをリアルタむムで収集、凊理、分析できる Amazon Kinesis や、メトリクス内の異垞を自動的に怜出し、その根本原因を特定する Amazon Lookout for Metrics などのサヌビスから倚倧なる恩恵を受けるこずができたす。 トラフィックの倉動に察凊する 小売業者は、e コマヌスのトラフィックが季節、月、日付、時間垯によっお倧きく倉化するこずをご存じでしょう。䟋えば、倚くの e コマヌスサむトでは、朝方の時間垯よりも倕方の時間垯でトラフィックが倚くなりたす。たた、平日ではなく、週末にトラフィックが急増するケヌスもありたす。䞀方、䌑日やその他のピヌク時のトラフィックは、これらのトレンドのいずれにも圓おはたらないかもしれたせん。このように動的で様々なパタヌンがあるため、ナヌザヌトラフィックの少数掟な異垞をニアリアルタむムで怜出するこずは非垞に困難です。 倧芏暡な e コマヌスを展開する䌁業の倚くは、ナヌザヌトラフィックの䞻芁な異垞を怜出するための手順をすでに敎えおいたす。しかし、これらのプロセスは、静的なアラヌトや手動による監芖技術に䟝存しおいるこずが倚く、少数掟な異垞をニアリアルタむムで怜出するこずは困難であり、問題が起こった際にチヌムが迅速に介入し、察応するこずが難しくなっおいたす。 小売業者は、過去のデヌタパタヌンに基づいお、ナヌザヌトラフィックのわずかな倉化を怜出するこずができるスマヌトな゜リュヌションを必芁ずしおいたす。しかし、静的なルヌルに基づいおこれらの傟向をプログラミングするこずは、非垞に時間がかかり、導入埌の効果もあたり期埅できないこずがありたす。 予想されるトラフィックの倉動を考慮し぀぀も、小売業者が自動的に少数掟なそしお䞻芁な異垞を怜知したい際に、AWSの異垞怜知゜リュヌションがどのように圹立぀かを詳しく芋おいきたしょう。 図1. e コマヌストラフィックのための異垞怜知゜リュヌションのアヌキテクチャ AWS の異垞怜知゜リュヌションずの連携 この゜リュヌションは、デヌタ収集ず異垞怜知を自動化し、デヌタを操䜜しお、重倧性に基づいお異垞をフィルタリングするためのグラフィカルナヌザヌむンタヌフェヌスを提䟛したす。ここからは、この゜リュヌションがどのように機胜するかを説明したす。 顧客は、オンラむンショッピングのために e コマヌスアプリケヌションを利甚したす。 &nbsp; プロセスは、顧客がモバむルたたはデスクトップアプリケヌションを䜿甚しお、e コマヌスのりェブサむトで商品を怜玢し、衚瀺するこずから始たりたす。買い物かごに商品を入れた埌、決枈ペヌゞで賌入を完了したす。これらのペヌゞのトラフィックは、時間間隔に基づくデヌタの塊に分解されたす。これらは、トラフィックのパタヌンを理解するために䜿甚できるデヌタポむントずしお機胜したす。 デヌタは、取り蟌たれ、倉換され、保存されたす。 &nbsp; e コマヌスアプリケヌションは、耇数のフォヌマットず異なる量のデヌタを生成したす。それを理解するためには、デヌタを継続的に取り蟌むストリヌミングプラットフォヌムにデヌタを䟛絊する必芁がありたす。この゜リュヌションでは、 Amazon Kinesis Data Streams あらゆる芏暡のデヌタストリヌムの取埗、凊理、保存を支揎を䜿甚しお、ナヌザヌのトラフィックを取埗し、e コマヌスアプリケヌションずのやりずりを蚘録したす。通垞、収集したデヌタを修正たたは「倉換」しお、迅速な分析や機械孊習に適した圢匏で保存する必芁がありたす。 Amazon Kinesis Data Firehose ストリヌミングデヌタを取り蟌み、倉換し、デヌタレむク・デヌタストア・分析サヌビスに配信するこずができるサヌビスや AWS Lambda サヌバヌやクラスタを意識せずにコヌドを実行できるサヌバヌレス、むベント駆動型のコンピュヌティングサヌビスなどの AWS サヌビスは、デヌタを倉換しお分析甚に準備するために圹立ちたす。デヌタは、どこからでもどんな量のデヌタでも取り出せるように構築されたオブゞェクトストレヌゞサヌビス、 Amazon Simple Storage Service (Amazon S3) を䜿っお、効率的にクラりドに保存されたす。 トラフィックの異垞を怜出し、チヌムに通知したす。 &nbsp; デヌタをニアリアルタむムで分析し、異垞を特定する準備が敎ったので、ここからが Amazon Lookout for Metrics の出番です。たずは、Amazon Lookout for Metrics で 怜出噚 を䜜成し、Amazon S3 デヌタリポゞトリからデヌタを自動的に取り蟌むこずから始めたす。怜出噚が起動するず、Amazon Lookout for Metrics はデヌタの監芖を開始し、異垞があればニアリアルタむムでフラグを立おたす。誀怜知を枛らすために、怜知システムの感床を 0 から 100 の間で調敎するこずができたす。機械孊習技術を䜿甚しお、Amazon Lookout for Metrics は、トラフィックパタヌンからフィヌドバックを埗お、時間の経過ずずもに怜出結果の継続的な改善をしたす。圓然ながら、異垞があればチヌムメンバヌに通知したくなるでしょう。通知により、りェブサむトで䜕が起きおいるのかを理解でき、必芁に応じお迅速に是正措眮を講じるこずができるようになりたす。この゜リュヌションは、 Amazon Simple Notification Service (Amazon SNS) ずシヌムレスに統合されおおり、SMS テキストメッセヌゞ、モバむルプッシュ、電子メヌルを通じおアラヌトや通知を自動的に送信するこずができたす。 たずめ AWS の異垞怜知゜リュヌションにより、小売業者は e コマヌスのトラフィックを監芖し、売䞊に圱響を䞎え埗るトラフィックパタヌンの異垞を迅速に怜知するための匷力なツヌルを手に入れたした。これは、埓来の静的アラヌトや手動による監芖技術を倧きく前進させるものです。オンラむン販売の拡倧ず䞍必芁な損倱の回避を目指す小売業者にずっお、このAWSの゜リュヌションは、コストず時間のかかる自瀟開発゜リュヌションに投資するこずなく、目暙を達成するための効果的な方法ずなり埗るでしょう。 各サヌビスの詳现は Amazon Lookout for Metrics Developer Guide Amazon Kinesis Data Streams Developer Guide Amazon Kinesis Data Firehose Developer Guide 著者に぀いお Aditya Pendyala Aditya は、NYC を拠点ずする AWS のシニア゜リュヌションアヌキテクトです。クラりドベヌスのアプリケヌションのアヌキテクトずしお豊富な経隓がありたす。珟圚、倧䌁業向けに、拡匵性、柔軟性、耐障害性に優れたクラりドアヌキテクチャの構築を支揎し、クラりドに関するあらゆるこずの案内をしおいたす。Shippensburg 倧孊でコンピュヌタサむ゚ンスの理孊修士号を取埗したした。たた、圌は、” When you cease to learn, you cease to grow “ずいう蚀葉を信条ずしおいたす。 翻蚳は Solutions Architect 金成が担圓したした。原文は こちら です。
テレコム 5G および IMS コンテナベヌスのワヌクロヌドは、 Multus CNI を利甚しおトラフィックずルヌティングの分離ずパケットアクセラレヌションを実珟したす。Multus コンテナネットワヌクむンタヌフェむスプラグむンを䜿甚するず、Kubernetes ポッドを耇数のむンタヌフェむスずネットワヌクに接続できるようになりたす。Multus CNIは「メタプラグむン」であり、 VPC CNI ( Amazon Elastic Kubernetes Service (Amazon EKS) のデフォルト CNI)、 IPVLAN CNI などの他のCNIを呌び出すこずでこれを実珟したす。VPC CNI は Kubernetes ポッドのプラむマリむンタヌフェむスを管理したすが、IPVLAN CNI では、ワヌカヌノヌドの Elastic Network Interface (ENI) 䞊の同じ MAC アドレスを䜿甚するこずで、ポッドがワヌカヌノヌドのセカンダリむンタヌフェむスを䜿甚できるようになりたす。Multus CNI は、 host-local 、 static 、および whereabouts などの IPAM CNI も呌び出したす。 「 Amazon EKS now supports Multus CNI 」の蚘事は、Amazon EKS で Multus ワヌクロヌドをデプロむし始めるのに圹立ちたす。Amazon EKS に Multus ベヌスのワヌクロヌドをプロダクション向けにデプロむするには、次の 2 ぀のトピックの管理を蚈画する必芁がありたす。 Multus ワヌカヌノヌドグルヌプ: ワヌカヌノヌドサブネット、およびワヌカヌノヌドの IP アドレス管理。各ワヌカヌノヌド ENI にはサブネットの IP アドレスが必芁 Multus ポッドネットワヌク: ワヌカヌノヌドサブネットからの Multus ポッドの IP 管理、および Amazon Virtual Private Cloud (Amazon VPC) でのポッド通信。 この蚘事では、暙準の Multus ノヌドグルヌプのデプロむ方法ず、Amazon VPC 内の Multus ワヌクロヌドで ipvlan CNI を䜿甚する際の䞊蚘のトピックを管理するための課題ずアプロヌチに぀いお説明したす。 暙準的な Multus ノヌドグルヌプ導入アプロヌチ 䞊の図は、IPVLAN CNIを䜿甚した Multus ワヌクロヌドのデプロむ䟋を瀺しおおり、この蚘事で説明しおいきたす。この䟋では、Amazon EKS クラスタヌず 2 ぀のワヌカヌノヌドを持぀ノヌドグルヌプがありたす。䞡方のワヌカヌノヌドは、次のように 2 ぀のサブネットに接続されたす。 eth0 ネットワヌク:10.10.12.0/24 (VPC CNI、即ちポッドのプラむマリむンタヌフェむスに䜿甚) eth1 ネットワヌク:10.10.1.0/24 (Multus ipvlan cni、即ちポッドのセカンダリむンタヌフェむスに䜿甚) 䞊のサンプルデプロむ方法では、デプロむは Amazon EKS クラスタヌデプロむから始たり、その埌に Amazon EKS ノヌドグルヌプのデプロむが続きたす。ノヌドグルヌプがデプロむされたら、Multus CNI ず関連するプラグむンをデプロむしおワヌクロヌドをサポヌトできたす。プラグむンがデプロむされたら、ワヌクロヌドをデプロむできたす。 次のセクションでは、Multus ワヌカヌノヌドグルヌプず IP 管理のデプロむ戊略に぀いお説明したす。 Multus ワヌカヌノヌドグルヌプのデプロむず IP 管理 Multus ワヌカヌノヌドデプロむ 自己管理型の Multus ノヌドグルヌプは、オヌトスケヌリンググルヌプを䜿甚しお埩元力最小限のワヌカヌ数を維持ずスケヌラビリティを提䟛したす。オヌトスケヌリンググルヌプは、 起動テンプレヌト を䜿甚しお Amazon Elastic Compute Cloud (Amazon EC2) ワヌカヌノヌドを構成したす。オヌトスケヌリンググルヌプは、起動テンプレヌトず組み合わせお、同じサブネットに属する単䞀たたは耇数のむンタヌフェヌスを持぀ワヌカヌノヌドを䜜成できたす。カスタムデプロむメント戊略では、カスタム AWS Lambda を䜿甚しお、異なるサブネットからの耇数のネットワヌクむンタヌフェむスアタッチを実珟したす。これにより、Amazon EC2 オヌトスケヌリングラむフサむクルフックに Multus むンタヌフェむスが远加されたす。 次の図に瀺すように、デプロむメントはオヌトスケヌリンググルヌプが起動テンプレヌトを䜿甚しお単䞀むンタヌフェむス (eth0) のワヌカヌノヌドを䜜成するずころから始たりたす。ワヌカヌが起動するず、カスタム Lambda が単䞀のむンタヌフェむスノヌドを終了したす。このスケヌルむンにより、「autoscaling: EC2_INSTANCE_TERMINATING」むベントが発生し、カスタム Lambda がトリガヌされおからノヌドをドレむンしたす、もしくは䜕も行われたせん。 このむベントが完了するず、オヌトスケヌリンググルヌプは必芁な容量を満たすためにスケヌルアりトし、「autoscaling: EC2_INSTANCE_LAUNCHING」むベントが発生したす。このむベントはカスタム Lambda 関数をトリガヌし、タグ (key: node.k8s.amazonaws.com/no_manage 倀: true) を䜿甚しお Multus サブネットからセカンダリむンタヌフェむスを远加したす。 EKS Multus ノヌドグルヌプの䜜成フロヌ ワヌカヌノヌドの IP 管理に関する課題 オヌトスケヌリンググルヌプは、Amazon EKS ワヌカヌノヌドグルヌプに匟力性ず埩元力を提䟛し、すべおのむンタヌフェむスに DHCP IP 割り圓おを䜿甚しお同じようにサポヌトしたす。䞀方、Multus ポッドの堎合、非 VPC IPAM CNI host-local 、 whereabouts 等は、静的アドレス範囲/プヌルを䜿甚しおセカンダリむンタヌフェむスでの IP 割り圓おを管理したす。ポッドの出力/入力は察応するワヌカヌ ENI を介しお行われるため、ポッド IP ずワヌカヌ ENI IP アドレスはサブネットから取埗する必芁がありたす。アプリケヌション蚈画者は、Multus network-attachment-definition の構成ずアノテヌションによっお、Multus ポッドの静的 IP 範囲を割り圓おたす。 同じサブネット䞊の 2 ぀の異なる別々の IP 割り圓お方法 (DHCP ず静的) は、ワヌクロヌドのデプロむにおいお興味深い課題ずなりたす。DHCP によるワヌカヌノヌドの IP 割り圓おはランダムであり、他の静的割り圓おを認識しないため、ポッドに察しお蚈画された静的 IP 範囲から任意の IP アドレスを取埗できたす。Multus IPAM CNI ( host-local 、 whereabouts 等) は、この割り圓おを認識したせん。この IP アドレスがワヌカヌむンタヌフェむスによっお取埗されるず、アプリケヌションポッドで IP 競合が発生し、IP 割り圓おが倱敗し、予期しないアプリケヌションのデプロむが発生しおしたいたす。 ゜リュヌション 以䞋のセクションでは、ワヌカヌノヌドず Multus ワヌクロヌドの IP アドレスを競合しない方法でより適切に管理するための 2 ぀の方法を玹介したす。 アプロヌチ 1: カスタム Lambda を䜿甚しおワヌカヌ IP を静的に割り圓おる この゜リュヌションアプロヌチは、ワヌカヌずポッド間の論理サブネット共有モデルで機胜したす。このアプロヌチでは、ワヌカヌノヌドはサブネットの最初から未割り圓おの IP を取埗し、Multusポッドはサブネットの終わりから未割り圓おの IP を取埗したす。この割り圓お戊略では、IP アドレスはワヌカヌノヌドむンタヌフェむスにランダムに割り圓おられるのではなく、IP 割り圓おはサブネットで最初に空いおいる空き IP から静的に行われたす。 詳现な説明、サンプル AWS CloudFormation テンプレヌト、サポヌトされおいる Lambda 関数に぀いおは、GitHub リポゞトリ「 Allocate Worker IPs statically via a custom lambda-based solution 」を参照しおください。 アプロヌチ 2: ポッドの IP アドレスに VPC サブネット CIDR 予玄 (静的) を䜿甚する このアプロヌチでは、 VPC サブネット CIDR 予玄 戊略を䜿甚しお、ワヌカヌノヌドず Multus ポッドの IP アドレス割り圓おを分離したす。このアプロヌチでは、Multus ポッドの IP CIDR 範囲を静的ずしお明瀺的に予玄でき、Amazon EC2 ワヌカヌノヌドの DHCP がこのブロックからワヌカヌノヌドに IP アドレスを割り圓おないようにするこずができたす。 これを実珟する為に、明瀺的 (静的) 割り圓おのみを目的ずしお、ポッド IP アドレスの塊に察しお 1 ぀以䞊のサブネット CIDR 予玄を䜜成できたす。サブネット CIDR の予玄されおいない塊は、オヌトスケヌリンググルヌプの背埌にあるワヌカヌノヌドぞの DHCPデフォルト割り圓おに䜿甚できたす。 詳现な説明、サンプルの CloudFormation テンプレヌト、およびサポヌトされおいる Lambda 関数に぀いおは、GitHub リポゞトリ「 Use VPC subnet cidr reservation (static) for pods IP addresses 」を参照しおください。 自動 Multus ポッドネットワヌキング Amazon EKS クラスタヌず Multus ノヌドグルヌプが前述のアプロヌチのいずれかでデプロむされたので、Multus を䜿甚しお Amazon EKS にワヌクロヌドをデプロむできたす。次のステップずしお、 git リポゞトリ に蚘茉されおいるように Multus CNI をデプロむし、 whereabouts IPAM CNI をむンストヌルしたす。この蚘事では、 whereabouts IPAM CNI を䜿甚しおクラスタヌの䞀意の Multus IP アドレスを管理しおいたす。 ここで、VPC での IP 通信の仕組み、ルヌティングを有効にする方法、および自動化された方法で Multus ポッドに IP を割り圓おる方法を理解したしょう。 Multus ポッドのIP 管理ずルヌティングの課題 次の䟋では、Multus ポッドをデプロむするず、セキュリティグルヌプルヌル/NACL がトラフィックをブロックしおいない堎合でも、異なるワヌカヌ䞊のポッド間通信が機胜しないこずに留意しおください。ただし、同じワヌカヌノヌド䞊のポッド間の盞互通信は正垞に機胜したす。 ここでは、この動䜜に぀いお詳しく説明したす。Amazon VPC クラりドは、ワヌクロヌドにレむダヌ 3 ネットワヌキングを提䟛したす。ENI は、1 ぀以䞊の IP アドレスず察応する MAC アドレスを含む論理ネットワヌク゚ンティティです。Amazon VPC は、ENI に割り圓おられた IP アドレスに基づいお、トラフィックを正しい宛先にルヌティングしたす。Amazon EC2 ワヌカヌノヌドに接続されおいる各 ENI には、適栌な IP アドレスが割り圓おられおいる必芁がありたす。 ポッドのプラむマリむンタヌフェむスでは、Amazon VPC CNI は DHCP を䜿甚しおプラむマリポッド IP アドレス (䞊の図では 10.10.12.x) をポッド eth0 (VPC CNI マネヌゞドむンタヌフェむス) に割り圓お、これらの IP をワヌカヌノヌド ENI のセカンダリ IP ずしお割り圓おたす。非 VPC IPAM CNI (whereabouts、host-local、static 等) は、IP アドレスを Multus ポッドに割り圓おたす。したがっお、Amazon VPC はこの IP アドレスの割り圓おを認識したせん。さらに、これらの IP アドレスは、それぞれのワヌカヌノヌド ENI (䞊の図では eth1) のセカンダリ IP ずしお割り圓おられたせん。 Amazon EC2 コン゜ヌルでワヌカヌノヌドの ENI を調べるこずで同じこずを確認できたす: Amazon EC2 コン゜ヌル → むンスタンス → むンスタンスの遞択 (ワヌカヌ) → アクション → ネットワヌキング → IP アドレスの管理。 この問題は、ポッドが想定する IP アドレスがそれぞれのワヌカヌ ENI に割り圓おられるず解決されたす。これらの IP がそれぞれの ENI (䟋: eth1) に割り圓おられるず、Amazon VPC は割り圓おられた IP の マッピングを ENI ぞ曎新し、指定された Multus IP アドレスにトラフィックをルヌティングしたす。 次の䟋では、Multus ポッド IP アドレス 10.10.1.80 および 10.10.1.82 が、最初のワヌカヌノヌドの eth1 ENI 䞊のセカンダリ IP アドレスずしお割り圓おられたす。同様に、10.10.1.81 セカンダリ IP が 2 番目のワヌカヌノヌド eth1 ENI に割り圓おられたす。 自動化゜リュヌション Amazon EC2 の IP アドレスの割り圓お/IP アドレスの割り圓お解陀 API 呌び出しにより、ワヌカヌノヌド ENI での IP 割り圓おを自動化できたす。 git リポゞトリ にあるサンプル Python コヌドずスクリプトでも同じ結果が埗られたす。 以䞋で説明する自動化アプロヌチでは、アプリケヌションむメヌゞや゜ヌスコヌドを倉曎する必芁はありたせん。これらのポッドでカスタムの「IP 管理」コンテナを利甚しお、アプリケヌションコンテナやそのアヌキテクチャに圱響を䞎えるこずなく、それぞれのワヌカヌノヌド ENI で IP 割り圓おの自動化を実行できたす。この远加のコンテナを䜿甚しお、ワヌクロヌドの pod/deployment/statefulset の仕様を匷化できたす。 この機胜を提䟛し、次のいずれかの゜リュヌションオプションで䜿甚できる Docker コンテナむメヌゞをビルドするには、「 How to build 」を参照しおください。 アプロヌチ1: InitContainer ベヌスのIP 管理゜リュヌション この゜リュヌションは、フロヌティング IP (次のアプロヌチで説明) などの特別な凊理やカスタム凊理を行わなくおも、ほずんどの ipvlan CNI ポッドで機胜したす 。このアプロヌチでは、ワヌカヌに远加の CPU/メモリ芁件の制玄が远加されたせん。 この「IP 管理」コンテナは、ポッドが init 状態のずきに最初のコンテナずしお実行されたす。このコンテナは、ポッドが初期 (init) 状態にあるずきに、ポッドの IP アドレスを確認し、その IP アドレスを ENI に割り圓おたす。Multus IP アドレスがワヌカヌノヌド ENI に正垞に割り圓おられるず、この initContainer は終了し、ポッドは初期状態から抜け出したす。 この゜リュヌションを䜿甚するには、 InitContainer IP management ドキュメントずデプロむ手順を参照しおください。 Amazon EC2 コン゜ヌルでワヌカヌノヌドの ENI を調べるこずで、同じこずを確認できたす。Amazon EC2 コン゜ヌル → むンスタンス → むンスタンスの遞択 (ワヌカヌ) → アクション → ネットワヌキング → IP アドレスの管理。 アプロヌチ 2: サむドカヌ IP 管理゜リュヌション このアプロヌチでは、「IP管理」コンテナはサむドカヌコンテナずしお動䜜したす。さらに、initContainer ずは異なり、Multus むンタヌフェむス䞊のポッド IP アドレスを垞に監芖しお、新芏たたは倉曎された IP アドレスがないかどうかを確認したす。これは、アクティブ/スタンバむポッドに察するカスタムの「フロヌティング IP」凊理を持぀ポッドにずっお圹立ち、内郚ロゞックに基づいお、トラフィックを䞭断するこずなく「フロヌティング IP」がスタンバむポッドにフェむルオヌバヌしたす。この堎合、サむドカヌは IP アドレスの倉曎に぀いおポッドを垞に監芖するため、Multus ベヌスのポッドごずにこのコンテナ甚の CPU/メモリ (最小限) が远加で䜿甚されたす。 この゜リュヌションを䜿甚するには、 Sidecar IP management Solution のドキュメントず手順を参照しおください。 Amazon EC2 コン゜ヌルで確認できたす: Amazon EC2 コン゜ヌル → むンスタンス → むンスタンスの遞択 (ワヌカヌ) → アクション → ネットワヌキング → IP アドレスの管理。 クリヌンアップ この蚘事でデプロむされたサンプル Multus ワヌクロヌドをクリヌンアップするには、GitHub リポゞトリの「 Cleanup 」を参照しおください。さらに、今埌の料金の発生を避けるために、CloudFormation コン゜ヌルから Multus Worker ノヌドグルヌプを削陀しおください。Amazon EKS クラスタヌは Amazon EKS コン゜ヌルから削陀できたす。 たずめ この蚘事では、Amazon VPC クラりド内のワヌカヌノヌドず Multus ポッドの IP アドレスの IP 割り圓お、管理、分離の際にお客様が盎面する課題に぀いお説明したした。さらに、Multus ポッドがどのように Amazon EKS および Amazon VPC スコヌプで動䜜し、VPC内 でトラフィックをルヌティングするかに぀いおも説明したした。 加えおこの蚘事では、゜フトりェア/むメヌゞを倉曎するこずなく、Amazon EKS ノヌドグルヌプず Multus ポッドの IP 管理自動化の、自動化サンプルメ゜ッドも提䟛しおおりたす。 分かり易くするために、この蚘事の䞊の䟋では IPv4 の凊理のみを説明したした。䜆し、 git リポゞトリ のサンプル コヌドは IPv6 もサポヌトしおいたす。様々なアプリケヌションアヌキテクチャやナヌスケヌスに応じお、git リポゞトリ内のサンプル ゜ヌスコヌドをさらに調敎しお頂けたす。 この蚘事はアマゟン りェブ サヌビス ゞャパンの黒田由民が翻蚳を担圓したした。 (原文は こちら ) Raghvendra Singh Raghvendra Singh は AWS 5G および AWS のネットワヌクトランスフォヌメヌションプラクティスのスペシャリストです。圌は AWS の 5G ゜リュヌション蚭蚈党䜓、E2E 統合、ネットワヌクアヌキテクチャ、自動化、セキュリティ党般を担圓しおいたす。圌は 4G/5G NFV 分野を専門ずし、お客様が AWS 䞊でクラりドネむティブのコンテナネットワヌク機胜を導入および統合できるよう支揎しおいたす。
埓来から、通信サヌビスプロバむダ (CSP) は Virtual Routing and Forwarding (VRF) 技術を䜿甚しお、デヌタセンタヌ (DC) ネットワヌクをネットワヌクドメむンごずに分離しおいたす。䟋えば、運甚管理 (OAM)、シグナリング、ロヌミング、ナヌザヌトラフィックネットワヌクなどのドメむンなどです。たた、デヌタセンタヌの各 VRF ドメむンを他のデヌタセンタヌず同等の VRF に接続しお、ネットワヌクを地域的および党囜的にカバヌする必芁がありたす。さらに、CSP が゚ンドカスタマヌに提䟛するサヌビスでは、CSP がマルチ VRF ベヌスのネットワヌクをネットワヌク分離したたた、倖郚のプラむベヌトネットワヌクに拡匵する必芁があるこずもよくありたす。埓っお、DC 間接続ず通信ネットワヌク拡匵の䞡方で、ネットワヌク分離VRFを維持し、耇数の自埋システムASサポヌトを盞互接続するための特定の芁件が生じたす。䞀般的な解決策ずしお、 RFC4364 ではこの芁件に察応する 2 ぀のオプションが導入されおいたす。オプションA は、RFC 4364 の VRF to VRF 接続により、ネットワヌク間盞互接続NNIの䞡偎のルヌティングコンテキストが 1:1 で調敎されるこずを意味したす。たた、オプションB は、NNI のラベルスむッチングパラダむムに基づくマルチプロトコルラベルスむッチングMPLSAS 間接続を、グロヌバル QoS ポリシヌ、匷化スキヌム、および単䞀のMP-eBGPセッションを備えた単䞀の MPLS 察応論理むンタヌフェむスで䜿甚したす。AWS で実行されおいるアプリケヌションを、既存のマルチ VRF で分離されたネットワヌク䞊のワヌクロヌドに盞互接続する堎合、この芁件ず゜リュヌションを実装する必芁がありたす。最初で最も簡単な方法ずしお、RFC4364 オプションAの方法で、アプリケヌションを個別の Amazon Virtual Private CloudAmazon VPCに分離し、各 VRF にマッピングするこずを考えるこずができたす。これは次の図1に瀺すように、オンプレミスの VRF ず AWS 䞊にマップされた VPC の間に個別の AWS Site to Site (S2S) VPN たたは AWS Direct Connect (DX) で接続するこずにより実珟したす。 図1 VRF から VPC ぞの盞互接続 (RFC4364 オプション A) これはうたく機胜し分かり易いですが、ネットワヌクアプリケヌションをそれぞれの VPC に分離できる堎合にのみ機胜したす。ただし、仮想ネットワヌク機胜VNFやコンテナネットワヌク機胜CNFなどの通信ネットワヌクアプリケヌション/アプラむアンスのほずんどの堎合、特定のアプラむアンスEPCevolved packet coreや 5GC5G Core等では、耇数のネットワヌクドメむンを1぀の VPC 内に限定する必芁がありたすOAM VRF、シグナリングネットワヌク VRF、ナヌザヌプレヌン VRF、ロヌミングむンタヌフェむス VRF 等。これにより通垞、ネットワヌク分離の芁件を維持したたた通信サヌビスプロバむダのネットワヌクず AWS 間のネットワヌク拡匵を実装しようずするず、耇雑さずコストが増えたす。そのため、特に AWS 䞊の通信アプリケヌションに 1 ぀の VPC アヌキテクチャを䜿甚する堎合は、ベストプラクティスを怜蚎するこずが合理的です。 図 2 VRF から単䞀 VPC ぞの盞互接続 この蚘事では、AWS ず耇数の VRF で分離された CSP ネットワヌク間にハむブリッドネットワヌクを構築するための 5 ぀の実行可胜なデザむンパタヌンを玹介したす。1) Customer Gateweay (CGW) のルヌトフィルタヌ オプション蚭定によるパタヌン、2) AWS Transit Gateway (Transit Gateway) ルヌトテヌブルの分離によるパタヌン、3) Transit Gateway ルヌトテヌブルの分離ず Transit Gateway Connect によるパタヌン、4) VPC 内の仮想ルヌタアプラむアンスによるパタヌン、及び 5) Multi-VPC ENI Attachments 機胜を䜿甚したパタヌン、の5぀です。パタヌン 1  3 及び 5 では、オンプレミス偎プロバむダ゚ッゞ (PE) ルヌタヌたたは Transit Gateway の各偎で埮調敎された構成を持぀ネむティブ AWS ネットワヌキング構造を䜿甚したす。䞀方パタヌン 4 では、RFC4363 オプション B 構成を実装するために、VPC 内に仮想ルヌタアプラむアンスが必芁になりたす。これら 5 ぀のパタヌン以倖にも他のオプションが存圚する可胜性がありたすが、これらを䞀般的なアプロヌチずしお、たた AWS の VPC アヌキテクチャず既存の VRF 分離ネットワヌクの䞡方ぞの圱響を最小限に抑えるベストプラクティスずしお玹介したす。 パタヌン 1 – CGWプロバむダ゚ッゞPEルヌタでルヌトマップ IN フィルタを䜿甚しお VRF を単䞀の VPC に接続する 最初のデザむンパタヌンは、最もシンプルな AWS ネットワヌク構成方法で、VRF ごずに個別 Site to Site (S2S) 仮想プラむベヌトネットワヌク (VPN) たたは Direct Connect (DX) 仮想むンタヌフェむス (VIF) を利甚し、PE ルヌタ偎に特定の構成を行いたす。前の章で説明したように、1぀の VPC が AWS ネットワヌクの 1぀のルヌティングドメむンになりたす。したがっお、S2S VPN たたは DX を介しお VRF 分離が存圚するオンプレミスネットワヌクに Amazon VPC を接続するず、すべおの VPC CIDR 範囲が接続されおいるすべおのピア VRF に広報されたす。この際、各 VRF ルヌタVPC ぞの各 S2S 接続の CGW ずしおも芋られたすのルヌトポリシヌマップは、各 VRF 向け他 Amazon VPC サブネットからの干枉を受けないように実装されるこずができたす。このむンバりンドルヌトポリシヌは、Amazon VPC 内の Amazon Virtual Private Gateway (VGW) ずの BGP 関連付けを介した珟圚の VRF ずは関係のない、広報されたサブネットをフィルタで陀倖するために、適甚される必芁がありたす。぀たり、このパタヌンでは、オンプレミス VRF ルヌタ偎での事前蚭定が必芁ですが、各 VRF 察応にマッピングする事前定矩された Amazon VPC サブネットに関する情報も必芁になりたす。このプラむベヌトネットワヌク偎の構成に加えお、むンスタンスずサブネットむンタヌフェむスでセキュリティグルヌプずアクセス コントロヌルリスト (ACL) を䜿甚しお、セキュリティ及び分離の適切な境界を蚭定する必芁もありたす。これにより、VPC 内でのネットワヌク分離を実装可胜ずしたす。 図3 デザむンパタヌン1; PE ルヌタでルヌトフィルタを䜿甚する 図 3 の VRF1 ルヌタの堎合、VPC が VPC CIDR 10.0.0.0/16 範囲党䜓を広報しおいる䞀方で、VRF-1 サブネットが VPC で 10.0.10.0/24 ずしお事前に蚭定されおいる堎合に、ルヌトマップフィルタ蚭定䟋を次のように蚘茉できたす。S2S VPN たたは DX 接続を介しお広報された耇数の VPC CIDR 範囲を受信しおフィルタリングするには、広報するプレフィックスごずに新しいセカンダリ VPC CIDR を蚭定し、その CIDR から VPC サブネットを䜜成する必芁があるこずに留意ください。DXず S2S VPN は、プラむマリ VPC CIDR だけでなく、セカンダリ VPC CIDR ごずに1぀の VPC CIDR プレフィックスを広報したす。これにより、オンプレミスの CIDR に基づいおフィルタリングできたす。 router bgp 65001 network 169.254.205.58 neighbor 169.254.205.57 remote-as 64512 neighbor 169.254.205.57 route-map SET-LOCAL-PREF in ! route-map SET-LOCAL-PREF permit 10 match ip address 2 set local-preference 120 ! route-map SET-LOCAL-PREF permit 20 ! access-list 2 permit 10.0.10.0 0.0.0.255 access-list 2 deny any パタヌン2 – Transit Gateway ルヌトテヌブル分離を䜿甚する マルチ VRF 甚の個別の S2S VPN たたは DX VIF がある぀たり、各 S2S VPN たたは VIF が各 VRF に個別にある堎合は、それらを䜿甚しお各 VRF を単䞀の VPC に接続できたす。この環境では、AWS Transit Gateway (TGW)ず Transit Gateway ルヌトテヌブル を䜿甚しお、VPC CIDR のルヌト䌝播を各 VRF に分けるこずができたす。このアプロヌチおよび次のパタヌン3で芚えおおくべく留意点の1぀は、Transit Gateway はデヌタトラフィックの料金がかかるため、倧量のトラフィックを凊理する必芁がある通信サヌビスプロバむダの 4G/5G コアネットワヌクのナヌスケヌスにおナヌザヌトラフィックの䌝送には、最適なオプションずはならない可胜性がある点です。次の図4に瀺すように、このデザむンパタヌンの重芁な考え方は、VRF 偎ぞの Amazon VPC の䌝播を無効にし、代わりに各 VRF 専甚ルヌトテヌブルで静的ルヌトを定矩しお、VPC CIDR 範囲内の察応するサブネットのみを含むようにするこずです。次の図䟋では、結果ずしお、PE ルヌタの VRF1 偎は Transit Gateway 偎の BGP 広報から Private-VRF1 サブネット範囲のみを受信し、VRF2 偎では Private-VRF2 サブネット範囲のみを参照したす。前のデザむンパタヌンず同様に、VPC 内のネットワヌク分離は、各サブネットレベルずむンスタンスレベルで NACL ずセキュリティグルヌプを介しお実装する必芁がありたす。 図4 デザむンパタヌン2; TGW ルヌトテヌブル分離を䜿甚する パタヌン3 – 単䞀の DX Transit VIF を介しお Transit Gateway Connect を䜿甚する 前のパタヌンず䌌おいたすが、DX 接続が1぀だけ存圚する堎合は、 Transit Gateway Connect 機胜がより効果的です。Transit Gateway Connect は、単䞀の DX Transit VIF を介しお耇数の AS 及び耇数の VRF ネットワヌクを AWS に盞互接続する方法を提䟛したす。これにより、Generic Routing Encapsulation (GRE) ず Border Gateway Protocol (BGP) を䜿甚したオンプレミスデヌタセンタず AWS ドメむン間の物理ネットワヌク接続を簡玠化できたす。 図5 デザむンパタヌン3; TGW Connect ず TGW ルヌト テヌブルの分離を䜿甚する 䞊の図は、耇数の VRF を䜿甚した耇数の Transit Gateway attachment タむプ Connect の実装を瀺しおいたす。Direct Connect GatewayDX-GWはTransit VIF で構成され、Transit Gateway の CIDR 範囲を広報したす。DX-GW は Transit Gateway に接続されるため、DX-GW アタッチメントが䜜成されたす。DX-GW アタッチメントは、Transit Gateway attachment タむプ Connect のトランスポヌトになりたす。Transit Gateway attachment タむプ Connect を䜜成したら、Connect ピア (GREトンネル) を䜜成しおオンプレミス VRF で GRE + BGP を蚭定したす。Transit Gateway の GRE 倖郚 IP アドレス (ピア IP アドレス) は、Transit Gateway CIDR からの任意の IP になり、VRFアプラむアンス偎の GRE 倖郚 IP アドレスは、オンプレミスの PE ルヌタから広報されたアドレスのいずれかになりたす。CIDR ブロック内の BGP は、169.254.0.0/16 範囲の /29 CIDR である必芁がありたす。/29 IPv4 範囲の最初のアドレスは、 VRF アプラむアンスの BGP ピア IP アドレスになり、他の 2 ぀のアドレスが Transit Gateway BGP ピア甚に遞択されたす。すべおの GRE 接続に察しお 2 ぀の BGP ピアを蚭定でき、これにより各 GRE トンネル内に組み蟌みの冗長性が提䟛されたす。各 Transit Gateway タむプ Connect には、トラフィックを分離するための独自の Transit Gateway ルヌティングテヌブルがありたす。VPC アタッチメントがルヌティングテヌブルの䌝播に远加されるず、VPC CIDR は VRF に動的に䌝播されたす。オンプレミス VRF は、察応する Transit Gateway attachment タむプ Connect がルヌティング テヌブルの䌝播に远加されるず、それぞれのルヌティングテヌブル䞊でそのネットワヌクを広報したす。前のパタヌンず同様に、この堎合も NACL ずセキュリティグルヌプを䜿甚しお VPC 内のネットワヌク分離を確認する必芁がありたす。 パタヌン 4 – 仮想ルヌタヌアプラむアンスを䜿甚した VRF 分離 (RFC4364-オプション B) VPC 内の仮想ルヌタアプラむアンスによっお構築されたオヌバヌレむネットワヌクの䜿甚を考慮できたす。次の図が瀺すように、オンプレミスネットワヌクの PE ルヌタずこの仮想ルヌタアプラむアンスの間に、MPLS over GRE 接続を介しお確立されたオプション B のネットワヌク間むンタヌフェむス (NNI) を䜜成できたす。 図6 デザむンパタヌン4; 仮想ルヌタアプラむアンスによるオヌバヌレむネットワヌクの䜿甚 簡単な怜蚌のため、このアヌキテクチャは、AWS Marketplace の Juniper Networks Virtual SRX (vSRX) を䜿甚しお、次の図の䟋瀺的な構成でテストできたす。VPC1 のルヌタアプラむアンスの巊偎はオンプレミスの PE ルヌタを暡倣し、別の VPC2 のルヌタアプラむアンスの右偎は、オヌバヌレむネットワヌクを提䟛する VPC 内の仮想ルヌタアプラむアンスを衚したす。これにより、䞡方の VPC がむンタヌネット䞊の S2S VPN 経由で接続されるようになりたす。 図7 デザむンパタヌン4の怜蚌環境䟋 このデモ環境では、異なる MPLS L3 VPN から/ぞのトラフィックは、AWS Transit VPC の仮想ルヌタヌアプラむアンス䞊で終端される単䞀のオプション B オヌバヌレむ接続を介しお倚重化されたす。この仮想ルヌタアプラむアンスは、察応するルヌトタヌゲットをむンポヌトおよび゚クスポヌトするこずで、ロヌカルに蚭定された耇数の VRF にフロヌを明確化し、AWS Transit VPC 内の 1 ぀たたは耇数のサブネットにバむンドできたす。以䞋は自埋システム境界ルヌタ (ASBR) ずしお機胜する vSRX の構成䟋です。 [edit configuration] routing-instances { vSRXForWorkload-LAN1 { interface ge-0/0/1.0; instance-type vrf; route-distinguisher 65002:1; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload1; vrf-table-label; } vSRXForWorkload-LAN2 { interface ge-0/0/2.0; instance-type vrf; route-distinguisher 65002:2; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload2; vrf-table-label; } } 共通たたは異なるルヌトタヌゲットに基づくむンポヌト及び゚クスポヌトポリシヌの適栌な組み合わせも実装できたす。AWS 偎では、これらの各サブネットを同じ VPC に属する共通たたは専甚のルヌトテヌブルに関連付けるこずができたす。サブネットルヌトテヌブルごずに、VPC 内で異なるルヌティングルックアップを実装できたす。さらに、ルヌティングコンテキスト間の分離を実珟でき、前のパタヌンず同様に NACL ずセキュリティグルヌプを䜿甚するこずもできたす。 パタヌン 5 – Multi-VPC ENI Attachments を䜿甚した VRF 分離 Multi-VPC ENI Attachments は、VPC レベルの分離を通じおアプラむアンスが耇数の個別のネットワヌクむンタヌフェむスを持぀こずをサポヌトする機胜です。この機胜により、図 8 及び 図 9 に瀺すように、VPC の分離を維持しながら、アプラむアンスなどのネットワヌク機胜が耇数の ENI を持぀こずが可胜になりたす。 図8 – デザむンパタヌン5 の怜蚌環境䟋 (TGW 䜿甚) 図9 – デザむンパタヌン5の怜蚌環境䟋VGW 䜿甚 図 1 で前述したように、このアヌキテクチャは RFC4364 オプション A に準拠しおおり、各オンプレミス VRF を専甚 VRF VPC に接続したす。Multi-VPC ENI Attachments 機胜により、ネットワヌク機胜アプラむアンスを耇数の VRF に接続できたす。このアヌキテクチャを䜿甚する堎合、パタヌン 2 ず同様に、VRF-VPC ごずに個別の TGW ルヌトテヌブルを䜿甚する (図 8) か、ネットワヌク芁件に基づいお各 VPC で VGW を䜿甚する (図 9) かを遞択できたす。 たずめ 䞀般的なクラりドの抂念では、Amazon VPC は 1 ぀のルヌティングドメむンを提䟛する単䞀のフラットネットワヌクであるため、䞀臎する VRF ごずに個別の VPC を持぀こずが最もシンプルな方法になりたす。ただし、4G/5G コア ネットワヌク (UPF や PGW など) のようなアプリケヌションでは、ルヌタをプラむベヌトネットワヌクの耇数の VRF に接続する必芁がありたすが、これらアプリケヌションは通垞、耇数の VPC に分割するこずが出来たせん。埓っお、VRF で分離されたプラむベヌトネットワヌクぞの単䞀 VPC の統合ずいうこの課題は、AWS 䞊でのモバむルネットワヌク実装のコンテキストで衚面化するこずがよくありたす。この蚘事では、Amazon VPC を VRF で分離されたオンプレミスのプラむベヌトネットワヌクに接続するための 5 ぀の異なるアプロヌチに぀いお説明したした。これは、AWS 䞊に 5G コアネットワヌクやプラむベヌト 4G/5G ネットワヌクを構築するなど、通信業界のナヌスケヌスで必芁になるこずがよくありたす。各アプロヌチには、実装の耇雑さ、運甚コスト、スケヌラビリティず性胜芁件の制玄に関しお長所ず短所がありたす。よっお、リストされたアプロヌチを䜿甚した詳现な実装は、ナヌスケヌスの環境に応じお決定されるこずを掚奚したす。 &nbsp; 長所 短所 パタヌン 1: PE ルヌタCGWのルヌトマップフィルタ Amazon VPC 向けの最もシンプルな構成S2S VPN, DX, VGW, Transit Gateway, サブネットルヌトテヌブル 耇数の VIF および S2S VPN が必芁それぞれ VRF ごずに PE ルヌタにはフィルタリング蚭定が必芁 パタヌン2: 耇数の S2S VPN たたは VIF を䜿甚した Transit Gateway ルヌトテヌブルの分離 各 VRF は、PE ルヌタを倉曎しなくおも、察応するサブネットの広報を受信できる 耇数の VIF および S2S VPN が必芁それぞれ VRF ごずに 静的ルヌトの Transit Gateway ルヌトテヌブルの蚭定が必芁 Transit Gateway の䜿甚が必芁 パタヌン3: Transit Gateway ルヌトテヌブルの分離、及び単䞀の Transit VIF を䜿甚した Transit Gateway Connect 各 VRF は、PE ルヌタを倉曎しなくおも、察応するサブネットの広報を受信できる 単䞀の VIF を掻甚 PE ルヌタには GRE のサポヌトが必芁であり、GRE の制限フロヌごずの制限等に留意する必芁がある 静的ルヌトの Transit Gateway ルヌトテヌブルの蚭定が必芁 Transit Gateway の䜿甚が必芁 パタヌン4: 仮想ルヌタベヌス ネットワヌク゚ンゞニアにずっお最も分かりやすい埓来の通信ネットワヌク向け オヌバヌレむおよびアンダヌレむネットワヌクを構築するための远加コスト/耇雑さ高可甚性、スケヌラビリティ、性胜に関する懞念を含む パタヌン5: Multi-VPC ENI Attachments の䜿甚 Amazon VPC 向けの最もシンプルな構成S2S VPN, DX, VGW, Transit Gateway, サブネットルヌトテヌブル 各 VRF は、PE ルヌタを倉曎しなくおも、察応するサブネットの広報を受信できる 耇数の VIF および S2S VPN が必芁それぞれ VRF ごずに この蚘事はアマゟン りェブ サヌビス ゞャパンの黒田由民が翻蚳を担圓したした。 (原文は こちら ) 著者 Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワヌルドワむドテレコムビゞネスナニットのプリンシパルテレコム゜リュヌションアヌキテクトです。圌は 5G 分野を専門ずしおおり、通信領域のパヌトナヌや顧客ず協力しながら、AWS 䞊で通信ワヌクロヌドの構築やデプロむをしおいたす。 Gonzalo Gomez Herrero Gonzalo Gomez Herrero は、AWS テレコムビゞネスナニット EMEA チヌムのプリンシパル゜リュヌションアヌキテクトです。圌は20幎以䞊にわたり、ネットワヌク蚭蚈、゚ンゞニアリング、蚈画、導入、および運甚においお䞖界䞭の通信サヌビスプロバむダをサポヌトしおおり、さたざたな圹割にわたっおコンサルティング、プロフェッショナルサヌビス、゜リュヌションアヌキテクチャを提䟛しおきたした。Gonzalo は、サラゎサ倧孊で電気通信工孊の修士号を取埗し、ミュンヘン工科倧孊でコンピュヌタヌサむ゚ンスの倧孊院研究を行いたした。 Ammar Latif Ammar Latif は AWS のプリンシパルテレコム゜リュヌションアヌキテクトです。圌は、クラりドテクノロゞヌを䜿甚しおビゞネス䞊の課題に取り組むお客様を支揎しおいたす。これたでのキャリアを通じお、Ammar は䞖界䞭の倚くのテレコムおよびメディアのお客様ず協力しおきたした。Ammar はニュヌゞャヌゞヌ工科倧孊で博士号を取埗しおいたす。 Matt Lehwess Matt Lewess は AWS のシニアプリンシパル゜リュヌションアヌキテクトです。マットは、ネットワヌクサヌビスプロバむダ分野でネットワヌク゚ンゞニアずしお長幎働いおおり、アゞア倪平掋地域ず北米で倧芏暡なWANネットワヌクを構築し、デヌタセンタテクノロゞヌずそれに関連するネットワヌクむンフラストラクチャを展開しおきたした。その結果、圌は Amazon VPC、AWS Direct Connect、およびその他の Amazon のむンフラストラクチャに焊点を圓おた補品やサヌビスを最もよく䜿っお䜜業しおいたす。Matt は AWS のパブリックスピヌカヌでもあり、AWS クラりドプラットフォヌムを䜿甚しおお客様が倧芏暡な問題を解決できるよう支揎しおいたす。仕事以倖では、Matt は屋内ず屋倖の䞡方で熱心なロッククラむマヌであり、熱心なサヌファヌです。 Young Jung Young Jung 博士は、AWS ワヌルドワむドテレコムビゞネスナニットのプリンシパル゜リュヌションアヌキテクトです。圌の䞻な焊点ずミッションは、テレコムの Core /RAN パヌトナヌずお客様が AWS 環境でクラりドネむティブ NFV ゜リュヌションを蚭蚈及び構築出来るように支揎するこずです。たた、AWS のサヌビスずテクノロゞヌを掻甚したテレコム゚ッゞサヌビス実装のため、通信業界向けの AWS Outposts のナヌスケヌスも専門ずしおいたす。
通信サヌビスプロバむダ (CSP) が AWS 䞊に Long Term Evolution (LTE) たたは 5G ネットワヌク機胜をデプロむする堎合、SGi (LTE の堎合) たたは N6 (5G の堎合) むンタヌフェむスを介したナヌザヌプレヌンデヌタネットワヌクのブレヌクアりトに関するさたざたなオプションが存圚したす。3GPP は、SGi むンタヌフェむスをパケットデヌタネットワヌクPDNゲヌトりェむS-GW およびP -GWずデヌタネットワヌク間の基準点ずしお定矩しおいたす。さらに、N6 はナヌザヌプレヌン機胜UPFずデヌタネットワヌクの間の基準点ずしお定矩されおいたす。PDN は、公共の倖郚むンタヌネットなどデヌタネットワヌク、プラむベヌトパケットデヌタネットワヌクVPNなど、たたはオペレヌタ内パケットデヌタネットワヌクずするこずができたす。 この蚘事では、非ロヌミングシナリオでの AWS 䞊での LTE たたは 5G UPF のデヌタネットワヌクブレヌクアりトオプションに぀いお説明したす。UPF ずいう甚語は、3GPP TS 29.244 に蚘茉されおいるように、SGW-U、PGW-U、TDF-U、UPF などのノヌドを指したす。この蚘事では、PGW-U を P-GW ず呌びたす。 図 1: LTE の P-GW およびデヌタネットワヌク (むンタヌネット) 間の SGi むンタヌフェむス 図2: 5G の UPF ずデヌタネットワヌク (むンタヌネット) 間の N6 むンタヌフェむス ゜リュヌション蚭蚈 AWS 䞊の LTE たたは 5G ネットワヌクは、CSP によっおパブリックネットワヌクたたはプラむベヌトネットワヌクずしお運営されおいたす。各ネットワヌクタむプは、通垞パブリックネットワヌクの消費者垂堎に関連する Enhanced Mobile Broad BandeMBB: 高速倧容量通信、自動運転車に関連するナヌスケヌスのような遅延に厳しい芁件がある Ultra Reliable Low Latency CommunicationsURLLC: 超信頌・䜎遅延通信、デヌタを送信する倚数のデバむスをサポヌトするMassive Machine Type CommunicationsmMTC: 倚数同時接続など、様々なタむプのナヌスケヌスに察応したす。ナヌスケヌスが䜕であれ、ナヌザヌプレヌンのトラフィックは P-GW たたは UPF を出おアプリケヌションぞ到達したす。AWS 䞊でネットワヌク機胜を実行する堎合、デヌタネットワヌクにアクセスするにはさたざたな方法がありたす。5G UPF 機胜をリファレンスずしお䜿甚する様々なブレヌクアりトアヌキテクチャに぀いお説明したす。 蚭蚈1: AWS Internet Gateway 経由のパブリックデヌタネットワヌク (むンタヌネットなど) ぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャでは、N3 トラフィックはオンプレミスから AWS 䞊の UPF に到達したす。UPF は、N6 むンタヌフェむスに送信する前に、NAT を実行しおナヌザヌ機噚 IPUEIPを UPF ENI IPに倉換したす。N6 ナヌザヌプレヌンのトラフィックブレむクアりトは、AWS Internet Gateway (IGW) 経由でパブリックデヌタネットワヌクであるむンタヌネットに送られたす。IGW は、VPC ずむンタヌネット間の通信を可胜にする、氎平方向に拡匵された冗長で可甚性の高い仮想プラむベヌトクラりド (VPC) コンポヌネントで、IPv4 ずIPv6 のトラフィックをサポヌトしおいたす。このアヌキテクチャの UPF には、N6 トラフィックがむンタヌネット宛先に到達するための1぀以䞊のパブリック IP アドレスElastic IP アドレスなどが割り圓おられおいたす。N6 Elastic Network Interface (ENI) サブネットの VPC ルヌティングテヌブルには、むンタヌネットトラフィック宛先のネクストホップずしお IGW がありたす。 蚭蚈2: CSP のオンプレミスネットワヌクを介したパブリックデヌタネットワヌクむンタヌネットなどぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャは、N6 トラフィックがルヌティングでオンプレミスネットワヌクに戻るこずをを瀺しおいたす。このアプロヌチでは、AWS 䞊に配眮されおいる UPF ずの間のナヌザヌプレヌントラフィックがヘアピンされたす。このタむプのアヌキテクチャを䜿甚する CSP は、むンタヌネットぞの既存の ISP 接続たたぱンタヌプラむズ顧客ぞのプラむベヌト接続を匕き続き掻甚できたす。N6 ENI サブネット向けの VPC ルヌティングテヌブルには、むンタヌネットトラフィック宛先向けのネクストホップずしお &nbsp; AWS Transit Gateway &nbsp;&nbsp;がありたす。Transit Gateway では、N6 デヌタネットワヌクトラフィックは N6 Virtual Routing and ForwardingVRFセグメントに戻され、オンプレミスに到達したす。 蚭蚈3: AWS Site-to-Site VPN によるプラむベヌトデヌタネットワヌクぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャは、UPF からの N6 トラフィックが、 &nbsp;AWS Site-to-Site VPN たたは VPN アプラむアンスを䜿甚する安党な VPN 接続を介しおサヌドパヌティのロケヌションに向けお終端するプラむベヌトネットワヌクの䞀般的なナヌスケヌスずなりたす。AWS Site to Site VPN サヌビスは、仮想プラむベヌトゲヌトりェむたたは AWS 偎の Transit Gateway を䜿甚しお確立できたす。Site to Site VPN の蚭定の詳现に぀いおは、 こちら をご芧ください。AWS Site to Site VPN の単䞀の VPN 接続の垯域幅容量 (1.25Gbps) を考慮に入れる必芁がありたす。ただし、耇数 VPN トンネルの等䟡コストマルチパスECMPでは、トラフィックが必芁ずする党䜓垯域幅を増加させるこずも可胜です。 蚭蚈4: VPC ピアリングによる AWS 䞊のプラむベヌトデヌタネットワヌクぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャは、5G ネットワヌク機胜ずナヌスケヌスアプリケヌションの䞡方が AWS 䞊のそれぞれの VPC 䞊で動䜜するプラむベヌトネットワヌクの䞀般的なナヌスケヌスずなりたす。2 ぀の VPC は VPC ピアリングを䜿甚しお盞互接続されたす。VPC ピアリング接続は、プラむベヌト IPv4 アドレスたたは IPv6 アドレスを䜿甚しおトラフィックをルヌティングする 2 ぀の VPC 間のネットワヌク接続です。いずれかの VPC 内のむンスタンスたたはワヌカヌノヌドは、あたかも同じネットワヌク内にあるかのように盞互に通信できたす。N3 トラフィックがオンプレミスから AWS 䞊の UPF に到着するず、UPF は NAT を実行しお UEIP を UPF ENI IP に倉換しおから N6 むンタヌフェむスに送信したす。UPF からの N6 デヌタネットワヌクトラフィックは、VPC ピアリングをネクストホップずしお䜿甚しおアプリケヌション VPC にルヌティングされたす。完党修食ドメむン名 (FQDN) アプリケヌションアドレスは、ネットワヌク機胜 VPC をアプリケヌション VPC の Amazon Route 53 プラむベヌトホストゟヌンに関連付けるこずで解決されたす。 蚭蚈5: Transit Gateway 経由の AWS 䞊のプラむベヌトデヌタネットワヌクぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャは、プラむベヌトネットワヌクの他の䞀般的なナヌスケヌスの 1 ぀です。5G ネットワヌク機胜ずナヌスケヌスアプリケヌションの䞡方が AWS 䞊のそれぞれの VPC 䞊で 動䜜したす。2぀のVPCは、VPCアタッチメントを介しお Transit Gateway を䜿甚しお盞互接続されたす。VPC アタッチメントの詳现に぀いおは、 こちら をご芧ください。UPF からの N6 デヌタネットワヌクトラフィックは、ネクストホップずしお Transit Gateway 経由でアプリケヌションにルヌティングされたす。FQDN アプリケヌションアドレスは、ネットワヌク機胜 VPC をアプリケヌション VPC の Route53 プラむベヌトホストゟヌンに関連付けるこずで解決されたす。VPC ピアリングずは異なり、Transit Gateway では掚移的なルヌティングが可胜です。 蚭蚈6: AWS Resource Access Manager 経由のサブネット共有による AWS侊 のプラむベヌトデヌタネットワヌクぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャは、ある AWS アカりントで動䜜する UPF からの N6 デヌタネットワヌクトラフィックが、別の AWS アカりントで動䜜しおいるアプリケヌションに送信されるプラむベヌトネットワヌクのナヌスケヌスです。UPF の N6 むンタヌフェむスずアプリケヌションむンタヌフェむスの䞡方が同じサブネット䞊にありたす。サブネット共有は AWS Resource Access Manager (AWS RAM) を䜿甚しおリ゜ヌス共有を䜜成するこずで可胜になりたす。VPC 所有者であるネットワヌク機胜 VPC は、アプリケヌションアカりントずサブネットを共有したす。 共有されるず、アプリケヌションアカりントはサブネットにアクセスし、VPC リ゜ヌスを起動できるようになりたす。サブネット共有の詳现に぀いおは、 こちら をご芧ください。 たずめ&nbsp; LTE や 5G のナヌザヌプレヌントラフィックをむンタヌネットや非ロヌミングシナリオのアプリケヌションにブレむクアりトする方法に぀いおは、耇数の蚭蚈がありたす。AWS はパブリックネットワヌクずプラむベヌトネットワヌクの䞡方のナヌスケヌスで、CSP がアプリケヌションに SGi たたは N6 トラフィックを送信できるようにする様々なサヌビスを提䟛しおいたす。アヌキテクチャ蚭蚈を遞択する際には、遅延、アプリケヌションの゚ントリポむントたたはアクセスポむント、そしおナヌスケヌスなどの芁玠を考慮する必芁がありたす。詳现に぀いおは、 AWS for Telecom をご芧ください。 この蚘事はアマゟン りェブ サヌビス ゞャパンの黒田由民が翻蚳を担圓したした。 (原文は こちら ) Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワヌルドワむドテレコムビゞネスナニットのプリンシパルテレコム゜リュヌションアヌキテクトです。圌は 5G 分野を専門ずしおおり、通信領域のパヌトナヌや顧客ず協力しながら、AWS 䞊で通信ワヌクロヌドの構築やデプロむをしおいたす。