アメーバブログを支えるデータセンターとインフラ技術

アメーバブログを支える
データセンターとインフラ技術
2016 September 16
CyberAgent, Inc. All Rights Reserved
レガシーなインフラからOpenStack移行の舞台裏

本資料は2016/09/16に行われました
アプリケーション・パフォーマンス 2016
発表内容からの抜粋となります。

平野智洋
株式会社サイバーエージェント
技術本部
サービスファシリティーグループ(SFG)
ハードウェア・ストレージワーキンググループ
（自称ハードウェアブローカー）
業務
ハードウェア/ストレージの検証・選定
ファシリティ設計・機器設置・配線・構築
システム開発・運用設計・トラブルシュートなど
サイバーエージェント歴12年

本日のアジェンダ
① アメーバブログって？？？
② 移行前に考えてたこと
③ 構成
④ 移行前に困ったこと
⑤ 移行後に困ったこと
⑥ これから作るなら気に掛けるべきこと

▼１万人以上の芸人・有名人が利用している国内最大ブログサービス
▶ 会員数が5,300万人突破
▶ 2004年からスタート
※2016/8月時点 Ameba全体での会員数
▶ 日本最大規模のブログサービス
このサービスをOpenstackに移行したお話

従来のアメーバブログが抱えた問題・・・
- 機器の老朽化と保守切れ→突然の故障→積み重なる屍の山
- 設置スペース不足
- 電力不足
- 手順が複雑で時間の掛かるサーバ構築
- 衝突するIPアドレス
- 担当者不明の謎サーバ
- 重たいNetwork
- アンバランスなストレージ
・・・などなど

作りやすく、捨てやすい
サーバリソース
OpenStackの採用

プライベートクラウドの核となる３本の矢の導入
ストレージ改革
NW改革サーバ改革
▶ KVMホストのHDDストレージ
▶ iSCSI接続のHDDストレージ
▶ iSCSI接続のNVMeストレージ
▶ サーバリンク1G → 10G x2 20G化
▶ L3DSRによる効率化
▶ Ironicによる仮想/物理の一元管理
▶ 豊富なインスタンス・ラックの高集約化

作りやすく、捨てやすい
サーバリソース
Novaリソース500台 (物理コア20,000個)
Ironicベアメタル(物理サーバ)150台
高速NVMe Cinderリソース 120TB, 大容量HDD Cinderリソース 360TB
Glance Imageリソース 100TB, Swift Objectリソース 1.3PB
OpenStackの採用

高集約化：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倍

Nova
Compute
Keystone
Authorize
Openstack -Kilo- コンポーネント
Cinder
Block Storage
Designate
DNS
Newtron
Networking
Glance
Image
Horizon
Dashboard
Ironic
Bare Metal
Swift
Object

2種類のCinderサービス
Virtual
Machine
Virtual
Machine
Virtual
Machine
Virtual
Machine ・・・・
大容量で、そこそこの速さ
無停止で完全冗長構成で高信頼の
Cinderサービス
Cinder-HDD
どんな高負荷にも耐えうる性能重視
最強パフォーマンスを誇る
Cinderサービス
Cinder-NVMe

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

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比較で約５倍の性能を保証！）
- 冗長なし！

導入前の検証で…
ストレージ改革
NW改革サーバ改革
▶ KVMホストのHDDストレージ
▶ iSCSI接続のHDDストレージ
▶ iSCSI接続のNVMeストレージ
▶ サーバリンク1G → 10G化
▶ L3DSRによる帯域効率化
▶ Ironicによる仮想/物理の一元管理
▶ 豊富なインスタンス・ラックの高集約化
帯域が10Gフルにでない
ストレージのIOが遅い
CPU利用に偏りが出る

少々負荷を掛けると仮想サーバがポンコツになる問題
現象：
ネットワーク負荷を掛けるとサーバが重い
原因：
仮想NICのSoftware Interruptsが特定CPUに偏っていた
現象詳細：
試験環境の仮想マシンにNginxを立てて
abで負荷を送ってみたらCPU0のidleだけ低かった。
結果的にCPU/DISK/Network、あらゆる処理が遅くな
る
原因詳細：
KVMのvirtio-netドライバは、8VCPU以上ある場合、
ソフトウェア割り込みを１つのCPUでしか処理しない
対策：
qemu-kvmおよびゲスト側でチューニングを実施した。
詳細は後述

Cinder-HDDストレージが遅い問題
現象：
ストレージがものすごく重い
原因：
Cinder-HDDの性能不足
現象詳細：
Cinder-HDDをマウントしたMySQLスレーブサーバ約100台にて、
旧環境からのシステム移行のため”インデックスの張り直し”ジョブを一斉に実行し
たら、
テストで1台だけで実施したときには20分で終わったのに、10時間以上掛かった。
原因詳細：
Cinder-HDDはCacheありきでパフォーマンスを嵩上げする、ベストエフォート型
なので、
Cacheが切れると劇的に遅くなる。（100台もバックエンドのストレージサーバ無
いし）
テスト時に一時的に速い状況があったのが混乱のもと。
そもそもCinder-HDDはDB用途には向かない。
対策：
Cinder-HDDのボリュームでは、厳しめのQoSを設定。
負荷の高いワークロードはCinder-NVMeの利用を明文化し、運用でカバー。
Cinder
Gateway
Cinder
Storage
HDD
DRAM
Cache
Virtual
Machine

□ 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にしても足りない。
移行後に困ったこと

□ 10Gはオワコン
設計当初は、1サーバ40コア程度だったが、今はより多くのコアを搭載できる。コンピューティング能力があがれば、
流れるトラフィックも増えてくるので、今後は25G/50G/100Gで作ったほうが良い。
□ Openstackを理解しよう
”誰でもかんたんに、開発いらずでクラウドを作れちゃうよ☆”
↑コレは嘘です
ドキュメントが嘘だったり、ドキュメントに書いてない裏設定が実装されていたり。
各コンポーネントは密結合でバグだらけ、Ironicは地雷だったり・・
リリースサイクルが早すぎで、去年のオプスタは今のオプスタじゃなさ過ぎるという理不尽さ。
不具合を埋めつつ独自patchをあてて運用をするしかないので、コードの読み書きは必須だしそれなりの覚悟が必要。
□ チューニング指南書を理解しよう
RedHatさんが “Virtualization Tuning and Optimization Guide” という、とても有意なドキュメントを
公開しています。”困ったエピソード”の半分は、これを読んでおけば回避できた。
これから作るなら気に掛けるべきこと

●メンバーを募集しています！
詳しくはコーポレートサイトまで！
https://www.cyberagent.co.jp/recruit/career/jobs/
●詳しくは直接聞いてください。
壇上ではお話できなかった裏事情、採用しているベンダやそれぞれのメリデメ、
具体的な数字・詳細構成などなど、お話しできます。

アメーバブログを支える
データセンターとインフラ技術
2016 September 16
CyberAgent, Inc. All Rights Reserved
レガシーなインフラからOpenStack移行の舞台裏
アプリ・ミドルウェア・インフラ編

中島弘貴
株式会社サイバーエージェント
技術本部
サービスリライアビリティグループ(SRG)
インフラエンジニア
業務
メディア事業における各種Webサービスの運用
サイバーエージェント歴5年

① 移行前の状況と課題
② Openstackを使った新構成
③ 負荷試験と移行メンテナンス
④ 移行後の状況
⑤ プライベートクラウドの使い勝手
⑥ まとめと今後

1. 移行前の状況①アプリ
サービス運用開始から年数の立ったシステムで
発生する種々の問題
サービス拡張で生まれる新機能（API）とDB群
構築された時期がまちまち
いつのまにか機能外から参照されるDB
→どこに手を入れればパフォーマンスが改善するの
か？
→複雑でテストしにくい環境
DB1 DB2
DB1 DB2
Web APP
Admin

1. 移行前の状況②インフラ
データベース問題
アメブロへのMySQL導入開始は2006年から
MySQL 4系とMyISAM
怖い障害とデータ不整合
肥大化したデータ
一部にはOracleもあり、保守に課題
古くなったOSの問題
セキュリティパッチ
先進的なミドルウェアの導入が苦しい
DB1 DB2
Oracle mysql4

DB1 DB2
2. 新構成①全体
移設を機に刷新
アプリケーションとデータベース
MySQLを5.5、フルInnoDBへ
Oracle廃止
必要な冗長性についてはMHAで確保
データアクセスは全てAPIで
構築の自動化
Openstack API + Terraform
Chef + Serverspec によるプロビジョニング
いつでも捨てて作り直せる環境へ
DB1 DB2
API
Web
APP
Admin

3. ①負荷試験
1週間分のログを元に繰り返しロードテスト
パフォーマンスの確認と問題点の洗い出し
問題になるのは多くの場合DBデータの取り扱い
キャッシュ化、取得データのスリム化、DBインスタンスの適正化
NewRelicの利用

3. ②メンテナンス
更新系と参照系の２回に分けて移行
参照系移行はDNSの切り替えにより実施（ユーザー影響なし）
更新系移行は計画メンテナンス
DB Master
(Old)
参照系更新系
DB Master
(New)
参照系更新系
Replication
DNS切り替え
旧DC 新DC
Openstack

3. ②メンテナンス
更新系と参照系の２回に分けて移行
参照系移行はDNSの切り替えにより実施（ユーザー影響なし）
更新系移行は計画メンテナンス
DB Master
(Old)
参照系更新系
DB Master
(New)
参照系更新系
Replication停止
メンテナンス
DNS切り替え
旧DC 新DC
Openstack

① 移行前の状況と課題
② Openstackを使った新構成
③ 負荷試験と移行メンテナンス
④ 移行後の状況
⑤ プライベートクラウドの使い勝手
⑥ まとめ

4. 移行後の状況：移行結果
性能面
スマートフォンぺージの表示速度が大きく改善
コンポーネントが整理されたことにより、問題点が把握しやすい
コスト面
300台以上の物理サーバー → 物理サーバー換算で100台以下に
運用面
要求の変化に柔軟に対応可能
サーバー増設なども、アプリ側担当で実施可能
負荷の高いDBを即日HDD→SSD化
コストが可視化されることにより、エンジニアの意識も変化

5. ユーザーから見たプライベートクラウドの使い勝手①
自動化は現状十分に可能
→ Openstackの場合は、API仕様が公開されており対応したツールが多
い。terraformなどの利用については、AWSなどのパブリッククラウド
を利用するのと同じレベルでの利用が可能
VMが利用できるストレージは高性能＋大容量の２本立てで
→ ローカルHDD + Cinder-SSD(NVMe)
→ ローカルSSD + Cinder-HDD などなど
とはいえ限界はあるので、クラウドのために無理をしすぎない
→ どうしても必要なら物理機を併用
→ パブリッククラウドが得意な部分は任せてしまう

5. ユーザーから見たプライベートクラウドの使い勝手②
パブリッククラウドとの併用の例（アメブロ）
1. Route53 (AWS)
○ 高い可用性
○ APIでレコードのコード化が可能（Roadworker等）
○ メンテナンスなどにとても便利な機能
2. S3（AWS）
○ 書き込みパフォーマンス抜群
○ ユーザー画像の保存に
他、Bigquery（GCP）等

6. 移設を終えて、今後に向けて
ミドルウェアや構成のアップデートがしやすいことは性能向上につながる
例）性能向上の効果が著しいと見込まれる新バージョンの採用
MySQL 5.7、Java/Ruby/Golangなどの最新バージョン
最終的には物理機を完全排除し、Immutable Infrastractureとして運用
アプリの性能を向上させるのはチーム力
適切にアプリケーションモニタリングを設定
チームへ常にパフォーマンスの情報が目に入るように（Slackへの通知など）
サービスの性質・データ量にあった構成への変更など、地道な作業が重要
例えば負荷試験のためにクラウドを使うのは良い用途です

アメーバブログを支えるデータセンターとインフラ技術

More Related Content

What's hot

Similar to アメーバブログを支えるデータセンターとインフラ技術

アメーバブログを支えるデータセンターとインフラ技術