YAPC::Fukuokaにカヤックのエンジニアが登壇します!

技術部ブログ編集委員の長田です。

3月に行われたYAPC::Kansai 2017 OSAKAに続き、 7月1日に開催されるYAPC::Fukuoka 2017 HAKATAでも弊社社員が登壇することになりました。

トーク内容をプロポーザルの抜粋にてご紹介します。 いずれもカヤックの仕事から生まれたノウハウが詰まった内容となっています。

分散ユニークID採番機katsubushiとWebアプリケーションへの応用例

by 藤原

http://yapcjapan.org/2017fukuoka/talks.html#/detail/13

面白法人カヤックでは、自社で開発したOSSの分散ユニークID採番機 katsubushi を Webアプリケーションの様々な場面で利用しています。

本トークでは、katsubushi の機能、利用方法、 Perl / Go で記述されたWebアプリケーションへの応用、 コンテナ環境での運用方法などについて紹介します。

katsubushiについては以前このブログでも紹介しているので、さらっと目を通しておくとトークの理解が早いかもしれません。

techblog.kayac.com

巨大Perlプロジェクトに、Dockerが出会った

by 川添

http://yapcjapan.org/2017fukuoka/talks.html#/detail/36

もはや未来の技術というより普遍的な技術になりつつあるコンテナ、Dockerですが、 みなさんPerlのプロジェクトで活用されていますでしょうか?

このトークでは、筆者がDockerをPerlのプロジェクトに導入していくにあたってどう活用しているかという話をします。

ちなみにDockerについては以前、技術評論社のSoftware Designに登壇者である川添と矢吹が共著で寄稿しています。

gihyo.jp

スキップしていいテスト、スキップしてはいけないテスト 〜速さと信頼を兼ねたテストコードを構築する術〜

by 谷脇

http://yapcjapan.org/2017fukuoka/talks.html#/detail/3

このトークでは、未来へ継続していくWebサービスアプリケーションを開発・運用する上で あえて テストをスキップする話や、テストを高速化する技法、決め事、書き方などについて 私や一緒に働いているチームのメンバーが考えたことについて話していきます。

まこぴーです。

おわり

登壇者以外にも参加者はいますので、トークでカヤックに興味を持っていただけた方は 懇親会などで話しかけていただければ幸いです。

ちなみにこの記事を書いている長田は諸々の事情により参加できません。悲しい。 福岡・・・おいしそうですね・・・。

カヤックでは明太子好きなエンジニアも募集しています!

関連記事

techblog.kayac.com

ゼロから始めるRails位置ゲーサーバ(その1)

こんにちは。クライアントチームサーバサイドエンジニア、コウです。最近、 Rails で位置ゲーのサーバサイドを実装しました。
なので、 Rails で位置ゲーサーバの実装方法について、3つの Part に分けて紹介させていただきます。

ポーリング API で、スマホのリアルタイム位置情報にもとづいて、何キロ範囲内の全てのマーカーデータをデータベースからとるには、いくつの実装方法があります。

Geohash

最初におすすめされたのは Geohash です。
Geohash は経緯度に基づくジオコーディング方法の一つです。
Geohash の gem を使えば、データベースは MySQL のままでも、実装できます。
でも、 Geohash の gem が大分古かったので、使えるかどうか試しませんでした。
なぜなら、もっと簡単な方法があるからです!

Geohashに興味のある方は、杉山さんの記事「サーバーで付近の情報を通知するサービスのつくり方」がおすすめです。

ElasticSearch

ElasticSearch はオープンソース全文検索エンジンです。
ElasticSearch はリアルタイム位置情報検索が得意だそうです。
あまり詳しくないので、今回はスルーさせてください。
なので、ElasticSearch Geolocation のドキュメント URL だけを貼りますね。

RedisとMongoDB

Redis 3.2 から Geo メソッドがいくつか追加されました。 Sorted Set で Geo 検索できます。2016年にリリースされたばかりなので、使った例がおおくないです。
リアルタイム位置情報のアップデートとセレクトが多い場合、MongoDB の Geospatial がよく使われています。スピードがかなり速いです。
でも今回のマーカーデータは全部事前に登録できる上に、リレーションデータもあります。
MongoDB を使うメリットはそんなに大きくないです。

MySQL Spatial Data

そういうわけで、もう既に MySQL をインストールしたので、 MySQL のSpatial Data についても調べました。
最初は、 MySQL の Spatial Data がいいと思いました。
インデックスも付けられるし、点と点の間の距離計算できます。
だけど!
「ユーザーから N キロメートル範囲内の全てのマーカーを取り出す」という簡単なことができるけど!
SELECT文が(私にとって)かなりわかりづらいです。

SELECT
    *, (
      6371 * acos (
      cos ( radians(78.3232) )
      * cos( radians( lat ) )
      * cos( radians( lng ) - radians(65.3234) )
      + sin ( radians(78.3232) )
      * sin( radians( lat ) )
    )
) AS distance
FROM markers
HAVING distance < 10
ORDER BY distance;

ref: stackoverflow (英語, published at 2014/02/18)

SET @user = ST_GeomFromText('POINT(139.777254 35.713768)');
SELECT *, ST_Distance_Sphere(@user, lonlat) AS distance
    FROM markers
    WHERE ST_Distance_Sphere(@user, lonlat) <= 10000
    AND ST_Within(
      lonlat,
      ST_Buffer(@user, DEGREES(300/(6370986*COS(RADIANS(ST_Y(@user))))),
      ST_Buffer_Strategy('point_square'))
    )
    ORDER BY distance;

ref: Shogo’s Blog (日本語, published at 2017/03/28)

sin cos acos radians が多くないでしょうか?
6371 は何の数字でしょうか?
ST_Distance_Sphere は遅い、Geometry 型しか使えないことも記事に書いてあります。
そんなこと思いつつ、別の解決方法を探り始めました。

PostgreSQL の PostGIS

「世界で最も人気なオープンソースデータベース」の MySQL から離れて、 ようやく、「世界で最も先進的なオープンソースのデータベース」の PostgreSQL までたどり着きました。 簡単に PostgreSQL + PostGIS のメリットを紹介しましょう。

  • リレーションデータベース
  • ドキュメント ( HTML / PDF / EPUB ) が完璧
  • PostGIS の使いやすさ (Geography 対応)
  • RDS の PostgreSQL に PostGIS のイクステンションがあらかじめインストールされている
  • ActiveRecord 専用 gem activerecord-postgis-adapter あり、その上、ずっとメンテナンスされている
  • 何よりセレクトが速い!!!

ベンチマークの数字からPostGISの性能のよさを証明しましょう。
下記は「railsでユーザーの緯度経度から10キロ以内のレコードを取り出して、距離でオーダーする」のセレクト文のベンチマークです:

User
  .select("users.*, st_distance(location, 'point(116.458104 39.966293)') as distance")
  .where("st_dwithin(location, 'point(116.458104 39.966293)', 10000)")
  .order("distance")
レコード件数 10w 20w 50w 100w 260w 1000w
かかった秒数 1.2ms 1.4ms 1.8ms 2.5ms 4.2ms 15.3ms

ref: Ruby China #22059 (中国語, published at 2014/10/15)

もう一度いいます!
何よりセレクトが速いです!

結論

なので、今回の仕様に一番ぴったりな解決方法は、 PostgreSQL の PostGIS で実装することでした。
めでたし〜めでたし〜

次回の Part 2 で、 上記にも出てた謎な英単語 「 Geography 」、 と「 Geometry 」について、簡単に話します。
お楽しみにしてください〜(<ゝω・)☆


(/・ω・)/ ★☆★☆★ サーバサイドエンジニア大絶賛募集中 ★☆★☆★ \(・ω・\)