クックパッドでのVPC移行について

18,250 views

Published on

※発表時に数字が間違っていたので訂正しました。 利用者数: 1,500万人→2,000万人

Published in: Technology

クックパッドでの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・サブネット構成 Subnetパž  あえて名前をつけると『Flat ターン(平たいサブネット)』…とか
  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. セキュリティグループ構成 Firewallパターン(階層的ž  『Functional アクセス制限)』と『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』に統一され、管理がしやすくなっ た

×