「金融リファレンスアーキテクチャ日本版」 は、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして 2022 年 10 月に正式版として発表し、多くのお客様にご利用いただいております。 この度、皆様からいただいたご意見を踏まえ、レジリエンス関連の機能強化を行ったv1.3を公開しました。変更点の概要は以下の通りです。 [v1.3での主な変更点] 勘定系ワークロード: マルチリージョン・デモ用サンプルアプリケーションの強化 1-1. Step Functionsによるリージョンの自動フェールオーバー 1-2. Synthetics Canaryによるアプリケーションの外形監視 1-3. OpenTelemetryの導入 (AWS X-Ray) 勘定系ワークロード: ランサムウェア対策の追加 これらのアップデートについて解説していきます。 1. マルチリージョンアプリケーションのレジリエンス強化 1-1. Step Functionsによるリージョンの自動フェールオーバー 金融リファレンスアーキテクチャ勘定系ワークロードでのマルチリージョンの構成 金融リファレンスアーキテクチャの勘定系ワークロードは、銀行の各種業務とその元帳のDBを管理する勘定系業務に対するリファレンスアーキテクチャーです。このアーキテクチャにあわせたオンライントランザクション処理のサンプルアプリケーションが含まれています。銀行勘定系をターゲットとしていますが、汎用的なトランザクション処理に向けたものとなりますので、他の同様なワークロードにも適用可能です。 勘定系ワークロードのリファレンスアーキテクチャ このアーキテクチャではアプリケーションをマルチAZ構成にすることで通常故障から保護しています。さらに、東京と大阪のマルチリージョンで Active – Standby 構成としています。東京リージョン全体が影響を受けるような何等かの障害が発生しても、大阪リージョンへフェイルオーバーすることで、サービスを提供し続けることが出来るようになっています。 このワークロードの上で稼働するアプリケーションとしては、トランザクション管理、アトミック性、排他制御などが求められるため、メイン DB としてRDBMSであるAurora Global Database、アプリケーションのステート管理用 DB として DynamoDB を使用しています。また、アプリケーションはECS上で東京、大阪の両リージョンで常時起動しており、 Route 53 ARC を利用して利用リージョンのアプリケーションへトラフィック制御を行っています。 リージョン切り替えのフローと自動化 東京リージョンの障害を想定してのフェイルオーバーと収束後の切り戻しを想定したフェイルバック、２つの切り替えフローを準備しています。 フェイルオーバーの流れを示したのが以下の図です。元帳にあたるAuroraDBのデータ不整合を避けるため、まずStep1として東京リージョンのアプリケーションを閉塞しデータベースの更新を停止します。これはDynamDB Global Tablesに持つ閉塞フラグを利用します。その後Step2としてクライアントのリクエストをDNSにより大阪リージョンへルーティングします。これはTTLを加味してAurora Global Databaseの切り替え中に東京へのルーティング情報が残らない状態にするため、また障害によるエラーではなく大阪リージョンで稼動するアプリケーションにルーティングすることで適切に閉塞のステータスを返却するためです。その後Step3としてAurora Global Databaseを使ってレプリケーションされている大阪リージョンのBDに切り替えます。切り替えが完了したのち、最後にStep4として大阪リージョンのアプリケーション閉塞を解除します。この一連のフェイルオーバーは約５分間で完了します。 Step Functionsによるリージョン切り替え作業の自動化 フェイルオーバとフェイルバックのフローは Step Functions を使って以下のようなステートマシンのフローで自動化しています。自動化においては各々のStepの間に、適切な切り替えのための待ち時間や確認処理を入れることが重要です。詳細は以下の図で示しています。 Step Functionsのステートマシン実行 1-2. Synthetics Canaryによるアプリケーションの外形監視 ミッションクリティカルなアプリケーションにおいて、外形監視はユーザー体験を直接反映し、システム全体の健全性を把握するために重要です。システム視点での内部監視では検出が難しい複雑な障害やネットワーク遅延を早期に発見し、迅速な対応を可能にします。また、サービスレベル契約（SLA）の遵守確認や、ビジネスインパクトの最小化にも寄与します。 今回のアップデートでは、 AWS CloudWatch Synthetics Canary を活用して、アプリケーションの外形監視のサンプル実装を提供します。このアプリケーションは残高照会、入金処理、出金処理のAPIを通じてトランザクションを処理します。大阪リージョンに設定したCanaryを用いて東京リージョンで稼働するアプリケーションに対して継続的に疑似トランザクションを実行させて、APIの応答メッセージの正常性と応答遅延を継続的にチェックしています。このサンプルによって、問題が発生した際に迅速に対応でき、サービスの信頼性を高めることができます。 Synthetic Canaryの実行 疑似トランザクション生成のためのHTTPリクエスト 1-3. OpenTelemetryの導入 (AWS X-Ray) サンプルアプリケーションの外形監視に加え、 AWS X-Ray を利用して、マイクロサービス間の遅延やエラー、失敗をトレースする仕組みを導入しました。このアプリケーションは残高照会、入金処理、出金処理のAPIを提供し、それぞれがマイクロサービスで構成されています。X-Rayを用いることで、各リクエストのフローを詳細に可視化し、特定のサービスでのパフォーマンス低下やエラー箇所を迅速に特定可能です。このトレース機能により、問題発生時の迅速なトラブルシューティングと、サービス全体の信頼性向上が実現されます。 X-Rayによるトレース 2. ランサムウェア対策の追加 ランサムウェアとは ランサムウェアとは「身代金（ransom、ランサム）を支払わないと被害者のデータを公開したり、ビジネスに不可欠な情報へのアクセスを遮断するマルウェアの一種のこと」です。ランサムウェアによる被害は、IPA (情報セキュリティ推進機構) が公表している 情報セキュリティ10大脅威 2024 の組織向け脅威の１位として挙げられており、組織にとって重大なセキュリティ上の脅威となっています。 ランサムウェアとは？ ランサムウェアによる被害を防ぐには、マルウェアの侵入防止や攻撃者によるデータへのアクセス防止、データアクセスの失敗を攻撃の予兆として検知するなどの対策が考えられますが、ここでは実際に被害を受けてしまった場合の復旧に備えたバックアップ取得に関する対策についてご紹介します。 ランサムウェアに対する主な対策 金融リファレンスアーキテクチャ勘定系ワークロードでの対策 勘定系ワークロードは永続化データに、メイン DB として Aurora Global Database、アプリケーションのステート管理用 DB として DynamoDB を使用しており、これらのデータベースを対象にランサムウェア攻撃を受けた際に復旧可能なように AWS Backup でバックアップを取得します。 AWS Backupは、取得したバックアップをバックアップボールトとして管理します。バックアップボールトには、取得したバックアップを保護するためにボールトロックをオプションで指定することができ、２種類のロックモードを提供しています。ガバナンスモードでは、ボールトに格納されたリカバリポイントは特定の IAM 権限でのみ削除可能なロックモードとなっており、コンプライアンスモードはデータ保持期間が終了するまでボールトとリカバリポイントをルートユーザー（アカウント所有者）や AWS を含めていかなるユーザーも変更、削除することができなくなります。詳しくは こちら をご覧ください。 AWS Backup Vault Lock ボールトロックはこのようにリカバリポイントを保護する機能を提供するため、ランサムウェア対策として利用することができます。金融リファレンスアーキテクチャ勘定系ワークロードでは、Aurora Global Database と DynamoDB テーブルを対象に AWS Backup でバックアップを取得し、ボールトロックを指定したバックアップボールトへと保管しています。ただしサンプルアプリケーションであることから、十分な IAM 権限を持つユーザーであればデータ削除が可能であるガバナンスモードでの実装としています。コンプライアンスモードに変更することで、バックアップボールトに格納されたリカバリポイントを一定期間、特権ユーザーでも削除できない状態とすることが可能です。 まとめ 金融リファレンスアーキテクチャ日本版の全てのコンテンツとコードは、パブリックの  GitHub リポジトリ から参照でき、Git リポジトリとしてローカル環境にクローンすることもできます。フィードバックや質問については Issue として GitHub サイト上に登録いただけます。また、執筆者に直接ご連絡頂いても構いません。ご利用される皆様からのニーズや意見に基づいて今後の改善方針を決めていきたいと考えておりますので、ご質問やフィードバックをお待ちしております。 金融リファレンスアーキテクチャ日本版v1.3での変更点の詳細については こちら を参照下さい。 なお、本ブログ記事は AWSのソリューションアーキテクトである根本裕規、疋田洋一、深森広英で執筆いたしました。 謝辞 アマゾン ウェブ サービス ジャパン合同会社 金融グループ/グローバルフィナンシャルサービス/プロトタイピングチームの下記メンバーで今回の開発を行いました。 根本裕規、疋田洋一、吉澤稔、深森広英、友岡雅志

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 9月に入り2024年もあと4ヶ月になりました。時間の流れの速さに驚いている今日この頃ですが、AWSでは年末に向けて様々なイベントを企画しています。随時情報をお知らせしていきますので楽しみにお待ち頂ければと思いますが、新しい知識を仕入れて頂いたり、実際に手を動かして頂いて実感を得て頂いたり、様々な体験をお届けしたいと思っていますので、是非ご期待ください。 「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、8 月 19 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ファミリーマート様、生成AIによりシステム運用業務を効率化 株式会社ファミリーマート様は、大規模で複雑なものになりがちなシステム開発において、今までの教訓や担当者の知見を効率的に活用したいという課題を感じており、生成AIを使った解決にチャレンジすることとしました。既存のシステムとの連携やセキュリティ向上のために様々なルールが設けられていますが、効率的に情報を検索するためのチャットボットがその第一歩です。着目すべきはPoCの実施に当たって定量的な評価手法を定義し、成功の度合いを測定できる用にしている点です。これによって生成AIで課題解決ができるテーマ、さらなる改善が必要なテーマを明確に判断することができているそうです。今後の展開として、このチャットボットの本格展開を検討しています。 AWS生成AI国内事例ブログ: 株式会社JDSC様、Bedrockによる横断検索システムで専門的な工数を97%削減 株式会社JDSC様は日本の産業のアップデートを使命とする、東京大学発のAI企業です。この事例は、JDSC様が海運事業に取り組むお客様に検索拡張生成(RAG)を構築し、専門的な知識を要する問い合わせ対応の時間を約97%削減、従来のシステムと比較して回答の精度を30%向上させるという結果を得ることに成功しています。また、問い合わせ対応にあたって属人的な知識や専門知識の必要性を軽減することで、対応可能な人材の幅を広げることができています。当初はClaude 3 Sonnetの利用を検討していたところ、Amazon Titan Text V2やClaude 3.5 Sonnetを比較し、用途に対してより良い結果が得られるClaude 3.5 Sonnetを採用することとしたエピソードは、Bedrockらしい事例だなと感じます。 ブログ記事「生成 AI のためのネットワーク境界でのセキュリティ保護」を公開 生成AIを組み込んだアプリケーションにおいても、セキュリティは重要な考慮事項です。このブログ記事では、ネットワーク境界保護の観点を説明し、生成AIアプリケーションにおいてどのように適用されるべきか、具体的なアーキテクチャ例はどういったものかを解説しています。ネットワーク境界保護を適用するとこで、不正使用やコスト超過、DDoS攻撃などへの耐性を獲得するためのアイデアが詰まっている記事です。 ブログ記事「Amazon Bedrock を活用した RAG チャットボットアーキテクチャのハードニング : セキュアデザインのためのブループリントとアンチパターンへの緩和戦略」を公開 この記事はセキュリティ計画を立案しそれに適合するようにAmazon Bedrockを利用することで、安全で責任あるチャットボットアプリケーションをデプロイする方法を解説しています。また、大規模言語モデル(LLM)を利用する際に課題に成り得る一般的なセキュリティリスクと、アンチパターンについても提示します。LLMを組み込んだアプリケーションの信頼性を高めるための手法を知ることができますので、ぜひご一読ください。 サービスアップデート Amazon Q Businessがユーザ認証のフェデレーションに対応 Amazon Q BusinessでIAMフェデレーション機能が公開されました。この機能を利用するとAmazon Q BusinessでOIDC(OpenID Connect)とSAML2.0プロトコルをサポートするアイデンティティプロバイダーと連携し、これらで管理するユーザIDとユーザの属性を利用してユーザの認証・認可が可能になります。従来は一旦AWS IAM Identity Centerに同期する必要がありましたが、この手間が不要になるのがポイントです。 Amazon Bedrockがクロスリージョン推論をサポート Amazon Bedrockでクロスリージョン推論機能が利用できるようになりました。この機能は、複数のリージョンでトラフィックを動的にルーティングすることで、ユーザトラフィックの増加時にも、より高いスループットやサービスの可用性を高めることが可能になります。利用できるリージョンをあらかじめ定義できるので、推論データが処理される場所を制御することもできます。現時点ではAnthropicのClaudeが対象になっています。 ブログ も出ていますのでこちらもどうぞ。 Amazon Bedrock Knowledge BasesでMetaのLlama 3.1を利用可能に Amazon Bedrock Knowledge Basesは検索拡張生成(RAG)を容易に実現するサービスです。今回、Amazon Bedrock Knowledge BasesでMeta社のLlama 3.1 405B, 70B, 8Bのモデルを利用できるようになりました。RAGワークロードにおいても、用途に応じて最適なモデルの選択肢の幅が広がっています。 Amazon SageMaker Projectsで過去に削除したプロジェクト名の再利用が可能に Amazon SageMaker Projectsは開発者環境とMLOpsのためのCI/CDシステムの設定や標準化を支援する機能です。今回、過去に使用していて削除したプロジェクトと同じ名前を、新しいプロジェクトに再利用できるようになり、命名規則を柔軟に考える事が可能になります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週も書きましたが、AWS Innovate – Migrate. Modernize. Build. が 9 月 26 日 (木)にオンラインで開催されます。先日実施した AWS Builders Online (現在オンデマンド視聴可能) はAWS入門のイベントでしたが、こちらはすでに活用されているユーザー企業の事例発表や、最新技術の情報が6トラックで実施されます。今回のテーマはモダナイズですので、クラウドテクノロジーを活用したモダナイズに関するセッションが多数提供されます。ぜひご参加ください。 – AWS Innovate – Migrate. Modernize. Build. それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月26日週の主要なアップデート 8/26(月) Amazon Braket は、ゲート方式の超電導デバイスである Rigetti の 84 量子ビット Ankaa -2 システムのサポートの追加を発表 – AWS AWS の量子コンピューティングサービスである Amazon Braket で Rigetti Computingの最新の84量子ビット Ankaa-2 システムが利用可能になりました。現在、北カリフォルニアリージョンで利用可能です。Ankaa-2 は、Amazon Braket で使用できる中で量子ビット数が最も多いゲート方式の量子デバイスです。 Amazon QuickSight で、組み込みダッシュボードにおいてビューの共有がサポートされるようになりました – AWS Amazon QuickSight で、組み込みダッシュボードにおいてビューの共有がサポートされるようになりました。ビューの共有は、ダッシュボードにフィルタなどを設定した状態を他ユーザーに共有するための機能ですが、これが今回の機能追加で埋め込みダッシュボードでも利用可能になりました。 8/27(火) Amazon Q Business launches IAM federation for user identity authentication – AWS Amazon Q Business は 生成AIのアシスタントで、顧客の企業データに基づいて質問への回答や情報のサマリなどを提供するサービスです。今回の機能追加で、IDプロバイダー (IdP)に直接連携できるようになりました（以前はいったん AWS IAM Identity Center に同期する必要がありました）。OpenID Connect (OIDC) プロトコルと SAML2.0 プロトコルをサポートします。 AWS announces support for Microsoft Entra ID and Microsoft Intune on Amazon WorkSpaces Personal – AWS Amazon WorkSpaces Personal は Microsoft Entra ID と Intune をサポートするようになりました。これにより Microsoft Active Directory を必要とせずに、Entra ID と連携し、Intune に登録されている仮想デスクトップをプロビジョニングできます。引き続き Active Directory との連携も利用することが可能です。 Amazon EC2 status checks now support reachability health of attached EBS volumes – AWS Amazon EC2 ステータスチェックで、アタッチされている EBS ボリュームがアクセス可能か、I/O操作を完了できるかといった状況を監視できるようになりました。この新しいステータスチェックを使用すると、EBSの障害をすばやく検出できます。 Amazon Bedrock now supports cross-region inference – AWS 単一のAPIで複数の基盤モデルを選択できる、生成AIアプリケーションのためのフルマネージドサービス Amazon Bedrock にクロスリージョン推論が追加されました。複事前に定義されているリージョンセットを利用することで、プライマリリージョンのキャパシティーが不足している際にセカンダリリージョンにリクエストをルーティングする機能です。注意点もあるので詳細は こちらのブログ をご確認ください 8/28(水) Announcing AWS Parallel Computing Service – AWS 新しいサービス AWS Parallel Computing Service (AWS PCS) が利用可能になりました。これはHPC(ハイパフォーマンスコンピューティン)領域のサービスで、多くのコンピュートノードを使った並列演算を支援します。これまでOSSで AWS ParallelCluster というHPC支援のソフトウェアを提供していましたが、これにより運用管理が楽な選択肢が追加されました。東京リージョンでも利用可能です。詳細は こちらのブログ をご覧ください。 AWS Network Firewall introduces GeoIP Filtering to inspect traffic based on geographic location – AWS AWS Network Firewall で、VPCへのトラフィックの GeoIP フィルタリングをサポートしました。この機能を使うと、特定の国から送受信されるトラフィックをブロックすることが容易に実現可能になります。 AWS announces Amazon-provided contiguous IPv4 blocks – AWS Amazon VPC IP Address Manager (IPAM) を使用して Amazon が提供する連続した IPv4 ブロック (Amazon-provided contiguous IPv4 Block)をプロビジョニングできるようになりました。パブリックIPアドレスを連続したブロックで確保することで、ネットワークの管理が容易になります。費用については、 VPCの料金ページ を確認してください。 8/29(木) Amazon Bedrock Knowledge Bases now supports Llama 3.1 405B, 70B, and 8B – AWS Amazon Bedrock Knowledge Bases は基盤モデル (FM) を社内のデータソースに安全に接続してRAGを実現することができます。今回の発表で新たに、MetaのLlama 3.1 ファミリーの基盤モデル（405B、70B、8B）が利用可能になりました。Llama 3.1はMetaの次世代最先端モデルで、128,000トークン（約96,000語、192ページの資料）のコンテキスト長をサポートしています。 Amazon OpenSearch Service now supports Graviton3 (C7g, M7g, R7g, R7gd) instances – AWS Amazon OpenSearch Service で AWS Graviton3 インスタンスがサポートされました。これにより、Graviton2 ベースのインスタンスよりも最大で25%パフォーマンスが向上します。コンピューティング最適化インスタンス (C7g)、汎用インスタンス (M7g)、およびメモリ最適化インスタンス (R7g、R7gd) から選択が可能です。詳細は こちらのブログ をご覧ください。 Announcing Validation API for AWS Step Functions – AWS AWS Step Functions でワークフロー用の新しい Validation (検証) API が利用可能になりました。Validation APIを利用することで、ワークフローのチェックを実行でき、構文エラーをより早く発見できるようになります。 8/30(金) Organizational Units in AWS Control Tower can now contain up to 1,000 accounts – AWS AWS Control Tower で、最大 1,000 のアカウントを含む組織単位 (OU) を登録できるようになりました。これまでは300が最大でした。 Amazon Redshift Serverless now supports AWS PrivateLink – AWS Amazon Redshift Serverless が AWS PrivateLink経由のアクセスをサポートしました。PrivateLinkを利用すると、クライアントからRedshift ServerlessもしくはRedshift ServerlessのAPIへのアクセスがAWSネットワーク内の経路で行われるようになり、コンプライアンス要件への対応などが可能になります。 AWS Amplify introduces new function capabilities with scheduled cron jobs and streaming logs – AWS AWS Amplify に Cron ジョブとストリーミングログが追加されました。Cron Jobs を設定することで、サーバーレス関数を特定の間隔で実行するように構成できます。一方、ストリーミングログを使用すると、関数の実行ログをリアルタイムで可視化できるためより効果的に監視およびデバッグが可能になります。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

はじめに COVID – 19 のパンデミックにより、企業は急速に変化する顧客ニーズに対応できるよう、サプライチェーン戦略を再評価する必要に迫られました。従来の一方向的なプッシュ型やプル型在庫アプローチから、顧客需要に柔軟に対応できる、より複雑で動的なモデルへと移行しています。この急速に進化する環境下で、新しい技術を迅速に実験・検証する能力が、企業が競争に勝ち抜くための必須条件となっています。 企業は、需要計画プロセスを強化し、動的な顧客ニーズに生産を合わせるため、大規模言語モデル (LLM) と機械学習 (ML) に多額の投資を行っています。AWS Supply Chain の 需要予測機能 を活用すれば、高度な ML アルゴリズムを利用して 正確な予測 行うことができます。特に、 無料利用枠 を活用することで、本格的な導入前に、ビジネスプロセスへの適用可能性と価値実証実験 (PoV) を行うことができます。 新しいサプライチェーン技術の導入や大規模な変更を行う際の一般的なアプローチは、価値実証実験 (PoV) を実施することです。PoV では、本格導入に先立ち、ソリューションの機能的実現可能性、価値、投資対効果 (ROI) を実証することができます。これには、実際の利用体験、ユーザーフィードバックの収集、潜在的な課題の特定と是正、定義された目標に対する実測、データ主導の意思決定に促進する洞察の提供が含まれます。PoV はリスク軽減、投資の正当化、ビジネス目標との整合性確保に役立ち、戦略的な意思決定と継続的な改善を可能にする際の重要な役割を果たします。 このブログ投稿では、実際の PoV に基づいた 3 つのステップのプロセスを概説し、AWS Supply Chain Demand Planning の有効なスコープ設定と PoV の実施をサポートします。以下のような一般的な質問に対応しています。 PoV (価値実証実験) とは何で、何を提供するのか? サプライチェーン管理の PoV テンプレートやフレームワークはあるのか? サプライチェーン PoV の具体例はどのようなものか? 規範的なアプローチを記述することで、他の AWS Supply Chain 機能やそれを用いたプロセスを評価するために適用できる堅牢なフレームワークを提供し、あらゆるタイプの PoV を効果的に実施するための貴重な指針となります。 PoV のスコープを適切に設定する ソリューションの機能とパフォーマンスを正確に評価できるように、PoV のスコープを適切に設定することが不可欠です。このセクションでは、PoV のスコープを設定する際の推奨手順を概説し、AWS Supply Chain Demand Planning に関する PoV を実施する食品・消費財流通業者の例を示します。 ステップ 1 : PoV の成功基準を設定する 最初のステップは、PoV の成功をどのように測定するかを決めることです。これには、評価したいプロセスとパフォーマンス指標を特定することが含まれます。例えば、食品・消費財の流通業者は需要計画を評価したいと考えていたため、業界標準の需要計画精度指標である WAPE (加重絶対パーセンテージ誤差) や MAPE (平均絶対パーセント誤差) を使用しました。 MAPE は、予測手法の精度を評価するのに広く使われる統計的な指標です。予測値と実際の値との間の絶対パーセント誤差の平均を計算し、パーセンテージで表します。MAPE が低いほど予測精度が高いことを示します。需要計画や在庫管理では、MAPE が主要業績評価指標 (KPI) として一般的に使われ、さまざまな予測モデルや手法の精度を評価・比較したり、許容できる予測誤差の目標 (業界標準は通常 10% 以下) を設定したり、時間の経過に伴う予測精度を監視して改善が必要な分野を特定するのに役立ちます。MAPE の詳細については、AWS Supply Chain が予測精度をどのように改善したかについての Amazon Pharmacy の 事例 をご覧ください。 流通業者は、全体的なユーザー体験と、プロセスが簡素化され、処理時間と運用時間が短縮されたかどうかも評価しました。 ステップ 2 : 最適な製品ミックスを特定する 次に、PoV に含めたい製品または製品グループを特定します。これにより、さまざまな製品タイプと需要パターンにわたってソリューションの機能をうまく検証できます。価値の実証実験 (PoV) でテストする製品の選択は、解決しようとしている問題と、PoV の限界をテストする最も効果的な方法によって異なります。理想的には、PoV ですべての製品をカバーし、さまざまな製品と製品の組み合わせに全体の需要計画の有効性をテストできます。ただし、この方法では時間がかかり、多くのリソースを必要とし、複雑さが増します。より実用的で実現可能なアプローチは、製品をより小さなサブセットにグループ化することです。このサブセットは、利益率への寄与度、販売/消費率、またはこれらの要因の組み合わせなどの要因に基づくことができます。より大きなデータセットをテストするよりも、より小さなデータセットをテストする方が効果的で素早く実施できます。 この食品・消費財流通業者のお客様は、利益率と在庫回転率に基づいて製品を区分しました。彼らは以下の製品グループから PoV テストのサブセットを作成しました。 利益の 60 – 75% を占める高利益率の高回転商品 利益の 10 – 15% を占める中回転の低利益率商品 低回転または低速度の商品 ステップ 3 : 正しい在庫ロケーションを特定する PoV に含めたい在庫ロケーション、例えば配送センター、倉庫、流通拠点、店舗を決定します。ビジネスボリューム (高、中、低) 、オペレーショナルな重要性 (ティア A の顧客、ティア B の顧客をカバーするなど)、ステップ 2 で特定された製品ミックスなどの要因に基づいて、1～3 か所のロケーションを選ぶことをお勧めします。別の検討すべき変数は、顧客層の階層構造で、ボリュームやビジネスの重要性に基づいて広範な顧客層 (例えばティア A、ティア B) を分類している場合に有用です。お勧めのアプローチは、現在のビジネスプロセスの管理方法に基づいて PoV をモデル化することです。例えば、需要計画担当者が顧客クラスターごとに予測数値を調整している場合は、そのレベルでモデル化するのが適切でしょう。 これらの手順に従えば、ビジネスニーズに基づいて機能とパフォーマンスを正確に評価できるよう、PoV の範囲を効果的に設定できます。 結論と次のステップ 適切な範囲の PoV を実施することは、組織が新しいサプライチェーン技術やプロセスを本格的に導入する前に、その実現可能性と価値を検証するために不可欠です。本ブログ投稿で概説した 3 ステップのプロセスは、実際の顧客の PoV に基づいた規範的なアプローチを提供し、企業が AWS Supply Chain Demand Planning の機能とパフォーマンスを自社の特定の要件に照らして正確に評価できるようにしています。明確な成功基準を設定し、最適な製品ミックスを特定し、適切な在庫拠点を選択することで、組織はリスクを軽減し、投資を正当化し、ビジネス目標との整合性を確保することができます。この体系的なアプローチは、情報に基づいた意思決定を促進するだけでなく、急速に進化するサプライチェーン環境において競争優位性を確保し、継続的な改善への道を開くことにもなります。 AWS Supply Chain を始めるのは簡単で、事前のライセンス料や長期契約は必要ありません。以下の 3 ステップで始められます。 AWS Supply Chain について学ぶ: AWS Supply Chain の ウェブサイト を訪れ、製品の機能と能力を理解する。 技術的な概要を知る: AWS Workshop Studio でセルフペースの技術的なウォークスルーを探索する。インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成方法を学ぶ。 AWS Supply Chain を使い始める: 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデータ主導の管理ツールを使って、サプライチェーン運用を合理化する。詳細な設定手順と追加のガイダンスについては、 ユーザーガイド にアクセスできる。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は 17 年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン 500 企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。Vikram はノースダラス地域を拠点としています。 <!-- '"` -->

みなさん、こんにちは。アマゾン ウェブ サービス ジャパンのソリューションアーキテクト志村です。今回は 9 月 26 日 (木) に開催する AWS Innovate の情報をお届けします！ 2021 年以降、年に数回テーマを設けて開催している AWS Innovate 。2024 年 9 月 26 日に、モダナイゼーションにフォーカスした、 AWS Innovate – Migrate. Modernize. Build . を開催します。今話題の生成 AI をはじめとする最新テクノロジーを活用して組織やシステムをモダナイズしていくことは、ビジネス価値を生み出す前提条件です。今回は、モダナイゼーションの重要な側面である、「インフラ」「アプリ」「データと組織」の 3 つの切り口で、「最新のモダナイズ手法とそれを支えるテクノロジーを学ぶ」をテーマに、全 29 セッションをお届けします。これには、昨今、多くのお客様の課題となっている メインフレームや Db2、SAP、VMware といった既存の環境からのモダナイゼーションに関するベストプラクティス、コンテナ・サーバーレス・開発支援機能を活用したモダンアプリケーションの開発・運用プロセス、またデータの民主化を実現してビジネス価値につなげるためのやり方などが含まれます。AWS エキスパートのセッションに加え、実際にモダナイゼーションに取り組まれているお客様による事例紹介、またモダナイゼーションを加速するための生成 AI の活用方法についてもご紹介します。 モダナイゼーションで目指すべきもの DX (デジタルトランスフォーメーション) をはじめとしたモダナイゼーションに関わるキーワードが、一般的になってきています。この記事を読まれている皆さまも、デジタル技術を活用して自社の業務を変革したい、既存のシステムをより良いものにしたいと考えていらっしゃるのではないかと思います。こうした文脈において「モダナイゼーション」という言葉は非常に幅広い意味で使われていますが、モダナイゼーションの定義とその目的についてはどのようにお考えでしょうか？ これに対して単一の回答はおそらく存在しないと思いますが、「社会の変化に合わせてすばやく価値を提供し続けるために、組織やシステムを常に新しくしていく」ことが、間違いなく答えの一つとして挙げられます。昨今、社会の動きは非常に目まぐるしくなっていますし、生成 AI をはじめとした新しい技術によって人々の生活も大きく変わってきています。こうした変化へどのように迅速に適応していくかについて、重要性が増してきている状況です。ここでいう変化は単に IT システムだけの話にとどまらず、組織の構成やビジネスプロセスなども含まれます。 一つ例を挙げましょう。カメラにおけるアナログからデジタルへの変化です。従来のアナログカメラは、たとえば 100 枚のショットを現場で撮って、現像して、うまく撮れていなければ再度準備をし、もう一度現場で撮り直す必要がありました。しかしデジタルカメラの登場により、フィルム交換の必要なく、それこそ 10000 枚以上のショットを連続で撮ることができるようになりました。また現像の必要なく、撮った写真をその場で確認してベストショットを選び、さらに生成 AI を用いた加工処理で品質を高めることもできます。単にアナログからデジタルにテクノロジーが変わっただけでなく、その裏側には業務プロセスそのものの変化があり、それらが総合的に意思決定の加速化といったビジネス成果をもたらしているわけです。私たちは、こうした変化への適応を「モダナイゼーション」になぞらえることができると考えます。 モダナイゼーションの実践における課題 さてモダナイゼーションによって変化への適応を進めていこうといったところで、いざ実践となると、さまざまな壁があると思います。先ほどの例でみたように、変化への適応には新たなテクノロジーの活用だけでなく、組織のあり方やビジネスプロセスの見直しまでが含まれます。 たとえば以下のような点でお困りではないでしょうか？ オンプレミスの古い IT 環境で多くのシステムが塩漬けになっているままの状態が続いており、最新のインフラ環境を活用するといったことがまったくできていない。またこれらをどう移行していけばいいのかがわからない アプリケーションチームと IT 基盤チームが分断されており、アプリケーション側の要件を IT 基盤に反映させること、また逆に IT 基盤側の変更にアプリケーション側が対応することに時間を要する データが各部署に散在しており、サイロ化されている。部署ごとに取り組みをしていても、部署横断でのデータ活用ができておらず、仕組みもない こうした課題に対応していくためには、既存の仕組みをモダナイズするためのベストプラクティスを知ることが非常に大事です。AWS をご活用いただいている多くのお客さまがモダナイゼーションにすでに取り組まれており、具体的なツールの活用や実践方法などの知見が蓄積されています。またマネージドサービスや生成 AI を含む AWS の包括的なテクノロジーを活用することで、モダナイズを加速することも可能です。 AWS Innovate – Migrate. Modernize. Build. では、こうしたモダナイゼーションにおけるさまざまなベストプラクティスを、テーマごとにまとめました。次に見どころをご紹介します。 セッションと見どころの紹介 オープニングセッション まずオープニングセッションでは、ビジネスの差別化につなげていくためのモダナイズの目指すべき姿についてお話しします。さらにそのために必要な要素を整理してご説明した上で、それらを支える AWS のテクノロジーについてご紹介します。モダナイゼーションの全体像を知りたい方におすすめの内容となっています。 ブレイクアウトセッション ブレイクアウトセッションでは 3 つのトラックをご用意しました。 1 つ目は「インフラモダナイズ」をテーマに、メインフレームや Db2、SAP、VMware といった既存の環境からのモダナイゼーションに関するベストプラクティスを、生成 AI を含む具体的なテクノロジーの活用や進め方、コスト削減効果などとあわせてご紹介します。また、近鉄情報システム様によるメインフレームからクラウドへの移行、三菱電機様による IoT ソリューション開発組織での生成 AI 活用、リクルート様によるプラットフォームエンジニアリングに関するセッションをお届けします。 2 つ目は「アプリモダナイズ」というテーマで、モダンな開発プロセス・環境を目指している方に、次の日からすぐに活かしていただける内容をご紹介します。具体的には Web / モバイル領域からバックエンドサービス領域までのアプリケーションのモダンな開発プロセス・環境に寄与するテクノロジー群として、コンテナサービス、サーバーレス、開発支援機能を中心としたセッションをお届けします。また、山梨中央銀行様の内製化のお取り組み、ソフトバンク様のサーバーレスを活用したオンラインストアサービス向上のための施策、MonotaRO 様によるマイクロサービス化に向けたドメインモデリングといった実践例も必見です。 3 つ目は「データと組織のモダナイズ」というテーマで、生成 AI やさまざまな分析テクノロジーを活用して、データからインサイトを得てビジネス価値に繋げていくためのセッション、データの民主化に向けたデータガバナンスや、データパイプラインのような堅牢かつスケーラブルな基盤の構築にフォーカスしたセッションをご用意しました。さらに、カシオ計算機様によるデータドリブンでのビジネス変革の推進、マクロミル様によるCRM/CX 支援事業の課題解決方法、ビットバンク様による意思決定を高度化するためのモダンデータ基盤構築事例のご紹介も行います。 以上のように、テクノロジーのみならず人・組織やプロセスを含む幅広い観点からの、さまざまなベストプラクティスやお客さまによるお取り組みの事例をお届けします。皆さまの多くが困っていらっしゃるポイントや、モダナイゼーションを加速するための具体的な手法をお伝えし、持ち帰って実践いただけるコンテンツを取り揃えてお待ちしています。 当日のアジェンダはこちらです。 タイムテーブルを PDF で見る AWS Innovate – Migrate. Modernize. Build. をより楽しむために 最後になりますが、このブログを読んで興味を持っていただいた方は、ぜひ イベントページ からご登録ください。もちろん当日に視聴していただくことでも十分に楽しんでいただける内容ですが、興味のあるセッションがすでにある場合は、ぜひ実際に AWS のコンソール からサービスを立ち上げて触ってみていただけると、当日の理解が深まると思います。 さらに当日はライブ Q&amp;Aを実施し、みなさんからの質問をお待ちしています。この機会を活用して AWS への質問、不明点の解消などにお役立てください。 詳細・お申込みは こちら から みなさまのご参加をお待ちしています。 – ソリューションアーキテクト 志村

本ブログは「 Hardening the RAG chatbot architecture powered by Amazon Bedrock: Blueprint for secure design and anti-pattern mitigation 」を翻訳したものとなります。 本ブログでは、 Amazon Bedrock を詳細なセキュリティ計画とともに使用して、安全で責任あるチャットボットアプリケーションをデプロイする方法を示しています。また、アプリケーションで大規模言語モデル (LLM) を公開する際に発生する可能性のある一般的なセキュリティリスクとアンチパターンを特定します。Amazon Bedrock には、脆弱性を軽減し、安全な設計の原則を取り入れるために使用できる機能が組み込まれています。本ブログでは、LLM ベースのアプリケーションの信頼性を高めるためのアーキテクチャ上の考慮事項とベストプラクティス戦略に焦点を当てています。 Amazon Bedrock は生成 AI (人工知能) と LLM の融合を実現し、インパクトのあるチャットボットアプリケーションを作成できるようにします。機密データや知的財産を扱うテクノロジーと同様に、セキュリティを優先し、強固なセキュリティ態勢を採用することが重要です。適切な対策を講じないと、これらのアプリケーションはプロンプトインジェクション、情報の開示、モデルの悪用、規制違反などのリスクにさらされる可能性があります。これらのセキュリティ上の考慮事項に積極的に対処することで、 Amazon Bedrock 基盤モデル と生成 AI 機能を責任を持って使用できます。 チャットボットアプリケーションのユースケースは、組織が生成 AI 基盤モデル (FM) の力を利用して独自のアプリケーションを構築したいと考えているエンタープライズ環境によく見られるパターンです。これは、 生成 AI セキュリティスコーピングマトリックス の事前学習済みのモデルのカテゴリに分類されます。このスコープでは、組織は Amazon Bedrock API を介して Anthropic 社の Claude などの FM と直接統合し、カスタマーサポート、検索拡張生成 (RAG) チャットボット、コンテンツ生成ツール、意思決定支援システムなどのカスタムアプリケーションを作成します。 本ブログでは、Amazon Bedrock と統合するチャットボットアプリケーションをデプロイするための包括的なセキュリティブループリントを紹介します。これにより、エンタープライズ環境で LLM と生成 AI を責任を持って運用できるようになります。LLM と生成 AI 機能を統合する際の課題に合わせた安全な設計の原則、アーキテクチャ上の考慮事項、ベストプラクティスを通じて、緩和戦略の概要を説明します。 本ブログのガイダンスに従うことで、Amazon Bedrock と統合され、生成 AI モデルを使用するチャットボットアプリケーションのデプロイと運用に関連するリスクを積極的に特定して軽減できます。このガイダンスは、セキュリティ態勢の強化、機密データや知的財産の保護、規制コンプライアンスの維持、エンタープライズ環境への生成 AI 機能を責任を持ってデプロイするのに役立ちます。 本ブログには、次の大まかなセクションが含まれています。 チャットボットアプリケーションアーキテクチャの概要 包括的なロギングおよびモニタリング戦略 セキュリティアンチパターンと緩和戦略 アンチパターン 1: 安全な認証とアクセス制御の欠如 アンチパターン 2: 不十分な入力のサニタイズとバリデーション アンチパターン 3: 安全でない通信チャネル アンチパターン 4: 不適切なロギング、監査、否認防止 アンチパターン 5: 安全でないデータストレージとアクセス制御 アンチパターン 6: FM と生成 AIコンポーネントの安全性の欠如 アンチパターン 7: 責任ある AI ガバナンスと倫理の欠如 アンチパターン 8: 包括的なテストと検証の欠如 アンチパターンの一般的な緩和戦略 安全で責任あるアーキテクチャブループリント チャットボットアプリケーションアーキテクチャの概要 本ブログで説明するチャットボットのアプリケーションアーキテクチャは、さまざまな AWS サービスを使用し、Amazon Bedrock および Anthropic 社の Claude 3 Sonnet LLM と統合する実装例を示しています。このベースラインアーキテクチャは、コアコンポーネントとその相互作用を理解するための基礎となります。ただし、お客様が Amazon Bedrock と統合するチャットボットアーキテクチャを設計および実装するには、お客様固有の要件や制約に応じて複数の方法があることに注意してください。実装のアプローチにかかわらず、生成 AI アプリケーションの安全な設計とデプロイには、適切なセキュリティコントロールを組み込み、ベストプラクティスに従うことが重要です。 チャットボットアプリケーションを使用すると、ユーザーはフロントエンドインターフェースを介して対話し、プロンプトやクエリを送信できます。これらのプロンプトは、Amazon Bedrock と統合することで処理され、Anthropic 社の Claude 3 Sonnet LLM と取り込まれたデータから構築されたナレッジベースを使用します。LLM は、プロンプトとナレッジベースから取得したコンテキストに基づいて、関連する応答を生成します。このベースライン実装では中核となる機能を概説していますが、生成 AI アプリケーションの導入に関連する潜在的なリスクを軽減するには、セキュリティコントロールを組み込み、ベストプラクティスに従う必要があります。以降のセクションでは、このようなアプリケーションで発生する可能性のあるセキュリティアンチパターンと、それに対応する緩和戦略について説明します。さらに、Amazon Bedrock を搭載したチャットボットアプリケーションの安全で責任あるアーキテクチャブループリントも提示します。 図 1: AWS サービスと Amazon Bedrock を使用したベースラインチャットボットアプリケーションアーキテクチャ チャットボットアプリケーションベースラインアーキテクチャのコンポーネント チャットボットアプリケーションアーキテクチャは、さまざまな AWS サービスを使用し、Amazon Bedrock サービスおよび Anthropic 社の Claude 3 Sonnet LLM と統合して、インタラクティブでインテリジェントなチャットボット体験を提供します。このアーキテクチャの主なコンポーネント (図 1 参照) は次のとおりです。 ユーザーインタラクションレイヤー: ユーザーは、 Streamlit フロントエンド(3)を通してチャットボットアプリケーションとやり取りします。Streamlitは、Python ベースのオープンソースライブラリで、ユーザーフレンドリーでインタラクティブなインターフェースを構築するために使用されています Amazon Elastic Container Service (Amazon ECS) on AWS Fargate : フルマネージドでスケーラブルなコンテナオーケストレーションサービスで、サーバーのプロビジョニングと管理が不要になり、基盤となるコンピューティングインフラストラクチャを管理しなくてもコンテナ化されたアプリケーションを実行できます アプリケーションのホスティングとデプロイ: Streamlit アプリケーション (3) のコンポーネントは AWS Fargate (2) 上の Amazon ECS にホストおよびデプロイされ、スケーラビリティと高可用性を維持しています。このアーキテクチャは、独立した仮想プライベートクラウド (VPC) 内のアプリケーションとホスティング環境を表し、疎結合アーキテクチャを促進します。Streamlit フロントエンドは組織固有のフロントエンドに置き換えることができ、VPC のバックエンド Amazon API Gateway とすばやく統合できます。アプリケーションロードバランサーは、Streamlit アプリケーションインスタンスにトラフィックを分散するために使用されます API Gateway 駆動での Lambda との統合: このサンプルアーキテクチャでは、フロントエンドから Amazon Bedrock サービスを直接呼び出す代わりに、 AWS Lambda 関数 (5) をバックエンドとした API Gateway が中間レイヤーとして使用されます。このアプローチは、フロントエンドからの直接的な露出を制限することで、懸念事項を分離し、スケーラビリティ、Amazon Bedrock への安全なアクセスを促進します Lambda: Lambda は、拡張性の高い短期的なサーバーレスコンピューティングを提供します。ここで、Streamlit からのリクエストが処理されます。まず、ユーザーのセッションの履歴が Amazon DynamoDB (6) から取得されます。次に、ユーザーの質問、履歴、コンテキストがプロンプトテンプレートにフォーマットされ、検索拡張生成 (RAG) を使用してナレッジベースで Amazon Bedrock に対してクエリされます DynamoDB: DynamoDB は、Lambda 関数を使用してチャット履歴、会話履歴、推奨事項、およびその他の関連データを保存および取得します Amazon S3: Amazon Simple Storage Services (Amazon S3) はデータストレージサービスで、ここではナレッジベースに取り込まれたデータアーティファクトを保存するために使用されます Amazon Bedrock: Amazon Bedrock はアーキテクチャにおいて中心的な役割を果たしています。Anthropic 社の Claude 3 Sonnet LLM (9) と、顧客の組織固有のデータから事前に生成された ナレッジベース (10) を組み合わせてユーザーから寄せられた質問を処理します Anthropic 社の Claude 3 Sonnet: Anthropic 社の Claude 3 Sonnet は、ユーザーの入力とナレッジベースから取得したコンテキストに基づいて、カスタマイズされた推奨事項と回答を生成するために使用される LLM です。これは Amazon Bedrock のテキスト分析および生成モジュールの一部です ナレッジベースとデータの取り込み: パブリックとして分類された関連ドキュメントは、Amazon S3 (9) から Amazon Bedrock ナレッジベースに取り込まれます。ナレッジベースは Amazon OpenSearch Service がバックエンドになっています。 Amazon Titan Embeddings (10) を使用して、ドキュメントのベクトルエンベディングデータベースが生成されます。データをベクトルエンベディングとして保存すると、ドキュメントの セマンティック検索や類似検索 が可能になり、ユーザーが提起した質問のコンテキストを取得できます (RAG)。質問に加えてコンテキストを LLM に提供することで、LLM から有用な回答を得る可能性がはるかに高くなります。 包括的なロギングおよびモニタリング戦略 このセクションでは、Amazon Bedrock を搭載したチャットボットアプリケーションの包括的なロギングおよびモニタリング戦略の概要を説明します。さまざまな AWS サービスを使用して、セキュリティイベント、パフォーマンスメトリックス、および潜在的な脅威の一元的なロギング、監査、およびプロアクティブなモニタリングを可能にします。 ロギングと監査: AWS CloudTrail : InvokeModel リクエストを含む Amazon Bedrock に対して行われた API 呼び出しと、リクエストを行ったユーザーまたはサービスに関する情報を記録します AWS CloudWatch&nbsp;Logs : Amazon Bedrock の呼び出しログ、ユーザープロンプト、生成されたレスポンス、呼び出しプロセス中に発生したエラーまたは警告をキャプチャして分析します Amazon OpenSearch Service : OpenSearch の統合、コンテキストデータの取得、ナレッジベースのオペレーションに関連するデータをログ記録し、またインデックス化します AWS Config : IAM ポリシー、VPC 設定、暗号化キー管理、その他のリソース設定を含む、チャットボットアプリケーションと Amazon Bedrock サービスに関連するリソースの設定をモニタリングおよび監査します モニタリングとアラート: AWS CloudWatch: モデル呼び出しの数、呼び出しのレイテンシー、エラーメトリクス (クライアント側のエラー、サーバー側のエラー、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングします。Bedrock の呼び出しとパフォーマンスに関連する異常や問題を事前に検出して対応できるように、対象を絞った CloudWatch アラームを設定します AWS GuardDuty : CloudTrail のログを継続的にモニタリングして、AWS 環境内の潜在的な脅威や不正なアクティビティがないかどうかを確認します AWS Security Hub : セキュリティポスチャ管理とコンプライアンスチェックを一元化します Amazon Security Lake : ログ分析のための一元化されたデータレイクを提供します。CloudTrail およびSecurity Hub と統合されています セキュリティ情報とイベント管理の統合: セキュリティ情報およびイベント管理 (SIEM) ソリューションと統合することで、ログの一元管理、セキュリティイベントのリアルタイムモニタリング、複数のソース (CloudTrail、CloudWatch Logs、OpenSearch Service など) からのロギングデータの関連付けを行うことができます 継続的な改善: 新たな脅威、アプリケーション要件の変化、または進化するベストプラクティスに対処するために、ロギングとモニタリングの設定、アラートの閾値、セキュリティソリューションとの統合を定期的に見直して更新します セキュリティアンチパターンと緩和戦略 このセクションでは、Amazon Bedrock チャットボットアプリケーションアーキテクチャに関連する一般的なセキュリティ上のアンチパターンを特定して説明します。開発段階とデプロイ段階の早い段階でこれらのアンチパターンを認識することで、効果的な緩和戦略を実施し、セキュリティ態勢を強化することができます。 Amazon Bedrock チャットボットアプリケーションアーキテクチャのセキュリティアンチパターンに対処することが重要である理由はいくつかあります。 データ保護とプライバシー: チャットボットアプリケーションは、個人情報、知的財産、ビジネス上の機密データなどのセンシティブなデータを処理して生成します。セキュリティアンチパターンに対処しないと、データ侵害、不正アクセス、および潜在的な規制違反につながる可能性があります モデルの完全性と信頼性: チャットボットアプリケーションの脆弱性により、不正なアクターが基盤となる生成 AI モデルを操作または悪用できるようになり、生成された出力の完全性と信頼性が損なわれる可能性があります。これは、特に意思決定の支援や重要なアプリケーションにおいて、深刻な結果をもたらす可能性があります 責任ある AI の導入: 生成 AI モデルの運用が増え続ける中、責任ある倫理的な導入のプラクティスを維持することが不可欠です。AI モデルを利用したチャットボットアプリケーションの信頼性、透明性、説明責任を維持するには、セキュリティアンチパターンに対処することが不可欠です コンプライアンスおよび規制要件: 多くの業界や地域には、AI 技術の使用、データプライバシー、情報セキュリティに関する特定の規制やガイドラインがあります。セキュリティアンチパターンに対処することは、チャットボットアプリケーションのコンプライアンスを順守し維持するための重要なステップです 本ブログで取り上げるセキュリティアンチパターンには次のものがあります。 安全な認証とアクセス制御の欠如 不十分な入力のサニタイズとバリデーション 安全でない通信チャネル 不適切なロギング、監査、否認防止 安全でないデータストレージとアクセス制御 FM と生成 AIコンポーネントの安全性の欠如 責任ある AI ガバナンスと倫理の欠如 包括的なテストと検証の欠如 アンチパターン 1: 安全な認証とアクセス制御の欠如 Amazon Bedrock を使用する生成 AI チャットボットアプリケーションでは、安全な認証とアクセス制御がないと、システムの機密性、完全性、可用性に重大なリスクが生じます。ID スプーフィングや不正アクセスにより、脅威アクターが正当なユーザーやシステムになりすましたり、チャットボットアプリケーションで処理された機密データに不正にアクセスしたり、アプリケーションで使用される顧客のデータや知的財産の完全性と機密性を侵害したりする可能性があります。 チャットボットアプリケーションは、機密情報や知的財産を含む可能性のあるユーザーのプロンプトや応答を処理するため、ID スプーフィングと不正アクセスはこのアーキテクチャで対処すべき重要な領域です。脅威アクターが正当なユーザーまたはシステムになりすますことができれば、悪意のあるプロンプトを挿入したり、ナレッジベースから機密データを取得したり、Amazon Bedrock と統合された Anthropic Claude 3 LLM によって生成された応答を操作したりする可能性があります。 アンチパターンの例 Streamlit のフロントエンドインターフェースまたは API Gateway エンドポイントを適切な認証メカニズムなしで公開すると、認証されていないユーザーがチャットボットアプリケーションと対話し、悪意のあるプロンプトを挿入できる可能性があります AWS アクセスキーまたは API 認証情報をアプリケーションコードまたは設定ファイルに保存またはハードコーディングすると、認証情報が公開されたり、Amazon Bedrock や DynamoDB などの AWS サービスへの不正アクセスのリスクが高まります Amazon Bedrock サービスやその他の重要なコンポーネントにアクセスするための上位権限を持つ管理者アカウントまたはサービスアカウントに、弱い、または推測しやすいパスワードを実装します AWS Identity and Access Management (IAM) ユーザーまたは権限のあるロールには多要素認証 (MFA) がないため、認証情報が漏洩した場合に Amazon Bedrock サービスを含む AWS リソースへの不正アクセスのリスクが高まります 緩和戦略 安全な認証とアクセス制御の欠如に関連するリスクを軽減するには、堅牢な IAM コントロールのほか、継続的なロギング、モニタリング、脅威検出メカニズムを実装してください。 IAM コントロール: OAuth 2.0 や OpenID Connect などの業界標準のプロトコルを使用し、 AWS IAM Identity Center やその他のアイデンティティプロバイダーと統合することで、Streamlit フロントエンドインターフェースと AWS API Gateway エンドポイントの認証と認可を一元的に行うことができます AWS IAM ポリシーとリソースベースのポリシー を使用してきめ細かなアクセス制御を実装し、必要な Amazon Bedrock リソース、Lambda 関数、およびチャットボットアプリケーションに必要なその他のコンポーネントのみへのアクセスを制限します Amazon Bedrock、DynamoDB、Streamlit アプリケーションなどの重要なコンポーネントにアクセスできるすべての IAM ユーザー、ロール、およびサービスアカウントに MFA の使用を強制します 継続的なロギングとモニタリング、脅威の検出: 一元的なロギングおよびモニタリングソリューションの実装に関するガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。またチャットボットアプリケーションコンポーネントと Amazon Bedrock サービス全体にわたる認証イベント、アクセス試行、潜在的な不正アクセスまたは認証情報の不正使用を追跡および監査するとともに、CloudWatch、Lambda、GuardDuty を使用して異常な動作や潜在的な脅威を検出して対応します アンチパターン 2: 不十分な入力のサニタイズとバリデーション 生成 AI チャットボットアプリケーションの入力バリデーションとサニタイズが不十分だと、インジェクションイベント、データ改ざん、敵対的イベント、データ汚染イベントなど、さまざまな脅威にシステムがさらされる可能性があります。これらの脆弱性は、不正アクセス、データ改ざん、モデル出力の侵害につながる可能性があります。 インジェクションイベント: ユーザーのプロンプトや入力が適切にサニタイズおよびバリデーションされていない場合、脅威アクターは SQL コードなどの悪意のあるコードを注入して、DynamoDB チャット履歴データへの不正アクセスや操作を引き起こす可能性があります。さらに、チャットボットアプリケーションまたはコンポーネントが適切なバリデーションなしにユーザー入力を処理すると、脅威アクターがバックエンドシステムに任意のコードを注入して実行し、アプリケーション全体を危険にさらす可能性があります データ改ざん: 脅威アクターは、チャットボットインターフェースと Amazon Bedrock サービスの間で送信されるユーザープロンプトやペイロードを変更し、意図しないモデル応答やアクションを引き起こす可能性があります。データの完全性チェックを行わないと、脅威アクターが Amazon Bedrock と OpenSearch の間で交換されるコンテキストデータを改ざんし、LLM の応答に影響する誤った検索結果や悪意のある検索結果につながる可能性があります データ汚染イベント: LLM またはチャットボットアプリケーションで使用されるトレーニングデータまたはコンテキストデータが適切にバリデーションおよびサニタイズされていない場合、不正なアクターが悪意のあるデータや誤解を招くデータを導入し、偏ったモデル出力や侵害されたモデル出力につながる可能性があります アンチパターンの例 Amazon Bedrock に送信する前にユーザープロンプトのバリデーションとサニタイズに失敗すると、インジェクションイベントが発生したり、意図しないデータ漏洩が発生したりする可能性があります OpenSearch から取得したコンテキストデータの入力バリデーションとサニタイズが行われていないため、不正なデータや悪意のあるデータが LLM の応答に影響を与える可能性があります LLM が生成した応答をユーザーに表示する前にサニタイズが不十分なため、コードインジェクションや有害なコンテンツのレンダリングが発生する可能性があります Streamlit アプリケーションまたは Lambda 関数でのユーザー入力の不適切なサニタイズにより、特殊文字、コードスニペット、または潜在的に悪意のあるパターンを削除またはエスケープできず、コードインジェクションイベントが発生する可能性があります LLM またはチャットボットアプリケーションで使用されるトレーニングデータやその他のデータソースの検証とサニタイズが不十分なため、データ汚染イベントが発生し、悪意のあるデータや誤解を招くデータが取り込まれ、偏ったモデル出力や侵害されたモデル出力につながる可能性があります ユーザープロンプトやデータ入力に無制限の文字セット、入力長、特殊文字を使用できるようにすることで、攻撃者が入力バリデーションやサニタイズのメカニズムを迂回する入力を作成できるようになり、望ましくない出力や悪意のある出力が発生する可能性があります 入力のバリデーションは拒否リストのみに頼っているため、攻撃者はこれをすばやく回避できるため、インジェクションイベント、データ改ざん、その他の悪用シナリオにつながる可能性があります 緩和戦略 不十分な入力のサニタイズとバリデーションに関連するリスクを軽減するには、チャットボットアプリケーションとそのコンポーネント全体に堅牢な入力バリデーションとサニタイズのメカニズムを実装してください。 入力のバリデーションとサニタイズ: チャットボットインターフェースと Amazon Bedrock サービスの境界でユーザープロンプトの厳格な入力バリデーションルールを実装し、許可される文字セットと最大入力長を定義し、特殊文字やコードスニペットを禁止します。 Amazon Bedrock のガードレール 機能を使用すると、拒否トピックとコンテンツフィルタを定義して、アプリケーションとのユーザー操作から望ましくない有害なコンテンツを削除できます より堅牢で包括的なアプローチを維持するには、入力バリデーションに拒否リストの代わりに許可リストを使用してください 特殊文字、コードスニペット、または潜在的に悪質なパターンを削除またはエスケープすることで、ユーザー入力をサニタイズします データフロー検証: 以下を含むコンポーネント間のデータフローの検証とサニタイズを行います FM に送信されたユーザープロンプトと、FM によって生成されてチャットボットインターフェースに返された応答 FM またはチャットボットアプリケーションで使用されるトレーニングデータ、コンテキストデータ、およびその他のデータソース 保護コントロール: AWS WAF を使用して、入力のバリデーションと一般的なウェブエクスプロイトから保護します AWS Shield を使用して、分散型サービス拒否 (DDoS) イベントから保護します CloudTrail を使用して、InvokeModel リクエストを含む Amazon Bedrock への API 呼び出しをモニタリングできます CloudTrail ログを分析し、アプリケーションログ、ユーザープロンプト、応答を取り込み、インシデントレスポンスや SIEM ソリューションとの統合を行うための Lambda 関数、 Amazon EventBridge ルール、CloudWatch Logs の実装に関するガイダンスについては、包括的なロギングおよびモニタリング戦略のセクションをご覧ください。入力のバリデーションとサニタイズ、ジェイルブレイクの試行や異常な動作に関連するセキュリティインシデントの検出、調査、緩和に役立ちます アンチパターン 3: 安全でない通信チャネル チャットボットアプリケーションコンポーネント間の安全でない通信チャネルは、機密データを傍受、改ざん、不正アクセスのリスクにさらす可能性があります。セキュリティで保護されていないチャネルでは、攻撃者が送信中のデータ (ユーザープロンプト、応答、コンテキストデータなど) を傍受して変更する中間者イベントが発生し、データの改ざん、悪意のあるペイロードの注入、不正な情報アクセスにつながります。 アンチパターンの例 VPC 内の安全なサービス間通信のために AWS PrivateLink を使用しないと、HTTPS を使用している場合でも、Amazon Bedrock と他の AWS サービスとの間の通信がパブリックインターネットを介した潜在的なリスクにさらされます コンポーネント間の転送中のデータ改ざんを検出および防止するためのデータ完全性チェックまたはメカニズムがない 新たな脅威に対処し、セキュリティのベストプラクティスに準拠していることを確認するために、通信チャネルの構成、プロトコル、および暗号化メカニズムを定期的に見直して更新していない 緩和戦略 安全でない通信チャネルに関連するリスクを軽減するには、安全な通信メカニズムを実装し、チャットボットアプリケーションのコンポーネントとその相互作用全体でデータの完全性を強化する必要があります。転送中の機密データを保護し、不正アクセス、データ改ざん、中間者攻撃を防ぐために、適切な暗号化、認証、および完全性チェックを実施する必要があります。 安全な通信チャネル: PrivateLink を使用すると、Amazon Bedrock とチャットボットアプリケーションアーキテクチャで使用される他の AWS サービスとの間の安全なサービス間通信が可能になります。PrivateLink は、Amazon VPC 内にプライベートで分離された通信チャネルを提供するため、パブリックインターネットを経由する必要がありません。これにより、HTTPS を使用している場合でも、サービス間で送信される機密データへの傍受、改ざん、または不正アクセスの可能性が軽減されます AWS Certificate Manager (ACM) を使用して、チャットボットのフロントエンドインターフェース (Streamlit アプリケーション) と API Gateway エンドポイント間の安全な通信に使用される SSL/TLS 証明書のデプロイを管理および自動化します。ACM は SSL/TLS 証明書のプロビジョニング、更新、デプロイを簡素化し、ユーザー向けコンポーネントとバックエンド API 間の通信チャネルが、業界標準のプロトコルと最新の証明書を使用して安全に暗号化されるようにします 継続的なロギングとモニタリング: 潜在的な通信チャネルの異常やセキュリティインシデントを検出して対応するための一元的なロギングおよびモニタリングメカニズムの実装に関するガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。これには CloudWatch、CloudTrail、AWS WAF などの AWS サービスを使用して、通信チャネルメトリクス、API 呼び出しパターン、リクエストペイロード、およびレスポンスデータをモニタリングすることも含まれます ネットワークのセグメンテーションと分離のコントロール: 専用の VPC とサブネット内に Amazon ECS クラスターをデプロイし、他のコンポーネントから分離し、最小権限の原則に基づいて通信を制限することにより、ネットワークセグメンテーションを実装します パブリック向けのフロントエンド層とバックエンドアプリケーション層用に VPC 内に個別のサブネットを作成し、コンポーネントをさらに分離します AWS セキュリティグループとネットワークアクセスコントロールリスト (NACL) を使用して、ECS クラスターとフロントエンドインスタンスのインバウンドトラフィックとアウトバウンドトラフィックをそれぞれインスタンスレベルとサブネットレベルで制御します アンチパターン 4: 不適切なロギング、監査、否認防止 生成 AI チャットボットアプリケーションのロギング、監査、否認防止のメカニズムが不十分だと、説明責任の欠如、フォレンジック分析の課題、コンプライアンス上の懸念など、さまざまなリスクにつながる可能性があります。適切なロギングと監査がなければ、ユーザーアクティビティの追跡、問題の診断、セキュリティインシデントの際のフォレンジック分析の実施、規制や内部ポリシーの遵守の証明が困難になります。 アンチパターンの例 Amazon Bedrock に送信されたユーザープロンプト、OpenSearch と交換されるコンテキストデータ、LLM からの応答など、コンポーネント間のデータフローのログ記録が不足しているため、セキュリティインシデントやデータ侵害が発生した場合の調査が妨げられます チャットボットアプリケーション内のユーザーアクティビティ(ログイン試行、セッション時間、実行されたアクションなど) のロギングが不十分なため、特定のユーザーを追跡してアクションを関連付ける機能が制限されます ログに記録されたデータの完全性と信頼性を保証するメカニズムがないため、記録されたイベントが改ざんされたり否認されたりする可能性があります ログデータを安全に保管し、不正アクセスや改ざんから保護できないため、ログ情報の信頼性と機密性が損なわれます 緩和戦略 不適切なロギング、監査、否認防止に関連するリスクを軽減するには、包括的なロギングおよび監査メカニズムを実装して、チャットボットアプリケーションコンポーネント全体の重大なイベント、ユーザーアクティビティ、およびデータフローをキャプチャします。さらに、ログデータの完全性と信頼性を維持し、改ざんや否認を防止し、ログ情報を安全に保管して不正アクセスから保護するための対策を講じる必要があります。 包括的なロギングと監査: CloudTrail、CloudWatch Logs、OpenSearch Service を使用してロギングメカニズムを実装するための詳細なガイダンスについては、「包括的なロギングとモニタリングの戦略」セクションを参照してください。また、CloudTrail を使用して API 呼び出し、特に Amazon Bedrock API の呼び出しや AWS 環境内のその他の API アクティビティのロギングとモニタリングを行います。CloudWatch を使用して Amazon Bedrock 固有のメトリックスをモニタリングします。また、CloudTrail ログファイルの整合性検証機能と Amazon S3 に保存されているログデータの S3 オブジェクトロックと S3 バージョニングの実装により、ログデータの完全性と否認防止を確保します 保存中の暗号化には AWS Key Management Service (AWS KMS) を使用し、ログデータへのアクセスを制御するための制限的な IAM ポリシーとリソースベースのポリシーを実装することで、ログデータが安全に保存され、不正アクセスから保護されていることを確認してください CloudTrail ログファイルの整合性検証と CloudWatch Logs の保持期間とデータアーカイブ機能を使用して、コンプライアンス要件に基づいて適切な期間ログデータを保持します ユーザーアクティビティのモニタリングと追跡: CloudTrail を使用して API 呼び出し、特に Amazon Bedrock API 呼び出しや AWS 環境内のその他の API アクティビティ (API Gateway、Lambda、DynamoDB など) のロギングとモニタリングを行います。さらに、CloudWatch を使用して、モデル呼び出しの数、レイテンシー、エラーメトリックス (クライアント側のエラー、サーバー側のエラー、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングできます セキュリティ情報およびイベント管理 (SIEM) ソリューションと統合して、一元的なログ管理とセキュリティイベントのリアルタイムモニタリングを行います データの完全性と否認防止: デジタル署名または否認防止メカニズムを実装して、記録されたデータの完全性と信頼性を検証し、記録されたイベントの改ざんや否認を最小限に抑えます。CloudTrail ログファイルの整合性検証機能を使用すると、業界標準のアルゴリズム (ハッシュには SHA-256、デジタル署名には SHA-256、デジタル署名には SHA-256 と RSA) を使用して否認防止を行い、ログデータの整合性を検証できます。Amazon S3 に保存されているログデータについては、S3 オブジェクトロックと S3 バージョニングを有効にし、変更不可能な Write Once Read Many (WORM) データストレージモデルを実現することで、オブジェクトの削除や変更を防ぎ、データの完全性と否認防止を維持できます。さらに、S3 バケットポリシーと IAM ポリシーを実装して、S3 に保存されているログデータへのアクセスを制限することで、ログに記録されたイベントのセキュリティと否認防止をさらに強化します アンチパターン 5: 安全でないデータストレージとアクセス制御 生成 AI チャットボットアプリケーションにおける安全でないデータストレージとアクセス制御は、情報開示、データ改ざん、不正アクセスなどの重大なリスクにつながる可能性があります。チャット履歴などの機密データを暗号化されていない、または安全でない方法で保存すると、データストアが侵害されたり、権限のないエンティティによってアクセスされた場合に情報漏えいが発生する可能性があります。さらに、適切なアクセス制御が行われていないと、権限のない第三者がデータにアクセス、変更、または削除できるようになり、データが改ざんされたり、不正アクセスされたりする可能性があります。 アンチパターンの例 AWS KMS カスタマー管理キー (CMK) を使用してチャット履歴データを暗号化せずに DynamoDB に保存します OpenSearch、Amazon S3、または機密データを処理するその他のコンポーネントのデータに対する、AWS KMS の CMK を使用した保存時の暗号化の不足 DynamoDB のチャット履歴、OpenSearch、Amazon S3、またはその他のデータストアに対する過度に寛容なアクセス制御や、きめ細かなアクセス制御メカニズムの欠如により、不正アクセスやデータ侵害のリスクが高まります 機密データをクリアテキストで保存するか、安全でない暗号化アルゴリズムや鍵管理手法を使用する 潜在的なセキュリティの脆弱性やアクセス要件の変更に対処するために、暗号化キーを定期的に確認してローテーションしたり、アクセス制御ポリシーを更新したりしていない 緩和戦略 安全でないデータストレージとアクセス制御に関連するリスクを軽減するには、強固な暗号化メカニズム、安全な鍵管理手法、きめ細かなアクセス制御ポリシーを実装してください。保存中および転送中の機密データを暗号化し、AWS KMS のお客様が管理する暗号化キーを使用し、IAM ポリシーとリソースベースのポリシーに基づいて最小権限のアクセス制御を実装することで、チャットボットアプリケーションアーキテクチャ内のデータのセキュリティと保護を大幅に強化できます。 保存時の鍵管理と暗号化: AWS KMS を実装して、DynamoDB、OpenSearch、Amazon S3 などのコンポーネント間のデータ暗号化のための CMK へのアクセスを管理および制御します CMK を使用して、保存中のチャット履歴データを自動的に暗号化するように DynamoDB を設定します OpenSearch と Amazon S3 が、これらのサービスに保存されているデータについて AWS KMS CMK で保存時に暗号化を使用するように設定します CMK ではセキュリティと制御が強化され、暗号化キーの作成、ローテーション、無効化、取り消しが可能になり、キーの分離と職務の分離が容易になります CMK を使用すると、キーポリシーを適用したり、キーの使用状況を監査したり、顧客による暗号化キーの管理を義務付ける規制要件や組織のポリシーを順守したりできます CMK は移植性が高く、特定のサービスから独立しているため、暗号化キーの管理を維持しながら、複数のサービス間でデータを移行または統合できます AWS KMS は、一元化された安全なキー管理ソリューションを提供し、さまざまなコンポーネントやサービスにわたる暗号化キーの管理と監査を簡素化します 以下を含む安全な鍵管理手法を実装します 暗号化されたデータのセキュリティを維持するための定期的なキーローテーション 特定の個人が主要な管理業務を完全に制御できないようにするための職務分離 キー管理操作の厳格なアクセス制御。IAM ポリシーとロールを使用して最小権限の原則を適用します きめ細かなアクセス制御: IAM ポリシーとロールを使用して、DynamoDB チャット履歴データストア、OpenSearch、Amazon S3、およびその他のデータストアへのきめ細かなアクセス制御を実装します DynamoDB チャット履歴データストア、OpenSearch、Amazon S3、その他のデータストアやサービスなど、機密データを処理するすべてのリソースに対して、きめ細かなアクセス制御を実装し、最小権限のアクセスポリシーを定義します。たとえば、IAM ポリシーとリソースベースのポリシーを使用して、特定の DynamoDB テーブル、OpenSearch ドメイン、S3 バケットへのアクセスを制限し、最小権限の原則に基づいて必要なアクション (読み取り、書き込み、一覧表示など) のみへのアクセスを制限します。このアプローチをチャットボットアプリケーションアーキテクチャ内の機密データを処理するすべてのリソースに拡張し、各コンポーネントまたはユーザーロールに最低限必要なリソースとアクションにのみアクセスが付与されるようにします 継続的な改善: 潜在的なセキュリティの脆弱性やアクセス要件の変更に対処するために、暗号化構成、アクセス制御ポリシー、およびキー管理方法を定期的に見直して更新してください アンチパターン 6: FM と生成 AI コンポーネントの安全性の欠如 チャットボットアプリケーションの FM や生成 AI コンポーネントに対するセキュリティ対策が不十分だと、モデルの改ざん、意図しない情報開示、サービス拒否などの深刻なリスクにつながる可能性があります。脅威アクターは、セキュリティで保護されていない FM や生成 AI モデルを操作して、偏った、有害な、または悪意のある応答を生成し、重大な損害や評判の低下を引き起こす可能性があります。 適切なアクセス制御や入力バリデーションを行わないと、意図しない情報漏えいが発生し、機密データが誤ってモデル応答に含まれてしまう可能性があります。さらに、安全でない FM または生成 AI コンポーネントは、サービス拒否イベントに対して脆弱であり、チャットボットアプリケーションの可用性を妨げ、その機能に影響を与える可能性があります。 アンチパターンの例 信頼できないデータソースや侵害されたデータソースを使用するなど、安全でないモデルのファインチューニング手法は、偏ったモデルや悪意のあるモデルにつながる可能性があります FM および生成 AI コンポーネントを継続的にモニタリングできないため、新たな脅威や既知の脆弱性に対して脆弱なままになっています FM や生成 AI コンポーネントの出力を制御およびフィルタリングするためのガードレールや安全対策がないため、有害な、偏った、または望ましくないコンテンツが生成される可能性があります FM コンポーネントに送信されるプロンプトやコンテキストデータのアクセス制御や入力バリデーションが不十分なため、インジェクションイベントや意図しない情報開示のリスクが高まります 安全な通信チャネル、モデルアーティファクトの暗号化、アクセス制御など、FM および生成 AI コンポーネントの安全なデプロイプラクティスの実装の欠如 緩和戦略 保護が不十分な FM と生成 AI コンポーネントに関連するリスクを軽減するには、安全な統合メカニズム、堅牢なモデルのファインチューニングとデプロイ手法、継続的なモニタリング、効果的なガードレールと安全対策を実施する必要があります。これらの緩和戦略は、チャットボットアプリケーションの生成 AI 機能のセキュリティ、信頼性、倫理的な整合性を確保しながら、モデルの改ざん、意図しない情報開示、サービス拒否イベント、有害または望ましくないコンテンツの生成を防ぐのに役立ちます。 LLM とナレッジベースとの安全な統合: Amazon Bedrock、OpenSearch、および FM コンポーネント間に安全な通信チャネル (HTTPS や PrivateLink など) を実装して、不正アクセスやデータ改ざんを防止してください インジェクションイベントや意図しない情報漏洩を防ぐために、FM コンポーネントに送信されるプロンプトとコンテキストデータには厳格な入力バリデーションとサニタイズを実装してください OpenSearch と統合するためにアクセス制御と最小権限の原則を実装して、LLM コンポーネントがアクセスできるデータを制限します 安全なモデルのファインチューニング、デプロイ、モニタリング: 信頼できる検証済みのデータソースを使用して、安全で監査可能なファインチューニングパイプラインを確立し、改ざんやバイアスの導入を防止します アクセス制御、安全な通信チャネル、モデルアーティファクトの暗号化など、FM および生成 AI コンポーネントの安全なデプロイプラクティスを実装します FM および生成 AI コンポーネントを継続的にモニタリングして、セキュリティの脆弱性、パフォーマンスの問題、意図しない動作がないかどうかを確認します レート制限、スロットリング、および負荷分散メカニズムを実装して、FM および生成 AI コンポーネントでのサービス拒否イベントを防止します セキュリティポリシー、業界のベストプラクティス、規制要件への準拠について、FM と生成 AI コンポーネントを定期的に見直し、監査します ガードレールと安全対策 ガードレールを導入しましょう。ガードレールとは、有害なアウトプットを減らし、FM や生成 AI コンポーネントの動作を人間の価値と調和させることを目的とした安全対策です キーワードベースのフィルタリング、メトリックベースのしきい値、人的モニタリング、各アプリケーションドメインの特定のリスクと文化的および倫理的規範に合わせたカスタマイズされたガードレールを使用してください パフォーマンスベンチマークと敵対的テストを通じてガードレールの有効性をモニタリングします ジェイルブレイクに対する堅牢性テスト ジェイルブレイクに対する堅牢制テストを実施してください。様々な禁止シナリオにわたる多様なジェイルブレイクを LLM および生成 AI コンポーネントにプロンプトを与えて試行し、脆弱性を特定してモデルの堅牢性を高めます アンチパターン 7: 責任ある AI ガバナンスと倫理の欠如 これまでのアンチパターンは技術的なセキュリティ面に焦点を当てていましたが、生成 AI システムの倫理的かつ責任あるガバナンスに取り組むことも同様に重要です。強力なガバナンスの枠組み、倫理的ガイドライン、アカウンタビリティ対策がなければ、チャットボットアプリケーションは意図しない結果や偏った結果、透明性と信頼性の欠如につながる可能性があります。 アンチパターンの例 生成 AI チャットボットアプリケーションの責任ある開発とデプロイを導く原則、ポリシー、プロセスを含む、確立された倫理的なAI ガバナンスフレームワークの欠如 LLM と生成 AI コンポーネントの透明性、説明可能性、解釈可能性を確保するための対策が不十分なため、意思決定プロセスの理解と監査が困難になっています 利害関係者の関与、公的な協議、社会的影響の考慮のためのメカニズムがないため、チャットボットアプリケーションに対する信頼が失われ受け入れられなくなる可能性があります 生成 AI システムのトレーニングデータ、モデル、または出力における潜在的なバイアス、差別、または不公平に対処できない チャットボットアプリケーションの倫理的行動や組織の価値観や社会規範との整合性をテスト、検証、継続的なモニタリングを行うためのプロセスが不十分 緩和戦略 責任ある AI ガバナンスと倫理の欠如を最小限に抑えるために、包括的な倫理的 AI ガバナンスの枠組みを確立し、透明性と解釈可能性を促進し、利害関係者を関与させて社会的影響を考慮し、潜在的なバイアスや公平性の問題に対処し、継続的な改善とモニタリングプロセスを実施し、ガードレールと安全対策を講じます。これらの緩和戦略は、生成 AI チャットボットアプリケーションの開発と導入における信頼、説明責任、倫理的連携を促進するのに役立ち、意図しない結果、偏った結果、透明性の欠如などのリスクを軽減します。 倫理的な AI ガバナンスの枠組み: 生成 AI チャットボットアプリケーションの責任ある開発とデプロイを導くための原則、ポリシー、プロセスを含む、倫理的な AI ガバナンスの枠組みを確立します 潜在的な倫理的ジレンマ、バイアス、または意図しない結果に対処するための明確な倫理ガイドラインと意思決定の枠組みを定義します チャットボットアプリケーションの倫理的な開発とデプロイを監督するために、指定された倫理委員会、倫理責任者、外部諮問委員会などのアカウンタビリティ措置を実施します 透明性と解釈可能性: LLM と生成 AI コンポーネントの透明性と解釈可能性を促進するための対策を実施し、意思決定プロセスの監査と理解を可能にする。 チャットボットアプリケーションの機能、制限、潜在的なバイアスや倫理的考慮事項について、利害関係者やユーザーに明確でアクセスしやすい情報を提供します 利害関係者の関与と社会的影響: 利害関係者の関与、公的な協議、社会的影響の考慮のためのメカニズムを確立し、チャットボットアプリケーションの信頼と受け入れを促進します 影響評価を実施して、個人、地域社会、または社会に対する潜在的な悪影響またはリスクを特定し、軽減する バイアスと公平性: 厳格なテスト、バイアスの軽減手法、継続的なモニタリングを通じて、生成 AIシステムのトレーニングデータ、モデル、または出力における潜在的なバイアス、差別、または不公平に対処します 潜在的なバイアスや盲点を減らすために、開発、テスト、ガバナンスのプロセスにおいて多様性と包括性のある表現を促進します 継続的な改善とモニタリング: チャットボットアプリケーションの動作と組織の価値観や社会規範との整合性を継続的にテスト、検証、モニタリングするためのプロセスを実装します 新たな倫理的課題、社会的期待、規制の進展に対応するために、AI ガバナンスの枠組み、ポリシー、プロセスを定期的に見直し、更新します ガードレールと安全対策: (訳者注: 日本語でアプリケーションを利用される場合、ユーザーガイドを参照の上日本語がサポートされているか事前にご確認下さい) Guardrails for Amazon Bedrock などのガードレールを導入します。これは、有害なアウトプットを減らし、LLM や生成 AI コンポーネントの動作を人間の価値観や責任ある AI ポリシーと一致させることを目的とした安全対策です Guardrails for Amazon Bedrock を使用して拒否トピックを定義し、コンテンツフィルターを使用してユーザーとアプリケーション間のやり取りから望ましくない有害なコンテンツを削除します 自然言語による説明を使用して拒否トピックを定義し、アプリケーションのコンテキストでは望ましくないトピックや主題分野を指定します コンテンツフィルターを設定して、ユースケースと責任ある AI ポリシーに基づいて、ヘイト、侮辱、セクシャリティ、暴力などのカテゴリーにわたって有害なコンテンツをフィルタリングするための閾値を設定します 個人識別情報 (PII) リダクション機能を使用して、LLM が生成した応答から名前、電子メールアドレス、電話番号などの情報をリダクションしたり、PII を含むユーザー入力をブロックします Guardrails for Amazon Bedrock を CloudWatch と統合して、定義されたポリシーに違反するユーザー入力と LLM レスポンスをモニタリングおよび分析することで、潜在的な問題を事前に検出して対応できるようになります パフォーマンスベンチマークと敵対的テストを通じてガードレールの有効性をモニタリングし、実際の使用状況や新たな倫理的考慮事項に基づいてガードレールの改良と更新を継続的に行います ジェイルブレイクに対する堅牢性テスト: ジェイルブレイクに対する堅牢制テストを実施してください。様々な禁止シナリオにわたる多様なジェイルブレイクを LLM および生成 AI コンポーネントにプロンプトを与えて試行し、脆弱性を特定してモデルの堅牢性を高めます アンチパターン 8: 包括的なテストと検証の欠如 LLM システムと生成 AI チャットボットアプリケーションのテストと検証プロセスが不十分だと、未確認の脆弱性、パフォーマンスのボトルネック、可用性の問題が発生する可能性があります。包括的なテストと検証を行わないと、組織はアプリケーションを本番環境にデプロイする前に、潜在的なセキュリティリスク、機能上のギャップ、スケーラビリティとパフォーマンスの制限を検出できない可能性があります。 アンチパターンの例 LLM の応答の正確性と完全性、およびチャットボットアプリケーションの特徴と機能を検証するための機能テストが不足しています さまざまな負荷条件下でのボトルネック、リソースの制約、またはスケーラビリティの制限を特定するためのパフォーマンステストが不十分です 潜在的なセキュリティの脆弱性やモデルの悪用を発見するための侵入テスト、脆弱性スキャン、敵対的テストなどのセキュリティテストが行われていません 自動化されたテストと検証のプロセスを継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインに組み込めないと、手動で 1 回限りのテスト作業が行われ、重大な問題を見落とす可能性があります Amazon Bedrock、OpenSearch、DynamoDB などの外部サービスやコンポーネントとのチャットボットアプリケーションの統合のテストが不十分であると、互換性の問題やデータ完全性の問題が発生する可能性があります 緩和戦略 包括的なテストと検証の欠如に対処するには、機能テスト、パフォーマンステスト、セキュリティテスト、および統合テストを含む強固なテスト戦略を実装する必要があります。自動テストを CI/CD パイプラインに統合し、脅威モデリングや侵入テストなどのセキュリティテストを実施し、敵対的検証手法を使用します。テストプロセスを継続的に改善して、生成 AI チャットボットアプリケーションの信頼性、セキュリティ、スケーラビリティを検証します。 包括的なテスト戦略: LLM システムとチャットボットアプリケーション全体の機能テスト、パフォーマンステスト、負荷テスト、セキュリティテスト、統合テストを含む包括的なテスト戦略を確立します アプリケーションの機能要件と非機能要件、およびセキュリティとコンプライアンス基準に基づいて、明確なテスト要件、テストケース、および承認基準を定義します 自動化されたテストと CI/CD 統合: 自動化されたテストと検証プロセスを CI/CD パイプラインに組み込むことで、LLM のパフォーマンス、セキュリティ、信頼性をライフサイクル全体にわたって継続的にモニタリングおよび評価できます 自動化されたテストツールとフレームワークを使用して、テストプロセスを合理化し、テストカバレッジを向上させ、回帰テストを容易にします セキュリティテストと敵対的検証: 潜在的なセキュリティリスクと脆弱性を事前に特定するために、設計プロセスの早い段階で、チャットボットアプリケーションアーキテクチャの設計が完成したらすぐに脅威モデリング演習を実施してください。その後、侵入テスト、脆弱性スキャン、敵対的テストを含む定期的なセキュリティテストを実施して、特定されたセキュリティの脆弱性やモデルエクスプロイトを発見して検証します 敵対的な検証手法を実装し、モデルの堅牢制とセキュリティを向上させます。これには、LLM に対して弱点や脆弱性を明らかにするように慎重に作成された入力をプロンプトとして与えることが含まれます パフォーマンスと負荷テスト: パフォーマンスと負荷を包括的にテストして、さまざまな負荷条件下で発生する可能性のあるボトルネック、リソースの制約、またはスケーラビリティの制限を特定します 負荷の生成、ストレステスト、キャパシティプランニングのためのツールとテクニックを使用して、チャットボットアプリケーションが予想されるユーザートラフィックとワークロードを処理できることを確認します 統合テスト: 徹底的な統合テストを実施して、チャットボットアプリケーションと Amazon Bedrock、OpenSearch、DynamoDB などの外部サービスおよびコンポーネントとの統合を検証し、シームレスな通信とデータの完全性を維持します 継続的な改善: 新たな脅威、新たな脆弱性、またはアプリケーション要件の変化に対処するために、テストと検証のプロセスを定期的に見直し、更新してください テストの知見と結果を利用して、LLM システム、チャットボットアプリケーション、および全体的なセキュリティ態勢を継続的に改善してください すべてのアンチパターンに共通の緩和戦略 LLM と生成 AI コンポーネントのセキュリティ対策、アクセス制御、モニタリングメカニズム、ガードレールを定期的に見直し、更新して、新たな脅威、脆弱性、進化する責任ある AI のベストプラクティスに対処します 定期的なセキュリティ評価、侵入テスト、およびコードレビューを実施して、ロギング、監査、および否認防止メカニズムに関連する脆弱性または設定ミスを特定して修正します 生成 AI アプリケーションのロギング、監査、否認防止に関するセキュリティのベストプラクティス、ガイダンス、および AWS や業界団体からの最新情報を常に把握してください 安全で責任あるアーキテクチャブループリント ベースラインとなるチャットボットアプリケーションアーキテクチャについて説明し、Amazon Bedrock を使用して構築された生成 AI アプリケーションに関連する重要なセキュリティアンチパターンを特定したので、安全で責任あるアーキテクチャブループリントを紹介します。このブループリント (図 2) には、アンチパターン分析全体を通して説明した推奨される緩和戦略とセキュリティコントロールが組み込まれています。 図 2: 安全で責任ある生成 AI チャットボットのアーキテクチャブループリント このターゲットステートアーキテクチャでは、認証されていないユーザーがフロントエンドインターフェース (1) を介してチャットボットアプリケーションと対話します。この場合、安全なコーディングプラクティスと入力バリデーションを実装することで、不十分な入力バリデーションとサニタイズというアンチパターンを軽減することが重要です。その後、ユーザー入力は、それぞれ DDoS 対策、Web アプリケーションファイアウォール機能、コンテンツ配信ネットワークを提供する AWS Shield、AWS WAF、CloudFront (2) を介して処理されます。これらのサービスは、入力バリデーションに AWS WAF を使用し、定期的なセキュリティテストを実施することで、不十分な入力バリデーション、ウェブエクスプロイト、および包括的なテストの欠如を軽減するのに役立ちます。 その後、ユーザーのリクエストは API Gateway (3) を介してルーティングされます。API Gateway (3) は、チャットボットアプリケーションのエントリポイントとして機能し、Streamlit フロントエンドへの API 接続を容易にします。認証、安全でない通信、LLM セキュリティに関連するアンチパターンに対処するには、API Gateway 内に安全な認証プロトコル、HTTPS/TLS、アクセス制御、入力バリデーションを実装することが不可欠です。VPC 内のリソースと API Gateway 間の通信は、VPC エンドポイント (4) を介して保護されます。PrivateLink を使用して安全なプライベート通信を行い、エンドポイントポリシーをアタッチしてどの AWS プリンシパルが API Gateway サービスにアクセスできるかを制御し (8)、安全でない通信チャネルのアンチパターンを軽減します。 Streamlit アプリケーション (5) は、VPC 内のプライベートサブネットにある Amazon ECS でホストされています。フロントエンドインターフェースをホストし、入力の検証とサニタイズが不十分にならないように、安全なコーディング手法と入力バリデーションを実装する必要があります。その後、ユーザー入力は VPC 内でホストされるサーバーレスコンピューティングサービスである Lambda (6) によって処理され、VPC エンドポイント (7) を介して Amazon Bedrock、OpenSearch、および DynamoDB に接続します。これらの VPC エンドポイントには、アクセスを制御するエンドポイントポリシーがアタッチされているため、Lambda 関数とサービス間の安全なプライベート通信が可能になり、安全でない通信チャネルのアンチパターンが軽減されます。Lambda では、入力バリデーションのアンチパターンに対処するために、厳格な入力バリデーションルール、許可リスト、ユーザー入力のサニタイズを実装しています。 ユーザーからのチャットボットアプリケーションのリクエストは、生成 AI ソリューションの Amazon Bedrock (12) に送信され、LLM の機能を提供します。FM と生成 AI コンポーネントの安全性を確保できないアンチパターンを緩和するために、Amazon Bedrock とのやり取りの際には、安全な通信チャンネル、入力のバリデーション、プロンプトとコンテキストデータのサニタイズを実装する必要があります。 Amazon Bedrock は、Amazon Bedrock ナレッジベースを使用して OpenSearch Service (9) とやり取りし、ユーザーの質問に関連するコンテキストデータを取得します。ナレッジベースは Amazon S3 (10) から公開ドキュメントを取り込むことによって作成されます。安全でないデータストレージとアクセス制御のアンチパターンを軽減するには、AWS KMS と OpenSearch Service 内のアクセス制御用のきめ細かい IAM ポリシーとロールを使用して保管時の暗号化を実装してください。Titan エンベディング (11) は、ベクトルエンベディング形式で Amazon S3 に保存されているドキュメントを表します。ベクトル形式により、類似度の計算と関連情報の検索が可能になります (12)。FM および生成 AI コンポーネントのセキュリティ対策が不十分なアンチパターンに対処するため、Titan エンベディングとの安全な統合と入力データのバリデーションを実装する必要があります。 ナレッジベースデータ、ユーザープロンプト、およびコンテキストデータは、Amazon Bedrock (13) と Claude 3 LLM(14) によって処理されます。生成 AI コンポーネントの安全性の欠如、責任ある AI ガバナンスと倫理の欠如といったアンチパターンに対処するため、安全な通信チャンネル、入力バリデーション、倫理的な AI ガバナンスフレームワーク、透明性と解釈可能性の対策、ステークホルダーの関与、バイアスの緩和戦略、および Guardrails for Amazon Bedrock のようなガードレールを実装する必要があります。 生成された応答と推奨事項は、Lambda 関数によって Amazon DynamoDB (15) に保存および取得されます。安全でないデータストレージとアクセスを軽減するには、保存中のデータを AWS KMS (16) で暗号化し、IAM ポリシーとロールによるきめ細かなアクセス制御を実装します。 ロギング、監査、モニタリングの包括的なメカニズムが CloudTrail (17)、CloudWatch (18)、AWS Config (19) により提供され、不適切なロギング、監査、および否認防止のアンチパターンに対処します。包括的なロギング、監査、およびモニタリングメカニズムの実装の詳細なガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。これには、Amazon Bedrock サービスに対して行われた API 呼び出しのロギング、Amazon Bedrock 固有のメトリクスのモニタリング、Bedrock 呼び出しログの記録と分析、およびチャットボットアプリケーションと Amazon Bedrock サービスに関連するリソースの構成のモニタリングと監査が含まれます。 IAM (20) は、アーキテクチャ全体において、また認証や安全でないデータの保存とアクセスに関連するアンチパターンの緩和において重要な役割を果たします。IAM ロールや IAM ポリシーは、チャットボットアプリケーションのさまざまなコンポーネントにわたる安全な認証メカニズム、最小権限によるアクセス、多要素認証、および堅牢な認証情報の管理を実施する上で重要です。さらに、Amazon Bedrock 内の特定のモデルやナレッジベースへのアクセスを制限するようにサービスコントロールポリシー (SCP) を設定して、機密性の高い知的財産への不正アクセスや使用を防ぐことができます。 最後に、チャットボットアプリケーションのセキュリティ態勢をさらに強化するための推奨サービスとして、GuardDuty (21)、 Amazon Inspector (22)、Security Hub (23)、および Security Lake (24) が追加されています。GuardDuty (21) はコントロールプレーンとデータプレーン全体で脅威を検出し、Amazon Inspector (22) は Amazon ECS および Lambda ワークロードの脆弱性評価と継続的なモニタリングを可能にします。Security Hub (23) はセキュリティポスチャ管理とコンプライアンスチェックを一元化し、Security Lake (24) はログ分析のための一元化されたデータレイクとして機能し、CloudTrail および Security Hub と統合されています。 結論 重要なアンチパターンを特定し、包括的な緩和戦略を提供することで、企業環境に生成 AIテクノロジーを安全かつ責任を持って導入するための強固な基盤が得られます。 本ブログで紹介する安全で責任あるアーキテクチャブループリントは、強固なセキュリティ、データ保護、倫理的ガバナンスを確保しながら、生成 AI の力を活用したい組織向けの包括的なガイドとなります。このブループリントは、安全な認証メカニズム、暗号化されたデータストレージ、きめ細かなアクセス制御、安全な通信チャネル、入力のバリデーションとサニタイズ、包括的なロギングと監査、安全な FM の統合とモニタリング、責任ある AI ガードレールなど、業界をリードするセキュリティコントロールを組み込むことで、生成 AI アプリケーションに関連する固有の課題と脆弱性に対処します。 さらに、包括的なテストと検証プロセスに重点を置き、倫理的な AI ガバナンスの原則を組み込むことで、潜在的なリスクを軽減できるだけでなく、潜在的なバイアスに対処し、組織の価値観や社会規範との整合性を確保しながら、LLM コンポーネントの透明性、説明可能性、解釈可能性を高めることができます。 本ブログで概説され、アーキテクチャブループリントに示されているガイダンスに従うことで、潜在的なリスクを積極的に特定して軽減し、生成 AI ベースのチャットボットソリューションのセキュリティ態勢を強化し、機密データや知的財産を保護し、規制コンプライアンスを維持し、責任を持って企業環境に LLM と生成 AI テクノロジーを導入することができます。 本ブログについて質問がある場合は、 AWS サポートにお問い合わせください 。 Magesh Dhanasekaran Magesh は AWS のセキュリティアーキテクトです。オーストラリアと米国の金融機関や政府機関に情報セキュリティコンサルティングサービスを提供した実績があります。Magesh は、クラウドセキュリティアーキテクチャ、デジタルトランスフォーメーション、安全なアプリケーション開発の実践における経験を活かして、AWS 製品とサービスに関するセキュリティアドバイスを提供しています。彼は現在、複数の業界認定資格を取得しています。 Amy Tipple Amy はプロフェッショナルサービスのデータ・機械学習チームのシニアデータサイエンティストで、AWS に約 4 年間在籍しています。エイミーは、生成 AI に関するいくつかの取り組みに携わっており、生成 AI 関連のセキュリティを AWS ユーザーが利用しやすく理解しやすいものにすることを推進しています。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

8月28日、 AWS Parallel Computing Service (AWS PCS) が発表されました。これは、お客様による ハイパフォーマンスコンピューティング (HPC) クラスターのセットアップおよび管理をサポートし、AWS で事実上あらゆるスケールでシームレスにシミュレーションを実行できるようにする、新しいマネージドサービスです。 Slurm スケジューラを使用すると、使い慣れた HPC 環境で作業できるため、インフラストラクチャについて心配することなく、結果が出るまでの時間を短縮できます。 2018 年 11 月、弊社は AWS がサポートするオープンソースクラスター管理ツール、 AWS ParallelCluster を発表しました。これは、AWS クラウドでの HPC クラスターのデプロイと管理に役立つツールです。AWS ParallelCluster を使用すると、お客様は概念実証や本稼働の HPC コンピューティング環境を迅速に構築およびデプロイすることもできます。また、 AWS ParallelCluster コマンドラインインターフェイス 、 API 、 Python ライブラリ 、オープンソースパッケージからインストールされたユーザーインターフェイスを使用できます。これらは、クラスターの解体や再デプロイを含む更新の責任を負います。しかし、多くのお客様は、HPC 環境の構築と運用における作業を削減したいと考え、フルマネージド型の AWS サービスを求めていました。 AWS PCS は、AWS が管理する HPC 環境を簡素化します。また、 AWS マネジメントコンソール 、AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) からアクセスすることが可能です。システム管理者は、コンピューティングとストレージの設定、ID、ジョブ割り当て設定を使用するマネージド Slurm クラスターを作成できます。AWS PCS は、シミュレーションのスケジューリングとオーケストレーションに、さまざまな HPC のお客様に使用されている拡張性と耐障害性に優れたジョブスケジューラ、Slurm を使用しています。科学者、研究者、エンジニアなどのエンドユーザーは、AWS PCS クラスターにログインして、HPC ジョブの実行と管理、仮想デスクトップでのインタラクティブソフトウェアの使用、データへのアクセスを行うことができます。コードの移植に多大な労力を費やすことなく、ワークロードをすばやく AWS PCS に持ち込めます。 フルマネージドの NICE DCV リモートデスクトップを使用してリモートで視覚化したり、ジョブテレメトリやアプリケーションログにアクセスしてスペシャリストが HPC ワークフローを 1 か所で管理できるようにしたりできます。 AWS PCS は、シミュレーションと計算を準備、実行、分析するための使い慣れた方法を使用して、数値流体力学、気象モデリング、有限要素解析、電子設計自動化、貯留層シミュレーションなどの分野にわたり、従来型と新型、コンピューティング集約型またはデータ集約型の幅広いエンジニアリングおよび科学ワークロードに対処できるよう設計されています。 AWS Parallel Computing Service の開始方法 AWS PCS を試すには、AWS ドキュメントの「 簡単なクラスターの作成に関するチュートリアル 」をご確認ください。まず、AWS PCS を試す AWS リージョンにあるアカウント内の Amazon Elastic File System (Amazon EFS) で、AWS CloudFormation テンプレートと共有ストレージを使用して、仮想プライベートクラウド (VPC) を作成します。詳細については、AWS ドキュメントの「 VPC の作成 」と「 共有ストレージの作成 」を参照してください。 1.クラスターの作成 AWS PCS コンソール で、リソースを管理しワークロードを実行するための永続的リソースである [Create cluster (クラスターを作成)] を選択します。 次にクラスター名を入力し、Slurm スケジューラのコントローラーサイズを選択します。クラスターワークロードの上限として、 [Small (小規模)] (最大 32 ノード、256 ジョブ)、 [Medium (中規模)] (最大 512 ノード、8,192 ジョブ)、または [Large (大規模)] (最大 2,048 ノード、16,384 ジョブ) を選択できます。 ネットワーキング セクションで、作成した VPC、クラスターを起動するサブネット、クラスターに適用するセキュリティグループを選択します。 オプションで、コンピューティングノードがスケールダウンするまでのアイドル時間、起動したコンピューティングノード上の Prolog および Epilog スクリプトディレクトリ、Slurm が使用するリソース選択アルゴリズムパラメータなどの Slurm 設定を設定できます。 [Create cluster (クラスターを作成)] を選択します。クラスターがプロビジョニングされるまでにはしばらく時間がかかります。 2.コンピューティングノードグループの作成 クラスターを作成した後、コンピューティングノードグループを作成できます。これは、AWS PCS がクラスターへのインタラクティブなアクセスを提供したり、クラスターでジョブを実行したりするために使用する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの仮想コレクションです。コンピューティングノードグループを定義するときは、EC2 インスタンスタイプ、最小インスタンス数と最大インスタンス数、ターゲット VPC サブネット、 Amazon マシンイメージ (AMI) 、購入オプション、カスタム起動設定などの共通特性を指定します。コンピューティングノードグループでは、 AWS Identity and Access Management (IAM) ロールを EC2 インスタンスに渡すインスタンスプロファイルと、AWS PCS が起動する EC2 インスタンスの設定に使用する EC2 起動テンプレートが必要です。詳細については、AWS ドキュメントの「 起動テンプレートの作成 」と「 インスタンスプロファイルの作成 」を参照してください。 コンソールでコンピューティングノードグループを作成するには、クラスターに移動し、 [Compute node groups (コンピューティングノードグループ)] タブと [Create compute node group (コンピューティングノードグループを作成)] ボタンを選択します。 2 種類のコンピューティングノードグループを作成できます。1 つはエンドユーザーがアクセスするログインノードグループ、もう 1 つは HPC ジョブを実行するジョブノードグループです。 HPC ジョブを実行するコンピューティングノードグループを作成するには、コンピューティングノード名を入力し、以前作成した EC2 起動テンプレート、IAM インスタンスプロファイル、クラスター VPC でコンピューティングノードを起動するサブネットを選択します。 次に、コンピューティングノードを起動するときに使用したい EC2 インスタンスタイプと、スケーリング用の最小インスタンス数および最大インスタンス数を選択します。ここでは hpc6a.48xlarge インスタンスタイプを選択し、スケールの上限を 8 インスタンスに設定しました。ログインノードでは、1 つの c6i.xlarge インスタンスなど、より小さいインスタンスを選択できます。インスタンスタイプがサポートしている場合は、 オンデマンド または スポット EC2 購入オプションを選択することも可能です。オプションで、特定の AMI を選択できます。 [Create (作成)] をクリックします。コンピューティングノードグループがプロビジョニングされるまでにはしばらく時間がかかります。詳細については、AWS ドキュメントの「 ジョブを実行するためのコンピューティングノードグループの作成 」と「ログインノード用のコンピューティングノードグループの作成 」を参照してください。 3.HPC ジョブの作成と実行 コンピューティングノードグループを作成したら、ジョブをキューに送信して実行します。利用可能なプロビジョニング済み容量に基づきコンピューティングノードグループで実行されるように AWS PCS がスケジュールするまで、ジョブはキューに残ります。各キューは、処理を行うために必要な EC2 インスタンスを提供する、1 つ以上のコンピューティングノードグループに関連付けられています。 コンソールでキューを作成するには、クラスターに移動し、 [Queues (キュー)] タブと [Create queue (キューを作成)] ボタンを選択します。 キュー名を入力し、キューに割り当てられたコンピューティングノードグループを選択します。 [Create (作成)] を選択し、キューが作成されるまで待ちます。 ログインコンピューティングノードグループがアクティブな場合、 AWS Systems Manager を使用して、作成された EC2 インスタンスに接続できます。 Amazon EC2 コンソール に移動し、ログインコンピューティングノードグループの EC2 インスタンスを選択します。詳細については、AWS ドキュメントの「 ジョブを送信および管理するためのキューの作成 」と「 クラスターへの接続 」を参照してください。 Slurm を使用してジョブを実行するには、ジョブ要件を指定する送信スクリプトを用意し、 sbatch コマンドを使用してキューに送信します。通常、これは共有ディレクトリから行われるため、ログインノードとコンピューティングノードには、ファイルにアクセスするための共通のスペースがあります。 Slurm を使用して AWS PCS でメッセージパッシングインターフェイス (MPI) ジョブを実行することもできます。詳細については、AWS ドキュメントの「 Slurm を使用した単一ノードジョブの実行 」または「 Slurm を使用したマルチノードの MPI ジョブの実行 」を参照してください。 フルマネージドの NICE DCV リモートデスクトップを接続して視覚化できます。開始するには、 AWS GitHub リポジトリの HPC レシピ にある CloudFormation テンプレートを使用してください。 この例では、 OpenFOAM MotorBike シミュレーション を使用して、オートバイとライダーの周りの定常流を計算しました。このシミュレーションは、3 つの hpc6a インスタンスの 288 コアを使用して実行されました。DCV インスタンスのウェブインターフェイスにログインした後、 ParaView セッションで出力を視覚化できます。 作成したクラスターとノードグループで HPC ジョブを実行した後、不必要な課金を避けるために、作成したリソースを削除する必要があります。詳細については、AWS ドキュメントの「 AWS リソースの削除 」を参照してください。 知っておくべきこと この機能について知っておきたい事柄には、次のようなものがあります。 Slurm バージョン – AWS PCS はもともと Slurm 23.11 をサポートしており、新しいバージョンが追加された際にお客様が Slurm のメジャーバージョンをアップグレードできるよう設計されたメカニズムを提供しています。さらに、AWS PCS はパッチバージョンを使用して Slurm コントローラーを自動的に更新するよう設計されています。詳細については、AWS ドキュメントの「 Slurm バージョン 」を参照してください。 キャパシティ予約 – オンデマンドキャパシティ予約を使用して、特定のアベイラビリティーゾーンおよび特定期間の EC2 キャパシティを予約し、必要なときに必要なコンピューティングキャパシティを確保できます。詳細については、AWS ドキュメントの「 キャパシティ予約 」を参照してください。 ネットワークファイルシステム – Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon File Cache 、Amazon EFS、Amazon FSx for Lustre など、データやファイルを書き込んだりアクセスしたりするネットワークストレージボリュームをアタッチできます。NFS サーバーなどのセルフマネージドのボリュームを使用することもできます。詳細については、AWS ドキュメントの「 ネットワークファイルシステム 」を参照してください。 今すぐご利用いただけます AWS Parallel Computing Service は、現時点で米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の各リージョンで使用可能です。 AWS PCS は AWS アカウントのすべてのリソースを起動します。また、これらのリソースに対して適切な料金が請求されます。詳細については、 AWS PCS の料金ページ を参照してください。 ぜひお試しいただき、 AWS re:Post for AWS PCS 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy P.S.HPC テスト環境の作成に寄与してくれた AWS の Principal Developer Advocate である Matthew Vaughn に感謝します。 原文は こちら です。

本ブログは株式会社 JDSC 様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。 AWS ソリューションアーキテクトの瀬高です。 日々のお客様との相談会を通して、生成 AI への注目度が高まっているのを感じる今日このごろです。その中でも、生成 AI に対して信頼できる知識ベースへの検索機能をかけ合わせた検索拡張生成、いわゆる RAG (Retrieval Augmented Generation) が業務効率化やデータの利活用方法の出口としてイメージしやすいところから人気があるように感じています。 今回ご紹介する事例は、 株式会社 JDSC 様が海運事業を取り組んでいるお客様に対し RAG を構築した事例となっています。RAG を構築するだけでなく、 Amazon Bedrock の特徴を活かしたモデルの使い分けや、専門用語に対する Claude の強さを活かし、専門的な工数の 97% を削減し、従来システムに対して 30% の精度向上を実現しています。 本取り組みは JDSC 様の NEWS にも掲載されています。合わせて御覧いただければと思います。 お客様の状況と経緯 JDSC 様は日本の産業をアップデートすることを使命とした、東京大学発の AI 企業で、機械学習などを活用した開発、運用やデータサイエンスに関するコンサルティング事業などを行っている企業となります。 エンドユーザーの社内では契約書や技術情報などの専門的なドキュメントがおよそ 1 万部ほどあり、業務に携わるメンバーはこの中やメールなどのタイムリーな情報も含めて横断的に質問に対する答えを探す必要がありました。ドキュメントの数やサイズも大きく目的の情報を探し出すまでの時間がかかる点や、属人的なノウハウが必要になっている点が課題となっており、数十秒で質問に対する答えを出せるようにしたいというニーズをお持ちでした。 また、お客様からのお問い合わせへの対応も進めていきたいという要望もあり、あらゆる情報を一元的に早く調べようとすると検索時間が多くかかる点に、ビジネス的な課題を感じられているとのことでした。 JDSC 様は RAG を構築することで、上記課題の解決を図ろうと検証を進めていました。 その中で、以下のような課題が出ていました。 ファイルサイズの大きさに伴う入出力のトークンサイズ 入力意図の誤認識や専門的な単語の認識率 禁止ワードへの過剰反応 金銭的なコストの高さ そこで、当時発表されたばかりの Anthropic 社の生成 AI モデルである Claude 3 やデータストアとなる Amazon Kendra 、 Amazon OpenSearch Service 、 Amazon RDS for PostgreSQL を Generative AI Use Case JP を参考に検証していただくことになりました。 ソリューション / 構成内容 検証の結果、下記のように Claude 3 とデータストアとして Amazon RDS for PostgreSQL を利用する構成を取ることに決定しました。 今回使用しているモデルは Claude 3.5 Sonnet と Claude 3 Haiku を利用しています。ベクトル検索の結果に含まれるドキュメントの一部が返却された際に Haiku でそれぞれ結果が役に立つかのチェックを行い精度の向上を図り、最終的なユーザーが触れるレスポンス文生成のところでは処理性能に優れる Claude 3.5 Sonnet を活用することで優れた文章表現を実現しています。 Amazon Bedrock + Claude を採用したポイントとして、プロンプトへの追従性や使い勝手、大きなトークンが扱える点、運用管理が AWS で完結する点、AWS のサポート体制などに魅力を感じてご採用いただきました。 開発当初は Claude 3 Sonnet を利用する予定でしたが、Bedrock が持つ特徴でもあるモデルの切り替えやすさを活かして Claude 3.5 Sonnet や Amazon Titan Text V2 などの当時の最新モデルを更に検証し Claude 3.5 Sonnet へスムーズにアップデートしてローンチしました。3.5 へのアップデートを行ったことで、利用者の質問に対して意図の汲み取りがよりスムーズにできるようになり顧客満足度の向上につながったと伺っています。 また、Generative AI Use Case JP についても「何から手をつけていいかわからない状態からのスタートだったが、動作するイメージがわかりやすくドキュメントも充実しているためスムーズにカスタマイズしていけた」とのコメントをいただいています。 導入効果 実際にエンドユーザーの方々に使っていただいた結果、下記のような良い結果が得られ AI の活用を更に推し進めていきたいとのご評価をいただいています。 お問い合わせの対応時間が約 97% 短縮 的確な回答を行う回答精度が 30％ 向上 回答作成をする属人的なノウハウや専門知識の必要性が下がり人材の幅が拡大 また ソリューション / 構成要素でも触れた Bedrock の持つ特徴の一つである、モデルの切り替えやすさを活かしたアーキテクチャを組んでいることで、今後出てくる新しいモデルの導入もスムーズにできる状態になっており、さらなる精度向上やコストダウンも見込まれています。 まとめ 今回は海運事業を取り組まれているエンドユーザー様向けに専門的な RAG を構築された事例をご紹介いたしました。Amazon Bedrock や Claude の特徴を活かしお客様のビジネスを加速させる取り組みをなされています。 また、移り変わりの激しい、新たにでたモデルに対しても Amazon Bedrock の特徴を活かしながらスピーディに検証していただいております。生成 AI 活用の幅が更に広がる取り組みになっているので是非ご参考いただければと思います。 構築方法など、ご不明な点があればお問い合わせいただければと思います。ぜひお試しください。 株式会社 JDSC : Technical Co-Founder 橋本 圭輔 様 (中央) Amazon Web Services Japan : アカウントマネージャー 菊地 晋哉 (左)、ソリューションアーキテクト 瀬高 拓也 (右) ソリューションアーキテクト 瀬高 拓也 (X – @stktky )

本ブログは「 Optimize data validation using AWS DMS validation-only tasks 」を翻訳したものとなります。 AWS Database Migration Service (AWS DMS) は、データを Amazon Web Services (AWS) に効率的かつセキュアに移行するのに役立ちます。Oracle や SQL Server などの広く使用されている商用データベースから、MySQL や PostgreSQL などのオープンソースデータベースにデータを移行できます。また、 AWS DMS は、 さまざまなサポートされているソース から AWS に移行する際にデータを検証する機能を提供します。データの整合性と正確性は、移行プロジェクトが成功するかどうかを左右する重要な要件の1つであり、お客様から頻繁にお伺いするポイントです。この記事では、 AWS DMS のデータ検証機能 について詳しく説明します。その利点、設定、およびユースケースを探ります。 AWS DMS によるデータ検証 AWS DMS のデータ検証機能は、ソースからターゲットへのデータ移行が正確に行われていることを確認するのに役立ちます。 AWS DMS の移行タスクで 全ロードのみ (既存データの移行) の移行タイプを選択した場合、完全ロードが完了した直後にデータ検証が開始されます。 完全ロード + CDC (既存データの移行と継続的な変更のレプリケーション) &nbsp;の移行では、完全ロードが完了した直後に検証が開始され、その後、変更データキャプチャ (CDC) による増分変更を継続的に比較します。CDC のみのタスクで検証が有効になっている場合、新しいデータの検証を開始する前に、テーブル内の既存のすべてのデータが検証されます。 データ検証中、 AWS DMS はソースの各行とターゲットの対応する行を比較し、行が同じデータを含んでいるかを確認し、不一致があればレポートします。列の値の比較方法はデータ型によって異なります。たとえば、大きなバイナリオブジェクト (LOB) 列の比較にチェックサム関数が使用されますが、他のデータ型の場合は実際の値が使用されます。 AWS DMS コンソールまたは AWS Command Line Interface (AWS CLI) を使用して、移行タスクでデータ検証機能を有効にできます。詳細については、 Migration Validation (Part 2) – Introducing Data Validation in AWS Database Migration Service を参照してください。また、移行やデータレプリケーションを実行せずに、データのプレビューと検証のみを行う 検証のみのタスク を作成できます。この検証では、ソースとターゲットの両方で追加のリソースが消費され、ネットワークリソースも追加で必要となります。また、ソースとターゲットのテーブルに主キーまたは一意のインデックスが必要です。AWS DMS 検証を使用する前に、その 制限事項 を確認することをお勧めします。 ソリューション概要 この投稿では、以下のトピックについて説明します。 AWS DMS 検証のみのタスクのユースケース(リレーショナルデータベース) AWS DMS 検証のみのタスク の構成と監視方法 検証のみのタスク: フルロードと CDC の比較 検証のみのタスクの最適化方法 検証が失敗するケースの対処方法 AWS DMS 検証のみのタスクのユースケース(リレーショナルデータベース) AWS DMS で検証のみのタスクを使用するいくつかの一般的なユースケースは次のとおりです。 データを移行せずに検証を実行する – 検証のみのタスクを使用すると、データを複製することなく、ソースとターゲットのデータを検証できます。これは、検証ルールと設定をテストするのに役立ちます。 検証を移行タスクから分離する – 個別の検証のみのタスクを作成することで、既存の移行タスクに影響を与えることなく、データを独立して検証できます。これにより、検証失敗が移行をブロックするのを防ぎ、また別のレプリケーションインスタンス (RI) で検証のみのタスクを実行することもできます。さらに、この別の RI では新機能を利用するために異なる DMS バージョンを使うこともできます。 検証失敗のトラブルシューティング – 移行タスクで検証が失敗した場合、進行中の移行タスクと分離されている検証のみのタスクを使用することで、特定の失敗を調査してトラブルシューティングしやすくなります。 スケジュールされた検証 – 検証のみのタスクを定期的に実行することで、変更されるソースとターゲットのデータを検証できます。これにより、継続的に実行されるタスクと比較してソースとターゲットデータベースインスタンスの負荷を軽減できます。 特定の時点でデータ行が一致しないことを迅速に確認する – 本番稼働切り替えを行う前または切り替えの最中にフルロードの検証のみのタスクを実行することで、新しいターゲットエンドポイントにアプリケーションを切り替える前にデータを検証できます。 データ修復スクリプト – 検証が失敗したテーブル向けのデータ修復スクリプトを作成した場合、フルロードのバリデーションのみのタスクを実行すると、スクリプトが対処可能な問題を迅速に検知できます。 AWS DMS 検証のみのタスクをどのように構成して監視するか AWS DMS コンソールを使用して検証専用のタスクを作成するには、AWS DMS タスクを作成する際に以下の設定を行います。 TargetTablePrepMode を DO_NOTHING (検証専用タスクのデフォルト) に設定します。 マイグレーションタイプを「 既存のデータを移行する 」または「 データ変更のみをレプリケートする 」に設定します。 データ検証で「 検証(データ移行なし) 」を選択します。 または、 JSON エディタを使ってタスク設定を変更することができます: "EnableValidation": true, "ValidationOnly": true, データ検証が有効になっている場合、AWS DMS コンソールまたは Amazon CloudWatch で 検証の状態 を監視できます。 テーブル内の一部のレコードがソースとターゲットで一致しない場合、検証状態は Mismatched records となり、ターゲットデータベースの awsdms_validation_failures_v1 テーブルで詳細を確認できます。このテーブルは、 ControlSchema で定義したスキーマまたはデータベースエンジンの デフォルトの場所 に作成されます。レコードが ValidationSuspended または ValidationFailed 状態になった場合、 AWS DMS は同じテーブルに診断情報を書き込みます。 次のスクリーンショットは、 PostgreSQL の例(ターゲット)を示しています。 AWS DMS データ検証の監視の詳細については、 Insights into AWS DMS resiliency and recovery scenarios with mitigations – Part 2 をご参照ください。 フルロードの検証のみ・ CDC の検証のみのタスク 前述のとおり、移行タイプには2種類あり、フルロードの検証のみのタスクと CDC の検証のみのタスクを作成できます。これら 2 種類のデータ検証プロセスと、主要なチューニング可能なパラメータについて、次のセクションで説明します。 フルロードの検証のみ AWS DMS バージョン 3.4.6 以降では、フルロードの検証のみのタスクを使用すると、ソーステーブルとターゲットテーブルのすべての行を高速に比較し、検証エラーがあればすぐに報告し、検証が完了した後にタスクを停止します。 AWS DMS はデータを論理的にパーティション(デフォルトは 1 パーティションあたり 10,000 レコード)に分割し、複数の AWS DMS データ検証スレッド(デフォルトは 5 つ)を使用して対応するパーティション間のデータを比較します。データ検証エラーがある場合、ターゲットデータベースの制御テーブル ( awsdms_control.awsdms_validation_failures_v1 ) にログが記録されます。次の図では、 Row n の列 coln の値が一致しないため、不一致レコードが報告されています。 次の表は、フルロードの検証タスクのみに関する重要なタスクパラメータを示しています。 AWS DMS のデータ検証タスクでサポートされているすべてのパラメータについては、「 データ検証タスクの設定 」を参照してください。 CDC の検証のみ CDC の検証のみのタスクが開始されると、既存のデータを最初に検証し、次に CDC によって変更されたデータを検証し、不一致があれば報告します。また、継続的にレプリケーションされた変更を再検証します。 CDC の検証では、誤検出を防ぐために、失敗する前に不一致の行を再試行します。再試行を待つ時間は、タスク設定の RecordFailureDelayLimitInMinutes および RecordSuspendDelayInMinutes パラメータで設定された失敗再試行期間(分単位)に依存します。次の図では、時刻 T1 で、 AWS DMS 検証スレッドが Row n のデータ不一致を発見します。すぐに失敗を報告するのではなく、再試行し、進行中のデータ複製タスクが問題を修正することを期待します。 次の図の時間 T2 では、まだ障害再試行期間内ですが、 AWS DMS の検証スレッドが Row n のデータを再度比較し、データが一致していることを確認したためデータ検証の失敗は報告されません。 AWS DMS の検証タスクでは、新しいデータが見つかるとそれらをパーティションに分割し、データ検証スレッドを割り当てて、データを検証します。 次の表は、CDC 検証のみのタスクの重要なタスクパラメータを示しています。これは、前述の完全ロード検証のみのタスクで説明されたパラメータに加えて考慮する必要があります。 AWS DMS データ検証タスクでサポートされているすべてのパラメータについては、「 データ検証タスクの設定 」を参照してください。 どのように AWS DMS 検証のみのタスクを最適化するか このセクションでは、 AWS DMS の検証のみのタスクのパフォーマンスを最適化できる複数の検証タスク設定について説明します。これらの設定は、本番環境で実装する前に検証環境でテストする必要があります。各検証タスクは独立しており、タスクごとに最適化が必要です。 ThreadCount : このパラメータは、 AWS DMS がデータ検証を実行する際に使用するスレッド数を指定します。デフォルトは 5 で、各スレッドは未検証のデータを処理して比較と検証を行います。より多くのスレッド数を設定すると、検証タスク全体のパフォーマンスが向上しますが、より多くのリソースがソースとターゲットのエンドポイントで消費されます。 PartitionSize : この設定は、各スレッドがソースとターゲットのインスタンスから読み取るレコード数を指定します。デフォルト値の 10,000 を増やすと、 AWS DMS が検証のためにより多くのレコードを読み取ることができますが、移行コンポーネントへの負荷が増加します。 RecordFailureDelayLimitInMinutes : このパラメータを使用すると、 AWS DMS が検証失敗を報告するまでの遅延を指定できます。通常、 AWS DMS はデータ変更がターゲットに複製されるまでの実際の遅延を許容するために、タスク待機時間の値を使用し、誤検出を防ぎます。この設定では、より高い値を定義できます。 ValidationQueryCdcDelaySeconds : これは、ソースとターゲットで最初の検証クエリが遅延する時間です。検証のみのタスクでは、デフォルト値は 180 秒です。ソースでの大量の更新により高い待機時間が発生する場合は、この値を大きくしてソースインスタンスへの再検証を減らすことができます。 FailureMaxCount : この設定は、タスクが中断される前の検証失敗の最大数を指定します。デフォルト値は 10,000 です。すべてのレコードを検証し続けたい場合は、この値をソーステーブルのレコード数より大きな値に設定します。一方、データの不一致を許容できない場合は、失敗が発生したときにタスクが迅速に中断されるように、より小さな値を使用できます。これにより、より厳格なデータ整合性チェックが行われます。 HandleCollationDiff : このオプションは、列の照合順序 (Collation) の違いがどのように処理されるかを制御します。デフォルトでは値は false で、列の照合順序の違いを無視します。これにより、データ検証で誤検出が発生する可能性があります。照合順序は、レコードの並び順やデータの比較方法を決定するため、データ検証の重要な側面です。たとえば、次の例は、文字列「 abcABC 」の ASCII 表現における大文字と小文字の区別のある並び替え順序と区別のない並び替え順序を示しています。 検証の失敗をどのように対処するか このセクションでは、 AWS DMS の検証タスクで発生しうる、データ検証の失敗に関するいくつかの一般的なシナリオと、それらを修正する方法について説明します。 LOB が切り捨てられる場合 データベースをターゲットインスタンスに移行する際、 AWS DMS の移行タスク内で設定されている場合、 LOB データを含むデータをレプリケーションできます。 LOB データの移行のために、いくつかの 構成可能な設定 があります。デフォルトでは、 AWS DMS は制限付き LOB モードを使用し、それぞれの LOB の最大サイズは 32 KB です。デフォルトの構成を使用する場合、最大 LOB サイズを超えるデータはすべて切り捨てられます。 切り捨てられた LOB 列は、ソースとターゲットの値が異なるため、データ検証に失敗します。 CloudWatch ログで切り捨てられたログを検索することで、 LOB の切り捨てが発生していることを確認できます。切り捨てを回避するには、ソースデータベースの LOB サイズに合わせて最大 LOB サイズを設定します。 LOB サイズがわからない場合は、 inline LOB モード(エンドポイントがサポートしている場合)を選択して、小さな LOB と大きな LOB の両方を複製できます。検証専用タスクの ValidationPartialLobSize の値は、データ移行タスクの最大 LOB サイズと同じ値に設定することをお勧めします。 数値・タイムスタンプが切り捨てられる場合 数値とタイムスタンプのデータは、通常データベースエンジンによって異なるスケールと精度を持っており、明示的に定義されていない場合、それぞれのデフォルト値は異なります。以下では、数値とタイムスタンプに関する潜在的な問題と、それらを修正する方法を示す一般的な例をいくつか説明します。 Oracle データベースがソースの場合 Oracle データベースの移行において、数値データ型である NUMBER 型の移行でスケールと精度が明示的に指定されていない場合、 AWS DMS はデフォルトでデータを小数点 10 桁で切り捨てます。そのため、小数点 10 桁を超える既存のデータが移行される場合、ターゲットで数値が切り捨てられます。例えば、データ 123456.123456789012 は 123456.1234567890 に切り捨てられます。データが切り捨てられるのを避けるためには、 移行タスクのエンドポイントの追加接続属性 (ECA) パラメータ NumberDataTypeScale に適切な値を設定します。デフォルト値は 10 ですが、この例では 12 に設定してデータ切り捨てを回避します。これらのパラメータ設定の詳細については、 AWS DMS のドキュメント を参照してください。 PostgreSQL がソース・ターゲットの場合 PostgreSQL から PostgreSQL への移行において、精度やスケールが定義されていない数値データ型の列にデータが格納されている場合、AWS DMS は全体で 28 桁、小数点 6 桁でデータを切り捨てます。切り捨てを回避するには、移行時に数値データを文字列型としてマッピングするために、ソースとターゲットの両エンドポイントの ECA に MapUnboundedNumericAsString=true を定義します。 タイムスタンプデータについて Oracle は、 TIMESTAMP 型のデータ型で 1 秒あたり最大 9 桁の小数部 (= ナノ秒単位 ) をサポートしています。 SQL Server は、 TIME 型のデータ型で1秒あたり最大 7 桁の小数部をサポートしています。このデータが MySQL や PostgreSQL などのターゲットにマップされる場合、両方とも TIMESTAMP 型のデータ型で 1 秒あたり最大 6 桁の小数部をサポートします。その場合、ソースデータベース ( 例えば Oracle) で TIMESTAMP(7) から TIMESTAMP(9) と定義されたデータ型に対して、 AWS DMS のデータ検証タスクが不一致レコードを報告します。同じ問題が、 Oracle の TIMESTAMP WITH TIME ZONE や TIMESTAMP WITH LOCAL TIME ZONE など TIMESTAMP 型の別種、または SQL Server の DATEIME2 や DATETIMEOFFSET にも当てはまる可能性があります。データの切り捨てがビジネス上許容できる場合は、後で示すようにカスタム関数を使ってオーバーライドの検証ルールを設定できます。 トリガーやスケジューラによってターゲットのデータが更新される場合 AWS DMSはソースからターゲットデータベースにデータを移行し、レプリケーションによってデータを同期させます。 AWS DMS 以外で発生する変更は、データの不整合のリスクを高め、データ検証エラーの原因となる可能性があります。これらの変更の一部は、意図せずに発生します。例えば: ターゲットでデータベーストリガーが有効になっている場合、 AWS DMS タスクがターゲットテーブルに DML による変更を加えるとデータが更新される可能性があります。ベストプラクティスとして、データ移行フェーズではトリガーを無効にし、カットオーバー移行のみ有効にすることが推奨されます。ターゲットが PostgreSQL の場合、パラメータ session_replication_role=replica を使ってトリガーと外部キー制約を無効にできます。 ターゲットデータベース上で実行されるスケジューラジョブがデータを変更する可能性があります。初期の スキーマ変換 時に、スケジューラジョブもターゲットに移行できます。しかしながら、これらのジョブが有効になっていると、ターゲットのデータが変更されてデータ検証に影響を与え、複雑なトラブルシューティングが必要になる可能性があります。ベストプラクティスとして、ターゲットデータを変更する可能性のあるスケジューラジョブ(内部データベースのスケジューラジョブまたはアプリケーションの一部として予定されている外部ジョブ)を移行中は無効にすることが推奨されます。 文字セットと照合順序 (collation) の設定について データ移行中、データは複数回デコードとエンコードされます。ソースデータベースからデータを読み取り、レプリケーションインスタンスでデータを処理し、最終的にターゲットデータベースのロケール設定に基づいてデータをターゲットデータベースに書き込みます。変換の際に、 Unicode から Latin 文字セットなどの不適切な構成が設定されている場合、データ検証タスクは欠損の可能性がある変換を記録するために、これらを ValidationFailed として報告する可能性があります。 また、アクセント・ケースセンシティブは、移行タスクでデータエラーの原因となる可能性があります。例えば、ソースデータベースがアクセント・ケースセンシティブを持つように構成されており(これはデフォルトの動作です)、 NAME 列を主キーとするテーブルに AAAA 、 aaaa 、 áááá の 3 つのレコードがあるとします。これらのレコードがアクセントとケースを区別しない MySQL データベース ( utf8mb4_0900_ai_ci の照合順序など) のようなターゲットデータベースに書き込まれると、重複キーエラーが発生します。これは、アクセントとケースの違いを無視して同じレコードとして扱われるためです。これらのレコードは、一意制約違反エラーにより、 awsdms_validation_failures_v1 コントロールテーブルに FAILURE_TYPE を MISSING_TARGET として表示されます。 変換ルールとフィルタールールの影響 AWS DMS には、データ移行の一環で既存のスキーマとデータを変換するための強力な 変換ルール があり、フィルター条件が満たされた場合にのみターゲットデータベースにデータを移行するための フィルタールール もサポートされています。データ移行タスクで使用されるこれらのルールは、意図せずにターゲットデータベースでデータの不整合を引き起こす可能性があります。データ検証のみのタスクを作成する場合、これらのルールの副作用としてデータ検証の問題が発生しないように、同じ変換とフィルターのルールを使用することが重要です。データ検証のみのタスクに変換またはフィルターのルールを含める場合、 AWS DMS はまず規則を適用し、次にデータを検証し、不一致のレコードについて失敗を報告します。 例えば、移行タスクで、ソースの COL1 をターゲットの col2 に変更する変換ルールを設定したとします。しかし、同じ変換ルールがないデータ検証のみのタスクを作成した場合、 TargetTablePrepMode が DO_NOTHING であるため、 AWS DMS は必要なテーブルメタデータを認識できません。このシナリオでは、 AWS DMS は COL1 と col2 を検証の対象から除外します。別のシナリオでは、データ移行にフィルターのルールを適用するが、データ検証のみのタスクではフィルターのルールを省略すると、レコードはソースデータベースに存在するが、フィルターのルールのために AWS DMS によってターゲットに移行されません。その結果、検証エラーが発生します。 データ検証でオーバーライドルールを活用する方法 データ検証中に、この投稿で説明されているようなさまざまな検証エラーが発生する可能性があります。たとえば、ソースとターゲットのエンジン間で文字セットが異なるため、同じデータが移行されているにもかかわらず、 RECORD_DIFF とともに Mismatched records エラーが発生する可能性があります。または、AWS DMS のデータ検証で使用される組み込み関数がソースデータベースのバージョンでサポートされていないことにより、 ValidationFailed として CloudWatchLogs に &lt;No authorized routine named ‘HASH’ of type ‘FUNCTION’ having compatible arguments was found&gt; や &lt;pg_catalog.timezone(unknown, json)&gt; などのエラーが表示される可能性があります。このような場合に備え、 AWS DMS のデータ検証では、マッピングルールの validation ルールタイプに オーバーライド検証関数 を提供しています。この機能により、ソースとターゲットのエンジンでサポートされているデータベース関数を使用して、独自の検証ルールを追加できます。 たとえば、前述の Oracle から MySQL への移行におけるタイムスタンプデータの切り捨てケースでは、次のオーバーライドルールがカスタム関数を使用してデータを比較します。このルールは、 Oracleの to_char 関数を使用してソース列のタイムスタンプ値を YYYY-MM-DD HH:MM:SS.ffffff 形式に変換し、MySQLの date_format 関数を使用してターゲット列の値を同じ形式に変換します。 { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "to_char(cast(${column-name} as timestamp(6)), 'YYYY-MM-DD HH24:MI:SS.FF6')” "target-function": "date_format(${column-name}, '%Y-%m-%d %H:%i%:%s.%f')" } 以下は、 IBM Db2 から PostgreSQL への移行時に特定の列のデータ長を比較する例です。 { "rule-type": "validation", "rule-id": "2", "rule-name": "2", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "length(${column-name})", "target-function": "length(${column-name})" } 次の検証ルールは、ソースとターゲットの列をテキストに変換し、 UTF8 でエンコーディングし、 MD5 ハッシュを計算し、ハッシュを大文字に変換し、最終的な出力型を VARCHAR(64) に設定した後、比較します。これは、 PostgreSQL から PostgreSQL への移行など、可変のデータベース間で一貫性のある一意の識別子として比較するのに役立つ可能性があります。 { "rule-type": "validation", "rule-id": "3", "rule-name": "3", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "CAST (upper(md5(convert_to(CAST ('${column-name}' AS text), 'UTF8'))) AS VARCHAR(64))", "target-function": "CAST (upper(md5(convert_to(CAST ('${column-name}' AS text), 'UTF8'))) AS VARCHAR(64))" } AWS DMS は MD5 暗号化ハッシュを使用して、 SYS.DBMS_CRYPTO.HASH(TO_CLOB("COLUMN_NAME"), 2) などのLOBを検証します。ソースの Oracle で Federal Information Processing Standards (FIPS) (DPFIPS_140 = true) を有効にすると、バージョンによっては HASH_MD5 が機能しない可能性があります。この場合、 PostgreSQL 移行のために次のオーバーライドルールを検討できます。 { "rule-type": "validation", "rule-id": "4", "rule-name": "4", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "dbms_lob.getlength(${column-name})" "target-function": "coalesce(char_length(${column-name}),0)" } クリーンアップ この投稿に沿ってテスト環境を作成した場合は、 AWS DMS リソースのクリーンアップ に記載された情報を使用して、この投稿で提案されたソリューションのテストに使用した環境を削除してください。 まとめ この投稿では、 AWS DMS のデータ検証のみのタスクの活用、監視、最適化、および一般的なユースケースの処理方法を示しました。ソースとターゲットのデータベースとデータ移行の要件によっては、 AWS DMS のデータ検証のみのタスクを検討し、移行に高い信頼性を持つことができます。 本ブログについてご質問がある場合は、 AWS サポートにお問い合わせください 。 投稿者について Jay Shin / Database Migration Specialist in DMA (Database Migration Accelerator) シンガポールを拠点として、クラウドネイティブのデータベースサービスを活用してお客様のデータベース移行とモダナイゼーションの加速を支援しています。 Donghua Luo / Senior RDS Specialist Solutions Architect AWSクラウドのデータベースサービスを活用して、AWSのお客様がより高い柔軟性、スケーラビリティ、および回復力を実現できるよう支援しています。 Barry Ooi / Senior Database Specialist Solution Architect AWSでのお客様のジャーニーの一環として、クラウドネイティブサービスを使用してデータプラットフォームを設計、構築、実装することが専門です。データ分析とデータの可視化に興味を持っています。 &nbsp; &nbsp; &nbsp;

はじめに 従来、高品質な 3D コンテンツの制作は複雑で時間がかかり、リソースを大量に消費するプロセスでした。3D モデリングやテクスチャリングから、最終的なシーンの組み立てやレンダリングまで、企業は専門的なスキルセットを必要としていました。特に現実世界の要素をデジタルで再現することが目的の場合、リアルな仮想環境、アセット、キャラクターを作り上げるには多大な労力を要しました。 例えば、この AWS ブログ では、 LiDAR スキャン 、 フォトグラメトリ 、 Neural Radiance Fields (NeRFs) などの技術を用いて、現実世界のオブジェクトや環境をデジタル化するプロセスを簡素化するリアリティキャプチャ技術について詳しく説明しています。その核となるアイデアは、シーンの複数の視点を捉え、それらの視点間の類似点と相違点を分析することで、シーンの深度と形状を推定するというものです。この自動化されたアプローチにより、手動での 3D モデリングの必要性がなくなり、従来の手法と比較して短時間で高品質なアウトプットを得ることができます。しかし、これらの技術には高価で特殊なハードウェアが必要であり、計算負荷が高く、通常はリアルタイムレンダリングのパフォーマンスが低いという課題があります。 最近、 3D Gaussian Splatting と呼ばれる新しい 3D Reconstruction およびラスタライゼーション技術が、このワークフローを加速させながら高品質なアウトプットを提供する可能性を示しています。この記事では、3D Gaussian Splatting とは何か、従来の 3D Reconstruction やリアリティキャプチャのアプローチに比べてどのような利点があるのか、3D コンテンツ制作にとってどのような意味を持つのか、そして組織が AWS を活用して 3D Gaussian Splatting を利用し、実世界の 3D アセットを大規模に再構成する方法について探っていきます。 3D Reconstruction とは？ 図 1. 3D Reconstruction は、2 次元の画像からコンピュータビジョン技術を用いて被写体の立体的な表現を生成し 3D 深度を推定します。 3D Gaussian Splatting について詳しく説明する前に、3D Reconstruction の概念を理解することが重要です。このプロセスは、写真やビデオフレームなどの 2D 入力を使用して、3D シーンやオブジェクトを再現し再構成(Reconstruction)することを含みます。例えば、カメラでシーンを撮影し、それをインタラクティブな 3D 環境に変換することなどが挙げられます。LiDAR のような 3D スキャン技術とは異なり、3D Reconstruction 技術は深度データを明示的な入力として提供するのではなく、2D 画像からカメラポーズを推定し、深度情報を推論して 3D 空間でシーンを再構成する必要があります。さらに、3D Reconstruction は multi-view stereo 、 structure from motion 、 shape from shading/texture/focus などの技術を活用して 2D から 3D を再現する複雑なコンピュータビジョンの問題として捉えることができます。 フォトグラメトリは 3D Reconstruction の最も古い例として、1980 年代から航空写真、測量、地図作成などの様々な用途で広く使用されてきました。 以前の AWS ブログ で説明されているように、フォトグラメトリは Structure from Motion と Multi-View Stereo を活用してシーンのポイントクラウドを生成します。そして、 Poisson や Ball-pivoting などの様々な手法を用いて、ポイントクラウドからテクスチャを重ねたポリゴンベースの 3D メッシュを作成することができます。より最近の 2020 年には、Neural Radiance Fields（「 NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis 」）が新しい 3D Reconstruction 技術として導入され、再構成されたシーンをメッシュではなくボリュームとして表現しました。これは、ニューラルネットワークを使用して光の放射特性を推定し、被写体周りの人工的な新しい視点を作成することで実現されました。フォトグラメトリと比較して、この新しいアプローチは一般的により効率的で、より速く出力を生成しますが、細部のレベルは時に劣ることがあります。 3D Gaussian Splatting とは？ 図2. 3D Gaussian Splats は 3D 空間のボリュメトリックな表現であり、従来のポリゴンベースのメッシュとは異なります。 2023 年、 SIGGRAPH で発表された論文「 3D Gaussian Splatting for Real-Time Radiance Field Rendering 」で、3D Gaussian Splatting が NeRF の概念を基に新しい 3D Reconstruction 手法として紹介されました。主な違いは、NeRF のように光の放射輝度を推定するためにニューラルネットワークを使用して新しい視点を作成するのではなく、3D Gaussian Splatting は視点依存の「ガウス分布」で 3D 空間を埋めることで新しい視点を生成するという点です。これらは、光の振る舞いを模倣するように色、密度、位置が調整された、ぼやけた 3D プリミティブとして現れます。 従来の手法がポリゴンメッシュの三角形を描画するのに対し、3D Gaussian Splatting はガウス分布を描画（または splat）します。これにより、数十億のガウス分布を使用して複雑な実世界の環境を再現する立体的な表現が可能になります。さらに重要なのは、3D Gaussian Splatting は NeRF とは異なり、ニューラルネットワークを使用せず、代わりに 確率的勾配降下法 などの従来の機械学習最適化手法を活用している点です。この手法は NeRF と類似していますが、ニューラルネットワークのレイヤーを使用しないため、計算効率が大幅に向上しています。 3D Gaussian Splatting 技術は、従来の技術と比較して一般的に視覚品質が向上し、生成時間が短縮されたフォトリアルな 3D Reconstruction を提供します。さらに、他の利点もあり、3D Reconstruction の新しい最先端技術として位置付けられています。 フォトリアルな 3D Reconstruction の最適化 図 3. 3D Gaussian Splats は、デジタルコンテンツ制作（DCC）ツールやゲームエンジンで使用して、リアルでインタラクティブな環境を構築できます。 3D Gaussian Splatting には、フォトグラメトリや NeRF などの従来の 3D Reconstruction 技術に比べていくつかの重要な利点があります： 生成時間の短縮 : 3D Gaussian Splatting は、3D 空間を明示的にモデル化するためのニューラルネットワークを使用せず、視点依存のガウス分布を直接描画します。これにより、3D シーンの再構成に必要な計算労力が大幅に削減され、処理能力と時間の両方が節約されます。 優れたリアルタイムパフォーマンス : 3D Gaussian Splats のボリュメトリックでポイントクラウドベースの性質により、ポリゴンベースのメッシュと比較してリアルタイムでのレンダリングが容易になります。また、3D Gaussian Splat 出力は NeRF よりもコンパクトであるため、Web やデバイス上でもパフォーマンスの高いリアルタイムアプリケーションが可能になります。 より安定したアウトプット : 3D Gaussian Splatting のアプローチは、ノイズに対してより高い耐性を示します。視覚的なアーティファクトが少なく、透過、反射、空白スペースなど、従来の 3D Reconstruction で課題になりやすい表現を適切に処理します。 これらの利点により、3D Gaussian Splatting は実世界を 3D で捉えて再現する際の障壁を大幅に低下させました。これは以下のことを意味します： 3D アセット作成の参入障壁の低下と市場投入までの時間短縮 : 従来の専門的な役割や使用例を超えて、3D の採用が加速し、使用範囲が拡大しました。複雑な 3D オブジェクトをモデリングするための専門知識はもはや必要ありません。必要なのはスマートフォンのカメラと、3D Gaussian Splatting を利用した 3D Reconstruction パイプラインのエンドポイントだけです。 インタラクティブでリアルタイムな3Dコンテンツ体験がより身近に : レンダリングに必要なハードウェア要件が軽減され、リアルタイムでの利用パフォーマンスが向上したことで、ライブ 3D コンテンツがあらゆるメディアで一般化されつつあります。特に一般消費者向けのコンピューティング、モバイル、AR/VR 分野で顕著です。高価な高性能コンピューティング環境がなくても、フォトリアルな 3D アセットを使用したインタラクティブな体験を大規模に提供できるようになりました。 3D Reconstruction 技術としての 3D Gaussian Splatting は、バーチャルプロダクションからデジタルツイン、E コマースの製品可視化に至るまで、複数の産業分野で 3D アセット作成へのアプローチを変革する可能性を秘めています。これらの体験は、インタラクティブで高忠実度な 3D アセットの性質から恩恵を受けます。そのすべてがクラウドを活用することで、よりスケーラブルで配信可能、そしてパフォーマンスの高いものとなります。 AWS を使用した大規模な 3D Gaussian Splatting 3D Gaussian Splatting は、他の 3D Reconstruction 技術と同様に、アセットの生成、管理、そしてグローバルなエンドユーザーへの配信において、クラウドのスケール、パフォーマンス、コンテンツ配信機能を活用するのに適しています。このようなワークフローを構築する方法は多数あります。 以下は、AWS での 3D Gaussian Splatting ワークフローの例で、全体的なプロセスを高レベルで図示しています： 図4. AWS における 3D Gaussian Splatting ワークフローの例。 このワークフローは以下のコンポーネントで構成されています： 入力 : 2D の動画や画像メディアが取り込まれ、ワークフローへの入力として使用されます。 ワークフロー : ワークフローは複数のパイプラインで構成され、それぞれが独立して直列に処理されます。 パイプライン : 各パイプラインは、標準化された入出力を持つ自己完結型のタスクです。パイプラインの使用により、スコープを区画化し、互いに独立して実行できる個別のプロセスを分離できます。このモジュール性により、各パイプラインのコードベースを最適化し、これらのプロセスを他のワークフローで再利用することができます。この例では、画像処理、Structure from Motion、3D Gaussian Splatting のトレーニングと初期化、3D Gaussian Splatting ビューワーのパイプラインがあります。 出力 : 3D Gaussian Splatting の生成では、ユーザーが Web ブラウザで適切なビューワーを使用して閲覧できる 3D オブジェクトが出力されます。 次の図は、前述の 3D Gaussian Splatting ワークフローがどのように AWS サービスを使用して実装できるかを示しています: 図5. 3D Gaussian Splatting のワークロードは、プロセスのオーケストレーションと処理に AWS サービスをビルディングブロックとして活用することで大きな恩恵を受けます。 この図は以下の主要コンポーネントを示しています: 開発者は AWS Cloud Development Kit (CDK) を使用して、使用前に一度だけインフラストラクチャを作成およびデプロイします。 AWS CDK は、デプロイ中に必要なインフラストラクチャの情報（URI、ARN）を AWS Systems Manager Parameter Store に保存します。 デプロイ後、ユーザーはインターネットに接続されたローカルブラウザでウェブサイトの URL を起動します。 ウェブサイトは Amazon Simple Storage Service (S3) でホストされ、 Amazon CloudFront を使用してグローバルに配信されます。 ユーザーは Amazon Cognito ユーザープールを使用して認証情報を入力してログインします。 ユーザーは UI で新しいアセット（動画または一連の画像）をアップロードし、API コマンドを発行して 3D Gaussian Splatting ワークフローを開始します。 ワークフローの状態とアセットの詳細は Amazon DynamoDB に保存されます。 AWS Step Functions ワークフローは、パイプラインを実行するプロセスハンドラーとして Amazon Elastic Container Service (ECS) を呼び出します。 Amazon ECS は、コンテナ用の Amazon Elastic Container Registry (ECR) 内のイメージを使用します。 Amazon ECS は、3D Gaussian Splatting パイプラインを実行するためのコンピューティングリソースを動的に確保し、コンテナをホストします。 生成されたアセットは Amazon S3 からパイプラインにロード/保存されます。 プロセスハンドラーが完了すると、ワークフローも完了します。 データベースは状態とワークフローの詳細で更新されます。 Amazon Simple Notification Service (SNS) を使用して、アセット作成完了時にユーザーに通知できます。 ユーザーは Web ブラウザで splat を表示できます。 Amazon CloudWatch を使用してログにアクセスできます。 AWS での 3D Gaussian Splatting を含むワークロードは、AWS のマネージドサービスと共にオープンソースソフトウェアやサードパーティツールを統合できます。例えば、画像の前処理にオープンソースツールを使用し、AWS のマネージドサービスを活用して再構成ジョブを実行することができます。 このワークフローに統合できる AWS サービスの例は他にもたくさんあります。AWS で 3D Gaussian Splatting のワークロードを実行することで、顧客は以下のようにアプリケーション機能を拡張できます: 弾力的な分散処理 : Amazon ECS、 Amazon Elastic Kubernetes Service (EKS) と AWS Batch を使用して、3D Reconstruction ジョブをパッケージ化し、複数のコンピュートノードに並列化および分散させることで、生成時間を短縮し、必要に応じてスケールアップ・ダウンできます。 AWS Deadline Cloud のようなコンピュートファームマネージャーを使用して Open Job Description (OpenJD) の互換性を活かして再構成パイプラインの実行を効率的に制御します。 コンテンツの保存と管理 ：AWS のオープンソース Visual Asset Management System (VAMS) ソリューションを利用して、Amazon S3 と Amazon DynamoDB を活用し、スキャンした 3D アセットを保存、管理、取得して内部コラボレーションを行います。 グラフィックスコンピューティング ： Amazon Elastic Compute Cloud (EC2) と、NVIDIA L4 Tensor Core GPUを搭載した最新世代の Amazon EC2 G6 インスタンス を活用することで、グラフィックスアプリケーションで 3D アセットを効率的に処理し、活用することができます。 コンテンツ配信とストリーミング ：Amazon CloudFront を使用して、再構成されたインタラクティブな 3D コンテンツを、低レイテンシーでエッジから、Web やモバイルでグローバルにストリーミングおよび配信します。 分析とインサイト ： Amazon Kinesis 、 Amazon Athena 、 Amazon QuickSight などの AWS 分析サービスを活用して、3D Reconstruction パイプラインからインサイトを得ます。パイプラインのパフォーマンスを追跡し、ボトルネックを特定し、大規模にコンピューティング効率を最適化します。 AI/ML 統合 ： Amazon SageMaker や Amazon Bedrock などのマシンラーニングおよび生成 AI サービスを統合して、例えば画像セグメンテーションやセマンティックラベリングなどのコンピュータビジョンを通じて、3D Reconstruction をさらに強化します。 デジタルツイン ： AWS IoT TwinMaker でスキャンした 3D アセットを使用して、実世界のシステムや操作を表現するデジタルツインアプリケーションを強化します。 AWSは、3D Gaussian Splatting ワークロードのライフサイクル全体をサポートする幅広いサービスを提供しています。これには、データ取り込み、分散処理、ストレージ、配信、レンダリング、分析、AI/ML、デジタルツインが含まれます。 まとめ 昨年、論文が発表されて以降、3D Gaussian Splatting は 3D アセットおよびコンテンツ制作の分野に革新をもたらし、3D Reconstruction リアリティキャプチャ技術のアクセシビリティと効果を大幅に向上させました。 3D Gaussian Splatting の分野は急速に進化を続けており、AWS パートナーからの継続的なイノベーションが行われています。NVIDIA は「 Text-to-4D with Dynamic 3D Gaussians and Composed Diffusion Models 」というアプローチを探求し、3D Gaussian Splatting と AI 拡散モデルを統合して、テキスト入力を通じてダイナミックなアセットを生成することを目指しています。また、Meta は「 Robust Gaussian Splatting 」に取り組んでおり、視覚的な不整合を減らすことで、スマートフォンでの撮影から得られる 3D Reconstruction 出力の堅牢性を向上させることに焦点を当てています。 AWS では、スケーラブルな 3D Gaussian Splatting パイプラインを実現するためのクラウドインフラストラクチャ、サービス、およびパートナーエコシステムを提供しています。これには、動画データの取り込み、モデル生成のためのコンピューティング、3D アセットの保存と管理、そしてあらゆるデバイスへのリアルタイムレンダリングと配信が含まれます。これにより、メディア、小売業、製造業などの様々な産業分野のアプリケーションにフォトリアルな 3D 機能を組み込むプロセスが簡素化されます。 私たちは、皆さんが 3D Gaussian Splatting や 3D Reconstruction 技術を自ら試すことを推奨します。GitHub 上の 「3D Gaussian Splatting for Real-Time Radiance Field Rendering」リポジトリ を参照して実装手順を確認し、今すぐ AWS 上でデプロイしてみてください。 注) 上記リポジトリで公開されているソースコードの利用にあたっては事前に ライセンス を確認し、その範囲内でご利用ください。 著者について Stanford Lee Stanford Lee は、Amazon Web Services のテクニカルアカウントマネージャーであり、Spatial Computing 領域の技術コミュニティメンバーです。大企業の上級技術リーダーシップに技術的なガイダンスを提供しています。この役割において、顧客とのエンゲージメントをリードし、技術的なプロトタイプを構築し、没入型3Dコンピューティングおよび拡張現実、仮想現実、複合現実（AR/VR/XR）技術に関する思想的リーダーシップを提供しています。オーストラリアのシドニーを拠点とし、以前は日本とシンガポールで勤務した経験があります。 Dario Macagnano Dario は、AWS のビジュアルコンピューティング部門のシニアソリューションアーキテクトです。 Eric Cornwell Eric Cornwell は、AWS の OSET(Open Source and Emerging Technologies）チームのシニア空間ソリューションアーキテクトです。様々な工学の学位を持ち、出版物を通じて貢献し、拡張現実に関する特許を保有しています。Eric は、最先端の没入型技術を活用してスケーラブルでインテリジェントな3Dソリューションを開発することに専念する熟練したビルダーとして知られています。新興技術における専門知識を活かし、AWS の顧客に価値をもたらす革新的な空間コンピューティングおよび3Dアプリケーションの創造において重要な役割を果たしています。 この記事は 3D Gaussian Splatting: Performant 3D Scene Reconstruction at Scale を翻訳したものです。翻訳はソリューションアーキテクトの小森谷が担当しました。

VMware ワークロードは長年にわたり、多くのエンタープライズ IT 環境の重要な基盤となってきました。しかし、ビジネスニーズの進化に伴い、多くの組織が現在これらのワークロードをどのように実行するのが最適か – クラウドに移行するか、オンプレミスに残るか – を評価しています。 AWS への移行は、組織が運用を効率化し、俊敏性を高め、技術的負債を削減しながらイノベーションを推進するのに役立つメリットを提供します。クラウドのスケーラブルで弾力的なリソースにより、企業は動的なワークロード要件を満たすためにオンデマンドでコンピューティング能力をプロビジョニングできます。この柔軟性はリソース利用を最適化するだけでなく、組織が消費したリソースに対してのみ支払うため、コスト削減にもつながります。 VMware ベースのワークロードを移行およびモダナイズ化しながらこれらのメリットを享受しようとする組織にとって、 AWS Migration Acceleration Program (MAP) が VMware ワークロードの移行をさらにサポートするように拡張されたことを発表できることを嬉しく思います。 MAP は、数十万のエンタープライズワークロードを移行した AWS の経験を活用して、クラウドへの移行を加速し簡素化する包括的で実績のあるクラウド移行プログラムです。MAP の拡張により、AWS は VMware ワークロードを AWS への移行に特化したツール、フレームワーク、リソース、トレーニングへのアクセスを提供します。 MAP は、Guardian Life が 18 ヶ月で 1,200 インスタンスにわたる 90 以上のアプリケーションを移行し、News Corp が 56 のデータセンターを 6 つに統合してインフラストラクチャの 75% をクラウドに移行し、Newsweek が全体的な月間運用コストを 75% 削減するのを支援しました。これらは、MAP が顧客にコスト削減 (1.5 倍)、スタッフの生産性 (5.7 倍)、ビジネスの俊敏性 (4.3 倍)、運用の回復力 (1.7 倍) の向上をどのように実現したかを示すほんの一例です。 既存の VMware ベースのワークロードを AWS でリホストするか、フルマネージド AWS サービス上でリプラットフォーム化するか、最新のクラウドサービスを使用してアプリケーションを完全にリアーキテクトするかにかかわらず、AWS MAP は移行を成功させるために必要なガイダンスと専門知識を提供します。MAP を使用することで、組織は実証済みの方法論とベストプラクティスを活用して、強固な AWS クラウド基盤を構築し、イニシアチブを加速し、リスクとコストを削減できます。 要約すると、MAP は AWS 認定移行パートナーと共に以下を提供します: リソースの適切なサイジングとライセンス支出の削減機会を特定するための無料の Optimization and Licensing Assessment (OLA) 。AWS ファイナンスのベンチマークデータによると、OLA を使用した顧客は 総所有コスト (TCO) を 36% 削減 できました。 対象となる移行に対して、AWSが提供する Cast、Cloudamize、CloudHedge、Concierto、Device42、Matilda Cloud、MontyCloud、RiverMeadow、Trianz およびその他の選定パートナーから、AWS 検証済みツールのライセンス。 AWS によるインベストメントにより、AWS サービスクレジット提供またはパートナー投資という形で、対象となる移行にかかる一時的な移行費用の相殺を顧客に支援します。 実証済みの方法論、フレームワーク、ツール、ベストプラクティス、専門知識。 クラウドスキルを構築し IT チームの準備を支援するための Migrating VMware Workloads to AWS と Migration Foundations Readiness Path を含む 500 以上のトレーニングコース。 私たちはサポートの準備ができています 最も包括的な機能、ツール、プログラム、専門知識、比類のないサービスの幅広さ、トレーニング、リソースを備えて、クラウドへの移行をサポートする準備ができています。コストの最適化、スケーラビリティの向上、新しいイノベーションの機会の解放を目指すなら、無料の 移行評価 をリクエストして今すぐ始めましょう。 さらに、無料のトレーニングモジュール Migrating VMware Workloads to AWS と Migration Foundations Readiness Path を探索して、ベストプラクティスを学び、その方法を確認してください。 専門家にご相談になりたい場合は、 こちら からお問合せください。 翻訳はソリューションアーキテクト 澤が担当しました。原文は こちら です。

こんにちは。ソリューションアーキテクトの阿南です。株式会社ファミリーマート（以下、ファミリーマート）システム本部 IT基盤部 クラウド推進グループでは、システム本部における AWS の開発・運用ガイドラインを定め、AWS システムの標準化を進めています。また、同 PMO・品質管理チームは、ファミリーマートのシステム開発プロジェクトにおいて客観的な視点で QCD を管理・コントロールしプロジェクトの品質を確保する取り組みをしています。本ブログは、ファミリーマートがどのように AWS 上で生成 AI をシステム開発に活用し、クラウド推進業務や品質管理業務の負荷低減を図っているか、ファミリーマート システム本部 IT 基盤部 クラウド推進グループ 朴明振 氏、柿澤拓哉 氏、同 PMO・品質管理チーム 藤田孝 氏から寄稿していただいたものです。 背景 AWS 阿南：クラウド推進業務に生成 AI を活用するに至った背景を教えてください。 ファミリーマート 朴氏：ファミリーマートはコンビニエンスストア事業に必要なシステムをオンプレミス環境で運用してきましたが、2017 年末からクラウドサービス (AWS) を活用することとなり、2024 年現在は多くのシステムが AWS で稼働しております。また、新規システムも多くが AWS 上での開発を予定しています。クラウド推進グループでは社内システムの AWS 移行・開発作業を支援しておりますが、生成 AI を利用することでより効率的な支援が可能であると判断し、導入を検討することになりました。 AWS 阿南：今回はクラウド推進業務に加えて、品質管理業務への生成 AI 活用もご検討されていますね。PoC の対象を拡大するに至った背景を教えてください。クラウド推進業務とは異なるニーズがあったのでしょうか？ ファミリーマート 藤田氏：PMO・品質管理チームはファミリーマートにおけるシステム開発の QCD 向上を目的として 2023 年に設立した新たなチームです。過去のシステム開発プロジェクトにおけるノウハウや教訓、PMO・品質管理チームメンバーのさまざまな知見を用いてプロジェクトを計画どおりの QCD で遂行していくことが求められます。システム開発の規模が大規模で複雑化することも多くあり、今までの教訓や担当者が持っている知見を効率的に活用をしていくことが望まれるという課題がありました。そのような背景の中、生成 AI を取り入れることで課題解決につながるのでは無いかと考えました。 チャットボットについて AWS 阿南：さっそくですが、業務を支援するために作成されたチャットボットについてお伺いしたいと思います。まずクラウド推進グループでは、どのような業務が対象となったのでしょうか？ ファミリーマート 朴氏：ファミリーマートでは既存システムとの連携とセキュリティ向上のためさまざまなルールを設けており、このルールに対した問い合わせ対応や手続きの案内などを対象として考えています。また、ファミリーマートでは AWS サポートセンターへ問い合わせた過去の実績をデータベースとして別途管理しており、ファミリーマート環境で発生したトラブルについて過去の実績を素早く回答を得られる仕組みも検討しています。 AWS 阿南：PMO・品質管理チームでは、どのような業務が対象となりましたか？ ファミリーマート 藤田氏：PMO・品質管理チームでは大きく３つの業務領域を対象としています。①品質向上（プロジェクトのリスク管理業務）②ノウハウ蓄積・共有（メンバー間でのノウハウ共有）③生産性向上（必要な社内情報に対してすみやかにアクセスして情報を入手出来ること） AWS 阿南：どちらの業務も、基準となるドキュメントやレビュー対象のドキュメントが存在し、その情報を効率的にまとめる、検索するという作業が重要なものですね。 ファミリーマート 朴氏：はい、そのため検索対象となるドキュメントを Amazon S3 のバケットに保存し、 Amazon Kendra から検索できるようにしました。Kendra の検索結果を Amazon Bedrock を通して大規模言語モデル（LLM）モデルを利用することで、自然言語での回答を得られる仕組みですね。またサポートへの問い合わせもクローズになるタイミングで自動的に S3 にアップロードし、定期的に Kendra に Syncできるようにしていますし、社内ドキュメントの内容も継続補強しています。 チャットボットのアーキテクチャ PoC の評価手法 AWS 阿南：評価手法についても事前に定義をして定量的な評価を実現されていました。どのような評価手法を取られたのかご紹介いただけますでしょうか？ ファミリーマート 藤田氏：PoC を開始するにあたり実施メンバー間でどうしたら効果的な PoC が出来るかディスカッションを経て PoC 計画を策定しました。ディスカッション時に多く懸念としてあがったのは PoC の進め方とゴールについてです。闇雲に実施しては最終評価が難しくなると考えたので、あらかじめ PoC 実施結果内容を定量的に測定することが出来るように工夫しました。具体的には、プロンプト自体に難易度のレベル定義づけをして（レベル低・中・高の順に進める）、生成された回答をさらに 5 段階（５：非常に役立つ〜 １：役立たない）で評価をし結果を数値化していきます。PoC の計画時点で最終評価があらかじめ定めたベースライン (3.0) の点数を超えることが出来れば次のステージに進むこととし、もし超えることが出来なければ PoC を中止することを事前に定義して進めました。 PoC で定義したプロンプトの難易度と結果評価レベル AWS 阿南：今回の PoC の評価はどのような結果となりましたか？ ファミリーマート 藤田氏：最終評価としては、全体平均 3.6 点となり事前に定めた基準「3.0」点を超える結果となりました。PoC で評価が高かったものは要約／テキスト生成／質問応答等の PoC カテゴリでした。PMO・品質管理チームではボリューム感のあるシステム開発ドキュメントを読み込むことも多いので、事前に生成 AI に要約させてポイントを理解して読むことで効率的／効果的に読込め生産性向上が期待出来ると考えています。逆にまだ実業務への活用には改善が必要があると思われたものは計算／推理を伴うものでした。 PoC の最終評価 工夫した点 AWS 阿南：今回活用の対象とした業務において、どのような要件があり、それらをどのような工夫で実現したか教えてください。標準的な RAG 構成では実現できないものがあったと思います。 ファミリーマート 柿澤氏：PMO・品質管理チームの業務では、各プロジェクトの設計資料が Kendra の検索対象となります。あるプロジェクトについての質問に他のプロジェクトの設計資料が参照されることが無いようにする必要がありました。PoC の段階では利用者も限定されていることもあり問題となることはありませんでしたが、今後対策すべき課題であると考えています。プロンプトで制御する方法も検討しましたが、厳密さを重視し、Kendra の Custom Document Enrichment 機能を用いて各ドキュメントにプロジェクトを示す属性を付与し、検索時に対象とするプロジェクトを Attribute Filter 機能で制限するという手法を採用予定です。 AWS 阿南：精度向上という観点では何か工夫がありましたか？ ファミリーマート 柿澤氏：AWS のブログ Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証 を参考に、Kendra に対するクエリを複数のクエリに拡張することで多様な検索結果を取得して精度を高める手法であるクエリ拡張を採用したいと考えております。PoC の中でそれぞれの質問に対して業務に役立つ回答が返ってきたかどうかを確認する過程で、役に立たない回答が返ってきた例では、そもそも Kendra からのドキュメント検索の時点で適切なドキュメントが検索できていないというケースが見られました。クエリ拡張を採用することにより、Kendra から適切なドキュメントを参照することができるようになり、最終的に Bedrock からもより業務に役立つ回答が生成できるようになる見込みとなります。 Why AWS？ AWS 阿南：システム本部支援のために、AWS の生成 AI を採用された決め手を教えてください。 ファミリーマート 朴氏：ファミリーマートでは既に多くのシステムが AWS で稼働しており、システム本部の開発業務をサポートするためのサービスとしては Bedrock と Kendra が最適であると思いました。また、GitHub の aws-samples にサンプルアプリケーション Generative AI Use Cases JP が公開されていて、迅速に PoC を進めることができることも大きい理由の一つです。 今後の展望について AWS 阿南：このチャットボットや、その他 AI の取り組みは今後どのように進めていく予定ですか。 ファミリーマート 朴氏：今のところは主な利用部署はクラウド推進グループと PMO・品質管理チームになっています。2024 年度下期から本格利用開始できるよう計画しています。また、AWS サービスと社内システムの開発タスクを連携して、システム本部全体的に活用できるように検討していく予定です。 著者について 朴 明振 韓国で大学を卒業し、日本でキャリアをスタート。インフラエンジニアとしてオンプレミス環境に関わりながら 2015 年に AWS と出会い、その後は AWS エンジニアとして会社に貢献しています。ファミリーマートには 2023 年入社、クラウド推進グループの CCoE メンバーとして主に AWS 環境の整備や改善を担当しています。 柿澤 拓哉 2012 年より SIer にて AWS をメインとしたインフラエンジニアとして従事。ファミリーマートの AWS の本格利用に伴い、2018 年より環境整備を担当し、現在もクラウド推進グループのメンバーとして対応。 藤田 孝 2024 年 1 月ファミリーマート入社。前職は SIer でシステム構築・運用やプロジェクトマネジメントを担当。専門領域はインフラ領域でファミリーマート PMO・品管チームにおいてもインフラ系のアーキテクトとしてシステム開発プロジェクトに対し客観的な視点で QCD 管理やコントロールを担当。

AWS User Group Japan (JAWS-UG) は、 「No Border」をテーマにした JAWS PANKRATION 2024 を主催しました。これは 24 時間のオンラインイベントで、世界中の AWS ヒーロー、AWS コミュニティビルダー、AWS ユーザーグループリーダーなどが、文化的なディスカッションからテクニカルトークまで、多岐にわたるトピックについて話し合います。このイベントの講演者の 1 人である Kevin Tuei 氏は、ケニアを拠点とする AWS コミュニティビルダー です。公の場での構築と、他の人との知識の共有の重要性を強調した Tuei 氏の講演は、このようなイベントにぴったりとマッチしていました。 8月19日週のリリース 8月19日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon S3 が条件付き書き込みのサポートを開始 –&nbsp; Amazon S3 に条件付き書き込みのサポートが追加されました。これは、オブジェクトを作成する前にその存在をチェックする機能です。この機能を使用することで、複数のクライアントを使用する分散アプリケーションが共有データセット全体でデータを並行して同時更新する方法を簡素化できるようになります。各クライアントはオブジェクトを条件付きで書き込んで、別のクライアントが既に書き込んだオブジェクトが上書きされないようにすることができます。 AWS Lambda が再帰ループ検出 API を導入 – 再帰ループ検出 API により、個々の AWS Lambda 関数に再帰ループ検出を設定できるようになりました。これは、再帰パターンを意図的に使用する関数の再帰ループ検出を無効にすることで、これらのワークロードの中断を回避できるようにします。他の AWS サービスに対する Lambda の再帰ループ検出サポートの拡大に伴い、これらの API を使用することで意図的な再帰ワークフローの中断を避けることが可能になります。Lambda 関数の再帰ループ検出は、Lambda コンソール、AWS コマンドラインインターフェイス (CLI)、または AWS CloudFormation 、 AWS サーバーレスアプリケーションモデル (AWS SAM) 、 AWS Cloud Development Kit (CDK) といった Infrastructure as Code ツールを使用して設定できます。この新しい設定オプションは、 AWS SAM CLI バージョン 1.123.0 と CDK v2.153.0 でサポートされています。 Amazon Bedrock バッチ推論 API の一般提供開始 –&nbsp;モデル評価、実験、オフライン処理の応答を得るために、 Amazon Bedrock を使用してプロンプトをバッチ処理できるようになりました。バッチ API を使用することで、基盤モデル (FM) を用いた推論をより効率的に実行できるようになります。また、応答を集約して、それらをバッチ分析することも可能です。使用を開始するには、「 Run batch inference 」を参照してください。 AWS のその他のニュース 2024 年 7 月に開始された AWS GenAI Lofts は、進化する生成人工知能 (AI) テクノロジー環境でイノベーションとコミュニティを育むように設計されたグローバルツアーです。Lofts は、世界中の主要 AI ホットスポットにコラボレーション型のポップアップスペースを設置することで、学び、構築し、つながるためのプラットフォームを開発者、スタートアップ、および AI 愛好家に提供します。イベントは世界各国で開催中です。お近くの開催地を見つけて、今すぐ参加しましょう。 今後の AWS イベント AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA であるかにかかわらず、地域内で開催される 今後の AWS Summit イベントの詳細については、こちらをご覧ください 。個人的な話になりますが、私は8月26日週の木曜日に開催される AWS Summit Johannesburg で基調講演者の 1 人としてお話しできるのを楽しみにしています。 登録は現在も受け付け中です 。ここで参加者の皆さんにお会いできるのを心待ちにしています。 AWS Community Day – この記事の冒頭で紹介したものと同様の AWS Community Day イベント で、地域のエキスパート AWS ユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボに参加しましょう。ニューヨークにお住まいの場合は、8月26日週この地域で開催されるイベントがあります。 近日中に開催されるすべての対面およびバーチャルイベント は、こちらで閲覧することができます。 8月26日週のニュースは以上です。9月2日週の Weekly Roundup もお楽しみに! –&nbsp; Veliswa 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server では、リージョン内リードレプリカとクロスリージョンリードレプリカの 2 つの一般的な読み取りスケール可用性オプションがあります。Amazon RDS のお客様はリードレプリカを使用して、分析ワークロードや読み取り目的のトランザクションワークロードをプライマリデータベースインスタンスからオフロードします。以前は、リードレプリカにはプライマリデータベースインスタンスが Multi-AZ 構成になっている必要がありました。ただし、お客様の中にはプライマリデータベースインスタンスの高可用性についてはあまり懸念していないものの、分析アプリケーションを低コストで提供するためにリアルタイムに近いデータレプリケーションを必要とするお客様もいます。プライマリインスタンスに対して分析クエリを実行すると時間がかかる傾向があり、その結果、他のトランザクション (OLTP) タイプのクエリがブロックされたりタイムアウトしたりする可能性があります。読み取り目的の分析クエリをプライマリインスタンスからオフロードすることで、ロックやブロッキング、クエリタイムアウトなどを減らし、プライマリインスタンスのパフォーマンスを向上させることができます。このようなお客様のニーズを考慮して、Amazon RDS for SQL Server は 2024 年 4 月 1 日に Single-AZ インスタンス用のリードレプリカを発表しました。 Multi-AZ 用の既存のリードレプリカ機能と同様に、Single-AZ 用の新しいリードレプリカ機能でも、Single-AZ インスタンスの読み取り可能なコピーを作成できます。Single-AZ のリードレプリカは、同じ AWS リージョン内またはリージョン間で作成できます。Single-AZ のクロスリージョンリードレプリカをクロスリージョンのディザスターリカバリーインスタンスとして使用することもできます。 この投稿では、Single-AZ のリードレプリカのアーキテクチャ、作成、監視について説明します。 Single-AZ のリードレプリカを使用するメリット Single-AZ リードレプリカには次の利点があります。 リードレプリカを使用して、Single-AZ プライマリインスタンスから分析ワークロードや読み取り目的のワークロードをオフロードできます。 リードレプリカを Single-AZ インスタンスに昇格させて、リージョン内またはリージョン間のディザスターリカバリーに役立てることができます。 Single-AZ のリードレプリカインスタンスの総コストは、Multi-AZ のリードレプリカインスタンスのコストに比べて低くなります。 同じ Single-AZ インスタンスに対して最大 15 個のリードレプリカを作成できます。 Single-AZ のリードレプリカを使用する場合の制限事項 Single-AZ リードレプリカを使用するときは、次の制限に注意してください。 複数のリードレプリカを作成することは可能ですが、挿入、更新、削除を受け入れることができるのはプライマリ Single-AZ インスタンスのみです。 リードレプリカへの自動フェイルオーバーはできません。ただし、必要に応じてリードレプリカをスタンドアロンの Single-AZ インスタンスに昇格させることはできます。一度リードレプリカを昇格させると、元のプライマリ Single-AZ インスタンスのリードレプリカには戻すことはできません。 アベイラビリティグループのデータ同期モードは非同期であるため、特にリソース競合が発生してプロビジョニングが不十分なインスタンスでは、リードレプリカで同期レイテンシーが発生する可能性があります。SQL Server の設計上、REDO スレッドが対応するログレコードをリードレプリカに適用するまで、データ変更はリードレプリカに反映されません。 リードレプリカ内のデータベースのバックアップは作成できません。 プライマリ Single-AZ インスタンスで作成されたテーブルやデータベースユーザーなどのデータベースレベルのオブジェクトは、自動的にリードレプリカにレプリケートされます。ただし、リードレプリカインスタンスの作成後にプライマリ Single-AZ インスタンスに追加されたログインや SQL エージェントジョブなどのサーバーレベルまたはインスタンスレベルのオブジェクトは、リードレプリカインスタンスで手動で作成する必要があります。 ソリューション概要 リードレプリカを含む Single-AZ インスタンスは、プライマリアベイラビリティーゾーンの 1 つのノードとセカンダリアベイラビリティーゾーンの 2 番目のノードで構成されます。これらのノードにはそれぞれ独自の Always On アベイラビリティグループがあります。これらのインスタンス間の可用性グループにまたがる分散型可用性グループが作成されます。プライマリ Single-AZ インスタンスでコミットされたトランザクションは、非同期的にリードレプリカにレプリケートされます。プライマリ Single-AZ インスタンスとリードレプリカインスタンスには、フロントエンドアプリケーションの接続文字列に使用できる独自の RDS エンドポイントがあります。 次の図は、同じリージョン内の Single-AZ インスタンスのリードレプリカのアーキテクチャを示しています。 Single-AZ インスタンスのリージョンとは異なる別のリージョンにリードレプリカを作成することもできます。次の図は、クロスリージョンリードレプリカを備えた Single-AZ インスタンスのアーキテクチャを示しています。 同じ Single-AZ インスタンスに対して最大 15 個のリードレプリカインスタンスを作成できます。より多くのリードレプリカを作成するビジネス上の理由がある場合は、プライマリインスタンスのリソース使用率を監視することが非常に重要であることに注意してください。ログレコードの読み取り、ログストリームの圧縮、および各レプリカへの送信を担当するバックグラウンドスレッドでは、リソースの競合 (CPU、スレッド、ネットワークなど) が発生し、パフォーマンスが低下する可能性があります。次の例は、2 つのリードレプリカを持つ Single-AZ インスタンスを示しています。RDS オートメーションは、作成したリードレプリカインスタンスごとに分散型可用性グループを作成します。 このアーキテクチャでは、OLTP タイプのトランザクションワークロードを Single-AZ エンドポイントに送信し、分析または読み取り目的のワークロードをリードレプリカエンドポイントに送信できます。 予期せぬ状況でリードレプリカの Single-AZ インスタンスがダウンし、回復不能な損傷を受けたり、アクセスできなくなったりした場合は、リードレプリカを Single-AZ インスタンスに昇格させて、アプリケーションのダウンタイムを減らすことができます。その後、Single-AZ インスタンス (プライマリに昇格したリードレプリカ) から新しいリードレプリカインスタンスを作成し、その新しいリードレプリカを指すように分析アプリケーションを再構成できます。 アプリケーションに同じ RDS Single-AZ またはリードレプリカインスタンスを指す接続文字列が複数ある場合は、対応する RDS エンドポイントを指す DNS レコードを作成することを検討してください。障害が発生した場合は、適切な RDS エンドポイントを指すように DNS レコードを更新できるため、1 つ以上のアプリケーションサーバーで複数の接続文字列を更新するオーバーヘッドを回避できます。 Single-AZ インスタンスに複数のリードレプリカを作成することは可能ですが、リソースの競合を避けるためにインスタンスのサイズ (インスタンスクラス、ストレージ IOPS、スループットなど) を適切に設定することが重要です。1 つ以上のリードレプリカの同期遅延は、SQL Server がプライマリデータベースレプリカのログファイルにログレコードを保持する原因になるためです。定期的なトランザクションログバックアップでは、ログレコードが送信されてリードレプリカにコミットされるまでログレコードをトランケートすることはできません。ログをトランケートできない場合、ログファイルは (設定されている場合) 自動的に拡張され 、最終的にディスク領域がいっぱいになり、プライマリインスタンスが停止する可能性があります。 以下のセクションでは、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用して Single-AZ インスタンスのリードレプリカを作成する方法を示します。 前提条件 このソリューションを設定するには、次の前提条件を満たす必要があります。 Microsoft SQL Serverの 分散型可用性グループ に関する基本的な知識。 サポート対象バージョンの SQL Server Enterprise エディションを実行しているアクティブな Single-AZ インスタンス (サポートされているマイナーバージョンの詳細については、「 RDS for SQL Server を使用したクロスリージョンリードレプリカ 」を参照してください)。Standard エディションでは現在、リードレプリカはサポートされていません。手順については、「 DB インスタンスの作成 」を参照してください。 バックアップ保持期間が 0 日を超えるプライマリ Single-AZ インスタンスで自動バックアップが有効になっていること。 コンソールを使用した Single-AZ のリードレプリカの作成 コンソールを使用してリードレプリカを作成するには、次の手順を実行します。 Amazon RDS コンソールのナビゲーションペインで [データベース] を選択します。 データベース一覧から Single-AZ インスタンスを選択します。 [アクション] メニューで [リードレプリカの作成] を選択します。 注意 : DB インスタンスは、SQL Server バージョン 2016 Enterprise Edition (またはそれ以降のバージョン) を実行する Single-AZ インスタンスである必要があります。サポートされているマイナーバージョンの詳細については、 リンク を参照してください)。 [DB インスタンス識別子] に、新しいリードレプリカインスタンスの名前を入力します。 [インスタンスの設定] セクションで、リードレプリカに適したインスタンスクラス (たとえば、db.m5.xlarge) を選択します。 特定の可用性グループでは、リソースの競合や同期のレイテンシーを避けるためにすべてのレプリカは同じワークロードを処理できる同等のインスタンスクラスとボリュームタイプで実行する必要があります。詳細については、「 可用性レプリカをホストするコンピューターに関する推奨事項 (Windows システム) 」を参照してください。 [AWS リージョン] では、アプリケーションのビジネス要件に基づいて適切なリージョンを選択します。 [ストレージタイプ] で、適切なストレージタイプ (gp2/gp3/io1/io2) を選択します。ストレージがいっぱいにならないように、ストレージの自動スケーリングを有効 / 無効にすることもできます。 io1/io2 を選択した場合は、プロビジョンド IOPS にも適切な値を指定してください。 gp3 を選択した場合は、プロビジョンド IOPS とストレージスループットに適切な値を指定してください。 I/O レイテンシーによってクエリの実行や同期のレイテンシーが発生しないように、ソースインスタンスと同様 (またはそれ以上) のストレージ構成を使用することをお勧めします。 [接続] セクションで、DB サブネットグループ、パブリックアクセス、VPC セキュリティグループ、およびアベイラビリティーゾーンの適切な値を選択します。要件に応じて、デフォルトまたは既存の値を選択できます。デフォルトのポート番号は 1433 です。別のポート番号を使用する場合は、「追加設定」で変更できます。 必要に応じて、インスタンスの Microsoft Windows 認証を選択します (詳細については、「 RDS for SQL Server による AWS Managed Active Directory の操作 」を参照してください)。ソースの Single-AZ インスタンスが既に Windows Active Directory ドメインの一部になっている場合は、適切なディレクトリを選択できます。 Single-AZ インスタンスが暗号化されている場合は、リードレプリカインスタンスの [暗号を有効化] をチェックします。暗号化されていない Single-AZ インスタンスから暗号化されたリードレプリカインスタンスを作成することはできません。 Performance Insights では、新しいリードレプリカの作成時に Amazon RDS Performance Insights を有効にすることも、後で有効にすることもできます。 無料で 7 日間のパフォーマンス履歴を保存できます。詳細については、「 Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング 」を参照してください。 [拡張モニタリングの有効化] をチェックすることも、後で有効にすることもできます。 拡張モニタリング は OS 関連の指標をキャプチャし、サーバーのリソース消費量やキャパシティプランニングなどの分析に使用できます。詳細については、「 Enhanced Monitoring の概要 」を参照してください。最大 7 日間の保存期間に対する拡張モニタリングは無料です。 ログ記録を長期間保存するビジネス上の理由があるかもしれません。[ログのエクスポート] で [エージェントログ] と [エラーログ] をチェックして、ログが Amazon CloudWatch にエクスポートされるようにします。 IAM ロールには、CloudWatch にログを公開するために使用する AWS Identity and Access Management (IAM) ロールを入力します。 設定値を確認し、[リードレプリカの作成] をクリックします。 AWS CLI を使用した Single-AZ のリードレプリカの作成 AWS CLI の create-db-instance-read-replica コマンドを使用して、Single-AZ インスタンスのリードレプリカを作成することもできます。構文の例を以下に示します。 aws rds create-db-instance-read-replica —db-instance-identifier &lt; RR_INSTANCE_NAME &gt; \ —source-db-instance-identifier &lt; SOURCE_SINGLEAZ_INSTANCE_NAME &gt; \ —region us-west-2 Bash たとえば、リージョン内の Single-AZ リードレプリカの場合は、次のコードを使用します。 aws rds create-db-instance-read-replica --db-instance-identifier singleaz-inst1-rr1 \ --source-db-instance-identifier singleaz-inst1 \ --region us-west-2 Bash クロスリージョン Single-AZ リードレプリカの場合は、次のコードを使用します。 aws rds create-db-instance-read-replica \ --db-instance-identifier singleaz-inst1-rr2 \ --source-db-instance-identifier arn:aws:rds:us-west-2: &lt; CUSTOMER_ID &gt; :db: singleaz-inst1 \ --endpoint-url https://rds-siteb.us-east-1.amazonaws.com \ --region us-east-1 --source-region us-west-2 Bash Single-AZ インスタンスのリードレプリカインスタンスを監視 他のタイプのリードレプリカと同様に、リソース消費量 (CPU、メモリ、I/O) を監視し、インスタンスのリソースを適切なサイズにすることが重要です。このキャパシティプランニングには、過去のベースライン消費量と将来のワークロード予測を使用できます。この目的には、拡張監視やパフォーマンスインサイトなどのツールを使用することも、サードパーティ製のツールを使用することも、SQL Server の組み込みの 動的管理ビュー と 動的管理関数 を使用してカスタム監視スクリプトを作成することもできます。リソースの使用状況を監視するだけでなく、同期レイテンシーも定期的に監視することをお勧めします。Amazon RDS ReplicaLag メトリクスを表示するか、T-SQL クエリを使用して定期的にラグ情報を収集することで、CloudWatch を使用してレプリケーションラグをモニタリングできます。 SELECT AR . replica_server_name , DB_NAME ( ARS . database_id ) 'database_name' , AR . availability_mode_desc , ARS . synchronization_health_desc , ARS . last_commit_time , ARS . last_hardened_lsn , ARS . last_redone_lsn , ARS . secondary_lag_seconds , ARS . redo_queue_size FROM sys . dm_hadr_database_replica_states ARS INNER JOIN sys . availability_replicas AR ON ARS . replica_id = AR . replica_id WHERE is_local &lt;&gt; 1 -- AND DB_NAME(ARS.database_id) = ' &lt;REPLACE WITH SPECIFIC DB NAME&gt; ' ORDER BY AR . replica_server_name ; SQL リードレプリカに関する一般的な運用上の考慮事項 リードレプリカを使用するときは、次の点に注意してください。 Single-AZ インスタンスとそのリードレプリカインスタンスには、さまざまなインスタンスクラスとボリュームタイプを使用できます。リードレプリカインスタンスを過少プロビジョニングすることは可能ですが、CPU やメモリの圧力、I/O レイテンシーによるクエリパフォーマンスの低下やデータ同期の問題を避けるため、リソース消費量を定期的に監視し、インスタンスクラスとストレージタイプのサイズを適切に決定することが重要です。 リードレプリカを初めて作成するとき、RDS オートメーションは Single-AZ インスタンスにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットバックアップを作成します。このスナップショットから新しいボリュームが作成され、リードレプリカインスタンスにアタッチされます。基盤となるストレージが Amazon Simple Storage Service (Amazon S3) のスナップショットバックアップから新しく作成された EBS ボリュームに対してストレージブロックをウォームアップするバックグラウンドプロセスである S3 ハイドレーションと呼ばれるプロセスを実行するため、新しく作成されたリードレプリカでは I/O レイテンシーが若干長くなります。その結果、最初の数時間は Always On レプリケーションラグとクエリ実行時のレイテンシーも大きくなることが予想されます。データがロードされていない場所でボリュームにアクセスすると、データがロードされている間、ボリュームにアクセスするトランザクションのレイテンシが通常よりも長くなります。ボリュームサイズが大きいほど、ハイドレーションが完了するまでの時間が長くなります。 リードレプリカを使用して Single-AZ インスタンスでデータベースを作成またはリストアすることができます。Amazon RDS のオートメーションにより、リードレプリカ内のデータベースが自動的にリストアおよびペアリングされます。ただし、Single-AZ インスタンスで作成したログインや SQL Agent ジョブなどのサーバーレベルのオブジェクトは、既存のリードレプリカに自動的にレプリケートされません。 リードレプリカは、分析タイプのワークロードをオフロードするためによく使用されます。分析ワークロードは tempdb データベースリソースを大量に消費する傾向があります。 tempdb の競合によるクエリのパフォーマンスの低下を避けるには、リードレプリカ内の tempdb データベースを監視し、適切なサイズを設定することが重要です。 Single-AZ インスタンスのアップグレード (メジャーバージョンまたはマイナーバージョン) を開始すると、Amazon RDS オートメーションは Single-AZ インスタンスのアップグレードとともにすべてのリードレプリカをアップグレードします。アップグレード中はインスタンスとデータベースにアクセスできないため、スケジュールされたメンテナンスウインドウ内でアップグレードを実行する必要があります。さらに、Single-AZ インスタンスとリードレプリカインスタンスに異なるバージョンの SQL Server を使用することはできません。 Single-AZ インスタンスからリードレプリカインスタンスへのデータ同期では、適切でないボリュームによる IOPS とスループットがボトルネックになる可能性があります。Single-AZ インスタンスとリードレプリカインスタンスに関連するボリュームを定期的に監視し、適切なサイズを設定することが不可欠です。 リードレプリカインスタンスはいつでも削除できます。1 つ以上のリードレプリカインスタンスを持つ Single-AZ インスタンスを削除すると、そのリードレプリカインスタンスは自動的に Single-AZ インスタンスに昇格します。昇格した Single-AZ インスタンスは必要に応じて削除できます。 結論 この投稿では、Amazon RDS for SQL Server Single-AZ インスタンスのリードレプリカが、Single-AZ インスタンスのスケーリングと、ソースの Single-AZ インスタンスからの読み取り集中型ワークロードのオフロードにどのように役立つかについて説明しました。さらに、ソースの Single-AZ インスタンスが使用できなくなった場合のディザスターリカバリーにも使用できます。過去のリソース消費量と将来のトランザクションリソースの予測に基づいて、リードレプリカインスタンス (CPU、メモリ、I/O) のサイズを適切に設定することが重要です。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Junu Thankappan は、アマゾンウェブサービスのシニアデータベースエンジニアです。AWS RDS チームで主に商用データベースエンジンと SQL Server を担当しています。

本ブログは「 Network perimeter security protections for generative AI 」を翻訳したものとなります。 生成 AI ベースのアプリケーションは、ここ数年で人気が高まっています。大規模言語モデル (LLM) を使ったアプリケーションは、企業が顧客に提供する価値を高める可能性があります。本ブログでは、生成 AI アプリケーションのネットワーク境界の保護について詳しく説明します。ネットワーク境界の保護の検討すべき様々な領域を説明し、それらが生成 AI ベースのアプリケーションにどのように適用されるかを議論し、アーキテクチャパターンを提供します。生成 AI ベースのアプリケーションにネットワーク境界の保護を実装することで、不正使用、コスト超過、分散型サービス拒否攻撃 (DDoS)、その他の脅威アクターや好奇心旺盛なユーザーからの保護に役立つコントロールが得られます。 LLM の境界での保護 Web アプリケーションのネットワーク境界の保護は、次のような重要な質問に答えるのに役立ちます。 アプリにアクセスできるのは誰ですか? アプリに送信されるデータの種類は何ですか? アプリが使用できるデータ量はどのくらいですか? ほとんどの場合、他の Web アプリと同じネットワーク保護の方法が生成 AI アプリにも機能します。これらの方法の主な焦点は、アプリが作成する特定のリクエストや応答ではなく、アプリにアクセスしようとするネットワークトラフィックをコントロールすることです。ここでは、ネットワーク境界の保護の 3 つの主要な領域に焦点を当てます。 アプリのフロントエンドの認証と認可 Web アプリケーションファイアウォールの使用 DDoS 攻撃からの保護 これらのアプリで LLM を使用することに関するセキュリティ上の懸念 (プロンプトインジェクション、機密情報の漏洩、過剰な代理行為など) については、この記事の範囲外です。 フロントエンドの認証と認可 ネットワーク境界の保護を設計する際、まずユーザーが認証 (AuthN) されているかどうか、および生成 AI ベースのアプリケーションに特定の質問をする権限 (AuthZ) があるかどうかに基づいて、特定のユーザーにアプリケーションへのアクセスを許可するかどうかを決める必要があります。多くの生成 AI ベースのアプリケーションは認証レイヤーの背後に配置されているため、ユーザーはアプリケーションにアクセスする前に ID プロバイダーにサインインする必要があります。認証の背後にない公開アプリケーション (チャットボットなど) の場合、次の 2 つのセクションで説明する AWS WAF と DDoS 保護に関して、追加の考慮が必要です。 例を見てみましょう。 Amazon API Gateway はアプリケーションフロントエンドのお客様向けのオプションであり、認証と認可を使用してユーザーや API を可視化します。フルマネージドされたサービスで、開発者が大規模に API を公開、保守、監視、セキュアにするのに役立ちます。API Gateway では、 AWS Lambda オーソライザーを作成してアプリケーション内の API へのアクセスをコントロールします。図 1 は、この例でのアクセスの仕組みを示しています。 図 1: クライアント～ LLM 間のシグナルパスにおける API Gateway、Lambda オーソライザー、基本的なフィルター 図 1 のワークフローは次のとおりです。 クライアントは&nbsp;API Gateway がフロントエンドとなる API にリクエストを送信します API Gateway はリクエストを受信すると、OAuth、SAML、または他のメカニズムを通じてリクエストを認証する Lambda オーソライザー にリクエストを送信します。Lambda オーソライザーは、API Gateway に AWS Identity and Access Management (IAM) ポリシーを返し、リクエストを許可または拒否します 許可された場合、API Gateway は API リクエストをバックエンドアプリケーションに送信します。図 1 では、これは LLM セキュリティの領域で追加の機能を提供し、より複雑なフィルタリングの代わりとなる Lambda 関数です。Lambda オーソライザーに加えて、クライアントごと、またはクライアントがアクセスするアプリケーションメソッドごとに API Gateway でスロットリングを設定できます。 スロットリング により、DDoS 攻撃だけでなく、モデルクローニングやモデル反転攻撃に対してある程度の緩和策を提供できます 最後に、アプリケーションは AWS 上にデプロイされた LLM にリクエストを送信します。この例では、LLM は Amazon Bedrock にデプロイされています Lambda オーソライザーとスロットリングの組み合わせにより、境界での様々な保護メカニズムをサポートできます。まず、認証されたユーザーのみがアプリケーションにアクセスできるため、ボットや一般ユーザーのアクセスを防ぐことができます。次に、認証されたユーザーに対して、LLM への過剰な呼び出しによるコストを防ぐため、呼び出しレートを制限できます。そして、ユーザーがアプリケーションによって認証および承認された後、アプリケーションはユーザーが認可されているデータにのみアクセスできるように、ID の情報をバックエンドのデータアクセスレイヤーに渡すことができます。 API Gateway の他にも、AWS ではフロントエンドの認証と認可を提供するためのオプションがあります。 AWS Application Load Balancer (ALB) は、アクセス前に OIDC プロバイダーへの認証をリクエストする OpenID Connect (OIDC) 機能をサポートしています。内部アプリケーションの場合、 AWS Verified Access は、アイデンティティとデバイスの信頼シグナルの両方を組み合わせて、生成 AI アプリケーションへのアクセスを許可または拒否します。 AWS WAF 認証または認可の決定が行われた後、次の考慮事項はアプリケーション側のネットワーク境界の保護です。 OWASP Top 10 for Large Language Model Applications で説明されているように、生成 AI ベースのアプリケーションには新しいセキュリティリスクが特定されています。これらのリスクには、安全が確認されていない出力ハンドリング、安全が確認されていないプラグイン設計、およびアプリケーションが望ましい基準から外れた応答を返す原因となるその他のメカニズムが含まれます。例えば、脅威アクターは LLM への直接的なプロンプトインジェクションを作成し、LLM の不適切な動作を引き起こす可能性があります。これらのリスク (安全が確認されていないプラグイン設計) の一部は、ID の情報をプラグインやデータソースに渡すことで対処できます。ただし、これらの保護の多くは、ネットワーク境界の保護の範囲外であり、アプリケーション内のセキュリティの領域に該当します。ネットワーク境界の保護では、アプリケーションにアクセスできるユーザーを検証し、アプリケーションアクセスの前にアプリケーションレベルでネットワークルールとパターンに基づいて Web リクエストを許可、ブロック、または監視するルールをサポートすることに重点が置かれています。 さらに、ボットトラフィックは Web ベースのアプリケーションにとって重要な検討事項です。 Security Today によると、インターネットトラフィックの 47% がボットから発生しています。パブリックアプリケーションにリクエストを送信するボットは、より多くのリクエスト負荷を引き起こすため、生成 AI ベースのアプリケーションの使用コストを押し上げます。 ボットトラフィックから保護するため、アプリケーションへアクセスする前の境界の保護の一部として AWS WAF を実装できます。AWS WAF を使用すると、保護対象の Web アプリケーションリソースに転送される HTTP(S) リクエストを監視およびブロックするファイアウォールをデプロイできます。これらのリソースは、API Gateway、ALB、AWS Verified Access、およびその他のリソースの背後に存在します。Web アプリケーションの観点では、AWS WAF は LLM の呼び出しが行われる前に、アプリケーションへのアクセスを防止または制限するために使用されます。これは重要な検討事項です。なぜなら、LLM への入力と出力を保護するだけでなく、正当なトラフィックのみがアプリケーションにアクセスできるようにする必要があるからです。 AWS マネージドルール または AWS Marketplace のマネージドルールグループ では、ルールグループの一部として定義済みのルールが提供されます。 もうすこし前の例を掘り下げてみましょう。図 1 のアプリケーションがスケールアップし始めたので、 Amazon CloudFront の背後に移動することにしました。CloudFront は、エッジロケーションのグローバルネットワークを使用して、AWS への分散型のイングレスを提供する Web サービスです。分散型のイングレスを提供するだけでなく、CloudFront を使用すると AWS WAF ルールの一部として SQL インジェクション、ボット制御、その他のオプションに対する保護をグローバルにデプロイできます。図 2 の新しいアーキテクチャを見ていきましょう。 図 2:クライアントからモデルへのシグナルパスに AWS WAF と CloudFront を追加する 図 2 に示されたワークフローは次のとおりです。 クライアントは API にリクエストを送信します。DNS はクライアントを AWS WAF がデプロイされている CloudFront のロケーションに向けます CloudFront はリクエストを AWS WAF ルールに送り、トラフィックをブロック、監視、または許可するかを決定します。AWS WAF がトラフィックをブロックしない場合、AWS WAF はそれを CloudFront のルーティングルールに送ります 注: API Gateway へのアクセスを制限して、ユーザーが CloudFront ディストリビューションをバイパスしてAPI Gateway にアクセスできないようにすることをお勧めします。この目標を達成する方法の例は、「 Restricting access on HTTP API Gateway Endpoint with Lambda Authorizer 」ブログ記事にあります CloudFront はトラフィックを API Gateway に送り、図 1 で説明したのと同じトラフィックパスを通過します さらに詳しく見るために、ボットトラフィックに焦点を当てましょう。 AWS WAF Bot Control を使用すると、スクレイパー、スキャナー、クローラー、ステータスモニター、検索エンジンなどのボットを監視、ブロック、またはレート制限できます。Bot Control は、設定済みのルールと複数の検査レベルのオプションを提供します。たとえば、ルールグループの Targeted レベルを使用すると、自己識別しないボットにチャレンジを仕掛けることができるため、悪意のあるボットがあなたの生成 AI ベースのアプリケーションに対して操作するのがより困難で高コストになります。Bot Control のマネージドルールグループを単独で、または他の AWS マネージドルールグループと独自のカスタム AWS WAF ルールと組み合わせて使用できます。Bot Control は、図 3 に示すように、あなたのアプリケーションを標的にしているボットの数について詳細に可視化できます。 図 3: Bot Control ダッシュボードで確認できるボットリクエストと非ボットリクエスト この機能はどのように役立つでしょうか? 生成 AI ベースのアプリケーションでは、ボットやその他のトラフィックがアプリケーションをどのように標的にしているかを確認できます。AWS WAF は、特定のボットを許可したり、ボットトラフィックをアプリケーションからブロックしたりするなど、ボットトラフィックの Web リクエスト処理を監視およびカスタマイズするオプションを提供します。Bot Control に加えて、AWS WAF には、ベースラインルールグループ、ユースケース固有のルールグループ、IP レピュテーションルールグループなど、さまざまなマネージドルールグループが用意されています。詳細については、 AWS マネージドルールグループ と AWS Marketplace マネージドルールグループ のドキュメントをご覧ください。 DDoS 保護 本ブログで最後に取り上げるトピックは、LLM における DDoS です。他のレイヤー 7 アプリケーションに対する脅威と同様に、脅威アクターは非常に多くのリソースを消費するリクエストを送信する可能性があり、その結果サービスの応答性が低下したり、大量のリクエストを処理する LLM の実行コストが増加したりします。スロットリングは、ユーザーごとまたはメソッドごとのレート制限をサポートするのに役立ちますが、DDoS 攻撃はスロットリングでは対処が困難な、より高度な脅威ベクトルが使用されます。 AWS Shield は、インターネットに面するアプリケーションに対する DDoS 保護を提供し、Shield Standard ではレイヤー 3 と 4、Shield Advanced ではレイヤー 7 を保護します。例えば、Shield Advanced は、既にデプロイされている AWS WAF の一部である Web アクセスコントロールリスト (ACL) を使用して、エクスプロイトの一部である Web リクエストをカウントまたはブロックすることで、自動的にアプリケーションの脅威を緩和します。要件に応じて、Shield は複数のレイヤーで DDoS 攻撃から保護できます。 図 4 は、Shield を追加した後のデプロイメントの様子を示しています。 図 4: クライアントからモデルへのシグナルパスに Shield Advanced を追加する 図 4 のワークフローは次のとおりです。 クライアントは API にリクエストを送信します。DNS はクライアントを CloudFront のロケーションに向けます。そこには AWS WAF と Shield がデプロイされています CloudFront はリクエストを AWS WAF ルールに送り、トラフィックをブロック、監視、または許可するかを判断します。AWS Shield は、さまざまな既知の DDoS 攻撃ベクトルとゼロデイ攻撃ベクトル を軽減できます。設定に応じて、Shield Advanced と AWS WAF が連携して、個々の IP アドレスからのトラフィックをレート制限します。AWS WAF または Shield Advanced がトラフィックをブロックしない場合、サービスはそれを CloudFront のルーティングルールに送ります CloudFront はトラフィックを API Gateway に送り、図 1 で説明したのと同じトラフィックパスを通過します AWS Shield と Shield Advanced を実装すると、セキュリティイベントに対する保護と、グローバルおよびアカウントレベルのイベントの可視性が得られます。例えば、アカウントレベルでは、アカウントで見られたイベントの総数、各リソースの最大ビットレートとパケットレート、CloudFront の最大リクエストレートに関する情報が得られます。Shield Advanced では、Shield Advanced が検出したイベントの通知と、検出されたイベントと緩和策に関する追加情報にもアクセスできます。これらのメトリクスとデータは、AWS WAF とともに、あなたの生成 AI ベースのアプリケーションにアクセスしようとしているトラフィックの可視性を提供します。これにより、アプリケーションへのアクセスや LLM の呼び出しの前に、緩和機能が提供されます。 考慮事項 生成 AI アプリケーションをデプロイする際の境界の保護については、以下の点を考慮してください。 AWS では、フロントエンド側の認証と認可と、AWS WAF 側の両方で境界の保護を構成する複数のオプションを提供しています。アプリケーションのアーキテクチャとトラフィックパターンに応じて、 複数のリソース が AWS WAF で境界の保護を提供し、認証と認可の決定のために ID プロバイダーと統合できます また、Lambda 関数やその他の AWS サービスを使用して、デプロイメントアーキテクチャの一部として、より高度なLLM 固有のプロンプトフィルターと応答フィルターをデプロイすることもできます。境界の保護機能は、望ましくないトラフィックがエンドアプリケーションに到達するのを防ぐことに重点が置かれています LLM で使用される大半のネットワーク境界の保護は、他の Web アプリケーションのネットワーク境界の保護メカニズムと同様です。違いは、通常の Web アプリケーションと比べて、追加の脅威ベクトルが発生する点です。脅威ベクトルの詳細については、 OWASP Top 10 for Large Language Model Applications と MITRE ATLAS を参照してください 結論 本ブログでは、従来のネットワーク境界の保護戦略が、生成 AI ベースのアプリケーションに多層防御を提供する方法について説明しました。LLM ワークロードと他の Web アプリケーションの類似点と相違点について説明しました。認証と認可の保護が重要な理由を説明し、API Gateway を使用してスロットリングと Lambda オーソライザーを通じた認証を行う方法を示しました。次に、AWS WAF を使用してアプリケーションをボットから保護する方法について説明しました。最後に、AWS Shield がさまざまなタイプの DDoS 攻撃からスケーラブルで高度な保護を提供する方法について説明しました。ネットワーク境界の保護と生成 AI セキュリティの詳細については、 AWS Security Blog チャンネル の他のブログ記事を参照してください。 本ブログについてご質問がある場合は、 AWS サポートにお問い合わせください 。 Riggs Goodman III Riggs は AWS の Principal Partner Solution Architect です。現在の専門分野は AI セキュリティとデータセキュリティで、AWS で AI ワークロードを構築するための技術的ガイダンス、アーキテクチャパターン、リーダーシップを顧客とパートナーに提供しています。社内では、顧客とパートナーの課題に対処するための AWS サービスチーム全体の技術戦略とイノベーションの推進に注力しています。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

産業データは貴重なリソースであり、機械の性能、プロセス、製品に関する洞察を提供します。 このデータを収集して分析することで、企業は製品の品質を高め、効率を最適化し、サプライチェーンを管理し、予防保全を効果的にスケジュールできます。 ただし、産業用デバイスからのデータ収集は複雑なプロセスになる可能性があります。 通常、これらのデバイスはさまざまなベンダーによって製造されており、それぞれが独自のデータ形式、アドレッシング、およびプロトコルを使用しています。 また、実際の製造工程 (本番環境) に必要なソフトウェアを導入、運用していくためには、検証時よりもさらに複雑になることもあります。 Shop Floor Connectivity (SFC) は工場からのデータ収集を可能にするソリューションで、新規設備であってもレガシーなプロトコルを用いた既存設備であってもカスタマイズ可能な接続ソリューションを迅速に提供できます。 SFC は、既存の IoT データ収集サービスの制約に対処し、データ収集を統合することで、さまざまなベンダーの機器から一貫した方法でデータを収集し、さまざまな AWS サービスで使用できるようにしています。 SFC コンポーネント SFC を構成するコンポーネントには主に 3 つのタイプがあります。 プロトコルアダプター SFC コア ターゲットアダプター 図：SFC コンポーネントの概要 SFC コンポーネントの概要 プロトコルアダプター プロトコルアダプターは、いくつかの産業用デバイスからデータを読み取るために使用されます。このアダプターは、デバイスが使用しているプロトコルを抽象化し、追加のメタデータを含むデータを共通の形式で SFC コアに送信します。 このインターフェイスは、フレームワークの他の部分を変更することなく、新しいプロトコルアダプターで SFC を簡単に拡張できるように設計されています。 この記事の執筆時点で、SFC には Modbus TCP、MQTT、OPCUA、Ethernet/IP PCCC、ADS、SNMP、S7、および SQL 用のアダプターなどがあります。 (訳注：他にも対応プロトコルがあるため詳細は Github リポジトリ をご参照ください) SFC コア SFC コアコンポーネントは SFC フレームワークのコントローラーです。 プロトコルアダプターを介したデータ収集の設定とスケジューリングを処理します。 オプションで、60 種類以上の型変換などが可能な関数を組み合わせて、受信した各データ値を変換できます。これにより、複雑なデータ変換要件に対応できます。 SFC コアはエンドツーエンドにデータ型を忠実に連携でき、複雑な構造化データ型や多次元配列などについても、ソースから読み取ったデータ形式でターゲットに送信できます。 オプションとして、12 種類の集計関数を使用して、データをエッジでバッファリングして集約し、ネットワークトラフィックの削減が可能です。 SFC コアは AWS Secrets Manager と統合されているため、システム設定で使用するシークレットをプレースホルダーで指定できます。 ターゲットアダプター ターゲットアダプターは、SFC コアからデータを受信し、特定の AWS サービスやお客様独自のサービスに送信するコンポーネントです。 コンポーネントはオプションで Apache Velocity テンプレートを使用してデータ変換を適用し、受信サービスに必要な形式でデータを配信できます。 本記事の執筆時点では、 AWS IoT Analytics , AWS IoT Core , Amazon Kinesis Data Streams , Amazon Data Firehose , AWS Lambda , Amazon Managed Streaming for Apache Kafka (MSK) , Amazon Simple Storage Service (S3) , AWS IoT SiteWise , Amazon Timestream , Amazon Simple Notification Service (SNS) , Amazon Simple Queue Service (SQS) のアダプターがあります。 ローカルファイルシステム、ターミナル出力、MQTT クライアント用の追加ターゲットも用意されています。 データ収集 データ収集は設定ファイルによって構成することができ、追加のコーディングは必要ありません。 これは、SFC コアプロセスにスケジュールを定義することによって実現されます。 各スケジュールの設定では収集間隔とデータソースを設定でき、様々な種類のデータソースから異なる形式のデータを設定をもとに読み取れます。ソースの種類はさまざまです。 ソースは、使用されるプロトコルアダプターと、そのアダプターを使用して読み取る必要がある値を定義します。 オプションで、変換と集計を定義して、収集したデータに適用できます。 1 つのスケジュールでは、収集および処理されたデータを送信するターゲットアダプターも指定します。 デプロイ SFC コアは、ユーザーが設定したコネクターとターゲットアダプターをロードする単一のプロセスとしてデプロイできます。 または、プロトコルアダプタ、ターゲットアダプタ、および SFC コアを、収集したデータを交換するために TCP/IP ストリームを介して通信する個々のサービスとして展開することもできます。 これらのサービスは、同じ物理マシンに配置することも、別の外部ハードウェアに配置することもできます。 この柔軟性により、データ収集と処理の負荷分散が可能になり、さまざまな接続要件と制限があるネットワークセグメントをまたいで展開できます。 以下の図は、いくつかのデプロイメント例を示しています。 図：SFC の構成例 SFC コンポーネントを実行するには Java 仮想マシンが必要です。 コンポーネントは、スタンドアロンのアプリケーション、コンテナとして、または AWS IoT Greengrass コンポーネントとして実行できます。 SFC の拡張 SFC は、新しいプロトコルとターゲットアダプタを簡単に実装し拡張できます。 新しいアダプターのコンポーネントを構築するには、開発者は SFC コアがアダプターと通信するために使用するアダプターのインターフェイスを実装する必要があります。 SFC は、開発者が SFC のコードを用いてプロトコルとターゲットの実装に集中できるように設計されていますが、必ずしも SFC のコードを修正する必要はありません。SFC は既存の設定 (Configuration) を組み合わせてカスタマイズされた設定プロバイダを構成できます。 SFC コンポーネントによって生成されるメトリクスは、 Amazon CloudWatch メトリクスやその他のメトリクスデータストアに送信できるように、カスタムメトリクスライター (書き込み機能) を構成できます。 カスタムログライターを設定することで、ロギング出力データをカスタムストアに書き込むこともできます。 OPC UA から Amazon S3 と AWS IoT Core への設定例 以下は OPC UA サーバーからデータを読み取り、データ加工や集計を行わずに AWS IoT Core サービスの MQTT トピックと Amazon S3 バケット内のオブジェクトに直接送信する簡単な設定例です。 さらに、下の画像には登場していませんがデバッグターゲットが含まれており、デバッグ目的でデータをコンソールに送信します。 図：設定ファイルで定義された構成のイメージ SFC 設定ファイル { "AWSVersion": "2022-04-02", "Name": "OPCUA to S3, IoT Core and console", "Schedules": [ { "Name": "OPCUA-DATA", "Interval": 1000, "Sources": { "OPCUA-SOURCE": ["*"] }, "Targets": ["IoTCoreTarget", "S3Target", "DebugTarget"] } ], "Sources": { "OPCUA-SOURCE": { "Name": "OPCUA-SOURCE", "ProtocolAdapter": "OPC-UA", "AdapterOpcuaServer": "OPCUA-SERVER", "SourceReadingMode": "Subscription", "Channels": { "ServerStatus": { "NodeId": "ns=0;i=2256" }, "SimulationCounter": { "NodeId": "ns=3;i=1001" }, "SimulationRandom": { "NodeId": "ns=3;i=1002" }, "LevelAlarm": { "NodeId": "ns=6;s=MyLevel.Alarm", "EventType": "ExclusiveLevelAlarmType" } } } }, "ProtocolAdapters": { "OPC-UA": { "AdapterType": "OPCUA", "OpcuaServers": { "OPCUA-SERVER": { "Address": "opc.tcp://sfc-server", "Path": "OPCUA/SimulationServer" } } } }, "Targets": { "IoTCoreTarget": { "TargetType": "AWS-IOT-HTTP", "TopicName": "sfc-data-topic", "Region": "eu-west-1", "CredentialProviderClient": "AwsIotClient" }, "S3Target": { "TargetType": "AWS-S3", "Region": "eu-west-1", "BucketName": "sfc-data-bucket", "Interval": 60, "BufferSize": 1, "CredentialProviderClient": "AwsIotClient", "Compression": "Zip" }, "DebugTarget": { "TargetType": "DEBUG-TARGET" } }, "AdapterTypes": { "OPCUA": { "JarFiles": ["/sfc/opcua/lib"], "FactoryClassName": "com.amazonaws.sfc.opcua.OpcuaAdapter" } }, "TargetTypes": { "AWS-IOT-HTTP": { "JarFiles": ["/sfc/aws-iot-http-target/lib"], "FactoryClassName": "com.amazonaws.sfc.awsiot.http.AwsIotHttpTargetWriter" }, "AWS-S3": { "JarFiles": ["/sfc/aws-s3-target/lib"], "FactoryClassName": "com.amazonaws.sfc.awss3.AwsS3TargetWriter" }, "DEBUG-TARGET": { "JarFiles": ["/sfc/debug-target/lib"], "FactoryClassName": "com.amazonaws.sfc.debugtarget.DebugTargetWriter" } }, "AwsIotCredentialProviderClients": { "AwsIotClient": { "IotCredentialEndpoint": "1234567890abcd.credentials.iot.eu-west-1.amazonaws.com", "RoleAlias": "TokenExchangeRoleAlias", "ThingName": "MyThingName", "Certificate": "/sfc/cert/certificate.crt", "PrivateKey": "/sfc/cert/private.key", "RootCa": "/sfc/cert/root.pem" } } } 設定のポイントとなる項目 Schedule : 設定の中心となるのが Schedule (スケジュール) で、この例では ‘OPCUA-DATA’ です。 このスケジュールは、データ取得のソースの概要を示し、収集間隔をミリ秒単位で設定し、データ配信のターゲットとなる宛先を指定します。 Sources : このセクションでは、データソースについて記述します。 この例では、単一の OPC UA ソースが定義されています。 このソース内の詳細として、アダプター名とデータの取得元となるアダプター内の特定のサーバーが含まれます。 チャンネルには、さまざまなタイプのソースアダプターに合わせたデータ項目が含まれています。 この例における OPC UA アダプターの場合、これらのチャンネルはデータノード、イベント、アラームなどのデータ項目を表し、それぞれが固有のノード ID で識別されます。 Protocol Adapters : 使用されるプロトコルアダプターは、このセクションで定義します。 各プロトコルアダプタータイプには固有の要素があります。 この例で使用されている OPC UA アダプターの場合、データが読み取られる実際の OPC UA サーバーの定義があります。 Targets : このセクションでは、データを配信する宛先を定義します。 ターゲットの種類ごとに、Amazon S3 ターゲットの場合は Amazon S3 バケット名、AWS IoT Core アダプターの場合はトピック名など、特定の要素があります。 Adapter Types and Target Types: 各アダプターとターゲットは各々の設定を持ちます。これらは AdapterTypes または TargetTypes セクションで設定する必要があります。 それぞれのタイプは、アダプターまたはターゲットを実装する JAR ファイルをロードする場所と、これらのインスタンスを作成するためのファクトリークラスの名前を定義します。 SFC コアは、この情報を使用して必要なアダプターとターゲットのインスタンスを作成します。 (注:これらのセクションは、アダプターまたはターゲットが SFC コアと同じプロセスで実行されている場合にのみ必要です。 アダプターまたはターゲットが IPC サービスとして実行される場合、アダプターはプロトコルまたはターゲットサーバーを参照します。これにより、アクセス可能なアドレスとポートが定義されます。) AWS IoT Credential Provider Clients: このセクションでは、AWS サービスへのアクセスを必要とするターゲットが使用するクライアントを定義します。各クライアントは、一時的な資格情報を取得するための X.509 証明書とキーファイルのセットを使用します。ロールエイリアスは、AWS サービスへのアクセスを許可するロールを指します。詳細については、AWS Security ブログの記事 “How to Eliminate the Need for Hardcoded AWS Credentials in Devices by Using the AWS IoT Credentials Provider” を参照してください。 SFC を利用開始するには SFC はソースコードとして提供されており、 https://github.com/aws-samples/shopfloor-connectivity から入手できます。GitHub の SFC リポジトリには、SFC の構成方法とカスタムコンポーネントの作成方法について詳しく説明されたドキュメントが含まれています。事前ビルドされた SFC パッケージは、 https://github.com/aws-samples/shopfloor-connectivity/releases からダウンロードできます。 SFC リポジトリには、この記事で使用した例の SFC のデプロイと構成に必要な手順を説明する包括的なクイックスタートガイドも含まれています。 投稿者について Arie Leeuwesteijn アマゾン ウェブ サービス (AWS) のプリンシパルソリューションビルダーである Arie Leeuwesteijn は、産業および製造業のクライアントに合わせたクラウドソリューションの設計を専門としています。 企業顧客を導く専門知識を持つ彼は、運用の最適化とビジネス価値の向上を目的としたクラウドサービスの実用化を促進しています。 このブログはソリューションアーキテクトの黒田が翻訳しました。原文は こちら です。

このブログは 2024 年 4 月 17 日に Bukhtawar Khan によって執筆された内容を翻訳したものです。原文は こちら を参照して下さい。 Amazon OpenSearch Service は最近、OpenSearch Optimized インスタンスファミリー (OR1) を導入しました。これは、内部ベンチマークで既存のメモリ最適化インスタンスと比較して最大 30% のコストパフォーマンスの向上を実現し、 Amazon Simple Storage Service (Amazon S3) を使用して 99.9999999% (イレブンナイン) の耐久性を提供します。この新しいインスタンスファミリーにより、OpenSearch Service は OpenSearch のイノベーションと AWS のテクノロジーを使用して、クラウドでのデータのインデックス作成と保存方法を再考します。 今日、お客様は大量のデータを取り込みながら、豊富でインタラクティブな分析を提供する機能により、運用分析に OpenSearch Service を広く使用しています。これらの利点を実現するために、OpenSearch は、データのインデックス作成とリクエストの処理を行う複数の独立したインスタンスを持つ大規模な分散システムとして設計されています。運用分析データが生成される速度と量が増加するにつれ、ボトルネックが発生する可能性があります。高いインデックス作成ボリュームを持続的にサポートし、耐久性を提供するために、OR1 インスタンスファミリーが構築されました。 この投稿では、OR1 インスタンスの新しいデータフローがどのように機能するか、新しい物理レプリケーションプロトコルによって高いインデクシングスループットと耐久性をどのように実現しているのかについて説明します。また、正確性とデータの整合性を維持するために解決したいくつかの課題についても詳しく説明します。 高スループットとイレブンナインの耐久性のための設計 OpenSearch Service は数万の OpenSearch クラスターを管理しており、高スループットと耐久性の目標を達成するために、お客様が使用する典型的なクラスター構成についての洞察を得ています。より高いスループットを達成するために、お客様はレプリカコピーを削除することでレプリケーションのレイテンシーを節約することがよくありますが、この構成では可用性と耐久性が犠牲になります。他のお客様は高い耐久性を必要とするため、複数のレプリカコピーを維持する必要があり、その結果、運用コストが高くなります。 OpenSearch Optimized インスタンスファミリーは、Amazon S3 にデータのコピーを保存することで、コストを低く抑えながら更なる耐久性を提供します。OR1 インスタンスでは、インデックス作成のスループットを維持しながら、高い読み取り可用性のために複数のレプリカコピーを構成しながら、インデックス作成のスループットを維持できます。 次の図は、OR1 でのメタデータ更新を含むインデックス作成フローを示しています インデクシングでは、個々のドキュメントは Lucene にインデックス付けされ、translog と呼ばれる先行書き込みログも追加されます。クライアントに確認応答を送り返す前に、すべての translog 操作は Amazon S3 でバックアップされたリモートデータストアに永続化されます。レプリカコピーが構成されている場合、プライマリコピーは正確性を保つためにすべてのレプリカコピーで複数のライターの可能性を検出するためのチェック (制御フロー) を実行します。 次の図は、OR1 インスタンスでのセグメント生成とレプリケーションのフローを示しています 新しいセグメントファイルが作成されるたびに、OR1 はそれらのセグメントを Amazon S3 にコピーします。転送が完了すると、プライマリは新しいセグメントがダウンロード可能になったことをすべてのレプリカコピーに通知する新しいチェックポイントを公開します。その後、レプリカコピーは新しいセグメントをダウンロードし、検索可能にします。このモデルは、Amazon S3 を使用して行われるデータフローと、ノード間トランスポート通信を介して行われる制御フロー (チェックポイントの公開と用語の検証) を分離します。 次の図は、OR1 インスタンスでのリカバリーフローを示しています OR1 インスタンスは、データだけでなく、インデックスマッピング、テンプレート、設定などのクラスターメタデータも Amazon S3 に永続化します。これにより、非専用のクラスターマネージャーセットアップでは一般的な障害モードであるクラスターマネージャークォーラムの損失が発生した場合でも、OpenSearch が最後に確認されたメタデータを確実に回復できるようになります。 インフラストラクチャの障害が発生した場合、OpenSearch ドメインは 1 つ以上のノードを失う可能性があります。このような場合、新しいインスタンスファミリーは、最後に確認された操作までのクラスターメタデータとインデックスデータの両方の回復を保証します。交換される新しいノードがクラスターに参加すると、内部クラスターリカバリーメカニズムは新しいノードのセットをブートストラップし、リモートクラスターメタデータストアから最新のクラスターメタデータを回復します。クラスターメタデータが回復された後、リカバリーメカニズムは、Amazon S3 から不足しているセグメントデータと translog を復元し始めます。次に、最後に確認された操作までのすべての未コミットの translog 操作が再生され、失われたコピーが復元されます。 OR1 の新しい設計では、検索の仕組みは変更されません。クエリは、インデックス内の各シャードのプライマリまたはレプリカシャードのいずれかによって通常どおり処理されます。データのレプリケーションに Amazon S3 を使用しているため、特定の時点ですべてのコピーが一貫性を保つまでに長い遅延 (10 秒程度) が発生する可能性があります。 このアーキテクチャの主な利点は、リーダーとライターの分離、コンピューティングレイヤーとストレージレイヤーの分離など、将来のイノベーションの基礎となるビルディングブロックとして機能することです。 レプリケーション戦略を再定義することでインデックス作成のスループットが向上する仕組み OpenSearch は、論理 (ドキュメント) レプリケーションと物理 (セグメント) レプリケーションの 2 つのレプリケーション戦略をサポートしています。論理レプリケーションの場合、データはすべてのコピーで個別にインデックス付けされるため、クラスターで冗長な計算が行われます。OR1 インスタンスは、データがプライマリコピーでのみインデックス付けされ、プライマリからデータをコピーすることで追加のコピーが作成される新しい 物理レプリケーション モデルを使用します。レプリカコピーの数が多い場合、プライマリコピーをホストするノードは、セグメントをすべてのコピーにレプリケートするために大量のネットワーク帯域幅を必要とします。新しい OR1 インスタンスは、 リモートストレージ オプションとして構成されている Amazon S3 にセグメントを永続的に保存することで、この問題を解決します。また、プライマリでのボトルネックなしにレプリカのスケーリングにも役立ちます。 セグメントが Amazon S3 にアップロードされた後、プライマリは新しいセグメントをダウンロードするようにすべてのレプリカに通知するチェックポイントリクエストを送信します。その後、レプリカコピーは増分セグメントをダウンロードする必要があります。このプロセスにより、データを冗長にインデックス付けするために必要なレプリカのコンピューティングリソースと、プライマリでデータをレプリケートするために発生するネットワークオーバーヘッドが解放されるため、クラスターはより多くのスループットを処理できます。レプリカが過負荷や遅いネットワークパスなどにより新しく作成されたセグメントを処理できない場合、レプリカは古い結果を返さないように一定のポイントを超えて失敗としてマークされます。 高い耐久性が良い理由と、それを適切に行うのが難しい理由 コミットされたすべてのセグメントは、作成されるたびに Amazon S3 に永続的に保存されますが、高い耐久性を達成する上での主な課題の 1 つは、スループットを犠牲にすることなく、クライアントへ確認応答を返す前にすべての未コミットの操作を Amazon S3 の translog に同期的に書き込むことです。新しいセマンティクスでは、個々のリクエストに追加のネットワークレイテンシーが発生しますが、他のスレッドがインデックスのリクエストを続けながら、指定された間隔まで単一のスレッドでリクエストをバッチ処理してドレインすることで、スループットへの影響がないようにしました。その結果、バルクペイロードを最適にバッチ処理することで、より多くの同時クライアント接続でより高いスループットを実現できます。 高い耐久性のあるシステムを設計する上での他の課題には、常にデータの整合性と正確性を強制することが含まれます。ネットワークパーティションなどの一部のイベントはまれですが、システムの正確性を損なう可能性があるため、システムはこれらの障害に対処する準備ができている必要があります。したがって、新しいセグメントレプリケーションプロトコルに切り替える際に、各レプリカで複数のライターを検出するなど、いくつかの他のプロトコルの変更も導入しました。このプロトコルは、クラスターマネージャークォーラムに基づいて新しく昇格されたプライマリが同時に新しい書き込みを受け入れている間に、分離されたライターが書き込みリクエストに応答できないようにします。 新しいインスタンスファミリーは、データの回復中にプライマリシャードの損失を自動的に検出し、Amazon S3 からデータを再ハイドレートしてクラスターを正常な状態に戻す前に、ネットワークの到達可能性に関する広範なチェックを実行します。 データの整合性のために、すべてのファイルは広範にチェックサムされ、ネットワークまたはファイルシステムの破損によってデータが読み取り不能になる可能性を検出して防止できるようにします。さらに、メタデータを含むすべてのファイルは不変になるように設計されており、破損に対する更なる安全性を提供し、偶発的な変更を防ぐためにバージョン管理されています。 データフローの再構想 OR1 インスタンスは、インフラストラクチャ障害時に失われたシャードのリカバリを実行するために、Amazon S3 から直接コピーを復元します。Amazon S3 を使用することで、プライマリノードのネットワーク帯域幅、ディスクスループット、およびコンピュートを解放でき、プライマリノードの調整を最小限に抑えてプロセス全体を調整することで、よりシームレスなインプレーススケーリングとブルー/グリーンデプロイメントエクスペリエンスを提供できます。 OpenSearch Service は、スナップショットと呼ばれる自動データバックアップを 1 時間間隔で提供します。これは、データが誤って変更された場合に、以前の時点の状態に戻るオプションがあることを意味します。しかし、新しい OpenSearch インスタンスファミリーでは、データがすでに Amazon S3 に永続的に保存されていることを説明しました。では、データがすでに Amazon S3 に存在する場合、スナップショットはどのように機能するのでしょうか？ 新しいインスタンスファミリーでは、スナップショットはチェックポイントとして機能し、ある時点で存在するセグメントデータを参照します。これにより、追加のデータを再アップロードする必要がないため、スナップショットはより軽量で高速になります。代わりに、その時点でのセグメントのビューを取得するメタデータファイルをアップロードします。これをシャロースナップショットと呼びます。シャロースナップショットの利点は、作成、削除、複製など、すべての操作に及びます。他の管理操作用に、 手動スナップショット で独立したコピーをスナップショットするオプションもあります。 まとめ OpenSearch はオープンソースのコミュニティ主導のソフトウェアです。レプリケーションモデル、リモートバックドストレージ、リモートクラスターメタデータなどの基本的な変更のほとんどは、オープンソースに貢献されています。事実、私たちはオープンソースファーストの開発モデルに従っています。 スループットと信頼性を向上させる取り組みは、学習と改善を続ける限り終わりのないサイクルです。新しい OpenSearh の最適化されたインスタンスは、将来のイノベーションへの道を開くビルディングブロックの基礎として機能します。私たちは信頼性とパフォーマンスの向上に向けた取り組みを継続し、新規および既存のソリューションビルダーが OpenSearch Service を使用して何を作成するかを楽しみにしています。本ブログにより、新しい OpenSearch インスタンスファミリーについての理解が深まり、このオファリングがどのように高い耐久性とより良いスループットを実現し、ビジネスのニーズに基づいてクラスターを構成するのに役立つかを理解できることを願っています。 OpenSearch への貢献に興味があれば、 GitHub issue を開いてあなたの考えを教えてください。また、OpenSearch Service で高いスループットと耐久性を実現した成功事例についてもぜひお聞かせください。 著者について Bukhtawar Khan &nbsp;は Amazon OpenSearch Service のプリンシパルエンジニアです。分散型および自律型システムの構築に興味を持っています。OpenSearch のメンテナーであり、アクティブなコントリビューターです。 Gaurav Bafna は Amazon Web Services で OpenSearch のシニアソフトウェアエンジニアです。分散システムの問題解決に興味を持っています。OpenSearch のメンテナーであり、アクティブなコントリビューターです。 Sachin Kale は AWS で OpenSearch のシニアソフトウェア開発エンジニアです。 Rohin Bhargava は Amazon OpenSearch Service チームのシニアプロダクトマネージャーです。AWS での情熱は、顧客がビジネス目標を達成するために適切な AWS サービスの組み合わせを見つけるのを助けることです。 Ranjith Ramachandra は、Amazon OpenSearch Service のシニアエンジニアリングマネージャーです。ハイスケーラブルな分散システム、高性能でレジリエントなシステムに情熱を注いでいます。

English follows Japanese. Amazon Web Services （AWS）では、お客様の信頼を得て維持することが継続的な取り組みとなっています。お客様の業界のセキュリティ要件に応じて、コンプライアンスレポート、証明書、認証の範囲とポートフォリオを決定しています。 AWS が「政府情報システムのためのセキュリティ評価制度（以下、ISMAP ）」の下で更新（2024年4月30日付で 2024 年 12 月 31 日まで）されたことをお知らせいたします。 今回の登録範囲は、5リージョンが新たに追加されAWS アジアパシフィック（東京）リージョンと AWS アジアパシフィック（大阪）リージョンを含む 28 リージョンであり、 AWSサービスの14件追加されAmazon Bedrock を含む合計 171のAWS サービスです。 AWS は、2020 年 3 月に発効されて以来、ISMAP 運営委員会によるISMAP への認定を継続しております。 ISMAP は、パブリッククラウドサービスのセキュリティを評価する日本政府のプログラムです。ISMAP の目的は、政府調達のベースライン要件として、クラウドサービス事業者（CSP ）が遵守すべき共通のセキュリティ基準を示すものとなります。 本制度では、CSP が実施しなければならないクラウド・ドメイン、プラクティス、およびプロシージャに関するセキュリティ要件を導入しています。CSP は、ISMAP 登録事業者として申請するために、ISMAP が認定する第三者評価者である監査機関と契約し、セキュリティ要件への準拠を評価したうえで、日本政府のセキュリティ要件を満たした事業者として登録を行います。 ISMAP によるCSP の登録により、政府の調達部門や機関および重要インフラに該当するお客様は、登録されたCSP との連携を促進し、政府情報システムへのクラウドサービスの円滑な導入に貢献することができます。今回の更新は、日本政府が定めたコンプライアンス要件を満たし、安全なAWS のサービスをお客様に提供するために、AWS が積極的に取り組んできたことを示すものです。AWSを利用するサービスプロバイダーや顧客は、AWS サービスのISMAP 認証を活用して、自社のISMAP 認証プログラムをサポートすることができます。 ISMAP に登録されたAWSサービスの全リストは、 AWS Services in Scope by Compliance Program&nbsp; で公開されております。 なお、ISMAP において登録されるクラウドサービスはAmazon Web Services となり、お客様はAmazon Web Services 全体の登録を受けたクラウドサービスとして利用することが可能です。AWS は、今回の監査対象期間において評価されたAWS の各種サービスを登録しています。AWS は継続的にサービスのアップデート、追加を行い、お客様への価値を提供しています。本登録外のサービスにおいても、お客様は各サービスの開発者ガイド、他の第三者による監査レポートの確認などによるリスク評価の上、お客様が設計するサービスへの利用可否を判断することが可能です。 また、AWS をインフラストラクチャとしてISMAP への登録を計画されているサービスプロバイダやお客様は、AWS Artifact よりISMAP Customer Package を利用することにより、責任共有モデルに基づくAWSの責任範囲とお客様の責任範囲、ISMAP において求められている様々なAWS からの情報提供、機能提供の概要を確認することが出来ます。なお、今回の更新にともない、ISMAP Customer Package の更新を予定しております。 なお、AWS の登録状況の確認や詳細なスコープ情報は、 ISMAP ポータル で確認することができます。 AWS では、これまで同様、お客様のビジネスニーズに基づいて、新しいサービスやリージョンをISMAP プログラムの対象にしていくことをお約束します。AWS におけるISMAP 認証の概要については、 ISMAP コンプライアンスページ を参照してください。ご不明な点がございましたら、ご遠慮なくAWSアカウントマネージャーまでお問い合わせください。 なお、Amazon Bedrock は、単一の API を介して AI21 Labs、 Anthropic、 Cohere、 Meta、 Mistral AI、 Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデル (FM) を選択できるフルマネージドサービスで、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供します。基盤モデル自体は、本ISMAP の対象範囲ではありません。詳しくは Amazon Bedrock の「よくある質問」 をご参照ください。 本Blogは、竹内 英稔、セキュリティアシュアランス本部グローバルAWSアシュアランス部 監査部長（日本）、および、松本 照吾、セキュリティアシュアランス本部セキュリティ本部 本部長、により執筆いたしました。 Earning and maintaining customer trust is an ongoing commitment at Amazon Web Services (AWS). Our customers’ security requirements drive the scope and portfolio of the compliance reports, attestations, and certifications we pursue. We’re excited to announce that AWS has achieved authorization under the Information System Security Management and Assessment Program (ISMAP) program, effective from December 1, 2023 to December 31, 2024. The authorization scope covers a total of 171 AWS services (an increase of 14 services over the previous authorization) including Amazon Bedrock, and across 28 AWS Regions (an increase of 5 Region over the previous authorization) including the Asia Pacific (Tokyo) Region and the Asia Pacific (Osaka) Region. This is the fourth time AWS has undergone an assessment since ISMAP was first published by the ISMAP steering committee in March 2020. ISMAP is a Japanese government program for assessing the security of public cloud services. The purpose of ISMAP is to provide a common set of security standards for cloud service providers (CSPs) to comply with as a baseline requirement for government procurement. ISMAP introduces security requirements for cloud domains, practices, and procedures that CSPs must implement. CSPs must engage with an ISMAP-approved third-party assessor to assess compliance with the ISMAP security requirements in order to apply as an ISMAP-registered CSP. The ISMAP program will evaluate the security of each CSP and register those that satisfy the Japanese government’s security requirements. Upon successful ISMAP registration of CSPs, government procurement departments, agencies, and critical infrastructure companies can accelerate their engagement with the registered CSPs and contribute to the smooth introduction of cloud services in government information systems. The achievement of this authorization demonstrates the proactive approach AWS has taken to help customers meet compliance requirements set by the Japanese government and to deliver secure AWS services to our customers. Service providers and customers of AWS can use the ISMAP authorization of AWS services to support their own ISMAP authorization programs. The full list of 171 ISMAP-authorized AWS services is available on the AWS Services in Scope by Compliance Program webpage , Note that the cloud service registered in ISMAP is Amazon Web Services, and customers can look as the scope. AWS has registered various AWS services under Amazon Web Services that have been evaluated during this audit period. AWS is continuously updating and adding services to provide value to customers. Even for services other than this registration, customers can determine whether or not they can be used for services designed by the customer after risk assessments based on the developer guide for each service, confirmation of audit reports by other third parties, etc. Also, by using the ISMAP Customer Package from AWS Artifact, our customers or partners can check the scope of responsibility of AWS and the scope of responsibility of customers based on the shared responsibility model, and the provision of information and functions from various AWS required by ISMAP. Note that we are planning to update the ISMAP Customer Package along with this update. And you can confirm the AWS ISMAP authorization status and find detailed scope information on the ISMAP Portal . As always, we are committed to bringing new services and Regions into the scope of our ISMAP program, based on your business needs. For an overview of ISMAP certification on AWS, see the ISMAP compliance page . If you have any questions, don’t hesitate to contact your AWS Account Manager. This blog was written by Takeuchi Hidetoshi, Security Assurance Division Global AWS Assurance Department Audit Manager (Japan), and Matsumoto Shogo, Head of Security Assurance, Japan.

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 2024 年 9 月 26 日 (水) 13:00 ~ 17:10 に、モダナイゼーションやマイグレートをテーマにした AWS Innovate が開催されます。モダナイズによりビジネス価値を生み出すための主要なコンポーネントである、インフラ、アプリ、データの観点から最新のモダナイズ手法を学べるセミナーです。オンライン開催で空き時間に参加がしやすくなっており、ぜひ事前登録の上ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月19日週の主要なアップデート 8/19(月) AWS Code Build で Mac を利用したビルドサポート AWS CodeBuild で macOS アプリケーションをビルドできるようになりました。Apple M2 インスタンス上で macOS 14 Sonoma を稼働し、macOS アプリケーションのビルドを行う仕組みです。Apple システム (iOS、iPadOS、watchOS、tvOS、macOS) 向けのアプリケーションをビルド、テスト、署名、配布するには、Xcode を使用する必要がありますが、これを CodeBuild で対応できるようになった形です。料金についての留意点ですが、CodeBuild for macOS はリソースを事前に予約する仕組みで動作するため、ビルドが実行されていなくても、ビルド用マシンが確保されている時間分の料金が発生します。詳細は こちらのブログ をご参照ください。 Amazon S3 で認証されていない HTTP アクセスの料金を無料に変更 Amazon S3 は、認証されていないリクエストを無料にする変更を完了しました。この変更により、バケット所有者は、個々の AWS アカウントまたは AWS Organization の外部からリクエストを受けた場合、HTTP 403 (Access Denied) エラー応答を返しますが、認証されていないリクエストに関する料金は発生しません。2024 年 5 月 13 日にアナウンスされ、大半の S3 API に適用しましたが、現在すべての S3 API で対応しました。 SageMaker Pipelines で ML ワークフローを簡単に作成するドラッグ &amp; ドロップ UI の対応 SageMaker Studio 内で利用できる SageMaker Pipelines で ML ワークフローを作成する際に、ドラッグ &amp; ドロップでアイコンを配置する、視覚的にわかりやすい UI にアップデートしました。データサイエンティストや ML エンジニアは、コーディングをせずに、エンドツーエンドのAI/MLワークフローを作成して、モデルの Training、Fine-tune、デプロイができるようになりました。 こちらのドキュメント に新 UI の画像付きで紹介されています。 8/20(火) Amazon S3 で条件付き書き込みのサポートを追加 Amazon S3 で、オブジェクトの作成前にそのオブジェクトの存在をチェックできる条件付き書き込みのサポートを追加しました。この機能により、データのアップロード時に既存のオブジェクトを上書きしないようにする処理の簡素化などに利用できます。データのアップロード前にオブジェクトの存在をチェックする処理や、クライアントサイドのメカニズムを構築するといった負担を軽減できます。大規模な分析、分散機械学習、その他の高度に並列化されたワークロードのパフォーマンスやコスト効率の向上といったメリットがあります。 AWS Lambda で関数ごとに再帰的ループ検出の機能管理 AWS Lambda は関数ごとに再帰ループ検出の有効 or 無効を指定する機能をサポートしました。デフォルトで有効になっている Lambda の再帰ループ検出は、サポートされているサービス間の再帰呼び出しを自動的に検出して停止する予防的な機能です。いわゆる、無限ループを検知する機能となります。いままでは AWS アカウント単位の指定でしたが、関数レベルで制御できるようになりました。 8/21(水) Amazon Bedrock でバッチ推論機能の一般提供開始 Amazon Bedrock でプレビュー提供していたバッチ推論機能の一般提供を開始しました。バッチ推論は、推論リクエストを非同期で実行し、あとから結果を取得する仕組みです。オンデマンド料金の 50 % で利用できる点や、 Service Quota がオンデマンドとバッチ推論で分離されているのがうれしいポイントです。バッチ推論の完了時間は、ジョブのサイズなどさまざまな要因に依存しますが、一般的には 24 時間以内に完了すると期待できます。Anthropic、Meta、Mistral AI、Amazon のモデルで利用が可能ですが、リージョンによって利用可否が異なるため、 詳細はこちらの表 をご参照ください。 Amazon EventBridge Scheduler でデフォルトの Service Quota の上限緩和 Amazon EventBridge Scheduler でデフォルトのサービスクォータが引き上げられ、スケジュール数のクォータが 100 万から 1,000 万に、呼び出しスループットのクォータが 500 から 1,000 呼び出し/秒に増えました。また、CreateSchedule、DeleteSchedule、GetSchedule、UpdateSchedule の API リクエストレートのデフォルトクォータが、50 から 1,000 リクエスト/秒に引き上げられました。さらに上限を緩和したい場合、Service Quotas コンソールからリクエストする仕組みがあります。 8/22(木) AWS IAM で AWS PrivateLink をサポート AWS Identity and Access Management (IAM) で、AWS PrivateLink をサポートしました。PrivateLink を使用すると、IAM ロールの管理や一時的な認証情報の取得などを、パブリックインターネットを経由せずに AWS リソースへリクエストができます。組織内のセキュリティ基準を満たす選択肢が拡充した形です。 AWS CloudFormation の IaC Generator でリソース検出とテンプレートレビュー機能のアップデート AWS CloudFormation で、既存のリソースから CloudFormation Template ファイルを生成する IaC Generator に 2 つの新機能のアップデートがありました。IaC Generator がアカウント内のリソースのスキャンを終了した後、テンプレートに含めたいリソースをより簡単に見つけられるよう、さまざまなリソースタイプのグラフィカルな概要を表示するようになりました。また、リソースを選択した後、AWS Application Composer でテンプレートをプレビューできるようになり、視覚的に確認がやりやすくなりました。 AWS Amplify で複数の S3 バケットをサポート AWS Amplify で複数の S3 バケットのサポートを開始しました。Amplify Storage 機能は S3 と統合されており、ファイルのアップロードやダウンロードをライブラリ経由で簡単に実装できます。JavaScript ライブラリのみのサポートですが、アップロードやダウンロードを実装する際に、複数の S3 バケットを指定できるようになりました。詳細は こちらのブログ記事 をご参照ください。 8/23(金) Knowledge Bases for Amazon Bedrock で Claude 3.5 Sonnet をサポート Knowledge Bases for Amazon Bedrock で Claude 3.5 Sonnet をサポートしました。 Knowledge Bases には、RetrieveAndGenerate API があり、ユーザーのリクエストに基づくデータの取得と、テキスト生成をしてくれるものですが、この機能で Claude 3.5 Sonnet をサポートした形です。利用できるリージョンは、東京、バージニア北部、オレゴン、フランクフルトの 4 つです。 Amazon Connectは、コールバックを設定する新しい方法をサポート Amazon Connect で、コールバックを作成する前と、キューに入っている間にアクションを実行するフローを設定できるようになりました。例えば、お客様に電話をかける前に SMS で通知を自動送信したり、エージェントが参照できるように最新のお客様データに基づいてコールバック属性を更新したり、問題がすでに解決されている場合はコールバックを終了させることができます。また、お客様プロファイルやサードパーティアプリケーションからのお客様情報に基づいて、コールバックの優先順位を動的に変更したり、別のキューに転送したりすることも可能です。コールバックキューの処理が遅れすぎている場合にも同様の対応ができます。 AWS CDK のアップデート情報が、X のハッシュタグ #cdk_release でまとめられています。バージョン v2.154.0 では、Knowledge Bases for Amazon Bedrock で Advanced RAG を行う機能、やPDF 内の画像を読み取るための Advanced Parsing 機能を CDK L1 コンストラクトでサポートしています。また、Parameter Store のクロスアカウント対応や、ALB の mTLS サポートなどがあります。CDK に興味がある方は、X のハッシュタグ #cdk_release も定期的にご覧いただけますと幸いです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 9月26日に、オンラインイベント「 AWS Innovate 」が開催されます。このイベントは定期的に開催しているものですが、今回のテーマは「Migrate. Modernize. Build.」です。変化が早い時代に対応するためには、生成AIをはじめとする新しい技術の活用を視野に入れつつ、自分達も素早く変化することが必要です。今回のAWS Innovateではアジリティ、俊敏性を高めるためのヒントをお届けします。無料でご参加頂けますので、皆様のご参加をお待ちしています。 「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、8 月 19 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ユビタス様、Amazon EC2とAWS ParallelClusterにより大規模言語モデル開発を加速 株式会社ユビタス 様は、AIキャラクターソリューション「 UbiONE 」を展開しています。これは金融や医療など様々な業界向けにカスタマイズされた対話型のソリューションですが、各業界には固有の要件がありカスタマイズが必要です。ですが、従来の開発アプローチではこのカスタマイズに多大な労力とリソースが必要でした。これを解決するために Amazon EC2 P5インスタンス と AWS ParallelCluster を活用することで、学習時間を従来比で90%短縮するという成果を出しています。同時にフロントエンド環境としてAWSのサービスを組み合わせる事で、複数のカスタマイズされたAIキャラクターを高速に構築・管理できるようになりました。 ブログ記事「新入社員プロジェクト生成 AI を活用した Virtual Summit Assistant展示実施報告 @ AWS Summit Japan 2024」を公開 6月20日21日に開催したAWS Summit Japanでは、入社2年目の社員がチームを組み「Virtual Summit Assistant」を開発しました。これは生成AIを活用してAWS Summit Japanの来場者に対して会場配置やお勧めセッションを案内するアシスタントです。このブログ記事では開発の取り組みやアーキテクチャ、ブース展示などについて紹介しています。お客様への案内をするアシスタントは生成AIの活用領域として注目される分野のひとつです。そのための参考になる情報が詰まっていますので、ぜひご覧ください。 ブログ記事「PartyRock 展示で見えた生成 AI の可能性 – 業務活用への道筋 (AWS Summit Japan 2024)」を公開 こちらもAWS Summit Japanに関連したブログ記事で、生成AIを組み込んだアプリを簡単に試せるPartyRockに関するブース展示についての紹介記事です。このブース展示では新入社員がサポーターとしてお客様へのご説明やサポートを担当していました。たくさんのお客様とのやりとりを通じて感じた、「PartyRockからはじめる生成AIの業務活用」のアプローチ方法について紹介しています。 ブログ記事「AWS で大規模言語モデルにより生成された関数を使ってお客様がロボット学習を包括的に訓練する方法」を公開 ロボット工学の分野では、複雑な操作をともなう問題をはじめ古典的な経路計画アルゴリズムでは効率的に処理できないケースへの対応として、強化学習という技術が活用されています。強化学習においては、行動の成否を測る報酬関数を設計することが不可欠です。この記事では、大規模言語モデルを利用して報酬関数を生成するアプローチについて解説しています。 ブログ記事「Amazon Connectの生成AIによるエージェント生産性向上」を公開 前回の週刊生成AI with AWS でご紹介した「 Amazon Connect Contact Lensが提供するエージェントのパフォーマンス評価機能が東京リージョンで利用可能に 」ですが、この機能を解説する日本語のブログ記事が公開されました。コンタクトセンターで、お客様からのお問い合わせに対応するエージェントの方を補助し、生産性を高めるための機能ですので、こういった課題感をお持ちの方は是非一度目を通していただくことをお勧めします。 スライド資料「100 以上の生成 AI 事例に見るビジネスインパクト創出の方程式」を公開 AWSでは、他の取り組みと同様に生成AIに取り組みたいと考えるお客様の支援にも力を入れています。現時点でも様々な事例が出てきており、お客様との議論を通じて得られた知見もあります。これらの事例や知見をまとめたスライド資料を公開しました。このやり方が唯一の方法、という訳ではありませんが、ひとつの考え方として参考にして頂けるのではないでしょうか。 サービスアップデート Amazon Q Consoleでユーザが利用しているサブスクリプションの把握が容易に 管理者がAmazon Q Consoleを利用することで、ユーザが利用しているサブスクリプションを詳細に把握できるようになりました。具体的にはAmazon Q Developer Pro, Amazon Q Business Pro, Amazon Q Business Liteの利用状況を把握できます。ユーザ毎にサブスクリプションの状態(利用中、利用停止中、無料トライアル中など)を表示するとともに、ユーザが利用可能なアプリケーションやアカウントなどの関連情報も表示されます。これによってAmazon Qがどのように利用されているか、現状を把握することが容易になります。 Amazon Bedrockの一部モデルで、通常より50%安価なバッチ推論が利用可能に 基盤モデルの処理を非同期で実行するバッチ推論機能が一般利用開始になりました。バッチ推論を利用することで、モデルの評価や、即時性を必要としない一方で多くのパターンの処理が必要なケースへの対応が容易になります。また、今回Anthropic/Meta/Mistral AI/Amazonなどが提供する一部のモデルにおいて、バッチ推論の費用がオンデマンドの半額(50%)でご利用頂けるようになりました。リアルタイムの応答が必要ない場合はお得に利用できますので、ぜひご検討ください。 Knowledge Bases for Amazon BedrockでAnthropic Claude 3.5 Sonnetが利用可能に 検索拡張生成(RAG)を容易に実現できるKnowledge Bases for Amazon BedrockでAnthropicのClaude 3.5 Sonnetをご利用頂けるようになりました。このモデルは最大200,000のコンテキストウィンドウに対応し、複雑な推論や低レイテンシなど、RAGで頻繁に求められる性能を備えているとされています。 ブログ記事 もご覧ください。 Amazon SageMaker PipelinesでMLワークフロー作成向けにドラッグ&amp;ドロップ形式の操作が可能に Amazon SageMaker Pipelinesはデータの前処理からモデルのモニタリングまで、機械学習のワークフロー全体をオーケストレーションし自動化するためのサービスです。今回、一連のワークフローを設定する際にドラッグ&amp;ドロップで作業ができるようになり、コーディングが不要になりました。 Amazon SageMaker Canvasがデータフローのインポートに対応 コーディング不要で機械学習による正確な予測を実現するAmazon SageMaker Canvasでは、データ準備のための機能としてAmazon SageMaker Data Wranglerを利用できます。今回、このSageMaker Data WranglerがAmazon SageMaker Studio Classicからのデータフローのインポートに対応しました。これにより、機械学習の開発者やデータサイエンティストがSageMaker Studio Classicで開発したデータの前処理フローを流用して、SageMaker Canvasのユーザが簡単に高度なデータ処理を実行できるようになります。 ブログ記事 もありますのでこちらもどうぞ。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。