DynamoDB利用時の書き込みスキュー（Write Skew）の回避 | フューチャー技術ブログ
はじめに一般的に複数のトランザクションが並行して同じオブジェクトに対してアクセスを行う場合には、トランザクションの分離レベル（SERIALIZABLE/REPEATABLE READ/READ COMMITTED/READ UNCOMMITTED）によって様々な問題が発生します。 DynamoDBは2018年にトランザクションがサポートされましたが、本記事ではファントムリードによる書き込みスキューの問題とその対応について取り上げたいと思います。 書き込みスキューとはまずはじめに、「書き込みスキュー」とは具体的にどのような問題なのか、まず例を見てみるのが一番わかりやすいでしょう。 書き込みスキューの例ここではイベントの申し込みシステムを考えてみましょう。 要件としてイベントの申し込み人数の上限は3人であると仮定します。 これを実現するためには、ユーザが申し込みの要求を行なった際に現在の申し込
TCCパターンとSagaパターンでマイクロサービスのトランザクションをまとめてみた | Wakatchi Tech Blog
こんにちわ、サイト管理者のわかっち (@wakatchi_tech) です。 質問者 マイクロサービスでシステム作ったらトランザクション管理がしんどいです。 こんな質問をいただきました。 マイクロサービスアーキテクチャでシステムを構築した際、更新対象が複数のサービスをまたがる場合は、トランザクションの扱いが途端に難しくなります。なかでも、障害発生時に各サービス間の処理をロールバックするためには補償(補正)トランザクションが必要になり、複雑なトランザクション制御が求められます。 補償トランザクションとは、処理の途中で失敗した場合に、それを取り消すことで実行結果を打ち消す処理のことです。補償トランザクションの実装は、打ち消す処理を提供するサービスと、それを呼び出すサービスの双方に負担があり、設計や実装が複雑になりがちです。 トランザクションには、1つのトランザクション内で1つのリソース（DBな
CockroachDBにおけるトランザクション実行のための3条件 Atomicity、状態判断、順番判断の必要性
Cloud Nativeなシステムを構築するにあたって手助けとなる、アプリケーション開発と運用のアジリティ、可用性、拡張性を支えるさまざまなデータベースを学ぶ「Cloud Native Database Meetup #1」。ここで「分散トランザクション in CockroachDB 」をテーマにkota2and3kan氏が登壇。まずはCockroachDBの概要と課題について紹介します。 CockroachDBの概要 kota2and3kan氏：それでは、「分散トランザクション in CockroachDB」というタイトルで私から話します。まず自己紹介ですが、こたつ＆＆みかん（＠kota2and3kan）というアカウントで活動しています。ふだんはサポートの仕事をしていて、ポスグレやCockroachDBを中心に、データベース周りの技術に興味があります。 （スライドを示して）さっそく本題に
Spannerの登場で急拡大したNewSQL 分散トランザクションの課題をどう解決したか
Cloud Nativeなシステムを構築するにあたって手助けとなる、アプリケーション開発と運用のアジリティ、可用性、拡張性を支えるさまざまなデータベースを学ぶ「Cloud Native Database Meetup #1」。ここで「NewSQLへの誘い」をテーマに小林氏が登壇。NewSQLが登場するまでの流れと、NewSQLのストレージエンジンと分散トランザクションについて紹介します。 自己紹介とセッションのアジェンダ 小林隆浩氏（以下、小林）：では、さっそく本セッションに入っていきますが、まずは私のほうでイントロダクションをこのままやります。 イントロダクションのテーマは、「NewSQLへの誘い」というかたちで進めていきます。私は小林と言い、データベースに関する連載や、書籍の翻訳なんかをしているエンジニアです。 いろいろなデータベースをつまみ食いするのが好きで、評価したり検証したり。あ
サーバーレスにおけるべき等性の実装 (バッチ処理と分散トランザクション編) ~サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第 4 回~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
このシリーズの 第２回 では、クライアントからバックエンドのサービスを利用する際に、なんらかの原因でエラーが発生した場合にクライアント側でリトライ処理が実行されると、リクエストが重複して送られる可能性があることを説明しました。クライアントからキューに対してメッセージを送信するようなサーバーレスのシステムにおいては、リトライ処理によって重複したメッセージが送信されてもメッセージの重複を排除する機能を利用することによってべき等性を実現する方法について解説を行いました。その中では、重複したメッセージをただ一度だけ処理する (Exactly Once) ことで、結果としてべき等性を実現するという具体的な実装方法と共に紹介しました。 第 3 回 では、キューからメッセージを取り出し、バックエンドのデータソースへ保存する処理においても、何らかのエラーによってリトライ処理が発生した場合に重複してデータの
あらゆるモノが安全につながれば世界は変わる ビットキーの認証認可プラットフォームが目指すシームレスにつながる社会
ビジネスブロックチェーンExpoは、ブロックチェーン技術を活用した産業課題解決・支援やビジネス創出を目指す国内外の企業を紹介するイベントです。その中で、スマートロックで有名なビットキーのVPoEである山本寛司氏が、ビットキーが目指すミッションについて紹介しました。 テクノロジーの力であらゆるものを安全で便利に気持ちよくつなぐ 山本寛司氏：ビットキーの山本と申します。本日はブロックチェーンの課題感とID権利、取引を管理する分散合意プラットフォームでの挑戦について、みなさまと共有できればと思っています。よろしくお願いいたします。 私はビットキーでVP of Engineering、いわゆるVPoEをやっています。CTOのようなイメージをもってもらえればいいかなと思います。 簡単にですが、私の経歴を紹介させてください。もともとエンジニアの道は歩いておらず、ロースクールを卒業して、縁があって前職は
Serverless Microservices - Saga Transaction - Qiita
CloudNativeがここまで進化するとインスタンスの仮想化技術をベースとしたシステムなど使いたくなくなってしまいます。 私は新たにシステムを構築する際、必ずServerless Firstの考え方で設計をしていきます。 その中でAWS Lambda、Amazon DynamoDBを中心にMicroservicesの設計をしていくのですが、 ACIDの部分をどう対処するかが一番悩むところです。 今回はServeice間のTransactionに関する話を自分なりに整理していきたいと思います。 図1 Saga Design Pattern Sagaは複数のサービスにまたがるトランザクションを実装するためのマイクロサービスアーキテクチャパターンです。 複数のマイクロサービス間でデータ一貫性を実現するもので、Sagaには２つのパターンがあります。 1. Choreography-based S
「注文サービスをサーバーレスで作ってみた」JAWS DAYS 2020登壇資料 #jawsug #jawsdays #jawsdays2020 | DevelopersIO
「注文サービスをサーバーレスで作ってみた」JAWS DAYS 2020登壇資料 #jawsug #jawsdays #jawsdays2020 本記事ではAWS上の分散トランザクションを構築する方法を紹介させて頂きたいと思います。あと、そのトランザクションの結果をストリーミングさせ、クライアントにデータが自動で連携される仕組みについても紹介させて頂きます。最後に、私が作ってみたサービスのフルコードのGithubレポジトリーを共有致します。 本記事は、オンラインで開催された「JAWS DAYS 2020」の登壇記事となります。 はじめに こんにちは、コンサル部のテウです。 去年の年末年始休暇中、マイクロサービスのいろんな実装パターンについて勉強をしましたところ、分散トランザクションのことにすごく興味が出来ました。そもそもトランザクションの意味だけが分かっていたレベルだったのですが、もっと詳し
分散合意アルゴリズム Raft を理解する - Qiita
Raft は Byzantine 障害に対する耐性がなく、論文を一見して恒久的なリーダーの乗っ取りからのログの改ざん、リーダー選挙の妨害などが可能であるところを見ても、P2P ではなく完全に管理されたネットワーク向けの合意アルゴリズム (CFT; Crash Fault-Tolerance) です。Byzantine 障害耐性が必要であれば Raft ではなくパフォーマンスを犠牲にして pBFT などを使う必要があるでしょう。 論文では Crash-Recovery より深刻な障害耐性には言及していないが (論説の範囲を外れるため当然だが)、もし実際に Raft を実装するなら現実的に想定される障害に対して工夫できる余地もいくつか存在します。例えば「テスト環境で使用していたノードの 1 つが事故で本番クラスタに『も』参加してしまった」といったような運用事故で起きうる障害は (大抵そのような
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つ目のアルゴリズム・シャー
2020年現在のNewSQLについて - Qiita
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
メルペイ立ち上げの裏側 – 決済サービス開発のゼロイチ話 | メルカリエンジニアリング
はじめに こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。この記事は、Merpay Advent Calendar 2019 の21日目の記事です。 3年前、ソーシャルゲーム業界からメルカリに転職してから、幸運なことにゼロイチで決済サービスの開発に関わることができて、エンジニアとしても人生としてもとても充実の3年間を送りました。 そして、今、日本ではすでにキャッシュレスブームが始まっていて、これからFinTechの領域で様々な革命が起きていくと思っています。この記事では私がエンジニアとしてこれまでに決済サービスの開発に関わってきたことを振り返り、これからFinTechに関わりたい方への参考になればと思います。 社内向け決済基盤の検討 メルカリに入社してすぐ、当時社内ID基盤を開発していたPlat
メルペイのマイクロサービスアーキテクチャの裏側と、不整合を防ぐための工夫
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「静的MPM決済を支える技術 」に登壇したのは、株式会社メルペイのsusho氏。今年の6月にサービスが開始したばかりのメルペイのサーバーサイドの特徴と工夫について語ります。 静的MPM決済を支える技術 susho氏：こんばんは。「静的MPM決済を支える技術」ということでsushoが発表させていただきます。 最初に自己紹介です。 社内ではsushoと呼ばれているので、ここでもそうさせていただいております。Twitterは@susho0220でやっています。
顧客データHub開発の裏側（中編） - Sansan Tech Blog
CTO藤倉です。今年3月、法人向けクラウド名刺管理サービス「Sansan」の新機能「顧客データHub」を発表しました。 これは、Sansanがこれまで蓄積してきた技術とノウハウを応用したテクノロジーで、独自の「名寄せエンジン」を用いて社内のあらゆる顧客データを統合できる機能です。 今回は、顧客データHubの開発を牽引したエンジニアである千田智己に話を聞きました。前中後編の3回に分けて紹介します。 中編では、彼の持つ技術や過去に担当したプロジェクトについて語ってもらいました。 入社直後に携わった戦略案件 藤倉：千田さんが最初に担当したのは、「Sansanスマートフォンプラン」のプロジェクトだったね。 千田：それまでのSansanとは違うビジネスモデル・販売モデルの構築を目指していました。このプロジェクトは仕様策定に難航して、ビジネスモデルが最終的に確定したのはリリース1か月前くらいでしたね。
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Implementing the transactional outbox pattern with Amazon EventBridge Pipes | Amazon Web Services
【SQLを学ぶ醍醐味】複数テーブルを扱うJOIN結合とトランザクションをくわしく解説
分散システムにおけるSagaパターンのAWS Step Functions による実装 �#AWSDevDay