小売業では常に、実店舗へのアクセスや人通りを増やすことを目指しています。そのためには、潜在顧客が最も便利な店舗を正確に特定できなければなりません。最もアクセスしやすい店舗に関する情報を、便利な Web/Mobile アプリケーションを通じて潜在顧客に提供することで、小売企業は来店を増やし、顧客体験を向上させることができます。何千もの店舗を持つ全国規模の小売業者も、数店舗しかない地元の小さな金物屋も、小売店舗を顧客にとってよりアクセスしやすくすることで、利益を得ることができます。 Amazon Location Service は、サーバーレスでフルマネージド位置情報サービスで、開発者は Esri 、 HERE Technologies 、 GrabMaps などの信頼できる商用プロバイダーやオープンデータからのデータを使用して、アプリケーションに位置情報機能をコスト効率よく追加することができます。Amazon Location を利用することで、オンラインストアでの体験を位置情報機能で簡単に補強し、顧客を店舗に誘導することができます。 本記事では、Amazon Location の Maps 、 Places 、および Routing API を使用して、営業時間や住所などの適切な店舗情報とともに、顧客にとって最もアクセスしやすい実店舗をリストアップするシンプルな店舗検索 Web ページを実装する方法を紹介します。 2 つのパターンを紹介します。1 つ目のパターンは、イギリスほどの大きさの地域に分散している 20 店舗未満のビジネスを想定しています。2 つ目のパターンは、米国サイズの地理的エリアに分布する 20 以上の店舗を持つビジネスを想定しています。 顧客体験 店舗検索サイトでは、2 つのオプションを提示するシンプルな Web ページが表示されます。 現在地を Web ブラウザと共有することに同意し、出発地点として使用します。これは、顧客が今すぐ店舗を訪れたい場合に便利です。 店舗検索サイトの検索したい場所を説明するテキスト（都市名など）を入力します。その後、顧客は出発地候補のドロップダウンから場所を選ぶことができます。場所が選択されると、この場所は出発位置に ジオコーディングされます 。これは、顧客が将来ある店舗を訪問する予定がある場合に便利です。 図 1 : 店舗検索のランディングページのナビゲーション 出発地が店舗検索サイトのバックエンドに送信された後、最も近い店舗が、顧客の体験を助ける以下の店舗情報とともに返されます。 推定所要時間と距離 営業時間 住所 図 2 : 最寄りの店舗リストの表示 店舗の位置は地図上のマーカーとして表示されます。 ソリューション概要 このソリューションでは、フロントエンドに Vue.js 3.0の シングルページアプリケーション (SPA) を使用します。この SPA は、 AWS Amplify Hosting を使用してホスティングされています。AWS Amplify Hosting は、フロントエンドのWeb および Mobile 開発者が AWS 上でフルスタックアプリケーションを簡単に構築、ホスティングできるフルマネージドサービスです。 バックエンドの AWS サービスは、データストアからストア情報を取得し、Amazon Location Service を使用してルーティングを実行し、関連する結果をフロントエンドに返すための API を提供します。このソリューションは、API をホストするために Amazon API Gateway 、ビジネスロジックを実装するために AWS Lambda 関数 、そして選択されたパターンに応じて店舗情報を保持するために Amazon DynamoDB または Amazon Aurora Serverless のいずれかを使用します。 コストを最適化するために、このソリューションを作成する際に 2 つのパターンを想定します。 ソリューションパターン タイプ 店舗数 国 1 小規模 < 20 イギリス 2 中 ~ 大規模 ≥ 20 アメリカ アーキテクチャ図 以下に示すのは、両方のパターンのアーキテクチャ図です。 図 3 : ソリューションのアーキテクチャ図 2 つのパターンでソリューションが異なる部分には、青 (パターン 1) と赤 (パターン 2) の色を使い、違いを強調しています。 ソリューションの仕組み 以下がソリューションの仕組みです。 顧客は、Amplify Hosting がホスティングする店舗検索 Web サイトにアクセスします。この Web サイトは、Vue.js 3フレームワークを使用して構築されており、 aws-amplify 、 maplibre-gl-js-amplify 、 maplibre-gl JavaScript ライブラリを使用して、 Amazon Cognito 、Amazon Location Service、およびベクトルタイルやマーカーなどのインタラクティブなマップオブジェクトの実装を容易にします。 顧客は、Amazon Cognito ユーザープールを使用して認証します。aws-amplify ライブラリは、登録と認証のワークフローを処理し、Amazon Cognito ID プールから一時的にスコープダウンされた AWS 認証情報を取得します。認証されたアクセスに関連する AWS Identity and Access Management (IAM) ロールは、Amazon Location Service リソースにアクセスするのに必要な最小限の権限のみを含んでいます。 maplibre-gl JavaScript ライブラリを使用して、 Web ページは、Maps API を使用して Amazon Location からダウンロードされたベクトルタイルを使用してインタラクティブなマップを表示します。マーカーは、結果が返されたときに出発地と目的地の店舗の場所を表示するために使用されます。 顧客が検索フィールドにカスタムテキストを入力すると、Amazon Location の SearchPlacesIndexForSuggestions Places API が呼び出され、提案された場所のリストをドロップダウンとして返します。顧客が選択肢の 1 つを選択すると、ジオコーディングのための GetPlace Places API が、出発地の位置座標を返す選択された PlaceId に対して呼び出されます。オプションとして、顧客は Locate me ボタンを使用してブラウザに現在地を確認させることができます。 選択された出発地は、API Gateway を使用してホストされているソリューションのカスタム API に送信されます。リクエストのペイロードはハッシュ化され、API Gateway は一般的にリクエストされる出発地（例えば、ラスベガスやロンドン）のキャッシュからレスポンスを返すことができます。 このステップは使用するパターンによって異なります。 パターン1 – API Gateway API は、DynamoDB のテーブルからすべての店舗位置情報を返す Lambda関数を呼び出します。 パターン2 – Lambda 関数は、PostgreSQL の PostGIS 地理空間機能 ( ST_DistanceSphere ) を使用して、目的地の店舗の候補のサブセットを返すクエリします。この Aurora Serverless PostgreSQL データベースの認証情報は、 AWS Secrets Manager に安全に保存されます。 両方のパターンについて、返された目的地店舗のリストは、これらの目的地までの推定距離と時間を確認するために Amazon Location の CalculateRouteMatrix Routes API を使用します。 ターゲット店舗とそのメタデータの控えめなショートリストがフロントエンドに返され、この情報は店舗検索 Web ページ上で顧客に提示される。 店舗の位置情報の想定 このデモのために、以下のデータソースを使用します。 イギリス – Network Rail が管理する鉄道駅 （18 箇所） 米国 – 1639 年から 2000 年の間に米国で運営された郵便局 （112,000 箇所以上） 店舗データは、提供されたテンプレートによって自動的にデータストアにロードされます。データインポートの仕組みについては、 GitHub リポジトリ を参照してください。 なぜマトリックス・ルーティングを使うのか？ 顧客が訪問する最寄りの店舗を特定する場合、評価されるルートは、顧客が選択した交通手段と、位置情報データプロバイダーが収集した交通網の現在の可用性に基づいていなければなりません。顧客の出発位置と候補店舗との間の大円距離を計算するだけでは、非現実的な結果が得られる可能性があり、不十分です。 以下の例では、カーディフ空港は物理的にイギリスのマインヘッドに近い位置にあります。しかし、間に水域があるため、道路を使用した場合、マインヘッドからよりアクセスしやすい空港は、実際にはブリストル空港です。 図 4 : マトリックス・ルーティングを使用して最寄りを計算する このソリューションのパターン 2 では、目的地となり得る店舗数が多い場合、Amazon Location の Routing API の使用を最小限にするため、座標間の大円距離に基づいて候補店舗の暫定リストを生成します。マトリックス・ルーティング API を使用する場合、計算されるルート数に対する 価格 は、出発地の数に目的地の数を掛けた数によって決まるため、多数の店舗を運営するビジネスでは、この方が費用対効果が高くなります。このパターンは、クエリあたりのコストを一定に保ちながら、何十万もの店舗にスケールすることができます。 さらに、どちらのパターンでも、API Gateway 上で キャッシュを有効 にし、繰り返しクエリに対するレスポンスがキャッシュから直接返されるようにし、バックエンドのインフラを経由しないようにしてます。これにより、結果取得の待ち時間とコストが削減されます。 チュートリアル aws-samples の GitHub リポジトリ が用意されているので、このソリューションを自分で試すことができます。以下のステップに従うと、サーバーレス店舗検索サイトの両方のパターンについて、フロントエンドとバックエンドのリソースがデプロイされます。 ソリューションをカスタマイズする方法の詳細については、リポジトリを参照してください。 前提条件 このチュートリアルの前提条件は以下の通りです。 AWS アカウント AWS Serverless Application Model (AWS SAM) を使用して AWS リソースをデプロイするための IAM 権限 AWS SAM Command Line Interface (CLI) のインストール Vue js 3.0 のインストール コードのダウンロード AWS SAM のインストール 公式ドキュメント の手順に従って、オペレーティングシステム用の AWS SAM CLI の最新リリースをインストールします。 sam —version を実行して AWS SAM CLI が正常にインストールされたか確認します。 注: AWS SAM CLI には、選択した AWS アカウントでリソースをプロビジョニングするための適切な権限が必要です。IAM を使用して アクセスキーとシークレットアクセスキー が作成され、 aws configure を使用してマシンにローカルに登録されていることを確認する必要があります 両方の API パターンで必要なすべてのフロントエンドコード、バックエンドコード、AWS SAM テンプレートは、 serverless-store-finder GitHubリポジトリ に格納されています。 以下のコマンドを実行して、すべての必要なファイルをダウンロードします。 git clone https://github.com/aws-samples/serverless-store-finder ダウンロードしたリポジトリのルートに移動し、JavaScript の依存関係をインストールします。 cd serverless-store-finder npm install .env.local.template ファイルをコピーし、.env.local に名前を変えます。 cp .env.local.template .env.local env.local.template ファイルには、AWS SAM テンプレートのデプロイからの出力が入力されます。 これで AWS SAM テンプレートをデプロイする準備ができました。 SAM テンプレートのデプロイ 店舗検索サイト AWS SAM テンプレート Store Finder - Core は、両方のパターンで必要な共有インフラリソース、つまり Amazon Location Map、Place Index、Route Calculator、Amazon Cognito ユーザープールと ID プールをデプロイします。この AWS SAM テンプレートは、空の Amplify Hosting アプリも作成します。 SAM テンプレートのデプロイ sam/core ディレクトリに移動します。 cd sam/core アプリケーションをビルドします。 sam build Build Succeeded メッセージが表示されます。 アプリケーションをデプロイします。 sam deploy --guided プロンプトが表示されたら、以下のように詳細を入力します。残りの項目はデフォルトのままでかまいません。 Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: <Your Store Finder "Core" Amazon CloudFormation stack name> AWS Region [eu-west-1]: <Your AWS Region> Parameter storeFinderAmplifySubdomain [demo]: <Amplify environment subdomain name used in URL> この例では、スタック名を myStoreFinder-Core-v1 とし、AWS リージョン eu-west-1 にデプロイしています。 パラメータ storeFinderAmplifySubdomain にどのような名前を選択したかをメモしておいてください。後でアプリケーションを Amplify Hosting にデプロイするときに使用します。今回は、 demo としました。 図 5 : AWS SAM テンプレート “Store Finder – Core” のデプロイ Successfully created/updated stack と表示されることを確認します。 図 6 : AWS SAM テンプレート “Store Finder – Core” のデプロイ成功の確認 .env.local ファイルに不足している Amazon Location と Amazon Cognito の詳細を、デプロイされた CloudFormation スタックから出力された値で入力します。 VITE_AWS_REGION=<Your AWS Region> VITE_AMAZON_COGNITO_IDENTITY_POOL_NAME=<storeFinderAmazonCognitoIdentityPoolName from the Store Finder "Core" Amazon CloudFormation stack output> VITE_AMAZON_COGNITO_USER_POOL_NAME=<storeFinderAmazonCognitoUserPoolName from the Store Finder "Core" Amazon CloudFormation stack output> VITE_AMAZON_COGNITO_USER_POOL_CLIENT_NAME=<storeFinderAmazonCognitoUserPoolClientName from the Store Finder "Core" Amazon CloudFormation stack output> VITE_AMAZON_LOCATION_SERVICE_MAP=<storeFinderAmazonLocationServiceMapName from the Store Finder "Core" Amazon CloudFormation stack output> VITE_AMAZON_LOCATION_SERVICE_PLACES_INDEX=<storeFinderAmazonLocationServicePlaceIndexName from the Store Finder "Core" Amazon CloudFormation stack output> 店舗検索 – API パターン1 AWS SAM テンプレート Store Finder - API Pattern 1 は、API Gateway、Lambda 関数、DynamoDB テーブルなど、パターン 1 で必要なバックエンド API インフラストラクチャとコードをデプロイします。この API は独立して機能し、パターン 2 に依存しません。 SAM テンプレートのデプロイ sam/api-pattern1 ディレクトリに移動します。 cd ../api-pattern1 アプリケーションをビルドします。 sam build Build Succeeded メッセージが表示されていることを確認します。 アプリケーションをデプロイします。 sam deploy --guided プロンプトが表示されたら、以下のように詳細を入力します。残りの項目はデフォルトのままでかまいません。 図 7 : AWS SAM テンプレート “Store Finder – API Pattern 1” のデプロイ この例では、スタック名を myStoreFinder-API-v1 としています。 Successfully created/updated stack と表示されることを確認します。 図 8 : AWS SAM テンプレート “Store Finder – API Pattern 1” のデプロイ成功の確認 .env.local ファイルに足りない API エンドポイントの値を、デプロイされた CloudFormation スタックから出力された値で入力します。 VITE_APIGATEWAY_ENDPOINT_API1=<storeFinderAPIGatewayEndpoint from the Store Finder "API1" Amazon CloudFormation stack output> 注：AWS SAMテンプレート Store Finder - API Pattern 1 には、 stores.json ファイルからストアデータを自動的にロードする Lambda カスタムリソース が含まれています。API 1 の準備は完了です。 店舗検索 – API パターン 2 AWS SAM テンプレート Store Finder - API Pattern 2 は、API Gateway、Lambda 関数、Amazon Aurora Serverless V2 PostgreSQL データベース、Secrets Manager のシークレットなど、パターン 2 で必要なバックエンド API インフラストラクチャとコードをデプロイします。この API は独立して機能し、パターン 1 に依存しません。 SAM テンプレートのデプロイ sam/api-pattern2 ディレクトリに移動します。 cd ../api-pattern2 アプリケーションをビルドします。 sam build Build Succeeded メッセージが表示されていることを確認します。 アプリケーションをデプロイします。 sam deploy --guided プロンプトが表示されたら、お使いの環境で選択した詳細を入力します。残りはデフォルトのままでかまいません。 Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: <Your Store Finder "API2" Amazon CloudFormation stack name> AWS Region [eu-west-1]: <Your AWS Region> Parameter storeFinderCoreCloudFormationStackName []: <Name of the Store Finder "Core" Amazon CloudFormation stack> Parameter storeFinderAuroraDBMasterUserName [admin_user] <Name of the PostgreSQL admin user account> Parameter storeFinderDatabaseTableName [tbl_postoffices]: <Name of table to be used in PostgreSQL database> この例では、スタック名を myStoreFinder-API2-v1 としています。 図 9 : AWS SAM テンプレート “Store Finder – API Pattern 2” のデプロイ Successfully created/updated stack と表示されることを確認します。この SAM テンプレートの展開には、最大 20 分かかります。 図 10 : AWS SAM テンプレート “Store Finder – API Pattern 2” のデプロイ成功の確認 .env.local ファイルに不足している API エンドポイントの値を、デプロイされた CloudFormation スタックから出力された値で入力します。 VITE_APIGATEWAY_ENDPOINT_API2=<storeFinderAPIGatewayEndpoint from Store Finder "API2" Amazon CloudFormation Stack output> 注：AWS SAM テンプレート Store Finder – API Pattern 2 には、 us-post-offices.csv ファイルから店舗データを自動的にロードする Lambda カスタムリソース が含まれています。API 2 の準備は完了です。 Amplify Hosting を使って Vue.js アプリケーションをビルドしてデプロイ 注：このデモを簡単にするために、Amplify Hosting はソフトウェアのバージョン管理システムと統合せずに使用しています。実際のアプリケーションでは、Amplify を Git ベースのリポジトリと統合することを強くお勧めします。 Vue.js アプリケーションをビルドしてデプロイ .env.local ファイルに空欄がないことを確認します。 プロジェクトフォルダのルートディレクトリでフロントエンドアプリケーションをビルドします。 cd ../.. npm run build 図 11 : “npm run build” の正常終了の確認 Vue.js のデプロイファイルが /dist に正常に作成されていることを確認します。 cd dist ls 以下のコマンドを実行して、フォルダ内のすべてのファイルを圧縮します。 正確なコマンドは、お使いの OS によって異なる場合があります。 zip -r store-finder.zip . 注：zip 操作は、フォルダレベルではなく、 /dist ディレクトリ内で行う必要があることに注意してください。その後、 .env.local ファイルを変更した場合は、Vue.js アプリケーションを再度ビルドし、以下の手順を繰り返す必要があります。 Amplify コンソールを開き、AWS SAM テンプレート Store Finder - Core で作成された Amplify アプリを選択します。 Deploy without Git provider を選択し、 Connect branch を選択します。 図 12 : Git プロバイダーなしで Amplify アプリをデプロイ Environment name には、AWS SAM テンプレート Store Finder - Core のデプロイ時に、SAM テンプレートパラメータ storeFinderAmplifySubdomain に指定した名前 (例： demo ) と同じ名前を指定します。 Method では、 Drag and drop を選択し、先に作成した store-finder.zip ファイルをアップロードします。これで自動的にデプロイが開始され、サイトが公開されます。 図 13 : Vue.js デプロイ用 zip ファイルをドラッグ＆ドロップ Amplify コンソールに Deployment successfully completed のメッセージが表示されるまで待ちます。 これで、Amplify Hpsting のドメインが提供する URL を使って、サーバーレス店舗検索サイトにアクセスできるようになりました。 図 14 : Amplify アプリのドメイン URL を使った店舗検索サイトへのアクセス このサイトにアクセスすると、まず最初にアカウントの作成とメールアドレスの確認が求められます。 注：このステップは、認証を強制することによって、デモのフロントエンドとバックエンド AP Iを保護します。ユースケースによっては、店舗検索サイトのサイトを Web サイトの訪問者が一般にアクセスできるようにする必要があるかもしれません。 図 15 : Amazon Cognito を使ったアカウントの作成 Select a country ドロップダウンを United Kingdom と United States の間で切り替えて、2 つの API パターンを試すことができます。 図 16：サーバーレス店舗検索サイトのデプロイのテスト クリーンアップ 課金を避けるために、AWS アカウントにプロビジョニングされた CloudFormation スタックを削除しましょう。 まとめ 本記事では、Amazon Location Service を使用して、顧客が最寄りの実店舗を検索できるシンプルで費用対効果の高い Web サイトを作成する方法を紹介しました。Amazon Location の Maps、Places、Routes API を使用することで、店舗検索 Web ページへの訪問者は、現在地、または将来的な位置から最も近い場所を素早く特定することができます。この情報は、どの店舗を訪れるかについての情報に基づいた意思決定に使用することができ、顧客の来店を増やすことができます。 著者プロフィール Alan Peaty Alan はパートナーソリューションアーキテクトとして、グローバルシステムインテグレーター (GSI) とその顧客の AWS サービス導入を支援しています。AWS に入社する前は、IBM、Capita、CGI などのシステムインテグレーターでアーキテクトとして働いていました。仕事以外では、アランはイギリスの田舎のぬかるんだトレイルを走るのが好きな熱心なランナーであり、IoT 愛好家でもあります。 Matt Nightingale マットは Amazon Web Services のシニアスタートアップソリューションアーキテクトで、スタートアップ企業が AWS 上でコスト効率と拡張性の高いソリューションを構築、拡張できるように支援しています。スタートアップと仕事をしていないときは、位置情報サービスを含むソリューションを構築しています。マットは 2020 年に AWS に入社し、マサチューセッツ州ボストンを拠点としています。 この記事は Matthew Nightingale と Alan Peaty によって書かれた Build a serverless store finder site using Amazon Location Service の日本語訳です。翻訳は、ソリューションアーキテクトの 稲田大陸 が担当しました。

はじめに 2023 年 6 月 29 日、出版業界のお客様向けに生成 AI の活用というテーマでセミナーをオンラインにて開催しました。このセミナーの開催報告として当日ご紹介した内容や資料をご紹介いたします。 本セミナー開催の背景についてご説明します。ビジネスへの活用が期待されている生成 AI は日々発展を続けており、新しい基盤モデルや新サービスの発表が相次いでおります。その様な環境の中、出版業界のお客様向けに、生成 AI を使った業務効率化やコンテンツ・IP の活用に関して、AWS で実現できる事のご紹介をさせて頂きたいと考え、セミナーを開催させて頂きました。セミナーの中では、AWS で生成 AI を活用する方法や、出版業界のお客様向けのユースケースのご紹介を致しました。 全体の資料は こちら よりダウンロード可能です。 AWS の生成 AI に関する取り組み アマゾン ウェブ サービス ジャパン合同会社 メディアソリューション部 ソリューションアーキテクト 本多 和幸 アマゾン ウェブ サービス ジャパン 本多より、AWS の生成 AI に関する取り組みと、今すぐ AWS 上で生成 AI を使い始める方法についてご紹介しました。生成 AI をビジネスに活かすためには、3 つの点が重要であるとお伝えしました。1 つ目は、1 つのモデルに依存せず幅広い基盤モデルの中から用途に適したモデルを選択する事、2 つ目は最適なパフォーマンスとコストの両立、3 つ目はアプリケーションへの統合を迅速に行える開発の利便性です。AWS ではこの 3 点全てにおいて、お客様のご要望にお応えできる環境をご用意しております。また、AWS 上で生成 AI の基盤モデルを動かす事ができるサービスは主に次の 3 つがあり、 Amazon Bedrock 、 Amazon SageMaker 、 Amazon EC2 それぞれについてご紹介しました。 Amazon Bedrock は、複数の基盤モデルをサーバーレスでお使い頂ける 2023 年 4 月に発表された新サービスです。お客様のユースケースに沿って AI21 Labs, Anthropic, Cohere, Stability AI, Amazon の基盤モデルを選択して頂けます。Amazon SageMaker は、機械学習に特化したプラットフォームです。 Amazon SageMaker JumpStart では、事前に用意されている基盤モデルを数クリックでホスティングする事ができます。Amazon EC2 では生成 AI に必要な学習と推論に特化した最新インスタンスが先般発表されました。Amazon EC2 は基盤モデルを独自開発するためのリソースとしてお使い頂けますし、基盤モデルの推論のリソースとしてもお使い頂けます。 AWS を活用した出版業界での生成 AI のユースケース アマゾン ウェブ サービス ジャパン合同会社 メディアソリューション部 ソリューションアーキテクト 前川 泰毅 アマゾン ウェブ サービス ジャパン 前川より、出版業界で応用できる生成 AI のユースケースをご紹介いたしました。今回ご紹介したトピックは大きく分けて、大規模言語モデル、音声要約、画像素材の生成/編集です。これらを応用する事で以下のような業務効率化、クリエイティブなアウトプットの生成が期待できます。 大規模言語モデル: 社内の編集部ごとに分割管理された資料をソースにした社内専用チャットボット 間違った回答をする可能性がある大規模言語モデル の弱点を補う事ができるソリューションです。 音声要約: 取材、インタビューのサマリや、音声から記事草案の自動生成 音声をテキストに変換する Amazon Transcribe と大規模言語モデルを組み合わせる事で実現できます。 画像素材の生成/編集: 記事の挿絵や、背景画、広告クリエイティブの自動生成、古いコンテンツのリマスター 画像生成の基盤モデルである Stable Diffusion を GUI で扱う環境の構築方法もご紹介しました。 併せて、それぞれのユースケースで直ぐに生成 AI を試せるリソースとして、基盤モデルの学習に使えるサンプルコードや AWS CloudFormation のテンプレートファイルもセミナー内でご紹介致しました。本セミナー資料内でサンプルコードやテンプレートファイルや構築方法をガイダンスしたブログ記事もご紹介していますのでぜひご参照ください。 学習データに使うコンテンツのデータ保護について 続いて、前川から AWS 上で基盤モデルの学習を行う際のデータ保護についてご説明しました。 重要な知的財産を扱う出版各社様にとってコンテンツの保護は非常に重要な課題です。基盤モデルを利用すると入力した情報が AWS や大元の基盤モデルの改善に使われるのではないかというお問合せも多く頂きますが、AWS 上のお客様のデータもお客様専用にチューニングしたモデルも、お客様の AWS 環境内でセキュアに管理可能です。AWS が勝手にデータやモデルを利用することはなく、また基盤モデルの学習に使用されることもありません。 セミナー後の最新情報について 2023 年 7 月末に開催された AWS Summit New York において、Amazon Bedrock の拡張を発表しました。今回の拡張により、基盤モデルを提供する企業として知られる Cohere、Anthropic と Stability AI の最新の基盤モデル、さらには、専門知識がなくても数回クリックするだけで、フルマネージドエージェントを作成できる革新的な新機能が追加されることになりました。 詳細は、 こちらの記事 をご覧ください。 おわりに 本ブログでは、2023 年 6 月 29 日に開催された「AWS で始める！出版業界向け生成 AI 活用のご紹介～大規模言語モデルから画像生成まで～」の内容をご紹介させて頂きました。本セミナーにご参加頂いた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、ソリューションアーキテクト本多が担当しました。

2022 年 1 月、 Amazon EC2 Hpc6a インスタンスがリリースされました 。これにより、コンピューティング関連のハイパフォーマンスコンピューティング (HPC) ワークロードを AWS で効率的に実行することが可能になるだけでなく、コンピューティングに最適化された 同等の x86 ベースのインスタンスに比べてコストパフォーマンスが最大 65% 向上します。 ジョブが複雑になるにつれて、お客様は、ジョブを完了するまでの時間を短縮するために、より高いコンピューティングパフォーマンスを備えたコアと多くのメモリ、そしてネットワークパフォーマンスを求めるようになりました。さらに、お客様は、より多くの HPC ワークロードを EC2 に導入することを検討しているため、AWS でプロセスを簡単に分散させ、ワークロード要件に合わせてメモリとネットワーク帯域幅を最大限に活用する方法を求めています。 8月17日、緊密に結合された HPC ワークロード向けに設計された次世代のインスタンスタイプである Amazon EC2 Hpc7a インスタンス の一般提供が開始されたことをお知らせします。 第 4 世代 AMD EPYC プロセッサ (Genoa) を搭載した Hpc7a インスタンスは、Hpc6a インスタンスに比べて最大 2.5 倍のパフォーマンスを発揮します。Hpc7a インスタンスは、 AWS Nitro System による 300 Gbps の Elastic Fabric Adapter (EFA) 帯域幅を提供し、高速で低レイテンシーのノード間通信を実現します。 DDR4 メモリよりも 50% 高いメモリ帯域幅を提供する Double Data Rate 5 (DDR5) メモリを搭載している Hpc7a インスタンスでは、メモリ内のデータへの高速アクセスが可能です。Hpc7a インスタンスは、 数値流体力学 (CFD) や 数値予報 (NWP) など、コンピューティング集約型でレイテンシーに敏感なワークロードに理想的です。 Hpc6a で実行している場合、Hpc7a インスタンスを使用すれば、Hpc6a インスタンスの 2 倍のコア密度、2.1 倍の有効メモリ帯域幅、そして 3 倍のネットワーク帯域幅を活用して、ジョブの完了に必要な時間を短縮できます。 Hpc7a インスタンスと第 4 世代 AMD EPYC プロセッサ (Genoa) と以前のインスタンスおよびプロセッサの比較を示すインフォグラフィックを以下に示します。 Hpc7a インスタンスでは、最大 192 コアの AMD EPYC プロセッサ CPU と 768 GiB RAM を利用できます。詳細な仕様は次のとおりです。 インスタンス名 CPU RAM (Gib) EFA ネットワーク帯域幅 (Gbps) アタッチされたストレージ Hpc7a.12xlarge 24 768 最大 300 EBS のみ Hpc7a.24xlarge 48 768 最大 300 EBS のみ Hpc7a.48xlarge 96 768 最大 300 EBS のみ Hpc7a.96xlarge 192 768 最大 300 EBS のみ これらのインスタンスではコンピューティング、メモリ、ネットワークパフォーマンスが向上し、CFD、天気予報、分子動力学、計算化学など、コンピューティング集約が最も高いワークロードを AWS で実行できます。 今年の7月にリリースされた EC2 Hpc7g インスタンス と同様に、お客様は小さいインスタンスサイズを使用して、アクティブ化する CPU コアの数を抑えながら、他のすべてのリソースをワークロード要件に基づいて一定に保つことができます。HPC ワークロードの場合、CFD ワークロードのコアあたりのメモリ帯域幅の増加、ライセンス制限のあるシナリオでの割り当てコア数の削減、コアあたりのメモリの増加などのシナリオが考えられます。詳細については、AWS HPC ブログの「 Instance sizes in the Amazon EC2 Hpc7 family – a different experience 」を参照してください。 Hpc6a インスタンスと同様に、Hpc7a インスタンスを使用して EC2 上で最大かつ最も複雑な HPC シミュレーションを実行し、コストとパフォーマンスを最適化できます。新しい Hpc7a インスタンスを AWS Batch と AWS と AWS ParallelCluster とともに使用して、ワークロードの送信とクラスターの作成を簡素化することもできます。 Amazon FSx for Lustre を使用すると、レイテンシーをミリ秒以下に抑え、1 秒あたり最大数百ギガバイトのストレージのスループットを実現できます、 HPC ワークロードのパフォーマンスを最大限に高めるため、これらのインスタンスでは、 同時マルチスレッド (SMT) が無効化されています。また、これらのインスタンスは、単一のアベイラビリティーゾーンで使用でき、外部ネットワークと EBS 帯域幅は制限されています。 今すぐご利用いただけます Amazon EC2 Hpc7a インスタンス は、現在、米国東部 (オハイオ)、欧州 (アイルランド)、US GovCloud の 3 つの AWS リージョンにおいて、 オンデマンド 、 リザーブドインスタンス 、 Savings Plans で購入できます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 Hpc7a インスタンスのページ にアクセスし、 HPC チーム 、 AWS re:Post for EC2 、または通常の AWS サポート連絡先にお問合せください。 — Channy 原文は こちら です。

医療情報システムとは、医療に関する患者情報を扱うシステム全般を指し、安全かつ信頼性のあるアーキテクチャで構築、運用される必要があります。 具体的には、日本では 3 省 2 ガイドライン ( 厚生労働省が定めた「 医療情報システムの安全管理に関するガイドライン 」 、総務省・経済産業省が定めた「 医療情報を取り扱う情報システム・サービスの提供事業者に おける安全管理ガイドライン 」の総称 ) に対し、医療機関等と共に関連事業者や責任者が要求事項を整理検討し、必要に応じて対策を施す必要があります。 前回の 医療情報ガイドラインの改定から読み解くクラウド化 のブログでは、3 省 2 ガイドラインにおける医療情報を取り扱う情報システム・サービスの提供事業者と医療機関等の位置付けについて取り上げました。 厚生労働省のガイドラインは、医療情報システムのサービス提供事業者だけではなくサービスを委託する医療機関等が主体的に遵守する必要があります。医療機関等のシステム管理者および責任者は、ガイドラインの情報を整理し、サービス事業者との契約の際に、当該サービスを利用した運用形態がガイドラインに準拠していることを自ら確認する必要があります。下記の厚生労働省が公開している Q&A では、クラウド型の電子カルテサービスを例に挙げ、サービスを委託する際に医療機関等がガイドラインに準拠しているかを確認する必要性が明記されています。 Ｑ－23 クラウド型の電子カルテサービスを行う業者に認定制度のようなものはあるのか。もしなければ、業者を選定する際に３省のガイドラインに準拠していることは、どうやって確認すればよいのか。 Ａ 認定制度は現在のところ存在しません。なお、厚生労働省のガイドラインは、サービス提供業者ではなく、サービスを委託する医療機関等が遵守すべきものです。 サービス業者の選定に当たっては、「「医療情報を取り扱う情報システム・サービスの 提供事業者における安全管理ガイドライン」に準拠している旨」をサービス業者に確認させるとともに、契約を結ぶ際に、その旨を条項に盛り込んでおくとよいでしょう。 また、サービスを委託する医療機関は、当該サービスを利用した運用形態が、厚生労働省のガイドラインに準拠していることを、自ら確認してください。 「医療情報システムの安全管理に関するガイドライン 第 6.0 版」 に関するＱ＆Ａ 企画管理編 Q-23 より 抜粋 従来のオンプレミス型の医療情報システムでは、サーバ室の管理からハードウェア機器の管理まで、医療情報システムの担当者や責任者が確認すべき点は膨大な範囲でした。AWS を活用することにより、これらの一部をオフロードし、運用上の負担の軽減に役立ちます。（参考： AWS の クラウドが選ばれる 10 の理由 ） 本ブログでは、はじめに AWS の責任共有モデル に触れ、どのように医療機関等のお客様が負担をオフロードできるかについて整理します。次に、クラウド環境で医療情報システムを構築・運用する際に、特にご質問をいただくことの多いネットワークの観点で、Part 1 では厚生労働省の医療情報ガイドラインに即した医療情報システム構築におけるポイントとして、専用線的接続や VPN を利用し医療機関等の拠点とクラウドを接続するハイブリッド構成に焦点を当ててご紹介します。 医療情報システムにおける責任共有モデル 従来のオンプレミス環境では、お客さま自身のデータやアプリケーションの運用に加え、物理的なハードウェア、ネットワークなどのインフラストラクチャの管理などを行う必要があり、お客様の責任範囲は膨大となっていました。AWS では 責任共有モデル に従って、セキュリティとコンプライアンスは AWS とお客様の間で共有される責任としています。 セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。 責任共有モデル より抜粋 この共有モデルは、AWS がホストオペレーティングシステムの仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担の軽減に役立ちます。 また、お客様がクラウドサービス事業者を利用する際の多くは重層的な責任共有モデルとして考えられます。（参考： 責任共有モデルとは何か、を改めて考える ）。医療情報システムにおいても以下のように考えられます。 ここで、AWS は医療情報システムにおける 3 章 2 ガイドラインへ対応しているか？ という質問を多くのお客様よりいただきます。AWS では責任共有モデルに従って、お客様や AWS パートナーの皆様の固有のシステム要件やアプリケーションの要求事項に見合う形で、どのように各種 AWS サービスをご活用いただけるかということを検討するための AWS サービスに関する情報をご提供し お客様ご自身にご判断いただいております 。そのため AWS から一概に対応可否を回答しておりませんが、AWS パートナー各社作成の「 医療情報システム向け AWS 利用リファレンス 」を活用いただくことが可能です。 したがって、クラウドの利用においても医療機関等は仕組みを正しく理解した上で、ガイドラインを遵守した構築を医療情報を取り扱う情報システム・サービス提供事業者へ委託を行う必要があります。 ここまで責任共有モデルに従いクラウド ’の’ セキュリティ(Security ‘of’ the Cloud)をご紹介しましたが、AWS ではお客様が クラウド ’における’ セキュリティ(Security ‘in’ the cloud) を高めるためのマネージドサービスを提供しております。例として、マネージドサービスである、 Amazon GuardDuty ではマネージド型の脅威検知の仕組みを提供しており、お客様の AWS アカウント環境を保護するために役立つ機能を提供しております。AWS のセキュリティ、アイデンティティ、コンプライアンス関連のマネージドサービスは こちら よりご確認ください。また、これから AWS アカウントを取得される方向けに 最初にやるべき AWS セキュリティ設定 10 のこと のオンデマンドセミナーも開催しております。 その他にも、有償のコンサルティングサービスである、 AWS Professional Services ではガイドラインへの対応に向けた支援メニューも提供しています。ぜひ、クラウド導入に関する相談については、 お問合せ窓口 よりお気軽にお問合せいただければと思います。 医療機関等とクラウドを結ぶハイブリッド構成 ここからは、厚生労働省のガイドラインで触れられている医療機関等と外部の接続について整理し、お客様のクラウドにおけるセキュリティを高めていただくため、専用線的接続や VPN を利用し医療機関等と医療情報システムを結ぶハイブリッド構成について紹介します。 ガイドラインの 6.0 版では システム運用編 [Control] の「13. ネットワークに関する安全管理措置」にて、医療機関等を外部と接続する際の遵守事項と考え方が整理されています。特に考え方の部分では、接続先が限定された「セキュアなネットワーク」と、接続先や接続先への経路が管理されていない「オープンなネットワーク」について紹介されており、遵守事項の②では、原則としてセキュアなネットワークを利用することが述べられています。一方で、「13 . 1 . 2 選択すべきネットワークのセキュリティ」では、専用線や IP-VPN による接続は高コストであるために多目的な利用にはなじみにくい状況に触れ、IPsec 等の技術を用いてインンターネット VPN を利用し、オープンなネットワーク経由でセキュアなネットワークへ接続するパターンについても触れられています。 AWS では Amazon VPC (Virtual Private Cloud) を利用し、論理的に隔離されたお客さまの仮想ネットワークを構築可能です。VPC 内には仮想サーバーである Amazon EC2 インスタンス等の各種リソースを起動できます。VPC はガイドライン内で示されるセキュアなネットワークに該当します。デフォルトでは閉じたネットワーク空間ですが、 インターネットゲートウェイの関連付け を設定することで、インターネットとの接続も可能です *1。 それでは、医療機関等とクラウドを接続した構成 (ハイブリッド構成)を、 AWS Direct Connect を利用したセキュアなネットワーク上で接続する方法と、 AWS Site-to-Site VPN により IPsec VPN を利用してオープンなネットワーク上で実現する方法について紹介します。 *1 NAT ゲートウェイ を利用することで、VPC内へのインバウンドの通信を拒否しつつ、アウトバウンドの通信のみを許可することも可能です。IPv6 の場合は Egress-Only インターネットゲートウェイ を利用することで制御可能です。利用例としては OS やミドウルウェアのアップデートに外部への接続が必要なケースなどがあります。 a. セキュアなネットワークを用いた接続 セキュアなネットワークを利用した接続のユースケースとしては、クラウド型電子カルテなどのミッションクリティカルな医療情報システムが考えられます。セキュリティ観点では、患者のゲノム情報などを扱うケースも特に機密性の高い情報を扱う場合も一例として考えられます。また、データ量の観点では PACS (医用画像管理システム)のような高解像度の医用画像の転送等により大容量の通信が想定されます。 AWS Direct Connect は、クラウドとオンプレミスや拠点を専用線的接続するためのサービスです。プライベートなネットワーク接続を提供し、大量のデータの転送やリソースの共有を効率的に行います。AWS は世界中の多くの地域に Direct Connect ロケーション と呼ばれる接続拠点を有しており、日本国内では 2023 年 5 月に追加された印西データセンター を含め 4 箇所(記事執筆時点: 2023 年 8 月 22 日) の Diect Connect ロケーションが利用可能です。回線は専用接続を利用する場合、1 Gbps、10 Gbps、100 Gbpsの速度が選択できます。ホスト型接続の場合は、50 Mbps、100 Mbps、200 Mbps、300 Mbps、400 Mbps、500 Mbps、1 Gbps、2 Gbps、5 Gbps、10 Gbpsの速度が選択できます。また、オンプレミスや拠点等のお客様環境から Direct Connect ロケーションまでの接続について、 AWS Direct Connect デリバリーパートナー の支援が利用できます。その他の検討ポイントとして Direct Connect の料金 は、ポート使用料と物理回線費用が必要となりますが、アウトバウンド料金が通常のインターネット向けと比べてデータ量あたりの費用が低い（インバウンドの料金はどちらも無料です）ため、この点を考慮するのが良いでしょう。AWS Direct Connectに関する解説は、 [AWS BlackBelt Online Seminar] AWS Direct Connect (動画は こちら )から確認できます。 大学・研究機関において、国立情報学研究所 (NII) が構築、運用している学術情報ネットワーク (SINET:Science Information NETwork) を利用されている場合は、SINET 経由で AWS を利用する SINET クラウド接続サービス も選択肢として考えられます。 【大学・研究機関向け】学術情報ネットワークSINET経由でのAWS利用の基本情報とアップデート のウェビナーを開催しておりますのでぜひご確認ください。 b. オープンなネットワーク上で IPsec VPN を用いたセキュアな接続 オープンなネットワーク上で IPsec VPN を利用したセキュアな接続のユースケースとしては、医療情報の 2 次利用基盤としてクラウドを活用するケースなどが想定されます。スモールスタートでクラウドのスケール可能な計算リソースを活用する場合にも適していると考えられます。その他にも、Direct Connect のバックアップ回線を安価に用意する方法としても選択できます。 AWS Site-to-Site VPN は、AWS のマネージド VPN サービスの 1 つであり、クラウドとオンプレミスのネットワークを IPsec を用いて安全かつ暗号化された接続で結ぶためのサービスです。インターネット回線とIPsec 対応ルーター、固定 Public IP があれば、容易に環境構築ができスモールスタートで始められる点がメリットです ( プライベート証明書 による認証の場合、非固定 Public IP にも対応可能)。Site-to-Site VPN であれば、オンプレミスのネットワークと VPC 間でのセキュアな通信を確立し、プライベート IP アドレス同士で通信することも可能です。医療機関等のオンプレミス側でセットアップする必要のあるカスタマーゲートウェイデバイスの要件は ドキュメント から参照できます。AWS Site-to-Site VPN に関する解説は、 [AWS BlackBelt Online Seminar] AWS Site-to-Site VPN (動画は こちら )から確認できます。 c. 発展的なネットワーク構成 医療機関等におけるクラウドの活用が進むにつれて、いくつかの課題が出てくることも想定されます。 例として、本ブログでは 2 つケースを取り上げ、それらを解決する発展的なアーキテクチャを紹介します。 ケース 1 ）クラウドで稼働する医療情報システムの増加 クラウドで運用される医療情報システムが増えることに伴い各システムへの個々の VPN 接続を行う場合、接続数が増え VPN ルータの管理運用の負荷が高まることが想定されます。これらはクラウドに限らず、従来より医療機関と外部システムを繋ぐ際にルータの管理をされていた担当者の方は経験のある話かと思います。 ケース 2）マルチテナントの医療情報システムにおける、接続先の医療機関の増加 マルチテナント SaaS 型サービス事業者の視点からネットワークを考えると、複数の医療機関と VPN 接続が必要となるため、 セキュリティ観点の課題や IP アドレス範囲の重複の課題が考えられます。 ケース 1 に対しては、 AWS Transit Gateway を利用した複数 VPC への接続が、ケース 2 に対しては AWS PrivateLink を利用した閉域 SaaS アーキテクチャが役立ちます。 ケース 1 のように、医療機関等をクラウドで稼働する複数の医療情報システムに接続する場合は AWS Transit Gateway が利用できます。ルーティングは Transit Gateway のルートテーブルおよび、各 VPC に紐づくルートテーブルで制御が可能です。さらに、 AWS Network Firewall を利用することでオンプレミスとクラウド間の通信のセキュリティを高めることも可能です。 AWS Network Firewallのデプロイモデル のブログでは Transit Gateway と Network Firewall を組み合わせ、インターネットからの入口を集約しトラフィックを検査する構成なども紹介しています。 AWS PrivateLink を利用すると、インターネットを経由させることなく VPC と AWS のリソース間の通信が可能です。ケース 2 において SaaS 事業者の VPC 内にある NLB (Network Load Balancer) に対して VPC エンドポイントを用意することで、セキュアにアクセスすることが可能です。また、直接 VPC 間をピアリング接続しているわけではないため、IP アドレスが重複していたとしても問題なく動作します。エンドポイントの名前解決には Route53 Resolver の Inbound Endpoint が利用できます。 また、SaaS 型で医療情報システムを提供されている事業者は、 AWS PrivateLink Ready パートナー に認定に認定されると、AWS と共同で製品のマーケティングを推進することもできますので、こちらもぜひご検討ください。詳細は AWS PrivateLink を利用した SaaS アプリケーションへのセキュアな接続 のブログから確認できます。 まとめ 本ブログでは、はじめに AWS の責任共有モデルに触れ、どのように医療機関等のお客様が運用の負担を軽減できるかについて紹介しました。また、医療機関等とクラウドをセキュアに接続する方法として専用線的接続や VPN を利用したネットワーク構成について解説しました。ネットワーク編 Part 2 では医療機関等のクライアント端末やサーバーからオープンなネットワークを利用した接続について解説を行う予定です。本稿が、医療情報システムをクラウド上に構築する医療機関等および医療情報を取り扱う情報システム・サービス提供事業者のみなさまの参考になれば幸いです。今後もお客様をサポートし、課題解決に寄与できればと考えております。 本記事では 2023 年 8 月時点での AWS 環境上で医療情報ガイドラインに対応するための考え方や関連する AWS の情報を概説しました。最新状況は、ぜひ AWS コンプライアンス「 日本の医療情報ガイドライン 」のページをご確認ください。 著者について 片山 洋平 (Katayama, Yohei) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。     尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。

現代のダイナミックな市場におけるサプライチェーンの管理には多くの課題があります。なぜなら、企業は急速に変化する消費者需要、技術の進歩、経済の不安定性、競争の激化に対処しなければならないからです。 これらの要因は需要と供給のバランスを崩し、業務の複雑さを増します。 供給計画、つまり顧客の需要を満たすために必要な製品（または原材料や部品）の数量を見積もるプロセスは、サプライチェーンの最も重要な分野の1つです。 従来、供給計画担当者は、需要予測とサプライヤーのリードタイムデータを元に平均値や固定値を使用してこれらの計算を行っていました。 その後、計画担当者は余剰在庫の割合を加算して安全在庫を確保します。 このアプローチでは、リードタイムの変動や物流の遅延が考慮から外され、一定の誤差が生じるため、過剰在庫や在庫不足が発生します。 マッキンゼー・アンド・カンパニーによると、 2022年小売業者は在庫不足を緩和するために在庫を過剰に購入し続けたため 、余剰在庫は 12% 増加して 740 億ドルになりました。こうした状況に対し機械学習（ ML ）を活用した供給計画プロセスを採用することで、変化する状況や傾向に合わせてダイナミックな対応を行うデータドリブンで予測的な供給計画モデルを使用できます。 ガートナーは、 2026年までに商用サプライチェーンソリューションの 75% 以上が、高度な分析 ( AA )、人工知能 ( AI )、データサイエンスまたは機械学習 ( ML ) ベースの機能を標準プロセスに組み込むと予測しています。 このブログ記事では、クラウドベースのアプリケーションである AWS Supply Chain が ML ベースのリードタイム変動検出を使用して計画の精度を向上させる方法について説明します。 これにより、企業は顧客満足度を犠牲にすることなく、より優れたコスト管理戦略を実現できます。 従来型と ML ベースの2 つの供給計画アプローチを使用する場合の違いと、ML 機能によって精度がどのように向上するかについて学びます。 ML ベースのリードタイム計算と従来の方法との比較 2つの供給計画手法の違いを理解するために、一般的な消費財企業のシナリオを元に作成した以下の数値例を考えてみましょう。 下記のグラフは、従来の供給計画手法と ML ベースの供給計画方法を使用した在庫計画を示しています。 黒い線は毎月の需要を表しており、これは受注数量によるものです。 オレンジ色の線は、固定リードタイムまたは平均リードタイムを使用して従来の方法で計算された在庫レベルを表しています。 需要ラインと在庫ラインの両方が前月比で変動します。 季節的な需要によって大きな変動が生じる可能性があるため、需要ラインの変動が予想されます。 オレンジ色の線の変動は、ある月では在庫過多を引き起こし、他の月では在庫不足を引き起こすことを表しています。 固定的なデータのみ利用して計画するとこの種の変動の一因となるため、供給計画担当者は、需要を逃さないように必要な在庫を過大に見積もりして供給計画を手動で調整します。 このアプローチは有効ですが、その結果として、計画担当者がモデルの調整に費やす時間が長くなったり、余剰在庫によりコストが増加したりします。 青い線は、ML ベースの方法で計算された月次在庫レベルを表します。 この方法では、過去と現在の取引（未処理注文や出荷など）の両方を使用して、10パーセンタイル（ P10 ）、50パーセンタイル（ P50 ）、90パーセンタイル（ P90 ）に基づいて確率的リードタイム予測を決定します。 ML アルゴリズムは、曜日 (配送タイムライン用)、出荷数量 (履歴量)、輸送レーン定義 (出荷元、出荷先、インコタームズ（貿易取引条件）などの特性を含む) などの主要な製品機能を使用して予測モデルを作成およびトレーニングします。 これらの特徴量は、注文リードタイムや予測に影響するデータポイントですが、平均値を用いるリードタイムの見積もり方法では無視されています。 ML アルゴリズムは、これらの変数の変化を学習に組み込んで調整するため、確率的なリードタイム予測が計算されます。 P50 は納期の推定値を示しますが、P10 と P90 は製品の配送シナリオの最良シナリオと最悪のシナリオを評価するのに役立ちます。 上のグラフでは、P50 を使用して供給量を計算しています。 2つの在庫レベルの計算アプローチの違いは、需要と供給のばらつきを使用して比較することもできます。 需要と供給のばらつきは、需要予測と計画在庫レベルの差であり、通常は毎月追跡されます。 以下のグラフは、前述の例の需要と供給のばらつきを計算し、各供給計画アプローチの分散値を示しています。 グラフの X 軸は、1 月から 12 月までの月を表します。 Y 軸は需要予測と計画在庫の差を表し、マイナス 15 からプラス 25 までの数値を一覧表示します。 需要と供給が完全に一致している理想的なシナリオでは、分散値は 0 になります。 これは黒い点線で示され、比較のベースラインです。 オレンジ色の線は、従来の計画方法と平均リードタイムを使用した分散値を表しています。 青い線は ML モデルを使った分散値を表します。 従来のアプローチ（オレンジ色の線）のばらつきは、プラス面とマイナス面の両方に顕著です。 正の分散値は、供給レベルが需要を上回っていることを意味し、過剰在庫の状況を示しています。 過剰在庫は過剰な運転資本を必要とし、在庫が傷みやすいものや季節限定のものである場合にはほかのリスクを招きます。 負の分散値は、供給レベルが需要よりも低いことを意味し、在庫切れの状況を示しています。 在庫切れは、顧客の喪失、収益の損失、顧客満足度の低下につながる可能性があります。 ML ベースのアプローチ（青い線）は、ばらつきが少なく、より正確な供給計画を実現します。 ML モデルは適応性もあるため、多くの情報を収集すればするほど正確になります。 AWS Supply Chain で ML ベースのリードタイム変動検出を使用する AWS Supply Chain は、ML ベースのアルゴリズムを使用してリードタイムの変動を検出するのに役立つビジネスアプリケーションです。 このアプリケーションでは、過去の処理済みトランザクションと、未出荷や未発送などの処理中のトランザクションが考慮されます。 ML アルゴリズムには、季節性、製q33品特性、ベンダーの特徴、配送先サイトなどの追加情報も組み込まれ、モデルをトレーニングします。 ユーザが運用パラメーターと条件を定義すると、アプリケーションがトランザクションを監視して、予測リードタイムと予想される配送日（信頼レベル付き）を算出します。 AWS Supply Chain は想定リードタイムとの差異を計算し、その差異がユーザー定義の許容範囲 (標準偏差) を超える場合は、リードタイムを見積もり直すことを推奨します。 この ML ガイドによるリードタイムの変動検出により、供給計画担当者は需要を満たす適切な在庫レベルを自信を持って維持できます。 ウォッチリストによるリードタイムの逸脱に関するインサイトの監視 AWS Supply Chain はお客様のサプライチェーンネットワークを監視し、注文、出荷、在庫移動などのトランザクションデータから学習します。 ユーザーは、製品、場所などの特定の監視対象のパラメーターを、追跡する過去の期間などの条件とともに定義できます。 監視する基準と対象のパラメーターを指定して、ウォッチリストを作成します。 AWS Supply Chain アプリケーションでは、 [インサイトウォッチリストを作成] を選択します。 次の画面が表示され、追跡する主要なパラメーターを入力します。 まず、製品、場所、またはこれら2つの組み合わせを選択します。 次に、リードタイム標準偏差 (リードタイム差異の許容範囲) と時間間隔を入力してリードタイムデータを追跡します。 このウォッチリストを他のユーザーと共有するには、 [ウォッチャー] ボックスに名前を追加します。 次のスクリーンショットは、指定した基準に違反している製品について警告するインサイトダッシュボード画面を示しています。 このダッシュボードは、ウォッチリストに追加したユーザーとも共有されます。 ダッシュボードには、赤いボックスで特定の製品に対する基準違反が警告表示されます。 たとえば、次のスクリーンショットのダッシュボードには、 Deluxe Styler のリードタイムが Dallas DC で逸脱していることが示されています。 次に、Deviation (偏差) ボックスを選択すると、偏差の詳細を示す次の画面が表示されます。 画面には、ユーザ設定の初期の情報に基づいて期待するリードタイムが表示され、それに対する推奨リードタイムが表示されます。推奨リードタイムは、機械学習を使用して計算され、過去の実績に基づいて行われます。 ML は、過去の実績と予想されるパフォーマンスをモデル化し、予測値、あるいは設定値の 5 日間の目標ではなく、19 日間の予想リードタイムを推奨しています。 また、このアプリケーションでは、過去の実績データに基づいて、この場所での Miss Frequently (目標逸脱の頻度) が 100% であることも報告されます。 インサイトでは、進行中の注文の期待される ( expected ) 納期を確認することもできます。 次のスクリーンショットは、未処理の発注書と、サプライヤー、製品、数量の一覧を示しています。 画面には、調整後のリードタイムに基づく受領予定日と、信頼度が低い日付と信頼度の高い日付が表示されます。 これらの日付では、過去のパフォーマンスに基づく統計的モデリングが考慮され、納品可能な日付の範囲がわかります。 これにより、実際のパフォーマンスに基づいた総合的なビューが得られるため、供給計画を調整できます。 他のチームメンバーとのコラボレーション コラボレーションはサプライチェーンにとって不可欠な機能です。 前のセクションで説明した供給計画の変更には、他のチームとの調整とコラボレーションが必要です。 従来、供給計画の調整に関する連絡は、電子メールまたは電話で行われていました。 この方法は有効ですが、解決に遅延が生じたり、会話中に同じ情報を共有していないことで問題が生じる可能性があります。 AWS Supply Chain にはコラボレーションツールが組み込まれているため、チームメンバーはアプリケーションを離れることなくチャットして問題について話し合い、解決できます。 ユーザーは同じ画面で同じ情報をチャット画面に表示できるため、コミュニケーションと解決をより迅速に行うことができます。 結論 現代の市場は活発に変動する性質を持っており、顧客はそれに対応して、供給計画戦略の進化が求められています。 静的データと平均リードタイムに依存する従来の方法では、誤差、過剰在庫、在庫不足、および不要な経費が発生する可能性があります。 供給計画に機械学習を導入すると、計画の精度が向上し、需要と供給のばらつきが減少します。 ML はサプライヤーのリードタイムの異常を検出して計画を修正し、効果的なリスク軽減措置を実施します。 異常の検知や、長期利用に対する適応もリアルタイムで行われているため、最適化された、効率的で機敏なサプライチェーンが継続的に維持されます。 サプライチェーンの可視性が継続的かつ向上することで、ボトルネックや潜在的な混乱を特定できるようになり、また、意思決定を迅速化することで、業務に影響を与えることなく潜在的な問題軽減を迅速に行うことができます。 これらの改善により、顧客の需要に効果的に対応し、市場や環境の変化に適応し、運用コストを削減できるようになるため、サプライチェーンのレジリエンスが向上します。 ML ベースのリードタイム偏差に関するインサイトを利用するには、 AWS Supply Chain &nbsp; にアクセスして詳細を確認してから始めましょう。 また、&nbsp; AWS Workshop Studio にアクセスして、ご自分のペースでインスタンスの作成、データの取り込み、ユーザーインターフェイスの操作、インサイトの作成、在庫リスクの軽減、他のユーザーとのコラボレーション、需要計画の生成についての概要をご確認ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は17年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン500企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。ヴィクラムはノースダラス地域を拠点としています。 <!-- '"` -->

資材のインバウンドサプライチェーンの目的は、予備部品、補修可能部品、消耗品を予定されたメンテナンス作業に間に合うように工場に届けることです。 しかし、パフォーマンスの低さ、チーム間の信頼の欠如、資材調達における可視性の低さなどが原因で、頻繁に再計画が行われ、メンテナンス作業を確実に実行するために必要以上に慌ただしくなります。 主要な鉱業およびエネルギー企業は、クラウドコンピューティング技術を活用して以下のようにビジネス成果の向上とリスクの軽減を図るケースが増えています。 作業開始日より前に資材が確実に届くようにすることで、設備のダウンタイムを削減します。ビジネス機会の規模は、運用設備1件あたり年間 $3 ～ 6M と推定されています。 メンテナンス実施チームが作業の移動や資材を探す時間を減らし、より多くの時間をメンテナンス作業に費やすことで、メンテナンスの生産性が向上します。 ビジネス機会の規模は、生産性が 5 〜 8% 向上することです。 資材の状態が可視化され、ベースとなるデータへの信頼性が確保されれば、余剰在庫が少なくなります。ビジネス機会の規模としては、在庫レベルを 1 〜 5% 削減し、速達便と航空貨物の出荷を 2 〜 5% 減らすことです。 エンジニアが直接かつガイド付きで購入できるようにすることで、調達の間接コストを削減します。 これにより、調達プロセスが合理化され、調達の役割が取引からコンサルティング業務へとレベルアップします。 目下のビジネス機会は、調達支出を最大 5% 削減することです。 このブログでは、特に鉱業およびエネルギー業界向けの保守の注文を監視・管制するコントロールタワーのユースケースと、関連するビジネス成果を紹介します。 クラウド技術を活用した保守の注文を監視・管制するコントロールタワー 私たちのビジョンは、各利害関係者が資材の流れを維持するために主要なアクションを完全に可視化し、彼らの決定がビジネス総コストに与える影響を理解できるようにする保守の注文（ MO ）の監視・管制するコントロールタワーを実現することです。 特定の日に MO をスケジュールまたは再スケジュールすることが、資材の入手可能性、メンテナンスの生産性、移動、宿泊施設の利用率にどのような影響を与えるかを透明化できます。 このビジョンに向かって進むには、企業はメンテナンス計画の段階とMOの計画段階の両方でデジタル機能と機械学習 ( ML ) 機能を構築する必要があります。 メンテナンス計画の時点での考慮事項 データドリブンな機械学習を活用した需要予測とシミュレーションによる将来の需要の可視化 メンテナンス計画の時点で、チームは一般に、大まかな作業と実行日を計画してスケジュールを立てるときに、必要な資材が現場にあることが確実ではありません。 その結果、頻繁な再計画とそれに伴う移動作業の両立、資材の発送依頼、メンテナンス作業のための人員の調整、資材が確実に利用できるようにするための安全在庫レベルの設定といったやりくりが必要になります。 サプライヤーは、将来の資材需要がどうなるかを把握できていません。 将来の需要の可視化は、生産計画に役立ち、購入者との関係を改善することにもつながります。 メンテナンス作業の再計画を減らす、つまり、期日通りに実行されるメンテナンスの注文を増やす 、そしてバランスの取れた在庫管理を実現するために、大手企業はクラウドベースのテクノロジーを資材需要予測、安全在庫分析、および What-if シナリオに適用しています。 Amazon SageMaker を用いた機械学習( ML )により、以下の要素を組み合わせて資材需要計画プロセスをサポートします。 今後の活動における資材需要予測のための過去の資材消費量 エンタープライズリソースプランニング（ ERP ）ソフトウェアシステムにおける機器向けの資材の消費ベースのデータ、また機器の設置台数ベースのデータ 後者では、分析を行って機器と資材の故障率（平均故障間隔）を計算できます。 これにより、メンテナンスプランナーは、メンテナンス作業、資材需要、および過去の資材消費量の可視性を自動的に予測できます。 また、将来の MO に関連する作業リストや部品表を簡単に確認できるようになります。 AWS はパートナーの Deloitte とともにあるエネルギー企業を支援し、データ品質 (資材マスターデータや作業リスト BOM など) に制約があったにもかかわらず、全資材の 25% の需要予測をうまく自動化できました。 さらなる取り組みの強化により、データ品質の問題にデータ拡張技術で対処すれば、全資材の約 50% までカバー範囲が拡大する可能性があります。 これにより、メンテナンス計画作業の半自動化が可能になります。 さらに、資材需要予測に基づいて、安全在庫レベルは静的ではなく動的に計算されます。 この計算では、希望するサービスレベル、資材の重要度、手持ち在庫、納期、資材のリードタイムが考慮されます。 資材管理者は、積極的に在庫を管理して全体的な在庫レベルを下げることができるため、安全在庫レベルの動的な計算によるメリットがあります。 最後に、What-if シミュレーション（たとえば、開始日を1か月変更するなど）により、生産の可用性、コスト、MO のスケジュール変更に伴う安全性への影響を可視化し、さらにはメンテナンス活動全体を経時的に把握できます。 これにより、メンテナンスのスケジューラーとプランナーは、特定の日に MO をスケジュールするときに、必要な資材のオンサイト在庫状況への影響をすばやく確認できます。 さらに大きく考えてみましょう。 このビューは資材だけに限定されるべきではありません。 人件費、移動、宿泊施設の利用状況、そして最も重要なことですが、保守対象の設備の稼働時間に関する潜在的なリスクなどの関連情報を使用して、ビジネス全体でのコストを検討しましょう。 ビジネスの全体像を把握するために、企業は強固な基盤となるデータプラットフォームと、 Amazon S3 を搭載した Lake House Architecture などの構造を通じて提供される強固なデータ構造が必要です。これにより、関連する財務、運用、資材の情報をすべて保存して迅速に取得できます。 資材入手と計画精度向上のための、現実的なベンダーリードタイムと輸送リードタイム 資材が現場に到着するまでにかかる時間についての情報が不十分なため、メンテナンスプランナーは MO の開始日を自信を持ってスケジュールできないことがよくあります。 直接購入の場合、ベンダーのリードタイムはエンドツーエンドのリードタイム全体の 60% 以上を占めることがよくあります。 また、アウトライン契約（他の業界のフレーム契約と同様）が締結されていなかったり、最近更新されていなかったりすると、メンテナンスプランナーは信頼できる情報を得ることができません。 SageMaker を用いた機械学習( ML )は、過去の PO ( Purchase Order ) 情報を分析して実際のベンダーリードタイムを予測します。 設備や機器の標準化があまり行われていないため、資材購入は一回限りのものであることが多く、過去のデータが不十分な場合は常に、同様の資材を使用して、 XGBoost などの監視付き ML アルゴリズムを資材レベルまたは資材グループおよびベンダーレベルで実行する必要があります。 これらのモデルでは、決定係数が 0.7 を超えると強い相関関係であることが証明されています。 重要な課題は、モデルが予測する信頼水準 ( 95% の確率水準など) を定義することです。 実際には、これは予測到着日が、必要なオンサイト日付より大幅に前にならないように予測アルゴリズムがトレーニングされていることを意味し、その結果、大量のバッファーが使用され、MO 計画が非現実的になります。 これとは対照的に、モデルで予測されるリードタイムが短すぎると、メンテナンスプランナーは信頼を失い、MO のタイムリーな実行がリスクにさらされます。 以下のグラフは、予定納期、ベンダー名、インコタームズ（貿易取引条件）、PO 作成月など、ベンダーのリードタイム予測に影響する要因の例を示しています。 このチャートは、特定のベンダーに関する高水準または低水準の予測因子、つまりどの要因が資材の到着を遅らせる可能性があるかをユーザーに提供します。 さらに、過去のベンダーの実績と契約上の義務を比較することで、ユーザーはそれに応じてベンダーの実績を管理しやすくなります。 インコタームズ(貿易取引条件)が買い手に輸送の手配を要求する場合（工場出荷時など）には、輸送、特に国際海上貨物輸送のリードタイムを予測する2番目の ML モデルを構築する必要があります。 船舶到着時刻の予測に機械学習を使用すると 、業界で広く使用されている従来の手動見積もり方法と比較して、陸上業務の計画と実施の精度が大幅に向上します。 メンテナンスの注文が計画されている場合 購入した資材の可視性 鉱業・エネルギー企業が資材のサプライチェーンを運営する際の共通の課題は、メンテナンスの利害関係者が注文承認から現場での入手までの進捗状況に関して、資材の可視性が限られていることです。 これは特にベンダーからの直接購入に当てはまり、在庫からの供給にもある程度は当てはまります。 調達チームとロジスティクスチームは、どの資材がクリティカルパスにあるのか、あるいはすでに遅延しているのかを把握することがほとんどできません。 また、どの作業を優先すべきかについてのガイダンスも不足しています。 このような可視性の欠如は、重要な資材が必要なときに現場にない場合や、予定日に間に合うように届くかどうか確信が持てない場合に、メンテナンス作業をリスクにさらします。 資材のコントロールタワーは、必要な資材がプロセス全体にわたってどのように進んでいるかを可視化します。 MO の承認からオンサイトでの納品まで、進捗状況を追跡するための一連のマイルストーンが定義されています。 この可視性により、メンテナンスの実行、調達、物流などのユーザーは、計画された実行日より前に資材が届くという貴重な洞察と確信を得ることができます。 さらに、可視性は、資材の流れと資材サプライチェーンにおける信頼を確保するために必要なアクションの優先順位付けと調整に役立ちます。 たとえば、調達チームは月に何千件もの購買依頼を処理しているのに、どの資材要求や関連アクションが最も重要か、どの資材が重要なのか、どの資材が重要なのか、どの資材が重要なのか、あるいはすでに遅延しているのかを理解していないことがよくあります。 優先順位付けエンジンは、ユーザーにいくつかの重要な作業を指示し、資材や注文の重要度、アクションやエスカレーションなどのサプライチェーンのさまざまな参加者が制御できるコンテキスト情報を提供します。 資材調達の進行が妨げられたり、状況の可視性が悪かったりすると、要求の所有者にとって資材の状況や解決の責任者が不明瞭になることがあります。 たとえば、ベンダーが品目を製造・納品できなくなった場合、資材が旧型のものになる可能性があります。 こうした障害は、発注と配送のプロセスの複数の段階で発生し、例えば PR ( Purchase Requisition )時や見積依頼（ RFQ ）の作成時に検知しうるものです。ソリューションが提供する推奨事項は、これに基づいて非常に状況に応じたものでなければなりません。 資材のコントロールタワーは、こうした障害を検知するコグニティブ機能を備えているだけでなく、類似のサプライヤーを見つけたり、クラスタリング技術を使って代替可能な資材を特定したりするなど、重要な推奨事項を提示するコグニティブ機能を備えています。 資材のコントロールタワーは資材の流れに焦点を当てており、計画と実行の両方のプロセスにまたがる MO 実行を監視・管制するコントロールタワーという私たちのビジョンの重要な構成要素です。 MO 実行を監視・管制するコントロールタワーには、資材だけでなく、メンテナンス実行チームや、メンテナンス作業の実行に必要なその他の活動（航空機やキャンプの運用など）も含まれています。 業界をリードする AWS のお客様の中には、AWS のサービスである AWS Supply Chain を活用して、次の 4 つのコア機能に沿った資材の追跡と推奨事項の提供を検討しているところもあります。 システムをまたぐデータの容易な接続 : 関連するメンテナンス計画、調達、ロジスティクスのデータはサイロ化していることが多く、関連するチームやユーザーは、エンドツーエンドのサプライチェーン全体にわたる資材の状態に関する使いやすいビューを作成するのに苦労しています。 AWS Supply Chain は、このようなサイロ化されたデータへのアクセスを支援し、事前にトレーニングされた自然言語処理 ( NLP ) モデルである ML アルゴリズムを使用して、既存のデータをターゲットデータモデルに変換します。 ML を活用した洞察 : 次に、AWS Supply Chain はデータを地図上に関連付けて表示し、各倉庫とサイトにおける資材の進捗状況、現在の在庫選択と数量、在庫の状態を強調表示します。 ML を使用した資材到着時間の予測 : この ML モデルは、残りのすべてのマイルストーンにリードタイムを追加し、障害解決時間を考慮して現場での現実的な到着日を見積もることで拡張できます。 在庫についての推奨事項提供とコラボレーションの支援機能 : ユーザーは、推奨アクションや緊急の在庫問題に関するインサイトを自動的に得ることができます。 監視リストを設定して、潜在的なサプライチェーンのリスクがある場合にアラートを受け取ることができます。 また、コラボレーション機能も備えているため、ユーザーは互いに通信したり、システム内の関連情報を追跡したりできます。 コグニティブ調達により、ビジネスユーザーに迅速でデータドリブンで Amazon ライクな購入体験を提供 資材サプライチェーンの最適化において調達が重要な役割を果たす理由は2つあります。 第一に、鉱業会社やエネルギー会社の調達支出は数十億ドルに上る傾向があり、支出削減は会社の収益に直接つながります。 第二に、PR からベンダー側での PO 承認までの平均時間は、数週間ではないにしても、数日かかることがよくあります。 これは特に、時間のかかる承認プロセスが原因で、購入履歴の処理時間のばらつきが限られている品目に当てはまります。そのため、調達プロセスにかかる時間を自信を持って把握することが複雑になります。 調達変革の中核には、保守エンジニアなどのビジネスユーザーがベンダーから直接品目を購入できるようにすることで、調達チームを取引的で事後対応型の役割からコンサルティング型の役割に変えたいという強い要望があります。 こうした要望により コグニティブ調達エンジン ( COPE ) というオファリングが支持されており、COPE は次のような機能を提供しています。 設定された上限金額を下回る補修部品発注のセルフサービスを提供します。 資材の Amazon のような購入体験により、適切な製品をより迅速、簡単、効率的に調達するためのエンドツーエンドのプロセスを実現します。 製品、価格、サプライヤー、過去の支出、個人ユーザーエクスペリエンスに関する比較分析用のデータ。これにより、パンチアウト（企業購買システム内でのベンダー提供カタログによる購買)が強化され、補完されます。 推奨事項、購入パターン、代替製品、および機器のタイプ、役割、購入履歴に基づいた焦点を絞ったオプションセットにより、ビジネスユーザーのニーズにより的確に対応できます。 購買支出の完全な可視化による調達チームの継続的な管理と、必要に応じて例外発生時のエスカレーションプロセスを設ける。 あるエンジニアが COPE Web ポータルにログインすると、入力された検索語に対する製品の選択肢がいくつか表示されます。 購入画面には、商品がフィットする理由とそうでない理由が表示されます。 O リングの例では、アイテム1と2は使用目的に非常に適しています。 それでも購入者がアイテム3が適していると見なす場合は、最も安いこの製品を選択できます。 こうした場合でも、適切なプロセスに適した機器を用意することで、安全性と設備寿命が向上し、メンテナンスコストが削減されます。 COPE による Amazon のような購買体験は、今日の購買慣行を一新し、時間とリソースを消費する調達プロセスの大部分を自動化し、調達支出を 5〜8% 削減する機会を提供します。 特にガスケットなどの価値の低い品目の場合、組織は PR から納品までの時間を短縮し、ロングテール品目の調達にかかる人件費を、1取引あたり $200 —300 から $5 —25 に削減できます。 一括注文と調達プロセスの改善のための Amazon Business Chevron や Exxon Mobile などのいくつかの企業は、 Amazon Business を活用しさらに一歩進んでいます。 Amazon Business は、Amazon のユーザーフレンドリーなショッピング体験をベースに、マルチユーザービジネスアカウントにより、特定の権限を持つ購買グループの作成、ガイド付き購入、高度な検索機能といった強力な支出の可視化と分析を可能にする現代の調達に不可欠な機能と組み合わせて活用しています。 たとえば、Chevron は幅広い資材を調達しており、その多くは Chevron に代わってビジネスパートナーが管理していました。 マネージャーは月次の出荷日に向けて購買リストを作成していました。 リストの作成、見積もりの取得、見積もりの承認、注文、配送の受け付けには4〜6週間かかります。 メンテナンスチームなどの社内顧客は、必要なものを正確に手に入れるためのコントロールが限られていたため、多くの拠点が失望していました。 Chevron は、購買を Amazon Business に移行しました。これは、支出を集約し、ダイナミックな店舗環境で誰もが必要な商品を見つけることができ、なおかつ大量注文のメリットを享受できます。 Amazon Business は Chevron の SMART GEP システムである Punchout と統合され、シームレスなユーザーエクスペリエンスを実現しました。 各ユーザーが個別に実施した注文は、経費マスターの報告用に自動的に1つの購入カードにまとめられ、注文は週1回の配送（ Amazon Day ）にまとめられます。 資材カテゴリーが過去の取引に合わせて細分化されていたなど課題もあったものの、柔軟な支払い条件で発注するなどして、サプライヤーを集約しました。 結論 このブログでは、鉱業およびエネルギー企業がクラウドコンピューティング技術を使用して資材サプライチェーンを最適化するビジネス機会について説明しました。 ビジネス機会は、メンテナンス計画プロセス中と資材需要が確認されたときの両方に存在します。 メンテナンス計画と実行の安定性が向上すると、メンテナンス実施チームの生産性が 5～ 8% 向上し、費用のかかる速達便や航空貨物の輸送が 2 ～ 5% 削減され、設備ダウンタイムのリスクが軽減され、運用設備あたり年間 $3 ～ 6M になる可能性があります。 AWS では、エンドツーエンドのサプライチェーン全体で資材の状態を可視化し、必要な期日より前に資材が現場に届くという確度を高め、間接調達支出を最大 5% 削減し、サプライチェーンのパフォーマンスとコミットメントに対する信頼を高めるのに役立つサービスをいくつか提供しています。 資材サプライチェーン管理に関するあなたのアプローチを学び、議論したいと思っているので、コメントにあなたの意見を残してください。 複雑なサプライチェーンの課題解決に AWS がどのように役立つかを知りたい場合は、担当の AWS アカウントマネージャーに連絡して、鉱業、エネルギー、工業 ( MEI ) 業務の業界専門家や、サプライチェーンや物流の専門家によるディスカバリーワークショップを開催してください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Manuel Baeuml 博士は、アジア太平洋地域と日本の AWS ProServe サプライチェーンとロジスティクスの責任者です。Manuel と彼のチームは、主要なデジタルサプライチェーンの実践を共有し、AWS のクラウドテクノロジーとサービスを活用してお客様の喫緊のサプライチェーンの問題を解決する役割を持っています。過去 15 年間、彼は鉱業、エネルギー、小売/CPG、輸送、物流の分野で、アジア太平洋地域と ヨーロッパの業界リーダーと仕事をする機会に恵まれてきました。Manuel はシンガポールを拠点としています。 Ben van Vlietは、オーストラリアとニュージーランドの鉱業、エネルギー、産業分野の顧客を担当するシニア・カスタマー・デリバリー・アーキテクトです。Ben の仕事は、AWS ProServe のお客様がデジタル戦略と運用戦略を定義できるよう支援することから、サプライチェーン、産業用 IoT、グリーンフィールド製品開発における戦略的イニシアチブの策定と実施まで多岐にわたります。Ben は鉱業、 石油、ガスの分野で深い経歴を持ち、アウトバウンドのサプライチェーンの計画、メンテナンスの有効性、デジタルイノベーションの分野で実務担当やリーダーの役割を果たしてきました。Ben はオーストラリアのパースを拠点としています。 Brett Birkbeckは、オーストラリアとニュージーランドの鉱業、エネルギー、産業向けのソリューションアーキテクチャの責任者です。Brett は、お客様が AWS クラウドによる変革を実現できるよう支援する AWS プロフェッショナルチームを率いています。Brett は鉱業とエネルギーの分野で豊富な経験を持ち、デジタル戦略、テクノロジー主導の近代化、インダストリアル IoT、AI/ML、デジタルツインに関するアドバイスを提供しています。ブレットはオーストラリアのパースを拠点としています。 <!-- '"` -->

このブログは 2023 年 2 月 8 日に Luca Mezzalira (Principal Solutions Architect)、Federica Ciuffo (Sr. Containers Solutions Architect)、Laura Hyatt (Solutions Architect)、Vittorio Denti (Machine Learning Engineer)、Zamira Jaupaj (Enterprise Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 持続可能性 は、テクノロジー業界だけでなく社会全体にとっても重要なトピックであり、天然資源や環境を枯渇させることなく、長期間にわたってプロセスや機能を果たし続ける能力と定義されています。 持続可能なワークロードを設計するための重要な要素の 1 つは、ソフトウェアアーキテクチャです。イベント駆動型アーキテクチャがバッチ処理やキューなどのソリューションを活用して複数のマイクロサービスの負荷を軽減するのにどのように役立つかを考えてみてください。このような場合、多くのネットワークトラフィックはクラウドワークロードの入り口で処理され、システム内部への負荷の緩和に役立ちます。アーキテクチャに加えてデータパターン、ハードウェア最適化、マルチ環境戦略など、クラウドにおける持続可能な姿勢を促進するソフトウェア開発ライフサイクルの多くの側面について考えてみましょう。 重要なポイントは、持続可能性を念頭に置いて設計することで、耐久性があるだけでなく、ビジネスに必要な俊敏性を維持できる柔軟性を備えたアプリケーションを構築できるということです。 今回の投稿では、クラウドアプリケーションをより持続可能にするためのハンズオンアクティビティ、ケーススタディ、ヒントやコツを紹介します。 持続可能な設計と AWS の二酸化炭素排出量の削減 アマゾンウェブサービス (AWS) は、組織による AWS サービスの利用の評価と最適化を支援するために AWS Well-Architected Framework の 持続可能性の柱 を立ち上げ、組織が AWS フットプリントを監視、分析、削減できるように Customer Carbon Footprint Tool を構築しました。 このセッションでは、これらのプログラムの最新情報を提供し、AWS アーキテクチャを最適化するための最も効果的な手法に焦点を当てます。Amazon Prime Video がこれらのツールをどのように使用してベースラインを確立し、AWS 利用全体の効率を大幅に向上させたかをご覧ください。 この re:Invent 2022 の動画はこちら! 持続可能性を考慮してアーキテクチャを設計する方法を理解するための Prime Video のケーススタディ 持続可能性を実現するために最新のデータアーキテクチャを最適化 モダンなデータアーキテクチャは、ビジネスインテリジェンスを可能にする持続可能でスケーラブルなプラットフォームの基盤です。この AWS Architecture Blog シリーズでは、持続可能性を念頭に置いてモダンなデータアーキテクチャを開発する方法についてのヒントを紹介しています。 2 つの記事で構成されていて持続可能性を損なうことなく、現在のデータアーキテクチャを再検討して強化するのに役立ちます。 Part 1 はこちら! | Part 2 はこちら! AWS データ・アーキテクチャ：持続可能性を考慮する時です AWS Well-Architected Labs: Sustainability このワークショップでは、AWS Well-Architected Framework を参加者に紹介します。AWS Well-Architected Framework は、パフォーマンス、拡張性、コスト効率のよいアプリケーションを AWS 上で設計および運用するための一連のベストプラクティスです。ワークショップでは、ソフトウェアアーキテクチャにとって持続可能性がいかに重要であるか、また AWS Well-Architected Framework を使用してアプリケーションの持続可能性パフォーマンスを向上させる方法についても説明します。 ワークショップはこちら! 持続可能性導入のベストプラクティスとモニタリング Rust と AWS Graviton によるクラウド内の持続可能性 この動画では、 Rust と AWS Graviton がエネルギー消費量の削減とパフォーマンスの向上にもたらすメリットについて学ぶことができます。Rust は C などのプログラミング言語のリソース効率と Java などの言語のメモリ安全性を兼ね備えています。また、この動画では、パフォーマンスとコストが最適化されたクラウドワークロードを提供するように設計された AWS Graviton プロセッサから得られる利点についても説明しています。このリソースは、持続可能性がどのようにコスト最適化の原動力になり得るのかを理解するのに非常に役立ちます。 re:Invent 2022 動画はこちら！ Rust と AWS Graviton がワークロードの持続可能性とパフォーマンスを向上させるのにどのように役立つかをご覧ください また次回お会いしましょう！ クラウド内の持続可能性についてのディスカッションにご参加いただきありがとうございます。2 週間後にアーキテクト向けのツールについてお話ししますので、またお会いしましょう。 このシリーズのすべてのブログを検索するには、AWS Architecture Blog の Let’s Architect! のコンテンツのリストをチェックしてください。 翻訳はネットアップ合同会社の Yotaro,Iwai 氏、監修はソリューションアーキテクトの沢田 吉伯が担当しました。 TAGS: case study , data architecture , Let’s Architect , re:Invent , software , Sustainability , workshop Luca Mezzalira Luca Mezzalira はロンドンを拠点とするプリンシパル・ソリューション・アーキテクトです。複数の著書を持ち、国際的な講演者でもある彼は、主にソリューション・アーキテクトの分野で専門知識を発揮しています。ルカは、マイクロフロントエンドを使ったフロントエンドアーキテクチャのスケーラビリティに革命をもたらし、ワークフローの効率化から製品の品質向上に至るまで高い評価を得ています。 Federica Ciuffo Federica Ciuffo は、AWS のシニア コンテナ ソリューション アーキテクトです。彼女はネットワークとコンテナに情熱を持っています。オフィスの外では、読書や絵を描いたり、友人たちと時間を過ごしたり、レストランでさまざまな料理の新しい料理を試したりすることを楽しんでいます。 Laura Hyatt Laura Hyatt は、AWS 公共部門のソリューションアーキテクトであり、英国の教育機関の顧客を支援しています。 Laura は、お客様がスケーラブルなソリューションを設計および開発するだけでなく、現在教育セクターが直面している問題に対して、革新的なソリューションを考える一役を担っています。 Laura の専門は IoT で、EMEA 全体の教育向け Alexa SME も務めています。 Vittorio Denti Vittorio Denti は、ロンドンを拠点とする Amazon の機械学習エンジニアです。ミラノ工科大学 (ミラノ) と KTH 王立工科大学 (ストックホルム) でコンピューターサイエンスとエンジニアリングの修士号を取得後、AWS に入社しました。 Vittorio は分散システムと機械学習のバックグラウンドを持っています。彼は特にソフトウェア エンジニアリングと機械学習科学の最新のイノベーションに情熱を注いでいます。 Zamira Jaupaj Zamira Jaupaj は、オランダを拠点とするエンタープライズ ソリューション アーキテクトです。彼女は非常に情熱的な IT プロフェッショナルであり、中小企業向けのコンテナ、サーバーレス、データ分析を使用した重要で複雑なソリューションの設計と実装において様々な国で 10 年以上の経験を持っています。

この記事は Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate (記事公開日 : 2023 年 8 月 9 日) の翻訳です。 導入 Amazon Elastic Container Service ( Amazon ECS ) タスクは、同時かつ同一の AWS Fargate インスタンス または Amazon EC2 コンテナインスタンス にスケジューリングされる、1 つ以上のコンテナで構成されます。コンテナでは Linux namespace を使用してワークロードの分離を実現するため、Amazon ECS タスク内で複数のコンテナが一緒にスケジューリングされた場合にも、コンテナ同士、あるいはコンテナとホスト間は分離されます。 本日より、AWS Fargate 上の ECS タスクで Linux カーネルパラメータを調整できるようになりました。Linux カーネルパラメータを調整することで、コンテナ化されたネットワークプロキシの ネットワークスループットを最適化 したり、不要な接続を適切に終了するように TCP キープアライブパラメータを調整 し、ワークロードの信頼性を向上させることが可能になります。今回の発表により、AWS Fargate を使用する際にも、Amazon EC2 を使用する場合とより近い形で ECS タスクを実行できるようになりました。 さらに、本日より AWS Fargate 上の ECS タスク内のすべてのコンテナ間で、プロセス ID (PID) namespace を共有できるようになりました。ECS タスク内のコンテナ間で PID namespace を共有することで、AWS Fargate ワークロードの可観測性を実現する手段が広がります。例えば、コンテナランタイムセキュリティツールなどの可観測性ツールをサイドカーコンテナとして実行し、同じ ECS タスク内のコンテナのプロセスを監視することが容易になります。 awsvpc ネットワークモード を使用した場合の Network namespace に加えて、PID namespace も、AWS Fargate 上の ECS タスク内のコンテナ間で共有可能な namespace の一員となりました。 この記事では、AWS Fargate の System Controls と PID namespace の共有について深堀りしていきます。 System controls Linux システムでは、コマンドラインユーティリティ sysctl でカーネルパラメータを調整できます。 Docker や finch などのコマンドラインインターフェースを使用してコンテナをローカルで起動する場合、 --sysctl フラグを指定することでカーネルパラメータを変更できます。ECS タスクの場合、 タスク定義 の systemControl キーでパラメータを定義できます。 コンテナ化されたネットワークプロキシを AWS Fargate 上で実行しているお客様からは、ワークロードにおいてより高いスループットを実現するために net.* カーネルパラメータを調整する必要がある、という 声 を頂いていました。特に要望が多かったカーネルパラメータには、接続要求を格納するキューの深さ net.core.somaxconn や、TCP/UDP 接続時に使用する一時的なエフェメラルポートの範囲 net.ipv4.ip_local_port_range などがあります。 信頼性の高いワークロードを設計する際に、AWS Fargate 上の ECS タスクの TCP キープアライブパラメータをカスタマイズしたい、という声も頂いていました。短い TCP キープアライブタイムアウトを設定することで、アプリケーションはネットワーク障害を迅速に検知し、失敗した接続を閉じることができます。TCP キープアライブを調整するユースケースの例としては、コンテナワークロードが Amazon Aurora PostgreSQL クラスター と通信している場合や、Amazon VPC NAT Gateway の トラブルシューティング を行う場合などが考えられます。 以前は、EC2 上で ECS タスクを実行する場合にのみ systemControl キーを設定可能でしたが、本日より AWS Fargate 上の ECS タスクにおいても、同様に設定可能となります。2 つのカーネルパラメータを調整する Amazon ECS タスク定義の例を以下に示します。 { ... "containerDefinitions": [ { "name": "myproxy", "image": "111222333444.dkr.ecr.eu-west-1.amazonaws.com/myproxy:latest", "essential": true, "systemControls": [ { "namespace": "net.core.somaxconn", "value": "6000" }, { "namespace": "net.ipv4.ip_local_port_range", "value": "1024 65000" } ] } ] } AWS Fargate / Amazon EC2 上の ECS タスクで設定可能なすべてのパラメータは、 Amazon ECS ドキュメント で確認できます。 IPC namespace のカーネルパラメータを使用する場合、IPC namespace はタスク内のコンテナ間で共有されないため、各コンテナに固有の値を設定できます。一方、Network namespace のカーネルパラメータを使用する場合、1 つのコンテナにパラメータを設定すると、タスク内のすべてのコンテナのパラメータが変更されます。具体的には、以下のように設定が適用されます。 コンテナ 1 に net.ipv4.tcp_keepalive_time=100 を設定した場合、この変更はコンテナ 2 にも反映されます。 コンテナ 1 に net.ipv4.tcp_keepalive_time=100 を、コンテナ 2 に net.ipv4.tcp_keepalive_time=200 を設定した場合、タスク内で最後に起動するコンテナのパラメータのみが適用されます。 PID namespace の共有 PID namespace は、コンテナ内のプロセスが参照可能なプロセスを制限します。デフォルトでは、コンテナ内のプロセスは同じコンテナ内のプロセスのみを参照でき、他のコンテナ内、または実行基盤となるホスト上のプロセスは参照できません。コンテナ間で PID namespace を共有する一般的なユースケースとして、可観測性ツールがあります。コンテナランタイムセキュリティツールは、多くの場合サイドカーコンテナで実行されます。このとき、サイドカーコンテナ内のプロセスがアプリケーションコンテナ内のプロセスを監視し、不審なシステムコールが実行されていないかどうかを確認します。 今回の発表により、タスク定義内の pidMode キーの値を task に設定することで、AWS Fargate においても ECS タスク内のコンテナ間で PID namespace を共有できるようになりました。 ウォークスルー このウォークスルーでは、まず PID namespace を共有した ECS タスクを作成します。このタスクには、アプリケーションコンテナ (nginx) とサイドカーコンテナ (デモ用の sleep プロセス) の 2 つのコンテナが含まれています。その後、サイドカーコンテナ内のプロセスが、アプリケーションコンテナ内のプロセスとどのようにやり取りできるかを確認します。 前提条件 このウォークスルーでは、Amazon VPC 内に作成した Amazon ECS クラスターを使用します。自身の AWS アカウントで新たに作成する場合は、 Amazon ECS getting started guide を参照してください。 AWS アカウントとコマンド実行環境の両方において、 ECS exec の前提条件 を満たしていることを確認してください。 AWS Fargate 上で ECS タスクを実行する 1. pidMode を有効化した、2 つのコンテナを含むタスク定義を作成します。以下の例では、タスク定義内の IAM ロール ( executionRoleArn と taskRoleArn ) を、前提条件で作成した IAM ロールに置き換えてください。 $ cat &lt;&lt;EOF &gt; taskdef.json { "family": "fargatepidsharing", "executionRoleArn": "arn:aws:iam::111222333444:role/ecsTaskExecutionRole", "taskRoleArn": "arn:aws:iam::111222333444:role/ecsTaskExecRole", "networkMode": "awsvpc", "requiresCompatibilities": [ "FARGATE" ], "containerDefinitions": [ { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:1.25-perl", "essential": true }, { "name": "sleeper", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "essential": true, "command": [ "sleep", "infinity" ], "linuxParameters": { "initProcessEnabled": true } } ], "cpu": "256", "memory": "512", "pidMode": "task" } EOF 2. aws ecs register-task-definition コマンドを実行し、タスク定義を登録します。 $ aws ecs register-task-definition \ --cli-input-json file://taskdef.json 3. aws ecs run-task コマンドを実行し、AWS Fargate 上で ECS タスクを実行します。以下の例では、ECS クラスター名、VPC サブネット、セキュリティグループの値を置き換える必要があります。外部からこのタスクにアクセスする必要はないので、プライベートサブネットと、イングレスルールを持たないセキュリティグループ (デフォルトのセキュリティグループなど) で十分です。 $ aws ecs \ run-task \ --count 1 \ --launch-type FARGATE \ --task-definition fargatepidsharing \ --cluster mycluster \ --enable-execute-command \ --network-configuration "awsvpcConfiguration={subnets=[subnet-07bd4d10ea848a008],securityGroups=[sg-061b33f4ed6b97c34],assignPublicIp=DISABLED}" 4. ECS タスクが正常に起動したら、 aws ecs execute-command コマンドを実行して、ECS タスク内のサイドカーコンテナでターミナルセッションを開始します。このコマンド実行時にエラーが発生する場合は、 amazon-ecs-exec-checker スクリプトを使用して、すべての前提条件を満たしていることを確認してください。 # ECS タスク ID を取得する $ aws ecs list-tasks \ --cluster mycluster { "taskArns": [ "arn:aws:ecs:us-west-2:111222333444:task/moira-prod/5ce56f226dd4477a9f57918a98fc852f" ] } # 実行中の ECS タスクで bash シェルを起動する $ aws ecs execute-command \ --cluster mycluster \ --task 5ce56f226dd4477a9f57918a98fc852f \ --container sleeper \ --interactive \ --command "/bin/bash" 5. ECS exec のターミナルセッションで、共有した PID namespace を確認できます。そのために、サイドカーコンテナ内に診断ツールをインストールします。 $ yum install procps strace -y 6. ps コマンド (上記でインストールした procps パッケージに含まれます) を使用することで、共有した PID namespace で実行中のすべてのプロセスを確認できます。このコマンドの出力には、サイドカーコンテナのプロセスだけでなく、アプリケーションコンテナの nginx プロセスも表示されます。また、ECS exec の機能を提供する AWS Systems Manager Session Manager のプロセスも表示されます。 $ ps -aef --forest UID PID PPID C STIME TTY TIME CMD root 38 0 0 09:53 ? 00:00:00 /managed-agents/execute-command/amazon-ssm-agent root 72 38 0 09:53 ? 00:00:00 \_ /managed-agents/execute-command/ssm-agent-worker root 34 0 0 09:53 ? 00:00:00 /managed-agents/execute-command/amazon-ssm-agent root 73 34 0 09:53 ? 00:00:00 \_ /managed-agents/execute-command/ssm-agent-worker root 266 73 0 09:58 ? 00:00:00 \_ /managed-agents/execute-command/ssm-session-worker ecs-execute-command-0147ec3fd84d94d24 root 276 266 0 09:58 pts/1 00:00:00 \_ /bin/bash root 286 276 0 09:59 pts/1 00:00:00 \_ ps -aef –forest root 8 0 0 09:53 ? 00:00:00 /dev/init -- sleep infinity root 19 8 0 09:53 ? 00:00:00 \_ sleep infinity root 7 0 0 09:53 ? 00:00:00 nginx: master process nginx -g daemon off; 101 56 7 0 09:53 ? 00:00:00 \_ nginx: worker process 101 285 7 0 09:59 ? 00:00:00 \_ nginx: worker process root 1 0 0 09:53 ? 00:00:00 /pause 7. PID namespace を共有することで、アプリケーションコンテナ内のプロセスが実行するシステムコールを監視することができます。ステップ 5 でインストールした strace パッケージを使用して、メインの nginx プロセスを監視してみましょう。システムコールを生成するには、 kill コマンドで nginx ワーカープロセスを強制終了します。以下の例では、メインの nginx プロセスは PID 7 で、ワーカープロセスは PID 56 です。これらの値は実行する環境によって異なる場合があるため、自身の環境に合わせて値を置き換えてください。 # プロセスの監視を開始する $ strace -p 7 -o straceoutput.txt &amp; # nginx ワーカープロセスを強制終了する $ kill -9 56 # プロセスの監視ログを表示する $ cat straceoutput.txt rt_sigsuspend([], 8) = ? ERESTARTNOHAND (To be restarted if no handler) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=56, si_uid=101, si_status=SIGKILL, si_utime=0, si_stime=0} --- gettid() ... このウォークスルーでは、PID namespace を共有することで、サイドカーコンテナ内のプロセスが ECS タスク内の他のコンテナで実行中のすべてのプロセスを参照し、監視できることを確認しました。ステップ 7 では、アプリケーションコンテナ内のプロセスを強制停止させ、それに伴ってアプリケーションコンテナ内で実行されるシステムコールをサイドカーコンテナから確認しました。 後片付け 以下の手順を実行し、作成したリソースを削除します。 1. ECS Exec のターミナルセッションで exit コマンドを実行し、ECS exec を終了します。 2. aws ecs stop-task コマンドを実行し、ECS タスクを停止します。 $ aws ecs stop-task \ --cluster mycluster \ --task 5ce56f226dd4477a9f57918a98fc852f 3. aws ecs deregister-task-definition コマンドを実行し、ECS タスク定義を登録解除します。 aws ecs deregister-task-definition \ --task-definition fargatepidsharing:1 PID namespace を共有する際の注意点 AWS Fargate 上の ECS タスク内のコンテナ間で PID namespace を共有できるようになりましたが、これには注意すべき点がいくつかあります。それらの注意点を、ウォークスルーで作成したアプリケーション/サイドカーコンテナの例に沿って説明します。 サイドカーコンテナ内のプロセスは、アプリケーションコンテナ内のプロセスを監視するだけでなく、停止または再起動できます。 サイドカーコンテナ内のプロセスは、アプリケーションコンテナのファイルシステムに部分的にアクセスできます。例えば、アプリケーションが PID 7 として実行されている場合、サイドカーコンテナ内では /proc/7/root/ にあるアプリケーションコンテナのファイルシステムにアクセスできます。このとき、Unix ファイルパーミッションが、アプリケーションコンテナのファイルシステムを保護する唯一の仕組みとなります。 ECS タスクで PID namespace を共有する場合、 pause プロセスが PID 1 として新しく実行されます。 アプリケーションコンテナ内で実行されるプロセスの完全なトレーサビリティを実現するためには、ECS タスクに SYS_PTRACE Linux capability を追加することを検討してください。 まとめ 今回の発表によって、AWS Fargate 上でより多くのワークロードを実行されることを楽しみにしています。PID namespace の共有とカーネルパラメータの調整は、 AWS Containers Roadmap でリクエストされていた機能です。私たちは皆様の声を大切にしており、GitHub issue による追加の機能要望や改善に関するフィードバックを心待ちにしています。AWS Fargate のセキュリティアーキテクチャの詳細については、 AWS Fargate セキュリティホワイトペーパー を参照してください。

このブログは 2023 年 8 月 14 日に Virgil Ennes（Specialty Sr. Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 多くのお客様は、プラットフォーム間で権限モデルが異なっていても、Linux と Windows から同時にアクセスができる高性能な共有ファイルシステムを必要としています。たとえば、メディアとエンターテイメント企業では、Linux と Windows クライアントでワークロードを双方でレンダリングする場合があります。これらのお客様は、「ユーザー名マッピング」などのメカニズムを使用して、Windows クライアントから NFS 経由で共有ファイルシステムをマウントし、ファイルアクセスの競合を回避できるようにしています。 Amazon FSx for OpenZFS （FSx for OpenZFS）はフルマネージドの AWS サービスとして、高性能アプリケーション向けのスケーラブルな OpenZFS ファイルシステムを提供します。スナップショットや暗号化などのデータ管理機能を備え、100 万以上の IOPS と 21 GB/s のスループットをサポートし、ビッグデータや、DevOps、研究のワークロードに適しています。異なるオペレーティングシステムと独自の権限モデル間のギャップを埋めるために、多くお客様では「ユーザー名マッピング」などのソリューションを使用して、NFS 経由でのシームレスなファイル共有を実現しています。 この記事では、Network File System（NFS）プロトコルバージョン 3 を使って、FSx for OpenZFS に保存されているデータを Linux と Windows クライアントで同時に共有するためのさまざまな認証方法を紹介します。これにより、クロスプラットフォームでのデータアクセスや、セキュリティ強化、効率的なデータ管理が可能になり、生産性の向上とリソースの最適化につながります。 NFS と FSx for OpenZFS のバックグラウンド NFS は Linux のネイティブプロトコルです。Linux 標準の mount コマンドと、ボリュームに関連付けられたドメインネームシステム（DNS）名を使用して、FSx for OpenZFS を Linux にマウントできます。 NFS プロトコルのバージョン 3 および 4.0、4.1、4.2 を使用して、FSx for OpenZFS ファイルシステム上のデータにアクセスできます。Linux クライアントは NFS バージョン 3 と 4.x をネイティブにサポートしており、Linux 標準の mount コマンドを使用してファイルシステムをマウントします。Windows クライアントは NFS バージョン 2 と 3 をサポートしており、NFS クライアントのインストールが必要です。 Linux クライアントと Windows クライアントを同時に FSx for OpenZFS に接続する場合は、両方のプラットフォームでサポートされている NFS バージョンである NFS バージョン 3 を使用します。 AWS 記事の「 新機能 – Amazon FSx for OpenZFS 」では、FSx for OpenZFS ファイルシステムのセットアップに関する情報を提供しています。 ソリューションのウォークスルー このソリューションを実装する手順の概要を以下に示します。 Windows に NFS クライアントをインストールして設定する Windows クライアントより NFS プロトコルを使用して&nbsp;FSx for OpenZFS をマウントするために必要です。 ファイルシステムをマウントする FSx for OpenZFS ファイルシステムを Windows クライアントと Linux クライアントの両方からマウントして、データにアクセスできるようにします。 ID マッピングと NFS 認証方法を選択して設定する ユーザー名マッピングサーバー、または Active Directory（AD）統合、匿名認証のいずれかを選択して、FSx for OpenZFS のファイルにアクセスするユーザーをマッピングし、認証します。 1. Windows に NFS クライアントをインストールして設定する Windows に NFS クライアントをインストールして設定する必要があります。Windows に NFS クライアントをインストールする手順は以下のとおりです。GUI または Windows powershell が使用できます。 以下に、Windows Server 2019 で GUI を使用した手順の例を記載します（この手順は Windows Server 2022 でも利用できます）。 （a）インストール Windows サーバーにて「 サーバーマネージャー 」を開きます。 ダッシュボードの「 クイックスタート 」より「 役割と機能の追加 」を選択し、ダイアログボックスで「 次へ 」を選択します。 「 インストールの種類 」で、「 役割ベースまたは機能ベースのインストール 」を選択し、「 次へ 」を選択します。 「 サーバーの選択 」画面で、サーバー名を選択し、「 次へ 」を選択します。 「 サーバーの役割 」画面で、「 ファイルサービスと記憶域サービス 」を展開します。 「ファイルサービスと記憶域サービス」の「 記憶域サービス 」を選択し、「 次へ 」を選択します。 「 機能 」画面で、「 NFS クライアント 」を選択し、「 次へ 」を選択します。 「 確認 」画面で、「 インストール 」を選択します。 図 1: Windows サーバーで NFS クライアントのインストール （b）設定 Windows に NFS クライアントをインストールした後に、設定を行う必要があります。Windows サーバーの GUI 上で NFS クライアントを使用して、クライアントの設定と、既定のファイルのアクセス許可、セキュリティモデルをカスタマイズします。デフォルト設定（以下参照） は、ほとんどの環境で機能します。ただし、デフォルトのファイル権限が必要となるセキュリティ対策に対応しているか、Linux ディストリビューションのデフォルトと一致するかを考慮する必要があります。 ※補足：以下の「NFS 用サービス」ツールは、NFS サーバーの機能を追加する必要があります 図 2: Windows サーバーの NFS クライント – デフォルトのファイル権限 2. ファイルシステムをマウントする Linux と Windows クライアントにファイルシステムをマウントして、データにアクセスします。 ファイルシステムをマウントするために DNS 名が必要です。FSx コンソールを使用して、FSx for OpenZFS ファイルシステムの「 ネットワークとセキュリティ 」タブに移動し、DNS 名をコピーしてください。以下の 図 3 で、FSx for OpenZFS ファイルシステムの DNS 名が記載されている個所を示しています。 図 3: ファイルシステムの DNS 名取得 2. ファイルシステムの DNS 名と、以下の mount コマンド（基本的な mount コマンド）を使用して、Linux サーバーにファイルシステムをマウントします。 mount -t nfs -o vers=3 fs-04fcff18e33270111.fsx.us-west-2.amazonaws.com:/fsx/sync_vol /fsxsync 図 4: Linux にファイルシステムをマウント 3. 以下のコマンドを使用して、Windows サーバにファイルシステムをマウントします。 mount \\fs-04fcff18e33270111.fsx.us-west-2.amazonaws.com\fsx\sync_vol\ Z: 図 5: Windows にファイルシステムをマウント ファイルシステムの性能を最適化する手順については、FSx for OpenZFS の ドキュメント を参照してください。 3. ID マッピングと NFS 認証方法を選択して設定する Linux と Windows では、使用するアカウントとセキュリティシステムが異なります。Linux は、ユーザー識別子（UID）とグループ識別子（GID）でユーザーを表します。Windows は、一意のセキュリティ識別子（SID）でユーザーとグループを表します。ユーザー名マッピングは、Linux の UID と GID を Windows の SID に変換する、またはその逆に変換するプロセスです。ユーザー名マッピングは、Windows ユーザーが透過的にファイルへのアクセスと、変更、作成を行うためのクリーンなデフォルトの権限セットを提供します。 「NFS と FSx for OpenZFS のバックグラウンド」セクションで説明したように、NFS のサービスをインストールして設定したら、適切な ID マッピングと認証方法を選択して設定を行う必要があります。ユーザー名マッピングサーバー、または Active Directory（AD）統合、匿名認証を使用できます。 AUTH_SYS または AUTH_UNIX：アカウントマッピングに UID と GID 識別子を使用する AUTH_SYS または AUTH_UNIX アカウントマッピングは、Linux の UID と GID を、対応する Windows ユーザーおよびグループの SID と照合するプロセスです。 Windows 用の NFS クライアントでは、スタンドアロンサーバー用の %windir%\system32\etc\passwd を使用する方法と、ドメインに参加しているサーバー用に AD を使用する方法の、2 つのアカウントマッピング方法をサポートしています。 3.1 スタンドアロンサーバー：/etc/passwd /etc/passwd を使用して、Linux の UID と GID を Windows ユーザーおよびグループの SID へ 1 対 1 でマッピングします。 1. はじめに、Windows 用 NFS クライアントを使用して「 ユーザー名マッピングサーバー 」を指定します。この例では、マッピングサーバーはパスワードファイルを含むサーバーです。 図 6: Windows サーバーの NFS クライント – ユーザー名マッピングサーバー 2. 次に、パスワード（passwd）ファイルを Windows のパス %SYSTEMROOT%\system32\drivers\etc に配置します。ファイル内の各 Windows ユーザーや SID は、ファイル内の UID と GID に基づいて Linux ユーザーと照合されます。 3. /etc/passwd ファイルとマッピングサーバーを設定した後に、Windows で NFS クライアントを再起動します。powershell コマンドの nfsadmin client stop と、nfsadmin client start を使用できます。NFS クライアントを再起動する前に、ファイルシステムが Windows からアンマウントされていることを確認してください。 図 7: NFS クライアントの再起動 以下は、Windows クライアントの %SYSTEMROOT%\system32\drivers\etc にある /etc/passwd ファイルを使用したユーザーマッピングの例です。 図 8: Windows passwd ファイルの例 各行には、コロンで区切られた次のフィールドがあります：Windows ユーザー名, Linux UID, Linux GID, 説明, Windows ホームディレクトリ 以下の例では、Linux と Windows の両方に mary というユーザーを作成しました。Windows サーバーにログインしてファイルシステムをマウントした後、以下のような mount コマンドを実行することで、mary の UID と GID（この例では UID は 1002 、GID は 1007）が有効であることが確認できます。 図 9: マウントポイントの有効な UID と GID 4. Linux でファイルを作成し、Windows からそのファイルを確認します。Linux に mary のアカウントでログインして、 /sync_vol にマウントした FSx for OpenZFSファイルシステムへ mary-file-linux.txt という名前のテキストファイルを作成します。以下では、 mary-file-linux.txt ファイルの所有権と、グループメンバーシップ、権限を確認できます。 図 10: ファイルの権限 – Linux 5. Windows 側からそのファイルを確認します。 Windows で mary のアカウントでログインして、FSx for OpenZFS ファイルシステムをマップしたドライブを開きます。ファイルにアクセスすることができ、Linux と同じ所有権と、グループメンバーシップ、権限を保持していることがわかります。 図 11 の赤いボックスには、Windows によって割り当てられたファイル権限と、ユーザー ID、グループ ID が表示されています。 図 11: ファイル権限 – Windows ファイルプロパティ 6. Windows でファイルを作成し、Linux からそのファイルを確認します。 Windows に mary のアカウントでログインしてテキストファイルを作成し、FSx for OpenZFS のファイル共有をマップした Z: ドライブに保存します。 図 12: Z: ドライブに保存したサンプルテキストファイル Windows より、Windows の NFS クライアントが Linux 標準の所有者、グループ、その他、および R、W、X を使って権限を割り当てていることが確認できます。割り当てられた権限には、Windows の NFS クライアントに設定されたデフォルトのファイル権限が適用されています（ 図 3 ）。さらに、Windows に格納されている passwd ファイルから UID と GID が割り当てられています。 図 13: ファイル権限 – Windows ファイルプロパティ 7. FSx for OpenZFS の Linux マウントポイントより同じファイルを確認します。ファイルの内容を確認し、Windows で表示されている権限と所有権が Linux と一致していることが確認できます。 図 14: ファイル権限 – Linux さらに、ユーザー名は Linux から Windows、またはその逆の Windows から Linux で一致させる必要がないことに注意してください。たとえば、Windows の以下 passwd ファイルでは、Windows のユーザ jeff を UID 1004 にマッピングしています。Linux での UID 1004 は phill という Linux ユーザーです。Windows はマッピングに Linux ユーザー名（この例では phill）ではなく、UID を使用します。 図 15: ユーザー名マッピング – jeff を UID 1004（phill） 3.2 AD 参加サーバー 1. AD に参加しているサーバーの場合、AD ドメイン（本例では example.com）を使用するには、NFS クライアントで ID マッピングソースを選択する必要があります。 図 16: Windows サーバーの NFS クライアント – AD ドメイン名 2. 次に、AD 組織単位（OU）のユーザー共通名（CN）属性を更新する必要があります。ADSI エディタを使用して、Windows ユーザーの「GIDNumber」と「UIDNumber」を、対応する Linux ユーザーの Linux UID と GID に一致させるように更新します。以下の手順に従ってください。 a. AD ドメインサーバーで、Windows の検索バーに「adsi」と入力して ADSI エディターを開きます。 図 17: ADSI エディター b. ADSI エディターの「 Users 」サブツリーに移動し、ドメインから OU 内の該当ユーザーを選択します。該当ユーザーを右クリックして、「 プロパティ 」を選択します。 図 18: ADSI エディター – ユーザーの CN 変更 本例では、Windows ユーザー&nbsp;brian の CN 属性「 gidNumber 」と「 uidNumber 」を更新して、Linux ユーザー brian の UID 1013 と GID 1005 と一致させます。 c. uidNumber &nbsp;を 1013 に変更します。 図 19: ADSI エディター – uidNumber 属性の変更 d. gidNumber を 1005 に変更します。 図 20: ADSI エディター – gidNumber 属性の変更 3. Linux から Windows にマップするすべてのユーザーでこのプロセスを繰り返します。完了したら NFS クライアントを再起動します。NFSクライアントの再起動には、powershell コマンドの nfsadmin client stop と nfsadmin client start を使用します。NFS クライアントを再起動する前に、必ず Windows でファイルシステムをアンマウントしてください。 4. Linux にユーザー brian としてログインしてファイルを作成し、そのファイルの所有権と、グループメンバーシップ、権限を確認します。 図 21: Linux ファイル詳細 5. 最後に、example.com AD のドメインユーザー brian として Windows にログインしてファイルを確認します。Linux の所有権と、グループメンバーシップ、権限が Linux ユーザー brian のものと想定どおり一致していることが確認できます。 図 22: AD を使用したユーザ名マッピングの検証 3.3 AUTH_NONE：匿名認証 匿名認証を使用して、Linux ユーザーのユーザー ID とグループ ID を Windows クライアントにマップすることができます。 匿名認証は、ファイルシステムへの読み取り/書き込みアクセスを提供する一般的な方法です。ただし、ファイルへの書き込みアクセスを調停する厳密なメカニズムは提供されないことに注意してください。さらに、ユーザー/グループレベルで権限を設定することはできません。このため、匿名認証は推奨される方法ではありません。セキュリティが問題にならない状況でのみ検討してください。 匿名認証を設定するには、次のレジストリキーを追加し、再起動する必要があります。 New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value &lt;Linux_uid&gt; -PropertyType "DWord" New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value &lt;Linux_gid&gt; -PropertyType "DWord" レジストリキーを追加して再起動後、以下のように匿名オプション（ -o anon ）を使用して Windows にファイルシステムをマウントできます。UID と GID には -2 が割り当てられていることに注意してください。これは、匿名アクセスが使用中であることを意味します。 図 23: 匿名認証 クリーンアップ 今後不要な課金が発生しないようにするため、本ソリューションで使用されているリソースを削除したい場合は、 FSx for OpenZFS ユーザーガイド に従って、ファイルシステムをアンマウントし、FSx for OpenZFS ファイルシステムを削除してください。 まとめ この記事では、Windows サーバの NFS クライアントを使用して FSx for OpenZFS ファイルシステムのデータにアクセスし、Linux と Windows クライアント間でデータが共有できるようにする方法について説明しました。ファイルシステムをマウントし、認証によって保護し、パフォーマンスを調整するプロセスを確認しました。 主なポイントは、Linux プラットフォームと Windows プラットフォームの両方で FSx for OpenZFS を使用して、共有ファイルストレージに NFS プロトコルを使用できる点です。 その利点として、クロスプラットフォームのデータアクセスや、セキュリティの強化、効果的なデータ管理などがあり、生産性が向上し、リソースを最適化できます。この戦略を採用することで、FSx for OpenZFS のパワーを活用するだけでなく、異なるオペレーティングシステム間のギャップを効果的に埋めることができます。 FSx for OpenZFS サービスをより深く理解するために、以下の「リファレンス」セクションを詳しく確認してください。 リファレンス FSx for OpenZFS – OpenZFS ユーザーガイド FSx for OpenZFS パフォーマンス Nfsadmin Utility 翻訳はプロフェッショナルサービス本部の葉山が担当しました。 Virgil Ennes Virgil Ennes は AWS の Specialty Sr. Solutions Architect です。Virgil は、AWS が提供する俊敏性、コスト削減、イノベーション、グローバルリーチを活用できるようお客様を支援することを楽しんでいます。彼は主にストレージ、AI、ブロックチェーン、分析、IoT、クラウド経済学に焦点を当てています。余暇には、家族や友人と時間を過ごしたり、お気に入りのサッカークラブ（GALO）を見たりすることを楽しんでいます。

このブログ記事では、 IBM PC の物語と比較しながら、自動車アプリケーション向けのオープンハードウェアプラットフォームの導入が、自動車業界のイノベーション、ディスラプション、トランスフォーメーションの推進において同様の環境を作り出す可能性があることを紹介します。また、このブログ記事では、こうしたプラットフォームをリリースする最初の自動車業界の企業が得る可能性のある優位性についても議論します。 IBM が最初の PC を導入した経緯 1981年の IBM PC のリリースは、パーソナルコンピューティングの歴史における重要なマイルストーンでした。これは大企業が製造・販売した最初のパーソナルコンピュータであり、現代の世界を形作る一助ともなった、コンピュータ業界にとっての一つの標準を打ち立てました。 IBM PC の開発の物語は、1970年代後半、フロリダの IBM ボカラトン事業所のエンジニアチームがパーソナルコンピューターの開発プロジェクトに着手したときに始まりました。チームは Don Estridge が率いていました。Estridge ははっきりした目標を描いており、手頃な価格で使いやすく、ビジネスアプリケーションの実行に十分な処理能力を備えたマシンを作ることを目指していました。 1981年8月12日の IBM PC の発売は、コンピューター業界と社会全体に大きな影響を与えました。これにより、コンピューティングの民主化への道が開かれ、強力なテクノロジーをより多くのユーザーが利用できるようになりました。また、 PC をコンピューティングの主要なプラットフォームとして確立させ、現代では様々な形でPCが社会を形成していると言えます。 IBM PC の成功に貢献した主な要因の 1 つは、マシンのオープンアーキテクチャでした。IBM はコンピューターの技術仕様を他のメーカーにも公開しました。サードパーティ企業は IBM PC と互換性のあるハードウェアとソフトウェアを開発できるようになりました。これにより、製品とサービスのエコシステムが繁栄し、IBM PC は長年にわたってパーソナル・コンピューター市場の主要なプラットフォームとなりました。 IBM は、新しい製品やテクノロジーの革新と開発を続けることで、コンピューター業界の主要プレーヤーとしての地位を維持することができました。この結果、PC 業界のハードウェア製造の面では他企業が IBM を追い越し始めても、成長を続ける PC 市場から IBM は利益を得続けることができました。 IBM PC の物語は、車載ハードウェアでも繰り返されるでしょうか？ 今日、車載アプリケーション向けのオープンハードウェアプラットフォームはまだ存在していません。しかし、このようなプラットフォームの登場は、自動車業界にとって重要なマイルストーンとなる可能性があります。1980年代に IBM PC がパーソナル・コンピューター業界を変革したように、車載アプリケーション向けのオープンハードウェアプラットフォームは、新しいアイデアやイノベーションの急増につながる可能性があります。 IBM PC は相互運用性を念頭に置いて設計されてたため、さまざまなメーカーのソフトウェアとハードウェアのコンポーネントがシームレスに連携できました。同じように、ソフトウェア・デファインド・ビークル (Software Defined Vehicle, SDV) の開発者は、さまざまなコンポーネントやシステムがシームレスに連携できるような、車載アプリケーション向けのオープンハードウェアプラットフォームを目指すべきです。 車載アプリケーション向けのオープンハードウェアプラットフォームの仕様を作成した最初の自動車メーカーには、次の4つの優位性を得る可能性があります。 俊敏性の向上 オープンハードウェアプラットフォームでは、仮想化されたモデルをオープンに開発し共有することができます。このような仮想化モデルを使用することで、桁違いに多くの人々や組織が車載アプリケーションの作成に参加できるようになります。AWS は、お客様が必要に応じてリソースを迅速に立ち上げ、数分で数百、数千のコンピューティングインスタンスをデプロイできるように支援します。このような機能があれば、自動車メーカーはより迅速かつ頻繁に実験や革新を行うことができます。 その一例が Stellantis のバーチャルエンジニアリングワークベンチです 。 戦略的優位性 オープンハードウェアプラットフォームを最初に開発した自動車メーカーは、より迅速なイノベーション、ブランドの評判の向上、業界でのリーダーシップを通じて競争力を獲得する可能性があります。今後、ハードウェアはコモディティ化し、ソフトウェアが差別化要因となるでしょう。お客様に代わってイノベーションを起こす自動車メーカーにとって、AWS は最適なパートナーであると私たちは考えています。なぜなら、AWS は最も包括的なサービスを提供し、最大かつ最も活気のあるお客様・パートナーのコミュニティと、最も実績のあるオペレーションとセキュリティの専門知識を備えているからです。 コラボレーション 車載アプリケーション向けのオープンハードウェアプラットフォームは、構築と革新のための技術的基盤を提供するデファクトスタンダードとしての地位を確立することができます。車載アプリケーション向けのオープンハードウェアプラットフォームの仕様をインターネットで入手できることは、自動車メーカーに複数の利点をもたらす可能性があります。たとえば、自動車メーカーはこの仕様を使用して、新しい電子制御ユニット (ECU) 開発プロジェクトの技術的基礎をパートナーに伝えることができます。ソフトウェアベンダーはプラットフォーム用のアプリケーションを独立して開発できるため、これらの企業に新たな機会が開かれます。AWS では、この種のコラボレーションをサポートする 2 つのサービスが提供されています。 AWS Clean Rooms を使用すると、お客様とそのパートナーは、互いの元データ自体を共有したりコピーしたりすることなく、集計データのみをより簡単かつ安全に分析できます。 組織内では、共通の目標を共有しているが共通のデータセットを持たないさまざまな事業部門が Amazon DataZone を使用できます。Amazon DataZone を使用すると、お客様は組織の事業部門全体でデータを大規模に共有し、検索し、発見できます。さらに、統合データ分析ポータルを介してデータプロジェクトで協力することもできます。 環境の一致 ARM ベースの SoC (System On a Chip) は、さまざまな電子機器におけるデファクト・スタンダードです。これらの機器には、スマートフォン、タブレット、スマートウォッチ、および車載システムなどの組み込みシステムが含まれます。その結果、ハードウェアベンダーは、特に車載の中央演算ユニット向けに、 ARM ベースの SoC を自社の製品に組み込むことが増えています。 Amazon EC2 上で動作する ARM ベースの AWS Graviton プロセッサを使用すると、開発者は車載アプリケーションバイナリをコンパイルし、車載器同様に AWS クラウドでも実行できます。 その観点から、組み込みエッジ向け Scalable Open Architecture for Embedded Edge (SOAFEE） は、重大性が混在する (mixed criticality) 車載アプリケーション向けに、クラウドネイティブなアーキテクチャ設計と、対応するリファレンス実装を開発し、商用・非商用目的で提供することを目指しています。SOAFEE の組織運営メンバーには、ARM , Bosch, Cariad, Contintenal, RedHat, SUSE, Woven Planet, AWS が含まれます。 AWS は業界の変革をどう支えるか AWS は、仮想化された車載ハードウェアを実行および操作するための幅広いツールとリソースを提供しています。私たちは、ソフトウェアが主な差別化要因となる未来に向けた自動車業界の移行を支援することを決意しています。 詳細については、 AWS for Automotive のウェブサイトからお問い合わせください。 TAGS: SDV Daniel Schleicher Daniel Schleicher は AWS の Continental 社担当シニアソリューションアーキテクトで、ソフトウェアデファインドビークルを専門としています。彼はこの分野で、クラウドコンピューティングの原理を車載アプリケーションに適用し、仮想化されたハードウェアを利用して車載アプリケーションのソフトウェア開発プロセスを進めることに興味があります。以前の役職では、ダニエルは Volkswagen でエンタープライズ統合プラットフォームの AWS への移行を主導し、プロダクトマネージャーとして Mercedes Intelligent Cloud の中心的なサービスの構築に貢献しました。 Aleksandar Tolev Aleksandar Tolev は、アマゾンウェブサービスのソリューションアーキテクトマネージャーで、製造業と自動車業界のお客様に情熱を注いでいます。Aleksandar は、ソフトウェア開発と複雑な課題に対するリーンアーキテクチャの活用に情熱を注いでいます。余暇には、スポーツ、メンタルトレーニング、料理をするのが大好きです。 本記事は AWS ブログ Learning From the IBM PC : How an open hardware platform for automotive applications can help transform the industry を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。

AWS re:Invent 2021 の基調講演で、Werner Vogels 博士は、「 どこにでもあるクラウド 」が AWS のハードウェアとサービスを通して AWS を新しいロケールに提供している方法に関するインサイトを共有し、自身の ブログ記事 の中で 2022 年以降のテクノロジー予測の 1 つとして紹介しました。 「2022 年、そして今後さらに顕著になるのは、従来の一元的なインフラストラクチャモデルを超えて、特殊なテクノロジーを必要とする新しい環境へと加速するクラウドです。クラウドは、車、ティーポット、テレビの中に存在するようになります。道路を走るトラックから、物資を輸送する船や飛行機まで、クラウドはあらゆるものの中に存在するようになります。クラウドはグローバルに分散され、地球上だけでなく、宇宙上のほとんどすべてのデジタルデバイスやシステムに接続されるようになります」。 AWS は、大都市圏、5G ネットワーク、オンプレミスの拠点、モバイル、モノのインターネット (IoT) デバイスに至るまで、お客様が業務を行うさまざまな環境でクラウドからアプリケーションを構築して実行するための真に一貫したセキュアなエクスペリエンスを提供します。 詳細については、2023 年 8 月 30 日の午前 10 時 (太平洋夏時間) (東部標準時午後 1 時) から開催される参加費無料の 1 日の仮想イベント、 AWS Hybrid Cloud &amp; Edge Day にご参加ください。このイベントは、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch など、複数のプラットフォームで同時にストリーミングされます。 ハイブリッドクラウドとエッジコンピューティングの最新のトレンドや新しいテクノロジーに関する AWS のリーダーと業界アナリストの話を聞き、クラウド環境全体で AWS ハイブリッドクラウドとエッジサービスを使用するためのベストプラクティスを学ぶことができます。また、AWS のお客様からデータ戦略と主要なユースケースを学び、AWS ハイブリッドクラウドとエッジサービス、新機能と利点についての理解を深めることができます。 このイベントで予定されているハイライトをいくつかご紹介します。 リーダーシップセッション –&nbsp;キックオフとして、EC2 Edge のバイスプレジデント Jan Hofmeyr を迎え、最近発表された AWS ハイブリッドクラウド、エッジ、IoT 機能を使用して、お客様が高性能でインテリジェントなアプリケーションを構築している方法についてのインサイトを共有するリーダーシップセッションを開催します。次に、EK Media Group のリサーチ部門の長を務める Elias Khnaser 氏が加わり、ハイブリッドクラウドとエッジコンピューティングに影響を与えるグローバル、ビジネス、経済のトレンドについて話し合い、お客様の要件とユースケースについて議論します。 クラウドクローザーセッション –&nbsp;AWS が大都市圏や通信ネットワークにクラウドを近づけている方法について説明します。 AWS Local Zones 、 AWS Outposts ファミリー、 AWS Wavelength などのサービスは、クラウドコンピューティングとストレージのパワーを 5G ネットワークのエッジにもたらし、よりパフォーマンスの高いモバイルエクスペリエンスを実現します。AWS リージョンとエッジの間における運用の一貫性を活用した Norton LifeLock 、 Electronic Arts 、 Epic Games などの新しい革新的なユースケースを紹介します。また、MindBody、ElToro、Onica の例や その他のお客様事例 など、ハイブリッドクラウドシナリオをオンプレミスの拠点にデプロイする方法も紹介します。 オンプレミスセッション – AWS クラウドをデータセンターやオンプレミスの拠点に導入して、環境全体で真に一貫したエクスペリエンスを実現するためのオプションについて学びます。AWS のハイブリッドサービスとエッジサービスがどのようにデータのローカル処理、応答時間の短縮、迅速な意思決定を実現する方法について、実際の例を紹介します。また、 トヨタ が Amazon ECS と Amazon EKS のハイブリッドオプションを活用して、複数の環境にわたって使い慣れた管理ツールを使用してアプリケーションをモダナイズした方法も紹介します。デジタル主権とデータレジデンシーの重要な側面において、オンプレミスの規制要件と現実世界のシナリオを効果的に満たす方法を学ぶことができます。 堅牢なエッジセッション –&nbsp; AWS Snow ファミリー のような堅牢でモバイル、そして接続されていないエッジをサポートする AWS のサービスについて学びます。組織は、ネットワーク接続が拒否される、中断する、断続的になる、制限される環境 (DDIL = Denied, Disrupted, Intermittent or Limited) 接続のロケーションにコンピューティングワークロードをデプロイできます。 DDR.Live が AWS Private 5G を使用して、ワイヤレス接続が制限された場所でのライブイベント配信のために独自の 4G/LTE または 5G プライベートネットワークをデプロイした方法を紹介します。トレーニング済みのオブジェクト検出モデルのデプロイやエッジでのアプリケーションの設計など、主なユースケースについて説明します。最後に、エッジでの運用に関するメリットと要件について、Constellation Research, Inc. のバイスプレジデント兼プリンシパルアナリストを務める Holger Mueller 氏とのディスカッションが予定されています。 IoT パネルディスカッション – AWS IoT のお客様と業界の専門家のパネリストがイノベーションへのジャーニーについて議論します。 EuroTech が、エッジでの接続によって業務効率を向上させる一連のデバイスとサービスを市場に投入した方法を紹介します。EV の 充電会社である Wallbox が AWS IoT サービス で運用コストを削減し、効率性をスケールした方法についても紹介します。 マルチクラウドセッション – AWS は、ガバナンス、運用管理、オブザーバビリティなどの領域でマルチクラウドオペレーションを実行およびサポートする多くの ツール を提供しています。ハイブリッド環境とマルチクラウド環境の一般的な課題に加えて、AWS がプロセスの管理、運用、自動化にどのように役立つかを説明します。また、 Rackspace が AWS Systems Manager を使用してハイブリッド環境とマルチクラウド環境全体のインスタンスパッチを適用し、クラウドプロバイダー全体のインフラストラクチャ管理を自動化した方法も紹介します。 このイベントは、ハイブリッドクラウド、エッジコンピューティング、IoT、ネットワーキング、コンテンツ配信、5G について詳しく知りたいと考えているすべてのお客様とビルダーを対象としています。低レイテンシー、ローカルデータ処理、またはデータレジデンシー要件の理由でオンプレミスまたはエッジに配置する必要があるアプリケーションをサポートする方法について説明します。 詳細、イベントスケジュール、および AWS Hybrid Cloud &amp; Edge Day への登録については、 イベントページ にアクセスしてください。 — Channy 原文は こちら です。

様々な業界 (ヘルスケア、ライフ サイエンス、金融サービス、小売など) のお客様は、より強力なセキュリティ体制を必要としています。特に、ホストしているデータベースにクレジット カード番号や国民識別番号 (米国の社会保障番号など) などの機密データが含まれている場合、このデータを暗号化してデータベース管理者へのアクセスを制御できるソリューションを提供することが重要になります。 Always Encrypted は、このセキュリティ要件に対する Microsoft SQL Server の機能です。 Always Encrypted を使用すると、クライアントはクライアント アプリケーション内の機密データを暗号化し、暗号化キーをデータベース エンジンに公開することがなくなります。これにより、データを所有し閲覧できるユーザーと、データを管理するがアクセス権を持たないユーザー (データベース管理者、クラウド データベース オペレーター、またはその他の高い権限を持つ未承認ユーザー) が分離されます。その結果、Always Encrypted を使用すると機密データをクラウドに自信を持って保存できるようになり、悪意のある内部関係者によるデータ盗難の可能性を軽減できます。 Always Encrypted はアプリケーションに対して暗号化が透過的に行われます。クライアント コンピューターにインストールする Always Encrypted 対応ドライバーは、クライアント アプリケーション内の機密データを自動的に暗号化および復号化することで透過的なアクセスを実現します。ドライバーは、データをデータベースエンジンに渡す前に機微な情報を保持するカラムのデータを暗号化し、アプリケーションへのセマンティクスが保持されるようにクエリを自動的に書き換えます。同様に、ドライバーはクエリ結果に含まれる暗号化されたデータベースのカラムに保存されたデータを透過的に復号化します。 この投稿では、Windows 証明書ストアを使用して Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスに Always Encrypted を設定する方法を順番に説明します。 Always Encrypted で使用できる他のキー ストア (Azure Key Vault、ハードウェア セキュリティ モジュール) については、この記事の執筆時点ではサポートされていません。 前提条件 このソリューションをセットアップするには、次のリソースを備えた作業環境が必要です。 SQL Server がインストールされた開発ホスト (Always Encrypted 証明書が生成される Windows デバイス)。 Windows を実行している Amazon Elastic Compute Cloud (Amazon EC2) でホストされているターゲット アプリケーション サーバー。 SQL Server 2016 以降のインスタンス (RDS for SQL Server インスタンス)。 証明書ファイルを保存する Amazon Simple Storage Service (Amazon S3) バケット。 Always Encrypted 証明書。 開発マシンで実行されているローカル SQL Server インスタンスを使用して列マスター キーの証明書を生成するには、次の手順を実行します。 SQL Server Management Studio (SSMS) を使用して、暗号化するデータベースの セキュリティ ノードの下にある [ 列マスター キー ] フォルダーを開き、[列マスター キー] フォルダーを右クリックして、[新しい列マスター キー] を選択します。オプションを表示します。 証明書を「Windows 証明書ストア – 現在のユーザー」 キー ストアに保存します。 Microsoft 管理コンソール (MMC) の [ 証明書 ] オプションを使用して、Always Encrypted 証明書を見つけ、サムプリントをメモします (証明書を選択して詳細ダイアログ ボックスを開きます)。このサムプリントは、プロセスを自動化するために開発したスクリプトで必要になります。これまでに証明書スナップインにアクセスしたことがない場合は、ここに記載されている詳細な手順に従ってください。 Microsoft 管理コンソール (MMC)を開きます。 [ ファイル ]メニューに移動し、[ スナップインの追加または削除 ]オプションを選択します。 リスト化されている利用可能なスナップインから [ 証明書 ] オプションを選択します。 個人 / 証明書 フォルダに移動します。 「 Always Encrypted 証明書 」をダブルクリックします。 [ 詳細 ] タブを選択し、下にスクロールして、[ サムプリント ] プロパティを選択します。 次のダイアログ ボックスが示すように、[ ファイルにコピー ] を選択して、証明書を PFX ファイルにエクスポートします。 [証明書のエクスポート ウィザード] ダイアログ ボックスで [ 次へ ] を選択します。 「 はい、秘密キーをエクスポートします 」オプションを選択し、[ 次へ ] を選択します。 [ Personal Information Exchange (.PFX) 形式 ] オプションを選択し、[ 次へ ] を選択します。 パスワード を入力し、「 AES256-SHA256 」暗号化オプションを選択して、[ 次へ ] を選択します。 適切な パスとファイル名 を指定します。 [ 次へ ] を選択します。 [ 完了 ] を選択して、証明書のエクスポート プロセスを完了します。 このファイルを指定された S3 バケット にアップロードします。 RDS for SQL Server インスタンスで Always Encrypted を構成する 前提条件となる手順がすべて完了し、Always Encrypted 証明書を PSX ファイルに正常にエクスポートできたら、Amazon RDS for SQL Server インスタンスで Always Encrypted を設定する準備が整います。これを行うには、次の手順を実行します。 Microsoft リモート デスクトップ プロトコル クライアント (RDP) を利用して、ターゲットのアプリケーション サーバー (Windows EC2 クライアント) にリモートで接続します。 Amazon S3 からローカルフォルダーに証明書を含む PSX ファイル をダウンロードします。 証明書をターゲットとなるアプリケーション サーバーにインポート します。 以下に示すように、Always Encrypted オプションを有効にして SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server に接続します。 新しいクエリ ウィンドウを開き、「Enable parameterization for Always Encrypted」にチェックをいれます。 暗号化されたデータをホストするための新しいデータベースを作成します。 USE master; GO IF DB_ID('AlwaysEncrypted') IS NULL CREATE DATABASE [AlwaysEncrypted]; GO 前に取得した証明書のサムプリントを参照して、列マスター キーを作成します。 CREATE COLUMN MASTER KEY [AE_ColumnMasterKey] WITH ( KEY_STORE_PROVIDER_NAME = 'MSSQL_CERTIFICATE_STORE', KEY_PATH = 'CurrentUser/My/a619fb0c4029cfcd9d9e935dbb8dc98e0902000f', ); GO 列暗号化キーを作成します。 1 つのオプションは、SQL Server Management Studio GUI を活用することです。この場合、「Always Encrypted Keys」ノードの下に ある 「 Column Encryption Keys 」フォルダを見つけ、その フォルダ を 右クリック して「 新しい列暗号化キー 」オプションを 選択 します。列暗号化キーに対する適切な名前を入力し、上で作成した列マスター キーを選択して、 [OK] をクリック します。あるいは、以下の T-SQL スクリプトを利用することもできます。次のコードに示されている ENCRYPTED_VALUE を実際に使用している環境の証明書と一致するように調整してください。 CREATE COLUMN ENCRYPTION KEY [AE_ColumnEncryptionKey] WITH VALUES ( COLUMN_MASTER_KEY = [AE_ColumnMasterKey], ALGORITHM = 'RSA_OAEP', ENCRYPTED_VALUE = 0x016E000001630075007200720065006E00740075007300650072002F006D0079002F006100360031003900660062003000630034003000320039006300660063006400390064003900650039003300350064006200620038006400630039003800650030003900300032003000300030006600374AEE2DA655985A4822614237F61F217171DD13882CE89120BC7B2D5DDD6863668EC2EFE24A64E55ADA2E8A52B0F1E758CD3717157E6612784BB21DE65FDD005322EAA78BC96EA9CB833F5F73E1DD859DB0AE92A6F9D272DEDF53934AF9B43445A01E9FBDBDEF5FCD68087D4EDE85D7479F2BE3D21E401CEABBC6630C004BE1A4BD29BBE2167850F2A08F688BD4AA430F73959D934B44412C62E8EE63D2949B31A1AA07EC80248E1351CF53F5E0C94A142FBE05817A2DEBA87E191B158A748F8925854E52EEBC5D0D620C9BE9BB8157880105A2108F4409B30EE8E8FBF5B51B8C2A884F69B08C568709176A8F9DC1C56E005363BFB2E8E0C5FB27C17551A447E5626432546249839A5AAF334371004BD105F553F5FFCB138C83B4AF54F62163FC08825365B11B0888AF1DB2487C41FBFFE6138C0091500C2B3AD5D3326D36504F5D00C1725C4418263C8D2943BF1DD93B0454DF952975AB795191CF309154B7B6430E55725BF1FC0529C3617B3D44B4A25B983C75339ED999C0143137BB728EB0ACD2878C1DB5780513F456AA50334913931F777297B2EFA42DC5916CCD4F01D05D25F654E65058DED9BF45BE712036AD57A627A8011B14B6406B4C5459C8A7A41D92957C364997FFFDC016A0A64923B1F5794819186443D891F5C534805FDF12EFFF65BCC60FBD4757D9F06E7727C50FE3F5EF440B80292E3AB7536CF09D98 ); GO 暗号化が適切に設定されていることを確認します (参照用にサンプル出力が含まれています)。 USE [AlwaysEncrypted]; GO select * from sys.column_master_keys; select * from sys.column_encryption_keys; select * from sys.column_encryption_key_values; GO 暗号化された列を含むテーブルを作成します。次のサンプルには、列暗号化キーの両方のオプション (DETERMINISTICとRANDOMIZE) が含まれています。一般に最も使用されるオプションは、非常に高速であるためDETERMINISTICですが、使用例によっては、RANDOMIZEの方が優れたオプションです (列のカーディナリティが非常に低い場合など)。以下の T-SQL ステートメントでは、文字列項目に対するDETERMINISTIC暗号化オプションには バイナリ コード ポイント照合 (_BIN2) が必要であることに注意することが重要です。 IF OBJECT_ID('dbo.CustomerInfo', 'U') IS NOT NULL DROP TABLE dbo.CustomerInfo; GO CREATE TABLE dbo.CustomerInfo ( CustomerId INT IDENTITY(10000,1) NOT NULL PRIMARY KEY, CustomerName NVARCHAR(100) COLLATE Latin1_General_BIN2 ENCRYPTED WITH ( ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey ) NOT NULL, CustomerPhone NVARCHAR(11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH ( ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey ) NOT NULL ); GO 最近作成したテーブルをクエリします SELECT TOP 3 * FROM dbo.CustomerInfo WITH(NOLOCK); GO いくつかのレコードを挿入します。このサンプルでは、挿入操作を単一のステートメントとして保持することが重要です。そうしないと、SSMS がエラーをスローします。 DECLARE @CName AS nvarchar(100) = 'CustomerA', @CPhone AS nvarchar(11) = '12123330988'; INSERT INTO [dbo].[CustomerInfo] VALUES (@CName, @CPhone); GO DECLARE @CName AS nvarchar(100) = 'CustomerB', @CPhone AS nvarchar(11) = '14152220786'; INSERT INTO [dbo].[CustomerInfo] VALUES (@CName, @CPhone); GO DECLARE @CName AS nvarchar(100) = 'CustomerC', @CPhone AS nvarchar(11) = '19255550484'; INSERT INTO [dbo].[CustomerInfo] VALUES (@CName, @CPhone); GO 再度、テーブルをクエリします。 SELECT TOP 3 * FROM dbo.CustomerInfo WITH(NOLOCK); GO 値は暗号化されていないことに注意してください。証明書がデプロイされていない他のクライアントからこのクエリを実行すると、暗号化された値のみが表示されます。考えられるテストは、クライアントから証明書を削除してからクエリを再度実行することです。 結論 この投稿では、Windows 証明書ストアを使用して Amazon RDS for SQL Server インスタンスに Always Encrypted を設定する方法を説明しました。 Microsoft SQL Server Always Encrypted は多くの 制限付き でリリースされており、Amazon RDS for SQL Server インスタンスでこの機能をセットアップした後も制限は引き続き適用されることに留意することが重要です。この投稿に含まれる手順に従って作成されたリソースを使用する必要がない場合は、環境をクリーンアップすることを忘れないでください。演習中に作成された Amazon RDS for SQL Server インスタンスを削除し、PSX のホストに使用された Amazon S3 バケットを削除します。証明書ファイルを削除し、ターゲット アプリケーション サーバー (Always Encrypted Client) として使用されている Amazon EC2 インスタンスを終了します。 ご質問、コメント、フィードバックがありましたら、この投稿のコメントセクションに残してください。 About the authors Camilo Leon は、データベースを専門とする AWS のプリンシパル ソリューション アーキテクトであり、カリフォルニア州サンフランシスコを拠点としています。彼は AWS の顧客と協力して、AWS リレーショナル データベースのワークロードとビジネス アプリケーションの設計、デプロイ、管理に対するアーキテクチャのガイダンスと技術サポートを提供しています。余暇には、マウンテン バイク、写真、映画を楽しんでいます。 &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

2023 年 7 月 : この投稿には、オンプレミスの SMTP サーバーを使用してデータベース メールを構成する手順が追加されました。 Amazon RDS for SQL Server が SQL Server データベース メールを完全にサポートするようになったことを発表できることを嬉しく思います。このリリースより前にデータベース メールを有効にするには、 リンク サーバー の使用などさまざまな回避策を使用する必要がありました。SQL Server 用データベース メールのリリースでは、DB パラメータ グループを使用してデータベース メールをシームレスに有効にすることができます。 データベース メールは、Microsoft SQL Server で頻繁に使用される機能の 1 つです。データベース メールを使用すると、SMTP (Simple Mail Transfer Protocol) サーバーを使用して SQL Server からユーザーにメッセージを送信できます。この投稿では、データベース メールを設定し、 Amazon Simple Email Service (Amazon SES) 経由で RDS for SQL Server DB インスタンスから E メールを送信する方法を学びます。 データベース メールの一般的なユースケースは次のとおりです。 テキストメッセージの送信 クエリ結果またはレポートをテキストまたは添付ファイルとして送信 プロシージャまたはジョブ内でプログラムによる電子メール通知の送信 この投稿では、次の AWS サービスを使用します。 Amazon RDS for SQL Server – データベース メールは、SQL Server の Web、Standard および Enterprise エディションでサポートされています。 Amazon SES – Amazon SES を SMTP サーバーとして使用します。これは 1 つのオプションにすぎません。代わりに、別の SMTP サーバーを使用することもできます。その場合は、Amazon SES のセットアップに関する次のセクションをスキップしてください。 Amazon SES のセットアップ Amazon SES を SMTP サーバーとして使用して、電子メールを迅速に送信します。 Amazon SES は、あらゆるアプリケーション内から E メールを送信できるコスト効率が高い柔軟でスケーラブルな E メール サービスです。まず、次の手順を実行します。 Amazon SES コンソールで、[ SMTP 設定 ] を選択します。 「 サーバー名 」と「 ポート 」の値に注目してください。 [ SMTP 認証情報の作成 ] を選択します。 注意 : Amazon SES SMTP インターフェイス経由で E メールを送信するために使用する認証情報は、各 AWS リージョンで固有です。詳細については、「 Amazon SES SMTP 認証情報の取得 」を参照してください。 AWS Identity and Access Management の名前を入力します。 (IAM) ユーザーにするか、デフォルトのままにします。 「 作成 」を選択します。 SMTP 認証情報を安全な場所に保存します。ダウンロードできるのはこのときだけです。 Amazon SES コンソールで、[ E メールアドレス ] を選択します。 [ 新しいメール アドレスの確認 ] を選択します。 確認メールを受信するには、所有しているメール アドレスを入力してください。 メールを確認すると、「 検証ステータス 」に 認証済み と表示されます。 この時点で、SMTP サーバーに関する必要な情報がすべて揃ったので、データベース メールの構成を開始することができます。 データベース メールのセットアップ データベース メールを構成する前に、まず DB パラメータ グループを通じてデータベース メールを有効にします。 DB パラメータ グループによるデータベース メールの有効化 データベース メールは、RDS インスタンスでは DB パラメータグループを通じて 有効にします。 Amazon RDS では、パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。各 RDS インスタンスには、デフォルトのパラメータ グループが関連付けられています。ただし、変更することはできません。新しいパラメータグループを使用することも、既存の作成済みパラメータ グループを使用することもできます。既存のパラメータグループを選択する場合は、SQL Server インスタンスのエディションとバージョンがサポートされている必要があります。新しいパラメータグループの作成の詳細については、「 DB パラメータ グループの操作 」を参照してください。パラメータ グループを通じてデータベース メールを有効にするには、次の手順を実行します。 Amazon RDS コンソールで、[ パラメータグループ ] を選択します。 使用するパラメータグループを選択します。 検索ボックスに「database mail xps」と入力します。 「 編集 」を選択して値を変更します。 [ 値 ] で 1 を選択します。 変更を保存します。 Amazon RDS コンソールで、[ データベース ] を選択します。 使用するインスタンスを選択します。 「 変更 」を選択します。 「 データベース オプション 」で、database mail xps に1 が設定されているパラメータグループを選択します。 「 続行 」を選択します。 「 変更のスケジュール 」で、「 すぐに適用 」を選択します。 [ DB インスタンスを変更 ] を選択して変更を適用します。 パブリックサブネット内のインスタンスのデータベースメールの構成 次の図は、データベース メール構成の例を示しています。 User1 は、Profile 1 を介してアカウント 1 とアカウント 2 にアクセスできます。User2 は、両方のプロファイルを介してすべてのアカウントにアクセスできます。 User3 は、Profile 2 を介してアカウント 2 とアカウント 3 にアクセスできます。 データベース メールを使用する前に、メール構成をセットアップする必要があります。 SQL Server Management Studioを起動します。 データベース メールが有効になっている RDS インスタンスの SQL Server エンジンに接続します。 新しいクエリを開きます。 次のストアド プロシージャを使用して、単純なデータベース メール構成を作成します。 データベース メール プロファイルを作成します (プロファイルは電子メール アカウントを保存するために使用されるコンテナです)。次のコードを参照してください。 use msdb go EXECUTE msdb.dbo.sysmail_add_profile_sp @profile_name = 'Notifications', @description = 'Profile used for sending outgoing notifications using SES.' ; プロファイルにプリンシパルを追加します。 public を使用すると、すべてのユーザーがプロファイルにアクセスできるようになります。 use msdb go EXECUTE msdb.dbo.sysmail_add_principalprofile_sp @profile_name = 'Notifications', @principal_name = 'public', @is_default = 1 ; 必要に応じてデータベース メール オブジェクトに対するアクセス許可を付与できますが、現時点では public で問題ありません。 データベース メール アカウントを作成します (必ず正しい SMTP 資格情報を入力してください)。 use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = ' example@example.com ', @display_name = 'Automated Mailer', @mailserver_name = ' email-smtp.us-west-2.amazonaws.com ', @port = 587 , @enable_ssl = 1, @username = 'SMTP-username' , @password = 'SMTP-password' ; この手順は、パブリック サブネットでホストされている RDS インスタンスに適しています。ただし、RDS インスタンスがプライベート サブネットに配置されている場合は、次のセクションで詳細なガイダンスを参照してください。 データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; プライベート・サブネット内のインスタンスのデータベース・メールの構成 RDS for SQL Server インスタンスがプライベート サブネットでホストされている場合は、Amazon SES の VPC エンドポイントを使用する必要があります。これにより、RDS for SQL Server インスタンスと SMTP サーバー間の通信が可能になります。先に進む前に、まず前のセクションのステップ 1 ～ 5 を完了することが重要です。これらの最初のステップは、その後のステップの基礎となります。 SES の VPC エンドポイントのセキュリティグループの作成 Amazon VPC コンソール を開きます SES VPC エンドポイントの セキュリティ グループ を作成します。 新しいインバウンドルールを作成します。 [タイプ] で、[ カスタム TCP ] を選択します。 [ ポート範囲 ] に、電子メールの送信に使用するポート番号を入力します。 25、465、587 を使用できます。 [ ソース タイプ ] で、[ カスタム ] を選択します。 [ ソース ] に、RDS for SQL Server インスタンスにアタッチされているセキュリティ グループを入力します。 VPC エンドポイントの作成 Amazon VPC コンソール を開き、[エンドポイント] を選択します。 「エンドポイントの作成」を選択します。 名前を入力します。 [サービス カテゴリ] で [AWS サービス] を選択します。 「サービス」で「smtp」を検索し、そのリージョンに固有の SMTP VPC エンドポイントを選択します。 「VPC」セクションで、このエンドポイントが作成される VPC を選択します。 追加設定では、デフォルトで DNS 名の DNS 名を有効化 にチェック、DNS レコードの IP タイプでは Ipv4 がチェックされていることを確認してください。 「サブネット」で、アベイラビリティーゾーン内のサブネットを選択します。 &nbsp;[セキュリティ グループ] で、前に作成したセキュリティ グループを選択します。 「エンドポイントの作成」をクリックします。 VPC エンドポイントが利用可能な状態になったら、エンドポイントを選択し、DNS フィールドで見つかった最初のエントリをコピーします。 SMTP サーバー名の代わりに、前に作成した VPC エンドポイントの DNS 名を使用してデータベース メール アカウントを作成します。 (必ず正しい SMTP 資格情報を入力してください) use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = 'example@example.com' , @display_name = 'Automated Mailer', @mailserver_name = 'vpce-XXXXX-XXXX.email-smtp.us-west-2.vpce.amazonaws.com' , -- VPC endpoint created in previous step @port = 587 , @enable_ssl = 1, @username = 'SMTP-username' , @password = 'SMTP-password' ; データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; テストメールの送信 ストアド プロシージャ sp_send_dbmail を実行して電子メールを送信します (次のコードを参照)。受信者は、 Amazon SES シミュレーター を使用して、メールの送信が成功したかどうかを簡単にテストできます。その他のテスト オプションについては、「メールボックス シミュレーターの使用」を参照してください。実際の受信者に送信したい場合は、このプロセスを繰り返して追加の電子メール アドレスを確認する必要があります。 EXEC msdb.dbo.sp_send_dbmail @profile_name = 'Notifications', @recipients = 'success@simulator.amazonses.com', @body = 'The database mail configuration was completed successfully.', @subject = 'Automated Success Message'; GO 次に、次に示すストアド プロシージャを実行してすべての電子メール アイテムを表示します。 SELECT * FROM msdb.dbo.sysmail_allitems sent_status 列で、ステータスが送信されたことを確認します。 オンプレミスの SMTP サーバーを使用したデータベース メールの構成 一部の顧客は、オンプレミスの SMTP サーバーを使用して Amazon RDS for SQL Server でメールを設定したいと考えていました。このセクションでは、オンプレミスの SMTP サーバーをメール サーバーとして使用して、RDS for SQL Server DB インスタンスから電子メールを送信するようにデータベース メールを構成する方法について詳しく説明します。 前提条件 次の前提条件を満たしている必要があります。 前のセクションの DB パラメータ グループを通じて database mail xps が有効になっている DB パラメータを持つ RDS for SQL Server インスタンスであること SMTP サーバーでの認証に有効な資格情報を持つオンプレミス SMTP サーバーであること オンプレミス SMTP サーバーの構成を変更するための十分なアクセス権限を持つこと オンプレミスの SMTP サーバー接続を確認する オンプレミスの SMTP サーバーが正しく構成されており、電子メールを送信できることを確認します。次のことを確認してください。 SMTP サーバー アドレス – SMTP サーバーの IP アドレスまたはホスト名を取得します。 ポート番号 – SMTP サーバーで使用されるポート番号をメモします (通常、暗号化されていない接続の場合はポート 25、TLS/SSL 暗号化された接続の場合はポート 587 )。 認証資格情報 – SMTP サーバーでの認証に必要なユーザー名とパスワードがあることを確認します。 暗号化要件 – SMTP サーバーに安全な接続 (TLS/SSL) が必要かどうかを決定します。 ネットワーク接続を有効にする ネットワーク接続を有効にするには、次の手順を実行します。 SMTP サーバーは AWS ネットワークの外部に存在するため、サーバーが指定された IP 範囲内の Amazon RDS for SQL Server からの接続を許可していることを検証する必要があります。 Amazon RDS for SQL Server の IP 範囲またはパブリック IP が SMTP サーバーの許可リストに含まれていることを確認する必要があります。これを実現するための具体的な手順は、組織のポリシーや設定によって異なる場合があることに注意してください。 RDS for SQL Server インスタンスのセキュリティ グループを変更し、SMTP サーバーからの接続を許可する新しい受信ルールを追加します。 RDS インスタンスが実行されている AWS アカウントでは、ポート 25 がデフォルトでスロットルされます。ポート 25 がブロックされていないことを確認するには、AWS に SMTP (ポート 25) スロットリングを削除するようにリクエストする必要があります。これを行うには、 電子メール送信制限の削除リクエスト フォーム を使用します。 SMTP サーバーの DNS を解決するための Amazon Route 53 ルールを追加します。これにより、RDS インスタンスから電子メールを送信するときに SMTP サーバーのドメインが解決されます。 データベースメールの構成 次の手順でデータベース メールを構成します。 「 パブリック サブネット内のインスタンスのデータベース メールの構成 」セクションと同じ手順に従って、データベース メールを設定します。 データベース メール アカウントを作成するとき、メール サーバー名には、オンプレミスの SMTP サーバー名または IP (例えば mysmtpsvr.com など) を使用します。 データベース メール アカウントを作成します (必ず正しい SMTP 資格情報を入力してください)。 use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = 'example@example.com', @display_name = 'Automated Mailer', @mailserver_name = 'mysmtpsvr.com', @port = 587, @enable_ssl = 1, @username = 'On-Prem-SMTP-username', @password = 'On-Prem-SMTP-password'; データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; 結論 この投稿では、Amazon SES を使用してデータベース メールを設定する方法を説明しました。 SQL Server 用データベース メールのリリースにより、データベース メールを有効にして使用するための回避策を見つける必要がなくなりました。このソリューションは、他のサードパーティ SMTP サーバーにも使用できます。今すぐ AWS マネジメントコンソール でデータベースメールを試して、コメントであなたの考えや経験を共有してください。 About the authors Andrew Zhou は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。彼は AWS RDS チームと協力して、商用データベース エンジンと SQL Server に重点を置いています。彼は技術的な課題に取り組むことを楽しんでおり、新しいテクノロジーを学ぶことに情熱を持っています。 Chandra Shekar Ramavath iは、アマゾン ウェブ サービスのデータベース エンジニアです。彼は AWS RDS チームと協力して、商用データベース エンジン、SQL Server、Oracle に重点を置いています。 Sid Vantair は、戦略アカウントを担当する AWS のソリューション アーキテクトです。リレーショナル データベースを扱う 10 年以上の経験を持つ彼は、顧客のハードルを克服するために複雑な技術的問題を解決することに熱心に取り組んでいます。仕事以外では、家族と過ごす時間を大切にし、子供たちの好奇心を育んでいます。 Bharath Kumar は、AWS プロフェッショナル サービス チームのリード データベース コンサルタントです。彼は、顧客がオンプレミス データセンターから AWS クラウドにデータベースを移行できるようにサポートし、また商用データベース エンジンから Amazon のオープンソース データベースへの移行もサポートしてきました。 Nishad Mankar は、AWS プロフェッショナル サービスのリード データベース コンサルタントです。彼は、顧客が AWS クラウド上でデータベースを移行して最新化できるよう支援しています。 &nbsp; &nbsp; &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

この記事は、“ Improving medical imaging workflows with AWS HealthImaging and SageMaker ” を翻訳したものです。 医用画像は、医療における患者の診断と治療計画において重要な役割を果たします。しかし、医療提供者は、医用画像の管理、保存、分析に関していくつかの課題に直面しています。このプロセスには時間がかかり、エラーが発生しやすく、コストがかかる可能性があります。 また、地域や医療制度全体では放射線科医が不足しており、人口の高齢化、画像技術の進歩、医療における画像診断の重要性の増大により、この専門分野の需要が高まっています。 画像検査の需要が高まり続ける中、対応できる放射線科医の数が限られているため、検査予約や適切な診断が遅れています。テクノロジーによって臨床医と患者への医療提供の改善が可能になる一方で、病院は最も差し迫った課題を解決するために次のような追加のツールを求めています。 画像検査および診断サービスに対する需要の高まりによる専門家の燃え尽き症候群 体積測定や画像の構造的セグメンテーションなど、手間のかかる作業 利便性、使いやすさ、個別化の観点から、小売やテクノロジーに匹敵する質の高い医療体験を期待する患者からの期待の高まり 臨床医と患者の体験を向上させるには、人工知能（AI）対応の画像診断クラウドソリューションでPicture Archiving and Communication System（PACS: 医用画像サーバー）を運用して、重要な知見を安全に取得し、医療へのアクセスを改善してください。 AIは自動化により放射線科医の燃え尽き症候群を低減するのに役立ちます。たとえば、AIは放射線科医の胸部X線画像の診断時間を節約します。また、精密検査が必要な領域を特定するための強力なツールでもあり、当初は特定できなかった二次的な発見も得るのに役立ちます。相互運用性と分析の進歩により、放射線科医は患者の健康記録を360度縦断的に把握できるようになり、より低コストでより良い医療を提供できるようになりました。 AWS は、これらの課題に対処するサービスを提供しています。このブログ記事では、 AWS HealthImaging (AWS AHI) と Amazon SageMaker 、およびこれらを併用して医療提供者の医用画像ワークフローを改善する方法について説明します。これにより、最終的に画像診断が加速し、放射線医学の生産性が向上します。AWS AHI を使用すると、開発者はクラウドネイティブな医用画像アプリケーションにパフォーマンス、セキュリティ、およびスケールを提供できます。これにより、Digital Imaging and Communication in Medicine (DICOM) 画像を取り込むことができます。Amazon SageMaker は AI と機械学習のためのエンドツーエンドのソリューションを提供します。 自動車事故後のX線に関する使用例を見てみましょう。この医用画像診断ワークフローでは、患者は救急室にいます。そこから: 患者は骨折の有無を確認するためにX線撮影を受けます。 スキャンされた撮影装置の画像はPACSシステムに送られます。 放射線科医は、この検査で取得した情報を確認し、レポートを作成します。 依頼医にレポートが提供されるまで、患者のワークフローは継続されます。 次世代の画像処理ソリューションとワークフロー 医療提供者は AWS AHI と Amazon SageMaker を併用することで、次世代の画像診断ソリューションを実現し、医用画像診断ワークフローを改善できます。次のアーキテクチャは、この例を示しています。 図 1: X 線画像が AWS HealthImaging に送信され、Amazon SageMaker エンドポイントが分析情報を抽出します。 アーキテクチャと主要なコンポーネントを見てみましょう。 1. イメージスキャナー:患者の体から画像をキャプチャします。モダリティによっては、X線検出器、CTスキャナーの検出器アレイ、MRIスキャナーの磁場と高周波コイル、または超音波センサーなどがあります。この例では X 線デバイスを使用しています。 AWS IoT Greengrass : DICOM C-Store SCP で設定されたエッジランタイムとクラウドサービスで、画像を受信して Amazon Simple Storage Service (Amazon S3 ) に送信します。画像と関連するメタデータは、それぞれ Amazon S3 と Amazon Simple Queue Service (Amazon SQS) に送信され、ワークフローがトリガーされます。 2. Amazon SQS メッセージキュー:S3 バケットからのイベントを受信し、 AWS Step Functions ワークフローオーケストレーションをトリガーします。 3. AWS Step Functions は変換ジョブとインポートジョブを実行して画像を処理し、AWS AHI データストアインスタンスにインポートします。 4. 最終的な診断画像は、関連する患者情報およびメタデータとともに、AWS AHI データストアに保存されます。これにより、画像データの検索と管理を効率的に行うことができます。また、クラウドネイティブ API と AWS パートナーのアプリケーションにより、医用画像データへのアクセスも可能になり、1 秒未満の大規模な画像取得レイテンシーを実現できます。 5. ML 画像のラベリングを担当する放射線科医は、 Amazon SageMaker Ground Truth を使用して医用画像にアノテーションを付けます。カスタムデータラベリングワークフロー（組み込みまたはカスタムのデータラベリングワークフローをサポートするフルマネージドデータラベリングサービス）を使用して DICOM 画像を視覚化およびラベル付けします。また、 3D Slicer などのツールを活用して、インタラクティブな医用画像にアノテーションを付けています。 6. データサイエンティストは、Amazon SageMaker のアノテーション付き画像を使用して、組み込みのディープラーニングモデルを構築または活用します。SageMaker には、低レイテンシーや高スループットから長時間実行される推論ジョブまで、さまざまな展開オプションが用意されています。これらのオプションには、バッチ、リアルタイム、または ニアリアルタイム の推論に関する考慮事項が含まれます。 7. 医療提供者は AWS AHI と Amazon SageMaker を使用して、AI を活用した検出と解釈のワークフローを実行しています。このワークフローを使用して、見えにくい骨折、脱臼、軟部組織損傷を特定し、外科医や放射線科医が自信を持って治療を選択できるようになります。 8. 最後に、AWS AHI に保存された画像はモニターやその他の視覚出力デバイスに表示され、放射線科医やその他の医療専門家が分析および解釈できます。 Open Health Imaging Foundation （OHIF）ビューアーは、オープンソースのウェブベースの医用画像プラットフォームです。複雑な画像処理アプリケーションを構築するためのコアフレームワークを提供します。 Radical Imaging と Arterys は、OHIF ベースの医用画像ビューアを提供する AWS パートナーです。 これらの各コンポーネントは、医用画像システムの全体的な性能と精度だけでなく、診断結果と患者ケアの向上に焦点を当てた継続的な研究開発においても重要な役割を果たします。AWS AHI は、効率的なメタデータエンコーディング、可逆圧縮、プログレッシブ解像度データアクセスを使用して、業界トップクラスのパフォーマンスを画像読み込みで提供します。効率的なメタデータのエンコーディングにより、画像ビューアと AI アルゴリズムは、画像データを読み込まずに DICOM 検査の内容を理解できます。 セキュリティ AWS の責任共有モデルは、AWS AHI と Amazon SageMaker におけるデータ保護に適用されます。 Amazon SageMaker は HIPAA の対象であり、保護対象保健情報 (PHI) を含むデータを扱うことができます。転送中のデータの暗号化は SSL/TLS によって提供され、Amazon SageMaker のフロントエンドインターフェイス (ノートブック) との通信時と Amazon SageMaker が他の AWS サービスとやり取りする場合の両方に使用されます。 AWS AHI は HIPAA 適格のサービスでもあり、メタデータレベルでのアクセス制御が可能なため、各ユーザーとアプリケーションには、それぞれのロールに基づいて必要な画像とメタデータフィールドのみが表示されます。これにより、患者のPHIの増加が防止されます。AWS AHI API へのすべてのアクセスは、 AWS CloudTrail に詳細に記録されます。 これらのサービスはどちらも AWS Key Management Service (AWS KMS) を活用して、PHI データを保存時に暗号化するという要件を満たします。 まとめ この投稿では、症状の早期発見と治療のための一般的な使用例を概説し、その結果、患者の治療成績が向上しました。また、テクノロジーの力を活用して医用画像の精度、効率、アクセス性を向上させることで、放射線医学分野を変革できるアーキテクチャについても取り上げました。 参考文献 AWS HealthImaging Partners AWS features AWS HealthImaging at RSNA22 Annotate DICOM images and build an ML model using the MONAI framework on Amazon SageMaker MLOps deployment best practices for real-time inference model serving endpoints with Amazon SageMaker Sukhomoy Basak Sukhomoy Basak はアマゾンウェブサービスのソリューションアーキテクトで、データおよび分析ソリューションに情熱を注いでいます。Sukhomoy は、企業のお客様と協力して、ビジネス成果を達成するためのアプリケーションの設計、構築、拡張を支援しています。 Hassan Mousaid Hassan Mousaid 博士は、アマゾンウェブサービスの主任ソリューションアーキテクトであり、ヘルスケアおよびライフサイエンス (HCLS) のお客様が、Amazon のイノベーションメカニズムを使用してアイデアを市場に投入するプロセスを加速できるようサポートしています。エンタープライズおよびクラウドトランスフォーメーション、ヘルスケアIT、医用画像分野で20年の経験があります。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

この記事は、“ Enhancing multidisciplinary collaboration in digital pathology with cloud-based PACS ” を翻訳したものです。 病理医は凍結切片法を用いて生検した組織の分析を行います。従来、凍結切開では組織生検の可視化に顕微鏡検査のみに頼っていました。ただし、顕微鏡スライドは壊れやすく、細胞構造の視覚化に使用される色素は時間の経過とともに色あせてしまうため、情報の共有とデータ保存に重大な問題が生じます。顕微鏡用カメラの発明により、スライドキャプチャが簡単になりました。それでも、画像はローカルストレージに最適化するために圧縮されることが多く、レポートの作成中に画像をキャプチャするという手作業が追加されるため、病理医の通常のワークフローが中断されることになります。 ホールスライドスキャナーは画像キャプチャの負担を軽減すると、当初はデジタル病理学において関心を呼びましたが、完全なエンドツーエンドのソリューションではありません。世界中の多くの病院は、まだデジタル病理学の可能性を最大限に活用していません。 韓国に拠点を置くヘルスケアテクノロジー（ HealthTech ）企業である INFINITT Healthcare は、スライド標本全体画像（WSI）の出力を医療における Digital Imaging and Communications in Medicine（DICOM）ファイルとして抽出して変換することで、状況を変えることに取り組んでいます。DICOM は、病理医が時間と資源を節約し、多分野のコミュニケーションを効率化し、患者ケアのソリューションを実現するまでの時間を短縮するのに役立つWSIのデジタルバージョンです。その後、これはアマゾンウェブサービス（AWS）上に構築されたクラウドベースの Digital Pathology System（DPS）に保存されます。 デジタル病理学のパイロットリサーチ計画 専門の腫瘍センターを備えたソウル有数の病院である Samsung Medical Center（SMC: サムスン医療センター）は、デジタル病理学の導入を先導しています。SMCは年間200万人以上の患者を診察しており、1,200人の医師と2,300人の看護師を含む約7,400人のスタッフが配置されている三次病院です。INFINITT との共同リサーチ計画で、 SMC は2019年に病理部門でクラウドネイティブな Picture Archiving and Communication System（PACS）を試験的に導入しました。 SMC の病理部門は、年間52,000件の症例をサポートしており、これは1日あたり平均約214人の患者です。病理医は、本院から離れた別の建物で働いています。通常、搬送者が生検標本を搬送し、臨床検査技師が顕微鏡検査のために処理と準備を行い、最終的に病理医が検体を診断する必要があります。緊急の所見は、電話で主治医に伝えられます。 病理学におけるデジタル化の直接的なメリット 以前は、病理医は生検スライドを分析し、その結果を診療ノートに個別のレポートとして記述していました。腫瘍検査中に所見について話し合いたい場合は、顕微鏡に接続されたカメラで顕微鏡画像を撮影し、組織病理学的所見を含む PowerPoint ファイルを準備する必要がありました。さらに、生検スライドが壊れている場合、病理医は同じスライド画像を得るためにパラフィンブロックの再切断を依頼する必要があります。 スライド全体をデジタル化することで、病理医は所見を画像に直接アノテーションできるようになりました。その後、腫瘍ボード中に画像を INFINITT DPS で直接開くことができるため、時間と労力を節約できるだけでなく、患者のケアに焦点を当てたより多くの情報に基づいた意思決定が可能になります。 クラウドベースの DPS は、複数の専門分野にわたる腫瘍学チームにおけるコミュニケーションを即座に改善しました。病理医は、 INFINITT が提供するソフトウェアシステムを使用して、プライマリケアチームに電話をかけ、一緒に WSI をレビューできます。双方向の診断ツールとして、ウェブブラウザに搭載された最新の画面共有技術により、複数の遠隔地の病理医がスライド画像全体を同時に見て、まとめて診断することができます。これが可能なのは、各ユーザーが自分のマウスカーソルでスライドを動かして特定の位置を指すことができ、他の全員がリアルタイムですべてを見ることができるからです。 DPS は、国家レベルでの研究協力を可能にするために、アジア太平洋地域の一部の医療センターで実施されています。その後、韓国病理学会は会員の教育と訓練を目的として DPS を採用しました。 病理医のコミュニティ全体では、新しい DPS によってコストのかかるローカル IT インフラストラクチャの必要性が軽減され、データガバナンスを改善したという意見が一致しています。これまで、研究データ保持ポリシーを大規模に実施することは困難でした。ポリシーに準拠するため、サーバーラックをサードパーティベンダーが廃棄する必要がありました。クラウドベースの DPS では、データ保持ポリシーは Amazon Simple Storage Service (Amazon S3) バケットに書き込まれ、自動的にバックアップされます。 INIFITT が AWS を使用して WSI をデジタル化する方法 図 1.SMC の支援に役立った INFINITT のソリューションのアーキテクチャ図 INFINITT は DPS ソフトウェアで複数の AWS サービスを使用しています。図 1 は、このソリューションの大まかなアーキテクチャを示しています。 1) さまざまな学術機関から提供された DICOM 形式の WSI は、 Amazon Virtual Private Cloud (Amazon VPC) の Amazon Elastic Block Store (Amazon EBS) にエクスポートされ、保存されます。 2) INFINITT DPS は VPC の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされます。 3) ユーザーはウェブポータルを介してWSIの検査にアクセスします。 4) アノテーションが付けられた WSI イメージは Amazon S3 に保存されます。 Amazon SageMaker は、人工知能 (AI) と機械学習 (ML) のワークフロー全体を管理し、関心のある特定の疾患に関するモデルをトレーニングするために使用されます。その後、処理された画像は Amazon S3 に保存され、INFINITT DPS 経由でアクセスできるようになります。 5) Amazon Cognito は INFINITT DPS ロードマップに追加され、臨床研究者の役割分担やアクセスガバナンスの強化など、役割分担によるデータへの安全なアクセスをサポートします。 INFINITT の DPS ソリューションは、病理学者のコミュニケーションと学際的なコラボレーションを強化するのに役立ちます。さらに、従来の IT インフラストラクチャからクラウドベースの PACS に切り替えることで、病院システムは50〜70％の節約になります。DPS は WSI データの自動バックアップをサポートし、データ保持ポリシーのガバナンスを容易にします。 デジタル病理学の次は？ 一般に、WSI の出力は、非圧縮画像の場合は2.5ギガバイト (GB) から10GB までさまざまです。病理検査ラボの一般的な作業負荷は、1日あたり約1,000枚の画像で、これは毎日生成される10テラバイト（TB）のデータに相当します。WSIの研究はGB単位の規模になることがあります。これは、デジタル画像検査の平均サイズが通常数十メガバイト（MB）から数百メガバイト（MB）である放射線画像検査などの他の専門分野とは対照的です。 SMC の病理検査部門全体が100％WSI を使用する方向に向かっているため、長期的にはクラウドベースの DPS の方がはるかに費用対効果が高い可能性があります。スライドのデジタル化により、SMC はさらなる革新と Amazon SageMaker を使った実験を計画しています。 SMC は、WSI での病理所見の検出を加速できる AI および ML アルゴリズムを構築する予定です。さらに、乳がんと前立腺がんに必要な面倒な悪性度判定プロセスを自動化して、病理医の臨床作業負荷を軽減したいと考えています。 世界的な労働力の高齢化により、 病理学は専門職の人員不足に直面しています。 しかし、 がんの診断数は増加しています。 したがって、病理学におけるデジタルトランスフォーメーションは、病院が今後数十年にわたって最適な状態で機能し続けるために不可欠です。クラウドネイティブなアプローチは、病院の情報システムに追加の資本的負担や運用上の負担をかけることなく、スタッフと患者の治療成績をサポートするのに役立ちます。 ヘルスケア向け AWS の詳細はこちら 世界中の医療機関や製薬企業は、連携の方法、データ主導の臨床および業務上の意思決定、精密医療の実現、医療費の削減の方法を改革しています。ヘルスケアおよびライフサイエンス組織がビジネス上および技術上の目標を達成できるように、AWS for Health は AWS のサービスと AWS パートナーソリューションを提供しており、世界中の何千ものお客様が使用しています。AWS が世界中の重要な医療ミッションをどのように支援しているかについての詳細は、 AWS for healthcare hubにアクセスする か、 AWS 公共部門チームにお問い合わせください。 AWS 公共部門ブログで関連記事を読む: Large scale AI in digital pathology without the heavy lifting Automating clinical lab workflow at scale for chronic disease monitoring with the cloud Alzheimer’s disease research portal enables data sharing and scientific discovery at scale Designing a biometric IoMT solution to support health equity with AWS ProServe AMILI helps advance precision medicine by building microbiome library on AWS Transforming radiology workflows with clinical decision support powered by AWS AWS Public Sector Blog ニュースレターを購読して 、公共部門の AWS ツール、ソリューション、イノベーションの最新情報をメールで受け取ることができます。または、 お問い合わせください。 このアンケートで AWS Public Sector Blog を使った感想をぜひお聞かせください。 アンケートからのフィードバックをもとに、読者の好みに沿ったコンテンツをさらに作成します。 MinSung Cho MinSung Cho は、韓国のアマゾンウェブサービス (AWS) ヘルスケアのリーダーです。彼は、Picture Archiving and Communication System（PACS）と電子医療記録（EMR）でヘルスケア企業のIT分野で10年以上の経験があり、GEヘルスケアでの前職からは医療用IoT（モノのインターネット）デバイスに関する8年以上の経験があります。 Dr. Sun Park Park 博士は神経内科医であり、医療業界で12年以上の経験を持ち、GEヘルスケア・コリアで6年間のデジタルイノベーションに携わってきた経験もあります。患者中心のケアと、病院のニーズを満たす適切なテクノロジーの導入に情熱を注いでいます。彼女は現在、韓国のアマゾンウェブサービス (AWS) の公的医療部門の事業開発業務を統括しています。 Dr. Petty Chen Chen 博士 は、アジア太平洋および日本 (APJ) の電子医療記録 (EMR) およびアマゾンウェブサービス (AWS) の病院エンゲージメントリーダーです。ハーバード大学で公衆衛生学修士（MPH）を、デューク国立大学医学部で医学博士（MD）を取得しています。ヘルスケアとテクノロジーの交差点で働く彼女は、人工知能（AI）と機械学習（ML）対応のソフトウェア開発における経験豊富なプロダクトリーダーであり、イノベーションの導入においてアジア全域の病院の責任者と緊密に協力してきました。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 AWS Black Belt オンラインセミナーをご存じでしょうか？AWSではいろいろなイベント・セミナーを開催していますが、このBlack BeltシリーズはAWSのサービス単体にフォーカスして解説を提供するものです。このBlack Beltの先月分の内容が以下に公開されています。オンデマンドで過去のセミナーをいつでも閲覧できますし、PDFで資料もダウンロード可能になっていますので活用してください。 – 2023 年 7 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年8月14日週の主要なアップデート 8/14(月) AWS CodePipeline now supports GitLab フルマネージドの継続的デリバリーサービスである AWS CodePipeline でソースレポジトリとしてGitLab.comがサポートされました。GitLab.comの変更をもとにビルドパイプラインを実行することが可能です。 AWS IAM Identity Center integration is now generally available for Amazon QuickSight Amazon QuickSight が AWS IAM Identity Center (旧AWS SSO)との連携をサポートしました。これにより容易に IAM Identity Center 経由でのフェデレーションサインインでQuickSightへのログインを実現可能です。具体的な連携例としては こちらのブログを参照してください 。 8/15(火) Amazon OpenSearch Serverless expands support for larger workloads and collections Amazon OpenSearch Serverless が拡張され、時系列コレクションの最大インテックスデータが6 TBに増加し(以前は1 TB)、検索・時系列コレクションの最大OpenSearch Compute Units (OCU)数も最大100 OCU(以前は50 OCU)まで拡張されました。OCUはOpenSearch Serverlessの仮想的なコンピューティング性能値です。 Amazon Kinesis Video Streams improves image sampling frequency to 5 frames per second 動画のストリーミング分析サービスである Amazon Kinesis Video Streams で動画から画像の切り出し頻度がこれまでの3秒に1枚から、最大で1秒あたり5枚に改善され、より短い頻度での分析処理が実行可能になりました。 8/16(水) AWS Backup Audit Manager now supports delegated backup administrator AWS Backup Audit Manager で、backup administrator の権限をAWS Organizations内のユーザーに移譲できるようになり、より柔軟な運用に対応可能になりました。 Announcing general purpose Amazon EC2 M7a instances Amazon EC2 の M7a インスタンスが一般提供開始（GA）になりました。現在 Ohio、N. Virginia、Oregon、Irelandリージョンで利用可能です。M7a インスタンスは第四世代AMD EPYC プロセッサ(Genoa)を搭載し、前世代のM6aと比較して最大50%高いパフォーマンスを実現します。詳細は こちらのブログをご覧ください 。 Amazon EC2 D3en instances are now available in additional regions Amazon EC2 D3en インスタンスが利用可能なリージョンが拡大され、新たにTokyo、Frankfurt、Singaporeの3リージョンで利用可能になりました。D3enは最大で 336 TB のローカルHDDを搭載したインスタンスで、最大 75 Gbps のネットワーク帯域と7 Gbps のEBS帯域を提供します。 Amazon RDS now supports M6g and R6g database instances in six additional AWS regions Amazon RDS で AWS Graviton2ベースの M6g、R6gインスタンスが選択可能なリージョンが追加され、新たにOsaka、 Cape Town、Jakarta、Melbourne、Zurich、 Bahrain の6リージョンにおいて利用可能になりました。サポートされるDBエンジンはPostgreSQL、 MySQL、 MariaDB です。 同時にT4gインスタンスのリージョン拡張もアナウンス されており、大阪リージョンを含む前述のリージョンで利用可能になっています。 Amazon RDS Performance Insights provides an on-demand analysis experience Amazon RDS の Performance Insights に新しいメトリクスが追加されました。このリリースにより、選択した期間のパフォーマンスのデータを分析できます。たとえばアプリケーションがスローダウンした期間を分析して、データベースの動作が変化したかどうか、またどのように変化したかを確認したり、それを是正するためのアドバイスを得ることが可能です。この機能は Aurora MySQL、 Aurora PostgreSQL、 RDS for PostgreSQL で利用可能です。 8/17(木) Announcing Amazon EC2 Hpc7a instances Amazon EC2 の Hpc7a インスタンスが一般提供開始（GA）になりました。現在 Ohio、 GovCloud (US-West) リージョンで利用可能です。Hpc7a インスタンスは第四世代 AMD EPYCプロセッサ(Genoa)を搭載し、前世代のHpc6aと比較して最大2.5倍の性能を提供します。詳細は こちらのブログ をご覧ください。 Announcing Amazon GameLift support for instances powered by AWS Graviton3 processors 信頼性が高くスケーラブルなゲームサーバーホスティングを提供する Amazon GameLift で AWS Graviton3 プロセッサを搭載したC7gインスタンスが利用可能になりました。Graviton2 と比較して最大25%高いパフォーマンスを提供可能です。 Amazon FSx for NetApp ONTAP now provides additional performance metrics and an enhanced monitoring dashboard Amazon FSx for NetApp ONTAP に新しいCloudWatchメトリクスが追加され、新たにCPU使用率、SSDのIOPS等が確認可能になりました。詳細は こちらのドキュメント をご覧ください。 8/18(金) AWS Batch on Amazon ECS now supports AL2023 AWS Batch on ECS において、ECSに最適化された Amazon Linux 2023 (AL2023) AMIが選択可能になりました。AL2023は2028年3月までの長期サポートを提供しています。AL2023については こちらのブログを参照してください 。 AWS Audit Manager adds integration with Amazon EventBridge AWS Audit Manager で Amazon EventBridge との連携をサポートしました。Audit Managerのイベントを元にEventBrigde経由で、AWS Lambdaや AWS Step Functionsに連携することが可能です。 AWSのユーザーグループである JAWS-UG をご存じの方も多いと思います。ユーザーグループ主導で各技術領域や地域別にいろいろな勉強会やイベントが毎週実施されています。そのいろいろなイベントの予定について、 こちらのNote で定期的に情報がまとめられているのをご存じでしょうか？今週・来週にどういったイベントがあるのか一覧できるようになっているので、ユーザーグループの活動についてご興味がある方は参考にしてください。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

(本記事は 2023/01/27に投稿された Differences to expect when migrating from Azure Cosmos DB to Amazon DynamoDB を翻訳した記事です。) Azure Cosmos DBのワークロードを Amazon DynamoDB に移行することを検討しているお客様から、どのような違いが想定されるのかと聞かれることがあります。この記事では、Azure Cosmos DBからDynamoDBへの移行時に想定される相違点と、それに備えるための計画について説明します。DynamoDBは、一般的なアクセスパターン (通常は大量のデータの保存と取得) に合わせて最適化された、サーバーレスなキーバリュー型のデータベースです。DynamoDBではマルチリージョン、アクティブーアクティブなフルマネージドのデータベースであり、あらゆる規模で１桁ミリ秒という一貫したレイテンシー、保存時の暗号化、バックアップと復元、インメモリキャッシュを実現します。DynamoDBはイベント駆動型アーキテクチャの一部として一般的に使用されており、他のAWS サービスを使用することでDynamoDBの機能を拡張することができます。 用語とアーキテクチャの比較 Azure Cosmos DBとDynamoDBはどちらもNoSQLデータベースですが、移行を開始する前にアーキテクチャと用語の違いを考慮する必要があります。 DynamoDB Azure Cosmos DB テーブル Table コレクション Collection 項目（最大サイズは400 KB） Item (maximum size is 400 KB) ドキュメント（最大サイズは2 MB） Document (maximum size is 2 MB) 属性 Attribute フィールド Field プライマリーキー：パーティションキー Primary key: Partition key パーティションキー Partition key プライマリーキー：ソートキー（任意） Primary key: Sort key (optional) 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields 複合プライマリーキー：プライマリーキー + ソートキー Composite key: Partition key + Sort key 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields ローカルセカンダリインデックス（LSI） ：パーティションキーはメインテーブルと同様で、ソートキーと非キー属性が異なる Local secondary index (LSI) : Same partition key as the main table but different sort key and non-key attributes 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields グローバルセカンダリインデックス（GSI） ：メインテーブルとは異なるパーティションキーとソートキーおよび非キー属性 Global secondary Index (GSI) : Different partition and sort key than in the main table and non-key attributes 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields Amazon Kinesis Data Stream と Amazon DynamoDB Streams Amazon Kinesis Data Streams and Amazon DynamoDB Streams 変更フィード Change Feed 1 RCU: 1 つの読み込みキャパシティーユニットは、強力な整合性を実現するには 1 秒あたり4KB、結果整合性を維持するために 1 秒あたり8KB One RCU: One read capacity unit is 4 KB per second for strong consistency and 8 KB per second for eventual consistency.1 WCU: 1 つの書き込みキャパシティーユニットは 1 秒あたり1KB One WCU: One write capacity unit is 1 KB per second. 1 RU: 要求ユニット (読み取りの場合、1 KBで) One RU: Request unit (1 KB for read)5 RU: 要求ユニット (書き込みの場合、1 KBで) Five RU: Request unit (1 KB for write) 複数のパーティションとテーブルにわたる トランザクションサポート Transaction support across multiple partitions and tables パーティション内のみのトランザクションサポート Transaction support only within a partition Amazon DynamoDB Accelerator (DAX) による読み取り時の応答時間をマイクロ秒で実現 Amazon DynamoDB Accelerator (DAX) for microsecond response time on reads 利用不可 Not available 使用可能なモード: プロビジョンド、オートスケーリング、オンデマンド Available modes: provisioned, autoscaling, and on-demand 使用可能なモード:プロビジョンド、オートスケーリング、サーバーレス Available modes: Provisioned, autoscaling, and serverless 保存時と転送時の暗号化 Encryption at rest and in transit 保存時と転送時の暗号化 Encryption at rest and in transit 論理パーティション Logical partitions 論理パーティション Logical partitions API サポート:DynamoDB API と PartiQL API support: DynamoDB API and PartiQL APIサポート：Core (SQL)、Cassandra、Gremlin、MongoDB、TableおよびPostgreSQL API support: Core (SQL), Cassandra, Gremlin, MongoDB, Table, and PostgreSQL 表 1: DynamoDB と Azure Cosmos DB の用語とアーキテクチャの比較 （注：より理解しやすいように本文の英語を併記しています） Amazon DynamoDB テーブル、スキーマ、およびインデックス 移行をシンプルにするため、Azure Cosmos DBのコレクションとDynamoDBのテーブル間を１対 １でマッピングするようにしてください。DynamoDBにはデータベースの概念はなく、テーブルと呼ばれるエンティティがあります。Azure Cosmos DBのコレクションに基づいてDynamoDBのテーブルを作成する場合： カーディナリティの高いパーティションキーを選択します。DynamoDBはパーティションキーの値を内部ハッシュ関数への入力として使用します。ハッシュ関数の出力によって、項目が保存されるパーティションが決まります。各項目の場所は、そのパーティションキーのハッシュ値によって決定されます。ほとんどの場合、同じパーティションキーを持つ項目は項目コレクションにまとめて格納されます。項目コレクションは、パーティションキーは同じでソートキーが異なる項目のグループとして定義されます。複合プライマリキーを含むテーブルでは、ソートキーはパーティションの境界として使用できます。DynamoDBは、コレクションサイズが10 GBを超えると、仮想的なパーティションをソートキーごとに分割します。ソートキーを使用してAzure Cosmos DBのプライマリ複合インデックスを置き換えることもできます。パーティションキーを選択する方法の詳細については、「 Choosing the Right DynamoDB Partition Key 」を参照してください。 同じパーティションキーと異なるソートキーを必要とするクエリパターンの場合では、非キー属性とともに、メインテーブル作成時にGSIまたはLSIを作成できます。GSIは、非キー属性とともに、テーブルの作成中または作成後でも作成することができます。 注: GSIが推奨されるオプションです。LSIを使用する場合、１つのパーティションキー値に対するインデックス項目の合計サイズが 10GB を超えることはできません。 プライマリキーとソートキーが異なるクエリパターンには、GSIを使用することが推奨されます。GSIはメインテーブルの作成中または作成後に、非キー属性とともに作成することができます。 Amazon Simple Storage Service (Amazon S3) から DynamoDB データをインポート する場合、インポート中にGSIが追加されます。ローカルおよびグローバルセカンダリインデックスは、一度定義されると、DynamoDBによって自動的に管理されます。セカンダリインデックスを使用すると、ベーステーブルと比較してデータサイズを削減するのに役立ちます。セカンダリインデックスのサイズが小さくなるかどうかは、使用される非キー属性の数によって異なりますが、プロビジョニングされたスループットのパフォーマンスを向上させるのに役立ちます。プロビジョニングモードのテーブルにGSIを作成する場合、そのインデックスに予想される負荷に応じて読み取りと書き込みキャパシティーユニットを指定する必要があります。GSI上でのクエリ操作は、ベーステーブルではなく、インデックスから読み取りキャパシティユニットを消費します。テーブル内の項目を追加、更新、削除すると、そのテーブルのグローバルセカンダリインデックスは非同期で更新され、インデックス更新は、ベーステーブルではなくインデックスの書き込みキャパシティーユニットを消費します。テーブル属性をGSIに投影する場合は、新しい更新がベーステーブルとGSIの両方に書き込みを行うため、プロビジョニングされた書き込みキャパシティーユニットをベーステーブルの書き込み容量と同等かそれ以上の値に設定することを推奨します。なお、GSIの更新には ２つの書き込みが必要となり、１つは、インデックスから前の項目を削除する書き込み、もう１つはGSIのパーティションキーまたはソートキーである属性を更新する際に、新しい項目をインデックスに追加するための書き込みとなります。 Azure Cosmos DBは、２つ以上のプロパティを持つ複合インデックスをサポートしています。ソートキーを連結して DynamoDBプライマリキーとセカンダリインデックスにマッピングできます。例えば、Azure Cosmos DBのEmployee ID、Country、State、Cityの各フィールドが複合キーとして定義されている場合、DynamoDB では、Employee IDをパーティションキー、ソートキーを country#state#city に置き換えます。なお、ソートキーの#はユーザー指定の区切り文字で、コロン（:）、カンマ（,）、チルダ（~）などの他の区切り文字に変更できることに注意してください。 DynamoDBはAzure Cosmos DBのデータ型をサポートしているほか、バイナリとセットのデータ型もサポートしています。Azure Cosmos DBからDynamoDBへの属性マッピングについては、表２を参照してください。 DynamoDB Azure Cosmos DB DynamoDB description Number Number 38桁の精度を持つ数値 String String UTF-8バイナリエンコードによるUnicode Boolean Boolean True or False List Array 順序付きの値のコレクション Map Object 順序なしの名前と値のペアのコレクション。Azure Cosmos DBのフィールドにある深くネストされたJSONデータには、このDynamoDBデータ型を使用してください。 Set Not supported 数値、文字列、バイナリなどの同じデータ型のコレクション Binary Not supported 圧縮されたテキスト、画像、または暗号化されたデータ 表 2: DynamoDB 属性マッピング DynamoDBインデックスはAzure Cosmos DBとは異なります。Azure Cosmos DBは転置インデックスを使用しますが、DynamoDBはテーブルパーティションとインデックスパーティションにハッシュアルゴリズムを使用します。Azure Cosmos DBのネストされたJSONインデックスを移行する場合、Azure Cosmos DBのインデックス付き属性は DynamoDB のプライマリキー、LSI、または GSIの一部である必要があります。ネストされたインデックス化されていないオブジェクトをマップデータ型として追加できます。 DynamoDBにはAzure Cosmos DBストアドプロシージャやユーザー定義関数と同等のものはありませんが、 AWS Lambda またはDynamoDB StreamsとLambdaの組み合わせを使用して同等の機能を実行することは可能です。DynamoDBクライアントはDynamoDBデータの事後後処理に責任を持ちます。 キャパシティユニット DynamoDBには、読み取りキャパシティーユニット (１つの RCU は、強力な整合性のある読み取りでは1秒あたり4KB、結果整合性のある読み取りでは 8KB/秒) と書き込みキャパシティーユニット (1 WCU はDynamoDBテーブルへの書き込みで1秒あたり1KB) があります。DynamoDBの RCUとWCU の要件を把握するには、DynamoDBをオンデマンドモードで実行することをお勧めします。移行を完了する前にオンデマンドモードでテーブルの負荷テストを実行することで、アプリケーションとテーブルがライブトラフィックに最適化されていることを確認できます。トラフィックパターンが急上昇するような場合には、引き続きDynamoDBオンデマンドモードの使用を継続します。予測可能なトラフィックパターンでは、負荷テストのベースラインを使用してプロビジョニングされたキャパシティを設定します。DynamoDBがアプリケーショントラフィックの増加に合わせてスケールすることができ、プロビジョニングされたスループットが不十分であることによるエラーを回避できるようにするために、プロビジョニングされたキャパシティーでオートスケーリングを使用することを推奨します。 グローバルテーブル の場合、書き込みキャパシティーの設定は、使用する各リージョンのレプリカテーブルとセカンダリインデックス全体で一貫して設定する必要があります。また、グローバルテーブルのレプリカの読み込みキャパシティー設定は、リージョンの読み取り要件に基づいている必要があります。 有効期限 (TTL) Azure Cosmos DBの有効期限（TTL）設定をDynamoDBに移植できます。Azure Cosmos DBのTTL（秒単位）をDynamoDB のエポックタイムに変換する必要があります。 DynamoDB TTL では、項目ごとにタイムスタンプを定義して、項目が不要になる時期を判断できます。項目が不要になったことを示すタイムスタンプから 48時間以内 に、DynamoDB は書き込みスループットを消費せずにその項目をテーブルから削除します。TTL は、ワークロードのニーズに合わせて最新の項目のみを保持することで、保存されるデータ量を削減する手段として、追加コストなしで提供されます。 DynamoDBのきめ細かなアクセス Azure Cosmos DBには、ロールベースのアクセス制御（RBAC）が組み込まれています。DynamoDBは、 AWS Identity and Access Management（IAM） を使用して、 項目および属性レベルでのきめ細かなアクセス を提供します。IAMポリシーは、DynamoDBのテーブルに格納された項目や属性へのアクセスを制御します。以下は、きめ細かいアクセス制御の２つの例です。 ユーザーの位置情報に基づいて近くの空港の情報を表示するモバイルアプリ。アプリは、航空会社名、到着時刻、フライト番号などの属性にアクセスして表示することができます。ただし、パイロットの名前や乗客数にアクセスしたり表示したりすることはできません。 ユーザーのハイスコアを１つのテーブルに保存するモバイルゲーム。各ユーザーは自分のスコアを更新できますが、他のプレイヤーのスコアを更新することはできません。 マイクロ秒単位のパフォーマンスを実現するAmazon DynamoDB DAX Azure Cosmos DBの読み取り時でマイクロ秒のレスポンスにサードパーティのキャッシュソリューションを使用している場合、 Amazon DynamoDB Accelerator（DAX） を使用することもできます。DAXを使用すると、コードをリファクタリングすることなくキャッシュソリューションを組み込むことができます。DAXは、DynamoDBのための結果整合性のあるライトスルーキャッシュレイヤーです。DAX は、必要に応じてリードスルーモード、ライトスルーモード、またはライトアラウンドモードで使用することができます。 Azure Cosmos DB変更フィードをDynamoDBに再設計する Azure Cosmos DBは、Azure Cosmos DBの変更フィードを使用して他のAzureサービスに変更を伝搬します。DynamoDBには、 変更データキャプチャ（CDC） 用に Amazon Kinesis Data Streams と Amazon DynamoDB Streams という２つのストリーミングオプションがあります。それぞれのストリーミングオプションは、以下で説明するユースケースに対応しています。 Kinesis Data Streamsは、ログデータのキャプチャ、リアルタイムメトリックスとレポート、リアルタイムデータ分析、複雑なストリーム処理などのユースケースに使用します。データストリームは、レコードの順序付けや重複が重要ではない場合に使用します（最終的な宛先で重複を処理し、冪等性のある処理を実現することができます）。たとえば、 Amazon OpenSearch Service では、複数のコンシューマーが無制限のスループットでストリームを並行処理する必要がある場合や、24時間を超えるデータ保持が必要な場合に、バージョニングと一意のIDを組み合わせて処理の重複を防ぐことができます。 DynamoDB Streamsは、時系列の変更ストリームをキャプチャし、この情報を最大24時間ログに保持します。その後、アプリケーション内から DynamoDB Streams Kinesis Adapter とDynamoDB Streams APIを使用して、専用のエンドポイントからデータレコードを読み取ることができます。また、Lambdaを自動スケーリングで使用してDynamoDB Streamsのデータを処理することもできます。 DynamoDB Streamsを使用する場合、ストリーミングデータを利用するには Kinesis Adapterが推奨されます。DynamoDB Streams Kinesis Adapterは、アプリケーションに代わって シャード管理 （シャードの有効期限と分割）を自動化します。また、「 DynamoDB Streams Kinesis Adapter を使用したストリームレコードの処理 」に記載されている、その他の利点もあります。Lambdaを使用してDynamoDBの追加、更新、削除イベントを開始できます。Azure Cosmos DBトリガーの代わりに DynamoDB StreamsとLambdaトリガーを使用することを検討してください。 DynamoDB Streamsの使用方法の詳細については、「 DynamoDB Streams Use Cases and Design Patterns 」を、Kinesis Data Streamsと DynamoDB Streamsの詳細な比較については DynamoDB ドキュメント を参照してください。 400 KB を超える項目の処理 DynamoDB の最大項目サイズは400KB で、これには属性名のバイナリ長 (UTF-8の長さ) と属性値の長さ (バイナリの長さ) の両方が含まれます。DynamoDBでは、400KBを超える項目に対して、GZIPなどの圧縮アルゴリズムを使ってから項目を挿入したり、大きな項目を複数の小さな項目に分割したりすることができます。また、これらの大きなオブジェクトをS3バケットに保存し、S3オブジェクトのURLを属性としてDynamoDBテーブルに保存することもできます。このアプローチでは、DynamoDBのインデックスを使用して高速な検索を行い、S3を耐久性が高く費用対効果の高いオブジェクトストアとして使用できます。 例として、あるアプリケーションが従業員の記録（名前、住所、その他の情報）を管理し、各従業員の600×400ピクセルの画像も保存する必要があるとします。この場合、1人の従業員の項目サイズが 400 KB の制限を超えています。さらに、ユーザーは従業員の項目がDynamoDBに追加されたら、すぐに人事アプリケーションを更新する必要があります。画像のURLを従業員の項目の属性として保存し、イメージを S3 バケットに保存できます。DynamoDB Streamsを使用してLambda関数を起動し、人事アプリケーションを更新できます。以下の図 1 は、このアプローチを示しています。 図１：大きなアイテムサイズを扱うためのアーキテクチャ この記事に記載されているソリューションオプションの詳細については、「 Large object storage strategies for Amazon DynamoDB 」と「 Use vertical partitioning to scale data efficiently in Amazon DynamoDB 」を参照してください。 グローバルテーブルとリージョナルテーブル DynamoDBグローバルテーブルは、独自のクロスリージョンレプリケーションソリューションを構築、維持することなく、マルチリージョン、アクティブーアクティブデータベースを展開するためのフルマネージドソリューションです。テーブルを利用したいリージョンを指定することができ、DynamoDBはそれらのリージョンを介して継続的なデータ変更をテーブルに伝搬します。これにより、ユーザーがどこにいても、低レイテンシーのデータアクセスが可能になります。Azure Cosmos DBのグローバルデータレプリケーションの代わりに DynamoDBグローバルテーブルを簡単に使用することができます。 DynamoDB はレプリカと同期するための非同期レプリケーションを提供し、通常1秒未満でリージョン間のレプリケーションを行います。レプリカの競合が発生した場合、DynamoDBグローバルテーブルでは、ベストエフォートで最終書き込み者優先が使用されます。DynamoDBグローバルテーブルは、グローバルに分散したユーザを持つ地理的に分散したアプリケーションに最適です。 Amazon DynamoDBのバックアップとリストア機能 DynamoDB には、データをバックアップおよびリストアするためのオプションがいくつかあります。 ポイントインタイムリカバリ（PITR） を使用すると、偶発的なDynamoDBテーブルへの書き込みや削除から保護することができます。PITRは継続的にデータをバックアップするので、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス（AWS CLI） 、または DynamoDB API を使用して、過去35日間の任意の時点にテーブルをリストアできます。PITRを使用することで、オンデマンドバックアップの作成、管理、スケジュールについて心配する必要はありません。また、DynamoDB のオンデマンドバックアップ機能を使用して、テーブルのフルバックアップを作成し、長期保存したり、コンプライアンスの対応に合わせてアーカイブを作成することができます。PITRとオンデマンドバックアップはどちらも、テーブルのパフォーマンスや APIレイテンシーには影響を与えません。 Azure Cosmos DB データを DynamoDB に移行 Azure Cosmos DBからDynamoDBへのデータ移行は以下の手順で行います。 Azure Azure データエクスプローラー を使用して CSV 形式でデータをエクスポートします。 データがCSV形式になったら、 AWS Database Migration Service (AWS DMS) を使用して DynamoDB に移行します。AWS DMS に関するチュートリアルについては、「 Migrate Delimited Files from Amazon S3 to an Amazon DynamoDB NoSQL Table Using AWS Database Migration Service and AWS CloudFormation 」を参照してください。 DMSを利用してデータを同期させます。 AWS Glue を使用してCosmos DBを移行できます。詳細については、「 Migrate from Azure Cosmos DB to Amazon DynamoDB using AWS Glue 」を参照してください。 Amazon S3 からテーブルデータをインポートすることもできます。詳細については、「 Amazon DynamoDB can now import Amazon S3 data into a new table 」を参照してください。 まとめ この記事では、Azure Cosmos DBとDynamoDBの関連する機能の違いと、移行時に考慮すべきアーキテクチャパターンについて説明しました。相違点はあるものの、それに適応するための方法があります。グローバルセカンダリインデックスのシャーディングとインデックスの過負荷への戦略、マテリアライズドクエリを使用したスケーラブルなグラフ処理、複合キーを使用したリレーショナルモデリング、そして、DynamoDBでのトランザクションワークフローの実行に関する詳細情報は「 DynamoDB Deep Dive: Advanced Design Patterns 」を参照してください。 質問や提案がある場合は、コメントを残してください。 著者について Utsav Joshi はAWSのプリンシパルテクニカルアカウントマネージャーです。ニュージャージー州在住で、AWSのお客様と協力してアーキテクチャ、運用、およびコスト最適化の課題を解決することを楽しんでいます。余暇には、旅行、ロードトリップ、子供たちとの遊びを楽しんでいます。 Joydeep Dutta はAWSのシニアソリューションアーキテクトです。Joydeepは、AWSのお客様と協力してワークロードを AWS クラウドに移行し、コストを最適化し、アーキテクチャのベストプラクティスを支援することを楽しんでいます。彼は、企業のコストと複雑さを軽減するのに役立つエンタープライズアーキテクチャに情熱を注いでいます。彼はニュージャージー州に住んでおり、余暇には音楽を聴いたり、屋外で過ごしたりしています

前回の記事 では、ストアコンピュータや、POS といった店舗に配置されているワークロードを AWS で稼働させるにあたってのメリットや構成について可用性と応答性能に焦点をあてて考察しました。本記事では、AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察します。 アーキテクチャとして検討すべき対象範囲 店舗システムをクラウド化するメリットとして、前回の記事では以下のメリットを述べました。 コスト削減（ストアコンピュータレス） 運用効率化（システム集約化、ハードウェアライフサイクルからの解放） 機能の高度化（データ活用のし易さ、ハードウェアリソース制約からの解放） 最後の機能の高度化について、店舗システムということで、POS や検品や陳列、発注やスタッフ管理といった店舗業務が検討範囲であることは言うまでもありませんが、”顧客の購買体験を提供する店舗” として考えた場合、購買体験がテクノロジーの進歩と共に変わっていることは、顧客でもある皆様はご理解いただけるのではないでしょうか。 以前：顧客の購買体験は店舗で完結 現在：顧客の購買体験は店舗で完結するわけでなく、ECやモバイルなどをまたがっている（例えばモバイルオーダーで注文して店舗で受け取る、フードデリバリーのように顧客は店舗に来店しないが店舗が介在する） 図1：購買体験の変化 購買体験が変化すると、店舗オペレーションや店舗システムも対応する必要があります。従って、アーキテクチャを考えるにあたり、既存業務の継続はいうまでもありませんが、絶えず変化する顧客ニーズや購買体験の変化に対応できるアーキテクチャが求められます。つまり、下図のような店舗システムにおける主要な機能とデータの配置を、そのままクラウドに移行することはできますが、変化により対応しやすいアーキテクチャに変更する契機と捉えることもできます。 図2：店舗システムと連携先システム 多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマース 絶えず変化する顧客ニーズや購買体験の変化に対して、リアル店舗やアプリケーションを含めた統一した体験を提供する ユニファイドコマース を通して顧客体験を向上させることに取り組まれています。小売業者がリアル店舗、EC サイトなど複数の販売チャネルを消費者に向けて用意する販売戦略がオムニチャネル戦略ですが、それぞれのチャネルにおいて消費者へ “統一された ( Unified ) ” 購買体験を提供することを目指す考え方がユニファイドコマースです。 ユニファイドコマースを実現するにあって、統一された顧客体験を提供するため、顧客との接点であるモバイルアプリ、店頭のタブレット、店舗の POS 端末など、様々なチャネルから顧客の行動履歴やオペレーションのデータをリアルタイムで受け取る必要があります。そして、チャネルが様々であっても、注文や在庫などの複数の拠点から随時更新される情報は最新の正しい値を特定できるようにデータを一元管理し、各チャネルからのリクエストに応じて共通のコマース機能を通してリアルタイムに情報を返す必要があります。 図3：ユニファイドコマース実現イメージ アーキテクチャは、多くの小売業者が注目している MACH (Microservices-based, API-first, Cloud-native SaaS, Headless) アーキテクチャを取り入れることで実現できます。ビジネスの機能別に開発できるようなマイクロサービスで設計し、機能間の連携は API を通して行い、クラウドの柔軟性やスケーラビリティを活用し、フロントエンドはヘッドレスな設計にすることでバックエンドのロジックと切り離して疎結合とする、という原則に基づいたアーキテクチャです。 図4：MACH アーキテクチャによる実店舗と EC が連携するアーキテクチャイメージ ユニファイドコマースを実現するにあたってのガイダンス AWS は、ユースケース別の AWS ベストプラクティスに基づく設計や実装として、AWS Solutions / Solutions Guidance / AWS Samples を用意してます。これらを利用することによって、全てを 1 から考えて自社向けに開発して、他社との差別化にならない部分に時間とお金を投資することを避けられます。 ユニファイドコマースについては、Solutions Guidance（ソリューションガイダンス）が用意されていて、「 AWS でのユニファイドコマースに関するガイダンス 」を参考にできます。 図5：アーキテクチャ図 詳しくは、ソリューションガイダンスのウェブページに加えて、本ソリューションガイダンスを解説しているこちらのブログ（ ビジネスアジリティを加速する AWS のアーキテクチャ part 2 – Unified Commerce on AWS ）にまとめられていますが、MACH アーキテクチャの原則に則っています。 店舗システムの移行にあたってのコンポーザブルアプローチ 店舗システムは、様々な業務機能やデータから構成されています。ストコン や POS といった機器に分かれているものの、長年運用していると、初めは別々に作られていた機能が、相互に関連し合う、いわゆる密結合となっていることは起こり得ます。また、クラウド移行後のユニファイドコマース、MACH アーキテクチャを紹介しましたが、今後を見据えてアーキテクチャを変更するものもあれば、差別化にはならないためそのまま移行するものもあります。 店舗業務の分類 業務システムに対する期待 システム/機能の例 移行方針の例 接客・販売 多様で変化する顧客ニーズに素早く対応することが期待される POS セルフレジ、スマフォレジを展開をしやすくするためアーキテクチャを変更する 在庫 モバイルオーダー、フードデリバリーとの連携をしやすくするためアーキテクチャを変更する バックヤード・店舗管理 接客・販売に注力できるための効率化が、業務だけでなくシステム面でも期待される 検品 既存機能を踏襲するので単純移行する スタッフ勤怠管理 開発と運用の負担を軽減するため SaaS を利用する 1 回で移行するビッグバンアプローチは、シンプルではあるものの移行失敗時による変革のリスクがありますが、共通のコマースメカニズムをマイクロサービスで提供するユニファイドコマースにおいては、必要となる仕組みを段階的に組み立てていくコンポーザブルアプローチにより、リスクの軽減を図りつつ、すばやく実現していくことができます。 密結合となっている、結果として一枚岩（モノリス）なアプリケーションを段階的に移行する設計パターンとして、ストラングラーフィグパターンを利用することができます。利用できるケースや考慮事項、実装といった詳細については、AWS の規範的ガイダンスのクラウドの設計パターン、アーキテクチャ、実装にまとめられています（ こちら ）。 この他、モノリスのアプリケーションからマイクロサービスとして機能を切り出すにあたっては、AWS の規範的ガイダンスの モノリスをマイクロサービスに分解 に、ビジネス能力別に分解、サブドメインによる分解、トランザクションによる分解、チームごとのサービスパターンなどの各パターンの利点と欠点を含む特徴がまとめられているので参考になります。さらに、マイクロサービス間でデータを永続化するためのパターンについては、 マイクロサービスにおけるデータ永続性の実現 にまとめられています。 まとめ 本記事では、店舗システムの AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察しました。顧客の購買体験を提供する店舗として、店舗に限らない各販売チャネルで統一した体験を提供するユニファイドコマースとして検討していく必要性と、ユニファイドコマースを実現する MACH アーキテクチャを紹介し、AWS より提供するソリューションガイダンスや規範的ガイダンスを利用することで、1 から考える必要がなく、実現に向けて迅速に進められることを説明しました。 コンビニエンスストアやスーパーマーケットなど多店舗展開している小売業では、どの機能からどのような移行方針で進めるか、という観点だけではなく、全店舗一斉に切り替えるのか、あるいは地域や店舗形態などの分類単位より段階的に切り替えるのか、という観点も考える必要があります。本記事によって、店舗システムのクラウド化にあたって考えなければならないことが減り、それによりクラウド移行が促進され、結果としてビジネスの成長につながれば幸いです。

しばしば組織の「個性」と表現される組織文化は、人々の働き方、相互作用、変化や課題への対応を決定します。組織の文化が変革の成功を左右する強力な要因であるという認識は、 エビデンス にも裏付けられています。文化の影響は、クラウドの変革においてさらに大きくなります。というのも、クラウドの機能がいかに有用だとしても、その実際の有用性は人々がどのように使うかによって決まるからです。 しかしながら、組織文化が存在し、従業員の行動を形成するということに誰もが同意するとしても、それは主観的で無形のものです。組織文化は、Well-Architected なシステムのように、意図して思慮深く設計および構築することは可能でしょうか？ この記事では、ビジネスの成果を達成するためにクラウド導入を加速する適切な組織文化を構築するためのベストプラクティスを提供します。 なぜクラウド導入に適した組織文化が重要なのか？ クラウドは、コスト削減、業務のアジリティ向上、運用の強靭性、スタッフの生産性向上など、多くの利点を提供しています。クラウドは急速に成長し、広く運用されているにもかかわらず、クラウドサービスのもたらす価値の実現において他の組織よりも成功している組織があります。 私たちのお客さまは、クラウドを利用して企業のデジタル変革を推進する上で、非技術的な要因、特に文化的変革が最大の課題だと述べています。すべての組織には既存の文化があります。文化には、クラウドへの対応を助ける側面もあれば、中立的な側面もあり、はたまた対立する側面もあります。成功している企業は、文化的な手段を活用して潜在的な問題点を特定して対処することで、クラウド導入を加速させています。 たとえば、クラウド導入を成功させるには、セルフサービスと再利用を重要視するオープンで協力的な文化が必要です。クラウドによって、企業は完璧さよりもスピードを優先するようになります。考えられるすべての結果に対して過度に分析する必要はありません。実験が奨励され、従業員は 試行錯誤 を通じて学ぶことができます。一方、指揮統制に基づいて意思決定を行う階層的な文化を持つ組織は、イノベーションを阻害し、クラウド導入における課題に直面する可能性があります。 組織文化の構築（アーキテクティング） 本来、または目的があって、すべての組織には文化があります。成功する企業文化は偶然の産物ではなく、慎重かつ意図的に構築されたものです。文化にはある程度の自発性と予測不可能性があるかもしれませんが、目的意識のある行動によっても影響を受け、形成されることもあります。 お客さま中心の文化 ：クラウドプラットフォームは、ビジネスソリューションを構築するための既製のビルディングブロックを提供します。お客さま中心の文化を促進することで、チームは「 他社との差別化につながらない面倒な重労働 」を省き、IT 内部ではなくビジネス価値とイノベーションに集中できるようになります。お客さま中心の文化は、お客さまのニーズ、嗜好、および行動を深く理解することを含みます。Amazon ではこれを「 Working Backwards 」（お客さまを起点に考え行動する）と呼んでいます。すべてのレベルの従業員がお客さまの満足を優先し、積極的にフィードバックを求め、お客さまからいただいた洞察に基づいて製品とサービスを改善するよう奨励されるべきです。 模範となるリーダーシップの文化 ：CEO はしばしば企業の文化、価値観、および長期的な目標を定義する一連の原則を実施します。これらの原則は、従業員に一体感をもたらすのに役立ちます。ただし、真に効果的なものであるためには、これらの原則が示されるだけでなく、組織のあらゆるレベルで実践される必要があります。リーダーは、「なぜクラウドなのか？」を明確に説明する中で、定義され、測定可能で、期待されるビジネス成果を伝える必要があります。変革をもたらすリーダーは、クラウド戦略の設定と伝達において、「これが私たちの未来です。そのためのロードマップがあり、その道のりを成功させるために必要なリソースを提供します。」と企業自身、自分たちの事業に対して伝えます。信頼を育み、リソースを提供し、自律性とコラボレーションを促進することで、リーダーは従業員が主体性を発揮し、前向きな変化を推進できるよう支援します。また、従業員が叱責を恐れることなく問題をエスカレーションできるオープンで安全な環境も醸成します。 データ駆動の意思決定文化 ：今日の意思決定には、固定的なオペレーション情報だけでなく、次のステップや将来の見通しをリアルタイムで分析する必要があります。クラウドは、事業において戦略的意思決定を行うために膨大な量のデータを処理するための強力な人工知能（AI）および機械学習（ML）ツールを提供します。クラウド導入のメリットを最大化するには、データを使用して情報を提供し、優先順位を付け、意思決定の指針を決めることに重点を置く、データ駆動の意思決定文化が必要です。たとえば、製造業ではクラウドベースの AI と ML ツールを使用してセンサーデータを分析し、ダウンタイムを最小限に抑え、コストを削減するためのメンテナンスを予測しスケジュールすることができます（予知保全）。データ駆動の意思決定文化を実施することで、予知保全分析からの得た知見を活用してメンテナンスタスクを優先順位付けし、リソースを効率的に割り当てることができます。 アジリティ、イノベーション、実験、リスクを取る文化 ：クラウドコンピューティングはアジャイル開発文化に適しています。それは実験、柔軟性、インクリメンタル（段階的）な提供の原則に基づいています。クラウドネイティブ技術は、サービス提供に影響を与えることなく、システムの迅速かつ頻繁な変更をサポートします。アジャイル開発アプローチでは、完璧よりもスピードが重視されます。望ましくない結果が発生した場合に、実行してはいけないアクションを知っておくことには価値があります。たとえば、Amazon では、 リーダーシッププリンシプル を指針として誘導し実行するためのメンタルモデルを使用しています。「Bias for Action」はその指針の 1 つで、「ビジネスにおいてスピードが重要です。多くの決定と行動は元に戻せるため、詳細な調査は必要ありません。計算されたリスクテイクを大切にします。」と述べています。 継続的な学習の文化 ：これは、従業員がクラウドの環境に対応するスキルと知識を持つことを確実にするために、組織が従業員のトレーニングと教育を優先する必要があることを意味します。これにはクラウドサービスに関する技術的なトレーニングだけでなく、コミュニケーションやコラボレーションといったソフトスキルを含みます。学習は自助努力で為すべきであり、イベント駆動のものでは成り立ちません。組織全体で絶え間なく学ぶためには、測定と報酬の仕組みが必要です。トレーニングだけでなく、クラウドの経験が豊富な従業員が新しいチームメンバーを指導するための社内メンターシッププログラムを設立することもできます。 再利用の文化 ：クラウドの価値を高めるためには、ソフトウェア資産の再利用が必要です。再利用により、組織は既存の実証済みで信頼性の高いソフトウェアコンポーネントを活用して、効率性の向上、コスト削減、市場投入までの時間の短縮を実現できます。たとえば、従来のソフトウェア開発者はインフラストラクチャリソースの複雑さを理解するのに時間を費やし、ビジネス価値を提供するソフトウェアの構築に充分な時間を割くことができませんでした。クラウドでは、 Infrastructure as Code (IaC) を使用することで、開発者は事前に構築されテストされた再利用可能なテンプレートを選択し、ソフトウェアアプリケーションを構築するために必要なインフラストラクチャコンポーネントを自動的にプロビジョニングします。再利用の文化には、個人が自分の知識、経験、リソースを他者と積極的に共有できる、オープンで協力的な考え方が必要です。 自動化とセルフサービスの文化 ：クラウド導入には、クラウドの強力な自動化ツールとセルフサービス機能を活用したリソースの提供、管理、利用が含まれます。セルフサービスには、従業員が信頼されて権限を持ち、自らのタスクに責任を持つような文化の変革が必要です。たとえば、オンプレミス環境では、アプリケーションチームは通常、IT インフラストラクチャチームにインフラのプロビジョニングを依頼します。クラウドでは、チームは自分自身で（セルフサービスで）自動化プロセスを通じてインフラをプロビジョニングします。これにより、開発者は自由になり、チケット処理を待つ代わりにビジネス価値を提供するための時間を増やすことができます。クラウド導入には集中的かつ組織的な取り組みが必要ですが、これを推進する Cloud Centre of Excellence (CCoE) が役立つ場合があります。この多種専門的なチームは、クラウドポリシー、ベストプラクティス、トレーニング、アーキテクチャを反復可能で自動化された、セルフサービス型の方法で提供することで、企業の成熟度を高めることができます。 セキュリティとコンプライアンスの文化 ：クラウド導入ではセキュリティとコンプライアンスに関する新たな考慮事項が生じます。組織はクラウド環境におけるデータ保護、プライバシー、および規制遵守を優先する必要があります。セキュリティとコンプライアンスに重点を置いた文化は、 責任共有 の意識を持つことで、セキュリティ対策がクラウド導入のあらゆる側面に統合されることを保証します。 ガバナンスの文化 ：クラウドサービスの利用を開始するのは容易になりましたが、企業のクラウド導入はより複雑になりました。適切なガバナンスがないと、クラウドの利用がすぐに制御を失う可能性があります。クラウドでは、インフラストラクチャの容量が「固定」から「無制限」に変わりますし、コストモデルも固定費から変動費（pay-as-you-go；従量課金）に変わります。これにより価値を提供するのに必要なアジリティは提供されるものの、シャドウ IT や経緯が不明のコストが発生することがあります。ここでクラウドガバナンスの文化が重要となります。ガバナンスの文化は、組織がクラウドの利用を管理し制御するために実施する一連のポリシー、手順、プロセスです。それはリアルタイムで自動化された「ガードレール」を通じてアジリティを維持しながら統制力を犠牲にすることなく実施されます。 おわりに 企業はそれぞれが複雑でユニークであり、文化が異なることもあります。組織文化は変革にとって重要であり、従業員のマインドセット、エンゲージメント、コラボレーション、変化への適応性、レジリエンスを形成します。変革の目標をサポートし、それに沿った文化を育むことで、組織は成功かつ持続可能な変革の実現可能性を高めることができます。Amazon のイノベーションへのアプローチは、文化からプロセス、テクノロジーに至るまでの一連の方法論、概念、ツールに基づいています。 参考情報 AWS CAF – Culture Evolution AWS Well-Architected Mental Models for Your Digital Transformation AWS Prescriptive Guidance – Accelerating cloud adoption through culture, change and leadership Learn from Amazon’s Approach to Innovation Leading and Innovating with Leadership Principles Elements of Amazon’s Day 1 Culture The Imperatives of Customer-Centric Innovation How to create a data-driven culture 本記事は、Nurani Parasuraman および Siraj Gadne による「 Maximize Cloud Adoption Benefits with a Well-Architected Organizational Culture 」を翻訳したものです。翻訳はカスタマーソリューションマネージャの山泉 亘が担当しました。 ＜原著執筆者について＞ Nurani Parasuraman AWS のカスタマーソリューションチームの一員です。彼は、人、プロセス、テクノロジー全体にわたる基本的な移行から大規模なクラウド変革への推進を通じて、企業が成功し、クラウド運用から大きなメリットを実現できるよう支援することに情熱を注いでいます。AWS に入社する前は、複数の上級管理職を歴任し、ファイナンスサービス、小売、通信、メディア、製造におけるテクノロジーの提供と変革を主導していました。彼は金融学の MBA と機械工学の理学士号を取得しています。 Siraj Gadne アマゾンウェブサービスのカスタマーソリューションチームのリーダーです。彼は真のビルダーであり、移行、モダナイゼーション、トランスフォーメーションを通じて顧客がクラウド運用のメリットを最大化できるよう支援することに情熱を注いでいます。Siraj は、25 年間のキャリアの中で、コンサルティングと企業の分野でいくつかの指導的地位を歴任してきました。AWS に入社する前、Siraj はザ・コカ・コーラ社、Merkle Inc.、キャップジェミニに勤務し、クラウド対応とデジタルトランスフォーメーションの分野で顧客にサービスを提供していました。

2023 年 7 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Personalize 基礎編 レコメンドを機械学習の専門知識無しで利用できる Amazon Personalize の使い方を紹介します 資料（ PDF ） | 動画（ YouTube ） 対象者 レコメンドの導入を検討されている方 本 BlackBelt で学習できること Amazon Personalize がなぜ必要なのかと基本的な使い方 スピーカー 近藤健二郎 ソリューションアーキテクト Amazon Neptune ではじめるグラフデータベース入門 近年注目を集めているグラフデータベースについて、 Amazon Neptune の便利機能や簡単なクエリの実行結果を交えながらご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースに関する基本的な知識を持っている方 データベースに関連する開発や運用経験を持っている方 グラフデータベースに興味を持っている方 Amazon Neptune に興味を持っている方 本 BlackBelt で学習できること グラフデータベースの概念やユースケース グラフデータベースのクエリ基礎知識 Amazon Neptune の概要 グラフデータベースの学習方法 スピーカー 木村達也 ソリューションアーキテクト DX の加速に向けた AWS クラウド導入フレームワーク (AWS CAF) の活用 AWS クラウド導入フレームワーク (AWS CAF) は、AWS の経験とベストプラクティスを活用しており、AWS の利用によるデジタルトランスフォーメーション (DX) とビジネスの成果の加速を促すフレームワークです。本セミナーでは、AWS CAF を活用していただくために、そのホワイトペーパーを読み解くための、コツやポイントを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 DX 推進の施策を検討中の システム / DX 部門の方 クラウド活用を体系的に進めたい IT 担当者、または CCoE の方 オンプレミスとクラウドの考え方の違いを確認したいシステム部門の方 本 BlackBelt で学習できること AWS クラウド導入フレームワーク (AWS CAF) の読み解く方法を学習でき、クラウドを活用したデジタルフォーメーション（DX）の進め方を学ぶことができます。 スピーカー 釈迦郡一郎 カスタマーソリューションマネージャー モダナイゼーションプロジェクト立ち上げに向けたポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。一方で、抽象的なために全容が把握しずらい、検討したが関係者の共通認識がはかれないまま進めた結果頓挫してしまった、どこから手をつければいいか分からない、といった声も聞くようになってきました。本セッションでは、モダナイゼーションプロジェクトの立ち上げに向けて、事前に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 モダナイゼーションに取り組むうえで、企画フェーズでの検討内容に関心があるリーダー、責任者の方 システムのモダナイゼーションに取り組もうとしているが、その対象選定や方針策定のポイントを確認したい方 本 BlackBelt で学習できること モダナイゼーションプロジェクト立ち上げ前に検討・考慮すべきポイント モダナイゼーションに取組む上での対象選定や方針策定の進め方 スピーカー 平岩梨果 ソリューションアーキテクト Modernize Enterprise Java Application エンタープライズにおける Java アプリケーションをモダナイゼーションするポイントやアプローチについて、AWS の各種サービスの組み合わせ方を紹介しながら理解を深めます。 資料（ PDF ） | 動画（ YouTube ） 対象者 Java アプリケーションのモダナイゼーションに関心のある、IT アーキテクトやソフトウェアエンジニア Java アプリケーションの維持運用に課題を感じている方 本 BlackBelt で学習できること エンタープライズの Java アプリケーションの構成要素や処理方式に対し、AWS の各種サービスを組み合わせることでどのようなモダナイゼーションが実現できるのか、どのようなメリットがあるのか、について理解を深めることができます。 スピーカー 倉元貴一 ソリューションアーキテクト AWS CDK 概要 (Basic #1) AWS Cloud Development Kit (AWS CDK) の概要から開発の流れまでをご紹介します。AWS CDK で Amazon VPC をデプロイするデモも含んでいます。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア プログラミングの知識がある、あるいはこれから学ぶ方 本 BlackBelt で学習できること Infrastructure as Code の基礎から、AWS CDK のコンセプトや誕生ストーリー、開発の流れまでを概観できます。 スピーカー 高野賢司 ソリューションアーキテクト AWS CloudFormation#1 基礎編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。 本セミナーは、AWS CloudFormation について解説するシリーズの初回である基礎編です。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation をこれから学ぶ方、概要をお知りになりたい方 本 BlackBelt で学習できること AWS CloudFormation を扱う上で必要になる用語や、基本機能について解説しています。 AWS CloudFormation の基本的な使い方について学習いただけます。 スピーカー 福井敦 パートナーソリューションアーキテクト Amazon GameLift FlexMatch マルチプレイヤーゲーム用のマネージドなマッチメイキングサービス Amazon GameLift FlexMatch について網羅的に解説します 資料（ PDF ） | 動画（ YouTube ） 対象者 マッチメイキングの導入を検討されている方 現行のマッチメイキングの仕組みに課題を感じている方 本 BlackBelt で学習できること Amazon GameLift FlexMatch の抑えておきたい概念と仕組みについて網羅的に学習できます スピーカー 秋山周平 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-08 AWS Cloud Development Kit (CDK) 開発の基礎 ソリューションアーキテクト 高野 賢司 2023-08 AWS Control Tower 基本編 ソリューションアーキテクト 桂井俊朗 2023-08 AWS Control Tower 手順編 既存 Organizations での有効化 クラウドサポートエンジニア 大西朔 2023-08 Amazon CloudFront ( レポート / モニタリング / ロギング編 ) ソリューションアーキテクト 長谷川純也 2023-08 Amazon Personalize 応用編 ソリューションアーキテクト 近藤健二郎 2023-09 AWS Batch HPC スペシャリストソリューションアーキテクト 小林広志 2023-09 Amazon Managed Grafana ソリューションアーキテクト 大井友三 2023-09 Amazon Kinesis Video Streams 基礎編 ソリューションアーキテクト 宇佐美雅紀 2023-09 Amazon Kinesis Video Streams 応用編 IoT スペシャリストソリューションアーキテクト 三平悠磨 2023-09 AWS SimSpace Weaver コンセプト編 ソリューションアーキテクト 阿南麻里子 2023-09 Virtual Andon on AWS ソリューションアーキテクト 山田航司 2023-09 ミニチュア工場デモ : AWS IoT によるデータ集約と可視化 ソリューションアーキテクト 鈴木健吾 2023-09 AWS Key Management Service セキュリティソリューションアーキテクト 平賀敬博 2023-09 AWS Secrets Manager ソリューションアーキテクト 押川令 2023-09 Amazon GameLift FleetIQ ソリューションアーキテクト 安藤怜央 &nbsp;