More Related Content
What's hot (20)
Similar to 厂笔贰贰顿础インフラ运営 (20)
厂笔贰贰顿础インフラ运営
- 2. もくじ ● ごあいさつ ● インフラチームご紹介 ● UZABASEとは ● SPEEDAとは ● SPEEDAインフラの概要 ● SPEEDAインフラの変遷 ● 四方山話 NewsPicks連携 ● 質問
- 3. ごあいさつ ● 話してる人 ○ 金屋（かなや）と申します ○ 2014年４月にUZABASEにジョイン ○ 前職?前々職?前々（略）もインフラやってます ■ Webサービス→事業会社（EC)→今ココ ○ SPEEDA本番サービスインフラを担当 ■ １年目は社内IT含め何でもやってた ● 引っ越し?電話?複合機?無線LAN...etc
- 4. インフラチームご紹介 ● チームメンバー ○ 人数 ■ ５名 ○ 仕事内容 ■ 社内ビジネス基盤の構築?運用 ● 社内IT全般 ■ 本番システム基盤の構築?運用 ● SPEEDA全般 ■ 社内ヘルプデスク ■ その他インフラ関連全般
- 8. SPEEDAインフラの概要 ● １００％ピュアオンプレミス ○ 某データセンターにて稼働しております ○ とはいえ、一部サービスでAWS利用中です ● BtoBサービス ○ 契約法人ユーザなので、ピークはビジネスタイム(9～18時)
- 9. SPEEDAインフラの概要 ● データ容量が大きい ○ MySQL ３TB以上 ○ Solr １TB以上 ○ ElasticSearch １TB以上 ○ ファイル ３TB以上 ● Webサービスは参照のみ ○ DBをマスタ、スレーブ構成でレプリケーションしている ○ Webサービスはスレーブ参照で、データ更新はマスタ ● 更新処理が多い ○ １０００本程度のバッチが日夜動作している ○ 最新の企業情報を取り込むため、日々大量の更新を捌く必 要がある
- 10. SPEEDAインフラの概要 ● SPEEDAの悩ましいところ ○ 誰がいつどのデータにアクセスするか分からない ○ 巨大なデータベースにもかかわらずキャッシュができない ○ ただしユーザ数は少ない ○ いかにデータの隅々まで高速にアクセスできるようにするか が課題
- 11. ● OS ● 仮想基盤 ● コンテナ ● 監視 SPEEDAインフラの概要 ● Web?AP?DBの３層構造 ○ LB ○ Web ○ AP ○ DB（データソース） ○ バッチ LVS（画像無い。。。） ステートフル！！ Cacti
- 12. ● 全てがシングルの全部入りというミニマム構成 ○ サーバは１台のタワー型のみ ■ 今も社内サーバルームにて開発機として稼働中 ● もちろん監視無し SPEEDAインフラの変遷 プロトタイプ ~2010 The Internet とあるマンションの一部屋 ?Web ?AP ?DB ?Solr ?バッチ SPOF仮想 物理
- 13. ● 複数台のサーバに分散されたが、基本シングル構成 ● 初のデータセンタ運用が開始された ○ お客さんのデータセンターに間借りで、小規模 ○ 物理サーバは複数台のラックマウント型 ● まだ監視無し SPEEDAインフラの変遷 Ver.1 2010~2011 The Internet データセンタのハーフラック間借り ?Web ?AP SPOF ?DB ?Solr ?バッチ 仮想 物理
- 14. ● サーバ台数も大きくなり、現行のデータセンタに移行 ● DBは物理サーバ、その他は仮想サーバの構成 ○ 但し、仮想基盤も含めシングル構成 ● まだ監視無し SPEEDAインフラの変遷 Ver.2 2011~2013 The Internet 現行のデータセンタ ?Web ?AP ?Solr SPOF ?DB ?バッチ 仮想 物理
- 15. ● 重要な日次更新バッチが２４時間で完了しない状態 ○ 最終兵器、FusionIOを導入、10倍高速化！ ■ 更新処理の安定性が向上し、SPEEDA品質も向上 ● DBの分割を実施し、更新負荷を分散 ● 監視（死活?性能）が開始された SPEEDAインフラの変遷 Ver.3 2013~2014 The Internet 現行のデータセンタ ?Web ?AP ?Solr SPOF ?DB分割+PCIe-SSD ?バッチ 仮想 物理
- 16. ● スイッチとサーバ間接続が冗長化された ● ハードウェア監視が開始された ● elasticsearchが導入された ○ 初期は物理サーバで稼働→やはり仮想化 ● backupDBを構築し、D２DでDBの３世代バックアップが可能に ○ 開発環境へのデータのリストアなど、柔軟性が向上 SPEEDAインフラの変遷 Ver.4 2014~2015 The Internet 現行のデータセンタ ?Web ?AP ?Solr ?elasticsearch SPOF ?DB分割+PCIe-SSD ?backupDB ?バッチ 仮想 物理
- 17. ● 仮想基盤用のiSCSI共有ストレージを導入 ○ 仮想基盤のクラスタ化 ○ ライブマイグレーションの実現 ● elasticsearchの大幅増強 ○ 物理10台化（仮想20台）+SSD化 SPEEDAインフラの変遷 Ver.5 2014~2015 The Internet 現行のデータセンタ SPOF ?DB分割+PCIe-SSD ?backupDB ?バッチ 仮想 物理 ?Web ?AP ?Solr ?elasticsearch + SSD
- 18. ● DBサーバの容量逼迫のため、リプレース ○ １U→2Uサーバに増強し、拡張性を3倍にした ○ それぞれ1.4TB→3TB、2.4TB→4TBへ増強 ○ 増強分のPCIe-SSDとして新たにHGSTを採用 ■ コスト半額以下で容量２倍を達成 SPEEDAインフラの変遷 Ver.6 2015~2016 The Internet 現行のデータセンタ SPOF ?DB分割+PCIe-SSD ?backupDB ?バッチ 仮想 物理 ?Web ?AP ?Solr ?elasticsearch + SSD
- 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Ｕｚａｂａｓｅ 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Ｕｚａｂａｓｅ 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Ｕｚａｂａｓｅ 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. 四方山話 NewsPicks連携 ES構成変更の結果 ● データノードの負荷が軽減された ● クライアントノードでFull GCが発生することはほとんどない ● 結果として検索応答時間が大幅に改善された
- 25. エンジニア募集