MySQL Casual Talks vol.7で「Continuous Restoreへの道」を発表奴
タイトルの通りだけど
MySQL Casual Talks vol.7でお話してきた。
MySQLのbackupはみんな取ってると思うけどそのBackupって本当にRestore出来るのかなーという不安からRestoreを検証してくれる仕組みを作ってみたというお話
発表資料はこれ
実は発表の二日前にようやくちゃんと全部のjobが綺麗に動いたんだけど、
何故かその段階で、もう大丈夫っしょ！(・。・)となってしまい、
実際に全部のjobを連結させて一連の流れが見えるようになったのは、
なんと発表当日会場入りの30分前という体たらくっぷり。
なので、資料の途中に書いてある実際の運用ではとかのくだりは、あくまでもそういう予定である。
みたいなかんじになってしまった。なんか今思うと詐欺みたいだなｗ
発表にあたって
実は人前で何かを発表するみたいな経験に乏しく、
発表当日は緊張しすぎて雨に濡れた子犬みたいになってた。
発表までにカジュアルウォーター３本ぐらい空けてしまったし
あと緊張のあまり大阪弁で発表してしまい、
「バァーンってBackup取ってー」
「バァーンってinstance作ってー」
「バァーンってRestoreしてー」
「バァーンってRestoreのcheckしますー」
みたいな感じで擬音語を多発したことにより、
バァーンの人みたいな認知のされ方をしたのは今となってはいい思い出です。
謝辞的な
この場を借りて的なお話を。
まず@namikawaさん
引きこもりがちな僕に発表の機会を与えていただきありがとうございます。
とってもいい経験になったし、もっと外に出てアウトプットしていかなきゃなと思える一日でした。
あと、発表の後の開放感からお酒を飲み歩いてベロンベロンになってしまった僕の代わりに夜間の障害対応をしていただき本当にありがとうございました・・・:(；ﾞﾟ'ωﾟ'):
そして、発表練習＆内容の相談に付き合ってくださった@kuwa_twさん、@dblmktさん、@kakky_hさん、@nekoruriさん本当にありがとうございます、資料当てをしてなかったら多分会場で死体が出来上がってました。
特に@kuwa_twさんは資料にも出演していただき本当にありがとうございます＾＾
あと、発表の時に@oranieさんを壮絶にdisってしまいましたが
いつもお世話になっております、本当にありがとうございます＾＾；
おわり
最近の私のchef周りの事情
どうやら台風が来るらしい。
台風にえしゃこらされて頑張ってる雨の音を肴にビール飲みながらブログ書いてる。
台湾ビール旨い、そしてフラフラする
んでまぁ、
事務職をドロップアウトしてインフラ周りのお仕事に戻って二ヶ月ぐらい。
サーバ管理ツールとしてchefをまた使い始めた。
chef周りのテストとかの運用ってどうするべきなのかなーと悩んだりしているのだが、現状のところを纏めてみる。
どうしたもんかなー
使用しているツール
- chef-solo
- Berkshelf
- Vagrant
- sahara plugin
- serverspec
こんな感じ。
今まではchef-serverを主に使っていたのだが、
chef-serverじゃないといけない理由もないし、
触ってみたこと無いやっていうモチベーションでchef-soloを使い始めた。
Berkshelfも依存関係管理すんのメンドイな、とか使ったことねーなーというモチベーションで始めた。
てか、意外とcommunityのcookbook使ってるのよね、最近。
まぁ、使ってみたら意外と便利。
Vagrantは完全にテスト用。
後述するが別にvirtualboxでもワンチャン実現可能じゃね？って言われそうな用途で使用しているが、
sahara-pluginが便利でVagrantに落ち着いている。
serverspecは最近使い始めた。
chef適用後の構成管理もちゃんとしたいなと思い使い始めてみた。あと、chefで管理してない部分とかね。
LDAPやら、NICやら、
なんだけど、今のモダンなchef周りの運用ってどんな感じなのかしら。
ダレか教えてよ（適当
おまけ
今のchefのテスト環境を作るに至るまでに辿ってきたページ。
chef-solo - Chefを読んで実行するための全知識 - Qiita
Cookbookの管理を楽にするBerkshelfの使い方( ｰ`дｰ´)ｷﾘｯ とか。 - 256bitの殺人メニュー
saharaでVagrantの状態管理 - Qiita
serverspec インフラ層のテスト項目を考える | Ore no homepage
すごいわかりやすいです、いつもお世話になってます。
おまけ２
vagrantのメモ
chefのテストはvagrantを使用している。
社内用に少し改良したvagrantboxを使用しているがそれ以外は特別なことはしていない。
vagrant upする時にchef_soloを走らせてもいいのだが、chefのレシピのテストでいちいちup＆destroyを繰り返してたら時間がいくらあっても足りない、のでsahara_pluginを使って以下のように実行している。
# cd Vagrant用のディレクトリ # vagrant ssh-config >> ~/.ssh/config # sed -i 's/Host default/Host kakeru_vagrant/' ~/.ssh/config # cd hogehoge/chef-repo #chefのRepositoryに移動してね # knife solo prepare kakeru_vagrant # knife solo cook kakeru_vagrant # vagrant sandbox on # vagrant sandbox commit # テストしたいレシピを実行 vagrant sandbox rollback #初期状態へ
ssh kakeru_vagrantでノンパスログイン出来るように、ssh_configを書き換えておく。
その後に、どのサーバにも適用するようなbaseのレシピを適用した後にcommit。
そしたら、作成中のレシピを当てて、ミスったらrollback、修正して適用、rollbackみたいな感じ。
おまけ３
chef-soloがんばるぞ～って矢先にchef-soloやめっからって公式が言い出したみたい。
Chef-Soloはオワコンになりlocal modeが今後の主流になるとのこと - DQNEO起業日記
あらまぁ。
hoge
なんか日記みたいなブログやな・・・
出、出〜、homebrew-cask便利奴〜ｗｗｗｗｗ
なんというか、会社で所属チームが変わった。
そして、変わった瞬間に夏休み突入した。
今治なう。orionビール片手に記事を書いてる。
なんでまぁ、良い機会だからアウトプット増やす的な意味でちゃんとブログ再開する。
リハビリで手順書記事。
経緯
先日新卒の頃に自作したWindowsPCを墓地に伏せ、会社支給のMBPを召喚した。
障害対応用に前から持ってたMBAもそろそろクリーンインストールしたいなーとか考えてたから、
この際Macの初期のセットアップをちゃんと手順化したいなーとか思ってた。
そしたら、homebrew-caskなるものが便利という噂を聞いた。なんで使ってみた( `o´ )
https://github.com/caskroom/homebrew-cask
homebrew-caskってなんなん
homebrewみたいな感じでdmg形式のアプリも管理出来るらしい。
マジか！
導入
# homebrew入れてね $ ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)" # cask導入しよか。 $ brew tap caskroom/cask $ brew install brew-cask
cask使ってみる
Mou - Markdown editor for web developers, on Mac OS X 入れてみよか
# 入れたいアプリあるかなー $ brew cask search mou ==> Exact match mou ... # あった入れてみる $ brew cask install mou
これで入る、うげー便利。ゲロ吐いた
もっと管理する
brewfileで管理するとモットいいと思う
brewfileやで
こういうのを用意しといて
$ brew bundle Brewfile
すれば、上記のアプリが勝手に入る
うげー便利。鼻血吹いた
出、出〜、ELBSSL証明書奴〜ｗｗｗｗｗ
早くこの形式のタイトルから脱したい
【たまごELBSSLかける】
【ELBにSSL証明書かける】
とか。なんでもいいけど。
で、
ELBにオレオレ証明書を突っ込んだ時の手順書が掘り出されたのでブログにも書き残すことにした
今年はいっぱいブログ書くねん....('A`)
証明書的な云々
証明書ってなんなんとか、オレオレ証明書ってどうやってツクんの？とかは人様のブログを参考に・・・
オレオレ証明書をopensslで作る（詳細版） - ろば電子が詰まっている
CSRを作るまで
秘密鍵作るで〜
作る $ openssl genrsa -aes128 2048 > server.key Generating RSA private key, 2048 bit long modulus ...................+++ ...................................+++ e is 65537 (0x10001) Enter pass phrase: Verifying - Enter pass phrase: 確認 $ openssl rsa -text < server.key
ELBは秘密鍵にパスフレーズがついていたらエラるので、パスを削除してあげる
$ openssl rsa -in server.key -out server.key Enter pass phrase for server.key: writing RSA key
CSR作成
今回はオレオレ証明書でやってみるので、対話形式で色々聞かれるけど今回は全部空Enterでかまわないす。
もし、ちゃんと認証局に依頼をするならここでちゃんと記入してね
作る $ openssl req -new -key server.key > server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: 以下略 確認 $ openssl req -text < server.csr
証明書
自分で署名して証明書つくんで〜
作る $ openssl x509 -req -signkey server.key < server.csr > server.crt Signature ok subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd Getting Private key 確認 $ openssl x509 -text < server.crt
設定すんで〜
AWSのマネジメントコンソールから
create Load Balancerをぽちっと押して、
こうやって
こう！
Private Keyが $ cat server.key Public Key Certificateが $ cat server.crt
やで〜。
ほなな〜ノシ
出、出〜、mongos接続突然切奴〜ｗｗｗｗｗ
なんというか、ただの恥さらしブログになんだけど自戒のために残しておく。
なんかおかしい
ある日、本番稼働してない控えのmongosさんで変なエラーが出てアプリでもいっぱいエラーが出てきた。
なんかオカシイ。
エラー的には下記
Tue Nov 26 18:20:47.294 [conn88] Socket say send() errno:32 Broken pipe 10.10.10.10:27018 Tue Nov 26 18:20:47.294 [conn88] warning: problem while initially checking shard versions on RS01 :: caused by :: socket exception [SEND_ERROR] for 10.10.10.10:27018 Tue Nov 26 18:20:47.294 [conn88] DBException in process: socket exception [SEND_ERROR] for 10.10.10.10:27018
Broken pipe....?
mongos->mongodの接続が切れてる... ? _ ?
調べる
最初は単純にBroken pipeだからネットワーク的な問題かなと思い、
トラフィックが急にオチてたりethとかで変なエラーが出てないかを見たがそれっぽいものは特に何もナシ。
connectionsが頭打ちになってね？となり
そこ周りで調べてみることにした
mongodのプライマリシャードのconnectionsを確認してみる。
900ちょっとで停滞・・・？
実際にログインしてプロセス数を確認してみる
ec2-user@prd-mongod001(ip-10-10-10-10) ~ $ ps auxxx -L | grep mong | wc -l 931
設定値は？
$ ulimit -u 1024
ﾃﾞﾌｫﾙﾄ･･･(´ｪ`* ;;;)
すごくそれっぽい
作業
mongoさん優しい。ulimitの推奨値書いてた
http://docs.mongodb.org/manual/reference/ulimit/
ulimitの説明とかも書いてくれてるしなんて親切なの・・・
実際に、作業にはいる
vim /etc/security/limits.d/90-nproc.conf # Default limit for number of user's processes to prevent # accidental fork bombs. # See rhbz #432903 for reasoning. #* soft nproc 1024
こっちをコメントアウトして、
vim /etc/security/limits.conf 追記 root soft nofile 64000 root hard nofile 64000 root soft stack unlimited root hard stack unlimited root soft nproc 32000 root hard nproc 32000 * soft nofile 64000 * hard nofile 64000 * soft stack unlimited * soft nproc 32000 * hard nproc 32000
プロセス再起動
$ cat /proc/`pgrep mongo | head -1`/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size unlimited unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 32000 32000 processes Max open files 64000 64000 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 13087 13087 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us
反映された
エラーも消えた。
実際の作業はchef流して、各mongo鯖のプロセスを再起動。
一応全てのmongoを１台ずつ再起動していったから、メンテに入れること無く作業は終わりました。
こんな所まで管理できるのもちょっと怖いね
感想
今回のサービスがAWS上で０から環境を作るというものだったのだが、
今まで社内の環境でKickstartとかでデフォルトで入ってた用意されたインフラ的なものにいかに助けられてたかという事を痛感した。
もっかいちゃんと読んでみよう。
おまけ１
mongod側のconnectionsをちょっと広い期間で見てみる。
（間にconnectionsが０にまで下がってるのは、僕がmongoのメモリリークのバグを踏んでサービスメンテ状態を２回引き起こしたからです、ごめんなさい死にます）
本当に今になって思えばなんだけど、
このグラフの期間で増設をしてmongosの台数が約2.5倍になったのに
mongodのconnectionが500 -> 900しかいかないなんて単純に考えてオカシイ
ちなみに、その後ulimitの変更を全ての鯖に適応したら
1200近くまで上がりました(′ʘ⌄ʘ‵)
おまけ2
ulimit適用してもOS再起動時に反映されてないんじゃないの？
【参考】http://blog.father.gedow.net/2012/08/08/ulimit-configuration/
といろいろ不安になったが、そもそも起動スクリプトにulimit書くとか以前に、起動ユーザーのulimitの値を引き継いでプロセスが上がってくるから、そんな心配はいらなかった
実際、試してみたら実行ユーザのulimitで上がってきました。
おまけ???
max processes1024
やんけ！と発見した後に、ulimitが原因だったと他に示す証拠が出てこなかったので、ステージング環境でmax processesを125とかにして再現するか試してみたらmongod自体が死んでテストにならなかった。うふふ
結局500ぐらいに変えて再発した。ので本番にも適用することにした。
状況証拠を集めみたいになってしまったが、今思えばmongodとかもログレベル上げてみれば良かったんや。
isucon2013で生き恥をさらした話
結果
予選敗退＾ｐ＾
多分技術的には読んでても面白く無いとおもう
なんせ何をチューニングしたのと言われても、
途中から何をどうしたか分からん状態に陥ってたから。
- そもそも当日の朝に全員集合して言語何にする？とか選ぶ体たらくっぷり。
僕遅刻しましたし- とりあえず、PHPでベンチ動いたからPHPにすっか(死ね)
- とりあえず、ベンチ動かしてmysqlがボトルネックっぽ(適当)
- とりあえず、インデックス貼ってみるか(適当)
- innodb_Memcachedってなんぞ(適当)
- とりあえず、countとか別にもたせたらいいんじゃね(適当)
- 全件取りに行く奴、キャッシュさせろ(適当)
- apacheでもキャッシュさせるか(適当)
とか、もうこんな感じですよ。
分担とかは特にせず、これボトルネックっぽくね、どうやったら解決できる？って全員が口出して解決しようとしてたのは逆に良かったのかな・・・？
悪かったこと
何よりも事前準備が足りなかった。
そして、ただただ自分の知識の無さを痛感した。
これ何？何に使っててどうやって動いてんの？みたいな。
良かったこと
自分がウンコカスだと改めて自覚した。
そして、モチベーションが何故か上がったこと。
自分と予選突破一位の人たちと、８倍強の差が開いてたけど、自分もあんな人達にみたいになりたいと純粋に思えた。
また再挑戦したい。
余談
予選敗退の日のお酒は本当に美味しかったです（悲しい）
出、出〜、Vagrant用Box作奴〜ｗｗｗｗｗ
経緯
色々細かいことは置いておいて、
Vagrantでさくっとchefのテストをしたかったんだけど、社内のリポジトリを見てるBase Boxが見当たらなかったので作ることにした。
設定色々
順番としては
VirtualBoxにお好みのOS入れる
Vagrant連携用の設定を入れる
お好みの設定を入れる（今回の場合僕は社内のリポジトリを見るようにしました）
BaseBoxに仕立て上げる
意外とさっくり作れるからさくっとやってみよう
OS Install
Cent6.4のminimalをここから取ってきてVirtualBoxでインストールしてね
Network設定
そのまんまインストールしてるとeth1がONBOOT="no"になってるからyesにしてね。
# vim /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" NM_CONTROLLED="no" ONBOOT="yes" BOOTPROTO="dhcp" # /etc/init.d/network restart
ビルド用のパッケージとか、アップデートとか
# yum install ruby ruby-devel gcc gcc-c++ automake autoconf make rubygems kernel-devel # yum update # reboot
Virtual Box Guest Additions
ファイル共有とかポートフォワーディングとか使うためにVirtual Box Guest Additionsを入れてくよ
VirtualBoxの
Devices>Install Guest Additionsを選択
# mkdir /media/cdrom # mount /dev/cdrom /media/cdrom # sh /mnt/VBoxLinuxAdditions.run Installing the Window System drivers [失敗] (Could not find the X.Org or XFree86 Window System.)
X環境が入ってないよって言われて怒られるけど、まぁ入れてないしね。
入ってなくてもいいしそのまま続行
本当に出来てるか確認してみよう
# VBoxControl --version # VBoxService --version
Vagrant用の設定
vagrant用ユーザーとsudo権限を付けるよ
# useradd -m vagrant # usermod -aG wheel vagrant # echo vagrant | passwd vagrant --stdin # echo "vagrant ALL=(ALL) ALL" >> /etc/sudoers # echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers # echo "Defaults env_keep=\"SSH_AUTH_SOCK\"" >> /etc/sudoers
ssh経由のsudoを許可するためにrequirettyフラグを折ってあげよう
Default !requiretty
vagrantのpublickeyを登録
# mkdir -m 0700 /home/vagrant/.ssh # curl -s https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub > \ > /home/vagrant/.ssh/authorized_keys # chown -R vagrant:vagrant /home/vagrant/.ssh # chmod -R 0600 /home/vagrant/.ssh/*
Chef入れる
$ sudo su - # curl -L http://www.opscode.com/chef/install.sh | bash
お好みの設定を入れる
今回は社内のリポジトリを見るようの設定を入れたかったので、
# vi /etc/yum.repos.d/CentOS-Base.repo お好みの設定を入れてね # yum clean all
base box化
vagrant package --base TestBox(今回VirtualBoxで作ったインスタンスの名前) [TestBox] Clearing any previously set forwarded ports... [TestBox] Creating temporary directory for export... [TestBox] Exporting VM..
そうすると、package.boxがカレントディレクトリにできるので、それをbox addしてあげる
ちなみに、対象イメージが起動中だとboxを作れないから先にshutdownしてあげよう
# vagrant box add TestBox package.box vagrant] Downloading with Vagrant::Downloaders::File... [vagrant] Copying box to temporary location... [vagrant] Extracting box...
あとは、お好みに使ってね
以上で、終了
ちなみに
使うまでも一応書いておくね
# vagrant init TestBox
# vim Vagrantfile
僕が使ってたのはこんな感じ↓
Vagrant::Config.run do |config|
config.vm.box = "TestBox"
# config.vm.box = "CentOS-6.2-x86_64"
config.vm.forward_port 80, 8080
config.vm.customize do |vm|
vm.memory_size = 1024
end
config.vm.provision :chef_solo do |chef|
chef.cookbooks_path = "~/chef_2/public/cookbooks"
chef.add_recipe "test::test"
end
end
あとは起動して入るだけ
# vagrant up # vagrant ssh
(∩´∀｀)∩ﾜｰｲ
ね、眠たい・・・・
失敗談とか後で追記していく・・・( ˘ω˘ )ｺﾞｰﾂｰｵﾌﾄｩﾝ
