AWS Black Belt Techシリーズ  Elastic Load Balancing (ELB)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

AWS Black Belt Techシリーズ Elastic Load Balancing (ELB)

on

  • 4,874 views

AWS Black Belt Tech Webinar 2014

AWS Black Belt Tech Webinar 2014
(旧マイスターシリーズ)

Amazon Elastic Load Balancing (ELB)

Statistics

Views

Total Views
4,874
Views on SlideShare
4,782
Embed Views
92

Actions

Likes
17
Downloads
77
Comments
0

6 Embeds 92

https://twitter.com 62
http://localhost 15
http://s.deeeki.com 5
http://local.eventdots.jp 5
http://hashtagsjp.appspot.com 3
http://dev.eventdots.jp 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

AWS Black Belt Techシリーズ Elastic Load Balancing (ELB) Presentation Transcript

  • 1. Elastic Load Balancing (ELB) AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) ソリューションアーキテクト 辻 義⼀一 放送:2014.5.07 最終更更新:2014.10.20
  • 2. ELB Updates • 2014.7 タイムアウト設定を変更更可能 • 2014.4 CloudTrail対象に追加 • 2014.3 接続のストリーミング • 2014.3 アクセスログのS3保管 • 2014.2 SSLサポート強化(Perfect Forward Secrecy(PFS)、Server Order Preference、 ELBSecurityPolicy-‐‑‒2014-‐‑‒01ポリシー追加) • 2013.11 クロスゾーン負荷分散 • 2013.10 CloudWatchのメトリック追加(BackendConnectionError、 SurgeQueueLength、SpilloverCount) • 2013.7 Proxy Protocol • 2013.5 全てのHTTPメソッド対応 • 2013.5 Route 53のフェールオーバ連携 • 2012.6 Internal ELB
  • 3. Agenda • ELBの基本 • ELBの各種機能 • ELBと各種サービスの連携 • ELB負荷試験時のTips • まとめ
  • 4. ELBの基本
  • 5. Elaastic Load Balancing (ELB) とは?  〜~ AWSクラウド上のロードバランシングサービス 〜~  ELBで実現できるシステム § スケーラブル : 複数のEC2インスタンスに負荷分散 § ⾼高い可⽤用性 : 複数のアベイラビリティゾーンにある複数のEC2インスタンス の中から正常なEC2インスタンスにのみ振り分け ELB⾃自⾝身の特徴 § スケーラブル : ELB⾃自体も負荷に応じてキャパシティを⾃自動増減 § 安価な従量量課⾦金金 : 従量量課⾦金金で利利⽤用可能 § 運⽤用管理理が楽 : マネージドサービスなので管理理が不不要 § 豊富な連携機能 : Auto Scaling, Route 53, Cloud Formation… などと連携
  • 6. ELBの使い⽅方イメージ アベイラビリティ ゾーン a ELB ユーザー マネージメント コンソール 開発・管理理者 EC2 EC2 アベイラビリティ ゾーン b myLB-xxx.elb.amazonaws.com
  • 7. 負荷分散してスケーラブルなシステムを バックエンドのEC2インスタンスのリクエスト数やコネクション数が 均等になるよう負荷分散 接続が少ない新インスタンスに 新しい接続を振り分ける 新サーバ追加! 過負荷 過負荷 対応プロトコル  L7: HTTP, HTTPS  L4: TCP, SSL
  • 8. 複数アベイラビリティゾーン(AZ)に分散 2段階で負荷分散 1) DNSラウンドロビンで各AZ内のELBに振り分け 2) 負荷が均等になるようにバックエンドのEC2に振り分け myLB-xxx.elb.amazonaws.com AZ -‐‑‒ aELB AZ -‐‑‒ b DNS ラウンドロビンで 振り分け 負荷分散
  • 9. 分散した上でヘルスチェックして⾼高い可⽤用性 • ELBは指定した設定に基づき、バックエンドの インスタンスのヘルスチェックを⾏行行う – Pingプロトコル 例例:HTTP (200番が返るのを確認) – Pingポート 例例:80番 – Pingパス(HTTP/S利利⽤用時)例例:/index.html – タイムアウト時間 例例:20秒 – ヘルスチェック間隔 例例:30秒 – 異異常判定までの回数 例例:4回 – 正常判定までの回数 例例:2回 • 正常との判定が遅いと追加したインスタンスが 使えるまでに時間がかかる。逆に異異常との判定が厳しすぎても、 過負荷時に処理理できるインスタンスを減らしてしまうことにも。
  • 10. ELB⾃自⾝身もスケーラブル ELB⾃自⾝身も負荷の増減に応じて⾃自動でスケール (キャパシティが⾃自動で増加する) [注意] ELBがスケールするときには、IPアドレスが変化します。 ELBへアクセスするときには必ずDNS名で! 独⾃自ドメインに割り当てる際はCNAMEにて。
  • 11. 安価な従量量課⾦金金 2GB → 100GB課⾦金金 1GB 49GB 49GB 98GB 2014年年10⽉月20⽇日現在 • 時間当たりの利利⽤用料料は、複数AZ配置構成でも同じ • SSLを利利⽤用しても同じ料料⾦金金 • ELBにリザーブドプランはなし • 処理理量量の課⾦金金は合計処理理量量 1GB
  • 12. ELBの各種機能
  • 13. ELBの各種機能 § ELB利利⽤用時のTips § 独⾃自ドメイン名で利利⽤用 § クライアントのIPアドレス取得 § AZとバックエンドキャパシティの関係 § ELBとバックエンドとのコネクション § SSLサポート § スティッキー セッション § 接続のストリーミング § アクセスログのS3保管 § ELB⾃自⾝身のスケーリング § VPCでの利利⽤用 § ELBとSecurity Group
  • 14. 独⾃自ドメイン名で利利⽤用 CNAMEを利利⽤用して実現 • 独⾃自ドメインの権威DNSサーバに設定すれば完了了  www.example.com CNAME myLB-‐‑‒xxxx.ap-‐‑‒northeast-‐‑‒1.elb.amazonaws.com • Zone Apex (www.exapmple.com ではなく example.com を指定) の場合 à 通常のDNSサーバではCNAME設定不不可 à Route 53のエイリアスレコードを 使うことで実現可能
  • 15. クライアントのIPアドレス取得 バックエンドサーバへの接続は、 ソースIPアドレスがELBのIPアドレスとなる – クライアント⇔ELB, ELB⇔バックエンドの接続はそれぞれ独⽴立立しているため – アクセスログにはELBのIPアドレスが記録される à HTTP/HTTPSならHTTPヘッダ上のX-‐‑‒Forwarded-‐‑‒Forで参照可 利利⽤用例例: -‐‑‒ アクセスログにクライアントのIPアドレスを記録 -‐‑‒ IPアドレスによるアクセス制限  送信元経由するルート X-‐‑‒Forwarded-‐‑‒For: 203.0.113.7, 10.12.33.44, 10.12.23.88 Client IP address 
  • 16. AZとバックエンドキャパシティの関係 良良くない例例:AZ間でキャパシティが不不均等 2 AZ-‐‑‒b3 New 2013.11 AZ-‐‑‒a 50% 50% もう⼀一⽅方より 負荷が⾼高くなる クロスゾーン負荷分散が有効であれば 50% 50% 台 台 2台 AZ-‐‑‒a 負荷を基に 均等に 3 台 AZ-‐‑‒b• リージョン内の複数AZに負荷分散可能 – 複数リージョンへの分散にはRoute 53を併⽤用できる • 各EC2インスタンスのタイプは同じに • AZごとのEC2インスタンス数はできれば均等に – クロスゾーン負荷分散でAZ間を越えて負荷を均等にできる
  • 17. ELBとバックエンドとのコネクション • クライアント ⇔ ELB のコネクション – 無通信状態が続くとそのコネクションを切切断する • ELB ⇔ バックエンドのEC2インスタンス のコネクション – EC2インスタンス上のApache等ではHTTP Keepalive設定を推奨 – Webサーバのタイムアウト値をELBのアイドルコネクションタイムアウトよ り⻑⾧長い時間に設定することを推奨 接続を維持できない場合、ELBがそのEC2インスタンスを異異常と判定し、 トラフィックを送らなくなることがあるので注意 • タイムアウトは60秒がデフォルト値で、1秒から60分までに変更更可能 クライアント ⇔ ELBELB ⇔ バックエンドのEC2インスタンス  New 2014.7
  • 18. ELB⾃自⾝身のスケーリング ELBは負荷に応じて⾃自動でスケールする • 但し、ELBへの接続・リクエストが瞬間的に急増したために、ELBのス ケーリングが間に合わない場合、HTTP 503を返す – 新サービス開始 – TVやメディアによるサービス紹介 – 負荷テスト 等  • 回避⽅方法は事前にELBをスケールさせておく – 負荷を段階的にかける – Pre-‐‑‒Warming(暖気運転)の申請を⾏行行う ※Business/Enterpriseサポート要
  • 19. VPCでの利利⽤用 • ELBを配置するサブネットをAZごとに1つ指定 サブネットは最⼩小 /27 CIDRブロックで、20個以上の空きIPが必要 • EC2 Classicに設置する場合と⽐比べた制約:IPv6サポートなし (2014年年4⽉月時点) myLB-xxx.elb.amazonaws.com AZ -‐‑‒ a AZ -‐‑‒ b ELBサブネット Webサブネット
  • 20. Internet-‐‑‒Facing ELB / Internal ELB § Internet-‐‑‒Facing ELB インターネットからアクセスできるELB – 名前解決するとグローバルIP  § Internal ELB VPC内やオンプレミス環境からのみ アクセスできればよいELB プライベートサブネットにも配置できる。 – 名前解決するとプライベートIP Internet-Facing ELB Webサーバ Internal ELB APサーバ
  • 21. ELBとSecurity Group • EC2 ClassicのSecurity Groupは”amazon-‐‑‒elb/amazon-‐‑‒elb-‐‑‒sg”、 VPCではELBに任意のSecurity Groupを指定可能 • ICMP Echo Request/Replyを許可 すれば、ELBがpingにも応答 • バックエンドのEC2インスタンスは ELBからのみリクエストを 受け付ける設定を推奨 443 sg-‐‑‒EC2 80: sg-‐‑‒ELB 22:10.0.0.0/24 80 80 80 sg-‐‑‒ELB80 443: 0.0.0.0/0 22
  • 22. ELBの各種機能 § ELB利利⽤用時のTips § 独⾃自ドメイン名で利利⽤用 § クライアントのIPアドレス取得 § AZとバックエンドキャパシティの関係 § ELBとバックエンドとのコネクション § SSLサポート § スティッキー セッション § 接続のストリーミング § アクセスログのS3保管 § ELB⾃自⾝身のスケーリング § VPCでの利利⽤用 § ELBとSecurity Group
  • 23. SSLサポート ELBでSSL Terminationできる a) ELBでSSL Terminationし、バックエンドとはSSLなし バックエンドのEC2インスタンスでSSL処理理せずに済むため 負荷をオフロードできる。 b) ELBでSSL Terminationし、バックエンドとは別途SSL c) SSLをバイパスしてバックエンドにTCPで送信 クライアント証明書認証などを利利⽤用するためにはTCPとして扱う a) HTTPS HTTP b) HTTPS / SSL HTTPS / SSL c) TCP TCP
  • 24. HTTPS/SSL利利⽤用時のサーバ証明書 ELBにサーバ証明書をアップロード • HTTPS/SSL利利⽤用にはサーバ証明書のアップロードが必須 • 複数ホスト名には別名・ワイルドカードか複数ELBで対応(SNI未対応) • バックエンドとの通信にSSLを⽤用いないなら証明書の管理理が容易易 • マネージメントコンソール or CLI or IAM APIで設定 SSL証明書のライセンスに関し ては、サーバ単位/ドメイン単位 で発⾏行行などそれぞれ異異なるので 発⾏行行元に問い合わせの事 サーバ証明書
  • 25. SSLのセキュリティ強化 • TLS 1.1, 1.2のサポート • Perfect Forward Secrecy (PFS) のサポート New 2014.2 • Server Order Preference New 2014.2 • 新しい定義済みのセキュリティポリシー New 2014.2 新しく作ったELBではELBSecurity-‐‑‒Policy-‐‑‒2014-‐‑‒01がデフォルト à 既存のELBには互換性確認の上 ELBSecurity-‐‑‒Policy-‐‑‒2014-‐‑‒01 の適⽤用を
  • 26. バックエンドインスタンスのサーバ証明書認証 ELBとバックエンドのEC2インスタンス間でHTTPS/SSL使⽤用時に、 特定の証明書を使⽤用しているかどうかバックエンドを認証
  • 27. ELBの各種機能 § ELB利利⽤用時のTips § 独⾃自ドメイン名で利利⽤用 § クライアントのIPアドレス取得 § AZとバックエンドキャパシティの関係 § ELBとバックエンドとのコネクション § SSLサポート § スティッキー セッション § 接続のストリーミング § アクセスログのS3保管 § ELB⾃自⾝身のスケーリング § VPCでの利利⽤用 § ELBとSecurity Group
  • 28. スティッキー セッション (stickness) 同じユーザから来たリクエストを全て同じEC2インスタンスに送信 • デフォルトで無効、使うには有効に • アプリケーションでのセッション情報、⼀一時ファイルなどを EC2インスタンスが保持する構成の場合に必要となる。 • HTTP/HTTPSでのみ利利⽤用可能 • ELBは独⾃自のセッションCookieを挿⼊入 EC2インスタンスの増減を柔軟にできるように、 セッション情報などは別のDBサーバやキャッ シュサーバに持たせるのが望ましい。 この場合スティッキー セッションは不不要。
  • 29. スティッキー セッションの有効期間 有効期間の制御⽅方法は以下2パターン § Application Generated Cookie Stickiness(アプリケーション制御) アプリケーションが作成したCookieにあわせる – アプリケーションが作成するCookie名を指定 – Cookieの有効パスもあわせる  § Load Balancer Generated Cookie Stickiness(期間ベース) セッション開始からの有効期間を指定してELBで制御 – 秒単位で指定 – 無期限にする事も可(無期限でもブラウザを閉じれば終了了)
  • 30. ELBの各種機能 § ELB利利⽤用時のTips § 独⾃自ドメイン名で利利⽤用 § クライアントのIPアドレス取得 § AZとバックエンドキャパシティの関係 § ELBとバックエンドとのコネクション § SSLサポート § スティッキー セッション § 接続のストリーミング § アクセスログのS3保管 § ELB⾃自⾝身のスケーリング § VPCでの利利⽤用 § ELBとSecurity Group
  • 31. 接続のストリーミング (Connection Draining)New 2014.3 バックエンドのEC2インスタンスをELBから登録解除したり、ヘルスチェッ クが失敗した時に、新規割り振りは中⽌止して、処理理中のリクエストは終わる まで⼀一定期間待つ。  • 新しく作成したELBではデフォルトで有効、タイムアウト 300秒。 • タイムアウト最⼤大 3600秒 • 接続のストリーミング動作中 – Management Consoleではインスタンスの表⽰示が消える – API/SDK/CLIでは状況がわかる  (2014.5時点)
  • 32. 登録解除時のAWS CLIでの表⽰示 $ aws elb describe-instance-health --load-balancer-name (ELB Name) { "InstanceStates": [ { "InstanceId": "i-XXXXXXXX", "ReasonCode": "N/A", "State": "InService", "Description": “N/A” } ] } State Description 正常時 InService N/A 接続のストリーミング 動作中 InService Instance deregistration currently in progress. 全接続終了後 or タイムアウト後 OutOfService Instance is not currently registered with the LoadBalancer.
  • 33. ELBの各種機能 § ELB利利⽤用時のTips § 独⾃自ドメイン名で利利⽤用 § クライアントのIPアドレス取得 § AZとバックエンドキャパシティの関係 § ELBとバックエンドとのコネクション § SSLサポート § スティッキー セッション § 接続のストリーミング § アクセスログのS3保管 § ELB⾃自⾝身のスケーリング § VPCでの利利⽤用 § ELBとSecurity Group
  • 34. アクセスログのS3保管New 2014.3 ELBのアクセスログを指定したS3に⾃自動保管 • 簡単にログのS3保管が実現できる • ELBだからこそ記録できる項⽬目 – ELBの応答コード – ELBでの処理理時間 – クライアントのIPアドレス • Apache/Nginxでは標準だがELBのログに含まれていない項⽬目 – リファラ – ユーザエージェント (2014.10時点)
  • 35. ELBと各種サービスの連携
  • 36. CloudWatchとの連携 CloudWatchによりELBの以下を1分単位で監視可能 • 正常なバックエンドのホスト数 (HealthyHostCount) • 異異常なバックエンドのホスト数 (UnHealthyHostCount) • リクエスト数 (RequestCount) 遅延時間  監視 • (Lantency)• ELBが返した4xx,5xxのレスポンス数 (HTTPCode_̲ELB_̲4xx) • バックエンドが返した2xx,3xx,4xx,5xxレスポンス数 (HTTPCode_̲Backend_̲2xxx) • バックエンドへの接続エラー回数 (BackendConnectionError) New 2013.10 • バックエンドへの送信保留留中の件数 (SurgeQueueLength) New 2013.10 • キュー溢れのため拒否した件数 (SpilloverCount) New 2013.10 計13項⽬目
  • 37. Auto Scalingとの連携 • Auto Scalingによるインスタンス増減時にELBへの追加・削除が可能 • ELBのヘルスチェックの結果をAuto Scalingに反映可能 • インスタンス削減時は、接続のストリーミングでの処理理中の接続を待つ  利利⽤用例例 – ⼀一定間隔でレスポンスをチェックし、遅延が増加したらインスタンスを⾃自動追加 – ELBのヘルスチェックが成功したEC2インスタンスを常にX台以上 増減 Auto scaling Group New 2014.3
  • 38. Route 53 DNSフェイルオーバ対応 Route 53のヘルスチェック機能とELBが連携  例例:アプリケーション障害時にSorryページヘ誘導 正常時フェイルオーバ時 S3 Bucket 3. ELB配下に正常なEC2 インスタンスなし  2. AppサーバのELB ヘルスチェック失敗  1. DBに問題発⽣生 4. フェイルオーバ  5. Sorry ページ
  • 39. OpsWorksのELB対応 OpsWorksでELBをLBレイヤーに利利⽤用可能に UserAWS Management Console   Load Balancerレイヤー   App Serverレイヤー  Databaseレイヤー  レシピ レシピ レシピ D B Web /App Web /App LB ①スタックの作成 ②レイヤーの作成 ③レシピの作成・設定 (ビルトイン レシピ利利⽤用可) ④レイヤーにインスタ ンス追加・起動 ⑤レシピによって パッケージインス  トール、設定 スタックLBとしてELBが選択可能に
  • 40. ELB負荷テストに関するTips
  • 41. ELBを負荷テストする必要性について ELBのいくつかの特⻑⾧長がテストシナリオに影響を与える可能性がある。 • ELBのスケーリング • ELBの初期キャパシティ • アイドル時のコネクションタイムアウト • バックエンドインスタンスのヘルスチェック • Stickyセッション 等  ご利利⽤用内容に合わせたシナリオでテストが必要
  • 42. ELBの負荷テスト⽅方法の種類 § シングルクライアントテスト 例例:Apache Bench(ab)  § マルチクライアントテスト 例例:curl-‐‑‒loader  (都度度DNS解決を⾏行行うツールが望ましい)  § 分散テスト 例例:Fabricフレームワーク、 BeesWithMachineGuns 負荷⽣生成 クライアント バックエンド インスタンス  クライアントの負荷が⾜足りない場合はクライアント数を増やす等で対応可
  • 43. 推奨テストアプローチ • 想定する最⼤大負荷のテスト • 通常のトラフィック時のテスト – トラフィックの多い時 – トラフィックの少ない時 – トラフィックの傾向に変化がある時(朝や昼の時間帯など) • 短い時間でトラフィックが⼤大きく変化する場合のテスト ELB以外にも負荷⽣生成クライアント、バックエンドEC2インスタンスも 監視すべき – アプリケーション内部の動作も要確認 – どこかボトルネックになっているか把握しておく 時間 負荷 
  • 44. 負荷テストの注意事項 • ELBの初期スケールに注意 – スケールするまでに、HTTP 503レスポンスを返す期間があり得る – 回避策: • ELBの暖気運転( Pre-‐‑‒Warming)申請をする • 5分間隔で50%以上のトラフィック増加をしないよう負荷テストを設定 • DNSクエリの仕⽅方に注意 – テストクライアント側で少なくとも1分に1回DNSの再解決をする • スティッキーセッション利利⽤用時の割り振り⽅方 – 同じCookieでリクエストを続けた場合などは振り分けに偏りが • バックエンドインスタンスのアイドルタイムアウト – 60秒以上に設定しないとELBが誤って不不健全なホストと⾒見見なす可能性あり
  • 45. まとめ
  • 46. まとめ 〜~ELBはAWSが提供するロードバランシングサービス〜~ § 運⽤用管理理コストを抑えながら スケーラブルで⾼高可⽤用なインフラを構築可能 § 各種サービスとの連携もスムーズ&随時拡充 § 負荷試験時はその特性を理理解した上で § 急激な負荷の増⼤大が想定される場合には、 サポート加⼊入の上で暖気申請(Pre-‐‑‒Warming)を
  • 47. 参考資料料(⽇日本語) • Elastic Load Balancing開発者ガイド http://docs.aws.amazon.com/ja_̲jp/ElasticLoadBalancing/latest/DeveloperGuide/Welcome.html  • Elasitc Load Balancingを評価するための ベストプラクティス http://d36cz9buwru1tt.cloudfront.net/jp/documentation/BestPracticesInEvaluatingELB-‐‑‒ja-‐‑‒final.pdf • Amazon ELB FAQ http://aws.amazon.com/jp/ec2/faqs/ (ELBの項⽬目) 
  • 48. 参考資料料(英語) • Amazon Elastic Load Balancing Developer Guide http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/Welcome.html  • Best Practices in Evaluating Elastic Load Balancing http://aws.amazon.com/articles/1636185810492479  • Amazon ELB FAQ http://aws.amazon.com/ec2/faqs/(ELBの箇所)  • AWS CLI – ELB http://docs.aws.amazon.com/cli/latest/reference/elb/  • [AWS re:Invent 2012] CPN 205: Zero to Millions of Requests https://www.youtube.com/watch?v=xKF-‐‑‒Aawz9oc
  • 49. Appendix
  • 50. ELBヘルスチェックの詳細 インスタンスが正常とみなされるまで • ヘルスチェックの間隔が20秒で、ヘルスチェックの成功判定回数の閾値 が3回の場合、正常と⾒見見なされるまでに60秒かかる ヘルスチェックの成功判定回数の閾値を少なくすることで、オンライン化 を早めることが可能 20秒 20秒 20秒 成功判定 1回目 成功判定 2回目 成功判定 3回目→オンライン ELBにEC2イン スタンスを登録
  • 51. ELBヘルスチェックの詳細 インスタンスが異異常とみなされるまで • ヘルスチェックの間隔が20秒で、ヘルスチェックの失敗判定回数の閾値が4回の 場合、異異常と⾒見見なされるまでに80秒かかる   20秒 20秒 20秒 失敗判定 1回目 失敗判定 2回目 失敗判定 3回目 失敗判定 4回目→オンライン 20秒 EC2インスタンスのステータスがrunning→terminateの場合 • EC2インスタンスがterminateされたことをELBが検知すると、すぐにEC2イン スタンスへはトラフィックを送らなくなる • ELBがterminateを検知するまでに、遅延が発⽣生する場合があるので、EC2 イン スタンスをde-‐‑‒registerしてからterminateすることを推奨
  • 52. Default VPC/Internal ELB制約⼀一覧まとめ プラットフォーム (2014年年10⽉月20⽇日時点) EC2-Classic EC2-VPC Internet-facing ELB Internal ELB Internet-facing ELB Internal ELB IPv6対応○ 作成不不可 ×× Dedicated Instance対応○×× Security Group設定×○○ Internet Gateway定義ー必須不不要 ELBの配置 必須 Subnet定義ー (Default VPCでは 任意) 必須 (Default VPCでは 任意)
  • 53. ELBにおけるサーバ証明書の扱いについて ELBにサーバ証明書をアップロード可能 パターン1: ELBに証明書をアップロード • 証明書の管理理が容易易 • IAMを使ってアップロード パターン2: バックエンドインスタンスに証明書を アップロード 証明書 証明書 証明書 • 証明書の管理理が⾯面倒 • 各インスタンスに証明書をアッ プロード 証明書 ※証明書のライセンスに関しては、ドメイン単位/サーバ単位で発⾏行行など それぞれ異異なるので発⾏行行元に問い合わせの事
  • 54. ELBからS3にRoute 53でフェイルオーバ設定 (1/3) 1) まずELBを指すレコードを作成する。 ELB, S3などIPアドレス 以外を対象にするには、 AliasをYesに Alias Targetの候補 として、⾃自動的に ELB, S3などが表⽰示 されるのでELBを指 定する。
  • 55. ELBからS3にRoute 53でフェイルオーバ設定 (2/3) 2) Routing Policyを「Failover」にして、設定します。 Active / Standby形式で、 フェイルーバさせたい事 を指定 通常時のレコードである ことを「Primary」と設定 して指定 正常かに基いてFailoverさ せるため「Yes」を指定 ELBの機能と連携できるため、 Route53のヘルスチェックは不不 要なため「No」を指定
  • 56. ELBからS3にRoute 53でフェイルオーバ設定 (3/3) 3) 2個⽬目のレコードを同じNameでS3を指定するレコードを作成し、Secondaryとして設定します。 Active / Standby形式で、 フェイルーバさせたい事 を指定 切切替先のレコードである ことを「Secondary」と 設定して指定