以前、Alibaba Cloud がピットに足を踏み入れたことについての記事を書きました: Stepping on the Pit: A summary of C#'s access to Alibaba Cloud's API
. 歴史を掘り下げてみましょう。
1. AWS独自のCPUクレジット機構
このメカニズムは、CPU クレジットなど、AWS が標準を超えて追加の CPU パフォーマンスを使用できるようにするという趣旨で真剣に研究されていませんが、この超過時間には制限があります。この制限は CPU クレジット メカニズムです: 公式 Web サイトのルール参照。
たとえば、プログラムが大量の CPU を消費するが、購入した EC2 CPU がプログラム要件を満たさない場合、プログラムは実行時にクレジットを消費し、クレジットが使い果たされた後、プログラムは強制的に実行されます。が減少し、プログラムがフリーズしたり応答を停止したりすることがあります。
AWS には CPU クレジットだけでなくトラフィック クレジットもあることに注意してください。
以前に Alibaba Cloud を使用していて、この点の概念がありませんでしたが、プログラムが制限を超えた場合に Alibaba Cloud がどのように処理するかがまだわかりません。
私の騙された経験:
新しいプロジェクト、テスト環境で大規模なタスクのテストと実行 (まだプレッシャー テストは行われていませんが、データ量はさらに多くなります)、MySQL は頻繁にフリーズし、通常の主キー クエリ SQL には 1 秒かかります。 key 午前中は正常、午後は故障となります。
ほとんどの時間は正常ですが、ごく一部の時間に障害が発生しており、リソースに問題があることは間違いないため、さまざまな問題のトラブルシューティングに 1 週間を費やした後、さまざまな低速クエリの最適化によって問題は解決されなかったのではないかと考えました
。リソースの問題でした 監視を注意深く確認したところ、障害が発生する前は CPU が高い状態から低い状態に変動していましたが、障害が発生すると、MySQL の CPU は一定のポイントまで直接低下し、その後はほぼ一直線になりましたライン。
運用保守完了後、AWSに作業指示を出したところ、AWSからは「クレジットが有効になるから正常です。クレジットを使い切ってしまうと問題が発生しますので、アップグレードをお勧めします」との返答がありました。
ポイントメカニズムがない場合、問題はずっと前に発見されています。つまり、リソースが不足しています...
実際、その後の本番環境でも同様の問題が発生しており、トラフィックが集中するとポイント不足の問題が発生します。
解決する？当然、ポイント不足の状況も監視・警報の対象に含まれます。
2.DNSにはqps制限があります
これは実稼働環境で発生し、実稼働エラー ログを検査したところ、1 日のピーク時間帯に複数の DNS 解決エラー ログが表示されることが判明しました。
運用保守を調べても問題が見つからず、
AWSに依頼するために作業を発注したところ、
K8SのCoreDNSにはqpsアクセス上限要件があり、ホストマシンに関係するというものでした。ポッド数には関係ありませんが、
リクエスト量が多い場合はホストマシンの購入を増設する必要があります。
つまり、ホストに十分なリソースがある場合でも、DNS アクセス制限の問題が発生する限り、問題を解決するには新しいホストを購入する必要があります。
3. 必須のアップグレード要件
AWS の多くのサービス (kafka、k8s、mysql) は定期的にアップグレードされますが、アップグレードは必須であり、期限があり、期限に
達すると、AWS は強制的に自動アップグレードを実行します。
主要なアップグレードの頻度は依然として非常に高く、ほぼ 1 ～ 2 か月に 1 回ですが、その理由は、さまざまなバグや潜在的な安全上の問題を修正するためです。
しかし、通常の状況では、実稼働サービスは基本的にイントラネット上に展開され、IP ホワイトリストの制限があり、
通常、外部に公開される Web ポートは 80 と 443 のみであり、セキュリティ リスクがあったとしても、通常は問題ありません
。この方法でこのモノをアップグレードしても、私たちにとってメリットはほとんどなく、代わりにサービスが中断される可能性があります。
たとえば、Kafka の実際のアップグレード プロセスでは、
- 一部のシステム コンシューマ プログラムは冪等でないか、冪等が適切に行われていないため、ガベージ データが生成されます。
- 一部のシステム プロデューサーは ACK 保証を提供していないため、メッセージが失われます。
- また、Kafka 例外をキャプチャしないシステムもあり、その結果、後続のプロセスが中断されます。
もちろん、これらはシステムの堅牢性と使いやすさが不十分であり、例外の処理が不完全であるため、修復する必要があるという問題です。
ただし、起業家チームの実際の作業では、通常、SLA 品質保証作業にあまり時間が与えられないため、
アップグレードできない場合は、ビジネス チームは依然としてアップグレードせず、安定性に重点を置くことを望んでいます。