分散型アーキテクチャとドメイン駆動設計JJUG ナイトセミナー 2025/1 発表資料」
Designing Tinder - High Scalability -
This is a guest post by Ankit Sirmorya. Ankit is working as a Machine Learning Lead/Sr. Machine Learning Engineer at Amazon and has led several machine-learning initiatives across the Amazon ecosystem. Ankit has been working on applying machine learning to solve ambiguous business problems and improve customer experience. For instance, he created a platform for experimenting with different hypothe
Testing Distributed Systems
Skip to the content. List of resources on testing distributed systems curated by Andrey Satarin. If you are interested in my other stuff, check out public talks. For any questions or suggestions you can reach out to me on Twitter, Bluesky @asatarin.bsky.social or other platforms. Table of Contents Overview of Testing Approaches Research Papers Bugs Testing Fault Tolerance Resilience In Complex Ada
分散アプリケーションの信頼性観測技術に関する研究 / A study of SRE
SRE NEXT 2020 IN TOKYO https://sre-next.dev/
Amazon Builder's Libraryを読んでみた - たけぞう瀕死ブログ
昨年のre:Invent 2019で発表されたAmazon Builder's Libraryを一通り読んでみました。通勤電車で読んでいたのですが、途中で冬休みに突入してしまい少し時間がかかってしまいました。途中で日本語にも対応していることに気付いたのですが、折角なので全て英語で読んでみました。 aws.amazon.com Amazonにおける大規模分散システムの開発で得られたノウハウが公開されているのですが、昨今マイクロサービスの普及もあり、Amazonのような規模でなくとも分散システムに関するノウハウが重要になりつつあります。もちろんAWSのインフラや規模感に依存する部分も多々見られるものの、大規模な分散システムを運用した上で得られる知見というのは得難いものですし、一般論として参考になる部分も多く、とても有用なコンテンツだと思います。 全体を通して共通して述べられていたのは以下のよう
Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog
このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 上記の理由の通り、目的は論文を翻訳することだけではなく、最終的にこれを踏まえて自分の見解をつらつらと書いていくところにもあります。 おそらく一番時間がかかるのはそれなので、一旦は翻訳を一通り終えた上で更に頑張っていきます。ゆっくりお待ちいただければと思います＞＜ 1. Introduction(まえがき) Borgが内部的に呼び出すクラスター管理システムは、Googleが実行するすべてのアプリケーションを許可、スケジュール、起動、再起動、および監視します。この論文ではその方法を説明します。 Borgには3つの主な利点があります。 リソース管理と障害処理の詳細を隠すため、ユーザーは代わりにアプリケーション開発に集中できます。 非常に高い信頼性と可用性で動作し、同じことを行
コンテナを使った分散システムのデザインパターン(Design patterns for container-based distributed systems) - 理系学生日記
Consul の文脈で出てきた Sidecar Proxy なんかは Sidecar Pattern に あてはまります。ぼく自身、このあたりの知識があまりないので、初歩的な知識を得たいと思い、以下の論文を読んでみました。 Design patterns for container-based distributed systems. Google が出したこの論文では、Container が分散システムにおけるデザインパターンにどう位置付けられていっているのかという話と、 これまでに出てきたデザインパターンを以下の 3 つの種類に分けて説明しています。 Single-container management patterns Single-node, multi-container application patterns Multi-node application pattern コ
Pravega – A Reliable Stream Storage System
Storage Reimagined for a Streaming World Pravega is about a new storage abstraction — a stream — for continuously generated and unbounded data. A Pravega stream stores unbounded parallel sequences of bytes in a durable, elastic and consistent manner while providing unbeatable performance and automatically tiering data to scale-out storage. Distributed messaging systems such as Kafka and Pulsar hav
今度こそ絶対あなたに理解させるPaxos - Qiita
Paxosとは何か 分散システムの金字塔とも呼ばれ、Leslie Lamport大先生の輝かしい成果の一つとして知られる分散合意アルゴリズムPaxos。 既存の解説 実はすでに存在するPaxosの解説は充分に質が高い Wikipediaの項目にも結構長々と書かれていて、これを読んで理解できた人はもう僕の記事を読む必要はない。 同様にPFIの久保田さんによる解説スライドもあり、これも良く書けているし、これを読んで理解できた人もこれ以上記事を読む必要はない。 minghai氏によるブログ記事のこれとか特にこっちなんかはかなり納得感があり、これらを読んで理解できた人も（中略） tyonekura氏によるスライドも良くかけていて(中略) この記事はこれらの説明に目を通してもなお理解できなかった人、もしくはこれらの説明をこれから読もうと思っている人に向けて書き、Paxosアルゴリズムの詳細な説明自体
Peter Bourgon · Metrics, tracing, and logging
2017 02 21 Today I had the good fortune of attending the 2017 Distributed Tracing Summit, with lots of rad folks from orgs like AWS/X-Ray, OpenZipkin, OpenTracing, Instana, Datadog, Librato, and many others I regret that I’m forgetting. At one point the discussion took a turn toward project scope and definitions. Should a tracing system also manage logging? What indeed is logging, when viewed thro
Paxos-based replicationはEventually consistentではなくstrongly consistentである - kuenishi's blog
ちょっと発言力のありそうな方がテクニカルに誤りを書かれていたので、ここでひっそりと訂正しておきたい。 このスライドの43ページ目に、 The problem with Paxos-based algorithm is that replications are eventual consistent. と、色付き文字で協調されて書かれている。このスライドで主張したいことの本筋ではないが、Spannerの性能がよいこととは関係がなく、Paxosなどのレプリケーションと、トランザクションとの関係で誤解を広めそうなので指摘しておきたい。辻マサカリと言って差し支えないだろう。 PaxosはStrongly consistentであることがMade Simpleの論文で証明されている（Strongly consistentが何かはまた別の機会にここに書こうと思う）。ちょっと長いが引用しておこう。 T
クラウドシステム基礎
enPiT（東大・東工大）クラウドシステム基礎 副題：分散システム基礎とクラウドでの活用 資料（2015年度版） 1コマ目前半：イントロ 1コマ目後半：相互接続の仕組み （ 付録 ） 2コマ目：基本的な考え方 （ 付録１ ・ 付録２ ） 3コマ目：定足数によるアプローチ 4コマ目：順序づけ 5コマ目：クラウドサービスの設計思想（１） 6コマ目：クラウドサービスの設計思想（２） 7コマ目：議論・まとめ 演習解答例（講義後にアップロード） レポート課題 講師 石川 冬樹（国立情報学研究所） f-ishikawa@nii.ac.jp 評価 出席ならびにレポート（ 10/6（火）〆切 ）-->により評価する．レポート詳細は資料参照．）
CRDT (Conflict-free Replicated Data Type)を15分で説明してみる - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 下記はスライドの講演の書き下しのようになっているので、スライドだけ見るんじゃなくて、スライドを見ながら文章を読み進めたい方向けです。 CRDTとは 今回は、CRDTというデータ構造について紹介します。CRDTはそもそも2011年にSSS(Stabilization, Safety, and Security of Distributed Systems)という国際会議で、INRIA(フランス国立情報学自動制御研究所)のMarc Shapiro博士によって発表された、比較的新しいモノです。 CRDTは"Conflict-free Repl
Distributed Computing: Principles, Algorithms, and Systems (4章) - mrasu’s blog
「Distributed Computing: Principles, Algorithms, and Systems」の4章 メモリダンプのように、分散システム全体に対する「現在状態」を取得する方法について 全コンピュータ同時に取ることはできないので、分散が牙を剥く Distributed Computing: Principles, Algorithms, and Systems 作者: Ajay D. Kshemkalyani,Mukesh Singhal出版社/メーカー: Cambridge University Press発売日: 2011/03/03メディア: ペーパーバックこの商品を含むブログを見る Chapter4 Global state and snapshot recording algorithms 4.1 Introduction グローバルな状態を取得できると、
分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは
最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった - Qiita
この表でみるとB-Gridが良さそうに見えますが、B-Gridはサイズが限られてしまう、解析においてはノードの稼働率が$1/3$以下という仮定が置かれている、等にも注意が必要です。 実践的な応用については、このリストの中だけでみるとMajorityが広く使われている理由もわかるように感じます(loadはそこそこ大きくても、resilienceが大事、またmajorityはread/writeでquorumシステムをうまく重み付けすることでread/write時のloadを調整できたりもするので)。 その他のQuorum達 今回挙げたquorum systemは基本的なものばかりです。これら以外にも様々な仕組みのquorum system達が数多く提案されています。 また、今回のquorum systemのモデルは停止故障しか考慮していませんが、分散システムを考える上で一番やっかいとされるビ
分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Amazon Builders' Library
The Amazon Builders' Library
分散システムについて語らせてくれ
