Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

背景 サーバーに対して位置情報を含む500万レコード以上のデータがFTP経由で送られてくる。送られてくるときは1つのファイルにある独自の方法で圧縮されているが、このままでは位置情報を元にした検査ができないため、受け取った時点で展開して位置情報をサポートしたデータベースに書き込むのが今回の課題。 なお、このファイルは5分毎に送られてくる。したがって書き込みに5分以上かかってはダメ。できたら アプリケーションでの展開 → データベースへの書き込み までを2分程度で終わらせて、その後は位置情報をもとに検索ができなければならない。という状況。 親切な方から、位置情報ならElasticsearchがいいんじゃないかと教えてくれた。で、試行錯誤してなんとか2分ちょっとで書き込めるようになったので、そこまでにやったことの覚え書き。 【2017/1/3 追記】参考資料 このメモをキータにあげた際に、Jun
はじめに 趣味でわいわい作っているサービスがあります。このサービスに検索機能をつけたいという話になりました。 最新の人気Webサービス・アプリが見つかる Service Safari このサービスは新サービスがキュレーターによって毎日投稿されて、それがアプリとかWebとかメールで見れるというサービスです。現状でも名前で検索したり、タグで検索したりはできるのですが、今回は複数タグでの検索や紹介文の全文検索機能をつけたいという要件です。MySQLだとつらそうなのでElasticsearchを使ってみることにしました。 サービス名の部分一致で検索できる サービス紹介文の全文検索ができる 複数のタグでの検索ができる サービスURLのドメインで検索ができる 上記の項目で複合検索ができることをゴールとします。 まったくのElasticsearch初心者がやっていることなど間違っているところもあるかもし
はじめに Elasticsearchはスケーラビリティに優れた全文検索エンジンですが、Relational Database(以下RDB)が持つ汎用性や機能の豊富さも追求しているように思います。この記事ではRDBの基本機能がどこまでElasticsearchで実現できるかをまとめました。データベースの知識だけで、全文検索を知らなかった私がElasticsearchを勉強し始めた頃に意外に感じた事を中心に両者の違いを比較しています。APIについては言語ごとの違いは言及せず、REST APIについてのみ述べています。特にバージョンの記述がない場合はElasticsearch 5.1を前提にしています。RDBは近年ポピュラーなOracle, SQLServer, DB2, Sybase, PostgreSQL, MySQLなどが準拠しているSQL92標準を前提としています。 基本的な違い RDB
前置き この記事は Retty Advent Calendar 23日目です。 昨日は@kazushikawamuraのReact & Firebaseで簡単なChatアプリを作ってみたでした。 Elasticsearchとは 今更なにを。。。と思う方がほとんどだと思います。 釈迦に説法で非常に恐縮ですが、5.1.1も出たところですし一回お浚いということで。。。 Elasticsearchは、Elastic社が展開する強力な検索エンジン?です。 正直なんて定義できるものかよく分からないですが、全文検索でよく使う、あとデータ分析にめっちゃ強いというところでいろんなところで重宝してます。 この前行ってたelastic{on}では、ある発表でElasticsearchのいいところを 「貯める、検索する、集計する」が一つのプロダクトで出来る というのをあげていました。 強力なビジュアライズツールK
はじめに こんにちは。転職会議チームでエンジニアをやっている @highwide です。 転職会議では、2016年に一部の検索画面をRails + elasticsearchで実装しました。その際、自分自身、アレコレ新しく学んだことが多かったので、今年のAdvent Calendarのネタにしたいと思います。 注意 Rails 4.2系/elasticsearch 2.4系の情報で書かれているところが多いため、ご参考にしていただく際は最新の情報と照らし合わせながら進めていただけると助かります。 ドキュメント設計 elasticsearchのドキュメント構造は以下のよう階層があります。 ちなみに学習を始めた際、 indexはRDBMSにおけるDATABASE、typeはRDBMSにおけるTABLE といった情報を目にしました。 確かに、階層構造を理解する上で誤った情報ではありませんが、RDB
はじめに この記事は CrowdWorks Advent Calendar 2016 12日目の記事です。 昨日のエントリーは @nasum さんによる「nasneの容量をシェルスクリプトでSlackに通知する」でした。 先日起きたことを、ありのままに1話します。 MySQL にあるデータを Elasticsearch (以下 ES と略) にインデックスしようとしていたと思ったら、いつの間にか Ruby の C 拡張をデバッグしていた。な、何を言ってるのか (ry おまえは何を言っているんだ 三行でまとめると、 Ruby を使って ES にインデックスを作ろうとしたら予期しない現象に遭遇して、 原因を探ろうとしたら C 拡張で実装されている箇所だったので、 しょうがないからデバッグする方法を調べた という話です。 発端 事の起こりは、自社サービスのデータベースに溜まっているデータをより効
はじめに 少し前の情報ですが、株式会社ラック社からDNSプロトコルを使用したウィルスについての注意喚起がありました。 ■遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起 http://www.lac.co.jp/security/alert/2016/02/01_alert_01.html 記事中にそのウィルスへの対応法について記載があり、その1つに「内部DNSのアクセスログから不正なリクエストを発見する(ログを取得する)」があげられています。 本事案以外でも、多くのマルウェアは名前解決を行いC&Cサーバとやり取りを行うため、DNS通信のログを取得することは、調査において重要な情報になると考えます。 DNS通信のログを取得するといっても、単純なパケットキャプチャだと、閲覧しにくい(後で情報を追う時に時間が掛かる)等の問題があります。 今回は、以下のオープン・ソースプロダク
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちわ、ワカルのCTOの包です。 今日で2015 WACUL Advent Calendar 2015 最後の日です。 この1年は、会社としても大きく成長した一年でした。すべて埋まった(!)アドベントカレンダーの記事を振り返ってみると、技術者の層がとても厚くなったなと感じます。 なにより、忙しい業務の合間に楽しい記事を書いてくれた会社のみんな、忙しい中寄稿してくれた @kenzan100 さん、技術メンバーの働き方に理解を示してくれて共に頑張っている会社のみんなに感謝しています。 データの検索は Elasticsearch に丸投げ
概要 Elasticsearch運用をDockerに移行する為に、とりあえずは手元のMac環境でElasticsearchを立ててみる。ついでに、terraformで立てたEC2に、dockerhubに登録したイメージをデプロイする。 それぞれバラバラにしか触ったことなかった、docker,terraformをしっかり触って理解するのが目的。 チェックポイント まずは、やってみたレベルなのでここを目標にする elasticserch1.6のDockerイメージを作る ローカルで2台起動してクラスタ構成の確認 ドキュメントの登録と両ノードで引けることを確認 作ったイメージをEC2にデプロイしてみる elasticserch1.6のDockerイメージを作る cloneとDockerFileの修正 テストなので、elasticsearch-headのプラグイン追加(Dockerfile)とクラ
はじめに 今更ながらかもしれませんが、EFK(ElasticSearch+Fluentd+Kibana)を試してみてます。 ちょっと試したいだけなのに一杯インストールせねばならんのですね。。。ということでEFK構成を構築するansibleのplaybookを作ってみました。良ければ使ってください。 Forwarder - https://github.com/uzresk/ansible-td-agent.git EFK - https://github.com/uzresk/ansible-efk.git 3分で構築する前提事項 ansibleが使えること gitが使えること(yum -y install gitとかで突っ込んでおいてください) サーバを2台(sshで接続できればなんでもいいです) こんな環境を作ります。 左側はfluentdのforwarder。右側はログを集積するag
目標 全く更地の状態、しかもfluentdもESもなんとなくしかわかってない状態から、どうにかKibanaでリソース監視Dashboardを作るまでこぎつける。 同じことをやっている記事はいっぱいあるので、fluentdとESをよくわかってない状態で始めようとして躓いたポイントを中心に手続き的に。 太字になってるところがわかりづらい点・注意を要する点・推奨する内容。 参考 公式: Fluent: http://docs.fluentd.org/articles/config-file ES: https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html http://blog.nomadscafe.jp/2014/03/dstat-fluentd-elasticsearch-kibana.html ht
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エージェントソフトウェアを対象PCにインストール形でサーバの監視・性能測定を行うツールのまとめ。 SaaSサービス NewRelic アプリケーションの性能測定が簡単にできるSaaS。あちこちで導入実績があってスタートアップではデフォルト担っているようにさえ感じる。各言語でのプラグインだけがあって、自作アプリ外のサービスは対象外なのかと思っていたが、プラグインのリストをみると色々と対応しているようだ。 Good 豊富な実績がある Bad インターネットにつながっていないと利用できない。 参考リンク New Relic Wantedlyを
以前、下記のPostをしていて、この時は一つのホストに複数のコンテナをDocker Composeを用いて構築していました。 ELK(ElasticSearch, Logstash, Kibana)+fluentdの環境をDocker Composeで構築しつつ、試しにCloudWatchの統計データを収集してみた このときのdockerの--linkオプションでは、別のホストマシン上に起動してあるコンテナのhosts情報を渡せなかったのですが、 Docker Engine 1.9で追加されたマルチホストネットワーキングを使えば、複数ホスト間でネットワークを共有し、--linkで渡した名前を元にしたアクセスが可能になるかと思い試してみました。 → --linkオプションはマルチホストネットワーキングではサポートされていませんでした。 また、将来的にDockerから削除されるそうです。 マル
Elasticsearch: The Definitive Guideでは、本番環境の構築についていろいろ詳しく書かれています。忙しい方のために、簡単に纏めました。 #基本的な考え方 まずメモリ容量について考えるでしょう。数百GBのサーバとAWSのt2.microのような1GBのサーバの両極があります。弱いサーバだと台数を増やさなければいけないが、クラスタ管理の手間、ノード間通信の負荷が増えます。あまりにも強いサーバだとCPUとメモリのバランスが取りにくいです。下記の図で示したように、真ん中の数十GBのサーバで組んだ数十台~数百台規模の構成がスイートスポットとなります。 #サーバスペック Elasticsearchはメモリバウンドなので、メモリが重要です。そうはいっても64GB以上はいりません。CPUは普通のマルチコアでよいので、Hzが重要ではありません。LuceneはI/Oバウンドなので
Amazon Elasticsearch Service は、アクセス制御が IAM や IPアドレスでできます。最初は IPアドレスフィルタでいじってたのですが、将来的にドツボにはまりそうだったため IAM で行うようにしました。 なお、Amazon Elasticsearch Service のアクセスポリシーの変更は、指定してから20分ぐらい待たないと反映されないため、面倒です。早めの IAM 化が楽だと思います。(反映待ちの間もサービスは使えます) IAM ユーザーの作成 IAM のユーザーページ https://console.aws.amazon.com/iam/home#users より「新規ユーザーの作成」 →適当に作ります 完成後、 「ユーザーのセキュリティ認証情報を表示」リンクをクリックして、 アカウント名、アクセスキー ID、シークレットアクセスキー を記録しておきま
Elasticsearchにクエリ投げても突然応答しなくなるという事象が発生し、調査してみたので内容をシェア。 ##出たエラー 突然Elasticsearchのクエリがfailし始めて、Kibanaのグラフが応答しなくなったという話が上がる。。 ログ見てると、下記の用語が怪しいので調査 ####うちの環境だと、HEAP_SIZEを18gにしていたので、まさにこのエラーは、[indices.breaker.fielddata.limit]でひっかかっている。(18g*60%=10.8g...) OOM(OutOfMemory)を制御する為の機構 デフォルト値は下記 [indices.breaker.fielddata.limit] The fielddata circuit breaker limits the size of fielddata to 60% of the heap, by
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く