先日は瞬殺で作るMesos + Chronos + Marathon + Dockerクラスタ環境で書いた通り、Mesosの環境を作ったのですが、今回はマイクロソフトが発表したService Fabricを触ってみました。実際触ってみるとかなり面白い感じなので、皆さんにも共有してみたいと思います。 Service Fabricとは Azure Service Fabricはマイクロサービスベースのアプリケーションを素早く開発するためのPaaSです。 マイクロサービスとは その前にそもそもマイクロサービスとは何でしょうか？マイクロサービスはマーチンファウラー氏が提唱した用語です。具体的なイメージはこの記事がわかりやすいです。モノリシックなRubyからGoによるマイクロサービスへ 上記マーチンファウラー氏のMicroservicesのページより 今までのアプリケーションは例えば私も大好きなRu

toyama0919/fluent-plugin-http_shadowというShadow Proxyっぽいことを簡単にやるプラグインを作りました。 production環境で半年くらい動かしてたのでメモしときます。 「Fluentd Meetup 2015 夏」で実際のユースケースを発表しました。 Shadow Proxyサーバとは Shadow Proxyサーバについては以下がわかりやすいです。 気軽なMySQLバージョンアップ - まめ畑 Go言語を含む複数種類の言語により実装されたソフトウェアのベンチマーク - Qiita 実装としては以下のようなものが公開されています。 cookpad/kage lestrrat/p5-Geest kentaro/delta 本番のリクエストをそのままバックエンドにあるサーバーに複製して送信するのですが、アプリケーションの規模が大きくなればなるほ

Help us understand the problem. What is going on with this article?

MongoDBを使うシステムが、最近多いと思います。 2.6系(安定版)の最新2.6.7ですが、Date型のインポート処理にバグがありそうです。 「1970/01/01」以前の Date型 を mongoexport すると、負の "$numberLong" として出力されるのですが、それを mongoimport すると、それ以降のフィールドが欠落してしまうのです。 例えば、ユーザマスタに「誕生日」フィールドがあると、45歳以上の人は「1970/01/01」以前の値が入っているわけで、マスタデータを移行したりでもすると、その人のフィールドがガッツリ無くなってしまいます。でも若手は大丈夫だから「どうせ部長の使い方がおかしいんでしょwww」といういつもの「偉い人に限って障害が発生する」パターンが展開されます。 大急ぎで調べた所、以下が判明しました。 2.6形式 "1965-11-17T00:

※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 （ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…） 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部

まず、 非常に大事なことですがこの表における価格はおおよその価格になります。あくまでも おおよその価格です。大事なことなので2回言いました。理由は後ほど説明します。 上記のようにLambdaファンクションに設定可能なメモリ量に応じて価格が変動します。メモリは最小128MBであり、64MB単位で設定することが可能で、最大で1024MB=1GBとなっています。最大の特徴はやはり100ミリ秒あたりとなっていることで、他のサービスと異なってかなり粒度が細かくなっています。これはLambdaはあくまでもイベントドリブンの関数実行であり、従来の長時間のバッチ処理の代替ではないということを表しているとも言えます。 また、メモリ容量に応じて単価が異なるだけでなく、CPU能力やIO能力も異なってきます。メモリ量を多く設定するとこれらの能力もあがるということですね。この辺りの話からLambdaの裏側に関して何

今年は始めて、re:Inventに参加してきたので、その際に見た「Amazon DynamoDB: Data Modeling and Scaling Best Practices」というセッションの内容を共有したいと思います。 内容をだいぶ端折ってるので、間違っている場合には、びしばしツッコミいただければと思います。 では、まいります。 1. CacheはCashなり なんでDynamoDBを使うかといえば、やっぱり、ポチポチっと設定するだけで簡単に読み込み、書き込み性能を上げたり、下げたりできるっていうのが大きなポイントかと思います。 ただ、設定した性能も、データのアクセスパターンによっては思い通りの性能が出ないことがあります。 例えば、ReadCapacityを 100から5,000 に上げたとします。そうると、DynamoDBは、「オレ１人では捌き切れない」と思って、パーティション

こんにちは。Treasure Dataの斉藤です。出張中に時間ができたのでシアトル空港でこの記事を書いています。日本語でブログを書くのはものすごく久しぶりなのですが、Treasure Dataの列志向(columnar)圧縮ストレージであるPlazmaDBについて紹介していきたいと思います。 Treasure Dataでは2014年現在まで5兆(trillion)件を超えるレコードが取り込まれており、一秒あたりでは40万以上(!)のレコードを処理しています。 2013年のTwitterでは１秒あたり5,700 tweets処理していたとのことなので、その処理量の大きさが実感できるのではないでしょうか。この量のレコードをそのまま蓄積するのではストレージ量が膨大になってしまいますので、Treasure Dataではレコードを列分解し、MessagePack形式に変換＋圧縮処理を施すことでデータ

Fluentd v0.12 がリリースされました。git log を見るに v0.10.1 がリリースされたのは 2011/10/16 とのことなので、３年越しのメジャーバージョンアップとなりました。自分が Fluentd の開発に携わってから初ですね。感慨深い。 Fluentd v0.12 には Fluentd v0.12 is Released で言及されているように、今まであった Input プラグイン、Output プラグインに加えて、Filter プラグイン という仕組みが追加されています。本記事ではその使い方、および作り方を解説します。 2014/12/30更新 v0.12.2 で filter メソッドで nil を返すとメッセージを削れるようになったので記事を修正。cf. #515 合わせて v0.12.2 で、Filter プラグインのテストヘルパーが追加されたのでテスト

ドワンゴがニコ動の画像配信向けにFPGAエンジニアを募集したり、マイクロソフトはBingをFPGA実装したり、Baiduもディープラーニングの高速化にFPGAを導入したりと、なんだか世の中急にハードウェアくさくなってきた。IoTとは違う意味で。 金融分野ではすでにCPUでは遅すぎてFPGAによるナノ秒単位の株取引が行われているって記事を書いたのは2年前だけど、ここ数年はIntelのCPUのクロックもあまり上がらなくなってきたし、Fusion-ioやNetezzaといった大手御用達のハイエンド鬼速ストレージも、フタを開ければ中身はすでにFPGAに移行済み。IBMが最近出したData Engine for NoSQLという製品ではPOWER8プロセッサにFPGAを直付けしてRedisを高速化したり。いよいよデータセンターにも、先の見えないCPUに代わってFPGAやGPUを導入する波が押し寄せつ

このガイドラインについて こちらのガイドラインは社内のバッチ処理スクリプト開発にあたっての、安定運用等に関わるガイドラインを公開用に書きなおしたものになります。 バッチサーバ規則 基礎項目 以下の要項を満たすことを確認する その他の用途で動作しているサーバ上での動作は行っていないこと 運用期間中に想定しうるデータ量にてOOMキラーに殺されないこと 想定の時間で終了すること データの読み込みは極力Read Replicaを見ていること データの書き込みによる本番サーバへの影響が見積もれていること 冪等性が担保されており、何度実行しても処理上の不具合は発生しないこと 多重実行時に不整合が発生しないこと エラー時の社内への通知が用意されていること エラー時の通知には再処理のための手順が揃っていること、もしくはそのドキュメントの場所が示されていること 個人ユーザー下にログや成果物を絶対に書き込んで

---- ---- ---- 追記: 2015/10/12 今では Datadog の公式エージェント (dd-agent) に組み込まれているので、How to monitor Fluentd with Datadog を読むことをオススメします。 ---- ---- ---- Fluentd のバッファ監視といえば、弊社の @moaikids さんが書いた munin-fluentd をはじめとして、いくつか既存のソリューションがありますが、弊社のメトリクス監視を Datadog に移行するタイミングで、munin-fluentd と同じ監視が Datadog にも欲しいよねということになって書いたので、それを紹介したいと思います。 Datadog Fluentd Integration 一言で説明すると、munin-fluentd と同じように、output プラグイン毎の retr

例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

うちの息子（９）はいっつも「おとうさんいつ帰ってくるの？」と聞くそうだ。そんな息子のニーズに応え、おとうさんいまどこメーターを日曜工作で作ってみた（最初は天気予報メーターにしようと思ったけど息子にいらんと却下された）。 スマホのWiFiとGPSの位置情報をIFTTTで拾ってcloudBitでサーボを動かす簡単なしくみ。電子工作の経験は不要で、こーいうのを子どもでも誰でも30分くらいで作れてしまう。cloudBit is AWESOMEである。 以下、このメーターの作り方を簡単にまとめ。 littleBitsって？ まずはlittleBitsを知らない人のために簡単に紹介しておこう。littleBitsは子供が遊びながら電子工作を学べるおもちゃで、ボタンやLED、モーター、光センサーといったいろんな電子部品のモジュールを組み合わせて回路を組める。電子工作っても、難易度はパズドラより低い。モジ

(9/2/2014　追記：何故か後編の記事が削除されていましたので、分割後修正して再アップしました。） はじめに この記事は実際に手を動かし、コンピュータを使ってデータ可視化を行う人に向けて一般的なノウハウをお伝えする三回シリーズの第二回です。 前編: 効果的なデータ可視化とはどのようなものか？ 中編: 分かりにくい可視化を避けるための手法の選択 後編: Part 1 基本原則 後編: Part 2 学習ガイド わかりにくい可視化 昨夜寝る前に気づいたのですが、前回のプログラマ向けのニッチな記事をはてなブックマークのヘッドラインで見かけて驚きました。そしてその中に鋭いコメントを発見しました: この手のグラフ系の可視化で本当に知見が得られたの？って思ってしまうな。わかりにくい。 これはまさにその通りで、これこそ私がこの記事をまとめようと思った理由の一つです。身も蓋もない事実を申し上げますと、

このシリーズは、Cytoscapeを使ってやIPython Notebook、Pandasなどのオープンソースツールを利用し、公開データを元に実際のグラフ可視化を行う過程を紹介する、可視化の実践者向けの記事です。 第一回 第二回 第三回 第四回 グラフ可視化ソフトCytoscapeによる地理情報データの可視化 (Cytoscapeによる東京周辺の路線図可視化。ハイレゾ版はこちら) はじめに 現代の地図はグラフです。そもそも数学的グラフの研究は現実世界の経路問題から始まりました(ケーニヒスベルクの問題)。計算機科学を専攻した方は、学生時代に単純化した最短経路検索や各種経路問題を課題で解いた記憶があるかと思います。そして恐らくそこでクラスNPの問題がどういうものかとか、NP困難とは何か等々込み入った話もそこで知ったはずです。とても身近に見える問題群が複雑な数学の世界に繋がっていることはとても興

効果的にコミュニケーションする 会話は相手と共感するところから始めます。言いたいことは同じでも、言い方を工夫することで相手とより良いコミュニケーションをとることができます。 うまく物事が伝わらないと思ったら、言い方を変えてみましょう。 だめだと分かりながらついついやってしまった自分の過去を反省しつつ、参考にしていただければと思い公開します。

そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A

竹内関数は関数呼出のオーバーヘッドのベンチマークやメモ化の例題としてよく挙げられます。 では分散処理言語で竹内関数を実装してみましょう。 分散処理言語では、多数の計算資源へ多数のタスクを良い感じに割り当てて分散処理する、といった事にフォーカスしてデザインされています。「良い感じ」というのには、対象となる処理の特性やネットワークの特性などによって様々なゴールがあるので、まあ色々です。 で、ちょうど、良い感じの分散処理スクリプト言語のSwiftが見つかったのでこれでやってみます。 Swiftではプロシージャ単位で良い感じに分散処理されます。竹内関数をプロシージャとして実装すると、全然良くない感じになるので、分散処理のオーバーヘッドがベンチマークができるはずです。 では実装してみます。プロシージャ名をtとして実装します。Swiftでは名前付の多値引数と多値返値が扱えます。返値はreturn文で返

（この記事は WWDC 2014 の直後に書かれました。内容は2014年時点のものです。本文中の「Swift」や「iOS 8」は当時まだベータ版だったソフトウェアを指します。） TL;DR WWDC で発表された情報と、一般公開されている Apple のドキュメントに含まれる情報は NDA に抵触しない。よってそれらの範囲で Swift や iOS 8 に関する情報はセーフ。しかしスクリーンショットの公開は不可。 この記事の内容に法的な保証はないので、不安なら Mac (or iOS) Developer Program License Agreement の条項10.1 Information Deemed Apple Confidential を参照のうえ、弁護士に相談すること。 関連リンク：自分の Apple Developer アカウントで同意した契約書の一覧ページ（要ログイン）