理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kubernetes ・「2020年のNewSQL」 https://qiita.com/tzkoba/items/5316c6eac66510233115 ・「NewSQLのコンポーネント詳解」 https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f ・Saga https://www.infoq.com/jp/news/2018/03/data-consistency-microservices/ ・「マイクロサービスとは分散システムである」 https://
さぁ！コンテナを設計しよう /「分散システムデザインパターン」を読んだ - kakakakakku blog
4月に出版された「分散システムデザインパターン」を読んだ．サブタイトルに「コンテナを使ったスケーラブルなサービスの設計」とある通り，コンテナを設計／運用するときに，どのようなデザインパターンを知っておくと良いのか？という点を学べる内容になっている．関連情報と合わせて書評を書きたいと思う．なお，今回は貴重な機会を頂き，本書の出版レビューに参加することができた．オライリー本に自分の名前が載っている！という喜びもある． 分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計 作者: Brendan Burns,松浦隼人出版社/メーカー: オライリージャパン発売日: 2019/04/20メディア: 単行本（ソフトカバー）この商品を含むブログを見る 目次 1章 : はじめに 第 I 部 : シングルノードパターン 2章 : サイドカー 3章 : アンバサダ 4章 : アダプタ
［速報］「The Amazon Builders' Library」発表。大規模分散システムの構築、運用などについて、Amazonが学んできたことをコンテンツとして公開。AWS re:Invent 2019
［速報］「The Amazon Builders' Library」発表。大規模分散システムの構築、運用などについて、Amazonが学んできたことをコンテンツとして公開。AWS re:Invent 2019 Amazon.comが開発してきた世界最大級の電子商取引システムや、それを支えるインフラであるところのAmazon Web Servicesは、世界でも最も複雑で巨大な分散システムの1つです。 そしてAmazon.comやAWSにとってさえ「分散システムの構築は難しいものだった」と、Amazon.com CTO Werner Vogels氏。 そしたなかで、Amazonはどのように堅牢でスケーラブルな分散システムを作ったのか？ エンジニア組織をスケールさせてきたのか？ どのように運用しているのか？ どうやってサービスを迅速に提供しているのか？ AWSのブログに投稿された記事「Check
分散システムの課題
Amazon が 2 台目のサーバーを追加した時から、分散システムは Amazon で馴染み深いものになりました。私が 1999 年に Amazon に入社したとき、サーバーの数が非常に少なかったため、「fishy」や「online-01」などのわかりやすい名前を付けることができました。けれども、1999 年であっても、分散コンピューティングは容易ではありませんでした。また現時点で、分散システムの課題には、レイテンシー、スケーリング、ネットワーキング API の理解、データのマーシャリングとアンマーシャリング、および Paxos などのアルゴリズムの複雑さが含まれます。システムが急速に大きくなり、分散するにつれて、理論的なエッジケースであったものが定期的に発生しました。 信頼できる長距離電話ネットワークやアマゾン ウェブ サービス (AWS) のサービスといった分散ユーティリティコンピュー
ゆううきが開発しているlstfやtranstracerなどのツールを最近のObservabilityの流れから紹介した話です。 Kyoto.なんか #5, https://kyoto-nanka.connpass.com/event/141982/, 2019年8月24日.
形式手法による分散システムの検証 #builderscon / builderscon tokyo 2019
builderscon tokyo 2019 で使用したスライドです。 本セッションでは、形式手法 (formal methods) を用いた分散アルゴリズムの検証について解説しました。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。 なお解説として取り上げたのは、AWS による事例論文でも有名なモデル検査器 TLA+ です。講演前半で形式手法の一般論に触れたのち、後半では分散トランザクションを実現するための TCC (Try-Confirm/Cancel) Pattern のモデリングと検証を行いました。 講演概要：https://builderscon.io/tokyo/2019/session/fa356ee3-6be9-4850-ac9e-037bd34aabaa 録画：https://www.y
2019年7月6日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「Kubernetesで始める新しい開発」に登壇したのは、株式会社サイバーエージェント・青山真也氏。登壇資料はこちら Kubernetes で始める新しい開発 青山真也 氏：本日は「Kubernetes で始める新しい開発」というテーマでお話しさせていただきたいと思います。 簡単に自己紹介なんですけど、私サイバーエージェントの青山と申します。普段はインフラエンジニアで主業務は主にGKEみたいなKubernetesサーバサービスのプラットフォームやKuberne
分散システムにおけるSagaパターンのAWS Step Functions による実装 �#AWSDevDay
AWS Dev Day Online - Session B4 分散システムにおけるSagaパターンのAWS Step Functions による実装 �#AWSDevDay / Implementing SAGA pattern on distributed system with AWS Step Functions.
はじめに July Tech Festa 2020において、「マイクロサービスの今だからこそ！理解して拡げる 分散システムの基礎知識」のタイトルで登壇をしてきました。スライドはこちらにありますが、資料内や当日のトークで話せていない部分を含めて、こちらでblogとして解説をしておきたいと思います。 1. セッションの導入 - 新たなムチャブリ - 今回は昨年の#JTF2019で私が話した、「Cloud Native開発者のためのDatabase with Kubernetes」からの続編という形にしてみました。 昨年は、 「せっかくKubernetesを使うのにアプリケーションだけじゃもったいない。 DB、そしてステートフルなワークロードにも適用していきましょう」 という話をしましたが、Kubernetes-native Testbedなど、そうした取り組みが増えつつある傾向にはとても興味を
![[#JTF2020 解説版]理解して拡げる 分散システムの基礎知識 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/540dafbb2d21efa93f97eb638299552222ffcfa6/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJTIzSlRGMjAyMCUyMCVFOCVBNyVBMyVFOCVBQSVBQyVFNyU4OSU4OCU1RCVFNyU5MCU4NiVFOCVBNyVBMyVFMyU4MSU5NyVFMyU4MSVBNiVFNiU4QiVBMSVFMyU4MSU5MiVFMyU4MiU4QiUyMCVFNSU4OCU4NiVFNiU5NSVBMyVFMyU4MiVCNyVFMyU4MiVCOSVFMyU4MyU4NiVFMyU4MyVBMCVFMyU4MSVBRSVFNSU5RiVCQSVFNyVBNCU4RSVFNyU5RiVBNSVFOCVBRCU5OCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9YzUyZmQxMmVmNzQ0Njk3MmZkNTE4MTFjNjU5NjFjNWM%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0emtvYmEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTUwYjMwODQ5NTExOTRhNGNmZTJlYjc4ZmFkZDY4MTkw%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D6745e3ed7f05f6f48209356eaa985cd6)
分散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. 分散
分散システム内のプロセス間の関係性に着目したObservabilityツールの設計と実装 / Transtracer CNDK2019
分散システム内のプロセス間の関係性に着目したObservabilityツールの設計と実装 / Transtracer CNDK2019
今から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の分散システム開発のノウハウが凝縮された「Amazon Builder’s Library」の中身を見てみた #reinvent | DevelopersIO
本日、Wernerのキーノートにて、開発者向けドキュメントラブラリーであるところの「Amzon Builder's Library」のリリースが発表されました。 Welcome to the Amazon Builders’ Library 弊社西澤の速報記事もでております。Amazon Builder's Libraryの概要はこちらを参照ください。 [速報] The Amazon Builders’ Libraryが発表されました #reinvent ｜ Developers.IO 現在、13個のライブラリが登録されていますが、この中から自分が気になったライブラリーを何個か紹介しようと思います。想像していた以上に内容が濃い！ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 ﾒｯﾁｬｺｲﾃﾞ ﾜｯｼｮｲ |_|＿| し'´Ｊ Challenges with distri
分散システムについて語らせてくれ | ドクセル
目次 分散システムを作る際に気をつけて欲しい事 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
Abstract 本セッションでは、形式手法 (formal methods) を用いた分散システムの設計および実装について解説します。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。受講対象は予備知識を持たない初心者を想定しており、具体例を通して形式手法の基本的なアイデアを知ることを目標とします。 分散システムのメリットとデメリット 近年、複数のコンポーネントが非同期的に連携して動作する分散システムは決して珍しいものではなくなりました。正しく設計された分散システムは、集中システムとは比較にならないフレキシビリティとスケーラビリティを発揮します。人気 OSS の中にも分散型の設計を取るものは多数見られ、一昔前のように一部の専門家だけに任せておくだけでなく、すべてのエンジニアにとって一種の基礎教養になってい
目次 目次 はじめに 分散システム視点での自動テストシステム 分散システム構成 入力 出力 テスト対象システム コンポーネント ノード 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プリンシパルエンジニアの技術記事をソリューションアーキテクトが解説～」。ここで、ソリューションアーキテクトの松田氏が登壇。まずは分散システムについて話します。 松田氏の自己紹介 松田丈氏：あらためまして、みなさんこんばんは。アマゾンウェブサービスジャパン ソリューションアーキテクトの松田丈です。よろしくお願いします。 私からは「分散システムの課題とリーダー選挙」というテーマでお話しします。本日4つ目の発表で、そろそろお疲れの方も多いかもしれませんが、チャットなどで盛り上げていただけるとうれしいです。ぜひリラックスして聞いてください。 はじめに自己紹
分散システムでのフォールバックの回避
重大な障害が発生したサービスからは、有用な結果を得ることができなくなります。たとえば、e コマースウェブサイトでは、製品情報のデータベースクエリが失敗すると、ウェブサイトは製品ページを正常に表示できません。Amazon のサービスは、信頼性を高めるために、重大な障害の大部分を処理する必要があります。重大な障害を処理するための戦略には、大きく次の 4 つのカテゴリーに分かれます。 • 再試行: すぐに、または少し遅れて、失敗したアクティビティを再度実行します。 • 積極的な再試行: アクティビティを並行して複数回実行し、最初のアクティビティを使用して終了します。 • フェイルオーバー: エンドポイントの別のコピーに対してアクティビティを再度実行するか、できればアクティビティの複数の並行コピーを実行して、それらの少なくとも 1 つが成功する確率を上げます。 • フォールバック: 異なるメカニズ
分散システムのパターン
原文(投稿日：2019/06/29)へのリンク Mathias Verraes氏が一連のブログ記事を投稿して、自身が仕事で出会った、有用な分散システムのパターンについて説明している。目的は、パターンをその有用なコンテキストとともに識別し、命名し、文書化することだ。その中で氏は、誤った状況で使用することが、パターンをアンチパターンにする場合の多いことを強調している。 DDD Europeの創業者兼コンサルタントであるVerraes氏は、現時点で16のパターンを、デカップリング、汎用メッセージング、イベントソーシングという３分野に定義した上で、各パターンについての問題と解決策を、時には例や実装を含めて説明する。 "Completeness Guarantee"は、プロデューサから送信されるドメインイベントセットの定義を目標とする部分と、プロデューサの状態をコンシューマが再現可能であることを必要
技術記事『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の最新情報を紹介する内容となった。
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 の分散ファイル システムなど、分散システムの設計、検証、評価を行うための反復プロセスについて記述しています。最初から
MITの分散システムの講義 6.824: Distributed Systems が面白かった件 - Qiita
これは何？ 分散システム初学者が、MITの院生向け講義 6.824: Distributed Systems を一通りやってみたので、その内容をまとめる。 分散システムなる分野に入門したいと思った際の一つの選択肢として個人的にオススメできるコンテンツだったので、この場で広く推すために書いている。 Lab3で扱うRaftのアーキテクチャ図より引用1 きっかけ 元々のモチベーションとしては、お仕事周りでAurora2やDynamo3、EBS4といった文献に目を通す中で、そもそも根底にある分散システムという分野を全然知らない。俺たちは雰囲気でクラウドをやっている(画像略)5…という気分になったのがきっかけだった。 ちょうど年末の空き時間に分散システムのオススメコンテンツを探している中で、推されていたこのコンテンツに出会ったのが12月末。その後は仕事の後など空き時間にちまちまやって、結局Lab3ま
Transtracer: 分散システムにおけるTCP/UDP通信の終端点の監視によるプロセス間依存関係の自動追跡
博士課程での研究まとめ 2023年1月版 / Summary of my research in the PhD course
Kubernetesでの分散システムの進化
ネットワークの次は、さまざまなAPIやエンドポイント、つまり、リソースバインディング - 他のプロトコルやさまざまなデータ形式と通信できるようにします。おそらく、あるデータ形式から別のデータ形式に変換することも必要でしょう。ここには、ろ光器 (light filtering) なども含めます。つまり、トピックをサブスクライブするときに、特定のイベントにのみ関心があるかもしれません。 最後のカテゴリーは何だと思いますか? それは状態です。私が状態とステートフル抽象化と言うときは、データベースの機能やファイルシステムなど、実際の状態管理については話していません。私は開発者が状態に依存している舞台裏の抽象化についてもっと話しています。おそらく、ワークフロー管理を行う能力が必要です。実行時間の長いプロセスを管理したり、一時的なスケジューリングやcronジョブを実行して、サービスを定期的に実行したい
分散システムにおけるScalableな名前付けアルゴリズム「Chord Protocol」を実装してみた - Qiita
この記事はEnjoy Architectingからの転載です。 概要 分散システムを学術的に学びたくて、 Chord Protocolというアルゴリズムが面白かったので実際に論文を読んで実装してみました。 この記事では、分散システムにおける名前付けの概念と、Chord Protocolの紹介、簡単な検証について言及していこうと思います。 分散システムにおける名前付けとは？ 分散システムの分野には「名前」、「名前付け」、「アドレス」と呼ばれる概念があります。 それぞれどのような意味を持っているのでしょうか？ 名前付けと名前 分散システムはネットワークを通じてそれぞれのサーバ、プロセスが協調して動作しています。 この中で、各サーバ、プロセスはやり取りをする相手の「名前」を知らなければやり取りを行うことができません。 この名前の解決を行うことを「名前付け」と呼んでいます。 そして、あるリソース（
「分散システム」という言葉は大まかにいって複数のコンピュータが一つの系となって協調動作するようなシステムのことを指す。本書のお題はそのときにどういうパターンがあるかを解説するものだ。作者がKubernetesの開発者であることや、副題をみても、複数のコンピュータを使って大規模にスケールするサービスを設計するときに必要なテクニックを解説するものだ。 分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計 作者: Brendan Burns,松浦隼人出版社/メーカー: オライリージャパン発売日: 2019/04/20メディア: 単行本（ソフトカバー）この商品を含むブログを見る しかしながら、分散システムという言葉は狭義には「いつでも故障しうる」複数のコンピュータがひとつの系となって協調動作するシステムという強い条件がつく。その上で協調動作のなかでも最も難易度の高いコンセン
あけましておめでとうございます（いまさらｗ）。もーすけです。 最近は呪術廻戦にハマっています。ぜひまだ見てない方見てみてください！ さて本題ですが、新年はじめの投稿はデータ指向アプリケーションデザインという書籍についてです。 最近読んだ中で一番良かった本ではないかと思っています。 実は、勤めている会社内でこの書籍の輪読会を行っていて、自分が12章（最終章）を担当しました。 12章はこの本の一番言いたいことが書いてある章でもあったので、本の魅力を理解してもらうのにもしかして役立つのでは！？と思い、この書籍の紹介しつつ、輪読会で発表した内容を動画で解説していきたいと思います。 どんな本なのか？ もしかしたら本のタイトルから「データエンジニアとかデータサイエンスの人とかよむ本かな？」と思ってしまうかもしれません（自分は最初ちょっとそうおもってましたｗ）。しかし、この本は 「信頼性があり、スケーラ
コンテナを使ったシステムのアーキテクチャパターンが掲載されている、分散システムデザインパターンという良書に出会ったので、Kubernetesの勉強を兼ねて各デザインパターンを実装してみましたので、ご紹介です。 この本は執筆者の論文が元になっており、そちらの翻訳記事もあるので、一読することをおすすめします。 Qiita | コンテナ・デザイン・パターンの論文要約 本記事で扱うデザインパターンとその例 分散システムデザインパターン中では、大別して2種のデザインパターンが紹介されています。 1台のノード上で複数のコンテナが動作するシングルノードパターン 複数のノード上で実現されるマルチノードパターン 本記事では、シングルノードパターンから以下のデザインパターンとその例を、Kubernetesでの実装例とともに解説します。 サイドカーパターン ex1. git-sync ex2. topz アンバ
分散システムにおけるScalableな名前付けアルゴリズム「Chord Protocol」を実装してみた - Enjoy Architecting
概要 分散システムを学術的に学びたくて、 Chord Protocolというアルゴリズムが面白かったので実際に論文を読んで実装してみました。 この記事では、分散システムにおける名前付けの概念と、Chord Protocolの紹介、簡単な検証について言及していこうと思います。 実際に作ったサーバ 分散システムにおける名前付けとは？ 分散システムの分野には「名前」、「名前付け」、「アドレス」と呼ばれる概念があります。 それぞれどのような意味を持っているのでしょうか？ 名前付けと名前 分散システムはネットワークを通じてそれぞれのサーバ、プロセスが協調して動作しています。 この中で、各サーバ、プロセスはやり取りをする相手の「名前」を知らなければやり取りを行うことができません。 この名前の解決を行うことを「名前付け」と呼んでいます。 そして、あるリソース（特定のプロセス、サーバなど）を一意に特定する
本当は恐ろしい分散システムの話 | ドクセル
スライド概要 分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html https://www.slideshare.net/kumagi/ss-81368169 と同一です。
運用の可視性を高めるために分散システムを装備する
大学卒業後に Amazon に入社したとき、最初のオンボーディングの練習の 1 つは、amazon.com ウェブサーバーを開発者のデスクトップで起動して実行することでした。最初の試行はうまくいきませんでした。何を間違えたのかすらわかりませんでした。親切な同僚が私に、ログを見て何が間違っているのかを確認するように提案しました。彼は、そのために「ログファイルを猫にする」べきだと言いました。 私は、彼らが何らかのいたずらをしているか、私には理解できない猫に関する冗談を言っているのだと確信しました。私は大学で Linux のみで、コンパイル、ソース管理、およびテキストエディタを使用しました。そのため、「cat」が実際に端末にファイルを出力するコマンドであり、別のプログラムにフィードしてパターンを探せるものだとは知りませんでした。 同僚に、cat、grep、sed、awk などのツールを教えてもら
"分散システムの８つの嘘”を振り返る
原文(投稿日：2021/09/03)へのリンク Ably Blogの先日の記事では、Alex Diaconu氏が、公開から13年を経た"eight fallacies of distributed computing (分散コンピューティングの8つの嘘)"を振り返るとともに、それらに対処するためのいくつかのヒントを紹介している。そのDiaconu氏に、Ablyのエンジニアたちがそれらの誤謬にどう対処しているのか、詳しく聞くことができた。 "eight fallacies"は、ソフトウェア開発を失敗に導く可能性のある、分散コンピューティングに関わる一連の誤謬(誤った考え方)だ。具体的には、"ネットワークは信頼できる"、"遅延はゼロである"、"帯域は無限である"、"ネットワークは安全である"、"トポロジは変化しない"、"管理者はひとりである"、"転送コストはゼロである"、"ネットワークは均一で
[レポート]Everything fails, all the time:分散システムにおける耐障害性のある設計について #AP-19 #AWSSummit | DevelopersIO
[レポート]Everything fails, all the time:分散システムにおける耐障害性のある設計について #AP-19 #AWSSummit AWS Summit tokyo 2023の「Everything fails, all the time:分散システムにおける耐障害性のある設計について」のセッションレポートです。 セッション概要 【スピーカー】 アマゾン ウェブ サービス ジャパン合同会社 グローバル・オートモーティブ事業部 シニアソリューションアーキテクト 小林 芙美 システムは必ず壊れます。マイクロサービスのような分散システムや、AWS のマネージドサービスを活用したクラウドネイティブなシステムは、上手く設計することで高い耐障害性を実現できます。一方でコンポーネント間の連携が複雑化することで障害の原因特定が困難になったり、挙動を完全に予測することが困難になりま
![[レポート]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)
Akkaクラスターでアクターを用いた大規模分散システムを構築する
リチャード 伊真岡です。この連載では非同期処理に役立つアクターモデルを学ぶため、JavaとScalaから使えるOSSであり、アクターモデルの実装を提供するAkkaを紹介します。前回の記事ではアクターと永続化層を接続する有効な設計パターンである、イベント・ソーシングとCQRSを紹介しました。今回は複数台のノードで構成したクラスター上でAkkaアクターを動かす、Akkaクラスターを解説します。 伝統的3層アーキテクチャでのスケールアウト 現代のシステムでは、ノード1台（本稿では、Akkaクラスターが立脚している分散システムの用語に合わせ、1台のコンピュータやサーバーを指します）で構成するシステムは稀で、負荷分散や耐障害性のため複数のノードで構成することが一般的です。 例えばアクターを用いない伝統的な3層アーキテクチャで、かつアプリケーション層に内部状態が存在しない設計の場合は、ノードの数を増や
CDSLでは，これまで仮想マシンで踏み台サーバを運用していました．踏み台サーバの役割はアクセス境界での認証のみです．今回，この踏み台サーバをコンテナ化しました． 研究室内に構築したKubernetes上に以下の構成ファイルでデプロイしました． cdsl-research/container-jumpsv: 踏み台サーバー（コンテナ） 以下の図は，アーキテクチャの全体像です．ESXi上のVMで構成されたKubernetesクラスタ上では，sshdが動作する踏み台コンテナが動作しています．踏み台コンテナは外部からのアクセスをNodePortにより実現しています．コンテナのログはrsyslogによりログサーバ（Fluentd）へ転送されます．踏み台の認証にはSTNSにより構築したID管理サーバにより実現しています． 外部からのアクセスは，RouterからポートフォワードでKubernetesクラ
LINEで働くエンジニアが、各職種別に日々の業務内容や開発体制、働く環境、今後の展望などについて話す「LINE 新卒採用 技術職 コース別説明会」。ここでデータプラットフォーム室の奥田氏が登壇。Data Platform室について話します。 奥田氏の自己紹介 奥田輔氏（以下、奥田）：じゃあ始めます。よろしくお願いします。LINEのData Engineeringセンター Data Platform室の奥田と申します。 私からは、Data Platform室が何やってるかとか、先ほど紹介もありましたが、LINEはデータプラットフォームを持ってます。（なので）それに関しての技術的だったり、ビジネス、会社的な位置付けも含めて紹介できればと思います。よろしくお願いします。 まず自己紹介です。奥田と申します。実は私も新卒（入社）で。ただかなり昔ですね。2013年の新卒入社になります。最初はインフラデ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散システム内の関係性に着目したObservabilityツール - Speaker Deck
「分散システムフレームワーク」としてのKubernetes
Amazon.co.jp: データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理: Martin Kleppmann (著), 玉川竜司 (翻訳), 斉藤太郎 (監修): 本
[#JTF2020 解説版]理解して拡げる 分散システムの基礎知識 - Qiita
Dockerを使ってElixirの分散システムを気軽に楽しむ - Qiita
分散システムはなぜ非中心の夢を見るか、Web 3.0ブームをまじめに考察する
形式手法による分散システムの検証 - builderscon tokyo 2019
Flakyテストから学ぶテスト自動実行分散システム設計入門 - Tabelog Tech Blog
分散システムは“故障する可能性があるもの”である 具体例から考える、データの一貫性を担保する難しさ
リーダーノードを使えばデータの整合性担保は容易になる 分散システムの耐障害性向上におけるAmazonの工夫
Microsoftがリードするモダンな分散システム用ランタイムDaprとは？
分散システムにおける適度な結合とは - Viadik Khononov氏のDDD Europeでの講演より
NALSD フラッシュカードを使用した 分散システムの設計 | Google Cloud 公式ブログ
分散システムデザインパターン寸評 - kuenishi's blog
分散システム構築の良書「データ指向アプリケーションデザイン」を動画で解説する · Goldstine研究所
Kubernetesで学ぶ分散システムデザインパターン - Qiita
さよなら踏み台VM，こんにちは踏み台コンテナ！ | クラウド・分散システム研究室
分散システムの管理やWeb UI・Web APIの開発も実施する 各ポジションが絡みながらデータ活用の環境を作る、データプラットフォーム室