JAWS-UG-Kyoto-2nd

6,252 views
6,208 views

Published on

JAWS-UG Kyoto勉強会 第二回で発表した資料です。はてなブログをAWSで構築した記録、アーキテクチャなど。

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,252
On SlideShare
0
From Embeds
0
Number of Embeds
2,481
Actions
Shares
0
Downloads
24
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

JAWS-UG-Kyoto-2nd

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

×