BigQuery, MySQL, PostgreSQL, Redshift, MongoDBのダッシュボードとしてredashが良さそう | Ore no homepage
BigQuery, MySQL, PostgreSQL, Redshift, MongoDBのダッシュボードとしてredashが良さそう ところで最近割と暇。そんな話をみんなにしたら「それ良いことじゃん」と突っ込まれた。たしかに前職とかだとちょっとした”戦場”が多かったような気がする。それがあってか手が空くと少し不安になってしまうw 実際冷静に考えると、暇があるということは、空いた時間で技術的な検証をしたり、好きなことをする余裕があるってことだ。まあもう良い年なので、余裕をもって生活したいね。それと、老害にならない程度に、良い意味で手を抜くようにもしたいと思っている。肩の力を抜くっつーか。 redashというものをたまたま見つけてよさそうなので触ってみた。簡単に言うと、データストアに投げるクエリを書いておくとその結果をグラフ化してくれる。今回は例としてBigQueryとのインテグレーション
Twitter上のできごとを監視してSlackに通知する | Ore no homepage
なんだかんだでTwitterってのはまだまだ現役で、Twitterを見ていると世の中の異変をいち早く察知できることがある。地震、天候、政変はもとより自社サービスやプロダクトの評判までも知ることができる。目玉の数さえあればどんなバグも…って言葉があるように、ユーザというのは最高のデバッガである。また昨今では数々のクラウドサービスを組み合わせてサービスを構築する手法もメジャーなので、クラウドベンダのアカウントや同業者発言を注視しておくと、使用しているXaaSの障害をいち早く知ることができる場合もある。例えばAmazonが障害を告知するよりも、タイムラインの方が先にAWSの異変に気づいてざわつくこともしばしばだ。 ということでTwitter上の任意のアカウントやキーワードを監視して、それをslackに通知するツールを書いてみた。Rubyの練習のネタなんかねーかなー、と考えてて良いネタだったから書
スマホからオペレーションするためにHubotを使っている | Ore no homepage
Hubotを使ってるんだけど、自分的ユースケースについて。 Hubot 説明するまでもない気がするので細かい説明は割愛。HubotはGitHubが開発したチャットbotというかチャットフレームワーク。hipchatやIRCなどに住ませて、mentionを受け取って任意の処理を行う事ができる。mentionを受け取ったときの処理はCoffeeScriptで書く。このようなボットを活用した開発はChatOpsなどと呼ばれる。 連携 自分のところではNewRelic、HipChat、Jenkins、munin、Sensu、サーバ管理ツール、本番環境のサーバと連携させている。 NewRelic、HipChatについてはhubot側の設定で連携できる。その他は自分でapiを叩いたり、sshでコマンドを投げたり、mentionの内容から画像URLを特定する…などという処理をプラグインに書いている。 ス
昨日、会社辞めた | 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/ これらの記事の登場人物が誰
社内勉強会でMySQLの運用について喋ってきた | Ore no homepage
すでにMySQLの運用テクニックは多くのTipsが出回っているので、考え方を中心に喋ってきた。主に、負荷が高い、レプリが遅延する、などについて。 資料 文字多めの資料になっている。オンプレでの運用が多いので、物理レイヤーの話も少しある。自己紹介だけ中途半端に英語。「資料を英語で書こうと思ったけど諦めたので、この後は全部日本語です」で、とりあえず一笑い取れた(失笑)。 こんな話をした↓ 負荷対策 SQLのチューニングはちゃんとしましょう。 ハードウェアリソースの負荷の箇所によって適切な対応をしましょう。 MySQLの設定は勘所を抑えて適切にしましょう。ただし、単なる数字いじりには意味はない。 ファイルシステムやそのオプションは、高トラフィック時に差が見えてくるので、留意はしておきましょう。 レプリケーションの遅延 資料の通りだよ。 MySQLは非同期(準同期)レプリケーションなので遅延は避け
会社主催のチューニング大会で切り戻しに失敗してランク圏外で終わるという失態 | Ore no homepage
最後に切り戻しミスって圏外で終了という痛い結果になってしまった。その記録。 事の顛末の要約と感想 競技開始 -> そこそこ良いスコアを出す -> phpまわりをいじりだす -> 終了直前までいじってもスコア上がらんので切り戻す -> なぜかスコアが全盛期に戻らないという事案が発生 -> 死 最初ぐだぐだになるんじゃないかと思っていたんだけど、なかなか面白かったです。定期的にこういう企画やると良いと思う。というか、月一くらいで重要サービスのチューニングをお題にしてみんなでチューニング大会したらいいんじゃないかな。会社としても絶対プラスになると思うよね。 競技のルール AWSのインスタンス4台与えられる。 すべてのインスタンスにApache, php, MySQLでアプリケーションが動いている そのうち一台に定期的に負荷が飛んでくるので、その結果がスコアとなる phpのソースはいじっちゃダメ
Google BigQueryにMySQLのデータを入れる | Ore no homepage
肋骨が折れたかもしれん。痛え。それは置いといて…BigQuery。処理能力を体感したかったのでとりあえずMySQLの本番データをつっこんだ。fluentdでログも突っ込んでるんだけど、そっちはデータが溜まってないからまだおもしろくないかな。それについてはまた別途。まあ、fluentdでデータ突っ込むのはいろんな人がqiitaとかブログに上げてるし書くまでもないかもしれないけどね。 0. 作業の流れ MySQLからダンプを抜く ダンプをCloud Storageにuploadする Cloud Storage からbigqueryにインポートする クエリ投げる という流れになる。この記事では深く言及しないが、Google Compute Platformのコンソールでプロジェクトの作成やら課金の登録やらが済んでいて、作業を行うマシンにはコマンドラインツールがインストール済みであるとする。 コマ
Sensu serverのdockerイメージ作った | Ore no homepage
最近モチベがあがらん。まあ酒飲めばどうでもよくなってしまうんだけど。温泉入りたい。 sensu-server、sensu-api、sensu-dashboard、redis、rabbitmqのプロセスが入ってるdockerイメージ作ったのでそれについて。これでsensuサーバの構築がdocker pull, docker runの2コマンドだけでできる。 作った githubとdocker indexに置いた。 github https://github.com/hiroakis/docker-sensu-server docker index https://index.docker.io/u/hiroakis/docker-sensu-server/ docker入れてるマシンから↓みたいな感じで、docker indexからdocker pullで持ってきてdocker runでバー
監視システムを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 今更ながらonline-schema-changeについて | Ore no homepage
そういえば先日はハロウィンだったね。んで、今日スタバに行ってみたら早くもクリスマス仕様。残念ながら年末の予定は無え。 そんなこんなでオンラインスキーマチェンジを本番のオペレーションで使い始めたのでそのメモ。 0. online-schema-change オンラインスキーマチェンジは、percona社が出しているpercona-toolkitに梱包されている。その他有用なツールも入っているのでお世話になっている人も多いだろう。で、オンラインスキーマチェンジはその名のとおり、スキーマの変更、alter文をブロックなしで実行してくれるという代物。 私事なんだけど、今までは「ちょっと更新をブロックしちゃうけどアクセスの少ない時間帯にオンラインでalterを流す」みたいな運用をしてた。実行内容にもよるけどalter tableは意外と早いので、「更新をブロックされる時間がSLA的に許可できるならO
NTTコミュニケーションズのクラウド「cloudn」を使ってみた所感 | Ore no homepage
知人が起業したのでたまにお手伝いをさせてもらってる。言語がScalaとJavaScriptでインフラが掲題のcloudn。俺のスキルセットじゃ手伝えることなさそうだったんだけど、多少は役に立つことができかな？報酬はビール一杯＋ホットドッグとかwやっすい労働力でしょw んで、まあ結局はAWSに鞍替えする方針になったんだけど、ちょっとだけcloudnの調査結果を公開しておく。AWSにした理由は、cloudnの調査工数に時間が取られるので慣れている方がいい、という理由。ちょっと検証時間足りない。スタートアップとしてはガンガン開発したいので、その工数をインフラの調査/検証に取られるのはちょっと…って判断かな。ちょっと触った感じは完成度高いと思う。cloudn。そして安さも魅力。 cloudn これ、ね。 http://www.ntt.com/cloudn/ 「くらうどえぬ」と読む。「くらうどん」で
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
開発支援系のサービスが充実しすぎて転職か廃業を考えた | 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を触り始めたころは、「気
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL 容量確保のためのデータ削除方式 | Ore no homepage
Sensu Casual Talks #1 at KAIZEN platformで喋ってきた | Ore no homepage