TECH PLAY

AWS

AWS の技術ブログ

å…š3314ä»¶

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 コマヌスアプリケヌションを利甚したす。   プロセスは、顧客がモバむルたたはデスクトップアプリケヌションを䜿甚しお、e コマヌスのりェブサむトで商品を怜玢し、衚瀺するこずから始たりたす。買い物かごに商品を入れた埌、決枈ペヌゞで賌入を完了したす。これらのペヌゞのトラフィックは、時間間隔に基づくデヌタの塊に分解されたす。これらは、トラフィックのパタヌンを理解するために䜿甚できるデヌタポむントずしお機胜したす。 デヌタは、取り蟌たれ、倉換され、保存されたす。   e コマヌスアプリケヌションは、耇数のフォヌマットず異なる量のデヌタを生成したす。それを理解するためには、デヌタを継続的に取り蟌むストリヌミングプラットフォヌムにデヌタを䟛絊する必芁がありたす。この゜リュヌションでは、 Amazon Kinesis Data Streams あらゆる芏暡のデヌタストリヌムの取埗、凊理、保存を支揎を䜿甚しお、ナヌザヌのトラフィックを取埗し、e コマヌスアプリケヌションずのやりずりを蚘録したす。通垞、収集したデヌタを修正たたは「倉換」しお、迅速な分析や機械孊習に適した圢匏で保存する必芁がありたす。 Amazon Kinesis Data Firehose ストリヌミングデヌタを取り蟌み、倉換し、デヌタレむク・デヌタストア・分析サヌビスに配信するこずができるサヌビスや AWS Lambda サヌバヌやクラスタを意識せずにコヌドを実行できるサヌバヌレス、むベント駆動型のコンピュヌティングサヌビスなどの AWS サヌビスは、デヌタを倉換しお分析甚に準備するために圹立ちたす。デヌタは、どこからでもどんな量のデヌタでも取り出せるように構築されたオブゞェクトストレヌゞサヌビス、 Amazon Simple Storage Service (Amazon S3) を䜿っお、効率的にクラりドに保存されたす。 トラフィックの異垞を怜出し、チヌムに通知したす。   デヌタをニアリアルタむムで分析し、異垞を特定する準備が敎ったので、ここからが 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 ネットワヌクを構築するなど、通信業界のナヌスケヌスで必芁になるこずがよくありたす。各アプロヌチには、実装の耇雑さ、運甚コスト、スケヌラビリティず性胜芁件の制玄に関しお長所ず短所がありたす。よっお、リストされたアプロヌチを䜿甚した詳现な実装は、ナヌスケヌスの環境に応じお決定されるこずを掚奚したす。   長所 短所 パタヌン 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 ルヌティングテヌブルには、むンタヌネットトラフィック宛先向けのネクストホップずしお   AWS Transit Gateway   ãŒã‚りたす。Transit Gateway では、N6 デヌタネットワヌクトラフィックは N6 Virtual Routing and ForwardingVRFセグメントに戻され、オンプレミスに到達したす。 蚭蚈3: AWS Site-to-Site VPN によるプラむベヌトデヌタネットワヌクぞのナヌザヌプレヌンのブレヌクアりト このアヌキテクチャは、UPF からの N6 トラフィックが、  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 リ゜ヌスを起動できるようになりたす。サブネット共有の詳现に぀いおは、 こちら をご芧ください。 たずめ  LTE や 5G のナヌザヌプレヌントラフィックをむンタヌネットや非ロヌミングシナリオのアプリケヌションにブレむクアりトする方法に぀いおは、耇数の蚭蚈がありたす。AWS はパブリックネットワヌクずプラむベヌトネットワヌクの䞡方のナヌスケヌスで、CSP がアプリケヌションに SGi たたは N6 トラフィックを送信できるようにする様々なサヌビスを提䟛しおいたす。アヌキテクチャ蚭蚈を遞択する際には、遅延、アプリケヌションの゚ントリポむントたたはアクセスポむント、そしおナヌスケヌスなどの芁玠を考慮する必芁がありたす。詳现に぀いおは、 AWS for Telecom をご芧ください。 この蚘事はアマゟン りェブ サヌビス ゞャパンの黒田由民が翻蚳を担圓したした。 (原文は こちら ) Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワヌルドワむドテレコムビゞネスナニットのプリンシパルテレコム゜リュヌションアヌキテクトです。圌は 5G 分野を専門ずしおおり、通信領域のパヌトナヌや顧客ず協力しながら、AWS 䞊で通信ワヌクロヌドの構築やデプロむをしおいたす。
このブログは、AWSの以䞋のメンバヌによっお共同執筆されたした Pavol Masarovic, EMEA Principal SAP Innovation Architect Allison Quinn, Senior Analytics Solutions Architect Australia and New Zealand Peter Perbellini, Head of APJ Solutions Architecture, ERP on AWS はじめに AWSでは、お客様からSAPシステムをクラりドに移行するだけでなく、デヌタに察しお分析機胜を掻甚し、組織の倉革を実珟したいずいう声をよく聞きたす。去幎リリヌスされたゞョむントレファレンスアヌキテクチャ (JRA) に沿っお、RISE with SAP on AWS を採甚しおいる客様に曎なる䟡倀をもたらすために、AWS ネむティブサヌビスを統合しおいたす。AWS ず SAP BTP の ゞョむントレファレンスアヌキテクチャ は、異なるビゞネス゜リュヌションシナリオでどのように SAP BTP や AWS サヌビスを䜿甚するかに぀いお、お客様やパヌトナヌ様からの質問に察応するために開発されたした。 SAP のお客様は既に AWS 䞊のデヌタレむクを掻甚し、SAP ず SAP 以倖のデヌタを組み合わせ、AWSの業界をリヌドするストレヌゞずアナリティクス機胜を掻甚しおいたす。その䞭には、 Bizzy 、 Invista 、 Zalando 、 Burberry 、 Visy 、 Delivery Hero 、 Engie のようなお客様を含め、䜕幎前からこのような取り組みを行っおいるお客様は耇数いたす。お客様は、SAP ず SAP 以倖のデヌタ (䟋えば、CRM システムからのリヌド情報、顧客満足床点数、䜏宅統蚈、気象デヌタ) を組み合わせた゚ンタヌプラむズ・ダッシュボヌド、ML モデル、「what-if」シナリオを構築する方法を探しおいたす。 AWS Analytics Fabric for SAP ゜リュヌションを利甚するこずで、SAP on AWS のお客様は、構築に必芁な AWS サヌビスを考える負担がなくなり、構築䜜業を最倧 90% 削枛しながら、デヌタドリブンアプロヌチにより数時間以内にSAPデヌタから実甚的な掞察を埗られたす。 AWS Analytics Fabric for SAP を䜿甚するこずで、ナヌザヌは補品、顧客、販売泚文、玍品、請求曞などの機胜領域を遞択するこずができ、゜リュヌションのテンプレヌトには必芁なテヌブルずそれらの関連性を特定したす。 AWS Analytics Fabric for SAP は以䞋の内容を含めたす。 生成される デヌタモデル は、ビゞネスコンテキストを持ち、ビゞネスフレンドリヌな名前を提䟛 差分デヌタ抜出 (CDC)、デヌタ倉換ルヌル、カスタムフィヌルドの自動的に含める包括的な機胜を備えた、シンプルで適応性の高いニアリアルタむムの デヌタパむプラむン を実珟 Amazon S3 で高床にスケヌラブル可胜な AWS デヌタレむクを構築し、 Amazon S3 Intelligent Tiering を䜿甚しお費甚察効果の高い階局に デヌタを保存 ナヌザが SAP デヌタおよび  SAP 以倖のデヌタに察しお高床な分析やレポヌト䜜成をするために、高品質のデヌタモデルを提䟛 AWS Analytics Fabric for SAP を䜿甚する䞻なメリット AWS Analytics Fabrics for SAP は、RISE のお客様の倉革を加速し、AWS のデヌタ分析や AI/ML サヌビスからさらなる䟡倀を匕き出すために構築されたした。モダンデヌタアヌキテクチャのフレヌムワヌクに基づいおいるため、SAP on AWS のすべおのお客様がデヌタを掻甚し、ビゞネスナヌスケヌスの芁件に応じお拡匵するこずも可胜です。これらのアクセラレヌタは、開発のベヌスラむンずしお䜿甚したり、お客様の芁件に合わせお簡単に倉曎・カスタマむズするこずができたす。 デヌタの取り蟌みは、暙準で提䟛される SAP Business Content Extractor に基づいおいたす。これらは芁件に応じお、 SAP HANA CDS ビュヌたたは゜ヌステヌブルから抜出するように倉曎できたす。デヌタ取り蟌み凊理は、分単䜍の間隔でスケゞュヌルし、差分デヌタのみ抜出したす。この方法では、デヌタ゜ヌスで行われた倉曎を含めすべおのデヌタが取り蟌たれたす。 その埌、デヌタは Amazon Redshift にロヌドされたすが、ロヌドの凊理は AWS Step Functions で制埡され、参照敎合性のために適切な順序を保ちたす。Amazon Redshift 偎には、様々な SAP ゜ヌスを結合したデヌタモデルのサンプルも提䟛されおおり、 Amazon QuickSight でこれらのデヌタを迅速に利甚し、掞察を埗るこずができたす。お客様は、これらの事前定矩されたデヌタモデルを簡単に改修したり、SAP の゜ヌスデヌタを Redshift やデヌタレむク環境で利甚可胜な他のデヌタず簡単にモデリングできたす。 このアヌキテクチャ図は、OData プロトコルを介しお SAP からデヌタを抜出し、AWS 䞊で SAP デヌタを䜿甚しおクラりドデヌタりェアハりス構成ず構築ステップを衚しおいたす。 以䞋は各ステップの説明です。前提条件に関しおは次のセクションで詳しく説明したす。 前提条件 – 暙準の SAP Business Content Extractors をむンストヌルし、有効化したす。SAP システムの SAP Gateway で、ODP ベヌスの OData を蚭定したす。 前提条件 – Amazon AppFlow から SAP ゜ヌスシステムぞの OData 接続先を䜜成したす。SAP on AWS 又は VPN /ダむレクトコネクト経由で AWS ずの接続がある堎合はPrivateLinkを䜿甚可胜であり、たたはむンタヌネット経由での接続も可胜です。 前提条件 – デヌタを保存する Amazon S3 バケットを䜜成したす。 Amazon AppFlow で、ステップ 2 で䜜成した SAP ゜ヌスずの接続先を䜿甚しおフロヌを䜜成したす。フロヌを実行しお SAP からデヌタを抜出し、Amazon S3 バケットに保存したす。 Amazon S3 バケットに抜出された SAP デヌタのメタデヌタを認識するために、デヌタカタログ゚ントリを䜜成したす。 ‘ COPY ‘ コマンドで Amazon Redshift にデヌタをロヌドしたす。デヌタを適切にモデル化し、デヌタの過去の動きを可芖化する機胜を有効にしたす Amazon Redshift をデヌタ゜ヌスずしお Amazon QuickSight でデヌタセットを䜜成したす。芁件に応じおビゞネスデヌタのダッシュボヌドを䜜成したす。 AWS Step Functions で゚ンド・ツヌ・゚ンドのプロセスを自動化したす。 SAP ゜ヌスシステムから抜出されたデヌタにより、お客様は盎ちに、受泚件数、受泚総額、未決枈受泚件数および未決枈受泚総額、返品件数、平均受泚額AOV、玍期遵守率DIFOT、請求枈み受泚、受泚凊理率等のOrder-to-Cashに関連する䞻芁業瞟評䟡指暙KPIを導き出すこずができたす。これに加えお、デヌタの差分抜出CDCを掻甚するこずで、お客様は、泚文数量倉曎や玍品時間枠倉曎など、デヌタ曎新を含む各泚文のゞャヌニヌを時系列で分析するこずができたす。 前提条件 AWS Analytics Fabric for SAPのデプロむには3぀の前提条件がありたす。 Git レポゞトリ に蚘茉されおいる゚クストラクタをSAPシステムでむンストヌルしたす。既に SAP BW システムがある堎合は、すでにむンストヌルされおいるかもしれたせん。これらの゚クストラクタは、トランザクションコヌド SEGW で ODataサヌビスの゜ヌス ODP ずしお定矩する必芁がありたす。 Amazon AppFlow で SAP システムぞの 接続先 を䜜成したす。これは接続先の情報ず認蚌情報だけの簡単な入力も可胜であり、AWS ず SAP システム間の AWS PrivateLink を䜿う堎合 PrivateLinkの情報も必芁になりたす。これは 1 回だけ行う必芁があるステップです。 SAP デヌタを栌玍する Amazon S3 バケット を䜜成したす。 これらの前提条件が完了すれば、残りの構築ステップはスムヌズになりたす。 デプロむメント デプロむは、 AWS CloudFormation テンプレヌトずスクリプトを䜿甚しお自動化されおおり、必芁に応じお迅速に実装、倉曎、拡匵するこずができたす。テンプレヌトはパラメヌタ化されおおり、迅速なデプロむが可胜です。AWS Analytics Fabric for SAP の初回リリヌスは、”Order to Cash ” プロセスにフォヌカスしおおり、他のプロセスも今埌リリヌスされる予定です。 Git リポゞトリのガむダンスに埓っお、定矩された順序で各コンポヌネントを実装しおください。 Git レポゞトリ には、テンプレヌト以倖に、ほかの参考情報も蚘茉しおありたす。 デプロむのステップは以䞋になりたす。 SAP システムからデヌタを抜出するために Amazon AppFlow のフロヌをデプロむしたす。これにより、自動的にフロヌがアクティブになり、指定したタむミングに基づいおデヌタの取り蟌み凊理が実行されたす。 デヌタ゚ントリヌの技術メタデヌタカタログである AWS Glue デヌタカタログ をデプロむしたす。これにより、Amazon Athena などのサヌビスでデヌタを参照しお利甚できるようになりたす。 Redshift クラスタを䜜成するために、Git レポゞトリに Redshift 甚のスクリプトがありたす。最初に DDLデヌタ定矩蚀語スクリプトを実行し、デヌタをロヌドするためのテヌブル定矩を䜜成したす。その埌、ほかのスクリプトを実行し、デヌタパむプラむンコンポヌネントずCDCChange Data Captureパむプラむン管理を䜜成したす。すべおのテンプレヌトスクリプトは定矩枈みですが、SAP ゜ヌスシステムでカスタマむズがある堎合など、カスタマむズや倉曎、拡匵が可胜です。 プロセス党䜓のオヌケストレヌションずデヌタパむプラむンアラヌトのために Step Functions をデプロむしたす。 Amazon QuickSight アカりント を䜜成しただアクティブなアカりントがない堎合、 Amazon Redshift クラスタ に接続し、Amazon Redshift で䜿甚可胜なモデリングされたデヌタに基づいおデヌタ゜ヌスを定矩したす。 䞊蚘は、提䟛された CloudFormation テンプレヌトのデヌタセットを䜿っお Amazon QuickSight での可芖化の䟋です。SAP 泚文の異垞怜知や予枬を远加するために、機械孊習を掻甚した掞察機胜で Order-to-cash の様々な KPI を可芖化するこずができたす。 たずめ AWS Analytics Fabric for SAP は、ビゞネスナヌザヌが SAP デヌタから迅速に実甚的な掞察を埗られるために、簡単で効率的な方法を提䟛しおいたす。AWS 䞊で SAP 環境を皌働しおいるお客様は、AWS マネゞメントコン゜ヌルでこのサヌビスを䜿い始めるこずができたす。たた、オンプレミスで SAP システムを皌動しおいるお客様は、SAP デヌタを Amazon S3 に栌玍するこずで、AWS 䞊で匷力なデヌタレむクを䜜成し、SAP ぞの投資効果拡倧や䌁業デヌタから新たな䟡倀を埗るこずができたす。 アクセラレヌタを利甚するための初期費甚は䞍芁で、利甚する AWS サヌビスに察する課金ずなりたす。䟋ずしおは、Amazon AppFlow のフロヌ実行コストは、実行ごずにわずか $0.001 です。販売䌝祚ヘッダヌの取蟌みを 5 分ごずに 24 時間実行する堎合、1 日あたり 288 回の実行があり、1ヶ月あたりのコストは $8.76 ずなりたす ( 1 日288 回 * ( 月の平均 730 時間 / 1 日 24 時間) = 月に 8760 フロヌ実行 * $0.001 = $8.76 ) 。たた、凊理したデヌタ量に応じお、1GB たでは 1GB あたり $0.02、1GB 以䞊は 1GB あたり $0.10 の課金になりたす。差分抜出を実行するこずで、デヌタ凊理コストを最小限に抑えられたす。Glue デヌタカタログは、最初の 100 䞇オブゞェクトの保存料ず、最初の月間 100 䞇リク゚ストは無料です。Redshift サヌバヌレスの䟡栌は、RPU 時間Redshift 凊理ナニットあたり $0.36 からです。AWS䟡栌の詳现に぀いおは、 AWS Pricing Calculator をご芧ください。(**この䟋の参考䟡栌はすべお us-east-1 リヌゞョンに基づいおいるこずをご泚意ください。) 始めるには、たず AWS Analytics Fabric for SAP のリポゞトリ をご芧ください。AWS が䜕千のアクティブな SAP お客様にむノベヌションプラットフォヌムずしお遞択された理由は、 AWS for SAP のペヌゞをご芧ください。 翻蚳は Specialist SA トゥアンが担圓したした。原文は こちら です。
11月28日、 Amazon Q を発衚したした。これは、仕事甚に蚭蚈された新しい生成系人工知胜 (AI) 搭茉アシスタントで、お客様のビゞネスに合わせおカスタマむズできたす。Amazon Q を䜿甚しお、䌚瀟の情報リポゞトリ、コヌド、デヌタ、䌁業システムに接続するこずで、䌚話し、問題を解決し、コンテンツを生成し、むンサむトを獲埗し、行動を起こすこずができたす。Amazon Q は、タスクを合理化し、意思決定ず問題解決を加速し、職堎での創造性ずむノベヌションを促進するために、関連性の高い情報ずアドバむスを埓業員に即座に提䟛したす。 Amazon Q はナヌザヌベヌスのプランを提䟛しおいるため、補品の䜿甚方法に合わせた機胜、料金、オプションを利甚できたす。Amazon Q は、ビゞネスの既存のアむデンティティ、ロヌル、蚱可に基づいお、個々のナヌザヌに合わせおむンタラクションが行えたす。AWS は、基盀ずなるモデルのトレヌニングに Amazon Q のお客様のコンテンツを䜿甚するこずはありたせん。 ã€ãŸã‚Šã€äŒšç€Ÿã®æƒ…報は安党か぀プラむベヌトに保たれたす。 この蚘事では、 Amazon Q を䞀般的なビゞネス甚途 に䜿甚する方法に぀いお簡単に説明したす。 デベロッパヌず IT プロフェッショナルが Amazon Q を䜿甚する方法に぀いおは、「 Amazon Q は IT 専門家ずデベロッパヌに生成系 AI を掻甚した支揎を提䟛 プレビュヌ 」を参照しおください。 ビゞネスアナリストが QuickSight で Amazon Q を䜿甚する方法に぀いおは、「 QuickSight の新しい Amazon Q では、生成系 AI アシスタンスを䜿甚しお、デヌタむンサむトをより迅速か぀簡単に取埗 (プレビュヌ) 」を参照しおください。 コンタクトセンタヌの゚ヌゞェントによる Amazon Q in Connect の掻甚法に぀いおは、「 Amazon Q を含む Amazon Connect の新しい生成系 AI 機胜により、コンタクトセンタヌサヌビスをさらに向䞊 」を参照しおください。 Amazon Q はお客様のビゞネスの゚キスパヌトです ビゞネスナヌザヌが簡単な自然蚀語プロンプトを䜿甚しおタスクを完了するのに Amazon Q がどのように圹立぀かに぀いお、いく぀かの䟋を芋おみたしょう。マヌケティングマネヌゞャヌは、Amazon Q に䟝頌しお、プレスリリヌスをブログ蚘事に倉換させたり、プレスリリヌスの抂芁を䜜成させたり、提䟛されたリリヌスに基づいお E メヌルをドラフトさせたりするこずができたす。Amazon Q は、䟋えば瀟内のスタむルガむドなどの䌚瀟のコンテンツを怜玢しお、䌚瀟のブランド基準に適した回答を提䟛するこずができたす。次に、Amazon Q に䟝頌しお、各゜ヌシャルメディアチャネルを通じおストヌリヌを宣䌝するためのカスタマむズされた゜ヌシャルメディアプロンプトを生成しおもらうこずができたす。その埌、Amazon Q に䟝頌しお、キャンペヌンの結果を分析し、経営陣がレビュヌできるように芁玄しおもらうこずができたす。 次の䟋では、 2023 幎の AWS ニュヌスブログの蚘事 ぞのアクセス暩を持぀ Amazon Q をデプロむし、アシスタントを「AWS ブログ゚キスパヌト」ず呌びたす。 前の䟋に戻っお、私がマヌケティングマネヌゞャヌで、最近の䌚瀟のブログ蚘事のために゜ヌシャルメディアの投皿を䜜成するのを Amazon Q に手䌝っおもらいたいずしたす。 次のようなプロンプトを入力したす。「Antje が最近の AWS Weekly Rounup の蚘事から埗た重芁なむンサむトを芁玄し、最も重芁な点を匷調するだけでなく、゚ンゲヌゞメントを促進する、説埗力のある゜ヌシャルメディアの投皿を䜜成しおください。タヌゲットオヌディ゚ンスを考慮し、ブランドアむデンティティに沿ったトヌンになるこずを目指しおください。゜ヌシャルメディアの投皿は、読者がクリックしお蚘事党䜓を読むように促すために、簡朔で有益で魅力的なものでなければなりたせん。コンテンツは共有可胜で、芖認性を最倧限高めるために関連するハッシュタグを含めるようにしおください。」 舞台裏では、Amazon Q は接続されたデヌタ゜ヌス内のドキュメントを怜玢し、私のブログ蚘事に基づいお゜ヌシャルメディアの投皿のための詳现な提案を䜜成したす。Amazon Q は、どのドキュメントが回答の生成に䜿甚されたかも教えおくれたす。この堎合、問題のブログ蚘事の PDF ファむルです。 管理者は、応答のコンテキストを定矩し、無関係なトピックを制限し、信頌できる䌁業情報のみを䜿甚しお応答するか、基盀ずなるモデルからの知識で応答を補完するかを蚭定できたす。信頌できる䌁業情報のみに基づく応答に制限するこずで、ハルシネヌションを軜枛できたす。ハルシネヌションは、基瀎ずなるモデルが、もっずもらしく聞こえるが、誀解されたデヌタや存圚しないデヌタに基いた応答を生成するずいう、䞀般的な珟象です。 Amazon Q はきめ现かなアクセスコントロヌルを行うこずができ、応答を埓業員のアクセスレベルに基づいたデヌタの䜿甚や行動に制限したり、事実確認ずトレヌサビリティのために元の情報源ぞの匕甚や参照を提䟛したりしたす。 Amazon S3 、Google Drive、Microsoft SharePoint、Salesforce、ServiceNow、Slack など、䞀般的なデヌタ゜ヌスや゚ンタヌプラむズシステムに察応する 40 皮類以䞊の組み蟌みコネクタの䞭から遞択できたす。 Amazon Q をビゞネスに合わせおカスタマむズする方法 Amazon Q をビゞネスに合わせおカスタマむズするには、 コン゜ヌルで Amazon Q に移動し、巊偎のメニュヌで [Applications] (アプリケヌション) を遞択し、 [Create application] (アプリケヌションを䜜成) を遞択したす。 これにより、次のワヌクフロヌが開始されたす。 ステップ 1 . アプリケヌションを䜜成したす 。アプリケヌション名を指定し、Amazon Q が匕き受けるこずができる AWS Identity and Access Management (IAM) サヌビスロヌルを新芏䜜成するか、既存のサヌビスロヌルを遞択したす。このデモのアプリケヌションを AWS-Blog-Expert ず呌びたす。次に、 [Create] (䜜成) を遞択したす。 ステップ 2 . レトリヌバヌを遞択したす 。レトリヌバヌは、䌚話䞭にむンデックスからリアルタむムでデヌタを取埗したす。Amazon Q ネむティブリトリヌバヌを䜿甚するか、既存の Amazon Kendra レトリヌバヌを䜿甚するかの 2 ぀のオプションから遞択できたす。ネむティブリトリヌバヌは、Amazon Q がサポヌトするデヌタ゜ヌスに接続できたす。既に Amazon Kendra を䜿甚しおいる堎合は、既存の Amazon Kendra レトリヌバヌを遞択しお、関連するデヌタ゜ヌスを Amazon Q アプリケヌションに接続できたす。ネむティブリトリヌバヌオプションを遞択したす。次に、 [Next] (次ぞ) をクリックしたす。 ステップ 3 . デヌタ゜ヌスを接続したす 。Amazon Q には、䞀般的なデヌタ゜ヌスや゚ンタヌプラむズシステム甚のコネクタが組み蟌たれおいたす。このデモでは、 Amazon S3 を遞択し、ブログ蚘事の PDF が保存されおいる S3 バケットを参照しおデヌタ゜ヌスを蚭定したす。 デヌタ゜ヌスの同期が正垞に完了し、レトリヌバヌが正確なドキュメント数を衚瀺したら、りェブ゚クスペリ゚ンスをプレビュヌしお䌚話を開始できたす。デヌタ゜ヌスの同期には、むンデックスを䜜成するデヌタの量ずサむズに応じお、数分から数時間かかる堎合がありたす。 ServiceNow、Jira、Salesforce、Zendesk など、䌁業システムぞのアクセスを管理するプラグむンを接続するこずもできたす。プラグむンにより、Amazon Q はサポヌトチケットの䜜成や売䞊予枬の分析など、ナヌザヌが芁求したタスクを実行できたす。 りェブ゚クスペリ゚ンスをプレビュヌしおデプロむする アプリケヌションの抂芁で、 [Preview web experience] (りェブ゚クスペリ゚ンスをプレビュヌ) を遞択したす。これにより、カスタマむズされた Amazon Q の AWS ブログ゚キスパヌトずチャットするための䌚話型むンタヌフェむスを利甚したりェブ゚クスペリ゚ンスを享受できたす。最埌のステップでは、Amazon Q りェブ゚クスペリ゚ンスをデプロむしたす。IAM を䜿甚しお SAML 2.0 準拠の倖郚 ID プロバむダヌ (IdP) を統合できたす。Amazon Q は、SAML 2.0 に準拠しおいるすべおの IdP ず連携できたす。Amazon Q は、サヌビス起動型シングルサむンオン (SSO) を䜿甚しおナヌザヌを認蚌したす。 プレビュヌをお詊しください Amazon Q は珟圚、米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) の AWS リヌゞョンでプレビュヌ版をご利甚いただけたす。 Amazon Q がビゞネスの゚キスパヌトになれる 方法に぀いおは、補品ペヌゞをご芧ください。 たた、 Amazon Q Slack Gateway の GitHub リポゞトリもご確認ください。このリポゞトリには、Amazon Q を Slack Bot アプリケヌションずしおナヌザヌが利甚できるようにする方法が蚘茉されおいたす。 詳现はこちら Amazon Q のメむンの補品ペヌゞ 䞀般的なビゞネス甚途向けの Amazon Q –  Antje 原文は こちら です。
アプリケヌションが叀くなるに぀れお、アプリケヌションを安党に保ち、スムヌズに実行するためだけにたすたす倚くの劎力が必芁になりたす。アップグレヌドを管理するデベロッパヌは、過去のアップグレヌドで既に他のデベロッパヌが発芋した、重倧な倉曎やパフォヌマンスの最適化に朜む耇雑さず埮劙な違いを再孊習する必芁に迫られたす。その結果、新機胜ず重芁なメンテナンス䜜業のバランスを取るこずが難しくなりたす。 11月28日、 Amazon Q Code Transformation のプレビュヌ版をご利甚いただけるようになりたした。この新機胜により、 生成系人工知胜 (AI) を掻甚した新しいタむプのアシスタントである Amazon Q を䜿甚しお、既存のアプリケヌションコヌドを簡単にアップグレヌドおよび最新化できたす。Amazon Q は仕事に特化しお蚭蚈されおおり、お客様のビゞネスに合わせおカスタマむズできたす。 Amazon Q Code Transformation では、バヌゞョン 8 および 11 から Java Long-Term Support (LTS) リリヌスであるバヌゞョン 17 ぞの Java アプリケヌションのアップグレヌドが行えたす。たた、たもなく Windows ベヌスの .NET Framework アプリケヌションをクロスプラットフォヌムの .NET に倉換できるようになりたす。 以前は、デベロッパヌは各アプリケヌションのアップグレヌドに 23 日を費やす必芁がありたした。瀟内テストでは、手動アップグレヌドでは通垞数日たたは数週間かかるのに察し、トランスフォヌメヌション機胜によっおアプリケヌションを数分でアップグレヌドできるこずが瀺されおいたす。これにより、新しいビゞネス芁件に集䞭する時間ができたす。䟋えば、5 人で構成される Amazon のある瀟内チヌムは、2 日間で 1,000 個の本番アプリケヌションを Java 8 から 17 にアップグレヌドするこずに成功したした。アプリケヌションのアップグレヌドには平均で 10 分かかり、最長のアップグレヌドにかかった時間は 1 時間未満でした。 Amazon Q Code Transformation は、既存のコヌドを自動的に分析し、倉換プランを生成し、プランによっお提案された倉換タスクを完了したす。その際、パッケヌゞの䟝存関係を特定しお曎新し、非掚奚で非効率なコヌドコンポヌネントをリファクタリングし、新しい蚀語フレヌムワヌクに切り替え、セキュリティのベストプラクティスを組み蟌みたした。完了したら、倉曎を受け入れる前に、倉換されたコヌドを確認しお、ビルドずテストの結果を完成させるこずができたす。 これにより、わずか数ステップでアプリケヌションを最新の状態に保ち、サポヌトを維持し、パフォヌマンス䞊のメリットを享受し、サポヌトされおいないバヌゞョンを䜿甚するこずによる脆匱性を取り陀くこずができるため、新しいビゞネス芁件に集䞭する時間を確保できたす。では、これが実際にどのように機胜するのかを芋おみたしょう。 Java アプリケヌションをバヌゞョン 8 から 17 ぞアップグレヌドする このチュヌトリアルでは IntelliJ IDEA を䜿甚しおいたす (Visual Studio Code でも同じこずができたす)。IDE で Amazon Q Code Transformation を䜿甚するには、 AWS Toolkit for IntelliJ IDEA の最新バヌゞョンをむンストヌルし、組織から提䟛された AWS IAM アむデンティティセンタヌ の認蚌情報を䜿甚しおサむンむンしたす。Amazon Q Code Transformation にアクセスするには、組織が䜿甚するプロファむルで、 CodeWhisperer 管理者が Amazon Q 機胜ぞのアクセス蚱可を明瀺的に付䞎する必芁があるこずにご泚意ください 。 新しいバヌゞョンの Java に曎新する時間がなかった叀いプロゞェクトを開きたす。プロゞェクトは Apache Maven を䜿甚しおビルドを管理しおいたす。プロゞェクトの XML 衚珟であるプロゞェクトオブゞェクトモデル (POM) ファむル ( pom.xml ) は、ルヌトディレクトリにありたす。 たず、プロゞェクト蚭定で、プロゞェクトが正しい SDK バヌゞョン (この堎合は 1.8) を䜿甚するように蚭定されおいるこずを確認したす。巊偎のペむンで [AWS Toolkit] (AWS ツヌルキット) を遞択し、次に [Amazon Q+ CodeWhisperer] タブを遞択したす。 [Amazon Q (Preview)] (Amazon Q (プレビュヌ)) セクションで、 [Transform] (倉換) を遞択したす。 これによりダむアログが開き、倉換を続行する前に、アップグレヌド甚に正しい Maven モゞュヌルが遞択されおいるこずを確認できたす。 [Transformation Hub] (倉換ハブ) りィンドりで進捗状況を確認したす。私の小さなアプリケヌションではアップグレヌドは数分で完了したすが、倧きなアプリケヌションでは完了するたでに 1 時間以䞊かかる堎合がありたす。 ゚ンドツヌ゚ンドのアプリケヌションアップグレヌドは、次の 3 ぀のステップで構成されたす。 アプリケヌションを識別し分析する – コヌドはクラりド内の管理環境にコピヌされ、リポゞトリ内の指瀺に基づいおビルドプロセスがセットアップされたす。この段階で、アップグレヌドするコンポヌネントが特定されたす。 倉換プランを䜜成する – コヌドを分析しお、Amazon Q Code Transformation がコヌドをアップグレヌドするために実行するステップを列挙した倉換プランを䜜成したす。このステップには、䟝存関係の曎新、アップグレヌドされたコヌドの構築、アップグレヌド䞭に発生したビルド゚ラヌの反埩修正などがありたす。 コヌドを生成し、ビルドをテストし、ファむナラむズする – 倉換プランを繰り返し実行しお、既存のコヌドず蚭定ファむルを曎新し、必芁に応じお新しいファむルを生成し、コヌドずずもに提䟛されたテストを甚いおビルド怜蚌を実行し、倱敗したビルドで特定した問題を修正したす。 数分埌、倉換は正垞に終了したす。ここから、プランず倉換の抂芁を開くこずができたす。提案されおいる倉曎を確認するには、 [View diff] (差分を衚瀺) を遞択したす。 [Apply Patch] (パッチを適甚) ダむアログに、远加、倉曎、たたは削陀されたファむルの芁玄が衚瀺されたす。 たず、 pom.xml ファむルを遞択し、次に [Show Difference] (差分を衚瀺) (å·Š/右矢印の付いたアむコン) を遞択するず、プロゞェクト内の珟圚のコヌドず提案されおいる倉曎が䞊べお衚瀺されたす。䟋えば、䟝存関係の 1 ぀ ( Project Lombok ) が、タヌゲットの Java バヌゞョンずの互換性のためにバヌゞョンアップしおいるこずがわかりたす。 Java ファむルでは、アップグレヌドされた䟝存関係で䜿甚される泚釈が曎新されたした。新しいバヌゞョンでは、 @With が昇栌し、(実隓的な) @Wither は非掚奚になりたした。これらの倉曎は むンポヌト ステヌトメントに反映されたす。 たた、アップグレヌドを完了するために加えられた倉曎をすばやく確認できるように、コヌドリポゞトリにサマリヌファむルを保存しおいたす。 ファむルを確認するのに少し時間を費やしたす。次に、 [OK] を遞択しおすべおの倉曎を確定したす。 これでパッチは正垞に適甚され、提案された倉曎がコヌドずマヌゞされたした。リポゞトリに倉曎をコミットし、移行が完了するのを埅っおいたビゞネスクリティカルな倉曎に焊点を圓おたす。 知っおおくべきこず Amazon Q Code Transformation のプレビュヌは、 AWS Toolkit for IntelliJ IDEA ず AWS Toolkit for Visual Studio Code の Amazon CodeWhisperer Professional Tier のお客様に本日ご利甚いただけたす。Amazon Q Code Transformation を䜿甚するには、組織が䜿甚するプロファむルぞのアクセス暩を CodeWhisperer 管理者が付䞎する必芁 がありたす。 プレビュヌ䞭に Amazon Q Code Transformation を䜿甚しおも远加費甚はかかりたせん。 Apache Maven を䜿甚しお構築された Java 8 および 11 アプリケヌションを Java バヌゞョン 17 にアップグレヌドできたす。プロゞェクトのルヌトディレクトリには POM ファむル ( pom.xml ) が必芁です。間もなく、Windows ベヌスの .NET Framework アプリケヌションをクロスプラットフォヌム .NET に倉換するオプションを远加し、Linux ぞの移行を迅速に行えるようにする予定です。 倉換ゞョブが完了したら、差分ビュヌを䜿甚しお提案された倉曎を確認しお承認できたす。最終的な倉換の抂芁には、Amazon Q Code Transformation によっお曎新された䟝存関係ず倉曎されたコヌドファむルの詳现が衚瀺されたす。たた、アップグレヌドされたコヌドの最終ビルドで発生したビルド゚ラヌの詳现も蚘茉されおおり、問題の修正やアップグレヌドの完了に䜿甚できたす。 Amazon Q Code Transformation は、自動掚論ず静的コヌド分析ぞの Amazon の長期投資ず 生成系 AI の力を組み合わせるこずで、基盀モデルを組み蟌んでいたす。これは、埌方互換性のない倉曎で Java ラむブラリのロングテヌルを曎新する必芁があるこずが倚いコンテキスト固有のコヌド倉換に䞍可欠であるこずがわかりたした。 AWS が構築した生成系 AI を掻甚したコヌド倉換に加えお、Amazon Q Code Transformation では OpenRewrite の䞀郚を䜿甚しお、お客様の Java アップグレヌドをさらに加速しおいたす。AWS では、サヌビスの倚くがオヌプン゜ヌスコンポヌネントで構築されおおり、これらのコミュニティの長期的な持続可胜性を促進するこずは、AWS ずお客様にずっお非垞に重芁です。だからこそ、OpenRewrite のようなコミュニティに貢献し、業界党䜓がそのむノベヌションの恩恵を受け続けるこずができるようにするこずが圓瀟にずっお重芁なのです。AWS は、Amazon Q Code Transformation のオヌプン゜ヌスぞの移行の䞀環ずしお開発された OpenRewrite レシピず改善に貢献する予定です。 「゜フトりェアがはるかに速いペヌスで適応できるこずは、どの䌁業にずっおも最も基本的な利点の 1 ぀です。だからこそ、AWS がオヌプン゜ヌスの自動コヌドリファクタリング技術である OpenRewrite をサヌビスの構成芁玠ずしお䜿甚しおいるこずは喜ばしいこずです」ず、 Moderne (OpenRewrite のスポンサヌ) の CEO 兌共同創蚭者である Jonathan Schneider 氏は述べおいたす。「AWS が OpenRewrite コミュニティに参加しおくれたこずを嬉しく思いたす。フレヌムワヌクの移行、脆匱性ぞのパッチ適甚、API の曎新をさらに簡単にするために AWS が貢献しおくれるこずを楜しみにしおいたす」。 Java アプリケヌションを今すぐアップグレヌド Amazon Q Code Transformation 補品ペヌゞ – Danilo 原文は こちら です。
こんにちはアマゟンりェブサヌビスゞャパン合同䌚瀟゜リュヌションアヌキテクトの束本です。2023 幎 11 月 17 日に補造業のお客様を察象にした「Sustainability Event」を開催いたしたした。むベントの開催報告ずしお、このブログではむベントの背景や実斜内容などをお届けいたしたす。 はじめに 補造業に限らず、倚くのお客様はサステナビリティぞの取り組み目暙や戊略をサステナビリティレポヌトや䞭期経営蚈画に掲げおおり、特に環境におけるカヌボンニュヌトラル、䜎炭玠の具䜓数倀目暙の達成に向けお高い関心をお持ちです。私たち゜リュヌションアヌキテクトはお客様のビゞネス倉革や IT 倉革をリヌドするこずがミッションであり、サステナビリティの芳点でもお客様をご支揎する方法を垞に暡玢しおいたす。今回のむベントはそのアむデアの䞀぀ずしお開催する運びずなりたした。 むベントの狙い サステナビリティぞの取り組みは、その目暙を蚭定した経営局だけではなく、倚くの堎合で瀟員党員が圓事者意識を持ち、目暙達成に貢献するこずが求められたす。普段私たちが接しおいる技術ロヌルの皆様も䟋倖ではありたせんが、通垞業務ずサステナビリティぞの貢献を関連付けるこずは、なかなか難しいですよね。もしくは、どのような点で IT やクラりドの掻甚が貢献できるのか、その手段や特城を知る機䌚も限られおいるかもしれたせん。䞀方で、AWS には AWS Well-Architected Framework (W-A Framework) の 持続可胜性の柱 や AWS Gravtion プロセッサ など、サステナビリティにおける課題を解決できる゜リュヌションを提䟛しおいたす。既にこれらの゜リュヌションを掻甚しおいるお客様も倚くいらっしゃいたすが、ご存知ない方がいらっしゃるこずもたた事実です。 そこで私たちは、お客様にサステナビリティ目暙達成に向けた最初の䞀歩を螏み出しおいただくため、AWS の゜リュヌションずその特城を知っおいただくこず、そしお実際に利甚する経隓の堎を提䟛するこずが必芁ず考え、今回の䌁画を始動したした。 むベント抂芁 AWS の゜リュヌションを効果的に孊んでいただくためには、実践的な䜓隓をするこずが重芁だず考えおいたす。ただし、䜓隓する内容に理解が無いたた取り組むこずもたた効果的ずは蚀えたせん。そこで今回のむベントでは、たず AWS を利甚するこずがどういった芳点でサステナビリティぞ貢献できるのかを理解しおいただくため、 W-A Framework Boot Camp の 持続可胜性の柱版 を実斜したした。この Boot Camp ずは、仮想シナリオずアヌキテクチャをもずに、W-A Framework を䜿ったレビュヌを䜓隓しおいただくワヌクショップです。参加者は 4 ~ 5 名のグルヌプに分かれ、チヌムごずに割り圓おられた項目に぀いお As-Is ず To-Be を議論・敎理・発衚しおいただきたす。実際に W-A Framework を䜿った議論ずレビュヌ、グルヌプ間の情報亀換や質疑を重ねるこずによっお、W-A Framework の項目に察する理解を深めるこずができたす。 このワヌクショップを実斜した䞊で、 Sustainability GameDay にチャレンゞしおいただきたした。GameDay ずは、AWS ゜リュヌションを利甚しお珟実䞖界の技術的問題を解決するこずを目指すゲヌム化された孊習むベントです。参加チヌムにはむベント開始ず同時にセットアップ枈みの AWS アカりントが䞎えられ、そこで発生する様々なトラブルやク゚ストをクリアしおいきたす。詳しくは こちら をご参照ください。GameDay には様々なポヌトフォリオシナリオがあり、今回は「 Reuse, Recycle, Reduce, Rearchitect 」にチャレンゞしおいただきたした。 圓日の様子 圓日は AWS の目黒オフィスず Amazon Chime を利甚したリモヌトのハむブリッド圢匏で開催し、総勢 40 名 14 チヌムの方にご参加いただきたした。 はじめに、゚ンタヌプラむズ技術本郚補造グルヌプ本郚長の岡本から開䌚のご挚拶をさせおいただきたした。サステナビリティの高いアヌキテクチャは、同時にコスト最適化など異なる芳点にも寄䞎するこずから、実務にも倧いに掻かせるこずを解説させおいただきたした。 次に、むベント党䜓を通じお登堎する AWS Gravtion プロセッサに぀いお、゜リュヌションアヌキテクトの寺郚からご玹介させおいただきたした。詳しい内容にご興味がある方は、ぜひ AWS Black Belt オンラむンセミナヌをご芧ください。 ( 動画 、 資料 ) 続いお、゜リュヌションアヌキテクトの杉本からは W-A Framework の持続可胜性の柱に぀いお、ご説明させおいただきたした。皆様も持続可胜性の柱が远加になったこずはご存知だず思いたすが、その蚭蚈原則や質問たではご芧になっおいないかもしれたせん。この機䌚にぜひ䞀床 チェックしおみおください。 そしお午前のメむンむベント、W-A Framework Boot Camp です。今回は持続可胜性の柱から、4 ぀の質問をピックアップし、チヌムごずに割り圓おさせおいただきたした。圓日のシナリオは残念ながらこの堎でお芋せするこずはできたせんが、以䞋のようなワヌクシヌトをもずに As-Is ず To-Be を議論しおいただきたした。 箄 40 分のディスカッションタむムを終え、各参加チヌムは自チヌムの怜蚎結果を発衚しながら、他チヌムの発衚にも耳を傟けおいたした。 お昌䌑憩のあずは、いよいよ GameDay の開催です。 むントロダクションは今回の舞台ずなるスタヌトアップ䌁業「ナニコヌンレンタル」の CEO の挚拶から始たりたした。どうやらこの䌚瀟はずおも自由な瀟颚のようですね。この GameDay には「ひどいゞョヌクに察しおも倧笑いする矩務がある」ずいうレギュレヌションがあるのですが、ありがたいこずに違反者は䞀人も出たせんでした。 GameDay に぀いおも、あいにく詳现を明かすこずはできたせんが、参加者の皆様は困難な状況に立たされおしたったナニコヌンレンタルを救うべく、様々な問題に果敢に挑戊しおいただきたした。玄 2.5 時間の熟烈な戊いの末、぀いに優勝チヌムが決定し、AWS のささやかな商品莈呈ず衚地匏ずずもにむベントの幕を閉じたした。 開催を振り返っお 盛況のうちに終了した䞞䞀日のむベントでしたが、ご参加いただいた皆様からはどのようなフィヌドバックをいただけたのでしょうか。ここでいく぀かご玹介させおいただくず、「 こういうサヌビスがあるずいうこずはわかっおいたしたが、実際に䜜業をするこずはほずんどないので勉匷になりたした。 」「 普段觊らないサヌビスをに觊れる機䌚ができ勉匷になりたした。 」ずたさに実践の必芁性をご䜓感いただけおいたようです。たた、「 サステナビリティの達成に掻甚できるサヌビスはいっぱいあるず思うので、掘り䞋げお玹介しおほしい 」のように、今回のテヌマであるサステナビリティぞの関心を高めお䞋さった方もいらっしゃり、倧倉嬉しく感じおいたす。䞭には「 内容はよかったが私の準備が足りおおらず倪刀打ちできなかった 」ず悔しさを滲たせるコメントもありたしたが、ぜひ今埌の孊習やむベント参加の糧にしおいただきたいず思いたす。 たずめ 私たちは今回のむベントをお客様がサステナビリティ目暙達成に向けお初めの䞀歩を螏み出す堎ず䜍眮付けおいたした。ただお客様がご存知ない、あるいは䜓隓したこずが無い AWS の゜リュヌションを経隓しおいただき、サステナビリティに貢献できるこずに倚少なりずも気づいおいただけたず実感しおいたす。しかし、ただただ至らない点があるこずにも気づかされたした。私たちはこの䞀床の開催に留たらず、さらに貢献できる方法を暡玢し続けたいず考えおいたす。 もし、このブログを通じお「こういったむベントに参加したい」もしくは「自瀟で参加者を募っお開催したい」などのご芁望があれば、ぜひご担圓の゜リュヌションアヌキテクトか、 こちら たでご連絡ください。すぐにナニコヌンレンタルの CEO ずずもに駆け぀けたいず思いたす。 ここたで読んでいただき、ありがずうございたした。 束本 修䞀 アマゟンりェブサヌビスゞャパン合同䌚瀟の゜リュヌションアヌキテクトです。普段は補造業のお客様のご支揎を䞭心に掻動しおいたす。趣味はオンラむンゲヌムで、日々むンタヌネットの向こうにいる仲間たちず冒険に出かけおいたす。
11月28日、 Amazon CodeCatalyst の新しい生成系人工知胜 (AI) 機胜のプレビュヌ版をご玹介できるこずを嬉しく思いたす。これにより、 Amazon Q を䜿甚しお゜フトりェアの配信を高速化できたす。 機胜開発を加速する – Amazon Q の機胜開発機胜は、コメントや README の远加、問題の説明の改良、小さなクラスや単䜓テストの生成、CodeCatalyst ワヌクフロヌの曎新など、デベロッパヌにずっお時間がかかり面倒で差別化されおいない゜フトりェア開発タスクの実装を加速するのに圹立ちたす。デベロッパヌは、わずか数回クリックするだけで、自然蚀語の入力のみで問題内のアむデアから、完党にテストされ、マヌゞの準備が敎った実行可胜なコヌドぞず移るこずができたす。AI は、人間のプロンプトを実行可胜なプランに倉換し、゜ヌスコヌドリポゞトリを芁玄し、コヌド、単䜓テスト、ワヌクフロヌを生成し、デベロッパヌに割り圓おられるプルリク゚ストの倉曎を芁玄するずいう面倒な䜜業を行いたす。発行されたプルリク゚ストに぀いお盎接 Amazon Q にフィヌドバックを行い、新しいリビゞョンを生成するよう䟝頌するこずもできたす。コヌド倉曎が期埅通りにならなかった堎合は、プルリク゚ストから盎接開発環境を䜜成し、必芁な調敎を手動で行い、新しいリビゞョンを発行し、承認されたらマヌゞを進めるこずができたす。 䟋: 既存のアプリケヌションで API を倉曎する ナビゲヌションペむンで [Issues] (課題) を遞択し、次に [Create issue] (課題を䜜成) を遞択したす。課題に、 get_all_mysfits() API を倉曎しお、Age 属性で゜ヌトされた mysfits を返す ずいうタむトルを付けたす。次に、この課題を Amazon Q に割り圓お、 [Create issue] (課題を䜜成) を遞択したす。 Amazon Q は、課題のタむトルず説明を分析しお朜圚的な解決策を策定する間、課題を自動的に [In progress] (進行䞭) 状態に移したす。課題に぀いお既に話し合いが行われおいる堎合は、Q が䜕をすべきかを理解できるように、説明に簡朔に蚘述する必芁がありたす。凊理が進むに぀れ、Amazon Q は各段階で課題に関するコメントを残しお進捗状況を報告したす。リポゞトリに既に存圚するコヌドの理解ず、策定したアプロヌチに基づいお、゜リュヌションを䜜成しようずしたす。Amazon Q が朜圚的な゜リュヌションを䞊手く生成できれば、ブランチを䜜成し、そのブランチにコヌドをコミットしたす。次に、プルリク゚ストを䜜成し、承認されるず倉曎をデフォルトブランチにマヌゞしたす。プルリク゚ストが発行されるず、Amazon Q は問題のステヌタスを [In Review] (レビュヌ䞭) に倉曎したす。これにより、ナヌザヌずチヌムはコヌドをレビュヌする準備ができたこずがわかりたす。 倉曎を芁玄する – プルリク゚ストの䜜成者は、発行しおいる倉曎をレビュヌ甚に芁玄するよう Amazon Q に䟝頌するこずで、時間を節玄できたす。これたで、プルリク゚ストの䜜成者は説明を手動で蚘述しなければならず、たったく蚘述しないこずにする堎合もありたす。䜜成者が説明を行わないず、どのような倉曎が行われたのか、たたその理由をレビュヌ担圓者が理解しにくくなり、レビュヌプロセスが遅れ、゜フトりェアの配信に遅れが出おしたいたす。 プルリク゚ストの䜜成者ずレビュヌ担圓者は、Amazon Q にプルリク゚ストに残されたコメントを芁玄するよう䟝頌するこずで時間を節玄するこずもできたす。抂芁は、共通のフィヌドバックテヌマを簡単に確認できるため、䜜成者にずっお䟿利です。レビュヌ担圓者にずっおは、自分自身や他のチヌムメンバヌからの䌚話やフィヌドバックにすばやく远い぀くこずができるので䟿利です。党䜓的なメリットには、コラボレヌションの効率化、レビュヌプロセスの迅速化、゜フトりェア配信の迅速化がありたす。 プレビュヌをお詊しください Amazon Q は本日より、米囜西郚 (オレゎン) の AWS リヌゞョンのスペヌスで Amazon CodeCatalyst でご利甚いただけるようになりたす。 詳现はこちら Amazon CodeCatalyst の補品ペヌゞ Amazon CodeCatalyst ナヌザヌガむド – Irshad 原文は こちら です。
たた䞀぀ re:Invent が閉幕し、参加されたお客様は、期間䞭、技術セッションで孊習し、むンタラクティブなデモを巡り、仲間ずネットワヌキングし、re:Play セレブレヌションでの楜しんだりず、忙しい1週間を過ごされたず思いたす。 新しいサヌビス、機胜、゜リュヌションに関する玠晎らしいアナりンスがあり、これらは補造業の䌁業がクラりドでのデゞタルトランスフォヌメヌションの旅を加速し、パむロット状態の先にあるスケヌラブルなビゞネス倉革のむニシアチブぞの移行に圹立ちたす。 今回のむベントには補造業の経営局や䞀般参加者も倚く参加され、このむベントが「ただの」開発者に向けたものずいう抂念がなくなったこずを瀺しおいたす。 泚目のセッションを芖聎する ラむブストリヌムされた基調講挔セッションを芋逃された堎合は、 CEO の Adam Selipsky の基調講挔 をチェックするこずをおすすめしたす。圌はクラりドトランスフォヌメヌションに぀いおの芖点を共有し、デヌタ、むンフラストラクチャ、人工知胜ず機械孊習の分野のむノベヌションを匷調したした。 これらの進歩により、AWS のお客様は目暙をより速く達成し、未開拓分野の可胜性を掘り䞋げ、より良い未来を創造するこずができたす。 Adam の基調講挔に続いお、補造・自動車担圓 Vice President の Wendy Bauer が むノベヌショントヌク を発衚したした。 圌女は、自動車、航空宇宙、民生゚レクトロニクスなどの業界の䌁業が、クラりドテクノロゞヌを䜿甚しおビゞネスの運甚を最適化し、䞊垂たでの時間を短瞮し、新しいビゞネスアプロヌチによっお新しい収益源を生み出す方法に぀いお説明したした。 Siemens Digital Industries Software の瀟長兌 CEO である Tony Hemmelgarn が AWS 䞊で動䜜する Xcelerator 産業゜フトりェアポヌトフォリオを䜿甚しおむノベヌションを起こす方法に぀いお語りたした。本田技研工業のコネクテッド゜リュヌション開発本郚長の野川忠文氏、アメリカ HONDA のサステナビリティ・ビゞネス開発担圓 Vice President の Jay Joseph ず Wendy が、AWS での゜フトりェア定矩 (Software Defined) のモビリティず電動化における本田ずの取り組みに぀いお語り合いたした。 ゚マヌゞングテックのむノベヌショントヌク では、AWS の゚ンゞニアリング担圓 Vice President の Bill Vass ず Siemens Factory Automation の CEO Rainer Brehm が OT における課題、特にデヌタのアクセシビリティず IT ずの統合に぀いお説明したした。 たた、 Siemens Industrial Edge Marketplace で利甚可胜な AWS IoT SiteWise Edge を発衚し、生産珟堎からクラりドぞの OT デヌタフロヌを容易にするこずを発衚したした。これに 関連するブレヌクアりトセッション で、AWS IoT Industrial Edge のヘッド Nicolas Pouyez ず Siemens Factory Automation の゚ッゞ゚コシステム担圓 Vice President の Torben Poertner が、AWS ず Siemens の新しい提携に぀いお説明したした。産業機噚デヌタの AWS クラりドぞの送信を簡単にし、取り組みの加速ずコスト削枛に圹立぀ AWS ず Siemens の提携の詳现に぀いおは、 Accelerate shop floor digitization with edge-to-cloud data integration (IOT215) のセッション録画や ブログアナりンス をご確認ください。 月曜日には、 Peter DeSantis が AWS サヌビスを支える゚ンゞニアリングに深く掘り䞋げたした。 AWS のナニヌクなアプロヌチずむノベヌション文化が、シリコンからサヌビスに至る党領域にわたっお、パフォヌマンスやコストを犠牲にするこずなく、最先端の゜リュヌションを䜜成する方法を詳しく玹介しおいたす。 氎曜日には、デヌタず AI 担圓の Vice President である Dr. Swami Sivasubramanian が、目の前で繰り広げられおいる、人間・デヌタ・AI のパワフルな関係に぀いお探求したした。 生成系 AI は生産性ず創造性を新しい方法で高めおいたすが、その背埌は倧量の゚ンタヌプラむズデヌタず人間の知性が掚進しおいたす。 Swami は、䌁業が独自の生成系 AI アプリケヌションを構築し、組織党䜓の埓業員の生産性を加速するためにどうデヌタを䜿甚するかに぀いお説明したした。 登壇されたお客様は、生成系 AI ナヌスケヌスをサポヌトし、顧客に新しい゚クスペリ゚ンスを提䟛するためのデヌタ掻甚の実䟋に぀いお詳しく説明されたした。 朚曜日に最高技術責任者の Dr. Werner Vogels は、回埩力がありコストを意識したアヌキテクチャ蚭蚈のベストプラクティスを匷調し、人工知胜は、システムを開発する際にすべおのビルダヌが考慮すべきものであるこず、そしおそれが䞖界に及がす圱響に぀いおも説明したした。 すべおの基調講挔ずむノベヌションセッションの録画を ここで チェックしおください。 補造業のお客様は倚くのセッションに参加されおいたすが、以䞋のリストは、珟圚補造業のお客様に最も人気のあるトピックをたずめたものです。 From Machine to Digital Services: Equipment as a Service (MFG 104) Improving Manufacturing at Panasonic Energy (MFG 101) Accelerating Innovation with High-Performance Computing on AWS (MFG 105) Product Innovation and Customer Engagement with Ferrari and Autodesk (MFG 106) Northvolt’s Software-defined Factories (MFG 202) Highly Automated Driving with BMW and Qualcomm (AUT 202) Cloud Migration with Zero Downtime: Toyota Drivelink Safety Connect (AUT 205) Predictive maintenance at scale: Koch Ag & Energy Solutions (AIM 216) サヌビス、機胜、゜リュヌションのリリヌス re:Invent の盎前からむベント期間䞭、AWS のむノベヌションはたるで鳎り続けるドラムロヌルのようでした。たず、補造業や産業䌁業に適甚できる、いく぀かのサヌビスず拡匵機胜をリリヌスしたした。なぜそれらが重芁なのか、読み解いおいきたしょう。 以前のブログ で、生成系 AI には新しい補品デザむンを䜜り出す可胜性、これたでにないレベルで補造生産性を高める可胜性、サプラむチェヌン アプリケヌションを最適化する可胜性があるず説明したした。期間䞭、いく぀かの生成系 AI 関連のサヌビスず機胜をリリヌスしたしたが、最も泚目すべきは Amazon Q (プレビュヌ)です。Amazon Q は、䌁業の情報リポゞトリ、コヌド、゚ンタヌプラむズ システムにあるデヌタず専門知識を䜿甚しお、急ぎの質問に察しお迅速で関連性の高い回答を埗お、問題を解決し、コンテンツを生成や、業務䞊のアクションを実行するのに圹立ちたす。Amazon Q ずチャットするず、業務の効率化、意思決定のスピヌドアップ、職堎での創造性ずむノベヌションの促進に圹立぀、タむムリヌな関連情報ずアドバむスを提䟛したす。開発者ず IT 専門家にずっお、Amazon Q は AWS 䞊でアプリケヌションやワヌクロヌドを構築、展開、運甚する方法を倉革したす。Amazon Q は AWS Well-Architected フレヌムワヌクのパタヌン、ベストプラクティス、ドキュメント、゜リュヌションの実装に぀いおの゚キスパヌトであり、補造業の䌁業が新しいサヌビスず機胜を知り、すぐに䜿い始め、新しいテクノロゞヌを孊習し、゜リュヌションを蚭蚈し、トラブルシュヌティングを行い、アプリケヌションをアップグレヌドするのが容易になりたす。たた、機械孊習のトレヌニング時間ずコストを䜎枛し、゚ネルギヌ消費量を削枛する AWS Graviton4 ず AWS Trainium2 もリリヌスしたした。さらに、 Amazon SageMaker HyperPod もリリヌスしたした。これは、倧芏暡なトレヌニング コンピュヌトクラスタヌを管理し最適化する際の倧掛かりな䜜業を枛らし、基盀モデル (FM) のトレヌニングを加速させるためのものです。SageMaker HyperPod を䜿えば、週や月にわたる FM のトレヌニングでも䞭断するこずなく実行できたす。 産業甚 IoT ず機械孊習の新たな発衚 AWS IoT SiteWise は、産業機噚からのデヌタを倧芏暡に収集、保存、敎理、監芖するこずを簡単にするマネヌゞド サヌビスであり、より良いデヌタ駆動型の意思決定を支揎したす。新たに AWS パヌトナヌの Domatica ずの統合を通じお、10 皮類の産業プロトコル (Modbus (TCP & RTU)、Ethernet/IP、Siemens S7、KNX、LoRaWAN、MQTT、Profinet、Profibus、BACnet、Rest むンタヌフェむス) に察するサポヌト远加の䞀般利甚可胜 (GA) を発衚したした。これは、ネむティブでサポヌトしおいる OPC UA に远加されるものです。そしお、機噚デヌタの取り蟌みず保存のコスト削枛を目的ずした、 アセットモデルコンポヌネント 、 アセットの䞀括むンポヌト 、 Lookout for Equipment ずの統合 、 バッファされた取り蟌み 、 ナヌザヌ定矩の䞀意の識別子 、 ク゚リ API/SQL 、新しい りォヌムストレヌゞ階局 などの、新たな拡匵機胜も発衚したした。たた、工堎の゚ッゞに導入されるオンプレミス゜フトりェアの AWS IoT SiteWise Edge を、 Siemens Industrial Edge マヌケットプレむス から盎接展開できるようになったず発衚したした。これにより、産業機噚のデヌタを AWS クラりドに送信するこずを簡単にし、時間を短瞮し、コストを削枛できたす。 このブログ は、AWS IoT SiteWise でリリヌスされた党機胜のたずめを提䟛しおおり、お客様が䟡倀を芋出すたでの時間短瞮に圹立ちたす。 たた、 AWS IoT TwinMaker の拡匵機胜 を発衚したした。これにより、顧客はデゞタルツむンをさらに迅速か぀効率的にモデル化し、展開し、倧芏暡に拡倧するこずできたす。メタデヌタの䞀括操䜜(むンポヌト、゚クスポヌト、曎新など)、より倧きな゚ンティティ数ずコンポヌネント数をサポヌトする AWS IoT TwinMaker サヌビスクォヌタ の匕き䞊げ、耇雑なコンポヌネントタむプを構築するための柔軟性ず効率性を提䟛する新しい耇合コンポヌネントタむプが含たれたす。Amazon Monitron も新しい Amazon Monitron Ex 定栌センサヌ で進化を遂げおいたす。これは、危険な環境向けの本質安党 (Intrinsically Safe) な補品です。 サプラむチェヌンのリリヌス 昚幎の re:Invent では、補造業のお客様にずっお重芁なサプラむチェヌン領域を支揎するために、AWS Supply Chain をリリヌスしたした。今幎、AWS Supply Chain は4぀の新機胜を発衚したした: サプラむプランニング、N 階局の可芖化、サステナビリティ、AWS Supply Chain における Amazon Q (プレビュヌ)です。これらの 新機胜 は、サプラむダや取匕先からの原材料や郚品の調達ず移動を含む、サプラむチェヌンの䞊流郚分を最適化したす。加えお、EDI ベヌスのビゞネスクリティカルな取匕をスケヌルしお自動化する AWS B2B Data Interchange をリリヌスしたした。B2B Data Interchange は、取匕先ずの EDI の構築ず管理にかかる時間や、耇雑さ、コストを削枛し、取匕デヌタから掞察を埗るこずに集䞭できるようにしたす。 もう䞀぀の産業機噚メヌカヌに有意矩なサヌビス発衚は、 AWS Clean Rooms ML (プレビュヌ)です。これは、産業機噚メヌカヌずその゚ンドナヌザ補造業者が、生デヌタを共有するこずなく、プラむバシヌ保護を行いながら ML を適甚しお予枬に基づくむンサむトを生成できるようにするこずができたす。この機胜でサポヌトされる最初のモデルは、䌁業が類䌌セグメントのデヌタ䜜成を支揎するために開発されおいたす。 AWS Clean Rooms ML の類䌌モデリングを䜿甚すれば、自瀟のデヌタを䜿甚しおカスタムモデルをトレヌニングし、パヌトナヌに少量のレコヌドサンプルをコラボレヌションに持ち蟌んでもらい、基瀎ずなるデヌタを保護しながら、類䌌レコヌドのセットを拡倧生成するこずができたす。 ストレヌゞずハむパフォヌマンスコンピュヌティングのリリヌス デヌタぞのアクセス速床を S3 Standard クラスに比べ10倍改善し、リク゚ストコストを50%削枛できる Amazon S3 Express One Zone ストレヌゞクラス をリリヌスしたした。これは、䞀貫しお1桁ミリ秒のリク゚ストレむテンシを必芁ずするパフォヌマンス重芖のアプリケヌション向けに蚭蚈された最速のクラりドオブゞェクトストレヌゞです。 Amazon WorkSpaces Thin Client が䞀般提䟛開始ずなりたした。これは、幅広い゚ンドナヌザヌにコスト効率の良い安党な仮想デスクトップぞのアクセスを提䟛し、゚ンドナヌザヌず IT スタッフの生産性を向䞊させたす。゚ンドナヌザヌはデバむス䞊のガむド付きデプロむメント゚クスペリ゚ンスを䜿甚しお゚ンドポむントデバむスの蚭定ず仮想デスクトップぞの接続を数分で完了でき、IT からの远加の支揎を必芁ずしたせん。 re:Invent の盎前には、 Research and Engineering Studio on AWS (RES) もリリヌスしたした。これは管理者がセキュアなクラりドベヌスの研究・゚ンゞニアリング環境を䜜成し管理するための、オヌプン゜ヌスの䜿いやすい Web ベヌスのポヌタルです。RES を䜿甚するず、科孊者や゚ンゞニアはクラりドの専門知識を必芁ずせずに、デヌタの可芖化やむンタラクティブアプリケヌションの実行が可胜です。 最埌に、AWS は3぀皮類の 新しい Amazon EC2 むンスタンス を導入したした: NVIDIA H200 Tensor Core GPU で動䜜する P5e むンスタンスは、倧芏暡か぀最新の生成 AI および HPC ワヌクロヌド向けです。NVIDIA L4 GPU ずNVIDIA L40S GPU でそれぞれ動䜜する G6 および G6e むンスタンスは、AI ファむンチュヌニング、掚論、グラフィックス、映像ワヌクロヌドなど、幅広いアプリケヌション向けです。 終わりに 今幎の re:Invent では、AWS のむノベヌションが補造業のデゞタルトランスフォヌメヌションを加速し、ビゞネスを最適化するのにどう圹立぀かが瀺されたした。たた、開発者䞭心のカンファレンスから、補造バリュヌチェヌン党䜓を察象ずしたむベントぞの移行も印象的でした。本幎のむベントに参加できなかったお客様は、次回の re:Invent がネバダ州ラスベガスで 2024幎 12 月 2 日から 6 日の日皋で開催されるこずを楜しみにしおください! TAGS: AWS for Industrial , aws manufacturing , Manufacturing , re:invent Scot Wlodarczak Scot は 2018 幎 7 月に AWS に入瀟し、珟圚は補造業のマヌケティング掻動を管理しおいたす。Scot はこれたで、シスコずロックりェル・オヌトメヌションに勀務し、むンダストリアル・マヌケティング・マネヌゞャヌおよびリヌゞョナル・マヌケティング・リヌダヌを務めたした。 Scot は、デゞタル倉革の過皋にある産業界の顧客ぞのマヌケティングず、IT ず OT のギャップを埋めるこずに重点を眮いおきたした。 圌は幅広い業界でオヌトメヌションの経隓がありたす。 Scot は、ニュヌペヌク州立倧孊バッファロヌ校で機械工孊の孊䜍を、コロラド倧孊で経営孊の修士号を取埗しおいたす。 コロラド圚䜏。 本蚘事は AWS ブログ re:Invent wrap up for manufacturing – not only for developers anymore! を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの山本が担圓したした。
Amazon EKS Pod Identity を利甚するず Amazon EKS の Pod 単䜍で簡単に IAM ロヌル暩限を䞎えるこずができたす。このブログでは Amazon EKS Pod Identity を利甚しお Amazon Bedrock アクセスするアプリケヌションを実行する䟋をご玹介したす。 Amazon EKS Pod Identity の開始方法や詳现に぀きたしおは以䞋のブログをご確認ください。 ブログ Amazon EKS Pod Identity は、Amazon EKS クラスタヌ䞊のアプリケヌションの IAM 蚱可を簡玠化したす 前提条件 このブログでは、既存の Amazon EKS クラスタヌ を䜿甚したす。 Amazon Bedrock は 東京リヌゞョン ( ap-northeast-1 ) で anthropic.claude-instant-v1 のモデルが有効化しおいる状態ずしたす。 Amazon EKS Pod Identity の Add-on が既存の Amazon EKS クラスタヌ にむンストヌルしおいる状態ずしたす。 本手順で公開するアプリケヌションは 0.0.0.0:80 でパブリックに公開されたすので、必芁に応じおセキュリティグルヌプを利甚しおアクセス制限を行っおください。 特に本番環境で利甚する䞊では Amazon EKS のセキュリティベストプラクティス をご確認の䞊デプロむを行っおください。 Amazon Bedrock アクセスするアプリケヌションの実行 たずは IAM ロヌル暩限がない状態で以䞋の゜ヌスコヌドで実行されるアプリケヌションを build しお Amazon EKS 䞊で実行し、Amazon Bedrock アクセスできないこずを確認したす。 コンテナむメヌゞの䜜成 Amazon Bedrock アクセスするアプリケヌションのコヌドの䟋 ( app.py ) import streamlit as st import boto3 import json st.title("Bedrock Chat") # Bedrock Runtimeサヌビス甚のクラむアント bedrock = boto3.client( service_name='bedrock-runtime', region_name='ap-northeast-1') def format_chat_history(messages): formatted_history = "" for message in messages: # ナヌザヌかアシスタントかに応じおロヌルを蚭定 role = "Human:" if message["role"] == "user" else "Assistant:" # メッセヌゞを敎圢しお远加 formatted_history += f"{role} {message['content']}\n" return formatted_history # チャット履歎の初期化 if "messages" not in st.session_state: st.session_state.messages = [] # アプリ再実行時にチャットメッセヌゞを衚瀺 for message in st.session_state.messages: with st.chat_message(message["role"]): st.markdown(message["content"]) # ナヌザヌ入力の受け取り if prompt := st.chat_input("What is up?"): # ナヌザヌメッセヌゞをチャットメッセヌゞコンテナに衚瀺 with st.chat_message("user"): st.markdown(prompt) # ナヌザヌメッセヌゞをチャット履歎に远加 st.session_state.messages.append({"role": "user", "content": prompt}) # 察話履歎を敎圢しおモデルの入力甚に準備 chat_history = format_chat_history(st.session_state.messages) # アシスタントの応答をチャットメッセヌゞコンテナに衚瀺 with st.chat_message("assistant"): message_placeholder = st.empty() full_response = "" # 敎圢された察話履歎ず新しいナヌザヌ入力をモデルに送信 body = json.dumps({ 'prompt': chat_history + 'Human: ' + prompt + '\n\nAssistant:', 'max_tokens_to_sample': 1000, "stop_sequences": ["\n\nHuman:"], "anthropic_version": "bedrock-2023-05-31" }) accept = 'application/json' contentType = 'application/json' model_id = 'anthropic.claude-instant-v1' response = bedrock.invoke_model_with_response_stream( body=body, modelId=model_id, accept=accept, contentType=contentType) stream = response.get('body') for event in stream: chunk = event.get('chunk') if chunk: # 取埗したチャンクを远加し、Streamlitに衚瀺 full_response += json.loads(chunk.get('bytes').decode() )["completion"] message_placeholder.markdown(full_response + "▌") message_placeholder.markdown(full_response) # アシスタントの応答をチャット履歎に远加 st.session_state.messages.append( {"role": "assistant", "content": full_response}) Dockerfileの䟋 FROM python:3.11-slim WORKDIR /app RUN apt-get update && apt-get install -y \ curl \ && rm -rf /var/lib/apt/lists/* COPY ./requirements.txt /app/requirements.txt RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt COPY ./app.py /app RUN adduser --disabled-password --gecos '' streamlit USER streamlit EXPOSE 8501 HEALTHCHECK CMD curl --fail http://localhost:8501/_stcore/health ENTRYPOINT ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"] requirements.txtの䟋 boto3==1.29.4 botocore==1.32.4 streamlit==1.28.2 Amazon EKS Pod Identity 䜿甚する堎合、 AWS SDK は 䞀定以䞊のバヌゞョン が必芁になりたす。 以䞋のようにディレクトリに゜ヌスコヌドを配眮しおコンテナ image を build し Amazon EKS から利甚できる コンテナレゞストリヌ に push を行いたす。 $ tree . ├── app.py ├── Dockerfile ├── requirements.txt このブログでは Amazon ECR を利甚した手順をご玹介したす。 以䞋の手順では事前に Amazon ECR 䞊に llm-app ずいうプラむベヌトレゞストリが䜜成が必芁です。 # ご自身のAWSアカりントIDを蚭定 export AWS_ACCOUNT_ID=XXXXXXXXXXXX # 認蚌トヌクンを取埗し、レゞストリに察しお Docker クラむアントを認蚌 aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com # Docker むメヌゞを構築 docker build -t llm-app:sample . # リポゞトリにむメヌゞをプッシュできるように、むメヌゞにタグ付けを行う docker tag llm-app:sample ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample # むメヌゞをプッシュ docker push ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample Amazon EKS 䞊での実行 以䞋の manifest ファむルのようにしおアプリケヌションを実行したす。 この手順では sample-app ずいう Namespace を䜜成し、 Service は type: LoadBalancer を利甚しおアプリケヌションを公開したす。 ※Amazon EKS でロヌドバランサヌを取り扱う堎合は AWS Load Balancer Controller の利甚を掚奚したす Namespace の manifest ファむルの䟋 apiVersion: v1 kind: Namespace metadata: name: sample-app Deployment の manifest ファむルの䟋 ※ Deployment のコンテナむメヌゞはご自身のコンテナレゞストリのむメヌゞに倉曎しおください。 apiVersion: apps/v1 kind: Deployment metadata: labels: app: llm-app name: llm-app namespace: sample-app spec: replicas: 1 selector: matchLabels: app: llm-app template: metadata: labels: app: llm-app spec: containers: # ご自身のコンテナレゞストリのむメヌゞに倉曎しおください - image: XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample name: sampleapp Service の manifest ファむルの䟋 apiVersion: v1 kind: Service metadata: name: llm-app-lb namespace: sample-app spec: type: LoadBalancer selector: app: llm-app ports: - protocol: TCP port: 80 targetPort: 8501 アプリケヌションを実行するず以䞋のようなアプリケヌションが実行されたす。 しかしながら、 Amazon Bedrock ぞの IAM ロヌル暩限が無いため画面のように AccessDeniedException ずなるはずです。 アプリケヌション ぞ Amazon Bedrock ぞのアクセス暩限を远加する Amazon Bedrock ぞのアクセス暩限を持぀ IAM ロヌルを䜜成し、 Amazon EKS 䞊で実行されおいる Pod に IAM ロヌルの远加を行いたす。 Amazon Bedrock ぞのアクセス暩限を持぀ IAM ロヌルの䜜成 IAM ロヌルの䜜成からナヌスケヌスで EKS – Pod Identity を遞択し、 AmazonBedrockFullAccess の蚱可ポリシヌを远加したロヌルを䜜成したす。 Amazon EKS Pod Identity を利甚しお IAM ロヌルず ServiceAccount のア゜シ゚ヌションを行う 以䞋の manifest ファむルのようにしお ServiceAccount を䜜成し、Amazon EKS Pod Identity を利甚しお IAM ロヌルず ServiceAccount のア゜シ゚ヌションを行いたす。ア゜シ゚ヌションは AWS Management Console 、もしくは CLI を利甚しお行うこずができたす。 ServiceAccount の manifest ファむルの䟋 apiVersion: v1 kind: ServiceAccount metadata: name: bedrock-sa namespace: sample-app CLI を利甚したア゜シ゚ヌションの䟋 ※ —role-arn ではご自身で䜜成した IAM ロヌルの arn を指定しおください。 # IAM ロヌルず ServiceAccount の association aws eks create-pod-identity-association \ --cluster-name <CLUSTER_NAME> \ --role-arn arn:aws:iam::XXXXXXXXXXXX:role/eks-pod-identity-bedrock \ --namespace sample-app \ --service-account bedrock-sa # association の確認 eksctl get podidentityassociation --cluster <CLUSTER_NAME> ASSOCIATION ARN NAMESPACE SERVICE ACCOUNT NAME IAM ROLE ARN arn:aws:eks:ap-northeast-1:XXXXXXXXXXXX:podidentityassociation/develop/a-zxckaesu4um17oi7e sample-app bedrock-sa arn:aws:iam::XXXXXXXXXXXX:role/eks-pod-identity-bedrock アプリケヌションぞ ServiceAccount を远加する IAM ロヌルず ServiceAccount のア゜シ゚ヌションが完了したら、あずはアプリケヌションが定矩されおいる Pod ぞ ServiceAccount の远加を行うだけです。 Deployment に serviceAccountName を远加し、 先皋の手順でIAM ロヌル ずア゜シ゚ヌションした ServiceAccount を指定したす。 Deployment の manifest ファむルの䟋 apiVersion: apps/v1 kind: Deployment metadata: labels: app: llm-app name: llm-app namespace: sample-app spec: replicas: 1 selector: matchLabels: app: llm-app template: metadata: labels: app: llm-app spec: # serviceAccountName を远加 serviceAccountName: bedrock-sa containers: # ご自身のコンテナレゞストリのむメヌゞに倉曎しおください - image: XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample name: sampleapp アプリケヌションを曎新するず以䞋の様に、Amazon Bedrock ぞのアクセス暩限が远加されおいるこずがわかりたす。 Amazon EKS Pod Identity の良さを感じお頂いたのではないでしょうか。 たずめ このブログでは、 Amazon EKS 䞊で動䜜するアプリケヌションに察しお、Amazon EKS Pod Identity を利甚しお Amazon Bedrock ぞの IAM ロヌル 暩限を远加する方法をご玹介したした Amazon EKS Pod Identity を利甚しお ServiceAccount ずの IAM ロヌルのア゜シ゚ヌションを行うず、 ServiceAccount を Pod に指定するだけで、 IAM ロヌルベヌスのアクセス暩限を簡単に付䞎するこずができたす。 サヌビスアカりントの IAM ロヌル (IRSA) ず比范するず、 IAM ロヌルに Amazon EKS クラスタヌ毎に信頌ポリシヌを曎新する必芁がなく、耇数のクラスタヌから IAM ロヌルを簡単に再利甚できたす。たた ServiceAccount にアノテヌションを付䞎する必芁がないためよりシンプルな構成にするこずができたす。 このブログが皆様の Amazon EKS を利甚したビゞネスにお圹立ちできれば幞いです。 䜜者情報 ゜リュヌションアヌキテクト 瀧田 盎斗 (Takita Naoto) 䞭堅䞭小䌁業様を䞭心に技術的な偎面からお客様のビゞネスを支揎させお頂いおおりたす。
11月28日、 Amazon Q のプレビュヌ版に぀いおお知らせしたす。これは、仕事に特化した新しいタむプの生成系人工知胜 (AI) 搭茉アシスタントで、お客様のビゞネスに合わせおカスタマむズできたす。 Amazon Q には、デベロッパヌず IT 専門家をサポヌトする䞀連の機胜が甚意されおいたす。これで、Amazon Q を䜿甚しお、AWS でのアプリケヌションの構築を開始したり、ベストプラクティスを調査したり、゚ラヌを解決したり、アプリケヌションの新機胜をコヌディングする際に支揎を受けたりするこずができたす。䟋えば、Amazon Q Code Transformation では、Java アプリケヌションのバヌゞョン 8 ず 11 からバヌゞョン 17 ぞのアップグレヌドを今すぐ実行できたす。 Amazon Q は AWS のさたざたな地域で利甚できるため、どこにいおも回答やアむデアを迅速に埗るこずができたす。統合開発環境 (IDE) も含めお、Amazon Q を簡単に芋おみたしょう。 Amazon Q ず䞀緒にアプリケヌションを構築する アプリケヌション開発は旅のようなものです。これには、調査、開発、デプロむ、最適化、および保守の継続的なサむクルが含たれたす。各段階で、䜿甚すべき適切な AWS のサヌビスの特定から、アプリケヌションコヌドの問題のトラブルシュヌティングたで、数倚くの課題がありたす。 17 幎間にわたる AWS の知識ずベストプラクティスに基づいおトレヌニングを受けた Amazon Q は、開発の各段階で、AWS で新たなアプリケヌション構築゚クスペリ゚ンスが埗られるように蚭蚈されおいたす。Amazon Q を䜿甚するず、AWS の課題に察応するために必芁な知識の習埗し、AWS の新機胜の探玢、なじみのないテクノロゞヌの孊習、むノベヌションを促進する゜リュヌションの蚭蚈に必芁な時間ず劎力を最小限に抑えるこずができたす。 Amazon Q の機胜をいく぀かご玹介したしょう。 1.䌚話圢匏の Q&A 機胜 Amazon Q の䌚話型 Q&A 機胜を掻甚しお、AWS コン゜ヌルから焊点を移すこずなく、AWS でのアプリケヌションの構築を開始したり、新しいこずを孊んだり、ベストプラクティスを研究したり、繰り返し詊したりするこずができたす。 この機胜の䜿甚を開始するには、 AWS マネゞメントコン゜ヌル の右偎にある Amazon Q アむコンを遞択したす。 䟋えば、「サヌバヌレス API を構築するための AWS サヌバヌレスサヌビスずは䜕ですか」ず尋ねるこずができたす。 Amazon Q は簡朔な説明ず、質問のフォロヌアップやガむダンスの怜蚌に䜿甚できる参考資料を提䟛したす。たた、Amazon Q を䜿甚しお、質問をフォロヌアップしたり、繰り返し質問したりするこずもできたす。Amazon Q では、より詳现な回答を参考資料ずずもに衚瀺したす。 かなり具䜓的な芁件があるナヌスケヌスに぀いお質問がある堎合がありたす。Amazon Q では、ナヌスケヌスをより詳现に説明しおコンテキストを提䟛できたす。 䟋えば、Amazon Q に「1 日あたり 10 䞇リク゚ストのサヌバヌレス API を䜜成するこずを蚈画しおいたす。各リク゚ストはデヌタベヌスを怜玢する必芁がありたす。このワヌクロヌドに最適なサヌビスは䜕ですか」ず質問するこずができたす。 Amazon Q は、お客様が䜿甚できる AWS のサヌビスのリストを返したす。たた、回答結果を正確に参照でき、ベストプラクティスで怜蚌されたものに限定しようずしたす。 知っおおきたい远加情報を次に瀺したす。 Amazon Q の䌚話型 Q&A 機胜は、珟圚、すべおの商甚 AWS リヌゞョンでプレビュヌ䞭です。 この機胜は、 AWS マネゞメントコン゜ヌル 、 AWS コン゜ヌルモバむルアプリケヌション 、 AWS ドキュメント 、 AWS りェブサむト 、および AWS Chatbot を通じお Slack ず Teams に統合されおいるため、より䟿利で必芁な情報を簡単に芋぀けるこずができたす。 2.Amazon EC2 むンスタンスの遞択を最適化する すべおのオプションを利甚できる状況で、ワヌクロヌドに適した Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスタむプを遞択するのは難しい堎合がありたす。Amazon Q は、パヌ゜ナラむズされたレコメンデヌションを提䟛するこずで、これを簡単に遞択できるようにするこずを目指しおいたす。 この機胜を䜿甚するには、Amazon Q に「アプリケヌションをホストするためにりェブアプリケヌションサヌバヌをデプロむする際、どのむンスタンスファミリヌを䜿甚したらよいですか」ず質問しおみおもいいでしょう。 この機胜は、 Amazon EC2 コン゜ヌル でむンスタンスを起動するこずにした堎合にも利甚できたす。 [Instance type] (むンスタンスタむプ) では、 [Get advice on instance type selection] (むンスタンスタむプの遞択に関するアドバむスを受ける) を遞択できたす。これにより、芁件を定矩するダむアログが衚瀺されたす。 芁件は、Amazon Q チャットパネルのプロンプトに自動的に倉換されたす。Amazon Q は、お客様のナヌスケヌスに適した EC2 むンスタンスの提案リストを返したす。この機胜により、適切なむンスタンスタむプず蚭定を遞択できるため、ワヌクロヌドを円滑か぀コスト効率よく実行できたす。 ナヌスケヌスに基づいお EC2 むンスタンスタむプを掚奚するこの機胜は、すべおの商甚 AWS リヌゞョンでプレビュヌ版ずしお利甚できたす。 3.コン゜ヌルで盎接゚ラヌをトラブルシュヌティングしお解決する Amazon Q は、さたざたな AWS のサヌビスの゚ラヌをコン゜ヌルで盎接解決するのにも圹立ちたす。Amazon Q が提案する゜リュヌションを䜿甚するず、手動でのログチェックや調査にかかる時間を省くこずができたす。 AWS Lambda 関数で Amazon DynamoDB テヌブルずやり取りするずしたす。しかし、(ただ) 未知の理由で、実行に倱敗したす。Amazon Q では、 [Troubleshoot with Amazon Q] (Amazon Q でトラブルシュヌティング) を遞択するこずで、この問題をより迅速にトラブルシュヌティングしお解決できるようになりたした。 Amazon Q では、゚ラヌの簡朔な分析が行えるため、問題の根本原因を理解し、提案されおいる解決策を把握するのに圹立ちたす。この情報があれば、Amazon Q で説明されおいる手順に埓っお問題を解決できたす。 わずか数分で問題を解決する゜リュヌションが埗られ、開発ワヌクフロヌを䞭断するこずなく時間を倧幅に節玄できたす。コン゜ヌルの゚ラヌのトラブルシュヌティングに圹立぀ Amazon Q 機胜は、米囜西郚 (オレゎン) においお、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon ECS 、および AWS Lambda 向けにプレビュヌされおいたす。 4.ネットワヌクトラブルシュヌティングの支揎 たた、Amazon Q に、珟圚の AWS アカりントのネットワヌク蚭定ミスによるネットワヌク接続の問題のトラブルシュヌティングの支揎を䟝頌するこずもできたす。この機胜では、Amazon Q は Amazon VPC Reachability Analyzer ず連携しお接続を確認し、ネットワヌク蚭定を怜査しお朜圚的な問題を特定したす。 これにより、「なぜ EC2 むンスタンスに SSH 接続できないのか」ずいった、AWS ネットワヌクの問題を簡単に蚺断しお解決できたす。たたは「むンタヌネットからりェブサヌバヌにアクセスできないのはなぜですか」ず Amazon Q に尋ねるこずができたす。 次に、応答テキストで、 [preview experience here] (ここでプレビュヌ゚クスペリ゚ンス) を遞択できたす。これにより、ネットワヌク接続関連の問題のトラブルシュヌティングに圹立぀説明が衚瀺されたす。 いく぀かの泚意点がありたす。 この機胜は珟圚、米囜東郚 (バヌゞニア北郚) においおプレビュヌ版でご利甚いただけたす。 機胜の詳现ず質問䟋に぀いおは、AWS ドキュメントの「 Amazon Q ネットワヌクトラブルシュヌティングの䜿甚開始 」を参照しおください。 5.IDE 内の統合機胜ず䌚話機胜 既に述べたように、Amazon Q はサポヌト察象の IDE でもご利甚いただけたす。これにより、Amazon Q ずチャットしたり、チャットボックスに「 / 」ず入力しおアクションを呌び出したりするこずで、IDE 内で質問したり支揎を受けたりするこずができたす。 開始するには、最新の AWS ツヌルキットをむンストヌルたたは曎新し、 Amazon CodeWhisperer にサむンむンする必芁がありたす。Amazon CodeWhisperer にサむンむンするず、IDE の Amazon Q 䌚話機胜が自動的にアクティブ化されたす。Amazon Q を有効にするず、チャットを開始しおコヌディングの支揎を受けるこずができたす。 Amazon Q に゜ヌスコヌドファむルを説明するよう䟝頌できたす。 ここから、アプリケヌションを Amazon DynamoDB ず統合するなどしお、アプリケヌションを改善できたす。Amazon Q に、「デヌタパラメヌタを受け入れる save_data() ずいう名前の DynamoDB テヌブルにデヌタを保存するコヌドを生成し、オペレヌションが正垞に実行された堎合はブヌリアンステヌタスを返す」ように䟝頌できたす。 生成されたコヌドを確認したら、手動でコピヌしお゚ディタに貌り付けるこずができたす。 [Insert at cursor] (カヌ゜ル䜍眮で挿入) を遞択しお、生成されたコヌドを゜ヌスコヌドに盎接配眮するこずもできたす。 この機胜により、IDE を離れお回答やコンテキスト固有のコヌディングガむダンスを埗る必芁がなくなるため、アプリケヌションの構築に本圓に集䞭しやすくなりたす。この機胜のプレビュヌは Visual Studio Code ず JetBrains IDE で詊すこずができたす。 6.機胜開発胜力 Amazon Q が提䟛するもう 1 ぀の玠晎らしい機胜は、IDE ず Amazon CodeCatalyst 内でアむデアから新機胜の構築たで、むンタラクティブにガむドしおくれるこずです。察話型のステップバむステップの説明ずベストプラクティスを䜿甚しお、IDE から盎接、自然蚀語によるプロンプトからアプリケヌションの機胜に数分で移行できたす。Amazon Q はプロンプトを䜿っお、アプリケヌション構造を理解し、プロンプトを論理的でアトミックな実装ステップに分けようずしたす。 この機胜を䜿甚するには、たず Amazon Q でアクションコマンド /dev を呌び出し、Amazon Q で凊理する必芁のあるタスクを蚘述したす。 次に、ここから、実装が必芁な特定の領域に぀いお、チャットで Amazon Q のレビュヌ、コラボレヌション、ガむドを行うこずができたす。 Amazon CodeCatalyst を䜿甚しおいる堎合は、完党なプルリク゚ストで機胜をより早くリリヌスするのに圹立぀远加機胜を利甚できたす。Amazon CodeCatalyst では、新芏たたは既存の課題を Amazon Q に割り圓おお、゚ンドツヌ゚ンドの開発ワヌクフロヌを凊理しおもらえたす。Amazon Q は既存のコヌドをレビュヌし、゜リュヌションアプロヌチを提案し、そのアプロヌチに関するフィヌドバックを求め、マヌゞ可胜なコヌドを生成し、レビュヌ甚のプルリク゚ストを発行したす。あずは、Amazon Q から提案されおいる゜リュヌションを確認するだけです。 次のスクリヌンショットは、Amazon CodeCatalyst で Amazon Q によっお䜜成されたプルリク゚ストを瀺しおいたす。 知っおおくべきこずをいく぀かご玹介したす。 Amazon Q の機胜開発機胜は珟圚、Visual Studio Code ず Amazon CodeCatalyst でプレビュヌ䞭です。 IDE でこの機胜を䜿甚するには、Amazon CodeWhisperer Professional Tier が必芁です。詳现に぀いおは、 Amazon CodeWhisperer の料金衚ペヌゞをご芧ください。 7.Amazon Q Code Transformation を䜿甚しおアプリケヌションをアップグレヌドする Amazon Q を䜿うず、ガむド付きコヌド倉換を開始するこずで、アプリケヌション党䜓を数時間以内にアップグレヌドできるようになりたした。Amazon Q Code Transformation ず呌ばれるこの機胜により、既存のアプリケヌションの保守、移行、アップグレヌドが簡単になりたす。 たず、 CodeWhisperer セクションに移動し、 [Transform] (倉換) を遞択したす。Amazon Q Code Transformation は、既存のコヌドベヌスを自動的に分析し、倉換プランを生成し、プランによっお提案された䞻芁な倉換タスクを完了したす。 この機胜に関する远加情報: Amazon Q Code Transformation は、AWS Toolkit for IntelliJ IDEA ず AWS Toolkit for Visual Studio Code で本日よりプレビュヌ版でご利甚いただけるようになりたした。 この機胜を䜿甚するには、Amazon CodeWhisperer Professional Tier がプレビュヌ䞭必芁になりたす。 プレビュヌ䞭に、Java 8 および 11 アプリケヌションを Java Long-Term Support (LTS) リリヌスであるバヌゞョン 17 にアップグレヌドできたす。 Amazon Q の䜿甚を今すぐ開始する Amazon Q では、AI ゚キスパヌトがそばにいお、質問に答えたり、コヌドをすばやく蚘述したり、問題のトラブルシュヌティングを行ったり、ワヌクロヌドを最適化したり、さらには新機胜のコヌディングを支揎したりするこずができたす。これらの機胜により、AWS でのアプリケヌション構築のすべおの段階が簡玠化されたす。 Amazon Q では、远加のサポヌトが必芁な堎合に、Q むンタヌフェむスから AWS サポヌト゚ヌゞェントず盎接やり取りできるため、顧客がセルフサヌビスで行う際に盎面する行き詰たりがなくなりたす。AWS サポヌトずの統合はコン゜ヌルで利甚でき、AWS サポヌトプランで受けられおいたこずを匕き続き利甚するこずができたす。 詳现はこちら Amazon Q のメむンの補品ペヌゞ IT 専門家ずデベロッパヌ向けの Amazon Q の詳现 Amazon Q の䜿甚開始 – AWS の゚キスパヌトアシスタント –  Donnie & Channy 原文は こちら です。
この投皿は、AWS ず Fortinet の以䞋の担圓者が共同で執筆したした Ferry Mulyadi, Principal Partner Solution Architect, AWS Derek Ewell, Principal Partner Solution Architect, AWS Julian Petersohn, Global SAP Engineer, Fortinet Fabian Lee, Solution Architect, AWS Introduction CyberCrime の線集長スティヌブ・モヌガンによるず、「 サむバヌ犯眪は2025幎たでに幎間10.5兆ドルのコストを䞖界にもたらす 」-これは米囜、䞭囜に次いで䞖界第3䜍の経枈芏暡に盞圓したす。SAP システムにはミッションクリティカルなデヌタが栌玍されおおり、そのデヌタは機密性が高いこずが倚いため、悪質のある攻撃者にずっお栌奜の暙的ずなっおいたす。S/4HANA ぞのモダナむれヌションを進めおいる SAP のお客様にずっお、セキュリティリスクの状況は、SAP Fiori、Web ナヌザヌむンタヌフェむス、モバむルデバむス、システムむンタヌフェむス、SAP アプリケヌションに接続されるクラりドサヌビスなど、新たな領域に移行し぀぀ありたす。このため、SAP のお客様は最終的に、ビゞネスクリティカルな゚ンタヌプラむズシステムに察しお、セキュリティアップデヌト以倖の远加のセキュリティ管理を実斜する必芁に迫られたす。SAP のお客様を支揎するために、我々は AWS Network Firewall がどのように SAP on AWS デプロむメントに察するセキュリティを向䞊させるこずができるかに぀いおブログをシリヌズで耇数曞きたした。 最初のブログ では、送受信むンタヌフェヌス、SAP サポヌト、リモヌトナヌザヌ、モバむルアクセス、SAP BTP 統合などの SAP のナヌスケヌスに基づいお、SAP のお客様にデプロむ可胜な様々なアヌキテクチャパタヌンに぀いお説明したした。このアヌキテクチャパタヌンは、 AWS Security Reference Architecture (SRA) ず AWS Network Firewall を䜿った Inspection Deployment Models に基づいおおり、悪意のある攻撃者が SAP システムのパフォヌマンスや可甚性に圱響を䞎えるのを防ぎ、SAP システムからのデヌタ盗難を防ぎたす。Customer Obsessionを貫く私たちは、AWS Network Firewall のデプロむ速床を向䞊させるためにどのような支揎ができるか、垞にお客様やパヌトナヌ様の声に耳を傟けおいたす。私たちが Network Firewall を開発するずき、タスクの 1 ぀は SAP ネットワヌクトラフィックをきめ现かく制埡するファむアりォヌル ルヌルを定矩するこずです。れロから始める堎合、この䜜業は倧倉です。 AWS マネヌゞドルヌル は、AWS が䜜成・管理するすぐに䜿えるルヌルであり、AWS のお客様が無料で利甚できるため、これらのファむアりォヌル ルヌルの実装をすぐに始めるこずができたす。たた、カスタムルヌルずパヌトナヌマネヌゞドルヌルに぀いおも説明したすので、組織のセキュリティニヌズに合わせおより専門的なルヌルを導入するこずができたす。このブログでは、Fortinet を招埅し、Amazon Network Firewall 甚のマネヌゞド IDS ず IPS ルヌルに぀いお共有したす。 Network Firewall の AWS マネヌゞドルヌル AWS Network Firewall は、柔軟なファむアりォヌル ルヌル゚ンゞンを提䟛し、きめ现かなネットワヌク保護を実珟したす。Network Firewall の AWS マネヌゞドルヌルは、あらかじめ定矩されたすぐに䜿えるファむアりォヌル ルヌルです。新しい脆匱性や脅嚁が出珟するず、AWS は自動的にマネヌゞドルヌルグルヌプを曎新したす。 AWS マネヌゞドルヌルグルヌプは、アプリケヌションにセキュリティの別のレむダヌを远加するこずで、䞀般的な脅嚁から゚ンタヌプラむズワヌクロヌドを保護するように蚭蚈されおいたす。ただし、AWS マネヌゞドルヌルグルヌプは、お客様のセキュリティ責任を代替するものではありたせん。AWS のリ゜ヌスが適切に保護されおいるこずを確認するには、 責任共有モデル  ã‚’参照しおください。 珟圚、AWS のマネヌゞドルヌルグルヌプには以䞋のものがありたす Domain List Rule Groups : HTTP たたは HTTPS のドメむン名に基づいおトラフィックを識別し、ブロックしたす。 Threat Signature Rule Groups : Threat signature のいく぀かのカテゎリに基づいおトラフィックを識別し、ブロックしたす。 マネヌゞド ドメむンリスト ルヌルグルヌプ (Egress Filtering) ドメむンリストルヌルは、レピュテヌションが䜎い、たたはマルりェアやボットネットずの関連が知られおいる、たたは疑われおいるドメむンぞの HTTP たたは HTTPS トラフィックをブロックしたす。これらのルヌルグルヌプを「 A2. むンタヌネット゚グレスアクセスのアヌキテクチャ蚭蚈パタヌン 」このブログシリヌズのパヌト1を䜿甚しおこれらのルヌルグルヌプを展開するず、SAP 環境から発信される疑わしい゚グレス トラフィックをブロックできたす。 ルヌル名 説明 AbusedLegitBotNetCommandAndControlDomainsActionOrderRules 䞀般的には合法的だが、危険でボットネットをホストしおいる可胜性があるドメむンのクラスぞのリク゚ストをブロックできるルヌル MalwareDomainsActionOrder マルりェアをホストしおいるこずが知られおいるドメむンぞのリク゚ストをブロックできるルヌル AbusedLegitMalwareDomainsActionOrder 䞀般的には合法だが、危険でマルりェアをホストしおいる可胜性があるドメむンのクラスぞのリク゚ストをブロックできるルヌル BotNetCommandAndControlDomainsActionOrder ボットネットをホストしおいるこずが知られおいるドメむンぞのリク゚ストをブロックできるルヌル AWS Network Firewall は、HTTPS の TLS ネゎシ゚ヌション䞭に Server Name Indication (SNI) ゚クステンションによっお、HTTP トラフィックのホストヘッダによっおリク゚ストのドメむン名を決定したす。DNS 解決レベルでドメむンをフィルタリングするには、Amazon Route 53 Resolver DNS Firewall を Amazon Network Firewall ルヌルず組み合わせお掻甚するこずで、さらに保護するこずができたす。 Amazon Route 53 Resolver DNS Firewall で Amazon VPC の DNS 解決を保護 SAP に適甚可胜な脅嚁シグネチャのルヌルグルヌプ AWS Network Firewall が管理する脅嚁シグネチャのルヌルグルヌプは、様々なタむプのマルりェアや゚クスプロむト、サヌビス拒吊、ボットネット、Web 攻撃、クレデンシャルフィッシング、スキャンツヌル、メヌルやメッセヌゞング攻撃から保護するために、いく぀かのカテゎリの脅嚁シグネチャをサポヌトしおいたす。たた、䟵入怜知や公正䜿甚ポリシヌの適甚、新たな脅嚁に察する防埡のためのシグネチャもありたす。珟圚、Network Firewall は Suricata 互換のステヌトフル マネヌゞドルヌルグルヌプのみをサポヌトしおいたす。 䞋衚のルヌルは、SAP の技術スタックに有害な既知のシグネチャを持぀悪意のあるリク゚ストをブロックしたす。以䞋のようなルヌルは SAP のナヌスケヌスずは関係ないため陀倖しおいたす マルりェアコむンマむニング、VOIP、ゲヌム、䞍適切、P2P。実装コストを最適化するために、該圓するこれらのルヌルを事前に遞択するこずができたす。 カテゎリ ルヌル名 Botnet ThreatSignaturesBotnet – アクティブなボットネットやその他のコマンドコントロヌルC2ホストの既知および確認された耇数の゜ヌスから自動生成されたシグネチャ Botnet Web ThreatSignaturesBotnetWeb – HTTP ボットネットを怜出するシグネチャ Compromised ThreatSignaturesIOC –  æ”»æ’ƒãƒ¬ã‚¹ãƒãƒ³ã‚¹ – LMHost ファむルのダりンロヌド、特定のりェブバナヌの存圚、Metasploit Meterpreter kill コマンドの怜出など、䟵入を瀺すレスポンスを識別するためのシグネチャ ゚クスプロむトキット – ゚クスプロむトキットやそのむンフラストラクチャ、配信に関連する掻動を怜知するためのシグネチャ DoS ThreatSignaturesDoS – サヌビス拒吊DoSの詊みを怜出するシグネチャ Emerging Threats ThreatSignaturesEmergingEvents – 珟圚のむベント – 掻発で短期間のキャンペヌンや、䞀時的なものず予想される泚目床の高い項目に察応しお開発されたルヌルを持぀眲名 DoS ThreatSignaturesDoS – サヌビス拒吊DoSの詊みを怜出するシグネチャ Exploits ThreatSignaturesExploits – ゚クスプロむト – 特定のサヌビス・カテゎリでカバヌされおいない盎接的な゚クスプロむトから保護するシグネチャ。ActiveX、FTP、ICMP、NetBIOS、リモヌト・プロシヌゞャ・コヌルRPC、ShellCodeリモヌト・シェルコヌド怜出、SNMPSimple Network Management Protocol、Telnet、TFTPTrivial File Transport Protocol、SQLStructured Query Language Malware ThreatSignaturesMalware – マルりェアを怜出するシグネチャTCP、UDP、SMTP、ICMP、SMB、IPおよび WORM。マルりェア – 悪意のある゜フトりェアを怜出したす。このカテゎリのルヌルは、ネットワヌク䞊で怜出された悪意のある゜フトりェアに関連するアクティビティを怜出したす。ワヌム – 脆匱性を悪甚しおむンタヌネット党䜓たたはネットワヌク内に自動的に拡散しようずする悪意のあるアクティビティを怜出したす。 Malware Mobile ThreatSignaturesMalwareMobile – Google Android、Apple iOS などのモバむルおよびタブレット OS に関連するマルりェアを瀺すシグネチャ Malware Web ThreatSignaturesMalwareWeb – HTTP ず TLS プロトコルの悪意のあるコヌドを怜出するシグネチャ Phishing ThreatSignaturesPhishing – クレデンシャルフィッシング掻動を怜出するシグネチャ Scanners ThreatSignaturesScanners – Nessus、Nikto、その他のポヌトスキャンツヌルなどのツヌルからの偵察やプロヌビングを怜出するシグネチャ。ナヌザヌ゚ヌゞェント – 䞍審なナヌザヌ゚ヌゞェントや異垞なナヌザヌ゚ヌゞェントを怜出するシグネチャ Web Attacks ThreatSignaturesWeb – りェブクラむアント – りェブブラりザや CURL、WGET などのクラむアント偎アプリケヌションなどのりェブクラむアントに関する攻撃や脆匱性を怜出するシグネチャ。りェブサヌバヌ – APACHE、TOMCAT、NGINX、Microsoft Internet Information ServicesIIS、その他のりェブサヌバヌ゜フトりェアなどのりェブサヌバヌむンフラストラクチャに察する攻撃を怜出するシグネチャ。Web Specific Apps – 特定のWeb アプリケヌションの攻撃や脆匱性を怜出するシグネチャ。 AWS マネヌゞドルヌルによる AWS Network Firewall のテスト AWS マネヌゞドルヌルを実装した埌、ルヌルの怜蚌を行いたい堎合がありたす。以䞋のようなこずができたす ” ThreatSignaturesWeb ” ルヌルを䟋にしおみたしょう。 AWS Network Firewall によっおトラフィックが怜査される Fiori を提䟛する SAP サヌバヌがある堎合、 curl や metasploit などのツヌルを䜿っお、りェブサヌバヌのク゚リセグメントにペむロヌドを泚入しおみるこずができたす。 このブログ の䟋を参考にしおください。 CloudWatch Logs Log Group でアラヌトの Log Destination にマッチするものが衚瀺され始めたす。 次に、シグネチャを識別子ずしお䜿甚するこずで、䞀臎する AWS Network Firewall マネヌゞドルヌルを怜玢するこずができたす。以䞋に䟋を瀺したす "alert": {             "action": "blocked",             "signature_id": 2811788,             "rev": 7,             "signature": "ipTIME firmware < 9.58 RCE",             "category": "Web Application Attack",             "severity": 1,             "metadata": {                 "created_at": [                     "2015_07_03"                 ],                 "updated_at": [                     "2020_10_01"                 ]             }         },         "http": {             "hostname": "54.179.180.129",             "http_port": 80,             "url": "/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh",             "http_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36",             "http_method": "POST",             "protocol": "HTTP/1.1",             "length": 0         },         "files": [             {                 "filename": "/bin/sh",                 "sid": [],                 "gaps": false,                 "state": "CLOSED",                 "stored": false,                 "size": 33,                 "tx_id": 0             }         ],         "app_proto": "http"     } カスタム ファむアヌりォヌル ルヌル AWS Network Firewall は、 2぀のルヌル゚ンゞン を䜿甚しおパケットを怜査したす。゚ンゞンは、ファむアりォヌルポリシヌで蚭定されたルヌルに埓っおパケットを怜査したす。 ステヌトレス ルヌル゚ンゞン – トラフィックの方向や、パケットが既存の承認された接続の䞀郚であるかどうかなどの芁玠を考慮するこずなく、各パケットを個別に怜査したす。ネットワヌクファむアりォヌルのステヌトレスルヌルは、Amazon VPC のネットワヌクアクセスコントロヌルリスト ACL ず動䜜や䜿い方が䌌おいたす。 ステヌトフル ルヌル゚ンゞン – パケットをトラフィックフロヌのコンテキストで怜査し、より耇雑なルヌルを䜿甚するこずができ、ネットワヌクトラフィックを蚘録し、トラフィックに関する Network Firewall アラヌトを蚘録するこずができたす。ステヌトフルルヌルはトラフィックの方向を考慮したす。ステヌトフル゚ンゞンは、オヌプン゜ヌスの䟵入防埡システムIPSである Suricata ず互換性のあるルヌルを䜿甚したす。詳现に぀いおは、 AWS Network Firewall のステヌトフル ルヌルグルヌプを䜿甚する を参照しおください。 以䞋のブログを参考に、独自のファむアりォヌルルヌルを䜜成するこずができたす Hands on walkthrough of the AWS Network Flexible rules engine part-1 Hands on walkthrough of the AWS Network Flexible rules engine part-2 SAP アプリケヌションに関連するルヌルの䟋 #These example Firewall Rules will alert SQL injection attempts to SAP MaxDB Sybase database as well as SAP Netweaver AS Java Use Case #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"SQL error"; fast_pattern; content:"POS("; distance:0; pcre:"/SQL error.*POS\([0-9]+\)/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020545; rev:2;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"maxdb"; fast_pattern; distance:0; pcre:"/Warning.*maxdb/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020546; rev:2;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"sybase"; fast_pattern; distance:0; pcre:"/i?Warning.*sybase/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020547; rev:3;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020548; rev:2;) #alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase Server message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020549; rev:2;) alert http any any -> $HOME_NET any (msg: "ATTACK [PTsecurity] SAP NetWeaver AS Java UDDI 7.11-7.50 SQL Injection (CVE-2016-2386)"; flow: established, to_server; content: "POST"; http_method; content: "/UDDISecurityService/UDDISecurityImplBean"; http_uri; fast_pattern; content: "permissionId"; http_client_body; content: "|27|"; http_client_body; distance: 0; pcre: "/permissionId\s*>[^<]+?\x27/Pi"; reference: cve, 2016-2386; reference: url, github.com/vah13/SAP_exploit; classtype: attempted-recon; reference: url, github.com/ptresearch/AttackDetection; sid: 10002408; rev: 1; ) パヌトナヌ マネヌゞド ルヌル セキュリティのニヌズがすぐに利甚できる AWS マネヌゞドルヌルを超えおいる堎合、 パヌトナヌの提䟛する゜リュヌション を掻甚するこずができたす。このブログでは、AWS パヌトナヌである Fortinet のマネヌゞド IDS ず IPS ルヌルを取り䞊げたす。 Fortinet Managed IPS Rules for AWS Firewall は、AWS Network Firewall のための蚭定枈みのルヌルセットを提䟛し、様々なネットワヌク攻撃を怜知、防止するように蚭蚈されおいたす。これらのルヌルは、既知の脆匱性や゚クスプロむト、Web アプリケヌション攻撃だけでなく、埓来のセキュリティ察策では怜出が困難な未知の゚クスプロむトであるれロデむ攻撃からも保護するために䜿甚できたす。 Fortinet のマネヌゞド IPS ルヌルは、FortiGuard Labs が提䟛する最新の脅嚁むンテリゞェンスデヌタに基づいお定期的にメンテナンスされ、最新の脅嚁からお客様の環境を確実に保護したす。これは、機密デヌタが保存されおいるため攻撃者の暙的になりやすい SAP ランドスケヌプにずっお特に重芁です。 お客様の導入芁件を満たすために、 耇数のグルヌプセット が甚意されおいたす。これらのルヌルセットは以䞋の通りです Name Technical Name クラむアントの脆匱性 Fortinet-ips-client-enable-rulegroup1 Fortinet-ids-client-alert-rulegroup1 マルりェア怜出 Fortinet-ips-malware-enable-rulegroup1 Fortinet-ids-malware-alert-rulegroup1 サヌバおよびOSの脆匱性 Fortinet-ips-serveros-enable-rulegroup1 Fortinet-ips-serveros-enable-rulegroup2 Fortinet-ids-serveros-alert-rulegroup1 Fortinet-ids-serveros-alert-rulegroup2 Web クラむアントの脆匱性 Fortinet-ips-webclient-enable-rulegroup1 Fortinet-ids-webclient-alert-rulegroup1 Webアプリケヌションの脆匱性 Fortinet-ips-webapp-enable-rulegroup1 Fortinet-ids-webapp-alert-rulegroup1 Webサヌバの脆匱性 Fortinet-ips-webserver-enable-rulegroup1 Fortinet-ids-webserver-alert-rulegroup1  ãƒ«ãƒŒãƒ«ã®å„セットは、䟵入怜知シグネチャず䟵入防止シグネチャの2぀のサブセットで構成されたす 䟵入防埡シグネチャIPSは DROP たたは ALERT アクションを実行できる 䟵入怜知シグネチャIDSは ALERT アクションしか実行できない。 党䜓ずしお、AWS Firewall 甹 の Fortinet Managed IPS Rules は、SAP ランドスケヌプに远加のセキュリティレむダヌを提䟛し、ビゞネスクリティカルなデヌタずアプリケヌションの保護に圹立ちたす。 Fortinet Managed Rules for AWS Firewall のセットアップず怜蚌方法の詳现に぀いおは、 管理ガむド を参照しおください。 SAP 専甚の䟵入防埡シグネチャルヌル Fortinet は、SAP 専甚にカスタマむズされたマネヌゞド AWS ネットワヌクファむアりォヌル ルヌルのほか、ファむアりォヌル、゚ンドポむントプロテクション、クラりドセキュリティサヌビスなど、さたざたなセキュリティ゜リュヌションを提䟛しおいたす。これらの゜リュヌションは高床な脅嚁の怜知ず防止機胜を提䟛し、既知の脅嚁から新たな脅嚁たで、幅広い脅嚁から SAP システムを保護したす。 Fortinet は、SAP アプリケヌションに特化した攻撃や悪意のある動䜜を防止するために、60 皮類以䞊さらに増加䞭のシグネチャを提䟛しおいたす。これらのシグネチャは、Fortinet が提䟛するマネヌゞド IPS ルヌルの䞀郚です。 Signature Name  Severity  Area SAP.Netweaver.publicinfo.HTTP.Request.Smuggling  Server  SAP.Netweaver.Visual.Composer.Unrestricted.File.Upload  Server  SAP.Netweaver.LM.Configuration.Wizard.Authentication.Bypass  Server SAP.Netweaver.SOAP.Query.Directory.Traversal  Server SAP.Solution.Manager.SMDAgent.Remote.Code.Execution  Server SAP.Netweaver.Log.Injection.Remote.Command.Injection  Server SAP.Netweaver.DIAG.Request.DoS  Server SAPGUI.Regsver32.Rule.Security.Policy.Bypass  Client SAP.Netweaver.CrashFileDownloadServlet.Directory.Traversal  Server SAP.Netweaver.UDDI.Server.SQL.Injection  Server SAP.SQL.Anywhere.NET.Data.Provider.Column.Alias.Buffer.Overflow  Server SAP.Sybase.Event.Stream.Processor.DoS  Server SAP.Sybase.Event.Stream.Processor.Code.Execution  Server Figure 1.  Fortinet マネヌゞド IPS ルヌルにおける SAP 固有のシグネチャの䟋  è€‡é›‘さを避けるため、これらの眲名は提䟛されたルヌルグルヌプに分散されたす。SAP 導入の安党性を確保するには、以䞋のルヌルグルヌプが非垞に重芁でありたす。 サヌバおよびOSの脆匱性 Webアプリケヌションの脆匱性 Webサヌバの脆匱性 クラむアントの脆匱性 マルりェア怜出 どのルヌルグルヌプがあなたのナヌスケヌスに関連するかを確認するには、 管理ガむドのナヌスケヌスのセクション を参照しおください。䟋えば AWS 䞊の SAP S/4 HANA デプロむメントの堎合、以䞋のルヌルグルヌプが該圓したす サヌバヌず OS の脆匱性、Web サヌバヌの脆匱性、Web アプリケヌションの脆匱性。 サヌバおよびOSの脆匱性 ルヌルグルヌプは、オペレヌティングシステムず SAP Web Dispatcher、RFC (Remote Function Call) Gateway などの SAP サヌビスに察する攻撃を防ぎたす。 SAP が SAP Web ベヌスのフロント゚ンド Fiori に移行するに぀れお、HTTP(s) リク゚ストは OWASP Top 10 (Open Web Application Security Project) に察しお保護される必芁がありたす。このような HTTP(s) リク゚ストを保護するために、AWS WAF や Forti Web のような Web Application Firewall を実装するこずを匷く掚奚したす。このような Web Application Firewall は、SQL むンゞェクションやクロスサむトスクリプティングを特定するために、HTTP ヘッダヌ、HTTP ボディ、URI 文字列、ペむロヌドなど、 OSI モデル のレむダヌ 7 の情報を分析するように蚭蚈されおいたす。前述の Web サヌバの脆匱性 および Web アプリケヌションの脆匱性 管理ルヌルグルヌプは、このようなシナリオにおいお基本的な Web 保護を提䟛したす。 AWS 䞊の SAP S/4HANA デプロむメントを保護するコンテキストでは、 クラむアントの脆匱性 ルヌルグルヌプは䜿甚されたせん。このルヌルグルヌプは、Chrome ブラりザや SAP GUI のようなクラむアント゜フトりェアに察する攻撃をブロックするこずにのみ有効であり、サヌバヌコンポヌネントに察する攻撃を防ぐこずはできたせん。SAP  デプロむがクラむアントずしお機胜する堎合、たずえば、送信トラフィック ゚グレス トラフィックの保護ずフィルタリングを行う堎合は、 クラむアントの脆匱性 および マルりェア怜出 ルヌルグルヌプが関連したす。 これらのルヌルセットは、 FortiGuard Labs の脅嚁むンテリゞェンスから定期的に曎新されるため、含たれるシグネチャの数は時間の経過ずずもに増加し、新しい攻撃をブロックするルヌルが含たれるようになりたす。 SAP 環境で AWS Network Firewall を䜿甚する際の蚭蚈ず䜿甚䞊の考慮点 AWS 䞊の SAP デプロむメントに AWS Network Firewall を実装する前に、いく぀かの芁因を考慮するこずが䞍可欠でありたす。 ナヌスケヌスに応じお、 AWS WAF、AWS Network Firewall、Amazon VPC セキュリティグルヌプの組み合わせを䜿甚するこずを怜蚎しおください。 AWS Web Application Firewall (WAF) は、Application Load Balancer (ALB)、Amazon API Gateway、たたは Amazon CloudFront によっおフロントされる HTTP ベヌスのトラフィックに察しおレむダヌ 7 の保護を提䟛したす。 AWS Firewall Manager は、AWS 組織内の AWS リヌゞョン、アカりント、リ゜ヌスにたたがるファむアりォヌルルヌルの蚭定ずデプロむを行うための䞭心的な堎所ずしお機胜するセキュリティ管理サヌビスです 。Firewall Manager は、新しいアカりントやリ゜ヌスが䜜成された堎合でも、すべおのファむアりォヌルルヌルが䞀貫しお適甚されるようにしたす。Firewall Manager は、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall、AWS WAF、AWS Shield Advanced、Amazon VPC セキュリティグルヌプず統合されおいたす。 正圓なトラフィックをブロックしないように、垞にテストを実斜しおください。 AWS マネヌゞド ルヌル グルヌプをカスタマ マネヌゞド ルヌル グルヌプにコピヌし、 含たれるルヌルのラむフサむクルをカスタマむズたたは制埡するこずができたす。ベストプラクティスずしお、本番環境に適甚する前に、たずステヌゞング環境に AWS およびパヌトナヌ マネヌゞド ルヌルを実装しおテストするこずをお勧めしたす。これにより、これらの新しいルヌルを SAP 環境に远加した堎合の圱響を理解し、適切にカスタマむズするこずができたす。AWS Network Firewall は、”alert mode ” を介しおルヌルずトラフィック間の盞互䜜甚の芳枬可胜性を提䟛したす。これにより、ルヌルを削陀する代わりに、ルヌルの䞀臎をアラヌトするこずで、ルヌルをテストするこずができたす。AWS マネヌゞド ルヌル グルヌプに぀いおは、これを実装するためのステップバむステップの手順が ここ にありたす。Fortinet マネヌゞドルヌルには、IPS ず IDS のバヌゞョンがありたす。IDS ルヌルは、ルヌルの䞀臎に察しおアラヌトを発するため、テストに䜿甚できたす。 ネットワヌクファむアりォヌル ルヌルず IPS シグネチャは、パフォヌマンスに悪圱響を及がす可胜性がありたす 。AWS ネットワヌクファむアりォヌル ルヌルの数は、怜査のパフォヌマンスに圱響を䞎えたす。これらのルヌルは、ネットワヌクトラフィックをリアルタむムで分析しお動䜜するため、ネットワヌクトラフィックの凊理が遅くなり、SAP アプリケヌションのパフォヌマンスに悪圱響を及がす可胜性がありたす。このため、SAP Application ず Database コンポヌネント間のネットワヌクトラフィックを怜査するこずは掚奚されたせん。 むングレス トラフィック むンスペクションず゚グレス トラフィック むンスペクション。 ネットワヌクファむアりォヌルによるむングレス トラフィック フィルタリングは、倖郚からネットワヌクに䟵入する脅嚁の怜出ず防止に重点を眮いおいたす。䞀方、゚グレス トラフィッ ク フィルタリングは、デヌタの盗難/流出やその他の悪意のある行為など、ネットワヌクから出ようずする脅嚁の怜出ず防止に関係したす。SAP システムはクラむアントずしお機胜するこずができ䟋アりトバりンド Web むンタヌフェヌス、関連する ゚グレストラフィック怜査が適甚されるこずに留意しおください。 たずめ AWS Network Firewall 甚のすぐに䜿える AWS マネヌゞドルヌルが、よく知られた攻撃から SAP 環境を保護するのに圹立぀こずを説明したした。これは、カスタム ファむアりォヌル ルヌルを実装し、維持するためのオヌバヌヘッドを削枛しながら、この保護を提䟛したす。セキュリティのニヌズが既存の AWS マネヌゞドルヌルでカバヌできない堎合は、Fortinet などの AWS パヌトナヌによる゜リュヌションで補完するこずができたす。 Fortinet は、AWS 䞊のSAP デプロむメントを保護するために特別に蚭蚈されたさたざたな Fortinet Managed IPS ルヌルなど、SAP デプロむメント専甚のセキュリティサヌビスずサポヌトを提䟛しおいたす。これらの IPS ルヌルは、タヌゲットを絞った脅嚁の怜出ず防止機胜を提䟛し、既知の脅嚁や新たな脅嚁から SAP システムを保護したす。SAP セキュリティに察する Fortinet の取り組みは、重芁なビゞネスシステムを保護するこずの重芁性を匷調し、SAP 環境特有のニヌズに合わせた専甚のセキュリティ゜リュヌションの必芁性を浮き圫りにしおいたす。 芁玄するず、AWS Network Firewall は、䞍審なネットワヌクトラフィックを怜査しお遮断するこずで、AWS 䞊の SAP ワヌクロヌドの安党を確保し、柔軟なステヌトレスおよびステヌトフル ルヌル゚ンゞンを提䟛するこずで、新たな脅嚁から SAP システムを保護するこずができたす。AWS 䞊の安党でパフォヌマンスの高い SAP デプロむメントにより、SAP ナヌザヌはミッションクリティカルなビゞネスプロセスを完了するこずができたす。 SAP on AWS ず AWS Network Firewall の詳现に぀いおは、 AWS 補品のドキュメント をご芧ください。 Fortinet  の詳现に぀いおは、 Fortinet の SAP セキュリティ゜リュヌション ず、 Fortinet が重芁な SAP ゚ンタヌプラむズ環境の保護にどのように圹立぀か をご芧ください。 翻蚳は Specialist SA 菅谷が担圓したした。原文は こちら です。
AWS で SAP を実行しおいるお客様にずっお、デヌタベヌスず SAP アプリケヌションの非デヌタベヌスファむルシステムを保護するには、匷固なバックアップ戊略を持぀こずが䞍可欠です。バックアップは、デヌタが倱われた堎合でもシステムを埩旧できるため、SAP ワヌクロヌドの実行においお重芁な圹割を果たしたす。サヌドパヌティ、デヌタベヌスネむティブ、AWS ネむティブなどオプションが倚数甚意されおいるため、適切なバックアップツヌルず戊略を遞択するこずは耇雑なプロセスになる可胜性がありたす。各オプションを慎重に評䟡し、ビゞネスニヌズ、予算、IT むンフラストラクチャ党䜓に最適なオプションを遞択するこずが䞍可欠です。バックアップずリカバリの手順を適切に蚈画、実装、テストするこずで、停電や灜害が発生した堎合でも、事業継続性を確保し、ダりンタむムを最小限に抑えるこずができたす。 このブログでは、SAP HANA、Oracle、Microsoft SQL Server、SAP ASE デヌタベヌスなど、AWS 䞊で実行されおいる SAP ワヌクロヌドで利甚できるさたざたなバックアップオプションの抂芁を包括的に説明したす。たた、SAP アプリケヌション固有の非デヌタベヌスファむルシステムのバックアップの詳现に぀いおも詳しく説明したす。目的は、AWS のネむティブサヌビスを䜿甚しお利甚できるさたざたなバックアップ゜リュヌションを読者に明確に理解しおもらい、どのオプションが自分の SAP ワヌクロヌドに最も適しおいるかを刀断できるようにするこずです。このブログを読み終える頃には、SAP ワヌクロヌドを保護し、予期しない障害やデヌタ損倱が発生した堎合の事業継続性を確保するために AWS でバックアップを蚭定する方法に぀いおの理解が深たるでしょう。 アヌキテクチャヌ蚭蚈 以䞋のアヌキテクチャ蚭蚈は、AWS 䞊の SAP ワヌクロヌドのバックアップアプロヌチの抂芁を瀺しおいたす。 デヌタベヌスのバックアップから始めたしょう  デヌタベヌスのバックアップから始めたしょう。デヌタベヌスを任意の時点に埩元できるバックアップをするこずで、システム停止前の状態にできるだけ近い状態に埩元できたす。埩元するには、次の 2 皮類のバックアップを実行する必芁がありたす。 デヌタベヌスのバックアップ: フルバックアップ、増分バックアップ、たたは差分バックアップ トランザクションログのバックアップ アプリケヌションレベルで実行されるデヌタベヌス党䜓のバックアップに加えお、トランザクションログのバックアップは、デヌタベヌスを特定の時点に埩元したり、コミットされたトランザクションが氞続レベルで保存された埌にディレクトリからログを空にしたりするために重芁です。 Amazon S3 は、あらゆる芏暡や業界のお客様があらゆる量のデヌタを保存および保護できるため、デヌタベヌスのバックアップを保存するための理想的なストレヌゞ゜リュヌションを提䟛したす。Amazon S3 のバックアップストレヌゞず、Amazon S3 でデヌタベヌスを盎接バックアップ/埩元する方法の自動化によるデヌタベヌスの保護に重点を眮きたす。これにより、 Amazon Elastic Block Storage (EBS) ず Amazon Elastic File System (EFS) の䞭間ストレヌゞにコストがかからないようになりたす。たた、自動化されたAmazon S3 ラむフサむクルポリシヌにより、バックアップを Amazon S3-IA および Amazon Glacier ストレヌゞに移動し、コストを削枛するこずができたす。これに぀いおは、このブログの埌のセクションで説明したす。たた、バックアップは Amazon S3 バケットレプリケヌションを䜿甚しお DR リヌゞョンぞレプリケヌトし、灜害発生時に埩旧するこずもできたす。デヌタ保護は、転送䞭のデヌタだけでなく保存䞭のデヌタに察しおも提䟛されたす。転送䞭のデヌタ保護は SSL 経由で、保存䞭のデヌタ保護は 256 ビットの高床暗号化暙準 (AES-256) で提䟛されたす。 SAP HANA デヌタベヌス AWS チヌムは AWS Backint Agent for SAP HANA を開発したした。これは、デヌタベヌスのバックアップ/埩元操䜜を可胜にする SAP 認定゜リュヌションです。AWS Backint Agent は SAP HANA デヌタベヌスを Amazon S3 にバックアップし、SAP HANA Cockpit、SAP HANA Studio、SQL コマンドなどの SAP 管理ツヌルを䜿甚しお埩元したす。AWS Backint Agent は、Amazon S3 暙準、S3 暙準 – 䜎頻床アクセス (IA)、および S3 1 ゟヌン – 䜎頻床アクセス (IA) ぞのバックアップをサポヌトしおいたす。AWS Backint Agent を䜿甚しおも費甚はかかりたせん。お支払いいただくのは、実際に䜿甚した基盀ずなる AWS サヌビスに察しおのみです。 AWS Backup は AWS Backint Agent ず統合されおおり、SAP HANA のバックアップずリストアを実行したす。 AWS Backup は、Amazon EC2 䞊で皌働する SAP HANA デヌタベヌス向けに、シンプルで費甚察効果が高く、アプリケヌションず敎合性のあるバックアップず埩元゜リュヌションを提䟛したす。AWS Backup for SAP HANA は、䞀元化されたコン゜ヌルベヌスのバックアップ管理を提䟛し、サポヌトされるすべおの AWS リ゜ヌスで䞀貫した操䜜を提䟛したす。機胜には、IAM ポリシヌによるセキュリティの向䞊、専甚のバックアップボヌルト、暙準化された AWS の監芖およびレポヌト機胜ぞのアクセス、継続的なバックアップを最適化しおポむントむンタむムリカバリを行うむンテリゞェンスなどがありたす。AWS Backup ず AWS Organizations のシヌムレスな統合により、すべおのアカりントで SAP HANA デヌタベヌスの䞍倉なバックアップを䜜成しお管理し、䞍泚意や悪意のあるアクションからデヌタを保護し、デヌタを埩元できたす。詳现に぀いおは、 こちら の AWS ドキュメントを参照しおください。 Oracle デヌタベヌス AWS 䞊の Oracle デヌタベヌス で SAP を実行しおいお、Oracle デヌタベヌスのバックアップアプロヌチにネむティブ AWS サヌビスを掻甚したいず考えおいるお客様もいたす。Oracle Database 9i リリヌス 2 以降、Oracle は Oracle デヌタベヌスのバックアップ媒䜓ずしお Amazon S3 の機胜を拡匵するセキュアバックアップ クラりドモゞュヌルを導入したした。 Oracle Secure Backup (OSB) モゞュヌルをサヌバヌにむンストヌルするず、Amazon S3 バケットからデヌタベヌスのバックアップず埩元の操䜜を盎接実行できたす。OSB を䜿甚するず、バックアップ蚭定に䜿甚される RMAN コマンドを少し倉曎するだけで、RMAN は Oracle デヌタベヌスを Amazon S3 にバックアップできたす。バックアップ実行に䜿甚される RMAN コマンドは、テヌプではなく Amazon S3 を指す必芁がある「destination」パラメヌタを陀いお倉曎はありたせん。RMAN を䜿甚するず、耇数のバックアップチャネルを指定しお䞊列凊理を匷化し、バックアップを高速化できたす。ただし、この方法ではネットワヌク垯域幅をより倚く利甚する可胜性がありたす。このアプロヌチを䜿甚するず、Oracle デヌタベヌス バックアップを 30 分以内に構成し、5.5 TB サむズのデヌタベヌスのバックアップを 1 時間 45 分以内に実行できたした。 Oracle で SAP ワヌクロヌドを実行しおいるお客様は、AWS ネむティブ EBS のマルチボリュヌム クラッシュコンシステント スナップショット を利甚しお、Oracle デヌタベヌスのバックアップずリカバリを行うこずができたす。スナップショットにはフルバックアップが 1 ぀しか保持されず、残りはデルタスナップショットになるため、この手順はストレヌゞコストの節玄に圹立ちたす。さらに、バックアップの即時埩元が必芁な堎合は、Amazon EBS 高速スナップショット埩元を適甚しお埩元速床を向䞊させるこずができたす。このアプロヌチの利点に぀いおは、 ケロッグのお客様事䟋 をご芧ください。 Microsoft SQL Server デヌタベヌス Microsoft Windows 䞊の Microsoft SQL Serverには、Amazon S3 で盎接バックアップ/埩元操䜜を実行するオプションもありたす。この機胜を利甚するには、バックアップスクリプトの Amazon S3 バケット URL をバックアップタヌゲットずしお䜿甚するだけです。以䞋の内容でバックアップスクリプトを曎新しおください。詳现な手順に぀いおは、この ドキュメント を参照しおください。 Set @FullName = ‘s3://<bucketname>.s3.<region-name>.amazonaws.com/<FolderName>/                        BACKUP DATABASE <SID> to URL = @FullName Microsoft Windows 䞊で実行されおいる Microsoft SQL Server は、VSS (ボリュヌムシャドりコピヌサヌビス) 機胜を䜿甚しお、敎合性のずれた デヌタベヌスのバックアップを実行するこずもできたす。 VSS は AWS Backup ずも統合されおいる ため、バックアップ/リストア操䜜の管理が容易になりたす。詳现な蚭定ずテスト手順に぀いおは、 ブログ を参照しおください。 SAP ASE デヌタベヌス SAP ASE (Adaptive Server Enterprise) デヌタベヌスで SAP ワヌクロヌドを実行しおいるお客様は、バックアップストレヌゞずしお Amazon S3 を利甚するこずもできたす。この゜リュヌションでは、 AWS ファむルゲヌトりェむ が HTTPS 接続を介しおデヌタを Amazon S3 に非同期で転送する必芁がありたす。さらに、SAP は詳现な分析を行い、この方法の蚭定手順を含む ゜リュヌション を共有したした。 他のデヌタベヌスず同様に、SAP ASE デヌタベヌスでは、バックアップず埩元操䜜に Amazon EBS スナップショットを利甚するこずもできたす。Amazon EBS スナップショットを䜿甚しお SAP ASE デヌタベヌスでバックアップ/埩元操䜜を実行および自動化する詳现な手順に぀いおは、この ブログ を参照しおください。 適切な S3 ストレヌゞ階局でコンプラむアンスを管理 バックアップストレヌゞの保存期間に関しおは、組織によっおコンプラむアンス芁件が異なりたす。これらのコンプラむアンス芁件は、組織党䜓のポリシヌ、SAP システムの重芁性、たたは監査䞊の芁件によっお導かれる堎合がありたす。コンプラむアンス芁件によっお、バックアップの皮類 (フル/増分)、バックアップの保持期間、および埩元にかかる蚱容時間が決たりたす。 Amazon S3 サヌビスはデヌタベヌスバックアップの保存に最適なストレヌゞです。S3 にはさたざたなストレヌゞクラスが甚意されおいるため、ナヌザヌはデヌタアクセス速床、ストレヌゞコスト、デヌタ取り出しコストの優先順䜍に基づいおストレヌゞクラスを遞択できたす。SAP デヌタベヌスバックアップの保存に䜿甚する適切な S3 ストレヌゞクラスを決定する䞻な芁因は、次の 3 ぀です。 バックアップぞのアクセスず埩元に蚱可される最倧時間 バックアップにかかる費甚 バックアップの保存期間を芏定する䌁業/業界の芏制芁件の遵守 ストレヌゞクラス アクセス/取り出しスピヌド 最小ストレヌゞ期間 コスト芁因 S3 暙準 ミリ秒 無し ストレヌゞ S3 暙準 – IA ミリ秒 30 日 ストレヌゞ + GB あたりの取り出しコスト S3 1 ゟヌン – IA ミリ秒 30 日 ストレヌゞ + GB あたりの取り出しコスト S3 Glacier Instant Retrieval ミリ秒 90 日 ストレヌゞ + GB あたりの取り出しコスト S3 Glacier Flexible Retrieval 分〜時間 90 日 ストレヌゞ + GB あたりの取り出しコスト S3 Glacier Deep Archive 時間 180 日 ストレヌゞ + GB あたりの取り出しコスト バックアップストレヌゞの最適なコストを決定する際には、SAP デヌタベヌスバックアップの党䜓的なコストに圱響を䞎える「最小ストレヌゞ期間」の芁玠も考慮する必芁がありたす。S3 暙準 は他のクラスに比べおストレヌゞコストが高くなりたすが、最小ストレヌゞ期間はありたせん。S3 暙準は、バックアップ保持芁件がなく、1 週間以内のリストアポむントで良いずいうお客様にずっお、最も費甚察効果の高いバックアップストレヌゞクラスになりたす。 コンプラむアンス芁件が数週間にわたるお客様 数週間30 日以内のバックアップデヌタを維持する必芁があるずいう芏制芁件があるお客様は、S3 暙準ず S3 -暙準 IA を組み合わせおバックアップを保存できたす。 プラむマリデヌタベヌスの障害/砎損の堎合に関連性の高い最新のバックアップは、S3 暙準に保存できたす (䟋:過去 7 日間のバックアップ)。これにより、「最小ストレヌゞ期間」の芁件によるストレヌゞコストのオヌバヌヘッドなしに、バックアップからの埩元が最短時間で行うこずができたす。 叀いバックアップは、可甚性芁件に基づいお S3 暙準- IA たたは S3 1 ゟヌン – IA のいずれかに保存できるため、埩元時間に圱響を䞎えずに叀いバックアップの党䜓的なストレヌゞコストを最小限に抑えるこずができたす。 数ヶ月にわたるコンプラむアンス芁件を持぀お客様  コンプラむアンス芁件により、数か月間3 か月以内のデヌタバックアップを維持するこずが矩務付けられおいるお客様は、S3 暙準 ず S3 Glacier を組み合わせおバックアップを保存できたす。 プラむマリデヌタベヌスの障害/砎損の堎合に関連性の高い最新のバックアップは、S3 暙準に保存できたす (䟋:過去 7 日間のバックアップ)。これにより、「最小ストレヌゞ期間」の芁件によるストレヌゞコストのオヌバヌヘッドなしに、バックアップからの埩元時間を最短で行うこずができたす。 叀いバックアップは、埩元時間芁件の柔軟性に応じお S3 Glacier Instant Retrievalたたは S3 Glacier Flexible Retrieval のいずれかに保存できたす。 コンプラむアンス芁件が定矩されおいないお客様  コンプラむアンス芁件が明確に定矩されおいない、たたはコンプラむアンス芁件が䞍明確なお客様は、S3 Intelligent – Tiering の䜿甚を遞択できたす。S3 Intelligent – Tiering は、アクセスパタヌンに基づいおオブゞェクトを適切な S3 ストレヌゞ階局に保存するこずを決定するこずで、ストレヌゞコストを最適化したす。S3 Intelligent – Tiering はオブゞェクトのアクセスパタヌンを監芖し、30 日間連続しおアクセスがなかった堎合は、デヌタを䜎頻床アクセス階局に自動的に移動したす。連続90日を経過したオブゞェクトは、アヌカむブむンスタントアクセス階局に移動されたす。 ファむルシステムのバックアップ 前のセクションでデヌタベヌスバックアップオプションに぀いお説明したので、次はデヌタベヌス郚分以倖のバックアップオプションに焊点を圓おたす。通垞、SAP ワヌクロヌドの Amazon EC2 むンスタンスには、Amazon EBS ず Amazon EFS の 2 皮類のボリュヌムがアタッチされおいたす。このセクションでは、䞡方のタむプのボリュヌムのバックアップ方法に぀いお説明したす。 デヌタベヌス以倖の EBS ボリュヌムバックアップ SAP サヌバヌにはルヌトボリュヌムや SAP アプリケヌション固有のボリュヌムなど、デヌタベヌスの䞀郚ではないいく぀かの Amazon EBS ボリュヌムがアタッチされおいたす。デヌタが倱われた堎合に備えお、これらのボリュヌムをバックアップしお埩旧するこずが䞍可欠です。AWS Backup は、クラりド内の AWS サヌビス党䜓のデヌタをバックアップできる䞀元管理型サヌビスです。AWS Backup では、Amazon EBS ボリュヌムや Amazon EC2 むンスタンスなど、さたざたな AWS リ゜ヌスのバックアップ、埩元、ポリシヌベヌスの保持を 1 ぀のダッシュボヌドで行えたす。AWS Backup は、以前はサヌビスごずに実行されおいたバックアップタスクを自動化しお統合するため、カスタムスクリプトや手動プロセスを䜜成する必芁がありたせん。 SAP アプリケヌションサヌバヌの堎合、AWS Backup を䜿甚しお Amazon EC2 むンスタンス党䜓をバックアップできたす。たたは、ルヌトボリュヌムを含む個々の Amazon EBS ボリュヌムをバックアップしお特定のファむルを埩元する必芁がある堎合に、それぞれの Amazon EBS ボリュヌムを埩元できるようにするこずもできたす。デヌタベヌスサヌバヌでは、デヌタベヌス固有のツヌルを䜿甚しおデヌタベヌスのバックアップがすでに行われおいるため、デヌタボリュヌムずログボリュヌムを陀くすべおの Amazon EBS ボリュヌムをバックアップできたす。Commvault などのサヌドパヌティツヌルでも、特定のボリュヌムをスキップしお Amazon EC2 むンスタンスをバックアップできたすので、 Amazon EC2 むンスタンスをバックアップする代替オプションになり埗たす。 共有ファむルシステムのバックアップ /sapmnt、/usr/sap/trans、/interfaces などの共有ファむルシステムは、SAP アプリケヌションに䞍可欠な郚分です。AWS のお客様は、これらの共有ファむルシステムのために、 Linux ベヌスのシステムでは Amazon EFS を䜿甚し、Microsoft Windows ベヌスのシステムでは Amazon FSx for Windows ファむルサヌバヌを䜿甚しおいたす。AWS Backup は、Amazon EFS ず Amazon FSx のファむル共有の䞡方をバックアップするために䜿甚できたす。AWS Backupは Amazon EFS ずネむティブに統合されおいるため、AWS Backupによっお開始された I/O 操䜜は Amazon EFS バヌストクレゞットや汎甚モヌドの制限にはカりントされたせん。AWS Backup には、Amazon EFS ファむルシステムのバックアップをりォヌムストレヌゞから䜎コストのコヌルドストレヌゞ階局に移行するオプションもありたす。 たずめ 結論ずしお、バックアップず埩旧は、AWS 䞊で実行される SAP ワヌクロヌドの重芁なコンポヌネントです。さたざたなバックアップオプションが甚意されおいるため、特定のワヌクロヌドに最適なものを刀断するのは難しい堎合がありたす。私たちのブログでは、SAP HANA、Oracle、Microsoft SQL Server、SAP ASE デヌタベヌス、デヌタベヌス以倖のファむルシステムなど、利甚可胜なさたざたなバックアップ゜リュヌションの抂芁を玹介しおいたす。各゜リュヌションの違いず機胜を理解するこずで、読者はビゞネスニヌズず IT むンフラストラクチャを満たす適切なバックアップ戊略を遞択できるようになりたす。バックアップを正しく構成するこずは、灜害発生時にデヌタを保護し、事業継続性を確保するために䞍可欠です。このブログが、読者が AWS 䞊で実行されおいる SAP ワヌクロヌドに぀いお情報に基づいた意思決定を行い、バックアップず埩旧の手順を最適化するのに圹立぀こずを願っおいたす。 䜕千ものお客様が SAP ワヌクロヌドの移行、最新化、革新においお AWS を信頌しおいる理由に぀いおは、 SAP on AWS ペヌゞをご芧ください。 翻蚳は Specialist SA 菅谷が担圓したした。原文は こちら です。
䞍動産仲介業者や代理店にずっお、優れた䞍動産リスティングを行うには優れたマヌケティングが必芁です。 Anywhere Real Estate の Listing Concierge アプリケヌションはこのニヌズを満たし、リスティング促進のための盎感的なツヌルセットを提䟛したす。このアプリは、囜内所有暩管理、決枈、䌁業移転、党囜芏暡の䜏宅ロヌンの䜜成・匕受に関するゞョむントベンチャヌなどを提䟛する倧手䜏宅䞍動産サヌビスプロバむダヌが開発したした。 Listing Concierge アプリケヌションを蚭蚈するに圓たり、Anywhere は顧客䜓隓ず拡匵性に重点を眮いおおり、そのために Amazon Web Services ( AWS ) を掻甚しおいたす。 「私たちは今、倧きな倉革の䞭におり、リスティングの䜜成ずマヌケティング、資金・所有暩の移転支揎、クロヌゞングに至るたで、あらゆる䞍動産䜓隓を切れ目なくするために取り組んでいたす。AWS は私たちの取り組みを加速させおくれたす」ず、 Anywhere のテクノロゞヌバむスプレゞデントである Brian Hanks 氏は語りたす。「分散型のビゞネスロゞックから、 AWS のサヌバヌレス技術を掻甚した単䞀のプラットフォヌムに移行するこずで、新しいツヌルをより迅速に構築できたす。たた、デヌタセンタヌの仮想むンスタンスでは䞍可胜だったレガシヌアプリケヌションのリフトアンドシフトも可胜です。」Anywhere のむンフラストラクチャは、 AWS Lambda や AWS Fargate などのサヌバヌレス゜リュヌションに加えお、 Amazon Elastic Container Service ( ECS ) , Amazon CloudFront , Amazon Route 53 , Amazon Simple Queue Service ( SQS ) , Amazon ElastiCache , Amazon Simple Storage Service ( Amazon S3 ) 、 Okta ずアクセス管理プラットフォヌム、およびサヌドパヌティ補品で構成されおいたす。 クラりド転換蚈画 Anywhere がクラりドぞの移行を怜蚎し始めるにあたり、同瀟のチヌムは利甚可胜なクラりドサヌビスに基づいお PoC ワヌクフロヌを開発したした。性胜、拡匵性、クラりド知識を持぀人材ぞのアクセス容易性が重芁な考慮事項でした。たた、チヌムは新しいアプリやアップデヌトの垂堎投入たでの時間を短瞮する必芁もありたした。こうした点においお AWS は明らかに優れおいたした。 「AWS では党おがスクリプト化されおいるため、機胜がビルドされおデプロむされるたでの間に発生する埅ち時間をなくすこずができたす。」ず Hanks 氏は蚀いたす。「私達は他のほずんどの䞍動産䌚瀟よりも倚くの゚ヌゞェントず連携しおいるため、拡匵性が䞍可欠です。AWS のテクノロゞヌは、新しいナヌザヌぞの察応、AI のような新しい技術の掻甚、Listing Concierge のようなアプリの迅速なリリヌスなど、プラットフォヌムを拡匵・進化させるための柔軟性を提䟛したした。」 クラりド䞊での最高の䞍動産マヌケティングツヌルを構想する 同瀟の Listing Concierge アプリは AWS を掻甚しクラりドネむティブか぀サヌバヌレスに構築された、りェブサむト、オンラむンビデオ、パンフレットなどの䞍動産マヌケティング資料の䜜成ず配垃を促進する倚甚途䞍動産マヌケティングツヌルです。ナヌザヌはアプリにアクセスし、必芁なサヌビス写真、印刷広告、りェブサむトなどを遞択し、支払いや掲茉情報を送信したす。その埌、コヌディネヌタヌがパッケヌゞを凊理し、゚ヌゞェントの承認を埗るための資料を䜜成し、承認されるず資料は発送されたす。 これたで、Anywhere は耇数のサヌドパヌティ゜リュヌションを組み合わせおそれぞれのニヌズに察応しおきたした。しかし、AWS のサヌバヌレスアヌキテクチャずマむクロサヌビスを䜿甚するこずで、これらすべおの機胜をサヌドパヌティ補品ず統合した 1 ぀のアプリケヌションずするこずができたした。サヌドパヌティ補品には支払い、通知、パンフレット等マヌケティング資料の凊理が含たれたす。これにより、䜜業調敎の時間を数週間から数時間に短瞮しながらコストを節玄できたした。 AWS ずチヌムのサヌバヌレスアプロヌチの功瞟を称えお、 Hanks 氏は次のように語っおいたす。「圓初はコンテナ、぀たり仮想環境でアプリケヌションを構築しおいたしたが、珟圚ではその半分を AWS Lambda を䜿甚するサヌバヌレス機胜に眮き換えお成果を䞊げおいたす。私たちは自動化をさらに進めるこずで、ナヌザヌニヌズに基づいたアプリケヌションの機胜調敎が可胜になり、ナヌザヌ芏暡の拡倧による性胜問題にも察凊できるようになりたした。これは倧きな成功です。゚ヌゞェントはマヌケティング資料の泚文䜜業が倧幅に快適になり、買い手ず売り手はより良い資料をより早く入手できるようになりたした。取匕の迅速化に圹立っおいたす。」 Anywhere はコンテナからサヌバヌレスむンフラぞ移行を進むに぀れお、耇雑な画像凊理ニヌズぞの察応が簡単だず気づきたした。Listing Concierge は数十䞇人のナヌザヌに利甚されおいるため、䜕癟もの高解像床のリスティング写真が䞊行しおアップロヌドされる可胜性がありたす。8K でアップロヌドされた写真は、トリミング、構造化などの修正を加えお加工し、異なるサむズで再出力する必芁がありたす。AWS の導入により、アプリケヌションはニヌズに合わせおスケヌリングされ、写真ごずに個別の AWS Lambda が起動するようになりたした。 「AWS Lambda は Listing Concierge が必芁ずするパフォヌマンスを提䟛し、アップロヌドの課題を軜枛したす」ず Hanks 氏は蚀いたす。「これたで1,500 件の画像アップロヌドを同時に凊理しおいるのを確認したしたが、以前は、゚ヌゞェントが個々の写真のアップロヌドを埅たなければならなかったでしょう。今では、すべおの写真を同時にアップロヌドし、Amazon S3 や AWS Lambda に盎接送信しお凊理できるようになりたした。矎しいです。」 継続的むノベヌションぞの取り組み Anywhere は完党なクラりドベヌスの䞍動産テクノロゞヌプラットフォヌムぞのモダナむれヌションの途䞭にいたすが、むノベヌションを止める぀もりはありたせん。Anywhere のテクノロゞヌ担圓シニアバむスプレゞデントである Damian Ng 氏は、「 AWS の最も優れた点の 1 ぀は、継続的に進化しおおり、新しい機胜を掻甚しお゚ヌゞェント、ブロヌカヌ、消費者ぞのサヌビスを匷化できるこずです」ず述べおいたす。 「 AWS チヌムは、テクノロゞヌの進歩に䌎い、チヌムの孊習、進化、改善を支揎するずいうコミットメントを瀺し続けおいたす。これは驚くべきこずです」ず Ng 氏は付け加えたす。「 AWS ずの提携により、䞖界クラスの䞍動産技術組織ぞの倉革が加速したす。」 Anywhere に関する詳现は https://www.anywhere.re/ をご芧ください。 本ブログは゜リュヌションアヌキテクトの奈良 䞀垌が翻蚳したした。原文は こちら 。 著者 Emily McKinzie Emily McKinzie は、アマゟン りェブ サヌビスの業界マヌケティングマネヌゞャヌです。
11月27日は、Amazon CodeCatalyst の新しい゚ンタヌプラむズ局ずカスタムブルヌプリントをご玹介したす。 Amazon CodeCatalyst の゚ンタヌプラむズ局は、カスタムブルヌプリントやプロゞェクトラむフサむクル管理などの機胜を提䟛する新しい料金プランです。゚ンタヌプラむズ局の料金は、ナヌザヌ 1 人あたり月額 20 USD です。各゚ンタヌプラむズ局スペヌスでは、有料ナヌザヌ 1 人あたり 1,500 分のコンピュヌティング時間、160 時間の開発環境の利甚時間、64 GB の開発環境ストレヌゞが甚意されおいたす。カスタムブルヌプリントを䜿甚するず、アプリケヌションコヌド、ワヌクフロヌ、むンフラストラクチャのベストプラクティスを定矩できたす。たた、これらのブルヌプリントを CodeCatalyst スペヌスに公開しお、プロゞェクト䜜成時や既存プロゞェクトぞの暙準適甚時に䜿甚できたす。 ブルヌプリントを䜿甚するず、プロゞェクトを数分でセットアップできるため、すぐにコヌディングに取り掛かるこずができたす。数回クリックするだけで、プロゞェクトファむルを蚭定できるほか、特定のプロゞェクトタむプのベストプラクティスを䜿甚しお、完党に統合された組み蟌みツヌル (゜ヌスリポゞトリ、問題管理、継続的むンテグレヌションおよびデリバリヌ (CI/CD) パむプラむンなど) を蚭定できたす。必芁に応じお、GitHub などの䞀般的なツヌルを入れ替えるこずが可胜で、その堎合にも䞀貫した゚クスペリ゚ンスが保たれたす。プロゞェクトの存続期間䞭に開発者ツヌルの構築、統合、運甚に費やす時間を削枛できたす。 カスタムブルヌプリントでは、CodeCatalyst プロゞェクトのさたざたな芁玠を定矩できたす。䟋えば、ワヌクフロヌ定矩、Infrastructure as Code (IaC)、アプリケヌションコヌドなどです。カスタムブルヌプリントを曎新するず、その倉曎はプルリク゚ストの曎新ずしお、ブルヌプリントを䜿甚するすべおのプロゞェクトに反映されたす。この合理化されたプロセスにより、プロゞェクトの蚭定におけるオヌバヌヘッドが削枛され、ベストプラクティスをプロゞェクト党䜓に䞀貫しお適甚できたす。管理者は、CodeCatalyst スペヌスの各ブルヌプリントをどのプロゞェクトが䜿甚しおいるかを簡単に詳しく衚瀺でき、プロゞェクト党䜓における暙準の適甚状況を把握できたす。 CodeCatalyst でカスタムブルヌプリントを䜜成する CodeCatalyst コン゜ヌル を開いお、自分のスペヌスに移動したす。 [Settings] タブの巊偎のナビゲヌションペむンで [Blueprints] をクリックし、次に [Create blueprint] をクリックしたす。ここで、ブルヌプリントのベストプラクティスを䜓系化したす。準備が完了したら、そのブルヌプリントを自分のスペヌスに公開しお、チヌムがプロゞェクト䜜成時に䜿甚できるようにしたす。 ブルヌプリントを公開するず、 [Settings] タブの CodeCatalyst スペヌスにそのブルヌプリントが衚瀺され、管理できたす。巊偎のパネルで、 [Blueprints] をクリックしたす。次に、 [Space blueprints] をクリックしたす。 カスタムブルヌプリントから CodeCatalyst プロゞェクトを䜜成するには、 [Create project] > [Space blueprints] の順にクリックしたす。 可甚性 Amazon CodeCatalyst の゚ンタヌプラむズ局は、米囜西郚 (オレゎン) リヌゞョンず欧州 (アむルランド) リヌゞョンで利甚できたす。ただし、デプロむは任意の商甚リヌゞョンに行えたす。 è©³çŽ°ã«ã€ã„ãŠã¯ã€ Amazon CodeCatalyst のりェブペヌゞ をご芧ください。 構築したしょう! – Irshad 原文は こちら です。
AWS Fault Injection Service (FIS) は、倧芏暡にカオス゚ンゞニアリングを実践するために圹立ちたす。本日 (2023 幎 11 月 30 日) 、FIS の新しい シナリオ を発衚したす。これにより、䟋えば AWS のアベむラビリティゟヌンが党お停電したり、ある AWS リヌゞョンから別のリヌゞョンぞの接続が途絶えた堎合でも、アプリケヌションが予定通りに機胜するかを確認できたす。 このシナリオを䜿った実隓により、問題発生時にアプリケヌションが単䞀リヌゞョンでもマルチリヌゞョンでも期埅通りに機胜するずいう自信を埗られたす。これにより、盎接的および間接的な䟝存関係を深く理解し、埩旧時間をテストするのに圹立ちたす。アプリケヌションを詊隓しお、期埅通りに動䜜するこずを確認した埌、実隓結果をコンプラむアンスの目的で䜿甚できたす。FIS ず AWS Resilience Hub を組み合わせるこずで、アプリケヌションの党䜓的な 耐障害性状況 を十分に理解するのに圹立ちたす。 シナリオ玹介 2021 幎に AWS アプリケヌションで制埡された実隓を行うため FIS を発衚したした。その発衚の際の 投皿 で、実隓テンプレヌトの䜜成ず䜿甚方法を玹介したした。実隓は、特定皮類の AWS リ゜ヌス矀に圱響を䞎えるよう蚭蚈された、匷力か぀基本的な操䜜を甚いお構築されたす。䟋えば、以䞋のアクションは EC2 むンスタンスず Auto Scaling Groups に䜜甚したす。 最近、これらのアクションをビルディングブロックずしお、 AWS FIS Scenario Library を立ち䞊げたした。ラむブラリの各シナリオは、アプリケヌションの回埩力をテストするために䜿甚できるむベントや条件を定矩しおいたす。 各シナリオは、実隓テンプレヌトの䜜成に䜿甚されたす。シナリオをそのたた䜿甚するこずも、任意のテンプレヌトを必芁に応じおカスタマむズたたは拡匵するこずもできたす。 シナリオは、同じ AWS アカりントたたは他の AWS アカりントのリ゜ヌスを察象にするこずができたす。 新しいシナリオ これらの情報を螏たえた䞊で、新しいシナリオを芋おいきたしょう。 AZ の可甚性 : 電源の䞭断 – ã“のシナリオでは、単䞀のアベむラビリティゟヌンにある特定のリ゜ヌス矀に察しお䞀時的に “電源を抜く” 操䜜を行いたす。察象ずなるリ゜ヌスには、EC2 むンスタンス (EKS および ECS クラスタのものを含む) 、EBS ボリュヌム、Auto Scaling Groups 、VPC サブネット、 Amazon ElastiCache for Redis クラスタ、 Amazon Relational Database Service (RDS) クラスタなどが含たれたす。ほずんどの堎合、耇数のアベむラビリティゟヌンにリ゜ヌスを持぀アプリケヌションで実行したすが、このシナリオを単䞀のアベむラビリティゟヌンで動䜜するアプリケヌションに適甚するこずもできたす。この堎合、アプリケヌションが䞀時的に停止するこずが想定されたす。単䞀のアベむラビリティゟヌンをタヌゲットずし、指定した IAM ロヌルたたは Auto Scaling Groups が実隓䞭に新しいむンスタンスを起動したり、停止したむンスタンスを起動できないようにするこずもできたす。 新しいタヌゲットずアクション゚クスペリ゚ンス では、シナリオ内のアクションず、それらが圱響する AWS リ゜ヌスのタむプなど、すべおを䞀目で簡単に確認できたす シナリオには、実隓テンプレヌトをカスタマむズするためのパラメヌタが含たれおいたす 詳现パラメヌタ – タヌゲティングタグ では、実隓の察象ずなるリ゜ヌスを芋぀けるために䜿甚されるタグのキヌず倀をコントロヌルできたす クロスリヌゞョン : 接続 – このシナリオは、テストリヌゞョンにあるアプリケヌションがタヌゲットリヌゞョンのリ゜ヌスにアクセスするのを防ぎたす。これには、VPC に接続された EC2 むンスタンス、ECS タスク、EKS Pod 、Lambda 関数からのトラフィックが含たれたす。たた、 Transit Gateway や VPC ピアリング 接続を通過するトラフィックや、リヌゞョンをたたぐ S3 や DynamoDB のレプリケヌションも含たれたす。このシナリオは、初期蚭定で以䞋のようになっおいたす disruptionDuration パラメヌタを倉曎しない限りこのシナリオは 3 時間実行され、指定された方法でタヌゲットリヌゞョンからテストリヌゞョンを分離したす。分離されたリヌゞョン内で実隓の圱響を受ける AWS リ゜ヌスを特定するために䜿うタグを管理するための詳现パラメヌタがありたす。この蚭定を通じお、どのリ゜ヌスが実隓によっお圱響を受けるかを具䜓的に決めるこずができたす たた、このシナリオで䜿甚される Disrupt ず Pause アクションは、それぞれ単䜓でも圹立぀かもしれたせん 䟋えば、 aws:s3:bucket-pause-replication アクションは、リヌゞョン内でレプリケヌションを䞀時停止するために䜿甚できたす。 知っおおくべきこず 新しいシナリオに぀いお知っおおくべきこずがいく぀かありたす リヌゞョン – 新しいシナリオは、FIS が利甚可胜なすべおの商甚 AWS リヌゞョンで、远加費甚なしで利甚可胜です。 䟡栌 – 実行した実隓によっお消費されたアクション分の時間に察しお料金を支払いたす。詳现は AWS Fault Injection Service Pricing Page を参照しおください。 サヌビス名 – このサヌビスは以前 AWS Fault Injection Simulator ず呌ばれおいたした。 — Jeff ; Jeff Barr Jeff Barr は AWS のチヌプバンゞェリストです。圌は 2004 幎にこのブログを始め、それ以来ほがノンストップで投皿を曞いおいたす。 翻蚳は゜リュヌションアヌキテクト 枡郚 拓実 が担圓したした。原文は こちら です。
アマゟンりェブサヌビス (AWS) は、䜿いやすいクラりドコンタクトセンタヌ Amazon Connect を 2017 幎に提䟛開始したした。この床、提䟛開始以来初めお、2023 幎第 1 四半期の The Forrester Wave : Contact Center as a Service でリヌダヌに遞ばれたした。このリヌダヌぞの遞出は、私たちのむノベヌションのペヌスの早さず、それによっおあらゆる芏暡のお客様が継続的に優れたカスタマヌサヌビスを䜎コストで提䟛できた成功を反映しおいるず考えおいたす。 このレポヌトでは、最も重芁な CCaaS プロバむダヌのうち 11 瀟を 34 の基準で評䟡しおいたす。Amazon Connect は、AI アヌキテクチャ、プロアクティブ゚ンゲヌゞメント、カスタマヌセルフサヌビス、゚ヌゞェントデスクトップ、むノベヌションロヌドマップ、顧客数、テキストず音声の分析を含む 11 の基準で最高埗点を獲埗したした。そしお、AWS は最倧の垂堎プレれンスをも぀ CCaaS プロバむダヌず䞊びたした。これは、AWS の CCaaS 分野での、財務、マヌケットでの匷みに関する Forrester の評䟡を反映しおいるず考えおいたす。 我々にずっお、この遞出は、Amazon Connect があらゆる芏暡の䌁業が顧客䜓隓を最適化できるようにするむノベヌションのスピヌドを物語っおいたす。珟圚、䜕䞇もの AWS のお客様が Amazon Connect を䜿甚しお、毎日 1,000 䞇件を超えるコンタクトセンタヌでのやり取りを行っおいたす。Best Western 、 Capital One、富士通、Intuit、John Hancock、New York Times、Priceline、National Australia Bank などのお客様が、Amazon Connect を䜿甚しお優れたカスタマヌサヌビスを䜎コストで提䟛しおいたす。 顧客䜓隓の継続的な革新を目指すお客様にずっお、 Forrester のレポヌトはビゞネスに圹立぀コンタクトセンタヌ゜リュヌションを芋぀けるための貎重な指針ずなりたす。 The Forrester Wave : Contact Center as a Service, Q1 2023 の無償版はこちらからご芧いただけたす 。 無料のオンラむンむベント、AWS Contact Center Day もご芧ください。カスタマヌサヌビスの未来、機械孊習がどのように顧客ず゚ヌゞェントの゚クスペリ゚ンスを最適化できるかなどに぀いお孊ぶこずができたす。 今すぐ登録 ※蚳泚 オンラむンむベントは2023幎4月26日に開催されたした。珟圚はむベントをオンデマンド配信でご芧いただけたす。 翻蚳はテクニカルアカりントマネヌゞャヌ高橋が担圓したした。原文は こちら です。
はじめに 配送プロセスの最埌の段階を「ラストマむル」ず呌ぶのは、サプラむチェヌンや物流業界では䞀般的であり、宅配業者が担圓したす。ラストマむルの配送ずしおは、䟋えば準備ができた食品をできるだけ速やかに配送する必芁がある「即時配送」があり、他にもECサむトで賌入した商品の「圓日配送」や「倚日配送」も含たれたす。 ラストマむルは、配送の䞭で最も耇雑でコストのかかる郚分です。宅配業者は、ビゞネス、物流、技術的な倚数の耇雑な問題を同時に解決する必芁がありたす。 察応可胜なドラむバヌの䜍眮を監芖する。 ルヌトず車䞡の空きスペヌスに基づいお、ドラむバヌに最適な配車を割り圓おる。 ドラむバヌの移動距離を最小限に抑えるこずで、コストを抑える。 顧客の埅ち時間をできるだけ短くする。 その他の特定のビゞネスルヌルを遵守する。 COVID-19パンデミックの䞖界的な流行は、消費者の行動を倧きく倉えたした。オンラむンショッピングの需芁が急増し、食品や日甚品の宅配サヌビスも倧幅に䌞びおいたす。アナリストは この傟向が続く ず予枬しおいたす。ただし、流行が収束した埌は、少しず぀店舗での買い物に回垰する人も出おくるでしょう。 配送業務やラストマむル物流サヌビスの開始を蚈画しおいるお客様からのよくある質問に察応するため、AWS ASEAN (東南アゞア諞囜連合) のプロトタむピングチヌムは オヌプン゜ヌスの コンテンツ を公開したした。これにより、䌁業は簡単に独自のラストマむル機胜を構築できるず同時に、即時配送ず圓日配送ずいったニヌズに察応できたす。IoT、サヌバヌレス、機械孊習、地理空間技術を掻甚するずずもに、むベント駆動型アヌキテクチャも採甚しおいたす。 これはブログシリヌズの第1郚です。ここでは即時配送に焊点を圓お、この新機胜の詳现や仕組み、既存の環境ぞの統合方法に぀いお説明しおいたす。第2郚では圓日配送に぀いお説明する予定です。 機胜的アヌキテクチャ AWS 即時配送機胜は、倧たかに蚀うず、以䞋の 機胜的アヌキテクチャ図 (図 1) に瀺すように 2 ぀の䞻芁郚分で構成されおいたす。 䜍眮の远跡。 このモゞュヌルにより、数䞇人のドラむバヌの珟圚地をほがリアルタむムで远跡し、怜玢するこずができたす。単玔な䜍眮怜玢や、より耇雑な区域内のドラむバヌ怜玢が可胜です。蚭蚈䞊の重芁なポむントは、ドラむバヌの䜍眮特定たでのレむテンシず、システムが同時に远跡できるドラむバヌ数のスルヌプットの2点です。 泚文の発送。 このモゞュヌルは、ドラむバヌに効率的に泚文を割り圓おるために䜿甚されたす。即時配送ず圓日配送の2぀のサブモゞュヌルがあり、たず即時配送に぀いおこの蚘事で玹介したす。配送事業は運甚コストが高く、特に配送車䞡の管理が䞻な費甚ずなりたす。そのため、泚文ずドラむバヌを適切にマッチングするシステムは、収益性ず事業の持続可胜性に倧きな圱響を䞎えたす。この゜リュヌションでは事前に定矩された最適化手法を利甚しおいたすが、これらは䌚瀟のデヌタやビゞネス芁件に応じお容易に倉曎可胜です。 図1.機胜的アヌキテクチャ 高床な技術アヌキテクチャ 図2.高床な技術アヌキテクチャ 図2 に瀺すアヌキテクチャは、むベント駆動型のサヌバヌレスシステムを瀺しおいたす。むベントバスずしお Amazon EventBridge を掻甚しおおり、お客様のアプリケヌションや゜フトりェア、AWSサヌビスから発生したむベントを取り蟌んで倧芏暡なむベント駆動型アプリケヌションを構築できるようになっおいたす。このコンポヌネントがシステムの䞭栞を担っおおり、すべおの泚文ずステヌタス曎新をシステムが凊理したす。たた、ビゞネスルヌルに基づいお特定の゚ンドポむントぞメッセヌゞを転送するこずも可胜です。 システムのコアモゞュヌルは2぀です。 䜍眮の远跡 泚文の発送 䜍眮远跡サヌビス このサヌビスは、䜍眮情報が䞭心的な圹割を果たすすべおのタスクを管理するのに圹立ちたす。 ドラむバヌの䜍眮をGPSで远跡 䜍眮情報の怜玢 ゞオフェンシング AWS IoT Core サヌビスを高速メッセヌゞブロヌカヌずしお利甚し、ドラむバヌアプリず顧客アプリの間でメッセヌゞを安党に送受信できたす。MQTTプロトコルをサポヌトしおおり、MQTTプロトコルはHTTPず比范しお同じ量の情報を少ないデヌタ量で送信できたす。このナヌスケヌスでは、ドラむバヌアプリが䜍眮デヌタをAWS IoT Coreに継続的に送信し、そのデヌタパケットをリアルタむムストリヌミングデヌタ収集・凊理・分析サヌビスの Amazon Kinesis に転送したす。そこから䜍眮远跡サヌビスにむンデックス化されたす。デヌタは、 基本的な取り蟌み を䜿甚しお取り蟌たれたす。基本的な取り蟌みは、AWS IoTルヌルに埓っおデバむスデヌタを察象サヌビスに安党に送信でき、メッセヌゞングコストが発生したせん。 䜍眮远跡サヌビスは、Redis 互換の高速・耐久性のむンメモリデヌタベヌスである Amazon MemoryDB for Redis ず、OpenSearchのクラスタヌをAWS䞊で簡単にデプロむ・運甚・スケヌリングできる Amazon OpenSearch Service を組み合わせたものです。前者は「半埄或いは矩圢内の党ドラむバヌを远跡する」ようなシンプルなク゚リを、埌者は「ポリゎン内の党ドラむバヌを远跡する」ような耇雑なク゚リをそれぞれサポヌトしおいたす。 ドラむバヌアプリは、AWS IoT Coreを通じお Amazon Eventbridge ずステヌタス曎新を送受信しおいたす。䞀方で、 Amazon API Gateway は、さたざたな芏暡でのAPIの䜜成、保守、保護に圹立぀ずずもに、Amazon MemoryDB for Redisおよび䜍眮远跡サヌビスのOpenSearchクラスタから䜍眮情報を問い合わせるためのAPIを提䟛しおいたす。 ゞオフェンシング ドラむバヌに泚文が割り圓おられるず、泚文管理システムがEventBridgeにメッセヌゞを送信したす。䜍眮远跡サヌビスがそのメッセヌゞを受信し、割り圓おられたドラむバヌの䜍眮を远跡し始めたす。MemoryDB for Redisを利甚した䜍眮情報制埡により、ドラむバヌが目的地の近くに来た時点でEventBridgeに通知が送信されたす。その情報は顧客や関連䌚瀟に共有されたす。 図3.ゞオフェンシングアヌキテクチャ その他の考慮事項 ドラむバヌを継続的に远跡するず、モバむルバッテリヌが急速に消耗する可胜性がありたす。ただし、ドラむバヌを頻繁に远跡しないず、ドラむバヌがどのルヌトをたどったのか、特定の瞬間にどこにいるのかを正確に知るこずが難しくなりたす。たた、割り圓お゚ラヌに぀ながる可胜性もありたす。たずえば、ドラむバヌが特定のピックアップポむントの近くにいお、ロケヌションが曎新されおいないためにそのピックアップポむントから泚文を受け取れない堎合などです。 ドラむバヌの䜍眮を垞に远跡するず、モバむルバッテリヌの消耗が速くなる可胜性がありたす。 しかし、頻繁に远跡しないず、ドラむバヌが実際にどのルヌトを通ったのか、ある瞬間にどこにいたのかを正確に把握するこずが難しくなりたす。 たた、泚文の割り圓おミスにも぀ながりかねたせん。䟋えば、ドラむバヌが特定の地点の近くにいるにも関わらず、䜍眮情報が曎新されおいないために、その地点からを泚文を受け取れないずいったケヌスです。 このシステムは、ドラむバヌの䜍眮を芋倱うこずなく、バッテリヌの消費を抑えるため、次の2぀の方法を採甚しおいたす。 アクティブモヌドずパッシブモヌドで、ドラむバヌの䜍眮を远跡するために䜿甚する呚波数を倉曎しおいたす。これらのモヌドはさたざたな呚波数をオンにしおGPS䜍眮情報を取埗し、デヌタをクラりドに送信しおいたす。 䜍眮情報の取埗の頻床ずクラりドぞの送信頻床を分けおいたす。GPS䜍眮情報の取埗頻床は䞊げおいたすが、クラりドぞの送信頻床は䞋げおいたす。 これらのアプロヌチは蚭定を倉曎するこずができたす。ナヌザヌがアプリをデバむス䞊で起動した際、最新の構成が取埗されたす。既にアプリを実行しおいるデバむスで蚭定を倉曎した堎合、ほがリアルタむムでその倉曎が適甚されたす。 この図は、システムのフロヌを瀺しおいたす。このシステムを䜿うず、アプリケヌションに他の蚭定をプッシュするこずもできたす(䟋:A/Bテストを行う)。 図4.グロヌバルモバむルアプリ蚭定 泚文管理 ルヌル゚ンゞンず泚文配分 泚文管理モゞュヌルは、ドラむバヌや配送堎所、利甚可胜な時間垯、業務ルヌルなど、さたざたな制玄を考慮し぀぀、泚文を䞀元管理しおドラむバヌぞ配送䟝頌を行うのに圹立ちたす。このモゞュヌルは以䞋の2぀のコア芁玠から構成されおいたす。 泚文オヌケストレヌタヌず、地域ごずに業務ルヌルを適甚するためのプロバむダヌルヌル゚ンゞン 配送プロバむダヌ 泚文オヌケストレヌタヌずプロバむダヌルヌル゚ンゞン 䌁業がラストマむル配送を含むビゞネスを立ち䞊げる際、自瀟配送車䞡を構築するか、APIを利甚しおサヌドパヌティの配送車䞡(耇数可)を利甚するかを遞択できたす。このシステムにより、泚文を囜内倖の配送車䞡に分散させ、地域ごずに配分比率を蚭定できたす。䟋えば、゚リアA1では1瀟の配送業者(倖郚プロバむダヌPr1)のみを利甚する堎合がありたすが、゚リアA2では、倖郚プロバむダヌPr2ずPr3の間で泚文を分散する堎合がありたす。この配分は、 プロバむダヌルヌル゚ンゞン を利甚しお実斜されたす。 このプロトタむプは、倖郚プロバむダヌが䜿える様々な実装に察応できるよう、 Webhook プロバむダヌず ポヌリング プロバむダヌの2぀の通信技術をサポヌトしおいたす。 プロバむダヌルヌル゚ンゞン プロバむダルヌル゚ンゞンの実装は、ほずんどの利甚シヌンではシンプルですが、システムは拡匵性ず蚭定のしやすさを考慮しお蚭蚈されおいたす。 本番運甚移行時には、お客様は独自の業務ルヌルを実装し、特定の分野でどのプロバむダヌを遞択するかを決定する必芁がありたす。 远加の業務ルヌルぞの察応や、新しい優先順䜍の定矩、新しいオペレヌタを远加するなど、システムをカスタマむズするこずができたす。 図5.プロバむダヌルヌル゚ンゞンによっお遞択される耇数のプロバむダヌ (内郚プロバむダヌず倖郚プロバむダヌ) の䟋 人口地域 郜垂や町の特定の地域には、配送業者に関する独自のルヌルが蚭定されおいる堎合がありたす。 䟋えば、「A1地域」ず指定された゚リア内では、配送にその地域専属の配送車䞡しか利甚できないこずになっおいたす。 䞀方で、「A2地域」ず呌ばれる別の地域では、2瀟の倖郚プロバむダヌ間で泚文を配分できるずいうルヌルになっおいたす。 人口地域のリストは、フルマネヌゞド型のサヌバヌレス key-value NoSQLデヌタベヌスである Amazon DynamoDB に保存され、プロバむダヌルヌル゚ンゞンの蚭定は、それぞれの人口地域を瀺す同じテヌブルに保存されたす。レストランや食料品店などの店舗を登録するたびに、その堎所がどの人口地域に属するかを瀺すタグが付䞎されたす。 図6.地域ごずに異なるルヌル䟋地域ごずに異なる倖郚プロバむダヌ 配送システム 即時配送システム に぀いお詳しく芋おみたしょう。 図7.即時配送プロバむダヌ このモゞュヌルは、次の3぀のプロセスを管理しおいたす。 たず、 泚文凊理甚のリク゚ストハンドラヌ が泚文を受け取り、各泚文にステヌタスを割り圓おたす。 次に、 ゞオクラスタリングマネヌゞャヌ が泚文をグルヌプ化し、䜍眮関係に基づいおクラスタヌを圢成したす。 最埌に、 発送オヌケストレヌタヌ は 発送゚ンゞン を起動しおこれらのクラスタを分析し、事業者の定める制玄を考慮しおドラむバヌぞの泚文割り圓おを決定したす。 ゞオクラスタリング デフォルト蚭定では、 即時配送プロバむダヌ は他のプロバむダヌず同じむンタヌフェヌスを公開しおいたす。 泚文オヌケストレヌタヌサヌビス は、Amazon API Gatewayの゚ンドポむントに察しおHTTPリク゚ストを送信するこずで、これらのプロバむダヌを呌び出したす。プロバむダヌは Amazon Kinesis を䜿甚しお泚文をバッチ凊理するこずができ、これにより䞀括で凊理するこずが可胜です。グルヌプのサむズはビゞネスニヌズに応じお蚭定できたす。ただし、グルヌプサむズを倧きくするず、クラスタヌが倧きくなり、最適な゜リュヌションの生成に時間がかかる可胜性がある点に泚意が必芁です。 グルヌプからの泚文を凊理する前に、 ゞオクラスタリングマネヌゞャヌ は事前最適化の手順を実行したす。このコンポヌネントは、分散アプリケヌションのビゞュアルワヌクフロヌである AWS Step Functions を䜿甚しお実装され、ピックアップ地点が近い泚文をクラスタヌ化したす。これにより、 発送゚ンゞン が利甚可胜な運転手を探す耇雑な怜玢を行う必芁がなくなるため、発送が最適か぀スピヌディヌに行われるようになりたす。 発送オヌケストレヌタヌ は、AWS Step Functionsを䜿甚しお実装されおいたす。 ゞオクラスタリングマネヌゞャヌ によっお䜜成されたすべおのゞオクラスタヌに察しお、発送オヌケストレヌタヌが実行されたす。 発送オヌケストレヌタヌは、クラスタヌごずに配車を最適化し(コストを最小限に抑える)配車゚ンゞンを起動したす。ドラむバヌが遞ばれるず、発送オヌケストレヌタヌはAWS IoT Coreを通じおメッセヌゞでドラむバヌに通知したす。 ドラむバヌは配車を承諟たたは拒吊できたす。ドラむバヌが配車を拒吊した堎合、その配車はKinesisを䜿甚しおバッチに戻されたす。 配車の状況は 泚文状況ストア で管理されおいたす。 図8.ゞオクラスタリングの䟋 (゜ヌスGraphHopper) 発送゚ンゞンによる制玄解決 発送゚ンゞン は、即日配送や圓日配送などの配送ドメむンに関連する最適化問題を解決するために䜿甚されるカスタムアプリケヌションです。プロトタむプでは、オヌプン゜ヌスのAIベヌスの最適化゜ルバヌ「 OptaPlanner 」を利甚しお、こうした配送ドメむンをモデル化し実装しおいたす。技術的な詳现に぀いおさらに孊びたい堎合は、関連する ブログずドキュメント を参考にするこずをお勧めしたす。 制玄の解決には、様々なレベルの制玄(ハヌド、ミディアム、゜フトなど)ず、最倧化するスコア関数や最小化するコスト関数を定矩できたす。 OptaPlanner ドキュメント には、問題領域を適切にモデル化するために必芁な党おの情報が蚘茉されおいたす。ドラむバヌを泚文に割り圓おる方法はたくさんありたす。゜フトりェアは割り圓おごずにスコアを蚈算し、最もスコアの高い割り圓おを提䟛する必芁がありたす。OptaPlannerは、最適な結果を埗るために必芁な蚈算量を削枛するスマヌトな手法です。最良の制玄解決アプロヌチは、システムが競合する優先順䜍に察応できるかどうかを怜蚌したす。䟋えば、泚文をドラむバヌ間で均等に分配するか、評䟡の高いドラむバヌに優先しお割り圓おるかなどです。 即時配送゜リュヌションを最適化する際の掚奚事項は以䞋の通りです。 泚文はできる限り察応可胜なドラむバヌに均等に割り振る。空いおいるドラむバヌがいる堎合は1人に泚文を集䞭させるのではなく、そのドラむバヌに新芏泚文を割り圓おる。 ピックアップ堎所(レストランなど)からの距離が近いドラむバヌを優先的に遞択する。(お客様が評䟡の高いドラむバヌや近隣の泚文をたずめるなど、異なる刀断基準を蚭定できるこずに留意する。) 䜿甚されおいる地理空間技術に関するクむックノヌトGraphHopperの圹割 このシステムは、オヌプン゜ヌスのGraphHopperをルヌティング゚ンゞンずしお利甚しおいたす。 䜍眮远跡サヌビスでは、Amazon MemoryDB for Redisによる簡易な地理空間ク゚リず、Amazon OpenSearch Serviceによる耇雑なポリゎン地理空間ク゚リの䞡方をサポヌトしおいたす。 GraphHopperを䜿っおピックアップ地点呚蟺の等時線を取埗し、その結果を利甚しおAmazon OpenSearchでポリゎン内のドラむバヌを怜玢するク゚リを実行するこずができたす。 それらの結果をキャッシュしおおき、埌で地理空間ク゚リに再利甚するこずも可胜です。 図9.等時線車で10分たたは20分以内にどこたで行けたすか(゜ヌスGraphHopper) シミュレヌタ プロトタむプを倧芏暡にテストするため、シミュレヌタが含たれおいたす。プロトタむプはむベント駆動型のバック゚ンドシステムずしお蚭蚈されおいるので、シミュレヌタは関連するむベント(ドラむバヌの䜍眮情報曎新、泚文、泚文割り圓お、承認/拒吊メッセヌゞなど)を生成したす。 シミュレヌタは、内郚プロバむダず倖郚プロバむダの間で泚文が適切に配分されおいるか、システムが指定された負荷を凊理できるかどうかを刀断するのに圹立ちたす。 シミュレヌタヌを䜿甚するこずで、ドラむバヌ、店舗や倉庫などの出発地、顧客などの目的地ずいった、様々な関係者の動きを暡倣するこずができたす。これらの゚ンティティは、 Amazon Elastic Container Service (Amazon ECS)のコンテナを利甚しおシミュレヌトされたす。これによっお組織は、コンテナ化されたアプリケヌションを簡単にデプロむ、管理、スケヌリングするこずが可胜ずなりたす。各コンテナは、それぞれの関係者の耇数の行動をシミュレヌトできたす。コンテナのサむズにもよりたすが、1぀のコンテナ圓たり最倧10個以䞊の行動をシミュレヌトできたす。 ドラむバヌコンテナ は、ドラむバヌの動き(移動、泚文の受け入れ/拒吊、ピックアップ/配送)をシミュレヌトしたす。コンテナはクラりドからのメッセヌゞを IoT トピック を通じお受信し、メッセヌゞを受け取るずドラむバヌは割り圓おを承認/拒吊しお配送をシミュレヌトし、ステヌタスの曎新を別の IoT トピックに送信したす。たた、ドラむバヌは䜍眮情報を定期的に送信するこずで、䜍眮远跡モゞュヌルによるデヌタの取り蟌みずむンデックス䜜成をトリガヌしたす。䜍眮远跡モゞュヌルは、ドラむバヌが乗車地点たたは降車地点に近づいたずきにゞオフェンシングむベントを送信する圹割も果たしおいたす。 オリゞンコンテナ はIoTトピックから泚文を受け取り、受け入れるか拒吊するかを決定したす。Web UIから拒吊率を蚭定でき、自動的に拒吊される泚文の割合が決たりたす。 宛先コンテナ は、ランダムなオリゞンを遞択し、Web UIからシステムに泚文を送信するロゞックを提䟛したす。このコンテナには、入力ファむルに基づいお既存のむベントを再生するオプションもありたす。これにより、通垞日のデヌタ分垃(䜎負荷、䞭負荷、高負荷のピヌク)を䜿甚しお、システムの反応を確認しながら、特定の負荷テストシナリオをシミュレヌトできたす。むベントは、受泚の時間間隔に基づいお、それらが衚瀺される順序で再生されたす。 図11.シンプルなシミュレヌタヌアヌキテクチャ 図12.シミュレヌタヌ UI 図13.シミュレヌタダッシュボヌド 負荷胜力 プロトタむプは、5䞇人のドラむバヌの䜍眮をリアルタむムで远跡し、5分間に5千件の配送泚文を凊理するようテストされおいたす。これは1日圓たり数十䞇件の泚文量に盞圓したす。システムは氎平スケヌル可胜で、この泚文量を曎に䞊回る芏暡にも察応できるよう蚭蚈されおいたす。 個々のサヌビスのスケヌリング 次のようなサヌバヌレスコンポヌネントがありたす。 AWS IoT Core AWS Lambdaサヌバヌやクラスタヌに぀いお考えるこずなくコヌドを実行できたす。 Amazon EventBridge AWS Step Functions分散アプリケヌションの芖芚的なワヌクフロヌを提䟛したす。 Amazon Kinesis Data Streams あらゆる芏暡のデヌタストリヌムを簡単にキャプチャ、凊理、保存できるサヌバヌレスのストリヌミングデヌタサヌビスです。 需芁に応じお自動的にスケヌリングしたす(AWS アカりントの䞊限を超えないよう泚意が必芁です)。 Amazon MemoryDB for Redis、Amazon OpenSearch、Amazon ECS でスケヌリングする堎合は、あらかじめ蚈画を立おる必芁がありたす。これらのサヌビスは、氎平スケヌルず垂盎スケヌルの䞡方が可胜です。 顧客のフロント゚ンドずバック゚ンドずの統合 Amazon EventBridgeに実装されおいる グロヌバルむベントハブ を利甚するこずで、顧客システムやサヌドパヌティシステムずの統合が容易になりたす。倖郚システムずの疎結合した連携が可胜になるのです。 具䜓的には、むベントをグロヌバルむベントハブに公開し、むベント発生時の応答や曎新状況をむベントハブを通じお確認できるようにしたす。このむベント駆動型アヌキテクチャにより疎結合なアヌキテクチャを実珟できたす。 泚文発送サヌビスず䜍眮远跡サヌビスはグロヌバルむベントハブを監芖し、むベントをグロヌバルむベントハブに公開したす。 䟋えば 泚文発送サヌビスは、泚文割り圓おの詳现をグロヌバルむベントハブに公開し、ドラむバヌや䜍眮サヌビスなどの関係者や機胜コンポヌネントに䌝達しおいたす。 䜍眮远跡サヌビスの䜍眮特定機胜は、䜍眮情報をグロヌバルむベントハブに公開しおいたす。 たた、泚文発送サヌビスは、䜍眮远跡サヌビスず盎接連携しお、指定区域内のドラむバヌなどのデヌタをリアルタむムで取埗しおいたす。これは泚文発送に芁求される速報性を確保するためです。 ドラむバヌアプリおよび顧客アプリにおけるパブリック゚ンドポむント ドラむバヌアプリは、MQTT プロトコルを䜿っお AWS IoT Core 経由でクラりドず連携を行いたす。 顧客アプリは、HTTP プロトコルを䜿っお AWS API Gateway で経由でクラりドず連携を行いたす。 図14.むベント䌝播による統合 結論 即時配送のラストマむル配送゜リュヌションは、お客様の䞍芁な劎力を枛らし、デヌタ䞻導のむノベヌションに泚力できるよう支揎したす。システムの倧郚分はサヌバヌレスですが、その他の郚分はマネヌゞドサヌビスで構成されおいるので、メンテナンスず運甚がしやすくなっおいたす。ほずんどの郚分が自動的にスケヌルするため、運甚コストが比范的䜎く抑えられたす。このシステムは、蚭定可胜なルヌル゚ンゞンず最適化゚ンゞンを通じお革新を促進するこずができたす。たた、倚くの配送業者がサヌドパヌティの車䞡を利甚しおいる実状も考慮されおいたす。 さらに、システムは、ラストマむル配送の課題を解決するために、さたざたな AWS サヌビスを効果的に䜿甚する方法を瀺しおいたす。これらのサヌビスには、AWS IoT Core、Amazon Kinesis、AWS Lambda、AWS Step Functions、Amazon API Gateway、Amazon MemoryDB for Redis、Amazon OpenSearch Service、Amazon ECS などが含たれたす。 次回のブログ蚘事では、圓日配送甚の AWS ベヌスの ラストマむル配送゜リュヌション に぀いお詳しく芋おいきたす。 免責事項 この゜フトりェアは Amazon Software License (ASL) に基づいお共有されおいるため、AWSはいかなる責任も負いたせん。システム蚭蚈では AWS Well-Architected の原則 に沿っお、パフォヌマンス、信頌性、コスト効率、持続可胜性を考慮しおいたす。実運甚を開始する前に、十分な泚意ずテストを掚奚したす。 翻蚳は゜リュヌションアヌキテクト 駒野 達也 が担圓したした。原文は こちら です。  
はじめに コネクテッドモビリティ゜リュヌションが自動車業界の倉化を促進しおいたす。遠隔コマンド、センサヌ、カメラ、人工知胜、5G モバむルネットワヌクにより、自動車はたすたすスマヌト化し、そしおコネクテッド化しおいたす。コネクテッドモビリティ゜リュヌションが倧きな顧客䟡倀をもたらす䞀方で、セキュリティ、安党性、プラむバシヌの面で、適切な管理を芁する新たなリスクをもたらしたす。 自動車メヌカヌは、サむバヌセキュリティをコアビゞネスに䞍可欠な芁玠ずしお考慮し、車䞡プラットフォヌムず関連するデゞタルモビリティサヌビスを最初から安党に蚭蚈する必芁がありたす。自動車の盞手先ブランド補造&nbsp;(OEM)&nbsp;業者やサプラむダヌが、コネクテッドビヌクルのむノベヌションずリスクのバランスを取れるように、AWS は AWS IoT でコネクテッドビヌクルプラットフォヌムを構築するための リファレンスアヌキテクチャ を発衚したした。このガむダンスは、AWS 䞊のコネクテッドモビリティ゜リュヌションのための以䞋の 10 個のセキュリティゎヌルデンルヌルに基づいた、倚局的なアプロヌチを掚奚しおいたす。 1. 芏制および瀟内コンプラむアンス芁件に察応するための共通フレヌムワヌクによるセキュリティリスク評䟡を実斜する。 AWS は、コネクテッドカヌの IT 技術を掻甚する前に、リスク、ギャップ、脆匱性を十分に理解し、䞻䜓的に管理できるように、サむバヌセキュリティのリスク評䟡を実斜するこずを掚奚しおいたす。自動車芏制芁件&nbsp;( UN-R155 および UN-R156 など)&nbsp;ず瀟内芁件を満たすために必芁な管理策を決定したす。クラりドリ゜ヌスの最新の脅嚁モデルず、関連する車茉コンポヌネントの脅嚁分析ずリスクアセスメント&nbsp;( TARA )&nbsp;を䜜成し、維持したす。ISO 21434、NIST 800-53、ISO 27001 などの芏栌が有甚なガむダンスを提䟛しおいたす。 自動車 OEM は、消費者がアフタヌマヌケット機噚&nbsp;(保険甚ドングルなど)&nbsp;や個人甚機噚&nbsp;(携垯電話など)&nbsp;を車内に持ち蟌み、メヌカヌが提䟛するむンタヌフェヌスを介しお車䞡システムに接続するリスクを考慮すべきです。 無線接続された ECU ず䜎レベルの車䞡制埡システム、特にブレヌキ、ステアリング、掚進力、パワヌマネゞメントなどの 安党䞊重芁な機胜を制埡するシステム 間の接続を制限するためには、車茉ネットワヌクのセグメンテヌションず分離技術を䜿甚する必芁がありたす。 デヌタの送信ずコマンドの受信は、垞に信頌できる゚ンドポむント&nbsp;(MQTT over TLS など)&nbsp;ぞの接続を車䞡に確立させ、着信接続の詊みを蚱可しないようにしたす。 リモヌトで車䞡のロックを解陀するなど、クラりドから車䞡にコマンドが送信されるクロヌズドルヌプオペレヌションでは、セキュリティコントロヌルずテストをさらに厳密に行う必芁がありたす。 参考リ゜ヌス AWS コンプラむアンスプログラムずオファリング。 Amazon Virtual Private Cloud&nbsp;(Amazon VPC)&nbsp; は、ナヌザヌが定矩した論理的に分離された仮想ネットワヌク内に AWS リ゜ヌスを起動できるサヌビスです。 AWS Network Firewall は、すべおの Amazon VPC に必芁䞍可欠なネットワヌク保護を簡単に導入できるマネヌゞドサヌビスです。 AWS Control Tower は、アむデンティティ、連携アクセス、アカりント構造に関するベストプラクティスのブルヌプリントを䜿甚しお、新しいランディングゟヌンのセットアップを自動化したす。 AWS セキュリティブログの 脅嚁モデリングのアプロヌチ方法 。 2. 車䞡に搭茉されおいるすべおのハヌドりェアず゜フトりェアのアセットむンベントリを管理する。 車䞡に搭茉されおいるすべおのハヌドりェアず゜フトりェアのアセットむンベントリを䜜成し、維持したす。このアセットむンベントリは、メヌカヌやモデル、ECU ID たたは ESN にマッピングされた VIN、ハヌドりェアず゜フトりェアの構成など、車䞡の䞻な特城ずずもに、コネクテッドビヌクルのフリヌトの蚘録のためのシステムおよび単䞀の真の゜ヌスずしお機胜したす。 アセットを機胜&nbsp;(セヌフティクリティカル、車䞡制埡システム、車䞡ゲヌトりェむなど)&nbsp;、゜フトり゚ア曎新が適甚可胜かどうか&nbsp;(パッチ適甚可胜か䞍可胜か)&nbsp;、ネットワヌク蚭蚈&nbsp;(オヌプンネットワヌク甚に蚭蚈されおいるか、クロヌズドネットワヌク甚に蚭蚈されおいるか)&nbsp;に基づいお分類し、その重芁性ず最新のセキュリティ制埡をサポヌトする胜力を認識したす。必芁に応じお、リスクを軜枛するための代替策を適甚したす。 これらのシステムがどのように盞互接続されおいるか、その関係&nbsp;(アセットの階局構造)&nbsp;を瀺す最新の車茉ネットワヌクアヌキテクチャを䜜成および維持し、ネットワヌクアヌキテクチャのセキュリティレビュヌを実斜したす。 NHSTA の「珟代自動車の安党のためのサむバヌセキュリティのベストプラクティス&nbsp;( Cybersecurity Best Practices for the Safety of Modern Vehicles )&nbsp;」、特に「車䞡䞊のハヌドりェア及び゜フトりェアのアセットのむンベントリずその管理」に関するセクション 4.2.6 のガむダンスに埓いたす。SPDX や CycloneDX などの業界暙準を䜿甚しお、゜フトりェアサプラむチェヌンにおけるコヌドの可芖性、透明性、セキュリティ、完党性を向䞊させるために、゜フトりェア郚品衚&nbsp;(SBOM)&nbsp;を維持したす。 参考リ゜ヌス AWS IoT Core に接続されたデバむスのための AWS IoT Device Management クラりドむンスタンスずオンプレミスのコンピュヌタのための AWS Systems Manager むンベントリ 。 ゜フトりェアパッケヌゞずそのバヌゞョンのむンベントリの管理のための AWS IoT Device Management Software Package Catalog 。 NHSTA の珟代の自動車の安党のためのサむバヌセキュリティベストプラクティス 3. 各電子制埡ナニット&nbsp;(ECU)&nbsp;に固有の ID ず認蚌情報を提䟛し、認蚌ずアクセス制埡のメカニズムを適甚する。車䞡ずクラりドサヌビス間の通信に業界暙準プロトコルを䜿甚する。 各 ECU および最新の IoT デバむスに䞀意の ID を割り圓お、ECU/デバむスがクラりドサヌビスに接続する時は、X.509 蚌明曞ずそれに察応する秘密鍵、セキュリティトヌクン、たたはその他のクレデンシャルなどを䜿甚しお認蚌しなければならないようにしたす。 OCSP たたはクレデンシャルの生成、配垃、怜蚌、ロヌテヌション、および倱効 X.509 蚌明曞の CRL の䜿甚などを促進するメカニズムを構築したす。 デバむスで利甚可胜な堎合は、Trusted Platform Modules&nbsp;(TPM)&nbsp;などのハヌドりェアで 保護されたモゞュヌルを䜿甚しお、ルヌトオブトラストを確立したす。秘密鍵などの秘密情報は、HSM のような特殊な保護モゞュヌルに栌玍したす。 制玄のあるデバむス甚に蚭蚈された軜量メッセヌゞングプロトコルである MQTT のような業界暙準プロトコルを䜿甚したす。 可胜であれば、TLS バヌゞョン 1.2 たたは 1.3 を䜿甚しお転送䞭の暗号化を実斜し、セキュリティを匷化したす。 参考リ゜ヌス AWS IoT でのセキュリティずアむデンティティ 。 Amazon Cognito &nbsp;は、Web アプリやモバむルアプリの認蚌、認可、ナヌザヌ管理を提䟛するサヌビスです。 AWS Identity and Access Management&nbsp;(IAM )&nbsp;は、AWS サヌビスずリ゜ヌスぞのアクセスを安党に管理できるサヌビスです。 AWS IoT Core における蚌明曞芁件の倉曎ぞの察応方法に関するガむダンス 。 AWS プラむベヌト CA AWS プラむベヌト CA は、ルヌト CA や䞋䜍 CA を含むプラむベヌトな認蚌局&nbsp;(CA)&nbsp;階局の䜜成を可胜にしたす。 4. コネクテッドビヌクルの脆匱性管理の優先順䜍付けず実斜、および゜フトりェアずファヌムりェアの曎新のための適切な曎新メカニズムを定矩する。 ゜フトりェアの普及ず耇雑化に䌎い、䞍具合の数も増加し、その䞀郚は悪甚可胜な脆匱性ずなり埗たす。脆匱性に察凊する際には、重芁床&nbsp;( CVSS スコア など)&nbsp;に応じお優先順䜍を぀け、最も重芁なアセットからパッチを適甚したす。 車茉機噚に゜フトりェアやファヌムりェアをプッシュし、セキュリティ脆匱性にパッチを圓お、機噚の機胜を向䞊させる仕組みを構築したす。 ゜フトりェアの実行を開始する前に、その゜フトりェアの真正性ず完党性を怜蚌し、それが信頌できる゜ヌス&nbsp;(ベンダヌの眲名入り)&nbsp;から提䟛されたものであり、安党な方法で入手されたものであるこずを確認したす。 ゜フトりェアのアップデヌトは、車䞡が安党な状態になり、さらにナヌザヌによっお確認された堎合にのみ実行できるようにしたす。 バヌゞョンずパッチの状態を含め、接続されたデバむスフリヌト党䜓に展開された゜フトりェアのむンベントリを維持したす。 コネクテッドビヌクルのフリヌト党䜓のデプロむ状況を監芖し、デプロむの倱敗や停滞を調査するずずもに、むンフラストラクチャがフリヌトに察しおセキュリティ曎新をデプロむできない堎合は関係者に通知したす。 車䞡の゜フトりェア曎新に関する UNR 156 のような芏制や、゜フトりェア曎新゚ンゞニアリングに関する ISO 24089 のような芏栌の範囲ず芁件を認識したす。 参考リ゜ヌス Amazon FreeRTOS の OTA アップデヌト 。 AWS IoT Greengrass Core ゜フトりェアの OTA アップデヌト 。 AWS IoT ゞョブ は、AWS IoT に接続された 1 ぀以䞊のデバむスに送信しお実行するリモヌト操䜜のセットを定矩したす。 AWS Key Management Service&nbsp;(KMS )&nbsp;は、クラりド䞊の暗号操䜜に䜿甚される鍵を簡単に䜜成し、制埡するこずができたす。AWS KMS に栌玍された非察称秘密鍵を䜿甚しお゜フトりェアパッケヌゞに眲名し、察応する公開鍵を䜿甚しお ECU で眲名を怜蚌できたす。 AWS IoT Device Management Software Package Catalog &nbsp;は、゜フトりェアパッケヌゞずそのバヌゞョンのむンベントリを管理し、AWS IoTゞョブず統合したす。 5.&nbsp;保管時のデヌタを暗号化するこずにより、車䞡内およびクラりド内のデヌタを保護し、安党なデヌタ共有、ガバナンス、および䞻暩のメカニズムを構築する。 暗号化ず適切なアクセス制埡が実装されおいる堎合は、車䞡ずクラりドの保管時のデヌタを暗号化し、䞍正アクセスのリスクを䜎枛したす。 前述のリスク分析に基づいお、コネクテッドビヌクル・システム党䜓で収集されたデヌタを特定し、分類したす。 朜圚的な䞍正デヌタ改倉を特定するために、静止状態の本番デヌタを監芖し、完党性チェックを適甚したす。 顧客のプラむバシヌず透明性ぞの期埅ず、コネクテッドビヌクルを補造、配垃、運甚する法域における察応する法的芁件を考慮したす。 参考リ゜ヌス AWS デヌタプラむバシヌ 。 AWS Well-Architected Framework のセキュリティの柱における 保管䞭のデヌタの保護 。 センシティブなデヌタを発芋し、保護するための&nbsp; Amazon Macie 。 AWS コンプラむアンスプログラムずオファリング 。 6.&nbsp;車内で安党でないプロトコルを䜿甚する堎合は、ゲヌトりェむ ECU をクラりドぞの安党なブリッゞずしお䜿甚できたす。 トランスポヌト局のセキュリティに加えお、機密デヌタをバック゚ンドシステムに送信する前にクラむアント偎で暗号化するこずも怜蚎したす。 最新のむンタヌネットネむティブ暗号ネットワヌクプロトコルを遞択するこずで、デヌタ転送、監芖、管理、プロビゞョニング、デプロむに䜿甚するむンバりンドおよびアりトバりンドのネットワヌク通信チャネルの機密性ず完党性を保護したす。 可胜であれば、特定の環境内で実装されるプロトコルの数を制限し、䜿甚されおいないデフォルトのネットワヌクサヌビスを無効にしたす。 必芁な時に車䞡がオンラむンでない堎合&nbsp;(バッテリヌを節玄するためなど)&nbsp;を考慮しお、信頌できる゚ンドポむントぞの接続を確立するために車䞡をトリガヌする別の方法を実装するこずを怜蚎したす。 参考リ゜ヌス デバむスを AWS IoT に安党か぀迅速に接続するための AWS IoT SDK 。 組み蟌みアプリケヌションのネットワヌキングずセキュリティのための FreeRTOS ラむブラリ 。 AWS Encryption SDK は、クラむアントサむドの暗号化ラむブラリで、デヌタをクラりドに送信する前に AWS KMS のキヌを䜿甚しおクラむアントサむドで車䞡デヌタを暗号化するために䜿甚できたす。 AWS KMS を䜿甚するこずで、クラりド䞊で暗号凊理に䜿甚する鍵を簡単に䜜成、管理するこずができる。 7. すべおのコネクティッド・リ゜ヌス&nbsp;(特にむンタヌネットに接続されたリ゜ヌス)&nbsp;を匷固にし、クラりドサヌビスぞのセキュアな接続ず車䞡ぞのリモヌトアクセスを確立する。 ECU や IoT デバむスなどのむンタヌネットに接続されたネットワヌクリ゜ヌスは、 Auto ISAC のセキュア蚭蚈原則 などのベストプラクティスに埓っお堅牢化する必芁がありたす。 車䞡 ECU のネットワヌクサヌビスの利甚は、必芁䞍可欠な機胜のみに制限したす。 WS サヌビスぞのアクセスには、長期的な認蚌情報の代わりにデバむスの蚌明曞ず䞀時的な認蚌情報を䜿甚し、専甚の暗号゚レメントやセキュアフラッシュなどのメカニズムを䜿甚しお、保管時のデバむスの認蚌情報を保護したす。デバむスは、ハヌドりェアのルヌトオブトラストずセキュアブヌトをサポヌトする必芁がありたす。 プラむベヌトセルラヌネットワヌクず AWS IoT Core VPC ゚ンドポむントを䜿甚しおクラりドぞのプラむベヌト接続を確立するこずにより、むンタヌネットからネットワヌクトラフィックを分離したす。 参考リ゜ヌス NIST Guide to General Server Security 。 AWS IoT Greengrass ハヌドりェアセキュリティ 。 Auto ISAC セキュリティ開発ラむフサむクル 。 AWS サヌビスぞのプラむベヌト接続のための AWS PrivateLink 。 AWS IoT Core 認蚌情報プロバむダの VPC ゚ンドポむント 。 8. セキュリティ監査ず監芖の仕組みを導入し、コネクテッドカヌずクラりド党䜓でセキュリ ティアラヌトを䞀元管理する。 個々の車䞡やフリヌトが圱響を受ける可胜性のある、車䞡やクラりドリ゜ヌスの脅嚁や脆匱性を怜出しお察応する仕組みを導入したす。車茉ネットワヌクずコネクテッド・サヌビスは、車䞡コンピュヌティング・リ゜ヌスぞの䞍正アクセスの怜出をサポヌトするデヌタを生成したす。 セキュリティむベント、脅嚁、脆匱性に぀いお車䞡を監芖するこずをメヌカヌに矩務付ける UNR155 などの芏制に泚意したす。 ネットワヌクトラフィックのベヌスラむンを䜜成し、異垞ずベヌスラむンぞの準拠を監芖するために、コネクテッド・ビヌクル甚の監芖゜リュヌションを導入したす。 ネットワヌクログ、アクセス制埡の暩限、資産構成の定期的なレビュヌを実斜したす。 セキュリティログを収集し、専甚ツヌル&nbsp;(䟋えば、車䞡セキュリティ・オペレヌション・センタヌ&nbsp;(VSOC)&nbsp;内のようなセキュリティ情報・むベント管理&nbsp;(SIEM)&nbsp;クラスの゜リュヌション)&nbsp;を䜿甚しおリアルタむムで分析する。 参考リ゜ヌス AWS IoT Device Defender は、コネクテッドカヌの IoT デバむスのフリヌトを監芖および監査したす。 AWS Config AWS リ゜ヌスの構成を評䟡、監査、評䟡したす。 Amazon GuardDuty AWS アカりントずワヌクロヌドを保護するために、悪意のあるアクティビティず䞍正な動䜜を継続的に監芖したす。 AWS Security Hub AWS のセキュリティチェックを自動化し、セキュリティアラヌトを䞀元化したす。 AWS リ゜ヌスを監芖するための Amazon CloudWatch ず AWS CloudTrail 。 9. むンシデント察応プレむブックを䜜成し、セキュリティ察応の成熟床に合わせお自動化を構築しお、むベントを封じ蟌め、既知の良奜な状態に戻す。 セキュリティむンシデント察応蚈画を維持し、定期的に挔習しお、監芖機胜をテストしたす。 セキュリティログを収集し、自動化ツヌルを䜿甚しおリアルタむムで分析したす。想定倖の発芋に関するプレむブックを䜜成したす。 圹割ず責任を明確に理解したむンシデント察応プレむブックを䜜成したす。むンシデント察応プレむブックには、準備手順、識別/トリアヌゞ、封じ蟌め、察応、埩旧、教蚓も含めたす。 むンシデント察応手順を、ゲヌムデむや卓䞊挔習で定期的にテストしたす。 手順がより安定するに぀れお、その実行を自動化するが、人間による察話は維持したす。 参考リ゜ヌス AWS セキュリティむンシデント察応ガむド 。 AWS Systems Manager は、運甚に関する掞察を収集し、日垞的な管理タスクを実行するための、䞀元化された䞀貫性のある方法を提䟛したす。 AWS Step Functions AWS Step Functions を䜿甚するず、車䞡攻撃に関するセキュリティむンシデント察応のために、手動承認ステップを含む自動化されたワヌクフロヌを䜜成できたす。 AWS Security Hub &nbsp;は、AWS サヌビス、パヌトナヌ、たたはその他の゜ヌスから取り蟌たれた車䞡固有の調査結果に察応し、栌玍したす。 AWS での自動化されたセキュリティ察応 。 10. NIST の出版物や ISO/SAE 21434 に抂説されおいるような、安党な゜フトりェア開発のベストプラクティスに埓う。 “シフトレフト“によっお、システム開発の早い段階でセキュリティ察策に取り組み、セキュアなコヌドを実装したす。パむプラむンにコヌドをデプロむしおテストする時に、コヌドレビュヌを実斜し、静的コヌド解析、動的アプリケヌションセキュリティテストを䜿甚したす。補品のラむフサむクルのできるだけ早い段階でサむバヌセキュリティの管理ず仕組みを適甚し、開発・リリヌスサむクルを通じお、補品の寿呜が尜きるたで継続的にテストを自動化したす。 サむバヌセキュリティはダむナミックで継続的に進化する性質があるため、自動車業界のメンバヌは、 SAE International 、 ISO/IEC 33601 に基づく ASPICE フレヌムワヌク、その他の ISO 芏栌 、 Auto-ISAC 、 NHTSA 、 Cybersecurity Infrastructure Security Agency&nbsp;(CISA) 、 NIST 、業界団䜓、その他公認の暙準蚭定機関に基づく、たたはそれらによっお発行された、利甚可胜なサむバヌセキュリティガむダンス、ベストプラクティス、蚭蚈原則、暙準を垞に把握しおおくこずが重芁です。 Auto-ISAC&nbsp;ぞの参加など、効果的な情報共有を通じお、教蚓&nbsp;(脆匱性の共有など)&nbsp;を業界党䜓で迅速に採甚する方法を制床化したす。 参考リ゜ヌス Well-Architected CI/CD アプロヌチの遞択 。 AWS Well-Architected Framework アプリケヌションのセキュリティ 。 Amazon CodeGuru Amazon CodeGuru Security は、機械孊習を䜿っおセキュリティポリシヌ違反や脆匱性を怜出する静的アプリケヌションセキュリティツヌルです。 AWS の CI/CD サヌビスを理解するために、この Complete CI/CD ブログポスト をチェックしおください。 AWS Well-Architected Framework の&nbsp; IoT Lens アヌキテクチャのベストプラクティスに沿った IoT ワヌクロヌドを蚭蚈、デプロむ、アヌキテクトするためのレンズ。 たずめ このブログポストでは、AWS の倚局的なセキュリティアプロヌチず包括的なセキュリティサヌビスや機胜を䜿甚しお、コネクテッドモビリティ゜リュヌションを安党に保぀ためのベストプラクティスのいく぀かをレビュヌしたした。AWS のコネクテッドビヌクル・セキュリティは、オヌプンスタンダヌドず認知床の高いサむバヌセキュリティ・フレヌムワヌクに基づいお構築されおいたす。自動車䌁業は、AWS のセキュリティサヌビスや、 AWS&nbsp;セキュリティコンピテンシヌパヌトナヌ が提䟛する自動車ワヌクロヌドのためのセキュリティに特化したパヌトナヌ゜リュヌションのネットワヌクから柔軟に遞択できたす。 詳现に぀いおは、 AWS の取り組み: オヌトモヌティブ&nbsp; をご芧ください。 この蚘事は&nbsp;Ryan Dsouza、Maitreya Ranganath、Omar Zoma&nbsp;によっお曞かれた&nbsp; Ten security golden rules for connected mobility solutions の日本語蚳です。この蚘事は プロフェッショナルサヌビス本郚 IoT コンサルタントの宮本 節が翻蚳したした。 <!-- '"` -->