ISUCON6参加者が実践したInfrastructure as CodeあるいはISUCON6のAzureインフラ解説 - まいんだーのはてなブログ
ISUCON6予選参加者の皆様、お疲れさまでした。 今回の ISUCON は Microsoft Azure ということで、多くの方にとってなじみのない環境だったと思います。 そこで、今回の ISUCON6 の予選問題がどのような仕組みで展開されているのか、Azure IaaSの仕組みを交えて解説します。 はじめに @matsuuさんの多大な努力によって、運営に提案しようと思っていた構成の大半がすでに作られていました。 使ったことのないクラウドを触り始めてすぐに作り上げてしまうのは、さすがです！ 復習される際はぜひ、@matsuuさんの作ったテンプレートを活用するとよいでしょう。 Azure IaaSの概要 Azureはおおむね国ごとにジオという単位で分けられており、その中に2つ以上のリージョンを持っています。 リージョンはそれぞれペアになるものが存在していて、日本では東日本と西日本がそれ
Microsoft に入社しました - まいんだーのはてなブログ
失業エントリからはや1ヶ月、新しいチャレンジとしてこの5月から Microsoft で働くことにしました。 前職では "どスタートアップ" からいっぱしの上場企業になるまでのサービス基盤をやり遂げることが出来ました。 が、ここ半年ちょい、運用系仕事を減らしていた最中は “開発シフトしていきたい” みたいなことを思ってはいたのですが、失業して時間ができたので改めて振り返ってみて思い直したのは “自分はやはり基盤側の方により興味関心が強い” ということでした。 また、ハウジングの物理基盤から IaaS + SaaS へ移行させる取り組みをして感じたのは “開発技術や運用基盤の選択は生産性と俊敏性をより重視すべき” というものでした。 実際 AWS で EC2 を使っているユーザが BigQuery で集計/分析したりするような事例は沢山出てきており、SaaS, PaaS をウマイこと組み合わせ
Fluentd と Norikra をもっとカジュアルに使おう - まいんだーのはてなブログ
Norikra とは Norikra とはリアルタイムイベントストリームに対して SQL ライクな言語で処理できる cool なプロダクトです。 例えば、Nginx のアクセスログを Norikra に流し込み、n分あたりのアクセス数やレスポンスタイムをリアルタイムに集計するといった事が可能です。 もちろん Nginx だけではなく、ご自身が書かれたアプリが出力するログも流し込んで集計できます。 更に Fluentd を組み合わせると GrowthForecast や Mackerel といったツールに集計結果を渡して可視化するなどといったことも容易なので、速報値集計やシステム運用状況の可視化に持ってこいです。 Fluentd と Norikra を活用して可視化する例 fluent-plugin-norikra と可視化ツール(GrowthForecast等)を組み合わせるとすぐに可視化
YAPC::Asia 2013 にて採択されたトークと、気になっているトークについて - まいんだーのはてなブログ
YAPC::Asia 2013 に submit していたトークが採択されました&気になってるトークについて書きます。 自分の予定トーク フルテストも 50ms で終わらせたい プロダクトが大きくなってくると、フルテストの実行が遅くなってリリースサイクルが遅くなり、ビジネスチャンスを逃したりやる気がなくなったりしますよね。 このトークでは、そういったプロダクトのテストの類型やCI、更にタイトルにある通りどのようにフルテストを高速に回しているかといったところをお話します。 Perl and Riak 今年から Riak を徐々に使い始めているので、その流れで得られた知見やアウトプットしたものの総決算的なトークにする予定です。 YAPCまでに打つ予定の新たな施策も内容に含められればと思ってます。 同僚のトーク宣伝 BrowserStack を用いたクライアントサイドのテスト FreakOut
MySQL Casualにおける 事前登録不要/先着順受付 という開催方式に関する報告 - まいんだーのはてなブログ
MySQL Casualという、気づくともう2,3年前くらいからやっているイベントがあります。 このほどそれの第四回を開催できる運びとなり、昨今言われている「ドタキャン/何も言わずに来ない」系のなんとやらをどうにかする施策を打ってみようと思ってやったことについてまとめみたいなのを書いておきます。 結論 参加者の方々を細かく追わなくて良いが、不特定多数を相手にする必要がある場合は今回MySQL Casualが取った「事前登録不要/先着順受付/指定時間で締め切り」という手法が有効です。 参加者の方々を細かく追う必要がある場合においても、受付でケア出来るのであれば有効です。 今後のMySQL Casualについては基本「事前登録不要/先着順受付/指定時間で締め切り」というやり方で行こうと思います。 なぜそうするのか 事前登録した瞬間は行きたいと思っていても、当日までに事情が変わるケースというのは
Perl から Riak を使うために Test::riak を書いた - まいんだーのはてなブログ
分散データストアって悩ましい問題がいろいろありますよね、特にスケールとパフォーマンス。 クライアント側で Consistent Hashing する、いわゆる Memcached プロトコル互換のプロダクトはいっぱいありますが、そういうものだとスケールするときにいろいろと大変です。 いわゆる「引越し先から読んで、なかったら引越し元から読み、引越し先に書く」みたいな対応が必要になってしまいます。 例えば5台を7台に広げたい場合、運用中の5台とは別に7台用意する必要があって面倒です。 そういうのを解決するプロダクトとして最近いくつか注目されているものがありますが、何処からか聞こえてきた「Riakいいみたいだよ」という一声から、検証のため Test::riak を書きました。 とは言え自分は Riak はもちろんのこと Erlang にはぜんぜん造詣がないので、なかなかドロ仕事をしているモジュー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
