事前知識編 システム開発するプログラマも読んでおいたほうがいい資料とか。 今時のシステムならまず仕様や運用に反映される。されてなかったらむしろこっちから確認取りに行った方がいい。 JOGAガイドライン 昔ガチャとかが問題になったときに出てきた協会のガイドライン。 オンラインゲーム安心安全宣言 オンラインゲームにおけるビジネスモデルの企画設計および運用ガイドライン ランダム型アイテム提供方式を利用したアイテム販売における表示および運営ガイドライン オンラインゲームガイドライン 開発環境編 GitHubみたいなPullRequestを出せる環境 GitだけじゃなくてGitHub。必然的に規模が大きくなるのでプルリク出して進めることになります。 CIまで設定をする 最初のうちにCircleCIのようなテストの自動実行する仕組みまで揃えてしまっておいたほうが良いです。後からだとそもそも対応できなく
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する https://zenn.dev/mpyw/articles/rdb-transaction-isolations 上記のスライドの具体的な結論に至るまでの導入として，知識があまりない状態でも段階的に読み込んでいけるように心がけたスライドで，株式会社ゆめみの社内勉強会にて発表しました。 スライドの途中の URL などは PDF としてダウンロードするとクリックできると思います。 事前のレビュー協力者 - https://twitter.com/neko_han25 - https://twitter.com/KentarouTakeda
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場 Amazon Web Servicesは、Amazon RDSのトランザクションの処理速度を最大で2倍にし、3台のクラスタ構成で可用性を高め、リードのスケーラビリティも向上する、新たな「Multi-AZ Deployment Option」（マルチAZ配置オプション）を発表しました。 New AWS News post by @sebsto: New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failoverhttps://t.co/sffr5boYlU — AWS Blogs (@AW
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つ目のアルゴリズム・シャー
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/
データベースのデータ・モデルは解決したい問題に合わせて使い分けることができ、昨今ではドキュメントやグラフなどのリレーショナル以外のモデルも注目されています。また、トランザクション系が生成した大量のデータをリアルタイムで分析するというような、性質の異なるワークロードを扱うことも求められています。これら性質の異なるデータ・モデルやワークロードを扱うにはどのような実装が必要でしょうか。この連載では、開発者の皆様がシステム・アーキテクチャやアプリケーション・コードをより洗練させるのに役立つデータベース・マネジメント・システム（DBMS）の基本を振り返り、実装に合った技術の組み合わせを解説します。 第1回はデータベースにアクセスするAPIで最も広く使われているSQLという言語の実行モデルを再確認します。なぜこの言語がリレーショナル・モデルのみならず他のデータ・モデルに対しての操作にも使われるようにな
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
実際はどう？ 共通で言えること MySQL/Postgres とも，ファジーリードとファントムリードはセットで起こったり起こらなかったりするようになっているため， SQL 標準のように更新なのか新規・削除なのかを意識する機会は少ないです。 一貫性読み取りで参照するデータは，更新時に参照するデータ本体とは隔離された スナップショット になります。 文の種類 アクション 参照先 ロック
![[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際](https://cdn-ak-scissors.b.st-hatena.com/image/square/be4a7bfbb640d53daec1dd96b5f2f8f4b120ea01/height=288;version=1;width=512/https%3A%2F%2Fstorage.googleapis.com%2Fzenn-user-upload%2Favatar%2F94ec78e846.jpeg){kind=avatar}
どうも、かとじゅんです。 松岡さん(id:little_hands)が以下の記事を更新されたそうです。松岡さん自身が悩まれた中で検討したオプションであって、唯一の正解ではないと踏まえたうえで、率直な感想を述べたいと思います。結論からいうと、論旨は前回の記事と変わりませんが、コード例で具体的な考え方を示している点を工夫しています。 little-hands.hatenablog.com 前回の考察記事も古くなったので、最新の記事に併せて考察をまとめ直したいと思います。 blog.j5ik2o.me ドメインモデル ドメインモデル図が追加されていますね。以下の３つの集約があるそうです。「一つの集約にまとめればいいよね」という提案はなしという前提で考えます。 ユーザー タスク アクティビティ・レポート 「アクティビティ・レポート」は「タスク」もしくは「ユーザー」に関連を持つようです。 「これらの
形式手法による分散システムの検証 #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
2021/7/16にCloud Native Database Meetup#1の発表資料です。
ここがすごいぞyugabyteDB！～OSS版CloudSpanner～ - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。インフラエンジニアの gumamon です！ 近年、Kubernetes等の登場により、アプリケーションのスケールアウトはとても簡単になりました。対して、データベース(DB)のスケールアウトは依然として困難です。 「RDBMS」⇒ データの一貫性は保てるが、スケールアウトが難しい 「NoSQL」⇒ データの一貫性を保てないが、スケールアウトが容易 DBのスケールアウトを考えるとこの２択に行きつく、というのが今までの常識だったかと思いますが、 『どっちも！』が出来てしまう第３の選択肢が登場しました。 データの一貫性を保て、且つスケールアウト容易な『NewSQL』！ 最近、NewSQLの一つである yugabyteDB の検証をする機会がありましたので、アーキテクチャと検証結果を紹介します。 目次 目次 ここがすごいぞ yugabyteDB！ yugabyteDBのアーキテクチャ
この記事は、Merpay Tech Openness Month 2023 の7日目の記事です。 はじめに こんにちは。メルコイン Payment Platform チームの @sapuri です。 メルコインではマイクロサービスアーキテクチャを採用しており、お客さまによりアプリの操作が行われると、それぞれのマイクロサービスを横断してリクエストが処理されます。 メルコインの Payment Platform は、お客さまの残高の管理や各種帳簿の作成などの決済事業のための基盤となる仕組みを提供しています。 そのなかで、Payment Service は決済トランザクションを管理するサービスとして、下位層のサービスが提供する各種決済手段を利用して、上位層のサービスが共通して利用できる決済 API を提供しています。 この記事ではマイクロサービスアーキテクチャにおける分散トランザクション管理の課
こんにちは、shallow1729:detailです。今回は先日MyNA会というイベントで発表したMySQLの標準のストレージエンジンであるInnoDBのMVCCのガベージコレクションについて書こうと思います。発表自体もアーカイブされているので以下から見る事ができます。 「日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会-」 公開版 - YouTube まず前半ではMVCCに関連するデータ構造を見ながらガベージコレクションの重要性やlong-running transactionの問題点について解説します。後半では実際のガベージコレクション(purge)の処理をソースコードレベルで追いながら、ユーザーに提供されているパラメーターを解説をします。 これまでに比べると踏み込んだ話題なのであまり基礎的な事は解説しません。知らない単語が多いかもしれないですが、適宜調べな
PostgreSQL Isolation について
トランザクションのACID特性のうち、Isolation(隔離性)について整理する。 検証環境検証には、PostgreSQL 10.5を独自ビルドしたものを利用する。 (gdbでデバッグできるように最適化オプションを無効にした) 参考 PostgreSQL 9.4.4をソースコードからインストールする # select version(); version --------------------------------------------------------------------------------------------------------- PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit (1 row) #
「PIXIV DEV MEETUP 2021」は、完全招待制のオンラインカンファレンスです。ライブセッションをはじめ、さまざまなイベントを通して、ピクシブのメンバーとピクシブのプロダクト開発における知見、組織文化を共有します。金川氏は、「BOOTH」で発生する決済スパイクに対する取り組みについて発表しました。 突然の決済スパイクに悩まされていた「BOOTH」 金川祐太郎氏（以下、金川）：「オンライン即売会を支えた技術」。BOOTH部の金川がお話します。よろしくお願いします。 「BOOTH」では、突然の決済スパイクに頭を抱えていました。決済スパイクは、例えば有名なクリエイターの期間限定販売や、「YouTube」などVTuberの配信中に商品が公開された時、あとは最近行われるエアコミケといったオンライン即売会などで発生します。 決済スパイクが起きる時、BOOTHでは同じ商品に注文が集中します。
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
Cloud SpannerとCloud Pub/Subとで実装するTransactional outboxパターン | メルカリエンジニアリング
Credit Designチームでバックエンドエンジニアをしている@iwataです。主にメルペイスマート払い関連の開発をしています。 Merpay Advent Calendar 2021 の21日目の記事をお届けします。 メルペイスマート払いの開発においてもご多分に漏れず、マイクロサービスアーキテクチャを採用しています。マイクロサービス開発において避けては通れない問題として、分散トランザクションによるデータ整合性の担保があります。メルペイスマート払いマイクロサービスでは一部APIにおいて整合性担保のために、Transactional outboxパターンを用いた実装をしています。 本記事ではテーブル設計を含めたその実装の詳細を紹介したいと思います。 tl;dr Transactional outboxパターンを使ったSpanner, Pub/Sub間での整合性担保 Spannerならでは
分散システムにおける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.
「マイクロサービスとメッセージングのなぜ [概要編]」はこちらです。 レッドハットでインテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 概要編ではメッセージングの良い面ばかりに焦点を当ててきましたが、今回の疑問編ではメッセージングを検討し始めたときに疑問に思ったり困りがちなことを説明したいと思います。概要編とは異なり、細かな技術的内容も含まれますので、その時々で必要な部分や興味ある部分だけ読んでいただければと思います。 (ところで、当初は前回を前編、そして今回を後編にして終わらせようと思っていたのですが、今回もあまりに長くなってしまったので、構成を変えたのでした。 このため当初の前編は概要編と名前を変更しています。) ではまず主に疑問とされることを確認して、その後に対処法を見ていきましょう。 メッセージングを利用することによる主な疑問 対処方法 Q1:
![マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f80853750b1c5f85bbe4ae4c26691362ff89c530/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20191208%2F20191208182318.jpg)
SQL Serverのスナップショット分離レベル導入によるデータ基盤連携の課題解決 - ZOZO TECH BLOG
こんにちは。アーキテクト部の廣瀬です。 弊社ではサービスの一部にSQL Serverを使用しており、BigQuery上のデータ基盤へテーブルを連携しています。連携の仕組みは非常によくできているものの、データ不整合や遅延が発生し得るという課題を抱えていました。しかし、SQL Serverのスナップショット分離レベルを導入することでそれらを解決できました。本記事では、抱えていた課題および解決までの流れと、スナップショット分離レベルを導入する際に気を付ける点を紹介します。 データ基盤連携の方法と課題 データ基盤との連携方法は、日次連携とリアルタイム連携の2種類です。それぞれの連携方法と抱えていた課題について説明します。 日次連携 1日1回、SQL Server専用の一括コピーツールである「bcp」を使用してテーブル全体のデータを取得する連携方法です。データ取得時のSQLのイメージは以下の通りです
Raft は Byzantine 障害に対する耐性がなく、論文を一見して恒久的なリーダーの乗っ取りからのログの改ざん、リーダー選挙の妨害などが可能であるところを見ても、P2P ではなく完全に管理されたネットワーク向けの合意アルゴリズム (CFT; Crash Fault-Tolerance) です。Byzantine 障害耐性が必要であれば Raft ではなくパフォーマンスを犠牲にして pBFT などを使う必要があるでしょう。 論文では Crash-Recovery より深刻な障害耐性には言及していないが (論説の範囲を外れるため当然だが)、もし実際に Raft を実装するなら現実的に想定される障害に対して工夫できる余地もいくつか存在します。例えば「テスト環境で使用していたノードの 1 つが事故で本番クラスタに『も』参加してしまった」といったような運用事故で起きうる障害は (大抵そのような
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説 こんにちは技術研究グループ・テクニカルディレクターの波多野です！ 普段は社内のインフラ、特にデータベース関連の技術的な問題を解決するのを仕事にしています。 弊社ではリレーショナル・データベースとしてはオープンソースの MySQL をとてもよく使っていますが、そんなオープンソースのデータベース界隈で最近よく目にするようになって来たのが 楽観的トランザクション(Optimistic Transaction) という技術です。今回はトランザクション処理の歴史的なところに触れながら、RocksDB に代表される楽観的トランザクションについて簡単に解説したいと思います はじめに MySQL を使っているとデフォルトでは REPEATABLE READ のトランザクション分離レベルになっていて、トランザク
米Google（グーグル）は2022年5月に開催した年次カンファレンス「Google I/O 2022」で、新しいデータベース（DB）サービスである「AlloyDB for PostgreSQL」を発表した。 グーグルが2022年5月12日（米国時間）に発表したAlloyDB for PostgreSQLは、同社が独自に開発したDBのサービスで、オープンソースソフトウエア（OSS）のリレーショナルDB（RDB）である「PostgreSQL」と互換性がある。ユーザーはPostgreSQL用のSQLクエリーや拡張機能がそのまま利用できる。 AlloyDB for PostgreSQLの特徴は、トランザクション処理（OLTP）性能とデータ分析（OLAP）性能を両立した点だ。グーグルによればAlloyDB for PostgreSQLは標準的なPostgreSQLに比べて、同じ数のCPUを使用する
はじめに こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。この記事は、Merpay Advent Calendar 2019 の21日目の記事です。 3年前、ソーシャルゲーム業界からメルカリに転職してから、幸運なことにゼロイチで決済サービスの開発に関わることができて、エンジニアとしても人生としてもとても充実の3年間を送りました。 そして、今、日本ではすでにキャッシュレスブームが始まっていて、これからFinTechの領域で様々な革命が起きていくと思っています。この記事では私がエンジニアとしてこれまでに決済サービスの開発に関わってきたことを振り返り、これからFinTechに関わりたい方への参考になればと思います。 社内向け決済基盤の検討 メルカリに入社してすぐ、当時社内ID基盤を開発していたPlat
TiKVにおけるトランザクションとMVCCの話
はじめに PingCAPの小板橋です。はじめまして！ TiDBの入門記事から上級者編まで幅広く取り扱う本アカウント第5回目は「TiKVにおけるトランザクションとMVCCの話」についてをまとめていきたいと思います。 TiKVの仕組み まずは、TiKVの仕組みについてを見ていきましょう。 全体のTiDBクラスターのアーキテクチャについては、下記の記事をご覧ください。 TiDBクラスターにおけるデータレイヤーにあるストレージノードとしてTiKVと呼ばれるものがあります。 TiKVは、分散型のキーバリューデータベースになり、ACIDに準拠したトランザクションAPIを提供しています。このTiKVの裏には、RocksDBとRaftコンセンサスアルゴリズムによって動作しています。 Raftコンセンサスアルゴリズムについては、また別の記事で深ぼっていきます。(こちらはこちらでお楽しみに！) RocksDB
Cloud Nativeなシステムを構築するにあたって手助けとなる、アプリケーション開発と運用のアジリティ、可用性、拡張性を支えるさまざまなデータベースを学ぶ「Cloud Native Database Meetup #1」。ここで「NewSQLへの誘い」をテーマに小林氏が登壇。NewSQLが登場するまでの流れと、NewSQLのストレージエンジンと分散トランザクションについて紹介します。 自己紹介とセッションのアジェンダ 小林隆浩氏（以下、小林）：では、さっそく本セッションに入っていきますが、まずは私のほうでイントロダクションをこのままやります。 イントロダクションのテーマは、「NewSQLへの誘い」というかたちで進めていきます。私は小林と言い、データベースに関する連載や、書籍の翻訳なんかをしているエンジニアです。 いろいろなデータベースをつまみ食いするのが好きで、評価したり検証したり。あ
マスタリング・イーサリアム
イーサリアムとは、分散型アプリケーションやスマートコントラクトのアプリケーション構築を可能にするオープンソースプロジェクトです。送金、決済などの金銭取引を行う機能に加えて、ゲーム、不動産取引、身分証明など、さまざまなサービスがイーサリアムから生まれています。本書は、ビットコインの定番書『Mastering Bitcoin』の著者と、イーサリアム共同設立者でありスマートコントラクト開発言語Solidityの開発者により執筆された、イーサリアムの技術解説書。イーサリアムとブロックチェーンの基本に始まり、ウォレット、トランザクション、Solidity言語によるスマートコントラクトの構築、暗号とセキュリティ、Vyper、DAppの構築、ERC20トークン、イーサリアム仮想マシン（EVM）、コンセンサスの仕組みまで、幅広い知識が得られます。イーサリアムについて詳しく知りたいすべての人必携の一冊です。
OceanVista http://www.vldb.org/pvldb/vol12/p1471-fan.pdf 基本的アーキテクチャは、DC間クラスターをインフラにおいて、高遅延・耐障害性を前提にした分散transactionの仕組みになっている。 どう見てもAlibabaのOceanBaseそのものではない。が、同じAlibabaグループでかつ、Oceanの名前をつけているので、関係はなくはないと思う。少なくとも同じグループまたは情報交換はしているのではないか。技術的な方向性を模索するプロトタイプに見える。 バックグラウンド的な与太話をすると、Alibabaは、というか中国的には、ITでの米国からの依存脱却（ポーズだけなのか、実際なのかは置いておいて）を目標として掲げているのは周知の通り。んで具体的な話としては、Alibaba的には脱Oracleが一つの目標になっている。この目線で見た
CloudNativeがここまで進化するとインスタンスの仮想化技術をベースとしたシステムなど使いたくなくなってしまいます。 私は新たにシステムを構築する際、必ずServerless Firstの考え方で設計をしていきます。 その中でAWS Lambda、Amazon DynamoDBを中心にMicroservicesの設計をしていくのですが、 ACIDの部分をどう対処するかが一番悩むところです。 今回はServeice間のTransactionに関する話を自分なりに整理していきたいと思います。 図1 Saga Design Pattern Sagaは複数のサービスにまたがるトランザクションを実装するためのマイクロサービスアーキテクチャパターンです。 複数のマイクロサービス間でデータ一貫性を実現するもので、Sagaには２つのパターンがあります。 1. Choreography-based S
Sagaパターンについて - Qiita
概要 マイクロサービスでは、移行する際にシステム移行に伴うDBの分解が発生した場合に、分散トランザクションは推奨していません。参照: マイクロサービスに移行した際の分散トランザクションの危険性 簡単に説明するなら分散トランザクションは、不具合となる危険性がある為です。 そのため、マイクロサービスで複数のリソースの結果整合性を利用する方法として、Sagaパターンがあります。 Sagaパターンとは Sagaパターンとは、結果整合性を使ったアーキテクチャの1つであり、複数の状態変更を調整できリソースを長時間ロックすることがないよう設計されたアーキテクチャパターンです。「Sagaの元々のアイデアは、Hector Garcia MolinaとKenneth Salemによって発表された論文から生まれました。」 もう少し詳しく説明すると、結果整合性を担保したい範囲を１つのローカルトランザクション(擬似
「注文サービスをサーバーレスで作ってみた」JAWS DAYS 2020登壇資料 #jawsug #jawsdays #jawsdays2020 | DevelopersIO
「注文サービスをサーバーレスで作ってみた」JAWS DAYS 2020登壇資料 #jawsug #jawsdays #jawsdays2020 本記事ではAWS上の分散トランザクションを構築する方法を紹介させて頂きたいと思います。あと、そのトランザクションの結果をストリーミングさせ、クライアントにデータが自動で連携される仕組みについても紹介させて頂きます。最後に、私が作ってみたサービスのフルコードのGithubレポジトリーを共有致します。 本記事は、オンラインで開催された「JAWS DAYS 2020」の登壇記事となります。 はじめに こんにちは、コンサル部のテウです。 去年の年末年始休暇中、マイクロサービスのいろんな実装パターンについて勉強をしましたところ、分散トランザクションのことにすごく興味が出来ました。そもそもトランザクションの意味だけが分かっていたレベルだったのですが、もっと詳し
更新APIの難しさ ネットワークの向こう側にあるリソースを更新するのは、単純なTCP/IPの仕組みでは難しい。その上に構成されたシンプルなプロトコルである単純なHTTPで実現しようとすると、以下に示すような箇所でエラーの発生可能性があり、双方で等しく検知することができないケースが存在し、同期的なリカバリが困難である。 エラーの発生箇所 1. クライアント→サーバの接続エラー 2. クライアントからリクエスト送信したがサーバに届かない。 3. サーバが不完全なメッセージを受信した。 4. メッセージがサーバの処理キューに入らない。 5. サーバで処理が正常に完了しない。 6. サーバからレスポンスを返そうとしたが接続が切れている。 7. サーバからレスポンスを返したが、クライアントに届かない table:エラー検知 クライアント サーバ ① コネクションタイムアウト,... 検知不能 ② ソ
はじめにこんにちは、Technology Innovation Group所属 DBチームの岩崎です。 テックブログにて記事を書くのは1年半ぶりです。(反省)あれからずっと設計～開発まで推進し、無事アプリリリースが完了しました。 — 脱RDB脳 — Cassandraのデータモデルについて考えてみる このタイミングで改めてKVS関連のナレッジを還元できたらと思い筆を執りました。 1. データモデル設計の勘所前回の記事でも書かせていただきましたが、KVSを採用するにあたって一番ポイントになるのがデータモデル設計です。 ここを外すと、開発で大いに苦しみます。場合によっては要件を満たせず再設計ORノックアウトなんてことにも繋がりかねません。 1-1. 更新要件を中心に設計するのがベターKVSはキーアクセスしかできないのでデータ参照にフォーカスしたモデルを設計しがちです。 もちろんこのアプローチは
Rails APIドキュメント: Active Recordのトランザクション（翻訳）｜TechRacho by BPS株式会社
概要 MITライセンスに基づいて翻訳・公開いたします。 英語ドキュメント: ActiveRecord::Transactions::ClassMethods（18707ab） ライセンス: MIT 2020/11/30: 初版公開（77f7b2d） 2022/12/07: 更新 トランザクションとは、それが1件のアトミックな操作としてすべて成功した場合に限りSQLステートメントが永続化する、保護的なブロックです。古典的な例としては「出金が成功した場合にのみ入金ができる（またはその逆の）2つの口座間での振替」があります。トランザクションはデータベースの一貫性を強制し、プログラムのエラーやデータベースの破損からデータを保護します。つまり、「すべて一括実行される」か「一切実行されない」かのどちらかでなければならないステートメントが複数ある場合は、基本的にトランザクションブロックを使うべきです。
【感想】『マイクロサービスパターン 実践的システムデザインのためのコード解説』：前編 - Rのつく財団入り口
「未来はすでにここにある。まだむらなく流通していないだけだ」←グッとくる 最初のエモワードがSF作家ウィリアム・ギブスンの引用でイイ！ サイバーパンク2077遊んでみた～い……じゃなかった、CloudFoundry.comのファウンダーでありMicroservices.ioの運営者、経験豊富なソフトウェアアーキテクトであるクリス・リチャードソンさんによる『Microservices Patterns』の翻訳本。 タイトルのようにアーキテクチャパターンやデザインパターンのようにマイクロサービスをパターンで体系化し、サンプルストーリーを元にした事例やコード例、OSS紹介を交えつつマイクロサービスを実践する設計方法を探求した本となっています。 Java文化圏で長く活動してきた方とのことでサンプルコードはほぼJava、Springフレームワーク、ご本人らによるマイクロサービス用のフレームワークEv
ビジネスブロックチェーンExpoは、ブロックチェーン技術を活用した産業課題解決・支援やビジネス創出を目指す国内外の企業を紹介するイベントです。その中で、スマートロックで有名なビットキーのVPoEである山本寛司氏が、ビットキーが目指すミッションについて紹介しました。 テクノロジーの力であらゆるものを安全で便利に気持ちよくつなぐ 山本寛司氏：ビットキーの山本と申します。本日はブロックチェーンの課題感とID権利、取引を管理する分散合意プラットフォームでの挑戦について、みなさまと共有できればと思っています。よろしくお願いいたします。 私はビットキーでVP of Engineering、いわゆるVPoEをやっています。CTOのようなイメージをもってもらえればいいかなと思います。 簡単にですが、私の経歴を紹介させてください。もともとエンジニアの道は歩いておらず、ロースクールを卒業して、縁があって前職は
PostgreSQLのread committed時におけるUPDATEの挙動について - そーだいなるらくがき帳
発端 @soudai1025 https://t.co/ZrXgtDi2La— Ryo Tomidokoro (@hanhan1978) 2022年7月2日 ファントムリードとファジーリード、それぞれがRCでも発生するかどうかって話ですか？— そーだい@初代ALF (@soudai1025) 2022年7月2日 端的に言うと， A: UPDATE tbl SET amount = amount - 1 WHERE amount > 0; B: UPDATE tbl SET amount = amount -1 WHERE amount > 0; で A と B がほぼ同時に流れたとき，amount がマイナスにならない保証があるかどうかですね。SET する部分がアトミックでも WHERE は…？というところです— RDB 初心者 (@mpyw) 2022年7月2日 反復不能読み取り=ファジ
Microservice and Transaction Management1 マイクロサービストランザクションの動向 - Qiita
はじめに はじめまして。日立製作所 クラウドビジネス推進センタの西谷と申します。ひょんな思い付きから、技術投稿を始めることにしましたので、よろしくお願いします。 今回は、マイクロサービスの最難関とも呼ばれているトランザクション管理について連載していこうと思います。 以下のような連載を考えてますが、LGTMいっぱいくれたら執筆をもっとがんばろうと思います 笑。 マイクロサービストランザクションの動向(今回) トランザクションの原則：ACID特性とCommitment Ordering1 トランザクションの原則：ACID特性とCommitment Ordering2 合意理論からみる2Phase CommitとMicroserviceマイクロサービス 結果整合性は本当に整合するのか ゴール マイクロサービスでトランザクション管理する主流の考え方を大まかに理解する。 マイクロサービスとは何か マ
(ベンダーの公式サイト以外での) 日本語によるメインフレーム技術情報は非常に貴重なので、以下の記事は大変興味深く読ませていただいた。 qiita.com で、この記事に付いたコメントで気になる問題提議があったので、連休のヒマに任せて参戦してみる。 Masanori Kusunoki / 楠 正憲 on Twitter: "汎用機の信頼性が今以てスゴい仕組みであることは間違いない。「他のノードから回復処理を行うべき」という後続はTandem/HimalayaとかStratusあたりと推察するんだけど、あの手の技術って今に引き継がれてるんだろうか？ / “メインフレームの異常処理 - Qiita” https://t.co/VQtR6lTVuH" 汎用機の信頼性が今以てスゴい仕組みであることは間違いない。「他のノードから回復処理を行うべき」という後続はTandem/HimalayaとかStra
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソシャゲサーバー開発するとき始めに考慮しておかないと死ぬポイント備忘録
MySQL/Postgres におけるトランザクション分離レベル
開発者が知っておきたいSQLの実行モデル～アプリからデータベースへのアクセスを高速化するには？
[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際
「DDDで複数集約間の整合性を確保する方法 Rev2」に対する考察 - かとじゅんの技術日誌
#CloudNativeDB NewSQLへの誘い
メルコイン決済基盤における分散トランザクション管理 | メルカリエンジニアリング
InnoDBのMVCCのガベージコレクションについて - shallowな暮らし
BOOTHの“決済スパイク”を防げ！ 創作物の総合マーケットを支えるトランザクション分割
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ
分散合意アルゴリズム Raft を理解する - Qiita
グーグルのHTAP対応PostgreSQL互換DB「AlloyDB」、データ分析性能は最大100倍
メルペイ立ち上げの裏側 – 決済サービス開発のゼロイチ話
Spannerの登場で急拡大したNewSQL 分散トランザクションの課題をどう解決したか
OceanVista 再読 - 急がば回れ、選ぶなら近道
Serverless Microservices - Saga Transaction - Qiita
Web APIのトランザクション - kawasima
KVSと二年間向き合って得たナレッジを還元する時がきた | フューチャー技術ブログ
あらゆるモノが安全につながれば世界は変わる ビットキーの認証認可プラットフォームが目指すシームレスにつながる社会
Tandem や Stratus の目指した世界は今に引き継がれてるのか？ - cat-a-log