Strata Data Conference in Londonで発表してきた
abstractやスライドは下記からたどれます。
https://conferences.oreilly.com/strata/strata-eu/public/schedule/detail/65222
一度はrejectされたCFPが2週間前になってacceptになったので慌てて準備して発表してきました。
20人ぐらいは来てくれたかな。発表直後には質問が出なくてちょっと寂しかったけど、その後いくつか質問くれたのでよかったです。
英語は正直まだかなり厳しいのですが、発表すると会話しやすくなっていいですね。しかも今回は最後とはいえ初日だったので明日の二日目が気楽です。
基調講演の印象だけ言うとプライバシーだったりGDPRだったりそういう方面にフォーカスが当たっているのかなと思いました。
ロンドンで現金、VISAカード盗難にあった
諸事情でロンドンに一人で来ていて現金、VISAカード盗難したのでメモっておく。
他の人が似たような状況にならないようになればと思います。
ロンドンは治安の良いところだと思っていたのですが、まあこういうことに遭遇してしまったので用心した方がいいですねという話です。
今回、現金とVISAカードを封筒に入れてそれをショルダーバッグの中において使っていました。外ではそれぐらいしか使わないだろうと思って日本で使ってた財布（中に日本円とか免許証とかがある）はホテルにおいてました。
で、気づいたらその封筒がなくなっていたというオチ。紛失の可能性もなきにしもあらずですが、地下鉄で盗られたのかなあと思ってます。ランチ食おうとしてレストランに入って注文した後に気づいた。食った後じゃなくてよかった。オイスターカードという日本でいうSuicaはあったのでホテルに帰ることはできました。
で、クレジットカードを止める必要があるわけですが、そのためのコミュニケーション手段は電話しかないです。
ただ僕の携帯からかけてもつながらず、ホテルの電話を借りてもうまくいかず、ロンドンのVJデスクにかけてそこで教えてもらった電話番号を何個か試してやっとつながりました。コレクトコールがうまくいかず直接、ホテルから日本に国際電話になりました。
三井住友の盗難受付デスクとロンドンのVJデスクの電話番号は下記にあります。
ロンドンのVJデスクは日本語OKですし、今回めんどくさい話を英語でホテルの人にしてもらいました。感謝。
https://www.smbc-card.com/mem/goriyo/kaigai_lost_list.jsp
https://www.smbc-card.com/mem/service/tra/pop/vj_london.jsp
後からわかったのですが、僕はLINE Mobileをつかっていてこれはデフォルトだと国際通話できません。オプション登録する必要があります。登録はwebからできて1日で完了しました。
なのでLINE Mobileユーザで海外に行くときはこのオプションを登録した方が良いと思います。
https://mobile.line.me/plan/option/
もしかしたらLINE Outなら通話できたのかも。
今回の件に関して、思ったのは海外においては電話という手段はネットと比べるとそこまであてにできないなということです。もちろんケースバイケースではありますが。
本人確認が必要だから電話が必要なんでしょうが、電話といっても公衆電話やホテルの電話もあれば携帯電話もあり、携帯電話もキャリアやMVNOによって微妙に差があるので、こうすれば絶対通話できるというものがない気がします。
ネットだったら繋がりさえすれば、デバイスに違いはそんなにないと思いますし、チャットでやりとりできた方が楽ですよねという。
ともあれ、クレジットカードを止めたはいいものの今後お金どうするんだという話ですが、結論から言うと僕はたまたま別途ソラチカカードを持っていてこれでATMから現金引き落とせました。
http://www.to-me-card.jp/campaign/tome_ana/
もしこれができなかったら、VISAカードを緊急発行して現地で受け取るしかなかったと思います。その場合でも3日ほどはかかりますが。なお僕の場合は日本円を持っていたのでそれをポンドに変えておきました。
そういうのが一切ない場合は、ホテルからなんとかしてお金借りてカードくるまで待つ以外の選択肢を思いつきません。あったら共有していただけたら嬉しいです。
ちなみにソラチカカードを作った理由は、私鉄で定期＋オートチャージしたいから以前作りました。
ソラチカカードはJCBベースで、JCBカードはぶっちゃけ海外ではほとんど使えないと思った方がいいと思います。
JCBプラザ・ロンドンに行って日本語で説明を聞きましたけど、少なくともロンドンで使える場所は限られているようです。
http://www.jcb.jp/ws/plaza/plaza_london.html
なのになんでATMでおろせたかというとソラチカカードがcirrus対応しているのでcirrusマークがあるATMなら、そこがJCB対応と書かれていなくてもキャッシングできるからです。LINE PayはJCBだけどICチップないのでNG
だらだら書いたのでまとめると、ひとりで海外行くときはクレジットカードは2枚持って別々に管理するべき、カードの種類はVISAとMasterがおそらく最強。LINE Mobileユーザは国際通話できるようにしておく、ですね。
あ、あと暗証番号は忘れないように。日本でクレジットカードの暗証番号入力することがあまりない方は忘れがちなので。
なんというか日本である程度シェアがあるけど海外ではほぼないサービスを使っていて海外でトラブルと厳しいですね。SPOFは避けて二重化大事という話でした。
石垣島へ行ってきた
石垣島へ一人旅してきました - wyukawa’s blog以来3年ぶり2回目の石垣島です。
5/1から6泊7日の旅です。今回はベストイン石垣島に泊まりました。
本当は前回止まったベッセルホテル石垣島にしたかったんですが予約取れず。
でもベストイン石垣島も良かったです。値段安いしコインランドリーあるし。ただ離島ターミナルまで行くとしたらバス使う必要があるのがちょっと面倒でした。
5/1に石垣空港に到着後、バスでホテルまで移動。今回はバス旅行メインかなと思って5日間で2000円乗り放題チケットを買いました。結果的にこれを使い倒した感じになりました。
バスの時刻表は路線バス案内 - 東運輸株式会社にありますし、バスアプリのNAVITIMEを使いつつ下記ブログを参考にしました。実際めっちゃ参考になりました。
バスで巡る石垣島１ 徒歩で巡る沖縄ぶらり紀行/ウェブリブログ
バスで巡る石垣島２ 徒歩で巡る沖縄ぶらり紀行/ウェブリブログ
ホテルに荷物預けた後すぐに平久保崎へ移動。
フリー乗降区間というのがあり、運転手にいうと、平久保と平野の間の灯台に一番近いところで降ろしてくれます。
降りた時点でだいたい17:10で、その後10分ほど歩くと灯台にたどり着きます。
その後戻ってきたバスに乗って玉取崎へ。平久保崎灯台での滞在時間は10分ほどですが、そんなに長期間滞在する必要もないと思いますし、おそらくこれが一番効率よく時間使えます。
18:19に玉取崎に着くので19:16のバスで帰ります。
5/2は川平湾へ
グラスボートにも乗りました。
5/3は唐人の墓へ
バスで戻って来夏世でランチ
来夏世 （くなつゆ） - 石垣市/沖縄そば [食べログ]
11時開店のちょっと前に行きましたがすでに並んでいました。
その後、鍾乳洞へ
5/4はバスで荒川まで行ってその後歩いてトミーのパンへ行ってパン買った後は米原へ
トミーのパン - 石垣市/パン [食べログ]
カレーパンとフランスパンを買った。どっちのパンもほどよく固くて美味しかった。
固すぎるのもダメだし、ふにゃふにゃなのもあんまり美味しくないけど良かった。あとカレーパンはちょっと辛かった。
その後、サビチ鍾乳洞へ。こちらもバスの運転手にサビチ鍾乳洞に一番近いところで降ろしてくださいと伝えます。
5/5は鳩間島へ。徒歩で島をぐるっとまわります。道もそんなに舗装されていないので自転車は使いづらいと思います。
5/6は御神崎へ
どうやって行ったかというと崎枝までバスで行ってそこからの5kmはランニングです。
徒歩だと時間かかり過ぎてバスの時間とうまく合わないので走りました。意外と暑くてアップダウンもあったのでちょっとバテた。
5/7は最終日で一旦空港へ行ってロッカーに荷物預けて白保へ
そして帰ってきました。
今回5/2から5/6の晩御飯はすべて島の食べものや南風 （しまのたべものや ぱいかじ） で食べました。
島の食べものや南風 （しまのたべものや ぱいかじ） - 石垣市/沖縄料理 [食べログ]
3年前も行ってうまかったので今回も行きましたが、前回以上に美味しかった気がします。
人気店なので予約したほうがいいです。
おすすめメニューは、カラッと揚げた島豆腐のにんにくじょうゆ、ラフティー、島らっきょう、ゴーヤチャンプルー、イカスミチャーハン、です。
掛川・新茶マラソンにいってきた
去年に続いて4回目の参加です。
掛川・新茶マラソンにいってきた - wyukawa’s blog
結果はネットタイムが4時間25分3秒でした。練習不足もあり30km以降失速。
坂もあったし、戦国汁、バナナ、メロン、いちご、オレンジを食べてたせいもある。
今回は腹減ってたのでさらに私設エイドで唐揚げ食った。ごちそうさまでした。
毎回思うけどこの大会は後半の坂があって結構きついです。。。
東京マラソン走ってきた
記録はネットタイムが3:56:57でした。
スタート前に二回トイレ行ったにもかかわらず、スタート待ってるうちに冷えてトイレ行きたくなり6kmあたりでトイレに行きました。まあそれがなかったとしても僕の自己ベスト3:48:00を更新するのは難しかったでしょう。
マラソンのタイムはここ数年停滞気味でシーズンで一回サブ4出せればいい方という感じです。サブ3.75はちょっと遠い。
それはともかく東京マラソンは運営がすごいちゃんとしてました。セキュリティも考慮してて、事前受付で顔写真取ってセキュリティバンドなるものを手に巻きます。これはレース後まで外したらだめで、これを使って選手はGATEに入場します。
どのGATEに入場するかも事前に決まっています。ゴール後の荷物受け取りもちょっと遠いんですが、場所が別れていて、混雑しないように動線をかなり意識している様子があります。
僕は出たことないですが、湘南国際マラソンはこの辺グダグダらしく人が混雑したり荷物受け取りも混乱があるようですが、東京マラソンはそういうのが一切なくすごくシステマティックに運営されていました。
まあそうでなければ3万6千人のランナーをセキュリティを考慮しつつさばけないよね。
欲を言えばスタート前のトイレ増やして欲しい。
コースも見所満載で、浅草寺、スカイツリー、東京タワーなどの名所を巡りつつ銀座のど真ん中を走れます。こりゃ他のマラソン大会が勝つのは難しいかも。。ただエイドの食べ物はバナナ、みかん、ミニトマトといったあたりで特色がなく、そこは他の大会、例えばしまだ大井川マラソンとか掛川新茶マラソンとか網走マラソンとかの方が上ですね。
Elasticsearch, Kibanaを5.6.2から6.1.2にupgradeした
といっても上書きupgradeじゃなくて新旧2つのElasticsearchにdouble writeして切り替えました。
うちの環境だとfluentd→kafka→kafka-fluentd-consumer→fluentd→Elasticsearchという経路でElasticsearchに書き込んでいます。
fluentdは0.12系を使っています。
kafkaが間にあるのでこの機会にmulti worker試したいなと思ってkafka以降の経路でfluentd 1を入れようとしたんですが、以下の理由から0.12を使いつづけています。
まあこれから試す人はfluentd 1で良い気はします。
fluentdのCPU使用率が上がった。
https://github.com/fluent/fluentd/issues/1801
もっともこの問題は現状解決されているはず。僕の環境ではすでに0.12で運用始まっているので試せてないですが。
fluent-plugin-record_modifierとfluent-plugin-prometheusがmulti worker未サポートだった。
prometheusに関してはもうサポートしたっぽい。https://github.com/fluent/fluent-plugin-prometheus/pull/44
record_modifierはfluentdのログを集めてきて下記のようにtagを書き換えるために使ってます。
<match fluent.**> @type record_modifier tag "fluentd" include_tag_key yes tag_key "loglevel" hostname ... portnum ... </match>
Elasticsearchのclient側の話としては、fluent-plugin-elasticsearchが依存しているelasticsearch-rubyに互換性が無いように見えたのでruby環境を完全に分けました。
https://github.com/elastic/elasticsearch-ruby
Java clientに関しては5.4でも6.1で動きました。
一部JavaScriptからElasticsearch APIをたたいているところがあって、そこはContent-Type指定が必要でした。
https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_rest_changes.html#_content_type_auto_detection
Elasticsearch本体側の話をすると、うちの環境ではindexというかshardが多すぎて日付が変わるタイミングでのindexingでエラーが出るので事前にバッチで翌日のindexを作るということをしていました。
ま、そもそもindex多すぎるのってどうなのっていうのをdiscussで聞いてみたらやっぱり減らせみたいな話になりました。
https://discuss.elastic.co/t/how-to-handle-many-indices/102803
そこでElasticsearch 5.4.2まではshard数をnode数にしてたんですが、それを変えて一部サイズが大きいindexに関しては1 shardがだいたい50GB以下になるようにshard数を指定して、それ以外はshard数を1にしました。
これにより今までは3万近くあったshardが2000ちょっとに減りました。
50GBという数字は
https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
を参考にしました。
TIP: Avoid having very large shards as this can negatively affect the cluster's ability to recover from failure. There is no fixed limit on how large shards can be, but a shard size of 50GB is often quoted as a limit that has been seen to work for a variety of use-cases.
あとmaster専用nodeを用意したところ、日付が変わるタイミングでのindexingでエラーが出なくなったのでバッチも減らせそうです。
今までは全nodeをmaster/data兼用にしてました。
ただmaster専用にするとcerebroに表示されないという問題があります。
Elasticsearch 5.4.2と6.1.2の違いですぐ気付いたのがindexのサイズです。
5.4.2の時は16億ドキュメントで4.2TBでしたが、6.1.2だと3.1TBに減っています。
その辺の改善はここが詳しそう
https://www.elastic.co/blog/minimize-index-storage-size-elasticsearch-6-0
他にもrestart時のrecoveryが早くなっている模様
この辺かな。https://www.elastic.co/blog/elasticsearch-sequence-ids-6-0
searchも早くなっているけど、まあ台数も倍なのでそれの影響が大きいはず。
とはいえ性能改善も入っている模様
https://www.elastic.co/blog/index-sorting-elasticsearch-6-0
他にはCPU使用率のばらつきが減ってますね。
kibanaに関してはindex patternをバッチで作っている部分があって、そこはkibanaのAPIを使うように変更しました。
https://github.com/elastic/kibana/issues/3709
