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

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・サブネット構成
Subnetパ
ž あえて名前をつけると『Flat
ターン（平たいサブネット）』…とか

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. セキュリティグループ構成
Firewallパターン（階層的
ž 『Functional
アクセス制限）』と『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』に統一され、管理がしやすくなっ
た