More Related Content Similar to 【デブサミ関西B4】 壮絶!さくらのレンタルサーバ構築・運用の舞台裏 (20) More from Developers Summit (20) 【デブサミ関西B4】 壮絶!さくらのレンタルサーバ構築・運用の舞台裏4. (C)Copyright 1996-2015 SAKURA Internet Inc.
• 事業者様向けにさくらのレンタルサーバをご提供
• 事業者様は弊社レンタルサーバをエンドユーザ
様にご提供
• サービスの運用/保守は弊社でサポート
• アカウント一括登録機能など高機能なコンパネ
を用意しました
• 高速なサービスのご提供が可能となっています
さくらのレンタルサーバ リセールサービス
9. (C)Copyright 1996-2015 SAKURA Internet Inc.
• 7月中頃デブサミで発表してくれと依頼される
• 以前弊社イベント(さくらの夕べ)で発表した
経験があったため
• 発表タイトルは自分で決めてねと言われる
• 「さくらのレンタルサーバ運用の現場」
でお願いしますと伝える
発表タイトルが決まった経緯
31. (C)Copyright 1996-2015 SAKURA Internet Inc.
• 手順書の書き方が人によって異なる
– レビューがしづらい
• デプロイ毎に同じような手順書を書く必要がある
– 無駄な工数の発生
• listファイルへの記述漏れ&不要な記述
– インシデントの発生
• デプロイに失敗したホストが分かりづらい
– 作業漏れの誘発
以前の方法における問題点
36. (C)Copyright 1996-2015 SAKURA Internet Inc.
• masterブランチからデプロイ用にブランチ切る
• デプロイ作業をAnsibleのplaybookとして記述
現在はどのように行っているか
$ git checkout –b mainte/hoge
39. (C)Copyright 1996-2015 SAKURA Internet Inc.
• レビューをして問題がなければ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
40. (C)Copyright 1996-2015 SAKURA Internet Inc.
• Gitリポジトリを見れば誰が/何時/何を/どの
ホストにデプロイしたのか分かる
– 作業履歴の検索性向上
• 同じような作業をplaybookとして使い回せる
– 無駄な工数の低減
• playbookは単なるyamlなので作業者による記述
方法のブレが少ない
– レビューしやすい
現在はどのように行っているか
41. (C)Copyright 1996-2015 SAKURA Internet Inc.
• デプロイに失敗したホストはretryファイルに
記述してくれる
– 作業漏れの防止
• 並列実行もしてくれる(forksオプション)
– デプロイ時間も申し分ない
現在はどのように行っているか
42. (C)Copyright 1996-2015 SAKURA Internet Inc.
• Dynamic Inventoryを使用することでデプロイ
毎に対象ホストを記述したファイルを用意する
必要がなくなった
現在はどのように行っているか
$ ansible-playbook -i ./bin/hosts.sh site.yml
43. (C)Copyright 1996-2015 SAKURA Internet Inc.
• -i オプションにplaybookの対象ホストを特定の
形式のJSONで返すスクリプトを指定
• その形式でJSON返せば言語は何でもOK
• サーバの役割&環境毎にグルーピングする
– バックアップサーバ/DBサーバ/ホストサーバ/etc
– production/staging
Dynamic Inventory
44. (C)Copyright 1996-2015 SAKURA Internet Inc.
• _meta属性のhostvarsでホスト固有の設定を
入れる
– pythonのパス指定している
– FreeBSD/Linux混在環境のため
• これを記述しないとホスト毎に--hostつきで
実行されてしまい遅すぎて使いものにならない
Dynamic Inventory
47. (C)Copyright 1996-2015 SAKURA Internet Inc.
• Ansibleはサーバを「あるべき状態」にしてくれる
• しかし何が「あるべき状態」か判断してくれない
– ファイルのパーミッション間違えても間違った状態を
「あるべき状態」と判断してしまう
• なので作業ミス防止のため使っている
Serverspecを使う理由
57. (C)Copyright 1996-2015 SAKURA Internet Inc.
• git-cvsimport 使って変換する
• 踏み台サーバ経由でcvsサーバにアクセス
するのでCVS_RSHでsshのラッパースクリプト
指定する
CVSからGitへ
#!/bin/sh
target=“$*”
ssh -i <priv-key> -tt hoge “sudo ssh $target”
58. (C)Copyright 1996-2015 SAKURA Internet Inc.
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>
59. (C)Copyright 1996-2015 SAKURA Internet Inc.
• このままだとcommitログがAuthor: cvs <cvs>
なので変換する必要がある
• 幸いCVSのcommitログにはby <user> と書く
習慣があったのでそれを利用する
• 変換にはgit-filter-branchを使って一括
で変換する
CVSからGitへ
60. (C)Copyright 1996-2015 SAKURA Internet Inc.
• --commit-filter commitの書き換え
• GIT_AUTHOR_(NAME|EMAIL) commitした人
• git-commit-tree 新しいcommitオブジェクト作る
CVSからGitへ
61. (C)Copyright 1996-2015 SAKURA Internet Inc.
• commitログがUTF-8で書かれてないものを
git-rebaseで変換
• commitログ変換したいだけなのでreword
• 手動で行った。。。
• 刺し身たんぽぽ
CVSからGitへ
$ git rebase -i HEAD~n
64. (C)Copyright 1996-2015 SAKURA Internet Inc.
• DBサーバ(MySQL)でInnoDBのクラッシュが発生
• 外部からSQL実行できるか/mysqldプロセスが
動作しているかという点は監視できていた
• すぐにCrash Recoverするのでアラートが発砲
しないため障害に気付けなかった
• 対応が遅れるとmysqldプロセス自体が起動しない
などの障害に至る
以前はどのように行っていたか
67. (C)Copyright 1996-2015 SAKURA Internet Inc.
• InnoDBのクラッシュが発生する原因は多岐に渡る
• ストレージ,H/W,データベースのデータ自体
• そのためMySQLのerrorログにCrashが発生した
と記述されたことを監視する
• ログ監視はZabbixで行う
現在はどのように行っているか
InnoDB: Database was not shut down normally!
74. (C)Copyright 1996-2015 SAKURA Internet Inc.
• ファシリティ部門にラック確保依頼を出す
• データベース残数を調査してサーバが不足する
ことが無いようにする必要がある
• 現在のところ1日約100データベース消費される
• 1ラック約3ヶ月もつ
• 適したラックを選定する必要がある
• 現在のサーバは1Uサーバなのでコールド/ホット
にする必要がある(空調に区別がある場合)
ラック確保
75. (C)Copyright 1996-2015 SAKURA Internet Inc.
ラックの利用状況の例
・コールドアイル
冷たい風が出てくるとこ
ろ
・ホットアイル
サーバから排出された温
まった風が出てくるとこ
ろ
・1Uサーバの場合前面か
ら冷たい風を受けて、背
面から温まった風を出す
76. (C)Copyright 1996-2015 SAKURA Internet Inc.
• 物流を担当している部署へ確保依頼出す
• 不足していれば発注も行う
• 現在の構成では1ラックにつき
– 1Uサーバ x 12
– SSD/HDD x 30
– メモリ 8G x 158
– WAN側スイッチ x 1
– LAN側スイッチ x 1
ラック確保 -> 機材確保
79. (C)Copyright 1996-2015 SAKURA Internet Inc.
• WAN/LAN用スイッチの設定
• ネットワーク担当部署に依頼
• WAN側スイッチはエッジルータに接続
• LAN側スイッチはIPMI接続に使用するために使う
• 使用可能なIPの割り出しなどもお願いする
• 割り出された範囲からIP選んでDNS登録
ラック工事 -> ネットワーク設定
81. (C)Copyright 1996-2015 SAKURA Internet Inc.
• データセンターチームでPXEブート&セット
アップスクリプト実行し最低限の設定実施
• ラックに設置してパッケージスクリプトの適用
• 構築後の動作検証
• 各種細々とした登録作業
– 監視/ラック図/リソースグラフ/etc
• 完成
ネットワーク設定 -> サーバ構築
84. (C)Copyright 1996-2015 SAKURA Internet Inc.
• 構築手順書見ながらサーバにsshで入って
コマンドぽちぽち打って構築する
– 10台前後とはいえ時間かかりすぎる
– 作業ミスの誘発
• 不要/非効率な各種サーバへの登録作業
– 大昔に作ったリソースグラフへの登録など
– 運用/CS部門に聞いても誰も使ってない。。。
– 監視サーバへの登録手動で行っている
以前はどのように行っていたか
87. (C)Copyright 1996-2015 SAKURA Internet Inc.
• あえてsshを禁止することでサーバ内オペ
レーションせず効率的なサーバ構築を目指す
• 手順書をAnsible化
• 検証作業もServerspec化
– 外部からのアクセス検証にはまだシェルを使ってる
• 監視サーバ(Zabbix)への登録はZabbix APIを利用
• リソースグラフはZabbixのスクリーン機能使う
現在はどのように行っているか
89. (C)Copyright 1996-2015 SAKURA Internet Inc.
• リソースグラフを複数サーバ間で比較できる機能
• 誰も使ってなかったグラフサーバへの代替
として利用中
• 障害対応時などに同じ構成のサーバとリソースを
比較することで障害原因の特定に役立てている
• サーバの傾向などの分析にも利用中
Zabbix Screen
91. (C)Copyright 1996-2015 SAKURA Internet Inc.
• Zabbix Screenの登録もAPI利用
– 今のところXML作ってimportしてる。。。
– Ansibleの2.xからZabbix API叩けるようなので検証中
Zabbix Screen
93. (C)Copyright 1996-2015 SAKURA Internet Inc.
• 歴史あるサービスは時代に追従する必要がある
• 放置しておくととてもツラいことになる
• 最初からモダンなインフラ環境がそろっている
のもいいけど、どうやって作り変えていくかと
考えていくことに楽しさがある
• 若干エモいですが割と今は仕事が楽しいです
まとめ