More than 3 years have passed since last update.

ZOZOテクノロジーズ #4Advent Calendar 2020

@tippyin

株式会社ZOZO

【最安値】AWSで独自ドメインの短縮URLを安く作る妙案【かもしれない】

Posted at 2020-12-09

概要

API Gatewayだけで短縮URLを作ります ← 本記事
URLはGitHubリポジトリで管理しCI/CDで更新します ← 次の記事

【問】 AWSで短縮URLサービスを作る場合、どんなアーキテクチャにしますか？

1. API Gateway + Lambda + DynamoDB

サーバーレスのお手本構成です。DynamoDBを使いたくない場合はRDSも使えます。RDS Proxyの登場により、従来アンチパターンとされていた Lambda + RDS の構成が取りやすくなりました。

【参考】【待望リリース！】もう Lambda×RDS は怖くない！LambdaでRDSプロキシを徹底的に検証してみた〜全てがサーバレスになる〜

Lambdaはコールドスタートでレスポンスが遅くなる場合がありますが、Provisioned Concurrency を使えば回避することができます（ただし別途お金がかかります）

【参考】Lambdaのコールドスタートを改めて整理する

2. ELB + EC2 + RDS

昔から愛されるスタンダード構成です。私も初めてAWSを触ったときはこの構成でRuby on Railsを動かしました。ただ最近の流行りはサーバーレスやコンテナかもしれません。

3. コンテナ

ECSまたはEKSになります。いずれもFargateかEC2を選べるので、実質4つの選択肢があります。諸説ありますが、ECS on Fargate がもっとも手軽だと個人的には思います。あとEKSは少々高いです（執筆時点で月72ドル〜）

【参考】EKSは本当にECSより難しいのか？

4. CloudFront + S3

いきなり意味不明ですが、そもそもアプリケーションは必要でしょうか？必要なURLの数だけ静的なWebページを作ればよくないですか？ WebページにJavaScriptを書けばリダイレクトできますよ？ HTTPステータスが200になりますケド。毎回HTMLファイルを作ってS3に置くのが面倒くさければ、CI/CDで自動化できなくもないですよ？...

自分ならやりません。HTTPステータス大事だし。

機能要件

ひとくちに「短縮URLサービス」と言っても色々な定義があると思います。アーキテクチャを考える前に、私が作りたいものの要件を以下にまとめます。

短縮URLの作成は自分（や限られたユーザー）のみが行う（＝誰でも短縮URLを作れるサービスではない）
短縮URLの作成はGUIでなくてもよいが、限りなくラクに行う
すでに持っている独自ドメインを使う
めちゃくちゃ安くする

※ この要件に深い意味はなく、ただ「私が作りたいもの」というだけです

で、このアーキテクチャを思いつきました

以下が本文です。

API Gatewayだけで短縮URLを作る

API Gatewayにはモック統合というものがあります。端的に言うとモックサーバーを簡単に作れる機能です。

【参考】Amazon API Gateway でのモック統合による REST API の作成

そしてふと思いつきました。モックで301を返せばリダイレクトできるのでは？と。

圧倒的安さ

AWSには12ヶ月の無料枠がありますが、それは含めず考えます。

記事執筆時点で、東京リージョンのAPI Gatewayの料金は次のとおりです（公式）

最初の3億3300万リクエストまで　100万リクエストあたり　4.25ドル

**なかなか安いです。**~~他のリージョンはもっと安いですけど~~

（別に外部へのデータ転送料金もかかりますが、今回はデータ量は限りなく少ないです）

そしてLambdaやデータベースは使わないので、その他の料金はかかりません。

APIを作ってみる

最終的にはCloudFormationを使いますが、まずはマネジメントコンソールで試します。

▼ REST APIを作成

▼ エッジ最適化を選択

▼ APIが完成。さっそくリソースを作成

▼ メソッドの作成。GETを作る。

▼ Mockを選択。

これで次の設定画面にたどり着きます。

詳解：モック統合

▼ この画面では4つの設定をします。①〜④の順に説明します。

① メソッドリクエスト

クライアントから受け取るパラメータ・ヘッダーと、認可について設定します。今回は編集しません（誰でもURLにアクセスできるようにし、パラメータなしのGETメソッドにするからです）

② 統合リクエスト

①メソッドリクエスト の内容をどのようにバックエンドへ渡すか定義します。マッピングテンプレートを使うことで、①の内容を加工してバックエンドへ送ることができます（バックエンドには通常LambdaやAWSサービスが選べます。一つ前の手順でモック統合を選びましたが、それは「バックエンドをMockエンドポイントにした」ということです）

重要なのは、モック統合の場合、ここで渡す内容がそのまま ④統合レスポンスに返ってくるということです

デフォルトではContent-Type: application/jsonのマッピングテンプレートに{"statusCode": 200}が入っています。今回は編集せずそのまま使います（ここを301にするやり方もあります。というかそれが正しいと思います）

③ メソッドレスポンス

クライアントに返すHTTPステータス・ヘッダー・コンテンツの組み合わせをここで定義します。例えばクライアントに200と503を返す場合は、その2つを定義しておきます。

画面の矢印の向き的には ④統合レスポンスを先に設定したくなりますが、先にこれを設定する必要があります。

▼ 今回はHTTPステータス301をLocationヘッダー付きで返したいので、以下のように設定します（すでにあった200は消しました）

④ 統合レスポンス

ここが一番難しいです。ざっくり言えば ③メソッドレスポンス と バックエンドからのレスポンス の対応表を定義します。例えばバックエンドから504が返ったときはクライアントに503を返すという設定をします。マッピングテンプレートを使うことで、バックエンドからのレスポンスを加工することもできます。

▼ 今回はバックエンド（＝モック）から200が返ってきた場合に302をクライアントに返すようにします。さらに「ヘッダーのマッピング」を使い、Locationヘッダーに'http://abehiroshi.la.coocan.jp/'を追加します（ちなみにクォーテーションがないとエラーになります）