​ ​

あなたの知らないファームノート 第1回 5つの技術要素

こんにちは。
ファームノートクラウド開発グループの谷内です。

株式会社ファームノートは、農業のIT化によって農家の経営改善を実現するために 2013 年に設立された企業です。
サービスの企画や営業、顧客サポート/コンサルタント、経営状態の見える化を行うITサービスの提供、などをワンストップで行っています。
国内の多くの企業はITシステム開発を外注しているかと思いますが、ファームノートではエンジニアを雇ってすべての機能を内製開発しています。

私は社内SEとして、牛の個体/群管理機能をクラウド上で提供するサービス「Farmnote」の製品開発に携わっています。
Farmnote」 では、畜産業というドメインモデルを定義し実現していく中で、結果として、通常の WEB サービス開発では「あまり触れる機会のない技術」を選定し、採用してきました。
今回は、その技術を5つほど紹介します。

1. Temporal database

"Temporal database"とは、値が時間経過で変化していく様子を記録するデータベースです。

以下のような特徴があります。
・ある事象が起こった時、それが「現実に発生した日時」と「システムに記録した日時」の双方を記録し、値のバージョン管理を行う
・特定時点におけるデータを照会できる
Oracle や DB2、SQL Server といった商用データベース製品には搭載されていますし、普通の機能なのかと思っていたのですが、WEBサービス界隈ではあまり聞かないようです。

ファームノート個体/群管理システムは、家畜に対する従業員、獣医師、授精師のあらゆる行為を Event Sourcing におけるイベントとして記録しています。
発生した過去の事実と、未来の予定としての双方のイベントが入力されます。
それらのイベントを時系列に並べて計算し、イミュータブルなテーブルを生成します。
そのテーブルには、「家畜が現在どのような状態にあるか」を数百種類に及ぶ計算済みのプロパティとして保存します。
それらは例えば、1頭単位の牛の生理状態などを表しますが、集約することで群の繁殖状況や農場全体の経営状態についても算出します。

この Event Sourcing によって計算された結果を、テンポラルデータベースに書き込むことにより、任意の過去の時点で農場がどのような状態であったのか?
将来の時点では農場はどのような経営状態となるのか?を知ることができるようになります。

ファームノートでは、テンポラルデータベースを postgresql 上に独自に実装しました。
イベントの書き込み先である Event Store も postgresql で設計された正規化されたテーブル群となっています。
時系列のイベントは計算のためだけでなく、そのままビューとして照会可能であり、家畜の履歴として見える化することにより牛肉のブランド化や生産効率化に利用されています。
計算結果のテーブルは、ユーザーが自由に検索条件を組み立ててクエリを実行可能としており、結果は常に数ミリ秒で返ってきます。
参照専用テーブルを持つようなアーキテクチャでは、通常 CQRS などの仕組みを利用して計算結果は非同期的に受け取る設計にすることが多いでしょう。
しかしファームノートでは、CQRS を採用しながらも、すべてが同期的に動作しており、どのような操作を行っても即時にすべての要素が再計算されて反映されます。

なお、これらの仕組みは軽量であり、AWSの格安なt系のRDSインスタンスでも十分に実現できます。


2. in-memory database

voltDB_logo.png

上述のような「計算結果を同期的に提供する」アーキテクチャは如何にして実現できるでしょうか?
ワーストケースでは、ほんの少し値が書き換わるだけで、その牛の10年間に渡る数千のイベントを再計算しなければなりません。
その計算というのは、例えば抗生物質の投与による出荷禁止期間や、適切に繁殖コントロールされているかの指標の算出といったものです。

ここでは次のことが起こります。
・大量のクエリ発行で読み込みの IO 待ち
・参照用テーブルへの書き込みの IO 待ち
・参照用テーブルの再計算/再構築による CPU 処理待ち

読み書き双方の負荷が高い上に CPU bound な処理もあり、普通のアーキテクチャでは手に負えない感じがします。

ここで私は VoltDB というインメモリデータベースで検証を行いました。
VoltDB とは ACID 特性 を持ち SQL を発行可能な RDB です。
・ロックフリーなアルゴリズムで動作し、OLTP 性能が非常に高い。
・最初からテーブルがシャーディングされており、スケールアップ、スケールアウトの双方でリニアに性能が向上する
・コンパイル済みの Java のストアドプロシージャーがシャーディングされたデータ上に配備され、単純なクエリであれば読み込みも相当速い

ストアドであるため間にネットワークを挟むことがなく読み書きのIO待ちがなくなります。
計算能力についても自由にスケールさせることができます。

ここでさらに AP サーバーとして Vert.x を組み合わせました。
Vert.xVoltDB のペアを1台の EC2 インスタンスに同居させ、それをひとつのユニットとします。
このユニットを増やすことで AP サーバーと DB サーバーの双方が同時にスケールし、耐障害性も同時に向上していきます。

このアーキテクチャは、次の特性を獲得しました。
・race condition も deadlock もない。マルチスレッドのことを一切考えなくてよい
・同時接続数について考慮する必要がない。ついでにデータベースのコネクションプールも必要ない
・参照専用テーブルが用意されることから、SQL の実行計画を眺めて最適化する必要もない
・クライアントアプリケーションを SPA でつくったため、サーバー側は shared nothing となり、さらにスケールさせやすくなった
・web アプリケーションから SockJS で接続させることができるため、ネットワーク回線が遅い環境でも高速に動作するようになった

その特性の上で動く実際のアプリケーションの性能は次のようなものでした。
・数百のプロパティを持った10万レコードの家畜データに対して複雑なクエリを発行、ユーザー認証処理やSQLが走る、レスポンスの JSON を生成する、クライアントが結果をビュー/データグリッドにレンダリングする、その全行程が数十ミリ秒で動作した
・データグリッドのページ切り替えボタンを連打すると、ちょっとびっくりするような体感速度でぺージが遷移した
「オフライン動作するデスクトップアプリケーションを凌駕する」性能を発揮した

最終的な決断として、このアーキテクチャはプロダクション環境では利用せず、RDS の postgresql と ElasticBeanstalk 上の rails という AWS に寄せた構成としました。
これは VoltDB のライセンス形態の変化や実装コスト、フレームワークの安定度合いなどを評価した結果です。


3. Sales Force Automation

salesforce.jpg

Sales Force Automaiton とは、営業支援を行うためのツールや手法のことを指します。
特にアーキテクチャとして面白いところはありませんが、web サービスの界隈のエンジニアの中ではほとんど話題に上らない気がするので取り上げてみました。
弊社では Salesforce で顧客管理をしているため、個体/群管理アプリケーションと Salesforce を force.com を利用して接続しています。
牛に取り付ける 行動検知デバイス Farmnote Color やそこからデータを送信するゲートウェイの在庫管理は Salesforce ですが、そのデータを同期したりしています。
Apex という Java によく似た独自の言語で開発を行います。また、SQL によく似た独自のクエリ言語を内臓しています。

4. Elixir

elixir_logo.png

弊社エンジニアの北村さんがプロダクション環境への導入を目論んでいる技術で、Erlang VM で動作する関数型言語です。
Erlang ですので、Vert.x のように同時接続に強いです。
3番目で紹介したように、弊社では行動検知デバイスを開発しています。
それは家畜がウェアラブルデバイスによって Intenet に常時接続される "Connected" な世界です。
1番目や2番目で説明で、やけに同期的な処理に拘っているなと感じたかもしれませんが、すべてがリアルタイムに同期してつながる世界を実現するため、現在採用を検討しています。


5. ADIS

段々とマニアックになってまいりました。これは Agricultural Data Interchange Syntax の略です。
ファームノートでは様々な外部システムと接続してデータ交換を行いますが、これは農業用のデータを交換するための規格です。
多くのシステムがこの規格に準拠したプログラムを持っており、互いにデータを交換できるようになっています。
例えば搾乳機械の利用統計を取得することにより、搾乳を行う従業員の作業効率について経営者が知ることができます。
乳量の落ち込みなどを知ることもできますし、抗生物質が投与された牛を搾乳機械にやってきた時に自動でゲートを閉めたりすることも可能です。


6. (おまけ)Estrus synchronization protocol

ovsynch.jpg

6つ目はおまけであり、結びとなります。
これは技術といっても IT 技術ではなく酪農・畜産技術です。
WEB サービスエンジニアが知っているわけがありませんが、ファームノートのエンジニアであれば全員が理解している必要があります。
海外でファームノートのような個体/群管理アプリケーションを開発しているエンジニアは、農業や酪農の技術にも造詣が深く、修士や博士過程を終了している人材も多くいます。
我々は彼らとも戦わなければなりません。

発情同期化プロトコルとは、牛の発情時期を確実にコントロールするための技術であり、農家の経営を大きく改善します。
そのため、様々な発情同期化プロトコルが研究、開発され、酪農の生産性に寄与してきました。
例えば Double-Ovsynch というプロトコルでは、牛に対して PG投与、2日後GnRHを投与、7日後に再度PG、9日後に再度GnRHという手順を踏むことで、高い確率で発情を起こすことができます。

このような複雑な作業を作業者の方が間違いなく実施するためには、ITシステムはどのようにそれを支援することができるでしょうか。
またそれが経営改善にどのぐらい役立っているかをどうやって数値化すればよいのでしょうか。

ファームノートでは、農家の経営改善にIT技術で立ち向かうエンジニアを募集しています。
我々は優れた技術によって、一目見てはっと驚く、目の覚めるような体験を顧客に提供したいと考えています。
必死に工夫して努力をし続けることで、畜産におけるITの常識を打ち破りたいのです。
また、その製品をもって海外への進出も目指しています。

どのような表現が WEB サービスエンジニアに届くのかはわからないのですが、Netflix が大規模配信に特化してその技術を先鋭化させていくようなのと同じような意味で、農業の経営改善に特化した技術を磨いていくエンジニア集団がファームノートには必要です。

同じ志の元、技術を磨きたいエンジニアの方は是非ご応募ください。

このエントリーをはてなブックマークに追加