Elasticsearchのパフォーマンス問題をプロファイラを使って解決する | メルカリエンジニアリング
search infra teamのmrkm4ntrです。我々のチームではElasticsearchをKubernetes上で多数運用しています。歴史的経緯によりElasticsearchのクラスタは全てElasticsearchクラスタ専用のnode pool上で動作していました。ElasticsearchのPodは使用するリソースが大きいため、このnode poolのbin packingが難しくコストを最適化できないという問題がありました。そこで全てのElasticsearchクラスタを専用のnode poolから他のワークロードと共存可能なnode poolへ移行しました。ほとんどのクラスタが問題なく移行できたのですが、唯一移行後にlatencyのスパイクが多発してしまうものがありました。 この記事では、その原因を調査する方法と発見した解消方法について説明します。 発生した現象 共
Elasticsearchを使ってリストAPIを100倍高速化した話
はじめに こんにちは！私がつとめている CastingONE という会社の SaaS には、テーブル形式のデータ一覧ページがあります。この一覧ページですが、最近データ数が増えれば増えるほど、じわじわとパフォーマンスが悪くなっていってました…。そこで今回は、そのリストデータ取得におけるパフォーマンス改善を行なった時の、パフォーマンス計測方法や検討内容、最終的な結果をまとめてみました。 対象読者 バックエンドのパフォーマンス改善の方法や改善の流れに興味がある方 ちなみに私がこの改善を行なった時のスペックですが、パフォーマンス改善については初心者寄りでした。「パフォーマンス改善って何それ美味しいの？」というレベル感だった当初、「達人が教える Web パフォーマンスチューニング 〜ISUCON から学ぶ高速化の実践」という本には基礎を知るところから大変お世話になったので、ご興味のある方はぜひ読んで
検索の応答性能を維持するための Benchmarking Automation | メルカリエンジニアリング
※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercari" の一環で書かれています。 はじめに こんにちは、メルカリMicroservices SREチームの藤本(@jimo1001)です。 私は Embedded SRE としてメルカリJPの検索に関連するマイクロサービスを提供している サーチインフラチームに入り、サービスの信頼性向上やインフラ周りの自動化に従事しています。今回は、メルカリの商品検索の応答性能を維持するための Benchmarking Automation の取り組みについて紹介したいと思います。 検索基盤のアーキテクチャ まず、検索基盤のアーキテクチャについて簡単に説明します。主要なコンポーネントに絞ってシンプルに表現したものが以下の図になります。 各コンポー
LINEエンジニアが語る、Elasticsearch運用法と監視の裏側
LINEエンジニアが語る、Elasticsearch運用法と監視の裏側 LINEデリマでのElasticsearchの運用と監視の話 #2/2 2018年1月30日、LINE株式会社が主催する技術者向けミートアップ「LINE Developer Meetup in Tokyo #27 -Elastic-」が開催されました。27回目となる今回のテーマは「Elastic」。LINE社内ではElasticsearchがどのように運用されているのか？ ゲストスピーカーにElasticのエヴァンジェリストも迎え、最新の事例と今後について語ります。プレゼンテーション「LINEデリマでのElasticsearchの運用と監視の話に登場したのは、LINE株式会社開発3センター開発支援室の渡邊紘太朗氏。LINEが手がけるフードデリバリーサービス「LINEデリマ」におけるElasticsearchの運用方法と
Elasticsearch 5.0.0で再インデクシングの高速化を探求する - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの渡辺です。IntelliJのコード補完はCtrl+;にバインドしています。 アプリケーション基盤チームでは、Necoプロジェクト（アーキテクチャ刷新プロジェクト）の一環として、 次世代の検索基盤を検討していて、その候補としてElasticsearchを調査しています。 先月の記事で再インデクシングと絡めてingest pluginの話をして、 びっくりするぐらい需要が低く、自分のテーマ選択のセンスのなさを痛感したのですが、 こじらせた感じで今日も再インデクシングの話をしたいと思います。 想定読者は、Elasticsearchにある程度慣れている方として、用語やAPI（インデックス, シャード, ScrollAPI, BulkAPIなど）の説明は最小限にします。 利用したElasticsearchのバージョンは5.0.0-alpha4です。2.X系だと
Elasticsearchインデクシングパフォーマンスのための考慮事項 - Qiita
マッピングタイプを使いすぎないようにする Elasticsearchでは１つのインデックスの中に複数の異なるスキーマ定義を持つことができる。このスキーマ定義をマッピングタイプという。単に「タイプ」と呼ばれる事もある。フィールドのデータタイプとは別の概念。インデックスはデータベースに、マッピングタイプはその中のテーブルに例えられる事が多いが、同じ名前のフィールドはマッピングタイプが異なっていても定義が共有されたりして、データベースのテーブルほど互いに独立していない中途半端なものになっている。（2.0より前のバージョンではタイプごとにフィールド定義が異なっていても多少使えたりしたが、2.0以降は厳密に禁止されるようになった. 参照：Conflicting field mappings） タイプが異なっていてもデータは同じLuceneインデックスの中に混ざって入ってしまうため、タイプ間で互いに影
Kibana用途でElasticsearchを使う時の高負荷対策TIPS - Qiita
これは Elasticsearch Advent Calendar 2015 8日目の記事です。 ログの可視化ツールとしてKibanaを使っている中で、Elasticsearch運用として色々と得られた知見を書きたいと思います。 Elasticsearchは、ライトな環境だったら特にチューニングなく安定してますがある程度ドキュメント数が積まれてくると、色々苦労があるなという印象です。 ここに書かれているのは、事情がありシングル構成で頑張った話なので、クラスタ組んでスケールするとこんな悩みはないのかもです。 でも、ログは運用系に入るのでそんなにコストかけれるとこはないのではという個人的な所感。 ラインナップとしては、下記のような感じです。 Kibana経由で重たいクエリが投げられると負荷高すぎて泣いた話 高負荷対策として、fielddata_cacheをディスクに逃がす方法 fluentdの
RDS for MySQLのスロークエリーログをAWS LambdaでElasticsearchに取り込む | DevelopersIO
はじめに 藤本です。 Elasticseachに取り込むネタが続いています。 前回のELBのアクセスログをAWS LambdaでElasticsearchに取り込むに続いて、今回はRDS for MySQLのスロークエリログをElasticsearchに取り込む実装をご紹介します。 概要 MySQL Serverはスロークエリーログにより指定した秒数を超えるクエリを記録することができます。スロークエリログはパフォーマンス劣化の解析、クエリの適切性、DBのマシンパワーの適切性のチェックに役立ちます。RDS for MySQLも例外ではありません。パラメータグループを設定することにより、スロークエリログを有効にすることができます。それに加えてRDS for MySQLの場合、AWSのAPIによりデータベースに接続せずともスロークエリログを取得することができます。 スロークエリログフォーマット
Elasticsearchのインデキシングに関するパフォーマンス検討
Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。 第一に、制御できないならば、巨大なJavaヒープを使用しない：必要なサイズ（マシンの持つRAMの半分以下）のheapだけを設定し
CactiのデータをElasticSearch+Kibanaでまとめてみてみよう
斎藤です。こんにちは。 最近、会社の中で様々な部活動が始まっています。「プログラミング部」や「フットサル部」といったメジャー(?)なものから、「サイクリング部」「P部(プロレス観戦部)」そして「二郎部」などなど、エッジが効いたものまであります。そうそう、私は「サイクリング部」と「P部」に所属しています。 さて、今回はKibanaを使って、Cacti(RRDTool)が収集したモニタリングデータを参照してみようと思います。Cactiはモニタリングデータを収集・ビジュアライズするツールとして普及していますが、他のサーバ・指標と比較するのがちょっと面倒です。そこを、Kibanaを用いてより見やすくしようと言うのが目的です。Kibanaとは、収集したログをGUIで整理しつつビジュアライズできるデータ分析ツールの一種です。たいてい、データストアとしてElasticSearchというNoSQL DBサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
