ファイルを読み込んで長い文字列を処理する方式からIOオブジェクトで処理する方式に変えたら10%高速化した話

株式会社リゾーム システム企画・開発部 第4グループの尾古(@patorash)です。

弊社で扱っているシステムで、複数のgzip圧縮したファイルを読み込んでDBにインポートする処理がありました。今回はそれのリファクタリングを行い、10%ほど速度改善した話です。

リファクタリング前の処理

リファクタリング前は、ファイルの内容を読み込んで変数に入れた後、インポート処理を行っていました。そのインポート処理においても、巨大文字列を1行ずつ読み込んで処理するようにしてありました。

file_path = Rails.root.join('files', 'import_file.jsonl.gz')
contents = Zlib::GzipReader.open(file_path) do |gz|
             gz.read
           end
ImportFile.import_from_string!(contents)

class ImportFile
  class << self

    # 文字列からデータをインポートする
    # @param [String] contents 改行コード区切りのJSON文字列
    # @option [Integer] batch_size 何件毎にインポートするかを指定。デフォルト1,000件。
    def import_from_string!(contents, batch_size: 1_000)
      records = []
      contents.each_line do |line|
        records << JSON.parse(line.chomp)
        if records.size == batch_size
          # activerecord-importを使ってバルクインサート
          import(records, validate: false, batch_size: batch_size)
          records = []
        end
      end
      ImportFile.import(records, validate: false)
    end
  end
end

問題点

まず、最も問題なのは、ファイルの内容を一度に全て読み込んでしまっているところです。今回の処理では、gzip圧縮から解凍した際のファイルサイズは100MBを超えるくらいのものでした。これが100MBどころではなく、もっと大きなファイルであった場合、メモリが足りなくなる可能性があります。

そして、次の問題点は、変数の内容を1行ずつ読み込んでいるところでした。1行ずつ読み込むこと自体はそんなに悪くないのですが、activerecord-importでバルクインサートをするかどうかのif文のチェックが毎回実行されていました。

リファクタリング後の処理

では、こちらをリファクタリングしていきます。

file_path = Rails.root.join('files', 'import_file.jsonl.gz')
io = File.open(file_path, 'r')
Zlib::GzipReader.wrap(io) do |gz|
  ImportFile.import_from_io!(gz)
end

class ImportFile
  class << self

    # IOオブジェクトからデータをインポートする
    # @param [IO] io IOオブジェクト
    # @option [Integer] batch_size 何件毎にインポートするかを指定。デフォルト1,000件。
    def import_from_io!(io, batch_size: 1_000)
      io.each_slice(batch_size) do |lines|
        jsons = lines.map { |line| JSON.parse(line.chomp) }
        # activerecord-importを使ってバルクインサート
        import(jsons, validate: false)
      end
    end
  end
end

変更点

IOオブジェクトを使うようにした

ファイルを一気に読み込むのではなく、IOオブジェクトから読み込むようにしました。

#each_sliceで1,000行ずつ読み込む

#each_lineメソッドで1行ずつ読み込むのをやめて、#each_sliceメソッドを使って、1,000行ずつ読み込むようにしました。1,000行読み込んでいるので、わざわざ1,000件のデータがあるかどうかのチェックは不要になったので、if文は削除できました。また、読み込む量も1,000行分毎で済むため、メモリ使用量も少なくて済みます。

パフォーマンス確認

「推測するな、計測せよ」というわけで、benchmark-ipsを使ってパフォーマンスの違いを検証しました。圧縮を解凍したら合計140MBくらいのデータで実験しています。

検証環境のスペック

結果

11%も速くなりました!🚀

Warming up --------------------------------------
                  io     1.000  i/100ms
                text     1.000  i/100ms
Calculating -------------------------------------
                  io      0.018  (± 0.0%) i/s -      1.000  in  56.379435s
                text      0.016  (± 0.0%) i/s -      1.000  in  62.673752s

Comparison:
                  io:        0.0 i/s
                text:        0.0 i/s - 1.11x  (± 0.00) slower

かなり効果があったと言えると思います。

まとめ

今回はファイルから一気に読み込んでから処理するのではなく、IOオブジェクトを使うようにリファクタリングしたケースをご紹介しました。

ファイルを一気に読み込むのは割とやってしまいがちなのですが、ファイルサイズが大きいデータが想定される場合はあまり良い方法ではありません。そういう場合はIOオブジェクトを活用しましょう。

「入門 監視」読書会レポート vol.1

株式会社リゾーム システム企画・開発部 第4グループの尾古(@patorash)です。

「現場で役立つシステム設計の原則」読書会が終わりましたので、先週から社内の有志で新たに読書会を始めました。 それをレポートしていきたいと思います。

読書会の題材

読書会の題材として選んだのは、入門 監視 ―モダンなモニタリングのためのデザインパターンです。

複数の候補がある中で決戦投票を行った結果、大差でこちらに決まりました。

皆、どう監視と向き合っていけばいいか、何をどう監視したらいいかを理解したいというのが現れていたかと思います。

読書会の進め方

進め方は、「現場で役立つシステム設計の原則」読書会のときと変わらずです。

  1. 当日までに事前に章を読んでおく
  2. 感想や疑問点をまとめる
  3. 読書会当日、感想をそれぞれ発表する
  4. 意見交換を行う
  5. まとめをYammerにアウトプットする

ただ、感想を書くときには、以下のような形にしてもらうよう、お願いしました。

  • 事前に1章分を読んでおいて、本の感想・疑問点・質問をまとめておいてください。
    • ※要点をまとめないでください。
  • 感想・疑問点・質問は、なるべく業務や過去の経験と絡めた形にすると助かります。
    • 経験知をシェアしましょう。

これは、プロダクト開発での課題・困り事と紐づけて考えてもらうことで、本の内容をより咀嚼することができると思ったからです。

1回目 レポート

初回は「1章 監視のアンチパターン」でした。参加者は6名でした。

出てきた感想

ツール依存
  • やりたいことをはっきりさせていく事が大事
    • 何を監視するべきなにかを理解しないといけない
    • 監視が目的になると、ツール依存やチェックボックス監視になってしまう
  • 目的と手段が逆転してしまう開発あるある
    • 最初は何らかの問題解決を目的としていた筈が、あるツールを採用後、使い倒すために道具を使う方向にシフトしてしまう
    • ツールや技術から選ぶと大体失敗するので、今ある課題を解決するために必要なものを探すという方針は、常に頭の中に入れておけたら苦労しなかった
  • ツールに依存するほど使えてない気もする…
自分でツールを作らなければならないときもある
  • 以前の職場で監視業務をしていた時は、同僚が作った自作ツールがいっぱいあって、めちゃくちゃ便利だった
  • 何だかんだどのCIツールも最後はシェル力が問われるところがある
  • 自分でツールを作っても良いという発想は無かった
  • 一から作成するのは大変なので、既存の監視サービスに組み込む形がいいのかもしれない(MackerelのカスタムメトリックやNew Relic Flex)
役割としての監視
  • 監視専門の人がいればなー、と思っていたが、それではいけないのだなと気づいた。
  • 監視しやすいシステムはチームワーク・連携力が段違いだった記憶。
    • 監視している誰かがログやアラートを共有してから、例えばアプリ担当者やコンテンツ作成者が心当たりを調査する。
    • なので行った操作・出力されたエラーが即時連携されること、これを受けた関係者が即座に自分のこととしてレスポンスを返すこと。
    • この辺りが綺麗に流れない組織だと、見通しは一気に悪くなる印象。
  • 「オペレーションチームだけでなく、全員が本番環境全体に責任をもつべき」
    • すごくいい言葉。自分事にしないと、なかなか身につかない
    • 全員が全員、ここまで意識はできていないと思う
チェックボックス監視
  • 耳が痛い話。痛いけれど、この監視は不要ですと言い切れる自信もなかったりするよなぁと思う
  • 現場に当てはめて考えてみた
    • 「メトリクスは記録しているがシステムがダウンした理由がわからない」
      • とりあえずサービスを再起動してみることが多いかも
      • それで直ったら調査を後回しにしがち
    • 「後検知が多すぎるのでアラートを常に無視する」
      • 誤検知ではないが、うるさすぎて無視していたことがあった
    • 「リソースがギリギリでもレスポンスタイムが許容範囲内なら問題ない」
      • 確かに
      • むしろリソースを上手に使い切っているとも言える
      • 動いているかを定義するのが大事なんだなぁ
「動いている」とはどういう意味か
  • 実際の業務では非機能要件の可用性・パフォーマンス辺りの話になってくるが、であれば関係各所との調整必至で明確な答えのない問題
  • 監視初心者としては書かれている内容は分かるが、どの程度にしたら良いのか悩んだり迷ったりして固まりそう
監視を支えにする
  • 暫定対応としてはありだろうけれど、常態化はよくない。リファクタリングが終わるまでの役目にするべき
  • Webアプリのバグ(開発環境やステージング環境で発見可能なレベル)を、本番環境にデプロイしてからインフラ担当者に指摘されることが常習化している現場はあった
    • よく指摘されていたのは「Webアプリを実装するエンジニアがあまりログを見ない」というもので、保守・運用経験が少ないとログをよく見る癖が付いていなかったり、障害調査がしやすいログ設計ができなかったり、ということがままある。ログ設計できるようになりたい。
手動設定
  • 自動設定できるようになりなさいってことで、やはり入門監視の前にAnsibleに詳しくなるべきではないだろうか…。しかし、日常的にサーバ管理やってるわけではないから、すぐに忘れてしまう。
  • 既に動いている自動化されていないシステムを自動化するのは大変
    • できることなら開発の早い段階から、理路整然と自動化されたシステムを構築するのが良いんだと思う
その他、色々
  • ツールを増やすのを恐るなという話。確かにと思う反面、多すぎて把握できなくなるのでまとめたいという話も出てくる
  • ツールの導入にはお金の話も絡むので、簡単に試せないケースがある
  • 監視ツールを常に表示しておくためのディスプレイ欲しいなぁ〜と思った
  • 会社で導入している監視ツールでどういうことができるのか確認してなかった。調べておきたい
  • 自作ツール、作るのはいいけれど、メンテが大変になるケースもちらほら…。

まとめ

アンチパターンの章ということもあって、皆グサグサと刺さっていたと感じました。耳が痛い話ばかりでした。「やりがちですね」とか、「とはいえ、どう設定すればいいのかがちょっとわからない」とか、今の現場での困り事と絡めての感想が出てきて、より自分ごととして考えることができているなと思いました。

ツールを増やしてもいい、自作してもいいというメッセージは、すごくよかったなと思います。いわゆる俺得ツールを自作していくようになっていけば素晴らしいと思います。

次章は「監視のデザインパターン」なので、今からとても楽しみです!

「現場で役立つシステム設計の原則」読書会レポート vol.10

株式会社リゾーム システム企画・開発部 第4グループの平松です。
今回は、読書会の第10回目のレポートになります。
前回のレポートは、こちらになります。

tech.rhizome-e.com

10回目レポート

今回は、第10章「オブジェクト指向設計の学び方と教え方」で参加者は6名でした。

それぞれの感想・意見交換

  • ドメインオブジェクトを設計していくという考え方にはあまりなってなかった
  • 受託開発をしているときはリファクタリングをする機会があまり与えられないため、良さがよくわかってなかった
  • オブジェクト指向は言葉で説明するのは難しい
  • オブジェクト指向を学ぶにはリファクタリングがいいと思う
  • 手を動かして覚える
    • 仕事のタスクだけだと覚えるのに時間がかかりそう
    • オブジェクト指向を意識して作業してもらわないと意味がない
    • コードレビューで言及して意識してもらうとか
  • 実際の実装を読んで理解する
    • 一番手っ取り早い気がする
    • 長くメンテされているライブラリ等は綺麗に実装されているものが多い
    • ついでにPRも出せば、手も動かせて良い勉強方法になりそう
  • 極端なコーディング規則を作ると、1人ならいいのかもしれないけれど、チームでやるとイライラしそう
    • 仕事で実践していくのは厳しい
    • プライベートで勉強がてら取り組むのには良さそう
    • Todoリストとかのサンプルアプリを作って試すなど
    • 一部、簡単に実践できる内容もあったので、今後、機能開発する際はチェックするようにしたい
  • ドメイン駆動設計の本は先輩社員にもオススメされた
    • 書かれたのが2000年代初頭なので、それを念頭に置いて読まなければならない
    • 書かれてる実装方法が現代においては冗長だったりするらしい
  • 「モノ」にフォーカスした「データクラス」がアンチパターンであることを理解する
    • データクラスは複数箇所で参照されるため、修正の影響範囲が大きくなるということを理解する
    • モノにフォーカスしたテーブルを作るとこれが出来上がる
    • モノにフォーカスしたテーブルを作っていいのは業務ロジックを持たないマスタデータだけ?

まとめ

この章では、オブジェクト指向の学び方について意見交換を行いました。
リファクタリングで学ぶという意見やライブラリ等の実装を読んで理解するという意見など、それぞれが思うオブジェクト指向の学び方が出てきました。

第10章で「現場で役立つシステム設計の原則」の読書会は終わりです。
この本を読んできて、ドメインオブジェクトの視点からオブジェクト指向とはどのようなものか、オブジェクト指向の開発とは何かを知ることができたのではないかと思います。 また、この本の内容が自社製品のリファクタリングをする上で基準の参考になりました。

次の読書会は入門 監視 ―モダンなモニタリングのためのデザインパターンを読んでいきます。

「現場で役立つシステム設計の原則」読書会レポート vol.9

株式会社リゾーム システム企画・開発部 第3グループの渡辺です。
今回は、読書会の第9回目のレポートになります。
前回のレポートは、こちらです。
tech.rhizome-e.com

9回目レポート

今回は、第9章「オブジェクト指向開発プロセス」を読み進めました。

それぞれの感想・意見交換

開発の進め方
  • 分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。
    • 特に、Railsでは顕著ではないかと思う。ちょっと規模が大きくなるとコードの見通しが急速に悪化するというのは、身に覚えがある。
    • コードの見通しが悪い
    • 手がつけられないほど難解
  • もう少し分析や設計に時間をかけるのが良いのかもしれない..。
ドキュメントについて
  • 開発の初期から利用規約・ユーザーガイドのアウトラインを作成しておき、開発が進むにつれ内容を充実させる、というのはいい考えだと思う。
  • データベースのテーブル名/カラム名とコメントは書くようにしている。I18nのデータを元にコメントにしていく仕組みを準備している。gemにしてもいいかもしれない。
    • 何のためのカラムか、制約か、わかりやすくなる
  • 技術方式のドキュメントもソースコードで表現できる(Infrastructure as Code)
    • 現代においては、この辺りはもう全てコード化しておくべきもの。学ばなければならないものが多い反面、自動化できることの恩恵は大きい。
  • ソースコードがドキュメントの代わりになる
    • ドメインオブジェクトのクラス名等と業務の関心事が一致してれば可能
    • とても魅力的だが、テスターの人にもある程度の知識が必要になる(IDE使えたりとか)
    • 技術者ではない人向けには別途ユーザーガイドなどを用意すると良い
    • ドメインモデルで設計ができれば、コードがドキュメントみたいなことが実現できる
情報共有の方法について
  • 口頭でのやりとりをラフスケッチとしてホワイトボードに起こしていくというのは、写真を撮るだけでいいしよくやっていた。
    • リモートワークが主流になった現在だと、MiroやMS Whiteboard等を活用するのもいいかもしれない。
  • ラフスケッチ良さそう
    • 今は口頭とかテキストベース
      • イメージしにくかったり見落としがあったりとか
ドメイン知識について
  • オブジェクト指向の開発を進めていく上で業務の理解は必須になっている
  • 分からないことは聞く。分かったふりはしないこと。
    • どのようにしてドメイン知識をつけたか、同じチームのメンバーに確認する
  • 他の章にも書いてあったが、プログラミングスキルとドメイン知識の両方を備えていかないと、優秀なエンジニアとは言えないと思う。業務知識の勉強会を行うことも大事と思われるので、そういうことも計画していったほうがよいかもしれない。

まとめ

本章では特に「ドキュメント」「情報共有」について、今までの経験でどうした方がいいのか答えが出ていなかったのですが、答えを見つける手がかりを得ることができました。
技術者向けには、ドメインモデルでの設計やInfrastructure as Codeにより、ソースコード自体をドキュメントとし、技術者以外の関係者との情報共有は、「利用者向けのドキュメント」や「画面・帳票」をメインに利用できるようしていきたいです。

現在実施している「現場で役立つシステム設計の原則」読書会は、ついに次回の第10章で最後となりました。
改めて今までを振り返り、今回得た知識を業務で活用して行こうと思います。

「現場で役立つシステム設計の原則」読書会レポート vol.8

株式会社リゾーム システム企画・開発部 第3グループの鳥井です。

読書会の第8回目のレポートです。

前回のレポートは、こちらになります。

tech.rhizome-e.com

8回目レポート

今回は、第8章「アプリケーション間の連携」で参加者は4名でした。

それぞれの感想・意見交換

アプリケーション間の連携方式
  • 代表的なものは以下の4つ
    • ファイル転送
    • データベース共有
    • Web API
    • メッセージング
  • 弊社でよくやる方式なのはファイル転送、WebAPI連携も多少やっている。
Web API設計
  • 更新も削除もPOSTにする
    • アプリケーションの独立性が高くなり、修正の影響を小さくできる
    • 更新や削除もPOSTで行うのはRESTに反するので、どうだろう..。
  • 大は小を兼ねるAPI
    • 必要のないパラメータまで理解しなければならなくなる
    • 受け取ったデータから必要なデータを取り出す処理が必要になる
  • 計算ロジックの置き場所
    • 以下の理由から、単純なものも含めてクライアント側を基本とするのが良い気がする。ただし、DBで集計できるものなどはWeb API側で処理する。
      • どちらに書くべきか判断に迷わなくなる
      • ロジックを書いてある箇所が特定しやすい
  • 登録と参照を分ける
    • 例えば指定席を予約するAPIの場合、POSTのレスポンスは予約番号だけを返し、予約内容はその予約番号を使って別途GETする
      • この例だとPOSTした際に予約内容の詳細を返す場合と比べて1回リクエストが増えるが、シンプルな設計になることのメリットのほうが大きいと思う
  • リソース単位を分ける
    • Web API側はシンプルになるが、これはリクエスト数がかなり増えそう
      • 例えば名前、生年月日、性別の3項目を1つの画面に表示したい場合、3回リクエストする必要がある。リソースの数だけリクエストが増えてしまう。
    • クライアント側はリソースの数だけリクエストする処理や受け取ったデータを管理する処理が必要になるので煩雑になりそう
      • URLを叩く処理などをSDKなどにまとめていけば再利用しやすくなり、クライアント側の負担を減らすことができるかも
非同期メッセージング
  • 非同期メッセージングをアプリケーション間で使ったことはない気がする..。
  • dRubyを使えばできる?
マイクロサービス化
  • 試行錯誤がしづらそうだと思った。サービス単位の分離を上手にやらないといけない。
  • 対象業務への理解が不十分な場合はモノリスで作っておき、後々分けていくのが良いかも
  • サーバーレス&マイクロサービスが今後の主流になっていくとは思うが、それはある程度サービスが枯れてからが良さそう

まとめ

今までWeb APIを利用することがあまりありませんでしたが、本章を読み進めることでWeb API自体やシンプルでより良い設計の方法について理解を深めることができたと思います。

ただし、Web API側のシンプルさを追求する一方でリクエストの頻度やクライアント側の負担についても考慮する必要があると感じました。

本章を通じて得た知見を活かしてシンプルで保守しやすいWeb API設計を意識しつつ、サービス全体としても最適な設計を模索していきたいと思います。

「現場で役立つシステム設計の原則」読書会レポート vol.7

株式会社リゾーム システム企画・開発部 第4グループの尾古(@patorash)です。

読書会の第7回目のレポートです。

前回のレポートはこちらです。

tech.rhizome-e.com

7回目レポート

それぞれの感想

画面にロジックを書いてしまうこと
  • 画面に表示するロジックと業務ロジックが混在してしまう
    • 1章で言われていた、ちょっとした条件分岐を追加したら複雑になってしまう件が頻発する
    • ビューにif文が入ると見辛くなる
      • 特に、slim*1で書いていると、閉じタグがないため、インデントが重要になるが、if文が入るとかなり見辛い
    • 複数画面にコードが重複してしまう
  • 表示のロジックと業務ロジックを分ける意味では、Railsでいえばビューヘルパーを使ったり、デコレーターを使っていくのがいいとは思う。ビューヘルパーのメソッドはオブジェクトをレシーバにできないのであまり好みではないけれど、契約による設計を重視した形にすれば、あまり散らからないのではないか?
論理的なビューと物理的なビュー
  • どこに画面用ロジックを集めるか問題
  • 論理的なビューに関してはドメインオブジェクトでいい、というのはわかるのだが、結局苦しんでいるところは物理的なビューだったりする。
  • Railsだとデコレーター層でやりがちだが、ビュー専用オブジェクトは極力作るべきではない
  • 画面に依存したドメインモデルもアンチパターン
  • class属性をドメインオブジェクトが持つべきという話
    • オブジェクトの状態によってclassを書き分けるif文がView上に出るたびに薄々感じていた
タスクベースのインターフェース
  • 関心事毎に画面を分割する発想はあまりなかった
  • ユーザーの入力負担軽減につながるので良さそう
  • 画面をタスクベースにできなくても、設計をタスクベースにしたり、画面の方も4原則を使って整えたらかなり見やすくなるのではないかと思う
  • 画面デザインの考え方をドメインオブジェクトのコードに当てはめるのは面白いと思った
  • 要件定義をする際に、お客様側は画面ありきで要件を考えるため、それがそのまま設計に繋がってしまうことがあった。
  • 今作っているサービスだとなんでも入力画面になっている。後で入力すればいいものまで、必須にする必要はないので、ドメインオブジェクトで整理していきたい。
  • 画面とオブジェクトを一致させることが、次第に画面に依存したオブジェクトを生み出すことに変わってしまいそうなのが一番懸念される
    • つまりレビュワーはこの点を特に注意深くレビューする必要がある
  • 画面もドメインオブジェクトで管理したいとなると、MVVMを使うようになってくるのは必然。しかし、この辺りをよくわかっていない人がやっているコードを見ると、「画面を値が連動していて便利」止まりになっている気がする。
利用者向けの情報もソフトウェアと整合させる
  • そうあるべきだが、これが難しい…
  • 開発者とプレスリリース/リリースノート/利用者ガイドを作成する人が異なるので…。
  • ドキュメント系のメンテナンスのためにはもうちょい開発者増やしたい。

意見交換

出た意見として、「全てのアンチパターンはモノに注目するが故に起きる。コトに注目することで細分化できたり解決するように見える」というのがありました。今まで読んできた中で、ドメインオブジェクトを作るにしても、テーブル設計をするにしても、コトに注目して整理することで、随分良くなるように感じています。

また、論理ビューと物理ビューをどうするべきか?について、時間をかけて話し合いました。最終的には、「物理ビューに依存したドメインオブジェクトにするべきではない」ということになりました。 最初は私は「論理ビュー用のロジックはドメインオブジェクトに持たせて、デコレーターには責務を割り切って物理ビューを担わせてしまえばいいのではないか?」という意見を展開していたのですが、ビュー専用オブジェクトになるし物理ビューと密結合になるのでよくないのでは?という意見もあり、考えを改めました。

Railsで論理ビューと物理ビューをどう管理するか?

読書会の後、ビューヘルパーに物理ビューを出力するメソッドを定義し、その引数に論理ビューを渡すという方式が一番しっくりくるのではないか?と考えました。

例えば、順番なしリストを作る場合は以下のような形になります。

まず、unordered_listヘルパーメソッドを定義します。

module ListHelper

  # ulタグのリストを表示する
  # @param [Array<String>] items リスト表示したい文字列の配列
  def unordered_list(items)
    render 'shared/ul' do
      render partial: 'shared/li', collection: items, as: :item
    end
  end

end

次に、上記のメソッドでレンダリングするViewを書いていきます。 views/shared/_ul.html.erbをこのようにします。

<ul>
<%= yield %>
</ul>

そして、views/shared/_li.html.erbをこのようにします。

<li><%= item %></li>

利用する場合は、例えば記事にタグがある場合はこのようにできます。

<h3>タグ一覧</h3>
<%= unorderd_list(@article.tags) %>

この形であれば、

  • ドメインオブジェクトは論理ビューに徹する
  • ヘルパーメソッドは論理ビューと物理ビューの繋ぎに徹する(ロジック含む)
  • 部分テンプレートは物理ビューに徹する(ロジック含まない)
  • 物理ビューにループ等のロジックを書かないで済む
  • 再利用性が高い
  • メソッドなのでIDEで補完が効く

と、良いこと尽しな気がしています。

まとめ

本章を通じて、普段から業務用ロジックと画面用ロジックのところで悩んでいたため、活発な議論ができたのではないかと思います。私自身もメンバーとの議論を通じて、考えを改めたほうがいいなと思えましたし、その中でより良い解決策を見出せたと感じています。

やはり本を読むだけでなく、意見交換を行える場があるほうがいいなと感じました。

「現場で役立つシステム設計の原則」読書会レポート vol.6

株式会社リゾーム システム企画・開発部 第1グループの小田です。

読書会の第6回目のレポートです。

前回のレポートはこちらです。

tech.rhizome-e.com

6回目レポート

今回は、第6章「データベースの設計とドメインオブジェクト」で参加者は5名でした。

それぞれの感想・意見交換

制約について
  • NOT NULL制約、一意性制約、外部キー制約を徹底すると自然と正規化が進む。
    • 適切なDB設計をするための指標としてわかりやすい
  • ここに書いてあるNOT NULL制約、ユニーク制約、外部キー制約などは基本的なものなので、出来る限り使う。データベース側の機能のチェック制約やenumなどを使うと、更にデータを守ることができる。
  • 原則としてNULLを許容しない。
    • もしNULL値がどうしても必要なカラムを見つけたら別のテーブルに分ける。
  • NOT NULL制約を使っていないカラムだとプログラム側でnullが来ることを考慮しなければならない。
  • 以前の勉強会で「データベースには事実を記録する。事実にはNULLなどない。基本的にNOT NULL制約を付けなければならない。」と言われて納得した。それ以降はNOT NULL制約を必ず付けるようにしている。レビューのときにも「NOT NULL制約を付けろおじさん」になっている。
  • (NOT NULL制約、普段はほとんど使ってない...)
コトに注目するデータベース設計
  • コトを記録するという発想がないと、モノに関連するもので一緒くたに詰め込んでしまおうと考えてしまいがち。
  • コトに注目するデータベース設計は楽々ERDレッスンでも言われていた。
    • 導出項目の排除につながる。
    • 導出項目はSQLのビューで状態を表現する。
  • 記録のタイミングが異なるデータはテーブルを分ける、というところ。マジでそれ!と思った。今の仕様がそうなっていなくてかなり辛い。
  • カラムを追加するのではなくテーブルを追加する。
    • そのカラムには過去データが存在しないので、NULLを許容するか偽データを登録するかの二択になるから、別テーブルに分けたほうが良い。
    • 確かに副作用がないけれど、テーブルが増えるしJOINが大変になりそうな気もする…。プログラムへの影響は少ないし、事実を記録する観点だとそっちのほうがいいのかな。
    • JOINが増えると性能面が不安
      • コト(口座への入出金データなど)を記録するテーブルとは別に、集計結果(口座残高など)を格納しておくテーブルを用意してあらかじめ集計しておくと良いらしい。
  • コトの記録の変更を禁止する(updateではなく、取り消しデータをinsert→修正後の新データをinsert)
    • 記録をupdateするのはupdate前の記録を削除することと同じ。updateせず「記録を修正した」というコトを記録する。
    • なるほどと思った。取り消しを記録する。元データ、取り消しデータ、新データ。INSERTだけで実現可能。
参照をわかりやすくする工夫
  • 状態の参照。コトの記録を徹底すれば、状態の算出は可能。動的に出力するのはパフォーマンス的に辛い場合もあるので、この辺りはRailsだとカウンターキャッシュを使ったり、DBのマテビューを使ったりしている。
  • 残高更新は同時でなくてもいい、一か所でなくてもいいという考え方は、柔軟性が生まれる。事実はDBに保存し、状態はKVSに持たせるようにすると良さそう。状態の参照は頻繁に行われると想定すると、KVSのほうが向いている。
  • モノの記録を行うからそこに状態を持つ必要が出てくるのであって、コトの記録に徹底するからこそ状態の更新をコトの記録と分離することが可能になるのだろうか
オブジェクトの設計とテーブルの設計
  • コトを記録するテーブルとドメインオブジェクトがほぼ1対1に対応することがある。しかし、似て非なるものという意識を持っておくべき。ドメインオブジェクトとデータベースのアクセスは、基本的に疎結合にしておいたほうがいい。そうでないと、互いに引っ張られ過ぎる。ドメインオブジェクトには業務ロジックを、データベースには事実の記録を。関心事が異なる。しかしそうなるとやはりRailsだと難しい。RailsActiveRecordドメインオブジェクトでもあり、データベースへのアクセス手段でもあるからだ。

まとめ

本章を通じて、コトに注目したデータベース設計を行うことで柔軟性が生まれ、データの管理やプログラムの修正が容易になることを理解することができました。 本章で書かれている内容と自身のプロダクトのデータベース設計を見比べ、どの辺りに改善の余地があるかを参加者全員が意識することができたと思います。

私は「原則として全てのカラムでNULLを許容しない」「カラム追加時は既存テーブルに追加するのではなく、新規テーブルを作成する」といった内容は想像したこともなかったのですが、そのように設計されたデータベースはデータの整合性や信頼性が高まり、定義の変更時にプログラムへの影響を最小限に抑えられることを理解できました。

また、読書会の中で「楽々ERDレッスン」という書籍を紹介頂きました。本章の内容についてはもう少し深掘りしてみたいと思ってるので、そちらも今後読んでみようと思います。