従業員の3分の2がクビになってもTwitterのシステムが停止せず動き続けた理由を元Twitterエンジニアが語る
イーロン・マスク氏がTwitterを買収してわずか3週間で従業員が7500人から2700人にまで激減したと報じられています。通常、従業員の3分の2が辞めてしまうと会社の運用に支障をきたし、Twitterのシステム維持にも大きな影響を与えてしまいそうなものですが、Twitterは記事作成時点でも問題なく稼働を続けています。大規模な人員削減があってもTwitterというシステムが維持されていた仕組みについて、Twitterのサイト信頼性エンジニア(SRE)を5年間務めていたマシュー・テージョ氏が語っています。
Why Twitter Didn't Go Down: From a Real Twitter SRE
https://matthewtejo.substack.com/p/why-twitter-didnt-go-down-from-a
テージョ氏は5年間にわたってTwitterのサイト信頼性エンジニアを務めており、そのうちの4年間はキャッシュ担当チームで唯一のサイト信頼性エンジニアでした。テージョ氏がチームに参加した時の最初のプロジェクトは、キャッシュサーバー用のマシンを新しいものに入れ替えることだったとのこと。テージョ氏が参加した当時はツールも自動化されておらず、サーバー名が書かれたスプレッドシートを手渡されて、すべて手作業で管理と運営を行っていたそうです。
キャッシュ担当チームで自動化・信頼性・運用に関する責任者という地位に就いたというテージョ氏は、「私はTwitterのキャッシュ周りを自動化するツールのほとんどを設計および実装したので、これについて話す資格があると思います。他にこのシステムを語れるのは1～2人しかいないかもしれません」と述べています。
インターネットコンテンツを配信する上で重要なのがキャッシュです。ウェブコンテンツをそのままメインサーバーからダウンロードさせるのではなく、コンテンツのコピーを取得したキャッシュサーバーからダウンロードさせることで、メインサーバーへの負荷を分散することができます。Twitterの場合、ツイートやタイムライン、ダイレクトメッセージ、広告、認証などがキャッシュサーバーから配信されていました。
テージョ氏によれば、TwitterのキャッシュはMesos上でApache Auroraのジョブとして実行されているとのこと。Auroraはアプリケーションを動作させるサーバーを見つけ、Mesosがすべてのサーバーを集約し、Auroraがそれらについて検知できるようにします。Auroraはアプリケーションの起動後も実行を続け、キャッシュクラスタの維持に必要なサーバーの稼働を維持します。
たとえば100台のサーバーで構成されているキャッシュクラスタで、1つのサーバーが何らかの理由で壊れた場合、Mesosが故障したサーバーを検出し、集約したサーバー群から削除します。そして、Auroraが実行中のキャッシュサーバーが99台しかないことを検知し、新しいサーバーを自動的に検索し、実行中のキャッシュサーバー台数を100台に戻します。一連の動作に人間による手作業が関わる余地はありません。
データセンターにおいて、サーバーは「ラック」と呼ばれる台に格納されており、さらにスイッチという装置で他のラック上のサーバーと接続され、ルーターを経由して最終的にはインターネットにつながるという複雑な構造になっています。1つのラックには、20台から30台のサーバーが搭載されており、ラックが故障したり、スイッチが壊れたり、電源が落ちたりすると、20台のサーバーがすべてダウンしてしまいます。
テージョ氏によれば、AuroraとMesosを使うもう一つのメリットは、1つのラックにあまり多くのアプリケーションを載せないようにできること。これによって、ラック全体を安全かつ突然ダウンさせることができ、AuroraとMesosがそれまで実行されていたアプリケーションのホームとなる新しいサーバーを用意することができます。
テージョ氏は就任時にもらったスプレッドシートを基に、すべてのサーバーを追跡するツールを作成し、ラック上の物理サーバーの数を増やしすぎず、かつ障害が発生しても問題が起きないようにすべてが分散されるように設計しているそうです。ただし、Mesosはすべてのサーバーの障害を検出できるわけではなく、ハードウェアの監視については別途行っているとのこと。そのため、ディスクの不良やメモリの不具合を検知した場合、アラートのダッシュボード上でデータセンター担当者に修理タスクが割り振られます。
さらにキャッシュ担当チームは、キャッシュクラスタの稼働時間をソフトウェアで追跡しています。短期間にダウンしたと見なされるサーバーが多すぎると、キャッシュの削除を必要とする新しいタスクは、安全が確認されるまで拒否されます。これにより、キャッシュクラスタ全体を誤って停止し、それらによって保護されているサービスに負担がかかることを回避できます。
また、数が多すぎてすぐにダウンしなかったり、一度に修理するには数が多すぎたり、Auroraが古いジョブを配置するための新しいサーバーを見つけられなかったりするという事態も想定しているとのこと。故障が検出されたサーバーの修理タスクを作成するには、まずそのサーバーのジョブを削除しても安全かどうかを確認し、ジョブが空になったら「データセンターの技術者が作業しても安全である」とマークします。データセンターの技術者がサーバーを「修理済み」とマークすると、修理済みのサーバーを検索してジョブを実行できるように自動的にアクティブ化するツールが実行されます。要するに、一連の修理タスクで人間の作業が必要なのは、「サーバーの物理的な修理」だけとなっているそうです。
テージョ氏によると、新しいキャッシュサーバーが追加されないバグや、サーバーの追加に最大10分かかってしまうバグもあったそうですが、自動化作業を進めたおかげでプロジェクトを軌道に乗せながら少しずつ修正することができたそうです。
一連のキャッシュサーバーの維持を自動化するシステムは、Twitterというサービスがダウンしてこなかった理由にもつながるそうです。テージョ氏によれば、Twitterには2つのデータセンターがあり、そこでTwitter全体の障害を処理することができるとのこと。基本的にTwitterで実行されるすべての重要なサービスは2つのうち1つのデータセンターで実行できるそうです。1つのデータセンターで利用できる容量は、災害発生時に対応する目的で、通常のサービス実行時の2倍が用意されていたとのこと。要するに、通常時はデータセンターの利用率が最大でも50％にとどまるというわけです。
ただし、利用率50％でもかなり忙しいそうで、必要な容量を計算するときは、1つのデータセンターですべてのトラフィックを処理するために必要な容量を計算し、その上にヘッドルームを追加するのが通常だったとのこと。テージョ氏によると、データセンター全体で障害が発生することは非常にまれで、テージョ氏が働いていた5年間で1度しか発生していないそうです。
また、マルチテナントクラスタで全ての処理を行うのではなく、キャッシュクラスタをアプリケーションレベルで分け、複数に分散させていたそうです。こうすることで、1つのクラスタに問題が発生しても、そのクラスタに含まれるサーバーにしか影響が及ばないようになります。また、キャッシュを分散させておくことで、Auroraの監視を行き届かせる設計意図もあったとのこと。
テージョ氏は「自動化に自動化を重ね、パフォーマンスに関する問題に取り組み、よりよくするための技術もテストし、大規模なコスト削減プロジェクトも推進しました。キャパシティ・プランニングを行ったり、サーバーを何台発注すべきかを決定したりとかなり忙しかったです。一日中ゲームやマリファナをやりながら給料をもらっていたわけではありません」とコメント。
また、テージョ氏は「Twitterのリクエストを処理しているキャッシュはこのようにして稼働し続けています。これは日常業務の一部に過ぎません。ここに至るまでには何年にもわたって大変な努力が必要でした。一歩引いてもなおTwitterのキャッシュシステムがまだ実際に機能していることに感謝しています」と語り、最後に「ただし、機能しているのは少なくとも今のところだけです。私はどこかにバグが潜んでいると確信しています……」という言葉を残しています。
0 件のコメント:
コメントを投稿