Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
SPEEDAの
インフラ運営
2016/07/07
UZABASEMeetUP
もくじ
● ごあいさつ
● インフラチームご紹介
● UZABASEとは
● SPEEDAとは
● SPEEDAインフラの概要
● SPEEDAインフラの変遷
● 四方山話 NewsPicks連携
● 質問
ごあいさつ
● 話してる人
○ 金屋(かなや)と申します
○ 2014年4月にUZABASEにジョイン
○ 前職・前々職・前々(略)もインフラやってます
■ Webサービス→事業会社(EC)→今ココ
○ SPEEDA本番サービスインフラを担当
...
インフラチームご紹介
● チームメンバー
○ 人数
■ 5名
○ 仕事内容
■ 社内ビジネス基盤の構築・運用
● 社内IT全般
■ 本番システム基盤の構築・運用
● SPEEDA全般
■ 社内ヘルプデスク
■ その他インフラ関連全般
UZABASEとは
・ミッション: 経済情報で、世界中の意思決定を支える
あらゆる経済情報を人とテクノロジーの力で整理・分析・創出することで、
人々の生産性を高め、創造性を解放する。
私たちは、経済情報で世界中の意思決定を支えるプラットフォーム...
SPEEDAとは
企業・業界分析のためのオンライン情報プラットフォーム
・世界370万社データが約560業界に分類・分析されたDB
・100万件以上のM&A情報
・10万系統以上の統計
→企業・業界分析を劇的に効率化し、意志決定の迅速化や
 本...
SPEEDAのデモ
https://www.ub-speeda.com/
SPEEDAインフラの概要
● 100%ピュアオンプレミス
○ 某データセンターにて稼働しております
○ とはいえ、一部サービスでAWS利用中です
● BtoBサービス
○ 契約法人ユーザなので、ピークはビジネスタイム(9~18時)
SPEEDAインフラの概要
● データ容量が大きい
○ MySQL 3TB以上
○ Solr 1TB以上
○ ElasticSearch 1TB以上
○ ファイル 3TB以上
● Webサービスは参照のみ
○ DBをマスタ、スレーブ構成でレプリ...
SPEEDAインフラの概要
● SPEEDAの悩ましいところ
○ 誰がいつどのデータにアクセスするか分からない
○ 巨大なデータベースにもかかわらずキャッシュができない
○ ただしユーザ数は少ない
○ いかにデータの隅々まで高速にアクセスできる...
● OS
● 仮想基盤
● コンテナ
● 監視
SPEEDAインフラの概要
● Web・AP・DBの3層構造
○ LB
○ Web
○ AP
○ DB(データソース)
○ バッチ        
LVS(画像無い。。。)
ステートフル!!
Ca...
● 全てがシングルの全部入りというミニマム構成
○ サーバは1台のタワー型のみ
■ 今も社内サーバルームにて開発機として稼働中
● もちろん監視無し
SPEEDAインフラの変遷 プロトタイプ ~2010
The Internet
とあるマンショ...
● 複数台のサーバに分散されたが、基本シングル構成
● 初のデータセンタ運用が開始された
○ お客さんのデータセンターに間借りで、小規模
○ 物理サーバは複数台のラックマウント型
● まだ監視無し
SPEEDAインフラの変遷 Ver.1 201...
● サーバ台数も大きくなり、現行のデータセンタに移行
● DBは物理サーバ、その他は仮想サーバの構成
○ 但し、仮想基盤も含めシングル構成
● まだ監視無し
SPEEDAインフラの変遷 Ver.2 2011~2013
The Internet
...
● 重要な日次更新バッチが24時間で完了しない状態
○ 最終兵器、FusionIOを導入、10倍高速化!
■ 更新処理の安定性が向上し、SPEEDA品質も向上
● DBの分割を実施し、更新負荷を分散
● 監視(死活・性能)が開始された
SPEE...
● スイッチとサーバ間接続が冗長化された
● ハードウェア監視が開始された
● elasticsearchが導入された
○ 初期は物理サーバで稼働→やはり仮想化
● backupDBを構築し、D2DでDBの3世代バックアップが可能に
○ 開発環...
● 仮想基盤用のiSCSI共有ストレージを導入
○ 仮想基盤のクラスタ化
○ ライブマイグレーションの実現
● elasticsearchの大幅増強
○ 物理10台化(仮想20台)+SSD化
SPEEDAインフラの変遷 Ver.5 2014~2...
● DBサーバの容量逼迫のため、リプレース
○ 1U→2Uサーバに増強し、拡張性を3倍にした
○ それぞれ1.4TB→3TB、2.4TB→4TBへ増強
○ 増強分のPCIe-SSDとして新たにHGSTを採用
■ コスト半額以下で容量2倍を達成
...
● NewsPicks連携でB2Cトラフィックを捌くことが必要になった
○ 冗長回線の導入で、インターネット回線が冗長化
○ L3バランサ(LVS)の導入で2000req/sec→40000req/sec
○ マイクロサービスアーキテクチャを採...
20Uzabase 20
DB
AP
Web/LBApache
Router
SPEEDA
CommonD
B
CommonDB FinanceDBUserDB FileDB
ES
Cluster
ES
Cluster
ES
Cluster
E...
21Uzabase 21
DB
Web/LB
AP
Apache
Router
SPEEDA
CommonD
B
CommonDB FinanceDBUserDB FileDB
ES
Cluster
ES
Cluster
ES
Cluster
...
22Uzabase 22
DB
Web/LB
AP
Nginx
lvsLVSApache
Router
SPEEDA
CommonD
B
CommonDB FinanceDBUserDB FileDB
ES
Cluster
ES
Cluster...
四方山話 NewsPicks連携 ES構成変更の結果
● データノードの負荷が軽減された
● クライアントノードでFull GCが発生することはほとんどない
● 結果として検索応答時間が大幅に改善された
四方山話 NewsPicks連携 デモ
https://www.newspicks.com/
DEMO
エンジニア募集
Upcoming SlideShare
Loading in …5
×

SPEEDAインフラ運営

4,470 views

Published on

SPEEDAインフラ運営

Published in: Engineering
  • Be the first to comment

SPEEDAインフラ運営

  1. 1. SPEEDAの インフラ運営 2016/07/07 UZABASEMeetUP
  2. 2. もくじ ● ごあいさつ ● インフラチームご紹介 ● UZABASEとは ● SPEEDAとは ● SPEEDAインフラの概要 ● SPEEDAインフラの変遷 ● 四方山話 NewsPicks連携 ● 質問
  3. 3. ごあいさつ ● 話してる人 ○ 金屋(かなや)と申します ○ 2014年4月にUZABASEにジョイン ○ 前職・前々職・前々(略)もインフラやってます ■ Webサービス→事業会社(EC)→今ココ ○ SPEEDA本番サービスインフラを担当 ■ 1年目は社内IT含め何でもやってた ● 引っ越し・電話・複合機・無線LAN...etc
  4. 4. インフラチームご紹介 ● チームメンバー ○ 人数 ■ 5名 ○ 仕事内容 ■ 社内ビジネス基盤の構築・運用 ● 社内IT全般 ■ 本番システム基盤の構築・運用 ● SPEEDA全般 ■ 社内ヘルプデスク ■ その他インフラ関連全般
  5. 5. UZABASEとは ・ミッション: 経済情報で、世界中の意思決定を支える あらゆる経済情報を人とテクノロジーの力で整理・分析・創出することで、 人々の生産性を高め、創造性を解放する。 私たちは、経済情報で世界中の意思決定を支えるプラットフォームをつく りあげます。 ・サービス  企業・業界分析のためのオンライン情報プラットフォーム  経済情報に特化したソーシャル経済ニュース 今回はこちら B2B B2C
  6. 6. SPEEDAとは 企業・業界分析のためのオンライン情報プラットフォーム ・世界370万社データが約560業界に分類・分析されたDB ・100万件以上のM&A情報 ・10万系統以上の統計 →企業・業界分析を劇的に効率化し、意志決定の迅速化や  本業務に注力できる
  7. 7. SPEEDAのデモ https://www.ub-speeda.com/
  8. 8. SPEEDAインフラの概要 ● 100%ピュアオンプレミス ○ 某データセンターにて稼働しております ○ とはいえ、一部サービスでAWS利用中です ● BtoBサービス ○ 契約法人ユーザなので、ピークはビジネスタイム(9~18時)
  9. 9. SPEEDAインフラの概要 ● データ容量が大きい ○ MySQL 3TB以上 ○ Solr 1TB以上 ○ ElasticSearch 1TB以上 ○ ファイル 3TB以上 ● Webサービスは参照のみ ○ DBをマスタ、スレーブ構成でレプリケーションしている ○ Webサービスはスレーブ参照で、データ更新はマスタ ● 更新処理が多い ○ 1000本程度のバッチが日夜動作している ○ 最新の企業情報を取り込むため、日々大量の更新を捌く必 要がある
  10. 10. SPEEDAインフラの概要 ● SPEEDAの悩ましいところ ○ 誰がいつどのデータにアクセスするか分からない ○ 巨大なデータベースにもかかわらずキャッシュができない ○ ただしユーザ数は少ない ○ いかにデータの隅々まで高速にアクセスできるようにするか が課題
  11. 11. ● OS ● 仮想基盤 ● コンテナ ● 監視 SPEEDAインフラの概要 ● Web・AP・DBの3層構造 ○ LB ○ Web ○ AP ○ DB(データソース) ○ バッチ         LVS(画像無い。。。) ステートフル!! Cacti
  12. 12. ● 全てがシングルの全部入りというミニマム構成 ○ サーバは1台のタワー型のみ ■ 今も社内サーバルームにて開発機として稼働中 ● もちろん監視無し SPEEDAインフラの変遷 プロトタイプ ~2010 The Internet とあるマンションの一部屋 ・Web ・AP ・DB  ・Solr ・バッチ SPOF仮想 物理
  13. 13. ● 複数台のサーバに分散されたが、基本シングル構成 ● 初のデータセンタ運用が開始された ○ お客さんのデータセンターに間借りで、小規模 ○ 物理サーバは複数台のラックマウント型 ● まだ監視無し SPEEDAインフラの変遷 Ver.1 2010~2011 The Internet データセンタのハーフラック間借り ・Web ・AP SPOF ・DB ・Solr ・バッチ 仮想 物理
  14. 14. ● サーバ台数も大きくなり、現行のデータセンタに移行 ● DBは物理サーバ、その他は仮想サーバの構成 ○ 但し、仮想基盤も含めシングル構成 ● まだ監視無し SPEEDAインフラの変遷 Ver.2 2011~2013 The Internet 現行のデータセンタ ・Web ・AP ・Solr SPOF ・DB ・バッチ 仮想 物理
  15. 15. ● 重要な日次更新バッチが24時間で完了しない状態 ○ 最終兵器、FusionIOを導入、10倍高速化! ■ 更新処理の安定性が向上し、SPEEDA品質も向上 ● DBの分割を実施し、更新負荷を分散 ● 監視(死活・性能)が開始された SPEEDAインフラの変遷 Ver.3 2013~2014 The Internet 現行のデータセンタ ・Web ・AP ・Solr SPOF ・DB分割+PCIe-SSD ・バッチ 仮想 物理
  16. 16. ● スイッチとサーバ間接続が冗長化された ● ハードウェア監視が開始された ● elasticsearchが導入された ○ 初期は物理サーバで稼働→やはり仮想化 ● backupDBを構築し、D2DでDBの3世代バックアップが可能に ○ 開発環境へのデータのリストアなど、柔軟性が向上 SPEEDAインフラの変遷 Ver.4 2014~2015 The Internet 現行のデータセンタ ・Web ・AP ・Solr ・elasticsearch SPOF ・DB分割+PCIe-SSD ・backupDB ・バッチ 仮想 物理
  17. 17. ● 仮想基盤用のiSCSI共有ストレージを導入 ○ 仮想基盤のクラスタ化 ○ ライブマイグレーションの実現 ● elasticsearchの大幅増強 ○ 物理10台化(仮想20台)+SSD化 SPEEDAインフラの変遷 Ver.5 2014~2015 The Internet 現行のデータセンタ SPOF ・DB分割+PCIe-SSD ・backupDB ・バッチ 仮想 物理 ・Web ・AP ・Solr ・elasticsearch + SSD
  18. 18. ● DBサーバの容量逼迫のため、リプレース ○ 1U→2Uサーバに増強し、拡張性を3倍にした ○ それぞれ1.4TB→3TB、2.4TB→4TBへ増強 ○ 増強分のPCIe-SSDとして新たにHGSTを採用 ■ コスト半額以下で容量2倍を達成 SPEEDAインフラの変遷 Ver.6 2015~2016 The Internet 現行のデータセンタ SPOF ・DB分割+PCIe-SSD ・backupDB ・バッチ 仮想 物理 ・Web ・AP ・Solr ・elasticsearch + SSD
  19. 19. ● NewsPicks連携でB2Cトラフィックを捌くことが必要になった ○ 冗長回線の導入で、インターネット回線が冗長化 ○ L3バランサ(LVS)の導入で2000req/sec→40000req/sec ○ マイクロサービスアーキテクチャを採用 ● elasticsearchの高速・安定化のために構成変更 ○ データノード、検索ノード、更新ノードを分離 SPEEDAインフラの変遷 Ver.7 2016~現在 The Internet 現行のデータセンタ SPOF ・DB分割+PCIe-SSD ・backupDB ・バッチ 仮想 物理 ・LVS ・Web ・AP ・Solr ・elasticsearch +SSD  +ノード役割分離
  20. 20. 20Uzabase 20 DB AP Web/LBApache Router SPEEDA CommonD B CommonDB FinanceDBUserDB FileDB ES Cluster ES Cluster ES Cluster ES Cluster ES (20台) CommonDB FinanceDB Light/Plug-in PIB 四方山話 NewsPicks連携 連携前 ・B2B ・同時接続数は多くない →この構成で捌ける
  21. 21. 21Uzabase 21 DB Web/LB AP Apache Router SPEEDA CommonD B CommonDB FinanceDBUserDB FileDB ES Cluster ES Cluster ES Cluster ES Cluster ES (20台) CommonDB FinanceDB News Media Stats Contents Proxy Search ContentsDB ContentsDB Light/Plug-in PIB 四方山話 NewsPicks連携 負荷テスト時に発生した課題 Apache ・B2B ・同時接続数は多くない ・B2C ・ユーザ150万人以上 →負荷試験で問題が発生 FW処理が重く トラフィックが捌け ない →ルーティングの みに変更 2000req/secで頭打ち →LVS+nginxに変更 検索レスポンス悪化 →ノード役割分離
  22. 22. 22Uzabase 22 DB Web/LB AP Nginx lvsLVSApache Router SPEEDA CommonD B CommonDB FinanceDBUserDB FileDB ES Cluster ES Cluster ES Cluster ES Cluster ES Data (20台) CommonDB FinanceDB News Media Stats Contents Proxy Search ContentsDB ContentsDB Nginx ES Search Light/Plug-in PIB ES Coordinate 四方山話 NewsPicks連携 最終構成 ・B2B ・同時接続数は多くない ・B2C ・ユーザ150万人以上 →無事に負荷試験をクリア 2000→40000req/sec に向上 リソース余裕で 捌けるように向上 検索レスポンスタイム 大幅に改善
  23. 23. 四方山話 NewsPicks連携 ES構成変更の結果 ● データノードの負荷が軽減された ● クライアントノードでFull GCが発生することはほとんどない ● 結果として検索応答時間が大幅に改善された
  24. 24. 四方山話 NewsPicks連携 デモ https://www.newspicks.com/ DEMO
  25. 25. エンジニア募集

×