アプリストアでiOSアプリを使用していて、最近、EC2でホストされているランディングページへのトラフィックが急増し、ページが応答しなくなったため、幸い、インスタンスを再起動して、 t2.medium。
今私は、同じ死を再び防ぐための技術を実装するために誰かを雇うことを探しています。私の経験では、基本的なdevopsのことは理解できますが、AWSでのロードバランサーには不十分です。インスタンスの手頃な実装とは何かを知りたいのです。
ランディングページとiOSアプリのバックエンドが同じインスタンスでホストされています。
回答:
これ以上の知識がなくてもすぐにこれを並べ替えたい場合は、Elastic beanstalkをお勧めします。これは、ロードバランサーの構成とインスタンスのスケーリングを処理する別のAWSアプリケーションです。
ロードバランサーとインスタンスに追加のコストがかかることはないため、t2タイプのインスタンスを使い続けることができますが、Elastic Beanstalkを必要なだけ拡張できます。
自動スケーリングは瞬時ではなく、トラフィックが急上昇した場合、通常は数分でスパイクを処理できますが、手動でインスタンスサイズをスケーリングするよりもはるかに優れており、簡単に把握できます。と。
上記の自動スケーリングといくつかのCloudWatchアラームを追加して、特定のしきい値が増加し始めたときに自動スケーリングプロセスを開始することをお勧めします。
例えば; サーバーを監視するようにCloudWatchを設定します。CPUが50％以上で30秒以上続くと、自動スケーリングプロセスが開始されます。
これは完全に問題がないわけではありませんが、一部のオンラインガイドで簡単に実行でき、すべてGUIで設定できます。
また、ランディングページが静的である場合は、それをフリーティアt2.microでホストし、アプリに別のt2.microフリーティアを使用してみませんか？
トラフィックの急増に対処するには、容量を増やすこととコストを削減することの2つの一般的な戦略があります。
容量の増加は自動スケーリングを意味し、パブリッククラウドが最初に利用可能になったとき、誰もが非常に興奮していました。最も基本的な意味では、これは負荷に基づいてより多くのWebサーバーを起動し、ロードバランサーに追加しますが、管理が面倒になる可能性があるため、Elastic Beanstalkなどのより多くのオートマジックソリューションもあります。
自動容量拡張の問題は、自動請求拡張でもあります。通常の10倍のトラフィックは、10倍のサーバーが10倍のお金を支払うことを意味します。だからこそ、心に留めておくと便利な戦略ですが、まずは自分がどれだけカンニングできるかを見ることから始めるべきだと思います。
チートとは、キャッシュを意味します。これは、ほとんどの場合、ユーザーに日付のデータがわずかに古く、ユーザーが気付かないという考えに基づいており、大幅な時間の節約になります。古くて5秒で大丈夫だと判断したページがあり、20リクエスト/秒を取得したとします。キャッシングなしでは、その計算は1分間に1200回実行されますが、キャッシングありでは12しかありません。これがいかに大きな違いを生むことができるかがわかります。
もちろん多くのタイプのキャッシングがあり、成功したウェブサイトはそれらのいくつかを使用します。しかし、あなたのユースケースでは、2つのかなり良い簡単なオプションがあります。
1つ目は、サイトを完全に静的にすることです。これは可能であると想定していますが、可能であれば、Nginxに直接htmlを提供させるだけで、大量のリクエストに対応できます。
ある程度の動的性が必要な場合は、ページ全体のキャッシュを実行することをお勧めします。Nginxにはこれを行う機能がいくつかありますが、柔軟性があるのでVarnishが本当に好きです。
どのオプションを選択する場合でも、負荷テストを行って、正しく設定されていることを確認してください。1つのスポットを修正すると、新しいボトルネックが明らかになることがあります。
AWSでの経験を共有したいと思います。私たちはEC2にアプリケーションをデプロイしましたが、同じ問題と高コストに直面しています。アプリケーションはモノリシックですが、Amazon EC2 Container Serviceをデプロイしましたが、
Application Load Balancerはトラフィックを処理し、トラフィックを正常なインスタンスにルーティングします。負荷のスケーリングやバランスを心配することなく、同じサービスの複数のタスクを実行できます。
このアーキテクチャにより、障害分離の実装が容易になります。ヘルスチェック、キャッシング、バルクヘッド、またはサーキットブレーカーなどの手法を使用すると、障害のあるコンポーネントの爆発範囲を縮小し、特定のアプリケーションの全体的な可用性を向上させることができます。