AWS Resilience Hub  は、アプリケーションにおけるレジリエンスの定義、追跡、管理を支援するために設計された AWS サービスです。このサービスでは、 AWS Well-Architected  のベストプラクティスを使用してワークロードのレジリエンスを理解し、改善するのに役立ちます。また、レジリエンスと運用上の推奨事項の両方を提供することで、お客様は目標復旧時点 (RPO) と目標復旧時間 (RTO) に関する組織およびワークロード毎の要件を一貫して満たすことができます。 このブログ記事では、レジリエンスのための責任共有モデルと、それが AWS Resilience Hub サービスを使用する際の考慮事項にどのように影響するかを見ていきます。 責任共有モデル レジリエンスのための責任共有モデル について詳しく知りたい場合は、ホワイトペーパー「 AWS におけるワークロードのディザスタリカバリ : クラウドにおける復旧 」を読むことをお勧めします。以下の図は、お客様と AWS が共有する責任を示しています。AWS はクラウドのレジリエンスに責任を負い、お客様はクラウドにおけるレジリエンスに責任を負います。 図 1 – レジリエンスは AWS とお客様が分担する責任 このモデルでは、お客様が AWS Resilience Hub サービスを使用する際に配慮すべき、レジリエンスの推奨事項と運用上の推奨事項、という点を表しています。以下では、 Resilience Hub ワークショップ で用いられているアーキテクチャから具体例を取り上げて、これらのさまざまな側面について説明します。アーキテクチャや AWS Resilience Hub の使用方法に関する詳細情報や自習用の手順については、ワークショップのガイドに従ってください。 図 2 – AWS Resilience Hubワークショップのアーキテクチャ例 ここで使用されているアーキテクチャは、Application Load Balancer、EC2 Auto Scaling グループ内の EC2 インスタンス群、および RDS データベースで構成される 3 層アーキテクチャです。EC2 インスタンスは NAT ゲートウェイ経由のアウトバウンド接続が可能で、アプリケーションの静的コンテンツは S3 バケットに保存されます。 レジリエンスの推奨事項 AWS Resilience Hub でアプリケーションを評価した後、このサービスでは、設定した RTO/RPO の目標を達成するために、アーキテクチャ内のさまざまなワークロードコンポーネントにわたってレジリエンスの推奨事項を多数提示してくれます。すべてのRTO/RPOポリシーを実現するには、すべてのコンポーネントに関する推奨事項に取り組む必要があります。AWS Resilience Hub サービス内で管理できる潜在的な障害タイプの全リストは、 レジリエンスポリシーの管理 ドキュメントに記載されています。本ブログ記事では、ワークロードのデータベースに関するオプションの 2 つの推奨事項に焦点を当てます。オプション 1 は最小限の変更とコストの両方を最適化し、オプション 2 はアベイラビリティーゾーン障害時における最短の RTO/RPO を実現するように最適化します。お客様は、組織とワークロードの RTO/RPO のニーズを満たすために、どのオプションを採用するかについて、アーキテクチャ上の決定を下す必要があります。どちらのオプションも、AWS Resilience Hub で定義されているアプリケーションの設定されたポリシーを満たします。 図 3 – データベースのレジリエンスに関する推奨事項 この例では、オプション 1 を実装することを決定しました。ご覧のとおり、データベースはすでに RTO と RPO のレジリエンスポリシーを満たしていますが、新しい評価では、アベイラビリティーゾーン障害時における RTO/RPO をさらに最適化することが推奨されています。つまり、必要に応じてさらに最適化した RTO/RPO を実現できるということです。 図 4 – 推奨事項を実装した後のデータベースのレジリエンスに関する推奨事項 運用上の推奨事項 アラーム ここでは、運用上の推奨事項に含まれるアラームセクションにおける、2 つのお客様の責任部分を見ていきます。 推奨アラームに必要な追加設定 推奨エンジンでカバーされないアラーム条件 推奨アラームに必要な追加設定 AWS Resilience Hub が推奨する推奨アラームの中には、追加の設定が必要なものがあります。以下の例では、対象の Amazon CloudWatch アラーム  には CloudWatch Synthetics が必要であることがわかります。CloudWatch Synthetics を使用して、スケジュールに従って実行される設定可能なスクリプトであるカナリアを作成し、エンドポイントと API をモニタリングできます。正確な要件の詳細は、以下に示すように「前提条件」セクションに記載されています。 推奨エンジンではカバーされないアラーム条件 レジリエンス評価を実行する場合、AWS Resilience Hub はアプリケーションのレジリエンスをモニタリングするために Amazon CloudWatch アラームを設定することを推奨しています。これらのアラームは完全ではないため、アプリケーションの監視ニーズを十分に検討して、アプリケーションを完全に監視できるようにする必要があります。ベストプラクティスを満たすためのガイドとして、AWS Well-Architected フレームワーク ( REL 6 : ワークロードリソースをどのように監視していますか？ ) を使用できます。 図 5 – アラームの前提条件 標準操作手順 (SOP) SOPは、障害やアラームが発生した場合にアプリケーションを効率的に復旧するために設計された規範的な一連の手順です。AWS Resilience Hub は、アプリケーションコンポーネントに基づいて、準備すべき SOP を推奨します。 アプリケーションごとに要件が異なるため、AWS Resilience Hub が提供するデフォルトの AWS Systems Manager (SSM) ドキュメントのリストでは、すべてのニーズに対応できるわけではありません。ただし、デフォルトの SSM ドキュメントをコピーして、それをベースとして使用して、アプリケーションに合わせた独自のカスタムドキュメントを作成することはできます。 ドキュメントをコードベースに直接追加し、そこですべての変更を加えることで、最新のSOPをインフラストラクチャとともに確実にデプロイできます。 AWS Fault Injection Service (FIS)  の実験と SSM ドキュメントを組み合わせ、CI/CD パイプラインで実行することで、SOP がワークロードに対して継続的にテストされていることがわかります。 運用準備状況レビュー (ORR) の一環として SOP レビューし、アプリケーションのニーズに合った最新の手順が整っていることを確認する必要があります。ORR のホワイトペーパーを確認して、その内容の詳細な概要を確認してください。 ORR カスタムレンズに関するブログ で説明されているように、 AWS Well-Architected ツール を使用して ORR カスタムレンズを使用することもできます。これがどのように Well-Architected フレームワークと適合するかについては、運用上の優秀性の柱に含まれる OPS07-BP02 運用準備状況の一貫したレビュー を参照してください。 Fault Injection Service (FIS) を用いた実験 ここでは、運用上の推奨事項に含まれる FIS セクションを見る際に、3 つのお客様の責任部分を見ていきます。 推奨される FIS 実験に必要な追加設定 推奨エンジンでカバーされていない FIS 要件 依存システムの網羅 推奨される FIS 実験に必要な追加設定 AWS Fault Injection Service (FIS) は、アプリケーションのパフォーマンス、可観測性、レジリエンスを向上させるための障害注入実験を実行する完全マネージド型のサービスです。障害注入実験を実行して、AWS リソースのレジリエンスと、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、および AWS リージョンの障害からの回復にかかる時間を測定できます。レジリエンスを測定するために、これらの障害注入実験では AWS リソースの中断をシミュレートします。中断の例としては、ネットワークが使用できないエラー、フェイルオーバー、EC2 Auto Scaling グループでのプロセスの停止、Amazon RDS でのブートリカバリ、アベイラビリティーゾーンの問題などがあります。障害注入実験が終了したら、アプリケーションがレジリエンスポリシーの RTO ターゲットに定義されている割り込みタイプから回復できるかどうかを判断できます。 AWS Resilience Hub が推奨する FIS 実験の中には、追加の設定が必要なものもあります。以下の例では、この FIS を用いた実験 には既存の CloudWatch アラーム が必要であることがわかります。正確な要件の詳細は、AWS Resilience Hub からの通知に記載されています。 図 6 – 追加の FIS 設定 推奨エンジンでカバーされていない FIS 要件 AWS Resilience Hub でリストされている実験はすべてを網羅しているわけではありません。利用可能な実験をワークロード要件と照らし合わせて評価する必要があります。この例では、S3、Auto Scaling グループ、RDS の実験の推奨事項と、ロードバランサーに対するネットワーク実験があります。他に実行したい実験があるかもしれません。たとえば、アプリケーションが EBS の一時的な I/O 停止 をどのように処理するかを確認したい場合があります。 図7 – FISの実験 依存関係の網羅 最後に、ワークロードは組織内の他の依存関係に依存している可能性があります。レジリエントなシステムを構築するためにどのような実験が必要かについて、依存するチーム間で交渉する必要があります。AWS Resilience Hub は、関連する個々のワークロードに関する実験を推奨できますが、実験の依存関係の側面については、お客様が適切に評価して実装する必要があります。その良い例が、Well-Architected の運用上の優秀性の柱である OPS04 にあります。 オペレーショナル・インテグレーション 上で説明した考慮事項に加えて、その他の考慮事項がいくつかあります。 その他の運用要件 前のセクションで説明したように、AWS Resilience Hub の運用上の推奨事項はすべてを網羅しているわけではありません。追加のアラーム、SOP、FIS 実験が必要な場合、AWS Resilience Hub の外部でこれらを作成して維持するのはお客様の責任です。 テンプレートを使用して個別ではなくワークロード単位に統合する AWS Resilience Hub による運用上の推奨事項はアプリケーション単位に統合される必要があります。ハードコーディングされたリソースは、顧客チームにより動的なものに置き換えることができます。AWS Resilience Hubのドキュメントには、その方法を概説した CloudFormation の例が掲載されています ( AWS CloudFormation を使用して運用上の推奨事項をアプリケーションに統合する ) 。 標準化されたレジリエンス戦略の出発点としてテンプレートを使用する レジリエンス導入の第一歩として AWS Resilience Hub を使用している場合は、プラクティスを標準化することが重要です。アラーム、SOP、FIS 実験は、個々のチームだけでなく組織全体のレジリエンス戦略の一部となるはずです。既存の ORR または開発中の ORR に AWS Resilience Hub を含めると、レジリエンスの戦略を定義するのに役立ちます。 新しい推奨事項を継続的に確認する レジリエンスと運用の両方に関する新しい推奨事項は、サービスが拡大し、追加の AWS サービスのサポートが追加されるにつれて、定期的に AWS Resilience Hub に追加されます。定期的な ORR の一環として、ワークロードの要件を継続的に評価して見直すことは、お客様の責任です。これには、AWS Resilience Hub の追加機能が含まれます。AWS Resilience Hub のアプリケーション耐性スコアを追跡することで、アラーム、SOP、FIS 実験が定期的にテストされているかどうかもわかります。詳細については、このブログ記事「 AWS Resilience Hub スコアの使用方法 」を参照してください。 結論 AWS Resilience Hub を使用すると、レジリエンスの取り組みのさまざまな段階にいるお客様が、ワークロードとアプリケーションのレジリエンスを定義、追跡、管理できるようになります。お客様は、組織とワークロードの期待に応えるだけでなく、クラウドにおけるレジリエンスに対する責任もカバーするために、AWS Resilience Hub の推奨事項に加えて、どのような追加要件やリソースを実装する必要があるかを定義する必要があります。 Jamie Ibbs Jamie Ibbs は AWS のスペシャリスト テクニカルアカウントマネージャです。彼は、特に管理やガバナンス、レジリエンシーに興味を持ち、お客様が大規模に運用できるよう支援しています。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

このブログは Sam Mokhtari, Dr. Ali Khoshkbar, Sandipan Bhaumik によって執筆された内容を翻訳したものです。原文は こちら を参照して下さい。 このブログシリーズの第一部「 持続可能性の為のモダンデータアーキテクチャ最適化 : 第一部 – データ取り込みとデータレイク 」では、 モダンデータアーキテクチャ における 1) データ取り込み、2) データレイクの柱に焦点を当てました。このブログ記事では、3) 統合データガバナンス、4) データ移動、5) 目的別分析の柱に含まれるコンポーネントを最適化するためのガイダンスとベストプラクティスを紹介します。 図 1 は、モダンデータアーキテクチャのさまざまな柱を示しています。これには、データ取り込み、データレイク、統合データガバナンス、データ移動、および目的別分析の柱が含まれます。 図 1. AWS のモダンデータ分析リファレンスアーキテクチャ 3. 統合データガバナンス 一元化されたデータカタログは、ストレージレイヤーのデータセットに関するビジネスのメタデータとテクニカルメタデータを保存する役割を担います。管理者はこのレイヤーに権限を適用し、セキュリティ監査のイベントを追跡します。 データディスカバリー データ共有を増やし、データの移動や重複を減らすには、様々なユーザーペルソナに対してデータ検出と明確なアクセス制御を可能にする必要があります。これにより、重複するデータ処理のアクティビティが減ります。組織内の各チームが、この一元化されたカタログを利用することができます。ファーストパーティデータ (売上データなど) またはサードパーティデータ (株価、気候変動のデータセットなど) を提供します。ソースから繰り返しデータを取得する必要はなく、データへのアクセスは 1 回だけで済みます。 AWS Glue データカタログでは、メタデータの追加と検索のプロセスを簡素化できます。AWS Glue クローラーを使用して既存のスキーマを更新し、新しいデータセットを発見します。スケジュールを慎重に計画して、不要なクロールを減らしてください。 データ共有 AWS Lake Formation などのサービスを使用して、様々なデータコンシューマー向けに明確に定義されたアクセス制御メカニズムを確立します。これにより、きめ細かなアクセス制御で組織単位の間でデータセットを共有できるようになり、重複するコピーや移動が減ります。 Amazon Redshift データ共有 を使用すると、データウェアハウス間でデータをコピーする必要がなくなります。 明確に定義されたデータセット 明確に定義されたデータセットと関連するメタデータを作成して、不必要なデータ処理や操作を回避します。これにより、追加のデータ操作に起因するリソース使用量を削減できます。 4. データ移動 AWS Glue は、サーバーレスで 従量課金制 のデータ移動機能を提供します。サーバーやクラスターを立ち上げて管理する必要はありません。数十テラバイトのデータを処理できる ETL パイプラインを設定します。 パフォーマンスを犠牲にすることなくアイドル状態のリソースを最小限に抑えるには、 AWS Glue の Auto Scaling を使用してください。 ユースケース ごと に AWS Glue ワークフローを作成するのではなく、 AWS Glue ブループリント を使用することで、同様のユースケースの AWS Glue ワークフローを作成して共有できます。 AWS Glue ジョブブックマーク は、以前に処理されたデータを追跡できます。 本番前のジョブ、テスト、1 回限りのデータロードなど、緊急性が低い、または時間に左右されないデータ統合ワークロードには、 Glue Flex ジョブ の使用を検討してください。Flex では、AWS Glue ジョブは専用のハードウェアではなく、予備のコンピューティング能力で実行されます。 複数のデータフレーム間の結合は、Spark ジョブでは一般的な操作です。ノード間のデータのシャッフルを減らすには、マージされたデータフレームの 1 つが実行中のすべてのノードで複製できるほど小さい場合、 broadcast joins を使用します。 最新の AWS Glue バージョン では、ワークロードにさらに多くの新しい効率的な機能が提供されています。 5. 目的に合わせた分析 データ処理モード リアルタイムデータ処理オプションには、継続的にコンピューティングリソースを使い、より多くのエネルギー消費が必要です。持続可能性を最大限に高めるには、トレードオフを評価し、最適なバッチデータ処理のオプションを選択してください。 バッチおよびインタラクティブなワークロードの要件を特定し、 Amazon EMR で 一時的なクラスター を設計します。スポットインスタンスを使用し、 インスタンスフリート を設定することで、使用率を最大化できます。 エネルギー効率を向上させるために、 Amazon EMR Serverless を使用すると、データ処理のジョブにリソースを過剰にプロビジョニングしたり、プロビジョニングが不十分になったりすることを回避できます。Amazon EMR Serverless は、アプリケーションが必要とするリソースを自動的に判断し、これらのリソースを収集してジョブを処理し、ジョブが終了するとリソースを解放します。 Amazon Redshift RA3 ノード はコンピューティング効率を向上させることができます。RA3 ノードでは、ストレージを拡張せずにコンピューティングをスケールアップまたはスケールダウンできます。 Amazon Redshift Serverless を選択すると、データウェアハウスの容量をインテリジェントにスケーリングできます。これにより、最も要求が厳しく予測不可能なワークロードでも、より高速なパフォーマンスを実現できます。 エネルギー効率の高い変換とデータモデル設計 データ処理とデータモデリングのベストプラクティスは、組織の環境への影響を軽減できます。 Amazon Redshift クラスター内のノード間での不必要なデータ移動を避けるため、 テーブル設計のベストプラクティス に従ってください。 Amazon Redshift の 自動テーブル最適化 (ATO) を使用して、使用パターンに基づいてテーブルを自動調整することもできます。 Amazon Athena または Amazon Redshift の EXPLAIN 機能を使用して、クエリを調整および最適化します。 Amazon Redshift Advisor は、パフォーマンス統計と運用データに基づいてデータウェアハウスを最適化するための具体的でカスタマイズされた推奨事項を提供します。 Amazon EMR または Amazon OpenSearch Service を、 AWS Graviton などの電力効率の高いプロセッサに移行することを検討してください。 AWS Graviton 3 は、他の CPU と比較して 2.5 ～ 3 倍のパフォーマンスを実現しています。Graviton 3 ベースのインスタンスは、同等の EC2 インスタンスと同じパフォーマンスで消費電力が最大 60% 少なくなります。 アイドルリソースを最小化 EMR クラスター の auto scaling を使用するか、 Amazon Kinesis Data Streams On-Demand を採用して、パフォーマンスを犠牲にすることなくアイドル状態のリソースを最小限に抑えます。 AWS Trusted Advisor は、十分に活用されていない Amazon Redshift クラスター を特定するのに役立ちます。使用していないときは Amazon Redshift クラスターを一時停止し、必要に応じて再開します。 エネルギー効率の高い消費パターン データを Amazon Redshift にコピーするのではなく、Amazon Athena または Amazon Redshift Spectrum を使用してその場でデータをクエリして 1 回限りの分析を行うことを検討してください。 必要に応じて、 頻繁にクエリを実行できるようにキャッシュレイヤー を有効にします。これは、Amazon Redshift などのサービスに組み込まれている result caching に追加されるものです。また、ソースデータが頻繁に変更されないすべてのクエリには、 Amazon Athena Query Result Reuse を使用してください。 Amazon Redshift または Amazon Aurora PostgreSQL で利用できる マテリアライズドビュー機能 を使用して、不必要な計算を回避してください。 Amazon Athena フェデレーテッドクエリ または Amazon Redshift フェデレーテッドクエリ を利用し、データストア全体でフェデレーテッドクエリを使用すると、データ移動を減らすことができます。個別の Amazon Redshift クラスター間でクエリを実行する場合は、これらのクラスター間のデータ移動を減らす Amazon Redshift データ共有 機能の使用を検討してください。 環境の持続可能性の為の改善追跡と評価 持続可能性に向けたワークロード最適化の成功を評価する最適な方法は、 プロキシメトリクスと作業単位の KPI を使用することです。これは、ストレージの場合は 1 トランザクションあたりの GB 数、コンピューティングの場合は 1 トランザクションあたりの vCPU 分です。 表 1 には、改善の度合いを測るメトリクスとして、分析サービスで収集できる特定のメトリクスが示されています。これらは、この記事で取り上げた最新のデータアーキテクチャの各柱に該当します。 柱 メトリクス 統合データガバナンス CloudTrail events – for monitoring crawler runs and job runs データ移動 DPU-hour for AWS Glue jobs 目的別分析 Redshift cluster performance data – CPUUtilization, percentage disk space used, read throughput, write throughput, query duration, query throughput Redshift query history (optimize queries) – query runtime, CPUUtilization, storage capacity used Amazon Redshift Spectrum queries – System views: SVL_S3QUERY, SVL_S3QUERY_SUMMARY CloudWatch metrics for Amazon EMR – IsIdle, HDFSUtilization, S3BytesRead, S3BytesWritten CloudWatch metrics for Amazon OpenSearch (Cluster metrics) – CPUUtilization, FreeStorageSpace, ClusterUsedSpace, JVMMemoryPressure, DiskThroughputThrottle CloudWatch metrics for Amazon Athena – ProcessedBytes, QueryQueueTime, TotalExecutionTime CloudWatch metrics for Amazon SageMaker – CPUUtilization, GPUUtilization, GPUMemoryUtilization, MemoryUtilization, and DiskUtilization Kinesis Data Analytics application metrics – CPUUtilization, containerCPUUtilization, containerDiskUtilization, idleTimeMsPerSecond テーブル 1. モダンデータアーキテクチャの柱となるメトリクス まとめ このブログ記事では、モダンアーキテクチャの統合データガバナンス、データ移動、目的別分析の柱の下でプロセスを最適化するためのベストプラクティスを紹介しました。 詳細を知りたい場合は、 AWS Well-Architected Framework の持続可能性の柱 や、 持続可能性のためのアーキテクチャ に関するその他のブログ投稿をご覧ください。 アーキテクチャに関するその他のコンテンツをお探しの場合は、 AWS アーキテクチャセンター を参照して、リファレンスアーキテクチャ図、精査されたアーキテクチャソリューション、 Well-Architected のベストプラクティス、パターン、アイコンなどを確認してください。 Sam Mokhtari Sam Mokhtari 博士は、AWS Well-Architected Framework の持続可能性の柱を主導しています。彼の主な専門分野はデータと分析であり、この分野で 30 以上の影響力のある記事を発表しています。 Dr. Ali Khoshkbar Ali Khoshkbar 博士は、アマゾンウェブサービス (AWS) プロフェッショナルサービスのシニアクラウドアーキテクトです。彼は、顧客がクラウド上でスケーラブルで高性能なデータ分析ソリューションを構築できるよう支援することに情熱を注いでいます。 Sandipan Bhaumik Sandipan Bhaumik は、ロンドンを拠点とするシニア分析スペシャリストソリューションアーキテクトです。彼は、クラウド内に最新のデータアーキテクチャを構築して大規模な分析を実行することで、顧客が従来のデータプラットフォームを最新化できるよう支援しています。 このブログは、ソリューションアーキテクトの福田哲也が翻訳しました。

一般的な SaaS におけるテナント分離戦略や実装例は、AWS ホワイトペーパー SaaS アーキテクチャの基礎 や builders.flash の記事「 SaaS on AWS を成功に導くためのポイントとは ? 」や AWS Well-Architected フレームワーク SaaS レンズ において紹介されています。 最近では、地方公共団体や医療等の高いセキュリティレベルが求められる業界にクラウドが普及してきたこともあり、閉域でのマルチテナント設計のニーズも増えてきています。例えば、自治体の基幹システムの実装では総務省が示す「地方公共団体における情報セキュリティポリシーに関するガイドライン」及びデジタル庁が示す「地方公共団体情報システム非機能要件の標準」に準拠したセキュリティ対策を施す必要があります。 また、政府共通のクラウドサービスの利用環境である ガバメントクラウド では、複数の地方公共団体の環境を1つのベンダで管理する、共同利用方式が推奨されています。さらに、共同利用方式において、団体 (テナント) 間の環境分離方式についてはアカウント分離、ネットワーク分離、アプリケーション分離等による分離手法の検証が行われています。その中でもアプリケーション分離はコスト効率が良いテナント間の分離手法と言われています。 一方、閉域網でのアプリケーション分離による、いわゆる SaaS の実装例やサンプル情報はまだ少ないのが実情です。 そのため、今回パブリックセクターのソリューションアーキテクトが、 閉域網でのマルチテナントアプリケーションのサンプルテンプレート を公開しました。本テンプレートは前述の AWS Well-Architected フレームワーク SaaS レンズ で定義されている、 ブリッジモデル を採用しています。 技術要素としては、 AWS PrivateLink や Nuxt 、 Keycloak を採用しているため、閉域での SaaS の実装を検討している方をはじめ、ガバメントクラウドにおいてアプリケーション分離を検討されている方、Keycloak on AWSに関心がある方にご参考いただけます。 ソリューション概要 テナント分離の詳細は SaaS ビジネスの成否を分けるテナント分離戦略 に記載がありますが、大きく分けると以下の3パターンです。 サイロ分離 プール分離 ブリッジモデル 本テンプレートではブリッジモデルを採用した以下のアーキテクチャとなっており、Multi-tenancy環境とConsumer環境を各々の Amazon VPC にデプロイすることが可能です。 Consumer VPCとMulti-tenancy VPC間の通信は、 Amazon Route53 とAWS PrivateLinkを利用して閉域接続しており、WebアプリケーションはNuxtで実装しています。認証に関しては、Keycloakを利用して各Consumer VPCにあるActive directoryに対してLDAP認証させ、後述するサブドメイン情報で各Consumerのページにルーティングしています。 通信の整理 本テンプレートでは、下図のように VPC 間で 3 つの経路による通信が必要となります。 ①端末からアプリケーションサーバへの通信、②端末から認証認可サーバへの通信、③認証認可サーバから Active Directory への通信 です。 団体間の環境をアカウント分離方式・ネットワーク分離方式で分離する場合、団体ごとに CIDR を設計できるため、各団体のネットワーク環境の CIDR と重複できないような設計ができ、 AWS Transit Gateway によるシステム間通信を行うことができます。 一方、アプリケーション分離方式を採用する場合、同じ VPC に複数の団体からアクセスされるため、CIDR 重複が起こり、Transit Gateway では正しく通信が行えなくなります。 そのため、今回は各団体の環境 (Consumer VPC) とアプリケーション環境 (Multi-tenancy Environment VPC) で双方向に Private Link を利用することで、CIDR 重複が起きていてもシステム間連携を行えるような実装にしています。 PrivateLink の詳細については AWS PrivateLink の概要 をご参照ください。 アプリケーションの設計 本構成におけるロードバランサー・アプリケーションコンテナのテナント分離について説明します。 本構成では、 Elastic Load Balancer(ELB) に Network Load Balancer を採用しています。 Application Load Balancer(ALB) はPrivateLink のターゲットに対応しておらず、機能的にも NLB で充足するためです。 一般的なブリッジモデルでは、NLB は団体間で共用するケースが多く見られます。自治体の要件として他自治体のアプリケーション画面が見えてはならないケースが想定されるため、本構成ではNLBを共用する構成(Shared NLB)の他、NLB を団体ごとに分離し、Endpoint によって制限をかけ、他自治体のアプリケーション画面に到達できないような構成 (Dedicated NLB)も選択できるようになっています。 テナントごとにアプリケーション画面を出し分ける方法として、テナントごとにパスを分ける ( https://domain/a-corp/ ) 設計や、ホスト名を分ける ( https://a-corp.domain/ ) 設計が考えられますが、今回は他自治体の他自治体のアプリケーション画面に到達できないようにするため、テナントごとにサブドメイン・ NLB を分け、コンテンツもサブドメインを元に出し分けています。具体的には、アプリケーションコンテナでは、アクセス元のサブドメインを元に、表示するコンテンツ・認証認可サーバの URL を使い分けています。一方で、アプリケーションコンテナに関しては複数のテナントで共用しており、コスト効率がよい設計となっています。 a-corp.xxxx.xxxx でアクセスした時のページ b-corp.xxxx.xxxx でアクセスした時のページ DB設計 本構成におけるデータベースのテナント分離について説明します。 本テンプレートでは自治体の基幹システムで採用されることが多いため、データベースエンジンとして PostgreSQL を、AWS のサービスとして Amazon Aurora Serverless を選定しています。 団体間の分離方式として、テナントごとにそれぞれ RDS インスタンスを用意し、それぞれのインスタンス内にテナント固有のデータベースを作成するサイロモデルを採用しています。理由としては、団体ごとに利用する暗号鍵を分けられるため暗号鍵消去が容易なことや、自治体によっては他団体とデータベースのインスタンスを分けるようなセキュリティポリシーを定めている場合があることから、サイロモデルを選定しました。 他にも様々なデータベースの分離方式があり、 SaaS におけるデータパーティショニング設計の勘所 で詳しく解説を行っています。 上記で挙げた観点以外でも、個別の専用環境を用意するコストはどれくらいか、団体間でリソース共有 (インスタンス共有) する場合はノイジーネイバーにどういう対策を行うかなど、多方面から検討を行う必要があります。 また、テンプレートの実装では RDS Proxy を採用していますが、アプリケーションが利用するコネクション数が多くない場合は RDS Proxy を利用せず、直接データベースへ接続する実装も考えられます(RDS Proxyを利用しない場合は、 config.ts のenableProxyをfalseに設定)。 認証 本構成における認証認可サーバの実装について説明します。 本テンプレートでは、認証認可サーバに Keycloak を採用しています。自治体の基幹システムの認証認可サーバでは、一般的な認証認可サーバが兼ね備えている機能の他、いくつかの追加の要件を満たすことが重要となります。 まず、「地方公共団体における情報セキュリティポリシーに関するガイドライン」に則るため、閉域でのアクセスに対応できることが必要となります。加えて、自治体の基幹システムにおいては認証認可サーバはユーザ認証機能だけでなく、システム間連携で利用される API の認証認可でも利用される可能性があります。その際「地方公共団体情報システム共通機能標準仕様書」に記載のある要件を満たす認証認可サーバを用意する必要がありますが、その要件も Keycloak で満たすことができるため、本テンプレートでは Keycloak を採用しました。 また、シングルサインオン (SSO) の実現には Open ID Connect (OIDC) を使用しています。OIDC は、安全かつ効率的な認証方法を提供し、ユーザー体験を向上させます。これにより、ユーザーは一度のログインで複数のサービスやアプリケーションにアクセスでき、作業効率が向上します。 既存 ID 管理システムの連携としては、自治体では既に ID 管理システムとして Active Directory を用いていることが多いため、LDAP を介して Active Directory と連携する実装としています。この連携により、既存の ID 管理システムをそのまま利用し、新しい認証システムへの移行をスムーズに行うことができます。 Keycloak は複数のテナントで共用し、 realm をテナントごとに分離する構成としています。 Webアプリケーション WebアプリケーションはNuxt( v3.8.2 )で実装し、コンテナ実行環境である AWS Fargate で稼働させ、 Amazon ECS でコンテナ環境を管理しています。アプリケーションのAPIは server/api で定義し、 useFetch でDatabaseへのデータ取得/登録を行なっています。今回は単純処理のためAPIのロジックをNuxtのserver/api側で全て実装しましたが、 AWS Lambda Function URLs や別のコンテナ環境で実装したWeb APIのエンドポイントを useFetch で利用することも可能です。Nuxtのデータフェッチに関しては こちら を参照ください。また、ルーティングに関しては、まずサブドメインを元に適切なKeycloakのrealmにルーティングし、 router options を利用しており各Pageへのルーティングを実現させています。 まとめ 本ブログでは、閉域網でのマルチテナントアプリケーションについて、テナント分離や実装内容について説明いたしました。本テンプレートはKeycloakでの認証方式を採用しているため、閉域網での実装に関心のある方だけではなく、Amazon ECS + AWS Fargateを利用したKeycloakのコンテナ実装に関心のある方にも参考になれば幸いです。 テンプレートのコードは aws-samples に公開しております。 著者について 松本 侑也 (Yuya Matsumoto) は、Public Sector 自治体担当のソリューションアーキテクトです。最近ではガバメントクラウドへの基幹システムの移行や、生成系AIの活用支援を中心に活動しています。       小泉 秀徳(Hidenori Koizumi) は、パブリックセクターのプロトタイピングソリューションアーキテクトです。最近のプロジェクトでは、生成系AIを活用したWebアプリケーション開発を行なっており、Next.jsやWebAssemblyに関心があります。

Protocol Buffers の概要 Protocol Buffers （Protobuf）は、構造化データをシリアル化するためのプラットフォームに依存しないアプローチを提供します。Protobuf は JSON に似ていますが、軽量で処理が速く、お好みのプログラミング言語でバインディングを自動的に生成できる点が異なります。 AWS IoT Core は、何十億もの IoT デバイスを接続し、何兆ものメッセージを AWS サービスにルーティングできるマネージドサービスです。これにより、アプリケーションを何百万ものデバイスにシームレスにスケーリングできます。AWS IoT Core と Protobuf の統合により、Protobuf の無駄のないデータシリアル化プロトコルと自動コードバインディング生成のメリットも得られます。 Protobuf コード生成による IoT のアジリティとセキュリティ Protobuf を利用する主な利点は、Protobuf によるコード生成を使用したソフトウェア開発の容易さと安全性です。アプリケーションのコンポーネント間で交換されるメッセージのスキーマの記述ができます。 protoc などのコード生成コンパイラが記述されたスキーマを解釈し、選択したプログラミング言語でのエンコードとデコード機能を実装します。Protobuf によるコード生成はメンテナンスが行き届いていて広く使用されているため、堅牢で実地試験済みのコードになっています。 自動コード生成により、開発者はエンコード関数やデコード関数を記述する必要がなくなり、プログラミング言語間の互換性が保証されます。 AWS IoT Core のルールエンジンによる Protocol Buffer メッセージング形式のサポートが新たに開始 されたことに伴い、C 言語 で記述されたプロデューサーアプリケーションをデバイス上で実行し、AWS Lambda 関数コンシューマーを Python で作成できるようになりました。これらはすべて生成されたバインディングを使用します。 AWS IoT Core で JSON よりも Protocol Buffers を使用するその他の利点は次のとおりです スキーマと検証: スキーマは送信者と受信者の両方によって適用され、適切な統合が確実に実現されます。メッセージは自動生成コードによってエンコードおよびデコードされるため、バグは排除されます。 適応性: スキーマは変更可能で、後方互換性と上位互換性を維持しながらメッセージコンテンツを変更できます。 帯域幅の最適化: 同じコンテンツでも、Protobuf を使用すると、ヘッダーではなくデータのみを送信するため、メッセージの長さが短くなります。時間が経つにつれて、デバイスの自律性が向上し、帯域幅の使用量が少なくなります。 メッセージングプロトコルとシリアル化形式に関する最近の調査 では、Protobuf 形式のメッセージは、同等の JSON 形式のメッセージよりも最大 10 倍小さいことが明らかになりました。つまり、同じコンテンツを伝送するためにネットワークを経由するバイト数が少なくなるということです。 効率的なデコード: Protobuf メッセージのデコードは JSON のデコードよりも効率的です。つまり、受信関数の実行時間が短くなります。 Auth0 が実施したベンチマーク では、Protobuf は同等のメッセージペイロードで JSON よりも最大 6 倍もパフォーマンスが高いことが明らかになりました。 このブログ記事では、Protobuf 形式を使用して AWS IoT Core にメッセージを公開するサンプルアプリケーションをデプロイする方法について説明します。その後、メッセージは AWS IoT Core ルールエンジンのルールによって選択的にフィルタリングされます。 Protobuf の基本をおさらいしてみましょう。 Protocol Buffers の概要 メッセージスキーマは Protobuf の重要な要素です。スキーマは次のようになります。 syntax = "proto3" ; import "google/protobuf/timestamp.proto" ; message Telemetry { enum MsgType { MSGTYPE_NORMAL = 0 ; MSGTYPE_ALERT = 1 ; } MsgType msgType = 1 ; string instrumentTag = 2 ; google . protobuf . Timestamp timestamp = 3 ; double value = 4 ; } C-like スキーマの最初の行は、使用している Protocol Buffers のバージョンを定義します。この記事では proto3 バージョンの構文を使用しますが、 proto2 もサポートされています。 次の行は、 Telemetry という新しいメッセージ定義が記述されることを示しています。 特にこのメッセージには、次の 4 つの異なるフィールドがあります。 msgType フィールド: MsgType 型で、「 MSGTYPE_NORMAL 」または「 MSGTYPE_ALERT 」の列挙子のみを指定可能 instrumentTag フィールド: string 型で、テレメトリデータを送信する計測器を識別 timestamp フィールド: google.protobuf.Timestamp 型で測定の時刻を示す value フィールド: double 型で計測値を示す 有効なすべてのデータ型と構文に関する追加情報については、 こちらのドキュメント を参照してください。 JSON 形式で記載された Telemetry メッセージは次のようになります。 { "msgType": "MSGTYPE_ALERT", "instrumentTag": "Temperature-001", "timestamp": 1676059669, "value": 72.5 } JSON Protocol Buffers (表示用に base64 でエンコード) を使用した同じメッセージは、次のようになります。 0801120F54656D70657261747572652D3030311A060895C89A9F06210000000000205240 メッセージの JSON 表現は 115 バイトであるのに対し、Protobuf では 36 バイトしかないことに注意してください。 スキーマが定義されると、 protoc を使用して次のことができます。 お好みのプログラミング言語でのバインディングの作成 AWS IoT Core が受信したメッセージをデコードするために使用する FileDescriptorSet の作成 AWS IoT Core での Protocol Buffers の利用 Protobuf は AWS IoT Core でさまざまな方法で使用できます。最も簡単な方法は、メッセージを バイナリペイロード として公開し、受信側のアプリケーションにデコードさせることです。これは AWS IoT Core ルールエンジンですでにサポートされており、Protobuf だけでなく、あらゆるバイナリペイロードで機能します。 ただし、Protobuf メッセージをデコードしてフィルタリングや転送を行う場合は、最大のメリットが得られます。フィルターされたメッセージは Protobuf として転送することも、JSON 形式しか認識しないアプリケーションとの互換性のために JSON にデコードすることもできます。 AWS IoT Core ルールエンジンが Protocol Buffers メッセージング形式をサポート したため、マネージドな機能を利用することでこれを実現できます。これより先のセクションでは、サンプルアプリケーションのデプロイと実行について説明します。 前提条件 こちらのサンプルアプリケーションを実行するには、次の条件を満たす必要があります。 protoc がインストールされたコンピュータ。 公式インストール手順 を参照してください。 AWS CLI のインストール。インストール手順は こちら を参照してください。 AWS アカウントと、Amazon S3、AWS IAM、AWS IoT Core、AWS CloudFormation に対するフルアクセス権限を持つ有効な認証情報 Python 3.7 以降のバージョン サンプルアプリケーション：Protobuf メッセージを JSON としてフィルタリングして転送 サンプルアプリケーションをデプロイして実行するには、次の 7 つの簡単なステップを実行します。 サンプルコードをダウンロードして Python の必要なパッケージをインストール IOT_ENDPOINT と AWS_REGION の環境変数を設定 protoc を使用して Python バインディングとメッセージ記述子を生成 Python と Protobuf で生成されたコードバインディングを使用してシミュレートされたデバイスを実行 AWS CloudFormation を使用して AWS リソースを作成し、Protobuf 記述子ファイルをアップロード Protobuf メッセージを照合、フィルタリング、JSON として再公開する AWS IoT ルールを確認 変換されたメッセージが再公開されていることを確認 Step 1：サンプルコードのダウンロードと Python の必要なパッケージのインストール サンプルアプリケーションを実行するには、コードをダウンロードして、その依存関係をインストールする必要があります。 まず、AWS github リポジトリからサンプルアプリケーションをダウンロードして抽出します https://github.com/aws-samples/aws-iotcore-protobuf-sample ZIP ファイルとしてダウンロードした場合は、解凍してください 必要な Python の依存関係をインストールするには、抽出したサンプルアプリケーションのフォルダー内で以下のコマンドを実行します。 pip install -r requirements.txt Bash 上記のコマンドを実行すると、 boto3 (Python 用 AWS SDK) と protobuf という 2 つの必要な Python 依存関係がインストールされます。 Step 2： IOT_ENDPOINT と AWS_REGION の環境変数の設定 シミュレートされた IoT デバイスは AWS IoT Core エンドポイントに接続して Protobuf 形式のメッセージを送信します。 Linux または Mac を実行している場合は、次のコマンドを実行します。 を必ず選択した AWS リージョンに置き換えてください。 export AWS_REGION = < AWS_REGION > export IOT_ENDPOINT = $( aws iot describe-endpoint --endpoint-type iot:Data-ATS --query endpointAddress --region $AWS_REGION --output text ) Bash Step 3： protoc を使用して Python バインディングとメッセージ記述子を生成 抽出されたサンプルアプリケーションには、前に示したスキーマの例に似た msg.proto という名前のファイルが含まれています。 以下のコマンドを実行して、シミュレートされたデバイスが記述子ファイルの生成に使用するコードバインディングを生成します。 protoc --python_out = . msg.proto protoc --include_imports -o filedescriptor.desc msg.proto Bash これらのコマンドを実施すると、次の2つのファイルが確認できます。 filedescriptor.desc msg_pb2.py Step 4：Python と Protobuf で生成されたコードバインディングを使用して、シミュレートされたデバイスを実行 抽出されたサンプルアプリケーションには、 simulate_device.py という名前のファイルが含まれています。 シミュレートされたデバイスを起動するには、以下のコマンドを実行します。 python3 simulate_device.py Bash AWS コンソールの MQTT テストクライアントを使用して、メッセージが AWS IoT Core に送信されていることを確認します。 AWS IoT Core サービスコンソール ( https://console.aws.amazon.com/iot ) にアクセスします。正しい AWS リージョンにいることを確認してください。 [テスト] で、[MQTT テストクライアント] を選択します。 トピックのフィルターに「 test/telemetry_all 」と入力します。 [追加設定] セクションを展開し、[MQTT ペイロード表示] で [未加工のペイロードを表示 (バイナリデータを 16 進値として表示)] を選択します。 [サブスクライブ] をクリックして、Protobuf 形式のメッセージが AWS IoT Core MQTT ブローカーに届くのを確認します。   Step 5：AWS CloudFormation を使用して AWS リソースを作成し、Protobuf 記述子ファイルをアップロード 抽出されたサンプルアプリケーションには、 support-infrastructure-template.yaml という名前の AWS CloudFormation テンプレートが含まれています。 このテンプレートは、Amazon S3 バケット、AWS IAM ロール、および AWS IoT ルールを定義します。 次のコマンドを実行して、CloudFormation テンプレートを AWS アカウントにデプロイします。必ず、 <YOUR_BUCKET_NAME> と <AWS_REGION> を S3 バケットと選択した AWS リージョンの名前に置き換えてください。 aws cloudformation create-stack --stack-name IotBlogPostSample \ --template-body file://support-infrastructure-template.yaml \ --capabilities CAPABILITY_NAMED_IAM \ --parameters ParameterKey = FileDescriptorBucketName,ParameterValue = < YOUR_BUCKET_NAME > \ --region = < AWS_REGION > Bash AWS IoT Core が Protobuf 形式のメッセージをサポートするには、protoc で生成した記述子ファイルが必要です。使用できるようにするために、作成した S3 バケットにアップロードします。以下のコマンドを実行して、記述子ファイルをアップロードします。 <YOUR_BUCKET_NAME> の値を CloudFormation テンプレートをデプロイするときに選択したのと同じ名前に置き換えてください。 aws s3 cp filedescriptor.desc s3://`<YOUR_BUCKET_NAME>`/msg/filedescriptor.desc Step 6: Protobuf メッセージを照合、フィルタリング、JSON として再公開する AWS IoT ルールを確認 こちらのBlogでは、危険な操作条件がある可能性があることを示している MSGTYPE_ALERT の msgType を持つメッセージをフィルタリングすることを考えます。CloudFormation テンプレートは、仮想デバイスが AWS IoT Core に送信している Protobuf 形式のメッセージをデコードする AWS IoT ルールを作成します。次に、アラートとなるメッセージを選択し、別の MQTT トピックとしてサブスクライブできるように JSON 形式で再公開 (再度パブリッシュ) する AWS IoT ルールを作成します。AWS IoT ルールを確認するには、次の手順を実行します。 AWS IoT Core サービスコンソールにアクセスする： https://console.aws.amazon.com/iot 左側のメニューの [メッセージのルーティング] で、[ルール] をクリックします。 ルールのリストには ProtobufAlertRule という名前の AWS IoT ルールが含まれています。クリックすると詳細が表示されます。 SQL ステートメントの下にある、下記 SQL ステートメントの記述を確認してください。各要素の意味については後ほど説明します。 [アクション] に AWS IoT トピックに再公開するアクションが一つあることを確認してください。 SELECT VALUE decode ( encode ( * , 'base64' ) , "proto" , "<YOUR_BUCKET_NAME>" , "msg/filedescriptor.desc" , "msg" , "Telemetry" ) FROM 'test/telemetry_all' WHERE decode ( encode ( * , 'base64' ) , "proto" , "<YOUR_BUCKET_NAME>" , "msg/filedescriptor.desc" , "msg" , "Telemetry" ) . msgType = 'MSGTYPE_ALERT' SQL   この SQL ステートメントは次の処理を行います。 SELECT VALUE decode(...) は、デコードされた Protobuf ペイロード全体が JSON ペイロードとして送信先の AWS IoT トピックに再公開されることを示します。メッセージを Protobuf 形式のまま転送したい場合は、これを単純な SELECT * に置き換えることができます WHERE decode(...).msgType = 'MSGTYPE_ALERT' は受信した Protobuf フォーマットのメッセージをデコードし、 msgType の値が MSGTYPE_ALERT となっているメッセージのみを転送します Step 7：変換されたメッセージが再公開されていることを確認 この AWS IoT ルールにあるアクションをクリックすると、メッセージが topic/telemetry_alerts トピックに再公開されることがわかります。  再公開先のトピックである test/telemetry_alerts は、サンプルアプリケーションの AWS CloudFormation テンプレート宣言されている AWS IoT ルールアクションの定義の一部です。 トピックをサブスクライブして JSON 形式のメッセージが再発行されるかどうかを確認するには、次の手順に従います。 AWS IoT Core サービスコンソールにアクセスする： https://console.aws.amazon.com/iot [テスト] で、[MQTT テストクライアント] を選択します。 トピックフィルターに test/telemetry_alert と入力します [追加設定] セクションを展開し、[MQTT ペイロード表示] で [JSON ペイロードを自動フォーマット (読みやすさが向上)] オプションが選択されていることを確認します。 [サブスクライブ] をクリックして、 msgType MSGTYPE_ALERT という JSON 形式に変換されたメッセージが届くことを確認してください 仮想デバイスで稼働するコードを調べると、メッセージの約 20% が MSGTYPE_ALERT タイプで、メッセージは 5 秒ごとに送信されていることがわかります。警告メッセージが届くまで待つ場合があります。 クリーンアップ このサンプルを実行した後にクリーンアップするには、以下のコマンドを実行します。 # delete the file descriptor object from the Amazon S3 Bucket aws s3 rm s3:// < YOUR_BUCKET_NAME > /msg/filedescriptor.desc # detach all policies from the IoT service role aws iam detach-role-policy --role-name IoTCoreServiceSampleRole \ --policy-arn $( aws iam list-attached-role-policies --role-name IoTCoreServiceSampleRole --query 'AttachedPolicies[0].PolicyArn' --output text ) # delete the AWS CloudFormation Stack aws cloudformation delete-stack --stack-name IotBlogPostSample Bash まとめ 今回の Blog でご紹介したように、AWS IoT Core で Protobuf を操作するのは、SQL ステートメントを書くのと同じくらい簡単です。Protobuf メッセージは、コスト削減 (帯域幅使用量の削減、デバイスの自律性の向上) と、 protoc がサポートするプログラミング言語での開発のしやすさという点の両方において JSON よりも優れています。 AWS IoT Core ルールエンジンを使用して Protobuf 形式のメッセージをデコードする方法の詳細については、 AWS IoT Core のドキュメント を参照してください。 サンプルコードは github リポジトリ https://github.com/aws-samples/aws-iotcore-protobuf-sample にあります。 decode 関数は、Amazon Kinesis Data Firehose にデータを転送する場合に特に便利です。デコードを実行するための AWS Lambda 関数を記述しなくても JSON 入力を受け付けることができるからです。 AWS IoT ルールアクションで利用できるサービス統合の詳細については、 AWS IoT ルールアクションのドキュメント を参照してください。 著者紹介 José Gardiazabal José Gardiazabal は、AWS のプロトタイピングおよびクラウドエンジニアリングチームのプロトタイピングアーキテクトです。プロトタイピングにより AWS 上での可能性を示すことにより、お客様が構築したいシステムの実現ができるようサポートしています。彼は電子工学の学士号とコンピュータサイエンスの博士号を持っています。以前は医療機器とソフトウェアの開発に従事していました。 Donato Azevedo Donato Azevedo は、AWS のプロトタイピングおよびクラウドエンジニアリングチームのプロトタイピングアーキテクトです。AWS 上での可能性を示すことで、お客様の真のポテンシャルを引き出す支援をしています。制御工学の学士号を持ち、以前は石油・ガスおよび金属・鉱業企業の産業オートメーションに従事していました。 この記事はJosé GardiazabalとDonato Azevedoによって書かれた How to build smart applications using Protocol Buffers with AWS IoT Core の日本語訳です。Solutions Architect の 西亀真之 が翻訳しました。

新型コロナウイルスのパンデミックが世界中を席巻する中、大くの組織は世界最大の「在宅勤務」の実験を余儀なくされました。現在に至ってみると、従来のオフィス環境はもはや存在せず、これからはハイブリッドワークやリモートワークが主流になることは明らかです。 フォーブスの国境を越えた従業員調査 によると、10 人に 8 人近くの労働者が、自宅、オフィス、好きな場所など、働く場所の柔軟性を好んでいることが明らかになりました。優秀な人材を確保し、魅力的な企業であるためには、企業が適応しなければならない新しい「規範」が存在することは明らかです。さらに、 リモートワーカーやナレッジワーカーの 75% が、フレキシブルな働き方への期待が高まっていると回答しており、 10 人中 4 人は オフィスに戻ることを求められたら仕事を辞めるかもしれないと回答しています。 ハイブリッドワークやリモートワークのモデルは今後も続くと予想されますが、一部の中小企業はリモートワークの対応に 苦労しています 。セキュリティ、リモート IT サポート、信頼性の低いネットワークはリモートワーカーを管理するうえで重要な技術的課題となっています。特にリモート IT サポートは 中小企業の 46% にとって 深刻な阻害要因となっています。その結果、 ハイブリッド・ファーストのマインドセットを持っているのはわずか 11% で 、37% は成熟したリモートワークを実践していると考えています。 パンデミックからの脱却に伴い、中小企業はハイブリッドワークプレイスをサポートするクラウドに目を向けています。ビデオ会議テクノロジーの利用の伸びが、中小企業がクラウドソリューションを採用する兆候として考えられます。しかし、クラウドには仮想会議ソリューション以上の魅力があります。クラウドサービスを利用することで、遠隔地にいる社員がどこからでも企業のリソースに安全にアクセスできるようになり、 企業のコンテンツの安全性が確保され 、組織内外のドキュメントをリモートで共有したり、コラボレーションするためのツールが提供されています。 リモートワークは、従業員に柔軟性をもたらすだけではないと考える企業が増えています。特定のビジネスツールやプロセスを見直すことで、ビジネスの基本的な進め方を改善するチャンスがあるのです。 このブログでは、先進的な中小企業がアマゾンウェブサービスを活用して、リモートワークの一般的な課題を克服し、従業員の生産性を変革している3つの方法について詳しく説明します。 1. 敏捷性（アジリティ）：リモートワークのスイッチを入れる 次の世界的大流行がいつ起こるかを正確に予測できる人は誰もいません。しかし、適切なインフラストラクチャスタックがあれば、企業は進化するビジネスニーズに俊敏に対応できます。 テクノロジー主導の創薬を専門とする日本の製薬会社、 協和キリン を例にあげてみましょう。何年にもわたってテクノロジーインフラストラクチャを徐々にクラウドに移行してきたため、この製薬会社は、新型コロナウイルスによるロックダウンが始まったとき、わずか1週間で 300～400 台の仮想デスクトップを追加できました。これにより、リモートワークにアクセスできる在宅勤務の従業員の総数は、米国と日本で 1,600 人に達しました。 その結果、協和キリンはビジネスと生産性への混乱を減らすことができました。さらに重要なのは、パンデミック発生前にオンプレミスの仮想デスクトップインフラストラクチャを Amazon WorkSpaces に移行することを決定したことです。 Amazon WorkSpaces は、リモートの従業員にインターネット接続されたあらゆるデバイスから、高速で応答性の高いデスクトップエクスペリエンスを提供する仮想デスクトップソリューションで、 30% のコスト削減につながりました 。 協和キリンの ICT ソリューション部門の責任者である楠本貴幸氏は、「新型コロナウイルスのパンデミックにより、Amazon WorkSpaces の価値を認識しました。ユーザーは、大きな混乱を招くことなく、自宅や仕事からデスクトップ環境を使い続けることができました。」 現在、協和キリンは、未知の将来のシナリオを正確に予測し、それに対処するために、多額の設備投資や時間のかかる計画をたてる必要がなくなっています。AWS への移行により、リモートワークの拡大に必要な俊敏性と費用対効果をが得ることができました。 2. サイバーセキュリティ：デバイスの増加、セキュリティの必要性 リモートワークがもたらす柔軟性と事業継続性とは裏腹に、まだいくつかのリスクがあります。その1つがサイバーセキュリティです。リモートで仕事をする人が増えるにつれて、保護すべきデバイスの数が増えます。この急増は、社内にITスタッフがいるかどうかにかかわらず、中小企業が直面するセキュリティ上の問題という独自の課題をもたらします。従業員が地理的に分散しているため、セキュリティ製品をリモートでインストール、管理、サポートできるようにしなければなりません。 インドに拠点を置き、金融サービス部門に価値の高いリサーチ、分析、ビジネスインテリジェンスを提供する Acuity Knowledge Partners 社 では、最近のリモートワークへの移行時に、データセキュリティの管理が重大なリスクとなりました。同社のアナリストは、これまで包括的なセキュリティ管理がなされていなかったため、社外で仕事をすることができませんでした。 Acuityの最高技術責任者である Sridhar Damala 氏は、次のように語っています。「新型コロナウイルスのパンデミックにより、当社の事業運営方法がすべて変わりました。リモートワークの許可を得るためには、情報をどのように保護するかについて、特定のデータセキュリティ対策を講じて、各クライアントのところに行かなければなりませんでした。WorkSpaces にはその答えがありました。」 WorkSpaces はこれらの「答え」を現実のものにしました。Acuity は、3 週間以内に、 世界中の 1,100 人の従業員を安全かつコンプライアンスに準拠した方法で仮想デスクトップに移行することができました 。 デジタル化が初めての方、中小企業にクラウド機能を追加したい方。AWS Smart Buisness で業種別、メリット別、ユースケース別などのソリューションをご覧ください。 3. スケーラビリティとコラボレーションの促進 リモートワーク環境やハイブリッドワーク環境に移行する中小企業にとって、サイバーセキュリティは必要不可欠ですが、ビジネスが最適に機能するためには、クラウドコンピューティングソリューションに伴う スケーラビリティ 、 信頼性 、 パフォーマンスの向上も必要です。 そのような企業の1つが、オーストラリアの多文化研究およびコミュニケーション機関である The LOTE Agency （LOTE）です。同社の業務には、ビデオ編集やマーケティングアーティファクトの作成などがあり、どちらもコンピューティングとストレージを大量に消費します。LOTE は、従来のオンプレミスシステムを AWS に移行することで、安全で高性能で回復力に優れ、効率的なインフラストラクチャを手に入れました。このインフラストラクチャは、従業員が拠点を置く場所に関係なく、 政府機関の厳しいワークロードの要求に対しても簡単に拡張できます 。 LOTE のゼネラルマネージャーである David Bartlett 氏は、同社が AWS に移行したことでコラボレーションの流動性がどのように向上したかについて語ります。Bartlett 氏は次のように語っています。「ある晩、私はスタッフにオフィスに来ないように言ったのですが、翌朝スタッフはオフィスにいないのにもかかわらず 100% 仕事をすることができました。驚くにはあたりません、それを可能にしたのは、AWS を導入していたからです。」 彼は続けます。「ドバイの多文化分野の専門家は、オーストラリアのデータセンターにあるデータを安全に扱うことができます。AWS 環境内で作業している場合、彼女はファイルをローカルに保存する必要はありません。この柔軟性が、当社の事業拡大と成長を支えています。」 言うまでもなく、AWS クラウドアーキテクチャを基盤としているため、LOTE は新型コロナウイルスによるロックダウン中でも従業員がシステムに安全にアクセスできるようにするうえでほとんど問題に直面しませんでした。さらに、同社はセキュリティ体制の改善により、オーストラリア政府からワクチン展開を支援する大規模な契約を獲得するに至りました。 リモートワーク向けの AWS ソリューション 上記の例では、企業がAWSクラウドインフラストラクチャをいかに簡単に拡張して、変動するリモートワークやハイブリッドワークの形態に対応できるかがお判りいただけたかと思います。AWS クラウドは、運用コストを抑えながら、中小企業 (SMB) に俊敏性、 セキュリティ 、 スケーラビリティ 、 信頼性 を提供します。 AWS を使用することで、従業員、コンタクトセンターのエージェント、クリエイティブプロフェッショナルは、事実上どこからでも生産的に働くことができます。詳しくは、 中小企業向けリモートワーク eBook をご覧いただくか、 AWS のエキスパート にお問い合わせください。 翻訳はソリューションアーキテクトの山﨑 博昭が担当しました。原文は こちら です。

約 30,000 のグローバル価格表から情報を収集し、カタログ化、更新することは、非常に困難な作業です。24 時間 365 日、いつでも利用可能なサービスを提供するには、スケーラブルで信頼性の高いインフラストラクチャが必要です。しかし、それでも中小企業（SMB）はeコマースで成功を目指すことをやめません。ニュージーランドのオークランドに拠点を置く Wine-Searcher は、わずか 85 人のチームでサポートされる世界最大のグローバルワイン検索エンジンを提供しています。Amazon Web Services を利用することで、Wine-Searcher は巨大なチームや無限のリソースを持つことなく、 IT レジリエンスを実現し 、データをより適切に管理できるようになりました。クラウド IT ソリューションによって Wine-Searcher がどのようにグローバルサービスを提供し、新しい機能を追加するために規模を拡大し続けることができるのか、CEO の Jules Perry 氏に話を聞きました。 クラウドによるビジネス課題の解決 Q. Jules, Wine-Searcher はソムリエがたくさんいる会社のようにみえますが、あなたのビジネスの見方は違いますか？どのような会社なのでしょうか？ A. Wine-Searcher は、ワイン、スピリッツ、ビールの世界最大のグローバル検索エンジンおよび価格比較エンジンです。世界中で毎月約 500 万人のユーザーにサービスを提供しています。Wine-Searcher は少し変わっています。名前にはワインが入っていますが、実際はIT組織です。私たちはインターネットビジネスで、世界中からデータを収集し、必要に応じて消費者に提供し、ワインやスピリッツ業界をサポートしています。 Q. Wine-Searcher は、以前は独自のデータセンターを社内に所有していました。どのようにニーズが変化したのですか？ A. 何年もの間、ホスティングビジネスを行う上で最も柔軟で反応性の高い方法は、実際に自分たちで行うことだとわかっていました。だからこそ、コロケーションサービスを運営することにしたのです。私たちは 22 年間、独自のウェブサービスをホストしてきました。よりモダンな環境、拡張性の高い環境、より優れたパフォーマンスと耐障害性を備えた環境に移行する必要があることがわかりました。オンプレミスまたはコロケーションサービスを独自に実行することは、今日の世界ではうまくいきません。 時間の経過とともに、クラウドから利用できるサービスは非常に優れたものになり、自社でできること、そして自社で運用し続けることを凌駕しています。また、ハードウェアから独立しているということは、トレーニングを受けたエンジニアが真夜中に稼働する必要がないということです。クリスマスの日に呼び出しがあったこともありました。そういった苦労から解放され、ハードウェアから解放されるのです。 クラウドセキュリティから始めて、サービスを拡大する Q. AWSと契約された当初は、主にセキュリティに重点を置かれていましたが、そこから急速に拡大していきました。その経験について教えてください。 A. AWS を使用した最初の試みは、オンプレミスとコロケーションサービスに 災害対策ソリューション を提供することでした。つまり、私たちは AWS で何ができるかのか、試していただけだったのです。私たちの経験と、システムがしっかりと機能すること、信頼性が高いこと、使いやすいことという確信に基づいて、すべてのサービスを移行するための計画を立て、実行に移行することができました。 AWS は導入が簡単です。サービスを利用することも、試してみることも、自分で検証することもできます。大きなコミットメントも必要ありません。必要な時に必要なだけ利用する。これは本当に魅力的な提案です。使用した分だけ料金を払い、独自のペースで進めることができます。 クラウド移行のカスタマイズ Q. 多くの中小企業は、データ移行に必要となる労力を懸念しています。経験談をお聞かせください A. AWS に移行する際の課題の 1 つは、どのサービスを採用し、どのような新しいテクノロジーを採用するかを検討することでした。また、既存のものをどのように移行するのかも検討する必要がありました。リフトアンドシフトが当初の移行方法でしたが、これは本当にうまくいきました。私たちが知っていて、理解し、長年にわたってチューニングしてきたすべてのテクノロジーがそのまま残っており、それらが私たちのために機能していたからです、リスクのない移行のようなものでした。 全体として、ウェブベースのサービスの移行を計画し、実行するのには 1 年はかかったと思います。当然ですが、最初に開発環境を移行しました。私たちはLinux、Apache、Oracle、Solr PHP のような非常に典型的な環境を運営しています。私たちはパフォーマンスやスケール、システムの動作、開発者とシステムをつなぐなどの事柄について、ある程度の経験を積むことができました。 デジタル化が初めての方、中小企業にクラウド機能を追加したい方。AWS Smart Buisnessで業種別、メリット別、ユースケース別などのソリューションをご覧ください。 イノベーションと俊敏性の向上 Q. クラウドへの移行によって、当初の予想を上回るビジネス上のメリットを得ることはできましたか? A. 今ではスタッフ全員が、自宅からでも、オフィスからでも、どこにいても、必要な場所で、完全に Amazon WorkSpaces を利用しています。スタッフが どこからでも安全に仕事をするために 、ラップトップ以外の IT 機器は必要ありません。これは本当に驚きです。このソリューションは私たちに信じられないほどの柔軟性を与えてくれます。そして、新型コロナウイルスのパンデミックにより非常に多くの企業が業務を中断せざるを得ませんでしたが、私たちは業務を継続することができました。 クラウドを利用し、独自のテクノロジーをコントロールできるということは、イノベーションを思い通りに自由に実行できるということでもあります。速く動きたければ、速く動く。より慎重に進めたいのであれば、それも可能です。AWS には、新しい分野での実験を可能にする一連のサービスがあります。 Q. Wine-Searcher の将来はどうなるのでしょうか？ A. クラウドを利用することで、新しいことに挑戦する自由がうまれました、挑戦に対処するためのインフラストラクチャを手に入れたからです。また、ダウンタイムやサービスの可用性を心配する必要がないため、より多くのリスクをとることができます。AWS のインフラストラクチャがあることで、更に野心的なチャレンジができるようになりました。AWS のインフラストラクチャがあることで、将来に向けてより大胆になることもできます。さらに、ビジネスの方向性について、より大胆な決断をくだすこともできます。AWS のインフラストラクチャ、リソース、そしてキャパシティがあるからこそ、以前なら考えもしなかったような決断を下すことができるのです。 Next steps クラウドへの移行によは、機敏性を保ち、優れたカスタマーエクスペリエンスを提供したいと考える中小企業は、IT レジリエンスを実現できるようになります。Wine-Searcher は、しっかりとサポートされた移行によって信頼性を向上させ、最終的には将来のイノベーションのためのプラットフォームを提供することができました。クラウドへの移行が、中小規模の eコマースビジネス の確実な拡大にどのように役立つのか、詳細をご覧ください。中小企業のビジネスの専門家と話す準備はできましたか？ 今すぐお問い合わせください 。 翻訳はソリューションアーキテクトの山﨑 博昭が担当しました。原文は こちら です。

電子商取引市場は、過去数年間で年間成長率が大幅に伸びています。顧客の購買行動はオンラインにシフトしていますが、店頭受け取りなどの新しいトレンドも一般的になりつつあります。 米国センサス局によると 、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 をご覧ください。