みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2023 年 7 月 27 日に「第三十二回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回のテーマは「Data Analytics」ということで、株式会社 E-Grant の堀江 氏、クラスメソッド株式会社の石川 氏、株式会社ジェーエムシステムズの植木 氏にご登壇いただきました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 AWS のメンバーからは AWS SDK for pandas に関するセッションをお届けし、株式会社 E-Grant の堀江 氏、クラスメソッド株式会社の石川 氏、株式会社ジェーエムシステムズの植木 氏からは、AWS を活用した Data Analytics の事例についてご紹介いただきました。合計 1 時間半の中で盛りだくさんの内容でお送りしました。 記事の中に資料や動画のリンクがありますので、見逃してしまった方はそちらから御覧ください。 アジェンダ 今月のお勧め 5 分間アップデート (5 分) スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 今月の AWS のサービスアップデートを 5 分でご紹介。たくさんのアップデートの中から 4 つをピックアップしました。 AWS が Amazon Aurora MySQL と Amazon Redshift のゼロ ETL 統合 (パ ブリックプレビュー) を発表 AWS Lambda now detects and stops recursive loops in Lambda functions AWS Fargate enables faster container startup using Seekable OCI Llama 2 foundation models from Meta now available in Amazon SageMaker JumpStart AWS の新着情報については  公式ページ  のほか、 週間 AWS  を合わせてご覧いただくのがオススメです！ プロダクト成長のためのデータの可視化（15 分） スピーカー：株式会社 E-Grant CTO 堀江 勉 氏 株式会社 E-Grant では「うちでのこづち」という CRM システムを提供しております。プロダクトは作ってからがスタート。どんな情報に価値があるのか、必要になるかはそれぞれ。そのためにデータを集約することと、ログの解析や可視化に取り組んでおります。本セミナーでは、どのような情報を可視化し、どのようにプロダクトの成長に活かしているか、Amazon Athena や Amazon QuickSight などの具体的な事例を交えてお話しいたします。 AWS SDK for pandas で手軽に実現する！pandas と AWS のデータ分析サービス統合（15 分） スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 福本 健亮 AWS SDK for pandas をご存知でしょうか？元々は AWS Data Wrangler という名前で提供されていましたが、現在は名前が変わりつつも引き続き同じ機能が提供されています。pandas を普段お使いの方であれば、慣れた操作感で Amazon Athena や AWS Glue をはじめとした多くの AWS データ分析サービスと接続し、ETL などの処理が行えます。本セッションでは、普段の業務でお役立ていただける AWS SDK for pandas の基本に加えてデモも用意していますので、是非ご覧ください！ Amazon Athena (Iceberg) x dbt ではじめるデータ分析！（15 分） スピーカー：クラスメソッド株式会社 プロトタイプソリューションアーキテクト 石川 覚 氏 昨年の re:Invent2022 で発表された Amazon Athena Verion 3 のフォーマットタイプ「Iceberg」は、パフォーマンス改善、Merge（UPSERT）のサポート、ビューのサポート、VACUUM のフラグメントデータファイルの削除の改善など正常進化を遂げ、dbt (data build tools) が必要とする機能が網羅されました。一方、コミュニティベースで開発が進められている dbt-athena パッケージの Version1.5 では、table materialization や incremental models のサポートが開始され、dbt の強みを生かしたデータ変換が可能になりました。この強力な組み合わせによるエレガントなデータトランスフォームをご紹介致します。 AWS Glue + Amazon QuickSight でクイックに成果を出す需要予測（15 分） スピーカー：株式会社ジェーエムエーシステムズ アドバンストテクノロジー部 植木 将也 氏 「需要予測」は DX / データ分析でも根強い人気のテーマです。一方で精度、複雑さ、属人性、データ不足などがシステム化の障壁となるケースも多々見受けられます。本セッションでは AWS Glue や Amazon QuickSight などを組み合わせたデータ分析事例を通じ、実際に直面した課題に対する具体的な解決方法をご紹介するとともに、クイック ＆ ライトな仕組みから段階的に成果を刈り取る勘所をお伝えします。 当日の様子 当日の内容を抜粋してご紹介します。 プロダクト成長のためのデータの可視化 [ 資料 、 動画 ] 最初のセッションは株式会社 E-Grant の 堀江 氏より、Amazon Athena や Amazon QuickSight を使ったデータの収集と可視化の事例について共有いただきました。CRM システムとして「うちでのこずち」を提供する株式会社 E-Grant 様は、サービスの成功をお客様の成長に繋げるという付加価値の向上という観点からも、データの収集と分析に取り組まれています。具体的な実例として、Apache や Nginx のログ、サービス独自のアクセスログ、DB から抽出したデータの可視化についてご紹介いただきました。また実際のデータ活用の事例として、どういったデータを活用し、どういったアクションに繋げているか、という観点で、いくつかのケースを紹介いただきました。 プロダクトの成長のためのデータの可視化に取り組むうえでの具体的な事例について紹介されており、データをもとにプロダクトの成長を加速させたいと考えている方には、ぜひ御覧いただきたい内容です。 AWS SDK for pandas で手軽に実現する！pandas と AWS のデータ分析サービス統合 [ 資料 、 動画 ] 2 つ目のセッションでは、ソリューションアーキテクトの福本より、AWS SDK for pandas について概要のご紹介とデモンストレーションをおこないました。AWS SDK for pandas は、AWS のデータ分析サービスと Pandas DataFrame 間のやり取りが簡単に行える Python のライブラリです。今回の発表では、ローカルとクラウドでデータフレームをやり取りしたり、Amazon Athena にクエリを投げてローカルで結果を受け取る、といったユースケースでのデモンストレーションを実施いたしました。 pandas を普段お使いでクラウドでのスケーラブルな環境を手に入れたいと考えている方にはオススメのセッションですので、ぜひ動画をご覧ください。 Amazon Athena (Iceberg) x dbt ではじめるデータ分析！ [ 資料 、 動画 ] 3 つ目のセッションでは、クラスメソッド株式会社 石川 氏より dbt-template ソリューションの Amazon Athena 対応で得られた技術調査の結果と、テーブルフォーマットである Apache Iceberg と dbt 対応について共有いただきました。従来のデータレイクの技術課題と Apache Iceberg による解決策の詳細や、dbt の特徴、Amazon Athena (Iceberg) と dbt を組み合わせて利用した際の課題や代替案についても共有いただきました。 実際に検証いただき得られた課題と代替案についても詳しく説明して頂いております。Apache Iceberg や dbt に興味がある方はぜひ動画をご覧ください！ AWS Glue + Amazon QuickSight でクイックに成果を出す需要予測 [ 資料 、 動画 ] 最後のセッションは、株式会社ジェーエムエーシステムズ 植木 氏より、データ分析でも根強い人気のテーマの一つである「需要予測」にフォーカスを当てて発表いただきました。需要予測の目的や現状の課題に加えて、業務上の課題やその対策について共有いただきました。AWS Glue や Amazon QuickSight を活用し、短期間で IT 部門以外の社員でも分析が可能な環境を構築した事例について紹介いただきました。 実際に直面した課題に対して、AWS を活用した具体的な解決手法について紹介いただいております。DX やデータ分析といったテーマで課題を感じている方はぜひ動画をご覧ください！ 次回予告 次回は「Security」編です。 ゲストスピーカーとして、弥生株式会社の峯岸 氏、HENNGE 株式会社の土居 氏、穂坂 氏をお招きしまして、マルチアカウント環境におけるセキュリティ強化の事例や AWS Control Tower Account Factory for Terraform の事例について発表いただきます。 次回も多くの方々のご参加を心よりお待ちしております！ 2023 年 4 月以降に開催予定の『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みを一括でできるようになりました！毎月申し込みする必要はなくなります。また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 三十三回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Security 編- 開催日時 2023 年 8 月 31 日（木）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 AWS 初心者が取り組んだセキュリティ強化の 2 年間とこれから スピーカー： 弥生株式会社 開発本部 情報システム部 インフラ/CCoE 峯岸 純也 氏 16:25 – 16:40 AWS Gateway Load Balancerを用いた仮想アプライアンスの活用 スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 長屋 和真 16:40 – 16:45 Q&A 16:45 – 17:00 Amazon GuardDuty 2023 夏 スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 吉田 裕貴 17:00 – 17:15 AFT で AWS アカウントをばら撒いてみた スピーカー：HENNGE株式会社 Cloud Product Development Division 土居 俊也 氏 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション 次回も多くの方々のご参加を心よりお待ちしております！ 特別回開催予告 また通常開催とは別の特別回として「AWS re:Inforce デモ祭り」を開催します。 2023 年 6 月に開催されたクラウドセキュリティ、コンプライアンスに特化したカンファレンスである AWS re:Inforce で発表された新サービス、新機能の内容についてデモ中心で Dive Deep します。 下記リンクから参加の申し込みをお願いいたします。 アップデート紹介とちょっぴり DiveDeep する AWS の時間 – AWS re:Inforce デモ祭り 開催日時 2023 年 9 月 6 日（水）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！ スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 柴田 龍平 16:25 – 16:40 Amazon CodeGuru Security の紹介 スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 江口 昌宏 16:40 – 16:45 Q&A 16:45 – 17:00 踏み台サーバーなしでプライベートサブネットのインスタンスに SSH？EC2 Instance Connect Endpoint を試してみる！ スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 山崎 宏紀 17:00 – 17:15 Amazon Inspector SBOM Export ではじめるソフトウェアサプライチェーンセキュリティ スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション こちらについても、多くの方々のご参加を心よりお待ちしております！ このブログの著者 後藤 健汰 (Goto Kenta) ソリューションアーキテクトとして ISV/SaaS 領域のお客様の技術支援を行っております。好きなサービスは Amazon EKS です。夢は本場フィンランドのサウナでバルト海にちょっぴり Dive Deep することです。

このブログは 2023 年 8 月 1 日に Dilip Kumar によって投稿された Empowering your workforce with Amazon WorkSpaces services and Microsoft 365 を翻訳したものです。 何万ものお客様が、エンドユーザーコンピューティングサービスとして、ユーザーが仕事をするために必要なすべてのツールを備えた、安全でスケーラブルかつコスト効率の高い仮想デスクトップサービスである Amazon WorkSpaces サービスを利用しています。お客様は WorkSpaces 上で、倉庫作業員を誘導する単一目的の Web アプリケーションから、メディアやエンターテイメントなどの GPU ベースの複雑なレンダリングワークロードまで、あらゆる種類のアプリケーションを使用しています。多くのお客様は、Microsoft 365 のような Office アプリケーションをハイブリッドユーザーやリモートユーザーに提供するためのシンプルかつ費用対効果の高いメカニズムを含むソリューションを必要としており、同時に企業データや知的財産のセキュリティ体制を改善する必要があると述べています。 2023年8月1日から、 AWS エンドユーザーコンピューティング のお客様は、 Amazon WorkSpaces サービス上で BYOL (Bring Your Own License) モデルを通じて Microsoft 365 ライセンスを使用できるようになります。ナレッジワーカーに最適な WorkSpaces の仮想デスクトップは、Microsoft Windows、Amazon Linux 2、および Ubuntu Desktop オペレーティングシステムをサポートし、さまざまなインスタンス構成で利用できます。これらのサービスは、高い安全性と信頼性を誇る AWS クラウド上で実行され、自動スケーリングと従量課金制により、利用した分だけ料金を支払うことができます。また、ユーザーは、いつでも、どこからでも、サポートされているデバイスから、仮想デスクトップとアプリケーションに安全にアクセスできます。Microsoft 365 は、Microsoft Word、Microsoft Excel、Microsoft PowerPoint、Microsoft Outlook などの一般的な Office アプリケーションにより、ソリューションのパワーをさらに高めます。含まれるアプリケーションは、 Microsoft 365 のライセンスプラン によって異なります。Microsoft は、Microsoft E3、E5、A3、A5、Business Premiumライセンスを WorkSpaces サービス上で使用することを許可しています。また、新しいライセンス条件では、Microsoft Project とMicrosoft Visio のライセンスを WorkSpaces サービスに持ち込むこともできます。 Microsoft 365 の Office アプリケーションを WorkSpaces サービス上で実行するために Microsoft 365 のライセンスを使用したいお客様には、追加料金やコストは発生せず、特別なセットアップやイメージ管理も必要ありません。お客様は既存のツールを使用して、Microsoft 365 を WorkSpaces サービスに導入することができます。また、サービスプロバイダー向けライセンスプログラム (SPLA) に基づき、WorkSpaces サービス上で実行する Microsoft Office Professional を AWS から引き続き購入することも可能です。 AWS エンドユーザーコンピューティングは、仮想デスクトップ体験の提供において 10 年以上にわたって高い評価を得ており、お客様は、Microsoft 365 アプリケーションを含め、組織に最適なソフトウェアを柔軟に選択することができます。 翻訳はソリューションアーキテクトの平田が担当しました。原文は こちら です。

(編集者注: 最近のトップニュースや発表、見逃せない今後のイベントといった多様な情報をよりよく反映するために、8月8日、この定期的な週次投稿のタイトルを AWS Week in Review から AWS Weekly Roundup に変更します。) デベロッパーアドボケイトにとってスタジオでの動画撮影は新しい経験で、慣れるまでに少し時間がかかりました。 7月31日週、AWS ロンドンスタジオのチームメイト数名と一緒に一連の動画を撮影しました。このビデオは、Build On AWS YouTube チャンネルで公開される予定です。Build On AWS は、アジリティを高め、イノベーションのスピードをアップしたいと考えている実践的で技術的な AWS クラウドビルダーを対象としています。このチャンネルでは、デベロッパーがデベロッパー向けに設計した動的で高品質のコンテンツが提供されています。 このチャンネルの詳細については、次の動画を参照してください。新しいコンテンツが公開されるときを見逃さないよう、チェックしてサブスクリプションを検討してください。 では、AWS の最新情報です。先週は AWS に関する多くのニュースがあったので、皆さんにお伝えすべきお知らせと今後予定されているイベントをまとめました。それでは、始めましょう。 7月31日週のリリース 見逃された可能性のある7月31日週のリリースをいくつかご紹介します。 Microsoft 365 Apps for enterprise が Amazon WorkSpaces サービスで利用できるようになりました – Amazon WorkSpaces は、AWS クラウド内のフルマネージド型のセキュアで信頼性の高い仮想デスクトップです。Amazon WorkSpaces では、使用したインフラストラクチャに対してのみの支払いで IT のアジリティを高めてユーザーエクスペリエンスを最大化できます。Amazon WorkSpaces で Microsoft 365 Apps for enterprise が利用可能になったことが発表されました。お客様ご自身の Microsoft 365 ライセンスを使用して、追加費用なしでアプリケーションをアクティベートし、Amazon WorkSpaces サービス上で Microsoft 365 Apps for enterprise を実行できます (Microsoft のライセンス要件を満たしている場合)。 AWS イスラエル (テルアビブ) リージョンの提供開始 – イスラエルにデータを安全に保存しながら、近隣のユーザーにさらに低いレイテンシーでサービスを提供できるようになりました。先週、イスラエルに位置するデータセンターのアプリケーションの実行とユーザーへのサービス提供を目的とした追加オプションをお客様に提供するためにテルアビブ リージョンがローンチされました。 Amazon Connect のローンチ – AWS のお客様とお客様の顧客のエンゲージメントを大きく変えている Amazon Connect は、 私が最もお伝えしたい AWS のサービス の 1 つです。いくつか例を挙げると、先週、Amazon Connect は、 シフト期間に基づくアクティビティの自動スケジュール 、 カスタムフローブロックタイトル 、 UI からのフローのアーカイブと削除 を発表しました。 AWS のその他のニュース 以下では、他の注目すべきニュースやブログ記事をいくつかご紹介します。 Amazon CloudWatch Internet Monitor でサポートされるヘルスイベント向けのカスタマイズ可能なしきい値 – この発表の前までは、ヘルスイベントを呼び出すための全体的な可用性とパフォーマンススコアのデフォルトのしきい値は 95% でした。今回の発表により、エンドユーザーと AWS でホストされているアプリケーションとの間のインターネット向けトラフィックについて、ヘルスイベントを呼び出すタイミングのしきい値をカスタマイズできるようになりました。 Amazon S3 バケットの AWS Backup パフォーマンスが向上 – 3 億以上のオブジェクトを含むバケットのバックアップ速度が最大 10 倍向上したため、Amazon S3 の初期バックアップワークフローをスピードアップするとともに、30 億以上のオブジェクトを含むバケットをバックアップできるようになりました。このパフォーマンス向上は、Amazon S3 の AWS Backup サポートが利用可能なすべてのリージョンで自動的に有効になります。追加コストは必要ありません。 AWS のオープンソースに関するニュースや最新情報については、オープンソースプロジェクト、記事、イベントなどに関する最新情報をお届けするために同僚の Ricardo Sueiras が厳選した情報が記載されている 最新のニュースレター をご覧ください。 AWS のお知らせの完全なリストについては、「 AWS の最新情報 」ページをご覧ください。 今後の AWS イベント 以下のイベントが近日開催予定です。 AWS Storage Day (8 月 9 日) – このイベントでは、ストレージに関する現在の意思決定で AI/ML の準備をする方法、オンプレミスとクラウドデータのストレージコストを最適化して限られた予算で大きな成果を出す方法に加えて、ランサムウェアからの保護に役立つ復旧計画など、総合的なデータ保護を組織に提供する方法を学習できる 1 日のイベントです。 詳細情報と登録はこちらです 。 AWS Summit メキシコシティ (8 月 30 日) – サミットにサインアップ すると、AWS について学びながら、志を同じくする他の人々とつながってコラボレーションできます。 AWS Community Day (8 月 12 日、19 日) – 各地のコミュニティリーダーがイベントロジスティクスとコンテンツの計画、準備、提供を行うコミュニティ主催のカンファレンスに参加してください: コロンビア (8 月 12 日)、 西アフリカ (8 月 19 日). P.S.私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をお聞かせください。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 – Veliswa 原文は こちら です。

このブログは 2023 年 8 月 9 日に Darryl Diosomito（Senior Solution Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 AWS では、お客様がクラウドの IT 運用を実行することを選択した場合に、最高の経験と、パフォーマンス、コストが得られると考えています。しかしながら、様々な理由によってマルチクラウド環境で IT 運用を実行されているお客様もいます。たとえば、お客様が別のクラウドプロバイダーで運営されている会社を買収した場合や、データが AWS に保管されている必要がある特定の AWS データ処理サービスを利用する場合などです。これらのお客様は、アプリケーションとクラウドインフラストラクチャ運用が更に複雑になる可能性があります。ITリソースのプロビジョニングや、管理、統制、アプリケーションの状態監視、複数の場所に保存されているデータの収集と分析に、複数プロバイダーのソリューションを使用することを考慮する必要があります。これらの課題を抱えるお客様を支援するために、AWS はクラウドサービスを拡張して、お客様がハイブリッドおよびマルチクラウドのインフラストラクチャとアプリケーションを合理化し、管理、統制ができるようにしています。そのサービスの 1 つが AWS DataSync（DataSync） です。 DataSync は、様々なクラウドプロバイダー間で データが移動できるようになりました 。DataSync を使用すると、他のクラウドの Amazon S3 互換ストレージ と Amazon S3 などの AWS Storage サービス間でオブジェクトデータを大規模に移動できます。Google Cloud Storage や、Azure Files、Azure Blob Storage のサポートに加えて、DataSync は DigitalOcean Spaces や、Wasabi Cloud Storage、Backblaze B2 Cloud Storage、Cloudflare R2 Storage、Oracle Cloud Storage 間とのデータコピーをサポートするようになりました。 この記事では、マルチクラウドでデータ転送を開始するための DataSync の設定に関する一般的な概要を説明します。DataSync が特定のエンドポイントを介して様々なクラウドに接続する方法について説明し、サポートされている各クラウドの違いの概要を説明します。DataSync を使用すると、ビジネスワークフローの一環として、他のクラウドから AWS へのデータ移行や、AWS でのデータアーカイブ、他のクラウド間とのデータ移動を迅速かつ簡素化することができます。AWS にデータを保管することで、最も重要なアプリケーションに対して AWS の比類ない経験と、成熟度、信頼性、セキュリティ、パフォーマンスを活用することができます。 仕組み DataSync は、 DataSync エージェント を使用して他のクラウドとの間でデータを転送します。DataSync エージェントは、DigitalOcean Spaces と、Wasabi Cloud Storage、Backblaze B2 Cloud Storage、Cloudflare R2 Storage、Oracle Cloud Storage に加えて Google Cloud Storage、Azure Blob Storage に接続する Amazon EC2 インスタンスにデプロイできます。エージェントを Google Cloud または Azure にデプロイすると、ネットワークで圧縮の利点が得られるため送信コストが削減できます。 はじめに まず、 DataSync エージェントをデプロイして有効化 します。アクティベーションプロセスにより、エージェントが AWS アカウントおよびリージョンに関連付けられます。Amazon EC2 ベースのエージェントの場合、 プライベート VPC エンドポイント を使用してエージェントを有効化することをお勧めします。 DataSync エージェントをデプロイして有効化した後は、他クラウドのストレージタイプ用の DataSync ロケーションを作成します。他クラウドにある別の Amazon S3 互換オブジェクトストレージから AWS に転送する場合は、DataSync タスクのソースとして使用する DataSync オブジェクトストレージロケーション を作成する必要があります。サポートされているクラウドは、特定のリージョンまたはアカウントを持つパブリックエンドポイントと認証情報キーを提供し、DataSync が指定されたオブジェクトストレージにアクセスできるようにします。次の表は、サポートされているクラウドの Amazon S3 互換オブジェクトストレージと、指定されたクラウドから AWS にデータを転送するために DataSync が使用するエンドポイントおよび読み取り権限を示しています。特定のアクセス権限の詳細については、クラウドプロバイダーのドキュメントを参照してください。 ロケーションの例として Wasabi Cloud Storage を使用して、Wasabi バケットのリージョナルサーバーエンドポイントを指定し、アクセスキーの認証情報を入力します。ロケーションが作成されたら、そのロケーションを使用して DataSync タスク の一部として AWS にデータを転送できます。 Azure Blob Storage には、Amazon S3 互換のエンドポイントは提供されていません。Azure BLOB Storage からの転送は、 DataSync の Microsoft Azure Blob Storage ロケーションタイプ を使用して設定します。 クラウド間でデータを転送する際の考慮事項 DataSync はマルチクラウドのデータ転送を簡素化しますが、他のクラウドの特性を考慮する必要があります。Azure Blob Storage と Backblaze B2 Cloud Storage はオブジェクトタグをサポートしていますが、サポートされている他のクラウドプロバイダーは Amazon S3 インターフェイスからのオブジェクトタグやクエリタグをサポートしていません。DataSync には、 オブジェクトタグをコピー するタスクレベルのオプションが用意されていますが、タグの取得をサポートしていないクラウドにオブジェクトをコピーしたり、クラウドからオブジェクトをコピーしたりする場合は、このオプションを無効にする必要があります。 また、オブジェクトの読み取り元のソースストレージクラスも考慮する必要があります。他のクラウドプロバイダーには、データ転送の送信料金とリクエスト料金に影響するストレージクラスのオプションが混在しています。 DataSync は他のクラウドにリクエストを発行 して、オブジェクトの比較と読み取りを行い、変更とデータ転送を判断します。Amazon S3 と同様に、Azure Blob Storageと Oracle Cloud Storage のオブジェクトストレージにはアーカイブストレージクラスがあり、DataSync がアーカイブストレージクラス内のオブジェクトを読み取る前にオブジェクトを復元する必要があります。 まとめ この記事では、合併や買収によってクラウド間でデータを移動する場合や、お客様の要件で特定クラウドサービスを使ってデータを処理する場合などによって、お客様がマルチクラウド環境を管理する必要があるシナリオについて説明しました。DataSync が、他のクラウドが提供する様々なオブジェクトストレージやファイルサービス間でのデータ転送をサポートしたことを紹介しました。次に、クラウドプロバイダーのストレージエンドポイントの取得や、オブジェクトタグのサポート、データがどのストレージクラスにあるかを把握することの重要性、リクエストと送信料金など、クラウド間のデータ転送を計画する際の考慮事項をいくつか確認しました。 DataSync を使用すると、データ移動のワークフローを簡素化および自動化でき、複数のクラウドプロバイダーと通信できるソリューションを構築する際の障壁を最小限に抑えることができるため、AWS 間のデータ移動がこれまで以上に簡単に実現できます。 AWS の詳細なドキュメントとブログで今すぐ始めましょう。 Google Cloud Storage の AWS DataSync 転送設定 Microsoft Azure Blob Storage の AWS DataSync 転送設定 AWS DataSync を使用して Google Cloud Storage から Amazon S3 にデータを移行する方法 AWS DataSync を使用して Azure Blob Storage から Amazon S3 へ移行する AWS DataSync を使用して Azure Files の SMB 共有から AWS にデータを移行する方法 翻訳はプロフェッショナルサービス本部の葉山が担当しました。 Darryl Diosomito Darryl は AWS の Senior Solution Architect です。彼は、お客様がクラウドに移行する一環として、データを AWS に移行する支援に重点を置いています。Darryl はニューイングランド地域に住んでおり、季節ごとのアウトドアのアクティビティを見つけることを楽しんでいます。

このブログは Lorenzo Ripani (Big Data Solutions Architect) と Stefano Sandona (Analytics Specialist Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 高可用性（HA）とは、指定された期間、故障することなく継続的に稼働するシステムまたはサービスの特性です。システム全体に HA 特性を実装することで、通常、サービスの中断につながる単一障害点を排除し、ビジネスの損失やサービスが使用不可能となることを回避します。 耐障害性と高可用性の核となる考え方は、定義の点では非常にシンプルです。通常、特定のサービスに対して冗長性を持たせるために複数のマシンを使用します。これにより、ホストがダウンしても他のマシンがトラフィックを引き継ぐことができるようになります。簡単に聞こえるかもしれませんが、特に分散テクノロジーを扱う場合、このような特性を得るのは容易ではありません。 Hadoop テクノロジーに焦点を当てると、使用しているフレームワークによって、複数のレイヤーで可用性について考える必要があります。耐障害性を持ったシステムを実現するには、次のレイヤーを考慮する必要があります。 データレイヤー 処理レイヤー 認証レイヤー 最初の 2 つの層は、通常、Hadoop フレームワークのネイティブ機能（ HDFS High Availability や ResourceManager High Availability など ) や、使用する特定のフレームワークで利用できる機能（例えば、読み取り処理の可用性を高めるための HBase テーブルレプリケーション を使用して処理されます。 認証レイヤーは、通常、Kerberos プロトコルの利用によって管理されます。Kerberos には複数の実装が存在しますが、 Amazon EMR はマサチューセッツ工科大学（MIT）が直接提供する Kerberos プロトコルのフリーな実装を使用しており、MIT Kerberos とも呼ばれます。 キー配布センター (KDC) のネイティブ設定 を見ると、ツールには典型的なプライマリ/セカンダリ構成が付属しており、プライマリ KDC に 1 つまたは複数のレプリカを追加して、可用性の高いシステムの構成が可能です。 しかし、この構成ではシステムが中断した場合に新しいプライマリ KDC を選出する自動フェイルオーバー機構は提供されていません。そのため、手動でフェイルオーバーを行うか、自動化されたプロセスを実装する必要がありますが、自動化のセットアップ作業は容易ではありません。 AWS のネイティブサービスを利用することで、MIT KDCの機能に対して、システムの障害に対する耐性をさらに高めることができます。 高可用な MIT KDC Amazon EMR は、Kerberos 認証を有効にするための異なるアーキテクチャオプションを提供し、各々が特定のニーズやユースケースを解決できます。Kerberos 認証は、 Amazon EMR セキュリティ設定 を定義することによって有効にできます。セキュリティ設定は Amazon EMR 自身に保存される情報です。そのため、複数のクラスター間でこの構成を再利用することができます。 Amazon EMR のセキュリティ設定を作成する際、 クラスター専用の KDC か外部 KDC のどちらかを選択する必要があるため、それぞれのソリューションの利点と制限を理解することが重要です。 クラスター専用 KDC を有効にすると、Amazon EMR は起動するクラスターの EMR プライマリノード上に MIT KDC を構成してインストールします。一方、外部 KDC を使用する場合、起動したクラスターは外部の KDC に依存します。この場合、 KDC は外部 KDC として別の EMR クラスターのクラスター専用 KDC 、または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスやコンテナにインストールされた KDC を使用できます。 クラスター専用 KDC は、 KDC サービスのインストールと設定をクラスター自体に委ねる、簡単な構成のオプションです。このオプションは、Kerberos システムに関する深い知識を必要としないため、テスト環境に適しています。また、クラスター内に専用の KDC を設置することで、Kerberos レルムを分離できるため、組織内の特定のチームまたは部門の認証にのみ使用できる専用の認証システムを提供できます。 ただし、KDC は EMR のプライマリノードに配置されているため、クラスターを削除すると KDC も削除されることを考慮する必要があります。また、KDC を他の EMR クラスター（セキュリティ設定で外部 KDC と定義したもの）と共有する場合を考慮すると、それらの認証レイヤーが侵害され、結果としてすべての Kerberos が有効なフレームワークが機能しなくなります。これはテスト環境では許容されるかもしれませんが、本番環境では推奨されません。 KDC の寿命は特定の EMR クラスターに縛られるとは限らないため、EC2 インスタンスや Docker コンテナに設置した外部 KDC を使用するのが一般的です。このパターンには、次のような利点があります。 Active Directory を使用するかわりに、Kerberos KDC にてエンドユーザーの認証情報を保持することができます（ただし、クロスレルム認証を有効にすることもできます）。 複数の EMR クラスター間で通信を可能にし、すべてのクラスタープリンシパルが同じ Kerberos レルムに参加することで、すべてのクラスターで共通の認証システムを使用できます。 EMR プライマリノードを削除することで他のシステムの認証に影響が出ないように、EMR プライマリノードの依存関係を削除できます。 マルチマスターの EMR クラスターが必要な場合は、外部 KDC が必要です。 しかし、単一のインスタンスに MIT KDC をインストールしても、本番環境で重要な HA 要件には対応できません。次のセクションでは、認証システムの耐障害性を向上させるために、AWS のサービスを使用して可用性の高い MIT KDC を実装する方法について説明します。 アーキテクチャ概要 次の図に示すアーキテクチャは、AWS サービスを使用して、 複数のアベイラビリティゾーンに跨った高可用な MIT Kerberos KDC の構成です。ここでは 2 つのバージョンを提案します。 Amazon Elastic File System (Amazon EFS) ファイルシステムをベースにしたものと、 Amazon FSx for NetApp ONTAP (FSx for ONTAP) ファイルシステムをベースにしたものです。 どちらのサービスも EC2 インスタンスにマウントし、ローカルパスとして使用することが可能です。Amazon EFS はFSx for ONTAP と比較して安価ですが、後者はミリ秒以下の操作レイテンシーを提供するため、パフォーマンス が向上します。 異なるファイルシステムを含むソリューションのベンチマークとして、複数のテストを実施しました。次のグラフは、Amazon EMR 5.36 の結果です。フレームワークとして Hadoop と Spark を選択し、クラスターが完全に立ち上がるまでの時間を秒単位で測定しました。 テスト結果を見ると、NFS プロトコルのロック操作のレイテンシによってもたらされるパフォーマンス低下は、クラスタートポロジーのノード数を増やすとクラスター起動の遅延が大きくなるため、Amazon EFS ファイルシステムは小規模クラスター（100 ノード未満）の処理に適していることがわかります。例えば、200 ノードのクラスターでは、Amazon EFS ファイルシステムによって生じる遅延により、一部のインスタンスは時間内にクラスターに参加できなくなります。その結果、クラスターに参加できないインスタンスは削除され、その後置き換えられるため、クラスター全体のプロビジョニングが遅くなります。これが、上のグラフでクラスターノードの数が 200 の場合の Amazon EFS のメトリックを公開していない理由です。 一方、FSx for ONTAP は、クラスターのプロビジョニング中に作成されるプリンシパルの数が増えても、Amazon EFS と比較してパフォーマンスの低下を抑えながら、より適切に処理できます。 FSx for ONTAP を用いたソリューションであっても、インスタンス数が多いクラスターでは、 Amazon EFS で前述したような挙動が発生する可能性があります。したがって、大きなクラスター構成の場合は、このソリューションを慎重にテストして評価する必要があります。 Amazon EFS を使用したソリューション 次の図は、Amazon EFS を使用したソリューションのアーキテクチャです。 インフラストラクチャは、KDC の耐障害性を向上させるために、さまざまなコンポーネントに依存しています。このアーキテクチャでは、次のサービスを使用しています。 Kerberos サービスポート（認証用の port 88 と、プリンシパルの作成や削除などの管理タスク用の port 749）に対応するように構成された Network Load Balancer を使用しています。このコンポーネントの目的は、別々のアベイラビリティゾーンにある複数の KDC インスタンス間でリクエストのバランスをとることです。また、障害が発生した KDC インスタンスに接続する際のリダイレクトメカニズムを提供します。 KDC の可用性を維持し、定義した条件に従って EC2 インスタンスを自動的に追加または削除できるようにする EC2 Auto Scaling group を使用しています。このシナリオでは、 KDC インスタンスの最小数を 2 台と定義します。 Amazon EFS ファイルシステムは、 KDC データベースのための永続的で信頼性の高いストレージレイヤーを提供します。このサービスには HA プロパティが組み込まれているため、ネイティブ機能として永続的で信頼性の高いファイルシステムを利用できます。 Kerberos の設定、具体的には Kadmin サービスに使用するパスワード、 KDC が管理する Kerberos ドメインとレルムを保存および取得するために AWS Secrets Manager を使用します。Secrets Manager を使用することで、 KDC インスタンスの起動時にスクリプトのパラメータやパスワードなどの機密情報を入力する必要がなくなります。 この構成では、単一インスタンスのインストールによるデメリットがなくなります。 失敗した接続は正常な KDC ホストにリダイレクトされるため、KDC が単一障害点であることはありません。 認証のための EMR プライマリノードに対する Kerberos トラフィックがなくなると、プライマリノードの状態が改善されます。これは、大規模な Hadoop (数百ノードの場合) のインストールでは重要になる場合があります。 障害が発生中も、存続しているインスタンスで管理業務と認証業務を処理しながら復旧することができます。 FSx for ONTAP を使用したソリューション 次の図は、 FSx for ONTAP を使用したソリューションのアーキテクチャです。 このインフラストラクチャは Amazon EFS の構成とほとんど同じ構成であり、同じメリットがあります。唯一の違いは、複数のアベイラビリティゾーンの FSx for ONTAP ファイルシステムを KDC データベースの永続的で信頼性の高いストレージレイヤーとして使用していることです。この場合でも、サービスには HA プロパティが組み込まれているため、そのネイティブ機能を活用して、永続的で信頼性の高いファイルシステムを実現できます。 ソリューションで使用するリソース 本記事では、一般的なガイドとして AWS CloudFormation のテンプレートを提供しています。必要に応じて見直し、カスタマイズする必要があります。また、このスタックによってデプロイされたリソースの中には、使用し続けるとコストが発生するものがあることに注意してください。 CloudFormation テンプレートには、複数のネストしたテンプレートが含まれています。次のものを作成します。 KDC インスタンスをデプロイするための、2 つのパブリックと 2 つのプライベートサブネットを持つ Amazon VPC パブリックサブネットに接続するインターネットゲートウェイとプライベートサブネットに接続する NAT ゲートウェイ 各サブネットの Amazon Simple Storage Service （Amazon S3）ゲートウェイエンドポイントと Secrets Manager インターフェイスエンドポイント VPC を含むリソースがデプロイされた後、KDC のネストされたテンプレートが起動され、次のコンポーネントをプロビジョニングします。 監視する特定の KDC ポート（ Kerberos 認証用の port 88 と Kerberos 管理用の port 749 ）用のリスナーにそれぞれ接続された 2 つのターゲットグループ。 異なるアベイラビリティゾーンに作成された KDC インスタンス間でリクエストのバランスをとるための Network Load Balancer 1 台。 選択したファイルシステムに応じて、複数のアベイラビリティゾーンに跨った Amazon EFS または FSx for ONTAP ファイルシステム。 KDC インスタンスをプロビジョニングするための構成とオートスケーリング。具体的には、KDC インスタンスは、KDC のプリンシパルデータベースを格納するために使用されるローカルフォルダに選択したファイルシステムをマウントするように構成されます。 2 つ目のテンプレートが終了すると、外部 KDC が設定された、選択した場合にはマルチマスター構成で EMR クラスターが起動します。 CloudFormation スタックの起動 スタックを起動し、リソースをプロビジョニングするには、次の手順を実行します。 Launch Stack を選択: 「Launch Stack」をクリックすると、お使いの AWS アカウント（サインイン済でない場合はサインインするように移行します）で AWS CloudFormation テンプレートが自動的に起動します。必要に応じて AWS CloudFormation コンソールでテンプレートを表示することができます。スタックが意図するリージョンで作成されることを確認してください。 CloudFormation スタックには、次のスクリーンショットに示すように、いくつかのパラメータが必要です。 次の表は、スタックの各セクションで設定が必要なパラメータを記載しています。 Core セクションでは, 次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 Project aws-external-kdc 環境がデプロイされるプロジェクトの名前です。スタックで作成された各リソースに関連付けられた AWS タグを作成する際に使用されます。 Artifacts Repository aws-blogs-artifacts-public/artifacts/BDB-1689 このスタックを起動するために必要なテンプレートとスクリプトをホストしている Amazon S3 のロケーションです。 Networking セクションでは、次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 VPC Network 10.0.0.0/16 VPC のネットワーク範囲 (例：10.0.0.0/16) Public Subnet One 10.0.10.0/24 1 つ目のパブリックサブネットのネットワーク範囲 (例： 10.0.10.0/24) Public Subnet Two 10.0.11.0/24 2 つ目のパブリックサブネットのネットワーク範囲 (例： 10.0.11.0/24) Private Subnet One 10.0.1.0/24 1 つ目のプライベートサブネットのネットワーク範囲 (例： 10.0.1.0/24). Private Subnet Two 10.0.2.0/24 2 つ目のプライベートサブネットのネットワーク範囲 (例：10.0.2.0/24). Availability Zone One (ユーザー選択) 1 つ目のプライベートおよびパブリックサブネットを配置するためのアベイラビリティゾーン. Availability Zone Two パラメータの値とは異なる値となります。. Availability Zone Two (ユーザー選択) 2 つ目のプライベートおよびパブリックサブネットを配置するためのアベイラビリティゾーン. Availability Zone One パラメータの値とは異なる値となります。 KDC セクションでは、次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 Storage Service Amazon EFS KDC で使用する共有ファイルシステムを指定します。Amazon EFS または FSx for ONTAP を指定します。 Amazon Linux 2 AMI /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 最新の Amazon Linux 2 AMI を取得するための AWS Systems Manager パラメータエイリアスを指定します。 Instance Count 2 起動する KDC のインスタンスの数 Instance Type c5.large KDC のインスタンスタイプ KDC Realm HADOOP.LAN 外部 KDC サーバーによって管理される Kerberos レルム KAdmin Password Password123 KDC で管理者操作を実行するためのパスワード Kerberos Secret Name aws-external-kdc/kerberos.config Kerberos の設定を保存するために使用される Secrets Manager のシークレット名 EMR では、次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 Multi Master Disabled 有効にすると、 Hadoop HA で構成された3つのプライマリでクラスターが起動します。 Release Version emr-5.36.0 Amazon EMR のリリースバージョン (Workers) Instance Type m5.xlarge クラスターのプロビジョニングに使用された EC2 インスタンスタイプ (Workers) Node Count 1 クラスターの起動中にプロビジョニングされた Amazon EMR CORE ノードの数 SSH Key Name (ユーザー選択) SSH リモートアクセスを提供するためにクラスターと KDC インスタンスに添付される有効な SSH PEM 鍵 次へ を選択します。 必要に応じて AWS tags を追加します。 (このソリューションでは、すでにいくつかの定義済み AWS タグを使用しています) 次へ を選択します。 最終要件を確認します。 送信 を選択します。 テンプレートのネットワークセクションで、必ず異なるアベイラビリティゾーンを選択してください（Availability Zone One と Availability Zone Two）。これにより、アベイラビリティゾーン全体に障害が発生した場合の障害を防ぐことができます。 インフラストラクチャのテスト インフラストラクチャ全体のプロビジョニングが完了後、HA 構成のテストと検証を行います。 本テストでは、KDC インスタンスの障害発生をシミュレートします。障害が起きた際に、残っている健全な KDC を使い続け、障害が発生した KDC の代わりに KDC インスタンスを追加することで、インフラストラクチャがどのように自己回復するのかを確認します。 CloudFormation スタックを起動し、2つの KDC インスタンスを指定し、KDC データベースのストレージレイヤーとして Amazon EFS を使用してテストを実施しました。EMR クラスターは、11 台の CORE ノードで立ち上げています。 インフラストラクチャ全体をデプロイした後、SSH 接続を使用して EMR プライマリノードに接続 し、テストを実行することができます。 プライマリノード・インスタンスに接続後、テストのセットアップを進めます。 まず、KDC データベース内に 10 個のプリンシパルを作成します。そのために、create_users.sh という bash スクリプトを下記の内容で作成します。 #!/bin/bash realm="HADOOP.LAN" password="Password123" num_users=10 for (( i=1; i<=$num_users; i++ )); do echo "Creating principal test_user$i@$realm" echo -e "$password\n$password\n$password" | kadmin -p kadmin/admin@$realm addprinc "test_user$i@$realm" > /dev/null 2>&1 done 次のコマンドでスクリプトを実行します。 sh create_users.sh 10 個のプリンシパルが KDC データベース内に正しく作成されたことを確認します。これを行うには、list_users.sh という別のスクリプトを作成し、前のスクリプトと同じように実行します。 #!/bin/bash realm="HADOOP.LAN" password="Password123" echo -e "$password\n$password\n$password" | kadmin -p kadmin/admin@$realm listprincs スクリプトの出力には、クラスターノードがプロビジョニングされたときに作成されたプリンシパルと、作成したばかりのテストユーザーが表示されます。 ここで、複数の kinit リクエストを並行して実行し、その間に、利用可能な 2 つの KDC インスタンスのうち 1 つで krb5kdc プロセスを停止します。 このテストは、 kinit リクエストの高い並列性を実現するために、Spark を使用して実行されます。 次に user_kinit.sh というスクリプトを作成します。 #!/bin/sh realm="HADOOP.LAN" password="Password123" num_users="10" for (( i=1; i<=$num_users; i++ )); do echo -e "$password" | kinit test_user$i@$realm > /dev/null 2>&1 echo $? done spark-shell を開き、 —files パラメータを使用して、前述の bash スクリプトをすべての Spark エグゼキューターに配布します。また、Spark の動的割り当てを無効にし、各々が 4 つの vCore を使用する 10 個のエクゼキューターでアプリケーションを起動します。 spark-shell —files user_kinit.sh —num-executors 10 —conf spark.dynamicAllocation.enabled=false —conf spark.executor.cores=4 次の Scala 文を実行して、分散テストを開始します。 val tasks = spark.sparkContext.parallelize(1 to 1600, 1600) val scriptPath = "./user_kinit.sh" val pipeRDD = tasks.pipe(scriptPath) pipeRDD.map(_.toInt).sum この Spark アプリケーションは 1,600 個のタスクを作成し、各タスクは 10 個の kinit リクエストを実行します。 これらのタスクは、一度に 40 個の Spark タスクのバッチで並列に実行されます。このコマンドの最終出力は、失敗した kinit リクエストの数を返します。 ここでは、2 つの利用可能な KDC インスタンス に接続できます。このテンプレートでは、KDC インスタンスに SSH キーを提供していないため、 AWS Systems Manager Session Manager を使用して、SSH キーなしで接続します。Amazon EC2 コンソールから AWS Systems Manager を使用して KDC インスタンスに接続するには、 セッションの開始（ Amazon EC2 コンソール） を参照してください。 1 つ目の KDC にて、次のコマンドを実行して、受信した kinit 認証リクエストを表示します。 sudo -s tail -f /var/log/kerberos/krb5kdc.log 出力例は次のスクリーンショットの通りです。 2 つ目の KDC にて、次のコマンドを実行し、障害をシミュレートします。 sudo -s killall krb5kdc Amazon EC2 のコンソールに接続し、KDC に関連するターゲットグループを開くと、インスタンスの状態が Unhealthy になり（ 3 回連続でヘルスチェックが失敗した後）、その後削除されて新しいインスタンスに置き換えられたことが確認できます。 ターゲットグループは、サービスに障害が発生した際に以下の手順を実行します。 KDC インスタンスが Unhealthy の状態となる。 Unhealthy となった KDC インスタンスをターゲットグループから登録解除する。（ドレイン処理） 新しい KDC インスタンスを起動する。 新しい KDC インスタンスをターゲットグループに登録し、ロードバランサーからのトラフィックを受信できるようにする。 KDC インスタンスに障害が発生している間、次のスクリーンショットのような出力が表示されることが予想されます。 置き換えられた KDC インスタンスに接続すると、 krbr5kdc ログにトラフィックが表示され始めるのが確認できます。 テストの最後には、失敗した Kerberos 認証の総数が表示されます。 出力結果より、このテストでは認証の失敗がありませんでした。しかし、このテストを何度も繰り返すと、いくつかのリクエストの認証中に krbr5kdc のプロセスが停止してしまい、エラー（平均 1 ～ 2 個）が発生する可能性があります。. kinit ツール自体にリトライの仕組みがないことに注意してください。クラスター上で実行される Hadoop サービスと、 EMR インスタンスのプロビジョニング中に行われる Kerberos プリンシパルの作成は、いずれも KDC 呼び出しに失敗した場合にリトライするように設定されています。 これらのテストを自動化したい場合、 AWS Fault Injection Simulator の利用をご検討ください。これは AWS 上でフォールトインジェクション実験を行うためのフルマネージドサービスで、アプリケーションのパフォーマンス、オブザービリティ、レジリエンシーを容易に向上させることができます。 クリーンアップ すべてのリソースをクリーンアップするために、次の手順を行ってください。 AWS CloudFormation のルートスタックの削除。 削除の開始からしばらくすると、失敗が表示されます。 VPC のネストしたCloudFormationスタックをクリックし、 Resources を選択します。VPC リソースに対して、 DELETE_FAILED エントリが表示されています。これは、EMR が自動的に Default Security Groups を作成し、それらが CloudFormation による VPC の削除を妨げていることが原因です。 AWS コンソールの VPC セクションに移動し、その VPC を手動で削除します。 CloudFormation に戻り、ルートスタックを再度選択し、Delete を選択します。今度は削除が完了します。 ファイルシステムのバックアップ Amazon EFS と FSx for ONTAP は AWS Backup にネイティブに統合されています。 AWS Backup は、バックアップの自動化と一元管理を支援します。ポリシー駆動型のプランを作成した後、進行中のバックアップのステータスの監視、コンプライアンスの検証、バックアップの検索と復元をすべてマネジメントコンソールから行うことができます。 詳細については、 「AWS Backup を使用して、Amazon EFS ファイルシステムのバックアップおよび復元するには」 および、 「Amazon FSx で AWS Backup を使用する」 を参照してください。 その他考慮事項 本セクションでは、このソリューションを使用する際の考慮事項を説明します。 共有ファイルシステムのレイテンシーが与える影響 共有ファイルシステムの利用は、多くの場合パフォーマンスの低下に繋がります。特に、同時に作成しなければならない Kerberos プリンシパルが多ければ多いほど、プリンシパル作成プロセスとクラスター起動時間にレイテンシーが発生することがわかります。 この性能低下は、同時に行われる並列 KDC リクエストの数に比例します。たとえば、同じ KDC に接続された 20 ノードを持つ 10 個のクラスターを起動しなければならないシナリオを考えてみます。10 個のクラスターを同時に立ち上げると、フレームワークに関連する Kerberos プリンシパルを作成するための最初のインスタンスプロビジョニング中に、KDC へ 10 × 20 ＝ 200 の並列接続が発生する可能性があります。さらに、サービス用の Kerberos チケットの持続時間はデフォルトで 10 時間であり、すべてのクラスターサービスがほぼ同時に起動されるため、サービスチケットの更新にも同じレベルの並列性が発生する可能性があります。一方、この 10 個のクラスターを時間差で起動すると、並列接続が20個で収まる可能性があります。その結果、共有ファイルシステムによって生じるレイテンシーはそれほどパフォーマンスに影響しません。 本記事にて先述したように、複数クラスターでは関連する KDC 間でクロスレルム認証を設定することなく、互いに通信する必要がある場合に同じ KDC を共有することができます。複数のクラスターを同じ KDC にアタッチする前に、その必要性が本当にあるかどうかを評価する必要があります。なぜなら、より良いパフォーマンスを実現し、問題が発生した場合の影響範囲を小さくするために、Kerberos レルムを異なる KDC インスタンスに分離することも検討できるからです。 まとめ ダウンタイムが許されない EMR クラスターにとって、高可用性と耐障害性は重要な要件です。これらのクラスター内で実行される分析ワークロードは、機密データを扱う可能性があるため、安全な環境での運用が不可欠です。そのため、安全で可用性が高く、耐障害性の高いセットアップが必要です。 本記事では、Amazon EMR のビッグデータワークロードの認証レイヤーの高可用性と耐障害性を持たせるひとつの実現方法を紹介しました。AWS のネイティブサービスを使用することで、複数の Kerberos KDC を並行して動作させ、障害が発生した場合に自動的にインスタンスを交換する方法を示しました。これとフレームワーク固有の高可用性および耐障害性を組み合わせることで、安全で高可用性かつ耐障害性を持った環境で運用することができます。 翻訳はネットアップ合同会社の岩井様、監修はテクニカルアカウントマネージャーの有田が担当しました。 著者について Lorenzo Ripani は、AWS の Big Data Solution Architect です。分散システム、オープンソース技術、セキュリティに特化しています。世界中の顧客に対して、Amazon EMR を使ったスケーラブルで安全なデータパイプラインの設計、評価、最適化を提供しています。 Stefano Sandona は、AWS の Analytics Specialist Solution Architect です。データ、分散システム、セキュリティに特化しているエンジニアです。世界中の顧客のデータプラットフォームのアーキテクトを支援しています。Amazon EMR とその周辺のセキュリティに強い関心を持っています。

このブログは 2023 年 8 月 8 日に Dave Jaskie によって投稿された Migrating Amazon WorkSpaces services from Microsoft Office included bundles to Microsoft 365 を翻訳したものです。このブログでは、WorkSpaces サービスで実行されている Office バンドルから Microsoft 365 に移行する方法について説明します。 AWS では、 Amazon WorkSpaces サービスで Microsoft Office アプリケーションを実行するための 2 つの選択肢を提供しています。 Microsoft Office は、WorkSpaces アプリケーションバンドルの一部として購入できます。 また、2023 年 8 月 1 日より、 Microsoft 365 Apps for enterprise ライセンスを Amazon WorkSpaces サービスで使用できる ようになりました。 Microsoft 365 は、Microsoft Word、Microsoft Excel、Microsoft PowerPoint、Microsoft Outlook、 その他 の一般的なオフィスアプリケーションを使用して WorkSpaces サービスの機能を強化します。 含まれるアプリケーションは Microsoft 365 ライセンス プランによって異なります。 Microsoft では、Microsoft 365 E3、E5、A3、A5、Business Premium ライセンスを WorkSpaces サービスで実行することを許可しています。 このブログでは、WorkSpaces サービスで実行されている Office バンドルから Microsoft 365 に移行する方法について説明します。 WorkSpaces インスタンスで Microsoft 365 の使用を開始するために必要な手順は、次のシナリオで説明する多くの要因によって異なります。 一般的なシナリオ シナリオ1: カスタムパブリックバンドルを使用して、WorkSpaces を展開しました。このバンドルは、デスクトップエクスペリエンスを搭載した Microsoft Windows Server をベースにしており、AWS が提供する Office ライセンスを使用しています。 まず、AWS が提供する WorkSpaces の Office ライセンスを削除します。 WorkSpaces から Office ライセンスを削除するには、Office の AWS ライセンスが含まれていない新しいイメージから新しい WorkSpaces バンドルを作成します。 既存の WorkSpaces インスタンスから Office をアンインストールするだけでは、Office の AWS ライセンス料金は削除されないことに注意してください。 次の手順に従います。 パブリックバンドルから新しい WorkSpaces を起動します。リストされたイメージに Office が含まれていないことを確認するために、Software の選択で “Base”  をフィルタリングします。 新しく作成した WorkSpaces にログインします。Windows を更新し、Microsoft 365 とその他の必要なアプリケーションをインストールして、WorkSpaces のイメージを作成します。 新しいイメージの作成が完了したら、そのイメージからカスタムバンドルを作成します。 新しいカスタムバンドルができたので、個々の WorkSpaces をそのバンドルに移行できます。 追加の情報については、 カスタムの WorkSpaces イメージとバンドルの作成 、および、 WorkSpace の移行 、に関するドキュメントを参照してください。 シナリオ2: カスタムバンドルを使用し、AWS 提供の Office ライセンスを使用して、Windows デスクトップでのライセンス持ち込み (BYOL) に基づき Amazon WorkSpaces を展開しています。 まず、AWS が提供する WorkSpaces の Office ライセンスを削除します。 WorkSpaces から Office ライセンスを削除するには、Office の AWS ライセンスが含まれていない新しいイメージから新しい WorkSpaces バンドルを作成します。 既存の WorkSpaces インスタンスから Office をアンインストールするだけでは、Office の AWS ライセンス料金は削除されないことに注意してください。 移行プロセスは、シナリオ1 で説明したプロセスと似ています。違いは、代替となるベースイメージが、パブリック WorkSpaces イメージからではなく、BYOL イメージとして Amazon Compute Cloud (EC2) へインポートした Amazon Machine Image (AMI) から取得される点です。 参考として、 自分の Windows デスクトップライセンスを使用する を参照してください。 ステップ 6 の WorkSpaces コンソールを使用して BYOL イメージを作成する から開始できます。 WorkSpaces コンソールのイメージ にて、 “BYOL イメージの作成” を選択します。 AMI ID には、以前のイメージを作成したのと同じ EC2 AMI を使用します。アプリケーションを選択のドロップダウンリストでは、Microsoft Office 2016 または Microsoft Office 2019 を選択しないでください。 新しい BYOL イメージの作成が完了したら、カスタムバンドルを作成します。 新しいカスタムバンドルができたら、コンソールまたは API で、個々の WorkSpaces を移行できます。 詳細については、 カスタムの WorkSpaces イメージとバンドルの作成 、 WorkSpace の移行 に関するドキュメントを参照してください。 シナリオ3: 既存のWorkSpacesインスタンスにOfficeがインストールされていないか、Microsoft 365 以外のバージョンの Office がインストールされています。 このシナリオでは、WorkSpaces インスタンスは AWS が提供する Office バンドルを実行していません。 WorkSpaces インスタンスに他のバージョンの Office がある場合は、まずそれらをアンインストールしてから、Microsoft 365 のインストールを実行します。 WorkSpaces インスタンスに他のバージョンの Office がない場合は、Microsoft 365 のインストールに進むことができます。 Office の展開に関する Microsoft の推奨事項 を確認してください。 シナリオ4: 新しい WorkSpaces インスタンスの展開。 新しい WorkSpaces インスタンスでは、AWS から Office バンドルを購入して使用しないでください。Microsoft 365 アプリケーションを展開するには、Microsoftの推奨事項に従ってください。Officeは カスタムイメージとしてバンドルに追加 するか、WorkSpaces インスタンスの起動後に展開できます。 シナリオ5 : Microsoft からの例外がある。 ユーザーが Microsoft 365 で展開された WorkSpaces インスタンスの利用を許諾され、すでにその環境を利用している場合は、正しいライセンスが配置されていることを Microsoft ライセンスプロバイダに確認してください。 API を使用した移行の自動化 複数の WorkSpaces のバンドルを一度に移行するには、 MigrateWorkSpaces API を使用します。 コマンドが発行されると切断されるため、ユーザーが WorkSpaces を使用していないことを確認してください。 このプロセスを自動化するには、 AWS CLI 、 AWS Tools for PowerShell 、または、 AWS SDK を使用してカスタムスクリプトを作成します。 特定のバンドルを持つ WorkSpaces のリストを取得する まずは非本番環境でテストし、その後 WorkSpaces インスタンスを少量ずつ移行することをお勧めします。大規模な移行を計画している場合は、AWS アカウントチームに支援を依頼してください。 PowerShell を開き、次のように入力します。 Get-WKSWorkSpaces -Region [ your-region-id ] -BundleId [ your-bundled ] WorkSpaces のマイグレーション PowerShell を開き、移行する WorkSpaceId、Region、および、BundleId を指定し、以下のコマンドを実行します。 Start-WKSWorkspaceMigration -SourceWorkspaceId [ your-workspaceid ] -Region [ your-region-id ] -BundleId [ your-bundleid ] または、オープンソースの EUC Toolkit プロジェクトを使用して、自動化を開始するための対話型 GUI を作成することもできます。 WorkSpace インスタンスの新しいバンドルへの移行 WorkSpaces が特定されたら、次のコマンドを使用して移行できます。 Start-WKSWorkspaceMigration 結論 このブログでは、Microsoft 365 Apps for enterprises のライセンスを Amazon WorkSpaces で使用するためのオプションを紹介しました。 さらに、Office バンドルとともに展開された WorkSpaces バンドルを識別するためのいくつかのオプションも取り上げました。 これらの情報を使用して、Microsoft 365 への移行の計画と自動化を開始することができます。 このブログに記載されている手順を、お客様の特定のユースケースに最適化する方法についてご相談されたい場合は、アカウントチームまでご連絡ください。 翻訳はソリューションアーキテクトの平田が担当しました。原文は こちら です。

この記事は Exposing Kubernetes Applications, Part 3: NGINX Ingress Controller (記事公開日: 2022 年 11 月 22 日) を翻訳したものです。 はじめに 連載「Kubernetes アプリケーションの公開」では、Kubernetes クラスターで実行されているアプリケーションを、外部からのアクセスのために公開する方法に焦点を当てます。 Part 1 では、Kubernetes クラスターでインバウンドトラフィックの制御を定義する 2 つの方法である Service と Ingress リソースタイプについて探りました。Service と Ingress コントローラーによるこれらのリソースタイプの処理について説明し、その後、いくつかのコントローラーの実装バリエーションの利点と欠点について概要を説明しました。 Part 2 では、Ingress コントローラーの AWS のオープンソース実装である AWS Load Balancer Controller について、セットアップ、設定、想定されるユースケース、制限事項をウォークスルーしました。 今回、Part 3 では、Ingress コントローラーのまた別のオープンソース実装である NGINX Ingress Controller に注目します。その機能の一部や、AWS Load Balancer Controller との違いについてウォークスルーします。 NGINX Ingress Controller のアーキテクチャ Part 1 では、下図に示すようなクラスター内レイヤー 7 リバースプロキシーを使用する Ingress コントローラーのタイプについて説明しました。 NGINX Ingress Controller の実装は、上記のアーキテクチャに沿っています。 コントローラーは、人気のあるオープンソースの HTTP およびリバースプロキシサーバーである nginx のインスタンスを含む Pod をデプロイ、設定、および管理します。これらの Pod は 、コントローラーの Service リソースを介して公開され、Ingress およびバックエンドの Service リソースで表される関連アプリケーションを対象としたすべてのトラフィックを受信します。コントローラーは、Ingress と Service の設定を、静的に提供される追加パラメータと組み合わせて、標準的な nginx の設定に変換します。そして、この設定を nginx の Pod に注入し、トラフィックをアプリケーションの Pod にルーティングします。 NGINX Ingress Controller の Service は、ロードバランサーを介して外部トラフィック向けに公開されています。この Service は、通常の <service-name>.<namespace-name>.svc.cluster.local クラスター DNS 名を介してクラスター内部からも利用できます。 ウォークスルー NGINX Ingress Controller がどのように動作するかを理解したので、実際に動作させてみましょう。 前提条件 1. AWS アカウントへのアクセスの取得 AWS アカウントと、AWS コマンドラインインターフェイス ( AWS CLI ) や類似のツールを使用して、ターミナルから AWS と通信できる必要があります。 以下のコード例では、AWS アカウント ID やリージョンなど、置き換えることを前提とした文字列がいくつかが含まれています。これらは、あなたの環境に合った値で置き換えてください。 2. クラスターの作成 eksctl を使用して Amazon EKS クラスターをプロビジョニングします。eksctl はクラスター自体の作成に加えて、VPC、サブネット、セキュリティグループといった必要なネットワークリソースもプロビジョニングおよび設定します。 以下の eksctl 設定ファイルは、 Amazon EKS クラスターとその設定を定義します。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: nginx-ingress-controller-walkthrough region: ${AWS_REGION} version: '1.27' iam: withOIDC: true managedNodeGroups: - name: main-ng instanceType: m5.large desiredCapacity: 1 privateNetworking: true 上記のコードを config.yml ファイルに記述してください。 AWS_REGION および AWS_ACCOUNT 環境変数を定義してください。その後、クラスターを作成します。 envsubst < config.yml | eksctl create cluster -f - このウォークスルーでは、Kubernetes バージョン 1.23 の Amazon EKS プラットフォームバージョン eks.3 を使用しています。(訳注: 翻訳時には、Kubernetes バージョン 1.27 の Amazon EKS プラットフォームバージョン eks.4 を使用して動作を確認しています。) シンプルにするため、上記の構成では、セキュリティやモニタリングなど、Kubernetes クラスターのプロビジョニングと管理の多くの側面は考慮していません。より詳細な情報とベストプラクティスについては、 Amazon EKS と eksctl のドキュメントを参照してください。 クラスターが稼働していることを確認します。 kubectl get nodes kubectl get pods -A 上記のコマンドは、1 つの Amazon EKS ノードと 4 つの実行中の Pod を返すはずです。 3. Helm のインストール コントローラーのインストールと設定には、Kubernetes において一般的なパッケージマネージャーである Helm を使用します。 こちら の手順に従って Helm をインストールしてください。 NGINX Ingress Controller のインストール 1. Helm を使用したコントローラーのインストール helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --version 4.2.3 \ --namespace kube-system \ --set controller.service.type=ClusterIP kubectl -n kube-system rollout status deployment ingress-nginx-controller kubectl get deployment -n kube-system ingress-nginx-controller コントローラーの Service を ClusterIP に設定しています。これは、ウォークスルー中にコントローラーの様々な設定パラメータを変更した際に、ロードバランサーが再作成されるのを回避するためです。ロードバランサーの作成については、記事の後半で説明します。 テスト用 Service のデプロイ 1. Namespace の作成 kubectl create namespace apps 2. Service のマニフェストファイルの作成 以下のコードを service.yml ファイルに記述します。 apiVersion: apps/v1 kind: Deployment metadata: name: ${SERVICE_NAME} namespace: ${NS} labels: app.kubernetes.io/name: ${SERVICE_NAME} spec: selector: matchLabels: app.kubernetes.io/name: ${SERVICE_NAME} replicas: 1 template: metadata: labels: app.kubernetes.io/name: ${SERVICE_NAME} spec: terminationGracePeriodSeconds: 0 containers: - name: ${SERVICE_NAME} image: hashicorp/http-echo imagePullPolicy: IfNotPresent args: - -listen=:3000 - -text=${SERVICE_NAME} ports: - name: app-port containerPort: 3000 resources: requests: cpu: 0.125 memory: 50Mi --- apiVersion: v1 kind: Service metadata: name: ${SERVICE_NAME} namespace: ${NS} labels: app.kubernetes.io/name: ${SERVICE_NAME} spec: type: ClusterIP selector: app.kubernetes.io/name: ${SERVICE_NAME} ports: - name: svc-port port: 80 targetPort: app-port protocol: TCP http-echo イメージを使用する上記の Service は、 ${SERVICE_NAME} 変数で定義した Service 名でリクエストに応答します。シンプルにするため、レプリカは 1 つとしています。 3. サービスのデプロイと検証 以下のコマンドを実行します (この記事を通して、これらの Service を使用します) 。 SERVICE_NAME=first NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=second NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=third NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=fourth NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=error NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=another-error NS=apps envsubst < service.yml | kubectl apply -f - すべてのリソースがデプロイされていることを確認しましょう。 kubectl get pod,svc -n apps シンプルな Ingress のデプロイ 1. Ingress のマニフェストファイルの作成と Ingress のデプロイ 以下のコードを ingress.yml ファイルにコピーしてください。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} spec: ingressClassName: nginx rules: - http: paths: - path: /first pathType: Prefix backend: service: name: first port: name: svc-port - path: /second pathType: Prefix backend: service: name: second port: name: svc-port AWS Load Balancer Controller の場合に見たのと同じように、 ingressClassName プロパティを nginx に設定することで、 NGINX Ingress Controller をターゲットにします。 nginx はコントローラーとともにインストールされるデフォルトの IngressClass の名前です。 以下のコマンドを実行して Ingress をデプロイします。 NS=apps envsubst < ingress.yml | kubectl apply -f - しばらくすると、Ingress リソースの状態を確認できるようになります (IP アドレスのバインドには少し時間がかかる場合があります) 。 kubectl get ingress -n apps 以下のような出力が得られます。 上記の ADDRESS と PORT 列は、コントローラーの Service のものが設定されています。 ClusterIP タイプで Service を作成するようにコントローラーを設定したため、Service と通信する方法として、Service に対するポートフォワーディングを設定する必要があります。 kubectl port-forward -n kube-system svc/ingress-nginx-controller 8080:80 2. Ingress のテスト これで、コントローラーの Service にリクエストを送信できるようになりました。 curl -sS localhost:8080/first curl -sS localhost:8080/second curl -sS localhost:8080/third 次の結果が得られれば、Ingress リソースがは正しくデプロイされ、設定されています。 IngressClass に関する考察 前述したように、 nginx という名前のデフォルトの IngressClass がコントローラーと一緒にインストールされています。以下のようなリソースです。 apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: nginx labels: app.kubernetes.io/name: ingress-nginx ... spec: controller: k8s.io/ingress-nginx AWS Load Balancer Controller とは異なり、 NGINX Ingress Controller は IngressClass パラメータ をサポートしていません。 IngressClass をデフォルトにするためには、 ingressclass.kubernetes.io/is-default-class: "true" アノテーションを追加するか、コントローラーのインストール時にデフォルトにするように設定します。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.ingressClassResource.default=true \ ... Default Backend とエラーハンドリング Ingress リソースのいずれかによって処理されないパスにリクエストを送信すると、nginx が 404 で応答することを確認しました。このレスポンスは、コントローラーにインストールされている Default Backend から返されます。これをカスタマイズする 1 つの方法は、たとえば Helm の values.yml ファイル を介して、 controller.defaultBackend プロパティを設定することです。これについては、この記事で後ほど説明します。もう 1 つの方法は、Ingress リソースに nginx.ingress.kubernetes.io/default-backend アノテーションを設定することです。 最後の方法として、次に示すような Ingress の仕様で設定することができます。 1. Ingress の更新とデプロイ ingress.yml ファイルを以下のように更新します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} spec: ingressClassName: nginx defaultBackend: service: name: error port: name: svc-port rules: - http: paths: - path: /first pathType: Prefix backend: service: name: first port: name: svc-port - path: /second pathType: Prefix backend: service: name: second port: name: svc-port デプロイします。 NS=apps envsubst < ingress.yml | kubectl apply -f - 2. Ingress のテスト これで、再びリクエストを送信してみましょう。 curl -sS localhost:8080/first curl -sS localhost:8080/second curl -sS localhost:8080/third これは、Default Backend を使用して、期待どおりに機能します。 複数の Ingress リソース 複数の Ingress リソースがあり、それらが異なるチームに属していたり、より大きなアプリケーションの一部であったりすることがよくあります。これらは別々に開発されデプロイされる必要がありますが、別々の構成は必要なく、1 つのコントローラーのインストールで処理できます。 NGINX Ingress Controller は Ingress リソースの マージをサポート していますが、 AWS Load Balancer Controller のようにリソースの順序やグルーピングを明示的に定義することはできません。 ホストベースのルーティング これまでのすべての例では、すべてのリクエストは同じドメインにルーティングされ、Ingress リソースが同じ *.* ホストにマージされることを前提としていました。どの Service がどのドメインで提供されるかを明示的に定義し、Ingress のホスト設定でそれらをセグメント化したりマージしたりすることもできます。 1. Ingress の更新とデプロイ ingress.yml を更新します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} spec: ingressClassName: nginx defaultBackend: service: name: error port: name: svc-port rules: - host: a.example.com http: paths: - path: /first pathType: Prefix backend: service: name: first port: name: svc-port - host: b.example.com http: paths: - path: /second pathType: Prefix backend: service: name: second port: name: svc-port 以下のコマンドを実行します。 NS=apps envsubst < ingress.yml | kubectl apply -f - 2. Ingress のテスト curl を使用して、さまざまなドメインへのリクエストをシミュレートできます。 curl localhost:8080/first -H 'Host: a.example.com' curl localhost:8080/second -H 'Host: b.example.com' curl localhost:8080/first -H 'Host: b.example.com' curl localhost:8080/first -H 'Host: b.example.net' 出力は次のようになります。 最後の 2 つのリクエストは、Default Backend にルーティングされることが期待されます。1 つはそのホストで定義されていないパスに送信されているため、もう 1 つは存在しないホストであるためです。 a.myapp.com と b.myapp.com の DNS レコードを NGINX Ingress Controller の Service に向けることで、両方のホストを処理することができます。このタスクを完了するために、Service を外部トラフィック向けに公開します (外部ロードバランサー経由など) 。これについては、この記事の後半で詳しく説明します。 Ingress の pathType および正規表現とリライト これまで、Ingress ルールの pathType を Prefix と定義してきました。 pathType を Exact に設定し、パスで 正規表現を使用 したり、リライトルールを定義することもできます。 1. Ingress の更新とデプロイ ingress.yml ファイルの Ingress 定義を変更し、再デプロイしましょう。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: ingressClassName: nginx defaultBackend: service: name: error port: name: svc-port rules: - http: paths: - path: /first/(.*)/foo pathType: Prefix backend: service: name: first port: name: svc-port nginx.ingress.kubernetes.io/rewrite-target アノテーションは、ルールのパスで定義されたキャプチャグループのうち、どれを Service に送信するかを定義しています。すなわち、 /$1 の場合は、1 番目のキャプチャグループの内容をリクエストのパスとして Service に送信します。 Ingress をデプロイしましょう。 NS=apps envsubst < ingress.yml | kubectl apply -f - 2. Ingress のテスト テストを実行します。 curl -sS localhost:8080/first curl -sS localhost:8080/first/foo curl -sS localhost:8080/first/bar curl -sS localhost:8080/first/bar/foo これは、次のような結果になります。 ロードバランサー経由で NGINX Ingress Controller を公開する in-tree Service コントローラーを使用する NGINX Ingress Controller を外部トラフィック向けに公開する最もシンプルな方法は、 Part 1 で説明した in-tree コントローラー に Service を処理させることです。そのためには、Service のタイプを LoadBalancer に設定します。これによって、 AWS Classic Load Balancer (CLB) がプロビジョニングされます。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.service.type=LoadBalancer \ ... AWS Classic Load Balancer の代わりに、より新しく、推奨される AWS Network Load Balancer を指定することもできます。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.service.type=LoadBalancer \ --set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"="nlb" \ ... また、Helm の values.yml ファイルを使用して、これらの設定パラメータをより快適な方法で提供することもでき、同じ効果を得られます。次のセクションでそのような使用例を見ていきます。 AWS Load Balancer Controller を使用する方法 Service のために作成しプロビジョニングされる Network Load Balancer をより詳細に制御したい場合は、Service コントローラーをインストールします。 AWS Load Balancer Controller が推奨される選択肢です。 AWS Load Balancer Controller も Ingress リソースを処理しますが、処理対象の IngressClass が alb であり NGINX Ingress Controller とは異なるため、衝突は発生しません。 NGINX Ingress Controller 用に AWS NLB をプロビジョニングする AWS Load Balancer Controller のインストールについては、すでに連載の Part 2 で説明しましたので、これについてはおなじみのはずです。 1. AWS Load Balancer Controller 用の AWS IAM ポリシーの作成 この手順のステップ 2 と3 のみ を実行して、 AWSLoadBalancerControllerIAMPolicy を作成します。IRSA ( IAM Roles for Service Accounts ) を使用して、AWS Load Balancer Controller に IAM アクセス許可を提供します。 なお、 OIDC IAM プロバイダー の登録は、上述のクラスター定義によって eksctl が自動的に行うため、明示的に行う必要はありません。 2. AWS Load Balancer Controller 用の Service Account の作成 連載の Part 2 では、 eksctl によるクラスターの作成時に、 AWS Load Balancer Controller の Service Account を作成しましたが、今回は個別に作成します。 eksctl create iamserviceaccount \ --cluster=nginx-ingress-controller-walkthrough \ --name=aws-load-balancer-controller \ --namespace=kube-system \ --attach-policy-arn=arn:aws:iam::${AWS_ACCOUNT}:policy/AWSLoadBalancerControllerIAMPolicy \ --approve 3. CRD のインストール 以下のコマンドは、AWS Load Balancer Controller が機能するために必要な CustomResourceDefinition をインストールします。 kubectl apply -k \ "github.com/aws/eks-charts/stable/aws-load-balancer-controller//crds?ref=master" 4. Helm を使用した AWS Load Balancer Controller のインストール helm repo add eks https://aws.github.io/eks-charts helm upgrade -i aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --set clusterName=nginx-ingress-controller-walkthrough \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller kubectl -n kube-system rollout status deployment aws-load-balancer-controller kubectl get deployment -n kube-system aws-load-balancer-controller 5. NGINX Ingress Controller の再デプロイ NGINX Ingress Controller の Helm チャートに設定パラメータを渡す方法を変更します。 values.yml ファイルを作成します。 controller: service: type: LoadBalancer annotations: service.beta.kubernetes.io/aws-load-balancer-name: apps-ingress service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: http service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthz service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: 10254 ここでは、Service のタイプを変更し、ロードバランサー (Network Load Balancer) の名前を定義し、アクセスできるように internet-facing としています。さらに、ターゲットタイプを ip とし、NGINX サーバーのヘルスチェックを設定しています。 AWS Load Balancer Controller の Service のアノテーションの詳細については、 ここ を参照してください。 NGINX Ingress Controller を再デプロイします。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --version 4.2.3 \ --namespace kube-system \ --values values.yml kubectl -n kube-system rollout status deployment ingress-nginx-controller kubectl get deployment -n kube-system ingress-nginx-controller 6. Ingress のテスト pathType やコントローラーのリライト機能を説明するために使用したのと同じ Ingress 定義を使っていることに注意してください。 Network Load Balancer の URL を環境変数に保存します。 export NLB_URL=$(kubectl get -n kube-system service/ingress-nginx-controller \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') 数分後、ロードバランサーのプロビジョニングが完了すると、リクエストを送信できるようになります。 curl ${NLB_URL}/first curl ${NLB_URL}/first/foo curl ${NLB_URL}/first/bar curl ${NLB_URL}/first/bar/foo これによって、予想どおり、以前と同じ結果が得られます。 既存のロードバランサーに NGINX Ingress Controller をアタッチする 前述の Service コントローラーを使用する方法に加えて、AWS CLI や Infrastructure as Code ツール ( AWS CloudFormation 、 AWS CDK 、 Terraform など) を介して Application Load Balancer や Network Load Balancer をプロビジョニングすることも可能です。 そのような場合、上記でインストールしたカスタムリソース定義の一部である TargetGroupBinding を使用することができます。 このリソース は、Service の Pod の IP アドレスをターゲットグループのターゲットとして登録することにより、Service (名前と Namespace で選択) をロードバランサーのターゲットグループ ( ARN で選択) にバインドします。 これは、ロードバランサーが他のコンピュートリソースで使用されている場合に有用な場合があります。まれに、クラスター内レイヤー 7 プロキシの上に、Application Load Balancer の独自機能の 1 つを利用するように設定する必要がある場合にも有用です。 複数の Ingress コントローラー 場合によっては、クラスター内に NGINX Ingress Controller の複数のインスタンスを構成して、別々の Ingress リソースを処理させることができます。これは、コントローラーに異なる設定を提供することで実現します。 AWS Load Balancer Controller とは異なり、 NGINX Ingress Controller はこのような構成をサポートしています。 次の例は 2 番目のコントローラーの例です。ユニークな名前、IngressClass 名、コントローラー値の設定が IngressClass に反映されます。 helm upgrade -i ingress-nginx-one ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.ingressClassResource.controllerValue=k8s.io/ingress-nginx-one \ --set controller.ingressClassResource.name=nginx-one \ ... これで、Ingress リソースは、 ingressClassName を nginx-one に設定することで、このコントローラをターゲットにできるようになります。 クリーンアップ これでウォークスルーは終了です。ウォークスルー中に作成したリソースを削除するには、次のコマンドを実行します。 helm uninstall -n kube-system ingress-nginx helm uninstall -n kube-system aws-load-balancer-controller envsubst < config.yml | eksctl delete cluster -f - aws iam delete-policy --policy-arn arn:aws:iam::${AWS_ACCOUNT}:policy/AWSLoadBalancerControllerIAMPolicy まとめ このシリーズでは、いくつかの Ingress コントローラーを紹介し、それぞれがどのように異なる動作をするのかを強調しながら説明しました。 NGINX Ingress Controller は、nginx のパワーを利用します。これはより柔軟なコントローラーですが、リクエストのデータパス上に必要なコンポーネントのメンテナンス、パッチ適用、スケーリングが必要になるという欠点があります。 これに対し、 AWS Load Balancer Controller は、その負担を、可用性が高くスケーラブルで実績のあるマネージドサービスである Elastic Load Balancing にアウトソーシングし、その機能セットに依存して必要な設定オプションを提供します。 極めて高い柔軟性と運用の簡便性のどちらを選択するかは、導入されるアプリケーションの要件に基づいて決まります。この連載では取り上げていない他の Service コントローラーや Ingress コントローラーとともに、アプリケーションを外部トラフィックに公開するための豊富な選択肢を提供するはずです。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

この投稿は、AWS と SAP の以下のメンバーによって共同執筆しました。 Ferry Mulyadi, Partner Solution Architect SAP Alliance APJ, AWS Manjunath Chandrashekhar, Director SAP Business Technology Platform CoE APJ, SAP はじめに 多くの SAP のお客様は、SAP への投資をより有効活用できるために、コア SAP ERP または SAP S/4HANA 内にカスタムコードの導入を検討しています。 アメリカ SAP ユーザーグループ ( ASUG 2021 ) が行った市場調査 によると、91％ 以上の顧客が重要なビジネスプロセスを実現するためにカスタムコードに依存しています。そのうちの 57% は、重要なビジネスプロセスの半分以上を SAP のカスタムインターフェースに依存しています。 これらのカスタムアプリケーションとインターフェースは、ビジネスライン全体でより効率的にプロセスを推進するために構築されたものですが、同時に企業に大きなオーバーヘッドをもたらしました。 アプリケーションは通常、 6 ～ 8 年前にレガシー開発フレームワークを使用して構築されました。 アプリケーションのメンテナンスと改善ノウハウは、従業員の減少によって失われています。 既存のアプリケーションを維持するコストのコントロールは難しくなっています。 SAP Business Technology Platform ( SAP BTP ) と Amazon Web Services ( AWS ) のクラウドサービスにより、SAP のお客様は SAP S/4HANA の重要なビジネスプロセスの改革に目を向けることができます。 SAP が推奨する クリーンコアの方法論 を取り入れられます。 SAP BTP は、データ分析、人工知能、機械学習、アプリケーション開発、自動化、連携を1つの統一されたプラットフォームに統合しています。 SAP BTP のサービスは AWS リージョンでも稼働され 、 AWS データ分析サービス 、 AWS IoT サービス 、 AWS AI 及び ML サービス 、その他の AWS サービスによって補完されています。 SAP BTP on AWS を選択する理由 SAP BTP は、データ分析、人工知能、機械学習、アプリケーション開発、自動化、統合の機能を1つの統一プラットフォームに集約しています。、2022 年 9 月 15日時点のSAP Discovery Center によると、SAP BTP には 96 のサービスがあり、そのうち 83 のサービスが 世界中で9 つの AWS リージョンで稼働されています。以下は例のサービスです。 Forms Service by Adobe は、SAP S/4HANA Private Cloud Edition ( PCE ) または RISE with SAP では常に必要なサービスです。このサービスがないと、請求書、販売注文書、船荷証券などの PDF 出力、印刷やインタラクティブフォームを生成できません。 SAP Process Automation は、ワークフローとロボティックプロセスオートメーションを組み合わせ、SAP のお客様がコードレスでビジネスプロセスの自動化を実現できるサービスを提供しています。 SAP Analytics Cloud は、SAP Data Warehouse Cloud ( SAP DWC ) と組み合わせた包括的なレポート、分析、計画のソリューションを提供しています。 SAP S/4HANA ( または RISE with SAP on AWS ) と SAP BTP を AWS 上で稼働する場合、すべてのインスタンスが AWS グローバルネットワーク内で稼働し、 AWS PrivateLink にもサポートされるため、より安全なアーキテクチャを実現でき、追加のデータ通信料金、データ通信レイテンシー、および追加のストレージ費用を回避できます（参考文献： SAP PrivateLink サービスを使用して SAP BTP サービスと AWS サービスを接続する方法 、 データ転送に関するアナウンス 、 Amazon VPC FAQ ) 。これにより、SAP DWC と AWS のデータ分析サービス 間の双方向データ連携など、強力なソリューションへが可能になり、ニーズに応じた最適なスケール、パフォーマンス、コストでニアリアルタイム分析を実現できます。 AWS と SAP BTP ジョイントレファレンスアーキテクチャが必要になる理由 AWS と SAP BTP のジョイントレファレンスアーキテクチャは、様々なビジネスソリューションのシナリオに SAP BTP または AWS サービスを使用する方法に関して、お客様やパートナーから来た共通の質問に答えるために作られました。それぞれのユースケースを深堀すると、AWS と SAP BTP のサービスが互いに補完し合い、ビジネス課題を解決するために連携が可能であることがわかりますでしょう。AWS と SAP BTP のジョイントレファレンスアーキテクチャでは、お客様にとって最高の Time-to-value と最小の TCO を達成するためのアーキテクチャの選択について、その指針を説明します。 基本方針 サービス機能 各サービスのビジネス課題を解決するための機能及び、どの技術領域に活用できるのかにより、アーキテクチャが決まります。以下は例のサービスです。 発注書承認のためのモバイルアプリを構築するために、ノーコードアプリ開発環境として SAP AppGyver を使用 AWS IoT Greengrass  と IoT Core を利用して、製造ライン向けの IoT との統合を構築 プリビルドコンテンツ 既にデータ連携又はレポート機能を持っているサービスがあれば、そのサービスを利用し、より良い Time to Value と 低い TCO を達成することが望ましいです。例としては、以下のようなサービスがあります。 SAP Integration Suite には、S/4HANA と SAP SuccessFactors との連携機能は持っています。SAP は、SAC、Planning と SAP DWC を使ったデータ分析ユースケースのために、あらかじめプレビルドビジネスコンテンツを提供しています。 Amazon AppFlow は、non-SAP エンタープライズアプリケーション又は Amazon S3 との連携機能を持っています。 データフェデレーション トランザクションデータレポーティング、人工知能 ( AI )、機械学習 ( ML ) などのユースケース向けの統合分析ソリューションが必要な場合、データレプリケーションではなくソースからデータにアクセスすることが望ましいです。理由は、パフォーマンス向上、レイテンシーの回避、作業の軽減、ストレージなどの追加コストの削減です。以下は例となります。 AWS IoT 、SAP Plant Maintenance、 Amazon Redshift からのデータに対して、 SAP DWC の機能を使ってデータフェデレーションを実現すれば、全体の機器の効率 ( OEE ) ダッシュボードをより効率的に構築できます。 リアルタイムで Amazon Athena に直接クエリーをフェデレートする SAP Data Warehouse Cloud の分析モデルを通じてライブデータをもたらし、SAP Analytics Cloud で売上比較分析チャートを示すエンドツーエンドシナリオです。 データロケーション ユースケースと合わせて、データが存在する場所によって、どのサービスを使うべきかの優先順位が決まります。例えば、以下のような例があります。 データソースが SAP アプリケーションにある場合、データミックスが主に SAP 主導であるため、可視化と分析の要件には SAP DWC と SAC を使用することが望ましいです。 データソースが Amazon S3 や Amazon Redshift にある場合（例えば、AWS IoT のデータストリームからのデータ）、可視化ツールには Amazon Quicksight を使用することが好ましいでしょう。 また、あるシナリオでは、ユースケースの要件で適切なツールの選択が決まり、データが存在する場所だけではソリューションの設計が決まらないこともあるので、注意してください。 このブログに記載している基本指針は原則的なものではなく、お客様のシナリオ、考慮事項、ユースケースに基づいて常にカスタマイズできます。 AWS と SAP BTP ジョイントレファレンスアーキテクチャのユースケース例 機械学習のためのデータフェデレーションアーキテクチャ 図 1 のアーキテクチャで、SAP FedML ( Federated Machine Learning Libraries) を活用し、ビジネスデータの抽出・移行をしなくても、 Amazon SageMaker で機械学習モデルの構築や学習させることができます。 このライブラリは、SAP Data Warehouse Cloud のデータ連携アーキテクチャを使って、ユーザやデータサイエンティストが Amazon SageMaker 上で機械学習モデルを構築、トレーニング、デプロイできるようにします。ソースからデータを複製または移行する必要性を回避できます。 図1. 機械学習のためのデータ連携アーキテクチャ SAP と AWS のモダンデータアーキテクチャ お客様がデジタルコアとして SAP S/4HANA を選び、エンタープライズデータ統合分析プラットフォームとして AWS を選択した場合、SAP とエンタープライズのデータの統合が重要になります。これは、データフェデレーションやデータレプリケーションにより実現できます。図 2 はモダンデータアーキテクチャであり、パートナーやお客様が SAP BTP と AWS のレポーティング、分析、ビジネスプランニングに関するサービス活用し、ビジネス課題を解決し、これまで不可能だった新しいビジネスの可能性を見いだすことにつながります。 図 2. SAP と AWS のモダンデータアーキテクチャ SAP と AWS のパートナー AWS と SAP BTP とのジョイントレファレンスアーキテクチャのシナリオに基づいたソリューションの構築を支援するため、複数の SAP と AWS のパートナーがいます。多くの国で展開している中、 アクセンチュア 、 デロイト 、 PwC 、 IBM 、 Capgemini 、 DxC 、 FAIR Consulting Group 、 DalRae Solutions 、 Bourne Digital 、 Citra Solutions などの SAP と AWS のパートナーに、ジョイントレファレンスアーキテクチャをお届けました。これらのパートナーは、ジョイントレファレンスアーキテクチャを利用して、複数の業界やビジネスドメインのお客様が直面する課題を解決することで、その専門知識の幅と深さを発揮できます。 AWS と SAP BTP ジョイントレファレンスアーキテクチャの成功事例 1/東南アジアのある資源会社は、データからタイムリーでインサイトを得ることに苦労しており、複数の異なるソースからのデータを統合することに多大な工数をかけていました。また、一部のデータソースが社外のアプリケーションやシステムに存在するため、データガバナンスとセキュリティも懸念事項となっています。お客様のデジタルトランスフォーメーション取り組みはアクセンチュアが支援しました。アクセンチュアは、お客様の課題の解決及び、データからより質の高いインサイト、透明性と価値を得て、業務の生産性と効率性を向上させるための支援を行っています。 アクセンチュアは、AWS と SAP BTP ジョイントレファレンスアーキテクチャをベースとして、カスタマイズされたソリューションを構築することで、この東南アジアの資源会社の目標達成を支援しています。ソリューション立ち上げ時のパートナーとして、アクセンチュアは AWS とSAP BTP ジョイントレファレンスアーキテクチャの開発とフィードバックに貢献しています。アクセンチュアは、スモールスタートで目的に合った設計を行うことで、お客様の投資収益率を最大化し、TCO を削減することを目指しています。これにより、ソリューションの柔軟性、拡張性、将来性を高め、段階的に機能を追加することで、さらに価値を高められます。 この事例は、AWS と SAP BTP のジョイントレファレンスアーキテクチャがAWSと SAP BTP 両方の技術の利点と価値を最大化し、参考可能なアーキテクチャ設計図とガイドラインをお客様に提供できている証拠です。AWS とSAP BTP を活用しお客様のための価値提供へのコミットメントにより、アクセンチュアは AWS Partner of the Year 2022 と SAP Asia Pacific Japan Award for Partner Excellence 2022 for SAP BTP を受賞しました。 2/ あるコンシューマー製品のメーカー ( FCMG ) は、販売パートナーからのフィードバックに基づき、自社のプロセスは複雑で不透明であり、価格・クレジット・製品デリバリー情報に関するコミュニケーションが不十分である課題を発見しました。この会社は、顧客中心になるために改善するために、販売パートナーとの取引プロセスを簡素化する必要があると判断しました。 カスタマーエクスペリエンスを改善するために、FAIR コンサルティンググループ ( FAIR ) が支援しました。FAIR は、SAP BTP と AWS サービスを使用したクラウドベースのソリューションを導入し、お客様の業務の整理や効率化することに成功しました。完全統合された「 Inquiry-to-cash 」（問い合わせから、見積もり、注文と契約、顧客専用の価格設定、とアカウントと支払いまでのプロセス）と「 Cash-to-service 」（クレーム、クレジット、リベート、資産管理のプロセス）のポータルなど、組織のデジタル化要件に沿った性能向上、自動化やセルフサービス機能を提供できました。 FAIR の統合アクセラレーター や標準化された会計・財務・販売・サービスプロセスを活用することで、お客様の業務が簡素化され、顧客とのつながり方が変わりました。その結果、手作業で入力される注文数が 30％ 減少し、収益の増加、業務の簡素化、顧客とのコミュニケーションの改善につながりました。これは、優れた性能性や自動化機能に加え、リアルタイムで簡単にアクセルできるユーザーインターフェースによって実現されました。 FAIR は、エクスペリエンスデザイン、SAP カスタマーエクスペリエンス、システム連携、AWS および SAP BTP、SAP クラウド移行などのコンサルティングサービスを提供しています。FAIR は SAP ゴールドパートナーおよびAWS パートナーです。AWS および SAP BTP ジョイントレファレンスアーキテクチャを対応できるパートナーとして、FAIR は SAP と AWS を高度なサービスに活用し、革新的なカスタマーエクスペリエンスを提供するための信頼できるアドバイスや導入サービスを提供しています。 結論 このブログでは、SAP への投資から価値を更に引き出すための AWS と SAP BTP ジョイントレファレンスアーキテクチャについて説明しました。これにより、ベストプラクティスと適切なソリューションや適切なツールを使用して、新しいビジネスチャンスやビジネス価値を創出できます。以下は、AWS と SAP BTP サービスによるモダナイゼーションの旅を開始するのに役立つ参考リソースです。 AWS と SAP BTP : SAP ERP のクラウド化からさらなる価値を生み出す SAP Open Connectors を使用した SAP システムと AWS サービスの統合 SAP HANA Cloud が ARM ベースの AWS Graviton プロセッサをサポート SAP Business Technology Platform を使用した SAP システムと AWS サービスの統合 SAP Data Warehouse Cloud と Amazon SageMaker 2.0 を使用した統合機械学習 SAP TechEd 2022 – ジョイントレファレンスアーキテクチャで SAP への投資の価値を高める [DT200] AWS re:Invent 2022 – SAP ジョイントレファレンスアーキテクチャャセッションとパートナー表彰 SAP on AWS 、 AWS 上のデータレイク の詳細については、 AWS 製品ドキュメント 、 SAP BTP ユースケースレポジトリ 、 SAP Discovery Center – Services 、 SAP Discovery Center – Missions をご参照ください。 SAP と AWS とのパートナーシップについて SAP と AWS は、10 年以上にわたって何千もの共同顧客を持つ戦略的関係を築いてきました。ジョイントレファレンスアーキテクチャと結合されたビジネス能力は、2 つの強力なエンジニアリング組織を結集してイノベーションを推進し、持続可能でインテリジェントな企業になるためのお客様のジャーニーをサポートするという点で重要な意味を持っています。実際、SAP はネットゼロカーボンにコミットし The Climate Pledge に署名され、SAP は 2030 年までのサステナビリティへのコミットメント を加速させています。 SAP on AWS のディスカッションに参加 お客様のアカウントチームと AWS サポートチャンネルに加えて、私たちは最近、re:Post – A Reimagined Q&A Experience for the AWS Community を開始しました。SAP on AWS ソリューションアーキテクトチームは定期的に SAP on AWS トピックを確認し、お客様やパートナーを支援するための議論や質問にお答えしています。もしご質問がサポート対応範囲外である場合、 re:Post に参加し、コミュニティのナレッジベースを追加することをご検討ください。 クレジット AWS と SAP BTP ジョイントレファレンスアーキテクチャは、パートナーを含む  SAP と AWS のパートナーシップと貢献の結果です。次のチームメンバーの貢献に感謝します：Nitin Joshi, Raymond Ho, RJ Bibby, Spencer Martenson, Derek Ewell, Anil Nallamotu, Marius Batrinu, Leo An, Mattia Colagrossi, Barry Hodges, Henry Victor, Ashok Munirathniam Nagichetty, Marin Videnov, Andrew Song, Chris Cormack。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

ライブストリーミングは、インタラクティブなライブ動画エクスペリエンスを通して、顧客を顧客のお気に入りのインフルエンサーやブランドにつなぐ方法としてますます一般的になっています。AWS のお客様である DeNA と ルーター は、フルマネージドのライブストリーミングソリューションである Amazon Interactive Video Service (Amazon IVS) を活用して、ターゲットの視聴者向けに魅力的なライブストリームとインタラクティブな動画エクスペリエンスを構築しています。 3 月には、ステージというリソースを使用して、インタラクティブなエクスペリエンスをより柔軟に構築できるように、 ライブストリームでの複数のホストに対する Amazon IVS のサポート が導入されました。ステージは、参加者がリアルタイムで音声と動画をやり取りできる仮想空間です。 ただし、視聴者を引き付け、全体的なエクスペリエンスを向上させるためにレイテンシーが重要な要素であることは変わりありません。レイテンシーが短いほど、ライブの視聴者と直接かつパーソナルな方法でつながることができます。これまで、Amazon IVS はステージを介して最大 12 のホストでリアルタイムのライブストリーミングをサポートしていました。チャンネル経由の視聴者のレイテンシーは約 3～5 秒でした。このレイテンシーギャップは、より多くの視聴者を対象とした直接的で魅力的なインタラクティブなエクスペリエンスを構築する際の障害となります。 Amazon IVS リアルタイムストリーミングの概要 本日、Amazon IVS Real-Time Streaming で、1 つのステージから最大 12 のホストで 10,000 人の視聴者にリアルタイムのライブストリームを配信できるようになったことに加えて、ホストから視聴者までのレイテンシーが 300 ミリ秒以下になったことをお伝えできることを嬉しく思います。 この機能により、ソーシャルメディアアプリケーションや、レイテンシーの影響を受けやすいオークションなどのユースケース向けに、インタラクティブな動画エクスペリエンスを構築する機会が広がります。 視聴者にリアルタイムレイテンシーを提供するために妥協する必要がなくなりました。複数の AWS サービスや外部ツールを使用するなどの代替策は必要ありません。一元化されたサービスとして Amazon IVS を使用するだけで、リアルタイムのインタラクティブなライブストリームを配信できます。この機能の使用を開始するためにアカウントで何かしらの要素を有効にする必要はありません。 Amazon IVS Broadcast SDK を使用したリアルタイムストリーム配信 リアルタイムストリームを配信するには、ステージリソースを操作し、iOS、Android、およびウェブで利用できる Amazon IVS Broadcast SDK を使用する必要があります。ステージを使用すると、参加者が視聴者またはホストとして参加できる仮想スペースを作成できます。リアルタイムのレイテンシーは 300 ミリ秒以下です。 ステージを使用して、ホストと視聴者が共にライブでつながるエクスペリエンスを構築できます。例えば、視聴者をホストに招待して他のホストを質疑応答に参加させること、歌のコンクールを開催すること、またはトークショーに複数のゲストを招待することができます。 ステージリソースの使用を開始する方法の概要については、「 Amazon IVS を利用してライブストリームに複数のホストを追加する方法 」を参照してください。全体的なフローとステージリソースの操作方法について簡単に復習しておきましょう。 まず、ステージを作成する必要があります。これはコンソールから行うか、Amazon IVS API を使用してプログラムで行うことができます。次のコマンドは、 create-stage API と AWS CLI を使用してステージを作成する方法の例です。 $ aws ivs-realtime create-stage \ --region us-east-1 \ --name demo-realtime \ { "stage": { "arn": "arn:aws:ivs:us-east-1:xyz:stage/mEvTj9PDyBwQ", "name": "demo-realtime", "tags": {} } } 参加者がホストまたは視聴者として参加できるようにするステージリソースの重要な概念は、参加者トークンです。参加者トークンは、参加者がステージを公開またはサブスクライブできるようにする承認トークンです。 create-stage API を使用している場合は、カスタムユーザー ID と表示を含む 属性 を使用して参加者トークンを生成し、追加情報を追加することもできます。API はステージの詳細と参加者トークンを返します。 $ aws ivs-realtime create-stage \ --region us-east-1 \ --name demo-realtime \ --participant-token-configurations userId=test-1,capabilities=PUBLISH,SUBSCRIBE,attributes={demo-attribute=test-1} { "participantTokens": [ { "attributes": { "demo-attribute": "test-1" }, "capabilities": [ "PUBLISH", "SUBSCRIBE" ], "participantId": "p7HIfs3v9GIo", "token": "TOKEN", "userId": "test-1" } ], "stage": { "arn": "arn:aws:ivs:us-east-1:xyz:stage/mEvTj9PDyBwQ", "name": "demo-realtime", "tags": {} } } create-stage API に加えて、API を使用して参加トークンをプログラムで生成することもできます。現在、参加トークンには PUBLISH と SUBSCRIBE という 2 つの属性値があります。 参加者をホストに招待する必要がある場合、参加トークンを作成するときに PUBLISH 属性を追加する必要があります。 PUBLISH 属性を使用すると、ホストの動画と音声をストリームに含めることができます。 参加トークンを生成する方法の例を次に示します。 $ aws ivs-realtime create-participant-token \ --region us-east-1 \ --capabilities PUBLISH \ --stage-arn ARN \ --user-id test-2 { "participantToken": { "capabilities": [ "PUBLISH" ], "expirationTime": "2023-07-23T23:48:57+00:00", "participantId": "86KGafGbrXpK", "token": "TOKEN", "userId": "test-2" } } 参加トークンを生成したら、WebSocket メッセージなどを使用して該当するクライアントに配布する必要があります。次に、Amazon IVS Broadcast SDK を使用するクライアントアプリケーション内で、この参加者トークンを使用して、ユーザーがホストまたは視聴者としてステージに参加できるようすることができます。ステージリソースの操作方法の詳細については、 iOS または Android 用のサンプルデモ、および リアルタイムデモ用のサーバーレスアプリケーション を参照してください。。 この時点で、ステージを使用して 10,000 人の視聴者にリアルタイムのライブストリームを配信できます。より多くの視聴者向けにストリームを拡張する必要がある場合は、ステージをチャンネルの入力として使用し、Amazon IVS の低レイテンシーストリーミング機能を使用できます。チャンネルを使用すれば、単一のソースから 5 秒以下の低レイテンシーで、同時実行性の高い動画を数百万人規模の視聴者に配信できます。ステージをチャンネルに公開する方法の詳細については、iOS、Android、ウェブの情報を含む Amazon IVS Broadcast SDK のドキュメントのページを参照してください。 Amazon IVS Real-Time Streaming 機能の階層型エンコーディング機能 エンドユーザーは高品質のライブストリームを求めています。ただし、ライブストリームの品質は、ネットワーク接続の状態やデバイスのパフォーマンスなど、さまざまな要因に左右されます。 最も一般的なシナリオは、最適な視聴構成以上の単一バージョンの動画を視聴者が受け取ることです。例えば、ホストが高品質の動画を制作できれば、接続が良好な視聴者はライブストリームを楽しむことができますが、接続速度が遅い視聴者の場合は読み込みに遅延が生じるだけでなく、動画を視聴できなくなることもあります。ただし、ホストが低画質の動画しか制作できない場合、接続が良好な視聴者は最適な動画が得られず、接続速度が遅い視聴者には望ましい視聴エクスペリエンスが提供されます。 この問題に対処するため、今回の発表では、Amazon IVS Real-Time Streaming 機能の階層型エンコーディング機能もリリースされました。ステージに公開すると、Amazon IVS は階層化されたエンコーディング (サイマルキャストとも呼ばれます) を使用して複数のバリエーションの動画と音声を自動的に送信します。その結果、視聴者はネットワークの状態に応じて受信可能な最高の品質でのストリームの視聴を継続できます。 お客様の声 プライベートプレビュー期間中、お客様から Amazon IVS Real-Time Streaming について多くのフィードバックをいただきました。 Whatnot は、コレクターや愛好家がコミュニティとつながり、お気に入りの商品を売買できるライブストリームショッピングプラットフォームおよびマーケットプレイスです。「ライブ動画オークションをグローバルコミュニティに拡大することは、私たちの主要なエンジニアリングの課題の 1 つです。リアルタイムのレイテンシーを確保することは、エキサイティングなオークションエクスペリエンスの整合性を維持するための基盤です。Amazon IVS Real-Time Streaming を活用することで、自信を持って業務を世界中にスケールアウトし、ウェブプラットフォームであるかモバイルプラットフォームであるかに関係なく、ユーザーベース全体でシームレスで品質の高いリアルタイム動画エクスペリエンスを保証できます」と Ludo Antonov 氏 (VP of Engineering) は語っています。 今すぐ利用可能 Amazon IVS Real-Time Streaming は、Amazon IVS を利用できるすべての AWS リージョンで利用できます。Amazon IVS Real-Time Streaming を使用する場合、ホストまたは視聴者が参加者としてステージリソースに接続している間、時間単位の料金が請求されます。 Amazon IVS’s Real-Time Streaming と低レイテンシーストリーミング機能のメリット、ユースケース、使用を開始する方法、料金の詳細については、 Amazon IVS のページ を参照してください。 ストリーミングをお楽しみください！ –  Donnie 原文は こちら です。

8月2日、AWS でのみ利用可能なカスタム第 4 世代インテル Xeon スケーラブルプロセッサを搭載した Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex および M7i インスタンスをリリースしました。これらのインスタンスは、クラウド内の同等のインテルプロセッサの中で最高のパフォーマンスを提供します (他のクラウドプロバイダーが利用するインテルプロセッサよりも最大 15% 高速)。M7i-Flex インスタンスは、最も一般的な 5 つのサイズで利用でき、多くのワークロードにおいて M6i インスタンスよりも最大 19% 優れた料金パフォーマンスを実現するように設計されています。M7i インスタンスは 9 つのサイズで利用可能であり (2 つのサイズのベアメタルインスタンスが開発中です)、前世代のインテル搭載インスタンスよりも 15% 優れた料金パフォーマンスを提供します。 M7i-Flex インスタンス M7i-Flex インスタンスは、M7i インスタンスの低コスト版であり、5% 高い料金パフォーマンスを提供し、5% 低い料金でご利用いただけます。これらは、すべてのコンピューティングリソースを十分に活用していないアプリケーションに最適です。M7i-Flex インスタンスは、CPU の 40% のベースラインパフォーマンスを提供し、95% の確率でフル CPU パフォーマンスまでスケールアップできます。M7i-Flex インスタンスは、ウェブおよびアプリケーションサーバー、仮想デスクトップ、バッチ処理、マイクロサービス、データベース、エンタープライズアプリケーションなどの汎用ワークロードの実行に最適です。現在、旧世代の汎用インスタンスを使用している場合は、アプリケーションやワークロードに変更を加えることなく、M7i-Flex インスタンスを採用できます。 M7i-Flex インスタンスの仕様を次に示します。 インスタンス名 vCPU メモリ ネットワーク帯域幅 EBS 帯域幅 m7i-flex.large 2 8 GiB 最大 12.5 Gbps 最大 10 Gbps m7i-flex.xlarge 4 16 GiB 最大 12.5 Gbps 最大 10 Gbps m7i-flex.2xlarge 8 32 GiB 最大 12.5 Gbps 最大 10 Gbps m7i-flex.4xlarge 16 64 GiB 最大 12.5 Gbps 最大 10 Gbps m7i-flex.8xlarge 32 128 GiB 最大 12.5 Gbps 最大 10 Gbps M7i インスタンス 最大のインスタンスサイズや高い CPU を継続的に必要とする大規模なアプリケーションサーバーやデータベース、ゲームサーバー、CPU ベースの機械学習、動画ストリーミングなどのワークロードの場合、M7i インスタンスを使用することで、高い料金パフォーマンスの恩恵を享受できます。 M7i インスタンスの仕様を次に示します。 インスタンス名 vCPU メモリ ネットワーク帯域幅 EBS 帯域幅 m7i.large 2 8 GiB 最大 12.5 Gbps 最大 10 Gbps m7i.xlarge 4 16 GiB 最大 12.5 Gbps 最大 10 Gbps m7i.2xlarge 8 32 GiB 最大 12.5 Gbps 最大 10 Gbps m7i.4xlarge 16 64 GiB 最大 12.5 Gbps 最大 10 Gbps m7i.8xlarge 32 128 GiB 12.5 Gbps 10 Gbps m7i.12xlarge 48 192 GiB 18.75 Gbps 15 Gbps m7i.16xlarge 64 256 GiB 25.0 Gbps 20 Gbps m7i.24xlarge 96 384 GiB 37.5 Gbps 30 Gbps m7i.48xlarge 192 768 GiB 50 Gbps 40 Gbps 各 M7i インスタンスには最大 128 個の EBS ボリュームをアタッチできます。比較のためにお伝えすると、M6i インスタンスでアタッチできる最大ボリューム数は 28 個です。 また、2 つのサイズのベアメタル M7i インスタンスを起動する準備も進めています。 インスタンス名 vCPU メモリ ネットワーク帯域幅 EBS 帯域幅 m7i.metal-24xl 96 384 GiB 37.5 Gbps 30 Gbps m7i.metal-48xl 192 768 GiB 50.0 Gbps 40 Gbps ビルトインアクセラレーター Sapphire Rapids プロセッサには 4 つの内蔵アクセラレーターが含まれており、それぞれが特定のワークロードのためにハードウェアアクセラレーションを提供します。 Advanced Matrix Extensions (AMX) – x86 命令セットに対するこの拡張機能のセットは、深層学習と推論を改善し、自然言語処理、レコメンデーションシステム、画像認識などのワークロードをサポートします。この拡張機能は、INT8 または BF16 の値の 2 次元行列に対する高速乗算の演算を提供します。詳細については、「 Intel AMX Instruction Set Reference 」の第 3 章をご覧ください。 インテル Data Streaming Accelerator (DSA) – このアクセラレーターは、CPU、メモリ、キャッシュ、ネットワークデバイス、ストレージデバイス間の一般的なデータ移動タスクをオフロードして、ストリーミングデータの移動と変換オペレーションを改善することにより、ストレージ、ネットワーキング、およびデータを多用するワークロードのために高いパフォーマンスを実現します。詳細については、「 Introducing the Intel Data Streaming Accelerator (Intel DSA) 」をお読みください。 インテル In-Memory Analytics Accelerator (IAA) – このアクセラレーターは、データベースと分析ワークロードをより高速に実行し、電力効率を向上させる可能性を秘めています。非常に高いスループットでのインメモリ圧縮、解凍、暗号化、および一連の分析プリミティブは、インメモリデータベース、オープンソースデータベース、 RocksDB や ClickHouse などのデータストアをサポートします。詳細については、「 Intel In-Memory Analytics Accelerator (Intel IAA) Architecture Specification 」をお読みください。 インテル QuickAssist Technology (QAT) – このアクセラレーターは、暗号化、復号、圧縮をオフロードし、プロセッサコアを解放して、電力消費を削減します。また、単一のデータフローでの圧縮と暗号化のマージもサポートします。詳細については、まずは「 Intel QuickAssist Technology (Intel QAT) Overview 」をご覧ください。 これらのアクセラレーターの中には、特定のカーネルバージョン、ドライバー、および/またはコンパイラの使用が必要なものもあります。 Advanced Matrix Extensions は、すべてのサイズの M7i および M7i-Flex インスタンスでご利用いただけます。インテル QAT、インテル IAA、およびインテル DSA アクセラレーターは、 m7i.metal-24xl および m7i.metal-48xl インスタンスで利用可能になる予定です。 詳細 M7i-Flex および M7i インスタンスに関して留意すべき点がいくつかあります。 リージョン – 新しいインスタンスは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用可能であり、2023 年中に他のリージョンでも利用可能になる予定です。 購入オプション – M7i-Flex および M7i インスタンスは、オンデマンド、リザーブドインスタンス、Savings Plan、およびスポットの形式でご利用いただけます。M7i インスタンスは、専有ホストおよび専有インスタンスの形式でもご利用いただけます。 – Jeff ; 原文は こちら です。

AWS がプライムデーを実現する方法についてお話しする私の毎年の伝統の一部として、いくつかのチャートトップのメトリクスを共有できることを嬉しく思います ( 2016 年 、 2017 年 、 2019 年 、 2020 年 、 2021 年 、および 2022 年 の過去の投稿も参照してください)。 今年は、私の趣味で使う 小型ボール盤 、3D プリンター用の フィラメント 、そして パイプ用点滴灌漑チューブ穴パンチ などを購入しました。また、孫のためにとても素敵な アルファベットブロック の本も数冊購入しました。 公式発表 によると、プライムデーの初日は、Amazon と個人出品者にとって史上最大の売り上となり、3 億 7,500 万点以上の商品が購入されました。 数字で見るプライムデー 例年と同様に、プライムデーでは AWS が活用されました。最も興味深く、驚異的なメトリクスをいくつか紹介します。 Amazon Elastic Block Store (Amazon EBS) – Amazon プライムデーのイベントでは、増分 163 ペタバイトの EBS ストレージ容量が割り当てられ、1 日あたり最大 15 兆 3,500 億件のリクエストと 764 ペタバイトのデータ転送が発生しました。EBS のピーク使用量の増加は前年に比べてわずか 7% でしたが、 Amazon Elastic Compute Cloud (Amazon EC2) の AWS Graviton ベースのインスタンスを使用したワークロード最適化を始めとする効率化に向けた取り組みによって1 日あたりのトラフィック量は 35% 増加しました。視覚的に比較すると次のようになります。 AWS CloudTrail – AWS CloudTrail は 2023 年のプライムデーをサポートするために 8,300 億件を超えるイベントを処理しました。 Amazon DynamoDB – DynamoDB は、 Alexa 、 Amazon.com サイト、そしてすべての Amazon フルフィルメントセンター など、トラフィックの多い多数の Amazon の施設やシステムを支えています。プライムデーの期間中、これらのソースは DynamoDB API に対して何兆もの呼び出しを行いました。DynamoDB は高可用性を維持しながら、1 桁のミリ秒のレスポンスを提供し、1 秒あたり 1億 2,600 万リクエストでピークに達しました。 Amazon Aurora – プライムデーでは、Amazon Aurora の PostgreSQL 互換エディションと MySQL 互換エディションを実行する 5,835 個のデータベースインスタンスが 3180 億トランザクションを処理し、2,140 テラバイトのデータを保存し、836 テラバイトのデータを転送しました。 Amazon Simple Email Service (SES) – Amazon SES は 2023 年のプライムデー期間中に 2022 年よりも 56％ 多い E メールを Amazon.com に送信し、これらの E メールの 99.8% をお客様に配信しました。 Amazon CloudFront – Amazon CloudFront は、1 分あたり 5 億件を超える HTTP リクエストのピーク負荷を処理し、プライムデー期間中には合計 1 兆件を超える HTTP リクエストを処理しました。 Amazon SQS – プライムデー期間中、Amazon SQS は、ピーク時に毎秒 8,600万件のメッセージを処理することにより、新しいトラフィック記録を樹立しました。これは、SQS が 1 秒あたり 7,050 万件のメッセージをサポートした 2022 年のプライムデーに比べて 22% の増加です。 Amazon Elastic Compute Cloud (EC2) – 2023 年のプライムデー期間中、Amazon は、2,600 を超えるサービスのために正規化された AWS Graviton ベースの Amazon EC2 インスタンスを使用しました。その数は 2022 年の 2.7 倍に上りました。より多くの Graviton ベースのインスタンスを使用することで、Amazon は消費電力を最大 60% 削減しながら、必要なコンピューティング容量を確保することができました。 Amazon Pinpoint – Amazon Pinpoint は、2023 年のプライムデー期間中に膨大な数の SMS メッセージをお客様に送信しました。配信成功率は 98.3% でした。 スケールする準備 毎年同じメッセージを繰り返します。厳密な準備は、プライムデーやその他の大規模イベントの成功の鍵です。同様のチャートトップイベントの準備をしている場合は、 AWS Infrastructure Event Management (IEM) を活用することを強くお勧めします。IEM エンゲージメントの一環として、私の同僚は、自信を持ってイベントを実行するのに役立つアーキテクチャおよび運用上のガイダンスを提供します。 – Jeff ; 原文は こちら です。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みについて、執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。 現行のスマートメーターシステムにおける方向性の検討 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半) で記載した現行のスマートメーターシステムの課題への対応として、 IT 分野における技術動向として広く進んできている AWS を中心としたクラウド技術の利用が選択肢になると考えました。クラウドを活用することで、オンプレミス設備においては避けられない、サーバハードウェアの保守切れに伴う「ハードウェアのリプレース」が、ほぼすべて不要になり、関連する業務の大幅な軽減が見込まれます。 また、システム負荷の増加に伴うサーバ増強の対応でも、クラウド活用の場合では、 GUI 上でのリソース設定だけでサーバリソースの変更ができ、また、設計次第ではオートスケール機能によりサーバのスケールアウトさえも考慮不要となります。さらに、クラウド上にデータを配置していくことで、多様なデータアナリティクスサービスも俊敏に利用できるため、柔軟かつ高度なデータ利活用の拡大も実現できます。 加えて、検討の素地として、当社の親会社である関西電力では、クラウド市場拡大の動向も踏まえてその活用に向けた調査や適用性に関わる技術検証を完了し、その結果、 AWS の標準採用を既に決定するなどクラウドの導入・利用について意思決定されていたことが挙げられます （※ 1 ） 。 （※ 1 ） AWS Summit 2022 「関西電力のデジタルトランスフォーメーションを支えるクラウド標準化・ガイドライン策定取組と AWS 活用事例」 このような背景もあって、スマートメーターシステムにおけるオンプレミス環境の様々な課題解決に向けて、クラウド活用の調査、検討を開始することは自然な流れでした。 クラウド化に関わる社内意見交換 先述のような背景から、スマートメーターシステムのクラウド化について技術調査、検討を進めることとなりましたが、当初、社内にはクラウドに対して漠然とした不安感を感じる意見が根強くありました。オンプレミスで設備構築するとともに業務スキームを整備することで、 10 年以上にわたって安定稼働を果たしてきた状況において、敢えてクラウドを選択することに対する不安感は当然のものであり、メリット・デメリットを含めて丁寧に意見交換を進めることとしました。 漠然とした不安感については、例えば、「クラウドってセキュリティ面は大丈夫なのか？」、「基幹業務システムでも使えるのか？」、「事業撤退などの懸念は無いか？」、「外資特有の強引な値上げ懸念は無いのか？」、「品質は担保されるのか？」、「保守や技術サポートは信頼に足るのか？」などがありました。漠然とした不安や疑問に対して、クラウドサービスへの知識や業界動向に関わる情報、 AWS や各社の事例などを収集し、事実確認を進めて、情報共有を通して関係者の理解を深め、検討初期段階における不安感を払拭していきました。また、セキュリティ面やクラウド活用の基本的な妥当性については、「システム構築に当たってのセキュリティ確保はクラウド利用者の設計次第であり、確実に実現可能」であること、「金融機関や社会インフラに関連する企業における基幹業務システムでも AWS 採用事例が拡大しており、技術面での導入障壁はない」など、社内で認識共有ができ、地に足の着いた検討と意見交換ができる状況が醸成され、その後はクラウド化に関する踏み込んだディスカッションが進みました。 例えば、 「インターネットからの侵入リスクに対してクラウドでは具体的にどのように対処するのか？」、 「クラウドでは障害復旧が長時間化しないか？当社専用のハードウェアの方が、障害復旧が早いのではないか？」、「システムをクラウドに移すことでネットワークコストが高止まりし、全体として高コストにならないか？」といった様々な疑問に対して論点化し意見交換しました。各論点に対して、 AWS クラウド導入事例を参考に情報収集した上で、双方の立場の意見を丁寧に整理し、侃々諤々の議論を継続しました。 その結果、セキュリティ面に加えて、可用性でもクラウドはオンプレミスと比べて同等以上の品質を確保できるという認識共有が図れました。ネットワークコスト面に関する検討では、クラウドとのネットワーク連携回線は単体ではコスト増になるのは明白であり、単体評価するのではなく、システム全体の TCO の観点から総合的に評価する必要性を明確にしました。次に、クラウドサービスの選択に議論が移りましたが、先述の通り関西電力で AWS を標準クラウドとして採用済であったこと、その実績評価や、市場シェア、コスト、サービス開発とその提供における顧客志向な考え方、サポート面、技術情報の入手しやすさなど総合的に検討した結果、当社も AWS を採用する方向性で認識共有されました。 以上のような、多岐にわたるクラウド化に関わる社内の意見交換も踏まえて、 AWS クラウドへの移行について、技術面を含めた社内理解が醸成され、方向性も固まっていきました。 コスト試算と経済性評価について スマートメーターシステムの AWS 移行に関わる概算コスト算定や経済性評価時に注力して意識したことは、クラウド化に伴い「増加するコスト」「減少するコスト」の種別を洗い出すことでした。このとき、当社グループ内の先行事例と実績を参考にしています。特に、当社先行事例として、IaaS （ Infrastructure as a Service ） のみならず PaaS（ Platform as a Service ） を活用することでクラウドのメリットである柔軟性、可用性の向上を実現しながら、コスト削減を実現できているという点を重要視しました。 これを支える仕組みとして、 AWS のマネージドサービスがあります。マネージドサービスを活用するメリットのもう1つの側面として、クラウド利用は従量課金（使った分だけ支払う）の考え方を享受できることがあります。従来のハードウェア一括調達のようにリソース消費量が最大となる瞬間を見据えた調達が不要となったことで、コスト削減の一助となりました。 一方、机上整理では評価しきれない項目もありました。具体的には、現環境での機能をそのままクラウドに実装することはできるものの、 AWS 移行に合わせて実装方法自体を見直すことで、コスト面でもより大きな効果が得られる可能性のある項目です。当社では、これらの項目については整理、認識したものの、セキュリティ面を含めた技術的な実現性の見極めに時間を要することから、検討の初期段階でのコスト評価対象からは一旦外すこととしました。 こうした一定の考え方に沿ったコスト概算の結果、コストメリットが必ず確保できるという見通しを立てることができました。 当初の検討結果を踏まえた大きな方向性の判断 このような、多岐にわたるクラウド化に関する調査検討や、それに基づく社内意見交換も踏まえて、2022 年 4 月に、現行スマートメーターシステムについて、「コスト削減を前提に AWS 移行を推進する」という方向性について経営判断を行うに至りました。 プロジェクト推進体制の確立と検討加速 「コスト削減を前提に AWS 移行を推進する」という前提条件に沿って本プロジェクトを推進するにあたって、「経済合理性を確実に達成する」という点は、 AWS 移行検討の深化にあたり非常に重要なテーマとなりました。 経済合理性を確実に確保可能なクラウド移行を実現するために、このフェーズから AWS Professional Services を、技術と業務の両面におけるプロジェクトマネジメントを主体的に推進する立場に招き入れ、当社と同じ立場でサブシステムを所管する各システムベンダーへの全体統括を行い、プロジェクト推進を加速させることとしました。 それ以降のプロジェクト推進にあたっては、 AWS 移行の取り組みに係る基本スタンスや実装方針を明らかにし、それを各システムベンダーに明確にメッセージングし、それに基づいてベンダー各社が検討推進することが重要と考え、基本スタンスの整理からメッセージングの内容に至るまで、踏み込んで AWS Professional Services と意見交換を重ねました。 特にクラウドへの移行方針については精力的に検討を実施しました。例えば、現行システムの AWS 移行について、検討当初はアプリケーションやミドルウェアに極力手間をかけずに、サーバを単にクラウド上に移行する考え方がコスト面でもリードタイムでも最適ではないかと考えていました。しかし、サーバを単にクラウド上に移行する “クラウドリフト” ではなく、マネージドサービスを積極活用して AWS 上の仕組みに最適化する ”クラウドシフト” という考え方で取り組む方が、クラウド固有のメリットを享受できる上に、維持運用性の向上や可用性の確保に関する投資を含めて高い経済合理性が確保可能だろうという結論に達しました。（ 図 1 ） 図 1 マネージドサービスの活用による構築・運用の負荷軽減 つまり、従来、オンプレミスで自らサーバ環境を整備してきたアプリケーションを AWS 上に従来同様に実装することは止め、クラウドサービスで代替できるものは積極的にサービス利用に乗り換えるという実装方針としました。 この実装方針を実現するためには、現行システムの改修が発生します。この過程において、マネージドサービスの積極採用の技術検討を加速させることに並行して、不要となった機能要件を洗い出して、それを踏まえたシステム要件の整理と見直し、次世代システムへの移行を意識したシステム改修の方向性を整理しました。このような実装対応方針を明確に打ち立ててベンダー各社とも意思統一を図ったうえで、クラウドシフトに向けた設計フェーズに踏み込むこととなりました。 次世代システムにおける当社の検討スタンス 現行スマートメーターシステムでの AWS 採用検討と並行して、次世代スマートメーターシステムの検討も進みました。システム開発観点において、現行システムで AWS 採用検討が進む中で次世代でもこれを否定するのではなく、より一層のクラウドメリットを享受する方向で検討を進めました。特に、次世代スマートメーターシステムではカーボンニュートラルに向けた環境変化に対応すべく、スマートメーターから得られるデータを柔軟に高度利活用した電力レジリエンスの強化、再エネ大量導入に資する配電網の更なる高度化を実現し、お客さまサービスのさらなる向上が必達であるため、これら要件へ着実に対応できる柔軟なシステム開発が必須と考えています。（図 2 ） 図 2 次世代スマートメーターを活用した電力DXの推進 次世代システム開発の方向性 次世代スマートメーターシステムの開発スタンスを実現するために、システム開発ではより近代的なアプローチを採用する方向で社内議論を進めました。スマートメーターシステムとして要求される堅牢なセキュリティ対策と送配電事業継続を支える高いレジリエンスを着実に実現しながら、将来予想される追加業務や要件へ対応できる仕組みを作り上げる必要があります。この思想を実現するためにも、当社の次世代スマートメーターシステムでは、マイクロサービスの考え方を導入し各コンポーネントを疎結合にしながら、機能拡張と障害発生時の影響範囲の極小化を目指しています。 加えて、マイクロサービスを着実に実現するためにも、サーバレスアーキテクチャを導入すると共に、現行システムよりも積極的にマネージドサービスを活用し、運用負荷軽減も狙う方向を打ち出しました。（図 3 ）これら方針を着実に実現しながら、クラウドサービスの最先端技術を余すことなく活用していくことで、より一層堅牢かつ柔軟なスマートメーターシステムの実現を目指しています。 こうした思想と方針に基づき、当社の次世代スマートメーターシステム開発は現在もプロジェクトが進んでいます。 図 3 当社スマートメーターシステム開発の方向性 現行システムと次世代システムのマイグレーション 最後に、現行システムと次世代システムの今後の展望について言及します。当社スマートメーターシステムは 2025 年度時点では、現行システムと次世代システムの並行稼働を予定しています。これは、それぞれに求められる特性が異なることや、次世代スマートメーターをいち早く活用してお客さまサービスの向上を狙うことなどを踏まえて方向付けしたものです。一方、運用負荷を含めた TCO 削減なども思慮し、早い段階で現行システムの次世代システムへのマイグレーション実現を図っていきます。 マイグレーションの方向性検討においても、現行システムを ”クラウドリフト” ではなく、マネージドサービスを積極活用することで AWS 上の仕組みに最適化する “クラウドシフト” という考え方を取り込んで検討してきたことで、次世代システムへの移行を見据えた現行システムの円滑な縮退も視野に入れた仕組みの実現性が見えてきました。 おわりに 今回の寄稿では、当社スマートメーターシステムにおけるクラウド活用の議論の全体像をご紹介しました。 次回以降は、技術的な観点でより詳細に、次世代スマートメーターシステム開発と、現行スマートメーターシステムのクラウドシフトについてご紹介致したいと考えています。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みについて、執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。 はじめに 関西電力送配電株式会社（以降、当社）は送配電事業の一層の中立性を確保するための電気事業法の改正に伴い、2020 年 4 月、関西電力から一般送配電事業を継承し、事業を開始しました。当社が将来目指す姿を描き出し、その姿に向かって自ら変革していく デジタルトランスフォーメーション （ DX ）に全社を挙げて取り組んでいく過程において、この度日本初となる、クラウドを中核としたスマートメーターシステムを開発することを決定致しました （※ 1 ） 。 本取り組みに対するブログは全体で三部作シリーズでお伝えする予定です。今回は第一部として、スマートメーターシステムにおけるクラウドや AWS 採用に関わる意思決定に至る社内の議論経過をお伝えします。次回以降は、 AWS 活用を前提とした次世代スマートメーターシステムの具体的な方向性や取り組みについて、また現行スマートメーターシステム （※ 2 ） のクラウドシフトに関する課題解決の経緯について、ご紹介します。 （※ 1 ） 「 スマートメーターシステムとして日本初となるクラウドを中核としたシステム開発を決定 」（当社のホームページ、 2023/3/31 ） （※ 2 ） 当社の現行スマートメーターは 2023 年 3 月に設置完了。その後、現行スマートメーターの有効期間（ 10 年間）が順次満了することに伴い、 2025 年度より次世代スマートメーターへの置き換えを開始予定。 図 1 当社ホームページのお知らせより抜粋 スマートメーターシステムとは スマートメーターシステムとは、お客さまの電気使用量を、通信網を介して遠隔・自動・定期的に収集・保存するシステムで、スマートメーターと通信ネットワーク、収集したデータを管理するシステム（メーターデータ収集・管理システム）、及び電気使用量にかかる業務を担うシステム（業務システム）により構成されます。スマートメーターは、お客さまの電気使用量を計測・記録する計量部と計測した電気使用量データを上位サーバへ伝送する通信部から構成されます。（図 2 ） 図 2 スマートメーターシステムとは 従前の、毎月一回の目視検針から、 30 分毎の遠隔・自動検針に大きく進歩を遂げただけでなく、スマートメーターからお客さま宅内の端末機器（Home Energy Management System 、Building Energy Management System 等）に電気使用量データを送信することにより、電気使用量が多い時間帯などを把握して、より効果的な省エネが実現可能になりました。 日本全国では 2010 年代前半から導入が開始され、 2020 年代前半に全戸設置が完了する見通しの現行スマートメーターシステムに対して、仕様を見直して機能向上を図った次世代スマートメーターシステムが、2025 年度から導入が開始される予定です。 なお、スマートメーターは、計量器として正確・適正な装置であることを計量部の検定を以って担保しており、この検定の有効期間が 10 年であることから、メーター全数に対してスマートメーターに置き換えていくには、基本的に 10 年の歳月を費やすことになります。 導入経緯と実態 当社では、計量器周辺業務の効率化等を目指し、1990 年代末期から通信方式の研究開発を進めてきました。この開発コンセプトが、後にスマートメーターと呼ばれる汎用的な概念になります。当時は、携帯回線等の通信網のランニングコストが高かったため、自営通信網を主体にして、いかに接続性・信頼性の高い通信ネットワークを構築できるかという点が大きな課題でした。また、当時の計量器は機械式と呼ばれるアナログのものが主流でした。 計量器のスマート化に向けた研究開発に一定のめどが立った 2005 ～ 2006 年に、当社内で議論し、計量器のスマート化に向けた本格検討を開始することになりました。当時はスマートメーターという言葉が存在せず、当社内では計量システムのスマート化を「新計量システム」と呼び、開発を推進しました。当時は計量器の表示を目視確認して検針することや、引っ越し等に伴う送電時には計量器側で作業することが当たり前でしたが、新計量システムに置き換わることにより、これらの業務が大幅に変化するため、数十から百数十人の社内関係者が一堂に介し、議論を積み重ねて、ありたい業務の姿を一つ一つ決めていく議論を繰り返しました。その議論を踏まえ、システム開発としては、 2006 年に開発ベンダーを決定して、システム要件も確定、 2007 年に各ベンダーでの開発を実施し、同年末には通信ネットワークからシステムに至る間のマルチベンダー試験を行い、 2008 年 4 月より試験的導入を開始、 2012 年から全面導入を開始しました。 導入当初は、開発時には想定し得なかった通信ネットワークの通信輻輳の事象など、数多くの新たな課題に直面し、大変な苦労をしましたが、それらを解消することで、着実に新計量システムの信頼性向上を図りました。その後、日本全国においてスマートメーター導入の機運が高まり、2014 年からは当時の電力会社 10 社の本格導入が開始、順次展開され、当社では 2023 年 3 月に全戸導入を完了しています。これまでに当社においては、スマートメーターシステムを活用し、安全かつ確実な検針作業の実現やお客さまの利便性向上、蓄積された電気使用量データに基づいた配電設備形成の合理化などに積極的に取り組んできました。 電気使用量データの利活用 当社では 2012 年からスマートメーターの全面導入を開始し、 2023 年 3 月に全戸への導入を完了しています。導入途上から 30 分毎に収集される電気使用量データの利活用に取り組んでおり、配電設備の正常化や合理化など実践的にデータ利活用を推進してきました。 一方で、後述するように現行スマートメーターシステムは、開発当時にクラウドシステムの概念が無かったためにオンプレミスでデータ収集システムを構築しています。このため、順次拡大するスマートメーターを収容するためのサーバシステムの拡張性に関する課題がありました。また、マルチベンダーによるシステム構築に伴うベンダー間の詳細にわたる仕様調整が必要であり、さらに、ベンダー独自仕様で構成されていることから、ニーズに応じた柔軟なデータの抽出や加工には課題があり、徹底的なデータ利活用の実現にはハードルがありました。この状況の中、昨今のレジリエンス強化に対する関心の高まりや、再生可能エネルギーを始めとする分散型エネルギーリソースの導入拡大の進展等を踏まえて、 2020 年 9 月に資源エネルギー庁が、スマートメーターシステムの高度利用に関する議論の場として次世代スマートメーター制度検討会を設置し、カーボンニュートラル時代に相応しいスマートメーターシステムの新しい仕様や備えるべき新しい機能について議論・検討されました。 現行システムの課題と次世代スマートメーター制度検討会の議論を踏まえて、当社ではスマートメーターから得られるデータを柔軟に高度利活用し、電力ネットワークをご利用いただくお客さまへのサービスレベルアップや社会のレジリエンス向上を図ることを目指し、現行システムと次世代システムを AWS をベースとしたフルクラウドで実現することを決定致しました。（図 3 ） 図 3 現行システムと次世代システムのフルクラウド化 本稿で取り上げるスマートメーターシステム スマートメーターシステムの全体概要は一般的に図 2 の通り、各家庭に設置されたスマートメーター、通信ネットワーク、データを収集・保存するデータセンター、及び関連業務を担う業務系の各種システムで構成されます。 本稿では、AWS 上に構成するシステムに焦点を当てた内容を取り上げますので、本稿においては、図 4 の通り、スマートメーターシステムのうちスマートメーターからのデータ収集を担うヘッドエンドシステム（ Head End System 。以下、 HES ）、ならびに収集されたデータの活用やメーター管理を担うメーターデータマネジメントシステム（ Meter Data Management System 。以下、 MDMS ）に特化して記載します。このため、特に断りの無い限り、本稿では HES と MDMS のみをスマートメーターシステムと表現します。 図 4 本稿で取り上げるスマートメーターシステム 現行のスマートメーターシステムにおける課題 当社では、スマートメーターという言葉が存在しない時代から、新計量システムと呼んで開発を進めてきました。現在のようにスマートメーターのパッケージシステムなど存在していませんので、複数のシステムベンダーの協力を頂き、試行錯誤しながらシステム構成や機能配置を模索してきました。結果として、オンプレミス環境に、ベンダー固有の技術・仕様でシステムを構成し、システムを実現することに成功しています。このシステムの運用開始以降、スマートメーターの設置数量の拡大に伴ってサーバ規模も順次拡大し続けながら、継続的な安定稼働を実現しています。 当社の現行スマートメーターシステムは、こうした経緯で作り上げられたシステムのために、独自 OS や商用データベース、ミドルウェア採用に伴う経済性や将来持続性の課題、システムベンダーへの一元的な委託も背景とした、システムのブラックボックス化、業務処理ロジックの隠匿化などの課題に直面していました。これらの課題は、スマートメーターの 100% 導入完了を受けて、収集される膨大な電気使用量データの高度利活用を指向する当社にとっては、非常に大きな課題となっていました。 また、 10 年かけて導入拡大していくスマートメーターに対して、収容数増加に伴うサーバ数の増大、関連する OS ・ミドルウェアの保守切れ、ライセンス更新、及びサーバリプレース作業が毎年発生していることも大きな課題でした。これらの課題については、その都度、検証作業などが発生するために、経済性の課題だけではなく、当社のサーバ保守関係に従事するメンバーの業務負荷が増大しているという課題でもありました。更に近年では、半導体枯渇によるサーバハードウェア調達納期の遅延など、将来の不確実性も含めた様々な課題が顕在化してきていました。 おわりに 本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「現行のスマートメーターシステムにおける課題まで」をご紹介致しました。後半については、「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (後半) 」をご参照ください。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

AWS ヒーロー プログラムでは、深い技術的専門知識と、他の人がより多くのことを学び、より早く構築できるよう支援したいという情熱を兼ね備えた個人を表彰します。長年にわたり、コミュニティがどのように AWS 上で構築されたソリューションを開発し、デプロイするかについて、トレンドが進化してきました。この影響により、特別なヒーローカテゴリが生まれました。8月1日、注目のセキュリティ分野のリーダーを公式に表彰し、称えることができることを嬉しく思います。 セキュリティは、チームが安全にイノベーションを起こすことを可能にするものというより、インパクトの観点から見られることがよくあります。初代の AWS セキュリティヒーロー は、情報提供と教育を意図して取られる実用的なアプローチが、セキュリティにポジティブな結果をもたらすことを幾度となく示してきました。AWS セキュリティヒーローの最初の仲間たちは、その分野の第一線で活躍する専門家であり、他のユーザーがセキュリティをよりよく理解できるよう手助けすることを共に志しています。 最初の AWS セキュリティヒーローをご紹介します。 Chris Farris 氏 – 米国、アトランタ セキュリティヒーローの Chris Farris 氏は、1994 年から IT 業界に従事しており、主に Linux、ネットワーク、セキュリティに取り組んできました。過去 8 年間、同氏はメディアとエンターテインメント業界のパブリッククラウドとパブリッククラウドのセキュリティに深く関わってきました。その専門知識を活かして、Turner Broadcasting、WarnerMedia、Discovery Communications、PlayOn! Sports でクラウドセキュリティプログラムを構築し、 進化させてきました。現在は主に、クラウドセキュリティの中核となる概念を理解し、中小規模の組織でもクラウドのセキュリティとガバナンスを強化できるよう、ビルダーを教育し、支援することに取り組んでいます。 Gerardo Castro 氏 – ペルー、カヤオ セキュリティヒーローの Gerardo Castro は、Caleidos のセキュリティソリューションアーキテクトです。彼は Medium ブログで技術的な記事を書いたり、サイバーセキュリティについて話したりするのが好きです。また、AWS に焦点を当てた動画、ポッドキャスト、オンラインクラス、ワークショップの作成と指導も行っています。さらに、Castro 氏は中南米の AWS UG セキュリティコミュニティのコミュニティリーダーであり、多くの人々にクラウドでのキャリアをスタートさせ、成長するきっかけを与えてきました。 臼田 佳祐氏 – 日本、千葉県 セキュリティヒーローの 臼田 佳祐 氏は、Classmethod のシニアソリューションアーキテクトであり、CISSP の認定を受けています。また、セキュリティに特化した日本 AWS ユーザーグループ (Security-JAWS) の中核メンバーでもあり、定期的にイベントを開催しています。臼田氏は AWS のセキュリティ関連のマネージドサービスに深い関心を持っており、世界中のすべての AWS アカウントで Amazon GuardDuty を使えるようにすることを提唱しています。 Ray Lin (Chia-Wei Lin) 氏 – 台湾、台北 セキュリティヒーローの Ray Lin 氏は、iFUS System Consultants Ltd. の AWS およびセキュリティコンサルタントであり、一からチームを構築し新製品を開発することに長けています。彼の主な専門分野は、ソフトウェアプロジェクト管理、アジャイル開発、ビジネスおよびシステム分析、SaaS 製品開発、アーキテクチャ設計、サイバーセキュリティ、DevSecOps、AI です。Lin 氏は、特にサイバーセキュリティと安全なアーキテクチャ設計分野で、AWS コミュニティにも多大な貢献をしてきました。知識を共有することに対する彼のコミットメントは、AWS ユーザーグループ台湾へ積極的に参加していることからも明らかです。 吉江 瞬氏 – 日本、横浜 セキュリティヒーローの 吉江 瞬 氏は、野村総合研究所 (NRI) のセキュリティコンサルタントで、2021 年からヒーローになっています。マルチクラウド環境におけるセキュリティの運用設計に関するコンサルティングを行っており、マルチクラウド、クラウドネイティブ、CNAPP、セキュリティオブザーバビリティに関連するテーマに焦点を当てています。また吉江氏は、2013 年に日本の AWS ユーザーグループ (JAWS-UG) に参加し、2019 年から JAWS-UG 東京勉強会を運営しています。 Teri Radichel 氏 – 米国、サバンナ セキュリティヒーローの Teri Radichel 氏は、組織へのクラウドセキュリティトレーニング、侵入テスト、セキュリティ評価という 3 つのサービスを提供するサイバーセキュリティ企業、2nd Sight Lab の CEO です。また、IANS Research を通じて組まれるコンサルティングコールで、顧客のサイバーセキュリティに関する質問に答えている。Radichel 氏は、「Cybersecurity for Executives in the Age of Cloud」という本の著者であり、2016 年からヒーローとして活躍しています。またセキュリティイノベーションが評価され、SANS 2017 Difference Makers 賞を受賞しています。Radichel 氏は GSE を含む 13 のサイバーセキュリティとペンテストの認定を受けています。GSE では、取得時に 2 日間の実地試験に合格する必要がありました。 詳細はこちら 新しいセキュリティヒーローのカテゴリについて詳しく知りたい、またはお近くのヒーローとつながりたいという場合は、 AWS ヒーローのウェブサイト にアクセスするか、「 AWS Heroes Content Library 」(AWS ヒーローコンテンツライブラリ) をご覧ください。 – Taylor 原文は こちら です。

2021 年 6 月、Jeff Barr は AWS イスラエル (テルアビブ) リージョンが間もなく利用可能になることを 発表しました 。本日、3 つのアベイラビリティーゾーンと il-central-1 API 名を備えた AWS イスラエル (テルアビブ) リージョン の一般提供の開始をお知らせします。 新しいテルアビブリージョンでは、アプリケーションを実行し、イスラエルにあるデータセンターからユーザーにサービスを提供するための追加オプションがお客様に提供されます。お客様はイスラエル国内にデータを安全に保存しながら、近隣のユーザーにさらに低いレイテンシーでサービスを提供できます。 AWS イスラエル (テルアビブ) リージョンの AWS のサービス 新しいテルアビブリージョンでは、 C5 、 C5d 、 C6g 、 C6gn 、 C6i 、 C6id 、 D3 、 G5 、 I3 、 I3en 、 I4i 、 M5 、 M5d 、 M6g 、 M6gd 、 M6i 、 M6id 、 P4de (パブリックプレビューのみ)、 R5 、 R5d 、 R6g 、 R6i 、 R6id 、 T3 、 T3a 、 T4g インスタンス、および次のさまざまな AWS のサービスをご利用いただけます:  Amazon API Gateway 、 AWS AppConfig 、 AWS Application Auto Scaling 、 Amazon Aurora 、 Aurora PostgreSQL 、 AWS Budgets 、 AWS Certificate Manager 、 AWS CloudFormation 、 Amazon Cloudfront 、 AWS Cloud Map 、 AWS CloudTrail 、 Amazon CloudWatch 、 Amazon CloudWatch Events 、 Amazon CloudWatch Logs 、 AWS CodeBuild 、 AWS CodeDeploy 、 AWS Config 、 AWS Cost Explorer 、 AWS Database Migration Service 、 AWS Direct Connect 、 AWS Directory Service 、 Amazon DynamoDB 、 Amazon Elastic Block Store (Amazon EBS) 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon EC2 Auto Scaling 、 EC2 Image Builder 、 Amazon Elastic Container Registry (Amazon ECR) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service 、 Amazon ElastiCache 、 AWS Elastic Beanstalk 、 Elastic Load Balancing 、 Elastic Load Balancing – Network (NLB) 、 Amazon EMR 、 Amazon EventBridge 、 AWS Fargate 、 Glacier 、 AWS Health Dashboard 、 AWS Identity and Access Management (IAM) 、 Amazon Kinesis Data Streams 、 Amazon Kinesis Data Firehose 、 AWS Key Management Service (AWS KMS) 、 AWS Lambda 、 AWS Marketplace 、 AWS Mobile SDK for iOS and Android 、 Amazon OpenSearch Service 、 AWS Organizations 、 Amazon Redshift 、 AWS Resource Access Manager 、 Amazon Relational Database Service (Amazon RDS) 、 Resource Groups 、 Amazon Route 53 、 Amazon Virtual Private Cloud (Amazon VPC) 、 AWS Secrets Manager 、 AWS Shield Standard 、 AWS Shield Advanced 、 Amazon Simple Notification Service (Amazon SNS) 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Simple Workflow Service (Amazon SWF) 、 AWS Step Functions 、 AWS Support API 、 AWS Systems Manager 、 AWS Trusted Advisor 、 VM Import/Export 、 AWS VPN 、 AWS WAF 、 AWS X-Ray 。 イスラエルの AWS Israel Ministry of Economic Industry によると、イスラエルはクラウドコンピューティング時代の最前線にあり、「数多くのグローバルスタートアップが輩出されている『スタートアップ国家』として知られています。過去 10 年間にわたって、イスラエルは 2,000 を超えるスタートアップを輩出してきましたが、これらのスタートアップの大部分は Software as a Service (SaaS) 駆動型です。新しいスタートアップが絶えず市場に参入しているため、イスラエルのクラウドテクノロジーが市場で成功を収めることについて、常に大きな期待が寄せられています」。 AWS は 2013 年に AWS Activate プログラムを通じてイスラエルのスタートアップのサポートを開始しました。イスラエルでは、AWS は 8200 EISP 、 F2 Venture Capital – thejunction 、 TechStars などのアクセラレーター組織や、 Entrée Capital 、 Bessemer Venture Partners 、 Pitango 、 Vertex Ventures Israel 、 Viola Group などのベンチャーキャピタル企業と連携して、これらのポートフォリオに含まれている企業の急速な成長をサポートしています。 2014 年、当社はイスラエルに AWS のオフィスと研究開発 (R&D) センターを開設しました。それ以来、Amazon は同国での R&D のプレゼンスを拡大し、現在では Prime Air や Alexa Shopping などを提供するに至っています。 2015 年、AWS はイスラエルのマイクロエレクトロニクス企業である Annapurna Labs を買収しました。同社は、AWS が設計した Graviton プロセッサ 、 AWS Inferentia 、 AWS Trainium チップ、 AWS Nitro System など、AWS 向けの高度なコンピューティング、ネットワーキング、セキュリティ、ストレージテクノロジーを開発してきました。 2018 年、当社は、テクノロジーに焦点を当てたイベントや教育活動を通じてイスラエルのスタートアップ、企業、政府のお客様の成長をサポートするために、 テルアビブの新しいオフィスに拡張しました 。これには、 Floor28 の AWS Experience Tel Aviv が含まれます。現在、Floor28 の AWS Experience Tel Aviv は教育ハブとなっており、AWS に興味のある人なら誰でも、業界イベント、ワークショップ、ミートアップに参加したり、AWS のエキスパートから技術指導やビジネス指導を無料で直接受けたりできます。 2019 年、当社はイスラエルで最初の AWS インフラストラクチャを立ち上げ、 Amazon CloudFront エッジロケーションを開設しました。2020 年には AWS Outposts と AWS Direct Connect をイスラエルに導入し、イスラエルの組織が独自のデータセンターで AWS のテクノロジーを実行し、AWS クラウドとの間での専用接続を確立できるようにしました。 2021 年 4 月、イスラエル政府は Nimbus 契約 の一環として AWS を主要なクラウドプロバイダーに選定したと発表しました。Nimbus フレームワークにより、省庁、教育、医療などの政府部門や、地方自治体が AWS テクノロジーを利用してデジタルトランスフォーメーションを加速できるようになります。 AWS は、 AWS Educate 、 AWS Academy 、 AWS re/Start 、および他の トレーニングおよび認定 プログラムなどのプログラムを通じて、イスラエルの現地のデベロッパー、学生、次世代の IT リーダーのスキルアップに投資し続けています。 AWS Educate および Academy プログラムは、クラウド関連の学習を加速し、イスラエルの今日の学生が将来の仕事に備えるための無料リソースを提供しています。既に AWS Academy プログラムに参加している イスラエルの大学 には、Bar Ilan University、Ben-Gurion University of the Negev、Holon Institute of Technology、Jerusalem College of Technology、University of Haifa が含まれます。また、失業者または不完全雇用者がクラウドキャリアを新たに開始するのを重点的にサポートするために、AWS re/Start を立ち上げました。現在、イスラエルの Appleseeds 、 Sigma Labs Jerusalem 、 Analiza Cyber Intelligence を通じて AWS re/Start プログラムにお申し込みいただけます。 イスラエルの AWS のお客様 イスラエルには、AWS を利用して輝かしい成果を実現している数多くのすばらしいお客様がいます。そのうちの数社を以下でご紹介します。 AI21 Labs – AI21 Labs は、企業が独自の生成系人工知能アプリケーションを構築できるようにする AI21 Studio を通じて、最先端の独自言語モデルを利用できるようにしているほか、同社の消費者向け製品である Wordtune (文脈と意味を理解する初の AI ベースの記述アシスタント) へのアクセスも提供します。AI21 Labs は、言語モデルの Jurassic-2 ファミリーを構築するために、高い費用対効果で効率的に数百の GPU にスケールしました。これらのモデルは、 Elastic Fabric Adaptor (EFA) によってサポートされる Amazon EC2 P4d インスタンス の 400 Gbps の高性能ネットワーキングに基づく分散並列インフラストラクチャを使用してトレーニングされています。 Bank Leumi – Leumi はイスラエルの大手銀行の 1 つで、全国に 200 を超える支店を持ち、AWS を利用して高度な銀行サービスの市場を構築する専門チームを擁しています。Leumi は、サービスを中断することなく、わずか 5 か月間で 16 のオンプレミスアプリケーションを以前の Kubernetes ソリューションから Amazon EKS Anywhere に移行しました。銀行の新しい環境により、デプロイに対する一貫したスケーラブルなアプローチが促進されました。これにより、時間と費用が削減され、イノベーションの速度を向上させることができました。 CyberArk – CyberArk は、ID セキュリティ業界における AWS のパートナーです。CyberArk は、特権アクセス管理を中心として、ビジネスアプリケーション、分散したワークフォース、ハイブリッドクラウドワークロード、および DevOps ライフサイクル全体にわたって、人間またはマシンのいずれであるかを問わず、あらゆる ID のために極めて包括的なセキュリティ SaaS サービスを AWS 上で提供します。CyberArk Identity Security Intelligence は、標的型攻撃に関連する可視性と応答性を高めるために、 AWS CloudTrail Lake と統合しました。また、CyberArk Audit は、セキュリティイベント情報を Amazon Security Lake に提供します。 Ichilov Hospital – Ichilov Hospital の I-Medata Innovation Center は、 AWS Control Tower を利用して、機密性の高い医療データを保護しながら、AWS アカウントの迅速かつ安全な一貫性のある作成を促進しています。また、同センターは Amazon SageMaker を利用して、サイエンティストが COVID-19 患者の悪化を早期に検出するための高度な機械学習モデルを構築、トレーニング、デプロイできるようにしています。同センターは、研究者の生産性を高める能力を維持しながら、AWS 上で機密性の高い医療データを完全に保護することができました。 イスラエルのお客様の事例 をさらにご覧いただけます。 今すぐご利用いただけます 新しいテルアビブリージョンは、お客様のビジネスをサポートする準備ができています。このリージョンで利用可能なサービスの詳細なリストは、 AWS サービスのリスト (リージョン別) でご覧いただけます。 この立ち上げにより、AWS の事業活動の場は、世界各地の 32 の地理的リージョンにおける 102 のアベイラビリティーゾーンに広がりました。また、 カナダ 、 マレーシア 、 ニュージーランド 、 タイ において、12 のアベイラビリティーゾーンと 4 つのリージョンをさらに追加する計画もこれまでに発表しています。 詳細については、「 グローバルインフラストラクチャ 」のページをご覧いただき、ぜひお試しください。そして、イスラエルの AWS サポートの通常のお問い合わせ先にフィードバックをお寄せください。 – Channy P.S.私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をいただけますと幸いです。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 原文は こちら です。

この記事は、“ Introducing AWS HealthScribe – automatically generate clinical notes from patient-clinician conversations using AWS HealthScribe ” を翻訳したものです。 はじめに 本日 (2023 年 7 月 26 日)、 AWS HealthScribe (プレビュー) を発表できることを嬉しく思います。これは、医療ソフトウェアベンダーが、患者と臨床医の会話を分析して予備的な臨床記録を自動的に生成する臨床アプリケーションを構築できるようにする、HIPAA 適格の新しいサービスです。 AWS では、医療とライフサイエンスにおいて、お客様のコラボレーションの方法、データ主導の臨床および運用上の意思決定、精密医療の実現、医療費削減などの目的に特化したサービスに投資してきました。AWS には、医療やライフサイエンスのデータを保存、変換、分析、アクセスできる、高性能で人口規模のアプリケーション構築が可能な最先端の機能が備わっています。目的に特化した機能により、お客様は、臨床記録、ゲノムやその他のオミクスデータ、医用画像、構造化されていない医療テキストや音声など、さまざまな種類の医療データや科学データを管理し、そこから得た知見を活用することができます。 文書化の義務が患者の診察体験を妨げる クリニックでの忙しい一日を想像してみてください。臨床医は、すべての患者に質の高いケアを提供しようと、予約をやりくりしながら一日を過ごしています。休憩時間が限られているこの連続したスケジュールに加えて、臨床医は患者の診察を行うたびに詳細な文書を保管する必要があります。この必要な管理業務に費やされる時間と労力により、患者との貴重な対面でのやり取りの時間を奪われてしまうことがよくあります。 業界の要件により、厳密な文書化が求められます。臨床医は、患者との対面でのやり取りよりも、管理作業に約 2 倍の時間を費やすことがよくあります 1 。そのため、思いやりのあるケアを提供することと、正確な記録を維持することとの間で葛藤が生じています。この負担は、臨床医と患者の両方に発生します。患者は医療提供者からあまりケアを受けられない一方で、臨床医は燃え尽き症候群のリスクが高くなり、仕事の満足度が低下します。医療筆記は文書作成の作業負荷を軽減するのに役立ちますが、雇用、訓練、維持に費用がかかり、文書作成に時間がかかるため、同様の燃え尽き症候群に直面することがよくあります。 新時代: AI を活用した医療情報文書化ソリューション AI は、管理業務への臨床医や医療筆記の関与を大幅に減らすことで、臨床文書の作成プロセスを変革する可能性を秘めています。従来の支援型 AI エージェントは、書き起こされた会話のコンテキストを理解する能力が限られていました。しかし、生成系 AI と大規模言語モデルの進歩により、コンテキストの理解が大幅に向上しました。 生成系 AI の核となるのは、学習データから複雑なパターンを識別して再現することの学習です。この機能は、データの複雑さと多様性が大きな課題となる医療業界の課題に非常に適しています。生成系 AI は、手間と時間がかかっていたタスクを迅速化し患者ケアの時間を確保する、といった医療提供変革の支援ツールを構築する新たな機会を生み出します。 AI への期待は大きいですが、医療アプリケーション開発者は、AI を構築し臨床アプリケーションへ統合する際に、いくつかの課題に直面しています。 実装の複雑さ: 会話型 AI および生成系 AI サービスのトレーニング、最適化、統合には、時間と費用がかかる場合があります。 セキュリティ: 開発者は、AI 搭載ソリューションがセキュリティ、プライバシー、医療に関する厳しいコンプライアンス要件を満たしていることを確認する必要があり、開発プロセスがさらに複雑になります。 信頼: AI が生成する臨床記録への信頼の欠如、およびモデルトレーニングにおける患者データの使用可能性に対する信頼性の欠如は、AI ベースのソリューション採用をためらう原因となります。 AWS HealthScribe の紹介 AWS HealthScribe は、医療ソフトウェアベンダーが患者と臨床医の会話を文書化、要約し、臨床記録を自動生成するアプリケーションの開発を支援する HIPAA 適格サービスです。AWS HealthScribe は、会話型 AI と生成系 AI を組み合わせることで、臨床記録作成の負担を軽減し、診察体験を向上させます。AWS HealthScribe は、臨床アプリケーションにおける臨床記録作成を迅速に行えるよう設計された AI 搭載の堅牢な機能一式を提供します。AWS HealthScribe は、患者と臨床医の会話音声を分析して以下の機能を提供します。 豊富な診察文書化: AWS HealthScribe は、文書化された各対話において単語レベルでのタイムスタンプを含む包括的なやり取りの文書化を提供します。 話者の役割識別: 診察室にいる個人は記録の中で一意に識別され、会話の内容から医師または患者を識別します。これにより、医師と患者のやり取りの中で、「誰が何を言ったか」を明確に確認できるようになります。 文書のセグメンテーション: AWS HealthScribe は、文書化された対話を分類し、臨床関連部分を主観、客観、評価、計画などの適切な要約セクションに整理します。また、会話中の雑談や沈黙時間も特定できるため、文書の特定箇所を見つけやすくなります。 臨床記録の要約: AWS HealthScribe は、診察内容を分析し、主訴、現在の病歴、評価、計画などの項目ごとにまとめられた臨床記録を生成します。これらの要約は簡単にレビュー、編集、最終決定が行え、臨床医や筆記の診察要点を素早くまとめることができます。 エビデンスマッピング: AI が生成する臨床記録で使用されるすべての文書には、元の診察記録への参照が含まれているため、ユーザーは要約の正確性を簡単に検証できます。 構造化された医学用語: AWS HealthScribe は、病状、医薬品、治療法など、会話の記録から構造化された医学用語を抽出します。これらの医学用語を使用すると、臨床応用のさまざまな分野に関連する有用なワークフロー候補を生成したり、関連するエントリを自動提案することができます。 医療アプリケーション開発者は、AWS HealthScribe を臨床アプリケーションに統合することで、医療従事者へ患者診察時の重要な項目を強調表示することができます。 図 1: 医療アプリケーション開発者が AWS HealthScribe により医療従事者へ提供できるアプリケーション体験の実例 これらの機能を統合することで、AWS HealthScribe は個別に AI サービスをトレーニング、最適化、統合、カスタムモデルを構築する必要性を減らし、より迅速な実装を可能にします。お客様は、個々の AI コンポーネントの最適化について心配することなく、エンドユーザーへの価値提供に集中できます。 すばらしい事例として、3M、ScribeEMR、Babylon などの医療ソフトウェアベンダーがすでに AWS HealthScribe を使用して臨床アプリケーションを強化していることが挙げられます。 3M Health Information Systems（3M HIS）は業界リーダーであり、その多様な M*Modal 音声理解、対話型およびアンビエント AI ソリューションは、現在全米で 30 万人以上の臨床医によって使用されています。 3M HIS のプレジデントである Garri Garrison 氏は、次のように述べています。「AWS に組み込まれた機械学習によって、3M HIS は臨床医のワークフローや手間のかかるプロセスを変革し、医療機関における臨床文書の作成や請求業務を効率化できます。3M HIS は AWS と提携し、臨床における文書化ワークフローに直接、対話型生成 AI を導入しています。AWS HealthScribe が当社の臨床アプリケーションの中核コンポーネントとなることで、3M のアンビエント臨床文書作成やバーチャルアシスタントソリューションをより迅速かつ高度化して、大規模に提供できるようになるでしょう」 Babylon は、人々の健康を大規模に管理するデジタルファーストの統合プライマリケアサービスです。 Babylon のチーフ・サイエンス・オフィサーである Saurabh Johri 氏は、次のように述べています。「人間の持つ医療の専門知識と AI を融合することで、質の高いヘルスケアをより手頃な価格で利用しやすくし、医療従事者にかかる負担を軽減できます。その一例が臨床概要などの分野でのイノベーションであり、ヘルスケアにおけるアウトカムの改善につながる可能性を持っています。Babylon は AI イノベーションのリーダーとして、引き続き AWS と連携し、AWS HealthScribe の生成系 AI 機能と当社の自然言語処理ソリューションとの統合を探求できることを期待しています」 ScribeEMR はバーチャルメディアスクライブ（補足：遠隔医療筆記）のリーディングプロバイダーとして、何百もの診療所や病院、医療システムに医療コーディングや医療オフィス用サービスをバーチャルで提供しています。 ScribeEMR の共同創業者兼ゼネラルマネージャーである Daya Shankar 氏は、次のように述べています。「ScribeEMR が目指すのは、ヘルスケア業界における実務の効率を高め、収益を最大化して医療従事者の燃え尽き症候群を減らすために貢献することです。AWS HealthScribe の能力を活用することで、当社は生成系 AI を利用して医療文書の作成プロセスを変革することができます。AWS HealthScribe との連携により、当社の高度なプロセスは患者の来院をより効果的に把握して解釈できるようになり、EMR のワークフローやコーディング、償還手続きを最適化することができます」 図 2: AWS HealthScribe は、AI が生成した要約が診察記録にリンクされるよう、的確に設計されている セキュリティとプライバシーに重点を置き、的確に構築されています AWS HealthScribe は、患者データのセキュリティとプライバシーを優先する HIPAA 適格サービスです。AWS は、AWS HealthScribe サービスを通じて生成された入力または出力を AWS HealthScribe のトレーニングに使用することはありません。ユーザーはデータを完全に管理でき、作成文書や予備的な臨床記録の保存場所を指定することができます。 AWS HealthScribe は、医療従事者が簡単に文書作成することができることを目的として、補助的な役割で使用するよう設計されています。AI が生成した要約はそれぞれ診察記録にリンクされているため、ユーザーは原本と相互参照することで正確性を簡単に検証でき、AI が生成した記録の根拠となるコンテキストを理解できます。AI が生成する知見のトレーサビリティと透明性を提供することは、説明可能性という責任ある AI の原則と合致し、臨床現場における AI の信頼獲得と安全な利用促進に役立ちます。 まとめ AWS は医療ソフトウェアベンダーと協力し、お客様が臨床医と患者の診察体験を改善できるよう支援しています。臨床アプリケーションでは、AWS HealthScribe が豊富な診察文書を自動生成しセグメント化、患者と臨床医の話し手の役割を特定、医学用語の抽出、そして予備的な臨床記録の生成を行います。AWS HealthScribe はこれらの機能を組み合わせることで、個別に AI サービスを統合および最適化する必要性を減らし、実装を迅速化します。AWS HealthScribe は、AI が生成する臨床記録の全ての文書に元の患者記録への参照を含めることで、医療ソフトウェアベンダーが AI を責任を持って使用できるよう支援します。AWS HealthScribe には、機密性の高い患者データを保護するためのセキュリティとプライバシーの機能が組み込まれています。 AWS HealthScribe は米国東部 (バージニア) でプレビュー版をご利用いただけます。このサービスにアクセスするには、 AWS HealthScribe のサインアップページ と 製品ページ にアクセスしてください。 [1] 医師は患者応対時間のほぼ 2 倍の時間を電子カルテ / デスクワークに費やしている Jason Mark Jason Mark は、アマゾンウェブサービスの米国非営利医療部門ソリューションアーキテクトチーム責任者です。 彼は SA チームを率いてお客様の課題を解決し、AWS を活用して患者に提供するケアを改善しています。 病院の薬局システム、コーディングと償還ソフトウェア、自然言語理解プラットフォームでの仕事など、医療技術の分野で 21 年の経験を持ち、Misys Healthcare と 3M Health Information Systems で勤務していました。 彼の仕事以外の生活は、娘や犬、飛行機による飛行を中心に回っています。 Sarthak Handa Sarthak Handa は、ワシントン州シアトルのアマゾンウェブサービス (AWS) AI/MLチームにて、シニアプロダクトマネージャーを務めており、医療業界の進歩を促進する AI サービスの開発に主眼を置いています。 AWS で働く前は、スタートアップの創業者として数年間働き、医療および災害救援セクター向けのテクノロジーソリューションを構築していました。 Tehsin Syed Tehsin Syed は、アマゾンウェブサービスのヘルス AI 担当ゼネラルマネージャーであり、Amazon Comprehend Medical、Amazon HealthLake、Amazon Omics、Amazon Genomics CLI などのヘルス AI 戦略、エンジニアリング、製品開発の取り組みを主導しています。 Tehsin は、エンジニアリング、科学、製品、テクノロジーを担当するアマゾンウェブサービスのチームと協力して、画期的な医療およびライフサイエンス AI ソリューションと製品を開発しています。 AWS で働く前は、Cerner Corporation でエンジニアリング担当副社長を務め、医療とテクノロジーの交差点で 23 年間働いていました。 翻訳は Solutions Architect 松浦が担当しました。原文は こちら です。

この記事は、“ Introducing AWS HealthImaging — purpose-built for medical imaging at scale ” を翻訳したものです。 医用画像データをペタバイト規模で保存、分析、共有するクラウドネイティブアプリケーションの開発を支援する専用サービス、 AWS HealthImaging の一般提供を発表できることを嬉しく思います。HealthImagingは DICOM P10 形式（訳註：DICOMが規定したバイナリフォーマット）でデータを取り込みます。低レイテンシーの検索と専用ストレージのための API を提供します。 医療機関のお客様からは、医療チームに最高の医用画像アプリケーションを提供したいという声と、インフラストラクチャ管理の複雑さを軽減したいという声が寄せられています。私たちの研究に焦点を当てたお客様は、画像データを大規模に分析し、組織全体での連携と発見を加速させたいと考えています。これらの利用者グループはどちらも、組織のすべての医用画像アプリケーションを同じデータストアから動作させたいという希望を示しています。クラウドはこうした利用者のニーズに応えるのに役立ちます。HealthImaging を使用すると、医用画像アプリケーションや研究ソリューションを提供する AWS パートナーのような開発者は、インフラストラクチャについて心配することなく、こうした利用者の課題に取り組むことに集中できます。 医療提供と研究における医用画像の拡大 100年以上にわたり、医療提供者はX線、MRI、超音波などの医用画像を使用して、患者の内部を非侵襲的に調べてきました。 ノーベル賞受賞者のマリー・キュリーは、医用画像の初期のパイオニアの一人でした。彼女は、第一次世界大戦中に戦場の外科医がより良いケアを提供できるように、「プチキュリー」と呼ばれるX線装置を搭載した車両を開発しました。 現在、医用画像は、がん、外傷、脳卒中など、さまざまな健康状態の診断と観察に使用されています。世界中で毎年36億件を超える医用画像処理が行われ、合計でエクサバイトの医用画像データが生成されています。 医療システムは、医用画像処理に対する需要の高まりに応えるのに苦労しています。2008年以降、米国の放射線科医に割り当てられる画像検査の平均数は、1日あたり58件から1日あたり100件に増加しました。同じ時期に、一般的な画像検査のサイズは2倍になり、150 MB近くになりました。その結果、放射線科医は生産性を向上させるための新しいテクノロジーを必要としており、読影に負担のかかるワークフローを合理化し、エラーを最小限に抑えるために AI の使用が増えています。 医療機関のITグループは、新しい医用画像検査や保管された医用画像検査を管理するインフラストラクチャに、責任を持ちます。これらの組織は、急速に増え続ける画像保管を、通常はオンプレミスで管理しています。インフラストラクチャがかなりの装置面積、ITスタッフ、運用予算を消費していると見ています。また、同じ医用画像へのアクセスを必要とし、それぞれに異なるレイテンシーと解像度のニーズを持つエンタープライズアプリケーションの数が増え続けています。その結果、さまざまなアプリケーション用に各画像の複数のコピーが保存され、さらに長期保存用に追加のコピーが保存されます。その結果、データが重複し、どのバージョンの画像が信頼できるかが不確実になるため、ストレージコストが高くなることになります。 介護チームや研究グループとの連携により、データのコピーがさらに増える可能性があります。医療チームは通常、完全に識別された患者のデータを必要としますが、AIモデルを構築するチームは匿名化されたデータを使用することを好む場合があります。従来のオンプレミスアーキテクチャでは、利用者はユースケースごとにデータのコピーを追加する必要がある場合があり、その結果、ストレージコストが高くなり、運用が複雑になります。医用画像の拡大により、新しい言語やコンピュータービジョンのAIモデルの開発に使用できる膨大なデータセットが作成されました。しかし、従来のデータサイロは、研究者のデータへのアクセスを制限することでイノベーションを妨げています。 AWS HealthImagingの紹介 HealthImagingは、インフラストラクチャの準備や設定を簡素化する専用の医用画像データストアを提供し、利用者が患者のケアや研究を行う時間を増やせるようにします。HealthImaging を使用すると、組織内のすべてのアプリケーションが、重複することなくデータの単一の信頼できるコピーにアクセスでき、ユーザーはどこからでもデータに安全にアクセスできます。HealthImaging コンソールで数回クリックするだけで、ペタバイト規模の医療画像データをホストできるデータストアをプロビジョニングでき、すべての画像を低レイテンシーで取り出せる状態に保つことができます。さらに、HealthImagingは、エンタープライズイメージングソリューションの運用に必要なインフラストラクチャの量を削減し、コストの削減と運用の複雑さの軽減に役立ちます。 お客様は HealthImaging 上に構築されたアプリケーションを使用することで、ハードウェアの更新サイクルやキャパシティプランニングを気にすることなく、イメージアーカイブのストレージコストを低く抑えることができます。画像撮影装置によって新しいデータが生成されると、そのデータをHealthImagingにインポートして、PACS（picture archiving and communication systems）（訳註：医用画像管理システム）などの医療システムですぐに取得できます。 AWS DataSync 、 AWS Direct Connect 、および AWS パートナーが提供する専用ゲートウェイにより、データをエッジからクラウドに簡単に移動できます。 図 1.モダリティ (CT、X線など) によって生成されたデータのインポートから、医療システム (PACS など) や研究ワークフローによる低レイテンシーの取得までのAWS HealthImaging の仕組み AWS パートナーは利用者に代わってイノベーションを行っています AWS パートナーはすでに HealthImaging を活用して、放射線科医、医療チーム、研究者が使用する医用画像ソリューションを再考しています。 ウェイク・フォレスト・バプティスト・ヘルスは、アポロ・エンタープライズ・イメージングとHealthImagingのソリューションにより、放射線科の学生が臨床コンテンツにアクセスしやすくしています。 「私たちは、全社で、また世界中の協力者と研究や教育のために、医用画像を拡大、共有、表示できる機能を必要としています。 Apollo EI と共同で AWS HealthImaging とその最先端のエンタープライズイメージングリポジトリテクノロジーを活用することで、それが可能になりました。」— ウェイク・フォレスト・バプティスト・ヘルスのシステムマネージャー、ジョシュ・タン 医用画像処理の世界的リーダーであるフィリップスは、HealthImagingを次世代の医用画像スイートの基盤要素として使用する予定です。 「私たちのビジョンは、臨床医とスタッフが増え続ける作業負荷を管理し、ワークフローを最適化して患者の診断と治療までの時間を短縮できるようにすることです。AWS HealthImaging のような AWS の専用サービスは、フィリップスのイノベーションを加速させ、お客様とその患者にサービスを提供するのに役立ちます。当社のクラウド対応の HealthSuite Imaging PACS は、AWS HealthImaging を使用して世界中の臨床医の体験とアクセシビリティを向上させることを目指しています。」— フィリップスの最高イノベーション責任者および最高戦略責任者兼エンタープライズインフォマティクスの最高ビジネスリーダー、シェズ・パートヴィ データをオンプレミスのサイロからクラウドに移行することで、イノベーションの新たな機会が生まれます。ヘルスイメージングは機械学習用に Amazon SageMaker と統合されているため、GPU アクセラレーテッドコンピューティングにアクセスできます。NVIDIA は、HealthImaging とシームレスに連携するハードウェアアクセラレーションツールとオープンソースフレームワークに投資して、医用画像処理におけるアルゴリズム開発と AI の採用を進めています。 「NVIDIA が共同設立して推進した MONAI は、特定の分野に特化した医用画像 AI フレームワークです。これにより、研究の飛躍的進歩や AI アプリケーションを臨床効果へと迅速に変換できます。MONAI と AWS HealthImaging の統合により、医用画像をほぼリアルタイムで表示、処理、セグメント化できるため、医師のワークフローが最適化され、患者体験が向上し、病院の効率が向上します。」 NVIDIA ヘルスケア AI 製品担当グローバルリーダー、プレナ・ドグラ また、パートナーはHealthImagingのメリットをより簡単に実現できるようにしています。Dicomaticsは、HealthImagingを使用してレガシー環境から最新のクラウドベースの環境へのエンタープライズクラスのデータ移行を支援するソリューションなど、さまざまなソリューションを提供する医療情報企業です。 「Dicomaticsは、シームレスでスケーラブルな医用画像データ移行のリーダーです。オンプレミスからクラウドまで、ペタバイト規模の複雑な移行の処理に優れています。AWS HealthImaging の力により、お客様は貴重なデータの保存、臨床作業負荷、画期的な研究に特化した専用クラウドサービスを手に入れることができるようになりました。」— Dicomatics、戦略的パートナーシップ、 アビラム・ビトン氏 医用画像用の費用対効果の高いストレージ HealthImagingは、あらゆるサイズの新しいデータや画像アーカイブを保存するための総所有コストを削減できる、費用対効果の高いストレージを提供します。HealthImagingには、新しいデータや頻繁にアクセスされるデータ用のフリークエントアクセスストレージ階層と、アクセス頻度の低いデータ用のコスト効率の高いアーカイブ・インスタント・アクセス階層があります。30 日以上保存されたデータは、自動的にアーカイブ層に移動されます。動作は Amazon Simple Storage Service (Amazon S3) の Intelligent-Tiering ストレージクラス と似ており、コスト削減はお客様に還元されます。 HealthImaging のどちらのストレージ階層も、ミリ秒単位のデータ取得をサポートしています。HealthImagingに保存されているすべての画像フレームは、1秒未満のレイテンシーでアクセスしてレンダリングできるため、お客様が高価なブロックストレージボリュームにデータをステージングする必要がなくなります。 スケーラブルなデータ取り込みと処理 DICOM P10 ファイルを HealthImaging にインポートするには、非同期インポートジョブを起動します。複数のインポートジョブを同時に実行することでスケールアップできます。個々のDICOM P10ファイルは画像フレームとしてインポートされ、患者、研究、およびシリーズレベルで一貫したメタデータを含む画像セットに自動的に整理されます。コピーおよび更新 API を使用すると、特定のワークフローで必要とされるイメージセットを簡単に管理できます。 各DICOM P10ファイルのピクセルデータは、効率的な可逆圧縮と解像度スケーラビリティを提供する最先端の画像圧縮コーデックであるハイスループットJPEG 2000（HTJ2K）としてエンコードされます。大量のアーカイブをお持ちのお客様は、HTJ2K を使用することでストレージ容量が削減され、コスト削減に役立つ場合があります。HealthImaging は、インポートされた各画像フレームにチェックサムを提供することで、すべてのピクセルデータが正常にトランスコードされたことを検証します。これらのチェックサムは画像セットのメタデータに追加されるため、画像フレームを取得する際に可逆画像処理を個別に検証できます。 DICOM P10ファイル内のメタデータ（患者識別情報や検査の詳細など）は、患者、検査、およびシリーズレベルで自動的に標準化されます。その結果、不一致がなくなり、データ品質が向上します。すべてのメタデータが保存され、DICOM データ要素のレジストリに基づいて正規化が実行されます。さらに、正規化された要素には、16進数のDICOMタグではなく、 PatientId などの開発者が使いやすいキーを使用してアクセスできます。 HealthImaging へのデータのインポートには料金はかかりません。ピクセルデータの符号化とメタデータの正規化は自動的に実行されます。つまり、お客様は自己管理型インフラストラクチャから HealthImaging に移行してDICOMを取り込む際のコストを削減できるということです。 リアルタイムアプリケーション向けに最適化された API 既存の画像転送プロトコル (DIMSE や DICOMWeb など) では、クラウドからのストリーミング時に遅延により、パフォーマンスが低下する可能性があります。しかし、放射線科医は、インタラクティブなワークフローや診断アプリケーションのために、待ち時間の低減を求めています。そのため、HealthImaging は、ピクセルデータやメタデータの取得を低遅延で行えるように最適化された API を提供しています。 HealthImagingは、効率的なメタデータのエンコード、可逆圧縮、およびプログレッシブ解像度の画像データアクセスのサポートにより、データ検索と画像読み込みにおいて業界トップのパフォーマンスを提供することを目的として構築されています。アプリケーションとAIアルゴリズムは、画像データをロードしなくても、APIを介して研究メタデータに効率的にアクセスできます。同様に、最先端の画像圧縮により、アプリケーションは画像品質を損なうことなく、APIを介して画像データを直接読み込むことができます。 HTJ2K コーデックは JPEG2000 よりも桁違いに速く、他のすべての DICOM 転送構文よりも少なくとも 2 倍高速です。HealthImaging を使用すると、アプリケーションは単一命令複数データ処理 (SIMD) で HTJ2K を活用して、優れた画像デコードパフォーマンスを実現できます。さらに、最新のブラウザーでは Web Assembly SIMD (WASM-SIMD) を利用して、インストール不要な Web ビューアで業界トップのパフォーマンスを実現できます。したがって、HealthImaginingを使用すると、アプリケーションは最も要求の厳しいインタラクティブなユースケースを満たすレイテンシーでデータを取得および転送できます。 まとめ 私たちのお客様とパートナーは、患者に代わってたゆまぬ革新を続けています。HealthImagingは、より多くの治療を必要とする患者に質の高いケアを提供できるよう支援しています。HealthImaging を使用すると、医用画像データをペタバイト規模で容易に管理でき、業界トップクラスのパフォーマンスでインフラストラクチャを心配する必要がなくなります。 HealthImaging を使い始めるには、 ドキュメント か、 Web ページ で詳細をご覧ください。 Tehsin Syed Tehsin Syed は、アマゾンウェブサービスのヘルス AI 担当ゼネラルマネージャーであり、Amazon Comprehend Medical、Amazon HealthLake、Amazon Omics、Amazon Genomics CLI などのヘルス AI 戦略、エンジニアリング、製品開発の取り組みを主導しています。Tehsin は、エンジニアリング、科学、製品、テクノロジーを担当するアマゾンウェブサービスのチームと協力して、画期的なヘルスケアおよびライフサイエンス AI ソリューションと製品を開発しています。AWS で働く前は、Tehsin は Cerner Corporation でエンジニアリング担当副社長を務め、ヘルスケアとテクノロジーの交差点で 23 年間働いていました。 Andy Schuetz Andy Schuetz 博士は、アマゾンウェブサービスのヘルス AI 担当プリンシパルプロダクトマネージャーであり、ヘルスケアおよびライフサイエンスのお客様向けのクラウドサービスの構築に注力しています。AWS に入社する前は、Andy はスタートアップの共同創設者であり、Sutter Health のシニアデータサイエンティストと、アルキメデス社の製品責任者を務めていました。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。