オリジンサーバーとは？CDNとの違い

オリジンサーバーとは、CDN、リバースプロキシ、ロードバランサーといった中継役に、元のウェブサイトのコンテンツやアプリケーションの応答を提供するシステムです。訪問者は、オリジンに直接ではなく、その中継役に接続することがあります。中継役は、コンテンツのキャッシュ、TLSの終端、トラフィックのフィルタリング、リクエストの分散、オリジンを直接の露出から守る役割などを担えます。この構成があるため、ドメインからIPへの検索では、アプリケーションのデータが保存されているマシンではなく、CDNやプロキシに属するアドレスが返されることがよくあります。公開DNSの答えが示すのは、公開されている入口であり、その背後にあるすべての内部コンポーネントとは限りません。

中継役を通るリクエストの経路

典型的なリクエストの経路は、DNSが公開ホスト名をエッジのアドレスに解決するところから始まります。ユーザーのブラウザーはCDNやプロキシに接続し、プロキシはキャッシュされた応答を返せるか、オリジンにリクエストを転送すべきかを判断します。オリジンは、仮想マシン、コンテナプラットフォーム、クラウドのロードバランサー、マネージドホスティングサービスなどです。公開エッジとアプリケーションの間には、複数の層が存在することもあります。各層には、それぞれ別のヘルスチェック、ルーティング、セキュリティの設定があります。そのため、DNSクエリが成功したことで確認できるのは、入口の公開アドレスだけです。プロキシがオリジンに到達できることまでは確認できません。

オリジンを中継役の背後に置けば、直接の露出を減らし、制御を一元化できますが、この設計は設定が正しいことが前提です。オリジンは、可能であれば、想定したプロキシのネットワークか認証された経路からのトラフィックだけを受け付けるのが一般的で、管理者は、無関係なDNSレコードやアプリケーションのインフラを通じて、オリジンの直接のアドレスを誤って公開しないようにすべきです。同時に、オリジンは、監視され、プロキシから到達可能な状態を保たなければなりません。許可リストの設定を誤ると、正当なエッジのトラフィックを遮断することがあります。また、オリジンに障害が起きると、DNSとCDNのエッジが正常でも、公開ドメインが失敗することがあります。

IP検索でオリジンを特定できない理由

DNS検索が返すのは、リゾルバーが参照することを許されたレコードです。ドメインがCDNを指している場合、その答えはCDNの公開エンドポイントです。オリジンはDNSで公開されていないかもしれず、検索ツールがエッジのIPをオリジンだと主張すべきではありません。アドレスの所有者情報は、インフラプロバイダーの特定に役立つことがありますが、それでもバックエンド全体の構成までは明らかになりません。セキュリティやインシデント対応の作業では、こうした証拠を慎重に扱ってください。共有されたエッジのアドレスは多数のドメインにサービスを提供することがあり、1つのアドレスに基づく思い込みは、サービスの帰属を誤らせることがあります。

• DNSは、公開された入口の特定に使い、バックエンドのアーキテクチャを決めつけるために使わない。
• オリジンへの接続性とヘルスは、CDNやリバースプロキシのダッシュボードで確認する。
• オリジンへのアクセスは、文書化されたネットワークと認証の制御で保護する。
• プライベートなオリジンや管理用のオリジンを、意図せず公開DNSに出さない。
• 観測したIPは、ある時点での公開DNSの答えとして、正確に記述する。

外側から内側へ向かってトラブルシューティングする

ユーザーがサイトに到達できないときは、まず公開DNSを確認し、次にエッジの接続と証明書をテストし、最後にプロキシからオリジンへのヘルスとアプリケーションのログを調べます。有効な公開アドレスがあるのにプロキシのエラーが出る場合、原因はDNSの先にあることが多くあります。一部の地域でのみ失敗する場合は、リゾルバーの答えとCDNのヘルスを、地域ごとに比較します。レコードを変更したあと、すべての地域で失敗する場合は、新しいDNSの宛先が、プロバイダーが想定する設定と一致しているかを確認します。この階層的な方法なら、保護を迂回したり、自分が管理していない隠れたインフラを探そうとしたりしなくても、問題を絞り込めます。

関連するアーキテクチャについては、CDNがDNSでトラフィックを振り分ける仕組み と CDNがオリジンIPを隠す理由 をご覧ください。公開の ドメイン検索ツール は、DNSが現在公開しているアドレスを確認するのに便利です。オリジンを診断するには、公開された名前解決をサービスの内部設計の完全な地図とみなすのではなく、自社のホスティングとプロキシのテレメトリを使ってください。

オリジンは特定のアドレスではなく、アプリケーション上の役割

チームは、オリジンを1つのサーバーIPと表現することがありますが、現代の構成では、1つのCDNの背後に、複数のオリジンプール、プライベートなロードバランサー、サーバーレスアプリケーション、ストレージサービスが存在することもあります。オリジンという役割は、特定の恒久的なマシンではなく、中継役にコンテンツを提供しているものによって決まります。公開DNSが同じエッジを公開し続けていても、オリジンは移動したり、スケールしたりできます。アーキテクチャを文書化するときは、公開ホスト名、CDNエッジ、オリジンのエンドポイント、アプリケーションのバックエンドという、それぞれの境界にラベルを付けてください。インシデント対応者が、適切な担当者に適切なログを依頼しやすくなります。エッジで応答が失敗した場合は、公開DNSのアドレスが障害の起きたコンポーネントを特定すると思い込まず、エッジの診断情報をオリジンのヘルスやリクエストIDと突き合わせてください。