Elastic Stack（ELKスタック）を導入する際、多くのエンジニアが最初に頭を悩ませるのが「データの収集・加工（前処理）に何を使うか」という問題です。 かつては「前処理といえばLogstash」の一択でしたが、Elasticsearchに  Ingest Pipeline  が実装されて以降、その手軽さとパフォーマンスから強力な選択肢となっています。 本記事では、LogstashとIngest Pipelineのアーキテクチャの違い、機能面での優劣、そして「結局どちらを選ぶべきか」の判断基準を技術者視点で解説します。 目次 1. LogstashとIngest Pipelineの概要 Logstash とは？ Ingest Pipeline とは？ 2. 4つの軸で見る決定的な違い ① 入出力の柔軟性（Inputs & Outputs） ② データの加工・拡充能力（Transformation） ③ 耐障害性とバッファリング（Queueing） ④ インフラ構成と運用コスト 3. 【結論】どちらを選ぶべきか？ ユースケース別の推奨 ✅ Ingest Pipeline を選ぶべきケース ✅ Logstash を選ぶべきケース 💡 比較サマリー 💡 ハイブリッド構成（併用）という選択肢も まとめ 1. LogstashとIngest Pipelineの概要 比較に入る前に、それぞれの立ち位置を簡単におさらいしておきましょう。 Logstash とは？ データ処理パイプラインを構築するための独立した外部サーバー（コンポーネント）です。豊富なプラグイン（Input / Filter / Output）を備え、多様なデータソースからデータを吸い上げ、複雑な加工を施した上で、Elasticsearchをはじめとする様々な宛先にデータを送信できます。 Ingest Pipeline とは？ Elasticsearchのクラスタ内部（Ingestノード）で動作する  前処理機能です。データがElasticsearchにインデックス（格納）される直前に、JSON形式のドキュメントに対して「プロセッサ」と呼ばれる処理を数珠つなぎに適用してデータを加工します。 2. 4つの軸で見る決定的な違い 2つのコンポーネントの特性を、「入出力」「データ加工能力」「耐障害性」「運用コスト」の4つの軸で比較します。 ① 入出力の柔軟性（Inputs & Outputs） Logstash: 圧倒的な柔軟性を持ちます。HTTPやSyslogなどのPush型だけでなく、リレーショナルデータベース（JDBC）やメッセージキュー（Kafka, RabbitMQ）からデータを自発的に取得（Pull）できます。また、加工したデータをElasticsearchに送りつつ、同時にS3へ生ログをアーカイブする、といった マルチ出力 が可能です。 Ingest Pipeline: あくまですべての処理が「Elasticsearchにデータが書き込まれるタイミング」で動作するため、外部へデータを読みに行くことはできません。Beatsやアプリケーションからデータを「Push」してもらう必要があります。また、出力先もパイプラインが動いているElasticsearch自身に限定されます。 ② データの加工・拡充能力（Transformation） Logstash: 条件分岐（if-else）のネストや、Rubyプラグインを用いたコードレベルでの柔軟な記述が可能です。また、処理中に外部のファイルやデータベースを参照してデータを補完（エンリッチ）する処理も得意です。 Ingest Pipeline: Grok、GeoIP、JSONなどの主要なプロセッサが標準搭載されており、一般的なログ（Apache, Nginx, システムログなど）のパースであれば十分すぎる性能を持っています。 enrich  プロセッサを使えばElasticsearch内の別インデックスを参照したデータ拡充も可能ですが、Logstashほど外部システムと密に連携した複雑な加工はできません。 ③ 耐障害性とバッファリング（Queueing） Logstash: 永続的キュー（Persistent Queues）を内蔵しています。Elasticsearch側が一時的なスパイクやメンテナンスでデータを受け付けなくなっても、Logstashがローカルディスクにデータを安全にバッファリングし、データロストを防ぎます。 Ingest Pipeline: 自身にデータを溜めるディスクキューはありません。Elasticsearchのインデキシング負荷が高くなると、データ送信元（Beatsなど）に対して「これ以上送らないでくれ」というバックプレッシャーをかけます。送信元がバッファを持っていない場合、データロストの追跡や再送管理を送信元側で担保する必要があります。 ④ インフラ構成と運用コスト Logstash: 独立したプロセス（JVM）として動くため、メモリやCPUの設計、パッチ当て、監視などの運用コストが上乗せされます。ただし、データ処理の負荷をElasticsearchクラスタから完全に分離できるというメリットもあります。 Ingest Pipeline: 新たにサーバーを構築する必要がありません。KibanaのUIやREST APIからJSON定義を投入するだけで即座にデプロイ・変更が可能です。運用は非常にシンプルになりますが、重いパース処理（複雑なGrokなど）が大量に走ると、Elasticsearch自体のリソース（検索やインデックス性能）を圧迫するリスクがあります。 3. 【結論】どちらを選ぶべきか？ ユースケース別の推奨 システム要件や現在の構成に合わせて、インフラエンジニアは以下の基準で選択することをお勧めします。 ✅ Ingest Pipeline を選ぶべきケース 「シンプルさ」と「スピード」を最優先する場合 データソースが  Elastic Agent  や  Beats  に統一されており、直接ElasticsearchにデータをPushできる。 ログの加工要件が、タイムスタンプの整形や不要フィールドの削除、シンプルなGrokパース程度である。 これ以上、管理対象のサーバーやコンポーネント（ミドルウェア）を増やしたくない。 ✅ Logstash を選ぶべきケース 「複雑なパイプライン」や「大規模・多様な環境」を管理する場合 データベース（SQL）やKafka、サードパーティのAPIなど、 多種多様な場所からデータをPullで収集 する必要がある。 受け取ったデータをElasticsearchだけでなく、 S3や別のオブジェクトストレージにも同時にバックアップ したい。 パース処理が非常に複雑で、Elasticsearchの検索・インデックス性能に影響を与えたくない（負荷を分離したい）。 データの突発的なスパイクに備え、堅牢なディスクバッファリング（永続的キュー）が必須である。 💡 比較サマリー 比較項目 Logstash Ingest Pipeline 配置・アーキテクチャ 独立した外部サーバー（JVM） Elasticsearchクラスタの内部（Ingestノード） 入力（データ収集） 自由度：高 （Pull型、Push型、各種DB、MQ対応） 自由度：低 （ElasticsearchへのPushのみ） 出力（データ送信） マルチ出力対応 （ES、S3、Kafka、ファイル等） Elasticsearch内部のみ キュー・バッファリング 内蔵（Persistent Queuesによるデータロスト防止） なし（送信元にバックプレッシャーをかける） 加工・拡充の複雑さ 非常に複雑なロジック、Rubyコード、外部DB参照 単一ドキュメント内の処理、簡単なクラスタ内ルックアップ インフラ管理負荷 高（追加のサーバー管理やチューニングが必要） 低（Elasticsearchの設定としてAPI管理可能） 推奨ユースケース 多種多様なソースからのデータ収集、マルチ出力、複雑なパース処理、負荷分離、高堅牢性が求められる大規模環境。 シンプルさとスピードを優先する場合。Beats/Agent利用時、標準的なログパース、管理コンポーネントを増やしたくない場合。 💡 ハイブリッド構成（併用）という選択肢も 「Logstashで多様なデータソースから収集・バッファリングを行い、Elasticsearchに転送した後の細かいパースはElasticのIntegration（標準のIngest Pipeline）に任せる」という  Logstash ➔ Ingest Pipeline  のハイブリッド構成も、大規模環境では一般的です。 まとめ 手軽さ、運用のしやすさ、標準的なログパース  ➔  Ingest Pipeline マルチ入出力、複雑なロジック、高堅牢性・バッファリング  ➔  Logstash 現代のElastic Stack構築における王道アプローチは、以下の2ステップです。 まずは運用の手軽な  Ingest Pipeline  で要件を満たせるか検討する。 入出力の制限やパースの複雑さ、インフラ分離の必要性が出てきた段階で  Logstash  の導入、あるいは併用へとステップアップする。 自社のインフラ規模やログの特性に合わせて、最適なデータパイプラインを選択しましょう！ The post Elasticのデータ前処理、どっちを選ぶ？ Logstash vs Ingest Pipeline 徹底比較 first appeared on Elastic Portal .

  Linux初心者がAzure仮想マシンでHTTPサーバーを構築した話 --> こんにちは！新卒でサイオステクノロジーに入社したごままぐろです。 本記事では、Linux初心者が研修で得た学びを以下の構成でご紹介します。LinuxはITパスポートなどの資格勉強で少し知っている程度だったのですが、この度新卒研修の一環としてLinux仮想環境でのサーバ構築を行いました。 これからLinuxを学ぶ方の参考になれば幸いです。 Linuxについて Linuxとは LinuxはWindowsやMacのようなOS（Operating System）の一種です。OSS（Open Source Software）として公開されているため、世界中の開発者が自由にプログラムの中身を確認したりカスタマイズできます。 厳密にいえば、「Linux」とはOSの核心である「カーネル」のことを指すようです。しかし実際には、カーネルに独自の管理ツールやアプリケーションを組み合わせた「Linuxディストリビューション」のことをLinuxと呼ぶことが多いそうです。 有名なLinuxディストリビューションには以下のものがあります。 RedHat系： RHEL、AlmaLinux など Debian系： Debian、Ubuntu など Linuxの特徴 Linuxには以下のような特徴があります。 基本的に文字ベースで操作する データをディレクトリとファイルの入れ子構造で管理する ユーザごとに権限を設定できる 私の場合、このあたりの特徴を掴むのに時間がかかりました。今も完全に理解できているか分からないのですが、私なりの言葉で簡単に説明したいと思います。 LPI-Japanという団体が初学者向けに 「Linux標準教科書」 という資料を公開しているので、正確な情報を知りたい方はそちらを参照してみてください。 １．基本的に文字ベースで操作する Linuxでは、キーボードで命令（コマンド）を入力するCUI（Character User Interface）での操作が基本です。 Linuxのコマンドは基本的に「コマンド」「オプション」「引数」で構成されます。 同じ操作でも、ディストリビューションによっては別のコマンドやオプションが存在する場合があるため、注意が必要です。 ２．データをディレクトリとファイルの入れ子構造で管理する Linuxでは、データはディレクトリとファイルの入れ子構造で管理されます。 ディレクトリはフォルダのようなもので、ファイルを整理するための入れ物です。ディレクトリの中にさらにディレクトリを作ることもでき、これを入れ子構造と呼びます。 ファイルを操作する時には、ファイルの住所（パス）を指定する必要があります。パスには、最上位（/ルートディレクトリ）からの絶対パスと、現在のディレクトリからの相対パスがあります。 絶対パス： /home/username/newdir/file1.txt 相対パス：(現在の位置が/home/usernameの場合) newdir/file1.txt ３．ユーザごとに権限を設定できる Linuxには「ユーザ」という概念があります。ユーザには、人がログインして操作を行うためのものの他に、人がログインできず内部でプログラムを動かすためのものもあります。 Linuxでは、ユーザごとに権限を設定できます。権限には、読み取り（r）、書き込み（w）、実行（x）の3種類があります。 例えば、ファイルに何か書き込みたいと思っても、自身が操作するユーザにその権限がなければ書き込むことはできません。 権限を設定するコマンドもあるため、必要に応じて割り当てたり変更する必要があります。 本章の内容は以上です。 次章では、実際にLinux仮想環境を用意してサーバ構築を行った手順をご紹介します。 Linux仮想環境でのサーバ構築 仮想マシン(AzureVM)の用意 Linuxは、コンピュータ（ハードウェア）の機能を管理しプロセスとの仲立ちを行うカーネルと、カーネルに人間の出した命令（コマンド）を翻訳し伝えるシェルで構成されています。 実際にLinuxを動かして学ぶには、コマンドを出す対象となるコンピュータが必要です。 しかし私が現在使っているコンピュータはWindowsという別のシステムが管理しているため、Linuxのコマンドを書いても通じません。 そのため今回は仮想化されたコンピュータである「Azure VM（Virtual Machines）」というクラウドサービスを利用して仮想環境を構築しました。 仮想マシンOSには、「Red Hat Enterprise Linux (RHEL) 9.4」を選択しました。 Windows環境を維持したままLinuxを実際に操作する方法は他にもいろいろあるので、ご自身のパソコンやその他条件に応じて選択することをおすすめします。 仮想マシンにSSH接続 仮想マシンを作成したら、次はそれに接続する必要があります。 今回はSSHという通信プロトコルを使って接続しました。 SSHは暗号化された通信を行うためのプロトコルで、今回のようにコンピュータが手元にない（リモート）場合でも安全に接続することができます。 SSH接続の手順は以下の通りです。 仮想マシン作成時に生成された秘密鍵を自分のパソコンに保存する ターミナル（コマンドプロンプト）を開き、以下のコマンドを実行して接続する ssh -i 秘密鍵のパス ユーザー名@IPアドレス 初回接続時には、ホストキーの確認が求められるので「yes」と入力 HTTP通信に必要なもののインストールと設定 作成した仮想マシンには最低限の機能しかないため、目的に応じて必要な部品や設定を追加する必要があります。 今回は、Webブラウザにアドレスを入力するとWebページが表示されるようにしたかったので、Apacheというものをインストールしました。 １．Azure Portalで受信ポート規則の変更 認証のため受信ポート22番（SSH）を許可する ソースは安全のため自分のIPアドレスに限定する ２．仮想マシン上でApacheのインストール sudo dnf install httpd ３．Apacheの起動と自動起動設定 ・サービスの起動 sudo systemctl start httpd ・自動起動の有効化 sudo systemctl enable httpd ４．RHELの内部ファイアウォールでHTTPトラフィックの許可 ・HTTPの許可 sudo firewall-cmd --add-service=http --permanent ・設定の反映 sudo firewall-cmd --reload ５．Azure Portalで受信ポート規則の変更 Webページを閲覧するため受信ポート80番（HTTP）を許可する ソースは自分のIPアドレスに限定する 表示するコンテンツの作成 Apacheのデフォルト設定では、「/var/www/html」ディレクトリにHTMLファイルを置くことで、Webページとして表示されるコンテンツを作成できます。 今回は、以下のコマンドで「index.html」を作成しました。 sudo vi /var/www/html/index.html Linuxでファイルを編集するには、viエディタなどのテキストエディタを使用します。 viエディタには実際に中身を編集するインサートモードと、ファイルの保存や終了などの操作を行うコマンドモードがあります。 慣れないうちは操作が難しく、何度かパニックになりました。   Webページの表示確認 Webブラウザに仮想マシンのIPアドレスを入力すると、作成したWebページが表示されます。 Azure Portalの受信ポート規則でソースを自分のIPアドレスに限定しているため、他のIPアドレスからはアクセスできません。 感想とまとめ 以上が今回のサーバ構築で行った内容でした。全くの初心者の私にとっては非常に充実した経験となりました。 実はこの後も様々な学習を続けており、現在は認証認可というもっと高度な設定に挑戦しています。余裕があれば現在取り組んでいる内容もまとめたいと思っているため、また機会があればよろしくお願いします。 長くつたない文章を最後までお読みいただき、ありがとうございました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post Linux初心者がAzure仮想マシンでHTTPサーバを構築した話 first appeared on SIOS Tech Lab .

本記事は 2026 年 7 月 1 日 に公開された「 Run log analytics for a fraction of the cost with the new engine for Amazon OpenSearch Service 」を翻訳したものです。 Amazon OpenSearch Service はリアルタイムの検索・分析エンジンで、AI ワークロードからログ分析まで幅広く使われています。業界全体で見ると、組織が扱うログ量は毎年 30〜40% ずつ増え続けており、オブザーバビリティ基盤のインフラコスト膨張とクエリ速度の低下が避けられない状況です。必要なデータを残すか、予算を守るか。多くのチームがこの二択を迫られています。 今回、Amazon OpenSearch Service にログ分析専用の新エンジンが加わりました。価格性能比は最大 4 倍、データ取り込み速度は 2 倍、分析クエリは最大 2 倍高速、ストレージコストは最大 70% 削減されます。ログ分析に最適化しつつも、OpenSearch の強みである全文検索は同じデータに対してそのまま使えるため、コスト削減と検索能力のトレードオフに悩む必要がなくなります。 この記事では新エンジンの仕組み、使い始める手順、そして数十億ドキュメントを使ったベンチマーク結果を紹介します。 最適化エンジンの仕組み 最適化エンジンは Amazon OpenSearch Service ドメイン内の新しいエンジンモードです。コンソール、API、セキュリティモデル、ネットワーク設定はすべて汎用エンジンと共通なので、運用の仕組みを変える必要はありません。 内部では、すべてのデータが Apache Parquet 形式で保存されます。検索対象として設定したフィールドには転置インデックスも作られるため、カラムナストレージの効率と全文検索の速度を両立しています。クエリが来ると Apache Calcite が解析・最適化を行い、カラムナデータの集計は Apache DataFusion、全文検索は Lucene と、処理に応じて最適なエンジンに振り分けます。この 2 つはクエリの途中で連携するため、ログ本文の検索と集計を 1 回のリクエストで完結できます。 利用者から見ると、取り込みには汎用エンジンと同じ REST API やクライアントライブラリがそのまま使えます。エージェントやパイプラインの変更は不要です。クエリ言語は Piped Processing Language (PPL) と SQL の 2 つに対応しており、どちらもベクトル化エンジンで直接実行されます。なお Domain Specific Language (DSL) のクエリ API はローンチ時点では未対応です。 使い方 ローンチ時点では、最適化エンジンはドメイン作成時に選ぶドメインレベルの設定です。既存ドメインへの追加や、個別インデックス単位での有効化には対応していません。最適化エンジンを使うには新しいドメインを作成し、取り込みパイプラインをそちらに向ける必要があります。 Amazon OpenSearch Service コンソールで新規ドメインを作成し、ユースケースに Observability を選ぶと、最適化エンジンがデフォルトで有効になった状態でドメインが構成されます。コンソール上には両エンジンの機能比較が表示されるので、自分のワークロードにどちらが適しているか判断できます。 ドメインが準備できたら、汎用エンジンと同じ Bulk API とクライアントライブラリで JSON を投入できます。既存の取り込みパイプラインやアプリケーションコードをそのまま流用できるため、移行時にコード変更は不要です。 ログ分析向け最適化エンジンのメリット 新エンジンで得られる改善をまとめます。 最大 4 倍の価格性能比 — 私たちが実施したベンチマークで汎用エンジンと比較した結果です。インシデント調査用の全文検索も引き続き利用できます。 最大 2 倍の分析クエリ速度 — データをカラム単位のバッチにまとめて処理するベクトル化実行パスにより、大規模データセットでも高速に結果を返します。 最大 2 倍の取り込みスループット — 追記専用のカラムナ書き込みパスで、持続的な取り込みレートが向上します。 最大 70% のストレージ削減 — カラムナストレージにより同じコストで最大 3 倍のデータを保持できます。 以下のセクションでは、数十億ドキュメント規模のオブザーバビリティワークロードで実施したベンチマークの方法、環境、結果を説明します。実際のワークロードでの効果はユースケースごとに異なるため、ご自身の環境でもテストされることをおすすめします。 ベンチマークの方法 OpenTelemetry の Telemetry Generator で合成トレースとログを大量に生成し、OTEL トレース、OTEL ログ、Web サーバーアクセスログの 3 種類のデータセットを作りました。生成データは bulk 形式の NDJSON として Amazon Simple Storage Service (Amazon S3) に保存し、AWS Fargate 上の Amazon Elastic Container Service (Amazon ECS) パイプラインで取り込みました。パイプラインは S3 からチャンクを読み、タイムスタンプを変換して OpenSearch の Bulk API に書き込む構成で、本番のオブザーバビリティフローを再現しています。 テスト環境は OpenSearch 3.5 を動かす 2 つの OpenSearch Service ドメインで、それぞれ 3 アベイラビリティゾーン構成、データノード 9 台です。 構成 最適化エンジン Standard Lucene インスタンスタイプ 9x or2.4xlarge.search 9x r8g.4xlarge.search リーダーノード 3x m7g.large.search 3x m7g.large.search EBS 2,500 GB gp3、7,500 IOPS、500 MB/s (ノードあたり) 2,500 GB gp3、7,500 IOPS、500 MB/s (ノードあたり) エンジンモード OPTIMIZED General Purpose ( best_compression ) 3 データセット合計で 244 億ドキュメント、9.5 TB の生 JSON を取り込みました。インデックスは 9 プライマリシャード、1 レプリカで、ISM ロールオーバーはプライマリシャードあたり 50 GB に設定しました。Lucene 側は best_compression (zstd) コーデック + _source 有効で、一般的な本番構成を再現しています。 取り込みパイプラインは同一 VPC 内の Fargate タスク 90 個 (各 16 vCPU、120 GB RAM、48 ライタースレッド、バルクサイズ 3,000 ドキュメント) で実行しました。 結果 取り込みスループット 最適化エンジンは追記専用のカラムナストレージを採用しており、ドキュメントごとに stored field を書く必要がありません。複数ドキュメントをまとめてカラムナセグメントとして一括書き込みするため、高いスループットを実現しています。 メトリクス 最適化エンジン Lucene ベースライン ピークスループット 178 万 docs/sec 約 64.7 万 docs/sec ピーク時クラスタ CPU 62% 72% Write rejection 0 0 取り込みドキュメント総数 244 億 157 億 同じ並列度で毎秒 178 万ドキュメントを維持し、Lucene の約 2 倍のスループットを CPU 負荷を抑えながら達成しました。write rejection は両ドメインともゼロでした。1 日に数テラバイトを取り込むチームなら、同じ量をより少ないノードで捌けるか、同じインフラでより長い保持期間を取れることになります。 ストレージ圧縮 Parquet のカラムナ形式では、同じフィールドの値がまとめて格納されるため、辞書エンコーディングや型に特化した圧縮が高い効率で効きます。加えて、行単位で生 JSON を保持する必要がないため、オブザーバビリティデータのストレージを大幅に削減できます。 244 億ドキュメントでの実測値: データセット ドキュメント数 ソース 最適化エンジン Lucene (デフォルト) 圧縮率 vs. ソース Lucene 比削減率 Web ログ 87.6 億 2,360 GB 254 GB 614 GB 89% 59% OTEL ログ 82.0 億 3,720 GB 815 GB 1,549 GB 78% 47% OTEL トレース 74.3 億 4,131 GB 841 GB 1,790 GB 80% 53% 合計 244 億 9,539 GB 1,910 GB 3,953 GB 80% 52% 結果として、生 JSON に対して 5 倍の圧縮 (80% 削減) を達成しています。デフォルトの Lucene 構成 ( _source 有効) と比べてもストレージはおよそ半分です。最適化エンジンは _source をクエリ時に Parquet カラムから再構成するため、ドキュメントの取得機能を維持しつつ生 JSON を別途保存する必要がなくなっています。 分析クエリ性能 オブザーバビリティダッシュボードの典型的なパターンとして、数十億のログイベントに対し 15 分間のタイムウィンドウで絞った分析集計のレイテンシーを計測しました。最適化エンジンは @timestamp カラムの row-group プルーニングでクエリ対象外のデータをスキップし、必要な部分だけを読みます。 クエリパターン データセット 最適化エンジン Lucene ベースライン 高速化倍率 サービス別エラー数 OTEL ログ 717 ms 2.8 s 3.9x ホスト別ログ量 OTEL ログ 252 ms 17.6 s 70x サービス・メソッド別 5xx エラー OTEL ログ 171 ms 885 ms 5.2x エラー上位サービス OTEL トレース 635 ms 569 ms 約 1x ポイントルックアップ (単一 traceId) OTEL トレース 394 ms 783 ms 2x すべてのクエリは 15 分ウィンドウでスコープ。インデックスサイズ: OTEL ログ 82 億イベント、OTEL トレース 74 億スパン。 最適化エンジンは、数十億ドキュメントに対する時間フィルター付き分析クエリを 171 ms〜717 ms で完了しました。特にフィルターなしの集計 (ホスト別ログ量: 70 倍高速) で差が顕著に現れており、必要なカラムだけを読むカラムナエンジンの特性が効いています。一方、Lucene の転置インデックスが高い選択性を発揮するクエリ (トレースのエラー上位サービス) では両者の性能は同程度でした。 検索とポイントルックアップ 分析だけでなく検索も高速です。最適化エンジンはカラムナストレージと Lucene 転置インデックスの両方を持っており、クエリプランナーが選択的なルックアップ (特定の traceId の検索など) を検出すると、カラムナスキャンではなく転置インデックスにルーティングします。74 億スパンに対する単一 traceId ルックアップは 165 ms で完了しました。 実際の障害調査では、まず集計で問題を絞り込み、次にポイントルックアップで該当トレースを引く、という流れが 1 つのドメインで完結します。 提供開始 Amazon OpenSearch Service のログ分析向け最適化エンジンは、OpenSearch Optimized Instances が利用できるすべての商用 AWS リージョン (AWS GovCloud (US) および中国リージョンを除く) で一般提供されています。 料金はインスタンスとストレージの標準 Amazon OpenSearch Service 料金に準じ、最適化エンジンの追加費用はかかりません。詳細は Amazon OpenSearch Service の料金 を参照してください。 設定と使い方の詳細は Optimized for Log Analytics (Amazon OpenSearch Service ドキュメント)、サービス概要は Amazon OpenSearch Service Log Analytics を参照してください。 フィードバックは AWS re:Post for Amazon OpenSearch Service または AWS サポートまでお寄せください。 著者について Jagadish Kumar Jagadish は Amazon Web Services のシニアソリューションアーキテクトで、OpenSearch と分析ワークロードを担当しています。 Rohin Bhargava Rohin は Amazon OpenSearch Service のシニアプロダクトマネージャーです。 Michael Supangkat Michael は Amazon Web Services のソリューションアーキテクトで、検索とオブザーバビリティを専門としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。