次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！ こんにちは！IT基盤部の熊谷です。IT基盤部にて大規模ゲームのインフラを見ている 新卒２年目のインフラエンジニアです。この記事では “DeNA でのデータベース運用とそのツラミ” と、“TiDB導入への検証・検討” をご紹介させていただきます。 データベースの最適解 DeNA のデータベース構成は最適解を求めて改良を積み重ねてきました。最初期の構成、(便宜上、第１世代と呼びます) では VM Instance 上に MySQL を構築し管理する MySQL on EC2 構成。続く第２世代では、マネージドサービスを駆使した Aurora MySQL 構成。この２世代の中で生じた “ツラミ” を解消する次の世代、言わば 第３世代に該当する新しいデータベース構成を現
![次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7a9ef2e383cbfc8885ee9e5572b0b143267e771/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F01%2Finfra-meetup-tidb%2Fcover.png)
Aurora MySQL のバックアップは本当にそれでいいのだろうか？ | CyberAgent Developers Blog
技術本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 また Amazon Aurora MySQL（以下：Aurora MySQL）の話です。何でこんなに Aurora MySQL に関する記事ばっか書いてるのか僕も分かりません。 前回の Aurora MySQL のアップグレード方法のベストプラクティスはこちらです。 RDS Graviton2 に少ないリスクで切り替える方法を考えてみる【アップグレード編】 | CyberAgent Developers Blog 今回はバックアップについてです。 そのクラスター、間違ったクエリ流したときに
RDS Auroraを使っているところで、OSの空きメモリが少なくなったアラートが出たので、それについて細かく考察したら、それなりの量になったのでまとめた感じです。 別にAuroraじゃなくRDS MySQLでも、MySQL Serverでも同じ話なのですが、クラウドならではの側面もあるなということでタイトルはRDSにしております。 RDSのメトリクス監視 RDSはブラックボックスとはいえ、必要なメトリクスはだいたい揃っているので、CloudWatch を見たり……APIで取得してどっかに送りつけたりして利用します。 なので、まずは接続数とメモリについて復習です。 SHOW STATUS 的には Threads_connected です。 CloudWatch Metrics 的には、DBInstanceIdentifier → DatabaseConnections です。 見た感じ、ど
助けて！ CloudWatch Logs のコストが急上昇!! ログ管理の最適化でコストを 1/3 にした話 - カミナシ エンジニアブログ
カミナシ ソフトウェアエンジニアの mina（@yoiyoicho）です。このブログでは、私が所属する「カミナシ ID」開発チームにおいて実施した、インフラコストの最適化施策について紹介します！ 「カミナシ レポート」の認証機能移行によりインフラコストが増加 「カミナシ ID」は OIDC / OAuth 2.0 などの標準仕様に準拠した、カミナシの ID 管理・認証基盤プロダクトです。インフラは AWS の各種サービスを活用して構築されています。 「カミナシ ID」は認証基盤という性質上、高いセキュリティや監査能力が求められます。そのため、API サーバーのアプリケーションログに加えて、データベースに対する操作やアクセス履歴をすべて記録した監査ログなど、各種ログを詳細に出力しています。これらのログは一度 CloudWatch Logs に集約され、Kinesis Data Firehos
Amazon Aurora MySQLの不具合でローカルディスクが枯渇しクエリが実行出来なくなった話 - Kaizen Platform 開発者ブログ
SRE Group Managerをしている前田です。今回の記事は当社で遭遇したAmazon Aurora MySQLの不具合の話になります。 3行まとめ Amazon Aurora MySQLのローカルストレージが異常な速度で消費、枯渇しクエリを実行するとエラーが発生するようになった 原因調査とAWSサポートへの問い合わせの結果、Aurora MySQL 2.10.0 の不具合と判明し、2.10.2へバージョンアップで解消 Auroraのローカルストレージは自動拡張されないので、残容量の監視をしましょう 事象発生と解決までを時系列で記載。 2021年10月、Auroraに対してクエリが実行出来なくなる 社内メンバーよりBIツールからAurora MySQLに対してのクエリがエラーになるとのことで、クエリに limit 100 を付けると実行出来、 limit 1000だと Error w
Amazon RDSからAuroraへ Mackerelのデータベース移行で何が改善したか - Hatena Developer Blog
こんにちは、MackerelチームでSREをしている id:heleeen です。 2023年3月に実施したMackerelのメンテナンスでは、データベースをAmazon RDSからAmazon Auroraに移行しました。この記事ではAuroraを選択した背景や、移行で考慮したことについてお伝えします。 データベースのアップグレードを機に検討 Auroraへ移行することによるメリット パフォーマンスの改善 マイナーバージョンアップのダウンタイムが短く サイジングを適切にできリソース活用も効率的に リードレプリカの運用負荷も改善 Auroraのリードレプリカを利用した移行 RDSにAuroraのリードレプリカを作成する リードレプリカの昇格と切り替え 本番のAurora移行に向けて準備したこと 検証環境で移行して課題を確認 本番メンテナンス時のバックアッププランを用意 Mackerelのメ
新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
2022.06.16 技術記事 新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] by Keijun Kumagai #infrastructure #aurora #aws #database #technical-verification #game-infrastructure #infra-quality こんにちは！IT基盤部の k-jun です。IT基盤部にて大規模ゲームのインフラを見ているインフラエンジニアです。この記事では、2022/04/21 に GA となった AWS の新サービス Aurora Serverless v2 に対して行った技術検証とその調査結果をご紹介させて頂きます。 Aurora Serverless v2 とは Aurora Serverless v2 は Amazon Aurora のオンデマン
![新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/edc2033bd2be270f3538bbd3e3b9bd2d546575d4/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F06%2Faurora-serverless-v2%2Fcover.png)
アプリケーション開発者のための PostgreSQL アーキテクチャに関する検討: パート 1 | Amazon Web Services
Amazon Web Services ブログ アプリケーション開発者のための PostgreSQL アーキテクチャに関する検討: パート 1 アプリケーション層は多くのクラウドアーキテクチャで世界中がアクセスする部分ですが、使用しているデータベースに合わせてアプリケーションを最適化する方法を検討することはほとんどないようです。リレーショナルデータベースエンジンを使用するときは、スキーマの設計だけでなく、アプリケーションが管理可能で、スケーラブルで、パフォーマンスが高いことを保証するために、データベースがストレージシステムに対してデータを読み書きする方法を理解することが重要です。シリーズのパート 1 となるこの投稿では、PostgreSQL の主要な用語について説明し、次に、Amazon Aurora PostgreSQL 互換エディションまたは Amazon Relational Dat
Amazon Aurora のインフラコストを55％削減しました。 - Stanby Tech Blog
はじめに こんにちは。スタンバイで求人データ管理に関するバックエンドエンジニアをしている池田です。 スタンバイはWEB上に存在する大量の求人を一括検索できるサービスを提供しており、その求人票のマスタのデータは Amazon Aurora を使って運用しております。 以下の記事で説明をしておりますが、2021年に求人取込直後の求人情報を構造化データとして保存するために Amazon Aurora を採用しました。 スタンバイの求人情報取込の仕組みを作り直した話 〜序章〜 DBエンジンとして Aurora ( MySQL 5.7 ) を利用しております。 ストレージエンジンとしてInnoDBを利用しております。 しかし作り直しから時が経ち、求人票の増加や各種機能の追加等によって Aurora のデータ量は想定上の速さで増加していき、それに比例する形でインフラコストも増加し続けていました。 今回
Amazon Aurora Serverless v2が最小キャパシティ0に対応し、自動停止･再開が可能になりました | DevelopersIO
Amazon Aurora Serverless v2が最小キャパシティ0に対応し、自動停止･再開が可能になりました Amazon Aurora Serverless v2 はAurora Capacity Unit(ACU)という単位でリソース管理され、0.5 ACU単位でワークロードに応じてスケールアップするサーバーレスデータベースです。従来は最小ACUが0.5でしたが、0キャパシティに対応したことにより、アクティビティのないインスタンスが自動的に停止・再開するようになりました。 例えば、本番･開発環境に同じAurora Serverless v2を導入しているケースにおいて、夜間や週末はアイドル状態を伴う開発環境の最小ACUを0にしておけば、利用がなくなるとインスタンスは自動停止し、コスト削減に繋がります。 対応DBエンジン 以下のAuroraエンジンに対応しています Postgre
リクルートが『スタディサプリ』で Amazon Aurora Serverless v2 を採用。コストを最適化しつつ Aurora の管理工数を大幅削減 | Amazon Web Services
Amazon Web Services ブログ リクルートが『スタディサプリ』で Amazon Aurora Serverless v2 を採用。コストを最適化しつつ Aurora の管理工数を大幅削減 株式会社リクルートは、日本国内のHR・販促事業及びグローバル斡旋・販促事業をおこなう事業会社です。リクルートでは、『スタディサプリ』というスマートフォンアプリ、パソコンで利用可能なオンライン学習サービスのデータベースとして Amazon Aurora PostgreSQL を採用しています。 2023 年 5 月にこの Aurora PostgreSQL を Aurora Serverless v2 に変更しました。採用検討から 1.5 ヶ月と短期間で導入を決定しましたが、入念な検証の結果 Aurora の運用負荷を大幅に削減し、サービスの安定運用も実現しています。本ブログは、『スタディサ
Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life
Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide
Aurora MySQL 5.6のサポート終了とゼロダウンタイムアップグレードへの挑戦 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、グローバル向けAWS版kintoneのバックエンドエンジニアをしている@ueokandeです。 8月になって暑い日々が続きますね。そして8月と言えば、Amazon Aurora MySQL-Compatible Edition version 1 with MySQL 5.6 compatibility（以下Aurora MySQL 5.6）のサポート終了までおよそ半年となりました。 グローバル向けAWS版kintoneでは、Aurora MySQL 5.6を採用しているバックエンドサービスがいくつかあり、チームで移行作業に取り組んできました。この移行作業は単なるアップグレードだけではなく、ダウンタイムなしでデータベースを移行するチャレンジにも取り組みました。この記事ではAmazon Auroraの移行作業の全貌と、移行戦略を紹介します。 Aurora MySQL 5.6のサポ
全世界で登録ユーザー数6000万人を超えるカレンダーシェアアプリを展開するTimeTree。同社ではそれら大量のデータを管理するデータベースをAmazon Aurora（以下、Aurora）からGoogle CloudのCloud Spanner（以下、Spanner）に移行した。Spannerを選択した背景、移行プロジェクトがうまくいった秘訣などを、同プロジェクトの立ち上げから携わった技術本部SREチーム マネージャーの金井栄喜（miu）氏とSREチーム バックエンドエンジニアのGreg氏に話を聞いた。 ローンチから10年、世界6000万ユーザーを抱える「TimeTree」 ──自己紹介をお願いします。 金井栄喜氏（以下、金井）：TimeTreeのSREチームのマネージャーとして、チームの醸成やメンバーの育成を担当しています。またスタッフエンジニアという役割も担っており、主にパブリックク
久々にAuroraについて、小ネタ系で書いてみるテスト。 主にストレージIOPSにまつわるTipsで、光り輝くモノは別にないですけど、基本が大事ということで。 ストレージIOPSのグラフ生成 データベースの運用において、監視データであるメトリクスを色々収集するのは基本ですが、その中でも最重要に位置する項目である ストレージのIOPS についてです。 まず、Auroraのストレージ構成は共有型であり、IOPSメトリクスはホスト毎ではなくクラスタ毎のデータとして記録されています。 参考ページ Aurora ストレージエンジンのご紹介 Amazon Aurora DB クラスターメトリクスのモニタリング RDS Aurora の管理画面でモニタリングを見ると、グラフ名が [請求済み] ボリューム読み取り IOPS (カウント) [請求済み] ボリューム書き込み IOPS (カウント) となってい
Aurora MySQLとAurora PostgreSQLの機能を比較してみた(2022年4月版) | DevelopersIO
ここまでで、本エントリでまとめたかったことが9割5分終わりました。 他にもこんなところに機能差異があるよ！や、ここ間違っているぞ！などの情報があればTwitter(＠ashi_ssan)のリプライもしくはDM等でぜひフィードバックいただきたいです。 いくつかピックアップして説明してみる ここまでで終わり、ではなんとなく味気ないエントリになってしまうと思ったので、機能に差があった箇所について個人的に気になった機能を数点ピックアップしてみました。 バックトラック バックトラックは指定した時間までDBクラスターを「巻き戻す」機能です。 サービスの中断を最小限に抑えながらのエラーの取り消し、数分で巻き戻し可能な迅速な実行などが可能なところに利点があります。 バックトラックの機能の概要について、以下のアップデートブログを参照ください。 そんなバックトラックですが、対応しているDBエンジンはMySQL
Amebaの大規模Aurora MySQLクラスタでのサービス無停止アップグレードへの挑戦 | CyberAgent Developers Blog
この記事は CyberAgent Developers Advent Calendar 2024 9日目の記事です。 こんにちは、Serveice Reliability Group(SRG)の鬼海 雄太(@fat47)です。 SRGは主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事ではアメーバブログを中心としたサービスの大規模Aurora MySQLクラスタを、サービス無停止でアップグレードするためにどのような取り組みをおこなってきたかをお伝えします。 Amebaの大規模Aurora MySQLクラスタについて アメーバブログは2004年にオープンしたブログサービスであり、今年20周年を迎えた長期間運用されているサービスです。Amebaは、このアメーバブログを中心に様々なサービスで構成され
[アップデート] Amazon Aurora でクラスターボリュームサイズの縮小が可能に！不要なデータ削除でコスト削減だ！ | DevelopersIO
[アップデート] Amazon Aurora でクラスターボリュームサイズの縮小が可能に！不要なデータ削除でコスト削減だ！ ドキュメントの更新情報からの共有ですが、Amazon Aurora でデータ削除によるクラスターボリューム（ストレージ）の縮小が可能になったようです！ 以下、ドキュメント更新履歴からの情報です。 Amazon Aurora クラスターボリュームの縮小 ご存知のとおり Amazon Aurora のクラスターボリュームはデータ量に応じて動的に拡張されます。ボリュームサイズを指定する必要はありません。一方でボリュームサイズの縮小には対応していませんでした。（縮小は Aurora に限らず、他の RDS エンジンでも同じです） 例えば、一時的に大きなデータを格納するために 50 GB から 100 GB に拡張されたとします。その後、不要になったので 50 GB のデータを
本番環境のAmazon Aurora MySQL v1(MySQL 5.6 互換)EOL対応でAmazon RDS Blue/Green Deploymentsを使ってアップグレードしてみた手順と所感 - コネヒト開発者ブログ
こんにちは。コネヒトのプラットフォームグループでインフラエンジニアをしている@sasashuuuです。 本日は、今年2月に対応した弊社の主力サービスであるmamariをはじめとする各種アプリケーションで使用している本番環境Amazon Aurora MySQL v1(MySQL 5.6 互換)のEOL対応において、まだリリースされてから間もない新機能であるAmazon RDS Blue/Green Deploymentsを本番導入した際の流れや所感についてまとめたいと思います。 はじめに 本記事の内容は実際にEOL対応に向けての検証を行っていた際や、EOL当日対応時の状況などを含んでおり、取り扱っているAWSサービスの仕様やその他記載内容は当時のものとなっています。最新の情報などはAWSの公式ドキュメントを参照してください。（公式ドキュメント先リンクは次項「Amazon RDS Blue/
Amazon Aurora の KMS キーをシュッと差し替える - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL を使っています（以下 Aurora と略します）。また、データ保護の追加レイヤーとして KMS を使って DB クラスターを暗号化しています。 docs.aws.amazon.com ここまでは良いのですが、KMS キーに AWS マネージドキーが設定されていました。普段から AWS を使っている方であれば「あちゃ〜」と思われるでしょう。 なぜ Aurora の KMS キーに AWS マネージドキーを使うのが「あちゃ〜」なのか KMS キーには、AWS マネージドキーとカスタマーマネージドキーの 2 種類があります。 AWS マネージドキーはユーザーに代わって作成されるキーで、RDS の場合は aws/rds というエイリアス名が付いています。
Aurora PostreSQLのログをCloudWatch Logsを経由せずに直接S3バケットにPUTしてみた | DevelopersIO
CloudWatch Logsを経由せずに直接S3バケットにログをPUTしたい こんにちは、のんピ(@non____97)です。 皆さんはAurora PostgreSQLのログをCloudWatch Logsを経由せずに直接S3バケットにログをPUTしたいと思ったことはあります? 私はあります。 CloudWatch LogsにDBのログを流すとそれなりに料金がかかります。特にlog_statementであればall、mod、pgaudit.logであればall、read、writeにすると大量のログが流れがちです。 Aurora PostgreSQL DB クラスターのクエリログ記録をオンにする - Amazon Aurora pgAudit 拡張機能のセットアップ - Amazon Aurora そのため、S3バケットにログを出力したいところでしょう。 S3バケットにログを出力する方
「制約を知れば知るほど、もっとそのテクノロジーへの愛が深まる…」 以前こんなツイートしたところ、いくらか反応がありました。 re:Invent 2024におけるAurora DSQLの発表はかなりのインパクトがありましたが、改めてドキュメントに目を通してみると、これは従来のAurora（PostgreSQL）とはかなり違うなぁという印象を持つ人も多いと思います。 このブログでは、Aurora DSQLの制約（できないこと）を中心に情報をまとめています。まだパブリックプレビューのAurora DSQLですが、この制約を知っておくことで、逆にAurora DSQLの使い所や特徴が浮かび上がってきます。 まだ現在はAurora DSQLの利用に料金がかかりません。今のうちにあれこれさわってみつつ、実運用を見据えた時にどのような制約がありそうか体験してみるのも良いと思います。 ほな、いってみよ！！
Amazon Aurora Limitless Databaseの3種類のテーブルの違い ~ Standard/Sharded/Reference ~ | DevelopersIO
Amazon Aurora Limitless Databaseの3種類のテーブルの違い ~ Standard/Sharded/Reference ~ AWSの提供する分散データベースAmazon Aurora Limitless Databaseには3種類のテーブルタイプが存在します。 Standard : 特定のシャードに保存されるデフォルトのテーブルタイプ Sharded : 複数のシャードに分散されるタイプ Reference : すべてのシャードにレプリケートされるタイプ 複数の Sharded テーブルを同じシャードキーで管理すると、 Collocatedタイプとなります。これらの違いを確認します。 サンプルスキーマ 検証のために、ECサイトを想定したAWSが提供する次のLimitless Database用のスキーマを活用します。 このサンプルでは、一度Standardテーブ
この記事はfreee 基盤チーム Advent Calendar 2023 の24日目の記事です。 はじめに はじめまして！ kanno と申します。freee SREで、freeeサインのプロダクトSREを担当しておりAWSインフラの改善や運用を主に行っています。初回の投稿で拙い文章になりますが、直近で実施したfreeeサインのAWSリージョンを移行した話を書こうと思います。 背景 元々、freeeサイン(旧ninja-sign)はHeroku上にアプリケーションをデプロイしていましたが、2022年の年末頃にAWSに移行しています。その際、元々のHerokuがus上で稼働していたことが影響して、AWSのバージニアリージョンに移行された状態でした。私がfreeeのサインチームにjoinしたのがこの時で、AWSリージョン移行を担当することになりました。 AWSリージョン移行のモチベーション
RDS Proxyが拡張クエリプロトコルに対応し、ピン留めの発生条件が緩和されました | DevelopersIO
CX事業部@大阪の岩田です。 本日のアップデートによりRDS ProxyがPostgreSQLの拡張クエリプロトコルをサポートするようになりました。本ブログではこのアップデートについてご紹介します。 ちなみに以前はpinningが「ピン留め」と翻訳されていましたが、最近は「固定」翻訳とされているようです。個人的にはピン留めの方がしっくりくるので、本ブログにおいては公式日本語ドキュメントが「固定」と翻訳している事象を全て「ピン留め」と呼ぶことにします。 そもそも拡張クエリプロトコルとは？ PostgreSQLではクエリを実行するためのプロトコルに、簡易クエリプロトコルと拡張クエリプロトコルという2つのプロトコルが存在します。ざっくりとした理解として、簡易クエリプロトコルの場合は生のSQL文をそのままサーバーに送信するのに対して、拡張クエリプロトコルの場合はパラメータを利用したSQL文を送信し
Data Modernization Day in Japan #3 「2.5時間で学ぶ！ Amazon Aurora のいま」資料・動画及び QA 公開 | Amazon Web Services
Amazon Web Services ブログ Data Modernization Day in Japan #3 「2.5時間で学ぶ！ Amazon Aurora のいま」資料・動画及び QA 公開 先日(2022/9/1) に開催した Data Modernization Day in Japan #3「2.5時間で学ぶ！ Amazon Aurora のいま 〜アーキテクチャと高可用性にパフォーマンスチューニングをそえて〜」の資料・動画を公開しました。今回のセミナーでは、RDS/Auroraの最新アップデートのセッションに加え、多くのお客様へのご利用が加速しているAuroraに関して、アーキテクチャ・高可用性・パフォーマンスチューニングに関するDive Deepセッションを行いました。 当日、参加者の皆様には数多くの QA を頂きありがとうございました。頂いた QA の一部についても
Amazon Aurora Serverless v2 supports scaling to zero capacity - AWS
Amazon Aurora Serverless v2 now supports scaling to 0 Aurora Capacity Units (ACUs). This launch enables the database to automatically pause after a period of inactivity based on database connections. When the first connection is requested, the database will automatically resume and scale to meet the application demand. Aurora Serverless v2 measures capacity in ACUs where each ACU is a combination
Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL | Amazon Web Services
AWS Database Blog Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL Purge is a housekeeping operation in a MySQL database. The InnoDB storage engine relies on it to clean up undo logs and delete-marked table records that are no longer needed for multiversion concurrency control (MVCC) or rollback operations. While our applications pursue a database design that aims
『呪術廻戦 ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化 - Sumzap Engineering Blog
この記事は、2024年3月7日に開催された「CyberAgent Game Conference 2024（CAGC 2024）」のセッション内容をAIによる自動文字起こしをベースに加筆修正したものになります。 セッション概要 TVアニメ『呪術廻戦』初のスマホゲーム『呪術廻戦 ファントムパレード（ファンパレ）』は、多くのユーザーに遊ばれ大量のアクセスが来ることが予想されていました。 本セッションでは、高負荷が予想される中、どのようにインフラを構築し負荷対策を行ったのか、実際のインフラ構成図をお見せしながらお話しします。 また、アプリリリース前に行った負荷試験の流れや、リリース後の負荷状況について、具体的なメトリクスの数字をお見せしながらご紹介します。 ※セッションのアーカイブ動画 登壇内容 タイトル 『呪術廻戦 ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化というタイトル
Aurora DSQL は何が新しいのか？（vs. これまでの Aurora 編）[DeNA インフラ SRE] | BLOG - DeNA Engineering
2025.03.11 技術記事 Aurora DSQL は何が新しいのか？（vs. これまでの Aurora 編）[DeNA インフラ SRE] by Hiroyuki Nishizaki #infrastructure #sre #database #aws #aurora #re:Invent こんにちは、IT 基盤部第4グループの西崎です。主に DeNA がグローバルに展開するゲームのインフラ管理を担当しています。 今回は昨年末の AWS re:Invent で発表された Amazon Aurora DSQL（以下 Aurora DSQL）について紹介します。ちょうど最近データベースについて調べていたのですが、その最中に AWS re:Invent 2024 での Aurora DSQL の発表を見て、Aurora DSQL がこれまでのデータベースとなぜ、どのように違うのかを知って
![Aurora DSQL は何が新しいのか？（vs. これまでの Aurora 編）[DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/ee44116ccd9542887531d730aef7e974c203ffe8/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2025%2F03%2Faurora-dsql_01_aurora%2Fcover.png)
ProxySQL を利用した Aurora MySQL の課題解決 [DeNA インフラ SRE] | BLOG - DeNA Engineering
2022.11.01 技術記事 ProxySQL を利用した Aurora MySQL の課題解決 [DeNA インフラ SRE] by yayohei #infrastructure #sre #database #aws #aurora #mysql #proxysql #stabilization #livestreaming-infrastructure #infra-quality こんにちは、 IT 本部 IT 基盤部第一グループの山本です。 今回は ProxySQL を利用した Aurora MySQL の新規接続の遅延問題の解消方法について紹介したいと思います。 Aurora MySQL のメリット Aurora MySQL のメリットとしては本稿で詳しく語るまでもないですが、Writer の 自動 Failover、Snapshot の取得の容易さ、Storage 故障の
![ProxySQL を利用した Aurora MySQL の課題解決 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/86065d7b8409d04e7be80a93878f716de9247a45/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F11%2Finfra-proxysql%2Fcover.png)
当ブログサイト(DevelopersIO)のDBを「Aurora Serverless v2」に移行してみた | DevelopersIO
AWSチームのすずきりょうです。 当ブログサイトの「DevelopersIO」2015年より記事のデータベースとして Amazon Aurora を利用しています。 先週一般公開された Aurora Serverless v2 への移行する機会がありましたので、紹介させていただきます。 事前準備 Aurora Serverless v2 をサポートする DBエンジンへのアップグレードを実施しました。 切替作業 Serverless v2 リーダーの追加 DBインスタンスクラス「Serverless v2」のリーダー(リードレプリカインスタンス)を追加しました。 フェイルオーバ優先順位は「tier-1」、ライターインスタンスと同等のDB性能を維持する指定としました。 「db.r6g.large」(vCPU:2、メモリ:16GiB)のライターでは、「tier-1」指定の 「Serverless
熊谷氏の自己紹介と、本セッションの概要熊谷圭遵氏：それでは「Aurora Serverless v2 コスト戦略の羅針盤」という題で、DeNA熊谷よりお話しします。よろしくお願いします。 最初に自己紹介です。社内ではk-junというハンドルネームでやっています。入社は2020年度の新卒になるので、社会人3年目ということになります。職種はインフラエンジニアに従事していて、大規模のゲームのインフラを見るような仕事をしています。趣味はウクレレとかボードゲームなどが好きです。 はじめに、今回のプレゼンで話す内容を簡単に2点紹介します。1点目に、Aurora Serverless v2のACU増加速度検証についてアップデートがあるので、こちらを紹介します。2点目に、Aurora Serverless v2の導入検討のコスト面について紹介できればと思います。 目次です。4フェーズに分けてお話ししていけ
【レポート】スパイクにもすぐにオートスケールするようになったAmazon Aurora Serverless v2のDeep Dive #reinvent #EMB023 | DevelopersIO
Amazon Auroraは商用データベースと同等のパフォーマンスと可用性を低コストで実現するRDBです。 2018年から自動的にキャパシティがスケーリングする Aurora Serverless が提供されていましたが、今年の re:invent でその進化版「 Aurora Serverless v2」がプレビュー公開されました。 Aurora Serverless v2 のポイントは次の2点です。 ワークロードに対してより滑らかにスケーリングするようになった Aurora の様々な高機能に対応 本レポートはその v2 の NEW LAUNCH セッションです。 セッション概要 タイトル : [NEW LAUNCH!] Amazon Aurora Serverless v2: Instant scaling for demanding workloads スピーカー : Murali
はじめに 概要 Amazon Auroraのバックアップからデータの復元までについて、色々と方法があるようでなんとなくの理解ではまずいと感じたのでまとめてみました。 全体像 バックアップの種類 バックアップ〜復元には3つの種類があります。 バックトラック(Aurora MySQLのみ) ポイントインタイムリカバリ スナップショット この3つをバックアップの要件に基づいて選んでいきます。 上から順にデータを保持しておく時間が短く、その分復元までの時間が早いです。 一旦、全体図を載せます。 Auroraの仕組み 各用語 バックアップの説明の前に簡単にAuroraの基本用語について理解していきます。 クラスタボリューム データベースの中身。 データを格納するところ。 DBインスタンス データベースにデータと登録するやつ。 データ読み書きをしてるやつ。 DBクラスタ クラスタボリュームとDBインス
「楽観同時実行制御ね。おーおーおー、そういうことね。なるへそ？」 Aurora DSQLは、re:Invent 2024の最大の発表でした（個人の感想です）。キーノートの最中に、いきなりGoogle CloudのSpannerが引き合いに出されるほどだったので、Spannerファンの人にも要チェックのアプデだったのではと思います。 マルチリージョン対応 高可用性とスケーラビリティ VPCの外で稼働 サーバーレス設計 ACID特性のサポート PostgreSQL互換rd 楽観的同時実行制御（OCC）の採用 分散アーキテクチャ など、ポイントが目白押しのAurora DSQLですが、トランザクション制御の仕組みが、RDBでは聞き慣れない楽観的同時実行制御（OCC）が採用されていると聞き、改めてその挙動を手を動かしてまとめてみました。 はっきり言います。ドキュメント読んでいるだけより手を動かした
【New!】Amazon Aurora MySQLがRDS Data APIをサポートしました！ | DevelopersIO
こんにちは。まるとです。 現地時間 2024/9/26、Amazon Aurora MySQLでもRDS Data APIをサポートするアナウンスがありました！ 従来は、Amazon Aurora PostgreSQLのみのサポートとなっておりましたが、今回新たにAmazon Aurora MySQLでもサポートしたことにより、更にDBエンジンの選択肢が増えるのではないでしょうか。 そもそも、RDS Data APIって何？何がすごいの？と感じる方もいらっしゃるかもしれません。 そこで、改めてRDS Data APIを整理し、実際に触っていきたいと思います。 RDS Data APIとは 一言でお伝えすると、APIを通してSQLステートメントを実行できるものです。 特徴としては以下のようなものが挙げられます。 DBクラスターへの永続的な接続が不要（接続を管理する必要がない） HTTPSエン
AWS re:Invent 2022 にて RDS の Blue/Green が発表されたことを受けて、この辺の具体的な運用をどのように改善できるのか考えていきます。 たいした内容ではないですが、丁寧に最適化して慣れれば、それなりに強い効果を発揮できそうな感じはあります。 ALTER TABLE の辛み まず復習からですが、RDS に Blue/Green が実装されるほど辛い運用はなんだったかというと、重い ALTER TABLE にあります。 ALTER には色々あるのでアレですが大雑把に言うと、容量や行数が大きいテーブルに対して実行すると、数時間単位～の処理時間がかかることが多く、しかもパッと見で進捗を把握できないという問題を抱えていました。それに対して色んな対策を取っていたと思います。例えば…… Handler_write SHOW GLOBAL STATUS LIKE ‘Hand
Amazon Aurora MySQL 5.6を頑張らずに8.0へメジャーアップグレードしてみた | DevelopersIO
小規模システムであること 長いメンテナンス時間を確保できること 単純・明快な方法が好まれること といった点から インプレース方式を採用しました。 インプレース方式 AWSのマネージド機能をフル活用し、クラスターを直接メジャーアップグレードします。 コンソールからボタンポチで作業が完結する一方で、マイグレートには比較的時間がかかります。 切り戻し時には、マイグレート前に作成されるスナップショットを利用します。 ダンプ & リストア方式 移行先バージョンのクラスターを作成し、mysqldump 等を利用してクラスター間でデータをエクスポート&インポートします。 弊社の技術ブログ・サイト Developers.IO を v2 から v3化(ついでに Aurora Serverless v2化)した際は、この方式を採用しました。 Aurora2(MySQL5.7互換)のDB環境をAurora3(M
Serverless FrameworkでAurora Postgres + VPC Lambda + RDS Proxyをデプロイする | DevelopersIO
Serverless FrameworkでAurora Postgres + VPC Lambda + RDS Proxyをデプロイする Serverless Frameworkを用いて、RDS Aurora Postgres、VPC Lambda、RDS Proxyをまとめてデプロイする方法をご紹介します。 こんにちは、クラスメソッドの岡です。 7月にRDS ProxyがGAとなったことで、サーバーレスでのRDS実用化待ったなし！！ということで今回はServerless FrameworkでRDS Aurora Postgres、VPC Lambda、RDS Proxyをまとめてデプロイしてみたので、テンプレートの中身を紹介していこうと思います。 動作確認環境 Python3.8.5 Serverless Framework Framework Core: 2.1.1 Plugin: 4
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDSで接続数とメモリ消費量の調整事例 | 外道父の匠
世界6000万ユーザーの「TimeTree」、サービスの未来を見据えて挑んだデータベース移行の舞台裏
Aurora運用Tips IOPS編 | 外道父の匠
Aurora DSQLの制約を知ってより理解を深める | DevelopersIO
freeeサインのAWSリージョンを移行した話 - freee Developers Hub
Aurora Serverless v2とAurora Provisionedのコスト比較 3つの変数を“羅針盤”に優位境界面を探る | ログミーBusiness
Amazon Aurora バックアップってややこしい - Qiita
Aurora DSQLの楽観同時実行制御を手を動かして学ぶ | DevelopersIO
AWS RDS/AuroraのDDL運用を最適化する | 外道父の匠
plea5station.com
pured.doorblog.jp
blog.peddals.com
note.com/kawaidesign
news.yahoo.co.jp
lifemilestone.hatenadiary.com