Upload
developers-summit
View
1.291
Download
0
Embed Size (px)
Citation preview
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 中山 幸治 @knakayama
• 新卒で入社して3年目
• インターネットサービス事業部
• 主にレンタルサーバの運用を担当
自己紹介
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 事業者様向けにさくらのレンタルサーバをご提供
• 事業者様は弊社レンタルサーバをエンドユーザ
様にご提供
• サービスの運用/保守は弊社でサポート
• アカウント一括登録機能など高機能なコンパネ
を用意しました
• 高速なサービスのご提供が可能となっています
さくらのレンタルサーバ リセールサービス
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 7月中頃デブサミで発表してくれと依頼される
• 以前弊社イベント(さくらの夕べ)で発表した
経験があったため
• 発表タイトルは自分で決めてねと言われる
• 「さくらのレンタルサーバ運用の現場」
でお願いしますと伝える
発表タイトルが決まった経緯
(C)Copyright 1996-2015 SAKURA Internet Inc.
• タイトルが大げさだったのでネタ系で挑む
• スベる
• 心に傷を負う
• 無難なタイトルにしたい ← 今ここ
発表タイトルが決まった経緯
(C)Copyright 1996-2015 SAKURA Internet Inc.
11年サービスを続けていると
当時は最適なアーキテクチャ
であっても時が経過する内に
問題点が出てくる
各アジェンダの流れ
(C)Copyright 1996-2015 SAKURA Internet Inc.
いわゆるBlue-Greenデプロ
イメントのように既存サービ
スをそっくり作り変えるよう
なことは現実的に難しい
各アジェンダの流れ
(C)Copyright 1996-2015 SAKURA Internet Inc.
• listファイルに対象のホスト名を記述
• xargsの-Pオプションで並列にssh
• デプロイ毎に手順書を作る
• 作成した手順書をレビューして作業実施
以前はどのように行っていたか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 手順書の書き方が人によって異なる– レビューがしづらい
• デプロイ毎に同じような手順書を書く必要がある– 無駄な工数の発生
• listファイルへの記述漏れ&不要な記述– インシデントの発生
• デプロイに失敗したホストが分かりづらい– 作業漏れの誘発
以前の方法における問題点
(C)Copyright 1996-2015 SAKURA Internet Inc.
• masterブランチからデプロイ用にブランチ切る
• デプロイ作業をAnsibleのplaybookとして記述
現在はどのように行っているか
$ git checkout –b mainte/hoge
(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
(C)Copyright 1996-2015 SAKURA Internet Inc.
• Gitリポジトリを見れば誰が/何時/何を/どの
ホストにデプロイしたのか分かる– 作業履歴の検索性向上
• 同じような作業をplaybookとして使い回せる– 無駄な工数の低減
• playbookは単なるyamlなので作業者による記述
方法のブレが少ない– レビューしやすい
現在はどのように行っているか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• デプロイに失敗したホストはretryファイルに
記述してくれる
– 作業漏れの防止
• 並列実行もしてくれる(forksオプション)
– デプロイ時間も申し分ない
現在はどのように行っているか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• Dynamic Inventoryを使用することでデプロイ
毎に対象ホストを記述したファイルを用意する
必要がなくなった
現在はどのように行っているか
$ ansible-playbook -i ./bin/hosts.sh site.yml
(C)Copyright 1996-2015 SAKURA Internet Inc.
• -i オプションにplaybookの対象ホストを特定の
形式のJSONで返すスクリプトを指定
• その形式でJSON返せば言語は何でもOK
• サーバの役割&環境毎にグルーピングする
– バックアップサーバ/DBサーバ/ホストサーバ/etc
– production/staging
Dynamic Inventory
(C)Copyright 1996-2015 SAKURA Internet Inc.
• _meta属性のhostvarsでホスト固有の設定を
入れる
– pythonのパス指定している
– FreeBSD/Linux混在環境のため
• これを記述しないとホスト毎に--hostつきで
実行されてしまい遅すぎて使いものにならない
Dynamic Inventory
(C)Copyright 1996-2015 SAKURA Internet Inc.
Serverspecを使う理由
テストコードを書く大前提として、利用しているサーバ構成管理ツールを信頼し、インフラコードを書く自分や他人を信頼しないという立場を取りましょう。
(C)Copyright 1996-2015 SAKURA Internet Inc.
• Ansibleはサーバを「あるべき状態」にしてくれる
• しかし何が「あるべき状態」か判断してくれない
– ファイルのパーミッション間違えても間違った状態を
「あるべき状態」と判断してしまう
• なので作業ミス防止のため使っている
Serverspecを使う理由
(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”
(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>
(C)Copyright 1996-2015 SAKURA Internet Inc.
• このままだとcommitログがAuthor: cvs <cvs>
なので変換する必要がある
• 幸いCVSのcommitログにはby <user> と書く
習慣があったのでそれを利用する
• 変換にはgit-filter-branchを使って一括
で変換する
CVSからGitへ
(C)Copyright 1996-2015 SAKURA Internet Inc.
• --commit-filter commitの書き換え
• GIT_AUTHOR_(NAME|EMAIL) commitした人
• git-commit-tree 新しいcommitオブジェクト作る
CVSからGitへ
(C)Copyright 1996-2015 SAKURA Internet Inc.
• commitログがUTF-8で書かれてないものを
git-rebaseで変換
• commitログ変換したいだけなのでreword
• 手動で行った。。。
• 刺し身たんぽぽ
CVSからGitへ
$ git rebase -i HEAD~n
(C)Copyright 1996-2015 SAKURA Internet Inc.
• DBサーバ(MySQL)でInnoDBのクラッシュが発生
• 外部からSQL実行できるか/mysqldプロセスが
動作しているかという点は監視できていた
• すぐにCrash Recoverするのでアラートが発砲
しないため障害に気付けなかった
• 対応が遅れるとmysqldプロセス自体が起動しない
などの障害に至る
以前はどのように行っていたか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• InnoDBのクラッシュが発生する原因は多岐に渡る
• ストレージ,H/W,データベースのデータ自体
• そのためMySQLのerrorログにCrashが発生した
と記述されたことを監視する
• ログ監視はZabbixで行う
現在はどのように行っているか
InnoDB: Database was not shut down normally!
(C)Copyright 1996-2015 SAKURA Internet Inc.
• logrt ローテーションされるlogを監視
• regexp 指定した文字列が出力されているか
現在はどのように行っているか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• コンパネからボタンをポチポチクリックするだけですぐに使える
• MySQL
• バージョンは(4.0/5.1/5.5)
• phpmyadminも使える
レンサバデータベース
(C)Copyright 1996-2015 SAKURA Internet Inc.
• ファシリティ部門にラック確保依頼を出す
• データベース残数を調査してサーバが不足することが無いようにする必要がある
• 現在のところ1日約100データベース消費される
• 1ラック約3ヶ月もつ
• 適したラックを選定する必要がある
• 現在のサーバは1Uサーバなのでコールド/ホットにする必要がある(空調に区別がある場合)
ラック確保
(C)Copyright 1996-2015 SAKURA Internet Inc.
ラックの利用状況の例
・コールドアイル冷たい風が出てくるところ・ホットアイルサーバから排出された温まった風が出てくるところ・1Uサーバの場合前面から冷たい風を受けて、背面から温まった風を出す
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 物流を担当している部署へ確保依頼出す
• 不足していれば発注も行う
• 現在の構成では1ラックにつき
– 1Uサーバ x 12
– SSD/HDD x 30
– メモリ 8G x 158
– WAN側スイッチ x 1
– LAN側スイッチ x 1
ラック確保 -> 機材確保
(C)Copyright 1996-2015 SAKURA Internet Inc.
• ラックが使用できる状態にする作業
• データセンターチームに依頼を出す
• ゴミ掃除
• マウントレール取り付け
• 電源タップ取り付け
• etc
機材確保 -> ラック工事
(C)Copyright 1996-2015 SAKURA Internet Inc.
• WAN/LAN用スイッチの設定
• ネットワーク担当部署に依頼
• WAN側スイッチはエッジルータに接続
• LAN側スイッチはIPMI接続に使用するために使う
• 使用可能なIPの割り出しなどもお願いする
• 割り出された範囲からIP選んでDNS登録
ラック工事 -> ネットワーク設定
(C)Copyright 1996-2015 SAKURA Internet Inc.
• データセンターチームでPXEブート&セット
アップスクリプト実行し最低限の設定実施
• ラックに設置してパッケージスクリプトの適用
• 構築後の動作検証
• 各種細々とした登録作業
– 監視/ラック図/リソースグラフ/etc
• 完成
ネットワーク設定 -> サーバ構築
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 構築手順書見ながらサーバにsshで入って
コマンドぽちぽち打って構築する
– 10台前後とはいえ時間かかりすぎる
– 作業ミスの誘発
• 不要/非効率な各種サーバへの登録作業
– 大昔に作ったリソースグラフへの登録など
– 運用/CS部門に聞いても誰も使ってない。。。
– 監視サーバへの登録手動で行っている
以前はどのように行っていたか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• あえてsshを禁止することでサーバ内オペ
レーションせず効率的なサーバ構築を目指す
• 手順書をAnsible化
• 検証作業もServerspec化
– 外部からのアクセス検証にはまだシェルを使ってる
• 監視サーバ(Zabbix)への登録はZabbix APIを利用
• リソースグラフはZabbixのスクリーン機能使う
現在はどのように行っているか
(C)Copyright 1996-2015 SAKURA Internet Inc.
• リソースグラフを複数サーバ間で比較できる機能
• 誰も使ってなかったグラフサーバへの代替
として利用中
• 障害対応時などに同じ構成のサーバとリソースを
比較することで障害原因の特定に役立てている
• サーバの傾向などの分析にも利用中
Zabbix Screen
(C)Copyright 1996-2015 SAKURA Internet Inc.
• Zabbix Screenの登録もAPI利用
– 今のところXML作ってimportしてる。。。
– Ansibleの2.xからZabbix API叩けるようなので検証中
Zabbix Screen
(C)Copyright 1996-2015 SAKURA Internet Inc.
• 歴史あるサービスは時代に追従する必要がある
• 放置しておくととてもツラいことになる
• 最初からモダンなインフラ環境がそろっている
のもいいけど、どうやって作り変えていくかと
考えていくことに楽しさがある
• 若干エモいですが割と今は仕事が楽しいです
まとめ
(C)Copyright 1996-2015 SAKURA Internet Inc.
さくらではモダンなインフラ構築
方法を知りつつ歴史あるサービス
にどう適用していくかを考え出せ
るエンジニアを募集中です!
一緒に改善していきませんか?
求人情報です