みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 2023 年 11 月 23 日に AWSome Day Online Conference が開催されます。このイベントは、クラウドジャーニーのはじめの一歩として、AWS クラウドに関する基礎知識を 3 時間で学ぶ無償の初心者向けオンラインイベントです。AWS の概要、コンピューティング、ストレージ、データベース、ネットワーク、IoT、機械学習などを知識を幅広く身に付けられます。事前登録が可能となっておりますので、ぜひ興味のある方はご登録をよろしくお願いいたします。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023 年 10 月 30 日週の主要なアップデート 10/30(月) AWS Elemental MediaTailor now available in seven additional regions AWS Elemental MediaTailor が大阪リージョンを含む 7 つの新しいリージョンで利用可能になりました。AWS Elemental MediaTailor は、複数の動画を 1 つのチャンネルに組み合わせたり、広告を挿入するなど、ライブ配信を支援する機能を提供するサービスです。このサービスを利用することで、チャンネルやその他のライブストリームを、様々なデバイスでパーソナライズされた広告とともに収益化し、視聴者にシームレスな体験を提供することができます。 Introducing eight new Amazon EC2 bare metal instances Amazon EC2 で、C7i、M7i、R7i、R7iz の新しいベアメタルインスタンスが利用可能になりました。M7i、C7i、R7i インスタンスは、AWS 向けにカスタマイズされた第 4 世代 Intel Xeon プロセッサーを搭載しています。同等の x86 ベースの Intel プロセッサーと比較して、最大 15% のパフォーマンス向上が図られています。このインスタンスは、オハイオ、バージニア、オレゴン、アイルランド、スペイン、ストックホルムの 6 つのリージョンで提供されています。R7iz インスタンスは、ターボクロック周波数が 3.9 GHz の Sapphire Rapids ベースのインスタンスとなっており、バージニアとオレゴンの 2 つのリージョンで提供されています。 AWS Trusted Advisor adds 64 new checks powered by AWS Config AWS Trusted Advisor が、AWS Config との統合により、「運用上の優秀性」カテゴリーで新たに 64 個のベストプラクティスチェック項目を提供開始しました。Trusted Advisor は、コスト最適化、パフォーマンス、セキュリティ、耐障害性、運用上の優秀性などのカテゴリーで、お客様の AWS 環境がベストプラクティスとどの程度乖離しているかをチェックし、継続的な改善に役立てることができるサービスです。この新しい 64 項目は、AWS Support の Business Support プラン以上で利用可能です。 10/31(火) AWS Elemental MediaPackage now available in Asia Pacific (Osaka) region AWS Elemental MediaPackage が大阪リージョンで利用可能になりました。MediaPackage は、動画配信時に様々なストリーミング形式にパッケージングすることで、携帯電話、パソコン、タブレット、ゲーム機など、多様なデバイスでの再生を可能にするサービスです。ライブ配信やオンデマンド配信の際に、スタートオーバー、一時停止、巻き戻しなどの一般的な動画機能を簡単に実装できます。また、デジタル著作権管理 (DRM) 技術を使って、コンテンツを保護することも可能です。 Amazon Athena announces one hour reservations for Provisioned Capacity Amazon Athena で、1 時間単位のキャパシティ予約が利用可能になりました。キャパシティ予約機能は、クエリ処理のための専用コンピュートリソースを確保するものです。これにより、ビジネスクリティカルなクエリーをほぼゼロレイテンシーでキューイングなしに処理できます。また、Athena の利用料金を固定化することでコントロールがやりやすくなるメリットもあります。アップデート前は最低 8 時間のキャパシティ予約が必要でしたが、今回のアップデートにより、最低 1 時間からのキャパシティ予約が可能になりました。東京を含む 8 つのリージョンで利用できます。 Amazon S3 Object Lambda now integrates with Amazon Athena Amazon S3 Object Lambda が Amazon Athena と統合され、Athena でクエリされる S3 データを自動的に変換できるようになりました。S3 Object Lambda を使用することで、S3 の GET、HEAD、LIST API リクエストに独自のコードを追加し、アプリケーションに返されるデータを変更できます。例えば、Athena でクエリを実行する際、Lambda 関数を使って機密データの列を自動的にマスクすることが可能です。 11/1(水) Amazon EC2 Capacity Blocks for ML Amazon EC2 Capacity Blocks for ML の一般提供が開始されました。これは、大規模な機械学習向けに設計された新しいタイプのキャパシティ予約の仕組みです。EC2 Capacity Blocks を利用すると、利用開始日と終了日を事前に指定し、その期間内に空きがあるか確認しながら GPU インスタンスのキャパシティを予約できます。既存の On-Demand Capacity Reservation が「現時点から」の予約に対して、EC2 Capacity Blocks は未来の日付で予約が可能なのが特徴です。現在、Amazon EC2 P5 インスタンスがオハイオリージョンで予約できるようになっています。利用にあたっては、予約期間は 1 日 ~ 14 日、予約インスタンス数は 1、2、4、8、16、32、64 台から選択する必要があるなどの制限があります。詳細は ドキュメント をご参照ください。 Amazon Redshift Multi-AZ is generally available for RA3 clusters Amazon Redshift で RA3 クラスタの Multi-AZ を一般提供開始しました。Redshift の Multi-AZ は、複数のアベイラビリティゾーンでデータウェアハウスを同時に実行し、不測の障害シナリオでも運用を継続しやすくする機能です。Multi-AZ により、Redshift の SLA が 99.99% に上がりました。ミッションクリティカルな使い方に対して、可用性の高い Redshift 環境をご利用頂けます。東京・大阪リージョンを含めた、25 リージョンで利用可能です。 Announcing new user roles for Amazon CodeCatalyst Amazon CodeCatalyst に、Power user、Limited access、Reviewer、Read only の 4 つの新しいユーザーロールが追加されました。Power user はプロジェクトの作成や AWS アカウントの追加ができます。Limited access はスペースメンバーのデフォルトロールで、プロジェクトの一覧表示ができます。Reviewer は Issue 機能の利用やプルリクエストの承認ができますが、ソースコードやワークフローの変更はできません。Read only はリソースの読み取りのみ可能で、作成・更新・削除はできません。 これらの新しいロールにより、アクションとプロジェクトへのアクセスをより細かくコントロールできるようになりました。 11/2(木) AWS IAM action last accessed information for more than 60 additional services AWS IAM で最後にアクセスしたアクション情報を確認する機能について、新たに 60 個の AWS サービスがサポートされました。最後にアクセスしたアクション情報を確認することで、使用されていない権限を発見し、許可するアクションのみ制限することがやりやすくなります。このアップデートで、AWS Auto Scaling、Amazon Redshift、Amazon Route 53 などのサービスが追加されました。 AWS Global Accelerator extends IPv6 support to dual stack NLB endpoints AWS Global Accelerator のデュアルスタックアクセラレータの機能を拡張し、デュアルスタックの ALB と EC2 に加えて、新たに NLB をサポートしました。デュアルスタックアクセラレータを利用することで、IPv4 と IPv6 の両方のネットワークトラフィックを、デュアルスタックの設定をしている NLB にルーティングできます。Global Accelerator は 2 つの静的な IPv4 アドレスに加えて、2 つの静的な IPv6 アドレスを持ちます。IPv6 を意識した環境を準備しやすくなるアップデートです。 11/3(金) AWS App Runner now supports Internet Protocol Version 6 (IPv6) for public inbound traffic AWS App Runner でパブリックなエンドポイントを構成する際に、IPv4 と IPv6 を同時に利用できるデュアルスタック構成をサポートしました。IPv4 と IPv6 の両方のクライアントは、App Runner のパブリックエンドポイントに直接アクセスが可能です。なお、プライベートエンドポイントは IPv4 のみサポートしています。パブリックエンドポイントからプライベートエンドポイントへ設定変更を行うと、IPv6 の通信が出来なくなるのでご注意ください。 2023 年 AWS re:Invent 速報 が事前登録開始になっています。AWS re:Invent の会期中に発表された新サービス・新機能を 1 時間で網羅してご紹介するものです。ぜひお見逃しの無いように事前登録をお願いします。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

本ブログでは2023年9月21日（木）に開催された、「現場の業務変革を実現するAI・データ活用(鉄道/運輸編・建設/プラント編)」のご講演サマリをお届けします。 1. JR九州の「AWS×データ分析」によるDX推進の取り組み 2. 電気設備に対する画像分類モデルの開発と生成AIを活用した異常画像生成の取り組み 3. 「建設デジタルプラットフォーム」によるデジタルデータ活用 4. ファストデジタルツインでちゃぶ台返し～保全の現場から市場を創る、ものづくりを変える～ 5. 現場業務変革を実現するAWSテクノロジー 　1. JR九州の「AWS×データ分析」によるDX推進の取り組み 資料ダウンロード 九州旅客鉄道株式会社様 (JR九州様)　からは、AWSとデータ分析を掛け合わせたDX推進の取り組みについてご紹介いただきました。 まず東村様より、JR九州様のグループ会社(JR九州グループ)としてのDX取り組みの経緯についてご紹介いただきました。 JR九州グループの組織として2019年に設立されたデジタル推進室では、当初、2030年までの長期ビジョンでデジタル技術の活用を推進していく想定でした。しかし、2019年以後のコロナウイルスの感染拡大により、リモートワークの増加、お客様のライフスタイル変化等により、JR九州グループは各ビジネス部門のDXやデータ活用の強化が早急に求められるようになりました。その対策として、JR九州グループDX戦略を策定し、2022年からDX戦略に沿った活動を開始されました。DX戦略の中の3つの目標として、お客様の体験価値の向上、オペレーション・メンテナンス改革、働き方改革・生産性向上を掲げられており、その目標の実現に向けて、様々な新技術の導入、クラウド・ネットワーク・ガバナンスなどの基盤整備、そしてDX推進人材の育成と体制強化への取り組みについて述べられていました。推進組織（CoE）だけに止まらず、各事業部に対してDXの専任となる人材を配置することで、CoEと各事業部の連携を強化し、DX推進を加速する仕組み作りが特徴的でした。 続いて、DX戦略のPJの一例として、データ分析プロジェクトについてお話をいただきました。データ分析PJは、JR九州グループ全体で専門チームを立ち上げられたプロジェクトで、2021年4月に、社内にどんなデータが保存されているかを一覧化してくことから取り組みを開始しました。一覧化したデータと各事業部でヒヤリングした結果に基づき、どのような分析と活用を実施すべきかを決めるテーマを洗い出し、2021年10月にデータ分析CoEの立ち上げと共にデータ分析がスタートしました。2022年4月には事業部専任の社員がアサインされ、現在では分析結果をベースにした業務やビジネスの構築と共に、社内外へのPJの発信にも注力されています。 データ分析PJを進めていく上で苦労したポイントは2点あり、1つはデータの把握でした。社内データは各課と各PJで細分化されており、どこにどのようなデータがあるのか、またそれぞれのデータの管轄はどこなのか不明で、それらを調べ一覧化することに非常に労力をかけることになりました。また、データの形式も非構造化データと呼ばれるデータが多く、活用できるデータなのかどうなのかを整理し、一覧化するところにも労力をかけることになりました。もう1つの苦労ポイントは分析チームの立ち上げ時で、今まで存在しなかったCoEといった枠組みに対し、新たに他部門からメンバーを選出するにあたり、関係各所への説明を実施して理解していただく必要がありました。こういった苦労がありながら、2021年に10月に分析PJチームを立ち上げが実現し、現在に至っております。 AWSを活用したデータ分析PJの事例として、動画データを活用した鉄道沿線設備の保全高度化と、販売データを活用した駅弁当の発注業務効率化の取り組みについて、それぞれ東村様と姫野様よりご紹介いただきました。本記事では、前者の事例についてご紹介いたします。 動画データを活用した鉄道沿線設備の保全高度化の事例についてご紹介します。JR九州様は、2020年4月より営業車両カメラシステムRED EYEを導入し、検査業務の一部効率化を行っておりました。しかし、このRED EYEのシステムは一部の検査を効率化するにとどまっており、活用幅の拡大が検討されました。そのためデータ分析PJとして、RED EYEシステムで取得できる前方の列車映像を活用し、既存のシステムでは検知できない「鉄道設備及び設備周辺の正常性」を保守社員が容易に確認できる業務支援ツールを内製開発で AWS 上に展開しました。支援ツールを用いた取り組みの内容についてお話します。まず事前に定期的に設備の周辺状況を確認したい画像データ群を用意し、定期的に録画されるRED EYEシステムの前方列車映像データから、それぞれの画像データに最も類似した動画フレームを抜き出します。それにより最新の設備周辺画像が抽出され、その画像のみを目視で確認することで、設備の状態を容易に確認でき、保全の計画や実施に役立てるといった取り組みになります。また、これらの画像データは、簡易Webアプリケーションを通して、保守担当社員が容易に確認できるようになっています。このシステムにより、例えば雑草繁茂によって視認しづらくなる設備の予兆検知が効率的に行えるようになりました。 姫野様より、生成系AIの活用についてもお話いただけました。JR九州グループは、「JR九州グループ共通 ChatGPT等生成AI利用ガイドライン」制定し、積極的な生成AIの活用を検討されているとのことでした。また、ガイドラインだけではなく、生成AIとはどのようなモノか、どのような使い道があるか、ガイドラインの要点は何か等をまとめた資料も展開し、日々の情報発信とあわせて社内での積極的な利用を推進されているとのことでした。具体的な生成AIの活用事例として、現在はJRキューポへのお客様お問い合わせメールの作成支援を提供しているとのことです。現在はローカルアプリによる提供となっていますが、社内の他のお問い合わせ業務への展開にむけて、AWSへの移行を検討されているとのことです。 最後に、データ分析基盤としてAWSを選択された理由と、今後についてお話いただけました。AWSを選択した理由は主に2つあり、1つ目はAWSには非常に多くのサービスが存在し、PoCも実施しやすいため、検証から本番活用までをスピーディに行える点でした。2つ目はJR九州様のDMP(Data Management Platform)基盤とJR九州グループの仮想環境基盤がAWSに存在しており、データ連係が行いやすい点でした。しかし、AWSのサービスを分析基盤として使用し始めて、まだ2年程度であるため、AWSをまだ活かしきれていないことを課題に感じておられました。今後は、よりAWSを活用してビジネスを加速させるため、Amazon S3を用いたDatalakeアーキテクチャ、Amazon SageMakerを筆頭とするAWSのAI/MLサービス、AWS IoTサービス、Amazon QuickSightなどの利用を検討されているとのことでした。 本登壇では、JR九州グループのDX戦略の全体像と取り組みをご紹介いただきました。また具体的なお話として、DX戦略の取り組みの1つであるデータ分析PJについて、事例を出しながらお話いただきました。JR九州様は、自社のデータとAWSを実際の業務に活用しながら、今後にも目を向けており、より一層自社データとAWSを活用していくことで、鉄道業界における様々な課題解決を目指しております。 2. 電気設備に対する画像分類モデルの開発と生成AIを活用した異常画像生成の取り組み 資料ダウンロード JR東日本情報システム様（JEIS様）からは鉄道の電気設備メンテナンス業務へのAI/ML活用についてご講演いただきました。この取り組みは鉄道の電気設備メンテナンスを鉄道事業者向けに提供されている東日本電気エンジニアリング様（TEMS様）様と共同で取り組まれています。 まず、電気設備に対する画像分類モデルの開発について方志様よりお話をいただきました。こちらは2023年5月のAWS Blogに寄稿いただいた「 Amazon RekognitionとAmazon SageMakerを組み合わせた効率的なAI開発 」を一段深掘りした内容です。外環検査時にメンテナンス現場で撮影した16の設備、13,000枚の画像を使い、Amazon RekognitionとAmazon SageMakerそれぞれの評価結果をご紹介いただきました。 分類対象となる設備は配線箱の内の配線自体が異なるものの、配線箱という大きなくくりで考えると特徴が似通っています。従来の教師あり学習を使った分類では対応できないのではないかという仮説を検証するためAmazon Rekognitionを利用した分類に取り組まれました。結果は1138枚のテストデータの内、996枚の画像判定に成功され概ね良い結果が得られました。 それぞれの設備個々の正解率に着目し結果を確認すると、特定の設備に関する正解率が低いことに気づきました。画像を確認すると、設備自体の形状は同じにもかかわらず用途の違いにより分類が異なりました。これらの設備は画像単体で見ると保守担当者でも分類の判断が難しく、画像から分類できないため別のアプローチを試みました。 別のアプローチでは画像という外形上の特徴だけでなく、撮影された時刻に着目し、前後の撮影された画像と共に外観以外の特徴を含む画像分類モデルをAmazon SageMakerを利用し開発をされました。このモデルはAmazon Rekognitionで判定が難しかった設備分類においても98％の分類精度を実現しました。総計の正解率ではAmazon Rekognitionの84%よりも高い95%の正解率を実現しました。 また、画像モデルだけでは分類を実際に利用したいTEMS様の作業に従事される方から直接利用することは難しいことに着目されました。サーバレスやマネージドサービスを活用したアプリケーション開発も行われ現場の方が利用しやすいWebアプリケーション作成も行われAI/MLサービスの利用から現場への展開までの一連のプロセスにおいてAWSを活用いただいていています。 稲森様からは、生成AIを活用した取り組みについてご発表いただきました。TEMS様のメンテナンス業務において、摂津日検査は大量の画像から異常を見つける作業であり、陣原の注意力に異存する作業となっています。業務を効率化するため異常を判定するAIを作ろうとすると、正常/異常の各データを用意しモデルを作り利用します。ただし鉄道設備における異常を記録する場合、鉄道設備の異常発生率が低いため、モデルをつくるに十分な異常データを準備できず少ない異常データでモデルを作成しても精度が上がらないという課題を抱えています。異常判定モデル作成に必要な異常データを、生成系AIを利用して生成し利用することで異常判定モデルの精度を高めるためことを目的に研究されました。 画像生成AIとしてStable DiffusionをAmazon SageMaker上で利用し、異常画像全体を生成するのではなく現存する電気配線の一部分だけをリアリスティックに異常を発生させるため、部分的な書き換えに特化したIn Paintingモデルを利用し構築しました。まず、Stability AI社のファンデーションモデルをそのまま利用し書き換えを試みたもののリアルな異常を安定的に生成することは困難でした。TEMS様が持つ実際の異常画像を加えて学習させ独自モデルを作り、再度検証するとリアルかつ、豊富な異常画像生成を可能としました。 本来の目的である異常画像を判定するためのモデルに必要なデータとして、生成系AIが作り出したデータの有効性を簡易的に検証するため、Amazon Rekognitionカスタムラベルにて検証されました。AIが生成した画像のみを使い学習させたモデルを利用し、実際の異常画像を分類したところ良好な結果を得ることができ、このアプローチは異常が少ない器機に対する異常判定モデルを作る際の手法として有用だと考えられます。研究に際し、Amazon SageMaker Studioをご利用いただきました。Amazon SageMaker Studioノートブックを複数並列で利用いただき効率的な開発も出来たとご評価いただきました。 鉄道インフラは数千キロに及ぶ設備のメンテナンスが日々行われることで安全・安心な輸送が実現されています。人口減少による少子高齢化が叫ばれる昨今、メンテナンス業務の省人化に向けたAIの開発にメンテナンス現場とIT技術者が協力して日々取り組まれていることに感銘を受けました。セッション後の質疑応答で方志様から課題を持っている事業者であるTEMS様が1万件以上ある画像にラベリングを実施されたことが今回成功した要因の1つとご紹介いただきました。利用者とIT技術者の二人三脚が鉄道のメンテナンス業務のこれからを作っていくのではないでしょうか。 3. 「建設デジタルプラットフォーム」によるデジタルデータ活用 資料ダウンロード 株式会社 竹中工務店 美里様からは“建設デジタルプラットフォームによるデジタルデータ活用”についてお話しいただきました。 まずは建設業界が直面している課題についてのご説明がありました。建設業界での課題として、一般的な日本の各種業界の課題に加えて、建設業ならではの課題があるという点について、数字根拠を含めて説明いただいています。キーワードとしては労働生産性・技能労働者不足・働き方改革。建設業に迫る避けられない課題が浮き彫りになります。 そしてこれらの課題に対して竹中工務店様では「新しいテクノロジーの活用」によって様々な取り組みに着手されています。その中からいくつかの取り組みをご説明いただきました。 最初にご説明いただいたのは登壇タイトルにもなっている建設デジタルプラットフォーム。デジタル活用が遅れていると言われることが多い建設業の中で、徹底した業務のデジタル化・デジタル活用を推進することで、生産性向上や生産性改革を推進するための仕組みとなります。 その他にもロボットの活用による労働環境改善や、新しい価値創造のためのスマートビル・オープンイノベーションといった取組による課題解決への動きをご説明いただいています。 後半では、建設デジタルプラットフォームを中心とした取組についてご紹介いただきました。建設デジタルプラットフォームは2021年11月より運用されており、事業に係る全てのデータを一元的に蓄積、AI等で高度利活用するための基盤と定義されています。データレイクのようなデータ基盤のみではなく、アプリケーション群と統合された基盤である点が特徴的です。アプリケーション群はIoT・BI・AIといったデータの高度利活用を担う部分になっています。 データ基盤についてはAWSのマネージドサービスを中心にした構成を取っていただいている部分も特徴の1つとなります。社内データはもとより社外データ・社外のサービス・前述のアプリケーション群との連携部分を含めて担う構成において、マネージドサービスの活用は非常に有効そうです。次にデータ集約・蓄積の機能についてご説明いただきました。まずは構造化データの集約・蓄積を整備し、活用できる状態にあるとのこと。今後は非構造データにも取り組む予定とのことです。非構造データの集約・蓄積・活用は注目度も高いと思いますので、今後の進化に期待したい部分です。基盤系の説明としては最後にIoT基盤についてのご説明をいただきました。一般的なIoT基盤と違い、都市OSなどの社外データ基盤との連携を視野に入れて、FIWAREを採用されている部分は特徴な部分では無いでしょうか。 そして基盤の次には実際のデータ活用の取り組みについていくつかご紹介いただきました。全社データ活用に向けた取り組みではデータ資産に対してのルールや体制整備に加えて、データ活用の民主化推進のための利用環境整備も実施しているというご説明がありました。データ活用ホームページの設置や、データカタログの整備など、利用者目線での取り組みは全社データ活用の大きな推進力の1つとなりそうです。またAIによるデータ活用についても具体的な例でご紹介いただいています。今回ご紹介いただいた例としては2点。1つ目は建物劣化診断。ファシリティマネジメントの領域で専門家の対応軽減を期待できる仕組みとして、適用範囲の拡大に現在も取り組まれているとのことでした。もう1つは安全情報分析。過去の労働災害データを元に、現在の作業所で予測される災害情報をAIで予測してアラートを出すという仕組み。各作業所での注意喚起に加えて、本社・本部での俯瞰管理用とでも活用されているとのことでした。 ※ AIを利用した建物劣化診断に関してはAWS Innovate -Data and Ai/ML Editionのオンデマンド配信にて、「 Amazon SageMakerを用いた建設業でのAIアプリ開発 」として佐藤氏よりご講演をいただいておりますのでこちらもご覧ください。 そして最後には更なるデータ活用への取り組みについてご紹介をいただきました。こちらも2つあり、1つ目は生成系AIなどの活用。最近話題の大規模言語モデル（LLM）の業務活用について検討・試行を進めておられるとのことです。生成系AIには大きな可能性を考えておられ、社内のデータサイエンティストにより組成されているアナリティクスチームを中心に業務部門を巻き込みながら取組を進めているとのこと。もう1つはデジタルツインの実現に向けての取組をご紹介いただきました。AWS IoT TwinMakerを活用した実際の画面等もご紹介いただいています。製造業では徐々に浸透を始めているデジタルツイン。建設業での実用にも期待がもたれます。 本登壇では幅広い形でデジタルデータ活用・デジタル変革への取組をご紹介いただきました。2024年に向けて大きな転換期を迎える建設業。竹中工務店様は建設デジタルプラットフォームを活用して、各種課題を解決していこうとされております。最先端技術の活用も含めて、今後の竹中工務店様の取組には注目が集まりそうです。 4. ファストデジタルツインでちゃぶ台返し～保全の現場から市場を創る、ものづくりを変える～ 資料ダウンロード ブラウンリバース株式会社 代表取締役 CEO 金丸様からは、“ファストデジタルツインでちゃぶ台返し〜保全の現場から市場を創る、ものづくりを変える〜”についてお話しいただきました。 プラント業界では、設備の高経年劣化、労働者不足、化石燃料設備統廃合や脱炭素などの市場変化へ対応をしなければならないことが経営課題となっています。また、現場目線で見ると人が少ないにもかかわらず、現場が遠く、広く、管理する設備の点数も多く、現場によっては中に入るたびに健康診断が必要であったり、クリーンルームを通る必要があったりと入るまでの手続きが多い状況になっています。このため、仮想空間上で三次元的に見られる仕組みがあると非常に助かるといった現場の声を聞きますが、今ある業界のツールを現場の設備管理の方が使うには機能が多すぎたり、自分の PC では動かないなどの理由でうまく使えてなかったりします。ブラウンリバース株式会社では Google Map のように直ぐに検索して使えるレベルの手軽さで設備管理の方が使えることを意識して INTEGNANCE VR の開発に取り組んでいます。 INTEGNANCE VR はファストデジタルツインをコンセプトに「いつでも」「どこでも」「誰でも」「すぐに」ご利用頂けるプラントの 3D マップ閲覧サービスで、圧倒的なモデル構築速度が売りの１つです。従来はレーザースキャナーを使ってモデル化しているが、三脚を立てて計測士がきちっと測って、エンジニアがプラントをモデル化していました。INTEGNANCE VR ではモビリティタイプのレーザースキャナーを利用して、400 m の競技場トラックぐらいのプラントであれば 1 日〜 2 日でスキャンし、翌日にはブラウザのビューワー上からお客様がプラントを確認できます。従来と比較して十分の一程度に提供時間を圧縮できます。また、スキャンした点群データや写真データは AWS に保管し、AWS 上のデータをリンクさせて、ビューワーをお客様のポータルのような使い方をしてもらって、図面を通してではなく、ブラウザを通してプラントの設備管理情報や整備記録をみたり、フランジ間の距離を測ったり、写真データにマーキングして情報共有したり、配管をナビゲーションする機能などを提供しています。 最後に産業界をひっくり返す２つのポイントについてもご説明頂きました。１つ目が、現場で見えているものと同じものが仮想空間にあるだけでは目的に到達するまでの時間や手間がかかり過ぎて敬遠される点で、紙ではできないタンクやタワーの断面を見られたり、重機の配置のシミュレーションが簡単にできると、現場の使い勝手が良いという話を頂けました。２つ目が、現場で色々な更新が行われていて、図面に落ちきっていないと、現場から図面に一所懸命に落とそうとして紙に縛られている点で、点群データなり写真データなりから検出した物体の前後関係を抽出して、図面に近い情報を引っ張り出して、機械が読み取れる情報に変換する仕組みができたら、紙から解放される世界ができるというメッセージをお伝えいただきました。 5. 現場業務変革を実現するAWSテクノロジー 資料ダウンロード 本セッションではAWS山下より現場の変革にAWSテクノロジーがお客様のデジタルトランスフォーメーション(DX)に、どのように貢献できるかについてお話しさせていただきました。 現場業務では、人、環境、セキュリティといった要素が課題として挙げられます。少子高齢化により労働集約的な資材配送業務で労働者の数が足りず、人件費の高騰が予測されます。環境といった側面では、温室効果ガス削減を前提としたオペレーションが求められています。鉄道・運輸や製造業・プラントはサイバー攻撃の対象とされる可能性が高いとされています。セキュリティ対応が義務化されていくという流れも見受けられます。 一方でこれらの課題を解決するためのDX推進活動において、避けられない課題もあります。鉄道・運輸の領域では膨大な器機からの大量データが集められているものの、保存されているだけで活動されていないとされています。製造業でもデータの90％は様々な環境に隔離されて保存されているという状況です。プラント業界でもデータの活用を進めているものの、実ビジネスに直結した活動は全体の30％程度と言われておりPoCの域を出ていません。やはりまだまだデータ活用に課題感があるのではないでしょうか。 DXの推進が進んでいないという訳ではなく、課題がありつつも進んでいるという認識です。DX白書ではアメリカの企業と比べて後れがあるものの20％以上の企業でAIやIoTが利用され、60％以上の会社でDXの成果が出ていると答えられています。日本において各社取り組みが進んでいるという認識です。 DX推進に必要なポイントとして、明確な課題、必要な技術、リスクを管理しながらチャレンジする環境が必要です。クラウドはこの3つの要素に対する解決策となり得ると考えています。スモールスタートで始められ、必要な時に必要なだけ利用できます。これによりアイディアから実装までの時間を短縮できると考えています。 産業分野の業務改善の流れとして、産業器機からの情報を取得するためのゲートウェイ、データの保管場所、データの可視化を行った上で、データを活用するという流れがあります。それぞれの領域においてAWSはサービスをご用意させていただいています。 本イベントでの講演で各社様が取り組まれていたAI/ML領域で、AWSは機械学習の開発者向け環境提供から、アプリケーションにAIを組み込む際に組み込みしやすいAIサービスをご用意しています。生成系AIのモデルは2018年より言語系だけで見ても数が増えており、AWSではコモディティ化が進むと考えています。Amazon Bedrockというサービスを発表しており、複数の企業が提供する基盤モデルから用途に最適なものを選択していただくことで、お客様に利用しやすい環境を提供するというコンセプトで開発しました。セキュリティに関しても様々なサービスをご用意しておりますのでぜひご利用いただければと思います。 関連記事リンク 【開催報告 ＆ 資料公開 】 鉄道業界向け DX セミナー 【開催報告】建設不動産 DX セミナー 建設業界パート 開催報告 この記事は以下のメンバーで担当しました。 竹川寿也 アマゾンウェブサービスジャパン合同会社 事業開発本部 シニア事業開発マネージャー 藤倉和明 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアソリューションアーキテクト 矢形拓也 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアソリューションアーキテクト 伊藤 一成 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 村田 京介 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 堀 竜慈 アマゾンウェブサービスジャパン合同会社 技術統括本部 アソシエイトリューションアーキテクト

前回の投稿 では、 Amazon Route 53 、 Amazon Relational Database Service (Amazon RDS) for SQL Server 、 Amazon Simple Storage Service (Amazon S3) を使用して、マルチリージョンのディザスタリカバリブループリントをデプロイしました。この記事では、AWS セカンダリリージョンで RDS for SQL Server を昇格させ、デプロイしたブループリントを使用してクロスリージョンフェイルオーバーを実行するプロセスについて説明します。 前回の投稿の簡単な振り返り 大まかに説明すると、次の手順を実行しました。 クロスリージョンリードレプリカで実行されている Amazon RDS for SQL Server データベースを確認します。 RDS インスタンスとのアプリケーション接続を設定するために Amazon Route 53 プライベートホストゾーン CNAME レコードを作成しました。 プライマリ AWS リージョンとセカンダリ AWS リージョン間のインターネットトラフィックを管理するように Amazon Route53 パブリックホストゾーンを設定しました。 ディザスタリカバリファイルをホストするために、両方のリージョンに個別の Amazon S3 バケットを作成しました。 パブリックドメイン名を使用してインターネットトラフィックの接続をテストしました。 このソリューションのアーキテクチャは、次の図に示されています。プライマリリージョンとセカンダリリージョンの両方が稼働している場合、Amazon Route53 はインターネットトラフィックをアクティブリージョン (この例では us-east-1 ) にルーティングします。インターネットトラフィックはパッシブリージョン (この例では us-east-2 ) にルーティングされません。 クロスリージョンフェイルオーバーに関する主な考慮事項: クロスリージョンフェイルオーバーを開始するには、さまざまな要因を十分に考慮する必要があります。考慮すべき重要な点をいくつか紹介します。 プライマリリージョンでアプリケーションが依存している 1 つ以上の AWS サービスが応答していないこと セカンダリリージョンにデプロイされたアプリケーション層は完全に更新され、主要な役割を引き受ける準備ができていること。Amazon Route 53 アプリケーションリカバリーコントローラーには、マルチリージョンの準備状況チェック機能があります。詳細については、 Amazon Route 53 アプリケーションリカバリーコントローラーの準備状況チェック を参照してください。 カスタマーサービスを回復する唯一の方法は、ライブトラフィックをセカンダリージョンに切り替えること セカンダリリージョンの RDS for SQL Server リードレプリカのレプリカラグは、ビジネスにとって許容可能な範囲 (RPO) を下回っていること。レプリカラグがゼロでない状態でクロスリージョンフェイルオーバーを開始すると、データが失われる可能性があります。詳細については、「 SQL Server リードレプリカの問題のトラブルシューティング 」を参照してください。 次の図は、ディザスタリカバリイベント中のアーキテクチャを示しています。 クロスリージョンフェイルオーバーの手順: イベントの順序に従って、このソリューションがどのように機能するかを見てみましょう。 ディザスタリカバリイベントを宣言し、SQL Server インスタンスのプライマリ RDS への書き込みを無効にします。 RDS for SQL Server クロスリージョンリードレプリカをセカンダリージョンのスタンドアロン DB インスタンスに昇格させます。 RDS for SQL Server リードレプリカの昇格が成功したら、 スモークテスト と呼ばれることが多いエンドツーエンドの検証を実施します。この検証プロセスにより、アプリケーションが正しく機能し、セカンダリ AWS リージョンで外部トラフィックを受け入れる準備ができていることを確認します。 ディザスタリカバリブループリントとともにデプロイされた Amazon S3 バケットにディザスタリカバリファイルを作成してアップロードします。Route53 パブリックレコードヘルスチェックの HTTP エンドポイントで指定されているのと同じファイル名を使用してください。 このファイルをアップロードすると、プライマリリージョンの Route 53 ヘルスチェックが失敗し、セカンダリリージョンへのフェイルオーバーが開始されます。 セカンダリリージョンへのフェイルオーバーが完了したら、アプリケーションスタックとデータベースの正常性を確認し、それらが正しく機能していて外部トラフィックを受信していることを確認します。このステップで、アプリケーションのダウンタイムは完了です。 セカンダリリージョンの RDS インスタンスを変更し、マルチ AZ オプションを有効にして、リージョン内の高可用性を再度有効にします。これは、RDS for SQL Server インスタンスにクロスリージョンリードレプリカを作成する際の前提条件でもあります。 AWS リージョンのプライマリリージョンが利用可能になったら、新しい RDS for SQL Server クロスリージョンレプリカを手動で作成して、クロスリージョンディザスタリカバリソリューションを再作成します。 Route53 のプライベートホストゾーン rds_sqlserver_private_hosted_zone を変更し、 rdsprimarydb.rds_sqlserver_private_hosted_zone CNAME レコードを更新して、プライマリリージョンに新しく作成されたリードレプリカを指すようにします。 フェイルオーバーの実装 クロスリージョンフェイルオーバーを開始するには、次の手順に従います。 ディザスタリカバリイベントを宣言し、プライマリリージョンの SQL Server インスタンスの RDS への書き込みを無効にします。アプリケーションがアクセスできる場合は、DR のフェイルオーバー中に現在のプライマリデータベースに誤って書き込まれないようにアプリケーションを停止します。 セカンダリリージョンでは、 Amazon CloudWatch メトリックスの Replica Lag を使用して SQL Server の RDS リードレプリカの遅延（ラグ）を確認します。この クエリ をプライマリデータベースで実行して、すべてのリードレプリカのレプリケーションラグに関する情報を取得することもできます。クロスリージョンのレプリケーションラグがゼロか、ビジネスで許容できる範囲 (RPO) を下回っている場合にのみ、次のステップに進んでください。レプリケーションラグがゼロでない状態でクロスリージョンフェイルオーバーを開始すると、データが失われる可能性があります。 Amazon Route 53 コンソール に移動します。 パブリックホストゾーンを選択し、ルーティングポリシーを確認します。 Amazon Route 53 ヘルスチェックダッシュボード に移動します。 プライマリリージョンのヘルスチェックレコード用の S3 ファイルエンドポイントの URL を書き留めておきます。この段階では、両方のリージョンのヘルスチェックの状態が正常である必要があります。 プライベートホストゾーン rds_sqlserver_private_hosted_zone に移動して CNAME エントリを確認します。セカンドリージョンのアプリケーションスタックは rdssecondarydb.rds_sqlserver_private_hosted_zone の CNAME レコードを使って RDS インスタンスに接続します。 セカンドリージョンで、RDS for SQL Server クロスリージョンリードレプリカを昇格させます。 AWS Lambda 関数 を作成して、このステップを自動化することもできます。参考となる Python コードは、この GitHub リポジトリ で見つけることができます。関数の作成手順については、 AWS Lambda 開発者ガイド を参照してください。 RDS for SQL Server インスタンスを昇格しても、RDS エンドポイント URL は変更されません。したがって、Route53 プライベートホストゾーンの CNAME レコードを更新する必要はありません。アプリケーションは、 rdssecondarydb.rds_sqlserver_private_hosted_zone レコードを使用して、昇格した RDS for SQL Server インスタンスに接続できます。 内部 スモークテスト またはアプリケーションの健全性チェックを実行してアプリケーションが正しく機能し、セカンダリリージョンでインターネットトラフィックを受け入れる準備ができていることを確認します。 セカンダリリージョンのアプリケーションスタックがインターネットトラフィックを受け入れる準備ができたら、フェールフェイルオーバープロセスを開始します。 手順 6 を参照してリカバリファイルの URL を取得します。このリカバリファイルをセカンダリリージョンの Amazon S3 バケットにアップロード します。この例では、ファイル名は initiate_failover.dr です。 このファイルを Amazon S3 バケットにアップロードすると、プライマリリージョンの Route53 ヘルスチェックが失敗します (Route 53 ヘルスチェックで ヘルスチェックステータスを反転する オプションを有効にしたことを思い出してください)。プライマリリージョンが異常とマークされると、Route53 はインターネットトラフィックのセカンダリリージョンへのフェイルオーバーを開始します。フェイルオーバーの遅延は、ヘルスチェック設定、 リクエスト間隔 、および 失敗しきい値 によって異なります。 フェイルオーバーが完了すると、アプリケーションはセカンダリ AWS リージョンでインターネットトラフィックの受信を開始します。 このステップではアプリケーションはダウンタイムから回復しますが、単一の AWS アベイラビリティゾーンで実行されます。リージョン内の高可用性をセットアップするには、セカンダリリージョンの RDS インスタンスを 変更 し、Amazon RDS for SQL Server のマルチ AZ を有効にします。 AWS プライマリリージョンが再び利用可能になったら、新しい RDS for SQL Server クロスリージョンリードレプリカを手動で作成して、クロスリージョンの災害復旧ソリューションを再作成します。 Route 53 プライベートホストゾーン rds_sqlserver_private_hosted_zone を更新し、新しい RDS for SQLServer クロスリージョンリードレプリカエンドポイントを使用して CNAME レコード値 rdsprimarydb.rds_sqlserver_private_hosted_zone を編集します。 次の図は、フェイルオーバー後の最終的なアーキテクチャを示しています。 後片付け このソリューションを実装するために作成されたリソースを削除するには、次の手順を実行します。 作成したパブリックおよびプライベートのホストゾーンを削除します。 アプリケーション構成を元の状態に変更します。 作成した Amazon S3 バケットを削除します。 まとめ この投稿では、アクティブ/パッシブ戦略を採用したマルチリージョン構成でデプロイされたアプリケーションのフェイルオーバープロセスについて説明しました。 Amazon Route 53 パブリックホストゾーンポリシーは、プライマリリージョンとセカンダリリージョン間のトラフィックをフェイルオーバーします。 Amazon Route53 プライベートホストゾーンポリシーは、適切なデータベースエンドポイントへのトラフィックのルーティングを処理します。これにより、アプリケーションが使用する統一された共通エンドポイントが提供され、障害時にアプリケーション構成を変更する必要がなくなります。 AWS Lambda 関数を使用して、RDS インスタンスの昇格に必要な手動タスクのスクリプトを作成できます。関数を 手動 でトリガーすることも、 イベントを使用する こともできます。 AWS アカウントでこのソリューションを試してください。 著者について Ravi Mathur は、AWS のシニアソリューションアーキテクトです。彼はお客様と連携して、さまざまな AWS サービスに関する技術支援やアーキテクチャに関するガイダンスを提供しています。彼は、さまざまな大規模企業でソフトウェアエンジニアリングとアーキテクチャの役割に数年間携わった経験を持っています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

ディザスタリカバリ (災害復旧) と高可用性計画は、事業運営の回復力と継続性を確保する上で重要な役割を果たします。AWS でのディザスタリカバリ戦略を検討する場合、主要な選択肢は 2 つあります。リージョン内のディザスタリカバリとリージョン間のディザスタリカバリです。リージョン内ディザスタリカバリとリージョン間のディザスタリカバリのどちらを選択するかは、アプリケーションとデータの重要性、規制要件、ユーザーの地理的分布、コスト、複雑さなど、さまざまな要因によって異なります。 AWS にマルチリージョンのディザスタリカバリソリューションを実装するには、まずインフラストラクチャの重要なコンポーネントを特定し、各コンポーネントに必要な目標復旧時点 (RPO) と目標復旧時間 (RTO) を決定する必要があります。RPO は許容できる最大データ損失量であり、RTO はシステムを復元するために定められた時間までにかかる最大時間です。 2023 年 7 月現在、 AWS クラウド は世界 31 の地理的リージョンにある 99 のアベイラビリティーゾーンにまたがっています。AWS はまた、カナダ、イスラエル、マレーシア、ニュージーランド、タイに 15 のアベイラビリティーゾーンと 5 つの AWS リージョンを追加する計画も発表しました。 Amazon Relational Database Service (Amazon RDS) は、クラウドでのデータベースのセットアップ、運用、スケーリングを簡単にするマネージドサービスです。 MySQL 、 MariaDB 、 PostgreSQL 、 Oracle 、 SQL Server などの一般的なエンジンから選択できます。 このシリーズでは、さまざまな AWS リージョンで可能な限りの高可用性とディザスタリカバリを必要とする重要なアプリケーションのニーズに焦点を当てます。この最初の投稿では、2 つの AWS リージョンにまたがって Amazon RDS for SQL Server 、 Amazon Route53 、 Amazon Simple Storage Service(Amazon S3) を使用するアプリケーションのフェイルオーバー戦略を確立するプロセスをご案内します。次の投稿では、このプランを使用して実際にフェイルオーバーを実行する方法を示します。 ソーリューション概要 このソリューションは、アクティブ/パッシブ戦略を採用した 2 つの AWS リージョンにデプロイされて、プライマリ (アクティブ) リージョンがワークロードをホストしてトラフィックを処理します。セカンダリ (パッシブ) リージョンはディザスタリカバリに使用されます。フェイルオーバーポリシーが設定された Amazon Route53 パブリックホストゾーンは、プライマリリージョンとセカンダリリージョンの間でインターネットトラフィックをルーティングするために作成されます。Amazon Route 53 プライベートホストゾーン CNAME レコードは RDS for SQL Server エンドポイントを格納します。アプリケーションはこれらのレコードを使用してデータベースに接続します。 次の図は、このアーキテクチャの主要なコンポーネントを示しています。 この例では、プライマリ AWS リージョンは us-east-1、セカンダリ AWS リージョンは us-east-2 です。さらに、次の点にも注意してください。 Amazon RDS for SQL Server マルチ AZ DB インスタンスはプライマリ AWS リージョンにデプロイされ、クロスリージョンリードレプリカはセカンダリリージョンにあります。 Amazon RDS for SQL Server は、 分散可用性グループ を使用してクロスリージョンリードレプリカ (非同期レプリケーション) を設定します。 アプリケーションスタックは両方のリージョンにデプロイされ、リリースバージョンは同じです。 インターネットトラフィックを処理する Amazon Route53 パブリックホストゾーン には “フェイルオーバー” ルーティングポリシー が設定されています。 Amazon Route53 プライベートホストゾーン は、SQL Server インスタンス接続のための RDS へのアプリケーション用の “シンプル” ルーティングポリシーで設定されています。 スタンバイがプライマリを引き継ぐ Amazon Route 53 パブリックホストゾーン のフェイルオーバーポリシーは、Standby takes over primary (スタンバイがプライマリを引き継ぐ) アプローチを使用して実装されます。この方法では、プライマリリージョンの Route53 ヘルスチェックが HTTP エンドポイントのアクセシビリティを検証します。そのエンドポイントはセカンダリリージョンに保存されている Amazon S3 ファイルになります。たとえば、AWS リージョン us-east-2 に examplebucket123 という名前の Amazon S3 バケットがあり、ファイル名が initiate_failover.dr の場合、この S3 ファイルにアクセスするための対応するエンドポイントは次のようになります。 https://examplebucket123.s3.us-east-2.amazonaws.com/initiate_failover.dr このヘルスチェックは、指定されたエンドポイントから受信した HTTP 応答が 4xx または 5xx のステータスコード (つまり、Route 53 ヘルスチェックエージェントがその Amazon S3 ファイルエンドポイントを解決できない) を返したときに正常と見なされます。逆に、レスポンスで 2xx または 3xx のステータスコードが返された場合、ヘルスチェックは失敗します (つまり、Route 53 ヘルスチェックエージェントは Amazon S3 ファイルエンドポイントを解決できたということです)。この方法は Route53 Invert ヘルスチェック と呼ばれます。この方法では、プライマリ AWS リージョンとセカンダリ AWS リージョン間のフェイルオーバーを手動で制御できるだけでなく、スタンバイリージョンのリソースに障害が発生した場合の偶発的なフェイルオーバーを防ぐこともできます。ディザスタリカバリ時には、このファイルをセカンダリリージョンの S3 バケットにアップロードしてください。これにより、プライマリリージョンの Route53 ヘルスチェックが意図的に失敗します。 HTTP ステータスコードのリスト については、このドキュメントを参照してください。信頼性の高いフェイルオーバーメカニズムを設計するさまざまなアプローチを包括的に理解するには、「 Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズム 」を参照してください。 インターネットトラフィックをセカンダリリージョンに自動的にフェイルオーバーすることは推奨されないことに注意してください。プライマリリージョンのネットワーク障害が短時間発生したような状況では、自動フェイルオーバーによってダウンタイムが長くなる可能性があります。 前提条件 このソリューションを実装するには、次のものが必要です。 プライマリリージョンのアプリケーションスタックと Amazon RDS for SQL Server マルチ AZ インスタンス。 セカンダリリージョンのアプリケーションスタックと Amazon RDS for SQL Server リードレプリカインスタンス (クロスレプリケーション)。手順については、「 Amazon Relational Database Service for SQL Server でクロスリージョンのリードレプリカを使用する 」を参照してください。 リードレプリカの作成後にプライマリ DB インスタンスで作成されたサーバーレベルのオブジェクト (ログイン、SQL エージェントジョブなど) は自動的にレプリケートされないため、リードレプリカで手動で作成する必要がありす。そのため、これらのオブジェクトがプライマリリージョンとセカンダリリージョンの間で同期していることを確認してください。詳細については、 Amazon RDS のドキュメント を参照してください。 ウォークスルー このソリューションを導入するには、次の手順を実行します。 プライマリリージョンの Amazon Relational Database service (RDS) コンソール に移動します。 SQL Server インスタンスのプライマリ RDS のエンドポイントを書き留めておきます。 同様に、 セカンダリリージョンの Amazon RDS コンソール に移動します。 RDS for SQL Server クロスリージョンリードレプリカのエンドポイントを書き留めておきます。 Amazon Route53 コンソール に移動します。 新しい プライベートホストゾーン を 作成します 。 両方のリージョンの VPC をプライベートホストゾーンに関連付けます。これはプライベートホストゾーンは Amazon VPC 内でトラフィックをルーティングするために必要です。 プライベートホストゾーンを作成したら、 シンプルルーティングポリシー で 2 つの CNAME レコードを追加します。この例では、以下の CNAME レコードを作成しました。 rdsprimarydb.rds_sqlserver_private_hosted_zone – プライマリリージョンの RDS for SQL Server に接続します。 rdssecondarydb.rds_sqlserver_private_hosted_zone – クロスリージョンリードレプリカの RDS for SQL Server に接続します。 両方の CNAME レコードを追加すると、プライベートホストゾーンは次のスクリーンショットのようになります。 データベース接続文字列のデータベースホスト名として CNAME レコード rdsprimarydb.rds_sqlserver_private_hosted_zone を使用してプライマリリージョンのアプリケーション設定を更新してください。 同様に、CNAME レコード rdssecondarydb.rds_sqlserver_private_hosted_zone を使用して、セカンダリリージョンのアプリケーションを更新します。このステップにより、アプリケーションが RDS エンドポイントを直接使用していないことが保証されます。そのため、フェイルオーバー中にアプリケーションを変更する必要はありません。 次の Python コードは、プライベートホストゾーン CNAME レコードを使用して RDS for SQL Server インスタンスに接続するコードの例です。 プライマリリージョンとセカンダリリージョンの両方に新しい Amazon S3 バケットを作成します。これらの S3 バケットはホストディザスタリカバリファイル専用です。ヘルスチェックプロセスのセキュリティと整合性を確保するには、このバケットへのアクセスを権限のある担当者のみに制限することが重要です。プライマリリージョンとセカンダリリージョンの両方が正常であれば、この時点でこれらのバケットは空のままにしておくことができます。 Amazon Route53 コンソール に移動し、 Route53 パブリックホストゾーン を作成して、パブリックドメインのインターネットトラフィックを管理します。 パブリックホストゾーンを作成したら、 Amazon Route53 ヘルスチェックコンソール に移動します。 新しい Route53 ヘルスチェックを 2 つ作成します。1 つはプライマリリージョンのフェイルオーバー用、もう 1 つはセカンダリリージョンのフェイルオーバー用です。これらのヘルスチェックは、プライマリリージョンのフェイルオーバーレコードとセカンダリリージョンのフェイルオーバーレコードに紐付けられます。 「ヘルスチェックの作成」ページで、以下を行います。 プライマリリージョンのヘルスチェック名を入力します。 次に、モニタリング対象の [ エンドポイント ] オプションを選択します。 エンドポイントの監視 のセクションで、[ ドメイン名 ] に入力してプロトコルに [ HTTPS ] を選択します。 [ドメイン名] で、セカンダリリージョンの Amazon S3 バケットエンドポイントを指定します。例 : examplebucket123.s3.us-east-2.amazonaws.com [パス] で、ディザスタリカバリファイル名を指定します。例 : initiate_failover.dr 「高度な設定」セクションで 失敗しきい値 と リクエスト間隔 を指定します。 [ ヘルスチェックステータスを反転 ] のオプションにチェックを入れ、[次へ] をクリックします。 [ ヘルスチェックの作成 ] をクリックします。 同じ手順を繰り返して、セカンダリリージョンのヘルスチェックレコードを作成します。 プライマリリージョンのヘルスチェックでは、セカンダリリージョンの S3 ファイルエンドポイントを指定します。その逆も同様です。プライマリリージョンにアクセスできなくなった場合は、セカンダリリージョンの S3 ファイルを変更してフェイルオーバーを開始できます。 プライマリリージョンとセカンダリリージョンのヘルスチェックが作成されると、Amazon Route53 はヘルスチェックを開始してステータスを報告します。 ステップ 13 で作成した Route53 パブリックホストゾーン に移動して、以下の手順を実行します。 フェイルオーバールーティングポリシー を使用してレ コードを作成 します。 [ フェイルオーバーレコードを定義 ] をクリックします。 このレコードをアプリケーションターゲットに関連付けます。たとえば、Route53 はアプリケーションロードバランサー、API ゲートウェイ、VPC エンドポイント、S3 エンドポイントなどをサポートしています。この例では、アプリケーション負荷分散ターゲットが選択されています。 プライマリリージョンを選択。 対象のロードバランサーを選択します。 フェイルオーバーレコードタイプを プライマリ に指定します。 プライマリリージョン用に作成されたヘルスチェックレコードを選択してください。 ターゲットヘルス評価オプションを無効にします。 サブミット 同様の手順を繰り返して、2 番目のレコードタイプ用に別のレコードを作成します。 パブリックホストゾーンの設定が完了すると、以下のスクリーンショットのようになります。 これで、Amazon Route53、Amazon S3、および Amazon RDS for SQL Server によるディザスタリカバリブループリントのデプロイが完了しました。この時点で、インターネットトラフィックを介してアプリケーションにアクセスできるはずです。 後片付け このシリーズの次回の記事では、このブルーポイントを使用して、クロスリージョンフェイルオーバーを実行する方法を示します。したがって、継続する予定がある場合は、このデプロイで作成されたすべてのリソースを保存しておいてください。 このソリューションを実装するために作成されたリソースを削除するには、次の手順を実行します。 作成したパブリックホストゾーンとプライベートホストゾーンを削除します。 アプリケーション構成を元の状態に変更します。 作成した Amazon S3 バケットを削除します。 まとめ この記事では、クロスリージョンのディザスタリカバリブループリントを実施する方法についてのガイダンスを提供しました。Amazon Route53 のパブリックホストゾーンポリシーの「スタンバイがプライマリを引き継ぐ」アプローチにより、組織はフェイルオーバープロセスの制御を維持し、プライマリリージョンにアクセスできなくなったときに手動でフェイルオーバーを開始できます。 このシリーズの 次回の記事 では、AWS セカンダリリージョンで RDS for SQL Server を昇格するプロセスと、デプロイしたブループリントを使用してクロスリージョンフェイルオーバーを実行するプロセスについて詳しく説明します。 著者について Ravi Mathur は、AWS のシニアソリューションアーキテクトです。彼はお客様と連携して、さまざまな AWS サービスに関する技術支援やアーキテクチャに関するガイダンスを提供しています。彼は、さまざまな大規模企業でソフトウェアエンジニアリングとアーキテクチャの役割に数年間携わった経験を持っています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

SageMaker Canvas は、生成系 AI を使用してコンテンツを生成および要約するための基盤モデル ( FM ) を、簡単に使えるモデルとしてサポートする ようになりました。自然言語を会話型チャットインターフェイスと併用すると、説明文、レポート、ブログ投稿の作成、質問への回答、メ自然言語を会話型チャットインターフェイスと併用すると、説明文、レポート、ブログ投稿の作成、質問への回答、メモや記事の要約、概念の説明などのタスクを、コードを 1 行も記述せずに実行できます。お客様のデータは、基盤モデルの改善には使用されず、サードパーティのモデルプロバイダーと共有されることもなく、完全に安全な AWS 環境内に留まります。 SageMaker Canvas では、 Amazon Bedrock モデル ( Anthropic の Claude 2 や AI21 Labs の Jurassic-2 など ) や、公開されている Amazon SageMaker JumpStart モデル ( Falcon-7B-Instruct 、Falcon-40B-Instruct など) を含むさまざまな FM にアクセスできます。1 つのモデルまたは最大 3 つのモデルを使用して、モデルの応答を並べて比較できます。SageMaker Canvas では、Amazon Bedrock モデルは常にアクティブになっているため、すぐに使用できます。SageMaker JumpStart モデルはオンデマンドで AWS アカウントで起動およびデプロイでき、2 時間操作がないと自動的にシャットダウンされます。 SageMaker Canvas の生成系 AI 機能を使用する方法を見てみましょう。この投稿では、架空のエンタープライズカスタマーサポートのユースケースを例として取り上げます。 前提条件 前提条件となる以下のステップを完了してください。 AWS アカウント を作成します。 SageMaker Canvas をセットアップし、オプションでインターネットにアクセスできない VPC を使用するように 設定 します。 Amazon Bedrock でモデルアクセスを設定します。 必要に応じて、お住まいの地域の g5.12xlarge と g5.2xlarge の サービスクォータ の増加をリクエストしてください。これらのインスタンスは SageMaker JumpStart モデルのエンドポイントをホストするために必要です。他のインスタンスは、可用性に基づいて選択できます。 顧客からの苦情の処理 あなたが自転車会社の苦情を処理するカスタマーサポートアナリストだとしましょう。顧客からの苦情を受けた場合、SageMaker Canvas を使用して苦情を分析し、顧客への個別の対応を生成できます。そのためには、以下のステップを完了してください。 SageMaker コンソールのナビゲーションペインで Canvas を選択します。 ドメインとユーザープロファイルを選択し、 Open Canvas を選択して SageMaker Canvas アプリケーションを開きます。 また、SageMaker Canvas には、最初に SageMaker コンソールにアクセスしなくても、 シングルサインオン やその他の既存の ID プロバイダー ( IDP ) を使用してアクセスできます。 Generate, extract and summarize content を選択してチャットコンソールを開きます。 Claude 2 モデルを選択した状態で、指示を入力して、自転車に関する苦情に対する顧客の感情を取得し、 Enter キーを押します。 特に苦情が長い場合は、自転車の具体的な問題を知りたいと思うかもしれません。だから、自転車の問題点を聞いてください。SageMaker Canvas はチャットのコンテキストを保存するので、苦情を再投稿する必要はないことに注意してください。 お客様の問題を理解したので、会社のフィードバックフォームへのリンクを含む回答を送信できます。 入力ウィンドウで、顧客からの苦情への回答をリクエストします。 FM から別のレスポンスを生成したい場合は、レスポンスセクションの更新アイコンを選択します。 元の回答とすべての新しい回答は、回答セクション内でページ分けされます。新しいレスポンスは元のレスポンスとは異なることに注意してください。必要に応じて、応答セクションのコピーアイコンを選択して、応答を電子メールまたは文書にコピーできます。 特定の変更をリクエストすることで、モデルの応答を変更することもできます。たとえば、モデルに50ドルのギフトカードオファーをメールの返信に追加するように依頼してみましょう。 モデル応答の比較 複数のモデル (最大 3 つ) のモデルからの応答を比較できます。Amazon Bedrock の 2 つのモデル ( Claude 2 と Jurassic-2 Ultra ) を SageMaker JumpStart モデル ( Falcon-7B-Instruct ) と比較して、評価してユースケースに最適なモデルを見つけてみましょう。 New chat を選択してチャットインターフェースを開きます。 モデルのドロップダウンメニューで、 Start up another model を選択します。 Foundation models ページの Amazon SageMaker JumpStart models で Falcon-7B-Instruct を選択し、右側のペインで Start up model を選択します。 モデルの起動には約 10 分かかります。 Foundation models ページで、次のステップに進む前に、Falcon-7B-Instruct モデルがアクティブであることを確認します。 New chat を選択してチャットインターフェースを開きます。 Compare を選択して 2 番目のモデルのドロップダウンメニューを表示し、もう一度 Compare を選択すると 3 番目のモデルのドロップダウンメニューが表示されます。 最初のドロップダウンメニューで Falcon-7B-Instruct モデルを選択し、2 番目のドロップダウンメニューで Claude 2 モデルを選択し、3 番目のドロップダウンメニューで Jurassic-2 Ultra モデルを選択します。 チャット入力ボックスに指示を入力し、 Enter キーを押します。 3 つのモデルすべてからの応答が表示されます。 2023/11/02時点で、Falcon-7B-Instruct、Jurassic-2が日本語未対応のため、英語で「顧客からの苦情の処理」と同内容のメールを生成しています。 クリーンアップ SageMaker Canvas から起動した SageMaker JumpStart モデルはどれも、2 時間操作がないと自動的にシャットダウンされます。コストを節約するためにこれらのモデルをより早くシャットダウンしたい場合は、このセクションの指示に従ってください。Amazon Bedrock モデルはアカウントにデプロイされていないため、これらをシャットダウンする必要はないことに注意してください。 SageMaker JumpStart の Falcon-40B-Instruct モデルをシャットダウンするには、次の 2 つの方法から選択できます。 結果比較ページで、Falcon-7B-Instruct モデルのオプションメニュー (3 つのドット) を選択し、次に Shut down mode を選択します。 または、New chat を選択し、model ドロップダウンメニューで Start up another model を選択します。次に、 Foundation models ページの Amazon SageMaker JumpStart models で Falcon-7B-Instruct を選択し、右側のペインで Shut down model を選択します。 左側のペインで Log out を選択して SageMaker Canvas アプリケーションからログアウトし、 SageMaker Canvas ワークスペースインスタンスのセッション時間の消費 を停止し、ワークスペースインスタンスが使用していたすべてのリソースを解放します。 結論 この投稿では、SageMaker Canvas を使用して、Amazon Bedrock と SageMaker JumpStart のすぐに使用できるモデルを使用してテキストを生成する方法を学びました。Claude 2 モデルを使用して、コードを 1 行も記述せずに、顧客の苦情に対する感情を分析し、質問をして、回答を生成しました。また、公開モデルを開始し、3 つのモデルからの回答を比較しました。 Amazon Bedrock モデルの場合、 Amazon Bedrock の料金ページ にあるように、入力トークンと出力トークンの量に基づいて課金されます。SageMaker JumpStart モデルは SageMaker インスタンスにデプロイされるため、 Amazon SageMaker の料金ページ  に従って、インスタンスタイプに基づいて使用期間分の料金が請求されます。 SageMaker Canvas は、ビジネスアナリストがさまざまなユースケースに対応する ML モデルを構築できる、コード不要の視覚的でインタラクティブなワークスペースで AI を民主化し続けています。SageMaker Canvas の新しい生成系AI 機能を今すぐ試してみてください。これらの機能は、 Amazon Bedrock または SageMaker JumpStart が利用可能なすべてのリージョンで利用できます。 原文は こちら です。ソリューションアーキテクトの濱野谷(@yoshiehm)が、英語版を元に翻訳しました。 著者について Anand Iyer は 2016 年から AWS の主任ソリューションアーキテクトを務めています。Anand は、世界中のヘルスケア、ファイナンスサービス、電気通信のクライアントが AWS とハイブリッドクラウドテクノロジーを使用してエンタープライズソフトウェアソリューションを設計および実装するのを支援してきました。ルイジアナ州立大学バトンルージュ校でコンピューターサイエンスの修士号を、ロサンゼルスの USC マーシャル・スクール・オブ・ビジネスで経営学修士号を取得しています。セキュリティ、ソリューションアーキテクチャ、DevOps エンジニアリングの分野で AWS の認定を受けています。 Gavin Satur は、アマゾンウェブサービスの主任ソリューションアーキテクトです。彼は企業のお客様と協力して、戦略的で優れた設計のソリューションを構築し、自動化に情熱を注いでいます。仕事以外では、家族との時間、テニス、料理、旅行を楽しんでいます。 Gunjan Jain は SoCal の AWS ソリューションアーキテクトで、主に大手ファイナンスサービス会社で働いています。クラウドの運用、クラウドの最適化、クラウド上で優れた設計を実現するためのベストプラクティスの採用を支援しています。 Harpreet Dhanoa は AWS で経験を積んだシニアソリューションアーキテクトで 、スケーラブルな分散システムの設計と構築において豊富な経歴を持っています。機械学習、オブザーバビリティ、分析に情熱を注いでいます。彼は、大規模な顧客がクラウドエンタープライズ戦略を構築し、AWS でビジネスを変革するのを支援することを楽しんでいます。自由時間には、ハープリートは2人の息子とバスケットボールをしたり、家族と過ごしたりしています。

本ブログでは、日本語 LLM の OSS である OpenCALM を LoRA (Low-Rank Adaptation) を用いた Fine-Tuning によりクイズ回答の精度を向上させるコードを SageMaker Studio Lab 上で実行することに挑戦します。最初に背景や課題についてご説明しますが、早速動かしてみたい方は、 SageMaker Studio Lab で日本語 LLM OpenCALM を動かす準備 からお読みいただくとスムーズです。 制限事項 執筆時点で SageMaker Studio Lab には CPU と GPU いずれも 1 日あたり連続の利用時間上限が決められています。また、閉域接続するオプションがなくインターネットフェーシングするサービスになります。好評いただいているサービスのため、特に GPU の利用時に一度では Start runtime できず複数回トライいただく場合があります。これらの特徴と上手にお付き合いいただきご利用いただければ嬉しいです。 日本語 LLM を学習してみたいけど、、、 最近、日本語 LLM (Large Language Model) の OSS が複数出現し、プライベートでも企業用途でも気になってらっしゃる方が多いのではないでしょうか？生成系 AI の一種である 日本語 LLM を使えば、 RAG (Retrieval Augmented Generation) を用いたエンタープライズサーチやチャットボットの高度化を日本語対応する形で実現できます。エンタープライズサーチもチャットボットもユーザが必要とする情報を取得するための手段であり、その高速化、高精度化は多くのユースケースに効果をもたらします。ソリューションアーキテクトとして日々お客様と相対させていただく中で、生成系 AI のお問合せの中でも RAG に関する議論が多いのはこのような背景からだと考えています。お客様からよくいただくご質問をいくつかピックアップしてみます。 ・ RAG に用いる LLM は学習する必要があるか？ RAG における LLM の学習の考え方には 3 つの選択肢があります。 学習済みの LLM をそのまま利用する（再学習しない） 学習済みの LLM を 再学習 (Fine-Tuning) して利用する LLM を一から学習して利用する 注意いただきたいのは、上記いずれも RAG 方式を採用することでお客様独自のデータに基づいた回答をすることが可能であるという点です。1, 2, 3 の順に学習に関する専門知識の必要性、開発、ランニングコストが大きくなる傾向があります。そのため、取り組みやすさも 1, 2, 3 の順と言って良いでしょう。1 から取り組んで、課題が発生した場合の対策として、2, 3 に進むステップでの検証方法をお伝えすることがあります。 ・ RAG に用いる LLM に日本語 LLM の OSS を使いたいが、その場合でも上記の考え方は同じか？ 基本的には同じであると考えています。日本語 LLM の OSS をご利用いただく場合は SageMaker を用いて推論用の Web API をホストいただく方法があります。コスト、データ保護、社内ポリシーなどの理由により自社で LLM モデルを管理したい場合には優れた選択肢の一つです。 ・ プロプライエタリのモデルよりも、OSS の LLM を再学習した方が精度が上がる可能性はあるか？ 可能性があります。こちらの ブログ をご覧ください。 株式会社サイバーエージェント様から 2023 年 5 月 11 日に公開された日本語大規模言語モデル である OpenCALM を Fine-Tuning した場合と、ChatGPT とを比較しています。 これらの議論をすると、「自社でも LLM を Fine-Tuning してみたい」というお話に発展するのですが、できるだけ小さなステップから始めることに越したことはありません。生成系 AI を費用対効果よくご利用いただくための GPU, Trainium , Inferentia を搭載した EC2 や、機械学習ワークロードに全面的に活用いただける SageMaker を LLM の Fine-Tuning にも有用なサービスとして AWS からご提供しています。しかしながら、これから AWS アカウントを取る必要があるお客様もいれば、自社内にアカウントがあっても必要な権限が付与されていない場合もあるでしょう。かと言って、GPU を搭載したマシンを購入いただいて検証を始めるというのも調達に時間と手間がかかってしまいます。 SageMaker Studio Lab という選択肢 そこで、AWS では SageMaker Studio Lab を提供しています。AWS アカウント不要の無料の Notebook サービスです。AWS アカウントとは別であり、メールアドレスがあれば登録することができます。始め方は こちら です。 SageMaker Studio Lab は 機械学習帳とも連携 しており、SageMaker Studio Lab を使ってすぐに機械学習のスキル獲得を始めていただく事ができます。 無料のノートブックと聞いて、以下のような懸念を感じる方もいらっしゃるのではないでしょうか？ GPU を使うと有料になるのではないか？ いいえ、SageMaker Studio Lab では GPU を無料でご利用いただけます ストレージを利用すると有料になるのではないか？ いいえ、SageMaker Studio Lab では 15 GB のディスク領域をご利用いただけます また、一度 Stop Runtime してしまうと消えてしまう領域とはなりますが、上記以外のディスク領域を活用いただく事が可能です (後述 RoLAで重要な要素となります) 使用できるライブラリや Python のバージョンが固定されているのではないか？ いいえ、上記の通り、Stop Runtime しても消えないストレージ領域に Conda 環境を保存いただくことで、継続的にご利用可能なお客様環境を構築いただく事ができます SageMaker Studio Lab 上で開発したものを別の開発環境に持っていくことが難しいのではないか？ Git Repository と連携が可能です SageMaker Studio への移行 が可能です これらの懸念の大元にあるのは、「一回きりの利用には良いが、継続して開発する環境としては不十分ではないか？」という観点です。勉強から始めて、せっかくなら、作った環境や成果物を今後も活用したいという要求に対して、SageMaker Studio Lab では上記のように機能を提供しています。さらに、SageMaker Studio Lab では作成した Notebook を AWS の大きな計算機リソースを活用してバッチジョブ化するための機能である Notebook Jobs という機能を提供しています（リンクは SageMaker のものですが同じボタンが SageMaker Studio Lab にもあるとお考えください）。こちらはAWSアカウントを取得する必要があり、SageMakerの利用に伴う料金が発生する点に注意が必要です。重要なことは、SageMaker Studio Lab が提供する計算機リソースを越えて、学習や推論を実行したい場合にも選択肢が提供されていることです。 SageMaker Studio Lab を使えば、初級レベルの機械学習の勉強を超えてご活用いただけそうだとイメージを持っていただければ嬉しいです。それでは、本題の SageMaker Studio Lab で 日本語 LLM を Fine-Tuning するお話に入っていきます。本ブログでは、 こちらのクイズのブログ に倣って、OpenCALM をクイズに回答する精度が向上するように Fine-Tuning していきます。 SageMaker Studio Lab で日本語 LLM OpenCALM を動かす準備 以降の内容では、SageMaker Studio Lab が持つ機能、つまり無料の範囲内でのお話となります。先述の Notebook Jobs は利用しません。NoteBoo Jobs の利用に関しては別途 Blog を公開予定です。また、以降を読み進めていただく上で、SageMaker Studio Lab のアカウントを取得いただいておくとスムーズです。取得方法は こちら です。このブログの実装は こちら のブログを参考にしています。特に、実装部分は以下を参考にしています。併せてご参考くださいませ。 https://huggingface.co/cyberagent/open-calm-7b https://github.com/aws-samples/aws-ml-jp/tree/main/tasks/generative-ai/text-to-text/fine-tuning/instruction-tuning/Transformers SageMaker Studio Lab にログインしたら、GPU を選択、 Start runtime をクリックてください。初回実行の場合、Mobile Number の登録と SMS 確認が必要な場合があります。日本の電話番号にて Mobile Number のチェックがうまくいかない場合は、Mobile Number の入力時に日本 +81 を選択いただき、電話番号の先頭 0 を除いて入力してみてください。 その後、ロボットでないことをチェックする画面を通過してください。SageMaker Studio Lab はご好評いただいており、GPU が確保できない場合がございます。その場合は複数回お試しください。 作業用のディレクトリを作成しましょう。ディレクトリ名は llm-lora-challenge とします。左のメニューにて右クリック、New Folder を選択し、llm-lora-challenge ディレクトリを作成します。 以降、全ての作業はこの llm-lora-challenge ディレクトリ以下で実施します。 必要なライブラリをインストールしていきましょう。2 つの手段があります。ここでは Conda 環境を作成し、可搬性を高める手順 (以下の 1 つ目の方法) を取ります。default 環境を複数の目的で共有して使うとライブラリのバージョン衝突などにより作業しにくくなることがありますが、それを防ぐ効果もあります。 個別の Conda 環境を作成しllm_finetuning.yml を作成し、GUI から Build Conda Environment を実行する llm_finetuning という名前の conda 環境を構成する (参考) default の Conda 環境にライブラリをインストールする requirements.txt を作成し、notebook のセルから pip install を実行する requirements.txt を作成し、terminal を立ち上げ、default に Conda 環境をスイッチした後、pip install を terminal から実行する 以下のように llm_finetuning.yml を作成します。 name: llm_finetuning dependencies: - python=3.10 - deepspeed - pip - pip: - git+https://github.com/huggingface/peft.git@207d2908650f3f4f3ba0e21d243c1b2aee66e72d - bitsandbytes==0.39.0 - accelerate==0.20.3 - transformers==4.30.1 - tokenizers==0.13.3 - pynvml==11.4.1 - protobuf==3.20.2 - scipy - optimum - appdirs - loralib - black - black[jupyter] - datasets - fire - sentencepiece - evaluate - einops - ipykernel 作成した llm_finetuning.yml を右クリックしBuild Conda Environment をクリック、確認画面で OK をクリックします。 terminal が起動され、install が開始されます。 以下が表示されれば完了です。 左上のプラスボタンから Launcher を起動して、conda 環境が作成されたか確認してみましょう。 Notebook の部分に作成した llm_finetuning:Python が表示されていれば成功です。 以降の実行は全て llm_finetuning 環境を利用します。Launcher 画面から llm_finetuning:Python をクリックし、ノートブックを開いたら右上の kernel の表示が llm_finetuning:Python になっていることを確認してください。もしなっていない場合は、そちらをクリックし、下記画面のように Select Kernel から llm_finetuning:Python を選択してください。 最終的な構成を先に示します。以降の手順にて作成いただいたり、ダウンロードしたり、実行によって生成されたりするものを含んでいます。 model/ Fine-Tuning を実行すると作成され、モデルファイルが保存される llm_finetuning.yml 本ブログで使用する llm_finetuning の Conda 環境を作成するためのファイル data/aio_02_train.jsonl ダウンロードされる Fine-Tuning 用ファイル data/aio_02_train_formatted.jsonl Fine-Tuning に利用しやすいようにフォーマットしたファイル templates/simple_qa_ja.json プロンプトテンプレート OpenCALM_inf.ipynb 本ブログで作成する推論用の Notebook ファイル OpenCALM_format.ipynb 本ブログで作成するクイズデータを Fine-Tuning 用にフォーマットする Notebook ファイル OpenCALM_finetune.ipynb 本ブログで作成する Fine-Tuning 用の Notebook ファイル OpenCALM_finetuned_inf.ipynb 本ブログで作成する Fine-Tuning 後のモデルを用いて推論する Notebook ファイル SageMaker Studio Lab で OpenCALM の推論を呼び出す ここでは、Fine-Tuning 前の OpenCALM モデルがどの程度クイズに回答できるか確認してみましょう。新規に ipynb ファイル OpenCALM_inf.ipynb を作成し、以下のソースコードを実行してみてください。OpenCALM は HuggingFace Transformers ライブラリから利用する事ができます。初回はモデルのダウンロードが走る分時間がかかります。2 回目以降はダウンロード済みのモデルを利用するため動作が速くなります。 model_name に以下を指定 (パラメータ数が小さい順に記載) することで、OpenCALM のパラメータ数が異なるモデルを使用する事ができます。いろいろ変えてみて回答がどうなるか確認してみると面白いかもしれません。 cyberagent/open-calm-small cyberagent/open-calm-medium cyberagent/open-calm-large cyberagent/open-calm-1b cyberagent/open-calm-3b cyberagent/open-calm-7b import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name = 'cyberagent/open-calm-1b' model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto", torch_dtype=torch.float16, cache_dir="/tmp/model_cache/") tokenizer = AutoTokenizer.from_pretrained(model_name) inputs = tokenizer("映画『ウエスト・サイド物語』に登場する2つの少年グループといえば、シャーク団と何団?答えは「", return_tensors="pt").to(model.device) with torch.no_grad(): tokens = model.generate( **inputs, max_new_tokens=64, do_sample=True, temperature=0.7, top_p=0.9, repetition_penalty=1.05, pad_token_id=tokenizer.pad_token_id, ) output = tokenizer.decode(tokens[0], skip_special_tokens=True) print(f'{model_name}:{output}') もし、以下のエラーが出た場合、SageMaker Studio Lab が CPU モードで実行されている可能性があります。このブログのコードは GPU モードでのみ動作します。一度 ログアウトいただき、GPU モードに切り替えて再度お試しください。 RuntimeError: "LayerNormKernelImpl" not implemented for 'Half' LLM の出力は確率的要素があるため必ずしも同じになるとは限りません。以下の結果は何か回答しようとはしているものの、正しくない答えが返ってきています。 cyberagent/open-calm-1b:映画『ウエスト・サイド物語』に登場する2つの少年グループといえば、シャーク団と何団?答えは「ダンシングロッド」です。 少年たちの友情や恋心が描かれたミュージカルは老若男女問わず人気で、『美女か野獣』(1992)から現在まで数多くの映画が製作されてきました。『ウェストミンスター寺院の鐘の音が聞こえるまで』『ヘアスプレー』、『ラブアクチュアリー』、そして今世紀最大のヒット作となったのが ここで、注意が必要なのは、ダウンロードされるモデルのファイルサイズです。モデル名を見てみましょう。 1b, 3b, 7b とあるモデル名はそれぞれのパラメータ数の規模を表しています。b は Billion = 10 億であり、7b は 70 億パラメータ規模のモデルであることがわかります。このモデルファイルは 10 GB を越えており、SageMaker Studio Lab で永続化 (Stop Runtime しても残る) 領域に保存してしまうと容量を圧迫してしまいます。今後継続的に開発に利用することを考えると Conda 環境の保存などに利用するためにこの領域は極力空けておきたいですよね。そこで、cache_dir に /tmp/model_cache/ を指定することで対策しています。 AutoModelForCausalLM.from_pretrained メソッドを cyberagent/open-calm-7b を指定して実行した場合、初回にかかる時間は数分程度でした。Start Runtime する度に 1 度だけかかる時間としては許容範囲ではないでしょうか。 SageMaker Studio Lab で OpenCALM を LoRA によって Fine-Tuning する ここでは OpenCALM のクイズ回答精度を向上するために必要な Fine-Tuning 用のデータを準備します。 こちらのブログ に沿う形で、クイズデータを Fine-Tuning 用のフォーマットに変換して保存します。新規に OpenCALM_format.ipynb を作成し、以下のソースコードをセルに転載し実行してみてください。data/aio_02_train_formatted.jsonl にフォーマット済みクイズデータが保存されます。 !wget -P data https://jaqket.s3.ap-northeast-1.amazonaws.com/data/aio_02/aio_02_train.jsonl # Convet .jsonl to .json import pandas as pd df = pd.read_json("data/aio_02_train.jsonl", orient="records", lines=True) df = df.rename(columns={"question": "instruction", "answers": "output"}) df = df[["instruction", "output"]] df["output"] = df["output"].apply(lambda x: f"{x[0]}」") df["input"] = "" print(df.shape) df.to_json( "data/aio_02_train_formatted.jsonl", orient="records", force_ascii=False, lines=True ) df.head(2) 作成されたデータを確認してみましょう。クイズデータのため、質問 (instruciton 列) と回答 (output 列) というペアでデータが作成されている事がわかります。 次に OpenCALM にクイズ回答用の学習をする準備をします。プロンプトテンプレートファイルを用意します。このテンプレートは OpenCALM に学習データを入力するときのテンプレートになります。以下の作業を実施してください。 templates ディレクトリを作成 こちらの template をダウンロード SageMaker Studio Lab の templates ディレクトリに配置 (ファイルはドラッグ&ドロップできます) 以下が template の中身です。 instruction に続き、 答えは「 をプロンプトとして含めることで回答を促しています。実は、先述の推論を試してみたときに、OpenCALM に 答えは「 と入力することで回答させようとしていた部分をテンプレートとして採用しています。 {input} を使用する場合とそうでない場合がある事がわかります。 {instruction} の部分はクイズのデータサンプルごとに異なります。一方で {input} はプロンプトを別途追加したい場合に利用できます。 {input} はこのブログでは使用しません。 OpenCALM_finetune.ipynb ファイルを作成してください。独自のユーティリティクラス Prompter がこのテンプレートファイルを読み、テンプレートに沿った形で OpenCALM にわたす役割です。 Prompter をダウンロードしコードをコピー&ペーストでセルに貼り付けてください。.py ファイルとして別途モジュールを import する形でも構いません。 最後に OpenCALM を Fine-Tuning するコードを準備します。 こちらの Fine-Tuning のコード をダウンロードしコードをコピー＆ペーストでセルに貼り付けてください。セルに貼り付ける際に以下は不要のためコメントアウトしましょう。 ... # from utils.prompter import Prompter ... # if __name__ == "**main**": # fire.Fire(train) .py ファイルとして別途モジュール import する形でも構いません。 Fine-Tuning では学習済みモデルを追加のデータを用いて再学習することで精度向上を図ります。パラメータをランダム値などにより初期化した状態から学習することに比べ、学習済みモデルのパラメータを初期値に利用した状態で学習を進める Fine-Tuning には学習のコスト効率を高めながらモデルの精度を高める狙いがあります。しかし、工夫無しに Fine-Tuning してしまうと全てのパラメータを更新対象にしてしまいコスト効率が悪くなったり、学習済みモデルが獲得した一般的な概念を失ってしまう壊滅的忘却と呼ばれる現象が発生するリスクがあります。そこで、少ない更新パラメータ数でコスト効率よく精度を向上させる研究分野や手法群を指す PEFT (Parameter-Efficient Fine Tuning) が生まれました。実務的には PEFT が実装されたライブラリを利用することでその恩恵を受ける事ができます。PEFT は hugging face library に実装があります。本ブログではこの内 LoRA ( LOW-RANK ADAPTATION OF LARGE LANGUAGE MODELS ) に挑戦します。LoRA は学習済みモデルのパラメータはそのままに、新たに追加したパラメータ (Neural Network の重み) に対し更新する手法です。この手法は以下の利点により注目されています。 更新対象パラメータ数の削減によりメモリ量と学習時間を短くできる場合がある LoRA 部分だけを切り替えることにより、タスクに特化して再学習した Fine-Tuned モデルを効率よく活用できる場合がある Fine-Tuning のソースコードのうち LoRA らしさが表れている部分に着目して読んでみましょう。実際のソースコードは toknizer や学習途中結果の保存などの実装が含まれていますが、LoRA のポイントは以下の通りです。 AutoModelForCausalLM.from_pretrained により LoRA の元になる学習済みモデルを読み込む LoraConfig にて、 LoRA のハイパーパラメータ を設定する で取得した model と 2. で設定した config を get_peft_model に渡すことにより LoRA 用の model を取得する で取得した model オブジェクトを transformers.Trainer に渡し trainer を取得する の trainer を使用し、 trainer.train を呼び出す また、 AutoModelForCausalLM.from_pretrained に cache_dir="/tmp/model_cache/" が指定されているため、LoRA に渡した学習済みモデルファイルは SageMaker Studio Lab では永続化されない領域に保存されます。また、 output_dir にディレクトリ名を指定すると永続化される領域に LoRA のファイルが保存されます。これによって SageMaker Studio Lab の永続化領域を圧迫することなく LoRA を実行できます。 以上で準備は終了です。さあ、Fine-Tuning を実行してみましょう！ 以下のコードをセルに貼り付けて実行してみてください。メモリ不足になる場合は他の Notebook を停止して閉じておきましょう。1b のモデルを学習する場合は 10 – 20 分、7b のモデルを学習する場合は 2 時間程度を要します。まずは動作させてみたいという場合は model_name を cyberagent/open-calm-1b などのパラメータ数の小さいモデルで試してみてください。本ブログでは 1b のモデルを試してみます。 model_name = "cyberagent/open-calm-1b" model_name_base = model_name.split("/")[-1] hyperparameters = { "base_model": model_name, "pad_token_id": 1, "data_path": "data/aio_02_train_formatted.jsonl", "num_epochs": 1, # default 3 "cutoff_len": 256, "group_by_length": False, "output_dir": "model", "lora_target_modules": ['query_key_value'], "lora_r": 16, "batch_size": 32, "micro_batch_size": 4, "prompt_template_name": "simple_qa_ja", } train(**hyperparameters) model_name に OpenCALM を指定しています。また、以下が大きいほど学習に時間を要しますが精度が改善する可能性があります。大きくし続ければ必ず精度が改善するわけではないため注意が必要です。 num_epochs : 学習サンプルを 1 巡する回数を表すハイパーパラメータ lora_r : 行列ランクと呼ばれるLoRA にて更新対象にするパラメータ数に依存するハイパーパラメータ 初めはこれらを小さくして、パラメータ数の小さいモデルで LoRA を実行し、正常に動作するかを確認してみると良いでしょう。 以下のような Epoch に対する進捗のログが出力されれば学習が実行されています。指定した num_epochs にログの Epoch が到達したら学習は完了です。 Training Alpaca-LoRA model with params: base_model: cyberagent/open-calm-1b data_path: data/aio_02_train_formatted.jsonl output_dir: model batch_size: 32 ・・・ [XXXXX/XXXXXX X:XX:XX < 00:00, X.XX it/s, Epoch 1.00/1] もし、学習時間が長く、SageMaker Studio Lab で実行できる GPU 利用時間制限を越えた場合でも、学習途中の LoRA ファイルが model ディレクトリに保存されているため、後で学習した LoRA ファイルを用いて学習を再実行したり、推論に利用したりする事が可能です。 SageMaker Studio Lab で Fine-Tuning した OpenCALM を使って推論する ここまでの作業により、LoRA により Fine-Tuning した OpenCALM モデルがクイズに上手に回答できる事が期待されます。早速、効果を確認していきましょう。新規に OpenCALM_finetuned_inf.ipynb を作成しましょう。 推論のサンプルコード を参考に実装します。このサンプルコードは SageMaker Inference Endpoint にホストする用のコードになっています。このブログでは SageMaker Inference Endpoint は使用しませんので、以下の手順に従って必要なコードだけをセルに貼り付けていきます。 OpenCALM_finetuned_inf.ipynb ファイルを作成してください。LoRA による Fine-Tuning 時に利用した Prompter クラスが必要です。同様に、 Prompter をダウンロードしセルに貼り付けてください。.py ファイルとして別途モジュール import する形でも構いません。 推論のサンプルコード から import に関する部分を抜き出しセルに貼り付けます。 from utils.prompter import Prompter は Prompter をセルに貼り付けている場合は不要です。 import os import sys import json from typing import Dict import torch import transformers from peft import PeftModel from transformers import GenerationConfig, AutoModelForCausalLM, AutoTokenizer, StoppingCriteria, StoppingCriteriaList, BitsAndBytesConfig import deepspeed StopOnTokens クラスをセルに貼り付けます。後ほどテキストを生成する際に生成の停止条件を与えるクラスです。 class StopOnTokens(StoppingCriteria): def __init__(self, stop_ids): self.stop_ids = stop_ids def __call__(self, input_ids: torch.LongTensor, scores: torch.FloatTensor, **kwargs) -> bool: for stop_id in self.stop_ids: if input_ids[0][-1] == stop_id: return True return False prompter, tokenizer, model を生成します。以下のソースコードをセルに貼り付けてください。 base_model = "cyberagent/open-calm-1b" device = "cuda" prompt_template = "simple_qa_ja" lora_weights = "model" prompter = Prompter(prompt_template) tokenizer = AutoTokenizer.from_pretrained(base_model) model = AutoModelForCausalLM.from_pretrained( base_model, load_in_8bit=False, torch_dtype=torch.float16, device_map="auto", cache_dir="/tmp/model_cache/" ) print("Loading Lora Weight") model = PeftModel.from_pretrained( model, lora_weights, torch_dtype=torch.float16, ) model.model_parallel = False if torch.cuda.device_count() > 1: model.is_parallelizable = True model.model_parallel = True 最後に、prompt を生成し、テキストを生成するパラメータを設定したら、テキスト生成するコードをセルに貼り付けてください。 instruction = "映画『ウエスト・サイド物語』に登場する2つの少年グループといえば、シャーク団と何団?" input = "" max_new_tokens = 32 stop_ids = [1, 0] prompt = prompter.generate_prompt(instruction, input) inputs = tokenizer( prompt, add_special_tokens=False, return_token_type_ids=False, return_tensors="pt" ).to(device) generation_config = GenerationConfig( max_new_tokens=max_new_tokens, return_dict_in_generate=True, output_scores=True, temperature=0.1, do_sample=False, num_beams=5, pad_token_id=1, bos_token_id=0, eos_token_id=0 ) with torch.no_grad(): generation_output = model.generate( **inputs, generation_config=generation_config, stopping_criteria=StoppingCriteriaList([StopOnTokens(stop_ids)]), ) s = generation_output.sequences[0, inputs['input_ids'].size(1):] output = tokenizer.decode(s, skip_special_tokens=True) output 推論のソースコードのうち LoRA らしさが表れている部分に着目して読んでみましょう。実際のソースコードは toknizer などの実装が含まれていますが、LoRA のポイントは以下の通りです。 AutoModelForCausalLM.from_pretrained により LoRA の元になる学習済みモデルを読み込む の model と lora_weights = “model“ を PeftModel.from_pretrained に渡し model を取得する の model により model.generate を呼び出す LoRA の保存先が model ディレクトリであったことを思い出してみましょう。Fine-Tuning 時と同様に、 AutoModelForCausalLM.from_pretrained に cache_dir="/tmp/model_cache/" が指定されているため、SageMaker Studio Lab の永続化領域を圧迫することなく LoRA を用いたモデルの推論を実行できます。 さあ、OpenCALM_finetuned_inf.ipynb を実行してみましょう。検証時の結果では、以下のように正しい回答が返ってきました。LLM の出力は確率要素があるため本ブログと同じ回答が得られない場合があることに注意が必要です。 ここで、興味深い事は Fine-Tuning 用ファイルには類似のクイズは含まれていなかった事です。Fine-Tuning に用いたクイズデータを確認したところ、ウェストサイドストーリーに関するクイズは以下のみでした。 {"instruction":"ミュージカル「ウエストサイド・ストーリー」の作曲で知られる音楽家は誰でしょう?","output":"レナード・バーンスタイン」","input":""} 元となる OpenCALM の学習データにはウェストサイドストーリーに関するテキストが含まれており、クイズ回答に特化した Fine-Tuning によって正しい回答を得られるようになった可能性があります。 発展 本ブログを参考に以下にチャレンジしてみましょう。 cyberagent/open-calm-7b を試す 本ブログのコードは 1b のモデルを試しましたが、作者の動作確認では 7b のモデルまで実行できることを確認しています。モデルの大きさによって回答精度がどう変わってくるのか、処理時間はどうか、是非お試しください。 SageMaker Studio への移行 SageMaker Studio Lab で作成したコードを SageMaker Studio Notebook で実行してみましょう。より多くの計算機リソースや機械学習ワークロードを実現する多くの機能と連携できるようになります。 OpenCALM 以外の日本語 LLM を試す Hugging Face に実装されているモデルであれば本ブログの実装を参考にすることができます。例えば、 rinna/japanese-gpt-neox-3.6b · Hugging Face を利用できるように改修してみましょう。rinna モデルの場合はどのようなプロンプトを与えると良いか試してみましょう。もしかしたら、OpenCALM とは違う特性があるかもしれません。 最後に 本ブログで解説した内容は SageMaker Studio Notebook, SageMaker Notebook Instance でも同様に実行可能です。もし、皆様が既に GPU を搭載した計算機環境をお持ちであれば、Jupyter notebook や Jupyter Lab を導入することで同様に実行可能です。生成系 AI はここ数年で実務レベルで活用できるユースケースが多岐に渡るほどの進化を遂げました。トップダウンで検証することになったご担当者様やボトムアップで面白い技術要素としてスキルを獲得しようとしている方まで様々かと思います。新しい技術を検証するとき、社会課題、社内課題ともにどんな課題がこの技術で解決できるかを机上で考える事は重要です。また、皆様の抱える課題のうち優先順位の高い費用対効果の高いテーマを選択することも重要です。同時に、予算や体制が小さな状況でも動くものを作り、その技術を通して何がどう動くのか体験することも重要だと考えています。このブログを通じて、日本語 LLM の OSS がどのように動作するのか、何に使えそうなのかを体験いただき、日本語 LLM の OSS が持つ可能性を感じていただければ大変嬉しく思います。 著者 中島 佑樹 西日本のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としている。 システム一般のテーマや Amazon Bedrock を用いた生成系 AI のシステム開発、Amazon SageMaker Studio Lab を用いた AIML への入門まで幅広く活動。

AWS は、2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2023 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4615 )。AWS ブースでは「Create. Deliver. Monetize.」をテーマに、「コンテンツ制作」、「放送」、「メディアサプライチェーン & アーカイブ」、「Direct-to-Consumer & ストリーミング」、「データサイエンス & AI/ML」におけるクラウドを利用した重要なワークロードの運用をサポートする技術とソリューションを、パートナー 9 社とともにご紹介します。本ブログでは、AWS ブースで行われるブースセミナーの中から 5 つのステージ特別プログラムをご紹介させていただきます。 Inter BEE とは Inter BEE とは、日本随一の音と映像と通信のプロフェッショナル展として、コンテンツビジネスに関わる最新のイノベーションが国内外から集まる国際展示会です。アフターコロナ時代におけるメディア産業の新たなユーザエクスペリエンスを提示する展示会として、「コンテンツ」を中核に位置づけ、コンテンツを「つくる (制作) 」「おくる (伝送) 」「うける (体験) 」の技術要素を網羅した「メディア総合イベント」に変容することを目指し、開催します。 開催期間は、幕張メッセで 2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) 、オンライン会場で 2023 年 11 月 6 日 ( 月 ) 〜 2023 年 12 月 15 日 ( 金 ) となっています。 下のリンクから登録を行うことで、無料で参加することができます。 登録はこちらから ステージ特別プログラムのご紹介 [Create.] バーチャルプロダクションにおける AWS 活用 – 制作から撮影まで 株式会社スタジオブロス 上津原一利 様 11 月 15 日 ( 水 ) 12:20-13:00 バーチャルプロダクションの制作、確認、撮影など、様々なシーンでクラウド活用することによって各作業を効率的に進めることができます。スタジオブロスで実際に行ったクラウド活用の事例や、活用によって広がる可能性などお伝えいたします。 Create. Deliver. Monetize. Trends & Customer stories in the M&E Industry Amazon Web Services Shad Hashmi 11 月 15 日 ( 水 ) 16:30-17:10 メディア・エンターテインメント業界は革新の波に直面しており、AWS はコンテンツ制作、メディアサプライチェーン & アーカイブ、放送、Direct-to-Consumer とストリーミング、データサイエンス & 分析、5 つの分野でお客様のイノベーションを支えています。Create. Deliver. Monetize. の視点から、海外のメディア&エンターテインメント業界のトレンドと AWS を用いたお客様事例を紹介します。 [Create.] 目指せ! 収録→編集→アーカイブまで素材一元管理 TBS テレビコンテンツ制作局のこれまでの取り組み 株式会社 TBS テレビ 吉橋 隆雄 様 11 月 16 日 ( 木 ) 15:40-16:20 大量の過去の収録テープ素材を前にした放送局の制作部門スタッフが「円滑に過去素材を再利用できる環境の構築」と「働き方改革にともなう諸業務の効率化」を目的に、社内各部署を巻き込んで説得し、映像のデータ化 ⇒ クラウド化 ⇒ クラウドオフライン編集に挑戦するまでの道のりと今後の課題と展望について、関係者一同と共にフランクにお話します。 [Monetize.] ABEMA ライブイベント配信におけるパーソナライズ広告挿入について 株式会社 AbemaTV 古川 俊太 様 11 月 16 日 ( 木 ) 16:30-17:10 ABEMA ではリニア配信とビデオ配信に加えて、スポーツなどの試合に対応できるように新しく「ライブイベント」という放送形態を導入しました。 ライブイベントという放送形態を新規で導入したことにより、広告の配信システムも新規で開発する必要がありました。 今回、AWS MediaTailor をパーソナライズ基盤として選定しましたが、その経緯と現状、展望についてお話しいたします。 [Deliver.] NeSTREAM LIVE AWS を活用した DOLBY ATMOS での高臨場感ライブ配信事例の紹介 メモリーテック株式会社 棟元 裕介 様、株式会社クープ 近藤 貴春 様、Dolby Japan 株式会社 萩谷 太郎 様 11 月 17 日 ( 金 ) 12:20-13:00 近年、音楽ライブにおいて、Dolby Atmos での劇場上映や、パッケージ販売・配信する事例が増えています。 Dolby Atmos はバーチャライザー技術と併用することで、ホームシアターやヘッドホンなどの様々な民生機器で使用することができます。 これまでの制作事例を踏まえ、今後増えていくことが予想される Dolby Atmos でライブ配信の仕組みなどについてご紹介します。 ブースセミナーのプログラム こちらは、AWS のブースで行うセミナーのプログラムです。今回ご紹介したステージ特別プログラムの他にも、パートナーセッションや AWS ブース紹介が行われます。 終わりに 今回は、Inter BEE 2023 の AWS ブースセミナーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2023 の 公式サイト からご確認ください。 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは Solutions Architect 濵野が担当しました。

はじめに 今日の組織は、地域・業界、またビジネスニーズによって異なる、プライバシーや規制の課題に直面しています。これらのプライバシー規制を遵守するために、コンタクトセンターの管理者は、コンタクトセンター内で使用される機密リソースに対する最小アクセス権限の実装を頻繁に求められます。 Amazon Connect の タグベースのアクセスコントロール により、Amazon Connect 管理コンソール内で Amazon Connect リソースに対するより細かいアクセスコントロールを有効にできるようになりました。タグは Key:Value のペアで、役割、チーム、事業部門、その他の基準によって、Amazon Connect リソースへのアクセスを管理、検索、フィルタリング、制御することができます。一例をあげると、タグベースのアクセスコントロールによって、ある管理者にすべてのエージェントを完全に管理するアクセス権を付与しつつ、別の管理者ロールでは管理者が所属するビジネスユニット内のエージェントの表示と管理のみに制限することができます。 この記事では、まず Amazon Connect 管理コンソールによるリソースタグ付けをサポートするようになった追加の Amazon Connect リソースについて説明します。その後、架空の会社 Octank 社の管理者が特定の Amazon Connect リソースにタグを設定し、タグベースのアクセスコントロールでそれらのリソースへの最小権限でのアクセスを設定する方法を示します。 このソリューションは、コンタクトセンターの管理者、マネージャー、コンプライアンス関係者、ビジネスプロセスアウトソーサー (BPO) などの第三者に以下のような利点をもたらします。 ビジネスニーズに基づいて、リソースを論理的にグループ分けした並べ替えやフィルタリング 機密情報 (PII など) の意図しない利害関係者への共有を防止 ソリューション概要 このソリューションを展開するため、以下の手順を実施します。 アクセスコントロールタグおよびリソースタグを特定のリソースに設定する リソースタグとアクセスコントロールタグを自動的に設定する リソースタグとタグベースのアクセスコントロールを設定する前に、Octank 社の社内情報ガバナンスと業務要件を以下に示します。 ユーザー、ルーティングプロファイル、キューへのアクセスを制限する、3つのコンタクトセンター管理者ロールを作成する Country:Argentina のタグだけが付いたリソースにアクセスできるコンタクトセンターロール BPO:Octank のタグだけが付いたリソースにアクセスできるコンタクトセンターロール Country:Argentina および BPO:Octank 両方のタグが付いたリソースにアクセスできるコンタクトセンターロール 前提条件 このチュートリアルは、以下のリソースを理解し、アクセスできることを前提としています。 Amazon Connect の管理者アクセス権を持つ AWS アカウント 作成 済みのAmazon Connect インスタンス 管理者権限 (Admin) の セキュリティプロファイル を持つ Amazon Connect ユーザー AWS リソースのタグ付け に関する基本的な知識 タグ付けをサポートする Amazon Connect のリソース Amazon Connect のリソースにタグを付ける 既存の機能に加えて、Amazon Connect 管理コンソール内で設定するリソースにもタグを付けることができるようになりました。次の表は、管理コンソール内でタグをサポートするようになったリソースと、 API/CLI レベル でタグをサポートしているリソースを示しています。 Amazon Connect リソース Amazon Connect 管理コンソール内でのタグ付け可否 API/CLI 経由のタグ付け可否 User Management 可 可 Security Profiles 可 可 Routing Profiles 可 可 Queues 可 可 Flows 不可 可 Hierarchy Groups 不可 可 Hours of Operation 不可 可 Quick Connects 不可 可 Prompts 不可 可 Instances 不可 可 Task Templates 不可 可 Phone Numbers 不可 可 Traffic Distribution Groups 不可 可 Agent Status 不可 可 アクセスコントロールタグとリソースタグを設定するチュートリアル 最初のセクションでは、最初に アクセスコントロールタグ と リソースタグ を使用してセキュリティプロファイルを設定することで、Amazon Connect 管理コンソール内でリソースタグを設定する方法について説明します。次のセクションでは、ユーザー、キュー、ルーティングプロファイルのリソースタグを設定する手順について説明します。最後のセクションでは、サンプルユーザーを使用してアクセス制御されるさまざまなセキュリティプロファイルを変更およびテストして、より細かいアクセスコントロールを検証する方法について説明します。 アクセスコントロールタグとセキュリティープロファイルの設定 このセクションでは、より細かいアクセスコントロールを持つ 3 つのセキュリティプロファイルを作成して、Amazon Connect 管理コンソール内でセキュリティプロファイルに対してアクセスコントロールタグとリソースタグの両方を設定する方法について説明します。 Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から セキュリティプロファイル を選択します 新しいセキュリティプロファイルの追加 を選択します 名前 と 説明 を入力します。ここではセキュリティプロファイルの名前を tagsecurityprofile1 とします。 セキュリティプロファイルのアクセス権限を選択します。下記画像のようにルーティングプロファイル、キュー、ユーザー、セキュリティプロファイルの各行で「すべて」を選択します 詳細オプションの表示 をクリックし、展開します アクセスコントロール の項目で、 リソース にユーザー、ルーティングプロファイル、キューを選択、 タグ のキーに Country 、値に Argentina を入力し、追加をクリックします タグの項目で、任意のリソースタグを入力し、追加をクリックします（画像の例では Createdby:ABC と入力) 保存をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります 同様の手順で、セキュリティプロファイル tagsecurityprofile2 と tagsecurityprofile3 を以下の表に記載のプロファイルの 名前 、アクセス権限、アクセスコントロール リソース 、アクセスコントロール タグ 、リソース タグ の通り作成します セキュリティプロファイルの名前 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ リソースタグ tagsecurityprofile1 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー Country:Argentina Createdby: ABC tagsecurityprofile2 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー BPO:Octank Createdby: ABC tagsecurityprofile3 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー Country:Argentina, BPO:Octank Createdby: ABC 以上が完了すると、次のアクセスコントロールタグが設定済みの 3 つのセキュリティプロファイルが作成されます。 アクセスコントロールタグ Country:Argentina が設定された tagsecurityprofile1 アクセスコントロールタグ BPO:Octank が設定された tagsecurityprofile2 アクセスコントロールタグ Country:Argentina と BPO:Octank が設定された tagsecurityprofile3 これらのセキュリティプロファイルを使用して、Octank のデータガバナンスとビジネス要件を適用できます。これについては、ユーザー、キュー、ルーティングプロファイルのリソースタグを設定した後で説明します。 リソースタグとユーザーの設定 このセクションでは、Amazon Connect 管理コンソール内でユーザーを設定し、リソースタグを適用する方法について説明します。サブ管理者権限と詳細なアクセス制御を適用したユーザーを 1 人作成し、表示/管理する 3 つのエージェントを作成します。ログインに tagadmin 、 taguser1 、 taguser2 、 taguser3 という名前を付けます。最後に、ルーティングプロファイル、セキュリティプロファイル、リソースタグを以下のように設定します。 ログイン 名 姓 ルーティングプロファイル セキュリティプロファイル リソースタグ 1 リソースタグ 2 tagadmin Admin Tag Basic Routing Profile tagsecurityprofile1 taguser1 Test1 Tag Basic Routing Profile Agent Country:Argentina taguser2 Test2 Tag Basic Routing Profile Agent BPO:Octank taguser3 Test3 Tag Basic Routing Profile Agent Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から ユーザー管理 を選択します 新しいユーザーの追加 を選択します ユーザーを手動で追加 を選択します 名 、 姓 、 ログイン 、 セキュリティプロファイル 、 ルーティングプロファイル を上記表のサンプルの通りに各ユーザーに設定します。別途、メールアドレスとパスワードを各ユーザーに設定する必要があります 管理者を作成する際はスキップできますが、エージェントを作成する際には次の手順が必要です。 詳細設定を表示 をクリックし、キーと値を上の表の例の通り入力、 追加 します 保存 をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります。 この手順を繰り返し、副管理者 ( tagadmin )および 3 つのエージェント( taguser1 , taguser2 , taguser3 )のアカウントを作成します 完了すると、tagadmin という名前の副管理者が 1 人と、次のリソースタグが設定された 3 人のエージェントが作成されます。 リソースタグ Country:Argentina が設定された taguser1 リソースタグ BPO:Octank が設定された taguser2 リソースタグ Country:Argentina と BPO:Octank が設定された taguser3 リソースタグとキューの設定 このセクションでは、Amazon Connect 管理コンソールでキューのリソースタグを設定する方法について説明します。 以下のように、稼働時間とリソースタグを含む tagqueue1 、 tagqueue2 、 tagqueue3 の 3 つのキューを作成します。 キューの名前 オペレーション時間 リソースタグ 1 リソースタグ 2 tagqueue1 Basic Hours Country:Argentina tagqueue2 Basic Hours BPO:Octank tagqueue3 Basic Hours Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ルーティング から キュー を選択します キューを追加 を選択します キューの 名前 (例: tagqueue1 ) 、 説明 を入力します。 オペレーション時間 は、Basic Hours を選択します 設定 から タグ の項目で、以下の画像のようにタグを入力し、 追加 します 保存をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります この手順を繰り返し、 tagqueue2 および tagqueue3 も作成します 上の手順が完了すると、以下の通りリソースタグが設定された 3 つのキューが作成されます。 リソースタグ Country:Argentina が設定された tagqueue1 リソースタグ BPO:Octank が設定された tagqueue2 リソースタグ Country:Argentina と BPO:Octank が設定された tagqueue3 ルーティングプロファイルとリソースタグの設定 このセクションでは、Amazon Connect 管理コンソールでルーティングプロファイルのリソースタグを設定する方法について説明します。 次に、以下に説明するように、 音声チャネル 、 デフォルトのアウトバウンドキュー 、およびリソース タグ を使用して、 tagroutingprofile1 、 tagroutingprofile2 、 tagroutingprofile3 という名前の 3 つのルーティングプロファイルを作成します。 ルーティングプロファイルの名前 選択するチャネル デフォルトのアウトバウンドキュー リソースタグ 1 リソースタグ 2 tagroutingprofile1 音声 BasicQueue Country:Argentina tagroutingprofile2 音声 BasicQueue BPO:Octank tagroutingprofile3 音声 BasicQueue Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から ルーティングプロファイル を選択します ルーティングプロファイルを追加 を選択します ルーティングプロファイルの 名前 (例: tagroutingprofile1 )と 説明 を入力します 設定 セクション内の チャネルの設定 で音声を選択、 キュー のセクションは変更せず、 デフォルトのアウトバウンドキュー で BasicQueue を選択します タグについては、以下のようにキー、値の組み合わせを設定し、 追加 をクリックします 保存 をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります この手順を繰り返し、 tagroutingprofile2 および tagroutingprofile3 も作成します 完了すると、次のリソースタグの付いた 3 つのルーティングプロファイルが作成されます。 リソースタグ Country:Argentina が設定された tagroutingprofile1 リソースタグ BPO:Octank が設定された tagroutingprofile2 リソースタグ Country:Argentina と BPO:Octank が設定された tagroutingprofile3 ここまででユーザー、キュー、ルーティングプロファイルのリソースタグを設定し、アクセス制御とリソースタグを使用してセキュリティプロファイルを設定しました。次のセクションで、サブ管理者の tagadmin が持つ詳細なアクセスを検証できます。 アクセスコントロールの確認 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した副管理者アカウント tagadmin でサインインします ユーザー から ユーザー管理 を選択します。キーがCountry、値がArgentinaのリソースタグを含んだユーザーだけが表示されます。具体的には、 taguser1 と taguser3 が表示されます ルーティング から キュー を選択します。キーがCountry、値がArgentinaのリソースタグを含んだキューだけが表示されます。今回は、 tagqueue1 と tagqueue3 が表示されます ユーザー から ルーティングプロファイル を選択します。キーがCountry、値がArgentinaのリソースタグを含んだキューだけが表示されます。今回は、 tagroutingprofile1 と tagroutingprofile3 が表示されます 補足 セキュリティプロファイルを作成、変更し、アクセス制御タグを追加すると、より制限が厳しくなります セキュリティプロファイルがユーザーに割り当てられるまで、アクセス制御タグは適用されません アクセスコントロールの変更と確認 次に、サブ管理者ユーザ ( tagadmin ) のセキュリティプロファイルを変更し、付与されたアクセス権を確認しましょう。手順は以下の通りです。 Amazon Connect 管理コンソールにサインインします ユーザー から ユーザー管理 を選択します ユーザー tagadmin を選択し、 編集 をクリックします ユーザー tagadmin のセキュリティプロファイル を、 tagsecurityprofile1 から tagsecurityprofile2 に変更します。ドロップダウンメニュー内に「アクセスコントロール: タグ」の表示を確認できます 保存 をクリックします 副管理者のアカウント(ユーザー tagadmin )でログインしているシークレットモードのウィンドウを再読み込みします。タグ BPO:Octank が含まれているユーザー、キュー、ルーティングプロファイルのみにアクセスできるはずです。つまり、ユーザー tagadmin から、ユーザー taguser2 と taguser3 、キュー tagqueue2 と tagqueue3 、ルーティングプロファイル tagrouringprofile2 と tagroutingprofile3 が確認できます 最後にユーザー tagadmin のセキュリティープロファイルを tagsecurityprofile2 から tagsecurityprofile3 に変更して、権限を確認します。タグ Country:Argentina と BPO:Octank の両方が付与されたユーザー、キュー、ルーティングプロファイルだけにアクセスできるはずです。ユーザー tagadmin からは、ユーザー taguser3 、キュー tagqueue3 とルーティングプロファイル tagroutingprofile3 のみが確認できます Amazon Connect API や SDK を利用したより詳細なアクセス制御の設定 Amazon Connect API を使用して、Amazon Connect リソースに対するより詳細なアクセス制御をプログラムで設定できます。 Create Security profile API によりリソースタグとアクセスコントロールタグを使用してセキュリティプロファイルを作成できます Create User API によりタグ付きのユーザーを作成できます Create Routing Profile API によりタグ付きのルーティングプロファイルを作成できます Create Queues API によりタグ付きのキューを作成できます クリーンアップ Amazon Connect 管理コンソールにログインし、このブログの手順で作成した ユーザーを削除 します このブログのハンズオンの為に Amazon Connect インスタンスをセットアップした場合は、Amazon Connect AWS コンソールにアクセスして Amazon Connect インスタンスを削除 できます 結論 このブログでは、Amazon Connect のリソースタグとアクセスコントロールタグを使用して Amazon Connect リソースへのきめ細かなアクセスコントロールを可能にする方法を説明しました。これにより Amazon Connect インスタンスの運用中に要件が変化したときに、チーム、ロール、またはその他の基準で複数のグループを作成し、さまざまな Amazon Connect リソースに対してより複雑なアクセスコントロール条件を表現することができます。 無料のオンラインイベント、AWS Contact Center Day もご覧ください。カスタマーサービスの未来、機械学習がどのように顧客とエージェントのエクスペリエンスを最適化できるかなどについて学ぶことができます。 今すぐ登録 ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 著者について Dilin Joy Dilin Joy は、 AWS のパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Behrang KHAKISEDDIGH Behrang KHAKISEDDIGH は、 AWS のシニアパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Mike Cairns Mike Cairns は、 AWS のパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Tommy Grahams Tommy Graham は、 AWS の技術担当のシニアプロダクトマネージャーです。彼は顧客と協力し課題の解決策を見極め、データ主導の意思決定で業務を楽しんで推進しています。 追加のリソース Amazon Connect 概要 Amazon Connect でセキュリティプロファイルのより詳細なアクセス制御 (リソースタグを使用) が可能に Amazon Connectのリリースノート Amazon Connect 管理者ガイド Amazon Connectのパートナー タグベースのアクセス制御 Amazon Connect API Reference (英文) 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

Amazon Redshift は、クラウドにおけるフルマネージド型のペタバイト規模のデータウェアハウスサービスであり、他のどのクラウドデータウェアハウスよりも 最大 5 倍優れたコストパフォーマンス を実現し、追加費用なしですぐにパフォーマンスの革新的な向上を実現できます。 何万ものお客様が Amazon Redshift を使用して毎日エクサバイト単位のデータを処理し、分析ワークロードを強化しています。 この記事では、Amazon Redshift SYS モニタリングビューについて説明し、Amazon Redshift のワークロードとリソース使用量のモニタリングを簡素化する方法について説明します。 SYS モニタリングビューの概要 SYS モニタリングビューは Amazon Redshift のシステムビューで、プロビジョニングされたクラスターやサーバーレスワークグループのクエリとワークロードのリソース使用状況をモニタリングするために使用できます。 これらには次の利点があります: クエリの状態、パフォーマンス指標、クエリの種類を考慮して、機能の整合性に基づいて分類されています パフォーマンスのトラブルシューティングに役立つように、 planning_time 、 lock_wait_time 、 remote_read_io 、 local_read_io などの新しいパフォーマンスメトリクスを導入しました Redshift の オプティマイザで書き直されたクエリの代わりに、ユーザーが送信したクエリをログに記録することで、モニタリングビューの使いやすさが向上しています 少ないビューでより多くのトラブルシューティングメトリクスを提供できます プロビジョニングされたクラスターでもサーバーレスワークグループでも同じクエリを使用できるため、Amazon Redshift の統合的なモニタリングが可能になります では、いくつかのSYS モニタリングビューの機能と、それらをモニタリングにどのように使用できるかを見ていきましょう。 さまざまなクエリレベルのモニタリングメトリクスを統合 次の表は、複数のシステムテーブルとビューをクエリすることで得られるさまざまなメトリクスと情報を、一つのSYSモニタリングビューにどのように統合できているかを示しています STL/SVL/STV 得られる情報 SYS モニタリングビュー ビューのカラム STL_QUERY クエリの消費合計時間, クエリ名の短縮系, ユーザーID, トランザクションID, セッションID,クエリのステータス, データベース名 SYS_QUERY_HISTORY user_id query_id query_label transaction_id session_id database_name query_type status result_cache_hit start_time end_time elapsed_time queue_time execution_time error_message returned_rows returned_bytes query_text redshift_version usage_limit compute_type compile_time planning_time lock_wait_time STL_WLM_QUERY キュー滞在時間, 実行合計時間 SVL_QLOG キャッシュの使用 STL_ERROR エラーコード、エラーメッセージ STL_UTILITYTEXT SELECT以外のSQL STL_DDLTEXT DDLステートメント SVL_STATEMENTEXT 全てのタイプのSQLステートメント STL_RETURN 結果の行数とバイト STL_USAGE_CONTROL クエリによって到達した使用制限 ID のリスト STV_WLM_QUERY_STATE WLMの現在の状態 STV_RECENTS 現在実行中であるか完了しているクエリ STV_INFLIGHT 実行中のクエリ SVL_COMPILE コンパイル SYS から STL/SVL/STV へのマッピングに関する追加情報については、 SYS モニタリングビューへの移行 を参照してください。 ユーザークエリレベルのロギング クエリのパフォーマンスを向上させるために、Redshift クエリエンジンはユーザーが送信したクエリを書き換えることができます。 ユーザーが送信したクエリの ID は、書き換えられたクエリの ID とは異なります。 この記事では、ユーザーが送信したクエリを 親クエリ 、書き直したクエリを 子クエリ と呼びます。 次の図は、親クエリレベルと子クエリレベルでのロギングを示しています。 親クエリのIDは 1000 で、子クエリのIDは 1001、1002、1003 です。 クエリのライフサイクルのタイミング SYS_QUERY_HISTORY では、さまざまなクエリライフサイクルフェーズに関連する詳細な時間メトリクスを提供するために、カラムが拡張されています。 すべての時間はマイクロ秒単位で記録されることに注意してください。 次の表は、これらのメトリクスをまとめたものです。 タイムメトリクス 詳細 planning_time クエリを実行する前にクエリが費やした時間。通常、パース、分析、計画、書き換えなどのクエリライフサイクルフェーズが含まれます。 lock_wait_time 参照されている必要なデータベースオブジェクトのロックの取得にクエリが費やした時間。 queue_time リソースが実行可能になるまで、クエリがキュー内で待機していた時間。 compile_time クエリのコンパイルにかかった時間。 execution_time クエリの実行にかかった時間。 SELECT クエリの場合、これには結果が返ってくるまでの時間も含まれます。 elapsed_time クエリ実行の開始から終了までの時間。 ソリューションの概要 SYS モニタリングビューに慣れるために、以下のシナリオについて説明します: ワークロードとクエリのライフサイクルのモニタリング データ取り込みモニタリング 外部クエリのモニタリング クエリのパフォーマンスが遅い場合のトラブルシューティング 前提条件 この投稿の例に従うには、以下を事前に準備する必要があります: AWS アカウント プロビジョニングされた Redshift クラスター (現在のトラック) または Amazon Redshift Serverless エンドポイント 加えて、この記事で参照されているすべての SQL クエリを Redshift クエリエディタ v2 SQL ノートブックとして ダウンロード してください。 ワークロードとクエリのライフサイクルのモニタリング このセクションでは、ワークロードとクエリのライフサイクルをモニタリングする方法について説明します。 実行中のクエリを識別 SYS_QUERY_HISTORY では、実行中のすべてのクエリと実行履歴を一元的に確認できます。 次のクエリの例を参照してください: SELECT * FROM sys_query_history WHERE status IN ( 'planning' , 'queued' , 'running' , 'returning' ) ORDER BY start_time ; SQL 次の結果になります。 実行時間の長い上位クエリを特定 次のクエリは、実行に最も時間がかかる上位 100 件のクエリを取得するのに役立ちます。 これらのクエリを分析 (可能であれば最適化) することで、全体的なパフォーマンスを向上させることができます。 これらのメトリクスは、すべての実行されたクエリを累積した統計値です。 時間の値はすべてマイクロ秒単位であることに注意してください。 --top long running query by elapsed_time SELECT user_id , transaction_id , query_id , database_name , query_type , query_text:: VARCHAR ( 100 ) , lock_wait_time , planning_time , compile_time , execution_time , elapsed_time FROM sys_query_history ORDER BY elapsed_time DESC LIMIT 100 ; SQL 次の結果になります。 クエリの種類、期間、ステータス別に毎日のクエリ数を収集 次のクエリは、さまざまなタイプのクエリが各日にどのように分布しているかを把握し、ワークロードの変化を評価して追跡するのに役立ちます: --daily breakdown of workload by query types and status SELECT DATE_TRUNC ( 'day' , start_time ) period_daily , query_type , status , COUNT ( * ) FROM sys_query_history GROUP BY period_daily , query_type , status ORDER BY period_daily , query_type , status ; SQL   次の結果になります。 実行中のクエリの実行詳細を収集する 実行中のクエリの実行レベルの詳細を確認するには、 SYS_QUERY_DETAIL テーブルをクエリするときに is_active = 't' フィルタを使用できます。 次の例を参照してください: SELECT query_id , child_query_sequence , stream_id , segment_id , step_id , step_name , table_id , coalesce ( table_name , '' ) || coalesce ( source , '' ) as table_name , start_time , end_time , duration , blocks_read , local_read_io , remote_read_io FROM sys_query_detail WHERE is_active = 't' ORDER BY query_id , child_query_sequence , stream_id , segment_id , step_id ; SQL 実行された最新の 100 個の COPY クエリを表示するには、次のコードを使用します: SELECT session_id , transaction_id , query_id , database_name , table_name , data_source , loaded_rows , loaded_bytes , duration / 1000.00 duration_ms FROM sys_load_history ORDER BY start_time DESC LIMIT 100 ; SQL 次の結果になります。 コミットとその取り消しに対するトランザクションレベルの詳細の収集 SYS_TRANSACTION_HISTORY は、コミットされたブロック、ステータス、分離レベル ( SERIALIZABLE または SNAPSHOT ISOLATION ) などの詳細とともに、コミットされたトランザクションに関するインサイトを提供することにより、トランザクションレベルのロギングを提供します。 また、ロールバックまたは取り消しトランザクションの詳細も記録されます。 次のスクリーンショットは、正常にコミットされたトランザクションについての詳細情報を取得する方法を示しています。 次のスクリーンショットは、ロールバックされたトランザクションについての詳細情報を取得する方法を示しています。 統計情報とバキューム SYS_ANALYZE_HISTORY モニタリングビューには、分析クエリの最終タイムスタンプ、特定の分析クエリの実行時間、テーブル内の行数、変更された行数などの詳細が表示されます。 次のクエリ例は、すべての永続テーブルに対して実行された最新の分析クエリのリストを提供します: SELECT TRIM ( schema_name ) schema_name , TRIM ( table_name ) table_name , table_id , status , COUNT ( * ) times_analyze_was_triggered , MAX ( last_analyze_time ) last_analyze_time , MAX ( end_time ) end_time , AVG ( ROWS ) "rows" , AVG ( modified_rows ) modified_rows FROM sys_analyze_history WHERE status != 'Skipped' GROUP BY schema_name , table_name , table_id , status ORDER BY schema_name , table_name , table_id , status , end_time ; SQL 次の結果になります。 SYS_VACUUM_HISTORY モニタリングビューでは、バキュームに関するすべての詳細が 1 つのビューに表示されます。 たとえば、次のコードを参照してください: SELECT user_id , transaction_id , query_id , TRIM ( database_name ) as database_name , TRIM ( schema_name ) as schema_name , TRIM ( table_name ) table_name , table_id , vacuum_type , is_automatic as is_auto , duration , rows_before_vacuum , size_before_vacuum , reclaimable_rows , reclaimed_rows , reclaimed_blocks , sortedrows_before_vacuum , sortedrows_after_vacuum FROM sys_vacuum_history WHERE status LIKE '%Finished%' ORDER BY start_time ; SQL 次の結果になります。 データ取り込みのモニタリング このセクションでは、データ取り込みをモニタリングする方法について説明します。 取り込みの概要 SYS_LOAD_HISTORY は、COPY コマンドの統計に関する詳細を提供します。 このビューを使用すると、取り込みワークロードに関するインサイトをまとめることができます。 次のクエリ例は、データ取り込みが行われたテーブルごとに分類された、取り込みの概要を 1 時間ごとに示しています。 SELECT date_trunc ( 'hour' , start_time ) period_hourly , database_name , table_name , status , file_format , SUM ( loaded_rows ) total_rows_ingested , SUM ( loaded_bytes ) total_bytes_ingested , SUM ( source_file_count ) num_of_files_to_process , SUM ( file_count_scanned ) num_of_files_processed , SUM ( error_count ) total_errors FROM sys_load_history GROUP BY period_hourly , database_name , table_name , status , file_format ORDER BY table_name , period_hourly , status ; SQL 次の結果になります。 ファイルレベルの取り込みログ SYS_LOAD_DETAIL は、ファイルレベルでの取り込み処理に関するより詳細なインサイトを提供します。 例としては、 sys_load_history を使用した次のクエリを参照してください: SELECT * FROM sys_load_history WHERE table_name = 'catalog_sales' ORDER BY start_time ; SQL 次の結果になります。 次の例は、詳細なファイルレベルのモニタリングがどのようなものかを示しています。 SELECT user_id , query_id , TRIM ( file_name ) file_name , bytes_scanned , lines_scanned , splits_scanned , record_time , start_time , end_time FROM sys_load_detail WHERE query_id = 1824870 ORDER BY start_time ; SQL     取り込みプロセス中のエラーをチェック SYS_LOAD_ERROR_DETAIL を使用すると、取り込みプロセス中に発生した可能性のあるエラーを追跡してトラブルシューティングできます。 このビューには、取り込み処理中にエラーが発生したファイルの詳細と、エラーが発生した行番号、およびその行内のカラムの詳細が記録されます。 次のコードを参照してください。 select * from sys_load_error_detail order by start_time limit 100 ; SQL 次の結果になります。 外部クエリのモニタリング SYS_EXTERNAL_QUERY_DETAIL は、 Amazon Redshift Spectrum やフェデレーテッドクエリを含む外部クエリの実行詳細を提供します。 このビューは、詳細をセグメントレベルで記録し、単一のモニタリングビューで外部クエリのトラブルシューティングとパフォーマンスのモニタリングに役立つインサイトを提供します。 このモニタリングビューが提供する有用なメトリクスとデータポイントは次のとおりです。 スキャンされた外部ファイル ( scanned_files ) の数と、Parquetやテキストファイルなどの外部ファイルのフォーマット ( file_format ) スキャンされたデータの行数 ( returned_rows ) とバイト数 ( returned_bytes ) 外部クエリとテーブルによるパーティショニング ( total_partitions と qualified_partitions ) の使用 特定の外部オブジェクトの一覧表示 ( s3list_time ) とパーティションスキャン ( get_partition_time ) にかかった時間の詳細なインサイト 外部ファイルの場所 ( file_location ) と外部テーブル名 ( table_name ) Redshift Spectrum 用の Amazon Simple Storage Service (Amazon S3) やフェデレーテッドクエリといった外部ソースのタイプ( source_type ) サブディレクトリの再帰スキャン ( is_recursive ) またはネストされた列データ型へのアクセス ( is_nested ) たとえば、次のクエリは、実行された外部クエリ数とスキャンされたデータ数の日次での概要を示しています。 SELECT DATE_TRUNC ( 'hour' , start_time ) period_hourly , user_id , TRIM ( source_type ) source_type , COUNT ( DISTINCT query_id ) query_counts , SUM ( returned_rows ) returned_rows , ROUND ( SUM ( returned_bytes ) / 1024 ^ 3 , 2 ) returned_gb FROM sys_external_query_detail GROUP BY period_hourly , user_id , source_type ORDER BY period_hourly , user_id , source_type ; SQL 次の結果になります。 パーティションの使用 大量のデータやファイルをスキャンする外部クエリがパーティション化されているかどうかを確認できます。 パーティションを使用する場合、パーティションキーに基づいて絞り込むことによって、外部クエリがスキャンする必要があるデータの量を制限できます。 次のコードを参照してください。 SELECT file_location , CASE WHEN NVL ( total_partitions , 0 ) = 0 THEN 'No' ELSE 'Yes' END is_partitioned , SUM ( scanned_files ) total_scanned_files , COUNT ( DISTINCT query_id ) query_count FROM sys_external_query_detail GROUP BY file_location , is_partitioned ORDER BY total_scanned_files DESC ; SQL 次の結果になります。 外部クエリでエラーが発生した場合は、 SYS_EXTERNAL_QUERY_ERROR を調べてください。 SYS_EXTERNAL_QUERY_ERROR には、そのファイル内の file_location 、 column 、および rowid のレベルで詳細が記録されます。 クエリのパフォーマンスが遅い場合のトラブルシューティング SYS モニタリングビューを使用したクエリレベルのトラブルシューティングを行うための、ステップバイステップのガイドとして、前提条件のセクションでダウンロードした sysview_slow_query_performance_troubleshooting SQL ノートブックがあります。これを参照して、次の質問に対する回答を探してください。 比較対象のクエリと、実行したクエリのクエリテキストは似ていますか ? クエリは結果キャッシュを使用していますか ? クエリのライフサイクル (キューイング、コンパイル、プランニング、ロック待機) のどの部分がクエリの実行時間に最も影響を与えていますか ? クエリプランは変更されましたか ? クエリは多くのデータブロックを読み込んでいますか ? クエリがディスク領域を使っていませんか？もしそうであればそれはローカルストレージですか、リモートストレージですか? データ (分散) と時間 (実行時間) の点で、大きく偏っているクエリですか ? ジョインまたはネストループで処理される行が増えていますか ? 統計情報が古くなっていることを示すアラートはありますか ? クエリに関係するテーブルに対して最後に VACUUM と ANALYZE が実行されたのはいつですか ? クリーンアップ Redshift のプロビジョニングされたクラスターまたは Redshift サーバーレスワークグループをこの記事のために作成し、ワークロードに対して必要なくなった場合は、それらを削除して追加コストの発生を防ぐことができます。 まとめ この記事では、Redshift SYS モニタリングビューを使用して、プロビジョニングされたクラスターとサーバーレスワークグループのワークロードをモニタリングする方法について説明しました。 SYSモニタリングビューでは、ワークロードのモニタリングが簡素化され、統一されたビューからさまざまなクエリレベルのモニタリング用のメトリクスにアクセスできます。また、プロビジョニングされたクラスターとサーバーレスワークグループの両方で、同じ SYS モニタリングビュークエリを使用できます。 また、SYS モニタリングビューを使用した主要なモニタリングおよびトラブルシューティングシナリオについても説明しました。 Redshift のワークロードには、新しい SYS モニタリングビューを使い始めることをお勧めします。 著者について Urvish Shah は Amazon Redshift のシニアデータベースエンジニアです。 彼はデータベース、データウェアハウス、アナリティクス分野で10年以上働いてきました。 仕事以外では、料理、旅行、娘との時間を楽しんでいます。 Ranjan Burman は AWS のアナリティクススペシャリストソリューションアーキテクトです。 Amazon Redshift を専門とし、お客様がスケーラブルなアナリティクスソリューションを構築できるよう支援しています。 彼はさまざまなデータベースおよびデータウェアハウステクノロジーで 16 年以上の経験があります。 クラウドソリューションによる顧客の問題の自動化と解決に情熱を注いでいます。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

11月27日(月)に無料ウェビナー AWS Purpose Built Database Webinar 「Amazon Aurora/RDS のコスト最適化」 を開催します。 本セッションでは、Amazon Aurora/RDS を長期間運用するにあたってのコスト最適化のポイントや、安定運用のコツについてご紹介します。本セッションは、以下の2部から構成されます。 「Amazon Aurora/RDS でのコストの最適化」のセッションでは、これまでのウェビナーで移行→コスト削減の話が多かったため、RDS長期・安定利用中のお客様向けのコスト削減をこのセッションで紹介し、それ以外にAurora Serverless v2やIO-Cost Optimization（New price model導入)の話も案内します。 「移行のベスト プラクティスとコストの最適化」のセッションでは、移行案件など、必要スペックが想定できているお客様へのコスト削減案を案内し、Tooling&Programもここで紹介します(DBFW/DMS・SCT/OLA)。 AWSマネージドデータベースサービスの運用とコスト削減に興味がある方は是非ご参加ください。 アジェンダ ※当日の進行により、時間割が若干変更となる場合がございます。 時間 プログラム 講師 14:00-14:30 Amazon Aurora/RDS でのコストの最適化 木村 達也 14:30-15:00 移行のベスト プラクティスとコストの最適化 小沢 亮太 開催場所 当日は下記のZoomにアクセスし、Meeting IDを入力してウェビナーにご参加ください。 https://zoom.us/join Meeting ID: 81462473492 Passcode: 357768 講師プロフィール 木村 達也 データ事業本部 ポートフォリオスペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 製造、通信、メディア業界のお客様に対するデータベースの課題解決支援に従事しています。 小沢 亮太 パブリックセクター技術統括本部 パートナーソリューションアーキテクト 前職では外資系データベースベンダーにて、データベースのサポート・プリセールスを行なってきました。AWSでは、パートナーソリューションアーキテクトとして、パートナー様が悩まれているデータベースの移行について、勉強会やソリューションをご案内しています。 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 10月もまもなく終わりですね。11月にさしかかると、常に意識に上がってくるのはAWSの世界最大の学習型カンファレンス、 AWS re:invent 2023 ですね。たくさんのサービスアップデートや先進的な事例が発表されますイベントですので、是非チェックしてください。キーノートと一部のコンテンツはオンラインで無料で視聴いただくこともできます。 そして毎年恒例のAWS BlackBelt Online Seminarのre:Inventまとめ回ですが、今年も配信いたします。日本時間で12/1のお昼休み、12:00-13:00に可能な限り全てのサービスアップデートをざっくりとご紹介します。無料でご参加いただけますが、こちらもお申し込みが必要になります。（10/30 17時頃追記： 申込みページ できました！） それでは、10 月 23 日週のアップデートを振り返ってみましょう。 2023 年 10 月 23 日週の主要なアップデート 10/23(月) Amazon ECSで予期できない負荷が発生した際の挙動を改善 Amazon ECSのタスクスケジューリング機能が強化され、予測できない負荷が発生した場合にもより回復力を高めるように動作するようになりました。ECSで稼働するタスク(コンテナ)はヘルスチェックが行われ、応答がない場合はそれが終了され代わりのタスクが起動されます。今回のアップデートで、新たにタスクを起動しサービスに組み込んだ後に、応答がないタスクを終了するような動作をするようになります。突発的な負荷が発生すると過負荷によってタスクがヘルスチェックに応答できず終了され、一時的に全体のキャパシティが低下してしまう、といったケースの回避につながることが期待できます。 Amazon RDS for SQL ServerがSQL Server 2019の新しいマイナーバージョンをサポート Amazon RDS for SQL ServerでSQL Server 2019 CU22 – 15.0.4322.2をサポートしました。Express, Web, Standard, Enterpriseの各エディションでご利用いただけます。 10/24(火) Amazon OpenSearch Serverlessで時刻ベースのデータ削除に対応 Amazon OpenSearch Serverlessで時刻に基づいた自動データ削除が可能になりました。この機能はインデックスライフサイクルポリシーを設定することで有効化できます。不必要になったデータを削除するといった、ハウスキーピング処理を容易に実現できます。 Amazon Aurora PostgreSQLでpgvector v0.5.0を利用可能に PostgreSQL互換のAmazon Auroraでpgvector v0.5.0を利用できるようになりました。機械学習モデルで利用されるエンベディング(埋め込み)データを格納し、効率的に類似するデータを検索することが可能です。HNSWによる近傍探索のためのインデクシングもサポートされており、特に生成系AIの分野で利用されるデータストアとしての利用が容易になります。pgvector v0.5.0はPostgreSQL 15.4, 14.9, 13.12, 12.16互換のAurora PostgreSQLでご利用いただけます。 Amazon Aurora PostgreSQLで新しマイナーバージョンをサポート PostgreSQL互換のAmazon AuroraでPostgreSQL 15.4, 14.9, 13.12, 12.16, 11.21がサポートされました。このアップデートにはBabelfish for Aurora PostgreSQL 3.3のようなアップデートも含まれています。 Amazon EKSでクラスタのサブネットとセキュリティグループの設定変更が可能に Amazon Elastic Kubernetes Service(EKS)で、クラスタに紐付けられたサブネットとセキュリティグループを変更できるようになりました。VPCの設定を変更する必要が発生した場合も、クラスタを作り直すことなしに変更内容に柔軟に追従させることができます。 Amazon EKSがカスタマーマネージドIAMポリシーをサポート Amazon EKSでユーザが作成した独自のIAMポリシー(カスタマーマネージドIAMポリシー)を利用できるようになりました。Kubernetesクラスタが引き受けることができるIAMの権限をきめ細かく制御することが可能になり、コンプライアンスやガバナンス要件を満たすことが容易になります。 Amazon SQSのFIFOキューの高スループットモードにおける上限を引き上げ Amazon SQLにおいて、順序と同じデータが重複して取り出されない事を保証するFIFOキューのスループット上限が引き上げられました。リージョンによって異なりますが、東京リージョンでは高スループットモードで最大9,000トランザクション毎秒まで対応可能です。リージョン毎の上限値については ドキュメント を確認してください。 10/25(水) Amazon RDS for PostgreSQL, MySQL, MariaDBでM7g/R7gインスタンスを利用できるリージョンを拡大 東京リージョンを始め5つのリージョンにおいて、RDS for PostgreSQL, MySQL, MariaDBをGraviton 3プロセッサベースのM7g/R7gインスタンスでご利用いただけるようになりました。 Amazon Aurora MySQL 3.04がLong term support(LTS)対象に MySQL 8.0.28と互換のAurora MySQL 3.04がLTS(Long term support)対象になりました。LTSリリースが動作するクラスタでは、最低3年間は同じマイナーバージョンにとどまり続けることが可能です。この期間はセキュリティ問題の修正などが提供されますが、新機能は含まれません。 Amazon Aurora MySQLのバージョン3.05が利用可能に Amazon Aurora MySQLのバージョン3.05が一般利用開始になりました。このバージョンはMySQL 8.0.32と互換性を持っています。 Amazon Aurora MySQLでデータベースの再起動時間を最大65%短縮 Amazon Aurora MySQLでバッファプールの初期化と検証の一部をデータベースがオンラインになった後に実行するよう最適化することで、予期しない再起動や計画的な再起動の双方について起動時間が最大65%短縮されました。この最適化はAurora MySQL 3.05以降でデフォルト有効になっています。 Amazon EC2 M2 Macインスタンスが一般利用開始に Amazon EC2で、M2プロセッサを搭載したMacインスタンスが利用可能になりました。iOS, macOS, iPadOSをはじめとするApple社のプラットフォーム向けの開発やテストにご利用いただけます。 10/26(木) Amazon OpenSearch ServiceがIPv6をサポート Amazon OpenSearch ServiceでIPv4に加えてIPv6による通信を利用できるようになりました。 Amazon EC2のI4iインスタンスで新たに2つのサイズが利用可能に 高いパフォーマンスを発揮するローカルストレージが利用できるI4iインスタンスで、新たにI4i.12xlargeとI4i.24xlargeというサイズをご利用いただけるようになりました。東京・大阪のリージョンでもご利用いただけます。 Amazon AppStream 2.0のMicrosoft Windows環境がマルチセッション接続に対応 Amazon AppStream 2.0でWindows環境のマルチセッション接続をサポートしました。複数のユーザセッションを単一のインスタンスで処理できるようになり、コスト効率が向上します。 Amazon EC2インスタンスに対して異なるVPCのENIをアタッチ可能に Amazon EC2で、EC2インスタンスにアタッチされたプライマリのENIが所属するVPCと異なるVPCに所属するENIを、同じインスタンスにアタッチできるようになりました。コントロールプレーンとデータプレーンの分離や、異なるVPCに集約されたアプライアンスへのアクセスが必要な場合に便利な機能です。 10/27(金) AWS NeuronがLlama-2 70bモデルとPyTorch 2.0をサポート AWS Neuronは機械学習用のアクセラレータであるInferentiaとTraniumを搭載したEC2インスタンス向けのSDKです。今回バージョン2.15がリリースされ、Llama-2 70bモデルのトレーニングへの対応と、PyTorch 2.0のサポートが行われました。 Amazon OpenSearch Serviceがk-NN FAISSエンジンによる効率的なクエリフィルタリングに対応 Amazon OpenSearch ServiceのOpenSearch 2.9を利用することで、k-NN FAISSエンジンを利用した効率的なクエリフィルタリングを活用可能になります。これを利用すると従来よりも低遅延で正確な結果を期待できるため、ベクトル検索を必要とするアプリケーションで便利にご利用いただけます。 Amazon Security Lakeが大阪リージョンで利用可能に セキュリティデータの分析を容易にするAmazon Security Lakeが大阪リージョンをはじめ、4つのリージョンでご利用いただけるようになりました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

アマゾン ウェブ サービス ジャパン合同会社とつくば市は、2022 年9 月に 研究開発型スタートアップの成長加速に向けた 連携協定を締結 いたしました。つくばの研究開発スタートアップの創出・育成に向けつくばのスタートアップへの AWS Activate を通したご支援や、イベントの共催等を行っています。 今回は 2023年 10月 18日に、 つくばスタートアップパーク でつくば市と AWS が開催したイベント 「イノベーションの最前線vol.6 ー防災テックを活かしたレジリエンス社会の実現に向けてー」 の開催報告を、当日の内容から一部抜粋してお送りします。 本イベントのご登壇者は以下の通りです。 I－レジリエンス株式会社 （以下、I－レジリエンス） 代表取締役社長　小林 誠 氏 防災科学技術研究所 （以下、防災科研） 防災情報研究部門/総合防災情報センター  吉森 和城 氏 モデレーター： アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 教育事業本部アカウントエグゼクティブ　田代 皓嗣 まずは小林 氏より、I－レジリエンスのお取り組み紹介をお話しいただきました。 防災科研の研究成果の社会実装のために生まれた、I－レジリエンスの挑戦 I－レジリエンス は、災害が多い日本で、防災の研究成果をきちんと社会で使える状態にしないといけない背景がありまして、防災科研の研究成果の社会実装を促進するために 2021 年 11 月設立されました。もうすぐ設立 2 年の、まだまだスタートアップです。産学官連携で行うために、民間企業 4 社にも出資いただいています。 I－レジリエンス株式会社 代表取締役社長　小林 誠 氏 I－レジリエンスの目的は大きく2つあります。 1 つ目は研究成果を活用したレジリエンス向上 です。防災科研のような研究者の方々が、研究成果を商品化して、運用して社会実装していくまでやるのは大変なので、社会実装を会社でやるのが私たちです。 2 つ目は、 民間企業主体のレジリエンス向上 です。行政だけではなく、企業や生活者にも情報を使った新しいサービスが必要なので、ここをI－レジリエンスとしてやっています。企業が使える防災情報サービスプラットフォームなどを運営し、その中で AWS も活用しています。大きく 3 つ DX・教育・ライフと 3 つの事業領域を持っています。 レジリエンスを高めることでより生活を豊かにする「レジリエントライフ」 レジリエンスとは、災害が起こった時、回復・復旧を早くしようというコンセプトですが、I－レジリエンスでは少し違う定義をしています。私たちは、 社会や個人に降りかかる自然災害だけではない困難に、適応、回復し、その後教訓をもとに成長し、次の被害を予防する、このサイクルを繰り返して困難を乗り越えるチカラ 、と定義しています。 レジリエントライフプロジェクト は、今年関東大震災100年に合わせて、防災科研と民間企業各社と一緒にスタートしました。各社が持っている強みを生かして、個人を起点にあらゆる困難に適応・回復・成長・予防できる生活の豊かさの実現を目指して活動しています。 防災という言葉はネガティブなイメージですが、レジリエンスを高めることでより豊かな生活を目指す、 「レジリエンスっていいよね」、というポジティブなイメージを広げていきたい という想いで取り組んでいます。 私たちは、困難な領域である防災分野のビジネスに挑戦し、これまた困難と言われている、研究成果の社会実装をするという、非常に難しいミッションを二つ負ったスタートアップです。やっていくべきことは主に 3 つあって、1 つ目はニーズとシーズのブリッジです。まだまだマッチングしていない防災に関するニーズと、シーズはたくさんあり、目利きをして橋渡しできる人が増えていく必要があります。 2 つ目は、1 つのソリューションでは解決できない生活者の課題を、色々な企業の色々なサービスを組み合わせて解決していく「コレクティブ・インパクト」を実現してくことです。3 つ目に、レジリエンス市場を新しく創出していくことです。 まだまだ防災分野の課題解決のためには、より多くの企業と共創していく必要があると思っています。私たちは、企業同士が防災分野で連携していくための基盤となるサービスとして、レジリエンスに関するすべてのニーズにこたえる総合プラットフォーム IRIN (I-Resilience Information Network）の開発を進めています。このようなサービスによってレジリエンス社会の実現を目指していきます。 分散した防災情報を集約・一元化し、防災効果の最大化を目指す 続いて、 防災科研 の吉森 氏より、防災科研の取り組みのご紹介と AWS の活用についてお話いただきました。 防災科研では、あらゆる自然災害を対象に、予測・予防、応急対応、復旧・復興という災害のすべての段階についての、基礎研究及び基盤的研究開発に取り組んでいます。例えば、全国各地にある地震計の観測震度をリアルタイムで公開( 強震モニタ )していたり、災害の現象実物大で再現し実験する施設( 大型降雨実験施設 、 E-ディフェンスなど )があったりします。 防災科学技術研究所 防災情報研究部門/総合防災情報センター  吉森 和城 氏 私が所属する防災情報研究部門では、色んな機関に分散している防災情報をきちんと活用し、社会実装していくために活動しています。その中で、 SIP4D （基盤的防災情報流通ネットワーク）というシステムを研究開発しています。こちらは分散したデータを繋ぎ相互に共有していく「パイプライン」を実現し、国全体としての災害対応の効果最大化を目指しています。その SIP4D で集約した情報を公開する 防災クロスビュー というウェブサイトも運用しています。 AWSとの出会いは北海道胆振東部地震。いつどこで地震や災害起きても、気づける仕組みが必要だった AWS と出会ったきっかけは、平成 30 年に発生した北海道胆振東部地震です。私のチームは、防災クロスビューを速やかに開設し、様々な情報発信を行いました。 しかし、深夜3時7分という、メンバー全員が寝ている時に深夜に発生したので、すぐに地震に気づくことができず、初動の対応に課題が残りました。 いつどこで地震が発生しても、対応者が気づける仕組みが必要 だという課題が浮き彫りになりました。 そのころ丁度スマートスピーカーが普及してきた頃だったので、Amazon Echo の Alexa スキルで地震情報を教えてくれるシステムを開発している開発者に問い合わせ、地震が起きたら強制的にアラートを出してくれる Alexa スキルを開発できないかと聞きました。 Alexa スキルは制約が多いので難しいと言われましたが、 Amazon Connect というサービスを使えば強制的に電話通知できると教えてもらいました。また、AWS の色々なサービスを組み合わせることで、電話通知だけではなく他の通知にも拡張できるとのことでした。 当初はコスト面が懸念でしたが、 AWS は従量課金で、災害発生時に電話をかけた時のみコストが発生するため、低コストで運用できるのでは と考え、AWS 導入の検討に踏み切りました。 開発者の方に相談して 10 日後にはサンプルを構築してくださり、このスピード感でサンプルシステムが実現できたので AWS は本当にすごいなと思いました。 突発的な災害にも、俊敏かつ柔軟に対応可能な災害通知システムを、2.5 か月で構築 サンプルシステムを踏まえ、実際に災害が起きた時に電話がかける仕組みを実現しようと、考案から2.5 か月で、初回の災害情報通知システムが構築されています。気象庁や J-アラートをトリガーに、AWS 上の処理を経て職員にチャットや電話等のツールで通知する仕組みです。 あくまで個人の見解とはなりますが、AWSを活用する上でプラスに感じていることは、まず 従量課金のため頻度が高くない利用に関しては、コストメリットが大きい ことです。そして システム構築のスピード感、スモールスタートで開発できその後の拡張が容易であること もメリットです。 最初は私も災害情報通知システムだけを作り始めましたが、2018 年の導入から業務の自動化・簡便化にも活用するようになり、5 年間でこれまで9 種類のシステムで AWS を活用しています。 一方で、少し困っていることとしては、従量課金のため費用感が確実に予想できないことです。ここ数年特に為替変動が大きく予測が難しいこともあり、この点は何かしらの改善を期待しているところです。 必要な時に、必要なだけ使うことができるクラウドは、防災テックと相性がよい 続いて、AWS の田代より、 AWS の概要についてお話しました。AWS クラウドの価値は、まさしく吉森 氏は話されたような、スモールスタートで必要な時に必要なだけ使えること、アイデアから実装までの時間を短縮できることで、防災分野はクラウドと大変相性がよいことを強調しました。 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 教育事業本部アカウントエグゼクティブ　田代 皓嗣 防災分野でテクノロジーを活用する余地はまだまだある。必要な時に必要なだけ防災データを活用できる仕組みの構築に向けて 最後に、登壇者でクロストークを行いました。ここではその一部を抜粋してお伝えします。 ―まずお伺いしたいのは、防災の領域でのテクノロジー活用はどのくらい進んでいるか、お二人のお考えを率直にお聞かせください。 小林 氏：まだまだこの領域で新しいテクノロジーの活用は進んでいないと考えています。例えば、災害の被害状況はリアルタイムで把握することができません。IoT や衛星データによって身の回りの情報、よりきめこまかやかに取得できると、防災対策も大きく変わってくると思います。 現状では、行政は市全体に対して防災サービス提供という形になっていますが、 一人ひとりに合わせて必要なサービスを提供していくには、テクノロジーをより活用していくことが重要 だと思いますし、さらに技術が進化していく必要があります。 「必要な時に、必要なだけ使えるようにする」というのは防災において重要です。平時から防災情報が活用できるようにするのは、コスト面では結構しんどい。 必要な時だけ使えるようにしておき、使った分だけ課金される仕組みができると、もっと防災情報は普及する と思います。そういったところで今後 AWS ともご一緒したいと思います。 田代：防災レジリエンスではテクノロジーによって情報がパーソナライズされていく、 個々人が最適な行動をとるうえで、クラウドがビジネスモデルに組み込まれていくことが必要 なのだということ理解しました。 吉森 氏：私もこの領域でテクノロジー活用の余地はまだまだあると考えています。 現在、やっと解析に使えるデータがそろい始めている段階 。集まったデータをより価値のある情報に変えていくために、新しいテクノロジーの活用がもっと必要です。 災害は毎回規模も大きさも違い、今まで準備していたデータの扱い方がガラッと変わったりします。それぞれにうまく対応していくのはテクノロジーで解決していかなければいけないと考えています。 スタートアップ企業の革新的ソリューションがもとめられている防災分野 田代：テクノロジーが解決していくために、スタートアップのような企業の革新的なソリューションが必要とされている市場だと思います。ぜひこの分野に取り組むスタートアップを増やしていきたいですね。 小林 氏： スタートアップのような方が情報を使いやすく、より防災サービスを作りやすくしていく環境作りを、私たちI－レジリエンスとしてやっていきたい と思っています。防災情報を一から集めるのは、各自がやらなくても、誰かがやってくれればよいんです。 田代：I-レジリエンスはご自身もスタートアップでありながら、スタートアップのためのプラットフォームにもなられようとされていますね。こういった状況も踏まえて、この領域で起業する方が増えることを期待しています。 ―I－レジリエンスは防災科研が出資をされて設立された、今までになかったベンチャーです。防災科研が出資までしてスタートアップを設立した目的についても、改めて教えていただけますでしょうか。 小林 氏：防災科研の素晴らしい研究成果をしっかり社会に広めていきたいというときに、研究者が社会実装まで担うのは難しいことがあります。研究者にはしっかり研究に専念していただきたいですし、私たちが会社として、社会に技術を実装していくために設立されました。I－レジリエンスは、研究所発ベンチャーではありながら、私のような技術者でも研究者でもない者が代表ですし、その技術が社会の何の役に立つのか、をうまく翻訳し、社会実装に繋げていきたいです。 田代： 防災科研とI－レジリエンスの関係は、研究の社会実装の形としては、先進的なモデルとなるような形 だと思っています。他の研究機関も真似するところがでてくると考えています。 ―最後に、今後テクノロジーを使ってどういったことをしていきたいか、将来の展望を教えてください。 吉森 氏：研究者の立場としては、研究のロジックや要件は定義しますが、それを支えるシステムやテクノロジーを作っていくために、 技術者が関わってくださることがもっと必要 です。 田代：そうですね。AWS を使えるようなエンジニアの方はぜひ防災科研にコンタクトしていただいて、防災の研究者と技術者の協業が増えるといいなと思います。 小林 氏：吉森さんのおっしゃる通り、研究を「実装」するためにも、研究開発において、研究にきちんとテクノロジーを入れていくことが重要だと思います。 防災は一つの分野ではなく、理学、工学、社会科学、医療、通信など様々な分野の色々なテクノロジーがないとできない特殊な領域です。現在では今バラバラに個別の機関がデータを抱えている状況です。なぜそのような対応をしたのか、等情報が集まっていくと、世の中は変わっていくと思っています。そういう バラバラのデータが、分野を超えてクラウドの同じ場所に集めて解析され、新しい価値を生み出して社会を変えていくことが求められています 。 私たちは、日々の生活の色々な部分にテクノロジーが組み込まれ、日常的にレジリエンスを意識するような社会を目指していきたいです。I－レジリエンス自身もスタートアップですが、他のスタートアップと協業して、そのような新しい社会を作ることを目指しています。 田代： システムのサイロを打破して、きちっとナレッジをシェアできるコミュニティを作っていく、そしてみんなで災害に備えていくことで、レジリエントな社会に繋がっていく と思います。 今日お話しされたアイデアがどんどん社会実装されていくのは一生活者としても非常に楽しみですし、AWS のテクノロジーがその社会の実現に貢献できればとても嬉しいです。 イベントレポートはいかがでしたでしょうか？AWS パブリックセクターは今後も、自治体、大学、研究機関、スタートアップの皆様と共創し、地域発イノベーションを加速させるためのさまざまなセッションや Meetup を実施予定です。ご関心を持たれた方は、ぜひお気軽に こちら までお問い合わせください。 このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター  シニア事業開発マネージャー（ Startup ）である 岩瀬 霞 が執筆しました。

この記事は Patterns for rapid IoT solution prototyping using AWS IoT Greengrass and Docker の日本語訳です。 はじめに 調査によると、モノのインターネット（IoT）ソリューションの実装には、通常、市場に出て運用準備が整うまでに 平均18〜24か月 かかります。IoT ソリューション開発に関連する一般的なシナリオには、デバイスプロビジョニング、テレメトリ収集、リモートコマンドアンドコントロールなどがあります。ユースケースにもよりますが、 well-architected IoT solution のプロトタイプを作成するには、それぞれのシナリオに適した設計原則とベストプラクティスを検討する必要があります。この投稿では、 AWS Cloud Development Kit (AWS CDK)、 AWS IoT Greengrass 、 Docker を組み合わせたプロトタイピングデザインパターンを採用して、AWS での IoT ソリューションのプロトタイピングを加速する方法を説明します。 AWS CDK は、一般的なプログラミング言語の表現力を利用して、AWS 上のクラウドリソースをモデル化することで、クラウド開発を加速します。AWS IoT Greengrass は、デバイスソフトウェアを構築、デプロイ、管理するためのオープンソースのエッジランタイムおよびマネージドクラウドサービスです。AWS IoT Greengrass を使用することで、ワークロードのエッジでの実行、IoT デバイスフリート全体に新規アプリケーションやレガシーアプリケーションをデプロイ、デバイスフリートをリモートで管理および操作を行うことができます。AWS IoT Greengrass には、カスタムコードを記述することなくエッジデバイスの機能を拡張できる 30 種類以上の AWS提供コンポーネント もあります。 AWS IoT Greengrass は、 Docker コンテナ内での実行や、Docker コンテナとしての実行 など、 さまざまなデプロイ方法 をサポートしています。AWS CDK を使用して作成された体系化されたインフラストラクチャパターンを、コンテナ化および自動化と組み合わせて、IoT デバイスの機能をテストまたは調査するための一貫したアプローチを作成できます。このアプローチは、プロトタイピングの繰り返し中に重要ではない暫定的なアーティファクトを残すことなく、IoT ソリューションの迅速なプロトタイピングをサポートします。 ソリューションの概要 本投稿では、このアプローチが一般的な IoT ソリューションシナリオをサポートする方法を説明します。一般的な IoT ソリューションシナリオは、デバイスプロビジョニング、デバイスコマンドアンドコントロール、テレメトリ収集です。 デバイスプロビジョニング 安全な IoT デバイスのプロビジョニング では、 固有の アイデンティティ を使用してデバイスを設定し、これらの ID を AWS IoT サービスに登録し、必要な権限を関連付ける必要があります。これにより、デバイスが AWS IoT やその他の必要な AWS サービスに安全に接続して通信できるようになります。この要件は AWS IoT Greengrass コアデバイスのセットアップ に適用されます。以下の手順は、AWS IoT Greengrass コアデバイスをプロビジョニングする方法を示しています。 AWS IoT Coreポリシーを作成します。 AWS IoT のモノ、グループ、証明書、プライベートキーを作成します。 AWS IoT ロールエイリアスと AWS Identity and Access Management (IAM) ロールを作成します。 AWS IoT Greengrass コアデバイスをセットアップします。 プロトタイピングとテスト用に AWS IoT Greengrass コンポーネントをデプロイします。 上記の手順を効率化するために、図 1 に示すパターンの採用を検討してください。このパターンでは、AWS CDK と Docker を使用して関連するリソースの作成を簡素化および効率化できます。そのため、ユーザーは 自身の IoT  ソリューションにおける機能の差別化実現に集中できます。本パターンには以下の要素が含まれます。 必要な AWS リソースを再利用可能な構成として表す AWS CDK スタック 。AWS リソースは、 AWS CloudFormation を使用して AWS CDK CLI を通じてデプロイされます。 新しく作成された AWS IoT クライアント証明書をダウンロードし、 Docker Compose ファイルと AWS IoT Greengrass セットアップスクリプトを設定することができる ヘルパースクリプト  があります。 AWS IoT Greengrass Core デバイスをセットアップし、AWS が提供するコンポーネントとオプションのカスタムコンポーネントを デプロイ する Docker コンテナです。 図 1.AWS CDK と Docker を使用して自動化された AWS IoT Greengrass Core デバイスプロビジョニングの基本プロトタイピングパターン 図 1.の詳細については、このセクションを開いて確認してください。 この図は、AWS IoT Greengrass コアデバイスのリソースの作成とデプロイを自動化する手順を示しています。AWS CDK (1) と CloudFormation (2) を使用して、必要な AWS IoT リソースと IAM リソースを作成します。付属のヘルパースクリプト (3) を使用してローカル設定を完了し、ローカルの Docker コンテナ (4) で AWS IoT Greengrass を起動します。 AWS IoT サービス、インフラストラクチャデプロイ、Docker を組み合わせて機能的な AWS IoT Greengrass コアデプロイを作成できます。その後、ソリューションに必要な 特化した コンポーネント開発 を進めます。 リモート管理/コマンドとコントロール IoT ソリューションを構築する際に遭遇する可能性のあるもう 1 つの一般的なシナリオは、IoT デバイスとリモートでやり取りできることです。たとえば、産業機器から特定のテレメトリデータを要求したり、ホームオートメーションイベントのスケジュールを設定したりします。AWS のベストプラクティスに従い、 MQTT プロトコル の双方向機能を使用してください。AWS では MQTT のコマンドとコントロールを実装するための  Device Shadow  と AWS IoT Jobs を提供しています。 図 1 で説明したパターンをベースにすると、このアプローチを拡張して MQTT 経由でデバイスのコマンドとコントロール機能をすばやく有効にすることができます。このパターンの例を図2に示します。このパターンには以下が含まれます。 AWS CDK スタックの内容: 追加の AWS IoT Core ポリシーと IAM ポリシーを作成します。 新しい AWS IoT モノグループを作成します。 既存の AWS IoT モノを新しいグループに追加します。 デバイスのコマンドとコントロールのカスタム AWS IoT Greengrass コンポーネントをデプロイします。 AWS CDK CLIを利用してCloudFormathionを実行し、リソースをデプロイします。 このパターンでは、AWS CDK ランタイムコンテキスト を使用して、以前に作成されたベースとなる CloudFormation スタックからサポートしている AWS CDK リソースを参照します。本パターンは、リソースの再実装や再デプロイすることなく、新しい機能を作成してテストすることに重点を置いています。 スタックが正常にデプロイされると、カスタムコンポーネントは指定された MQTT トピックをサブスクライブし、コマンドリクエスト到達を待機します。このトピックを通じてデバイスにコマンドを発行し、MQTT トピックのレスポンス内で完了ステータスメッセージを受信します。 このアプローチを採用すると、利用用途に合致した AWS IoT ソリューションの一部として、カスタムデバイスのコマンドとコントロール機能のプロトタイプを迅速に作成できます。 図 2.MQTT を使用した IoT デバイスのコマンドとコントロールのプロトタイピングパターンの例 図 2 の詳細については、このセクションを開いて確認してください。 AWS CDK (1) を使用して、すでにデプロイされた CloudFormation スタック (2) を参照し、追加の AWS IoT、IAM、および AWS IoT Greengrass デプロイリソースを作成します。MQTT ベースのコマンドとコントロールのコンポーネントは、ローカルで実行されている AWS IoT Greengrass コアデバイスにデプロイされます。 テレメトリの収集 最後に、一般的な IoT ソリューションには、物理デバイス、センサー、または産業機器からテレメトリデータを収集する機能が必要です。収集されたデータは、ストリーミング分析、デジタルツイン、予知保全、プロセスのシミュレーションと最適化など、多くの IoT アプリケーションをサポートできます。詳細については、「  IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 」を参照してください。 基本的なデバイスプロビジョニングパターン (図 1) を基盤として、ユースケースの要件を満たすために IoT データを AWS に取り込むオプションを検討できます。たとえば、AWS IoT Greengrass コア デバイス上で実行されている AWS IoT SiteWise を使用すると、産業機器からのデータを大規模に収集、整理、分析できます。具体的には、 OPC-UA プロトコルを使用して産業用テレメトリデータを取り込むソリューションを作成してください。取り込んだデータを 視覚化 して 分析し 、異常に対応したり、産業施設間の違いを特定したりできます。 このソリューションを実装するには、図 3 に示すパターンを採用してください。以前のパターンと同様に、このパターンには以下が含まれます。 AWS CDK スタックの内容: 専用の AWS IoT Core ポリシーと IAM ポリシーを作成します。 新しい AWS IoT モノグループを作成します。 既存の AWS IoT モノを新しいグループに追加します。 D必要な AWS IoT Greengrass コンポーネント ( AWS IoT SiteWise OPC-UA コレクター 、 AWS IoT SiteWise パブリッシャー 、および AWS IoT Greengrass ストリームマネージャー ) をデプロイします。 クラウドフォーメーションを使用して AWS CDK CLI を使用してリソースをデプロイします。 また、このパターンでは、AWS CDK ランタイムコンテキスト を使用して、作成済みのベースとなる AWS CloudFormation スタックがサポートする AWS CDK リソースを参照します。 デプロイすると、IoT Greengrass コア デバイスは既存の OPC-UA エンドポイントからテレメトリを収集し、このテレメトリを AWS IoT SiteWise に発行できるようになります。詳細については、「 AWS IoT SiteWise へのデータの取り込み 」を参照してください。 図 3.OPC-UA と AWS IoT SiteWise を使用してテレメトリを取り込むプロトタイピングパターンの例 図 3 の詳細については、このセクションを開いて確認してください。 AWS CDK (1) を使用して、以前にデプロイされたベースの CloudFormation スタック (2) を参照し、追加の AWS IoT、IAM、および AWS IoT Greengrass デプロイリソースを作成します。テレメトリの収集と公開に必要な AWS IoT SiteWise コンポーネントは、ローカルで実行されている AWS IoT Greengrass コアデバイスにデプロイされます。 このアプローチを使用すると、必要なテレメトリの取り込み機能を迅速に構築してテストできます。自動化とコンテナ化という利点も加わり、プロトタイピングにかかるコストを全体的に削減できます。 この記事で紹介するパターンとソリューションはすべて、以下の概要に従ってお客様の AWS アカウントで使用できます。 前提条件 AWS アカウント へのアクセス。 ローカルにインストールされた Docker ランタイム 、または AWS Cloud9 クラウドベースの統合開発環境。 AWS IoT Greengrass accelerators の GitHub リポジトリへのアクセス。 ソリューションウォークスルー 今回紹介しているパターンは、 AWS IoT Greengrass accelerators  の GitHub リポジトリから入手できます。これらのパターンやその他の利用可能なパターンを調べるには、このリポジトリを開発環境にクローンし確認してください。クローンを作成したら、表示される手順に従って環境に AWS IoT Greengrass Core デバイスをセットアップし、説明されているシナリオを調べることができます。 例 説明 Base Implementation IoT Greengrass コアデバイスのプロビジョニングの基本パターンです。 Operating System Command Component 基本パターンを拡張したもので、デバイスのコマンドと制御機能の実装例を紹介しています。 AWS IoT SiteWise Deployment 基本パターンを拡張したもので、AWS IoT SiteWise を使用した OPC-UA による産業用テレメトリの取り込みを紹介しています。 各列のリンク先に記載されているデプロイ手順に従うと、すぐに使い始めることができます。これらのソリューション例をカスタマイズして、さまざまなユースケースに適応させることができます。また、既存のパターンを基盤として新しい AWS CDK スタックを作成し、独自のユースケースに合わせてカスタムコンポーネントを作成してテストすることもできます。すべてのサンプルを AWS Cloud9 にデプロイして、アーティファクトをローカルにインストールまたはデプロイしなくても、迅速に検証することができます。 クリーンアップ 追加料金が発生しないように、この記事で作成したリソースを削除してください。 作成した CloudFormation スタックを削除するには: https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。 削除するスタックを選択すると、その詳細が表示されます。 Delete  を選択し、最新のスタックから例を実行して作成された各スタックの削除を確認します。スタックが順番に削除されるのを待ちます。 まとめ この投稿では、AWS CDK、AWS IoT Greengrass、Docker を組み合わせて AWS で迅速な IoT ソリューションのプロトタイピングを実現する方法を説明しました。宣言型インフラストラクチャをコードとして使用し、コンテナ化と自動化を行うことで、パターンベースのプロトタイピングアプローチを採用して、一般的な IoT ソリューションシナリオを迅速に構築できます。コア機能の構築に費やす時間を短縮することで、IoT ソリューションの差別化と革新的な機能の実現に集中できます。これにより、市場投入までの全体的な時間も短縮されます。 詳細については、他のプロトタイプパターンの作成に役立つ AWS クラウド開発キット (AWS CDK) 、 AWS IoT Greengrass 、および AWS IoT Greengrass accelerators  を参照してください。 著者について Maxim Chernyshev Maxim Chernyshev は、AWS で鉱業、エネルギー、産業分野の顧客を担当するシニアソリューションアーキテクトです。西オーストラリア州パースに拠点を置く Maxim は、適用可能な幅広いAWSのサービスと機能を使用して、お客様が複雑で斬新な問題に対するソリューションを考案できるよう支援しています。Maxim は、産業用IoT、スケーラブルな IT/OT コンバージェンス、サイバーセキュリティに情熱を注いでいます。 この記事は Maxim Chernyshev によって書かれた  Patterns for rapid IoT solution prototyping using AWS IoT Greengrass and Docker の日本語訳です。ソリューションアーキテクトの川﨑 裕希が翻訳しました。

本記事は、製薬企業における大規模言語モデル ( LLM ) の効果が大きく期待できる様々なユースケースについて業務部門毎に整理し、AWS が提供する生成系 AI サービスと共に解説する 3 部構成のシリーズの 2 つ目のブログ記事です。 パート1 では、臨床開発でのデータクリーニング作業、メディカルライティングを始めとした文書業務の効率化について、ファーマコビジランス部門での AI アプリケーションを利用した SNS 上の有害事象を検知について説明しました。パート 2 では、メディカルアフェアーズ部門での社内レビュー業務の効率改善、マーケティング部門における医療関係者向け、患者さん向けの生成系 AI チャットボットの有用性ついて説明します。 ユースケース＃3：メディカルアフェアーズ 社内のメディカルエキスパートをアナログなレビュープロセス、文書管理から解放する 製薬企業が医療関係者向けに行うプロモーション活動には、適正使用などの観点から薬機法、医療用医薬品プロモーションコードなど様々なルールが設けられており、確実な順守が求められています。このルールは年々厳格化しており、製薬企業が医療関係者向けに開催する講演会等で使用される発表スライドは、事前に社内レビューが実施されています。これらのレビュー業務は、メディカルアフェアーズ部門のメディカルエキスパート（医師、または医学系学位保持者）を中心に医科学的な妥当性、正確性、コンプライアンスなど複数の観点から行われています。特にコロナ禍に伴う企業主催のオンラインセミナーの増加を背景に、レビュー業務の負担が急激に増加しています。 この課題に対し、AI と機械学習を用いることで効率的なレビューを実施できる可能性があります。具体的には、スライドに記載された情報を AI が解析し、適正使用の観点から予め設定した注視すべきポイントが含まれるスライドにアラームを発し、レビューワーの確実な検証と適切な資料作成を支援するサービスが国内で展開されています。レビュー業務の生産性を大幅に改善し、社内のメディカルエキスパートがより医科学的、戦略的な活動にフォーカスできるようになります。 製薬企業が医療関係者に提供する情報の特徴の一つは、透明性が高く、説明可能な情報、参照元が明確であることです。医師や薬剤師に提供される情報は、常に医科学的に検証された“出処が明らかな内容”で回答する必要があります。一方で、外部からの問い合わせは、製品情報から疾患情報、最新論文まで非常に多岐に渡ります。そのため、担当部門では、社内外の何千もの医療情報ソースを分析し、大量の Q＆A を準備する必要があります。この準備プロセスには、膨大な裏付け調査、評価、データ統合が必要になり、正確な回答を効率的に導き出す環境の構築には非常に多くの労力を要しています。この課題に対する一つの解決策として、生成系 AI を活用したチャットボットの可能性を紹介したいと思います。 医療関係者向けのチャットボットは、24 時間 365 日の問い合わせ対応を可能にし、医療従事者や患者さんなど利用者の利便性向上を図る目的として、様々な製薬企業から提供されています。厚生労働省の調べによると、平均1社当たりの問い合わせ件数は、1カ月に約 2026 件で、その 97 ％以上が医療関係者からの問い合わせです。問い合わせの多い製薬企業では 1 カ月に 6000 件以上と報告されており、チャットボットは、お客様からの大量の問い合わせに対応するためには欠かせないツールと言っても過言ではないでしょう（ 厚生労働省, 2022 ）（ 第一三共, 2022 ）問い合わせに対しては、社内で承認、確認された内容から正確な情報をお伝えすることが重要となります。 その観点において、AWS の生成系 AI を活用したチャットボットでは、企業規模で正確な回答を合成することができます。予め準備した信頼できるデータレポジトリ（社内の参照元）に接続し、自然言語クエリを実行して、これらの信頼できるデータソースの内容に応じた回答を数秒で生成することができます。加えて、回答生成に使用されたデータ参照元をリファレンスとして表示することで、情報の正確性を検証することも可能になります。なお詳細は、後述の「責任ある AI のためのアプローチ」で記載しています。 ユースケース＃4：マーケティング 生成系 AI チャットボットは、患者さんと製薬企業をつなぐエンゲージメントチャネルになるのか？ 昨今、製薬企業では患者サポートプログラム( PSP : Patient Support Program )への取り組みが盛んになっています。その理由の一つとして、癌や難病といったスペシャリティ医薬品の増大に伴い、抗癌剤など外来治療（通院注射）が一般化されたことで、患者支援、副作用マネジメントの重要性が高まっているからと考えられます。加えて、新型コロナウイルス感染症による受診控えや治療中断を防ぐ手段として、PSP を通じて直接、患者にコミュニケーションを取ることで、患者の QOL やアドヒアランス改善、治療アウトカムの向上につなげたいという企業の意識変化、患者中心の企業活動が強化されている影響と考えられます。 PSP では、自社の医薬品を使用する患者さんに対し、疾患や治療に関する情報提供、注射手技の解説などの資材提供だけにとどまらず、疾患に特化した治療管理アプリ、服薬管理用のデバイスやオンライン診療など様々なデジタルサービスを組み合わせた患者支援プラットフォームとして提供されることも少なくありません。患者向けチャットボットは、これらの患者支援プラットフォーム上で、患者さんが日常生活に抱える疑問や不安を気軽に相談できるツールとして提供されるケースが増えています。 一方で、従来の AI チャットボットのコミュニケーションはまだ機械的な感じがする、あるいは質問の意図とは違った回答が表示されて回答が的を射ていないと思われる人もいるかもしれません。このような疑問に対して、カリフォルニア大学サンディエゴ校（ UCSD ）が、2023 年に患者向け生成系 AI チャットボットを利用した医師と患者のエンゲージメントについて、非常に興味深い研究結果を報告しています（ John W. Ayers, 2023 ） 図表： Boston Consulting Group Article, July 2023 この研究では、医療系 SNS に患者から寄せられた質問 195 件をランダムに抽出し、医師の回答と生成系 AIの回答を「回答された情報の質」「文章から受ける思いやり」の二つの観点から評価し、比較検討しています。評価は 5 段階で（ 1 が最も悪く、5 が最も良い）医療専門家が行っています。 その結果、「情報の質」については、良い／非常に良い以上（≧ 4 ）の割合が、チャットボット：78.5 ％、医師：22.1 ％で、チャットボットの割合が 3.6 倍有意に高いことが分かりました。 また、「思いやり」についても、ある／とてもある以上（≧ 4 ）の割合が、チャットボット：45.1 ％、医師：4.6 ％で、チャットボットの割合が 9.8 倍高かったと報告されました。 この非常に興味深い結果は、生成系 AI がチャットボットを、知りたい情報を得るという単なる検索ツールから、製薬企業と患者のより良いエンゲージメントチャネルへ進化させる日も近いという可能性と示唆を与えてくれています。 次号、Part.3 では「責任ある AI 開発のためのアプローチ」について考察し、AWS が提供する生成系AIサービスについてご紹介します。 亀田　俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。 製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（ DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

こんにちは、アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクトの川島です。2023 年 10 月 19 日に AWS for Games Live を開催いたしました。 AWS for Games Live とは？ AWS for Games Live は、AWS 公式ウェブマガジン builders.flash の記事と連動したイベントで、AWS for Games の 3 つの柱「Build」「Run」「Grow」の柱のうち 1 つにフォーカスを当てて、その内容を掘り下げるものです。参加者の方々には、ゲーム業界のトレンドを知ったりネットワーキングを楽しんだりする時間として活用していただいています。今回は、「これからのゲームデータ分析環境を考える」と題して、AWS でのゲーム分析について 4 つのセッションを設けました。 AWS でこれから始めるゲーム分析 はじめに、ソリューションアーキテクト渡邉 真太郎から、ゲームを改善するための分析を予算や工数が限られたなかで進めていくために、サーバーレスな分析サービスを組み合わせた AWS でのゲーム分析の導入例をご紹介しました。資料は こちらのリンク からご覧いただけます。 本セッションでは最初に、Amazon Aurora にある基本 KPI データをエンジニアが SQL でアドホックに集計して制作チームに共有している状況を仮定しました。このとき、集計の処理時間の長期化や集計対応の工数が課題として想定されます。そこで第一に、Amazon Redshift Serverless というクラスター管理不要のクラウドデータウェアハウスを導入し、Amazon Aurora との Zero-ETL 統合をセットアップします。Amazon Aurora と Amazon Redshift の Zero-ETL 統合は現在 機能の制限 がある Public Preview のものであり、後段のセッションで詳しく紹介します。第二に、幅広いメンバーが定常的にデータを確認・分析するための可視化に、サーバーレスな BI サービスである Amazon QuickSight を導入します。 しかしこれでもなお、基本 KPI データだけではゲーム内のユーザーの動向を定量的に確認することができず、この課題を解消するためにはユーザー行動ログも出力し分析する必要があります。そこで第三に、Amazon Kinesis Data Firehose によりゲームサーバーやクライアントからユーザー行動ログを吸い出して Amazon Redshift Serverless に格納します。これにより、分析に必要な基本 KPI データとユーザー行動ログの双方を分析・可視化できるようになります。 このようにAWSのサーバーレスな分析サービスを組み合わせていくことで分析要件の変化に応じてゲーム分析環境を発展させられることをお話ししました。 Amazon Aurora と Amazon Redshift の Zero-ETL 統合のご紹介 次に、同じくソリューションアーキテクトの佐藤 祥多から、Amazon Aurora と Amazon Redshift の Zero-ETL 統合 (以下単に「Zero-ETL 統合」) についてご紹介しました。資料は こちらのリンク からご確認ください。 Zero-ETL 統合は、ETL パイプライン不要で複数の Amazon Aurora データベースから Amazon Redshift に対して数秒以内にデータを複製できる、現在 Public Preview 中の機能です。現在は Amazon Aurora MySQL の一部バージョンのみをサポートしています。内部では Amazon Aurora の拡張 Binlog を利用してデータ複製をしているため、MySQL クラスタへの負荷を最小限に抑えられることや Crash recovery の時間が大幅に改善していることも特徴です。本機能は、ETL の運用軽減・データベースへの負荷軽減・リアルタイムでの可視化といった用途でお使いいただけます。 本セッションでは、ゲーム内の仮想通貨の動きをリアルタイムで可視化するデモもお見せしました。クライアントから送られた情報が、Amazon Aurora から Amazon Redshift に同期され、Amazon Managed Grafana で可視化されるという一連の流れをお見せし、設定の簡単さやリアルタイム性を実感していただける内容でした。 Amazon Aurora MySQL と Amazon Redshift の Zero-ETL 統合について使い所を考えてみた！ 続いて、面白法人カヤックの池田 将士氏から、Zero-ETL 統合の具体的な使い道やメリットについてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 池田氏が Zero-ETL 統合のメリットを論じるにあたって挙げたキーワードは「VPC 超え」でした。 Amazon Aurora と Amazon Redshift が異なる VPC にある場合、VPC を跨いだデータ搬送が必要になります。この「VPC 超え」の状況は、複数ゲームタイトルの統合的な分析のための分析用アカウントを用いるクロスアカウント分析の場合などに発生します。そして、そのときに Zero-ETL 統合のメリットが大きいというのが池田氏の着目する点です。「VPC 超え」のデータ搬送においては、これまで、Amazon S3 のスナップショットを経由する方法や VPC Peering で Federated Query もしくは変更データキャプチャ (CDC) を用いる方法、パブリックアクセスで AWS IAM を用いて権限を付与する方法といったものがありました。しかし、それぞれの方法で、リアルタイム性や管理の手間といった課題はありました。一方で Zero-ETL 統合なら、AWS マネージドかつニアリアルタイムで、VPC やアカウントが異なっていても CDC ができるという旨味があります。 一方で、Amazon Aurora と Amazon Redshift が同一 VPC 内に存在するときは、Federated Query で十分な場合もあります。しかしながら、それでも Zero-ETL 統合により享受できるメリットもあります。第一に、大量のデータを扱うときには Federated Query では Amazon Aurora 側の読み込み負荷が気になるため、Zero-ETL 統合によりその負荷を軽減できます。第二に、Amazon Aurora MySQL は行指向のデータベース、Amazon Redshift は列指向のデータベースなので、Zefo-ETL 統合を導入して両者を使い分けながらクエリを操作することで、効率的に分析できるようになります。これにより、HTAP (Hybrid Transactionla/Analytical Processing) と呼ばれる、トランザクション処理と分析処理の両方が行えるデータベースと同じような使い方が実現できるのです。 モンストシリーズでのデータ分析戦略 最後に、株式会社 MIXI の白川 裕介氏から、モンストシリーズにおけるデータ分析戦略についてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 モンストシリーズは 1 年弱で 6 個と多くのタイトルが出ており、内製開発と他社による開発のいずれもが共存しておりました。当初は各デベロッパーが個別最適化しながらゲーム開発していたのですが、その点に課題を感じた MIXI では統一されたルールを定義しました。そのなかで、今回は KPI などのデータ分析の方針のルールを取り上げてご紹介いただきました。 第一に、ログイン・課金・ゲームプレイといった全タイトルで共通の KPI ログを定義し、ログフォーマットも共通化して同じクエリで分析できるようにしています。加えて、それ以外の各タイトル固有の KPI ログは個別に取得しています。ログの取得は MIXI で検証して開発社にサンプルの実装を提供しました。 第二に、KPI ログの転送では、Amazon Kinesis Agent・Amazon Kinesis Data Streams・Amazon Kinesis Data Firehose を用いたデータ転送フローの標準仕様を策定しました。なお、Amazon Kinesis Data Streams がなくても構成は可能ですが、Amazon Kinesis Data Firehose の仕様上 PutRecord 時のデータごとの改行が必要だったり、恒常的な大量の流量を捌けないことがあったりする点に注意が必要です。なお、開発社によっては Fluent Bit や CloudWatch を用いたカスタマイズもしています。 第三に、Aurora MySQL スナップショットの方法にも 2 通りの方法を決めています。 1 つ目が SELECT INTO OUTFILE の SQL ステートメントを実行する方法です。ここでは、インスタンスへの負荷を考慮してリードレプリカを用いることや AWS Lambda でのタイムアウトを避けるため AWS Glue ジョブの Python Shell で実行することを推奨しています。2 つ目が Amazon S3 のエクスポート機能を用いる方法です。こちらは制約が多い代わりに簡単に実行できるものです。 以上に挙げた内容は、後から決めるのではなく最初に決めておくことが大事だと白川氏は強調しました。MIXI では、一定のルールを設けつつも後から柔軟に変更しています。そしてデータ形式やインフラの共通化により、リソースの最適化や横断的な同様のクエリでの分析の実現といったメリットがありました。 最後に 今回ご紹介したものをはじめとして、AWS 上には効率的に分析するための様々なサービスや機能があります。ゲームを発展させるのに分析は一つの重要な要素ですので、ご自身のゲームにおいてもぜひ活用をご検討ください。また、AWS for Games Live は AWS 公式ウェブマガジン builders.flash と連動して、定期的に開催しております。今回複数のセッションで紹介された現在 Public Preview 中の Zero-ETL 統合機能も、 builders.flash 内の記事 で取り上げていますので、ご興味があればぜひご覧ください。 ※この記事はTakumi Kawashimaが作成し、Hiroshi Sumiが代理で投稿しています。

AWS European Sovereign Cloud により、政府機関、規制が厳しい業界、およびそれらをサポートする独立系ソフトウェアベンダー (ISV) は、欧州連合 (EU) に所在し、かつ、EU の居住者である AWS の従業員によって運用およびサポートされる AWS インフラストラクチャ上で、機密データを保存したり、重要なワークロードを実行したりできるようになります。最初のリージョンはドイツ国内に設けられることになります。 背景 2022年末、当社は AWS Digital Sovereignty Pledge を発表し、クラウドで利用できる最先端の主権コントロールと機能のセットをお客様 (およびすべての AWS をご利用のお客様) に提供することをお約束しました。そのお知らせ以降、当社は、その誓約を守るためにいくつかの重要な一歩を踏み出しました。 2023 年 5 月 – AWS Nitro System が独立したサードパーティーによって検証され、AWS の誰かが AWS ホスト上のお客様のデータにアクセスすることを許可するいかなるメカニズムも含まれていないことが確認されたことを お知らせ しました。同時に、 AWS Key Management Service (KMS) 外部キーストア を利用することで、AWS の外部にキーを保存し、そのキーを使用して AWS に保存されているデータを暗号化できることをお知らせしました。 2023 年 8 月 – AWS 専有ローカルゾーン を 発表しました 。これは、AWS が完全に管理し、特定のお客様またはコミュニティ専用に構築され、お客様が指定する場所またはデータセンターに設けられるインフラストラクチャです。 AWS European Sovereign Cloud 今後の AWS European Sovereign Cloud は、フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム、スペイン、チューリッヒで既にオープンしている 8 つの既存の AWS リージョンとは別個であり、これらから独立したものとなります。これにより、既に使い慣れた AWS サービス、API、ツールが提供されると同時に、デプロイのための追加のオプションが提供されます。この設計は、データレジデンシー、運用上の自律性、回復力のニーズを満たすのに役立ちます。 このクラウドと既存の AWS グローバルクラウドの間の分離を維持するには、新しい AWS アカウントを作成する必要があります。作成するメタデータ (データラベル、カテゴリ、許可、設定など) は EU 内に保存されます。これは、支出データや請求データなどの AWS アカウント情報には適用されません。これらの情報は、一定量の使用と引き換えに適用される該当階層内で、有利な料金が確実に適用されるようにするために集計および使用されます。 前述のとおり、このクラウドは、EU に所在し、かつ、EU の居住者である AWS の従業員によって運用およびサポートされ、サポートは 24 時間年中無休で利用可能となる予定です。 AWS European Sovereign Cloud は、運用上、他のリージョンから独立し、別個のリージョン内の請求システムおよび使用量測定システムが使用されることになります。 初期のリージョン 初期のリージョンはドイツ国内に設けられることになります。これは、複数のアベイラビリティーゾーンを利用して立ち上げられます。これらの各アベイラビリティーゾーンは個別の異なる地理的位置に所在し、これらの間には十分な距離が確保されるため、単一のイベントがビジネスの継続性に影響を及ぼすリスクを大幅に軽減できます。 立ち上げが近づくにつれて、利用可能なサービスやインスタンスタイプなどに関するさらなる詳細が判明する予定です。 将来的には、このクラウド内のこのリージョンと他のリージョンは、 AWS Outposts および専有ローカルゾーン用の親リージョンとしても機能するようになる予定です。これらのオプションにより、分離と国内のデータレジデンシーに関してさらに柔軟な対応が可能になります。ご自身の所在国の 専有ローカルゾーン にご関心がおありの場合は、担当の AWS アカウントマネージャーにお問い合わせください。 準備を整えましょう 既存のリージョンのいずれかで今すぐアプリケーションの構築を開始し、リージョンの立ち上げ時にそれらを AWS European Sovereign Cloud に移行できます。特定のリージョンに固有の問題をより深く理解するために、現地の規制当局との対話を開始することもできます。 – Jeff ; 原文は こちら です。

AWS ニュースブログチームの全員が、ラスベガスで行われる毎年恒例のカスタマーカンファレンス、 AWS re:Invent の開催中に新しいサービスと機能を発表するための記事の執筆に全力で取り組んでいます! そして、私たちが皆さんに読んでいただくためのコンテンツを準備している間も、AWS のサービスチームは革新し続けています。以下は、10月16日週のリリースの概要です。 10月16日週のリリース 私が関心を持ったリリースをいくつかご紹介しましょう。 Amazon CodeCatalyst – CI/CD ワークフローをトリガーするための cron 式を追加できるようになりました。 これは、ワークフローを指定された時間に開始する手段を提供します。CodeCatalyst は、プロジェクトのコラボレーションツール、CI/CD パイプライン、および開発環境とデプロイ環境を統合する統合開発サービスです。 Amazon Route53 – お客様のトラフィックをお客様に最も近い AWS Local Zones にルーティング して、レイテンシーの影響を受けやすいワークロードのアプリケーションパフォーマンスを向上させることが可能になりました。詳細については、Route53 のドキュメントの「 Geoproximity routing 」を参照してください。 Amazon RDS – AWS がお客様のデータベースの TLS 証明書に署名するために使用するルート証明書は、2024 年に有効期限が切れます。データベース用の新しい証明書は、有効期限日の前に生成しておく必要があります。 このブログ記事には、そのステップバイステップ手順が詳しく説明されています 。AWS が生成した新しいルート証明書の有効期間は、 RSA2048 では今後 40 年、 RSA4098 および ECC384 では 100 年になります。AWS のデータベース証明書を更新する義務を負うのは、皆さんのプロとしてのキャリアの中でこれが最後になるでしょう。 Amazon MSK – Kafka クラスターを大規模に複製することは困難で、大抵の場合は、インフラストラクチャとレプリケーションソリューションを独自に管理しなければなりません。AWS は、同じ AWS リージョン内、または複数の AWS リージョンにまたがる Kafka クラスターのためのフルマネージドレプリケーションソリューション、 Amazon MSK Replicator の提供を開始しました。 Amazon CodeWhisperer – Amazon CodeWhisperer Professional の次なる機能のプレビューが開始されました。 これからは、プライベートコードベースで CodeWhisperer をトレーニングできるようになります 。この機能は、より適切な提案を組織の開発者に提供することによって、組織のプライベートライブラリやフレームワークに対する毎日のコーディングで開発者をよりよくサポートできるようにします。 Amazon EC2 – 第 7 世代のメモリ最適化 EC2 インスタンス (R7i) が利用可能になりました 。これらのインスタンスは、第 4 世代インテル Xeon スケーラブルプロセッサー ( Sapphire Rapids ) を使用しています。このインスタンスファミリーは、最大 192 個の vCPU と 1,536 GB のメモリを提供します。これらは、インメモリデータベースやキャッシュなどのメモリ集約型アプリケーションに最適です。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供が開始されました。 Amazon Bedrock が欧州 (フランクフルト) で利用可能になりました 。ヨーロッパのお客様は、そのデータが欧州連合内に維持されることを確実にしなければならない場合が多いため、この機能はこれらのお客様にとって重要です。これからは、プロンプトやカスタム設定がヨーロッパ内に維持されるという確信を持ったうえで、アプリケーションに生成系 AI 機能を組み込み、大規模言語モデルにアクセスすることができるようになります。 Amazon EC2 が、複数のインスタンスファミリーのフットプリントを拡大し、カナダ (中部) と南米 (サンパウロ) で m6gd インスタンス 、 カナダ (中部) で c6a インスタンス、カナダ (中部) と欧州 (ミラノ) で m6a インスタンス、そして米国西部 (北カリフォルニア) とアジアパシフィック (シンガポール) で r6a インスタンス の提供を開始しました。最後に、欧州 (チューリッヒ) では m6id インスタンスが利用できるようになりました 。 Amazon EMR Managed Scaling がアジアパシフィック (ジャカルタ) で利用可能になりました。 その他の AWS ニュース 以下は、皆さんが興味を持つと思われるその他のブログ記事とニュースです。 Community.AWS ブログが、 Java アプリケーションと Go アプリケーション内に Amazon Bedrock を統合する方法を説明する新しい記事を発表しました。また、私の同僚である Brooke も、 re:Invent に初めて参加する人のためのサバイバルガイド を書きました。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS ニュースのすばらしい情報源には、他にも次のようなものがあります。 AWS Open Source Newsletter AWS Graviton Weekly AWS Cloud Security Weekly Last Week in AWS 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーが運営する、コミュニティ主導のカンファレンスに参加しましょう。このカンファレンスは、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、および ブラジル (11 月 4 日) で開催されます。 AWS Innovate: Every Application Edition – 無料のオンラインカンファレンスに参加して、 セキュリティと信頼性の強化、限られた予算でのパフォーマンスの最適化、アプリケーション開発の迅速化を行い、生成系 AI を用いてアプリケーションに大革新をもたらすための最先端の方法を探りましょう。10 月 26 日に開催される AWS Innovate Online アジアパシフィック & 日本 にぜひ登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – このカンファレンスに参加 して、AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent ハイライト を確認してください。 近日開催される対面イベントと仮想イベントのすべてを閲覧することができます。 10月23日週のニュースは以上です。re: Invent ブログ記事の執筆に戻ろうと思います。 10月30日週の Weekly Roundup もお楽しみに! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) コンソールで [証明書の更新] を目にしても驚かないでください。 Amazon RDS for MySQL、MariaDB、SQL Server、Oracle、PostgreSQL、Amazon Aurora のデータベースインスタンスに接続するために、Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を証明書の検証とともに使用しているか、または使用する予定がある場合、ルート証明書の有効期限が切れる前に、DB インスタンスとアプリケーションの両方で新しい認証機関 (CA) 証明書をローテーションする必要があります。 DB インスタンスのほとんどの SSL/TLS 証明書 ( rds-ca-2019 ) は、 2020 年の証明書の更新 後、2024 年に期限切れになります。2022 年 12 月に、40 年間有効な CA 証明書 ( rds-ca-rsa2048-g1 ) と 100 年間有効な CA 証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) を新しくリリースしました。これにより、CA 証明書をローテーションした後、長期にわたって、再度ローテーションする必要はありません。 影響を受けるリージョンと、それらの rds-ca-2019 の有効期限の一覧を次に示します。 有効期限 リージョン 2024 年 5 月 8 日 中東 (バーレーン) 2024 年 8 月 22 日 米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (ストックホルム)、および南米 (サンパウロ) 2024 年 9 月 9 日 中国 (北京)、中国 (寧夏) 2024 年 10 月 26 日 アフリカ (ケープタウン) 2024 年 10 月 28 日 欧州 (ミラノ) 2061 年まで影響なし アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、欧州 (スペイン)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (UAE)、AWS GovCloud (米国東部)、および AWS GovCloud (米国西部) 次のステップでは、アプリケーションからデータベースインスタンスへの接続を維持するために証明書をローテーションする方法を示します。 ステップ 1 – 影響を受ける Amazon RDS リソースを特定する 前述したように、 Amazon RDS コンソール の [証明書の更新] ページで影響を受ける DB インスタンスの総数を確認し、影響を受けるすべての DB インスタンスを表示できます。注: このページには、現在のリージョンの DB インスタンスのみが表示されます。複数のリージョンに DB インスタンスがある場合は、各リージョンの証明書の更新のページを確認して、古い SSL/TLS 証明書を使用しているすべての DB インスタンスを表示します。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して describe-db-instances を呼び出し、期限切れの CA を使用するインスタンスを見つけることもできます。クエリにより、アカウントと us-east-1 リージョン内の RDS インスタンスのリストを表示できます。 $ aws rds describe-db-instances --region us-east-1 | jq -r '.DBInstances[] | select ((.CACertificateIdentifier != "rds-ca-rsa2048-g1") and (.CACertificateIdentifier != "rds-ca-rsa4096-g1") and (.CACertificateIdentifier != "rds-ca-ecc384-g1")) | "DBInstanceIdentifier: (.DBInstanceIdentifier), CACertificateIdentifier: (.CACertificateIdentifier)"' ステップ 2 – データベースクライアントとアプリケーションを更新する DB インスタンスに新しい証明書を適用する前に、接続するために SSL/TLS およびサーバー証明書を使用するクライアントとアプリケーションの信頼ストアを更新する必要があります。 現在、アプリケーションが接続するための前提条件として証明書の検証が必要かどうかを、DB インスタンス自体から簡単に判断する方法はありません。ここでの唯一のオプションは、アプリケーションのソースコードまたは設定ファイルを検査することです。 DB エンジン固有のドキュメント には、極めて一般的なデータベース接続インターフェイスで注意すべき点が概説されていますが、証明書の検証が使用されているかどうか、および特定のクライアントアプリケーションのためにアプリケーションの SSL/TLS 証明書を更新する正しい方法をアプリケーションデベロッパーに確認することを強くお勧めします。 アプリケーションの証明書を更新するために、古い CA と新しい CA の両方の証明書を含む 新しい証明書バンドル を使用できます。これにより、アプリケーションを安全にアップグレードし、移行期間中も接続を維持できます。 各 DB エンジンについての SSL/TLS 接続の確認とアプリケーションの更新については、次のトピックを参照してください。 新しい SSL/TLS 証明書を使用して MariaDB DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Microsoft SQL Server DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して MySQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Oracle DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Aurora MySQL DB クラスターに接続するようにアプリケーションを更新する 。 新しい SSL/TLS 証明書を使用して Aurora PostgreSQL DB クラスターに接続するようにアプリケーションを更新する 。 ステップ 3 – 非本番 RDS インスタンスで CA ローテーションをテストする すべての信頼ストアで新しい証明書を更新した場合は、非本番環境で RDS インスタンスを使用してテストする必要があります。この設定は、本番環境と同じデータベースエンジンとバージョンを備えた開発環境で実行します。また、このテスト環境は、本番と同じコードと設定を使用してデプロイする必要があります。 テストデータベースインスタンスで新しい証明書をローテーションするには、 Amazon RDS コンソール で、変更する DB インスタンスについて [変更] を選択します。 [接続] セクションで、 rds-ca-rsa2048-g1 を選択します。 [続行] を選択して、変更の概要を確認します。変更をすぐに適用する場合は、 [すぐに適用] を選択します。 AWS CLI を使用して DB インスタンスのために CA を rds-ca-2019 から rds-ca-rsa2048-g1 に変更するには、 modify-db-instance コマンドを呼び出し、 --ca-certificate-identifier オプションを使用して DB インスタンス識別子を指定します。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --apply-immediately これは、本番データベースインスタンスで新しい証明書を手動でローテーションする方法と同じです。参照した信頼ストアまたは CA 証明書バンドルを使用したローテーションの後、アプリケーションが SSL/TLS を使用して問題なく再接続することを確認します。 新しい DB インスタンスを作成する場合、デフォルトの CA は 2024 年 1 月 25 日までは rds-ca-2019 のままですが、その後は rds-ca-rsa2048-g1 に変更されます。新しい CA を設定して新しい DB インスタンスを作成する場合、CA オーバーライドを設定して、すべての新しいインスタンスの起動で任意の CA が使用されるようにできます。 $ aws rds modify-certificates \ --certificate-identifier rds-ca-rsa2048-g1 \ --region <region name> これは、RDS DB インスタンスが存在するすべてのリージョンで行う必要があります。 ステップ 4 – 本番 RDS インスタンスを安全に更新する 非本番環境でのテストが完了したら、本番環境で RDS データベース CA 証明書のローテーションを開始できます。ステップ 3 に示すように、DB インスタンスを手動でローテーションできます。今日のエンジンの多くは再起動を必要としませんが、メンテナンス期間に再起動をスケジュールすることが推奨されることにご留意ください。 ステップ 1 の [証明書の更新] ページで、ローテーションする DB インスタンスを選択します。 [スケジュール] を選択すると、次のメンテナンス期間に証明書のローテーションをスケジュールできます。 [今すぐ適用] を選択すると、ローテーションをすぐに適用できます。 [スケジュール] を選択すると、証明書のローテーションを確認するよう求めるプロンプトが表示されます。このプロンプトは、更新のスケジュールウィンドウも示します。 (すぐに、またはメンテナンス期間中に) 証明書が更新された後、データベースとアプリケーションが想定どおりに動作していることを確認する必要があります。 今日の DB エンジンのほとんどでは、証明書を更新するためにデータベースを再起動する必要はありません。CA 更新のためだけにデータベースを再起動したくない場合は、 modify-db-instance コマンドで --no-certificate-rotation-restart フラグを使用できます。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --no-certificate-rotation-restart エンジンの再起動が必要かどうかを確認するには、 describe-db-engine-versions コマンドの出力で SupportsCertificateRotationWithoutRestart フィールドを確認します。このコマンドを使用すると、再起動なしでのローテーションをサポートしているエンジンを確認できます。 $ aws rds describe-db-engine-versions \ --engine <engine> --include-all --region <region> | jq -r '.DBEngineVersions[] | "EngineName: (.Engine), EngineVersion: (.EngineVersion), SupportsCertificateRotationWithoutRestart: (.SupportsCertificateRotationWithoutRestart), SupportedCAs: ([.SupportedCACertificateIdentifiers | join(", ")])"' データベースインスタンスのために SSL/TLS を使用しない場合でも、CA をローテーションすることをお勧めします。将来的に SSL/TLS を使用する必要がある場合があります。その場合、JDBC コネクタや ODBC コネクタなどの一部のデータベースコネクタは、接続する前に有効な証明書をチェックします。その際、CA の期限が切れていると、SSL/TLS を使用できない可能性があります。 DB インスタンスを手動で変更することによる証明書の更新、サーバー証明書の自動ローテーション、信頼ストアに証明書をインポートするためのサンプルスクリプトの検索の詳細については、「 Amazon RDS ユーザーガイド 」または「 Amazon Aurora ユーザーガイド 」を参照してください。 留意点 知っておくべき重要な事項をいくつか次に示します。 Amazon RDS Proxy と Amazon Aurora Serverless は、 AWS Certificate Manager (ACM) からの証明書を使用します。SSL/TLS 証明書をローテーションする際に Amazon RDS Proxy を利用している場合は、Amazon RDS Proxy 接続を使用するアプリケーションを更新する必要はありません。Aurora Serverless を利用している場合、SSL/TLS 証明書をローテーションする必要はありません。 現在から 2024 年 1 月 25 日 まで – 新しい RDS DB インスタンスには、 create-db-instance API の ca-certificate-identifier オプションで別の CA を指定しない限り、デフォルトで rds-ca-2919 証明書が含まれます。または、上記のセクションで言及したように、アカウントのためにデフォルトの CA オーバーライドを指定します。 2024 年 1 月 26 日 以降 – 新しいデータベースインスタンスは、 rds-ca-rsa2048-g1 証明書を使用するようデフォルト設定されます。新しいインスタンスのために別の証明書を使用することを希望する場合は、AWS コンソールまたは AWS CLI を使用して、どの証明書を使用するかを指定できます。詳細については、 create-db-instance API ドキュメント を参照してください。 Amazon RDS for SQL Server を除き、今日の RDS および Aurora エンジンのほとんどは、その最新バージョンにおいて、データベースの再起動なしでの証明書のローテーションをサポートしています。 describe-db-engine-versions を呼び出し、応答フィールド SupportsCertificateRotationWithoutRestart を確認します。このフィールドが true に設定されている場合、インスタンスでは CA 更新のためにデータベースを再起動する必要がありません。 false に設定すると、再起動が必要になります。詳細については、AWS ドキュメントの「 データベースのために CA を設定する 」を参照してください。 ローテーションされた CA は、各 DB インスタンスにインストールされる DB サーバー証明書に署名します。DB サーバー証明書は、信頼されたサーバーとして DB インスタンスを識別します。DB サーバー証明書の有効期間は、DB エンジンとバージョンによって異なり、1 年間または 3 年間です。CA がサーバー証明書の自動ローテーションをサポートしている場合、RDS は DB サーバー証明書のローテーションも自動的に処理します。DB サーバー証明書のローテーションの詳細については、AWS ドキュメントの「 サーバー証明書の自動ローテーション 」を参照してください。 40 年間有効な証明書 ( rds-ca-rsa2048-g1 ) または 100 年間有効な証明書を使用することを選択できます。RDS インスタンスによって使用される期限切れの CA は、RSA2048 鍵アルゴリズムと SHA256 署名アルゴリズムを使用します。 rds-ca-rsa2048-g1 はまったく同じ設定を使用するため、互換性の点で最適です。100 年間有効な証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) は、 rds-ca-rsa2048-g1 よりも安全な暗号化スキームを使用します。これらを使用する場合は、本番前環境で十分にテストし、データベースクライアントとサーバーがリージョンで必要な暗号化スキームをサポートしていることをダブルチェックする必要があります。 すぐに始めましょう! 証明書の有効期限が切れるまであと 1 年間ある場合でも、チームと連携して計画を開始すべきです。SSL/TLS 証明書を更新するには、有効期限が切れる前に DB インスタンスを再起動する必要がある場合があります。有効期限前にアプリケーションを更新するようにスケジュールし、本番環境でこれらのステップを完了する前に、ステージングまたは本番前のデータベース環境でテストを実行することを強くお勧めします。SSL/TLS 証明書の更新の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 SSL/TLS 接続を使用しない場合、データベースセキュリティのベストプラクティスは、SSL/TLS 接続を使用し、接続認証プロセスの一部として証明書の検証をリクエストすることです。SSL/TLS を使用して DB インスタンスへの接続を暗号化する方法の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 ご質問や問題がある場合は、ご利用のサポートプランに応じて、通常の AWS サポート までお問い合わせください。 – Channy 原文は こちら です。

モダンアプリケーションは、モジュール式かつ分散型のコンポーネントで構築されています。お客様は、特にハイブリッドクラウド環境において、サービスコンポーネント間のアプリケーションネットワーキングをシンプル化する柔軟な方法を求めています。 VMware Cloud on AWS を利用することで、お客様はオンプレミスの vSphere 環境からのワークロードとアプリケーションをシームレスなハイブリッドクラウド体験で Software Defined Data Center (SDDC) に簡単に移行できます。 ワークロードを VMware Cloud on AWS に移行するにつれ、SDDC 上で実行されている既存のアプリケーションと、ネイティブ AWS サービスを使用してデプロイされた新しいサービスとの接続要件に対処することが不可欠となってきます。 異なる AWS アカウントや Amazon Virtual Private Cloud (VPC) 間のサービス接続をサポートするには通常、 VPC ピアリング 、 AWS Transit Gateway 、 AWS PrivateLink 、 サービスメッシュ プロキシなど、追加のネットワーキングサービスとコンポーネントをプロビジョニングする必要があります。 さらに、複数の AWS アカウントと VPC を持つお客様は、重複する CIDR ブロックや環境分離の要件などの課題に直面することが多く、サービス間のアンダーレイとなる IP 接続性の構築をさらに複雑にします。 この記事では、 Amazon VPC Lattice が SDDC やクラウドネイティブ環境全体のサービス間通信を、アンダーレイネットワークの複雑さを抽象化しながらシンプル化する方法を見ていきます。また、VPC Lattice を活用して、VMware Cloud on AWS からクラウドネイティブサービスへアプリケーションをシームレスに変換、移行できることも説明します。 Amazon VPC Lattice 概要 2023 年 3 月、AWS はアプリケーションネットワーキングサービス「Amazon VPC Lattice」の 一般提供を発表 しました。VPC Lattice は、サービス間通信のディスカバリと接続を容易にするものです。 VPC Lattice は、論理的なアプリケーションレイヤーネットワークである サービスネットワーク を作成します。これにより、異なる AWS アカウントや Amazon VPC 間でのサービスネットワーク全体のクライアント (コンシューマー) とサービス (プロバイダー) 間のアプリケーション通信を、アンダーレイネットワークの複雑さを抽象化してシンプル化します。 以下の図を元に Amazon VPC Lattice の主なコンポーネントを確認しましょう。 図1 – Amazon VPC Lattice の主なコンポーネント サービス : VPC Lattice サービスは、特定のタスクや機能を提供するカスタマーアプリケーションを表します。サービスは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、サーバーレス関数など、さまざまなコンピュートオプションで実行できます。VPC Lattice サービスは、 AWS Resource Access Manager (RAM) を使用して他の AWS アカウントと共有できます。VPC Lattice サービスには、次の要素が含まれます。 ターゲットグループ – アプリケーションやサービスを提供するリソースの集まりです。ターゲットには、EC2 インスタンス、IP アドレス、 AWS Lambda 関数、 Application Load Balancer 、 Kubernetes Pod を指定できます。 リスナー – 定義されたプロトコル (HTTP/HTTPS) とポート番号に基づいて、ターゲットグループ内のターゲットに接続リクエストをルーティングするプロセスです。 ルール – 優先順位、条件、アクションが定義されたアプリケーションフローを制御するルーティングルールです。 サービスネットワーク : サービスの集合を論理的に区切る境界。VPC Lattice サービスと VPC をサービスネットワークに関連付けて、サービス接続を容易にすることができます。RAM を使用して、サービスネットワークを他のアカウントと共有することもできます。 サービスディレクトリ : 所有または RAM 経由で共有されているすべての VPC Lattice サービスの中央レジストリ。 認証ポリシー : サービスへのアクセスを制御するために、サービスネットワークまたはサービスに関連付けることができる AWS Identity and Access Management (IAM) ポリシー。 VPC がサービスネットワークと関連付けられると、VPC 内のクライアントは Domain Name System (DNS) を使用して、サービスネットワークに登録されたサービスを自動的に検出できるようになります。さらに、登録済みサービスのすべてのアプリケーション間トラフィックは VPC Lattice を通過するようになります。 VPC Lattice は、IAM ベースの認証ポリシーを使用したコンテキスト固有の認証によって、アプリケーション接続のセキュリティも強化します。これにより、顧客は細かいトラフィック制御とエンドツーエンドの可観測性が得られます。 VPC Lattice の詳細については、この ブログ記事 と Amazon VPC Lattice リファレンスアーキテクチャ を参照してください。 VMware Cloud on AWS と VPC Lattice の統合 SDDC ENI を介した Application Load Balancer の活用 VMware Cloud on AWS 上で実行されているアプリケーションを Amazon VPC Lattice と統合するには、Application Load Balancer が必要です。これは、VPC Lattice が一意のリンクローカルアドレスレンジの 169.254.171.0/24 を使用しているためです。このアドレスレンジは VPC 内でのみローカルにアクセス可能で、SDDC 外部にルーティングできません。 そこで、 Connected VPC 内に Application Load Balancer をデプロイすることで、 VPC Lattice からの着信リクエストを終端できます。これにより、広帯域かつ低レイテンシの SDDC Elastic Network Interface (ENI) を使用して、SDDC 上にホストされているワークロードにアプリケーションフローを IP ターゲット としてルーティングできます。サンプルアーキテクチャは以下の通りです。 図2 – Application Load Balancer を介した SDDC ENI 統合   SDDC と Connected VPC 間のデータ転送は、SDDC とネイティブサービスが同じ AWS アベイラビリティーゾーン (AZ) 内にデプロイされている限り、いかなる egress 通信コストも発生しません。 以下のスクリーンショットに示すように、Connected VPC 内に 内部 Application Load Balancer をプロビジョニングすると、 ユーザーガイド に従って、SDDC 上で実行されているアプリケーション向けの Lattice ターゲットグループ (およびサービス) を作成できます。 図3 – VPC Lattice ターゲットグループとして Application Load Balancer を登録  VMware Transit Connect を介した Application Load Balancer の活用 Application Load Balancer を Lattice サービスとは分けた VPC に展開し、 VMware Transit Connect を介してアプリケーショントラフィックを SDDC に渡すという選択肢もあります。以下の図のような構成です。 図4 – VMware Transit Connectを介した Application Load Balancer の統合 これは、Application Load Balancer がセキュリティ検査の要件のために Central Ingress VPC に展開されている場合に有効です。サービスネットワークは、別の AWS アカウントに存在し、AWS RAM を使用して ingress VPC と共有されることもあります。 VMware Transit Connect は、VMware が管理する AWS Transit Gateway ソリューションで、お客様のSDDC、クラウドネイティブサービス、オンプレミスリソース間の高速かつ回復性のある接続を提供します。SDDC と Amazon VPC を接続するために VMware Transit Connect をプロビジョニングする方法については、 VMware のブログ記事 を ( 日本語ブログはこちら ) 参照してください。 お客様の環境で AWS Transit Gateway をすでに利用している場合は、ingress Application Load Balancer で着信サービスリクエストを終端し、アプリケーションフローを リージョン内ピアリング を使用した AWS Transit Gateway とVMware Transit Connect 経由で SDDC に配信することが可能です。以下の図は、このサンプルアーキテクチャを示しています。 図 5 – リージョン内ピアリングによる Application Load Balancer 統合 SDDCとネイティブサービス間のアプリケーション接続のシンプル化 VMware Cloud on AWS のお客様が、アプリケーションネットワーキングをシンプル化し、変革を加速する VPC Latticeの活用例を見ていきましょう。 最初の例では、お客様はオンプレミスのアプリケーション群を VMware Cloud on AWS に移行しました。新しくSoftware-as-a-Service (SaaS) 製品のローンチを計画しており、これには SDDC-01 上のバックエンド APIサービス (Service 1) を、ネイティブ AWS 環境で最近構築された 2 つのマイクロサービス (Service2, Service3) と統合する必要があります。これらのマイクロサービスは、下の図に示すように、異なる AWS アカウントと VPC にまたがる AWS Lambda と Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされています。 図 6 – SDDC アプリケーションと複雑性のある AWS 環境の統合 お客様は以下のサービス統合の要件と課題があります: VPC-02 の CIDR と SDDC-01 の CIDR は一部重複しています。 VPC-03 は、外部のサービスプロバイダーが所有する別の AWS Organization の下にデプロイされているため、直接 IP 接続を確立することは許可されていません。 Service 2 と Service 3 は、Service 1 にアクセスする必要があります。 Service 2 と Service 3 は、双方向で通信する必要があります。 この場合、マルチアカウント環境における SDDC、コンテナ、サーバーレス関数全体で、セキュアかつプライベートなアプリケーション間接続を構築するために、VPC Lattice を活用できます。 VPC Lattice のユニークなリンクローカルアドレスレンジは、VPC や SDDC 間の潜在的なIPアドレスの競合問題も解消します。 まず、SDDC-01 にアタッチされた Connected VPC 内に、Service 1 の Application Load Balancer を作成する必要があります。これは、Lattice サービスはネイティブ VPC 内でのみアクセスできるため、Service 1 のすべての着信サービスリクエストを Connected VPC で終端するためです。 次に、VPC Lattice サービスネットワークを作成し、AWS RAM を介して 3 つのサービスアカウント (Account 1 ~3) と共有します。これにより、各アカウントで個別の VPC Lattice サービス (Service 1~3 向け) を作成し、サービスネットワークに関連付けることができます。 最後に、Service 2 と Service 3 が双方向通信を必要とするため、VPC-02 と VPC-03 をサービスネットワークに関連付ける必要があります。 ただし、Service 3 はバックエンドサービスであるため、Connected VPC をサービスネットワークに関連付ける必要はありません。 以下にアーキテクチャ、ソリューションの概要を示しています。 図 7 – VPC Lattice によるアプリケーション間ネットワーキングのシンプル化 VPC Lattice を使用すると、マルチアカウントおよびマルチ VPC 環境における VMware Cloud on AWS アプリケーションとクラウドネイティブサービス間の相互接続を素早く構築できます。また、AWS Transit Gateway、AWS PrivateLink、 Private NAT Gateway など、追加のネットワークインフラストラクチャサービスの構築による複雑さと管理オーバーヘッドを排除できます。 さらに、VPC Lattice には Lattice サービスごとに一意の DNS 名を自動的に割り当てる、組み込みの DNS ベースのサービスディスカバリーがあります。 Amazon Route 53 プライベートホストゾーンを利用することで、サービスの CNAME、またはエイリアスレコードをカスタマイズすることもできます。 VPC Lattice によるアプリケーション変革の加速 次の例では、VPC Lattice が VMware Cloud on AWS のお客様がアプリケーションをシームレスにクラウドネイティブサービスに変換・移行するのにどのように役立つかを探っていきます。 お客様は SDDC 上で実行されているレガシーアプリケーションのリファクタリングを進めており、それを AWS Lambda のサーバーレス関数に再構築しました。SDDC 内のレガシーアプリケーションから Lambda 関数へのサービストラフィックの切り替え前に、アップストリームの他のサービスへの潜在的な影響を調査するための一連のカナリアテストを実施したいと考えています。 Amazon VPC Lattice は、このシナリオのような ブルー/グリーン や カナリアスタイル のロールアウトなど、一般的なデプロイメントパターンをサポートしています。VPC-02 の Lambda 関数を使用する 1 つのターゲットグループと、Connected VPC 内の Application Load Balancer を公開して SDDC-01 上のレガシーアプリケーションに向けたもう 1 つのターゲットグループで VPC Lattice サービスを設定できます。 その後、以下の図に示すように、リクエスト条件 (パス、メソッド、ヘッダー) に基づいて、 2 つのターゲットグループ間でトラフィックを分散する重み付けルーティングを利用できます。 図 8 – VPC Lattice による SDDC と AWS Lambda を横断したカナリアロールアウト VPC Lattice は、サービス間の詳細なアクセスログを提供します。サポートされているログ配信ターゲットには、 Amazon Simple Storage Service (Amazon S3) バケット、 Amazon Kinesis Data Firehose 、 Amazon CloudWatch のロググループが含まれます。これにより、お客様は必要なログの詳細を迅速に取得し、特定のサービスまたはサービスネットワーク全体で発生し得る問題を特定および分析できます。 VPC Lattice は、アプリケーションの変革とモダナイゼーションを促進し、新しいアイデアを簡単に試すことができ、必要に応じて迅速にロールバックできるようにします。 これにより、サービス移行時のリスクを軽減し、最終的にエンドユーザーの体験を向上させます。 追加の考慮事項 サービスネットワーク全体でのネットワークレベルの保護を実施するため、VPC Lattice の AWS マネージドプレフィックスリスト をセキュリティグループで活用することをおすすめします。 さらに、個々のサービスまたはサービスネットワーク全体のいずれかに、強力な認証とコンテキスト固有の認可を適用するために、サービスレベルの認証ポリシーを使用できます。詳細は、こちらの AWS ブログ記事 を参照してください。 デフォルトでは、VPC Lattice のサービスはリンクローカルアドレスレンジがルーティング不可能なため、VPC 内からのみアクセスできます。 Lattice サービスへの外部接続性を提供するには、 Elastic Load Balancing とプロキシのフリートを使用した ingress VPC が必要です。サンプルアーキテクチャと実装ガイドは、この AWS ブログ記事 を参照してください。 AWS 責任共有モデル に従って、AWS インフラストラクチャ上にホストされるコンテンツの管理はお客様の責任となります。この ユーザーガイド に従って Amazon VPC Lattice を設定し、セキュリティとコンプライアンス目標を満たしてください。また、VMware Cloud on AWS の ネットワークとセキュリティの包括的なガイド も参照してください。 VMware Cloud on AWS 環境の強化に役立つ リソース があります。 価格については、Amazon VPC Lattice の 料金ページ をご確認ください。 AWS Transit Gateway や VMware Transit Connect の 料金 もご参照ください。 まとめ この投稿では、Amazon VPC Lattice が VMware Cloud on AWS のお客様にどのようにアプリケーションネットワーキングをシンプル化し、変革を加速できるかについて説明しました。一般的な統合アーキテクチャと使用例の概要についてもご紹介しました。 より詳細については、以下のリンクをご参考ください。 VMware Cloud on AWS ハイブリッドネットワークデザインパターン VPC Lattice のご紹介 – サービス間通信のためにネットワーキングを簡素化する Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 本稿は、ソリューションアーキテクトの齋藤が翻訳を担当しました。原文は こちら です。

このブログは 2023 年 10 月 2 日に 執筆された内容を日本語化したものです。原文は こちら をご参照ください。 (原文はイベント開催前に掲載された為、イベント期間中のみの活動については省略しています) Unreal Engine (UE) の開発会社である Epic Games が主催する毎年恒例の開発者カンファレンスである Unreal Fest は、 10 月 3 日から 5 日までニューオリンズで開催され、 3 日間の講演セッション、ハンズオンワークショップ、業界に特化したトラックを開催します。このカンファレンスにはゲーム開発者、デザイナー、アーティスト、様々な業界の専門家が一堂に会し、最新テクノロジーについてより深い洞察を得たり、専門家から学んだり、 UE のクリエイターやゲーム開発者と交流したりします。このブログ記事では Unreal Fest 2023 での AWS for Games のプレゼンスについて取り上げます。 UE のゲーム開発者が AWS を使用してリアルタイム 3D 体験をどのようにスケーリングしているかについては、 AWS と Unreal Engine をご覧ください。 現地での活動 AWS は今年 Unreal Fest のプラチナスポンサーになったことを誇りに思います。これには、パートナーセッション、ブースプレゼント、 AWS 業界の専門家によるライブ製品デモが含まれます。 AWS で Unreal Engine のゲームを構築しているお客様 高度な 3D ゲーム開発テクノロジーと専用のグローバルインフラストラクチャ機能を組み合わせることで、ゲームスタジオがどのようにゲームを構築、運営、成長させているかをご紹介します。 Epic Games は 2018 年にアマゾンウェブサービス （AWS） を全面的に採用し、ビジネスに不可欠なストレージ、分析、スケーリング機能を提供しました。これは毎日約 1,500 万人のアクティブユーザーがいるオンラインゲーム「フォートナイト」のリリースで爆発的に増加しました。フォートナイトは、世界中のゲームサーバー、バックエンドサービス、ウェブサイトを含め、ほぼすべて AWS 上で運営されています。詳細は こちら をご覧ください。 Odyssey Interactive は 2020 年に設立されたウォータールーを拠点とするゲームスタジオで、最初のゲームであるオメガストライカーズの発売と拡大のための費用対効果の高いソリューションを求めていました。オメガストライカーズは UE をベースに構築された 3 対 3 のエキサイティングなフットボールバトルゲームです。実績のある AWS と UE によるソリューションにより、 Odyssey Interactive はバックエンドのインフラストラクチャではなく優れたゲームの制作に集中できるようになりました。こちらの お客様のビデオ をご覧ください。 QXR Studios の共同創設者である Graeme Devine 氏は次のように語っています。「これまでは 100人 以上のチームがこのレベルで成果を出すのに 5 年の期間と 2500 万ドルがかかっていました。業界としては AWS や UE のようなツールにより、テクノロジーの基盤となるサービスに加えて、世界中のアーティストやモデラーにアクセスできるようになりました。これにより小規模なゲーム会社でも AAA のゲームコンテンツを制作できるようになり、ワクワクしています」。こちらの お客様のブログ をご覧ください。 Red Barrels はモントリオールに拠点を置く独立系ゲームスタジオで、スタジオの設立当初から UE をベースに開発を続けています。同社は最初のマルチプレイヤータイトルである「 Outlast Trials 」のゲームサーバーを管理するソリューションを必要としていました。 Red Barrels は UE と AWS の両方を選択しました。これはこれらのテクノロジーがゲーム開発プロセスにパワーと柔軟性をもたらすためです。こちらの お客様のビデオ をご覧ください。 Behaviour Interactive はカナダ最大のゲームスタジオの 1 つで、受賞歴のある非対称型マルチプレイヤーホラーゲーム「 Dead by Daylight 」は 2016 年の発売以来 5,000 万人を超えるプレイヤー数を獲得しています。 UE と AWS により、スタジオは忠実度の高いゲーム体験を制作し、何 100 万人ものプレイヤーに自信を持ってスケールできるようになりました。こちらの お客様のビデオ をご覧ください。 AWS での Unreal Engine 利用例 AWS for Games には、UE ゲーム開発者がコストを削減し、反復作業を迅速に行い、より良いプレイヤー体験を世界規模で提供できるよう支援する、用途別のポートフォリオが用意されています。 仮想ワークステーション – AWS 上の Epic Unreal Engine 5 ワークステーションは、 3D データをホストしてレンダリングするための高価なハードウェアや物理ワークステーションを必要とせずに、忠実度が高く没入感のある 3D 体験を世界中にシームレスに提供します。この Amazon Machine Image (AMI) には UE 5.2 とその動作に必要なものが予め用意されているため、ダウンロードやインストールなしでクラウドで直接制作作業を行う事ができます。詳細は こちら をご覧ください。 ビルドパイプライン – AWS 上の Incredibuild は、 UE の開発者と DevOps の管理者に、ゲームを継続的にビルド、改善、予定通りリリースするためのスケーラブルなプラットフォームを提供する強力なソリューションです。詳細は こちら をご覧ください。 バージョン管理 – AWS 上の Perforce Helix Core は、グローバルな規模と優れたパフォーマンスを実現するエンタープライズ向けのバージョン管理システムです。これは信頼できる単一のソースを UE のデジタルアセットに提供することで、グローバルなチームや大規模なバイナリアセットを管理できるようにします。詳細は こちら をご覧ください。 ゲーム QA とテスト – Amazon GameLift Anywhere は、環境内のハードウェアを統合する事で、ローカルワークステーションでリアルタイムにゲームプレイのモニタリングとデバッグが行える様高速化します。詳細は こちら をご覧ください。 ゲームサーバーホスティング – AWS Graviton3 プロセッサを搭載した Amazon GameLift の専用ゲームサーバー管理サービスは、計算集約型の UE ゲームに最適なコストパフォーマンスを実現します。 Unreal Engine 用 Amazon GameLift Plugin は、 Windows および Mac OS 用の UE 5、 UE 5.1、 UE 5.2、 UE 5.3 をサポートしており、最新の Amazon GameLift SDK 5 以上の API が含まれているため、お客様はUnreal Engine Editor でゲームをビルド、テスト、デプロイできます。詳細は こちら をご覧ください。 ゲーム分析 – AWS のゲーム分析パイプラインは、ゲーム開発者がスケーラブルなサーバーレスデータパイプラインを立ち上げ、 UE で作られたゲームクライアントのアクティブユーザーとビルドから生成されたプレイヤーデータを取り込み、保存、分析するのに役立ちます。詳細は こちら をご覧ください。 カスタムゲームバックエンドホスティング – AWS でのカスタムゲームバックエンドホスティングのガイダンスでは、 UE 5 のサンプルコードとともに、カスタマイズされた軽量でスケーラブルなクロスプラットフォーム向けのID認証機能をデプロイする方法を示しています。詳細は こちら をご覧ください。 ゲーム開発者が AWS 上で UE のゲームを構築、実行、成長させるのに役立つ、 7 つの専用機能 終わりに Unreal Fest はさまざまな業界のデベロッパーやクリエイターが一堂に会し、新しいプロジェクトについて学び、最新テクノロジーのハンズオントレーニングを受け、他のクリエイターと出会い、ネットワークを築くための今年のプレミアイベントです。 UE のゲームの開発者が、 AWS でゲームのワークロードと体験をどのように変革しているかについての詳細は AWS と Unreal Engine のホームページをご覧ください。 翻訳はソリューションアーキテクトの長田が担当しました。