ECSで作ったサイトが超重かった原因はLB設定ミスでした
何があった
https://tagfoto.link/
というプライベートな画像アップローダーをRailsで構築してFargateでECSにデプロイしたんですよ。そしたら超重いんですよ。原因を探りました。
結論
ロードバランサーの設定ミスでした。あ、タイトルにも書いてるのでここに書く意味もあまりなかった。
もう少し詳細に書くと、VPCの2つのサブネットの内1つがパブリックではなくプライベートでした。これをパブリックのものに変更し、改善されました。マジで原因の特定に時間掛かった。誰にも聞けないし、Googleだと関係ない記事ばかり引っかかるしで苦労しました。AWSのログの見方を、まずは理解する必要があると思いました。(ただAWSのログに触れてる記事って例外なく糞ムズいんですよね。そしてAWSって公式のドキュメント自体が超ムズいし。萎える・・。が、後々絶対役に立つはず)
公開までの流れ
色々な記事を参考に、下記を実施しました。やった通りの順番にしてますので、「本来なら先にこっちをやるべき」というのもありますがそこはご愛嬌ということで。
- 作ったRailsアプリをコンテナ化
- VPC作成
- RDS作成
- AWS CLI使えるようにする
- ECRにプッシュ
- FargateでECSにデプロイ
- Route53でドメイン取得、レコード設定
- 証明書発行
- ターゲットグループ作成
- ロードバランサー作成
- ECSのタスク定義更新(ロードバランサー設定)
- もっかいECSデプロイ
ここまでやって、ようやく「ローカル環境にてDockerで動かしていたWebサービスを、自分の好きなドメインでみんなに使ってもらえる」状態になります。で、実際そうなったんですよ。「あ、動く動く！」って。
ポートフォリオサイトにした
で、これも現在進行系(なおかつこのブログのURLも先方に伝えてる)なんですがね、Web開発系の会社に応募しまして。そして応募書類に、上記サイトをポートフォリオとして記載している訳です。
立ち上がりが遅いぞ
応募書類をメールで送ってしばらくして、ふともう一度サイトにアクセスしたんです。「万が一止まってたらスキル疑われるよな〜」って。そしたら、読み込まないんです。いや、正確に言うと「アクセスして1分くらい、全くなんの反応もなく、その後何事もなかったかのように動き出す、その後しばらくはサクサク動く、でも時間を置くと(30分くらい？)また同じように、アクセスしたらしばらく止まる」という症状なんです。
応募書類は、金曜に送っています。土日に直すしかないですよね。動きの早い会社なら、もうサイト見てますよね。「あれ？遅え！」ってなりますよね。俺、終わった・・。ってなった訳です。この「遅いのに気づいた」のがこの金曜の夜(2023年8月18日 金曜日 23時)の話。変な汗が止まりません
改善に向けて何をやったか
ここが、俺の要改善ポイントだと思うんですが、ログにそこまであたってないんですよ。結果論(いや、一般論か？)ですが、AWSの色んなログっぽいものを見まくったらもう少し早めに直ってたと思います。やったことと結果は下記です。
- ECSの正常性のグラフ → 異常なし
- RDSのグラフ → 異常なし
- Googleで「ECS Fargate アクセス 遅い」で検索 → デプロイの遅さに言及する記事が目立つものの、ECSタスク定義のCPU、メモリのアップによる速度改善について触れているものもあった → やってみたが効果なし
- ECSのパブリックIPでアクセス → 遅くない → ということはRoute53のレコード設定か証明書発行あたりか？ → 再度、参考にした記事を確認 → その通りできている
- ChatGPTに聞いてみる → あまり参考にならず(最下段の参考1参照)
- ロードバランサーか？とふと思いつき「aws load balancer 遅い」で調べる → それっぽい記事発見 → VPCのサブネットとルートテーブルの紐づけミスだったので俺とは違うな → 診断サイトの存在を知る
- 診断サイトやる → 「77秒(おい！)です。99％はSSHが原因です。」とのこと
- またもChatGPT → 回答の2つ目に、ロードバランサーの設定ミスと書いている(最下段の参考2参照)
- ECSのコンソールにて、作成したLBの「サブネットの編集」を見る → なんか「プライベートだけどいいの？」的な警告文出てる → パブリックのサブネットに変更 → 改善
参考1(ChatGPTとのやり取り)
質問
Rails(DBはRDS)で作ったサービスをfargateでECSに置いているが、URLでアクセスすると、とにかく遅い。ただ、正常に表示された後はサクサクどのページに行っても動く。しかし、しばらくアクセスしないと、再度アクセスしたときに同じように遅い。ちなみにデプロイにかかる時間は標準。下記アドバイスください
1 ECS,RDS等の何のグラフを見れば遅い原因が分かるか。
2 遅い原因は何が考えられるか。
回答
遅いパフォーマンスの問題に対処するためのアドバイスを以下に示します。
1.ECS、RDSのパフォーマンスの監視：
ECSとRDSのコンソールで、以下のグラフやメトリクスをチェックしてみてください。
- CPU 使用率: サービスやデータベースのCPU使用率が高い場合、パフォーマンスに影響を及ぼす可能性があります。
- メモリ使用率: メモリ使用率が高い場合、システムのスワップや遅延が発生する可能性があります。
- データベースのクエリパフォーマンス: RDSのクエリログやパフォーマンスメトリクスを確認して、クエリの遅延がないか確認します。
2.遅い原因の考えられる要因：
- コールドスタートの影響: Fargateはコンテナを必要に応じて起動するため、初回アクセス時にコールドスタートの遅延が発生する可能性があります。
- リソース制約: ECSコンテナやRDSが十分なリソースを確保しているか確認してください。不十分なリソースはパフォーマンスの低下を引き起こす可能性があります。
- データベースクエリの最適化: RDSのクエリが効率的でない場合、データベースの負荷が増加し、遅延の原因となる可能性があります。
- キャッシュの活用: データベースやアプリケーションの結果をキャッシュして、頻繁なアクセスの高速化を図ることができます。
上記のステップに従って、問題の特定と解決策の導入を検討してみてください。状況によっては、ボトルネックやルート原因を特定するのに時間がかかるかもしれませんが、障害排除のプロセスを進めることでパフォーマンスを向上させることができるでしょう。
参考2(ChatGPTとのやり取り)
質問
ECSのサイトの遅い原因を、解析サイトで調べると「Webサーバーの接続受付（SSL）」が99%の原因だった。時間は77秒。対処法を教えてほしい。。ちなみにECS,fargate,route53,ロードバランサーを使っている。
回答
Webサーバーの接続受付（SSL）が遅いという問題に対処するためのいくつかの対策を以下に示します。
- 使用するSSL/TLS証明書の確認: SSL/TLS証明書の選択や設定に問題がないか確認してください。証明書の更新が必要な場合は、最新の証明書を使用してください。
- ロードバランサーの設定を最適化: 使用しているロードバランサーの設定を確認し、適切に設定されていることを確認してください。必要に応じてロードバランサーのタイムアウト値やヘルスチェックの設定を調整してみてください。
- ネットワーク帯域幅の拡張: ECSタスクやFargateコンテナのネットワーク帯域幅が不足している場合、サーバーの応答が遅くなることがあります。必要に応じて帯域幅を増やしてみてください。
- アプリケーションの最適化: Webサーバーのコードや設定が最適化されているか確認してください。余分な処理や遅延の原因となる要因を特定し、改善を行ってください。
- CDNの使用: Amazon CloudFrontなどのCDN（コンテンツデリバリーネットワーク）を導入することで、コンテンツの配信を高速化し、サーバーへの負荷を軽減できる場合があります。
- コンテナのスケーリング: サーバーへの接続が遅い場合、タスク数を増やすことでトラフィックの処理を分散することができます。Fargateのスケーリング設定を調整して、トラフィックの増加に対応できるようにしてみてください。
- ボトルネックの特定: ロードバランサーやコンテナ、インフラストラクチャの各部分でボトルネックが発生していないか詳細に調査し、特定してください。
このような対策を検討し、問題の根本原因を特定してから対処を行うことで、Webサーバーの接続受付の遅延を軽減することができるかと思います。
