0 0 5 0 Dropbox の同期エンジンのコードを完全に書き換えるのは、困難な道のりでした（その目標と決断までの詳細については、以前の投稿をご覧ください）。コードの書き換えとは、運用中に膨大な数のユーザーのマシンで稼働している Dropbox を支えるエンジンを入れ替えることです。正しくコードを書き換えるには、テストの自動化に本腰を入れる必要がありました。私たちが策定したテスト戦略のおかげで、コードを書き換えている間、いつでも正しい方向に向かっていると確信が持てました。このおかげで現在も、短いリリース周期で新機能の開発と出荷を続けることができます。 ここでは、最初に新しい同期エンジン「Nucleus」の設計に反映したテスタビリティの検討事項と、テストしやすいアーキテクチャ上に構築したランダム化テスト システムの一部について説明していきます。 目次 テスタビリティ 1-1. プロトコル
※この投稿は米国時間 2020 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 分散システムには数多くの設計方法が存在しますが、その一つにシステムの自然な拡張を考慮した設計があります。この方法では、システムがより多くのリクエストを処理していくにつれて、コンポーネントの書き換えや再設計を行います。また、概念実証から始める手法もあります。システムによってビジネスに付加価値がもたらされたら、次のバージョンがゼロから設計されます。 Google では、Non-Abstract Large System Design（NALSD）と呼ばれる手法を使用しています。NALSD は、分散コンピューティング向けの Borg クラスタ管理や Google の分散ファイル システムなど、分散システムの設計、検証、評価を行うための反復プロセスについて記述しています。最初から
同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
オブザーバビリティ（可観測性）とは何か？を学べる「Distributed Systems Observability」を読んだ - kakakakakku blog
2019年頃から「オブザーバビリティ (Observability)」もしくは「可観測性」という言葉をよく聞くようになった（本記事では「オブザーバビリティ」という表記に統一する）．「マイクロサービス」と同じように「バズワード」の側面があり「オブザーバビリティとは何か？」という質問に対して様々な回答が考えられると思う． 今回は「オブザーバビリティ」の理解を深めるために「Distributed Systems Observability」を読んだ．本書は O'Reilly Media で読むこともできるけど，Humio のサイトから無料でダウンロードすることもできる（メールアドレス登録は必要）．著者は Cindy Sridharan となり，肩書は「Distributed Systems Engineer」と書いてあった． www.humio.com 目次 本書には「オブザーバビリティ」をテー
Rayとは RayはPythonにおける分散並列処理を高速かつシンプルに書けるフレームワークで, 既存のコードを並列化することも容易な設計となっています. Rayを使うことでmultiprocessingなどに比べ簡単にプロセスレベルの並列処理を記述することができます. 本記事はRayチュートリアルの内容をもとにしており, コードはPython 3.8.2, Ray 0.8.4での動作を確認しています. インストール ターミナルでpipなどからインストールできます. 使い方 基本的な用途としては覚える文法はray.init ray.remote ray.get の3つのみで, この記事では加えてray.wait ray.put も紹介します. Rayによる並列化の基本 実行に3秒かかる関数 func が二度呼び出され全体の実行に6秒かかる以下のコードについて, func の実行を並列化する
大規模システムにおける5つのログ転送パターン
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
システムの構成を社内で共有したり外部に説明したりする際に、システム構成図を作成した経験のあるエンジニアは多いはず。ダイアグラム作成ソフト「Diagrams」を使うと、AnsibleやSubiquityといった「Infrastructure as Code(IaC)」に関連するサービスのように、プログラミング言語のPythonでコードを書くことで、クラウドやオンプレミスの構成図を描くことができます。 Diagrams · Diagram as Code https://diagrams.mingrammer.com/ まずはDiagramsの動作に必要なパッケージをインストールします。今回Diagramsのインストールに利用するのはUbuntu 18.04です。 sudo apt install -y python3 python3-pip graphviz 続いてDiagramsをインスト
[レポート] 1000万ユーザーのためのAWSクラウドアーキテクチャの進化#AWSSummitOnlineKorea | DevelopersIO
こんにちは！新卒エンジニアのハウンです? AWS Summit Online Koreaが開催されたことで、韓国語のセッションレポートを投稿しました！日本の方々ともセッションの内容を共有できたらなと思い、日本語のレポートも残しておきます。 今回の記事は模範事例の「1000万ユーザーのためのAWSクラウドアーキテクチャの進化」セッションについてまとめます。 ※ 本記事で使用されているアーキテクチャ図は登壇資料をもとに修正されたものです。 登壇者紹介 Jongmin Moon Solutions Architect AWS Korea AWSグローバルインフラストラクチャーとサービス AWSは全世界22箇所のリージョンを運営 各リージョンごとに2つ以上のアベイラビリティゾーンを持っているので、他のサービスより可用性が高い リージョンと216のPoP(205のエッジローケーション, 11のリージ
![[レポート] 1000万ユーザーのためのAWSクラウドアーキテクチャの進化#AWSSummitOnlineKorea | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e518b1f93dfdc31309838137b90da275a4352e91/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F05%2Faws-summit-online-korea.png)
マルチランタイム・マイクロサービスアーキテクチャ
状態(state)を話題にする場合、その多くはサービスの状態や、ステートレスが望ましい理由といったことが多いのですが、サービスを管理するプラットフォーム自体にも状態は必要です。信頼性の高いサービスオーケストレーションの実行、分散型のシングルトン、時間的スケジューリング(cronジョブ)、冪等性、ステートフルなエラーリカバリ、キャッシュなどを行なうには、状態が必要になります。ここで挙げたすべての機能が、内部的に状態を持つことに依存しているのです。状態管理の実際はこの記事の範囲ではありませんが、状態に依存する分散プリミティブやその抽象化は関心の範囲内にあります。 バインディング 分散システムのコンポーネントは相互の通信が必要なだけではなく、最新の外部システム、あるいはレガシな外部システムとのインテグレーションも必要です。そのためには、さまざまなプロトコルを変換し、ポーリングやイベント駆動、リク
分散アプリケーションの異常の原因を即時に診断するための手法の構想 / Causality Tracing in Distributed Applications
分散アプリケーションの異常の原因を即時に診断するための手法の構想 / Causality Tracing in Distributed Applications
背景 Log Matching Property の証明 データ構造と述語の定義 AppendEntries 関数の性質 leader の log に関する性質 Log Matching Property の証明 参考資料 背景 分散合意アルゴリズム Raft は kubernetes のクラスターの構成情報を保存する etcd の内部で使われておりお世話になっている方も多いアルゴリズムだと思います。 この記事では Raft の満たす重要な性質である Log Matching Property について証明します。 元々、『Raft を TLA+ で検証する』というタイトルの記事を書こうと考えて Raft の考案者 Diego Ongaro の博士論文を読み始めました（その記事は後日公開予定です）。 アルゴリズムは論文の 3 章に書かれているのですが、そこで Raft が常に成り立つことを
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & Apps Online
2020 年 4 月 27 日（月） 第 10 回 Google Cloud INSIDE Games & Apps Online Google Cloud 篠原 一徳によるセッション スライドです。Read less
Distributed Systems 3rd edition (2017) - DISTRIBUTED-SYSTEMS.NET
You can get a digital (personalized) copy of this book for free. PPT slides now available This page refers to the 3rd edition of Distributed Systems For this third edition of “Distributed Systems,” the material has been thoroughly revised and extended, integrating principles and paradigms into nine chapters: Introduction Architectures Processes Communication Naming Coordination Replication Fault t
Microsoftは、「Windows 10」ユーザーが「Folding@home」プロジェクトにコンピューターの余剰演算能力を安全に提供するためのPowerShellスクリプトをリリースした。分散コンピューティング技術を活用して疾病研究を行うプロジェクトである「Folding@home」は現在、新型コロナウイルス感染症（COVID-19）の解析に取り組んでいる。 既に多くのユーザーが、Folding@homeのタンパク質動力学シミュレーションを支援するために、macOSやWindows、Linuxにこのソフトウェアのクライアントをダウンロードしている。 Microsoftの今回の取り組みは、Windows 10のユーザーが、Windowsサンドボックスを利用して安全に演算能力を提供できるようにするものだ。 Folding@homeプロジェクトは、生化学と分子生物学が専門のワシントン大学セ
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました 生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!! https://tech-lab.connpass.com/event/315703/ etcdとは？OSSの分散KVSです。単純なkey-Value形式のデータを保存することができます。アーキテクチャーも単純で、構築もそれほど難しくはありません。詳細は以下のURLを御覧ください。 https://et
12-3章では確率変数の期待値について、12-5章では確率変数の分散について学びました。この章では、2つの確率変数の和、差、共分散、相関係数について学びます。 ■2つの確率変数の期待値 2つの確率変数とYの和、差の期待値は、次に示すように、それぞれの期待値、の和、差に等しくなります。
Folding@home – Fighting disease with a world wide distributed super computer.
START FOLDING NOW Install our software to become a citizen scientist and contribute your compute power to help fight global health threats like COVID19, Alzheimer’s Disease, and cancer. Our software is completely free, easy to install, and safe to use.
NewSQLのコンポーネント詳解 - Qiita
4.2.1 Shardingの手法 先ほどの表1を理解するにはSharding手法の列にあげられた各用語の理解が必要となる。 YugaByteDBのブログ「Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database」には、非常に詳しくShardingの手法が紹介されている。この記事では、大きく以下4つの分類があるという。 Algorithmic Sharding (例: Memcached/Redis) Linear Hash Sharding (例: 過去のCassandra) Consistent Hash Sharding (例: DynamoDB、Cassandra) Range Sharding (例: Spanner、HBase) 詳細は割愛するが、1つ目のアルゴリズム・シャー
配信サーバー「VODST」 - DMM inside
｜DMM inside
OceanVista http://www.vldb.org/pvldb/vol12/p1471-fan.pdf 基本的アーキテクチャは、DC間クラスターをインフラにおいて、高遅延・耐障害性を前提にした分散transactionの仕組みになっている。 どう見てもAlibabaのOceanBaseそのものではない。が、同じAlibabaグループでかつ、Oceanの名前をつけているので、関係はなくはないと思う。少なくとも同じグループまたは情報交換はしているのではないか。技術的な方向性を模索するプロトタイプに見える。 バックグラウンド的な与太話をすると、Alibabaは、というか中国的には、ITでの米国からの依存脱却（ポーズだけなのか、実際なのかは置いておいて）を目標として掲げているのは周知の通り。んで具体的な話としては、Alibaba的には脱Oracleが一つの目標になっている。この目線で見た
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
Implementing Raft: Part 0 - Introduction - Eli Bendersky's website
This is the first post in a multi-part series describing the Raft distributed consensus algorithm and its complete implementation in Go. Here is a complete list: Part 0: Introduction (this post) Part 1: Elections Part 2: Commands and log replication Part 3: Persistence and optimizations Raft is a relatively new algorithm (2014), but it's already being used quite a bit in industry. The best known e
Over the past few weeks, the Bitbucket Engineering team has been sharing our ongoing efforts and wins in our journey to achieving world-class reliability. In our previous post, Development Manager Dan Tao took you through our PIR process. In this next post, we’ll talk about database scalability. Bitbucket’s usage is growing Two services at the core of Bitbucket are the ones serving the Bitbucket w
Percolator vs Spanner. Implementing Distributed Transactions the Google Way
Our post 6 Signs You Might be Misunderstanding ACID Transactions in Distributed Databases describes the key challenges involved in building high performance distributed transactions. Multiple open source ACID-compliant distributed databases have started building such transactions by taking inspiration from research papers published by Google. In this post, we dive deeper into Percolator and Spanne
The etcd key-value store is a distributed database based on the Raft consensus algorithm. In our 2014 analysis, we found that etcd 0.4.1 exhibited stale reads by default. We returned to etcd, now at version 3.4.3, to investigate its safety properties in detail. We found that key-value operations appear to be strict serializable, and that watches deliver every change to a key in order. However, etc
What is Distributed SQL?Distributed SQL is a category of relational databases that combines the core features of traditional SQL and NoSQL systems, being strongly consistent while natively providing ACID transactional support across data centers, availability zones, and regions—in the cloud. It provides a single logical relational database deployed across a cluster of network servers. Distributed
博士課程での研究まとめ 2023年1月版 / Summary of my research in the PhD course
Apache Flink PlaygroundsでApache FlinkとApache Kafkaによるストリーム処理の雰囲気を感じてみた | DevelopersIO
Amazon Kinesis Data Analyticsでは、Apache Flinkをベースとしたストリーム処理が可能です。 Apache Flink PlaygroundsはFlinkの機能を手早く試せる環境をDocker Composeを使って構築できます。 今回はApache Flinkがどういったものなのかを知る為にApache Flink Playgroundsで遊んでみました。 apache/flink-playgrounds: Apache Flink Playgrounds Apache Flink 1.9 Documentation: Flink Operations Playground Apache Flink Apache Flink is an open source platform for distributed stream and batch data
バッチ処理について考える - Qiita
TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万～数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ？ネットに本にも答え載ってないよ？低レイヤも意識しないと動かないよ？ 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本
きっかけは、たつぞうさんからのタレコミでしたW このツリー、また怪傑さんがブログにまとめてくれるはず。|дﾟ)ﾁﾗｯ いつも思うけど、ここまでの議論が、パッと、アドリブで丁々発止でできること自体がスゴいことなのよ。 多分、どこのコンサルでもここまで深い理解は出来てないのでは クリプト界隈の意義のあるプロレスを記事にまとめることに存在意義を見出した私としては早速まとめにとりかかりました！ 今回の対談テーマは「ブロックチェーンにコンソーシアムは是か？否か？」 以下 ２名の対談となります。 ひよこさん と極度信玄（してます）さん "集中化されたブロックチェーンはトランザクションを簡単に検閲でき、通常の分散データベースよりも使用するのがはるかに非効率的であるため、分散化なしではブロックチェーンを使用する意味はあまりありません。" ↑これに対して、ブロックチェイナーの反論を聞きたい。。 基本的には同
Ray is an open-source unified compute framework that makes it easy to scale AI and Python workloads — from reinforcement learning to deep learning to tuning, and model serving.
分散システムでのフォールバックの回避
重大な障害が発生したサービスからは、有用な結果を得ることができなくなります。たとえば、e コマースウェブサイトでは、製品情報のデータベースクエリが失敗すると、ウェブサイトは製品ページを正常に表示できません。Amazon のサービスは、信頼性を高めるために、重大な障害の大部分を処理する必要があります。重大な障害を処理するための戦略には、大きく次の 4 つのカテゴリーに分かれます。 • 再試行: すぐに、または少し遅れて、失敗したアクティビティを再度実行します。 • 積極的な再試行: アクティビティを並行して複数回実行し、最初のアクティビティを使用して終了します。 • フェイルオーバー: エンドポイントの別のコピーに対してアクティビティを再度実行するか、できればアクティビティの複数の並行コピーを実行して、それらの少なくとも 1 つが成功する確率を上げます。 • フォールバック: 異なるメカニズ
昨年のre:Invent 2019で発表されたAmazon Builder's Libraryを一通り読んでみました。通勤電車で読んでいたのですが、途中で冬休みに突入してしまい少し時間がかかってしまいました。途中で日本語にも対応していることに気付いたのですが、折角なので全て英語で読んでみました。 aws.amazon.com Amazonにおける大規模分散システムの開発で得られたノウハウが公開されているのですが、昨今マイクロサービスの普及もあり、Amazonのような規模でなくとも分散システムに関するノウハウが重要になりつつあります。もちろんAWSのインフラや規模感に依存する部分も多々見られるものの、大規模な分散システムを運用した上で得られる知見というのは得難いものですし、一般論として参考になる部分も多く、とても有用なコンテンツだと思います。 全体を通して共通して述べられていたのは以下のよう
今回私は2020年以降のSNSの動向を記そうと思いnoteを書き始めた。 そして今まさにTwitterはSNSの歴史的な岐路へ立っている。それは何故かを先ず語らなくてはこの話は進められないだろう。 つい先日、Twitter創始者のJack DorseyがTwitterのネットワークを分散化方針を発表したのだ。 Twitter is funding a small independent team of up to five open source architects, engineers, and designers to develop an open and decentralized standard for social media. The goal is for Twitter to ultimately be a client of this standard. 🧵 —
Cisco Advent Calendar 2019 第24日目！ 1. はじめに 2019年も早くも年末となりました。Cisco有志で綴るAdvent Calendarも今年は3回目。私はこの、年末恒例行事になったわくわくするAdvent Calendarに、わくわくする(?!)システム理論的なことを書くことにしています。過去二回のエントリーもぜひご覧いただけたら嬉しいです。 2017年 ネットワーク・エンジニアリングから学ぶこと − システム理論の見地から 2018年 システム理論の続き - 生命モデルの限界と克服 2. システム理論って何？ 「わくわくするシステム理論」などと言いながら、そういえば「システム理論とは何か」についてきちんと記述していませんでした。Wikipediaによる「システム理論」解説 によると「現象のマクロな挙動を直接的にモデル化して扱う科学理論のこと」と書かれて
書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について - Qiita
この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad
OpenCensusとhttptrace.ClientTraceを使ってHTTPリクエストのlatencyを可視化する - oinume journal
はじめに みなさんこんにちは。これはGo5 Advent Calendar 2019の19日目の記事です。この記事はOpenCensusとhttptrace.ClientTraceを使ってHTTPリクエストの内部的なlatencyを可視化する話です。「内部的なlatency」というのは、HTTPリクエストの中で名前解決にどのぐらいかかったとか、コネクションを張るのにどのぐらいかかったなどです。 なお、この記事に記載しているコードは全てGitHub repositoryに上げてあります。 やりたいこと とあるアプリケーションでHTTP Clientを使ってHTTPリクエストを大量に送る処理がありました。そのサーバーはUS Regionで動いていて、そこからHTTPリクエストを日本にあるサーバーに送るというもので、この処理のlatencyが非常に気になっていました。そのため、HTTPリクエスト
分散システムの課題
Amazon が 2 台目のサーバーを追加した時から、分散システムは Amazon で馴染み深いものになりました。私が 1999 年に Amazon に入社したとき、サーバーの数が非常に少なかったため、「fishy」や「online-01」などのわかりやすい名前を付けることができました。けれども、1999 年であっても、分散コンピューティングは容易ではありませんでした。また現時点で、分散システムの課題には、レイテンシー、スケーリング、ネットワーキング API の理解、データのマーシャリングとアンマーシャリング、および Paxos などのアルゴリズムの複雑さが含まれます。システムが急速に大きくなり、分散するにつれて、理論的なエッジケースであったものが定期的に発生しました。 信頼できる長距離電話ネットワークやアマゾン ウェブ サービス (AWS) のサービスといった分散ユーティリティコンピュー
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dropbox での同期のテスト 確信を持って同期の中核コードを書き換えるまで
NALSD フラッシュカードを使用した 分散システムの設計 | Google Cloud 公式ブログ
RayによるPython分散並列処理入門 - Qiita
Pythonでコードを書いてAWSやKubernetesのシステム構成図を出力できる「Diagrams」
A Proof for Log Matching Property of Raft - 俺の Colimit を越えてゆけ
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & Apps Online
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
マイクロソフト、「Folding@home」の新型コロナ分析に協力するPowerShellスクリプトを公開
分散KVS「etcd」の環境を世界最速で構築！！ | SIOS Tech. Lab
15-6. 2変数の期待値と分散 | 統計学の時間 | 統計WEB
OceanVista 再読 - 急がば回れ、選ぶなら近道
2020年現在のNewSQLについて - Qiita
Scaling Bitbucket's Database - Bitbucket
Jepsen: etcd 3.4.3
Distributed SQL 101 | Yugabyte
分散アプリケーションの信頼性観測技術に関する研究 / A study of SRE
ブロックチェーンにコンソーシアムは是か？否か？ - 快傑Ｚの仮想通貨を投資以外で消耗してます！
Productionizing and scaling Python ML workloads simply | Ray
Amazon Builder's Libraryを読んでみた - たけぞう瀕死ブログ
SNSが変わろうとしている：Twitterの分散化方針をアナタは知っているか｜Wakageeks
システム理論の続き - 宣言的ネットワーキング - Qiita