Ponz Dev Log

ゆるくてマイペースな開発日記

技術書典 応援祭で出したKafka本の振り返り

技術書典 応援祭でKafkaに関する技術同人誌を執筆しました。 3月の頭から頒布が始まってからだいぶ時間が経ってしまったので、執筆前から執筆後までの振り返りを書き連ねます。

執筆した本はこちらです↓

[技術書典マーケット] techbookfest.org

[BOOTH] ponzdou.booth.pm

執筆まで〜執筆中

技術書典7で１冊書いたことがあったので、スケジュール感と本の執筆環境準備は手間取らなかったです。 参考までに執筆環境はこんな構成です↓

手元でプレビューを確認しつつ、git commit → git pushしたら自動的にCloud BuildでPDF生成が走るように自動化していました。 CI環境が整うと効率上がるのですごく良いです。CIはいいぞ😊

書いた中身の振り返り

最初に目次レベルのレビューを受けた時点では、頒布前告知の以下の記事で宣言した通りかなり広く浅く触れる本にする予定でした。 ponzmild.hatenablog.com

ただ、紙に印刷して読み直してみると、手を広げ過ぎて全てが浅い本になっていたので結果的に構成変更しています。 「Kafka初学者」をターゲットにするべく、詳細の深掘りやKafkaの周辺プロダクトの話はスコープ外して、基本的な部分の説明を充実させています。

  • メッセージのデータ構造を定義するSchema Registryの章は全て削除した。
  • 概要説明とコマンドライン操作の章を挿絵入れて丁寧にした。 (ページ数が倍に...)
  • Kafka ConnectのConnector自前実装の節を削除。替わりにOSSのConnector(PostgreSQLのもの)の利用チュートリアルを厚めにした。
  • Kafka Streamsはメッセージ加工するステートレスなアプリのみ扱い、メッセージの集約・表示するステートフルなアプリはGitリポジトリ参照に留めた。
  • コラムは長く書かずに1行リンクに寄せた。

書きたかった(≒深掘りして学びたかった)トピックはたくさんあったのですが、 次に書く内容が増えたと捉えて内容を取捨選択したことで読みやすくなったと思っています。

書いた後の振り返り

本を書いたきっかけは単なる技術的関心の追究だったわけですが、 お仕事でも使う機会がありそうだったので啓蒙資料としてKafkaの魅力プレゼン資料として使うことも目的としていました。

実際にチームメンバーに説明する機会にも恵まれ、メンバーに簡潔に説明してクライアントアプリを書き始められるところまで持っていけたのは1つの成果です。 説明していて気付いたのですが、自分の本をさらにサマリした数枚のスライドにまとめて見せると良いですね。 理解してほしいポイントが著者・聴衆共に分かりやすく、同時に本の内容にも興味を持ってもらえます。

ただ、Kafkaそのものの理解が深まっても業務アプリに活かすためには考慮すべき点が多く、学ぶべき点につきません。。。 例えば、以下のような考慮点は処理する業務特性を理解した上で設計する必要があります。

  • メッセージの二重送信防止
  • 受け取ったメッセージの二重実行の防止
  • Consumerのエラーハンドリング (失敗したら、メッセージは捨てるのか、リトライか、Dead Letter Queueに入れるのか...)
  • Web APIの処理をProducer/Consumerに分割する方針
  • Kafkaを使えるユースケースの選定
  • etc...

これらの話題はまだ自分の中で答えは見つかっていません。 Red Hatさんの以下のブログ記事が参考になりそうですが、自分の中で整理できたらブログ記事にするか本にしたいですね。

rheb.hatenablog.com

本当に、本を書き終わってからが本番ですね。

また別の機会にKafka関連の本書きたいですね。Kafkaアプリ設計・実装つまづき集とか。

本じゃなくてもLTとかに登壇というスタイルもいいかも。どこかいい場所あるかしら？

以上。