Embed Size (px)
Citation preview
クックパッド株式会社
インフラストラクチャー部 部長
菅原 元気
自己紹介
菅原元気 (@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台以上
インフラエンジニアは６人
クックパッドについて
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・サブネット構成
あえて名前をつけると『Flat Subnetパターン（平たいサブネット）』…とか
VPC・サブネット構成
VPC
レンジ: 10.0.0.0/16
サブネット１
レンジ: 10.0.0.0/17
ゾーン: ap-northeast-1a
サブネット２
レンジ: 10.0.128.0/17
ゾーン: ap-northeast-1b
VPC・サブネット構成
所謂『プライベートサブネット』は利用しない
同じレイヤで複数のゾーンを使いたい
○ 冗長性の確保、ではなくキャパシティの確保
○ さらに上下に分割すると２×２＝４つのサブネットが必要→管理コストの増大
セキュリティはセキュリティグループで担保
VPC・サブネット構成
サブネットは２つ
３つ以上のサブネット
→管理コストの増大を懸念
ゾーン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
セキュリティグループ構成
セキュリティグループ構成
『Functional Firewallパターン（階層的アクセス制限）』と『Operational
Firewallパターン（機能別アクセス制限）』の組み合わせ
セキュリティグループ構成
セキュリティグループは３種類
すべてのインスタンスに適用される『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』に統一され、管理がしやすくなった
