MySQL Casual Talks vol.8で喋ってきた | Ore no homepage
先日行われたMySQL Casual Talks #8で登壇してきた。会場を貸してくださったテコラスさん、主催者ならびに参加者の皆様ありがとうございました。 発表のネタ ネタは「トレタのMySQL」と「はじめてのRails+MySQLの運用でOctopusでハマったこと」の二つを用意したんだが、後者は内容がRailsに寄りすぎていたというのと、時間的にもアレだったので自粛した。 小規模限定回ということだったんだが、そもそもウチは小規模なんだろうか？という疑問があった。なので「これできるの小規模だからだよなぁ…」と思えることを捻出して喋ってみた。 トレタのMySQL 内容的には、 小規模だと、Likeで全文検索とかアンチパターンみたいなことやっててもでも割と動くよ。 小規模だと大規模に比べて運用は楽。でもこれは台数が少ないからということではなく、アーキテクチャがシンプルだから。 大規模であっ
ウチの監視システムの変遷について書く | Ore no homepage
今、リアルタイムでは休暇中でフランクフルト経由ベルリン行きの飛行機の中にいる。暇すぎる。うちの会社、ってかトレタの監視系の変遷について書く。でも絵を描く気力はないので文字のみ。 今の状況です ルフトハンザは日本線は軽食の時間に ONIGIRI が出てくるので結構好きな航空会社です。休暇中なのにラップトップ持ってくのはプロ社畜の証。まあ今会社で裏側見てるのが俺しかいないので、エエ…。しかし世の中ホント便利に便利になってる。空の上でもインターネットができる。言い方を変えると空の上でもアラートが届くっていう…。飛行機の中は暇すぎるけどさすがに仕事はしたくないね。というかこの旅行中は仕事を忘れたい。 2014/10以前 俺が入社する前。 コア機能：Engineyard(OS: gentoo)。 プロセス異常監視、閾値監視など：monit エラートラッキング、レスポンスタイム、SQL：NewReli
nginxのproxy_passにIPではなくホスト名を使うときの注意点 | Ore no homepage
nginxの背後にELBがいて、proxy_pass https://xxx.yyy.comみたいに指定していたんだが、突然クライアントにHTTP 499が返却されてしまうという事案が発生した。なおこの記事の対象はnginx1.8系とnginx1.6系。調べたところによると割とみんなよくハマる定期ネタのようだ。 どういうことか nginxの仕様としてproxy_passに名前を使っている場合、その名前解決はnginx起動時に行われる。そしてそのときに取得したIPはnginxにキャッシュされてnginxの再起動もしくはHUPを受け取るまで解放されない。 なのでELBのようにIPが変化するものをnginxの後段に置くときは注意する。 proxy_pass https://xxx.yyy.com; だけでなく、resolverでDNSとそのキャッシュのexpireを指定、さらにset $xxxで
Twitter上のできごとを監視してSlackに通知する | Ore no homepage
なんだかんだでTwitterってのはまだまだ現役で、Twitterを見ていると世の中の異変をいち早く察知できることがある。地震、天候、政変はもとより自社サービスやプロダクトの評判までも知ることができる。目玉の数さえあればどんなバグも…って言葉があるように、ユーザというのは最高のデバッガである。また昨今では数々のクラウドサービスを組み合わせてサービスを構築する手法もメジャーなので、クラウドベンダのアカウントや同業者発言を注視しておくと、使用しているXaaSの障害をいち早く知ることができる場合もある。例えばAmazonが障害を告知するよりも、タイムラインの方が先にAWSの異変に気づいてざわつくこともしばしばだ。 ということでTwitter上の任意のアカウントやキーワードを監視して、それをslackに通知するツールを書いてみた。Rubyの練習のネタなんかねーかなー、と考えてて良いネタだったから書
chefを捨ててシェルスクリプトにした | Ore no homepage
一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch
OSXのdashboardを使うと監視が捗るかもしれない | Ore no homepage
今教えてもらった。知らなかった。もしかしたらちょっと便利かもしれない。 サファリでmuninとか開いて「ファイル」 ->「Dashboardで開く」を選択する。 で、選択して、追加をクリック。 するとこんな感じで、ダッシュボードで見れるようになる。ついでにアメッシュも表示させてる。よく見るグラフをダッシュボードに入れておけば、四本指スワイプで「シュッ！」で見れるようになる。 おわり
昨日、会社辞めた | Ore no homepage
正確には昨日が最終出社日で2014/10/31が退職日になる。これから一ヶ月有給消化。在籍してたのは3年半くらいか。楽しかったよ。 選別もろた。花束、色紙、自社サービスのグッズ、酒のとっくりとおちょこ、お菓子、アンチェインのフィギュア、ワイン…とまあ大量にいろいろいただきました。帰り道、道行く人の「どこに買い物行ってきたんだこのおっさんは」みたいな視線がおもしろかったw おわり 以下、追記 ちょうど辞めたばかりで思うところがあるので、もう少し書く。このへんのはてぶ記事↓について、ね。 http://b.hatena.ne.jp/entry/www.mynewsjapan.com/reports/2081 http://b.hatena.ne.jp/entry/www.nikkei.com/article/DGXMZO77749270Q4A930C1000000/ これらの記事の登場人物が誰
監視システムをSensuに刷新した | Ore no homepage
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムがmonっつー超レガシーシステム。知っている人もいるかもしれないが、monはperl製のシンプルな監視システム。古くからあるものなんだけど「mon perl」で検索すると「もしかして: man perl」とgoogle様にも何だっけソレ？と言われてしまうかわいそうな奴(「mon monitoring tool」だとちゃんと出てくる)。なのでまあこの際だから俺が葬り去ってやる。導入したSensuのバージョンは0.12.6。GW前くらいから運用しているが今んとこ問題ない。まだ運用期間短いね。 割と長文になっちまったので、目次をば。 0. sensu概要 1. なぜsensu？ 2. インストール 3. コンフィグの配置 4. プラグインについて 5. API 6. デバッグ 7. 今後の展望 0. sensu概要
MySQL InnoDBの圧縮に関する雑感 | Ore no homepage
7月は一回も記事書かなかった。3年くらい前からInnoDBの圧縮をしてみたり止めてみたりって行為を度々しているので、所感についてまとめとく。 2011年頃(MySQL5.1) 容量削減目的で圧縮を試す。 環境 CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz(仮想8コア)×1 memory: 24GB storage: ioDrive Duo(2面合わせて600GBくらい。SW RAID0で組む。) OS: CentOS 5.4(kernel: 2.6.18-164.el5) filesystem: xfs(noatime, nobarrier) MySQL: 5.1 innodb plugin Query: ピーク時に更新系が5kqpsくらいだったかなあ…忘れた。 圧縮した結果 容量は半分に削減できた。 パフォーマンスはあまり変わらなかった。 CPU
Google BigQueryにMySQLのデータを入れる | Ore no homepage
肋骨が折れたかもしれん。痛え。それは置いといて…BigQuery。処理能力を体感したかったのでとりあえずMySQLの本番データをつっこんだ。fluentdでログも突っ込んでるんだけど、そっちはデータが溜まってないからまだおもしろくないかな。それについてはまた別途。まあ、fluentdでデータ突っ込むのはいろんな人がqiitaとかブログに上げてるし書くまでもないかもしれないけどね。 0. 作業の流れ MySQLからダンプを抜く ダンプをCloud Storageにuploadする Cloud Storage からbigqueryにインポートする クエリ投げる という流れになる。この記事では深く言及しないが、Google Compute Platformのコンソールでプロジェクトの作成やら課金の登録やらが済んでいて、作業を行うマシンにはコマンドラインツールがインストール済みであるとする。 コマ
opensslのTLS heartbeat read overrun (CVE-2014-0160)を対処した | Ore no homepage
あ、このサイト、ね。無駄にSPDYとかやるからコレ踏んじまった。openssl＋nginxをリコンパイルで対処。そして対応完了したらこのサイトがSPDYじゃなくなっちまった。これについてはまたあとで…。この脆弱性、2014/4/7に発令が出たんで、早めに対処しましょう。 TLS heartbeat read overrun (CVE-2014-0160) 詳細は下記のとおり http://jp.techcrunch.com/2014/04/08/20140407massive-security-bug-in-openssl-could-effect-a-huge-chunk-of-the-internet/ http://heartbleed.com/ https://www.openssl.org/news/secadv_20140407.txt techcrunchから要点を引用すると
RethinkDBをちょっと触ってみた感想 | Ore no homepage
なんか負荷試験やってて疲れた。その合間にRethinkDBを触ってみた。いわゆる「やってみた」系のゆるい記事。 そうそう、snapchatちょっと面白くなってきたw オッサン同士でクソくだらない10秒動画とか送って遊んでるw RethinkDB http://www.rethinkdb.com/ つい最近登場したわけではなく、どうやら2009年〜2010年当たりに生まれたようだ。 感想など 画像が多くなってしまったので、先に結論というか感想を書く。 データの操作感はMongoDBっぽい。データもまんまjsonだし。 管理WebUIがイケメン。データ操作、クエリのプロファイル、クラスタ管理、モニタリングなどいろいろできる。 どこで使おうかな、まずは簡単なツール用のデータストアとかにはいいんじゃない？ 公式ドキュメントは割と充実している。こういうときに使ったらいいよって説明もある↓ http:
MySQLのクエリ集計手法いろいろ | Ore no homepage
Webサービスを開発/運用してるモンとしては、いろんなWebサービスを触ってみなきゃアカンってことで、アメリカの若モンに大人気ってふれこみのsnapchatに登録してみた。これでリア充の仲間入りやと思ったが、snapchat友達が同僚二人しかいないうえに、利用シーンがあまり思い浮かばないww オジサン困っちゃいました。画像とか送信できるんだけど、数秒で消えるの。むしろそこがウリっていうね。どうやって遊ぼうか…。 2月はブログ書かなかったなーと思ったのでMySQL小ネタ。世間的にも自分的にも真新しくもなんともないTipsです。 innotopで集計 実は以前、Qiitaに書いたので↓をば。。。 http://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa 流れるクエリ、ロックの状況、トランザクション(show engine innodb s
serverspec インフラ層のテスト項目を考える | Ore no homepage
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
MySQL 今更ながらonline-schema-changeについて | Ore no homepage
そういえば先日はハロウィンだったね。んで、今日スタバに行ってみたら早くもクリスマス仕様。残念ながら年末の予定は無え。 そんなこんなでオンラインスキーマチェンジを本番のオペレーションで使い始めたのでそのメモ。 0. online-schema-change オンラインスキーマチェンジは、percona社が出しているpercona-toolkitに梱包されている。その他有用なツールも入っているのでお世話になっている人も多いだろう。で、オンラインスキーマチェンジはその名のとおり、スキーマの変更、alter文をブロックなしで実行してくれるという代物。 私事なんだけど、今までは「ちょっと更新をブロックしちゃうけどアクセスの少ない時間帯にオンラインでalterを流す」みたいな運用をしてた。実行内容にもよるけどalter tableは意外と早いので、「更新をブロックされる時間がSLA的に許可できるならO
開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage
なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」
MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage
毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日本の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー？温暖化ってやつ？日本の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気
Riak 06 バックアップ/リストア | Ore no homepage
HW障害か何かでノードがぶっ壊れて、置き換え用の新しいノードを故障したノードと同じIP/同じname(vm.argsの-name)で構築するようなケース。 新しいノードにRiakインストール 新しいノードに、バックアップからデータ、リング、コンフィグ（/var/lib/riak/bitcask(lebeldb), /etc/riak/*, /var/lib/riak/ring）を戻す。 新しいノードのRiak起動。 で、おｋ。 2.2 別のノードにデータを移す場合 別に用意したサーバにデータを移したいケース。もしくはぶっこわれたノードを置き換えるときに、事情があって同じIPにすることができないようなケース(DHCPでIP振ってるときとか)。 新しいノードにRiakインストール 新しいノードに、バックアップからデータ、リング、コンフィグ（/var/lib/riak/bitcask(lebel
Riak 05 システムプランニング | Ore no homepage
ハードウェア層 OS層 クラスタの留意点 負荷分散 ベンチマーク BitcaskとLevelDB コンフィグファイル スケールアウトとスケールアップの手順 運用上の注意点 64ビットCPUアーキテクチャ 最低4GBのメモリ。メモリは最も重要。局所性を活かせるのであれば多くメモリを必要としない。 RAID0、SSDを考慮すると良い。IOバウンドになりがちなので。 ミラーリング(RAID1)は考えなくて良い。 RAID(RAID1？)はやめちゃいな(クラスタ組んでるしいいんじゃない？的な？)。 ディスクサイズ重要。 ギガビットイーサも考慮にいれて。ネットワークも使うよ。 仮想マシンを使う場合は一番良いインスタンスを使う。同じデータセンタ/リージョンに配置するようにする。 クラスタ全体で必要なディスクサイズは次のように計算できる。 オブジェクト数 * 平均オブジェクトサイズ * n_val 50
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL 容量確保のためのデータ削除方式 | Ore no homepage