「さくらのVPS」のインフラと運用 / How we operate the Infrastructure of Sakura VPS

by chamaharun

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⾃⼰紹介

Slide 3

Slide 3 text

⼩林巧 (こばやしたくみ) • [email protected] @chamaharun • 2017年4⽉⼊社新卒3年⽬所属 • 技術本部ミドルウェアグループ • 仮想化基盤チーム VPSインフラ担当経歴 • 2014/2 〜 DCOPチームアルバイト • 2017/6 〜 SVOPチーム • 2018/3 〜仮想化基盤チーム著書 • 技術評論社イラスト図解でよくわかる ITインフラの基礎知識(共著) • 技術評論社 Software Design 2018年7⽉号/2018年10⽉号(寄稿)

Slide 4

Slide 4 text

• さくらのVPSのサービスについて • さくらのVPSの仕組み • 運⽤するにあたって⾟いところと今後の意気込み今⽇お話すること注意事項等 • サービス提供上公開できないこともあります(DC所在地や原価等) • 「for Windows」「ベアメタルプラン」は仕様が違います • 資料作成当時(2019年9⽉)の情報です発表当時資料になく⼝頭で説明・補⾜した部分は発表後にここに追記しています。

Slide 5

Slide 5 text

「さくらのVPS」とは

Slide 6

Slide 6 text

さくらのVPS使っている⼈!

Slide 7

Slide 7 text

• Virtual Private Server = 仮想専⽤サーバ • 2010年サービス開始 • 注⽂するとVMが作成されグローバルIPとrootパスが送られてくる • コントロールパネルから起動・停⽌・ローカル接続などができるさくらのVPS VM = Virtual Machine 仮想マシン直近の主な機能拡充 • 「サーバ監視β」提供開始(2019年1⽉) • パケットフィルタ機能リリース(2019年6⽉) • CentOS 8 提供開始(2019年10⽉)など詳しくは「VPSニュース」へ https://vps-news.sakura.ad.jp/

Slide 8

Slide 8 text

さくらのクラウドとのアーキテクチャの⽐較さくらのVPS さくらのクラウド VM ホストサーバ VM ホストサーバ VM VM VM ホストサーバ VM ストレージ VMのストレージがホストサーバ上にある VMのストレージがネットワーク上にある • ⾼価なストレージアプライアンスを必要とせず安価に提供可能 • 障害の影響範囲が⼩さい • ホストが障害でも別のホストからVMを起動できる • 別のVMで使⽤していたディスクを接続して VMを起動できる

Slide 9

Slide 9 text

さくらのVPSのホストサーバ VM VPSホストサーバ VM VM • VMが稼働しているサーバ • 複数VMでリソースを共有 • HDD/SSD/PSUなどのパーツを複数搭載し冗⻑化 • ハードウェアRAID • bonding / NW機器の冗⻑化 • IPMIによるリモートからの操作 NIC = Network Interface Card PSU = Power Supply Unit RAID = 冗⻑化や⾼速化のため複数のディスクを束ねて使⽤すること

Slide 10

Slide 10 text

〇〇Stackなどのクラウド管理基盤ソフトウェアを使⽤せず⾃前で実装 • KVM+QEMU (仮想マシンの実⾏環境) • libvirt (仮想マシンの制御) • Linux Bridge + (Nested)VLAN(仮想マシンのNW) • LVM(仮想マシンのストレージ) さくらのVPSの実装⾃社で開発・保守することで低コストで運⽤＆不具合に迅速に対応 KVM = Kernel-based Virtual Machine LVM = Logical Volume Manager

Slide 11

Slide 11 text

さくらのVPSのVMができるまで VM VPSホストサーバ VM VM スクリプト VPS API 実⾏ LV LV LV 実⾏結果 • 社内システムとの調整(課⾦等) • ホストサーバの選定 • スクリプトの実⾏結果をコンパネへ反映 • LV(VMのストレージ領域)の作成 • OSイメージの展開 • VMの初期設定 •スタートアップスクリプトの挿⼊など • 通信設定・パケットフィルタなど • VMの起動お客様からVMの申し込みがあると、VPS APIがリソースの空き具合から収容するホストサーバを選定し、ホストサーバにあるスクリプトを叩き、スクリプトがVM作成などを⾏います。

Slide 12

Slide 12 text

「さくらのVPS」の運⽤

Slide 13

Slide 13 text

• サービスを安定的に提供し続けること = 監視を⾏い障害が発⽣したら対応する・発⽣しにくいようにする • サービス品質の継続的向上 = パフォーマンス改善・機能追加など運⽤「さくらのVPS」では開発と運⽤には明確な線引きはなく、メンバーそれぞれの得意分野で開発・運⽤を⾏っているサービスを安定して提供し続けるのは当然⼤事ですが、お客様に選ばれ使い続けていただくためには、サービスを維持するだけでなく改善も必要で、開発も運⽤に含まれると考えています。

Slide 14

Slide 14 text

サービスチームお客様対応部隊さくらのVPSの運⽤体制 24/365オペレーション部隊 DCOP 現地・物理作業 SVOP ホストアラート対応・メンテ VPSインフラ担当 VPS-API担当 NWOP NWアラート対応・メンテ対応依頼・共同対処エスカレーション CR カスタマーサポート VPS NW担当 24時間有⼈でサービスを横断して対応を⾏う体制があり、⼿順書と権限を渡して対応を依頼し、対応しきれないものに関してはエスカレーションを⾏ってもらってい、共同で対処します。

Slide 15

Slide 15 text

機械は必ず壊れる • 特に回転系 (HDD / PSUなど) 障害と計画メンテナンス • ホットスワップのパーツはダウンタイムなしで交換 • 障害の予兆を検知し、計画メンテナンスを⾏う⼀部ホットスワップにより交換できないものもありますが、NICなど冗⻑化しているパーツであれば⽚側が動作している間にメンテナンスを計画しホストサーバを停⽌して交換します。

Slide 16

Slide 16 text

HW交換メンテナンスの流れ計画メンテナンス対応例メンテ情報掲載シャットダウン筐体交換復旧確認 • アラート等を検知 • メンテナンス情報の掲載と対象ユーザへのメール送信（１〜２週間前） • VMの状態保存とホストサーバのシャットダウン • 予備機とディスク以外の筐体を交換 • ホスト正常性を確認し VMの状態を復元 • VMの疎通確認所要時間3時間程度：通常は深夜帯に実施予備機は障害機と同スペックのものを複数⽤意しており、対応するスロットのディスクを差し替え、障害機が設置してあったラックの位置にマウントし結線する運⽤を⾏っております。

Slide 17

Slide 17 text

• 崩れたRAIDは再作成するしかない • バックアップから復旧するのに時間がかかる • CCを定期的に実⾏し不整合を検出・修正する • RAID/SMARTエラー値をホスト・スロット毎に追跡して予防交換ストレージ障害は影響が⼤きい CC(Consistency Check) = 仮想ドライブのデータ整合性をチェック修正するRAIDカードの機能 CCを定期的に実⾏していても、不良スロットの影響により動作が不安定になることがあるので、 SMARTやRAIDカードのエラー値をチェックして、状況次第で予防交換を⾏います。

Slide 18

Slide 18 text

0 4 1 2 3 5 RAID多重障害事例 • RAID10のホスト • Slot0にてエラー値の上昇を確認 • 通常通りSlot0の交換を⼿配 • CCを⼿動実⾏

Slide 19

Slide 19 text

0 4 1 2 3 5 RAID多重障害事例 ❌ ⚠ • RAID10のホスト • Slot0にてエラー値の上昇を確認 • 通常通りSlot0の交換を⼿配 • CCを⼿動実⾏ • Slot1が脱落 • Slot0をリビルドソースとすると失敗する可能性アリ

Slide 20

Slide 20 text

0 4 1 2 3 5 • RAID10のホスト • Slot0にてエラー値の上昇を確認 • 通常通りSlot0の交換を⼿配 • CCを⼿動実⾏ • Slot1が脱落 • Slot0をリビルドソースとすると失敗する可能性アリ RAID多重障害事例 ⚠ 緊急メンテナンスを実施し、 VMを別ホストに退避 Slot1をこのまま交換してしまうとVMのデータ消失に繋がる恐れがあったので、やむを得ず緊急で深夜帯にVMの移設を⾏いました。

Slide 21

Slide 21 text

0 4 1 2 3 5 RAID多重障害事例 VM移設後 • slot1を交換(3⽇後) →リビルド →完⾛ • slot0が脱落(22⽇後) →交換 →リビルド →完⾛ RAIDの状態は元に戻りましたが、データが破損し⻑時間のダウンタイムが発⽣するよりはよかったと考えています。このように最悪の事態を回避するために緊急メンテナンスを⾏うこともあります。

Slide 22

Slide 22 text

• ユーザーからの問い合わせ対応 • 障害エスカレーション対応 • ベンダーとの保守の調整 • ⽇常的なメンテナンス • ⼤規模なメンテナンス • Abuse対応 • 運⽤・サービス改善 VPSインフラメンバーの⽇常

Slide 23

Slide 23 text

• ユーザーからの問い合わせ対応 • 障害エスカレーション対応 • ベンダーとの保守の調整 • ⽇常的なメンテナンス • ⼤規模なメンテナンス • Abuse対応 • 運⽤・サービス改善 VPSインフラメンバーの⽇常「⽇常的なメンテナンス」についてはディスクの予防交換などが該当します。

Slide 24

Slide 24 text

ユーザーからの問い合わせ対応 VPSインフラメンバーの⽇常① • ホストサーバに原因がある場合 • 同⼀ホスト収容の他のVMの影響である場合 • VM内部の問題と思わしき場合障害が発覚した場合は障害情報の掲載と対応 VPSが重たい VPSに疎通がない VPSが起動しない VNCコンソールに接続できない切り分けて対応

Slide 25

Slide 25 text

• 故障率の上昇 • 保守費の⾼騰 • 収容率の低下⼤規模なメンテナンス VPSインフラメンバーの⽇常② より新しく⾼性能なサーバにリプレース古い機材を使い続けると・・・通常のマイグレーション： 1VMあたり数⼗分〜数時間のサービス断 x 数⼗〜数百VM ⼀⻫にデータ同期と切り替えを⾏い、サービス断を最⼩限に抑えつつ効率的にマイグレーション例）機材⽼朽化メンテナンス BIOSやRAIDカードのファームウェアを更新する作業や脆弱性対応なども⼤規模なメンテナンスに⼊ると思いますが、ここ最近は機材⽼朽化メンテナンスに注⼒しているのでそれについて話します。

Slide 26

Slide 26 text

論理移設メンテナンス(DRBD挟み込み) VM ストレージ VM • VMをシャットダウン • DRBDをセットアップ • LVMのデバイスを切り替え • VMを起動 • VM起動後の確認 DRBD 挟み込み VM VM DRBD = ホスト間でブロックデバイスの同期・複製ができるソフトウェア VPSインフラメンバーの⽇常② - ⼤規模なメンテナンスストレージ DRBDという、HAなどでブロックデバイスの同期に使われるソフトウェアを、VMのIOを⼀度⽌めて VMのストレージ領域であるLVと、ホストサーバのストレージの間に挟み込みます。

Slide 27

Slide 27 text

論理移設メンテナンス(VMデータ同期) DRBD データ同期 VM VM VPSインフラメンバーの⽇常② - ⼤規模なメンテナンスストレージ DRBD • DRBD⼊り新ホストを構築 • 新旧ホストを接続 • データの同期 VM ストレージ VM DRBD ⼀度挟み込んでしまえば、VMを停⽌することなくVMデータの同期を開始できます。右側のDRBDデバイスはもう⼀つの旧ホストから⼊ってくるVMの領域になります。

Slide 28

Slide 28 text

• VM定義データの移⾏ • 旧ホストでVMをシャットダウン • LVMを切り替え • 新ホストでVMを起動 • VM起動後の確認ストレージ VM VM VM VM 論理移設メンテナンス(論理切り替え) VPSインフラメンバーの⽇常② - ⼤規模なメンテナンス同期された状態で旧ホストのVMをシャットダウンしてIOを停⽌すると、新ホストにも旧ホストと同じ VMデータが存在することになります。この状態で新ホストでDRBDを外しVMを起動します。

Slide 29

Slide 29 text

• 「さくらのVPS」は独⾃実装で⼯夫することにより、コストを下げリーズナブルにサービスを提供できている。 • サービス開始から約10年が経過し、様々なノウハウを培ってきた⼀⽅、運⽤上の課題が⾒えてきた。 • 今後は省⼒化・⾃動化を推進し、運⽤の負荷を低減するとともによりよいサービスづくりに注⼒していきたい。まとめ

Slide 30

Slide 30 text

Slide 31

Slide 31 text

おまけ：運⽤・サービス改善時間があったのでVPSインフラメンバーの⽇常③「運⽤・サービス改善」についてお話します。

Slide 32

Slide 32 text

RAIDアラートの対応の流れ(従来) • SSHで対象ホストにログイン→コマンドでスロットの特定 • 対象ホストの設置位置・保守⽤ログなどを取得しメールで交換依頼 • 現地で保守⽤ディスクと交換→⾃動でリビルド開始 • SSHで対象ホストにログイン→リビルド開始を確認アラート検知交換対象特定ディスク交換リビルド確認「⼿順があるし⾃動化できそう」 VPSインフラメンバーの⽇常③ - 運⽤・サービス改善これはまだ実験中で本番投⼊していない取り組みなんですが、アラートを検知してから復旧するまで、有⼈によるオペレーション多いと実際に対応しながら思った事がありまして、

Slide 33

Slide 33 text

RAIDアラートの対応の流れ(⾃動化) • アラートスクリプト内部で交換対象を特定 • 必要情報を収集し依頼チケット作成＆Slack通知 • 現地で保守⽤ディスクと交換→⾃動でリビルド開始 • SSHで対象ホストにログイン→リビルド開始を確認ディスク交換以外の部分は監視サーバに設置するスクリプトで実⾏！ →年間数百⼈時の⼯数削減アラート検知交換依頼・通知ディスク交換リビルド確認 VPSインフラメンバーの⽇常③ - 運⽤・サービス改善監視の仕組みを⾒直し、スクリプトにオペレーションの⼀部を⾏わせることで省⼒化ができます。運⽤者の負荷が減って、サービスの改善に繋がるようなことを今後はもっとやりたいと思っています。