俺の考えるISUCON - たごもりすメモ
ISUCONというイベントがある。要するに技術コンテストイベントだ。領域はWebアプリケーションにかかわる全てといってよい。 isucon.net これがなんなのか、そろそろ一発説明しておくか、という気分にちょっとなったので書く。実は何を隠すこともなく次の出題者なのでいかに出題内容にひっかからないように書くかがちょっと大変かもしれないが、どうせ出題内容とかまだ確定しているわけでもないので、いいや。 ISUCONとは何か ある日の朝、Webアプリケーションが一式、適当に設定されたサーバごと渡されます。あとベンチマークツールも渡されます。 さて夕方までにこのベンチマークツールの計測するスコアを可能な限り上げてください、そのためなら渡されたサーバ上で何をやっても構いません。ただしベンチマークツールはアプリケーションの動作が変わっていないかどうかチェックするための機構を備えているので、そいつが違反
マウンテンビューの片隅で意識低く短期間滞在を生き抜くためのノウハウ - たごもりすメモ
自分もシリコンバレーはマウンテンビューに本社があるベンチャーに就職して仕事でカリフォルニアの青空すばらしい! とか言っているからにはこの地域でいかに生き抜くべきかみたいな意識の高いことを書こうかと思ったが、青空を見ながらも既にビールが入っていて到底無理そうだった*1。 なので、シリコンバレーとかベイエリアなんて風呂敷を広げず、マウンテンビュー、しかもダウンタウン近くではなくSan Antonioという微妙に離れた田舎でクルマ無しにショートステイを無事生きるにはどうすればよいかについて書き残そうと思う。 そんなニッチな文書書いてどうするんだという話はありそうだが、少なくともこれから東京で入社してくる同僚のためには役に立つ……はずだ。 前提 San Antonio Mountain Viewというところにオフィスがあって、そこに徒歩で通えるあたりのホテルもしくはAirbnbに宿泊すると思いねえ
小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ
でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え
就職しました - たごもりすメモ
結局3月からそのまま働くことにしました。 先日のエントリを書いて以来、本当に多くの方から声をかけていただきました。ありがとうございました。本来なら個別にご報告するべきところですが、ちょっと数が多くて厳しいので、このエントリをもって報告にかえさせていただきます。 またいろいろと話を伺う中で考えたことなどもあるので、そちらについては別途エントリを書くつもりです。 様々な話を聞いた上で、1月末の時点では自分でもわかっていなかったことがわかりました。最終的に重視したのは以下の点です。 技術ベンチャーであること ベンチャー企業として大きな成功を狙っていること、またそれが有望に見えること 優秀なプログラマが同僚に多いこと 退職エントリに書いた観点のほかに、この3点が今回の自分にとって重要だということは後から見えてきたことでした。 ということで Treasure Data に入社しました。Softwar
Datastore Masakari Talksやった #dsmasakari - たごもりすメモ
Datastore Masakari Talksっていう名前でやったら面白いんじゃね？ という話で @shot6 さんと盛り上がって、そのまま会場を手配してもらったので二人して面白駆動な感じでやった。 Datastore Masakari Talks - connpass これがまた大変面白い感じになったのでよかった。 勉強会に Masakari とついていて話すのを敬遠した人もいたみたいだけど、普通の神経の人はしゃべってる人のことを面罵したりはしないし、普通でない人というのは業界にほとんどいないので、要するに普通の勉強会だった。「DISることしか言ってはいけません」的なレギュレーションは使ってれば問題のあるところって普通見付かるよね、という前提のもとに決めたもので、要するに普通に使っていて感じたことを話してほしいじゃんね、みたいな感じ。 自分も2年前に使うのをやめたデータストア、Kyot
fluentdとシステム設計の小ネタ - たごもりすメモ
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
uuidtools gemの新版がリリースされました - たごもりすメモ
https://rubygems.org/gems/uuidtools uuidtoolsという便利なgemがありましてその名の通りuuidの生成に使えるものでしたが、その機能のうちMACアドレスからuuidを生成するという部分がifconfig外部コマンドに依存していました。 で、みなさんご存知の通りRHEL/CentOS 7ではこのifconfigコマンドが標準でインストールされなくなり、正常に動作しなくなりました。これに伴った修正がuuidtools gemでも行われましたが、長くリリースされない状況でした。 https://github.com/sporkmonger/uuidtools/issues/24 が、先日無事リリースされたため、みなさんアップデートしましょう、自分で作っているgemがuuidtools依存しているなら 2.1.5 以降に依存するよう変更しましょう、という
NATやファイアウォールの向こうへデータをお届けする fluent-plugin-pull_forward を書いた - たごもりすメモ
Fluentdにおけるネットワークごしデータ転送プラグインといえば forward が組み込みであるし、通信路を暗号化したければ secure-forward がある。 しかしこれらFluentdのネットワーク転送プラグインは基本的に全て送信元から送信先に対してプッシュする形になっており、ネットワーク接続も送信元から送信先に対して行うことになっている。このため送信先のFluentdがNAT下にある場合やファイアウォールで保護された場所にある場合、もしくはダイヤルアップ接続……は、まあ今は無いだろうけど、例えば移動するデバイス上にある場合など、こういったときにはうまくデータの転送を行う構成がとれない。 なぜこういう状況、つまりプッシュ型で転送を行うプラグインばかりなのかというと、FluentdのBuffer pluginの仕組みによる。細かく設計上の話をあれこれしてもアレだし面倒くさいので省
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
FluentdでバッファつきOutputPluginを使うときのデフォルト値 - たごもりすメモ
なんか自分で docs.fluentd.org へのpatchを書いてて混乱してきたのでまとめる。コードを読んでも関係する設定値がいくつものモジュールに分散しており、完全に把握することが困難である。具体的には、この組合せを記憶だけで答えられる fluentd コミッタはおそらく一人もいない。 概要 対象は BufferedOutput および TimeSlicedOutput を継承している output plugin の全て*1。out_forward, out_exec や out_exec_filter も含まれる。 基本的にはいくつかの設定により flush をするタイミングを制御するパラメータ一式、およびflush対象となるデータのチャンクを溜めておく量の上限を決めることとなる。fluentd をうっかり試したときに「アイエエエ、fluent-cat してみたんだけど、設定したと
Norikra v1.0.0 - たごもりすメモ
English article 以前からスキーマレスなストリーム処理をSQLで！というソフトウェアとして作っていたNorikra、このたびあちこち機能改善したりしたので、既にお仕事で絶賛稼働中ということもあるし、区切りとして v1.0.0 としてリリースした。 ついでにロゴとかも作ったので、なんとなくいい感じになりつつある。 https://rubygems.org/gems/norikra/versions/1.0.0-java http://norikra.github.io/ 修正点は リポジトリ のChangesに書いてあるが、curlだけで操作できるようHTTP JSON APIが加わってたり、GCまわりでハマらないようなデフォルトオプションが入ってたり、分析系クエリを書きたい人のために Group-by with Rollup や Grouping sets, Cube などの
業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ
先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を
4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、
serverspecのアーキテクチャ - たごもりすメモ
serverspecは以下のようなソフトウェアですね。 サーバがどのような状態かをRuby DSL(RSpec記法)で記述する 記述されたspecの状態になっているかどうかをチェックする チェックはローカルマシンに対して行われるか、もしくはSSHを経由してリモートサーバに対して行われる チェックはOSコマンドを叩くことによって行われる これがどのように有用なのはかもうあちこちに書かれているので置いておいて、アーキテクチャを理解すると、以下のようなことがわかります。 specの実行にはRubyが必要 チェック対象サーバにはRubyは必要「ではない」 なので、チェック対象サーバの状態を取得するためにRubyの機能が問題になることはありません。もしうまく状態をとれていない項目があればそれはspecの書き方が悪いか、あるいはOSコマンドに落とす部分(matcher)がうまく作れていないかなので、ど
tagomorisとDMM.comのはなし - たごもりすメモ
前にこんなblogエントリを書いた。 dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ このエントリ、Cassandra Casualという勉強会でCassandraのようなそうでないような話を聞きながら、しかもビール2本飲んだ状態で書いたものだった。書いてさっさと公開して放っておいた*1ところ、だいぶ経ってはてブがやたらとついていることにびっくりしたものだった。 正直に言おう。対象はなんでもよかったんだ。世間に知られている大規模インターネットサービスを運営していて、会社としての・中の人としての雑誌記事やイベント登壇やblogエントリがあまり見られない企業であれば。DMMでなくても、たとえばFC2でも楽天でもNTT docomoでもY!Jでもドワンゴでも。 もちろんどんな会社の人でも行くべきところに行けば中の人がいるのは知っているけれども、そういう話じゃない。単に
クラウド環境の設計指針をどう決めるか - たごもりすメモ
クラウドに限らず、データセンタの設計全般に言えることだけど。 コンピューティング基盤をどのように設計するかには根本から異なるアーキテクチャが様々あって、ある特定の方向のアーキテクチャについても実現するためのソフトウェアやハードウェアに様々なものがある。 合議制で決めてはいけない。何を採用するか、どのように設計するかについては、誰かが英知をもって決断するべきだ。それも可能な限り素早く。 今更言うまでもないことだが、この世界は技術の変化が非常に速い。おそらく3年経てば優位な技術は入れ替わっていて、何か新しいトレンドとか技術要素だとかいったものが登場しているだろう。 そんな中で何を採用するかについて、長い時間をかけるのは簡単だ。3年かけて実機を多数揃えて比較検討すれば、検討開始からの3年間で何が優位だったかが確実にわかるだろう。 おそらくその頃には別の技術が登場し、更に3年の比較検討が必要になっ
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
isucon3本戦いってきた＆勝ってきた！ #isucon - たごもりすメモ
isucon3の本戦にLINE選抜チームとして出た。ガッカリな感じだった予選時の状況はこちら。 isucon3予選参戦の記録 - tagomorisのメモ置き場 引き続き @kazeburo @sugyan @tagomoris の3人チーム。 ざっくりまとめ みんなこれまでこんな楽しいイベントに参加してたのか！ ずるい！！！！！！ 普段やってることを普段通りやる、と思っていたが焦って普段やらないようなミスを次々連発、社会は厳しい 思いきった構成変更とかできるのがisuconでしょｗｗｗｗ とかドヤ顔していたが、やりきれた。ドヤッ。 これからisuconという名前を口にするときに堂々とドヤ顔しようと思います。嘘です。元出題者のくせに成績出ないとかｗｗｗみたいにならなくて本当に安心しました。終わったあとのビールおいしかったです。 ということで、勝ちました。優勝と、あと僅差で特別賞もいただきま
OSS CEP Server 'Norikra' v0.0.1 released! - たごもりすメモ
みんな大好きFluentdはプラグインも自由に書けて好き放題にリアルタイム集計を行うことが可能なわけですが、やりたい処理にあわせて無限にプラグインを書き続けてるとプラグインの数が爆発し何がどんな処理をしているのかもよくわからず混乱の海に呑まれて消えるという未来がみなさんの脳裏にもおそらく想像されていることと思います。 で、世の中にはCEPエンジンというものがあってストリーム状に流れてくるイベントデータに対して処理を行う仕組みがあるわけですね。これ使いたい！ しかもあれだ、簡単に処理が書けるものがいい！ 何が言いたいかと言うとWE NEEEED xQL!!!!!!!!!!!!!!! そんなようなことをこちらのエントリを書いたときに思ったわけです。 http://tagomoris.hatenablog.com/entry/2013/02/19/142017 で、RubyKaigiにも通っちゃ
dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ
dmmは世の中のオトコノコにとっていろいろと言及するのに躊躇いつつ誰でも知っているアレなわけです。で、それなりの規模のWebサービスの裏側を見たことがある人なら誰でも、dmmの裏側はきっと物凄いことになっているに違いない、ということが想像がつくわけですね。 簡単に思い付く範囲でも以下のようなものがあります。 膨大な画像(サムネイル)および実コンテンツ(画像、動画、ソフトウェア圧縮ファイル)を配信するトラフィック しかもトップ数パーセントだけではなく、おそらくかなり裾野が広いトラフィック 膨大な商品の高速な列挙・表示 膨大な商品に関するタグつけ 膨大な商品に関する自然言語による全文検索 全トラフィックにおける膨大な量の課金・決済トランザクション 実物の通信販売に決済結果を載せる流通関連の問題 大勢のユーザに対して膨大な商品から適切に行うためのレコメンデーション これだけのことをやっているから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
