クックパッドでのVPC移行について
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 14,840 views

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

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

Statistics

Views

Total Views
14,840
Views on SlideShare
14,311
Embed Views
529

Actions

Likes
84
Downloads
77
Comments
0

15 Embeds 529

http://snipsnaptmae.wordpress.com 189
http://www.sochiai.com 119
https://twitter.com 90
http://snip-snap.posterous.com 57
http://s.deeeki.com 26
http://d.hatena.ne.jp 17
https://si0.twimg.com 8
http://twitter.com 6
http://tweetedtimes.com 5
http://rssc.dokoda.jp 3
http://sochiai.com 3
http://leapf.org 2
https://www.chatwork.com 2
http://fr.twitter.com 1
http://jp.twitter.com 1
More...

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

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

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