クラウドデザインパターン#4 CDP VPC移行編 登壇者名・社名　菅原 元気（クックパッド株式会社 インフラストラクチャー部 部長）

1. クックパッド株式会社
インフラストラクチャー部 部長
菅原 元気

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. クックパッドについて
 2010年
 AWSの検証開始
 2011年8月〜10月
 データセンターからAWSに移行
 2012年8月
 VPCに移行

9. VPCのメリット
 非VPCにはない機能
 IPアドレスの固定
○ インスタンスをStop/StartしてもIPアドレスは
変わらない
○ 任意のIPアドレスをつけることができる
 ENI (Elastic Network Interface)
 Internal ELB
 稼働中のインスタンスのセキュリティグ
ループが変更可能

10. VPCのメリット
 セキュリティ
 デフォルトでインターネットと通信ができ
ない
 同じセグメントにほかのユーザがいない
 ELBへのセキュリティグループの適用

12. VPC・サブネット構成

13. VPC・サブネット構成
 あえて名前をつけると『Flat Subnetパ
ターン（平たいサブネット）』…とか

14. VPC・サブネット構成
 VPC
 レンジ: 10.0.0.0/16
 サブネット１
 レンジ: 10.0.0.0/17
 ゾーン: ap-northeast-1a
 サブネット２
 レンジ: 10.0.128.0/17
 ゾーン: ap-northeast-1b

15. VPC・サブネット構成
 所謂『プライベートサブネット』は利用
しない
 同じレイヤで複数のゾーンを使いたい
○ 冗長性の確保、ではなくキャパシティの確保
○ さらに上下に分割すると２×２＝４つのサブ
ネットが必要→管理コストの増大
 セキュリティはセキュリティグループで担保

16. VPC・サブネット構成
 サブネットは２つ
 ３つ以上のサブネット
→管理コストの増大を懸念
 ゾーンCができたら？できましたね…
→…あきらめます(´・ω・`)

17. VPC・サブネット構成
 ELB用のサブネットは作らない
 基本的にIPアドレスに依存しないようにし
ているので、ELBがどのIPアドレスを使って
も問題ない
 10.0.*.0/17なので、ELBでIPアドレスが枯渇
することは考えにくい
 ELB用にサブネットを作ることで、アドレ
スのレンジが断片化することを懸念

18. ネットワーク構成

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タグとホスト名を
ひも付け

24. ネットワーク構成
 インスタンスの初期化スクリプト実行時
に、自身の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

25. セキュリティグループ構成

26. セキュリティグループ構成
 『Functional Firewallパターン（階層的
アクセス制限）』と『Operational
Firewallパターン（機能別アクセス制
限）』の組み合わせ

27. セキュリティグループ構成
 セキュリティグループは３種類
 すべてのインスタンスに適用される
『default』
 レイヤごとに適用される『front-internet /
front-elb』『middle』『back』
 一部の特殊なインスタンスごとのロール
（例: DNS、Gateway）

28. セキュリティグループ構成
 『default』
 インスタンス間のICMP、全インスタンスからの
DNSへの問い合わせ、監視サーバからの全イン
スタンスへの問い合わせなどを許可
 『front-internet / front-elb』
 インターネット / ELBからproxyへのアクセスを
許可
 『middle』
 proxyからappへのアクセスを許可
 『back』
 appからDBへのアクセスを許可

29. セキュリティグループ構成
 サブネット間での通信制限はなし
 セキュリティグループ間の通信可能ポー
トは制限
 基本的な構成は非VPCと同じ
 ただし200近くあったセキュリティグループ
をある程度統一
 AWSの方から『VPCで一定以上のセキュリ
ティグループを作成した場合に通信が遅く
なる可能性がある』との指摘をいただいた
ため（実際遅くなるかは不明）

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でのチェックの方が良い

34. 移行手順
 移行手順はデータセンター→AWSと同様
 『Weighted Transitionパターン（重みづけラ
ウンドロビンDNSを使った移行）』の変形

35. 1. VPCにインスタンスを用意

36. 2. Proxyでの振り分けによる負荷試験

37. 3. Route53での振り分けによる動作確認

38. 4. メンテナンスでマスタDBを移行

39. 5. ドメインのIPアドレスを変更

40. 補足
 非VPCとVPCの間の通信はSSHによる
トンネル
 autosshと独自スクリプトによりデーモン化
 パケットがインターネットを通らないせい
か、非常に安定していた
 各所に内部ELBを配置していたが、パ
フォーマンスの低下が見られたため直前
に撤去

42. 所感
 IPアドレスが固定されているのがとても
ありがたい
 『稼働中はセキュリティグループを変更
できない』というプレッシャーがなく
なった
 冗長化の手段がいくつかあるので、可用
性を確保しやすくなった
 パフォーマンスの変化は特に見られない

43. 結果的なメリット
 CentOSのバージョンアップ
 全インスタンスの64bit化
 設計のリファクタリング
 セキュリティグループの見直し
 サーバ種別ごとにAMIあったが『Base
AMI+puppet』に統一され、管理がしやすく
なった