URL短縮サービスの設計と実装

Posted at 2025-10-25

はじめに

近年、SNSやブログなどで情報を共有する際、長いURLは文字数制限や見た目の問題から敬遠されがちです。URL短縮サービスは、このような長いURLを短く、扱いやすい形式に変換するサービスであり、現代のウェブコミュニケーションにおいて重要な役割を担っています。

本記事では、そのアーキテクチャ、パフォーマンス分析、そして今後の改善点について解説します。

「Shortify」は、Docker Composeを利用して構築されており、以下のコンポーネントで構成されています。

各コンポーネントの役割は以下の通りです。

この構成により、スケーラビリティとメンテナンス性を両立させています。

サービスの性能を評価するため、analysis.ipynb というJupyter Notebookを用いて以下のパフォーマンステストを実施しました。

テストは、ローカル環境でDockerコンテナを起動した状態で行いました。

負荷テストの結果、以下のことが分かりました。

1000件の短縮リクエストを連続投入した結果、処理完了までに5.52秒を要し、平均レイテンシは4.64ms、スループットは181リクエスト/秒でした。HTTP 200の成功レスポンスが1000件中1000件、ID衝突は発生せず、リダイレクトも最初の200件すべてがHTTP 302で応答しました。

この結果は単一ノード構成で期待できるスループットの目安となり、さらなる余裕を確保するには水平スケールやキャッシュ層の強化を検討する余地があります。

URL短縮処理とリダイレクト処理のレイテンシを個別に測定した結果です。

処理内容	平均レイテンシ (ms)
URL短縮	4.64
リダイレクト	5.90

URL短縮処理はアプリケーション層でのID生成と保存を含めても平均4.64msで完了しました。一方、リダイレクト処理はRedisキャッシュ経由でもネットワーク往復が加わり、平均5.90ms（最小3.37ms、最大9.01ms）でした。

パフォーマンステスト以外にも、以下の観点で動作検証を行いました。

正常系リダイレクト: 長いURLを短縮し、302リダイレクトで元URLへ遷移することを確認しました。
一意性・冪等性: 異なるURLから生成されるスラッグが衝突しないこと、同一URLからは常に同じスラッグが返ることをテストで検証しました。
キャッシュ性能: Redisキャッシュをウォームアップした後に5回リダイレクトを繰り返したところ、平均レイテンシは5.90ms（最小3.37ms、最大9.01ms）でした。
エラー処理: 不正なURLにはHTTP 422、存在しないスラッグにはHTTP 404が返ることを確認し、入力バリデーションが有効に機能していることを確認しました。
短期安定性: 0.5秒間隔で3回リダイレクトを行っても、すべて302で期待通りのLocationヘッダーが返りました。

今回のパフォーマンス分析の結果を踏まえ、以下の最適化が考えられます。

キャッシュ戦略の見直し: 現在は単純なキャッシュアサイドパターンですが、より積極的にキャッシュを活用する（例：Write-throughパターン）ことで、書き込み処理のレイテンシを改善できる可能性があります。
データベースのスケールアウト: 書き込み負荷がボトルネックであるため、データベースをシャーディングするなどして、書き込み性能を向上させることが有効です。
ID生成方法の改善: 現在はデータベースのシーケンスを利用していますが、より高速なID生成アルゴリズム（例：Snowflake）を導入することで、書き込み処理全体の高速化が期待できます。
エラー応答ポリシーの明確化: Notebookでは不正なURLに422、存在しないスラッグに404が返りました。期待する仕様と突き合わせ、メッセージ整備やバリデーションルールの共通化を検討する余地があります。

本記事では、URL短縮サービスの設計と実装、そしてパフォーマンス分析について解説しました。負荷テストを通じて現状の課題を明らかにし、今後の改善の方向性を示すことができました。