2019年SRE考 - ゆううきブログ
この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちに、SREに関する私的な論考をまとめておく。 (以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。) SREとの関わり なぜSREに関心をもったのか 2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニア、インフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SRE
マイクロサービスの Saga パターンについて - Qiita
以前の記事で『Microservice Patterns』について要約したが、その中の一つの Saga パターンについて、もう少し詳しく掘り下げてみる。 どういう文脈で Saga パターンを使うか？ 各サービスがそれぞれの Bounded Context (整合性の境界)で自前のデータストア（Database per Service）を持っているマイクロサービスアーキテクチャで、複数サービスにまたがるワークフローのデータ整合性を維持したい。 どういう制約のもとで Saga パターンを使うか？ 以下のような事情で、分散トランザクションは使いたくない。 モダンでメジャーな NoSQL やメッセージブローカではサポートされていないものが多い。 CAP 定理の認知度が高まって、Consistency を絶対視する風潮が見直され、Availability をより重視するシステムも増えている。 分散ト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
