Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
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
エンジニア募集
Próxima SlideShare
Cargando en…5
×

SPEEDAインフラ運営

4.702 visualizaciones

Publicado el

SPEEDAインフラ運営

Publicado en: Ingeniería
  • Sé el primero en comentar

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. エンジニア募集

×