こんにちは！ このポストでは、Geolonia のベクトルタイル配信基盤についての技術的な背景を解説します。
Gelonia のバックエンドは AWS 環境上に構築されていて、完全なサーバーレス構成になっています。従来はベクトルタイルのデータを静的にホスティングして地図の配信を行っていましたが、今回システムのリプレイスを行い、サーバーレス構成を維持したままベクトルタイルを動的に配信できるようになりました。
リプレイス前（静的配信）
タイルを静的配信する旧環境は Amazon S3、 及び CloudFront を用いた構成でした。
地図タイルは z/x/y.mvt のようなパスで配信されていることが多いと思いますが、この zxy インデックスをキーに S3 バケットのオブジェクトとして静的なファイルをホスティングしています。このバケットをオリジンに設定した CloudFront からタイルの配信が行われます。
ユーザーからタイルのリクエストがあると、CloudFront へのビューワリクエスト及びオリジンレスポンスに伴って Lambda@Edge が発火し、アクセストークンの検証やキャッシュ制御などを行います。
Lambda@Edge としてデプロイする Lambda 関数の作成やインフラの構成管理については Serverless Framework をインターフェースとして用いることで DevOps に親和的な開発環境になっています。
課題
S3 でのベクトルタイルホスティングにはいくつかの課題があります。
まず、Lambda@Edge のデプロイフローが煩雑であること。関数の更新と反映のためには CloudFront の再デプロイが必要で、更新には 10 分近い時間がかかります。
また、タイルのデータのデプロイはさらに大変で、直列で処理した場合ですが、例えば日本のエリアを対象に生成した全てのベクトルタイルをデプロイするために日単位の時間がかかります。これは、HTTP で行われる S3::putObject の操作を大量のファイルに対して行う必要があるためです。
リプレイス後（動的配信）
そこで、S3 と Lambda@Edge の利用をやめ、タイルのデータのデプロイは MBTiles 形式のファイルの単位で行うことにし、デプロイにかかる時間の短縮をはかりました。新しい配信環境の構成は以下のようになっています。
新環境では MBTiles ファイルを直接 EFS に保存することにしました。同一の VPC 内に Lambda を配置し EFS をマウントすることでデータへのアクセスが可能になります。MBTiles のファイルは SQLite 形式のデータベースで、Lambda の内部で zxy インデックスを指定してクエリを行うことでベクトルタイルのバイナリデータを直接取得します。
メリット
EFS を使うことでデプロイの速度が大幅に改善されました。2GB 弱のサイズの MBTiles ファイル1つだけであれば、デプロイは1分程度で終了します。作業の負担が軽減され、デプロイ・検証・公開のサイクルを短縮したことで、フィードバックをダイレクトに反映しながら製品である地図タイルを改善していくワークフローが整いました。
データの出力時にコンテンツに対して動的な変更を加えることが可能になったのも魅力的です。例えばユーザーの属性やタイルのリクエストの状況に応じて個別に最適化されたデータを配信することも技術的に可能になりました。
新しい配信方式のベクトルタイルの地図は 公式ドキュメント などで体験できます。また、CodePen というサービスにも大量のサンプルがありますので、簡単にカスタマイズを試すことができます。この際 API キーは不要です。
現在 β 版の段階ですが、独自ドメインで Geolonia の地図を利用する上で必要な API キーを発行するためのダッシュボードも用意しています。
Geolonia ではクラウドや Node.js などの技術が好きな開発パートナーさんを募集しています。 ぜひ Geolonia の Office Hour に遊びに来てください。 お仕事の相談やその他技術談義なども大歓迎です！
追記
このタイル配信システムは、以下のリポジトリで MIT ライセンスで公開しています。
https://github.com/geolonia/tileserverless
プルリクエストや Issue などお気軽にお寄せください。日本語でもOKです。