Recommended
More Related Content
What's hot
What's hot (20)
Similar to アメーバブログを支えるデータセンターとインフラ技術
Similar to アメーバブログを支えるデータセンターとインフラ技術 (20)
Recently uploaded
Recently uploaded (9)
アメーバブログを支えるデータセンターとインフラ技術
- 1. アメーバブログを支える データセンターとインフラ技術 2016 September 16 CyberAgent, Inc. All Rights Reserved レガシーなインフラからOpenStack移行の舞台裏
- 3. 平野 智洋 株式会社サイバーエージェント 技術本部 サービスファシリティーグループ(SFG) ハードウェア・ストレージ ワーキンググループ （自称 ハードウェアブローカー） 業務 ハードウェア/ストレージの検証・選定 ファシリティ設計・機器設置・配線・構築 システム開発・運用設計・トラブルシュート など サイバーエージェント歴12年
- 4. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 5. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 6. ▼１万人以上の芸人・有名人が利用している国内最大ブログサービス ▶ 会員数が5,300万人突破 ▶ 2004年からスタート ※2016/8月時点 Ameba全体での会員数 ▶ 日本最大規模のブログサービス このサービスをOpenstackに移行したお話
- 7. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 8. 従来のアメーバブログが抱えた問題・・・ - 機器の老朽化と保守切れ→突然の故障→積み重なる屍の山 - 設置スペース不足 - 電力不足 - 手順が複雑で時間の掛かるサーバ構築 - 衝突するIPアドレス - 担当者不明の謎サーバ - 重たいNetwork - アンバランスなストレージ ・・・などなど
- 10. プライベートクラウドの核となる３本の矢の導入 ストレージ改革 NW改革 サーバ改革 ▶ KVMホストのHDDストレージ ▶ iSCSI接続のHDDストレージ ▶ iSCSI接続のNVMeストレージ ▶ サーバリンク1G → 10G x2 20G化 ▶ L3DSRによる効率化 ▶ Ironicによる仮想/物理の一元管理 ▶ 豊富なインスタンス・ラックの高集約化
- 11. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 13. 作りやすく、捨てやすい サーバリソース Novaリソース500台 (物理コア20,000個) Ironicベアメタル(物理サーバ)150台 高速NVMe Cinderリソース 120TB, 大容量HDD Cinderリソース 360TB Glance Imageリソース 100TB, Swift Objectリソース 1.3PB OpenStackの採用
- 14. 高集約化：Nova Compute Node ラック構成 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server 1U Server TOR SW TOR SW Leaf SW Leaf SW Node Node Manage SW Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node Node 【従来構成】 1ラック最大 6KVA 1Uサーバ24台 1Gbps Network 物理192コア 【Compute Nodeラック】 1ラック最大 定格 15KVA 実効 10KVA →実測値 6-7KVA 1/2Uサーバ最大48台 10Gbps構成 物理1,920コア マルチノードタイプを採用！ 同等の電力で容積効率 10倍
- 15. Nova Compute Keystone Authorize Openstack -Kilo- コンポーネント Cinder Block Storage Designate DNS Newtron Networking Glance Image Horizon Dashboard Ironic Bare Metal Swift Object
- 16. Nova Compute Keystone Authorize Openstack -Kilo- コンポーネント Cinder Block Storage Designate DNS Newtron Networking Glance Image Horizon Dashboard Ironic Bare Metal Swift Object
- 18. 2種類のCinderサービス Virtual Machine Cinder Gateway Virtual Machine Virtual Machine Virtual Machine ・・・・ Cinder Storage Cinder Storage HDD HDD MIRROR Cinder NVMe NVMe NVMe NVMe NVMe NVMe NVMe Cinder Gateway Cinder Storage Cinder Storage HDD HDD MIRROR Cinder NVMe NVMe NVMe NVMe NVMe NVMe NVMe 1クラスタ4台構成 x32 合計320TB 1台 6NVMe x12台 合計120TB
- 19. Cinderサービスのスペック Cinder-HDD - 物理 640TB, 実効 320TB 2Mirror - 1ボリューム最大 2TB - 合計最大 640ボリューム - 合計最大 1,000,000 IOPS / 6,400Mbps (ベストエフォート) Cinder-NVMe - 物理 120TB, 実効 120TB - 1ボリューム最大 1.4TB - 1ボリュームあたり10,000 IOPS保証 / 800Mbps保証 （RAID10のHDD比較で約５倍の性能を保証！） - 冗長なし！
- 20. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 21. 導入前の検証で… ストレージ改革 NW改革 サーバ改革 ▶ KVMホストのHDDストレージ ▶ iSCSI接続のHDDストレージ ▶ iSCSI接続のNVMeストレージ ▶ サーバリンク1G → 10G化 ▶ L3DSRによる帯域効率化 ▶ Ironicによる仮想/物理の一元管理 ▶ 豊富なインスタンス・ラックの高集約化 帯域が10Gフルにでない ストレージのIOが遅い CPU利用に偏りが出る
- 24. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 25. □ Openstackの監視問題 突貫工事でリリースしたが、Designate・Neutron・MQ・Ironicまわりでトラブルが頻発。 各コンポーネントの監視が行き届いておらず、ユーザからの問い合わせベースで障害に気づく状況。 → 現在はほぼ監視を設定したが、さいしょから、ちゃんと監視しましょう。 □ CPU世代間のマイグレーションができない問題 E5-2600 V2のCPUで構築したが、生産終了のためV3, V4のCPUでテストを実施したが… → 仮想サーバのマイグレーションが出来ない問題が発覚。もう古いCPUも買えないしどうしよう □ Ironicの運用問題 運用開始当時は、サーバの種類は4種類くらいしか無かったが、現在は20種類を超える。 新構成の機器を導入するたび、OSのリリース(CentOS7.1→7.2)のたびに、OS Imageの作り込みが必要。 □ 20Gbpsでも足りない問題 当時、Cinder-NMVeでは最強のストレージデバイスを選択したが、半年くらい後に選択できる容量が倍増し、 速度も向上。最新のNVMeデバイスを検証したが、帯域を40Gbpsにしても足りない。 移行後に困ったこと
- 26. 本日のアジェンダ ① アメーバブログって？？？ ② 移行前に考えてたこと ③ 構成 ④ 移行前に困ったこと ⑤ 移行後に困ったこと ⑥ これから作るなら気に掛けるべきこと
- 27. □ 10Gはオワコン 設計当初は、1サーバ40コア程度だったが、今はより多くのコアを搭載できる。コンピューティング能力があがれば、 流れるトラフィックも増えてくるので、今後は25G/50G/100Gで作ったほうが良い。 □ Openstackを理解しよう ”誰でもかんたんに、開発いらずでクラウドを作れちゃうよ☆” ↑コレは嘘です ドキュメントが嘘だったり、ドキュメントに書いてない裏設定が実装されていたり。 各コンポーネントは密結合でバグだらけ、Ironicは地雷だったり・・ リリースサイクルが早すぎで、去年のオプスタは今のオプスタじゃなさ過ぎるという理不尽さ。 不具合を埋めつつ独自patchをあてて運用をするしかないので、コードの読み書きは必須だしそれなりの覚悟が必要。 □ チューニング指南書を理解しよう RedHatさんが “Virtualization Tuning and Optimization Guide” という、とても有意なドキュメントを 公開しています。”困ったエピソード”の半分は、これを読んでおけば回避できた。 これから作るなら気に掛けるべきこと
- 29. アメーバブログを支える データセンターとインフラ技術 2016 September 16 CyberAgent, Inc. All Rights Reserved レガシーなインフラからOpenStack移行の舞台裏 アプリ・ミドルウェア・インフラ編
- 30. 中島 弘貴 株式会社サイバーエージェント 技術本部 サービスリライアビリティグループ(SRG) インフラエンジニア 業務 メディア事業における各種Webサービスの運用 サイバーエージェント歴5年
- 31. 本日のアジェンダ ① 移行前の状況と課題 ② Openstackを使った新構成 ③ 負荷試験と移行メンテナンス ④ 移行後の状況 ⑤ プライベートクラウドの使い勝手 ⑥ まとめと今後
- 32. 1. 移行前の状況①アプリ サービス運用開始から年数の立ったシステムで 発生する種々の問題 サービス拡張で生まれる新機能（API）とDB群 構築された時期がまちまち いつのまにか機能外から参照されるDB →どこに手を入れればパフォーマンスが改善するの か？ →複雑でテストしにくい環境 DB1 DB2 DB1 DB2 Web APP Admin
- 33. 1. 移行前の状況②インフラ データベース問題 アメブロへのMySQL導入開始は2006年から MySQL 4系とMyISAM 怖い障害とデータ不整合 肥大化したデータ 一部にはOracleもあり、保守に課題 古くなったOSの問題 セキュリティパッチ 先進的なミドルウェアの導入が苦しい DB1 DB2 Oracle mysql4
- 34. 本日のアジェンダ ① 移行前の状況と課題 ② Openstackを使った新構成 ③ 負荷試験と移行メンテナンス ④ 移行後の状況 ⑤ プライベートクラウドの使い勝手 ⑥ まとめと今後
- 35. DB1 DB2 2. 新構成①全体 移設を機に刷新 アプリケーションとデータベース MySQLを5.5、フルInnoDBへ Oracle廃止 必要な冗長性についてはMHAで確保 データアクセスは全てAPIで 構築の自動化 Openstack API + Terraform Chef + Serverspec によるプロビジョニング いつでも捨てて作り直せる環境へ DB1 DB2 API Web APP Admin
- 36. 本日のアジェンダ ① 移行前の状況と課題 ② Openstackを使った新構成 ③ 負荷試験と移行メンテナンス ④ 移行後の状況 ⑤ プライベートクラウドの使い勝手 ⑥ まとめと今後
- 38. 3. ②メンテナンス 更新系と参照系の２回に分けて移行 参照系移行はDNSの切り替えにより実施（ユーザー影響なし） 更新系移行は計画メンテナンス DB Master (Old) 参照系 更新系 DB Master (New) 参照系 更新系 Replication DNS切り替え 旧DC 新DC Openstack
- 39. 3. ②メンテナンス 更新系と参照系の２回に分けて移行 参照系移行はDNSの切り替えにより実施（ユーザー影響なし） 更新系移行は計画メンテナンス DB Master (Old) 参照系 更新系 DB Master (New) 参照系 更新系 Replication停止 メンテナンス DNS切り替え 旧DC 新DC Openstack
- 40. 本日のアジェンダ ① 移行前の状況と課題 ② Openstackを使った新構成 ③ 負荷試験と移行メンテナンス ④ 移行後の状況 ⑤ プライベートクラウドの使い勝手 ⑥ まとめ
- 41. 4. 移行後の状況：移行結果 性能面 スマートフォンぺージの表示速度が大きく改善 コンポーネントが整理されたことにより、問題点が把握しやすい コスト面 300台以上の物理サーバー → 物理サーバー換算で100台以下に 運用面 要求の変化に柔軟に対応可能 サーバー増設なども、アプリ側担当で実施可能 負荷の高いDBを即日HDD→SSD化 コストが可視化されることにより、エンジニアの意識も変化
- 42. 本日のアジェンダ ① 移行前の状況と課題 ② Openstackを使った新構成 ③ 負荷試験と移行メンテナンス ④ 移行後の状況 ⑤ プライベートクラウドの使い勝手 ⑥ まとめと今後
- 43. 5. ユーザーから見たプライベートクラウドの使い勝手① 自動化は現状十分に可能 → Openstackの場合は、API仕様が公開されており対応したツールが多 い。terraformなどの利用については、AWSなどのパブリッククラウド を利用するのと同じレベルでの利用が可能 VMが利用できるストレージは高性能＋大容量の２本立てで → ローカルHDD + Cinder-SSD(NVMe) → ローカルSSD + Cinder-HDD などなど とはいえ限界はあるので、クラウドのために無理をしすぎない → どうしても必要なら物理機を併用 → パブリッククラウドが得意な部分は任せてしまう
- 44. 5. ユーザーから見たプライベートクラウドの使い勝手② パブリッククラウドとの併用の例（アメブロ） 1. Route53 (AWS) ○ 高い可用性 ○ APIでレコードのコード化が可能（Roadworker等） ○ メンテナンスなどにとても便利な機能 2. S3（AWS） ○ 書き込みパフォーマンス抜群 ○ ユーザー画像の保存に 他、Bigquery（GCP）等
- 45. 本日のアジェンダ ① 移行前の状況と課題 ② Openstackを使った新構成 ③ 負荷試験と移行メンテナンス ④ 移行後の状況 ⑤ プライベートクラウドの使い勝手 ⑥ まとめと今後
- 46. 6. 移設を終えて、今後に向けて ミドルウェアや構成のアップデートがしやすいことは性能向上につながる 例）性能向上の効果が著しいと見込まれる新バージョンの採用 MySQL 5.7、Java/Ruby/Golangなどの最新バージョン 最終的には物理機を完全排除し、Immutable Infrastractureとして運用 アプリの性能を向上させるのはチーム力 適切にアプリケーションモニタリングを設定 チームへ常にパフォーマンスの情報が目に入るように（Slackへの通知など） サービスの性質・データ量にあった構成への変更など、地道な作業が重要 例えば負荷試験のためにクラウドを使うのは良い用途です
- 47. Thank you