AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

3670

このブログは、 Modular functions design for Advanced Driver Assistance Systems (ADAS) on AWS を翻訳したのものです。 過去 10 年間で、多くのプレイヤーがディープニューラルネットワーク(DNN)を使った自動運転車(AV)システムを開発してきました。これらのシステムはシンプルなルールベースのシステムから進化し、先進運転支援システム(ADAS)や完全な自動運転車へと変わってきています。これらのシステムはペタバイト規模のデータと数千の計算ユニット(vCPU と GPU)をトレーニングに必要とします。 この投稿では、ビルドアプローチ、ADAS の異なる機能ユニット、モジュラーパイプラインの構築アプローチ、および ADAS システムを構築する際の課題について取り上げています。 DNN トレーニング メソッド と デザイン AV システムは、ディープニューラルネットワーク(DNN)で構築されています。AV システムの設計には、2つの主要なアプローチがあります。その違いは、DNN がどのように訓練され、システムの境界が設定されているかに基づいています。 モジュラートレーニング &nbsp;– システムは個別の機能ユニット(例:認識、位置特定、予測、計画など)に分割されます。これは多くの AV システム提供者によって使用される一般的な設計パラダイムです。システムが個々のモジュールに分割されるため、それぞれが独立して構築・訓練されます。 エンドツーエンドトレーニング – このアプローチでは、センサーデータを入力として取り、運転コマンドを出力する DNN モデルを訓練します。これはモノリシックなアーキテクチャで、主に研究者によって探求されています。DNN アーキテクチャは通常、報酬/ペナルティシステムに基づく強化学習(RL)または人間の運転を観察する模倣学習(IL)に基づいています。全体的なアーキテクチャは単純ですが、モノリシックを解釈・診断するのは難しいです。しかし、アノテーションは安価で、システムは人間の行動を通じて収集されたデータから学習します。 これら2つのアプローチに加えて、研究者たちは中間表現によって接続された2つの異なる DNN を訓練するハイブリッドアプローチも探究しています。 この投稿は、モジュラーパイプラインアプローチに基づく機能について説明しています。 自動運転のレベル SAE インターナショナル(旧称:自動車技術者協会)の J3016 規格 は、運転自動化の6つのレベルを定義しており、運転自動化について最も引用される情報源です。これには、レベル0(自動化なし)からレベル5(完全な運転自動化)までが含まれており、以下の表に示されています。 Level Name Feature 0 運転自動化なし 人 1 運転支援 人 2 部分運転自動化 人 3 条件付運転自動化 システムが運転し、人がバックアップ 4 高度運転自動化 システム 5 完全運転自動化 システム モジュラーファンクション 以下のダイアグラムは、モジュラーファンクションデザインの概要を提供します。 自動運転システム(ADシステム)は、自動化の高いレベル(レベル2以上)で複数の機能を実行します: データ収集 – 自動運転車(AV)システムは、リアルタイムでセンチメートル精度の周囲の情報を収集します。車両は様々なデバイスを装備しており、これらのデバイスの機能は様々で重なる部分もあります。AV は進化し続けている分野で、センサーやデバイスの種類についての合意や標準化はありません。ここに挙げたデバイスに加えて、車両はナビゲーションのための GPS や、直線および角速度の測定のための慣性計測ユニット(IMU)を使用することもあります。ADAS システムのタイプによって、以下のデバイスの組み合わせが見られます: カメラ – 人間の知覚に概念的に似ている視覚デバイス。高解像度に対応していますが、深度推定や極端な天候条件の処理が苦手です。 LiDAR – 周囲の情報を 3D ポイントクラウドとして提供する高価なデバイス。正確な深度と速度の推定が可能です。 超音波 – 小さくて安価なセンサーですが、短距離でのみ効果的に機能します。 レーダー – 長距離と短距離の両方に対応し、低視認性や極端な天候条件でもよく機能します。 データフュージョン – AV システムの一部である複数のデバイスが信号を提供しますが、限界があります。しかし、デバイス間の信号は補完的な情報を提供します。AV システムは、統合されたデバイスからのデータを融合し、包括的な認識を構築します。この統合されたデータセットは、DNN のトレーニングに使用されます。 認識 – AV システムは、デバイスから収集した生データを分析して、車両周辺の環境についての情報を構築します。これには障害物、交通標識、その他のオブジェクトが含まれます。これを道路シーン認識、あるいは単に認識と呼びます。これには、近くの車両、歩行者、交通信号、交通標識としてオブジェクトを検出し分類することが含まれます。この機能は深度を測定し、車線検出、車線の曲率推定、縁石検出、遮蔽を行います。この情報は経路計画とルート最適化に不可欠です。 ローカリゼーションとマッピング – AV システムが安全に運転するために、検出された物体の位置を理解する必要があることを説明しています。AV システムは 3D マップを作成し、自車(ego vehicle)とその周囲の位置をマップ上で更新します。また、検出された物体とその現在位置を追跡します。進んだシステムは、動いている物体の運動学を予測します。 予測 – 他のモジュールから集められた情報を基に、AV システムは環境の直近の未来の変化を予測します。車両上で実行される DNN は、運動状態(位置、速度、加速度、ジャーク)を時間経過で投影することにより、自車と周囲の物体の相互作用の位置を予測します。これにより、潜在的な交通違反や衝突、または危険な接近を予測することができます。 パスプランニング&nbsp; – この機能は、認識、位置特定、予測からの入力に基づいて、車両が次に取りうるルートを描く責任があります。最適なルートを計画するために、AV システムは、位置特定、地図、GPS データ、予測を入力として取ります。一部の AV システムは、固定ルート上にエゴ車両と他のオブジェクトの運動学を投影して鳥瞰図を構築し、3D マップを提供します。また、他の車両からのデータも融合します。全体として、計画機能は、ドライバーの快適さを最大化することを目的として、可能なルートから最適なルートを見つけます(例えば、スムーズな曲がり角 vs. 急な曲がり角、ゆっくりと減速する vs. 一時停止標識で急に停止する)。 制御と実行 – ルートプランナーからの入力を受け取り、加速、減速、停止、ステアリングホイールの回転などの動作を行います。コントローラーの目的は計画された軌道を維持することです。 トレーニングパイプライン&nbsp; – 車両に予測を提供する DNN は訓練される必要があります。通常、車両から収集されたデータを使用してオフラインで訓練されます。訓練には、長期間にわたって数千の計算ユニットが必要です。訓練に必要なデータ量と必要な計算能力は、モデルのアーキテクチャと AV システムプロバイダーによって異なります。DNN を訓練するために、AV システムプロバイダーは、部分的には人間によって注釈され、部分的には自動化されたラベル付きデータが必要です。通常、ナンバープレートの番号や顔などの個人識別情報(PII)は、ぼかしによって匿名化されます。多くのプロバイダーは、シミュレーションを使用してラベル付きデータを増強します。これにより、特定のシナリオのデータを生成し、実世界のデータを増強する能力が提供されます。AV システムプロバイダーはまた、トレーニング、微調整、エッジケースの処理に関連するデータを掘り出すためのツールを使用します。訓練されたモデルは、オフラインシミュレーションで精度を検証されます。一部のプロバイダーは、休眠モデル戦略を使用し、候補モデル(休眠)を本番モデルと並行して展開します。休眠モデルからの予測は車両の制御には使用されませんが、プロバイダーは実際のシナリオでモデルの精度を検証するのに役立ちます。 課題 AV 用の DNN は膨大なデータ量でトレーニングする必要があり、DNN をトレーニングし、大量のトレーニングデータを扱い、モデルとデータ並列性を最適化する要因を考慮するために、スケーラブルな計算インフラが必要です。 大量のデータでのトレーニング 大量のデータを使ったトレーニングでは、AV システムは車両に取り付けられたデバイスから大量のデータを収集します。AV システムプロバイダーによっては、車両のフリートが数台から数千台に及びます。AV システムプロバイダーが直面する典型的な課題には以下のようなものがあります: ・ ペタバイトのデータの収集、前処理、および保存 – 各車両は8時間の運転で40TB以上のデータを収集します。 ・ 膨大なデータ量から関連する代表データを識別する – これは、一般的なシナリオ(障害物がある正常速度での運転など)でクラスの不均衡を生じさせないようにするために重要です。より高い精度を得るためには、DNN は多様で良質なデータの大量のデータが必要です。 ・ コーナーケースのボリューム – ML モデルは幅広いコーナーケースを処理する必要があります。これは AV システムの安全性を確保するために不可欠です。 ・ トレーニング時間 – 膨大なデータ量を考えると、トレーニング時間はしばしば複数日または数週間に及びます。これにより開発速度が低下し、迅速に失敗する能力が低下します。 大規模なデータ処理の課題に対処するために、 Amazon SageMaker の分散データ並列処理機能(SMDDP)を利用できます。SageMaker はフルマネージドな機械学習(ML)サービスです。データ並列処理では、大量のデータがバッチに分割されます。データブロックが複数の CPU や GPU(ノードと呼ばれる)に送信され、結果が組み合わされます。各ノードには DNN のコピーがあります。SageMaker は 分散データ並列ライブラリ を開発し、ノードごとにデータを分割し、ノード間の通信を最適化します。SageMaker Python SDK を使用して、トレーニングスクリプトに最小限の変更を加えることで、データ並列処理のジョブをトリガーできます。データ並列処理は、人気のあるディープラーニングフレームワーク PyTorch、PyTorch Lightening、TensorFlow、Hugging Face Transformers をサポートしています。 現代自動車は SageMaker のデータ並列処理を利用して自動運転モデルのトレーニング時間を短縮し、8つのインスタンスで 90% 以上のスケーリング効率を実現しました。各インスタンスには 8 つの GPU があります。次の図はこのアーキテクチャを示しています。 詳細については、 Hyundai が Amazon SageMaker を使用して自動運転モデルの ML モデルの訓練時間を短縮する方法 を参照してください。 SageMaker での分散訓練に関する詳細は、AWS re:Invent 2020 のビデオ「 Amazon SageMaker における DataParallel を使用した高速訓練とほぼ線形スケーリング 」と「 Amazon SageMaker の分散訓練エンジンの背後にある科学 」を参照してください。 大量データのラベル付け トレーニングパイプラインは、大量のラベル付きデータセットを必要とします。お客様が直面する一般的な課題の1つは、画像、ビデオ、センサー(例えば、3D ポイントクラウド)のアノテーションツールの開発、オブジェクト検出のためのカスタムワークフロー、およびセマンティックセグメンテーションタスクです。あなたは、ワークフローをカスタマイズする能力が必要です。 Amazon SageMaker Ground Truth は、カスタムワークフローを構築および管理する柔軟性を提供する完全に管理されたデータラベル付けサービスです。Ground Truth を使用すると、画像、ビデオ、ポイントクラウドデータのオブジェクト検出、オブジェクト追跡、セマンティックセグメンテーションタスクのラベルを付けることができます。車両から収集されたデータを AWS Storage Gateway 、 AWS Direct Connect 、 AWS DataSync 、 AWS Snowball 、または AWS Transfer Family などのデータ転送メカニズムを使用して、プレミスから AWS に転送できます。データが前処理された後(例えば、顔やナンバープレートのぼかし)、クリーンアップされたデータセットはラベル付けの準備が整います。Ground Truth は、カメラからのビデオ入力と LiDAR データのセンサーフュージョンをサポートします。 Amazon Mechanical Turk 、信頼できるサードパーティベンダー、または独自のプライベートワークフォースを通じて、人間のアノテーターを使用することを選択できます。 以下の図では、 AWS Batch を使用してデータを前処理し、Ground Truth を使用してデータセットにラベルを付けるためのリファレンスアーキテクチャを提供しています。 さらに詳しい情報については、 Field Notes: Automating Data Ingestion and Labeling for Autonomous Vehicle Development および Amazon SageMaker Ground Truth での 3D オブジェクトトラッキングとセンサーフュージョンのためのデータ ラベリング に関する記事を参照してください。 Ground Truth を使用して 3D ポイントクラウドデータをラベル付けする方法についての詳細は、 Use Ground Truth to Label 3D Point Clouds を参照してください。 トレーニングの為のインフラストラクチャ 自動運転 (AV) システムが成熟するにつれて、DNN は多数のエッジケース(例えば、高速道路を歩く人々など)に対処するために訓練される必要があります。これにより、モデルは複雑で大きくなります。これは、記録されたデータのマイニングやシミュレーションを通じて、新しいシナリオに対応するためにより多くのデータで DNN を訓練することを意味します。これは、より多くのコンピューティング能力とコンピューティングインフラのスケーリングを要求します。 ML ワークロードの計算ニーズをサポートするために、SageMaker はトレーニング用の複数のインスタンスタイプを提供します。各ファミリーは特定のワークロードのために設計されており、インスタンスの vCPU、GPU、メモリ、ストレージ、およびネットワーキング構成に基づいて選択できます。完全なエンドツーエンドの AV 開発のために、企業は主に m、c、g、および p ファミリーに依存しています。 一部の顧客は、Deep Learning AMI (DLAMI) を使用して、p ファミリーの NVIDIA GPU ベースの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動します。各 EC2 p ファミリーインスタンス世代は、最新の NVIDIA 技術(p2 インスタンス(Tesla K80)、p3 インスタンス(Volta V100)、および p4d インスタンス(Ampere A100)を含む)を統合しています。 以下の図は、利用可能なインスタンスを要約しています: DNN(Deep Neural Network)が複雑で一つの GPU のメモリに収まらない場合、SageMaker の モデル並列ライブラリ を使用できます。これは、レイヤーを GPU やインスタンス間で分割します。このライブラリを使って、TensorFlow や PyTorch モデルを複数の GPU やノードにわたって自動的に分割し、コードの変更を最小限に抑えることができます。 MLOps 実運用に関しては、データ サイエンティストが改訂されたモデルで実験を行うことから、数千台の車両へのデプロイまで、AV システム プロバイダーは様々なニーズに対応するための、エンドツーエンドでシームレスに動作するツールセットが必要です。 大規模なデータ収集と変換 モデルの自動分析と評価 データパイプラインの標準化 データ サイエンティストのための実験定義と実施 モデルパフォーマンスの監視 エンドツーエンドの自動化による繰り返しプロセスの確立と人間介入の排除 自動化されたモデルデプロイメントで、訓練済みモデルを数百万台の車両に迅速にデプロイできる SageMaker は包括的な MLOps ツールを提供します。データ サイエンティストは、 Amazon SageMaker Experiments を使用して、試行として反復の入力、パラメータ、設定、結果を自動的に追跡できます。これらの試行を実験に割り当て、グループ化し、整理することもできます。 Amazon SageMaker Model Monitor は、リアルタイムで ML モデルの品質を継続的に監視するのに役立ちます。モデル品質の逸脱、例えばデータドリフトや異常がある場合に通知する自動アラートを設定できます。オーケストレーションに関しては、 SageMaker Pipelines SDK 、 AWS Step Functions 、 Amazon Managed Apache Airflow (Amazon MWAA)、Kubeflow などのオープンソースツールを含む多くのオプションから選択できます。 結論 この投稿 で、私たちは ADAS の構築アプローチと異なる機能ユニット、モジュラーパイプラインを構築するための統一フレームワーク、そして ADAS システムを構築する際の課題について説明しました。私たちは、リファレンスアーキテクチャと、お客様が SageMaker や他の AWS サービスを使用してスケーラブルな AV システムを構築する方法を説明するケーススタディやブログ投稿へのリンクを提供しました。提案されたソリューションは、お客様がスケーラブルな AV システムを構築する際の課題に対処するのに役立ちます。後の投稿 で、私たちは ADAS システムによって使用される DNN について徹底的に掘り下げる予定です。 このブログはシニアソリューションアーキテクトの渡邊翼が翻訳を担当しました。 About the Authors Shreyas Subramanian &nbsp;は、プリンシパル AI/ML スペシャリスト ソリューション アーキテクトとして、AWS プラットフォームを使用して、顧客がビジネス上の課題を機械学習で解決するのを支援しています。シュレヤスは、大規模最適化と機械学習のバックグラウンドを持ち、最適化タスクの加速のために機械学習と強化学習を使用しています。 Gopi Krishnamurthy は、ニューヨーク市に拠点を置くアマゾン ウェブ サービスのシニア AI/ML ソリューション アーキテクトです。彼は、大手自動車企業の顧客と協力し、彼らの機械学習ワークロードを変革し、クラウドへの移行を支援しています。彼の主な関心事は、ディープラーニングとサーバレス技術です。仕事の外では、家族と過ごすことと、幅広い音楽を探求することを楽しんでいます。 <!-- '"` -->
アマゾンウェブサービス (AWS) では、 AWS のセキュリティベストプラクティス に記載されているように、可能な限りアクセスキーなどの長期的な認証情報を作成する代わりに、一時的な認証情報を使用することを推奨しています。 一時的なセキュリティ証明書(短期認証情報とも呼ばれます)は、有効期限が限られており、定期的なローテーションや取り消しが不要なため、認証情報が誤って公開された場合の影響を抑えることができます。一時的なセキュリティ認証情報の有効期限が切れると、AWS はその認証情報を使用して行われた認証および認可リクエストを承認しなくなります。 VMware Cloud on AWS を使用すると、お客様はワークロードとアプリケーションをオンプレミスの vSphere 環境から Software-Defined Data Center (SDDC) に簡単に移行でき、シームレスなハイブリッドクラウド体験を実現できます。 VMware Cloud on AWS とネイティブ AWS サービスとの統合は強力な機能であり、お客様は 200 を超える AWS サービスにまたがるアプリケーションの移行とモダナイゼーションに活用できます。 本稿では、 AWS Identity and Access Management (IAM) Roles Anywhere が、VMware Cloud on AWS で実行されているワークロードと AWS サービスとの統合のセキュリティをどのように強化できるかを見ていきます。 VMware Cloud on AWS で実行されているワークロードが AWS サービスにアクセスする必要がある一般的なユースケースと、認証情報の管理に IAM Roles Anywhere を使用する利点について説明します。 最後に、VMware Cloud on AWS で実行されているワークロードに IAM Roles Anywhere を設定する方法を示すシナリオ例を紹介します。 VMware は AWS スペシャライゼーションパートナー であり、エンタープライズソフトウェアのリーディングイノベーターです。 移行を簡素化するために共同設計された VMware Cloud on AWS は、コンピューティング、ネットワーク、ストレージの機能を統合し、お客様がオンプレミス環境とクラウド環境全体で VMware のツール、スキルセット、ガバナンスを活用できます。 AWS IAM Roles Anywhere の概要 AWS Identity and Access Management (IAM) Roles Anywhere は、IAM ロールを使用して AWS のサービスや、AWS 以外のアプリケーションやサービス内のリソースにアクセスできるようにする機能です。 IAM Roles Anywhere の 紹介記事 では、AWS のサービスにアクセスするために、サードパーティのアプリケーションやサービスごとに長期認証情報を作成および管理する必要がないことについて説明しています。代わりに、AWS 外で実行されるサーバー、コンテナ、アプリケーションなどのワークロードのために、AWS アプリケーションで使用するのと同じ IAM ポリシー と IAM ロール を使用して、 IAM の一時的なセキュリティ認証情報 を取得できます。 一般的なユースケース VMware Cloud on AWS の仮想マシン (VM) で AWS サービスにアクセスするための認証情報が必要な場合は、IAM Roles Anywhere を使用できます。 以下に一般的なユースケースをいくつか示します。 段階的な移行の過程で、ハイブリッドワークロードが AWS サービスにアクセスする VMware Cloud on AWS のワークロードから、 AWS Secrets Manager に保存されているシークレットにアクセスする VMware Cloud on AWS の VM のデータを Amazon Simple Storage Service (Amazon S3) にバックアップする VMware Cloud on AWS の VM 上のクライアント/エージェントが、 Amazon RDS 、 Amazon DynamoDB 、 DocumentDB などのバックエンドデータベースに安全にアクセスすること VMware Cloud on AWS ワークロードのための IAM Roles Anywhere VMware Cloud on AWS ワークロードに IAM Roles Anywhere を活用することの主な利点は次のとおりです。 集中アクセス管理機能 を提供する AWS IAM サービスにより、IAM ロール、ポリシー、パーミッションを活用することで VMware Cloud on AWS のワークロードから AWS サービスへのアクセスを一貫性のあるスケーラブルな方法で制御および管理できます。 VMware Cloud on AWS 上のワークロード内で直接使用されている IAM ユーザーのアクセスキー といった 長期間有効なアクセス認証情報を配布して埋め込む必要性を最小限に抑えます 。代わりに、VM/サーバーが一時的に IAM ロールを引き受けることができるため、機密性の高い資格情報の露出を最小限に抑え、全体的なセキュリティを向上させます。 特定の権限を持つカスタム IAM ロールを作成して VM に割り当てることで、VM に きめ細かい権限 を定義できます。このきめ細かな制御により、各 VM/サーバーに必要な権限のみが付与され、最小権限の原則に沿うことが保証されます。 動的で柔軟なアクセス が可能になり、アクセス管理が簡素化されるため、VM/サーバー自体に直接変更を加えることなく、要件の変化や人員の変更に迅速に対応できます。 IAM Access Analyzer や AWS CloudTrail などの AWS サービスを通じてアクセスイベント、権限、変更を追跡および監視することで、 監査とコンプライアンス要件に対応するデータを強化 できます。 ソリューション概要 IAM Roles Anywhere を使用するには、一時的なセキュリティ証明書発行プロセスのために 認証局 (CA) が発行した X.509 証明書をワークロードで使用する必要があります。公開鍵基盤 (PKI) と IAM Roles Anywhere の間の信頼を確立するためのトラストアンカーとして CA を IAM Roles Anywhere に登録します。 図 1 のアーキテクチャは、VMware Cloud on AWS の VM で実行されているアプリケーションが、プライベート CA が発行した X.509 証明書を使用して IAM Roles Anywhere に一時的な AWS 認証情報をリクエストし、認証プロセスを完了する権限を持つ IAM ロールを引き継ぐ様子を示しています。 図 1 — アプリケーションの証明書ベースの認証 各コンポーネントがソリューションにどのように貢献しているかを調べてみましょう。 VMware Cloud on AWS の VM 上で実行されているアプリケーションは、IAM Roles Anywhere に認証リクエストを行い、パブリックキー (証明書にエンコード) と対応するプライベートキーで署名された署名を送信します。 アプリケーションでは、リクエストで引き受けるロールも指定します。 リクエストを受信すると、IAM Roles Anywhere は、まずパブリックキーで署名を検証し、次にその証明書がアカウントに設定されたトラストアンカーによって発行されたものであることを検証します。 詳細については、 署名検証ドキュメント を参照してください。 両方の検証が成功すると、アプリケーションが認証され、IAM Roles Anywhere は AWS Security Token Service (AWS STS) を呼び出して、リクエストで指定されたロールの新しいロールセッションを作成します。 アプリケーションは受け取った一時的なセキュリティ認証情報を使用して AWS サービスに接続します。 シナリオ例とウォークスルー 前提条件 IAM Roles Anywhere をセットアップする前に、以下の要件を満たす必要があります。 独自の CA の証明書バンドル、または IAM Roles Anywhere と同じ AWS リージョンにあるアクティブな AWS Certificate Manager AWS プライベート CA (ACM プライベート CA) の証明書バンドル VMware Cloud on AWS の仮想マシンから IAM Roles Anywhere やその他の AWS サービスへの API 呼び出しを実行するためのネットワーク接続。VMware Cloud on AWS のさまざまなネットワークアーキテクチャパターンを示す VMware Cloud on AWS リファレンスアーキテクチャ を参照できます。 IAM ロールと IAM Roles Anywhere の管理者権限 IAM Roles Anywhere のセットアップ VMware Cloud on AWS で実行されているワークロードから IAM Roles Anywhere を使用して AWS への認証を行うには、IAM Roles Anywhere コンソールを使用してトラストアンカーとプロファイルを作成する必要があります。 手順については、 AWS IAM Roles Anywhere の トラストアンカーとプロファイルの作成 に関するドキュメントを参照してください。 VMware Cloud on AWS 上の VM での設定 まず、エンドエンティティ証明書と関連するプライベートキーが VMware Cloud on AWS の VM でローカルに利用可能であることを確認します。 ACM プライベート CA コンソールから証明書をダウンロードした場合は、 openssl ユーティリティを使用して以下のコマンドを実行し、証明書ファイルを.txt から PEM 形式に変換できます。 openssl rsa -in &lt;private_key.txt&gt; -out &lt;private_key.pem&gt; -outform PEM; openssl x509 -in &lt;certificate.txt&gt; -out &lt;certificate.pem&gt; -outform PEM; IAM Roles Anywhere は、現在の AWS SDK がサポートしている プロセス認証情報 機能と併用できる認証情報ヘルパーツールが用意されています。これにより、アプリケーションの署名プロセスが簡単になります。 認証情報ヘルパーツールの入手方法については、 IAM Roles Anywhere のドキュメント を参照してください。 機能をテストするには、VMware Cloud on AWS の VM で認証情報ヘルパーツール ( aws_signing_helper ) を手動で実行します。次のコマンドを使用します。 ./aws_signing_helper credential-process \ --certificate /path/to/certificate \ --private-key /path/to/private-key \ --trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID \ --profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID \ --role-arn arn:aws:iam::account:role/role-name-with-path IAM Roles Anywhere からセッション認証情報が正常に受信されるはずです。セットアップが機能することを確認したら、 ~/.aws/config ファイルを更新または作成し、署名ヘルパーを credential_process として追加することができます。これにより、VMware Cloud on AWS の VM に無人アクセスが可能になります。 AWS コマンドラインインターフェイス (CLI) 設定ファイルの詳細については、 設定ファイルと認証情報ファイルの設定 を参照してください。 [user@server .aws]# cat config [default] output = json region = us-east-1 credential_process = ./aws_signing_helper credential-process —certificate /path/to/certificate.pem —private-key /path/to/private_key.pem —trust-anchor-arn arn:aws:rolesanywhere:&lt;region&gt;:&lt;account_id&gt;:trust-anchor/&lt;id&gt; —profile-arn arn:aws:rolesanywhere:&lt;region&gt;:&lt;account_id&gt;:profile/&lt;id&gt; —role-arn arn:aws:iam::&lt;account_id&gt;:role/&lt;role_name&gt; 設定が期待どおりに機能することを確認するには、 aws sts get-caller-identity CLI コマンドを実行し、引き受けたロールが IAM Roles Anywhere で設定したものであることを確認します。 また、ロールセッション名には、認証に使用された証明書のシリアル番号が含まれていることも確認してください。 AWS IAM Roles Anywhere のモニタリング AWS には、IAM Roles Anywhere を監視したり、問題が発生した場合に報告したり、イベントに対して自動的にアクションを実行したりできるさまざまな監視ツールが用意されています。 詳細については、 IAM Roles Anywhere のモニタリング を参照してください。 コストに関する考慮事項 IAM Roles Anywhere は、 サポートされているリージョン で追加料金なしで利用できます。IAM Roles Anywhere との信頼を確立するために ACM プライベート CA を使用した場合は、 ACM プライベート CA の標準料金 が適用されます。 その他の考慮事項 IAM Roles Anywhere のトラストアンカーを無効にして、VMware Cloud on AWS の仮想マシンへの新しいセッションの発行を直ちに停止することも、特定の時点より前に発行されたロールの認証情報に対する すべての権限を直ちに取り消す こともできます。 証明書の取り消しは、インポートされた証明書失効リスト (CRL) を使用することでサポートされます。 CA から生成された CRL をアップロードすると、認証に使用された証明書の失効ステータスがチェックされます。 IAM Roles Anywhere は CRL 配布ポイント (CDP) またはオンライン証明書ステータスプロトコル (OCSP) エンドポイントへのコールバックをサポートしていません。 もう 1 つのポイントは、プライベートキーが適切なファイルシステム権限で VM に安全に保存されていることを確認することです。 クリーンアップ リソースをクリーンアップするには以下のステップを実行してください。 前のステップで作成した トラストアンカー と プロファイル を削除します。 前のステップで作成した IAM Roles Anywhere サービスプリンシパルを信頼する IAM ロールを削除 します。 VMware Cloud on AWS の VM 上の ~/.aws/config ファイルを更新し、前のステップの一部として設定した credential_process としての署名ヘルパーを削除します。 仮想マシンのローカルに保存されているエンドエンティティ証明書と関連する秘密鍵を削除します。 前提条件の一部として作成された場合、 プライベート CA を削除します。 まとめ 本稿では、IAM Roles Anywhere サービスによって、長期認証情報を配布および埋め込む必要がなくなることで、VMware Cloud on AWS で実行されているワークロードが AWS API と安全にやり取りできるようにする方法について説明しました。 また、VMware Cloud on AWS で実行されているワークロードに IAM Roles Anywhere を使用する一般的なユースケースと、VMware Cloud on AWS の仮想マシンでの関連するセットアッププロセスについても説明しました。 翻訳は Partner SA 豊田が担当しました。原文は こちら です。
PGA ツアーはリアルタイムのデータを活用してゴルフの観戦体験をさらに向上させ、ファンがゲームをより身近に感じられるようにしています。さらに豊かな体験を提供するために、グリーン上のボール位置を自動的に追跡する次世代ボール位置トラッキングシステムの開発を進めています。 PGA ツアーは現在、すべてのショットの開始位置と停止位置を正確に追跡するために、複雑なカメラシステムとオンサイトコンピューティングを利用した最高のスコアリングシステムである CDW 社提供の ShotLink を使用しています。PGA ツアーは、次世代のクラウドベースのパイプラインを開発し、パッティンググリーン上のゴルフボールを特定するために、コンピュータビジョンと機械学習の技術を探求したいと考えていました。 Amazon Generative AI Innovation Center (GAIIC) は、最近の PGA ツアーのイベントで得たサンプルデータセットを用いて、これらの技術の有効性を実証しました。GAIIC は、プレーヤーをカメラの視野内で正確に特定し、パッティングをしているプレーヤーを判断し、カップに向かって動くボールを追跡する、複数の畳み込みニューラルネットワーク (CNN) を連結し、一連のモジュラーパイプラインを設計しました。 この投稿では、このパイプラインの開発、RAW データ、パイプラインを構成する畳み込みニューラルネットワークの設計、およびそのパフォーマンスの評価について説明します。 データ PGA ツアーは 1 ホールのグリーン周辺に設置された 3 台の 4K カメラから撮影された 3 日間のビデオを GAIIC に提供しました。以下の図は、一つのカメラからのフレームをクロップしてズームし、パッティングするプレーヤーがはっきりと見えるようにしたものです。カメラの解像度は高いにも関わらず、グリーンから距離があるため、ボールは小さく見えます(通常 3×3、4×4、または 5×5 ピクセル)。このサイズのターゲットを正確に特定することは難しい場合があります。 カメラの映像に加えて、PGA ツアー は各ショットのスコアリングもアノテーションデータとして GAIIC に提供しました。これには、ボールの着弾位置のタイムスタンプが含まれています。これにより、グリーン上における全てのパットを視覚化するだけでなく、パターを打っている全てのプレーヤーのビデオクリップを抽出することができ、それを手動でラベル付けすることで、パイプラインを構成する検出モデルの訓練データとして活用することができます。次の図は、上から時計回りに 3 つのカメラビューとおおよそのパット経路のオーバーレイを示しています。ピンポジションは毎日移動させられ、1 日目は青、2 日目は赤、3 日目はオレンジに対応しています。 パイプラインの概要 全体のシステムは、トレーニングパイプラインと推論パイプラインの両方で構成されています。次の図は、トレーニングパイプラインのアーキテクチャを示しています。まず、 Amazon Kinesis のようなストリーミングモジュールから取得したライブビデオ、または Amazon Simple Storage Service (Amazon S3) に直接配置した過去のビデオのいずれかからビデオデータを取り込みます。トレーニングパイプラインでは、ビデオの前処理および Amazon SageMaker Ground Truth を使用した画像の手動ラベル付けが必要です。モデルは Amazon SageMaker でトレーニングでき、その成果物は Amazon S3 に保存できます。 推論パイプラインは、次の図に示すように、ビデオの RAW データから順次情報を抽出し、最終的にボールの緯度経度を予測するいくつかのモジュールで構成されています。 最初に、各カメラが捉えた広い視野からグリーンが切り取られ、プレーヤーやボールを検出するモデルが対象とする領域を減らします。次に、 3 つの畳み込みニューラルネットワーク (CNN) を使用します。1番目の CNN は、視野内に存在する人物位置を検出します。2 番目の CNN では、どのタイプの人物を検出したかを予測し、パットを試みる人物が存在するを判断します。可能性が高い人物が検出されたら、同じCNNを使用してパター付近のボール位置を予測します。3 番目の CNN はボールの動きを追跡し、最後にカメラのピクセル位置から GPS 座標への変換関数が適用されます。 プレーヤー検出 CNN を用いて一定間隔で 4K フレーム全体にわたってボールを検出する方法は可能ですが、カメラの距離から見たボールの小さなサイズを考慮すると、どんな小さな白い物体でも誤って検出してしまい、誤報が多くなる恐れがあります。画像全体でボールを探すのを避けるためには、プレーヤーの姿勢とボールの位置の相関関係を利用することが有効です。パットする際にはボールがプレーヤーの近くにあるため、視野内でプレーヤーを特定することで、ボールを探す必要のあるピクセル領域の範囲を大きく絞り込むことができます。 下図に示すように、あらかじめ訓練された CNN を使って、視野内に映るすべての人物のバウンディングボックスを予測することができました。ただ残念ながらグリーン上には複数のボールがあることが多いので、単にすべての人物を検出してボールを検索するだけではなく、さらなるロジックが必要となります。このため、現在パッティングをしているプレーヤーを検出するための別の CNN が必要です。 プレーヤーの分類とボール検出 グリーン上のボールのありかをさらに絞り込むために、事前学習済みの物体検出 CNN (YOLO v7) をファインチューニングして、グリーン上のすべての人物を分類しました。このプロセスの重要なコンポーネントは、SageMaker Ground Truth を使用して一連の画像に手動でラベルを付けることでした。これらのラベルにより、CNN はパッティングをしているプレーヤーを高い精度で分類できるようになりました。ラベリングプロセスでは、パッティングをしているプレーヤーとともにボールの位置も明確化されていたため、この CNN はボール検出も行うことができ、パット前のボールの初期位置にバウンディングボックスを描画し、その位置情報を後段のボール追跡 CNN に送ることができるようになりました。 画像内のオブジェクトには 4 つの異なるラベルを使用してアノテーションを付けています: player-putting – クラブを持ち、パッティングの体勢にあるプレーヤー player-not-putting – パッティングの体勢にないプレーヤー(クラブを持っている可能性もあります) other-person – プレーヤーではないその他の人物 golf-ball – ゴルフボール 以下の図は、SageMaker Ground Truth のラベルを使用してファインチューニングされた CNN が、視野内の各人物を分類していることを示しています。この分類は、選手・キャディー・ファンといった外見が広範囲に及ぶため、判断は難しくなります。そのため、プレーヤーがパッティングに分類された後、ボール検出用にファインチューニングした CNN がそのプレーヤー近くの小さなエリアに適用されます。 ボール経路の追跡 3 つ目の CNNとなる、モーショントラッキング用に事前学習済みの ResNet アーキテクチャは、パット後のボールを追跡するために使用されました。 モーショントラッキングは徹底的に研究された問題だったこともあり、このネットワークを追加のファインチューニングなしでパイプラインに統合してもうまく機能しました。 パイプライン出力 これら一連の CNN は、人物の周りにバウンディングボックスを置き、グリーン上の人物を分類し、初期のボール位置を検出し、ボールが動き始めたらボールを追跡します。以下の図は、パイプラインのラベル付きビデオ出力を示しています。 ボールが動くにつれて、そのピクセル位置が追跡され記録されます。 グリーン上の人物が追跡されバウンディングボックスで囲まれていることに注目してください。下のパット中プレーヤーは「Player Putting」と正しくラベル付けされ、動くボールは小さな青いバウンディングボックスで追跡されています。 パフォーマンス パイプラインのコンポーネントのパフォーマンスを評価するには、ラベル付けされたデータが必要です。ボールの正確な緯度経度は提供されていましたが、ボールの最終的なピクセル位置やプレイヤーのパッティング位置など教師データ (Ground Truth) となる中間点についてのデータはありませんでした。私たちが実施したラベリングにより、これらのパイプラインの中間出力の教師データを開発し、パフォーマンスを測定できるようになりました。 プレイヤーの分類とボール検出の精度 パッティングをしているプレイヤーとボールの初期位置の検出のために、データセットをラベル付けし、前述のように YOLO v7 CNN モデルをファインチューニングしました。 モデルは次の図に示すように、前の人物検出モジュールの出力を以下の 4 つのクラスに分類しました: player-putting : パッティングしているプレイヤー player-not-putting : パッティングしていないプレイヤー other-person : その他の人物 golf-ball : ゴルフボール このモジュールのパフォーマンスは、混同行列で評価されています。対角線上の値は、予測されたクラスが教師データの実際のクラスと一致した頻度を示しています。このモデルは、各人物で 89% 以上の再現率を達成しており、ゴルフボールでは 79% の再現率となっています(これは、モデルがゴルフボールの例ではなく人物の例で事前学習されているため、トレーニングセットにより多くのラベル付きゴルフボールが含まれていれば改善できると予想されます)。 次のステップは、ボールトラッカーを起動することです。 ボール検出の出力結果は、ボールが検出されているかどうかの確信度を表す数値であるため、そのしきい値を設定し、それが結果にどのように影響するかを観察することができます。以下の図に要約を記載しています。しきい値が高いほど誤検知は少なくなりますが、確信度の低いボールの例も見逃してしまうため、この方法にはトレードオフがあります。20% および 50% の確信度のしきい値を試したところ、ボール検出率はそれぞれ 78% および 61% でした。この指標では、20% のしきい値が優れています。 トレードオフは、20% の信頼度しきい値では、検出全体の 80% が実際にボールを示していました (20% が誤検知) が、50% の信頼度しきい値では 90% がボールを捉えていました (10% が誤検知)。誤検知を少なくするには、50% のしきい値の方が優れています。 これらの指標は、より大規模なトレーニングセットに対してより多くのラベル付きデータを用いることで改善できるはずです。 検出パイプラインのスループットは 1 秒あたり 10 フレーム程度なので、現時点では 50 フレーム/秒の入力に対して連続かつ高速に実行するのには単一インスタンスでは十分ではありません。ボールが打たれてから 7 秒以内に出力を得るには、レイテンシの最適化がさらに必要で、パイプラインの複数バージョンを並列に実行し、量子化による CNN モデルの圧縮などが考えられます。 ボール軌道追跡の精度 事前学習済みの MMTracking の CNN モデルはうまく機能しますが、興味深い失敗例があります。次の図では、トラッカーは最初ボールを捉えるものの、ボールとパターヘッドの両方を含むようにバウンディングボックスを拡大したのち、パターヘッドの方だけを追跡し、ボールを捉えきれないケースを示しています。この場合、パターヘッドが白く見える(おそらく鏡面反射のため)ので、混同してしまうのは理解できます。この問題については追跡用のラベル付きデータと追跡 CNN のファインチューニングにより今後改善する見込みがあります。 結論 本投稿では、カメラの視野内のプレイヤーを検出し、パッティングしているプレイヤーを特定し、カップに向かっていくボールを追跡するモジュール式パイプラインの開発について説明しました。 PGA ツアーと AWS とのコラボレーションの詳細については、 PGA TOUR tees up with AWS to reimagine the fan experience (PGA ツアーが AWS と組んでファン体験を刷新) を参照してください。 著者 James Golden は、機械学習と神経科学のバックグラウンドを持つAmazon Bedrockの Applied Scientist です。 Henry Wang は Amazon Generative AI Innovation Center の Applied Scientist で、AWS の顧客向けに生成 AI ソリューションを研究・構築しています。スポーツとメディア&エンターテインメント業界にフォーカスしており、過去に様々なスポーツリーグ、チーム、放送局と仕事をしてきました。趣味はテニスとゴルフです。 Tryambak Gangopadhyay は AWS Generative AI Innovation Center の Applied Scientist で、さまざまな業界の組織と共同研究を行っています。役割は、重要なビジネス上の課題に対処し、AIの導入を加速するための研究を実施し、生成 AI ソリューションを開発することです。 翻訳はソリューションアーキテクト河角修が担当しました。原文は こちら です。
世界有数のバイオ医薬品メーカーであるファイザーは、機械学習 (ML)と人工知能 (AI) を用いて哺乳動物細胞培養用のバイオリアクター (医薬品製造に利用する細胞を培養する装置) をニアリアルタイムに監視し、バッチ収量を向上させると共に、不純物の混入リスクを低減しています。Amazon Web Service (AWS) を利用することで、同社は Manufacturing Intelligence Edge (MI Edge) と呼ぶ AI / ML プラットフォームを開発しました。これは、世界各地の製造拠点にあるバイオリアクターを継続的に監視するものです。従来、一日一回のサンプリングによる観測を行っていましたが、MI Edge では、内部状態を機械学習によってモデル化したことで、数秒毎のニアリアルタイムで状況を推測可能となりました。それにより、高い頻度でオペレータが適切なパラメータを調整できることとなった結果、収量が増加し、サイクルタイムが短縮し、不純物の混入リスクが低減したうえ、より早く、より多くの患者に医薬品を届けることが出来ています。この投稿では、初期の概念実証 (PoC) のために実装されたユースケース、サービス、アーキテクチャ、およびサンプルコードについて説明します。モデルの準備、推論関数の作成、ブリッジコンポーネントの作成、およびエッジへのコンポーネント導入、のステップが含まれます。 背景 最適な生産をするには、バイオリアクター内を理想的な環境として、細胞培養を促すことが肝要です。オペレータは、培地から物理的にサンプルを採取し、そのサンプルを分析することで細胞の成長を監視します。分析結果に基づいて、オペレータは栄養供給率などを調整し、細胞にとっての最適条件を維持します。サンプリングは必要な作業ですが、それによって望ましくない細胞がバイオリアクターに混入してバッチを汚染し、損失を引き起こすこともあります。このリスクを最小限に抑えるため、サンプリングは24時間毎に行われます。24時間を空けることはバッチの汚染機会を減少させる一方で、細胞培養の促進具合を観測するオペレータの能力も低下します。「測定間隔の短縮はリスク低減の鍵であり、閉ループプロセス制御においても不可欠です。」と、ファイザーのデジタル製造4.0シニアディレクターである Shawn Mullins 氏は述べています。「もちろん、これらは全ての FDA 関連ガイドラインに準拠し、安全な方法である必要があります。」 さらに、ファイザーの旧プラットフォームは、「スケーラビリティや横展開の容易さに欠け、予測分析や深層学習フレームワークが導入しづらかった。」と、ファイザーのグローバルテクノロジー&エンジニアリングディレクターである Reza Kamyar 氏は述べています。 モデルアーキテクチャ オペレータに対し、物理サンプリング間の状態を推測し、より高精度で調整できるツールを提供するために、ファイザーのグローバルテクノロジー&エンジニアリング (GTE) チームは、Physics-Informed Neural Network (PINN) を使用しました。この機械学習モデルは、生物学的プロセスの低いデータ可用性 (訳注 : 一般的に生物学では、支配する法則が未知であったり、必要なデータが不明であることが多い) を克服し、センサーデータとプロセスパラメータからバイオリアクター内の培養の常態を予測します。PINN モデルはバイオリアクター内の培養の常態を高精度で表現でき、かつオペレータが高い頻度で調整を加えることが可能です。 ML Edge の構成 ファイザーのデジタル MI チームと AWS は共同で、ファイザーのワークロードを製造工場で処理するためのハイブリッドで低遅延のコンテナプラットフォーム MI Edge を構築しました。AWS上で、アプリケーション、ダッシュボード、そして PINN モデルのようなワークロードが構築され、製造現場で稼働するハードウェアに導入されます。モデルのバージョン管理、デプロイパイプライン、セキュリティポリシー、ユーザーアクセス制御、およびアプリケーションログ管理の機能は、AWS 上にあります。 MI Edgeは、 AWS IoT Greengrass (デバイスソフトウェアの構築、デプロイ、管理のためのオープンソースとクラウドサービス) を含むAWSの産業用エッジサービス群を使用します。AWS IoT Greengrass は柔軟性が高く、Linux、Windows、Raspberry Pi OS 上で実行することができ、ARM と x86 プロセッサに対応しています。このランタイムは、予め構築された AWS IoT Greengrass component 内で、Docker コンテナ、ネイティブOSのプロセス、カスタムランタイムをローカルで起動できるほか、 AWS Lambda (多様なアプリケーションやバックエンドサービスのコードを実行できるサーバレスでイベント駆動型のコンピューティングサービス)上の機能を利用することができます。 MI Edge は、AWS IoT Greengrass のインスタンスを管理し、モデル、アプリケーション、ダッシュボードなどのワークロードを安全、かつ簡単にデプロイします。更にこのプラットフォームは、 AWS IoT Core を使用しています。このサービスはインフラの管理不要で、何十億もの IoT デバイスとの接続、何兆ものメッセージを AWS のサービス群にルーティングすることができます。 さらに MI Edge は、バイオリアクターのデータ処理に AWS IoT SiteWise を使用しています。このサービスは、大規模な産業機器からデータを収集・整理・分析する用途に設計されたものです。AWS IoT SiteWise は、このソリューションの主要な MVC (Model – View – Controller) インフラです。AWS IoT SiteWise は、以下の機能を提供します: データスキーマを設計し、スキーマをデータストリームに接続する OPC UA 統合を提供し、スキーマにデータをストリーミングする エッジやクラウドでダッシュボードを作成し、可視化する 受信データに応じたアラームとアクションを構成する 最終的に MI Edge は、機械学習モデルを構築・訓練・デプロイするサービスである Amazon SageMaker を使用しています。これはフルマネージドなインフラ、ツール、ワークフローを備えているため、あらゆるケースのモデルが構築可能です。具体的に MI Edge は、クラウド上の Amazon SageMaker、エッジデバイス向けに推論モデルを最適化する Amazon SageMaker Neo, 、及びエッジデバイスの推論エンジンである Amazon SageMaker Edge Manager を使用することで、エッジにおけるモデルの実行とメンテナンスを簡素化しています。 機械学習モデルの準備 AWS IoT Greengrass 上で PINN モデルを最適に実行する準備として、ファイザーは Amazon SageMaker Neo を用いてモデルを機械語にコンパイルしました。このサービスでは、特定のハード / ソフト / GPU / CPU の組合せ向けにコンパイルすることが可能です。これにより得られた機械学習モデルは、与えられたエッジデバイス上でも精度を維持し、最適なパフォーマンスで実行できます。 下記は、構築済みモデルを Nvidia Jetson Xavier NX プラットフォーム向けにコンパイルする Amazon SageMaker Jupyter notebookのPython コードスニペットの例です。得られたコンパイル済みモデルが NX プラットフォームで実行されるとき、モデルは NX GPU 内の「 CUDA 」コアを使用します。 機械学習モデルがコンパイルされると、AWS IoT Greengrass コンポーネントとしてパッケージ化され、デプロイの準備が完了します。 推論関数の準備 推論関数とは、下記のことを行うパッケージ化されたコードです。 データソースから入力値を取得し、準備する モデルのpredict() メソッドに入力値を渡して呼び出す モデルのpredict() 呼出し結果を取得する モデルの予測に基づいて振る舞う 下記は、推論の入力値が届くたびにトリガーされる、推論関数のメインループのスニペットです。このメインループは、Amazon SageMaker Edge Manager から gRPC を介して、コンパイル済み機械学習モデルの predict() メソッドを呼び出します。推論結果は確認のため、AWS IoT Core message queuing telemetry transport (MQTT) サービスにパブリッシュされます。 ブリッジコンポーネントの構築 PoC 要件の1つは、RESTful web API からのデータをAWS IoT SiteWiseに取り込むことでした。AWS IoT SiteWise のデフォルトコネクタは OPC UA ですが、顧客のデータソースは OPC UA 接続に対応していませんでした。GTE チームは、REST API 呼出しを OPC UA データに変換するブリッジコンポーネントを作成しました。変換されたデータは、オンプレミスの産業機器データを収集・処理・監視するための AWS IoT SiteWise Edge に取り込まれます。 下記は、ブリッジコンポーネントにおける、メインループの例です。 推論関数とブリッジの両方が、PINN モデルのようなひとつの AWS IoT Greengrass コンポーネントとしてパッケージ化されています。以下に見ることができるのは、推論関数 (ブリッジ) とモデルのコンポーネントであり、AWS IoT Greengrass デバイスへのデプロイ準備ができた状態です。 コンポーネントのデプロイ AWS IoT Greengrass は、デプロイタスクによって、ターゲットデバイスにコンポーネントをデプロイします。タスクのターゲットとしては、単一の AWS IoT Greengrass デバイス、あるいは複数デバイスのグループを指定することができます。 コンポーネントをデプロイするには、コンポーネントと AWS IoT Greengrass デバイスに適用する構成情報を定義します。 デプロイが created 状態となれば、カスタムコンポーネント (コンパイルされた PINN モデル、推論関数、ブリッジコンポーネント) が AWS IoT Greengrass デバイス上にデプロイされます。このデバイスは現在、そのハードウェア上でネイティブに推論タスクを実行する準備が整っています。 まとめ 本ブログ記事では、ファイザーのデジタル MI チームと GTE チームが、AWS の産業用エッジサービス、 AI / ML サービスを使用して、生産バイオリアクターの効率を向上させた方法について説明しました。MI Edgeプラットフォームを通じて、ファイザーはバイオリアクターをニアリアルタイムで監視し、適時、入力調整をすることができます。こうした能力により、生産性向上、サイクルタイムの短縮、汚染リスクの低減を実現しました。 ファイザーのデジタル製造 VP である Mike Tomasco 氏は、「 MI Edge の機能は、私たちのデータについてのビジョンと、高度な分析(機能)の実現に貢献しています。 」 と述べています。「我々は、 MI Edge の大変だったパイロットプロジェクトフェーズを乗り越えており、これら機能の本格的なグローバル展開を進めています。」 ファイザーは引き続き、AWS の産業用エッジサービスを活用した製造プロセスの改善方法を探求していきます。機械学習モデルの使用拡大による API (Active Pharmaceutical Ingredients. 原薬。医薬品に含まれる有効成分。) 製造プロセスの最適化、AI を活用した機器故障の予測と防止、製造サイトのエネルギー消費最適化に取り組んでいきます。 ファイザーは、AWS の産業用エッジサービスの使用を継続することで、製造プロセスを更に改善し、患者への医薬品供給を加速できると確信しています。 <!-- '"` --> TAGS: aws manufacturing , machine learning , Manufacturing , Pfizer Doug Anson Doug Ansonは、ハイテク分野で30年以上にわたるベテランです。ビジョン、戦略、実装/開発など、様々な役割で多くの技術分野に貢献してきました。主な注力分野は、産業 IoT 、クラウドコンピューティング、エッジ / IoT コンピューティング、プロトコル開発 / マッピング / 統合が含まれます。ハイテクの仕事の傍ら、Doug は商用パイロットのライセンスを持ち、大好きなテキサス州を飛行機で探訪する航空機所有者です!加えて、マーシャルアーツを熱心に学んでいます。 Don Bennett Don Bennett は、大手ライフサイエンス企業を支援する AWS インダストリーチームのシニアソリューションアーキテクトです。テクノロジーを活用する企業の目標達成を支援して、約25年の IT 経験を持っています。 Hamid Mehdizadeh Hamid Mehdizadeh は、ファイザーのグローバルデジタル製造インテリジェンスプログラムを率いています。このプログラムは、 AI / ML を大規模に、さらに加速して展開することが可能で、バイオ医薬品製造操作の支援を通じ、AI ドリブンな組織へと変革することを目指しています。Hamid は化学工学の博士号を持ち、グローバルのクロスファンクショナルチームに戦略的、戦術的な指針を提供してきた経験が10年以上あります。 Krishna Doddapaneni Krishna は、AWS の IoT スペシャリストパートナーソリューションアーキテクトです。日頃、パートナーと顧客が構築する極めて挑戦的で革新的な IoT 製品やソリューションの支援をしています。Krishna は、無線センサーネットワークで博士号、ロボットセンサーネットワークでポスドク研究員を務めました。彼は「コネクテッド」ソリューション、テクノロジー、セキュリティとそのサービスに情熱を注いでいます。 Patrick Jones Patrick Jones は、ファイザーデジタル PGS と協力し、エンタープライズアーキテクチャを指揮しているディレクターです。Patrick は、SFA、ヘルプデスク、サーバーおよびネットワーク管理、工場サイバーセキュリティ、部門およびエンタープライズアーキテクチャを経験してきました。幅広いスキルとビジネス知識を活用して、製造環境における ML / AI の全体的な実装の導きを支援してきました。ファイザーで31年以上のデジタル経験があります。 Saran Ethiraj Saran Ethiraj は、ファイザーデジタル PGS の MI ソリューションデリバリーのディレクターです。最新のデータベースからクラウドテクノロジーまで、様々な技術アーキテクチャとデザインの幅広い経験を持っています。この専門知識を活用し、コスト効率に優れたファイザーの AWS クラウドソリューションへ移行を支援しています。また、機械学習とエッジコンピューティングの技術的な支援、ビジネス影響への支援についても行っています。彼の最近のクラウドソリューションは、CIO 2023 イノベーション賞を受賞しました。 この投稿は、「 Pfizer boosts bioreactor efficiency with AWS industrial edge services 」 を AWS Japan SA の田中豊洋が翻訳しました。
Amazon Relational Database Service (Amazon RDS) では、オペレーティングシステムのリアルタイムメトリクスにアクセスできるようにすることで、RDS のリソースをさまざまなプロセスやスレッドがどのように使用しているかを監視できます。Amazon RDS コンソールで、インスタンスごとに 監視したいメトリクス を管理できます。 Amazon CloudWatch は AWS のネイティブモニタリングツールです。すべての AWS サービスとワークロードの主要な監視ツールとして、お客様に広く使用されています。 しかし、RDS には、CloudWatch と組み合わせて使用できる 拡張モニタリング と呼ばれるアドオン機能があります。テレメトリーの追加レイヤーが提供されるため、より高い解像度の監視データが必要な調査に役立ちます。CloudWatch メトリクスのみに依存するトラブルシューティング手法では、これらの重要な指標を見逃す可能性があります。そのため、拡張モニタリングのきめ細かなメトリクスと CloudWatch メトリクスを併用することで、インスタンスのパフォーマンスをより包括的かつ正確に把握でき、問題解決のための効果的な意思決定が可能になります。RDS インスタンスを作成すると、拡張モニタリングはデフォルトでは無効になっています。しかし、インスタンスの作成時に有効にするか、既存のインスタンスを変更して有効にすることもできます。この記事では、拡張モニタリングが提供するさまざまな機能について説明します。 拡張モニタリングは次のデータベースエンジンで使用できます。 Amazon RDS for MariaDB Amazon RDS for MySQL Amazon RDS for Oracle Amazon RDS for PostgreSQL Amazon RDS for SQL Server Amazon Aurora MySQL-Compatible Edition Amazon Aurora PostgreSQL-Compatible Edition (訳注: Amazon RDS for Db2 (2023 年 11 月 27 日に一般提供が開始) でも使用可能です) 拡張モニタリングは、db.m1.small インスタンスクラスを除くすべての DB インスタンスクラス で使用できます。この記事では、Amazon RDS for MySQL を使用した拡張モニタリングの機能について説明します。 拡張モニタリングの概要 RDS インスタンスを監視する場合、拡張モニタリングには次の利点があります。 CloudWatch メトリクスや Amazon RDS Performance Insights と一緒に使用できるモニタリングのもう 1 つのレイヤーが追加されます 注: ここでの CloudWatch メトリクスとは、RDS サービスが、追加費用なし、 1 分単位で CloudWatch に公開する、デフォルトの標準的なメトリクスのことを指します。 CPU Nice、空きメモリ、アクティブメモリ、ロードアベレージ (1、5、15 分)、スワップイン、スワップアウト、などを監視するための、サブコンポーネントレベルのメトリクスのグラフを提供します CloudWatch の標準的な 1 分よりも解像度が高く (1 秒、5 秒、10 秒、15 秒、30 秒、60 秒) 、パフォーマンスやリソース関連の問題の調査やトラブルシューティングに役立ちます DB インスタンスのデータストレージボリュームにおける、それぞれのディスクのメトリクスを示す、物理デバイスレベルのグラフを提供します Amazon CloudWatch Logs アカウントにログが配信され、CPU 使用率、メモリ、ディスク IO、ネットワーク、物理デバイス IO などの メトリクス を表示して調べることができます。 DB インスタンスで実行されているプロセスの詳細を含む、 オペレーティングシステムのプロセスリスト を提供します この記事では、次のことについて説明します。 Amazon RDS for MySQL で 1 秒単位の拡張モニタリングを設定する方法 RDS for MySQL インスタンスにテスト用の負荷をかける方法 CloudWatch コンソールと RDS 拡張モニタリングを使用してメトリクスを分析する方法 拡張モニタリングの追加機能 CloudWatch ロググループ RDSOSMetrics を元にした、拡張モニタリングログの表示 監視のための OS プロセスリストの表示 RDS インスタンスでワークロードを実行し、CloudWatch メトリクスと拡張モニタリングメトリクスの両方をモニタリングします。拡張モニタリングのメトリクスは CloudWatch メトリクスではなく CloudWatch ログに保存されます。拡張モニタリングにかかる費用は、RDS インスタンスから転送されるデータ量、拡張モニタリングの解像度、ログファイルの保持ポリシーなどの要因によって異なります。詳細については、「 拡張モニタリングのコスト 」を参照してください。 前提条件 テストでは、次のインスタンスとストレージ構成を使用しました。 Amazon RDS for MySQL エンジンバージョン — 8.0.32 インスタンスクラス — db.t2.medium ストレージタイプ — gp2 ストレージサイズ — 20GB クライアント — RDS インスタンスと同じ VPC にある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされている MySQL Workbench (バージョン 8.0) ツール Amazon RDSで拡張モニタリングを設定する 拡張モニタリングには、OS メトリクス情報を CloudWatch Logs に送信するための、 AWS Identity and Access Management (IAM) ロールが必要です。このロールは、 拡張モニタリングを有効にするときに作成することも、事前に作成することもできます 。RDS インスタンスの拡張モニタリングを有効または無効にするには、次の手順を実行します。 Amazon RDS コンソールでインスタンスを選択し、インスタンスが既に存在する場合は [変更] を選択します。 新しい DB インスタンスを作成する場合も、以下の手順は同じです。 [追加設定] &nbsp;を展開します。 モニタリングセクション で、DB インスタンスの [拡張モニタリングの有効化] を選択します。 モニタリングロール では、Amazon RDS が CloudWatch ログと自動的に通信できるようにするために作成した IAM ロールを選択するか、 デフォルト を選択して、Amazon RDS に rds-monitoring-role という名前のロールを作成させます。 [詳細度] では、DB インスタンスまたはリードレプリカのメトリクスが収集される時間の間隔を秒単位で選択します。このパラメーターは、1 秒、5 秒、10 秒、15 秒、30 秒、または 60 秒に設定できます。 または、 AWS コマンドラインインターフェイス (AWS CLI) コマンドを使用して拡張モニタリングを有効にすることもできます。詳細については、「 拡張モニタリングのオンとオフを切り替える 」を参照してください。 RDS for MySQL インスタンスでワークロードを実行する このテストでは、10,000 件のレコードを 2 つのステップ (それぞれ 5,000 件) で 5 秒の遅延を挟んで挿入します。この目的は、RDS for MySQL インスタンスの急激な負荷上昇をシミュレートし、後で拡張モニタリングのメトリクスからスパイクを調べることです。こういったスパイクは、RDS サービスがデフォルトで CloudWatch にパブリッシュするデフォルトのメトリクスでは観察できない場合があります。 MySQL Workbench などのクライアントから MySQL 用 Amazon RDS に接続します。 MySQL Workbench から Amazon RDS for MySQL に接続する方法については、「 MySQL Workbenchからの接続 」または「 Amazon RDS で MySQL データベースを作成して接続する 」を参照してください。 次のコマンドを実行して、MySQL Workbench または他のお好みのクライアントを使ってデータベースを作成します。 Create database testdb; テーブルを作成します。 use testdb; create table test1 ( id int not null auto_increment primary key, col1 varchar(10), col2 varchar(10) ) engine = InnoDB; 次のスクリプトを実行して、5 秒ごとにテーブルにデータを挿入します。 Drop procedure if exists testdata; delimiter // create procedure testdata (in num int) begin declare i int default 0; while i &lt; num do insert into test1 (col1,col2) values ('col1_value','col2_value'); set i = i + 1; end while; end // delimiter ; call testdata (5000); DO SLEEP(5); Drop procedure if exists testdata; delimiter // create procedure testdata (in num int) begin declare i int default 0; while i &lt; num do insert into test1 (col1,col2) values ('col1_value','col2_value'); set i = i + 1; end while; end // delimiter ; call testdata (5000); メトリクスの比較 このセクションでは、CloudWatch にパブリッシュされたデフォルトのメトリクスと RDS 拡張モニタリングによって生成されたメトリクスを比較して、前述のワークロードの主要なメトリクスをいくつか調べます。 WriteIOPS: CloudWatch 10,000 件のレコードが、5 秒の遅延をはさんで 2 回にわけて RDS for MySQL インスタンスに挿入されたとき、次の CloudWatch グラフに示すように、CloudWatch メトリクスでは WriteIOPS が約 530 であることが示されました。Amazon RDS は、メトリクスデータを 1 分間隔で CloudWatch に送信することに注意してください。そのため、グラフには 1 分未満の急上昇があったとしても表示されません。 WriteIOPS: 拡張モニタリング 同じワークロードにおいて、拡張モニタリングでは WriteIOPS が約 1600 と表示されます。これは、このデモでは拡張モニタリングの解像度が1秒に設定されているため、拡張モニタリングのアドオン機能が提供する最も詳細なデータが得られるためです。次のスクリーンショットは、拡張モニタリングの解像度が高いために1分未満のスパイクが発生している、拡張モニタリングによる 書き込み IO/秒 を示しています。ディスク I/O とファイルシステムの集計グラフを表示する場合、rdsdev デバイスは、すべてのデータベースファイルとログが保存されている /rdsdbdata ファイルシステムに関連付けられます。filesystem デバイスは、オペレーティングシステムに関連するファイルが保存されている / ファイルシステム ( root とも呼ばれる) に関連しています。 CPU 使用率: CloudWatch 同じワークロードでの CloudWatch の CPU 使用率についても同じ傾向が見られます。1 分の精度で最大値は約 12% と報告されます。次のスクリーンショットは、CloudWatch からの CPU 使用率を示しています。 CPU 合計: 拡張モニタリング 一方、拡張モニタリングでは、より短い1 秒単位の解像度の機能により、CPU 使用率が約 50% と報告されています。次のスクリーンショットは、拡張モニタリングによる CPU 合計を示しています。 CPU Nice:拡張モニタリング インスタンス上の、ユーザのワークロードによる CPU 使用率を意味する CPU Nice などのメトリクスを確認したい場合、拡張モニタリングでは次のグラフが表示されます。同様に、アクティブメモリ、空きメモリ、空きスワップ、スワップイン、スワップアウト 等々 のグラフも表示されます。 観察のまとめ 拡張モニタリングは、OS レベルのきめ細かな1分未満の解像度のメトリクスを監視するのに役立ちます。拡張モニタリングのこの解像度の機能は、Amazon RDS が 1 分間隔で平均化したメトリクスデータを CloudWatch に送信するため、CloudWatch ではキャプチャされない、1 分未満の間でスパイクするワークロードを監視する場合に便利です。たとえば、テストの結果より、CloudWatch では WriteIOPS の使用率が高い(ピークは 1,600 IOPS)ことは確認されていません。ReadIOPS が同様のレベルまで上昇したとしても、同じ現象が予想されます。このため、拡張モニタリングを CloudWatch のデフォルトメトリクスと組み合わせて使用すると、包括的かつ詳細なトラブルシューティングを実行するのに役立ちます。 さらに、CPU Nice グラフに見られるように、拡張モニタリングからさまざまなメトリクスのサブコンポーネントのグラフを確認することもできます。拡張モニタリングのダッシュボードに表示するグラフを選択するには、 [グラフを管理] タブを開いてサブコンポーネントを選択します。 拡張モニタリングのその他の機能 RDSインスタンス上でデータがストライピングされるボリュームの数を知る必要がある場合があります。この情報は、スロットリング、レイテンシー、およびその他のパフォーマンス関連の問題に対するトラブルシューティングに役立ちます。 次のスクリーンショットの中で、RDS インスタンスに 4 つのボリュームがアタッチされていることがわかります。Amazon RDS for SQL Server では、サイズに関係なくアタッチされるボリュームは 1 つだけです。アタッチするボリュームのタイプに応じて、それぞれのスループットと IOPS の制限が適用され、Amazon RDS のパフォーマンスにおいてに大きな役割を果たします。 次のスクリーンショットは、拡張モニタリングによる物理書き込み IO/秒 を示しています。 CloudWatch のロググループ 拡張モニタリングでは、ロググループ RDSOSMetrics 上で、生成されたログが保持されます。これらのログには JSON 形式のデータが含まれており、CloudWatch コンソールと AWS CLI で表示できます。ログストリームの各ログには、 RDS インスタンスに関連するデータ の配列が含まれています。ロググループ RDSOSMetrics で生成された RDS インスタンスログを表示するには、次の手順に従います。 CloudWatch コンソールのナビゲーションペインで [ロググループ] を選択します。 RDS インスタンスに対応するログストリームを選択します (ログストリームは RDS DBリソースIDと同じ名前です)。 時間範囲のフィルターに基づいて調査に必要なログを選択します。 次の例には、 cpuUtilization:nice 、 memory:buffers などのすべてのメトリクスの詳細な値が含まれています。 { "engine": "MYSQL", "instanceID": "yyyy", "instanceResourceID": "xxxx", "timestamp": "2023-05-01T20:36:02Z", "version": 1, "uptime": "00:27:36", "numVCPUs": 4, "cpuUtilization": { "guest": 0, "irq": 0, "system": 0.3, "wait": 0, "idle": 99.3, "user": 0.3, "total": 0.9, "steal": 0, "nice": 0.3 }, "loadAverageMinute": { "one": 0.04, "five": 0.03, "fifteen": 0.04 }, "memory": { "writeback": 0, "hugePagesFree": 0, "hugePagesRsvd": 0, "hugePagesSurp": 0, "cached": 716380, "hugePagesSize": 2048, "free": 13573744, "hugePagesTotal": 0, "inactive": 2026324, "pageTables": 7744, "dirty": 848, "mapped": 107644, "active": 267504, "total": 16069100, "slab": 72004, "buffers": 140440 }, "tasks": { "sleeping": 111, "zombie": 0, "running": 0, "stopped": 0, "total": 111, "blocked": 0 }, "swap": { "cached": 0, "total": 16776188, "free": 16776188, "in": 0, "out": 0 }, "network": [ { "interface": "eth0", "rx": 910, "tx": 12785 } ], "diskIO": [ { "writeKbPS": 16, "readIOsPS": 0, "await": 1, "readKbPS": 0, "rrqmPS": 0, "util": 0.8, "avgQueueLen": 0, "tps": 4, "readKb": 0, "device": "rdsdev", "writeKb": 16, "avgReqSz": 8, "wrqmPS": 0, "writeIOsPS": 4 }, { "writeKbPS": 4, "readIOsPS": 0, "await": 1, "readKbPS": 0, "rrqmPS": 0, "util": 0.4, "avgQueueLen": 0, "tps": 1, "readKb": 0, "device": "filesystem", "writeKb": 4, "avgReqSz": 8, "wrqmPS": 0, "writeIOsPS": 1 } ], "physicalDeviceIO": [ { "writeKbPS": 16, "readIOsPS": 0, "await": 1, "readKbPS": 0, "rrqmPS": 0, "util": 0.8, "avgQueueLen": 0, "tps": 3, "readKb": 0, "device": "nvme1n1", "writeKb": 16, "avgReqSz": 10.67, "wrqmPS": 1, "writeIOsPS": 3 } ], "fileSys": [ { "used": 372316, "name": "", "usedFiles": 251, "usedFilePercent": 0, "maxFiles": 13107200, "mountPoint": "/rdsdbdata", "total": 205270252, "usedPercent": 0.18 }, { "used": 2233064, "name": "", "usedFiles": 39420, "usedFilePercent": 6.02, "maxFiles": 655360, "mountPoint": "/", "total": 10230600, "usedPercent": 21.83 } ] ログは、ログストリームデータを消費できるその他のAWSサービスや、処理および可視化ツールを提供するサードパーティーツールに転送することができ、それぞれ、 Amazon Kinesis Data Firehose や Amazon QuickSight といったものが挙げられます。 監視のためのOSプロセスリスト DB インスタンスで実行されているプロセスの詳細を確認したい場合は、Amazon RDS コンソールの RDS インスタンスの [モニタリング] タブにある [ OS プロセスリスト ] を選択します。 プロセスリストビューに表示される拡張モニタリングメトリクスは、RDS 子プロセス、RDS プロセス、および OS プロセスに分類されます。 CloudWatch と拡張モニタリングの測定値には違いがあるかもしれません。詳細については、「 CloudWatch と拡張モニタリングのメトリクスの相違点 」を参照してください。 拡張モニタリングにより、ネットワーク、スワップ、ProcessListなどの新しいメトリクスにアクセスできます。拡張モニタリング専用のこれらのメトリクスは、トラブルシューティングを行っている間に、OS がどのように動作していたかをより深く理解するのに役立ちます。拡張モニタリングで利用できるメトリクスを確認するには、「 拡張モニタリングの OS メトリクス 」を参照してください。 Amazon RDS モニタリングツールに関する考慮事項 Amazon RDS は、データベースパフォーマンスのモニタリングとトラブルシューティングのため、拡張モニタリング、CloudWatch、Performance Insights の 3 つの主要なツールを提供します。これらのツールは、RDS に関する特定の問題のトラブルシューティングのため、それぞれ独自のユースケースがあります。 拡張モニタリングを使用すると、データベースエンジンが実行されている OS に関する非常に詳細なメトリクス、細かく分けられたメトリクス (CPUUtilization.nice、memory.free など)、および CloudWatch に送られたログを取得して、さらなる分析と統合が可能になります。 一方、CloudWatch は、RDS サービスによって公開されたデフォルトのメトリクスを 1 分単位で受け取り、インスタンスの動作を視覚的に確認するために幅広く使用されます。このツールには、グラフの重ね合わせ、軸の切り替え、数式計算、粒度の変更 (1 分、5 分、15 分)、CloudWatch 保持ポリシーで定義されている履歴データ (数か月にさかのぼる) の表示などの機能もあり、Amazon RDS でのリソース使用や顧客ワークロードの傾向を特定するのに非常に役立ちます。 拡張モニタリングと CloudWatch にはそれぞれ独自のメトリクスがあります。拡張モニタリングには、他のメトリクスに加えて物理デバイスのメトリクスがあります。一方、CloudWatch には、BurstBalance、DatabaseConnections など、使用パターンの特定に役立つ重要なメトリクスがあります。 Performance Insights では、データベースの負荷を評価して最適化できます。また、1 分未満のメトリクスも提供され、1 秒間のメトリクスは最大 2 年間保持されます。待機イベントや SQL クエリなど、複数のディメンションを使用して細かく分析できます。また、Performance Insightsでは、Amazon RDS の負荷を視覚化し、その原因となっているクエリの種類、クエリの発信元、原因となっているユーザーを特定するのに役立ちます。 クリーンアップ 追加コストが発生しないように、このデモンストレーションに使用したリソースはすべて削除してください。 RDS インスタンスを削除します。 ローカルホストから クライアントツールを削除 します。 RDS インスタンスの拡張モニタリングに関連する ログストリームを削除 します。 RDSOSMetrics はデフォルトで 30 日間保持されることに注意してください。 まとめ この記事では、Amazon RDS for MySQL のワークロードがスパイクするデモを使って、インスタンスのパフォーマンスをより包括的かつ正確に把握するために、拡張モニタリングの詳細なメトリクスを使用することの重要性を強調しました。 この投稿について質問やコメントがある場合は、コメントセクションに残してください。 著者について Abdul Sarker は、AWS で 2 年間にわたってクラウドサポートエンジニアを務めています。AWS クラウドで優れたカスタマーエクスペリエンスを提供することに重点を置き、外部のお客様と協力して、Amazon RDS インフラストラクチャのトラブルシューティング、AWS DMS プロジェクトの支援、社内文書や記事の作成と改善など、さまざまなシナリオを処理しています。 Nirupam Datta は AWS のクラウドサポート DBA です。彼はAWSに約3年半在籍しています。データベースエンジニアリングとインフラストラクチャアーキテクチャで 11 年以上の経験を持つNirupamは、Amazon RDSのコアシステムと Amazon RDS for SQL Server の専門家でもあります。彼はお客様に技術支援を提供し、AWS クラウドへの移行、最適化、移行を支援しています。 翻訳はクラウドサポートエンジニアの立野が担当しました。原文は こちら です。
情報システムの公平かつ迅速な調達のために、SaaS のカタログサイト「デジタルマーケットプレイス(以下、DMP)」がデジタル庁によって構築・提供されています。 アマゾン ウェブ サービス ジャパン(以下、AWS)は DMP へのご登録に関心のある事業者や DMP・公共調達に関わる事業者同士の交流を希望される方に向けて、2023 年 12 月 20 日に「デジタルマーケットプレイス 実証カタログサイト DMP(α 版)ワークショップ・交流会」を AWS Startup Loft Tokyo にて開催しました。 本イベントは DMP の意義や利点について参加者の方々にご理解いただき、DMPに関心のある事業者や販売会社の方々がネットワークを形成する場としてご活用いただくことを目指しました。ここではそのレポートをお届けします。 デジタルマーケットプレイス概要 AWS パブリックセクター 官公庁事業本部 DX Advocate 七尾 健太郎 はじめに、AWS パブリックセクター 官公庁事業本部 DX Advocate の七尾 健太郎より、DMP の概要について解説しました。 現在、行政機関が情報システムを導入する際には、行政機関の調達仕様に対して複数社が価格と提案を示し、これらを総合評価した上で最も適した事業者を落札するという流れになっています。この仕組みでは、調達にかかるまでの期間が長く、手続きが官民の双方にとって負担になります。また、営業組織が大きくはない企業にとっては、どこで公募が行われているのかを探すことや、探すことができても応札する作業が大変で、参入障壁が高いと感じるかもしれません。 一方の DMP では、デジタル庁と基本契約を締結した事業者がソフトウェア(SaaS)を登録できる、カタログサイトを設けます。そのカタログサイトを通じて各行政機関が最適なサービスを選択し、個別契約を行う流れになっています。これにより、調達にかかるまでの期間が短くなり、調達のプロセスそのものも簡潔になります。さらに、調達情報が可視化され、透明性が担保されることで、多くの事業者が参入することも期待できます。 2023年11月に実施されたデジタル庁説明会より引用 ここから七尾は、2024 年度以降に DMP を活用した情報システム調達がどのような流れになるのかを解説していきました。 最初のステップでは、デジタル庁がソフトウェア開発会社や販売会社といった事業者とそのサービスを募集します。その次に、デジタル庁と事業者間で調達の基本的な諸条件について契約を締結(基本契約)。さらに、事業者がWeb 上に仕様・約款・価格表を含むサービス情報を登録し掲載されるため、行政機関がそれらの情報を検索・閲覧します。最後に、各行政機関がサービスを選定し、事業者との個別契約を締結します。この際に、DMPで検索・比較した結果がエビデンスとされることで、調達の透明性や公平性を担保されます。 DMP を導入することで、多くのソフトウェア(SaaS)製品の可視化と比較を可能にし、行政機関に迅速で公平な調達を促します。こうした公共調達を通じて中小企業やスタートアップといったソフトウェア産業の振興を実現する効果が期待されています。 DMP で検索を行う際には「政策タグ」と「機能タグ」というカテゴリーを検索条件として使用します。「政策タグ」には、たとえば「防災」や「マイナンバーカード対応」といった要素が含まれており、「機能タグ」には、たとえば「チャット」や「会計ソフト」といった要素が含まれています。それぞれの検索条件を組み合わせることで適切なソフトウェアを見つけることが可能になります。 七尾はセッション終盤に、DMP と Amazon のビジネスモデルとの類似点について解説しました。Amazon はそこに訪れるお客様体験の向上を重視しています。それによりアクセス頂くお客様が増えることで、出品者と品揃えが増え、それによってまた顧客体験が向上します。こうして取引量が増えると、より効率的なマッチング構造が実現でき、より適正な価格で商品を購入頂けるようになり、またさらに顧客満足度が向上するという、好循環を生み出しています。DMP でもそうした好循環が起きることへの期待を述べたうえで、「今後も AWS パブリックセクターは DMP の普及の支援をしていきます」とセッションを結びました。 DMP のソフトウェア、サービスの登録操作について AWS プロフェッショナルサービス パブリックセクター シニアアドバイザリーコンサルタント 上土井 裕人 ここからは、AWS プロフェッショナルサービス パブリックセクター シニアアドバイザリーコンサルタントの上土井 裕人が、DMP へソフトウェアやサービスを登録する具体的な手順*について解説しました。DMP(α 版)への登録作業は、大きく 5 つのステップに分かれています。 ステップ1. 事前準備 ステップ2. 事業者情報の登録 ステップ3. ソフトウェア情報の登録 ステップ4. ソフトウェア価格情報の登録 ステップ5. 付帯するサービスの登録 2023年11月に実施されたデジタル庁説明会より引用 セッション内ではこれら一連の手順の説明に加えて、DMP 上に掲載されている「よくある質問」とその回答についても上土井は解説しました。 「よくある質問」の詳細は こちら ※詳しい操作方法につきましては、 DMP(α版)サイト の、 事業者向けご利用ガイド をご参照ください。 セッション終盤では、実際に DMP の画面を操作しながら、一連の情報登録プロセスをデモンストレーションしました。 その後の質疑応答では、会場・オンラインの参加者から多くの質問や、DMPに関する要望が寄せられました。AWS社員からは、DMP(α版)は初期段階であり、今後は参加者の皆でDMPを良くしていこうというコミュニティ作りが大事だというお話をしました。いただいた質問は、後日デジタル庁に問い合わせ、正式な回答を参加者にお送りしています。 セッション後の交流会では、公共調達に関心のある事業者同士の情報交換やネットワーキングが活発に行われました。また、この交流会には DMP の開発に携わる 株式会社 dotD の方々も参加。DMPの機能や在り方について、意見交換が実施されました。 おわりに イベント最終盤では、AWS パブリックセクター シニア事業開発マネージャーの岩瀬 霞がご挨拶をしました。 「AWS パブリックセクターでは今後も、公共分野でビジネスに取り組まれている方々や、これから参入される方々に向けてご支援とコミュニティ形成を行っていきます。今回のイベントのテーマであった DMP に関しても、利用にあたっての解説やコミュニティ形成を 2024 年も継続して行う予定です。 ご参加いただいている皆様と一緒にDMP をより良くしていきたい。それによって、公共分野の課題解決につながると信じて、私たちは活動しております。 今回は DMP α版の事業者向けの登録機能のみリリースされた段階でのワークショップでしたが、今後さらに機能が追加され、行政職員の方々が登録されたサービスを検索できるようになる予定です。その際には、もう一度このような形でワークショップや交流会を行うことを想定しています。ぜひ、その際にはご参加いただければ幸いです。」 DMPの概要に関しては、こちらのブログでも解説しております。AWSの公共分野でのご支援や活動にご関心をお持ちの方は、ぜひ こちら よりお問い合わせください。お読みいただきありがとうございました。 関連リンク デジタルマーケットプレイス&nbsp; α 版 公共機関における AWS 導入のためのお役立ちサイト AWS プロフェッショナルサービス AWS スタートアップ支援プログラム 公共分野におけるAWSのスタートアップ支援
この記事は アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 山本 直志、渡邉 聡と アイレット株式会社 土井田篤氏、吉盛浩司氏による共著です。 2023 年 11 月 29日から12月 2 日までの 4 日間、東京ビッグサイトで「2023 国際ロボット展」が開催されました。国際ロボット展は iREX (International Robot Exhibition )とも呼ばれ、東京ビックサイトにて毎年開催される、産業ロボットやコンシューマロボットに関する最先端の技術が集結する世界最大級の国際見本市です。今回の国際ロボット展では、 AWS および AWS パートナーのアイレット株式会社が、一般社団法人 Edgecross コンソーシアム *1の会員企業として、共同で Edgecrossブースのデモを構築展示しました。 Edgecross(エッジクロス)コンソーシアムとは Edgecross コンソーシアムとは、工場内の FA (ファクトリーオートメーション)機器と IT システムの連携を推進する業界団体で、国内外の FA ベンダーから IT ベンダー、その他含め、 400 以上( 2023 年 1 月現在)の組織が加盟しています。エッジコンピューティング領域のオープンなプラットフォーム「 Edgecross 」の進化と普及を通じて、 IoT と産業界全体の進展のために活動しています。下記は Edgecross ソフトウェアの概念図です。 ロボットが配置される生産現場では複数メーカーかつ新旧の様々な装置が稼働し、それぞれが CC-Link IE、 EtherCAT 、 EtherNet/IP 、 PROFINET 、 MTConnect などの異なる FA プロトコルを使用して通信します。真ん中の Edge 層に位置する Edgecross 基本ソフトウェアは各種 FA プロトコルのデータコレクタを持っており、生産現場の FA ネットワークに応じて適切なデータコレクタを選択することで、 FA プロトコルの違いを吸収することができます。それにより、工場内に散在する異なるメーカーのロボットや装置を束ねて、 IT システム層(上記概念図の一番上の層)に繋ぎ、工場全体のロボットの稼働状況の一元把握などの様々なデータ活用を行うことができるようになります。 昨年開かれた JIMTOF 2022 でも AWS は Edgecross コンソーシアムの会員企業として 工作機械のデータをクラウドで可視化・活用するデモを提供し、そのアーキテクチャをご紹介しました 。JIMTOF のデモでは AWS IoT SiteWise および、 Amazon ECS で Grafana コンテナをホストすることで可視化ダッシュボードを作り、さらには AWS IoT Core を通じて各社のソリューションとシームレスな連携が取れることをご紹介しました。その際、実際の会場に配置された機器の状態をダッシュボード上の会場マップで表現するなど複雑な表現を行うために、OSS の Grafana とコミュニティプラグインを使う必要がありました。しかし、2023年11月の Amazon Managed Grafana のアップデートにより Amazon Managed Grafana でもコミュニティプラグインを用いた拡張が可能になりました 。また、これまで東京リージョンでは利用できなかった AWS IoT TwinMaker が2023年10月に 東京リージョンで GA されたことによって、Amazon Managed Grafana と AWS IoT TwinMaker を用いてより高度な設備状態の表現が可能になってきました。国際ロボット展では、これらのアップデートを存分に盛り込んだ形のデモ展示となっています。次に、今回実際に展示したデモの概要をご紹介します。 Edgecross (エッジクロス)コンソーシアム 展示ブース 国際ロボット展 2023 の Edgecross コンソーシアムブースでは、「その生産性、エッジ IoT でいっぱつ解決」というコンセプトのもと、27社の会員企業様とスマートファクトリーソリューションを協同展示しました。実際には Edgecross 会員であるロボットメーカー5社のブースで展示されているロボットから Edgecross 基本ソフトウェアを活用して稼働データ(生産数、良品数、ステータス、サイクルタイム、電力量、エラーコードなど)を収集し、国際標準規格の「OPC UA」(OPC Unified Architecture)で各会員企業様の製品やソリューションへ配信し、前述のコンセプトを具現化するものとなっています。 今回 AWS とアイレットは、会場全体を大きな工場と見立て、その稼働状況を表示するダッシュボードを構築して展示しましたので、その概要をご紹介します。 デモの概要 今回構築したデモ環境の構成図を以下に示します。 Edgecross コンソーシアムブースに設置した PC に AWS IoT Greengrass で OPC UA のデータを収集、配信するコンポーネントをデプロイし、Edgecross 基本ソフトウェアから提供されるロボットの稼働データを収集、AWS IoT SiteWise へ転送しています。AWS IoT SiteWiseでは展示会場全体/ロボットメーカー/ロボットの階層構造を持つアセットを構成し、構造化された時系列データが蓄積される様になっています。 ダッシュボードは Amazon Managed Grafana で展示会場全体とロボット個別の稼働状況を表示するものを作成しました。 展示会場の 3D フロアマップは AWS IoT TwinMaker で作成して展示会場全体のダッシュボードに組み込み、こちらも AWS IoT SiteWise&nbsp; のデータと連動してロボットメーカー毎の稼働状況を表示しています。 今回のデモは AWS のマネージドサービスをフル活用し、短時間かつシンプルな構成で構築することができました。 以下に展示したダッシュボード画面をご紹介します。 展示会場全体ダッシュボード 中央には展示会場のフロアマップを AWS IoT TwinMaker を用いて 3D で可視化しており、ロボットメーカー毎の稼働状況をブースの色で表現しています。 また、画面右側には展示会場全体、下側にはロボットメーカー毎に集計した主要 KPI を表示しています。 ロボット個別ダッシュボード 画面左上には画像を含むロボットの情報を、その下にはロボットの稼働データから計算した主要な KPI(設備総合効率、性能、稼働率、品質)、運転状況、アラーム状況を表示しています。 画面右側には良品/不良品を含む生産数や消耗品使用回数、消費電力の累積値等を表示しています。 生産数、設備効率、電力使用量についてはグラフで表現し、時系列の変動を確認できる様にしています。 まとめ Edgecross と AWS の IoT サービスを組み合わせることにより、異なる FA プロトコルを使用するエッジデバイスのデータを手軽にクラウドに送信、可視化、そして活用に繋ぐところまでを素早く実現できる点が、本デモのポイントです。 期間中、国際ロボット展には過去最多の 15 万人以上の方が来場され、 Edgecross コンソーシアムのブースにも多数のお客様がお越し下さいました。ミニブースでのプレゼンテーションに加え、ブースにお越しいただいた皆様とは、「装置データをクラウドに置くことの価値」や、「実際に自社の工場に導入する際の課題」等をディスカッションさせていただきました。 AWS では日本国内に製造業を専門にしたチームを有し、 Smart Factory のワークロードで AWS クラウドを利用いただくご支援をしています。ご興味のある製造業のお客様は AWS までお問合せください 。また、AWS パートナーのアイレット株式会社には下記の情報よりコンタクトください。 アイレット株式会社– AWS パートナースポットライト アイレットは、AWS を活用したインフラ構築、システム開発、UI/UX デザイン、24時間365日の運用・保守までをトータルでサポートする「cloudpack」を提供している AWS パートナー企業です。2013年には日本初の「AWS プレミアコンサルティングパートナー(現 AWS プレミアティアサービスパートナー)」に認定され、これまでの導入実績は 2,500 社以上、年間プロジェクト数は 4,300 以上にのぼり、スタートアップ企業から大企業まで、規模や業種を問わず幅広いお客様をご支援させていただいております。 アイレット株式会社 問い合わせ先 | パートナー概要 *1 Edgecross の詳細は以下を参照ください https://www.edgecross.org/ja/
※本記事に記載の内容は 2024 年 1 月 29 日の内容に基づいたものです。今後、サービスの更新や変更に伴い、本記事の内容と異なる部分が出てくる可能性がある点、予めご了承ください。 こんにちは!テクニカルトレーナーの室橋です。2024 年が始まり、早くも 1 ヶ月ですね。みなさま、今年の学習計画は立てていらっしゃいますか?学習計画の中に「AWS クラウドの学習」が入っている方は、AWS クラウドの学習教材として、ゲームベースで行うことができる学習コンテンツの「AWS Cloud Quest (以下 CQ )」 のご利用はいかがでしょうか。CQ は、ゲーム内で、ストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS アカウントを使用しながら解いていく、RPG テイストのコンテンツです。以前 こちらのブログ にてご案内いたしました通り、 「AWS Cloud Quest: Cloud Practitioner」 については、無料 & 日本語版でプレイ可能です。 さて、本日は 2023 年 11 月から 2024 年 5 月末まで、期間限定で利用可能な 「AWS Cloud Quest: Recertify Cloud Practitioner (Japanese) 日本語版(以下 CQ : CPE 再認定)」 の無料ベータ版のご紹介です。 この、新たにご提供する「CQ : CPE 再認定」は、AWS 認定の 1 つである 「AWS Certified Cloud Practitioner」 向けの新しい再認定オプションです。「CQ : CPE 再認定」のすべての課題をクリアすることにより、既に取得済みで、6 ヶ月以内に更新が必要な「AWS Certified Cloud Practitioner」を更新することが可能です(残り期間が 6 ヶ月以上の場合、再認定のロールにはチャレンジできません)。 「CQ : CPE 再認定」を利用する場合、まずは「Skill Builder」から「Cloud Quest: Recertify Cloud Practitioner」を検索し、 「AWS Cloud Quest: Recertify Cloud Practitioner (Japanese) 日本語版」 の登録を行ってください(CQ の Cloud Practitioner ロール同様、こちらも無料で利用可能です)。 再認定のロールにチャレンジする場合、CQ にログイン後、画面左上の「ロール」を選択してください。下記画面では、オレンジ色のボタンで表示されています。 その後表示されるロール選択画面にて、「Cloud Practitioner 再認定」ロールを選択した後に「ロールを有効化」ボタンをクリックし、その後に表示される画面でご自身の「Candidate ID」を入力すると、再認定のロールが有効化できます。その際、Candidate ID に紐づいた CLF の認定期間が残り 6 ヶ月以内である必要がありますので、ご注意ください(残り期間が 6 ヶ月以上の場合、再認定のロールを有効化することができません)。 また、再認定の課題に挑戦する前には、「Cloud Practitioner」ロールの 12 個のクエストをクリアする必要があります。再認定の課題のみにチャレンジすることはできませんので、まずは「Cloud Practitioner」ロールをクリアし、その後、再認定の課題に挑戦してください。なお、既に「Cloud Practitioner」ロールの 12 個の課題をクリア済みの方は「Cloud Practitioner 再認定」のロールを選択し、すぐに再認定チャレンジに挑戦できます。 再認定のチャレンジ内容に関しては、このブログの中でご案内することはできないのですが、「Cloud Practitioner」ロールをプレイして、知識を身につけていれば、達成可能な内容です。じっくりと時間を取ってチャレンジしてください。 再認定の課題を含め、「CQ : CPE 再認定」ロールのすべての課題が完了すると、認定を 3 年間更新することができます。クリア後の「受け取る」ボタンをクリックし、再認定の申請を行ってください。 今回ご紹介した 「AWS Cloud Quest: Recertify Cloud Practitioner (Japanese) 日本語版」 をプレイすることにより、普段受けていただく認定試験とは一味違い、実践的な経験を通じて、AWS の知識を確認しつつ、再認定にチャレンジできます。現段階では、2024 年 5 月末までの期間限定でのご案内予定のため、この機会に是非、認定の更新にチャレンジしてください。 そして、最後に耳寄りな追加情報です!現在、AWS では、AWS の全認定試験について、再受験無料キャンペーンを実施しております。こちらは、2024 年 4 月 15 日までにプロモーションコードを入力して試験予約および受験いただくと、試験に不合格だった場合、2024 年 6 月 30 日までの再受験が無料(無料再試験は一人につき 1 回まで)になるというキャンペーンです。詳細に関しましては こちらのページ にてご案内しておりますので、AWS の認定試験を受験予定の方は是非チェックしてください。 ご参考までに、CQ の日本語版が日本語表示されない場合の「言語表示の切り替え方法」をあわせてご案内します。ゲームタイトル画面で日本語が表示されない場合、以下の手順で日本語に切り替えることができます。 1. タイトル画面右上にある「Settings」(歯車マークのアイコン) をクリックします。 2. 画面左にある「Language」をクリックします。 3. 「Japanese / 日本語」を選択すると「Change Language?」ポップアップが表示されるので、「I Understand」ボタンをクリックします。 4. ゲームが再起動されることを伝える日本語のポップアップが表示されます。「OK」をクリックすると、ゲームが再起動し、日本語のゲームタイトルが表示されます。
このブログは、 Improved resiliency with backpressure and admission control for Amazon OpenSearch Service を翻訳したものです。 Amazon OpenSearch Service は、AWS クラウドで OpenSearch クラスターを大規模に安全にデプロイし運用するのを簡単にするマネージドサービスです。昨年、 Shard indexing backpressure と アドミッションコントロール を導入しました。これはクラスターリソースと入力トラフィックをモニタリングして、メモリ不足などの安定性のリスクを引き起こす可能性のあるリクエストを選択的に拒否したり、メモリの競合、CPUの飽和、GC オーバーヘッドなどによるクラスター パフォーマンスへの影響を軽減します。 OpenSearch Service の Search Backpressure と CPU ベースのアドミッションコントロールをご紹介できることを嬉しく思います。これにより、クラスターの回復力がさらに向上します。これらの改善は、OpenSearch のバージョン 1.3 以降のすべてのバージョンで利用できます。 Search Backpressure バックプレッシャーは、システムが作業で圧倒されるのを防ぐ機構です。 バックプレッシャーは、クラッシュやデータ損失を防ぎ、パフォーマンスを改善し、システムの完全な障害を回避するために、トラフィックレートの制御や過剰な負荷を削減します。 Search Backpressure は、ノードが負荷状態にあるときに実行中のリソース集約型の検索リクエストを識別してキャンセルするメカニズムです。これは、ノードのクラッシュやクラスター全体の健全性への影響を引き起こしうる、異常に高いリソース使用量(複雑なクエリ、遅いクエリ、多数のヒット、重い集計など)を伴う検索ワークロードに対して効果的です。 Search Backpressure は、タスクのリソースを追跡するフレームワークの上に構築されており、各タスクのリソース使用量を監視するための使いやすい API を提供しています。Search Backpressure はバックグラウンドスレッドを使用してノードのリソース使用量を定期的に測定し、CPU時間、ヒープ割り当て、経過時間などの要因に基づいて実行中の各サーチタスクにキャンセルスコアを割り当てます。キャンセルスコアが高いほど、よりリソースを必要とするサーチリクエストになります。サーチリクエストはキャンセルスコアの降順にキャンセルされてノードが迅速に回復しますが、無駄な作業を避けるためにキャンセルされる数はレート制限されます。 次の図は、Search Backpressure のワークフローを示しています。 検索リクエストのキャンセル時には、HTTP 429 “Too Many Requests” ステータスコードが返されます。OpenSearch は、失敗したシャードが一部の場合に限り、部分的な結果を返します。以下のコードを参照してください: { "error": { "root_cause": [ { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb &gt;= 77.6mb], elapsed time exceeded [1.7m &gt;= 45s]" } ], "type": "search_phase_execution_exception", "reason": "SearchTask was cancelled", "phase": "fetch", "grouped": true, "failed_shards": [ { "shard": 0, "index": "nyc_taxis", "node": "9gB3PDp6Speu61KvOheDXA", "reason": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb &gt;= 77.6mb], elapsed time exceeded [1.7m &gt;= 45s]" } } ], "caused_by": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb &gt;= 77.6mb], elapsed time exceeded [1.7m &gt;= 45s]" } }, "status": 429 } Search Backpressure のモニタリング ノードステータス API を使用して、詳細な Search Backpressure の状態を監視できます: curl -X GET "https://{endpoint}/_nodes/stats/search_backpressure" Amazon CloudWatch を使用して、クラスタ全体のキャンセルの概要も確認できます。次のメトリクスが ES/OpenSearchService 名前空間で利用可能です: SearchTaskCancelled – コーディネーターノードのキャンセル数 SearchShardTaskCancelled – データノードのキャンセル数 次のスクリーンショットは、CloudWatch コンソールでこれらのメトリクスを追跡する例を示しています。 CPU ベースのアドミッションコントロール アドミッションコントロールは、現在の容量に基づいてノードへのリクエスト数を先取りして制限するゲートキーパーメカニズムで、通常のトラフィック増加やスパイクトラフィックの両方に対応します。 JVM メモリプレッシャーとリクエストサイズのしきい値に加えて、移動平均の CPU 使用率をモニタリングして、入力される _search と _bulk リクエストを拒否するようになりました。 これにより、ノードが多数のリクエストで圧倒されてホットスポット、パフォーマンスの問題、リクエストのタイムアウト、その他の連鎖的な障害が発生するのを防ぎます。 過剰なリクエストは、拒否時に HTTP 429 “Too Many Requests” ステータスコードが返されます。 HTTP 429 エラーの処理 ノードに過剰なトラフィックを送信すると、HTTP 429 エラーが発生します。これは、クラスタリソースが不足しているか、リソース消費の激しい検索リクエストが発生しているか、意図しないワークロードのスパイクが発生したことを示しています。 Search Backpressure は、拒否をする理由を提供します。これにより、リソース消費の激しい検索リクエストを微調整できます。 トラフィックスパイクの場合、エクスポネンシャルバックオフとジッターを用いたクライアント側のリトライをおすすめします。 過剰な拒否をデバッグするために、これらのトラブルシューティングガイドも参考にできます: OpenSearch サービスで検索拒否または書き込み拒否を解決する方法を教えてください。 Amazon OpenSearch Service クラスターでの検索レイテンシーの急上昇をトラブルシューティングするにはどうすればよいですか? 結論 Search Backpressure は、過剰な負荷を削減するリアクティブなメカニズムで、アドミッションコントロールは、ノードの容量を超えるリクエスト数を制限するプロアクティブなメカニズムです。 この2つは協調して、OpenSearch クラスタの全体的な回復力を高めます。 Search Backpressure は OpenSearch で利用できます。私たちは常に 外部からのコントリビューション を歓迎しています。 まずはじめに、 RFC を参照してください。 翻訳は Solutions Architect 深見が担当しました。 著者について Ketan Verma は、Amazon OpenSearch Service で働くシニアソフトウェア開発エンジニアです。大規模分散システムの構築、パフォーマンスの改善、シンプルな抽象化による複雑なアイデアの単純化に情熱を注いでいます。仕事外では、読書を楽しみ、自宅バリスタのスキルを磨いています。 Suresh N S は、Amazon OpenSearch Service で働くシニアソフトウェア開発エンジニアです。大規模分散システムの問題解決に情熱を注いでいます。 Pritkumar Ladani は、Amazon OpenSearch Service で働く SDE-2 です。オープンソースソフトウェア開発への貢献を好み、分散システムに情熱を注いでいます。アマチュアのバドミントン選手でもあり、トレッキングを楽しんでいます。 Bukhtawar Khan は、Amazon OpenSearch Service で働くプリンシパルエンジニアです。 分散システムや自律システムの構築に興味があります。 OpenSearch のメンテナーであり、アクティブにコントリビュートしています。
このブログは、 Enhance resiliency with admission control in Amazon OpenSearch Service を翻訳したものです。 OpenSearch は、リアルタイムアプリケーションモニタリング、ログ分析、ウェブサイト検索など、幅広いユースケースで使用される分散型のオープンソースの検索と分析スイートです。 Amazon OpenSearch Service は、大規模な OpenSearch クラスターを安全に展開し運用することを容易にするマネージドサービスです。Amazon OpenSearch Service は、ユースケースに合わせた幅広いクラスター構成を提供します。2021 年に、 自動メモリ管理 の機能を Auto-Tune の下でリリースしました。Auto-Tune は、Amazon OpenSearch Service の適応型リソース管理システムで、リクエストを継続的にモニタリングし、効率とパフォーマンスを向上させるためにクラスターリソースを最適化します。 本日 (2022 年 2 月)、Auto-Tune のためのアドミッションコントロールのリリースを発表できることをうれしく思います。Amazon OpenSearch Service のアドミッションコントロールは、ノードが負荷を受けたときに、REST レイヤーで新規に受信するリクエストを早期に制限することで、OpenSearch クラスターの全体的な回復力を強化します。このメカニズムにより、ノード障害の可能性と、クラスターへの連鎖的な影響を防ぐことができます。 アドミッションコントロールの概要 アドミッションコントロールは、クラスターの状態に基づいてトラフィックを調整するレバーのように機能します。 予測されたリソース使用量に基づいて、OpenSearch へのリクエストごとにトークンを割り当てることによってこの機能は実現されます。 プロセスが完了すると、トークンが解放されます。 すべてのトークンが取得された後、ノードへの追加のリクエストはトークンが再びリクエスト処理に利用できるようになるまで “too many requests” という例外でスロットリングされます。 場合によっては、管理者はアドミッションコントロールを利用して、シャードが割り当てられるなどの特定の条件が満たされるまでトラフィックを完全にシャットダウンし、頻繁なノードドロップを防ぐことができます。 アドミッションコントロールはノードのゲートキーパーであり、ノードの現在のキャパシティに基づいてノードに処理されるリクエスト数を制限します。 アドミッションコントロールは、Amazon OpenSearch Service ドメインが、トラフィックの定常的な増加や急増によって過負荷になるのを防ぎます。 リソースの状況を認識する機能を持っているため、受信リクエストのコスト(リクエストペイロードのコンテンツ長)とノードのその時点での状態(Java 仮想マシン(JVM)の全体)に基づいてクラスターを調整します。 この認識機能により、ノード上でのリアルタイムかつ状態ベースのアドミッションコントロールが可能になります。 デフォルトでは、JVM memory pressure とリクエストサイズのしきい値が超えた場合、アドミッションコントロールが _search リクエストと _bulk リクエストをスロットリングします。 JVM memory pressure のしきい値 アドミッションコントロールは JVM memory pressure の現在の状態を追跡し、事前に設定された JVM memory pressure のしきい値に基づいて受信リクエストをスロットリングします。 このしきい値を超えると、ノード上のメモリが解放され memory pressure がしきい値を下回るまで、すべての設定された _search リクエストと _bulk リクエストがスロットリングされます。 リクエストサイズのしきい値 特定のリクエストのサイズは、そのコンテンツ長によって決定されます。 アドミッションコントロールは実行中のリクエストを追跡し、このコンテンツ長に基づいてすべてのリクエストにトークンを割り当てます。 その後、実行中のリクエストの集計サイズが事前に設定されたしきい値を超えると、メモリ使用量に基づいて受信したリクエストをスロットリングします。 すべての新しい _search リクエストと _bulk リクエストは、処理中のリクエストが完了するまでスロットルされ、新しい リクエストで占有されるクォータを放棄します。 次の図は、このプロセスを示しています。 Auto-Tuneの仕組み Auto-Tune は、OpenSearch クラスターからのパフォーマンスと使用状況のメトリクスを使用して、クラスターの速度と安定性を改善するためのメモリ関連の構成変更を提案します。 Amazon OpenSearch Service コンソールでその推奨事項を確認できます。 アドミッションコントロールは非破壊的な変更であり、ノードを再起動することなく変更を適用できることを意味します。 アドミッションコントロールの事前定義されたリクエストサイズの 10% というしきい値は、ほとんどのユースケースを満たします。 しかし、Auto-Tune は現在、システム上で占有されている JVM の量に基づいて、デフォルトのしきい値を通常 5-15% の間で動的に増減できるようになりました。 Auto-Tune を有効にすると、リクエストサイズのしきい値の自動調整がデフォルトで有効になります。 Auto-Tune は現在、JVM メモリプレッシャーのしきい値のチューニングを行いません。 アドミッションコントロールの監視 Amazon OpenSearch Service は Amazon CloudWatch に対して、 AutoTuneSucceeded と AutoTuneFailed の 2 つの Auto-Tune メトリクスを送信します。 各メトリクスには、 AutotuningType と呼ばれるサブカテゴリが含まれており、これは問題の特定のタイプの変更を示します。 アドミッションコントロールは、 ADMISSION_CONTROL_TUNING と呼ばれる新しいタイプを追加します。 CloudWatch コンソールの メトリクス ページで、 ES/OpenSearchService を選択してください。 次に、 AutotuningType、ClientId、DomainName、TargetId を選択してください。 AutotuningType で ADMISSION_CONTROL_TUNING に絞り込みます。 結論 アドミッションコントロールは、リクエストが多すぎる場合や、 JVM の使用率が高くなりしきい値を超えた場合に、 _search および _bulk リクエストを要求ベースで拒否することにより、ノードが次の要因によって生じる障害の連鎖的影響を受けるのを防ぎます: トラフィックの急増 – ノード全体での使用状況が急速に蓄積する要求トラフィックの突発的な急増やスパイク シャード分散の偏り – シャードの不適切な分散により、ホットスポットやボトルネックが発生し、全体的なパフォーマンスに影響する 低速なノード – ディスク、ネットワークボリュームなどのハードウェアの劣化またはソフトウェアのバグにより、データノード全体の速度が低下する Amazon OpenSearch Service とその機能に関する、さらにエキサイティングな更新情報にご期待ください。 翻訳は Solutions Architect 深見が担当しました。 著者について Mital Awachat は、Amazon Web Services の Amazon OpenSearch Service で働く SDE-II です。 Saurabh Singh は、Amazon Web Services で AWS OpenSearch に携わるシニアソフトウェアエンジニアです。データ検索と大規模分散システムに関連する問題の解決に情熱を注いでいます。OpenSearch への積極的なコントリビューターです。 Ranjith Ramachandra は、Amazon Web Services の Amazon OpenSearch Service で働くエンジニアリング・マネージャーです。 Bukhtawar Khan は、Amazon OpenSearch Service で働くシニアソフトウェアエンジニアです。分散システムや自律システムに興味があります。OpenSearch に積極的に貢献しています。
みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 早いもので1月も残り数日になりましたがいかがお過ごしでしょうか? 前回もご紹介したAWS re:Invent Recap インダストリー編(業界ごと)がいよいよ明日から始まります。申込まだの方がいらっしゃればお忘れ無く。 – AWS re:Invent Recap – インダストリー編 2024 年 1 月 30 日(火)〜 2 月 1 日(木) – AWS re:Invent Recap – ソリューション編 2024 年 2 月 6 日(火)〜 9 日(金) それでは、先週の主なアップデートについて振り返っていきましょう。 2024年1月22日週の主要なアップデート 1/22(月) Amazon ECS Service Connect introduces support for automatic traffic encryption with TLS Certificates Amazon ECS Service Connectでサービス間通信の暗号化(TLS)がサポートされました。この機能はAWS Private Certificate AuthorityとECSが連携して証明書の発行や配布が、AWS Secrets Managerにより証明書のローテーションが自動化されています。詳細については ドキュメント もご確認ください。 Amazon RDS Custom for SQL Server supports SQL Server 2022 Amazon RDS Custom for SQL ServerがMicrosoft SQL Server 2022 CU9をサポートしました。SQL Server 2022 CU9については Microsoftのリリースノート を、RDS CustomでSQL Server 2022を利用する方法は こちらのブログ もご確認ください。 AWS Step Functions adds integration for 33 services including Amazon Q AWS Step FunctionsがAmazon Q, Amazon CloudFront KeyValueStoreなど新たに33のサービスをサポートをしました。同時に、すでにサポートするサービスのAPIも新たに1500以上が対応されています。今回の追加はAWS Step Functions が利用できるすべてのリージョンで利用可能ですが、呼び出されるサービスと API アクションは、対象サービスの提供リージョンに準じるので こちら でご確認ください。 1/23(火) Amazon EC2 M7a, R7a instances now available in Asia Pacific (Tokyo) region Amazon EC2 M7a インスタンスと R7a インスタンスが東京リージョンで利用可能になりました。M7aとR7a インスタンスは第四世代AMD EPYC プロセッサ(Genoa)を搭載し、前世代のM6a インスタンス, R6a インスタンスと比較して最大50%高いパフォーマンスを実現します。 Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.29 Amazon EKS と Amazon EKS DistroでKubernetes 1.29がサポートされました。Kubernetes v1.29 の主な変更点の詳細については、 ブログ と Kubernetesのリリースノート を参照してください。 Amazon Inspector now supports CIS Benchmark assessments for operating systems in EC2 instances Amazon InspectorがEC2のオペレーティングシステムに対するCISベンチマークの評価に対応しました。前世代のInspector ClassicではCISペンチーマークの評価に対応していましたが、現行世代では対応予定のアナウンスのみでした。今回のアップデートによりCISベンチマークのためにClassicをご利用いただいていたお客様も現行で評価いただくことが可能になります。詳細は ドキュメント をご確認ください。 1/24(水) AWS Billing Conductor releases account-scoped custom line items AWS Billing Conductorで請求グループ内の任意のアカウントにカスタム明細項目を適用できるようになりました。カスタム明細項目はAWS Supportなどの料金やクレジットの割り振りを細かく設定できる機能で、これまでは請求グループ毎に適用することができました。この機能は北京、寧夏を除くAWSの全てのパブリックリージョンでご利用可能です。 1/25(木) Provisioned capacity for API limits now available in Amazon Cognito Amazon Cognitoが、より高いリクエスト制限を必要とするお客様向けに、プロビジョニング済みキャパシティーをサポートするようになりました。ユーザー認証、ユーザー作成などの9つのAPIカテゴリでリクエスト可能です。具体的なAPIに関しては ドキュメント をご確認ください。プロビジョニング済みキャパシティーは希望する1秒あたりのリクエスト数(RPS)の増分と期間 に基づいて課金されます。 Amazon IVS announces audio-only pricing for Low-Latency Streaming Amazon Interactive Video Service (Amazon IVS)に 音声コンテンツのみ の配信料金が設定されました。これまで、音声コンテンツのみ の配信はアドバンスド HD、アドバンスド SDでサポートされていましたが、料金はアドバンスド SDのレートが適用されていました。今回 音声コンテンツのみ の利用料金が設定され、アドバンスド HDの10分の1の価格で配信が可能になります。同時に 音声コンテンツのみ のサポートがベーシックチャンネルとスタンダードチャンネルに拡張されました。詳細についてはIVSの 料金ページ をご確認ください。(1/28 – 執筆時点では英語ページのみ反映されています。ご注意ください) 1/26(金) SageMaker Automatic Model Tuning now supports Delete API Amazon SageMaker 自動モデルチューニングでプログラム経由でチューニングジョブを削除するための DeleteHyperParameterTuningJob API が提供されました。これにより一覧表示や履歴管理の効率化や、ジョブ名の再利用が可能になります。このAPIはAmazon SageMaker 自動モデルチューニング が利用可能な全てのリージョンで利用可能です。詳細は ドキュメント もご確認ください。 オンラインカンファレンスの AWS Innovate – AI/ML and Data Edition が2/22(木)に開催されます。「生成AI 」「AI/MLプラットフォーム」「ビジネスユースケース」のトラック、16のセッションに加え、いつでも利用可能なオンデマンド形式のハンズオン提供されます。ぜひご登録ください! それでは、また来週! ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )
本ブログ記事は Flexible Compute を担当する プリンシパルソリューションアーキテクトの Ahmed Nada と Amazon EC2 Auto Scaling を担当する プリンシパルプロダクトマネージャーの Kevin OConnor による共著です。 Amazon Web Services (AWS) を利用する世界中のお客様は Amazon EC2 Auto Scaling を使用して、自身のワークロードのための Amazon Elastic Compute Cloud (Amazon EC2) キャパシティをプロビジョニングし、スケールさせ、管理しています。新しい EC2&nbsp; Amazon Machine Images (AMIs) のデプロイ、EC2 インスタンスタイプの変更、自身のコードの最新化を確実に実施するために Amazon EC2 Auto Scaling インスタンス更新を利用しています。 現在、EC2 Auto Scaling はインスタンスの置き換えが発生する要因によって「終了する前に起動(launch before terminate)」や「終了してから起動(terminate and launch)」という振る舞いをしています。EC2 Auto Scaling を利用するお客様からは、アクティブなインスタンスが置き換えられることによる潜在的な中断を最小限にするために、新しいインスタンスの起動を今まで以上に制御できるようにしたいという声を頂いてきました。こういった要望に対応する Amazon EC2 Auto Scaling のインスタンスメンテナンスポリシーを導入できることを嬉しく思います。この機能は、お客様が EC2 インスタンスの置き換えプロセスをより細かく制御できるようにし、Amazon EC2 のコストを最小限に抑えながら、パフォーマンスの優先順位と運用に合った方法でインスタンスを置き換えられるようにする拡張機能です。 本ブログ記事では、インスタンスメンテナンスポリシーを設定し、Amazon EC2 Auto Scaling グループで使用する様々な方法を紹介します。 背景 AWS は、Amazon EC2 キャパシティを管理するプロセスを簡素化することを目的として、2009 年に Amazon EC2 Auto Scaling をローンチしました。それ以来、 予測スケーリング 、 属性ベースのインスタンスタイプの選択 、 ウォームプール などの高度な機能の導入による改善を続けてきました。 Amazon EC2 Auto Scaling は基本機能の 1 つとして、インスタンスの状態、 Amazon EC2 スポットインスタンス の中断、インスタンスの更新オペレーションへの応答、によってインスタンスを置き換えます。インスタンスの置き換え機能により、Amazon EC2 Auto Scaling グループ内の正常で高性能な EC2 インスタンス群を維持できます。状況によっては、代替インスタンスを起動する前にインスタンスを終了するとパフォーマンスに影響が出たり、最悪の場合、アプリケーションのダウンタイムが発生したりする可能性があります。要件がどのようなものであれ、インスタンスメンテナンスポリシーにより、特定のニーズに合わせてインスタンスの置き換えプロセスを微調整できます。 概要 インスタンスメンテナンスポリシーにより、最小正常率 ( MinHealthyPercentage ) と最大正常率 ( MaxHealthyPercentage ) という 2 つの新しい Amazon EC2 Auto Scaling グループ設定が追加されています。これらの値は、インスタンスの置き換え時に正常で実行中の状態でなければならないグループの希望容量の割合を表します。 MinHealthyPercentage の値は 0 ~ 100%、 MaxHealthyPercentage の値は 100 ~ 200% の範囲です。これらの設定は、 ヘルスチェックベースの置き換え 、 インスタンスの最大存続期間 、 EC2 スポットキャパシティの再調整 、 アベイラビリティーゾーンの再調整 、インスタンス購入オプションの再調整、 インスタンスの更新 など、インスタンスの置き換えにつながるすべてのイベントに適用されます。また、特定のデプロイユースケースに合わせて、インスタンスの更新操作において、グループレベルのインスタンスメンテナンスポリシーを上書きすることもできます。 インスタンスメンテナンスポリシーを使用しない場合、Amazon EC2 Auto Scaling グループはインスタンスを置き換えるときに前述の動作を使用します。インスタンスメンテナンスポリシーの MinHealthyPercentage を 100% に、 MaxHealthyPercentage を 100% より大きい値に設定すると、Amazon EC2 Auto Scaling グループはまず代替インスタンスを起動し、それらが使用可能になるのを待ってから、置き換え対象のインスタンスを終了します。 インスタンスメンテナンスポリシーの設定 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、AWS SDK、 AWS CloudFormation 、および Terraform を使用して、新規または既存の Amazon EC2 Auto Scaling グループにインスタンスメンテナンスポリシーを追加することができます。 コンソールで Amazon EC2 Auto Scaling グループを作成または編集する場合、インスタンスメンテナンスポリシーの置き換え動作を定義する 4 つのオプションが表示されます。これらのオプションには、Amazon EC2 Auto Scaling サービスが現在使用しているデフォルトのインスタンス置き換え設定を維持できる ポリシーなし というオプションが含まれます。 図 1: 「Auto Scaling グループの作成」ウィザード内のインスタンスメンテナンスポリシー機能の画面 アプリケーションの可用性を高めるためのインスタンスメンテナンスポリシーの使用 Amazon EC2 Auto Scaling グループキャパシティの可用性を優先したい場合は、 終了する前に起動 ポリシーを選択するのが適切です。このポリシー設定は、グループの容量を一時的に増やすことで、置き換え操作中に新しいインスタンスを起動します。Amazon EC2 コンソールにて、置き換え方法として 終了する前に起動 を選択した後、必要な MaxHealthyPercentage 値を設定することで、インスタンスの置き換え中に追加で起動するインスタンスの数を決定します。 例えば、インスタンスの置き換え時に可用性を優先する必要があるワークロードを管理している場合は、 MinHealthyPercentage を 100% に設定して 終了する前に起動 ポリシータイプを選択します。 MaxHealthyPercentage を 150% に設定すると、Amazon EC2 Auto Scaling は、置き換え対象のインスタンスを終了する前に、代替インスタンスを起動します。必要な可用性を確保するために、置き換え中は希望する容量がグループの最大容量を超えて 50% 増加するときもあります。次の図のグラフは、 終了する前に起動 ポリシーでインスタンスの更新操作がどのように動作するかを示しています。 図 2: 終了する前に起動ポリシーを使用したインスタンス置き換えプロセス インスタンス更新時のインスタンスメンテナンスポリシー上書き インスタンスメンテナンスポリシー設定はすべてのインスタンス置き換え操作に適用されますが、新しいインスタンスの更新操作の開始時に上書きすることができます。インスタンスメンテナンスポリシーの上書きは、不適切なコードがデプロイされた際に、ダウンタイムなしで置き換える必要があるような場合に役立ちます。問題のあるコードを含むインスタンスを終了する前に、まったく新しいグループ分のインスタンスを稼働させるようにインスタンスメンテナンスポリシーを設定できます。この場合、インスタンスの更新操作の MaxHealthyPercentage を 200% に設定すると、不正コードの問題に迅速に対処するために、1 サイクルで置換が行われます。 MaxHealthyPercentage を 200% に設定すると、インスタンス置き換え方法の設定が Auto Scaling Group の最大キャパシティ値を超えることが許容されますが、アカウントレベルのクォータによる制約を受けるため、この機能を適用する際には必ずこれらを考慮に入れてください。次の図は、この操作が視覚的にどのように動作するかを示しています。 図 3: 新しいデプロイを高速化するように設定されたポリシーを使用したインスタンス置き換えプロセス 置き換えとデプロイ時のコスト管理 終了してから起動 ポリシーオプションを使用すると、インスタンス置き換え時のコスト管理を優先できます。このポリシータイプを設定すると、Amazon EC2 Auto Scaling は既存のインスタンスを終了し、置き換えプロセス中に新しいインスタンスを起動します。 終了してから起動 ポリシーを設定するには、 MinHealthyPercentage を指定して容量がどの程度低下してもよいか指定し、 MaxHealthyPercentage を 100% に設定します。この設定では、Auto Scaling グループの容量を、希望する容量もしくはそれ以下の状態に保ちます。 次の図は、 MinHealthyPercentage を 80% に設定したときの動作を示しています。インスタンスの置き換えプロセスにて、Auto Scaling グループはグループの正常な容量を一時的に 80% に減らすことで、最初にインスタンスの 20% を終了し、すぐに代替インスタンスを起動します。グループは、新しいインスタンスが設定されたヘルスチェックを通過して ウォームアップ が完了するのを待ってから、残りのインスタンス置き換えのバッチに進みます。 図 4: 終了して起動ポリシーを使用したインスタンス置き換えプロセス MinHealthyPercentage と MaxHealthyPercentage の値の違いは、インスタンス置き換えプロセスのスピードに影響することに注意してください。上の図では、Amazon EC2 Auto Scaling グループが各サイクルで 20% のインスタンスを置き換えています。 MinHealthyPercentage と MaxHealthyPercentage の間のギャップが大きいほど、置き換え処理は速くなります。 最大限の柔軟性を実現するカスタムポリシーの使用 MinHealthyPercentage と MaxHealthyPercentage の値を任意に設定できる カスタム動作 オプションも採用することもできます。このポリシータイプを使用すると、独自のニーズに合わせてインスタンスのメンテナンスポリシーを調整でき、置き換え動作を微調整したり、Amazon EC2 Auto Scaling グループ内のインスタンスの容量を制御したりすることができます。 置き換え処理における端数計算はどのようになるのか? Amazon EC2 Auto Scaling は、インスタンスの置き換えを実行するときは常に可用性を優先します。インスタンスメンテナンスポリシーが設定されている場合、Amazon EC2 Auto Scaling は MinHealthyPercentage を下回ることよりも、新しいインスタンスの起動を優先します。たとえば、希望容量が 10 インスタンスの Amazon EC2 Auto Scaling グループで、 MinHealthyPercentage が 99% に設定され、 MaxHealthyPercentage が 100% に設定されているインスタンスメンテナンスポリシーでは、1 つのインスタンス容量も減らすことはできません。そのため、Amazon EC2 Auto Scaling は終了前に起動することを優先し、置き換えが必要なインスタンスを終了する前に 1 つの新しいインスタンスを起動します。 インスタンスメンテナンスポリシーの設定は必須ではありません。インスタンスメンテナンスポリシーを使用するように Amazon EC2 Auto Scaling グループを設定しなければ、Amazon EC2 Auto Scaling グループの既存のインスタンス置き換えプロセスの動作に変更はありません。 CloudFormation または Terraform テンプレートを使用して、グループレベルのインスタンスメンテナンスポリシーを設定できます。テンプレート内で MinHealthyPercentage と MaxHealthyPercentage の両方の値を設定して、Amazon EC2 Auto Scaling グループの要件に沿ったインスタンス置き換え動作を決定する必要があります。 結論 本ブログ記事では、Amazon EC2 Auto Scaling グループの新しいインスタンスメンテナンスポリシー機能を紹介し、使用方法の例を示しました。インスタンスメンテナンスポリシー設定はすべてのインスタンス置き換えプロセスに適用され、インスタンスの更新機能の実行毎に設定を上書きすることもできます。インスタンスメンテナンスポリシーを設定することで、Amazon EC2 Auto Scaling グループ内のインスタンスの起動とライフサイクルを制御し、アプリケーションの可用性を高め、手動による介入を減らし、Amazon EC2 の使用に関するコスト管理を改善できます。 この機能の詳細と使用を開始する方法については、Amazon EC2 Auto Scaling ユーザーガイド を参照してください。 翻訳は Partner Solutions Architect 塩飽が担当しました。原文は こちら です。
昨今のデータドリブンな世界では、組織は拡大し続けるデータエコシステムから貴重な洞察を管理し、抽出する上で、前例のない課題に直面しています。データ資産とユーザーの数が増えるにつれ、データ管理とガバナンスに対する従来のアプローチではもはや間に合いません。顧客は現在、権限管理を分散化するためのより高度なアーキテクチャを構築しています。これにより、中央のガバナンスチームに律速されることなく、個々のユーザーグループが独自のデータ製品を構築して管理できるようになります。 AWS Lake Formation のコア機能の1つは、 AWS Glue Data Catalog のデータベース、テーブル、カラムなどのリソースのサブセットに対する権限をデータスチュワードに委任することです。これにより、誰がリソースにアクセスできるかを決定できるようになり、データレイクの権限管理を分散化できます。 Lake Formation にはデータスチュワードが 独自の Lake Formation タグを作成してアクセス権を管理できる機能 が追加されました。 Lake Formation タグベースアクセス制御 (LF-TBAC) は、属性に基づいて権限を定義する認証戦略です。 Lake Formation ではこれらの属性を LF タグと呼びます。 LF-TBAC は、データカタログリソースが多数ある場合に Lake Formation の権限を付与する方法として推奨されます。 LF-TBAC は、名前付きリソース方式よりスケーラブルで、権限管理のオーバヘッドも少なくて済みます。 この記事では、 LF タグの作成、管理、権限付与をデータスチュワードに委任するプロセスについて説明します。 Lake Formation は AWS アナリティクス全体にわたって大規模なユーザーのセキュリティ管理とガバナンスを簡素化することで、これらの高度なアーキテクチャの基盤として機能します。 Lake Formation は AWS アカウントかんの安全な共有と、権限を拡張できるタグベースのアクセス制御を提供することでこれらの課題に対処するように設計されています。特性とプロパティに基づいてデータ資産にタグを割り当てることにより、組織は特定のデータ属性に合わせたアクセス制御ポリシーを実装できます。これにより、権限のある個人またはチームのみがドメインに関連するデータにアクセスして操作できるようになります。例えば、顧客はデータ資産に「Confidential」というタグを付け、機密データにアクセスすべきユーザーにのみその LF タグへのアクセスを許可することができます。タグベースのアクセス制御は、データセキュリティとプライバシーを強化するだけでなく、効率的なコラボレーションとナレッジシェアリングを促進します。 単一アカウント、ハブアンドスポーク、中央ガバナンスによるデータメッシュなど、どのアーキテクチャを選択したとしてもデータガバナンスにおけるプロデューサーの自律性と分散型のタグ作成および委任の必要性は最も重要です。一元的なタグ作成とガバナンスのみに依存していると、ボトルネックが生じ、アジリティが妨げられ、イノベーションが阻害される可能性があります。プロデューサーとデータスチュワードに、特定のドメインに関連するタグを作成および管理する自律性を付与することで、組織はプロデューサーチーム間のオーナーシップと説明責任の意識を育むことができます。この分散型アプローチにより、変化する要件に迅速に適応して対応できます。この方法論は、組織が中央ガバナンスとプロデューサーオーナシップのバランスを取るのに役立ち、ガバナンスの向上、データ品質の向上、そしてデータ民主化につながります。 Lake Formation はこれらの課題に対処するためのタグ委任機能を発表しました。この機能により、 Lake Formation の管理者は AWS Identity and Access Management (IAM) ユーザーとロールにタグの作成、関連付け、そしてタグ表現の管理を行う権限を与えることができます。 ソリューションの概要 この記事では、複数のグループが私用している中央データレイクを持つ組織の例を検討します。このケースでは2人のペルソナがいます。1人は Lake Formation の管理者 LFAdmin で、データレイクを管理し、様々なグループにオンボーディングを行います。もう一方は組織内のセールスグループのリソースを所有し管理も行うデータスチュワード LFDataSteward-Sales です。ここでのゴールはデータスチュワードに権限を付与して、 LF タグを使用して所有するリソースに権限を付与できるようにすることです。さらに、組織には Confidentiality と Department と呼ばれる共通 LF タグがあり、データスチュワードはこれらを使用できます。 次の図はソリューションを実装するためのワークフローを示しています。 大まかな手順は以下の通りです。 LF タグを作成する権限を Lake Formation 管理者ではないユーザー用の IAM ロール LFDataSteward-Sales に付与します。 組織の共通の LF タグを LFDataSteward-Sales ロールに関連付ける権限を付与します。 LFDataSteward-Sales ロールを使って新しい LF タグを作成します。 LFDataSteward-Sales ロールを使って新しい一般的な LF タグをリソースに関連づけます。 LFDataSteward-Sales ロールを使って他のユーザーに権限を付与します。 前提条件 このチュートリアルは以下のものが必要です。 AWS アカウント Lake Formation の使い方と Lake Formation が一連のテーブルに対する権限を管理できるようにする方法に関する知識 Lake Formation 管理権限を有する IAM ロール。この記事では、その IAM ロールを LFAdmin とする。 LFAdmin によって作成された2つの LF タグ Confidentiality をキーとするバリュー PII と Public Department をキーとするバリュー Sales と Marketing 組織のデータスチュワードである IAM ロール。この記事では、その IAM ロールを LFDataSteward-Sales とする。 データスチュワードは少なくとも1つのデータベースに対してスーパーユーザーのアクセス権を持っている必要があります。この記事では、データスチュワードは3つのデータベース( sales-ml-data 、 sales-processed-data 、 sales-raw-data )へのアクセス権を持っています。 データスチュワードが LF タグを使用する権限を付与するユーザーとしての役割を果たす IAM ロール。この記事では、その IAM ロールを LFAnalysts-MLScientist とします。 データスチュワードに LF タグを作成できるよう権限を付与する 以下の手順を実行して LFDataSteward-Sales に LF タグを作成する権限を付与します。 LFAdmin ロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の LF-Tags and permissions を選択します。 LF-Tags では、 LFAdmin としてログインしているためアカウント内で作成されたすべてのタグを確認できます。 Confidentiality の LF タグと Department の LF タグ、そしてそれぞれのタグに指定できるバリューが表示されます。 LF-Tag creators タブで Add LF-Tag creators を選択します。 IAM users and roles では LFDataSteward-Sales の IAM ロールを指定します。 Permission では Create LF-Tag を選択します。 このデータスチュワードが他のユーザーに LF タグの作成権限を付与できるようにするには Grantable permission で Create LF-Tag を選択します。 Add を選択します。 LFDataSteward-Sales の IAM ロール独自の LF タグを作成する権限が付与されるようになりました。 一般的な LF タグが使えるようデータスチュワードに権限を付与する ここで Confidentiality と Department タグを使ってタグ付ける権限をデータスチュワードに付与したいと思います。以下の手順を実施します。 LFAdmin ロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の LF-Tags and permissions を選択します。 LF-Tag permissions タブで Grant permissions を選択します。 Permission type として LF-Tag key-value permission を選択します。 LF-Tag permission オプションは LF タグを変更または削除する権限を付与しますが、このユースケースでは適用されません。 IAM users and roles を選択し、 LFDataSteward-Sales の IAM ロールを指定します。 Confidentiality の LF タグではすべてのバリューを選択し、 Department の LF タグでは Sales のみを選択します。 Permissions では Describe 、 Associate 、 Grant with LF-Tag expression を選択します。 Grant permissions を選択します。 これにより、 LFDataSteward-Sales ロールは Confidentiality タグとそのすべてのバリューを使ってリソースにタグを付けることができ、 Department タグには Sales のバリューのみを使ってタグを付けることができるようになりました。 データスチュワードロールを使って新しい LF タグを作成する この手順では LFDataSteward-Sales のロールが独自の LF タグを作成する方法を示します。 LFDataSteward-Sales のロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の LF-Tags and permissions を選択します。 LF-Tags セクションには、 Confidentiality タグと、 Sales のバリューのみの Department タグが表示されます。データスチュワードとして、権限付与を簡単にするために独自の LF タグを作成したいと思います。 Add LF-Tag を選択します。 Key には Sales-Subgroups と入力します。 Values には DataScientists 、 DataEngineers 、 MachineLearningEngineers を入力します。 Add LF-Tag を選択します。 LF タグの作成者として、データスチュワードは自分が作成したタグに対する全ての権限を持っています。データスチュワードがアクセスできる全てのタグを見ることができます。 データスチュワードとして LF タグをリソースに関連付ける 機械学習エンジニアが sales-ml-data のリソースにアクセスできるように、先ほど作成した LF タグにリソースを関連付けます。 LFDataSteward-Sales ロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインで Databases を選択します。 sales-ml-data を選択し Action メニューから Edit LF-Tags を選択します。 以下の LF タグとバリューを追加します。 キーは Sales-Subgroups 、バリューは MachineLearningEngineers キーは Department 、バリューは analytics キーは Confidentiality 、バリューは Public Save を選択します。 データスチュワードとして LF タグを使って権限を付与する LF タグを使って権限を付与するためには、以下の手順を実施します。 LFDataSteward-Sales のロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の Data lake permissions を選択します。 Grant を選択します。 IAM users and roles を選択しアクセス権を付与する IAM プリンシパルを選択します(この例では Sales-MLScientist ロール)。 LF-Tags or catalog resources セクションで、 Resources matched by LF-Tags を選択します。 以下のタグ設定を入力します。 Department LF タグのバリューとして Sales Sales-Subgroups LF タグのバリューとして MachineLearningEngineers Confidentiality LF タグのバリューとして Public このロールは機械学習とデータサイエンスユーザーなので、データベースの管理とテーブル作成ができるように全ての権限を付与しようと思います。 Database permissions で Super を選択し、 Table permissions も Super を選択します。 Grant を選択します。 設定された LF-Tag expressions が表示されます。 ユーザーに付与された権限を検証する Amazon Athena を使ってアクセス権を確認するために、 Sales-MLScientist のロールとして Athena コンソールに移動します。 Sales-MLScientist のロールが sales-ml-data データベースと全てのテーブルにアクセスできるようになったことがわかります。このケースでは、テーブルは sales-report 1つのみ存在します。 クリーンアップ リソースをクリーンアップするために、以下を削除します。 この記事の内容に従って作成した IAM ロール 作成した LF タグ まとめ この記事では、分散型タグ管理のメリットと、新しい Lake Formation の機能がこれを実装するのにどのように役立つかについて説明しました。プロデューサーチームのデータスチュワードにタグ管理の権限を付与することで、組織は各自のドメイン知識を活用してデータの微妙な違いを効果的に把握できるようになります。さらに、データスチュワードに権限を付与すると、データスチュワードがタグ付けの主導権を握ることができ、正確性と関連性が確保されます。 この記事ではデータスチュワードに LF タグの作成や一般的な LF タグの使用許可を与えるなど、分散型の Lake Formation タグ管理に関連する様々な手順について説明しました。また、データスチュワードが独自の LF タグを作成し、タグをリソースに関連づけ、タグを使用して権限を付与する方法を示しました。 新しい分散型の Lake Formation タグ管理機能をぜひ試してみてください。詳細については、 Lake Formation tag-based access control をご参照ください。 本記事は、Ramkumar Nottath、Mert Hocanin による Decentralize LF-tag management with AWS Lake Formation を翻訳したものです。 翻訳はソリューションアーキテクトのJang Soohyeongが担当しました。
昨今のデータドリブンな世界では、様々なプラットフォーム間でデータを簡単に移動して分析できることが不可欠です。フルマネージド型のデータ統合サービスである Amazon AppFlow は AWS サービスと SaaS アプリケーション間のデータ転送を効率化する最前線に立ってきており、現在は Google BigQuery にも対応しています。このブログ記事では、Amazon AppFlowの Google BigQuery コネクタ がGoogle のデータウェアハウスから Amazon Simple Storage Service (Amazon S3) にデータを転送するプロセスを簡略化する手法と、マルチクラウドデータアクセスの民主化を含めたデータ専門家や組織にとっての大きなメリットについて解説します。 Amazon AppFlow の概要 Amazon AppFlow は Google BigQuery 、 Salesforce 、 SAP 、 Hubspot 、 ServiceNow などの SaaS アプリケーションと、 Amazon S3 や Amazon Redshift などの AWS サービスの間におけるデータの安全な転送を数回のクリックで実現できるフルマネージドなデータ統合サービスです。 Amazon AppFlow では、ほぼ全ての規模のデータフローを任意の頻度(定期実行、ビジネスイベントへの対応、オンデマンド)で実行できます。フィルタリングや検証などのデータ変換機能の設定だけで、すぐに使用できる豊富なデータをフローの一部として生成できます。 Amazon AppFlow では転送中のデータが自動的に暗号化され、 AWS PrivateLink と統合された SaaS アプリケーションではデータがパブリックなインターネットを通るのを制限できるため、セキュリティ上の脅威にさらされるリスクが軽減されます。 Google BigQuery コネクタのご紹介 Google BigQuery コネクタ は Google のデータウェアハウスの分析機能を利用し、 BigQuery からのデータを簡単に統合、分析、保存、または追加の処理を行い、実用的なインサイトに変換したいと考えている組織に可能性をもたらします。 アーキテクチャ Amazon AppFlow を使って Google BigQuery から Amazon S3 にデータを転送するアーキテクチャを確認してみましょう。 データソースを選択する: Amazon AppFlow でデータソースとして Google BigQuery を選択します。データを抽出するテーブルまたはデータセットを指定します。 フィールドマッピングと変換: Amazon AppFlow の直感的なビジュアルインターフェースを使ってデータ転送を設定します。必要に応じてデータフィールドをマッピングし、変換を適用してデータを要件に合わせることができます。 転送頻度:データ転送の頻度(毎日、毎週、毎月など)を設定できます。柔軟に設定でき、自動化に役立ちます。 送信先:データの送信先として S3 バケットを指定します。 Amazon AppFlow は効率的にデータを転送し、 Amazon S3 ストレージからデータにアクセスできるようにします。 消費: Amazon Athena を利用して Amazon S3 上のデータを分析します。 前提条件 このソリューションで使われるデータセットは合成患者集団シミュレータであり Apache License 2.0 に基づくオープンソースプロジェクトである Synthea により生成されるものです。 Amazon AppFlow と Google BigQuery アカウントの接続 この投稿では、 Google アカウント、適切な権限を持つ OAuth クライアント、および Google BigQuery データを利用します。 Amazon AppFlow から Google BigQuery にアクセスできるようにするには、事前に新しい OAuth クライアントを設定する必要があります。設定手順については、 Google BigQuery connector for Amazon AppFlow をご参照ください。 Amazon S3 の設定 Amazon S3 の全てのオブジェクトはバケットに保存されます。 Amazon S3 にデータを保存する前に、結果を保存する S3 バケットを作成する 必要があります。 Amazon AppFlow の結果を保存するための新しいS3バケットの作成 S3 バケットを作成するために、以下の手順を実施します。 Amazon S3 の AWS マネジメントコンソールから バケットを作成 をクリックします。 グローバルで一意の バケット名 を入力します(例: appflow-bq-sample )。 バケットを作成 をクリックします。 Amazon Athena の結果を保存するための新しい S3 バケットの作成 S3 バケットを作成するために、以下の手順を実施します。 Amazon S3 の AWS マネジメントコンソールから バケットを作成 をクリックします。 グローバルで一意の バケット名 を入力します(例: athena-results )。 バケットを作成 をクリックします。 AWS Glue データカタログのユーザーロール( IAM ロール) フローとともに転送されるデータをカタログ化するためには、 AWS Identity and Access Management (IAM) における適切なユーザーロールが必要です。このロールを Amazon AppFlow に提供して、 AWS Glue Data Catalog 、テーブル、データベース、およびパーティションを作成するために必要なアクセス権限を付与します。 必要なアクセス権限を持つ IAM ポリシーの例については、 Identity-based policy examples for Amazon AppFlow をご参照ください。 デザインのチュートリアル それでは、実際のユースケースから Amazon AppFlow の Google BigQuery コネクタがどのように動くかを見てみましょう。このユースケースでは、 Amazon AppFlow を使って Google BigQuery からの履歴データを Amazon S3 にアーカイブし長期保存と分析を行います。 Amazon AppFlow の設定 Google アナリティクスから Amazon S3 にデータを転送するための新しい Amazon AppFlow フローを作成します。 Amazon AppFlow コンソール で フローを作成 をクリックします。 フロー名を入力します(例: my-bq-flow )。 必要な タグ を追加します。例えば、 キー には env 、 値 には dev と入力します。 次へ をクリックします。 送信元名 で Google BigQuery を選択します。 新規接続を作成 をクリックします。 OAuth クライアント ID と クライアントシークレット 、そして接続名を入力します(例: bq-connection )。 ポップアップウィンドウで、 amazon.com が Google BigQuery API にアクセスすることを許可するかと聞かれたら許可を選択します。 Google BigQuery オブジェクトを選択 で テーブル を選択します。 Google BigQuery サブオブジェクトを選択 で BigQuery プロジェクト名 を選択します。 Google BigQuery サブオブジェクトを選択 で データベース名 を選択します。 Google BigQuery サブオブジェクトを選択 で テーブル名 を選択します。 送信先名 で Amazon S3 を選択します。 バケットの詳細 では、前提条件として Amazon AppFlow の結果を保存するために作成した Amazon S3 バケットを選択します。 プレフィックス として raw を入力します。 次に、 AWS Glue データカタログ の設定を指定して、さらに分析するためのテーブルを作成します。 前提条件で作成した ユーザーロール ( IAM ロール)を選択します。 新しい データベース を作成します(例: healthcare )。 テーブルプレフィックス を指定します(例: bq )。 オンデマンドで実行 を選択します。 次へ をクリックします。 手動でフィールドをマッピングする を選択します。 Allergies テーブルから 送信元フィールド名 として次の6つのフィールドを選択します。 Start Patient Code Description Type Category フィールドを直接マッピングする を選択します。 次へ をクリックします。 フィルターを追加する セクションで、 次へ をクリックします。 フローを作成 をクリックします。 フローの実行 新しいフローを作成したら、オンデマンドで実行できます。 Amazon AppFlow コンソール で、 my-bq-flow を選択します。 フローを実行 をクリックします。 このチュートリアルでは、分かりやすいようにジョブのオンデマンド実行を選択してください。実際には、スケジュールされたジョブを選択して、新しく追加されたデータのみを定期的に抽出できます。 Amazon Athena を経由したクエリ オプションの AWS Glue データカタログ設定を選択すると、データカタログが作成され Amazon Athena からクエリを実行できるようになります。 クエリ結果の保存場所を設定するように求められたら、 設定 タブに移動して 管理 を選択します。 設定を管理 で、前提条件で作成したAthena結果バケットを選択し、 保存 を選択します。 Amazon Athena コンソール でデータソースとして AWSDataCatalog を選択します。 次に、 データベース として healthcare を選択します。 これで AWS Glue クローラーによって作成されたテーブルを選択してプレビューできます。 次のようなカスタムクエリを実行し上位10のアレルギーを検索することもできます。 注 :以下のクエリから、テーブル名(ここでは bq_appflow_mybqflow_1693588670_latest )を実際生成されたテーブル名に置き換えてください。 SELECT type, category, "description", count(*) as number_of_cases FROM "healthcare"."bq_appflow_mybqflow_1693588670_latest" GROUP BY type, category, "description" ORDER BY number_of_cases DESC LIMIT 10; 実行 をクリックします。 クエリの結果として件数で上位10のアレルギーが表示されます。 クリーンアップ 料金が発生しないようにするには、次の手順を実行して AWS アカウント内のリソースをクリーンアップしてください。 Amazon AppFlow コンソールのナビゲーションペインで フロー を選択します。 フローのリストから、 my-bq-flow を選択し削除をクリックします。 削除と入力しフローを削除します。 ナビゲーションペインから 接続 を選択します。 コネクタから Google BigQuery を選択し、 bq-connector を選択した上で削除をクリックします。 削除と入力し接続を削除します。 IAM コンソールのナビゲーションペインから ロール を選択し、 AWS Glue クローラーのために作成したロールを選択した上で削除をクリックします。 Amazon Athena コンソールを開きます。 AWS Glue クローラーが作成した healthcare データベース配下のテーブルを削除します。 healthcare データベースを削除します。 Amazon S3 コンソールで Amazon AppFlow の結果バケットを検索し、 空にする をクリックしてバケット内のオブジェクトを削除ます。その後、バケットを削除します。 Amazon S3 コンソールで Amazon Athena の結果バケットを検索し、 空にする をクリックしてバケット内のオブジェクトを削除ます。その後、バケットを削除します。 Google BigQuery リソースを含むプロジェクトを削除して Google アカウントのリソースをクリーンアップします。 クリーンアップ の手順に従ってリソースを削除します。 まとめ Amazon AppFlow の Google BigQuery コネクタは、 Google のデータウェアハウスから Amazon S3 へのデータ転送プロセスを効率化します。この統合により、分析、機械学習、アーカイブ、長期保存が簡素化され、 Google と AWS 両方のプラットフォームの分析機能を活用しようとしているデータ専門家や組織に大きなメリットをもたらします。 Amazon AppFlow を利用すると、データ統合の煩雑さが解消され、データから実用的な洞察を引き出すことに集中できます。履歴データをアーカイブする場合でも、複雑な分析を行う場合でも、機械学習のためのデータを準備する場合でも、このコネクタがプロセスを簡素化し、幅広いデータ専門家が利用できるようにします。 Amazon AppFlow を利用して Google BigQuery から Amazon S3 にデータを転送する方法に興味がある場合は、こちらの ビデオチュートリアル をご覧ください。このチュートリアルでは、接続の設定からデータ転送フローの実行までの全体のプロセスを説明します。 Amazon AppFlow のより詳細な情報は こちらのページ をご確認ください。 本記事は、Kartikay Khator、Kamen Sharlandjiev による Simplify data transfer: Google BigQuery to Amazon S3 using Amazon AppFlow を翻訳したものです。 翻訳はソリューションアーキテクトのJang Soohyeongが担当しました。
いつものことですが、1月22日週、 Amazon Web Services (AWS) の世界では多くのことが起こりました。また、世界中で開催されている AWS コミュニティ のイベントやイニシアチブにも興奮を隠せません。一緒に見ていきましょう! 1月22日週のリリース 私が注目したリリースを以下に記載しました。 Amazon Elastic Container Service (Amazon ECS) がマネージドインスタンスドレインのサポートを開始&nbsp;– マネージドインスタンスドレインでは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにデプロイされたワークロードを安全に停止して、終了していない他のインスタンスに再スケジュールすることで、正常にシャットダウンできます。この新機能を使用すると、新しい AMI バージョンのデプロイなどのインフラストラクチャのメンテナンスが合理化され、ワークロードを中断せずにインスタンスをシャットダウンするカスタムソリューションが不要になります。詳細については、Nathan の AWS Containers のブログ 投稿を参照してください。 Amazon Relational Database Service (Amazon RDS) for MySQL がマルチソースレプリケーションのサポートを開始 –&nbsp;マルチソースレプリケーションを使用すると複数の RDS for MySQL データベースインスタンスを 1 つのターゲットデータベースインスタンスのソースとして設定できます。この機能により、単一のターゲットへの複数のシャードのマージ、分析を目的としたデータの統合、単一の RDS for MySQL インスタンス内での長期バックアップの作成などのタスクが容易になります。詳細については、「 Amazon RDS for MySQL ユーザーガイド 」を参照してください。 Amazon EMR Studio での作成エクスペリエンスが簡素化され、起動時間が向上 – EMR Studio を作成するためのコンソール操作が簡素化され、インタラクティブなワークロードやバッチワークロードをデフォルト設定でより簡単に起動できるようになりました。起動時間が改善されたことで、EMR Studio ワークスペースを起動してノートブックでインタラクティブな分析を数秒で実行できるようになりました。詳細については、「 Amazon EMR ユーザーガイド 」を参照してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクト、プログラム、ニュース項目をいくつかご紹介いたします。 Amazon Bedrock を使ってニュースを要約 – 同僚の Danilo が、 Amazon Bedrock を使用して RSS または Atom フィードから最新のニュースを要約する アプリケーション を構築しました。このアプリケーションは AWS Lambda 関数としてデプロイされます。この関数は、RSS または Atom フィードから最新のエントリをダウンロードし、リンクされたコンテンツのダウンロード、テキストの抽出、そして要約の作成を行います。 AWS コミュニティビルダープログラム &nbsp;– AWS コミュニティビルダープログラムにご参加ください。 2024 年の応募締め切りは 1 月 28 日です 。AWS コミュニティビルダープログラムは、知識の共有と技術コミュニティとのつながりに熱心な AWS 技術愛好家に技術リソース、教育、ネットワーキングの機会を提供します。 AWS ユーザーグループ – AWS ユーザーグループ Yaounde Cameroon が 12 週間のワークショップチャレンジを開催しました。参加者は 12 週間にわたって、アーキテクチャ、セキュリティ、ストレージなど、AWS とクラウドコンピューティングのさまざまな側面を確認するとともに、スキルを磨いて知識を共有しました。このすばらしいイニシアチブの詳細については、 LinkedIn の投稿 を参照してください。 AWS オープンソースニュースと更新情報 – 私の同僚の Ricardo が 週刊のオープンソースニュースレター を執筆し、AWS コミュニティの新しいオープンソースプロジェクト、ツール、デモを紹介しています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Innovate: AI/ML and Data Edition – 2024 年 2 月 22 日に開催される アジアパシフィックおよび日本の AWS Innovate オンラインカンファレンス に登録して、人工知能 (AI) と機械学習 (ML) でイノベーションを生み出す方法を参照、検索、学習してください。3 か国語で提供される 50 以上のセッションから選択し、生成 AI ビルダー向けのテクニカルデモを実際に体験してください。 AWS コミュニティ re:Invent re:Caps –&nbsp;世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベント に参加して、AWS re:Invent の最新の発表をご確認ください。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 今週はここまでです。1月29日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –&nbsp; Antje この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。
アマゾン ウェブ サービス (AWS) は Amazon Bedrock を初めとした生成 AI サービスを提供しています。Amazon Bedrock では、Amazon の基盤モデルだけでなく、Anthropic、Stability AI、Meta といった代表的な生成 AI モデルプロバイダーの基盤モデルが利用可能です。一方で、日本語という言語の特殊性などへの対応のため、国内事業者により日本語特化の大規模言語モデル (LLM) の開発が進められています。AWS ジャパンは、 LLM 開発支援プログラム などを通じて、お客様にとってのモデルの選択肢を拡充する活動を行っています。この度、LLM を AWS 上で簡単にデプロイしたりファインチューニングできるサービスである Amazon SageMaker JumpStart において、Stability AI 社が開発した日本語 LLM である Japanese Stable LM Instruct Alpha 7B v2 が利用可能になりました。SageMaker JumpStart に日本語 LLM を掲載するのは、 rinna 社に続いて 2 社目の事例となります。今回のモデル登録も AWS ジャパンとしての活動から生まれました。 本記事では、SageMaker JumpStart を通じて Japanese Stable LM Instruct Alpha 7B v2 モデルを探して、ノーコード、および SageMaker Python SDK でデプロイする方法を解説します。 Japanese Stable LM Instruct Alpha 7B v2 とは Japanese Stable LM Instruct Alpha 7B v2 は、Stability AI Japan によって開発された 70 億パラメータを持つ大規模言語モデルです。Transformer モデルのデコーダーのみで構成される自己回帰言語モデルである、 Japanese Stable LM Base Alpha 7B の事前学習モデルをベースに構築されており、さらにさまざまな指示 (instruction) データセットを用いて微調整されています。指示データセットを用いた微調整により、テキスト生成、テキスト要約、質問応答など、さまざまなゼロショットおよび少数ショット (few-shot) の自然言語処理タスクを実行することができるようになっています。Apache License 2.0 の条項に従い、無料かつ商用利用可能でオープンなモデルであることも特徴です。 SageMaker JumpStart とは SageMaker JumpStart は、機械学習の開発運用のプロセスを加速させることができるハブのサービスです。SageMaker JumpStart ではモデルカタログの機能も提供しており、幅広いタイプの基盤モデルが掲載されています。例えば、機械学習エンジニアの方々は、ネットワークから隔離された環境から専用の SageMaker インスタンスに基盤モデルをデプロイしたり、 SageMaker 上でモデルのトレーニングを実行してカスタマイズすることができます。なお、同じく複数の基盤モデルにアクセスできるサービスとして Amazon Bedrock がありますが、Amazon Bedrock はサーバーレスのサービスであり、インフラを考慮ぜずに使えるのが特徴です。逆に、SageMaker JumpStart ではニーズに合わせてインフラをコントロールできる点が異なります。 以降で解説するように、SageMaker Studio の GUI で数回クリックするか、SageMaker Python SDK を介してプログラム的に Japanese Stable LM Instruct Alpha 7B v2 をご自身の環境にデプロイすることができます。また、 SageMaker Pipelines などの SageMaker の MLOps 機能を使用して基盤モデルの運用を高度化することも可能です。モデルは AWS のセキュアな環境にデプロイされ、お客様の VPC 管理下に置くことも可能です。そのため、データセキュリティが確保されます。Japanese Stable LM Instruct Alpha 7B v2 モデルは、東京リージョン ( ap-northeast-1 ) を含めた複数のリージョンで利用可能です。 SageMaker JumpStart で Japanese Stable LM Instruct Alpha v2 をノーコードでデプロイする SageMaker Studio の GUI から SageMaker JumpStart を開くか、もしくは SageMaker Python SDK を利用して基盤モデルにアクセスすることができます。このセクションでは、SageMaker Studio でモデルを探す方法について説明します。 SageMaker Studio は統合開発環境 (IDE) であり、データの準備から機械学習モデルの構築、トレーニング、デプロイ、監視まで、機械学習の開発運用ライフサイクル全体をカバーする Web ベースのビジュアルインターフェイスを提供します。SageMaker Studio の開始方法とセットアップ方法の詳細については 開発者ドキュメント を参照してください。 SageMaker Studio にアクセスすると、左側のメニューより SageMaker JumpStart にアクセスできます。 SageMaker JumpStart を開くと、さまざまなモデルハブやモデルプロバイダーのリストが表示されます。今回は Stability AI のカードをクリックします。 Stability AI のページでは画像生成モデルである Stable Diffusion のいくつかのバージョンが選択できますが、それだけではなく、新しい Japanese Stable LM Instruct Alpha 7B v2 も表示されています。 Japanese Stable LM Instruct Alpha 7B v2 のカードを開くとモデルの詳細を確認できます。ここではモデルの説明、トレーニングに使われたデータセット、ライセンスなどが確認できます。右上の Deploy をクリックするとモデルデプロイ用の画面に遷移します。 推論エンドポイントの名前、インスタンスタイプ、インスタンス数、その他オプションをセットした上で右下の Deploy ボタンを押すとモデルのデプロイが開始されます。ちなみに、ここで選択している ml.g5.2xlarge は NVIDIA A10G Tensor Core GPU (GPU メモリ 24 GiB) が 1 台搭載されており、東京リージョンでは 1 時間あたり 2.197 USD で利用できる、推論用途に適したインスタンスです。インスタンスタイプごとの特徴は こちら 、SageMaker の料金は こちら を参照してください。 5-10 分ほど待機して、ステータスが In service に変わればデプロイは成功です。 SageMaker Python SDK でデプロイする もちろん GUI からモデルをデプロイするだけでなく、SageMaker Python SDK を用いてプログラム的にデプロイすることもできます。その際には、SageMaker Python SDK の JumpStartModel クラスで対象のモデル ID を指定し、 deploy() メソッドを呼ぶことで実行できます。 import sagemaker from sagemaker.jumpstart.model import JumpStartModel model_id = "model-textgenerationjp-japanese-stablelm-instruct-alpha-7b-v2" model = JumpStartModel(model_id=model_id) predictor = model.deploy() 後述するように、こちらの返り値の predictor を用いて推論自体を実行することもできます。 Japanese Stable LM Instruct Alpha 7B v2 で推論を実行する Japanese Stable LM Instruct Alpha 7B v2 は以下のような形式で入力を受け取ることを前提にチューニングされています。「 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 」という文章は常に固定であり、「 ### 指示: 」のセクションに質問事項や解きたいタスクの説明を与え、「 ### 入力: 」のセクションはオプション変数として指示に関する詳細情報や選択肢などの補足情報を必要に応じて与えます。そして、「 ### 応答: 」のセクションに LLM からの応答が入るという構成になっています。 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 与えられたことわざの意味を小学生でも分かるように教えてください。 ### 入力: 情けは人のためならず ### 応答: このプロンプトの形式を一定に保つため、以下のように build_prompt 関数を用意し、 instruction と input のキーを持つ辞書をインプットとして、プロンプトを構築するような仕組みを用意することをおすすめします。以降のコードは SageMaker Studio から Code Editor などを開いて実行 してください。 input1 = { "instruction": "与えられたことわざの意味を小学生でも分かるように教えてください。", "input": "情けは人のためならず", } def build_prompt(instruction, input="", sep="\n\n### "): sys_msg = "以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。" p = sys_msg roles = ["指示", "応答"] msgs = [": \n" + instruction, ": \n"] if input: roles.insert(1, "入力") msgs.insert(1, ": \n" + input) for role, msg in zip(roles, msgs): p += sep + role + msg return p prompt1 = build_prompt(input1["instruction"], input1["input"]) プロンプトは JSON 形式にエンコードしていきます。 text_inputs キーにプロンプトの文字列を渡します。その他、 LLM の推論に関わるパラメーター も同時に渡すことができます。 payload = { "text_inputs": prompt1, "early_stopping": True, "no_repeat_ngram_size": 4, "max_new_tokens": 128, "do_sample": True, "temperature": 1.0, "top_p": 0.95, } 推論を実行するには、SageMaker のランタイムのクライアントを用意し、 invoke_endpoint API を実行します。 EndpointName には推論エンドポイントの名前、 ContentType には application/json 、 Body には JSON エンコードした上記のペイロードを渡します。すると、推論エンドポイントからのレスポンスが返ってきます。 import json import boto3 from pprint import pprint client = boto3.client("runtime.sagemaker", region_name=region_name) response = client.invoke_endpoint( EndpointName=endpoint_name, ContentType="application/json", Body=json.dumps(payload).encode("utf-8"), ) なお、Japanese Stable LM Instruct Alpha 7B v2 を ml.g5.2xlarge インスタンス 1 台にデプロイした推論エンドポイントを上記のスクリプトで 700 回実行して推論にかかる時間の統計を取ったところ、今回の設定では 2.09 s ± 102 ms (平均値 ± 標準偏差) という結果になりました。この結果は、インスタンスタイプや、インスタンス数、推論パラメーター (特に出力文の長さを調整する max_new_tokens ) に依存する点にはご注意ください。 さて、LLM からの出力 (completion) は Body キーに StreamingBody 形式で格納されているので、 read() で読み込みます。 prediction = json.loads(response["Body"].read()) generated_text = prediction[0][0]["generated_text"] pprint(generated_text) 生成されたテキストは以下のようになっています。今回は推論パラメーターの top_p (上位 p % のトークンを取得) と temperature (確率分布の散らばり具合を調整) をそれぞれランダム性が出るように設定しているため、推論を実行するたびに異なった出力文が生成されます。 # generated_text の中身 ('以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。\n' '\n' '### 指示: \n' '与えられたことわざの意味を小学生でも分かるように教えてください。\n' '\n' '### 入力: \n' '情けは人のためならず\n' '\n' '### 応答: \n' '「情けは人の為ならず」は、情けは他人のためを思ってかけるものですが、結果として、自分に恩恵が戻ってくるという意味です。') 応答部分だけ抜き出すと『 「情けは人の為ならず」は、情けは他人のためを思ってかけるものですが、結果として、自分に恩恵が戻ってくるという意味です。 』となっています。「情けは人の為ならず」ということわざは、三省堂のスーパー大辞林では『情けを人にかけておけば,巡り巡って自分によい報いが来るということ。』という意味であると説明されています。誤用されがちなことわざではありますが、Japanese Stable LM Instruct Alpha 7B v2 も辞書と同等の説明ができていることがわかります。 SageMaker Python SDK でモデルをデプロイした場合の推論方法 SageMaker Python SDK の JumpStartModel クラスの deploy() メソッドを用いてモデルをデプロイした場合、返り値の predictor を用いて推論を実行することができます。裏側では上記の方法と同様に invoke_endpoint が呼ばれていますが、複数の処理が隠蔽されており、シンプルな API で推論を実行することができます。 predictor.content_type = "application/json" prediction = predictor.predict( json.dumps(payload).encode("utf-8"), ) あと片付け SageMaker のリアルタイム推論エンドポイントは、起動中に課金され続けるため、検証が終わったら忘れずに削除してください。 sagemaker_client = boto3.client("sagemaker", region_name=region_name) # 推論エンドポイントの削除 sagemaker_client.delete_endpoint(EndpointName=endpoint_name) # SageMaker Python SDK を利用した場合 predictor.delete_endpoint() まとめ 本記事では、SageMaker Studio から SageMaker JumpStart に掲載されている Japanese Stable LM Instruct Alpha 7B v2 モデルを使い始める方法を紹介しました。SageMaker JumpStart を使うことで、動作が保証されているインスタンス上で最適化された推論コードを用いた推論エンドポイントの作成を行うことができます。基盤モデルは事前にトレーニングされているため、追加のトレーニングを行うことなく、ユースケースに合わせてすぐ利用を開始することができます。ぜひみなさんも SageMaker JumpStart から Japanese Stable LM Instruct Alpha 7B v2 を試してみてください! 著者について 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は某世界旅行すごろく系ゲームを 1 人で 100 年分走り切る修行をしていましたが、挫折しています。
ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。 そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、どの資料を確認した方がいいのかを役割別にまとめています。 本ブログは自治体に業務システムを提供するベンダーの方へ向けた「ASP&amp;運用管理補助者編」です。 そのほかの方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内: 『自治体職員編』 ガバメントクラウドの道案内: 『統合運用管理補助者編』 ガバメントクラウドの道案内: 『ネットワーク構築運用補助者編』 ガバメントクラウドの道案内:『ASP&運用管理補助者編』(本ブログ) ガバメントクラウドではガバメントクラウドの個別領域 (AWS アカウント) の運用管理を行う事業者を「ガバメントクラウド運用管理補助者」、業務システムの構築・提供・運用保守など行う事業者を ASP として定義しています。 どちらか片方、もしくは両方に該当する事業者の方にご参考いただける内容となっています。 ここでは気にするべきポイントをステップに分けて紹介します。 「共同利用方式」か「単独利用方式」かを考える 自社の作業範囲を明確にする (共同利用方式の場合) 団体間の分離方式を確認する 運用保守経路を確保する モダナイズを検討する 利用できるベストプラクティスやサンプルがないか確認する それぞれの対応方法について概要と、どのように考えていくかをお伝えします。 (1) 「単独利用方式」か「共同利用方式」かを考える まずはガバメントクラウドの利用方式として「単独利用方式」か「共同利用方式」のどちらで自治体へ環境を提供するか考える必要があります。 単独利用方式の場合、自治体職員にも AWS アカウントの権限が払い出されます。共同利用方式の場合、ベンダーにのみ AWS アカウントを利用する権限が払い出されます。 共同利用方式では自治体が AWS アカウントの運用管理を個別に行わない前提となっているため、各自治体で要件の差が出づらいと考えられます。そのため複数の自治体へ業務システムを提供する場合、共同利用方式を選択し、 AWS CDK などの IaC や、監視のダッシュボード等を共通化しておくことにより、運用保守の工数や構築の初期費用を削減できることがあります。 「 地方公共団体情報システムのガバメントクラウドの利用に関する基準 【第 1.0 版】 」でもいくつかの理由から共同利用方式が推奨されています。 一方で、 Direct Connect ・ AWS Transit Gateway 等のネットワークを管理するアカウントは、自治体個別の要件が発生することが多いため単独利用方式になることが多いと考えられます。 ガバメントクラウドの道案内: 第 1 回『自治体職員編』: (4) 「共同利用方式」か「単独利用方式」かを考える では自治体職員の方の立場から 2 つの利用方式の違いについて記載しているため、こちらも併せてご参照ください。 (2) 自社の作業範囲を明確にする 自治体のガバメントクラウドの利用環境は、複数の事業者によって構成されるマルチベンダーの環境になることがほとんどです。 そのため、自社の作業範囲としてどこまでを担うか自治体の方と協議して決定する必要があります。それぞれの事業者の詳細な役割分担については、AWS Blog 自治体のお客様向け「ガバメントクラウド利用タスクリスト」を公開します をご参照ください。 例えば、以下の作業項目は自治体の方針に合わせて構成が変わってくるポイントのため、まずはじめに確認しておくことをお勧めします。 a. ASP 、運用管理補助者それぞれの役割の有無 まず、自社が AWS アカウントの管理を実施する「ガバメントクラウド運用管理補助者」としての業務、アプリケーションの構築・提供を行う「ASP」としての業務のどちらを担うか確認します。傾向としては、1 つの事業者が運用管理補助者と ASP を両方担うケースが多いようです。 運用管理補助者の業務も実施する場合、業務を提供する自治体が ガバメントクラウドの道案内:『統合運用管理補助者編』 に記載されている統合運用管理補助者を採用していないか確認し、統合運用管理補助者が実施する業務を確認し、それを基に運用管理補助者として実施しなければいけない業務を設計していきます。 b. 庁舎との接続 自治体から基幹業務システムを利用するためには、自治体庁舎と AWS 間を専用線で接続する必要があります。 以下の構成例は一例ですが、庁舎 – AWS 間を接続するために、 Direct Connect ・ AWS Transit Gateway を管理する事業者が必要です。 本ブログでは、庁舎との接続などネットワーク関連の作業を担当する事業者を「ネットワーク構築運用補助者」と呼びます。ネットワーク構築運用補助者の詳細については ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』 をご確認ください。 自治体へネットワーク構築運用補助者に該当する事業者を採用しているか確認し、採用している場合はネットワーク構築運用補助者へ連絡を取り、自社で実施しなければならないネットワーク関連のタスクについて確認しましょう。 c. DNS サーバー 自治体の個人番号利用事務系ネットワーク内では、システムの名前解決にインターネットを利用することができないため、クライアントに提供されるシステムの名前解決を行う手段を提供する必要があります。 Amazon Route 53 Resolver インバウンドエンドポイントを利用することで、閉域網から AWS 上に構築されたシステムの名前解決を行うことが可能です。 インバウンドエンドポイントは、各 ASP・運用管理補助者が個別に管理する場合と、ネットワーク構築運用補助者や統合運用管理補助者が統合的に管理する場合が考えられるため、自治体の方針を確認し、自社のシステムの名前解決をどのように提供することになるか事前に把握しておく必要があります。 詳しくは ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』 の「 DNS の設計について」をご確認ください。 d. Private CA 自治体の基幹システムの実装では「 地方公共団体情報システム非機能要件の標準 」において、すべての伝送データの暗号化をするように記載されています。 そのため、内部ネットワークからアクセスされる個人番号利用事務系のシステムでも TLS を利用した実装が必要です。TLS で通信を暗号化するために TLS サーバー証明書が必要となりますが、内部ネットワークでサーバー証明書を利用する場合 Private CA が必要となります。 ネットワーク構築運用補助者や統合運用管理補助者が統合的に Private CA を管理し各ベンダーにサーバー証明書を配布する場合と、各 ASP・運用管理補助者が個別に Private CA を管理する場合があるため、自治体の方針を確認し自社のタスクについて整理します。 AWS で Private CA を構築する場合、 AWS Private CA をご利用いただくことができます。 e. 認証認可サーバー (データ連携の方針) 「 地方公共団体情報システム共通機能標準仕様書 」にデータ連携機能の標準仕様が定められ、各標準準拠システムは一部の例外を除き、ガバメントクラウドの CSP が提供するオブジェクトストレージと REST API を利用したデータ連携が求められることとなりました。 ガバメントクラウド上のシステムとオンプレミスのシステムとの連携や、複数の CSP にシステムが分散している場合などでは、システム間の認証認可をどのように行うかが課題となります。標準仕様では自治体ごとに一台の認証認可サーバーを運用していくことが求められており、この認証認可サーバーの運用を行っているベンダーと連携をとる必要があります。 f. Active Directory との連携 業務システムのうち、ファイルサーバーなど Active Directory との連携が必要な場合があります。その場合、自治体で管理している Active Directory と連携が必要です。どのベンダーが Active Directory を管理しているのか、どの方式で Active Directory が構築されているのか (オンプレミス、 Amazon EC2 上の Active Directory、 AWS Managed Microsoft Active Directory ) を確認し、Active Directory と連携ができることを確認します。 (3) 団体間の分離方式を決定する 共同利用方式で業務システムの提供を行う場合、主に 3 種類の団体間のシステム分離方法が考えられます。 団体ごとに専用のアカウントを用意し、団体に関係するリソースをアカウントレベルで分離 (アカウント分離) 複数の団体でアカウントを共有、団体専用の VPC (閉域論理ネットワーク: Amazon VPC ) を用意し、主要なリソースを VPC レベルで分離 (ネットワーク分離) 複数の団体でアカウント、VPC、主要なリソースを共有し、アプリケーションレベルで分離 (アプリケーション分離) このうち、アプリケーション分離を採用できるかどうかはシステムやアプリケーションの実装に大きく依存することになるため、アカウント分離やネットワーク分離が採用されることが多くなることが想定されます。 ネットワーク分離では一部のサービスを団体間で共有することが可能でアカウント分離と比べると一定のコスト抑制効果を期待でき、アカウント分離では団体ごとの範囲を明確化することができる点、アカウントごとのクォータを気にする必要がない点がメリットと言えます。 それぞれの方式の特徴を把握し、提供する業務システムに合わせて選択します。 (4) 運用保守経路を確保する ガバメントクラウド上で構築した業務システムへの運用保守経路を構築します。自治体の基幹業務ではインターネット経由でシステムの運用保守を行うことができないため、以下のいずれかの方法を利用して業務システムの運用保守をする必要があります。 自治体庁舎へ赴き、自治体が保有している回線を利用して保守 ベンダの拠点と自治体庁舎が専用線で接続されている場合、自治体庁舎を経由して自治体が保有している回線を利用して保守 ベンダーが独自に専用線を利用してクラウドへの運用保守経路を構築 共同利用方式を選択している場合、3 の方法を選択する場合でも、自治体の数と同じ専用線を契約する必要はなく、1 つの専用線で複数の自治体の業務システムを運用保守できます。 3 の方法では、1 ベンダーが複数の自治体システムの運用保守を行うことが想定されます。その場合、複数の自治体のネットワークと運用保守 VPC の CIDR 重複が発生し得ます。 AWS PrivateLink を利用すれば、ネットワークアドレスが重複していても各業務システムと通信が行えるため、上記の図は AWS PrivateLink の利用を踏まえた構成図となっております。 (5) モダナイズを検討する ガバメントクラウドに構築するシステムは、ガバメントクラウドへの移行のタイミングをはじめ、継続的にシステムのモダナイズを検討することが求められます。これは一般的なシステムについても同様で、システムの構築後、適切なモニタリングを実施することで改善点を見つけ、より堅牢で効率の良いクラウドネイティブなシステムへと改善を繰り返すサイクルを構築することが重要です。 このサイクルを構築するために、主に 3 つの観点でモダナイズを検討していくことをお勧めいたします。 運用・監視業務のモダナイズ Amazon CloudWatch などのマネージドサービスを利用してシステム全体やアプリケーションの稼働状況を観測可能にします。 AWS における運用・監視について包括的に学ぶには One Observability Workshop の実施がおすすめです。 One Observability Workshop https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/ja-JP インフラストラクチャ構築・システム構築のモダナイズ AWS CloudFormation や AWS CDK を利用しインフラストラクチャの構築を自動化し、AWS Code シリーズによる CI/CD を実施しシステムのデプロイを自動化することで、高頻度のリリースをミスなく実行する環境を構築します。 AWS CDK について初歩から学ぶには、 TypeScript の基礎から始める AWS CDK 開発入門 がおすすめです。 TypeScript の基礎から始める AWS CDK 開発入門 https://catalog.workshops.aws/typescript-and-cdk-for-beginner/ja-JP アプリケーションのモダナイズ Amazon ECS や Amazon EKS を利用したアプリケーションのコンテナ化の検討や、 AWS Lambda を利用した機能のマイクロサービス化、 AWS Step Functions を利用したバッチ処理のマネージド化を検討します。 特に、アプリケーションをコンテナ化する上では以下の資料・ワークショップが参考になります。 クラウドにリフトしたアプリケーション をコンテナ化するためのアプローチ https://pages.awscloud.com/rs/112-TZM-766/images/AWS-48_Container_Modernization_KMD36.pdf コンテナ化のためのリアーキテクチャ https://catalog.us-east-1.prod.workshops.aws/workshops/a49e50ba-7473-4348-ba5d-6166385ad91d/ja-JP また、AWS ではこういったシステムのモダナイズを検討する上で指針となる情報を様々な形で発信しています。ぜひご活用ください。 AWS クラウドでのアプリケーションモダナイゼーション戦略 https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-modernizing-applications/welcome.html 今から始める! AWS におけるクラウドのシステム運用入門 2020 年版 (動画) https://resources.awscloud.com/aws-summit-online-japan-2020-on-demand-aws-sessions-3-44912/aws-05-aws-summit-online-japan-2020-720p (6) 利用できるベストプラクティスやサンプルがないか確認する AWS では様々なシステムのサンプルアプリケーションおよびサンプルテンプレートを公開しており、標準準拠システムをガバメントクラウドに構築する際に重要となる閉域網におけるサンプルも提供しています。 閉域網アプリケーション サンプルテンプレート https://aws.amazon.com/jp/blogs/news/announcing-template-for-closed-network-system-workloads-on-aws/ 閉域網マルチテナントアプリケーション サンプルテンプレート https://aws.amazon.com/jp/blogs/news/multitenancy-app-with-keycloak-closed-network/ また、ガバメントクラウド向けのテンプレートがデジタル庁からも提供されており、Government Cloud Assistant Service (GCAS) などを通じて入手することが可能です。 ガバメントクラウド利用における推奨構成 (AWS 編) 地方公共団体情報システム認証機能に関するリファレンスガイド(AWS 編) このほか、AWS では継続してガバメントクラウドや標準準拠システムに資するサンプルテンプレートを公開していく予定です。 まとめ 本ブログでは、ASP・運用管理補助者となる事業者の方向けにガバメントクラウド上で業務システムを構築するうえで検討すべきポイントをご紹介しました。ガバメントクラウドを利用する際の不明点が少しでも取り除けていたら幸いです。 自治体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/
このブログは 2023 年 11 月 27 日に Doug Buser 氏によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 AWS re:Invent にて、Riot Games のグローバルインフラストラクチャとオペレーションの責任者である Brent Rich 氏が、同社が 2024 年初頭で完了予定の数年にわたるグローバル規模なデータセンター廃止の取り組みの最終段階にあることを発表しました。Riot Games は『リーグ・オブ・レジェンド』・『VALORANT』・『リーグ・オブ・レジェンド:ワイルドリフト』・『チームファイト タクティクス(TFT)』や『レジェンド・オブ・ルーンテラ』などのゲームタイトルを運営しており、この取り組みにより、Riot はこれまでにないほどプレイヤーの近くにサーバを配置できるようになりました。 2017 年、Riot Games は自社のデータセンターを廃止しアマゾン ウェブ サービス(AWS)クラウドに完全に移行する意思決定をしました。その後、14 のデータセンターが閉鎖され、先月にもラスベガスとチリのデータセンターが閉鎖されています。Riot は向こう数ヶ月内にブラジルとトルコの残りのデータセンターも閉鎖する予定です。 AWS は Riot の公式のクラウドサービスプロバイダーであると同時に、公式のクラウド人工知能(Artificial Intelligence、AI)・クラウド機械学習(Machine Learning、ML)・クラウド深層学習(Deep Learning、DL)プロバイダーでもあります。 Riot が会社として成長し続け、テレビ番組や音楽・eスポーツ放送などのプレイヤーを楽しませるための新しい道を模索している中、Rich 氏はチームにクラウドファーストのマインドセットを持つよう促しています。「壁にぶつかった時、昔は『自分たちで頑張ろう』と考えるのが普通だったが、今ではまず『AWS に相談してみよう』とみんな思うようになりました」 Riot と AWS のコラボレーションの歴史を振り返り、クラウドの導入にあたって Riot が取った段階的なアプローチがいかにして社内で最もクラウドに対して懐疑的な人たちさえも味方につけられたかについて見ていきましょう。 物語のはじまり 「2015 年の Riot は破竹の勢いでした」と Rich 氏は振り返りました。「『リーグ・オブ・レジェンド(LoL)』が大ヒットし、当時の Riot はパフォーマンスとプレイヤー体験を最優先事項としていました」 2015 年から 2018 年にかけて、Riot は隔週で『LoL』のアップデートをリリースし、プレイヤーを熱中させるゲームであり続けるよう注力しました。この時 Riot のデータセンターで使われているテクノロジーは 10 年ほど昔の古いものでした。ライフサイクルアップグレードや古めのソフトウェアサービスの AWS 上での仮想化は行なったものの、Riot は依然としてオンプレミスのインフラストラクチャに依存していました。 2019 年が差し迫るころ、Riot ではスタンドアローンのモバイルゲーム『チームファイト タクティクス(TFT)』のローンチと 2020 年の次の大型タイトル『VALORANT』のリリースが控えていました。『VALORANT』では世界中のプレイヤーに遊んでもらうため、当初の計画では世界各地の 40 拠点でデータセンターを構える予定でした。レイテンシの低いソリューションの採用は『VALORANT』の成功の絶対条件でした。『VALORANT』では開発の初期段階から、ピーカーズアドバンテージの排除をプレイヤーにとっての中核となる価値の一つとして位置づけていました。(ピーカーズアドバンテージとは、プレイヤー間のレイテンシのばらつきによりサーバがプレイヤーの入力を受け付けるタイムラグにずれが生じ、一部のプレイヤーがわずかに有利になる現象です。) Rich 氏は「当時、パフォーマンスを出したいならベアメタルだという考え方が主流でした。一方、データセンターを所有・運用するのは途方もなく複雑なことで、自動化しようと思うのならなおのことです。我々はクラウドでもベアメタルと同等なパフォーマンスを引き出す方法を探っていました」と語りました。 Riot Games の『リーグ・オブ・レジェンド』シニアプリンシパルソフトウェアエンジニア兼テックリードの David Press 氏はこのように述べました。「これまで以上にキャパシティの柔軟な増減が必要でした。オンプレミスだと数ヶ月のプランニングが必要で、そうするとプロジェクトはウォーターフォール志向にならざるをえませんでした。我々はもっとアジャイルでいきたいと考えました」 Riot は運用の簡素化・効率向上によるイテレーションの高速化と負荷試験の自動化を目標とし、クラウドをオンプレミスのデータセンターの拡張として利用することを検討しはじめました。目標達成のため、Rich 氏と彼のチームは AWS との協力に踏み出し、プランの策定・実行に移りました。 「当時も今も AWS はクラウド業界のトッププレイヤーです。当時、我々はすでに数年間 AWS と仕事してきて、彼らの Customer Obsession(カスタマーオブセッション)を実感してきました。だからこそ、彼らは我々にとって素晴らしい戦略的パートナーになると確信していました」と Rich 氏は語りました。 『VALORANT』の攻めのレイテンシ要件を前に、Riot は Amazon Elastic Kubernetes( Amazon EKS )のサービスチームと連携し Riot と Riot ゲームのプレイヤーが求めるような機能やサポート、そして体験を提供するためのロードマップを策定しました。 段階的なアプローチ 2019 年 6 月、Riot は『TFT』を皮切りにゲーム開発のアプローチをクラウドに移し始めました。Rich 氏曰く『TFT』は「AWS 生まれのゲームだった」とのことです。一方『VALORANT』は大きな試練でした。Riot チームは『VALORANT』のローンチに向けて 18 か所でのグローバル展開に決定しました。そのうち 14 か所は AWS、4 か所は Riot のデータセンターを活用することになりました。2020 年初頭、『VALORANT』のクローズドベータが開始し、期間中の 4 月から 5 月にかけては 1 日あたり約 300 万人のプレイヤーがゲームをプレイしました。これは正式リリースとほぼ同等の規模感でした。 「3 月から全面的にクラウドを活用し、クラウドの超大規模スケーリングを頼るようになりました」と Rich 氏は語りました。 『VALORANT』はクラウドベースで正式のパブリックローンチを果たし、瞬く間に Riot の新たな数十億規模のフランチャイズとなりました。その後も Riot はいくつかの規模の小さめのゲームをクラウドでローンチしました。これらのローンチの成功を経て、Riot は残りのサーバも AWS に移行すると舵を切りました。 社内合意を得る Rich 氏は時間をかけてコンセプトを徐々に実証していくアプローチを取ったことが、当初懐疑的な CXO クラスの役員たちの信頼を得るための鍵となったと説明しました。「クラウドで新しいものをきちんと動かせることを証明しなければなりませんでした。一番のポイントはユーザーデータグラムプロトコル(UDP)のレイテンシとパケットロスが許容範囲内に収まることを証明することでした。パケットロスは一旦発生すると回復不可能で、ゲームプレイ中にパケットロスが発生すると自キャラがテレポートしているかのように見えてしまいます」 Rich 氏はプロジェクトを始めると、最初にチームメンバーにクラウド採用に関する懸念事項を全て挙げてもらい、集まったものを一つ一つ検証していきました。「彼らの懸念はいずれも正当なものでした。我々はこれらについて調査し、全て対処できるものだと証明しました」と Rich 氏が語りました。「『TFT』はクラウドから直接ゲーム体験を提供しています。これによりクラウドの処理能力に問題はないと証明でき、クラウドはデータセンターと同等の品質だったということです」 Riot の CTO・Derek DeFields 氏は Rich 氏の段階的なアプローチを支持し、新しいデータセンターをこれからも作るべきだと主張する人たちにも働きかけました。「全員が全員納得してくれたわけではなく、中には予備として設備を買っておきたい人もいました。『TFT』や『VALORANT』を AWS 上に載せる際オールインするとは一度も口にしませんでしたが、AWS との良好な関係と彼らからの協力は我々に大きな影響を与えました」 Press 氏によると「オンプレミスで運用していたころは、ハードウェア障害が起きるたびに 90 分間のサービス停止が発生していました。AWS に移行し RDS を使うようになってからは、ハードウェア障害がなくなったわけではないのですが、サービスの停止時間はわずか 30 秒となりました」 Rich 氏は、レガシーゲームの AWS 移行を担当するリードエンジニアリングチームが Rich 氏のチームからプロジェクトを引き継ぎたいと申し出た時、プロジェクトの成功を確信したと述べました。「彼らがプロジェクトを引き受けられるように、我々は 2 年間努力を重ねてきました。これをもって移行プロジェクトの最後のチェック項目もクリアできました」 新しいマインドセット クラウド移行によってどんな新しい道が開かれたかと質問された時、Rich 氏は発想を逆転しこう述べました。「むしろ何が閉ざされるのかが重要です。一つの物語が幕を閉じました。データセンターで生まれたものはほとんど消え去り、クラウドが我々の目標達成に有効であることが実証された今、昔ながらのデータセンターマインドセットも変わりました」 Riot は自社の多くのプロジェクトを支援するために、Amazon EKS サービスチームと定期的に機能プランニングセッションを行いツールや新機能の開発を続けています。「戦略的パートナーなしでは非常に難しいこともあります。我々と AWS と我々のインテグレーションパートナーである Slalom 社との連携を例にあげると、我々は三社で一つの『LoL』の綿密な自動化ランブックを共有しています。新しいリージョンで何かを立ち上げる際数週間もあれば事足ります。こうしたパートナーシップは非常に貴重なものだと言えます」 翻訳はソリューションアーキテクトのBaixiao Linが担当しました。
はじめに コンタクトセンターの管理者は、エージェントと顧客のやりとりの改善に向け、エージェントのコーチングの必要性の正確な特定という課題をよく抱えています。この課題に対処するため、Amazon Connect では一連のパフォーマンス評価機能を提供しています。これらの機能により、フォーム作成と評価プロセスの両方を自動化して、エージェントの評価に必要な手動プロセスを削減できます。さらに、Amazon Connect には技術的な評価機能のパブリック API も提供しており、フォーム作成と評価プロセスの両方を自動化できるため、エージェントの評価に必要な手動プロセスをさらに削減できます。 これらのAPIを使用することで、エージェントのパフォーマンスについて、他の側面を反映する外部のデータをエージェント評価プロセスに組み込むことができ、 Amazon Connect の外部にあるシステムから取得した情報でパフォーマンスに関する洞察を補うことができます。このブログ投稿では、これらの API の使用方法について説明します。 概要 この記事では、次のシナリオを使用して、API (アプリケーションプログラミングインターフェイス) の使用方法を示します。 AnyCompany は自動車保険会社で、コンタクトセンターに1000人以上のエージェントを擁し、保険サービスに関わる顧客からの通話を日常的に処理しています。同社では、エージェントに会社のポリシーに従い、カスタマーサービスの通話中、前向きな感情を保つことを求めています そのため、コンタクトセンターのスーパーバイザーは、エージェントが会社のポリシーを遵守していることを確認するために、エージェントのパフォーマンスを定期的に評価する必要があります。エージェントのパフォーマンスを評価するには、スーパーバイザーはエージェントと顧客の電話を聞いたり、チャットの記録を読んだりした後、電子フォームを使って電話やチャットでのやり取り中のエージェントのパフォーマンスに関して回答する必要があります ただし、コール数、エージェントの数が多く、実施される評価の数が少なすぎて、有意義な洞察を得たり、エージェントのパフォーマンスを向上させたりすることができていません。そのため、AnyCompany は、エージェントを自動的に評価し、スーパーバイザーが通話を聞いたり、通話の記録を読んだりしなくても、評価が確認できるシステムが必要です このブログ記事では、電子評価フォームをプログラムで作成し、Amazon Connect が最近リリースした API を使用してフォームに対してエージェントのパフォーマンスを評価するソリューションについて説明します。以下の図と手順は、この記事が従うワークフローを示しています (図 1 、図 2)。 図 1: API による評価フォームの作成 ステップ 1: API を活用して評価フォームを作成し、 Amazon Connect に保存します。このワークフローは上の図 1 に示されています。このワークフローにおける顧客とのやりとりを以下の図 2 に示します。 図 2: 顧客とのやりとりを示す概要図 ステップ 2: 発信者(顧客)が既存の自動車保険のサービスを受けるために電話をかけてきます ステップ 3: 発信者がエージェントと話し、やり取りが完了してエージェントが電話を切ると、発信者は通話後のアンケートオプションを選択し、アンケートに回答します。回答は 問い合わせ属性 としてキャプチャされ、その通話の 問い合わせレコード に保存されます ステップ 4: Amazon Connect が、この通話のトランスクリプトを S3 バケットに自動的にアップロードします ステップ 5: トランスクリプトファイルがアップロードされると Lambda 関数がトリガーされます ステップ 6: Lambda 関数が問い合わせ属性からアンケートのスコアを抽出します。また、トランスクリプトファイルから感情スコアを抽出します ステップ 7.1: Lambda 関数が評価フォームの質問を、アンケートの質問への回答と呼び出しのセンチメントスコアで更新します。 ステップ 7.2: Lambda 関数がこの通話の評価を送信します 前提条件 この手順では、以下について理解、アクセスできることを前提としています。 AWS アカウント Amazon Connect インスタンス Amazon Connect インスタンスで取得済みの電話番号 AWS IAM によるポリシーとロールの作成 Amazon S3 でバケットを作成する Stack を実行するための AWS CloudFormation Amazon Connect Contact Lens ソリューションのデプロイ 注:この投稿では、ネストされた CloudFormation テンプレート (CFT) のセットを使用しています。 メインの CFT は、他の 3 つのネストされた CFT を自動的に呼び出してデプロイを完了します。 手順の概要 : ソリューションのデプロイは、次の 2 つの手順で構成されます。 ここから CloudFormation スタックをデプロイ します 機能の確認 : テスト通話を行い、結果を確認します CloudFormation スタックのデプロイ ステップ 1: AWS マネジメントコンソール にログインします ステップ 2: CloudFormation スタックをデプロイします ステップ 2.1: 手順の概要に記載の 「 ここから CloudFormation スタックをデプロイ 」をクリックします ステップ 2.2: 図 3 のように一意なスタック名を入力します ( 例 : create-ef-assets) 図 3: CloudFormation のパラメータ設定 パラメータ “AmazonConnectInstanceArn” と “BasicQueueArn” は Amazon Connect インスタンスからコピーする必要があります。以下の手順では、これらを取得する方法について説明します。 ステップ 2.3: AmazonConnectInstanceARN : Amazon Connect インスタンスの ARN を取得する方法については、 こちら を参照してください。ARN をコピーし、下の図 4 に示すように CloudFormation のフォームに貼り付けます。 図 4: Amazon Connect インスタンスの ARN の確認 ステップ 2.4: BasicQueueARN : Amazon Connect コンソールからキューの ARN を取得する方法については、以下の図 5 を参照してください。Amazon Connect でキューを設定していない場合は、キューの設定方法について こちら を参照してください。Amazon Connect インスタンスが作成されると、“ Basic Queue “ がデフォルトで作成されます。このブログ用にインストールしたサンプルフローでは、このキューを使用して API の使用方法を説明しています。キューを設定したら、キューの ARN をコピーして、ステップ 2.3 と同様に CloudFormation フォームの BasicQueueArn に貼り付けます。 図 5: Queue ARN の取得 ステップ 2.5: S3BucketName : 通話録音が保存されている S3 バケットの名前。 次に示す ようにインスタンスページに移動します。通話録音を保存する S3 バケットは、「データストレージ」→「通話記録」の下に表示されます。 (下の図 6 を参照)このフィールドに必要なのはバケット名だけです。例 – amazon-connect-beXXXXXXXXXX (下の図 6 を参照してください。最初の「/」より前にあるものはすべてS3バケット名の一部であり、 CloudFormation テンプレートへの入力として指定する必要があります) 図 6: 通話記録の S3 バケット 図 7 のように CloudFormation テンプレートに貼り付けます。 図 7: CloudFormation の入力欄に S3 バケット名を貼り付け ステップ 3: 次のページで “ 次へ ” をクリックし、もう一度 “ 次へ ” をクリックします ステップ 4: 次のページの一番下までスクロールする ステップ 4.1:「 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 」のチェックボックスをオンにします。 ステップ 4.2:「 AWS CloudFormation によって、次の機能が要求される場合があることを承認します: CAPABILITY_AUTO_EXPAND 」のチェックボックスをオンにします。 ステップ 4.3: “スタックの作成“ をクリックします。 ステップ 5: AWS CloudFormation テンプレート がすべてのリソースを作成するのに 5 ~ 10 分かかる場合があります。完了すると、ステータスが CREATE_COMPLETE と表示されます。 注意: これは ネストされた CloudFormation テンプレート です。メインスタックは他の 3 つのスタックに依存しています。以下の図 8 は、これらの各スタックによって作成されるリソースを示しています。必要なのはベーススタック (install_ef_api_assets.yml) を実行することだけです。他のスタックはベーススタックによって自動的に呼び出されます。 図 8: CloudFormation テンプレートによってインストールされたアセット ステップ 6: このブログ記事は Amazon Connect Contact Lens を使用しています。Amazon Connect インスタンスにログインし、 Contact Lens が有効になっていることを確認します(下の図 9 を参照) 図 9: Contact Lens の有効化 機能のテスト このセクションでは、 CloudFormation テンプレート によってデプロイされたアセットの概要を説明し、その結果をテスト、検証します。 CloudFormation テンプレートによってデプロイされたアセット アセット 1: 評価フォーム: ステップ 1: コンソール内の評価フォームに移動し、 CloudFormation テンプレート によって作成されたフォームを探します (下記の図 10 と図 11 を参照) 図 10: Amazon Connect コンソールメニュー内の評価フォームの位置 図 11: 自動的に作成された評価フォームテンプレート ステップ 2: “ バージョン 1 ” をクリックして評価フォームを開き、作成された質問を確認します (下の図 12 を参照) 図 12: API を介して作成された評価フォーム アセット 2: コンタクトフロー 「フロー」セクションに移動し、テンプレートによって 2 つのフローが作成されたことを確認します (図 13) 図 13: テンプレートによって作成された 2 つのフロー 結果のテストと検証 ソリューションをテストする方法は以下の通りです。 ステップ 1: リンク先 の手順で、 BasicContactFlow で終わる問い合わせフローに電話番号を割り当てます ステップ 2: ユーザーを作成し、 リンク先 の手順で Basic Routing Profile &nbsp;に割り当てます ステップ 3: リンク先 の手順で、エージェントとしてコンタクトコントロールパネルにログインし、ステータスが Available であることを確認します ステップ4: 上記のステップ 1 の電話番号に顧客として電話をかけ、CCP 経由でエージェントとして電話に出ます。45~50秒以上会話を続けてください。この後、以下の手順に従ってください。 ステップ 5: エージェント側で電話を切り、 Available に戻ります ステップ 6: 顧客側で通話を続けてください。次のようなアンケートのメッセージが流れます。 “ How did we perform, on a scale of one to five. One being bad and five being amazing. ” (私たちの対応を 1 から 5 で評価してください。悪ければ 1 、素晴らしければ 5 を選んでください) ステップ 7: 顧客側の電話のキーパッドで 1 から 5 までの数字 (3 など) を押します。 ステップ 8: システムからの返答 “ Thank you for rating us 3. Good bye. ” (3 の評価ありがとうございました、さようなら)を確認し電話を切ります ステップ9:1~3分待ってから、図 14-a に示すようにコンタクトの検索に移動し、かけた通話を検索し、通話を開いて詳細を表示します ステップ 10: 連絡先の詳細ページには、コンタクトが評価され、評価が自動的に送信されたことが表示されます。図 14-b を参照してください。また、評価に割り当てられたスコアも表示されます (この場合は 10% 、下の図 14-c を参照)。 図 14-a: コンタクトの検索画面 図 14-b: 連絡先の詳細画面に、自動的な評価結果が表示されている様子 図 14-c: 自動評価の詳細 API 呼び出しシーケンス 通話が終了すると、図 15 の順序で評価フォーム API が呼び出されます。 図 15: API 呼び出しのシーケンス図 クリーンアップ 評価フォームによるコンタクトの評価にはコストがかかります。さらに、電話の着信や Contact Lens に関する費用もかかります。Amazon Connect の料金は こちら に記載されています。今後課金されないようにするには: ステップ 1: 電話番号とコンタクトフローの関連付けを解除します ステップ 2: コンソールから「 電話番号を表示 」に移動します (図 16) 図 16: 電話番号を表示する ステップ 3: このテストで使用した電話番号を選択します (図 17) 図 17: 電話番号を選択 ステップ 4: 問い合わせフローの横にある「x」をクリックして、電話番号を問い合わせフローから切り離し (図 18)、「 保存 」をクリックします 訳注 : 電話番号の維持にもコストが発生します。電話番号をこのテストのために取得した場合は、 電話番号のリリース を検討してください 図 18: 問い合わせフローから電話番号の関連付けを切り離す ステップ 5: AWS CloudFormation のスタックを削除 し、作成したリソースを削除します 結論 スコアリングと評価は、エージェントの品質を管理するためのコンタクトセンターの運営に欠かせないものです。このブログ記事では、Amazon Connect API を使用して評価フォームを作成し、問い合わせを評価、送信する方法の例を示しました。評価に関する API の全リストは こちら をご覧ください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。
AWS Amplify の新しい コードファースト開発者エクスペリエンス は、ウェブ開発の未来を形作ることに貢献しています。このアプローチでは、AWS サービスの力を活用しながら、シームレスなデベロッパーエクスペリエンス(DX)に焦点を当てて、アプリファーストの考え方で構築することに重点が置かれています。このアプローチを採用することで、開発者は顧客のニーズを満たす堅牢でスケーラブルなフルスタックアプリケーションを作成できます。このブログ記事では、開発者がアプリを開発、拡張、デリバリーする際に直面するストレスの原因と、Amplify がこれらの課題をどのように解決するかについて詳しく説明します。コード生成から拡張性の実現、デプロイの合理化まで、Amplify にはフルスタックのアプリケーションをクラウドで構築するために必要なものがすべて揃っています。 この記事では、AWS Amplify のコードファーストアプローチの背後にある要件と主な利点について説明します。 ストレスの原因 開発者が開発プロセスにおけるストレスを経験すると、新機能の提供、バグの解決、顧客の問題への対応などが遅れる可能性があります。これはひいてはカスタマーエクスペリエンス全体に影響します。デベロッパーエクスペリエンス(以下 DX)の低下は、通常、次の 3 つの領域のいずれかに分類されます。 開発 あなたのウェブ開発者としての時間は、ウェブアプリの機能構築に費やされます。この構築過程を自動化したり、コーディング体験を向上させるベンダーのツールやサービスは、生産性と効率を大幅に向上させることができます。しかし、これらが意識的に設計されていない場合、それらは貧弱なエクスペリエンスの一因となる可能性があります。 ここでは、開発者のソフトウェア構築を支援するツールが考慮すべき、優れた DX のための一般的な考慮事項を紹介します: 冗長性の排除:CRUD API や UI コンポーネントのような冗長なコードを、ツールやサービスが生成する シームレスなパフォーマンス:導入してしてすぐ(Out-of-the-box)に効果を得られるようにする 型の安全性:TypeScript は新しい標準であり、支持されるに十分な理由がある 拡張 デフォルト設定は便利ですが、特定のアーキテクチャの決定を強制するものであり、将来、その決定が古くなる可能性があります。開発者のエクスペリエンスを向上させようとするあまり、ベンダーは自分のスタイルに合わないデフォルトに縛り付けてしまう可能性があります。 拡張性のある API:API を拡張できるだけでなく、ベンダーはパズルのピースを公開し、そこにあなた自身のピースをはめ込めるようになっているべき ロジックの持ち込み:ベンダーの API の一部を利用せず、代わりに独自のロジックを持ち込めるべきである (原文を尊重し、表現を直訳しています) デリバリー ウェブ開発者として完全に自動化すべきことが 1 つあるとすれば、それはプロダクトデリバリーです。残念なことに、私たちの多くはインフラストラクチャの設定に関してスキルギャップを抱えていますが、それは問題ありません。なぜなら、あなたの責任は開発に集中しているからです。 自動化: ホスティング機能だけでは不十分です。使い慣れた言語の CI/CD パイプラインを通じて、変更を加えて自動的にロールアウトできる必要があります 親しみある言語でのインフラストラクチャ設定: インフラストラクチャの設定経験は、ウェブ開発者に合わせて調整されるべきです。JavaScript 開発者の場合は JS を使用し、YAML の記述方法を理解して知っている場合は YAML を使用してサーバーを構成できる必要があります それぞれの DX に関する考慮事項についてより深いレベルで説明し、AWS Amplify がそれぞれをどのように解決するかについても見ていきましょう。 開発: Amplify の型安全性 TypeScript の人気は最近急上昇し、 2023 年 の Stack Overflow Developer Survey で 5 番目に愛されている言語になりました。TypeScript の人気は、ウェブ開発における柔軟性と堅牢性の両方を備えた言語を好むトレンドを反映しています。開発者は、エラーを早期に発見し、共同作業を合理化し、大規模なコードベースに明確な構造を提供する TypeScript の機能を高く評価しています。 型安全性により、実行時ではなく開発中にエラーを検出できるため、デバッグやテストにかかる時間を大幅に節約できます。また、コードを通じた明確なコミュニケーションが鍵となるコラボレーション環境では、コードの可読性と保守性が向上します。 ウェブ開発における TypeScript の人気と利点に加えて、TypeScript の Isomorphic 機能は急速に人気を集めています。TypeScript の Isomorphic 機能を使うと、開発者はサーバーコードとクライアントコードの両方からアクセスできる型を作成できます。つまり、開発者はサーバーとクライアント間でコードを共有できるため、コードの重複が減り、保守が容易になります。AWS Amplify は、これらすべての DX が組み込まれ、型安全性ファースト(タイプセーフファースト)になりました。 開発: 自動化されたパフォーマンス 私たちが Nuxt.js や Next.js をデフォルトにしている究極の理由は、SSR や SSG などのためではありません。100/100 のパフォーマンススコアの結果として、素晴らしい体験をお客様に提供したいからです。私は、Next.js、Astro、Nuxt、Remix が何をするか以上にパフォーマンスを気にするよう提唱していますが、基礎を正しくすることを心配する必要がないのは、すがすがしいことです。 React と Vue はブラウザで実行できる JavaScript を生成し、あらゆるパフォーマンスと SEO コストが発生する中で簡単にデプロイ/提供できるようにします。しかし、クライアントでハイドレートする前に、まずサーバーでページをレンダリングする必要がある場合、SSR のビルドプロセスと出力を制御する必要が出てきます。ここで Amplify Hosting の出番です。SSR のデプロイを気にすることなく、SSR フレームワークを使用してパフォーマンスを重視した構築が可能になります。ほとんどの場合、必要なのはリポジトリを接続することだけです。 AWS Amplify は Next.js アプリをすぐにサポートし、 Nuxt アプリもホスティング できるようになりました。 開発: コード生成 Web 開発での CRUD (作成、読み取り、更新、削除) の実装は反復的な作業で、多くの場合はこれらの開発にかなりの時間がかかります。この課題に対処するため、TypeScript 開発者はこれらのタスクを自動化してワークフローを合理化するコードジェネレーターに目を向けました。 コードジェネレーターは、データモデル、API クライアント、UI コンポーネント、フォーム UI を生成する場合に特に役立ちます。このような反復的なタスクを自動化することで、プロジェクトのより複雑でクリエイティブな側面に集中できます。さらに、コードジェネレーターは型の安全性を導入し、コード品質を向上させることで、DX を向上させることができます。 Amplify Gen 2 では、コードの記述時にロジックと型が自動的に生成され、CLI コマンドを明示的に実行する必要がなくなるため、自動化がさらに一歩進んでいます。Gen 2 は TypeScript ファーストで、フロントエンドコード用の「データクライアント」をデータスキーマから生成することができます。その結果、開発者はこのクライアントを利用して CRUDL (作成、読み取り、更新、削除、一覧表示) 処理を記述するだけでよくなり、CRUD のための関数を書くという、これまで行ってきた反復的な作業から解放されます。 以下のコードスニペットは、Gen 2 でスキーマを定義する方法を示しています。 DefineData 関数を使用してデータのスキーマと認証モードを設定します。これは、Gen 2 がバックエンドのデータモデル定義を型の安全性で合理化する方法を示しています。 // Backend import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ Todo: a .model({ content: a.string(), done: a.boolean(), priority: a.enum(["low", "medium", "high"]), }) .authorization([a.allow.owner()]), }); export type Schema = ClientSchema&lt;typeof schema&gt;; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", apiKeyAuthorizationMode: { expiresInDays: 30, }, }, }); 以下のコードスニペットは、 aws-amplify/data の generateClient 関数を利用して、バックエンドとやり取りするための型付きクライアントインスタンスを作成する React コンポーネントです。 // Frontend import { useState, useEffect } from 'react'; import { generateClient } from 'aws-amplify/data'; import { Schema } from '@/../amplify/data/resource'; export default function HomePage() { const client = generateClient&lt;Schema&gt;(); const [todos, setTodos] = useState&lt;Schema['Todo'][]&gt;([]); useEffect(() =&gt; { async function listTodos() { // fetch all todos const { data } = await client.models.Todo.list(); setTodos(data); } listTodos(); }, []); useEffect(() =&gt; { const sub = client.models.Todo.observeQuery() .subscribe(({ items }) =&gt; setTodos([...items])) return () =&gt; sub.unsubscribe() }, []); return ( &lt;main&gt; &lt;h1&gt;Hello, Amplify 👋&lt;/h1&gt; &lt;button onClick={async () =&gt; { // create a new Todo with the following attributes const { errors, data: newTodo } = await client.models.Todo.create({ content: "This is the todo content", done: false, priority: 'medium' }) console.log(errors, newTodo); }}&gt;Create &lt;/button&gt; &lt;ul&gt; {todos.map((todo) =&gt; ( &lt;li key={todo.id}&gt;{todo.content}&lt;/li&gt; ))} &lt;/ul&gt; &lt;/main&gt; ); } 拡張: Hooks Hooks は、拡張性を付与する実装ツールです。拡張性とは、カスタマイズ、スケーラビリティ、将来を見据えたもの、効率性、そしてコラボレーションを意味します。 Amplify Functions は AWS Lambda に支えられており、サーバーサイドの拡張性を提供します。基盤となるインフラストラクチャを管理せず、アプリケーションにバックエンド機能を拡張できます。Amplify Gen 2 により、開発者は Amazon Cognito でのユーザー認証など、さまざまなイベントに対応するカスタム機能を作成できます。顧客がサインアップした後にビジネスロジックを実行したい状況を考えてみましょう。開発者は Amazon Cognito で post-confirmation トリガーを作成し、カスタムサーバーレス関数で認証フローを強化できます。 // amplify/backend.ts import * as url from 'node:url'; import * as cognito from 'aws-cdk-lib/aws-cognito'; import * as lambda from 'aws-cdk-lib/aws-lambda-nodejs'; import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource.js'; import { data } from './data/resource.js'; const backend = defineBackend({ auth, data }); // create function stack for the auth triggers const authTriggerStack = backend.createStack('AuthTriggerStack'); // create the PostConfirmation trigger const postConfirmationTrigger = new lambda.NodejsFunction( authTriggerStack, 'PostConfirmation', { entry: url.fileURLToPath( new URL('./custom/post-confirmation.ts', import.meta.url) ) } ); // add the newly created trigger to the auth resource const userPool = backend.resources.auth.resources.userPool as cognito.UserPool; userPool.addTrigger( cognito.UserPoolOperation.POST_CONFIRMATION, postConfirmationTrigger ); Amplify Hub イベントはフロントエンドの拡張性を提供します。これにより、フロントエンドアプリケーションのさまざまな部分がリアルタイムで相互通信できるようになります。これは、アプリケーションの状態の変化やユーザー操作に迅速に対応する必要がある、動的で応答性の高いユーザーインターフェイスを作成する場合に特に役立ちます。たとえば、ユーザーがログインすると、フロントエンドのさまざまなコンポーネントがこのイベントに直ちに応答し、それに応じて UI を更新できます。 import { Hub } from "aws-amplify/utils"; const hubListenerCancel = Hub.listen("auth", ({ payload }) =&gt; { switch (payload.event) { case "signedIn": console.log("user have been signedIn successfully."); break; case "signedOut": console.log("user have been signedOut successfully."); break; case "tokenRefresh": console.log("auth tokens have been refreshed."); break; case "tokenRefresh_failure": console.log("failure while refreshing auth tokens."); break; case "signInWithRedirect": console.log("signInWithRedirect API has successfully been resolved."); break; case "signInWithRedirect_failure": console.log("failure while trying to resolve signInWithRedirect API."); break; case "customOAuthState": logger.info("custom state returned from CognitoHosted UI"); break; } }); hubListenerCancel(); // stop listening for messages Amplify Gen2 において、Hooks (サーバーレス関数と UI イベント) は後回しにされるものではなく、意図的にソリューションに組み込まれています。この統合により、開発者は順応性と拡張性に優れ、将来を見据えたアプリケーションを作成するためのツールを手に入れることができます。Amplify Hub イベントによるリアルタイムのインタラクションでフロントエンドを強化するにしても、サーバーレス機能でバックエンドを拡張するにしても、Amplify Gen2 は、現代のアプリケーション開発の限界を押し広げる柔軟性と能力を開発者に提供するように設計されています。 拡張: サービス 開発者は、新しいサービスをアプリケーションに統合するよりも、ソリューションの構築に時間を費やすことを好みます。一般的に、AWS サービスのオーケストレーションをアプリケーションコードに組み込む必要がある場合、多くのコンテキストスイッチが必要です。これらのサービスは手動で作成および管理する必要があり、各サービスの制約を事前に理解しておく必要があります。 この問題を解決し、開発者のエクスペリエンスを向上させるために、Amplify Gen2 は AWS Cloud Development Kit (CDK) の上に階層化されています。つまり、Amplify が生成するリソースを拡張するのに特別な設定は必要ないということです。たとえば、CDK を使用して LocationMapStack というカスタムスタックを作成し、アプリケーションに必要な Amazon Location Service リソースを定義できます。その後、このスタックを amplify/backend.ts ファイルに含めることで、アプリケーションの一部として確実にデプロイできます。 import { CfnOutput, Stack, StackProps } from "aws-cdk-lib"; import * as locations from "aws-cdk-lib/aws-location"; import { Construct } from "constructs"; export class LocationMapStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Create the map resource const map = new locations.CfnMap(this, "LocationMap", { configuration: { style: "VectorEsriStreets", // map style }, description: "My Location Map", mapName: "MyMap", }); new CfnOutput(this, "mapArn", { value: map.attrArn, exportName: "mapArn", }); } } // In amplify/backend.ts const locationStack = backend.createStack("locationStack"); new LocationMapStack(locationStack, "locationstack"); これの最大の利点は、コードエディターを離れる必要がないことです。Amplify の機能を既存の AWS リソースと統合できるため、既存のインフラストラクチャを Amplify の機能とともに活用できます。また、CDK が型を持っているため、 Intellisense から洞察を得ることができ、サービスのドキュメントを事前に読む必要はありません。 デリバリー: Time to Production(TTP) Qovery (トップクラスの社内開発者プラットフォーム)は、” Overcoming Shared Environment Bottlenecks “で、かつてはコラボレーションに効果的だった共有開発環境が、今では生産性のボトルネックを引き起こすことで知られていると書いています。このような環境では、プロジェクトの停滞や開発チームの妨げとなる競合やリソース競合が発生することがよくあります。4 人の開発者が単独でフルスタックの機能に取り組んでいるが、1 つの開発環境を共有しているところを想像してみてください。このような共有環境は、ストレスや遅延の原因となります。各開発者がそれぞれのコンポーネントに変更を加える際には、競合を避け、変更によってアプリケーション全体が損なわれないように、チームメイトと慎重に調整する必要があります。 このシナリオでは、開発者 A はバックエンドコードを熱心に更新しますが、開発者 C がデータベースの変更を完了するまで待つ必要があります。一方、UI を全面的に見直した開発者 B はジレンマに直面しています。コードをプッシュする必要があるが、開発者 D の進行中の統合作業とのコンフリクトの可能性には警戒しているということです。この共有開発環境は、コラボレーションを促進するどころか、進行を妨げ、開発サイクル全体を遅らせるボトルネックになります。 Amplify Gen 2 では、開発者ごとのクラウドサンドボックス環境が導入されています。ローカル開発向けに調整されたこれらの環境では、忠実度の高い AWS バックエンドがリアルタイムでデプロイされるため、開発者は本番環境に近い開発環境で機能を繰り返し開発できます。 このアプローチは、チームがクラウドアプリケーションで共同作業したり反復したりする方法に革命をもたらし、開発時間を大幅に短縮し、本番稼働までの時間(TTP)を短縮します。このプロセスのシンプルさも同様に画期的です。コードの変更を保存するだけで、コードをサンドボックス環境に簡単にデプロイできます。この 4 人の開発者が、お互いの変更によって環境が乱されることなく、フルスタックの機能を個別にシームレスに開発しているところを想像してみてください。 デリバリー: インラインバックエンド 従来のウェブ開発では、フロントエンドとバックエンドの両方のコンポーネントをデプロイするには、多くの設定と複数のステップが必要であり、ストレスの原因となる可能性があります。インラインバックエンドは、フロントエンドとバックエンドを別々にデプロイする必要がないため、デプロイプロセスを合理化し、アプリケーションを本番環境に移行するのに必要なステップを大幅に削減します。この合理化されたアプローチにより、開発者の時間と労力が節約され、デプロイエラーのリスクが最小限に抑えられるため、より信頼性が高く一貫性のある開発環境が保証されます。 Amplify Gen 2 では、コードをコミットするたびにフロントエンドとバックエンドをまとめてデプロイできます。コードファーストアプローチでは、Git リポジトリがフルスタックアプリケーションの状態の信頼できる情報源となることが保証されます。バックエンドのリソースはすべてコードとして再定義され、ブランチ間の再現性と移植性が促進されます。これと環境変数とシークレットの一元管理を組み合わせることで、下位環境から上位環境への昇格ワークフローが簡素化されます。Amplify Gen 2 は、単一プロジェクトのデプロイアプローチを導入し、Git ブランチを共有環境として活用し、コードファーストの理念を採用し、環境変数とシークレットの一元管理を実装することで、フルスタックのアプリケーションデプロイに革命をもたらします。 デリバリー: TypeScript でインフラストラクチャを追加する AWS Amplify Gen 2 はこの変化を利用して、「使い慣れたコードのみ」をモットーとする新しい方法論を提供しています。このアプローチにより、従来のインフラストラクチャ管理ツールや言語に付随する手間が省け、フルスタックの開発者は使い慣れた TypeScript を使用してアプリケーションインフラストラクチャを定義できるようになります。 これまで、インフラストラクチャをセットアップするには、AWS コンソールをナビゲートするか、多数の CLI コマンドを実行する必要がありました。その結果、セットアップの予測が難しくなり、エラーが発生しやすくなることがよくありました。Amplify Gen2 では、Amplify がこのプロセスを変革し、インフラストラクチャの設定を予測可能にし、データ、認証、ストレージサービスなどをサポートするコードと同じ場所に配置できるようになりました。この変更により、インフラストラクチャーの複雑さが制御不能になり、予測不能の原因になりかねないという大きな課題が解決されます。 パスベースの規約 ( amplify/auth/resource.ts や amplify/data/resource.ts など) に従って TypeScript としてインフラストラクチャをファイルに作成することで、開発者は Visual Studio Code の厳密な型指定と IntelliSense を活用してエラーを最小限に抑えることができます。バックエンドに重大な変更があった場合、フロントエンドコードで型エラーが発生し、開発者へ即座にフィードバックされます。このフィードバックループによってフロントエンドコードの信頼性を確保し、開発者が自信を持って開発を進めることができます。 import { defineAuth } from "@aws-amplify/backend"; import secret from "@aws-amplify/backend"; export const auth = defineAuth({ loginWith: { email: { verificationEmailSubject: "Welcome, verify your email", }, externalProviders: { loginWithAmazon: { clientId: secret("LOGINWITHAMAZON_CLIENT_ID"), clientSecret: secret("LOGINWITHAMAZON_CLIENT_SECRET"), }, }, }, multifactor: { mode: "OPTIONAL", sms: { smsMessage: (code) =&gt; `Your verification code is ${code}`, }, }, userAttributes: { profilePicture: { mutable: true, required: false, }, }, }); Amplify Gen2 の TypeScript のインフラストラクチャは、「設定より規約」の原則を体現しており、インフラストラクチャを管理するための明確で体系的な方法を提供します。つまり、開発者はコードエディターで快適に操作でき、その場でドキュメントにアクセスでき、コンテキストの切り替えによる中断を回避できます。 まとめ AWS Amplify のコードファーストアプローチは、カスタマーエクスペリエンスを優先し、AWS サービスを活用することで、ウェブ開発に革命をもたらしています。このアプローチにより、開発者は顧客のニーズを満たす堅牢でスケーラブルなフルスタックアプリケーションを作成できます。 このアプローチの主なメッセージには、コードからのインフラストラクチャ機能、インフラストラクチャを定義するコードを記述する機能、フルスタック開発用の TypeScript、保存時の変更のプレビュー、コード生成、設定不要のフルスタックデプロイなどがあります。これらのパラダイムを採用することで、開発者は TypeScript を使用してアプリケーションを構築し、迅速に開発サイクルを反復して、アプリケーションを簡単にスケーリングできます。AWS Amplify のコードファーストアプローチは、開発者に強力なツールとシームレスな開発体験を提供することで、ウェブ開発の未来を形作っています。 この記事は Christian Nwamba による “ The future of web development: AWS Amplify’s Code First Approach ” を和訳したものです。翻訳はソリューションアーキテクトの 髙柴 が担当しました。