Amazon Web Services ブログ

Category: Amazon OpenSearch Service

Amazon OpenSearch Service で長期ロギング費用を 4,800% 削減

サーバーログ、サービスログ、アプリケーションログ、クリックストリーム、イベントストリームなどの時間制限のあるデータに 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 に永続的に保存できる) に加わります。

Amazon OpenSearch Serverless によるあらゆる規模における費用対効果の高い検索機能

Amazon OpenSearch Serverless の今までより安価な新しいエントリーコストを発表できることを喜ばしく思います。
インデクシングと検索のワークロードに対して 0.5 OpenSearch Compute Unit (OCU) がサポートされたことで、エントリーコストが半分になりました。

Amazon OpenSearch Service が Elasticsearch および OpenSearch バージョンの標準・延長サポート期間を発表

Amazon OpenSearch Service は、19 のオープンソース Elasticsearch バージョンと、11 の OpenSearch バージョンをサポートしています。AWS は長年にわたり、新しいエンジンバージョンにおいて安定性、回復力、セキュリティを強化することで、お客様が OpenSearch Service からより大きな価値を得られるよう努めてきました。ソフトウェアのバージョンが古くなるにつれ、これらのバージョンが高いセキュリティと法令遵守の基準を満たし続けることを確実にする必要があります。Elasticsearch バージョン 1.5 や 2.3 などの OpenSearch Service でサポートされている多くのレガシーバージョンは、もはや積極的にサポートされていないサードパーティに依存しています。最新のエンジンバージョンに移行することで、お客様は新機能、改善されたコストパフォーマンス、そして OpenSearch に対する当社のセキュリティ改善から最大限の恩恵を得ることができます。

本日、Amazon OpenSearch Service で利用可能ないくつかのバージョンについて、標準サポートと延長サポートの終了時期を発表します。

Zstandard 圧縮による Amazon OpenSearch Service のストレージコスト最適化

Amazon OpenSearch Service は、AWS Cloud 上で OpenSearch クラスターを大規模にセキュアに展開、運用するのを簡単にするマネージドサービスです。OpenSearch Service ドメインでは、データはインデックスの形式で管理されます。使用パターンに基づいて、OpenSearch クラスターには 1 つ以上のインデックスがあり、そのシャードはクラスター内のデータノードに分散されています。各データノードには固定のディスクサイズがあり、ディスク使用量はノードに格納されているインデックスシャードの数に依存します。各インデックスシャードは、ドキュメント数に応じて異なるサイズを占める可能性があります。ドキュメント数に加えて、インデックスシャードのサイズを決定する重要な要因の 1 つは、インデックスに使用される圧縮アルゴリズムです。

Amazon Bedrock Agents と Amazon CloudWatch Logs を使用した、生成 AI によるクラウド運用ワークフローの実現

このブログ記事では、AWS のクラウド運用シナリオにおいて、アプリケーションログファイルで観察されたエラーに基づいて問題を分類し、その後解決するために、Amazon Bedrock エージェントと Bedrock の FM を使用した 生成 AI の使用例を紹介します。
我々のソリューションでは、Amazon Bedrock エージェントは基盤モデル (FM) の推論の性能を使用して、CloudWatch Logs に公開されたアプリケーションログについてのエラー解決を要求するユーザー指示を複数のステップに分解します。開発者/アナリストが提供した自然言語の指示を使用してオーケストレーション計画を作成し、その後、関連する API を呼び出し、Amazon Bedrock Knowledge Base にアクセスすることで計画を実行します。これには、大規模言語モデル (LLM) によって生成された応答を補強するために、ベクトルデータストア (Amazon OpenSearch Serverless) から情報を引き出す処理が含まれます。