はじめに 以前投稿した通り TROCCO のジョブ画面に表示されるログは DB に保存されていました。 サービス開始から時間が経ち、保存されたログのサイズが見過ごせない大きさになったため、去年 SRE ではログを S3 に保存する大掛かりなリアーキテクチャを行いました。 その後ログが S3 に保存されるようになったものの、依然として古いログは DB に保存されたままでした。 先日それらログをついに消し去るに至ったので成果と道のりをまとめたいと思います。 結果発表 消したサイズ 9TB 削減したコスト $5,340/month (¥865,080/月 - 162円換算) 消したログ数 推定4億 ※ ログ保存用カラムを NULL or 空文字 に置換しました 内容 ログが保存してある DB のカラムの値を NULL か空文字に置換することでログを削除しています。 また後述する通り削除後に OP
こんにちは！ 承認チームでGoエンジニアとしてインターンをしているunagamです。 最近は夏の旅行先として色々な場所を調べるのにハマっています。 今回はあまり馴染みのないSQLのLATERAL句で大幅にAPIを高速化できたので、その学びを共有したいと思います。 概要 APIのボトルネックだったSQLを、LATERAL を使って 94.7ms → 0.236ms（99.75%削減） まで短縮できた。 ただし LATERAL は無条件に速くなるわけではない。外側の行数に比例してコストが増えるという性質があり、条件次第では逆に遅くなる恐れがある。 それでも、リスクを理解した上で適用すれば、LATERAL は強力な改善策になり得る。 経緯 Datadogを用いて承認サーバーのAPIを監視していた際、一週間の合計処理時間が1.6日と他と比べて圧倒的に処理時間を消費しているAPIを見つけました。 処
はじめに 2026年5月26日に、コミュニティ版 MySQL 8.4.7 と互換性のあるAmazon Aurora MySQL 8.4（以下、Aurora MySQL 8.4）がGA（一般公開）となりました。 Auroraクラスターを作成しようとした際には、エンジンバージョン一覧画面にて「Aurora MySQL 8.4.7」が選べるようになっています。 本記事では、Aurora MySQLの新しいバージョン管理方式や主な変更点に触れつつ、コミュニティ版MySQL 8.0と互換性のあるAurora MySQL 3からAurora MySQL 8.4へのアップグレード時に確認しておくべき変更点や、サポート終了（EOL）までのスケジュールについてご紹介します。 Aurora MySQL 8.4における変更点 今回のアップデートはAurora独自の機能拡張ではなく、純粋にMySQL 8.4ベース
こんにちは、いつも心に冪等性 sinmetalです。「Merpay & Mercoin Tech Openness Month 2026」の3日目の記事です。 本記事では、MySQLで動いていた「お客さまが所持するクーポン一覧取得」クエリをSpannerへ移行した際に直面したパフォーマンス問題と、その解決までの過程を紹介します。 DBごとのアーキテクチャの差 MySQLとSpannerはどちらもSQLを利用できますが、アーキテクチャが大きく異なるので、テーブルやクエリの設計は異なります。移行する時は差異があるSQLを修正するだけでなく、各DBのアーキテクチャまで意識して、実装を見直す必要があります。 MySQLのアーキテクチャ MySQLはPrimary InstanceがWriteを担当するのでWriteをスケールさせたいなら、Primary Instanceのマシンを強化します。 Re
MySQL 9.7 は Oracle MySQL の新 LTS メジャーとして登場しました。RDS では Preview 提供のみですが、公約6ヶ月以内に基づくと 2026年10月頃が GA の目安になります。 MySQL 8.0.46 はコミュニティ 8.0 系の最終リリースです。Oracle の Premier Support は 2025年4月に、Extended Support も 2026年4月に終了しており（MySQL Product Support EOL Announcements）、今後新たなマイナーリリースは予定されていません。後継 LTS は 9.7 系です。 結果の背景・メカニズムの考察 RDS for PostgreSQL が即日提供できる理由について、公式ブログでは「PostgreSQL and MariaDB communities develop in th
こんにちわ。せじまです。 むかしむかし、社内勉強会で話した内容を公開させていただくということが何度かありました。 TIME_WAITに関する話 EthernetやCPUなどの話 CPUに関する話 先日、社内で「データベースを異なる環境や互換性のあるマネージドサービスなどに移行する際、どういうことを考えてるか、幅広い層に向けて話してください」といった要望がありまして。 久々に話をさせていただきましたので、そのときの資料を公開させていただくことにしました。（いちおう、Speaker DeckにもSlideshareにも両方アップロードしておきました。） 互換性のある（らしい）DBへの移行など考えるにあたってたいへんざっくりfrom Takanori Sejima ※このスライドの内容を全部話すと100〜120分くらいはかかりそうなので、社内ではかいつまんで話しました。 個人的に、データベースの
こんにちは、 Legalscape (採用情報) で法情報のグラフデータを構築・運用するチームに所属するあざらし🦭です。 Docker ComposeでMySQLコンテナのhealthcheckを書くとき、mysqladmin ping を使うのが定番だと思います。ただこの方法には落とし穴があり、healthcheckが通っているのにTCPで接続すると Connection refused になるケースがあります。 本記事では、なぜそうなるのかと、正しいhealthcheckの書き方を紹介します。 よくあるhealthcheck ネット上でよく見かけるのはこのような定義です。 services: mysql: image: mysql:8 healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-P", "
HOME/Technical article/The story of how the Performance Schema was the cause of a worsening error rate in Aurora MySQL, even though the load on the system hadn't increased. The story of how the Performance Schema was the cause of a worsening error rate in Aurora MySQL, even though the load on the system hadn't increased.
CIが8分を超えていました。1日に10回pushすれば、待ち時間だけで80分になります。開発のテンポが悪くなるし、プルリクエスト（PR）のフィードバックループも遅れます。 結果から書くと、CI実行時間を8m08s → 3m37sまで短縮できました。55%の削減です。しかも最初のPRではプロダクションコードの変更は一切なく、CI設定とDB設定だけで47%削減しています。 この改善はRailsアプリのCI（GitHub Actions、matrix 5分割、MySQL使用）で行ったもので、似た構成のプロジェクトならそのまま適用できる部分が多いはずです。この記事では、インフラ層の最適化（第1弾）とアプリ層の最適化（第2弾）の2段階に分けて、やったことを順に書いていきます。 改善の全体像 — なぜインフラ層から着手したか 改善前のCI構成 対象はRailsアプリのCIで、GitHub Action
私はMySQLが好きです。長く使ってきましたし、オンプレミスでの運用もやってきました。 しかし現職に来てからは、PostgreSQLを使う機会が増えました。最初は正直かなり抵抗感がありました。ずっとMySQLを使ってきたので、慣れの問題もありますし、PostgreSQLに対して必要以上に構えていたところもあったと思います。 ただ、実際に使っていくうちに、PostgreSQLの良さが少しずつ見えてきました。最近では、新規開発でどちらを選ぶかと聞かれたら、PostgreSQLを選びたいと思うようになっています。 私はMySQLを長く使ってきたので、昔のMySQLの雑さも知っています。ただ同時に、今でも昔の印象だけでMySQLを語るのは不正確だとも思っています。sql_modeをきちんと設定すれば危ない挙動の多くは避けられますし、MySQL 8でかなり多くの機能が入りました。 また、今回はオンプ
11年ぶりに外部キーNightが帰ってきます。 (前回のイベントはこちら: https://connpass.com/event/11463/) この11... 外部キーに対する思いをたくさん聞けて大変に楽しい会でした。自分も言いそびれたり、盛り込めなかった内容がたくさんあるので、ここで補足しようと思います。 何が言いたかったの 外部キー制約は運用上の障壁になるだけでなく、整合性を守る仕組みとしては力不足すぎる。システム全体のことを考えたとき、不変条件はアプリケーションにエンコードせざるを得ないのだから、そちらに寄せるほうが合理的。 でした。 一定の害が存在することについては、会の中でも認められていたように思います。スキーマの変更を阻害するだとか、パーティショニングできなくなるとか、特にMySQLでは性能劣化が大きいとか、そういうやつです。懇親会でも「トレードオフとして受け入れられる」とい
※2026/01/27 10:00 元のタイトルと内容に含まれていた、「MySQLリポジトリへのコミット頻度が激減」というのは誤りというご指摘を受け修正いたしました。ご指摘くださった皆様、ありがとうございました。 1月24日、The Registerが「Devs assessing options for MySQL's future beyond Oracle」と題した記事を公開した。この記事では、MySQLが直面している存続の危機と、Oracle体制からの脱却を模索するコミュニティの動向について詳しく紹介されている。 以下に、その内容を紹介する。 「MySQLは今、重要な岐路に立たされている」——。 かつてMySQL ABで開発に携わり、現在はPerconaのCTOを務めるVadim Tkachenko氏の言葉は、単なる比喩ではない。ウェブのバックエンドを支え続けてきた巨人が、Orac
こんにちは、株式会社 PKSHA Technology ソフトウェアエンジニアの中西です。 1. はじめに Go 言語で MySQL を利用する場合、標準ライブラリの database/sql と、ドライバである go-sql-driver/mysql を組み合わせるのが一般的です。この構成は、事実上のデファクトスタンダードとして定着しています。[1] また、セキュリティ対策も重要です。特に SQL インジェクションを防ぐため、プレースホルダ ? を用いた Prepared Statement の利用はベストプラクティスと言えます。[2] しかし、この標準的で安全な構成でも、パフォーマンスが著しく劣化するケースはあります。本稿では Prepared Statement の 2 方式を整理し、Go のデフォルト設定で性能が落ちる原因をベンチマーク結果と合わせて示します。解決策と採用時のトレー
やらかしてしまいました。今回は業務における失敗談をお話しようと思います。 何をやらかしたか バッチの実装を誤った結果多数のユーザーにメールを重複送信してしまい、ユーザーはもちろん社内のカスタマーサクセスチーム、開発チームにもご迷惑をおかけしてしまいました。 技術スタック typescript Prisma Mysql バッチの要件 特定のステータスを持つユーザーに対して、以下の処理を行うバッチです ステータスの更新 ※更新すること次のバッチの対象から外れる その他の処理 ※本題から逸れるので省きます メール送信を行う どんな実装をしたか 流れとしてはこんな感じ バッチの対象ユーザーを取得 ユーザーに対して、updateMany等で一括更新処理 処理が終わったら対象ユーザーにメール送信 export async function sample() { // 対象ユーザーを取得 const t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
