Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

18,764 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』に統一され、管理がしやすくなっ た

×