最近仕事で Apache Kafka を使おうと思っていたり、分散処理が面白くて勉強している。そんな中いままさに知りたいことがセッション一覧に連なってたので参加してきた。
以下、聴講したセッションの概要、気になったところや質問させていただいたことのメモ。
NTTデータ テクノロジーカンファレンス2017 デジタルトランスフォーメーション成功のカギ～ Hadoop, Spark, ブロックチェーン
Hadoop/Spark を活用した家電ログ分析基盤の移行事例の紹介
ネットを介して収集した各種ログを活用して「ユーザー行動を先読み・自動運転」「ユーザーごとの個別最適化」といった進化をする家電。ログを収集するシステムが構築されてはいるものの、それを活用する部分に課題があり、Hadoop/Spark でいい感じにした事例のお話。
従来は、分析担当者がログを溜め込んでいるシステムからデータを DL ( = スケーラビリティの課題)し、それを PHP + MySQL で作られたアプリケーションで加工( = パフォーマンスの課題)して、ローカル PC の Access や BI ツール等で分析( = ユーザービリティの課題)していた。
※ ユーザービリティの課題： 使うツールが多い・担当者によってバラバラ・手順が複雑
スケーラビリティ・パフォーマンス・ユーザビリティの課題に対して(主に PHP + MySQL の部分を) Hadoop/Spark に置き換えることで、データの加工やレポート作成にかかる時間が劇的に改善したとのこと。
個人的に気になったのは、本題から少しそれるが、ユーザーごとの個別最適化について「データが蓄積していない新規ユーザーにどのように最適化するか」の話。既存の全データを地域等の属性で分類し、新規ユーザーの属性と突き合わせて最適化する、というのがセッションで紹介されていて なるほど〜と思った。
前述の Hadoop/Spark によって分析プロセスを改善したからこそできる事なのだろう。
つまり、Apache Kafka ってどうなのよ？
Kafka コントリビューターの佐々木徹さんよる、Kafka の概要や特徴についての解説。
（内容が盛りだくさんすぎて全然メモが取れてない…）
ディスクに永続化
Kafka はメッセージをディスクに永続化する特徴がある。そのため、ディスク I/O を効率化する工夫や、運用上の注意点がある。
- ログファイル (メッセージの実体)
- インデックスファイル (byteインデックス)
- タイムインデックスファイル (タイムスタンプインデックス)
上記3種類のファイルを作る。ディスク I/O によるパフォーマンスへの影響を最小にするために、(1)キャッシュ機構を持たない( = OS のキャッシュ機構に依存する)、(2)受信したメッセージをすぐにはフラッシュしない( = Broker のメモリに乗れば受信完了)といった工夫がされている。
これに関連する運用上の注意点として、
(1) OS のページキャッシュを利用しているので、Broker のメモリは JVM のヒープメモリを増やす必要は無い。
(2) クラスタを組む際に注意
また、Broker に必要なメモリ・ディスクを見積もる指針としては、流れるメッセージサイズや○日前のメッセージにも普通にアクセスがあるのか？といった観点で実際に計測すると良い。
その他、運用についてのナレッジは Apache のドキュメントや、開発を主導している confluent 社のドキュメントを見ると良い。
到達保証
- Producer <–> Broker の通信: Acknowledge
- Consumer <–> Broker の通信: OffsetCommit
によって到達保証を実現する。
通常は At least once だが、特定の条件付きで Exactly once も可能。
- すべての情報を同一の Kafka クラスタに書き込む場合
- Kafka Streams を使ったアプリケーション
（スライドは公開予定無しとのことだった）
本当は恐ろしい分散システムの話
先日 分散システムについて語らせてくれ が話題になった kumagi さんのお話。
興味深い内容と、テンポが良くカジュアルな語り口が相まって発表にどんどん引き込まれていく感覚があった。
世界の叡智を結集した有名な OSS であっても、CAP 定理や ACID 特性は意外と守られていないというお話。
“壊れる” の定義にはプロセスの死亡や物理的な故障はもちろん、データ化けも含まれている。化けて壊れたデータに耐性が無い分散ソフトウェアは、その壊れたデータがそのまま伝搬してしまう。
（「データ化けで壊れるのはどうしようもないんじゃないか…?」と思ったのだが、しっかり障害に発展しないようにチェックサムで対策したソフトウェアもあることを知って、自分の知識の浅さを感じた）
分散システムは壊れることを前提に考えるべきで、意図的にシステムに障害を入れる Fault Injection Test を実施している企業もある。とても興味深い取り組みだが、その障害を起こす仕組みも面白かった。
Chaos Engineering を読もうと思った。
まとめ
C会場の Technology Deep Dive ではコントリビューターによる解説が多く、タイトルのとおり深い話が多かった。企業主体のカンファレンスでこのクオリティはさすが NTT データさんという感じ。
自分は分散処理関係のプロダクトについて実務経験が無かったり、アルゴリズムも勉強しはじめなので前提知識が足りてなかったり具体的なイメージができずフム〜と雰囲気で聞いてるだけの時が結構あったので、もったいない思いをしたというか悔しい。まぁ今はしょうがない、頑張ろう。
発表はもちろん、その内容から登壇者の豊富な技量が伝わってきてとても刺激になった。意識の高まりを感じる。
とても学びの多いカンファレンスでした。登壇者の皆さま、運営の皆さまありがとうございました！