11月29日は、 Amazon DocumentDB (MongoDB 互換) のベクトル検索 の一般提供についてお知らせします。この製品は、ドキュメントデータベース内でミリ秒の応答時間で何百万ものベクトルを保存、索引付け、検索できる新しい組み込み機能です。 ベクトル検索は、 機械学習 (ML) で使用される新しい手法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータに類似したデータポイントを検索します。ベクトルは、Amazon Bedrock、Amazon SageMaker、およびその他のオープンソースまたは独自の ML サービスでホストされている大規模言語モデル (LLM) から作成された非構造化データを数値で表したものです。このアプローチは、 検索拡張生成 (RAG) モデルアプローチを使用して、直感的な検索、製品推奨、パーソナライゼーション、チャットボットなどの 生成型人工知能 (AI) アプリケーションを作成するのに役立ちます。たとえば、データセットに映画の個別のドキュメントが含まれている場合、単にキーワードを照合するのではなく、「ボート」、「悲劇」、「実話に基づいた映画」などの共有コンテキストに基づいて、 タイタニック に似た映画をセマンティックに検索できます。 Amazon DocumentDB のベクトル検索を使用すると、個別のベクトルデータベースインフラストラクチャを管理する時間とコストをかけることなく、微妙な意味とコンテキストに基づいてデータベースを効果的に検索できます。また、Amazon DocumentDB が提供する、完全に管理された、スケーラブルで、安全で、可用性が高い JSON ベースのドキュメントデータベースも利用できます。 Amazon DocumentDB でベクトル検索を開始する ベクトル検索機能は、Amazon DocumentDB 5.0 インスタンスベースのクラスターで利用できます。ベクトル検索アプリケーションを実装するには、ドキュメント内のフィールドに埋め込みモデルを使用してベクトルを生成し、ソースデータを Amazon DocumentDB 内に並べて保存します。 次に、ベクトルフィールドにベクトルインデックスを作成します。これにより、類似のベクトルを取得しやすくなり、セマンティック検索を使用して Amazon DocumentDB データベースを検索できます。最後に、ユーザーが送信したクエリは、同じ埋め込みモデルを使用してベクトルに変換され、意味的に類似したドキュメントを取得してクライアントに返します。 Amazon DocumentDB でベクトル検索を使用して簡単なセマンティック検索アプリケーションを実装する方法を見てみましょう。 ステップ 1.Amazon Titan 埋め込みモデルを使用してベクトル埋め込みを作成する Amazon Titan 埋め込みモデルを使用して埋め込みベクトルを作成してみましょう 。Amazon Titan Embeddings モデルは、サーバーレスの生成系 AI サービスである Amazon Bedrock で利用できます。インフラストラクチャを管理することなく、単一の API を使用して簡単にアクセスできます。 prompt = "I love dog and cat." response = bedrock_runtime.invoke_model( body= json.dumps({"inputText": prompt}), modelId='amazon.titan-embed-text-v1', accept='application/json', contentType='application/json' ) response_body = json.loads(response['body'].read()) embedding = response_body.get('embedding') 返されるベクトル埋め込みは次のようになります。 [0.82421875, -0.6953125, -0.115722656, 0.87890625, 0.05883789, -0.020385742, 0.32421875, -0.00078201294, -0.40234375, 0.44140625, ...] ステップ 2.ベクトル埋め込みを挿入してベクトルインデックスを作成する insertMany( [{},...,{}] ) オペレーションを使用して、Amazon DocumentDB のコレクションに追加したいドキュメントのリストを使用して、生成されたベクトル埋め込みを追加できます。 db.collection.insertMany([ {sentence: "I love a dog and cat.", vectorField: [0.82421875, -0.6953125,...]}, {sentence: "My dog is very cute.", vectorField: [0.05883789, -0.020385742,...]}, {sentence: "I write with a pen.", vectorField: [-0.020385742, 0.32421875,...]}, ... ]); createIndex コマンドを使用してベクトルインデックスを作成できます。Amazon DocumentDB は、フラット圧縮 (IVFFLAT) ベクトルインデックスを使用した転置ファイルを使用して、近似最近傍検索 (ANN) を実行します。この機能は、ユークリッド、コサイン、内積の 3 つの距離計量をサポートします。ここでは、空間の 2 点間の直線距離の尺度であるユークリッド距離を使用します。ユークリッド距離が小さいほど、ベクトルは互いに近づきます。 db.collection.createIndex ( { vectorField: "vector" }, { "name": "index name", "vectorOptions": { "dimensions": 100, // the number of vector data dimensions "similarity": "euclidean", // Or cosine and dotProduct "lists": 100 } } ); ステップ 3. Amazon DocumentDB からベクトル埋め込みを検索する $search 内の新しい集計パイプライン演算子を使用して、ドキュメント内の類似のベクトルを検索できるようになりました。「 ペットが好き 」を検索するサンプルコードは次のとおりです。 db.collection.aggregate ({ $search: { "vectorSearch": { "vector": [0.82421875, -0.6953125,...], // Search for ‘I like pets’ "path": vectorField, "k": 5, "similarity": "euclidean", // Or cosine and dotProduct "probes": 1 // the number of clusters for vector search } } }); これにより、「 犬と猫が大好き 」などの検索結果が返されます。意味的には似ています。 詳細については、Amazon DocumentDB のドキュメントを参照してください。Amazon DocumentDB によるセマンティックムービー検索など、より実用的な例については、 GitHub リポジトリ にある Python のソースコードとデータセットをご覧ください。 今すぐご利用いただけます Amazon DocumentDB のベクトル検索は、 Amazon DocumentDB が利用可能な すべての AWS リージョンで Amazon DocumentDB 5.0 インスタンスベースのクラスターを使用しているすべてのお客様に追加費用なしで利用できるようになりました。Amazon DocumentDB への埋め込みの保存、インデックス作成、および検索ベクトルには、標準のコンピューティング、I/O、ストレージ、およびバックアップ料金が適用されます。 詳細については、 Amazon DocumentDB のドキュメント を参照してください。フィードバックは、 AWS re:Post for Amazon DocumentDB または通常の AWS サポート連絡先から送信してください。 – Channy 原文は こちら です。

アマゾン ウェブ サービス (AWS) の スマートストアソリューション の出現は、小売業者に新たな可能性を示しました。これらのソリューションを最大限に活用するには、小売業者はネットワークインフラストラクチャを最適化する必要があります。小売業者が業務のデジタル化を進め、より多くのサービスをクラウドに移行するにつれて、セキュリティとネットワークインフラストラクチャが主要な論点となっています。何千ものエンドポイントの管理、セキュリティコンプライアンスの確保、すべての店舗からの迅速かつ安全なクラウドアクセスの提供は、小売業者が直面する課題のほんの一部にすぎません。これらの課題は、世界中に大規模な店舗ネットワークを持つ小売業者にとって特に困難な場合があります。 幸いなことに、これらの課題に対する解決策があります。それは、AWS を使用してネットワークとセキュリティインフラストラクチャを統合し、一元管理することです。グローバルまたは全国規模のネットワークバックボーンを構築し、店舗やビジネスセンターにリーフノードを接続し、すべて AWS が管理することで、小売業者は AWS Cloud WAN を使用して世界中の何千もの店舗を AWS に接続できます。このアプローチは、低レイテンシーで安全な接続を提供するだけでなく、セキュリティの管理と監視を一元化し、すべての店舗で一貫したセキュリティポリシーを実現します。一元管理システムを導入することで、小売業者は各店舗に常駐する IT スタッフを必要とせずに、ネットワークインフラストラクチャを一元的に管理することで、セキュリティ規制の遵守、業務の合理化、コストの削減を実現できます。 ネットワークインフラストラクチャを最適化し、AWS スマートストアソリューションを活用することで、小売業者は収益を向上させながら顧客の店内体験を向上させることができます。たとえば、リアルタイムのデータ分析を使用してショッピング体験をパーソナライズしたり、オンラインとオフラインのチャネルを統合して新しい収益源を創出したり、サプライチェーン業務を最適化したりすることができます。さらに、小売業者は AWS の機械学習機能を活用して、在庫管理を自動化し、店舗のレイアウトと人員配置を最適化し、さらには盗難の検出と防止を行うことができます。 可能性は無限ですが、すべては強固なネットワークインフラストラクチャと信頼できるクラウドプロバイダーがあることが前提です。 店舗側に必要な要件 ほとんどの小売店には、IT チームがリモートから管理する IT 環境があります。これには以下が含まれます。 小売店向け IT ハードウェア: このカテゴリには、サーバー、従業員用 PC 、 Point-of-Sale (POS) コンポーネント、デジタルサイネージ、カメラなどのセキュリティデバイスなど、店舗でよく見かけるデバイスが含まれます。 小売店向け IT ソフトウェア: このカテゴリには、サーバーと PC のオペレーティングシステム、プロダクティビティソフトウェア、ERP ソフトウェア、コミュニケーションアプリケーション、ロイヤルティアプリケーション、e コマース、ビジネスアプリケーション、注文管理ソフトウェアが含まれます。 小売店向け IT サービス: このカテゴリには、サポートサービス、ハードウェアおよびソフトウェア管理、インストール/変更管理、ディザスタリカバリ、カスタムソフトウェア統合/開発が含まれます。 米国全土の 500 を超える店舗の平均を調べたところと、上記のすべてに店舗ごとの費用がかかります。世界中に数千の店舗を展開するような一部の小売業者では、IT 支出は大幅に増加します。 IT コンポーネント 500 を超える店舗の平均 PC 5% ファイアウォール/ルーター/スイッチ 2% 電話システム 6% 社内電話回線 7% サーバー (Windows DC 、SQL) 4% アプリケーションメンテナンス /POS 、スケジューリング、在庫管理、電子メール、その他アプリケーションのアップグレード 20% ブロードバンド接続 3% IT メンテナンスサポート (40 時間/月) 52% データストレージ / バックアップ 1% 合計 一部の小売業者では約 8,000 万ドルになります 表 1 — 小売店舗の IT コスト (ハードウェア、ソフトウェア、サービス) ほとんどの小売業者の IT 支出は年々増加し続けているため、これらのサービスの多くを AWS に統合してコストを削減し、顧客体験への投資を増やすことができます。このようなインフラストラクチャの管理は、特にさまざまな地域にまたがる多数の店舗を扱う場合には困難な場合があります。すべてのハードウェアとソフトウェアが最新で、安全で、正しく機能していることを確認することは、IT チームにとって大変な作業です。 小売業者は、IT インフラストラクチャの管理という課題に加えて、店舗ネットワークの信頼性と安全性を確保し、クラウドベースのサービスに対する需要の高まりに対応できるようにする必要もあります。e コマースの台頭により、顧客はすべてのチャネルでシームレスな体験を期待しており、小売業者はこの体験を実店舗でも提供できなければなりません。そのためには、リアルタイムの在庫管理、顧客分析、パーソナライズされたマーケティングなど、複数のアプリケーションとサービスを支えることのできる堅牢でスケーラブルなネットワークインフラストラクチャが必要です。AWS を使用して ネットワークとセキュリティインフラストラクチャ を統合して一元管理することで、小売業者はこれらの課題を克服し、シームレスでパーソナライズされたショッピング体験を顧客に提供できます。 実店舗のサービスを AWS に移行すると、コスト削減とともに以下のメリットが得られます。 一元化されたセキュリティ 侵入ポイントを減らす一元化されたインターネットアクセス 電話システム/電話回線などの資産を減価償却するための共有リソース 仮想デスクトップインフラストラクチャ (VDI) ソリューションによる安全なデスクトップアプライアンス (最小限の店舗の端末) すべての店舗にまたがるディザスターリカバリソリューション 店舗を横断した在庫管理 IT 人件費の削減 店舗ソリューションの導入 ソリューション概要 スマートストアネットワーキングおよびインフラストラクチャソリューションは、パートナーとの Direct Connect または SD-WAN （Software Defined-Wide Area Network）を使用して、すべての店舗を AWS に接続します。冗長性を確保するため、各店舗には AWS への接続が少なくとも 2 つ必要です。商品のスキャン、支払い処理、領収書の印刷、および店舗の端末用のハードウェアコンポーネントは、プライベート接続を介して AWS サービスに接続できます。 すべての店舗ソフトウェアは、オペレーションサポートのために最も近い AWS リージョンにデプロイする必要があります。これにより、サーバーや店舗ごとのメンテナンスが不要になります。支払い機能のためには、 AWS 仮想デスクトップインフラストラクチャソリューション に接続するゼロクライアントモニターが設置され、店舗アプリケーションがクラウド ERP および POS システムと通信できるようになり、より高い回復力とディザスターリカバリ機能が提供されます。電話交換機 (PBX) サービスは、Asterisk や Sipxcom などのオープンソースソリューションを使用して米国の 2 つのリージョンに統合し、 Amazon Connect と統合することでシームレスな顧客体験を実現できます。 AWS ネットワークインフラストラクチャ AWS ネットワークインフラストラクチャは AWS Cloud WAN を使用して構築され、クラウドネットワークエンジン (CNE) が米国の 4 つのリージョン (us-east-1、us-east2、us-west1、us-west2) のそれぞれにデプロイされます。これにより、4 つのリージョンに関連付けられた Direct Connect ロケーションが、AWS リージョン全体の Amazon Virtual Private Clouds (Amazon VPC) にトラフィックをルーティングできるようになります。 AWS Cloud WAN 内では、セグメントを作成して、各地域の店舗とそれに関連付けられた Amazon VPC ワークロードのトラフィックルールをグループ化できます。これにより、インターネットトラフィックと冗長ワークロードの管理が簡素化され、通信トラフィック用の VOIP セグメント、アプリケーションの開発とテスト用の開発セグメント、ビジネスアプリケーションの本番セグメントなど、アプリケーションとビジネス要件に基づいてネットワークトラフィックをセグメント化できます。このように店舗を地理的セグメントにグループ化することで、地域固有のニーズに基づいてさまざまなサービスを提供することもできます。 セキュリティアーキテクチャについては、すべての店舗のインターネット入出力トラフィックを処理するために、出口用のAmazon VPC が各リージョンに設定されます。出口用の Amazon VPC では、冗長構成でデプロイされたファイアウォールを使用してトラフィックを検査し、ネットワークインフラストラクチャの高度なセキュリティを確保します。 図 1: リファレンスネットワークアーキテクチャ 店舗から AWS への接続 小売業者のネットワーク上の各店舗には、近接性とネットワークプロバイダーのサービスに基づいて選択された 2 つの異なる AWS Direct Connect (Direct Connect) ロケーションへのファイバー接続が 2 つ以上必要です。仮想プライベートネットワーク (VPN) を使用した AWS Cloud WAN への 3 次バックアップ接続は、5G または BB を使用して設定できます。0.0.0.0/0 のルートが Direct Connect または VPN 経由で AWS を指定しているため、店舗からインターネットに直接アクセスすることはできません。AWS Direct Connect サービスプロバイダーに接続するには、各店舗にローカルルーターまたはスイッチが必要です。2 つの Direct Connect 接続は、異なるポイントオブプレゼンス (POP) で接続することをお勧めします。 複数の Direct Connect 接続と VPN バックアップのルート優先順位を管理するには、AWS のベストプラクティスに従って、ローカルルーターでボーダーゲートウェイプロトコル (BGP) を使用する必要があります。各 Direct Connect 接続は、店舗から Direct Connect ロケーションまで 1G で、AWS への Direct Connect ロケーションの帯域幅は、必要な店舗数と帯域幅に応じて 10G です。パケットのスループットを確保するには、帯域幅をオーバープロビジョニングすることをお勧めします。AWS Direct Connect はパケットの優先順位とサービス品質 (QoS) を管理しないため、すべてのパケットには差分サービスコードポイント (DSCP) のマークを付け、送信元で優先順位を付ける必要があります。DSCP マーキングは宛先に渡されます。帯域幅とクラスレスドメイン間ルーティング（CIDR）の計画が実施されている場合、店舗は Direct Connect 接続を追加する前に、まず SD-WAN を使用して AWS に接続できます。 ハイブリッド接続モデル すべての店舗が同じ接続モデルを必要とするわけではありません。店舗は大都市圏、郊外、地方に分類できます。これらのカテゴリではそれぞれ、接続オプションと帯域幅のニーズが異なる場合があります。 店舗から AWS に接続するには、SD-WAN を使用して店舗のローカル Direct Connect ロケーションにある顧客管理のスイッチ/ルーターへのラストマイルを行うハイブリッドアプローチがあります。この方法では、短距離でのパフォーマンスが向上し、レイテンシーが減少します。Direct Connect ロケーションでは、SD-WAN 接続を集約して AWS Cloud WAN に直接接続できます。 ブロードバンド回線を使用する郊外地域の店舗では、店舗接続の集約をローカルゾーンで行うこともできます。仮想 SD-WAN アプライアンスをローカルゾーンにデプロイして、SD-WAN ネットワークをローカル AWS ロケーションに拡張して AWS Cloud WAN に接続できます。全体として、このハイブリッドアプローチにより、店舗から AWS への効率的な接続が可能になります。 各接続モデルは、パフォーマンスと遅延の要件に基づいて最適かどうかをテストする必要があります。 図 2: ハイブリッド接続 店舗のインターネットアクセス 一部の店舗では、インターネットに直接アクセスできない場合があります。インターネット宛のトラフィックはすべて、Direct Connect 経由でインターネット出口用の Amazon VPC に送信されます。ファイアウォールポリシーは、設定されたルールに基づいて、下りの Amazon VPC のインターネットトラフィックに適用されます。インターネット出口用の Amazon VPC は各 AWS リージョンで設定され、トラフィックは各セグメントのルートテーブルを使用してインターネット出口用の Amazon VPC に送られます。 このモデルを利用すると、管理が必要なファイアウォールの数を合計 4 セットに減らすことができます。インターネット出口用の Amazon VPC は AWS Cloud WAN 内の共有サービスセグメントに接続されます。 図 3: ストア接続 マルチクラウド相互接続 Azure 、 GCP 、 SAP などの他のクラウドプロバイダーにデプロイされているワークロードの場合、小売業者はそのクラウドプロバイダーが存在するトランジットポイントへの Direct Connect 接続が必要になります。マルチクラウド接続をサポートする Direct Connect ロケーションを使用することをお勧めします。 これを設定するには、小売業者には次の 2 つの選択肢があります。 AWS Direct Connect 接続と他のクラウド接続を相互接続し、ルーティングを管理するルーターを備えたコロケーションラックを Direct Connect ロケーションにセットアップします。 マルチクラウドをサポートする Direct Connect パートナー と連携します。 どちらのオプションでも、IPv4 CIDR ブロック範囲が重複しないようにする必要があります。また、AWS Cloud WAN のルーティングルールは、トラフィックをマルチクラウドの Direct Connect ロケーションに転送するように適切に設定する必要があります。 マルチクラウドの Direct Connect 接続が設定されている各リージョンでは、マルチクラウド接続との間のすべての経路について、ファイアウォール検査付きのトランジット Amazon VPC を作成することをお勧めします。このファイアウォールはインターネット出口用のファイアウォールとは別のものです。 注:他のクラウドプロバイダーのパートナーサポートによっては、必要に応じて複数の Direct Connect ロケーションを使用して他のクラウドプロバイダーに接続できます。 エッジファイアウォールの設計 このアーキテクチャには以下のファイアウォールが推奨されます。 AWS Network Firewall – AWS Network Firewallは、AWS 内で開始されるすべてのアウトバウンドトラフィックに対して、出口用の Amazon VPC にデプロイされます。アウトバウンドトラフィックとレスポンストラフィックは、設定されたポリシーに基づいて検査されます。AWS Cloud WAN は、すべての Amazon VPC トラフィックを出口用の Amazon VPC 経由で転送するように設定できます。 Multi-Cloud Amazon VPC firewall – このファイアウォールは、AWS を経由して他のクラウドプロバイダー接続に向かうすべてのトラフィックに使用されます。各リージョンでアクティブ/スタンバイの 1 組が設定されます。 AWS WAF with AWS Shield – このファイアウォールは、Web アプリケーションの小売用 Web サーバーに送信されるすべての Web トラフィックに使用されます。これには、外部サポートを必要とするサードパーティーの Software-as-a-Service (SaaS) アプリケーションも含まれます。 一元管理されたファイアウォールマネージャーを使用することをおすすめします。高可用性と障害復旧のためには、複数のリージョンに展開する必要があります。 ローカルゾーン接続 ローカルゾーンは、必要に応じてワークロード用のミリ秒未満のレイテンシーをサポートできます。ローカルゾーンを使用すると、その店舗のリージョンの Amazon VPC は、コンピューティングリソースとストレージリソースをローカルゾーンに拡張できます。今後、サポートされるサービスが増えるにつれて、それらのサービスをローカルゾーンで利用できるようになります。Direct Connect を使用すると、リージョンへルーティングを戻さなくても、店舗のネットワークルーティングをローカルゾーンに直接拡張できます。 各ワークロードを分析して、ローカルゾーンが最適な選択肢かどうかを確認する必要があります。 スマートストアアプリケーション スマートストアアプリケーションには、相互に連携する必要のある店舗内コンポーネントとクラウドベースのコンポーネントの両方があります。たとえば、インタラクティブな統計情報を生成するためのカメラビジョンと人工知能と機械学習（AI/ML）処理の場合、ハードウェアを備えた AI コンポーネントは店舗にあり、データ分析とプレゼンテーションはクラウドで行われる場合があります。そうは言っても、店舗はかさばるハードウェアやサーバーを店舗内に置かず、商品を販売するためのスペースを空けたいと考えています。このような低レイテンシーの重要なソフトウェアの多くは、店舗がある場所の近くのローカルゾーンに導入できます。本ブログで説明されているネットワークアーキテクチャを利用することで、店舗はこの作業の負担を軽減できます。ローカルゾーンからは、店舗の貴重な帯域幅を使用することなく、AWS リージョンでデータを処理できます。 店舗とローカルゾーン間の通信のセキュリティは、プライベートネットワークを使用してローカルゾーンに直接接続するか、ローカルゾーンの仮想アプライアンスへの安全なトンネルを作成する店舗内の SD-WAN ベースのアプライアンスを使用してトラフィックを暗号化することで実現できます。もう 1 つの考慮は、トラフィックの優先順位です。コンピュータビジョン、RFID、スマートキオスク、ロボティクス、VOIP などの複数のスマートストアソリューションをサポートする場合、サービス品質が重要なニーズになります。店舗の帯域幅のニーズがブロードバンドアップリンク容量を超える時が来るでしょう。SD-WAN とDirect Connect のオーバーレイを使用すると、ネットワークエンジニアはビジネスニーズに基づいてトラフィックに優先順位を付けるポリシーを追加できます。このアーキテクチャは、スマートストア機能の有効化をサポートします。 まとめ 結論として、小売店向けの AWS ネットワークインフラストラクチャと接続オプションは、クラウドへの高性能で信頼性の高い接続を提供するように綿密に設計されています。 AWS Direct Connect 、SD-WAN 、ハイブリッドアプローチなど、さまざまな接続オプションがあるため、小売店は自分に最適なオプションを選択できます。さらに、AWS のサービスとベストプラクティスを活用することで、店舗はセキュリティと回復力を向上させながら、オンプレミスのハードウェアとメンテナンスの必要性を減らすことができます。 全体として、このネットワークインフラストラクチャと接続ソリューションは、小売店がクラウドに接続して事業運営をサポートするためのスケーラブルで柔軟かつ効率的な方法を提供します。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns Extending your VPC to Local Zones Smart Stores 著者について Ameel Kamboh Ameel Kamboh は AWS のシニアソリューションアーキテクトで、緊急通報ネットワークをグローバルに構築した経歴があります。ネットワークと複雑なアプリケーションの構築で 28 年以上の経験を持つ Ameel は、高可用性とスケーラビリティに重点を置いて設計してきました。AWS では、Ameel は小売企業部門での活動範囲を広げ、可能性を秘めた芸術をもたらす革新的なソリューションを顧客に提供してきました。 Chris Sereno Chris は AWS のソリューションアーキテクトで、ネットワーク分析のバックグラウンドを持っています。彼は、お客様がパフォーマンスと信頼性の高いアプリケーションを提供できるよう支援することに情熱を注いでいます。予定がないときには、キーボードを使って音楽を作るのを楽しんでいます。 Justin Swagler Justin Swagler は、AWS のフィジカル Retail のワールドワイド・ヘッドであり、フィジカル・リテールのグローバル戦略とソートリーダーシップを率いています。Justin は、イノベーション戦略、小売事業、製品開発、経営幹部など、消費者向けパッケージ商品、小売、戦略において 15 年以上にわたる経験があります。彼は、消費者体験を戦略的に革新し、再発明するよう組織を導くことに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ・スクール・オブ・マネジメントで経営学修士号を取得しています。 Rahul Nammireddy Rahul は AWS のシニアソリューションアーキテクトであり、デジタルネイティブのお客様をクラウドネイティブの変革に導くことに重点を置いています。彼は AI/ML テクノロジーに情熱を傾け、小売や通信などの業界の顧客と協力して、お客様の急速なイノベーションを支援しています。Rahul は 23 年以上にわたるキャリアを通じて、スタートアップ企業から上場企業まで、さまざまな企業で主要な技術指導的役割を果たしてきました。ビルダーとしての専門知識を披露し、イノベーションを推進してきました。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。

11月29日は、新機能を備えた Amazon OpenSearch Serverless 用ベクトルエンジン が一般公開されたことをお知らせします。2023 年 7 月に、Amazon OpenSearch Serverless 用ベクトルエンジンの プレビューリリースを発表 しました。これは、シンプルでスケーラブルで高性能な類似検索機能です。ベクトルエンジンを使用すると、基盤となるベクトルデータベースインフラストラクチャを管理することなく、最新の機械学習 (ML) 拡張検索エクスペリエンスや生成型人工知能 (生成系 AI) アプリケーションを簡単に構築できます。 数千次元の何十億ものベクトル埋め込みをミリ秒単位で保存、更新、検索できるようになりました。ベクトルエンジンの高性能な類似検索機能により、AI を活用した生成型アプリケーションでは、ミリ秒単位の応答時間で、正確で信頼性の高い結果を得ることができます。 また、ベクトルエンジンでは、ベクトル検索と全文検索を同じクエリで組み合わせることで、ハイブリッド検索で結果を最適化および調整できるため、個別のデータストアや複雑なアプリケーションスタックを管理および保守する必要がなくなります。ベクトルエンジンは、安全で信頼性が高く、スケーラブルでエンタープライズ対応のプラットフォームを提供し、プロトタイピングアプリケーションをコスト効率よく構築し、本番環境にシームレスに拡張できます。 専用のベクトルエンジンベースのコレクションを作成することで、ベクトルエンジンをすぐに使い始めることができます。コレクションとは、埋め込みを論理的にグループ化したもので、連携してワークロードをサポートします。 ベクトルエンジンは、 OpenSearch Compute Units (OCU)、つまりコンピュートキャパシティユニットを使用して、類似検索クエリを取り込んで実行します。1 つの OCU は、99 パーセントのリコール率で、128 次元の最大 200 万のベクトル、768 次元の 500,000 のベクトルを処理できます。 OpenSearch サーバーレス上に構築されたベクトルエンジンは、デフォルトでは可用性の高いサービスです。アカウントの最初の収集には、少なくとも 4 つの OCU (プライマリとスタンバイを含む取り込み用に 2 つの OCU、アベイラビリティーゾーン全体に 2 つのアクティブなレプリカがある検索用に 2 つの OCU) が必要です。同じ AWS Key Management Service (AWS KMS) キーを使用する以降のすべてのコレクションは、それらの OCU を共有できます。 GA での新機能とは? プレビュー以降、Amazon OpenSearch Serverless 用ベクトルエンジンは、検索拡張生成 (RAG) コンセプトを使用して生成系 AI アプリケーションを構築するための Amazon Bedrock のナレッジベース のベクトルデータベースオプションの 1 つになりました。 今回の GA リリースの新機能または改善された機能は次のとおりです。 冗長レプリカ (開発とテストに重点を置く) オプションを無効にする プレビューブログ記事 でお知らせしたように、この機能により、可用性のためだけに別のアベイラビリティーゾーンに冗長な OCU を用意する必要がなくなります。コレクションには 2 つの OCU (1 つはインデックス用、もう 1 つは検索用) を使用してデプロイできます。これにより、冗長レプリカを使用するデフォルトのデプロイと比較して、コストが半分に削減されます。コスト削減のため、この構成は開発およびテストワークロードに適しており、経済的です。 このオプションでも、ベクトルエンジンが Amazon S3 のすべてのデータを保持するため、耐久性は保証されますが、シングル AZ に障害が発生すると、可用性に影響が及びます。 冗長レプリカを無効にする場合は、新しいベクトル検索コレクションを作成するときに [冗長性を有効にする] のチェックを外してください。 開発とテストに重点を置いたオプション用のフラクショナルOCU 開発とテストに重点を置いたワークロードに対して OCU の部分課金をサポートする (つまり、冗長レプリカオプションがない) ため、ベクトル検索コレクションの最低価格が下がります。ベクトルエンジンは、最初は小さい 0.5 OCU を導入しながら、同じ機能を低スケールで提供し、ワークロードの需要に合わせてフル OCU 以上までスケールアップします。このオプションを使用すると、ベクトルエンジンを試す際の月額コストをさらに削減できます。 10 億スケールの自動スケーリング ベクトルエンジンのシームレスな自動スケーリングにより、スケーリングのためにインデックスを再作成する必要がなくなります。プレビューでは、約 2,000 万のベクトル埋め込みをサポートしていました。ベクトルエンジンが一般公開されたことで、10 億のベクトルスケールをサポートできるよう制限を引き上げました。 今すぐご利用いただけます Amazon OpenSearch Serverless 用ベクトルエンジン は、Amazon OpenSearch Serverless が利用可能なすべての AWS リージョンで利用できるようになりました。 はじめに、次のリソースを参照してください。 Amazon OpenSearch Serverless 用ベクトルエンジンのご紹介 (現在プレビュー中) Amazon OpenSearch Service のベクトルエンジンでセマンティック検索を試してみる Amazon OpenSearch Service のベクトルデータベース機能の説明 OpenSearch をベクトルデータベースとして使う Amazon OpenSearch Serverless 入門ドキュメント デモビデオ: ベクトル検索用の Amazon OpenSearch Service デモビデオ: 検索機能の強化: OpenSearch と一括ベクトル検索 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 – Channy 原文は こちら です。

11月29日は、 Amazon SageMaker HyperPod を紹介します。この製品は、大規模な分散トレーニング専用のインフラストラクチャを提供することで、基盤モデル (FM) のトレーニング時間を短縮するのに役立ちます。SageMaker がクラスターの状態をアクティブに監視し、障害のあるノードを交換してチェックポイントからモデルトレーニングを再開することで、ノードとジョブの回復を自動化しながら、SageMaker HyperPod を使用して FM を数週間から数か月間トレーニングできるようになりました。 クラスターには、SageMaker の分散トレーニングライブラリがあらかじめ設定されています。これにより、トレーニングデータとモデルをすべてのノードに分割して並列処理し、クラスタのコンピューティングとネットワークインフラストラクチャを最大限に活用できます。追加のフレームワーク、デバッグツール、最適化ライブラリをインストールすることで、トレーニング環境をさらにカスタマイズできます。 SageMaker HyperPod を使い始める方法を紹介します。次のデモでは、SageMaker HyperPod を作成し、 AWS ML トレーニングリファレンスアーキテクチャ GitHub リポジトリで共有されている例を使用して Llama 2 7B モデルをトレーニングする方法を示します。 クラスターの作成と管理 SageMaker HyperPod 管理者は、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用してクラスターを作成および管理できます。  コンソールで 、 Amazon SageMaker に移動し、左側のメニューの [HyperPod クラスター] で [クラスター管理] を選択し、その後 [クラスターの作成] を選択します。 以下のセットアップでは、クラスター名を指定し、選択したインスタンスタイプと各インスタンスグループに割り当てるインスタンスの数でインスタンスグループを設定します。 また、クラスターの作成時に各インスタンスグループで実行するライフサイクルスクリプトを 1 つ以上準備して Amazon Simple Storage Service (Amazon S3) バケットにアップロードする必要があります。ライフサイクルスクリプトを使用すると、クラスター環境をカスタマイズし、必要なライブラリとパッケージをインストールできます。SageMaker HyperPod のライフサイクルスクリプトの例は、GitHub リポジトリにあります。 AWS CLI を使用する AWS CLI を使用してクラスターを作成および管理することもできます。このデモでは、JSON ファイルでクラスター構成を指定します。2 つのインスタンスグループを作成することにしました。1 つは「controller-group」と呼ばれるクラスターコントローラーノード用で、もう 1 つは「worker-group」と呼ばれるクラスターワーカーノード用です。 モデルトレーニングを行うワーカーノードには、 AWS Trainium チップを搭載した Amazon EC2 Trn1 インスタンスを指定します。 // demo-cluster.json { "InstanceGroups":[ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "lifecycleConfig": { "SourceS3Uri": "s3://<your-s3-bucket>/<lifecycle-script-directory>/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/my-role-for-cluster", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group", "InstanceType": "trn1.32xlarge", "InstanceCount": 4, "lifecycleConfig": { "SourceS3Uri": "s3://<your-s3-bucket>/<lifecycle-script-directory>/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/my-role-for-cluster", "ThreadsPerCore": 1 } ] } クラスターを作成するには、次の AWS CLI コマンドを実行します。 aws sagemaker create-cluster \ --cluster-name antje-demo-cluster \ --instance-groups file://demo-cluster.json 作成時に、 aws sagemaker 記述クラスター と aws sagemaker リストクラスターノード を使用して、クラスターとノードの詳細を表示できます。コントローラーノードのクラスター ID とインスタンス ID を書き留めます。クラスターに接続するには、その情報が必要です。 また、 Amazon FSx for Lustre などの共有ファイルシステムをアタッチすることもできます。FSx for Lustre を使用するには、 Amazon Virtual Private Cloud (Amazon VPC) 設定を使用してクラスターをセットアップする必要があります。これは SageMaker VPC を作成する方法と Lustre に FSx をデプロイ する方法を示す AWS CloudFormation テンプレートです。 クラスターに接続するには、 クラスターユーザーは、クラスター管理者によってプロビジョニングされたクラスターにアクセスできる必要があります。アクセス権限を設定したら、SSH を使用してクラスターに接続し、ジョブをスケジュールして実行できます。プリインストールされている AWS Systems Manager 用の AWS CLI プラグイン を使用して、クラスターのコントローラノードに接続できます。 デモでは、コントロールノードのクラスター ID とインスタンス ID をターゲットとして指定して、次のコマンドを実行します。 aws ssm start-session \ --target sagemaker-cluster:ntg44z9os8pn_i-05a854e0d4358b59c \ --region us-west-2 Slurm を使用してクラスターでジョブをスケジュールして実行する 発売時には、SageMaker HyperPod は Slurm によるワークロードオーケストレーションをサポートしています。Slurm は人気のあるオープンソースのクラスター管理およびジョブスケジューリングシステムです。クラスター作成の一環として、ライフサイクルスクリプトを使用して Slurm をインストールして設定できます。ライフサイクルスクリプトの例はその方法を示しています。次に、標準の Slurm コマンドを使用してジョブをスケジュールし、起動できます。アーキテクチャの詳細と役立つコマンドについては、 Slurm クイックスタートユーザーガイド をご覧ください。 このデモでは、 AWS ML トレーニングリファレンスアーキテクチャ GitHub リポジトリにあるこの例 を使用して、Trn1 インスタンスを使用して Slurm で Llama 2 7B をトレーニングする方法を示しています。私のクラスターはすでに Slurm でセットアップされており、Lustre ファイルシステムの FSx がマウントされています。 注意 Llama 2 モデルは Meta によって管理されています。 Meta リクエストアクセスページ からアクセスをリクエストできます。 クラスター環境のセットアップ SageMaker HyperPod は、 Conda 、 venv 、 Docker 、 enroot など、さまざまな環境でのトレーニングをサポートしています。 README の指示に従って、仮想環境 aws_neuron_venv_pytorch を構築し、Trn1 インスタンスでモデルをトレーニングするための torch_neuronx と neuronx-nemo-megatron ライブラリをセットアップしました。 モデル、トークナイザー、データセットの準備 指示に従って Llama 2 モデルとトークナイザーをダウンロードし、モデルを Hugging Face 形式に変換します。次に、 RedPajama データセット をダウンロードしてトークン化します。最後の準備ステップとして、モデルトレーニングをスピードアップするために、事前 (AOT) コンパイルを使用して Llama 2 モデルをプリコンパイルします。 クラスターでジョブを起動する これで、 sbatch コマンドを使用してモデルトレーニングジョブを開始する準備ができました。 sbatch --nodes 4 --auto-resume=1 run.slurm ./llama_7b.sh squeue コマンドを使用してジョブキューを表示できます。トレーニングジョブが実行されると、SageMaker HyperPod の復元機能が自動的に有効になります。SageMaker HyperPod は、前述のコマンドに示すように、ハードウェア障害を自動的に検出し、必要に応じてノードを交換し、 自動再開 パラメーターが設定されている場合はチェックポイントからトレーニングを再開します。 モデルトレーニングジョブの出力は、次のファイルで確認できます。 tail -f slurm-run.slurm-<JOB_ID>.out モデルトレーニングが開始されたことを示すサンプル出力は、次のようになります。 Epoch 0: 22%|██▏ | 4499/20101 [22:26:14<77:48:37, 17.95s/it, loss=2.43, v_num=5563, reduced_train_loss=2.470, gradient_norm=0.121, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.40] Epoch 0: 22%|██▏ | 4500/20101 [22:26:32<77:48:18, 17.95s/it, loss=2.43, v_num=5563, reduced_train_loss=2.470, gradient_norm=0.121, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.40] Epoch 0: 22%|██▏ | 4500/20101 [22:26:32<77:48:18, 17.95s/it, loss=2.44, v_num=5563, reduced_train_loss=2.450, gradient_norm=0.120, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.50] モデルトレーニングジョブをさらに監視してプロファイリングするには、 SageMaker がホストする TensorBoard やその他の任意のツールを使用できます。 今すぐご利用いただけます SageMaker HyperPod は、本日より AWS リージョンの米国東部 (オハイオ州)、米国東部 (バージニア州北部)、米国西部 (オレゴン州)、アジアパシフィック地域 (シンガポール)、アジア太平洋地域 (シドニー)、アジアパシフィック地域 (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) でご利用いただけます。 詳細はこちら。 価格情報とサポートされているクラスターインスタンスタイプのリストについては、 Amazon SageMaker HyperPod を参照してください デベロッパーガイド をご覧ください AWS マネジメントコンソールにアクセスして、SageMaker HyperPod で FM のトレーニングを開始してください –  Antje PS: AWS でブログ記事を書くのは、投稿タイトルの下に名前が 1 つしかない場合でも、常にチームの努力が必要です。今回は、 Brad Doran 、 Justin Pirtle 、 Ben Snyder 、 Pierre-Yves Aquilanti 、 Keita Watanabe 、 Verdi March の各氏に、サンプルコードの提供や、大規模モデル学習インフラ、Slurm、SageMaker HyperPod の管理に関する専門知識の共有など、惜しみない協力をいただきました。 原文は こちら です。

11月29日、 アンソロピックのクロード2.1 ファンデーションモデル (FM) が Amazon Bedrock で発売されたことをお知らせします。先週、Anthropic は最新モデルである クロード 2.1 を発表しました。これは、業界をリードする200,000トークンのコンテキストウィンドウ (クロード 2.0の2倍)、幻覚発生率の低減、長い文書の精度の向上、システムプロンプト、関数呼び出しとワークフローオーケストレーションのためのベータツール使用機能など、企業向けの主要な機能を提供します。 Amazon Bedrock でクロード 2.1が利用可能になったことで、Anthropic のより正直で信頼性の高い AI システムを使用して、 エンタープライズ対応のジェネレーティブ人工知能 (AI) アプリケーションを構築できます。Anthropic が提供する クロード 2.1 モデルを Amazon Bedrock コンソール で使用できるようになりました。 Amazon Bedrock の新しいクロード2.1モデルに関する主なハイライトは次のとおりです。 200,000トークンのコンテキストウィンドウ — エンタープライズアプリケーションでは、製品ガイド、技術文書、財務諸表、法的声明などの長い文書を扱う場合、より大きなコンテキストウィンドウとより正確な出力が必要になります。クロード 2.1は20万トークンをサポートしています。これは約15万語、つまり500ページを超える文書に相当します。豊富な情報をクロードにアップロードすると、要約、質疑応答、傾向の予測、複数の文書の比較対照が可能になり、事業計画の立案や複雑な契約の分析が可能になります。 精度の大幅な向上 — クロード 2.1 では、クロード 2.0 と比較して、幻覚発生率が2倍低下し、自由形式の会話やドキュメント Q&A での幻覚が 50％ 減少し、不正回答が 30％ 減少し、文書が特定の主張を裏付けていると誤って結論付ける割合が 3〜4 倍減少するなど、誠実さも大幅に向上しました。クロードは自分が知らないことを知るようになり、幻覚を起こすよりも反論する可能性が高くなります。この精度の向上により、顧客や従業員向けに、より信頼性の高いミッションクリティカルなアプリケーションを構築できます。 システムプロンプト — クロード 2.1では、システムプロンプトがサポートされるようになりました。これは、ロールプレイングシナリオ、特に長時間の会話でのキャラクターの深みと役割の順守の向上、ガイドライン、ルール、指示の厳守など、さまざまな方法で Claude のパフォーマンスを向上させる新機能です。これは構造的な変化を表していますが、クロードの以前の促し方からの内容の変化ではありません。 関数呼び出しとワークフローオーケストレーションのためのツールの使用 — ベータ機能として提供される クロード 2.1 は、既存の社内プロセス、製品、API と統合して、生成的な AI アプリケーションを構築できるようになりました。クロード 2.1は、追加のナレッジソースからデータを正確に取得して処理するだけでなく、特定のタスクの関数を呼び出します。 クロード 2.1 では、プライベート API や ウェブ 検索 API を使用してデータベースを検索して質問に答えたり、自然言語のリクエストを構造化された API 呼び出しに変換したり、製品データセットに接続してレコメンデーションを行ったり、顧客の購入を支援したりすることができます。この機能へのアクセスは現在、一部の早期アクセスパートナーに限定されており、近い将来にオープンアクセスが予定されています。早期アクセスに興味がある場合は、AWS アカウントチームにお問い合わせください。 クロード2.1の特徴と機能の詳細については、 Amazon Bedrock の Anthropic クロードと Amazon Bedrock のドキュメント をご覧ください。 クロード2.1のアクション Amazon Bedrock で クロード 2.1 を使い始めるには、 Amazon Bedrock コンソールにアクセスしてください 。左下のペインで モデルアクセス を選択し、右上の モデルアクセスの管理 を選択し、ユースケースを送信して、Anthropic クロード モデルへのモデルアクセスをリクエストします。モデルにアクセスするには数分かかる場合があります。既にクロード モデルにアクセスできる場合は、クロード 2.1 へのアクセスを別途リクエストする必要はありません。 チャットモードで クロード 2.1 をテストするには、左側のメニューペインの プレイグラウンド で テキスト または チャット を選択します。次に Anthropic を選択し、次に クロード v2.1を選択します 。 API リクエストを表示 を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK のコード例を使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルは次のとおりです。 $ aws 岩盤ランタイム呼び出しモデル\       --model-id anthropic.claude-v2:1 \       --body "{\"prompt\":\"Human: \\n\\nHuman: Tell me funny joke about outer space!\n\nAssistant:", "max_tokens_to_sample": 50}' \       --cli-binary-format raw-in-base64-out \       invoke-model-output.txt Claude 2.1 モデルで提供されるシステムプロンプトエンジニアリング手法を使用できます。この手法では、その内容を参照または利用する質問の前に、入力やドキュメントを配置します。入力には、自然言語テキスト、構造化文書、 <document> 、 <papers> 、 <books> 、または タグを使用したコードスニペットなどがあります。チャット履歴などの会話テキストや、チャンク化されたドキュメントなどの検索拡張生成 (RAG) 結果を使用することもできます。 これは、サポートエージェントが企業文書に基づいて顧客の質問に回答するためのシステムプロンプトの例です。 タスクで参照できるドキュメントは次のとおりです。 <documents>  <document index="1">   <document_content>   (文書のテキストコンテンツ-一節、ウェブページ、記事などが考えられます)    </document_content> <document index="2">   <source>https://mycompany.repository/userguide/what-is-it.html</source> </document> <document index="3">   <source>https://mycompany.repository/docs/techspec.pdf</source>  </document> ... </documents> あなたはラリーで、会社の製品について深い知識を持つカスタマーアドバイザーです。ラリーは、顧客がナンセンスなことを言ったり、皮肉っぽいことを言ったりしても、顧客に対して非常に忍耐強いです。ラリーの答えは丁寧ですが、時には面白いこともあります。しかし、彼は会社の製品に関する質問に答えるだけで、他の質問についてはあまり知りません。提供されているドキュメントを使用して、ユーザーの質問に答えてください。 人間: 私が操作すると、あなたの製品は奇妙なスタッター音を出しています。何が問題なの? Amazon Bedrock のプロンプトエンジニアリングの詳細については、Amazon Bedrock のドキュメントに含まれている プロンプトエンジニアリングガイドライン を参照してください。クロードを含む Amazon Bedrock テキストモデルの一般的なプロンプトテクニック、テンプレート、例を学ぶことができます。 今すぐご利用いただけます クロード 2.1 は現在、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。 支払いは実際に使用した分のみで、オンデマンドモードでは時間ベースの契約は不要です。テキスト生成モデルでは、処理された入力トークンと生成されたすべての出力トークンに対して課金されます。または、時間ベースの契約と引き換えに、アプリケーションのパフォーマンス要件を満たすのに 十分なスループット をプロビジョニングすることもできます。詳細については、「 Amazon Bedrock 価格設定 」を参照してください。 Anthropic Claude 2.1 を今すぐ Amazon Bedrock コンソールで試して、Amazon Bedrock の AWS re にフィードバックを投稿するか、通常の AWS サポートの連絡先を通じて投稿してください。 — チャニー 原文は こちら です。

本稿では  カヤバ株式会社 （以下、カヤバ）において、データとデジタル技術を活用できるデジタル人財の育成を目指し、AI ハッカソンなどを活用して教育の体系化・内製化を推し進めた取り組みについてご紹介します。 この取り組みについてより詳しくご覧になりたい方は カヤバ技報 第66号 デジタル人財育成の取組み  もご覧ください。（カヤバでは社員は会社の「財産」との認識があり、「人材」を「人財」と称しています） また本活動と並行して実施した、内製化によるシステムモダナイゼーションの取り組みについては こちら でご紹介しています。 デジタル人財育成の必要性 カヤバは、四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。これまでに予知保全システムでのクラウド利用をきっかけとして 2017 年より AWS 上で クラウドネイティブな IoT プラットフォーム を構築し、社員が場所や時間の制約を受けることなく柔軟にデータを活用できる、コスト効率に優れた基盤を提供してきました。 カヤバでは 2019 年に設立された DX 推進部（現、デジタル変革推進本部）が旗振り役となり、ロードマップとして独自に6段階からなるデータ活用のステップを定義し、デジタルトランスフォーメーションを加速を目指しています。 図: データ活用ステップ 個人に依存したデータ活用から、あらゆる社員がデータを利用できる民主化、データ主導の意思決定を経て、ビジネスモデルの変革に至るこのステップを滞りなく進めるためには、システムの整備だけではなく、それを活用できる人財の育成が必要不可欠です。カヤバでは目指すべきデジタル人財を「デジタル技術を扱うテクノロジースキルとビジネス変革スキルを兼ね備えた人財」と定義し、特に重点的な育成が必要な分野と位置付けた AI (Artificial Intelligence) および BI (Business Intelligence) について、社員一人一人が次に目指すべきレベルを明確化するためにスキル別の階級策定表を策定し、また成長を支援するための教育計画を策定し、年間を通じて教育プログラムを提供しています。   図: デジタル人財 スキル別の階級策定表 図: デジタル人財育成の教育計画 AI 人財育成の取組み カヤバでは上記教育計画に基づいて、AI および BI の人財育成に重点的に取り組んでいますが、ここではそのうち AI に関する取り組みについてご紹介します。 AI人財育成では「AI教育カリキュラム」および「AIコミュニティ」の 2 つが活動の主たる柱となっています。 AI教育カリキュラム AI教育カリキュラムは知識や技術の習得を目的として、基礎理論からサービス化を視野に入れた実践的な内容までを網羅的にカバーしています。データサイエンティストやデータエンジニア、機械学習エンジニアが相互に円滑なコミュニケーションをとりながら技術的に連携できるよう、すべての受講生に対して MLOps を考慮した教育カリキュラムの提供を目指しており、2022年はAI基礎、プログラミング基礎、AWS基礎、AI実践の4種類の講座と、AIハッカソンプログラムを展開しました。AIハッカソンについては後述します。 AIコミュニティ AIコミュニティは、製品開発や生産技術など様々な領域から集まった人財がAI/MLに関する知識や技術について意見を交換しています。チャットツール上で社員がオープンに交流する場を提供し、またグループワークとして日頃の開発業務で抱えている具体的な課題を募集し、メンバが協力して解決を試みるなどの試みを行なっています。 AI ハッカソン 通年の教育カリキュラムで習得した知識や技術をチーム単位でアウトプットするイベントとして、2022 年より AWS の支援を得て AI ハッカソンを開催しています。 ハッカソンでは DX 推進部が運営主体となり、参加者は4人毎のチームを組んで運営から提供された仮想の課題に対して協力して機械学習によるソリューションの開発を行います。この活動では、単に機械学習モデルを実装するだけでなく、機械学習モデルの運用の仕組みや、AWS が提唱する Well-Architectedフレームワークへの適合なども課題として採用しました。2022年度は DX 推進部を含む 5 部署から計 16 名の社員が AI ハッカソンに参加し、3 ヶ月の活動期間中は週次のオフィスアワーとして AWS のソリューションアーキテクトへ自由に相談できる場を用意することで、チームが検討している設計や機械学習に関する実装上の不明点の解決をサポートしました。 ハッカソンの最後に実施した成果発表会では、カヤバの経営層や AWS 社が参加し、チーム毎に機械学習モデルの実装結果や機械学習システムの設計に関する工夫点を発表しました。 図: 成果発表会資料 2023年には、2022年のAIハッカソン受講生が担当する開発テーマの中から 2 つがプロジェクト化され、実証実験 (PoC: Proof of Concept) が開始されました。生産領域から製造ラインの外観検査におけるMLOps基盤の開発を、製品領域からCAEとAIを融合させたサロゲートモデルの活用基盤の開発に着手し、2024年から順次、運用を見込んでいます。 図：製造ラインの外観検査におけるMLOps基盤 図：サロゲートモデルの活用基盤 まとめ・今後について 本稿では，カヤバにおけるデジタル人財育成の取組みをご紹介しました。カヤバでは教育の目的は、社員が習得した知識や技術を日頃の開発業務に応用し、ビジネスに貢献することで初めて達成されると考えています。カヤバは今後も社内のデータ活用事例を増やし、DXの実現に向けて世の中のトレンドを意識しながら，必要な教育カリキュラムを展開・拡大していく予定です。   本稿はソリューションアーキテクト 内田、石井が担当し、カヤバ株式会社 デジタル変革推進本部 宮内 悠樹との共同執筆です。デジタル人材育成に取り組む方の参考となれば幸いです。 カスタマープロフィール: カヤバ株式会社 (KYB Corporation) 1919 年創業、設立1948 年。従業員数: 13,920名（2023年度・連結）四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。

本稿では  カヤバ株式会社 （以下、カヤバ）のデジタル変革推進本部が中心となり、オンプレミスに存在したシステム群を内製化によってクラウドネイティブなアーキテクチャへと移行した、モダナイゼーションの取り組みについてご紹介します。 また本活動と並行して教育の体系化・内製化を推し進めた取り組みについては こちら でご紹介しています。 移行の背景と課題 カヤバは、四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。これまでに予知保全システムでのクラウド利用をきっかけとして 2017 年より AWS 上で クラウドネイティブな IoT プラットフォーム を構築し、社員が場所や時間の制約を受けることなく柔軟にデータを活用できる、コスト効率に優れた基盤を提供してきました。 カヤバでは社内のデジタルトランスフォーメーションを加速することを目的として 2019 年に DX推進部（現在のデジタル変革推進本部）を設立し、その活動の一環として古くから長期稼働しているシステムの次世代化を推進してきました。この活動の一環として、2021 年下期に品質データ管理システムが内製化の対象に選ばれ、検討が始まりました。品質データ管理システムは、製品のトレーサビリティを実現するものであり、工場設備や試験機から収集された製品の加工条件や試験計測値などの品質情報を保存しています。旧来のシステムはオンプレミスで運用されており、主に3つの課題に直面していました。 課題1. メンテナンスコスト 20年以上稼働する当該システムは必ずしも正しく文書化されておらず、機能の修正や追加をする際にソースコードを直接確認しなければならないケースが頻発していました。また、Oracle Database をはじめとする商用ソフトウェアのサポートサービス費用がメンテナンスコスト最適化の足枷せとなっていました。 課題2. 可用性とセキュリティ 旧来のシステムは冗長化されていないサーバーコンポーネントが存在したことでシステムダウンを招くことがあり、また DR (Disaster Recovery: 災害復旧 ) 対策の不完全さによって広域災害時に業務が停止するリスクを抱えていました。また 2018 年には従業員によるコンプライアンス上の問題が露見し、改ざんをはじめとするデータベースの不正操作を検知する仕組みの導入も急務となっていました。 課題3. パフォーマンス 品質データ管理システムで使用しているデータベースは 20 年前の設計時と比較して取り扱うデータ量が拡大しており、最低限の正規化しか行われていない大福帳型のスキーマ構造では周辺システムとのデータ連携を行う際に十分なパフォーマンスを提供することができませんでした。 以下のアーキテクチャ図は、旧来のオンプレミスシステムの主要なコンポーネントを表したものです。 図: オンプレミスシステムのアーキテクチャ 前述の課題を解決するため、次のようなソリューションを検討し、適用しました。 1. サーバーレスサービスの活用 メンテナンスコストの課題への対策として、AWS の各種サーバーレスサービスの活用を推進しました。従来、ファイルサーバー上から別のサーバーへファイルを転送して処理していたアーキテクチャを、Amazon S3 や AWS Lambda を活用するアーキテクチャに変更することで、個々のサーバーに対するパッチ適用など運用工数を削減することができました。またサービスが提供するAWSリージョン内での冗長性やリージョン間のデータ連携機能等を活用することで広域災害への対応を強化することができました。リアーキテクチャにあたっては改修工数が発生しましたが、改修に要した期間はオンプレミスを前提とした予測よりも短期で完了することができました。 2. Amazon Quantum Ledger Database (Amazon QLDB) の導入 データの改ざん防止に適したフルマネージド型の台帳データベースである Amazon QLDB を導入しました。Amazon QLDB に品質データを保存することによって、完全かつ検証可能な変更履歴を長期に渡って保持し、管理者を含むあらゆる権限でのデータの変更を確実に追跡することが可能となりました。Amazon QLDB  に品質データのマスタを格納することに加え、社内ユーザーのニーズに応えるために複数の AWS サービスとの組み合わせでソリューションを提供しました。例えば、オンプレミス環境での SQL 検索の需要に応えるために、Amazon QLDB から Amazon Aurora PostgreSQL へデータを同期し、SQL 検索が可能になるようにしました。さらに、可視化の要望に応えて Tableau でダッシュボードを構築しました。SQL 検索機能に関しては、Amazon QLDB とのデータ連携に Amazon Kinesis Data Streams を使用し、データの順序保証には AWS Step Functions と AWS Lambda を利用した実装を行いました。 3. Amazon Aurora PostgreSQL の導入 周辺システムとの連携でパフォーマンスの課題が発生していたデータベースを、Amazon Aurora PostgreSQL に移行されました。また Amazon Aurora Global Database によってデータベースをリージョン間にレプリケーションすることで、今後の予定されている世界中の拠点からの利用拡大に際しても、アプリケーションからネットワーク上の距離が近い場所からデータを提供することが可能になりました。移行に際してはスキーマの正規化やコード体系の見直しも合わせて実施したことで、複数のシステム間でのデータ連携もスムーズに行うことができるようになりました。 これらの対策を取り入れ、新たに構築したシステムのアーキテクチャは以下の通りです。 図: クラウド上に新たに構築したアーキテクチャ 導入効果と今後の展望 前述の三つの課題（メンテナンスコストの増加、可用性とセキュリティ、パフォーマンス）を解決し、コストの最適化、システムの信頼性の向上、パフォーマンスの向上を実現しました。2023 年 9 月からは一部の工場での本格稼働を開始し、国内外での展開を計画中です。導入効果として、コスト面では従来のオンプレミス環境と比較して 5 年間で約 80% の削減が見込まれており、この削減には Oracle Database から Amazon Aurora PostgreSQL への変更、そしてアーキテクチャのサーバーレス化が寄与しています。 次の図はオンプレミスからクラウドへの移行パターンを示しています。今回の移行では、紫色の線で表されたリファクタの戦略を採用しました。単なるリホスト（Lift and Shift、オレンジ色の線）と比べると、リファクタには多くの工程を要することに気づかれるかもしれません。特に再設計が必要な箇所は高度な知識を要し、既存の設計と実装に加えて AWS の仕様に精通していることも求められました。このプロジェクトを実質約 1 年で内製化し成功させた実績は、品質データ管理システムに留まらず、他のシステムへも応用可能であると信じており、将来的にはサーバーコストを大きく削減できると考えています。 図: AWS への移行戦略 本稿はソリューションアーキテクト 内田、石井が担当し、カヤバ株式会社 デジタル変革推進本部 古川 輝との共同執筆です。Amazon QLDB をはじめとするAWSのマネージドサービスを活用したモダナイゼーションに取り組む方の参考となれば幸いです。 カスタマープロフィール: カヤバ株式会社 (KYB Corporation) 1919 年創業、設立1948 年。従業員数: 13,920名（2023年度・連結）四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。

コンビニエンスストアという名前からもわかるように、コンビニエンスストアは速く便利なことを目的としています。 平均的な消費者が店内で過ごす時間は 3~4 分です 。ほとんどの消費者が店に入るときには、すでに何を買うか決めてます。 しかし、その利便性は、消費者が長いレジの行列を見たときに台無しになることがあります。残念ながら、消費者の「長い」という認識は必ずしも寛容ではありません。ある 調査 では、消費者の 15% が 1 分以上待たされると、必需品でないものの購入を諦めることがわかりました。彼らの半数は、わずか 30 秒待っただけで店を出て行くと言いました。 しかし、テクノロジーによって 30 秒の待ち時間を解消することができます。Amazon の Just Walk Out テクノロジー は、この便利さを実現した例です。 Just Walk Out テクノロジーが実装された店舗では、消費者は必要なものを手に取り、ただ出ていくだけでいいのです – レジに並ぶ必要は全くありません。Amazon は、自社のコンビニエンスストアである Amazon Go だけでなく、旅行小売、スポーツスタジアム、ライブイベント会場などのサードパーティーが運営するコンビニエンスストアおよび、コンビニ企業向けにこのテクノロジーを実装しました。 Amazon の Just Walk Out テクノロジー担当バイスプレジデントである Jon Jenkins は、「 Just Walk Out テクノロジーは、コンビニエンスストア運営者がコンシューマージャーニーのビジョンを設定できるようにすると同時に、迅速で便利なショッピング体験という目的を達成するのに役立つ」と説明しました。「コンビニエンスストアには、エンドツーエンドの店舗ジャーニーを柔軟に設計してもらいたいと考えています。コンビニエンスストアは、入退店体験、購入後の消費者体験、商品価格設定、支払い方法など、取り入れたい機能を定義できます」と彼は言います。 テクノロジーを活用したアクション Just Walk Out テクノロジーを採用した店舗に入るには、消費者はクレジットカードを挿入またはタップしたり、アプリやデジタルウォレットを使用したり、 Amazon One デバイスの上に手のひらをかざしたりすることで入店できます。 Amazon One は、消費者が支払いから入店まで、さまざまな体験を簡単にする手のひらを使った ID ソリューションです。Amazon One を初めて利用する消費者は、数秒で登録できます。一度登録すれば、Amazon One を導入している場所ならどこでも、手のひらを使って入店し支払いができます。 「いったん店に入ると、消費者はいつものように買い物をすればよいだけです。」と Jenkins は言います。「消費者が棚から取り出したものはすべて自動的に仮想ショッピングカートに追加され、棚に戻したものはすべて仮想ショッピングカートから削除されます。たとえば、棚からソーダを取り出すと、そのソーダは仮想ショッピングカートに入れられ、買い物が終わって店を出たときに請求されます。」 チェックアウトの手間を省く 店舗での買い物をより速くするため、多くのコンビニエンスストアはセルフレジを導入しています。セルフレジを導入することでレジ担当者の数を減らし、消費者に支払いオプションを増やすことができますが、その反面、消費者の利便性を低下させる結果となります。 セルフレジでは、消費者は商品のバーコードを見つけて、スキャンするか手動で入力しなければなりません。そして POS 機器から支払いデバイスに切り替えて購入しなければなりません。セルフレジのプロセスには多くの間違いが起こりやすく、実際に頻繁に起こっています。消費者が速やかな買い物を期待している時に、レジのプロセスに問題が発生したり、前の人が問題に直面していて列が停滞すると、イライラと苛立ちを感じることになります。 これとは対照的に、Just Walk Out テクノロジーはチェックアウトの手間を省き、コンビニエンスストアのオペレーションとスタッフの効率化を支援します。Jenkins は次のように語っています。「レジなしの店舗では、消費者は自分のペースで入店し、買い物を楽しみ、帰宅できるため、消費者の不満は最小限に抑えられます。」 運用の最適化とパフォーマンスの向上 Just Walk Out テクノロジーは、コンビニエンスストア事業者に複数のメリットをもたらします。レジの行列をなくすことで、スタッフはより良い体験を提供することに注力できます。「スタッフは、消費者への対応、質問への回答、商品の探し方の手伝い、必要に応じての陳列棚の補充などに、より多くの時間を費やすことができ、レジ操作や支払い処理などに時間を取られなくて済みます。この技術は、コンビニエンスストアが従業員を支払い処理のような反復的な機能から、よりエンゲージメントの高い消費者中心の機能へとシフトするのに役立ちます。」 Just Walk Out テクノロジーは、コンビニエンスストアがスペースの生産性を最大化するのにも役立ちます。コンビニエンスストアは伝統的に小規模な店舗です。従来の POS システム専用のスペース（通常は視認性の高いエリア）をなくすことで、コンビニエンスストアはそのスペースを再割り当てして、より多くのより良い製品配置やプロモーションを行うことができます。 さらに、コンビニエンスストア事業者はは、Just Walk Out アナリティクスを利用することで、自社の Just Walk Out テクノロジー対応店舗における商品の検討、受け取り、棚への返品、購入方法に関するインサイトを得ることができます。 e コマースサイトについて考えてみてください。小売業者は、最初にクリックされた商品、よく一緒に閲覧された商品、最終的に購入された商品を確認できます。Just Walk Out アナリティクスは、コンビニエンスストアのリーダーに実店舗についてもこれと同レベルの洞察を提供します。Just Walk Out アナリティクスを使うと、コンビニエンスストアのリーダーは、店舗全体および棚別、備品別、製品カテゴリ別の商品インタラクションをスケーラブルでデータ主導型のビューで把握できます。この洞察は、コンビニエンスストアのリーダーが商品の品揃えや配置を改善し、オペレーション効率を高め、消費者の店舗体験を向上させるのに役立ちます。 消費者とコンビニエンスストア事業者は同じような目標を共有しています。どちらも、買い物を簡単にする店舗体験を求めています。「 Just Walk Out テクノロジーは双方にメリットをもたらします」と Jenkins は言います。「レジの列に並ぶ必要がなくなるため、消費者は忙しい生活の中でも簡単に店舗に入って必要なものを購入することができます。それがこのテクノロジーによって可能になることであり、この体験をより多くのお客様に提供できることを楽しみにしています。」 Amazon の Just Walk Out テクノロジーとコンビニエンスストア向け Amazon One の 詳細 をご覧ください。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。

本記事は How to: Create a VR application with user insights using AWS Amplify and WebXR を翻訳したものです。 このブログでは、 AWS Amplify と Babylon.js の WebXR 実装 を使用して、ユーザーのインサイトを活用したバーチャルリアリティ体験を作成する方法について学びます。この組み合わせによって、最初のバーチャルリアリティ（VR）アプリケーションを立ち上げる際のハードルを下げることができるでしょう。 このハウツーでは、AWS Amplify を使用してフルスタックアプリケーションをホストし、Babylon.js の WebXR 実装で VR シーンと機能を提供し、 Amazon DynamoDB を使用してユーザーイベントを保存し報告する、シンプルな VR 対応アプリケーションを作成する手順をカバーします。アプリケーションは Amplify と Babylon.js を使用して設定され、デプロイされます。コントローラーの入力データは WebXR を使用して有効にされ、ユーザーの入力イベントは DynamoDB、 Amazon Athena 、および Amazon Quicksight を使用して保存および報告されます。アプリケーションで使用される 3D モデルは、 Amazon Simple Storage Service（Amazon S3） を使用して保存されます。Amplify は AWS CodeCommit を使用して継続的なデプロイメントを行います。 最終的には 3D モデルを使用した VR アプリケーションが作成され、ユーザーの入力が記録・可視化されるため、お客様はユーザーエクスペリエンスの改善方法についてのインサイトをダッシュボードで確認できます。 この Amplify アプリケーションでは、たとえばプレイヤーは VR コントローラーで Color GUI から青色を選択します。色の変更イベントは、データベースに色の値を送信します。 DynamoDB テーブルには、各イベントの色の値が記録されます。 Quicksight ダッシュボードは DynamoDB からのデータを表示するために使用されます。 アーキテクチャ ユーザーは、VR 対応デバイスを使用して AWS Amplify のウェブサイトに接続します。テクスチャやオブジェクトは Amazon S3 からアプリケーションに読み込まれます。オブジェクトは AWS Amplify の外で Amazon S3 において管理します。ユーザーは XR シーンで利用可能なオブジェクトやコントロールと対話し、クリック、色の選択、テクスチャの選択などの各ユーザーイベントは DynamoDB に送信されます。Amazon Athena は Quicksight がユーザーのインサイトを提供するためのデータを利用可能にします。AWS Amplify の管理者は、ホストされたサイトにユーザーのインサイトに基づいた変更をデプロイすることができます。 前提条件 AWS Amplify 、 Amazon DynamoDB 、 Amazon S3 、 Amazon Athena 、および Amazon Quicksight への完全な権限を持つ既存の Amazon Web Services (AWS) アカウント JavaScript と Linux コマンドラインに慣れている Node.js v14.x 以降 npm v6.14.4 以降 git v2.14.1 以降 最新の Amplify CLI ；バージョン 10.6.2 以上 手順の概要 サンプルアプリケーションをデプロイして実行するには、次の手順を実行します。 ステップ 1: React アプリケーションのセットアップ Getting started – React – AWS Amplify Docs を使用して React アプリケーションを作成し、create-react-app を使用してディレクトリ構造を作成し、ローカルシステムで開始できることを確認します。 ステップ 2: AWS Amplify と Babylon.js のインストール Getting Set Up | Babylon.js Documentation を使用して AWS Amplify CLI 、Babylon.js、および Babylon.js モジュールをインストールします。AWS Amplify は、フロントエンドの Web およびモバイル開発者が AWS 上でフルスタックアプリケーションを迅速かつ容易に構築できるようにするための目的に特化したツールおよび機能のセットです。 ステップ 3: Amplify でバックエンドを初期化 このプロジェクトでは、Amplify の AWS AppSync 、Amazon S3、 Amazon Cognito との統合を活用します。アプリケーションの構築とデプロイ、必要な AWS リソースのプロビジョニングについては Complete guide to full-stack CI/CD workflows with AWS Amplify も参照してください。まずは Amplify CLI を使用して Amplify 環境を初期化し、編集します。 ステップ 4: Amplify でバックエンドリソースを作成 Storage – Overview – AWS Amplify Docs を使用して Amplify バックエンドリソースを作成しプッシュし、 Tutorial – Add authentication – React – AWS Amplify Docs を使用して認証を行い、 Tutorial – Connect API and database to the app – React – AWS Amplify Docs を使用してデータを同期および DynamoDB に保存します。 ステップ 5: Amazon S3 にテクスチャをアップロード AWS 管理コンソール に移動し、作成されたリソースを表示します。Amazon S3 コンソールに移動し、ステップ 4 で作成したバケットを探します。トップディレクトリで「public」というフォルダを作成し、そのフォルダに入ります。このフォルダ内で「アップロード」をクリックし、バケットにテクスチャをアップロードします。これでコードからアクセス可能になります。 ステップ 6: アプリケーションシーンの作成 Babylon.js は JavaScript ベースの人気のある 3D エンジンで、Web 用の 3D アプリケーションやゲームを開発するためのオープンソースフレームワークです。これは、リアルな動きやオブジェクト間の相互作用を容易に作成できる高度な機能を提供し、VR アプリケーションの作成に不可欠です。Babylon.js のドキュメントから Starter HTML Template を使用して index.html ファイルを作成します。ローカルシステムでコードをコピーし、 README.md の src/index.js、src/App.js、および src/Scene.js に貼り付けます。 ステップ 7: git ベースの CI/CD デプロイメント用の CodeCommit を作成 アプリケーションをホストするために、AWS Amplify Hosting サービスと AWS CodeCommit を使用します。Amplify Hosting は完全に管理された CI/CD およびホスティングサービスであり、AWS CodeCommit は完全に管理されたソースコントロールサービスであり、 Setting up Amplify access to GitHub repositories のドキュメントを使用して git ベースの CI/CD デプロイメントを可能にします。 ステップ 8: 継続的なデプロイメントのために Amplify を CodeCommit に接続 AWS 管理コンソールから Amplify コンソールを開き、継続的なデプロイメントを有効にするために CodeCommit リポジトリに接続します。 ステップ 9: Amazon Athena と DynamoDB コネクタを作成 Amazon Athena DynamoDB コネクタ により、Amazon Athena は DynamoDB と通信できるようになり、SQL を使用してテーブルをクエリできます。これにより、シーン内のユーザーアクションから取り込まれたイベントデータを視覚化するために QuickSight を使用できます。 ステップ 10: QuickSight ダッシュボードを作成 DynamoDB に保存されたイベントデータから洞察を得るために QuickSight ダッシュボード を作成します。Amazon QuickSight は、簡単に理解できる洞察を提供するために使用できるクラウドスケールのビジネスインテリジェンス（BI）サービスです。 ステップ 11: VR アプリケーションの表示と使用 新しい CodeCommit プッシュコマンドが実行されるたびに、Amplify は新しいビルドとデプロイプロセスを実行します。デプロイプロセスが完了すると、最新バージョンはアプリホスティング環境にある同じプロダクションブランチの URL に残ります。 ステップ 12: QuickSight ダッシュボードの表示 QuickSight は、172 回の VR コントローラーのクリックと、各クリックの色の RGB 値を示しています。 ステップ 13: 公開アクセスの制限またはクリーンアップ 意図しないアクセスによるコスト上昇を防ぐためには、 Restricting access to branches の指示に従って Amplify URL をパスワード保護するか、作成されたすべてのリソースを削除します。 終わりに Amplify、Babylon.js、および Babylon.js の WebXR スタックを使用する方法を示すこのブログは、WebXR を始めるための多くの方法のうちの一つにすぎません。Amplify を使用すると、XR のアイデアを反復するための継続的なデプロイメント環境が提供されます。Bablyon.js で次に試すべきことのインスピレーションを得るためには、 The Playground を訪れてください。このブログの例は、追加のオブジェクト、テクスチャ、およびコントロールでより多くのイベントデータを収集すること、より包括的なダッシュボードを作成すること、または AI/ML を追加してユーザーの洞察を拡大することでさらに拡張することができます。 次のステップ このブログで概説されているセットアップを再現するために使用された具体的な技術コマンドを含む完全なステップバイステップの解説は、 Create a VR application with user insights using aws amplify and the webxr stack で見つけることができます。 著者について Brian M. Slater Brian M. Slater は、Amazon Web Services の Independent Software Vendors (ISV) の Principal Solutions Architect です。Brian は、政府、スタートアップ、および金融サービスにおいて多年の経験を持っています。現在は、IoT および空間コンピューティングソリューションの構築において顧客を支援しています。 Sam Burton Sam Burton は Amazon Web Services のエンタープライズソリューションアーキテクトであり、業界のベストプラクティスに従って AWS 上でソリューションを構築、反復、およびスケールするお客様を支援しています。エンタープライズ顧客との作業以外に、Sam は AWS Amplify などのフロントエンドの Web およびモバイルサービスでの構築を行っています。 Sneha Panchadhara Sneha Panchadhara は Amazon Web Services のソリューションアーキテクトで、お客様がビジネス目標を達成し、AWS サービスの採用を加速するのを支援することを楽しんでいます。仕事以外の時間は、家族や友人と過ごすのが好きです。 翻訳はソリューションアーキテクトの阿南が担当しました。原文は こちら です

本記事は Exploring the Spatial Computing Spectrum: The Next Frontier of Immersive Technologies を翻訳したものです。 新しい技術進歩の時代に入るにつれ、次なるイノベーションのフロンティアは空間コンピューティングによって動かされることが明らかになってきました。ゲーム、映画とメディア、シミュレーション、あるいはメタバースなどの分野において、さまざまな業界の企業が空間コンピューティングの能力開発を競っています。特に、3D コンテンツ作成、ゲーム、シミュレーション、地理空間の4つの空間コンピューティングセグメントがイノベーションを推進する立場にあります。これらの各領域のためのより良いツールとクラウドサービスを開発することで、空間コンピューティングは人々の働き方、遊び方、生活の仕方を革新する新しい可能性の扉を開くでしょう。 Amazon Web Services(AWS) のチームは、すでに空間コンピューティングの基盤を構築するために懸命に取り組んでいます。このブログ記事では、空間コンピューティングとは何かを探り、3D コンテンツ作成、ゲーム、シミュレーション、地理空間を通じて、AWS がこの革新的なテクノロジーの未来を形作る支援をしていることを紹介します。 空間コンピューティングとは 空間コンピューティングは、仮想世界と物理世界の組み合わせです。物理世界を仮想化し、仮想情報を物理世界に重ね合わせることで、ユーザーがデジタルコンテンツと自然かつ直感的に対話できるようになります。この組み合わせにより、物理的あるいは仮想的な場所におけるデータの可視化、シミュレーション、操作が強化されます。ブログ “The Best way to Predict the Future is to Simulate it”  で、Amazon のテクノロジー担当 VP Bill Vass は、「空間コンピューティングは、協調型エクスペリエンスを実現する原動力です」と述べています。 空間コンピューティングは、業種や業界の垣根を越えています。ユースケースは、リアルタイムメトリクスを表示するデジタルツインから、大規模多人数同時オンライン (MMO) ビデオゲーム、都市全体のレーザースキャンで訓練された AI/ML モデルなど、幅広い範囲に及びます。これらのユースケースは業界の垣根を越えていますが、同様のコアテクノロジー、仕様、ワークフロー、課題を共有しています。 アート作品の制作 3D デジタルコンテンツ制作は、空間コンピューティングのバックボーンです。AWS を利用することで、顧客は画期的なアート作品の創作により多くの時間を費やし、ハードウェアやレンダーファームの管理に費やす時間を短縮できます。ブログ “Avatar: The Way of Water” のような最新のコンピュータグラフィックス (CG) ショットをレンダリングする場合でも、プロダクションをクラウドに移行することで世界中から最高の人材を集める場合でも、AWSのソリューションとサービスはクリエイターが観客を楽しませる力を発揮してきました。 AWS のメディアサービス は、顧客がハリウッドの大作映画のデジタルコンテンツを作成し、ライブおよびオンデマンドのビデオワークフローを構築するのに利用されてきました。 AWS Thinkbox Deadline は、スケーラブルかつ柔軟なコンピュートレンダリング管理の業界標準です。Deadline により、顧客はオンプレミスのレンダーファームからクラウドに移行でき、アーティストはより迅速に反復処理を行い、ショットの納期を従来の日数から時間単位に短縮することが可能になりました。 ここ数年で、顧客は中央集中型のチームから世界中に分散したチームへと移行してきました。これにより、スタジオはタイムゾーンを越えて世界中から最高のクリエイターを集めることができるようになりました。 AWS Studio in the Cloud ソリューションは、スタジオの分散型グローバルチームへの移行を支える基盤として機能してきました。こうした移行からの学びを踏まえ、AWS のツールとサービスは 3D コンテンツ制作のためのクラウド利用をより簡単にするよう進化を遂げています。AWS は、顧客がワークフローを加速し、次世代の 3D コンテンツをより効率的に制作できるよう、コアとなるクラウドインフラとリソースの提供に注力しています。 AWSは次なる一手を予測するため、先を見据えています。世界中のスタジオがクラウドを利用して、日数ではなく時間単位で映像作品を制作してきました。顧客とのこうした取り組みから得た教訓をさらに推し進めることで、新しい形の映画製作、インタラクティブ体験、ビデオゲームのためのより大規模なスケーラビリティ、可用性、クラウドコンピューティングパワーを実現していきます。 あらゆる規模でのゲーム この 5 年間でビデオゲームは驚異的な成長を遂げており、AWS は規模の大小を問わずゲーム開発者をサポートしてきました。インディーゲームスタジオの Blinkmoon Games から、 Epic Games のような業界最大手スタジオまで、AWS に全面的にコミットしている開発者に対し、AWS はグローバルな規模でゲームを提供するために必要なツールとリソースを提供しています。 今日、Epic Games が開発した Fortnite は、ほぼ完全に AWS 上で動作しています。 AWS Graviton processors を搭載した Amazon EC2 インスタンスを何万台も使用し、Epic Games は毎日世界中の何百万人ものプレイヤーをサポートしています。今年、Epic Games は AWS と協力し、 AWS Local Zones を通じてより多くの Fortnite プレイヤーをサポートしました （英語）。現在 AWS Local Zones 上で動作しているため、中部アメリカとメキシコのプレイヤーは、新しい北米中央 Fortnite リージョンで低レイテンシーのゲームプレイを体験できます。AWS では、ゲームプレイの機能とクラウドサービスが拡張していくにつれ、Fortnite のプレイヤーがどのようなことを実現するのか楽しみにしています。 チームの規模に関わらず、 Amazon GameLift を利用することで、セッションベースのマルチプレイヤーゲームのための専用のリアルタイムサーバーを提供できます。 開発者がサーバーの完全な制御とカスタマイズを必要とする場合でも、面倒なカスタムゲームサーバーのデプロイプロセスを省くことができる使いやすいゲームサーバーを必要とする場合でも、どちらでもAmazon GameLift はゲームのマーケットへのリリースを支援することができます。 リアルタイム 3D エクスペリエンスのユースケースがゲームから他のビジネス分野に広がるにつれ、 AWS for Games のソリューションを求める顧客が増えています。 当社のパートナーである Surreal Events は、AWS を利用してメタバースソリューションを拡張・スケーリングし、世界中の顧客に提供しています。 AWS を利用することで、あらゆる種類のリアルタイム 3D エクスペリエンスを構築する開発者は、仮想世界を拡大していくにつれて、エンドユーザーに大規模なコラボレーションをもたらすことができます。 未来のシミュレーション 近年、ほぼすべてのビジネス分野で、何らかの形でのシミュレーションが採用されるようになりました。ライフサイエンス、金融サービス、石油・ガス、設計、エンジニアリング、気候科学、自動運転などです。 システムがますます複雑になるにつれ、空間シミュレーションは、物理世界への洞察を提供する鍵となります。 過去には、空間シミュレーションは1つのハードウェアに制約されており、開発者にとってはほぼ不可能な課題でした。 このため、AWS は昨年、新しいシミュレーション専用サービスである AWS SimSpace Weaver を発表しました。 この新サービスにより、AWSの開発者は都市規模の 3D シミュレーションから洞察を得ることができます。 SimSpace Weaver は、コンピューティングインフラストラクチャー全体でシミュレーションを管理することで、クラウドで大規模な空間シミュレーションを簡単に実行できるようにします。 これにより、開発者はクラウドインフラストラクチャーのプロビジョニングとメンテナンスではなく、シミュレーションとアプリケーションの構築に集中できます。 さらに、SimSpace Weaver は、人気のあるリアルタイム 3D エンジンとの統合を提供するため、開発者は没入型でインタラクティブな体験を作り出すことができ、チームは実世界のシナリオをより良く理解することができます。 大規模な群衆シミュレーションのエキスパートである uCrowds 社との提携により、私たちは何百万ものシミュレートされた人間がネバダ州ラスベガスの通りを歩く実世界のシミュレーションの拡大、実行、可視化の可能性を示しました。この規模でシミュレーションを行うことで、私たちのチームは人口の急増が物理的な都市インフラに与える影響についてより良い理解を得ることができました。 AWS re:Invent 2022でのAmazonのCTO、Werner Vogelsの言葉 を言い換えると、私たちは物理的なものと仮想的なものとの境界線が曖昧になる中で、シミュレーションが重要であると考えており、開発者たちがあらゆるもののシミュレーションを始めることを願っています。 地理空間データを至る所で活用する 歴史を通じて、地図は新しいフロンティアを定義する上で重要な役割を果たしてきましたが、空間コンピューティングの強化により、これからもその役割を続けるでしょう。相互接続された私たちの世界では、地図は商品やサービスのルート、場所、フェンスを定義します。ビジネスが都市をナビゲートし、荷物を追跡し、車両やラストワンマイルを配送する自動運転ロボットのルートを設定する際、地図が提供する地理空間データはますます重要になっています。 2021 年、AWS は Amazon Location Service を発表しました。これは、地図、興味のあるポイント、ジオコーディング、ルーティング、トラッキング、ジオフェンシングをアプリケーションに簡単かつ安全に追加できる完全に管理されたサービスで、データのセキュリティ、ユーザーのプライバシー、またはコストを妥協することなく提供します。Amazon Location には、地図ベースの可視化、リソースの追跡、配送、ジオマーケティングによる場所を意識したユーザーのエンゲージメントなど、様々なユースケースのための位置機能が追加されました。 AWSは地図にとどまりません。アプリケーションに高い理解、洞察、および文脈に応じた情報をもたらすために、AWSは Amazon SageMaker も拡張し、開発者が地理空間データを使用して、機械学習モデルをより速く構築、トレーニング、デプロイできるようにしました。 AWS の Open Data Program と組み合わせることで、テラバイト単位のオープンソースの LiDAR ポイントクラウドデータを使用して、新しい地理空間ワークロードのための AI/ML モデルをトレーニングすることができます。自動運転車のフリート、配送ロボットのトレーニング、または物理世界からの洞察を得たい場合であっても、 Amazon SageMaker での地理空間ML は、開発チームが地理空間データを分析し、インタラクティブな地図を使用して 3D で強化されたグラフィックでモデル予測を探索することを可能にします。 空間コンピューティングにより、次世代のアプリケーションは私たちの周囲の物理的世界に対して、より深い洞察と文脈データをもたらすでしょう。Amazon Location や SageMaker などの AWS サービスは、すでに開発者によって使用されており、私たちの仮想世界を物理的な世界にオーバーレイしています。 更なるイノベーションへ 空間の革命はすでに進行中で、AWS のお客様によって、あらゆる規模やビジネスラインで主導されています。3D の文脈データと AWS クラウドのパワーとスケールにより、私たちの仮想世界と物理世界はシームレスに組み合わされ、働き方、生活、遊び方の変革を促進しています。AI/ML がよりアクセスしやすくなるにつれて、 AWS 上の生成 AI サービス を使えば、誰もがクリエイターになり、3D 仮想コンテンツで物理世界を拡張することができるでしょう。 3D コンテンツ作成、ゲーム、シミュレーション、地理空間という 4 つのテクノロジーセグメントを通じて、AWS は開発者と協力して未来を形作っています。AWS チームが未来を見据える中で、私たちは新しいツールやクラウドサービスを開拓し、技術革新の次のフロンティアに挑戦し、世界中の開発者が未来を構築することを支援することを目指しています。 著者について Chris Lee Chris Lee は AWS の没入型テクノロジー部門のディレクターでありGMです。彼は、AWS 上で大規模な空間コンピューティング体験を構築するために、レンダリング、VFX、ゲーム、シミュレーション、地理空間サービスの構築に注力しています。この役割に就く前、Chris は 20 年以上にわたりゲーム業界で複数の AAA ゲームを構築してきました。 翻訳はソリューションアーキテクトの阿南が担当しました。原文は こちら です。

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 金成が担当しました。原文は こちら です。