SlideShare una empresa de Scribd logo
1 de 39
Descargar para leer sin conexión
はてなブログの下側


            株式会社はてな
         渡辺 起 (id:wtatsuru)
2011/11/10 JAWS-UG - Kyoto 勉強会第2回
自己紹介
   渡辺 起 (WATANABE Tatsuru)
       システムプラットフォーム部@はてな 2011年10月入社
       AWSまわりを主に担当
       Id:wtatsuru, @tatsuru
   経歴
       福岡→東京→京都
       大学ロボコン、HPC(High Performance Computing)
   趣味:ラーメン屋巡り
       http://d.hatena.ne.jp/wtatsuru/
                                                 2
Outline
   はてなについて
   AWSでのインフラ構築
       環境構築
       サーバ・ネットワーク構成
       冗長化
       監視体制
   所感
                         3
はてなについて




          4
はてなのサービス
   はてなダイアリー
   はてなブックマーク
   人力検索はてな
   うごめもはてな
    etc.



                      5
はてなのインフラ
   iDC
       物理サーバ640台、仮想化して約2000台
       自作・ベンダー製サーバ
       SSDを多用
           例:はてブのスレーブはほぼSSD
   CentOS 5.5 / Debian 6.0
       Xen で仮想化
       プライベートクラウドっぽく運用
           コマンド一発でDomU
                                6
はてなのインフラ
   AWS
       S3
       CloudFront:CDN
       EMR / Hive:ログ解析
           社内Hadoopから移行

   既存サービスはiDCが中心
       レイテンシの問題
        → 東京リージョンで解決!
                           7
はてなブログ




http://hatenablog.com/   8
はてなブログ
   2011/11/07 招待制ベータリリース
   生まれ変わったはてなダイアリー
   はてな初のAWS上で動くサービス!




                            9
はてなブログ
   はてな初のAWS上で動くサービス!
   はてなブログの下側を中心に話します
       cf. 新はてなダイアリーの裏側 (id:onishi)
        http://www.slideshare.net/onishi/ss-9726535




                                                      10
AWSでのインフラ構築




              11
サーバ構成
   いつもの三段構成
       Proxy: nginx        proxy
       Backend: Plack
       DB: MySQL 5.5
                           backend




                             DB

                                     12
サーバ構成
   使いたいサービス
       EC2 (Elastic Computing Cloud)
       ELB (Elastic Load Balancing)
       RDS (Relational Database Service)
       VPC (Virtual Private Cloud)




                                            13
ネットワーク構成
   EC2のネットワーク
       起動時にIPアドレス割り当て (DHCP)
           グローバル+プライベート (10.0.0.0/8)
       セキュリティグループでアクセス制限
       Elastic IP (固定グローバルIPアドレス)割り当て可能
   IPアドレスベースのアプローチは使えない


                                        14
ネットワーク構成
   Elastic IP が固定IPアドレス代わりに使える?
       ほとんど代替にはならない
       EC2内からElastic IPへのアクセスはNATされて届く
           アクセス制限ができない
           AWS内のみに制限するのも困難
               Amazonの増え続けるIPアドレス帯を追えない
       外向きサービスのみに使用


                                           15
ネットワーク構成
   セキュリティグループはシンプルに
       全サーバが所属する基本グループ
           ICMP, オフィスからのSSH などを許可
       Proxy, backend, DB ロールごとに
       内部サービス用:VPN, DNS, nagios, develop




                                            16
ネットワーク構成
   DCにVPNサーバを用意
       スレーブDB等はVPN接続
   内部サービス用のインスタンスを用意
       DCからの接続はここでNAPT
       DC内への接続はポート転送


   DC → EC2: 全て通る
   EC2→内部サービス:通る
   EC2 w/VPN → DC: 全て通る
                           17
冗長化・負荷分散
   高性能
   高可用性




                      18
冗長化・負荷分散
   これまで使っていた手法を変更する必要あり                            LVS
                                                   LVS

       LVS+keepalived による負荷分散                   proxy
                                                proxy
                                               proxy
       keepalivedによる冗長化:Master DB, LVS
                                                    LVS
                                                   LVS
   動的なIPアドレス
                                                backend
                                               backend
                                              backend
       DNSに依存してしまう
                                                       LVS
   L2, L3 の制限によるもの                                   LVS

       マルチキャストが使えない
                                          master
                                          master            slave
                                                           slave
                                                          slave
       IPアドレスがつけかえられない
       (VPCでも解決しない)
                                                                    19
冗長化・負荷分散
   代替手段
       proxy
           Elastic IP, ELB
       backend
           proxyでの振り分け, HAProxy, ELB
       Master DB
           MySQL Proxy, HAProxy, RDS
       Slave DB
           同上
                                        20
冗長化・負荷分散
   Proxy
       Elastic IP のつけかえ
           Elastic IP にDNSレコードを向ける
           アクティブ側を監視、落ちたら付け替える。
           お手軽
                                       EIP
                                      Proxy   Proxy

       ELB:本命
           AWSが提供するロードバランサ。
           ヘルスチェック、AutoScaling
           複数リージョンも
                                                      21
冗長化・負荷分散
   Backend
       プロキシでの振り分け
           mod_loadbalancer (Apache), nginx


       ELB:本命
           ヘルスチェック、AutoScaling
           ELBへ直接アクセスされる可能性を考慮




                                               22
冗長化・負荷分散
   DB
       master
            master-master 相互レプリケーション
            DNSベースでのフェイルオーバ:信頼性・ダウンタイムの問題
             MySQL Multi-master on EC2 (id:stanaka)
                http://www.slideshare.net/stanaka/mysql-multimaster-on-ec2
       slave
            スレーブインスタンスを用意
            振り分けはHAProxy, MySQL Proxy を検証中
       バックアップ
            EBS Snapshot
                                                                             23
冗長化・負荷分散
   RDS
       AWSのリレーショナルデータベースサービス
       MySQL
       Multi-AZ
       定期スナップショット
       Read Replica
           振り分けは自前で行う必要有り
           MySQL Proxy, HAProxy
           パフォーマンスに若干の不安
       まさに求めていたもの
                                   24
冗長化・負荷分散
   開発段階                      EIP

                              proxy
       最小構成
       EBSインスタンス
                             backend           memcached




                    master             slave


                                                       25
冗長化・負荷分散
   いまここ                                      EIP

       Proxy                                 proxy
                                               proxy

           Elastic IP で
            Active/Standby
       Backend                              backend
                                              backend           memcached
                                                                memcached

           nginxで振り分け
       DB
           master, slave, backup
                                    master              slave
                                                        slave
           1台ずつ

                                                                       26
冗長化・負荷分散




           27
冗長化・負荷分散
   リリース予定                ELB


                 proxy
                  proxy          proxy
                                  proxy


                 ELB             ELB


               backend
                backend         backend
                                 backend




       Read Replica       RDS      Read Replica

                                                  28
インスタンス作成
   インスタンス作成はAPIのラッパを使用

       基本セットアップ、サーバ管理ツールへの登録
       AMI, セキュリティグループの設定
   Chef で構成管理
       ソフトウェアのインストール・設定



                                29
監視
   負荷状況の収集
       SNMPで収集、RRDToolで保存・可視化
       CloudWatch は使用せず
   独自のサーバ管理ツール




                                 30
監視




     31
監視
   Nagiosで監視・アラート
       EC2内に専用の監視サーバを配置
       Ping, HDD容量, httpd, レプリケーション状態など
       設定ファイルは管理用DBの情報から自動生成




                                           32
VPC
   VPCの利用を検討中
       IPアドレスを自由に決められる
           付け替えはできない
       より信頼できるVPN接続
       マルチキャスト使えない...
                              Amazon Virtual Private Cloud User Guide より
   要件                        http://docs.amazonwebservices.com/AmazonVPC/2011-07-15/UserGuide/




       複数経路→BGPを喋る必要(!)
           OSPFで経路を配る内部ネットワークとの兼ね合い
                                                                                      33
       Vyatta で検証中
所感




     34
AWSで感じたメリット
   初期投資が抑えられる
       サーバの準備が不要
       ラック空ける、サーバ一式準備
   柔軟なインフラ
       空きホストを探さなくてもいい
       簡単にスケールアップ
   国際化に対応しやすい
       複数AZで世界中から低レイテンシ
                           35
苦労している点
   パフォーマンス
       特にDBのI/O
       EBSで数百IOPS
           DCでSSD単体で4000IOPS
       高速ストレージオプションをぜひ!




                                36
苦労してます
   L2, L3での制限からくるもの
       マルチキャスト使えない→VRRP, LVSが使えない
       IPアドレスベースでの切り替えに頼り切っていた
   ELB, MSQL Proxy




                                     37
まとめ
   はてなブログをAWSでβリリースしました
   成長に伴って柔軟に対応するインフラ
   既存サービスを移すよりは楽だが、苦労も多い




                           38
ご清聴ありがとうございました。

  はてなブログをよろしくお願いいたします。




                         39

Más contenido relacionado

La actualidad más candente

OpenFlow in IaaS - Wakame
OpenFlow in IaaS - WakameOpenFlow in IaaS - Wakame
OpenFlow in IaaS - Wakame
axsh co., LTD.
 
OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...
OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...
OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...
Naoto Gohko
 
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/SpringPacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Takatoshi Matsuo
 
Whats new Apache CloudStack
Whats new Apache CloudStackWhats new Apache CloudStack
Whats new Apache CloudStack
Kimihiko Kitase
 
okuyama 勉強会 20110928
okuyama 勉強会 20110928okuyama 勉強会 20110928
okuyama 勉強会 20110928
Hiroshi Bunya
 
CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)
CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)
CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)
Satoshi Shimazaki
 

La actualidad más candente (19)

OpenFlow in IaaS - Wakame
OpenFlow in IaaS - WakameOpenFlow in IaaS - Wakame
OpenFlow in IaaS - Wakame
 
HBase at LINE
HBase at LINEHBase at LINE
HBase at LINE
 
What's new in Couchbase Server 4.0 ja
What's new in Couchbase Server 4.0 jaWhat's new in Couchbase Server 4.0 ja
What's new in Couchbase Server 4.0 ja
 
OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...
OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...
OpenStack + KVM + IPv6 = oname.com; Next Folsom/Grizzly Service development s...
 
Couchbase 101 ja
Couchbase 101 jaCouchbase 101 ja
Couchbase 101 ja
 
Crooz meet fusion io3 open
Crooz meet fusion io3 openCrooz meet fusion io3 open
Crooz meet fusion io3 open
 
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/SpringPacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
 
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoyaインフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
 
Infinispan - Open Source Data Grid
Infinispan - Open Source Data GridInfinispan - Open Source Data Grid
Infinispan - Open Source Data Grid
 
[db tech showcase Tokyo 2014] C34:[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシ...
[db tech showcase Tokyo 2014] C34:[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシ...[db tech showcase Tokyo 2014] C34:[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシ...
[db tech showcase Tokyo 2014] C34:[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシ...
 
Whats new Apache CloudStack
Whats new Apache CloudStackWhats new Apache CloudStack
Whats new Apache CloudStack
 
CloudStackとNetScaler連携tips
CloudStackとNetScaler連携tipsCloudStackとNetScaler連携tips
CloudStackとNetScaler連携tips
 
okuyama 勉強会 20110928
okuyama 勉強会 20110928okuyama 勉強会 20110928
okuyama 勉強会 20110928
 
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
 
2012 OSC Kyoto / 2012 OSC Tokyo Fall - OpenStack vps kvm
2012 OSC Kyoto / 2012 OSC Tokyo Fall - OpenStack vps kvm2012 OSC Kyoto / 2012 OSC Tokyo Fall - OpenStack vps kvm
2012 OSC Kyoto / 2012 OSC Tokyo Fall - OpenStack vps kvm
 
LAMP技術者でも無理なくツカエルWindowsAzureで運営するソーシャルアプリの裏側
LAMP技術者でも無理なくツカエルWindowsAzureで運営するソーシャルアプリの裏側LAMP技術者でも無理なくツカエルWindowsAzureで運営するソーシャルアプリの裏側
LAMP技術者でも無理なくツカエルWindowsAzureで運営するソーシャルアプリの裏側
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
 
CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)
CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)
CloudStackとNetScalerの連携(CloudStackユーザ会 in 大阪)
 
Couchbase meetup20140925
Couchbase meetup20140925Couchbase meetup20140925
Couchbase meetup20140925
 

Destacado

[AWSマイスターシリーズ] AWS Billingについて
[AWSマイスターシリーズ] AWS Billingについて[AWSマイスターシリーズ] AWS Billingについて
[AWSマイスターシリーズ] AWS Billingについて
Amazon Web Services Japan
 
セキュリティを捉えてクラウドを使うためのポイント
セキュリティを捉えてクラウドを使うためのポイントセキュリティを捉えてクラウドを使うためのポイント
セキュリティを捉えてクラウドを使うためのポイント
Yasuhiro Araki, Ph.D
 
フロントエンドフレームワークの選び方 - 20170320
フロントエンドフレームワークの選び方 - 20170320フロントエンドフレームワークの選び方 - 20170320
フロントエンドフレームワークの選び方 - 20170320
Shinichi Takahashi
 

Destacado (10)

SimpleDBを使った ソーシャルアプリ構築事例
SimpleDBを使った ソーシャルアプリ構築事例SimpleDBを使った ソーシャルアプリ構築事例
SimpleDBを使った ソーシャルアプリ構築事例
 
JAWS-UG Kyoto #02 LT
JAWS-UG Kyoto #02 LTJAWS-UG Kyoto #02 LT
JAWS-UG Kyoto #02 LT
 
AWS SDK for Java
AWS SDK for JavaAWS SDK for Java
AWS SDK for Java
 
運用でSSHログインしなければいけないのは◯◯力不足
運用でSSHログインしなければいけないのは◯◯力不足運用でSSHログインしなければいけないのは◯◯力不足
運用でSSHログインしなければいけないのは◯◯力不足
 
Why PHP is (so much) more better than Ruby?
Why PHP is (so much) more better than Ruby?Why PHP is (so much) more better than Ruby?
Why PHP is (so much) more better than Ruby?
 
【JAWS DAYS 2016】ランサーズを支えるAurora
【JAWS DAYS 2016】ランサーズを支えるAurora【JAWS DAYS 2016】ランサーズを支えるAurora
【JAWS DAYS 2016】ランサーズを支えるAurora
 
[AWSマイスターシリーズ] AWS Billingについて
[AWSマイスターシリーズ] AWS Billingについて[AWSマイスターシリーズ] AWS Billingについて
[AWSマイスターシリーズ] AWS Billingについて
 
セキュリティを捉えてクラウドを使うためのポイント
セキュリティを捉えてクラウドを使うためのポイントセキュリティを捉えてクラウドを使うためのポイント
セキュリティを捉えてクラウドを使うためのポイント
 
フロントエンドフレームワークの選び方 - 20170320
フロントエンドフレームワークの選び方 - 20170320フロントエンドフレームワークの選び方 - 20170320
フロントエンドフレームワークの選び方 - 20170320
 
AWS Black Belt Online Seminar 2017 Auto Scaling
AWS Black Belt Online Seminar 2017 Auto ScalingAWS Black Belt Online Seminar 2017 Auto Scaling
AWS Black Belt Online Seminar 2017 Auto Scaling
 

Similar a JAWS-UG-Kyoto-2nd

AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - Eコマース編 -AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - Eコマース編 -
SORACOM, INC
 
CDP キャンペーンサイト編 UPDATE
CDP キャンペーンサイト編 UPDATECDP キャンペーンサイト編 UPDATE
CDP キャンペーンサイト編 UPDATE
Hiroyasu Suzuki
 
ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ
ELB & CloudWatch & AutoScaling - AWSマイスターシリーズELB & CloudWatch & AutoScaling - AWSマイスターシリーズ
ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ
Amazon Web Services Japan
 
MySQL Multi-master on EC2
MySQL Multi-master on EC2MySQL Multi-master on EC2
MySQL Multi-master on EC2
Shinji Tanaka
 
AWSクラウドデザインパターン(CDP) - 概要編 -
AWSクラウドデザインパターン(CDP) - 概要編 - AWSクラウドデザインパターン(CDP) - 概要編 -
AWSクラウドデザインパターン(CDP) - 概要編 -
SORACOM, INC
 
2011-04-21 クラウド勉強会
2011-04-21 クラウド勉強会2011-04-21 クラウド勉強会
2011-04-21 クラウド勉強会
Koichiro Doi
 
さくらのクラウドインフラの紹介
さくらのクラウドインフラの紹介さくらのクラウドインフラの紹介
さくらのクラウドインフラの紹介
SAKURA Internet Inc.
 

Similar a JAWS-UG-Kyoto-2nd (20)

PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったことPHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったこと
 
AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - Eコマース編 -AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - Eコマース編 -
 
[AWS Summit 2012] クラウドデザインパターン#7 CDP キャンペーンサイト編 (Wordpress)
[AWS Summit 2012] クラウドデザインパターン#7 CDP キャンペーンサイト編 (Wordpress)[AWS Summit 2012] クラウドデザインパターン#7 CDP キャンペーンサイト編 (Wordpress)
[AWS Summit 2012] クラウドデザインパターン#7 CDP キャンペーンサイト編 (Wordpress)
 
CDP キャンペーンサイト編 UPDATE
CDP キャンペーンサイト編 UPDATECDP キャンペーンサイト編 UPDATE
CDP キャンペーンサイト編 UPDATE
 
ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ
ELB & CloudWatch & AutoScaling - AWSマイスターシリーズELB & CloudWatch & AutoScaling - AWSマイスターシリーズ
ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ
 
20120521 aws-meister-elb&as&cw-public
20120521 aws-meister-elb&as&cw-public20120521 aws-meister-elb&as&cw-public
20120521 aws-meister-elb&as&cw-public
 
Windows Azure 基盤を支えるテクノロジー
Windows Azure 基盤を支えるテクノロジーWindows Azure 基盤を支えるテクノロジー
Windows Azure 基盤を支えるテクノロジー
 
Windows Azure
Windows AzureWindows Azure
Windows Azure
 
[AWS Summit 2012] クラウドデザインパターン#3 CDP Eコマース編 (EC-CUBE)
[AWS Summit 2012] クラウドデザインパターン#3 CDP Eコマース編 (EC-CUBE)[AWS Summit 2012] クラウドデザインパターン#3 CDP Eコマース編 (EC-CUBE)
[AWS Summit 2012] クラウドデザインパターン#3 CDP Eコマース編 (EC-CUBE)
 
OSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUGOSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUG
 
[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編
[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編
[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編
 
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
 
PHP on Cloud
PHP on CloudPHP on Cloud
PHP on Cloud
 
MySQL Multi-master on EC2
MySQL Multi-master on EC2MySQL Multi-master on EC2
MySQL Multi-master on EC2
 
[AWS Summit 2012] クラウドデザインパターン#2 CDP 画像・動画配信編
[AWS Summit 2012] クラウドデザインパターン#2 CDP 画像・動画配信編 [AWS Summit 2012] クラウドデザインパターン#2 CDP 画像・動画配信編
[AWS Summit 2012] クラウドデザインパターン#2 CDP 画像・動画配信編
 
AWSクラウドデザインパターン(CDP) - 概要編 -
AWSクラウドデザインパターン(CDP) - 概要編 - AWSクラウドデザインパターン(CDP) - 概要編 -
AWSクラウドデザインパターン(CDP) - 概要編 -
 
2011-04-21 クラウド勉強会
2011-04-21 クラウド勉強会2011-04-21 クラウド勉強会
2011-04-21 クラウド勉強会
 
さくらのクラウドインフラの紹介
さくらのクラウドインフラの紹介さくらのクラウドインフラの紹介
さくらのクラウドインフラの紹介
 
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlCassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
 
SQL Azure のシームレスな管理
SQL Azure のシームレスな管理SQL Azure のシームレスな管理
SQL Azure のシームレスな管理
 

JAWS-UG-Kyoto-2nd

  • 1. はてなブログの下側 株式会社はてな 渡辺 起 (id:wtatsuru) 2011/11/10 JAWS-UG - Kyoto 勉強会第2回
  • 2. 自己紹介  渡辺 起 (WATANABE Tatsuru)  システムプラットフォーム部@はてな 2011年10月入社  AWSまわりを主に担当  Id:wtatsuru, @tatsuru  経歴  福岡→東京→京都  大学ロボコン、HPC(High Performance Computing)  趣味:ラーメン屋巡り  http://d.hatena.ne.jp/wtatsuru/ 2
  • 3. Outline  はてなについて  AWSでのインフラ構築  環境構築  サーバ・ネットワーク構成  冗長化  監視体制  所感 3
  • 5. はてなのサービス  はてなダイアリー  はてなブックマーク  人力検索はてな  うごめもはてな etc. 5
  • 6. はてなのインフラ  iDC  物理サーバ640台、仮想化して約2000台  自作・ベンダー製サーバ  SSDを多用  例:はてブのスレーブはほぼSSD  CentOS 5.5 / Debian 6.0  Xen で仮想化  プライベートクラウドっぽく運用  コマンド一発でDomU 6
  • 7. はてなのインフラ  AWS  S3  CloudFront:CDN  EMR / Hive:ログ解析  社内Hadoopから移行  既存サービスはiDCが中心  レイテンシの問題 → 東京リージョンで解決! 7
  • 9. はてなブログ  2011/11/07 招待制ベータリリース  生まれ変わったはてなダイアリー  はてな初のAWS上で動くサービス! 9
  • 10. はてなブログ  はてな初のAWS上で動くサービス!  はてなブログの下側を中心に話します  cf. 新はてなダイアリーの裏側 (id:onishi) http://www.slideshare.net/onishi/ss-9726535 10
  • 12. サーバ構成  いつもの三段構成  Proxy: nginx proxy  Backend: Plack  DB: MySQL 5.5 backend DB 12
  • 13. サーバ構成  使いたいサービス  EC2 (Elastic Computing Cloud)  ELB (Elastic Load Balancing)  RDS (Relational Database Service)  VPC (Virtual Private Cloud) 13
  • 14. ネットワーク構成  EC2のネットワーク  起動時にIPアドレス割り当て (DHCP)  グローバル+プライベート (10.0.0.0/8)  セキュリティグループでアクセス制限  Elastic IP (固定グローバルIPアドレス)割り当て可能  IPアドレスベースのアプローチは使えない 14
  • 15. ネットワーク構成  Elastic IP が固定IPアドレス代わりに使える?  ほとんど代替にはならない  EC2内からElastic IPへのアクセスはNATされて届く  アクセス制限ができない  AWS内のみに制限するのも困難  Amazonの増え続けるIPアドレス帯を追えない  外向きサービスのみに使用 15
  • 16. ネットワーク構成  セキュリティグループはシンプルに  全サーバが所属する基本グループ  ICMP, オフィスからのSSH などを許可  Proxy, backend, DB ロールごとに  内部サービス用:VPN, DNS, nagios, develop 16
  • 17. ネットワーク構成  DCにVPNサーバを用意  スレーブDB等はVPN接続  内部サービス用のインスタンスを用意  DCからの接続はここでNAPT  DC内への接続はポート転送  DC → EC2: 全て通る  EC2→内部サービス:通る  EC2 w/VPN → DC: 全て通る 17
  • 18. 冗長化・負荷分散  高性能  高可用性 18
  • 19. 冗長化・負荷分散  これまで使っていた手法を変更する必要あり LVS LVS  LVS+keepalived による負荷分散 proxy proxy proxy  keepalivedによる冗長化:Master DB, LVS LVS LVS  動的なIPアドレス backend backend backend  DNSに依存してしまう LVS  L2, L3 の制限によるもの LVS  マルチキャストが使えない master master slave slave slave  IPアドレスがつけかえられない  (VPCでも解決しない) 19
  • 20. 冗長化・負荷分散  代替手段  proxy  Elastic IP, ELB  backend  proxyでの振り分け, HAProxy, ELB  Master DB  MySQL Proxy, HAProxy, RDS  Slave DB  同上 20
  • 21. 冗長化・負荷分散  Proxy  Elastic IP のつけかえ  Elastic IP にDNSレコードを向ける  アクティブ側を監視、落ちたら付け替える。  お手軽 EIP Proxy Proxy  ELB:本命  AWSが提供するロードバランサ。  ヘルスチェック、AutoScaling  複数リージョンも 21
  • 22. 冗長化・負荷分散  Backend  プロキシでの振り分け  mod_loadbalancer (Apache), nginx  ELB:本命  ヘルスチェック、AutoScaling  ELBへ直接アクセスされる可能性を考慮 22
  • 23. 冗長化・負荷分散  DB  master  master-master 相互レプリケーション  DNSベースでのフェイルオーバ:信頼性・ダウンタイムの問題 MySQL Multi-master on EC2 (id:stanaka) http://www.slideshare.net/stanaka/mysql-multimaster-on-ec2  slave  スレーブインスタンスを用意  振り分けはHAProxy, MySQL Proxy を検証中  バックアップ  EBS Snapshot 23
  • 24. 冗長化・負荷分散  RDS  AWSのリレーショナルデータベースサービス  MySQL  Multi-AZ  定期スナップショット  Read Replica  振り分けは自前で行う必要有り  MySQL Proxy, HAProxy  パフォーマンスに若干の不安  まさに求めていたもの 24
  • 25. 冗長化・負荷分散  開発段階 EIP proxy  最小構成  EBSインスタンス backend memcached master slave 25
  • 26. 冗長化・負荷分散  いまここ EIP  Proxy proxy proxy  Elastic IP で Active/Standby  Backend backend backend memcached memcached  nginxで振り分け  DB  master, slave, backup master slave slave  1台ずつ 26
  • 28. 冗長化・負荷分散  リリース予定 ELB proxy proxy proxy proxy ELB ELB backend backend backend backend Read Replica RDS Read Replica 28
  • 29. インスタンス作成  インスタンス作成はAPIのラッパを使用  基本セットアップ、サーバ管理ツールへの登録  AMI, セキュリティグループの設定  Chef で構成管理  ソフトウェアのインストール・設定 29
  • 30. 監視  負荷状況の収集  SNMPで収集、RRDToolで保存・可視化  CloudWatch は使用せず  独自のサーバ管理ツール 30
  • 31. 監視 31
  • 32. 監視  Nagiosで監視・アラート  EC2内に専用の監視サーバを配置  Ping, HDD容量, httpd, レプリケーション状態など  設定ファイルは管理用DBの情報から自動生成 32
  • 33. VPC  VPCの利用を検討中  IPアドレスを自由に決められる  付け替えはできない  より信頼できるVPN接続  マルチキャスト使えない... Amazon Virtual Private Cloud User Guide より  要件 http://docs.amazonwebservices.com/AmazonVPC/2011-07-15/UserGuide/  複数経路→BGPを喋る必要(!)  OSPFで経路を配る内部ネットワークとの兼ね合い 33  Vyatta で検証中
  • 34. 所感 34
  • 35. AWSで感じたメリット  初期投資が抑えられる  サーバの準備が不要  ラック空ける、サーバ一式準備  柔軟なインフラ  空きホストを探さなくてもいい  簡単にスケールアップ  国際化に対応しやすい  複数AZで世界中から低レイテンシ 35
  • 36. 苦労している点  パフォーマンス  特にDBのI/O  EBSで数百IOPS  DCでSSD単体で4000IOPS  高速ストレージオプションをぜひ! 36
  • 37. 苦労してます  L2, L3での制限からくるもの  マルチキャスト使えない→VRRP, LVSが使えない  IPアドレスベースでの切り替えに頼り切っていた  ELB, MSQL Proxy 37
  • 38. まとめ  はてなブログをAWSでβリリースしました  成長に伴って柔軟に対応するインフラ  既存サービスを移すよりは楽だが、苦労も多い 38