電子商取引市場は、過去数年間で年間成長率が大幅に伸びています。顧客の購買行動はオンラインにシフトしていますが、店頭受け取りなどの新しいトレンドも一般的になりつつあります。 米国センサス局によると 、2022 年の米国の小売電子商取引の売上高は 1 兆ドルを超え、2021 年比 7.7% 増加しました。 小売業者はデジタルコマースに大規模な投資をしてきましたが、特にブラックフライデーのようなセールスイベントのピーク時には EC トラフィックを把握するのに苦労しています。消費者行動の変化に対応するために、小売業者はアプリケーションをクラウドに移行するだけでなく、クラウドネイティブ技術を最大限に活用する必要があります。 このブログでは、非同期イベント駆動アプローチとサーバーレスサービスを使って小売注文管理システムをリファクタリングまたは再構築することで、小売業者がレジリエンシー、スケーラビリティを改善し、イノベーションに注力できるようになる方法について説明します。 ブラックフライデーの販売イベント中に深刻な障害を経験した後、LEGO はモノリシックな EC プラットフォームをリファクタリングしました。通常の販売イベント時には、LEGO はオンライントランザクションが最大 200 倍に、ユーザートラフィックが最大 9.5 倍に跳ね上がるのを経験していました。サーバーレスなイベント駆動アプローチを使ってプラットフォームをリファクタリングすることで、 トラフィックのピーク時でも問題なく対応できるようになりました 。 米国の高級小売店であるニーマンマーカスは、ストラングラーフィグ移行パターンを使ってサーバーレスに移行することで、 アプリケーションの起動時間を 50% 短縮し 、開発者の敏捷性を高め、コストを削減しました。 なぜサーバーレスのイベント駆動型アーキテクチャを選択するのか Dr. Werner Vogels は re:Invent 2022 の基調講演で 、世界は本質的に非同期的でイベント駆動型であると指摘しました。例えば、小売業における注文管理システムを考えてみましょう。顧客が EC サイトで注文をするとそれがイベントになります。顧客はほぼ即座に注文を受け付けたことの通知を受け取ります。一方、残った注文処理部分は疎結合されたサービスを通じて非同期的に処理することができます。 例えば、支払いサービスは独立して支払いを処理しステータスを返すことができます。在庫サービスは商品の在庫があるかどうかをチェックしシステムに通知することができます。これらの様々なサービスは、イベントブローカーと呼ばれる中央のハブを通じて互いに通信します。 イベント駆動型アーキテクチャの意味を説明したところで、サーバーレスについて考えてみましょう。サーバーレスとイベント駆動型アーキテクチャの相性が良いのは、AWS Lambda のようなサーバーレスサービスがイベントをトリガーにして構築されているからです。課金が発生するのはイベントが処理されている時だけです。 要約すると、サーバーレスのイベント駆動型アーキテクチャのメリットは以下の通りです。 レジリエンシー – 疎結合システムのメリットは、システムの一部品が故障してもその故障はそのコンポーネントに限定され、システムの残りの部分は影響を受けないことです。例えば配送サービスがダウンしても、チェックアウトサービスには影響しません。このため、開発者が配送サービスの修復に取り組む一方で、顧客はオンライン注文を続けることができます。LEGO が AWS 上でサーバーレスを採用することを決めたのは、大変人気のあるセールスイベント中に 2 時間近くの障害があったことがきっかけでした。 スケーラビリティ – サーバーレスサービスは、プロビジョニングなしに要求に応じて自動的にスケールします。サーバーレスであることでシステムはピーク需要時に自動的にスケールアップし、需要が少ない時にはスケールダウンしてコストを節約することができます。さらに、疎結合されたサービスは互いに独立してスケールできます。Taco Bell は、サーバーレスのイベント駆動型ミドルウェアソリューションを構築することで、 6 ヶ月で配達パートナーを 4 社追加しました 。 スピードとアジリティ – サーバーレスアプリケーションは構築が簡単で実験も容易です。イベント駆動型アーキテクチャの疎結合な性質のおかげで、アーキテクチャの進化や既存アプリケーションへの新機能の追加が迅速に行えます。スウェーデン最大のオンライン専門食料品店の MatHem.se は、AWS 上でサーバーレスと非連結アーキテクチャを採用することで、 10 倍のスピードでイノベーションを起こせるようになりました 。 小売注文管理フロー 次の図は、サンプルの小売注文管理システム内でイベントがどのように流れるか、および、それらを使用して疎結合の e コマースシステムを構築する方法の概念図を示しています。 この例は、以下のサービスを示しています: チェックアウトサービス、注文サービス、フルフィルメントサービス、倉庫管理サービス、通知サービス。 これらのサービスは、独立したマイクロサービスとして構築されているため、他のコンポーネントに影響を与えることなく、独立してスケールし、独立して失敗することができます。 異なるサービスは直接お互いと通信せず、イベントブローカーを経由して通信します。 サービスはタスクの完了時にイベントブローカーにイベントを発行し、その特定のイベントを待機している他のサービスがそれを受け取ります。 顧客が商品を注文して出荷されるまでのイベントの流れを見てみましょう。 顧客が商品を注文すると、 CheckOut Service が OrderCreated イベントを発行します。 Order Service は OrderCreated イベントを受け取ります。 Order Service は支払いを処理し、 OrderProcessed イベントを作成します。 Fulfillment Service は OrderProcessed イベントを受け取ります。 イベントを取得すると履行プロセスを開始し、エラーがなければ ShipmentPrepared イベントを発行します。 Warehouse Service は ShipmentPrepared イベントを受け取ります。 これにより、倉庫担当者にアイテムの梱包を通知します。それが完了すると、 Warehouse Service は ShipmentProcessed イベントを発行します。 Fulfillment Service は ShipmentProcessed イベントを受け取ります。 ShipmentProcessed イベントを取得すると、処理を完了させ OrderFulfilled イベントを発行します。 Notification Service は注文の受注から出荷までの進捗状況を顧客に通知するために、すべての関連イベントを受け取ります。 イベント駆動型アーキテクチャを用いて疎結合なシステムを構築する概念は、銀行、保険（ローン処理、 保険処理 など）、顧客サービス、製造など、多くの業界のユースケースに適用できます。 コンポーザブルコマースと MACH AWS がテクノロジー・イネーブラーとして参加している組織である MACH アライアンス が規定しているガイダンスに基づいてコンポーザブルコマースアプローチを採用している小売業者は、このサーバーレスのイベント駆動型パターンを採用して自社の e コマースシステムの注文管理部分を構築することができます。 MACH （マイクロサービスベース、API ファースト、クラウドネイティブ SaaS、ヘッドレスの略）により、小売業者は最善のソリューションを選択し、プラットフォームの一部を組み立て（または自社で構築）することで将来性のあるプラグイン可能なソリューションを構築できます。 まとめ このブログでは、小売注文処理のためのサーバーレスイベント駆動アーキテクチャについて説明しました。マイクロサービスやサーバーレスなどのクラウドネイティブ技術を利用した e コマースシステムは、時間当たりの市場投入能力、レジリエンシー、拡張性を向上させ、コストを削減することで、小売業者が競争優位を確保するのに役立ちます。 詳細は以下のリソースをご覧ください: サーバーレスランドにおけるイベント駆動アーキテクチャ 完璧な結合: AWS における e コマース デジタルコマースのパワーを捉える 著者について Vandana Venkatesan Vandana Venkatesan は、AWS のサーバーレスな Go-to-Market 戦略の専門家です。 Vandana は、サーバーレスファーストのアプローチを用いた AWS 上のアプリケーションモダナイゼーションを通じて、顧客が最も重要なビジネス目標を達成するのを支援しています。 Alexander Vladimirov Alexander Vladimirov は、AWS サーバーレスとアプリケーションモダナイゼーションの専門家です。ソリューションアーキテクチャとソフトウェアエンジニアリングの分野で 20 年以上の実務経験があります。彼が情熱を傾けているのはイベント駆動型アーキテクチャで、顧客のクラウド近代化の一環としてこの最新アプローチの採用を支援しています。彼は AWS サーバーレススタックを使用して、完全にサーバーレスで、スケーラブルで、堅牢で、高効率のイベント駆動型ソリューションの設計とプロトタイピングを楽しんでいます。 翻訳はソリューションアーキテクトの飯野が担当しました。原文は こちら です。

このブログは “ Considerations for security operations in the cloud ” を翻訳したものです。 サイバーセキュリティチームは多くの場合、さまざまな機能で構成されています。通常、これらには、ガバナンス、リスクとコンプライアンス (GRC)、セキュリティアーキテクチャ、アシュアランス、セキュリティオペレーションなどが含まれます。各部門には固有のタスクがありますが、他の事業部門と連携してチームがワークロードを安全に出荷して実行できるよう支援するという共通の目標に向かって取り組んでいます。 このブログ記事では、セキュリティオペレーション (SecOps) 機能の役割、特に企業や環境に最適な運用モデルを選択する際に検討すべき考慮事項に焦点を当てます。これは、組織がクラウドでより多くのワークロードに適応して運用するようになったときに特に重要になります。 ビジネスプロセスを管理する運用チームは組織の屋台骨です。業務を効率的に運営するための道を開き、どの日常的なプロセスが効果的かをしっかりと理解できるようにします。通常、これらのプロセスはランブックまたはプレイブックとも呼ばれる標準運用手順 (SOP) 内で定義され、人事、経理、IT などのビジネス機能はその周囲に集められています。これはサイバーセキュリティや SecOps にも当てはまり、通常、組織全体のセキュリティを運用上監視しています。 チームは、クラウドでワークロードをスケーリングしたり開発したりする際に、本質的にセキュリティの所有権の委任に頼る運用モデルを採用しています。このような委任が出現すると、現在サポートしているモデルを再評価する必要が出てくるかもしれません。その際には、どのような結果を得ようとしているのかを理解することが重要です。「セキュリティ問題に迅速に対応して解決できるようにしたい」「アプリケーションチームがセキュリティに関する意思決定を自分で行えるようにしたい」また、「組織のセキュリティ状況を一元的に可視化したい」とも考えています。この最後の目標は、複数のチームの運用を改善できるツールやプロセスの改善の余地がある箇所を特定するうえで重要です。 SecOps の運用モデルを設計するには、次の 3 つの方法があります。 一元化 : SecOpsが企業全体のセキュリティイベントの特定と修正を担当する、より伝統的なモデルです。これには、パッチの適用やセキュリティ構成の問題など、企業に関する一般的なセキュリティ体制の調査結果を確認することも含まれます。 分散型 : 企業全体にわたるセキュリティイベントへの対応と修復の責任は、アプリケーション所有者と個々のビジネスユニットに委任されており、一元的な運用機能はありません。それでもなお、包括的なセキュリティ統制機能は存在していて、それはよりポリシーや原則の観点が際立ったものです。 ハイブリッド : 両方のアプローチが混在しています。セキュリティイベントを特定して対応を調整する責任とオーナーシップは SecOps にある程度ありますが、修復の責任はアプリケーション所有者と個々のビジネスユニットが負います。 これらの説明から分かるように、異なるモデルの主な違いは、修復と対応を担当するチームにあります。このブログ記事では、各モデルの利点と考慮事項について説明します。 このブログ記事で紹介する戦略と運用モデルでは、SecOpsとクラウドで事業を行う組織の役割に焦点を当てます。注目すべきは、これらの運用モデルは特定のテクノロジーやクラウドプロバイダーには適用されないということです。各モデルには、考慮すべきメリットと課題があります。全体として、リスクを管理し、継続的な改善への道筋を提供しながら、最高のビジネス成果をもたらす運用モデルの採用を目指すべきです。 背景: 集中型モデル ご想像のとおり、SecOpsの最も親しみやすく、よく理解されている運用モデルは集中型です。従来、SecOpsは、ほとんど静的なオンプレミスのインフラストラクチャと、従業員のラップトップ、サーバー、データベースなどの企業資産を十分に理解している社内のセキュリティスタッフから徐々に発展してきました。 このように一元化することで、組織は使い慣れた運用モデルと構造を手に入れることができます。時間が経つにつれて、業界全体でこのモデルを運用することで、チームは一般的なセキュリティイベントに対して信頼できるSOPを開発できるようになりました。これらのインシデントに対処するアナリストは、インシデントを解決するために必要なインフラストラクチャ、環境、手順を十分に理解しています。インシデントが発生するたびに、SOP を更新し、その知識と教訓を業界全体と共有する機会が得られます。この継続的なフィードバックサイクルは、長年にわたってSecOpsチームにメリットをもたらしてきました。 セキュリティ問題が発生した場合、このモデルにおけるさまざまなチーム間の責任分担を理解することは、迅速な解決と是正のために非常に重要です。RACI モデルとも呼ばれる責任割り当てマトリックスでは、「実行責任者」、「説明責任者」、「相談先・協業先」、「報告先」という役割が定義されています。このようなモデルを利用することで、各従業員、部門、事業部門が連携して、インシデントが発生した場合にそれぞれの役割と連絡先を認識し、定義されたプレイブックを使用してインシデントに迅速に対応できるようになります。 セキュリティイベント中はプレッシャーが高まる可能性があり、生産システムが関与するインシデントはさらに重要になります。通常、集中型モデルでは、セキュリティイベントはセキュリティアナリストが監視する中央のキューに流れ込みます。一般的なアプローチはセキュリティオペレーションセンター (SOC) です。SOC では、複数のソースからのイベントが画面に表示され、キュー内のアクティビティもトリガーされます。セキュリティインシデントは、SOP に精通し、インシデントに対処する際の時間的制約の重要性を理解している経験豊富なチームによって対処されます。さらに、一元化されたSecOpsチームは通常、24時間365日のモデルで運営されています。これは、複数のタイムゾーンにチームを配置するか、MSSP（マネージド・セキュリティ・サービス・プロバイダー）の支援を受けることで実現できる場合があります。どちらの戦略をとるにしても、経験豊富なセキュリティアナリストにセキュリティインシデントに対処してもらうことは大きなメリットです。経験があると、問題を効率的かつ徹底的に修正できるようになるからです。 コンテキストと背景を考えると、一元化されたSOCはクラウドで運用されているときにどのような見た目と使い心地になるのでしょうか。また、どのような課題があるのでしょうか。 クラウドにおける集中型 SOC : メリット クラウドプロバイダーは、集中型モデルで動作する SOC 向けに多くのソリューションと機能を提供しています。たとえば、組織のクラウドセキュリティ体制全体を監視できるため、社内および業界全体での主要業績評価指標 (KPI) のベンチマークが可能になります。これにより、組織はスコアの低い分野にセキュリティイニシアチブ、トレーニング、意識向上を図ることができます。 セキュリティ オーケストレーション、オートメーション、レスポンス (SOAR) はセキュリティ業界全体でよく使われているフレーズですが、クラウドはこの機能を最大限に引き出します。ネイティブとサードパーティの両方のセキュリティサービスとソリューションを自動化と組み合わせることで、セキュリティインシデントの迅速な解決が容易になります。SOAR を使用すると、人間の介入が必要なインシデントだけがアナリストによって実際にレビューされます。調査の結果、そのアラートに自動化を導入できれば、すぐに適用できます。アラートを自動化するための一元化された場所があると、組織はセキュリティイベントへの対応に対して一貫した構造化されたアプローチをとることができ、アナリストは脅威ハンティングなどの活動に集中する時間を増やすことができます。 さらに、このような脅威ハンティング業務には、一元的なセキュリティデータレイクまたは同様のテクノロジーが必要です。その結果、SecOpsチームは、従来のサイバーセキュリティ機能であった企業全体のデータの一元化を推進できるよう支援しています。 クラウドにおける集中型SOC : 組織上の考慮事項 従来の SOC が一般的に使用する KPI には、検出までの時間 (TTD)、確認までの時間 (TTA)、解決までの時間 (TTR) などがあります。これらは、SecOpsマネージャーがSecOpsチームが社内および業界のベンチマークと比較してどの程度うまく機能しているかを理解し、ベンチマークするために使用できる優れた指標です。組織がクラウド内の幅広さと深さを活用し始めると、追跡する必要のある KPI はどのように変化するのでしょうか。前述のように、クラウドではクラウドフットプリントの可視性が高まるため、KPI を簡単に追跡できます。ただし、従来の KPI を評価して、まだ使用しても意味があるかどうかを理解する必要があります。他に検討すべき KPI には、自動化の進展、人間によるアクセスの減少、セキュリティ体制の全体的な改善を示す指標があります。 組織は、集中型SOCモデルにおける運用プロセスと能力のスケーリングファクターを検討する必要があります。クラウドを採用することによるメリットが実感されると、組織は通常、クラウドフットプリントを積極的に拡大および拡大します。一元化されたSecOpsチームにとって、これは拡大を望む幅広いビジネスと、環境内の問題を完全に理解して対応する能力を必要とするSOCとの間で困難な戦いを招く可能性があります。たとえば、ほとんどの組織は、新しいアーキテクチャとその利点を紹介するために小規模な概念実証 (POC) をまとめています。これらのPOCは、より広い組織が利用できるブループリントとして利用できるようになるかもしれません。新しいブループリントが導入されたら、一元管理された SecOps チームが自動化機能を実装して信頼し、アラート、監視、運用プロセスが適切であることを確認する必要があります。 分散化 : すべてのオーナーシップがアプリケーションチームにある状態 ワークロードをクラウドに移行または設計することで、スピードとアジリティの向上、組み込みのネイティブセキュリティ、数分でグローバルにリリースできることなど、多くのメリットが組織にもたらされます。分散型モデルを見ると、ビジネスユニットはクラウドのセキュリティ機能を活用するために、開発パイプラインにプラクティスを組み込む必要があります。これはシフトレフトやDevSecOpsアプローチと呼ばれることもあります。本質的には、セキュリティのベストプラクティスを開発プロセスのあらゆる部分に、できるだけ早い段階で組み込むことです。 SecOps機能のオーナーシップをビジネスユニットとアプリケーションオーナーに置くことには、いくつかのメリットがあります。直接的なメリットの 1 つは、アプリケーションやアーキテクチャを作成するチームが、自社製品に関する直接的な知識とコンテキストを認識できることです。ワークロードの予想される動作と情報フローを理解することは、問題の迅速な修正と解決に役立つため、セキュリティイベントが発生したときにはこの知識が不可欠です。チームがそれぞれの運用プロセスに最も適した方法でセキュリティインシデントに取り組むようにすれば、修正のスピードも上がります。 分散化 : 組織上の考慮事項 分散型アプローチを検討する際、知っておくべき組織上の考慮事項がいくつかあります。 中央の SecOps 部門に所属する専任のセキュリティアナリストは、セキュリティインシデントに日々対処しています。彼らは業界を研究し、今後の脅威に鋭敏に目を光らせており、プレッシャーのかかる状況にも精通しています。分散化すると、セキュリティインシデント発生時に提供される、一貫性のある冷静なエクスペリエンスが失われる可能性があります。業界経験のあるセキュリティ担当者を各ビジネスユニットに組み込むことで、開発ライフサイクル全体を通してセキュリティが考慮され、インシデントが可能な限り迅速に解決されるようになります。 過去のインシデントからのコンテキスト情報と根本原因分析は重要なデータポイントです。SecOpsチームを一元化することで、組織全体に影響を及ぼすセキュリティ問題の全体像をはるかに簡単に把握できるようになります。これにより、ある事業部門からシグナルを受け取り、それを組織の他の部署に適用して、それらにも脆弱性があるかどうかを理解し、将来の組織保護に役立てる能力が向上します。 SecOpsの責任を完全に分散させると、これらのメリットが失われる可能性があります。前述のように、学んだ教訓がビジネスユニット間で共有されていることを確認するには、効果的なコミュニケーションとデータ共有環境が不可欠です。このような効果的な知識共有を実現する 1 つの方法は、クラウドセンターオブエクセレンス (CCoE) を立ち上げることです。CCoEは幅広い情報共有に役立ちますが、一元化されたSecOps機能によってチームの引き継ぎが最小限に抑えられることは、一貫性を促進する強力な組織的メカニズムです。 従来、一元化されたモデルでは、SOC はアプリケーションと重要なビジネス機能を 24 時間 365 日対応していたため、大規模なセキュリティスタッフが必要になることもありました。分散型モデルでも 24 時間 365 日の運用が必要であり、各アプリケーションチームやビジネスユニットにその機能を提供しなければならないと、コストが増加する一方で、情報の共有が困難になることがあります。分散型モデルでは、組織プロセス全体の自動化レベルを高めれば、24 時間 365 日の対応に必要な人員を減らすことができます。 モデルの融合 : ハイブリッドアプローチ ほとんどの組織は、最終的に何らかの形でハイブリッド運用モデルを使用することになります。このモデルは、集中型モデルと分散型モデルの利点を組み合わせたもので、事業部門と中央のSecOps部門間の責任と所有権の分担が明確になっています。 この双方の長所を活かしたシナリオは、「グローバルでモニタリングし、ローカルで対応する」という表現に要約できます。つまり、SecOpsチームと幅広いサイバーセキュリティ部門が、セキュリティに関するベストプラクティスとガードレールで組織全体を導きながら、報告、コンプライアンス、組織全体のセキュリティ体制の把握に関する可視性を維持しているということです。一方、各地域のビジネスユニットには、自社アプリケーションのセキュリティイベントの修復を自信を持って行うためのツール、知識、専門知識があります。 このハイブリッドモデルでは、所有権の委任を 2 つの部分に分けます。1 つ目は、セキュリティ運用機能が一元管理されていることです。この集中管理能力は、CCoE を通じたアプリケーションチームとセキュリティ組織間のパートナーシップに基づいています。これにより、一貫性、ツールの専門知識、過去のセキュリティインシデントから学んだ教訓といったメリットが得られます。2 つ目は、日常的なセキュリティイベントやセキュリティ体制の調査結果の解決がビジネスユニットに委ねられていることです。これにより、ChatOps や自動化、クラウドで利用できるツールなど、ビジネス上の問題に最も近い人々が、チームの働き方に最も適した方法でサービス改善に取り組むことができます。解決のために委任したいイベントの種類の例としては、パッチの適用、構成の問題、ワークロード固有のセキュリティイベントなどがあります。フォレンジックやその他の調査など、専門的なセキュリティ知識が必要な問題については、中央セキュリティ組織への明確なエスカレーションルートをこれらのチームに提供することが重要です。 このハイブリッドモデルで業務を行う場合、RACI は特に重要です。セキュリティインシデントが発生したときの混乱を避けるためには、ビジネスユニットとSecOpsチームの間に明確な責任があることを確認することが重要です。 まとめ クラウドには、組織の新しい機能を活用する機能があります。セキュリティ、スピード、アジリティの向上は、ワークロードをクラウドに移行することで得られるメリットのほんの一部です。従来の一元化された SecOps モデルでは、組織のセキュリティ検出と対応に一貫したアプローチが採用されています。対応を分散化することで、アプリケーションチームは設計上の決定の結果に直接触れることができるため、改善をスピードアップできます。アプリケーションチームが問題解決に責任を負うハイブリッドモデルでは、SecOps が作業を継続できるようにしながら、問題解決までの時間を短縮できます。ハイブリッド運用モデルはクラウドの機能を補完し、アプリケーション所有者とビジネスユニットが組織全体のセキュリティに対する高い基準を維持しながら、それぞれに最適な方法で作業できるようにします。 どの運用モデルや戦略に着手するにしても、目指すべき下記の基本原則を覚えておくことが重要です。 事業全体で効果的なリスク管理を可能にする セキュリティ意識を高め、可能な場合はセキュリティチャンピオンを組み込む 規模を拡大しても、セキュリティイベントに関する組織全体の可視性を維持する アプリケーションオーナーとビジネスユニットがそれぞれにとって最適な方法で業務を行えるよう支援する アプリケーションオーナーやビジネスユニットと協力して、サイバーランドスケープを理解する クラウドは組織に多くのメリットをもたらし、セキュリティ組織はチームが安全に展開および運用できるよう支援します。これは、生産性の向上と継続的なイノベーションにつながり、社内チームにとっても顧客にとっても良いことです。 この投稿についてフィードバックがある場合は、下のコメントセクションにコメントをお送りください。この投稿について質問がある場合は、 AWS サポート にお問い合わせください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 スチュアート グレッグ スチュアートは、ソートリーダーシップを発揮し、お客様に信頼されるアドバイザーになることを楽しんでいます。余暇には、スチュアートがおやつを食べたり、マラソンを走ったり、変わったアイアンマンに手を出す姿が見られます。 本ブログの翻訳はソリューション アーキテクトの大井が担当しました。

このブログは “ Evolving cyber threats demand new security approaches – The benefits of a unified and global IT/OT SOC ” を翻訳したものです このブログ記事では、統一されたグローバルな情報技術および運用技術（IT/OT）セキュリティオペレーションセンター（SOC）を検討する際に組織が検討すべき利点と考慮事項のいくつかについて説明します。この記事では SOC 内の IT/OT コンバージェンスに焦点を当てていますが、ハイブリッドクラウドやマルチクラウド、Industrial IoT (IIoT) など、他の環境について考えるときには、ここで説明した概念やアイデアを参考にしてください。 組織がリモートワークに移行するにつれて、またInternet of Things（IoT）やサイバーフィジカルシステムなどの世界中からオンライン化されるエッジデバイスを介した相互接続性の増加により、資産の範囲は大幅に拡大しました。多くの組織にとって、IT SOC と OT SOC は別々でしたが、コンバージェンスを支持する強い論拠があります。コンバージェンスは、予期しない活動に対応できるというビジネス上の成果をより良く表すものです。 インダストリアル IoT ソリューションの 10 のセキュリティゴールデンルール の中で、AWS は OT と IIoT 環境全体にセキュリティ監査と監視のメカニズムを導入し、セキュリティログを収集し、SOC 内のセキュリティ情報およびイベント管理 (SIEM) ツールを使用して分析することを推奨しています。SOC は監視、検出、対応に使用されます。これは従来、環境ごとに個別に行われていました。このブログ記事では、これらの環境を統合することが SOC にもたらすメリットと潜在的なトレードオフについて探ります。組織はこのブログ記事で取り上げた点を慎重に検討すべきですが、統合型SOCの利点は潜在的なトレードオフを上回ります。日常業務がITとOTの間でより密接につながっているため、ある環境から別の環境に伝播する脅威チェーン全体を可視化することは、組織にとって非常に重要です。 従来の IT SOC 従来、SOC は、オンプレミスかハイブリッドアーキテクチャかを問わず、組織内の IT 環境全体のセキュリティ監視、分析、インシデント管理を担当していました。この従来のアプローチは長年にわたって有効であり、SOC が可視化して進化する脅威から IT 環境を効果的に保護できるようになっています。 注:組織は、 このブログ記事 で説明されているクラウドでのセキュリティ運用に関する考慮事項に注意する必要があります。 従来の OT SOC 従来、OT、IT、クラウドの各チームは、 Purdue モデル で説明されているように、エアギャップの別々の側面で作業してきました。その結果、OT、IIoT、クラウドセキュリティ監視ソリューションがサイロ化され、カバレッジにギャップが生じたり、コンテキストが失われたりする可能性があり、そうでなければ対応能力を向上させることができたはずです。IT/OT コンバージェンスのメリットを最大限に引き出すには、IIoT、IT、OT が効果的に連携して、幅広い視点と最も効果的な防御策を提供する必要があります。コンバージェンスの傾向は、新たに接続されたデバイスや、セキュリティと運用の連携方法にも当てはまります。 企業は、 製造業におけるデジタルトランスフォーメーション がどのように競争上の優位性をもたらすかを模索する中で、 IoT 、クラウドコンピューティング、人工知能と機械学習 (AI/ML)、その他のデジタル技術を利用しています。これにより、組織が保護しなければならない潜在的な脅威領域が増大し、統一されたグローバルSOCを通じて提供される、広範で統合された自動化された多層防御セキュリティアプローチが必要になります。 OT ネットワークに出入りするトラフィックを完全に可視化して制御できなければ、運用部門は予期しないイベントの特定に使用できるコンテキストや情報を完全に把握できない可能性があります。制御システムや、プログラマブル・ロジック・コントローラ (PLC)、オペレータ・ワークステーション、安全システムなどの接続された資産が危険にさらされた場合、脅威アクターは重要なインフラストラクチャやサービスに損害を与えたり、ITシステム内のデータを侵害したりする可能性があります。OT システムに直接的な影響がない場合でも、OT ネットワークの運用と監視に関する安全上の懸念から、二次的な影響によって OT ネットワークが停止する可能性があります。 SOC は、主要なセキュリティ担当者とイベントデータを 1 か所にまとめることで、セキュリティとコンプライアンスの向上に役立ちます。SOC を構築するには、人材、プロセス、テクノロジーへの多額の先行投資と継続的な投資が必要となるため、重要です。ただし、セキュリティ体制の改善の価値は、コストと比較して非常に重要です。 多くの OT 組織では、オペレーターやエンジニアリングチームはセキュリティに重点を置くことに慣れていない可能性があります。場合によっては、組織が IT SOC から独立した OT SOC を設定することもあります。エンタープライズおよび IT SOC 向けに開発された機能、戦略、テクノロジーの多くは、セキュリティオペレーション (SecOps) や標準運用手順 (SOP) などの OT 領域にも転用されます。OT 固有の考慮事項があることは明らかですが、SOC モデルは IT/OT の統合型サイバーセキュリティアプローチの出発点として適しています。さらに、SIEM などのテクノロジーは、OT 組織がより少ない労力と時間で環境を監視し、投資収益率を最大化するのに役立ちます。たとえば、IT と OT のセキュリティデータを SIEM に取り込むことで、IT と OT の利害関係者は、セキュリティ作業を完了するために必要な情報へのアクセスを共有できます。 統合 SOC のメリット 統合 SOC は組織に多くのメリットをもたらします。IT 環境と OT 環境全体を幅広く可視化できるため、協調的な脅威検出、迅速なインシデント対応、環境間での侵害指標 (IOC) の即時共有が可能になります。これにより、脅威の経路と発生源をよりよく理解できます。 IT 環境と OT 環境のデータを統一された SOC に統合することで、データの取り込みと保存を割引してスケールメリットを享受できます。さらに、統一された SOC を管理することで、データ保持要件、アクセスモデル、自動化や機械学習などの技術機能を一元化し、オーバーヘッドを削減できます。 ある環境内で開発された運用上の重要業績評価指標 (KPI) を別の環境を強化し、セキュリティイベントの平均検出時間 (MTTD) の短縮などの運用効率を高めることができます。統一された SOC は、セキュリティ、運用、パフォーマンスの統合を可能にし、テクノロジー、場所、導入環境における包括的な保護と可視化をサポートします。IT 環境と OT 環境の間で学んだ教訓を共有することで、全体的な運用効率とセキュリティ体制が向上します。また、統一された SOC により、組織は規制要件を 1 か所で順守できるようになり、コンプライアンスへの取り組みと運用監視が効率化されます。 セキュリティデータレイクと AI/ML などの高度なテクノロジーを使用することで、組織は回復力のある事業運営を構築し、セキュリティ脅威の検出と対応を強化できます。 IT と OT の対象分野の専門家 (SME) から成る部門横断的なチームを結成することで、文化的な隔たりを埋め、コラボレーションを促進し、統一されたセキュリティ戦略の策定が可能になります。統合され統一された SOC を導入することで、IT および OT のサイバーセキュリティプログラムにおいて産業用制御システム (ICS) の成熟度を高め、ドメイン間のギャップを埋め、全体的なセキュリティ機能を強化できます。 統合 SOC に関する考慮事項 統一 SOC には、組織が考慮すべき重要な側面がいくつかあります。 まず、統一された SOC 環境では職務分掌がきわめて重要です。最も適切な専門家がそれぞれの環境のセキュリティイベントに取り組むことができるように、専門知識と職務に基づいて特定の職務が各個人に割り当てられていることを確認することが不可欠です。さらに、データの機密性を慎重に管理する必要があります。特定の種類のデータへのアクセスを制限するには、権限のあるアナリストだけが機密情報にアクセスして扱うことができるようにしながら、強固なアクセスと権限の管理が必要です。組織全体の セキュリティのベストプラクティスに従って 明確な AWS Identity and Access Management (IAM) 戦略を実施し、職務分掌が実施されていることを確認する必要があります。 もう 1 つの重要な考慮事項は、IT 環境と OT 環境の統合中に運用が中断される可能性があることです。移行を円滑に進めるためには、データの損失、可視性の損失、標準運用の中断を最小限に抑えるための慎重な計画が必要です。IT セキュリティと OT セキュリティの違いを認識することが重要です。OT 環境は独特な性質を持ち、物理インフラストラクチャと密接に結びついているため、産業組織が直面するさまざまな使命、課題、脅威に対応する、カスタマイズされたサイバーセキュリティ戦略とツールが必要です。IT サイバーセキュリティプログラムのコピー&ペーストによるアプローチでは十分ではありません。 さらに、サイバーセキュリティの成熟度は IT ドメインと OT ドメインによって異なることがよくあります。サイバーセキュリティ対策への投資は異なる場合があり、その結果、OT サイバーセキュリティは IT サイバーセキュリティと比較して比較的成熟度が低くなります。統一された SOC を設計および実装する際には、この相違点を考慮する必要があります。各環境のテクノロジースタックのベースラインを作成し、明確な目標を定義し、ソリューションを慎重に設計することで、この不一致を確実に考慮に入れることができます。ソリューションが概念実証 (PoC) 段階に移行したら、コンバージェンスを本番環境に移行する準備が整っているかどうかのテストを開始できます。 また、IT チームと OT チームの文化的な格差にも対処する必要があります。組織のサイバーセキュリティポリシーと手順が ICS や OT のセキュリティ目標と一致していないと、両方の環境を効果的に保護できなくなる可能性があります。コラボレーションと明確なコミュニケーションを通じてこの格差を埋めることが不可欠です。これについては、 “OT/IT コンバージェンスを成功させるための組織変革の管理“ に関する記事 で詳しく説明されています。 統合IT/OT SOCの導入: 図 1 は、統合 IT/OT SOC で想定される導入を示しています。これはユニファイド SOC の概略図です。この記事の第 2 部では、AWS のサービスと AWS パートナーネットワーク (APN) ソリューション を使用して、AWS 上で統一されたグローバル SOC を設計および構築する方法について、規範的なガイダンスを提供します。 図 1: 統合された IT/OT SOC アーキテクチャ IT/OT ユニファイド SOC の構成要素は次のとおりです。 環境 :従来の IT オンプレミス組織、OT 環境、クラウド環境など、複数の環境があります。各環境は、資産からのセキュリティイベントとログソースの集まりです。 データレイク :さまざまな環境からの未加工データが共通のスキームに標準化されていることを確認するために、データの収集、正規化、強化を一元的に行える場所です。データレイクは、長期保存のためのデータ保持とアーカイブをサポートする必要があります。 視覚化 :SOC には、組織上および運用上のニーズに基づいた複数のダッシュボードが含まれています。ダッシュボードには、IT 環境と OT 環境間のデータフローなど、複数の環境のシナリオを網羅できます。また、各利害関係者のニーズに対応するために、個々の環境専用のダッシュボードもあります。人間と機械がデータを照会してセキュリティやパフォーマンスの問題を監視できるような方法でデータを索引付けする必要があります。 セキュリティ分析 :セキュリティ分析は、セキュリティシグナルを集約して分析し、より精度の高いアラートを生成し、同時に発生する IT シグナルや信頼できるソースからの脅威インテリジェンスに対して OT シグナルをコンテキスト化するために使用されます。 検出、警告、対応 :個々の環境と複数の環境の両方のデータに基づいて、関心のあるイベントに対してアラートを設定できます。データ全体にわたって脅威の経路や関心のあるイベントを特定するには、機械学習を活用する必要があります。 まとめ このブログ記事全体を通して、セキュリティ運用を最適化するという観点から、IT 環境と OT 環境の統合について説明してきました。統一された SOC を設計して実装することの利点と考慮事項について見てきました。 日常業務が IT と OT のつながりを強める中、ある環境から別の環境に広がる脅威の連鎖全体を可視化することは、組織にとって極めて重要です。統一された SOC はインシデントの検出と対応の中枢であり、組織のセキュリティ体制とサイバーレジリエンスを向上させる上で最も重要な要素の 1 つになり得ます。 統合が組織の目標であれば、それが何を意味するのかを十分に検討し、統合型SOCが実際にどのようなものになるかを計画する必要があります。多くの場合、小規模な概念実証を行い、段階的に移行することがこのプロセスに役立ちます。 次回のブログ記事では、AWS のサービスと AWS パートナーネットワーク (APN) ソリューションを使用して、統一されたグローバルな SOC を設計および構築する方法について、規範的なガイダンスを提供します。 関連資料 : AWS Security Hubで OT、産業用 IoT、クラウドにまたがるセキュリティ監視を実現する Improve Your Security Posture with Claroty xDome Integration with AWS Security Hub AWS IoT Device Defender と AWS Security Hub を直接統合し、セキュリティ体制を強化する A cloud-based security operations center (SOC) helps improve your security detection and response AWS セキュリティブログ：セキュリティモニタリングに関するタグのブログ この記事に関するフィードバックがある場合は、下のコメントセクションにコメントを送信してください。この記事に関するお問い合わせは、 AWS サポート にご連絡ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 スチュアート グレッグ スチュアートは、ソートリーダーシップを発揮し、お客様に信頼されるアドバイザーになることを楽しんでいます。余暇には、スチュアートがアイアンマンのトレーニングをしたり、おやつを食べたりしています。 ライアン ドソウザ ライアン は AWS のプリンシパル IIoT セキュリティソリューションアーキテクトです。ニューヨーク市に拠点を置く Ryan は、AWS の機能を活用して、測定可能なビジネス成果を実現する、より安全でスケーラブルで革新的な IIoT ソリューションをお客様が設計、開発、運用できるよう支援しています。Ryan は、複数の技術分野や業界で 25 年以上の経験があり、接続されたデバイスにセキュリティをもたらすことに情熱を注いでいます 本ブログの翻訳はソリューション アーキテクトの大井が担当しました。

COVID-19 パンデミックは、ビジネスと世界市場にかつてない混乱をもたらしました。現在、世界の大半はパンデミックによる不安と混乱は脱したように見えます。しかし、特に消費財企業は、サプライチェーンの混乱や労働力不足といった大きな課題に対処し続けています。同時に、パンデミック中に変化した消費者の購買パターンや期待も、今や当たり前のものとなっています。消費財業界のリーダーは、市場の変動や消費者の嗜好の変化に対応するため、イノベーションと俊敏性を念頭に置きながら、戦略的に物事を考えなければなりません。そこで、洞察と着想を得るために、Amazon Web Services, Inc.（ AWS ）パートナーのエグゼクティブと対談し、困難な時代における彼らのリーダーシップと専門知識をご紹介します。 消費財パートナー対談ブログシリーズの最新回では、AWS パートナーであり、特定業界の企業向けビジネスクラウドソフトウェア製品のグローバルリーダーである Infor の、食品・飲料業界担当 シニア インダストリー＆ソリューション ストラテジー ディレクターの Marcel Koks 氏と、食品・飲料業界担当 インダストリー＆ソリューション ストラテジー ディレクターの Mikael Bengtsson 氏にお話を伺いました。このブログでは、クラウドプラットフォームと AI/ML （人工知能/機械学習）テクノロジーが、食品・飲料企業のオペレーションの創造的な最適化、無駄の削減、生産性の向上にどのように役立つのかについて、お二人の見解をご紹介します。 AWS: 読者に、 Infor の視点を理解してもらうためにお聞かせください。Infor はどのような分野で活躍されていますか？また、どのような消費財企業のエグゼクティブと交流があるのでしょうか？ Marcel Koks:  Infor は、消費財分野のサプライチェーン全体、製品の製造・流通を含む食品・飲料業界を専門としています。食品・飲料業界には、乳製品、食品材料、タンパク質など、多くのミクロ分野があることに注意することが重要です。ミクロ分野によって、課題やニーズは大きく異なります。 Infor は、最高経営責任者（ CEO ）、最高情報責任者（ CIO ）、サプライチェーンリーダーなど、C-Suite や VP 層のエグゼクティブと連携し、最終損益に影響を与え、事業運営を改善する IT の意思決定を支援します。 AWS: 消費財企業は前例のない混乱を乗り越えてきました。お客様にとって最大の課題は何でしたか？ Mikael Bengtsson: 最近まで、食品・飲料業界のお客様が経験してきた最大の課題は、サプライチェーンの混乱に集中していました。しかし、ここ数カ月、サプライチェーンはそれほど不安定ではなく、現時点ではそれほど切迫した問題ではありません。現在の最大の課題は、全面的な物価の上昇です。ウクライナ戦争、インフレ、さらなる持続可能性対策など、多くの要因がコスト上昇の原因となっています。もうひとつの継続的な課題は労働力不足であり、企業は、より少ない従業員で、より高まる消費者の需要に対応する必要があります。 AWS： 市場ダイナミクスや消費者の期待の変化に対して、消費財企業は現在の事業運営環境をどのように調整しているとお考えですか？ Marcel Koks: 業界が経験したさまざまな混乱は、需要と供給の変化に対応する俊敏性のニーズを浮き彫りにしましたが、需要と供給への対応以上に、新たな販売チャネルや、事業買収、国際的な事業展開など、新たなビジネス戦略を迅速に実行し、収益性の高い成長を維持するための俊敏性が求められています。Infor の食品・飲料業界特化型のクラウド統合基幹業務 ( ERP ) プラットフォームはまさしくその俊敏性を提供しています。サプライチェーンの面では、 需要、供給、生産計画、そして生産スケジュール管理を行う Infor の製品が、需要、供給、生産能力のバランスをとりながら最も収益性の高い方法で、ビジネス変化への迅速な対応を支援します。物価の上昇に伴い、食品・飲料企業は製品ポートフォリオを分析し、どの製品がビジネスや市場にとって最も有効かを判断する必要があります。この場合も、 Infor の製品ライフサイクル管理ソリューションにより、食品・飲料企業は、適切な新製品のアイデアに優先順位をつけることで、より迅速に、より成功率を高めて新製品を市場へ投入することができます。 AWS： 消費財業界は驚くほどの回復力があります。新しい生活様式に目を向けた時、テクノロジーとクラウドは消費財業界にとってどのような役割を果たすとお考えですか？ また、テクノロジーは消費財業界における製品の生産プロセス、サプライチェーン、そして消費者接点をどのように強化するとお考えですか？ Mikael Bengtsson: Infor のクラウドプラットフォームは、消費財業界のビジネスに可視性を提供するだけでなく、ハイパーオートメーションによる効率性を提供し、AI や ML を活用することによる、さらなる効率性と俊敏性も実現します。この最新テクノロジーを活用することで、大量のデータを消費・分析し、製造現場から ERP プラットフォームに至るまで、より良い意思決定を支援することができます。これにより、全体的な効率の向上、コスト削減、時間の節約、最終的には無駄の削減につながります。 AWS: 現在の消費財業界の混乱に伴い、貴社は変化に対応するためにどのような改革を進めていますか？ Marcel Koks: 一般的な業界では AI や ML の導入が遅れている企業が多い中、 AI や ML の機能を活用する Infor のお客様が増えてきています。これらの機能はすべてのテナントで利用可能であり、これがパブリッククラウドサービスの真の利点です。例えば、チーズのグローバルプロバイダである Amalthea 社は、 Infor の AI ソリューションを 90 日足らずで導入 し、生産改善や無駄の削減のための洞察を毎日得られるようにすることで、歩留まりの見込みを最大化しました。 Infor は、データを収集・分析するためのプラットフォームを提供し、製造、サプライチェーン、さらには製品開発そのものに至るまで、自動化と効率化を実現します。 Infor のソリューションは、未曾有の世界経済情勢の中で、より少ないコストでより多くの成果を上げ、真の柔軟性と俊敏性を実現する手段を提供します。 AWS: これからの「新しい生活様式」についての話題が多くなっています。貴社にとって、この「新しい生活様式」とはどのようなものですか？また、 3 年後の消費財業界はどうなっていると思いますか？ Mikael Bengtsson: ほとんどの企業がクラウドへのデジタルトランスフォーメーションを行い、その結果、より良いビジネス上の意思決定とイノベーションを推進するために、統合された AI と ML を使用するようになるでしょう。この移行により、サプライチェーンはより効率的になり、無駄が減ることになります。その他の大きなトレンドとしては、持続可能性への注目が高まりや、消費者の需要が高まる中で、消費者への影響を最小限に抑える方法を決定することが挙げられます。食品・飲料業界では、今後 3 年間で、代替タンパク質と新しい農業手法が目立つようになるでしょう。そして、今後さらに多くの混乱が予想されます。変化のスピードはますます速くなり、パンデミックやウクライナ戦争のような世界規模の出来事の中で、企業は俊敏になり、利益を維持するために適応する必要があります。 AWS: 消費財業界の未来で楽しみなことは何ですか？ Marcel Koks: 食品・飲料企業がクラウドを活かし、AI や ML を駆使することで、オペレーションを創造的に最適化し、無駄を省き、生産量を増加させることを楽しみにしています。まだ活用の初期段階とはいえ、食品・飲料業界の製造領域が次の段階を迎えるために、 AI と ML を活かせる場所はたくさんあります。例えば、 Infor はベーカリー材料ビジネスをグローバルに展開する Zeelandia と連携し、 AI ソリューションを導入することで、顧客ごとの製品レコメンドにかかる準備が 83% 高速化 されて、全体的な顧客体験の向上を実現しています。さらに、多くの企業が先進的な工場や自動化に投資する中、 Infor はインダストリー 4.0 を支える技術の開発に取り組んでいます。 Infor は The Smart Factory @ Wichita のスポンサーを務めており、 The Smart Factory @ Wichita では、製造業の皆様が自身のビジネスをデジタルトランスフォームする方法を調査することや、最新技術を体験することができます。 AWS: Marcel 氏 と Mikael 氏、私たちと対談していただきありがとうございます。あなた方の洞察と専門知識に感謝します。 このブログシリーズをお楽しみいただければ幸いです。 Infor の Marcel 氏 と Mikael 氏、またはAWSに質問がある場合は、このブログにコメントを残してください。 Infor の詳細については、Infor の コンタクトページ からお問い合わせください。 AWSパートナースポットライト Infor は、業種別に特化したビジネスクラウドソフトウェアのグローバルリーダーであり、世界中の 67,000 社のお客様にミッションクリティカルなエンタープライズアプリケーションを提供しています。 Infor は、AWS を活用して最新のツールを構築・導入し、お客様のビジネスの変革とイノベーションの加速を支援しています。 AWS における Infor については こちら から詳細をご覧ください。 著者について Marcel Koks Marcel Koks は、 Infor の食品・飲料市場における戦略を策定しています。そのためには、業界のトレンドを分析し、 Infor のエンタープライズアプリケーションプラットフォームにどの業界向けの機能が必要かを判断します。そして、食品・飲料企業と緊密に連携し、ニーズを把握します。食品・飲料企業のニーズと機械学習、ブロックチェーン、IoT などの実用的なユースケースと結びつけることで、顧客を支援し、周囲に刺激を与えています。 Kevin McCurdy Kevin E. McCurdy は、AWS のグローバル 消費財 セグメントリード（ APN ）であり、戦略的な ISV および SI パートナーの発掘と関係構築を担当です。それ以前は、E2open のデマンドシグナルマネジメント担当 VP 、後に E2open に買収された Orchestro の共同創業者兼戦略アカウント担当 VP 、Mercari Technologies の共同創業者兼事業開発・サービス担当 VP でした。Coca-Cola 、 General Mills 、Kellogg’s 、PepsiCo 、Unilever 、Kraft-Heinz など、世界的な消費財企業や小売企業において、サプライチェーンマネジメント、カテゴリーマネジメント、デマンドシグナルマネジメントの分野で 25 年以上の経験があります。Pennsylvania State University でビジネスロジスティクスと国際ビジネスの理学士号を取得しました。 Mikael Bengtsson Mikael Bengtsson は、ビジネスおよびテクノロジーのコンサルティングにおいて 20 年以上の経験があり、食品・飲料業界に特に重点を置き、社内業務およびサプライチェーン（戦略的調達、調達、企業間電子商取引ネットワークなど）の上流から下流まで、世界有数のメーカーをサポートしています。Mikael は、ビジネス価値をもたらす、より良いプロセスと効率性を実現するために、テクノロジーを活用したグローバルな変革プロジェクトを統括してきました。また、測定可能なビジネス価値を提供することを主な目的として、テクノロジー導入手法の開発を主導してきました。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。

編集者注：このブログは、ビルダーが独自のソリューションを作成するためのデモンストレーションと基礎を提供するために設計されたスターター・プロジェクトの例です。本番環境で使用できるものではありません。本番環境にデプロイして使用することを計画している場合は、 本番環境での使用 を参照してください。このソリューションをさらに進めるために追加のサポートが必要な場合は、 AWS プロフェッショナルサービス または Amazon Connect パートナー にお問い合わせください。 AWS Contact Center Day にご参加ください。この無料のバーチャルイベントでは、カスタマーサービスの未来や、機械学習による顧客とエージェントの体験の最適化などについて学ぶことができます。 今すぐ登録 >> ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 企業は顧客の期待に応えるため、よりパーソナライズされた体験を提供しようと努力しています。今日、消費者は友人や家族とのコミュニケーションにさまざまなリッチなデジタルメッセージングアプリケーションから選ぶことができ、WhatsApp は世界的に最もよく利用されているアプリケーションの一つです。消費者は、利便性と柔軟性を求めて、自分の好きなデジタルチャネルでコミュニケーションできる選択肢をますます求めています。どのような規模の組織であっても、変化し続ける顧客のコミュニケーションの好みに応えるためには、デジタルコミュニケーション戦略においてこの点を考慮することが重要です。 Amazon Connect のメッセージストリーミング API を使用すると、デジタルチャネルを Amazon Connect コンタクトセンターに簡単に統合できます。追加のチャネルを統合することで、顧客が好むデジタルチャネルで、パーソナライズされたリアルタイムのサポートを提供することができます。 このブログでは WhatsApp を Amazon Connect コンタクトセンターに統合する方法をご紹介します。ここで説明する手順とアーキテクチャは他のデジタルチャネルとの統合にも応用できます。本記事の手順に従って WhatsApp をセットアップすると、エージェントはすでに Amazon Connect の音声、チャット、タスクで使用しているエージェントデスクトップから、WhatsApp チャネルの顧客メッセージを受信し、返信することができます。 ソリューション概要とアーキテクチャ このブログ記事では、 GitHub リポジトリ からサンプルプロジェクトをデプロイします。このプロジェクトには WhatsApp メッセンジャーチャネルをサポートするエンドツーエンドのインフラストラクチャが含まれています。 これらの API を使用して Amazon Connect Chat と SMS を統合する方法については、 Amazon Connect を使用した SMS 上でのパーソナライズされた顧客体験の構築 のブログをご覧ください。 図1 : ソリューション・アーキテクチャ 顧客はデジタルメッセージングチャネルから Amazon API Gateway にホストされている Webhook にメッセージを送信します。 API Gateway は AWS Lambda にメッセージを送信します。 AWS Lambda はチャットのコンタクトコンテキストを Amazon DynamoDB に書き込みます。 これがコンタクトの最初のメッセージである場合、AWS Lambda は、StartChatContact、StartContactStreaming、CreateParticipantConnection の順序で API を呼び出します。チャットがすでに存在している場合、AWS Lambda はAmazon Connect にメッセージを送信します。 Amazon Connect はエージェントまたはシステムのメッセージを Amazon SNS にストリーミングします。 Amazon SNS が AWS Lambda を呼び出します。 AWS Lambda が Amazon DynamoDB にチャットのコンタクトコンテキストを問い合わせます。 AWS Lambda は返信メッセージを送信元チャネルから API を通じて顧客に配信します。 前提条件 このチュートリアルでは、以下のリソースを理解し、アクセスできることを前提としています： 次のサービスに対して管理者権限を持つ AWS アカウント – Amazon Connect、Amazon API Gateway、AWS Lambda、Amazon DynamoDB、Amazon Simple Notification Service、AWS Secrets Manager、AWS CloudFormation Amazon Connect インスタンス Amazon Connect のコンタクトフローのセットアップ（切断フローを含む） ローカル環境での AWS CLI のセットアップ Meta (Facebook) の開発者アカウント。詳細は Meta for Developers コンソール をご覧ください。 NPM を使って開発者マシンへの Node.js のインストール。詳細は nodejs downloads をご覧ください。 デプロイのチュートリアル Meta for Developers コンソール Meta for Developers コンソール に移動します。 マイアプリ をクリックします。 アプリを作成 をクリックします（または既存アプリを選択します）。アプリに必要な機能については、 その他 を選択し、 次へ をクリックします。 アプリタイプを選択します。ここでは WhatsApp をサポートする ビジネス を選択します。 次へ をクリックします。 アプリの表示名 、 連絡先メールアドレス 、 ビジネスアカウント を紐づけるかどうかを選択し、 アプリを作成 をクリックします。 ダッシュボード に移動し、 アプリに製品を追加 セクションで WhatsApp サービスの 設定 を選択します。 Meta ビジネスアカウントを 作成 または選択し、 次へ を選択します。 アプリの設定 > ベーシック に移動し、 app secret の 表示 をクリックします。表示された値は Amazon Secrets Manager で WA_APP_SECRET というキーにシークレットを作成する際に必要となるため、保存して下さい。 WhatsApp > API設定 に移動し、 電話番号ID をメモします。このIDは後ほど AWS Secrets Manager でシークレット ( WA_PHONE_NUMBER_ID ) として必要になります。 また、 テスト番号 もメモします。ソリューションがデプロイされたら、この番号に、テスト用の電話からメッセージを送信する必要があります。これは Amazon Connect デプロイメント用のビジネス電話番号です。 また、 受信者の電話番号を選択 のドロップダウンに、テストに使用するお客様の電話番号を追加して下さい。指示に従って電話番号の追加と認証を行って下さい。注意： この電話番号で WhatsApp を登録し、クライアント端末に WhatsApp クライアントがインストールされている必要があります。検証メッセージは WhatsApp クライアントのアーカイブリストに表示され、メインのメッセージリストには表示されません。 API 経由で WhatsApp にアクセスする新規ユーザーを作成 Meta の ビジネスマネージャ を開き、あなたが作成した、またはアプリを関連づけたビジネスアカウントを選択し、ビジネス設定(歯車アイコン)をクリックします。 ユーザー の下にある システムユーザー をクリックします。 追加 をクリックし、新規システムユーザーを作成します。 システムユーザーに名前を付け、役割を 管理者 に設定し、 システムユーザーを作成 をクリックします。 アセットを割り当てる ボタンで新規ユーザーを WhatsApp アプリに関連付けます。 アセットタイプの選択 リストから アプリ を選択し、 アセットの選択 であなたが作成した WhatsApp アプリ名を選択します。部分的なアクセス許可にて アプリをテスト を有効にし、 変更を保存 をクリックして 完了 をクリックします。 新しいトークンを生成ボタン をクリックし、作成した WhatsApp アプリを選択します。 利用可能なアクセス許可 リストから whatsapp_business_messaging と whatsapp_business_management を選択し、一番下の トークンを生成 をクリックします。 アクセストークンをコピーして保存します。このアクセストークンは、次のセクションでシークレット WA_ACCESS_TOKEN として使用します。 OK をクリックする前に、トークンをコピーしたことを確認してください。 アクセストークン作成の詳細については、Meta for Developers コンソールの WhatsApp > 設定 や 固定トークンの作成方法 をご覧ください。 AWS Secrets Manager のセットアップ AWS Secret Manager のコンソール に移動し、 新しいシークレットを保存する をクリックし、 その他のシークレットのタイプ を選択します。Facebook Messengerとの統合を使用している場合、シークレットは両方のソリューションで共有できますが、シークレット内のキーは各ソリューションで個別に作成する必要があります。 下記の キー/値のペア のところに、 WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET 、 WA_VERIFY_TOKEN を追加します。 WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET には、前のステップで取得した値を指定します。WA_VERIFY_TOKEN には任意のランダム文字列 (自身で作成したもの) を指定できます。これは後のステップで、WhatsApp webhook に追加されます。 デフォルトの暗号化キー( aws/secretsmanager )を選択します。次 をクリックします。 注: 新しいキーを追加することも可能ですが、その際はCDKプロジェクトを変更し、暗号化キーへのアクセス許可を与えてください。 シークレットの名前 と 説明 を入力し、 次 をクリックします。 注: リソース権限やその他の設定を追加する場合は、CDKスタックリソースにこのシークレットへの権限が与えられていることを確認してください。 次 をクリックし、シークレットを 保存 します。 注: 必要に応じて自動ローテーションの設定を行うことができますが、このチュートリアルではデフォルト値のままとします。 AWS Secret Manager のコンソール で、作成したシークレットを検索し、 シークレット ARN をメモしてください。これは後ほど、CDKでデプロイする際に必要になります。 Amazon Connect インスタンスの詳細を取得 AWS マネジメントコンソールの Amazon Connect に移動します。 Amazon Connect インスタンスを選択し、 インスタンスARN をメモします。 Amazon Connect 管理コンソール にログインし、 コンタクトフロー の画面を開きます。WhatsAppチャネルでチャットを開始させたい コンタクトフロー を選択し、その コンタクトフローID をメモします。 AWS CDK と Bootstrap CDK 環境をインストール（CDK をインストール済みの場合はスキップ） npm -g install typescriptnpm -g install aws-cdk cdk bootstrap aws://ACCOUNT_ID/AWS_REGION プロジェクトのデプロイ 続行する前に、前のステップで以下の変数があることを確認してください。 Amazon Connect インスタンス ARN Amazon Connect コンタクトフロー ID WA_PHONE_NUMBER_ID 、 WA_ACCESS_TOKEN 、 WA_APP_SECRET 、 WA_VERIFY_TOKEN の値を格納する、AWS Secret Manager のシークレット ARN Git を使って、GitHub からリポジトリをクローンします。 git clone git@github.com:amazon-connect/amazon-connect-message-streaming-examples.git ターミナルでディレクトリのルートに移動します。 cd amazon-connect-message-streaming-examples CDK プロジェクトと AWS Lambda 関数の依存関係をインストールします。 npm install cd src/lambda/inboundMessageHandler npm install cd ../../.. cd src/lambda/outboundMessageHandler npm install cd ../../.. cd src/lambda/digitalChannelHealthCheck npm install cd ../../.. AWS CLI プロファイルを使用して CDK プロジェクトをデプロイします。cdk スタックに必要なコンテキスト環境変数として、 amazonConnectArn 、 contactFlowId 、 waSecretArn を指定します。 cdk deploy \ --context waSecretArn=<YOUR SECRET ARN> \ --context amazonConnectArn=<YOUR AMAZON CONNECT INSTANCE ARN> \ --context contactFlowId=<YOUR CONTACT FLOW ID 注: WhatsApp、SMS、Facebook Messenger チャネルは全て同じ CDK プロジェクトの一部です。SMS または Facebook チャネルをデプロイしたい場合には、追加のコンテキストパラメータが必要です。SMS の場合は pinpointAppId と smsNumber (携帯電話番号)、Facebook の場合は fbSecretArn が必要です。詳細は SMS ブログ と Facebook ブログ をご参照ください。 CDK のデプロイが完了したら、CDK の出力から WhatsAppApiGatewayWebhook を確認します。 Meta コンソール ターミナルの CDK 出力にて、API Gateway の呼び出し URL WhatsAppApiGatewayWebhook を確認します。 Meta for Developers コンソール に戻ります。 WhatsApp > 設定  を選択し、Webhook 設定ページにアクセスします。 Webhook の下にある 編集 をクリックします。 コールバック URL には、 API ゲートウェイ呼び出し URL を指定します。 トークンを検証 には、 AWS Secrets Manager のセットアップの手順で作成したランダム文字列を指定します。 確認して保存 をクリックします。 Webhook フィールドセクションの 管理 をクリックします。 messages の行の サブスクリプション登録 をクリックします。 完了をクリックします。 おめでとうございます！Amazon Connect インスタンスにデジタルチャネルとして WhatsApp が追加されました。WhatsApp ビジネス テスト番号 を WhatsApp アカウントの連絡先に追加し、その連絡先にメッセージを送信すると、Amazon Connect インスタンスに接続されます！ クリーンアップ Whatsapp アプリを削除します。 Meta for Developers コンソール に移動し、 マイアプリ を選択し、 アプリの削除 を選択してWhatsapp アプリを削除します。 Meta 開発者アカウントを削除します。 AWS Secret Manager のコンソールに移動し、シークレットを削除します。 CDK スタックを破棄します。 cdk destroy \ --context waSecretArn=<YOUR SECRET ARN> \ --context amazonConnectArn=<YOUR AMAZON CONNECT INSTANCE ARN> \ --context contactFlowId=<YOUR CONTACT FLOW ID> まとめ 本ブログでは、 Amazon Connect Chat メッセージストリーミング API と WhatsApp を例に、Amazon Connect のデジタルチャネルを構築する方法をご紹介しました。本ブログのステップに従って WhatsApp インテグレーションを実装することで、エージェントは Amazon Connect の音声、チャット、タスクに使用しているエージェントデスクトップから、WhatsApp 上の顧客メッセージの受信と返信を開始することができます。 始めるには GitHub リポジトリ にアクセスし、プロジェクトをデプロイしてください！ 注: これは実験用に簡単にデプロイできるように設計されたサンプルプロジェクトです。IAM ポリシーは最小権限を使用していますが、デプロイされた AWS API Gateway はパブリックにアクセスできます。次の公式ドキュメント Amazon API Gatewayでのセキュリティ に従い、 AWS API Gateway のセキュリティ を確保するために適切な処置を行ってください。 著者情報 Abhishek Pandey は Amazon Web Services のシニアソリューションアーキテクトです。16 年以上のエンタープライズ IT の経験を持つ Abhishek は、さまざまな業界のビジネスイノベーションをサポートする創造的なソリューションを設計するために、顧客と深く掘り下げることに情熱を注いでいます。Abhishek は、情熱、熱意、顧客支持、好奇心、創造性の秘密のブレンドを使用して、AWS クラウドの価値を解き放つためにビルダーを鼓舞します。 — Attila は Amazon Web Services Professional Services グループの Amazon Connect コンサルタントです。コンタクトセンターの経験に加え、ソフトウェア開発とエンタープライズネットワーキングの経験があります。Attila は、顧客メリットを提供するために製品機能を強化する革新的な方法を常に模索しています。 — AWS Contact Center Day にご参加ください。この無料のバーチャルイベントでは、カスタマーサービスの未来や、機械学習 による顧客とエージェントの体験の最適化などについて学ぶことができます。 今すぐ登録 >> ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 翻訳はソリューションアーキテクトの濱上が担当しました。原文は こちら です。

はじめに AWS IoT Core は AWS IoT Core フリートプロビジョニング におけるセルフマネージドのクライアント証明書の署名方法の一般提供を開始しました。新しいセルフマネージドの証明書署名機能により、 フリートプロビジョニング 時に、外部の認証局 (CA) 、独自の公開鍵基盤 (PKI) 、もしくは AWS Private CA などの一般的な CA サービスを利用して、証明書署名要求 (CSR) に署名を行うことができます。この統合により、フリートプロビジョニングを行う際に X.509 クライアント証明書の属性をカスタマイズすることが可能となり、セキュリティが重視されるシナリオでは特に有効です。このブログでは、AWS マネジメントコンソールと AWS CLI を使用してどのようにセルフマネージドのクライアント証明書の署名を行うことができるか解説します。 フリートプロビジョニングでのセルフマネージドの証明書署名機能の利点 クライアント証明書のカスタマイズの合理化: セルフマネージドのクライアント証明書署名機能により、フリートプロビジョニングにおいて任意の CA で直接クライアント証明書の署名を行うことができます。そのため、カスタムのソリューションを設定する必要がなく、導入にかかる時間を節約し、メンテナンスコストを削減することができます。 セキュリティと柔軟性の強化: お客様のプライベート CA や他のパブリックに信頼されている CA を用いることでお客様のセキュリティ要件に柔軟に対応できるようになります。有効期間、署名アルゴリズム、発行者、エクステンションを選択することができるため、よりフレキシブルに証明書の管理を行うことができます。 ファームウェアのアップデートは不要: 新しいセルフマネージドの証明書の署名を使用するためにファームウエアのアップデートは不要です。AWS マネジメントコンソール、もしくは AWS CLI 上からセルフマネージドのクライアント証明書署名方式を有効にすると、フリートプロビジョニングの CreateCertificateFromCsr MQTT API の証明書の署名の動作が更新されます。一方、AWS 管理のクライアント証明書署名方式を使用する場合、AWS IoT Core は自身の CA にてCSR に署名を行います。 AWS IoT Core フリートプロビジョニングの概要 AWS IoT Core のフリートプロビジョニング機能を使用すると、クライアントが AWS IoT Core に初めて接続するときに、クライアント証明書と秘密鍵を生成し、安全な形で配信することできます。特筆すべき点として、AWS IoT Core によって発行されたクライアント証明書だけでなく、CA 認証局によって署名されたクライアント証明書も利用することができます。この機能により、デバイスのセットアッププロセスが効率化され、カスタマイズの選択肢が増えます。 プロビジョニングには以下の2つの方法があります: クレームによるプロビジョニング 信頼できるユーザーによるプロビジョニング クレームによるプロビジョニング 製造時に、プロビジョニングだけを行う事が可能な、権限が制限されたプロビジョニングクレーム証明書と秘密鍵をデバイスに書き込んでおき、この証明書を AWS IoT Core に登録しておきます。これにより、サービス開始時にデバイスが通常のオペレーションで使用するためのクライアント証明書と交換することができます。 信頼できるユーザによるプロビジョニング 多くの場合、信頼されたユーザーによるプロビジョニングでは、エンドユーザーや管理者のような信頼されたユーザーが、モバイルアプリを使用して、デプロイされた場所でデバイスを設定するときに、デバイスが初めて AWS IoT Core に接続します。信頼されたユーザーによるプロビジョニングは、スマートホームデバイスなどの様に、デバイスをコンパニオンアプリで設定する必要がある場合によく使用されます。 この機能を有効にするワークフロー 前提条件 ご自身のAWS アカウントにて certificate provider を作成するための権限が付与されていること Lambda 関数を作成、追加する権限が付与されていること PLambda 関数の変数を追加、更新する権限が付与されていること Tセルフマネージドのクライアント証明書の署名を有効にするためには以下のステップが必要です 証明書に署名を行う AWS Lambda 関数を作成し、関数を実行するために AWS IoT の権限を付与します。 セルフマネージドの証明書署名方法に切り替えます。それにより、アカウントレベルで AWS IoT certificate provider のリソースが作成され、certificate provider がAWS Lambda 関数の Amazon Resource Name (ARN) を使用します。 AWS IoT Core の certificate provider が作成されると以降は、そのアカウントでの証明書署名要求 (CSR) に署名を行うために呼び出させる fleet provisioning CreateCertificateFromCsr MQTT API は AWS Lambda 関数を使用するようになります。AWS IoT Core 自身のもつ CA でクライアント証明書が署名されるように戻すために、Amazon 管理の CA に切り替えることも可能で、その場合には certificate provider はアカウントから消去されます。 ソリューションの概要 AWS IoT Core フリートプロビジョニングでのセルフマネージドクライアント証明書署名のソリューションの概要を、アーキテクチャ図とともに、順を追って見ていきましょう。 以下のステップは、ユーザーがセルフマネージドクライアント証明書署名を作成し、切り替えを行った際の CreateCertificateFromCsr の動作を示します: デバイスが CreateCertificateFromCsr をリクエストする。 AWS IoT Core certificate provider が存在しないので、AWS IoT Core は自身の CA にて CSR に署名を行い、クライアント証明書を発行する。 ユーザーがクライアント証明書作成方法をセルフマネージドに切り替える。これにより、 certificate provider が作成される。 デバイスが CreateCertificateFromCsr をリクエストする。 AWS IoT Core はクライアント証明書に署名を行うために certificate provider の AWS Lambda 関数を呼び出す。 ユーザーがクライアント証明書作成方法を AWS マネージドに切り替える。これにより、certificate provider が削除され、AWS マネージドクライアント証明書署名方式に移行する。 デバイスが CreateCertificateFromCsr をリクエストする。 クライアント証明書セルフサインメソッドが存在しないので、AWS IoT Core が CSR を署名する。 Figure 1.0: AWS IoT Core フリートプロビジョニングソリューションアーキテクチャ概要図 実装の手順 プライベート CA の作成 このブログではクライアント証明書のセルフ署名方式として AWS プライベート CA を証明書の署名に使用します。プライベート CA をどのように作成するかを示す手順については プライベート CA の作成 をご参照ください。作成した CA の ARN を保存しておいてください。 AWS Lambda 関数の作成 セルフマネージドクライアント証明書作成方法に切り替える前に、CSR に署名を行うための AWS Lambda 関数を作成する必要があります。以下の関数は、プライベート CA と SHA256WITHRSA の署名アルゴリズムを使用して、入力された CSR に署名を行うため、AWS プライベート CA を呼び出します。戻されたクライアント証明書は1年間有効です。(要望に応じて有効期限を変更することも可能です。サンプルコードは365日の有効期限を設定しています。) Step 1: AWS Lambda コンソールから: 関数の作成を選択 一から作成」を選択 関数名を入力し、最新の Python のランタイムを選択、残りの項目はデフォルトのままにします。 「関数の作成」を選択 関数が作成されたら Step2 へ。 Step 2: 関数を選択して、以下のサンプルコードをエディターにコピーします。 import os import time import uuid import boto3 def lambda_handler(event, context): ca_arn = os.environ['CA_ARN'] csr = (event['certificateSigningRequest']).encode('utf-8') acmpca = boto3.client('acm-pca') cert_arn = acmpca.issue_certificate( CertificateAuthorityArn=ca_arn, Csr=csr, Validity={"Type": "DAYS", "Value": 365}, SigningAlgorithm='SHA256WITHRSA', IdempotencyToken=str(uuid.uuid4()) )['CertificateArn'] # Wait for certificate to be issued time.sleep(1) cert_pem = acmpca.get_certificate( CertificateAuthorityArn=ca_arn, CertificateArn=cert_arn )['Certificate'] return { 'certificatePem': cert_pem } このコードは作成したプライベート CA の ARN を参照するので、ARN を関数の設定に登録することが必要です。関数の設定タブに移動し、左側のメニューバーから環境変数を選択します。CA_ARN をキーとして、作成したプライベート CAの ARN の値を値として登録します。 関数を実行するために AWS IoT のパーミッションを取得する AWS Lambda 関数を作成した後、関数を実行するために AWS IoT のパーミッションを取得します。 Step 1: Lambda 関数を選択 設定のタブを開く アクセス権限を選択 リソースベースのポリシーステートメントの箇所から 「アクセス権限を追加」を選択 「 AWS のサービス」を選択 サービスのドロップダウンメニューから「AWS IoT」を選択 ステートメントIDに一意なステートメントIDを入力 「ソース ARN」に certificate provider の ARN をペースト (以下のリージョン、アカウント ID 、certificate provider の名前を置き換えてください) “arn:aws:iot:REGION:ACCOUNT_ID:certificateprovider:CERTIFICATE_PROVIDER_NAME” 作成した AWS Lambda 関数をテスト 新しく作成した AWS Lambda 関数を選択し、「テスト」のタブにてテストイベントを作成することで、作成した AWS Lambda 関数をテストすることができます。テストイベントに以下のサンプル JSON データを挿入します。 { "certificateSigningRequest": "-----BEGIN CERTIFICATE REQUEST-----\nMIICaTCCAVECAQAwJDEiMCAGA1UEAwwZQm9zdG9uQ2VydGlmaWNhdGVQcm92aWRl\ncjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALAlk4aEcoheqUPFOj17\ne8Qs9fhLXkNLhtmx/ePE6A0Tb6dFwWt+jwspITE96heBBQrMVCwVkI2C5tbtpx3a\n8+c5qlSZBGX7w9Tlz1Ik30rJQTeB/X7CIU068ld4b+xBNxQLJQw0eSmWCC8p+CD/\nkdxC8rGCkSia/Cd7Hp9pTdBL8nU1t+QDppv+c4dtYrRVDjPmRcwpv4dyvH5/R6aZ\nxJToKPlt3P6cpa5KEhWZvjVt7XvpbU4GMhP+ZeQL1bLFWZAJ+tAiz6qG5xr4X/2V\nWjmSQWsDnbSzWjdRtXJZZGucIR6Gif95G2E08/VJlRtBi3d3OnhdYbYBiNW4X5ck\nsqkCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQCTqiW6qZ1nLW1pNt35wFVTpvzR\nUUkAdNLugmdNZIhqi4VWi0YXfhTPszOdnTcDAaoBTvSvmqCZHfPnRnt65XsMcNQO\nY+M5f/b1n5t0kKbzdFLu+GlK2eB+J8VtQqfAKw3q5a6Q0nu+OUOhm2PepdMkRoxw\n9tUDLTHiG/8zySxUo552hNlBz0wDVb1hjrEgLDi56mQ7FJKICzpkQAq5pMcJQj6t\nozWYrxzszGDa+ZFQ7H4DY/xl4acf1rownncF7mqQgVcAjTXchJ/ETIghJAO8qU1+\nz7ASTlm8Ym8Qov9YiISzss9i2z/78tVksvL3idZ5L0W2m6pnkVuQe3wknBYw\n-----END CERTIFICATE REQUEST-----", "clientId": "221a6d10-9c7f-42f1-9153-e52e6fc869c1", "principalId": "f2a33ae79323012c5f5b4250de3952568f1d81b2aa5bad1301b23b0991ba0ef4" } データを挿入後、保存し、テストを実行します。 AWS IoT のコンソール上でセルフマネージド型のクライアント証明書署名方式を有効にする AWS IoT のコンソール上から（以下のスクリーンショットをご参照ください） 「セキュリティ」を選択 「Certificate signing」を選択 「Edit signing method」を選択 Figure 1.1: フリートプロビジョニングでのセルフマネージド証明書署名 「Self-managed」を選択 証明書プロバイダーの設定で 証明書プロバイダー名に一意の名前を入力 AWS Lambda 関数について、先ほど作成した Lambda 関数を選択 証明書プロバイダーを作成」を選択 Figure 1.2: セルフ署名による署名書の署名を有効にする 「確認」と入力し、「確認」をクリックします。 Figure 1.3: 証明書署名方法を確認 完了すると、証明書プロバイダーが「Self-managed」に変更されます。 (以下の figure 1.4 をご参照ください) Figure 1.4: クライアント証明書詳細 セルフマネージドクライアント証明書署名の AWS Lambda 関数への入力 AWS IoT Core は、デバイスが CreateCertificateFromCsr MQTT API を呼び出すと、以下の JSON オブジェクトを AWS Lambda 関数に送信します。certificateSigningRequest の値は、デバイスが CreateCertificateFromCsr リクエストにて提供したCSR（ Privacy-Enhanced Mail（PEM）形式 ）です。principalId は、CreateCertificateFromCsr リクエストの際に AWS IoT Core への接続に使用したプリンシパル（クライアント証明書）の ID となります。clientId は MQTT 接続の際に設定したクライアント ID となります。 { "certificateSigningRequest": "string", "principalId": "string", "clientId": "string" } セルフマネージドクライアント証明書署名の AWS Lambda 関数からのレスポンス AWS Lambda 関数は certificatePem の値を含むレスポンスを戻す必要があります。以下は成功した場合のレスポンスの例です。AWS IoT は戻り値 (certificatePem) をクライアント証明書を作成するために使用します。 { "certificatePem": "string" } クライアント証明書の登録が成功した場合、CreateCertificateFromCsr は CreateCertificateFromCsr のレスポンスに含まれるのと同じ certificatePem を返します。詳細は、 CreateCertificateFromCsr のレスポンスのペイロードの例をご参照ください。 重要な注意事項: AWS Lambda 関数が返すクライアント証明書は、証明書署名要求（CSR）と同じサブジェクト名と公開鍵を持つ必要があります。 AWS Lambda 関数は、5秒以内に実行を終了する必要があります。 AWS Lambda 関数は、セルフマネージドクライアント証明書署名を有効にした AWS アカウントおよびリージョンにある必要があります。 AWS IoT サービスに対して、AWS Lambda 関数を実行する権限を付与する必要があります。サービス間での混乱した代理のセキュリティ問題を回避するために（ リンク先のガイダンス に従って、混乱した代理問題を回避してください）、Lambda 関数の実行権限には sourceArn と sourceAccount を設定することを推奨します。詳細については、 サービス間での混乱した代理問題の防止 を参照してください。 AWS CLI を用いてセルフマネージド型のクライアント証明書の署名を有効にする セルフマネージドクライアント証明書の署名を利用するには、アカウントレベルで AWS IoT Core の certificate provider を作成する必要があります。create-certificate-provider CLI コマンドを使って certificate provider を作成することができます。 aws iot create-certificate-provider \ --certificateProviderName my-certificate-provider \ --lambdaFunctionArn arn:aws:lambda:&lt;your-region&gt;:&lt;your-account-id&gt;:function:my-function \ --accountDefaultForOperations CreateCertificateFromCsr このコマンドの出力例は以下のようになります: { "certificateProviderName": "my-certificate-provider", "certificateProviderArn": "arn:aws:iot: &lt;your-region&gt;:&lt;your-account-id&gt;:my-certificate-provider" } AWS IoT Core の certificate provider の作成が成功すると、以下のようにアカウント内の provider のリストを取得することができます: aws iot list-certificate-providers このコマンドの出力例は以下のようになります: { "certificateProviders": [ { "certificateProviderName": "my-certificate-provider", "certificateProviderArn": "arn:aws:iot:us-east-1:123456789012:certificateprovider:my-certificate-provider" } ] } 注意: AWS IoT Core の certificate provider を作成するとフリートプロビジョニング向けの CreateCertificateFromCsr の API の振る舞いは、全ての CreateCertificateFromCsr の呼び出しが CSR を署名するために certificate provider を起動するように変わります。これには certificate provider が作成されてから数分を要しますのでご注意ください。 まとめ AWS IoT Core のフリートプロビジョニングでのセルフマネージドクライアント証明書署名機能により、フリートプロビジョニングを使用する際の証明書署名を、特定のニーズに応じてカスタマイズすることが可能となり、カスタムのインフラストラクチャを設定する必要がなくなります。この機能により、フリートプロビジョニングを使用する際に、よりフレキシブルでかつ制御性の高い形で組織固有のセキュリティの要件を満たすことが可能となります。 著者について Syed Rehan は、ロンドンの Amazon Web Services（AWS）のシニア IoT サイバーセキュリティスペシャリストで、AWS IoT の組織で活動しています。AWS IoT、機械学習、サイバーセキュリティに関する出版物の著者として、彼はグローバルな役割に広範な専門知識をもたらし、Syed は、AWS IoT Core Identify &amp; Access Management サービスの採用を促進するために、セキュリティスペシャリスト、開発者、セキュリティの意思決定者と協力して、グローバルな顧客にサービスを提供しています。サイバーセキュリティ、IoT、クラウド技術に関する深い知識を持ち、スタートアップから大企業まで幅広い顧客を支援し、AWS環境内で安全な IoT ソリューションの構築を可能にしています。 Victor Lesau は Amazon Web Services のシニアテクニカルプロダクトマネージャーです。AWS IoT Core Identity &amp; Access Management の製品戦略、ロードマップ計画、ビジネス分析、顧客エンゲージメント、その他の製品管理分野を担当しています。 Diana Molodan は、AWS IoT Core のソフトウェア開発エンジニアです。豊富な経験を生かし、応用暗号、ID 管理、IoT、クラウドインフラストラクチャに関連する技術に注力しています。 この記事は Syed Rehan、Victor Lesau 、Diana Molodan によって投稿された AWS IoT Core now supports private certificate authorities with fleet provisioning を翻訳したものです。プロフェッショナルサービス本部 シニア IoT コンサルタントの小林が翻訳しました。 <!-- '"` -->

AWS ParallelCluster は、新薬の発見から F1 レースカーの設計、天気の予測に至るまで、さまざまな問題に対応する強力なコンピューティング機能を提供します。 ParallelCluster を利用する全てのケースにおいて、シミュレーションを実行するエンジニアや、実験結果の分析を行うサイエンティストが手動で処理を実行する必要があります。 この投稿では、オープンソースの Slurm REST API を使用して、プログラムでジョブを送信したり監視したりする方法を説明します。 これにより、API 呼び出しを介して ParallelCluster を自動化システムに統合できます。 例えば、ゲノムサンプルがシーケンサーから読み取られるたびに、個々の読み取りのアライメントを行う二次解析パイプラインが自動的に供給されたり、新しい衛星データがAmazon S3バケットに格納されると、最新の天気予報を作成するジョブがトリガーされたりすることを意味します。 本日は、AWS ParallelCluster を使用してこのような仕組みを設定する方法を説明します。 使用できるコードを含む GitHub リポジトリへのリンクを示し、curl と Python の両方を使用して API を呼び出す方法の例を示します。 アーキテクチャー この図は、Slurm REST API を使用したクラスター アーキテクチャーの例を示しています。 REST API はヘッドノード上で実行され、ジョブを Compute キューに送信します。 API の認証に使用される認証情報は、 AWS Secrets Manager に保存されます。 図示されている Compute キューは例にすぎません。クラスターは任意のインスタンス構成で構成できます。 図 1 – REST API 実行におけるアーキテクチャー図 このチュートリアルでは、 ParallelCluster UI を使用してSlurm REST API を有効化し、クラスターをセットアップします。 ParallelCluster UI をセットアップするには、 オンライン ドキュメントを参照してください 。 ParallelCluster CLI を使用したい場合は、Step 4 のYAML 構成例 を参照してください。 Step 1 – インバウンド API リクエストを許可するセキュリティ グループを作成する デフォルト構成では、クラスターは REST API へのインバウンド HTTPS リクエストを受け入れることができません。セキュリティグループを作成して、クラスター外部からのAPI呼び出しを許可します。 EC2 セキュリティグループコンソール に移動し、 [セキュリティ グループを作成] を選択します。 [セキュリティ グループ名]に、 Slurm REST API (または任意の別の名前) を入力します。 [VPC] がクラスターを構築した VPC と一致することを確認してください。 インバウンド ルールを追加し、[タイプ] で HTTPS を選択し、[ソース] をアクセスしたい CIDR 範囲のみに変更します。 例えば、VPC に関連付けられた CIDR を設定することでVPC 内へのアクセスを制限できます。 [セキュリティグループを作成] を選択します。 図 2 – セキュリティグループの設定 Step 2 – IAM 権限を追加する ParallelCluster UI チュートリアル のセクションG – Setup IAM Permissions の手順に従ってください。 Step 3 – クラスターを構成する ParallelCluster UI の Create Clusters で、Head node section &gt; Head node instance &gt; Advanced options &gt; Additional security groups の項目に Step 1 で作成した Slurm REST API セキュリティーグループを追加します。Scripts 配下にある Run script on node configured を選択し、次のスクリプトを追加します。 https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh 図 3 – ノード構成後に実行するスクリプトの追加 Head node section &gt; Security configuration and permissions &gt; IAM Policies の項目に、ポリシーを追加します。この作業は JSON Web Token (JWT) を自動的に更新するために必要となります。 arn:aws:iam::aws:policy/SecretsManagerReadWrite 図 4 – AWS SecretsManager の更新を許可する IAM ポリシーの追加 クラスターを作成します。 Step 4 – 構成を検証する Cluster Configuration YAML ファイルは次のようなテキストになります。 ParallelCluster UI の代わりに ParallelCluster CLI を使用することを選択した場合は、以下を置き換える必要があります。 AdditionalSecurityGroups : Slurm REST API への接続を許可する追加のセキュリティ グループが含まれている必要があります (Step 1 にて作成)。 OnNodeConfigured : インストール後のスクリプトを参照する必要があります: https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh Imds: ImdsSupport: v1.0 HeadNode: InstanceType: c5.xlarge Imds: Secured: true Ssh: KeyName: amzn2 LocalStorage: RootVolume: VolumeType: gp3 Networking: SubnetId: subnet-xxxxxxxxxxxxxx AdditionalSecurityGroups: - sg-slurmrestapixxxxxxxxxx Iam: AdditionalIamPolicies: - Policy: arn:aws:iam::aws:policy/SecretsManagerReadWrite CustomActions: OnNodeConfigured: Script: &gt;- https://raw.githubusercontent.com/aws-samples/aws-parallelcluster-post-install-scripts/main/rest-api/postinstall.sh Scheduling: Scheduler: slurm SlurmQueues: - Name: queue-1 ComputeResources: - Name: queue-1-cr-1 Instances: - InstanceType: c5.xlarge MinCount: 0 MaxCount: 4 ComputeSettings: LocalStorage: RootVolume: VolumeType: gp3 Networking: SubnetIds: - subnet-xxxxxxxxxxxxxxxxxx Region: us-east-2 Image: Os: alinux2 Step 5 – API を呼び出す Step 1 のセキュリティグループ上で許可したネットワークのマシンにログインします。このマシンがヘッドノードと通信できることを確認してください。 ssh username@ip 次の環境変数を設定します。 export CLUSTER_NAME=[name of cluster] &nbsp;API リクエストを作成するために必要な情報を確認し、API リクエストを呼び出します。 APIリクエストの作成には、以下の情報が必要です。 ・JWT トークン : インストール後のスクリプトにより、 AWS SecretsManager に slurm_token_$CLUSTER_NAME という名前でシークレットが作成されます。 AWS コンソールまたは AWS CLI を使用して、クラスター名に基づいてシークレットを確認します。 export JWT=$(aws secretsmanager get-secret-value --secret-id slurm_token_$CLUSTER_NAME | jq -r '.SecretString') NOTE: Since the Slurm REST API script is not integrated into ParallelCluster, this secret will not be automatically deleted along with the cluster. You may want to remove it manually on cluster deletion. Bash ・ヘッドノードの Public IP : Amazon EC2 ダッシュボードまたは ParallelCluster CLI を使用してヘッドノードの Public IP を確認することができます。 export HEADNODE_IP=$(pcluster describe-cluster-instances -n $CLUSTER_NAME | jq -r '.instances[0].publicIpAddress') ・クラスター ユーザー : 利用するAMI によって異なりますが、通常は ec2-user 、 ubuntu 、または centos のいずれかになります。 export CLUSTER_USER=ec2-user curl を使用して API を呼び出します。 curl -H "X-SLURM-USER-NAME: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" https://$HEADNODE_IP/slurm/v0.0.39/ping -k 次のような応答が返されます。 { "meta": { "plugin": { "type": "openapi\/v0.0.39", "name": "REST v0.0.39" }, "Slurm": { "version": { "major": 23, "micro": 2, "minor": 2 }, "release": "23.02.2" }... APIを使用してジョブを送信します。 JSONを使用してジョブパラメーターを指定します。 クラスターユーザーに応じて、標準ディレクトリの変更が必要になる場合があります。 API にジョブを送信します。 curl -H "X-SLURM-USER-TOKEN: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" -X POST https://$IP/slurm/v0.0.39/job/submit -H "Content-Type: application/json" -d @testjob.json -k ジョブが実行中であることを確認します。 curl -H "X-SLURM-USER-NAME: $CLUSTER_USER" -H "X-SLURM-USER-TOKEN: $JWT" https://$IP/slurm/v0.0.39/jobs -k Python リクエスト ライブラリを使用した API の呼び出し 次の内容を含む slurmapi.py というスクリプトを作成します。 #!/usr/bin/env python3 import argparse import boto3 import requests import json # Create argument parser parser = argparse.ArgumentParser() parser.add_argument('-n', '--cluster-name', type=str, required=True) parser.add_argument('-u', '--cluster-user', type=str, required=False) subparsers = parser.add_subparsers(dest='command', required=True) diag_parser = subparsers.add_parser('diag', help="Get diagnostics") ping_parser = subparsers.add_parser('ping', help="Ping test") submit_job_parser = subparsers.add_parser('submit-job', help="Submit a job") submit_job_parser.add_argument('-j', '--job', type=str, required=True) list_jobs_parser = subparsers.add_parser('list-jobs', help="List active jobs") describe_job_parser = subparsers.add_parser('describe-job', help="Describe a job by id") describe_job_parser.add_argument('-j', '--job-id', type=int, required=True) cancel_parser = subparsers.add_parser('cancel-job', help="Cancel a job") cancel_parser.add_argument('-j', '--job-id', type=int, required=True) args = parser.parse_args() # Get JWT token client = boto3.client('secretsmanager') boto_response = client.get_secret_value(SecretId=f'slurm_token_{args.cluster_name}') jwt_token = boto_response['SecretString'] # Get cluster headnode IP client = boto3.client('ec2') filters = [{'Name': 'tag:parallelcluster:cluster-name', 'Values': [args.cluster_name]}] boto_response = client.describe_instances(Filters=filters) headnode_ip = boto_response['Reservations'][0]['Instances'][0]['PublicIpAddress'] url = f'https://{headnode_ip}/slurm/v0.0.39' headers = {'X-SLURM-USER-TOKEN': jwt_token} if args.cluster_user: headers['X-SLURM-USER-NAME'] = args.cluster_user # Make request if args.command == 'ping': r = requests.get(f'{url}/ping', headers=headers, verify=False) elif args.command == 'diag': r = requests.get(f'{url}/diag', headers=headers, verify=False) elif args.command == 'submit-job': with open(args.job) as job_file: job_json = json.load(job_file) r = requests.post(f'{url}/job/submit', headers=headers, json=job_json, verify=False) elif args.command == 'list-jobs': r = requests.get(f'{url}/jobs', headers=headers, verify=False) elif args.command == 'describe-job': r = requests.get(f'{url}/job/{args.job_id}', headers=headers, verify=False) elif args.command == 'cancel-job': r = requests.delete(f'{url}/job/{args.job_id}', headers=headers, verify=False) print(r.text) ジョブを送信するには下記を実行してください。 ./slurmapi.py -n [cluster_name] submit-job -u [cluster_user] -j testjob.json さらに詳しい情報を入手するには下記を実行してください。 ./slurmapi.py -h 結論 Slurm REST API をセットアップすると、クラスターをプログラムで制御できるようになり、クラスターを自動化ワークフロー上で構築できるようになります。 これにより、無数のユースケースの中でも、ゲノミクスデータの自動二次分析、金融市場のリスク分析、天気予報などの新しいユースケースが可能になります。 私たちは皆さんが何を構築するかを楽しみにしています。思いついたものを X（旧Twitter） に投稿して紹介してください。 この投稿は、シニア HPC ソリューション アーキテクトである Sean Smith と、HPC SDE インターンである Ryan Kilpadi によって寄稿されました。 翻訳はソリューションアーキテクトの寺部が担当しました。原文は こちら です。 著者について Ryan Kilpadi Ryan Kilpadi は、AWS ParallelCluster を手がける HPC チームの SDE インターンとして戻ってきました。 彼は、2022 年の夏のインターンシップ プロジェクトとして、ParallelCluster での Slurm REST API の実装に取り組みました。 Sean Smith Sean Smith は、AWS の HPC および生成 AI 担当のシニア スペシャリスト ソリューション アーキテクトです。 以前は AWS Batch と CfnCluster のソフトウェア エンジニアとして働き、AWS ParallelCluster を作成したチームの最初のエンジニアになりました。

異種データベースの移行は多段階のプロセスであり、通常、評価、データベーススキーマの変換、データ移行、機能テスト、パフォーマンスチューニングなど、複数のチームにわたる多くのステップが含まれます。 IBM Db2 LUW から Amazon Aurora PostgreSQL 互換エディション または Amazon Relational Database Service (Amazon RDS) for PostgreSQL への移行は、本質的に異種DBの移行であり、従前から用いられているこういった手順が必要です。 AWS では、異種データベース移行のスキーマ変換を簡素化する AWS Schema Conversion Tool (AWS SCT)や、ダウンタイムを最小限に抑えながらデータを迅速かつ安全に AWS に移行できる AWS Database Migration Service (AWS DMS) などのツールとサービスを提供しています。 AWS SCT は、PostgreSQL に自動的に変換される Db2 コードの割合、変換に手作業が必要なコードの割合と詳細なアクション項目を示す評価レポートを生成します。 AWS SCT によるスキーマの移行は完全に自動化されたプロセスではないため、ターゲットデータベースのオブジェクトや主要なオブジェクト機能が不足している可能性は常にあります。 スキーマの検証は移行プロセスにおいて、スキーマ変換プロセスでの問題を、それ以降の段階に持ち越さないようにするための重要なマイルストーンです。 この記事では、Db2 LUW から Amazon RDS for PostgreSQL または Aurora PostgreSQL に移行されたデータベーススキーマオブジェクトを検証する方法について説明します。 いつ、どのオブジェクトを検証すべきか スキーマを Db2 LUW から正常に変換し、AWS SCT またはその他の変換ツールを使用して PostgreSQL に変換されたスキーマをデプロイ後、スキーマ検証を実行する必要があります。 次のリストは、データベース移行時に検証する必要がある Db2 LUW (ソース) と Aurora PostgreSQL (ターゲット) のデータベースオブジェクトを示しています。 スキーマ テーブル ビュー 主キー 外部キー インデックス マテリアライズドクエリテーブル ユーザー定義データ型 トリガー シーケンス プロシージャ 関数 以下のセクションでは、各オブジェクトタイプのオブジェクト数がソースデータベースとターゲットデータベースで一定であることを確認するために、各オブジェクトタイプの検証シナリオを詳細に説明します。 これらの検証シナリオでは、変換の精度は対象外です。 スキーマ スキーマは、アプリケーションまたはマイクロサービスに関連した機能を提供するデータベースオブジェクトの集まりです。 SQL クエリを使用して、ソースデータベースとターゲットデータベースのスキーマを検証できます。 DB2 LUW Query PostgreSQL Query select schemaname as schema_name from syscat . schemata where schemaname not like 'SYS%' and schemaname not IN ( 'SQLJ' , 'NULLID' ) order by schema_name ; SQL SELECT SCHEMA_NAME , SCHEMA_OWNER FROM INFORMATION_SCHEMA . SCHEMATA WHERE SCHEMA_NAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) AND SCHEMA_NAME not like 'pg_temp%' AND SCHEMA_NAME not like 'pg_toast%' order by SCHEMA_NAME ; SQL Db2 LUW example output: PostgreSQL example output: Db2 LUW スキーマを変換すると、AWS SCT はターゲットデータベースに追加のスキーマ ( aws_db2_ext と aws_db2_ext_data ) を追加します。 これらのスキーマは、変換されたスキーマを Aurora PostgreSQL データベースに書き込む際に必要な Db2 LUW データベースの SQL システム関数を実装します。 これらの追加スキーマは AWS SCT 拡張パック と呼ばれます。 Db2 LUW と PostgreSQL (‘ pg_catalog ‘、’ information_schema ‘、’ public ‘) のシステムテーブルまたはカタログテーブル (‘ SYS% ‘、’ SQLJ ‘、’ NULLID ‘) に関連するスキーマは除外されます。 また、Aurora PostgreSQL の特定の機能に関連するスキーマ ( aws_commons 、 aws_lambda ) も除外しています。 ソースデータベースとターゲットデータベースのスキーマの数が一致していることを確認する必要があります。 相違点が見つかった場合は、 AWS SCT のログ を調べて障害の原因を特定するか、手動で作成する必要があります。 テーブル AWS SCT はソース Db2 LUW テーブルを同等のターゲット (PostgreSQL) テーブルに変換します。 必要に応じて、カスタム マッピングルール を使用して特定のテーブルを移行対象に含めたり除外したりできます。 以下のスクリプトは、すべてのテーブルの数と詳細レベルの情報を返します。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as table_count from syscat . tables tab where tab . type = 'T' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL SELECT NSPNAME as schema_name , count ( RELNAME ) as table_count FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'p' , 'r' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) group by NSPNAME ORDER BY NSPNAME ; SQL Db2 LUW example output: PostgreSQL example output: IBM Db2 ではテーブルパーティションを個別のテーブルとしてリストしていないため、PostgreSQL のパーティションテーブルを除外するために C.RELISPARTITION = 'f' という条件を追加しました。 PostgreSQL には、プライマリキー、外部キー、インデックスのオブジェクト数に影響する可能性のある パーティションテーブル に関するいくつかの制限があることに注意してください。 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as table_name from syscat . tables tab where tab . type = 'T' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname ; SQL SELECT NSPNAME as schema_name , RELNAME as table_name FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'p' , 'r' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) order by NSPNAME , RELNAME ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベースの結果を検証します。 違いが見られる場合は、AWS SCT または手動ログから理由を特定し、問題を解決した後に失敗したステートメントを再実行してください。 ビュー AWS SCT によって変換されたビュー数は、ソースデータベースとターゲットデータベースで次のクエリを実行して検証できます。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as view_count from syscat . tables tab where tab . type = 'V' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL SELECT NSPNAME as schema_name , count ( RELNAME ) as view_count FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'v' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' ) group by NSPNAME order by NSPNAME ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as view_name from syscat . tables tab where tab . type = 'V' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname ; SQL SELECT NSPNAME as schema_name , RELNAME as view_name FROM PG_CLASS C LEFT JOIN PG_NAMESPACE N ON N . OID = C . RELNAMESPACE WHERE C . RELKIND in ( 'v' ) AND C . RELISPARTITION = 'f' AND N . NSPNAME not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by NSPNAME , RELNAME ; SQL Db2 LUW example output: PostgreSQL example output: この SQL を使用して、ソースとターゲットの間の数と詳細を確認する必要があります。 相違点が見つかった場合は、原因を特定して相違点を修正してください。 主キー データベースオブジェクトの検証に加えて、データに一貫性があり、整合性が保たれていることを確認する必要があります。 制約 の種類が異なると、挿入時にデータを柔軟に制御して確認できるため、実行時のデータ整合性の問題を回避できます。 主キーを使用すると、列に一意の値を設定できるため、正規化処理後に情報が重複するのを防ぐことができます。 このキーは、キー値に基づく検索を改善し、テーブルスキャンを回避するのに役立ちます。 次のクエリは、ソースデータベースとターゲットデータベースの主キーの数と詳細を抽出するのに役立ちます。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( * ) as PK_Count from syscat . tables tab inner join syscat . tabconst const on const . tabschema = tab . tabschema and const . tabname = tab . tabname and const . type = 'P' inner join syscat . keycoluse key on const . tabschema = key . tabschema and const . tabname = key . tabname and const . constname = key . constname where tab . type = 'T' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL select kcu . table_schema , count ( * ) as pk_count from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'PRIMARY KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by kcu . table_schema order by kcu . table_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , tab . tabname as table_name , const . constname , key . colname as column_name , key . colseq as position from syscat . tables tab inner join syscat . tabconst const on const . tabschema = tab . tabschema and const . tabname = tab . tabname and const . type = 'P' inner join syscat . keycoluse key on const . tabschema = key . tabschema and const . tabname = key . tabname and const . constname = key . constname where tab . type = 'T' and tab . tabschema not like 'SYS%' order by tab . tabschema , tab . tabname , const . constname , key . colname , key . colseq ; SQL select kcu . table_schema , kcu . table_name , tco . constraint_name , kcu . column_name , kcu . ordinal_position as position from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'PRIMARY KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by kcu . table_schema , kcu . table_name , tco . constraint_name , kcu . column_name , kcu . ordinal_position ; SQL Db2 LUW example output: PostgreSQL example output: この SQL を使用して、ソースとターゲットの間のプライマリキーの数と詳細を確認する必要があります。 相違点が見つかった場合は、デプロイログから原因を特定し、違いを修正してください。 外部キー 外部キーはテーブル間の参照整合性を維持するのに役立ちます。 AWS DMS のフルロードを使用してデータ移行を実行する前に、ターゲット側でこれらのキーをオフにする必要があります。 詳細については、「 PostgreSQL データベースの AWS Database Migration Service のターゲットとしての使用 」を参照してください。 次のクエリでは、ソースデータベースとターゲットデータベースの両方にある外部キーの数と詳細レベルの情報を取得できます。 外部キーは、AWS DMS を使用してフルロードによるデータ移行を完了した後に検証します。 Db2 LUW Query PostgreSQL Query select tabschema as schema_name , count ( * ) as fk_count from syscat . references where tabschema not like 'SYS%' group by tabschema order by tabschema ; SQL select kcu . table_schema , count ( * ) as fk_count from information_schema . table_constraints tco join information_schema . key_column_usage kcu on kcu . constraint_name = tco . constraint_name and kcu . constraint_schema = tco . constraint_schema and kcu . constraint_name = tco . constraint_name where tco . constraint_type = 'FOREIGN KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by kcu . table_schema order by kcu . table_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select ref . reftabschema as schema_name , ref . reftabname as table_name , ref . constname as fk_constraint_name , ref . tabname as foreign_table_name , trim ( key . colname ) as fk_column_name from syscat . references ref left outer join syscat . keycoluse key on key . tabschema = ref . tabschema and key . tabname = ref . tabname and key . constname = ref . constname where ref . tabschema not like 'SYS%' order by ref . reftabschema , ref . reftabname , ref . constname ; SQL select rel_kcu . table_schema as schema_name , rel_kcu . table_name as table_name , kcu . constraint_name , kcu . table_name as foreign_table_name , kcu . column_name as fk_column_name from information_schema . table_constraints tco join information_schema . key_column_usage kcu on tco . constraint_schema = kcu . constraint_schema and tco . constraint_name = kcu . constraint_name join information_schema . referential_constraints rco on tco . constraint_schema = rco . constraint_schema and tco . constraint_name = rco . constraint_name join information_schema . key_column_usage rel_kcu on rco . unique_constraint_schema = rel_kcu . constraint_schema and rco . unique_constraint_name = rel_kcu . constraint_name and kcu . ordinal_position = rel_kcu . ordinal_position where tco . constraint_type = 'FOREIGN KEY' and kcu . table_schema not in ( 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_data' , 'aws_db2_context' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by rel_kcu . table_schema , rel_kcu . table_name , kcu . constraint_name ; SQL Db2 LUW example output: PostgreSQL example output: PostgreSQL バージョン 11 にはパーティションテーブルの外部キーに関する 制限 がありますが、その制限の多くはバージョン 12 以降では解消されています。 ソースデータベースとターゲットデータベース間の外部キーの数と詳細を検証する際は、これらの制限に留意する必要があります。 インデックス インデックスは、テーブルの 1 つ以上の列に基づいて作成されるデータベースオブジェクトです。 インデックスはクエリのパフォーマンスを改善し、ユニークインデックスとして定義した場合にはデータの一意性を保証します。 ユニークインデックス ユニークキーを使用すると、カラム内のデータの一意性を維持できます。 次のクエリを使用すると、ソースデータベースとターゲットデータベースの両方にあるユニークキーの数と詳細レベルの情報を取得できます。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , count ( cols . colname ) as unique_count from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'U' ) group by ind . tabschema order by schema_name ; SQL SELECT sch . nspname , count ( * ) as unique_count FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 't' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by sch . nspname order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , ind . tabname as table_name , ind . indname as CONSTRAINT_NAME , 'Unique Index' as constraint_type , cols . colname as column_name from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'U' ) order by schema_name , ind . tabname , ind . indname ; SQL SELECT sch . nspname as schema_name , tab . relname as table_name , cls . relname as constraint_name , ids . indexdef as definition FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 't' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 非ユニークインデックス インデックス はクエリのパフォーマンスを向上させる上で重要な役割を果たします。 チューニング方法はデータベースごとに異なるため、Db2 LUW データベースと PostgreSQL データベースではユースケースによってインデックスの数や種類が異なるため、インデックスの数も異なる場合があります。 PostgreSQL のパーティションテーブルの制限により、インデックス数も異なる場合があります。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , count ( cols . colname ) as index_count from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'D' ) group by ind . tabschema order by schema_name ; SQL SELECT sch . nspname , count ( * ) as index_count FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 'f' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) group by sch . nspname order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select ind . tabschema as schema_name , ind . tabname as table_name , ind . indname as index_name , cols . colname as column_name from syscat . indexes ind join syscat . indexcoluse cols on ind . indname = cols . indname and ind . indschema = cols . indschema where ind . tabschema not like 'SYS%' and ind . uniquerule in ( 'D' ) order by schema_name , ind . tabname , ind . indname , cols . colname ; SQL SELECT sch . nspname as schema_name , tab . relname as tabl_name , cls . relname as constraint_name , ids . indexdef as definition FROM pg_index idx JOIN pg_class cls ON cls . oid = idx . indexrelid JOIN pg_class tab ON tab . oid = idx . indrelid and tab . RELISPARTITION = 'f' JOIN pg_namespace sch on sch . oid = tab . relnamespace JOIN pg_am am ON am . oid = cls . relam JOIN pg_indexes ids ON sch . nspname = ids . schemaname and ids . tablename = tab . relname and cls . relname = ids . indexname where idx . indisunique = 'f' and indisprimary = 'f' and sch . nspname not in ( 'pg_toast' , 'pg_catalog' , 'information_schema' , 'aws_commons' , 'aws_lambda' , 'aws_db2_ext_data' , 'aws_db2_ext' , 'public' , 'db2inst1' ) order by sch . nspname ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベース間のインデックスの数と詳細を確認する必要があります。違いがある場合は、既知の理由によるものか、デプロイメントログに基づいて調査して修正する必要があります。 マテリアライズド・クエリー・テーブル Db2 LUW のマテリアライズドクエリテーブルは PostgreSQL の マテリアライズドビュー として移行されます。 マテリアライズドクエリテーブルが結果をテーブルのような形で保持することを除けば、通常のビューと似ています。 これにより、データがすぐに返されるので、クエリのパフォーマンスが向上します。 次のクエリを使用して、ソースとターゲットのオブジェクトを比較できます。 Db2 LUW Query PostgreSQL Query select tab . tabschema as schema_name , count ( tab . tabname ) as mq_count from syscat . tables tab where tab . type = 'S' and tab . tabschema not like 'SYS%' group by tab . tabschema order by tab . tabschema ; SQL select schemaname , count ( * ) as mq_count from pg_matviews where schemaname NOT IN ( 'information_schema' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) group by schemaname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tabschema as schema_name , tabname as MQ_NAME from syscat . tables where type = 'S' and tabschema not like 'SYS%' ; SQL select schemaname , matviewname as mq_name from pg_matviews where schemaname NOT IN ( 'information_schema' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベース間のマテリアライズドクエリテーブルとマテリアライズドビューの数と詳細を確認し、違いがあればデプロイログに基づいて調査して修正する必要があります。 ユーザー定義データ型 AWS SCT はカスタムデータタイプを Db2 LUW から PostgreSQL に タイプ として移行します。次のクエリを使用して、ソースとターゲットのオブジェクトを比較できます。 Db2 LUW Query PostgreSQL Query select typeschema as schema_name , count ( * ) as udt_count from SYSCAT . DATATYPES where typeschema not like 'SYS%' group by typeschema ; SQL SELECT n . nspname , count ( * ) as udt_count FROM pg_catalog . pg_type t JOIN pg_catalog . pg_namespace n ON n . oid = t . typnamespace WHERE ( t . typrelid = 0 OR ( SELECT c . relkind = 'c' FROM pg_catalog . pg_class c WHERE c . oid = t . typrelid ) ) AND NOT EXISTS ( SELECT 1 FROM pg_catalog . pg_type el WHERE el . oid = t . typelem AND el . typarray = t . oid ) AND n . nspname NOT IN ( 'information_schema' , 'pg_toast' , 'aws_commons' , 'pg_catalog' , 'public' , 'aws_db2_ext' , 'aws_db2_ext_data' ) group by n . nspname order by n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: ソースデータベースとターゲットデータベース間のユーザー定義型の数と詳細を確認し、違いがあればデプロイログに基づいて調査して修正する必要があります。 トリガー トリガー は、データベースの監査、ビジネスルールの実装、参照整合性の実装に役立ちます。 また、適切な領域での使用状況によっては、パフォーマンスに影響を与えることもあります。 以下のクエリでは、ソースデータベースとターゲットデータベースの両方のトリガーの数と詳細がわかります。 Db2 LUW Query PostgreSQL Query select tabschema as table_schema , count ( trigname ) as trigger_count From syscat . triggers t where tabschema not like 'SYS%' group by tabschema order by tabschema ; SQL SELECT trigger_schema AS SchemaName , Count ( trigger_name ) AS TriggerCount FROM information_schema . TRIGGERS WHERE trigger_schema NOT IN ( 'aws_db2_ext' , 'aws_db2_ext_data' , 'pg_catalog' ) GROUP BY trigger_schema ORDER BY trigger_schema ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select tabschema as table_schema , trigname as trigger_name , tabname as table_name , case trigtime when 'B' then 'before' when 'A' then 'after' when 'I' then 'instead of' end as activation , rtrim ( case when eventupdate = 'Y' then 'update ' else '' end || case when eventdelete = 'Y' then 'delete ' else '' end || case when eventinsert = 'Y' then 'insert ' else '' end ) as event from syscat . triggers t where tabschema not like 'SYS%' order by table_name , trigger_name ; SQL SELECT trigger_schema AS TriggerSchemaName , trigger_name , event_object_schema AS TableSchema , event_object_table AS TableName , event_manipulation AS TriggerType FROM information_schema . TRIGGERS WHERE trigger_schema NOT IN ( 'aws_db2_ext' , 'aws_db2_ext_data' , 'pg_catalog' ) ORDER BY trigger_schema , trigger_name ; SQL Db2 LUW example output: PostgreSQL example output: Db2 LUW と PostgreSQL の間のトリガー数は、PostgreSQL でのトリガーの 実装方法 によって異なる場合があります。 ソースデータベースとターゲットデータベース間のトリガーの数と詳細を確認する必要があります。相違点がある場合は、既知の理由によるものか、デプロイメントログに基づいて調査して修正する必要があります。 シーケンス シーケンスは、指定した範囲と順序に基づいて列の整数値を作成したり増やすのに役立ちます。 ID 列とは異なり、シーケンスは特定のテーブルに関連付けられません。 アプリケーションはシーケンスオブジェクトを参照して次の値を取得します。 シーケンスとテーブルの関係はアプリケーションによって制御されます。 ユーザーアプリケーションはシーケンスオブジェクトを参照し、複数の行やテーブルにわたって値を調整できます。 以下のクエリは、ソースデータベースとターゲットデータベースにあるシーケンスの数と詳細レベルの情報を取得するのに役立ちます。 Db2 LUW Query PostgreSQL Query select SEQSCHEMA , count ( * ) as seq_count from syscat . sequences where SEQSCHEMA not like 'SYS%' and OWNERTYPE = 'U' and SEQTYPE = 'S' group by SEQSCHEMA order by SEQSCHEMA ; SQL select n . nspname as schema_namee , count ( * ) as seq_count from pg_sequence seq join pg_class seqc on seq . seqrelid = seqc . oid join pg_namespace n on seqc . relnamespace = n . oid where n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) group by n . nspname order by n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下を使用してください。 Db2 LUW Query PostgreSQL Query select SEQSCHEMA , SEQNAME , CYCLE , ORDER , CACHE from syscat . sequences where SEQSCHEMA not like 'SYS%' and OWNERTYPE = 'U' and SEQTYPE = 'S'; SQL select n . nspname as schema_namee , seqc . relname as seqname , seqcycle as cycle , seqcache as cache from pg_sequence seq join pg_class seqc on seq . seqrelid = seqc . oid join pg_namespace n on seqc . relnamespace = n . oid where n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) order by n . nspname , seqc . relname ; SQL Db2 LUW example output: PostgreSQL example output: ソースとターゲットの間のシーケンスの数と詳細を確認する必要がありますが、移行後にシーケンスを正しい値に 設定する ことも重要です。 シーケンスをソースデータベースからターゲットデータベースに移行した後は、シーケンスの minvalue から始まるため、挿入文や更新文の実行中に重複キーエラーが発生する可能性があります。 プロシージャ Db2 LUW ストアドプロシージャは、ビジネスロジックをカプセル化し、関連する DDL または DML 操作を単一の作業単位で実行します。 PostgreSQL では、 プロシージャ の制限により、ストアドプロシージャよりも 関数 を使用します。この数は、ソースデータベース内の既存の関数数に加算されます。 ソースデータベースとターゲットデータベースの両方で、次のクエリはプロシージャの数と詳細レベルの情報を提供します。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , count ( * ) as proc_count from syscat . routines where routinetype = 'P' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' group by routineschema order by routineschema ; SQL SELECT n . nspname AS SchemaName , Count ( p . proname ) AS procCount FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'p' GROUP BY n . nspname ORDER BY n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , routinename as procedure_name from syscat . routines where routinetype = 'P' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' order by schema_name , procedure_name ; SQL SELECT n . nspname AS SchemaName , p . proname AS function_name FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'p' GROUP BY n . nspname , p . proname ORDER BY n . nspname , p . proname ; SQL Db2 LUW example output: PostgreSQL example output: 関数 Db2 LUW では、関数は入力パラメータに特定のビジネスロジックまたは機能ロジックを実装し、特定の種類の定義済み出力を返します。 PostgreSQL では、ビジネスロジックとファンクショナルロジックの実装に関数が好まれるため、その数は通常 Db2 LUW よりも多くなります（訳注： PostgreSQL では、関数を使ってロジック実装されることが Db2 と比較すると多いためで、 SCT の変換機能により関数の数が増えるわけではありません）。ソースデータベースとターゲットデータベースの両方で、以下のクエリは関数の数と詳細レベルの情報を提供します。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , count ( * ) as func_count from syscat . routines where routinetype = 'F' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' group by routineschema order by routineschema ; SQL SELECT n . nspname AS SchemaName , Count ( p . proname ) AS func_Count FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'f' GROUP BY n . nspname ORDER BY n . nspname ; SQL Db2 LUW example output: PostgreSQL example output: 詳細レベルの情報については、以下のクエリを使用してください。 Db2 LUW Query PostgreSQL Query select routineschema as schema_name , routinename as function_name from syscat . routines where routinetype = 'F' and routineschema not like 'SYS%' and routineschema not like 'SQLJ%' order by schema_name , function_name ; SQL SELECT n . nspname AS SchemaName , p . proname AS function_name FROM pg_proc p join pg_namespace n ON p . pronamespace = n . oid WHERE n . nspname NOT IN ( 'pg_catalog' , 'information_schema' , 'aws_db2_ext' , 'aws_db2_ext_data' , 'aws_commons' , 'db2inst1' , 'aws_lambda' , 'public' ) AND p . prokind = 'f' GROUP BY n . nspname , p . proname ORDER BY n . nspname , p . proname ; SQL Db2 LUW example output: PostgreSQL example output: 有用な PostgreSQL カタログテーブル 次の表は、いくつかの有用な Db2 LUW と、それに対応する PostgreSQL システムおよびカタログのテーブルとビューをまとめたものです。 これらのテーブルとビューには、データベース内に存在するさまざまなオブジェクトに関するメタデータが含まれており、データベースオブジェクトの検証に使用されます。 Db2 LUW PostgreSQL Use Case syscat.tables/ syscat.columns pg_tables /information_schema.tables さまざまなテーブルのプロパティ syscat.tables/ syscat.columns Pg_views/information_schema.views ビューのさまざまなプロパティ syscat.tables/ syscat.tabconst/ syscat.references/ syscat.keycoluse pg_indexes/pg_index インデックスに関する詳細情報 syscat.routines pg_proc プロシージャ、関数、トリガー関数に関する詳細情報 syscat.triggers information_schema.triggers トリガーに関する詳細情報 Syscat.sequences pg_sequence/information_schema.sequences シーケンス、ID、serialカラムに関する詳細情報 Syscat.tables pg_matviews マテリアライズドビューの詳細 syscat.datatypes pg_type カスタムデータ型に関する詳細情報 PostgreSQL ではサポートされていないオブジェクトの扱い PostgreSQL でサポートされていない Db2 LUW オブジェクトの移行は手動で実行する必要があります。 この記事で提供するクエリを使用すると、移行したオブジェクトを繰り返し検証してギャップを特定し、それに応じて修正できます。 まとめ この投稿では、Db2 LUW と Aurora PostgreSQL、または PostgreSQL データベース用の RDS のメタデータクエリによるデータベースオブジェクトの検証について説明しました。 データベースオブジェクトの検証は、移行の正確性を詳細に把握し、すべてのデータベースオブジェクトが適切に移行されたかどうかを確認するための重要なステップです。 また、データベース検証フェーズでは、ターゲットデータベースの整合性を確認し、依存するアプリケーションプロセスの事業継続性を確保します。 オブジェクトが自動変換されるか手動で変換されるかに関係なく、機能テストだけでなくユニットテストも数回繰り返す必要があります。 これにより、アプリケーションとの統合テストを行う際の多くのやり直しが省けます。 コメントや質問がある場合はお知らせください。 私たちは皆さんのフィードバックを大切にしています！ 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。 著者について Sai Parthasaradhi は AWS プロフェッショナルサービスのデータベース移行スペシャリストです。 彼はお客様と緊密に連携して、お客様が AWS でデータベースを移行し、最新化できるよう支援しています。 Rakesh Raghav は、インドの AWS プロフェッショナルサービスの主任データベースコンサルタントで、お客様がクラウドの導入と移行を成功させるお手伝いをしています。 彼は、お客様のデータベースのクラウドへの移行を加速させる革新的なソリューションの構築に情熱を注いでいます。 Veeranjaneyulu Grandhi は、AWSのデータベースコンサルタントです。 彼はお客様と協力して、スケーラブルで可用性が高く、安全なソリューションを AWS クラウドで構築しています。 彼の重点分野は、同種データベース移行と異種データベース移行です。

この投稿では、IBM Guardium でモニタリングするための Amazon Aurora PostgreSQL 互換エディション のデータベースアクティビティストリーミング (DAS) をセットアップする手順を説明します。 ここでは IBM Guardium バージョン 11.5 を使用しています。 Aurora PostgreSQL 互換エディションは、 Amazon Aurora のスピード、信頼性、管理性と、オープンソースデータベースのシンプルさと費用対効果を兼ね備えた、フルマネージドの PostgreSQL 互換、ACID 準拠のリレーショナルデータベースエンジンです。 IBM Guardium は、データベースアクティビティのモニタリングとデータ保護機能を提供する IBM セキュリティ製品です。 IBM Guardium は Aurora データベース内のアクティビティをリアルタイムで継続的に監視します。 SQL ステートメント、ログイン試行、管理アクションをキャプチャして分析します。 Guardiumはデータベースのアクティビティを即座に可視化することで、疑わしいアクティビティや不正なアクティビティを迅速に特定して対応できるようにします。 高度な分析と機械学習 (ML) 技術を採用して、潜在的なセキュリティ脅威を検出して防止します。 また、データ保護ポリシーを実施することで、 Amazon Relational Database Service (Amazon RDS) に保存されている機密データを保護するのにも役立ちます。 Amazon RDS 環境内のきめ細かなアクセス制御を確立し、特権ユーザーのアクティビティを監視できます。 IBM Guardiumは、組織がGDPR、HIPAA、PCI DSSなどを含む 幅広い規制や標準 へのコンプライアンスを維持できるよう支援します。 コンプライアンス要件を満たすのに役立つ、事前に作成されたコンプライアンス・レポートとテンプレートのほか、カスタマイズ可能なポリシーとルールも用意されています。 IBM Guardiumがサポートするプラットフォームについては、「 Guardium Data Protection 11.5のサポート対象プラットフォームと要件 」を参照してください。 ソリューション概要 以下の図は、IBM Guardium でモニタリング用に Aurora DAS を構成するための大まかな手順を示しています。 ワークフローには以下のステップが含まれます。 データベースアクティビティストリーミングを有効にする 。 「この構成ではデータベースアクティビティストリーミングを開始できません」というエラーが表示される場合は、「 データベースアクティビティストリーミングでサポートされている DB インスタンスクラス 」をチェックして、DB クラスターがサポートされているインスタンスクラスを使用しているかどうかを確認してください。 Aurora は Amazon Kinesis データストリームを自動的に作成します。 RDS データベースインスタンスの データベースアクティビティストリーミングのステータス は、Amazon RDS コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して取得できます。 IBM Guardium で Kinesis データストリームを設定します。 IBM Guardium は Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するデータコレクターで、RDS インスタンスからデータベースアクティビティをキャプチャします。 IBM Guardium で DAS を設定したら、収集するデータとその処理方法を定義する IBM Guardium ポリシー を設定する準備が整います。 IBM Guardium では、Amazon RDS からキャプチャされたデータを分析して、データベースのアクティビティについてより深い洞察を得ることができます。 IBM Guardium に組み込まれている分析機能を使用して、傾向やパターンを特定し、異常を検出し、レポートを生成できます。 これにより、データベースがどのように使用されているかをよりよく理解し、セキュリティーやコンプライアンスを強化する必要がある分野を特定できます。 また、潜在的なセキュリティ脅威やコンプライアンス違反を通知するアラートや通知を設定することもできます。 IBM Guardiumがセキュリティー上の脅威やコンプライアンス違反を検出すると、アラートや通知をトリガーできます。 問題のあるユーザーや IP アドレスをブロックしたり、セキュリティー・チームに電子メール通知を送信したりして、 これらのアラートに自動的に対応するようにIBM Guardiumを構成 できます。 これにより、潜在的なセキュリティー上の脅威に迅速に対応し、ビジネスへの影響を最小限に抑えることができます。 以下のセクションでは、データベースデータベースアクティビティストリーミングを有効にし、Amazon EC2 で IBM Guardium インスタンスを設定する手順を示します。 前提条件 この投稿は、以下の前提条件を満たしていることを前提としています。 必要なリソースを作成する権限を持つ AWS アカウント。 Amazon EC2 で動作する IBM Guardium のアクティブライセンスまたは試用版ライセンス。 AWS マーケットプレイス から セットアップ された IBM Guardium 。 IAM ロールを作成するための AWS Identity and Access Management (IAM) 権限。 Amazon RDS と Kinesis に関する基本的な知識。 Aurora PostgreSQL DB クラスター。 Aurora PostgreSQL DB クラスターを作成するには、「 Aurora PostgreSQL DB クラスターを作成して接続する 」のステップに従ってください。 データベースアクティビティストリーミングの開始 データベースアクティビティモニタリングを有効にするには、「 データベースアクティビティストリーミングの開始 」の手順に従ってください。 IAM ロールの作成 IAM ロールを使用すると、AWS のサービスにアクセスするための一時的な権限を委任できるため、認証情報が長期間使用されなくなります。 詳細については、「 IAM ロールの作成 」を参照してください。 以下のステップを完了してください。 次の IAM ポリシーを使用してロールを作成します。 a. Guardium-das-policy : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:ListStreams", "cloudwatch:PutMetricData", "cloudwatch:GetMetricStatistics" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kinesis:RegisterStreamConsumer", "kinesis:DescribeStreamConsumer", "kinesis:DescribeStreamSummary", "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:ListStreamConsumers", "kinesis:SubscribeToShard" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Scan", "dynamodb:UpdateItem", "dynamodb:DeleteItem" ], "Resource": "*" } ] } JSON b. assume-role: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "*" } ] } JSON 次の IAM 信頼ポリシーステートメントを追加してください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "AWS":"arn:aws:sts::&lt;&lt;account-id&gt;&gt;:assumed-role/&lt;&lt;iam-rolename&gt;&gt;/&lt;&lt;Guardium-instance-id&gt;&gt;" }, "Action": "sts:AssumeRole" } ] } JSON これらの権限は必要に応じてさらに制限できます。 これで、IBM Guardium EC2 インスタンスにロールをアタッチできるようになりました。 Amazon EC2 コンソールのナビゲーションペインで [インスタンス] を選択します。 Guardium インスタンスを選択します。 「アクション」メニューで「セキュリティ」を選択し、「IAM ロールの変更」を選択します。 Guardium インスタンスにアタッチするために作成した IAM ロールを選択します。 [保存] を選択します。 IBM Guardium でデータ・アクティビティ・ストリームを設定します。 Guardiumのデータ・アクティビティ・ストリームを設定するには、以下の手順を実行します。 IBM Guardium ウェブコンソールにログインします。 「 Discover 」、「 Database Discovery 」、「 Cloud DB Service Protection 」を選択します。 以下の詳細を使用して Cloud DB サービスアカウントを作成します。 [ Name ] には、Cloud DB Service Account と入力します。 [ Provider ] には [ Amazon ] を選択します。 [ Audit type ] には、[ Data Streams ] を選択します。 [ Authentication type ] には [ IAM Instance Profile ] を選択します。 [ Role ARN ] には、作成したロールの ARN を入力します。 [ Create ] を選択します。 ストリームを発見したい各リージョンの行を選択し、「 Discover 」を選択します。 オプションで、フィルターを使用して検索を絞り込むこともできます。 たとえば、「us」という文字を含むデータストリームのみを表示するには、us と入力します。 IBM Guardium はリージョンを検索し、選択したリージョンの新しいストリームをすべて Streams テーブルに追加します。 ストリームを選択し、「 Enable Monitoring 」を選択します。 [Start monitoring stream] で、次の情報を入力します。 [DB Type] では、データベースタイプを選択します (この投稿では Aurora PostgreSQL を選択します)。 [DB DNS endpoint] には、DB DNS エンドポイントを入力します。 DB DNS エンドポイントは Amazon RDS コンソールの [接続とセキュリティ] タブにあります。 Writer インスタンスのエンドポイントを選択する必要があります。 [Port] には、DB DNS エンドポイントのポート (5432 など) を入力します。 [Cluster resource ID] には、ストリームに関連付けられた RDS クラスターのクラスターリソース ID を入力します。 クラスターリソース ID は、Amazon RDS の [設定] タブに [リソース ID] というラベルが付いています。 無効または不明なクラスターリソース ID を入力すると、ストリームのステータスにエラーが報告されます。 [Consumer group Name] には、わかりやすい名前を入力します。 これにより、このデータストリームを複数のコンシューマーが共有または別々に表示できるかが決まります。 コンシューマーグループ名には任意の固有の名前を使用できます。 データストリームビューを共有するには、同じコンシューマーグループ名を使用してください。 「OK」を選択します。 データストリームを有効にして実行したら、 stream テーブルを使用してデータストリームを追跡および管理できます。 ステータスカラーの意味は次のとおりです。 緑 – 正常またはストリーミングが有効で、受信レコードを受信しています。 青 – まだ設定されていません グレー – 使用不可 黄色 – 警告。通常は ConsumerNoInboundRecords というメッセージが表示される 赤 – エラー状態 IBM Guardium のポリシー IBM Guardium で DAS を設定すると、Guardium システムが監視するデータベーストラフィックにリアルタイムで適用されるポリシー、ルール、アクションを設定できます。 ポリシーは、どのトラフィックを無視またはログに記録するか、どのアクティビティがより詳細なロギングを必要とするか、どのアクティビティがアラートをトリガーするか、またはデータベースへのアクセスをブロックするかを定義します。 ポリシーとルールの種類、およびポリシーを作成または変更する方法について詳しくは、「 ポリシー 」を参照してください。 クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。 「 Streams 」テーブルで、「 Disable Monitoring 」を選択します。 Cloud DB Service Account を削除します。 Amazon RDS コンソールで RDS インスタンスに移動し、 データベースアクティビティストリーミングを無効 にします。 RDS インスタンスを 削除 します。 Amazon EC2 コンソールで IBM Guardium EC2 インスタンスを 終了 します。 サマリー Amazon RDS を IBM Guardium と統合することで、データベースインフラストラクチャのセキュリティ、コンプライアンス、データ保護機能が全体的に強化されます。 Guardium の高度なモニタリング、脅威検出、コンプライアンスレポート機能により、Amazon RDS 環境におけるデータを自信を持って管理し、リスクを軽減できます。 この記事では、監視用に Aurora PostgreSQL と互換性のある DAS を IBM Guardium でセットアップする方法と、IBM Guardium でポリシーを定義する方法を学びました。 IBM Guardium のオファリングについて詳しくは、以下を参照してください。 IBM Security Guardium Central Manager IBM Guardium protection options IBM Guardium setup policies IBM Guardium support maintenance この投稿についてご意見がありましたら、コメント欄で送信してください。 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。 著者 Supriya Kanjilal は IBM の AWS セキュリティアーキテクトで、15 年以上の業界経験を持ち、サイバーセキュリティとクラウド移行戦略を専門としています。 現在は IBM と AWS の戦略的パートナーシップに取り組んでいます。 彼の役職は、お客様が AWS クラウドで IBM ソフトウェアソリューションを設計、計画、設計できるよう支援することです。 Rishit G. Barochia は IBM のクラウドソフトウェアアーキテクトです。 彼の経験には、テクニカルアーキテクチャ、クラウド、マイクロサービスアーキテクチャ、ハイブリッドソリューションが含まれます。 IBMとAWSの戦略的パートナーシップに取り組んでいます。 彼の役職は、お客様が AWS クラウドで IBM ソフトウェアソリューションを設計、計画、設計できるよう支援することです。 Sethil Nagaraj はアマゾンウェブサービスのパートナーソリューションアーキテクトで、バージニア州を拠点としています。 彼は顧客の問題に対して創造的なソリューションを提供することを楽しんでいる一方で、クラウドコンピューティングがいかに可能性の技術を促進しているかに魅了されています。

この記事は Create an Apache Hudi-based near-real-time transactional data lake using AWS DMS, Amazon Kinesis, AWS Glue streaming ETL, and data visualization using Amazon QuickSight の翻訳記事です。 テクノロジーの急速な発展に伴い、ますます多くのデータ量が、構造化、半構造化、非構造化など、さまざまな形式で提供されるようになっています。ほぼリアルタイムで業務データをデータ分析することは、一般的なニーズとなりつつあり、データ量の急激な増加により、スケーラビリティとパフォーマンスを向上させるために、リードレプリカをデータレイクに置き換えることが一般的になっています。実際のユースケースの多くでは、リレーショナルデータベースのソースからターゲットにリアルタイムでデータをレプリケートすることが重要です。変更データキャプチャ（CDC）は、ソースデータベースで行われた変更をキャプチャし、他のデータストアに反映するための最も一般的なデザインパターンの1つです。 最近、 AWS Glue 4.0 でのストリーミング抽出、変換、およびロード（ETL）ジョブの サポートを発表 しました。AWS Glueの新バージョンで、AWS内でのデータ統合ワークロードを高速化します。AWS Glue のストリーミング ETL ジョブは、ストリーミングソースから継続的にデータを取得し、インフライトでデータをクリーンアップおよび変換し、数秒で分析に利用できるようにします。お客様のニーズをサポートするため、AWSは幅広いサービスを提供しています。 AWS Database Migration Service （AWS DMS）のようなデータベースレプリケーションサービスは、ソースシステムから Amazon Simple Storage Service （Amazon S3）というデータレイクのストレージ層をとして広く使われているストレージサービスにデータをレプリケートすることができます。リレーショナルデータベース管理システム（RDBMS）に更新を適用するのは簡単ですが、データレイクにこのCDCプロセスを適用するのは困難です。オープンソースのデータ管理フレームワークである Apache Hudi は、インクリメンタルなデータ処理とデータパイプライン開発を簡素化するために使用され、上記の問題を解決するための良い選択肢です。 この投稿では、Amazon Relational Database Service（Amazon RDS）やその他のリレーショナルデータベースから S3 データレイクにニアリアルタイムだけではなく、データの非正規化、変換、エンリッチ可能な柔軟性を持つ CDC の適応方法を紹介します。 ソリューション概要 ソース RDS インスタンスの変更をニアリアルタイムにキャプチャするために AWS DMS を使用し、CDC レプリケーションの宛先として Amazon Kinesis Data Streams を使用します。AWS Glue ストリーミングジョブは Kinesis Data Streams から変更されたレコードを読み込んでエンリッチし、Apache Hudi フォーマットで S3 データレイクにアップサートします。これにより、 Amazon Athena でデータをクエリし、 Amazon QuickSight で可視化することは可能になります。AWS Glue は、Apache Hudi ベースのテーブルにストリーミングデータの継続的な書き込み操作をネイティブにサポートしています。 以下の図は、この投稿で使用されたアーキテクチャを示しています。 AWS CloudFormation テンプレートも提供します。 前提条件 始める前に、以下の前提条件があることを確認してください： AWSアカウント Amazon S3の基本的な理解 ダッシュボードを作成するためのQuickSightの基本的な理解 Amazon RDSデータベース、AWS DMSインスタンスとタスク、Kinesisデータストリーム、S3バケット、AWS Glueジョブ、AWS Glueデータカタログ、およびQuickSightダッシュボードを作成し、Athenaを使用してSQLクエリを実行するための権限を持つ AWS Identity and Access Management（IAM） ロール（ IAMアイデンティティ権限の追加と削除 を参照してください。） ソースデータ概要 今回は ticket_activity テーブルを使用してスポーツイベントのほぼリアルタイムのデータを分析することに興味があるデータアナリスト向けのユースケースを想定します。このテーブルの例を次のスクリーンショットに示します。 Apache Hudi connector for AWS Glue この投稿では、Hudi フレームワークをネイティブサポートしている AWS Glue 4.0 を使用します。Hudi はオープンソースのデータレイクフレームワークで、 Amazon S3 上に構築されたデータレイク におけるインクリメンタルなデータ処理を簡素化します。タイムトラベルクエリ、ACID（原子性、整合性、分離性、永続性）トランザクション、ストリーミングデータ取り込み、CDC、アップサート、および削除などの機能が利用できます。 AWS CloudFormation を用いてリソースセットアップ 迅速なセットアップのために CloudFormation テンプレート が用意しました。ご自身のニーズに合わせて見直してカスタマイズすることができます。 CloudFormation テンプレートは以下のリソースを生成します： RDS データベースインスタンス（ソース） AWS DMS レプリケーションインスタンス、ソーステーブルから Kinesis データストリームにデータをレプリケートするために使用します Kinesis データストリーム 4つの AWS Glue Python シェルジョブ： rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; – Amazon RDS 上に ticket_activity というソーステーブルを 1 つ作成します rds-ingest-data-initial-&lt;CloudFormation Stack name&gt; – Faker ライブラリでサンプルデータがランダムに自動生成され、 ticket_activity テーブルにロードされます rds-ingest-data-incremental-&lt;CloudFormation Stack name&gt; – 新しいチケットアクティビティデータを継続的にソーステーブル ticket_activity に取り込みます。このジョブは顧客のアクティビティをシミュレートします rds-upsert-data-&lt;CloudFormation Stack name&gt; – ソーステーブル ticket_activity に特定のレコードをアップサートします。このジョブは管理者の活動をシミュレートします AWS Identity and Access Management（IAM） のユーザーとポリシー Amazon VPC、パブリックサブネット、2つのプライベートサブネット、インターネットゲートウェイ、NAT ゲートウェイ、ルートテーブル プライベートサブネットは、RDS データベースインスタンスと AWS DMS レプリケーションインスタンスのため作られます NAT ゲートウェイは、AWS Glue の Python シェルジョブから Python 用 MySQL コネクタを使用するために pypi.org への到達性を確保するために使用します。また、Kinesis Data Streams と Amazon S3 API エンドポイントへのアクセスも可能ようにします これらのリソースをセットアップするには、以下の前提条件が必要です： まずは、IAM ロール dms-vpc-role 、 dms-cloudwatch-logs-role 、 dms-access-for-endpoint が必要になります。AWS DMS を使用したことがない場合は、IAM コンソールまたは AWS コマンドラインインターフェイス（AWS CLI） を使用して、これらの特別な IAM ロールを作成する必要があります。手順については、 AWS CLI および AWS DMS API で使用する IAM ロールの作成 を参照してください AWS Lake Formation コンソールの Data Catalog settings ページで、 Use only IAM access control for new databases と Use only IAM access control for new table in new databases の選択を既に解除している場合は、この2つのチェックボックスを再度選択し、設定を保存する必要があります。詳細については、 データレイクのデフォルト設定の変更 を参照してください 以下の図は、プロビジョニングされたリソースのアーキテクチャを示しています。 以下の手順で CloudFormation スタックを起動します： AWS CloudFormation コンソールにサインインします Launch Stack を選択します Next を選択します S3BucketName には、新しいS3バケットの名前を入力します VPCCIDR には、既存のネットワークと競合しない CIDR IP アドレス範囲を入力します PublicSubnetCIDR には、 VPCCIDR に指定した CIDR 内の CIDR IP アドレス範囲を入力します PrivateSubnetACIDR と PrivateSubnetBCIDR には、 VPCCIDR で指定した CIDR 内の CIDR IP アドレス範囲を入力します SubnetAzA および SubnetAzB には、使用するサブネットを選択します DatabaseUserName には、データベースユーザー名を入力します DatabaseUserPassword には、データベース・ユーザーのパスワードを入力します Next を選択します 次のページで、 Next を選択します 最後のページで詳細を確認し、 I acknowledge that AWS CloudFormation may create IAM resources with custom names をチェック入れます Create stack を選択します スタックの作成には約 20 分かかります 初期ソーステーブルの設定 AWS Glueジョブ、 rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; は、RDS データベースインスタンス上に event というソーステーブルを作成します。Amazon RDS で初期ソーステーブルをセットアップするには、以下の手順を実行します： AWS Glue のコンソールで、ナビゲーションペインの Jobs を選択します。 rds-ingest-rds-setup-&lt;CloudFormation Stack name&gt; を選択し、ジョブを開きます。 Run をクリックします Runs タブに移動し、 Run ステータスが SUCCEEDED と表示されるのを待ちます。 This job will only create the one table, ticket_activity , in the MySQL instance (DDL). See the following code: CREATE TABLE ticket_activity ( ticketactivity_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, sport_type VARCHAR(256) NOT NULL, start_date DATETIME NOT NULL, location VARCHAR(256) NOT NULL, seat_level VARCHAR(256) NOT NULL, seat_location VARCHAR(256) NOT NULL, ticket_price INT NOT NULL, customer_name VARCHAR(256) NOT NULL, email_address VARCHAR(256) NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL ) 新しいレコードの取り込み このセクションでは、新しいレコードの取り込み手順を詳しく説明する。以下の手順でジョブを実行します。 AWS DMS を使用した Kinesis Data Streams へのデータ取り込みの開始 Amazon RDS から Kinesis Data Streams へのデータ取り込みを開始するには、以下の手順を実行します： AWS DMS コンソールで、ナビゲーションペインの データベース移行タスク を選択します。 タスク rds-to-kinesis-&lt;CloudFormation Stack name&gt; を選択します。 アクション メニューで、 開始/再開 を選択する。 ステータス が Load complete および Replication ongoing と表示されるまで待ちます。 AWS DMS レプリケーションタスクは、Amazon RDS から Kinesis Data Streams へ継続的にデータを取り込みます。 Amazon S3 へのデータ取り込み 次に、Kinesis Data Streams から Amazon S3 へのデータ取り込みを開始するために、以下の手順を実行します： AWS Glue コンソールで、ナビゲーションペインの Jobs を選択します。 streaming-cdc-kinesis2hudi-&lt;CloudFormation Stack name&gt; を選択してジョブを開きます。 Run を選択します。 Runs タブで実行状況を確認し、 Running と表示されるのを待ちます。 Amazon RDS 上のソーステーブルへのデータロード Amazon RDS 上のソーステーブルへのデータ取り込みを開始するには、以下の手順を実行します： AWS Glue コンソールで、ナビゲーションペインの Jobs を選択します。 rds-ingest-data-initial-&lt;CloudFormation Stack name&gt; を選択して、ジョブを開きます。 Run を選択します。 Runs タブに移動し、 Run ステータス が SUCCEEDED と表示されるのを待ちます。 取り込んだデータの検証 ジョブの開始から約 2 分後、データは Amazon S3 に取り込まれるはずです。Athena に取り込まれたデータを検証するには、以下の手順を実行します： Athena コンソールで、初めて Athena クエリを実行する場合、以下のステップを完了します： 設定 タブで 管理 を選択します。 Athena がクエリ結果を保存するS3 パスを指定します。 保存 を選択します。 Editor タブで、テーブルに対して以下のクエリを実行し、データをチェックします： SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" limit 10; AWS CloudFormation は下記のような実行環境のアカウント ID を名前に入れ込んだデータベースを作成します database_&lt;your-account-number&gt;_hudi_cdc_demo 。 既存のレコードを更新する 既存のレコードを更新する前に、 ticket_activity テーブルからレコードの ticketactivity_id 値をメモしてください。Athena を使って以下の SQL を実行してください。この投稿では、例として ticketactivity_id = 46 を使用します： SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" limit 10; リアルタイムのユースケースをシミュレートするには、RDS データベースインスタンスのソーステーブル ticket_activity のデータを更新し、更新されたレコードが Amazon S3 にレプリケートされることを確認します。次の手順を実行します： AWS Glue のコンソールで、ナビゲーションペインの Jobs を選択します。 rds-ingest-data-incremental-&lt;CloudFormation Stack name&gt; を選択し、ジョブを開きます。 Run を選択します。 Runs タブを選択し、 Run status が SUCCEEDED と表示されるのを待ちます。 ソーステーブルのレコードをアップサートするには、以下の手順を実行します： AWS Glue のコンソールで、ナビゲーションペインの Jobs を選択します。 ジョブ rds-upsert-data-&lt;CloudFormation Stack name&gt; を選択します。 Job details タブの Advanced properties の Job parameters で、以下のパラメータを更新します： Key に –ticketactivity_id を入力します。 Value には 1 を上記で指定したチケット ID の 1 つ（この記事では 46）に置き換えてください。 Save を選択します。 Run を選択し、 Run status が SUCCEEDED と表示されるのを待ちます。 この AWS Glue Python シェルジョブは、チケットを購入する顧客のアクティビティをシミュレートします。ジョブの引数. --ticketactivity_id で渡されたチケット ID を使用して、RDS データベースインスタンスのソーステーブル ticket_activity のレコードを更新します。これは ticket_price=500 と updated_at を現在のタイムスタンプで更新します。 Amazon s3 に取り込まれたデータを検証するために、Athena から同じクエリを実行し、先ほどの ticket_activity の値をチェックし、 ticket_price と updated_at フィールドを観察します。 SELECT * FROM "database_&lt;account_number&gt;_hudi_cdc_demo"."ticket_activity" where ticketactivity_id = 46 ; QuickSight でデータ可視化 AWS Glue ストリーミングジョブによって生成された出力ファイルを S3 バケットに入れたら、QuickSight を使って Hudi データファイルを可視化することができます。QuickSight は、クラウド用に構築されたスケーラブルでサーバーレス、組み込み可能な ML を利用したビジネスインテリジェンス（BI）サービスです。QuickSight を使えば、ML を活用した洞察を含むインタラクティブな BI ダッシュボードを簡単に作成、公開することができます。QuickSight ダッシュボードは、あらゆるデバイスからアクセスでき、アプリケーション、ポータル、ウェブサイトにシームレスに組み込むことができます。 QuickSight ダッシュボードの作成 QuickSight ダッシュボードを構築するには、以下の手順を実行します： QuickSight コンソールを開きます。 QuickSight のウェルカムページが表示されます。QuickSight にサインアップしていない場合は、サインアップ・ウィザードを完了する必要があります。詳細については、 Amazon QuickSight サブスクリプションのサインアップ を参照してください。 サインアップ後、QuickSight は “ようこそウィザード “を表示します。短いチュートリアルを表示することも、閉じることもできます。 QuickSight コンソールでユーザー名を選択し、 QuickSight を管理 を選択します。 セキュリティとアクセス権限 を選択し、 管理 を選択します。 Amazon S3 を選択し、先ほど AWS CloudFormation で作成したバケットを選択します。 Amazon Athena を選択します。 Save を選択します。 QuickSight はリージョンを意識せずご利用いただけますが、後続の操作を行う前に、AWS Glue 等で使用したリージョンに戻してください。 データセットの作成 QuickSight を起動して実行できるようになったので、データセットを作成できます。以下の手順を実行します： QuickSight コンソールのナビゲーションで データセット を選択します。 新規データセット を選択します。 Athena を選択します。 データソース名 には名前を入力します（例：hudi-blog）。 Validate を選択肢します。 検証が成功したら、 Create data source を選択します。 データベース は、 database_&lt;your-account-number&gt;_hudi_cdc_demo を選択します。 テーブル で ticket_activity を選択します。 Select を選択します。 Visualize を選択します 時間、 ticket_activity_id の順に選択すると、時間ごとの ticket_activity_id のカウントを取得できます。 後片付け 料金が発生しないようにこのソリューションを環境内でテスト目的で使用していた場合は、以下の手順で後片付けます： AWS DMS レプリケーションタスク rds-to-kinesis-&lt;CloudFormation Stack name&gt; を停止します。 RDS データベースに移動し、 変更 を選択します。 削除保護を有効にする の選択を解除し、 続行 を選択します。 AWS Glue のストリーミングジョブ streaming-cdc-kinesis2redshift-&lt;CloudFormation Stack name&gt; を停止します。 CloudFormation スタックを削除します。 QuickSight ダッシュボードで、ユーザー名を選択し、 QuickSightを管理 を選択します。 アカウント設定 を選択し、 アカウントの終了 を選択します。 アカウントの終了 を選択して確認します。 確認 を入力し、 アカウントを削除 を選択します。 まとめ この投稿では、Apache Hudi ベースのほぼリアルタイムのトランザクションデータレイクを作成するために、AWS Glue ストリーミングジョブを使用して、新しいレコードだけでなく、リレーショナルデータベースから更新されたレコードも Amazon S3 にストリーミングする方法を示しました。このアプローチによって、Amazon S3 でアップサートのユースケースを簡単に実現できます。また、QuickSight と Athena を使って Apache Hudi のテーブルを可視化する方法も紹介した。次のステップとして、大容量データセット用の Apache Hudi パフォーマンスチューニングガイド を参照してください。QuickSight でのダッシュボードのオーサリングの詳細については、 QuickSightダッシュボード作成体験ワークショップ（日本語） 、 QuickSight オーサーワークショップ（英語） をご覧ください。 翻訳はソリューションアーキテクトの Rui Lee が担当しました。原文は こちら です。

このブログは、Gergely Cserdi と Akshay Parkhi が共同執筆しました。 はじめに SAP は 2027 年までに SAP HANA 以外のデータベースに対する 一般的なサポート を終了するため、近い将来、 SAP HANA は SAP システムの新規導入における唯一の選択可能なデータベースになります。特に多数の HANA インスタンスを運用しているお客様にとって、TCO を削減するためには、一貫性のある自動化された方法でデータベースのパッチを適用することが重要です。 多くの場合、HANA ノード間では HANA System Replication (HSR) が有効になっています。これを Pacemaker クラスタと組み合わせると、お客様のデータベースは HA アーキテクチャを実現できます。このような方法でデータベースをクラスタ化すると、HANA データベースにパッチを適用する nZDT (ほぼゼロのダウンタイム) 方式のメリットを受けることができます。このブログでは、クラスタ化された HANA ノードに nZDT パッチを適用する方法について説明し、Red Hat Enterprise Linux (RHEL) ベースのシステムでプロセス全体を自動化する Ansible プレイブックのサンプルも紹介します。 パッチ適用処理中のほとんどの時間においては、データベースは少なくとも 1 つのノードで使用が可能な状態です。クラスタを使用しない場合のパッチ適用については、SAP ヘルプサイトにかなり詳しく記載されていますが、HANA ノードがクラスタ構成の場合に nZDT パッチを実行する方法に関する情報は限られています。 図 1: ペースメーカーを使用した 2 ノードの HANA クラスタ構成 前提条件: 稼働中の HANA HSR クラスタペア ( AWS Launch Wizard を使えば、数時間で、完全に自動的に SAP HANAのクラスタ構成の構築ができます。詳細に関しては、 AWS Launch Wizard&nbsp; ユーザガイド をご参照ください。) HANA パッチを適用する前に、必要な OS パッチ (ある場合) が適用されていること。詳細については、以下の情報をご確認ください。 OS に関して、BYOS の場合は“Red Hat Enterprise Linux for SAP Solutions”、またはAWS Marketplace の場合は“Red Hat Enterprise Linux for SAP with High Availability and Update Services” が必要です。サポートされている OS については、 OSS ノート 1631106 をご参照ください。また、Red Hat Enterprise Linux for SAP ソリューションサブスクリプションの ナレッジベース を参照することもできます。 root パスワードが必要で、まつ両方のノードで同じパスワードになっていることが必要です。この点に関するサポートが必要な場合は、チームの Linux 管理者に問い合わせてください。 SYSTEMDB と TENANT のために SYSTEM ユーザパスワードが必要です。この点に関しては、チームのデータベース管理者に問い合わせてください。 使用可能な Ansible インフラストラクチャーをお持ちで、HANA ノードでプレイブックを実行するように設定されていること。 必要な HANA のパッチパッケージが S3 バケットにあるか、ファイルシステムに保存されていること。 (オートメーション処理は両方からファイル取得可能) SAP HANA パッチソフトウェアは SAP Marketplace ソフトウェアダウンロードセンター からダウンロードします。(ダウンロードエリアにアクセスするには SAP Marketplace アカウントが必要) パッチファイルが Amazon S3 バケットに保存される場合、Amazon EC2 には、該当のバケットにアクセスできる IAM ロールが付与されていること。 手順 nZDT メソッドで HANA クラスタノードにパッチを適用する一般的なプロセスは以下になります。この例では、ノード 1 が現在プライマリノードで、ノード 2 がセカンダリノードであると仮定します。 * 注意 : 作業順番を守ることは重要です。 クラスタノード 2 をスタンバイモードに設定 スタンバイモードを有効にすると、指定したノードはリソースをホストできなくなります。制約が許せば、そのノードで現在アクティブなリソースがあれば、別のノードに移動されます。この場合、HANA インスタンスはセカンダリ役割であり、現在使用されているクラスタノード 1 はすでにプライマリインスタンスとなっているため、リソースはクラスタノード 1 に移動されません。 クラスタをメンテナンスモードに設定 クラスタ全体をメンテナンスモードにすると、クラスタがクラスタリソースを一切管理しなくなります。HANA のパッチ適用中に HANA サービスが断続的に停止し、そうしなけれ場クラスタが動作する可能性があるため、これは不可欠です。 ノード 2 の HANA パッチ適用 セカンダリノードで HANA にパッチを適用します。このステップは、データベースのソフトウェアバージョンを更新するための中心的な部分です。 図 2: セカンダリノードの HANA パッチ適用 パッチ適用プロセス中、セカンダリノードは一定期間使用できなくなります。ただし、プライマリノードは通常どおり稼働しており、SAP アプリケーションとユーザーにサービスを提供します。 ノード 2 をスタンバイモードから解除 このステップでは、クラスタノード 2 がクラスタで再び使用可能になり、リソースを受け入れられます。 クラスタのメンテナンスモードをオフ メンテナンスモードを無効にすると、クラスタはプライマリノードとセカンダリノードの間の HSR を自動的に再確立します。SAP はセカンダリノードをプライマリノードよりも高いパッチレベルに設定することをサポートしています。セカンダリノードはプライマリノードと同期される状態になります。 レプリケーションが再開され、正常に動作 この段階では、セカンダリノードがプライマリノードと完全に同期し、引き継ぐ準備が整うまで待つ必要があります (ステータス SOK)。 ノード 1 をスタンバイモードに設定 スタンバイモードでは、プライマリクラスタノードはリソースをホストできなくなり、プライマリ HANA の役割がノード 1 からノード 2 に引き継がれます。クラスタは現在のプライマリノードを降格させ、ノード 2 の HANA インスタンスを昇格させます。また、クラスタはオーバーレイ IP をノード 2 に移動し、ルートテーブルの更新を行います。これにより、SAP を引き継いだ後も、ユーザーは引き続き先の HANA データベースに接続できます。 図 3: テイクオーバー処理中にセカンダリノードが昇格 テイクオーバーが完了するまで待機 テイクオーバー処理には少し時間がかかります。ノード 1 にパッチを適用する前に、ノード 2 の HANA インスタンスが完全にプライマリ役割を引き継いでいることを確認する必要があります。 クラスタをメンテナンスモードに設定 クラスタがパッチ適用プロセスの妨げにならないようにするには、クラスタ全体をメンテナンスモードにする必要があります。 ノード 1 の HANA パッチ適用 この段階では、HANA DB はノード 2 でプライマリとして実行されており、SAP システムからの接続とユーザーからの接続を受け入れます。ノード 1 の HANA インスタンスにパッチを適用できるようになりました。 図 4 元のプライマリであったノード1へのパッチ適用し、現在はセカンダリノードがプライマリ役割 ノード 1 をスタンバイステータス解除 ノード 1 のパッチ適用が完了したら、スタンバイ状態から外すことで、クラスタノードとして再び有効にできます。 クラスタのメンテナンスモードをオフ クラスタがメンテナンスモードを終了すると、クラスタノード 1 で HANA インスタンスが起動していることを確認します。現在、クラスタノード 2 の HANA インスタンスにはプライマリ役割があるため、クラスタノード 1 の HANA インスタンスはセカンダリ役割として起動され、ノード 2 からノード 1 へのレプリケーションが開始されます。 図 5: パッチを適用した HANA ノード間で HSR を再確立 クラスタリソースを消去 メンテナンス作業中に、クラスタフレームワークでエラーやアラートが発生することがあります。クラスタを最初からやり直すには、これらをクリーンアップする必要があります。 まとめると、パッチ適用プロセス中は、テイクオーバー発生時に短時間停止する場合を除いて、常に少なくとも 1 つのノードでデータベースが使用可能である必要があります。注:プライマリとセカンダリは、最後に入れ替わります。これは正常であり、データベースの動作には影響しません。都合の良いときに元のトポロジーに 切り戻す ことができます。 プロセス全体を自動化する Ansible プレイブックのサンプルコードは、この 公開 github リポジトリ にあります。 Ansible プレイブックを実行するための準備 ターゲット HANA パッチ SAR ファイルを SAP Marketplace からダウンロードし、S3 バケットまたはサーバーのファイルシステムに配置します。S3 バケットまたはディレクトリに 1 つの SAR パッチファイル以外のファイルが含まれていないことを確認してください。以下は、パッチ HANA SP05 rev64 の SAR ファイルを格納している S3 バケットの例です。 図 6: HANA SAR ファイルを格納する Amazon S3 バケット リポジトリを Ansible コントローラーサーバーにコピー リポジトリをコピーする 1 つの方法は、git clone コマンドを使用することです。git コマンドに関しては参考情報のセクションをご確認ください。そのためには、まず git をインストールする必要があります。Linux への インストール方法 をご覧ください。 コピーしたリポジトリのディレクトリにアクセスし、インベントリファイルを作成し、「SAP_ &lt;SID&gt;_hana_ha」という名前のグループを作り、そのグループに 2 つの HANA ノード IP を追加します。たとえば、HANA SID が「HDB」、HANA ノード 1 の IP が 10.20.30.40、HANA ノード 2 の IP が 10.20.30.50 の場合、インベントリファイルの内容は次のようになります。 [SAP_HDB_hana_ha] 10.20.30.40 10.20.30.50 自動化ツールHANA パッチツール hdblcm を実行するには、複数の認証情報が必要になります。セキュリティ上のベストプラクティスとして、可変ファイルやその他の方法でパスワードを簡単に開示できないようにしてください。Ansible は、機密情報の暗号化に役立つ ansible-vault ツールを提供しています。HANA パッチを適用する Ansible プレイブックソリューションでは、以下の認証情報を含む「passvault.yml」というボールトファイルが必要です。 root ユーザパスワード 変数名: ROOTPWD &lt;sid&gt;adm ユーザパスワード 変数名: SIDADMPWD SYSTEM @ テナントパスワード 変数名: SYSTEMTNTPWD SYSTEM @ SYSTEMDB パスワード 変数名: SYSTEMDBPWD これらの認証情報を「passvault.yml」ファイルに追加すると、変数名や暗号化された値が格納されます。 たとえば、暗号化された root パスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。 ansible-vault encrypt_string ‘theactualpassword’ --name ‘ROOTPWD’ | tee -a passvault.yml 別の例として、SYSTEM DB の SYSTEM ユーザーの暗号化されたパスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。 ansible-vault encrypt_string ‘somepassword’ --name ‘SYSTEMDBPWD’ | tee -a passvault.yml パスワード変数を追加するときは、暗号化に同じボールトパスワードを使用してください。暗号化されたパスワードをすべて追加したら、ファイルの新しい行から始まるようにしてください。必要なパスワードをすべて追加すると、ファイルは次のようになるはずです。 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# cat passvault.yml SYSTEMDBPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 35643964393039616161626666353862653038373434613533313566353134376364643337666539 6436623736323161613031663636356162633362353831620a393365646636653837636633623164 32623365313931303939323532393265613565643965393538393737353436366330636233646330 3265663163636366340a633734306136313839366431616562666162386633353035393764313833 3137 SYSTEMTNTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 39613736376436396361383939313637623435326232656163353863383138633230326166666334 3733653737646431373261313434353065646431343037370a333963643230313565653264643831 36393332386266333438326639346539316330303331393464663539653864353834656665346264 3134306666623765640a303733383031376131613438396436393334636166386233633966396432 3232 ROOTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 30323033336466663837623064343631376634316534316165316438306635636562633164653266 3331663837303932346237643165353062656165356562300a626363373134663635313962303363 37323531633737656239356438613838343665353530313939356530616631623561623733643236 6138653361316265650a386561366330303832346235383035346363633463663035383131623732 3438 SIDADMPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 63633035656533316432353435376433393565623066643735326165313137396633323132363730 3562623132356439613533633536323563333738373931650a623964323966386634616466376631 37386564666337626630333338666264666365616263366531306162636539366461386135663263 3334373437643763380a316238373335653636323564363139376562616130396164613932633938 3361 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# ファイルの設定が完了したら、次の手順に進みます。 プレイブックを実行 ディレクトリをコピーしたリポジトリのルートに切り替え、以下のコマンドを実行します。 ansible-playbook -i &lt;inventoryfile&gt; --ask-vault-pass -e "SID=&lt;SID&gt;" -e "MEDIASRC=&lt;s3/fs&gt;" -e "MEDIALOC=&lt;locationofSARfile" ./patch_sap_hana.yml たとえば、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースが S3 バケット「s3://hanapatch/」にある場合は、次の構文を使用します。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=s3" -e "MEDIALOC=s3://hanapatch/" ./patch_sap_hana.yml 別の例として、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースがファイルシステムから、SAR ファイルが /tmp/hanapatch/ にある場合は、次の構文を使用してください。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=fs" -e "MEDIALOC=/tmp/hanapatch/" ./patch_sap_hana.yml 自動化処理は、前述で説明した順序でノードにパッチを適用します。パッチ適用処理が終了すると、ノードの役割が入れ替われることに注意してください。ノードの元のロールは後でいつでも元に切り戻すことができます。パッチが適用されたことを確認するには、Ansible ログの末尾にある各 HANA ノードの新しいパッチバージョンを確認できます。 クリーンアップ Playbook が正常に実行されると、パスワードテンプレートファイルは自動的にクリーンアップされます。 プレイブックを実行した後も、再び必要になった場合に備えて、ソフトウェアは引き続き使用できます。不要になった場合は、アーカイブするか、単純に削除することをおすすめします。 コスト 2 つの HANA ノードのコスト以外に、自動化には Amazon EC2 インスタンス上で稼働する小さな Ansible 管理ノードが必要な場合があります。 HANA のパッチファイルを保存するために S3 バケットが必要です。一般的なパッチファイルは約 3 ～ 4 GB で、これは年間わずか数ドル (0.023$/GB /月) に相当します。 他の展開 SAP HANA HSR の概念 について詳しくは、SAP 公式ヘルプドキュメントをご覧ください。 HANA HSR に関するよくある質問に対するその他の回答については、 SAP Note 1999880 — FAQ: SAP HANA システムレプリケーションをご覧ください。 RHEL 上の HANA 用 SAP ペースメーカークラスタの詳細については、公式の SAP HANA on AWS ガイド をお読みください。 AWS 無料利用枠サービスを活用して、最小限のコストで SAP on AWS で Ansible を使用する方法を学ぶのに役立ちます。Amazon Linux 2 では AWS 無料利用枠 を使用して EC2 インスタンスを作成できます。このインスタンスは Ansible 管理ノード を実行するのに使用できます。 Ansible モジュールとコーディング技術について詳しくは、ansible の 公式ドキュメント をご覧ください。 結論 この例では、クラスタ化された HANA ノードの nZDT パッチ処理がどのようなものかを説明しました。また、プロセスを自動化する例の方法として、 Ansible プレイブックも提供しました。 図 7:&nbsp; nZDT HANA のパッチ適用プロセス全体の概要ステップ AWS は HANA パッチ適用を自動化するための AWS Systems Manager ドキュメント (SSM ドキュメント) もサポートしていますが、クラスタノードはまだサポートされていないことに注意してください。 SLES ベースのシステムには、考え方は同じです。pcs コマンドをそれぞれ crm コマンドに置き換えるか、YAST モジュールを使用して処理することが可能です。 今後のアクション AWS Launch Wizard for SAP を使用して新しい HANA クラスタ構成を構築してみましょう。まず、 オンラインドキュメント をご確認ください。 無料利用枠の Amazon インスタンスに ansible をインストールし、公開リポジトリからサンプルコードのクローンを作成します。 HANA クラスタノードのロールを確認し、パッチを適用する前に HANA DB のバージョンを確認してください。 インベントリファイルと passvault.yaml ファイルを準備し、パッチ適用プレイブックを起動します。 HANA クラスタノードの役割をもう一度確認し、パッチ適用後に HANA DB のバージョンを確認します。現在、どのノードがプライマリになっているのかでしょうか？ 不要なコストを避けるため、テスト後は必ずリソースをクリーンアップしてください。 リファレンス 公式 SAP ページにある SAP HANA システムレプリケーションによる SAP HANA システムのアップデート Near Zero Downtime Upgrades のために、SAP HANA システムレプリケーションの使用 AWS Launch Wizard YAST モジュールを使用した HANA クラスタの SLES nZDT パッチ適用 Git クローンコマンドの リファレンス 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

AWS Launch Wizard for SAP API による SAP 環境構築の自動化 AWS Launch Wizard は、オンプレミスで数週間から数カ月かかる HANA ベースの SAP アプリケーションの環境構築を、わずか数時間で、安全で高性能、復元力があり、効率的に、AWS に構築するための完全に自動化されたプロセスをお客様に提供します。AWS Launch Wizard for SAP サービスは、 AWS 、SAP、および使う OS のベストプラクティスに従って、SAP アプリケーションと SAP HANA データベースのインストールと設定に必要なすべての AWS リソースをプロビジョニングします。 Nvidia 、 UNOX 、 Storengy などのお客様は、AWS Launch Wizard を利用して SAP 環境の移行を加速させています。 2020 年 4 月のサービス一般提供開始以来、AWS for SAP チームはお客様やパートナー様からのフィードバックに耳を傾け、AWS Launch Wizard サービスを継続的に改善してきました。そのフィードバックに基づいて、SAP アプリケーションソフトウェアの自動構築、構築前/構築後のスクリプトによるカスタマイズされたデプロイ、AWS サービスカタログとの統合など、いくつかの重要な改善を行いました。さらに、Launch Wizard チームは、AWS、SAP、およびオペレーティングシステムの最新機能を活用した新機能を継続的に提供しています。これにより、SAP アプリケーションのあらゆる階層で最新のイノベーションを活用することができ、お客様の投資が将来にわたって保護されます。 お客様から最も要望の多かった機能の 1 つは、AWS Launch Wizard を既存の導入ツールやスクリプトと統合できることです。お客様がアプリケーション・プログラミング・インターフェース・コール（API）を使用して、AWS管理コンソールにログインすることなく、プログラマティックでSAPシステムをデプロイできるようになったことを11月初旬に 発表 しました。 このブログでは、SAP S/4HANA システムをプログラマティックでデプロイが可能にする新しい AWS Launch Wizard API について詳しく説明します。 AWS Launch Wizard API 概要 AWS Launch Wizard API を使用すると、以下のアクションが実行可能となります。 CreateDeployment: 指定された設定でワークロードをデプロイします。 ListDeployments: 作成されたデプロイメントを一覧表示します。 GetDeployment: 特定のデプロイメントに関する詳細情報を取得します。 DeleteDeployment:特定のデプロイメントを削除します。 ListDeploymentEvents:デプロイ中に実行されているすべてのアクションを一覧表示します。 ListWorkloads: AWS Launch Wizard がサポートしている利用可能なすべてのワークロードを一覧表示します。 ListWorkloadDeploymentPatterns: 特定のワークロードのすべてのデプロイパターンを一覧表示します。 GetWorkload: 特定のワークロードに関する詳細情報を取得します。 デプロイメントの仕様 デプロイ仕様は、ニーズに応じてアプリケーションをデプロイするための情報提供に使用します。デプロイ仕様で、Amazon Virtual Private Cloud、サブネット、セキュリティグループなどのインフラストラクチャ関連の仕様や、構築予定の SAP システムの SID、SAP ソフトウェアおよびバージョンなどのアプリケーション仕様を提供します。 こちらのURL に記載されているように、サポートされているデプロイパターン毎に、異なる仕様が必要となります。AWS Launch Wizard API は、SAP HANA データベースと NetWeaver ベースのアプリケーションの以下のデプロイパターンをサポートします。 SAP HANA SAP HANA データベース、は以下のデプロイパターンがサポートされています。 SAP HANA 高可用性構成 SAP HANA マルチノード SAP HANA シングルノード SAP アプリケーション SAP S/4HANA、SAP S/4 Foundations、SAP Solution Manager、SAP BW/4HANA、NetWeaver ABAP や Java などの SAP NetWeaver ベースのアプリケーションでは、以下のデプロイパターンがサポートされています。 高可用性構成 マルチノード/分散構成 シングルノード/セントラル構成 ユースケース AWS Launch Wizard API の発表により、Launch Wizard サービスが、単なるコンソールベースのサービスから強化されます。これらの API によって、SAP アプリケーションをデプロイするために、オペレータや管理者がコンソールを操作する必要がなくなります。最初のテスト/検証作業を行えば、その後人の操作を全く介在せずにデプロイを実現できます。Launch Wizard API を活用できるユースケースをいくつかご紹介します。 SAP のデプロイをさらにスピードアップ: SAPアプリケーションを迅速にプロビジョニングするために、SID、インスタンス番号、サイジングなどのパラメータを微調整できる自動化ルーチンを構築します。 障害復旧プロセスの最適化: 災害復旧のテスト/イベント中に、ベースラインシステムのプロビジョニングに使用できるテンプレートを構築することで、Launch Wizard API を災害復旧計画の一部として活用できます。これらのテンプレートは DR プロセスに一貫性と再現性をもたらし、コンソールを使用して手動でシステムを導入する際に発生する可能なミスを削減します。 一時的または N+1 ランドスケープ設定: AWS Launch Wizard for SAP API を活用して、一時的なプロジェクト環境または永続的な N+1 環境を立ち上げながら、SAP システムのデプロイプロセスを加速できます。 例：AWS Launch Wizard for SAP API を使用した SAP S/4HANA デプロイ この例では、 AWS Command Line Interface (AWS CLI) を使用して AWS Launch Wizard for SAP API を呼出し、ABAP SAP セントラルサービス (ASCS)、プライマリアプリケーションサーバー (PAS)、SAP HANA データベースを含む SAP S/4HANA システムを、単一の EC2 インスタンスに構築します。 前提条件: AWS アカウント AWS CLI をインストールして設定 (この ドキュメント を参照)。最低限必要なバージョンは AWS CLI バージョン2 です。 AWS Launch Wizard for SAP の一般的な条件と IAM 前提条件を設定完了 (この ドキュメント を参照) SAP アプリケーションとデータベースのインストールメディアをダウンロードして準備 (この ドキュメント を参照) ステップ 1: デプロイメント仕様ファイルの準備 AWS Launch Wizard for SAP API は、JSON 形式のファイルを使用して、通常は AWS コンソールから入力されるデプロイに関する設定値を定義します。デプロイパターンに基づいて、SAP アプリケーションを構成するために必要なパラメータリストについては、 SAP デプロイ仕様 を参照してください。 { "KeyPairName": "ExampleKeyPair", "VpcId": "vpc-a1b2c3d4", "AvailabilityZone1PrivateSubnet1Id": "subnet-11111111aaaaaaaaa", "Timezone" :"PST", "EnableEbsVolumeEncryption" :"Yes", "EbsKmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:alias/aws/ebs", "CreateSecurityGroup" :"No", "DatabaseSecurityGroupId" :"sg-1234567890abcdef0", "ApplicationSecurityGroupId" :"sg-021345abcdef6789", "SidAdmUserId" :"7002", "SapSysGroupId" :"5001", "DatabaseSystemId" :"HYD", "SapSid" :"S4K", "ApplicationDataVolumeType" :"gp2", "DatabaseInstanceNumber" :"30", "InstallAwsBackintAgent" :"Yes", "BackintSpecifications": "{\"backintBucketName\":\"launchwizardsoftware\",\"backintBucketFolder\":\"HANABackintBucketFolder\",\"backintBucketRegion\":\"us-east-1\",\"backintKmsKeyArn\":\"arn:aws:kms:us-east-1:111122223333:alias/aws/s3\",\"backintAgentVersion\":\"2.0.2.732\",\"backintContinueOnFailure\":\"No\",\"backintCreateEbsVolume\":\"No\"}", "CentralSystemOperatingSystem" :"SuSE-Linux-15-SP2-For-SAP-HVM", "CentralSystemAmiId" :"ami-1234567890abcdef0", "CentralSystemInstanceType" :"r5.8xlarge", "CentralSystemHostname" :"apis4sin", "SapPassword" :"EXAMPLE-PASSWORD", "DatabaseLogVolumeType" :"io2", "SetupTransportDomainController" :"Yes", "InstallSap" :"Yes", "SapInstallationSpecifications": "{\"parameters\":{\"PRODUCT_ID\":\"saps4hana-2021\",\"HDB_SCHEMA_NAME\":\"SAPABAP1\",\"CI_INSTANCE_NR\":\"22\",\"ASCS_INSTANCE_NR\":\"20\",\"SAPINST_CD_SAPCAR\":\"s3:\/\/launchwizardsoftware\/sapmedia\/sapcar\",\"SAPINST_CD_SWPM\":\"s3:\/\/launchwizardsoftware\/sapmedia\/swpm\/20-sp10\",\"SAPINST_CD_KERNEL\":\"s3:\/\/launchwizardsoftware\/sapmedia\/kernel\/785\",\"SAPINST_CD_LOAD\":\"s3:\/\/launchwizardsoftware\/sapmedia\/exports\/s4h-2021\",\"SAPINST_CD_RDBMS\":\"s3:\/\/launchwizardsoftware\/sapmedia\/database\/hana-20-sp06-rev60\",\"SAPINST_CD_RDBMS_CLIENT\":\"s3:\/\/launchwizardsoftware\/sapmedia\/hana-client\/20-11\"}, \"onFailureBehaviour\": \"CONTINUE\"}", "SnsTopicArn" :"arn:aws:sns:us-east-1:111122223333:InstallStatus", "SaveDeploymentArtifacts" :"Yes", "DeploymentArtifactsS3Uri" :"s3://launchwizardsoftware", "DisableDeploymentRollback" :"Yes", "CentralSystemAutomaticRecovery": "Yes", "DatabaseDataVolumeType": "gp3" } ステップ 2: デプロイメント仕様の検証 デプロイを実行する前に、 create deployment アクションのオプションの dry-run フラグを使用して仕様を検証し、アクションに必要な権限があるかどうかを確認できます。 // Example command values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json デプロイに問題がない場合は、次のメッセージが表示されるはずです。 // Example JSON response { "deploymentId": "Dry run is successful" } ステップ 3: デプロイを実行開始 dry-run フラグでデプロイ仕様を検証した後、—no-dry-run フラグを使用して実際のデプロイメントを開始します。 // Example command with sample values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --no-dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json 以下に示すようにデプロイメント ID を取得し、後でこの ID をを使用してデプロイメントの進行状況を確認することができます。 // Example JSON response { "deploymentId": "72c26320-6d17-4e55-992c-b3ad8d47331d" } ステップ 4 — デプロイメントのステータスを確認 list-deployment-events アクションを使用してイベントを一覧表示し、デプロイメントのステータスを確認できます。 // Example command values aws launchwizard list-deployment-events \ --deployment-id 72c26320-6d17-4e55-992c-b3ad8d47331d \ --region us-east-1 以下のスクリーンショットは、 list-deployments-events API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deploymentEvents": [ { "name": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "description": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "status": "Completed", "statusReason": "Resource limit validation completed successfully", "timestamp": "2023-10-26T12:18:34.721000-04:00“ }, { "name": "Create resource group", "description": "Creates a resource group with all the application resources", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:32.937000-04:00" }, { "name": "Create secret", "description": "Creates a new secret", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:33.392000-04:00" }, { "name": "Creates the infrastructure for the application deployment", "description": "Creates the infrastructure for the application deployment", "status": "IN_PROGRESS", "statusReason": "", "timestamp": "2023-10-26T12:19:52.694000-04:00" } ] } デプロイメントが正常に完了すると、API コマンド list-deployments を使用してデプロイメントのステータスを取得できます。 // Example command values aws launchwizard list-deployments \ --region us-east-1 以下のスクリーンショットは、 list-deployments API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deployments": [ { "name": "S4HanaSingleTest", "id": "a572f36c-5b06-4fb5-932c-61e684ca3159", "workloadName": "SAP", "patternName": "SapNWOnHanaSingle", "workloadVersionName": "2023-10-26-00-00-00", "status": "COMPLETED", "createdAt": "2023-10-26T22:02:39.413000-05:00" } ] } トラブルシューティング AWS Launch Wizard for SAP のトラブルシューティングについては、 AWS Launch Wizard トラブルシューティングガイド を参照してください。 まとめ このブログでは、AWS Launch Wizard for SAP API を使用して、プログラムで SAP システムを AWS にデプロイする方法について学びました。この新機能を使用することにより、AWS Launch Wizard for SAP コンソールにアクセスしたり、デプロイのステップを手動で画面設定したりする必要がなくなります。詳細については、 AWS Launch Wizard の詳細ページ と ドキュメント をご覧ください。 AWS re: Invent 2023 に参加される方は、 ENT312 — Deploy and optimize SAP on AWS with DevOps で、 AWS Launch Wizard APIを使用して、SAP S/4HANA システムの高可用性構成をいかに簡単に構築、スケーリングできるかをご覧ください。このセッションで、AWS for SAP のエキスパートがプロセスのステップを説明し、AWS での SAP システムの稼働に関する質問にお答えします。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

e コマースサイトは、機敏で正確、そして何よりもユーザーフレンドリーであるべきです。しかし、e コマースサイトの検索パフォーマンスの歴史は、顧客と小売業者のどちらも満足させていない現実を物語っています。 Baymard Institute によると、「全 e コマースサイトのうち 61％ が、 ユーザーの検索語句にそぐわない検索結果を表示している」ため、顧客は新しい検索語句を入力するか、古い検索語句を完全に放棄せざるを得ないのです。 Forrester によると、 「商品の検索体験全体に対するイライラによって、 約 68％ という許容できないほどの解約や離脱を引き起こされている」といいます。 Z 世代がより速く（そしてより正確な）検索結果を求める中、e コマース企業は検索をモダナイズしなければならないという重圧を感じていますが、行動に移している企業はほとんどありません。この失敗をそのままにしてしまうと、イノベーションだけでなく、売上においても競合他社に遅れをとるという深刻なリスクを負うことになります。 このブログでは、なぜ小売業者がキーワード検索の品質のために機会損失してしまうのかと、どのようにして Amazon Web Services（ AWS ）が自然言語処理（ NLP ）を用いて、 e コマース企業の収益向上を支援できるのかを述べます。 キーワード検索の課題 すべてのオンライン顧客が買い物中に検索バーを利用するわけではないですが、50％ 近くは利用しています。 Forrester は、2022 年のロードマップレポート ” Must-Have E-Commerce Features ” にて、「小売ウェブサイトユーザーの 43% は、初めてウェブサイトにアクセスした際に、まずは検索バーで検索することから始める」ということです。このことから、検索結果に重点を置くことは、顧客との関係を維持する上でさらに重要になります。しかしながら、検索結果に重点を置くことはそれほど簡単ではありません。なぜなら、ほとんどの検索エンジンは自然言語を理解しないからです。 例えば、あなたが赤いドレスシャツを探しているとしましょう。あなたはお気に入りのウェブサイトを立ち上げ、検索バーに「男性 赤い ドレスシャツ」と入力します。そうすると、検索エンジンはあなたが書き込んだ内容を理解しようとします。しかし、キーワード検索エンジンは、キーワードをそれぞれ個別の用語としてしか理解できないため、必要な情報以外の入力は、ズレた検索結果を導いてしまう可能性があります。赤いドレスシャツの検索結果の代わりに、検索エンジンは 「ドレスシャツ 」ではなく、ドレスやシャツの検索結果を返すかもしれません。これを変えるには、検索エンジンが検索語句を一つの用語として理解する必要があります。言い換えれば、ユーザーの意図を理解する必要があるのです。 キーワード検索によくある課題として、タイプミス、同義語と方言、特徴検索、フィルター検索、コンテキスト検索、テーマ検索があります。 タイプミス： 検索したい単語を誤ってスペルミスしてしまうことです。例えば、「 sweater 」と入力すべきところを 「 sweeter 」と入力することです。 同義語と方言： 地域によって異なる意味を持つ単語を検索することです。例えば、「 sunglasses 」ではなく、「 shades 」と検索してしまい、全く異なる検索結果を得ることがあります。 例：multi-billion-dollar retailer – 「 mens sunglasses 」の代わりに 「 mens shades 」で検索した結果 特徴検索： ユーザーが特定の特徴を持つ商品を検索することです。例えば、「 strap sandal 」と検索した際に、キーワード検索エンジンが理解できるのはキーワードだけで、ユーザーの意図は理解できないので、商品説明にはサンダルとストラップが使用されていても、検索エンジンは検索語句と同一と認識できず、検索結果は 0 件と返します。 フィルター検索： ユーザーが商品の属性で検索することです。例えば、$ 30 未満のイヤリング、青色の靴下、ポリエステルの椅子張りカバーなどと検索します。 例：multi-billion-dollar retailer – 「 Earrings Under 30 」 の検索結果として関連のないアイテムが表示されてしまう コンテキスト検索： ユーザーが特定の商品ではなく、コンテキストに基づいて何かを検索することです。例えば、「すきま風対策」や「寒さ対策」と検索して、どんな商品が結果に出てくるかを確認するような場合です。コンテキスト検索は、小売業者にとって最も困難なものになります。なぜなら、コンテキスト検索では、ユーザーが存在しないキーワードを検索していることが多く、その結果、検索結果が 0 件になったり、関連した検索結果が 0 件になるからです。 テーマ検索： ユーザーがテーマ別のカテゴリーで商品を検索することです。例えば、特定の種類のラグを探している人は、単に 「ラグ」と検索するのではなく、「廊下用ラグ」と検索するかもしれません。 例：multi-billion-dollar retailer – 「 rug 」 の代わりに 「 hallway rug 」 で検索した結果 Baymard Institute は、「ユーザーの観点では、これらの日常的な表現は業界用語と同じように正しいと思っており、大規模テストの参加者のほとんどは、検索結果が悪かったときに別の類義語を試そうとは思わなかった」と述べています。「その代わりに、検索結果が悪かったり、限定的だったりするのは、そのサイトがそのような商品を選んでいるからだと参加者は単に思い込んでいました。」 機会損失を回避しましょう 顧客と小売業者にとって、検索の問題はイライラさせられるものですし、ショッピング体験の全体的な質を低下させています。しかも、小売業者は、この問題から顧客の体験と企業の財務の両面で悪影響を受けます。もし、顧客が探している商品を見つけられなければ、小売業者は多くの収益を失うことになるからです。 数字を見てみましょう。 Econsultancy の調査によると、e コマースの平均コンバージョン率は 2.77% です。しかし、顧客が検索バーを使って探していた商品を見つけると、平均コンバージョン率は 4.63% に上昇します。これは e コマースの平均コンバージョン率のほぼ 2 倍です。 Amazon.com で検索された場合、この数字はさらに上昇します。毎回 Amazon.com で検索し、探していた商品を見つけると、 コンバージョン率は 6 倍に上昇 します。つまり、かつては 2％ だったコンバージョン率が 12％ になります。このパーセンテージを収益に換算すると、e コマース企業にとって財務的に大きな改善です。 e コマース検索の改善を AWS はどのように支援できるのでしょうか？ AWS は、Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service といった人工知能と機械学習（ AI/ML ）サービスを提供しています。これらのサービスを利用することで、e コマース検索を改善することができます。 Amazon Comprehend は、機械学習を使用してテキストの意味、洞察、つながりを見つける自然言語処理サービスです。このサービスにより、あなたの検索エンジンはキーフレーズ、エンティティ、感情をインデックス化し、検索パフォーマンスを向上させることができます。Amazon Comprehend は時間をかけて学習し、ドキュメント、カスタマーサポートチケット、商品レビュー、メール、ソーシャルメディアへの投稿といったテキスト情報から貴重な洞察を発見します。Amazon Comprehend を使用することで、ユーザーは次のことができるようになります： ビジネスの分析とコールセンターの分析： 顧客アンケートから洞察を引き出し、商品を改善します。 商品レビューのインデックス化と検索： キーワードだけでなく、キーフレーズ、エンティティ、感情をインデックス化した検索エンジンを用いることで、コンテキストに焦点を当てます。 Amazon Kendra は、自然言語を理解する ML ベースのインテリジェント検索エンジンです。このインテリジェントなエンタープライズ検索サービスは、組み込みのコネクタを使用して、さまざまなコンテンツリポジトリを横断して検索することができ、機械学習の専門知識がなくても、ユーザーに高い精度の回答を提供します。 Amazon Textract は、スキャンした文書からテキスト、手書き文字、データを手作業なしで自動的かつ正確に抽出でき、すぐに使える ML サービスです。業種を問わず、データを整理し、元のコンテキストを保ち、出力結果のマニュアルレビューを省くために、Amazon Textract を利用できます。 Amazon OpenSearch Service はオープンソースの分散型検索・分析スイートで、インタラクティブなログ分析、ニアリアルタイムのアプリケーション監視、ウェブサイト検索を実行できます。OpenSearch Service を使用すると、ユーザーはアプリケーション、ウェブサイト、データレイクカタログ内で、高速かつパーソナライズされた検索により、関連するデータをすばやく見つけることができます。 結論 何十億ドルもの売上があるにもかかわらず、小売業者は検索パフォーマンスの低さによって収益を失っています。しかし、そのままにしておくのは勿体ありません。Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service といった AWS サービスを利用することで、この問題を解消することができます。これらのサービスにより、小売業者は強力で改善された検索体験を生み出すことができるため、最終的には、収益の減少ではなく、収益の増加に集中することができます。 AWS の AI/ML サービス を利用して小売業の検索パフォーマンスを改善し、収益を増加させる方法をご覧ください。 消費財業界向けの AWS の取り組みについては こちら から詳細をご覧ください。または、 AWS 担当者 にお問い合わせください。 参考リンク Building Blocks for Modern Retail Ecommerce and Media Search with AWS Amazon OpenSearch Service と Amazon Comprehend を使用したテキスト分析 Building an NLU-powered search application with Amazon SageMaker and Amazon Opensearch Service KNN feature 著者について Aditya Pendyala Aditya はニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。クラウドベースのアプリケーションのアーキテクトとして豊富な経験があります。現在、大企業と協業し、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャの構築を支援するとともに、クラウドに関するあらゆることを案内しています。Shippensburg University でコンピューターサイエンスの理学修士号を取得し、 “When you cease to learn, you cease to grow “という言葉を信条としています。 Siddharth Pasumarthy Siddharth はニューヨークを拠点とする AWS のソリューションアーキテクトです。ファッションやアパレル業界の小売企業の顧客と協業し、クラウドへの移行や最先端技術の導入を支援しています。Indian Institute of Technology で建築学の学士号、Kelley School of Business で情報システムの修士号を取得しました。最新のテクノロジーに精通するだけでなく、芸術にも情熱を注いでおり、余暇にはアクリル画の静物画を制作しています。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。

こちらの Blog は、 Accelerate connected vehicle deployment with the Connected Mobility Solution on AWS &nbsp;を翻訳したものです。 AWS は、オートモーティブクラウド開発者ポータル (ACDP) の追加を含む、 Connected Mobility Solution (CMS) の大幅な改善をお知らせできることを嬉しく思います。本改善には、高度な DevOps 機能、Cloud Formation や Cloud Developer Kit ( CDK ) などのデプロイツール、コネクテッド車両プラットフォーム (CVP) の開発と運用監視の改善に役立つ新しいプラグインとメトリックスが含まれます。重要なのは、 OTA やライフサイクル管理など、車両のリモート機能を、堅牢なコントロールプレーンを通じて、より適切に管理できるようになったことです。 CMS 内の ACDP (下図 1 参照: CMS on AWS — ACDP) は、CVP 開発者の包括的なハブとして機能します。これにより、CVP (下記の図 2: AWS 上の CMS — CVP アーキテクチャ) アセットのコラボレーション、デプロイ、運用を効率化できます。ACDP は、CVP に必要なツール、ドキュメント、指標を統合するように設計されているため、開発者は質の高いソリューションの提供に集中できます。これには、インフラストラクチャモジュール、再利用可能なコードコンポーネントのデプロイ、デプロイ可能なコードアセットの管理が含まれます。 ACDP を使用すると、お客様はコネクテッドカーのコンポーネントをよりシンプルで安全な方法で導入できます。たとえば、ACDP は、わかりやすい車両オンボーディング、データの標準化と保存のための統合データプレーン、データの異常や閾値違反に対する警告システムなどの機能を顧客に提供しています。さらに、ユーザーは車両管理ポータルと車両テレメトリーシミュレーターの恩恵を受けることができます。 図 1 : CMS on AWS — ACDP 図 2 : CMS on AWS — CVP アーキテクチャ モジュール式で直感的な CMS は、スケーラビリティと顧客による使いやすさを考慮して設計されています。これは、お客様がコネクテッドモビリティ機能を安全かつ効率的に導入および管理できるように設計されています。自動車メーカー、サプライヤー、モビリティテクノロジープロバイダーは CMS を使用して、コネクテッドビークルのデータに基づいて車両管理や車両のパーソナライズなどのサービスを提供できます。また、CMS は、開発者エクスペリエンスに重点を置いたプラットフォームエンジニアリングアプローチを通じて、コストの最適化、市場投入までの時間の短縮、開発者の作業負荷の軽減など、自動車業界のお客様が直面する主要な課題にも対処します。 業界レポート によると、このような優れた設計のプラットフォームは、最大 25% のコスト削減、40% の生産性向上、市場投入までの時間の 50% 短縮につながります。 注目すべき例としては、 同様のプラットフォーム を実装したトヨタが挙げられます。トヨタは、市場投入までの時間を大幅に短縮し、年間コストを 500 万ドル以上削減しました。 コストと開発時間を抑えながら、消費者の高まるデジタル期待に応えるため、AWS は新しい CMS を導入しました。AWS 自動車および製造部門のソリューションおよび GTM ディレクターである Bill Foyは、「このソリューションにより、お客様は自社またはパートナーのソリューションを革新し、より効率的にデプロイできるようになります」と強調しています。 CMS on AWS が一般公開されました。開始するには、 AWS Connected Mobility Solution をご覧ください。

お客様がコンタクトセンターを管理しているなら、組織が顧客の信頼とロイヤルティを構築する上でエージェントが重要な役割を果たしていることをご存知でしょう。コンタクトセンターに連絡したことがある人なら、エージェントが複雑な意思決定を導き、必要に応じて迅速かつ正確なソリューションを提供することがいかに重要であるかを知っています。これには時間がかかり、正しく行わないとフラストレーションがたまる可能性があります。 Amazon Connect の生成系 AI 機能 本日、 Amazon Connect の既存の人工知能 (AI) 機能に、 Amazon Bedrock を通じて利用できる大規模言語モデル (LLM) を活用した生成系 AI 機能が加わり、コンタクトセンターが顧客にサービスを提供する方法が劇的に変わったことをお知らせします。LLM は、一般に基盤モデル (FM) と呼ばれる膨大な量のデータについて事前にトレーニングされており、テキストを理解、学習、生成し、インタラクティブな会話を行い、質問に回答し、ダイアログやドキュメントを要約し、レコメンデーションを提供することができます。 Amazon Q in Connect: カスタマーサポートを迅速に行うための推奨される回答とアクション 組織は常に変化しています。こうした組織の変化に対応する高いレベルのパフォーマンスを維持するために、コンタクトセンターはエージェントのオンボーディング、トレーニング、コーチングを継続的に行っています。トレーニングやコーチングを受けたとしても、エージェントは顧客に優れたサービスを提供するために、製品ガイドや組織のポリシーなど、さまざまな情報源を検索しなければならないことがよくあります。これにより、顧客の待ち時間が長くなり、顧客満足度が低下し、コンタクトセンターのコストが増加する可能性があります。 Amazon Q in Connect は、生成系 AI を活用したエージェントアシスタントで、以前は Amazon Connect Wisdom として提供されていた機能を備えています。顧客の意図を理解し、関連する情報源を使用して正確な応答とアクションを行い、エージェントが顧客固有のニーズを伝え、解決するためのアクションをすべてリアルタイムで提供します。2024 年 3 月 1 日まで、Amazon Q in Connect を無料でお試しいただけます。この機能は簡単に有効にでき、Amazon Connect コンソールから始めることができます。 Amazon Connect Contact Lens: 生産性向上のためのコンタクト後の要約生成機能 顧客とのやり取りを改善し、詳細を後で参照できるようにするために、コンタクトセンターのマネージャーは、顧客とのやり取りのたびにエージェントが手動で作成するメモを活用しています。これらのメモには、顧客の問題への対処方法、会話の重要な場面、保留中のフォローアップ項目に関する詳細が含まれています。 Amazon Connect Contact Lens では、生成系 AI を活用したコンタクト後の要約作成が行えるようになり、コンタクトセンターのマネージャーがより効率的にモニタリングできるようになり、コンタクトの質とエージェントのパフォーマンスの向上を支援できるようになりました。例えば、要約を使用して顧客へのコミットメントを追跡し、フォローアップアクションが迅速に完了したことを確認できます。顧客とのやり取りの直後に、Contact Lens は会話を簡潔でまとまりのある要約にまとめることができるようになりました。 Amazon Connect の Amazon Lex: アシスト付きスロット解決 Amazon Lex を使用して、以前よりチャットボット、仮想エージェント、対話型音声応答 (IVR) を構築できました。これにより、顧客は人間のエージェントに話しかけることなく予定を立てることができます。例えば、「自分と 2 人の子供の旅行予約を変更する必要がある」というのは、従来のボットでは数値 (旅行予約に何人いるのか?) を把握して解決するのが難しい場合もあるでしょう。 新しいアシスト付きスロット解決機能により、Amazon Lex はユーザーの発話のスロット値を非常に正確に解決できるようになりました (例えば、3 という正しい数値を使って前の質問に回答するなど)。これは、精度を向上させ、より良い顧客体験を提供する LLM の高度な推論機能によって支えられています。より良いセルフサービス体験を構築するのに役立つ生成系 AI を利用した新しい機能など、 Amazon Lex のすべての機能をご覧ください。 Amazon Connect Customer Profiles: 統一された顧客プロファイルをより迅速に作成して、パーソナライズされた顧客体験を実現 顧客はパーソナライズされたカスタマーサービスエクスペリエンスを期待しています。これを実現するために、コンタクトセンターは顧客の好み、購入状況、やり取りを包括的に理解する必要があります。これを実現するために、コンタクトセンターの管理者は、複数のアプリケーションからの顧客データをマージして、統合された顧客プロファイルを作成しています。これらのアプリケーションにはそれぞれ、さまざまなタイプの顧客データがさまざまなデータストアにわたってさまざまな形式で保存されています。これらのさまざまなデータストアからのデータをつなぎ合わせるには、コンタクトセンターの管理者がデータを理解し、それを整理して統合された形式にまとめる方法を考え出す必要があります。これを実現するために、コンタクトセンターの管理者は何週間もかけて一つの顧客プロファイルにまとめています。 本日より、 Amazon Connect Customer Profiles は LLM を使用して、統合された顧客プロファイルの作成に必要な時間を短縮できます。コンタクトセンターの管理者が Amazon Simple Storage Service (Amazon S3) 、Adobe Analytics、Salesforce、ServiceNow、Zendesk などのデータソースを追加すると、Customer Profiles はデータを分析して、データ形式と内容が何を表し、データが顧客プロファイルとどのように関連しているかを理解します。次に、Customer Profiles は、さまざまなソースからのデータを整理して組み合わせて完全で正確なプロファイルにする方法を自動的に決定します。ほんの数ステップで、マネージャーは顧客プロファイルの確認、必要な編集、設定を完了できます。 Amazon Connect のアプリケーション内、ウェブ、動画機能 組織としては、使いやすく便利で優れたカスタマーサービスを提供したいと考えていることでしょう。この記事の前半で、セルフサービスチャットボットと、それがどのように役立つかについて説明しました。顧客は往々にして、チャットボットを超えて、エージェントとの音声会話を行いたいと思うことがあります。 Amazon Connect には、豊富でパーソナライズされたカスタマーエクスペリエンスを提供するのに役立つアプリ内機能、ウェブ機能、ビデオ機能が搭載されています (詳細については、 Amazon Lex の機能を参照 )。フルマネージド型の通信ウィジェットを使用すれば、数行のコードを記述するだけで、これらの機能をウェブアプリケーションやモバイルアプリケーションに実装できます。これにより、顧客はページを離れることなく、ウェブまたはモバイルアプリケーションからサポートを受けることができます。ビデオは、エージェントのみ、顧客のみ、またはエージェントと顧客の両方が有効化できます。 Amazon Connect SMS: 双方向 SMS 機能 ほとんどの人がモバイルデバイスを所有しており、外出先でもテキストベースのサポートを受けられる柔軟性が重宝されています。コンタクトセンターのリーダーはこのことを知っており、これまで、顧客に双方向の SMS を提供するために、接続されていないサードパーティーのソリューションに頼っていました。 Amazon Connect には現在、コンタクトセンターのリーダーがこの柔軟性を提供できるように、双方向の SMS 機能が搭載されています (詳細については、 Amazon Lex の機能 を参照してください)。これにより、コストのかかるサードパーティーソリューションとの統合なしに、顧客満足度を高め、エージェントの生産性を向上させることができます。SMS チャットは、通話やチャットと同じ設定、 Amazon Connect エージェントワークスペース 、分析を使用して有効にできます。 詳細はこちら Amazon Q in Connect 製品ページ Amazon Amazon Connect の開始方法 ユーザーガイド フィードバックを送信する AWS re:Post for Amazon Connect 、または通常の AWS サポート窓口を通じて – Veliswa 原文は こちら です。

AWS は発足から 3 年目を迎えたデジタル庁と、ガバメントクラウドの加速を継続して支援します 急ピッチでデジタル化を進める日本の政府、自治体、企業、スタートアップ 私たちアマゾン ウェブ サービス（以下、AWS）は、クラウドを中核としたデジタル技術には、社会の課題や困難を突破する力が備わっていると考えています。なぜならば、クラウドによって誰もが高度なテクノロジーと、様々なデータを簡単に利用できる社会を構築することができるからです。私達はこれを、テクノロジーとデータの民主化と呼び、AWS はこれらの民主化を通じて、国民・市民　一人ひとりが、デジタルの恩恵を享受できる、社会の実現に貢献するために、地域社会をより豊かに、そして地球と人々の発展を支える信頼性の高いテクノロジーを提供することを目指しています。そして、日本全体のデジタルトランスフォーメーション（以下、DX）を支援するため、日々活動を行っています。この思いは、政府が進めるビジョンである、全国どこでも 誰もが便利で快適に暮らせる 社会を目指す「 デジタル田園都市国家構想 」に一致するものです。 世界における日本のデジタル競争力の強化、最終的に市民・国民のより良い、心豊かな暮らしの実現のために、日本政府は DX をさらに加速しています。2021 年のデジタル庁創設、行政、教育、医療などのデジタル化、デジタル格差の解消、さらにガバメントクラウドの実現など、急ピッチでデジタル化を進めています。デジタル田園都市構想もその一つで、デジタルの力を活用して地域の社会課題の解決を目指し、地域でイノベーションを起こし新たな仕事を生み出すスタートアップ支援を進め、人の流れを作り、結婚・出産・子育てがしやすい環境作りを行うことを目指しています。 ガバメントクラウドの意義はますます大きく デジタル田園都市国家などを実現するデジタル基盤として進められているイニシアティブの中に、ガバメントクラウドがあります。ガバメントクラウドは、クラウドサービスの利点を最大限活用し、迅速、柔軟、セキュア、コスト効率の高いシステムを構築・提供し、最終的には国民、市民へのより良いサービスにつなげるもので、デジタル庁がけん引して進めています。官公庁や自治体のデジタル化施策のベースとなるこのガバメントクラウドに、AWS は 2021 年度から継続して採択され、 2024 年度も引き続き採択されています。ガバメントクラウドに必要な要素を AWS が実現している証左であると大変光栄に思うと同時に、日本政府、官公庁、自治体のインフラとして、引き続きコスト効率の良さを維持しながら、セキュアで、最新技術を利用できるクラウドを提供すべく、引き続き真摯に取り組み続けます。 また AWS は、ガバメントクラウド活用の支援のために、官公庁や自治体職員、および自治体を支援するパートナー向けに、AWS に関する基礎知識を学ぶ トレーニング （ハンズオンを含む）を2022 年 6 月から提供しています。 2023 年 10 月までに、のべ 1,000 人以上の官公庁・自治体職員・パートナーが参加しました。 AWS は公共、教育機関、非営利団体を支援してきた、クラウドベースのソリューションと経験を持つ世界中の AWS パートナーを認定する AWS 公共部門パートナー(PSP) プログラム を提供しており、日本の公共部門のお客様がイノベーションの文化を醸成し、パートナーやスタートアップ、シビックテックのエコシステムを活かして、地域体験を革新するために協働しています。 地方創生・地域活性化、行政の業務改善のための生成系 AI 活用など、自治体との様々な側面での連携を加速 AWS は、全国の自治体や地域行政におけるイノベーションを支援し、より良い社会と市民生活の実現に貢献すべく、様々な自治体、関係団体との連携を図っています。2022 年 9 月に つくば市 と研究開発型スタートアップの成長加速に向けてまた、同年同月に 浜松市 とデジタル・スマートシティ浜松の実現に向けて連携協定を締結しました。2023 年 5 月には 新潟県 と地域産業の活性化に向けた包括的な取り組み、同年 8 月に 北九州市 と地域の特色や強みを活かしながら地域課題を解決するための DX の推進に向けた取り組みを進めています。 例えば、新潟県との連携から、地域の人材育成支援に関して、すでにポジティブな動きが生まれています。AWS の認定トレーニングパートナーである トレノケート株式会社 は AWS と共に、新潟県の地域のリーダーを育てる新しい取り組みである NINNO ACCADEMIA において、AWS のクラスルームトレーニング Developing on AWS を 提供しています 。新潟の地域・社会課題を解決していく人材を育てるために、様々なプログラムを提供し、地域の DX を加速しています。 また、 大阪市 と 2023 年 9 月、行政 DX に向け、生成系 AI の活用に関して連携することで協定を締結。大阪市の行政業務の効率化と、市民サービス向上に向け、生成系AIの利活用の可能性と、利用にあたっての課題解決などについて、共同検証を行っています。 市民生活に直結する公共部門においては、データの確固たる信頼性や透明性が必須となってきます。私たちは、過去 20 年以上にわたり、人工知能（ AI ）や機械学習（ ML ）を誰でもが使うことができるように民主化し、グローバル企業や大規模な公共部門の組織からスタートアップまで、あらゆる規模のお客様が安全に容易に、そして適切なコストで革新的な AI ソリューションを構築できるよう注力しています。 このように AWS は、生成系 AI サービス、ソリューションを含めた最先端、かつ安全に安心して使っていただくテクノロジーや、幅広いサービスを提供しつつ、地域の活性化、市民へのより良いサービスの提供をデジタルを最大限に活用して取り組んでいる自治体と協働し、 DX の加速をサポートしています。 AWS ならではの AI / ML の支援・テクノロジーの民主化　日本の大規模言語モデルの構築支援と選択肢の提供 前日の大阪市の生成系 AI の取り組みの通り、生成系 AI をビジネスや公共部門領域に利用する動きが活発化しています。AWS ではこれまでに&nbsp; Amazon Bedrock 、 Amazon CodeWhisperer 、 Amazon Q &nbsp;などの生成系 AI サービスや&nbsp; AWS Generative AI Accelerator 、 AWS Generative AI Innovation Center &nbsp;といった生成系 AI 開発者支援プログラムを提供してきました。これら、Amazon の 20 年以上にわたる機械学習の経験から生まれたサービス・プログラムを活用することで、お客様は &nbsp;AWS 上で柔軟、セキュア、かつ費用対効果の高い生成系 AI アプリケーションを構築することができます。AWS では Amazon Bedrock や&nbsp; Amazon SageMaker JumpStart &nbsp;で多くの大規模言語モデル ( Large Language Model, LLM ) をお客様に提供しており、お客様の用途に合わせた幅広い選択肢と柔軟性を提供します。また、AWS はお客さまがこの新しいテクノロジーの価値をフルに活かせるように、生成系 AI の専門家からなるチームを設置しており、あらゆる組織が AI を活用できるように支援するという目標を掲げています。 その一環としてアマゾン ウェブ サービス ジャパンは 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の大規模言語モデルの開発を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。詳しくは こちら をご覧ください。 クラウドと AI に対応したスタートアップを含む中堅中小企業（ MSME ）が日本経済を牽引 冒頭、クラウドには社会の課題や困難を突破する力がありますとお伝えしました。それを証明するべく、AWSは、グローバルのコンサルティング企業であるアクセンチュアと共同で、社会課題に取り組む中堅中小企業（MSME: Micro, Small &amp; Medium Enterprises）のクラウドへの移行によってもたらされる日本経済、および社会へのインパクト潜在的効果について検証し、レポート「 日本においてクラウド主導経済が現実に：中堅中小企業（MSME）を通じてクラウドが経済と社会に与えるインパクトとは 」 を発表しました。 同レポートによると、日本経済はクラウドが主導するテクノロジーを採用した MSME によって、2030 年には医療、教育、農業の分野全体で年間総額 1 兆 9,000 億円相当の生産性向上効果、日本の全雇用の 7 ％にあたる 520 万人の雇用を生み出すと予測しています。 医療分野では、クラウド主導の MSME が登場することで、医療機関にアクセス困難で十分なサービスを受けられない地域の課題解消を実現する可能性があるとしています。2030 年には日本でクラウド主導の MSME が医療分野で大きく成長し、年間総額 1 兆 2,000 億円相当の生産性向上効果の創出を促し、6,000 万件のオンライン医療相談をサポートすることになると推計しています。 教育分野では、クラウド主導の MSME がデジタルプラットフォームを通じ、教育へのアクセス性向上とインクルージョン教育に関する課題への対応を支援できる可能性があります。2030 年に MSME が教育分野で年間総額 5,000 億円相当の生産性向上効果を創出し、日本の 400 万人の生徒に e ラーニングソリューションを提供するようになるほか、2030 年までに日本で約 2,000 万人の成人がクラウド主導の MSME を介しオンライン教育にアクセスするようになり、現在の利用者数の 185% 増となると見込んでいます。 農業分野でクラウド主導の MSME が AI やクラウドテクノロジーを通じ、データ主動型の農業生産を導入することで、食糧不足問題を解決する可能性があると期待されています。2030 年には、農業生産に関わる日本の MSME が年間 1,000 億円相当の生産性向上を創出し、3 軒に 1 軒の農業従事者が精密農業ソリューションを利用するようになるだろうと推計しています。これは現在の使用率の 130% 増にあたります。 AWS では、中堅中小企業、スタートアップがイノベーションを支える重要な存在となり、医療、教育のデジタルサービスへのアクセスを改善するなど、社会の課題に対処する上で重要な役割を果たす存在になるだろうと考えています。生成系 AI や高度なクラウドテクノロジーの導入を加速し、経済的・社会的メリットを速やかに可能にするために、AWS は政府、関連機関など各業界と協力し、日本のビジネスがすべての人々にとってより良い未来を築けるよう支援していきます。 社会課題の解決を積極的に取り組む自治体、企業、スタートアップを支援 ビジネス、地域のさらなる活性化実現のために、AWS では「 デジタル社会実現ツアー2023 」を開催しました。昨年初めてオンラインにて開催した「 デジタル社会実現ツアー 2022 」をさらに進化させ、2023 年は 8 月 22 日の高松会場を皮切りに、広島、北九州、大阪、新潟、横浜、名古屋、浜松、仙台、札幌、那覇、福岡、そして全国の自治体、スタートアップなどに集まっていただき、総集編のようなコンテンツとした 10 月 4 日の東京会場と、全国計 13 ヶ所でリアルに開催しました。 「デジタル社会実現ツアー 2023 」のテーマは、「地域創生を“さらに”一歩進めるには？」。政府が進めるデジタル田園都市国家構想によって実現を目指す地域創生や社会課題解決のために、地域交通のリ・デザイン、遠隔医療、こども政策、教育 DX、観光 DX、防災 DX、スマート農林水産業・食品産業など、各領域において、先行して取り組みを始めている先進的な企業やスタートアップおよびそれらと連携している自治体や関係各省庁の皆様を各会場にお招きしました。そこで、「プロジェクトの進め方（資金調達など）」「人材育成」「デジタル技術の活用」といった注目の各トピックについての成功談・失敗談についてお話いただきました。全国各地で開催することで、地域ならではの課題、チャレンジが話し合われました。様々なトピックやテーマについて、多くの様々な参加者の方から情報共有、ディスカッションが行われましたが、AWS を活用しつつ社会課題の解決に尽力している企業様をハイライトとして抜粋してご紹介します。 浜松会場では、「浜松市実証実験サポート事業」に採択されたプロジェクトとして、 株式会社フジヤマ が提案した、浜松市全域の盛土の変化を観測するWebシステムが紹介されました。低コストで利用できる衛星データを活用し、AI 学習を用いた盛土の変化検出手法の検証および Web システム構築を行うことで、市域全体の盛土監視システムの構築を目指すものです。 札幌会場では、 株式会社よびもり が知床（羅臼町と斜里町ウトロ）の海上にて、役場、観光船協議会および漁協とともに実施した、助け合い海難救助サービス「よびもり（ yobimori ）」の実証実験を紹介しました。「よびもり」は、海難事故が発生した場合、最新の位置情報を近くの漁船、観光船などにつないで、救助要請を可能とする仕組みです。 横浜会場では、神奈川県による「要配慮施設利用者の安全を守る避難確保計画の取組化」の実証実験として、 株式会社ネオジャパン の製品である desknet’s NEOとAppSuite にて構築した避難確保計画作成アプリケーションが紹介されました。横浜市の避難確保計画に関するサイトと情報をアプリ上に集約し、災害に対する意識啓発を促進している事例です。 「デジタル社会実現ツアー2023」は、全 13 会場の様子をオンデマンド視聴することができます。詳しくは こちら からご覧ください。 デジタル庁が進めるデジタルマーケットプレイスへの支援 現在、デジタル庁では官公庁や自治体などの行政機関がクラウドソフトウェア（SaaS）を調達する際に、オンライン上でほしいソフトウェアを検索、比較して、調達できるような手法「デジタルマーケットプレイス（DMP）」の開設準備を進めています。 DMP はデジタル庁が運営する調達プラットフォームで、多様なベンダーがサービスを登録し、その中から行政機関が必要なサービスを検索・選定し、簡易的に調達できるようになります。2024 年度下半期の本番サイトオープンにあわせ、国と自治体が調達の際に DMP を利用できるような国の制度整理を進め、会計制度上も利用できるものとする計画です。これに先立ち、2023 年度は α 版というカタログサイトが公開され、事業者が実際に製品を登録し、売り手側、買い手側のニーズや操作性等の確認・調査が行われる予定です。 公共調達の仕組みが大きく簡素化されることと、SaaS というクラウドによる提供形態の製品の紹介の場が作られることにより、これまで公共調達に参加しにくかった中堅中小企業やスタートアップなどにとっては大きなメリットとなります。また、買い手側も DMP というオンライン上で、いつでもどこでも、自分たちのニーズに合った製品を探し出すことができるようになります。 もともとはスタートアップであるアマゾンに出自をもつ AWS は、民間ビジネス領域のみならず、公共部門でのスタートアップの更なる活躍を継続して支援しており、これまでハードルが高かった公共調達に、より参入しやすくなるこの DMP に賛同し、成功を支援します。 例えば前述の、11 月 30 日に事業者向け機能がリリースされた カタログサイトα版 を構築したスタートアップである株式会社dotD（ドットディー）は、 AWSプロフェッショナルサービス によるコンサルティング支援を活用しました。また私たちは、AWS を活用頂いているパートナー向けに、カタログサイト α 版へ製品を登録するためのワークショップや意見交換のための交流会を実施しています。詳しくは こちら をご覧ください。 AWS では、日本の DMP 開設、本格稼働に最大限協力し、企業やスタートアップが公共調達のハードルを乗り越えて、公共部門で社会課題解決のために活躍し、さらに日本の行政サービスの質の向上およびコスト削減に向け貢献されることを全面的に協力し支援していきます。 AWS が考える継続支援への決意 AWS では、デジタル庁が掲げるデジタル田園国家構想を実現するための支援として、ガバメントクラウドに AWS を採用いただくにとどまらず、さらなる活動を継続して行っていくことが重要と考えています。今後、豊かな暮らしを実現していくためには、「経済・社会の発展」、それを実現する要素として「テクノロジーとデータの民主化」、さらに「社会課題の解決」、「付加価値の創造」という循環を作り出していくことが必要です。 しかも、付加価値の創造や社会課題の解決のためには従来の手法では難しい場面が出てくるかもしれません。そこで重要になるのが新しい考え方でテクノロジーを使うような新しい企業が誕生するための「スタートアップへの支援」です。こうして誕生したスタートアップは、「革新的なビジネスモデル」を生み出し、「経済・社会の発展」に寄与すると共に、付加価値の創造や社会課題の解決の一助となっていくでしょう。 日本のデジタル化、それによる市民のより良い暮らしの実現に向けて、AWS は引き続き全方位であらゆるステークホルダーと協力し、支援し、タッグを組み、安全で安心して信頼いただけるクラウドサービスの提供、活動を続けてまいります。 AWS の 2022 年の公共部門における取り組みについては、 こちら をご覧ください。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮

はじめに デジタル環境が急速に変化する今日、企業は効率的な業務運営、コスト削減、クラウドコンピューティングの最適活用を常に模索しています。企業の成長に伴い、Azure や Google Cloud Platform(GCP) から Amazon Web Services(AWS) への移行など、異なるクラウドプロバイダー間での仮想マシン(VM)移行が必要となることが多々あります。 しかし、クラウドへの移行を始めることは、課題や複雑さが多く困難な作業になりかねません。 そこで、 AWS Application Migration Service (AWS MGN) が移行プロセスを簡素化・合理化する強力なツールとして役立ちます。 AWS MGN は、高度に自動化されたリフト&amp;シフトソリューションを提供することで、クラウド移行の簡素化、促進、コスト削減を実現します。 1台のサーバーにつき最大 90 日間、サーバーの数に制限なく無料で移行できます。ほとんどのお客様は、この 90 日以内にサーバーの移行を完了し、AWS Application Migration Service を無料でご利用いただけます。 このブログでは、AWS MGN を使用して Azure 上の仮想マシンを AWS に移行する方法について解説します。 移行をスムーズに成功させるための手順、ベストプラクティス、留意点について説明し、AWS が提供する様々な機能を最適に活用できるよう助言します。 アーキテクチャの概要 AWS MGN は、物理サーバー、仮想マシン、クラウド上のサーバーを、簡単に別の場所に移行できるサービスです。 オンプレミスのデータセンターや別の AWS リージョン、他のクラウドプロバイダー上のサーバーから、AWS にサーバーを移行することができます。 以下のアーキテクチャ図は、AWS MGN を使ってオンプレミスのサーバーを AWS に移行する流れを示しています。 図 1. AWS MGN アーキテクチャ図 ソースサーバにインストールされた軽量なエージェントが、レプリケーションを実行します。この AWS レプリケーションエージェントは、TLS を利用してポート 443 を通じて安全に通信を行い、接続されているすべてのディスクをスキャンして、ターゲットリージョンへブロックレベルでレプリケーションを行います。最初のレプリケーションが完了すると、レプリケーションエージェントはソースサーバへの変更を監視し、その変更点をレプリケートしていきます。これにより、ターゲットリージョンに保存されたデータを最新の状態に保つことができます。 ソースとターゲットが完全に同期し、継続的レプリケーションモードになった後は、テストまたはカットオーバーを開始することができます。 テストまたはカットオーバーが開始されると、AWS MGN は Amazon Elastic Compute Cloud (Amazon EC2) &nbsp; の API を使用してターゲットインスタンスを起動し、新しい Amazon Elastic Block Store (Amazon EBS) &nbsp; ボリュームをアタッチします。 AWS MGNを利用することで、アプリケーションやワークロードの内容に関わらず、オンプレミスのデータセンターや他のクラウドプロバイダーから AWS へ仮想マシンを移行することができます。 ソリューション概要 AWS MGN を利用すると、仮想マシンを Amazon EC2 に移行できます。また、アプリケーションデータの同期も確認できます。 移行に関する手順は以下の通りです。 AWS MGN を利用してレプリケーション環境を構築します。 一時的な認証情報を作成します。 Azure の仮想マシンに AWS MGN エージェントをインストールします。 ソースサーバーの起動設定を行います。 テスト用インスタンスとカットオーバーインスタンスを起動します。 前提条件 Azure での WordPress サイトの作成 まず移行を行うには、 WordPress が構築されている Azure 仮想マシンが必要です。Azure 仮想マシンを作成する手順は以下の通りです。 Azure アカウント上で検索バーに「 WordPress 」と入力し、検索します。 検索に一致した Marketplace で [ WordPress ] オプションを選択します。App Service で WordPress を選択しないでください。選択すると、VM にアクセスできなくなります。 [ 作成 ] を選択します。 リソースグループ名 と 仮想マシン名 を入力します。 管理者アカウント に、 ユーザー名 と キーペア名 を入力します。これは後でインスタンスに接続するときに使用します。 [ 確認および作成 ] を選択します。 新しいキーペアを生成するように求められます。後で仮想マシンにアクセスできるように、プライベートキーをダウンロードするオプションを選択します。 ソースサーバーネットワーク AWS MGN レプリケーションエージェントを WordPress サーバーにインストールする際には、ネットワーク設定を適切に構成し、アクセスを許可する必要があります。手順は以下の通りです。 Azure アカウントで、仮想マシンを検索します。 WordPress ドキュメントの作成時に指定した名前の仮想マシンを選択します。 サイドバーの 設定 の [ネットワーク設定] タブを選択します。 図 2. WordPress を実行しているソースサーバーのネットワーク画面 [ 受信ポート ルール ] を選択します。宛先ポート範囲を 443 に設定し、プロトコルとして TCP を選択します。 DenyAllInbound の優先度よりもこのルールの優先度番号が小さいことを確認してください。 次に、[ ポート ルールの作成 ] – [ 送信ポート ルール ] を選択します。 このメニューで、宛先ポート範囲を 1500 に、プロトコルを TCP に設定します。残りはデフォルトのままにします。 セクション 1: AWS MGN 環境のセットアップ AWS MGN のランディングページで[ 使用を開始 ]をクリックします。このサービスに初めてログインした場合、サービスの初期設定を求められます。 図 3. AWS MGN サービス初期時のプロンプト コンソールの AWS MGN エリアにアクセスするのが初めてではない場合は、サイドバーの [ レプリケーションテンプレート ] に移動し、[ サービスのアクセス許可を再初期化 ] を選択することでアクセス許可を再設定できます。 サービスを初期化すると、 AWS Idenity and Access Management (IAM ) ロールとともにレプリケーションテンプレートが作成されます。テンプレートは、新しく追加されたソースサーバーごとにデータレプリケーションがどのように機能するかを規定します。また IAM ロールはレプリケーションエージェントをインストールするために必要な権限が付与されます。 構成されたレプリケーション設定は、個々のソースサーバーまたはソースサーバーのグループでいつでも変更できます。 レプリケーション設定の詳細 をご覧ください。 セクション 2: 一時的な認証情報の作成 ソースサーバーに AWS MGN エージェントをインストールするには、まず必要な認証情報を作成する必要があります。そのためには、インストール権限を持つ AWS IAM ロールを作成します。このロールを使用して、MGN で利用するための一時的な認証情報を生成します。 コンソールの AWS IAM に移動します。 サイドバーで、[ アクセス管理 ]の[ ロール ]タブを選択します。 右上の [ ロールを作成 ] ボタンを選択します。 図 4. 新しいロールを作成できる AWS IAM ロール画面 信頼されたエンティティタイプについては、[AWS アカウント] を選択し、[次へ] を選択します。 許可ポリシーの検索バーで、[AWSApplicationMigrationAgentInstallationPolicy] を検索し、その横にあるチェックボックスをオンにして選択します。次に、[次へ] を選択します。 ロール名には 「 mgn_install 」 を入力します。次に、下にスクロールして [ ロールを作成 ] を選択します。 ロール検索バーで、先ほど作成した mgn_install ロールを検索し、選択して概要にアクセスします。 概要に表示されている mgn_install の ARN をコピーします。 セッション時間が長く必要と想定される場合は、編集ボタンを選択し、必要に応じてロールの最大セッション時間を長くしてください。 図 5. mgn_install ロールの概要 セクション 3: Azure 仮想マシンに AWS MGN エージェントをインストールする コンソールの AWS MGN に移動します。ソースサーバーを選択し、[ サーバーを追加 ]を選択してエージェントインストーラーのリンクを取得します。 図 6. 新しいソースサーバーを追加できる AWS MGN ソースサーバー画面 [ サーバーを追加 ]を選択すると、AWS レプリケーションエージェントインストールに関する設定画面が表示されます。 図 7. AWS レプリケーションエージェント のインストール画面 ここでは、セクション2で作成した IAM ロールの認証情報(AccessKeyID、SecretAccessKey、および SessionToken)を提供する必要があります。そのため、 AWS Security Token Service (AWS STS) の AssumeRole API を利用して、一時的な認証情報を取得します。一時的な認証情報を取得するには以下の手順を実行します: コンソールページの左下にある CloudShell ボタンを選択して、コマンドラインインターフェイス (CLI) を開きます。 図 8. AWS CloudShell インターフェイス CLI に次のコマンドを挿入します。これにより、AccessKeyID、SecretAccessKey、および SessionToken が出力されます。これらのトークンは、AWS レプリケーションエージェントのインストールページの項目 に利用します。 (図 7 を参照)。 aws sts assume-role —role-arn [mgn_install の ARN] –-role-session-name “mgn-install” 図 9. aws sts assume-role コマンドを実行した後の CloudShell の出力 AccessKeyID、SecretAccessKey、および SessionToken を入力後、図7の項目5と6のコマンドをコピーして Azure 仮想マシン上で実行することで、Azure 仮想マシンにレプリケーションエージェントをインストールすることができます。 Azure 仮想マシンへの Secure Shell (SSH) または Remote Desktop Protocol (RDP) のガイダンスについては、次のドキュメントを参照してください。 https://learn.microsoft.com/en-us/azure/virtual-machines/linux-vm-connect?tabs=Linux 項目 5 のコマンドを正常に実行すると、次のようになります。 図 10. エージェントインストーラが正常にダウンロード完了した場合の出力 同様に、項目6のコマンドを実行すると、次のようになります。 図 11. レプリケーションエージェントを正常にインストール完了した場合の出力 AWS レプリケーションエージェント が正常にインストールされたことを示すプロンプトが表示された後、AWS MGN のソースサーバー一覧にソースサーバーが表示され、初期同期が開始されます。 図 12. MGN のアクティブなソースサーバーリストに表示されるサーバー エージェントのインストール後、ソースサーバに接続されているすべてのディスクが自動的にスキャンされ、検出されたディスク上のデータに対して複製が開始されます。 セクション 4: サーバー起動設定の構成 テストインスタンスとカットオーバーインスタンスを起動する前に、いくつかの設定を構成する必要があります。 設定を行うには、まずソースサーバーを選択します。ここから、図13に示すように、[ 起動設定 ]に移動できます。 [ 起動設定 ]では、[ 一般的な起動設定 ] と [ EC2 起動テンプレート ]の2つがあります。 図 13. ソースサーバーの起動設定 このユースケースでは、[ 一般的な起動設定 ] をデフォルトのままにします。 [ EC2 起動テンプレート ]については、[ ネットワーク設定 ] までスクロールし、[ 高度なネットワーク設定 ] を選択します。 図 14. EC2 起動テンプレート内のネットワーク設定 ここでは、WordPress サーバーが公開されている前提で、[ パブリック IP の自動割り当て ]を有効にする必要があります。次に、[ テンプレートのバージョンを作成 ] を選択して、これを新しいテンプレートバージョンとして保存します。 図 15. 高度なネットワーク設定 テンプレートを構成したら、テンプレートを開いて正しく構成されていることを確認する必要があります。そのためには、テンプレートバージョンを作成した後に表示される成功通知でテンプレート名を選択します。 図 16. 起動テンプレートが正常に作成された後に表示されるメッセージ AWS MGN はデフォルトのバージョンの EC2 起動テンプレートを使用します。新しく作成したテンプレートはデフォルトにはなっていないため、[ アクション ] に移動して [ デフォルトバージョンを設定 ] を選択する必要があります。ドロップダウンから最新のテンプレートバージョンを選択し、「 デフォルトバージョンとして設定 」を選択します。 図 17. デフォルトバージョンを設定するドロップダウンメニュー セクション 5.テストインスタンスとカットオーバーインスタンスの起動 最初にテストインスタンスを起動し、テストインスタンスで問題が無いことを確認した後カットオーバーに進みます。これは、カットオーバーのプロセスを完了する前に、インスタンスで問題が発生しないかどうかを事前に検証するためです。 ソースサーバーの [ 移行ライフサイクル ] 列に [ テストの準備完了 ] と表示され、データレプリケーションステータスが正常となっているを確認します。 次に、ソースサーバーを選択し、[ テストおよびカットオーバー ] から [ テストインスタンスを起動 ] を選択します。 図 18. [テストおよびカットオーバー] から[テストインスタンスを起動] を選択 テストインスタンスの起動に成功すると、[ アラート ]列に [ 起動済み ]と表示されます。サーバーを選択し、[ 移行ダッシュボード ]を表示して確認することもできます。起動ステータスが[ 成功 ]と表示されると、起動したテストインスタンスを EC2 で表示し、パブリック IPv4 アドレスを開くオプションが表示されます。これはカットオーバーインスタンスでも同様に表示されます。 (オプション) 検証に失敗した場合、[ アラート ]列にエラーメッセージが表示されます。再試行する前にサーバーのトラブルシューティングを行えるように、[ 移行ライフサイクル ]を[ テストの準備完了 ]に戻すオプションを選択できます。エラー一覧とトラブルシューティング方法については、 こちら をご覧ください。 テストが成功したら、[ テストおよびカットオーバー ]に移動し、[ カットオーバーの準備完了 ] としてマークできます。次に、[ カットオーバーインスタンスを起動 ] を選択します。テストと同様に、[ アラート ]列に [ 起動済み ] ステータスが表示されれば、カットオーバーが成功したことがわかります。ソースサーバー名を選択して、移行ダッシュボードを表示することもできます。 図 19. [テストおよびカットオーバー] から [カットオーバーインスタンスを起動]を選択 次に、ソースサーバーのリストからソースサーバーを選択し、[ 移行ダッシュボード ]から EC2 へのリンクを選択します。 図 20. 移行ダッシュボードで、起動した EC2 カットオーバーインスタンスに遷移 インスタンス概要から、新しいインスタンスのパブリック IPv4 アドレスを確認し、IPv4 アドレスを使用して WordPress ページにアクセスします。 図 21. カットオーバーインスタンスの EC2 概要とパブリック IPv4 アドレス IPv4 アドレスにアクセスし WordPress ページが機能していれば、カットオーバーは成功しています。移行を完了するには、コンソールで AWS MGN サービスに戻り、ソースサーバー に移動します。 ソースサーバーを選択し、[ テストおよびカットオーバー ]から[ カットオーバーを最終処理 ]を選択します。最終処理が完了すると、ソースサーバーの移行に使用されたリソースがすべてクリーンアップされ、破棄されます。 図 22. [テストおよびカットオーバー]から[カットオーバーを最終処理]を選択 セクション 6: クリーンアップ クリーンアップするには、ソースサーバーを選択し、[ アクション ]から「 アーカイブ済みとしてマーク 」を選択します。 アーカイブ済みとしてマークされたサーバーは AWS MGN コンソールに表示されなくなります。 (オプション)カットオーバーインスタンスを使用する目的でこれを実行した場合は、このステップに従わないでください。ただし、学習としてこのガイドに従った場合は、ターゲットの EC2 インスタンスを削除して、そのインスタンスとそれに関連する EBS ボリュームのコストが発生しないようにする必要があります。これを行うには、EC2 ダッシュボードにアクセスしてインスタンスを表示します。そこからインスタンスを選択し、[ インスタンスの状態 ] から [ インスタンスの終了 ] を選択します。 結論 このブログ記事では、AWS MGN を使用して Azure から AWS へ仮想マシンを移行する際の主な手順について説明しました。 移行をスムーズに行う方法として、AWS MGN の環境設定の方法、Azure の仮想マシンに MGN エージェントをインストールする手順を解説しました。さらに、AWS 側で起動テンプレートを設定する方法もステップバイステップで説明しました。 AWS MGN は、仮想マシンをクラウド間で移行するプロセスを簡略化することを目的としており、互換性の評価、データレプリケーション、カットオーバーなどのタスクを高度に自動化します。 この記事は特に Azure VM から AWS への移行に焦点を当てていますが、MGN はオンプレミス、Azure、GCP、AWS など、異なる環境間での異機種移行もサポートしています。 組織は、アプリケーションポートフォリオと要件を評価し、AWS MGN が自社のクラウド移行戦略とロードマップに適合し、どの部分で活用できるかを判断することができます。 翻訳はソリューションアーキテクト 駒野 達也 が担当しました。原文は こちら です。

はじめに 過去数年にわたり、産業や製造の領域では、 インダストリアル IoT (IIoT) 、人工知能 (AI) 、 機械学習 (ML) の進歩による変革が加速しています。この変革の中心にあるのはデータであり、これを効果的に活用すれば、ビジネスのオペレーション効率、イノベーション、顧客満足度を新たな高みに押し上げることができます。強固な産業データ基盤の構築は、単なる戦略的な活動ではありません。デジタル時代における成功を目指すメーカーや産業界にとって不可欠です。 AWS IoT SiteWise は、産業機器から大規模なデータを簡単に収集、整理、分析できるマネージドサービスであり、顧客がより適切でデータ主導の意思決定を行えるよう支援します。 Volkswagen Group 、 Coca-Cola İçecek 、 Yara International などのお客様は、AWS IoT SiteWise を使用して、工場全体で生成されたオペレーショナルテクノロジー (OT) データをコンテキスト化して分析できる産業用データプラットフォームを構築し、事業とビジネスのグローバルビューを構築しています。さらに、 Embassy of Things (EOT) 、 Tata Consulting Services (TCS)、 Edge2Web 、 TensorIoT 、 Radix Engineering などの AWS パートナーは、予知保全やアセットパフォーマンスモニタリングなどのユースケースを可能にする専用アプリケーションの基盤となっています。お客様やパートナーとのこうした取り組みを通じて、デジタルトランスフォーメーションの取り組みを拡大する上での主な障害は、プロジェクトの複雑さ、インフラストラクチャのコスト、価値実現までの時間にあることがわかりました。 こうした障害に対処するため、AWS IoT SiteWise ではお客様やパートナーが AWS IoT SiteWise に保存されている産業機器データに分析と AI/ML を適用する方法を簡素化する新機能をリリースしました。これらの新機能により、データをクラウドに取り込むコストを最大 70% 削減し、プロジェクトのタイムラインを数か月から数週間に短縮、ビジネスインテリジェンス (BI) ダッシュボードや ML アプリケーションでデータに簡単にアクセスできるようになります。これらの機能強化により、お客様はアセットモデルと階層をより迅速に導入し、取り込みから数分以内に分析ワークフローを実行し、予測メンテナンスのユースケースをより迅速に展開して計画外のダウンタイムを回避できます。今回の新機能により、AWS は、大量の多様な産業データを実用的な洞察に変換し、オペレーション効率を高め意思決定を改善することをより簡単かつ費用対効果の高い方法で実現できるようになりました。 このブログ記事では、AWS IoT SiteWise で最近リリースされた機能の詳細と、AWS のお客様とパートナーがデータ基盤の近代化を促進するためにこれらの機能をどのように使用しているかについて詳しく説明します。 変革のペースを加速する 業務全体の可視性を標準化することは、産業変革の重要な要素です。これは、従来の分断された手動の監視方法からの転換を意味し、コンテキスト化されたデータの統一されたビューに基づいて構築された、統合されたデータ主導型のアプローチが必要です。AWS IoT SiteWise は、このようなデータの標準化とコンテキストをアセットモデルで提供します。モデルはデータを整理し、企業、サイト、エリア、およびマシンレベルでの分析に役立ちます。しかし、産業のオペレーションが複雑であることを考えると、物理資産を正確に表すモデルの構築と維持には時間がかかり、洞察を得るまでの時間が遅れる可能性があります。 新たに追加された API により、AWS IoT SiteWise では、データヒストリアン、他の AWS アカウント、または AWS の独立系ソフトウェアベンダー (ISV) パートナーの場合は独自の産業データモデリングツールなどのさまざまなシステムから、 産業アセットモデルのメタデータを大規模にインポート、エクスポート、更新 ができるようになりました。 図 1: ヒストリアンなどの外部システムから機器メタデータをインポート さらに、AWS IoT SiteWise は、お客様が新しいアセットモデルを作成するために再利用できる アセットモデルコンポーネント とサブコンポーネントの作成をサポートするようになりました。アセットモデルコンポーネントにより、お客様は複雑な機械を企業全体で再利用可能な部品に分割できます。お客様は全社的なコンポーネントライブラリを作成できるため、モデルの標準化が促進され、業務の拡大や複雑化に伴うより効率的なスケーリングが可能になります。下の図は、再利用可能なサーボモーターコンポーネントを使用して複雑な溶接ロボットをモデル化する方法を示しています。新機能により、新しい産業用ユースケースを導入するまでの時間が数か月から数週間に短縮され、さまざまな産業用データソースからのデータを統合ビューにすばやく取り込むことで、価値実現までの時間が短縮されます。 図 2: 再利用可能なコンポーネントモデルを作成してアセットを記述し、データを整理 リアルタイムおよび過去の機器データの統合ビューの作成 AWS IoT SiteWise は、リアルタイムの機器データと過去の機器データの両方を安全に一元管理できるストレージを提供します。エンドユーザーと産業用アプリケーションは、AWS IoT SiteWise に保存されているデータを利用して、貴重な洞察を得てビジネス成果を促進できます。 機器からリアルタイムのデータを収集するために、AWS IoT SiteWise では AWS IoT SiteWise Edge を提供しています。これは AWS によって作成され、オンプレミスにデプロイされ、エッジでの機器の収集、整理、処理、監視を簡単に行えるようにするソフトウェアです。SiteWise Edge を使用すると、お客様は OPC-UA などの産業用プロトコルや標準を使用して機器に安全に接続し、機器からデータを読み取ることができます。AWS パートナーである Domatica 社と協力し、MQTT、Modbus、SIMATIC S7 などの 10 種類の産業用プロトコルのサポートを追加 しました。これにより、機器、機械、レガシーシステムから AWS IoT SiteWise に取り込んで、エッジでの処理や産業用データレイクを強化できるデータの種類が多様化されました。1 秒未満のレイテンシーでデータをクラウドに取り込むことで、お客様は AWS IoT SiteWise を使用して、産業活動全体にわたる何十万ものアセットをほぼリアルタイムで監視できます。 図3: AWS パートナーである Domatica 社の EasyEdge ソフトウェアをを利用することにより新たにサポートされたプロトコルによる機器への接続が可能 ただし、クラウドにおいてすべての機器データがニアリアルタイムで必要なわけではありません。エネルギー、組立製造、プロセス業界のお客様とのプロジェクトを通して、クラウドに送信された機器データのうち、クラウド上のダッシュボードで使用されているニアリアルタイムのデータはわずか10～30％であることがわかりました。残りの 70% ～ 90% は、BI ダッシュボードや機械学習モデルトレーニングなど、クラウド内のデータを数秒ではなく数分以内に必要とする分析アプリケーションで使用されます。そのため、データの取り込みと保存の方法を最適化する必要がありました。 そこで、分析のユースケースに適したコストとパフォーマンスを提供するために、 バッファリングされたデータ取り込みを発表 しました。バッファリングされたデータ取り込みでは、クラウドに取り込まれる前にエッジでバッファリングするデータストリームを顧客が設定できます。これにより、お客様はクラウドへのデータ取り込みコストを最大 70% 削減できます。 コスト効率が高く分析クエリ用に最適化されたストレージ AWS IoT SiteWise には複数のストレージ階層があり、パフォーマンスとコスト効率のバランスを取りながら、さまざまなユースケースを柔軟にサポートできます。ホットストレージ階層は頻繁にアクセスされるデータに最適化されており、インタラクティブダッシュボードなどのリアルタイムアプリケーションでは書き込みから読み取りまでの待ち時間が短くなります。コールドストレージ層は、 Amazon S3 バケットを使用して、稀に使用されるデータを保存します。新機能としてデータをコスト効率よく保存できるように設計された 新しいウォームストレージ階層 を追加しました。ウォームストレージ階層は BI、レポートツール、ML モデルトレーニングなどのアプリケーションで、書き込みから読み取りまでの待ち時間が中程度の大量のデータを取得するのに最適化されています。このウォームストレージ階層により、お客様は大量のデータを、 Amazon S3 に近い 1 GB あたりの価格で保持できます。 ウォームストレージ階層を使用しているお客様は、 新しい Query API も使用できます。Query API を使用すると、お客様は SQL に似たクエリステートメントを使用して、1 回の API リクエストで、アセットモデル、アセット、測定値、メトリクス、変換、集計からメタデータと時系列データを取得できます。この機能は、Amazon QuickSight、PowerBI、Microsoft Excel などのツールと互換性があり、ニアリアルタイムや過去の企業業績のレポートを作成できます。 お客様は、新しい Query API で SQL クエリステートメントを使用してデータを探索し、洞察を抽出できます。次の例は、ユーザーが名前に「Engine」を含むすべてのマシンの RPM 情報をクエリする方法を示しています。 select a.event_timestamp,b.asset_name ,c.property_name , a.quality,a.integer_value from raw_time_series a,asset b , asset_property c where a.event_timestamp &gt; 1698335614 and b.asset_name LIKE ‘Engine%’ and c.property_name = ‘RPM’ event_timestamp asset_name property_name quality integer_value 26-10-2023T15:53:34 Engine001 RPM GOOD 2857 26-10-2023T15:53:34 Engine002 RPM GOOD 2549 26-10-2023T15:63:34 Engine001 RPM GOOD 2753 26-10-2023T15:63:34 Engine002 RPM GOOD 2349 表 1: SQL ステートメントを使用したクエリによるデータ取得 機械学習を使用した予知保全プログラムの推進 複数のお客様が、AWS IoT SiteWise からの産業機器データを Amazon Lookout for Equipment と統合して、予測を行い、機器の異常な動作を検出できる機械学習モデルを作成しています。しかし、サービス間の連携のためにお客様が複数のステップを踏む必要があり、時間のかかるプロセスでした。 AWS IoT SiteWise と Amazon Lookout for Equipment の新しいネイティブ統合 により、連携のための複雑な仕組みの構築やコードを記述したりすることなく、これら 2 つのサービス間でデータを直接同期できるようになりました。これにより、Lookout for Equipment の機械学習モデルを AWS IoT SiteWise から簡単に構築でき、異常検出と予知保全が可能となります。 トヨタ自動車ノースアメリカ (TMNA) は、AWS IoT SiteWise データを使用して Amazon Lookout for Equipment で作成されたモデルを自社の CNC マシンにデプロイしました。サイトあたり200台以上の CNC マシンが年中無休で稼働していたため、TMNA メンテナンスチームにとって予知保全には時間とコストがかかりました。TMNA は、AWS IoT SiteWise を使用して、障害を数日前に予測し、計画外のダウンタイムを削減できる 予測メンテナンス ソリューションを開発しました。導入以来、お客様は数十件の事故や何時間ものダウンタイムを防ぐことができただけでなく、オペレーション可用性を過去 12 か月間の平均で 10% 向上させました。 「当社のフォーカスラインの稼働率は78～ 82% で、毎月約40時間のダウンタイムが発生していました。AWS の支援により、マシンに多くの問題が見つかりました。気付かないままにしておくと、重大な障害につながります。現在、当社の OA は 92% で、ダウンタイムは約20時間です。」— Braden Burford, Sr. Maintenance Engineer, Toyota 機器データのコンテキスト化による強力な洞察 産業の変革は、主に機器、機械、レガシーシステムから得られるデータの可能性を解き放つことに重点を置いています。従来のデータ管理システムでは、効率性、拡張性、革新性に向けた高い要求を満たすにはもはや十分ではありません。これらの機能強化により、AWS IoT SiteWise は、データを資産として活用するためのスケーラブルで統一された統合アプローチを可能にする最新の産業用データ基盤を実現します。コスト効率が高く、安全で再現性のあるフレームワークを提供することで、お客様が産業変革のための強固な基盤を構築し、業務を最適化するのに役立つ産業用データセットへのアクセスを可能にします。 AWS のお客様であるバイオ医薬品の世界的リーダーである Bristol Myers Squibb (BMS) は、AWS IoT SiteWise による産業データ基盤の近代化によって業務変革を実現されたお客様です。生物製剤、製薬、細胞療法の各部門にわたる事業戦略を強化するという目標を掲げており、BMS は従来のデータシステムの見直しの必要性を認識しました。彼らの主な目的は明確でした。1/ 企業全体の可視性を実現すること、2/ エンドツーエンドのトレーサビリティを確立すること。3/ プロセス監視、予測的資産保守、継続的プロセス検証 (CPV) のための検証済みの単一エンタープライズソリューションを実装すること。 BMS は、企業全体の可視性と分析を強化できるデータ管理への統合アプローチを求めて、AWS IoT SiteWise を採用しました。BMS は、Enterprise PI Historian からデータを引き出し、それを AWS 上の統合データレイクに送ることで、データ管理においてかつてないスケール、パフォーマンス、スピードを実現しました。 BMS の重要な進歩の 1 つは、エンタープライズリソースプランニング (ERP) やその他のシステムからの情報とデータを集約することで、データにコンテキストを追加できることでした。これにより、さまざまな場所で製造されている製品バッチのより詳細なサイト分析が可能になりました。 「生物製剤、製薬、細胞療法におけるビジネス戦略の改善を目指すにあたり、可視性とトレーサビリティの強化が不可欠であり、AWS IoT SiteWise は完璧なソリューションでした。AWS を使用してデータ基盤を最新化することで、さまざまなデータソースを統合データハブにシームレスに統合し、効率とスケーラビリティを最適化しました。この変革により、さまざまなシステムからのデータを組み合わせることができ、複数のサイトにわたる製品バッチの洞察に満ちた分析が可能になりました。これにより、アセットのメンテナンスを予測する能力が大幅に強化され、新しい潜在的なユースケースに光が当てられました。これはゲームチェンジャーです。」— Nitin Bhatti, GPS IT, Manufacturing Analytics at Bristol Myers Squibb BMS の変革は、将来のイノベーションの舞台となりました。インフラストラクチャが最新化されたことで、Predictive Asset Maintenance (PAM) や多変量分析など、新たなユースケースを検討できるようになりました。長期的なビジョンには、データの使用と分析を現場の担当者の範囲を超えて拡大し、企業全体の包括的な視野を提供することが含まれます。 AWS パートナーと協力してビジネス成果を実現 デジタルトランスフォーメーションを進めている産業界では、プロジェクトの拡大が難しいことに気付きました。PoC から大規模な企業への本格導入までイニシアチブをとることは、リソースを大量に消費し、専門的なスキルが必要です。AWS パートナーは、業界全体にわたる深い専門知識を持ち、基幹業務のユースケースを解決するソリューションを提供することで長期的な顧客価値を生み出すために必要な推進要因を理解しています。これらのパートナーは、お客様が AWS IoT SiteWise を使用して堅牢なデータ基盤を構築できるよう支援し、そのデータ基盤を使用してお客様の特殊なユースケースの解決を支援します。AWS IoT SiteWise パートナーのいくつかの例を以下に示します。 EOT は Twin Fusion を構築しました。これは、AWS IoT SiteWise を使用して、AWS クラウド内の高度な分析、ML、生成 AI を活用してレガシー IoT データの活用、管理、視覚化、アクションを実現する、Software-as-a-Service (SaaS) 製品です。Twin Fusion は、 産業データファブリック (IDF) に関する AWS ガイダンス の一部です。Twin Fusion は、マシンや時系列データからの IIoT データやセマンティックデータを AWS IoT SiteWise に取り込むためのエンドツーエンドのソリューションを提供します。Twin Fusionは、複数の産業用データソースからのメタデータを統合する企業全体のデジタルツイングラフアセットモデルを提供します。この製品は、エンドユーザーデータ分析、アセット階層検索、埋め込みMLモデル、およびAIによる産業資産の企業全体の最適化のためのオペレーションダッシュボードを提供します。 TCS は、時系列データを AWS サービスでモダナイズするパートナーであり、エッジと AWS クラウドに AWS IoT SiteWise をデプロイすることで、顧客の価値実現までの時間を短縮しています。TCS は、お客様が複数の時系列データを単一のエンタープライズクラウドヒストリアンに取り込み、データのサイロ化を解消して、機器のダウンタイムの最適化、サイクルタイムの改善、一貫した生産性、不良率の低下、環境コンプライアンスなどの産業上の課題を解決できるよう支援します。 Edge2Web は、ノーコードおよびローコードの産業用アプリケーションの オープンプラットフォーム の基盤として AWS IoT SiteWise を使用しています。Edge2Web アプリケーションは、お客様が資産をより適切に管理し、機械のダウンタイムを削減し、製品品質を向上させ、生産パフォーマンスを最適化するのに役立ちます。 TensorIoT は、AWS IoT SiteWise 上に構築された SmartInsights ソリューションを開発しました。SmartInsights は、「起こったこと」と「これから起こること」を1つの画面で確実に視覚化します。SmartInsights を使用すると、お客様は予知保全、リモートアセット監視、再生可能資産の性能予測と保守などのユースケースを解決できます。 Radix Engineering は、産業界のお客様がエッジに保存されている時系列データを活用し、AWS IoT SiteWise を使用して従来の産業オペレーション技術 (OT) アーキテクチャを最新化できるよう支援すると同時に、統合された機械学習 (ML) モデルと洞察により運用と信頼性の向上を促進することに重点を置いています。 これらのパートナーソリューションはそれぞれ、特定の産業上の課題に対処するだけでなく、長期的なビジネス価値と効率性を実現するためにデジタルトランスフォーメーションの取り組みを成功させる上で、専門知識と AWS IoT SiteWise などの高度なツールが果たす重要な役割を示しています。 変革の青写真 トヨタ自動車北米と Bristol Myers Squibb の成功事例は、他の企業の青写真として役立っています。これらのリーダーをはじめとする多くの企業が、スケーラブルで再現性のある産業データ基盤を提供するサービスとして AWS IoT SiteWise を採用し、それを日常業務に統合し、過去およびリアルタイムの機器データの力を活用してデジタルトランスフォーメーションの価値を実現しています。 AWS IoT SiteWise を開始するには、 ここをクリック してください。 re:Invent 2023 に参加する場合は、以下のセッションに参加して、これらの新機能を深く掘り下げてください。 IOT206 | Accelerating industrial transformation with IoT on AWS IOT215 | Accelerate shop floor digitization with edge-to-cloud data integration IOT212 | Modernizing your data historian with AWS IoT SiteWise IOT203 | Automated anomaly detection for smart manufacturing この記事は Sophie Pagalda、Sharon Allpress、Jan Borch、David Castro によって書かれた The Blueprint for Industrial Transformation: Building a Strong Data Foundation with AWS IoT SiteWise の日本語訳です。この記事は Solutions Architect の西亀真之が翻訳しました。

はじめに モノのインターネット ( IoT ) ワークロードを導入しようとする場合、企業はプラットフォームを複数の選択肢から選択することになります。この選択肢はさまざまで、独自デバイスのハードウェアを含めて完全にゼロから構築する方法や、事前に設定されたハードウェアを購入して、完全な SaaS (Software as a Service) IoT プラットフォームに接続するような方法があります。 このブログの目的は、IoT ソリューションの設計に必要なスキルや知識を理解し、どのコンポーネントを自前で開発して、どのコンポーネントを外部の技術ソリューションとして買ってくるのかを判断できるようにすることです。IoT ワークロードを AWS に移行しようと考えている場合は、 「&nbsp; AWS IoT Core へのシームレスな移行を計画する &nbsp;」&nbsp;をご参照ください。 AWS を利用することによる、移行プロセスの簡略化、提供可能なサポート、得られるメリットなどを理解するための最初のステップとして役立ちます。 一般的な AWS IoT アーキテクチャのコンポーネント デバイスの製造 ハードウェアの設計と製造では、考慮すべき要素がいくつかあります。 要件に基づき、ソリューションの現在および将来のニーズを満たすためにハードウェアを選択する必要があります。 IoT の一般的な制約、つまり電力(供給と消費)、接続性、セキュリティ、オペレーティングシステムの管理に関する意思決定が必要です。 ハードウェアを社内で製造していない場合、オリジナルデバイスメーカー ( ODM ) を選択する必要があります。ODM には、大量のデバイスを生産するための製造ライン、ツール、プロセスが揃っています。 通常、プリント基板 ( PCB ) の回路図、部品表、ファームウェア、プロビジョニング要件など、提供する仕様に基づいて製造できます。 デバイスのハードウェア制約を考慮する項目 : 消費電力 : デバイスの使用方法と場所は、電源供給に大きな影響を与えます。ウェアラブルデバイスは小さなバッテリーで動作しますが、テレビは AC 電源を必要とします。バッテリーを必要とするデバイスの場合、バッテリーが再充電可能か交換可能か、ハードウェアの寿命まで利用可能かを判断する必要があります。 オペレーティングシステムとファームウェア : オペレーティングシステムやファームウェアの選択は、デバイスの種類と期待されるタスクによって異なります。小型で低消費電力のデバイスは FreeRTOS などの リアルタイムオペレーティングシステム が必要かもしれませんし、大型で専用の電源を必要とするデバイスは Linux などのフルスタックオペレーティングシステムが必要になる場合もあります。 接続性 : IoT ソリューションには、 イーサネット 、 Wi-Fi 、 セルラー 、 LoRaWAN 、 Bluetooth Low Energy ( BLE ) など、多くの接続性とプロトコルのオプションがあります。デバイスの設置場所、可用性、消費電力、セキュリティ、ユースケースによって、ソリューションに最適な接続オプションが決まります。 AWS ではこのコンポーネントを支援するために、 AWS デバイス認定プログラム &nbsp;を完了した AWS パートナー製デバイスのリストである AWS Partner Device Catalog &nbsp;を提供しています。 このリストにあるデバイスは、AWS IoTとAWSのベストプラクティスとの互換性を確保し、市場への投入を高速化するのに役立ちます。さらに、自社製造のデバイスをお持ちの場合は、 AWS IoT Core Device Advisor &nbsp;を使用して、AWS IoT Core と確実かつ安全に接続できることを検証できます。 デバイスのプロビジョニング IoT ソリューションにおけるデバイスのプロビジョニング方法は、デバイスの機能とその製造プロセスによって異なります。ここでの主な焦点は、デバイスとその認証情報の作成方法にあります。 セキュリティは、あなた、エンドユーザ、デバイス製造業者にとって最優先事項であるべきです。X.509 証明書を使用する場合、製造プロセスで、デバイスが一意となる証明書と秘密鍵のペアを取得するタイミングと、IoT ソリューションにどのように登録するかを明確にする必要があります。 デバイスプロビジョニングと証明書管理を検討する際のポイント : メーカーの選択 : 信頼できる証明書チェーンは、ハードウェアを社内開発または OEM パートナーを選択することから始まります。後者の場合、サプライチェーン全体で証明書の整合性が維持されていることを確認するために、そのプロセスを検査する必要があります。&nbsp; 認証局 ( CA ) : デバイスの製造に柔軟性を持たせるために、AWS では独自の CA、サードパーティの CA、 Amazon ルート認証局 ( CA ) &nbsp;など、複数の選択肢を用意しています。&nbsp; ハードウェアセキュリティモジュール&nbsp; : IoT デバイスに組み込まれたセキュアエレメントは、デバイスセキュリティの基盤を形成します。これにより、証明書やシークレットの暗号化と改ざん防止の保存、ファームウェアとアプリケーションの検証が可能になります。これを支援するために、AWS には&nbsp; AWS IoT ExpressLink を搭載したさまざまな接続モジュールがあります。これらのモジュールには AWS が要求するセキュリティ要件を実装したソフトウェアが含まれています。 外部リソース : カスタムプロビジョニングプロセスを可能にするために、IoTソリューション内でのリソース作成が必要になる場合があります。 これらのリソースは、デバイスの稼働台数が増加するにつれてスケールするように設計する必要があります。 AWS の場合、これは&nbsp; Pre-provisioning hook &nbsp;として機能する&nbsp; AWS Lambda function になる可能性があります。 デバイスレベルのロジック : デバイスには、確実かつ安全にプロビジョニングされるため、オンデバイスのロジックが必要になる場合があります。 AWS では、 AWS IoT SDKs &nbsp;はこのオンデバイスのロジックを可能にするために設計されています。 AWS IoT Core を使用したデバイスのセキュアなプロビジョニングと登録の詳細については、 AWS IoT Core Device Provisioning &nbsp;や AWS ホワイトペーパーの&nbsp; Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core &nbsp;をご参照ください。 デバイス管理 成熟したプロビジョニングのプロセスがあれば、デバイスは最初に接続したときからセキュアで最新の状態に保たれますが、ファームウェアや証明書のローテーションなどの更新が必要になる場合があります。完全にコンプライアンスを遵守し、最高のユーザーエクスペリエンスを提供するためにはこうした更新が必要です。これらの更新のためのソリューションは、配信の中断、接続性、ロールバックルーチン、自動スケーリングへの対応が必要となるでしょう。 デバイス管理戦略を検討する際の考慮事項 : デバイス整理 : デバイスをすばやく識別し操作できることで、コンプライアンスから外れた場合のトラブルシューティングと隔離が可能になります。多数のデバイスを運用する場合、デバイスの整理、インデックス作成、分類を行うソリューションが必要になります。AWS では、 Fleet Hub for AWS IoT Device Management &nbsp;を使用できます。 デバイス監視 : デバイス群のステータスを監視できることは、誤動作やコンプライアンス違反のデバイスを特定するのに重要です。デバイスのメトリクス、ログ、設定などの観測データとセキュリティデータを収集する監視ソリューションを用意してください。 AWS IoT Device Defender は、稼働している多数のデバイスのセキュリティのための監査と継続的なインテリジェントな監視を提供します。 イベントへ対応 : ログ、メトリクス、アラームの最小セットを定義することで、運用チームは大きなビジネスの中断を防ぐことができます。監視ソリューションと統合できるスケーラブルなアラートソリューションが必要です。AWS では&nbsp; Amazon CloudWatch &nbsp;を使用できます。 Over-The-Air ( OTA ) アップデート対応 &nbsp;: デバイスは更新を受信して適用できるように設計する必要があります。IoT ソリューションは更新を送信し、デバイスの更新進捗を監視できる必要があります。AWS では、 AWS IoT Device Management Jobs &nbsp;を使用できます。 このコンポーネントを支援するために、 AWS IoT Device Management 、 AWS IoT Device Defender 、 AWS IoT Core &nbsp;は、稼働している IoT デバイス全体のデバイス整理、監視、アラート、OTA 更新のための完全な機能セットを提供します。 デバイスデータの取り込み すべての IoT ソリューションがデータ取り込みに焦点を当てるわけではありませんが、そうしたソリューションでは、このデータ取り込みがプライマリなコンポーネントとなり、ソリューションの全体的なアーキテクチャに影響します。このコンポーネントに対する要件は、ソリューションのスケール、コスト、セキュリティ、パフォーマンスに影響するため、現在と将来のデータ取り込みを考慮した IoT ソリューションのアーキテクチャを設計する必要があります。 データ取り込み戦略を検討する際の考慮事項 : データサイズ : デバイスがハードウェア的に制約されていない場合、効率を高めるためにメッセージサイズを一定に 保ち、小さいメッセージをバッチ処理することを検討してください。バッチ処理は、メッセージ送信時だけでなく、IoT Core に取り込んだ後に IoT ルールを使用して実行できる ことに留意してください。 データの頻度と構造 : デバイスがメッセージを送信する頻度を考慮し、ソリューションがそのスケールに対応できるように設計してください。頻度に加えて、データの構造がメッセージベースかストリーミングベースの IoT ワークロードかを決定します。 MQTT トピック設計 : このプロトコルを使用する場合は、最小限の権限コミュニケーションを実施しつつ、将来のデバイス導入をサポートできるスキーマのバランスをとる必要があります。適切なトピックスキーマは 、柔軟なメッセージフィルタリングとメッセージルーティングを可能にする共通の命名規則を実装します。 データストレージ : メッセージのフローと使用法を分析し、適切なストレージソリューションを特定してください。これらのストレージソリューションは、ユースケース、全体的なメッセージ構造、スケール ( 現在と将来の成長 ) 、コストなど、複数の考慮事項があります。&nbsp; ルーティング : 取り込んだ後、メッセージをストレージや他のサービスにルーティングするための、ルールベースの簡単なソリューションが必要です。これらのルールは、さらなるメッセージのバッチ処理、処理、アラートなどに使用できます。&nbsp; エッジゲートウェイ : 一般的なアーキテク チャパターンは、データを取り込み、処理、バッチ処理してから IoT ソリューションに送信するゲートウェイまたはブローカーを用意することです。これは、デバイスに近いローカルエンドポイント、または IoT ソリューションに近いクラウドベースのゲートウェイとして実装できます。 このコンポーネントの支援として、AWS IoT Core を使用すると、インフラを管理することなく、 数十億ものIoTデバイスを接続 し、 Amazon SQS &nbsp;、 Amazon Kinesis 、 Amazon SNS などの他の AWS サービスに 何兆ものメッセージをルーティング できます。AWS には、エッジランタイムを提供するオープンソースの&nbsp; AWS IoT Greengrass &nbsp;もあります。AWS IoT Core を使用したデータ取り込みのパターンの詳細は、AWS IoT ブログの「 IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 」をご参照ください。 リアルタイムのビデオとデータストリーム 前のセクションで説明したものに加えて、IoT ワークロードがビデオやその他の高容量データストリームで構成されている場合は、さらにいくつかの点を考慮する必要があります。データストリームを扱う IoT ワークロードは、ビデオ処理や分析などのアプリケーション向けに、高頻度かつ非構造化の生データを扱うことが多くなります。 ストリーミングベースのワークロードを考慮するポイント :&nbsp; プロデューサ側 : データストリームがどのように生成されるかは、IoT ソリューションの下流でどのようにインジェスト、処理、保存されるかに直接影響します。 デバイスのストリーミングプロトコル、ネットワークの可用性、アクセシビリティ 、コストの制約などの側面が、ストリームの生成方法に影響します。&nbsp; コンシューマ側 : データストリームの消費と処理は、IoT ソリューションの必要なスケールと全体的なコストに影響を与える可能性があります。ビデオストリームなどの高頻度データは、高可用性で管理が容易で、スループット要件を処理できる堅牢なアーキテクチャーが必要になります。 これらのストリームの直接的なビジネス価値を総合的な IoT ソリューションで考慮して、最もコスト効果的かつスケーラブルな方法で消費および処理することを決定してください。&nbsp; このようなアーキテクチャを支援するために、AWS には AWS IoT Greengrass 、Amazon Kinesis 、 Amazon Kinesis Video Streams があります。 AWS IoT Greengrass は、エッジでデータストリームを 容易に消費および処理し、 AWS 提供のコンポーネント を介して AWS に転送できるエッジランタイムを提供するオープンソースです。 Amazon Kinesis は、 デバイスから直接 、AWS IoT Greengrass Stream manager コンポーネント から、または AWS IoT ルール から生成されるストリーミングデータをコスト効果的に処理および分析できるマネージドサービスです。 Amazon Kinesis Video Streamsは、デバイスから直接、または AWS IoT Greengrass の Edge connector for Kinesis Video Streams &nbsp;を介して生成されたビデオストリームを、ソースプロトコルに関係なく安全に表示、処理、分析できるマネージド AWS サービスです。 デバイスのコマンド・アンド・コントロール コマンド・アンド・コントロールは、デバイスにアクションの実行を要求するメッセージを送信し、成功または失敗の確認応答を受け取る操作です。これは、デバイスへのコマンドメッセージまたは IoT ソリューションからデバイスの状態を変更して伝達することで実現できます。データ取り込みとコマンド・アンド・コントロールのための IoT ソリューションのメッセージングニーズを評価および最適化することで、パフォーマンスとコストのバランスが最適になります。 デバイスのコマンド・アンド・コントロール戦略についての検討パターン : コマンドメッセージング : 選択したメッセージングプロトコルを使用して、コマンドを直接デバイスに送信します。デバイス側のロジックを実装して、コマンドの受信、実行、デバイスの実行ステータスの報告をする必要があります。このパターンでは、IoT ソリューションでコマンドメッセージを確実に配信する必要があり、デバイスがオフラインになったり接続が切断された場合には、対処可能な障害が発生することに留意してください。 デバイスの状態 : デバイスの状態は IoT ソリューションで処理し、コマンドの設定や実行ステータスの更新に使用できます。この状態は、IoT ソリューションからの変更があった際にデバイスへ送信され、デバイス自身が変更を加えた場合にもそれを送り返すことができる、単純なドキュメントとすることができます。このパターンでは、デバイスが接続されていなくても、IoT ソリューションと対話できます。 このコンポーネントを支援するために、AWS IoT Core は&nbsp; AWS IoT Device Shadow service 　、 MQTT5 リクエスト/レスポンスパターン 、AWS IoT デバイス管理は AWS IoT Job 機能 を提供しています。デバイスのコマンド・アンド・コントロールの実装パターンの詳細は、「 AWS IoT Lens for the AWS Well-Architected Framework 」の デバイスコマンド の項を参照してください。 クラウドアーキテクチャ IoT ソリューションがクラウドに存在する場合、地域を限定した1つのサービスや小規模なデバイス群から始めることができます。これは概念実証やデモンストレーションには十分ですが、ソリューションを本番に移行する際には、クラウドベースのベストプラクティスを考慮して構築されていることを確認する必要があります。「 AWS Well-Architected framework &nbsp;」は、ソリューションの設計、構築、レビューの際に、AWS を安全かつ高パフォーマンス、回復性が高く、効率的に使用していることを確認するのに役立ちます。AWS IoT におけるクラウドベースのベストプラクティスの詳細は、 IoT Lens – AWS Well-Architected Framework &nbsp;を参照してください。 まとめ このブログでは、典型的な IoT ソリューションを構成する主要な技術要素に分解し、それぞれについて考慮すべき要件と注意点を明らかにしました。IoT ソリューションの構築は間違いなく複雑ですが、AWS IoT を活用することによって、その道のりを簡素化、合理化することができます。さらに、 AWS パートナー が構築した AWS IoT ソリューションを利用することで、市場投入までの時間を短縮することもご検討ください。 著者紹介 Kai-Matthias Dickman &nbsp;は、Amazon Web Services ( AWS ) の IoT ソリューションアーキテクトです。大企業の開発者や意思決定者と協力して、AWS IoT サービスの導入を推進することを楽しんでいます。IoT とクラウドに関する深い知識を持っており、スタートアップから大企業に至る世界中のお客様と協力して、AWS エコシステムを使った IoT ソリューションの構築を可能にする役割を担っています。 Nicholas Switzer &nbsp;は、Amazon Web Services の IoT ソリューションアーキテクトです。2022年に AWS に加入し、IoT 、エッジコンピューティング、コネクテッドプロダクト分野を専門としています。アメリカに拠点を置き、日常生活を改善するスマートプロダクトの構築を楽しんでいます。 この記事は Kai-Matthias Dickman &nbsp;,&nbsp; Nicholas Switzer &nbsp;によって書かれた Deploying and managing an IoT workload on AWS &nbsp;の日本語訳です。この記事は ソリューションアーキテクト の伊藤 一成が翻訳しました。

e コマース市場は年々拡大を続けており、小売業界のさらなる変革を後押ししています。小売業者は、より多くの顧客を EC サイトへ呼び込むことに尽力しており、特にブラックフライデーやサイバーマンデーなどのピーク時の売上において、EC サイトが占める割合が高まっています。 Statista によると 、2022 年第 3 四半期、米国の小売業全体の売上において、 e コマースの占める割合は 14.8 ％ で、これは前四半期を上回っており、金額にして約 2660 億ドルになります。 小売業のリーダーが、e コマース事業から更なる価値を得る方法を模索しているのは、驚くことではありません。そのため、多くの企業がウェブサイトのトラフィックを監視し、売上に影響を与え得るオンラインアクティビティの変化の兆候を見つけ出そうとしています。例えば、トラフィックが減少することは、製品の価格設定が最適でなかったことや、システム障害などの要因により、需要が減少したことを示す可能性があります。いずれにせよ、売上は打撃を受けることになります。 一方、e コマースのトラフィックが急増することは、小売業者にとって良いことのように思えますが、必ずしもそうとは限りません。例えば、価格設定にミスがあり、オンラインショップの顧客がとんでもない安値で商品を買い占めていった場合です。最近、ある大手小売業者が、ウェブサイト上の小数点の位置を間違えて、100 ドルの人気商品をわずか 10 ドルで表示したことがありました。オンラインショップの顧客は大喜びで商品を大量に注文し、小売業者はこの不手際を修正し、さらなる損失を食い止めるために奔走することになりました。 どちらのシナリオでも、重要なのは、e コマースのトラフィックを常に把握し、発生した問題を解決するためにチームを迅速に動員することです。そこで、アマゾン ウェブ サービス（ AWS ）の人工知能と機械学習ソリューションが役に立ちます。小売業者は、ビデオやデータストリームをリアルタイムで収集、処理、分析できる Amazon Kinesis や、メトリクス内の異常を自動的に検出し、その根本原因を特定する Amazon Lookout for Metrics などのサービスから多大なる恩恵を受けることができます。 トラフィックの変動に対処する 小売業者は、e コマースのトラフィックが季節、月、日付、時間帯によって大きく変化することをご存じでしょう。例えば、多くの e コマースサイトでは、朝方の時間帯よりも夕方の時間帯でトラフィックが多くなります。また、平日ではなく、週末にトラフィックが急増するケースもあります。一方、休日やその他のピーク時のトラフィックは、これらのトレンドのいずれにも当てはまらないかもしれません。このように動的で様々なパターンがあるため、ユーザートラフィックの少数派な異常をニアリアルタイムで検出することは非常に困難です。 大規模な e コマースを展開する企業の多くは、ユーザートラフィックの主要な異常を検出するための手順をすでに整えています。しかし、これらのプロセスは、静的なアラートや手動による監視技術に依存していることが多く、少数派な異常をニアリアルタイムで検出することは困難であり、問題が起こった際にチームが迅速に介入し、対応することが難しくなっています。 小売業者は、過去のデータパターンに基づいて、ユーザートラフィックのわずかな変化を検出することができるスマートなソリューションを必要としています。しかし、静的なルールに基づいてこれらの傾向をプログラミングすることは、非常に時間がかかり、導入後の効果もあまり期待できないことがあります。 予想されるトラフィックの変動を考慮しつつも、小売業者が自動的に少数派な（そして主要な）異常を検知したい際に、AWSの異常検知ソリューションがどのように役立つかを詳しく見ていきましょう。 図1. e コマーストラフィックのための異常検知ソリューションのアーキテクチャ AWS の異常検知ソリューションとの連携 このソリューションは、データ収集と異常検知を自動化し、データを操作して、重大性に基づいて異常をフィルタリングするためのグラフィカルユーザーインターフェースを提供します。ここからは、このソリューションがどのように機能するかを説明します。 顧客は、オンラインショッピングのために e コマースアプリケーションを利用します。 &nbsp; プロセスは、顧客がモバイルまたはデスクトップアプリケーションを使用して、e コマースのウェブサイトで商品を検索し、表示することから始まります。買い物かごに商品を入れた後、決済ページで購入を完了します。これらのページのトラフィックは、時間間隔に基づくデータの塊に分解されます。これらは、トラフィックのパターンを理解するために使用できるデータポイントとして機能します。 データは、取り込まれ、変換され、保存されます。 &nbsp; e コマースアプリケーションは、複数のフォーマットと異なる量のデータを生成します。それを理解するためには、データを継続的に取り込むストリーミングプラットフォームにデータを供給する必要があります。このソリューションでは、 Amazon Kinesis Data Streams （あらゆる規模のデータストリームの取得、処理、保存を支援）を使用して、ユーザーのトラフィックを取得し、e コマースアプリケーションとのやりとりを記録します。通常、収集したデータを修正または「変換」して、迅速な分析や機械学習に適した形式で保存する必要があります。 Amazon Kinesis Data Firehose （ストリーミングデータを取り込み、変換し、データレイク・データストア・分析サービスに配信することができるサービス）や AWS Lambda （サーバーやクラスタを意識せずにコードを実行できるサーバーレス、イベント駆動型のコンピューティングサービス）などの AWS サービスは、データを変換して分析用に準備するために役立ちます。データは、どこからでもどんな量のデータでも取り出せるように構築されたオブジェクトストレージサービス、 Amazon Simple Storage Service (Amazon S3) を使って、効率的にクラウドに保存されます。 トラフィックの異常を検出し、チームに通知します。 &nbsp; データをニアリアルタイムで分析し、異常を特定する準備が整ったので、ここからが Amazon Lookout for Metrics の出番です。まずは、Amazon Lookout for Metrics で 検出器 を作成し、Amazon S3 データリポジトリからデータを自動的に取り込むことから始めます。検出器が起動すると、Amazon Lookout for Metrics はデータの監視を開始し、異常があればニアリアルタイムでフラグを立てます。誤検知を減らすために、検知システムの感度を 0 から 100 の間で調整することができます。機械学習技術を使用して、Amazon Lookout for Metrics は、トラフィックパターンからフィードバックを得て、時間の経過とともに検出結果の継続的な改善をします。当然ながら、異常があればチームメンバーに通知したくなるでしょう。通知により、ウェブサイトで何が起きているのかを理解でき、必要に応じて迅速に是正措置を講じることができるようになります。このソリューションは、 Amazon Simple Notification Service (Amazon SNS) とシームレスに統合されており、SMS テキストメッセージ、モバイルプッシュ、電子メールを通じてアラートや通知を自動的に送信することができます。 まとめ AWS の異常検知ソリューションにより、小売業者は e コマースのトラフィックを監視し、売上に影響を与え得るトラフィックパターンの異常を迅速に検知するための強力なツールを手に入れました。これは、従来の静的アラートや手動による監視技術を大きく前進させるものです。オンライン販売の拡大と不必要な損失の回避を目指す小売業者にとって、このAWSのソリューションは、コストと時間のかかる自社開発ソリューションに投資することなく、目標を達成するための効果的な方法となり得るでしょう。 各サービスの詳細は Amazon Lookout for Metrics Developer Guide Amazon Kinesis Data Streams Developer Guide Amazon Kinesis Data Firehose Developer Guide 著者について Aditya Pendyala Aditya は、NYC を拠点とする AWS のシニアソリューションアーキテクトです。クラウドベースのアプリケーションのアーキテクトとして豊富な経験があります。現在、大企業向けに、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャの構築を支援し、クラウドに関するあらゆることの案内をしています。Shippensburg 大学でコンピュータサイエンスの理学修士号を取得しました。また、彼は、” When you cease to learn, you cease to grow “という言葉を信条としています。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。