TECH PLAY

AWS

AWS の技術ブログ

å…š3297ä»¶

2024 幎 12 月 1 日、テストの合理化ず 生成 AI アプリケヌションの改善に圹立぀ Amazon Bedrock の 2 ぀の新しい評䟡機胜を発衚したした。 Amazon Bedrock ナレッゞベヌスで RAG 評䟡 (プレビュヌ) のサポヌトを開始 – Amazon Bedrock ナレッゞベヌス を䜿甚しお、自動ナレッゞベヌス評䟡を実行しお、 怜玢拡匵生成 (RAG) アプリケヌションを評䟡および最適化できるようになりたした。評䟡プロセスでは、 倧芏暡蚀語モデル (LLM) を䜿甚しお評䟡のメトリクスを蚈算したす。RAG 評䟡では、さたざたな蚭定を比范し、蚭定を調敎しお、ナヌスケヌスに必芁な結果を埗るこずができたす。 Amazon Bedrock Model Evaluation に LLM-as-a-Judge (プレビュヌ) を远加 – 人間による評䟡を行う堎合ず比べお、わずかなコストず時間で、人間䞊みの品質でテストや他のモデルを評䟡できるようになりたした。 これらの新機胜により、AI を掻甚したアプリケヌションの評䟡を迅速か぀自動的に行い、フィヌドバックルヌプを短瞮し、改善をスピヌドアップするこずで、本番環境ぞの移行が容易になりたす。これらの評䟡では、正確性や有甚性、および回答拒吊や有害性などの責任ある AI 基準を含む、品質に関する耇数の偎面を評䟡したす。 簡単か぀盎感的に理解できるように、評䟡結果は各スコアの自然蚀語による説明を出力ずコン゜ヌルに衚瀺し、スコアは解釈しやすいように 0 から 1 に正芏化されおいたす。ルヌブリックはすべおゞャッゞプロンプトずずもに文曞に公開されおいるため、サむ゚ンティストでなくおもスコアの導出方法を理解できたす。 実際にどのように機胜するか芋おみたしょう。 Amazon Bedrock ナレッゞベヌスで RAG 評䟡を䜿甚する Amazon Bedrock コン゜ヌルの [Inference and Assessment] (掚論ず評䟡) セクションで [Evaluations] (評䟡) を遞択したす。そこに、新しい [Knowledge Bases] (ナレッゞベヌス) タブが衚瀺されたす。 [Create] (䜜成) を遞択し、評䟡の名前ず説明を入力しお、メトリクスを蚈算する [Evaluator model] (評䟡者モデル) を遞択したす。今回は、Anthropic の Claude 3.5 Sonnet を䜿いたす。 評䟡するナレッゞベヌスを遞択したす。以前、 AWS Lambda デベロッパヌガむド PDF ファむル のみを含むナレッゞベヌスを䜜成したした。このようにするこずで、評䟡のために AWS Lambda サヌビスに぀いお質問するこずができたす。 怜玢機胜だけを評䟡するこずも、怜玢しお生成するワヌクフロヌ党䜓を評䟡するこずもできたす。この遞択は、次のステップで利甚できるメトリクスに圱響したす。怜玢ず応答生成の䞡方を評䟡するこずにし、䜿甚するモデルを遞択したす。今回は Anthropic の Claude 3 Haiku を䜿いたす。 Amazon Bedrock Guardrails を䜿甚したり、応答生成モデルの埌に [configurations] (蚭定) リンクを遞択しおランタむム掚論蚭定を調敎したりするこずもできたす。 これで、評䟡するメトリクスを遞択できたす。 [Quality] (品質) セクションで [Helpfulness] (有甚性) ず [Correctness] (正確性) を遞択し、 [Responsible AI metrics] (責任ある AI メトリクス) セクションで [Harmfulness] (有害性) を遞択したす。 次に、評䟡に䜿甚するデヌタセットを遞択したす。これは、この評䟡甚に準備しお Amazon Simple Storage Service (Amazon S3) にアップロヌドした JSONL ファむルです。各行には䌚話が含たれ、その䞭のメッセヌゞごずに参照応答がありたす。 {"conversationTurns":[{"referenceResponses":[{"content":[{"text":"A trigger is a resource or configuration that invokes a Lambda function such as an AWS service."}]}],"prompt":{"content":[{"text":"What is an AWS Lambda trigger?"}]}}]} {"conversationTurns":[{"referenceResponses":[{"content":[{"text":"An event is a JSON document defined by the AWS service or the application invoking a Lambda function that is provided in input to the Lambda function."}]}],"prompt":{"content":[{"text":"What is an AWS Lambda event?"}]}}]} 評䟡の結果を保存する S3 の堎所を指定したす。評䟡ゞョブでは、S3 バケットが Amazon Bedrock ナヌザヌガむドに蚘茉されおいるクロスオリゞンリ゜ヌス共有 (CORS) 蚱可で蚭定 されおいる必芁がありたす。 サヌビスにアクセスするには、Amazon Bedrock が匕き受けるこずができる AWS Identity and Access Management (IAM) サヌビスロヌルを䜜成たたは提䟛する必芁がありたす。これにより、評䟡で䜿甚される Amazon Bedrock および Amazon S3 リ゜ヌスぞのアクセスが可胜になりたす。 数分埌に評䟡が完了したので、結果を閲芧したす。評䟡の実際の所芁時間は、プロンプトデヌタセットのサむズ、䜿甚したゞェネレヌタおよび評䟡者モデルによっお異なりたす。 䞀番䞊の メトリクスサマリヌ では、すべおの䌚話の平均スコアを䜿甚しお党䜓的なパフォヌマンスを評䟡したす。 その埌、 生成メトリクスの内蚳 に、遞択した各評䟡メトリクスの詳现が衚瀺されたす。私の評䟡デヌタセットは小さかった (2 行) ので、倧きな分垃を芋る必芁はありたせん。 ここから、䌚話䟋ずその評䟡も確認できたす。すべおの䌚話を芋るには、S3 バケットの党出力を確認するこずができたす。 なぜ 有甚性 が 1 を少し䞋回っおいるのかに興味がありたす。 有甚性 が芋れるように、 䌚話䟋 の拡倧ずズヌムを行いたす。そこには、生成された出力、評䟡デヌタセットず共に提䟛したグラりンドトゥルヌス、およびスコアが衚瀺されたす。モデルの掚論を芋るためにスコアを遞びたす。モデルによるず、より詳现な情報があれば圹立ったようです。モデルは本圓に厳しい審査員です。 RAG 評䟡の比范 ナレッゞベヌスの評䟡の結果は、それ自䜓では解釈が難しい堎合がありたす。このため、コン゜ヌルでは耇数の評䟡の結果を比范しお違いを理解できたす。これにより、関心のあるメトリクスが改善されおいるかどうかがわかりたす。 䟋えば、以前、他に 2 ぀のナレッゞベヌスの評䟡を実行したした。これらは、同じデヌタ゜ヌスを持぀ナレッゞベヌスに関連しおいたすが、チャンクず解析の蚭定が異なり、埋め蟌みモデルも異なりたす。 2 ぀の評䟡を遞択し、 [Compare] (比范) を遞択したす。コン゜ヌルで比范できるようにするには、評䟡が同じメトリクスを察象ずする必芁がありたす。 [At a Glance] (抂芁) タブでは、スパむダヌチャヌトを䜿甚しおメトリクスを芖芚的に比范しおいたす。この堎合、結果はそれほど倉わりたせん。䞻な違いがあるのは 忠実床 スコアです。 [Evaluation details] (評䟡の詳现) タブには、スコアの違いなど、各メトリクスの結果の詳现な比范が衚瀺されたす。 Amazon Bedrock Model Evaluation で LLM-as-a-judge (プレビュヌ) を䜿甚する Amazon Bedrock コン゜ヌルでは、ナビゲヌションペむンの [Inference and Assessment] (掚論ず評䟡) セクションで [Evaluations] (評䟡) を遞択したす。 [Create] (䜜成) を遞択した埌、 Automatic: Model as a judge (自動: Model as a judge) オプションを遞択したす。 評䟡の名前ず説明を入力し、評䟡メトリクスの生成に䜿甚される 評䟡モデル を遞択したす。ここでは Anthropic の Claude 3.5 Sonnet を䜿いたす。 次に、評䟡したいモデルである [Generator model] (ゞェネレヌタモデル) を遞択したす。モデル評䟡は、より小さく、より費甚察効果の高いモデルがこのナヌスケヌスのニヌズを満たしおいるかどうかを把握するのに圹立ちたす。ここでは Anthropic の Claude 3 Haiku を䜿いたす。 次のセクションでは、評䟡する メトリクス を遞択したす。 [Quality] (品質) セクションで [Helpfulness] (有甚性) ず [Correctness] (正確性) を遞択し、 [Responsible AI metrics] (責任ある AI メトリクス) セクションで [Harmfulness] (有害性) を遞択したす。 [Datasets] (デヌタセット) セクションでは、評䟡デヌタセットが保存される Amazon S3 の堎所ず、モデル評䟡ゞョブの結果が保存される S3 バケット内のフォルダを指定したす。 評䟡デヌタセット甚に、別の JSONL ファむルを甚意したした。各行には、プロンプトず参考甚の回答が蚘茉されおいたす。圢匏はナレッゞベヌスの評䟡ずは異なるこずに泚意しおください。 {"prompt":"Write a 15 words summary of this text:\n\nAWS Fargate is a technology that you can use to run containers without having to manage servers or clusters.With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers.This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.","referenceResponse":"AWS Fargate allows running containers without managing servers or clusters, simplifying container deployment and scaling."} {"prompt":"Give me a list of the top 3 benefits from this text:\n\nAWS Fargate is a technology that you can use to run containers without having to manage servers or clusters.With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers.This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.","referenceResponse":"- No need to manage servers or clusters.\n- Simplified infrastructure management.\n- Improved focus on application development."} 最埌に、Amazon Bedrock にこの評䟡ゞョブで䜿甚されるリ゜ヌスぞのアクセスを蚱可する IAM サヌビスロヌルを遞択できたす。 評䟡の䜜成が完了したした。数分埌、評䟡が完了したす。ナレッゞベヌスの評䟡ず同様に、結果は メトリクスの抂芁 から始たりたす。 生成メトリクスの内蚳 には各メトリクスの詳现が蚘茉されおいたす。いく぀かのサンプルプロンプトの詳现も芋るこずができたす。評䟡スコアをよりよく理解するために、 有甚性 を確認したす。 評䟡のプロンプトはモデルによっお正しく凊理されおおり、その結果を自分のナヌスケヌスに適甚できたす。この評䟡で䜿甚したものず同様のプロンプトをアプリケヌションで管理する必芁がある堎合は、評䟡モデルが良い遞択肢です。 知っおおくべきこず これらの新しい評䟡機胜は、次の AWS リヌゞョン でプレビュヌ版ずしお利甚できたす。 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ、シドニヌ、東京)、カナダ (䞭郚)、欧州 (フランクフルト、アむルランド、ロンドン、パリ)、南米 (サンパりロ) での RAG 評䟡 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ、゜りル、シドニヌ、東京)、カナダ (䞭郚)、欧州 (フランクフルト、アむルランド、ロンドン、パリ、チュヌリッヒ)、南米 (サンパりロ) での LLM-as-a-Judge 利甚可胜な評䟡者モデルはリヌゞョンによっお異なるこずに泚意しおください。 料金は、モデル掚論甚の暙準的な Amazon Bedrock の料金 に基づいおいたす。評䟡ゞョブ自䜓に远加料金はかかりたせん。評䟡者モデルず評䟡察象モデルの請求は、通垞のオンデマンド料金たたはプロビゞョニング料金に埓っお行われたす。ゞャッゞプロンプトテンプレヌトは入力トヌクンの䞀郚であり、透明性を高めるため、このようなゞャッゞプロンプトは AWS のドキュメントに蚘茉されおいたす。 評䟡サヌビスはリリヌス時点では英語コンテンツ向けに最適化されおいたすが、基盀ずなるモデルではサポヌト察象の他の蚀語のコンテンツも凊理できたす。 䜿甚を開始するには、 Amazon Bedrock コン゜ヌル にアクセスしおください。詳现に぀いおは、 Amazon Bedrock のドキュメント をご芧になり、 AWS re:Post for Amazon Bedrock にフィヌドバックを送信しおください。 community.aws では、詳しい技術コンテンツを怜玢し、ビルダヌコミュニティが Amazon Bedrock を䜿甚する方法を芋出すこずができたす。これらの新機胜で䜕を構築するのか教えおくださいね! – Danilo 原文は こちら です。
本蚘事は 2024幎11月27日に公開された ” Export AWS Migration Hub data for Import into AWS Application Migration Service ” を翻蚳したものです。 AWS Application Discovery Service (ADS) は、AWS ぞの移行準備ずしおサヌバヌを怜出したす。ADS は、 既存の゜ヌス からデヌタをむンポヌトするか、サヌバヌのパフォヌマンスずネットワヌク通信デヌタを収集する 怜出゚ヌゞェント 、たたは、 ゚ヌゞェントレスコレクタヌ を展開するこずで、怜出を実行したす。収集されたデヌタは、 AWS Migration Hub に送られ、そこでサヌバヌをアプリケヌショングルヌプに分類するこずが可胜です。移行の 準備フェヌズ の重芁な郚分は、サヌバヌを 移行りェヌブ に分けるこず、および ADS によっお芳枬されたパフォヌマンスメトリクスに基づいお Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスのレコメンデヌションを取埗するこずです。移行りェヌブは Migration Hub 内で構成可胜です。 この投皿では、移行りェヌブを含む移行蚈画の構築方法、EC2 むンスタンスのレコメンデヌション取埗、および Migration Hub からのデヌタの゚クスポヌト方法を説明したす。その埌、 AWS Application Migration Service (AWS MGN) にデヌタをむンポヌトする方法を玹介したす。 ADS で収集されたデヌタは Migration Hub 内で敎理され、AWS MGN で䜿甚できるよう゚クスポヌトできたす。AWS MGN は、AWS に移行するためのサヌビスです。移行元サヌバヌのデヌタを AWS にレプリケヌトし、移行元サヌバヌを Amazon EC2 むンスタンスず Amazon Elastic Block Store ボリュヌムで AWS ネむティブに実行するように自動的に倉換したす。Migration Hub のデヌタを AWS MGN にむンポヌトするず、指定されたアプリケヌションずりェヌブに埓っお移行を実行できたす。AWS MGN が起動する Amazon EC2 むンスタンスは、ADS のパフォヌマンスメトリクスの情報を元に生成された Amazon EC2 むンスタンスのレコメンデヌションず䞀臎したす。 この投皿では、Migration Hub に収集されたデヌタがすでに存圚するこずを前提ずしおいたす。 サヌバヌを移行りェヌブごずにグルヌプ化 移行りェヌブは、技術的および非技術的な䟝存関係を持぀アプリケヌションずむンフラストラクチャの集たりで、同時にグルヌプずしお移行する必芁がありたす。Migration Hub を䜿甚するず、サヌバヌをアプリケヌションにグルヌプ化し、アプリケヌションの集合䜓である移行りェヌブを定矩できたす。 以䞋の手順に埓っお移行りェヌブを䜜成しおください。 Migration Hub 内の アプリケヌション メニュヌから、りェヌブに割り圓おたいアプリケヌションを遞択したす 図 1 – Migration Hub のアプリケヌションメニュヌのスクリヌンショット、アプリケヌションの遞択を衚瀺 遞択したアプリケヌションの鉛筆アむコンをクリックするず、Wave ID を入力できたす。同じ Wave ID のすべおのアプリケヌションは、AWS MGN 内の りェヌブ にたずめられたす 図2 – Wave ID の線集画面のスクリヌンショット Migration Hub からデヌタを゚クスポヌトし、EC2 むンスタンスのレコメンデヌションを取埗する Amazon EC2 むンスタンスのレコメンデヌション は、既存のパフォヌマンス芁件を凊理できる最も安䟡な Amazon EC2 むンスタンスタむプを遞択するために䜿甚されたす。これらの掚奚事項を生成するために䜿甚されるデヌタは、ADS によっお収集された実際の䜿甚率メトリックス、たたは Migration Hub に手動でむンポヌトされた詳现なパフォヌマンス情報です。 以䞋の手順に埓っお Amazon EC2 むンスタンスの掚奚事項を゚クスポヌトしおください。 Migration Hub 内の アプリケヌション メニュヌから、EC2 むンスタンスのレコメンデヌションを生成したいアプリケヌションを遞択しおください 図3 – Amazon EC2 むンスタンスのレコメンデヌションでアプリケヌションを遞択するスクリヌンショット アクション メニュヌから「 EC2のレコメンデヌションを取埗 」を遞択しおください サむゞングの蚭定 を遞択しおください。Discovery ゚ヌゞェント、たたぱヌゞェントレス コネクタを䜿甚した堎合は、時系列の利甚率デヌタに基づく 利甚率のパヌセンタむル を䜿甚できたす。 リヌゞョン 、 テナンシヌ 、 料金モデル を遞択しおください 図4 – むンスタンスのレコメンデヌションの蚭定を遞択するスクリヌンショット ゚クスポヌトに含たれるサヌバヌやアプリケヌションを远加したり削陀したりするこずができたす ゚クスポヌトのレコメンデヌション を遞択しお、゚クスポヌトしたす zipファむルをダりンロヌドしたす。zipファむル内には2぀のCSVファむルが含たれおいたす。 EC2InstanceRecommendations-#### – EC2むンスタンスのレコメンデヌションが含たれおいたす MgnInventory-#### – AWS MGN にむンポヌトできるデヌタが含たれおいたす AWS MGN にサヌバヌ情報をむンポヌト MgnInventory-#### CSVファむルは、AWS MGN にむンポヌトできたす。 アプリケヌションの情報は AWS MGN 䞊のアプリケヌションリ゜ヌスに倉換され、そのアプリケヌションに属するすべおのサヌバヌがグルヌプ化されたす。りェヌブの情報は AWS MGN 䞊のりェヌブリ゜ヌスに倉換され、そのりェヌブに属するすべおのアプリケヌションがグルヌプ化されたす。りェヌブずアプリケヌションの䞡方で、AWS MGN を䜿うナヌザヌは耇数のサヌバヌに察する䞀括操䜜を実行したり、移行の状況を集玄しお監芖するこずができたす。 残りの情報は EC2 起動テンプレヌトを蚭定するために䜿甚され、テストずカットオヌバヌの目的で起動される Amazon EC2 むンスタンスに適甚されたす。これにはむンスタンスタむプずサブネットが含たれたす。 VMware 固有の属性 ( vmname や vmmoref など) を移行した Amazon EC2 むンスタンスにタグずしお远加できるよう、「 サヌバヌタグを転送 」を有効にするこずができたす。 次の CSV 内のフィヌルドに泚意しおください。 mgn:server:user-provided-id – 重耇を避けるため、このフィヌルドの初期倀は、Migration Hub 内の ホスト名 ず サヌバヌID の連結になっおいたす。この倀は任意の倀に倉曎できたす。この ID は、AWS Replication Agent をむンストヌルする際に䜿甚する user-provided-id ず 䞀臎する必芁 がありたす。 ゚ヌゞェントのむンストヌル䞭、デフォルトの ID は゜ヌスサヌバヌのホスト名になりたす。むンストヌルパラメヌタヌ –user-provided-id を䜿甚するず、デフォルトの ID を䞊曞きできたす。むンストヌルパラメヌタヌの䜿甚方法に぀いおは、 Linux および Windows のむンストヌル手順をご芧ください。 mgn:wave:name – このフィヌルドの倀には、Migration Hub で構成したりェヌブが含たれおいたす。 mgn:launch:instance-type – このフィヌルドの倀には、レコメンデヌションされたむンスタンスタむプが含たれおいたす。 mgn:launch:nic:0:private-ip:0 – このフィヌルドの倀は、移行されるサヌバヌの IP アドレスを蚭定するために䜿甚されたす。Migration Hub からの゚クスポヌトでは、この倀が AWS で同じ IP アドレスを䜿甚するように移行元゜ヌスサヌバヌの珟圚の IP アドレスに蚭定されたす。移行されるサヌバヌが異なる IP 範囲の Amazon Virtual Private Cloud (Amazon VPC) に入る堎合は、このフィヌルドを空癜にする必芁がありたす。 AWS MGN にデヌタをむンポヌトするには、次の手順に埓っおください。 AWS MGN の むンポヌト メニュヌから ファむルを遞択 をクリックし、Migration Hub からダりンロヌドした CSV ファむルをむンポヌトしたす 図5 – AWS MGN のむンポヌトメニュヌでファむルを遞択するスクリヌンショット Migration Hub からダりンロヌドした CSVファむルを遞択したす むンポヌト を遞択したす むンポヌト履歎 を䜿甚しお、むンポヌト操䜜の状況を远跡できたす Migration Hub のサヌバヌず りェヌブ構成、Amazon EC2 むンスタンスタむプのレコメンデヌションが AWS MGN に远加されたした。 図6 – AWS MGN 内の Migration Hub からむンポヌトされた「りェヌブ」のスクリヌンショット たずめ AWS Migration Hub ず AWS Application Discovery Service (ADS) は、AWS ぞの移行の調査、蚈画、実行に利甚できたす。ADS は、Amazon EC2 むンスタンスタむプのレコメンデヌションに重芁なパフォヌマンスメトリクスを収集するために䜿甚できたす。Migration Hub は、サヌバヌをアプリケヌションずりェヌブにグルヌプ化するこずができ、䞀緒に移行する必芁があるアプリケヌションを定矩したす。調査・蚈画時に収集したデヌタに基づいお生成された Amazon EC2 むンスタンスのレコメンデヌションを゚クスポヌトするこずで、移行の実行フェヌズに反映させるこずができたす。゚クスポヌトされたデヌタは、移行サヌビスの AWS Application Migration Service (AWS MGN) に盎接むンポヌトできる圢匏になっおいたす。AWS MGN は、Migration Hub からの゚クスポヌトに埓っお、アプリケヌション、移行りェヌブ、むンスタンスタむプの蚭定を行いたす。 Migration Hub ず AWS Application Migration Service の機胜に぀いおさらに詳しく知りたい方は、ぜひ公匏ドキュメントを確認しおみおください。 著者に぀いお Peter Giuliano Peter Giuliano は、AWSのシニア・マむグレヌション・゜リュヌション・アヌキテクトで、オンプレミスおよびクラりドむンフラストラクチャで20幎以䞊の経隓を持っおいたす。AWSでは、お客様がクラりドぞの倧芏暡な移行を蚈画し実行するのを支揎し、お客様の経隓ず教蚓が共有されるよう努めおいたす。仕事以倖では、ランニングが趣味で、新しい堎所を旅行するのが奜きです。 この蚘事の翻蚳は゜リュヌションアヌキテクトの須山健吟が担圓したした。原文は こちら です。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 あけたしおおめでずうございたす。本幎も週刊生成 AI with AWS ず、週刊 AWS をよろしくお願いいたしたす。 1 月に入り AWS 公匏りェブマガゞン、builders.flash の蚘事が公開されおいたすので生成 AI に関係するものをピックアップしおみたす。粟床評䟡・信頌性・セキュリティ・高床な RAG 構築などの実甚的なテクニックが蚘茉されおいたすので興味に合わせおご芧ください。 Amazon Bedrockを甚いた掲瀺板投皿監芖システムの実珟~株匏䌚瀟ゲヌム゚むトによる生成AI実装解説 (株匏䌚瀟ゲヌム゚むト様) AI技術で高校生の未来を支揎する『AI-m゚むム』~面接緎習の革新 (株匏䌚瀟マむナビ様) 生成AIセキュリティの歩き方 Amazon Bedrock Knowledge Basesでもサポヌト開始(preview)した噂のGraphRAGずは䞀䜓なんなのか?! それでは、1 月 6 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: 䞉協立山株匏䌚瀟様、生成 AI アシスタントをか月でリリヌスし議事録䜜成時間を 75% 削枛 䞉協立山株匏䌚瀟様 は、生成 AI 掻甚による生産性向䞊を目的ずした瀟内向けサヌビス 「AI ふたば」を展開しおいたした。プログラミングなどの䞀郚の業務で掻甚されおいた䞀方で、業務での掻甚シヌンが䞍明確であるこずや、RAG が導入されおいないこずなどの理由から、䌚瀟党䜓での掻甚が進たないずいう課題を抱えおいたした。そこで、䞊蚘の課題解決に向けお Generative AI Use cases JP (以䞋、GenU) の導入を怜蚎したした。GenU をカスタマむズし、業務での掻甚シヌンに即した 50 パタヌンほどのプロンプトテンプレヌトを導入したこずで瀟内の利甚者が 1.5  2 倍皋床拡倧したそうです。さらに圓初から芁望の倚かった議事録䜜成機胜をリリヌスしたこずで、幎間で 1 侇 5000 時間の業務時間削枛効果が芋蟌たれおいたす。 ブログ蚘事「Amazon Nova のご玹介: フロンティアむンテリゞェンスず業界をリヌドする料金パフォヌマンス」を公開 昚幎の 12 月 3 日に、 Amazon Bedrock で利甚可胜な基盀モデル (FM) である Amazon Nova を発衚したした。Amazon Nova は最先端のむンテリゞェンスず業界トップクラスの䟡栌パフォヌマンスを実珟したす。この蚘事では、Amazon Nova のそれぞれのモデルの特城・プロンプト䟋・呌び出し方䟋を玹介しおいたす。 サヌビスアップデヌト Amazon Q Developer が Amazon SageMaker Code Editor IDE で利甚可胜に Amazon SageMaker Studio をご利甚のお客様は、Code EditorVisual Studio CodeIDE 内で Amazon Q Developer による生成AI アシスタンスを利甚できるようになりたした。Q Developer を䜿甚するこずで、トラブルシュヌティングに関するガむダンスを埗たり、コヌド生成を行ったりするこずが可胜になり、機械孊習開発プロセスの効率化が期埅できたす。この機胜は、SageMaker Studio が利甚可胜なすべおの AWS リヌゞョンでご利甚いただけたす。 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は生成 AI ず毎日戯れおおり、特にコヌド生成ず LLM ゚ヌゞェントに泚目しおいたす。奜きなうどんは’かけ’です。
本ブログは 2025 幎 1 月 8 日に公開された「 New AWS Skill Builder course available: Securing Generative AI on AWS 」を翻蚳したものずなりたす。 Amazon Web ServicesAWS 䞊での生成 AI ワヌクロヌドをセキュアにするためにお客様をサポヌトする、新しい AWS Skill Builder コヌス「 Securing Generative AI on AWS 」の提䟛開始をお知らせしたす。 この包括的なコヌスは、セキュリティの専門家、アヌキテクト、人工知胜および機械孊習AI/ML゚ンゞニアが AWS クラりド䞊の生成 AI アプリケヌションおよびモデルのセキュリティのベストプラクティスを理解し、実装するための助けずなるを目的ずしおいたす。 AWS Skill Builder は、AWS のお客様およびパヌトナヌがデゞタルトレヌニング、セルフペヌスラボ、その他のコヌスタむプを通じおクラりドスキルを構築するための孊習センタヌです。AWS Skill Builder には、お客様が AWS セキュリティの抂念を理解し、実践的な経隓を埗るための様々な AWS セキュリティコンテンツがありたす。 コヌスのハむラむトは以䞋の通りです蚳者泚コンテンツは英語ずなりたす。 生成 AI セキュリティスコヌプマトリックスの玹介 – この革新的なフレヌムワヌクを䜿甚しお、異なる AI 実装を分類し、保護する方法を孊びたす。 䞻芁な AI セキュリティフレヌムワヌクのカバレッゞ – OWASP Top 10 for Large Language Models (LLMs) ず MITRE ATLAS フレヌムワヌクに぀いおの掞察を埗たす。 実践的なセキュリティ戊略 – 様々な AI のスコヌプにおけるガバナンス、法埋、リスク、コントロヌル、レゞリ゚ンスの分野にわたる包括的なセキュリティを実装するスキルを開発したす。 実䞖界での応甚 – コンシュヌマアプリケヌション、゚ンタヌプラむズ゜リュヌション、事前孊習枈みのモデル、ファむンチュヌニングされたモデル、自身で孊習したモデルをカバヌするケヌススタディにセキュリティのコンセプトを適甚したす。 コヌスを受講するには 無料の AWS Skill Builder アカりントにサむンアップしたす。 コヌスカタログで「Securing Generative AI on AWS」を怜玢したす。 コヌスに登録しお孊習を始めたしょう 補足情報 生成 AI セキュリティに関するさらなる情報に぀いおは、以䞋のブログシリヌズをご確認いただくこずをお勧めしたす。 生成 AI をセキュアにする: 生成 AI セキュリティスコヌピングマトリックスの玹介日本語 生成 AI をセキュアにする: 関連するセキュリティコントロヌルの適甚日本語 生成 AI をセキュアにする: デヌタ、コンプラむアンス、プラむバシヌに関する考慮点日本語 私たちは皆さたのフィヌドバックや貢献を倧切にしおいたす。コヌスを完了した埌にご意芋や掞察があれば、コヌスのフィヌドバックから、たたは AWS サポヌト にお問い合わせください。 Anna McAbee Anna は、AWS で金融サヌビス、生成AI、むンシデント察応にフォヌカスしたセキュリティスペシャリスト゜リュヌションアヌキテクトです。仕事以倖では、テむラヌ・スりィフトを楜しみ、フロリダ・ゲむタヌズ・フットボヌルチヌムを応揎し、NFL を芳戊し、䞖界䞭を旅するこずを楜しんでいたす。 Pablo Roesch Pablo は、AWS のテクニカルシニアプロダクトマネヌゞャヌで、セキュリティおよびクラりド運甚トレヌニングポヌトフォリオを管理しおいたす。圌は生成 AI を掻甚しおコヌス開発ず垂堎投入戊略を革新し、技術的専門知識ずむノベヌティブなアプロヌチを組み合わせおいたす。Pablo は、パッケヌゞ化された仮想マシンアプリケヌションずの倖郚通信US 11,7973,26 B2の特蚱を保有しおおり、クラりドおよび仮想化技術における圌の専門知識を反映しおいたす。 Meg Peddada Meg は 10 幎以䞊の経隓を持぀シニアセキュリティ゜リュヌションアヌキテクトで、セキュリティ、リスク、コンプラむアンスを専門ずしおいたす。圌女の専門知識はガバナンス、セキュリティ自動化、脅嚁管理、アヌキテクチャに及びたす。䜙暇には、バレヌボヌル、アヌトずクラフト、新しいブランチ䜓隓を芋぀けるこずを楜しんでいたす。 翻蚳はプロフェッショナルサヌビス本郚の藀浊 雄倧が担圓したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの戞塚です。今週も 週刊AWS をお届けしたす。 私は幎初に趣味のパデルの倧䌚に出お、リフレッシュしおきたした。みなさんはどんな幎末幎始を過ごされたしたか 今幎も新たな機胜が远加されおいっおたすね。それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎1月6日週の䞻芁なアップデヌト 1/7(火) Amazon DynamoDB now supports configurable point-in-time-recovery periods Amazon DynamoDB では、ポむントむンタむムリカバリ (PITR) の期間を蚭定できるようになりたした。PITR を䜿甚したデヌタリカバリの期間をテヌブル単䜍で 135 日の範囲で指定できたす。PITR は、DynamoDB のデヌタを偶発的な曞き蟌みや削陀から保護し、リカバリ期間内の任意の秒数たでデヌタをリストアするこずができたす。 これにより、バックアップのリカバリ期間を蚭定するこずで、デヌタリカバリ期間を短瞮する必芁があるコンプラむアンスや芏制芁件を満たすこずができたす。 Announcing 20 additional AWS Systems Manager Automation runbook recommendations in AWS Chatbot AWS は、AWS Chatbot のむベント通知のコンテキストアクションボタンずしお、AWS Systems Manager Automation で20 個の掚奚ランブックの䞀般提䟛を発衚したした。 このリリヌスにより、お客様は Microsoft Teams や Slack チャネルから AWS Systems Manager オヌトメヌションを実行し、AWS Security Hub や Amazon ECS 関連のむベントに察凊できるようになりたす。詳现は、AWS Chatbot の ドキュメント たたは AWS Chatbot の補品ペヌゞ を参照しおください。 1/8(æ°Ž) Amazon Q Developer is now available in Amazon SageMaker Code Editor IDE Amazon SageMaker は、SageMaker Studio コヌド゚ディタにおける Amazon Q Developer の䞀般提䟛を発衚したした。 SageMaker Studio の顧客は、コヌド゚ディタヌ (Visual Studio Code – オヌプン゜ヌス) IDE 内で、Q Developer によるゞェネレヌティブ AI アシスタンスを利甚できるようになりたした。 Q Developer を䜿甚するこずで、デヌタサむ゚ンティストず ML ゚ンゞニアは、SageMaker の機胜、コヌド生成、トラブルシュヌティングに関する専門家のガむダンスにアクセスできたす。 これにより、退屈なオンラむン怜玢やドキュメントレビュヌの必芁性がなくなり、差別化されたビゞネス䟡倀を提䟛する時間を確保できるため、生産性が向䞊したす。 Amazon Connect Contact Lens now provides free trials for conversational analytics and performance evaluations Amazon Connect Contact Lens は、䌚話分析ずパフォヌマンス評䟡を初めお利甚するナヌザヌ向けに無料トラむアルを提䟛するようになりたした。 音声甚䌚話アナリティクスを初めおご利甚になるお客様には、最初の 2 ヶ月間、月間 10 䞇分の音声通話を無料でお詊しいただけたす。 さらに、初めお Contact Lens のパフォヌマンス評䟡を䜿甚する顧客には、最初のパフォヌマンス評䟡を提出した日から 30 日間の無料トラむアルが提䟛されたす。 1/9(朚) AWS Compute Optimizer now expands idle and rightsizing recommendations for Amazon EC2 Auto Scaling groups AWS Compute Optimizer は、スケヌリングポリシヌず耇数のむンスタンスタむプを持぀Amazon EC2 Auto Scaling グルヌプに、アむドル状態ず適切なサむズ調敎の掚奚事項を远加したした。 新しい掚奚事項により、スケヌリングポリシヌや耇数のむンスタンスタむプを䜿甚しおいる Auto Scaling グルヌプのコストずパフォヌマンスを最適化するためのアクションを、専門的な知識や゚ンゞニアリングリ゜ヌスを必芁ずせずに実行できるようになりたす。 1/10(金) AWS CodeBuild now supports batch builds with reserved capacity and Lambda compute AWS CodeBuild は、バッチビルド機胜を拡匵し、リザヌブドキャパシティフリヌトおよび Lambda コンピュヌティングのサポヌトを远加したした。この機胜拡匵により、ビルドバッチに察しおオンデマンドむンスタンス、リザヌブドキャパシティフリヌト、Lambda コンピュヌティングリ゜ヌスを組み合わせお遞択できるようになりたす。バッチビルドでは、1 ぀のプロゞェクト内で耇数のビルドを同時に実行し、それらを調敎するこずが可胜です。この機胜は、マルチプラットフォヌムプロゞェクトや盞互䟝存するビルドプロセスを持぀開発者に特に有甚です。ビルドシヌケンスは、ビルドリスト、ビルドマトリックス、たたは䟝存関係グラフを䜿甚しお定矩できたす。CodeBuild はこれらのビルドのオヌケストレヌションを管理し、開発ず統合プロセス党䜓を効率化したす。 Amazon Connect Contact Lens launches agent performance evaluations for email contacts Amazon Connect Contact Lens は、メヌルコンタクトに察する゚ヌゞェントのパフォヌマンス評䟡機胜をリリヌスしたした。この新機胜により、マネヌゞャヌは Amazon Connect 内でメヌルを含むすべおのコンタクトチャネル音声、チャット、メヌル、タスクにおける゚ヌゞェントのパフォヌマンスを、䜿いやすい単䞀のりェブむンタヌフェヌスで評䟡できるようになりたした。たた、゚ヌゞェントグルヌプ党䜓のパフォヌマンスを時系列で集玄した掞察も埗られたす。 むンフル゚ンザも流行っおいるので、みなさんも䜓調には気を぀けおください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 戞塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界党般のお客様をご支揎しおいる゜リュヌション アヌキテクトで、AI/ML、IoT を埗意ずしおいたす。最近では AWS を掻甚したサステナビリティに぀いおお客様に蚎求するこずが倚いです。 趣味は、パデルずいうスペむン発祥のスポヌツで、䌑日は仲間ずよく倧䌚に出おいたす。
本ブログは 2024 幎 12 月 17 日に公開された「 How DeNA Co., Ltd. accelerated anonymized data quality tests up to 100 times faster using Amazon Redshift Serverless and dbt 」を翻蚳したものです。 本ブログは 株匏䌚瀟ディヌ・゚ヌ・゚ヌ以䞋 DeNA  ず Amazon Web Services Japan が共同で執筆したした。 DeNA は「䞀人ひずりに想像を超える Delight を」ずいうミッションのもず、ゲヌム、ラむブコミュニティ、ヘルスケア・メディカル、スポヌツ・スマヌトシティ、モビリティなど倚岐にわたる事業を展開しおいたす。䞭でもヘルスケア・メディカル事業では、機密性の高いデヌタを扱っおおり、同瀟のデヌタポリシヌに準拠するためにデヌタ凊理に関しお以䞋の芁件を蚭定しおいたす デヌタポリシヌに準拠したデヌタ凊理 – 必芁に応じお機密性の高いデヌタをマスキングや削陀を行い、匿名化デヌタに倉換したす。加えお区分倀に無効な倀が含たれないようにするなど、的確䞔぀損倱なくデヌタの凊理を行いたす。 デヌタポリシヌに準拠した匿名化デヌタの品質テスト – 加工埌のデヌタ品質問題を迅速に特定し察凊するため、デヌタ品質テストを実斜しお高品質なデヌタを垞に維持したす。 本ブログでは、DeNA が Amazon Redshift Serverless ず dbt ( dbt Core ) を組み合わせお、匿名化デヌタの品質テストを高速化した事䟋をご玹介したす。なお、本取り組みに぀いおは DeNA Engineer Blog にも蚘茉がありたす。そちらも䜵せお参考いただけるず幞いです。 解決したい課題 デヌタ品質テストは、毎月 10 TB のデヌタに察しお 1,300 件のテストを実斜する必芁がありたす。今たでデヌタ品質テストは AWS 䞊の Amazon Elastic Compute Cloud (Amazon EC2) で Python で実装されたバッチゞョブを実行しお行っおきたした。しかし、事業ずデヌタ量の拡倧に䌎い、以䞋の課題に盎面したした。 パフォヌマンス – ゚ンゞニアがビッグデヌタ凊理を想定しおバッチを蚭蚈しおいなかったため、デヌタ品質テストの完了に数日から数週間を芁しおいたした。 コスト – 特に倧芏暡なデヌタセットに察しお、バッチの蚭蚈によりコストが増加したした。実装䞊、デヌタをメモリにロヌドしお凊理する必芁があり、倧芏暡なテヌブルのデヌタを扱う際には、メモリ容量が倧きな EC2 むンスタンスを利甚する必芁がありたした。 保守性 – バッチの実装が゚ンゞニアごずに倧きく異なり、保守に必芁な知識が属人化しおいたため、保守のコストが増倧しおいたした。 Redshift Serverless ず dbt ぞの移行 これらの課題を解決するため、DeNA は以䞋の理由から Redshift Serverless ず dbt (オヌプン゜ヌスのデヌタ倉換ツヌル) を採甚したした。䞻な理由は以䞋の通りです  Redshift Serverless によりスケヌラブルでコスト効率の高い凊理が可胜  dbt により利甚技術を暙準化しお運甚がしやすいデヌタ品質テストの実装が可胜 この決定は様々な゜リュヌションを比范怜蚎した結果なされたした。圓初 DeNA は既存の Python バッチゞョブを䞊列化するこずを怜蚎したした。しかし、珟時点で保守負荷が高く改修が難しい Python バッチに手を入れるのは工数が倚くかかり、たた属人化による高い保守負荷を解決するこずには぀ながらないため、採甚を芋送りたした。代わりに、ヘルスケア・メディカル事業で利甚しおいる dbt を採甚し、倧芏暡な分散凊理が可胜な AWS のサヌビスず組み合わせお利甚するこずを決定したした。dbt は SQL 䞭心のテンプレヌト゚ンゞンで、反埩的で拡匵可胜なデヌタ倉換を SQL ず Python で蚘述するこずができたす。dbt には data tests ずいう、SQL を利甚しおデヌタモデルやテヌブルが期埅されるルヌルや条件に埓っおいるかを怜蚌するテスト機胜があり、デヌタの敎合性や制玄違反を怜出しおデヌタ品質を高めるこずができたす。この機胜を利甚するこずで、事業における利甚技術を統䞀化するこずができ、運甚性や汎甚性の高い SQL を利甚しおデヌタ品質テストを実装するこずができたす。たた dbt を倧芏暡分散凊理が埗意なマネヌゞドサヌビスに接続するこずで、コスト効率を向䞊させながら凊理を高速化できるず考えたした。 AWS は dbt を接続しおデヌタを凊理できるサヌビスずしお、 Amazon Redshift や  AWS Glue などを提䟛しおいたす。今回 DeNA は Redshift Serverless を採甚したした。䞻な採甚理由は、サヌバヌレスによる䜎い運甚負荷ず高いコストパフォヌマンスに加え、デヌタりェアハりスサヌビス特有の構造化されたデヌタぞの優れた凊理パフォヌマンスです。 ゜リュヌションの抂芁 DeNA は以䞋のアヌキテクチャを蚭蚈したした。コスト効率や運甚性の芳点で、すべおのコンポヌネントをサヌバヌレスで構築したした。 蚭蚈のポむント デヌタ品質テストの察象ずなるデヌタは Amazon Simple Storage Service (Amazon S3) に配眮されるため、配眮をトリガヌに Amazon EventBridge 経由で AWS Step Functions の ステヌトマシン (ワヌクフロヌ) を起動したした。1皮のデヌタで耇数のファむルが提䟛されるため、すべおのファむルの配眮が完了したこずを確認できるように、提䟛元のシステムから完了を瀺すファむルを Amazon S3 に配眮するようにしたした。 dbt は AWS のサヌバヌレスコンテナサヌビスである AWS Fargate を利甚しお Amazon Elastic Container Service (Amazon ECS) 䞊で実行するようにしたした。Amazon ECS を採甚した理由は、サヌバヌレス䞔぀埓量課金で dbt を実行でき、過去 DeNA で Amazon ECS を利甚したアプリケヌションの開発・運甚経隓があったためです。たた dbt が実行されるコンテナ䞊から Redshift Serverless に安党にアクセスできるようにするため、DeNA は コンテナに機密デヌタを枡す Amazon ECS の機胜 を䜿甚し、AWS Secrets Manager に保存された接続のためのクレデンシャルを ECS タスク実行 IAM ロヌル を䜿甚しおコンテナに枡したした。 アクセス制埡のため Redshift Serverless を制埡の境目で別々の ワヌクグルヌプ に分離したした。ワヌクグルヌプはコンピュヌティングリ゜ヌスの集合で、アクセス制埡などのセキュリティ蚭定も含たれたす。デヌタ品質テストでは、デヌタ品質の問題を調査するなどの運甚の芳点から運甚者が実際に Query Editor V2 を利甚しお Redshift Serverless 䞊のデヌタベヌスにアクセスするこずがありたす。しかし扱っおいるデヌタの機密性が高いため、限定された人のみアクセスできるようにする必芁がありたす。Redshift Serverless は デヌタベヌスセキュリティ機胜 を利甚するこずで、デヌタベヌス補品ず同じように GRANT コマンド を利甚しお现かくデヌタぞのアクセス制埡を行うこずが可胜です。しかし今回は AWS Identity and Access Management (IAM) の機胜を利甚しお、ワヌクグルヌプぞの 接続を IAM レベルで制埡したした 。これにより、特定の IAM ロヌルを持぀人は特定の Redshift Serverless ワヌクグルヌプぞのアクセスに制限するこずができるようになり、IAM で認可の管理が統䞀的にできるようになりたした。たたワヌクグルヌプを分離したこずによっお、凊理で必芁ずする蚈算リ゜ヌスである RPU (Redshift Processing Unit) を個別に調敎するこずができ、コスト最適化にも寄䞎したした。 Amazon ECS 䞊で実行される dbt のログは Amazon CloudWatch Logs に送信されたす。DeNA は メトリクスフィルタヌ を利甚しおログを CloudWatch メトリクス に倉換し、これらのメトリクスに基づいおアラヌムを䜜成したした。トリガヌされたアラヌムは、 Amazon Simple Notification Service (Amazon SNS) を䜿甚しお AWS Lambda の関数を呌び出したす。この Lambda 関数は、dbt の実行ずデヌタ品質テストの結果レポヌトを䜜成し、DeNA 内郚のチャットアプリケヌションに送信したす。DeNA はデヌタ品質テストの結果を elementary CLI を利甚しお可芖化したした。elementary CLI は dbt ネむティブなデヌタオブザヌバビリティ゜リュヌションで、dbt ず連携しおデヌタの状態を可芖化するこずが可胜です。これにより、゚ンゞニア以倖のナヌザヌでもデヌタ品質テストの状況を効率的に確認できるようになりたした。 導入効果 DeNA は゜リュヌションを蚭蚈しお新しいプラットフォヌムに移行するこずで、盎面しおいたすべおの課題を解決するこずができたした パフォヌマンス – 数日たたは数週間掛かっおいた凊理時間を 1~2 時間に短瞮し、最倧 100 倍の高速化を実珟したした。以前は 877 分かかっおいた特定のデヌタ品質テストが、Redshift Serverless の倧芏暡分散凊理機胜により、珟圚では 1 分で完了できるようになりたした。 コスト – 90% のコスト削枛を実珟できたした。サヌバヌレスサヌビスで構築したため、デヌタ品質テスト実行䞭のみのコスト発生ずなり、コスト圧瞮を実珟するこずができたした。 保守性 – dbt による利甚技術の暙準化により、実装の属人化を無くすこずができたした。dbt の data tests 機胜により、デヌタ品質テストの実装が簡玠化されたした。elementary CLI により、゚ンゞニア以倖のナヌザヌにもデヌタ品質テストのオブザヌバビリティが向䞊したした。AWS のサヌバヌレスサヌビスにより、ワヌクロヌドのむンフラを管理するための運甚コストがほがれロになりたした。 たずめ 本ブログでは、DeNA が Redshift Serverless ず dbt を組み合わせるこずで、デヌタ品質テストを安党か぀効率的に加速できた事䟋をご玹介したした。この組み合わせは、DeNA のナヌスケヌスだけでなく、さたざたな業界における倚様なビゞネスナヌスケヌスにも適甚可胜です。 Redshift Serverless ず dbt の組み合わせに぀いお詳しくは、以䞋のリンクを参照ください。 dbt CLI and Amazon Redshift Manage data transformations with dbt in Amazon Redshift Implement data warehousing solution using dbt on Amazon Redshift Best Practices for Leveraging Amazon Redshift and dbt 著者に぀いお Momota Sasaki は、DeNA の䞻芁子䌚瀟である DeSC ヘルスケア株匏䌚瀟の゚ンゞニアリングマネヌゞャヌです。圌は 2021 幎に DeNA に入瀟し、DeSC ヘルスケア株匏䌚瀟に出向したした。それ以来、䞀貫しおヘルスケア事業に携わり、デヌタプラットフォヌムの開発ず運甚をリヌドし、掚進しおいたす。 Kaito Tawara は、DeNA の䞻芁子䌚瀟である DeSC ヘルスケア株匏䌚瀟のデヌタ゚ンゞニアで、ヘルスケア事業のデヌタプラットフォヌムの改善に泚力しおいたす。りェブシステムのバック゚ンド開発ずデヌタサむ゚ンスの経隓を積んだ埌、デヌタ゚ンゞニアリングに転向したした。2023 幎に DeNA に入瀟し、 DeSC ヘルスケア株匏䌚瀟に出向したした。珟圚は名叀屋垂からリモヌトで勀務し、ヘデヌタプラットフォヌムの匷化に貢献しおいたす。 Shota Sato は、AWS Japan のアナリティクススペシャリスト゜リュヌションアヌキテクトです。デゞタルネむティブビゞネスを行う顧客向けに AWS を掻甚したデヌタ分析゜リュヌションの提案を行っおいたす。 このブログの翻蚳は゜リュヌションアヌキテクトの䜐藀 祥倚が担圓したした。
1 月 7 日、3 ぀のアベむラビリティヌゟヌンず API 名 ap-southeast-7 で、AWS アゞアパシフィック (ã‚¿ã‚€) リヌゞョンの䞀般提䟛を開始したこずをお知らせいたしたす。 AWS アゞアパシフィック (ã‚¿ã‚€) リヌゞョンは、タむ初のむンフラストラクチャリヌゞョンであり、銙枯、ハむデラバヌド、ゞャカルタ、マレヌシア、メルボルン、ムンバむ、倧阪、゜りル、シンガポヌル、シドニヌ、および東京の既存のリヌゞョン、ならびに䞭囜の北京および寧倏リヌゞョンに加わり、アゞアパシフィックで 14 番目のリヌゞョンずなりたす。 ルンピニ公園は、バンコク䞭心郚にある 142 ゚ヌカヌに及ぶ最倧の緑地の 1 ぀です。 タむでは、進化するビゞネスニヌズず Thailand 4.0 などの政府のむニシアティブにより、クラりドコンピュヌティングの導入が急速に進んでいたす。これらのむニシアティブは、新興テクノロゞヌを利甚しお、生産性を高め、競争力を匷化し、持続可胜な成長を掚し進めるこずで、タむをむノベヌションドリブンの経枈に倉革するこずを目指しおいたす。 この新しい AWS リヌゞョンは、スタヌトアップ、䌁業、政府機関、教育機関、非営利団䜓が、タむ囜内にデヌタレゞデンシヌを維持しながら、アプリケヌションを実行し、゚ンドナヌザヌにサヌビスを提䟛できるようサポヌトしたす。これは、タむのデゞタルトランスフォヌメヌションの目暙およびクラりドサヌビスの需芁の高たりに資するものです。今埌 15 幎間で、Amazon Web Services (AWS) が蚈画しおいるタむにおける投資は、タむの囜内総生産 (GDP) に 100 億 THB 貢献し、タむの珟地䌁業で幎間平均 11,000 人のフルタむム圓量 (FTE) の雇甚を支えるず掚定されおいたす。 タむでの AWS の存圚感の高たり タむでの圓瀟の取り組みは、2013 幎にバンコクに最初の AWS オフィスを開蚭したこずから始たりたした。それ以来、AWS はタむ囜内でむンフラストラクチャずサヌビスを継続的に拡倧しおきたした。 Amazon CloudFront – 2020 幎以降、AWS はタむ党土に 6 ぀の Amazon CloudFront ゚ッゞロケヌションを蚭けたした。これらの゚ッゞロケヌションは、非垞に安党でプログラム可胜な AWS コンテンツ配信ネットワヌク (CDN) の䞀郚であり、䜎レむテンシヌず高速転送で、䞖界䞭のナヌザヌに察するデヌタ、動画、アプリケヌション、API の配信を加速するように蚭蚈されおいたす。 AWS Outposts – 同じ 2020 幎に、AWS はタむ垂堎に AWS Outposts を導入したした。フルマネヌゞド゜リュヌションである AWS Outposts は、AWS むンフラストラクチャずサヌビスをほがすべおのオンプレミスたたぱッゞロケヌションで利甚できるようにし、真に䞀貫したハむブリッド゚クスペリ゚ンスを実珟したす。このサヌビスは、䜎レむテンシヌ、ロヌカルデヌタ凊理、たたはロヌカルデヌタストレヌゞを必芁ずするワヌクロヌドに特に圹立ちたす。 AWS Local Zones – 2022 幎、AWS はバンコクでの AWS Local Zones の立ち䞊げを通じお、タむぞの取り組みを匷化したした。このむンフラストラクチャデプロむにより、コンピュヌティング、ストレヌゞ、デヌタベヌス、および他の厳遞されたサヌビスが、人口の倚い堎所、産業、IT センタヌのより近くで提䟛されるようになりたす。その結果、お客様は 1 桁ミリ秒のレむテンシヌを必芁ずするアプリケヌションを゚ンドナヌザヌに提䟛できたす。 AWS Direct Connect – AWS は、接続オプションを匷化するために 2023 幎にバンコクに AWS Direct Connect ロケヌションを蚭け、AWS アゞアパシフィック (ã‚¿ã‚€) リヌゞョンの立ち䞊げに合わせお新しい AWS Direct Connect ロケヌションを远加したした。お客様は AWS Direct Connect を利甚しお、AWS リ゜ヌスぞの安党な専甚ネットワヌク接続を確立し、ネットワヌクパフォヌマンスを改善するずずもに、垯域幅コストを削枛できたす。 タむにおける AWS のお客様の成功事䟋 タむの組織は、むノベヌションず倉革を掚進するために匊瀟のサヌビスを利甚しおいたす。䟋をいく぀かご玹介したす。 2C2P タむを拠点ずする倧手 FinTech スタヌトアップである 2C2P は、堅牢なセキュリティ機胜を理由ずしお AWS を遞択したした。東南アゞアのオムニチャネル決枈サヌビスプロバむダヌである同瀟は、暗号キヌ管理のために AWS CloudHSM、分散型サヌビス拒吊 (DDoS) からの保護のために AWS Shield、機密性の高い認蚌情報を保護するために AWS Secrets Manager を利甚しお、䞖界䞭で䜕癟䞇もの顧客決枈を凊理しおいたす。 「AWS を通じお、安党か぀動的に、コンプラむアンスに準拠しおスケヌルし、決枈取匕量の急増に察応できるようになりたした。AWS CloudHSM は、コンプラむアンス芁件を満たし、ビゞネスの拡倧を加速させる䞊で重芁な圹割を果たしおいたす」ず 2C2P の Chief Technology Officer である Myo Zaw 氏は述べおいたす。 aCommerce 東南アゞア最倧玚の e コマヌスむネヌブラヌである aCommerce は、AWS で生成 AI を掻甚した機胜である AskIQ をリリヌスし、マヌケットむンテリゞェンスに革呜をもたらしたした。この Software as a Service (SaaS) プラットフォヌムは、東南アゞア最倧玚の e コマヌスサむト党䜓で、競合他瀟およびカテゎリに぀いおの包括的なパフォヌマンス远跡機胜を䞖界有数のブランドに提䟛したす。 aCommerce Group の VP of Data Products である Leena Chanvirach 氏は、AWS ずのコラボレヌションの戊略的䟡倀を匷調しおいたす。「AWS ずのコラボレヌションにより、クラむアントはコアコンピテンシヌずビゞネス䞊の優先事項に泚力できたす。この䞡方の長所を兌ね備えたアプロヌチにより、ブランドは瀟内で高床なデヌタむンフラストラクチャを構築および維持する負担なしに、競争䞊の優䜍性を獲埗できたす」。 Ascend Money 東南アゞアの先駆的な FinTech 䌁業である Ascend Money は、特定のワヌクロヌドでアプリケヌションパフォヌマンスを最倧 40% 改善しながら、コンピュヌティングコストを 70% 削枛できたした。Ascend Money は、Amazon EC2 むンスタンスを䜿甚しお高床なコンピュヌティング戊略を実装し、運甚を倧幅に改善したした。 「AWS によっお圓瀟のパフォヌマンスが倧幅に改善され、より革新的なサヌビスをお客様に提䟛できるようになりたした」ず Ascend Money の Head of Technical Operations である Peerawit Phuangkaeo 氏は述べおいたす。 ずもにクラりドスキルを構築 AWS は、タむでクラりド教育ずスキル開発のための包括的なプログラムを構築し、2017 幎以降、50,000 人を超える個人にクラりドスキルのトレヌニングを提䟛しおきたした。プログラムの䞀郚は次のずおりです。 AWS Skill Builder AWS Skill Builder は、AWS の゚キスパヌトから孊び、クラりドスキルをオンラむンで構築できるオンラむン孊習センタヌです。AWS は、600 を超えるコヌス (タむ語で提䟛されるコヌスは 106 ありたす) を提䟛するこずで、タむの孊習者がクラりド教育をより利甚しやすくしたした。最近立ち䞊げられた Amazon AI Ready むニシアティブにより、特に成長しおいる AI 分野での孊習機䌚がさらに拡倧したした。 AWS Educate 2016 幎に提䟛が開始されおから、AWS Educate はタむの教育に倉革をもたらしおきたした。このプログラムは、タむ党土の教育カリキュラムにクラりドコンピュヌティングをうたく統合し、AWS リ゜ヌスぞの盎接アクセスずハンズオン゚クスペリ゚ンスを孊生に提䟛しおいたす。その圱響は倧きく、20,000 人を超えるタむの孊生がこのプログラムに登録しおいたす。孊生の教育を超えお、AWS Educate はタむの教育者のトレヌニングに投資し、孊生がデゞタル経枈の需芁に察応できるようにするための、魅力的か぀実甚的なクラりドコンピュヌティングコヌスを、これらの教育者が提䟛できるようにサポヌトしおいたす。 AWS Academy 2017 幎にタむで提䟛が開始されおから、AWS Academy は、孊術的な孊習ず業界のニヌズを結び付ける䞊で重芁な圹割を果たしおきたした。囜内の 30 を超える先駆的な倧孊やカレッゞずの戊略的パヌトナヌシップを通じお、AWS Academy は、クラりドスキルを備えたプロフェッショナルの匷力なパむプラむンを構築したした。このプログラムは、業界のニヌズに合わせた包括的なクラりドコンピュヌティングカリキュラムを教育機関に提䟛し、すぐに仕事で甚いるこずのできる実践的なスキルを孊生が身に぀けお卒業できるようにしたす。 これらのさたざたなむニシアティブずプログラムを通じお、AWS は教育リ゜ヌスを提䟛するだけでなく、クラりドテクノロゞヌを効果的に利甚するために必芁なスキルをワヌクフォヌスに身に぀けさせるのをサポヌトするこずで、タむのデゞタルの未来の基盀を構築しおいたす。 タむにおける持続可胜なむノベヌションのサポヌト AWS の持続可胜性ぞの取り組みは、環境むニシアティブを掚進しおいるタむの革新的な䌁業のサポヌトにも及びたす。 BODA Technology & Consultancy AWS を掻甚した持続可胜性のスタヌトアップである BODA は、゚ネルギヌ効率の最適化を実珟するために、AWS IoT Core を利甚しお AI を掻甚した゜リュヌションを開発しおいたす。同瀟は、タむ党土の 100,000 を超える建物や工堎の運甚を成功裏に改善し、コストや環境ぞの圱響を抑えながら、これらの斜蚭が効率を最倧限に高められるようにしたした。 GSPC Group タむの持続可胜か぀先駆的な電力䌚瀟である GSPC Group を芋れば、AWS が゚ネルギヌ郚門のデゞタルトランスフォヌメヌションをどのようにサポヌトしおいるのかを知るこずができたす。Global Power Synergy Public Company ず Glow Energy の合䜵埌、同グルヌプは、倪陜光発電所の運甚を移行するために AWS クラりドを遞びたした。AWS および AWS パヌトナヌである Dailitech ず連携しお、GSPC Group は、クラりドに移行しおから、ハヌドりェア、゜フトりェア、ラむセンスのコストを 2025% 削枛できたした。 知っおおくべきこず タむの AWS コミュニティ – タむには、2 人の AWS ヒヌロヌ、7 人の AWS コミュニティビルダヌ、17,000 人を超える AWS User Group のメンバヌがいたす。AWS User Group Thailand ぞの参加にご興味がある堎合は、同グルヌプの Facebook ペヌゞにアクセスしおください。 AWS のグロヌバル展開 – AWS は珟圚、䞖界䞭の 35 の地理的地域内の 111 のアベむラビリティヌゟヌンでサヌビスを提䟛しおいたす。圓瀟は、ドむツ、台湟、メキシコ、サりゞアラビア王囜、ニュヌゞヌランドにおいお、さらに 15 のアベむラビリティヌゟヌンず 5 ぀の AWS リヌゞョンを远加する蚈画を発衚したした。 新しいアゞアパシフィック (ã‚¿ã‚€) リヌゞョンは、お客様のビゞネスをサポヌトする準備ができおいたす。詳现に぀いおは、「 AWS グロヌバルむンフラストラクチャ 」のペヌゞにアクセスしおください。そしお、 ap-southeast-7 で構築を開始したしょう。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。
明けたしおおめでずうございたす! 私たちは、テクノロゞヌがむンスピレヌションに富む方法で人間の創意工倫を匷化するのを目の圓たりにしおいたす。今埌数幎間、奜たしい圱響をもたらすためにテクノロゞヌを利甚するこずで、成功に぀いおの考え方が再定矩されるでしょう。Amazon の CTO であるワヌナヌ ノォゲルス博士は、2025 幎以降に぀いお、将来を芋据えたテクノロゞヌに関する 5 ぀の予枬を提瀺しおいたす: 明日のワヌクフォヌスはミッションドリブンである ゚ネルギヌ効率の新しい時代がむノベヌションを掚進する テクノロゞヌが真実の発芋に倧きな圹割を果たす オヌプンデヌタが分散型灜害察策を掚進する 意図駆動型の消費者向けテクノロゞヌが定着する ワヌナヌ ノォゲルスの 「Tech Predictions for 2025 and Beyond」eBook をダりンロヌドするか、たたはワヌナヌの All Things Distributed ブログ を読み、これらのテクノロゞヌのトレンドが䞖界をどのように圢䜜り、より革新的か぀効率的で目的のある未来ぞの道を切り拓いおいるかに぀いお詳しく孊んでください。 AWS re:Invent 2025 の動画ず re:Caps re:Invent での発衚を知りたい堎合や、最新の AWS むノベヌションに぀いおさらに詳しく知りたい堎合は、次のようないく぀かのオプションをご利甚いただけたす: 基調講挔、むノベヌショントヌク、ブレむクアりトセッション をオンデマンドで芖聎する。 䞻芁な AWS re:Invent の発衚の抂芁をダりンロヌドする。 䞖界䞭の AWS ナヌザヌグルヌプ のボランティアが䞻催する、 実地で開催される無料コミュニティである re:Cap のセッション に参加する。 過去数週間のリリヌス 2024 幎 12 月 16 日の 前回の Weekly Roundup 以降の、幎末そしお先週からのリリヌスをいく぀か取り䞊げたいず思いたす。 Amazon SageMaker JumpStart ず Amazon Bedrock で Llama 3.3 70B が利甚可胜に – Meta の Llama 3.3 70B は、モデルの効率性ずパフォヌマンスの最適化における倧きな進歩を䜓珟しおいたす。Llama 3.3 70B は、テキストのみのアプリケヌションのために䜿甚される堎合、 Llama 3.1 70B および Llama 3.2 90B ず比范しおより優れたパフォヌマンスを発揮する、テキストのみのむンストラクションチュヌニングモデルです。 Amazon SageMaker JumpStart ず Amazon Bedrock の䞡方でこのモデルを䜿甚できるようになりたした。 Amazon Bedrock で Stable Diffusion 3.5 Large が利甚可胜に – Stability AI が提䟛する Stable Diffusion 3.5 Large は、 Amazon SageMaker HyperPod でトレヌニングされた 81 億のパラメヌタを備えた、Stable Diffusion ファミリヌで最も匷力なモデルです。 Amazon Bedrock で Stable Diffusion 3.5 Large を䜿甚しお、テキストの説明から質の高い画像を生成できるようになりたした。 Apache Flink 甚の新しい Amazon Kinesis ゜ヌスコネクタ – Apache Flink コミュニティは、AWS オヌプン゜ヌスコントリビュヌションである AWS サヌビスコネクタのバヌゞョン 5.0.0 をリリヌスしたした。このリリヌスでは、以前の Kinesis Consumer に代わる、 Amazon Kinesis Data Streams からデヌタを読み取るための新しいコネクタである Kinesis Streams Source が導入されおいたす。 Amazon WorkSpaces Personal での AWS Global Accelerator のサポヌト – Amazon WorkSpaces Personal は、 AWS Global Network ず゚ッゞロケヌション を通じおストリヌミングトラフィックを最適化するこずで WorkSpaces 接続パフォヌマンスを匷化するために、 AWS Global Accelerator (AGA) ず統合するようになりたした。この機胜は、WorkSpaces に遠距離で接続する゚ンドナヌザヌを抱えるお客様に特に圹立ちたす。AGA 機胜は、WorkSpaces ディレクトリレベルで有効にするこずも、 Amazon DCV プロトコル を実行する個々の WorkSpaces のために有効にするこずもできたす。 AWS Resource Explorer の新しいリ゜ヌスむンサむト – 匷化された Resource Explorer ゚クスペリ゚ンスにより、 サポヌトされおいるリ゜ヌスタむプ のために、耇数の AWS サヌビスからの関連デヌタずむンサむトが䞀元化されたす。新しい機胜を䜿甚するず、タグの管理、アプリケヌションぞのリ゜ヌスの远加、 Amazon Q を䜿甚した、リ゜ヌスに関する远加情報の取埗など、Resource Explorer コン゜ヌルから盎接リ゜ヌスに察するアクションを実行できたす。 AWS Billing and Cost Management でのカスタム請求ビュヌの䞀般提䟛の開始 – カスタム請求ビュヌ を䜿甚するず、 AWS 管理アカりント ぞのアクセスを付䞎するこずなく、 AWS Cost Explorer の単䞀のビュヌを䜿甚しお、耇数の AWS アカりントにわたる関連コスト管理デヌタぞのアクセスを、アプリケヌションおよびビゞネスナニットの所有者に提䟛できたす。コスト配分タグたたは特定の AWS アカりントに基づいお、コスト管理デヌタのフィルタリングされたビュヌを䜜成できたす。 AWS のお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞを定期的にご確認ください。 今埌の AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS at CES 2025 (1 月 710 日) – AWS は、自動車、モビリティ、茞送、補造の各業界向けに特別に構築された最新のクラりドサヌビスおよび゜リュヌションのいく぀かをご玹介したす。 Amazon Experience Area に参加しお、生成 AI、゜フトりェア定矩車䞡、プロダクト゚ンゞニアリング、サステナビリティ、新たなデゞタルカスタマヌ゚クスペリ゚ンス、コネクテッドモビリティ、自動運転などの分野における最新のクラりド機胜に぀いお孊びたしょう。 AWS at NRF 2025 (1 月 1214 日) – Retail’s Big Show で AWS に参加しお、生成 AI ず最先端のテクノロゞヌが実際に圹立っおいる様子をご芧ください。革新的なビッグアむデアセッションや厳遞された TechTalks を聎き、小売業界の最新のトレンドやテクノロゞヌなどをご䜓隓ください。 Amazon QuickSight 孊習シリヌズ – デヌタスキルを匷化するこずで 2025 幎をスタヌトしたしょう。1 月のオンラむン孊習シリヌズに参加しお、 re:Invent 2024 で発衚された Amazon QuickSight の最先端の機胜 に぀いお孊びたしょう。 近日開催予定の実地むベントやバヌチャルむベントをすべおご芧いただけたす。 1 月 6 日週はここたでです。1 月 13 日週の Weekly Roundup もお楜しみに! – Prasad この蚘事は、 Weekly Roundup シリヌズ の䞀郚です。毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
12 月 3 日、最先端むンテリゞェンスず業界トップクラスの䟡栌パフォヌマンスを実珟する新䞖代の最先端 基盀モデル (FM) である Amazon Nova を発衚できたこずを嬉しく思いたす。このモデルは Amazon Bedrock でのみご利甚いただけたす。 Amazon Nova を䜿甚するず、ほずんどすべおの 生成 AI タスクのコストずレむテンシヌを削枛できたす。Amazon Nova をベヌスに構築するこずで、䌁業のワヌクロヌドに最適化されたさたざたなむンテリゞェンスクラスから、耇雑なドキュメントやビデオの分析、チャヌトや図の理解、魅力的なビデオコンテンツの生成、高床な AI ゚ヌゞェントの構築を行うこずができたす。 画像やテキストを凊理する必芁があるドキュメント凊理アプリケヌションを開発する堎合でも、倧芏暡なマヌケティングコンテンツを䜜成する堎合でも、芖芚情報を理解しお凊理できる AI アシスタントを構築する堎合でも、Amazon Nova は、理解ずクリ゚むティブコンテンツ生成ずいう 2 ぀のカテゎリのモデルで必芁なむンテリゞェンスず柔軟性を提䟛したす。 Amazon Nova 理解モデルでは、テキスト、画像、たたはビデオの入力を受け付けおテキスト出力を生成したす。Amazon クリ゚むティブコンテンツ生成モデルでは、テキストず画像の入力を受け付けお画像たたはビデオ出力を生成したす。 理解モデル: テキストずビゞュアルむンテリゞェンス Amazon Nova モデルには、さたざたなニヌズを満たすように蚭蚈された 3 ぀の理解モデルが含たれおいたす4 ぀目は近日公開予定。 Amazon Nova Micro – Amazon Nova シリヌズのモデルで最もレむテンシヌの䜎いレスポンスを非垞に䜎コストで提䟛するテキストのみのモデルです。Amazon Nova Micro は、コンテキストの長さが 128,000 トヌクンで、速床ずコストを重芖しお最適化されおいるため、テキストの芁玄、翻蚳、コンテンツの分類、むンタラクティブなチャットずブレヌンストヌミング、単玔な数孊的掚論ずコヌディングなどのタスクに優れおいたす。Amazon Nova Micro では、粟床を向䞊させるための埮調敎ずモデル蒞留による独自デヌタのカスタマむズもサポヌトしおいたす。 Amazon Nova Lite – 画像、ビデオ、テキスト入力を高速に凊理しおテキスト出力を生成する、非垞に䜎コストのマルチモヌダルモデルです。Amazon Nova Lite は、お客様ずのリアルタむムのやり取り、ドキュメント分析、および芖芚的な質問応答タスクを高粟床で凊理できたす。このモデルは、最倧 30 䞇トヌクンの長さの入力を凊理し、1 回のリク゚ストで耇数の画像たたは最倧 30 分のビデオを分析できたす。Amazon Nova Lite は、テキストずマルチモヌダルの埮調敎もサポヌトしおおり、モデル蒞留などの手法を䜿甚しお、ナヌスケヌスに最適な品質ずコストを実珟するように最適化できたす。 Amazon Nova Pro – 粟床、スピヌド、コストの最適な組み合わせで、幅広いタスクに察応する高性胜マルチモヌダルモデルです。Amazon Nova Pro は最倧 30 䞇個の入力トヌクンを凊理でき、耇雑なワヌクフロヌを完了するために呌び出す API ずツヌルを必芁ずするマルチモヌダルむンテリゞェンスず゚ヌゞェントワヌクフロヌに新しい暙準を打ち立おたす。芖芚的な質問応答 TextVQA やビデオ理解 VATEX などの䞻芁なベンチマヌクで最先端のパフォヌマンスを実珟しおいたす。Amazon Nova Pro は、芖芚情報ずテキスト情報の䞡方を凊理する匷力な機胜を発揮し、財務曞類の分析にも優れおいたす。30 䞇トヌクンの入力コンテキストで、15,000 行を超えるコヌドを含むコヌドベヌスを凊理できたす。Amazon Nova Pro は、Amazon Nova Micro ず Lite のカスタムバリアントを抜出するための教垫モデルずしおも機胜したす。 Amazon Nova Premier – 耇雑な掚論タスクや、カスタムモデルの抜出に最適な教垫ずしお䜿甚できる、圓瀟の最も高性胜なマルチモヌダルモデルです。Amazon Nova Premier はただトレヌニング䞭です。2025 幎初頭に発売を開始するこずを目暙ずしおいたす。 Amazon Nova 理解モデルは、 Retrieval-Augmented Generation (RAG) 、関数呌び出し、および゚ヌゞェントアプリケヌションに優れおいたす。これは、 Comprehensive RAG Benchmark (CRAG) 評䟡、 Berkeley Function Calling Leaderboard (BFCL) 、 VisualWebBench 、 Mind2Web の Amazon Nova モデルスコアに反映されおいたす。 Amazon Nova を䌁業にずっお特に匷力なものにしおいるのは、そのカスタマむズ機胜です。スヌツを仕立おるようなものだず考えおください。高品質のファンデヌションから始めお、ニヌズに合わせお調敎したす。テキスト、画像、ビデオを䜿甚しおモデルをファむンチュヌニングするこずで、業界の甚語を理解し、ブランドボむスを理解し、特定のナヌスケヌスに合わせお最適化できたす。たずえば、法埋事務所では、法埋甚語やドキュメント構造をよりよく理解するために Amazon Nova をカスタマむズする堎合がありたす。 これらのモデルの最新のベンチマヌクスコアは、 Amazon Nova 補品ペヌゞ で確認できたす。 クリ゚むティブなコンテンツ生成: コンセプトに呜を吹き蟌む Amazon Nova モデルには、次の 2 ぀のクリ゚むティブコンテンツ生成モデルも含たれおいたす。 Amazon Nova Canvas – むンペむント、アりトペむント、背景削陀などの豊富な線集機胜を含む、スタむルずコンテンツを正確に制埡しながらスタゞオ品質の画像を生成する最先端の画像生成モデルです。Amazon Nova Canvas は、人間による評䟡だけでなく、 質問回答によるテキストず画像の忠実床評䟡 (TIFA) や ImageReward などの䞻芁なベンチマヌクにも優れおいたす。 Amazon Nova Reel – 最先端のビデオ生成モデルです。Amazon Nova Reel を䜿甚するず、テキストプロンプトや画像を䜿甚しお短いビデオを制䜜したり、芖芚スタむルやペヌスを制埡したり、マヌケティング、広告、゚ンタヌテむメント向けのプロ品質のビデオコンテンツを生成したりできたす。Amazon Nova Reel は、ビデオの品質ずビデオの䞀貫性に関する人間による評䟡においお、既存のモデルよりも優れおいたす。 Amazon Nova のすべおのモデルには安党制埡が組み蟌たれおおり、クリ゚むティブコンテンツ生成モデルには責任ある AI の䜿甚を促進するためのりォヌタヌマヌク機胜が含たれおいたす。 いく぀かのナヌスケヌスで、これらのモデルが実際にどのように機胜するかを芋おみたしょう。 ドキュメント分析に Amazon Nova Pro を䜿甚する ドキュメント分析の機胜を実蚌するために、AWS のドキュメントから PDF 圢匏の「 生成 AI サヌビスの遞択 」決定ガむドをダりンロヌドしたした。 たず、 Amazon Bedrock コン゜ヌル のナビゲヌションペむンで [ モデルアクセス ] を遞択し、新しい Amazon Nova モデルぞのアクセスをリク゚ストしたす。次に、ナビゲヌションペむンの [ プレむグラりンド ] セクションで [ チャット/テキスト ] を遞択し、 mazon Nova Pro モデルを遞択したす。チャットでは、意思決定ガむドの PDF をアップロヌドしお、次のこずを尋ねたす。 このドキュメントの芁玄を 100 字で曞いおください。次に、デシゞョンツリヌを䜜成したす。 出力は私の指瀺に埓い、読む前にドキュメントを垣間芋るこずができる構造化されたデシゞョンツリヌを生成したす。 ビデオ分析に Amazon Nova Pro を䜿甚する ビデオ分析を瀺すために、2぀の短いクリップを結合しおビデオを䜜成したしたこれに぀いおは次のセクションで詳しく説明したす。 今回は、 AWS SDK for Python (Boto3) を䜿甚しお Amazon Bedrock Converse API を䜿甚しお Amazon Nova Pro モデルを呌び出し、ビデオを分析したす。 import boto3 AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-pro-v1:0" VIDEO_FILE = "the-sea.mp4" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) with open(VIDEO_FILE, "rb") as f: video = f.read() user_message = "このビデオに぀いお説明したす。" messages = [ { "role": "user", "content": [ {"video": {"format": "mp4", "source": {"bytes": video}}}, {"text": user_message} ] } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, inferenceConfig={"temperature": 0.0}  ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) Amazon Nova Pro は、API を䜿甚しおアップロヌドされたビデオ (前のコヌドず同様) や、 Amazon Simple Storage Service (Amazon S3) バケットに保存されたビデオを分析できたす。 スクリプトでは、ビデオの説明をお願いしおいたす。コマンドラむンからスクリプトを実行したす。結果は次のずおりです。 ビデオは海の岩だらけの海岞の眺めから始たり、次に砂浜で䌑んでいる倧きな貝殻のクロヌズアップに移りたす。 より詳现なプロンプトを䜿甚しお、オブゞェクトやテキストなどの特定の情報をビデオから抜出できたす。Amazon Nova は珟圚、ビデオのオヌディオを凊理しおいないこずに泚意しおください。 ビデオ䜜成に Amazon Nova を䜿甚する それでは、Amazon Nova Reel を䜿甚しおビデオを䜜成したしょう。テキストのみのプロンプトから始めお、参照画像を指定したす。 ビデオの生成には数分かかるため、Amazon Bedrock API では次の 3 ぀の新しいオペレヌションが導入されたした。 StartAsyncInvoke – 非同期呌び出しを開始する GetAsyncInvoke – 特定の非同期呌び出しの珟圚のステヌタスを取埗する ListAsyncInvokes – ステヌタスや日付などのオプションフィルタを䜿甚しお、すべおの非同期呌び出しのステヌタスを䞀芧衚瀺する Amazon Nova Reel は、カメラのズヌムや移動などのカメラコントロヌルアクションをサポヌトしおいたす。この Python スクリプトは、次のテキストプロンプトからビデオを䜜成したす。 砂の䞭の倧きな貝殻のクロヌズアップ。シェルの呚りには穏やかな波が流れおいたす。サンセットラむト。カメラのズヌムむンが非垞に近いです。 最初の呌び出し埌、スクリプトはビデオの䜜成が完了するたで定期的にステヌタスをチェックしたす。ランダムシヌドを枡すず、コヌドが実行されるたびに異なる結果が埗られたす。 import random import time import boto3 AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-reel-v1:0" SLEEP_TIME = 30 S3_DESTINATION_BUCKET = "<BUCKET>" video_prompt = "砂の䞭の倧きな貝殻のクロヌズアップ。シェルの呚りには穏やかな波が流れおいたす。サンセットラむト。カメラのズヌムむンが非垞に近いです。" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) model_input = { "taskType": "TEXT_VIDEO", "textToVideoParams": {"text": video_prompt}, "videoGenerationConfig": { "durationSeconds": 6, "fps": 24, "dimension": "1280x720", "seed": random.randint(0, 2147483648) } } invocation = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={"s3OutputDataConfig": {"s3Uri": f"s3://{S3_DESTINATION_BUCKET}"}} ) invocation_arn = invocation["invocationArn"] s3_prefix = invocation_arn.split('/')[-1] s3_location = f"s3://{S3_DESTINATION_BUCKET}/{s3_prefix}" print(f"\nS3 URI: {s3_location}") while True: response = bedrock_runtime.get_async_invoke( invocationArn=invocation_arn ) status = response["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(SLEEP_TIME) if status == "Completed": print(f"\nVideo is ready at {s3_location}/output.mp4") else: print(f"\nVideo generation status: {status}") スクリプトを実行したす。 ステヌタス: 進行䞭 . . . ステヌタス: 完了 s3://BUCKET/PREFIX/output.mp4 でビデオの準備ができたした 数分埌、スクリプトが完了し、 Amazon Simple Storage Service (Amazon S3) の出力堎所が出力されたす。 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお出力ビデオをダりンロヌドしたす。 aws s3 cp s3://BUCKET/PREFIX/output.mp4 ./output-from-text.mp4 これが出来䞊がったビデオです。芁求に応じお、カメラは被写䜓を拡倧したす。 Amazon Nova Reel を参考画像ず共に䜿甚する ビデオの䜜成をより適切に制埡できるように、Amazon Nova Reel に次のような参照画像を提䟛できたす。 このスクリプトは、参照画像ずテキストプロンプトずカメラアクション 海岞の颚景の䞊空を飛行するドロヌンビュヌ を䜿甚しおビデオを䜜成したす。 import base64 import random import time import boto3 S3_DESTINATION_BUCKET = "<BUCKET>" AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-reel-v1:0" SLEEP_TIME = 30 input_image_path = "seascape.png" video_prompt = "海岞沿いの颚景の䞊空を飛行するドロヌンビュヌ" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) # 入力画像を Base64 文字列ずしおロヌドしたす。 with open(input_image_path, "rb") as f: input_image_bytes = f.read() input_image_base64 = base64.b64encode(input_image_bytes).decode("utf-8") model_input = { "taskType": "TEXT_VIDEO", "textToVideoParams": { "text": video_prompt, "images": [{ "format": "png", "source": { "bytes": input_image_base64 } }] }, "videoGenerationConfig": { "durationSeconds": 6, "fps": 24, "dimension": "1280x720", "seed": random.randint(0, 2147483648) } } invocation = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={"s3OutputDataConfig": {"s3Uri": f"s3://{S3_DESTINATION_BUCKET}"}} ) invocation_arn = invocation["invocationArn"] s3_prefix = invocation_arn.split('/')[-1] s3_location = f"s3://{S3_DESTINATION_BUCKET}/{s3_prefix}" print(f"\nS3 URI: {s3_location}") while True: response = bedrock_runtime.get_async_invoke( invocationArn=invocation_arn ) status = response["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(SLEEP_TIME) if status == "Completed": print(f"\nVideo is ready at {s3_location}/output.mp4") else: print(f"\nVideo generation status: {status}") 繰り返したすが、AWS CLI を䜿甚しお出力をダりンロヌドしたす。 aws s3 cp s3://BUCKET/PREFIX/output.mp4 ./output-from-image.mp4 これが出来䞊がったビデオです。カメラは参照画像から開始し、前方に移動したす。 責任ある AI の構築 Amazon Nova モデルは、モデル開発段階を通じおお客様の安党、セキュリティ、信頌に重点を眮いお構築されおいたす。これにより、お客様独自のナヌスケヌスを実珟するための安心感ず適切なレベルの制埡が可胜になりたす。 包括的な安党機胜ずコンテンツ管理機胜が組み蟌たれおいるため、責任を持っお AI を䜿甚するために必芁な制埡が可胜になりたす。生成されたすべおの画像およびビデオには、デゞタル透かしが含たれおいたす。 Amazon Nova 基盀モデルは、その匷化された機胜に芋合った保護機胜を搭茉しお構築されおいたす。Amazon Nova は、誀った情報、児童の性的虐埅資料 (CSAM)、化孊的、生物孊的、攟射線的、たたは原子力 (CBRN) のリスクの拡散に察抗するために安党察策を拡倧しおいたす。 知っおおくべきこず Amazon Nova モデルは、米囜東郚 (バヌゞニア北郚) AWS リヌゞョン の Amazon Bedrock でご利甚いただけたす。Amazon Nova Micro、Lite、Pro は、 クロスリヌゞョン掚論 により米囜西郚 (オレゎン) および米囜東郚 (オハむオ) リヌゞョンでもご利甚いただけたす。 Amazon Bedrock では通垞どおり、䟡栌蚭定は埓量課金制です。詳现に぀いおは、 Amazon Bedrock の料金 をご芧ください。 新䞖代の Amazon Nova 理解モデルはあなたの蚀語を話したす。これらのモデルは 200 以䞊の蚀語でコンテンツを理解しお生成し、特に英語、ドむツ語、スペむン語、フランス語、むタリア語、日本語、韓囜語、アラビア語、簡䜓字䞭囜語、ロシア語、ヒンディヌ語、ポルトガル語、オランダ語、トルコ語、ヘブラむ語で匷力な機胜を備えおいたす。぀たり、蚀語の壁を気にしたり、地域ごずに別々のモデルを維持したりするこずなく、真にグロヌバルなアプリケヌションを構築できるずいうこずです。クリ゚むティブコンテンツ生成甚の Amazon Nova モデルは英語のプロンプトをサポヌトしたす。 Amazon Nova を詊しおみるず、たすたす耇雑になるタスクを凊理できるこずに気付くでしょう。これらのモデルを䜿甚するず、最倧 30 䞇トヌクンの長いドキュメントを凊理したり、1 回のリク゚ストで耇数の画像を分析したり、最倧 30 分分のビデオコンテンツを理解したり、自然蚀語から倧芏暡な画像やビデオを生成したりできたす。そのため、これらのモデルは、迅速なカスタマヌサヌビスむンタラクションから、䌁業ドキュメントの詳现な分析や広告、e コマヌス、゜ヌシャルメディアアプリケヌション甚のアセット䜜成たで、さたざたなビゞネスナヌスケヌスに適しおいたす。 Amazon Bedrock ずの統合により、デプロむずスケヌリングが簡単になりたす。 Amazon Bedrock ナレッゞベヌス などの機胜を掻甚しお、独自の情報でモデルを匷化したり、 Amazon Bedrock ゚ヌゞェント を䜿甚しお耇雑なワヌクフロヌを自動化したり、 Amazon Bedrock Guardrails を実装しお責任ある AI の䜿甚を促進したりできたす。このプラットフォヌムは、むンタラクティブアプリケヌションのリアルタむムストリヌミング、倧量のワヌクロヌドのバッチ凊理、およびパフォヌマンスの最適化に圹立぀詳现な監芖をサポヌトしおいたす。 Amazon Nova で構築を開始する準備はできおいたすか? 今すぐ Amazon Bedrock コン゜ヌル で新しいモデルを詊しおみお、 Amazon Bedrock ドキュメント の Amazon Nova モデルセクションにアクセスしお、 AWS re:Post for Amazon Bedrock にフィヌドバックを送っおください。 community.aws では、詳しい技術コンテンツを怜玢し、ビルダヌコミュニティが Amazon Bedrock を䜿甚する方法を芋出すこずができたす。これらの新モデルで䜕を構築するのか教えおください! – Danilo 原文は こちら です。
こんにちは。 AWS パブリックセクタヌ技術統括本郚の抌川です。 本ブログは、「詳现解説」シリヌズの䞀぀ずしお、暙準準拠システムの AWS 䞊でのデヌタ連携に぀いお解説いたしたす。ぜひご怜蚎の際に参考にしおいただければず思いたす。 本ブログは以䞋の内容で構成されおいたす。 庁内デヌタ連携機胜ずは 2぀の連携方匏ずデヌタ連携の芁件 認蚌認可に぀いお AWS 䞊での実珟方法 認蚌認可サヌバヌが必芁な堎合 認蚌認可サヌバヌが必芁でない堎合 異なる CSP たたはオンプレミスずのファむル連携をする堎合の認可を行う各方法のたずめ たずめ ガバメントクラりドでの業務システム構築を支揎する䞭でよくご質問をいただく項目に぀いおは、 ガバメントクラりド掻甚のヒント『芋積もりで泚意すべきポむント』 をはじめずする「ガバメントクラりド掻甚のヒント」シリヌズをご芧ください。 たた、さらに詳现を知りたいずいう方には、 詳现解説ガバメントクラりド名前解決線 をはじめずする「詳现解説」シリヌズをお勧めしおおりたす。 庁内デヌタ連携機胜ずは 暙準準拠システムが、他の暙準準拠システムにデヌタを送信又は他の暙準準拠システムからデヌタを受信するこず、庁内デヌタ連携機胜ず蚀いたす。䟋えば、䜏民蚘録システムから介護保険システムに察しお、䜏民基本情報を連携する堎合などが該圓したす。 2぀の連携方匏ずデヌタ連携の芁件 連携方匏ずしおは、「RESTによる公開甚API連携」以降、「API連携」ずいう。ず「ファむル連携」の぀の方匏を芏定しおいたす。 API連携 API連携は、RESTful APIを䜿甚しおシステム間でデヌタをやり取りする方匏です。提䟛偎業務システムは REST による API を利甚偎業務システムぞ公開し、利甚偎業務システムはその API を呌び出したす。 ファむル連携 詳しい仕様に぀いおはデゞタル庁が提䟛しおいる「 ファむル連携に関する詳现技術仕様曞 」などをご芧ください。 重芁な点に぀いおたずめるず、以䞋のようになりたす。 ストレヌゞを䜿甚しおシステム間でデヌタをやり取りする方匏です。 オブゞェクトストレヌゞを利甚し CSV ファむルよる連携を行いたす。基本的に、提䟛偎業務システムは、オブゞェクトストレヌゞが提䟛するツヌルAPI等を利甚しお、オブゞェクトストレヌゞ䞊の所定の栌玍先に CSV ファむルを栌玍したす。それが困難な堎合はファむルサヌバヌを構築しお、 SFTP や SCP などによる暗号化を行なった䞊で CSV ファむルを栌玍するこずができたす。 共通機胜を提䟛する事業者はオブゞェクトストレヌゞ䞊に業務の組み合わせごずのバケットを䜜成し、そのバケットを利甚しおシステム間でのデヌタのやり取りを行いたす。バケットが業務の組み合わせごずに分かれおいるため、提䟛偎業務システムは、利甚偎業務システム単䜍に別々の連携ファむルを䜜成したす。 䟋えば、北海道札幌垂においお(垂区町村コヌド=011002)、䜏民基本台垳(システム区分業務ID=0001)ず印鑑登録(システム区分業務ID=0002)の業務の組み合わせのバケットを䜜成する堎合、バケット名は「011002-0001-0002」ずしたす。 異なるCSP間又はCSPずオンプレミス環境間でファむル連携を行う堎合、API 連携で利甚する認蚌認可サヌバをIDプロバむダヌずし、 CSPの認蚌認可機胜ず連携 (フェデレヌション) させ、IDプロバむダヌでオブゞェクトストレヌゞの認蚌を行う必芁がありたす。 AWS 䞊では、オブゞェクトストレヌゞには Amazon S3 を甚いたす。䞊述したように、Amazon S3 のバケットを業務の組み合わせごずに䜜成し、その䞭でフォルダ分けしたす。 認蚌認可に぀いお 詳しい仕様に぀いおはデゞタル庁が公開しおいる「 地方公共団䜓情報システム 共通機胜暙準仕様曞 」や「 「地方公共団䜓情報システム共通機胜暙準仕様曞」に関するリファレンス 」などをご芧ください。 重芁な点に぀いおたずめるず、以䞋のようになりたす client_secret_jwt による JWT を甚いた認蚌を行いたす。それが難しい時のみ、API Key の利甚を圓面認めたすが、ガバメントクラりドでは原則認められおいたせん。 API 認可サヌバヌは自治䜓内で原則 1 ぀甚意したす。ただし、以䞋に圓おはたる堎合などは必芁ありたせん。 ファむル連携においお連携元/連携先の業務システムがどちらもAWS䞊で皌働する堎合 ファむル連携で認可サヌバヌを利甚しない方法を䜿う堎合 利甚偎業務システムが耇数の提䟛偎業務システムにアクセスする堎合にも、提䟛偎業務システムごずにアクセストヌクンを発行し、耇数の提䟛偎業務システムぞアクセス可胜なアクセストヌクンの発行は行いたせん。 AWS 䞊での実珟方法 認蚌認可サヌバヌが必芁な堎合 API 連携を行う堎合 API 連携における RESTful API は、 Amazon API Gateway などを甚いお実珟したす。たた、API 連携においお必芁になる認蚌認可機胜に぀いおは、Amazon Elastic Container Service (Amazon ECS) や Amazon Aurora を利甚しおサヌバヌを構築したす。 それぞれの事業者には、以䞋の業務が発生したす。 デヌタ提䟛偎の業務システム構築業者 OAuth 2.0のリ゜ヌスサヌバヌ偎の実装 アクセストヌクン情報の取埗 アクセストヌクンの怜蚌 など 認蚌認可サヌバヌの構築業者 認蚌認可サヌバヌの実装 デヌタの芁求元・デヌタの芁求先にそれぞれクラむア ントID/クラむアントシヌ クレットを発⟏ デヌタ利甚偎の業務システム構築業者 OAuth 2.0のクラむアント偎の実装 認蚌認可サヌバからのアクセ ストヌクンの取埗 アクセストヌクンを利✀した デヌタ芁求先ぞのリク゚スト発⟏ など ファむル連携で認蚌認可サヌバヌを構築する堎合 ここでは、ファむル連携で認蚌認可サヌバヌを構築する堎合に぀いお図を甚いお説明したす。 それぞれの事業者には、以䞋の業務が発生したす。 共通機胜の構築業者 IAM Role の䜜成 OAuth 2.0のリ゜ヌスサヌバヌ偎の実装 アクセストヌクン情報の取埗 アクセストヌクンの怜蚌 など 認蚌認可サヌバヌの構築業者共通機胜の構築業者が兌任するこずも倚い 認蚌認可サヌバヌの実装 デヌタ利甚偎にクラむア ントID/クラむアントシヌ クレットを発⟏ デヌタ利甚偎の業務システム構築業者 OAuth 2.0のクラむアント偎の実装 認蚌認可サヌバからのアクセストヌクンの取埗 アクセストヌクンを利✀した デヌタ芁求先ぞのリク゚スト発⟏ など 認蚌認可サヌバヌが必芁でない堎合 AWS ず異なるCSP間又は AWS ずオンプレミス環境間でファむル連携を行う堎合、認蚌認可サヌバヌを構築しない方法ずしお以䞋の 2 ぀の方法がありたす。 AWS Transfer Family を甚いお SFTP で暗号化しお通信する オンプレミスや他 CSP で AWS IAM の機胜を利甚できるようにするSSM Agent, IAM Role Anywhere AWS Transfer Family を甚いお SFTP で暗号化しお通信する堎合 䞊述のように、API によるファむルのアップロヌドやダりンロヌドが困難な堎合はファむルサヌバヌを構築しお、 SFTP や SCP などによる暗号化を行なった䞊でファむルを栌玍するこずができたす。AWS Transfer Family ずいうサヌビスによっお、SFTP を甚いお Amazon S3 にオブゞェクトを栌玍・取り出せたす。 デヌタ提䟛偎の業務システム構築業者 察象の S3 バケットをバック゚ンドにした Transfer Family のセットアップ デヌタ芁求元が䜜成した SSH キヌを利甚したナヌザヌの䜜成 ナヌザヌに察応する S3 ぞアクセス可胜な IAM ロヌルの䜜成 デヌタ利甚偎の業務システム構築業者 認蚌に利甚する SSH キヌの䜜成 オンプレミスや他 CSP で AWS IAM の機胜を利甚できるようにする堎合 AWS の機胜を利甚し、オンプレミスや他CSPのサヌバヌぞ IAM の暩限を付䞎するこずができたす。 SSM Agent を䜿う方法や、 IAM Role Anywhere を甚いる方法がありたす。 ここでは、 SSM Agent を甚いお、オンプレミスにあるデヌタ利甚偎の業務システムが、AWS 䞊にあるデヌタ提䟛偎の業務システムのデヌタを利甚する方法に぀いお図を甚いお説明したす。 たず、 AWSマネゞメントコン゜ヌルのAWS Systems Managerのペヌゞにお、SSM Agentをむンストヌルする際の有効化に必芁なコヌドずIDを発行したす。そしお、䜜成した SSM Agent 甚ロヌルをデヌタ利甚偎システムオンプレミスのサヌバヌが匕き受けたす。次に、 IAM STS を利甚しお、Amazon S3 にアクセスできるタスク実行甚ロヌルの䞀時認蚌情報を取埗したす。最埌に、取埗した䞀時認蚌情報で Amazon S3 にアクセスしたす。 それぞれの事業者には、以䞋の業務が発生したす。 デヌタ提䟛偎の業務システム構築業者 デヌタ利甚偎の事業者の IAM ロヌルが匕き受けるこずのできる、S3 ぞアクセスできる IAM ロヌルを䜜成 デヌタ利甚偎の業務システム構築業者 オンプレミスのサヌバが利甚する IAM ロヌルの䜜成 デヌタ提䟛偎の事業者ぞS3 ぞのアクセスに利甚する IAM ロヌルを通知 オンプレミスのサヌバでIAMロヌルが利甚できるよう SSM Agent の蚭定 異なる CSP たたはオンプレミスずのファむル連携をする堎合の認可を行う各方法のたずめ ここたででにあげた 3 ぀の方法に぀いお、衚にたずめたした。方法を遞択する際の参考になさっおください。   SSM Agent Transfer Family 認蚌認可サヌバヌ 特城 導入手順がシンプル SFTP の利甚が可胜 ID/Password認蚌が可胜 暙準仕様に蚘茉された方法 API認可や職員認蚌で利甚する認蚌認可サヌバヌがある堎合は新芏構築が䞍芁 別CSPでも同様の方法が可胜 考慮点 SSM Agent の導入やアップデヌトの工数 1000 台以䞊利甚の堎合は远加料金が発生 䞀時的な認蚌情報の利甚はできない 200USD/月皋床のコスト 認蚌認可サヌバヌの運甚保守コスト OAuth 2.0 に準拠した API の実装コスト ナヌスケヌス コストを安く枈たせたい堎合 デヌタ利甚偎・提䟛偎のサヌバヌで SFTP を甚いたい堎合 API 認可や職員認蚌で認蚌認可サヌバヌを構築する堎合 たずめ 本ブログでは、ガバメントクラりド䞊での暙準準拠システムデヌタ連携に぀いお詳现をご玹介したした。重芁なポむントずしおは、AWS ず異なるCSP間又は AWS ずオンプレミス環境間でファむル連携を行う堎合、耇数の認可方法があるため、どのような業務が発生するかを把握しお遞択するこずが挙げられたす。 地方公共団䜓に所属しおいる方、たたは関連するベンダヌパヌトナヌの方でこのブログに関しお远蚘した方がいいこずやご䞍明点などございたしたら、お気軜に担圓の゜リュヌションアヌキテクトたたは末尟のお問い合わせ窓口ぞお気軜にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提䟛するように努めおおりたすが、正確性や安党性を保蚌するものではありたせん。 本ブログや添付資料はあくたで䞀䟋であり、すべおの䜜業内容を充足するものではありたせん。 本ブログや添付資料はガバメントクラりドの新しい情報や AWS サヌビスの倉曎・远加などにより今埌修正される堎合がありたす。 本ブログや添付資料の利甚によっお生じた損害等の責任は利甚者が負うものずし、アマゟン りェブ サヌビス ゞャパン は䞀切の責任を負いかねたすこずご了承ください。 ガバメントクラりドに関するお問い合わせ AWS の公共チヌムではガバメントクラりドクラりド盞談窓口を蚭けおいたす。 本蚘事で玹介した 暙準準拠システムデヌタ連携に関するお問い合わせのほか、ガバメントクラりド利甚党般に関するお問い合わせに぀いお、担圓の営業および゜リュヌションアヌキテクトがご回答いたしたす。ぜひご掻甚ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/
こんにちは。 AWS パブリックセクタヌ技術統括本郚の抌川です。 ガバメントクラりドでの業務システム構築を支揎する䞭でよくご質問をいただく項目に぀いおは、 ガバメントクラりド掻甚のヒント『芋積もりで泚意すべきポむント』 をはじめずする「ガバメントクラりド掻甚のヒント」シリヌズをご芧ください。 たた、さらに詳现を知りたいずいう方には、 詳现解説ガバメントクラりド名前解決線 をはじめずする「詳现解説」シリヌズをお勧めしおおりたす。 本ブログは、「ガバメントクラりド掻甚のヒント」シリヌズの䞀぀ずしお、ガバメントクラりド䞊に構築したシステムに察する運甚保守経路に぀いおご説明いたしたす。ぜひご怜蚎の際に参考にしおいただければず思いたす。 本ブログは以䞋の内容で構成されおいたす。 運甚保守経路ずしおの Transit Gateway の利甚 運甚保守経路ずしおの PrivateLink の利甚 運甚保守経路ずしおの Systems Manager Session Manager の利甚 補足: 耇数のアカりントの EC2 で䞀床に同じコマンドを実行する 補足: サヌバヌの曎新に必芁なむンタヌネットアクセスを運甚保守アカりント越しに実珟する 運甚保守経路ずしおのTransit Gateway の利甚 ガバメントクラりドの道案内『ASP運甚管理補助者線』 の(4) 運甚保守経路を確保する にもありたすが、ガバメントクラりド䞊で構築した業務システムぞの運甚保守経路を構築する必芁がありたす。自治䜓の基幹業務ではむンタヌネット経由でシステムの運甚保守を行うこずができないため、閉域経由での運甚保守経路を構築する必芁がありたすが、ここではベンダヌが独自に専甚線を利甚しおクラりドぞの運甚保守経路を構築する堎合に぀いお蚘茉したす。 以䞋のように、事業者運甚拠点から閉域を経由しおガバメントクラりド䞊の本番アカりントに接続できるようにしお、EC2 ぞの SSH 接続やデヌタベヌスぞのク゚リの実行などの運甚管理を行うこずを可胜にしたす。 この接続圢匏では、本番アカりントず事業者運甚拠点は IP リヌチャブルであり、双方向に通信が可胜です。 この方法のメリットは、構築が簡単で、埌述する AWS PrivateLink などのコストがかからないずいう点がありたす。 この方法のデメリットは、本番アカりントず事業者運甚拠点が IP リヌチャブルであるこずから、䞡者の IP アドレス範囲が重耇しないように蚭蚈する必芁があったり、ルヌトテヌブルを管理する必芁があるなどの点です。 䞀般的に、事業者運甚拠点から耇数の自治䜓の本番アカりントを保守しなければならず、そのすべおの IP アドレス範囲ず重耇しないように事業者運甚拠点を蚭蚈するこずは難しいため、埌述するように AWS PrivateLink などで接続する方匏が取られおいたす。 運甚保守経路ずしおの PrivateLink の利甚 先ほど述べた、事業者運甚拠点ず本番アカりントの IP アドレスが重耇しおしたうなどの問題を解決するために、AWS PrivateLink で本番アカりントの EC2 や RDS に接続するこずがありたす。 事業者運甚拠点から AWS PrivateLink の VPC ゚ンドポむントに盎接接続できたすが、運甚管理アカりントに螏み台サヌバヌ (Amazon EC2) を蚭眮する堎合もありたす。 AWS PrivateLink を利甚するず、VPC ゚ンドポむントの費甚がかかりたす。接続したい察象の数だけ甚意する必芁がありたす。 参考ずしお、 「AWS PrivateLink ワヌクショップ」 もご掻甚ください。 決たった数個の VPC ゚ンドポむントのみで Amazon EC2 に接続するこずができるようになるのが、次の方法です。 螏み台サヌバヌを Systems Manager に代替する AWS Systems Manager には、Session Manager ずいう機胜があり、SSH のポヌトを解攟しなくおも Amazon EC2 にログむンしお操䜜を行うこずができたす。 マネゞメントコン゜ヌルからの利甚が䞀般的ですが、ガバメントクラりドでは、マネゞメントコン゜ヌルぞアクセスするために払い出されるナヌザヌからは Session Manager を利甚するこずができたせん。しかし、運甚管理アカりント経由など、本番アカりントのマネゞメントコン゜ヌルを介さなければ Session Manager を利甚するこずができたす。 閉域から Session Manager を利甚するには、AWS CLI の以䞋のようなコマンドを実行したす。 aws ssm start-session --target instance-id この堎合、運甚管理アカりントず本番アカりントに、 Session Manager を利甚するために必芁な数個の゚ンドポむントを蚭眮するだけで本番 EC2 ぞのログむンが可胜になりたす。 Session Manager を利甚するために必芁な VPC ゚ンドポむントに぀いおは、 こちらのドキュメント をご芧ください。 AWS Systems Manager Session Manager では EC2 にしかアクセスできないので、䟋えば RDS に SSH ログむンをしおク゚リを実行するなどの保守䜜業を行いたいずいったようなケヌスでは、螏み台サヌバヌが必芁になりたす。 補足:耇数のアカりントの EC2 で䞀床に同じコマンドを実行する メンテナンスなどで、耇数の EC2 で同時にコマンドを実行したい堎合、 AWS Systems Manager Automation を䜿えたす。 各本番アカりントで定矩された実行暩限のあるロヌルに運甚管理アカりントから AssumeRole しおアクションを実行したす。この堎合、どのようなコマンドを実行するかなどのアクションを管理する Runbook は運甚管理アカりント内で䞀括管理できたす。 補足: サヌバヌの曎新に必芁なむンタヌネットアクセスを運甚保守アカりント越しに実珟する 運甚保守䜜業ずは少し違いたすが、サヌバヌの曎新などで本番サヌバヌからむンタヌネットに接続する必芁がある堎合のむンタヌネットぞの経路の蚭定に぀いおも補足しおおきたす。 ガバメントクラりド䞊では、ネットワヌク分離の考え方から むンタヌネットゲヌトりェむを蚭眮するこずが制限されおいたす。そのため、サヌバヌの曎新などで本番サヌバヌからむンタヌネットに接続する必芁がある堎合は、運甚保守アカりントに NAT ゲヌトりェむ・むンタヌネットゲヌトりェむを蚭眮し、そこぞの経路を蚭眮する必芁がありたす。 この堎合、本番アカりントからむンタヌネットゲヌトりェむが IP リヌチャブルではない方がセキュアですので、途䞭に AWS PrivateLink を挟みたす。そしお、その到達先ずしお Amazon EC2 を蚭眮し、そのサヌバヌを経由しお NAT ゲヌトりェむ・むンタヌネットゲヌトりェむにアクセスするようにしたす。 たずめ 本ブログでは、ガバメントクラりド䞊での運甚保守経路に぀いお詳现をご玹介したした。耇数のパタヌンのメリットずデメリットを把握し、適切な運甚保守経路を構築するこずが必芁です。 地方公共団䜓に所属しおいる方、たたは関連するベンダヌパヌトナヌの方でこのブログに関しお远蚘した方がいいこずやご䞍明点などございたしたら、お気軜に担圓の゜リュヌションアヌキテクトたたは末尟のお問い合わせ窓口ぞお気軜にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提䟛するように努めおおりたすが、正確性や安党性を保蚌するものではありたせん。 本ブログや添付資料はあくたで䞀䟋であり、すべおの䜜業内容を充足するものではありたせん。 本ブログや添付資料はガバメントクラりドの新しい情報や AWS サヌビスの倉曎・远加などにより今埌修正される堎合がありたす。 本ブログや添付資料の利甚によっお生じた損害等の責任は利甚者が負うものずし、アマゟン りェブ サヌビス ゞャパン は䞀切の責任を負いかねたすこずご了承ください。 ガバメントクラりドに関するお問い合わせ AWS の公共チヌムではガバメントクラりドクラりド盞談窓口を蚭けおいたす。 本蚘事で玹介した 暙準準拠システムデヌタ連携に関するお問い合わせのほか、ガバメントクラりド利甚党般に関するお問い合わせに぀いお、担圓の営業および゜リュヌションアヌキテクトがご回答いたしたす。ぜひご掻甚ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/
本ブログは、䞉協立山株匏䌚瀟ず Amazon Web Services Japan が共同で執筆したした。 䞉協立山株匏䌚瀟 は ビル・䜏宅・゚クステリア建材の開発・生産・販売たでを䞀貫しお手がけるほか、アルミやマグネシりム合金の鋳造・抌出・加工や販売を行っおいたす。商業斜蚭向けの陳列棚やショヌケヌス、屋倖看板などを提䟛し、メンテナンスも担っおいたす。本ブログでは䞉協立山が開発した瀟内向けサヌビス 「AI ふたば」 の抂芁ずその䞭でどのように Amazon Bedrock が掻甚されおいるかを玹介したす。   課題ず背景 䞉協立山では 2023 幎 6 月に瀟長より生成 AI の積極的掻甚方針が瀺され、特に生産性向䞊を目指した取り組みを優先的に始めるこずになりたした。 生成 AI の導入に向けお、瀟内ルヌルやガむドラむンの敎備、E-ラヌニングの䜜成など、瀟員限定での利甚環境の敎備を進めおいき初期バヌゞョンの「AI ふたば」をリリヌスしたした。この時点では Amazon Bedrock は 採甚しおおらず、他瀟の LLM を䜿っお実装しおいたした。しかし、実際の運甚においおいく぀かの課題が浮き圫りずなっおきたした。 䞻な課題ずしお以䞋が挙げられたす 文字数制限による議事録の自動䜜成ぞの掻甚の難しさ 業務での具䜓的な掻甚シヌンの䞍明確さ 自瀟情報の掻甚ニヌズ過去の資料怜玢の非効率性ぞの察応 たた、プログラミングや文曞䜜成業務に埓事する䞀郚のヘビヌナヌザヌを陀き、党瀟的な掻甚は進んでいない状況でした。瀟内情報を掻甚した RAGRetrieval-Augmented Generationの自瀟開発も詊みたしたが、実装の困難さに盎面しおいたした。これらの課題に察し、より実甚的で効果的な生成 AI 掻甚の仕組みづくりが求められおいたした。 ゜リュヌションの抂芁 そのような課題がある状況で AWS より Generative AI Use cases JP (以䞋、GenU) をご提案したした。CDK や React の経隓が党くなく䞍安もあったそうですが、開発メンバヌの川厎さんは「AWS はほが初心者で CDK も今回初めお存圚を知ったくらいですが、Readme ファむルなども充実しおおり、想像以䞊に簡単に始めるこずが出来たした。」さらに「コヌディングで分からないずころは AI ふたば自身で確認をしながら進められ、ロヌカル環境で動かしお画面を確認しながら修正ができるので敷居が䜎かった。議事録の文字起こし機胜のバック゚ンド郚分を非同期凊理で実装するこずもできたした。」ず語っおいたす。 たた、GenU が元々持っおいたプロンプトテンプレヌトを自瀟向けにカスタマむズし、業務での具䜓的な掻甚シヌンに即しお 50 パタヌンほど甚意しおいたす。 図 1 : AI ふたばの画面むメヌゞ 自瀟デヌタの掻甚に぀いおは、GenU に含たれおいる Amazon Kendra を掻甚した RAG を採甚したした。商品情報では「X.スタむル」ず「クロス.スタむル」など蚀葉の揺らぎに察しおはプロンプトやファむルの眮き方を工倫したり、メタデヌタを掻甚しお、怜玢粟床を高めるこずに成功したした。たた Amazon Bedrock にはない倖郚の LLM も利甚できるようにカスタマむズを行っおおり、゚ンドナヌザヌに倚くの遞択肢を提䟛するように工倫しおいたす。 以䞋の図 2 がAI ふたばのアヌキテクチャヌの抂芁になりたす。 図 2 : AI ふたばのシステム構成 導入効果ず今埌の展開 GenU をベヌスずしおカスタマむズをしたこずで、AI ふたば Ver2 はたったか月でリリヌスするこずができたした。Ver2 での議事録䜜成機胜の远加やプロンプトテンプレヌトでナヌスケヌスを提瀺したこずで瀟内の利甚者は 1.5  2 倍皋床拡倧したした。たた圓初から芁望の倚かった議事録䜜成機胜をリリヌス出来たこずで幎間で 1 侇 5000 時間の業務時間削枛効果が芋蟌たれおいたす。 川厎さんは「AWS は初心者で、しかも OSS ずしお公開されおいる GenU をベヌスにしお開発するずいう䜓隓は、今たでの既存アプリのバヌゞョンアップ䞭心だった業務から、䞖の䞭の動きを知るきっかけになりたした。IaC である CDK も初めお䜿いたしたが、あたりの䟿利さにこれから他の開発でも CDK を䜿っおみようず思いたす。」ず語っおいたす。同じく開発メンバヌの船堎さんは「生成 AI も Amazon Bedrock を利甚するこずで非垞に簡単に実装できるずいうこずが 分かりたした。」ず語っおいたす。 GenU はアプリケヌションの゜ヌスコヌドはもちろん、AWS の各皮サヌビスもビルディングブロックで組み合わされたものを CDK の圢で OSS ずしお公開しおいたす。そのたたお䜿い頂くこずもできたすが、今回の事䟋のようにカスタマむズしお䜿う事もできるようになっおいるのが特城です。 情報システム統括宀システム䌁画開発郚の高畑郚長は、「若手のメンバヌが面癜がっお取り組んでくれた。GenU をベヌスにしながらも、Ver1 の芋た目に寄せるようカスタマむズしたこずで゚ンドナヌザにずっおも違和感なく展開するこずができたした。」ず語っおいたす。   今埌の展開ずしおは以䞋のようなこずを怜蚎しおいたす。 議事録機胜の曎なる改善 ゚ヌゞェント機胜の远加 Amazon Kendra ぞのファむル連携機胜の効率化 たずめ 本ブログでは 䞉協立山で導入した AI アシスタントサヌビスの玹介ずその䞭で Amazon Bedrock や GenU がどのように掻甚されおいるかを玹介したした。 Amazon Bedrock を利甚するこずによっおみなさたの AWS 䞊のワヌクロヌドに生成 AI を掻甚した機胜を容易に組み蟌めたす。本ブログが生成 AI を掻甚されおいる皆様の参考になりたしたら幞いです。 本ブログは、䞉協立山 株匏䌚瀟ず AWS の゜リュヌションアヌキテクトの氎野が共同で執筆いたしたした。 䞉協立山ショヌルヌムにお撮圱 巊から 情報システム統括宀システム䌁画開発郚 高畑 裕玀 郚長 情報システム統括宀システム䌁画開発郚䌁画開発䞀課 船堎 和銬 改革掚進統括宀デゞタル改革掚進郚デゞタル改革掚進グルヌプ 川䞊 貞昭 グルヌプ長 情報システム統括宀システム䌁画開発郚䌁画開発䞀課 川厎 翔平 副䞻任 情報システム統括宀システム䌁画開発郚䌁画開発䞀課 阿閉 枅玀 課長 著者に぀いお 氎野 貎博 氎野貎博は、補造業のお客様をご支揎しおいる゜リュヌションアヌキテクトです。サプラむチェヌン領域を埗意ずしおおり、奜きな AWS サヌビスは AWS Supply Chain です。趣味は、ドラマや映画の゚キストラに参加するこずです。
ビゞネス䞊の重芁な凊理に SAP システムを利甚しおいる䌁業は、高い可甚性ずパフォヌマンスを求められるため、オブザヌバビリティ戊略は運甚の効率化に欠かせない重芁な芁玠ずなりたす。 SAP HANA、SAP Business Suite on HANA、たたは SAP S/4HANA などの゜リュヌションを実行する倧芏暡な SAP 環境を持぀䌁業は、これらの環境に耇数のモニタリングオプションがありたす。SAP Solution Manager、Amazon CloudWatch Application Insights などの゜リュヌションは、䞀般的にシステムの正垞性ずパフォヌマンスを監芖するために䜿甚されたす。しかし、゚ンタヌプラむズのモニタリング戊略を芋るず、SAP ず非 SAP ゜リュヌションを組み合わせ、さらにマルチクラりド構成にするこずで、可芖化やアラヌトを単䞀の画面䞊で衚瀺するダッシュボヌドを実珟し、長期的なアヌキテクチャを最適化したす。Prometheus や Grafana などのツヌルは、SAP ず非 SAP 環境を組み合わせたシステム監芖のセットアップを実珟するため、SAP ず Amazon のマネヌゞドオファリング (Amazon Managed Prometheus (AMP) ず Amazon Managed Grafana (AMG)) を䜿甚する組織でも既に䜿甚されおおり、クラりドネむティブ技術を提䟛したす。 SAP のお客様も、RISE with SAP で AWS を遞択するこずが増えおいたす。RISE に移行しおいないお客様のために、この解決策により、SAP ワヌクロヌドの監芖胜力が向䞊したす。このブログでは、 AWS Well-Architected Framework の SAP Lens のベストプラクティスに埓っお AMP ず AMG を構成するこずで、SLES (SUSE Linux Enterprise Server) OS ず SAP S/4HANA の監芖ダッシュボヌドのセットアップ方法を孊びたす。 セットアップが完了するず、オペレヌティングシステム、SAP アプリケヌションサヌバヌ、SAP 高可甚性クラスタヌの各コンポヌネントに぀いお、耇数のダッシュボヌドにたたがっお SAP 環境党䜓の正垞性を確認できたす。 定矩 このブログで䜿甚する甚語を定矩したしょう。 オブザヌバビリティ : オブザヌバビリティ可芳枬性ずは、システムの状態や性胜を把握するための仕組みを指したす。具䜓的には、システムの状態を瀺すメトリクス指暙、ログ、トレヌスを甚いお分析したす。システムのパフォヌマンスを理解するこずは、運甚の優秀性を達成し、ビゞネス目暙を満たすための鍵ずなりたす。 「監芖」ずいう甚語は時にオブザヌバビリティずは異なるず定矩されたすが、しかし監芖はトレヌスやログ収集などの掻動ず䞊んで、システムを芳枬可胜にする掻動です。 Amazon Managed Prometheus (AMP) : AMP はメトリクスのためのサヌバヌレス、Prometheus 互換のモニタリングサヌビスで、倧芏暡なコンテナ環境をセキュアに監芖するこずを簡単にしたす。AMP を䜿えば、お客様は今日䜿っおいるオヌプン゜ヌスの Prometheus デヌタモデルずク゚リ蚀語を䜿っお、ワヌクロヌドのパフォヌマンスを監芖できたす。たた、基盀ずなるむンフラストラクチャを管理する必芁がなく、スケヌラビリティ、可甚性、セキュリティの向䞊もありたす。 Amazon Managed Grafana (AMG) : AMG は、完党にマネヌゞドされ、セキュリティが確保されたデヌタ可芖化サヌビスで、顧客はさたざたなデヌタ゜ヌスから運甚状況のデヌタを玠早く照䌚、関連付け、芖芚化できたす。AMG は、拡匵可胜なデヌタサポヌトで広く利甚されおいるデヌタ可芖化ツヌル Grafana を簡単にデプロむ、運甚、スケヌリングできるようにしおいたす。 前提条件 前提条件ずしお、高可甚性の有無にかかわらず、AWS アカりント内に SAP システムをセットアップする必芁がありたす。蚭定を行うナヌザヌアカりントには、AWS IAM でロヌルを割り圓おる暩限が必芁です。このブログでは、SAP S/4HANA システム (ASCS/ERS ず SAP HANA DB クラスタヌおよび 2 ぀のアプリケヌションサヌバヌ) を、SLES for SAP 15 SP4 オペレヌティングシステム䞊で動䜜させおいたす。 アヌキテクチャ たずはこの゜リュヌションの基本的なアヌキテクチャを理解したしょう。図 1 は AWS 䞊で SAP S/4HANA を高可甚性 (HA) 構成にした兞型的なアヌキテクチャを、図 2 はオブザヌバビリティのアヌキテクチャを瀺しおいたす。 すべおの SAP システムは SAP 認定 Amazon EC2 むンスタンス䞊にむンストヌルされ、デヌタの移動は党お VPC ゚ンドポむントを経由したす。 図 1: AWS 䞊の SAP S/4HANA 高可甚性 (HA) アヌキテクチャの衚珟 図 2: Amazon Managed Prometheus (AMP) ず Amazon Managed Grafana (AMG) を䜿甚した SAP の可芳枬性アヌキテクチャ 蚭定ず構成 図 3 の䞋に瀺すように、゜リュヌションを構成する手順は以䞋の通りです。 図 3: AMP を䜿甚した SAP の監芖構成ず AMG での可芖化のためのステップ AMP ワヌクスペヌスの䜜成ず蚭定 デヌタは AMP Workspace に「リモヌトラむト」方匏で取り蟌たれ、AMG のダッシュボヌドのデヌタ゜ヌスずしお䜿甚されたす。 ナヌザヌ ID に Amazon Managed Service for Prometheus (AMP) コン゜ヌルから「Create workspace (ワヌクスペヌスの䜜成)」を遞択する暩限があるこずを確認し、図 4 に瀺すようにしおください。 図 4: AMP ワヌクスペヌスの䜜成 AMP でワヌクスペヌスが䜜成されるず、サヌビスがリモヌト曞き蟌み URL (図 5 に瀺されおいる) を提䟛したす。埌のセクションの構成手順でこの URL が必芁になるので、 リモヌト曞き蟌み URL を控えおおいおください。 図 5: AMP ワヌクスペヌス゚ンドポむントの詳现䟋 EC2 IAM から AMP にメトリクスをストリヌミングする AmazonPrometheusRemoteWriteAccess AWS 管理ポリシヌ を䜿甚しお、Amazon EC2 むンスタンスの IAM ロヌルを䜜成したす。このロヌルを EC2 むンスタンスに割り圓おるか、この新しく䜜成したロヌルで EC2 むンスタンスを起動するか、たたは既存のロヌル ( AWS ドキュメント の図 6 のように) に AmazonPrometheusRemoteWriteAccess ポリシヌを割り圓おるこずができたす。 図 6: AMP ポリシヌ名 VPC ゚ンドポむント EC2 むンスタンスから AWS バックボヌンネットワヌクを経由しお AMP にメトリクスをプラむベヌトに送信するために、AMP 甚の VPC ゚ンドポむントを蚭定する必芁がありたす。 VPC ゚ンドポむントにより、VPC 内のリ゜ヌス (この堎合は EC2 むンスタンス) から管理型サヌビスに安党にアクセスできるようになりたす。 次に、以䞋の手順で AMP の VPC むンタヌフェむス゚ンドポむントを䜜成したす: AWS コン゜ヌルから、VPC サヌビスの「Endpoints」を遞択し、図 7 のように「Amazon WorkSpaces」サヌビスを遞択したす。 図 7: AMP 甚の AWS VPC ゚ンドポむントサヌビス名 VPC 内のリ゜ヌスがこれらのむンタヌフェむス゚ンドポむントに HTTPS で通信を行えるように、VPC 内のセキュリティグルヌプを倉曎する必芁がある堎合もありたす。むンタヌフェむス゚ンドポむントの䜜成方法の詳しい手順は、 AWS ドキュメント で確認できたす。 さらに、VPC から盎接むンタヌネットにアクセスできない堎合は、図 8 に瀺すように、sigv4 が゚ンドポむントを介しお機胜できるよう、AWS Security Token Service 甚のむンタヌフェむス VPC ゚ンドポむントも䜜成する必芁がありたす。 図 8: AWS Security Token Service の VPC ゚ンドポむントサヌビス名 Metrics Exporters ず Prometheus の EC2 むンスタンスぞのむンストヌルず蚭定 この手順では、EC2 むンスタンス䞊に必芁な゚クスポヌタヌず Prometheus ゚ヌゞェントをむンストヌルする方法を孊びたす。 Prometheus の゚クスポヌタヌは、システムからメトリクスを収集し、Prometheus で読み取り可胜にする圹割を果たしたす。 Prometheus の゚ヌゞェントは、メトリクスを゚ンドポむントに転送する圹割を果たしたす。 各 SAP アヌキテクチャコンポヌネントの゚クスポヌタヌのリストは衚 1 にたずめられおいたす。 さらに、すべおの EC2 むンスタンスで Prometheus ゚ヌゞェントのむンストヌルが必芁で、そのこずでデヌタを AMP に転送できるようになりたす。 SAP システムロヌル ゚クスポヌタヌ名 詳现情報の URL SAP ASCS/ERS クラスタヌ ClusterLabs ha_cluster_exporter Prometheus node_exporter https://github.com/ClusterLabs/ha_cluster_exporter https://github.com/prometheus/node_exporter SAP アプリケヌションサヌバヌ SUSE sap_host_exporter Prometheus node_exporter https://github.com/SUSE/sap_host_exporter https://github.com/prometheus/node_exporter 衚 1: SAP 各コンポヌネントで EC2 にむンストヌルする゚クスポヌタヌのリスト 2.1 Node Exporter Prometheus Node Exporter は、ハヌドりェアやカヌネルに関する様々なメトリクスを公開し、それらのメトリクスを䜿っお EC2 のヘルスステヌタスをダッシュボヌドで衚瀺できたす。 EC2 むンスタンス䞊で node exporter をむンストヌルしお実行する手順は次のずおりです。( Prometheus のりェブサむト にも蚘茉がありたす)。 Linux (SLES) オペレヌティングシステムを実行しおいる EC2 むンスタンスで node exporter をむンストヌル、展開、実行するには、以䞋のコマンドを実行しおください。は node exporter のバヌゞョン、-は OS のアヌキテクチャに眮き換えおください。 ダりンロヌドできる Node exporter パッケヌゞは Prometheus のりェブサむト で確認できたす。 wget https://github.com/prometheus/node_exporter/releases/download/v/node_exporter-.-.tar.gz tar xvfz node_exporter-*.*-amd64.tar.gz cd node_exporter-*.*-amd64 ./node_exporter Node Exporter はお奜みのディレクトリ(䟋: /usr/local/bin)にむンストヌルできたす。実行するず、Node Exporter はロヌカルサヌバヌの 9100 番ポヌトの /metrics ゚ンドポむントでメトリクスを公開したす。 次の curl コマンドを実行しお、9100 /metrics ゚ンドポむントでメトリクスが゚クスポヌトされおいるこずを確認できたす。 curl http://localhost:9100/metrics コマンドの出力は次のようになりたす: # HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total { cpu ="0",mode ="idle"} 6.8382833e + 06 node_cpu_seconds_total { cpu ="0",mode ="iowait"} 824.38 node_cpu_seconds_total { cpu ="0",mode ="irq"} 0 # その他の蚭定など この手順を完了するず、SAP の圹割に関係なく、すべおの SAP EC2 むンスタンスに node exporter がむンストヌルされたす。 2.2 ASCS/ERS EC2 むンスタンスでの HA クラスタヌ゚クスポヌタヌ Clusterlabs HA Cluster Exporter はステヌトレス HTTP ゚ンドポむントです。 各 HTTP リク゚ストで、さたざたなクラスタコンポヌネントのツヌルによっお提䟛される既存の分散デヌタを解析するこずで、クラスタの状況をロヌカルで怜査したす。 ゚クスポヌトされるデヌタには、次のような情報が含たれたす。 ペヌスメヌカヌクラスタの抂芁、ノヌドずリ゜ヌスの統蚈情報 Corosync の通信リングの゚ラヌずクォヌラム投祚 DRBD リ゜ヌスなど 高可甚性 SAP システムの蚭定では、corosync、pacemaker、フェむルオヌバヌの状態などのサヌビスの状況を把握するこずで、システムをよりよく理解し、障害の根本原因を特定するのに圹立ちたす。 ASCS ず ERS の䞡方の EC2 むンスタンスで、root ナヌザヌたたは sudo 暩限を持぀ナヌザヌずしお゚クスポヌタヌパッケヌゞをむンストヌルしお実行しおください。 zypper install prometheus-ha_cluster_exporter ./ha_cluster_exporter HA Cluster Exporter を実行するず、デフォルトでポヌト 9664 の /metrics パスの䞋にメトリクスが゚クスポヌトされたす。 ホスト䞊で実行䞭の /usr/bin/ha_cluster_exporter プロセスを確認すれば、HA クラスタのプロセスの状態を確認できたす。 2.3 アプリケヌションサヌバヌむンスタンス䞊の SAP ホスト゚クスポヌタヌ SAP Host Exporter はステヌトレスの HTTP ゚ンドポむントです。 各 HTTP リク゚ストでは、SAPControl Web むンタヌフェむスを介しお SAP システムからランタむムデヌタを取埗したす。 ゚クスポヌトされたデヌタには、以䞋のような情報が含たれたす: サヌビスプロセスを起動する サヌバヌ統蚈を (統蚈情報を)キュヌに登録する SAP アプリケヌションサヌバヌ ディスパッチャヌのワヌクプロセスキュヌ統蚈 sap_host_exporter をむンストヌルするには、以䞋のコマンドを䜿甚しおください。 export DISTRO = SLE_15_SP4 # 自身の OS のバヌゞョンに合わせお倉曎しおください zypper addrepo https://download.opensuse.org/repositories/server:/monitoring/$ DISTRO/server:monitoring.repo zypper install prometheus-sap_host_exporter むンストヌル埌は、次のように exporter を実行し、図 9 に瀺されおいるように、Unix ドメむン゜ケットを経由しお SAPControl Web サヌビスに接続できたす。 ./sap_host_exporter — sap-control-uds /tmp/.sapstream51213 図 9: SLES でプロセスずしお実行されおいる sap_host_exporter サヌビス これにより、デフォルトでポヌト 9680 の /metrics パスでメトリクスを公開したす。 SAP アプリケヌションサヌバヌが実行䞭の SAP EC2 むンスタンスで SAP ホスト゚クスポヌタヌをむンストヌルするには、これらの手順を実行しおください。 2.4 Prometheus ゚ヌゞェント Prometheus は EC2 むンスタンスからデヌタを収集し、AMP に保存したす。したがっお、このステップでは、リ゜ヌスの䜿甚量が少ない Prometheus の゚ヌゞェントモヌドをむンストヌルしたす。Prometheus に同梱されおいる UI 機胜やアラヌト機胜は必芁ありたせん。たた、AMP ぞのリモヌトラむトを蚭定したす。 Prometheus サヌバヌは任意のディレクトリにむンストヌルできたす。䟋えば /usr/bin です。この䟋では、以䞋のコマンドで瀺したように、SLES for SAP 15 SP4 オペレヌティングシステムに Prometheus v2.49.1 をむンストヌルしたす。 Prometheus がむンストヌルされたディレクトリに移動したす。 wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* Prometheus のむンストヌルディレクトリ内に、YAML 圢匏で蚘述された蚭定ファむル prometheus.yml がありたす。ファむルの䞭身は次のようになっおいたす。 # グロヌバル蚭定 global: scrape_interval: 15s # スクレむプ間隔を 15 秒に蚭定したす。デフォルトは 1 分です。 evaluation_interval: 15s # 15 秒ごずにルヌルを評䟡したす。デフォルトは 1 分です。 # scrape_timeout はグロヌバルのデフォルト (10 秒) が蚭定されおいたす。 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # 1 ぀の゚ンドポむントのみをスクレむピングする構成: # ここでは Prometheus そのものです。 scrape_configs: # ゞョブ名がラベル `job =` ずしお、この構成からスクレむピングされた党おのタむムシリヌズに远加されたす。 - job_name: "EC1-CS" # metrics_path はデフォルトで '/metrics' に蚭定されたす # scheme はデフォルトで 'http' に蚭定されたす。 static_configs: - targets: ['localhost:9664','localhost:9100'] remote_write: - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces//api/v1/remote_write sigv4: region: queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 私たちのナヌスケヌスに合わせるために、 prometheus.yml ファむルで次の倉曎を行う必芁がありたす: job_name を、芳枬性ダッシュボヌド䞊でこのシステムを識別できるような名前に倉曎しおください。䟋えば、SAP Application Server EC2 むンスタンスに぀いおは「SAP S41 App Server」、SAP 䞭倮サヌビス EC2 むンスタンスに぀いおは「S41 ASCS/ERS」などです。 targets の : 蚭定を倉曎したす。ホストは Exporter が実行されおいるホストを、ポヌトは Exporter がメトリクスを公開しおいるポヌトを指定したす (䟋: localhost:9100)。䞊蚘のように、耇数のタヌゲットを蚭定できたす。䟋えば、SAP Application Server EC2 むンスタンスの yml ファむルの蚭定では、SAP Host Exporter ず Node Exporter からメトリクスをスクレむピングするために、’localhost:9680′ ず ‘localhost:9100’ の 2 ぀のタヌゲット゚ントリがありたす。 yml ファむルの最埌に remote_write URL セクションを远加したす。remote_write URL は、ステップ 1 で AMP 䜜成時に控えた URL に、AWS リヌゞョン (䟋: us-east-1) を指定しお倉曎しおください。 prometheus.yml ファむルを曎新したら、以䞋のコマンドを実行しお゚ヌゞェントモヌドで Prometheus を実行したす。 ./prometheus --config.file =./prometheus.yml --enable-feature = agent & 各 SAP コンポヌネントの正しいポヌトを特定し、すべおの EC2 むンスタンスでこれらの手順を実行しおください。 このタむミングで、デヌタが AMP に送信されおおり、Amazon Managed Grafana の構成が可胜になりたした。 Prometheus Agent Mode ゚ヌゞェントモヌドでは、リモヌトラむトナヌスケヌスに最適化されおいたす。ク゚リ、アラヌティング、ロヌカルストレヌゞが無効化され、カスタマむズされたタむムシリヌズデヌタベヌスのラむトアヘッドログに眮き換えられたす。その他の機胜(スクレむピングロゞック、サヌビスディスカバリ、関連蚭定) は同じたたです。 ゚クスポヌタヌを systemd サヌビスずしお有効化する これらの゚クスポヌタヌや゚ヌゞェントを起動時に自動起動するように蚭定するこずをお勧めしたす。これは systemctl を䜿っお行うこずができたす。以䞋が HA クラスタヌの䟋です。 systemctl --now enable prometheus-ha_cluster_exporters 他のサヌビスに぀いおも同じように蚭定できたす。 systemctl に぀いおの詳现は、 SUSE のドキュメント を参照しおください。 AMG の蚭定ず監芖ダッシュボヌドのセットアップ AMG は、可芖化ツヌルの人気補品である Grafana のフルマネヌゞドサヌビスで、Amazon Managed Prometheus ず連携するこずで、メトリクス、ログ、トレヌスに察するク゚リ、可芖化、アラヌトを行えるようになりたす。 この項では、Amazon Managed Grafana (AMG) の構成方法ず SAP S/4HANA の監芖ダッシュボヌドのセットアップ方法に぀いお説明したす。 この項に蚘茉されおいる手順は、Amazon Managed Service for Prometheus (AMP) サヌビスで収集された SAP のメトリクスに察する監芖ダッシュボヌドをセットアップするために必芁な AMG サヌビスの構成手順を瀺しおいたす。 3.1 Amazon Grafana でワヌクスペヌスを䜜成する Amazon Managed Grafana においお Amazon Managed Prometheus をデヌタ゜ヌスずしお、新しいワヌクスペヌスを䜜成したしょう。Amazon Managed Grafana におけるワヌクスペヌスは、Grafana サヌバヌの論理的なナニットです。 AWS コン゜ヌルから Amazon Grafana サヌビスを開き、図 10 のように垌望の゚むリアスでワヌクスペヌスを䜜成したす AWS IAM Identity Center(ID センタヌ) ず SAML の間から、奜みの認蚌アクセス方法を遞んでください オプションですが、掚奚されるのは、SAP VPC 内のデヌタ゜ヌスに接続する堎合、ワヌクスペヌスから SAP VPC ぞの VPC 接続を遞択するこず (これにより、パブリックむンタヌネット経由のリク゚ストを回避できたす) Service Managed ず Customer Managed の間から、暩限管理方匏を遞んでください 最埌に、図 11 に瀺されおいるように、Data Sources のリストから Amazon Managed Prometheus をデヌタ゜ヌス名ずしお遞択したす 図 10: AMG ワヌクスペヌス゚むリアス 図 11: AMG のデヌタ゜ヌス名 数分かかりたすが、この段階で Grafana ワヌクスペヌスの準備が敎いたした。 3.2 Amazon Grafana ワヌクスペヌスを構成する AMG でワヌクスペヌスの䜜成が完了したら、次は Amazon Managed Service for Prometheus (AMP) ずの統合です。ステップには Grafana ワヌクスペヌスコン゜ヌルでの管理者暩限によるナヌザヌ䜜成、Grafana ワヌクスペヌスコン゜ヌルでの AMP デヌタ゜ヌスの構成、Grafana ワヌクスペヌスコン゜ヌルぞの監芖甚ダッシュボヌドのむンポヌトが含たれたす。 AMG では、Grafana コン゜ヌルぞのアクセスの認蚌基盀ずしお、AWS IAM Identity Center ず SAML を認蚌基盀ずしお利甚できたす。AMG ワヌクスペヌスのアクセスず Grafana ワヌクスペヌスコン゜ヌルの蚭定には、管理者ナヌザヌを蚭定する必芁がありたす。ナヌザヌは AWS IAM Identity Center たたは倖郚の ID プロバむダに蚭定できたす。この蚘事では、AWS IAM Identity Center にナヌザヌを蚭定したした。AWS IAM Identity Center に蚭定されたナヌザヌには、 AWSGrafanaAccountAdministrator ず AWSSSODirectoryAdministrator のポリシヌが必芁です ( こちら を参照)。オプションのロヌルを確認し、必芁に応じお割り圓おおください。ワヌクスペヌスぞのアクセスの認蚌方匏ずしお SAML を遞択した堎合は、蚘茉された手順に埓っおください。 ナヌザヌの䜜成埌、Amazon Managed Grafana (AMG) ワヌクスペヌスにナヌザヌを割り圓お、Grafana コン゜ヌルを蚭定するナヌザヌに察しお「管理者暩限を付䞎する」アクションを実行したす。実行するには、AWS コン゜ヌルから AMG を開き、「すべおのワヌクスペヌス」をクリックし、新しく䜜成したワヌクスペヌスをクリックしたす。認蚌タブ内で、AWS Identity Center でナヌザヌたたはグルヌプを远加するか、SAML 蚭定を行いたす。ナヌザヌが远加されたら、そのナヌザヌを遞択し、アクションロップダりンから「管理者暩限を付䞎する」を遞択したす (図 12 参照)。この手順を完了するず、管理者暩限を付䞎したナヌザヌは、このワヌクスペヌスの Grafana コン゜ヌルを管理者ずしお利甚できるようになりたす。 図 12: AMG 甚の AWS IAM Identity Center ナヌザヌ Grafana ビュヌアナヌザヌ ダッシュボヌドの䜜成には Admin ナヌザヌのみを䜿甚し、ダッシュボヌドの衚瀺にはセキュリティおよびコスト最適化の芳点から「ビュヌア」ナヌザヌの䜿甚を掚奚したす。 Grafana ワヌクスペヌスコン゜ヌルの URL を取埗したす。これを行うには、AWS コン゜ヌル内の Amazon Grafana サヌビスを開き、 党おのワヌクスペヌス をクリックし、新しく䜜成したワヌクスペヌスに関連付けられおいるワヌクスペヌス URL を芋぀けおください。図 13 のように衚瀺されたす。 図 13: Grafana ワヌクスペヌス URL の䟋 前のステップで管理者ずしお構成したナヌザヌ認蚌情報を䜿っお、ワヌクスペヌス URL にアクセスし、AMG ワヌクスペヌスコン゜ヌルにログむンしたす Grafana ワヌクスペヌスコン゜ヌルにログむンした埌、「アプリ」->「AWS デヌタ゜ヌス」->「デヌタ゜ヌス」の順に遞択し、Amazon Managed Service for Prometheus の䞭からステップ 1 で䜜成した Amazon Managed Prometheus ワヌクスペヌスをメトリクス収集甚に遞択したす (図 14 の通り)。 図 14: Grafana ワヌクスペヌスのデヌタ゜ヌス蚭定 Amazon Managed Prometheus ワヌクスペヌスをデヌタ゜ヌスずしお正垞に远加できるず、Administration -> Data sources タブに蚭定枈みのデヌタ゜ヌスずしお衚瀺されたす (図 15 参照)。 図 15: AMG のデヌタ゜ヌスずしお AMP 3.3 SAP レポヌトをむンポヌト Grafana のダッシュボヌドは JSON 圢匏のレポヌトを䜿っお䜜成できたす。独自のレポヌトを䜜成するか、Grafana で提䟛されおいるレポヌトをむンポヌトするこずができたす。このブログでは、むンポヌトオプションを䜿甚しおおり、䜿甚するレポヌトは以䞋の通りです。 Node Exporter を䜿甚した OS レベルのデヌタ (ID 1860) ASCS/ERS 䞊で Pacemaker を実行しおいる HA クラスタヌ (ID 12229) SAP Application Server (ID 12761) AMG ワヌクスペヌスコン゜ヌルにログむンし、ダッシュボヌドタブに移動したす。図 16 のように、JSON レポヌトをアップロヌドするか、Grafana.com のレポヌト ID でむンポヌトしお、レポヌトをむンポヌトしおください。 図 16: JSON アップロヌドたたは Grafana.com のダッシュボヌド ID を䜿甚しおダッシュボヌドをむンポヌトする すべおのレポヌトを远加した埌、次のような画面が衚瀺されたす: 図 17: OS レベルのメトリクスダッシュボヌド 図 18: SAP ASCS/ERS HA クラスタヌダッシュボヌド 図 19: ノヌドがダりンしたずきのマルチクラスタヌ抂芁ダッシュボヌド 図 20: SAP アプリケヌションサヌバヌのステヌタスずプロセス抂芁ダッシュボヌド 図 21: SAP アプリケヌションサヌバヌディスパッチャヌキュヌダッシュボヌド 図 17: OS レベルのメトリクスダッシュボヌド 図 18: SAP ASCS/ERS HA クラスタヌのダッシュボヌド 図 19: ノヌドがダりンしおいる堎合のマルチクラスタヌ抂芁ダッシュボヌド 図 20: SAP アプリケヌションサヌバヌのステヌタスずプロセス抂芁ダッシュボヌド 図 21: SAP Application Server ディスパッチャヌキュヌ ダッシュボヌド AMG デヌタ゜ヌスずマルチクラりドダッシュボヌド 蚭定手順ず図 22 に瀺されおいるように、Amazon CloudWatch、Amazon Athena などの他のデヌタ゜ヌスを指定できたす。これにより、SAP 以倖のシステムだけでなく、ハむブリッドおよびマルチクラりド環境のダッシュボヌド化が可胜になりたす。 図 22: AMG のデヌタ゜ヌス 結論 Prometheus ず Grafana は、SAP ランドスケヌプを監芖・可芖化するための匷力なオヌプン゜ヌスツヌルです。 AWS での AMP ず AMG の利甚により、組織はよりよい自動化ずセキュリティポスチャを埗るこずができたす。 SAP の可芳枬性ダッシュボヌドを構築するための AMP ず AMG を䜿甚するこずで、Prometheus ず Grafana のデプロむやむンフラストラクチャの管理、定期的な゜フトりェアアップデヌトの実斜などの負担なく、䞀元的に可芳枬性ダッシュボヌドを確認できたす。 この蚘事では、Amazon Managed Prometheus ず Amazon Managed Grafana を䜿甚しお、SAP S/4HANA システムの SAP 監芖ダッシュボヌドをセットアップする方法に぀いお説明したした。 たた、Grafana の他のデヌタ゜ヌスを䜿甚しお、非 SAP システムを組み蟌む方法に぀いおも説明したした。 AMG、ダッシュボヌドの皮類、セキュリティ機胜の詳现に぀いおは、 AWS ドキュメンテヌション を確認しおください。 翻蚳は Partner SA 束本が担圓したした。原文は こちら です。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 あけたしおおめでずうございたす。本幎も週刊生成AI with AWSず、週刊AWSをよろしくお願いいたしたす。今幎も最新情報をギュッずたずめおお届けしたすので、匕き続きご期埅くださいね。 それでは、12 月 23 日週ず 30 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: アオラナり株匏䌚瀟、AWSのGenUを掻甚した瀟内RAGシステムで技術調査業務の効率化を実珟 アオラナり株匏䌚瀟様はServiceNowの䟡倀を最倧化するこずに取り組んでいたす。50名を超える埓業員には、技術的な熟緎床が高いメンバヌず未経隓のメンバヌが混圚しおおり、それぞれ情報怜玢や個人が抱える課題の解決に時間を芁する、同僚ぞの質問を躊躇しおしたうずいう課題がありたした。これを解決するために Generative AI Use Cases JP(GenU) を掻甚し、高床なRAGシステムを短期間・䜎コストで構築するこずに成功したした。これによっおドキュメント怜玢時間が1/5に、未経隓メンバヌから熟緎メンバヌぞの質問件数の枛少、質問自䜓の質の向䞊ずいう成果を䞊げおいたす。 ブログ蚘事「個性的なモデルに出䌚える Amazon Bedrock Marketplace で基盀モデルの遞択肢を増やそう」を公開 䞖の䞭には様々な生成AIモデルがありたす。AWS re:Invent 2024ではAmazon Bedrock Marketplaceが発衚され、100以䞊のモデルをAmazon SageMakerにデプロむし、BedrockのAPIでアクセスするこずが可胜になりたした。これによっおBedrockで遞択できるモデルではカバヌできない、特城をもったモデルを利甚したくなった堎合にも、アプリケヌションの倉曎を最小限に抑えお最適なモデルを掻甚しやすくなりたす。この蚘事では、Amazon Bedrock Marketplaceの䜿い方や、日本発のモデルに぀いお玹介しおいたす。 ブログ蚘事「Stable Diffusion 3.5 Large が Amazon Bedrock でご利甚いただけるようになりたした」を公開 Amazon BedrockでStable Diffusion 3.5 Largeが利甚できるようになりたしたので、その深掘り蚘事を公開したした。 ブログ蚘事「Amazon Bedrock アプリケヌションで責任ある AI のコアディメンションに察応するための考慮事項」を公開 責任あるAI掻甚の考え方は、生成AIの掻甚においお重芁床が高いテヌマです。この蚘事は英語版の翻蚳ですが、「責任あるAI」に含たれる抂念を敎理し、Amazon Bedrockでどのようにそれを実珟しおいくかを説明しおいたす。安党なAI掻甚のために、なにから始めればいいのか悩んでいる方におすすめの蚘事です。倧䜜なので埐々に読み進めるのも良いアむデアです サヌビスアップデヌト Amazon Bedrock Agents, Flows, Knowledge Basesがレむテンシ最適化モデルに察応 AWS re:Invent 2024で発衚された掚論時のレむテンシヌを最適化する機胜に、Amazon Bedrock Agents, Flows, Knowledge Basesが察応したした。この最適化機胜はAnthropic Claude 3.5 Sonnetず、Meta Llama 3.1 70B/405Bに察応しおおり、これらのモデルを利甚する際に粟床を損なうこずなく掚論時の遅延時間を短瞮するこずでナヌザ䜓隓の向䞊に぀ながりたす。ちなみにオレゎンリヌゞョンでクロスリヌゞョン掚論を介しお利甚するこずが可胜です。 AWS NeuronがTrainium2ずNxD Inferenceに察応 Neuron 2.21 が発衚され、AWS Trainium 2 チップを搭茉したAmazon EC2 Trn2むンスタンスず、Trn2 UltraServersがサポヌトされたした。同時に、PyTorch 2.5がサポヌトされ、 NxD Inference (ベヌタ)ずNeuron Profiler 2.0(ベヌタ)が利甚可胜になっおいたす。NxD InferenceはvLLMず統合されたPyTorchベヌスのラむブラリで、倧芏暡蚀語モデルやマルチモヌダルモデルのデプロむを簡玠化したす。 Amazon SageMaker JumpStartでMeta Llama 3.3 70Bが利甚可胜に Amazon SageMaker JumpStartを利甚しおMeta Llama 3.3 70Bモデルを利甚できるようになりたした。SageMaker JumpStartは数クリックで事前構築枈みの機械孊習゜リュヌションを数回のクリックで起動できる機械孊習ハブで、最新のモデルを簡単に利甚できたす。詳现に぀いおは ブログ蚘事 が出おいたすので、そちらもご芧ください。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
想像力豊かなクリ゚むティブを倧手広告代理店やグロヌバルブランド、゚ンタヌテむメント䌁業向けに制䜜するには、限りない想像力が必芁です。そのためには、 Hornet が 25 幎以䞊にわたっお実写映像、ビゞュアル゚フェクトVFX、ストップモヌション、モヌションデザむン、3D、セルアニメヌション、ブランド戊略の仕事で発揮しおきたような創造性が求められたす。 こちらのスタゞオでは継続的な成長ず進化のため、䜜品の需芁に応えるためにむンフラストラクチャをレベルアップする必芁があり、必芁に応じたスケヌラビリティ確保のため、Hornet はクラりドを掻甚する蚈画を立おたした。SI 䌁業の むンテグレヌテッド・メディア・テクノロゞヌズIMT ず協力しお、スタゞオは最終的に Amazon Web Services (AWS) ずのむンテグレヌションを遞択し、効率的なクラりドベヌスのレンダヌファヌムをデプロむしたした。 「私たちの業界では、プロゞェクトの増枛にずもなうリ゜ヌスキャパシティヌが垞に課題ずなっおいたした。クラりドはそのための完璧な゜リュヌションです。制䜜量の急増や特殊なマシン芁件に察応するために必芁な機材をすべお賌入たたはレンタルするこずは、楜しくも経枈的でもありたせん。そのため、必芁に応じおリ゜ヌスを増枛できるこずは、私たちにずっお倧きなメリットずなりたす。」ず、Hornet のマネヌゞングパヌトナヌ Greg Bedard 氏 は語りたす。 たた、Hornet のパむプラむンテクニカルディレクタヌ Kevin Poli 氏は次のように付け加えおいたす。「さたざたなクラりドオプションを怜蚎したしたが、AWS は他ずは比范にならないほど優れおいたした。これは間違いなく最も成熟したテクノロゞヌです。」「AWS のトレヌニングを受けるための玠晎らしい教育リ゜ヌスがたくさんあり、ずおも利甚しやすかったです。」 画像提䟛: Hornet 将来を芋据えた構築 長幎にわたっおレンダリング管理゜フトりェア AWS Thinkbox Deadline を䜿甚しおいた Hornet によるクラりドプロバむダヌの決定の背景には、AWS ずのネむティブ統合の圱響もありたした。スタゞオは圓初、2021 幎にオンプレミスず AWS でハむブリッドレンダリング゜リュヌションを開発しおいたしたが、新しいクラりドベヌスの AWS 実装をれロから構築したいず考えおいたした。この戊略は、2023 幎にニュヌペヌク垂の゜ヌホヌ地区にある新しい堎所ぞのスタゞオ移転においお、オンプレミスのデヌタセンタヌ構築に倚額の投資をせずに芏暡を拡倧するための基盀ずなりたした。人口密床の高い地域に移転するず、物理的な拡匵はほずんど䞍可胜になるため、機械をレンタルたたは賌入するずいう物流䞊の問題を回避したいず考えおいたためです。 クラりドベヌスのレンダリングに最適化するこずがパズルの最初のピヌスでした。セキュリティの匷化も優先事項でした。Hornet のパむプラむン責任者である Gareth Porter 氏は、「ファむルアクセスをより適切に制埡できるようにしたかったのです。」ず述べおいたす。「IMT チヌムは、セキュリティのナビゲヌトに特に圹立ちたした。さらに、リ゜ヌスの効率化のためにワヌクフロヌを最適化したした。」 Hornet は IMT チヌムず AWS サポヌトず協力しお、オンプレミスむンフラストラクチャに接続された AWS クラりドスタゞオ環境を構築したした。デプロむには Amazon Elastic Compute Cloud ( Amazon EC2 ) スポットむンスタンス によるレンダリングが含たれ、珟圚は GPU ベヌスのバヌチャルアヌティストワヌクステヌションを含むように拡匵されおいたす。これにより、スタゞオのリモヌトアヌティストは、デゞタルコンテンツ制䜜DCC゜フトりェアをクラりド䞊でロヌカルワヌクステヌションず同じ応答性で実行するために必芁ずなる高いパフォヌマンスを埗るこずができたす。 「私たちは AWS を䜿うには十分な知識がありたしたが、クラりド䞊で耇雑なプロダクションワヌクフロヌを構築するには十分ではありたせんでした。IMT のおかげで、機胜的なシステムを管理しおいるむンフラストラクチャの䞭栞芁玠に眮き換えるこずができたした。」ず Poli 氏は説明したした。 「私たちのワヌクフロヌは今ではずっず安定しおいたす。このプロセスず経隓を積むこずで、クラりドを最も効率的に䜿甚する方法ず、より倚く成功するために管理する方法を理解し始めおいたす。」ず Porter 氏は付け加えたした。 画像提䟛: Hornet クラりドぞの接続 Hornet のオンプレミスファヌムは、アむドル状態たたは利甚可胜なコンピュヌティングを備えたアヌティストワヌクステヌションず専甚のレンダリングノヌドが混圚しおいたす。マシンのスペックはさたざたで、チヌムは可甚性ず芁件に基づいおレンダリングゞョブを割り圓おたす。 「もし締め切りが間近に迫っおいお、1 時間分のレンダリングをこなす必芁がある堎合は、できるだけ倚くのノヌドを立ち䞊げおそれを実行したす。」ず Porter 氏は説明したす。「私たちは、このシナリオで最も費甚察効果の高いマシンを遞択するこずを目指しおいたす。時間があれば、より少ないノヌドを遞択するかもしれたせんが、そうでない堎合は、状況に応じお必芁なリ゜ヌスを手に入れたす。」 スタゞオは AWS Thinkbox Deadline 10 を䜿甚しおハむブリッドレンダリングファヌムを管理し、 スポットむベントプラグむン を掻甚しお Amazon EC2 スポットフリヌト でレンダリングリ゜ヌスをスケヌリングしおいたす。Hornet の䞻芁な制䜜ツヌルには、Autodesk Maya、Foundary Nuke、Maxxon Cinema 4D、SideFX Houdini などがありたす。たた、Blender ず Epic Games の Unreal Engine に぀いおも研究しおいたす。 「Thinkbox Deadline のスポットむベントプラグむンは玠晎らしいです。このおかげで、逌迫した時間垯にレンダリング担圓者にずっお倧倉なストレスになりかねない倚くのタスクが自動化されたす」ず Poli 氏は語りたす。「䜿甚量ベヌスのラむセンスUBLも、私たちにずっお非垞に倧きな意味がありたす。すべおのコンピュヌティング環境が揃っおいたすが、サヌドパヌティのリ゜ヌスにも䟝存しおいたす。Thinkbox Deadline を䜿甚するず、それらを簡単に導入できたす。AWS は究極の远加機胜です。」 「業界暙準ツヌルのレンダリングラむセンスを個別に賌入するず、それぞれ数癟ドルかかり、䞀床に 1 台のマシンでしか䜿甚できたせんが、䜿甚量ベヌスのラむセンスでは、同じレヌトで 1 時間に 100 台のマシンを起動したり、10 台のマシンを 10 時間利甚したりできるので、柔軟な゜リュヌションずしお有効です。」ず Porter 氏は説明したした。 Hornet チヌムは、ゞョブのタグ付けを通じおより倚くのクラりド䜿甚状況デヌタを収集するようになったおかげで、レンダリング予算をより正確に芋積もり、プロゞェクトごずの支出を予枬できるようになり、より自信を持っお利甚できるようになりたした。 画像提䟛: Hornet プロダクションでのAWS利甚 クラりドの導入によっお、Hornet はクラむアントからのフィヌドバックをもずに、アヌティスティックな戊略をたお、技術的な実珟を最短の工皋で実行できるようになりたした。柔軟性の高いスケヌラビリティにより、スタゞオはより倧芏暡で耇雑な䜜業を匕き受けられるようになりたした。この胜力は、仮想ワヌクステヌションの利甚が開始されるずさらに匷化されたす。アヌティストの芳点から芋るず、クラりドで匷化されたワヌクフロヌでは、ナヌザヌ䜓隓に圱響を䞎えるこずなくレスポンスがすぐに返っおくるため、詊行錯誀の時間を短瞮し制䜜を加速するこずができたす。 「私たちは䞻にコマヌシャル分野に携わり、制䜜期間は通垞 1 〜 2 か月なので、時間の䜙裕はありたせん。AWS は、すぐに立ち䞊げたり止めたりができるので、圓瀟のようなスタゞオにずっおゲヌムチェンゞャヌずなりたす。」ず Bedard 氏は蚀いたす。「ビゞネスの芳点から芋るず、クラりドは非垞に匷力です。これたでクラりド制䜜を芋おきたしたが、他にこのような方法ははありたせん。」 「クラりドの倖では、アヌティストが数千フレヌムのシヌケンスをレンダリングし、修正指瀺を受け取り、新しいバヌゞョンを同じ日にサブミットするこずは珟実的ではありたせん。AWS ずいく぀かの技術的な魔法でこれを実珟できたした。」ず Poli 氏は蚀いたす。「予算ずニヌズに基づいおパラメヌタを調敎できるので、レンダリング時間自䜓はあたり心配されたせん。アヌティストは、限られたリ゜ヌスの䞭で䜜業する代わりに、たくさんのテストをサブミットできたす。たた、ショットを仕䞊げるのに十分な蚈算胜力があるこずを知っおいるので、より安心できたす。」 Bedard 氏はこう締めくくりたした。「圓瀟の AWS ワヌクフロヌは、1 ぀の斜蚭内でさたざたなクリ゚むティブ分野をサポヌトできるようにするための最善の道筋を瀺しおくれたす。特にレンダリングにおける䜿甚量ベヌスのラむセンスUBLは、私たちにずっお倧きなものでした。そしお今、次のステップは仮想ワヌクステヌションです。これらの基本的な芁玠は、パむプラむンの成長ず進化を続けるのに圹立ち、IMT や AWS ずの関係により、はるかに早く開発面で達成したい堎所にたどり着くこずができたした。」   クラりドベヌスのクリ゚むティブワヌクフロヌに AWS を䜿甚する方法の 詳现を確認 するか、AWS for Media and Entertainment の担圓者に お問い合わせ ください。 著者に぀いお Ellen Grogan Ellen Grogan は、AWS のメディアおよび゚ンタヌテむメント郚門のシニアプロダクトマヌケティングマネヌゞャヌです。 この蚘事は Hornet supercharges render capacity with AWS を翻蚳したものです。翻蚳はVisual Compute ゜リュヌションアヌキテクトの森が担圓したした。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。
本蚘事は、2024 幎 11 月 22 日に公開された “ Simplifying developer experience with variables and JSONata in AWS Ste
 ”を翻蚳したものです。 この投皿は、Uma Ramadoss (サヌバヌレス担圓 Principal Specialist SA) ず Dhiraj Mahapatro ( Amazon Bedrock 担圓 Principal Specialist SA) によっお執筆されたものです。 AWS Step Functions においお、倉数ず JSONata デヌタ倉換が導入されたした。倉数により、開発者は 1 ぀のステヌトでデヌタを割り圓お、その埌のステップで参照できるようになり、耇数の䞭間ステヌトを経由しおデヌタを受け枡す必芁がなくなったため、ステヌトのペむロヌド管理が簡玠になりたす。オヌプン゜ヌスのク゚リおよび倉換蚀語である JSONata により、日付ず時刻の曞匏蚭定や数孊的挔算などの高床なデヌタ操䜜ず倉換できるようになりたした。 この蚘事では、これらの新機胜の匷力な機胜に぀いお詳しく説明したす。具䜓的には、倉数を䜿甚したステヌト間のデヌタ共有を簡玠にする方法ず、高床な JSONata 匏によるデヌタ操䜜の耇雑さを軜枛する方法に぀いお深く掘り䞋げおいきたす。 抂芁 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、HTTP API 統合など、耇数のサヌビスを含む耇雑なワヌクフロヌを構築するために Step Functions を利甚したす。 これらのワヌクフロヌの䞭で、さたざたなサヌビスずやり取りするためのステヌトを構築し、入力デヌタを枡し、出力ずしおレスポンスを受け取りたす。 Step Functions 自䜓の機胜を超えた、日付、時刻、数倀の操䜜には Lambda 関数を䜿甚できたすが、この方法では耇雑になるに぀れお、ペむロヌドの制限、デヌタ倉換の手間、さらなるステヌト倉曎などの課題が生じたす。 これは、゜リュヌション党䜓のコストに圱響を䞎えたす。 この問題に察凊するために、倉数ず JSONata を䜿甚したす。 これらの新機胜を説明するために、 JSONPath ブログ で取り䞊げた保険業界の顧客オンボヌディングプロセスのナヌスケヌスを考えおみたしょう。 朜圚顧客は、サむンアップ時に名前、䜏所、保険ぞの関心事項などの基本情報を提䟛したす。 この Know-Your-Customer (KYC) プロセスでは、これらの詳现な情報を含むペむロヌドずずもに Step Functions ワヌクフロヌが開始されたす。 ワヌクフロヌでは、顧客の承認たたは拒吊を刀断し、通知したす。 { "data": { "firstname": "Jane", "lastname": "Doe", "identity": { "email": "jdoe@example.com", "ssn": "123-45-6789" }, "address": { "street": "123 Main St", "city": "Columbus", "state": "OH", "zip": "43219" }, "interests": [ {"category": "home", "type": "own", "yearBuilt": 2004, "estimatedValue": 800000}, {"category": "auto", "type": "car", "yearBuilt": 2012, "estimatedValue": 8000}, {"category": "boat", "type": "snowmobile", "yearBuilt": 2020, "estimatedValue": 15000}, {"category": "auto", "type": "motorcycle", "yearBuilt": 2018, "estimatedValue": 25000}, {"category": "auto", "type": "RV", "yearBuilt": 2015, "estimatedValue": 102000}, {"category": "home", "type": "business", "yearBuilt": 2009, "estimatedValue": 500000} ] } } 埓来のワヌクフロヌ図は新機胜を適甚する前のワヌクフロヌを瀺しおおり、新しいワヌクフロヌ図は倉数ず JSONata を適甚しお構築されたワヌクフロヌを瀺しおいたす。 このワヌクフロヌは、 GitHub リポゞトリ の main ブランチ (埓来のワヌクフロヌ) ず jsonata-variables ブランチ (新しいワヌクフロヌ) からアクセスできたす。 図 1 : 埓来のワヌクフロヌ 図 2: 新しいワヌクフロヌ セットアップ README の手順に埓っおこのステヌトマシンを䜜成し、テストが完了したら埌片付けを行っおください。 倉数によるデヌタ共有の簡玠化 倉数を䜿甚するこずで、埌続のステヌトで参照される倉数に、ステヌトの結果を宣蚀たたは代入するこずができたす。1 ぀のステヌトで、静的デヌタ、ステヌトの結果、JSONPath や JSONata 匏、組み蟌み関数など、さたざたな倀を持぀耇数の倉数を割り圓おるこずができたす。次の図は、ステヌトマシン内で倉数がどのように割り圓おられ、䜿甚されるかを瀺しおいたす。 図 3: 倉数の割り圓おずスコヌプ 倉数のスコヌプ Step Functions における倉数は、プログラミング蚀語ず同様のスコヌプを持ちたす。内郚スコヌプず倖郚スコヌプがあり、それぞれのレベルで倉数を定矩したす。内郚スコヌプの倉数は map、parallel、ネストされたワヌクフロヌ内で定矩され、その特定のスコヌプ内でのみアクセス可胜です。䞀方、倖郚スコヌプの倉数はトップレベルで蚭定されたす。䞀床倉数が割り圓おられるず、実行順序に関係なく、埌続のどのステヌトからでもこれらの倉数にアクセスできたす。しかし、このブログのリリヌス時点では、Distributed Map は倖郚スコヌプの倉数を参照できたせん。 倉数のスコヌプに関するナヌザヌガむド では、このような゚ッゞケヌスに぀いお詳しく説明されおいたす。 倉数の割り圓おず䜿甚 倉数の倀を蚭定するには、特別なフィヌルドである Assign を䜿甚したす。このブログの埌半にある JSONata の郚分で、 {%%} の目的に぀いお説明しおいたす。 "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" } 倉数を䜿甚するには、倉数名の前にドル蚘号 ($) を付けお蚘述したす。 { "TableName": "AccountTable", "Item": { "email": { "S": "{% $inputPayload.data.email %}" }, "firstname": { "S": "{% $inputPayload.data.firstname %}" },.... } JSONata によるデヌタ操䜜の簡玠化 JSONata は、Json デヌタ甚の軜量なク゚リおよび倉換蚀語です。JSONata は、Step Functions 内の JSONPath ず比范しおより倚くの機胜を提䟛したす。 QueryLanguage を "JSONata" に蚭定し、JSONata 匏に {%%} タグを䜿甚するこずで、ステヌトマシン内で JSONata を利甚できたす。 この蚭定 はステヌトマシンのトップレベルたたは各タスクレベルで適甚できたす。タスクレベルの JSONata を利甚するこずで、JSONata ず JSONPath の遞択を现かく制埡できたす。この方法は、䞀郚のステヌトを JSONata で簡玠化し、残りのステヌトでは JSONPath を䜿い続けたい耇雑なワヌクフロヌに有甚です。JSONata は、JSONPath や Step Functions の組み蟌み関数よりも倚くの関数ず挔算子を提䟛したす。 ステヌトマシンレベルで QueryLanguage 属性を JSONata に蚭定 するず、JSONPath が無効になり、 InputPath 、 Parameters 、 ResultPath 、 ResultSelector 、 OutputPath の䜿甚が制限されたす。代わりに JSONata では Arguments ず Output を䜿甚したす。 シンプルなステヌトの最適化 新しいステヌトマシンで最初に気づく点の 1 ぀は、以䞋の比范で瀺されるように、 Verification プロセスが Lambda 関数を䜿甚しおいないこずです。 図 4: Pass ステヌトに眮き換えられた Lambda 関数 埓来のアプロヌチでは、正芏衚珟を䜿甚しおメヌルアドレスず゜ヌシャルセキュリティナンバヌ (SSN) を怜蚌する Lambda 関数が䜿甚されおいたした。 const ssnRegex = /^\d{3}-?\d{2}-?\d{4}$/; const emailRegex = /^[a-zA-Z0-9._-] +@[a-zA-Z0-9.-] + \.[a-zA-Z]{2,4}$/; exports.lambdaHandler = async event => { const { ssn, email } = event ; const approved = ssnRegex.test(ssn) && emailRegex.test(email); return { statusCode: 200, body: JSON.stringify({ approved, message: `identity validation ${approved ? 'passed' : 'failed'}` }) } }; JSONata を䜿甚するず、ステヌトマシンの Amazon States Language (ASL) を利甚しお正芏衚珟を盎接定矩できたす。 Pass ステヌトず JSONata の $match() を䜿甚しお、メヌルアドレスず SSN を怜蚌したす。 { "StartAt": "Check Identity", "States": { "Check Identity": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isIdentityValid": "{% $match($states.input.data.identity.email, /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/) and $match($states.input.data.identity.ssn, /^(\d{3}-?\d{2}-?\d{4}|XXX-XX-XXXX)$/) %}" } } } } 同様に、JSONata の高床な文字列関数 $length 、 $trim 、 $each 、 $not を䜿っお、 Pass ステヌトの䞭で䜏所を怜蚌できたす。 { "StartAt": "Check Address", "States": { "Check Address": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isAddressValid": "{% $not(null in $each($states.input.data.address, function($v) { $length($trim($v)) > 0 ? $v : null })) %}" } } } } JSONata を䜿甚する堎合、 $states は 予玄倉数 になりたす。 結果の集蚈 以前は JSONPath では、 Choice ステヌト以倖で匏は䜿甚できたせんでした。しかし JSONata ではそのような制限はありたせん。この䟋では、 parallel ステヌトで各サブステップからの本人確認ず䜏所確認の結果を収集しおいたす。それらの結果を boolean 倉数 isCustomerValid に集玄しおいたす。 "Verification": { "Type": "Parallel", "QueryLanguage": "JSONata", ... "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" }, "Next": "Approve or Deny?" } ここで重芁な点は、 $states.result を介した結果ぞのアクセスず、{%%} 内での AND ブヌル挔算子 の䜿甚です。これにより、この倉数を䜿甚する埌の Choice ステヌトがシンプルになりたす。 JSONata の Operators を䜿甚するこずで、可胜な限りこのような匏を柔軟に蚘述でき、単玔なデヌタ倉換するをためのコンピュヌト局を削枛できたす。 さらに、 {%%} 内の匏が true たたは false の倀を返す限り、柔軟な JSONata 挔算子および匏を利甚するこずで、 Choice ステヌトが簡単に䜿えるようになりたす。 JSONata 関数ずしおの組み蟌み関数 Step Functions は、 Step Functions の組み蟌み関数 ず同等の機胜を提䟛するために、JSONata の組み蟌み関数が提䟛されおいたす。 DynamoDB の putItem ステップでは、 States.UUID() 組み蟌み関数ず同じ機胜を持぀ $uuid() の䜿甚方法を瀺しおいたす。 たた、日付ず時刻に関する JSONata 固有の関数も利甚できたす。 以䞋のステヌトは、DynamoDB テヌブルにアむテムを挿入する前に、 $now() を䜿甚しお珟圚のタむムスタンプを ISO-8601 圢匏の文字列ずしお取埗する䟋を瀺しおいたす。 "Add Account": { "Type": "Task", "QueryLanguage": "JSONata", "Resource": "arn:aws:states:::dynamodb:putItem", "Arguments": { "TableName": "AccountTable", "Item": { "PK": { "S": "{% $uuid() %}" }, "email": { "S": "{% $inputPayload.data.identity.email %}" }, "name": { "S": "{% $inputPayload.data.firstname & ' ' & $inputPayload.data.lastname %}" }, "address": { "S": "{% $join($each($inputPayload.data.address, function($v) { $v }), ', ') %}" }, "timestamp": { "S": "{% $now() %}" } } }, "Next": "Interests" } JSONata 匏が ASL を利甚しおステヌトマシンを定矩する際の開発者の負担を軜枛するため、 S.$ 内で .$ 衚蚘が䞍芁になったこずに泚目しおください。Step Functions 内で利甚可胜な 远加の JSONata 関数 に぀いおも調べおみおください。 高床な JSONata JSONata の柔軟性は、組み蟌み関数、 高階関数 のサポヌト、 関数型プログラミング構文 に由来したす。JSONPath では、高床な匏 "InputPath": "$..interests[?(@.category ==home) ]" を䜿甚しお、配列 interests から䜏宅保険関連の興味関心をフィルタリングしおいたした。JSONata は フィルタリング 以䞊の機胜を提䟛したす。たずえば、䜏宅保険の関心事を探し、カテゎリタむプが home の totalAssetValue を参照し、name や email などの既存のフィヌルドを JSONata 倉数ずしお参照できたす。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests[category='home']{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果の JSON は次のようになりたす。 `{ "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1400000, "home": { "own": 2004, "business": 2009 } }` これらのステップに埓うこずで、すべおの保険に関する関心事ずその集玄結果を収集し、1 ぀䞊のレベルに進みたす。カテゎリフィルタヌがもう存圚しないこずに泚目しおください。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果は次のようになりたす。 { "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1549000, "home": { "own": 2004, "business": 2009 }, "auto": { "car": 2012, "motorcycle": 2018, "RV": 2015 }, "boat": { "snowmobile": 2020 } } 耇雑な匏の探玢 サンプルデヌタず JSONata プレむグラりンドを利甚 しお、芁件に合った詳现で耇雑な匏を芋぀けおください。以䞋は JSONata プレむグラりンドの䜿甚䟋です。 図 5: JSONata プレむグラりンド 考慮事項 倉数のサむズ 1 ぀の倉数の最倧のサむズは 256KiB です。 この制限は、ステヌト出力を別々の倉数に栌玍するこずで、Step Functions のペむロヌドサむズ制限を回避するのに圹立ちたす。 個々の倉数のサむズは最倧 256KiB ですが、単䞀の Assign フィヌルド内のすべおの倉数の合蚈サむズは 256KiB を超えるこずはできたせん。 この制限を回避するには Pass ステヌトを䜿甚できたすが、栌玍されたすべおの倉数の合蚈サむズは、1 回の実行に぀き 10MiB を超えるこずはできたせん。 倉数の可芖性 倉数は、ステヌト間でデヌタを共有するのを簡単にする匷力な仕組みです。䜿いやすく柔軟であるため、 ResultPath 、 OutputPath 、JSONata の Output フィヌルドよりも倉数を優先しおください。ただし、 Output を䜿う可胜性のある堎面が 2 ぀ありたす。1 ぀目は、倖偎のスコヌプから内偎のスコヌプの倉数にアクセスできない堎合です。この堎合、 Output フィヌルドを䜿うず、ワヌクフロヌの異なるレベル間でデヌタを共有できたす。2 ぀目は、ワヌクフロヌの最終ステヌトからレスポンスを送信する際に、 Output フィヌルドを䜿う必芁がある堎合です。以䞋の JSONPath から JSONata ぞの移行図に、その詳现を瀺しおいたす。 図 6: JSONPath から JSONata ぞの移行 さらに、特定のステヌトに割り圓おられた倉数は、同じステヌトからはアクセスできたせん。 "Assign Variables": { "Type": "Pass", "Next": "Reassign Variables", "Assign": { "x": 1, "y": 2 } }, "Reassign Variables": { "Type": "Pass", "Assign": { "x": 5, "y": 10, ## The assignment will fail unless you define x and y in a prior state. ## otherwise, the value of z will be 3 instead of 15. "z": "{% $x+$y %}" }, "Next": "Pass" } ベストプラクティス Step Functions の 怜蚌 API は、ワヌクフロヌのセマンティックチェックを提䟛し、早期の問題発芋を可胜にしたす。 ワヌクフロヌの安党な曎新を確実するために、怜蚌 API ず バヌゞョニングず゚むリアス を組み合わせお、段階的にデプロむするこずをお勧めしたす。 JSONata の耇数行の匏は有効な JSON ではありたせん。したがっお、セミコロン “;” で区切られた文字列ずしお 1 行 を䜿甚し、最埌の行で匏を返すようにしおください。 盞互排他 QueryLanguage タむプの䜿甚は盞互に排他的です。倉数の割り圓お時に JSONPath/組み蟌み関数ず JSONata を混圚させないでください。たずえば、以䞋のタスクは倱敗したす。倉数 b は JSONata を䜿甚しおいたすが、 c は組み蟌み関数を䜿甚しおいるためです。 "Store Inputs": { "Type": "Pass", "QueryLanguage": "JSONata" "Assign": { "inputs": { "a": 123, "b": "{% $states.input.randomInput %}", "c.$": "States.MathRandom($.start, $.end)" } }, "Next": "Average" } JSONPath で倉数を䜿甚するには 、 QueryLanguage を JSONPath に蚭定するか、タスク定矩からこの属性を削陀しおください。 結論 倉数ず JSONata により、AWS Step Functions は開発者が Amazon States Language (ASL) で通垞のプログラミングパラダむムに合わせた簡朔なコヌドで゚レガントなワヌクフロヌを蚘述できるようになり、開発者䜓隓が向䞊したした。 開発者は、䜙分なデヌタ倉換のステップを省略するこずで、より高速に、クリヌンなコヌドを蚘述できるようになりたした。 これらの機胜は、新芏および既存のワヌクフロヌの䞡方で䜿甚できるため、JSONPath から JSONata ず倉数ぞの移行を柔軟に行うこずができたす。 倉数ず JSONata は、AWS Step Functions が利甚可胜なすべおの AWS リヌゞョンで远加料金なしでお客様にご利甚いただけたす。 JSONata ず 倉数 のナヌザヌガむド、および jsonata-variables ブランチの サンプルアプリケヌション を参照しおください。 サヌバヌレスに関する知識を深めるには、 Serverless Land をご芧ください。
みなさん、明けたしおおめでずうございたす。゜リュヌションアヌキテクトの杉山です。幎末幎始で 1 週 Skip させおいただいたため、2 週たずめお 週刊AWS をお届けしたす。 幎末幎始に SNS でバズっおいた (?) レシピを䜿っお、自宅で豚骚ラヌメンを䜜りたした。たるで倖出先のお店でいただけるような味にできお、ちょっずした充実があり、リフレッシュできたした。 それでは、䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎12月23日 – 30日 週の䞻芁なアップデヌト 12/23(月) Amazon SES Mail Manager でログ機胜に察応 Amazon SES の Mail Manager でログ機胜を提䟛開始したした。Mail Manager は組織内でメヌルを送受信する際に、コンプラむアンスを䞀元的に管理できる機胜セットです。䟋えば、DKIM が Pass になったメヌルのみ受信する、Trend Micro Virus Scanning ず連携しりむルススキャン埌にメヌルを受信する、ずいったルヌル管理が可胜です。この Mail Manager に CloudWatch Logs、S3、Firehose ぞログを出力する機胜が远加され、詳现なトラブルシュヌトなどがやりやすくなりたした。詳现は こちらの Document を参照ください。 Amazon Lightsail API ゚ンドポむントが IPv6 での接続をサポヌト Amazon Lightsail API ゚ンドポむントが IPv6 プロトコルをサポヌトし、IPv6 での接続が可胜になりたした。埓来の゚ンドポむントは IPv4 専甚でしたが、新たに IPv6 接続が可胜な dual-stack ゚ンドポむント䟋 : lightsail.ap-northeast-1.api.awsが远加されたした。詳现は こちらの Document を参照ください。 AWS CloudTrail が Internet Protocol Version 6 (IPv6) をサポヌト AWS CloudTrail は CloudTrail API ゚ンドポむントでデュアルスタックを導入し、IPv6 での接続が可胜になりたした。たた、AWS PrivateLink を䜿甚しお VPC から CloudTrail API ゚ンドポむントにプラむベヌトにアクセスする堎合でも、デュアルスタックが利甚可胜です。 12/26(火) Amazon EKS が Kubernetes バヌゞョンのサポヌトステヌタスなどを取埗する API を远加 Amazon EKS で Kubernetes バヌゞョンのサポヌトステヌタスなどを取埗する API を远加したした。 DescribeClusterVersions API を AWS CLI や SDK などから利甚でき、各 Cluster Version のリリヌス日、Standard Support の期限、Extended Support の期限などを確認できたす。たた、各バヌゞョンに぀いお、珟状 Standard Support なのか、Extended Support なのか、サポヌト期限切れかどうかを確認できたす。埓来 AWS Document から確認 できたしたが、これをプログラムから取埗できるようになった圢です。 12/27(æ°Ž) Amazon EC2 I7ie むンスタンスが AWS US East (Ohio)、US West (Oregon) リヌゞョンで利甚可胜 Amazon EC2 で、I7ie むンスタンスがオハむオ、オレゎンリヌゞョンで利甚可胜になりたした。I7ie は高密床ストレヌゞ最適化むンスタンスで、倧芏暡なデヌタセットにアクセスする際に、非垞に䜎いレむテンシヌで、高いランダム読み取り/曞き蟌み性胜が必芁なワヌクロヌドに最適です。最倧 120 TB のロヌカル NVMe ストレヌゞを提䟛し、前䞖代むンスタンスず比范しお最倧 2 倍の vCPU ずメモリを提䟛したす。 1/2(朚) AWS Application Discovery Service で IPv6 ゚ンドポむントをサポヌト AWS Application Discovery Service (ADS) で、IPv6 ゚ンドポむントをサポヌトしたした。Application Discovery Service は、クラりド移行の䞀環で、移行元のサヌバヌやアプリケヌションを自動的に発芋し、それらのシステム構成、䜿甚状況、パフォヌマンスデヌタ、などの詳现な情報を収集したす。リ゜ヌスのサむゞング、アプリケヌション間の䟝存関係の把握などに利甚できたす。IPv6 をサポヌトするようになり、より幅広いネットワヌク環境でご利甚しやすくなりたした。 1/3(金) AWS WAF コン゜ヌルに新しいトップむンサむトのダッシュボヌド機胜を远加 AWS WAF のコン゜ヌルダッシュボヌドに、トラフィックに関するむンサむトを提䟛する、より充実したダッシュボヌド機胜を远加したした。CloudWatch Logs に蓄積しおいるデヌタを掻甚し、URI Path、HTTP Method、接続元 IP、User agent などの属性ごずにトラフィックデヌタを確認できるダッシュボヌドを提䟛するものです。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
はじめに 生成 AI の掻甚が䌁業の競争力を巊右する時代ずなっおいたす。しかし、 PwC 瀟の 生成AIに関する実態調査2024 春 米囜ずの比范 によるず、「必芁なスキルを持った人材がいない」や「ノりハりがなく、どのように進めれば良いか、進め方がわからない」、「意矩やメリット、費甚察効果を感じない」ずいった課題があるなど、倚くの䌁業では、生成 AI の導入にあたっお、技術的なハヌドルや、コスト面での課題を抱えおいたす。 アオラナり株匏䌚瀟 以䞋、アオラナりは、AWS が提䟛する Generative AI Use Cases JP 通称: GenUを掻甚するこずで、わずか 2 週間ずいう短期間で瀟内 RAG システムを構築し、ドキュメント怜玢時間が埓来の 1/5 皋床に短瞮するなど、倧幅な業務効率化を実珟したした。本ブログは、アオラナりがどのように GenU を掻甚したか、アオラナりの AI プロダクト開発郚の金山 陜垌氏から寄皿いただいたものです。 課題ベンチャヌ䌁業における業務効率化の必芁性 アオラナりは、埓業員数 50 名を超えるベンチャヌ䌁業です。技術的な熟緎床が高いメンバヌ高床技術者ず、未経隓メンバヌが入り混じっおおり、プロゞェクト運営の際に以䞋のような課題が生じおいたした。 高床技術者は、膚倧な技術ドキュメントの効率的な探玢に時間がかかる 未経隓メンバヌは、高床技術者ぞの問い合わせに時間を䜿っおおり、双方の時間を䜿われる 未経隓メンバヌは、忙しい高床技術者ぞの質問を躊躇しおしたう これらの課題を解決するために、最新の生成 AI 技術である RAG を利甚したいず思いたしたが、AI 導入においおは、限られた予算内で実斜できるよう工倫する必芁がありたした。 ゜リュヌションGenU を掻甚した瀟内 RAG システムの構築 AWS の AI/ML ゜リュヌションアヌキテクトである呉 和仁氏 @kazuneet に盞談したずころ、AWS が提䟛する Generative AI Use Cases JP 通称: GenU、以降 GenU ず略すをご玹介いただき、私たちは GenU を基盀ずした瀟内 RAG システムの構築を決定したした。 GenU を採甚したポむント すぐにデプロむできる AWS の技術者が構築した質の高いコヌドがすぐデプロむできる状態で甚意されおおり、自瀟での開発工数を倧幅に削枛できるこずが魅力でした。導入手順も䞁寧に解説されおおり、AWS 未経隓者でも容易に導入するこずが出来そうでしたし、結果ずしお容易でした。 カスタマむズの柔軟性 最新の LLM モデルを蚭定ファむルの倉曎のみで導入できたりず、カスタマむズが柔軟にできるように蚭蚈されおおりたした。たた、GenU の利甚状況のモニタリングや、ナヌザヌからのハルシネヌション報告などをもずにデヌタを修正するシステムを簡単に連結するこずが出来たした。 コスト最適化 サヌバヌレスアヌキテクチャが最倧限掻甚されおおり、ほが利甚分のみの安䟡な運甚コストも倧倉魅力的でした。ベクトル DBに Pinecone などのサヌドパヌティヌ補品を利甚するためのガむドもあり、さらなるコスト最適化の怜蚎が容易なように蚭蚈されおいたした。 アヌキテクチャ システムは以䞋のように、GenU をベヌスずしお、匊瀟独自に GenU を管理するためのシステムを構築しおいたす。 ServiceNow の技術ドキュメント日本語/英語60,000 ペヌゞず、600,000 件の QA デヌタを元にした瀟内 RAG システムを、2 週間で構築するこずができたした。 アオラナりでの GenU 構成 ナヌザヌは、GenU の画面から、RAG チャットを利甚しお技術的な質問をするこずが出来たす。 アオラナりでの GenU 利甚むメヌゞ GenU管理システムでは、ナヌザヌの利甚状況のモニタリングや、ナヌザヌからのハルシネヌション報告を元にデヌタの修正䜜業を行えるようにしおいたす。 アオラナりでの GenU ダッシュボヌド GenU の導入効果 GenU を導入するこずで、以䞋のような効果を月々数䞇円皋床のコストで実珟するこずが出来たした。 高床技術者は、ドキュメント怜玢時間が埓来の 1/5 皋床に短瞮 未経隓者の高床技術者ぞの問い合わせ件数が削枛 未経隓者はたず GenU で調査した埌、高床技術者に深い内容を聞くずいう質問の質の向䞊 結果ずしお、プロゞェクトを効率的に進めるこずができるようになったず䜓感しおいたす。 今埌、プロゞェクトの成果物たで生成 AI が䜜成サポヌト出来るか、怜蚌しおいく予定です。 たずめ GenU の掻甚により、私たちは短期間か぀䜎コストで高床な RAG システムを構築するこずができたした。特筆すべきは、AWS の MLSA である呉氏による手厚いサポヌトです。技術的な課題に盎面した際も、迅速な解決策の提案をいただき、スムヌズな導入を実珟できたした。 ベンチャヌ䌁業にずっお、効率的なリ゜ヌス掻甚は重芁な課題です。GenU は、その解決策ずしお非垞に有効なツヌルずなりたした。今埌も、AWS の提䟛するサヌビスを掻甚しながら、さらなる業務改善を進めおいきたいず考えおいたす。 執筆者に぀いお アオラナり株匏䌚瀟の AI プロダクト開発チヌムです。 金山 陜垌 フルスタック゚ンゞニア。゜リュヌションの蚭蚈、実装を担圓しおいたす。 新しいAI技術ず前職でのWebアプリケヌション開発の経隓を掻かし、なにかを実珟するこずを楜しんでいたす。 近頃足回りを囲むパネルヒヌタヌを手に入れたので、今冬はこれだけで乗り切ろうかず画策䞭。 宍戞 凌雅 オペレヌション゚ンゞニア。本プロゞェクトで運甚蚭蚈を䞻に担圓しおいたす。 前職で培った経隓を掻かし、効率的で効果的な運甚フロヌの構築に努めおいたす。 生成AIを仕事やプラむベヌトで積極的に掻甚しおおり、その可胜性を远求するこずで䞖の䞭に貢献したいず考えおいたす。 趣味は散歩や筋トレで、䜓力づくりを楜しみながらリフレッシュしおいたす。 鄭 å·œ AI゚ンゞニア兌開発リヌドずしお、チヌム管理䜜業ず実装䜜業を担圓しおいたす。 前職で培った統蚈知識ず開発経隓を掻かし、適切な解決策を考えお事業䟡倀を創出しおいたす。 画像認識や生成モデルの分野に興味を持ち、実務の䞭で実践できるこずを楜しんでいたす。 人ず技術の橋枡し圹ずしお、チヌムのモチベヌションを高め぀぀、成果を匕き出せるよう努めおいたす。 保田 駿介 ServiceNowコンサルタント。お客様ずのPoC実斜、プリセヌルス掻動を実斜。生成AIを含むAI/ML技術の支揎を担圓しおいたす。 様々な業界のServiceNowやSalesforceの導入を支揎しおいた経隓を生かし、ビゞネス䞊の課題や業務課題解決するためのAI/ML゜リュヌションの提案や導入支揎に努めおいたす。 BizDevの圹割ではありたすが、技術面もキャッチアップを怠らず進めおいこうず思っおたす。 李 溶基 ServiceNowアヌキテクト。AWSずServiceNowの連携郚分の開発を担圓。REST API開発経隓を生かし、ビゞネス䞊の課題を解決するためのAI/ML゜リュヌションの提案や導入支揎に努めおいたす。 プラむベヌトではランニングやゞム通いを通じおストレスを発散しおいたす 䌊藀 芳幞 ゚ンゞニア。前職の経隓を掻かし、AI/ML技術ずServiceNowを融合させ、䌁業の生産性向䞊の新しい可胜性を暡玢しおいたす。 新しい技術に觊れるこずは楜しみの䞀぀で、積極的に手を動かしおいたす。プラむベヌトでは育児に忙しい日々を送っおいたすが、フットサルやゞム通いを通じおストレスを発散しおいたす。 参考情報 Generative AI Use Cases JP Amazon Bedrock ナヌザヌガむド AWS Lambda 開発者ガむド Meta knowledge for retrieval augmented large language models (amazon science)
今日の デヌタ䞻導の䞖界 では、䌁業は デヌタレむク や りェアハりス にたたがる 膚倧な量の情報 を凊理および分析する効率的な方法を垞に暡玢しおいたす。 Amazon SageMaker Lakehouse を䜿甚するず、 Amazon Simple Storage Service ( Amazon S3 ) 䞊のデヌタレむクず Amazon Redshift デヌタりェアハりスにたたがるすべおのデヌタを統合するこずができ、匷力なアナリティクスず AI / ML アプリケヌションを䞀元化されたデヌタで構築できたす。SageMaker Lakehouse は、デヌタを動かさずに Apache Iceberg ず互換性のあるすべおのツヌルず゚ンゞンでク゚リを実行できる柔軟性を提䟛したす。これは、SageMaker Lakehouse の機胜を䜿甚したい オヌプン゜ヌスの Apache Spark ナヌザヌにずっお、゚キサむティングな可胜性を開きたす。さらに、 SageMaker Lakehouse では、すべおのアナリティクスおよび ML ツヌルや゚ンゞンに適甚されるきめ现かい暩限を定矩するこずで、デヌタを保護するこずができたす。 この投皿では、オヌプン゜ヌスの Apache Spark のパワヌを利甚し、 AWS Glue Iceberg REST Catalog で動䜜するようサヌドパヌティの゚ンゞンを蚭定する方法を探りたす。 この投皿には、 AWS Lake Formation が䞀時的なクレデンシャルを提䟛する機胜を䜿甚しおメタデヌタず実デヌタぞのアクセスを管理し、 Amazon S3 テヌブルに察しおデヌタを読み取り/曞き蟌みする操䜜を実行する方法の詳现が含たれたす。 ゜リュヌション抂芁 この投皿では、お客様が Data Catalog を䜿甚しお組織内の構造化および半構造化デヌタセットのテクニカルメタデヌタを䞀元管理し、デヌタチヌムが Apache Spark を䜿甚しおデヌタ凊理を行えるようにしたいず考えおいたす。 お客様は、 AWS Glue デヌタベヌスを䜜成したす。そしお、Lake Formation の暩限コントロヌルを䜿甚しおAmazon S3 䞊の Iceberg デヌタを読み曞きするために、Iceberg Rest API を䜿甚しお Glue Data Catalog ず察話できるよう Apache Spark を蚭定したす。 たず、 Apache Spark を䜿甚しお ETL ( 抜出・倉換・ロヌド ) スクリプトを実行するこずから始めたす。 Amazon S3 䞊に Iceberg テヌブルを䜜成し、 Glue Iceberg REST Catalog を䜿甚しおそのテヌブルにアクセスしたす。 ETL スクリプトは Iceberg テヌブルにデヌタを远加し、 その埌 Spark SQL を䜿甚しおデヌタを読み取りたす。 この投皿では、他のデヌタチヌムが Amazon Athena を䜿甚しお、このデヌタをク゚リする方法に぀いおも玹介したす。 前提条件 Data Catalog を持぀アカりントの、 Lake Formation デヌタレむク管理者である AWS Identity and Access Management (IAM) ロヌル にアクセスできる必芁がありたす。 手順に぀いおは、 デヌタレむク管理者を䜜成する を参照しおください。 Python バヌゞョン 3.7 以降がむンストヌルされおいるこずを確認したす。 pip3 のバヌゞョンが 22.2.2 以䞊であるこずを確認しおください。 最新の AWS Command Line Interface ( AWS CLI ) をむンストヌルたたは曎新したす。 手順に぀いおは、 最新バヌゞョンの AWS CLI のむンストヌルたたはアップデヌト を参照しおください。 AWS CLI を䜿甚しお aws configure を実行し、 AWS アカりントを指定したす。 お客様の Iceberg テヌブルを栌玍する S3 バケットを䜜成 したす。 今回は、 us-east-2 の AWS リヌゞョンを䜿甚し、バケット名を ossblog-customer-datalake ずしたす。 AWS Glue Iceberg REST Catalog ゚ンドポむントを䜿甚したデヌタアクセスに䜿甚する、 OSS Spark 甚の IAM ロヌルを䜜成したす。䜜成した IAM ロヌルが Data engineer permissions で定矩されおいる AWS Glue ず Lake Formation のポリシヌを持っおいるこずを確認しおください。 この投皿では、 spark_role ずいう名前の IAM ロヌルを䜿甚したす。 Lake Formation のサヌドパヌティからのアクセス暩限を有効にする このセクションでは、 Lake Formation に S3 バケットを登録 したす。 このステップにより、Lake Formation は Amazon S3 に保存されたメタデヌタずデヌタの䞀元的な暩限管理システムずしお機胜し、デヌタレむク環境においおより効率的でセキュアなデヌタガバナンスを可胜にしたす。 ロケヌションの登録に䜿甚するロヌルの芁件 に埓っお、ナヌザヌ定矩の IAM ロヌルを䜜成したす。 この投皿では、IAMロヌル : LFRegisterRole を䜿甚したす。 以䞋のコマンドを実行し、 IAM ロヌル LFRegisterRole を䜿甚しお、S3バケット ossblog-customer-datalake を登録したす。 aws lakeformation register-resource \ --resource-arn ' < S3 bucket ARN for amzn-s3-demo-bucket> ' \ --role-arn ' < IAM Role ARN for LFRegisterRole > ' \ --region <aws_region> たたは、Lake Formation の AWS マネゞメントコン゜ヌルを䜿甚するこずもできたす。 Lake Formation コン゜ヌルに移動し、ナビゲヌションペむンから Administration を遞択し、次に Data lake locations を遞択しお、以䞋の倀を入力したす。 Amazon S3 path では、 s3://ossblog-customer-datalake を遞択したす。 IAM role では、 LFRegisterRole を遞択したす。 Permission mode では、 Lake Formation を遞択したす。 Register location を遞択したす。 Lake Formationで、倖郚゚ンゞンがデヌタにアクセスできるように full table access を有効にしたす。 管理者ナヌザヌずしおサむンむンし、ナビゲヌション ペむンで Administration を遞択したす。 Application integration settings を遞択し、 Allow external engines to access data in Amazon S3 locations with full table access を遞択したす。 Save を遞択したす。 OSS Spark ロヌルのリ゜ヌスアクセスを蚭定 Lake Formation コン゜ヌルに移動し、ナビゲヌションペむンで Databases を遞択しお、デフォルトカタログに ossblogdb ずいう AWS Glue デヌタベヌス を䜜成したす。 デヌタベヌスを遞択し、 Edit を遞択しお Use only IAM access control for new tables in this database のチェックボックスをオフにしたす。 OSS Spark ロヌルにリ゜ヌス暩限を付䞎 OSS Spark が ossblogdb デヌタベヌスの䞊でデヌタセットを䜜成し、デヌタを投入できるようにするには、前提条件のステップ 4 で䜜成した Apache Spark むンスタンスの IAM ロヌル spark_role  を䜿甚したす。 Apache Spark はこのロヌルを䜿甚しお、Iceberg テヌブルを䜜成し、レコヌドを远加し、読み蟌みたす。 この機胜を有効にするには、 spark_role にフルテヌブルアクセスを付䞎し、テヌブルデヌタを保存できる S3 バケットにデヌタロケヌション暩限を付䞎したす。 spark_role にテヌブル䜜成暩限を付䞎 デヌタレむク管理者ずしおサむンむンし、AWS CLIで以䞋のコマンドを実行したす。 aws lakeformation grant-permissions \ --principal '{"DataLakePrincipalIdentifier":"arn:aws:iam:: <aws_account_id> :role/ <iam_role_name> "}' \ --permissions '["CREATE_TABLE","DESCRIBE"]'\ --resource '{"Database":{"CatalogId":" <aws_account_id> ","Name":"ossblogdb"}}' \ --region <aws_region> たたはコン゜ヌル䞊で以䞋を実斜したす Lake Formation コン゜ヌルのナビゲヌションペむンで、 Data permissions を遞択し、 Grant を遞択したす。 Principals セクション の IAM users and roles で、 spark_role を遞択したす。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を遞択したす。 Catalogs では <accountid> を遞択したす。 Databases では ossblogdb を遞択したす。 Database permissions で、 DESCRIBE ず CREATE TABLE を遞択したす。 Grant を遞択したす。 spark_role にデヌタロケヌション蚱可を付䞎 デヌタレむク管理者ずしおサむンむンし、AWS CLI を䜿甚しお以䞋のコマンドを実行したす。 aws lakeformation grant-permissions --principal '{"DataLakePrincipalIdentifier":" <Principal> "}' --permissions DATA_LOCATION_ACCESS --resource '{"DataLocation":{"CatalogId":" <Catalog ID> ","ResourceArn":" <S3 bucket ARN> "}}' --region <aws_region> たたはコン゜ヌル䞊で以䞋を実斜したす。 Lake Formation コン゜ヌルのナビゲヌションペむンで、 Data Locations を遞択し、 Grant を遞択したす。 IAM users and roles では、 spark_role を遞択したす。 Storage locations では、 バケット名 を遞択したす。 Grant を遞択したす。 AWS Glue Iceberg REST catalog ゚ンドポむントを䜿甚する Spark スクリプトのセットアップ 以䞋の内容で、 oss_spark_customer_etl.py ずいう名前のファむルをあなたの環境に䜜成したす。 import sys import os import time from pyspark.sql import SparkSession #Replace <aws_region> with AWS region name. #Replace <aws_account_id> with AWS account ID. spark = SparkSession.builder.appName('osspark') \ .config('spark.jars.packages', 'org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160') \ .config('spark.sql.extensions', 'org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions') \ .config('spark.sql.defaultCatalog', 'spark_catalog') \ .config('spark.sql.catalog.spark_catalog', 'org.apache.iceberg.spark.SparkCatalog') \ .config('spark.sql.catalog.spark_catalog.type', 'rest') \ .config('spark.sql.catalog.spark_catalog.uri','https://glue. <aws_region> .amazonaws.com/iceberg') \ .config('spark.sql.catalog.spark_catalog.warehouse',' <aws_account_id> ') \ .config('spark.sql.catalog.spark_catalog.rest.sigv4-enabled','true') \ .config('spark.sql.catalog.spark_catalog.rest.signing-name','glue') \ .config('spark.sql.catalog.spark_catalog.rest.signing-region', <aws_region> ) \ .config('spark.sql.catalog.spark_catalog.io-impl','org.apache.iceberg.aws.s3.S3FileIO') \ .config('spark.hadoop.fs.s3a.aws.credentials.provider','org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider') \ .config('spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled','false') \ .getOrCreate() spark.sql("use ossblogdb").show() spark.sql("""CREATE TABLE ossblogdb.customer (name string) USING iceberg location 's3://<3_bucket_name>/customer'""") time.sleep(120) spark.sql("insert into ossblogdb.customer values('Alice') ").show() spark.sql("select * from ossblogdb.customer").show() Pyspark をロヌカルで起動し、 Amazon S3 䞊の Iceberg テヌブルぞの読み曞き を怜蚌する pip install pyspark を実行したす。 スクリプトをロヌカルに保存し、環境倉数 AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY , AWS_SESSION_TOKEN に spark_role の䞀時的な認蚌情報を蚭定したす。 python /path/to/oss_spark_customer_etl.py を実行したす。 Athena を䜿甚しお Iceberg テヌブルのデヌタを衚瀺するこずもできたす。 他のデヌタチヌムがコンテンツを閲芧できるようにするには、Lake Formation コン゜ヌルを䜿甚しおデヌタチヌムの IAM ロヌルに読み取りアクセス暩を付䞎したす。 Lake Formation コン゜ヌルのナビゲヌションペむンで、 Data permissions を遞択し、 Grant を遞択したす。 Principals セクションの IAM users and roles で、 <iam_role> を遞択したす。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を遞択したす。 Catalogs では <accountid> を遞択したす。 Databases では ossblogdb を遞択したす。 Tables では customer を遞択したす。 DESCRIBE ず SELECT を テヌブル暩限 に遞択したす。 Grant を遞択したす。 IAM ロヌルでサむンむンし、以䞋のコマンドを実行したす。 SELECT * FROM "ossblogdb"."customer" limit 10; クリヌンアップ リ゜ヌスをクリヌンアップするには、以䞋の手順を実行したす。 Data Catalog で䜜成したリ゜ヌスデヌタベヌス/テヌブルを削陀したす。 S3バケットを 空にしお 、 削陀したす 。 結論 この投皿では、Amazon S3 の Iceberg テヌブルにアクセスするための Apache Spark ず AWS Glue Iceberg Rest Catalog のシヌムレスな統合に぀いお説明し、Iceberg REST API を䜿甚しお読み取りず曞き蟌みの操䜜を効果的に実行する方法を瀺したした。 この゜リュヌションの玠晎らしいずころは、その柔軟性にありたす。デヌタセンタヌのベアメタルサヌバヌで Spark を実行しおいる堎合でも、 Kubernetes クラスタで実行しおいる堎合でも、その他の環境であっおも、このアヌキテクチャはニヌズに合わせお適応させるこずができたす。 著者に぀いお Raj Ramasubbu は、Amazon Web Servicesのビッグデヌタおよびアナリティクス、AI / MLに特化したシニアアナリティクススペシャリスト゜リュヌションアヌキテクトです。 AWS 䞊で拡匵性、パフォヌマンス、安党性の高いクラりドベヌスの゜リュヌションを蚭蚈、構築するお客様を支揎しおいたす。 AWS 入瀟以前 20 幎以䞊にわたり、デヌタ゚ンゞニアリング、ビッグデヌタ分析、ビゞネスむンテリゞェンス、デヌタサむ゚ンス゜リュヌションの構築における技術的専門知識ずリヌダヌシップを発揮しおきたした。 圌は、ヘルスケア、医療機噚、ラむフサむ゚ンス、小売、資産管理、自動車保険、䜏宅甚䞍動産投資信蚗、蟲業、タむトル保険、サプラむチェヌン、文曞管理、䞍動産など、さたざたな業皮のお客様を支揎したした。 Srividya Parthasarathy は、 AWS Lake Formation チヌムのシニアビッグデヌタアヌキテクトです。 プロダクトチヌムやお客様ず協力しお、分析デヌタプラットフォヌム向けの堅牢な機胜ず゜リュヌションを構築しおいたす。圌女は、デヌタメッシュ゜リュヌションを構築し、コミュニティず共有するこずを楜しんでいたす。 Pratik Das は、 AWS Lake Formation のシニアプロダクトマネヌゞャヌです。 デヌタに関するあらゆるこずに情熱を持っおおり、お客様の芁件を理解し、楜しい゚クスペリ゚ンスを構築するためにお客様ず協力しおいたす。 圌は、デヌタドリブン゜リュヌションず機械孊習システムの構築経隓がありたす。 翻蚳は Solutions Architect 圓山が担圓したした。原文は こちら です。
この蚘事は Amazon EKS now supports Amazon Application Recovery Controller (蚘事公開日: 2024 幎 11 月 8 日) を翻蚳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) が Amazon Application Recovery Controller ( ARC ) のサポヌトを開始したした。ARC は AWS リヌゞョン たたはアベむラビリティゟヌン (AZ) の障害に察する準備ず埩旧を可胜にする AWS サヌビスです。 ARC には、ゟヌンシフトずゟヌンオヌトシフトを含む マルチ AZ リカバリ ず、ルヌティングコントロヌルず準備状況チェックを含む マルチリヌゞョンリカバリ の 2 ぀の機胜がありたす。今回のリリヌスにより、以前は Application Load Balancer (ALB) ず Network Load Balancer (NLB) でのみ利甚可胜だったゟヌンシフトずゟヌンオヌトシフトが Amazon EKS をサポヌトしたした。 ARC のゟヌンシフトずゟヌンオヌトシフトは、障害のある AZ から他の正垞な AZ に ingress トラフィックをシフトするこずで、サポヌトされおいる AWS リ゜ヌスのマルチ AZ リカバリを実珟したす。シフトが終了するず、ARC は ingress トラフィックを再び受信できるように以前に圱響を受けた AZ を戻したす。 Amazon EKS コン゜ヌル、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 AWS CloudFormation 、たたは eksctl を䜿甚しお、EKS クラスタヌのゟヌンシフトを有効にできたす。有効にするず、ARC コン゜ヌル、AWS CLI、たたはゟヌンシフトずゟヌンオヌトシフト API を䜿甚しお、EKS クラスタヌのゟヌンシフトを開始したり、ゟヌンオヌトシフトを有効にしたりできたす。 EKS クラスタヌでゟヌンシフトをトリガヌするには、たず AZ を遞択し、次に EKS クラスタヌ (バヌゞョン 1.28 以降) を遞択し、ゟヌンシフトを有効にする有効期限を指定したす。するず、ARC はゟヌンシフトを開始し、遞択した AZ からトラフィックを切り離したす。ARC は、有効期限が切れるか、ナヌザヌがキャンセルした堎合にゟヌンシフトを終了したす。ゟヌンシフトが終了するず、トラフィックは EKS クラスタヌに接続されおいるすべおの正垞な AZ に戻りたす。 EKS クラスタヌのゟヌンオヌトシフトを有効にするず、AZ が異垞であるこずを ARC が怜出したずきに、AWS がナヌザヌに代わっおトラフィックを切り離すこずを蚱可するこずになりたす。ARC は内郚テレメトリを䜿甚しお、AWS ネットワヌク、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Elastic Load Balancing (ELB) サヌビスなど、さたざたな゜ヌスからの重芁なヘルスメトリクスを監芖しおいたす。ARC は、圱響を受けた AZ が再び正垞状態になったこずがテレメトリで瀺されるず、ゟヌンオヌトシフトを終了したす。これにより、EKS クラスタヌに接続されおいるすべおの正垞な AZ にトラフィックが返されたす。 ARC ゟヌンシフトずゟヌンオヌトシフトを利甚する理由 AWS グロヌバルクラりドむンフラストラクチャ は、各 AWS リヌゞョンが完党に分離された耇数の AZ で構成されおいるため、耐障害性ずレゞリ゚ンスを提䟛したす。このマルチ AZ アヌキテクチャを掻甚するこずは、リヌゞョンに高可甚性アプリケヌションを実装するために䞍可欠です。Amazon EKS では、耇数の AZ にデプロむするこずで可甚性の高いアプリケヌションを迅速に開発できたすが、スケヌラブルでパフォヌマンスが高く、信頌性の高い方法で AZ の障害に察凊するには、構築ず保守に倚倧な劎力を芁するカスタム゜リュヌションを実装する必芁がありたす。 もう 1 ぀の課題は、シミュレヌションが難しいこずが倚い AZ 障害シナリオのテストです。テストが䞍十分だず、環境内の AZ で異垞が生じたずき、予期せぬワヌクロヌドの動䜜に陥る可胜性がありたす。 ARC ゟヌンシフトたたはゟヌンオヌトシフトを甚いるず、障害のある AZ で実行されおいるクラスタヌワヌカヌノヌドず Pod を䞀時的に隔離し、クラスタヌ内のネットワヌクトラフィックをそれらから自動的に切り離しお、ワヌクロヌドの耐障害性ず可甚性を向䞊させるこずができたす。 さらに、ゟヌンシフトずゟヌンオヌトシフト機胜を䜿甚するこずで、AZ 障害の蚈画ず察応に䌎うチヌムのオペレヌションオヌバヌヘッドを削枛できたす。 仕組み EKS クラスタヌを ARC リ゜ヌスずしお登録するず、ARC を䜿甚しおクラスタヌのゟヌンシフトをトリガヌしたり、もしくはクラスタヌのゟヌンオヌトシフトを有効にしたりできたす。ARC がゟヌンシフトを実行するず、クラスタヌは次のような倉曎を受けたす。 Kubernetes スケゞュヌラ が異垞な AZ のノヌドに新しい Pod をスケゞュヌルできないように、圱響を受けた AZ のノヌドは cordon (スケゞュヌル察象倖ずしおマヌク) されたす。 マネヌゞドノヌドグルヌプ (MNG) を䜿甚しおいる堎合、 アベむラビリティゟヌンの再調敎 は䞀時停止され、 Auto Scaling グルヌプ (ASG) が曎新されお、新しい Amazon EKS のデヌタプレヌンノヌドが正垞な AZ でのみ起動されるようになりたす。Karpenter ず Kubernetes の Cluster Autoscaler は、ARC ゟヌンシフトずゟヌンオヌトシフトをネむティブでサポヌトしおいたせん。正垞に動䜜しおいる AZ のみに新しいノヌドをプロビゞョニングするよう自動スケヌリングツヌルを再構成する必芁がありたす。新しいノヌドの起動に特定の AZ のみを䜿甚するように Karpenter ず Cluster Autoscaler を蚭定する方法に぀いおは、 Amazon EKS ベストプラクティスガむド を参照しおください。 異垞な AZ のノヌドは終了されたせん。したがっお、圱響を受けた AZ の Pod は削陀されたせん。これは、ゟヌンシフトの期限が切れたりキャンセルされたずきに、トラフィックがフルキャパシティヌの状態の AZ に安党に戻るようにするためです。 EndpointSlice controller は、障害のある AZ 内のPod の Endpoint を怜出し、それらを関連するEndpointSlice リ゜ヌスから削陀したす。これにより、ネットワヌクトラフィックが正垞な AZ の Pod の Endpoint のみを察象ずするこずが保蚌されたす。Endpoint slice controller は、ゟヌンシフトがキャンセルたたは期限切れになるず、埩元された AZ の Endpoint を含むように Endpoint slice を曎新したす。 次の図は、Amazon EKS 環境における AZ の異垞が生じた堎合の east-to-west (クラスタヌ内郚) のトラフィックフロヌを瀺しおいたす。このようなシナリオでは、ネットワヌクパケットのドロップやネットワヌク遅延が発生する可胜性がありたす。 次の図は、障害のある AZ からトラフィックを切り離した堎合の Amazon EKS 環境を瀺しおいたす。 ゟヌンシフトずゟヌンオヌトシフトのための EKS クラスタヌずワヌクロヌドの準備 Amazon EKS でゟヌンシフトずゟヌンオヌトシフトが正垞に動䜜するようにするには、事前に AZ 障害に匷いクラスタヌ環境を準備する必芁がありたす。以䞋は、 EKS クラスタヌに実装する必芁がある重芁なステップのリストです。これらのステップに぀いおは、 Amazon EKS のドキュメント で詳しく説明されおいたす。 クラスタヌ内のワヌカヌノヌドを耇数の AZ に分散したす。 単䞀の AZ の削陀に耐えられるだけの十分なコンピュヌティングキャパシティをプロビゞョニングしおください。AZ 障害に耐えられるアプリケヌションの構築方法の詳现に぀いおは、 静的安定性 に関する AWS のドキュメントを参照しおください。 すべおの AZ で、Pod を事前にスケヌリングしおください。これらの Pod には、アプリケヌション Pod ず、CoreDNS、Cluster Autoscaler、 AWS Load Balancer Controller などのコントロヌラヌ Pod が含たれたす。これを実珟する方法の詳现に぀いおは、 Amazon EKS のドキュメント を参照しおください。 Pod レプリカを耇数の AZ をたたいで分散させお、単䞀の AZ を切り離しおも十分な容量が残るようにしたす。これを実珟するには、Topology spread constraints が圹立ちたす。 クラスタヌで実行されおいるコントロヌラヌやその他のアプリケヌションの高可甚性 (HA) をサポヌトするためにリヌダヌの遞出が必芁な堎合は、ポッドの数が奇数であるか、ポッドが 2 ぀以䞊であるなどの基準が、AZ 障害むベント䞭および発生埌に䞀貫しお満たされおいるこずを確認しおください。 ロヌドバランサヌを䜿甚しお倖郚トラフィックを Kubernetes の Service にルヌティングする堎合は、ALB ず NLB のみを䜿甚するこずをお勧めしたす。 AWS Load Balancer Controller を䜿甚しおロヌドバランサヌを管理するこずもお勧めしたす。AWS Load Balancer Controller はむンスタンスず IP トラフィックモヌドをサポヌトしおいたすが、そのうちの IP モヌドが掚奚されたす。むンスタンスず IP モヌドの詳现に぀いおは、 AWS Load Balancer Controller のドキュメント を参照しおください。 Amazon EKS のゟヌンシフトによっおアプリケヌションずクラスタヌ環境が正垞に回埩するには、前述のステップが䞍可欠です。さらに、AZ 障害を効果的に管理するには、以䞋のベストプラクティスをお勧めしたす。 Topology Aware Routing などの Kubernetes 機胜を䜿甚するか、 サヌビスメッシュ ず統合するこずで、Pod 間の通信を同じ AZ 内に限定したす。 同じ AZ 内に、盞互に䟝存するアプリケヌションずサヌビスを配眮したす。これは Pod Affinity rule で実珟できたす。 マルチ AZ オブザヌバビリティ を実装したす。 アプリケヌションでは、デヌタベヌス、サヌビスなどの倖郚䟝存関係に察するタむムアりト倀を適切に蚭定し、再詊行を実装しおください。障害を正垞に凊理するには、゚クスポネンシャルバックオフパタヌンを備えたサヌキットブレヌカヌを実装しおください。 ゟヌンシフトずゟヌンオヌトシフトをサポヌトするようにクラスタヌずワヌクロヌドを準備する方法、およびゟヌンシフトずゟヌンオヌトシフトに関するその他のベストプラクティスの詳现に぀いおは、 Amazon EKS ドキュメント を参照しおください。 さらに、ワヌクロヌドが AZ 障害を凊理できるこずを定期的にテストしお怜蚌するこずを匷くお勧めしたす。ゟヌンシフトを手動でトリガヌするか、ゟヌンオヌトシフトを有効にしお、クラスタヌ環境の AZ を 1 ぀枛らしおワヌクロヌドが期埅どおりに機胜するこずを確認するこずで、AZ 障害をテストできたす。 始めおみよう ARC ゟヌンシフト機胜の説明に䜿甚するサンプルアプリケヌションを準備したした。このりォヌクスルヌでは、既存の EKS クラスタヌを䜿甚するか、 新しいクラスタヌを䜜成 できたす。クラスタヌずそのクラスタヌに蚭定されおいるノヌドグルヌプは、3 ぀の AZ にたたがり、各 AZ に少なくずも 1 ぀のノヌドが必芁です。 1. サンプルアプリケヌションをデプロむする a. たず、EKS クラスタヌにサンプルアプリケヌションをデプロむしたす。Kubernetes Secret を䜜成するずきは、必ず有効なナヌザヌ名ずパスワヌドを指定しおください。この Secret は、MySQL デヌタベヌスずそれに接続するアプリケヌションの䞡方で䜿甚されたす。 kubectl create secret generic catalog-db --from-literal=username=<<有効なナヌザヌ名で眮換>> --from-literal=password=<<有効なパスワヌドで眮換>> cat << EOF > catalog_deploy.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: catalog data: DB_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_READ_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_NAME: catalog --- apiVersion: v1 kind: Service metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: clusterIP: None ports: - port: 3306 targetPort: mysql protocol: TCP name: mysql selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql --- apiVersion: v1 kind: ServiceAccount metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm --- apiVersion: v1 kind: Service metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: type: ClusterIP ports: - port: 80 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample --- apiVersion: apps/v1 kind: Deployment metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: replicas: 3 strategy: rollingUpdate: maxUnavailable: 1 type: RollingUpdate selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: "8080" prometheus.io/scrape: "true" labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog serviceAccountName: catalog securityContext: fsGroup: 1000 containers: - name: catalog env: - name: DB_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password envFrom: - configMapRef: name: catalog securityContext: capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 image: public.ecr.aws/aws-containers/retail-store-sample-catalog:0.8.1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 8080 protocol: TCP livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 3 resources: limits: memory: 256Mi requests: cpu: 128m memory: 256Mi volumeMounts: - mountPath: /tmp name: tmp-volume volumes: - name: tmp-volume emptyDir: medium: Memory --- apiVersion: apps/v1 kind: StatefulSet metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql app.kubernetes.io/managed-by: Helm spec: replicas: 3 serviceName: catalog-mysql selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql template: metadata: labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/component: mysql containers: - name: mysql image: public.ecr.aws/docker/library/mysql:8.0 imagePullPolicy: IfNotPresent env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password - name: MYSQL_DATABASE value: catalog - name: MYSQL_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: MYSQL_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password volumeMounts: - name: data mountPath: /var/lib/mysql ports: - name: mysql containerPort: 3306 protocol: TCP volumes: - name: data emptyDir: {} --- EOF kubectl apply -f catalog_deploy.yaml b. Kubernetes マニフェストファむルをクラスタヌに適甚するず、それぞれ catalog ず catalog-mysql ずいう名前の 2 ぀のアプリケヌションが䜜成され、 catalog-mysql は MySQL デヌタベヌスになりたす。次のステップに進む前に、Pod が実行状態であるこずを確認したす (これには数分かかる堎合がありたす)。 2. クラスタヌのゟヌンシフトを有効にする a. Amazon EKS コン゜ヌルを開いおクラスタヌを遞択し、次の図に瀺すように、 抂芁 (Overview) の ゟヌンシフト (Zonal Shift) セクションに移動したす。 b. 管理 (Manage) を遞択し、 有効化 (Enabled) を遞択し、倉曎を保存したす。 3. アプリケヌションを怜蚌する a) default Namespace で利甚可胜な Service を䞀芧衚瀺したす。 kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE catalog LoadBalancer XX.XXX.XXX.XXX <pending> 80:31932/TCP 41m catalog-mysql ClusterIP None <none> 3306/TCP 41m b) catalog Service ぞの kubectl port-forward をバックグラりンドモヌドで実行したす。プロセスのプロセス ID を曞き留めおおきたす。 kubectl port-forward svc/catalog 8090:80 > /dev/null & [1] 42306 c) curl を䜿甚しお catalog Service を呌び出すず、以䞋に瀺すように、いく぀かのアむテム ID を返すこずを確認したす。 curl -s localhost:8090/catalogue | jq -r '.[0,1].id' 510a0d7e-8e83-4193-b483-e27e09ddc34d 6d62d909-f957-430e-8689-b5129c0bb75e # port-forward プロセスを終了 (42306) kill -9 <<kubectl port-forward プロセスのプロセスID>> 4. クラスタヌ・トポロゞヌを理解する アプリケヌションが正垞に動䜜しおいるこずを確認できたので、ゟヌンシフトを実行する準備が敎いたした。ただし、ゟヌンシフトをトリガヌする前に、クラスタヌのトポロゞヌを理解する必芁がありたす。これには、Pod が皌働しおいる AZ を特定するこずが含たれたす。 a. リヌゞョンの AZ ID を䞀芧衚瀺したす。この䟋では、リヌゞョンは us-west-2 なので、us-west-2 の AZ ID を確認できたす。 aws ec2 describe-availability-zones --query 'AvailabilityZones[*].[ZoneName, ZoneId]' --output text us-west-2a usw2-az2 us-west-2b usw2-az1 us-west-2c usw2-az3 us-west-2d usw2-az4 b. 次のコマンドを䜿甚しお、クラスタヌ内の各ノヌドずそれが動䜜しおいる AZ を特定する必芁がありたす。次のコマンドを入力するず、ノヌド名ずノヌドが実行されおいる AZ のリストが出力されるはずです。この䟋では、3 ぀のノヌドが 3 ぀の AZ (us-west-2b、us-west-2b、us-west-2c) に分散しおいたす。 kubectl get nodes -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.metadata.labels.topology\.kubernetes\.io/zone}"{"\n"}{end}' | sort -k 1 > nodes-info.txt cat nodes-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2a" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2b" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2c" c. 次のコマンドを䜿甚しお、各 Pod が珟圚実行されおいるノヌドず AZ を特定する必芁がありたす。コマンドを入力するず、Pod 名、AZ、および Pod が実行されおいるノヌドを瀺す出力が生成されたす。この堎合、3 ぀の AZ の 3 ぀のノヌドに分散されたカタログアプリケヌションポッドがありたす。 kubectl get pods -l "app.kubernetes.io/component"=service -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.spec.nodeName}"{"\n"}{end}' | sort -k 2 > pods-info.txt join -1 1 -2 2 nodes-info.txt pods-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2b" "catalog-74957c74ff-xxxxx" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2c" "catalog-74957c74ff-yyyyy" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2a" "catalog-74957c74ff-zzzzz" 5. ゟヌンシフトをトリガヌする これで、クラスタヌ・トポロゞヌを十分に理解できたはずです。次に、ゟヌンシフトをトリガヌしおトラフィックを AZ から切り離し、ゟヌンシフト機胜をテストしたす。 a. 次の図に瀺すように、ARC コン゜ヌルを開き、 ゟヌンレベルの移行 (Zonal Shift) を遞択したす。 b. 次の図に瀺すように、ゟヌンシフトを開始するために、トラフィックを切り離す AZ (us-west-2b)、ゟヌンシフトを実行する EKS クラスタ、有効期限 (10 分) を遞択しお、そしお 開始 (Start) を遞択したす。 ゟヌンシフトは、トリガヌしおから完了するたでに数分かかりたす。そのため、数分埅っおからテストするこずをお勧めしたす。 c. アプリケヌションの Endpoint ぞのトラフィックを生成しおアプリケヌションを怜蚌し、トラフィックを切り離した AZ で実行されおいる Pod に察しお呌び出しが行われおいないこずを確認したす。そのためには、たず Kubernetes Job を実行しおアプリケヌションぞのトラフィックを生成し、次にトラフィックを凊理する Pod ずそれらが属する AZ をログから特定したす。次のコマンドを入力するず、catalog Service ぞのトラフィックが 2 ぀の Pod に分散されおいるこずがわかりたす。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間埅぀ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 5 catalog-78679df9c4-xxxx 6 catalog-78679df9c4-zzzz d. Pod の䜍眮を確認するず、どの Pod も AZ us-west-2b (ゟヌンシフトによっおトラフィックが迂回された AZ) で皌働しおいないこずがわかりたす。 join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 5 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 6 e. 先に進む前に、トラフィックを生成するために䜜成した Kubernetes Job を削陀したす。 kubectl delete job curl-job 6. ゟヌンシフトをキャンセルする a. 次の図に瀺すように、以前に䜜成したゟヌンシフトを遞択し、 ゟヌンシフトをキャンセル (Cancel zonal shift) を遞択しお、ゟヌンシフトのキャンセルをテストしたす。 ゟヌンシフトのキャンセルは、トリガヌしおから完了するたでに数分かかりたす。そのため、数分埅っおからテストするこずをお勧めしたす。 b. アプリケヌションぞのトラフィックを生成し、AZ で動䜜しおいる Pod がトラフィックを受信しおいるこずを確認できたす。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間埅぀ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 9 catalog-78679df9c4-xxxx 7 catalog-78679df9c4-yyyy 5 catalog-78679df9c4-zzzz join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 9 catalog-74957c74ff-yyyy ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal us-west-2b 7 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 5 # kubernetes job を削陀する kubectl delete job curl-job 7. クラスタヌのゟヌンオヌトシフトを蚭定したす a. ゟヌンオヌトシフトを蚭定する前に、ARC が緎習実行が成功のうちに完了したかどうかを怜査するために甚いる Amazon CloudWatch アラヌムを蚭定する必芁がありたす。ARC ゟヌンオヌトシフトの緎習実行の詳现に぀いおは、この ドキュメント を参照しおください。 b. 次の図に瀺すように、ARC コン゜ヌルを開き、 ゟヌンオヌトシフトを蚭定 (Configure zonal autoshift) を遞択したす。 c. ゟヌンオヌトシフトの蚭定するリ゜ヌス (Resource to configure) ずしお EKS クラスタヌを遞択し、ゟヌンオヌトシフトのステヌタス (Zonal autoshift status) で 有効化 (Enable) を遞択し、CloudWatch アラヌム ARN を入力しお 䜜成 (Create) を遞択したす。次の図に瀺すように、コン゜ヌルのオプションセクションはそのたたにしおおきたす。 d. ARCは、緎習実行の䞀環ずしお、週に1回、ゟヌンオヌトシフトを実斜したす。Amazon EventBridge ずの統合を甚いお、ゟヌンオヌトシフトず緎習実行の通知を受け取るこずができたす。緎習実行䞭に、ゟヌンシフトの怜蚌に䜿甚したのず同じ怜蚌手順をゟヌンオヌトシフトに適甚できたす。 ゟヌンシフトずオヌトシフトにより、AZ 障害からの迅速な回埩ず Amazon EKS ワヌクロヌドの信頌性の向䞊が可胜になりたす。AZ 障害に察しお真に回埩力を発揮するには、ワヌクロヌドがゟヌンシフトやゟヌンオヌトシフト機胜を䜿甚するだけでなく、「クラスタヌずワヌクロヌドの準備」セクションで抂説されおいるプラクティスを遵守しお AZ 障害からの回埩も行う必芁がありたす。 埌片付け 今埌のコストを避けるため、この挔習甚に䜜成された EKS クラスタヌなどのリ゜ヌスをすべお削陀しおください。次のコマンドは、ゟヌンシフトをテストするために以前にむンストヌルしたアプリケヌションを削陀したす。 kubectl delete -f catalog_deploy.yaml kubectl detelet secret catalog-db rm nodes-info.txt pods-info.txt pod-logs.txt pods-nodes-az.txt 䟡栌ず提䟛リヌゞョン Amazon EKS の ARC ゟヌンシフトおよびゟヌンオヌトシフト機胜の察応は、䞭囜ず GovCloud リヌゞョンを陀くすべおの AWS リヌゞョンで利甚できたす。EKS クラスタヌでゟヌンシフトを有効にしおゟヌンシフトをトリガヌしおも、远加のコストは発生したせん。ただし、Pod やクラスタヌノヌドの事前スケヌリングなど、ワヌクロヌドが AZ 障害を確実に凊理できるようにするために、远加のコストがかかる堎合がありたす。 たずめ この投皿では、ARC ゟヌンシフトおよびゟヌンオヌトシフト機胜を䜿甚しお、単䞀の AZ 障害から回埩する方法を説明したした。入念な蚈画ず実装を行うこずで、ゟヌンシフトずゟヌンオヌトシフトの可胜性を最倧限に掻甚しお、単䞀の AZ 障害から Amazon EKS クラスタヌで実行されおいるアプリケヌションずデヌタ゜ヌスを保護できたす。 Amazon EKS のゟヌンシフトずゟヌンオヌトシフトの詳现に぀いおは、 Amazon EKS のドキュメント を参照しおください。 GitHub でホストされおいる AWS Containers Roadmap にコメントを残したり、Issue を投皿したりするこずで、EKS クラスタヌの ARC ゟヌンシフト機胜に関するフィヌドバックを提䟛できたす。今埌も機胜を進化させ、ナヌザヌがクラスタヌの耐障害性ず可甚性を向䞊させるのに圹立぀さたざたな方法を暡玢しおいきたすので、ご期埅ください。 翻蚳はシニアパヌトナヌ゜リュヌションアヌキテクトの垂川が担圓したした。原文は こちら です。