お疲れ様です。Qiita初投稿なので温かい目で見ていただけると幸いです。
今回、秋のハッカソンでインフラ担当を担っていたのですが
デプロイ後の本番環境で動作が重くて、思い通りの挙動が出来ず苦戦しました。
具体的な事象
主に以下の2点がありました。
- 画面遷移に非常に時間がかかる
- URL を開くまでに 2 分以上かかる
以下、それぞれどのように解消したのか記載していきます。
画面遷移の問題
原因は以下の二つでした。
その１：署名付きURLを設定していた。
AWS_QUERYSTRING_AUTH = True #Trueにした結果、署名付きURLを設定していた。
ここをTrueにしてしまうと以下のような理由で動作が重くなります。
-
毎回「有効期限付きの署名」を計算
- CPU で暗号計算が走る（OpenSSL）
- CSS / JS / PNG など 全静的ファイル分発生
-
毎回 URL が変わる（動的URL）
# 具体例
https://bucket.s3.amazonaws.com/static/logo.png?AWSAccessKeyId=xxx&Expires=1700000000&Signature=xxxxx
- キャッシュが効かない
- CloudFrontやブラウザのキャッシュが不可になる
- すべての静的ファイルが毎回ダウンロードされる
- PCブラウザは拡張機能が多いので解析が余計に遅くなる
解決策
今回、自分たちが作ったサービスでは静的ファイル(CSS/JS/画像）のみで
これらは公開前提のため署名付きURLにする必要はありません。
そのため署名付きURLの設定をFalseにしました。
AWS_QUERYSTRING_AUTH = False #Falseに変更
余談ですが署名付きURLを Trueにすべきケースは以下の通りです。
機密ファイルを扱う場合
例：個人情報、ユーザーデータ、内部資料など、外部公開できないもの。
ユーザーごとにアクセス制限をかけたい場合
例：「ログインユーザーだけ閲覧可能」「購入者だけダウンロード可能」など。
期限付きで一時的にアクセスを許可したい場合
例：サポート対応で「この画像だけ 24 時間共有したい」など。
ダウンロード回数・アクセス範囲をコントロールしたい場合
例：外部に勝手に拡散されたくない資料を配布する際など。
CloudFront + Signed URL / Signed Cookie を使って制御する場合
一般公開したくないコンテンツを配信する用途。
API 経由で非公開オブジェクトを扱いたい場合
Webアプリ側から S3 の非公開ファイルを取得するときに使う。
料金の観点で S3 をパブリック公開したくない場合
（ただしこれは安全性の理由がメイン）
その２：STATIC_URLを S3 にしていた。
S3から静的ファイルを配信すると遅い理由は以下の通りです。
- TCP/TLSの確立が重い
- レイテンシが比較的大きい
- 初回アクセスが特に遅延
- PNG/JS/CSSなど複数ファイルを一気に読むため負荷増
- PCブラウザでは HTTP/2 セッション再利用が効きにくく、余計に遅い
解決策
- 今回実施したもの
以下のようにS3配信からローカル配信に切り替えました。
# STATIC_URLをローカル配信に変更
STATIC_URL = "/static/"
上記の変更により、静的ファイルが EC2（Nginx）から直接配信されるようになります。
- S3連携の場合
もし S3 を利用し続ける場合はCloudFront を導入してキャッシュ配信する構成も有効だと思います。
（今回は時間の都合上、実施しませんでした。）
URLの問題
URL を開くまでに非常に時間がかかり、この問題の解決にはかなり苦労しました。
状況は以下の通りでした。
- PCは重い
- スマホは開くまでにそこまで支障がない
なぜこのような違いになるのか気になりました。
調査していく内に以下の記事を見つけました。
この記事を参考に調査をしたら
ALBが参照しているサブネットを確認したら
片方のサブネット(赤枠で囲っているもの）がPrivateでした。
このPrivateサブネットから別のPublicサブネットに変更したところ
URLの不具合が解消されました。
（完全に自分の凡ミスです汗）
※コンソールから上記画面に行くまでの方法
AWS コンソール → EC2 → ロードバランサー→ 対象の ALB をクリック
→ ネットワークマッピングタブをクリック
詳細
-
ALB はインターネット向けの場合、Publicサブネットに配置必須
- 片側が Private だと ALB が正常に Internet Gateway を使えない
-
ルーティングが不整合
-
ALB の内部でヘルスチェックや AZ 間ルーティングが片側しか働かない
→ 初回の接続確立に時間がかかることがある
-
-
ALB が片AZのみ稼働になっていた可能性
- これもレスポンス遅延の原因になる
まとめ
振り返ってみると、今回の不具合の原因は、
結果的には自分の初歩的なミスだったと思います。
たったこれだけの見落としでここまで悩まされるのかと実感したので、
この経験を糧に、AWS の構築について改めて学び直す必要があると感じました。