ラウンドロビンDNSは静的コンテンツの負荷分散に「十分」ですか？

http://sstatic.netの Webサイト間で提供する一連の共有静的コンテンツがあります。残念ながら、このコンテンツは現在、まったく負荷分散されていません。単一のサーバーから提供されています。そのサーバーに問題がある場合、共有リソースは不可欠な共有javascriptライブラリおよびイメージであるため、それに依存するすべてのサイトは事実上ダウンしています。

単一サーバーの依存関係を回避するために、このサーバー上の静的コンテンツの負荷を分散する方法を検討しています。

ラウンドロビンDNSはせいぜいローエンド（一部はゲットーとさえ言うかもしれません）ソリューションであることに気付きますが、私は疑問に思わずにはいられません- ラウンドロビンDNSは静的コンテンツの基本的な負荷分散のための「十分な」ソリューションです？

これについては[dns] [load-balancing]タグで議論されており、このトピックに関するすばらしい投稿をいくつか読んでいます。

複数のラウンドロビンAレコードによるDNSロードバランシングの一般的なマイナス面を認識しています。

• 通常、DNSレコードを使用したハートビートや障害検出は行われないため、ローテーション内の特定のサーバーがダウンした場合、そのAレコードをDNSエントリから手動で削除する必要があります
• DNSエントリはインターネット全体に積極的にキャッシュされるため、これが機能するには、生存時間（TTL）を必ずかなり低く設定する必要があります。
• クライアントコンピューターは、複数のAレコードがあることを確認し、正しいレコードを選択する責任があります。

しかし、ラウンドロビンDNSはスターターとして十分に優れており、静的コンテンツの負荷分散の "より良い代替案を調査および実装している間"の形で、何よりも優れていますか？または、DNSラウンドロビンはどのような状況でもほとんど価値がありませんか？

ジェフ、私は同意しませんが、負荷分散は冗長性を意味するものではなく、実際はまったく逆です。サーバーが多いほど、特定の瞬間に障害が発生する可能性が高くなります。そのため、負荷分散を行う際に冗長性が必須ですが、残念ながら、ヘルスチェックを実行せずに負荷分散のみを提供するソリューションが多くあり、その結果、サービスの信頼性が低下します。

DNSラウンドロビンは、負荷を複数のポイントに分散することにより（潜在的に地理的に分散される）、容量を増やすのに優れています。ただし、フェイルオーバーは提供しません。まず、カバーしようとしている障害の種類を説明する必要があります。サーバー障害は、標準のIPアドレス引き継ぎメカニズム（VRRP、CARPなど）を使用してローカルでカバーする必要があります。スイッチの障害は、サーバー上の2つのスイッチへの復元力のあるリンクによってカバーされます。WANリンク障害は、ルーティングプロトコルまたはレイヤー2ソリューション（例：マルチリンクPPP）を使用して、ユーザーとプロバイダー間のマルチリンクセットアップでカバーできます。サイトの障害はBGPでカバーする必要があります。IPアドレスは複数のサイトに複製され、利用可能な場合にのみネットに通知します。

あなたの質問から、サーバーのフェールオーバーソリューションを提供するだけでよいようです。これは、ハードウェアやISPとの契約がないため、最も簡単なソリューションです。そのためには、サーバー上で適切なソフトウェアをセットアップする必要があります。これは、はるかに安価で信頼性の高いソリューションです。

「haproxyマシンに障害が発生した場合はどうなりますか？」それは同じだ。負荷分散と高可用性のためにhaproxyを使用する私が知っているすべての人々は2台のマシンを持ち、ucarp、keepalived、またはheartbeatのいずれかを実行して、そのうちの1つが常に利用できるようにします。

これが役立つことを願っています！

負荷分散として、それはゲットーですが、多かれ少なかれ効果的です。負荷から落ちているサーバーが1つあり、それを複数のサーバーに分散したい場合は、少なくとも一時的にこれを行うのが妥当な理由かもしれません。

ラウンドロビンDNSには、負荷の「バランス」として多くの有効な批判がありますが、短期的なバンドエイド以外の目的で行うことはお勧めしません。

しかし、主な動機は単一サーバーの依存関係を回避することであると言います。停止したサーバーをローテーションから自動で削除する方法がなければ、ダウンタイムを防ぐ方法としてはあまり価値がありません。（ローテーションと短いTTLからサーバーを引き出す自動化された方法で、それはゲットーフェールオーバーになります。手動では、それさえありません。）

2つのラウンドロビンサーバーの1つがダウンした場合、顧客の50％が失敗します。これは、サーバーが1つだけの場合の100％の障害よりも優れていますが、実際のフェールオーバーを実行した他のほとんどのソリューションはこれよりも優れています。

1つのサーバーで障害が発生する確率がNの場合、2つのサーバーでは、確率は2Nです。自動化された高速フェールオーバーがない場合、このスキームにより、一部のユーザーに障害が発生する可能性が高くなります。

手動回転のうち、死者のサーバーを取るために計画している場合、あなたはそれを行うことができる速度によって制限されていると、 DNS TTL。サーバーが午前4時に停止した場合はどうなりますか？真のフェイルオーバーの最大の部分は、一晩中スリープ状態になることです。 すでにHAProxyを使用しているので、それに精通している必要があります。HAProxyはまさにこの状況に合わせて設計されているため、使用することを強くお勧めします。

ラウンドロビンDNSは、人々が考えるものではありません。DNSサーバーソフトウェア（つまり、BIND）の作成者として、ラウンドロビンが計画どおりに機能しなくなった理由をユーザーに考えさせます。TTLが0秒であっても、一部のキャッシュは最小限の時間（多くの場合30〜300秒）を置くため、そこにある程度のキャッシュがあることを理解していません。

また、AUTHサーバーはラウンドロビンを実行する場合がありますが、重要なもの（ユーザーが話すキャッシュ）が保証するわけではありません。要するに、ラウンドロビンはクライアントの観点からの順序を保証するものではなく、認証サーバーがキャッシュに提供するもののみを保証します。

実際のフェイルオーバーが必要な場合、DNSは1つのステップにすぎません。2つの異なるクラスターに複数のIPアドレスをリストすることは悪い考えではありませんが、実際の負荷分散を行うには、そこで他のテクノロジー（単純なエニーキャストなど）を使用します。私は個人的に、通常DNSを不正に使用するハードウェアロードバランシングハードウェアを軽spしています。また、DNSSECが来ることを忘れないでください。したがって、この領域で何かを選択した場合は、ゾーンに署名するとどうなるかをベンダーに問い合わせてください。

何度か言ったことがありますが、もう一度言います。回復力が問題であれば、DNSトリックは答えではありません。

最高のHAシステムにより、クライアントはすべてのリクエストに対してまったく同じIPアドレスを使用し続けることができます。これは、クライアントが障害に気付かないようにする唯一の方法です。

したがって、基本的なルールは、真の回復にはIP ルーティングレベルのトリックが必要であるということです。ロードバランサアプライアンス、またはOSPF「等コストマルチパス」、またはVRRPを使用します。

一方、DNSはアドレス指定技術です。ある名前空間から別の名前空間にマッピングするためだけに存在します。そのマッピングへの非常に短期間の動的変更を許可するように設計されていなかったため、そのような変更を行おうとすると、多くのクライアントが気づかないか、せいぜい気づくまでに長い時間がかかります。

また、負荷は問題にならないため、ホットスタンバイとして実行する別のサーバーを用意することもできます。ダムラウンドロビンを使用する場合は、何かが壊れたときにDNSレコードを事前に変更する必要があるため、DNSを変更せずに、ホットスタンバイサーバーを積極的にアクティブに切り替えることができます。

すべての回答を読みましたが、サーバーが応答しない場合、最新のWebブラウザーのほとんどが代替IPアドレスのいずれかを試行することを確認しませんでした。記憶が正しければ、Chromeは複数のIPアドレスを試し、最初に応答したサーバーで続行します。したがって、私の意見では、DNSラウンドロビンの負荷分散は、常に何よりも優れています。

ところで：DNSラウンドロビンは、単純な負荷分散ソリューションと考えています。

私はこのスレッドに遅刻しているので、おそらく私の答えは下に一人でホバリングし、無視されて、においを嗅ぎます。

まず、質問に対する正しい答えは、質問に答えることではなく、次のように言うことです。

1. 「おそらく、代わりにWindows ネットワーク負荷分散が必要です。」または
2. 「時代に合わせて、静的コンテンツをCloud FilesやS3などに配置し、CDNで世界中にミラーリングします。」

NLBは成熟しており、タスクに非常に適しており、セットアップが非常に簡単です。クラウドソリューションには長所と短所があり、これらはこの質問の範囲外です。

質問

ラウンドロビンDNSはスターターとして十分に優れており、静的コンテンツのロードバランシングの「より良い代替案を調査および実装している間」という形で、何よりも優れていますか。

たとえば、2つまたは3つの静的Webサーバー間ですか？はい。DNSRound Robinをサーバーヘルスチェックと統合し、デッドレコードを一時的にDNSレコードから削除するDNSプロバイダーがあるため、何もしないよりはましです。だから、このようにあなたが得るまともな負荷分散と、いくつかの高可用性を。設定には5分もかかりません。

しかし、このスレッドの他の人が概説した警告が適用されます：

• 現在のMicrosoftブラウザーはDNSデータを30分間キャッシュするため、初期DNSキャッシュの状態に応じて、ユーザーのサブセットの30分間を超えるフェールオーバー時間を調べています。
• フェイルオーバー中にユーザーに表示されるものは、奇妙な場合があります（静的コンテンツに対して認証を使用しておらず、確かに認証を形成していませんが、リンクには注意すべきものが表示されます）。

その他の解決策

HAProxyは素晴らしいですが、Stack OverflowはMicrosoftテクノロジースタック上にあるため、Microsoftロードバランシングと高可用性ツールを使用すると、管理オーバーヘッドが少なくなる可能性があります。ネットワーク負荷分散は問題の一部を処理しますが、Microsoftは実際にL7 HTTPリバースプロキシ/ロードバランサーを実際に使用しています。

私は自分でARRを使用したことはありませんが、その2番目のメジャーリリースであり、Microsoftから来ているので、十分にテストされていると思います。docsを理解するのは簡単です。ここでは、Webノードでの静的コンテンツと動的コンテンツの分布を見る方法について説明します。また、負荷分散と高可用性の両方を実現するためにNLBでARRを使用する方法について説明します。

負荷分散および復元メカニズムとしてのDNSラウンドロビンに関する不情報の提供に貢献している貢献者の数は驚くべきものです。通常は機能しますが、その仕組みを理解し、そのような偽情報によって引き起こされる間違いを避ける必要があります。

1）ラウンドロビンに使用されるDNSレコードのTTLは短くする必要がありますが、ゼロではありません。TTLをゼロにすると、回復力が提供される主な方法が崩れます。

2）DNS RRは拡散しますが、負荷を分散しません。大規模なクライアントベースでは、DNSサーバーに個別に照会する傾向があるため、異なる最初の選択肢のDNSエントリになります。これらのさまざまな最初の選択は、クライアントがさまざまなサーバーによって処理され、負荷が分散されることを意味します。ただし、それはすべて、どのデバイスがDNSクエリを実行しているか、および結果を保持する期間に依存します。一般的な例は、企業プロキシの背後にあるすべてのクライアント（それらのDNSクエリを実行する）がすべて単一のサーバーをターゲットにすることです。負荷は分散されますが、均等にバランスが取れていません。

3）DNS RRは、クライアントソフトウェアが適切に実装している限り（およびTTLとユーザーアテンションスパンの両方が短すぎない限り）復元力を提供します。これは、DNSラウンドロビンがサーバーIPアドレスの順序付きリストを提供し、クライアントソフトウェアが接続を受け入れるサーバーを見つけるまで、それらの各アドレスに順番に接続を試みる必要があるためです。

したがって、最初の選択サーバーがダウンした場合、クライアントのTCP / IP接続がタイムアウトし、TTLまたはアテンションスパンのいずれも期限切れでない場合、クライアントソフトウェアはリストの2番目のエントリに対して別の接続を試行します。 TTLが期限切れになるか、リストの最後に到達します（またはユーザーが嫌悪感をあきらめます）。

破損したサーバー（障害）の長いリストと大きなTCP / IP接続再試行制限（クライアント構成の機能障害）は、クライアントが実際に動作しているサーバーを見つけるまでに長時間かかることがあります。TTLが短すぎると、リストの最後まで処理されず、代わりに新しいDNSクエリを発行して、新しいリストが（できれば異なる順序で）提供されます。

時々、クライアントは不運になり、新しいリストは壊れたサーバーから始まります。システムにクライアントの復元力を提供する最良のチャンスを与えるには、TTLが通常のアテンションスパンより長く、クライアントがリストの一番下に到達するようにする必要があります。

クライアントは、動作中のサーバーを見つけると、それを覚えておく必要があり、次の接続を行う必要がある場合、検索を繰り返してはなりません（TTLが期限切れになっていない限り）。TTLを長くすると、クライアントが動作中のサーバーを検索する際にユーザーが遅延する頻度が減り、エクスペリエンスが向上します。

4）DNS TTLは独自に機能します。DNSレコードを手動で変更する場合（たとえば、長期的に破損したサーバーを削除する場合）、短いTTLを使用すると、その変更をすばやく伝達できます（一度実行すると）。問題について知るまでにかかる時間と、手動で変更する時間とのバランスを考慮します。また、通常のクライアントは、TTLが期限切れになったときに動作中のサーバーの新しい検索を行うだけです。

DNSラウンドロビンには2つの優れた機能があり、幅広いシナリオで非常に費用対効果が高くなります。1つ目は無料、2つ目はクライアントベースとほぼ同じ地理的分散です。

他のすべての「賢い」システムが行う新しい「障害の単位」は導入されません。相互リンクされた要素の負荷全体で一般的な同時障害が発生する可能性のある追加コンポーネントはありません。

「賢い」システムは素晴らしく、シームレスなバランス調整とフェイルオーバーのメカニズムを調整および提供する素晴らしいメカニズムを導入しますが、最終的に、シームレスなエクスペリエンスを提供するために使用する方法そのものがアキレス腱です-また、そうすることで、システム全体の障害をシームレスに体験できます。

はい、そうです、DNSラウンドロビンは、すべての静的コンテンツを1か所でホストする単一のサーバーを超えた最初のステップに間違いなく「十分」です。

Windows VistaおよびWindows 7 は、IPv6アドレス選択をIPv4にバックポートしたため、ラウンドロビンのクライアントサポートを異なる方法で実装します。（RFC 3484）

したがって、Vista、Windows 7、およびWindows 2008のユーザーの数が多い場合、ersatz負荷分散ソリューションでの計画と矛盾した動作を見つける可能性があります。

ロードバランサーとして、長いTTLを使用するラウンドロビンDNSを常に使用しています。ブラウザを使用したHTTP / HTTPSサービスでは、非常にうまく機能します。

ほとんどのブラウザーはある種の「別のIPで再試行」を実装しているため、ブラウザーで本当にストレスを感じますが、他のライブラリーまたはソフトウェアが複数IPソリューションをどのように処理するかわかりません。

ブラウザーが1つのサーバーから応答を受け取らない場合、自動的に次のIPを呼び出して、それを使用し続けます（ダウンするまで...そして別のIPを試行します）。

2007年に、次のテストを実行しました。

• 次のように、1つのラウンドロビンエントリを指すiframeをWebサイトに追加します http://roundrobin.test:10080/ping.php
• このページは3つの異なるIPですべてポート10080でリッスンする3つのPHPソケットによって提供されました（Webサイトが実行されているため、ポート80でテストする余裕はありませんでした）
• 1つのソケット（Aと言う）は、ブラウザが10080ポートに接続できることを確認するためにありました（多くの企業が標準ポートのみを許可しているため）
• 他の2つのソケット（たとえばBとC）は、オンザフライで有効または無効にできます。

私はそれを1時間実行させ、大量のデータを用意しました。結果は、ソケットAでのヒットの99.5％について、ソケットBまたはCでヒットしました（もちろん、これらの両方を同時に無効にしませんでした）。ブラウザーは、iPhone、Chrome、Opera、MSIE 6/7/8、BlackBerry、Firefox 3 / 3.5でした。

今日まで、私はそれをもう一度テストしませんでしたが、おそらく新しいテストをいつかセットアップするか、他の人がテストできるようにgithubでコードをリリースするでしょう。

重要な注意：それがほとんどの時間機能していても、いくつかのリクエストが失敗するという事実を削除しません。私はアプリケーションがPOSTリクエストにも使用します。アプリケーションが機能しない場合にエラーメッセージを返すので、ユーザーがデータを再度送信できるようになり、おそらくこの場合ブラウザは別のIPを使用し、保存が機能します。また、静的コンテンツの場合、非常に優れた機能を発揮します。

したがって、ブラウザで作業している場合は、静的コンテンツまたは動的コンテンツのいずれかにラウンドロビンDNSを使用すれば、ほとんど問題はありません。サーバーはトランザクションの途中でダウンすることもあります。最適なロードバランサーを使用しても、このようなケースに対処することはできません。動的コンテンツの場合、セッション/データベース/ファイルを同期する必要があります。そうしないと、これを処理できません（ただし、実際のロードバランサーでも同様です）。

追記：を使用して、独自のIPで動作をテストできますiptables。たとえば、HTTPトラフィックのファイアウォールルールの前に、次を追加します。

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

（12.34.56.78明らかにあなたのIPはどこですか）

を使用しないでください。DROPポートはフィルター処理されたままになるため、ブラウザーはタイムアウトするまで待機します。そのため、1つのサーバーまたは他のサーバーを有効または無効にできます。最も明らかなテストは、サーバーAを無効にし、ページをロードしてから、サーバーAを有効にし、サーバーBを無効にすることです。ページを再度ロードすると、ブラウザーから少し待つと、サーバーからロードされますもう一度。Chromeでは、ネットワークパネルでリクエストを確認することでサーバーのIPを確認できます。のGeneralタブにHeaders、という名前の偽のヘッダーが表示されRemote Address:ます。これは、答えを得たIPです。

したがって、1つのサーバーでメンテナンスモードにする必要がある場合、1つのiptables REJECTルールでHTTP / HTTPSトラフィックを無効にするだけで、すべての要求は他のサーバーに送信されます（1回の待機で、ユーザーにはほとんど気付きません）。

今は2台のサーバーがあり、DNSを使用して各サーバーのIPアドレスにラウンドロビンを実行するとします。1つのサーバーがダウンすると、DNSサーバーはダウンしたことを認識せず、RRプロセスの一部としてそのIPアドレスを提供し続けます。すると、視聴者の50％が、JavaScriptまたは画像を失った壊れたサイトを取得します。

おそらく、背後にある2台のサーバーを表すWindows NLBによって処理される共通のIPアドレスを指す方が簡単です。静的コンテンツにLinuxサーバーを使用している場合を除き、どこかで読んだことを覚えていますか？

ラウンドロビンロードバランシングは、DNSゾーンも制御している場合にのみ機能するため、サーバーのリストを変更し、タイムリーにゾーンマスターにプッシュできます。

他の回答の1つで述べたように、ラウンドロビンの隠れた悪は、サーバーとクライアントの間のどこでも発生する可能性があるDNSキャッシングであり、このソリューションの小さな利点を完全に無効にします。DNS TTLを非常に低い値に設定しても、ISPまたはクライアントのDNSキャッシュが現在デッドIPアドレスをアクティブに保つ期間をほとんど制御できません。

これは確かにSPOFよりも改善されていますが、ほんのわずかです。私は誰があなたのサーバーをホストしているのかを見て、彼らが提供しなければならないものを見るでしょう、多くは彼らが提供できるある種の基本的なロードバランサーサービスを持っています。

同様に、S3に静的コンテンツが複製された単一のサーバーがあり、プライマリがダウンしたときにS3 CNAMEに切り替えることもできます。同じ遅延が発生しますが、複数のサーバーコストは発生しません。

これは、あなたが何を話しているのか、そして何台のサーバーをローテーションするのかに本当に依存します。私はかつて複数のサーバー上で稼働するサイトを持っていましたが、当時は主に初心者だったためにDNSラウンドロビンを使用していましたが、それは大きな問題ではありませんでした。クラッシュしなかったため、大きな問題ではありませんでした。それは本当にばかげた複雑でないシステムだったので、持ちこたえ、かなり一定のトラフィックレベルを持っていました。交通渋滞でクラッシュした場合、それは日中のことであり、私が簡単に処理できるものでした。あなたの静的コンテンツは、それ自体でクラッシュを引き起こさないほど単純であるとみなされます。

ハードウェア障害などを除いて、サーバーはどれくらい安定していますか？このコンテンツのトラフィックはどのくらい「スパイキー」ですか？Apacheまたは何かを直進し、トラフィックが比較的平坦であると仮定すると、それほどクラッシュすることはありません。ラウンドロビンは「十分」です。

私は100％HAソリューションを説教していないので、私は下票されると確信していますが、それはあなたが求めたものではありません。それは、解決策として費やした労力として受け入れたいものに帰着します。

負荷分散にRR DNSを使用している場合は問題ありませんが、そうではありません。冗長サーバーを有効にするためにこれを使用していますが、その場合は問題ありません。

以前の投稿で述べたように、ハートビートを検出し、戻ってくるまで叩くのをやめる必要があります。

良いニュースは、スイッチまたはWindowsのいずれかで、ハートビートを非常に安く利用できることです。

他のOSについてはDunnoですが、同様にそこにあると思います。

（たとえば、sshに使用する静的IPに加えて）各サーバーに追加のIPアドレスを割り当て、それをDNSプールに取り込むことをお勧めします。そして、サーバーに障害が発生した場合に備えて、いくつかのソフトウェアを使用してこれらのIPアドレスを切り替えます。たとえば、HeartbeatまたはCARPがこれを実行できますが、他にも解決策があります。

これには、サービスのクライアントにとって、設定を変更する必要がないという利点があり、DNSキャッシングまたはTTLを心配する必要はありませんが、DNSラウンドロビン「負荷分散」を利用することができます。 。

特に、静的ボックスに複数のIPを使用できる場合は、おそらく仕事をするでしょう。1つの「静的コンテンツの提供」IPと1つの「マシンの管理」IPがあります。その後、ボックスがダウンした場合、既存のHAソリューションまたは手動操作を使用して、障害が発生したマシンのIPを他の「クラスターメンバー」のいずれかまたは完全に新しいマシン（どれだけ速くなるかによって）起動して実行します）。

ただし、このようなソリューションにはいくつかの小さな問題があります。負荷分散は完璧に近い場所ではないため、手動での介入に依存している場合、一部の訪問者が停止する可能性があります。

ハードウェアロードバランサーは、おそらくDNSラウンドロビンよりも負荷を共有し、「クラスターの稼働時間」を提供するという点で優れた仕事をすることができます。反対に、それは1つ（または2つ、理想的にはHAクラスターにLBがあるため）、購入、電源、冷却を必要とするハードウェアと（おそらく）慣れるまでの時間です（まだ知らない場合）専用のロードバランサーがあります）。

質問に簡潔に答えるには（ラウンドロビンDNSがスターターとして十分であり、静的コンテンツの負荷分散の "より良い代替案を調査および実装している間" 何よりも優れている）、私はそれが何よりも優れていると言います、ただし、他の形式の負荷分散を引き続き調査する必要があります。

数年前にWindows Load Balancingを調査したとき、MicrosoftのWebファームは複数の負荷分散グループとして構成され、それらの間にはDNSラウンドロビンが設定されているという文書を見ました。各ネームスペースで複数のDNSサーバーが応答できるため、Microsoftの負荷分散は自己修復機能を備えているため、冗長性と負荷分散の両方が提供されます。

欠点：少なくとも4台のサーバー（2台のサーバーx 2グループ）が必要です。

Schofの答えに対するJeffのコメントに答えて、HAProxyサーバー間でDNSラウンドロビンを行う方法はありますか？

実際のソリューションを導入している間に十分に活用できる、非常にわずかな使用法です。あなたが言うように、TTLは非常に低く設定する必要があります。ただし、これには、問題が発生している間に問題のあるマシンをDNSから取り出すという副次的な利点があります。SvrA、SvrB、SvrCがコンテンツを配布しているときに、SvrAがダウンしたとします。DNSからそれを引き出し、低TTLで定義された短い期間の後、リゾルバーは稼働している別のサーバー（SvrBまたはSvrC）を見つけ出します。SvrAをオンラインに戻し、DNSに戻します。一部の人にとっては短いダウンタイム、他の人にとってはダウンタイムはありません 素晴らしいとは言えませんが、実行可能です。より多くの静的サーバーを混在させると、ユーザーの過半数グループがダウンする可能性が低くなります。

インターネットのトポロジにより、実際の負荷分散ソリューションが提供する真のバランスの取れた分散は得られません。関係するすべてのサーバーの負荷を引き続き監視します。