SQL ServerのCDCを用いた加熱商品の販売イベントにおける負荷軽減の取り組み - ZOZO TECH BLOG
こんにちは、SRE部の廣瀬です。 本記事では、ZOZOTOWNでカートに商品を入れる際に使われているデータベース群の内、SQL Server（以降、カートDBと呼ぶ）にフォーカスします。ZOZOTOWNでは数年前から、人気の商品（以降、加熱商品と呼ぶ）が発売された際、カートDBがボトルネックとなる問題を抱えています。様々な負荷軽減の取り組みを通じて状況は劇的に改善されていますが、未だに完璧な課題解決には至っていません。 そこで今回は、加熱商品の発売イベントにおける負荷軽減の取り組みを振り返ります。また、直近の取り組みとして、SQL ServerのCDCを用いた新たな負荷軽減の検証内容をご紹介します。 背景 - カートDBのボトルネックについて 加熱商品の発売イベントに関する対策について、最初に言及した記事としては以下が挙げられます。この記事では人気の福袋商品を加熱商品として紹介していますが
書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について - Qiita
この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad
エッジコンピューティングを活かしたウェブアプリケーションホスティング構想 - ゆううきブログ
さくらインターネット研究所では、超個体型データセンターというコンセプトに則り、あらゆるデバイスと場所がデータセンターとなり、各データセンターが有機的に結合した集中と分散のハイブリッド構造をもつコンピューティングを目指している。 超個体型データセンターにとって、重要な先行コンセプトに、エッジコンピューティングがある。 この記事では、エッジコンピューティング環境において、ウェブアプリケーションをホスティングするためのアーキテクチャを考察する。 エッジコンピューティング Kashifらのサーベイ論文1によると、エッジコンピューティング技術を必要とする背景は、次のようなものになる。 スマートデバイス、ウェアラブルガジェット、センサーの発展により、スマートシティ、pervasive healthcare、AR、インタラクティブなマルチメディア、IoE(Internet of Everything)な
人気順検索のSolrはスケールのためにディスクを捨てた - クックパッド開発者ブログ
技術部クックパッドサービス基盤グループの id:koba789 です。 昨年まではデータ基盤グループというところで 最新のログもすぐクエリできる速くて容量無限の最強ログ基盤 を作ったりしていました。 今年はちょっとチームを移動しまして、検索システムをいじっていました。今回はそのお話です。 なお、クックパッドには様々な検索システムがありますが、この記事では説明を簡単にするためにレシピの検索のみに焦点をあてています。 クックパッドの検索システムにあった課題 クックパッドにはレシピを検索できる機能があります。 プレミアム会員限定の人気順検索もこの機能の一部です。 しかし、この重要な機能を支える検索システムにはいくつもの課題がありました。 Solr が古すぎる クックパッドでは、レシピ検索を含む多くの検索機能にSolrを用いています。 今年の始めに私がこの課題に取り組み始めた時点では、その Sol
詳細設計における成果物一覧と書き方（詳細設計書サンプルあり） | 若手エンジニアの羅針盤
システム開発工程における詳細設計は、どんな作業をすればいいのか、どんなアウトプットを出せばいいのか疑問を持つことも多いと思う。 そこで今回は詳細設計のサンプルを紹介しつつ書き方も簡単に説明していく。 なお、詳細設計は内部...
Data Models
Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves
オブジェクト指向 Rails しばしば出てくる3つの悩みを解決する。 - Qiita
はじめに Railsで開発をしていると頭を悩ます３つのしばしばがあります。 １つのモデルで複数のモデルを操作してしまう 冗長なコードが複数のモデルまたはコントローラに出てくる 表示のためだけに、モデルにメソッドを追加する これらを解決するためには、オブジェクト指向とデザインパターンによる考え方ができるとよいです。 この記事では、Railsでよりオブジェクト指向的に、より構造が単純で、より DRYに書くためのパターンを学びます。 環境は Rails 4 です。 キーワードは３つ。 複雑なビジネスロジックを分離する Non associated Model 関心の分離を保ちつつ処理をまとめる Model/Controller Concerns 表示ロジックをモデルから分離する Decorator Non associated Model 解決する問題 １つのモデルで複数のモデルを操作してしまう
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
DDDにおいてRDBMSとのインピーダンスミスマッチをどう扱うべきか？
Ryo Asai @ryoasai74 なるほど。P157「一般的に言えることだが、使っているフレームワークとは争わないこと。フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、詳細は捨て去る方法を模索すること。」#DDDjp 2011-04-30 20:20:19 Ryo Asai @ryoasai74 P160「データベースをオブジェクトの格納先として見る場合には、マッピングツールの能力に関わらず、データモデルとオブジェクトモデルをかけ離れたものにしてはならない。」これは読み落としてはならないことですね。モデルと実装を結びつけ、無駄な間接層による複雑さを避けるべき。#DDDjp 2011-04-30 21:01:35
DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
DCIアーキテクチャへの違和感から見えてくるユースケースDSL - 石橋秀仁(zerobase)書き散らす
DCIとDDD DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticismを読んだり、DCI meetup w/ @jcoplien for Rubyistsに参加したりして、DCIアーキテクチャについて考えてきた。 DCIはメッセージパッシング指向だ。そのSmalltalk的なオブジェクト指向の原理はいいけど、実装が嫌だ。 そもそも、DCIアーキテクチャ提唱の目的は、メンタルモデルのセマンティクス・ギャップを埋めることだ。DDDの「ユビキタス言語」も、メンタルモデルのセマンティクス・ギャップを埋めるための要素であり手法だ。だから、ふつうにDDD（ドメイン駆動設計）をやればいいと思った。 DCIへの疑問 DCIでは、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって
ドメインモデルの関連を表現するには - じゅんいち☆かとうの技術日誌
たとえばこんなモデルがあって、相互に依存しているケースを考えよう。 注意:説明を簡単にするために、varを利用しています。 従業員1 2 3 4 5 class Employee( val id: Long, val name: String, var depertment: Option[Depertment] = None ) 部署1 2 3 4 5 class Depertment( val id: Long, val name: String, var employees: Seq[Employee] = Seq.empty ) 利用例1 2 3 4 5 val employee = new Employee(1, "KATO") val depertment = new Depertment(1, "Dev") employee.depertment = Some(depertm
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
JAWS-UG@Kyoto で発表してきました - wtatsuruの技術方面のブログ
[http://atnd.org/events/21055:title-JAWS-UG - Kyoto勉強会 第2回] で、「はてなブログの下側」というタイトルで発表してきました。 JAWS-UG-Kyoto-2nd View more presentations from Tatsuru Watanabe 内容に関してはこんな感じです。 はてなのサービスとして初めてAWS上でリリースされた、はてなブログのインフラ面について。 ベータ中の体制と将来的な案、それに関わるメリットと不安。 柔軟なインフラが作れてうれしい！ L2, L3 の自由が無くて苦しい！ CPU・メモリは安くてうれしいが、SSD中毒なのでI/Oつらい！
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
基本設計における成果物一覧と書き方（基本設計書サンプルあり） | 若手エンジニアの羅針盤
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
PostgreSQLアンチパターン
はてなブックマークにおけるアクセス制御 - 半環構造に基づくモデル化
InfoQ: データの削除は非推奨
DCI and the application builds our mental models
