【デブサミ関西B4】壮絶！さくらのレンタルサーバ構築・運用の舞台裏

(C)Copyright 1996-2015 SAKURA Internet Inc.
壮絶！さくらのレンタルサーバ構築・運用の舞台裏
Developer Summit 2015 KANSAI

• 中山幸治 @knakayama
• 新卒で入社して3年目
• インターネットサービス事業部
• 主にレンタルサーバの運用を担当
自己紹介

さくらのレンタル
サーバリセール
サービス始めました
宣伝

• 事業者様向けにさくらのレンタルサーバをご提供
• 事業者様は弊社レンタルサーバをエンドユーザ
様にご提供
• サービスの運用/保守は弊社でサポート
• アカウント一括登録機能など高機能なコンパネ
を用意しました
• 高速なサービスのご提供が可能となっています
さくらのレンタルサーバリセールサービス

ぜひご活用
下さい
さくらのレンタルサーバリセールサービス

今日の発表
タイトル
発表タイトルが決まった経緯

壮絶！さくらの
レンタルサーバ
構築・運用の舞台裏

煽り過ぎでは

• 7月中頃デブサミで発表してくれと依頼される
• 以前弊社イベント(さくらの夕べ)で発表した
経験があったため
• 発表タイトルは自分で決めてねと言われる
• 「さくらのレンタルサーバ運用の現場」
でお願いしますと伝える

• タイトルが大げさだったのでネタ系で挑む
• スベる
• 心に傷を負う
• 無難なタイトルにしたい ← 今ここ

ええ。。。

ハードルを
上げてみた

やったぜ

Kさんありがとう
ございます！

前置きは
以上です

• デプロイ
• バージョン管理
• 監視
• 構築
アジェンダ

歴史のあるサービス
の場合必ず技術的
負債が発生する
各アジェンダの流れ

さくらのレンタル
サーバはお陰様で
生誕11年

11年サービスを続けていると
当時は最適なアーキテクチャ
であっても時が経過する内に
問題点が出てくる

いわゆるBlue-Greenデプロ
イメントのように既存サービ
スをそっくり作り変えるよう
なことは現実的に難しい

そのため既存サービス
を時代に合わせて進化
させていく必要がある

なので各アジェンダ
は以下の流れで発表
します

以前はどのように
行っていたか
現在はどのように
行っているか

デプロイ
デプロイ

以前はどのよう
に行っていたか
デプロイ

以前はどのように行っていたか
$ cat list | xargs –P n ssh

• listファイルに対象のホスト名を記述
• xargsの-Pオプションで並列にssh
• デプロイ毎に手順書を作る
• 作成した手順書をレビューして作業実施

• 手順書の書き方が人によって異なる
– レビューがしづらい
• デプロイ毎に同じような手順書を書く必要がある
– 無駄な工数の発生
• listファイルへの記述漏れ＆不要な記述
– インシデントの発生
• デプロイに失敗したホストが分かりづらい
– 作業漏れの誘発
以前の方法における問題点

• 誰がいつ/どのホストに/何を実施したのか
把握しづらい
– 作業履歴が辿りづらい

現在はどのよう
に行っているか
デプロイ

Ansible
+
Serverspec
+
GitHub Flow
現在はどのように行っているか

• masterブランチからデプロイ用にブランチ切る
• デプロイ作業をAnsibleのplaybookとして記述
$ git checkout –b mainte/hoge

• Serverspecでテストコード記述

• デプロイの作成が終わったらPull Request

• レビューをして問題がなければmasterにmerge
• ansible-playbookコマンドでデプロイ
• Serverspecでデプロイ内容確認
$ ansible-playbook -i ./bin/hosts.sh site.yml
--limit bar
$ git merge --no-ff mainte/foo
$ git push –u origin master
$ rake serverspec:baz -t -j n -m

• Gitリポジトリを見れば誰が/何時/何を/どの
ホストにデプロイしたのか分かる
– 作業履歴の検索性向上
• 同じような作業をplaybookとして使い回せる
– 無駄な工数の低減
• playbookは単なるyamlなので作業者による記述
方法のブレが少ない
– レビューしやすい

• デプロイに失敗したホストはretryファイルに
記述してくれる
– 作業漏れの防止
• 並列実行もしてくれる(forksオプション)
– デプロイ時間も申し分ない

• Dynamic Inventoryを使用することでデプロイ
毎に対象ホストを記述したファイルを用意する
必要がなくなった
$ ansible-playbook -i ./bin/hosts.sh site.yml

• -i オプションにplaybookの対象ホストを特定の
形式のJSONで返すスクリプトを指定
• その形式でJSON返せば言語は何でもOK
• サーバの役割&環境毎にグルーピングする
– バックアップサーバ/DBサーバ/ホストサーバ/etc
– production/staging
Dynamic Inventory

• _meta属性のhostvarsでホスト固有の設定を
入れる
– pythonのパス指定している
– FreeBSD/Linux混在環境のため
• これを記述しないとホスト毎に--hostつきで
実行されてしまい遅すぎて使いものにならない
Dynamic Inventory

Dynamic Inventory

Serverspecを使う理由
テストコードを書く大前提として、
利用しているサーバ構成管理ツールを
信頼し、インフラコードを書く自分や
他人を信頼しないという立場を取りま
しょう。

• Ansibleはサーバを「あるべき状態」にしてくれる
• しかし何が「あるべき状態」か判断してくれない
– ファイルのパーミッション間違えても間違った状態を
「あるべき状態」と判断してしまう
• なので作業ミス防止のため使っている
Serverspecを使う理由

バージョン管理

CVS

ツラい

ツラさは説明しなく
ても分かると思うの
で割愛します

Git

普通ですね
Git

CVSからGitへの
移行方法
CVSからGitへ

• git-cvsimport 使って変換する
• 踏み台サーバ経由でcvsサーバにアクセス
するのでCVS_RSHでsshのラッパースクリプト
指定する
CVSからGitへ
#!/bin/sh
target=“$*”
ssh -i <priv-key> -tt hoge “sudo ssh $target”

CVSからGitへ
• -v verbosity
• -a imports all commits
• -d cvs root
• -C git repo
$ export CVS_RSH=“/path/to/cvssh.sh”
$ git cvsimport -v -a -
d :ext:cvs@hoge:/path/to/cvsroot -C <git-
repo> <cvs-repo>

• このままだとcommitログがAuthor: cvs <cvs>
なので変換する必要がある
• 幸いCVSのcommitログにはby <user> と書く
習慣があったのでそれを利用する
• 変換にはgit-filter-branchを使って一括
で変換する
CVSからGitへ

• --commit-filter commitの書き換え
• GIT_AUTHOR_(NAME|EMAIL) commitした人
• git-commit-tree 新しいcommitオブジェクト作る
CVSからGitへ

• commitログがUTF-8で書かれてないものを
git-rebaseで変換
• commitログ変換したいだけなのでreword
• 手動で行った。。。
• 刺し身たんぽぽ
CVSからGitへ
$ git rebase -i HEAD~n

監視
監視

監視

• DBサーバ(MySQL)でInnoDBのクラッシュが発生
• 外部からSQL実行できるか/mysqldプロセスが
動作しているかという点は監視できていた
• すぐにCrash Recoverするのでアラートが発砲
しないため障害に気付けなかった
• 対応が遅れるとmysqldプロセス自体が起動しない
などの障害に至る

監視

ログ監視

• InnoDBのクラッシュが発生する原因は多岐に渡る
• ストレージ,H/W,データベースのデータ自体
• そのためMySQLのerrorログにCrashが発生した
と記述されたことを監視する
• ログ監視はZabbixで行う
InnoDB: Database was not shut down normally!

• logrt ローテーションされるlogを監視
• regexp 指定した文字列が出力されているか

構築
構築

データベース

• コンパネからボタンをポチポチクリックする
だけですぐに使える
• MySQL
• バージョンは（4.0/5.1/5.5)
• phpmyadminも使える
レンサバデータベース

構築フロー
構築の流れ

• ラック確保
• 機材確保
• ラック工事
• ネットワーク設定
• サーバ構築
構築フロー

• ファシリティ部門にラック確保依頼を出す
• データベース残数を調査してサーバが不足する
ことが無いようにする必要がある
• 現在のところ1日約100データベース消費される
• 1ラック約3ヶ月もつ
• 適したラックを選定する必要がある
• 現在のサーバは1Uサーバなのでコールド/ホット
にする必要がある(空調に区別がある場合)
ラック確保

ラックの利用状況の例
・コールドアイル
冷たい風が出てくるとこ
ろ
・ホットアイル
サーバから排出された温
まった風が出てくるとこ
ろ
・1Uサーバの場合前面か
ら冷たい風を受けて、背
面から温まった風を出す

• 物流を担当している部署へ確保依頼出す
• 不足していれば発注も行う
• 現在の構成では1ラックにつき
– 1Uサーバ x 12
– SSD/HDD x 30
– メモリ 8G x 158
– WAN側スイッチ x 1
– LAN側スイッチ x 1
ラック確保 -> 機材確保

• ラックが使用できる状態にする作業
• データセンターチームに依頼を出す
• ゴミ掃除
• マウントレール取り付け
• 電源タップ取り付け
• etc
機材確保 -> ラック工事

こんな感じでデータセンター
チームの方々に作って
もらいます
ラック図

• WAN/LAN用スイッチの設定
• ネットワーク担当部署に依頼
• WAN側スイッチはエッジルータに接続
• LAN側スイッチはIPMI接続に使用するために使う
• 使用可能なIPの割り出しなどもお願いする
• 割り出された範囲からIP選んでDNS登録
ラック工事 -> ネットワーク設定

ネットワーク構成

• データセンターチームでPXEブート&セット
アップスクリプト実行し最低限の設定実施
• ラックに設置してパッケージスクリプトの適用
• 構築後の動作検証
• 各種細々とした登録作業
– 監視/ラック図/リソースグラフ/etc
• 完成
ネットワーク設定 -> サーバ構築

構築

構築手順書

• 構築手順書見ながらサーバにsshで入って
コマンドぽちぽち打って構築する
– 10台前後とはいえ時間かかりすぎる
– 作業ミスの誘発
• 不要/非効率な各種サーバへの登録作業
– 大昔に作ったリソースグラフへの登録など
– 運用/CS部門に聞いても誰も使ってない。。。
– 監視サーバへの登録手動で行っている

構築

SSH禁止

• あえてsshを禁止することでサーバ内オペ
レーションせず効率的なサーバ構築を目指す
• 手順書をAnsible化
• 検証作業もServerspec化
– 外部からのアクセス検証にはまだシェルを使ってる
• 監視サーバ(Zabbix)への登録はZabbix APIを利用
• リソースグラフはZabbixのスクリーン機能使う

• 今のところRubyのzabbixapiというモジュール
を利用している
Zabbix API

• リソースグラフを複数サーバ間で比較できる機能
• 誰も使ってなかったグラフサーバへの代替
として利用中
• 障害対応時などに同じ構成のサーバとリソースを
比較することで障害原因の特定に役立てている
• サーバの傾向などの分析にも利用中
Zabbix Screen

Zabbix Screen

• Zabbix Screenの登録もAPI利用
– 今のところXML作ってimportしてる。。。
– Ansibleの2.xからZabbix API叩けるようなので検証中
Zabbix Screen

• 歴史あるサービスは時代に追従する必要がある
• 放置しておくととてもツラいことになる
• 最初からモダンなインフラ環境がそろっている
のもいいけど、どうやって作り変えていくかと
考えていくことに楽しさがある
• 若干エモいですが割と今は仕事が楽しいです
まとめ

さくらではモダンなインフラ構築
方法を知りつつ歴史あるサービス
にどう適用していくかを考え出せ
るエンジニアを募集中です！
一緒に改善していきませんか？
求人情報です

ご静聴ありがとう
ございました
終わり

【デブサミ関西B4】 壮絶！さくらのレンタルサーバ構築・運用の舞台裏

More Related Content

What's hot

Viewers also liked

Similar to 【デブサミ関西B4】 壮絶！さくらのレンタルサーバ構築・運用の舞台裏

More from Developers Summit