こんにちは。カスタマーソリューションマネージャー (CSM) の仁科です。昨今、クラウドがビジネスにもたらす経済的価値を追求し、会社や組織全体としてこれを享受するための施策を立案／推進するチームを立ち上げるお客さまが珍しいものではなくなりました。このチームは 「クラウド活用推進組織」 や 「クラウド CoE (Centre of Excellence)」、もしくは省略して 「CCoE」 と呼ばれています。 以前のブログ では、CCoE の活動に関して AWS Summit Online 2022 の事例を交えながら、CCoE の活動内容を検討する際の考え方についてご紹介しました。今回は AWS Summit Tokyo 2023 の CCoE に関する事例や関連の事例から、CCoE を取り巻く状況をご紹介したいと思います。前編では CCoE の活動事例や共通点をご紹介し、後編では少し視点を変えて、2023 年の事例から見えてくる CCoE の在り方を考察します。 この記事は、次のような方を読者として想定しています。 まだ CCoE を組成していないお客さまで、CCoE について知りたい、もしくは、CCoE を組成しようと考えている方 CCoE を組成しているお客さまで、業務の質を良くしたい もしくは 業務の幅を広げたいと考えている方 2023 年の CCoE に関する事例を知りたい方 クラウド活用推進に必要な観点 以前のブログ でもご紹介しましたが、重要な観点ですので改めて簡単にご説明します。クラウドを活用しビジネス成果を加速させるための活動を検討する際に観点として利用できるのが、 AWS クラウド導入フレームワーク (AWS CAF) というフレームワークです。AWS CAF では、クラウド活用推進のために必要な活動を 6 つの観点 (下記の図の左側に記載している非技術的な観点のビジネス、ピープル、ガバナンス、右側に記載している技術的な観点のプラットフォーム、セキュリティ、オペレーション) にグループ化しています。これら 6 つの観点すべてが CCoE の活動スコープと言えますが、すべてを CCoE 単独で実施する必要はありません。各企業の事業環境や事業戦略上の優先順位を踏まえ、CCoE がどの領域にどの程度入っていくのかを検討し、関係部署と役割を調整しながら、それぞれの企業にあった CCoE としての活動を決めて、実施していくことが重要です。 2023 年の CCoE の活動事例と共通点 AWS Summit Tokyo 2023 でも以下のセッションで CCoE の活動に関して触れられています。詳細に関しては、ぜひ動画や資料をご確認ください。 トヨタ CCoE が進める Developer eXperience のカイゼン(CUS-10) [ 動画 、 資料 ] 国でもできたスマートなクラウド利用 ～高速試行錯誤しながら進歩を続けるクラウド CoE～(CUS-16) [ 動画 、 資料 ] 2023 年の事例としては「カイゼン、改善」というキーワードが見られました。トヨタ自動車の事例では「開発者の仕事を楽にすること」を「DevEx (Developer eXperience) カイゼン」として取り組まれていました。デジタル庁／農林水産省の事例では「統制を改善し続けるプロセス」を高速回転させ、改善に継続的に取り組まれていました。 こちらの記事 でも記載している通り、「クラウドを使って、会社、組織をもっと良くしたい」という心構えが表れていることが分かります。クラウド自体が日々進化していることから、一度何かを実施して終わり、ではなく、CCoE として継続して改善を続けていくことでクラウド活用を推進していくことが重要です。 また、CCoE がクラウド利用のブロッカーにならないように、現場のために動く、現場の効率化を図るために活動しているという内容も見られました。トヨタ自動車では、ガードレール型セキュリティや最低限開発に必要な Git や CI/CD などを開発者に提供することで、開発開始までのリードタイムを約 96％ 削減したという事例をご紹介いただいています。CCoE の活動によって、開発者がより開発をしやすくなる環境を整えているという良い事例です。デジタル庁／農林水産省では、クラウド利用ガイドラインにおいて、「標準化・共有化・シンプル化によりムリ・ムダ・ムラを無くす」をコンセプトに、クラウド利用者が必要なルールをわかりやすくシンプルに記載し、持続的に更新いただいています。ガイドラインやルールを決めても、内容が複雑だったり、チェックする項目が多いと形骸化しがちです。ガイドラインを作るにあたって、利用者目線で本当に必要な内容は何かを検討して決定していくことが重要です。2 つの事例から、 こちらの記事 で記載している「利他的であること」という心構えも変わらず見られることが分かります。 2023 年は上記の事例のほかに、CCoE という単語は明確にはないものの、クラウドの人材育成や組織横断的なクラウド利用改善の取り組み、必要に応じて AWS パートナーを活用する事例も見られました。以下にその一部を抜粋します。 ベイシアが目指す「クラウド化」周回遅れからデジタル先進企業への挑戦(AP-16) [ 資料 ] クルマのサブスク「KINTO」のアジリティとガバナンスを両立する DBRE の取り組み(CUS-11) [ 動画 、 資料 ] 情シスの情シスによる情シスのための人材育成-リスキリングとそれに反する教育後回しジレンマ克服の具体策-(CUS-01) [ 動画 、 資料 ] 国の DX を支えるデジタル人材の育成(AWS-53) [ 動画 、 資料 ] 前述した通り、CCoE がクラウドに関するあらゆる改善、活動をすべて実施すべき、というわけではなく、あくまで CCoE も含めたいずれかの部署や横断型組織などでクラウド利用に関しての課題全体に取り組んでいくことが重要であると言えます。ぜひ、 AWS Summit Tokyo 2023 のその他の事例についても参照してみていただければと思います。 まとめ 前編では、 AWS Summit Tokyo 2023 から見る、2023 年の CCoE の活動事例や共通点をご紹介しました。 CCoE として必要な心構えである 「クラウドを使って、会社、組織をもっと良くしたい」 「利他的であること」 は引き続き重要であり、各会社、組織で取り組まれている 必ずしも CCoE 単独でクラウド推進におけるすべての課題解決を行う必要はなく、いずれかの部署や横断型組織も含めてクラウド推進における課題に取り組んでいくことが重要 後編では、2023 年の事例から見えてくる CCoE の在り方を考察します。 参考情報 CCoE 活動検討のはじめの一歩 今から始める CCoE、3 つの環境条件と 3 つの心構えとは クラウドマイグレーションの意外なつまづきポイントを解説！AWS移行セミナー～組織や人材、ガバナンスなど非技術的な領域の課題と対策～ AWSクラウド導入フレームワーク (AWS CAF) MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (前編) MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (後編) 著者 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 仁科 みなみ

IBM MQは、世界の銀行、航空会社、医療機関、保険会社など、多くの企業組織で使用されているメッセージ指向ミドルウェア (MOM) 製品です。 AWS では、既存のオンプレミスにある MOM システムをクラウドで実行されている新しいアプリケーションと統合できる方法についてお客様からよくお問い合わせいただきます。お客様は、クラウドアプリケーションからこれらのメッセージングシステムにメッセージを送受信できる、費用対効果が高く、スケーラブルで手間のかからないソリューションを探しています。 このブログ記事では、オンプレミスの IBM MQ から Amazon MQ 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Notification Service (Amazon SNS) への双方向ブリッジをセットアップする方法を示しています。 これにより、フルマネージド型の AWS メッセージングサービスと Apache Camel を使用してプロデューサーアプリケーションとコンシューマーアプリケーションを統合できます。このブログでは前述のソリューションをデプロイする方法と、SNS、SQS、およびデモ用の IBM MQ クラスター環境（ AWS Fargate 上の Amazon Elastic Container Service (ECS) で実行）を使用して、実行中の統合をテストする方法を学びます。 このソリューションは、ブログ記事「 Migrating from IBM MQ to Amazon MQ using a phased approach 」で説明されているアプローチを使用して、段階的な移行の一部として使用することもできます。 ソリューション概要 Apache Camel ブローカークラスターを使用して、IBM MQ システムと、ターゲットシステム（ActiveMQ エンジンの Amazon MQ、SNS トピック、 SQS キューなど）を双方向に統合します。 次の例では、AWS サービス (この場合は AWS Lambda と SQS) が SNS トピック経由で IBM MQ に公開されたメッセージを受信します: クラウドメッセージコンシューマー (Lambda と SQS) は、ソリューション内のターゲット SNS トピックにサブスクライブします。 Apache Camel ブローカーは、 AWS Secrets Manager に保存されている認証情報で IBM MQ に接続し、IBM MQ’s Java Library を使用してキューから新しいメッセージを読み取ります。 IBM MQ’s Java Library を利用する場合、IBM MQ メッセージのみがソースとしてサポートされています。 Apache Camel ブローカーは、これらの新しいメッセージをターゲット SNS トピックに公開します。 Amazon SNS Extended Client Library for Java を使用して、256 KB を超えるメッセージを Amazon Simple Storage Service (Amazon S3) バケットに保存します。 Apache Camel は、2 回再試行しても SNS に配信できないメッセージを S3 のデッドレターキューバケットに保存します。 次の図は、ソリューション内で SQS キューから IBM MQ にメッセージを送り返す方法を示しています: Lambda を使ったサンプルメッセージプロデューサーは、SQS キューにメッセージを送信します。 Amazon SQS Extended Client Library for Java を使用して 256 KB を超えるメッセージを送信します。 Apache Camel ブローカーは、必要に応じて SQS Extended Client Libraryを使用して SQS に公開されたメッセージを受信します。 Apache Camel ブローカーは、メッセージを IBM MQ ターゲットキューに送信します。 同様に、ブローカーは IBM MQ に配信できないメッセージを S3 デッドレターキューバケットに保存します。 段階的なライブマイグレーションは、次の 2 つのステップで構成されます: ブローカーサービスをデプロイして、既存の IBM MQ キューへのメッセージの読み取りと書き込みを可能にします。 コンシューマーまたはプロデューサーが移行されたら、対応するサービスを新しく選択したサービス (SNS または SQS) に移行します。 次に、 AWS Cloud Development Kit (AWS CDK) を使用してソリューションをセットアップする方法を学習します。 ソリューションのデプロイ 必要条件 AWS CDK TypeScript Java Docker Git Yarn Step 1: リポジトリをクローンする git を使用してリポジトリをクローンします: git clone https://github.com/aws-samples/aws-ibm-mq-adapter Step 2: テスト用 IBM MQ 認証情報のセットアップ このデモでは、IBM MQ の相互 TLS 認証を使用します。そのためには、 app フォルダで以下のコマンドを実行して X.509 証明書を生成し、AWS Secrets Manager に保存する必要があります: X.509 証明書を生成します。 ./deploy.sh generate_secrets Apache Camel ブローカーに必要なシークレットを設定します ( &lt;integration-name &gt; は、たとえば dev と置き換えてみてください) : ./deploy.sh create_secrets broker &lt;integration-name &gt; 模擬用の IBM MQ システムのシークレットを設定します: ./deploy.sh create_secrets mock cdk.json ファイルを、ここまでのコマンドで出力されたシークレット ARN で更新します。（訳註：IBMMQ_TRUSTSTORE_… と IBMMQ_KEYSTORE_… はサンプルコード中の複数箇所で定義されていますが、全て更新が必要です）: IBM_MOCK_PUBLIC_CERT_ARN IBM_MOCK_PRIVATE_CERT_ARN IBM_MOCK_CLIENT_PUBLIC_CERT_ARN IBMMQ_TRUSTSTORE_ARN IBMMQ_TRUSTSTORE_PASSWORD_ARN IBMMQ_KEYSTORE_ARN IBMMQ_KEYSTORE_PASSWORD_ARN 独自の IBM MQ システムを使用していて、すでに X.509 証明書が利用可能になっている場合は、スクリプトを実行した後にスクリプトを使用してそれらの証明書を AWS Secrets Manager にアップロードできます。 Step 3: ブローカーの設定 このソリューションでは 2 つの Apache Camel ブローカーがデプロイされます。1 つはテスト用 IBM MQ システムからのメッセージを読み取るため、もう 1 つはメッセージを送り返すためのものです。送信用、受信用で異なるApache Camel ブローカーの使用は２つの目的があります。１つ目は、Auto Scaling 機能をより有効活用するためです。２つ目は、送信と受信のどちらかに問題発生しても、もう片方に影響を与えないためです。 cdk.json ファイルを次の値で更新します。: accountId : ソリューションをデプロイする AWS アカウント ID。 region : ソリューションをデプロイする AWS リージョンの名前。 defaultVPCId : ブローカーとモックがデプロイされている AWS アカウント内の既存の VPC ID を指定します。 allowedPrincipals : アカウント ARN (例： arn:aws:iam::123456789012:root を追加して、この AWS アカウントがブローカーとの間でメッセージを送受信できるようにします。このパラメーターを使用して、SQS と SNS の両方の統合にクロスアカウント関係を設定し、複数のコンシューマーとプロデューサーをサポートできます。（訳註：サンプルコード中の複数箇所で定義されていますが、全て更新が必要です。） Step 4: ソリューションのブートストラップとデプロイ 開発アカウントに正しい AWS_PROFILE と&nbsp; AWS_REGION 環境変数が設定されていることを確認してください。 yarn install を実行して CDK の依存関係をインストールします。 CDK をブートストラップする ために yarn cdk bootstrap –-qualifier mq &lt;aws://&lt;account-id &gt;/&lt;region &gt; コマンドを実行します。 最後に、 yarn cdk deploy '*-dev' –-qualifier mq --require-approval never を実行して、ソリューションを dev 環境にデプロイします。 Step 5: 統合のテスト AWS System Manager Session Manager とポートフォワーディングを利用してテスト用 IBM MQ インスタンスへのトンネルを確立し、ウェブコンソールにアクセスして手動でメッセージを送信します。ポートフォワーディングの詳細については、ブログ「 Amazon EC2 instance port forwarding with AWS Systems Manager 」を参照してください。（訳註：サンプルコードの README の「 How to test locally 」の項目も適宜ご参照ください） コマンドラインターミナルで、開発アカウントに正しい AWS_PROFILE と AWS_REGION 環境変数が設定されていることを確認します。 さらに、次の環境変数を設定します: IBM_ENDPOINT : IBM MQ のエンドポイント。例: IBM モック用のネットワークロードバランサー mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com （訳註：マネジメントコンソールでデプロイされたロードバランサーのDNS名をコピーすることで取得可能です） BASTION_ID : 踏み台ホストのインスタンス ID。この出力は、「ステップ 4: ソリューションをブートストラップとデプロイ」において、 mqBastionStack のデプロイ後のリストから取得できます。 以下のコマンドを使用して環境変数を設定します: export IBM_ENDPOINT=mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com export BASTION_ID=i-0a1b2c3d4e5f67890 スクリプト test/connect.sh を実行します デフォルトの IBM ユーザー ( admin ) と AWS Secrets Manager に mqAdapterIBMockAdminPassword として保存されているパスワードを使用して、 https://127.0.0.1:9443/admin から IBM ウェブコンソールにログインします。 IBM MQ からのデータの送信と SNS での受信: IBM MQ コンソールで、ローカルキューマネージャー QM1 → DEV.QUEUE.1 にアクセスします Hello AWS という内容のメッセージを送信してください。このメッセージは AWS Fargate によって処理され、SNS に公開されます。 SQS コンソールにアクセスし、 snsIntegrationStack-dev-2 プレフィックスキューを選択します。これは SNS トピックにサブスクライブされたテスト用の SQS キューです。 [メッセージの送受信] を選択します。 [メッセージをポーリング] を選択すると、前に IBM MQ に送信された Hello AWS メッセージが表示されます。 Amazon SQS から IBM MQ へのデータの返送: SQS コンソールにアクセスし、 sqsPublishIntegrationStack-dev-3-dev というプレフィックスの付いたキューを選択します。 [メッセージの送受信] を選択します。 [メッセージ本文] には、 Hello from AWS を追加してください。 [メッセージを送信] を選択します。 IBM MQ コンソールで、ローカルキューマネージャー QM1 → DEV.QUEUE.2 にアクセスして、このキューの下にリストされているメッセージを探します。 Step 6: クリーンアップ cdk destroy '*-dev' を実行して、このウォークスルーの一部としてデプロイされたリソースを削除します。 まとめ このブログでは、Amazon SQS と Amazon SNS を使用して IBM MQ とクラウドアプリケーション間でメッセージを交換する方法を学びました。 独自の統合を始めることに興味がある場合は、GitHub リポジトリの README ファイルを参照してください。JMS、NMS、AMQP 1.0 などの業界標準の API とプロトコルを使用して既存のアプリケーションを移行する場合は、リポジトリに用意されている手順を使用して Amazon MQ と統合することを検討してください。 Kubernetes で Apache Camel を実行することに興味がある場合は、代わりに Apache Camel K を使用するようにアーキテクチャを変更することもできます。 その他のサーバーレス学習リソースについては、 Serverless Land をご覧ください。 この記事は、Principal Security Consultant の Joaquin Rinaudo と DevOps Consultantのゲジム・ムスリアンが執筆したものを Solutions Architect の三厨が翻訳しました。原文は こちら （記事公開日：2023 年 8 月 15 日）。 <!-- '"` -->

あと数日したら飛行機で南に向かいます。ラテンアメリカツアーの始まりです。独りではありません。 Jeff や Seb といったニュースブログの執筆者たちも AWS Community Day、そして ペルー 、 アルゼンチン 、 チリ 、 ウルグアイ のイベントで講演します。私たちを見かけたら声をかけてください。皆さんにお会いできるのを心待ちにしています。 8月14日週のリリース 8月14日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 AWS AppSync が GraphQL API のすべてのリゾルバーの JavaScript をサポート – 2022年 、AppSync が JavaScript パイプラインリゾルバーをサポートするようになったことが発表されました。そして、 先週 から、JavaScript を使用してユニットリゾルバー、パイプラインリゾルバー、および AppSync Javascript ランタイム上で実行する AppSync 関数を記述できるようになりました。 AWS CodePipeline が GitLab をサポート – AWS CodeCommit、Bitbucket、GitHub.com、GitHub Enterprise Server などのプロバイダーに加えて、 GitLab.com リソースリポジトリ で、AWS CodePipeline を使用してコード変更をビルド、テスト、デプロイできるようになりました。 Amazon CloudWatch Agent が OpenTelemetry トレースと AWS X-Ray のサポートを追加 – 新しいバージョンのエージェントでは、単一のエージェントで CloudWatch だけでなく OpenTelemetry と AWS X-Ray の メトリクス、ログ、トレースを収集 できるようになりました。テレメトリ収集のインストール、設定、管理が簡素化されます。 新しいインスタンスタイプ: Amazon EC2 M7a と Amazon EC2 Hpc7a – 新しい Amazon EC2 M7a は、第 4 世代 AMD EPYC プロセッサを搭載した汎用インスタンスです。このインスタンスタイプの詳細な仕様については、一般提供の発表に関する ブログ記事 を参照してください。新しい Amazon EC2 Hpc7a インスタンスには、第 4 世代 AMD EPYC プロセッサも搭載されています。これらのインスタンスタイプは、ハイパフォーマンスコンピューティング向けに最適化されています。各 Amazon EC2 Hpc7a インスタンスタイプの特性については、 Channy Yun のブログ記事 を参照してください。 AWS DeepRacer 教育者プレイブック – 先週、AWS DeepRacer 教育者プレイブックが発表 されました。このプレイブックは、基盤となる機械学習 (ML) カリキュラムとラボをクラスに統合することを目的とした教育者向けのツールです。教育者は、これらのプレイブックで自動運転車のシミュレーションを使って機械学習の基礎に関する学生のスキルを向上させることができます。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 AWS Lambda を使用した Apache Kafka ストリーム処理のガイド – Julian Wood が Lambda と Apache Kafka を使用する方法に関する包括的なガイドを公開しました。Amazon Kinesis ユーザーでも問題ありません。類似のトピックを紹介しているこの ビデオシリーズ を活用してください。 AWS の公式ポッドキャスト &nbsp;– 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報 &nbsp;– 私の同僚である Ricardo &nbsp;が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Hybrid Cloud &amp; Edge Day (8 月 30 日) – 無料で参加できる 1 日のバーチャルイベントに参加して、ハイブリッドクラウドとエッジコンピューティングの最新のトレンドと新しいテクノロジーに関する講演を聴き、AWS リーダー、お客様、業界アナリストが紹介するベストプラクティスを学習してくだだい。詳細については、 詳細なアジェンダを参照して、今すぐ登録 してください。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ &nbsp;(8 月 30 日) と ヨハネスブルグ &nbsp;(9 月 26 日) の 2 回の対面イベントです。 AWS re:Invent &nbsp; (11 月 27 日～12 月 1 日) – re:Invent シーズンが間もなく始まります。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。&nbsp; 登録が開始されました 。 AWS Community Day &nbsp; – AWS ユーザーグループリーダーが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください 台湾 &nbsp;(8 月 26 日)、 ニュージーランド &nbsp;(9 月 6 日)、 レバノン &nbsp;(9 月 9 日)、 ミュンヘン &nbsp;(9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 チリ (9 月 30 日) で開催されます。すべての AWS Community Day のスケジュールについては、 こちら を参照してください。 CDK Day (9 月 29 日) – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントです (英語とスペイン語)。 詳細については、ウェブサイトを参照してください 。 8月21日週はここまでです。8月28日週に再びアクセスして、新たな Week in Review をぜひお読みください! この記事は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! –&nbsp; Marcia 原文は こちら です。

このブログは 2023 年 7 月 6 日に Gena Gizzi、Jake Wolf、Noor Fairoza、Chris Blackwell によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 AWS 上での Unreal Engine 開発の民主化：エンドユーザコンピューティング（EUC）サービスと高性能な GPU ベースの EC2 インスタンスを用いて はじめに ゲーム業界は日々進化しており、中でもユーザ生成コンテンツ（user-generated content、略して UGC）が変革の先駆けとなっています。プレイヤーは自己表現や報酬（マネタリーリワードとソーシャルリワード）を得るためかつてないほど多くの UGC を作り出しています[1]。しかしゲーム開発とコンテンツ作りは複雑で困難です。学生から専門家まであらゆる人が参画できるようにするため、ゲーム業界では開発を民主化するツールを用意する必要があります。そしてそこから次のような新しい課題が生まれます。どうすればゲーム開発のハードルを下げながらもプレイヤーのクリエイティビティを担保できるでしょうか？どのようにして学習コストを下げ、ハードウェアの制約を取り払い、ゲーム開発のコストを下げることができるでしょうか？ これらの課題に対しゲーム業界では多くの新しい試みがなされました。中でも特筆すべきのは Epic Games と Unreal Engine （UE）です。Unreal Engine はフォトリアルなビジュアルと没入的体験を作り出す世界で最も高度な 3D 制作ツールです。UE が脚光を浴びたのはまずゲーム業界でのことでしたが、今では放送、アニメーション制作、シミュレーションなどの業界でも人気なツールとなっています。Epic Games のフォートナイトも Unreal Engine を利用しています。フォートナイトはプレイヤーに UGC やクリエイティブな体験を提供し、今や1つのソーシャルエクスペリエンスとなってきています。 Epic Games は GDC 2023 で Unreal Editor for Fortnite （UEFN）を発表しました。UEFN はゲームや体験を設計、開発し、フォートナイトに直接公開できる新しい PC アプリケーションです。これによりゲーム開発の学習コストが下がり、プレイヤーは今まで以上に簡単に Unreal Engine の機能を使って UGC の創作ができるようになりました。 一方ハードウェアやコスト面での課題はまだ残っています。ゲーム開発ツールを利用するには往々にして高価な GPU 付きハードウェアが必要です。これらのハードウェアは高価なだけでなく入手に時間がかかり、手軽にスケールアップ/スケールダウンもできません。例としては こちら の Unreal Engine 5 の推奨ハードウェア要件をご覧ください。従業員に最新のハードウェアを購入する予算のない小規模なゲームスタジオや、最新のゲーミング PC とハイエンドな GPU が手に入らないプレイヤーにとって、このようなハードウェア要件は制約になる可能性があります。そこでクラウドが助けになります。クラウド上で UE や UEFN を使う主なメリットはスケーラビリティと柔軟性の向上とコスト削減です。ゲーム開発者やクリエイターは高価な初期費用を心配することなくクラウド上で強力なハードウェアが備わったインスタンスを起動させたり、必要に応じスケールアップ/スケールダウンさせることができます。クラウドを使えば小規模なスタジオでも大きいスタジオと肩を並べることができるようになり、個人開発者もより手軽にコンテンツ制作を始められます。 AWS 上でクラウドベースのゲーム開発をする方法は多くあり、選定の際にはいくつか考慮すべき要素があります。例えば開発者の人数、予算、ユーザペルソナ、所在地、レイテンシ、プレゼンテーション層の要件、カスタマイズ性、セキュリティ要件や特定のユースケースなどが考えられます。Amazon AppStream 2.0、Amazon WorkSpaces、Amazon EC2 は主な選択肢です。本ブログではこれらの選択肢について取り上げ、ご利用のツールにかかわらず（UE、UEFN、またはその他の GPU 要件のあるゲーム開発ツール）、ユースケースに最適なクラウドベースのゲーム開発サービス選定をお手伝いします。 Amazon AppStream 2.0 Amazon AppStream 2.0 はクラウドベースのゲーム開発の選択肢の1つです。AppStream 2.0 はクラウド上でデスクトップライクなアプリケーションストリーミング体験を提供します。ゲーム開発チームはデバイスや場所の制限なしにグラフィック集約型や高性能アプリケーションを利用することができ、時間とコストを節約できます。特に高性能なコンピューティングリソースやグラフィックリソースが必要だが、高価なハードウェアを購入したくないゲーム開発者や 3D モデリングアーティストにとって Amazon AppStream 2.0 は有力な選択肢になるでしょう。そのほか学生や請負業者など特定のアプリケーションを一定期間内だけ利用したいユースケースにおいても AppStream 2.0 は良い選択肢の1つになります。 AppStream 2.0 が良い選択肢だと思いましたらまずはこちらの 入門ガイド または無料 オンラインコース を確認してみましょう。ゲーム開発で利用する場合「 Graphics design streaming instances for image builders 」と「 Graphics design streaming instances for fleets 」の サービスクォータ の上限緩和申請も必要になります。高性能な 4xlarge から始めることを推奨していますが、ユースケースに合ったインスタンスサイズを利用することが大切です。テストやモニタリングを通して適切なインスタンスサイズを見つけましょう。また、AWS 完全初心者の方は AppStream のプロビジョンニングを開始する前に AWS の基礎知識 を学ぶことをおすすめします。 AppStream 2.0 をご利用する上で注意していただきたいのは、AppStream 2.0 のローカルストレージは非永続なため、ユーザはセッションごとにデータを外部の永続化ストレージ（外部の永続化ストレージのオプションは こちら をご参照ください）に保存しないとデータを失うリスクがあるところです。また AppStream と WorkSpaces はどちらもレイトレーシングと Lumen/Nanite をまだサポートしていません。これらのサポートが必要な場合、本ブログで取り上げた選択肢の中で最もカスタマイズ性の高い EC2 の方がユースケースに合う可能性があります。EC2 についてはブログの後半からご確認ください。またブログの最後に AppStream 2.0、WorkSpaces と EC2 の機能比較一覧表もありますので、選定の際ぜひご参照ください。 Amazon WorkSpaces Amazon WorkSpaces はクラウドベースのゲーム開発のもう1つの選択肢です。仮想デスクトップにフルアクセスしたいグラフィックデベロッパーにとって WorkSpaces はいい選択肢になります。WorkSpaces はあらゆるロケーションからクライアント（Windows、MacOS、Linux、その他モバイルデバイスやタブレットなどに対応。詳細は こちら ）を通してアクセスできる仮想デスクトップを提供します。WorkSpaces は必要なツールや開発環境をインストールするようにカスタマイズできるため、特定のソフトウェアや IDE またはツールが必要な開発者にとって役立ちます。WorkSpaces にはデフォルトで永続ストレージが付属されています。また AlwaysOn と AutoStop といった実行モードがあり使っていない時のコスト削減につながります。このように開発者は慣れ親しんできた専用 VDI と似た感覚で WorkSpaces を利用できます。また WorkSpaces は追加の永続ストレージも利用でき、 追加料金なしで WorkDocs のストレージを 50GB 利用 できます。 Amazon WorkSpaces が良い選択肢だと思いましたら、こちらの 入門ガイド を確認して初めての WorkSpace を起動してみましょう。グラフィックスアプリケーションをご利用したい場合、インスタンスタイプは必ず Graphics.g4dn か GraphicsPro.g4dn のどちらかを選ぶようにしましょう。これらのインスタンスタイプは多精度 Turing Tensor Cores および RT Cores を備えた NVIDIA T4 Tensor Core GPU、AWS カスタム第2世代 Intel® Xeon ®スケーラブル （Cascade Lake）プロセッサ、およびローカルデータの高速アクセスが必要なアプリケーションに最適なローカル NVMe ストレージが付属しています。 WorkSpaces は AppStream と同様に AWS リージョンごとのグラフィックスインスタンスの種類とターゲット数の 上限緩和申請 が必要になります。Graphics と GraphicsPro インスタンスは vCPU の数、RAM と NVMe SSD ストレージの容量に違いがありますが GPU スペックは同等です。ご注意いただきたいのは上限緩和申請が通るまで1週間かかることもあるため、利用開始時や大規模なイベントを控えている際は余裕を持って申請するようにしましょう。 より詳しい情報やコストについては Amazon WorkSpaces のウェブサイト をご参照ください。また無料のオンライントレーニングとして WorkSpaces Primer と WorkSpaces Deep Dive も提供しています。WorkSpaces は AWS マネジメントコンソール からご利用いただけます。 Amazon EC2 Amazon EC2 はクラウド上のゲーム開発の選択肢の中で最もカスタマイズ性の高いものです。Amazon EC2 は事実上特殊要件のあるものも含むすべてのワークロードに対応できるセキュアでサイズ変更可能なコンピューティングリソースを提供します。ゲームスタジオは EC2 を使用して独自のクラウドベース仮想ワークステーションソリューションを構築することができます。これはインフラストラクチャをより細かく制御したい大きめの開発チームにとって特に有用です。また Amazon EC2 はゲームのワークロードに使用可能なインスタンスタイプを幅広く提供しています。例えば Amazon EC2 でクラウドベースのゲーム開発をする場合 G5 インスタンス がおすすめです。G5 は高性能な GPU ベースインスタンスでグラフィック集約型のワークロードに最適です。強力な GPU 以外にも EC2 のカスタマイズ性は非常に高く、高性能なネットワーキングとストレージもご利用可能です。これにより EC2 は 3D モデリング、アニメーション、レンダリングといったゲーム開発タスクにとっても理想的なソリューションになります。 Amazon EC2 を利用する場合、マネージドサービスである Amazon AppStream と Amazon WorkSpaces より多くのインフラストラクチャ管理作業が発生します。EC2 インスタンスのプロビジョニングとオーケストレーションを簡略化するために Amazon Machine Images（AMI）、AWS Marketplace、AWS CloudFormation と AWS Control Tower などのツールが存在します。例えば AWS Marketplace から Unreal Engine 5 AMI を起動させればすぐに開発に着手することができます。ただしチームの規模が小さく時間もあまりない場合、Amazon EC2 を使うとインスタンス、プレゼンテーションレイヤー、インフラストラクチャのスケーリング、パッチあてなどの管理作業が発生することを考慮に入れていただきたいです。 クラウドベースのゲーム開発において最大限の制御とカスタマイズ性が必要な場合、Amazon EC2 は最適な選択肢です。 Amazon EC2 の開始方法 を確認し初めてのインスタンスを立ち上げてみましょう。その後こちらの Game Production in the Cloud Pipeline を参照してみると良いかもしれません。こちらのリポジトリには仮想ワークステーションのデプロイとセットアップ手順が含まれています。 機能比較 ご自身のワークロードにとってどの選択肢が最適か決めかねていますか？それとも他に特別な要件があるでしょうか？こちらの詳細機能比較一覧表をぜひご参考にしてください（表の情報は 2023 年 7 月 6 日オリジナルのブログ記事公開時までの情報に基づいています）！ Appstream Workspaces EC2 永続デスクトップ &nbsp; X X 選択式永続性 X &nbsp; &nbsp; GPU インスタンス (G4) X X X GPU インスタンス (G5) &nbsp; &nbsp; X サポートされているリージョン数 15 13 全リージョン対応 ブラウザからのアクセス X X &nbsp; シッククライアントからのアクセス Windows のみ X 任意 タブレット入力サポート X X X – via NICE DCV ゲーミングコントローラサポート &nbsp; &nbsp; X – via NICE DCV Relative Offset X &nbsp; &nbsp; OS サポート Windows 2016, 2019 Windows 10 Windows, BYOL, Linux, Marketplace AMIs プロトコル NICE DCV PCOIP NICE DCV (推奨), Teradici, Parsec 休眠モード X X 手動 料金体系 時間単位で従量課金 時間単位、月単位で従量課金 時間単位のオンデマンド課金、セービングプラン、リザーブドインスタンス（RI） 認証方法 Microsoft Active Directory, AWS Managed Microsoft AD, AppStream 2.0 User Pools, SAML 2.0 Integration, Streaming URL Creation Microsoft Active Directory, AWS Managed Microsoft AD, SAML 2.0 Integration, AD Connector 任意 マルチモニターサポート 解像度4Kの場合最大2枚、2Kの場合最大4枚対応 GraphicsProの場合3840×2160解像度で最大2枚、1920×1200で最大4枚； Graphicsの場合2560×1600解像度で最大1枚 カスタム可能 まとめ UGC の出現によりゲーム業界は目まぐるしく変化し続けており、すべての人が参画できるようにゲーム開発を民主化することが重要です。Epic Games の Unreal Editor for Fortnite はゲーム開発の民主化への一歩です。UE、UEFN あるいはその他の開発ツールなどツールに関わらず、ゲーム開発ではハードウェア面とコスト面の課題が依然として存在します。これは小さいゲーム会社や個人クリエイターにとっては制約になる可能性があります。AWS は Amazon WorkSpaces、Amazon AppStream と Amazon EC2 などいくつかのクラウドベースのソリューションを提供しています。これらのソリューションは、ゲーム開発上のハードウェア面とコスト面の課題に対処しゲーム開発をよりユーザ重視にすることで、拡張性とコスト効率の向上をお手伝いします。 リソース こちらのリンクを辿ってもっと学習してみましょう！ AWS for Games https://aws.amazon.com/jp/gametech/?nc1=h_ls AWS クラウドゲーム開発 https://aws.amazon.com/jp/gametech/remote-game-production/ はじめての Unreal Engine 5 https://dev.epicgames.com/community/learning/courses/nE0/unreal-engine-5/4VqE/unreal-engine-5 はじめての UEFN https://dev.epicgames.com/community/learning/courses/9DG/fortnite-uefn/2bVB/fortnite-uefn AWS 入門ガイド – https://aws.amazon.com/appstream2/getting-started/ Setup sample applications – https://docs.aws.amazon.com/appstream2/latest/developerguide/getting-started.html Build multiplayer games on cloud – https://aws.amazon.com/blogs/gametech/online-multiplayer-amazon-gamelift-aws-serverless/ Unreal Engine 5 Marketplace AMI – https://aws.amazon.com/marketplace/pp/prodview-iu7szlwdt5clg [1] https://www.gamedeveloper.com/blogs/how-do-different-kinds-of-ugc-satisfy-players-#close-modal 翻訳はソリューションアーキテクトのBaixiao Linが担当しました。

ブルー/グリーンデプロイは、新しいコードの導入に伴うダウンタイムやリスクを最小限に抑えることを目的として、ソフトウェア開発において広く用いられているデプロイメント手法です。このデプロイ戦略は、2つの同一環境（ブルーおよびグリーン）を並行稼働させ、必要に応じてそれぞれの環境間でトラフィックを誘導します。この手法はエンドユーザーに悪影響を及ぼさず、途切れることなく新しい機能や更新をデリバリーできます。必要であれば簡単にロールバックできます。アジリティ、継続的デリバリー、信頼性のあるソフトウェアデリバリーを重視するチームにとって、ブルー/グリーンデプロイは重要なプラクティスです。 この記事では、 Amazon CloudFront の機能である継続的デプロイを活用できるさまざまなユースケースについて議論をします。この機能は、ブルー/グリーンや Canary のテクニックを用いて、動作中のコンテンツ配信ネットワーク（CDN）ディストリビューションをデプロイするためのマネージドな方法を提供しています。これにより、ドメイン全体に渡って変更を加える際のリスクを大幅に低減します。この機能を使用すると、全てのエッジロケーションに変更を展開する前に、本番トラフィックの一部を更新した構成に向けて誘導することで、変更の検証を行えます。 一般的なユースケース CloudFront の継続的デプロイは、ユーザーエクスペリエンスを妨げることなく、新機能、バグ修正、その他の変更をアプリケーションにリリースできる効果的な手法です。この記事では、いくつかの一般的なユースケースについて議論します。 クリティカルなシステムの更新 ビジネスクリティカルなアプリケーションとって、ダウンタイムやユーザーエクスペリエンスへの悪影響を最小限に抑えることは重要です。CloudFront の継続的デプロイを使用すると、既存のバージョンと並行して CDN コードの新しいバージョンをデプロイし、テストを行い、ダウンタイムなしで新しいバージョンに切り替えることができます。この機能により、ゼロダウンタイムでのデプロイや簡単なロールバックが可能となり、古い CloudFront ディストリビューションから新しいディストリビューションへのシームレスな移行を実現します。 A/B テスト CloudFront の継続的デプロイは、ソフトウェア開発における実験に利用することもできます。これは、CloudFront のお客様が自身のユーザーベースを用いて試行できる実験の数を増やし、ビジネスメトリクスを収集して情報に基づいた意思決定を行い、これを繰り返すことで、プロダクトの開発ライフサイクルを短縮できます。 速いロールバック 従来のデプロイメント手法では、変更のロールバックは困難で時間のかかるプロセスとなることがあります。しかし、CloudFront の継続的デプロイでは、もし他のディストリビューションの新しいコードに問題が発生した場合、プライマリディストリビューションのコードに簡単に切り戻すことができます。これにより、デプロイ中に発生しうる様々な問題やバグの影響をユーザーが受けることはありません。 新機能のロールアウト 新機能のローンチでは、CloudFront の継続的デプロイは間違った CDN コードをデプロイするリスクを最小化する手助けをしてくれます。ユーザーの少数のグループに対して更新をリリースすることで、全体のユーザーベースにリリースする前に、開発者はその更新が正しく機能しているかを確認できます。これは、問題の拡大を防ぎ、ユーザーエクスペリエンスへの悪影響を最小限に抑えることができます。 ステージング環境でのテスト コードベースへのあらゆる変更は、まずステージングディストリビューションにデプロイされます。これにより、テストチームは新しい変更に対して包括的なテストを行えます。テストが完了すると、変更内容をステージングディストリビューションから本番ディストリビューションにコピーできます。もしくは、アクティブな環境からアイドルな環境にトラフィックをリダイレクトして、アイドルな環境を新しい本番環境とすることもできます。このアプローチでは、本番環境に展開する前の新しいコードベースに対して、徹底的なテストや検証を実施できます。テスト中に発生したあらゆる問題は、アイドル環境で対処や解決がなされ、本番環境への影響を最小限に抑えることができます。 はじめに CloudFront の継続的デプロイをセットアップする ために、CloudFront マネジメントコンソール、 AWS CloudFormation 、 AWS SDK 、または AWS コマンドラインインターフェイス(AWS CLI) を使用して、既存のディストリビューションの新しいステージングディストリビューションの作成から始めることができます。新しいステージングディストリビューションが作成されると、希望する変更を適用できるようになり、重みベースやヘッダーベースのようなステージングポリシーを設定して、新しいディストリビューションに対するトラフィックを段階的に増やせます。 ステージングディストリビューションが期待通りに動作していることを検証した後、変更内容をメインのディストリビューションにコピーするか、このディストリビューションをプライマリディストリビューションへと昇格させることができます。このプロセスは変更のシームレスかつコントロールされたデプロイを可能とし、エンドユーザーへの影響を最小限に抑えることができます。 ソリューションの概要 サンプルソリューションは、１つの Amazon Simple Storage Service(Amazon S3) オリジンの CloudFront ディストリビューションをデプロイします。また、プライマリディストリビューションへ変更を安全にテストしリリースするために、ステージングディストリビューションを用いた昇格の設定を行えます。推奨されるソリューションとしては、 CloudFront ディストリビューションの設定変更のために、継続的デプロイを有効にした AWS Cloud Development Kit（AWS CDK）パイプライン を実装することです。 1. AWS CDK Pipeline は、プライマリディストリビューション、ステージングディストリビューション、Amazon S3 オリジン、およびデプロイメントポリシーの作成を手助けします。 2. AWS Step Functions ワークフローは、以下のアクションを実行する CloudFront API の呼び出しをオーケストレーションする責務があります。 a. 継続的デプロイポリシーを有効化し、プライマリディストリビューションに紐づける b. 最新のステージングの設定でプライマリディストリビューションを更新する このソリューションの一部では、Amazon S3 オリジンを持つ CloudFront ディストリビューションのデプロイと、変更のテストやプライマリディストリビューションへの昇格を目的としたステージングディストリビューションの設定を行います。 リファレンスソリューション リファレンスソリューションの GitHub リポジトリはこちら です。 実装の詳細 ステップバイステップで実装の詳細を示すと以下のようになります。 1. cdk deploy コマンドによるパイプラインスタックの作成 2. プライマリディストリビューションに対して変更をリリース a. プライマリディストリビューションのスタックを更新して、ディストリビューションの設定を変更します。変更内容をコードリポジトリにコミットします。 b. リポジトリへのコードのコミットがパイプラインをトリガーします。 c. パイプラインはプライマリディストリビューションに対して変更のデプロイを行う一連のステージを実行します。 3. CloudFront の継続的デプロイを使用した継続的デプロイのワークフロー a. プライマリディストリビューションがデプロイされて有効になると、パイプラインを継続的デプロイモードに更新することで、ディストリビューションへのあらゆる変更がブルー/グリーンデプロイもしくは Canary デプロイを使用してリリースされます。 b. 継続的デプロイはパイプラインコード内のフラグを更新することで有効化できます。これはステージングディストリビューションを使用して変更を昇格させます。 c. パイプラインでは SingleHeader トラフィック設定またはブルー/グリーンデプロイを使用します。パイプラインコード内のフラグを更新することで SingleWeight トラフィック設定を使用するように更新することもできます。 d. SingleWeight を選択した場合、リクエストを同じ CloudFront ディストリビューションで処理しながらユーザーに同じ体験を提供しつづけるための session stickiness の設定を選択できます。 e. ディストリビューションの設定に変更を加え、リポジトリにコミットします。 f. リポジトリへの変更のコミットがパイプラインをトリガーします。変更を反映したステージングディストリビューションと、ヘッダーベースまたはウェイトベースによるトラフィックの振り分けを含んだデプロイメントポリシーが作成されます。 g. Step Functions をパイプラインのステップとして実行することにより、継続的デプロイポリシーのプライマリディストリビューションへのアタッチまたはリンクが行われます。 ディストリビューションにデプロイメントポリシーをアタッチするため、Step Functions はデプロイメントポリシーを有効にし、プライマリディストリビューションを更新します。 h. パイプラインは、ステージングディストリビューションでの変更をプライマリディストリビューションに昇格する前に、手動での承認を待ちます。 i. 検証した後、パイプラインではステージングの変更を含んだプライマリディストリビューションへの更新を承認する必要があります。これにより、変更がリリースされます。変更をリリースするために、パイプラインは Step Functions を実行します。 CloudFront API を呼び出し、プライマリディストリビューションをステージングの設定で更新します。 まとめ CloudFront の継続的デプロイは、最小限のリスクと最大の効率性でソフトウェアの更新をリリースするための強力なツールです。CloudFront の継続的デプロイが利用可能になったことで、ソフトウェアリリースの速度と信頼性をさらに向上させることができます。CloudFront のエッジサーバーのグローバルネットワークを活用することで、デプロイメントが世界中のユーザーに素早くかつ簡単に展開され、一貫したユーザーエクスペリエンスを保ち、ダウンタイムを最小限に抑えるられるようになりました。 本記事は「 Achieving Zero-downtime deployments with Amazon CloudFront using blue/green continuous deployments 」の翻訳となります。 このブログの翻訳はプロフェッショナルサービスの 鈴木（隆） が担当しました。

小売業では常に、実店舗へのアクセスや人通りを増やすことを目指しています。そのためには、潜在顧客が最も便利な店舗を正確に特定できなければなりません。最もアクセスしやすい店舗に関する情報を、便利な 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 小規模 &lt; 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]: &lt;Your Store Finder "Core" Amazon CloudFormation stack name&gt; AWS Region [eu-west-1]: &lt;Your AWS Region&gt; Parameter storeFinderAmplifySubdomain [demo]: &lt;Amplify environment subdomain name used in URL&gt; この例では、スタック名を 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=&lt;Your AWS Region&gt; VITE_AMAZON_COGNITO_IDENTITY_POOL_NAME=&lt;storeFinderAmazonCognitoIdentityPoolName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_COGNITO_USER_POOL_NAME=&lt;storeFinderAmazonCognitoUserPoolName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_COGNITO_USER_POOL_CLIENT_NAME=&lt;storeFinderAmazonCognitoUserPoolClientName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_LOCATION_SERVICE_MAP=&lt;storeFinderAmazonLocationServiceMapName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_LOCATION_SERVICE_PLACES_INDEX=&lt;storeFinderAmazonLocationServicePlaceIndexName from the Store Finder "Core" Amazon CloudFormation stack output&gt; 店舗検索 – 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=&lt;storeFinderAPIGatewayEndpoint from the Store Finder "API1" Amazon CloudFormation stack output&gt; 注：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]: &lt;Your Store Finder "API2" Amazon CloudFormation stack name&gt; AWS Region [eu-west-1]: &lt;Your AWS Region&gt; Parameter storeFinderCoreCloudFormationStackName []: &lt;Name of the Store Finder "Core" Amazon CloudFormation stack&gt; Parameter storeFinderAuroraDBMasterUserName [admin_user] &lt;Name of the PostgreSQL admin user account&gt; Parameter storeFinderDatabaseTableName [tbl_postoffices]: &lt;Name of table to be used in PostgreSQL database&gt; この例では、スタック名を 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=&lt;storeFinderAPIGatewayEndpoint from Store Finder "API2" Amazon CloudFormation Stack output&gt; 注：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&amp;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 のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。 &nbsp; &nbsp; 尾原 颯 (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 窪田が担当しました。原文は こちら です。