サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
kumagi.hatenablog.com
8/10のNTT Tech Conference #2 にて発表の時間をもらってこのタイトルで喋ってきた ntt-developers.github.io 発表が決まるまで これはNTTグループ内のソフトウェア・ネットワーク系技術者が集まるコミュニティで、誰が発表者になれるかは投稿されたProposalに対するコミュニティ内での投票によって選考される。 何を話したいか自分の中でも固まりきっていなかった上に、主催者の話をロクに聞いていなかった自分は小さい部屋で僕のことを知る人しか集まらない不人気セッションを勝手に想像しており、abstractを書く欄に「実世界で使われている分散システムを構成する際に理解してほしい議論についてkumagiが一人で滔々と語る。」という漠然とした説明を書いた。初心者にこそ聴いて欲しいという身勝手な理由でレベル設定をBeginnerにし、自己紹介欄に至っては本当は経
こんな記事が目に入った。 www.itmedia.co.jp 大雑把に完全に間違ったことを言っているわけでもないが、読んでいくといろいろ鼻につくところがあり、どのあたりから間違っているのかと自分に問いただすのは現時点での自分の知識を棚卸しするためにも有用かも知れないと思ったので一言一句漏らさず思うところを書いていこうと思う。 中には枝葉末節な難癖もあるので全部を真に受けない感じで読んで欲しい。 Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。 単一のトランザクション処理を分散して実行しているかというと、Spannerはトランザクションごとに担当のトランザクションマネージャがそのトランザクション処理全体を取り仕切って行う仕組みになっている。なので「トランザクション処理の大規模分散処理
TL; DR; 「神輿は軽くてバカがいい」というのは文字面以上に誠実な上司と社員の信頼関係 大きい企業ではとにかく会議が多い。僕の務めている部署では意図して会議を減らしているのでかなりマシな部類ではあるものの、その減っている会議の中でもときおり大きい組織らしい側面がひょっこり顔を出す。 それは、僕が普段から「ファントム」と呼んでいる現象である。僕の脳内ではFate/Grand Orderに出てくるファントム・オブ・ジ・オペラのイメージでだいたい合っている(画像はゲームから引用)。 会社は組織として動いているので、例えば「部」のレベルでの意思決定が必要な問題に対し、ヒラ社員が勝手に意思決定をすることは当然できない。 そこで部のレベルの承認を得るための道筋を、一個下の課のレベルで検討をするためヒラ社員と課長で会議する。その中での意思決定は「その場に居ない」部長の意思をみんなで想像しながら行う。
以下ポエム。 TL;DR; 悪者が居ない組織でも無能で勤勉な会議体は未知の力学で動き続けるのだ。 一般に、大企業に就職するのは簡単ではない。 知名度がある分、エントリーしてくる人間の数も多く自然と競争が熾烈になる。 その熾烈な競争を勝ち残った分、そりゃ優秀な人間が多いというのは採用を担当した人事の弁である。 実際に仕事で役立つ力と、採用の現場で重視されるコミュ力では尺度に乖離があったりで必ずしも現実はうまく回らない。 世の中のIT系の巨大プロジェクトは往々にしてデスマーチに見舞われる。 デスマーチに巻き込まれた末端の人間は目の前の個別の問題に対して「おいこりゃやべーよなんとかしないと」とか思いつつも末端故に全体を止めるような力を持ち合わせてない。 であれば、デスマーチの頂点付近にいる重役ぐらいにしかそれを止める強権を発動し得ないのではないかというのは妥当な考えである。だが世の中はうまく行か
引き続き分散システムのデザインパターンの話をしていく。例によって適切な名前を見つけられなかった場合にはその場で適当に名づけているので、ここに書いてある名称が技術レベルでの正式名称だとは思わず、正式名称を見つけたらそっとコメント欄で教えてください。 Application Level Ack リクエストを受け取った際にAcknowledgment(Ack) を返却するのは重要であるというのは異論の余地はない。だが、どのレベルで返却すべきかというのはデザインスペースの一部である。 ご存知の通り、TCPはそもそもSYN → SYN-ACK →ACKの3方向ハンドシェイクを行い、それぞれの通信ペイロードにシーケンス番号を付けて送達を確認している。SO_LINGERを使えばclose時に未送信パケットが残っていればそれを送り終わるまでclose()をブロッキングする事もできる。TCPのトランスポート
これまでプログラミングモデルのプの字もなかったので申し訳程度にプログラミングモデルの話をする。 分散して特定のアプリを動かしたいだけなら、例えばbitcoinをマイニングするASICクラスタに対して特定のプログラミングモデルは必要とされない。そのように、行いたいタスク抜きにプログラミングモデルを語る事はできない。 HPC(ハイパフォーマンスコンピューティング)系のワークロードは古くからMPIがデファクトとなっている。 MPIでのプログラミング MPIというのは「Message Passing Interface」の略でSmalltalkなどの文脈で語るいわゆるメッセージパッシングとは哲学というかレイヤーが違う。こいつは 配列を引数に取る関数の形で1:1, 1:N, N:Nの通信の典型的なパターン(1:Nなら例えば `MPI_Broadcast` とか)をインタフェースとして定義しており、ユ
昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication の本をベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか?」「データフローは
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の3つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
http://www.amazon.co.jp/dp/1608452352 を読んで自分の気になった所を読みながらメモした物を置いておく。抄訳ほどすら訳していない。 発表のプロットに使うまとめ。論文の参照番号がそのまま埋め込まれてるのは酷いのでそのうち直すかも。気になる人は本を買ってください。 あまりに乱雑に書いてある&&Markdown記法なので読むに耐えないかも…。 ## 並行制御 ロックのタイミング。 衝突頻度が高いほどPessimisiticの方が性能が出るが、衝突頻度が低い場合はOptimisticのほうが速い事が多い。 ### Pessimistic アクセス時にロックする。デッドロックに気をつける必要がある。 ### Optimistic それ以外。デザインの幅が広い。ライブロックの危険がある。 readにOptimistic、writeにPessimiesicを使う亜種もあ
この記事は安ワインを煽りながら勢いで書いたので一切の正しさを保証しません。 分散システムで良く出る課題として障害耐性がある。 性能を増やしたい→台数を増やせばいい→一台でも壊れたら全体が死ぬので脆弱になった→一台死んだぐらいで全体が死なないような仕組みにしろ→複数台でデータを複製するしかない という変遷は自然で、ここから一歩踏み出そうとして大量の屍が量産されたのがここ50年ぐらいの歴史。逆に言うとここまでは50年以上前には到達していて、その50年で何も成果が無かったわけじゃない。 中でも大きな成果だと思っているのがLinealizablityの定義。これは分散システムに対して結局のところ人類が何を望んでいるのかを明文化した点で大きな貢献があった。 僕の覚えている定義はこう。 クライアントが要求した順番とシステム内で実行される順番は等しい。 しかもクライアントが要求を発行した全順序と系を跨い
STMの話題では無いのだけれど自分がKVS上でのSTMというものをPythonで作りながら感じた事 pip install python-memcacheで入る、純Python実装のmemcacheクライアントライブラリ memcachedクライアントライブラリは他にも幾つか有ったのだけれどことごとく要件を満たさなかった - cmemcached : libmemcachedをcythonで包んだラッパ。失敗したら論理エラーだろうが物理エラーだろうが全部数字の0を返すというダメっぷりに辟易。ついでにcythonなので今のPyPyでは動かない - pylibmc : libmemcachedを純Cで包んだラッパ。論理的な失敗(add, replace, casのセマンティクス上の失敗)ならきちんとboolで返って来るし、通信ミスなどの物理エラーはきちんと例外飛ばしてくれる。マルチスレッドの時
HTMの第一人者にして、obstruction-freeやwait-freeなどの厳密な定義や、CAS命令の数学的な意義を証明し、The Art of Multiprocessor Programmingの著者で、ロックフリーでもSTMでも八面六臂の活躍をしているMaurice Herlihy先生が連名している最近の論文を流し読み。 Aleksandar Dragojevic, Maurice Herlihy, Yossi Lev, Mark Moir: On the power of hardware transactional memory to simplify memory management. PODC 2011: 99-108 「トランザクショナルメモリのパワーでメモリ管理を簡略化する」という感じ。 GCを使わない環境下においてメモリ管理は鬼門になってて、そのせいでC++のロ
この記事は pyspa advent calendar 2023の11日目の記事です。 godboltをご存知だろうか。 godbolt.org ブラウザから誰でもアクセスできる無料サービスでコンパイラの挙動について学ぶ事ができる。 例えば簡単に「渡された数Nに対し1+2+....+Nを返す関数sum」を例にすると こんな感じにコンパイル結果のアセンブリを表示してくれる。 アセンブリはマウスカーソルを置くとそれが元のコードのどの場所に対応したものなのかを逐一ハイライト表示してくれる。この機能を実現するために必要な労力は並では無いと思うが詳細はわからない。アセンブリ側も複数色あるのは元のコードの1行が同じ背景色のブロックになった事を表している。 これがすごいのはコンパイラの選択肢の豊富さである。gccはもちろんのことclang, zig c++, msvc, nvc++(なにそれ?), el
このページを最初にブックマークしてみませんか?
『Software Transactional Memo』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く