URL短縮機能を作った話

2024/05/31

web 仕事

t f B! P L
記事内に広告が含まれています。
Chrome url

仕事でやったことって記録に残すことがあまりなく、せいぜい職務経歴書にさらっと書く程度になってしまう。思い出せるようにポエム的な奴を描いてみることにする。

URL短縮機能とは

URLを短くする機能。以上。
だと説明が乱暴なので、どこかのメルマガで見かけたページを紹介。いくつかサービスもあるけど、ライセンスとか管理機能とか、なかなかニーズに合うものがなくて結局作ったんだけど。

短縮URLサービスを自作! その方法とメリットを徹底解説 - Value Note - わかる、なるほどなIT知識。

短縮URLサービスを自作! その方法とメリットを徹底解説 - Value Note - わかる、なるほどなIT知識。

Webサイトやブログの新着情報など、URLの告知に便利な短縮URL。bit.lyを始めとした商用短縮URLサービスが有名です。けれども、短縮URLサービスは自作も可能なのです。 ...

URL短縮機能の実装が必要になった理由

当時のお仕事で相手にしていたサービスには、GoogleのURL短縮サービスを利用した「URL短縮機能」があった。まぁ、オフショアで作っているサービス(モジュール)であったのだが。

で、ある時、URL短縮サービスがエラーになるなぁと思ったら、程なくしてサービス終了のアナウンス。かなり利用されている機能なので、サービス終了とともに機能廃止!というわけにはいかない…のに、機能リクエストをオフショアに出している気配がない。どうするつもり?

URL短縮仕様を考える

どうしようもないタイミングになって「やって」と言われても困るので、やることにする。まずは仕様決め。

  • 短縮した時の文字の長さを、GoogleのURL短縮サービスを使った時と同じにする。
    提供していたサービスでは、同じメッセージを複数送れるようテンプレート機能が用意されていた。そのため、短縮した時の長さが変わってしまうとテンプレートから作った文面の長さも変わってしまう。文字数で課金されるSMSにとっては重要で、長くなるとカウントされる通数が増えてしまい、クレーム問題になりかねない。
    SMSの文字数制限と料金

    SMSの文字数制限と料金

    SMSは文字数によって料金が変わります。メールと違い、長文だと高くなるので注意が必要です。何文字で変わるのか、考え方を説明します。

  • 日毎のアクセス数を短時間で算出できること。
    提供していたサービスには短縮URLのアクセス件数を日毎に出す機能があったが、GoogleのURL短縮サービスlは累積のアクセス数しか取得できない。毎日アクセス数を取得して、前日分のデータとの差分を計算していたようだが、アクセス数取得には時間がかかり、半日経っても算出てきていないこともしばしば。顧客からの問い合わせが相次いでいた。

実装の仕様としては

  • 短縮URLは、アルファベット大文字小文字+数字の62文字で構成する
  • 大文字小文字を区別するよう、データベース(テーブル)を設定する
  • 重複のチェックは、短縮URLを格納するカラムにユニーク制約をつければ実現できる
  • 同じタイミングで短縮URLを生成しようとした時、異なる結果になるようにしたいから、生成ロジックに顧客IDを絡ませたい
  • 同じURLを短縮させたいことがあるだろうから、生成ロジックに時間情報を絡ませたい
  • 短縮URLを元に戻すプログラムと、URLの短縮やアクセス数を取得するプログラムは、ユーザーが異なることから別々のプログラムとする
  • 短縮URLの長さと構成文字はわかっているから、それをウェブアプリケーションファイアウォールのルールに設定する

LとlとIの区別がしにくいとかあるものの、基本的に手打ちするものではないので、問題はない。構成する文字に記号も加えればより多くのURLを扱えることになるが、まぁ、それは足りなくなった時に検討すればよいだろう。

短縮URLへのアクセスが爆発的に増加することもあり得るので、必要な処理だけスケールアップできるように、独立したプログラムとした。

機能追加のリクエストは相手にしないのが重要

GoogleのURL短縮サービスではユーザーエージェント別の集計ができた?みたいで、機能追加を言ってきた人がいたけど、相手にしない。
提供しているサービスでは使っていないし、必要な機能だけを実装するのが堅牢なシステムにするコツだからだ。

そこは大人の対応で、「次のバージョンで検討します」として言って逃げる。そういった機能を追加する話は聞いていないし。使いもしない機能を要求する人はどこにでもいるので、仕様追加・変更的な話はマネージャーに回してしまうのが正解。この時はマネージャーからはなにも言われなかったから、思いつきで言っただけなんだろう。

調整はマネージャーに任せる

仕様を考えて、APIの仕様を決めたら説明資料を作り、オフショア先との調整はマネージャーに任せる。
「これが仕様です。問題があれば言ってください」
「大丈夫そうですか?では、これで作りますので」
プログラムを作ってインフラの設定をしてデプロイして…。やれるの、自分しかいなかったからしょうがない。

オフショア先での対応に結構時間がかかり、「こんなに急いで作らなくてもよかった Orz」という感じではあった。

人気の投稿

ブログ アーカイブ

自己紹介

ストックオプションを半分しか行使していなかったけど、パワハラをなぁなぁで済まそうとする会社から転職。アーリーリタイアを目指し、自分で稼ぐ術を模索中。

改正電気通信事業法に関する表記

・掲載内容

当サイトでは成果報酬型広告/クリック型広告の効果測定のため、利用者の方のアクセス情報を外部事業者に送信しております。
当該の情報は個人を特定する情報ではございません。また当該の情報が目的外利用される事は一切御座いません。

1.送信される情報の内容
  • 広告の表示日時
  • 広告のクリック日時
  • 広告の計測に必要なクッキー情報
  • 広告表示時及び広告クリック時のIPアドレス
  • 広告表示時及び広告クリック時に使用されたインターネット端末およびインターネットブラウザの種類
2.送信先となる事業者の氏名又は名称
  • グーグル合同会社
  • 楽天グループ株式会社
  • アマゾンジャパン合同会社
  • ヤフー株式会社
  • 株式会社ファンコミュニケーションズ
  • 株式会社もしも
3.利用目的

成果報酬型広告/クリック型広告の効果測定および不正防止のため

QooQ