最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
ここがつらいよ分散SQLデータベース Yoshitaka Koitabashi Sr. Solution Architect PingCAP株式会社 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_e 自己紹介 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_e Yoshitaka KOITABASHI PingCAP株式会社 Sr. Solution Architect 💙 Database / Serverless / Container ● PingCAPとは？ ● 分散型SQLデータベース ● TiDBの裏側 (アーキテクチャ/MVCC/分散トランザクション/Raft/ etc...) ● 実際の運用現場で直面する課題 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_
Developers Summit 2025 登壇資料
こんにちは。はじめまして。れとるときゃりー(@retoruto_carry)と申します。 最近、個人開発しているサービスのDBをFirebase FirestoreからSupabaseに移行しました。 移行には２週間程かかりましたが、Firestoreでつらみを感じていてた部分が解消されて満足しています。 FirestoreはNoSQLなので、設計が難しく、画面のUI構成やユースケースを熟考したうえでデータ設計を考える必要があり、ガンガン仕様変更したり、複雑なクエリをしたりするには向いていない傾向があると感じていました。 Supabaseは、Firebaseの便利な部分を受け継ぎつつ、バックエンドがRDB(PostgreSQL)なので、上記の欠点が解消されています。 また、Firebaseがクエリごと料金が掛かるのと比較して、Supabaseはインスタンスごとの課金であり、セルフホストも可
はじめに 概要 Apache Iceberg(アイスバーグ)とは [重要] Icebergの本質はテーブル仕様である Table Spec バージョン Icebergハンズオン Icebergの特徴 同時書き込み時の整合性担保 読み取り一貫性、Time Travelクエリ、Rollback Schema Evolution Hidden Partitioning Hidden Partitioningの種類 時間 truncate[W] bucket[N] Partition Evolution Sort Order Evolution クエリ性能の最適化 ユースケース Icebergのアーキテクチャ Iceberg Catalog Iceberg Catalogの選択肢 metadata layer metadata files manifest lists manifest files
そーだいさんが執筆された記事で、履歴テーブルから最新の1件を取ってくる方法について解説している。PostgreSQLの例だと以下のようなユーザーの履歴データに対し: CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First entry of user1', '2024-01-01 10:00:00'), (1, 'Second entry of user1', '2024-01-02 09:30:00'), (2, 'First entr
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした（幸いすぐにキャンセルして事なきを得ました）。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確
こちらは NewsPicksアドベントカレンダーの9日目の記事です。 はじめに こんにちは。NewsPicks エンジニアの鶴房です。 フロントエンドの刷新プロジェクトにおいて、主にインフラとバックエンドを担当しています。 今回は私が以前起こしてしまったサービス全停止の障害の原因と、その再発防止策に関して記載します。 尚、弊社ではRDBMSとしてMySQLを利用しているので、この記事はMySQLに関する内容になります。 障害事象 今年の夏頃、約30分の間、NewsPicksのほぼ全てのサービスが停止してしまいました。 ユーザーは、その間、ログインも、記事を読むことも、記事にコメントすることもできない状態でした。 アプリを開くと、エラーメッセージが表示されるだけの状態で、障害の解消までずっとその状態が続いていました。 障害の直接原因 障害の直接の引き金になったのは、タイトルにある通りALTE
Mercari DBRE(DataBase Reliability Engineering Team)のtaka-hです。 本エントリでは、メルカリの開発環境のデータベース移行の事例を紹介します。なお記事は、MySQL Advent Calendar 2024、およびTiDB Advent Calendar 2024とのクロスポストになります。 この記事の手法を用いて、開発環境では、MySQLからTiDBへ移行すると同時に、スキーマ統合するということを達成しています。本記事により、読者の方々がProxySQLや、TiDBのエコシステムに興味を持っていただけることを期待しています。 TL;DR TiDBのData Migration(以後、TiDB DMと呼びます)のTable Routingを用いると、TiDBにスキーマ統合したインスタンスを作成できる 2段のProxySQLを構成し、1段
この記事は hacomono advent calendar 2024 の18日目の記事です 今年9月にhacomonoにJOINし、基盤本部というところで今後のhacomonoのアーキテクチャ設計をしている @bootjp と申します。分散システムが好きです。 hacomonoも昨今のWebサービスの例にもれず、分散システム化しています。 そしてより高い可用性と低い運用コストを目指して新たなアーキテクチャの検討をしています。 今回はその取り組みのなかで、分散システムに関わる難しさというテーマで一貫した時刻の取り扱いの話で記事を書きます。 はじめに 昨今のWebをはじめとしたサービスは一つのサーバーで完結することが少なくなりました。 一つのアプリケーションを複数のサーバーやコンテナで、そして異なるサービスのシステムを組み合わせて「分散システム」として構築されています。 それは可用性や負荷分
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
趣味開発でマネージドデータベースに課金したくない勢に安DBソリューションとして好評だったlitestreamについての近況をまとめてみました。安DBという謎の用語は「運用コストが安いデータベース」の意味で今作りました。 軽くおさらいするとlitestreamはSQLiteのレプリケーションを実現するミドルウェアで[1]、LiteFSはそれを分散環境に拡張してスケールをしようとしたもの[2]。 LiteFS Cloudはサ終した litestreamの技術をマネージドサービスにしようとたくらんだLiteFS Cloudは[3]、有料版が始まったかと思ったらいきなり提供終了した。 全然利用されなかったことが理由のようだ。確かにLiteFS自体が実験的な段階のソフトウェアな上にConsulサーバーと連携したり使いこなすのは難しい印象があった。 LiteFS は開発停止してる LiteFS自体は放
はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお
Scaling SQLite to 4M QPS on a single server (EC2 vs Bare Metal) Expensify has an unusual technology stack in many ways. For example, we don't use DNS internally -- just configuration-managed /etc/hosts files -- and it works great. Similarly, we only make limited use of AWS -- instead hosting our own hardware for the web and database layer -- and it works great. But most surprising of all is tha
-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885…
はじめに Next.js を Cloudflare にホスティングしようとすると、必然的に Edge Runtime 環境になります。しかし、Edge Runtime 環境では、Node.js Runtime と異なり、Prisma がそのまま使えません。 最初に思い浮かぶ解決策は Prisma Accelerate です。Prisma Accelerate は公式のサービスで、接続プールイングやグローバルキャッシュ機能を備えており、Edge Runtime でも Prisma を使えるようにします。 しかし、無料プランだと月に 6 万クエリの制限があり、本番運用には不安が残ります。 そこで、今回は Prisma Accelerate を自前で Cloudflare Workers 上に構築し、本番運用に耐えうるサービスを無料で開発する方法を紹介します。この方法なら、無料プランでも 月に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
