【デブサミ関西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


Zabbix Screen


• 歴史あるサービスは時代に追従する必要がある

• 放置しておくととてもツラいことになる

• 最初からモダンなインフラ環境がそろっている

のもいいけど、どうやって作り変えていくかと

考えていくことに楽しさがある

• 若干エモいですが割と今は仕事が楽しいです

まとめ


さくらではモダンなインフラ構築

方法を知りつつ歴史あるサービス

にどう適用していくかを考え出せ

るエンジニアを募集中です！

一緒に改善していきませんか？

求人情報です


ご静聴ありがとう

ございました

終わり

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

Technology

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