Dropbox での同期のテスト 確信を持って同期の中核コードを書き換えるまで
0 0 5 0 Dropbox の同期エンジンのコードを完全に書き換えるのは、困難な道のりでした（その目標と決断までの詳細については、以前の投稿をご覧ください）。コードの書き換えとは、運用中に膨大な数のユーザーのマシンで稼働している Dropbox を支えるエンジンを入れ替えることです。正しくコードを書き換えるには、テストの自動化に本腰を入れる必要がありました。私たちが策定したテスト戦略のおかげで、コードを書き換えている間、いつでも正しい方向に向かっていると確信が持てました。このおかげで現在も、短いリリース周期で新機能の開発と出荷を続けることができます。 ここでは、最初に新しい同期エンジン「Nucleus」の設計に反映したテスタビリティの検討事項と、テストしやすいアーキテクチャ上に構築したランダム化テスト システムの一部について説明していきます。 目次 テスタビリティ 1-1. プロトコル
同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
Bugs Everywhere
What is Bugs Everywhere? Bugs Everywhere is a “distributed bugtracker”, designed to complement distributed revision control systems. By using distributed revision control as a backend for bug state, we gain several convenient features: Bugs and code that live on branches are tracked together—when a branch is merged, both the code changes and bug changes that the branch contains are merged alongsid
分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
How to hack metacpan.org
YAPC::Asia 2014 Reject con LT 2014-09-03
HDFS HA セミナー #hadoop
2013/05/30に開催した、HDFS HA(High Availability: 高可用性)セミナーの資料です。同じくご登壇頂いた、株式会社サイバーエージェントの上原誠様の資料は↓です。 http://www.slideshare.net/makotouehara39/cl-st-20130530nnhaRead less
Winnyの通信解読に挑戦！
Winnyの通信を特定する方法には，「流れるパケットのパターン（トラフィック・パターン）を調べる方法」と，「パケットの中身を調べてWinnyのパケットであることを確認する方法」の2通りがある。前者は，直接中身のデータをのぞいているわけではないため，通信の秘密を守るという大前提があるプロバイダがWinnyを規制する際に使っている。しかし，Winnyの通信を確実に特定するなら，後者の方法がベストである。実際にWinnyの通信を解読できるのか，Winny作者の金子勇氏の著書『Winnyの技術』やインターネットで得られた情報などを参考に挑戦してみた。 Winny（ウイニー）同士の通信はすべて暗号化されている。このため，流れるパケットをのぞいても，内容がどんなものなのかだけでなく，Winnyの通信なのかどうかも，ひと目ではわからない。Winnyが採用している暗号アルゴリズムRC4は，Webアクセスや
4Gamer.net — [CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た，ゲームデザインの大原則
[CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た，ゲームデザインの大原則 編集部：touge 先週行われた「CEDEC 2010」の講演から「ネットワークゲームの仕組みとゲームデザイン」と題されたセッションを紹介しよう。 「CEDEC 2010」公式サイト 登壇したのは，セガ第三CS研究開発部のテクニカルディレクター 節政暁生氏。節政氏は「ファンタシースター オンライン」シリーズのプログラマとして，長年ネットワークゲーム（オンラインゲーム）の開発を手がけてきてきた人物だ。この講演では，その経験からネットワークゲームのゲームデザインにおいて，気をつけるべきことについてのレクチャーが行われた。その内容には一部技術的な要素を含むものの，基本的にはプランナーに向けたものであるため，理解にそれほど専門的な知識は必要ない。いわばネットワークの基礎の基礎にあ
![4Gamer.net — [CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た，ゲームデザインの大原則](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba2b74f4bf8449048ce5025fbdac545d7519da6a/height=288;version=1;width=512/https%3A%2F%2Fwww.4gamer.net%2Fgames%2F105%2FG010549%2F20100905002%2FTN%2F002.jpg)
24 Days of GHC Extensions: Static Pointers
Today we start to wrap up 24 Days of GHC Extensions with the final guest post, this time from Mathieu Boespflug of Tweag I/O. Mathieu, along with his colleagues Facundo Domínguez and Alexander Vershilov, has been working with the GHC team on a new extension - in fact, so new, you won’t even find this in a stable release of GHC! In today’s post, we’ll have a look at a new type of pointer that can b
Notes on Distributed Systems for Young Bloods – Something Similar
I’ve been thinking about the lessons distributed systems engineers learn on the job. A great deal of our instruction is through scars made by mistakes made in production traffic. These scars are useful reminders, sure, but it’d be better to have more engineers with the full count of their fingers. New systems engineers will find the Fallacies of Distributed Computing and the CAP theorem as part of
分散ストレージ技術Cephの最新情報
Cephのアーキテクチャの解説、最新動向、ベンチマークや事例などを掲載したスライドです。 第1回サービスプロバイダー様向け技術勉強会Read less
Home
Get Started Learn how to build concurrent, distributed programs with Cloud Haskell Learn more Cloud Haskell: Erlang-style concurrent and distributed programming in Haskell. The Cloud Haskell Platform consists of a generic network transport API, libraries for sending static closures to remote nodes, a rich API for distributed programming and a set of platform libraries modelled after Erlang’s Open
AuroraのストレージのQuorum原理 - yoshidashingo
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 今回発表になった Amazon RDS for Aurora。最大の特徴はストレージが従来のRDS(Multi-AZ)における「完全同期なミラーディスク型のレプリケーション」方式でなく、「Quorumベースの非同期レプリケーション」方式が採用された点です。 Quorumの概念 Quorum自体の概念の説明はWikiなどを参照してください。ノード間で投票を行い、定足数が揃った処理を実行／破棄するという考え方です。 Quorum - Wikipedia 同期型のミラーディスク型から非同期のQuorum型へ Aurora以外のRDSのMulti-AZ配備は、マスターノードのディスクへの書き込みをブロックレベルでスタンバイ側に適用する完全同期なフィジカルレプリケーションを行っています。これにはいくつかの課題が考えら
Sharding を使いこなすための5つのTips - doryokujin's blog
@doryokujinです。今日も相変わらずMongoDBの、そしてShardingに関する記事を書こうと思います。 …と、その前にお知らせです！6月は2つのMongoDB勉強会を予定しております、是非ご参加下さい！ ・2011年6月11日（土） 「第4回 MongoDB 勉強会 in Tokyo」@フューチャーアーキテクト ・2011年6月28日（火）「第1回 MongoDB ソースコードリーディング」@PFI さて、それでは本題に入りたいと思います。 MongoDBのShardingといえば、 ・初期設定やShardの追加・削除といった導入の容易さ ・Shardの面倒をMongo側がずっと見てくれるという管理の容易さ を備えていると言うことで興味を持っておられる方も多数いると思います。 しかしその一方で実際にSharding環境を導入している方々の中の多くは、遭遇する様々な不都合や不整
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゲーム開発に携わる Web エンジニアへ贈る, 正しい Web サーバの作り方.
分散システムとして見たブロックチェーン (September 30, 2016)
IronFleet: 分散システム検証の方法論
https://www.ietf.org/proceedings/94/slides/slides-94-iss-1.pdf
オンラインゲームの仕組みと工夫
GitHub - cockroachdb/cockroach: CockroachDB - the open source, cloud-native distributed SQL database.
