稼働時間が長いサービスは、再起動せずにパッチをどのように適用しますか？
再起動することはできませんが、更新には再起動が必要な重要なセキュリティ更新プログラムがシステムにどのようにインストールされますか？たとえば、ダウンタイムなしで24時間365日稼働する必要があるサービス/ビジネス。 Amazon.comまたはGoogle。
実行中のコードのホットパッチを可能にするさまざまなオペレーティングシステムのさまざまなユーティリティがあります。この例としては、Linuxの kpatch および livepatch の機能があり、動作を中断せずに実行中のカーネルにパッチを適用できます。その機能は制限されており、カーネルに些細な変更を加えることしかできませんが、適切な修正を行う時間が見つかるまで、多くの重要なセキュリティ問題を軽減するにはこれで十分なことがよくあります。この種の手法は、一般に 動的ソフトウェア更新 と呼ばれます。
ただし、ダウンタイムが実質的にないサイト（ high-availability ）は、ライブパッチのためにそれほど冗長ではないが、冗長性があるため、指摘する必要があります。 1つのシステムがダウンしたときはいつでも、トラフィックのルーティングまたは要求の処理を遅延なく即座に開始できるいくつかのバックアップがあります。これを達成するための多数の異なる手法があります。冗長性のレベルは、 nines で測定される大幅なアップタイムを提供します。スリーナインの稼働時間は99.9％です。フォーナインの稼働時間は99.99％などです。「聖杯」はファイブナイン、つまり99.999％の稼働時間です。あなたが挙げたサービスの多くは、世界中に広がっている冗長なバックアップシステムのため、5つの9の可用性があります。
Netflixの従業員によるセキュリティ会議でのプレゼンテーションを見ました。パッチはまったく適用されません。代わりに、パッチが必要な場合、新しいインスタンスを立ち上げ、パッチされていないインスタンスを吹き飛ばします。彼らはこれをほぼ絶えず行っています。彼らはそれを red-blackデプロイメント と呼んでいます。
短い答えは：
再起動します
AmazonとGoogleが単一のサーバーで実行されていると想定しているようですが、それが再起動されると、サイト/サービス全体がダウンします。これは真実からはほど遠いです-大規模なサービスは通常、並行して動作する多くのサーバーで実行されます。詳細については、 クラスタリング 、 ロードバランシング 、および フェイルオーバー などのテクニックを参照してください。
たとえば、Googleには 世界中の12を超えるデータセンター があり、それぞれが膨大な数のサーバーを保持しています（推定値は センターあたり100,000〜400,000サーバー ）。
このような環境では、更新（機能とセキュリティの更新の両方）は通常 ローリングデプロイメント としてインストールされます。
- サーバーのサブセットを選択する
- サブセットにアップデートをインストールする
- サブセットを再起動します。その間、他のサーバーが引き継ぎます
- 次のサブセットで繰り返します:-)
他にもホットパッチなどのオプションがありますが、私の経験ではそれほど頻繁に使用されていません。少なくとも、典型的な大規模なWebサイトでは使用されていません。詳細は森の答えを見てください。
「ソフトウェアの展開」で「 展開アクティビティ 」を確認できます。一般的な方法は、サービスの前でロードバランサーを使用し、それに応じてトラフィックをリダイレクトすることです。 「ブルーグリーン展開」と呼ばれる手法では、トラフィックを「ブルー」から「グリーン」サーバーにリダイレクトします。もちろん、アプリケーションがこれを適切に処理できる場合、ユーザー側のダウンタイムはありません。ステートレスサービスを通じて。
アプリケーションが青いサーバーでv1を実行し、ロードバランサーがそこにトラフィックを送信するとします。グリーンサーバー（トラフィックを受信しない）をv2にアップグレードできます。次に、ロードバランサーを再構成して、トラフィックをグリーンサーバーに転送します。したがって、ダウンタイムなしでv1からv2にアップグレードしました。
青緑色の手法は、テストの一部としても使用できます。たとえば、トラフィックの95％を青色のサーバー（v1）に、5％を緑色のサーバー（v2）に転送するようにロードバランサーを構成します。このようにして、トラフィックが少なく、バグがある場合にユーザーに与える影響を少なくして、新しいバージョンをテストできます。
物事がクラスター化され、プロキシ化されている場合は、非常に簡単です。同じジョブを実行できるノードが多数あるため（または、検索エンジン、Hadoopファイルシステムなどのデータリポジトリの場合はseveral）
ウェブ検索をしてください。 www.altavista.comにアクセスします。 DNSエントリには6ダースのIPアドレスがリストされ、クライアントはランダムに1つをヒットします。各IPはCiscoルーターであり、内部IPアドレスで8つの物理フロントエンドサーバー（合計48）のランダムな1つにトラフィックを送っています。そのサーバーはクエリを正規化し（空白を削除するなど）、MD5ハッシュを取得します。 MD5は、300 プロキシサーバーのどのクエリに移動するかを決定します。そのクエリは、SOAPなどの標準プロトコルを介してproxyに送信されます。
フロントエンドサーバーは、単一のクエリの一時的な要求のみを処理するため、交換可能です。最悪の場合を除き、顧客はクエリを削除します。フロントエンドサーバーで障害が発生し始めたときにRRDデータまたは他のデータ収集を使用してウォッチドッグし、そのトラフィックをスタンバイサーバーに再ルーティングします。シスコのルータについても同じことが言えます。
プロキシは最初にcacheをチェックします。キャッシュヒットの場合、ローカリゼーションブレンディングが行われ、回答が返されます。完了しました。 「キャッシュミス」の場合、プロキシはクエリを検索クラスタにファンアウトします。
プロキシがダウンした場合は、別の物理マシンをそのプロキシに交換できます。プロキシは互換性がないため、これはもう少し重要です。それぞれが検索結果スペクトルの小さなスライスを「所有」します。したがって、0x0000-0x00d9マシンがダウンした場合、代理人はその範囲に介入する必要があります。さらに悪いことに、その代替マシンには空のキャッシュがあるため、検索クエリはすべてキャッシュミスになります。これにより、検索クラスタの負荷がproper少し増加しますダウンしたプロキシごと。つまり、すべてのプロキシを同時にバウンスした場合、ピークの検索時間中には行わない！
もちろん、検索クラスターは同様の階層化と冗長性を備えており、検索データベースの各セグメントは複数のノードに存在するため、ノードがダウンした場合、他のノードがその結果のスライスを提供できます。
例としてプロキシに焦点を当てています。そこへの通信はSOAPを介して行われ、外部への通信は同様の高レベルのプロトコルを介して行われます。検索エンジンのクラスター負荷のバランスをとるために重要なキャッシュを除いて、データの入出力は一時的です。重要なのは、いつでも瞬時に入れ替えることができ、最悪の場合、数回の検索がタイムアウトになることです。これはフロントエンドサーバーが気づくものであり、クエリを再度送信するだけで、その時点で新しいプロキシが起動します。
したがって、300個のプロキシがあり、プロキシがキャッシュを回復するのに1時間半かかり、検索エンジンの負荷が20％増加することを許容できる場合は、30秒ごとに1つのプロキシを交換できるため、スライド30分の期間、60個のプロキシ（20％）がキャッシュを再構築しています。急いで行く必要さえあると仮定すると、それ高速です。
この例のロールアウトには2時間半かかりますが、緊急の脅威がより迅速な対応を必要とする場合は、キャッシュミスが増えるという苦痛に耐えるか、パッチを適用するのに十分な時間サービスを停止します（ただし、検索エンジンの例ではキャッシュミスは、戻ってきたときも問題になります。緊急DBのリロードと必要なキャッシュフラッシュの後のRRDグラフを見ました。
もちろん、通常、プロセスは完全に再起動せずにパッチを適用し、停止して再起動できます。本番ノードで2年間の稼働時間を確認しました。