Groongaで学ぶ全文検索 2016-01-15に参加した

Groongaで学ぶ全文検索 2016-01-15 - Groonga | Doorkeeper

という勉強会に参加した。

groonga.doorkeeper.jp

このポストはこの勉強会の方針に基づき書いている。

この勉強会では準備をしない。
予習、復習をしない方針。
この場でまとまった知識を共有し合う方針。
以下、昨日聞いた事を書き留めた。（あまりまとまってはいない。）
この記事を書いた時は昨日2016年1月16日で同席したみなさんにはサラッとお見せした。
一つの内容を複数の人が書いているので他の方のブログが読みやすいと思う。

要約としては以下になる。

全般的にRDBMSと違って、全文検索はトランザクション機能を有するものが少なく、データロストにどのように対応するかという事。
groongaは他のRDBMSより書き込みが早い。（早い理由はデータ圧縮などをしているとのこと。）
mroongaではmysqlのレプケーションを利用して、データの損失に備えている。
mroonga自体にはレプケーション機能はないとの事。

---

RDBMSの信頼性について
最終的にはディスクは壊れる。
　壊れる種類
　　論理的に壊れる
　　物理的に壊れる
物理的にディスクが壊れた場合はデータは助からない。

RDBMSはトランザクションによって、論理的にデータが壊れることを防いでいる。
運用ではコピーを取ることが必須。
　コピーは同時に壊れる確率を下げる。
　コピーをすれば費用がかかる。

1台のサーバでサービス運用をするのは無理があるので複数台で運用する。

mroongaの話
　全文検索製品ではトランザクションに対応したものが少ない。（理由は難しいなど）　よって、RDBMSに比べ全文のDBは論理的に壊れる可能性が高い。

対策
　バックアップをとっておくというやり方
　途中のデータは捨てる。というやり方
　普通のやり方はマスターデータをキープするやり方。
　マスターデータから復旧するには何かしらのデータを足す。
　（差分バックアップを足すなどの方法。）

全文検索はデータを足すという方法をとっている。
　復旧するにはダウンタイムとのトレードオフ
　0から作り直すのは時間かかる。

対策として複数のサーバ間でコピーをする。
サーバ間のコピーでも遅延がある。（replication遅延）
　クライアントからのクエリ発行数に対して、レプケーションのセッションが1つしかなく遅れる。
　今のmysqlは、セッションが複数張れて改善されている。

RDBMSのトランザクションは大きいと(commitまでのクエリが多数発行されると)、レプケーション遅延が発生する場合がある。

groongaは他のRDBMSより書き込みが早い。
　mysqlのreplicationを利用してgroongaは書き込みしている。
　InnoDBがマスターDBとして機能してスレーブにコピーができる。
　検索だけはスレーブ側に発行する。

データの格納方法について
　mroongaはデータとインデックスをに入れる
　pgroogaはデータだけpostgresに入れて、 groongaがインデックスを持つ。

運用上の注意点
　1マスタ2スレーブの構成の際スレーブへのアクセスが少ないからと言って、スレーブ側にも書き込みしてはならない。
　mroongaは1マスター2スレーブ構成も出来る。
　mroongaは強制終了しなければデータは壊れない。

今日知り得た知識
　全文検索エンジンは検索時は書き込みしない。（ものが多い）

　書き込みが都度発生してかつ、全文検索する場合はやはりKVSなどのものがいいのではないか。

とここまで書いて、ブログを発表しあった際、正しくないと御指摘いただいた。

違うらしい、groongaはカラムベースのロックで、書き込みロックとなっている。
（さらに書き込みリクエスト毎にこまかな制御をされているのだと推測する。）
参照される情報は新しい方が良いという設計方針のため、書き込みが多くても検索には支障がない。
情報の書き込みがあっても、検索のQueryを発行しても問題がないとの事です。

須藤さんから説明いただいた。
ありがとうございました。

---

この様に人の話を聞いて、理解した内容を文章に起こしその場で発表するという画期的な勉強会でした。

須藤さんは物腰が柔らかい印象な方で、丁寧に解説いただけた。

この会では最初に参加者が疑問に思っている事を聞いて、興味を持っている内容を須藤さんから話ていただいている。

あと、自分は早めに会場についてしまって、1つ質問をしました。

「mroongaのMariaDB対応について」

デフォルトでバンドルされているとの事でした。

これは自分が無知で無礼な質問であったかも知れません。
この場でお詫び申し上げます。

デフォルトで入っているならば直ぐに試せるので非常にありがたい。

このMariaDBにデフォルトでmroongaがバンドルされているという事は大きく知らせた方がいいのではと思う。
（自分はmysqlの話を聞いている傾向があってMariaDBの話にあまり関心がないからかも知れない。）

参考までに須藤さんの活躍の記事があったのでリンクを貼っておきます。

enterprisezine.jp

Akamai Conference 2015 参加レポート1

6/11 Akamai Conference 2015 に参加した。

丁度、Interop Tokyo 2015 と同日開催で気になった方もいるのではと思う。

（明らかにInterrop帰りでロゴ入り手提げ袋を持った来場者もいらした。）

akamaiというとSDN事業社でどの様なサービスなのか契約しないとわかりにくい。
機能としては理解していても、なかなか情報が得られないので参加した次第。

開催概要
日時 2015年6月11日（木）13:15～20:30（プレセッション12：15～13：00）
会場 ザ・プリンス パークタワー東京

道に迷ってしまった事もあり、プレセッセッションはほぼ不参加。

6/22に動画や資料は後日公開される様なので詳しくはそちらを見ていただいた方が正確でいいと思う。

私の様ないわゆるSIerに勤めた経験もない者が大規模エンタープライズで必要とされるサービスについて正しく理解して書ける訳でないので、このポストの内容については期待しないでいただきたい。

まだ、公開まで日数がかかるので、一部参加したセッションのメモを修正して公開した次第。

なお、会期中の写真撮影、動画の記録、録音は禁止されていた。

---

15:10-15:45

「大規模コンテンツ配信とITガバナンス強化に向けての取り組み～グローバル展開の加速～」
株式会社スクウェア・エニックス
執行役員　第11・12ビジネス・ディビジョン 情報システム部
西角 浩一 氏

骨子

• 担当している事業規模
• 株式会社スクウェア・エニックスとはどの様な事業を手がけているか。
  　akamaiの利点
• マネージメントの話。

まずスクエアエニックスとはどの様な会社か。
言わずとしれたエンターテインメント事業者ではあっても、来場者向けに紹介。
ゲーム、出版、グループ企業による遊戯施設の経営等の事業。
欧米ではドラゴンクエストよりFFの方が認識が率が高い印象。
空港での海外の方にスクウェア・エニックスを説明した時の御経験談

西角 浩一 氏の経歴
（※詳細失念）
マッキンゼー・アンド・カンパニー
シスコ
dip http://www.dip-net.co.jp
　等を歴任

100人規模の開発者向けサービスを手がけている。
情報システム部ではあっても、商用システム部門と遜色ないといっても過言ではない規模のサービスを自社で運用している。

• 担当している事業規模

以下、おおよその要求。
・サーバ
秒間10万リクエストを必要としている。
　1システム1.5T
・ネットワーク
　BGP 130 pear
　ゲームという特質上、1ms-2ms遅延しか許されない。（MMO等の動画配信ということだと思う。）
　オフィスフロア幹線　100-200Gbps
・ストレージ
　数ペタ
　ゲノム解析等も行っている
・クライアントPC
100GbpsオールSSD化済み
（一般的な企業の情報システム部門とはスケール感が異なると感じました。）

• 株式会社スクウェア・エニックスとはどの様な事業を手がけているか。

スクエアエニックスはグローバル企業でデジタルコンテンツありきの会社。
世界で配信する上での経営課題
（同一タイトルを同時リリースという事なのだろうと思う。）
2002年から世界展開でゲーム配信をしている。
MMOは2010年頃からの配信

　akamaiの利点
　　コストメリットある。
　　扱いやすい。
　　セキュリティなどニーズにマッチしていた。
　　静的ファイル配信とパッチ配信サーバとしてakamaiを利用している。

1ゲームで1Gから数十Gのデータを配信している
スクエアエニックスではコアゲーマ向けのゲームを取り扱っている。
（配信容量が大きくなりがちなのだろう）
ゲームを配信するにあたって、お客様の回線が必ずしもよくない状況がある。

具体的なタイトルで配信例
戦国IXA（他、失念と割愛）
映像サイズは小さいが安定配信が難しい

過去MMO配信でどの程度の負荷があったか。
世界展開しているので、サービススタート時にダウンロードのスパイクある。
自社のインフラだけでは突発的でさばく事が難しい。
他、ソーシャルゲームのレスポンスを上げる為にakamai社と検討中。

全世界のオペレーションを日本から行ってる。
理由としては、グローバルで展開しているので、セキュリティやゲームの運用ポリシーが国地域毎で違うと困る

• マネージメントの話

スクエアエニックスはグローバル企業ではあるが、もともと海外の関連会社は違う会社だった。
2009年より考え方も違う会社とメールを同じにする。
（おそらくドメイン名等もバラバラだったのかも知れない。）
地道に統合作業を行っていった。
北米DCにて現地の方との作業。
日本人を2年派遣した。
6-7年の期間を要した。
（メールという事では無くゲーム配信の為のインフラ構築の話だと記憶）
仕事に関する根本的な姿勢が欧米と異なる。
外国人の特徴
　効率化の為の作業をする。
　繁忙期でも残業しないのが外人
　報連相はない
　ただし、組織の上下関係は欧米人の方の方が守る。
マッキンゼーで得たロジックは外国人の部下には受け入れられやすかった。

---

懇親会で聞いた話
あまりにも事業規模が大きいので競合他社がないのではと思ったので質問した。
DNSだけで言えばamazon route53が思いつくが、rack spaceが顧客として挙げられていて主軸としているビジネスがわかりにくい。

　Q、競合他社としては何処になるのか。
　A、セキュリティ製品で言えばF5等が挙げられるが完全に競合という事業社はない。

　Q、rack spaceと協業しているのであれば最初からクラウドサーバ上にCDNを設けるサービス等を出さないものか。

　A、出す予定は無い。

　以下会話の内容を整理して書くと、cisco製品等にも組み込まれていて、サーバやサービスに組み込むというより、端末側にアプリケーションを置くといった事でダウンロード速度を上げるといった事を事業として手がけている。

その場で話した訳ではないが、よくよく思い出してみると、oracleのいくつかのソフトウェア製品をダウンロードする際にakamai製のダウンローダーを使った事がある。
つまり、ただ単純にサーバー側に大規模な製品を投入するわけでは無く、インターネットとしてスピードが出せる位置の製品開発を行っている。
最高経営責任者Tom Leighton氏のkeynoteでも聞いたが、よく言われる ラストワンマイル - Wikipedia の問題解決をした方が効率がいいのだろう。

Twitter Flock Tokyo 2015 参加レポート 1 Digits: A Better Way to Loginについて

Twitter Flock Tokyo 2015
という開発者向けの会議に参加した。

その中の講演の一つについて書いてみる。
同時通訳の日本語をそれなりに咀嚼して書いているので情報として劣化している恐れがある。

（好評であれば他の講演も書き起こしてみたい。）
誤りがあれば教えていただきたい。

Digits: A Better Way to Login
15:20 - 15:50
Romain Huet (@romainhuet) | Twitter 氏

digitsについて
http://get.digits.com/

世界はスマホの世の中となっている
3億台の端末が北米でリリースされる。
今年12億4千万台のモバイル端末が売られる。
アイデンティティの選択肢が多くて複雑になってしまう。
みんなが持っているのは電話番号。
電話番号で認証する事でシンプルになる。

では何故電話番号はなぜ認証に使われなかったのか？
SMSサービスが行われる順番
モバイルアプリ->SMS->SMSアグリケータ->電話会社 (GMOBILEやairtel)
860のオペレータ（電話会社？）がある。
アプリそれぞれでSMSアグリケータへのバックエンドに対応する必要がある。
（860社の電話会社を一環してサポートする認証基盤というのは実質作れない。）
認証基盤の構築には費用がかかる。

100万認証の価格は各国によって費用が異なる。
US $50,0000
ブラジル $5,000
ユーザが認証画面から電話番号を入力した後、SMSが送られる。
（このユーザに対するSMS送信の費用をtwitter社で費用負担しているらしい。）

Digitsそのものはソーシャルアカウントではない。
(おそらく認証させてそのまま使うという事ではなく一度SMSによる認証が行われるという意味だと思う。)

国とオペレータが変わっても認証出来る。
Digitsは属性を拡張できる。（例えば名前等の追加）
Digitsの認証画面は表示色をカスタマイズできる。
アピアランスの変更ができる。
メッセージのローカライズできる。
受け取った側の国によってメッセージを変更してユーザの使っている言語に合わせられる。
Androidでは1タップログイン可能となっている。
（たぶんアプリ内で自端末の電話番号が取得できるのだろう。筆者推測）
javascriptでwebアプリログインにも連動出来る。
216カ国 28言語対応

digitsのアップデート情報
　digits.comを開設した
　ここでユーザ自信がアカウントマネージメント出来る。
　セキュリティをユーザが変更出来る。

講演とは別に会場にいたtwitter社のエンジニアに質問してみた。

digitsで認証済みの携帯なくしたらどうするのか聞いた。

今は携帯番号が同じなら同一アカウントに出来る。

違う番号しか用意できなかった場合、同一アカウントにする仕組みは開発中との事。

時期は未定。

下は会場の写真。

#morisnite vol.2 とは

おととい2015年2月6日
#morisnite vol.2
というエンジニアが多く集まる、🍺を消化する会が行われました。
会場を提供くださいました、株式会社フリークアウト様ありがとうございました。
ささやかながら、お礼としてブログに書くことで多少なれとも社会的認識が上がれば幸いかと。

みなさん #morisnite の感想とかブログに書いてほしいです

— まいんだー (@myfinder) 2015, 2月 6

詳細はこちら
http://connpass.com/event/11600/

で、参加動機としては、エンジニアとの交流エンジニア狩り狩りを目的としていました。 というのは、さておき

オンプレ環境でがっつりあれこれやっていたので、クラウドサービス上で事業を展開するところで働きたいなあ、と思っています。

とあったので、じゃあ何処がいいの？と思って聞ききに行ければと思いました。

http://tagomoris.hatenablog.com/

参加者心得？
　大人の節度を忘れず少年のように楽しみましょう。

いい大人が手ぶらで飲みに行くのもなんだから、さっと食べられるプチトマトを成城石井で購入。

大きな地図で見る
あと、お酒を飲み疲れたら水が飲みたくなるという知見をtokyurubykaigiというイベントで得たので、2リッターのペットボトルの水を1本持って行きました。
パーティーにはリッツが欠かせないのでと思いきやシンプルなタイプはなかったので、チーズが挟まったタイプを購入

今度ここにくる方の参考になればと思います。
適度に飲食物を持ち込みたいといったケースに有効。
会場入りする前に食材を持って移動するのはつらいので。

あと、料理ガチな方は料理持ち込みされていらして、唐揚げ作って持って来た。（私が1つ美味しく頂きました。醤油ベースの味で旨い。しょっぱすぎず鳥肉の味がジューシー）
生ハム原木の持ち込みされる方もいらした。（旨い。旨すぎる。）

#morisnite vol.2
式次
　（遅刻参加したので、挨拶は知らない。）
・しゃべりたい人が喋る。
・飲みたいだけ飲む。
・バスケットゴールが１つあるのでシュートをする。


自分は何度かお会いした事のある方と以下の様な事を話した。
皆さんの同意を得ていないので、誰と話したかは一旦伏せておこう。

・自分の所属している会社のアレがアレの件。深入りした場合はそれだけになってしまうんでは？(例:mysqlおじさん）
・近所の図書館の蔵書は技術書が多く最高。その後オススメした方が図書カードを作ったのかを確認。
・過去に自作サーバ同窓会という物が行われたが卒業した方はまたハードウェアに手を出すのか？または出さないのか？
　昨今、facebookがハードウェアを開発していたりする状況を鑑みるとまた自作サーバブームはくるのか？
・crossでアンカンファレンスをしたらエンジニアの知り合い増えたかどうか。また誕生日にatnd建てたらどーか。

あと一番の収穫はあのクラウドのサービスで期待されているものがとても素晴らしい。
詳しくはハッシュタグを検索。乞うご期待。

エンジニア飲み素晴らしい。
そこそこ協調して、食べ物持参、酒持参。
毎回では準備に疲れてしまうだろうから、たまにはいい。

次の日、
dots. Summit 2015 - ドッツサミット #dotssummit
http://eventdots.jp/event/309318
が開催されるが、お構いなしに飲んでいた。
こんな事を寛大に容認していただける事業社はなかなか他にない。

たまたま話しかけた方が中の人で人事に関わる方で、今日の会場撤収と、次の日のイベント開催の為に開場を担当されるとの事だった。
本当にお疲れ様です。

酔っ払いどもの陣頭指揮をして、会場の片付けを進行してくださいました、@myfinder 氏ありがとうございます。

あと、オリーブの実を買った方。
私は好きなのでばくばく食べましたが、量が多く余っていましたよ。
私の持ち込んだプチトマトも余ったな。
自分が食べる分＋ちょっとでも皆が集まると、そのちょっとが多くなる。
乾パンとかも1缶あまっていたので、私がもらいました。

次回の🍺送り先は会場へ直接がいいのでは。
@tagomoris さんお疲れ様でした。

#isucon で優勝ビリとりました。

ブログに技術的な事以外書きたくないのですが、本件については書かなければならないでしょう。

という事で、つまらないタイトルでpostした通り#isuconに参加しました。

あの日何を考え参加したのか、思い出しながら書いてみます。

くわしい技術的な事は、他の方が沢山書いてくれているので、いまさら詳しく書くこともないでしょう。

当日の方針等は一応考えて参加しました。

一人で参加したので、簡単な事はさっさと済ませて、効果がなければ深追いせず、一つでも効果があれば儲けもの。効果がなければ次の策。時間が余ればじっくり取り組むといった方針で挑みました。

あまり事前調査や予習をしても自分本来の力ではありませんし、むしろドタバタした感じで自分がどこまでやれるのか試してみたいという心情でありました。

実際には次のような方針

環境はちょいちょい整えるが、こだわる時間もないから、screen、ngrepだけはインストールしよう。

（yumで簡単に終わらせる。ngrepはソースからでも簡単にインストール）

apacheはさっくりnginxへ変更

（これにはまった。）

mod_pagespeedをインストール

（結構前に話題になったけど今はあまり聞かない。誰も覚えていないんじゃないかという淡い期待）

mysqlはHandlerSocketで高速化

（参照だけでも早くなればいいんじゃないか。ここに時間をかけよう）

でまぁ当日。

phpによる実装ないじゃん。

これは痛かった。

自分は普段プログラムを書かないので、言語の事はさっぱりな訳で。

ましてや会社で使ってない、node.jsやrubyとか無理なんですよ。

ま実際出来たとしても、あのメンバーに勝ち得る訳ない。（←ここ後ほど重要。）

この段階で心半分以上折れました。orz

とまぁぼやいても始まらないので、nginxにしようと。

で他の方が書いてらっしゃる@kazebroさんの罠にまんまとはまりました。

ngrep入れたのだからちゃんと見ればよかった。

（↑実際そんな精神的余裕が持てませんでした。）

フロントはapacheでappサーバ2台にリバースプロクシーでリクエストを渡しているだけ。

↑ここに対してもはまった。

nginxのリバースープロクシー書くにしても数行で済む設定なので、間違う訳ない。

と思って、設定ファイルを穴が開くほど見直し。

でもよくわかんらん。何がわるいか。

設定書き間違えたかな？そん訳ないよな？ひさびさにビルドするから何か不足があるのか？いやpcreは入れたしな。

とかなり自問自答。

実際当日のプロクシー設定はIPアドレス指定によるものだったのだが、ここが悪いのか？

まぁphpじゃないんだからやることやるしか無いよな。

と思いhost名を指定。

やはりsyntaxミス？

nginx -tによる構文チェックとかすっかり忘れていたので、nginx再起動を繰り返す。再起動なので余計に時間がかかる。

やっぱり、わからない。
これは何か細工があるなと推測。一人なので出来ることは少ないんだし深追いはしない方針なのでスルー。
だいたいリバースプロクシーしかしてないんだから、ものすごい改善にはならない。

あきらめて、mysqlを見てみる。（この時点で13時は過ぎていたはず。）

クエリはngrepを使ったか余り思い出せないが、問題のSQLは簡単にわかった。
ただしこれをどうやってruby等に組み込めるか？
rubyのソースはクエリがまとまっていて見やすい。


ただ、いろいろあるクエリーの一つや一部だけポート番号を変えて、HandlerSocketにアクセスする文法がわからない。（おちついて考えれば変数上書きすればいいだけのはず。）
だいたい今日9/6に知ったことだけど、DESCとかコーディングで頑張るのが辛い。

あと座席の都合でmysqlに詳しい方が目に入る。
この方がいる場所でチューニングしても太刀打ちできないしなぁ。とも思う。


という訳であきらめapacheのmod_pagespeedをインストール。
あっさり入るが予習した訳ではないので、設定ファイルの項目や効果がわからない。
でも待てよ、画像やjsファイルが少ないんでそもそも効果が少ないんじゃ。。？

以下apacheに手を入れるかmysqlまわりに手を入れるか、ちょっと調べて挫折。
これを繰り返していた。


という事を15:00までやってた気がする。
何もできないから、mysqlのバージョンでも上げよう。
rpmでインストールされていて見慣れた感じ。
いくつかrpmを取得してインストールできたが、upgradeとかまともにやった事がないので、時間切れ。
無念。


で反省点。
他のメンバーにとらわれず自分の出来ることを着実にやればよかったと。
少しでも成果があればいいじゃないか。そもそも一人なんだし勝てる訳がない。
といまだ後悔しております。


でも良い思い出になりました。
ひさびさに、難題を与えられて苦労したりするシュチュエーションを思い出しました。
ものすごい、いい意味でのプレッシャー等感じました。


会場の様子など思い出した事と言えば、無線LANが切れると一斉にやる事が無くなるので強制休憩w。
自分は途中でPocketWifiにしてしまいました。
また笑えるのが、競技中と懇親会での落差。
懇親会、京都に帰る方々除いてほぼほぼ全員参加というのもイベントとしては珍しい。
皆さんかなり盛り上がってましたからね。
自分はよく読むブログの半袖さんや、主催の方といろいろ話して、ブログ記事に書いてある事のちょっとした疑問等が晴れました。


こんな楽しい時間を提供してくださった、運営の方々には非常に感謝しております。
参加者も凄腕の方が集まり楽しませていただきました。
熱かった。勉強会でもなんでもそうだけど一過性のブームで終わって欲しくないと思いました。
この熱さが後世というほどでもないけど、何年も続けば嬉しい。
ぜひwikiぺディアに残したい。#ISUCON。誰か書いて（というか自分がこっそり書けばいいか。）


次は見るだけ枠の人の為に、screenコマンドでwatch -n 1 pstreeとかした結果が延々写るモニター等があったらうれしいと思いました。
まぁpsとかでもいいけど。それだけ見てニヤニヤする人専用の部屋（というかパーテーションでも可）があればサーバ台数用意しなくても見学だけもかなり盛り上がる。（俺的には絶対盛り上がる。）


という事で次回類似イベント、10/1に参加します。
今日別のイベントでお会いした方も出場されるようなのでまた楽しみです。
今度は着実に出来る事をやろうと思う次第。

こんな駄文を最後まで読んでくれた方ありがとうございます。