高並行性マスクスナップアッププロジェクトアーキテクチャの進化の記録と最適化の経験の共有

牧原石

著者：Yang Muオリジナル（元のニックネーム、畜産）、Ali Cloudテクノロジーの専門家、長年のオペレーティングシステムとアプリケーションのデバッグ経験、深い理論的知識、実践的な経験。現在、Linuxのパフォーマンスチューニング、コンテナクラスター、システムネットワーキングに重点を置いています。
この記事は、元のテキストに基づいてわずかな変更を加えて、公開アカウント「ProgramApeStone」で公開することを元の作成者によって承認されています。

バックグラウンド

流行の初めに、ある場所の政府が市の市民に無料のマスクのバッチを発行することを決定し、この市の市民は無料で収集の予約をすることができます。予約時間は午前9時から12時までです。そのため、このシーンは期間限定のラッシュ購入シーンであり、非常に大きなタイミングに直面します。大規模なトラフィックと大規模な同時実行の問題については、プロジェクトの実施中に、いくつかの記録と考えが関係するアーキテクチャ。

アーキテクチャ図と分析-V1

オリジナルアーキテクチャの図解と分析（
高並行性マスクスナップアッププロジェクトアーキテクチャの進化の記録と最適化の経験の共有
2月2日午後22時頃のオリジナルアーキテクチャ）2月2日午後22時頃のオリジナルアーキテクチャ

クライアントはHTTPSプロトコルを使用してECSに直接アクセスします。
ECSでNginxを使用して、HTTPS443ポートを監視します。
NginxはTomcatを逆にし、Nginxは静的ファイルを処理し、Tomcatは動的要求を処理します。
プログラムは最初にRedisに移動してキャッシュをチェックし、ミスがある場合はデータベースに移動してデータをクエリします。同時に、RedisとMysql間のデータ同期はプログラムによって制御されます。

このアーキテクチャ設計：

利点：管理が簡単で、展開が簡単です。
短所：パフォーマンスの低下、スケーラビリティの欠如、および単一のリスクポイント。
結果：アプリケーションがオンラインになるとすぐにハングアップし、不明な理由で予定ページがリークされ、サービスが予約時間前に電話を切る。
アーキテクチャ図と分析-V2

次に、介入してアーキテクチャを調整しました。24：00頃に、午前9時にサービスを開始するように依頼しました。時間が厳しすぎ、タスクが重すぎて、プログラムを移動できません。の並行アーキテクチャの実行方法数十万人？
2月3日午前9時頃の建築、4
高並行性マスクスナップアッププロジェクトアーキテクチャの進化の記録と最適化の経験の共有
日午前9時頃の建築復元）2月3日午前9時頃の建築

SLBに接続し、ミラーリングによって負荷容量を水平方向に拡張します。
読み取り/書き込み分離データベースアーキテクチャへのアクセス、Alibaba Cloudデータベースによる自動読み取り/書き込み分離、および自動データ同期。
Nginxプロトコルを調整します。
同じアーキテクチャのスタンバイクラスタが有効になります（ドメイン名解決のために2つのAレコードが作成されます）。
アクセスログを分析したところ、失敗の理由はSMSを取得し、ログインしてCookieを初期化した時点であることがわかりました。

このアーキテクチャ設計：

利点：高可用性の向上と負荷容量の拡張。
短所：トラフィックの見積もりが不十分で、静的ページもECSにあるため、SLBの出力帯域幅は一度最大値の5.XGに達し、同時実行性は22w +に達しました。
結果：トラフィックが多すぎるため、ユーザーはしばらくページを開くことができませんでした。同時に、ドメインネームサービスプロバイダーXXの制限により、顧客は自分で解決策を追加できませんでした。その夜、ドメインネームサービスプロバイダーに連絡できなかったため、CDN計画が取り残されました。
アーキテクチャ図と分析-V3

高並行性マスクスナップアッププロジェクトアーキテクチャの進化の記録と最適化の経験の共有
2月5日のアーキテクチャ

超広い帯域幅をオフロードするためのCDNへのアクセス。
Nginxプロキシをキャンセルします。
新しいプログラムが時間どおりにオンラインにならないようなディザスタリカバリ切り替え計画を作成しました（使用されるとは思っていませんでした）。
仮想サーバーグループを使用して新しいプログラムと古いプログラムを切り替えますが、欠点は、7層の監視SLBバックエンドがハングできるのは200台のマシンのみであり、それ以上のSLBがそれを保持できなくなるため、古いプログラムが引き継がれる;
5日はこのアーキテクチャを使ってオンラインにしました。在庫は7分で完売し、とてもスムーズな体験でした。健康な学生が開発した新しいプログラムは本当にクールです。

このアーキテクチャ設計：

利点：CDNは静的リソーストラフィックに負担をかけるため、SLB出力帯域幅が減少し、ストレステストの効果も非常に理想的です。
短所：ページにクロスドメインを含む追加の独立したドメイン名が必要です。4日にテストを開いたときに、ウェアハウジングと予約済みのSMSが文字化けして戻ってきたことが判明し、緊急に古いプログラムに切り替えられました。つまり、第2世代のアーキテクチャです。
理想的なアーキテクチャ図と分析-V4

高並行性マスクスナップアッププロジェクトアーキテクチャの進化の記録と最適化の経験の共有
理想的なアーキテクチャ

メインドメイン名アクセスCDN;
CDNは、ソースに戻るHttpおよびHttpsプロトコルを設定して、SLBのさまざまな監視にアクセスし、新しいプログラムと古いプログラムを切り替えます。具体的な実装は、ソースに戻るプロトコルの対応です。異なるモニターは異なるプログラムに対応します。

このアーキテクチャ設計：

利点：静的アクセラレーションにより、SLB帯域幅が減少し、ソースに動的に戻り、クロスドメインの問題が発生せず、切り替えが便利になります。
短所：手動で設定する必要があり、ミラーリングによってecsをデプロイするのは不便です。十分な時間があれば、コンテナアーキテクチャを直接使用できるのは非常に良いことです。スケールは数十または数百に拡張できます。ポッド、およびノードも自動的に拡張できます。
総括する

時間は厳しく、仕事は重く、私は多くの落とし穴に遭遇しました：

vcpu購入クォータ;
SLBバックエンドマウントクォータ。
顧客の残高が不十分な場合、延滞は停止します。
ドメインネームサービスプロバイダーの解決策は、追加するためにカスタマーサービスに連絡する必要があります。
CDNアーキテクチャが最初に検討されたとき、クロスドメインの問題は考慮されていませんでした。
新しいプログラムの開発中に、メインライブラリがテストに接続されなかったため、オンライン障害が発生しました（メインライブラリが文字化けしました）。
初めて（No. 3）が中断されたときは、SLBのトラフィックのみが関係し、最も障害の多いリンクは詳細に分析されませんでした。
圧力テストは、純粋に手動テスト機能に依存して、オンラインになる前に欠落しています。
圧力テストはJmeterに依存しています（PTSは圧力測定のために4日の夕方から5日の朝に導入されました）。
突然、クライアントの元のプログラムがWindowsに配置され、Windows +不良プログラムのパフォーマンスが非常に悪かったことを思い出しました。
この「小さなプロジェクト」は、実際には前後に10万ドルもかかりますが、最初からやっていけば、コストを半分に減らすことができるはずです。
最終結果統計（サンプリング分析、実際のデータはこれよりも大きい）：

結果統計（サンプリング分析）の
最後の3世代がオンラインになり、150台のマシンが保険目的で使用されましたが、イベント中の観察と結果に基づいています圧力テストの結果50台のマシンが耐えられるはずだと推定されています.5時間のクラッシュやエンドユーザーによる叱責から、7分で完売したリーダーの称賛まで、3回の夜間戦闘の後でも、私はまだ感じることができます漠然と。体と心が昇華します。
さまざまな最適化ノート

パラメータの最適化

ネットワークチューニング


net.ipv4.tcp_max_tw_buckets = 5000 --> 50000
net.ipv4.tcp_max_syn_backlog = 1024 --> 4096
net.core.somaxconn = 128 --> 4096
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1(5和6同时开启可能会导致nat上网环境建联概率失败)
net.ipv4.tcp_tw_recycle = 1

/etc/security/limits.conf


* soft nofile 65535
* hard nofile 65535

Nginxパラメーターの最適化


worker_connections  1024-->10240;
worker_processes  1-->16;（根据实际情况设置，可以设置成auto）
worker_rlimit_nofile 1024-->102400;
listen 80 backlog 511-->65533；

一部のシナリオでは、nginxが長い接続を開いて、短いリンクによって引き起こされるオーバーヘッドを最適化することも検討できます。

アーキテクチャの最適化

SLBバックエンドECSの数を増やすと、ECS構成が統合されます。
Nginxリバースジェネレーションバックエンドアップストリームの無効なポートの削除。
Cloud Assistantは、処理サービスをバッチ処理し、パラメーターを最適化し、インスタンスIDを追加します;（焦点を合わせるために、ECSをバッチで使用する場合は、Cloud Assistantの使用を検討できます）
クラウドモニタリングとマーケットモニタリング、ECS、SLB、DCDN、Redisなど。
SLBを7層監視モードに調整します。最初の7と最後の4のセッションを閉じると、ログインステータスが無効になります。
プログラムの最適化

GCログを追加し、GC分析の問題をキャプチャし、プロセスメモリを設定します。


/usr/bin/java -server -Xmx8g -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/xxxx.gc.log -Dserver.port=xxxx -jar /home/app/we.*****.com/serverboot-0.0.1-SNAPSHOT.jar

SMS送信ロジックを最適化し、ログイン時に最初にRedisの未登録セッションにクエリを実行してから、未登録セッションなしでSMS確認コードの送信を許可します（ショートメッセージの量を減らし、ログインエクスペリエンスを最適化します）。
jedis接続プールの最適化。


maxTotal 8-->20
acceptcount优化（对标somaxconn）

バグ：springboot1.5を使用したjedis2.9.1のRedis接続リークにより、Tomcat 800プロセスは、使い果たされた後、Redis接続を無期限に待機していました。その後、さらに調査したところ、この問題は2.10.2で修正されており、2.10.2は2.9.1と下位互換性があることがわかりました。
データベースの最適化
Redisパブリックネットワークアドレスが内部ネットワークアドレスに変更されます。
Redisセッションタイムアウト設定は、Redis接続を解放するために短縮されています。
SQLの最適化が遅い（RDSのCloudDBAは非常に使いやすい）。
読み取り専用インスタンス、自動読み取り/書き込み分離を追加します。
バックログを最適化します。
読み取り/書き込み分離インスタンスの数を追加します。
やっと

高並行性マスクスナップアッププロジェクトアーキテクチャの進化の記録と最適化の経験の共有

Linuxシステム診断のためのECS運用保守ガイド
この記事は「Linuxシステム診断のためのECS運用保守ガイド」から抜粋したものです。「Linuxシステム診断のためのECS運用保守ガイド」は牧原の骨の折れる作業です。内容が洗練されているだけでなく、しかし、コードの作成者も時間を費やしました。また、Alibaba Cloud Developer Communityに直接ログインして、「ECS操作および保守ガイド-Linuxシステム診断」という本をダウンロードするか、公式アカウントの舞台裏にあるキーワード「ecs」に直接返信して、このコレクションを入手することもできます。
Alibaba Cloud開発者コミュニティには、高品質の技術記事がたくさんあります。観察して学ぶことができます。多くの本は、無料で直接ダウンロードできます。

この記事の内容が刺激的でやりがいがあると思われる場合は、[私が見ている]をクリックするのを手伝ってください。または、転送して共有し、より多くの友達に見てもらいましょう。