独自の短縮URLシステムを構築へ

プロジェクトの背景と目的

PL（プロジェクトリーダー）：本プロジェクトの背景と目的について改めて確認したいと思います。SMSやLINEなどを活用した広告配信の際のメッセージ本文に記載するURLに対し、ユーザーや施策を特定するためにパラメーターを付与する必要がありましたね。しかし、その結果URLが長大化し、文字数制限に引っかかる問題が発生していました。そこで、パラメーターを維持しつつ、短縮化できるURLシステムの構築を目指すこととなりました。

エンジニア：はい、そのとおりです。従来は外部の短縮URLサービスを利用することもありましたが、自社ドメインのURLではないことでユーザーの安心感が損なわれるのではないかという懸念もありました。そこで、パラメーターを維持しつつ自社ドメインベースの短縮URLを生成する独自の仕組みを構築することで、文字数制限の解決とユーザーに与える印象の改善を目指しました。

PL：そうですね。ビジネス上の課題とユーザー視点の両面から、この取り組みの必要性は大きかったですね。

技術選定の経緯

PL：では、具体的なシステムについて説明してもらえますか?

エンジニア：はい。今回、短縮URLシステムとしては、２つの機能を開発しました。１つは、短縮URLによるリクエストを受け付けて、オリジナルのURLで正しく処理を行う仕組みです（図１）。もう１つは短縮URLを登録するためのAPIです（図２）。

Lambda@Edgeを採用

PL：1つ目の短縮URLによるリクエストを受け付ける仕組みは、どんな技術を使って実現したんですか？

エンジニア：こちらは検討の結果、AWS CloudFrontにLambda@Edgeを組み合わせるアーキテクチャにしました。Lambda@Edgeの部分は独自サーバを立てる選択肢もありましたが、Lambda@Edgeならサーバレスでクイックに構築できる点と、インフラコストが抑えられる点でメリットがありました。他プロジェクトから得たナレッジによれば、独自サーバに比べてパフォーマンスは100〜300msぐらいは劣りますが、短縮URLシステムのユースケースではパフォーマンスよりもコストが優先と判断しました。

PL：そうですね。SMS等からのリンクを開く際の少しのパフォーマンス劣化がコンバージョンに影響するリスクは低いという判断でしたね。

比較項目	Lambda@Edge + CloudFront	独自サーバ方式
構築の容易さ	◎ サーバレスなので容易	△ サーバ構築が必要
インフラコスト	◎ 低コスト	× 高コスト
パフォーマンス	△ 十分高速だがコールドスタート等のオーバヘッドあり	◎ 高速
運用負荷	◎ サーバレスなので楽	× サーバ保守が必要
スケーラビリティ	◎ 設定が楽	△ 設定に多少手間がかかる

表1. Lambda@Edgeと独自サーバの比較

DynamoDBによるデータ管理

PL：もう1つの短縮URL登録APIは複数のプロダクトで短縮URLシステムを共有したいというコンセプトから生まれたアーキテクチャでしたね。こちらの機能では、どのような技術要素がポイントになりましたか？

エンジニア：こちらの機能では短縮URLのデータストアを何にするかがポイントでした。DynamoDBとElasticacheが候補に挙がりましたが、結論としてはDynamoDBを選択しました。パフォーマンス面ではElasticacheのほうが優れていました。一方でDynamoDBのほうがインフラコストが抑えられることと、AWSマネージメントコンソール上でPartiQLエディタを使ってデータ確認できる点などで運用しやすさを評価しました。

比較項目	DynamoDB	Elasticache
パフォーマンス	○ 十分な速度	◎ 高速
インフラコスト	◎ 低コスト	△ 比較すると高コスト
運用性	◎ マネージメントコンソール上でデータ確認可能	△ データ確認できる環境整備に多少手間がかかる
スケーラビリティ	○ 設定で可能	△ 設定に多少手間がかかり、インフラコストも高くなる

表2. DynamoDBとElasticacheの比較

PL：こちらもLambda@Edge採用の理由同様に過剰なパフォーマンスよりも、コストや運用容易制を重視した形ですね。データストアの部分では有効期限管理もしていましたよね？

エンジニア：はい。短縮URLを長期間保持すると不正利用や保管データサイズの増加につながります。そのためデータに有効期限を設定して管理するようにしました。有効期限管理にはDynamoDBのTTL(Time to Live)機能を活用しています。これにより、データの自動削除が可能になり、不要データの削除ロジックを実装する必要がなくなりました。ただし、現在のAPIは有効期限の柔軟な指定にまだ対応できていません。今後、利用シーンの拡大が見込まれるため、APIでの有効期限指定機能の追加を検討中です。

PL：TTL機能の活用は開発工数を大幅に削減してくれましたね。今は有効期限は固定の設定になっていますが、既に短縮URLシステムを使いたいという新たな機能案が複数のプロダクトで聞こえてきていますし、APIの拡張は必須ですね。

初期リリース時の課題とその対応

パフォーマンス問題への対処

PL：本番運用を開始した直後に、少し問題が起きて緊急対応してましたよね？

エンジニア：はい、初期リリース時にSMSの一括送信処理のパフォーマンス劣化が発生しました。原因は、メッセージごとに短縮URLのAPIを呼び出していたため、n+1問題が起きていたことでした。この問題に対して、複数URLの一括短縮化APIを新たに実装し、パフォーマンスのチューニングを行いました。

PL：運用を通じて予期せぬボトルネックが見つかったわけですね。素早く対応策を立てられたことは良かったですが、こういったケースを事前に予見できるようになるのが理想的ですね。

エンジニア：そうですね。反省点として、初期設計の段階でユースケースをもっと詳細にストーリーベースで洗い出し、様々な利用パターンに備えた設計を心がける必要がありました。今後はユーザー視点に立ち、様々な状況を想定した設計を心がけていきたいと思います。

最後に

PL：本プロジェクトを通して、多くの技術的な課題に直面しながらも、着実に解決に導いてこられたことがよくわかりました。独自の短縮URLシステムを構築することで、低コストで自社ドメインの短縮URLを使い放題になったことは大きな成果です。

エンジニア：ありがとうございます。新しい技術的チャレンジをしつつ、それが単なるエンジニアの自己満足で終わらず、コストメリットもあり、複数のプロダクトで活用されるものが作れたことには満足しています。

PL：今後もこういったビジネスインパクトのある開発をどんどん起案していきたいですね。また、今回得た技術的なナレッジを組織内に展開していってくれることも期待してます。

エンジニア：はい。他の開発でも使えそうな知見が得られたので、来月のふりかえり会でも共有していきます。

PL：期待してます！