Googleに転職していきなり3ヶ月の育休を貰った - Software Transactional Memo
TL;DR アフィ記事です 転職してからすっかりSNSで音沙汰がなくなったなkumagiと一部の界隈で噂されているようですが、twitterやFacebookにはたまに書いていたように娘が産まれました。 Googleでは子供が生まれた時に育休を取ることができる。 単なる育児休業は育児・介護休業法に定められた労働者の権利であるけれど、Googleではそれに加えて3ヶ月間フルに給料が支払われる有給休暇が付与される*1。これに加えて雇用保険から給付金をもらう育休を取っても良いとされているが、ソフトウェアエンジニア的な意味で遅れを取り過ぎるのも憚られたのでまずは3ヶ月の有給休暇をありがたく頂戴することにした。 授乳について 3ヶ月までの赤ちゃんは昼夜問わず3時間おきに母乳やミルクを欲しがる。大抵の成人は3時間おきに母乳やミルクを与え続けると精神的にだいぶ参ってくるという知見が広く共有されていたので
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
『夢のデータベース？「Cloud Spanner」の実力は？』について - Software Transactional Memo
こんな記事が目に入った。 www.itmedia.co.jp 大雑把に完全に間違ったことを言っているわけでもないが、読んでいくといろいろ鼻につくところがあり、どのあたりから間違っているのかと自分に問いただすのは現時点での自分の知識を棚卸しするためにも有用かも知れないと思ったので一言一句漏らさず思うところを書いていこうと思う。 中には枝葉末節な難癖もあるので全部を真に受けない感じで読んで欲しい。 Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。 単一のトランザクション処理を分散して実行しているかというと、Spannerはトランザクションごとに担当のトランザクションマネージャがそのトランザクション処理全体を取り仕切って行う仕組みになっている。なので「トランザクション処理の大規模分散処理
分散プログラミングモデルおよびデザインパターンの考察 その4 - Software Transactional Memo
引き続き分散システムのデザインパターンの話をしていく。例によって適切な名前を見つけられなかった場合にはその場で適当に名づけているので、ここに書いてある名称が技術レベルでの正式名称だとは思わず、正式名称を見つけたらそっとコメント欄で教えてください。 Application Level Ack リクエストを受け取った際にAcknowledgment(Ack) を返却するのは重要であるというのは異論の余地はない。だが、どのレベルで返却すべきかというのはデザインスペースの一部である。 ご存知の通り、TCPはそもそもSYN → SYN-ACK →ACKの3方向ハンドシェイクを行い、それぞれの通信ペイロードにシーケンス番号を付けて送達を確認している。SO_LINGERを使えばclose時に未送信パケットが残っていればそれを送り終わるまでclose()をブロッキングする事もできる。TCPのトランスポート
分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo
昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication の本をベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌
分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは
分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
