[AWS Summit 2012] クラウドデザインパターン#4 CDP VPC移行編

クックパッド株式会社

インフラストラクチャー部部長

菅原元気

自己紹介

菅原元気 (@sgwr_dts)

クックパッド(株) / インフラエンジニアデータセンターからAWSへの移行を担当しました

OSS公開してます AWSツール

elasticfox-ec2tag（VPC対応済み！）、IAM Fox、R53 Fox

Rubyライブラリ各種 http://rubygems.org/profiles/winebarrel

http://rubygems.org/profiles/winebarrel

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・サブネット構成


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


VPC

レンジ: 10.0.0.0/16

サブネット１

レンジ: 10.0.0.0/17

ゾーン: ap-northeast-1a

サブネット２

レンジ: 10.0.128.0/17

ゾーン: ap-northeast-1b


所謂『プライベートサブネット』は利用しない

同じレイヤで複数のゾーンを使いたい

○ 冗長性の確保、ではなくキャパシティの確保

○ さらに上下に分割すると２×２＝４つのサブネットが必要→管理コストの増大

セキュリティはセキュリティグループで担保


サブネットは２つ

３つ以上のサブネット

→管理コストの増大を懸念

ゾーンCができたら？できましたね…

→…あきらめます(´・ω・`)


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を刺すため、パケットの出入りに注意が必要


Internal ELB 一部サービスで試験的に導入

基本的な仕組みが通常のELBと同じなので、内部向けとしては使いにくい部分がある ○ ELB内部のインスタンスの増加によってスケールアウトするので、ホスト名をキャッシュしたりコネクションが維持されていると、帯域のスケールアウトが難しい

○ 接続先については同じIPアドレスを使っていてもバックエンドに均等に分散される（が重み付けはない）

○ 帯域のスケールアウト不要でもう少し賢い振り分けが必要なら、冗長化したHAProxyの方が使い勝手が良い


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』に統一され、管理がしやすくなった

[AWS Summit 2012] クラウドデザインパターン#4 CDP VPC移行編

Technology

Transcript of [AWS Summit 2012] クラウドデザインパターン#4 CDP VPC移行編