Amzon Bedrock や ChatGPT のように API 経由で呼び出せる基盤モデルの精度とコストは実用的なレベルに到達しています。一方で、皆さんが開発している製品やサービス、プロダクトには様々なデータが蓄積されていると思います。そのデータで機械学習モデルを学習できれば、より顧客のニーズに合った体験を提供できます。体験が改善されればより多く顧客が集まり、そこから得られるデータはさらなるモデルの改善につながります。 API で利用できるモデルは追加学習なしに高い精度で推論できるものの、最初から顧客が満足するレベルの精度が出せるとは限りません。例えばカスタマーサポートの応対で使う場合、顧客の言葉の意味を取り違えたり、応対マニュアルと異なる対応や回答を伝えてしまう可能性があります。蓄積されたデータから不適切な回答を抜き出し、分析結果をもとに基盤モデルへの指示方法 ( プロンプト ) やモデル自体を調整できれば、より顧客のニーズに沿った体験を提供できます。 本文書では、 蓄積したデータによる精度改善を視野に入れた場合、 API と OSS のどちらがコスト効率が良くなるのか を検証します。 OSS とは、 Hugging Face などで公開されている基盤モデルをカスタマイズし、ホスティングする利用形態を想定しています。学習なしの推論で OSS のモデルが API 経由で利用できるモデルに並ぶのは現時点で難しいですが、学習データがあるなら話は変わってきます。 API の場合はプロンプトの修正 (Prompt Engineering) が精度改善の主な手段ですが、 OSS ではモデルの追加学習 (Fine Tuning: 本記事では Instruction Tuning を指します ) も選択肢になります。最近では対話形式に沿うよう学習 (Instruction Tuning) されたモデルが次々と公開されているため、 素の基盤モデルを用いた前回の検証 よりも少ないデータ量で API に並ぶ精度が得られると期待されます。 実験では、API として Amazon Bedrock で利用できる Claude と Claude Instant の 2 つ、OSS として open-calm-1b 、 japanese-gpt-neox-3.6b-instruction-ppo 、 bilingual-gpt-neox-4b-instruction-ppo 、 ELYZA-japanese-Llama-2-7b-instruct 、 Swallow-13b-instruct-hf の 5 つを使用しました。 1b 、 3b 、 7b 、10b クラスのモデルを取りそろえた形です。 モデル名 公開元 種別 概要 Claude v2.1 Anthropic API Anthropic の提供する高性能な基盤モデル。 Hugging Face の Leaderboard では GPT-4 などに次ぐ精度。日本語性能でも、 Rakuda Ranking などでトップレベルの性能を示す。 20 万トークンという長大なテキストを扱える。 Claude Instant Anthropic API 高速な応答に重点を置いたモデル。 10 万トークンという長大なテキストを扱える。 open-calm-1b CyberAgent OSS 株式会社サイバーエージェントから公開された GPT-NeoX ベースの日本語大規模言語モデル。 japanese-gpt-neox-3.6b-instruction-ppo rinna OSS rinna 株式会社から公開された日本語で学習された GPT-NeoX ベースの大規模言語モデル。対話形式のデータで教師あり学習、強化学習が行われた日本語大規模言語モデル。 bilingual-gpt-neox-4b-instruction-ppo rinna OSS rinna 株式会社から公開された日英両言語で学習された GPT-NeoX ベースの大規模言語モデル。対話形式のデータで教師あり学習、強化学習を行っている。 ELYZA-japanese-Llama-2-7b-instruct ELYZA OSS 株式会社 ELYZA から公開された、 Meta の Llama2 をもとに日本語コーパスで継続学習した大規模言語モデル。独自データでの教師あり学習を行っている。 Swallow-13b-instruct-hf 東工大 / 産総研 OSS 東工大と産総研の研究チームから公開された、Meta の Llama2 をもとに日本語コーパスで継続学習した大規模言語モデル。 Claude 2.1 は GPT-4 、 Claude Instant は ChatGPT 3.5 に近しい精度なので値は読み替えていただけると思います。評価用のデータセットは幅広な選択肢がありますが、今回は JGLUE の中でも質問回答のデータセットである JSQuAD を使用しました。 JSQuAD には、 Wikipedia の文書とそれに関する質問、質問に対する回答箇所が収録されています。近年、検索と生成を組み合わせた RAG (Retrieval Augmented Generation) と呼ばれる手法が注目されていますが、検索結果から要求に応じた情報を抽出するタスクは JSQuAD の形式に近く、 RAG で使用するモデルを選ぶ際の参考指標となり得ると考えたためです。 本記事では、気になる実験結果を先に提示し、のちのセクションで実験の内容について詳細に解説します。 API と OSS のコスト効率の比較結果 コスト効率とは、精度とコストの比率を指します。精度、コストの比較結果を示し最後にコスト効率について示します。 精度は次の図の結果となりました。縦軸は F1 という実際の回答と出力された回答がどれだけオーバーラップしているかを表す指標 ( 後述します ) 、横軸は使用した JSQuAD の学習データの件数です。API である Claude についてはプロンプトに含めた例示 ( データ ) の数、 OSS については追加学習に使用したデータの件数を示します。 API か OSS かで「データ件数」の意味が異なる点、また件数が対数軸になっている点にはご注意ください。追加学習には LoRA の手法を用い、ハイパーパラメーターやエポック数などの設定は各データ件数でそろえていますが、規定時間以内に終わらなかった学習は途中で打ち切っています。 この結果からは、次の 5 つの示唆が得られます (Claude をハイエンドのモデル、 Claude Instant を軽量なモデルと表現しています )。なお、得られる示唆は質問回答タスクに限定される点に注意してください。 1) 10B クラスの日本語 OSS モデルは、ハイエンドの API モデルを利用する場合の精度に匹敵する。 2) 7B クラスの日本語 OSS モデルでも、 30 件以上のデータがあれば追加学習で軽量な API モデルの精度に匹敵する。 3) 7B クラスの日本語 OSS モデルでも、 500 件以上のデータがあれば追加学習でハイエンドの API モデルの精度に匹敵する。 4) 4B 以下のモデルは追加学習しても API 経由のモデルの精度に至らず、また過学習により精度が下がる可能性がある。 5) プロンプトの例示は 2 件あれば十分効果が得られる。 続いて、コストを示します。縦軸は金額 ($) 、横軸はデータ件数です。金額は OSS の場合学習にかかった費用と検証データセットの推論にかかった費用の合計、 API の場合推論にかかった費用のみになります。 API では、ハイエンドのモデルは性能が高い分、やはり費用がかかることがわかります。 OSS では、おおむね 4000 件を超えたあたりから学習コストに対し得られる性能が割に合わなくなることが読み取れます ( 4B の rinna のモデルで少し跳ねがありますが、全体の傾向に影響ないと見ています ) 。先ほどの例から、十分な精度が得られるのは 500 件程度のため、あまり大量の学習データを用意するのは経済的ではないと言えそうです。 最後に、コスト効率の目安として F1 の値を学習コストで割った値をプロットした図を示します。 $1 の学習コストを払うことでどれくらい精度である F1 が向上するか、つまりコスト効率を示す指標になります。 7B のモデルである ELYZA が 32 件の時に突出しており、以後基本的には下がることがわかります。 1B の OpenCALM や 4B の rinna は初期コスト効率が低いものの 500 件近辺で持ち直し、以後は他のモデル含め下降傾向を示しています。そのため、まず 30 件以上、 500 件までは十分な費用対効果が期待できると言えると思います。この知見は、モデルにとって適切なプロンプトを探索したい場合どの程度データ件数をそれぞれ用意すればよいのかの疑問にも示唆を与える結果です。 質問回答タスクに基づく検証から、 API と OSS の使い分けは以下のようにするとよいのではないかという示唆が得られます。なお、文中では冗長性を省くため断定的に書いていますが、あくまで質問回答データセットを用いた本実験から得られる示唆と認識ください 。 API 経由で利用し精度に課題がある場合、 2 つ程度プロンプトに例示入れることで確かな精度の向上を確認できる。 Claude Instant 、あるいは ChatGPT 3.5 相当の精度は 7B クラスのモデルを 30 件以上のデータで追加学習することで到達できる。精度が十分であり、安定性や速度の課題がホスティング費用に勝るなら切り替える価値がある。 Claude 2.1 、あるいは GPT-4 相当の精度が必要な場合、 1) 10B クラスの OSS モデルを使用するか、 2) 7B クラスの OSS モデルを 500 件程度のデータで追加学習し目的の精度が得られるか検証する。精度が十分得られ、安定性や速度の課題がホスティング費用に勝るなら切り替える価値がある。 以下のセクションでは、結論に至るまでの実験設定について記載します。今後、他モデルの数、また要約や分類といった他のタスクについても検証を検討しています。 API と OSS の基盤モデル 現在、基盤モデルを利用する選択肢は大きく分けて API と OSS の 2 つがあります。 API は ChatGPT や Amazon Bedrock のように Web API 経由で基盤モデルを利用する形式です。基盤モデルをホスティングするインフラを意識することなく使うことができ、多くの場合処理したトークン数に応じて費用を支払います。 Anthropic の Claude や OpenAI の ChatGPT など、非常に性能が高いモデルを安価に利用できることが特徴です。トークン数に応じて課金されるため、詳細なプロンプトや例示を書くほどコストがかかることになります。 OSS は Hugging Face などで公開されているオープンソースのモデルを GPU インスタンス等にホスティングして利用します。推論用のコードやインフラを準備する手間があるものの、一度立ち上げてしまえば API リクエスト数や処理トークン数を意識することなく使用できます。 また、 API 提供者の設定するリクエスト制限、サービス停止などの影響を受けることもありません。 Amazon SageMaker JumpStart を使えば、モデルのホスティングもボタン操作のみで行えます。現在、 rinna と Stability AI の日本語モデルが掲載されており、今後も増える予定です。 OSS であるため、手元のデータで追加学習しカスタマイズすることもできます ( 追加学習、また追加学習後のモデルの利用と公開についてはライセンスを注意深く確認してください ) 。カスタマイズは API でもできるようになってきていますが、 Amazon Bedrock では 時間単位課金のモデルユニットが必要 であり、 ChatGPT でも カスタマイズしたモデルを使うときの料金は 3 倍近くになります (2024/1/31 時点) 。追加学習後の推論のコスト効率を考える場合、 OSS のモデルは良い選択肢になるでしょう。 評価手法 : データセット 今回は評価に JSQuAD という質問回答のデータセットを使用します。中のデータは次のような形式をしています。 SQuAD (The Stanford Question Answering Dataset) というデータセットを参考に作成されており、 Wikipedia の記事 ( context ) に対する質問 ( question ) と回答 ( answers ) が収録されています ( answers は 1 件のみです)。 SQuAD2.0 では context に答えがない場合 is_impossible : true のケースが存在しますが、 JSQuAD は SQuAD 1.1 をベースにしており答えられない質問は含まれていません。 { "title": "東海道新幹線 (Tokaido Shinkansen)", "paragraphs": [ { "qas": [ { "question": "2020年（令和2年）3月現在、東京駅 - 新大阪駅間の最高速度はどのくらいか。 (What is the maximum speed between Tokyo Station and Shin-Osaka Station as of March 2020?)", "id": "a1531320p0q0", "answers": [ { "text": "285 km/h", "answer_start": 182 } ], "is_impossible": false }, { .. } ], "context": "東海道新幹線 [SEP] 1987年（昭和62年）4月1日の国鉄分割民営化により、JR東海が運営を継承した。西日本旅客鉄道（JR西日本）が継承した山陽新幹線とは相互乗り入れが行われており、東海道新幹線区間のみで運転される列車にもJR西日本所有の車両が使用されることがある。2020年（令和2年）3月現在、東京駅 - 新大阪駅間の所要時間は最速2時間21分、最高速度285 km/hで運行されている。" } ] } 1 つの context には複数の質問があります。同じ context のデータは類似性が高いため、学習データを作る際は context が重複しないようにしています ( データ数が 15,000 件までは重複させないことができました ) 。 JSQuAD の学習データからランダムにサンプリングしデータ件数ごとの学習データを作成します。データを全く与えない場合を 0、そこから 2 、 4 、 8 、 16 ・・・と 2 の倍数刻みで 8192 件まで context の重複がないようランダムに選択したデータセットを用意しました。さらに、 15652 件 ( context 重複なしで作れる最大のデータ数 )、31005 件( context 重複を最大 2 回許可)、45576 件( context 重複を最大 3 回許可)、57086 件( context 重複を最大 4 回許可)、62859 件( context 重複が最大 5 件、 JSQuAD 内の全質問)のデータセットを用意しました。件数ごとのデータセットについて、 API はプロンプト内の例示に、 OSS ではモデルの追加学習に使用します。データが少なすぎると追加学習が困難なので、 追加学習は 8 件からスタートをしています。逆に、 API のプロンプトに入力できる事例数は 8 件を上限にしています。今回、評価データセット全件を評価するために Amazon Bedrock で Preview 中の Batch inference の機能 を使用したのですが、その容量の制限上この値に留めています。 128 件入れた研究もあり ( Cold-Start Data Selection for Few-shot Language Model Fine-tuning: A Prompt-Based Uncertainty Propagation Approach ) 、 Claude は 20 万トークンものサイズを扱えるので GA した際には推論可能な量も増えることを期待しています。 評価手法 : 精度の算出 JSQuAD の問題を基盤モデルで解き精度を計測するにはどうすればよいでしょうか ? 例えば、 Claude の場合は次のようにプロンプトを与えています。 input には context 、instruction には question が入ります。基盤モデルの回答と answers が一致するかで精度を評価します。 Human: 与えられたinputからinstructionに対する回答を抽出する関数を実行してください。 入出力のexampleを示します。 <example> <input>・・・</input> <instruction>・・・</instruction> Answer:xxxxx </example> <example> <input>・・・</input> <instruction>・・・</instruction> Answer:xxxxx </example> 次のinputからinstructionに対する回答を抽出してください。結果はAnswer:の後に記載し名詞以外何も含まないことを厳守してください。 <input>・・・</input> <instruction>・・・</instruction> Assistant:Answer: 精度は回答と完全に一致した Exact Match の数、予測の中にどれだけ回答と一致する文字が含まれるかを計測する F1 で行います。 JSQuAD の評価において、 F1 は文字単位で計算します。英語では単語単位なのですが、日本語の場合形態素解析の仕方で評価が揺らいでしまうためです 。 「 285 km/h 」が正解の場合、 “285 km/h” と完全に回答できれば Exact Match ですが “285” だと Exact Match にはなりません。 F1 の場合 “2” “8” “5” は一致していると評価されるのでより寛容な評価になります。ただ、今回評価に使用した lm-evaluation-harness では JSQuAD の評価を単語単位で計算している ので、本記事の F1 の値は本来の値とは少し異なります。上記は Claude の例を示しましたが、プロンプトの形式は各 API / OSS の形式に準じます。例えば、 Claude であれば \n\nHuman: と \n\nAssistant: の対話形式に、 OSS では例えば rinna のモデルであれば "ユーザー: " or "システム: " の形式に合わせます。 lm-evaluation-harness ではタスクの指定でプロンプトのテンプレートを切り替えることができます。例えば、 rinna 用のテンプレートは jsquad-1.1-0.4 になります。 評価手法 : コストの算出 コストはどう評価すればよいでしょうか ? 学習と推論の 2 つのコストがあります。 OSS の場合は学習と推論にかかったコスト、 API の場合は推論のみにかかったコストが計上対象となります。 OSS のモデルの学習は、 OpenCALM の検証 の時と同じ実装を使用しました。 aws-ml-jp 上のサンプルを使用することで、 Notebook を実行するのみで簡単に Hugging Face 上のモデルを LoRA 形式で追加学習できます 。テンプレートはモデルごと合ったものを使用し、 3 エポック学習を回しています。学習に使用したインスタンスは NVIDIA A10G の GPU が搭載された g5.2xlarge なので、インスタンスの時間当たりの単価と学習にかかった時間をかけ合わせればコストが計算できます。次の図は ELYZA の学習時間を示した図です。 価格を計算する際は、オンデマンド価格を参照しました ( 執筆時点で $1.212 / 時間 ) 。精度が十分な値になる 512 件では学習に 15 分程度、金額にして 44 円ぐらいになります。 小学校の遠足のおやつ代は平均 426 円 とのことなので、約 1/10 の金額でモデルが遠足に行って成長して帰ってくると考えると割安と感じます。スポットインスタンスなどを利用すればより安価になります。推論も同様にかかった時間に単価をかけて計算しましたが、 Swallow のみ g5.2xlarge に乗せるため 8bit の量子化をしています。 API のコストは、入出力のトークン数から計算します。ただし、評価用データ (validation dataset) が 4000 件近くあり、普通に 1 件 1 件推論しているとあっという間に 1 分当たりのリクエスト上限 に達してしまいます。そのため、  Preview 中の Batch inference の機能 を使用しました。次に Batch inference のサンプルコードを示します。 Amazon Simple Storage Service にデータをアップロードし、 create_model_invocation_job  を実行します。 roleArn は Permission を参照し作成したロールの arn を設定します。 import time import boto3 bedrock = boto3.client(service_name="bedrock") inputDataConfig = ({ "s3InputDataConfig": { "s3Uri": "s3://input-bucket/input/abc.jsonl" } }) outputDataConfig = ({ "s3OutputDataConfig": { "s3Uri": "s3://output-bucket/output/" } }) response = bedrock.create_model_invocation_job( roleArn="arn:aws:iam::123456789012:role/MyBatchInferenceRole", modelId="amazon.titan-text-express-v1", jobName="my-batch-job", inputDataConfig=inputDataConfig, outputDataConfig=outputDataConfig ) job_id = response.get('jobArn') status = 'Begin' while status not in ('Completed', 'Failed', 'Stopped'): time.sleep(5) status = bedrock.get_model_invocation_job(jobIdentifier=job_id)[ "status" ] 定期的に get_model_invocation_job を実行しステータスを確認します。私が実行したところ、ジョブが実行開始になるまで ( Submitted から InProgress になるまで ) 数時間待たされることもあり、 Preview 以後改善されることを期待しています。 Batch inference は推論結果だけでなく、そのバッチで入出力されたトークン数が出力されます。以下は、 2 shot でプロンプトを書いたときの結果です。入出力のトークン数にそれぞれの単価をかけることでコストを算出できます。 { "processedRecordCount":4442, "successRecordCount":4442, "errorRecordCount":0, "inputTokenCount":3418270, "outputTokenCount":50038 } 実験コードは以下で公開しています。 Batch inference の実装サンプルはまだ少ないと思いますので、参考にしていただければ幸いです！ https://github.com/aws-samples/aws-ml-jp/pull/66 実験結果と今後の展望 実験結果は冒頭ご紹介した通りです。どれぐらいのデータがあれば OSS で公開されているモデルを追加学習し期待の精度が得られるのか、参考となる指標を示すことができたと思います。インスタンスをホスティングする場合常時稼働する点がネックになりますが、文書解析などリアルタイムで行う必要がないもの、ゲームなどで多様なキャラクターのバリエーションが必要でアクセス頻度も高い場合など、カスタマイズ性とホスティングによるレスポンスの速度や安定性が光るシーンは多々あると考えています。また、モデルを量子化しさらに C++ で最適化することで AWS Lambda 上で推論するなどできれば、実質サーバーレスの API と同等の体験が実現できるでしょう。 今後は、他タスクでの検証、また 7B のモデルを軸にサーバーレス形式での推論が行えないかなどを深堀できればと考えています。 著者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。 前川 泰毅 (Taiki Maekawa) は AWS Japan のソリューションアーキテクトでメディア領域のお客様中心にアーキテクチャ設計や構築を支援しています。機械学習領域を得意としておりソリューションやサンプルコードの作成を行っています。 呉 和仁 (Go Kazuhito) は AWS Japan の機械学習ソリューションアーキテクト。 IoT の DWH 開発、データサイエンティスト兼業務コンサルタントを経て現職。プログラマの三大美徳である怠惰だけを極めてしまい、モデル構築を怠けられる AWS の AI サービスをこよなく愛す。

テキストからの画像生成 (text-to-Image) は、AIの急速に成長している分野であり、メディアとエンターテインメント、ゲーム、eコマース製品の視覚化、広告とマーケティング、建築設計と視覚化、芸術作品、医療画像など、さまざまな分野で応用されています。 Stable Diffusion は、text-to-Image モデルで、高品質の画像を数秒で作成できます。AWSは2022 年 11 月に、モデル、アルゴリズム、ソリューションを提供する機械学習 (ML) ハブである Amazon SageMaker JumpStart で、 Stable Diffusion のモデルを使用して、テキストから画像を生成できることを 発表しました 。2023年4月に Amazon Bedrock が導入され、その進化は続きました。Amazon Bedrockは、便利なAPIを通じて Stable Diffusion を含む最先端の基盤モデルへのアクセスを提供するフルマネージドサービスです。 text-to-image の取り組みに着手する顧客の数が増え続けるにつれ、共通のハードルが生じます。それは、高品質で目的に基づいた画像を生成するためのプロンプトを、どのように作成するかということです。この課題では、ユーザーが自分のビジョンに合ったプロンプトを見つけるために繰り返し実験を行うため、かなりの時間とリソースが必要になることがよくあります。 RAGは、言語モデルが外部データソースからコンテキストドキュメントを取得し、この情報を使用してより正確で有益なテキストを生成するプロセスです。この手法は、知識集約型の自然言語処理 (NLP) タスクに特に役立ちます。私たちは今、その変革的な手法をtext-to-image の世界にまで広げています。このブログでは、検索拡張生成（RAG） の力を利用して Stable Diffusion モデルに送信されるプロンプトを強化する方法を示します。Amazon Bedrock と SageMaker JumpStart では、大規模言語モデル (LLM) を使用して、プロンプト生成用の独自の AI アシスタントを数分で作成できます。 text-to-image のプロンプトの作成方法 text-to-image モデルのプロンプトの作成は、一見簡単そうに見えるかもしれませんが、実は複雑な作業です。単に言葉をいくつか入力して、モデルがあなたの心の中のイメージに合った画像を並べることを期待するだけの作業ではありません。効果的なプロンプトは、創造性の余地を残しながら、明確な指示を提供する必要があります。具体性とあいまいさのバランスを取る必要があり、使用する特定のモデルに合わせて調整する必要があります。プロンプトエンジニアリングの課題に対処するために、業界ではさまざまなアプローチを模索してきました。 プロンプトライブラリ — 一部の企業では、ユーザーがアクセスしてカスタマイズできる事前に作成されたプロンプトのライブラリを用意しています。これらのライブラリには、さまざまなユースケースに合わせたさまざまなプロンプトが含まれているため、特定のニーズに合わせてプロンプトを選択または調整できます。 プロンプトテンプレートとガイドライン — 多くの企業や組織は、定義済みのプロンプトテンプレートとガイドラインのセットをユーザーに提供しています。これらのテンプレートが提供するプロンプトを書くための構造化されたフォーマットにより、効果的な指示を簡単に作成できます。 コミュニティとユーザーの貢献 — 多くの場合、クラウドソーシングプラットフォームとユーザーコミュニティは、プロンプトを改善する上で重要な役割を果たします。ユーザーは、微調整したモデル、成功したプロンプト、ヒント、ベストプラクティスをコミュニティと共有して、他のユーザーがプロンプト作成スキルを学んだり磨いたりするのに役立てます。 モデルの微調整 — 企業は、特定の種類のプロンプトをよりよく理解して対応できるように、text-to-image モデルを微調整する場合があります。微調整を行うと、特定のドメインやユースケースのモデルパフォーマンスを向上させることができます。 これらの業界アプローチは、効果的な text-to-image プロンプトを作成するプロセスを、より利用しやすくユーザーフレンドリーで効率的なものにし、最終的には、幅広い用途における text-to-image モデルの使いやすさと汎用性を高めることを目的としています。 プロンプトデザインに RAG を使用する このセクションでは、これらの既存のアプローチと調和しながら、RAG の手法がプロンプトエンジニアリングのゲームチェンジャーとしてどのように役立つかについて詳しく説明します。RAG をプロセスにシームレスに統合することで、迅速な設計の合理化と効率の向上が可能になります。 プロンプトデータベースでのセマンティック検索 プロンプトの膨大なリポジトリをプロンプトライブラリに蓄積したり、特定のユースケースや目的に合わせて設計された多数のプロンプトテンプレートを作成したりしている企業を想像してみてください。従来、text-to-image プロンプトのインスピレーションを求めるユーザーは、これらのライブラリを手動で閲覧し、多くの場合、広範なオプションのリストをふるいにかけていました。このプロセスは時間がかかり、非効率的です。テキスト埋め込みモデルを使用してプロンプトライブラリからプロンプトを埋め込むことで、企業はセマンティック検索エンジンを構築できます。仕組みは次のとおりです。 プロンプトの埋め込み — 企業はテキスト埋め込みを使用して、ライブラリ内の各プロンプトを数値表現に変換します。これらの埋め込みは、プロンプトのセマンティックな意味とコンテキストをキャプチャします。 ユーザークエリ — ユーザーが独自のプロンプトを入力したり、希望する画像を説明したりすると、システムはその入力を分析して埋め込むこともできます。 セマンティック検索 — テキスト埋め込みを使用して、システムはセマンティック検索を実行します。ユーザーの入力とプロンプトライブラリの履歴データの両方を考慮して、ユーザーのクエリに基づいてライブラリから最も関連性の高いプロンプトを取得します。 プロンプトライブラリにセマンティック検索を実装することで、企業は従業員が膨大な量のプロンプトに簡単にアクセスできるようになります。このアプローチは、迅速な作成を促進するだけでなく、text-to-image の生成おける創造性と一貫性を促進します。 セマンティック検索からのプロンプト生成 セマンティック検索は関連するプロンプトを見つけるプロセスを合理化しますが、RAG はこれらの検索結果を使用して最適化されたプロンプトを生成する点で、さらに一歩進んでいます。仕組みは次のとおりです。 セマンティック検索結果 — ライブラリから最も関連性の高いプロンプトを取得すると、システムはこれらのプロンプトをユーザーの元の入力と一緒にユーザーに表示します。 テキスト生成モデル — ユーザーは検索結果からプロンプトを選択したり、好みの詳細情報を提供したりできます。システムは、選択したプロンプトとユーザーの入力の両方を LLM に送ります。 最適化されたプロンプト — LLM は、言語のニュアンスを理解した上で、選択したプロンプトの要素とユーザーの入力を組み合わせて最適化されたプロンプトを作成します。この新しいプロンプトは、ユーザーの要件に合わせて調整され、目的の画像出力が得られるように設計されています。 セマンティック検索とプロンプト生成を組み合わせると、プロンプトを検索するプロセスが簡単になるだけでなく、生成されるプロンプトの関連性が高く効果的なものになります。これにより、プロンプトの微調整とカスタマイズが可能になり、最終的には text-to-image の生成結果が向上します。以下は、セマンティック検索とプロンプト生成のプロンプトを使用して Stable Diffusion XL から生成された画像の例です。 オリジナルのプロンプト セマンティック検索からのプロンプト LLMで最適化されたプロンプト 子犬のイラストレーション 森の中を散歩する少年と犬のイラスト擬人化された犬の漫画イラスト、アニメスタイル、白い背景 コーギーの子犬を描いたペーパークラフト。とってもキュート、かわいい、ハッピー 夕食のテーブルでサンドイッチを食べているかわいい犬のアニメーション、イラスト 森の中を散歩する少年と子犬のイラストレーション さまざまな業界にわたる RAG ベースのプロンプトデザインアプリケーション 推奨する RAG アーキテクチャを検討する前に、画像生成モデルが最も適用しやすい業界から始めましょう。アドテックでは、スピードと創造性が重要です。RAG ベースのプロンプト生成は、広告キャンペーン用に多数の画像をすばやく作成するためのプロンプトを提案できるので、即座に価値を高めることができます。人間の意思決定者は、自動生成された画像を確認して、キャンペーンの候補画像を選択できます。この機能は、スタンドアロンアプリケーションにすることも、現在利用可能な一般的なソフトウェアツールやプラットフォームに組み込むこともできます。 Stable Diffusion モデルが生産性を高めることができるもう1つの業界は、メディアとエンターテイメントです。RAG アーキテクチャは、たとえばアバター作成のユースケースに役立ちます。シンプルなプロンプトから始めて、RAG はアバターのアイデアにもっと多くの色や特徴を加えることができます。多くのプロンプト候補を生成し、より創造的なアイデアを提供できます。これらの生成された画像から、特定のアプリケーションに最適な画像を見つけることができます。多くの迅速な提案が自動的に生成されるため、生産性が向上します。考えられるバリエーションこそが、ソリューションの直接的なメリットです。 ソリューション概要 お客様が独自の RAG ベースの AI アシスタントを構築して、AWS 上で迅速な設計を行えるようにしたことは、現代のテクノロジーの多用途性の証です。AWS は、この取り組みを促進するためのオプションとサービスを多数提供しています。次のリファレンスアーキテクチャ図は、AWS でのプロンプト設計用の RAG アプリケーションを示しています。 AI アシスタントに適切な LLM を選択する場合、AWS ではお客様固有の要件を満たすさまざまな選択肢を用意しています。 まず、専用インスタンスを利用して SageMaker JumpStart から入手できる LLM を選択できます。これらのインスタンスは、Falcon、Llama 2、Bloom Z、Flan-T5 などのさまざまなモデルをサポートしています。また、Cohere の Command と Multilingual Embedding や AI21 Labs の Jurassic-2 などの独自のモデルを試すこともできます。 よりシンプルなアプローチをご希望の場合は、AWS が Amazon Bedrock で Amazon Titan や Anthropic Claude などの LLM を提供しています。これらのモデルには、簡単な API 呼び出しで簡単にアクセスできるため、その機能を簡単に活用できます。柔軟性と多様なオプションにより、オープンコンテナによるイノベーションを求める場合でも、独自のモデルの堅牢な機能を求める場合でも、プロンプトデザインの目的に最も合致する LLM を自由に選択できます。 重要なベクトルデータベースの構築に関しては、AWS はネイティブサービスを通じて多数のオプションを提供しています。 Amazon OpenSearch Service 、 Amazon Aurora 、または Amazon Relational Database Service (Amazon RDS) for PostgreSQL を選択できます。それぞれが特定のニーズに合わせて堅牢な機能を提供します。あるいは、Pinecone、Weaviate、Elastic、Milvus、Chroma などの AWS パートナーが提供する、ベクトルの効率的な保存と検索に特化したソリューションを提供する製品を探すこともできます。 プロンプトデザインのための RAG ベースの AI アシスタントの構築に役立つように、 GitHub リポジトリに包括的なデモンストレーションをまとめました。このデモンストレーションでは、次のリソースを使用します。 画像生成：Amazon Bedrock の Stable Diffusion XL テキスト埋め込み：Amazon Bedrock の Amazon Titan テキスト生成：Amazon Bedrock の Claude 2 ベクトルデータベース：FAISS (効率的な類似検索のためのオープンソースライブラリ) プロンプトライブラリ：text-to-image 生成モデル用の最初の大規模プロンプトギャラリーデータセットである DiffusionDB のプロンプトサンプル さらに、LLM の実装には LangChain を、Web アプリケーションコンポーネントには Streamit を組み込んで、シームレスでユーザーフレンドリーなエクスペリエンスを提供しています。 前提条件 このデモアプリケーションを実行するには、次のものが必要です。 AWS アカウント Amazon SageMaker Studio の操作方法に関する基本的な理解 GitHub からリポジトリをダウンロードする方法の基本的な理解 ターミナルでのコマンド実行に関する基本的な知識 デモアプリケーションを実行する 必要なすべてのコードは、 GitHub リポジトリから指示とともにダウンロードできます。アプリケーションがデプロイされると、次のスクリーンショットのようなページが表示されます。 このデモンストレーションでは、実装プロセスをわかりやすくわかりやすくすることを目指しています。実践的な経験を積んで、RAG の世界への旅をスタートさせ、AWS で設計を迅速に行えるようにします。 クリーンアップ アプリを試した後、アプリケーションを停止してリソースをクリーンアップします。 結論 RAG は、Stable Diffusion の text-to-image 機能を復活させ、プロンプト・デザインの世界における画期的なパラダイムとして台頭してきました。RAG のテクニックを既存のアプローチと調和させ、AWS の強力なリソースを使用することで、創造性を合理化し、学習を促進する道筋が見えてきました。 その他のリソースについては、以下をご覧ください。 Stability.ai official website Stability.ai Stable Diffusion XL 1.0 release notes Amazon Bedrock User Guide Amazon SageMaker JumpStart Developer Guide Build Streamlit apps in Amazon SageMaker Studio 翻訳はソリューションアーキテクトの濱野谷(@yoshiehm)が担当しました。原文は こちら です。 著者について James Yi は、アマゾン ウェブ サービスのエマージングテクノロジーチームのシニア AI/ML パートナーソリューションアーキテクトです。彼は、企業の顧客やパートナーと協力して、AI/ML アプリケーションの設計、デプロイ、スケーリングを行い、ビジネス価値を引き出すことに情熱を注いでいます。仕事以外では、サッカー、旅行、家族との時間を楽しんでいます。 Rumi Olsen は AWS パートナープログラムのソリューションアーキテクトです。現在の職務ではサーバーレスソリューションと機械学習ソリューションを専門としており、自然言語処理技術のバックグラウンドも持っています。彼女は余暇のほとんどを娘と過ごし、太平洋岸北西部の自然を探索しています。

この記事は、2024 年 1 月 30 日に Pam Brown によって投稿された AWS Certification retirements and launches を翻訳したものです。 2024 年 4 月に、 AWS Certified Data Analytics – Specialty (DAS) 、 AWS Certified Database – Specialty (DBS) 、 AWS Certified: SAP on AWS – Specialty (PAS) の 3 つの AWS 認定を廃止します。 テクノロジーの変化の速さを考慮して、私たちは常に認定を見直し、お客様のニーズにどの程度応えているかを評価しています。私たちは、Specialty の AWS 認定の数を減らし、Foundational、Associate、Professional の AWS 認定を強化することで、お客様により良いサービスを提供する機会があると考えています。 データ活用の専門知識に対する需要の高まり この取り組みの一例として、 2024 年に新たに AWS Certified Data Engineer – Associate (DEA) を開始します。 World Economic Forum によると、2025 年までに、世界中で毎日約 463 エクサバイトのデータ（2 億 1,270 万枚の DVD に相当）が生成されると予測されています。データの急激な増加により、あらゆる業界でデータエンジニア、データアナリスト、データサイエンティストなどの専門家の必要性が高まっています。 IDC * によると、テクノロジーの急速な進歩と専門的なスキルの必要性により、データに関する専門知識を持つ人材の需要が高まっています。しかし、人材プールが限られているため、組織は適切な人材を適切な役割に配置することが困難になっています。このことは、北米の IT リーダーが最も困難であると報告しており、55% がデータエンジニアの職務に就くのが難しいと回答しています。 AWS Certified Data Engineer – Associate (DEA) は、データ関連の AWS サービスにおける個人のスキルと知識を検証し、ビジネス成果につながるインサイトのために質の高いデータを分析、操作、保証できる有能なデータエンジニアを育成して雇用する手段を雇用者に提供します。この新しい AWS 認定は、2024 年 3 月 12 日から予約と受験が可能になる予定です。 *IDC, What AI and Data Roles Are Most Difficult to Fill at Enterprises Worldwide?, Doc:# US50846023, June 2023 廃止予定の AWS 認定 廃止予定の 3 つの AWS 認定のいずれかを保有している場合、その認定は取得日から 3 年間有効です。Credly のデジタルバッジは引き続き表示できます。 これらの認定の有効期限が切れる予定で、有効な状態を維持したい場合は、終了前に必ず試験を再受験してください。 AWS Certified Data Analytics – Specialty (DAS) は 4 月 8 日まで、 AWS Certified Database – Specialty (DBS) と AWS Certified: SAP on AWS – Specialty (PAS) は 4 月 29 日までが期限となります。 期限を過ぎると、これらの試験は提供されなくなるため、再認定を受けることはできません。 また、AWS Skill Builder で提供されているこれら 3 つの AWS 認定に関する試験準備リソースも廃止されます。試験準備リソースには、練習問題、模擬試験、Exam Prep Course が含まれます。これらの試験準備リソースにアクセスできる最終日は、AWS Certified Data Analytics – Specialty (DAS) に関連する試験準備リソースについては 2024 年 4 月 8 日、AWS Certified Database – Specialty (DBS) と AWS Certified: SAP on AWS – Specialty (PAS) に関連する試験準備リソースについては 4 月 29 日です。 AWS でのデータ分析、データベース、SAP の学習リソース AWS Training and Certification では、 AWS Skill Builder で データ分析 や データベース に関するさまざまなデジタルトレーニングリソースを引き続き提供しています。また、最近、 SAP on AWS 向けの新しいデジタルコース を追加しました。今後は、RISE with SAP や SAP Business Technology Platform などのトピックをカバーするコースも追加される予定です。AWS パートナー専用の SAP on AWS に関するその他のトレーニングについては、 AWS パートナーネットワークポータル から AWS パートナートレーニングにアクセスしてください。 この記事の翻訳は Sr. Technical Instructor の生出拓馬が担当しました。

このブログは、 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 ソリューション アーキテクトです。彼は、大手自動車企業の顧客と協力し、彼らの機械学習ワークロードを変革し、クラウドへの移行を支援しています。彼の主な関心事は、ディープラーニングとサーバレス技術です。仕事の外では、家族と過ごすことと、幅広い音楽を探求することを楽しんでいます。 <!-- '"` -->

このブログは、 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 をお届けします。 早いもので１月も残り数日になりましたがいかがお過ごしでしょうか？ 前回もご紹介した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 年分走り切る修行をしていましたが、挫折しています。