分散トレーシングシステムのZipkinを使ってみた話 - Qiita
Java Advent Calendarの22日目担当のmiya10keiです。 今回は分散トレーシングシステムであるZipkinを勉強しながら使ってみた話になります。 はじめに まずはじめに、分散トレーシングについて完全に素人だったのでこの辺のスライドやブログを見てみました。 https://www.slideshare.net/rakutentech/spring-cloudzipkin http://www.baeldung.com/tracing-services-with-zipkin 分散トレーシングとは そもそも、分散トレーシングとはなにかという話ですが、分散されたシステムで処理されるリクエストを追跡（トレーシング）するためのものになります。マイクロサービスのような複数のサービスで構成されるシステム（分散システム）では、１つのリクエストが複数のサービスをまたいで処理されること
OpenZipkin · A distributed tracing system
Zipkin Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data. If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be sum
GitHub - Netflix/Hystrix: Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure
Hystrix is no longer in active development, and is currently in maintenance mode. Hystrix (at version 1.5.18) is stable enough to meet the needs of Netflix for our existing applications. Meanwhile, our focus has shifted towards more adaptive implementations that react to an application’s real time performance rather than pre-configured settings (for example, through adaptive concurrency limits). F
JanusGraph
Distributed, open source, massively scalable graph database JanusGraph is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster. JanusGraph is a project under The Linux Foundation, and includes participants from Expero, Google, GRAKN.AI, Hortonworks, IBM and Amazon.
CockroachDB 2.0 has arrived!
CockroachDB debuted as the open source database that made it possible to build massive, reliable cloud applications without giving up SQL. Forward-thinking companies adopted it to hide the complexity of dealing with distributed scale, resilience, and consistency problems in the database layer. The promise was simple: keep your apps simple and your pagers silent. Over the last six months, we’ve wel
今度こそ絶対あなたに理解させるPaxos - Qiita
Paxosとは何か 分散システムの金字塔とも呼ばれ、Leslie Lamport大先生の輝かしい成果の一つとして知られる分散合意アルゴリズムPaxos。 既存の解説 実はすでに存在するPaxosの解説は充分に質が高い Wikipediaの項目にも結構長々と書かれていて、これを読んで理解できた人はもう僕の記事を読む必要はない。 同様にPFIの久保田さんによる解説スライドもあり、これも良く書けているし、これを読んで理解できた人もこれ以上記事を読む必要はない。 minghai氏によるブログ記事のこれとか特にこっちなんかはかなり納得感があり、これらを読んで理解できた人も（中略） tyonekura氏によるスライドも良くかけていて(中略) この記事はこれらの説明に目を通してもなお理解できなかった人、もしくはこれらの説明をこれから読もうと思っている人に向けて書き、Paxosアルゴリズムの詳細な説明自体
データーベースをCPだのAPだのと分類するのはやめて下さい - suzuki79のブログ
Please stop calling databases CP or AP (2015-4-11) by Martin Kleppmann 元の記事は上のリンクよりご覧になれます。こちらの記事は 本人の許可を得て、翻訳・掲載したものです。翻訳へのフィードバックはコメントよりお願いいたします。 Jeff HodgesのNotes on Distributed Systems for Young Bloodsという優れたブログで、CAP定理を使ってシステムを評価することが推奨されています。多くの人はこのアドバイスを真摯に聞き、自分たちのシステムをCP（ネットワークの分割のもとでは一貫性はあるが可用性がない）、AP（ネットワーク分割のもとでは可用性があるが一貫性がない）、あるいはまれにCA（これの意味するところは「自分はまだ５年前のCodaの投稿を読んでいません」です）と表現するようになりまし
Understanding Paxos
Introduction Paxos is one of the oldest, simplest, and most versatile algorithms in the field of distributed consensus. It has long been considered the gold-standard in this domain and dozens of papers and articles have been written to describe its various applications, optimizations, and usage techniques. However, despite the volume of literature that has been generated on this subject in the las
ストリーム処理を支えるキューイングシステムの選び方
This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their core components. It then provides a table comparing 8 popular open source messaging platforms: Apache Kafka, ActiveMQ, RabbitMQ, NATS, NSQ, Redis, ZeroMQ, and Nanomsg. The document discusses using Apache Kafka for streaming and integration with Google Pub/Sub, Dataflow, and BigQuery
Apache SystemML
SystemML is now SystemDS To reflect the change of focus to the end-to-end data science lifecycle What is SystemDS? SystemDS is an open source ML system for the end-to-end data science lifecycle from data integration, cleaning, and feature engineering, over efficient, local and distributed ML model training, to deployment and serving. To this end, it provides a stack of declarative languages with R
分散システム処理モデルに関する動向について（MapReduceからBorgまで）
詳細については後述しますが、MapReduceの処理モデルは、上記の通り各区分ごとにそれぞれ単純化（限定）されたモデルであったと言えます。 また、MapReduceの関数プログラミングおよびグラフ的な特徴も合わせて以下に整理してみます。 関数プログラミング的な特徴 MapおよびReduceフェーズは、それぞれ関数型プログラミングのMapおよびReduce処理をモデル化したものです。MapReduceは、参照透過性がある純粋な関数処理と言えます。参照透過性とは入力により出力が一意に決まる性質のことです。言い換えればMapReduceの処理は、大域などの処理に影響する外部の環境は持たず、内部的にも静的な一時変数などの状態も持たないことを意味します。 純粋な関数処理は複数の処理が同時に実行されても他の並列に動作している処理の状態には左右されないため、この参照透過性は並列化に向いている性質がありま
Introducing Dockercast – the Docker Podcast | Docker Blog
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build CloudSpeed up your image buildsTestcontainers Desktop Local testing with real dependenciesTestcontainers Cloud Test without limits in the cloud See our product roadmapMORE resources for developers
NSQ Docs 1.3.0 - A realtime distributed messaging platform
Distributed NSQ promotes distributed and decentralized topologies without single points of failure, enabling fault tolerance and high availability coupled with a reliable message delivery guarantee. See features & guarantees. Scalable NSQ scales horizontally, without any centralized brokers. Built-in discovery simplifies the addition of nodes to the cluster. Supports both pub-sub and load-balanced
Resilient Distributed Datasetsに関する論文まとめ（１章〜５章 - 夢とガラクタの集積場
こんにちは。 Resilient Distributed Datasetsに関する論文 「Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing」 （http://www.cs.berkeley.edu/~matei/papers/2012/nsdi_spark.pdf） について、概念と動作概要が書かれた１章〜５章を読んだので、１投稿にまとめます。 基本的には以前見たスライドの詳細化版なんですが、一部スライド見ているだけだとわからない情報もあり、参考になりました。 Sparkが対象とするような「基本的には全データに対して同じ演算を行う」アプリケーションにおいては 読み取り専用というRDDの性質がマイナスにならないこと、読み取り専用であることで 一貫性考慮が簡略
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
管理が困難―分散処理の常識はZooKeeperで変わる
管理が困難―分散処理の常識はZooKeeperで変わる：ビッグデータ処理の常識をJavaで身につける（8）（1/3 ページ） Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 分散処理の課題が「管理」なのは常識 複数の計算機上で動作（分散）するアプリケーション、ソフトウェアが多く存在します。分散ソフトウェアは複数の計算機で動作することで大量のデータを扱えたり、高負荷な状況に対処します。本稿では、複数の計算機（クラスタ）で動作する各サーバを「インスタンス」と呼びます。 本連載で紹介した分散Key-Valueデータベースである「HBase」は複数の計算機で動作する代表的なソフトウェアです。両ソフトウェアはともに「Apache ZooKeeper」（以下、Z
Introduction to Ceph (Japanese) 0908 2011
20. [ ] tatsuya@ceph2c:~$ fio fio-scenarios/seqwrite-ceph-001w-test.fio seq-write: (g=0): rw=write, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1 Starting 1 process seq-write: Laying out IO file(s) (1 file(s) / 1024MB) Jobs: 1 (f=1): [W] [100.0% done] [0K/37768K /s] [0/9220 iops] [eta 00m:00s] seq-write: (groupid=0, jobs=1): err= 0: pid=5370 write: io=1024MB, bw=37681KB/s, iops=9420, runt= 27828msec cl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散システムについて語らせてくれ
GitHub - twitter/finagle: A fault tolerant, protocol-agnostic RPC system
ZooKeeper - the unsung hero