http://techblog.netflix.com/2013/10/introducing-chaos-to-c.html 「歴史上の有名な開発プロジェクトからまなぶべきこと」をまとめていたときに、Videoの中で、ある大型ロケットエンジンの開発において、信頼性テストのために小型爆弾をエンジンの噴射口辺りで爆発させて耐性を調べた云々のエピソードが紹介されていて、更に続いて「ネット業界で同じようなことをやってるのはNetflixぐらいだ。」という説明がありました。その時は何のことだかよくわからなかったのでブログでは取り上げなかったのですが、今回見つけました。 以前紹介したように、北米のインターネットトラフィックの30%以上を占めるNeflixはインフラをAmazonに全面的に移行しています。クラウドに移行した後の学びとして、 自社データセンターの時は、個別のハードウェアインスタンスが障害

マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。 1) 非同期 & 可視化が進む GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。 2) マネージャの役割が変わる 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。 プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向

http://paulstamatiou.com/twitter-video/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 38分前 フレームワークやツールが進化することで、そこそこのスキルがあれば比較的短い期間でもそれなりのプロダクトをつくれるようになるという恩恵を世の中全体が享受できますが、一方で才能のある人たちは、その便利になった道具を利用して、更に先に進みます。そしてUIの競争は際限なく続きます。 一つの目のパターンは、意外なところまで気遣いをしているので、それを発見したときにポジティブな喜び、驚きを感じるところ。 Slackを使っていると、 登録済のパスワードの入力を求められる画面で、スマホキーボードでのパスワード入力を面倒に思う人、もしくはパスワードが長い人に配慮して、「パスワードを入力する替わり

http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか？その障害がゆっくりと起きたらどうか？ システムをどのようにスムーズにデグレードさせることができるか？ システムは想定以上の負荷にどう対処するようになっているか？ 大きな障害が起き

Googleで分散システムの開発をてがけ、現在はソーシャルメディア mttr.toを立上げ中のBen Sigelmanが、Goを分散システムの開発に利用する場合の、メリットおよびチャレンジについて講演しています。 分散システムのあるべき姿 分散システムの勘所は、最上位ビットをパフォーマンス的にも構造的にもうまく扱うことができるかというのがポイント。その効果が一番大きい。スループットの改善のような詳細は、自分もGoogleでそれに取組んだけれども、9ヶ月くらいたつとハードウェアの性能で解決される可能性が高い。また、構造的にというのは、なるべく小さなコンポーネントを組み合わせたシステムにできるかという意味。 Goのよいところは、 両方、とくに後者によい。Railsだとアプリを複数個用意して並列処理するのは大変だったけど、Goだとシンプルにできて、標準ライブラリも読みやすいとかなどなど。パフォー

https://www.youtube.com/watch?v=B1Wt8s4LEfk 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 10/29に開催されたSecurity@Scaleのカンファレンスで、興味深いと思った話題を拾ってみました。 SquareのDiogo Monicaの講演は、障害/脆弱性に対応する社内システムをどのように自動化 / 最適化させてきたかというテーマ。 脆弱性の種別（XSS等） x セキュリティゾーン（システムのどの箇所にとって脅威になるかを3段階に分類。DBに近い方が危険性が高い。）でスコア化することで、対応のために発行されるチケットは自動的に優先付けされる。 SLA（サービスレベルアグリーメント）において、例えば、P0は24時間以内、P1は7日以内、P2は30日以内と

サービスを一から立ち上げる場合も、成功したサービスが更に拡大する場合も、いずれもスケールさせるのは一苦労ですが、今回は、Dropboxの初期の取組みと、Facebookの最近の動きを取り上げてみます。 まずは、DropboxのKevin Modzelewskiが、創業当初のサーバインフラの進化を時系列で紹介している講演から。 Dropboxのデータの特徴 書込みボリューム大: 通常のサービスはコンテンツをつくるより消費するボリュームが圧倒的に多いので、read/write比率が、100:1とか1000:1であるのが典型だが、Dropboxはユーザの全端末がコピーを持つ構造なので、その比率が約1:1になる。つまり、同じサーバに対して、他社よりも100倍、1000倍書込みの役割が大きくなる構造。 ACID特性の要件をしっかり守る必要がある。ユーザの情報を預かるのだから、原子性について、「大きな

https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの

Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。 同社のAPIは現在、 エンドポイント: 106 バージョン: 65 APIクライアント: 6 ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。 1) ユーザが利用するバージョン情報の把握 ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で保管している。それ以降、ユーザ企業はバージョンのことを意識することなく、最初のバージョンのAPIを利用し続けることができるようにしている。ユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。 2) バージョンと機能の整合性 YAMLファイルでバージョンとその振舞いの情報

https://www.youtube.com/watch?v=ySW6Yk_DerY Rustについては「Rustのあれこれ」で少し触れましたが、Yehuda Katzが、Skylightの一連のブログとGoGaRuCo2014の講演で、「ハイレベル言語のプログラマーがシステムレベルの言語を学ぶチャンス」という観点で紹介しています。 主なポイントとしては、 プログラミング言語の特性は変わることがないとか、プログラミング言語のパフォーマンスと生産性は常にトレードオフであるという考え方は、JavaScriptにおいて、生産性が少し改善されつつ同時にパフォーマンスが大きく向上してきたという事実から、必ずしも正しくはない。 Rustは、セグメンテーション違反が起きないという意味での安全性と、どこにメモリを置くか直接コントロールできる仕様を両方兼ね備える。 Rustを学ぶということは、ハイレベル言

https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿

http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers/answer/Jeff-Darcy? 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 スポーツにしろ、勉強にしろ、仕事にしろ、何をやるにもその特定の分野でトップ1%人は尊敬するほどすごいのですが、本人が長く続けつつ努力をしてきたことが垣間見えるので、なぜ優秀なのかというのが理解できる範囲。ただし、そのさらにトップ10%、いわゆる世の中でその分野のトップ0.1%の人というのは、すごすぎて、どうしてそうなれるのかが分からないと実感することがあります。議論している時に、数歩先の真理を理路整然と突然読み取って指摘されるような、驚くようなセンスを見せつけられる経験を数

https://www.youtube.com/watch?v=r7qN8QwGv2w 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 MesosConのキーノートスピーチを紹介します。 まずは、Apache MesosのProgram Chairを務めるTwitterのBenjamin Hindmanが、Mesosの目指す立ち位置について、 現代において「他のコンピュータ」と形容すると、データセンターを指すケースが多い。 アプリを動かすコンピュータという見地からは、PC / タブレット / スマホ / サーバにOSがあるように、データセンターにもOSが必要。 Mesosは、データセンターのOSである。つまり、分散システムにおけるkernelの役割を担う。 そのエコシステムの広がりは、 Mesosとつ

http://corner.squareup.com/2014/09/squares-api.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 SOAにおけるサービス間のコミュニケーションについては、CODE CLIMATEにおいて、Protocol Buffers vs JSONという比較が取り上げられていて、「ブラウザやJavaScriptが直接データを利用しないケース、特に内部サービス間のコミュニケーションにはProtocol Buffersの方が向いているのでは。」と紹介されています。 せっかく整合性のあるデータ構造を用意しても、サービス間のデータのやり取りの際に苦労させられることが多い。Protocol BuffersならProtoフォーマットにしてエンコーディングするだけで、意図す

https://techblog.livingsocial.com/blog/2014/08/26/soa-series-part-5-testing-apps-with-service-dependencies/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約3時間前 LivingSocialのRailsアプリSOAシリーズの5回目として、サービス指向アーキテクチャにおけるテストのあり方についての話。 まずは、アプリ間のサービスコールを全てmock/stubしたり、逆に依存関係を常にそのまま利用するのではなく、1回だけコールする手法を推薦しています。 テスト対象のコードは、依存するサービスに一度だけコール & レスポンスを記録し、その後の実行ではリプレイを利用する。 メリット ネットワークコールが一度で済むの

https://www.youtube.com/watch?v=mVN7aTqr550 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Code ClimateのBryan HelmkampのRedDotRuby 2014での講演です。ビデオの前半の30分は、Docker + Rubyアプリのユースケースの場合の、概要/ツール紹介/デモです。ここでは、後半に語られているDockerのバリューについて、まとめてみます。 デリバリーの単位 Rubyエンジニアとして、デリバリーするときの単位という概念が今まではなかった（が、Dockerで実現できた）。かつて、JRubyでしばらく開発していたときがあって、その際は、jarファイルの中身がなんであれ、テストして問題なければ、DevOpsチームに渡すだけ。ある意

http://www.centurylinklabs.com/optimizing-docker-images/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 米国キャリアのリサーチ部門であるCenturyLink Labsが、 Dockerイメージは1Gを超えることがよくあって、ローカルで実験しているうちはよいが、ネットワークを介して頻繁にやり取りしはじめると、サイズが問題になる。 ということで、dockerイメージのサイズを減らす取り組みについて、ブログで紹介しています。 Layers レイヤの構成の詳細については、Dockerのドキュメントを参照されたし。本議論のポイントとして理解しておかなくてはいけないのは、Dockerfileでの各操作の結果、新しいイメージのレイヤが順次生成されるというこ

http://company.myshopify.com/blogs/technology/14909841-kafka-producer-pipeline-for-ruby-on-rails 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 オンラインストア & リアルショップ向けのアプリを提供しているShopifyがブログでKafkaの導入について紹介しています。 Kafkaに限らず、Google / Facebook / Twitter / LinkedInなど大手がオープンソースで取組んできたApache系の大規模分散システム向けのソリューションを、他のネット企業もサービスが成長してきたら導入するという話しが続いていますが、このShopifyのように、「魅力的なソリューションに見えるけど、Lin

https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ（apt, yum, gem等）レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい

https://www.youtube.com/watch?v=Iebb5dXaScE 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 GopherCon 2014における、PoptipのCEOであるKelsey Falterの講演。同社はCNN、ESPN、L’Orealなどメディア & コンシューマグッズ大手に、ソーシャルメディアコンテンツの分析やアンケートのプラットフォームを提供しているNew Yorkのスタートアップです。 最初はNode.jsで開発したが、スタートアップにありがちな大手顧客の対応のためのスケールアップと、平行して資金調達活動を続ける中での時間がないバタバタの状況で、 インスタンスが落ちるとシングルポイント障害点になってしまう。ホストしているサーバの障害やアプリのクラッシュなどが