Architecture

LTM と GSLB：現代のトラフィック管理の基盤

Created   Updated
Load Balancing Infrastructure Networking
  1. ローカルトラフィック管理の理解
  2. グローバルサーバーロードバランシング
  3. LTM と GSLB の組み合わせ
  4. 本番環境インシデント：GSLB が危機を救った日
  5. LTM と GSLB：並列比較
  6. LTM と GSLB をいつ使用するか
  7. 代替案と現代的なアプローチ
  8. 運用上の考慮事項
  9. 結論

現代のアプリケーションは、高可用性、パフォーマンス、地理的分散を必要とします。ユーザーは場所に関係なく即座の応答を期待し、サービスは個々のサーバーやデータセンター全体が故障しても稼働し続ける必要があります。ローカルトラフィックマネージャー（LTM）とグローバルサーバーロードバランシング（GSLB）は、これらの課題に対するソリューションとして登場し、分散システムにおけるトラフィック管理の基盤を形成しています。

LTM は単一のデータセンター内で動作し、複数のサーバーにトラフィックを分散してリソース利用を最適化し、フォールトトレランスを提供します。GSLB はこの概念をグローバルに拡張し、場所、健全性、容量に基づいてユーザーを最適なデータセンターに誘導します。両者を組み合わせることで、パフォーマンスと可用性を維持しながら、複数のレベルで障害に耐えられる回復力のあるアーキテクチャを構築できます。

本記事では、LTM と GSLB がどのように機能するか、そのアーキテクチャパターン、および運用上のトレードオフについて検討します。実際の実装例を通じて、各技術がいつ意味を持つか、そして現代のインフラストラクチャでどのように補完し合うかを明らかにします。

ローカルトラフィック管理の理解

ローカルトラフィックマネージャーは、データセンターレベルで動作し、クライアントとアプリケーションサーバーの間に位置して、受信リクエストをインテリジェントに分散します。

LTM アーキテクチャ

LTM は、高度なトラフィック分散機能を備えたリバースプロキシとして機能します：

🔄 LTM コアコンポーネント

仮想サーバー

  • 複数のバックエンドサーバーを表す単一の IP アドレス
  • クライアントは個々のサーバーではなく仮想 IP（VIP）に接続
  • クライアント接続を終端し、バックエンドへの新しい接続を開始
  • SSL/TLS 終端を実行可能
  • トラフィックポリシーとルーティングルールを適用

サーバープール

  • 同じサービスを提供するバックエンドサーバーのグループ
  • メンバーは動的に追加または削除可能
  • 各メンバーにヘルスモニタリングあり
  • 容量の違いに対応する重み付け分散をサポート
  • ダウンタイムなしのローリングデプロイメントを実現

ヘルスモニタリング

  • アクティブチェック：LTM が定期的にサーバーをプローブ
  • パッシブチェック：実際のトラフィックを監視して障害を検出
  • 複数のチェックタイプ：TCP、HTTP、HTTPS、カスタムスクリプト
  • 障害サーバーをローテーションから自動削除
  • 回復後に段階的に再導入

LTM は接続状態を維持し、サーバーの健全性を追跡し、設定されたアルゴリズムと現在の状況に基づいてリアルタイムでルーティング決定を行います。

ロードバランシングアルゴリズム

異なるアルゴリズムは異なるアプリケーション特性に適しています：

⚖️ 分散戦略

ラウンドロビン

  • リクエストをサーバー間で順次分散
  • シンプルで予測可能
  • サーバーの容量が等しい場合に適している
  • 現在のサーバー負荷を考慮しない
  • リクエストコストが均一なステートレスアプリケーションに最適

最小接続数

  • アクティブ接続数が最も少ないサーバーにルーティング
  • 長時間接続を考慮
  • リクエスト期間が変動するアプリケーションに適している
  • 接続追跡のオーバーヘッドが必要
  • データベース接続とストリーミングに効果的

重み付け分散

  • サーバー容量に比例してトラフィックを割り当て
  • サーバーの仕様が異なる場合に有用
  • デプロイメント中にトラフィックを段階的にシフト可能
  • 容量計画とチューニングが必要
  • ブルーグリーンデプロイメントパターンを実現

IP ハッシュ / セッション永続性

  • 同じクライアントを同じサーバーにルーティング
  • ステートフルアプリケーションのセッションアフィニティを維持
  • 不均等な分散を引き起こす可能性
  • サーバーメンテナンスを複雑化
  • 代替案：共有セッションストレージ

アルゴリズムの選択は、アプリケーションアーキテクチャ、特にセッションがステートフルか自由に分散できるかに依存します。

SSL/TLS 終端

LTM は一般的に SSL/TLS 終端を処理し、暗号化操作をアプリケーションサーバーからオフロードします：

🔒 SSL 終端の利点

パフォーマンス最適化

  • 集中型証明書管理
  • 暗号化操作のハードウェアアクセラレーション
  • アプリケーションサーバーの CPU 負荷を削減
  • バックエンドへの接続再利用を実現
  • 証明書ローテーションを簡素化

トラフィック検査

  • LTM は復号化されたトラフィックを検査可能
  • コンテンツベースのルーティングルールを適用
  • Web アプリケーションファイアウォール（WAF）ルールを実装
  • アプリケーション層トラフィックをログ記録・監視
  • 悪意のあるリクエストを検出してブロック

運用の簡素化

  • 証明書更新の単一ポイント
  • サービス全体で一貫した TLS 設定
  • コンプライアンス監査が容易
  • 集中型暗号スイート管理

ただし、SSL 終端は、LTM とバックエンド間のトラフィックがデータセンター内で通常暗号化されていないことを意味します。機密性の高いアプリケーションの場合、SSL 再暗号化またはエンドツーエンド暗号化が必要になる場合があります。

グローバルサーバーロードバランシング

GSLB は、複数の地理的場所にわたってロードバランシングを拡張し、ユーザーを最適なデータセンターに誘導します。

GSLB の動作方法

レイヤー 4/7 で動作する LTM とは異なり、GSLB は通常 DNS レベルで動作します：

🌍 GSLB アーキテクチャ

DNS ベースのルーティング

  • GSLB はドメインの権威 DNS サーバーとして機能
  • クライアントは www.example.com の DNS をクエリ
  • GSLB は最適なデータセンターの IP アドレスを返す
  • クライアントは選択されたデータセンターに直接接続
  • GSLB はトラフィックフローに継続的に関与しない

ヘルスモニタリング

  • GSLB は各データセンターの健全性を監視
  • チェックは単純（ping）または複雑（アプリケーションレベル）
  • 障害データセンターは DNS レスポンスから削除
  • 健全な場所への自動フェイルオーバー
  • 回復中に段階的にトラフィックをシフト

地理的インテリジェンス

  • ソース IP からクライアントの場所を判断
  • ネットワークトポロジーに基づいて最寄りのデータセンターにルーティング
  • 地理的距離だけでなくレイテンシを考慮
  • 特定地域に対してオーバーライド可能（データ主権）
  • パフォーマンスと容量のバランスを取る

DNS ベースのアプローチは、GSLB が実際のトラフィックを処理することなくグローバル分散を提供し、大規模なスケールを可能にします。

GSLB ルーティングポリシー

異なるポリシーは異なる目的に最適化されています：

🎯 ルーティング戦略

地理的近接性

  • ユーザーを最寄りのデータセンターにルーティング
  • ほとんどのユーザーのレイテンシを最小化
  • 理解と設定が簡単
  • データセンターの負荷を考慮しない
  • 過負荷の近隣データセンターにトラフィックを送る可能性

ラウンドロビン

  • データセンター間でユーザーを均等に分散
  • グローバルに負荷を分散
  • ユーザーの場所とレイテンシを無視
  • テストまたはコスト最適化に有用
  • 遠隔データセンターのユーザーエクスペリエンスが悪い

重み付け分散

  • データセンター容量に基づいてトラフィックを割り当て
  • 異なるインフラストラクチャサイズを考慮
  • メンテナンスのためにトラフィックを段階的にシフト可能
  • 制御されたロールアウトを実現
  • 容量計画が必要

パフォーマンスベース

  • 測定されたレイテンシまたは応答時間に基づいてルーティング
  • ネットワーク状況に動的に適応
  • 最高のユーザーエクスペリエンスを提供
  • 実装と監視がより複雑
  • 継続的な測定インフラストラクチャが必要

フェイルオーバー

  • プライマリデータセンターがすべてのトラフィックを処理
  • セカンダリデータセンターはプライマリが故障した場合のみトラフィックを受信
  • 最もシンプルな災害復旧アプローチ
  • 通常運用時にセカンダリ容量を無駄にする
  • バックアップインフラストラクチャの明確なコスト最適化

多くの実装は、ポリシーを組み合わせています：地理的近接性と健全性ベースのフェイルオーバー、容量ベースの重み付けなど。

DNS TTL の課題

GSLB の DNS ベースのアプローチには、重要な制限があります：DNS キャッシング。

⚠️ DNS キャッシングの影響

Time to Live（TTL）のトレードオフ

  • 低 TTL（60-300 秒）：より速いフェイルオーバー、より高い DNS クエリ負荷
  • 高 TTL（3600+ 秒）：より低い DNS 負荷、より遅いフェイルオーバー
  • クライアントと ISP は TTL を無視してより長くキャッシュする可能性
  • 即座のトラフィックシフトの保証なし
  • 低 TTL でもフェイルオーバーに数分かかる可能性

実際の動作

  • 一部の ISP は TTL に関係なく DNS を数時間キャッシュ
  • モバイルネットワークは積極的なキャッシングを行うことが多い
  • 企業ネットワークは TTL をオーバーライドする可能性
  • ブラウザは独立して DNS をキャッシュ
  • オペレーティングシステムには独自の DNS キャッシュがある

フェイルオーバーへの影響

  • DNS ベースの GSLB では即座のフェイルオーバーを実現できない
  • 一部のユーザーは障害データセンターへの接続を続ける
  • アプリケーションレベルのリトライロジックが不可欠
  • クリティカルなサービスには Anycast または BGP ベースの代替案を検討
  • 即座の切り替えではなく、段階的なトラフィックシフトを計画

この制限により、GSLB は即座のフェイルオーバーが必要なシナリオには適していません。アプリケーションは接続障害を適切に処理し、リトライする必要があります。

LTM と GSLB の組み合わせ

最も堅牢なアーキテクチャは、両方の技術を階層的なアプローチで組み合わせます：

✅ 階層化されたトラフィック管理

GSLB 層（グローバル）

  • ユーザーを最適なデータセンターにルーティング
  • データセンターレベルの障害を処理
  • 地理的分散を提供
  • DNS レベルで動作
  • リージョン間トラフィックを管理

LTM 層（ローカル）

  • データセンター内でトラフィックを分散
  • サーバーレベルの障害を処理
  • SSL 終端を提供
  • レイヤー 4/7 で動作
  • データセンター内トラフィックを管理

組み合わせの利点

  • グローバルな回復力とローカルな最適化
  • データセンター障害が他のリージョンに影響しない
  • サーバー障害がユーザーに見えない
  • ダウンタイムなしのメンテナンス
  • リージョン間での段階的なデプロイメント

このアーキテクチャは、複数のレベルで回復力を提供します：サーバー、データセンター、リージョン。

トラフィックフローの例

階層化されたトラフィック管理を通じた典型的なリクエストフロー：

1. ユーザーが www.example.com の DNS をクエリ
2. GSLB が最寄りのデータセンターの IP を返す（例：米国西部）
3. ユーザーが米国西部データセンターの VIP に接続
4. LTM が VIP で接続を受信
5. LTM がアルゴリズムを使用して健全なバックエンドサーバーを選択
6. LTM が SSL を終端し、バックエンドに転送
7. バックエンドがリクエストを処理し、レスポンスを返す
8. LTM がレスポンスをユーザーに転送

バックエンドサーバーが故障した場合、LTM は即座に別のサーバーにルーティングします。米国西部データセンター全体が故障した場合、GSLB は最終的に新しいユーザーを米国東部にルーティングします（DNS TTL が期限切れになった後）。

本番環境インシデント：GSLB が危機を救った日

数年前、私は壊滅的なデータセンター障害の際に GSLB の価値を目撃しました。シンガポールのプライマリデータセンターが完全なネットワーク停止を経験しました。私たちのサーバーだけでなく、施設全体が接続を失いました。このインシデントは、災害復旧計画をテストし、GSLB の強みと制限の両方を明らかにしました。

障害のカスケード

停止は現地時間午前 2:47 に始まりました。監視システムはすぐに障害を検出しましたが、最初は範囲が明確ではありませんでした：

🚨 インシデントタイムライン

T+0 分：初期検出

  • シンガポールデータセンターの監視アラート
  • すべてのヘルスチェックが同時に失敗
  • GSLB が自動的にシンガポールを DNS ローテーションから削除
  • 新しい DNS クエリが東京と香港の IP を返す

T+5 分：ユーザー影響の開始

  • キャッシュされた DNS を持つユーザーがまだシンガポールに接続
  • 接続タイムアウトと障害
  • アプリケーションリトライロジックが起動
  • 一部のユーザーが他のリージョンへのフェイルオーバーに成功
  • 他のユーザーは完全なサービス中断を経験

T+15 分：段階的な回復

  • より多くのユーザーの DNS キャッシュが期限切れ
  • トラフィックが東京と香港にシフト
  • これらのデータセンターが負荷増加を経験
  • 過負荷による一部のパフォーマンス低下
  • ほとんどのユーザーが正常に接続

T+30 分：安定化

  • トラフィックの大部分が健全なデータセンターに移行
  • 積極的な DNS キャッシングによる残りの障害
  • 負荷が分散されるにつれてパフォーマンスが正常に戻る
  • シンガポールデータセンターは依然として完全にオフライン

GSLB は設計通りに正確に動作しました：障害を検出し、シンガポールをローテーションから削除しました。しかし、DNS TTL（300 秒）は、障害後もユーザーが数分間接続を試み続けることを意味しました。

うまくいったこと

階層化されたアーキテクチャはその価値を証明しました：

✅ 成功したフェイルオーバー要素

GSLB 自動検出

  • ヘルスチェックが 30 秒以内に障害を検出
  • シンガポールが即座に DNS レスポンスから削除
  • 手動介入不要
  • 新しいユーザーが自動的に健全なデータセンターにルーティング

アプリケーションリトライロジック

  • アプリケーションが失敗した接続をリトライするように設定
  • リトライが新しい DNS ルックアップをトリガー
  • ユーザーが最終的に健全なデータセンターに到達
  • 完全な障害ではなく優雅な劣化

マルチリージョン容量

  • 東京と香港に十分な容量
  • シンガポールのトラフィックを崩壊せずに処理
  • パフォーマンスは低下したが許容範囲
  • 容量計画の仮定を検証

健全なデータセンター内の LTM

  • 東京と香港の LTM が増加した負荷を分散
  • 個々のサーバーが圧倒されない
  • ヘルスモニタリングがカスケード障害を防止
  • 接続後のユーザーには透過的

GSLB がなければ、サービス全体がオフラインになっていたでしょう。残りのデータセンターに LTM がなければ、増加した負荷が個々のサーバーを圧倒していた可能性があります。

うまくいかなかったこと

インシデントは制限も明らかにしました：

⚠️ フェイルオーバーの課題

DNS キャッシング遅延

  • ほとんどのユーザーが移行するまで 5-15 分
  • 一部の ISP は 1 時間以上キャッシュ
  • モバイルネットワークが特に問題
  • 即座のキャッシュ無効化を強制する方法なし
  • ユーザーは移行期間中に障害を経験

セッション喪失

  • シンガポールのアクティブセッションが失われる
  • ユーザーが再認証する必要
  • 進行中のトランザクションが失敗
  • リージョン間セッションレプリケーションなし
  • データ整合性の課題

監視ギャップ

  • 施設全体の停止を即座に特定できず
  • 最初は自分たちのインフラストラクチャの問題だと考えた
  • 施設の問題を確認するのに 20 分かかった
  • より良い外部監視が必要
  • 施設プロバイダーとのコミュニケーションが遅延

DNS TTL の制限は特にフラストレーションでした。GSLB が数秒以内に正しく応答したにもかかわらず、制御できないキャッシングのためにユーザーは数分間失敗し続けました。

学んだ教訓

このインシデントは、いくつかのアーキテクチャ原則を強化しました：

🎯 災害復旧の洞察

DNS の制限を受け入れる

  • DNS ベースの GSLB は即座のフェイルオーバーを提供できない
  • 5-15 分の移行期間を計画
  • アプリケーションリトライロジックが不可欠
  • 真にクリティカルなサービスには Anycast を検討
  • 現実的な RTO 期待値を設定

容量計画

  • 各データセンターは N+1 容量を処理する必要
  • すべてのデータセンターが常に利用可能だと仮定しない
  • 負荷下でフェイルオーバーを定期的にテスト
  • 容量使用率を継続的に監視
  • リージョナルトラフィックスパイクを計画

セッション管理

  • ステートレスアプリケーションはクリーンにフェイルオーバー
  • ステートフルアプリケーションにはセッションレプリケーションが必要
  • 分散セッションストアを検討
  • セッション喪失シナリオのために設計
  • 優雅なセッション回復を実装

監視とコミュニケーション

  • インフラストラクチャの外部から監視
  • 施設プロバイダーとのコミュニケーションチャネルを確立
  • インシデント検出と通知を自動化
  • エスカレーション手順を文書化
  • 訓練中にコミュニケーションをテスト

シンガポールの停止は 4 時間続きました。GSLB は、初期移行期間後、ユーザーが最小限の中断を経験することを保証しました。それがなければ、サービス全体が期間中オフラインになっていたでしょう。

LTM と GSLB：並列比較

側面 LTM（ローカルトラフィックマネージャー） GSLB（グローバルサーバーロードバランシング）
範囲 単一データセンター 複数のデータセンター/リージョン
OSI 層 レイヤー 4/7（トランスポート/アプリケーション） レイヤー 3（DNS）
ルーティング決定 接続/リクエストごと DNS クエリごと
フェイルオーバー速度 即座（秒） DNS キャッシングによる遅延（分）
トラフィック処理 実際のトラフィックをプロキシ IP アドレスのみを返す
ヘルスチェック 接続レベル監視 データセンターレベル監視
ロードバランシング サーバー間分散 データセンター間分散
SSL/TLS SSL 終端可能 SSL に関与しない
セッション永続性 スティッキーセッションをサポート セッション認識なし
典型的なユースケース Web サーバー間で負荷を分散 ユーザーを最寄りのリージョンにルーティング
障害ドメイン 個々のサーバー障害 データセンター/リージョン障害
設定の複雑さ 中程度 低い（DNS ベース）
運用オーバーヘッド 高い（接続状態） 低い（ステートレス DNS）
スケーラビリティ ハードウェア容量に制限 高度にスケーラブル（DNS）

LTM と GSLB をいつ使用するか

LTM、GSLB、または両方の選択は、アーキテクチャと要件によって異なります：

🤔 意思決定フレームワーク

LTM を使用する場合：

  • 単一データセンター内で運用
  • サーバーレベルのロードバランシングが必要
  • SSL 終端が必要
  • 接続レベルのヘルスモニタリングが必要
  • 同じサービスを提供する複数のサーバーがある
  • レイヤー 7 ルーティング機能が必要

GSLB を使用する場合：

  • 複数の地理的場所で運用
  • データセンターレベルのフェイルオーバーが必要
  • ユーザーを最寄りの場所にルーティングしたい
  • データローカリティのコンプライアンス要件がある
  • リージョン間の災害復旧が必要
  • グローバルパフォーマンスを最適化したい

両方を使用する場合：

  • 複数のデータセンターでグローバルに運用
  • 各データセンターに複数のサーバーがある
  • 複数のレベルで回復力が必要
  • グローバルとローカルの両方で最適なパフォーマンスが必要
  • 高可用性要件がある
  • 運用の複雑さを正当化できる

ほとんどの大規模アプリケーションは、成長してグローバルに分散するにつれて、最終的に両方を採用します。

代替案と現代的なアプローチ

従来の LTM と GSLB は、新しい技術からの競争に直面しています：

🔄 現代的な代替案

Anycast ルーティング

  • 複数の場所から同じ IP をアナウンス
  • ネットワークルーティングがユーザーを最寄りの場所に誘導
  • 即座のフェイルオーバー（DNS キャッシング遅延なし）
  • 実装がより複雑
  • BGP とネットワークの専門知識が必要
  • CDN と DNS サービスで一般的

サービスメッシュ

  • アプリケーションレベルのロードバランシング
  • コンテナオーケストレーションと統合
  • 動的サービスディスカバリー
  • きめ細かいトラフィック制御
  • マイクロサービスアーキテクチャに適している
  • 例：Istio、Linkerd、Consul

クラウドロードバランサー

  • クラウドプロバイダーのマネージドサービス
  • クラウドインフラストラクチャと統合
  • 自動スケーリングとヘルスモニタリング
  • 運用負担が低い
  • 例：AWS ELB/ALB、Azure Load Balancer、GCP Load Balancing

オリジンフェイルオーバー付き CDN

  • CDN がグローバル分散を処理
  • 自動オリジンフェイルオーバー
  • キャッシングがオリジン負荷を削減
  • 簡素化されたアーキテクチャ
  • 例：CloudFlare、Fastly、Akamai

これらの代替案は、現代のクラウドネイティブアーキテクチャとのより良い統合を提供することが多いですが、従来の LTM/GSLB は多くのシナリオで依然として関連性があります。

運用上の考慮事項

LTM と GSLB の運用は、運用の複雑さをもたらします：

⚠️ 運用上の課題

設定管理

  • LTM と GSLB の設定を同期させる必要
  • 変更には慎重なテストが必要
  • 設定ミスが停止を引き起こす可能性
  • バージョン管理と自動化が不可欠
  • 定期的な監査が必要

ヘルスチェック設計

  • 積極的すぎる：誤検出、フラッピング
  • 寛容すぎる：障害検出が遅い
  • 実際のアプリケーション機能をテストする必要
  • 精度とオーバーヘッドのバランスを取る
  • 異なる障害モードに対する異なるチェック

容量計画

  • LTM 自体がボトルネックになる可能性
  • GSLB DNS インフラストラクチャをスケールする必要
  • N+1 冗長性を計画
  • 使用率を継続的に監視
  • ピーク負荷条件下でテスト

監視とアラート

  • LTM/GSLB の健全性をアプリケーションと別に監視
  • 異常な分散パターンを追跡
  • ヘルスチェック障害にアラート
  • DNS クエリパターンを監視
  • ベースラインメトリクスを確立

運用負担は大きいですが、高可用性とグローバル分散を必要とするアプリケーションには正当化されます。

結論

ローカルトラフィックマネージャーとグローバルサーバーロードバランシングは、現代の高可用性アーキテクチャの基盤を形成します。LTM はデータセンター内でサーバーレベルの分散を提供し、障害を透過的に処理してリソース利用を最適化します。GSLB はこれをグローバルに拡張し、場所、健全性、容量に基づいてユーザーを最適なデータセンターにルーティングします。両者を組み合わせることで、パフォーマンスと可用性を維持しながら、複数のレベルで障害に耐えられる回復力のあるシステムを構築できます。

アーキテクチャパターンは確立されています：GSLB はグローバルルーティングのために DNS レベルで動作し、LTM はローカル分散のためにレイヤー 4/7 で動作します。この階層化されたアプローチは、データセンターとサーバーの両方のレベルで回復力を提供し、ダウンタイムなしのメンテナンスと優雅な障害処理を可能にします。この組み合わせにより、アプリケーションはパフォーマンスと可用性を維持しながらグローバルにスケールできます。

しかし、両方の技術は運用の複雑さと制限をもたらします。DNS ベースの GSLB は、キャッシングのために即座のフェイルオーバーを提供できず、アプリケーションがリトライロジックを実装し、障害時の移行期間を受け入れる必要があります。LTM は、ヘルスチェック、ロードバランシングアルゴリズム、容量計画の慎重な設定が必要です。運用負担には、設定管理、監視、フェイルオーバーシナリオの定期的なテストが含まれます。

実際のインシデントは、これらの技術の価値と制限の両方を示しています。シンガポールデータセンターの停止は、GSLB がトラフィックを健全な場所に正常にルーティングしたことを示しましたが、即座のフェイルオーバーを妨げる DNS キャッシング遅延も明らかにしました。インシデントは、マルチリージョン容量計画、アプリケーションリトライロジックの重要性、そして DNS ベースのフェイルオーバーが秒ではなく分かかることを受け入れることの重要性を検証しました。

Anycast ルーティング、サービスメッシュ、クラウドロードバランサーなどの現代的な代替案は、異なるトレードオフを提供します。Anycast は DNS キャッシング遅延なしでより速いフェイルオーバーを提供します。サービスメッシュはマイクロサービスアーキテクチャとより良く統合されます。クラウドロードバランサーはマネージドサービスを通じて運用負担を削減します。しかし、従来の LTM と GSLB は、特にハイブリッドクラウドとオンプレミス環境において、多くのシナリオで依然として関連性があります。

LTM、GSLB、または両方を実装する決定は、アーキテクチャ、スケール、可用性要件に基づいて行う必要があります。単一データセンターのデプロイメントは LTM のみから恩恵を受けます。マルチリージョンのデプロイメントは地理的分散のために GSLB を必要とします。大規模なグローバルアプリケーションは通常、複数のレベルで回復力を得るために両方を必要とします。可用性要件が求める場合、運用の複雑さは正当化されますが、それほど重要でないアプリケーションには、よりシンプルな代替案で十分な場合があります。

これらの技術を実装する前に、次のことを検討してください：可用性要件は運用の複雑さを正当化しますか？チームは設定と監視の負担を管理できますか？現実的な条件下でフェイルオーバーシナリオをテストしましたか？ニーズを満たすよりシンプルな代替案はありますか？答えは、従来の LTM/GSLB、現代的な代替案、または複数の技術を組み合わせたハイブリッドアプローチを採用するかどうかを導きます。

シェア