サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
hiroakis.com
今日は有給で家でアレしています。今の会社に入ってから技術的な話は会社の技術ブログに書いてたんだけど、やはり自分のところにも書いていこうかな、と。件のとおりなんだが、Circle CIに設定する環境変数を管理するツールを書いた。 Circle CIと環境変数 Circle CIはプロジェクトごとに環境変数の設定ができる。ここで設定された環境変数はCircle CIのコンテナにセットされ、テストやデプロイ時に参照することができる。Ansibleのvaultパスワードをセットしておいて、リポジトリ内で暗号化して管理しておいた秘密鍵を複合してテスト時に利用する、AWSなどのアクセスキーをセットしておいて、テストがパスされたらAWSキーを利用してデプロイを行う…など。 とりあえずこいつらのポチポチがつらい。一度セットすると人間の目では見れなくなるので、何がセットされているか設定したやつにしかわからな
みんなのGo言語を著者の一人である @songmu さんからいただきました。ありがたい。それにしても久々の記事だな、オイ…。今度近況でも書くか…。 感想 全体を通しての感想ですが「goの文法に慣れてきたしそろそろ本格的なアプリケーションを書くか」という人に最適なんじゃないかという感想です。これは言語問わずですが、その言語で初めてアプリケーションを書くときにはおそらく次のようなことが気になるでしょう。 開発環境はどうするのがいいのか？ インターフェースやらほげほげやら習ったけどどう活用しようか？ 書いたアプリケーションを運用に乗せたいんやけどデプロイやらモニタリングはどうやるのがいいのか？ などなど。このような悩みは、今の時代githubやらブログやらを漁って他人のコードや手法を参考にするのが定石でしょうけど、ネットに転がっている種々の情報を整理して自分なりの解を導き出すのは骨が折れる作業で
Mackerel Advent Calendar 2015の12日目です。比較的ゆるい内容にしました。昨日はすてにゃんさんでした。 この記事について 件の通り、mackerelのチェックプラグインについて。僕自身も業務では監視システムの中核としてMackerelを採用していて、主題のgo-check-pluginsやmackerel-agent-pluginsにいくつかのコントリビュートをさせていただいております。今回はgo-check-pluginsのプラグイン仕様やらお作法やらを簡単に解説します。golangでチェックプラグインを書いてみたいという人の一助になれば幸いです。 go-check-plugins チェックプラグインの開発にはいくつかのルールとお作法があります。ざっくり言うと次のポイントを押さえるべきだと思っています。 exit code 公式HPにも解説がありますが、これが
カレー Advent Calendar 2015の8日目。五反田にオフィスを構えているのでその付近のカレー事情をば。 五反田リージョン 五反田リージョンには駅を挟んで西五反田、東五反田と二つのAZがあります。私のオフィスは西AZなのですが、東AZまでのRTTは片道10分以内だ。しかしながらAZまたぎのレイテンシ軽減のために主に西AZを使うことが多い。 と、まあ冗談はこれくらいにして五反田のカレー屋で俺が好きな店をいくつか紹介させていただきます。オフィスが西側なので主に西五反田の店について。 うどん まずはこちら。山手通りの小道を少し入ったところにあるスープカレーの店。店名は うどん だがメニューに うどん はない(ギャグで言ってるのか？)。ちゃんとしたスープカレーの店である。まずは下の公式HPをクリックしてみてくれ。どう思う？突然現れるalert(“ありがとねー うどん?”)。最後の「?」
先日行われたMySQL Casual Talks #8で登壇してきた。会場を貸してくださったテコラスさん、主催者ならびに参加者の皆様ありがとうございました。 発表のネタ ネタは「トレタのMySQL」と「はじめてのRails+MySQLの運用でOctopusでハマったこと」の二つを用意したんだが、後者は内容がRailsに寄りすぎていたというのと、時間的にもアレだったので自粛した。 小規模限定回ということだったんだが、そもそもウチは小規模なんだろうか？という疑問があった。なので「これできるの小規模だからだよなぁ…」と思えることを捻出して喋ってみた。 トレタのMySQL 内容的には、 小規模だと、Likeで全文検索とかアンチパターンみたいなことやっててもでも割と動くよ。 小規模だと大規模に比べて運用は楽。でもこれは台数が少ないからということではなく、アーキテクチャがシンプルだから。 大規模であっ
今、リアルタイムでは休暇中でフランクフルト経由ベルリン行きの飛行機の中にいる。暇すぎる。うちの会社、ってかトレタの監視系の変遷について書く。でも絵を描く気力はないので文字のみ。 今の状況です ルフトハンザは日本線は軽食の時間に ONIGIRI が出てくるので結構好きな航空会社です。休暇中なのにラップトップ持ってくのはプロ社畜の証。まあ今会社で裏側見てるのが俺しかいないので、エエ…。しかし世の中ホント便利に便利になってる。空の上でもインターネットができる。言い方を変えると空の上でもアラートが届くっていう…。飛行機の中は暇すぎるけどさすがに仕事はしたくないね。というかこの旅行中は仕事を忘れたい。 2014/10以前 俺が入社する前。 コア機能：Engineyard(OS: gentoo)。 プロセス異常監視、閾値監視など：monit エラートラッキング、レスポンスタイム、SQL：NewReli
9/28, 29にポートランドで開催されたHashiconfに参加してきた。海外のカンファレンスに参加したのは2012年のQCon SF以来か？各セッションの具体的なレポートは既に他の人が書いていたりするので俺は主に全体的な感想や現場で得られた情報を書く。 ちなみに会社の金で行かせてもらえました。ありがたいことです。 感想 モチベーションの向上 何度かこの手のカンファレンスに足を運んでいるが、やはり一番の収穫はモチベーション。各セッションの内容も良いんだけど、それらは今の世の中カンファレンス自体に参加しなくても十分に得られる。リアルタイム中継もあったりするし、TL見てれば情報はゴマンと流れてくる。実際今回もNomadとOttoの発表がされたが、その日のうちに”触ってみた系”の記事が投稿されていたりした。現場でそれを聞くおもしろさはあるとは思うが、それよりもセッションの合間に他の参加者と話を
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で
前回、最近割と暇とか書いたらなんかエラーが増えてきて対応しなきゃって事案が発生した。Rubyなアプリケーションの運用は今の会社で初めてなんだが、こういうトラブルに直面すると知見が増える。 いうてもやることは結構あるっちゃあるんだけどね。直近だとうるう秒対応とか…。俺んとこはntpd止めることにした。で、うるう秒経過後に起動する、と。ワケあって本番のOSがgentooだし、何が起きるかわからんので。AWS上にいるAmazon Linuxや、GCE上にいるUbuntuはslewモードで乗り切る。しかしまあマルチクラウドも考えものだな…。運用しづらい。個人的には今のGentooなインフラをAWSに移したいんだが、会社としてまだその判断はしないようだ。まあインフラ周り見てるの俺一人しかいねーしな…。 環境 Ruby 2.0.0 Rails 4.0.1 Unicorn 4.6.3 Octopus 0
BigQuery, MySQL, PostgreSQL, Redshift, MongoDBのダッシュボードとしてredashが良さそう ところで最近割と暇。そんな話をみんなにしたら「それ良いことじゃん」と突っ込まれた。たしかに前職とかだとちょっとした”戦場”が多かったような気がする。それがあってか手が空くと少し不安になってしまうw 実際冷静に考えると、暇があるということは、空いた時間で技術的な検証をしたり、好きなことをする余裕があるってことだ。まあもう良い年なので、余裕をもって生活したいね。それと、老害にならない程度に、良い意味で手を抜くようにもしたいと思っている。肩の力を抜くっつーか。 redashというものをたまたま見つけてよさそうなので触ってみた。簡単に言うと、データストアに投げるクエリを書いておくとその結果をグラフ化してくれる。今回は例としてBigQueryとのインテグレーション
「エンジニアなんだから社内インフラとか余裕でしょ？」とか言われたわけではないんだけど、社内ネットワーク構築とかやったことないんだわ。なのでそのメモ。 企業規模 創業2年弱とかそんくらいのBtoBベンチャー。 社員数30人くらい。うちエンジニアは6人。 要件 社員用NWとゲスト用NWは分けたい 社員用NWから外に出て行くIPは固定IPにしたい ゲスト用NWから外に出て行くIPは↑とは別にしたい VPNほしい 構成 モデムからの線をHUBで二本に分岐する。分岐先にはそれぞれ別のルータがいて、それぞれが別のプロバイダとPPPoEを喋る。1つのルータから2つのプロバイダに接続させて、うまくルーティングさせてもよかったんだが、機器の予備という意味でももう一個ルータがあってもいいんじゃないかと思ったので買わせてもらってこの構成にした。 各機器の設定は至極単純で、ルータは上述したようにPPPoE接続設定
今回も簡単な記事。頭がタイムゾーン慣れしていないってのと今までJST以外での運用をやったことがなかったのでメモ。結論から言うとin_time_zoneはサマータイムも考慮してくれるので特に難しく考えなくてOK。 日本にもサマータイムがあった時期があったようだ かつては日本にもサマータイムがあったようなので日本で実験する。railsコンソールを叩いて今日の日本の時刻を調べる。 irb(main):039:0> Time.local(2015,5,27).in_time_zone(‘Asia/Tokyo’) => Wed, 27 May 2015 09:00:00 JST +09:00 日本は標準時+9時間なので想定通りの結果が返る。ここで日本がサマータイムを導入していた1950年にタイムスリップしてみる。 irb(main):038:0> Time.local(1950,5,27).in_t
ちょっと行ってきた。ところで今回の旅で得られた知見は3泊程度でヨーロッパに行っても割と楽しめるということだ。つまり夏休みとかじゃなくて、3連休＋有給1日でヨーロッパとか遠方に行くのもありだね。 ほぼ写真の羅列とその説明です。 旅程 5/12 10:30 成田out -> 5/12 14:50 ヘルシンキ(フィンランド) in 5/13 ヘルシンキ(フィンランド) -> タリン(エストニア) -> ヘルシンキ(フィンランド) 5/14 ヘルシンキ 5/15 17:15 ヘルシンキout -> 5/16 成田in 航空券＋燃費＋滞在費で13マンくらいだった。 5/12 ヘルシンキ 成田からヘルシンキに飛ぶ。10時間くらいかな。空港からヘルシンキ中央駅までシャトルバスが出てるのでそれに乗る。さすがLinuxが生まれた国、IT先進国らしくバスの中にもフリーwifiが飛んでる。 今回は事前に何も調べ
なんだかんだでTwitterってのはまだまだ現役で、Twitterを見ていると世の中の異変をいち早く察知できることがある。地震、天候、政変はもとより自社サービスやプロダクトの評判までも知ることができる。目玉の数さえあればどんなバグも…って言葉があるように、ユーザというのは最高のデバッガである。また昨今では数々のクラウドサービスを組み合わせてサービスを構築する手法もメジャーなので、クラウドベンダのアカウントや同業者発言を注視しておくと、使用しているXaaSの障害をいち早く知ることができる場合もある。例えばAmazonが障害を告知するよりも、タイムラインの方が先にAWSの異変に気づいてざわつくこともしばしばだ。 ということでTwitter上の任意のアカウントやキーワードを監視して、それをslackに通知するツールを書いてみた。Rubyの練習のネタなんかねーかなー、と考えてて良いネタだったから書
著者で元同僚の@dblmktさんからいただきました。いただいてから少し時間が経ってしまった…。 SQLパフォーマンス詳解 購入はこちらから: http://sql-performance-explained.jp/ @dblmktさんのブログ: http://b.l0g.jp/uncategorized/sql-performance-explained-ja/ 購入する場合、電子版での購入になります。ちなみに、紙の本は夏以降に出るらしいです。 感想 翻訳本なのですが、読みやすく翻訳されています。初心者からエキスパートまで役に立つ内容です。特に駆け出しのエンジニアは持っておくといいと思います。自分も若い頃にこれを読んでいたらもっと上達が早かったんじゃないかと思いました。 where句とインデックスの説明 where句とインデックスの説明に大半を割かれています。やはりSQLの主役はselec
一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch
10月頃にヨルダン、イスラエル、パレスチナに行ってきた。フォトギャラリー。物々しいと言われている地域だが個人的にイスラム文化圏は結構好きで、しばしばそのような地域に行っている。もちろんガザや現在のシリアなどガチで危険な場所には行かないが。 現地人と昨今の情勢の話もしたんだが「イスラム国(Islamic state)」と言うとちょっと嫌な顔をされる「あいつらはイスラムじゃないから！」って。「ダー」だか「ダイシュ」だかって表現してたかな？忘れた。でもまあ「イスラムは人を傷つけない平穏なものなんだ」とかいいつつ「いろいろ教えてあげたから金くれ」とか言うんだけどね。払わないけど。それとこれとは別ってことだな。 ヨルダン、イスラエル、パレスチナに行ってきた ここ2年だと、クロアチア、ボスニア、ウズベキスタンと行ったんだが、同世代や少し上の世代の方に会うことが多く、バックパッカーの高齢化が進んでいるの
今教えてもらった。知らなかった。もしかしたらちょっと便利かもしれない。 サファリでmuninとか開いて「ファイル」 ->「Dashboardで開く」を選択する。 で、選択して、追加をクリック。 するとこんな感じで、ダッシュボードで見れるようになる。ついでにアメッシュも表示させてる。よく見るグラフをダッシュボードに入れておけば、四本指スワイプで「シュッ！」で見れるようになる。 おわり
正確には昨日が最終出社日で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 Casual Talks #1で喋ってきました。会場の提供および招待していただいたKAIZEN platformのglidenoteさんありがとうございました。他の参加者の皆様もありがとうございました。Sensu運用者として、いちエンジニアとしてとても面白い話を聞く事ができて大満足の勉強会でございました。 資料 俺の発表はSensuのUIである、sensu dashboard, sensu admin, uchiwa, sensu-cliおよびHubotから操作するときの雑感について話してきた。
すでにMySQLの運用テクニックは多くのTipsが出回っているので、考え方を中心に喋ってきた。主に、負荷が高い、レプリが遅延する、などについて。 資料 文字多めの資料になっている。オンプレでの運用が多いので、物理レイヤーの話も少しある。自己紹介だけ中途半端に英語。「資料を英語で書こうと思ったけど諦めたので、この後は全部日本語です」で、とりあえず一笑い取れた(失笑)。 こんな話をした↓ 負荷対策 SQLのチューニングはちゃんとしましょう。 ハードウェアリソースの負荷の箇所によって適切な対応をしましょう。 MySQLの設定は勘所を抑えて適切にしましょう。ただし、単なる数字いじりには意味はない。 ファイルシステムやそのオプションは、高トラフィック時に差が見えてくるので、留意はしておきましょう。 レプリケーションの遅延 資料の通りだよ。 MySQLは非同期(準同期)レプリケーションなので遅延は避け
Hubotを使ってるんだけど、自分的ユースケースについて。 Hubot 説明するまでもない気がするので細かい説明は割愛。HubotはGitHubが開発したチャットbotというかチャットフレームワーク。hipchatやIRCなどに住ませて、mentionを受け取って任意の処理を行う事ができる。mentionを受け取ったときの処理はCoffeeScriptで書く。このようなボットを活用した開発はChatOpsなどと呼ばれる。 連携 自分のところではNewRelic、HipChat、Jenkins、munin、Sensu、サーバ管理ツール、本番環境のサーバと連携させている。 NewRelic、HipChatについてはhubot側の設定で連携できる。その他は自分でapiを叩いたり、sshでコマンドを投げたり、mentionの内容から画像URLを特定する…などという処理をプラグインに書いている。 ス
最後に切り戻しミスって圏外で終了という痛い結果になってしまった。その記録。 事の顛末の要約と感想 競技開始 -> そこそこ良いスコアを出す -> phpまわりをいじりだす -> 終了直前までいじってもスコア上がらんので切り戻す -> なぜかスコアが全盛期に戻らないという事案が発生 -> 死 最初ぐだぐだになるんじゃないかと思っていたんだけど、なかなか面白かったです。定期的にこういう企画やると良いと思う。というか、月一くらいで重要サービスのチューニングをお題にしてみんなでチューニング大会したらいいんじゃないかな。会社としても絶対プラスになると思うよね。 競技のルール AWSのインスタンス4台与えられる。 すべてのインスタンスにApache, php, MySQLでアプリケーションが動いている そのうち一台に定期的に負荷が飛んでくるので、その結果がスコアとなる phpのソースはいじっちゃダメ
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
サッカー観戦が好きなハズなんだけど、今回のワールドカップまだ一試合も見てない。試合の状況はTwitterや外の叫び声で把握してるんだけど…。 えーと、以前、似たような記事(https://hiroakis.com/blog/2012/07/31/mac-osxiterm2tmuxzsh/)を書いてから2年も経ってしまった。ちょいちょい使うツールが増えたりもしたのでそのまとめ。基本的には自分用メモだけど、紹介したものが人様の役に立てば幸い。同業者の人達の環境とかどうなってるのか気になるね。 0. シノギ 自己紹介ってわけじゃないけど、普段こんな仕事↓やってる奴の環境ですよ、っと。 Web屋でSNSやソーシャルゲームの運用。 会社の職種的にはインフラエンジニアというくくり。 しかしながらデータセンター行くのは月一くらい。 普段はサーバの管理とか運用改善とかをしてる。 ターミナルカタカタしてたり
肋骨が折れたかもしれん。痛え。それは置いといて…BigQuery。処理能力を体感したかったのでとりあえずMySQLの本番データをつっこんだ。fluentdでログも突っ込んでるんだけど、そっちはデータが溜まってないからまだおもしろくないかな。それについてはまた別途。まあ、fluentdでデータ突っ込むのはいろんな人がqiitaとかブログに上げてるし書くまでもないかもしれないけどね。 0. 作業の流れ MySQLからダンプを抜く ダンプをCloud Storageにuploadする Cloud Storage からbigqueryにインポートする クエリ投げる という流れになる。この記事では深く言及しないが、Google Compute Platformのコンソールでプロジェクトの作成やら課金の登録やらが済んでいて、作業を行うマシンにはコマンドラインツールがインストール済みであるとする。 コマ
同じスペックのハードウェアで動いているMySQLサーバが2台あるんだけど、なんか性能が明らかに違うって事案があって。調べてみたらBIOSの設定が違ってて…。フラッシュの性能を引き出すには省電力モードを解除しないとダメ。このへんについてはちゃんとマニュアルに書いてある。そんな記事。 BIOSを調査 MySQLのコンフィグやらOSの設定を調査してもまったく一緒で、CPUやらメモリやらNICやらioDriveのドライバやらコンフィグを調べても一緒。で、BIOSを調査。DELLのサーバは下記のコマンドでBIOSの設定を調べられる。 omreport chassis biossetup このコマンドでバーンとBIOSの設定を取得できる。このomreportってユーティリティはsrvadmin-xxxxってパッケージに入っている(srvadmin-omacoreとか)。DELLさんのサイトを漁ってくだ
最近モチベがあがらん。まあ酒飲めばどうでもよくなってしまうんだけど。温泉入りたい。 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でバー
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムが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概要
次のページ
このページを最初にブックマークしてみませんか？
『Ore no homepage | おれのホームページ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
