More Related Content
Similar to クックパッドでのVPC移行について (20)
More from Sugawara Genki (20)
クックパッドでのVPC移行について
- 2. 自己紹介
菅原元気 (@sgwr_dts)
ž クックパッド(株) / インフラエンジニア
— データセンターからAWSへの移行を担当し
ました
ž OSS公開してます
— AWSツール
elasticfox-ec2tag(VPC対応済み!)、IAM Fox、
R53 Fox
— Rubyライブラリ各種
http://rubygems.org/profiles/winebarrel
- 4. クックパッドについて
ž 2,000万人以上が利
用するレシピサイト
ž 120万品以上のレシ
ピが公開されている
ž PV/月は5億PV
ž Rails+MySQL
- 5. クックパッドについて
ž すべてAWS上で運用
ž サーバ台数は400台
以上
ž インフラエンジニア
は6人
- 9. VPCのメリット
ž 非VPCにはない機能
— IPアドレスの固定
○ インスタンスをStop/StartしてもIPアドレスは
変わらない
○ 任意のIPアドレスをつけることができる
— ENI (Elastic Network Interface)
— Internal ELB
— 稼働中のインスタンスのセキュリティグ
ループが変更可能
- 13. VPC・サブネット構成
Subnetパ
ž あえて名前をつけると『Flat
ターン(平たいサブネット)』…とか
- 14. 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
- 17. VPC・サブネット構成
ž ELB用のサブネットは作らない
— 基本的にIPアドレスに依存しないようにし
ているので、ELBがどのIPアドレスを使って
も問題ない
— 10.0.*.0/17なので、ELBでIPアドレスが枯渇
することは考えにくい
— ELB用にサブネットを作ることで、アドレ
スのレンジが断片化することを懸念
- 19. ネットワーク構成
ž VPCのゲートウェイ
— サブネットのレンジの先頭(10.0.0.1、
10.0.128.1)
— VPCのRoute Tablesに従ってルーティングを行う
— インターネットとの通信にはEIPが必要
— NAPTはできない(…と思います)
ž VPCのDNS
— VPCのレンジの先頭(10.0.0.2)
○ なぜかサブネットごとにはない
— 外部のサーバのホスト名を管理
○ 内部のサーバのホスト名は保持していない
- 20. ネットワーク構成
ž 内部ゲートウェイ
— IPアドレスを(ユーザが使える)サブネッ
トのレンジの先頭に固定(10.0.0.4、
10.0.128.4)
— eth0と別にENIを差してEIPをアサイン
— IPマスカレードで他のインスタンスからイ
ンターネットへの通信を中継
- 21. ネットワーク構成
ž 内部のインスタンスの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
- 22. ネットワーク構成
ž ルート
— 同一サブネット内
→ゲートウェイを経由しない
— 隣のサブネット
→AWSのゲートウェイを経由
— インターネット
→内部ゲートウェイを経由
ž インスタンスの起動時に自身のIPアドレ
スからサブネットを判別し、Routing
Tableを設定
- 23. ネットワーク構成
ž 内部DNS
— PowerDNS+MySQL
— IPアドレスを内部ゲートウェイの隣のアド
レスに固定(10.0.0.5、10.0.128.5)
— 独自のスクリプトでNameタグとホスト名を
ひも付け
- 26. セキュリティグループ構成
Firewallパターン(階層的
ž 『Functional
アクセス制限)』と『Operational
Firewallパターン(機能別アクセス制
限)』の組み合わせ
- 28. セキュリティグループ構成
ž 『default』
— インスタンス間のICMP、全インスタンスからの
DNSへの問い合わせ、監視サーバからの全イン
スタンスへの問い合わせなどを許可
ž 『front-internet / front-elb』
— インターネット
/ ELBからproxyへのアクセスを
許可
ž 『middle』
— proxyからappへのアクセスを許可
ž 『back』
— appからDBへのアクセスを許可
- 30. ENIと内部ELBについて
ž ENI (Elastic Network Interface)
— Heartbeatとの組み合わせで冗長構成が可能
— 単一インスタンスに複数のIPを付与するこ
とも可能だが、結局APIをたたくことになる
のでENIを利用
— ダウンタイムはEIPを使った仕組みよりもか
なり短い(10〜20s)
— スプリットブレインを考える必要がない
— ただし同じセグメントに複数のNICを刺すた
め、パケットの出入りに注意が必要
- 31. ENIと内部ELBについて
ž Internal ELB
— 一部サービスで試験的に導入
— 基本的な仕組みが通常のELBと同じなので、内
部向けとしては使いにくい部分がある
○ ELB内部のインスタンスの増加によってスケール
アウトするので、ホスト名をキャッシュしたりコ
ネクションが維持されていると、帯域のスケールア
ウトが難しい
○ 接続先については同じIPアドレスを使っていても
バックエンドに均等に分散される(が重み付けは
ない)
○ 帯域のスケールアウト不要でもう少し賢い振り分
けが必要なら、冗長化したHAProxyの方が使い勝
手が良い
- 32. ENIと内部ELBについて
ž Internal ELB
— 帯域は内部のインスタンスに依存と思われる
○ アクセス量が多くなると単一のIPアドレスでも帯
域が広がる
○ ただし、ウォームアップしても直接通信するより
若干帯域が狭い
— 60秒間通信がないとコネクションが切断される
○ MySQL等の前に置く場合に注意が必要
— MySQLの前に置いた場合、TCPポートチェッ
クで接続エラーが増える
○ xinetdを使ったHTTPでのチェックの方が良い
- 42. 所感
ž IPアドレスが固定されているのがとても
ありがたい
ž 『稼働中はセキュリティグループを変更
できない』というプレッシャーがなく
なった
ž 冗長化の手段がいくつかあるので、可用
性を確保しやすくなった
ž パフォーマンスの変化は特に見られない