秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
Parapet - A purely functional library to build distributed and event-driven systems
A purely functional library to build distributed and event-driven systems It's not a secret that writing distributed systems is a challenging task that can be logically broken into two main aspects: implementing distributed algorithms and running them. Parapet plays the role of execution framework for distributed algorithms - it can be viewed as an intermediate layer between a low-level effect lib
※本文読まなくてもいいので、ぜひ図だけでも見ていってください笑 ※このあたりお詳しい人がいたらコメント、補足など大歓迎 目次 目次 0. はじめに 1. 更新版ビジョン 2. 代表的なクラスタリング 2.1非階層型（K-means法）[1,2] 2.2 階層型（樹形図：デンドログラム）[2,3,4] 2.4 その他 3. 群知能クラスタリング[5] 3.1 Ant Colony Clustering Model (ACCM) 3.1.1 概要 3.1.2 クラスタリング挙動の可視化 3.2 Boids（Bird-oid:仮想的な鳥）、あるいはFlock Algorithm 3.2.1 概要 3.2.2 クラスタリング挙動の可視化 3.2.3 入れ子構造のクラスタリング 3.2.4 補足 4. おわりに 5. 参考 0. はじめに 私のやりたい構想をまとめたブログ（超個体型データセンターにお
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019 アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。 スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。 そのために開発されたのが「Scrum@Scale」フレームワークです。スクラムをスケールさせる仕組みの背後にあるスケールフリーネットワークや、大きな組織でも迅速に情報を共有する手法が組み込まれた「Scrum@Scale」について、2019年2月に行われたイベント「Developers Summit 2019」で株式会社アトラクタの代表取締役 原田騎郎氏が説明しています。 本
Example: Time-based Auto Scaling on Amazon ECS + AWS Fargate
Time-based-auto-scaling-on-fargate.md Set parameters $ export ECS_CLUSTER_NAME={YOUR_ECS_CLUSTER_NAME} $ export ECS_SERVICE_NAME={YOUR_ECS_SERVICE_NAME} RegisterScalableTarget $ aws application-autoscaling register-scalable-target --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id service/${ECS_CLUSTER_NAME}/${ECS_SERVICE_NAME} \ --min-capacity 1 \ --max-capaci
GitHub - bastion-rs/bastion: Highly-available Distributed Fault-tolerant Runtime
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Cloudstate is no longer actively developed Cloudstate was an open source protocol and reference implementation exploring ideas for stateful serverless, and was originally developed by Lightbend. The project is no longer active, since 2021. An open source alternative is Eigr. A continuation of the ideas can be found in Lightbend's platform-as-a-service Akka Serverless.
TECH x GAME COLLEGE #20 (https://techxgamecollege.connpass.com/event/129268/) で, データの整合性を保つという観点から, マイクロサービスや RDBMS との付き合い方などの話しをしました. その際に使用したスライドとなります.
データ指向アプリケーションデザイン
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
[Apache Kafka] Kafka StreamsでStream処理をしてみる [node.js] | DevelopersIO
Apache Kafkaとは Apache Kafkaとは、Linkedinが開発した分散メッセージキューで、 データストリーミング用のプラットフォームです。 メッセージキューとは、システム間でデータのハブととして機能し、 対象データを一時的に保持してくコンポーネントです。 キューをはさむことでシステム間を疎結合にし、通信を非同期化することができます。 AWSでいえば、sqsやkinesisが同様のサービスにあたります。 Apache Kafkaはスケーラビリティや大量データの扱いに長けており、耐障害性もあるスグレモノです。 本稿ではApache Kakfaとnode.js用モジュールのkafka-nodeとkafka-streamsをつかって node.jsからkafkaへアクセスしてみます。 Amazon Kinesisとの比較 以前はAWSフルマネージド(kinesis)かどうか、と
![[Apache Kafka] Kafka StreamsでStream処理をしてみる [node.js] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b07b7c6bbbd77094a43e44f45030ff3684657c12/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F07%2Fapache-kafka.png)
Operating a Large, Distributed System in a Reliable Way: Practices I Learned
For the past few years, I've been building and operating a large distributed system: the payments system at Uber. I've learned a lot about distributed architecture concepts during this time and seen first-hand how high-load and high-availability systems are challenging not just to build, but to operate as well. Building the system itself is a fun job. Planning how the system will handle 10x/100x t
Grokking Modern System Design Interview for Engineers & Managers - AI-Powered Learning for Developers
EXPLORE THE CATALOGSupercharge your career with 700+ hands-on courses
Amazon SQSでFIFOだからってシステム全体が Exactly-Once になると思ったら大間違いだっていう話 - Smoky God Express
TL; DR Amazon SQS で Exactly-Once なキューを使おうとも冪等な処理を書くべき キューが Exactly-Once であるという性質はシステム全体が Exactly-Once になることを保証できない 結局マルチデータソースへの書き込みの問題が残る Designing Data-Intensive Applications (邦訳: データ指向アプリケーションデザイン） が良書でした 邦訳は未読1ですが原著の内容がいいのできっとだいじょうぶでしょう Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 作者: Martin Kleppmann出版社/メーカー: O'Reilly Media発売日: 2017/
README.md この和訳メモは以下のリンク先の記事の和訳です。 https://www.linkedin.com/pulse/microservices-client-side-load-balancing-amit-kumar-sharma/ マイクロサービス: クライアントサイドロードバランシング プロダクションでのフェイルセーフ性を確保するために、同じアプリケーションを複数のインスタンスにデプロイします。 同じアプリケーションをホストする論理的なサーバ（ノード）のグループは Application Clusterを構成します。 伝統的なアプローチ それらのノードの一つに伝達させるための伝統的な方法はロードバランサーを通して行われます。 クライアントはアプリケーションクラスタの前にあるロードバランサを知っています。 リクエストを受け取った際に、ロードバランサはクラスタにあるどのノー
パフォーマンス効率のクイック リンク - Microsoft Azure Well-Architected Framework
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
Gartnerは、ブロックチェーンプロジェクトの一般的な7つの間違いを挙げ、回避手法とともに解説した。例えば分散型台帳技術（DLT）だけにこだわる、本番環境に適用できるかどうかの見極めが甘いといった間違いを指摘した。 Gartnerは2019年6月12日（米国時間）、ブロックチェーンプロジェクトが失敗する根本原因として、一般的な7つの間違いを挙げ、回避する手法とともに解説した。 Gartnerによると、ブロックチェーンには高い関心が寄せられている。だが、同社が3000人以上のCIO（Chief Information Officer：最高情報責任者）を対象に行った調査「2019 CIO Agenda Survey」では、ブロックチェーンを既にデプロイしているか、近いうちにデプロイすると答えたCIOは、11％にすぎない。これは、プロジェクトの大部分が初期の実験段階を超えては進んでいないためで
データ指向アプリケーションデザイン
監訳者まえがき はじめに 第I部データシステムの基礎 1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション 1.1 データシステムに関する考察 1.2 信頼性 1.2.1 ハードウェアの障害 1.2.2 ソフトウェアのエラー 1.2.3 ヒューマンエラー 1.2.4 信頼性の重要度 1.3 スケーラビリティ 1.3.1 負荷の表現 1.3.2 パフォーマンスの表現 1.3.3 負荷への対処のアプローチ 1.4 メンテナンス性 1.4.1 運用性：運用担当者への配慮 1.4.2 単純さ：複雑さの管理 1.4.3 進化性：変更への配慮 まとめ 2章 データモデルとクエリ言語 2.1 リレーショナルモデルとドキュメントモデル 2.1.1 NoSQLの誕生 2.1.2 オブジェクトとリレーショナルのミスマッチ 2.1.3 多対一と多対多の関係 2.1.4 ドキュメントデータベース
Index Compression Using Byte-Aligned ANS Coding and Two-Dimensional Contexts
GitHub - pingcap/talent-plan: open source training courses about distributed database and distributed systems
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Abstract 本セッションでは、形式手法 (formal methods) を用いた分散システムの設計および実装について解説します。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。受講対象は予備知識を持たない初心者を想定しており、具体例を通して形式手法の基本的なアイデアを知ることを目標とします。 分散システムのメリットとデメリット 近年、複数のコンポーネントが非同期的に連携して動作する分散システムは決して珍しいものではなくなりました。正しく設計された分散システムは、集中システムとは比較にならないフレキシビリティとスケーラビリティを発揮します。人気 OSS の中にも分散型の設計を取るものは多数見られ、一昔前のように一部の専門家だけに任せておくだけでなく、すべてのエンジニアにとって一種の基礎教養になってい
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
How my distributed team communicates so no context is left behind
How my distributed team communicates so no context is left behind My team at CircleCI is made up of seven engineers, a product manager, a designer, and an engineering manager, and we are distributed all across the world: in the US from West Coast to East Coast, then to Serbia, Thailand, and finally Japan. Usually, we’re based in places like San Francisco, Chandler, Tempe, Boulder, Knoxville, Novi
OpenTelemetry
OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior. OpenTelemetry is generally available across several languages and is suitable for use.
Raft は Byzantine 障害に対する耐性がなく、論文を一見して恒久的なリーダーの乗っ取りからのログの改ざん、リーダー選挙の妨害などが可能であるところを見ても、P2P ではなく完全に管理されたネットワーク向けの合意アルゴリズム (CFT; Crash Fault-Tolerance) です。Byzantine 障害耐性が必要であれば Raft ではなくパフォーマンスを犠牲にして pBFT などを使う必要があるでしょう。 論文では Crash-Recovery より深刻な障害耐性には言及していないが (論説の範囲を外れるため当然だが)、もし実際に Raft を実装するなら現実的に想定される障害に対して工夫できる余地もいくつか存在します。例えば「テスト環境で使用していたノードの 1 つが事故で本番クラスタに『も』参加してしまった」といったような運用事故で起きうる障害は (大抵そのような
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自律分散協調システム的妄想と群知能クラスタリング - クマガリウムぶろぐ
Distributed State Management for Serverless - Cloudstate
ゲーム開発に携わる Web エンジニアへ贈る, 正しい Web サーバの作り方.
Microservices: Client Side Load Balancing の和訳
ブロックチェーンの「7つの間違い」と回避手法、Gartnerが解説
Understanding distributed processing in Python
形式手法による分散システムの検証 - builderscon tokyo 2019
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
分散合意アルゴリズム Raft を理解する - Qiita