9月9日、シナジーカフェ GMO Yoursにて『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』出版記念！執筆者が語る大講演会！が開催されました。前編のセッション編のレポートに続き、このイベントの模様をレポートします。
特別パネルディスカッション
休憩をはさみ、発表した鈴木健太氏、吉田健太郎氏、大谷純氏、道井俊介氏と、モデレータの伊藤直也氏を交えたパネルディスカッションが行われました。
著者陣の仕事はサーバインフラエンジニア？
伊藤直也氏
伊藤：トレジャーデータの太田さんからモデレータの依頼があり、ここにいます。さて、本書の書名は『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』ですが、皆さん、サーバインフラエンジニアですか？
全員：はい。
道井俊介氏
道井：メインはインフラ、息抜きでログの仕事をしています。最近はサーバのパフォーマンスの可視化もし始めました。
伊藤：なぜこの質問をしたかと言うと、そもそもログ収集はインフラエンジニアの業務範囲なのかを聞きたくて。世間一般の認識はどうですか？
鈴木健太氏
鈴木：先のセッションで権限があったから入れましたという話が挙がっていましたが、インフラエンジニアだから入れられるというのは結構あると思います。
道井：インフラエンジニアは基本どこのサーバでもSSHログインできるため、勝手にFluentdを入れて、勝手にログをもってくることができます。
伊藤：待って、この話はあまり一般的でないと思う（会場：笑）
吉田健太郎氏
吉田：僕の会社も同じような感じです。2、3年前に、ログ解析やクエリログの収集をしたくなり、トレジャーデータのFluentdが良さそうだというのが分かりました。木曜にメールをして、翌月曜には全台にデプロイが完了していました。
伊藤：それはインフラエンジニアとしての業務にあたっていたんですか？
吉田：趣味です。
伊藤：なぜ、皆さん趣味でやってるんですか（苦笑）
鈴木：僕はもともとはサーバサイドエンジニアで、インフラエンジニアの人にFluentdを入れるかどうかを聞きました。いまは菅理APIを作ったり、Elasticsearchの面倒をみていたりしています。やはり許可がいらないというのがあるので、とりあえず入れてしまうというのがありますね。
ログ解析の仕事は片手間にやれる？
伊藤：ログ収集エンジニアといっても、業務側の知識が必要ですよね？ つまり、エンジニア以外の人がどういうデータを見たいのか、必要なデータをヒアリングしないといけないとか。そういうことをやりはじめると、インフラエンジニアをしながら、片手間にログエンジニアをするのは難しいと思いますが、そのあたりはどうですか？
道井：そうですね、時間的には厳しいですね。ただ、pixivではフルタイムで作業するグロースチームがあります。そして、自分を含めインフラエンジニアは何をしても許されているというか、いろいろなことをしています。そういう状況で、自分のタスクの進み具合を見ながら、空き時間にそちらを手伝う感じですね。
大谷純氏
大谷：そのチームがどういうデータがほしいとか、どう入れるべきだというのは設計してくれるんですか？ それとも相談しながら？
道井：どうですかね。ふらっと行って、こういうのはどうですか？という感じです。
鈴木：Elasticsearchが楽なのはログを入れたらきちんと出してくれるところなので、まずはタイムスタンプだけあれば良いみたいなところがあります。
道井：Elasticsearchを入れていると、他の使い方を始めてくれるというのがあります。
伊藤：たしかに。その発想から行くと、インフラエンジニアの人が始めるってのはありますね。
大谷：中に入れておけば、誰か見てくれるし、誰か触ってくれるだろうと。その敷居を下げているのが良いですね。
伊藤：僕が昔、ソーシャルゲームの会社にいた時には、ログエンジニアと言うのが明確にいて、ログだけやっていました。そして、ゲームを作ってるチームから生ログを見たいという声に答えていました。それこそ便利なHadoopクラスタなどがない時代から行っていて、ファイルサイズがとても大きく、力技で対応していました。そのため、1、2人は張りついていないとできなくて、インフラとは違うスキルセットが必要でした。
大谷：その点はゲーム業界がやや特殊で、ユーザの動きを見て課金につなげなくてはいけないのかなと思います。
EFKの導入前はどうしてた？
伊藤：そうそう。話が順番が前後してしまうけど、そもそもEFK（Elasticsearch, Fluentd, Kibana）スタックがない頃はどうしてましたか？
吉田：EFKの前はFluentdとGrowthForecastを使って可視化をしていました。デプロイ直後は500エラーが増えたり、レスポンスタイムが劣化したりすることがあると言われますが、ログをtailで眺めていても全然分かりません。アプリエンジニアに気づいてもらいたくて。
伊藤：今回、話が2つあると思っていて、エラーやレスポンスタイムなどのシステムモニタリングの話と、ECサイトの購買数やアクティブユーザの数などのビジネス側の話です。いまのはモニタリングの話で、モニタリングは昔からいろいろあったと思うのですが、DAUを計算するとか、どうしてコンバージョンしたのかなどは、どのように調べていましたか？
道井：pixivでは2年ほど前に分析基盤を作ろうとなり、その時にグロースチームができました。僕はこのチームには入っていませんでしたが、そこにデータがあったのでKibanaに入れました。それよりも前は、サービスについて知るということをあまりやっていなかったはずです。お問い合わせはよく見ていましたが、やることが多くて、やることを探すという段階ではなかったです。
伊藤：それでも最初伸びているかどうかということを、ユーザー数や登録数などから見ますよね？
道井：Google Analyticsが入っていたので、全員がそれを見ていました。ただ、Google Analyticsの集計をがんばってやるのですが、出てくるのがすごく遅いというか。
鈴木：VOYAGE GROUPのメディア関連事業の人たちは、Google Analyticsの神みたいな感じで。その他、Fluentdを入れる前から、課金のログやポイントのログ等をRDBに入れていて、それをダンプしてNetezzaなどのデータウェアハウスに入れて分析して、回していました。
伊藤：あまり体系化された方法があったわけではない？
鈴木：そもそもお金をかかわるものを一番見たいんですよね。そこの部分はデータベースに入れていた感じです。
データウェアハウスとの関係
伊藤：ちなみに、データウェアハウスみたいなものは会社にありますか？
道井：ないです。
吉田：そういうので言えば、トレジャーデータのサービスをクラウドで使っています。
伊藤：この話が僕は肝だと思っています。データウェアハウスがドーンと載っていた会社にとって、いわゆるEFKみたいな、もう少しシステム寄りの人達がマネジメントする分析基盤はどういう存在なのかなと。
鈴木：個人的に、カジュアルに使えるElasticsearchは良いなと思っています。ユーザが1行のログまで落とし込んで見ることは、BIツールではあまりしないです。BIツールは統計値・傾向を見るために様々なクエリでラップされているものです。そのため、裏側の、データウェアハウス自体にどうクエリをするのがセットで大事だと思います。しかし、Elasticsearchの場合はログにフォーカスしてるためTrendsを通しやすく、そこが違うかなと。
伊藤：なるほど。では、データウェアハウスはデータウェアハウスで会社の中に今まで通りあって、それが業務が回っている横に、プラスアルファで違う軸の分析ツールとして足すような感じですか？
鈴木：そんな感じですね。
伊藤：（会場に向けて）そもそもデータウェアハウスを知ってる人は手を挙げてみてください。（挙手を見て）結構少ない……。業務系のシステムを作ってる人は、データウェアハウスになじみがあります。例えばユニクロでは、全世界の店舗からPOSデータを集めて、1日でバッチを回して、毎日の売上などを集計しないといけないわけです。どのように収集・計算するのかなど、様々な要件があります。そこで、中央に何かデータベースウェアという高いハードとソフトウェアを置いて、そこににログを集めます。そして大げさな名前のBIツールを入れると、あまりSQLを書かなくても、大きいハードに対してクエリを投げてグラフ化できるものがあります。こういった昔からすごい業界が20年よりも前からあります。EFKの話をしてる人たちはその辺のことを知らずに話をしている人が結構いるような気がしています。EFKはそのモダン版みたいという印象を持っています。逆に言うとEFKなどを導入すると、昔からあるデータウェアハウスはどういうしていくつもりなのか？ 並行で使うのか、対立なのか、置き換えるのか等を聞きたいです。
鈴木：データウェアハウスは使うのに敷居も高いし、値段も高いのもあります。やはり、スキーマを組むのが肝かなと思っています。
大谷：設計が大変そうですか？
伊藤：設計は大変ではないけど、考え方がRDBと違っていて、スタースキーマというデータウェアハウス独自のようなものを使います。
鈴木：正規化しませんよね。
伊藤：マスターテーブルみたいなものを多く作ります。例えば、顧客の名前などが入ったりしています。また、中央に正規化しないログデータをため込むテーブルを用意します。そして、マスターテーブルと中央のfactテーブルをジョインすると、顧客がこの日にどのくらい使ったのかが出るので、それをSQLで結び付けるような感じです。このようなユースケースとか、最近だとビックデータ系のHadoopやGoogle BigQuery、Amazon Redshiftなどは、とても領域がかぶっていると感じています。そのあたりとの棲み分けはどうなってるのでしょう？
大谷：個人的にはElasticsearch社に入る前から、Elasticsearchに興味がありました。とりあえず入れてみて簡単に触れるのが一番の売りだと思っています。ログを突っ込んで、どういう軸で見たら良いかを試すために使ってもらうのが楽かなと。だいたいこの軸で見たいというのが決まれば、HadoopなりKibanaなりを組んでもらって集計を回す感じでしょうか。とりあえずテストベッドとしてデータを入れて触ってみるというのが簡単にできるため、そいうところに便利なのかなと個人的には思います。
伊藤：pixivではGoogle BigQueryを併用していると言っていましたが、まさにそのとおり？
道井：はい。Google BigQueryでフィルタリングしたデータを突っ込むみたいなことをしていますね。
伊藤：もともとカジュアルに、直近なデータや瞬間的なものはElasticsearchに入れて見て、長い時系列で見たい時にGoogle BigQueryでため込んでるんですよね？
道井：そうですね。基本的にFluentdからは、ElasticsearchにもGoogle BigQueryにも同じデータを入れていますが、Elasticsearchでは1ヶ月でデータを消してしまいます。そのため、1ヶ月分だけならKibanaで見ればいいし、それ以外であればGoogle BigQueryに対してクエリを投げてバッチを回してます。
古いデータはどうしてる？
伊藤：1ヶ月でデータを消しているとのことですが、そのあたりの話をする時、Fluentdでカジュアルにデータを送ればいいんだ言っても、ため込んだデータどうすれば良いのかと言うのを誰も言ってくれません。古いデータはどうしてるんですか？
吉田、鈴木：消してます。
大谷：本には周期的に消せるというツールの話も取り上げました。EFKでは日付単位で消せます。「デフォルトは消す」ですが、消すのが嫌なら「閉じる」というリソースを食わない形があります。つまり、indexのファイルを保存するけど検索できない仕組みになります。そういうツールを使ってもらって、たぶん皆さんそれで消してるか閉じてるかだと思います。
鈴木：ログは、Amazon S3などのストレージに置いてしまいます。そちらに全部あるみたいな感じです。
道井：ほんとに永続しないといけないデータは、別の人がきちんとがんばっています。
伊藤：では、Elasticsearchに限定した話だと、あくまでユースケースは若干限定的ということになりますね。きちんとやるなら、それを補完するデータウェアハウスとかGoogle BigQueryとか、そういうもっと大きい部品を背後に置いて、2段階構成にするというのが定番ですか？
道井：そうですね。また、Google BigQueryからElasticsearchに入れているのには理由があります。弊社ではGoogle BigQueryに入れたのをTableauなどのBIツールにつないでいるのですが、社内でKibanaのほうが慣れているから見やすいよねという意見があります。
大谷：それはだいぶ変わった意見では（笑）
伊藤：TableauとはBIツールの一つで、国内ではたぶんかなりメジャーなツールです。けっこう面白くてGUIで操作できます。それぞれのカラムに色をつけて、それをつなげるとSQLに変換してくれます。
鈴木：勝手にSQLされるのが嫌で。これはエンジニアの感覚だと思うんですが。
伊藤：それは良いんだよ（苦笑） なるほど、古いデータは捨てる。ちなみにHadoopクラスタとかに載せている時の古いデータはどうしていますか？
鈴木：adingoはAWSに載っているため、S3に過去のデータは全部残っています。集計したい時にはAmazon EMRを使います。
吉田：リブセンスもAWSに載っています。直近データはElasticsearchに入れているのですが、ほとんどの解析エンジニアリンニングに関しては1ヶ月くらいのデータを使っています。データは消さずに、すべてをため込んでいます。そのため、とんでもない量がたまっています。時系列でパッチングされているため、直近だけならすぐ取りかかれますし、1年2年と設定すればすごく時間かかってしまいます。場合によってはサービス開始のほうから見てください、とかありますね。
データを蓄積するのは進化した形？
伊藤：完全に与太話になりますが、ログ解析などで、古いログデータをAmazon S3にとっておくようになりましたよね。全人類、要らなくなったデータを蓄積していって、どうするのだろうなと思います。
鈴木：（笑） 僕がこうやってiPhoneでなんかユースケースで見たログが10年後もAmazon S3に残ってるかと思うと、ちょっと。
伊藤：それを残してなんになるのかと。いや、すいません。古いデータを残しておくというのがそこがよく分からなくて。よく分からないけど使わないデータをずっと残しておいて何になるんだっけと思いながら、残すのですが……。
鈴木：分析者的には、モデルを作るときにたくさんデータがあったほうが良くて。そのために残してるというのが一つ大きいですね。
伊藤：でも、そういうのはビジネス用重要なデータだけですよね。例えば、Nginxの5年前のアクセスログとかをとっていても意味がなくて。でもとっておきますよね。警察からの照会などで役に立つ場面も当然ありますが。だからとっておかないといけませんが、全人類のログが膨大なHDDに積み上げられていく。全然エコではないですよね。
鈴木：エコではないですね（笑）
道井：その通りですね。昔は例えば、1ヶ月のどれだけ売上があったとか、1ヶ月に会員数が伸びた等の集計済みのデータがあれば良いという時代でした。いまは、データをHadoopクラスタとか、使えるところに放り込んでおいておいて、使うタイミングで集計しています。
伊藤：そこがパラダイムシフトだと思っています。昔は、データウェアハウスの世界で言う業務DB、つまり本番のデータベースに直接クエリを投げていました。例えば、MySQLのスレーブとかで作っておき、バッチ処理をそこに投げて、ユーザ数やユニーク数などをがんばって集計していました。それがHadoopとかビッグデータとか言うようになって、ログ解析のためにログを送るようになりました。ようするに、エンタープライズの世界で昔からデータウェアハウスでやっていたような手法を、BtoCの世界でもカジュアルにやるようになってきたわけです。これは資源を使い続けるじゃないですか。すごく気持ち悪いんですよ、生理的に。でも、いまはあきらめて、Google BigQueryにログを送り続けているのですが、なんか罰があたりそうです。
鈴木：ビックデータとは、そもそも全量（すべてのデータ）を使って何をするのか、という文脈だと思っています。Hadoopもそうですし、全部データが使えるようになったから、みんな同じことできるようになったよねというパラダイムから、だんだんこういうふうになってきたと思います。たしかに使わないログは増えますが。
伊藤：ようするに、頭を使わなくなっていて。クエリ投げれば、こう大きいクラスタで処理してくれるから、全部持っておけばいいよねという富豪的世界感というか。
鈴木：良さは2つあり、もう一つ進化したパラダイムというのがあると思います。スキーマオンリードとスキーマオンライトという話です。書き込むときにスキーマが決まるのと、読み込むときに決まるという、この2つの違いがあります。ライトのほうは、データベースはスキーマを決めないといけないということです。でもログであれば、とりあえず生のまま書いておいて、集計するときに、つまり読み込むときにスキーマを決めればいいとなりますよね。そこがたぶん大きいと思います。
伊藤：いや、結局、計算機のスピードが速くなったとか、並列機計算のパラダイムが進化したから、ログをそのまま流し込んでおくだけで、「昔は計算できなかった業務データが計算できるようになりました。ハッピーですね」という世界なんですが、僕らは、ログエンジニアたちはカルマを積み上げているわけです。将来、地獄に落ちるかもしれない。まあそれは冗談ですけど。
ログエンジニアの仕事
伊藤：だから、そういう変化がここ数年で起きています。そうすると、いま言ったみたいに、昔であればGoogle Anlistics使ってたりとか、MySQLにクエリに投げていたことを、別でやるシステムを構築しなければいけなくなったから、やっぱりログエンジニアという職業が出てくるわけです。本書を読んでログばかりやると、ログエンジニアにクラスチェンジしますね。
鈴木:世の中にログエンジニアが増えて幸せなのかと言うと、悩みますね。
伊藤：そうなんです。僕、時々思うことがあります。ログのこの話と少し似ているのですが、最近、デベロッパープロダクティビティなどと言って、ようはインフラとかアプリケーションエンジニアに収まらない役割を用意して、継続的デリバリーとかデプロイを自動化するとか、そういうことを行うわけです。それにより、ボタン一発で自動デプロイできたりと、幸せです。けれど、そもそもこういう職業がなくてもしていたのに、10年経ったらログエンジニアとかデベロッパープロダクティビティとか、昔がなかった職業が生まれて行っていますよね。でも、僕らがユーザに提供しているものは、昔作っていた掲示板に毛が生えた程度ものしか、実のところ提供できていないじゃないですか。本質的に進化しているのかなと思います。ログ、良いんですよ。ログエンジニアやってると、ログで可視化するというのは重要だから、可視化は大事ですよとプレゼンするのですが、心の中では実際どう思っていますか？
鈴木：ログを見るというのは結局、既存の改善の話に落ち着くかなというのがあります。そう、革命は起きづらいです。
伊藤：ログ収集の実感値、どの程度役立てられているか。プレゼン資料を書くと、きれいごとになってしまうので止めましょうということです。実際先ほど言ったみたいに、ログだけだと非連続な変化を起こしづらい。だから、既存のデータからベースの改善という話になります。それでも行ったほうが良いですか？
鈴木：行ったほうが良いと思います。結局、続けないと新しいものは出てきません。「続けるために、もう少しきちんと儲けましょう」「儲けるために改善しましょう」という話になります。
大谷：Kibanaについて仕事で説明していますが、その際にはどんなデータを入れて、どういうふうに入れたら面白いかを考えています。ログも同じで、どのように検索するとか、どういう軸で集計したら面白いものが出てくるかとかは、誰が考えないといけませんよね。そういうのは、自分で考えてるんですか？
鈴木：自分で考えたりしてますね。
大谷：業務知識がある人はそういうのを考えてくれたり、相談したりをするのかなというのを知りたいです。
鈴木：営業の人にどういう軸で見ているのかを聞くこともあります。エンジニアなら、わりとすぐに軸についてはこうしましょうとなりますね。
大谷：こういうツールだと使いにくいという話もありますか？
鈴木：Elasticsearchのaggregationがちょっと分からないけど、どうしたらいいか？と質問は結構ありますね。
伊藤：たしかに昔から、営業とかの相談を受けてSQLを書いて運用ばかりしていたエンジニアはいました。それが進化してログエンジニアになったと思えば、非常にポジティブですが。
鈴木：個人的には、みんながSQLを投げたほうが幸せではないかという気もしますけどね。
伊藤：そう、それもあります。
吉田：そういう考えで、僕の会社ではアルバイトさんでもSQLを書いています。SQL講座を開いて、いままでExcelやWordしか使ったことがないという人に対して、いやいや関係ない、できるんだ的な感じで教えています。そして、検索してもらっていますね。
ログ解析すると、数字しか見なくなる？
伊藤：話ずれてしまったので戻すと、ログ解析は役になってると。逆に、すごく嫌だったことあります？
道井：まあ、仕事が増えましたね（会場：笑）
吉田：効果があるんだろうと思って行った施策が、データから見ると全然だめだったというので、泣く泣くクローズということがありました。
伊藤：それは、そのデータがなかったから、そもそもそういう議論になったんですかね？
吉田：たぶんそうならずに、いいだろうということで、なんとなく残るような感じですね。
伊藤：これは結構本質的だと思います。数字にして出してしまうと、きちんと量子化と言うか、数字化できてないが故に、結論がNGだねということがあります。けれど実際は単にきちんと数字が出きてないだけで、自分たちの認知していない領域の部分で、きちんと効果が出ていることがあるはずですよね？
鈴木：そこは難しいですね。広告では、直接そのクリックした広告ではなくて、いろいろなページで過去に見てるものも寄与しているという話があります。そういうのを追い始めると、分からなくなります。
伊藤：あくまで、ある程度の間接、つまりヒントとして数字を見るのは良いのですが、最近の風潮だと数字がすべてみたいなところがあります。数字になっていないところは議論ができないという話がありますが、やり過ぎ感があります。
鈴木：そうすると、面白いアプリケーションができなくなるんですよ。
伊藤：ログエンジニアは、そういうところにもある程度自覚がないといけないですね。なんでも数字化してデータ出せば良いというものではないと思います。
道井：一昨年くらいに、可視化などでABテストをすごく行い始めました。その3か月後に、もうABテストはやめようという話になったんです。ABテストをしていると数字しか見なくなるんです。数字を追うのは楽しいけど、小さいことしかしていない。例えば、ここを変えたら、コンバージョン率が何％上がりましたといっても、僕らはページのボタンしか変えてないんです（苦笑） だから数字とかよりも、みんながどう見ても良いよねと思うことを行ったほうが良いという話があり、ABテストをあまり行わなくなりました。
伊藤：（笑） 僕らもABテストのツールをお客さんに使ってもらいながら、これがすべてではないですと必ず告げています。ABテストは適当に使っていると罠に落ちてしまいます。そうならないように使ってくださいねと、コンサルティング込みで売っています。
鈴木：そこは難しいところですね。
道井：例えば、結局導線はここにおいたほうが良いとか、そういうレベルの改善はABテストで全然でいいのですが、そういうのもやりつつそれはメインではないよねと意識し始めたのが昨年くらいからです。
伊藤：逆に言うと、そういったことはエンジニアリングの話ではなく、ビジネスをどう行うか、みたいな話ですよね。ログエンジニアをしていて、最初のうちはFluentdめっちゃ楽しい！と言ってたら、これでABテストできる、とか巻き込まれていく。
鈴木：意思決定のためにやるものなので、分析することは、そこに行きつくと思うんですよね。
伊藤：材料を提供するときの難しさとか、モラルの問題とか、結構あると思います。ログエンジニアの悩みなど、そういう話を、ぜひプレゼンしてください。
ログ収集システムの規模感は？
伊藤：別の話になります。個人的に聞きたかったのですが、ログ収集システムの規模感というのは、どのような感じですか。先ほどのElasticsearchは、pixivくらいの規模だと何台くらいですか？
道井：pixivのElasticsearchは2台しかないです。32Gメモリに、SSDが3個。余っていたサーバです。
伊藤：それが余ってるってずるくないですか？
道井：これはきちんとして余っていたサーバです。もっと前はベニヤ版の上にマザーボードを載せて、8Gのメモリを積んだサーバを、4台並べたというのを僕が作りました。しかし、あまりにElasticsearchの書き込みで止まってしまい……。週明け月曜に僕が会社に来ると、Elasticsearchが止まっていますよと、怒られていました。すいません、と言って直すのを3週間してしまいました。その後、きちんとしたサーバにしようと思って、データセンターで余っていた2台のサーバにした感じです。
伊藤：Elasticsearchの2台のみということですが、Kibanaのフロントは？
道井：Kinabaもそこに載っています。kibanaはJavaScirptで動くため、全然関係ないです。適当に入れておくだけですね。
伊藤：では、基本、多少いい感じのサーバ2台で十分まかなえているということですか？
道井：はい。そのために行っているのが、先ほどのセッションでも言いましたが、pixivではアクティビティと言う、結構構造化されているイベントログです。PVのままではなくて、ログインされたタイミングとか、ユーザがボタンを押したタイミングだとか、そういうタイミングでしか発火しないログです。全リクエストのログも入れていたのですが、それを全部入れると全然ダメで、10分の1にサンプリングしたのを入れていたりしていました。でも、いまはそれも入れてないです。結果、500万レコードになります。PVは1日1億くらいあるため、それを入れるにはKibanaでは全然追いつかなくて、Google BigQueryに入れてフィルタリングして引っ張ってくるみたいな感じです。
鈴木：いまは運用していませんが、Amazon EC2のm1.xlargeで15台並べてElasticsearchを運用していました。indexなどが70Gできるものを使っていたのですが、メンテナンスが面倒になったのと、そこのログをみんな見てくれなくて……。
伊藤：メンテナンスが面倒と言いますが、（価格が）高いですよね？
鈴木：高いと言えば、高いです。いまは1日20～30Gのログを、r3.2xlrageというメモリ60Gくらいのがあるサーバ、それを2台並べてやっています。
伊藤：さきほどは32G。そして60G。
吉田：32Gですね。
伊藤：結構良いマシンを使っていますね。リブセンスはAWSなんですか？
吉田：ほとんどがオンプレで動かしていて、一部はクラウドを使っています。Elasticsearchを動かしているのは保守切れサーバを拝借して使っています。
伊藤：32Gの保守切れサーバですか？
道井：うちと同じ感じですね。普通のIAのサーバは32Gで4コアという感じなので、32Gまでは結構載せられます。4コアの型落ちしてきたサーバに、メモリを買って刺せば32Gのサーバになりますから。
伊藤：基本IOバンドだから、メモリとディスクだけが必要となると。CPUは古くても大丈夫ですか？
鈴木：CPUはindexを生成するタイミングで使われますね。
大谷：集計するのにも少し使います。
鈴木：メモリですよ、やっぱり。ほんとにElasticsearchがFull GCで死ぬと悲惨なことになるので、メモリは積んだほうが良いです。
道井：そうですね。
伊藤：なんと言うか、いま僕らもGoogle BigQueryを使っていますが、いろいろと面倒なことがあります。例えば、そこまでインタラクティブではないのに、クエリを何秒待たないといけないとか。また、BIツール入れるのが面倒なので、コンソールからSQLをどんどん書いています。しかし、さすがにSQLだとな……でもBIツール買って入れるのかとか。このように中途半端な状態なのでElasticsearchを入れようかと思ったのですが、自分で運用したくないと思いませんか。
鈴木：なるほど。
伊藤：Elasticseachのクラウドサービスはないんですか？
大谷：foundとか、qboxさんとか、いくつかありますね。
伊藤：Elasticsearch社自身はそういうのは行っていないのですか？
大谷：行ってないですね。Elasticsearch社自身はサポートやトレーニングですね。
伊藤：そのようなサービスを使えば、運用しなくてもできますか？
大谷：そうですね、使えると思います。ただ、データ課金になってしまうため、そこそこの値段がするはずです。
吉田：クエリ課金はないんですか？
大谷：クエリもあったかな？ 日本のだとデータ件数ですね。
会場からの質問
伊藤：そろそろ時間も迫ってきましたね。会場の人で質問してみたい人はいますか？
バックアップは？
会場:Elasticsearchのバックアップはどうしていますか？ オブジェクトストレージに入れているという話もありましたが、バックアップはサーバを運用していると気になります。
鈴木：スナップショットをとっていますね。
吉田、道井：しないです。
伊藤：逆に言うと、ログをAmazon S3に保存していれば、再カウント可能ということですよね？
全員：そうですね。
道井：30日くらい経てば、どうせリフレッシュされるので、まあいいかという話もあります。テンポラリなので。
吉田：直近2～3時間くらいをモニタリングするような用途で使ってるので、消えてしまったら、溜まるまで少し待ってくださいという感じで、ゆるく運用してます。
鈴木：KibanaのDashboardの設定などは取っておかないとまずいですよね？
全員：たしかに（笑）
Elasticsearchはもともと検索用のサーバですよね？
会場：Elasticsearchはもともと検索用のサーバですよね。ログを突っ込んで使い倒していますが、そのあたりどうですか？
大谷：いま検索したいものは、全文検索だけではないはずです。ログもやらないといけないというので、Kibanaがありますよね。そのため、そちらの方向にも行ってると思ってもらえるといいのではないでしょうか。そういう意味で、時系列のデータを持ったものを入れるとか、効率的に書ける仕組みにも向いています。
会場：複雑な思いをしているわけではない？
大谷：個人的には全文検索から来てるから、そちらも面白いと思います。そうではない考え方で便利に使うのもアリかなと思います。広い意味で検索と思っていただき、データを入れてとりあえず検索・可視化できる仕組みを提供していると考えてもらえればいいかなと思います。
伊藤：たしかに。今日はGoogle BigQueryと同列でElasticsearchの話をしてきましたが、検索エンジンですよね。完全にビックデータのバックエンドみたいな認識になってしまいましたね。
鈴木：そうですね。ポジショニングの問題かなと（笑）
吉田：リブセンスでは、Elasticsearchを全文検索で使ってるほうがメジャーだったりします。
大谷：日本だと、はてなブックマークとかもそうですよね。
伊藤：良く知っていますね。
大谷：はい（笑） Solrからスイッチしていただいたようで。そういう意味だと他に、GitHubのバックエンドもそうです。
道井：pixivもElasticsearchを検索エンジンに使っています。
伊藤：突然Elasticsearch自慢がはじまった（笑） ログの話ばかりしてるとElasticsearchがスケールしないみたいな話になるりますが、通常の全文検索だとデータ量はそこまで多くないため最近のマシンなら十分indexを保存できますね。
大谷：そうですね。GitHubでも大丈夫ですので。ログに特化したではないですが、 ログを入れやすくというので日付単位でindexを作る仕組みがあります。
吉田：ログ用途よりもアグリゲーションと呼ばれる集計機能が優秀で、モダンな感じに作られていますよね。DSLクエリの柔軟性が高すぎて、書きにくいという声はありますが。
大谷：そのあたりは多少そうですね。
伊藤：Elasticsearchは検索エンジンということで、皆さん間違いないように。
Kibanaの運用における注意点は？
会場：KibanaはBasic認証をかけられますが、誰でも気軽に編集できますよね。どういう運用をしていますか？
道井：pixivはオンプレでネットワークを持っているので、社内ネットワークからプロキシを通してつなぐ形です。それで同期している感じです。なんでそういうことをしているかというと、KibanaはElasticsearchに直接APIをたたくからです。例えばDELETEを投げるとElasticsearchのデータが消えてしまいます。まあ、DELETEはメソッドで塞いでいますが。
伊藤：それはNginxなどのフロントでDELETEメソッドを受けつけない感じですか？
道井：そうです。
伊藤：最近、typesterさんが作ったgateというGoで書かれたプロキシがあります。GoogleのOauthをしてくれるプロキシサーバみたいなものです。Elasticsearchとか、AWS上のパブリックなサーバにそれを入れておいて、使ってみたいのに対してプロキシを通して裏側から認証をかけられるから、Basic認証よりもましな認証ができるようになります。
鈴木：GoogleアカウントでOauthできるという話ですか？
伊藤：そうそう。Google Appsを使っている会社であれば、2段階認証も使って、結構強固な認証ができるはずです。あと、このドメインでの認証しかしないとできます。結構良いです。
鈴木：adingoではLDAPを使っています。
Elasticsearchのスキーマのデータ型に関するルールは？
会場：開発の話になると思いますが、Elasticsearchのスキーマの型はどのように決めていますか？ 型が変わるとおかしくなりますよね。
鈴木：弊社はGitHubでスキーマを管理しています。新しくindexを作る時にはダイナミックミックマッピングの設定を書いて、上手く当てることはしていますね。どうですか？
道井：ログのスキーマは決めていませんね。
鈴木：全部Stringですか？
道井：はい。ダイナミックマッピングはあります。*を使う感じです。ログに関してはスキーマを決めていません。ログに関してはですけど。
吉田：基本的にダイナミックマッピングですが、ここのフィールドに関してはこの型を使うといった、選択的な指定を行っています。基本的にはStringですが、ここは数値にしたいというのは個別に設定しています。
道井：あと、Fluentdから入れる時には型がきちんと合っていれば、IntegerはIntegerとして入ります。特にそこで困ってないですね。
大谷：他にテンプレートを使っていただくとか。また、マルチフィールドという形で、一つのフィールドを複数の型、Stringだったり、形態素する/しないだったり、そいういのが一度にかけられます。投げるJSONは一つです。そのデータが内部に入っていればindexに設定してもらう機能があります。それを活用すると、いろいろなパターンの解析ができるような仕組みになるかなと思います。
鈴木：ログでトークナイズすると、結構大変なことになりますよね。
大谷：トークナイズすると、日本語って一文字ずつ切れてしまうので結構つらいです。IPアドレスなどが切れてしまいます。
道井：そうですね。マルチフィールドを使ってトークナイズするのと、しないので2個作りますね。
大谷：例えば、先ほどのKibanaのグラフで単語単位で出したいものは、トークナイズしていないものをグラフで使うようにします。
伊藤：時間も押しているので、以上とさせていただきます。本日はどうもありがとうございました。
懇親会
イベント終了後は、懇親会が行われました。乾杯の挨拶は、本書『サーバ／インフラエンジニア養成読本 ログ収集～可視化編』の担当編集者である技術評論社の高屋卓也氏が行いました。
その後、登壇者を交えて参加者の皆さんが歓談を楽しんでいました。
