最近、新しいコロナウイルスに感染した肺炎の流行の影響により、スパイクトラフィックが劇的に増加しています。
2月3日以降、Dingdingは絶えずトラフィックのピークを迎えています。1,000万を超える企業がDingdingを使用してオンラインで作業し、総数は2億を超えます。全国の20を超える省の200を超える教育局が「コースライブブロードキャスト」プログラムを開始しました、20,000を超える小中学校を含む1200万人以上の生徒が参加しています。
持続的なビジネスの成長により、ディンディングは多くの歴史的瞬間を生み出しました。2月5日、ディンディングはAppleの無料App Storeランキングのトップに躍り出て、これまでに占めています。
2月6日、DingdingはCCTVに出演し、Dingding CTOがインタビューされました
アウトブレイクトラフィックは、主にDingDingのリモートオフィスおよびオンライン教育機能から発生します。文字通り、DingDingのビジネス機能は2つしかないようですが、DingDing内には20以上の依存モジュールがあります。生放送/ホームスクール/健康パンチカードおよびその他のビジネスシナリオ。このような爆発的な成長の下で20を超える企業のパフォーマンスと安定性を確保する方法は、ディンディングのバックエンドシステムとデータベースシステムにとって大きな課題です。
この記事では、データベースDBAの視点からこの「戦い」に勝った方法、プロセスで発生した課題、チームの編成方法、考え方、テクノロジーを使用してこれらを克服する方法を紹介します挑戦し、そして最後にこの戦いを通して、私たちが蓄積した経験と技術。
1.データベースシステムへの挑戦
データベースは、Dingdingビジネスシステムの運用に強く依存しています。このシナリオでは、Double 11と同様に、データベースの計画と展開の方法が安定性の最も重要な部分になっていますが、この戦いが突然起こり、あまり多くありません。時間の準備のため、多くの困難と課題に直面しました要約すると、次の3つのポイントがあります。
1.システムに必要な容量はどれくらいか、例としてメッセージモジュールを予測することはできません。DingdingNewsの毎日のピークトラフィックは、Spring Festivalの前は1000万未満でした。最初の容量評価では、全員が2月3日の目標を設定しました。毎日のピークの3倍ですが、2月10日のピークの到来に伴い、2月10日の目標は10倍に調整され、その後2月17日の学期到来により再び40倍の目標に調整されます。 。したがって、総容量は1日のピークの40倍になります。
2.時間が限られ、容量の拡張に対する多くの要求があり、リソースが不足している流行トラフィックの急増により、システムは毎年ダブル11と同じくらいの影響を与えています。Eコマースでは、Double 11の準備に半年かかりますが、今回の残り時間は数時間でしか測定できません。一方、Dingdingはコストを考慮して、基本的にリソースプールにスペアマシンがなく、既存のリソース展開密度も比較的高くなっています。リソースを移動して、短期間に20コアクラスター近くのDingdingの容量を拡張する方法大きな問題です。
3.極端なシナリオでシステムの安定性とユーザーエクスペリエンスを保証する方法さまざまな要因がクラスターの拡張を制限し、システムがボトルネックに達した場合、どうすればよいですか？どのような緊急対策を使用できますか？ユーザーへの影響を最小限に抑えるためのバランスポイントはありますか？
2.対応策
ビジネストラフィックの突然の急増は、Dingdingチームの基盤となるデータベースシステムの包括的な検査でもあります。DTS、ミドルウェアシステム、データベースチーム、Dingdingビジネスチームは、基盤となる成熟した管理と制御に依存して、密接に連携して、専門的な機能と成熟した製品を通じて上記の課題を1つずつ解決します。
1.合理的な人員配置
1）流行時のデータベースチームの設立中、釘付けビジネスセキュリティチームのメンバーには、データベースチームDBA /データベースカーネル/ CORONA / TDDL / DTS / jingwei / NOSQL製品ラインの学生が含まれていました。
Dingdingの事業ラインによると、各DBAは事業ラインをフォローアップし、保護のピーク期間に参加し、オンラインシステムのステータスと水位を時間内にブロードキャストするため、保険会社の意思決定担当者はシステムのステータスを把握できます。オンラインで発生した問題を緊急に処理し、問題が短時間で確実に修復されるようにします。不合理なビジネスシナリオを最適化して、既知の問題が1回だけ発生するようにします。システムの圧力テストに参加し、時間内に修正する必要がある潜在的なリスクポイントを見つけ、不十分なシステム容量でシステムを拡張し、リソースがピークに達する前にデータベースに十分な容量を確保します。
2）データベースチームはDingding安定性チームと緊密に連携します。初期段階ではリソースが限られているため、拡張する必要のあるシステムがたくさんあります。各ビジネスラインの所有者は、自分のシステムが最も重要であると感じています。自分のデータベースを拡張することを優先し、一部の所有者でさえプルします。あなた自身のリーダー、またはリーダーのリーダーでさえも、拡大の需要を高めるためにDBAに来ました。
これは、僧侶が多すぎて肉が少ないため、空に戻れないため、DBAに大きなプレッシャーを与えており、DBAも多くの不満を抱えています。ビジネスの重要性に従ってデータベースの拡張ニーズに優先順位を付け、拡張ニーズを統一します。DBAは、優先順位とビジネスの目標容量に従って判断し、限られたリソースの下で体系的に拡張して、リソースがブレードで最初に使用されるようにします。 、拡張効率を大幅に改善します。
2.緊急時のリソース調整
急に流行が始まり、流量は増えると誰もが予想していましたが、どれだけ増えるのか誰にもわからず、早めに準備する必要がありました。リソースがシステム拡張の抵抗にならないようにするため。DBAとクラウドリソースチームは合理的な計画を立てました。短期的には、グループのクラウドマシンを借りて、同時に他のBUデータベースクラスターのサイズを削減することで、約400台のマシンを集めて、優先度の高いシステムの拡張を確保し、クラウドリソースの再配置を調整しました。ほんの数日で、300台を超えるマシンがネイルリソースプールに再配置され、すべてのネイルデータベースの拡張要件が確保されました。
リソースを配置したら、データベースの復元力を確認します。PolarDB-X3ノード分散デプロイメントアーキテクチャを利用して、元のクラスターをオンラインで簡単にアップグレードおよび拡張できます。これにより、ユーザーへの影響が少なく、一貫したデータを確保できます。セックス。一部のシナリオでは、ユーザーはデータを元のクラスターからより多くのサブデータベースとテーブルを含む新しいクラスターに移行する必要があります。成熟した管理および制御プラットフォームでDTSを使用してスムーズに完了することもできます。結局、リソースがある限り、データベースはビジネスニーズを満たすために非常に柔軟にすることもできます。
3.緊急事態と最適化
システムのピークが来る前に、データベースチームは緊急時の計画をすでに準備しています。パラメーターのダウングレード、データベースパラメーターの調整によるデータベース機能のフル活用、スループットの向上
リソースのダウングレード、リソース制限の調整、CPU分離の解放、およびデータベースのBPサイズの緊急増加
異常なSQLの場合、影響の確認後の緊急フロー制限、またはSQL実行計画プロファイルによる緊急介入
スタンバイデータベースの完全なクラスターフローが分散され、プレッシャーの状況に応じて最大読み取りトラフィックをスタンバイデータベースに切り替えることができます。
必要に応じてデータベースのスループットをさらに向上させるために、データベースの一貫性の弱いスクリプトを準備する
同時に、ビジネスの現在の制限/ダウングレード計画と組み合わせて、未知のピークトラフィックが到着したときに、多くのデータベースシステムの安定した運用を保証できます。
ただし、サービスの現在の制限により、多くのユーザーのエクスペリエンスが低下します。以前のサービスの現在の制限値は30QPM /グループに設定されていました。つまり、各グループは1分間に30のメッセージしか送信できず、多くの場合、1分の最初の20秒間にさらに多くのメッセージを送信できます。短時間で30個のメッセージが送信されました。残りの時間が40秒を超えると、ユーザーの経験上、釘は使用できません。この状況では、DBAは、現在の制限時間枠を減らし、現在の制限値30QPMを30 / 20Sに変更することをお勧めします。 97％削減され、ユーザーエクスペリエンスが大幅に向上しました。
（赤い曲線は流動限界です）
4. DB容量の見積もりとパフォーマンス分析
ビジネスでは、システムの水位レベルはクラスターのCPU状況によって大まかに分析できますが、DBでは、CPU、IO、ネットワーク、SQL、ロックなどだけでなく、コンポーネントのボトルネックが最終的な容量のボトルネックになることがよくあります。多くの場合、ビジネスモデルによってボトルネックが異なります。大規模なクエリであっても、一部はCPUボトルネックである可能性があり、一部はメモリヒット率が不十分であることが原因であり、一部は不当なインデックス設計が原因である可能性があります。より複雑な部分は、一部のボトルネックが線形でないことが多いことです。圧力を2倍に増加しても問題はなく、ハードウェア機能はまだ余剰ですが、3倍に増加すると、直接リンクされます。このシナリオでは、DBの容量をより正確に評価するにはどうすればよいですか？
これまでは、経験を基にビジネス側でフルリンクプレッシャーテストを実施し、DBの容量（クラスターがサポートできる読み取りと書き込みの数）を見積もりましたが、この方法には次の問題があります。
多くの場合、圧力テストデータセットはデータベース全体に比べて比較的小さく、DBヒット率は基本的に100％です。これは、IOを使用するビジネスモデルの分析にとって大きなエラーです
コストが高く、より多くの学生が参加して、上流と下流のリンク全体を接続する必要がある
フルリンクが圧力テストされている場合でも、DBエンドに実際に押し付けられているのは、多くの場合、コアインターフェースのほんの一部であり、回線上のすべてのインターフェースの100％をカバーすることはできません。多くの遅いSQLは、これらの簡単に無視されるインターフェースに起因します。
この問題点を解決する方法は、すべてのオンラインビジネストラフィックが一度収集されて再生される限り、実際には非常に簡単に考えることができますが、実装は非常に複雑です。私たちが本当に必要としているのは、DBのユニバーサルシングルリンク圧力測定機能です。これは、アップストリームサービスに依存しません。DBレイヤーは、トラフィックを生成、スケールアップまたはスケールダウンするだけでなく、トランザクション比率を変更した後で圧力を再度変更することもできます。 。
2019年から、DBAとDharma Instituteのデータベースサイエンティストの共同の取り組みにより、上記の要件を満たすClouDBenchを開発し、DBAがこの戦いの能力を評価するのを支援しました。
最初に効果を示します：
青は特定の瞬間における実際のビジネスのパフォーマンス曲線であり、緑はDBエンドトラフィックの再生から収集したパフォーマンス曲線です。2つの曲線は時系列に非常に適合していることがわかります。特に、InnoDB内のインジケーターは非常に近いです。トラフィックの変動。
ビジネスのワークロードをより現実的に再現できる場合、DBの容量を分析し、極端なシナリオでパフォーマンスのボトルネックを分析するというプレッシャーを増幅して、DBを最適化し、最適化の効果を検証できます。
ClouDBenchは、Grayscale Autonomous Service Database Autonomy Service（DAS）で利用できるようになりました。ClouDBenchの実装については、フォローアップ記事で詳しく紹介しますので、ご期待ください。
3.結果と考え方
2月17日の第3波のピーク時に、ディングディンのさまざまなシステムが着実に稼働していました。2月18日から、以前の完全保険から日常のメンテナンスに変更しました。すべてのシステムのデータベースがあるので、なぜこの確信があるのでしょうか。すべてが拡張および最適化されており、現在のシステム容量をはるかに超えることができます。
わずか2週間で、各データベースシステムの能力は数倍から40倍以上になり、その中には、1PBを超えるストレージスペースを持つ非常に大規模なデータベースクラスターが数多くあります。これらすべては、Alibaba Cloudデータベースの復元力を完全に証明します。制御/ DTS / CORONAなどのさまざまな製品の完璧な連携により、Alibaba Cloudデータベースは、洪水のピークフローの前では無敵です。
今回の流行により発生したアウトブレイクトラフィックは未対応ですが、今回のキャンペーンで多くのことを学びましたが、今後このような問題が発生した場合でも対応可能です。経験は次のポイントを要約します：
1.人事組織：
まず第一に、人事組織では、ビジネスと開発は突然のトラフィック、タイムリーな発見と早期準備の鋭敏な感覚を備えている必要があり、ビジネスパーティの安定の責任者は緊急チームを設置して、依存するビジネスと対応するバックエンドシステムを整理し、各ビジネスラインの所有者とバックエンドシステムを接続する必要があります。データベース製品の所有者は緊急チームに含まれています。緊急チームは、キャパシティプランニング、人材の割り当て、リソースの調整を統合して、ビジネスパーティー/バックエンド製品チーム/リソースチーム間の連携を実現します。
2.技術アーキテクチャ：
一方、技術アーキテクチャに関しては、十分な柔軟性のあるデータベース製品を使用して、使用するデータベース製品が自由に拡張および収縮できるようにする必要があります。また、トラフィックが来た後に拡張できるようにするだけでなく、毎日のトラフィックを確実に減らすこともできます。ダウン。管理や制御などの各運用および保守コンポーネントは、自動運用および保守を実装する必要がありますが、いくつかの極端なシナリオでは、自動運転から手動モードに切り替えてタスクが円滑かつ効率的に実行されるようにするために、緊急スイッチを多くの主要な操作に残します。 。
3.緊急措置：
システムのボトルネックに直面した場合、ビジネス製品とデータベース製品を事前に準備する必要があり、ビジネスにはダウングレード機能と現在の制限機能が必要です。システムがプレッシャーに耐えられない場合、一部の非コア機能をダウングレードして、場合によっては制限することができます。コアビジネスの正常な運用を保証するコア機能。データベース製品は、容量を拡張することなく、いくつかの最適化方法によってデータベースのスループットを即座に向上させる機能を備えている必要があります。さらに重要なことに、これらの機能は、さまざまなデプロイメント環境やさまざまなDBアーキテクチャーで優れた互換性を備えている必要があります。対応するツールと計画があります。
一方、計画の効果を評価および検出する手段が必要です。これで、ClouDBenchを使用してDBの容量を分析および予測できますが、現在の使用コストはまだ高すぎます。フォローアップClouDBenchは、より自動化し、使用コストを削減し、容量を減らす必要がありますこれはビジネスオーナーに透過的に送信されます。大きなプロモーションの前に、システムの水位の評価、パフォーマンスのボトルネックの発見、DBパラメータの最適化、計画の効果の検証のために、多数のDBシングルリンク圧力テストが自動的に実行されます。
最後に、Alibaba CloudデータベースのサポートでNail Sanduoを祝福し、より高く、より遠くまで飛ぶことができます！
クラウドについては、Yunqiを参照してください：クラウド情報、クラウドケース、ベストプラクティス、製品紹介、https：//yqh.aliyun.com/
この記事はAlibaba Cloudのオリジナルコンテンツであり、許可なく複製することはできません。
