3.13 ネットワーキングと接続性
概要と動機
アプリケーションが行うすべてのリクエストはネットワークを越え、ネットワークはあなたの締め切りを気にしません。コードとデータベース、決済プロバイダー、ブラウザの間には、動く部品の層が座っています。名前解決、ルーティング、輻輳制御、暗号化のハンドシェイク、負荷分散装置、プロキシ、ファイアウォール。ほとんどのアプリケーションエンジニアは、これらすべてを、平らで信頼できるパイプとして扱い、その想定こそが、本番のインシデントの最も豊かな単一の源です。古典的な分散コンピューティングの落とし穴(ネットワークは信頼できる、レイテンシはゼロ、帯域幅は無限、トポロジーは決して変わらない、転送コストはゼロ)は、小さな不具合を障害に変える信念をまさに名指ししています。本章はネットワーキングの資格講座ではありません。ネットワークが誤動作しても動き続けるシステムを築くために、アプリケーションエンジニアが実際に必要とする、実用的な知識です。
大きな組織にとって、接続性は、アーキテクチャが物理と政治に同時に出会う場所です。グローバルな企業は、データセンター、クラウドのリージョン、パートナーのAPI、レガシーシステムをつなぎ合わせ、各跳躍が、レイテンシ、失敗モード、誰かが所有しなければならないセキュリティの境界を加えます。政府は、トラフィックが自分たちのネットワークにどう出入りするか、市民のデータがどこを移動してよいかについて、厳格なルールを重ねます。ネットワークを理解するチームと無視するチームの違いは、可用性の数字、ページの読み込み時間、侵害の報告、監査の指摘として現れます。この内容は、分散システム(3.3章)、スケーラビリティとレジリエンス(3.5章)、インフラとクラウドのセキュリティ(4.3章)、暗号と鍵管理(4.8章)につながります。
良い知らせは、レジリエントなシステムを築くためにルーティングプロトコルを習得する必要はないということです。どの層が決定に重要か、レイテンシがどこから来るか、名前がどう解決されるか、接続がどう保護されて負荷分散されるか、そしてネットワークの境界で穏やかにどう失敗するかを知る必要があります。それらを正しくすれば、ネットワークの大半は頼れる基盤になります。
主要原則
- ネットワークは依存先であり、所与ではない。 すべてのリモート呼び出しを、遅くなり、落ち、終わったかどうかについて嘘をつきうるものとして扱います。
- レイテンシは距離とラウンドトリップで決まる。 光の速さには勝てないので、ラウンドトリップを減らし、データをユーザーの近くに動かします。
- 名前は、マシンよりも失敗する。 名前解決と証明書は、驚くほど多くの障害を引き起こすので、第一級の運用上の関心事として扱います。
- 暗号化を意図して保護し、終端する。 トラフィックがどこで暗号化され、どこで復号され、誰が鍵を持つかを正確に知ります。
- すべてのネットワーク境界にはタイムアウトとフォールバックが必要である。 際限のない待ちと盲目的なリトライは、一つの遅い依存先をグローバルな障害に変えます。
- 縁では既定で拒否する。 ネットワークを分割し、出ていけるものを管理し、境界はすでに穴だらけだと想定します。
- コードだけでなく、接続を観察する。 接続エラー、再送、ハンドシェイクの時間、DNSのレイテンシは、ログが通常見逃すシグナルです。
推奨事項
決定に実際に影響する層を理解する
七層モデル全体を暗記する必要はありませんが、頭の中の地図は必要です。トランスポート層では、伝送制御プロトコル(TCP)が、ハンドシェイクとヘッドオブラインブロッキングのコストで、順序付けられた信頼できるバイトストリームを与え、ユーザーデータグラムプロトコル(UDP)は、配信保証のない、安くて順序のないデータグラムを与えます。信頼できるリクエスト/応答のトラフィックはTCPに乗り、リアルタイムのメディア、ゲーム、一部のテレメトリは、遅れたパケットが失われたパケットより悪いので、UDPに乗ります。
ハイパーテキスト転送プロトコル(HTTP)の進化は、性能の天井を変えます。HTTP/1.1は一度に接続あたり一つのリクエストを扱うので、ブラウザは多くの接続を開き、繰り返しのハンドシェイクを払います。HTTP/2は、一つのTCP接続上で多くのストリームを多重化し、アプリケーションレベルのヘッドオブラインブロッキングは取り除きますが、TCPレベルのものは取り除きません。一つのパケットの損失が、その接続上のすべてのストリームを止めます。HTTP/3は、QUIC、つまりUDPベースのトランスポートの上で動き、各ストリームに独立した配信、速い接続の確立、ネットワークの変化をまたぐ接続の移行を与えます。これらを自分で実装することはめったにありませんが、負荷分散装置、コンテンツ配信ネットワーク、クライアントで選び、その選択はテールレイテンシに現れます。
DNSと証明書を本番のシステムとして扱う
ドメインネームシステム(DNS)は、人間の名前をアドレスに変換し、ほぼすべてのリクエストの前に座っています。驚くほど多くの大きな障害がDNSにたどれます。誤ったレコードの変更、期限切れのゾーン、誤設定されたリゾルバ、古い答えを提供するキャッシュ層、最初のバイトに数百ミリ秒を加える遅い権威サーバー。DNSの変更を、コードのデプロイと同じ厳密さで扱います。インシデントの間にトラフィックを素早く動かせ、通常の運用で古いキャッシュを招かない、妥当なTTL(生存時間)の値を使い、名前解決のレイテンシと失敗率を本物の指標として監視します。
証明書にも同じ真剣さが値します。トランスポート層セキュリティ(TLS)の証明書が気づかれずに期限切れになると、サービス全体が一度に暗転し、その失敗はコードのバグとは似ても似つきません。発行と更新を自動化し、期限を中央で追跡し、期限のずっと前にアラートを出します。TLSをどこで終端するかを意図して決めます。エッジの負荷分散装置か、プロキシか、サービスまで届くか。エッジでの終端は内部のトラフィックを単純にしますが、再暗号化しない限り内部の跳躍を暗号化しないままにします。認証局、鍵のローテーション、暗号の選択は4.8章で扱います。ここでの運用上の要点は、DNSと証明書は静かに失敗してすべてを巻き込むので、両方を計装して自動化することです。
適切な層で負荷分散し、プロキシを働かせる
負荷分散はトラフィックを多くのバックエンドに広げ、それをどこで行うかが重要です。レイヤー4(L4)の負荷分散装置は、ペイロードを読まずにIPアドレスとポートでルーティングするので、速く、プロトコルに依存せず、安い。レイヤー7(L7)の負荷分散装置はHTTPを理解するので、パスやヘッダーでルーティングし、TLSを終端し、冪等なリクエストをリトライし、レート制限を徹底できますが、リクエストごとにより多くの仕事をします。ほとんどのアプリケーションのトラフィックは、縁にL7のリバースプロキシやAPIゲートウェイを望み、TLS、認証、ルーティング、オブザーバビリティを扱う一つの場所を与えます。L4は、生のスループットやHTTPでないプロトコルのために取っておきます。
ヘルスチェックが、負荷分散を安全にするものです。「プロセスが動いている」だけでなく、本物の準備を反映するよう設定し、データベースに届かないバックエンドが、エラーを返す前にローテーションから外されるようにし、デプロイ時には接続をドレインして処理中のリクエストが終わるようにします。APIゲートウェイは横断的関心事(認証、レート制限、リクエストの整形、バージョニング)を集中させますが、重要な依存先であり、潜在的なボトルネックになるので、他の中核サービスと同じ可用性の予算とオブザーバビリティを与えます。
CDNとエッジでデータをユーザーの近くに動かす
レイテンシはラウンドトリップ時間に支配され、ラウンドトリップ時間は距離に支配されます。コンテンツ配信ネットワーク(CDN)は、ユーザーの近くのアクセス拠点にコンテンツをキャッシュするので、静的なアセット、そしてますます動的でパーソナライズされた応答も、海をまたぐのではなく、数ミリ秒先から提供されます。地理的に広がった利用者を持つあらゆるユーザー向けの製品にとって、CDNは、行える最も見返りの高い性能への投資の一つで、トラフィックの急増と大量の攻撃を吸収する盾としても働きます。
役立つ所では、仕事をエッジに押しやります。エッジでTLSを終端すると、高価なラウンドトリップがユーザーの近くで起こるので、ハンドシェイクのレイテンシが縮み、エッジの拠点でAPIの応答をキャッシュすると、一般的なリクエストの経路長が縮みます。取引はキャッシュの無効化です。データが近く、キャッシュされるほど、鮮度を保証するのは難しくなるので、何が、どれだけ古くてよいかを明示してください。これは3.5章のキャッシュと性能の議論につながります。
ネットワーク境界を既定でレジリエントにする
すべてのリモート呼び出しは、ネットワークがあなたを傷つけうる場所なので、それぞれを同じ規律で包みます。ハングした依存先が接続プールとスレッドプールを使い果たしてその背後のすべてを止めるので、すべての呼び出しに明示的なタイムアウトを設定します。繰り返しても安全な操作だけをリトライし、瞬断が同期したリトライの嵐にならないようジッター付きの指数バックオフを使い、合計の試行回数と合計時間に上限を設けます。閾値の失敗の後、すでに溺れているサービスにリクエストを積み上げる代わりに、クールダウンの間は速く失敗するようサーキットブレーカーを加えます。これらのパターンは3.3章で深く扱われます。ここでの要点は、それらがとりわけネットワーク境界に属するということで、各チームが再発明するのではなく、理想的には共有のプラットフォームの既定としてです。
タイムアウトを呼び出しの連鎖の下へ予算化します。ユーザー向けのリクエストに2秒の予算があり、四つの跳躍をまたぐなら、各跳躍は残り時間がどれだけ少ないかを知り、虚空にリトライするのではなく速く失敗しなければなりません。プーリングとキープアライブで接続を再利用し、リクエストごとに新しいTCPとTLSのハンドシェイクを払わないようにし、平均だけでなくテールレイテンシを観察します。遅い1パーセントこそ、ユーザーが覚えていて、負荷のもとで連鎖するものだからです。
ネットワークのトポロジーを設計し、統治する
クラウドでは、ネットワークは設定するソフトウェアなので、意図して設定します。ワークロードを仮想プライベートクラウド(VPC)に置いて分割します。公開向けの層、アプリケーションの層、データの層を、存在すべきトラフィックだけを許可するルールを伴う別々のサブネットに。イングレスと同じくらい意図して、エグレスを管理します。管理されない外向きのアクセスは、侵害の間にデータが出ていく方法であり、侵害されたワークロードがコマンド・アンド・コントロールのサーバーに届く方法なので、外向きのトラフィックを管理されたゲートウェイを通し、本当に届く必要のある宛先を許可リストにします。IPv6を後回しにせず計画してください。アドレスの枯渇とパートナーの要件がいずれそれを強い、後付けは苦痛だからです。
ゼロトラストセキュリティモデルを採用します。「ネットワークの内側」を信頼するものとして扱うのをやめ、ネットワーク上の位置ではなくアイデンティティに基づいて、すべてのリクエストを認証し認可します。実際には、サービス間の相互TLS、短命の認証情報、隣のサブネットから来たからリクエストが安全だと想定しない方針を意味します。サービスメッシュは、これの多くを一様に提供できます。各サービスと並べてサイドカーのプロキシを動かすことで、メッシュはアプリケーションのコードを変えずに、相互TLS、一貫したリトライとタイムアウト、跳躍ごとのテレメトリを与えます。運用の複雑さといくらかのレイテンシを加えるので、サービスの数が、一様でコード不要の徹底をオーバーヘッドに見合うものにしたときに採用します。ゼロトラストと分割は、4.3章と8.3章でさらに展開されます。
トレードオフ: 長所と短所
| 決定 | 長所 | 短所 / コスト |
|---|---|---|
| L7負荷分散装置 / APIゲートウェイ | 賢いルーティング、TLS終端、認証、レート制限、オブザーバビリティ | リクエストごとのレイテンシの増加、重要な共有の依存先 |
| L4負荷分散装置 | 速く、プロトコルに依存せず、安い | HTTPを見ることも作用することもできない。内容を考慮したルーティングなし |
| エッジでのTLS終端 | 速いハンドシェイク、単純なバックエンド | 再暗号化しない限り、内部の跳躍が暗号化されない |
| CDNとエッジのキャッシュ | 大きなレイテンシの改善、急増と攻撃を吸収 | キャッシュの無効化と古さ、追加のコストと設定 |
| サービスメッシュ | アプリを変えずに一様な相互TLS、リトライ、テレメトリ | 運用の複雑さ、サイドカーのレイテンシとリソースコスト |
| QUIC上のHTTP/3 | トランスポートのヘッドオブラインブロッキングなし、速い確立、接続の移行 | より新しいツール、UDPが絞られることがある、デバッグが難しい |
中心的な緊張は、制御と単純さの間にあります。ネットワーク境界に加えるすべての有能なコンポーネント(L7ゲートウェイ、メッシュ、CDN、エグレスプロキシ)は、ルーティングの知能、セキュリティの徹底、可視性を買い、それぞれがまた、一つの跳躍、一つの失敗モード、運用すべき何かを加えます。共有の関心事を共有のインフラに押しやるのは、十分な数のチームがそれを必要として運用上の重さを正当化するときだけにし、速い経路を短く保つことで解決します。マネージドな負荷分散装置でTLSを終端してそれで済ませる二人のスタートアップは、同じチームがサービスメッシュを手作りするより、良い取引をしています。一様な相互TLSとエグレスの管理を持たない千サービスの企業は、より悪い取引をしています。
チームで議論すべき問い
各リクエストの経路で、TLSはどこで終端し、全員が同じように描けますか。 これは、インシデントが起こるまでは些細なことに聞こえます。チームの半分がトラフィックは端から端まで暗号化されていると信じ、もう半分がエッジで復号されてバックエンドに平文で送られていると知っているなら、セキュリティのギャップとデバッグの罠の両方があります。大きな組織にとって、この問いはコンプライアンスに直接対応します。規制当局と監査人は、市民や顧客のデータが平文でどこを移動するかを尋ね、「確かではない」は指摘事項です。クライアントからデータベースまでの一つの本物の経路の実際の図を持ち込み、暗号化が始まり終わるすべての点と、誰が各証明書と鍵を持つかに印を付けてください。答えは、内部の再暗号化が必要か、相互TLSがどこに属するか、期限が切れるとサービスを落とす証明書がどれかを教えるはずです。誰も自信をもって描けないなら、そのギャップが最初の仕事です。
DNSが遅い、あるいは間違っているとき、システムはどうなり、実際にそれをテストしましたか。 DNSはほぼすべてのリクエストの上流にありますが、ほとんどのチームは、DNSの劣化のもとでシステムを観察したことがありません。遅いリゾルバはすべての新しい接続にレイテンシを加え、古いキャッシュは廃止されたホストにトラフィックを送りえ、誤ったレコードの変更は、サービス全体を数秒でブラックホールにしえます。大きな企業では、内部のサービスディスカバリ、パートナーとの統合、クラウドのエンドポイントがすべて名前解決に頼るので、影響範囲はより広くなります。DNSのTTLの設定、あれば名前解決のレイテンシの指標、誤ったレコードの変更のランブックを持ち込み、インシデントの間にトラフィックを実際にどれだけ速く動かせるかを問ってください。答えは、名前解決を第一級の指標として監視するか、敏捷性とキャッシュ効率の両方のためにTTLを調整するか、DNSのフェイルオーバーをリハーサルするかを導くはずです。DNSの失敗を管理されたテストで引き起こしたことがないなら、その実験はカレンダーに載せるべきです。
ネットワーク境界のレジリエンスのパターンのうち、プラットフォームの既定はどれで、どれをすべてのチームが再発明していますか。 タイムアウト、ジッター付きの上限付きリトライ、サーキットブレーカー、コネクションプーリング、跳躍ごとのトレーシングは、一度築かれて全員に引き継がれるときに、最も安く最も信頼できます。個々のチームに任せると、それらはずれます。タイムアウトのない呼び出し、冪等でない操作をリトライするもの、接続レベルのテレメトリを出さないものがあり、ギャップは負荷のもとでのみ表面化します。大きなチームにとって、これは、レジリエンスがどこに住むかについての組織的な選択です。共有のライブラリやプラットフォーム層か、サービス全体に散らばるか。サービスのサンプルを監査して、いくつがすべてのリモート呼び出しに明示的なタイムアウトを設定し、相関識別子を端から端まで伝播しているかを数えたものを持ち込んでください。その数が低いなら、修正はプラットフォームへの投資で、それを標準化することは、レジリエンスをテスト可能で監査可能にもし、それは規制された分野でますます重要です。答えは、ネットワークのプラットフォーム能力に資金を出すか、インシデントで一貫性のなさにお金を払い続けるかを教えるはずです。
各ワークロードは今、公共のインターネット上の何に届き、それらの外向きの宛先のそれぞれを誰が承認しましたか。 イングレスは攻撃者がノックする場所なので注意を集めますが、エグレスは、侵害の間にデータが実際に出ていく方法であり、侵害されたワークロードがコマンド・アンド・コントロールのサーバーに連絡する方法です。ほとんどのチームは、自分に話しかけるものを、自分が話しかけるものよりはるかに簡単に一覧にでき、その非対称性こそが攻撃者が突くギャップです。相反する考慮は摩擦です。承認された宛先の許可リストは、今日新しいサードパーティのAPIを呼び出したい開発者を遅くするので、誠実な議論は、縮んだ影響範囲と引き換えに、どれだけの便利さを手放すかです。代表的なサービスの現在の外向きのルール、過去一週間に実際にどこへ接続したかのキャプチャ、新しい宛先を承認するプロセス(あれば)を持ち込んでください。企業と政府のシステムでは、これは任意の衛生ではなく監査の項目です。境界の保護とエグレスの一覧は、まさに規制当局とネットワーク境界の規則が提出を求めるもので、「どのワークロードもどこにでも届く」は、是正を告げられる指摘事項です。
タイムアウトとリトライは、呼び出しの連鎖の下で一つの一貫した予算に合成されますか。それとも、各跳躍が孤立して推測していますか。 四つのサービスをまたぐユーザー向けのリクエストには、ユーザーが実際に感じる単一の締め切りがありますが、各跳躍は通常、ローカルに自分のタイムアウトを設定し、すでに諦めたサービスにリトライし、余分な仕事をしながらエンドツーエンドの予算を吹き飛ばします。大きなチームにとって、危険は創発的です。個々には妥当なサービスごとのタイムアウトが、連鎖する停止と同期したリトライの嵐に複合し、どの単一のチームも自分のダッシュボードからは見えません。緊張は、各チームが自分の限度を調整するローカルな自律と、すべての跳躍が読んで、時間が使われるにつれて縮める、伝播する締め切りの間にあります。各跳躍のタイムアウトとリトライの方針を伴う本物のリクエストの経路、製品が約束するエンドツーエンドの予算、負荷のもとでのテールレイテンシの数字(平均ではなくp99)を持ち込んでください。規制された高可用性の文脈では、これを復旧目標に結びつけてください。予算内で速く失敗できない連鎖は、一つの遅い依存先を、侵害されたサービスレベル目標に変え、その侵害こそがリーダーシップと監査人があなたに説明を求める数字です。
どのサービスの数とトラフィックのプロファイルで、一様な徹底(サービスメッシュ、L7ゲートウェイ、エッジのキャッシュ)が運用上の重さに見合い、今日その曲線のどこにいますか。 ネットワーク境界に加えるすべての有能なコンポーネントは、ルーティングの知能、セキュリティ、可視性を買い、それぞれがまた、一つの跳躍、一つの失敗モード、24時間運用すべき何かを加えます。メッシュを早すぎる時期に採用すれば、少数のサービスをサイドカーの複雑さに溺れさせ、遅すぎる時期に採用すれば、一様な相互TLSや一貫したリトライのない千のサービスを抱えます。競合する考慮は、多くのチームにわたるコード不要で一貫した徹底の価値と、コントロールプレーンを動かす本物のコスト、追加のレイテンシ、それをデバッグできる乏しい人々です。現在のサービスの数と成長曲線、すでに同じ保証を提供する共有クライアントに乗っているサービスの割合、使えるレイテンシの余裕を持ち込んでください。大きな企業や機関にとって、この決定はガバナンスの決定でもあります。メッシュや中央のゲートウェイは、プラットフォームチームが方針をあらゆる所に一度に展開できるようにし、それはコンプライアンスには強力ですが、その単一の隘路の資源が不足していれば危険なので、副次的なプロジェクトではなく、独自の可用性目標を持つ中核のインフラとして予算化してください。
セクター別の視点
スタートアップ。 マネージドなインフラに頼り、乏しいエンジニアリングの注意を、パケットではなく製品に使ってください。自動更新される証明書でTLSを終端するマネージドなL7負荷分散装置と、アプリの前のCDNが、運用チームなしに、暗号化され、負荷分散され、世界的に速いトラフィックを買います。すべての外部呼び出しを、タイムアウトと上限付きのリトライを伴う小さな共有クライアントで包み、人より多くのサービスができるまでサービスメッシュには抵抗します。
小規模事業者。 ネットワークの専門家はおらず予算も厳しいので、接続性を、構築するものではなく、設定済みで買うものとして扱ってください。自動化された証明書、DNS管理、妥当なファイアウォールをすでに既定で与えるクラウドプロバイダーやプラットフォームを選び、自分で組み立てるのではなく、それらが提供するものをオンにします。決めなければならない所では、マネージドの選択肢を好みます。ベンダーに証明書の更新とDNSの監視にお金を払うことは、忘れられた期限切れが引き起こす障害よりはるかに安いのです。
大企業。 問題は多くのチームとリージョンにわたる一貫性です。一様な相互TLS、標準化されたタイムアウトとリトライ、管理されたエグレス、そしてどのチームもオプトアウトできない証明書とDNSの監視。これらを共有のプラットフォームのインフラ(サービスメッシュ、内部ゲートウェイ、共有のクライアントライブラリ)に押しやり、レジリエンスが再発明されるのではなく引き継がれるようにし、ネットワーク境界を、他の中核サービスと同じ可用性の予算とオブザーバビリティで管理します。VPCを分割し、エグレスを中央で統治し、トポロジーを監査するソフトウェアとして扱います。
政府。 調達規則、透明性、公的な説明責任があらゆる境界を形づくります。インターネットへ向かうトラフィックを、少数の堅牢化され監視されたゲートウェイに流し、すべての外部エンドポイントを一覧にし、サービスがネットワーク上の位置ではなく、短命の認証情報でアイデンティティによって認証される、ゼロトラストアーキテクチャを運用します。DNSと証明書の管理を、専用の監視を伴う重要なインフラとして扱います。市民向けのサービスの期限切れの証明書一つが、公衆と立法府の両方の精査を招くからです。そして境界保護のレビューが、文書化された擁護できる設計を見つけられるよう、証拠を監査可能に保ちます。
事例
スタートアップ。 10人のサービスとしてのソフトウェア会社は、すべてを、自動更新される証明書でTLSを終端する単一のマネージドなL7負荷分散装置の背後で動かし、ウェブアプリケーションとAPIの前にCDNを置きます。その組み合わせが、専任の運用チームなしに、速い世界的なページの読み込みを与え、製品のローンチからのときどきのトラフィックの急増を吸収し、オリジンを守ります。決済プロバイダーとメールサービスへのすべての呼び出しに明示的なタイムアウトと上限付きのリトライを設定し、小さな共有クライアントで包むので、遅いサードパーティがユーザーのリクエストをハングさせることは決してありません。サービスメッシュは加えません。十数のサービスでは、運用のコストが利益を上回り、マネージドなインフラがすでに暗号化され負荷分散されたトラフィックを与えているからです。
大企業。 多国籍の小売業者は、三つのクラウドのリージョンとレガシーのオンプレミスのデータセンターにまたがって運用し、在庫と決済のトラフィックが開かれたネットワークを決して通らないよう、公共のインターネットではなくプライベートのリンクで接続しています。各リージョンは、公開、アプリケーション、データのサブネットが別々の、分割されたVPCにあり、すべての外向きのトラフィックは承認された宛先を許可リストにするエグレスゲートウェイを通るので、侵害されたワークロードが静かにデータを持ち出すことはできません。何百ものサービスが、あらゆる所で相互TLSを徹底し、一様なリトライ、タイムアウト、トレーシングを適用するサービスメッシュを通じて通信するので、中央のプラットフォームチームは、アプリケーションのコードに触れずに新しいリトライの方針を展開できます。中央集権的な証明書の監視が期限を何日も前に指摘し、自動化が顧客が気づく前にそれらをローテーションします。
政府。 国の機関は、インターネットへ向かうすべてのトラフィックを、信頼されたインターネット接続のモデルに沿って、少数の堅牢化され監視されたゲートウェイに流す、ネットワーク境界の保護規則のもとで運用しています。機関間のトラフィックはプライベートの接続上で動き、すべての外部エンドポイントが一覧にされているので、セキュリティチームは何が出入りできるかを正確に知っています。機関は、サービスが短命の認証情報でアイデンティティによって互いに認証し、境界の内側から来たというだけではリクエストが信頼されない、ゼロトラストアーキテクチャを運用しています。DNSと証明書の管理は、専用の監視を伴う重要なインフラとして扱われます。期限切れの証明書一つや誤ったゾーンの変更が、市民向けの給付ポータルを落とし、公衆と立法府の精査の両方を生みうるからです。
ビジネスケース: 動機、ROI、TCO
ネットワーキングの規律は安く買え、その不在は最悪の瞬間に支払われます。投資は大半が一度きりでプラットフォームの形をしています。タイムアウトとリトライを伴う共有クライアント、自動化された証明書管理、DNSの監視、適切に分割されたVPC、エッジのキャッシュ。それぞれがそれを引き継ぐすべてのチームの利益になるので、チームごとの限界コストは低く、見返りは複利で増えます。特にCDNは、しばしば二度元を取ります。オリジンの帯域コストを削りながら、より速いページの読み込みに続くコンバージョンとエンゲージメントの数字を改善するからです。
この仕事を飛ばすコストは、障害と侵害で測られます。期限切れの証明書や誤ったDNSの変更は、エンジニアが誤った層を追う間に修正が遅れ、数分で製品全体をオフラインにしえます。欠けたタイムアウトは、一つの遅い依存先を完全なプラットフォームの停止に連鎖させえます。管理されないエグレスは、侵害されたワークロード一つを、データ持ち出しのインシデントに変えます。リーダーシップがすでに追跡している言葉で論拠を示してください。可用性、平均復旧時間、ページの読み込み時間、侵害のリスク。自動化された証明書とDNSの管理は、自ら招く障害の種類を防ぎ、エッジとCDNへの投資は製品の性能指標を動かし、分割とエグレスの管理は侵害の影響範囲を縮めます。総所有コストの議論は、本ガイド全体で繰り返されるものです。能力を作り込むことは、問題を強いるインシデントの後に後付けするコストの何分の一かです。
アンチパターンと落とし穴
- ネットワークは信頼できて速いと想定する。 リモート呼び出しがローカルであるかのようにコーディングし、タイムアウトも、リトライも、「タイムアウトしたがおそらく完了した」の処理もないこと。
- 手作業の証明書管理。 期限をスプレッドシートや誰かの記憶で追跡し、気づかれずに失効したときの最終的な障害を保証すること。
- DNSを運用システムとして無視する。 名前解決の監視がなく、TTLが雑で、デプロイの厳密さなしにレコードが変更されること。
- 冪等性もバックオフもないリトライ。 重複した副作用と、小さな瞬断を障害に増幅する同期したリトライの嵐。
- 内部ネットワークを信頼する。 境界の内側のあらゆるものを安全として扱い、暗号化されない内部トラフィックとアイデンティティに基づく認可がないこと。
- 管理されないエグレス。 ワークロードがどんな外向きの宛先にも届くことを許し、攻撃者に持ち出しの経路とコマンドサーバーへのチャネルを渡すこと。
- おしゃべりなリクエストの経路。 各跳躍がラウンドトリップを加える深い同期の呼び出しの連鎖で、負荷のもとでテールレイテンシが膨らむこと。
- サービスメッシュの早すぎる採用。 共有クライアントのほうがよく仕えたはずの少数のサービスのために、サイドカーの複雑さとレイテンシを引き受けること。
成熟度モデル
- レベル1、開始: リモート呼び出しがローカルの呼び出しのように扱われます。タイムアウトとリトライは欠けているか素朴で、「タイムアウトしたがおそらく完了した」は処理されません。証明書とDNSは手作業で管理されて驚きの障害を引き起こします。分割はなく、内部のトラフィックは既定で信頼されます。接続性の仕事は反応的で、インシデントが強いた後にだけ起こります。
- レベル2、発展: 一部のチームは基本的な実践を採用しましたが、サービス間で一貫しません。タイムアウトと単純なリトライは一部にあり、TLSは負荷分散装置で終端され、証明書はほぼ自動化されています。CDNが静的なコンテンツの前にあり、基本的なネットワークの分割はありますが、エグレスはおおむね開いていて、各チームが独自のクライアントを発明します。あるチームがうまくやることを、別のチームはまだ始めていません。
- レベル3、標準化: レジリエントなネットワーキングは、文書化され、組織全体で徹底されています。タイムアウト、ジッター付きのバックオフ、サーキットブレーカーは、すべてのチームが引き継ぐ共有ライブラリやゲートウェイを通じて標準です。DNSと証明書は本番のシステムとして監視され自動化され、VPCは管理されたイングレスとエグレスで分割され、接続レベルのテレメトリがあらゆる所で集められ、ゼロトラストの原則が、一つのチームの実験ではなく方針として採用されつつあります。
- レベル4、管理: ネットワーク境界が、標準化されているだけでなく、ベースラインに対して測定され、制御されています。名前解決のレイテンシ、TLSのハンドシェイク時間、再送と接続エラー率、テールレイテンシ(平均ではなくp99)、証明書の期限までの余裕、エグレス方針の違反が、アラートの閾値とエラーバジェットを伴うダッシュボードで追跡されます。継続・中止とキャパシティの判断はそのデータに駆動され、意図したDNSと依存先の障害の訓練がスケジュールで実行されて結果が測定され、どのシグナルの回帰も、次の障害で発見されるのではなく捉えられ所有されます。
- レベル5、オーケストレーション: レジリエントなネットワーキングは、継続的に改善され、組織全体に統合され、変化に適応する、プラットフォームの既定です。相互TLSとアイデンティティに基づく認可は、しばしばサービスメッシュを通じて一様で、エッジとCDNの戦略は実際のレイテンシのデータに対して調整され、エグレスは完全に統治され、トポロジー、プロバイダー、ルーティングの選択は、コスト、リスク、トラフィックの変化に応じて再均衡されます。ネットワーキングの決定は、キャパシティ、セキュリティ、ビジネスの計画に織り込まれ、組織は、ラウンドトリップ、テールレイテンシ、境界の失敗モードについて、当然のこととして明示的に推論します。
議論のためのアイデア
- 主要なDNSプロバイダーやリゾルバが一時間劣化したら、システムのどれだけがまだ動き、それをどうやって知りますか。
- サービスのうち、「内側」に入ったトラフィックをまだ暗号化せずに送っているものはどれで、そのギャップを閉じるには何が必要ですか。
- アーキテクチャの中で最も深い同期の呼び出しの連鎖はどこで、典型的なユーザーのリクエストは実際にいくつのネットワークのラウンドトリップを招いていますか。
- タイムアウトは呼び出しの連鎖の下で一貫した予算に合成されますか。それとも、各層が自分で設定して願っていますか。
- ワークロードは今、公共のインターネット上の何に届き、それらの外向きの宛先のそれぞれを誰が承認しましたか。
- 何個のサービスで、サービスメッシュの一様な徹底が運用コストを上回り、あなたの組織はそれにどれだけ近いですか。
要点
- ネットワークは独自の失敗モードを持つ依存先です。すべてのリモート呼び出しを、成功か明確な失敗だけでなく、遅さ、損失、完了のあいまいさのために設計します。
- レイテンシはラウンドトリップと距離に支配されるので、跳躍を減らし、接続を再利用し、CDNとエッジでデータをユーザーの近くに動かします。
- DNSとTLS証明書は静かに失敗してサービス全体を落とします。両方を本番のシステムとして自動化し監視します。
- トラフィックに合う層で負荷分散し、共有の関心事は、可用性とオブザーバビリティのコストが正当化されるときにだけL7ゲートウェイの背後に置きます。
- ネットワーク境界を、タイムアウト、ジッター付きの上限付きリトライ、サーキットブレーカーで既定でレジリエントにします。理想的には、引き継がれるプラットフォームの既定として。
- VPCを分割し、エグレスを統治し、IPv6を計画し、ゼロトラストを採用して、ネットワークの「内側」にいることが、自動的な信頼を与えないようにします。
参考文献とさらなる読み物
- W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols
- Ilya Grigorik, High Performance Browser Networking
- Cricket Liu and Paul Albitz, DNS and BIND
- Andrew S. Tanenbaum and David J. Wetherall, Computer Networks
- Michael Nygard, Release It!: Design and Deploy Production-Ready Software
- Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
- Lee Calcote and Zack Butcher, Istio: Up and Running (service mesh concepts)
- Internet Engineering Task Force, RFC 9110 (HTTP Semantics) and RFC 9000 (QUIC)
- Peter Deutsch and James Gosling, “The Eight Fallacies of Distributed Computing”
- National Institute of Standards and Technology, Special Publication 800-207: Zero Trust Architecture