20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…
理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…
分散システムにおける一貫した時刻の取り扱いの課題と解決策 - Spanner TiDB CockroachDBに学ぶ - hacomono TECH BLOG
この記事は hacomono advent calendar 2024 の18日目の記事です 今年9月にhacomonoにJOINし、基盤本部というところで今後のhacomonoのアーキテクチャ設計をしている @bootjp と申します。分散システムが好きです。 hacomonoも昨今のWebサービスの例にもれず、分散システム化しています。 そしてより高い可用性と低い運用コストを目指して新たなアーキテクチャの検討をしています。 今回はその取り組みのなかで、分散システムに関わる難しさというテーマで一貫した時刻の取り扱いの話で記事を書きます。 はじめに 昨今のWebをはじめとしたサービスは一つのサーバーで完結することが少なくなりました。 一つのアプリケーションを複数のサーバーやコンテナで、そして異なるサービスのシステムを組み合わせて「分散システム」として構築されています。 それは可用性や負荷分
分散システムにおけるSagaパターンのAWS Step Functions による実装 �#AWSDevDay
AWS Dev Day Online - Session B4 分散システムにおけるSagaパターンのAWS Step Functions による実装 �#AWSDevDay / Implementing SAGA pattern on distributed system with AWS Ste…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに July Tech Festa 2020において、「マイクロサービスの今だからこそ！理解して拡げる 分散システムの基礎知識」のタイトルで登壇をしてきました。スライドはこちらにありますが、資料内や当日のトークで話せていない部分を含めて、こちらでblogとして解説をしておきたいと思います。 1. セッションの導入 - 新たなムチャブリ - 今回は昨年の#JTF2019で私が話した、「Cloud Native開発者のためのDatabase with Kubernetes」からの続編という形にしてみました。 昨年は、 「せっかくKub
![[#JTF2020 解説版]理解して拡げる 分散システムの基礎知識 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3da478df3d67fb4d461e81339a4232199e0e89c4/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNTQ4NTMlMkZwcm9maWxlLWltYWdlcyUyRjE1ODI4Nzk0OTg_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9N2RiZTVhYjZkMzc3ZTg2YWVjMTdjNjI0N2I1NDA1OGI%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D9c5b29ed57351b2e950bcfb4cfe585f3%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCJTIzSlRGMjAyMCUyMCVFOCVBNyVBMyVFOCVBQSVBQyVFNyU4OSU4OCU1RCVFNyU5MCU4NiVFOCVBNyVBMyVFMyU4MSU5NyVFMyU4MSVBNiVFNiU4QiVBMSVFMyU4MSU5MiVFMyU4MiU4QiUyMCVFNSU4OCU4NiVFNiU5NSVBMyVFMyU4MiVCNyVFMyU4MiVCOSVFMyU4MyU4NiVFMyU4MyVBMCVFMyU4MSVBRSVFNSU5RiVCQSVFNyVBNCU4RSVFNyU5RiVBNSVFOCVBRCU5OCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPWIyZTNkMDM2OGE1YjI0OTkyOGVkNzQ5MzY2YTdiMTM1%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDB0emtvYmEmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz02MTU1ZDAzNzgyYTk0ZTQzMTU4YmRkYjE3YjMyMjU4OA%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D5399a5bf7881c1edfb16418c88780cac)
分散Erlangシステムを楽しむには複数のPCがあるといいのですが、それだと準備が大変で敷居を高く感じるかもしれません。 Dockerを使えば一つのPC上に複数の仮想ホストを簡単に立ち上げられます。それらを別々のPCに見立てれば、気軽に遊べるのではないでしょうか。 やりたいこと Dockerで仮想Linuxマシンを三つ起動してそれらを別々のPCと見立てる それぞれの仮想Linuxマシンでノードを起動する すべてのノードを接続 後は自由に遊ぶ ノードとは 分散Erlangのドキュメントによると A distributed Erlang system consists of a number of Erlang runtime systems communicating with each other. Each such runtime system is called a node. 分散
分散システムについて語らせてくれ | ドクセル
目次 分散システムを作る際に気をつけて欲しい事 1.分散自体を目的にしない事 2.論文を読んでそのまま実装しない事 3.Two Phase Commitを使わない事 4.手を動かす事 Copyright©2016 NTT Corp. All Rights Reserved. 2 分散自体を目的にしない事 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ？ Copyright©2016 NTT Corp. All Rights Reserve
今から10年ほど前の2013年、筆者は六本木のダイニングバー「The Pink Cow」に入り浸っていた。多国籍の料理や酒を楽しむため……ではなく、そこに集う暗号資産（仮想通貨）Bitcoin（ビットコイン）ファンに話を聞くためだ。 銀行を介さず自らデジタル通貨を管理し、店で決済できるBitcoinの可能性に、誰もが興奮していた。ブロックチェーンを使えば、銀行や国家から独立したDecentralized（非中心、非中央集権）なマネーを運営できる。そんな魅力に引かれていた。 そして2022年。DeFi（分散型金融）やNFT（非代替性トークン）、DAO（分散型自律組織）などに代表される「Web 3.0（Web3）」のブームにおいても、やはり人々を引き付けたのは非中心という考え方だった。「Web 1.0やWeb 2.0は中央集権的だが、Web 3.0は非中心になる」といわれるようになった。 とは
技術記事『Amazon Builders' Library』にフォーカスを当てた勉強会「AWS Tech talkNight#5 クラウドネイティブ時代のエンジニアが押さえておきたい ソフトウェアの構築・運用で考慮すべき5つのポイント ～AWSプリンシパルエンジニアの技術記事をソリューションアーキテクトが解説～」。ここで、ソリューションアーキテクトの松田氏が登壇。まずは分散システムについて話します。 松田氏の自己紹介松田丈氏：あらためまして、みなさんこんばんは。アマゾンウェブサービスジャパン ソリューションアーキテクトの松田丈です。よろしくお願いします。 私からは「分散システムの課題とリーダー選挙」というテーマでお話しします。本日4つ目の発表で、そろそろお疲れの方も多いかもしれませんが、チャットなどで盛り上げていただけるとうれしいです。ぜひリラックスして聞いてください。 はじめに自己紹介を
目次 目次 はじめに 分散システム視点での自動テストシステム 分散システム構成 入力 出力 テスト対象システム コンポーネント ノード Testcase Allocator Cucumber Selenium Browser 事例：食べログで起きた分散システム視点でのFlakyテスト 問題 Flakyテストの事象: "たまに" "不特定" "多数のテストケースが" "Cucumberのstepの60秒タイムアウトエラーで失敗する" Flakyテストの原因調査の複雑さ 原因と対策 「事象A: たまに（4回に1回程度の頻度で）」の原因と対策 「事象B: 不特定 (毎回異なるテストケース)」の原因と対策 「事象C: 多数のテストケースが(テストケース全体の20~70%程度)」の原因と対策 「事象D: Cucumberのstepの60秒タイムアウトエラーで失敗する」の原因と対策 結果 巻き込まれて
技術記事『Amazon Builders' Library』にフォーカスを当てた勉強会「AWS Tech talkNight#5 クラウドネイティブ時代のエンジニアが押さえておきたい ソフトウェアの構築・運用で考慮すべき5つのポイント ～AWSプリンシパルエンジニアの技術記事をソリューションアーキテクトが解説～」。ここで、ソリューションアーキテクトの松田氏が登壇。続いて、リーダーノードについて話します。前回はこちらから。 リーダーノードを設ける3つのメリット松田丈氏：次に、この問題を単純にしてくれるリーダーノードという考え方について説明します。リーダーノードとは何でしょうか。（まず）リーダーノードを設けるメリットについて見ていきます。 1つ目のメリットは、データの整合性担保をリーダーノード内で完結させられることです。例えば競合する書き込みがあった際に、その順序性をリーダーノード内で整理する
MicrosoftはCNCF（Cloud Native Computing Foundation）が主催するWebinarで、クラウドネイティブなシステムにおいて分散処理を実装するランタイムであるDaprを解説するセッションを実施した。CNCFのWebinarページには、CNCFにホストされている多数のプロジェクトのセッションだけではなくCNCFのメンバーによる技術解説が公開されている。今回紹介するセッションは2020年10月1日に公開されたもので、CNCFのプラチナムメンバーであるMicrosoftがコンテンツを提供したものになる。 参考：Dapr, Lego for microservices セッションのタイトルは「Dapr, Lego for Microservices」というもので、マイクロサービスを構築する際にランタイムとして機能するDaprの最新情報を紹介する内容となった。
MITの分散システムの講義 6.824: Distributed Systems が面白かった件 - Qiita
これは何？ 分散システム初学者が、MITの院生向け講義 6.824: Distributed Systems を一通りやってみたので、その内容をまとめる。 分散システムなる分野に入門したいと思った際の一つの選択肢として個人的にオススメできるコンテンツだったので、この場で広く推すために書いている。 Lab3で扱うRaftのアーキテクチャ図より引用1 きっかけ 元々のモチベーションとしては、お仕事周りでAurora2やDynamo3、EBS4といった文献に目を通す中で、そもそも根底にある分散システムという分野を全然知らない。俺たちは雰囲気でクラウドをやっている(画像略)5…という気分になったのがきっかけだった。 ちょうど年末の空き時間に分散システムのオススメコンテンツを探している中で、推されていたこのコンテンツに出会ったのが12月末。その後は仕事の後など空き時間にちまちまやって、結局Lab3ま
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
※この投稿は米国時間 2020 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 分散システムには数多くの設計方法が存在しますが、その一つにシステムの自然な拡張を考慮した設計があります。この方法では、システムがより多くのリクエストを処理していくにつれて、コンポーネントの書き換えや再設計を行います。また、概念実証から始める手法もあります。システムによってビジネスに付加価値がもたらされたら、次のバージョンがゼロから設計されます。 Google では、Non-Abstract Large System Design（NALSD）と呼ばれる手法を使用しています。NALSD は、分散コンピューティング向けの Borg クラスタ管理や Google の分散ファイル システムなど、分散システムの設計、検証、評価を行うための反復プロセスについて記述しています。最初から
Kubernetesでの分散システムの進化
ネットワークの次は、さまざまなAPIやエンドポイント、つまり、リソースバインディング - 他のプロトコルやさまざまなデータ形式と通信できるようにします。おそらく、あるデータ形式から別のデータ形式に変換することも必要でしょう。ここには、ろ光器 (light filtering) なども含めます。つまり、トピックをサブスクライブするときに、特定のイベントにのみ関心があるかもしれません。 最後のカテゴリーは何だと思いますか? それは状態です。私が状態とステートフル抽象化と言うときは、データベースの機能やファイルシステムなど、実際の状態管理については話していません。私は開発者が状態に依存している舞台裏の抽象化についてもっと話しています。おそらく、ワークフロー管理を行う能力が必要です。実行時間の長いプロセスを管理したり、一時的なスケジューリングやcronジョブを実行して、サービスを定期的に実行したい
本当は恐ろしい分散システムの話 | ドクセル
スライド概要 分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html https://www.slideshare.net/kumagi/ss-81368169 と同一です。
分散システムにおけるScalableな名前付けアルゴリズム「Chord Protocol」を実装してみた - Qiita
分散システムにおける名前付けとは？ 分散システムの分野には「名前」、「名前付け」、「アドレス」と呼ばれる概念があります。 それぞれどのような意味を持っているのでしょうか？ 名前付けと名前 分散システムはネットワークを通じてそれぞれのサーバ、プロセスが協調して動作しています。 この中で、各サーバ、プロセスはやり取りをする相手の「名前」を知らなければやり取りを行うことができません。 この名前の解決を行うことを「名前付け」と呼んでいます。 そして、あるリソース（特定のプロセス、サーバなど）を一意に特定するための文字列を「名前」呼んでいます。 アドレス 名前が分かっていても実際にはそれだけではやり取りできず、実際には「アドレス」と呼ばれるリソースの住所に対してアクセスすることでやり取りが成立します。 つまり、リソースに対する実質的なアクセスポイントをアドレスと呼んでいます。 名前との違いは、名前は
あけましておめでとうございます（いまさらｗ）。もーすけです。 最近は呪術廻戦にハマっています。ぜひまだ見てない方見てみてください！ さて本題ですが、新年はじめの投稿はデータ指向アプリケーションデザインという書籍についてです。 最近読んだ中で一番良かった本ではないかと思っています。 実は、勤めている会社内でこの書籍の輪読会を行っていて、自分が12章（最終章）を担当しました。 12章はこの本の一番言いたいことが書いてある章でもあったので、本の魅力を理解してもらうのにもしかして役立つのでは！？と思い、この書籍の紹介しつつ、輪読会で発表した内容を動画で解説していきたいと思います。 どんな本なのか？ もしかしたら本のタイトルから「データエンジニアとかデータサイエンスの人とかよむ本かな？」と思ってしまうかもしれません（自分は最初ちょっとそうおもってましたｗ）。しかし、この本は 「信頼性があり、スケーラ
？？？：雰囲気で分散システム使ってるやついる!? ？？？：いねぇよな！！！！！ むっそ：んなわけねぇよ、いるんだよ！！ここによぉ！！ (終) はじめに なんか分散システムっぽいのは使えてるけど、いまいち詳しいことは知らないってひとが多いと思います。私もです。 別に分散システムの仕組みを知らなくても問題なかったりするものですが、いざシステム障害などが起きると これそもそもの仕組み知らんと無力じゃね？ ってなったりします。(無情にもやばいバグが時々起きたりします) 今回は分散システムにわか勢による分散システムを知るのに良さそうなリンクをまとめたり感想を書いていこうかと思います。 分散システムを考え始めたきっかけ DynamoDB嘘松事件 事件前の実装 現在開発しているプロダクトで下記のような処理がありました。 (先人の過去の遺物が残っていてあまり良くないアーキテクチャになってます) フロントエ
[レポート]Everything fails, all the time:分散システムにおける耐障害性のある設計について #AP-19 #AWSSummit | DevelopersIO
AWS Summit tokyo 2023の「Everything fails, all the time:分散システムにおける耐障害性のある設計について」のセッションレポートです。 セッション概要 【スピーカー】 アマゾン ウェブ サービス ジャパン合同会社 グローバル・オートモーティブ事業部 シニアソリューションアーキテクト 小林 芙美 システムは必ず壊れます。マイクロサービスのような分散システムや、AWS のマネージドサービスを活用したクラウドネイティブなシステムは、上手く設計することで高い耐障害性を実現できます。一方でコンポーネント間の連携が複雑化することで障害の原因特定が困難になったり、挙動を完全に予測することが困難になります。このような分散システムにおいて、高い耐障害性を備えたシステムを設計するための方法をお話しします。 セッション視聴 5/22からAWS Summit Tok
![[レポート]Everything fails, all the time:分散システムにおける耐障害性のある設計について #AP-19 #AWSSummit | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/92906dcb785a4c93120a3f47650fb23b9bcad275/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F04%2Fbnr_AWS_smt_tokyo2023_1200x630_SR.png)
新規サービスで分散システムにおける責務分解とパフォーマンスのトレードオフを考えた話 - asoview! Tech Blog
アソビュー！ Advent Calendar 2024の19日目（表面）です。 アソビューにて海外事業を担当している江部です。今年の前半まではCTOで、今年からは心機一転して海外事業責任者を拝命し、これまでの国内向けサービスを拡張して海外向けのサービスを新規事業として立ち上げることにチャレンジしています。 役割は事業責任者ですが、MVP開発フェーズ終盤においてはプロダクトチームと一緒に開発に取り組んでいます。 今日はこの海外事業を立ち上げるにあたって、アーキテクチャ上の責務分解とシステム全体の性能のトレードオフについて悩んだことがあったので、そのお話をネタにしていきたいと思います。 背景 起こった問題 問題の原因 対策の検討 ① キャッシュで対応 長所 短所 ② 共通基盤のAPIをサイトに最適化 長所 短所 今回の私達の選択 最後に 背景 前述の通り、アソビューでは海外のレジャーやアクティ
分散システムにおけるScalableな名前付けアルゴリズム「Chord Protocol」を実装してみた - Enjoy Architecting
概要 分散システムを学術的に学びたくて、 Chord Protocolというアルゴリズムが面白かったので実際に論文を読んで実装してみました。 この記事では、分散システムにおける名前付けの概念と、Chord Protocolの紹介、簡単な検証について言及していこうと思います。 実際に作ったサーバ 分散システムにおける名前付けとは？ 分散システムの分野には「名前」、「名前付け」、「アドレス」と呼ばれる概念があります。 それぞれどのような意味を持っているのでしょうか？ 名前付けと名前 分散システムはネットワークを通じてそれぞれのサーバ、プロセスが協調して動作しています。 この中で、各サーバ、プロセスはやり取りをする相手の「名前」を知らなければやり取りを行うことができません。 この名前の解決を行うことを「名前付け」と呼んでいます。 そして、あるリソース（特定のプロセス、サーバなど）を一意に特定する
"分散システムの８つの嘘”を振り返る
原文(投稿日：2021/09/03)へのリンク Ably Blogの先日の記事では、Alex Diaconu氏が、公開から13年を経た"eight fallacies of distributed computing (分散コンピューティングの8つの嘘)"を振り返るとともに、それらに対処するためのいくつかのヒントを紹介している。そのDiaconu氏に、Ablyのエンジニアたちがそれらの誤謬にどう対処しているのか、詳しく聞くことができた。 "eight fallacies"は、ソフトウェア開発を失敗に導く可能性のある、分散コンピューティングに関わる一連の誤謬(誤った考え方)だ。具体的には、"ネットワークは信頼できる"、"遅延はゼロである"、"帯域は無限である"、"ネットワークは安全である"、"トポロジは変化しない"、"管理者はひとりである"、"転送コストはゼロである"、"ネットワークは均一で
Akkaクラスターでアクターを用いた大規模分散システムを構築する
リチャード 伊真岡です。この連載では非同期処理に役立つアクターモデルを学ぶため、JavaとScalaから使えるOSSであり、アクターモデルの実装を提供するAkkaを紹介します。前回の記事ではアクターと永続化層を接続する有効な設計パターンである、イベント・ソーシングとCQRSを紹介しました。今回は複数台のノードで構成したクラスター上でAkkaアクターを動かす、Akkaクラスターを解説します。 伝統的3層アーキテクチャでのスケールアウト 現代のシステムでは、ノード1台（本稿では、Akkaクラスターが立脚している分散システムの用語に合わせ、1台のコンピュータやサーバーを指します）で構成するシステムは稀で、負荷分散や耐障害性のため複数のノードで構成することが一般的です。 例えばアクターを用いない伝統的な3層アーキテクチャで、かつアプリケーション層に内部状態が存在しない設計の場合は、ノードの数を増や
奥田氏の自己紹介奥田輔氏（以下、奥田）：じゃあ始めます。よろしくお願いします。LINEのData Engineeringセンター Data Platform室の奥田と申します。 私からは、Data Platform室が何やってるかとか、先ほど紹介もありましたが、LINEはデータプラットフォームを持ってます。（なので）それに関しての技術的だったり、ビジネス、会社的な位置付けも含めて紹介できればと思います。よろしくお願いします。 まず自己紹介です。奥田と申します。実は私も新卒（入社）で。ただかなり昔ですね。2013年の新卒入社になります。最初はインフラデータベースエンジニアでLINE GAMEの裏側のデータベースを維持運用してました。そこから社内移動を希望して、今のHadoopやETL、バッチジョブのジョブの開発に移動しました。 また、2018年とか2019年ぐらいからはデータプラットフォーム
CDSLでは，これまで仮想マシンで踏み台サーバを運用していました．踏み台サーバの役割はアクセス境界での認証のみです．今回，この踏み台サーバをコンテナ化しました． 研究室内に構築したKubernetes上に以下の構成ファイルでデプロイしました． cdsl-research/container-jumpsv: 踏み台サーバー（コンテナ） 以下の図は，アーキテクチャの全体像です．ESXi上のVMで構成されたKubernetesクラスタ上では，sshdが動作する踏み台コンテナが動作しています．踏み台コンテナは外部からのアクセスをNodePortにより実現しています．コンテナのログはrsyslogによりログサーバ（Fluentd）へ転送されます．踏み台の認証にはSTNSにより構築したID管理サーバにより実現しています． 外部からのアクセスは，RouterからポートフォワードでKubernetesクラ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[#JTF2020 解説版]理解して拡げる 分散システムの基礎知識 - Qiita
Dockerを使ってElixirの分散システムを気軽に楽しむ - Qiita
分散システムはなぜ非中心の夢を見るか、Web 3.0ブームをまじめに考察する
分散システムは“故障する可能性があるもの”である 具体例から考える、データの一貫性を担保する難しさ | ログミーBusiness
Flakyテストから学ぶテスト自動実行分散システム設計入門 - Tabelog Tech Blog
リーダーノードを使えばデータの整合性担保は容易になる 分散システムの耐障害性向上におけるAmazonの工夫 | ログミーBusiness
Microsoftがリードするモダンな分散システム用ランタイムDaprとは？
分散システムにおける適度な結合とは - Viadik Khononov氏のDDD Europeでの講演より
NALSD フラッシュカードを使用した 分散システムの設計 | Google Cloud 公式ブログ
分散システム構築の良書「データ指向アプリケーションデザイン」を動画で解説する · Goldstine研究所
雰囲気で分散システム使ってるやついる!? - Qiita
分散システムの管理やWeb UI・Web APIの開発も実施する 各ポジションが絡みながらデータ活用の環境を作る、データプラットフォーム室 | ログミーBusiness
さよなら踏み台VM，こんにちは踏み台コンテナ！ | クラウド・分散システム研究室