rasv: Raspberry Pi 上の Docker でベクトルタイルを扱うプロジェクトを開始した

 _   _ _   _  __     __        _             
| | | | \ | | \ \   / /__  ___| |_ ___  _ __ 
| | | |  \| |  \ \ / / _ \/ __| __/ _ \| '__|
| |_| | |\  |   \ V /  __/ (__| || (_) | |   
 \___/|_| \_|    \_/ \___|\___|\__\___/|_|   

 _____ _ _        _____           _ _    _ _   
|_   _(_) | ___  |_   _|__   ___ | | | _(_) |_ 
  | | | | |/ _ \   | |/ _ \ / _ \| | |/ / | __|
  | | | | |  __/   | | (_) | (_) | |   <| | |_ 
  |_| |_|_|\___|   |_|\___/ \___/|_|_|\_\_|\__|

       Make the technology the easy part.

概要

ポータブルなベクトルタイルのツールキットを、Raspberry Pi を使いながら作っていきたい、という話です。

容易に入手できる安定した Linux 環境としての Raspberry Pi

わずかな人的資源・経済的資源のもとでベクトルタイルを進めるということは、難しい挑戦です。資源を節約するために、無駄を回避する必要があります。

ベクトルタイルを生産したりホストしたりするためには、本物の Linux 環境が必要です。誰もが安心して少ない手数でアクセスできる Linux 環境が欲しいところです。

Windows Subsystem for Linux は Fire and Motion

これまで、 Microsoft の Windows Subsystem for Linux に期待してきました。これからも期待するでしょう。しかし、不連続的に進化を続ける Windows Subsystem for Linux の運動は、結果的に Fire and Motion （射撃しつつ前進） 戦術になっています。このような大きな会社の Fire and Motion 戦術に丁寧に応じていく体力は、我々にはないかもしれません。よって、Microsoft の仕事にはこれまで通り期待しつつ、やや距離をとりましょう。

Raspberry Pi を用いた Ambush battle

Windows Subsystem for Linux よりもさらに必要資源が少ない、しかし Linux としては安定した環境を求めるべく、Raspberry Pi を用います。変遷の多い Windows Subsystem for Linux も避け、Homebrew も避け、狭小であるからこそ本物の Linux にアクセスしやすいという特徴を、Raspberry Pi に求め、そこにある、多くの資源を必要としないが安定した環境を用いたいわば Ambush battle を試みます。

Raspbian の特徴

Raspberry Pi の推奨 OS となっている Raspbian は Debian ベースです。その安定性（保守性）には期待して良いでしょう。

他方で、ベクトルタイル系のソフトウェアは最新のコンパイラやライブラリを求めることが多く、また、Raspberry Pi は CPU が arm32v7 系統です。そこで、Docker を用いて最新の環境からのソースビルドを多用します。

具体的には、arm32v7/debian:unstable からの組み上げをはかるわけですね。

タスクの定義

Raspberry Pi 上の Docker で動く国連ベクトルタイルツールキットを実現する Dockerfile を粘り強く作っていきます。

レポジトリ

上記 Dockerfile を配置するためのレポジトリを次の場所に作りました。

rasv は "RASpberry Pi for the UN Vector Tile Toolkit" の略称ということで、よろしくおねがいします。

ベクトルタイル技術の特性との相性

ベクトルタイル技術はウェブブラウザを基盤としている以上、最少数・最精鋭の技術で組み上げていくべきものです。

Raspberry Pi の持つ、制約が多くて速度の遅い環境は、最少数・最精鋭の技術で組み上げていくということを促してくれるでしょう。

いずれ、Raspberry Pi で動く Dockerfile を作ることができれば、Dockerfile の冒頭 FROM 行を変更することで、他のプラットフォームのためのイメージもおそらく容易に作ることができるでしょう。

まとめ

国連ベクトルタイルツールキットの portable 性の確保を求めて、地形を選んで安定した良い場所で「待ち伏せ」をはかります。こういった手法を考えることを可能にしてくれた、Raspberry Pi, Raspbian, Docker, Debian に感謝します。

追伸： デスクトップ GIS との関係

多様なデータへの対応を求められがちなジオスペーシャル分野では、ソフトウェア開発において、つい「あれもこれも」戦略に頼りがちです。

結果として、デスクトップ GIS というアプローチをとる限りは、かつて軽量で鳴らした QGIS が現在そうなってしまったように、重くて導入しづらく飛びにくいものを作ることになりがちです。

ウェブ時代の GIS というのは、ソフトウェアよりもデータのライフサイクルやライフスパンに寄り添った形で作られなければなりません。

ウェブ地図技術分野の現況に目を向けてみると、Mapbox 系のオープンソースのベクトルタイル技術がとっている以下の戦略に可能性を感じます。

1. データについて、性能重視で力強く標準化する
2. ソフトウェアは最少数・最精鋭で支え、コアユースケースでの性能を重点的に更新していく
3. 帯域幅において差別化を試みる
4. 収益は帯域だけではなくストレージを基準としたモデルにする

感想

• Dockerfile の開発時点では、Raspberry Pi に併用して MacOS でもイメージを作ってみていますが、MacBook Pro 2017 上の MacOS でも、イメージの build に膨大な時間がかかっています。Raspberry Pi でのビルドには、とても膨大な時間がかかりそうです。しかし、ビルドに膨大な時間がかかるということは、ビルドしたイメージを配布することによる利益は大きい、ということですね。
• それぞれのメジャーリリース時点で構成ソフトウェアについて保守的なバージョン選びをし、また古いメジャーリリースのままでの運用を許容するエンタープライズカルチャーにも感謝します。この文化に触れたことで、最初にはソースからのビルドを行わなければならないと決意することができ、次にはその OS ネイティブでの配備ではなくて Docker を用いた配備をせざるを得ないと決意することができました。身軽なモダン環境にしか触れていなかったら、Docker をかませることに今ほど興味を持ち得なかったかもしれません。Raspberry Pi を使うという手法には、エンタープライズカルチャーへの不要な抵触を回避するという効果もあると思います。
• Dockerfile の中の make コマンドに -j2 とかつけていないのは、Raspberry Pi 上で実行した時に、CPU が発熱しすぎて調子が悪くなることを恐れたからです。