ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
Nominatimのセルフホストとホスト型互換サービスの比較
Nominatimのセルフホスティングは正当で、十分に文書化された選択肢です。特にジオコーディングのインフラを完全に自社ネットワーク内に置く強い理由がある組織を中心に、多くの組織がうまく運用しています。しかし、そのトレードオフは現実のものであり、ごまかさずにはっきり述べておく価値があります。OpenStreetMapのデータ抽出をダウンロードしてインポートし、許容できる速度でクエリに応答できるだけのディスク容量とメモリを確保し、OpenStreetMap自体の更新に合わせてデータをある程度最新に保ち、アプリケーションが必要とする稼働率の保証を満たしてサーバーを運用することを、すべて自分で引き受けることになります。
これらはどれも、わかりにくいとか文書化されていないという意味で難しいわけではありません。継続的に続くという意味で難しいのです。公開した当日にはうまく動いていたセルフホスティングのNominatimインスタンスも、誰も更新処理をスケジュールしていなければ、1年後には鮮度が落ちている可能性があります。また、ある特定の住所が正しく一致しなくなった理由を突き止めるには、Nominatimのソフトウェアと、基盤となるOpenStreetMapのデータの慣例の両方を理解する必要があります。
ホスト型の互換ホストを使えば、その運用の層を完全に取り除けます。その代わりに、ジオコーディングのトラフィックは自社ではなく第三者のインフラを通ることになります。ここで実際に下すべき判断はこの点であり、どちらか一方が単純に優れているかどうかという問題ではありません。
My GeocodeのNominatim互換ホストは、セルフホスティングまたは公開のNominatimインスタンスが返すのとまったく同じレスポンス構造を再現します。display_name、文字列としてのlatとlon、そしてsuburbやpostcodeのようなOpenStreetMap独自のフィールド名を使うaddressオブジェクトを返し、異なるのは著作権、利用規約、プライバシーに関する文言だけです。詳しいリファレンスは/compatibility/nominatim/にあります。フィールド構造がそのまま引き継がれるため、セルフホスティングのインスタンス向けに書かれたコードは、ホストと認証を変更するだけで済むはずです。
どちらの道を選ぶ前にも、正直に答えておく価値のある質問がいくつかあります。
- 組織に、セルフホスティングなら満たせてホスト型サービスでは満たせない、特定のコンプライアンスやデータレジデンシー上の理由があるか
- 現在、セルフホスティングのインスタンスの保守にどれだけのエンジニアリング時間を費やしていて、その時間を別のことに使えばどれだけの価値があるか
- トラフィック量がインフラコストをすでに正当化できるほど多く安定しているか、それとも、リクエスト単位やサブスクリプションの予測可能なコストのほうがすっきり扱えるような変動の仕方をしているか
答えがセルフホスティングのインフラから移行する方向を示しているなら、ホスト型側の認証では、X-API-Key、Authorization: Bearer、HTTP Basic認証、またはクエリパラメータとして送信するキーを使います。これは、公開Nominatimインスタンスが求めるUser-Agentベースの利用ポリシーに代わるものです。料金には、キーなしで1日あたり2,500件の無料リクエスト、さらにキーごとに1日あたり2,500件の無料リクエスト（ネットワーク単位で集計）が含まれ、それを超えると1リクエストあたり€0.0001のプリペイドクレジットか、月額€50のUnlimitedキーとなります。これはプラットフォーム上の他のすべてのエンドポイントと同じ料金です。多くのチームにとって、サーバーコスト、エンジニアリングの保守時間、リクエスト量をこの料金と照らし合わせて計算することが、どちらに決めるにしても最も早く結論を出す方法です。