[AWS Summit 2012] クラウドデザインパターン#4 CDP VPC移行編

2,178 views
2,034 views

Published on

クラウドデザインパターン#4
CDP VPC移行編

登壇者名・社名 菅原 元気(クックパッド株式会社 インフラストラクチャー部 部長)

Published in: Technology

[AWS Summit 2012] クラウドデザインパターン#4 CDP VPC移行編

  1. 1. クックパッド株式会社インフラストラクチャー部 部長 菅原 元気
  2. 2. 自己紹介菅原元気 (@sgwr_dts) クックパッド(株) / インフラエンジニア  データセンターからAWSへの移行を担当し ました OSS公開してます  AWSツール elasticfox-ec2tag(VPC対応済み!)、IAM Fox、 R53 Fox  Rubyライブラリ各種 http://rubygems.org/profiles/winebarrel
  3. 3. クックパッドについて  2,000万人以上が利 用するレシピサイト  120万品以上のレシ ピが公開されている  PV/月は5億PV  Rails+MySQL
  4. 4. クックパッドについて  すべてAWS上で運用  サーバ台数は400台 以上  インフラエンジニア は6人
  5. 5. クックパッドについて 2010年  AWSの検証開始 2011年8月〜10月  データセンターからAWSに移行 2012年8月  VPCに移行
  6. 6. VPCのメリット 非VPCにはない機能  IPアドレスの固定 ○ インスタンスをStop/StartしてもIPアドレスは 変わらない ○ 任意のIPアドレスをつけることができる  ENI (Elastic Network Interface)  Internal ELB  稼働中のインスタンスのセキュリティグ ループが変更可能
  7. 7. VPCのメリット セキュリティ  デフォルトでインターネットと通信ができ ない  同じセグメントにほかのユーザがいない  ELBへのセキュリティグループの適用
  8. 8. VPC・サブネット構成
  9. 9. VPC・サブネット構成 あえて名前をつけると『Flat Subnetパ ターン(平たいサブネット)』…とか
  10. 10. VPC・サブネット構成 VPC  レンジ: 10.0.0.0/16 サブネット1  レンジ: 10.0.0.0/17  ゾーン: ap-northeast-1a サブネット2  レンジ: 10.0.128.0/17  ゾーン: ap-northeast-1b
  11. 11. VPC・サブネット構成 所謂『プライベートサブネット』は利用 しない  同じレイヤで複数のゾーンを使いたい ○ 冗長性の確保、ではなくキャパシティの確保 ○ さらに上下に分割すると2×2=4つのサブ ネットが必要→管理コストの増大  セキュリティはセキュリティグループで担保
  12. 12. VPC・サブネット構成 サブネットは2つ  3つ以上のサブネット →管理コストの増大を懸念  ゾーンCができたら?できましたね… →…あきらめます(´・ω・`)
  13. 13. VPC・サブネット構成 ELB用のサブネットは作らない  基本的にIPアドレスに依存しないようにし ているので、ELBがどのIPアドレスを使って も問題ない  10.0.*.0/17なので、ELBでIPアドレスが枯渇 することは考えにくい  ELB用にサブネットを作ることで、アドレ スのレンジが断片化することを懸念
  14. 14. ネットワーク構成
  15. 15. ネットワーク構成 VPCのゲートウェイ  サブネットのレンジの先頭(10.0.0.1、 10.0.128.1)  VPCのRoute Tablesに従ってルーティングを行う  インターネットとの通信にはEIPが必要  NAPTはできない(…と思います) VPCのDNS  VPCのレンジの先頭(10.0.0.2) ○ なぜかサブネットごとにはない  外部のサーバのホスト名を管理 ○ 内部のサーバのホスト名は保持していない
  16. 16. ネットワーク構成 内部ゲートウェイ  IPアドレスを(ユーザが使える)サブネッ トのレンジの先頭に固定(10.0.0.4、 10.0.128.4)  eth0と別にENIを差してEIPをアサイン  IPマスカレードで他のインスタンスからイ ンターネットへの通信を中継
  17. 17. ネットワーク構成 内部のインスタンスのRouting Table  ゾーン: ap-northeast-1b Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.169.254 * 255.255.255.255 UH 0 0 0 eth0 10.0.128.0 * 255.255.128.0 U 0 0 0 eth0 10.0.0.0 10.0.128.1 255.255.128.0 UG 0 0 0 eth0 default 10.0.128.4 0.0.0.0 UG 0 0 0 eth0
  18. 18. ネットワーク構成 ルート  同一サブネット内 →ゲートウェイを経由しない  隣のサブネット →AWSのゲートウェイを経由  インターネット →内部ゲートウェイを経由 インスタンスの起動時に自身のIPアドレ スからサブネットを判別し、Routing Tableを設定
  19. 19. ネットワーク構成 内部DNS  PowerDNS+MySQL  IPアドレスを内部ゲートウェイの隣のアド レスに固定(10.0.0.5、10.0.128.5)  独自のスクリプトでNameタグとホスト名を ひも付け
  20. 20. ネットワーク構成 インスタンスの初期化スクリプト実行時 に、自身のIPアドレスからサブネットを 判別し、resolv.confを設定 search ... options timeout:2 attempts:1 nameserver 10.0.128.5 # 自身のサブネットの内部DNS nameserver 10.0.0.5 # 隣のサブネットの内部DNS nameserver 10.0.0.2 # VPCのDNS
  21. 21. セキュリティグループ構成
  22. 22. セキュリティグループ構成 『Functional Firewallパターン(階層的 アクセス制限)』と『Operational Firewallパターン(機能別アクセス制 限)』の組み合わせ
  23. 23. セキュリティグループ構成 セキュリティグループは3種類  すべてのインスタンスに適用される 『default』  レイヤごとに適用される『front-internet / front-elb』『middle』『back』  一部の特殊なインスタンスごとのロール (例: DNS、Gateway)
  24. 24. セキュリティグループ構成 『default』  インスタンス間のICMP、全インスタンスからの DNSへの問い合わせ、監視サーバからの全イン スタンスへの問い合わせなどを許可 『front-internet / front-elb』  インターネット / ELBからproxyへのアクセスを 許可 『middle』  proxyからappへのアクセスを許可 『back』  appからDBへのアクセスを許可
  25. 25. セキュリティグループ構成 サブネット間での通信制限はなし セキュリティグループ間の通信可能ポー トは制限 基本的な構成は非VPCと同じ  ただし200近くあったセキュリティグループ をある程度統一  AWSの方から『VPCで一定以上のセキュリ ティグループを作成した場合に通信が遅く なる可能性がある』との指摘をいただいた ため(実際遅くなるかは不明)
  26. 26. ENIと内部ELBについて ENI (Elastic Network Interface)  Heartbeatとの組み合わせで冗長構成が可能  単一インスタンスに複数のIPを付与するこ とも可能だが、結局APIをたたくことになる のでENIを利用  ダウンタイムはEIPを使った仕組みよりもか なり短い(10〜20s)  スプリットブレインを考える必要がない  ただし同じセグメントに複数のNICを刺すた め、パケットの出入りに注意が必要
  27. 27. ENIと内部ELBについて Internal ELB  一部サービスで試験的に導入  基本的な仕組みが通常のELBと同じなので、内 部向けとしては使いにくい部分がある ○ ELB内部のインスタンスの増加によってスケール アウトするので、ホスト名をキャッシュしたりコ ネクションが維持されていると、帯域のスケール アウトが難しい ○ 接続先については同じIPアドレスを使っていても バックエンドに均等に分散される(が重み付けは ない) ○ 帯域のスケールアウト不要でもう少し賢い振り分 けが必要なら、冗長化したHAProxyの方が使い勝 手が良い
  28. 28. ENIと内部ELBについて Internal ELB  帯域は内部のインスタンスに依存と思われる ○ アクセス量が多くなると単一のIPアドレスでも帯 域が広がる ○ ただし、ウォームアップしても直接通信するより 若干帯域が狭い  60秒間通信がないとコネクションが切断される ○ MySQL等の前に置く場合に注意が必要  MySQLの前に置いた場合、TCPポートチェッ クで接続エラーが増える ○ xinetdを使ったHTTPでのチェックの方が良い
  29. 29. 移行手順 移行手順はデータセンター→AWSと同様  『Weighted Transitionパターン(重みづけラ ウンドロビンDNSを使った移行)』の変形
  30. 30. 1. VPCにインスタンスを用意
  31. 31. 2. Proxyでの振り分けによる負荷試験
  32. 32. 3. Route53での振り分けによる動作確認
  33. 33. 4. メンテナンスでマスタDBを移行
  34. 34. 5. ドメインのIPアドレスを変更
  35. 35. 補足 非VPCとVPCの間の通信はSSHによる トンネル  autosshと独自スクリプトによりデーモン化  パケットがインターネットを通らないせい か、非常に安定していた 各所に内部ELBを配置していたが、パ フォーマンスの低下が見られたため直前 に撤去
  36. 36. 所感 IPアドレスが固定されているのがとても ありがたい 『稼働中はセキュリティグループを変更 できない』というプレッシャーがなく なった 冗長化の手段がいくつかあるので、可用 性を確保しやすくなった パフォーマンスの変化は特に見られない
  37. 37. 結果的なメリット CentOSのバージョンアップ 全インスタンスの64bit化 設計のリファクタリング  セキュリティグループの見直し  サーバ種別ごとにAMIあったが『Base AMI+puppet』に統一され、管理がしやすく なった

×