AWS上のシステム設計

第14章 URL短縮サービスの設計 URL短縮サービスをデザインする

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第9章でDNSの概念について説明し、WebサイトのURLはIPアドレスよりも覚えやすいと述べたが、長いURLについてはどうだろうか？URLのルート部分（例えば、https://learning.oreilly.com/library/view/system-design-on/9781098146887 のlearning.oreilly.com）は覚えやすいが、長いURLは忘れやすい。私たちがよくテキストにリンクを埋め込むのは、その方が読みやすさが増すからだ。

長いURLを共有するもう一つの方法は、短縮することだ。例えば、LinkedInでは、投稿の一部であるURLは自動的に短縮される。これは、投稿の読みやすさとユーザ対話を高めるのに役立つからだ。Twitter（現在はXとして知られている）のようなマイクロブログのアプリケーションでは、1つの投稿の文字数に制限があるため、文章の長さを短くするために、TinyURLや BitlyのようなURL短縮サービスを使ってURLを短縮し、フルレングスの代わりにそれらを投稿に添付することができる。

この章では、URL短縮サービスの設計を検討し、AWSクラウド上にシステムをデプロイする方法について議論する。まずは要件収集とシステムに期待することから議論を始める。その後、システムの詳細に入る。

システム要件

、解決すべき問題について明確な目標を持つべきである。そこから、大小を問わず、どんなシステムでも設計するための次のステップは、要件を集めることである。これらの要件には次のようなものがある：

• なぜこのシステムが必要なのか？このシステムが解決しようとするビジネス上のユースケースは何か？

• このシステムのユーザは誰か？ユーザ数は？

• ゼロから新しいシステムを設計する代わりに、活用できるシステムはすでにあるのか？Bitlyのようなシステムは、URL短縮APIをビジネス顧客に公開している。では、BitlyシステムのAPIを利用する代わりに、なぜ独自のシステムを構築する必要があるのか？

• システムの遅延は重要か？

要件リストは膨大になり、作成には時間がかかるが、これは非常に重要なステップである。第1部と第2部では、2つのテクノロジーを比較し、ビジネス・ユースケースの理解に応じて最適なソリューションを選ぶ方法について何度も説明した。要件が明確に定義されていなければ、選択肢の長所と短所を比較検討することはできない。システムの要件は通常、機能要件と非機能要件（NFR）の2つに分類される。

機能要件と非機能要件

機能要件とは、、システムがエンドユーザに提供する機能や特徴のことである。URL短縮サービスに期待されることはシンプルである：

• このシステムは、長いURLとして入力を受け取り、短縮URLを返す。

• 短いURLは、どのユーザがアクセスしても長いURLにリダイレクトされなければならない。

最もクリティカルな要件とともに、顧客の視点に立った付加価値の高い要件や、ビジネス価値を引き出すのに役立つ要件を検討することができる。以下のようなものがある：

• カスタムURL作成サポート

• 最も人気のあるURLなど、URLのアクセスパターンを分析する。

• URLの有効期限を設定し、一定期間が経過すると自動的に有効期限が切れてアクセスできなくなるようにする。 ...