AWS RDS/Auroraでモニタリング＆チューニングを始めるための資料11選
これはなに ども、レバテック開発部のもりたです。 もりたはデータベースが好きなんですが、最近は特にAWS RDS/Auroraでのモニタリングとパフォーマンスチューニングについて興味があります。ただ、これらのうちモニタリングは扱っている話題が若干ローレベルであまりピンとこず、またチューニングもどこから手をつければいいのかわかりませんでした。 この記事では、もりたがモニタリング＆チューニングを学習する上で役に立った書籍やWeb上の資料をロードマップ形式で紹介していきます。対象読者はDBのモニタリングとチューニングをやりたいけどどこから手をつければいいか分かんないなとなっている人、ゴールはそんな人がモニタリング＆チューニングの第一歩を踏み出せることです。 スコープ 今回扱うもの、扱わないものは以下の通りです。 扱う モニタリング＆チューニングの概要 モニタリングの前提知識 チューニングの前提知
Aurora MySQL version 3でTempTable溢れの振り返り
9/11に開催された、【Chatwork × みてね勉強会】EKS＆Aurora最新ノウハウでお話させていただいた、みてねSREの伊東の登壇資料です。
大規模サービスのデータベースエンジンを MySQLからAurora MySQLへの移行 〜リードレプリカ, DNSを利用した最小ダウンタイム移行方法〜 - メドピア開発者ブログ
バックエンドエンジニアの徳富(@yannKazu1)です。先日、メドピアのメインサービスであるmedpeer.jpで使われているデータベースエンジンを、MySQLからAurora MySQLへと移行しました。今回はその移行のプロセスについて詳しくお話しします。 移行したデータベースの簡単なインフラ構成 移行方針 今回移行するデータベースは複数のアプリケーションから参照されており、ダウンタイムによるユーザー影響が大きいため、移行方針の検討の段階で重視したのは、ダウンタイムの最小化でした。これを達成するために、DNSのCNAMEレコードと、Auroraのリードレプリカを活用し、移行させることにしました。 DNSのCNAMEレコードの使用 データベースエンドポイントをアプリケーションに直接記述する代わりに、DNSのCNAMEレコードを利用して間接的に参照するようにしました。これにより、データベー
【塩漬けダメ絶対】AWSのAurora＆RDSがDBエンジンの延長サポートを有償提供！ - Qiita
日本時間 2023/9/1(金)の深夜、AWSより以下のアップデートが発表されました！ 土曜の朝からXで早速話題になっています。 ニュースリリース ブログ ※全体的にまだ日本語ドキュメントに反映されていない情報が多いので、リンク先にRDS Extended Supportに関する言及が見られない場合は言語設定をEnglishに切り替えて再確認することをお勧めします。 3行でまとめると？ AWSはAuroraおよびRDSのDBエンジンの所定サポート終了後、最大3年の延長サポートを有償提供する 対象のDBエンジンはMySQL 5.7 & PostgreSQL 11および、それ以降の主要バージョン 2023年12月から延長サポートへのオプトインが可能。実際の課金開始はバージョン依存。最速でも2024年3月1日以降となる クラウドにおける「DBバージョンアップ」の扱い AWSクラウドが提供するマネ
Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話
こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち（@_awache）による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに
Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい - GMOインターネットグループ グループ研究開発本部（次世代システム研究室）
2023.01.11 Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい Amazon Aurora MySQLでテーブルの再構築を伴う操作を行うと，Readerインスタンスで瞬間的に対象のテーブルが見えなくなる場合があるので，オペレーションの実行タイミングに気をけましょう，というお話です。再構築を伴う操作には，一部のALTER TABLEやOPTIMIZE TABLEが含まれます。 こんにちは，S.T.です。Amazon Aurora MySQLで少し気になる現象を見かけたので紹介します。この現象を知っていれば回避できるので，クリティカルな影響があるということではないですが，将来直ってくれると嬉しいですね。 1.Amazon Aurora MySQLとは Amazon Aurora MySQLはAWSで利用できるマネージドのRDBです。コ
一般公開された Amazon Aurora Serverless v2 を東京リージョンで試してみた | DevelopersIO
動作確認 初期ACU 作成直後のAmazon Aurora Serverless v2 のACU値を、CloudWatchのメトリック「ServerlessDatabaseCapacity」で確認しました。 インスタンスの作成直後のACUの値は32でした。 無負荷状態では、最小ACUの指定値(今回は8)まで段階的に低下していました。 INNODB_BUFFER_POOL_SIZE CLIを利用し、ACU値「8」で稼働中のDBの状態を確認しました。 $ DBHOST='aurora-ss-v2.cluster-xxxxxxx.ap-northeast-1.rds.amazonaws.com' $ echo 'SELECT @@GLOBAL.INNODB_BUFFER_POOL_SIZE/1024/1024' | mysql -h ${DBHOST} -P 3306 -u admin -p @
「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理
「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理 Amazon Web Services（AWS）は、クラウド上でデータベースのマネージドサービスとして提供している「Amazon Aurora Serverless」の新バージョン「Amazon Aurora Serverless V2」の正式版としてのリリースを発表しました。 Instant scale ↔️ instant cost efficiency. Amazon Aurora Serverless v2 scales in a fraction of a second while eliminating database capacity management, so you only pay for what you use & sa
Amazon RDS/Auroraをクローンするシステムを作った話 - クックパッド開発者ブログ
こんにちは、技術部SRグループの菅原です。 最近、Ninja650からNinja1000に乗り換えました。パワーがあるせいで３速発進・４速発進が平気でできてしまい、シフトワークがどんどん下手になっています。精進したいものです。 この記事では、Amazon RDS/Auroraをクローンするシステムを作った話を書きます。 Amazon RDS/Auroraをクローンするシステム サービス開発を行っていると、調査や検証でプロダクション環境で使われているデータベースが必要になることがあります。開発環境やステージング環境にもデータベースは存在するのですが、プロダクション環境のデータでしか再現しないバグの調査や、プロダクション環境のデータ量でのスキーマ変更の負荷の検証など、開発環境やステージング環境のデータベースではできない作業も多いです。しかし、オペレーションミスや個人情報へのアクセスを考えると、
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap） - Qiita
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap）MySQLAWSAurora 2018/01/13追記： 「AWSが再度パッチを当てたみたい」という情報があったので、3度目のベンチマークを行ったところ、db.r4.largeおよびdb.r4.xlargeについて、2017/10/末頃とほぼ同じ速度に戻ったことを確認しました。 「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） （以下、古い情報なので現在とは状況が異なります。） 以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。 Amazon AuroraでR4インスタ
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
Aurora 移行をキッカケに大きく改善したデータベース運用 | CyberAgent Developers Blog
はじめに クラウドファンディングプラットフォーム Makuake でウェブオペレーションをメインで担当している吉田慶章 ( @kakakakakku ) です．Developers Blog では，過去に『Well-Architected を目指した改善と組織文化への影響』を執筆したり，『「経営層を巻き込まないと開発組織は変わらない」――急成長するクラウドファンディングサービス「Makuake」エンジニアが社長と取り組んだこと』で組織変革をテーマにしたインタビューを受けたりしています．今回はサービスで使っているデータベースを MySQL 5.5 on EC2 から Amazon Aurora（以下，Aurora）に完全に移行した事例を紹介したいと思います．既にリリースをして約1ヶ月稼働していますが，大きな問題もなく安定稼働しています． 背景 例えばウェブサーバなど，既にスケールアウトが前提
Auroraの各種エンドポイントとダウンタイムの検証 | 外道父の匠
前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは３種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ
【Aurora】とあるWebサイトのDBをAmazon Auroraに移行してみた | DevelopersIO
はじめに AWSチームのすずきです。 今月（2015年10月）よりAWS東京リージョンで利用可能となった、RDS for Amazon Aurora。 とあるサイトのCMS（WordPress）のバックエンドDBとして稼働していたRDS（mysql）を移行し、 Amazon Auroraの性能の一端を確認できる機会がありましたので、紹介させて頂きます。 概要 RDSのスナップショットより、スナップショットの移行（migrate）を実施しました。 ElasticBeanstalkの機能(クローン、DNSスイッチ）を利用して、RDS（Aurora）参照環境の構築と切替を実施しました。 DBの最終同期として、mysqldumpコマンドによるエクスポート、インポートを行いました。 システム概要図 移行手順 スナップショットの復元 AWSコンソール、RDSのスナップショット画面より復元対象とするRD
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
Amazon Auroraの耐障害性について調べてみた | DevelopersIO
Amazon Auroraの耐障害性について プレビュー版のAmazon Aurora使えるようになったので色々試しています。Auroraには耐障害性（フォールト・トレランス）の仕組みがあり、何かしらの障害に対してサービスが継続的に停止しないような設計になっています。新しいDBエンジンということで、障害発生時にどのように対応すれば良いのか分かっていない方も多いかと思います。今回は、Auroraがどのような耐障害性を持っているのかご紹介したいと思います。 AuroraのDBクラスタ概念図 プライマリのインスタンス Auroraは、複数のAZにまたがったDBクラスタを組むことができます。この際、DBへの接続方法はIPアドレスではなくRDSが発行するホスト名を用います。例）mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
