EC2：明らかなリソース競合のない定期的なパフォーマンスの問題
Ubuntu 9.10 x64 xlarge AmazonEC2インスタンスでLAMP + memcachedを実行しています。このサーバーは1秒あたり数百のリクエストを処理します。そのうちの約60％は静的で、残りはすべてmysqlやmemcachedと何らかの方法でやり取りします。このサーバーは、関連している可能性があり、診断が難しいことが証明されている2つのパフォーマンスの問題に悩まされています。以下のすべての統計は、特に指定がない限り、CloudWatch、munin、またはvmstat/iostat/topを使用して収集されています。
最初の問題は、ほとんどのApacheプロセスがすべてのハングを解除する前に約10〜30秒間同時にiowaitする間、数分ごとに高iowaitの定期的なスパイクが繰り返されることです。この間、ディスクまたはネットワークの負荷が増加することはなく、ディスクキューは低いままであり、スワッピングは発生しません。
さらに深刻なことに、ピーク時にはサーバーのパフォーマンスが突然大幅に低下し、サービス要求が直前の約1/3に低下することがあります。一度開始すると、このパフォーマンスの低下は2〜8時間続く可能性があり、その後突然完全なパフォーマンスに戻ります。これが発生すると、システムが何かを停止したかのようになります。 CPU使用率、ディスク負荷、およびネットワーク負荷（CloudWatchによって報告される）はすべて同時に比例して低下しますが、ディスクの競合はありません。ディスクキューとスループットの両方が低下し、特にこれらの低下の間、常に最大値を大幅に下回ります。 編集：この問題は解決されました。 Apacheはワーカープロセスを使い果たしており、何らかの理由で、正常に動作していたプロセスであっても、パフォーマンスを完全にクラッシュさせる正当な理由であると判断しました。
例外はネットワーク読み取りであり、これは以前と同じ高さのままであり、サーバーが以前と同じ量で引き続きアクセスされていることを示します。これが発生したときに自分でサーバーに接続しようとすると、サーバーは非常に遅くなり、リクエストを処理する前に接続を切断するだけです。パフォーマンスが現在低下しているかどうかに関係なく、メモリ使用量もCPU使用率も特に高くないことに注意してください。CPU％が10％を超えることはめったになく、ディスクがいっぱいまたは混雑していません。これらのディップ中のスワップパフォーマンスに関するデータはまだ収集できていませんが、収集しようとしています。
現状では、これらの不思議な問題を引き起こしている可能性のあるアイデアが不足しており、これがEC2自体の問題（または誤動作）である可能性があることをますます懸念しています。トラフィックがピークに達したときに大規模なディップが常に発生しているように見えるという事実（ただし、これはサーバーが利用可能なリソースを最大限に活用していることを意味するわけではありません）は単なる偶然ではありません。
すべてのMySQLデータベースとログはEBSボリュームでホストされ、すべての静的コンテンツは別の異なるEBSボリュームでホストされます。 Apacheは1秒あたり160〜240リクエスト、MySQLは1秒あたり180〜200クエリを処理し、memcachedからのクエリは最大0％、ヒット率は最大90％です。負荷平均は約3でホバリングする傾向があります。ディスクアクセスを最小限に抑えるために、Apacheアクセスログは無効になっています。
ほとんどの場合（2番目の問題で解決策を見つけたと述べたように）、これらの問題は構成またはその他のベースです。 EC2/EBS /その他のクラウドテクノロジーはこれの根源ではありません。これらは、これまでに受け取った回答とは逆に、どのような環境でも発生する問題です。
また、AmazonはSLAを提供しています。一部のリソースが競合する可能性は非常にまれですが、マイナーな状況があります。ただし、現在の使用状況を考慮することはほとんどありません。私は引き続きさまざまな論点について診断研究を行い、Amazon WebServicesの技術チームとも話し合います。そこには通常非常に知識のある人々がいるので、彼らのフォーラムもチェックしてください。あなたはフォーラムを知っているかもしれませんが、念のために-ここでそれらをチェックしてください： https://forums.aws.Amazon.com/index.jspa
また、アーキテクチャの観点から、この負荷を複数のEC2インスタンスに分散して負荷分散することを考えましたか？これは、これらの問題のいくつかを解決する必要があるオプションです。また、あなたが議論しているアーキテクチャから、少し力の弱いインスタンスに分割して作業を分散した方が全体的に良いかもしれないように思えます。他の利点は、サイト/サービスが成長し続ける場合、垂直方向ではなく水平方向に拡張するのに適した位置にいることです。もちろん、後者は制限されます。
何よりもまず、サイトの読み込みに深刻な問題が発生していることをお詫び申し上げます。私の知る限り、これらすべては、アプリケーションの可用性とパフォーマンスに関するSLAポリシーで概説されているはずです。
User37899がコメントしているように共有パブリッククラウドを使用することは、ミッションクリティカルなアプリケーションで集中的な運用である場合、このための理想的なプラットフォームではありません。共有の話は、プロセスがどこで実行されているかがわからないだけでなく、そのグリッド上の他の顧客によってパフォーマンスが影響を受けるということです。ストレージは、パフォーマンスの低下を引き起こしている特定のグリッド上の共有リソースである可能性が高いです。
Amazon x64 xLargeデプロイメントは適切に指定する必要がありますが、前述のように、ディスクリソースは、ボリュームとRAID構成によって切り分けられますが、共有プールからアクセスしています。
この問題を解決するための適切な対応に最も役立つように、あなたが何を持っているか、そして他のいくつかのパフォーマンスカウンターとデータベースアーキテクチャについてもう少し知りたいと思います。私には、より適切なソリューションのように思えますが、少なくともデータベースレイヤーをベアメタル上に配置するか、専用のハードウェアを利用するプライベートクラウドに配置することです。
お気軽にご連絡ください。チャットが可能です。頑張ってください。
EC2は共有ホスティング環境であるため（ホストは他のホストと同じハードウェアを共有します）、I/O操作にかなりのばらつきが見られます。 EBSボリュームは基本的にNASであり、ネットワークトラフィックと同じNICを共有します。各物理ホストはバックボーンへの接続が1Gbしかないため、他の顧客のネットワーク操作と競合しているだけでなく、その顧客やディスクとのネットワーク競合もあります。実際には、他の多くのトラフィックの多い顧客とボックスを共有していない限り、ネットワークの競合は通常問題にはなりません。より大きなインスタンスを使用することによるものです（より大きなインスタンスはボックスのより大きな割合を占めるため、共有リソースが少なくなります）。
ピーク時およびこれらの問題の期間中に、どのような種類のIOPSが発生していますか？ （sar -d tps列）
これらの期間中のあなたの盗み時間は何ですか？ （iostat -x1またはsar-u）。
複数のEBSボリュームを一緒にソフトウェアRAIDすることで、IOP容量を増やすことができます。これはiowait時間を短縮するのに役立ちます。ぎこちないように聞こえますが、実際には機能します。これではネットワーク競合の問題は解決されませんが、トラフィックが多いため、リンクが飽和状態になっているとは思えません。ただし、別の顧客がいる可能性があり、あなたにいくらかの苦痛を引き起こしています。
残念ながら、このタイプの問題の簡単な解決策は、単にインスタンスを再スピンすることである場合があります。共有顧客が異なる別のホストで発生する可能性があります。 EC2のお客様は、インスタンスをスピンし、いくつかのベンチマークを実行し、結果に不満がある場合は再スピンするのが一般的です。
もう1つの推奨事項は、Web層とデータベース層を異なるサーバーに分割することです。通常、web/dbを備えた単一のサーバーは、さまざまな理由から悪い考えであり、この場合、ボトルネックの診断がさらに困難になる可能性があります。