要約

  • PeeringDBのAPI v3草案は、複数拠点から提供する公開・読み取り専用サービスと、可用性・データ鮮度の目標を提案している。
  • まだ意見を募る設計案であり、アクセス規則やAPI仕様は未確定だ。稼働中の性能を示すデータもない。

この草案は、将来のAPIに目標時刻を置いた一方で、公開開始日は示していない。9月18日付のPeeringDB文書は、可用性を99.95%以上、変更の99%を1分以内に反映し、キャッシュを含む最新データ応答の遅れを15分以内に抑える目標を掲げる。実装時期は記されておらず、文書の状態は初回の意見募集・レビュー用の草案だ。

APNICが10月7日に掲載したPeeringDBの製品更新は、検討の背景を説明している。製品責任者のLeo Vegodaは、読み書きを分けて複数の場所から読み取りを提供することと、関連データを効率よく検索することを主な狙いに挙げた。実装前にAPI利用者の意見を求めている。具体的な仕様はPeeringDBの草案にあり、APNICは掲載媒体であってAPIの運用主体ではない。

提案の初版は範囲を絞る。v3はv2と並行する公開読み取り専用APIとなり、書き込みはv2に残る。検索は名称とASNが出発点で、キーごとの非公開ビュー、階層の展開、順位付き全文検索、位置・距離検索は初版に含めない。フラットなオブジェクト、差分同期、日次スナップショットを通じて、利用者が自分のコピーを作成・更新する設計だ。応答にはデータセットのバージョンを示し、バージョン用エンドポイントでソースの鮮度を報告する。

鮮度の目標には測定範囲がある。ソースに変更が生じてから最新データを返すまでを測り、キャッシュの遅れを含む。一方、日次スナップショット、過去データの走査、第三者ミラー、利用者側のポーリング間隔は除外される。15分は提供を止める境界ではなく、アラートを出すための上限だ。目標を外れてもサービスを停止してはならない、と草案は定めている。

PeeringDBをネットワーク、施設、交換接続の関係を調べるために使う運用者にとって、これは将来の公開ビューが更新される速度を測る枠組みになる。ただし、掲載内容が完全か、参加者が更新する記録が正確かを証明するものではない。PeeringDBはルーティング制御面ではなく、この提案がRIRの資源割り振りやBGP判断を変えるわけでもない。

実装前の論点も残る。クエリー、応答、エラー、互換性の詳細はOpenAPIで定める予定で、アクセス方法とレート制限も実装前に決める必要がある。可用性の測定期間も開始日も文書にはない。設計上の割合は稼働記録ではない。

次に確認したいのは改訂版の仕様、確定したアクセス方針、そして実装後にソース・キャッシュ・クライアントの挙動を分けて測るデータだ。それまではAPI v3は将来の読み取り経路に向けた提案であり、運用者が今すぐ依存できるサービスではない。

出典