23,000人が2017年4月8日にオンラインの口述を書きました。これはどのように起こりましたか?

今年、世界の858都市から20万人が教育キャンペーン「Total Dictation」に参加しました。 ディクテーションは、主にオフラインサイトで7年間書かれていますが、オンラインでこれを行う機会は2014年からです。 このサイトでの過酷な負荷のすべての悲しみを経験したことから、今年、アクションの主催者はIT企業のチーム全体を引き付けました。 今日は、私たちの仕事の一部についてお話します。



画像

写真:ヴァレリー・メルニコフ、RIA Novosti



Total Dictation Foundationは2月にアクションのプロモーションを開始しました。その後、オンライントレーニングセッションが開始され、最初のメディア出版物が公開されました。 各レッスンは平均13,990人が視聴しました。もちろん、口述の当日には、サイトにさらに大きな負荷がかかると想定されていました。 昨年、口述の際に、DDoS攻撃がサーバーを攻撃しました。そのため、しばらくの間サイトを利用できませんでした。 以下は、サイトのパフォーマンスを担当していました。





ロードのサイト準備



作業を開始する前に、プロジェクトは、2つのCPUコア、4 GBのRAM、HDDという特徴を持つ単純な仮想サーバーに配置されました。



当初、プロジェクトチームは、プロモーション当日に120 RPSがサーバーに到着し、毎分1000人の訪問者がサイトを訪問することを提案しました。 RPSサーバーが現在処理できる量と、ピーク負荷に必要なサーバー構成を調べるために、Yandex.Tankサーバー負荷テストが実行されました。 メインサーバーとバックアップサーバーの最終構成は、48 CPUコア、128 GBのRAM、250 GB SSDのように見えました。



プロジェクトのピーク負荷に備えて、設定とコードの両方の面で必要な最適化をすべて実行できるように、サイトで仮想サーバーをアップグレードしました。



負荷テストと並行して、アンチドスプロバイダーをサイトに接続するプロセスが進行中です。 彼は次のように見えた:



  1. サイトのすべてのAレコードは、IPの反行為に切り替えられました。
  2. プロジェクトの実際のIPが送信メールヘッダーに表示されないように、メールサーバーの設定が変更されました。
  3. 反DoS側では、サイトに着信するすべての要求のフィルタリングと、その後のプロジェクトサーバーへのプロキシが構成されました。


最初は、新しいサーバーを分割し、プライマリが落ちた場合に備えて、一方のサーバーをプライマリ、もう一方をバックアップとして作成することが計画されていました。 しかし、全体的なシステム容量を増やすための負荷テスト中に、バックアップサーバーを使用してバックエンド要求(この場合はphp-fpm)を処理することが決定されました。 プライマリサーバーとバックアップサーバー間のバックエンド要求は、プライマリサーバーでnginxを使用して分散されました。 MySQLは一般的なセッションストレージとして構成されました-「1C-Bitrix」を使用すると、サーバー設定を変更せずにこれを実行できます。



口述の日の1週間半前に、プロジェクトは新しいサーバーに切り替えられました。 これを行うために、彼らはまずすべてのソフトウェア設定、サイトファイル、データベースを含む古いサーバーの完全なコピーを作成しました。 切り替えプロセス自体は次のようになりました。



  1. 古いサーバーから新しいサーバーへのプロジェクトファイルのデータベースレプリケーションと同期を設定します。
  2. 切り替え時には、nginxを使用して、古いサーバーから新しいサーバーへのすべてのリクエストのプロキシが有効化されていました。
  3. データベース複製を無効にしました。


アンチDoSプロバイダー側​​では、すべてのトラフィックが新しいサーバーに到着するように、ターゲットサーバーのアドレスが変更されています。



サイトの移転後、最終的な負荷テストが実行されました-500 RPSの負荷がエミュレートされました。 主催者は、彼らが思っていたよりも多くの訪問者がいるだろうと提案した。 テストの結果、セッションの保存にMySQLを使用しているため、ディスクの負荷が非常に大きく、ピーク時に問題が発生する可能性があることがわかりました。 そのため、memcacheのストレージ用にセッションを再構成することが決定されました。この後の負荷テストでは、現在のハードウェアに予想される負荷で「ボトルネック」が発生しないことが示されました。



アクションの日にロードする



一般に、複数の独立した当事者が関与するプロジェクトは、常に挑戦であり、常にリスクです。 したがって、開始前に、すべての準備作業、ストレステスト、コード監査などにもかかわらず、まだ緊張と不安が残っていました。



画像



ディクテーションは、2017年4月8日、ウラジオストク(GMT +10)の15:00に開始されました。 最初は、負荷は最小限でした-ダイナミクスの1秒あたり約20リクエスト。 しかし、もちろん、リラックスする価値はありませんでした。 モスクワ時間の14:00に行われた最大のブロードキャストでは、Memcacheのキャッシュ用により多くのメモリを割り当て、そこで同じセッションを取り出して、ディスクの負荷を減らしました。 放送は問題を修正することなく行われ、負荷は制御可能で、すべてが迅速に、正しく機能しました。



画像



これは、その日のロード画像の様子です(イルクーツクチャートの時間、GMT +8)。



全体の結果



みんな頑張った! Total Dictationから同僚に負荷の監視に関するデータを送信して、来年の計画を立てました。



画像



4月8日、9万人の観客がインターネットでアクションを見ました。23,000人がオンラインで口述を書きました。 4月9日から4月18日までに、サイトには454798のユニークユーザーがアクセスし、400万ページを閲覧しました。参加者は評価を見つけ、エラーの分析とともにウェビナーを視聴しました。 主催者は、2018年4月14日に口述の準備を既に開始しています-自分自身も引き上げます(オンラインコースでロシア語の規則を繰り返します)、すべての口述!



PS 10月13日、モスクワのITインフラストラクチャの事故に関する無料のUptime Day会議を開催しています 。詳細は昨日の投稿サイトでの登録にあります



All Articles