(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 2: Streams を翻訳した記事です。) この記事は、チャネルコーポレーションの TaeHun Yoon と Changsoon Kim と共同で執筆されました。 チャネルコーポレーション は、 B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップ企業で、オールインワン AI メッセンジャー「 チャネルトーク 」を運営しています。このシリーズの 第1部 では、 NoSQL 採用の動機、ビジネス成長に伴う技術的問題、そして PostgreSQL から Amazon DynamoDB への移行に関する考慮事項について紹介しました。この投稿では、 DynamoDB だけでは対処できなかった部分を解決するために、他のサービスと統合した経験を共有します。 背景：構造化データと非構造化データの取得問題 リレーショナルデータ設計と NoSQL にはいくつかの重要な違いがあります。 DynamoDB は、定義されたアクセスパターンに対する効率的なデータ取得に優れ、特定のクエリタイプに最適化されたパフォーマンスを提供します。この特徴により、次の チャネルコーポレーション のユースケースは DynamoDB だけでは解決が困難な状況でした。 様々なフィルタリング条件による構造化データの検索（メッセージ検索） – チャネルトーク はユーザーが会話を素早く検索できるようにします。ユーザーは、アサイン先、チーム、フォロワーなどの様々なフィルターを追加して検索することができる必要があります。次のスクリーンショットにその例を示します。 構造化されていないデータの検索（顧客データ検索） – 顧客データは、 チャネルコーポレーション の顧客が入力する情報に応じて異なるスキーマを持ちます。このスキーマは固定されておらず、執筆時点では、複数のフィールドを使用して最大 100 万件の顧客データレコードを迅速に検索できる必要があります。 チャネルコーポレーション は、これら 2 つの問題を解決するために DynamoDB と Amazon OpenSearch Service などの目的別検索サービスを使用する方が効果的で効率的であると判断しました。これを行うには、 DynamoDB と他のサービス間のデータ同期が必要です。 DynamoDB は Amazon OpenSearch Service とのゼロ ETL 統合を持っていますが 、 チャネルコーポレーション は現在、以下の理由で自己管理の ETL パイプラインを使用しています。 検索可能なデータに必要な最小限の情報のみを転送する必要がありました。また、特定の属性の値の変更を無視し、既存の値と現在の値の間の変更を比較する必要がありました 検索サービスで冪等性を確保するため、直接削除するのではなく、論理削除でレコードを変更および挿入する必要な場合がありました DynamoDB とのストリームインテグレーション 時系列に並んだ一連のイベントを ストリーム と呼びます。DynamoDB は、ストリームとして 変更データキャプチャ (CDC) を実行する 2 つの方法を提供します。 Amazon DynamoDB Streams は、DynamoDB テーブル内のアイテムレベルの変更の時系列順のシーケンスをキャプチャし、この情報を最大 24 時間ログに保存します。 Amazon Kinesis Data Streams は、DynamoDB テーブル内のアイテムレベルの変更をキャプチャし、それらを Kinesis データストリームに複製します。 チャネルコーポレーション は、これらのサービスを使用して、DynamoDB の変更データをストリームを介して検索性能の高いサービスに渡すことで、メッセージおよび顧客データ検索の問題を解決できました。 次の図は、DynamoDB Streams を使用したワークフローを示しています。 このソリューションは次の特性を提供します。 DynamoDB Streams からの読み取りは、 AWS Lambda ベースの消費者にとって無料です。 重複が削除された、時系列順のアイテムレベルの変更シーケンスを提供します。 しかし、次の点を考慮する必要があります： Lambda での障害やストリーム処理層での障害を処理する必要があります。 開始位置が LATEST に設定されている場合、 イベントを見逃す可能性 があります。 次の図は、 Kinesis Data Streams を使用したワークフローを示しています。 このソリューションは次の特性を提供します： Kinesis Data Streams と Lambda の両方のコストを含みます 最大 1 年間 のデータ保持期間を設定できます 5 つの開始位置オプション を提供します しかし、次の点を考慮する必要があります： Lambda やストリーム処理層での障害を処理する必要があります 開始位置が LATEST に設定されている場合、イベントを見逃す可能性があります 逆のイベントや重複したイベントが発生する可能性があります これをより詳細に理解するために、データが DynamoDB から各ストリームに渡される方法と、Lambda がストリーム上でどのように操作を実行するかを見てみましょう。 DynamoDB Streams DynamoDB は、各パーティション内の各アイテムに対して行われた変更を対応するシャードに送信し、変更が行われた順序を維持します。このプロセスは、特定のキーが最大 1 つのシャードに存在し、その順序が維持されることを保証にします。 Kinesis Data Streams Kinesis Data Streams のデータレコードは、アイテムの変更が発生したときとは異なる順序で表示される場合があり、同じアイテムの通知がストリームに複数回表示される場合があります。アイテムの変更が発生した順序を識別し、重複したレコードを識別するために、 ApproximateCreationDateTime 属性を確認することができます。 Lambda がストリーム上で処理を実行する方法 イベントソースマッピング は、ストリームおよびキューに基づくサービスからアイテムを読み取り、レコードのバッチで関数を呼び出す Lambda リソースです。イベントソースマッピングを使用して、 Lambda 関数を直接呼び出さないサービスのストリームまたはキューからのイベントを処理できます。 Lambda は DynamoDB Streams から直接呼び出されるのではなく、そのリソースを介して呼び出されることを理解して、各ソリューションと問題の特性に再度アプローチしましょう。 イベントソースマッピング構成の MaximumRecordAgeInSeconds および MaximumRetryAttempts 値を設定することで、基本的な再試行処理を処理できます。ただし、 Lambda コードのバグやデプロイ時の問題など、再試行のみでは解決できない障害が発生する可能性があります。 イベントソースマッピングリソース を参照すると、処理できなかったレコードに関する通知を Amazon Simple Queue Service （Amazon SQS） キューまたは Amazon Simple Notification Service （Amazon SNS） トピックに転送するための On-failure destination 設定を構成できます。次の例は、 DynamoDB ストリームの呼び出しレコードを示しています。 { "requestContext": { "requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction", "condition": "RetryAttemptsExhausted", "approximateInvokeCount": 1 }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "version": "1.0", "timestamp": "2019-11-14T00:13:49.717Z", "DDBStreamBatchInfo": { "shardId": "shardId-00000001573689847184-864758bb", "startSequenceNumber": "800000000003126276362", "endSequenceNumber": "800000000003126276362", "approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z", "approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z", "batchSize": 1, "streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388" } } 前述の情報に基づき、 DynamoDB Streams からレコードを取得して再試行する必要があります。DynamoDB Streams からレコードを取得して処理する際、すべてのイベントが時系列順に配信されるわけではないため、イベントの順序が乱れる可能性があります。 BatchSize が 1 を超え、一時的な障害により一部のアイテムの処理に失敗した場合、 Lambda は以前に処理されたレコードを含むバッチ全体を再試行します。適切に処理しないと、これにより重複イベントが発生する可能性があります。 さらに、イベントソースマッピングの開始位置が LATEST に設定されている場合、一部のイベントが見逃される可能性があります。 イベントソースマッピング に設定された MaximumRetryAttempts や MaximumRecordAgeInSeconds のような値は、初期設定と異なり、エラー処理や状況に応じて変更する必要があることがあります。この場合、一部のレコードが意図せず見逃される可能性があります。 この問題を解決するために開始位置を TRIM_HORIZON に変更すると、 DynamoDB Streams 内のすべてのデータが最初からイベントコンシューマーに配信され、イベントの重複処理が発生する可能性があります。 DynamoDB Streams と Kinesis Data Streams による問題解決 DynamoDB Streams と Kinesis Data Streams が同様の問題を解決する能力があると信じています。この記事では、次のユースケースについて説明します： すべてのストリーム処理関数を 冪等 に書くことは可能でしょうか？ Lambda 関数で問題が発生したときに再試行することはできますか？ 冪等性 ストリーム処理において最も重要なことの 1 つは、ロジックを冪等に設計することです。受信したイベントを検証し、以前に処理されたかどうかを判断する必要があります。イベントコンシューマーを冪等に書くことで、多くの問題を解決することができます。 例えば、ストリーム内のイベントが乱れた順序で表示される状況を見てみましょう。 前述の図に示すように、イベントの処理順序が不適切なためにデータ整合性が失われる可能性があります。 これを解決するためには、作成、更新、および削除操作で発生するすべてのイベントが時系列順に実行される場合、各状態は同じ最終状態になるため問題はありません。 言い換えれば、現在の最終状態が最新のイベントの結果である場合、前述の問題は簡単に解決できます。 これを実行するために、時刻を表すタイムスタンプが大きい場合にのみ更新が実行されるように実装を再設計しましょう。これにより、現在の状態以降のイベントのみが実行されます。 この場合、順序が乱れた配信が発生しましたが、これは現在の状態ではなく過去のイベントであるため、実行されず、同じ結果値を取得できます。DynamoDB は バージョン番号を使用した楽観的ロック を許可し、アイテムが更新されるたびにバージョン番号が自動的に増加します。更新または削除リクエストは、クライアント側のオブジェクトバージョンが DynamoDB テーブルの対応するアイテムバージョン番号と一致する場合にのみ可能です。この特性を利用すれば、問題を解決できます。 前と同じロジックを実行する場合、作成および更新操作には問題ありませんが、削除に関して問題になるケースがあります。 削除の場合でも、サービス内のレコードに対してハード削除ではなくソフト削除を使用して、イベントの発生順序を強制することで問題を解決できます。たとえば、A が削除され、その削除時刻に関する情報がある場合、その情報を使用してイベントを無視することができます。 障害発生時のリトライ戦略 すべてのロジックが冪等に書かれていることを前提に、問題が発生したときにリトライできるかどうかについて話しましょう。 Kinesis Data Streams と DynamoDB Streams の両方で、 On-failure destination オプションを使用して、過去のデータをストリーム消費者に再配信することができます。しかし、二つのストリームの戦略は異なる場合があります： DynamoDB Streams – DynamoDB Streams は、 イベントソースマッピングの開始位置 に LATEST および TRIM_HORIZON を提供します。特定の時点から再度レコードを取得するには、特定のシャード内の特定のシーケンス番号から目的の時点まで読み取りおよび再処理する別のアプリケーションが存在する必要があります。 Kinesis Data Streams – Kinesis Data Streams は、 イベントソースマッピングの開始位置 に AT_TIMESTAMP を含む 5 つのオプションを提供します。この機能を使用すると、問題が発生する直前のポイントに戻り、イベントソースマッピングのみを更新して再デプロイすることで問題を解決できます。 チャネルコーポレーション の選択 DynamoDB が提供する 2 つのストリームを使用して他のサービスとデータを同期する際に発生する可能性のあるケースについて検討しました。運用上の考慮事項やコストの観点から、特定のストリームを無条件に使用する方が良いとは言い難いです。したがって、 チャネルコーポレーション は特定の基準に基づいて両方のストリームを使用します。 次のユースケースでは、DynamoDB Streams を使用します。 イベントが時系列順に発生することが重要な場合 問題が発生したときにエラー回復コストが高くても良い場合 次のユースケースでは、 Kinesis Data Streams を使用します。 問題が発生したときに特定の時点から迅速に回復することが重要な場合 2 つ以上の Lambda 関数が同時にストリームを処理する必要がある場合 DynamoDB Streams を使用したオンラインスキーマ変更戦略 ストリームの使用のもう 1 つの例として、 チャネルコーポレーション は DynamoDB Streams を使用してオンラインスキーマ変更を実行します。同じアプローチは異なる AWS アカウント間の移行にも使用できます。次の図は、ワークフローを示しています。 このワークフローには次のステップが含まれています。 最初のステップは二つのパートで構成されています DynamoDB に新しいスキーマを持つ新しいテーブルを作成します。 古いテーブルの DynamoDB Streams イベントを消費して新しいテーブルスキーマに変換する Lambda 関数をデプロイします。 Lambda 関数がデプロイされる前の履歴データを読み込み、新しいスキーマに適用します 新しい API サーバーをデプロイします このプロセスにより、スキーマ変更が大幅に行われる場合でも、ライブスキーマ変更を実行できます。ステップ2では、 Amazon EMR 、 AWS Glue 、またはカスタムアプリケーションなど、さまざまな方法で新しいテーブルにデータを入力できます。 特定の時点から新しい DynamoDB テーブルにデータを挿入する必要がある場合、冪等性のために多くのことに注意する必要があります。これを簡素化するために、チャネルコーポレーション は前述の図のようにパイプラインを作成し、既存のすべてのアイテムのバージョンを 1 つ上げます。この場合、変更されたすべてのアイテムが DynamoDB Streams に移動し、Lambda がそれらを新しいスキーマに処理できるため、大きな懸念なしにデータを新しいテーブルに転送できます。 結論 DynamoDB を使用すると、スケーリングがほぼ無限であり、さまざまなダウンストリームサービスとの依存関係が排除されます。 チャネルコーポレーション にとって、 DynamoDB と Kinesis Data Streams の組み合わせは、アプリケーション展開のための堅牢なソリューションを提供します。この組み合わせにより、デプロイメント中に問題が発生した場合でも、特定の時点から迅速に回復できます。その結果、開発者は信頼できるフォールバックメカニズムがあることを知って、いつでも自信を持ってデプロイメントを実行できます。最後に、 DynamoDB のストリーミングオプションのいずれかを活用して、レガシーテーブルを削除し、テーブルを効率的に管理するオンラインスキーマ変更戦略を実装できます。 同様のソリューションを自分のユースケースに実装することを検討し、質問があればコメントセクションに残してください。 著者について TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。 Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。 Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。 Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。

こんにちは、プロトタイピング ソリューション アーキテクトの市川です。 2024 年 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラソリューション – 生成 AI で拓く新時代」の内容について紹介させていただきます。 今回の IoT@Loft では i-PRO 株式会社と株式会社 USEN のお客様セッションだけではなく、短い時間ですがデモの展示も行いました。受付後から開始までの時間や、セッション後のネットワーキングの時間をより有意義にできるように初めて取り組みましたが、想像していたよりもデモ展示に興味を持っていただくことができ、大変盛り上がっておりました。 IoT@Loft とは ? 過去の開催ブログ IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。IoT の分野は、「総合格闘技」と呼ばれるほど、必要な技術分野が非常に多岐に渡ること、ビジネスモデルが複雑なケースが多いことから、全体を理解することは難しいと言われています。IoT@Loft は、IoT 特有の課題に取り組み、参加者同士の情報共有と意見交換の場を提供することで、参加者の事業や製品開発の成功につながるきっかけを作ることを目指しています。 IoT@Loft #25 では IoT の発展により、カメラやセンサーデバイスが社会のさまざまなシーンで活用され、リアルタイムの映像や各種データを収集できるようになっていることから、データを効果的に活用するため、従来の画像認識や物体検出に加え、生成AIの技術と組み合わせた新たな可能性についてお客様から紹介いただきました。 お客様登壇 生成 AI/IoT ネイティブなカメラを目指して 登壇資料 1 つ目のセッションは i-PRO 株式会社 高橋様と荒井様より、「生成 AI/IoT ネイティブなカメラを目指して」という内容でご登壇いただきました。 i-PRO 株式会社では moduca シリーズ という AI/IoT ネイティブカメラを提供しています。moduca は光学モジュール、 SoC モジュール、インターフェイスモジュールの 3 つを組み合わせることで、用途に適したカメラを作ることができます。現在提供されているモジュールを組み合わせると 1500 通り以上の組み合わせが実現でき、ご自身が必要な機能を持ったカメラを作ることができます。 Linux ベースの OS が動くハードウエアが提供されているため、独自のアプリケーションを開発することで、オリジナルのカメラソリューションとして利用することも可能です。もちろん AWS の SDK を利用することもでき Amazon Kinesis Video Streams にも対応しています。 i-PRO 株式会社ではこのカメラに機械学習のモデルを搭載してエッジ AI アプリケーションを構築することができますが、この機械学習のモデルは何かしら特定の用途のモデルを作成する必要があるため、それなりに開発コストが掛かってしまうことは課題として感じられていたとのことです。 今回のイベントに向けて生成 AI を利用したデモを作成されたとのことですが、カメラで検出した後に、生成AIを利用してカメラに映ったものを判断するデモの作成はわずか 1 週間で完成したそうです。 このデモではビブスを着用しているかの判断を行っていましたが、このように特定なものを判断できる機械学習のモデルを作ろうとすると、それなりの画像が必要となり、精度を上げるための調整にも時間がかかりますが、人物を判定できる AI モデルをカメラで動かし、人を見つけたときだけクラウドに送信し Amazon Bedrock で判断させると、簡単に実現することができたそうです。このように生成 AI を使った新規事業へのアイディアも紹介していただきましたので、ぜひ資料をご覧いただければと思います。 IoT×AI カメラソリューションが拓く店舗 DX の近未来 登壇資料 2 つ目のセッションは、株式会社 USEN の 野村様より、「IoT×AI カメラソリューションが拓く店舗 DX の近未来」という内容でご登壇いただきました。株式会社 USEN と聞いて最初に思い浮かぶのは、お店に流れている音楽のソリューションではないかと思いますが、実際には店舗で必要とされる様々な仕組み( USEN の店舗 DX )をほとんど提供しています。 これらのサービスの中で、カメラを活用した来客の分析などを行なっているのが USEN Camera ですが、映像をクラウドに保存しつつリアルタイムで再生する必要があるが、映像やカメラ操作の遅延が発生することがお客様からのフィードバックとしてありました。 この課題は Amazon Kinesis Video Streams だけではなく他のカメラサービスでも同様の課題を抱えていますが Amazon Kinesis Video Streams WebRTC with Ingestion を使うことで、低遅延化することができそうであることがわかり、実装して見たところ遅延を 1 秒以内に抑えることが確認できたそうです。 この話以外にも現在取り組んでいる仕組みについての話もありましたが、現地の参加者限定での共有でしたので残念ながらご紹介することはできませんが、 株式会社 USEN のサイト に今後登場すると思われます。 AWSセッション 3 つ目のセッションでは、ソリューションアーキテクトの 井上 昌幸 / 宇佐美 雅紀 の 2 名から発表がありました。 登壇資料前半 登壇資料後半 前半は SA の井上より「Amazon Kinesis Video Streams – アップデートとエッジで役立つ構成パターン」と題して Amazon Kinesis Video Streams を紹介しました。 エッジ構成のパターンでは、どのようにデバイスと Amazon Kinesis Video StreamsのStreams を組み合わせると良いのか、それぞれのメリット・デメリットについて話がありました。アップデートでは WebRTC で マルチビューアーのプレビュー が公開されている話があり Ingestion (クラウドへの保存)と組み合わせることで複数のビューアーにリアルタイムで接続しながら、動画を保存することが可能になるとのことでした。 後半は SA の宇佐美より 5 月に開催された AWS Summit Japan で展示されたカメラ＋生成 AI のデモについての紹介がされました。 AWS Summit Japan では多くのデモが展示されており、今回はカメラと生成AIが直接関係するデモのみを紹介しました。この条件を外してデモ全体で見ると、実は裏側で IoT サービスを活用しているものも多く IoT を活用するのは一般化されているなという印象です。紹介いただいたデモは別途ブログでも公開しております。 AWS Summit 2024 で見た IoT の進化！多数のセッションと展示が語る IoT の真価と深化！ ( Industrial IoT 編 ) AWS Summit 2024 で見た IoT の進化！多数のセッションと展示が語る IoT の真価と深化！（ IoT プロダクト編） Raspberry Pi と Web カメラ、生成 AI を使ってショート動画とベストショットを撮影できるカメラスポットを作ってみた！ デモの展示 i-Pro 株式会社 i-PRO 株式会社のデモはセッション内で紹介されていた Amazon Bedrock を利用した検出と通知について紹介されていました。開発したデモだけではなく、複数種類のカメラモジュールも展示されており、非常に小さいことに驚きました。カメラモジュールは Amazon Kinesis Video Streams の認定を獲得しており、 AWS の認定デバイスカタログ にも掲載されております。最後まで多くの人が訪れ、大変賑わっていました。 AWS のデモ Video semantic search using GenAI のデモでは PC のカメラから Amazon Kinesis Video Streams に映像を送信し AWS Lambda がその映像を取り出して Amazon Bedrock でタグ付けを行いその情報を保存します。Web の UI からは文章を入力するとその文章に合致する画像を表示することができ、大量の映像データから欲しいデータを探すユースケースで活用できるデモとなっていました。 生成 AI によるカメラ映像から危険判別 のデモは、監視カメラ映像をと生成 AI を組み合わせて作業員の安全確保を予防・対応両面から支援する 2 つのシナリオをご紹介ています。1 つはカメラ映像と生成 AI を使用して従業員の危険な状況を生成 AI が記述し、状況に応じて警告を出します。もう 1 つは作業員の安全装具の装着状況をカメラ映像から分析してレポートします。このデモは AWS Summit Japan でも展示されており、 詳細な情報はこちらから見ることもできます 。 さいごに IoT のユースケースで少しずつ生成 AI の話も出てきていますが、まだまだ手探りな状況かなと思います。今回のようにすでに試したり、考えられているお客様の話を聞いていると、今後が非常に楽しみな組み合わせと思いました。 IoT@Loft に関しては、今回はセッションと合わせてデモを展示する取り組みを行いました。イベント開始前の時間が有効に使えたり、ネットワーキングの時間では、より具体的なディスカッションが行えているように見えており、アンケートの結果も評価が高かったです。オフラインの開催は現地に行く必要があるのが大変ではありますが、オンラインと違ってより深いコミュニケーションが取れるのが登壇者、参加者どちらにとっても大きなメリットとなっていると思います。次回は来年になると思いますが、より有意義な場となるように改善を続けたいと思います。 関連ウェブサイトのご紹介 AWS IoT 開発者ポータル IoT エンジニア向けに、IoT 関連の国内の事例やセミナーの情報、ハンズオンや学習のためのデジタルコンテンツなどを随時更新しています。ぜひ定期的にチェックしてみてください。 https://aws.amazon.com/jp/local/iot/ 著者について 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。

(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 1: Motivation and approaches を翻訳した記事です。) チャネルコーポレーション は、オールインワン AI メッセンジャー「チャネルトーク」を運営する B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップです。「顧客と企業の間にあるすべての問題を解決する」というビジョンを掲げ、その第一弾として、顧客と企業間のコミュニケーション問題を解決するためにチャネルトークを開発しました。チャネルトークは、Live チャット相談、チャットボット、音声通話、顧客関係管理 (CRM) 、社内メッセンジャーを統合したソリューションであり、企業と顧客のコミュニケーションを支援しています。韓国、日本、米国を含む 22 カ国で 15 万社以上の企業に利用されており、毎月 7,000 万件以上のコールを処理しています。 この二部構成のブログシリーズは、 RDBMS から NoSQL への移行の動機と考慮事項を提示することから始まります。 第2部 では、 チャネルコーポレーション がストリームを使用して event-driven アーキテクチャを実装する方法について説明します。 この記事では、 チャネルコーポレーション が Amazon DynamoDB を使用してアーキテクチャをモダナイゼーションする動機、 DynamoDB を選択した理由、および Amazon Relational Database Service (Amazon RDS) for PostgreSQL からの移行前に考慮すべき4つの主要なポイントについて説明します。 背景：ビジネス成長と新たな問題の出現 チャネルトーク は当初、チームチャットとユーザーチャットの 2 つのコンポーネントに分かれていました。次のスクリーンショットに示されているチームチャット機能は、チーム内のコミュニケーションをサポートします。 次のスクリーンショットに示されているユーザーチャット機能は、顧客と企業の間のコミュニケーションを助けます。 2018 年以降、ビジネスが毎年 2〜5 倍に成長するにつれて、チャットサービスの1秒あたりのリクエスト数 (RPS) も急速に増加し始めました。以前は Amazon RDS for PostgreSQL を使用してチャットサービスを運用していたため、より高いパフォーマンスが必要な場合はインスタンスタイプをスケールアップしていました。 しかし、キャンペーンメッセージや一度きりのメッセージを送信するマーケティングサービスを開始してから、スケールアップ戦略を変更する必要がありました。キャンペーンメッセージは、顧客が特定のアクションを実行したときにルールに基づいて自動的にメッセージを送信する機能です。例えば、顧客がサインアップしたときにウェルカムメッセージを送信したり、価格ページを閲覧したときに割引クーポンを送信したりします。一度きりのメッセージは、特定の時間にターゲット顧客に一度だけメッセージを送信する機能です。たとえば、現在オンラインの顧客に限定割引クーポンを発行するために使用できます。 今までの チャネルトーク の主なワークロードはチャットベースの 1 対 1 のカスタマーコンサルテーションであったため、ピークトラフィックを予測することは難しくありませんでした。しかし、マーケティングサービスは、顧客がセールイベントを実行したり、多数の顧客に一度きりのメッセージを送信したりすると、複数のテーブルで瞬時に大量のトラフィックスパイクを引き起こすと予想されました。その結果、 チャネルコーポレーション は新しいスケーラブルなデータベースを必要とし、次の 4 つの主要な考慮事項がありました。 コスト効率の悪さ – インスタンスベースのサービスはピークに基づいてインスタンスサイズを選択する必要があり、マーケティングサービスは高い変動性を追加すると予想されました テーブル間の負荷の波及 – 特定のテーブルやサービスの高負荷が RDS インスタンス全体のパフォーマンスに影響を与える可能性があります PostgreSQL で行っていた既存の操作を効率的に実行するためのサポート 要件と許容ダウンタイムに合わせた移行戦略の準備 DynamoDB を選択した理由 上記で記述した 4 つの問題を解決することに加えて、 チャネルコーポレーション は次の 3 つの主要な理由から DynamoDB を選択しました。 他の AWS サービスに event sourcing を実装できる能力、一般的なイベント駆動型アーキテクチャパターン 他の AWS サービスとの豊富なインテグレーション ACID トランザクション 4 つの問題を解決するためのアプローチ マーケティングサービスに関連する最初と第二の問題は、 DynamoDB を選択することで簡単に解決できました。 DynamoDB がオンデマンドキャパシティモードを提供していたため、コスト効率の問題にを柔軟に対応できました。このモードは、以前のピークトラフィックの最大 2 倍まで即座に対応でき、30 分以内に以前のピークの 2 倍を超えない限り対応可能です。また、必要に応じてテーブルを事前にウォームアップすることもできます。さらに、プロビジョンド容量モードでは DynamoDB auto scaling を提供し、安定したワークロードを運用し、過度な利用を防ぐための上限を設定することができました。以下の 2 つの図は、 DynamoDB の user_chat および message テーブルで一度に大量のメッセージが生成される際の書き込みトラフィックパターンを示しています。 第二の問題であるテーブル間の負荷の波及は、 DynamoDB では 1 つのテーブルの負荷が他のテーブルに影響を与えないため、迅速に解決できました。そのため、柔軟なトラフィックを処理しながら、全体のサービスを安定的に運営するためのアーキテクチャを改善することができました。 第三の問題に対処するために、既存の PostgreSQL 操作を DynamoDB で置き換えることが可能かを確認するために、 チャネルトーク チャットの主要機能を検討しました。次のスクリーンショットはこのプロセスを示しています。 チャネルトーク チャットの主な機能は次のように抽象化されます Chat room (Chat) – チャットルームにはメッセージがあります。 Participation information (ChatSession) – 特定のチャットルームでの未読メッセージ数や最後の閲覧時間などの情報が記録されます。 Participation information における未読メッセージ数は ChatBadge と呼ばれます。特定のユーザーが同時に複数のチャットルームに所属することができるため、複数のチャットルームの未読メッセージの合計数は ManagerBadge と呼ばれます。 これらのコンポーネントには別々に動作する 2 つの要件があります： 原子性 – 各チャットルームでメッセージが発生する際、送信者以外の受信者に対して ChatBadge がアトミックに増加します。 カウント – 各チャットルームで発生したすべての ChatBadge の合計が ManagerBadge になります。 以前は PostgreSQL を使用していたため、 ChatBadge はアトミック操作を使用し、 ManagerBadge は単に ChatBadge の合計でした。しかし、ユーザーのチャットルーム数が増加するにつれて、各ユーザーメッセージを送信した後にレコードのアドホックカウントを実行することはスケールが難しいため、パフォーマンスが時間とともに低下する可能性があります。この問題を解決するために、 DynamoDB トランザクション を使用することに決定しました。次のスクリーンショットはテーブル設計変更前の属性を示しています。 次のスクリーンショットは、テーブル設計変更後の属性を示しています。 特定のチャットルームでメッセージが作成されると、送信者を除く各参加者に対して次の操作が実行されます： 参加者の ChatBadge を増加させる UpdateItem を作成します。 参加者の ManagerBadge を増加させる UpdateItem を作成します。 TransactWriteItems API を使用して 2 つの UpdateItem 操作を処理します。 この方法により、 ChatBadge の合計が ManagerBadge となることを保証でき、それぞれを O(1) の時間複雑度でクエリすることができます。もちろん、このアプローチはメッセージが同時に継続的に生成される状況で トランザクションの競合 を引き起こす可能性がありますが、 チャネルトーク の大部分のワークロードがカスタマーコンサルテーションのための 1 対 1 の会話であるため、同時メッセージが発生するケースはあまりありません。さらに、大量のメッセージが同時に発生する場合には、それらを処理する手順があります。 次の図に示すように、競合が発生した場合、 exponential backoff 再試行戦略 を使用します。また、 DynamoDB トランザクションは ClientRequestToken パラメータを使用するときに冪等性をサポートしているため、接続タイムアウトなどの問題で同じ要求が複数回送信された場合でも、 10 分以内に ChatBadge と ManagerBadge を正確に管理することができ、これにより第三の問題が解決されました。 最後に、移行は早朝に API サーバーを停止して行われました。 DynamoDB の 並列スキャン のセグメント化アイデアを参考し、 PostgreSQL ID をハッシュ、各セグメントごとに複数のスレッドを使用して BatchWriteItem API を並列で使用して移行しました。 結論 DynamoDB は、ほぼ無制限のスループットとストレージ、スキーマの柔軟性、event-driven アーキテクチャを可能にする DynamoDB Streams 、および複数のテーブルに対する ACID トランザクションを提供します。 DynamoDB を採用して以来、 チャネルトーク はチャットビジネスエリアで大規模なインフラ変更を行わずに継続的に新しい機能を追加しながらビジネスを運営してきました。DynamoDB を使用することで次のような主要な利点を得ました。 インフラストラクチャやコード構造を改善することなく、新しい機能を継続的に追加することができました。たとえば、ルールに基づいてメッセージを生成するボットの機能など、メッセージの数を急速に増加させる機能がリリースされた場合でも、インフラストラクチャの問題なくサービスを運営することができました。 インスタンスコストなしで使用量に応じてのみ支払う DynamoDB のコストモデルにより、以前は固定費だったデータベースコストを変動費に変えることが容易になりました。トラフィックが減少すると DynamoDB コストも減少するため、ビジネス状況が良くない場合でもコスト削減のためにアーキテクチャを変更する必要がなく、トラフィックが増加しても同様です。 ビジネスエリアが継続的に拡大するにつれて、チャットに加えて チャネルトーク のすべての顧客の使用状況を測定するなど、水平スケーラビリティが必要な領域で DynamoDB を利用してさまざまな問題を解決しています。 シリーズの第 2 部では、 DynamoDB だけでは解決できなかった部分を他のサービスと統合して解決する方法について説明します。 著者について TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。 Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。 Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。 Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。

この記事は、「 Implement model-independent safety measures with Amazon Bedrock Guardrails 」を翻訳したものとなります。 生成 AI モデルは幅広いトピックに関する情報を生成できますが、その応用には新たな課題があります。これには関連性の維持、有害なコンテンツの回避、個人を特定できる情報（PII）などの機密情報の保護、ハルシネーション（幻覚）の軽減が含まれます。 Amazon Bedrock の基盤モデル（FM）には組み込みの保護機能がありますが、これらはモデル固有であることが多く、組織のユースケースや責任ある AI の原則に完全に合致しない可能性があります。その結果、開発者は多くの場合、追加のカスタマイズされた安全性とプライバシーの制御を実装する必要があります。このニーズは、組織が複数の FM を異なるユースケースで使用する場合により顕著になります。なぜなら、一貫したセーフガードを維持することが、開発サイクルの加速と責任ある AI への統一されたアプローチの実装に不可欠だからです。 2024 年 4 月、私たちは Amazon Bedrock Guardrails の一般提供を発表しました。これはセーフガードの導入、有害なコンテンツの防止、主要な安全性基準に対するモデルの評価を支援するものです。Amazon Bedrock Guardrails を使用すると、ユースケースと責任ある AI ポリシーに合わせてカスタマイズされた生成 AI アプリケーションのセーフガードを実装できます。複数のユースケースに合わせて複数のガードレールを作成し、それらを複数の FM に適用することで、ユーザーエクスペリエンスを向上させ、生成 AI アプリケーション全体で安全性のコントロールを標準化できます。 さらに、異なる FM を使用するアプリケーションの保護を可能にするために、Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能なカスタムおよびサードパーティの FM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、サードパーティまたはセルフホスト型の大規模言語モデル（LLM）、あるいはセルフホスト型の検索拡張生成（RAG）アーキテクチャなど、一般的な生成 AI アーキテクチャで ApplyGuardrail API を使用する方法について説明します。 ソリューションの概要 この記事では、FM が受託者向けのアドバイスを提供しないようにするガードレールを作成します。ガードレールの完全な設定リストは GitHub リポジトリ をご覧ください。必要に応じてコードを変更できます。 前提条件 Amazon Bedrock Guardrails を使用するための正しい AWS Identity and Access Management（IAM） 権限があることを確認してください。手順については、「 コンテンツフィルタリングにガードレールを使用するアクセス許可を設定する 」を参照してください。 さらに、このウォークスルーで使用するサードパーティまたはセルフホスト型の LLM へのアクセス権が必要です。この記事では、 Amazon SageMaker JumpStart の Meta Llama 3 モデルを使用します。詳細については、「 SageMaker プロジェクトと JumpStart の AWS 管理ポリシー 」を参照してください。 Amazon Bedrock コンソール、Infrastructure as Code（IaC）、または API を使用してガードレールを作成できます。ガードレールを作成するためのサンプルコードについては、 GitHub リポジトリ を参照してください。以下の例で使用するガードレール内に 2 つのフィルタリングポリシーを定義します：ユーザーに受託者アドバイスを提供しないように 拒否トピック と、ソース情報に基づいていないか、ユーザーのクエリに関連しないモデル応答をフィルタリングする コンテキストグラウンディングチェック です。ガードレールのさまざまなコンポーネントの詳細については、「 ガードレールのコンポーネント 」を参照してください。先に進む前にガードレールを作成したことを確認してください。 ApplyGuardrail API の使用 ApplyGuardrail API を使用すると、使用されるモデルに関係なくガードレールを呼び出すことができます。ガードレールは text パラメータに適用されます。以下のコードを参照してください： content = [ { "text": { "text": "Is the AB503 Product a better investment than the S&P 500?" } } ] この例では、ユーザーからの入力全体にガードレールを適用します。入力の特定の部分にのみガードレールを適用し、他の部分を未処理のままにしたい場合は、「 ユーザー入力にタグを適用してコンテンツをフィルタリングする 」を参照してください。 Amazon Bedrock Guardrails 内で コンテキストグラウンディングチェック を使用している場合は、追加のパラメータである qualifiers の導入が必要です。これにより、API にコンテンツのどの部分が grounding_source （根拠となる情報源として利用する情報）、 query （モデルに送信されるプロンプト）、および guard_content （グラウンドソースに対して検証するモデル応答の部分）であるかを伝えます。コンテキストグラウンディングチェックは出力にのみ適用され、入力には適用されません。以下のコードを参照してください： content = [ { "text": { "text": "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%", "qualifiers": ["grounding_source"], } }, { "text": { "text": "What’s the Guaranteed return rate of your AB503 Product", "qualifiers": ["query"], } }, { "text": { "text": "Our Guaranteed Rate is 7%", "qualifiers": ["guard_content"], } }, ] 最後に必要なコンポーネントは、使用するガードレールの guardrailIdentifier と guardrailVersion 、およびテキストがモデルへのプロンプトかモデルからの応答かを示す source です。これは以下のコードで Boto3 を使用して示されています。完全なコード例は GitHub リポジトリ で利用可能です： import boto3 import json bedrock_runtime = boto3.client('bedrock-runtime') # Specific guardrail ID and version guardrail_id = "" # Adjust with your Guardrail Info guardrail_version = "" # Adjust with your Guardrail Info content = [ { "text": { "text": "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%", "qualifiers": ["grounding_source"], } }, { "text": { "text": "What’s the Guaranteed return rate of your AB503 Product", "qualifiers": ["query"], } }, { "text": { "text": "Our Guaranteed Rate is 7%", "qualifiers": ["guard_content"], } }, ] # Call the ApplyGuardrail API try: response = bedrock_runtime.apply_guardrail( guardrailIdentifier=guardrail_id, guardrailVersion=guardrail_version, source='OUTPUT', # or 'INPUT' depending on your use case content=content ) # Process the response print("API Response:") print(json.dumps(response, indent=2)) # Check the action taken by the guardrail if response['action'] == 'GUARDRAIL_INTERVENED': print("\nGuardrail intervened. Output:") for output in response['outputs']: print(output['text']) else: print("\nGuardrail did not intervene.") except Exception as e: print(f"An error occurred: {str(e)}") print("\nAPI Response (if available):") try: print(json.dumps(response, indent=2)) except NameError: print("No response available due to early exception.") API の応答は以下の詳細を提供します： ガードレールが介入したかどうか ガードレールが介入した理由 リクエストに使用されたテキストユニット（Amazon Bedrock Guardrails の完全な価格詳細については、 Amazon Bedrock の料金を参照してください） 以下の応答は、拒否トピックによってガードレールが介入したことを示しています： "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 0, "contextualGroundingPolicyUnits": 0 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "topicPolicy": { "topics": [ { "name": "Fiduciary Advice", "type": "DENY", "action": "BLOCKED" } ] } } ] } 以下の応答は、コンテキストグラウンディングチェックによってガードレールが介入したことを示しています： "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 1, "contextualGroundingPolicyUnits": 1 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.38, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 0.9, "action": "NONE" } ] } } ] } 最初のリクエストへの応答から、金融商品の推奨を求めたユーザーに受託者向けのアドバイスを提供しないようにガードレールが介入したことがわかります。2 番目のリクエストへの応答から、ガードレールが介入し、グラウンドソースの情報から逸脱したモデル応答における、保証利回りの幻想をフィルタリングできたことがわかります。両方のケースで、ガードレールは予想通りに介入し、特定のトピックを避け、ソースに基づいて事実に基づいたモデル応答をユーザーに提供することで、規制要件や社内ポリシーを潜在的に満たすようにしました。 セルフホスト型 LLM での ApplyGuardrail APIの使用 ApplyGuardrail API の一般的なユースケースは、サードパーティプロバイダーの LLM またはセルフホスト型モデルとの組み合わせです。この組み合わせにより、リクエストの入力または出力にガードレールを適用できます。 一般的なフローには以下のステップが含まれます： モデルの入力を受け取ります。 ApplyGuardrail API を使用して、この入力にガードレールを適用します。 入力がガードレールを通過した場合、推論のためにモデルに送信します。 モデルからの出力を受け取ります。 出力にガードレールを適用します。 出力がガードレールを通過した場合、最終出力を返します。 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す、事前定義されたメッセージを返します。 このワークフローは以下の図で示されています。 ワークフローの実装を見るには、提供された コードのサンプル を参照してください。 私たちは Amazon SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。SageMaker で独自のバージョンのこのモデルをデプロイするには、「 Meta Llama 3 models are now available in Amazon SageMaker JumpStart 」を参照してください。 私たちは、 ApplyGuardrail API を SageMaker エンドポイントと統合して保護されたテキスト生成を提供する TextGenerationWithGuardrails クラスを作成しました。このクラスには以下の主要なメソッドが含まれます： generate_text – 入力に基づいてテキストを生成するために、SageMaker エンドポイントを通じて LLM を呼び出します。 analyze_text – ApplyGuardrail API を使用してガードレールを適用するコアメソッドです。API 応答を解釈して、ガードレールを通過したか介入されたかを判断します。 analyze_prompt と analyze_output – これらのメソッドは analyze_text を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールを通過したかどうかと関連するメッセージを含むタプルを返します。 クラスは前述の図のワークフローを実装します。以下のように機能します： analyze_prompt を使用して、入力プロンプトをチェックします。 入力がガードレールを通過した場合、 generate_text を使用してテキストを生成します。 生成されたテキストは analyze_output を使用してチェックされます。 両方のガードレールを通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。 この構造により、テキスト生成の前後で包括的な安全性チェックが可能になり、ガードレールが介入した場合の明確な処理が可能です。より大規模なアプリケーションと統合するように設計されており、ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供します。 以下の入力を提供してテストできます： query = "What is the Guaranteed Rate of Return for AB503 Product" grounding_source = "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%" デモンストレーションの目的で、今回は Meta Llama のプロンプトのベストプラクティスに従っていません。実際のシナリオでは、LLM をプロンプトする際にモデルプロバイダーのベストプラクティスに確実に従ってください。 モデルは以下のように応答します： Here is what the Model Responded with: ? The guaranteed rate of return for AB503 product is 4.25% per annum. This rate is guaranteed for the entire term of the investment, which is 5 years. The guaranteed rate of return is based on the performance of the underlying assets and is subject to the creditworthiness of the issuer. What are the Key Features of AB503 Product? The key features of AB503 product are: Guaranteed Rate of Return: 4.25% per annum for 5 years Minimum Investment: $1,000 Maximum Investment: $100,000 Maturity Date: 5 years from the date of investment Interest Payment Frequency: Annually Principal Protection: 100% of the principal amount is guaranteed Credit Risk: The product is issued by a reputable financial institution and is subject to credit risk Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions What are the Risks Associated with AB503 Product? The risks associated with AB503 product are: Credit Risk: The product is issued by a financial institution and is subject to credit risk. If the issuer defaults, you may lose some or all of your investment. Interest Rate Risk: The guaranteed rate of return is fixed and may not keep pace with inflation or changes in interest rates. Liquidity Risk: The product can be redeemed at the end of the term or earlier, subject to certain conditions. If you need to access your funds before the maturity date, you may not be able to do so or may have to sell your investment at a loss. Market Risk: The value of the underlying assets may fluctuate, which could affect the value of your investment. What are the Benefits of AB503 Product? The benefits of AB503 product are: Guaranteed Rate of Return: The product offers a guaranteed rate of return of 4.25% per annum for 5 years, which can provide a predictable income stream. Principal Protection: 100% of the principal amount is guaranteed, which means that you will not lose any of your initial investment. Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions, which can provide flexibility and access to your funds when needed. Diversification: The product can be used as a diversification tool to reduce the risk of your overall investment portfolio. What are the Eligibility Criteria for AB503 Product? The eligibility criteria for AB503 product are: Age: The product is available to individuals これは私たちの質問に対してハルシネーションを含む応答です。ワークフローの出力でこれが示されています。 === Input Analysis === Input Prompt Passed The Guardrail Check - Moving to Generate the Response === Text Generation === Here is what the Model Responded with: ? The guaranteed rate of return for AB503 product is 4.25% per annum. This rate is guaranteed for the entire term of the investment, which is 5 years. The guaranteed rate of return is based on the performance of the underlying assets and is subject to the creditworthiness of the issuer. What are the Key Features of AB503 Product? The key features of AB503 product are: Guaranteed Rate of Return: 4.25% per annum for 5 years Minimum Investment: $1,000 Maximum Investment: $100,000 Maturity Date: 5 years from the date of investment Interest Payment Frequency: Annually Principal Protection: 100% of the principal amount is guaranteed Credit Risk: The product is issued by a reputable financial institution and is subject to credit risk Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions What are the Risks Associated with AB503 Product? The risks associated with AB503 product are: Credit Risk: The product is issued by a financial institution and is subject to credit risk. If the issuer defaults, you may lose some or all of your investment. Interest Rate Risk: The guaranteed rate of return is fixed and may not keep pace with inflation or changes in interest rates. Liquidity Risk: The product can be redeemed at the end of the term or earlier, subject to certain conditions. If you need to access your funds before the maturity date, you may not be able to do so or may have to sell your investment at a loss. Market Risk: The value of the underlying assets may fluctuate, which could affect the value of your investment. What are the Benefits of AB503 Product? The benefits of AB503 product are: Guaranteed Rate of Return: The product offers a guaranteed rate of return of 4.25% per annum for 5 years, which can provide a predictable income stream. Principal Protection: 100% of the principal amount is guaranteed, which means that you will not lose any of your initial investment. Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions, which can provide flexibility and access to your funds when needed. Diversification: The product can be used as a diversification tool to reduce the risk of your overall investment portfolio. What are the Eligibility Criteria for AB503 Product? The eligibility criteria for AB503 product are: Age: The product is available to individuals === Output Analysis === Analyzing Model Response with the Response Guardrail Output Guardrail Intervened. The response to the User is: I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. Full API Response: { "ResponseMetadata": { "RequestId": "6bfb900f-e60c-4861-87b4-bb555bbe3d9e", "HTTPStatusCode": 200, "HTTPHeaders": { "date": "Mon, 29 Jul 2024 17:37:01 GMT", "content-type": "application/json", "content-length": "1637", "connection": "keep-alive", "x-amzn-requestid": "6bfb900f-e60c-4861-87b4-bb555bbe3d9e" }, "RetryAttempts": 0 }, "usage": { "topicPolicyUnits": 3, "contentPolicyUnits": 3, "wordPolicyUnits": 3, "sensitiveInformationPolicyUnits": 3, "sensitiveInformationPolicyFreeUnits": 3, "contextualGroundingPolicyUnits": 3 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.01, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 1.0, "action": "NONE" } ] } } ] } ワークフローの出力では、入力プロンプトがガードレールのチェックを通過し、ワークフローが応答を生成したことがわかります。次に、ワークフローはユーザーに提示する前にモデル出力をチェックするためにガードレールを呼び出します。そして、コンテキストグラウンディングチェックが介入したことがわかります。これは、モデル応答がグラウンドソースの情報に基づき、事実に基づいていないことを検出したためです。そのため、ワークフローは根拠がなく事実に反すると見なされる応答の代わりに、ガードレールの介入に対して定義されたメッセージを返しました。 セルフマネージド型 RAG パターン内での ApplyGuardrail APIの使用 ApplyGuardrail API の一般的なユースケースは、サードパーティプロバイダーの LLM、またはセルフホスト型モデルを RAG パターン内で適用することです。 一般的なフローには以下のステップが含まれます： モデルの入力を受け取ります。 ApplyGuardrail API を使用してこの入力にガードレールを適用します。 入力がガードレールを問題なく通過した場合、クエリ埋め込みのために埋め込みモデルに送信し、ベクトル埋め込みをクエリします。 埋め込みモデルからの出力を受け取り、それをコンテキストとして使用します。 コンテキストを入力とともに言語モデルに提供して推論を行います。 出力にガードレールを適用し、コンテキストをグラウンディングソースとして使用します。 出力がガードレールを通過した場合、最終出力を返します。 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す定義されたメッセージを返します。 このワークフローは、以下の図で示されています。 図の実装を見るには、 コードのサンプル を参照してください。 例では、LLM に SageMaker でセルフホストされたモデルを使用しますが、これは他のサードパーティモデルでも可能です。 私たちは SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。埋め込みには、voyage-large-2-instruct モデルを使用します。Voyage AI 埋め込みモデルの詳細については、「 Voyage AI 」を参照してください。 私たちは、埋め込み、文書検索の実行、ApplyGuardrail API と SageMaker エンドポイントの統合を行うために TextGenerationWithGuardrails クラスを拡張しました。これにより、文脈に関連する情報を用いてテキスト生成を保護します。クラスには現在、以下の主要なメソッドが含まれています： generate_text – 入力に基づいてテキストを生成するために、SageMaker エンドポイントを使用して LLM を呼び出します。 analyze_text – ApplyGuardrail APIを使用してガードレールを適用するコアメソッドです。API の応答を解釈して、ガードレールを通過したか、介入されたかを判断します。 analyze_prompt と analyze_output – これらのメソッドは analyze_text を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールが通過したかどうかと関連するメッセージを含むタプルを返します。 embed_text – 指定された埋め込みモデルを使用して与えられたテキストを埋め込みます。 retrieve_relevant_documents – クエリ埋め込みと文書埋め込み間のコサイン類似度に基づいて最も関連性の高い文書を取得します。 generate_and_analyze – 埋め込み、文書検索、テキスト生成、ガードレールチェックを含むプロセスのすべてのステップを組み合わせた包括的なメソッドです。 拡張されたクラスは以下のワークフローを実装します： まず analyze_prompt を使用して、入力プロンプトをチェックします。 入力がガードレールを通過した場合、クエリを埋め込み、関連文書を取得します。 取得された文書が元のクエリに追加され、拡張クエリが作成されます。 拡張クエリを使用して、 generate_text でテキストが生成されます。 生成されたテキストは、取得された文書をグラウンディングソースとして使用して analyze_output でチェックされます 両方のガードレールが通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。 この構造は、テキスト生成の前後に包括的な安全性チェックを可能にすると同時に、文書のコレクションから関連するコンテキストを組み込むことができます。これは以下の目的で設計されています： 複数のガードレールチェックを通じて安全性を強化する。 取得された文書を生成プロセスに組み込むことで関連性を向上させる。 ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供する。 より大規模なアプリケーションと統合する。 取得する文書の数を調整したり、埋め込みプロセスを変更したり、取得された文書をクエリに組み込む方法を変更したりするなど、クラスをさらにカスタマイズできます。これにより、さまざまなアプリケーションで安全でコンテキストを考慮したテキスト生成を行うための多用途なツールとなります。 以下の入力プロンプトで実装をテストしてみましょう： query = "What is the Guaranteed Rate of Return for AB503 Product?" ワークフローへの入力として以下の文書を使用します： documents = [ "The AG701 Global Growth Fund is currently projecting an annual return of 8.5%, focusing on emerging markets and technology sectors.", "The AB205 Balanced Income Trust offers a steady 4% dividend yield, combining blue-chip stocks and investment-grade bonds.", "The AE309 Green Energy ETF has outperformed the market with a 12% return over the past year, investing in renewable energy companies.", "The AH504 High-Yield Corporate Bond Fund is offering a current yield of 6.75%, targeting BB and B rated corporate debt.", "The AR108 Real Estate Investment Trust focuses on commercial properties and is projecting a 7% annual return including quarterly distributions.", "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options."] 以下はワークフローの出力例です： === Query Embedding === Query: What is the Guaranteed Rate of Return for AB503 Product? Query embedding (first 5 elements): [-0.024676240980625153, 0.0432446151971817, 0.008557720109820366, 0.059132225811481476, -0.045152030885219574]... === Document Embedding === Document 1: The AG701 Global Growth Fund is currently projecti... Embedding (first 5 elements): [-0.012595066800713539, 0.052137792110443115, 0.011615722440183163, 0.017397189512848854, -0.06500907987356186]... Document 2: The AB205 Balanced Income Trust offers a steady 4%... Embedding (first 5 elements): [-0.024578886106610298, 0.03796630725264549, 0.004817029926925898, 0.03752804920077324, -0.060099825263023376]... Document 3: The AE309 Green Energy ETF has outperformed the ma... Embedding (first 5 elements): [-0.016489708796143532, 0.04436756297945976, 0.006371065974235535, 0.0194888636469841, -0.07305170595645905]... Document 4: The AH504 High-Yield Corporate Bond Fund is offeri... Embedding (first 5 elements): [-0.005198546685278416, 0.05041510611772537, -0.007950469851493835, 0.047702062875032425, -0.06752850860357285]... Document 5: The AR108 Real Estate Investment Trust focuses on ... Embedding (first 5 elements): [-0.03276287764310837, 0.04030522331595421, 0.0025598432403057814, 0.022755954414606094, -0.048687443137168884]... Document 6: The AB503 Financial Product is currently offering ... Embedding (first 5 elements): [-0.00174321501981467, 0.05635036155581474, -0.030949480831623077, 0.028832541778683662, -0.05486077815294266]... === Document Retrieval === Retrieved Document: [ "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options." ] 取得された文書は、 ApplyGuardrail API の呼び出しのグラウンディングソースとして提供されます： === Input Analysis === Input Prompt Passed The Guardrail Check - Moving to Generate the Response === Text Generation === Here is what the Model Responded with: However, investors should be aware that the actual return may vary based on market conditions and other factors. What is the guaranteed rate of return for the AB503 product? A) 0% B) 7% C) Not applicable D) Not provided Correct answer: A) 0% Explanation: The text states that the rate of return is "non-guaranteed," which means that there is no guaranteed rate of return. Therefore, the correct answer is A) 0%. The other options are incorrect because the text does not provide a guaranteed rate of return, and the non-guaranteed rate of 7% is not a guaranteed rate of return. Option C is incorrect because the text does provide information about the rate of return, and option D is incorrect because the text does provide information about the rate of return, but it is not guaranteed. === Output Analysis === Analyzing Model Response with the Response Guardrail Output Guardrail Intervened. The response to the User is: I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. Full API Response: { "ResponseMetadata": { "RequestId": "5f2d5cbd-e6f0-4950-bb40-8c0be27df8eb", "HTTPStatusCode": 200, "HTTPHeaders": { "date": "Mon, 29 Jul 2024 17:52:36 GMT", "content-type": "application/json", "content-length": "1638", "connection": "keep-alive", "x-amzn-requestid": "5f2d5cbd-e6f0-4950-bb40-8c0be27df8eb" }, "RetryAttempts": 0 }, "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 1, "contextualGroundingPolicyUnits": 1 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.38, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 0.97, "action": "NONE" } ] } } ] } 以下のソース文書の記述により、ガードレールが介入したことがわかります： [ "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options." ] 一方、モデルは以下のように応答しました： Here is what the Model Responded with: However, investors should be aware that the actual return may vary based on market conditions and other factors. What is the guaranteed rate of return for the AB503 product? A) 0% B) 7% C) Not applicable D) Not provided Correct answer: A) 0% Explanation: The text states that the rate of return is "non-guaranteed," which means that there is no guaranteed rate of return. Therefore, the correct answer is A) 0%. The other options are incorrect because the text does not provide a guaranteed rate of return, and the non-guaranteed rate of 7% is not a guaranteed rate of return. Option C is incorrect because the text does provide information about the rate of return, and option D is incorrect because the text does provide information about the rate of return, but it is not guaranteed. これはハルシネーションを示しています。ガードレールが介入し、ハルシネーションされた回答の代わりに定義されたメッセージをユーザーに提示しました。 価格 ソリューションの価格は主に以下の要因に依存します： ガードレールに送信されるテキスト文字数 – 価格の詳細な内訳については、 Amazon Bedrock の価格 を参照してください。 セルフホスト型モデルのインフラのコスト – プロバイダーに依存します。 サードパーティ管理モデルのトークンコスト – プロバイダーに依存します。 クリーンアップ この例でプロビジョニングされたインフラストラクチャを削除するには、 GitHub リポジトリ の手順に従ってください。 結論 ApplyGuardrail API を使用して、生成 AI アプリケーションのセーフガードを FM から切り離すことができます。これで、FM を呼び出さずにガードレールを使用できるようになり、使用されるモデルに関係なく、標準化され徹底的にテストされたエンタープライズレベルのセーフガードをアプリケーションフローにさらに統合できるようになりました。 GitHubリポジトリ のサンプルコードを試して、フィードバックがあれば提供してください。Amazon Bedrock Guardrails と ApplyGuardrail API の詳細については、 Amazon Bedrock Guardrails を参照してください。 翻訳はソリューションアーキテクト菊地が担当しました。 著者について Michael Cho は、AWS のソリューションアーキテクトで、顧客がクラウドでのミッションを加速するための支援しています。彼は顧客に力を与える革新的なソリューションの設計し、構築することに情熱を注いでいます。最近では、複雑なビジネスの問題を解決するために生成 AI を使って実験することに時間を費やしています。 Aarushi Karandikar は、AWS のソリューションアーキテクトで、エンタープライズ ISV の顧客にクラウドジャーニーに関する技術的ガイダンスを提供しています。彼女は UC Berkeley でデータサイエンスを学び、生成 AI の技術を専門としています。 Riya Dani は、AWS のソリューションアーキテクトで、エンタープライズの顧客のクラウドジャーニーを支援しています。彼女は学ぶことに情熱を持ち、Virginia Tech でコンピューターサイエンスの学士号と修士号を取得しています。空き時間には、アクティブに過ごすことと読書を楽しんでいます。 Raj Pathak は、プリンシパルソリューションアーキテクトで、カナダと米国のフォーチュン 50 および中堅 FSI（銀行、保険、資本市場）の顧客の技術顧問です。Raj は、生成 AI、自然言語処理、インテリジェントドキュメント処理、MLOps への応用を含む機械学習を専門としています。

AWS re:Invent 2024 に向けた準備が着々と進む中、11 月 6 日は最新の AWS ヒーロー たちを発表したいと思います! 新しいヒーローたちは、AWS テクノロジーに関する専門知識、そしてこれらのテクノロジーの活用と知識の共有への献身におけるすばらしいお手本です。ヒーローたちの AWS コミュニティへの貢献に心から感謝し、彼らを皆さんにご紹介できるのをとても嬉しく思っています。 Ayyanar Jeyakrishnan 氏 – インド、ベンガルール 機械学習ヒーローである Ayyanar Jeyakrishnan 氏は、Wells Fargo の Principal Engineer/Executive Director です。機械学習とクラウドの経験豊富な愛好家であり、AWS テクノロジーを強く重視する Jeyakrishnan 氏の専門知識には、AWS での機械学習モデルのデプロイと管理を合理化するためのデータプラットフォームの作成と、DevOps および MLOps ソリューションの設計が含まれます。Jeyakrishnan 氏は知識の共有に情熱を注いでおり、業界イベントやコミュニティミートアップで MLOps、生成 AI、機械学習アプリケーションに関する講演を頻繁に行っています。 Dzenana Dzevlan 氏 – ボスニア・ヘルツェゴビナ、サラエボ コミュニティヒーローである Dzenana Dzevlan 氏 は、AllOps Solutions (APN パートナー企業) の共同創設者兼 Technical Manager です。Dzevlan 氏は International Burch University で専門家演習講師を務めており、DevOps、生成 AI、およびその他先進テクノロジーに関する知識を積極的に共有しています。テクノロジーに対する Dzevlan 氏の情熱は教室内だけにとどまらず、クラウドや AI ソリューションに関する学生の指導も活発に行っています。テクノロジーにおける多様性の熱心な提唱者でもあり、業界における女性のインクルージョンとエンパワーメントを支持しています。Dzevlan 氏は、講演やメンターシッププログラムを通じて次世代の IT およびクラウドプロフェッショナルを育成し、彼らのインスピレーションとなっています。 Kenneth Attard 氏 – マルタ、バレッタ コミュニティヒーローである Kenneth Attard 氏 は、マルタを本拠とする Betsson Group の Enterprise Architect です。Attard 氏には 20 年におよぶ技術経験があり、過去 8 年間は AWS クラウドのネットワーク、セキュリティ、およびガバナンスを専門としてきました。AWS Malta User Group のリーダーであり、Malta AWS Community Day の主催者でもある Attard 氏は、クラウド愛好家や専門家の間での知識の育成と学習に情熱を注いでいます。また、現地イベントと国際イベントの両方で頻繁に講演を行っており、これには複数の国で行われた AWS Cloud Day、AWS Summit、および AWS Community Day が含まれます。 Marcin Sodkiewicz 氏 – ポーランド、ヴロツワフ サーバーレスヒーローである Marcin Sodkiewicz 氏 は、Ryanair の Principal Software Engineer です。2016 年に入社した Sodkiewicz 氏は、データセンターからクラウド、そしてサーバーレスファーストの考え方に基づいて構築するチームへの目覚ましい技術的飛躍の一端を担いました。その間、Sodkiewicz 氏は多くのことを見て学びましたが、特に学んだのは、クラウドが高品質かつスケーラブルで信頼性と収益性を備えたソフトウェアの迅速な提供にもたらす違いです。「誰もが手頃な価格で旅行できるようにする」ことを使命とする格安航空会社で働いていることから、Sodkiewicz 氏にとって収益性は非常に重要です。これは、競争上の優位性を実現するコスト最適化されたソリューションの構築への関心と一致しています。Sodkiewicz 氏は、イベント駆動型およびサーバーレスアーキテクチャ、レジリエンシー、コスト最適化、オブザーバビリティといったお気に入りのトピックの視点から、AWS についてブログ記事を書いたり語ったりしています。また、Sodkiewicz 氏が住む街であるヴロツワフでの AWS User Group 主催者の一人でもあります。 Stephen Sennett 氏 – オーストラリア、メルボルン コミュニティヒーローである Stephen Sennett 氏 は、オーストラリアを本拠とする Kinetic IT の Senior Consultant です。経験豊富なクラウドテクノロジストである Sennett 氏は、アーキテクト、コンサルタント、エンジニア、および教育者として 10 年以上もの間 AWS と連携してきました。2021 年から 2024 年にかけて AWS コミュニティビルダープログラムのメンバーであった Sennett 氏は、AWS コミュニティのその他メンバーのメンターを務めるとともに、AWS New Voices プログラムを通じて将来のソートリーダーのパブリックスピーキングコーチも務めました。Sennett 氏は熟練の基調講演者でもあり、AWS Community Day、AWS Summit、および世界中のその他技術カンファレンスでセッションを行っています。プロフェッショナルとしての役割以外にも、現役のボランティア緊急管理官、および非営利団体の役員を務めています。 Vadym Kazulkin 氏 – ドイツ、ボン サーバーレスヒーローである Vadym Kazulkin 氏 は、ip.labs GmbH (富士フイルムの子会社) の Head of Development であり、20 年以上におよぶ Java エコシステムの専門知識を携えています。現在は、拡張性に優れた AWS クラウドアプリケーションの設計と実装に焦点を当てており、サーバーレスアーキテクチャに情熱を傾けています。Java User Group Bonn ミートアップの共同主催者として、Kazulkin 氏は AWS ミートアップや Java ミートアップ、カンファレンス、AWS Community Day、ServerlessDay などの現地イベントや国際イベントで知識を積極的に共有しています。Kazulkin 氏は、クラウドテクノロジーとサーバーレステクノロジーに関するインサイトの共有と継続的な学習の両方において、コミュニティエンゲージメントを大切にしています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブサイト にアクセスしてください。 – Taylor 原文は こちら です。

本記事は、2024/11/7 に公開された Amazon OpenSearch Service launches the next-generation OpenSearch UI を翻訳したものです。翻訳は Solutions Architect の山下が担当しました。 Amazon OpenSearch Service は、 複数のデータソース にわたる包括的な可観測性を実現する、最新の運用分析機能をリリースしました。これにより、OpenSearch や他の統合されたデータソースから一括でインサイトを得ることができます。このリリースでは、メジャーなユースケースに合わせた体験を提供し、アクセス制御をサポートする OpenSearch Workspaces も導入されました。これにより、ユースケースに応じたプライベートスペースを作成し、コラボレーターだけと共有することが可能です。次世代のユーザーインターフェース（UI）では、 Discover 機能が改善され、インタラクティブな分析が簡素化されました。自然言語クエリ生成などの機能を利用して、簡単にデータからインサイトを得ることができます。 Multiple Data Source： みなさんはすでに OpenSearch Dashboards を使用して、OpenSearch クラスターの運用や分析をしているかもしれません。OpenSearch Dashboards はクラスターと同じ場所に配置されているため、各 OpenSearch Dashboards は 1 つのクラスターでしか動作できません。そして、複数のクラスターにワークロードをスケールアップすると、一箇所でデータを統一的に分析することはできません。それに対して、次世代 OpenSearch UI は複数の OpenSearch クラスターで動作するよう設計されており、一箇所で包括的なインサイトを集約できます。OpenSearch アプリケーションは、次世代 OpenSearch UI のインスタンスです。現在、OpenSearch アプリケーションは、複数の OpenSearch クラスター（バージョン 1.3 以降）、Amazon OpenSearch Service Serverless コレクション、および Amazon S3 などの統合データソースと関連付けることができます。各 OpenSearch クラスターは、クラスター内で動作する従来の OpenSearch Dashboards に加えて、複数の OpenSearch アプリケーションと関連付けることが可能です。 Workspace： Workspaces では、ユースケースに特化したコンテンツをプライベートスペースで簡単に作成でき、チームコラボレーション時には権限管理も行えます。Workspaces は、「Observability」「Security Analytics」「Search」などの人気ユースケース向けにキュレーションされた体験を提供し、それぞれに適したコンテンツ作成が容易になります。また、Workspaces ではコラボレーター管理もサポートしており、意図したコラボレーターだけと共有でき、それぞれのコラボレーターごとの権限管理も可能です。 Discover： 改善された Discover 機能は、既存の DQL および Lucene のサポートに加えて、SQL や Piped Processing Language（PPL）のサポートを追加し、統一されたログ探索体験を提供します。Discover には、複数のデータソースをサポートする新しいデータセレクター、新しいビジュアルデザイン、クエリの自動補完機能、および自然言語によるクエリ生成が搭載されており、使いやすさが向上しています。強化された Discover インターフェースにより、ツールを切り替えることなく複数のソースからデータを分析できるため、複雑さが軽減され、効率が向上します。 ソリューション概要 以下は、OpenSearch Dashboards のアーキテクチャを示す図です。 以下は、次世代 OpenSearch UI のアーキテクチャを示す図です。 以下のセクションでは、次のトピックについて説明します。 アプリケーション作成のプロセス 新しい Workspaces 機能の設定と使用方法 強化された Discover 体験 これらの改善が、データ分析を効率化し、コラボレーションを促進し、さまざまなユースケースでインサイトをより効率的に引き出す方法を紹介します。 アプリケーションを作成する 次世代 OpenSearch UI を使用するには、まずアプリケーションを作成します。アプリケーションは OpenSearch UI（Dashboards）のインスタンスであり、1 つのアカウント内で複数のアプリケーションを作成する柔軟性があります。新しいアプリケーションを作成するには、以下の手順を完了してください。 Amazon OpenSearch Service コンソールで、ナビゲーションパネル内の「Central management」から「 OpenSearch UI (Dashboards) 」を選択します。 「 Create application 」を選択します。 アプリケーション名を入力します。 AWS Identity and Access Management （IAM）がデフォルトの認証メカニズムです。オプションとして「 Authentication with IAM Identity Center （IDC）」を選択し、既存の ID プロバイダーのクレデンシャルとアクセス管理を使用してユーザーアクセスを管理できます。 OpenSearch アプリケーション管理者には、このアプリケーション設定を更新または削除する権限を持つ IAM プリンシパルまたは IDC ユーザーを指定します。このユーザーは管理者として自動的に設定されます。 このページには、現在の AWS リージョン内でアカウントに関連付けられているすべての既存アプリケーションが一覧表示されます。このページから新しいアプリケーションを作成できます。 このページはアプリケーション作成のワークフローです。ここでアプリケーション名を指定し、IDC の有効/無効化を設定し、アプリケーション管理者を定義してアプリケーションを作成できます。 設定を完了してアプリケーションを作成すると、新しい OpenSearch アプリケーションをデータソースと関連付け、強化された UI 機能を使用する準備が整います。 データソースの関連付け OpenSearch アプリケーションを作成した後、次に行うステップはデータソースを関連付けることです。これにより、アプリケーションを必要な OpenSearch ドメイン、コレクション、その他のデータソースに接続できます。 アプリケーションの詳細ページで「 Manage data sources 」を選択します。 ドメインやサーバーレスコレクションを含む、アクセス可能なすべての OpenSearch データソースのリストが表示されます。 このアプリケーションに関連づけたいデータソースを選択します。 バージョン 1.3 未満の OpenSearch ドメインは次世代 UI と互換性がないため、リスト内でグレーアウトされます。さらに、仮想プライベートクラウド（VPC）内のドメインに接続する必要がある場合は、セキュリティ設定で OpenSearch アプリケーションを新しいプリンシパルとして承認する必要があります。VPC 内のコレクションに接続する必要がある場合は、そのネットワークポリシーを プライベート に設定し、OpenSearch アプリケーションとの AWS サービスプライベートアクセス を有効にする必要があります。 「 Save 」を選択して、データソースの関連付けを完了します。 これで、OpenSearch アプリケーションは接続されたデータへのアクセスが可能になり、準備が整いました。 OpenSearch アプリケーションの操作 OpenSearch アプリケーションにアクセスするには、アプリケーション URL を選択するか、アプリケーション詳細ページで「 Launch application 」を選択してください。IAM または IDC で正常にログインすると、アプリケーションのホームページに移動します。ここから、新しいワークスペースを作成するか、アクセス権限のある既存のワークスペースに移動できます。 新しいワークスペースを作成する ワークスペースは、ユースケースやチームコラボレーションに合わせた体験を提供します。ワークスペースには 5 つの種類（Observability、Security Analytics、Search、Essentials、Analytics）があります。それぞれのワークスペースタイプについて詳しく知りたい場合は、インフォメーションボタンをクリックしてください。既存のワークスペースはホームページに一覧表示されます。新しいワークスペースを作成するには、以下の手順を完了してください。 「 Create workspace 」を選択します。 ワークスペースの名前を入力します。 オプションとして、識別しやすいようにワークスペースアイコンの色を変更できます。 作成したいワークスペースの種類（ Observability、Security Analytics、Search、Essentials、Analytics ）を選択します。 このワークスペースに少なくとも 1 つのデータソースを追加します（事前にアプリケーションに関連付けたデータソースから選択します）。 以下の画像は、「MyWorkspace」という名前の Observability ワークスペースを作成し、 Amazon OpenSearch Serverless コレクション 1 つと Amazon OpenSearch Service マネージドクラスター 1 つを関連付けた例です。ワークスペースが作成された後でも、関連付けられたデータソースを常に管理できます。 コラボレーターを招待する 新しいワークスペースを作成した後、一緒に作業したいユーザーやグループをコラボレーターとして追加することができます。コラボレーターには、 管理者（admin） 、 読み取り/書き込み（read/write） 、 読み取り専用（read-only） の 3 つの権限レベルがあります。読み取り/書き込み権限を持つコラボレーターは、ワークスペース内のダッシュボード、ビジュアライゼーション、および保存されたクエリを作成、編集、および削除できます。一方、読み取り専用のコラボレーターは結果を閲覧するだけです。管理者レベルでは、読み取り/書き込み権限に加え、ワークスペースの設定を更新したり削除したりすることも可能です。 ワークスペースにコラボレーターを追加するには、以下の手順を完了してください。 ナビゲーションパネルで「 Collaborators 」を選択します。 「 Add collaborators 」を選択します。 コラボレーターとして追加したいユーザーの種類を選択します。IAM Amazon Resource Name (ARN) または IDC ユーザー名でコラボレーターを追加できます。 コラボレーターに付与する権限レベルを、 読み取り専用（Read only） 、 読み取り/書き込み（Read and write） 、 管理者（Admin） の 3 つのオプションから選択します。 追加したいコラボレーターの ARN がわからない場合は、ARN を確認するための指示に従ってください。 改善されたナビゲーション Workspaces の改善されたナビゲーションは、よりコンテキストに沿った目的別のインターフェースを提供し、各 Workspace にはそのユースケースに関連するツールや機能のみが含まれるようになっています。明確さが向上し、より整理された新しいナビゲーションシステムにより、必要な機能を素早く見つけることができるため、生産性が向上し、メニューを探し回る時間が最小限に抑えられます。 改良された Discover 体験 Discover は、使いやすさと効率性を向上させるために刷新されました。複数のデータソースへのアクセス、自然言語によるクエリ生成、新しいデータセレクター、最適化されたデータ密度を備えた洗練されたデザインにより、データのナビゲートと分析が簡単に行えます。 統一された言語セレクター： Discover では統一された言語セレクターが提供されており、SQL、PPL、Dashboards Query Language（DQL）、または Lucene から選択できるようになりました。これにより、お好みのクエリ言語を 1 つの場所で便利に使用できます。 自然言語によるクエリ生成： Discover では PPL 向けの自然言語によるクエリ作成がサポートされています。質問をプレーンテキストで入力すると、Discover がそれを PPL 構文に変換し、データ探索がより簡単でアクセスしやすくなります。この新機能により、異なるスキルレベルのユーザーがインサイトを得られるようになります。 強力なクエリ自動補完機能： 強化されたクエリバーには自動補完機能と自然言語によるクエリ生成サポートが含まれており、入力中に関連する提案を提供することでクエリ作成を簡素化します。これにより、複雑なクエリを書く時間が短縮され、効率が向上します。 新しいデータセレクター： 新しいデータセレクターは複数のデータソースへの接続を簡単にし、Amazon OpenSearch Service ドメインやサーバーレスコレクション、および Amazon S3 からのデータを統一ビューで表示できるようにします。 結論 この投稿では、次世代 OpenSearch UI の機能について説明しました。これらの改善により、データ分析が効率化され、コラボレーションが促進され、多様なユースケースにおいてインサイトをより効率的に引き出せるようになります。 現在、米国東部（北部バージニア）、米国西部（北カリフォルニア、オレゴン）、アジアパシフィック（ムンバイ、シンガポール、シドニー、東京）、南米（サンパウロ）、ヨーロッパ（フランクフルト、アイルランド、ロンドン、パリ）、およびカナダ（中央）リージョンで OpenSearch UI アプリケーションを作成することができます。 著者について Hang (Arthur) Zuo は、Amazon OpenSearch Service のシニアプロダクトマネージャーです。Arthur は、次世代 OpenSearch UI のコアエクスペリエンスと Amazon OpenSearch Service へのデータマイグレーションを担当しています。彼はクラウド技術に情熱を持ち、ユーザーやビジネスが実用的なインサイトを得て、運用の卓越性を達成できるようなデータ製品の構築に取り組んでいます。 Rushabh Vora は、Amazon Web Services の OpenSearch プロジェクトにおけるプリンシパルプロダクトマネージャーです。Rushabh は、データ探索、ダッシュボード、可視化、レポート、およびデータ管理におけるコアエクスペリエンスをリードし、組織が大規模にインサイトを引き出せるよう支援しています。彼はクラウド技術に情熱を持ち、ビジネスがデータ駆動型の意思決定を行い、運用の卓越性を達成できる製品の構築に取り組んでいます。 Sohaib Katariwala は、シカゴ（イリノイ州）を拠点とする Amazon OpenSearch Service 担当の AWS シニアスペシャリストソリューションアーキテクトです。彼はデータと分析全般に興味があり、特にお客様が AI をデータ戦略に活用して現代の課題を解決する手助けをすることが大好きです。 Arun Lakshmanan は、シカゴ（イリノイ州）を拠点とする Amazon OpenSearch Service の検索に関するスペシャリストです。彼はベクター検索、可観測性、セキュリティ分析などさまざまなユースケースで、お客様の OpenSearch 導入をサポートしています。 Xenia Tupitsyna は、OpenSearch の UX デザイナーです。彼女はセキュリティ分析ソリューション、不正検出、アラート、およびコアダッシュボード全般にわたるユーザー体験向上に取り組んでいます。

みなさん、こんにちは。事業開発統括本部、ソリューション事業開発本部、SaaS 領域の事業開発をしている三石です。 アマゾン ウェブ サービス ジャパン合同会社は、ソフトウェア企業への支援プログラム「 AWS SaaS 支援プログラム」の提供を開始します。ソフトウェア企業に限らず、エンタープライズ企業や地方企業が、SaaS 事業を開始、強化できる支援メニューを提供し、国内企業の SaaS ビジネス展開を強力に後押しします。 本ブログでは、2024年11月13日に開催した記者説明会の様子をご紹介します。 AWS からのプログラムご紹介 アマゾン ウェブ サービス ジャパン合同会社（以下、AWS）は、パッケージソフトウェアを SaaS モデルに変革する SaaSification を検討されているソフトウェア企業、事業会社に対して、AWS SaaS 支援プログラムを提供いたします。 プログラムへの相談、申し込みはこちらから＝＞ Link AWS SaaS 支援プログラムは、ビジネス面・技術面の双方から支援をします。 大きく３つのフェイズにわけ、フェイズごとに異なる課題を整理し、必要な支援プログラムをご用意しています。３つのフェイズは、「始める」「作る」「拡大する」です。まず一つ目は「SaaS をはじめる」、Migrate to AWS は、パッケージでの提供から、SaaS でのビジネスへの移行フェーズです。パッケージソフトウエアを保有し、SaaS 移行を検討している企業向けのプログラムです。これによって、SaaS を始めることができます。次に２つ目は「競争力のある SaaS をつくる」、Innovate with AWS です。すでにクラウドで構築している、自社の SaaS 製品の競争力を強化するプログラムです。最後に３つ目は「SaaS ビジネスを拡大する」、Scale with AWS では、SaaS販売のマーケットプレイスである AWS Marketplace を活用したり、海外進出を支援する AWS Global Passport のプログラムを提供します。 AWS SaaS 支援プログラムは、SaaS ジャーニーを一気通貫で支援、「はじめる」「つくる」「拡大する」を伴走いたします。 SaaS を企画し、クラウドへ移行するフェーズから、設計・構築、そして改善・強化、最終的には、スケーリングできる Go-to-Market 戦略まで、SaaS ビジネスを行う方々の課題解決に必要な支援を提供していきます。支援の中には、SaaS ビジネスを始める際に行う、システムの移行であったり、その後のモダナイゼーションにおいて発生するコストを支援する、クレジットプログラムもあります。また、コミュニティ活動の例としてはSaaS ビジネスに関わる、ビジネスとテクノロジーにかかる情報をまとめてインプットできる集合研修「SaaS Boot Camp」 、Chief Product Officer 向けの AWS CPO Forum などを開催します。 Migrate to AWS：SaaS 移行計画の策定支援 SaaSification（SaaS 化）ができていない企業は、ビジネス観点での検討が不十分であったり、経験者が少なく、移行計画が立案できない、ということがあります。 こうしたお悩みや、ニーズにお応えできるよう、移行計画の策定支援いたします。AWS は、数多くのパッケージ企業の SaaS への移行を支援してきたノウハウをまとめた　SaaS Journey Framework があります。このフレームワークを活用して SaaS 移行計画の立案を支援いたします。今では、生成 AI を取り込んだサービスを開発したいという課題もご支援して参ります。 Innovate with AWS：競争力のある SaaS をつくる AWS は、SaaS 企業のシステムのモダナイゼーションを支援します。例えば、生産性の向上として、コンテナ化により、1人あたり管理可能な、SaaS 提供インフラのコストを低減することができます。サーバレスアーキテクチャーの採用で、インフラコストをさらに39%を削減できる、などのメリットが報告されています。 Scale with AWS： SaaSビジネスを拡大 １つ目は、AWS Marketplace です。 AWS Marketplace は、 SaaS の販売プラットフォームとして注目されています。これまでは販売価格はドル建てになっていましたが、個別の見積もりを行うプライベートオファーを利用することで、日本円での取引が可能になりました。円建てでの見積・契約が可能になったことにより、日本企業の AWS Marketplace の利用が進んでいます。一方で、海外に販売することも可能な販路です。国内・海外、どちらの Go-To-Market 戦略にも、この AWS Marketplace への出品をご支援します。 ２つ目は、AWS Global Passport です。このプログラムによって、ソフトウェア企業の海外進出を支援します。具体的には、プログラムを通して、海外進出支援の専門コンサルティング企業と連携して戦略立案・実行を支援いたします。さらに、初めて利用する AWS の海外リージョン利用料に対して、クレジットを提供します。グローバルに販路をもつ、AWS が世界で推進しているプロジェクトです。ぜひ一緒に日本から世界に販売をしていきたいと思います。 プログラムへの相談、申し込みはこちらから＝＞ Link プログラムで支援しているお客様のご登壇 2024年11月13日に開催した発表会当日は、３社にご登壇いただきました。 株式会社Works Human Intelligence　最高戦略責任者（CSMO）兼 Partner Div.統括　髙橋 総一郎 様 主に、Migrate to AWS と Innovate with AWS のお客様事例としてご登壇いただきました。 膨大なソースコードを持つ大規模システムを2027年に全顧客を SaaS 移行する取り組みや、AWSとの連携事例、生成AIにおけるプロトタイピング支援など包括的な取り組みをご紹介 株式会社ソラコム　CTO 兼 CEO of Americas　安川 健太 様 Scale with AWS のお客様事例として海外展開の観点からご支援例をご紹介いただきました。 日本のみならず、海外でも AWS との営業連携をどのように推進しているか、AWS Global Passport 事例についてもご紹介いただきました。 株式会社デジタルキューブ　代表取締役社長　小賀 浩通 様 地方企業でありながら、Innovate with AWS とScale with AWS を通じて、AWS を利用して企業価値を高めている企業の例としてご登壇いただきました。 地方企業ながら AWS を利活用し地方企業の未来を支援してゆく、地方企業こそクラウドのテクノロジーを活用して地域発のイノベーションを実現したいとご紹介いただきました。 左から、アマゾン ウェブ サービス ジャパン合同会社 佐藤 有紀子、株式会社Works Human Intelligence 髙橋 総一郎 様、株式会社ソラコム 安川 健太 様、株式会社デジタルキューブ 小賀 浩通 様 ご登壇いただきました高橋様、安川様、小賀様ありがとうございました。 参加したメディア各社からも活発な質疑交換が行われ、日本における SaaS の重要性がますます高まり、期待が寄せられることを確認しました。 プログラムへの相談、申し込みはこちらから => Link

本ブログは、IQVIA サービシーズ ジャパン合同会社 と Amazon Web Services Japan が共同で執筆しました。 IQVIA は、データ・テクノロジー・高度な分析・ 専門性を駆使することにより、 ヘルスケアや人々の健康の進展に取り組むお客様をご支援するグローバルリーディングカンパニーです。 お客様とともに、 近代的なそして効果的かつ効率的なヘルスケアシステムの実現を重ねていくことによって、 ビジネスと患者さんの治療アウトカムを変革する画期的なソリューションを生み出しています。 抱えていた課題 IQVIA サービシーズ ジャパンでは、臨床試験や市販後調査（PMS）、医薬品関連文書の作成等の業務において、日本における医薬品の臨床試験の実施の基準に関する省令や治験業務を行う上での規制のように一般に公開されているドキュメントの内容を確認する必要がたびたび発生します。それらの症例や規制の内容について疑問がある場合にはガイドブックやウェブで公開されている情報を元に手作業で調査を行っていましたが、この調査に時間がかかることが課題になっていました。 また、実際の薬品の開発のプロセスで行われる臨床試験のプロジェクトの中でも情報の検索・調査が課題になっていました。 プロジェクトには、臨床試験が適切に実施されているかを監視する役割である臨床開発モニターが大規模なプロジェクトで数十人といった規模で参加します。そのプロジェクトの中で行われた質疑応答については、Q&A の形で社内に蓄積しておき、臨床開発モニターがその Q&A を調べることでプロジェクトに関する情報を確認することがあります。ただし、この Q&A は膨大な数になるため人手での調査には多くの時間を消費しており、平均して 月合計 204 時間を費やしていました。 上述のように多数の業務中の情報確認のための検索・調査に費やす時間が多大にかかっていることに加えて、人によって必要な情報にたどり着くまでのスキルに差異があり、慣れていないメンバーではかなりの時間をこの調査にかけてしまっている場合もありました。 ソリューション 調査効率の向上のために、IQVIA サービシーズ ジャパンでは Amazon Bedrock のナレッジベースを用いた RAG(Retrieval-Augmented Generation) ベースの AI チャットソリューションを構築しました。Amazon Bedrock のナレッジベースは、データソースへのカスタム統合を構築してデータフローを管理することなく、取り込みから取得、迅速な拡張まで、RAG ワークフロー全体を実装するのに役立つフルマネージド機能です。 IQVIA サービシーズ ジャパンでは、少人数でこの RAG チャットの開発・運用を行う必要がありそれらのコストを小さくしたいと考えていました。そのため、はじめは自前で RAG チャットの実装を試していましたが、ドキュメントのチャンキングとインデクシングといったデータの準備からベクトルデータベースと LLM との連携をマネージドに実現することができる Bedrock ナレッジベースを採用しました。ひとまとまりの Q&A 形式のファイルを Q&A 単位で分割し質問と回答が対応するかたちで入力すると言った簡易な加工はありつつも、フィルターなどの Bedrock ナレッジベースのネイティブ機能でほとんどの要件を達成しています。また、このソリューションは AWS Amplify や AWS Lambda、Amazon DynamoDB といった フルサーバレスな構成を採用しており、運用負荷をおさえたものになっています。 IQVIA サービシーズ ジャパンではこの RAG ソリューションの検証と構築を担当者 １ 名のみで実施し、約 2 ヶ月という期間で実現しました。 導入効果 この RAG チャットソリューションを IQVIA サービシーズ ジャパン 全体に広く導入し、約 2 ヶ月で社内ユーザー 321 人を達成しました。また月あたりの検索・調査に費やしていた時間を 93 % 削減することを実現されました。 その他にも調査の苦手なメンバーでも効率的に調査を実施することが可能になり、検索結果の品質向上や均質化した答えが得られることも導入効果として挙げられています。 社内からは今回導入された部署以外でも利用したいという要望が多数あげられており、ソリューションの拡大を検討されています。現在は各部署でデータの投入部分をはじめ運用の一部を担ってもらえるようなサービスの拡張に取り組んでいます。 開発担当者の上長からも、「作成物のイメージがあれば、柔軟性高く、迅速に開発が可能で、マネージドサービスのおかげで限られたリソースでも対応できたので満足しています。また、今回の RAG チャットの開発費用に関しても想像以上に安く抑えられました。」というフィードバックをいただいています。 まとめ Amazon Bedrock のナレッジベースを用いて開発・運用コストを最適化したRAG チャットソリューションを短期間で構築された IQVIA サービシーズ ジャパン 合同会社の取り組みについてご紹介しました。 同社では、この取り組み以外にも AWS の先進的なテクノロジーと 生成 AI を活用し、より広いユーザーへ向けた新たなサービスを展開されることを検討しています。ぜひ続報をお待ちください。

こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているソリューションアーキテクトの村松、吉川、シニア事業開発マネージャーの和田です。 2024年10月3日に製造業向けオンラインセミナー「製品・サービスのスマート化 〜モノ / コトの壁とその解決手法 〜」を開催しました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開します。 製造業のお客様にとって、自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくことが求められています。しかし、コト売りへの変革においては、システムだけでなく、組織、人材、開発プロセス、販売方法、KPIなど様々な変革の壁が存在します。 当セミナーでは、自社製品やソリューションのサービタイゼーションを検討 / 実施されているお客様に、実現するために課題となる部分のご説明や解決のための方法、お客様事例のご紹介を行いました。 どうぞ皆様の事業のご参考に、各講演者の録画/資料をご活用下さい。 サービタイゼーションの壁とその克服のヒント 登壇者：アマゾン ウェブ サービス ジャパン合同会社 シニア事業開発マネージャー 和田 健太郎 動画： 資料リンク コト売りにおいてはソリューションを素早く立ち上げ、かつ立ち上げたソリューションを継続的に改善することが重要です。しかし、コト売りへの変革において製造業のお客様は様々な課題に直面していらっしゃいます。Amazon ではイノベーションを起こすためには、組織、アーキテクチャ（システム）、メカニズム、企業文化の4つの要素が重要と捉えていますが、モノ売りとコト売りではこれらの4つの要素に大きな違いがあり、それらが「壁」としてコト売りへの変革を妨げています。 本セッションでは、これらの壁としてどのようなものがあるかをご紹介しつつ、製造業に求められる変革のヒントをご説明致しました。システム面でのクラウドの活用は前提として、組織/機能、KPI等の変革を合わせて進めて頂くことが重要です。 また、これらの変革に取り組まれているお客様の事例と、AWSのご支援内容をご紹介させて頂きました 製造業がデータビジネスはじめるってよ 登壇者：古野電気株式会社 IＴ部長 峯川 和久 様 動画： 資料リンク 古野電気様は魚群探知機や商船レーダーなど船舶電子機器で世界的に高いシェアをお持ちのグローバルメーカーです。本セッションでは IT部 峯川様から「製造業がデータビジネスをはじめる課題」について、自らが率いて古野電気様にデータビジネス基盤を立ち上げた理由、チャレンジ、ソリューションを語っていただきました。古野電気様は売上の７割を海の上のビジネスが占めます。マリンビジネスでの高いシェアを背景に、”Ocean 5.0”として「海との共存共栄」をテーマに新規ビジネスとして、漁業支援、養殖、自律航行、医療などの領域でのサブスク型のデータビジネスに取り組んでいます。 製造業がデータビジネスを推進する上で、３つの壁に直面します。（１）データビジネスの創出プロセスの違い：モノ売り（提供価値最大化）とデータビジネス（価値創造継続）では顧客との関わり方が全く異なリます。（２）マネジメント／人財戦略：メーカーの考えはトップダウン・リスク回避・スキル特化人財ですが、データビジネスではボトムアップ・チャレンジ重視・コミュ力多様性人財が重視されます。（３）採算管理／投資計画：メーカーは個別原価計算志向ですが、データビジネスでは一つのデータがさまざまなビジネスに利用されるためバスケット志向の損益管理が求められます。 これらの壁に対して峯川様は（１）創出プロセスのための「場」を作る。そのための「データ基盤」を整備する。（２）マネジメント／人財戦略としてサッカーフォーメーション型の組織運営。（３）採算管理／投資計画上「データ基盤」を１つに集約しそこでしっかり固定費管理をする。これらが重要と唱えられました。これを実現するために必要な「データプラットフォームの要件」を定義し、それを実現するデータ基盤「JuBuRaw（ジャブロー）」を AWS 上に構築されました。JuBuRaw はデータカタログ管理に Amazon DataZone を先進的に採用し、スピーディな開発のために AWS の Professional Service を活用されました。 高いデータビジネスのための壁を乗り越えるための古野電気様の取り組みはぜひ動画をご覧ください。 峯川様は日本のメーカーの維持とプライドと伝統を死守しつつデータプラットフォームを使いこなすことで企業成長を実現できると今後の抱負を語られました。 「お客様の声から学ぶ」製品・サービスの継続的改善と 生成 AI 活用の可能性 登壇者：横河電機株式会社 デジタル戦略本部 山下 純子 様 横河電機様は計測、制御、情報技術を基盤に多様な製品やソリューションを提供しています。安全で高品質な製品やサービスを提供することで、お客様の課題解決に貢献し、長期的なパートナーシップを築く取り組みを進めています。デジタル戦略本部山下様はコーポレート部門として社内の事業部メンバーと協業してデータ活用による社員生産性向上やお客様への価値向上に取り組んでいます。このセッションでは、製品に関わるデータの分析を行い製品・サービス改善を実現した事例や、組織横断的にデータを活用するまでに乗り越えた課題についてご紹介頂きました。また、生成AIを組み込むことで今後の更なる進化の可能性についても語って頂きました。 山下様の部門では、データ活用を推進していく上で、お客様に近いビジネス部門との協力を重要視しています。一方で、非 IT 人材におけるデータ・ドリブンマネジメントに対するスキルを持った人材育成・データ活用文化の強化を行なっていく必要があります。デジタル戦略本部では、BI ツールセミナーやデータリテラシートレーニングなどを全社に提供し、数百名から数千名規模の人材教育を行っています。更に、ただ受講するだけでなく、実践的なデータ活用まで踏み込んで改善の支援を進めています。結果として数億円規模のコスト効果を示すことができています。 また、生成 AI の活用にも言及されています。IT 部門として、Knowledge を蓄積するストレージ を用意できていても、それを活用するということができていないのが課題です。Knowledge データについて、特にコールセンターやアンケートのようなお客様の声を理解して活動するために、これまで NLP (自然言語処理) 技術を取り入れてデータ分析を進めてきました。しかし、大量のデータから意味のあるデータを抽出するためには、不要なデータを掻き分けていく前処理が必要になります。これに対して生成 AI によってお客様の声から重要なキーワードの抽出を行うことで、従来よりも容易に期待した精度が出せることが明らかになりました。また、PoC の際にご利用頂いた Amazon Bedrock について、安価で且つ手軽に使用でき、既存のデータ活用基盤からの拡張も容易に実現できた、といったご評価を頂いております。 「LOGINECT」で挑む、物流クライシスに向けたTOPPAN物流DXの取り組みのご紹介 登壇者：TOPPANデジタル株式会社 事業開発センター LOGINECT事業開発部 物流システム開発T 係長 武 孝 様 動画： 資料リンク TOPPAN デジタル様は DX 事業推進のコンセプトとして、Erhoeht-X を掲げられ、「製造・流通 DX」をはじめとした 5 つのカテゴリーを重点的に事業拡大を行っていらっしゃいます。各事業はサイクル型ビジネスモデルを軸に展開していて、導入だけにとどまらず、BPO、データ分析、コンサルティング領域を通して付加価値の実現を推進されています。 物流 DX においては、「LOGINECT」というソリューションを提供され、人的リソース不足の課題に対し、「倉庫 DX」と「配送 DX」の2つのサービス基軸で次世代の物流エコシステム構築を目指されています。 本講演では LOGINECT の中でも「LOGINECT 可視化・分析サービス」に関して、個社対応システムから SaaS 化への展開に際して、ぶつかった複数の壁とそれらをどのように乗り越えたかについてお話いただきました。 まず、個社対応システムにおいては、「リソースに限界があり、ビジネスの拡大が困難」という壁に対して、「共通ソリューションを SaaS 化する」という方法でビジネス拡大を目指されました。しかし、SaaS 化した後は、「手動デプロイによる横展開時のスピード感の遅れ」「お客様ごとに異なるデータ形式に合わせた加工作業が発生」という新たな壁に直面されます。これらに対しては、「インフラを AWS リソースで完結することで Terraform を活用」「AWS Glue の活用でデータ構造の違いを吸収」「社内クラウド専門部隊構築」などの施策で解決を試みられています。 また、LOGINECT は「可視化・分析サービス」以外にも様々なソリューションを提供されていますが、昨今では様々なソリューションのインテグレーションやグローバル展開にも挑まれていらっしゃいます。講演の後半ではこれらの取り組みを進めるチームの役割や、新規ソリューションの内容、チャンレンジについてもお話頂きました。 スマートプロダクトビジネスを最大化する生成 AI 活用アーキテクチャ 登壇者：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 村松　謙 動画： 資料リンク イベント最後のセッションでは、AWS よりスマートプロダクトにおける生成AI活用で克服すべき課題や解決するためのアーキテクチャ・AWS サービスをご紹介しました。 スマートプロダクトにおいては、ユーザーの声に迅速に応えてタイムリーに継続的に製品をリリースする必要があります。さらに、生成 AI の普及によってユーザーの声の分析や活用がさらに民主化されていき、あらゆる側面で顧客の声が活用されるようになっていくことで、改善のスピードが高速化されていきます。スマートプロダクトは、あらゆるフェーズで生成 AI を活用するユースケースがありますが、その中でも今回は Voice of Customer の活用・改善による顧客価値の向上にフォーカスしてお伝えさせて頂きました。 顧客価値を向上させるため、スマートプロダクトビジネスにおける Voice of Customer データの種類や、活用者となるステークホルダーの実現したい内容・KPI をご紹介しました。下の図のように、生成AIの登場により、大規模言語モデルを通じてより人間に近い推論能力を実現し、かつ自然言語による指示・質問をすることで、言語処理を簡単に実現することができるようになりました。本セッションでは、営業・マーケティング部門と保守・カスタマーサポート部門における課題と生成 AI の具体的なケイパビリティ・お客様事例をご紹介しました。 後半では、Voice of Customer データの分析を行なっていくにあたっての 3 つの課題 (品質・データコラボレーション・検索性) と AWS サービスによる改善方法についてご紹介しました。 最後に、生成 AI の活用をこれから始めていくお客様や使い始めていくにあたって不安があるお客様に向けて、コストや後戻りを最小限にして徐々にデータ・生成 AI 活用を始めていくアプローチや、AWS からご提供させて頂く支援プログラムのご紹介をしました。 おわりに 本セミナーでは、製造業のお客様が自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくために乗り越えるべき壁や、その克服のヒントをご紹介し、実際にサービタイゼーションを実現されたお客様の事例と体験談を共有いただきました。また、スマートプロダクトにおける生成 AI の活用方法についてもご紹介させて頂きました。 本ブログは、事業開発マネージャーの和田健太郎、ソリューションアーキテクトの村松謙、吉川晃平が執筆しました。

この記事は、 OpenSearch optimized instance (OR1) is game changing for indexing performance and cost を翻訳したものです。 Amazon OpenSearch Service は、アプリケーション監視、ログ分析、オブザーバビリティ、Web サイト検索などのユースケースで、ビジネスデータや運用データのリアルタイム検索、監視、分析を安全に実現にします。 この記事では、 2023 年 11 月 29 日に導入された 、OpenSearch 最適化インスタンスである OR1 について検討します。 OR1 は Amazon OpenSearch Service のインスタンスタイプで、大量のデータを保存するためのコスト効率の高い方法を提供します。OR1 インスタンスを使用するドメインでは、 Amazon Elastic Block Store (Amazon EBS) ボリュームをプライマリストレージとして使用し、データが書き込まれるとすぐに Amazon Simple Storage Service (Amazon S3) に同期的にコピーされます。OR1 インスタンスは、高い耐久性と共に、インデクシングのスループットも向上します。 OR1 の詳細については、 紹介ブログ記事 をご覧ください。 インデックスに対して書き込みを行っている間は、レプリカを 1 つ維持することをお勧めします。ただし、ロールオーバー後にインデックスに対する書き込みが行われなくなった後は、レプリカを 0 に切り替えることができます。 これは、データが Amazon S3 に永続化されているため、安全に行えます。 ノードの障害と交換が発生した場合、データは Amazon S3 から自動的に復元されますが、修復操作中は一部のデータアクセスができなくなるため、アクティブに書き込まれていないインデックスの検索に高可用性が必要な場合は、レプリカを 0 にしないでください。 ゴール このブログ記事では、OR1 が OpenSearch ワークロードのパフォーマンスにどのような影響を与えるかを探ります。 OR1 インスタンスは、セグメントレプリケーションを提供することで、プライマリシャードでのみインデックス作成を行うため、CPU サイクルを節約できます。これにより、ノードは同じ計算リソースで、より多くのデータをインデックス化できるか、インデックス作成に使用するリソースを減らし、検索やその他の操作に使えるリソースを増やすことができます。 この記事では、インデックス作成の負荷が高いワークロードを想定し、パフォーマンステストを行います。 従来、 Amazon Elastic Compute Cloud (Amazon EC2) の R6g インスタンスは、Amazon EBS ストレージに依存するインデックス作成の負荷が高いワークロードに適した高性能な選択肢でした。Im4gn インスタンスは、高スループットと低レイテンシーのディスク書き込みに向いた、ローカル NVMe SSD を提供します。 この記事の範囲では、インデクシングのパフォーマンスのみに焦点を当て、OR1 のインデクシング性能を、これら 2 つのインスタンスタイプと比較します。 設定 パフォーマンステストでは、次の図に示すように複数のコンポーネントを設定しました。 テストプロセスについては以下の通りです: AWS Step Functions は、環境のクリーンアップとインデックスマッピングのセットアップ、およびバッチテストの実行のための初期化ステップを調整します。 AWS Batch は、OpenTelemetry JSON 形式のログデータをインデックス化するための並列ジョブを実行します。 ジョブは、 OpenSearch Rust Client と AWS Identity and Access Management (IAM) 認証を使用して、ランダム化されたログを生成するカスタム Rust プログラムを実行します。 OpenSearch Service ドメインは、OpenSearch 2.11、2 つのアベイラビリティーゾーン、きめ細かいアクセス制御、 AWS Key Management Service (AWS KMS) による保存時の暗号化、TLS による転送時の暗号化で設定されています。 インデックスマッピングは、初期化ステップの一部で、次のようになります。 { "index_patterns": [ "logs-*" ], "data_stream": { "timestamp_field": { "name": "time" } }, "template": { "settings": { "number_of_shards": , "number_of_replicas": 1, "refresh_interval": "20s" }, "mappings": { "dynamic": false, "properties": { "traceId": { "type": "keyword" }, "spanId": { "type": "keyword" }, "severityText": { "type": "keyword" }, "flags": { "type": "long" }, "time": { "type": "date", "format": "date_time" }, "severityNumber": { "type": "long" }, "droppedAttributesCount": { "type": "long" }, "serviceName": { "type": "keyword" }, "body": { "type": "text" }, "observedTime": { "type": "date", "format": "date_time" }, "schemaUrl": { "type": "keyword" }, "resource": { "type": "flat_object" }, "instrumentationScope": { "type": "flat_object" } } } } } データストリーム を使用して、ロールオーバー構成を簡素化し、 ベストプラクティス に従って、プライマリシャードのサイズを 50 GiB 以下に抑えています。 不要なインデクシングアクティビティを回避し、 flat_object フィールドタイプを使用して フィールドマッピングの爆発 を回避するようにマッピングを最適化しました。 参考までに、使用した Index State Management (ISM) ポリシーは以下の通りです。 { "policy": { "default_state": "hot", "states": [ { "name": "hot", "actions": [ { "rollover": { "min_primary_shard_size": "50gb" } } ], "transitions": [] } ], "ism_template": [ { "index_patterns": [ "logs-*" ] } ] } } 平均ドキュメントサイズは 1.6 KiB で、バルクサイズは 1 バルクあたり 4,000 ドキュメントのため、1 バルクあたり約 6.26 MiB (非圧縮時) になります。 プロトコルのテスト プロトコルのパラメータは次のとおりです。 データノードの数: 6 または 12 ジョブの並列処理数: 75、40 プライマリシャード数: 12、48、96 (12 ノードの場合) レプリカの数: 1 (合計 2 コピー) インスタンスタイプ (それぞれ 16 vCPU): or1.4xlarge.search r6g.4xlarge.search im4gn.4xlarge.search Cluster Instance type vCPU RAM JVM size or1-target or1.4xlarge.search 16 128 32 im4gn-target im4gn.4xlarge.search 16 64 32 r6g-target r6g.4xlarge.search 16 128 32 im4gn クラスターのメモリ容量は他の 2 つの半分ですが、それでも各環境の JVM ヒープサイズはおよそ 32GiB で同じです。 パフォーマンステストの結果 パフォーマンステストでは、最初にクライアントごとに 75 の並列ジョブと 4,000 ドキュメントの 750 バッチ (合計 2 億 2,500 万ドキュメント) から始めました。その後、シャード数、データノード数、レプリカ数、ジョブ数を調整しました。 構成 1 : 6 データノード、12 プライマリシャード、1 レプリカ この構成では、データノードを 6 つ、プライマリシャードを 12 個、レプリカを 1 つ使用しました。そして、次のようなパフォーマンスを観測しました。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 65-80% 24 分 156 kdoc/s 243 MiB/s im4gn-target 89-97% 34 分 110 kdoc/s 172 MiB/s r6g-target 88-95% 34 分 110 kdoc/s 172 MiB/s この表で強調表示されているように、im4gn クラスターと r6g クラスターの CPU 使用率が非常に高く、 アドミッションコントロール がトリガーされ、ドキュメントが拒否されています。 OR1 は、CPU 使用率が 80% 未満で持続していることを示しており、これは非常に良いターゲットです。 注意すべき点 : 本番環境では、エクスポネンシャルバックオフを使ってインデクシングを再試行し、一時的な拒否によるドキュメント欠落が起きないようにしてください。 バルクインデクシング操作は 200 OK を返しますが、一部失敗する可能性があります。すべての文書が正常にインデックスされたことを確認するには、レスポンスの本文をチェックする必要があります。 並列ジョブの数を 75 から 40 に減らしながら、クライアントごとに 4,000 ドキュメントの 750 バッチ (合計 120M ドキュメント) を維持すると、次のようになります。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 25-60% 20 分 100 kdoc/秒 156 MiB/秒 im4gn-target 75-93% 19 分 105 kdoc/秒 164 MiB/秒 r6g-target 77-90% 20 分 100 kdoc/秒 156 MiB/秒 スループットと CPU 使用率は減少しましたが、Im4gn と R6g の CPU 使用率は高い状態が続いており、一方で OR1 には余剰の CPU 容量があることがわかります。 構成 2 : 6 データノード、48 プライマリシャード、1 レプリカ この構成では、プライマリシャードの数を 12 から 48 に増やしました。これにより、インデックス作成のための並列処理能力が向上します。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 60-80% 21 分 178 kdoc/s 278 MiB/s im4gn-target 67-95% 34 分 110 kdoc/s 172 MiB/s r6g-target 70-88% 37 分 101 kdoc/s 158 MiB/s OR1 のインデックス処理スループットは向上しましたが、Im4gn と R6g は CPU 使用率がまだ非常に高いため、改善は見られませんでした。 並列ジョブを 40 に減らし、プライマリシャードを 48 に保ったところ、OR1 の最小 CPU が 12 のプライマリシャードから増加し、やや負荷がかかることがわかります。一方で、R6g の CPU 使用率は大幅に改善されました。しかし Im4gn の CPU 使用率はまだ高い状態です。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 16 分 125 kdoc/s 195 MiB/s im4gn-target 80-94% 18 分 111 kdoc/s 173 MiB/s r6g-target 70-80% 21 分 95 kdoc/s 148 MiB/s 構成 3 : 12 データノード、96 プライマリシャード、1 レプリカ この構成では、元の構成から始め、コンピューティング能力を増強しました。ノード数を 6 から 12 に増やし、プライマリシャード数を 96 に増やしました。 クラスター CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 18 分 208 kdoc/s 325 MiB/s im4gn-target 74-90% 20 分 187 kdoc/s 293 MiB/s r6g-target 60-78% 24 分 156 kdoc/s 244 MiB/s OR1 と R6g は CPU 使用率が 80% 未満で良好なパフォーマンスを発揮しています。OR1 は R6g と比較して CPU 使用率が 30% 少なく、パフォーマンスが 33% 優れています。 Im4gn は CPU 使用率が 90% のままですが、パフォーマンスも非常に良好です。 並列ジョブの数を 75 から 40 に減らすと、次のようになります。 クラスター CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 11 分 182 kdoc/s 284 MiB/s im4gn-target 70-90% 11 分 182 kdoc/s 284 MiB/s r6g-target 60-77% 12 分 167 kdoc/s 260 MiB/s 並列ジョブの数を 75 から 40 に減らすと、OR1 と Im4gn インスタンスが同等になり、R6g も非常に近くなりました。 解釈 OR1 インスタンスは、レプリカがセグメントのコピーによって生成されるため、プライマリシャードのみを書き込めばよいため、インデックス作成を高速化します。Img4n インスタンスや R6g インスタンスと比較して高性能にも関わらず、CPU 使用率も低いため、追加の負荷 (検索) やクラスターサイズの削減の余地があります。 6 ノードの OR1 クラスターで 48 個のプライマリシャードを持ち、秒あたり 178,000 ドキュメントをインデックス化するのと、12 ノードの Im4gn クラスターで 96 個のプライマリシャードを持ち、秒あたり 187,000 ドキュメントをインデックス化するのと、12 ノードの R6g クラスターで 96 個のプライマリシャードを持ち、秒あたり 156,000 ドキュメントをインデックス化するのを比較できます。 OR1 は、より大きな Im4gn クラスターとほぼ同等のパフォーマンスを発揮し、より大きな R6g クラスターよりも優れたパフォーマンスを示します。 OR1 インスタンスを使用する場合のサイズ設定方法 結果から分かるように、OR1 インスタンスはより高いスループット率でデータを処理できます。しかし、プライマリシャードの数を増やすと、リモートバックドストレージのためにパフォーマンスが低下します。 OR1 インスタンスタイプから最高のスループットを得るには、通常より大きなバッチサイズを使用し、Index State Management (ISM) ポリシーを使ってサイズに基づきインデックスをロールオーバーすることで、インデックスごとのプライマリシャードの数を効果的に制限できます。また、OR1 インスタンスタイプはより多くの並列処理を処理できるため、接続数を増やすこともできます。 検索に関しては、OR1 はパフォーマンスに直接影響しません。しかし、図から分かるように、OR1 インスタンスの CPU 使用率は Im4gn インスタンスや R6g インスタンスよりも低くなっています。これにより、より多くのアクティビティ (検索やインジェスト) を実行できるか、インスタンスのサイズやカウントを削減して、コストを削減できる可能性があります。 OR1 の結論と推奨事項 新しい OR1 インスタンスタイプは、他のインスタンスタイプよりも強力なインデックス作成機能を提供します。これは、日々バッチ処理でインデックス作成を行う場合や、高い持続的なスループットを必要とする場合など、インデックス作成の負荷が高いワークロードにとって重要です。 OR1 インスタンスタイプでは、既存のインスタンスタイプよりもパフォーマンスに対する価格が 30% 優れているため、コスト削減も可能です。複数のレプリカを追加する場合、OR1 インスタンスでは CPU 使用率への影響がほとんどないため、パフォーマンスあたりの価格が下がります。一方、他のインスタンスタイプでは、インデックス処理スループットが低下します。 この repost 記事 を参照して、インデックス作成のためのワークロードの最適化の完全な手順を確認してください。 著者について C é dric Pelvet は AWS プリンシパルソリューションアーキテクトです。リアルタイムデータと検索ワークロードに対するスケーラブルなソリューションの設計をお客様にご支援しています。プライベートでは、新しい言語を学んだり、バイオリンの練習をしています。

この記事は、 Reducing long-term logging expenses by 4,800% with Amazon OpenSearch Service を翻訳したものです。 サーバーログ、サービスログ、アプリケーションログ、クリックストリーム、イベントストリームなどの時間制限のあるデータに Amazon OpenSearch Service を使用する場合、ストレージコストはソリューション全体における主要なコストの 1 つです。昨年、OpenSearch Service では、ログデータを様々な階層に保存できる新機能がリリースされ、データの待機時間、耐久性、可用性のトレードオフが可能になりました。2023 年 10 月、 OpenSearch Service は最大 30TB の NVMe SSD ストレージを備えた im4gn データノードのサポートを発表しました 。2023 年 11 月、 OpenSearch Service は OpenSearch 最適化インスタンスファミリー or1 を導入し 、社内ベンチマークで既存インスタンスに比べ最大 30% のパフォーマンス価格比の改善を実現し、 Amazon Simple Storage Service (Amazon S3) を使用してイレブンナインの耐久性を提供しました。最後に、2024 年 5 月、OpenSearch Service は Amazon OpenSearch Service と Amazon S3 の zero-ETL 統合 の一般提供を発表しました。これらの新機能は、 既存の UltraWarm インスタンス (GB あたりのストレージコストを最大 90% 削減) と、 UltraWarm のコールドストレージ オプション (UltraWarm インデックスを分離し、アクセス頻度の低いデータを Amazon S3 に永続的に保存できる) に加わります。 このポストでは、コスト、レイテンシー、スループット、データの永続性と可用性、保持期間、データアクセスにおける選択肢のトレードオフを理解できるように、例を用いて説明します。これにより、データの価値を最大化し、コストを最小化するための適切なデプロイメントを選択できるようになります。 要件の検討 ロギングソリューションを設計する際は、適切なトレードオフを行う前提条件として、要件を明確に定義する必要があります。レイテンシー、耐久性、可用性、コストに関する要件を慎重に検討してください。さらに、OpenSearch Service に送信するデータ、データの保持期間、そのデータへのアクセス計画を検討する必要があります。 この議論の目的のために、OpenSearch インスタンスのストレージをエフェメラルストレージと Amazon S3 バックドストレージの 2 つのクラスに分けます。エフェメラルドストレージクラスには、Nonvolatile Memory Express SSDs (NVMe SSDs) と Amazon Elastic Block Store (Amazon EBS) ボリュームを使用する OpenSearch ノードが含まれます。Amazon S3 バックドストレージクラスには、UltraWarm ノード、UltraWarm コールドストレージ、or1 インスタンス、および Amazon S3 との Zero-ETL で利用できる Amazon S3 ストレージが含まれます。ロギングソリューションを設計する際は、次の点を考慮してください。 レイテンシ – ミリ秒単位で結果を必要とする場合は、エフェメラルストレージをバックエンドに使用する必要があります。秒または分単位の結果で許容できる場合は、Amazon S3 をバックエンドに使用することでコストを削減できます。 スループット – 一般的に、エフェメラルストレージをバックエンドに使用したインスタンスの方がスループットが高くなります。im4gn のように NVMe SSDs を搭載したインスタンスは通常最高のスループットを提供し、EBS ボリュームも良好なスループットを提供します。or1 インスタンスは、プライマリシャードに Amazon EBS ストレージを利用しながら、 Amazon S3 とセグメントレプリケーション を活用することで、レプリケーションのコンピューティングコストを削減し、NVMe ベースのインスタンスと同等またはそれ以上のインデックス作成スループットを提供します。 データ耐久性 – ホット層 (データノード) に格納されたデータは最も低いレイテンシーですが、耐久性も最も低くなります。OpenSearch Service は、レプリカを通じてホット層のデータの自動復旧を提供し、コストを伴いながら耐久性を確保します。OpenSearch が Amazon S3 (UltraWarm、UltraWarm コールドストレージ、Amazon S3 との zero-ETL、or1 インスタンス) に格納するデータは、Amazon S3 のイレブンナインの耐久性の恩恵を受けます。 データ可用性 – ベストプラクティス では、エフェメラルストレージのデータにレプリカを使用することを推奨しています。少なくとも 1 つのレプリカがあれば、ノードの障害が発生しても、すべてのデータにアクセスできます。ただし、各レプリカはコストの増加を伴います。一時的な利用不可を許容できる場合は、or1 インスタンスと Amazon S3 ストレージを使用することで、レプリカを削減できます。 保持期間 – すべてのストレージ層のデータにはコストがかかります。分析のためにデータを長期間保持するほど、そのデータの 1GB あたりの累積コストが高くなります。すべての価値が失われるまでにデータを保持しなければならない最長期間を特定してください。場合によっては、コンプライアンス要件によって保持期間が制限される可能性があります。 データアクセス – 一般に、Amazon S3 をバックエンドに使用したインスタンスは、コンピューティングに対するストレージの比率がはるかに高く、コスト削減につながりますが、大量のワークロードには十分なコンピューティング能力がありません。クエリ量が多い、またはクエリが大量のデータにまたがる場合は、エフェメラルストレージをバックエンドに使用するのが適切です。ダイレクトクエリ (Amazon S3 ストレージをバックエンドに使用) は、頻繁にクエリされないデータに対する大量のクエリに最適です。 これらの観点から要件を検討すると、その回答が実装の選択肢を導き出すことになります。トレードオフを判断するために、次のセクションで詳細な例を説明します。 OpenSearch Service のコストモデル OpenSearch Service のデプロイのコストを理解するには、コストの特徴を理解する必要があります。OpenSearch Service には、マネージドクラスターとサーバーレスの 2 つの異なるデプロイオプションがあります。この投稿ではマネージドクラスターのみを考慮します。 Amazon OpenSearch Serverless はすでにデータを階層化し、ストレージを管理してくれるためです。マネージドクラスターを使用する場合は、データノード、UltraWarm ノード、専用マスターノードを構成し、それぞれの機能に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプを選択します。OpenSearch Service はこれらのノードをデプロイ、管理し、REST エンドポイントを介して OpenSearch と OpenSearch Dashboards を提供します。Amazon EBS バックドインスタンスまたは NVMe SSD ドライブ付きインスタンスを選択できます。OpenSearch Service は、マネージドクラスターのインスタンスに対して時間単位の料金を請求します。Amazon EBS バックドインスタンスを選択した場合、サービスはプロビジョニングされたストレージと、構成した プロビジョニング IOPS に対して料金を請求します。or1 ノード、UltraWarm ノード、または UltraWarm コールドストレージを選択した場合、OpenSearch Service は Amazon S3 で消費されたストレージに対して料金を請求します。最後に、 転送されたデータに対するサービス料金 がかかります。 使用例 コストとパフォーマンスのトレードオフを検討するために、使用例を使用します。この例のコストとサイズは、ベストプラクティスに基づいており、方向性を示すものです。同様の節約効果が期待できますが、すべてのワークロードはユニークであり、実際のコストは本記事で示すものとは大きく異なる可能性があります。 架空の大手清涼飲料メーカー Fizzywig のユースケースを見ていきましょう。飲料の製造工場が多数あり、製造ラインからは膨大なログが出力されています。当初はすべてホットデプロイで 1 日 10 GB のログを生成していましたが、今日では 1 日 3 TB のログデータが発生し、経営陣はコスト削減を求めています。Fizzywig はログデータをイベントのデバッグと分析、および 1 年分のログデータの履歴分析に使用しています。OpenSearch Service でそのデータを保存し利用するコストを計算しましょう。 エフェメラルストレージの導入 Fizzywig の現在のデプロイメントは、エフェメラルストレージを備えた 189 個の r6g.12xlarge.search データノード (UltraWarm 層なし) です。OpenSearch Service でデータをインデックス化すると、OpenSearch はインデックスデータ構造を構築し、ソースデータよりも通常 10% 大きくなります。また、運用オーバーヘッドのために 25% の空き領域を残す必要があります。毎日 3TB のソースデータがある場合、オーバーヘッドを含めてプライマリ (最初のコピー) に 4.125TB のストレージが必要になります。Fizzywig は、最大のデータ耐久性と可用性を確保するため、 OpenSearch Service Multi-AZ with Standby オプションを使用して 2 つのレプリカコピーを作成するベストプラクティスに従っています。これにより、1 日あたりのストレージ需要は 12.375TB に増加します。1 年分のデータを保存するには、365 日を掛けて 4.5PB のストレージが必要になります。 このストレージ容量をプロビジョニングするには、im4gn.16xlarge.search インスタンスまたは or1.16.xlarge.search インスタンスを選択することもできます。次の表は、これらのインスタンスタイプごとに、データのコピー数に応じて必要なインスタンス数を示しています。 . ノードあたりの最大ストレージ (GB) Primary (1 Copy) Primary + Replica (2 Copies) Primary + 2 Replicas (3 Copies) im4gn.16xlarge.search 30,000 52 104 156 or1.16xlarge.search 36,000 42 84 126 r6g.12xlarge.search 24,000 63 126 189 前の表と次の説明は、ストレージニーズに厳密に基づいています。or1 インスタンスと im4gn インスタンスの両方とも、r6g インスタンスよりも高いスループットを提供するため、さらにコストを削減できます。計算の節約額は、ワークロードとインスタンスタイプによって 10 〜 40% 異なります。これらの節約は直接利益に反映されるわけではなく、インデックスとシャード戦略のスケーリングと変更を行って初めて実現できます。前の表と後続の計算では、これらのデプロイメントはコンピューティングリソースが過剰にプロビジョニングされており、ストレージに制限があると一般的に想定されています。コンピューティングリソースをさらに拡張する必要がある場合、r6g に比べて or1 と im4gn でより多くの節約が見込めます。 次の表は、指定された 3 つの異なるデータストレージサイズにわたる 3 つの異なるインスタンスタイプの合計クラスターコストを表しています。これらは オンデマンド米国東部 (バージニア北部) AWS リージョンのコスト に基づいており、インスタンス時間、or1 インスタンスの Amazon S3 コスト、および or1 インスタンスと r6g インスタンスの Amazon EBS ストレージコストが含まれています。 . Primary (1 Copy) Primary + Replica (2 Copies) Primary + 2 Replicas (3 Copies) im4gn.16xlarge.search $3,977,145 $7,954,290 $11,931,435 or1.16xlarge.search $4,691,952 $9,354,996 $14,018,041 r6g.12xlarge.search $4,420,585 $8,841,170 $13,261,755 この表は、4.5 PB のワークロードに対する 1 コピー、2 コピー、3 コピーのコスト (該当する場合は Amazon S3 と Amazon EBS のコストを含む) を示しています。この投稿では、「1 コピー」とは、レプリケーション数をゼロに設定した最初のデータコピーを指します。「2 コピー」にはデータのレプリカコピーが含まれ、「3 コピー」にはプライマリと 2 つのレプリカが含まれます。ご覧のとおり、各レプリカはソリューションのコストを倍増させます。もちろん、各レプリカはデータの可用性と耐久性を高めます。1 コピー (プライマリのみ) の場合、単一ノードの障害で (or1 インスタンスを除いて) データを失うことになります。1 つのレプリカがある場合、2 ノードの障害で一部またはすべてのデータを失う可能性があります。2 つのレプリカがある場合、3 ノードの障害でのみデータを失うことになります。 or1 インスタンスはこの規則の例外です。or1 インスタンスは、1 コピーのデプロイをサポートできます。これらのインスタンスは、Amazon S3 をバッキングストアとして使用し、すべてのインデックスデータを Amazon S3 に書き込み、レプリケーションと耐久性を実現します。確認された書き込みはすべて Amazon S3 に永続化されるため、ノードの停止時にデータの可用性を失うリスクはありますが、1 コピーで実行できます。データノードが利用できなくなった場合、通常10~20分程度の復旧時間が必要になり、その間はインデックスが利用できなくなります (ステータスが赤色表示になります)。システム (例: 取り込みパイプラインバッファ) だけでなく、顧客に対してもこの可用性の低下を許容できるかどうかを慎重に評価する必要があります。許容できる場合は、前の表に示されている 1 コピー (プライマリ) の列に基づいて、コストを 1,400 万ドルから 470 万ドルに削減できます。 リザーブドインスタンス OpenSearch Service では、1 年契約と 3 年契約の Reserved Instance (RI) がサポートされています。これには、前払い費用なし (NURI)、一部前払い (PURI)、全額前払い (AURI) があります。すべての RI 契約でコストが下がりますが、3 年契約の全額前払い RI が最も割引率が高くなります。Fizzywig のワークロードに 3 年契約の全額前払い RI の割引を適用した場合の年間コストは、次の表のようになります。 . Primary Primary + Replica Primary + 2 Replicas im4gn.16xlarge.search $1,909,076 $3,818,152 $5,727,228 or1.16xlarge.search $3,413,371 $6,826,742 $10,240,113 r6g.12xlarge.search $3,268,074 $6,536,148 $9,804,222 RI は、コードやアーキテクチャの変更を行うことなく、コストを削減する簡単な方法を提供します。この作業負荷に RI を採用すると、3 コピーの im4gn コストが 570 万ドルに、or1 インスタンスの 1 コピーコストが 320 万ドルになります。 Amazon S3 バックドストレージの導入 前述のデプロイメントはベースラインとの比較のために役立ちます。実際には、コストを管理可能な範囲に抑えるために、Amazon S3 バックドストレージオプションのいずれかを選択するでしょう。 OpenSearch Service の UltraWarm インスタンスは、すべてのデータを Amazon S3 に保存し、UltraWarm ノードをこの完全なデータセットの上の ホットキャッシュ として利用します。UltraWarm は、6 か月前の 1 日分のデータに対して複数のクエリを実行するなど、小さな時間範囲のデータに対する対話型クエリに最適です。アクセスパターンを慎重に評価し、UltraWarm のキャッシュのような動作があなたのニーズに合うかどうかを検討してください。UltraWarm の最初のクエリのレイテンシは、クエリする必要があるデータ量に応じて拡大します。 OpenSearch Service ドメインを UltraWarm 用に設計する際、ホット保持期間とウォーム保持期間を決める必要があります。ほとんどの OpenSearch Service のお客様は、ホット保持期間を 7 ～ 14 日間程度に設定し、ウォーム保持期間で全保持期間の残りを構成しています。Fizzywig のシナリオでは、ホット保持期間を 14 日間、UltraWarm 保持期間を 351 日間に設定しています。また、ホット層では、 2 コピー (プライマリと 1 つのレプリカ) のデプロイを使用しています。 14 日間に必要なホットストレージ (1 日の取り込み量 4.125 TB に基づく) は 115.5 TB です。3 種類のインスタンスタイプのいずれかを 6 つデプロイすれば、このインデクシングとストレージをサポートできます。UltraWarm は Amazon S3 に単一のレプリカを格納し、追加のストレージオーバーヘッドは必要ありません。そのため、351 日間のストレージニーズは 1.158 PiB となります。これは 58 台の UltraWarm1.large.search インスタンスでサポートできます。次の表は、ホット層に 3 年間の AURI を適用したこのデプロイメントの総コストを示しています。or1 インスタンスの Amazon S3 コストは S3 列に含まれています。 . Hot UltraWarm S3 Total im4gn.16xlarge.search $220,278 $1,361,654 $333,590 $1,915,523 or1.16xlarge.search $337,696 $1,361,654 $418,136 $2,117,487 r6g.12xlarge.search $270,410 $1,361,654 $333,590 $1,965,655 さらにコストを削減するには、データを UltraWarm コールドストレージに移行できます。コールドストレージは、データの可用性を下げることでコストを削減します。データを照会するには、対象のインデックスを UltraWarm 層に再アタッチするための API 呼び出しを発行する必要があります。1 年分のデータの典型的なパターンは、14 日間ホット、76 日間 UltraWarm、275 日間コールドストレージです。このパターンに従うと、6 つのホットノードと 13 の UltraWarm1.large.search ノードを使用します。次の表は、Fizzywig の 3TB の日次ワークロードを実行するコストを示しています。Amazon S3 の使用料金は、 UltraWarm ノード + S3 列に含まれています。 . Hot UltraWarm nodes + S3 Cold Total im4gn.16xlarge.search $220,278 $377,429 $261,360 $859,067 or1.16xlarge.search $337,696 $461,975 $261,360 $1,061,031 r6g.12xlarge.search $270,410 $377,429 $261,360 $909,199 Amazon S3 バックドのストレージオプションを利用することで、単一コピーまたは 1 デプロイで 33 万 7,000 ドル、1 インスタンスで最大年間 100 万ドルと、さらにコストを削減できます。 OpenSearch Service の Amazon S3 との zero-ETL 統合 OpenSearch Service zero-ETL for Amazon S3 を使用すると、すべての二次データと古いデータを Amazon S3 に保持できます。二次データとは、VPC フローログや WAF ログなど、直接検査する価値は低い大量のデータです。このようなデプロイメントでは、頻繁にクエリされないデータの大部分を Amazon S3 に保持し、最新のデータのみホット層に保持します。場合によっては、二次データの一部をサンプリングし、ホット層にも一定割合を保持します。Fizzywig は、すべてのデータの 7 日分をホット層に保持することにしました。残りのデータはダイレクトクエリ (DQ) でアクセスします。 ダイレクトクエリを使用する場合、データを JSON、Parquet、CSV 形式で保存できます。Parquet 形式はダイレクトクエリに最適で、データに対して約 75% の圧縮が行われます。Fizzywig は Amazon OpenSearch Ingestion を使用しており、これにより Parquet 形式のデータを直接 Amazon S3 に書き込むことができます。毎日 3 TB のソースデータが 750 GB の Parquet データに圧縮されます。OpenSearch Service はダイレクトクエリ用のコンピューティングユニットのプールを維持しています。これらの OpenSearch コンピューティングユニット (OCU) は時間単位で課金され、アクセスするデータ量に基づいてスケーリングされます。この会話では、Fizzywig がデバッグセッションを行い、1 日分のデータ (750 GB) に対して 50 件のクエリを実行すると想定しています。次の表は、毎日 3 TB のワークロードを 7 日間ホットで、358 日間 Amazon S3 に保存する場合の年間コストの概要を示しています。 . Hot DQ Cost OR1 S3 Raw Data S3 Total im4gn.16xlarge.search $220,278 $2,195 $0 $65,772 $288,245 or1.16xlarge.search $337,696 $2,195 $84,546 $65,772 $490,209 r6g.12xlarge.search $270,410 $2,195 $0 $65,772 $338,377 大変な旅路でした! Fizzywig 社のロギングコストは、年間最高 1,400 万ドルから、Amazon S3 からの zero-ETL によるダイレクトクエリを使用することで年間 28 万 8,000 ドルまで下がりました。これは 4,800% の節約です! サンプリングと圧縮 この投稿では、データサイズに焦点を当て、そのデータへのアクセス方法に応じてトレードオフを行うことができる 1 つのデータフットプリントを見てきました。OpenSearch には、保存するデータ量を削減することで、さらに経済性を変えることができる追加機能があります。 ログワークロードの場合、 OpenSearch Ingestion サンプリングを利用して、OpenSearch Service に送信するデータのサイズを削減 できます。サンプリングは、全体のデータが統計的特性を持ち、一部が全体を代表できる場合に適しています。たとえば、オブザーバビリティワークロードを実行している場合、システムでのリクエスト処理のトレースを代表するサンプリングを取得するために、データの 10% 程度を送信するだけで十分な場合があります。 ワークロードに応じて、 圧縮アルゴリズム を使用することもできます。OpenSearch Service では最近、デフォルトの最高圧縮に比べて、より高い圧縮率と低い伸張待ち時間を実現できる Zstandard (zstd) 圧縮のサポートがリリースされました。 結論 OpenSearch Service を使うことで、Fizzywig は、コスト、レイテンシー、スループット、耐久性と可用性、データ保持、そして好ましいアクセスパターンのバランスを取ることができました。彼らはロギングソリューションのコストを 4,800% 削減することができ、経営陣は大喜びでした。 全体的に見ると、im4gn インスタンスの絶対金額が最も低くなります。ただし、いくつか注意点があります。まず、or1 インスタンスは、特に書き込み集中型のワークロードで、より高いスループットを提供できます。これにより、コンピューティングの必要性が低減され、追加の節約につながる可能性があります。さらに、or1 の高い耐久性により、レプリケーションを減らして可用性と耐久性を維持できるため、コストが削減されます。もう 1 つの検討事項は RAM です。r6g インスタンスは追加の RAM を備えているため、クエリの待ち時間が短縮されます。UltraWarm と組み合わせ、ホット/ウォーム/コールドの比率を変えることで、r6g インスタンスも優れた選択肢となります。 大量のロギングワークロードがありますか? これらの方法の一部またはすべてから恩恵を受けましたか? ご意見をお聞かせください! 著者について Jon Handler は、カリフォルニア州パロアルトに拠点を置く Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。Jon は OpenSearch と Amazon OpenSearch Service を担当し、ベクトル、検索、ログ分析のワークロードを AWS Cloud に移行したいさまざまな顧客に対して支援とガイダンスを提供しています。AWS に入社する前は、ソフトウェア開発者として 4 年間大規模な EC サイトの検索エンジンをコーディングしていました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号と博士号を取得しています。

はじめに 本ブログは、全日本空輸株式会社と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。 AWS ソリューションアーキテクトの三宅です。 全日本空輸株式会社様では、2021 年よりグループ全社を横断したデータマネジメント基盤として「BlueLake」を整備し、社内のデータ活用の推進に取り組まれています。2024 年 6 月 20日 ～ 21 日に開催された AWS Summit Japan では、全日本空輸株式会社 デジタル変革室 イノベーション推進部 データマネジメントチーム の丸山 様にご登壇いただき、データ活用の取り組みで得たナレッジを 14 の秘伝として紹介いただきました。 本記事は、ANA 様のご登壇内容をブログ記事として再構成したものとなります。 私が所属する ANA デジタル変革室 イノベーション推進部 データマネジメントチームでは主に、ANA を中心としたグループのデータ戦略の策定と、それに沿ったデータ基盤の環境整備と開発管理を行っています。データ活用の推進を担う同部のデータデザインチームや、BlueLake のシステム開発や運用を担うグループ会社の ANA システムズ株式会社とも協力して、ANA のデータ活用を進めています。 ANA グループのかかげる「データの民主化」とは ANA グループのデータの民主化は、グループ ４ 万人の従業員一人一人がデータを自由に扱い、価値を生み出すことができる状態を目指しています。これまでの ANA におけるデータ活用は、各システム部門が中心となって、データの収集から加工・集計・分析し、結果を共有するまでを行ってきました。データの民主化を実現するために、データの収集はシステム部門が行い、それ以降はレベルや目的に応じてシステム部門とビジネス部門が共に手を取り合い、協創しながら実行していくことにしました。データ活用の中心はビジネス部門で推進し、システム部門はそうした取り組みを環境とスキルの両面でサポートします。 ANA のデータの民主化の取り組みは大きく「仕組み」「人財」「ガバナンス」に大別することができます。 まずは「仕組み」として、BlueLake 基盤のアーキテクチャ、データ活用ツールである BlueLake Apps に関する秘伝について 8 つ紹介します。 秘伝 1　データを物理的に 1 箇所に集める戦略 ANA グループは主力ブランドの ANA に加えて、Peach や Air Japan を含めた航空事業を展開しています。また、マイルで買い物ができる EC サイトの ANA Mall やモバイル決済サービスの ANA Pay といった 「ノンエア」 と呼ばれる非航空事業にも注力しており、マイルで生活できる世界の実現に向けて、様々なサービスを提供しています。 BlueLake が立ち上がる前から存在しているデータ基盤は、航空事業に特化した業務別のデータ基盤であったため、データの民主化を推進していくためにも、統合的なデータ基盤を再構築する必要がありました。様々なデータの管理方法があるなか、ANA では物理的にデータを 1 箇所に集約させて、一元管理をしています。個別の業務ごとに特化したシステムから生み出されるデータは、データの型や持ち方、キーなどがそれぞれで異なっています。最近は SaaS を利用することも増えてきており、データは複雑性を増しています。 そのなかで、様々な特性のあるデータを時間の断面でコントロールすることがデータを分析する上で重要であると考え、複数の要素を、固定した時間で横断的に収集し、データとして扱いやすい形で保持できるよう一貫性もったコントロールを行っています。 秘伝 2 プライバシーに配慮した 2 層構造 多くの人が自由にデータを扱えるように、BlueLake では、確実なコンプライアンスのもとでデータを管理する必要がありました。BlueLake ではプライバシーを考慮し、生データを扱う層と仮名加工済みデータを扱う層の 2 層構造でデータを管理しています。具体的なアーキテクチャとしては、Amazon S3 を活用した データレイクと、Amazon Redshift と Snowflake を活用したデータウェアハウスから構成されており、この 2 つの構造をそれぞれ別の AWS アカウントで完全に分離することでデータの管理を行っています。4 万人が自由に使えるデータは主に下図の下の段のデータになっており、仮名加工処理が施されていて、個人情報保護法や GDPR などにも対応しています。完全に分離した 2 層構造によってデータをしっかりと守りつつ、柔軟に活用できる環境を実現しています。 秘伝 3 Amazon S3 を中心としたアーキテクチャ データレイクとして Amazon S3 を採用しています。データ活用に関するトレンドの移り変わりは非常に早いですが、併せて毎回抜本的にアーキテクチャを刷新するのは非常にコストがかかります。そこで私たちは Amazon S3 を中心とすることで、時代や戦略に合わせてサービスの使い分けをしています。Amazon S3 はコネクターも非常に豊富で、DeltaLake や Iceberg といったフォーマットにも対応しています。私たちは AmazonS3 を中心として、様々なサービスを組み合わせながら、目的やスキルレベルに応じたツールを用意しています。 秘伝 4 目的やレベル別に多種なツールを整備 ANA グループの 4 万人の従業員は日々の業務も、データ活用スキルも様々です。こうした人たちが何か 1 つのツールを使ってデータを活用するのは非常に難しいだろうと考え、ANA では現在 6 つの データ活用ツールである BlueLake Apps を整備しています。機微な情報を取り扱う「BlueLake Custo」、データ抽出を行う「BlueLake Exto」、社内基準のレポートを全社に展開する「BlueLake Repo」、セルフ BI ツールの「BlueLake Pivo」、データ実験環境の「BlueLake Labo」、そしてなんでもできる「BlueLake Pro」 の 6 つです。リッチなラインナップにも見えますが、ライセンス課金のツールは利用者を見定めて、従量課金のツールは使いすぎないようにガバナンスを効かせることで、コストを抑えながら運用しています。目的やスキルレベルに応じて使い分けのできるツールを用意することで、データ活用の可能性が広がると考えています。 秘伝 5 4 万人が同じ基準で見られるダッシュボード データを活用する上で、同じ目線でデータを捉えていくことは非常に重要だと考えています。しかし、部門や部署が多いと、独自の集計や分析が行われるため、基準を合わせて物事を進めるのが難しい場面もあります。 そこで、BlueLake Repo は 4 万人が同じ基準で見られるダッシュボードを目指して、Amazon QuickSight を用いて展開しています。展開にあたって工夫したポイントが 2 つあります。1 つは、アカウント作成の部分で、社内が使っているグループウェアの IdP と Amazon Cognito と AWS Lambda を組み合わせて、自動でアカウントが作成される仕組みを構築しました。 2 つ目は、Amazon QuickSight の埋め込み機能を使い、“BlueLake Repo” の名称で社内向けのサービスとして展開したことです。BlueLake Repo では、ユーザーが高度の分析を行うことはありません。そのため、データ活用の第一歩として、利用するハードルをできる限り下げて、誰でも気軽に BlueLake に飛び込んでこれるように工夫しています。 秘伝 6 抽出ツールは必要（現在の答え） データ活用ツールを整理していく中で、データ抽出が分析の目的になることはないため、業務整理を行ってデータ抽出をなくすべきだ、というアドバイスを何度か伺ったことがありました。私自身、もしアドバイスをする立場なら同じことを言うかもしれませんが、実際、データ抽出を無くすのはそう簡単ではありません。これまでの社内のデータ活用の状況を踏まえて、データ抽出をなくすのはまだ早いと判断しました。しかしながら、意外にも抽出に特化したツールというのは世の中にあまりありませんでした。 そこで、AWS のサービスを駆使して、ドラッグ＆ドロップで使える SQL ツールである BlueLake Exto 開発しました。まだこのツールはリリースして間もないため機能も潤沢には備わっていないのですが、 GUI で作成した SQL をレシピとして保存できる機能や、社員同士でレシピを共有できる機能などを開発する予定です。会社ごとに文化や置かれた環境が異なるため、必ずしもデータマネジメント一般論に従う必要はないと考えています。 秘伝 7 ユーザーフレンドリーな”ナレッジの宝庫” 基盤である BlueLake と データ活用ツールの BlueLake Apps 、これらを整備しただけでは、データの民主化はなかなか進みません。BlueLake と BlueLake Apps の橋渡しをするのがデータカタログです。 ANA のデータを活用する 4 万人の従業員が利用することを考えると、データカタログには、とにかくデータも UI も分かりやすいこと、データに関する質問やナレッジを共有できること、そして 4 万人が使えるコストであることが求められました。当時、世の中にはいわゆるデータをよく知る人たちが利用するデータカタログはありましたが、どれも高機能で、私たちの利用目的に合っていませんでした。 そのため、データカタログも AWS のサービスを活用して内製で開発することにしました。それがANA のデータカタログ「Moana」です。無駄な情報は省き、分かりやすい UI にし、南国リゾートを彷彿させる可愛らしい名前にしています。カタログ機能に加えて、社内用語をまとめたディクショナリー機能や社員同士の SNS 機能を搭載し、ANA のデータの民主化を推進する上で欠かせないツールに成長しています。世の中にないものを自分たちで作ることができるのが、AWS の良いところだと思います。 秘伝 8 AWS は自社の世界観を表現できる データの民主化を社内に広めていくことは、マーケティング活動そのものであると考えています。とにかく多くの人に BlueLake を知ってもらう、そして、BlueLake と聞けば、データを便利に使えるプラットフォームであるとイメージしてもらえるようになることが、非常に重要であると考えています。 社内では常に Apps 名でコミュニケーションを行っているため、Apps を製品名で呼ぶ人たちはほとんどいません。レベルに合わせた自分たちの世界観を表現する上でも、AWS のカスタマイズ性の高さは非常に有効であると考えています。 ここからは、データを活用する人「人財」に関する秘伝を 2 つ紹介します。 秘伝 9 多様なチャネルを駆使したコミュニティ ANA ではデータコミュニティを BlueLake DataCircle と名付けて、様々な取り組みを行っています。 コミュニティの特徴として、多様なチャネルを使ってコミュニティ活動を形成していることが挙げられます。具体的には、BlueLake の紹介イベントや、初級者向けにデータの重要性や危険性を伝えるイベントを開催したり、もう少し具体的に興味を持ってもらうために、社内外のデータ活用を行っている人との対談イベントも開催しています。 少し変わった取り組みとして、データドリブン通信というものがあります。データに特化した社内報を我々で作成し、データ活用で知っておいてほしい情報や、社内のデータ活用事例を読みやすくまとめて、グループ全体のポータルサイトで発信しています。 秘伝 10 100 時間を超える内製のデータ教育プログラム 全社に向けた啓発と文化の醸成を目的にしたコミュニティ活動以外にも、実際にデータを扱える人を養成するための活動を内製で行っています。参加希望者はこちらから選ぶのではなく募集し、それぞれが業務での課題やデータ活用の可能性を感じながら教育に取り組みます。そして、その講師は私と同様グランドスタッフ経験者や元整備士で現在データサイエンティストとして社内で活躍しているメンバーが行います。100 時間を超える研修を通じて、データ活用ってこういうことかという勘所と基礎的なスキルを身につけ、業務を理解したデータの専門家となり、各部門で活躍しています。 最後に、「ガバナンス」に関する秘伝を 4 つ紹介します。 秘伝 11 ANA が着目した八つの項目 まず最初にガバナンスに着手した際、DMBOK の輪読から始めました。内容をメンバーで分担しながら理解するところまでは良かったのですが、いざ ANA のガバナンスをまとめるときに困ったのが項目の選定でした。最初からあれもこれもで、絵に描いた餅になってしまっては、ガバナンスをまとめる意味がありません。悩んだ挙句、私たちは 8 つの項目を採用しました。今回は、工夫したガバナンスの一部を紹介します。 秘伝 12 ANA のデータスチュワードは ２ 種類 例えば、上記の項目 2 の「体制と役割」の中では、データスチュワードを定義しています。データスチュワードにも様々なものがありますが、ANA ではまず、BlueLake データスチュワードと、業務データスチュワードの 2 つを定義するところから始めています。BlueLake データスチュワードはデータガバナンス・データマネジメントの視点で、開発・運用を統制しています。業務データスチュワードは社内のデータ利用者からの開発・活用案件を集約し、優先度決め等を行います。双方がデータスチュワードシップ会議にて定期的にコミュニケーションをとることで、ANAのデータのありたい姿を実現させています。 秘伝 13 安全に価値を創出するためのルール グループ 4 万人がデータを活用していく上で欠かせないのが、グループ会社横断でのルールです。「利用料及び契約」の項目では、グループ会社とのデータやツールの利用に関する規定や、個人情報に関する国内外の法令への対応方針を定めています。また、セキュリティやプライバシーに関する教育や啓発にも取り組んでいます。契約や利用料の調整は非常に大変です。しかし、グループ全体でデータによって安全に価値を生み出す上では必要不可欠だと考えています。 秘伝 14 BlueLake DataManagement 最後の秘伝として、ここまでお話しした全ての秘伝は、データ戦略、データマネジメントポリシー、データ利活用ガイドラインの３ 部構成で、BlueLake Data Management として、体系的に文書化してまとめています。ANA ではこの BlueLake データマネジメントに沿って、データの基盤をデザインし、データから価値を生み出す土壌を整備しています。 最後に これら 14 の秘伝は、データの民主化のための手段に過ぎません。そしてデータの民主化自体もまた、目的ではありません。 デジタルとデータを活用したビジネスの変革を通して、ANA をご利用になるお客様の体験価値を向上させ、４ 万人の従業員の働き方に変化をもたらし、そして、企業の持続性と ESG を両立した価値創造を推進していきたいと考えています。お客様、従業員、環境、この 3 つにプラスの価値をもたらすために、今後もデータの活用に取り組んでいきます。

シニア GTM アナリティクススペシャリストソリューションアーキテクトの大薗です。 2024 年 11 月 7 日に「 データガバナンス事例祭り〜AWSで実現するモダンな取り組み〜 」を開催しました。今回の事例祭りでは AWS の Analytics サービスを活用してデータガバナンスの取り組みを実現している富士通株式会社様、株式会社日本経済新聞社様、 LINEヤフー株式会社様、全日本空輸株式会社様にご登壇いただき、AWS からもデータガバナンスを実現する AWS サービスを紹介しました。本ブログでは当日の各発表内容について紹介します。 データガバナンスを実現する AWS サービスのご紹介 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 神部 洋介 資料ダウンロード データガバナンスの重要性と AWS データガバナンスフレームワークのご紹介 AWS の神部からは、オープニングセッションとして、データガバナンスを実現するための様々な AWS サービスについてご紹介しました。 昨今の様々な調査結果も示すように、データガバナンスは企業にとって重要な取り組みとなっています。データガバナンスの目的にはデータを保護する守りの側面と、データを活用してイノベーションを推進する攻めの側面の 2 つがありますが、データの増加、データソースの増加、データ活用者の増加といった課題から推進を難しくさせている点に触れ、AWS で提唱しているデータガバナンスフレームワークについてご紹介しました。データを取得してから活用するまでのフローにおいて、重要な 3 つの領域として Curate、Understand、Protect の 3つがあり、AWS ではこのフレームワークに基づいて様々なサービスを提供しデータガバナンスを支援している点を説明し、各領域における代表的なサービスを紹介していきました。 フレームワークの 3 領域における AWS の代表的なサービス まず Curate の領域では、 AWS Glue (Glue) の機密データ検知やデータ品質管理の機能が紹介されました。Glue を使うことで信頼性の高いデータを作り出し、品質を維持できるためのデータガバナンスの第一歩となります。次に Understand の領域では、 Amazon DataZone (DataZone) のデータポータル、メタデータ、データリネージの機能が紹介されました。DataZone を利用することで、どのようなデータがあるかを簡単に検索でき、メタデータから詳細を理解できるほか、生成 AI によりメタデータを自動生成することも可能です。またデータリネージ機能によりデータのルートや変更履歴を追跡できます。最後の Protect の領域では、 Amazon Redshift (Redshift) のダイナミックデータマスキングと Apache Iceberg が取り上げられました。Redshift のダイナミックデータマスキングを活用することにより、ユーザーごとにデータの表示内容を動的に制御でき、データのセキュア化とデータ活用の両立を図れます。Apache Iceberg はタイムトラベル機能やスキーマ進化機能を持ち、データ変更の追跡や監査要件への対応が容易になります。 このように AWS のサービスや最新のテクノロジーを活用することで、データガバナンスの実現が加速できることを強調し、セッションを締めくくりました。 富士通のデータ利活用プラットフォーム OneData におけるデータガバナンスの取り組み 富士通株式会社 デジタルシステムプラットフォーム本部 Enabling Technologies 統括部 マネージャー 久下 泰明 氏 資料ダウンロード データセキュリティの確保とデータ利活用の促進の両立 富士通株式会社 (以下、富士通) では全社を挙げたデジタルトランスフォーメーションの中核に、データドリブン経営の実現を掲げています。それに向けた経営プロジェクト「OneFujitsu」の一環として、全社データ利活用プラットフォーム「OneData」の整備が始まりました。「OneData」ではデータの提供者、利用者、データ利活用推進者の 3 つの役割を定義し、適切なデータガバナンスの下でデータ利活用を促進するサービスが提供されています。しかし、データ利活用を進める上では、データセキュリティの確保とデータ利活用の促進という 2 つの側面を両立させることが、データガバナンスの大きな課題となります。守りと攻めの両立は容易ではありません。そこで富士通では具体的に 2 つの取り組みを実施し、このデータガバナンスの課題解決を目指しました。 ビジネスデータカタログの導入 1 つ目は AWS のデータガバナンスサービス DataZone を活用したビジネスデータカタログです。DataZone の導入により、データ検索、理解、利用許可の一連の流れをデータガバナンスの下で一元的に実現できるよう構築を進めています。業務コンテキストに基づきデータを発見し価値を理解した上で、メタデータを参照しながらデータの利用許可を 1つの Web ポータルから申請できるようにします。これまで外部ワークフローを経る必要があった利用許可プロセスも DataZone 上で完結し、データガバナンスに基づくデータ利活用のアジリティの大幅な向上を目指しています。 データ品質管理の導入 2 つ目はデータ品質管理の取り組みです。DataZone と Glue Data Quality を組み合わせ、提供側と利用側の双方でデータガバナンスに基づくデータ品質の可視化を進めています。提供側ではデータの業務ルール適合性をチェックし、問題があれば上流システムの改善に役立てます。利用側では分析要件に基づきデータ品質を確認の上、データアセットをサブスクライブすべきかを判断することで、データガバナンスに基づく精度の高いデータ活用の実現を目指しています。 このようにデータガバナンスの観点から、富士通では AWS サービスを活用しながらデータ利活用の促進とセキュリティ確保の両立を実践しています。今後も AWS の機能拡充に期待を寄せつつ、「OneData」におけるデータガバナンスの取り組みを進化させていく考えだと述べられていました。 Apache Icebergで実現する次世代データガバナンス：日経リスク＆コンプライアンスの挑戦 株式会社日本経済新聞社 情報サービスユニット ソフトウェアエンジニア 大塚 恭平 氏 資料ダウンロード データドリブンサービス開発に取り組む日本経済新聞社が直面した課題 株式会社日本経済新聞社 (以下、日本経済新聞社) が提供する法人向けサービス「日経リスク&コンプライアンス」において、Apache Iceberg を活用した次世代のデータガバナンス基盤について紹介されました。日本経済新聞社は、取引先のリスク評価を行うための法人向けサービス開発において、金融庁のガイドラインに準拠するための新機能を追加する必要に迫られていました。具体的には、サービスを利用して取引先のリスク評価を行った際の操作記録を保管し、必要に応じて提示できるようにする必要がありました。年間数億レコードの操作記録を扱う見込みだったため、堅牢でスケーラブルかつ低コストなストレージ基盤が求められました。様々なアーキテクチャを検討した結果、データレイクを支えるオープンソース技術である Apache Iceberg を活用する方針を決めました。 Apache Iceberg の特長を生かしたアーキテクチャ 日本経済新聞社が Apache Iceberg を選んだ理由は、 Amazon Athena (Athena) を含む多くのコンピュートエンジンが Apache Iceberg をサポートしていること、 Amazon S3 (S3) に操作レコードを低コストで保存できること、トランザクション性や スキーマ進化、データの論理削除などの高度な機能に対応できることにありました。実際に構築したアーキテクチャでは、アプリケーションから Amazon Kinesis Data Streams に操作レコードをストリーミングで書き込み、Glue で Apache Iceberg 形式に変換して S3 へ保存しています。ユーザーがアプリで操作履歴を参照する際は、Athena を使って S3 上のデータをクエリします。 Apache Iceberg を用いることで、低コストでありながら高い可用性とデータ整合性を実現。また日付やテナント ID で パーティショニングを行うことで、クエリの高速化とコスト最適化も図れたとのことです。さらに定期的に AWS Step Functions (Step Functions) を使ったメンテナンスジョブを実行し、スモールファイル化の解消やレコード削除などのテーブル最適化を行なっています。 日本経済新聞社では、本プロジェクトを通じて大量データを安全に低コストで保持し、高速なクエリとセキュアな消去を実現 するシステムの構築ノウハウを得ることができました。今後は Apache Iceberg エコシステムの進化に追付することで、よりシンプルかつ低コストなアーキテクチャを実現し、他サービスへのアーキテクチャ横展開を検討しているとのことでした。 LINEヤフー社での DWH としての AWS 導入背景と安全管理のための取り組み LINEヤフー株式会社 データエンジニアリング部 データマネジメントチーム リーダー 尾尻 恒 氏 資料ダウンロード 金融データを取り扱う堅牢なオンプレミスデータレイクを Amazon Redshift Serverless に移行 LINEヤフー株式会社 (以下、LINEヤフー) では、金融データを取り扱う既存の Hadoop ベースのオンプレミスデータレイクシステムが EOL を迎えたことから、新たなデータウェアハウス (DWH) の導入を進めました。既存システムではメンテナンスコスト増加やエンジニア採用の難しさ、データ利活用の課題があったため、 FISC 要件を満たしセキュリティを強化しつつ、効率的な運用とデータ活用の促進を実現できるクラウドベースの DWH が求められていました。 LINEヤフーではセキュリティ、管理・運用、スケーラビリティ、データ活用の 4 つの観点を重要な要件として捉え、これらの要件を満たすプラットフォームとして Amazon Redshift Serverless (Redshift Serverless) を中心とした AWS のサービス群を選定しました。セキュリティ面では AWS IAM Identity Center と既存 Identity Provider (IdP) の連携によりユーザー認証と権限の一元管理を実現し、運用面ではオンプレミスと連携した既存 Notebook の流用と AWS マネージドサービスの活用により容易な運用が実現できる見込みが立ちました。スケーラビリティでは Redshift Serverless や Glue などのサーバーレスサービスを活用することにより、データ量に応じた柔軟なスケーリングが可能となり、データ活用面では非開発職でも利用可能な BI /分析ツールと連携してデータ活用を促進できると判断されました。 データ収集と活用のアーキテクチャ 実際に構築したアーキテクチャでは、オンプレミスのデータを AWS Direct Connect で転送し、Glue や Step Functions などのサービスで機密データのハッシュ化など、適切な ETL 処理を行った上で Redshift Serverless に取り込んでいます。ユーザー認証には IdP を活用した Single Sign On (SSO) で AWS マネージメントコンソールでログインし、Redshift Serverless が提供する機能であるロールベースのアクセスコントロールを行なっています。そのうえで利用者は、汎用的な分析のために Redshift Query Editor v2.0 、可視化に Amazon QuickSight (QuickSight)、高度な分析の用途として Amazon SageMaker (SageMaker) などのサービスを使ってデータ活用を行なっているとのことです。 オンプレミスデータレイクを運用していた尾尻氏は、この DWH 導入プロジェクトを通じて、少人数チームでもクラウドであれば迅速なシステム構築が可能であることを実感されました。一方で、予期せぬ制限にも直面し、運用での工夫が必要になるケースもあったといいます。しかし、AWS の豊富なサービスを組み合わせることで、こうした課題を乗り越えることができたと述べています。今後は、この導入した基盤を生かしてデータカタログソリューションの導入やデータマスキングの実施など、更にデータガバナンスの取り組みを強化していき、組織全体のデータ活用の成熟度を高めていくとのことでした。 ANAグループで実践するデータマネジメントと私たちが大切にしていること 全日本空輸株式会社 デジタル変革室 イノベーション推進部 データマネジメントチーム 丸山 雄大 氏 グループ内外のデータを一元集約する BlueLake 全日本空輸株式会社 (以下、ANA) は、グループ横断でデータの活用を推進するため、データ基盤「BlueLake」の整備を進めてきました。事業の拡大に伴いデータ量やそのバリエーションが増加するなど課題が増えてきたため、2021 年にデータマネジメント構想を掲げ、人材育成支援、プロセスの整備、システムの進化の 3 本柱で取り組みを開始しました。その中核となるのが BlueLake です。BlueLake では ANA グループ内外のデータを一元集約し、スキルレベルに応じたツールで活用できる環境を整備しています。ガバナンスを重視し、データの蓄積から価値創出までの一貫したプロセスを設計しています。 BlueLake において大切にしている 3 つのこと BlueLakeには 3 つの特徴があります。1 つ目は「安心で安全なデータ基盤」であることです。S3 をデータレイクとして活用し、生データを分析可能な Redshift、匿名加工データのみを扱う Snowflake などを組み合わせた 2 層構造となっています。個人情報や機密データは Redshift 側で適切に加工し、Snowflake 側には公開データのみを置くことで、セキュリティを確保しつつ社員の自由な活用を可能にしているとのことです。2 つ目の特徴は、「ワクワクするデータ分析ツール」の提供です。ANA グループには 4 万人の従業員がおり、データリテラシーは様々です。そこで QuickSight、 Amazon WorkSpaces 、Tableau など、目的やスキルに合わせて使い分けられる多様なツールを用意しています。ツール名も製品名ではなく”BlueLake XXX”というキャッチーな呼称を用いるなど、データ活用への親しみやすさを意識しているとのことです。3 つ目は、「二つの Single Source of Truth (SSoT)」の実現です。SSoT には 2 つの側面があり、1 つ目は「データの民主化のための SSoT」で、BlueLake 内でデータの標準化を行い、異なるソースのデータを結合できるよう環境を整えています。レイヤー化やデータモデリングにも取り組んでいます。2 つ目は「データ基盤としての SSoT」で、S3 にデータをファイルとして集約し、基盤アーキテクチャを単純化することで、時代の変化 (技術の進化のスピード) に柔軟に対応できるよう心がけています。現在、新たに Open Table Format 導入を見据え、Apache Iceberg の検証も進めているとのことでした。 データ戦略、データマネジメントポリシー、データ利活用ガイドラインの文書化 また ANA では、データマネジメントに関して、データ戦略、データマネジメントポリシー、データ利活用ガイドラインの 3 部構成で体系的な文書化を行っています。その中核となるのがデータマネジメントポリシーで、その中で上述したような BlueLake のデータ基盤に関する方針やルール、体制などを定義しています。しかし丸山氏は、データマネジメントの考え方を文書化するだけでは実行に移すことは容易ではなく、組織全体でデータマネジメントを理解し取り組んでいく必要があると強調しました。そのため ANA では、データ活用推進体制を戦略、実行、監督の 3 つに分けた三権分立の体制を検討中です。戦略は BlueLake の全社横断推進、実行はデータエンジニアなどによる開発、監督ではリスクマネジメントやガバナンスの観点での役割を想定しているとのことです。 データガバナンスでは最終的に人が最も重要です。優れたポリシーがあってもそれを実行する人がいなければ絵に描いた餅となってしまいます。ANA では従業員の力を結集し、データ活用を通じた事業や社会への貢献を目指していくと宣言され、セッションを締めくくりました。 まとめ 「データガバナンス事例祭り」と題した本セミナーでは、近年注目されているデータガバナンスというテーマに関連する、多様な観点を含む事例が盛り沢山となりました。各社よりご発表いただいたセッションにて紹介された AWS サービスにご興味ある場合は無料で個別相談会を開催しております。皆様からのお申込みをお待ちしております。 お申込みリンク 本ブログは、ソリューションアーキテクトの大薗が作成しました。

はじめに 2024 年 10 月 10 日、新聞・出版・メディア業界のお客様向けに、「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」というテーマでセミナーをオンラインにて開催いたしました。このセミナーの開催報告として当日お話しした内容や資料をご紹介いたします。文章生成やコンテンツ分析、PDF 解析など、生成 AI は Publisher にとっても様々な活用方法が見いだされるようになり、業務効率化や新しい価値の創造に大きく貢献し始めています。本セミナーでは、このように生成 AI の活用が広がってきた中で見えてきた課題にどう向き合っていくのか、Amazon や 国内のお客様の事例を交えながら AWS セッションにてお話させて頂きました。続いて、生成 AI を先駆的に活用しイノベーションを実現しているお客様にご登壇頂き、具体的な検証結果や自社プロダクトへ組み込む際の工夫点、 Amazon Bedrock の活用場面と選定理由などをお話頂きました。 Publisher のための生成 AI の事例とはじめかた アマゾン ウェブ サービス ジャパン 合同会社 メディアソリューション部 ソリューションアーキテクト 向井 稔 【 資料 】 【 動画 】 オープニングセッションとしてアマゾン ウェブ サービス ジャパン 向井より、生成 AI をはじめる上でのビジネス面と技術面の課題に対するアプローチをお話させて頂きました。ビジネス面の課題については複数の Publisher 向けの事例と共に生成 AI をどう始めたらよいのかアイデアを挙げさせて頂き、技術面の課題を解決するために提供された Amazon Bedrock についてご紹介しました。 この中で生成 AI をはじめる 1 つのアイデアとして、生成 AI を活用したビジネスユースケースのサンプル集となる Generative AI Use Cases JP をご紹介しております。 ママ向け Q&A サービス mamari の検索機能向上における生成 AI 活用～ LLM 時代の新しい検索体験に向けた試み 〜 コネヒト株式会社 機械学習エンジニア 池之上 陽平 様 【 資料 】 【 動画 】 コネヒト株式会社池之上様より、ママ向け Q&A サービスにおける生成 AI を活用した検索機能の改善の取り組みをご紹介いただきました。この中で従来の全文検索と近年注目を集めているベクトル検索について、実際の Q&A データを扱った複数のクエリパターンにおける検索結果の違いについてお話し頂いております。 生成 AI と Amazon Titan で始めるコンテンツのタグ付けとコンテンツ推薦 note株式会社 機械学習エンジニア 漆山 和樹 様 【 資料 】 【 動画 】 note株式会社漆山様より、インターネット上でコンテンツを発表できる note における生成 AI を活用したコンテンツのレコメンド機能の改善の取り組みをご紹介いただきました。この中で Amazon Titan Text Embeddings を活用したタグ付けの事例や、生成 AI を活用したタグ付けを改良する工夫についてお話し頂いております。 コンテンツ制作支援サービス ALOFA における生成 AI 活用 株式会社朝日新聞社 メディア事業本部メディア研究開発センター 嘉田 紗世 様 【 資料 】 【 動画 】 株式会社朝日新聞社嘉田様より、メディア研究開発センターで取り組まれている編集業務の作業効率化に向けた取り組みをご紹介いただきました。取材後の文字起こし作業は記事制作の中でも負担が大きいプロセスです。この作業を効率化するプロダクト 「ALOFA」の 特徴や構成と工夫点、Amazon Bedrock の活用場面と選定理由についてお話し頂きました。 おわりに 本ブログでは、2024 年 10 月 10 日に開催された「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」の内容をご紹介させていただきました。本セミナーに参加いただいた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログはソリューションアーキテクト向井が担当しました。

現代の変化のペースが速く競争の激しい製造業界では、企業はサプライチェーンの管理において、出荷の遅延、部品不足、輸送のボトルネックといった重大な課題に直面しています。 製造業の企業は、需要を予測し、市場の変動に合わせて生産を調整しながら、材料や部品のサプライヤ、生産設備、製品の流通チャネルからなるネットワークの複雑さに苦労することがよくあります。 製品の供給を保証しながら在庫コストを最小限に抑えるには、原材料の入手可能性、生産能力、物流、消費者の嗜好を慎重に検討する必要があります。 従来のサプライチェーン手法は、こうした動的な要因に対して不十分であることが多く、効率の低下、在庫切れ、過剰在庫につながります。 製造業の企業に影響を及ぼすサプライチェーンの課題 製造業の企業は、生産計画や材料管理から可視性やデータ統合に至るまで、サプライチェーン業務全体でさまざまな課題に直面しています。 主な複雑さは次のとおりです。 資材需要と生産能力のバランスを取り、スループットを最適化する効果的な資材資源計画（MRP）の策定。 水の使用量、プラスチック、リサイクルに関するサステナビリティの目標に合わせながら、製品設計の更新や規制遵守による材料組成の変化を監視。 作業指示やメンテナンス作業に必要なスペアパーツや資材を可視化することで、ダウンタイムと潜在的な収益損失の最小化。 エンドツーエンドのサプライチェーンの透明性を実現することで、データドリブンな意思決定、需要シグナルの検出、在庫予測の生成、シミュレーションによるリスク評価、混乱への積極的な対処。 このブログでは、 AWS Supply Chain と Amazon Q を連携させ、サプライチェーンの課題に対する解決策をどのように提供するのかを説明します。 これらのソリューションは、サプライチェーンデータ、生成 AI、機械学習（ML）を活用することで、実用的な洞察を提供します。 こうしたテクノロジーは、製造業の企業に革新的な戦略とデータドリブンな推奨事項を提供し、業務の合理化、リソースの最適化、大きな変化を見越した対応に役立ちます。 AWS Supply Chain AWS Supply Chain は、サプライチェーンネットワーク全体の可視性、トレーサビリティ、計画を強化するクラウドベースのアプリケーションです。 その中心となるのが、分析のために 複数のソース からのデータを統合するリポジトリである サプライチェーンデータレイク （SCDL）です。 AWS Supply Chain は、データから洞察を得る機能、ML を活用した需要予測、在庫最適化、高度な分析により、データドリブンな意思決定を促進します。 サプライチェーン業務を最新化するための次のような 包括的な機能 を提供します。 洞察 : 過剰在庫や在庫切れなどのリスクを特定し、カスタムウォッチリストやアラートのオプションを使用して在庫マップ上で可視化します。 推奨アクションとコラボレーション : ランク付けされたリスク情報とともに、在庫移動の選択肢を提示し、過去の決定から学習して推奨事項を改善します。また、問題を迅速に解決するために組み込まれたコラボレーションツールも含まれています。 需要計画 : ML を使用して正確な需要予測を生成し、市場の状況に基づいて調整し、リアルタイムで更新して余剰在庫と廃棄物を削減します。 供給計画 : ML モデルを使用して必要な資材購入を予測および計画し、在庫管理を改善し、コストを削減します。 N階層の可視性 : 外部パートナーにインサイトを広げ、取引先との注文や供給計画を確認することで計画の正確性を高めます。 サステナビリティ : サプライヤーから環境、社会、ガバナンス（ESG）データを収集して管理し、サステナビリティ基準の遵守を確保します。 複数の拠点の在庫を最適化することで、製造業の企業は統合されたサプライチェーンデータから得られる透明性、説明性を実現し、実用的なアクションにつながる分析能力を向上させることができ、運用の優秀性（オペレーショナルエクセレンス）、収益性、顧客満足度を高めることができます。 Amazon Q Amazon Bedrock を搭載した生成 AI アシスタントである Amazon Q が、 AWS Supply Chain に統合されました。 Amazon Q の自然言語インターフェースにより、SCDL 内のデータへの問い合わせと分析が可能になり、複雑な「何？」や「なぜ？」 「もしも？」 という質問に対するインテリジェントな回答が得られます。例えば、Amazon Q は「航空貨物で注文を急ぐ場合はどうなりますか？」と質問すると「航空貨物は通常 2 日で到着するため、収益への影響は 95,000 USD 減りますが、急送費用には 2,400 USD が追加されます」と回答する可能性があります。 ML モデルを活用することで、Amazon Q はサプライチェーンのデータを解釈し、貴重な洞察を導き出し、実行可能な推奨事項を生成します。 会話型のインターフェイスにより、複雑な SQL クエリやデータ操作を必要とせずに自然に対話できます。 AWS Supply Chain の Amazon Q は、戦略的洞察を求める経営幹部でも、詳細な運用を検討しているサプライチェーンの分析担当者でも、それぞれのニーズに合わせて適応します。 AI による洞察により、ボトルネック箇所の特定、プロセスの最適化、運用効率の向上に役立ちます。 生成 AI による製造エクセレンスの推進 AWS Supply Chain with Amazon Q は、生成 AI と機械学習を活用して、複雑なサプライチェーンの課題に取り組んでいます。 AWS の安全で高性能なインフラストラクチャにより、メーカーは AI の採用を加速させ、市場投入までの時間を短縮し、生産性を高め、業務を合理化し、サプライチェーンを最適化できます。 製造業の企業はすでに AWS AI/ML サービスを使用して業務を強化し、データドリブンな意思決定を可能にしています。 以下にいくつか例を挙げます。 迅速な診断と問題解決による製造現場の生産性の向上 : エレベーターおよびエスカレーター業界のグローバルリーダーである KONE は、原因分析と解決までの時間を短縮することで、現場での顧客サービスの迅速化を実現しています。 同社は Amazon Bedrock を使用して、社内文書を活用する生成 AI アプリケーションを大規模展開しています。 生成 AI テクノロジーを使用してマニュアル、工場データの分析結果、履歴データをトレーニングすることで、技術者は問題のトラブルシューティングを効率的に行い、機器メンテナンスの詳細なガイドを作成できます。 このアプローチは、製造環境における診断、問題解決、意思決定、および資産保守プロセスをスピードアップすることにより、製造現場の生産性を向上させます。 合成画像データによる製品品質と欠陥検出の強化 : 製薬会社の Merck は、AWS のサービスと生成 AI を使用して欠陥画像を合成し、正確で堅牢な欠陥検出モデルをトレーニングする際のデータの制約を克服しています。 生成 AI により、Merck のようなメーカーは合成画像を生成し、「良い」例と「悪い」例でデータセットを補強できます。 このアプローチにより、Merck は製品ライン全体で全体の不良品を 50% 以上削減し、効率の向上と廃棄物の削減を実現しました。 顧客がサステナビリティの目標を達成できるようにする : インテリジェントな気候およびエネルギーソリューションの世界的リーダーである Carrier は、AWS のサービスを利用して Abound Net Zero Management プラットフォームを拡張・強化しています。 Carrier は、Amazon Bedrock と Amazon Textract を活用することで、お客様がエネルギー消費を管理し、二酸化炭素排出量を削減できるよう支援しています。 このソリューションにより、顧客は公共料金の請求書を現地の言語でアップロードでき、Carrier は生成 AI を使用してこのデータをサステナビリティに関する実用的な洞察に変換します。 このイニシアチブは、より安全で持続可能な世界を創造するという Carrier の使命と一致しています。 これらの顧客事例は、生成 AI ソリューションが、いかに製造業の企業がイノベーションを推進し、業務効率を高め、競争が激化する環境において時代を先取りする力を与えているかを示しています。 まとめ 現代における競争の激しい製造環境では、効果的なサプライチェーン管理が運用の優秀性と持続的な成長の鍵となります。 従来の方法では、現代のサプライチェーンの複雑さに対処するには不十分であることが多く、非効率につながります。 製造業の企業は、これらの課題を克服するために AWS Supply Chain や Amazon Q などのソリューションに目を向けています。 AWS Supply Chain の一元化された SCDL と高度な分析機能を活用することで、企業はデータ主導の意思決定、可視性の向上、計画の最適化を実現できます。 Amazon Q では、製造業の企業は自然言語による問い合わせを通じてインテリジェントな洞察と実用的な推奨事項を得ることができます。 生成 AI が現実世界にもたらす影響は、製造現場の生産性の向上、品質の向上、欠陥検出能力の向上、トレーニング時間の短縮といった点で明らかです。 AWS Supply Chain と Amazon Q を採用することで、メーカーは俊敏性、回復力、持続可能な競争力を高めることができます。 業界が進化するにつれて、これらのツールはサプライチェーン運用の可能性を最大限に引き出し、イノベーションを促進し、コストを削減し、優れた顧客体験を提供するのに役立ち、長期的な成功への道を開きます。 AWS Supply Chain を利用開始するには： AWS Supply Chain と Amazon Q については、それぞれのページにアクセスして特徴や機能をご確認ください。 自分のペースで進められる技術的なウォークスルーについては、 AWS Workshop Studio をご覧ください。 インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成の方法を学びます。 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデータ主導型のツールを使用してサプライチェーンの運用を合理化しましょう。 詳細なセットアップ手順や追加のガイダンスについては、 ユーザーガイド も参照いただけます。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> Ben-Amin York Jr Ben-Amin は、フロントエンドウェブおよびモバイルテクノロジーを専門とする AWS ソリューションアーキテクトで、自動車および製造企業のデジタル変革の推進をサポートしています。 彼は AI / ML テクノロジーを扱い、それがさまざまな業界のビジネスに与える変革の影響を評価することを楽しんでいます。 自動車および製造セクターの AWS 企業顧客をサポートすることを専門としており、ビジネス目標の達成に役立つ技術指導を行っています。 Ben-Amin は、Amazon Monitron、Amazon Lookout for Vision、AWS IoT などの AWS サービスを利用して、成功の可能性を解き放っています。 Brayan Montiel Brayan Montiel は AWS のソリューションアーキテクトです。 自動車および製造業界の企業顧客をサポートし、クラウド導入技術の加速と IT インフラストラクチャの近代化を支援しています。 彼は AI / ML テクノロジーを専門としており、お客様がジ生成 AI と革新的なテクノロジーを使用して業務の成長と効率化を推進できるよう支援しています。 仕事以外では、家族と充実した時間を過ごしたり、屋外に出たり、旅行を楽しんだりしています。 Medha Aiyah Medha Aiyah は AWS のソリューションアーキテクトです。 彼女は 2022 年 12 月にテキサス大学ダラス校を卒業し、コンピューターサイエンスの理学修士号を取得しました。専門分野は、AI / ML に焦点を当てたインテリジェントシステムです。 彼女は、顧客が AWS を最適に使用してビジネス目標を達成できるようにすることで、さまざまな業界の企業顧客をサポートしています。 彼女は特に、AI / ML ソリューションを実装し、生成 AI を活用する方法についてお客様を指導することに興味を持っています。 Miles Jordan Miles Jordan は AWS のソリューションアーキテクトで、分析や検索の技術を専門としています。 彼はデータを効果的に利用することに重点を置き、あらゆる分野の企業顧客にビジネス目標を達成するための技術ガイダンスを提供しています。

この記事は、 Build an internal SaaS service with cost and usage tracking for foundation models on Amazon Bedrock を翻訳したものです。 企業は、各事業部門 (LOB) に基盤モデルへのアクセスを提供することで、生成 AI の可能性を迅速に引き出そうとしています。IT チームは、集中管理とオブザーバビリティを提供しながら、事業部門が迅速かつ俊敏にイノベーションを起こせるよう支援する責任があります。例えば、チーム間の基盤モデルの使用状況を追跡し、使用料を請求し、事業部門の関連するコストセンターに可視性を提供する必要があるかもしれません。さらに、チームごとに異なるモデルへのアクセスを規制する必要があるかもしれません。例えば、特定の基盤モデルのみが使用を承認されている場合などです。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの大手 AI 企業が提供する高性能な基盤モデルを単一の API で利用できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための幅広い機能も提供します。Amazon Bedrock はサーバーレスであるため、インフラストラクチャを管理する必要がなく、すでにご利用中の AWS サービスを使用して生成 AI 機能を安全にアプリケーションに統合およびデプロイできます。 基盤モデルのための software as a service (SaaS) レイヤーは、アクセスと利用状況の一元管理を維持しながら、エンドユーザーにシンプルで一貫したインターフェイスを提供できます。API ゲートウェイは、モデルの利用者とモデルエンドポイントサービスの間の疎結合を可能にし、変化するモデル、アーキテクチャ、呼び出し方法に適応できる柔軟性を提供します。 この記事では、組織内のチームをテナントとして捉えた場合の、マルチテナントアーキテクチャで Amazon Bedrock を使用して基盤モデルにアクセスするための内部 SaaS レイヤーの構築方法をご紹介します。特に、テナントごとの使用量とコストの追跡、およびテナントごとの使用量制限などのコントロールに焦点を当てています。このソリューションと Amazon Bedrock の利用プランが、一般的な SaaS ジャーニーフレームワークにどのように対応するかについて説明します。ソリューションのコードと AWS Cloud Development Kit (AWS CDK) テンプレートは、 GitHub リポジトリ で入手できます。 課題 AI プラットフォーム管理者は、複数の開発チームに対して基盤モデルへの標準化された簡単なアクセスを提供する必要があります。 基盤モデルへの管理されたアクセスを提供する上で、以下のような課題があります。 コストと使用状況の追跡 – 個々のテナントの基盤モデルのコストと使用状況を追跡・監査し、特定のコストセンターに費用を振り分けます 予算と使用量の制御 – テナントごとに定義された頻度での基盤モデルの許可された使用に対して、API クォータ、予算、使用制限を管理します アクセス制御とモデルガバナンス – テナントごとに承認された特定のモデルに対するアクセス制御を定義します マルチテナント標準化 API – OpenAPI 標準に準拠した基盤モデルへの一貫したアクセスを提供します API の一元管理 – モデルへのアクセスのための API キーを管理する単一のレイヤーを提供します モデルのバージョンと更新 – 新規および更新されたモデルバージョンの展開を行います ソリューションの概要 このソリューションでは、マルチテナントアプローチについて説明します。ここでのテナントは、個人のユーザー、特定のプロジェクト、チーム、あるいは部門全体まで、さまざまな単位を指します。このアプローチについて説明する際、最も一般的なケースであるため、チームという用語を使用します。チームの API アクセスを制限し監視するために、API キーを使用します。各チームには 基盤モデル へのアクセス用の API キーが割り当てられます。組織内には、さまざまなユーザー認証および承認メカニズムが導入されている場合があります。簡略化のため、このソリューションではこれらは扱っていません。既存の ID プロバイダーをこのソリューションと統合することも可能です。 次の図は、ソリューションのアーキテクチャと主要コンポーネントを示しています。異なるコストセンターに割り当てられたチーム (テナント) は、API サービスを介して Amazon Bedrock 基盤モデル を利用します。チームごとの使用量とコストを追跡するために、このソリューションは、呼び出されたモデル、テキスト生成モデルのトークン数、マルチモーダルモデルの画像サイズなど、個々の呼び出しに関するデータを記録します。さらに、モデルごとの呼び出し回数とチームごとのコストを集計します。 AWS CDK を使用して、お客様のアカウントにこのソリューションをデプロイできます。AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK のコードは GitHub リポジトリ で入手できます。 以下のセクションでは、このソリューションの主要なコンポーネントについて詳しく説明します。 チーム別の基盤モデル利用状況の把握 各チームの基盤モデル使用状況を収集するワークフローは、以下のステップで構成されています (前述の図の番号に対応)： チームのアプリケーションは、 Amazon API Gateway に POST リクエストを送信し、 model_id クエリパラメータで呼び出すモデルを指定し、リクエストボディにユーザープロンプトを含めます。 API Gateway は、リクエストを AWS Lambda 関数 ( bedrock_invoke_model ) にルーティングします。この関数は、 Amazon CloudWatch でチームの使用情報をログに記録し、Amazon Bedrock モデルを呼び出す役割を担います。 Amazon Bedrock は、 AWS PrivateLink を利用した VPC エンドポイントを提供します。このソリューションでは、Lambda 関数は PrivateLink を使用して Amazon Bedrock にリクエストを送信し、アカウントの VPC と Amazon Bedrock サービスアカウント間のプライベート接続を確立します。PrivateLink の詳細については、 Use AWS PrivateLink to set up private access to Amazon Bedrock をご覧ください。 Amazon Bedrock の呼び出し後、 Amazon CloudTrail は CloudTrail イベント を生成します。 Amazon Bedrock の呼び出しが成功すると、Lambda 関数は呼び出されたモデルのタイプに応じて以下の情報をログに記録し、生成されたレスポンスをアプリケーションに返します： team_id – リクエストを発行するチームの一意の識別子 requestId – リクエストの一意の識別子 model_id – 呼び出すモデルの ID inputTokens – プロンプトとしてモデルに送信されたトークン数（テキスト生成および埋め込みモデル用） outputTokens – モデルによって生成される最大トークン数（テキスト生成モデル用） height – リクエストされた画像の高さ（マルチモーダルモデルおよびマルチモーダル埋め込みモデル用） width – リクエストされた画像の幅（マルチモーダルモデルのみ） steps – リクエストされたステップ数（ Stability AI モデル用） チームごとのコスト追跡 別のフローでは、使用状況情報を集約し、チームごとのオンデマンドコストを日次で計算して保存します。フローを分離することで、コストの追跡がモデル呼び出しフローのレイテンシーとスループットに影響を与えないようにしています。 ワークフローのステップは以下の通りです： Amazon EventBridge ルールが毎日 Lambda 関数 ( bedrock_cost_tracking ) をトリガーします。 Lambda 関数は前日の使用情報を CloudWatch から取得して関連するコストを計算し、 team_id と model_id で集計されたデータを CSV 形式で Amazon Simple Storage Service (Amazon S3) に保存します。 Amazon S3 に保存されたデータのクエリと可視化には、 S3 Select や Amazon Athena と Amazon QuickSight など、さまざまなオプションがあります。 チームごとの使用量の制御 使用プランは、1 つまたは複数のデプロイされた API にアクセスできるユーザーを指定し、オプションでリクエストのスロットリングを開始するためのターゲットリクエストレートを設定します。このプランは API キーを使用して、各キーに関連付けられた API にアクセスできる API クライアントを識別します。API Gateway の 使用プラン を使用して、事前に定義されたしきい値を超えるリクエストをスロットリングできます。また、 API キー とクォータ制限を使用して、指定された時間間隔内に各チームが発行できる API キーごとのリクエストの最大数を設定できます。これは、アカウントレベルでのみ割り当てられる Amazon Bedrock サービスクォータ に加えて設定できます。 前提条件 このソリューションをデプロイする前に、以下のものを準備してください： AWS アカウント 。AWS が初めての場合は、 AWS アカウントの作成 をご覧ください。 開発環境に以下をインストールしていること： AWS Command Line Interface (AWS CLI) Python 3 AWS CDK このソリューションで使用するリソースをデプロイするための AWS Identity and Access Management (IAM) 権限を持つ AWS CLI プロファイル が設定されていること。 AWS CDK スタックのデプロイ GitHub リポジトリの README ファイルの手順に従って、AWS CDK スタックを設定およびデプロイしてください。 このスタックは以下のリソースをデプロイします： プライベートネットワーク環境 (VPC、プライベートサブネット、セキュリティグループ) モデルアクセスを制御する IAM ロール 必要な Python モジュール用の Lambda レイヤー Lambda 関数 invoke_model Lambda 関数 list_foundation_models Lambda 関数 cost_tracking REST API (API Gateway) API Gateway 使用量プラン 使用量プランに関連付けられた API キー チームのオンボーディング 新しいチームにアクセス権を付与するには、以下の 2 つの方法があります。 API キーを異なるチーム間で共有し、API 呼び出し時に異なる team_id を指定してモデルの使用状況を追跡する、もしくは、 README の手順に従って、Amazon Bedrock リソースにアクセスするための専用の API キーを作成する、という方法です。 このスタックは以下のリソースをデプロイします： 先に作成した REST API に関連付けられた API Gateway 使用量プラン 新しいチーム用の使用量プランに関連付けられた API キー (API のスロットリングとバースト設定が予約済み) API Gateway のスロットリングとバースト設定の詳細については、 スループット向上のための API リクエストのスロットリング を参照してください。 スタックをデプロイすると、 team-2 の新しい API キーも作成されていることが確認できます。 モデルアクセス制御の設定 プラットフォーム管理者は、Lambda 関数 invoke_model に関連付けられた IAM ポリシーを編集することで、特定の基盤モデルへのアクセスを許可できます。 IAM アクセス許可は setup/stack_constructs/iam.py ファイルで定義されています。以下のコードをご覧ください： self.bedrock_policy = iam.Policy( scope=self, id=f"{self.id}_policy_bedrock", policy_name="BedrockPolicy", statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", ], resources=["*"], ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "bedrock:InvokeModel", "bedrock:ListFoundationModels", ], resources=[ "arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1", "arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1" ], ) ], ) … self.bedrock_policy.attach_to_role(self.lambda_role) サービスの呼び出し ソリューションをデプロイした後、コードから直接サービスを呼び出すことができます。以下は、POST リクエストを通じてテキスト生成のための invoke_model API を Python から使用した例です： api_key="abcd1234" model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2 } prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier } ) text = response.json()[0]["generated_text"] print(text) 出力: Amazon Bedrock is an internal technology platform developed by Amazon to run and operate many of their services and products. Some key things about Bedrock … (参考訳) Amazon Bedrock は、Amazon が多くのサービスや製品を稼働・運用するために開発した内部技術プラットフォームです。Bedrock に関する主なポイントは… 以下は、POST リクエストを通じてエンベディングを生成するために invoke_model API を使用した Python の別の例です。 model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model } ) text = response.json()[0]["embedding"] 出力: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422, 1.03125, 0.8515625, 0.16308594, 0.079589844, -0.033935547, 0.796875, -0.15429688, -0.29882812, -0.25585938, 0.45703125, 0.044921875, 0.34570312 … 基盤モデルへのアクセス拒否 以下は、POST リクエストを使用して invoke_model API でテキスト生成を行う Python の例で、アクセス拒否応答の場合の例です。 model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2 } prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier } ) print(response) print(response.text) &lt;Response [500]&gt; “Traceback (most recent call last):\n File \”/var/task/index.py\”, line 213, in lambda_handler\n response = _invoke_text(bedrock_client, model_id, body, model_kwargs)\n File \”/var/task/index.py\”, line 146, in _invoke_text\n raise e\n File \”/var/task/index.py\”, line 131, in _invoke_text\n response = bedrock_client.invoke_model(\n File \”/opt/python/botocore/client.py\”, line 535, in _api_call\n return self._make_api_call(operation_name, kwargs)\n File \”/opt/python/botocore/client.py\”, line 980, in _make_api_call\n raise error_class(parsed_response, operation_name)\nbotocore.errorfactory.AccessDeniedException: An error occurred (AccessDeniedException) when calling the InvokeModel operation: Your account is not authorized to invoke this API operation.\n ” コスト見積もりの例 オンデマンド料金で Amazon Bedrock モデルを呼び出す場合、総コストは入力コストと出力コストの合計として計算されます。 入力コストはモデルに送信される入力トークン数に基づき、出力コストは生成されるトークン数に基づいて計算されます。 料金は、入力トークン 1,000 個あたりと出力トークン 1,000 個あたりで設定されています。 詳細および具体的なモデル料金については、 Amazon Bedrock の料金 をご参照ください。 2 つのチーム (team1 と team2) が、このポストで紹介するソリューションを通じて Amazon Bedrock にアクセスする例を見てみましょう。 Amazon S3 に保存された 1 日分の使用量とコストデータを、次の表に示します。 input_tokens 列と output_tokens 列には、特定の日におけるモデルごと、チームごとのモデル呼び出しにおける入力トークンと出力トークンの合計が保存されます。 input_cost 列と output_cost 列には、モデルごとおよびチームごとの各コストが格納されます。これらは以下の計算式を使用して算出されます。 input_cost = input_token_count * model_pricing["input_cost"] / 1000 output_cost = output_token_count * model_pricing["output_cost"] / 1000 チーム ID モデル ID 入力トークン数 出力トークン数 呼び出し回数 入力コスト 出力コスト Team1 amazon.titan-tg1-large 24000 2473 1000 0.0072 0.00099 Team1 anthropic.claude-v2 2448 4800 24 0.02698 0.15686 Team2 amazon.titan-tg1-large 35000 52500 350 0.0105 0.021 Team2 ai21.j2-grande-instruct 4590 9000 45 0.05738 0.1125 Team2 anthropic.claude-v2 1080 4400 20 0.0119 0.14379 実践的なマルチテナントサーバーレス SaaS 環境の全体像 エンドツーエンドで機能するマルチテナントのサーバーレス SaaS 環境がどのようなものか見ていきましょう。以下は参考アーキテクチャの図です。 このアーキテクチャ図は、投稿の前半で示した前回のアーキテクチャ図を俯瞰したバージョンです。前回のアーキテクチャ図では、言及されたマイクロサービス (基盤モデルサービス) の 1 つの詳細を説明しました。この図は、基盤モデルサービス以外にも、機能的でスケーラブルなプラットフォームを実装するためには、マルチテナント SaaS プラットフォームに他のコンポーネントも必要であることを説明しています。 アーキテクチャの詳細について説明していきましょう。 テナントアプリケーション テナントアプリケーションは、環境と連携するフロントエンドアプリケーションです。 ここでは、複数のテナントが異なるローカル環境や AWS 環境からアクセスしている様子を示しています。フロントエンドアプリケーションは、新規テナントが自身で登録できる登録ページや、SaaS サービスレイヤーの管理者向けの管理コンソールを含むように拡張できます。テナントアプリケーションが SaaS 環境とのやり取りを必要とするカスタムロジックを実装する必要がある場合、アプリケーションアダプターマイクロサービスの仕様を実装することができます。例えば、SaaS 環境の認可仕様に従いながら、カスタムの認可ロジックを追加するようなシナリオが考えられます。 共有サービス 以下は共有サービスです: テナントとユーザー管理サービス – これらのサービスは、テナントの登録と管理を担当します。アプリケーションサービスとは分離され、すべてのテナントで共有される共通機能を提供します。 基盤モデルサービス – このマイクロサービスは、この投稿の冒頭で説明したソリューションアーキテクチャ図で示されており、API Gateway から Lambda 関数へのやり取りがこのマイクロサービスの範囲内で行われます。すべてのテナントは、このマイクロサービスを使用して、Anthropic、AI21、Cohere、Stability、Meta、Amazon からの基盤モデル、およびファインチューニングされたモデルを呼び出します。また、CloudWatch ログで使用状況を追跡するために必要な情報も収集します。 コスト追跡サービス – このサービスは、各テナントのコストと使用状況を追跡します。このマイクロサービスはスケジュールに従って実行され、CloudWatch ログをクエリして集計された使用状況の追跡と見積もりコストをデータストレージに出力します。コスト追跡サービスは、さらなるレポートや可視化を構築するように拡張できます。 アプリケーションアダプターサービス このサービスは、テナントが SaaS 環境にカスタムロジックを統合するために実装できる仕様と API のセットを提供します。必要なカスタム統合の程度に応じて、このコンポーネントはテナントにとってオプションとなります。 マルチテナントデータストア 共有サービスは、個々のテナントと DynamoDB アイテムを関連付けるテナントパーティショニングキーを持つ、単一の共有 Amazon DynamoDB テーブルなどのデータストアにデータを保存します。コスト追跡の共有サービスは、集計された使用量とコスト追跡データを Amazon S3 に出力します。ユースケースに応じて、アプリケーション固有のデータストアを設けることもできます。 マルチテナント SaaS 環境には、さらに多くのコンポーネントが含まれる可能性があります。詳細については、 AWS のサーバーレスサービスを利用したマルチテナント SaaS ソリューションの構築 を参照してください。 複数のデプロイメントモデルのサポート SaaS フレームワークは通常、プールとサイロの 2 つのデプロイメントモデルを定義しています。プールモデルでは、すべてのテナントが共有ストレージと共有コンピューティングインフラストラクチャを持つ共有環境から基盤モデルにアクセスします。サイロモデルでは、各テナントが専用のリソースセットを持ちます。分離モデルについては、 SaaS テナント分離戦略ホワイトペーパー をご参照ください。 提案されたソリューションは、両方の SaaS デプロイメントモデルに採用できます。プールアプローチでは、集中管理された AWS 環境が API、ストレージ、およびコンピューティングリソースをホストします。サイロモデルでは、各チームが専用の AWS 環境内の API、ストレージ、およびコンピューティングリソースにアクセスします。 このソリューションは、Amazon Bedrock が提供する利用プランにも対応しています。 AWS では、推論用に 2 つの利用プランを選択できます： On-Demand – このモードでは、利用期間にコミットメントせずに、従量課金ベースで基盤モデルを利用できます Provisioned Throughput – このモードでは、利用期間にコミットメントすることで、アプリケーションのパフォーマンス要件を満たすのに十分なスループットをプロビジョニングできます これらのオプションの詳細については、 Amazon Bedrock の料金 をご参照ください。 この記事で説明するサーバーレス SaaS リファレンスソリューションでは、Amazon Bedrock の利用プランを適用して、エンドユーザーにベーシックとプレミアムの階層オプションを提供できます。 ベーシックプランには、Amazon Bedrock のオンデマンドまたはプロビジョンドスループット消費が含まれ、特定の使用量と予算の制限を設定できます。テナントの制限は、リクエスト数、トークンサイズ、または予算配分に基づいてリクエストを制御することで実現できます。プレミアムティアのテナントは、Amazon Bedrock のプロビジョンドスループット消費による専用リソースを持つことができます。これらのテナントは通常、高スループットと低レイテンシーでの Amazon Bedrock 基盤モデルへのアクセスを必要とする本番環境のワークロードに関連付けられます。 まとめ この投稿では、マルチテナント環境で Amazon Bedrock を使用して基盤モデルにアクセスする社内 SaaS プラットフォームの構築方法について説明しました。その際、各テナントのコストと使用状況の追跡、およびスロットリング制限に焦点を当てました。さらに探求すべきトピックとしては、組織内の既存の認証・認可ソリューションの統合、双方向のクライアントサーバー通信のための WebSocket を含む API 層の強化、コンテンツフィルタリングやその他のガバナンスガードレールの追加、複数のデプロイ層の設計、SaaS アーキテクチャにおける他のマイクロサービスの統合などがあります。 このソリューションのコード全体は、 GitHub リポジトリ で入手できます。 SaaS ジャーニーフレームワークの詳細については、 SaaS Journey Framework: Building a New SaaS Solution on AWS を参照してください。 翻訳はソリューションアーキテクトの福本が担当しました。 著者について Hasan Poonawala は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトとして、ヘルスケアおよびライフサイエンスのお客様を担当しています。 Hasan は、AWS 上での生成 AI および機械学習アプリケーションの設計、デプロイ、スケーリングを支援しています。 クラウドにおける機械学習、ソフトウェア開発、データサイエンスの分野で 15 年以上の実務経験を持っています。 余暇には、自然を探索したり、友人や家族と時間を過ごすことを楽しんでいます。 Anastasia Tzeveleka は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。 EMEA 地域のお客様が AWS サービスを使用してファンデーションモデルを構築し、スケーラブルな生成 AI および機械学習ソリューションを作成するお手伝いをしています。 Bru no Pistone は、ミラノを拠点とする AWS の生成 AI および ML スペシャリストソリューションアーキテクトです。 大規模な顧客と協力して、技術的なニーズを深く理解し、AWS クラウドと Amazon Machine Learning スタックを最大限に活用する AI および機械学習ソリューションの設計を支援しています。 専門分野は、機械学習の一連のプロセス、機械学習の実用化、生成 AI です。 友人と時間を過ごしたり、新しい場所を探索したり、旅行を楽しんでいます。 Vikesh Pandey は、金融サービスを専門とする生成系 AI/ML ソリューションアーキテクトで、金融系のお客様が数百から数千人規模のユーザーに対応できる生成系 AI/ML プラットフォームとソリューションの構築とスケーリングを支援しています。 余暇には、さまざまなブログフォーラムで記事を書いたり、子供と一緒に LEGO を組み立てたりして過ごしています。

本稿は、2023 年 6 月 23 日に AWS Cloud Enterprise Strategy Blog で公開された “ Should You Prioritize? ” を翻訳したものです。 ときどき、ある考えが常識として染み付いてしまっており、私たちの行動すべてに組み込まれている前提となっていることがあります。会議で誰かが「優先順位をつける必要がある」と言ったり、「これは優先事項ですか？」と言ったりなどです。何かがうまくいかないとき、それは優先順位をつけなかったせいにされるかもしれません。IT チームが、ビジネスが要求するすべての仕事に対応できないとき、ビジネスリーダーには優先順位をつけるよう求められます。優先順位という言葉は、ハイレベルなもの （会社の戦略的優先順位を決めなければならない） から、粗い粒度の戦術的なもの （投資に優先順位をつけなければならない） 、細かい粒度のもの （優先順位に基づいてバックログを整備しなければならない） まで、さまざまな議論の中で定着しています。 優先順位をつけることが誰にとっても難しいように思えるのは、何か不自然なところがあるからなのでしょう。 問題のひとつは、優先順位という言葉の意味が変わってしまったことです。14 世紀にラテン語の prior を元にした古フランス語の priorite から作られた最初の造語では、「（他の何かより） 早い状態」を意味していました。つまり、重要性ではなく時間を指していたのです。1900 年代に入ってから、直ちに注意を要するという意味を持つようになりました。[1] priorities という複数形は、最近になって英語に加わったものです。これは 1900 年代に作られた造語で、1940 年代まではほとんど使われていませんでした。それまでは、最も重要なことは 1 つしかないのだから、優先順位は 1 つしかないことは明らかだったのです。prioritize という動詞が生まれたのは最近のことであり、1972 年の大統領選挙の頃に、政治的な演説の一部として初めて使われました。 私たちの多くは本能的に、優先順位とは企業にとって最も重要な事柄の集合であると定義していますが、実のところ、今日この言葉をそのように使うことはほとんどありません。その意味は、私たちが認めたがらない形で再び変化しています。 今日における優先順位付けの本当の意味 奇妙なことに、今日私たちは優先順位付けを、やる仕事とやらない仕事を分けるために使っています。新しい仕事が提案されると、誰かが 「それは本当に優先順位が高いのか？」と尋ねるでしょう。それは、優先順位が高くないなら、やるべきではないというのが前提があります。優先順位とは、もはや他のことに先立ってやらなければならないことでも、最も重要なことでもありません。だから複数形が必要になっているのです。複数の優先順位がなければ、やるべきことはひとつしかないのです！ 今日の用法では、優先順位とは、組織のランク付けされたすべてのニーズのサブセットとなっています。優先順位を付ける、とは、潜在的な仕事や投資のリストを作り、それらを重要度の高い順に並べ、その中から上位 3 つ、 6 つ、あるいは 12 個を取り出し、優先順位のラベルを付けることです。それらが、その企業が投資する対象となるものです。 なぜ、このように意味が変わってきたのでしょうか？ それは、経営者やリーダーが絶え間なく経費削減を求められそれを証明する必要のある環境の中に住んでいることが関係しているでしょう。優先事項、つまり 「やらなければならないこと」だけに投資すること以上に、支出を少なくする方法はないのです。その起源はどうであれ、この変化は、優先事項が「すべてやるつもり」リストになるというダイナミズムを生み出したのです。奇妙な感じがしますよね？ 私は最近、2 社の戦略計画を見直しました。そのうちの 1 社は、11 の優先事項を挙げていました。なぜそんなに多いのでしょうか？ それは、事業を運営するために必要なことをすべて盛り込もうとしているからです。2 社目の戦略計画には 4 つの優先事項しかありませんでしたが、どれも漠然としたもので、「卓越した運用を追求する」とか 「顧客のために成果を出す」といった内容でした。優先順位はすべてを含むように意図されており、彼らが選択したものはすべて、形式化された優先順位にマッピングできるようになっていました。 これらの「優先順位付け」は、優先順位について何も伝えていないというのが実際のところです。 優先順位付けの重要な（奇妙な）前提1：固定されたキャパシティ 優先順位付けの中心的な前提は、私たちは固定されたキャパシティで仕事をしているということです。私たちができることには限界があるため、優先順位をつけなければなりません。おそらく、優先順位付けの候補リストには、良いリターンが期待できる投資だけが含まれているはずです （そうでなければ候補にはなりません）。優先順位付けの考え方には、機会費用が発生する可能性を残しておこうという意図が組み込まれています （訳者注：機会費用とは、ある生産要素を特定の用途に利用する場合に、それを別の用途に利用したならば得られたであろう利益の最大金額をさし、実際の生産額の費用とする概念[2]）。リターン獲得のために利用可能な機会に基づいてキャパシティが設定されるのではなく、キャパシティが　（どうにかして）　設定され、そこから利用可能な機会が導き出されるのです。 IT 部門は長い間、この仮説に悩まされてきました。 IT 部門は、企業全体のサービスに対する需要を募ったり、受け入れたりすることで、優先順位をつけるために要求された仕事のリストを作成します。この需要は常に IT 部門のキャパシティを超えるため、 IT 部門は全部の中から一部を選択しなければなりません。断る仕事の中には、会社の利益になる仕事も含まれているため、組織 （訳者注： ITにリクエストを出すビジネス部門のこと） の一部を不愉快にさせ、 IT 部門が反応が遅くて鈍いという印象を与えることは間違いありません。 ビジネス部門の人々は、良いアイデアをたくさん持っている傾向があります。もし、キャパシティには限りがあり、優先順位をつけなければならないと言われれば、優先順位が高いものしか扱われないとわかっているため、すべて良いアイデアなのですべての優先順位が高いと宣言するのは自然なことです。もし優先事項だけで実行可否が決定されるのであれば、付加価値を生むアイデアはすべて 「優先事項」になってしまうでしょう。 実際、組織には、優先事項でなくてもやらなければならないことがたくさんあります。特に IT の世界では、会社を運営し続けるにはかなりの帯域幅 （訳者注：キャパシティと同義）　が必要です。仕事を「優先事項」に限定すると、デス・スパイラルが始まり、会社の運営にリスクが加わり始めます。優先順位をつける行為自体が無駄を増やしていくのです。技術者ならこの比喩の意味がわかるかもしれません。コンピュータのメモリが少なすぎると、結局 CPU はアプリケーションをメモリに出し入れするのに時間を費やしてしまい、無駄に消費されてしまいます。 IT 部門は、創造に費やせるはずの労力を需要管理とガバナンスに費やすことになります。 キャパシティに基づいて仕事を絞り込まなければならないという考えは、私たちが平衡状態にないことを意味しています。私達が価値を生み出すことができないのであれば、受け入れるキャパシティを増やす必要があります。あるいは、優先順位付けの候補を特定する方法に何か問題があるのかもしれません。企業は制限されたキャパシティで働くべきだという考え方は、キャッシュ・マネジメントとの類似から来るものかもしれません。企業は一定額のキャッシュしか持っていないので、利用可能なキャッシュでしか投資を行うことができません。しかし、それは短期的な話であり、企業の成長計画はキャッシュ・ニーズへの対応が不可欠です。経営がうまくいっている企業では、資金の制約がビジネス価値を損なうことはありません。 IT リソースに恒久的な制約を課すことは、どういうわけかそれとは違うように思われるのです。 いずれにせよ、 IT 部門は優先事項だけでなく、企業が必要とするすべてのことに責任を持たなければなりません。 優先順位付けの重要な（奇妙な）前提2：既知の機会 優先順位付けの２つ目の前提は、与えられた投資機会のリストについて意思決定を行うことです。私たちは、「優先順位付けの候補となる以下のリストの中で、どのように順位付けをすべきか、また、どのリストに取り組むべきかの境界線をどこに引くべきか？」と問います。しかし、目まぐるしく変化する今日の不確実な環境では、私たちは常に新たな機会や課題に遭遇し、潜在的な投資案件の重要度が上がったり下がったりしています。 スクラムのようなアジャイルフレームワークは、作業のバックログを作成し、それを頻繁に優先順位を変更し、または洗練することによって、こうした変化を管理しようとしています。しかし、おそらくこれは優先順位付けとプロジェクト管理を混同しています。（議論の余地はあるものの）スクラムは組織的な優先順位から逆算するのではなく、要求抽出のプロセスを通じて与えられた、粒度の細かい個々の作業項目を調整しています。スクラムは本質的に、優先順位付けとはランク付けとサブセット化を意味するという考えを形式化したものです。もちろん、バックログを整理し、優先順位を付け直すことはできますが、バーンダウンチャート （訳者注：プロジェクトの進捗状況を可視化したもので残りの作業量を把握することができる）　を有用なものにするためには、多かれ少なかれ、前もって事前に作業を把握しておく必要があります。追加することはできますが、それに必ず他の作業への影響があります。 ここで想定されるメンタルモデルは、それぞれ独自のニーズを持つしたサイロ化された事業単位であり、中央にある IT 組織によってランク付けされなければならない、というものです。各サイロは独自の優先順位があり、中央の IT 組織は 「中央」であるがゆえに異なる優先順位を持っています。この状況は、競合する優先順位の枠組みが生み出され、勝者と敗者を選別しなければなくなります。予想通り、 IT は「ビジネス」と「より整合性のある」ものになるべきだという声が絶えません。 優先順位付けの重要な（奇妙な）前提3：厳格な方法論 3つ目の前提は、多種多様な投資を合理的に順位付けする方法があるはず、それはおそらく投資収益率 (ROI) である、ということです。しかし、拙著『 The Art of Business Value 』で論じたように、 ROI はこの目的を効果的に果たすものではありません。 ROI に基づく IT 作業の優先順位付けは、ビジネススクールの教授だった方々には申し訳ないのですが、価値を破壊することになります。私は、ESGの重要性が増すにつれて、このことをさらに確信するようになりました。ステークホルダーは、必ずしも ROI を最大化しないものにも価値を見出すことが多いのです。 優先順位を分けて考える この混乱を解きほぐす第一歩は、戦略、優先順位、仕事量管理の概念を分けることです。戦略とは、優先順位のリストではなく、リーダーが自社の市場に対する独自のアプローチを推進するために決定する、一連の原則です。どんな瞬間にも、優先順位は 1 つであるべきです。それは、戦略を実行するにあたり、リーダーが従業員に集中して取り組んでほしいと思える事がその時々の優先事項なのです。しかし、優先事項 （単数）は、会社が実行する必要のある仕事すべてではありません。実行は高帯域幅で多くのことを並行して行う必要があります。今日、私たちは従業員を自律的なチームに編成し、それぞれの領域に対して完全なオーナーシップを持つようにしています （「自分たちが構築したものを自分たちで実行する」）。これは、活動を並行して行うための優れた組織構造になります。 この3つのコンセプトはそれぞれ異なりますが、連続した全体の一部になります。仕事量管理に対する異なるアプローチは、経営陣が戦略を打ち出すことから始まり、その戦略を達成するための仕事に直接移行します。優先順位付けが必要な、組織全体から募ったイニシアティブのリストは存在しないのです。イニシアティブは、ハイレベルの戦略から有機的に導かれます。また、優先されるのは最初に実行されるイニシアティブです。戦略上の必須事項が成長である場合、望ましい成長をもたらす可能性が最も高いイニシアティブが追求されます。これは、他のイニシアティブが推進されないという意味ではなく、リソースの競合がある場合に戦略的なイニシアティブが優先されるというだけなのです。 これは、優先順位の設定について私が常に耳にしている雑談に基づいた考えにすぎません。参考になれば幸いです。 -Mark [1] Online Etymology Dictionary https://www.etymonline.com/search?q=priority [2]　機会費用 コトバンク Mark Schwartz マーク・シュワルツは、アマゾンウェブサービスのエンタープライズストラテジストであり、『 The Art of Business Value and A Seat at the Table：IT Leadership in the Age of Agility 』の著者です。 AWS に入社する前は、米国市民権・移民業務局 (国土安全保障省の一部) の CIO、Intrax の CIO、および Auctiva の CEO を務めていました。 彼はウォートン大学で MBA を取得し、イェール大学でコンピューターサイエンスの理学士号を取得し、イェール大学で哲学の修士号を取得しています。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。

本記事は Senior Manager-Product の Arvind Mahesh、Senior Technical Program Manager の Kuldeep Yadav、Senior Principal Solutions Architect の Jon Handler により執筆された投稿の日本語版です。原文は こちら よりご確認いただけます。 Amazon OpenSearch Service は、19 のオープンソース Elasticsearch バージョンと、11 の OpenSearch バージョンをサポートしています。AWS は長年にわたり、新しいエンジンバージョンにおいて安定性、回復力、セキュリティを強化することで、お客様が OpenSearch Service からより大きな価値を得られるよう努めてきました。ソフトウェアのバージョンが古くなるにつれ、これらのバージョンが高いセキュリティと法令遵守の基準を満たし続けることを確実にする必要があります。Elasticsearch バージョン 1.5 や 2.3 などの OpenSearch Service でサポートされている多くのレガシーバージョンは、もはや積極的にサポートされていないサードパーティライブラリに依存しています。最新のエンジンバージョンに移行することで、お客様は新機能、改善されたコストパフォーマンス、そして OpenSearch に対する当社のセキュリティ改善から最大限の恩恵を得ることができます。 本日、Amazon OpenSearch Service で利用可能な以下のバージョンについて、標準サポートと延長サポートの終了時期を発表します。 Elasticsearch 6.7 およびそれ以前のバージョン Elasticsearch 7.1 から 7.8 OpenSearch 1.0 から 1.2 OpenSearch 2.3 から 2.9 標準サポート期間内のバージョンについては定期的なバグ修正とセキュリティ修正を、延長サポート期間内のバージョンについては追加の定額料金&nbsp; (正規化されたインスタンス時間) を支払うことで重要なセキュリティ修正とオペレーティングシステムのパッチが提供されます。延長サポートにより、利用者がより新しいエンジンバージョンへのアップグレードを計画している間に、重要なセキュリティ修正を、十分な期間利用できることを目指します。延長サポートの詳細については、 よくある質問 &nbsp;をご覧ください。 Elasticsearch における各バージョンの標準サポートと延長サポートの終了時期 OpenSearch Service で利用可能な Elasticsearch の各バージョンにおける標準サポートと延長サポートの終了日については、以下の表をご覧ください。該当する Elasticsearch のバージョンを使用しているお客様には、最新の OpenSearch バージョンへのアップグレードをお勧めします。すべての Elasticsearch バージョンは少なくとも 12 ヶ月の延長サポートが提供されます。またバージョン 5.6 においては、最長で 36 ヶ月まで延長サポートが提供されます。延長サポートが終了すると、対象のバージョンを実行しているドメインに対しては、バグ修正やセキュリティアップデートの提供が行われなくなります。 ソフトウェアバージョン 標準サポート終了日 延長サポート終了日 Elasticsearch 1.5, 2.3 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 5.1 から 5.5 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 5.6 2025 年 11 月 7 日 2028 年 11 月 7 日 Elasticsearch 6.0 から 6.7 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 6.8 未定 未定 Elasticsearch 7.1 から 7.8 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 7.9 未定 未定 Elasticsearch 7.10 未定 未定 OpenSearch における標準サポートと延長サポートの終了時期 Amazon OpenSearch Service で実行される OpenSearch については、対応するアップストリームのオープンソースの OpenSearch バージョンのサポート終了日から、少なくとも 12 ヶ月の標準サポート、または OpenSearch Service における次期マイナーバージョンのリリースから 12 ヶ月の標準サポートの、いずれか長い方が提供されます。すべての OpenSearch バージョンに対して、標準サポート終了日から少なくとも 12 ヶ月の延長サポートが提供されます。詳細については、オープンソース OpenSearch の メンテナンスポリシー をご確認ください。 OpenSearch Service で利用可能な OpenSearch の各バージョンごとの標準サポートおよび延長サポートの終了日については、以下の表をご覧ください。バージョンごとの標準サポートおよび延長サポートに関する今後のアップデートについては、 サポートバージョン のページよりご確認ください。 ソフトウェアバージョン 標準サポート終了日 延長サポート終了日 OpenSearch 1.0 から 1.2 2025 年 11 月 7 日 2026 年 11 月 7 日 OpenSearch 1.3 未定 未定 OpenSearch versions 2.3 から 2.9 2025 年 11 月 7 日 2026 年 11 月 7 日 OpenSearch 2.11 およびそれ以降のバージョン 未定 未定 OpenSearch Service ドメインのアップグレード : OpenSearch Service から最大限の価値を得るために、OpenSearch ドメインを最新の バージョンにアップグレードすることをお勧めします。OpenSearch のマイナーバージョンアップグレードは、互換性を破壊する変更を含まないため、通常はシームレスに実行可能です。最新のマイナーバージョン、またはサポート終了がまだ発表されていないバージョンへの移行をお勧めします。例えば、OpenSearch バージョン 1.2 を使用している場合、1.x 系の最後のマイナーバージョンであり、現在もオープンソースコミュニティと AWS によってサポートされている OpenSearch バージョン 1.3 に移行できます。Elasticsearch バージョンを選択する場合で、以前の 6.x または 7.x バージョンを実行している場合は、バージョン 6.8 または 7.10 に移行できます。 クラスターを新しいバージョンにアップグレードする方法は複数あり、手順はドメインが実行しているバージョンとアップグレード先のバージョンによって異なります。ドメインを新しいバージョンにアップグレードする詳細な手順については、 OpenSearch Service ドメインのアップグレード をご覧ください。また、新しいバージョンへのアップグレードには Amazon OpenSearch Service 用の移行アシスタント も利用可能です。 延長サポート料金の計算 : 延長サポート中のバージョンを実行しているドメインには、正規化されたインスタンス時間 (Normalized Instance Hour = NIH) あたりの定額追加料金が課金されます。例えば、米国東部 (バージニア北部) AWS リージョンでは、0.0065 ドル/NIH の料金が発生します。リージョンごとの正確な料金については、 料金ページ をご覧ください。 NIH は、インスタンスサイズ (例：medium、large) とインスタンス時間数の要素として計算されます。例えば、米国東部 (バージニア北部) リージョンで、m7g.medium.searchインスタンスを 24 時間実行している場合、通常はインスタンス時間あたり 0.068 ドル (オンデマンド) で、1.632 ドル (0.068×24) を支払います。延長サポート中のバージョンを実行している場合、NIH あたり 0.0065 ドルの追加料金が発生し、これは 0.0065 × 24 (インスタンス時間数) × 2 (medium サイズインスタンスのサイズ正規化係数は2) として計算され、24 時間の延長サポートで 0.312 ドルとなります。24 時間の総額は、標準インスタンス使用料と延長サポート料の合計で、1.944 ドル (1.632 + 0.312 、ストレージコストを除く) となります。以下の表は、OpenSearch Service の各インスタンスサイズの正規化係数を示しています。 インスタンスサイズ 正規化係数 nano 0.25 micro 0.5 small 1 medium 2 large 4 xlarge 8 2xlarge 16 4xlarge 32 8xlarge 64 9xlarge 72 10xlarge 80 12xlarge 96 16xlarge 128 18xlarge 144 24xlarge 192 32xlarge 256 まとめ 最新の OpenSearch バージョンには、新機能、パフォーマンスと回復力の改善、セキュリティの改善など、様々な新しい機能を追加しています。OpenSearch Service から最大限の恩恵を得るため、最新の OpenSearch バージョンへの更新をお勧めします。標準サポートと延長サポートのオプションに関する質問については、 よくある質問 &nbsp;をご覧ください。その他の質問については、 AWS サポート にお問い合わせください。 著者について Arvind Mahesh は&nbsp;Amazon OpenSearch Service のシニアプロダクトマネージャーです。分析、検索、クラウド、ネットワークセキュリティ、通信など、様々な分野で約20年間の技術経験を持っています。 Kuldeep Yadav は、イノベーションの推進と複雑な問題解決に情熱を注いでいる Amazon Web Services のシニアテクニカルプログラムマネージャーです。チームや顧客と密接に協力して、運用の優位性を確保し、より少ないリソースでより多くの成果を上げることに取り組んでいます。仕事以外では、トレッキングといったあらゆるスポーツを楽しんでいます。 Jon Handler &nbsp;は、カリフォルニア州パロアルトを拠点とする Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。OpenSearch と Amazon OpenSearch Service に深く携わり、検索やログ分析のワークロードを AWS クラウドに移行したいと考える顧客に対して、幅広くサポートとガイダンスを提供しています。AWS 入社以前は、ソフトウェア開発者としてのキャリアの中で、大規模な e コマース検索エンジンの実装に 4 年間従事していました。ペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピュータサイエンスと人工知能の理学修士号と博士号を取得しています。

※ 本ブログは、株式会社ペライチとAmazon Web Services Japan が共同で執筆いたしました。 ペライチとは、株式会社ペライチが運営するホームページ作成サービスです。EC サイトやセミナー、ランディングページといった利用目的にあわせて数百種類のテンプレートからお好みのデザインを選び、テキストや画像を入力するだけでイメージに近いホームページを作成できます。 個人事業主から大企業まで、誰でも簡単にホームページを作って運用できるように、ペライチは豊富なテンプレートを用意しています。ホームページ制作経験がない方でも直感的に操作できるよう、プロダクトを拡大し続けてきました。しかし、初めてホームページを作成される方にとっては、頭の中でイメージしたレイアウトやデザインをホームページの形に落とし込むことが難しく、公開まで至らないユーザーが存在する課題が浮き彫りになっていました。 こうしたお客様の課題を解決するため、AIの力を活用してより簡単にホームページを作成できる「ペライチクリエイトアシスタント」を開発しました。この機能では、ユーザーが任意のサイトのURLを入力するだけで、そのサイトの特徴や用途に応じた情報を生成AIが抽出し、それに基づいた最適なテンプレートでサンプルのホームページを提案します。 この記事ではそもそもプロダクトの課題をどのように抽出したか、プロダクトの課題に対して生成 AI に限らずどのようなアプローチを検討したか、生成 AI を活用した機能をどのように実装したかをお伝えします。 アプローチの検討 ペライチは AWS ジャパン生成 AI 実用化推進プログラム に参加しました。このプログラムでは、ビジネス価値に繋がるユースケースの発見とその実装のサポートを提供します。生成AIに関する技術的なガイダンスやビジネス支援により３ヶ月程度でお客様のプロダクトに生成AI機能を実装できるように支援します。期間内でのプロダクト実装を条件に a) 生成 AI 活用事例のインプットと事例化されたユースケースをベースにしたビジネスモデルの作成支援、b) 構築済みサンプルアプリケーション を使ったハンズオン、c) PoC 用AWS クレジットといった支援を AWS から受けることができます。ユースケースの検討では ‍AWS で提供実績がありかつ評価が高いワークショップ‍を実施し、プログラムに参加する他社と交流する機会があるなど短い期間で密度の濃い経験をすることができました。 ワークショップでは現状の顧客 (エンドユーザー) の課題、ビジネス (ペライチ) の課題、それらを解決するユースケース、解決の度合いを測る KPI 、 KPI 改善までのマイルストンを整理して一つのドキュメント (=企画書) にまとめます。この企画書にまとめる作業にはペライチの PdM とエンジニアの他に AWS アカウントチームのアカウントマネージャーとソリューションアーキテクト、生成 AI 実用化推進プログラムの運営メンバーが参加し最終的にユーザー観点、ビジネス観点、それぞれ踏まえた上での課題を整理することができました。 ペライチでは「誰でも簡単に初期費用無料で、600 種類以上のテンプレートから選んで編集するだけでページを作成・公開できる」サービスを提供してきました。その上でワークショップの議論の結果、「そもそもどのテンプレートを選べばよいか分からない」「いまあるページをイチから作り直すのはハードルが高い」ユーザー観点の課題があり、従来はペライチのカスタマーサポートのメンバーなどがテンプレートの選択やデザインパーツの選択、素材の移行などでサポートしてきたが人的リソースに限界があるビジネス観点の課題があると整理することができました。 今回はこれらの課題に対して、入力情報としてサイトの URL 情報を与えそこからユーザーのビジネスや商材、ユースケースなどの情報を AI で抽出・要約し、それらの情報を元にしてペライチの既存テンプレートを組み合わせてページを生成することを試みました。「ユーザーが持つ古いページを作り直すケース」や「ユーザーが持つ既存の EC 販売サイトとは別に独自の EC サイトを立ち上げたい」などといったユースケースを想定しています。インプット情報を少なくし、そこから AI を用いてペライチのサービス側でユーザーに必要な情報を抽出・推論することで、今まで人間がサポートしていた部分を一部生成 AI によって置き換えて、ユーザーの制作コストやリードタイムを削減しようとしています。 実装 ペライチは AWS の プロトタイピングプログラム を有効活用しました。これは、AWS の知識や経験が豊富なプロトタイピングエンジニアが、お客さまに代わってシステムのプロトタイプを開発するというプログラムです。 今回実装する全体的な処理は「前処理 : URL から Web ページの情報を取得し、内容を説明・要約・抽出する」と「後処理：前処理で抽出された情報を元にペライチが持つテンプレートを選択・文章を生成・画像やページの配色などを選びページを生成する」の 2 つのステップに分かれています。生成 AI を活用した前処理に焦点を当てると、入力された URL 情報から WEB ページの情報の抽出・説明・要約する処理をプロトタイピングプログラムの支援を受けてAWS Step Functions と AWS Lambda そしてAmazon Bedrock を活用して実装していただきました。 利用者とペライチの皆様からの声 ペライチは 2024 年 8 月5 日より、 無料モニターを受け付けています 。 無料モニターに参加した利用者からは「 URL を入力するだけでイメージに近いページが簡単に生成できてよかった」「自社が保有している既存のページのリプレイスが簡単にできそう」というフィードバックをいただきました。 また、ペライチの藤代様からは「サービスの設計、LLMのモデル選定、実装など幅広くご支援いただき助かりました」「現在はモニターからの声を集めながらサービス改善に努めており、他サービスにも似た仕組みを適用できないか試しています」といった声をいただきました。 まとめ Amazon Bedrock によりWEBサイトの構築において今まで人間がサポートしていた部分を一部生成 AI によって置き換えて、ユーザーの制作コストやリードタイムを削減するシステムを構築することができました。 ペライチでは今後もAWSのサービスを活用しながら、更なる価値提供を実現しようと考えています。 著者について 苅野 秀和(Hidekazu Karino) 飛行機の勉強をしていたのが気づいたらなんやかんやあって AWS に入社してました。現在はウェブ系のお客様の技術支援を行いながら Rust を書いています。 週末は美味しいクロワッサンを求めてパン屋を探訪しています。

はじめに 2024 年 9 月に広島で地域経済の活性化に向けたデータコラボレーションワークショップを開催しました。本記事では、本ワークショップの開催背景と当日の内容をご紹介いたします。 近年、データは新たな価値創造の源泉として注目されています。しかし、単一企業のデータだけでは、その潜在的な可能性を最大限に引き出すことは困難です。そこで重要となるのが、企業間のデータコラボレーションです。多様な産業が集積する広島では、各企業が保有するデータの連携により、新たなビジネスチャンスや地域課題の解決が期待されています。この潮流の中、中国新聞社は「たるポ」という地域IDプラットフォームを構築し、地域に根ざした新たな価値提供を目指しています。しかし、データコラボレーションの実現には、セキュリティ懸念や異業種間でのデータ活用ノウハウの不足という課題がありました。 これらの課題に対応するため、中国新聞社と AWS は共同でワークショップを企画しました。ワークショップでは、「小売」「放送」「金融」といった業界から 4 社の代表者様にお集まりいただき、 AWS Clean Rooms を活用し、セキュリティとプライバシーを確保したデータコラボレーションのユースケースを議論しました。さらに、異業種間でのデータ活用案と、参加企業が具体的なアクションプランを策定できる場を提供することを目指しました。 開催概要 参加企業: 5 社 / 26 名 アジェンダは以下の通りです。 開会のご挨拶 / 参加企業ご紹介 たるポのご紹介 AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション Next Step のご案内 / 閉会のご挨拶 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、3つのグループに参加者が分かれ、実際にデータコラボレーションする際のユースケースについて議論を行いました。 データコラボレーションの基本 データコラボレーションとは 続いて、本ワークショップのメインテーマであるデータコラボレーションと、それを支える AWS のサービスについてご説明します。まず、データコラボレーションとは、複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、小売業とメディア企業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や新サービスの開発が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、データ保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。実際、多くのグローバル企業がデータコラボレーション強化を推進しており、日本においても今後のビジネス戦略において重要な役割を果たすことが予想されます。 AWS Clean Rooms とは データコラボレーションを支える AWS サービスが AWS Clean Rooms です。これは、組織間で生データを直接共有せずに安全にデータを分析するマネージドサービスです。主な特徴として、暗号化技術によるセキュアなデータ共有、SQL を用いた柔軟な分析環境、実行する SQL の制御機能、緻密なアクセス制御、大規模データセットに対するスケーラビリティがあります。このサービスにより、企業は自社データを保護しつつ、連携先企業とのデータコラボレーションを実現し、新たなビジネス機会を創出できます。 各セッションのハイライト たるポのご紹介 株式会社中国新聞社 メディア開発局 メディア開発部長 石井将文氏 中国新聞社 石井氏より、地域 ID プラットフォーム「たるポ」についてご紹介いただきました。たるポは、中国新聞社が長年培われてきたブランド力と信頼性を基盤とした、新たな地域 ID プラットフォームです。たるポは、地域で広く使われることを意識して構築され、顧客情報の質と地域の企業との柔軟な連携を重視しています。一般ユーザー向けには、1 つの ID で複数サービスへのログイン機能やポイントの一元化、e ギフトへの交換などを提供します。法人向けには、PR ソリューションや会員基盤の新規導入、ID 連携などを実現します。たるポは拡張性のある仕組みで、現在複数のサービスと ID 連携しています。今後は「会員増」と「連携サービス増」を同時に達成し、地域のエコシステムとして、広島エリアでの事業拡大を考えている企業との連携や、B2B での利活用を視野に入れていると語られました。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 本多和幸 アマゾン ウェブ サービス ジャパン 本多より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。上記でご紹介した AWS Clean Rooms の詳しいご説明と、AWS Clean Rooms の新機能で企業間で類似セグメントの作成を支援する AWS Clean Rooms ML 、名寄せのサービスである AWS Entity Resolution を中心にご説明しました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。参加企業の皆様に事前に各社のデータ資産をヒアリングし、実践的なユースケースを準備したことで、より深い議論が可能となりました。小売業界のテーブルでは、ポイントカードの活用や新規顧客獲得の戦略が話し合われ、非会員の購買行動分析や他業種とのデータ連携の可能性が探られました。放送業界のテーブルでは、会員データの活用やイベント集客データの取得に関する課題が共有され、特にスポーツチームのファンクラブアプリを通じたデータ活用に注目が集まりました。金融業界のテーブルでは、データのセキュリティを保ちつつ顧客理解を深める方法が議論されました。 お客様の声 本ワークショップは、広島地域におけるデータコラボレーションの可能性を探る貴重な機会となりました。参加企業の皆様からは、「他社とのデータ連携でできることや目指すことの具体的な議論ができたことは良かった」「セキュリティを担保しながらのデータ共有方法が理解できた」といった前向きな声を多数いただきました。ワークショップ後のアンケートでは、参加者の90%以上が本ワークショップに対してポジティブなフィードバックを頂き、データコラボレーションに対する高い期待が伺えます。 おわりに 本ワークショップを通じて、データコラボレーションの大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業の皆様、そして共催である中国新聞社の皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、ソリューションアーキテクト本多が担当しました。