Googleは、COVID-19の大流行により、より多くの人々がMeetを使用するようになったため、使用量の増加によるGoogle Meetのスケーリングの課題について書いた。GoogleのSREチームは、今年初めに始まったトラフィック増加の課題に取り組むために、既存のインシデント管理フレームワークを変更して使用した。
SREチームは、2月17日頃にGoogle Meetのリージョナルキャパシティで早期の警告を受け取った、しかし、この頃はユーザへの継続的な停止や影響はまだなかった。目標は、機能停止を防ぎ、まだ未知の拡張要求に応じてスケールすることだった。チームの対応戦略は、通常のインシデント管理フレームワークを使用することで、これは「従来の」インシデントのパラメーターに適合していなかった。北米とヨーロッパの両方で、インシデントコマンダ、コミュニケーションリード、オペレーションリードなどの特別の役割を設定した。チームは作業を合理化するために「ワークストリーム」を設定した。各ワークストリームは、容量、依存関係 (Meetが依存する認証サービスなど)、ボトルネック、コントロールノブ、および新しいチューニングパラメータを使用したプロダクションロールアウトの特定の側面を扱った。彼らは、過負荷と燃え尽きを回避するために、インシデント対応で各人に「スタンバイ」を追加した。
Googleのサイト信頼性エンジニアスタッフであるSamantha Schaevitz氏は、インシデントコマンダの1人だった。彼女の役割は、「どの戦術問題が残っているか、誰が何に取り組んでいるのか、そして私たちの対応に影響を与えたコンテキスト (政府のCOVID-19対応など) に関するステータス情報を収集し、支援できる人々に仕事をディスパッチする」ことであった。チームの技術的な目標は、「地域で利用可能なMeetサービスの容量をユーザの需要よりも先回りする」ことだった。
チームはMeetのサービス容量を2倍にすることができ、プロビジョニング容量の決定は、履歴トレンドを使用することから、使用量を予測するための新しいモデルに移行する必要があった。第2フェーズでは、50倍の増加に向けて取り組んだ。プロセスの自動化に着実に注力し、新しいプロセスを含め、チームは手動操作を減らし、変更をより迅速に展開できた。それぞれのロールアウトはカナリアデプロイメントを通じて行った。
この問題対応の興味深い観察では、プロセスにより多くのリソース (CPUおよびRAM) を割り当てることは、プロセス全体に分散した同じリソースよりも効率的であるということだった。これは、各プロセス (監視、ヘルスチェック、初期化) に不可避のオーバーヘッドを少ないプロセス数で最小限にできるという事実によるものだ。チームがこの「インシデント」をクローズするまでに、Meetには毎日1億人近くの参加者がいた。
他の会議プラットフォームも同じ時期に同様の成長を遂げている。たとえば、CiscoのWebexは、全世界で通常の3倍のボリュームを記録しており、特定の地域ではより多くの増加が見られた。「5億人以上の会議参加者があり、4月には250億以上の会議議事録を記録しました」。彼らは、増加した負荷の処理の一環として、分析機能とセキュリティ機能により重点を置いていた。同様に、Zoomでは、4月の毎日の会議参加者が50％増加した。Zoomには17のデータセンタがあり、AWS、Oracle Cloud、Azureも使用している。増加する需要に対応するために、AWSに「5000〜6000のサーバ」を毎晩追加した。
4月に毎日2億人の会議参加者がいたMicrosoft Teamsは、全てAzureで実行される。Googleで起こったことと同様に、Microsoft Teamsのチームは、トラフィックの急増により「以前の予測モデルはすぐに時代遅れになっている」ことに気付いた。彼らのブログ投稿によると、彼らは予測モデリング手法を使用し、行き過ぎることなくリソースの決定をスピードアップした。その他の対策として、重要なサービスをより多くの地域に展開し、コードを最適化し、ネットワークトラフィックのルーティングを改善し、より強力なデータ圧縮を行った。彼らは、燃え尽き症候群を回避するために、内部のインシデント管理プロセスにもいくつかの変更を加えた。