Classic Load Balancer からの移行ガイド

Elastic Load Balancing (ELB) は、AWS クラウド上でアプリケーションの可用性とスケーラビリティを確保する上で不可欠なサービスです。現在、ELB は Application Load Balancer (ALB)、Network Load Balancer (NLB)、Gateway Load Balancer (GLB) といった現行世代のロードバランサータイプをサポートしていますが、Classic Load Balancer (CLB) は旧世代のロードバランサーと位置付けられています。

移行の必要性

Classic Load Balancer の現状

Classic Load Balancer (CLB) は、長らく多くの AWS アプリケーションの基盤として機能してきましたが、技術の進化と共に、より現代的で高機能なロードバランサーが登場しました。

CLB の特徴と制限

基本的な負荷分散: ワークロードを仮想サーバーなどの複数のコンピューティングリソースに分散
可用性と耐障害性: アプリケーションの可用性と耐障害性を高める基本機能
ヘルスチェック: 正常なターゲットにのみリクエストを送信する機能
暗号化処理: 暗号化および復号の作業をロードバランサーに任せる機能

現行世代への移行推奨

AWS は、より高度な機能、優れたパフォーマンス、および柔軟性を享受するために、既存の Classic Load Balancer を Application Load Balancer または Network Load Balancer へ移行することを強く推奨しています。

ELB の基本機能

共通する利点

動的リソース管理: コンピューティングリソースの追加や削除を、アプリケーションへのリクエストの流れを中断することなく実行
ヘルスチェック: 正常なターゲットにのみリクエストを送信するよう設定
処理の最適化: 暗号化および復号の作業をロードバランサーに任せることで、コンピューティングリソースのメインワークへの集中を促進

移行のメリット

Application Load Balancer (ALB) や Network Load Balancer (NLB) は、Classic Load Balancer と比較して、より多くの機能、優れたパフォーマンス、そして高い柔軟性を提供します。

Application Load Balancer (ALB) のメリット

高度なルーティング機能

ALB は、以下の条件に基づいてトラフィックをルーティングする高度な機能をサポートします：

パス条件: 特定の URL パス（例: /images）へのリクエストを特定のターゲットグループにルーティング
ホスト条件: 異なるホスト名（例: api.example.com と web.example.com）に基づいてトラフィックを分離
HTTP ヘッダー条件: リクエストヘッダーの内容に基づくルーティング

柔軟なルーティングとリダイレクト

URL リダイレクト: 特定の URL から別の URL へのリクエストをリダイレクト
マルチアプリケーション対応: 1つの EC2 インスタンス上の複数のアプリケーションにリクエストをルーティング
マイクロサービス対応: マイクロサービスアーキテクチャやコンテナ化されたアプリケーションに最適

高度な機能

カスタム HTTP レスポンス: ロードバランサーが直接カスタム HTTP レスポンスを返す機能
多様なターゲットタイプ: IP アドレス、AWS Lambda 関数をターゲットとして登録可能
ユーザー認証機能: 企業 ID やソーシャル ID（Google、Facebook など）を使用した認証
コンテナ統合: Amazon ECS で実行されるコンテナ化されたアプリケーションへの優れたサポート

監視とログ機能

詳細なヘルスモニタリング: 各サービスのヘルス状態を個別にモニタリング
アクセスログの強化: 追加情報を含む圧縮形式でのログ保存
パフォーマンス向上: より高いスループットと低いレイテンシーを実現

Network Load Balancer (NLB) のメリット

高性能とスケーラビリティ

NLB は、揮発性のワークロードを処理し、毎秒数百万のリクエストに対応できる能力を持ち、非常に高いパフォーマンスと極めて低いレイテンシーが求められるワークロードに最適です。

静的 IP アドレス

Elastic IP 対応: サブネットごとに 1つの Elastic IP アドレスを割り当て可能
固定 IP 要件: 固定 IP アドレスが必要なアプリケーションに最適
DNS キャッシュ対応: DNS キャッシュの問題を避けたい場合に有効

柔軟なターゲット管理

IP ターゲット: IP アドレスを指定してターゲットを登録
VPC 外対応: VPC 外のターゲットを含めることも可能
マルチアプリケーション: 1つの EC2 インスタンスで複数のアプリケーションへのルーティング

高度な統合機能

コンテナ統合: Amazon ECS コンテナ化アプリケーションへの強化された対応
詳細なヘルスモニタリング: 各サービスのヘルスを個別にモニタリング

移行プロセス

Classic Load Balancer から新しいロードバランサーへの移行には、移行ウィザードを使用する方法と手動で移行する方法の2つがあります。

移行ウィザードによる移行

概要

移行ウィザードは、既存の Classic Load Balancer の設定を使用して、同等の Application Load Balancer または Network Load Balancer を自動的に作成します。

利点

時間削減: Classic Load Balancer の移行に要する時間と労力を削減
設定継承: 既存の設定を可能な限り継承
エラー軽減: 手動設定によるエラーのリスクを軽減

重要な注意点

新規作成: 移行ウィザードは新しいロードバランサーを作成（既存の CLB を直接変換するわけではない）
手動作業: 新しく作成されたロードバランサーにトラフィックをリダイレクトする作業は手動で実行
並行運用: 移行期間中は両方のロードバランサーが並行して動作

制限事項

共通制限

名前の重複: 新しいロードバランサーの名前は、同じリージョン内の既存のロードバランサーと重複不可
タグ制限: aws: プレフィックスを含むタグは移行対象外

ALB への移行時の制限

サブネット要件: Classic Load Balancer にサブネットが1つしかない場合、ALB には少なくとも2つのアベイラビリティーゾーンが必要
ヘルスチェック変更: TCP ヘルスチェックを使用する HTTP/HTTPS リスナーがある場合、ヘルスチェックプロトコルは HTTP に、パスは「/」に更新
セキュリティポリシー: カスタムまたはサポートされていないセキュリティポリシーは、デフォルトセキュリティポリシーに置き換え

NLB への移行時の制限

旧世代インスタンス: 特定の旧世代 EC2 インスタンスタイプ（C1, CC1, CC2, CG1, CG2, CR1, CS1, G1, G2, HI1, HS1, M1, M2, M3, T1）は新しいターゲットグループに登録不可
ヘルスチェック: 一部のヘルスチェック設定は移行不可能
SSL/TLS: SSL リスナーは TLS リスナーに変換され、証明書とセキュリティポリシーを継承

移行ウィザードの実行手順

Amazon EC2 コンソールを開き、ナビゲーションペインで**[ロードバランサー]**を選択
移行させる Classic Load Balancer を選択し、**[詳細]セクションで[移行ウィザードを起動]**を選択
**[Application Load Balancer に移行]または[Network Load Balancer に移行]**を選択
新しいロードバランサー名とターゲットグループ名を入力
ターゲットインスタンスと適用されるタグを確認
概要を確認し、**[Application Load Balancer を作成]または[Network Load Balancer を作成]**を選択して移行を開始

手動移行

概要

手動移行は、より詳細な制御と段階的な移行を可能にします。AWS Management Console、AWS CLI、または AWS SDK を使用して実行できます。

ステップ1: 新しいロードバランサーの作成

基本設定

新しいロードバランサーを、Classic Load Balancer と同じ設定で作成します：

スキーム: インターネット向けまたは内部向け
サブネット: 同じサブネット構成
セキュリティグループ: 同じセキュリティグループ

ターゲットグループの設定

ヘルスチェック: Classic Load Balancer と同じヘルスチェック設定
Auto Scaling 統合: Classic Load Balancer が Auto Scaling グループに接続されている場合は新しいターゲットグループを接続
手動登録: または EC2 インスタンスを手動でターゲットグループに登録

リスナーの設定

デフォルトルール: 各リスナーにリクエストをターゲットグループに転送するデフォルトルールを設定
HTTPS 対応: HTTPS リスナーを作成する場合は AWS Certificate Manager (ACM) で提供された証明書を指定
セキュリティポリシー: デフォルトのセキュリティポリシーを使用することを推奨

タグの設定

Classic Load Balancer がタグ付けされている場合は、関連性のあるタグを新しいロードバランサーに追加します。

ステップ2: トラフィックの段階的リダイレクト

初期テスト

機能確認: 新しいロードバランサーの DNS 名をウェブブラウザで確認
動作検証: アプリケーションが適切に動作することを確認

段階的移行

DNS レコード作成: ドメイン名を新しいロードバランサーに関連付ける新しい DNS レコードを作成
重み付けルーティング: Amazon Route 53 などの DNS サービスで重み付けルーティングを設定
- 新しいロードバランサー: 重み「1」（10% のトラフィック）
- 古いロードバランサー: 重み「9」（90% のトラフィック）
監視: 新しいロードバランサーを継続的にモニタリング
段階的調整: トラフィックが適切に処理されることを確認しながら重みを調整

重要な考慮事項

TTL の影響: DNS レコードの有効期限（TTL）は 60 秒のため、変更反映に最大 60 秒かかる
両方向トラフィック: 移行期間中はトラフィックが両方のロードバランサーに流れる可能性
完全移行: すべてのトラフィックが新しいロードバランサーにリダイレクトされるまで DNS レコードの重み更新を継続

ステップ3: 古いロードバランサーの削除

削除前の確認

完全移行の確認: すべてのトラフィックが新しいロードバランサーに移行済み
既存リクエストの完了: 古いロードバランサーにルーティングされた既存のリクエストがすべて完了
DNS レコードの削除: 古いロードバランサーの DNS レコードを削除

安全な削除

上記の確認が完了した後、古い Classic Load Balancer を安全に削除できます。

移行後の更新事項

移行作業はロードバランサーの置き換えで終わりではありません。新しいロードバランサーの機能とメトリクスを活用し、既存のインフラストラクチャとの整合性を保つために、関連サービスの設定を更新する必要があります。

IAM ポリシーの更新

API バージョンの違い

Classic Load Balancer: API バージョン 2012-06-01 を使用
ALB、NLB、GLB: API バージョン 2015-12-01 を使用

更新の必要性

Elastic Load Balancing に関連する IAM ポリシーは、新しい API バージョンに対応するように更新する必要があります。これにより、適切な権限が維持され、新しいロードバランサーの管理が可能になります。

CloudWatch メトリクスの更新

名前空間の違い

Classic Load Balancer: AWS/ELB 名前空間
Application Load Balancer: AWS/ApplicationELB 名前空間
Network Load Balancer: AWS/NetworkELB 名前空間

更新対象

ロードバランサーのパフォーマンスや健全性を監視するために設定された以下の項目を更新：

CloudWatch アラーム: 新しいメトリクス名前空間を使用
ダッシュボード: 新しいメトリクスに対応
監視スクリプト: 新しいメトリクス名を使用

AWS CLI コマンドの更新

コマンドの変更

旧 API: aws elb コマンド
新 API: aws elbv2 コマンド

更新対象

AWS Command Line Interface (CLI) を使用してロードバランサーを操作するスクリプトがある場合、コマンドを更新する必要があります。

AWS CloudFormation テンプレートの更新

リソースタイプの変更

Classic Load Balancer: AWS::ElasticLoadBalancing::LoadBalancer
新しいロードバランサー: AWS::ElasticLoadBalancingV2 のリソースタイプ群

更新の範囲

テンプレート: 新しいリソースタイプを使用
パラメーター: 新しいロードバランサーのパラメーターに対応
出力: 新しいロードバランサーの出力値に対応

アプリケーションコードの更新

SDK の更新

Elastic Load Balancing API バージョン 2012-06-01 を使用しているアプリケーションコードも、バージョン 2015-12-01 を使用するように更新することが推奨されます。

更新対象

API 呼び出し: 新しい API バージョンに対応
エラーハンドリング: 新しいエラーコードに対応
レスポンス処理: 新しいレスポンス形式に対応

Classic Load Balancer の作成禁止

IAM ポリシーを活用することで、ユーザーが Classic Load Balancer を新たに作成できないように制限し、組織全体で新しいロードバランサータイプへの移行を強制することができます。

API 設計の違い

Classic Load Balancer (V1 API)

CreateLoadBalancer: ロードバランサーとリスナーを同時に作成
必須要素: 作成時に少なくとも 1つのリスナープロトコルを指定

新しいロードバランサー (V2 API)

CreateLoadBalancer: ロードバランサーのみを作成
CreateListener: リスナーを別途作成
分離設計: ロードバランサーとリスナーの作成が分離

制限ポリシーの実装

ポリシーの考え方

API 設計の違いを利用して、elasticloadbalancing:CreateLoadBalancer アクションが elasticloadbalancing:ListenerProtocol 条件キーを含む場合（つまりリスナープロトコルが指定されている場合）に、そのアクションを拒否します。

実装例

json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "elasticloadbalancing:CreateLoadBalancer",
            "Resource": "arn:aws:elasticloadbalancing:*:*:loadbalancer/*",
            "Condition": {
                "Null": {
                    "elasticloadbalancing:ListenerProtocol": false
                }
            }
        }
    ]
}

ポリシーの効果

Classic Load Balancer: 作成時にリスナープロトコルが必要なため、このポリシーによって新規作成が防止される
新しいロードバランサー: リスナープロトコルを同時に指定する必要がないため、このポリシーは影響しない

移行のベストプラクティス

事前準備

現状分析

トラフィック分析: 現在のトラフィックパターンとピーク時間の把握
依存関係の特定: 他のサービスや設定との依存関係を確認
要件の整理: 移行後に必要な機能と設定の整理

移行計画

段階的移行: 一度にすべてを移行するのではなく、段階的に実行
ロールバック計画: 問題が発生した場合のロールバック手順を準備
監視計画: 移行期間中の監視とアラート設定

移行実行

テスト環境での検証

同等環境: 本番環境と同等のテスト環境での事前検証
機能テスト: 新しいロードバランサーの機能テスト
性能テスト: パフォーマンステストの実施

本番移行

メンテナンス窓口: 適切なメンテナンス窓口での移行実行
段階的切り替え: 重み付けルーティングによる段階的切り替え
継続監視: 移行期間中の継続的な監視

移行後の最適化

新機能の活用

高度なルーティング: ALB の高度なルーティング機能の活用
ターゲットグループ: 複数のターゲットグループによる柔軟な構成
セキュリティ強化: WAF や認証機能の活用

監視とメンテナンス

メトリクス監視: 新しいメトリクスによる包括的な監視
アラート設定: 適切なアラート設定による迅速な対応
定期的な見直し: 設定の定期的な見直しと最適化

トラブルシューティング

一般的な問題と解決策

移行時の問題

ヘルスチェック失敗: ターゲットグループのヘルスチェック設定を確認
DNS 切り替え遅延: TTL 設定と DNS キャッシュの影響を考慮
セキュリティグループ: 適切なポートとプロトコルのアクセス許可

機能の問題

ルーティング問題: リスナールールとターゲットグループの設定確認
証明書問題: ACM 証明書の有効性と設定確認
パフォーマンス問題: インスタンスの容量とヘルスチェック設定の見直し

監視の問題

メトリクス取得: 新しい名前空間でのメトリクス取得確認
アラート動作: 新しいメトリクスに対応したアラートの動作確認
ログ出力: アクセスログの出力先と形式の確認

まとめ

Classic Load Balancer から Application Load Balancer または Network Load Balancer への移行は、単なる技術的なアップグレードに留まらず、アプリケーションのアーキテクチャを近代化し、将来の成長に対応するための戦略的な投資です。

移行による主要な利点

機能面での向上

高度なルーティング: より柔軟で詳細なトラフィック制御
統合機能: 他の AWS サービスとの深い統合
セキュリティ: 強化されたセキュリティ機能とコンプライアンス対応

運用面での向上

監視とログ: より詳細な監視とログ機能
自動化: 自動スケーリングとヘルスチェックの改善
管理効率: 統合された管理機能による運用効率の向上

将来への対応

スケーラビリティ: より高いスケーラビリティと性能
新機能対応: 継続的な新機能の提供
アーキテクチャの柔軟性: モダンなアーキテクチャパターンへの対応

戦略的価値

ビジネスへの影響

可用性の向上: より高い可用性とサービス継続性
コスト効率: 効率的なリソース利用によるコスト最適化
競争力強化: 最新技術による競争力の維持・向上

技術的価値

現代化: アプリケーションアーキテクチャの現代化
標準化: 業界標準に準拠した技術基盤
拡張性: 将来の要件変化への対応力

現行世代のロードバランサーが提供する豊富な機能と高いパフォーマンスを最大限に活用することで、より堅牢でスケーラブルなアプリケーションを AWS クラウド上に構築し、ビジネスの要件に柔軟に対応できるようになります。

移行は計画的に実施し、段階的なアプローチを取ることで、リスクを最小限に抑えながら、現代的なクラウドインフラストラクチャの恩恵を受けることができます。

Classic Load Balancer からの移行ガイド ​

移行の必要性 ​

Classic Load Balancer の現状 ​

CLB の特徴と制限 ​

現行世代への移行推奨 ​

ELB の基本機能 ​

共通する利点 ​

移行のメリット ​

Application Load Balancer (ALB) のメリット ​

高度なルーティング機能 ​

柔軟なルーティングとリダイレクト ​

高度な機能 ​

監視とログ機能 ​

Network Load Balancer (NLB) のメリット ​

高性能とスケーラビリティ ​

静的 IP アドレス ​

柔軟なターゲット管理 ​

高度な統合機能 ​

移行プロセス ​

移行ウィザードによる移行 ​

概要 ​

利点 ​

重要な注意点 ​

制限事項 ​

共通制限 ​

ALB への移行時の制限 ​

NLB への移行時の制限 ​

移行ウィザードの実行手順 ​

手動移行 ​

概要 ​

ステップ1: 新しいロードバランサーの作成 ​

基本設定 ​

ターゲットグループの設定 ​

リスナーの設定 ​

タグの設定 ​

ステップ2: トラフィックの段階的リダイレクト ​

初期テスト ​

段階的移行 ​

重要な考慮事項 ​

ステップ3: 古いロードバランサーの削除 ​

削除前の確認 ​

安全な削除 ​

移行後の更新事項 ​

IAM ポリシーの更新 ​

API バージョンの違い ​

更新の必要性 ​

CloudWatch メトリクスの更新 ​

名前空間の違い ​

更新対象 ​

AWS CLI コマンドの更新 ​

コマンドの変更 ​

更新対象 ​

AWS CloudFormation テンプレートの更新 ​

リソースタイプの変更 ​

更新の範囲 ​

アプリケーションコードの更新 ​

SDK の更新 ​

更新対象 ​

Classic Load Balancer の作成禁止 ​

API 設計の違い ​

Classic Load Balancer (V1 API) ​

新しいロードバランサー (V2 API) ​

制限ポリシーの実装 ​

ポリシーの考え方 ​

実装例 ​

ポリシーの効果 ​

移行のベストプラクティス ​

事前準備 ​

現状分析 ​

移行計画 ​

移行実行 ​

テスト環境での検証 ​

本番移行 ​

移行後の最適化 ​

新機能の活用 ​

監視とメンテナンス ​

トラブルシューティング ​

一般的な問題と解決策 ​

移行時の問題 ​

機能の問題 ​

Classic Load Balancer からの移行ガイド

移行の必要性

Classic Load Balancer の現状

CLB の特徴と制限

現行世代への移行推奨

ELB の基本機能

共通する利点

移行のメリット

Application Load Balancer (ALB) のメリット

高度なルーティング機能

柔軟なルーティングとリダイレクト

高度な機能

監視とログ機能

Network Load Balancer (NLB) のメリット

高性能とスケーラビリティ

静的 IP アドレス

柔軟なターゲット管理

高度な統合機能

移行プロセス

移行ウィザードによる移行

概要

利点

重要な注意点

制限事項

共通制限

ALB への移行時の制限

NLB への移行時の制限

移行ウィザードの実行手順

手動移行

概要

ステップ1: 新しいロードバランサーの作成

基本設定

ターゲットグループの設定

リスナーの設定

タグの設定

ステップ2: トラフィックの段階的リダイレクト

初期テスト

段階的移行

重要な考慮事項

ステップ3: 古いロードバランサーの削除

削除前の確認

安全な削除

移行後の更新事項

IAM ポリシーの更新

API バージョンの違い

更新の必要性

CloudWatch メトリクスの更新

名前空間の違い

更新対象

AWS CLI コマンドの更新

コマンドの変更

更新対象

AWS CloudFormation テンプレートの更新

リソースタイプの変更

更新の範囲

アプリケーションコードの更新

SDK の更新

更新対象

Classic Load Balancer の作成禁止

API 設計の違い

Classic Load Balancer (V1 API)

新しいロードバランサー (V2 API)

制限ポリシーの実装

ポリシーの考え方

実装例

ポリシーの効果

移行のベストプラクティス

事前準備

現状分析

移行計画

移行実行

テスト環境での検証

本番移行

移行後の最適化

新機能の活用

監視とメンテナンス

トラブルシューティング

一般的な問題と解決策

移行時の問題

機能の問題