2017-12-08

ES DeskというElasticsearch検証用Webアプリを作った

このエントリはElastic stack (Elasticsearch) Advent Calendar 2017の12/8分です。

ES DeskというElasticsearch用のWebアプリを作成しました

github.com

まずはデモサイトをご覧ください。

http://es-desk.winebarrel.jp/

これは何？

Elasticsearchのインデックスを編集しながら、トライアンドエラーで検証するためのWebアプリです。

以下のような機能があります。

ブラウザからのQuery DSLの送信と結果の保存
データセットの登録・インポート
インデックスの作成・編集
Query DSLの登録・編集

Elasticsearchのインデックスのアナライザを変更する検証を行うときに、いままでは「元のインデックスを消して」「curlで修正したインデックスを投入して」「データをロードして」みたいなことをやっていたんですが、ES Deskではブラウザから直接インデックスの定義を編集することができ、元のデータの残る*1ので、「こまごまとインデックスの編集→検索結果を見る」という作業をやるときに手間がかなり省けました。

また、検索結果を「クエリ＋そのときインデックス定義＋検索結果＋そのときのデータセット」という感じでスナップショット的に保存しておけるので、他の人に「こういうアナライザをつかったら、こんな結果になりました」というのを共有しやすいです。

なかなか便利に使っております。

どうぞご利用ください。

*1:正確にはデータを再ロードしています

2017-11-28

utsusemiというプロキシサーバを書いた

github.com

これは何？

リクエストが来たとき、バックエンド①が404ならバックエンド②にアクセスして、バックエンド②が404ならバックエンド③にアクセスして…みたいなプロキシサーバ。

開発用の画像配信サーバに画像がなかったときに、本番にアクセスしにいく、みたいな用途で使います。

それnginxで（ｒｙ

できます。なんかこんなQAがあって、

server {
  listen 80;
  location / {
    proxy_pass http://foo.bar.dev/
    proxy_intercept_errors on;
    error_page 404 =200 /production/$uri;
  }

  location /production {
    internal;
    rewrite ^/production/(.*) /$1 break;
    proxy_pass http://foo.bar.prod/
  }
}

こんな設定にしたら、できました。

が、バックエンドが三つは無理でした。できるのかもしれないけど、わからなかった。。。

それvarnishで（ｒｙ

できます。 return (restart);とかでできます。というか、もともとそうやって実装されてたんですけど、オーバーキル感があるので、結局、自前で実装しました。

で

でまあ、utsusemiというプロキシサーバをGoで書きました。 Golang便利。

こういう設定を書いて、起動すると

#port = 11080

[[backend]]
target = "http://httpstat.us/404"
#ok = [200]

[[backend]]
target = "https://www.google.co.jp"
#ok = [200]

[[backend]]
target = "https://s.yimg.jp"
#ok = [200]

yahooの画像にもgoogleの画像にもlocalhost:11080でアクセスできます。

その他

はてなブログ、tomlのsyntax highlightをサポートしてくれないかなー（nginxをサポートしてて驚いた。すばらしい）

2017-08-11

Rails / Active RecordでMySQLのgeometry型をサポートするライブラリを書いた

Armgという、ARをMySQLのgeometry型に対応させるためのライブラリを書きました。

github.com

使い方は以下の通り。

require 'active_record'
require 'armg'

ActiveRecord::Base.establish_connection(adapter: 'mysql2', database: 'my_db');

ActiveRecord::Migration.create_table :geoms, options: 'ENGINE=MyISAM' do |t|
  t.geometry 'location', null: false
  t.index ['location'], name: 'idx_location', type: :spatial
end

class Geom < ActiveRecord::Base; end

wkt_parser = RGeo::WKRep::WKTParser.new(nil, support_ewkt: true)
point = wkt_parser.parse('SRID=4326;Point(-122.1 47.3)')
Geom.create!(location: point)

Geom.first
#=> #<Geom id: 1, location: #<RGeo::Cartesian::PointImpl:0x... "POINT (-122.1 47.3)">>

ridgepoleにPRをもらって、コードを眺めていたら何となく対応できそうだったので、書いてみた感じです。当初は自前でWKBのパースをやっていたんですが、まじめに考えると大変そうだったので、RGeoを使うようにしました。 MySQL 5.7の最新版だとInnoDBでもgeometry型にインデックスを貼れるので、利用する機会も増えるかも。

ridgepoleでは以下のように-rオプションでarmgを渡してやると、ダンプできます（が、動作はきちんと確認できてません）

$ ridgepole -c mysql2://root:pass@127.0.0.1:13306/test -r armg -e
# Export Schema
create_table "geoms", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=latin1" do |t|
  t.geometry "location", null: false
  t.index ["location"], name: "idx_location", type: :spatial
end

2017-07-02

ath: a interactive Amazon Athena shell

Webコンソールからパーティションをぽちぽち追加するのに疲れたので、Athena用のシェルを書きました。

github.com

使い方は以下のような感じです。

$ export ATH_OUTPUT_LOCATION=s3://my-bucket

$ ath

default> show databases;
default
sampledb

default> /use sampledb
sampledb> show tables;
elb_logs

sampledb> select * from elb_logs limit 3;
"request_timestamp","elb_name","request_ip","request_port","backend_ip","backend_port","request_processing_time","backend_processing_time","client_response_time","elb_response_code","backend_response_code","received_bytes","sent_bytes","request_verb","url","protocol","user_agent","ssl_cipher","ssl_protocol"
"2015-01-01T08:00:00.516940Z","elb_demo_009","240.136.98.149","25858","172.51.67.62","8888","9.99E-4","8.11E-4","0.001561","200","200","0","428","GET","https://www.example.com/articles/746","HTTP/1.1","""Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Safari/602.1.50""","DHE-RSA-AES128-SHA","TLSv1.2"
"2015-01-01T08:00:00.902953Z","elb_demo_008","244.46.184.108","27758","172.31.168.31","443","6.39E-4","0.001471","3.73E-4","200","200","0","4231","GET","https://www.example.com/jobs/688","HTTP/1.1","""Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1""","DHE-RSA-AES128-SHA","TLSv1.2"
"2015-01-01T08:00:01.206255Z","elb_demo_008","240.120.203.212","26378","172.37.170.107","8888","0.001174","4.97E-4","4.89E-4","200","200","0","2075","GET","http://www.example.com/articles/290","HTTP/1.1","""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246""","-","-"

sampledb> select * from elb_logs limit 3 &
QueryExecution 2335c77b-d138-4c5d-89df-12f2781c311b

sampledb> /desc 2335c77b-d138-4c5d-89df-12f2781c311b
{
  "query_execution_id": "2335c77b-d138-4c5d-89df-12f2781c311b",
  "query": "select * from elb_logs limit 3",
  "result_configuration": {
    "output_location": "s3://sugawara-test/2335c77b-d138-4c5d-89df-12f2781c311b.csv"
  },
  "query_execution_context": {
    "database": "sampledb"
  },
  "status": {
    "state": "SUCCEEDED",
    "submission_date_time": "2017-07-02 16:29:57 +0900",
    "completion_date_time": "2017-07-02 16:29:58 +0900"
  },
  "statistics": {
    "engine_execution_time_in_millis": 719,
    "data_scanned_in_bytes": 422696
  }
}

sampledb> /result 2335c77b-d138-4c5d-89df-12f2781c311b
"request_timestamp","elb_name","request_ip","request_port","backend_ip","backend_port","request_processing_time","backend_processing_time","client_response_time","elb_response_code","backend_response_code","received_bytes","sent_bytes","request_verb","url","protocol","user_agent","ssl_cipher","ssl_protocol"
"2015-01-01T16:00:00.516940Z","elb_demo_009","242.76.140.141","18201","172.42.159.57","80","0.001448","8.46E-4","9.97E-4","302","302","0","2911","GET","https://www.example.com/articles/817","HTTP/1.1","""Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1""","DHE-RSA-AES128-SHA","TLSv1.2"
"2015-01-01T16:00:00.902953Z","elb_demo_005","246.233.91.115","1950","172.42.232.155","8888","9.59E-4","0.001703","8.93E-4","200","200","0","3027","GET","http://www.example.com/jobs/509","HTTP/1.1","""Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Safari/602.1.50""","-","-"
"2015-01-01T16:00:01.206255Z","elb_demo_002","250.96.73.238","12800","172.34.87.144","80","0.001549","9.68E-4","0.001908","200","200","0","888","GET","http://www.example.com/articles/729","HTTP/1.1","""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246""","-","-"

どうぞご利用ください。

2017-06-26

Ridgepole v0.7.0.beta2

Ridgepole v0.7.0.beta2をリリースしました。開発中にコメントやフィードバックをしていただいた方にはありがとうございました。

github.com

主な変更点は以下の通りです。

Rails(ActiveRecord) 4.xのサポートを止めた
- 5.xと両方のフォーマットをサポートする必要があったspecがだいぶきれいになりました
- またactiverecord-mysql-awesomeの機能は5.xに取り込まれているので--enable-mysql-awesomeオプションを削除しました
Rails(ActiveRecord) 5.1に対応
Ruby 2.4のサポート…というかテストケースを追加
DROP TABLEをスキップする--skip-drop-tableオプションを追加
MySQLのテーブルオプションの差分を適用する--mysql-change-table-optionsオプションを追加
- kamipoさんの実装をほとんどそのまま取り入れました
MySQL 5.7のサポート
- JSON型とGenerated Columnsが使えるようになりました
URL形式の接続設定のサポート
環境変数経由での接続設定の受け渡し（-c env:MY_DB_URL）
名無しの外部キーのサポート
外部キーの適用順序の変更（FK削除→テーブル変更→FK追加）

AR 5.1サポート・MySQL 5.7サポート・FKまわりの改善が大きなところです。特にFKまわりついては、はまる人が多いようだったので、それなりに使い勝手を良くしたつもりです。（とはいえ、ARの名無しFKの実装についてはもやもやするところですが）

0.7系について、不具合や要望等があれば随時Issue上げていただけると助かります。

2017-04-10

fstaidというHAデーモンを作った

fstaidというHAデーモンを作りました。

github.com

HeartbeatとかCorosyncとかPacemakerの代替を考えて作ったソフトウェアです。

なぜ作ったのか？

それほど多くはないんですがたまに「先方の許可するIPアドレスは１つしかないから、フェイルオーバー時にElasticIPを付け替える感じで」という案件がたまにあるんですよ。そうすると「Corosync/Pacemakerでクラスタ組むか。だるいな…」ということになって、Heartbeat/Corosync/Pacemakerを使いたくない欲が高まった結果、作成されました。 KeepalivedやSerfを使ってクラスタを組むこともできるんですが、どうもやりたいことに対して、オーバーキル感とか明後日の方向感がぬぐえない感じでいました。

話は変わってMHAです。 MHAいいですよね。安定した動作もレプリケーションの付け替えもすばらしいんですが

監視対象外の第三者サーバによるモニタリング
セカンダリチェック
CLIツール群による設定・環境まわりのチェック
フェイルオーバー完了後の起動ロック

などなど、「ああ、わかってる…」感がすごく好きでした。 fstaidにはMHAにインスパイアされたこれらの設計を取り入れた（つもり）です。

サーバ構成イメージ

使い方

以下のような感じで起動します。

fstaid -config fstaid.toml

設定ファイルは以下の通り。

[global]
port = 8080
interval = 1
maxattempts = 3
#lockdir = "/tmp"
#log = "/var/log/fstaid.log"
#mode = "debug"

[handler]
command = "/usr/libexec/fstaid/handler.rb"
timeout = 300

[primary]
command = "curl -s -f server-01"
timeout = 3

[secondary]
command = "curl -s -f -x server-02:8080 server-01"
timeout = 3

[self]
command = "curl -s -f 169.254.169.254/latest/meta-data/instance-id"
timeout = 3

[[user]]
userid = "foo"
password = "bar"

動作

2〜4までを一定時間ごとに繰り返す
self-checkを実行→失敗したら即終了
maxattemptsまでprimary-checkを実行。すべて失敗したら4に進む
secondary-checkを実行。失敗したら5に進む
監視対象を死亡と見なして、ハンドラスクリプトを実行
フェイルオーバーが完了。ロックファイルを作成してfstaidは終了（ロックファイルを削除しないと、起動できない）

self-checkの必要性が微妙な感じなんですが、今のところ

self-checkでsecondary-checkの踏み台サーバとの疎通を確認
secondary-checkで踏み台サーバ経由で監視対象の動作を確認（ssh、http proxy等々）
primary-checkで監視対象の動作を直接確認

とするといいんじゃないかと考えております。

ハンドラ

ハンドラはこんな感じです。

#!/usr/bin/env ruby
# The handler is called when both the primary check and the secondary check fail

primary_exit_code   =  ARGV[0].to_i
primary_timeout     = (ARGV[1] == 'true')
secondary_exit_code =  ARGV[2].to_i
secondary_timeout   = (ARGV[3] == 'true')


def failover
  # to fail over
end

if primary_exit_code != 0
  if secondary_timeout
    # Nothing to do if the secondary-check times out
    exit 1
  end

  failover
elsif primary_timeout
  # Nothing to do if the primary-check times out
  exit 2
end

Rubyで書いてますが、実行できればシェルスクリプトでもなんでも。

ARGV[0]: primary-checkの終了コード
ARGV[1]: primary-checkがタイムアウトしたか否か
ARGV[2]: secondary-checkの終了コード
ARGV[3]: secondary-checkがタイムアウトしたか否か

ここに、ElasticIPの付け替えとか、ENIの付け替えとかを仕込むとよいかと。

その他

curl localhost:8080/failをたたくことで、手動でフェイルオーバーを実行することもできます。

まとめ

今のところ、まだそのような案件が降ってきていないので、まだ実戦投入はできていないのですが、つらみが出てきそうなら積極的に使っていこうかと考えています。あるいは、まだ知らない便利ソリューションがあるとしたら是非知りたいところですが…

2016-11-03

pt-online-schema-change-fast-rebuild-constraints

pt-online-schema-change-fast-rebuild-constraintsというpt-oscのプラグインを書きました。

これは--alter-foreign-keys-method= rebuild_constraintsを高速にするプラグインです。

通常、FKで参照されている親テーブルにpt-oscを実行しようとすると*1

pt-online-schema-change \
  --alter 'ADD num int' \
  h=localhost,u=root,D=employees,t=employees \
  --dry-run
  #--execute

$ ./pt-osc.sh
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
Child tables:
  `employees`.`dept_emp` (approx. 331143 rows)
  `employees`.`dept_manager` (approx. 24 rows)
  `employees`.`salaries` (approx. 2838426 rows)
  `employees`.`titles` (approx. 442010 rows)
You did not specify --alter-foreign-keys-method, but there are foreign keys that reference the table. Please read the tool's documentation carefully.

こんな感じで警告が出ます。

--alter-foreign-keys-method=rebuild_constraintsをつけてexecuteしてみると

$ ./pt-osc.sh
...
2016-11-03T12:44:13 Copied rows OK.
2016-11-03T12:44:13 Swapping tables...
2016-11-03T12:44:13 Swapped original and new tables OK.
2016-11-03T12:44:13 Rebuilding foreign key constraints...
2016-11-03T12:44:35 Rebuilt foreign key constraints OK.
2016-11-03T12:44:35 Dropping old table...
2016-11-03T12:44:35 Dropped old table `employees`.`_employees_old` OK.
2016-11-03T12:44:35 Dropping triggers...
2016-11-03T12:44:35 Dropped triggers OK.
Successfully altered `employees`.`employees`.

と、FKの貼り替えに結構時間がかかってしまいます。

--alter-foreign-keys-method=drop_swapだと速いは速いんですが

2016-11-03T12:47:13 Copied rows OK.
2016-11-03T12:47:13 Drop-swapping tables...
2016-11-03T12:47:13 Analyzing new table...
2016-11-03T12:47:13 Dropped and swapped tables OK.
Not dropping old table because --no-drop-old-table was specified.
2016-11-03T12:47:13 Dropping triggers...
2016-11-03T12:47:13 Dropped triggers OK.
Successfully altered `employees`.`employees`.

テーブルが存在しない瞬間があるので、プロダクションでは使いづらいです。

pt-online-schema-change-fast-rebuild-constraints.pl

--plugin=pt-online-schema-change-fast-rebuild-constraints.plとしてやると、--alter-foreign-keys-method=rebuild_constraintsでも一瞬でFKの貼り替えが終わります。

pt-online-schema-change \
  --alter 'ADD num int' \
  --alter-foreign-keys-method=rebuild_constraints \
  --plugin=pt-online-schema-change-fast-rebuild-constraints.pl \
  h=localhost,u=root,D=employees,t=employees \
  --execute

$ ./pt-osc.sh
...
2016-11-03T12:56:53 Copied rows OK.
2016-11-03T12:56:53 Analyzing new table...
2016-11-03T12:56:53 Swapping tables...
2016-11-03T12:56:53 Swapped original and new tables OK.
Disable foreign key checks
2016-11-03T12:56:53 Rebuilding foreign key constraints...
2016-11-03T12:56:53 Rebuilt foreign key constraints OK.
Enable foreign key checks
2016-11-03T12:56:53 Dropping old table...
2016-11-03T12:56:53 Dropped old table `employees`.`_employees_old` OK.
2016-11-03T12:56:53 Dropping triggers...
2016-11-03T12:56:53 Dropped triggers OK.
Successfully altered `employees`.`employees`.

ログを見るとわかると思いますが、FKの貼り替えの前後でFKのチェックを無効化→有効化するようにしています。これでFK追加・削除時のテーブルコピーを行わないようにして、高速化しています。

余談

「テーブルのスワップ+FKの貼り替え」はアトミックな操作じゃないので、タイミングによっては「子テーブルにデータを挿入しようとしたら旧親テーブルのFKのせいで、制約違反になる」というタイミングがあるのではないかなぁ、と思ってたりしてます。

なので、

FKを無効化
子テーブルのFKを削除
親テーブルをスワップ
子テーブルのFKを再作成
FKを有効化

という手順がベストではないかと考えているのですが、プラグインだけでそこまでやるのは手間がかかりそうです。

*1:employees sample databaseを使ってます